SDLC - Guia Rápido

O Ciclo de Vida de Desenvolvimento de Software (SDLC) é um processo usado pela indústria de software para projetar, desenvolver e testar softwares de alta qualidade. O SDLC tem como objetivo produzir um software de alta qualidade que atenda ou supere as expectativas do cliente, alcance a conclusão dentro do prazo e das estimativas de custo.

  • SDLC é a sigla de Software Development Life Cycle.

  • É também chamado de Processo de Desenvolvimento de Software.

  • SDLC é uma estrutura que define tarefas executadas em cada etapa do processo de desenvolvimento de software.

  • ISO / IEC 12207 é um padrão internacional para processos de ciclo de vida de software. Pretende ser o padrão que define todas as tarefas necessárias para o desenvolvimento e manutenção de software.

O que é SDLC?

SDLC é um processo seguido por um projeto de software, dentro de uma organização de software. Consiste em um plano detalhado que descreve como desenvolver, manter, substituir e alterar ou aprimorar software específico. O ciclo de vida define uma metodologia para melhorar a qualidade do software e o processo geral de desenvolvimento.

A figura a seguir é uma representação gráfica dos vários estágios de um SDLC típico.

Um ciclo de vida de desenvolvimento de software típico consiste nas seguintes etapas -

Etapa 1: Planejamento e Análise de Requisitos

A análise de requisitos é o estágio mais importante e fundamental no SDLC. É realizado pelos membros seniores da equipe com informações do cliente, do departamento de vendas, pesquisas de mercado e especialistas no domínio da indústria. Essas informações são então usadas para planejar a abordagem do projeto básico e conduzir o estudo de viabilidade do produto nas áreas econômica, operacional e técnica.

O planejamento dos requisitos de garantia da qualidade e a identificação dos riscos associados ao projeto também são feitos na fase de planejamento. O resultado do estudo de viabilidade técnica é definir as várias abordagens técnicas que podem ser seguidas para implementar o projeto com sucesso com riscos mínimos.

Etapa 2: Definição de Requisitos

Uma vez que a análise de requisitos é feita, a próxima etapa é definir e documentar claramente os requisitos do produto e obter a aprovação do cliente ou dos analistas de mercado. Isso é feito por meio de umSRS (Software Requirement Specification) documento que consiste em todos os requisitos do produto a serem projetados e desenvolvidos durante o ciclo de vida do projeto.

Etapa 3: Projetando a Arquitetura do Produto

O SRS é a referência para que os arquitetos de produto apresentem a melhor arquitetura para o produto a ser desenvolvido. Com base nos requisitos especificados no SRS, geralmente mais de uma abordagem de design para a arquitetura do produto é proposta e documentada em um DDS - Design Document Specification.

Este DDS é revisado por todas as partes interessadas importantes e com base em vários parâmetros como avaliação de risco, robustez do produto, modularidade de design, orçamento e restrições de tempo, a melhor abordagem de design é selecionada para o produto.

Uma abordagem de design define claramente todos os módulos arquitetônicos do produto, juntamente com sua comunicação e representação do fluxo de dados com os módulos externos e de terceiros (se houver). O design interno de todos os módulos da arquitetura proposta deve ser claramente definido com o mínimo de detalhes em DDS.

Etapa 4: construção ou desenvolvimento do produto

Neste estágio do SDLC, o desenvolvimento real começa e o produto é construído. O código de programação é gerado de acordo com o DDS durante este estágio. Se o design for executado de maneira detalhada e organizada, a geração de código pode ser realizada sem muitos problemas.

Os desenvolvedores devem seguir as diretrizes de codificação definidas por sua organização e ferramentas de programação como compiladores, interpretadores, depuradores, etc. são usados ​​para gerar o código. Diferentes linguagens de programação de alto nível, como C, C ++, Pascal, Java e PHP são usadas para codificação. A linguagem de programação é escolhida de acordo com o tipo de software que está sendo desenvolvido.

Etapa 5: Testando o Produto

Este estágio é geralmente um subconjunto de todos os estágios, pois nos modelos SDLC modernos, as atividades de teste estão principalmente envolvidas em todos os estágios do SDLC. No entanto, esta etapa refere-se à única fase de teste do produto, onde os defeitos do produto são relatados, rastreados, corrigidos e retestados, até que o produto atinja os padrões de qualidade definidos no SRS.

Etapa 6: implantação no mercado e manutenção

Assim que o produto é testado e pronto para ser implantado, ele é lançado formalmente no mercado apropriado. Às vezes, a implantação do produto acontece em estágios de acordo com a estratégia de negócios dessa organização. O produto pode primeiro ser lançado em um segmento limitado e testado no ambiente real de negócios (UAT - Teste de aceitação do usuário).

Então, com base no feedback, o produto pode ser lançado como está ou com melhorias sugeridas no segmento de mercado-alvo. Após o lançamento do produto no mercado, é feita a manutenção da base de clientes existente.

Modelos SDLC

Existem vários modelos de ciclo de vida de desenvolvimento de software definidos e projetados que são seguidos durante o processo de desenvolvimento de software. Esses modelos também são chamados de Modelos de Processo de Desenvolvimento de Software ". Cada modelo de processo segue uma série de etapas exclusivas para seu tipo para garantir o sucesso no processo de desenvolvimento de software.

A seguir estão os modelos SDLC mais importantes e populares seguidos na indústria -

  • Modelo de Cachoeira
  • Modelo Iterativo
  • Modelo Espiral
  • V-Model
  • Modelo big bang

Outras metodologias relacionadas são o modelo Agile, o modelo RAD, o desenvolvimento rápido de aplicativos e os modelos de prototipagem.

O modelo em cascata foi o primeiro modelo de processo a ser introduzido. Também é conhecido comolinear-sequential life cycle model. É muito simples de entender e usar. Em um modelo em cascata, cada fase deve ser concluída antes que a próxima fase possa começar e não há sobreposição nas fases.

O modelo em cascata é a abordagem SDLC mais antiga que foi usada para desenvolvimento de software.

O modelo em cascata ilustra o processo de desenvolvimento de software em um fluxo sequencial linear. Isso significa que qualquer fase do processo de desenvolvimento começa apenas se a fase anterior for concluída. Neste modelo em cascata, as fases não se sobrepõem.

Modelo em cascata - Design

A abordagem em cascata foi o primeiro modelo SDLC a ser amplamente utilizado na Engenharia de Software para garantir o sucesso do projeto. Na abordagem "The Waterfall", todo o processo de desenvolvimento de software é dividido em fases distintas. Neste modelo em cascata, normalmente, o resultado de uma fase atua como entrada para a próxima fase sequencialmente.

A ilustração a seguir é uma representação das diferentes fases do modelo em cascata.

As fases sequenciais no modelo em cascata são -

  • Requirement Gathering and analysis - Todos os requisitos possíveis do sistema a ser desenvolvido são capturados nesta fase e documentados em um documento de especificação de requisitos.

  • System Design- As especificações de requisitos da primeira fase são estudadas nesta fase e o projeto do sistema é preparado. Este projeto de sistema ajuda a especificar requisitos de hardware e sistema e ajuda a definir a arquitetura geral do sistema.

  • Implementation- Com entradas do projeto do sistema, o sistema é primeiro desenvolvido em pequenos programas chamados unidades, que são integrados na próxima fase. Cada unidade é desenvolvida e testada quanto à sua funcionalidade, que é conhecida como Teste de Unidade.

  • Integration and Testing- Todas as unidades desenvolvidas na fase de implantação são integradas em um sistema após o teste de cada unidade. Após a integração, todo o sistema é testado para quaisquer falhas e falhas.

  • Deployment of system- Uma vez que o teste funcional e não funcional é feito; o produto é implantado no ambiente do cliente ou lançado no mercado.

  • Maintenance- Existem alguns problemas que surgem no ambiente do cliente. Para corrigir esses problemas, são lançados patches. Também para aprimorar o produto, algumas versões melhores são lançadas. A manutenção é feita para entregar essas mudanças no ambiente do cliente.

Todas essas fases são colocadas em cascata entre si, nas quais o progresso é visto como um fluxo constante para baixo (como uma cachoeira) através das fases. A próxima fase é iniciada somente após o conjunto de metas definido ser alcançado para a fase anterior e é homologado, daí o nome "Modelo em Cachoeira". Neste modelo, as fases não se sobrepõem.

Modelo em cascata - Aplicação

Cada software desenvolvido é diferente e requer uma abordagem SDLC adequada a ser seguida com base nos fatores internos e externos. Algumas situações em que o uso do modelo em cascata é mais adequado são -

  • Os requisitos são muito bem documentados, claros e fixos.

  • A definição do produto é estável.

  • A tecnologia é compreendida e não é dinâmica.

  • Não há requisitos ambíguos.

  • Amplos recursos com a experiência necessária estão disponíveis para dar suporte ao produto.

  • O projeto é curto.

Modelo em cascata - vantagens

As vantagens do desenvolvimento em cascata são que ele permite departamentalização e controle. Um cronograma pode ser definido com prazos para cada estágio de desenvolvimento e um produto pode prosseguir pelas fases do modelo de processo de desenvolvimento uma a uma.

O desenvolvimento vai desde o conceito, passando pelo design, implementação, teste, instalação, solução de problemas e termina na operação e manutenção. Cada fase de desenvolvimento ocorre em ordem estrita.

Algumas das principais vantagens do modelo em cascata são as seguintes -

  • Simples e fácil de entender e usar

  • Fácil de gerenciar devido à rigidez do modelo. Cada fase tem resultados específicos e um processo de revisão.

  • As fases são processadas e concluídas uma de cada vez.

  • Funciona bem para projetos menores onde os requisitos são muito bem compreendidos.

  • Estágios claramente definidos.

  • Marcos bem compreendidos.

  • Fácil de organizar as tarefas.

  • O processo e os resultados são bem documentados.

Modelo em cascata - Desvantagens

A desvantagem do desenvolvimento em cascata é que ele não permite muita reflexão ou revisão. Depois que um aplicativo está em estágio de teste, é muito difícil voltar e alterar algo que não foi bem documentado ou pensado no estágio de conceito.

As principais desvantagens do modelo em cascata são as seguintes -

  • Nenhum software funcional é produzido até o final do ciclo de vida.

  • Grandes quantidades de risco e incerteza.

  • Não é um bom modelo para projetos complexos e orientados a objetos.

  • Mau modelo para projetos longos e em andamento.

  • Não é adequado para projetos onde os requisitos têm um risco moderado a alto de alteração. Portanto, o risco e a incerteza são altos com este modelo de processo.

  • É difícil medir o progresso em estágios.

  • Não pode acomodar mudanças de requisitos.

  • Ajustar o escopo durante o ciclo de vida pode encerrar um projeto.

  • A integração é feita como um "big bang. No final, o que não permite identificar precocemente nenhum gargalo ou desafio tecnológico ou empresarial.

No modelo Iterativo, o processo iterativo começa com uma implementação simples de um pequeno conjunto de requisitos de software e aprimora iterativamente as versões em evolução até que o sistema completo seja implementado e esteja pronto para ser implantado.

Um modelo de ciclo de vida iterativo não tenta começar com uma especificação completa de requisitos. Em vez disso, o desenvolvimento começa especificando e implementando apenas parte do software, que é então revisado para identificar outros requisitos. Esse processo é então repetido, produzindo uma nova versão do software ao final de cada iteração do modelo.

Modelo Iterativo - Design

O processo iterativo começa com uma implementação simples de um subconjunto dos requisitos de software e aprimora iterativamente as versões em evolução até que o sistema completo seja implementado. A cada iteração, modificações de design são feitas e novos recursos funcionais são adicionados. A ideia básica por trás desse método é desenvolver um sistema por meio de ciclos repetidos (iterativos) e em porções menores de cada vez (incrementais).

A ilustração a seguir é uma representação do modelo Iterativo e Incremental -

O desenvolvimento iterativo e incremental é uma combinação de design iterativo ou método iterativo e modelo de construção incremental para desenvolvimento. "Durante o desenvolvimento de software, mais de uma iteração do ciclo de desenvolvimento de software pode estar em andamento ao mesmo tempo." Este processo pode ser descrito como uma abordagem de "aquisição evolutiva" ou "construção incremental". "

Nesse modelo incremental, todo o requisito é dividido em vários builds. Durante cada iteração, o módulo de desenvolvimento passa pelas fases de requisitos, design, implementação e teste. Cada versão subsequente do módulo adiciona função à versão anterior. O processo continua até que o sistema completo esteja pronto de acordo com o requisito.

A chave para o uso bem-sucedido de um ciclo de vida de desenvolvimento de software iterativo é a validação rigorosa dos requisitos e a verificação e teste de cada versão do software em relação a esses requisitos em cada ciclo do modelo. Conforme o software evolui por ciclos sucessivos, os testes devem ser repetidos e estendidos para verificar cada versão do software.

Modelo Iterativo - Aplicativo

Como outros modelos SDLC, o desenvolvimento iterativo e incremental tem algumas aplicações específicas na indústria de software. Este modelo é usado com mais frequência nos seguintes cenários -

  • Os requisitos do sistema completo são claramente definidos e compreendidos.

  • Os requisitos principais devem ser definidos; entretanto, algumas funcionalidades ou aprimoramentos solicitados podem evoluir com o tempo.

  • Há um tempo para a restrição do mercado.

  • Uma nova tecnologia está sendo usada e aprendida pela equipe de desenvolvimento enquanto trabalha no projeto.

  • Os recursos com os conjuntos de habilidades necessários não estão disponíveis e são planejados para serem usados ​​com base em contrato para iterações específicas.

  • Existem alguns recursos e metas de alto risco que podem mudar no futuro.

Modelo iterativo - prós e contras

A vantagem desse modelo é que existe um modelo funcional do sistema em um estágio muito inicial de desenvolvimento, o que torna mais fácil encontrar falhas funcionais ou de design. Encontrar problemas em um estágio inicial de desenvolvimento permite tomar medidas corretivas em um orçamento limitado.

A desvantagem desse modelo SDLC é que ele é aplicável apenas a projetos de desenvolvimento de software grandes e volumosos. Isso ocorre porque é difícil quebrar um pequeno sistema de software em outros pequenos incrementos / módulos que podem ser reparados.

As vantagens do Modelo SDLC Iterativo e Incremental são as seguintes -

  • Algumas funcionalidades de trabalho podem ser desenvolvidas rapidamente e no início do ciclo de vida.

  • Os resultados são obtidos antecipadamente e periodicamente.

  • O desenvolvimento paralelo pode ser planejado.

  • O progresso pode ser medido.

  • Menos dispendioso para alterar o escopo / requisitos.

  • Testar e depurar durante iterações menores é fácil.

  • Os riscos são identificados e resolvidos durante a iteração; e cada iteração é um marco facilmente gerenciado.

  • Mais fácil de gerenciar o risco - a parte de alto risco é feita primeiro.

  • A cada incremento, o produto operacional é entregue.

  • Problemas, desafios e riscos identificados de cada incremento podem ser utilizados / aplicados ao próximo incremento.

  • A análise de risco é melhor.

  • Suporta mudanças de requisitos.

  • O tempo de operação inicial é menor.

  • Mais adequado para projetos grandes e de missão crítica.

  • Durante o ciclo de vida, o software é produzido precocemente, o que facilita a avaliação e o feedback do cliente.

As desvantagens do Modelo SDLC Iterativo e Incremental são as seguintes -

  • Mais recursos podem ser necessários.

  • Embora o custo da mudança seja menor, não é muito adequado para mudanças de requisitos.

  • É necessária mais atenção da administração.

  • Podem surgir problemas de arquitetura ou design do sistema porque nem todos os requisitos são reunidos no início de todo o ciclo de vida.

  • A definição de incrementos pode exigir a definição do sistema completo.

  • Não é adequado para projetos menores.

  • A complexidade do gerenciamento é mais.

  • O fim do projeto pode não ser conhecido, o que é um risco.

  • Recursos altamente qualificados são necessários para a análise de risco.

  • O progresso dos projetos é altamente dependente da fase de análise de risco.

O modelo em espiral combina a ideia de desenvolvimento iterativo com os aspectos sistemáticos e controlados do modelo em cascata. Este modelo espiral é uma combinação de modelo de processo de desenvolvimento iterativo e modelo de desenvolvimento linear sequencial, ou seja, o modelo em cascata com grande ênfase na análise de risco. Ele permite lançamentos incrementais do produto ou refinamento incremental por meio de cada iteração em torno da espiral.

Modelo Espiral - Design

O modelo espiral tem quatro fases. Um projeto de software passa repetidamente por essas fases em iterações chamadas espirais.

Identificação

Esta fase começa reunindo os requisitos de negócios na espiral da linha de base. Nas espirais subsequentes, à medida que o produto amadurece, a identificação dos requisitos do sistema, requisitos do subsistema e requisitos da unidade são todos feitos nesta fase.

Esta fase também inclui a compreensão dos requisitos do sistema por meio da comunicação contínua entre o cliente e o analista de sistema. Ao final da espiral, o produto é implantado no mercado identificado.

Projeto

A fase de projeto começa com o projeto conceitual na espiral da linha de base e envolve o projeto arquitetônico, o projeto lógico dos módulos, o projeto físico do produto e o projeto final nas espirais subsequentes.

Construir ou construir

A fase de construção se refere à produção do produto de software real em cada espiral. Na espiral da linha de base, quando o produto é apenas pensado e o design está sendo desenvolvido, um POC (Prova de Conceito) é desenvolvido nesta fase para obter o feedback do cliente.

Em seguida, nas espirais subsequentes com maior clareza sobre os requisitos e detalhes de design, um modelo funcional do software chamado build é produzido com um número de versão. Essas compilações são enviadas ao cliente para feedback.

Avaliação e Análise de Risco

A Análise de Risco inclui a identificação, estimativa e monitoramento da viabilidade técnica e riscos de gerenciamento, como atrasos no cronograma e excesso de custos. Depois de testar a construção, no final da primeira iteração, o cliente avalia o software e fornece feedback.

A ilustração a seguir é uma representação do Modelo Espiral, listando as atividades em cada fase.

Com base na avaliação do cliente, o processo de desenvolvimento de software entra na próxima iteração e, posteriormente, segue a abordagem linear para implementar o feedback sugerido pelo cliente. O processo de iterações ao longo da espiral continua ao longo da vida do software.

Aplicação de modelo espiral

O Modelo Espiral é amplamente utilizado na indústria de software, pois está em sincronia com o processo natural de desenvolvimento de qualquer produto, ou seja, aprender com maturidade que envolve risco mínimo para o cliente e também para as empresas de desenvolvimento.

As dicas a seguir explicam os usos típicos de um modelo espiral -

  • Quando há uma restrição orçamentária e a avaliação de risco é importante.

  • Para projetos de médio a alto risco.

  • Compromisso de projeto de longo prazo devido a possíveis mudanças nas prioridades econômicas conforme os requisitos mudam com o tempo.

  • O cliente não tem certeza de seus requisitos, o que geralmente acontece.

  • Os requisitos são complexos e precisam de avaliação para obter clareza.

  • Nova linha de produtos que deve ser lançada em fases para obter feedback suficiente do cliente.

  • Esperam-se mudanças significativas no produto durante o ciclo de desenvolvimento.

Modelo espiral - prós e contras

A vantagem do modelo de ciclo de vida em espiral é que ele permite que elementos do produto sejam adicionados, quando se tornam disponíveis ou conhecidos. Isso garante que não haja conflito com os requisitos e projetos anteriores.

Este método é consistente com abordagens que possuem múltiplas compilações e liberações de software, o que permite fazer uma transição ordenada para uma atividade de manutenção. Outro aspecto positivo desse método é que o modelo em espiral força um envolvimento precoce do usuário no esforço de desenvolvimento do sistema.

Por outro lado, é preciso uma gestão muito rigorosa para concluir esses produtos e existe o risco de uma espiral indefinida. Portanto, a disciplina de mudança e o grau de aceitação das solicitações de mudança são muito importantes para desenvolver e implantar o produto com sucesso.

As vantagens do modelo Spiral SDLC são as seguintes -

  • Mudanças de requisitos podem ser acomodadas.

  • Permite o uso extensivo de protótipos.

  • Os requisitos podem ser capturados com mais precisão.

  • Os usuários veem o sistema cedo.

  • O desenvolvimento pode ser dividido em partes menores e as partes de risco podem ser desenvolvidas mais cedo, o que ajuda no melhor gerenciamento de risco.

As desvantagens do modelo Spiral SDLC são as seguintes -

  • A gestão é mais complexa.

  • O fim do projeto pode não ser conhecido no início.

  • Não é adequado para projetos pequenos ou de baixo risco e pode ser caro para projetos pequenos.

  • O processo é complexo

  • A espiral pode continuar indefinidamente.

  • Grande número de estágios intermediários requer documentação excessiva.

O modelo V é um modelo SDLC onde a execução dos processos ocorre de forma sequencial em forma de V. Também é conhecido comoVerification and Validation model.

O V-Model é uma extensão do modelo em cascata e é baseado na associação de uma fase de teste para cada estágio de desenvolvimento correspondente. Isso significa que, para cada fase do ciclo de desenvolvimento, há uma fase de teste diretamente associada. Este é um modelo altamente disciplinado e a próxima fase começa somente após a conclusão da fase anterior.

V-Model - Design

No V-Model, a fase de teste correspondente da fase de desenvolvimento é planejada em paralelo. Portanto, há fases de verificação em um lado do 'V' e fases de validação no outro lado. A fase de codificação une os dois lados do V-Model.

A ilustração a seguir descreve as diferentes fases em um modelo V do SDLC.

Modelo V - Fases de verificação

Existem várias fases de verificação no V-Model, cada uma delas é explicada em detalhes abaixo.

Análise de Requisitos de Negócios

Esta é a primeira fase do ciclo de desenvolvimento em que os requisitos do produto são entendidos da perspectiva do cliente. Esta fase envolve uma comunicação detalhada com o cliente para entender suas expectativas e requisitos exatos. Esta é uma atividade muito importante e precisa ser bem administrada, pois a maioria dos clientes não tem certeza do que exatamente precisa. oacceptance test design planning é feito neste estágio, pois os requisitos de negócios podem ser usados ​​como uma entrada para o teste de aceitação.

Projeto de sistema

Depois de ter os requisitos do produto claros e detalhados, é hora de projetar o sistema completo. O projeto do sistema terá a compreensão e detalhamento do hardware completo e configuração de comunicação para o produto em desenvolvimento. O plano de teste do sistema é desenvolvido com base no projeto do sistema. Fazer isso em um estágio anterior deixa mais tempo para a execução real do teste posteriormente.

Projeto arquitetônico

As especificações arquitetônicas são compreendidas e projetadas nesta fase. Normalmente, mais de uma abordagem técnica é proposta e com base na viabilidade técnica e financeira a decisão final é tomada. O design do sistema é subdividido em módulos que ocupam funções diferentes. Isso também é conhecido comoHigh Level Design (HLD).

A transferência de dados e a comunicação entre os módulos internos e com o mundo exterior (outros sistemas) é claramente entendida e definida nesta etapa. Com essas informações, os testes de integração podem ser projetados e documentados durante este estágio.

Projeto de Módulo

Nesta fase, o projeto interno detalhado para todos os módulos do sistema é especificado, referido como Low Level Design (LLD). É importante que o design seja compatível com os outros módulos da arquitetura do sistema e com os outros sistemas externos. Os testes de unidade são uma parte essencial de qualquer processo de desenvolvimento e ajudam a eliminar o máximo de falhas e erros em um estágio muito inicial. Esses testes de unidade podem ser projetados neste estágio com base nos designs dos módulos internos.

Fase de Codificação

A codificação real dos módulos do sistema projetados na fase de design é realizada na fase de codificação. A linguagem de programação mais adequada é decidida com base nos requisitos de sistema e arquitetura.

A codificação é realizada com base nas diretrizes e padrões de codificação. O código passa por várias revisões de código e é otimizado para melhor desempenho antes que a compilação final seja verificada no repositório.

Fases de Validação

As diferentes fases de validação em um modelo V são explicadas em detalhes abaixo.

Teste de Unidade

Os testes de unidade projetados na fase de design do módulo são executados no código durante esta fase de validação. O teste de unidade é o teste em nível de código e ajuda a eliminar bugs em um estágio inicial, embora todos os defeitos não possam ser descobertos pelo teste de unidade.

Teste de integração

O teste de integração está associado à fase de projeto arquitetônico. Os testes de integração são realizados para testar a coexistência e a comunicação dos módulos internos do sistema.

Teste de Sistema

O teste do sistema está diretamente associado à fase de design do sistema. Os testes de sistema verificam toda a funcionalidade do sistema e a comunicação do sistema em desenvolvimento com sistemas externos. A maioria dos problemas de compatibilidade de software e hardware podem ser descobertos durante a execução do teste do sistema.

Teste de aceitação

O teste de aceitação está associado à fase de análise de requisitos de negócios e envolve o teste do produto no ambiente do usuário. Os testes de aceitação revelam os problemas de compatibilidade com os outros sistemas disponíveis no ambiente do usuário. Ele também descobre os problemas não funcionais, como defeitos de carga e desempenho no ambiente real do usuário.

V- Modelo ─ Aplicação

A aplicação do modelo V é quase igual ao modelo em cascata, pois ambos os modelos são do tipo sequencial. Os requisitos devem ser muito claros antes do início do projeto, porque geralmente é caro voltar e fazer alterações. Este modelo é utilizado no campo do desenvolvimento médico, por ser um domínio estritamente disciplinado.

As dicas a seguir são alguns dos cenários mais adequados para usar o aplicativo V-Model.

  • Os requisitos são bem definidos, claramente documentados e fixos.

  • A definição do produto é estável.

  • A tecnologia não é dinâmica e é bem compreendida pela equipe do projeto.

  • Não há requisitos ambíguos ou indefinidos.

  • O projeto é curto.

V-Model - Prós e Contras

A vantagem do método V-Model é que ele é muito fácil de entender e aplicar. A simplicidade desse modelo também facilita o gerenciamento. A desvantagem é que o modelo não é flexível para mudanças e caso haja uma mudança de requisito, o que é muito comum no mundo dinâmico de hoje, torna-se muito caro fazer a mudança.

As vantagens do método V-Model são as seguintes -

  • Este é um modelo altamente disciplinado e as fases são concluídas uma de cada vez.

  • Funciona bem para projetos menores onde os requisitos são muito bem compreendidos.

  • Simples e fácil de entender e usar.

  • Fácil de gerenciar devido à rigidez do modelo. Cada fase tem resultados específicos e um processo de revisão.

As desvantagens do método V-Model são as seguintes -

  • Alto risco e incerteza.

  • Não é um bom modelo para projetos complexos e orientados a objetos.

  • Mau modelo para projetos longos e em andamento.

  • Não é adequado para projetos em que os requisitos apresentam um risco moderado a alto de alteração.

  • Quando um aplicativo está em estágio de teste, é difícil voltar e alterar uma funcionalidade.

  • Nenhum software funcional é produzido até o final do ciclo de vida.

O modelo Big Bang é um modelo SDLC onde não seguimos nenhum processo específico. O desenvolvimento apenas começa com o dinheiro e os esforços necessários como entrada, e a saída é o software desenvolvido, que pode ou não atender aos requisitos do cliente. Este modelo do Big Bang não segue um processo / procedimento e requer muito pouco planejamento. Mesmo o cliente não tem certeza sobre o que exatamente deseja e os requisitos são implementados imediatamente, sem muita análise.

Normalmente, esse modelo é seguido para pequenos projetos em que as equipes de desenvolvimento são muito pequenas.

Modelo Big Bang ─ Design e Aplicação

O Modelo Big Bang consiste em focar todos os recursos possíveis no desenvolvimento e codificação de software, com muito pouco ou nenhum planejamento. Os requisitos são compreendidos e implementados à medida que surgem. Quaisquer alterações necessárias podem ou não precisar renovar o software completo.

Este modelo é ideal para pequenos projetos com um ou dois desenvolvedores trabalhando juntos e também é útil para projetos acadêmicos ou práticos. É um modelo ideal para o produto onde os requisitos não são bem compreendidos e a data de lançamento final não é fornecida.

Modelo do Big Bang - Prós e Contras

A vantagem desse modelo do Big Bang é que ele é muito simples e requer muito pouco ou nenhum planejamento. Fácil de gerenciar e nenhum procedimento formal é necessário.

No entanto, o Modelo do Big Bang é um modelo de risco muito alto e mudanças nos requisitos ou requisitos mal-entendidos podem até mesmo levar à reversão completa ou ao fracasso do projeto. É ideal para projetos repetitivos ou pequenos com riscos mínimos.

As vantagens do modelo Big Bang são as seguintes -

  • Este é um modelo muito simples

  • Pouco ou nenhum planejamento necessário

  • Fácil de gerenciar

  • Muito poucos recursos necessários

  • Oferece flexibilidade aos desenvolvedores

  • É uma boa ajuda de aprendizagem para recém-chegados ou alunos.

As desvantagens do modelo Big Bang são as seguintes -

  • Risco muito alto e incerteza.

  • Não é um bom modelo para projetos complexos e orientados a objetos.

  • Mau modelo para projetos longos e em andamento.

  • Pode ser muito caro se os requisitos forem mal interpretados.

O modelo Agile SDLC é uma combinação de modelos de processo iterativos e incrementais com foco na adaptabilidade do processo e na satisfação do cliente pela entrega rápida do produto de software funcional. Os métodos ágeis dividem o produto em pequenas compilações incrementais. Essas compilações são fornecidas em iterações. Cada iteração normalmente dura cerca de uma a três semanas. Cada iteração envolve equipes multifuncionais trabalhando simultaneamente em várias áreas como -

  • Planning
  • Análise de Requisitos
  • Design
  • Coding
  • Teste de Unidade e
  • Teste de aceitação.

No final da iteração, um produto funcional é exibido para o cliente e os stakeholders importantes.

O que é Agile?

O modelo Agile acredita que cada projeto precisa ser tratado de maneira diferente e os métodos existentes precisam ser ajustados para melhor atender aos requisitos do projeto. No Agile, as tarefas são divididas em caixas de tempo (pequenos intervalos de tempo) para fornecer recursos específicos para um lançamento.

A abordagem iterativa é feita e a construção do software funcional é entregue após cada iteração. Cada construção é incremental em termos de recursos; a versão final contém todos os recursos exigidos pelo cliente.

Aqui está uma ilustração gráfica do modelo ágil -

O processo de pensamento Agile começou no início do desenvolvimento de software e começou a se tornar popular com o tempo devido à sua flexibilidade e adaptabilidade.

Os métodos Agile mais populares incluem Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development e Dynamic Systems Development Method (DSDM) (1995). Esses agora são chamados coletivamente deAgile Methodologies, depois que o Manifesto Ágil foi publicado em 2001.

A seguir estão os princípios do Manifesto Ágil -

  • Individuals and interactions - No desenvolvimento ágil, a auto-organização e a motivação são importantes, assim como as interações como colocalização e programação em pares.

  • Working software - O software de trabalho de demonstração é considerado o melhor meio de comunicação com os clientes para entender seus requisitos, ao invés de depender apenas de documentação.

  • Customer collaboration - Como os requisitos não podem ser reunidos completamente no início do projeto devido a vários fatores, a interação contínua com o cliente é muito importante para obter os requisitos adequados do produto.

  • Responding to change - O desenvolvimento ágil é focado em respostas rápidas para mudanças e desenvolvimento contínuo.

Modelos SDLC Agile vs. Tradicional

Agile é baseado no adaptive software development methods, enquanto os modelos SDLC tradicionais, como o modelo em cascata, são baseados em uma abordagem preditiva. As equipes preditivas nos modelos SDLC tradicionais geralmente trabalham com planejamento detalhado e têm uma previsão completa das tarefas e recursos exatos a serem entregues nos próximos meses ou durante o ciclo de vida do produto.

Os métodos preditivos dependem inteiramente do requirement analysis and planningfeito no início do ciclo. Quaisquer mudanças a serem incorporadas passam por um rígido controle de gestão e priorização de mudanças.

Agile usa um adaptive approachonde não há planejamento detalhado e há clareza sobre as tarefas futuras apenas no que diz respeito aos recursos que precisam ser desenvolvidos. Há um desenvolvimento orientado por recursos e a equipe se adapta aos requisitos de produto em constante mudança. O produto é testado com muita frequência, por meio de iterações de lançamento, minimizando o risco de quaisquer falhas importantes no futuro.

Customer Interactioné a espinha dorsal desta metodologia Ágil, e a comunicação aberta com documentação mínima são os recursos típicos do ambiente de desenvolvimento Ágil. As equipes ágeis trabalham em estreita colaboração umas com as outras e geralmente estão localizadas na mesma localização geográfica.

Modelo Agile - Prós e Contras

Métodos ágeis estão sendo amplamente aceitos no mundo do software recentemente. No entanto, esse método nem sempre é adequado para todos os produtos. Aqui estão alguns prós e contras do modelo Agile.

As vantagens do modelo ágil são as seguintes -

  • É uma abordagem muito realista para o desenvolvimento de software.

  • Promove o trabalho em equipe e o treinamento cruzado.

  • A funcionalidade pode ser desenvolvida e demonstrada rapidamente.

  • Os requisitos de recursos são mínimos.

  • Adequado para requisitos fixos ou variáveis

  • Oferece soluções iniciais de trabalho parciais.

  • Bom modelo para ambientes que mudam constantemente.

  • Regras mínimas, documentação facilmente empregada.

  • Permite o desenvolvimento e entrega simultâneos dentro de um contexto geral planejado.

  • Pouco ou nenhum planejamento necessário.

  • Fácil de gerenciar.

  • Oferece flexibilidade aos desenvolvedores.

As desvantagens do modelo ágil são as seguintes -

  • Não é adequado para lidar com dependências complexas.

  • Mais risco de sustentabilidade, facilidade de manutenção e extensibilidade.

  • Um plano geral, um líder ágil e uma prática de gerenciamento de projetos ágil são essenciais sem os quais não funcionará.

  • O gerenciamento de entrega estrito determina o escopo, a funcionalidade a ser entregue e os ajustes para cumprir os prazos.

  • Depende muito da interação com o cliente, portanto, se o cliente não for claro, a equipe pode ser conduzida na direção errada.

  • A dependência individual é muito alta, visto que há um mínimo de documentação gerada.

  • A transferência de tecnologia para novos membros da equipe pode ser bastante desafiadora devido à falta de documentação.

o RAD (Rapid Application Development)O modelo é baseado em prototipagem e desenvolvimento iterativo sem nenhum planejamento específico envolvido. O processo de escrever o software em si envolve o planejamento necessário para desenvolver o produto.

O Desenvolvimento Rápido de Aplicativos concentra-se em reunir os requisitos do cliente por meio de workshops ou grupos de foco, teste inicial dos protótipos pelo cliente usando conceito iterativo, reutilização dos protótipos (componentes) existentes, integração contínua e entrega rápida.

O que é RAD?

O desenvolvimento rápido de aplicativos é uma metodologia de desenvolvimento de software que usa planejamento mínimo em favor da prototipagem rápida. Um protótipo é um modelo funcional que é funcionalmente equivalente a um componente do produto.

No modelo RAD, os módulos funcionais são desenvolvidos em paralelo como protótipos e são integrados para fazer o produto completo para uma entrega mais rápida do produto. Como não há planejamento prévio detalhado, fica mais fácil incorporar as mudanças no processo de desenvolvimento.

Os projetos RAD seguem um modelo iterativo e incremental e têm pequenas equipes compostas por desenvolvedores, especialistas de domínio, representantes de clientes e outros recursos de TI trabalhando progressivamente em seu componente ou protótipo.

O aspecto mais importante para o sucesso desse modelo é garantir que os protótipos desenvolvidos sejam reutilizáveis.

Design de modelo RAD

O modelo RAD distribui as fases de análise, projeto, construção e teste em uma série de ciclos de desenvolvimento curtos e iterativos.

A seguir estão as várias fases do Modelo RAD -

Modelagem de Negócios

O modelo de negócios para o produto em desenvolvimento é desenhado em termos de fluxo de informações e distribuição de informações entre os diversos canais de negócios. Uma análise de negócios completa é realizada para encontrar as informações vitais para os negócios, como podem ser obtidas, como e quando as informações são processadas e quais são os fatores que impulsionam o fluxo de informações bem-sucedido.

Modelagem de Dados

As informações coletadas na fase de Modelagem de Negócios são revisadas e analisadas para formar conjuntos de objetos de dados vitais para os negócios. Os atributos de todos os conjuntos de dados são identificados e definidos. A relação entre esses objetos de dados é estabelecida e definida em detalhes de acordo com a relevância para o modelo de negócios.

Modelagem de Processo

Os conjuntos de objetos de dados definidos na fase de Modelagem de Dados são convertidos para estabelecer o fluxo de informações de negócios necessário para atingir objetivos de negócios específicos de acordo com o modelo de negócios. O modelo de processo para quaisquer alterações ou aprimoramentos nos conjuntos de objetos de dados é definido nesta fase. São fornecidas descrições de processos para adicionar, excluir, recuperar ou modificar um objeto de dados.

Geração de aplicativos

O sistema real é construído e a codificação é feita usando ferramentas de automação para converter modelos de processo e dados em protótipos reais.

Teste e Rotatividade

O tempo geral de teste é reduzido no modelo RAD, pois os protótipos são testados de forma independente durante cada iteração. No entanto, o fluxo de dados e as interfaces entre todos os componentes precisam ser testados exaustivamente com cobertura de teste completa. Uma vez que a maioria dos componentes de programação já foi testada, isso reduz o risco de quaisquer problemas graves.

A ilustração a seguir descreve o modelo RAD em detalhes.

RAD Modelo Vs SDLC Tradicional

O SDLC tradicional segue modelos de processo rígidos com alta ênfase na análise e coleta de requisitos antes do início da codificação. Isso pressiona o cliente a aprovar os requisitos antes do início do projeto, e o cliente não consegue sentir o produto porque não há uma versão funcional disponível por um longo tempo.

O cliente pode precisar de algumas alterações depois de ver o software. No entanto, o processo de mudança é bastante rígido e pode não ser viável incorporar grandes mudanças no produto no SDLC tradicional.

O modelo RAD se concentra na entrega iterativa e incremental de modelos de trabalho para o cliente. Isso resulta em entrega rápida ao cliente e envolvimento do cliente durante o ciclo completo de desenvolvimento do produto, reduzindo o risco de não conformidade com os requisitos reais do usuário.

Modelo RAD - Aplicação

O modelo RAD pode ser aplicado com sucesso aos projetos nos quais a modularização clara é possível. Se o projeto não puder ser dividido em módulos, o RAD pode falhar.

As dicas a seguir descrevem os cenários típicos onde RAD pode ser usado -

  • O RAD deve ser usado apenas quando um sistema puder ser modularizado para ser entregue de maneira incremental.

  • Deve ser usado se houver alta disponibilidade de designers para modelagem.

  • Deve ser usado apenas se o orçamento permitir o uso de ferramentas automatizadas de geração de código.

  • O modelo RAD SDLC deve ser escolhido apenas se especialistas de domínio estiverem disponíveis com conhecimento de negócios relevante.

  • Deve ser usado quando os requisitos mudam durante o projeto e os protótipos de trabalho devem ser apresentados ao cliente em pequenas iterações de 2-3 meses.

Modelo RAD - Prós e Contras

O modelo RAD permite uma entrega rápida, pois reduz o tempo geral de desenvolvimento devido à reutilização dos componentes e ao desenvolvimento paralelo. O RAD funciona bem apenas se engenheiros altamente qualificados estiverem disponíveis e o cliente também estiver comprometido em atingir o protótipo pretendido no prazo determinado. Se houver falta de comprometimento de qualquer um dos lados, o modelo pode falhar.

As vantagens do modelo RAD são as seguintes -

  • Mudanças de requisitos podem ser acomodadas.

  • O progresso pode ser medido.

  • O tempo de iteração pode ser curto com o uso de poderosas ferramentas RAD.

  • Produtividade com menos pessoas em um curto espaço de tempo.

  • Tempo de desenvolvimento reduzido.

  • Aumenta a reutilização de componentes.

  • Ocorrem revisões iniciais rápidas.

  • Incentiva o feedback do cliente.

  • A integração desde o início resolve muitos problemas de integração.

As desvantagens do modelo RAD são as seguintes -

  • Dependência de membros da equipe tecnicamente fortes para identificar os requisitos de negócios.

  • Apenas o sistema que pode ser modularizado pode ser construído usando RAD.

  • Requer desenvolvedores / designers altamente qualificados.

  • Alta dependência de habilidades de modelagem.

  • Inaplicável a projetos mais baratos, pois o custo de modelagem e geração automatizada de código é muito alto.

  • A complexidade do gerenciamento é mais.

  • Adequado para sistemas que são baseados em componentes e escalonáveis.

  • Requer o envolvimento do usuário em todo o ciclo de vida.

  • Adequado para projetos que requerem tempos de desenvolvimento mais curtos.

A Prototipagem de Software se refere à construção de protótipos de aplicativos de software que exibem a funcionalidade do produto em desenvolvimento, mas podem não conter a lógica exata do software original.

A prototipagem de software está se tornando muito popular como um modelo de desenvolvimento de software, pois permite entender os requisitos do cliente em um estágio inicial de desenvolvimento. Ajuda a obter feedback valioso do cliente e ajuda os designers e desenvolvedores de software a entender o que exatamente se espera do produto em desenvolvimento.

O que é prototipagem de software?

Prototype é um modelo funcional de software com algumas funcionalidades limitadas. O protótipo nem sempre mantém a lógica exata usada no aplicativo de software real e é um esforço extra a ser considerado na estimativa de esforço.

A prototipagem é usada para permitir que os usuários avaliem as propostas do desenvolvedor e as experimente antes da implementação. Também ajuda a entender os requisitos que são específicos do usuário e podem não ter sido considerados pelo desenvolvedor durante o design do produto.

A seguir está uma abordagem passo a passo explicada para projetar um protótipo de software.

Identificação de Requisito Básico

Esta etapa envolve a compreensão dos requisitos básicos do produto, especialmente em termos de interface do usuário. Os detalhes mais intrincados do design interno e aspectos externos, como desempenho e segurança, podem ser ignorados nesta fase.

Desenvolvendo o protótipo inicial

O protótipo inicial é desenvolvido nesta fase, onde os requisitos básicos são apresentados e as interfaces de usuário são fornecidas. Esses recursos podem não funcionar exatamente da mesma maneira internamente no software desenvolvido. Enquanto, as soluções alternativas são usadas para dar a mesma aparência ao cliente no protótipo desenvolvido.

Revisão do protótipo

O protótipo desenvolvido é então apresentado ao cliente e aos demais stakeholders importantes do projeto. O feedback é coletado de maneira organizada e usado para melhorias adicionais no produto em desenvolvimento.

Revise e aprimore o protótipo

O feedback e os comentários da revisão são discutidos durante esta fase e algumas negociações acontecem com o cliente com base em fatores como - restrições de tempo e orçamento e viabilidade técnica da implementação real. As alterações aceitas são novamente incorporadas ao novo Protótipo desenvolvido e o ciclo se repete até que as expectativas do cliente sejam atendidas.

Os protótipos podem ter dimensões horizontais ou verticais. Um protótipo horizontal exibe a interface do usuário do produto e oferece uma visão mais ampla de todo o sistema, sem se concentrar nas funções internas. Um protótipo vertical do outro lado é uma elaboração detalhada de uma função específica ou um subsistema no produto.

O objetivo do protótipo horizontal e vertical é diferente. Os protótipos horizontais são usados ​​para obter mais informações sobre o nível da interface do usuário e os requisitos de negócios. Pode até ser apresentado nas demonstrações de vendas para obter negócios no mercado. Os protótipos verticais são de natureza técnica e são usados ​​para obter detalhes do funcionamento exato dos subsistemas. Por exemplo, requisitos de banco de dados, cargas de interação e processamento de dados em um determinado subsistema.

Prototipagem de Software - Tipos

Existem diferentes tipos de protótipos de software usados ​​na indústria. A seguir estão os principais tipos de prototipagem de software amplamente usados ​​-

Descartável / Prototipagem Rápida

A prototipagem descartável também é chamada de prototipagem rápida ou fechada. Este tipo de prototipagem usa poucos esforços com análise de requisitos mínimos para construir um protótipo. Uma vez que os requisitos reais são compreendidos, o protótipo é descartado e o sistema real é desenvolvido com uma compreensão muito clara dos requisitos do usuário.

Prototipagem Evolutiva

A prototipagem evolutiva, também chamada de prototipagem de breadboard, é baseada na construção de protótipos funcionais reais com funcionalidade mínima no início. O protótipo desenvolvido constitui o coração dos futuros protótipos sobre os quais todo o sistema é construído. Usando a prototipagem evolutiva, os requisitos bem compreendidos são incluídos no protótipo e os requisitos são adicionados como e quando eles são compreendidos.

Prototipagem Incremental

A prototipagem incremental refere-se à construção de vários protótipos funcionais dos vários subsistemas e, em seguida, integrar todos os protótipos disponíveis para formar um sistema completo.

Prototipagem Extrema

A prototipagem extrema é usada no domínio do desenvolvimento web. Consiste em três fases sequenciais. Primeiro, um protótipo básico com todas as páginas existentes é apresentado no formato HTML. Em seguida, o processamento de dados é simulado usando uma camada de serviços de protótipo. Por fim, os serviços são implementados e integrados ao protótipo final. Este processo é chamado de Prototipagem Extrema, usado para chamar a atenção para a segunda fase do processo, onde uma IU totalmente funcional é desenvolvida com muito pouca consideração pelos serviços reais.

Prototipagem de Software - Aplicativo

A prototipagem de software é mais útil no desenvolvimento de sistemas com alto nível de interação com o usuário, como sistemas online. Os sistemas que precisam que os usuários preencham formulários ou percorram várias telas antes de os dados serem processados ​​podem usar a prototipagem de forma muito eficaz para dar a aparência exata antes mesmo de o software real ser desenvolvido.

O software que envolve muito processamento de dados e a maior parte da funcionalidade é interna com muito pouca interface de usuário geralmente não se beneficia da prototipagem. O desenvolvimento do protótipo pode ser uma sobrecarga extra em tais projetos e pode exigir muitos esforços extras.

Prototipagem de software - prós e contras

A prototipagem de software é usada em casos típicos e a decisão deve ser tomada com muito cuidado para que os esforços despendidos na construção do protótipo agreguem um valor considerável ao software final desenvolvido. O modelo tem seus prós e contras discutidos a seguir.

As vantagens do modelo de prototipagem são as seguintes -

  • Aumento do envolvimento do usuário no produto antes mesmo de sua implementação.

  • Como um modelo funcional do sistema é exibido, os usuários obtêm uma melhor compreensão do sistema que está sendo desenvolvido.

  • Reduz tempo e custo, pois os defeitos podem ser detectados muito mais cedo.

  • Um feedback mais rápido do usuário está disponível, levando a melhores soluções.

  • Funcionalidade ausente pode ser identificada facilmente.

  • Funções confusas ou difíceis podem ser identificadas.

As desvantagens do modelo de prototipagem são as seguintes -

  • Risco de análise de requisitos insuficiente devido à dependência excessiva do protótipo.

  • Os usuários podem ficar confusos com os protótipos e os sistemas reais.

  • Praticamente, essa metodologia pode aumentar a complexidade do sistema, pois o escopo do sistema pode se expandir além dos planos originais.

  • Os desenvolvedores podem tentar reutilizar os protótipos existentes para construir o sistema real, mesmo quando isso não for tecnicamente viável.

  • O esforço investido na construção de protótipos pode ser muito grande se não for monitorado adequadamente.