Traduzido do Inglês para o Português - [Link].

com

Por que aprender SDLC?

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 visa produzir um software de alta
qualidade que atenda ou supere as expectativas do cliente, alcance a conclusão dentro dos prazos e
estimativas de custo.

SDLC é um processo seguido para 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.

 SDLC é a sigla de Ciclo de Vida de Desenvolvimento de Software.

 Também é chamado de Processo de Desenvolvimento de Software.
 SDLC é uma estrutura que define as 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.

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 de 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 Cascata
 Modelo Iterativo
 Modelo espiral
 Modelo V
 Modelo Big Bang

Outras metodologias relacionadas são Modelo Ágil, Modelo RAD, Desenvolvimento Rápido de Aplicativos
e Modelos de Prototipagem.
SDLC - Visão geral

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 visa produzir um software de alta
qualidade que atenda ou supere as expectativas do cliente, alcance a conclusão dentro dos prazos e
estimativas de custo.

 SDLC é a sigla de Ciclo de Vida de Desenvolvimento de Software.

 Também é chamado de Processo de Desenvolvimento de Software.
 SDLC é uma estrutura que define as 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 para 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 nos seguintes estágios -

Etapa 1: Planejamento e Análise de Requisitos

A análise de requisitos é a etapa mais importante e fundamental no SDLC. É realizado pelos membros
seniores da equipe com insumos do cliente, do departamento de vendas, pesquisas de mercado e
especialistas do setor. Essas informações são então utilizadas para planejar a abordagem do projeto básico e
realizar 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.

Estágio 2: Definindo Requisitos

Uma vez que a análise de requisitos é feita, o próximo passo é definir e documentar claramente os requisitos
do produto e obtê-los aprovados pelo cliente ou pelos analistas de mercado. Isso é feito por meio de um
documento SRS (Software Requirement Specification) que consiste em todos os requisitos do produto a
serem projetados e desenvolvidos durante o ciclo de vida do projeto.

Estágio 3: Projetando a Arquitetura do Produto

O SRS é a referência para que arquitetos de produtos apresentem a melhor arquitetura para o produto a ser
desenvolvido. Com base nos requisitos especificados na SRS, geralmente mais de uma abordagem de
projeto 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 do projeto, restrições de orçamento e tempo, a melhor
abordagem de projeto é 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 de 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 os mínimos
detalhes no DDS.

Estágio 4: Construindo ou Desenvolvendo o Produto

Nesta fase do SDLC o desenvolvimento real começa e o produto é construído. O código de programação é
gerado conforme DDS durante esta etapa. Se o projeto for realizado de forma detalhada e organizada, a
geração de código pode ser realizada sem muita complicação.

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 usadas 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 em relação ao 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 modernos de SDLC, as
atividades de teste estão principalmente envolvidas em todos os estágios do SDLC. No entanto, esta etapa
refere-se apenas à etapa 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 na SRS.

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

Uma vez que o produto esteja testado e pronto para ser implantado, ele é lançado formalmente no mercado
apropriado. Às vezes, a implantação do produto acontece em etapas de acordo com a estratégia de negócios
dessa organização. O produto pode ser lançado primeiro em um segmento limitado e testado no ambiente
real de negócios (UAT-User accept testing).

Em seguida, 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 sua manutenção para a 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 de 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 Cascata
 Modelo Iterativo
 Modelo espiral
 Modelo V
 Modelo Big Bang

Outras metodologias relacionadas são Modelo Ágil, Modelo RAD, Desenvolvimento Rápido de Aplicativos
e Modelos de Prototipagem.
SDLC - Modelo em Cascata

O Modelo Cascata foi o primeiro Modelo de Processo a ser introduzido. Também é referido como um
modelo de ciclo de vida linear-sequencial. É 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 Waterfall é a primeira abordagem SDLC 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 estiver
concluída. Neste modelo em cascata, as fases não se sobrepõem.

Modelo Cascata - Projeto

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 separadas. Neste modelo Waterfall, 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 Waterfall são:

 Levantamento e análise de requisitos: 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.
 Projeto de sistema: Nesta fase são estudadas as especificações de requisitos da primeira fase e
elaborado o projeto do sistema. Esse design de sistema ajuda a especificar os requisitos de hardware
e sistema e ajuda a definir a arquitetura geral do sistema.
 Implementação: Com insumos do projeto do sistema, o sistema é desenvolvido primeiramente em
pequenos programas chamados unidades, que são integrados na próxima fase. Cada unidade é
desenvolvida e testada quanto à sua funcionalidade, o que é conhecido como Unit Testing.
  Integração e Teste− 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 quanto a falhas e
falhas.
 Implantação do sistema− Uma vez realizados os testes funcionais e não funcionais; o produto é
implantado no ambiente do cliente ou lançado no mercado.
 Manutenção− Existem alguns problemas que surgem no ambiente do cliente. Para corrigir esses
problemas, os patches são lançados. 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 estão 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 para a fase anterior ser alcançado e ela é assinada, por isso o nome “Modelo Cascata”. Neste
modelo, as fases não se sobrepõem.

Modelo Cascata – Aplicação

Cada software desenvolvido é diferente e requer uma abordagem SDLC adequada a ser seguida com base
em fatores internos e externos. Algumas situações em que o uso do modelo Waterfall é 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 o conhecimento necessário estão disponíveis para dar suporte ao produto.
 O projeto é curto.

Modelo Cascata – Vantagens

As vantagens do desenvolvimento em cascata são que ele permite a departamentalização e o controle. Um

cronograma pode ser definido com prazos para cada estágio de desenvolvimento e um produto pode passar
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 do desenvolvimento prossegue 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 manusear devido à rigidez do modelo. Cada fase tem entregas específicas 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.
 Fases claramente definidas.
 Marcos bem compreendidos.
 Fácil de organizar tarefas.
 Processo e resultados são bem documentados.

Modelo Cascata – Desvantagens

A desvantagem do desenvolvimento em cascata é que ele não permite muita reflexão ou revisão. Uma vez
que um aplicativo está no 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é tarde durante o ciclo de vida.
 Grandes quantidades de risco e incerteza.
 Não é um bom modelo para projetos complexos e orientados a objetos.
 Modelo ruim para projetos longos e contínuos.
 Não é adequado para projetos em que os requisitos apresentam risco moderado a alto de mudança.
Portanto, o risco e a incerteza são altos com esse modelo de processo.
 É difícil medir o progresso em etapas.
 Não pode acomodar requisitos em mudança.
 Ajustar o escopo durante o ciclo de vida pode encerrar um projeto.
 A integração é feita como um “big-bang bem no final, o que não permite identificar antecipadamente
nenhum gargalo ou desafios tecnológicos ou de negócios.
SDLC - Modelo Iterativo

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
esteja implementado e pronto para ser implantado.

Um modelo de ciclo de vida iterativo não tenta começar com uma especificação completa dos requisitos. Em
vez disso, o desenvolvimento começa especificando e implementando apenas parte do software, que é então
revisado para identificar outros requisitos. Este 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, são feitas modificações de design 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 (iterativo) e em porções menores
de cada vez (incremental).

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.” Esse
processo pode ser descrito como uma abordagem de “aquisição evolutiva” ou “construção incremental”.

Neste modelo incremental, todo o requisito é dividido em várias compilações. 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ções à 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. À medida que o software evolui através de ciclos sucessivos, os testes
devem ser repetidos e estendidos para verificar cada versão do software.

Modelo Iterativo - Aplicação

Assim como outros modelos SDLC, o desenvolvimento iterativo e incremental tem algumas aplicações
específicas na indústria de software. Este modelo é mais frequentemente usado nos seguintes cenários -
  Os requisitos do sistema completo são claramente definidos e compreendidos.
 Os requisitos principais devem ser definidos; no entanto, algumas funcionalidades ou melhorias
solicitadas podem evoluir com o tempo.
 Há um tempo para a restrição do mercado.
 Uma nova tecnologia está sendo usada e está sendo 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 estão planejados
para serem usados por contrato para iterações específicas.
 Existem alguns recursos e objetivos de alto risco que podem mudar no futuro.

Modelo Iterativo – Prós e Contras

A vantagem deste modelo é que existe um modelo de funcionamento do sistema em um estágio muito inicial
de desenvolvimento, o que facilita 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 úteis.

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 precocemente e periodicamente.
 O desenvolvimento paralelo pode ser planejado.
 O progresso pode ser medido.
 Menos custoso 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 em cada incremento podem ser utilizados/aplicados ao
próximo incremento.
 A análise de risco é melhor.
 Ele suporta a mudança 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 antecipadamente, 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, mas não é muito adequado para mudar os requisitos.
 É necessária mais atenção da gestão.
 Problemas de arquitetura ou design do sistema podem surgir 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 da gestão é maior.
 O fim do projeto pode não ser conhecido, o que é um risco.
 São necessários recursos altamente qualificados para a análise de risco.
 O progresso dos projetos é altamente dependente da fase de análise de risco.
SDLC - Modelo Espiral

O modelo espiral combina a ideia de desenvolvimento iterativo com os aspectos sistemáticos e controlados
do modelo 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 uma ênfase
muito alta na análise de risco. Ele permite lançamentos incrementais do produto ou refinamento incremental
por meio de cada iteração ao redor da espiral.

Modelo Espiral - Projeto

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 com a coleta dos 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 feitos nesta fase.

Essa fase também inclui o entendimento dos requisitos do sistema por meio da comunicação contínua entre
o cliente e o analista do sistema. No 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 refere-se à 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, uma POC (Prova de
Conceito) é desenvolvida nesta fase para obter feedback do cliente.

Então, nas espirais subsequentes, com maior clareza sobre os requisitos e detalhes do projeto, um modelo de
trabalho 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 identificar, estimar e monitorar a viabilidade técnica e os riscos de gerenciamento,
como atrasos no cronograma e excesso de custos. Após testar a compilaçã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 Modelo Espiral

O Modelo Espiral é amplamente utilizado na indústria de software por estar em sincronia com o processo
natural de desenvolvimento de qualquer produto, ou seja, aprendizado com maturidade que envolve risco
mínimo tanto para o cliente quanto para as empresas de desenvolvimento.

Os ponteiros 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 longo prazo com o projeto devido a possíveis mudanças nas prioridades
econômicas à medida que os requisitos mudam com o tempo.
 O cliente não tem certeza de seus requisitos, o que geralmente é o caso.
 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.
 Mudanças significativas são esperadas 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 design anteriores.
Esse método é consistente com abordagens que possuem várias compilações e versões de software, o que
permite fazer uma transição ordenada para uma atividade de manutenção. Outro aspecto positivo deste
método é que o modelo 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 completar tais produtos e corre-se o risco de rodar
a espiral em um loop indefinido. Portanto, a disciplina da mudança e a extensão de receber solicitações de
mudança são muito importantes para desenvolver e implantar o produto com sucesso.

As vantagens do modelo espiral SDLC são as seguintes −

 A mudança de requisitos pode ser acomodada.

 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 arriscadas podem ser
desenvolvidas mais cedo, o que ajuda na melhor gestão de riscos.

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

 A gestão é mais complexa.

 O fim do projeto pode não ser conhecido antecipadamente.
 Não é adequado para projetos pequenos ou de baixo risco e pode ser caro para projetos pequenos.
 Processo é complexo
 Espiral pode continuar indefinidamente.
 Grande número de estágios intermediários requer documentação excessiva.
SDLC - Modelo V

O modelo V é um modelo SDLC onde a execução dos processos acontece de forma sequencial em forma de
V. Também é conhecido como modelo de Verificação e Validação.

O V-Model é uma extensão do modelo cascata e baseia-se na associação de uma fase de teste para cada fase
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.

Modelo V - Projeto

Sob o V-Model, a fase de teste correspondente da fase de desenvolvimento é planejada em paralelo.

Portanto, há fases de Verificação de um lado do 'V' e fases de Validação do 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 V-Model do SDLC.

V-Model - 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 gerenciada, pois a
maioria dos clientes não tem certeza do que exatamente eles precisam. O planejamento do projeto de teste de
aceitação é feito neste estágio, pois os requisitos de negócios podem ser usados como 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á o entendimento e detalhamento da configuração completa de hardware e 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 do teste real mais tarde.

Projeto arquitetônico

As especificações arquitetônicas são compreendidas e projetadas nesta fase. Geralmente 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 é dividido em módulos que ocupam diferentes funcionalidades. Isso também é conhecido
como High Level Design (HLD).

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

Projeto do Módulo

Nesta fase, é especificado o projeto interno detalhado de todos os módulos do sistema, denominado Low
Level Design (LLD). É importante que o projeto seja compatível com os demais módulos da arquitetura do
sistema e com os demais sistemas externos. Os testes unitários 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 nesta fase com base nos projetos dos módulos internos.

Fase de codificação

A codificação real dos módulos do sistema projetados na fase de projeto é retomada na fase de codificação.
A melhor linguagem de programação adequada é decidida com base no sistema e nos requisitos de
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 registrada no
repositório.

Fases de validação

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

Teste de unidade

Os testes de unidade projetados na fase de projeto do módulo são executados no código durante esta fase de
validação. O teste de unidade é o teste no nível do 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 de arquitetura. Os testes de integração são realizados
para testar a coexistência e comunicação dos módulos internos dentro do sistema.
Teste do sistema

O teste do sistema está diretamente associado à fase de projeto do sistema. Os testes do 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 pode ser descoberta 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 V-Model é quase igual ao modelo cascata, pois ambos os modelos são do tipo sequencial. Os
requisitos precisam estar muito claros antes do início do projeto, porque geralmente é caro voltar e fazer
alterações. Este modelo é usado no campo do desenvolvimento médico, pois é um domínio estritamente
disciplinado.

Os ponteiros 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 fixados.

 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 é 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 a 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 manusear devido à rigidez do modelo. Cada fase tem entregas específicas 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.
 Modelo ruim para projetos longos e contínuos.
 Não é adequado para projetos em que os requisitos apresentam risco moderado a alto de mudança.
 Uma vez que um aplicativo está no estágio de teste, é difícil voltar e alterar uma funcionalidade.
 Nenhum software funcional é produzido até tarde durante o ciclo de vida.
SDLC - Modelo Big Bang

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 estar de acordo com os 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 ele quer e os requisitos são implementados em tempo real sem muita análise.

Normalmente este modelo é seguido para pequenos projetos onde as equipes de desenvolvimento são muito
pequenas.

Modelo Big Bang ─ Design e Aplicação

O Modelo do 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 final de lançamento não é fornecida.

Modelo Big Bang – Prós e Contras

A vantagem deste 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
incompreendidos podem até levar à reversão completa ou à eliminação 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
 Poucos recursos necessários
 Dá flexibilidade aos desenvolvedores
 É uma boa ajuda de aprendizagem para recém-chegados ou estudantes.

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

 Risco e incerteza muito altos.

 Não é um bom modelo para projetos complexos e orientados a objetos.
 Modelo ruim para projetos longos e contínuos.
 Pode ser muito caro se os requisitos forem mal compreendidos.
SDLC - Modelo Ágil

O modelo Agile SDLC é uma combinação de modelos de processos iterativos e incrementais com foco na
adaptabilidade do processo e na satisfação do cliente pela entrega rápida do produto de software em
funcionamento. 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 −

 Planejamento
 Análise de Requisitos
 Projeto
 Codificação
 Testes Unitários e
 Teste de aceitação.

No final da iteração, um produto de trabalho é exibido para o cliente e partes interessadas importantes.

O que é Ágil?

O modelo ágil acredita que cada projeto precisa ser tratado de forma diferente e os métodos existentes
precisam ser adaptados para melhor atender aos requisitos do projeto. No Agile, as tarefas são divididas em
caixas de tempo (pequenos prazos) para entregar recursos específicos para uma versão.

A abordagem iterativa é adotada e a construção do software de trabalho é entregue após cada iteração. Cada
compilaçã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 ágil começou cedo no desenvolvimento de software e começou a se tornar
popular com o tempo devido à sua flexibilidade e adaptabilidade.

Os métodos ágeis 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). Estes são agora coletivamente referidos como Metodologias
Ágeis, depois que o Manifesto Ágil foi publicado em 2001.

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

 Indivíduos e interações− No desenvolvimento ágil, auto-organização e motivação são importantes,

assim como interações como co-location e programação em pares.
 Software funcionando− O software de trabalho de demonstração é considerado o melhor meio de
comunicação com os clientes para entender seus requisitos, em vez de depender apenas da
documentação.
 Colaboração do cliente− Como os requisitos não podem ser coletados 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.
 Respondendo à mudança− Desenvolvimento Ágil é focado em respostas rápidas a mudanças e
desenvolvimento contínuo.

Modelos SDLC ágeis vs tradicionais

O Agile é baseado nos métodos de desenvolvimento de software adaptativos, 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 da análise de requisitos e planejamento feito no início do

ciclo. Quaisquer mudanças a serem incorporadas passam por um rigoroso gerenciamento de controle de
mudanças e priorização.

O Agile usa uma abordagem adaptativa onde não há planejamento detalhado e há clareza nas tarefas futuras
apenas em relação a quais recursos precisam ser desenvolvidos. Há desenvolvimento orientado a recursos e
a equipe se adapta dinamicamente às mudanças nos requisitos do produto. O produto é testado com muita
frequência, por meio das iterações de lançamento, minimizando o risco de falhas maiores no futuro.

Interação com o clienteé a espinha dorsal desta metodologia Agile, e comunicação aberta com
documentação mínima são as características típicas do ambiente de desenvolvimento Agile. As equipes
ágeis trabalham em estreita colaboração umas com as outras e geralmente estão localizadas na mesma
localização geográfica.

Modelo Ágil – Prós e Contras

Os métodos ágeis estão sendo amplamente aceitos no mundo do software recentemente. No entanto, este
método pode nem sempre ser 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 rapidamente e demonstrada.
 Os requisitos de recursos são mínimos.
  Adequado para requisitos fixos ou em mudança
 Oferece soluções de trabalho parciais iniciais.
 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 planejado geral.
 Pouco ou nenhum planejamento necessário.
 Fácil de gerenciar.
 Dá 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, manutenibilidade e extensibilidade.
 Um plano geral, um líder ágil e uma prática ágil de PM são essenciais, sem os quais não funcionará.
 O gerenciamento rigoroso da entrega dita 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
direcionada na direção errada.
 Há uma dependência individual muito alta, pois há uma documentação mínima gerada.
 A transferência de tecnologia para novos membros da equipe pode ser bastante desafiadora devido à
falta de documentação.
SDLC - Modelo RAD

O modelo RAD (Rapid Application Development) é 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 o desenvolvimento do produto.

O Desenvolvimento Rápido de Aplicativos concentra-se em reunir os requisitos do cliente por meio de

workshops ou grupos focais, testes iniciais dos protótipos pelo cliente usando conceito iterativo, reutilização
dos protótipos existentes (componentes), 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 o

mínimo de planejamento 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 tornar o produto completo para uma entrega mais rápida do produto. Como não há um 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 possuem 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 deste modelo é garantir que os protótipos desenvolvidos sejam
reutilizáveis.

Projeto 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 interativos.

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

Modelagem de Negócios

O modelo de negócio para o produto em desenvolvimento é desenhado em termos de fluxo de informação e

distribuição de informação entre vários canais de negócio. Uma análise completa do negócio é realizada para
encontrar as informações vitais para o negócio, como elas 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 com sucesso.

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 do modelo de negócios.

Modelagem de Processos

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
processos e modelos de dados em protótipos reais.

Testes e Volume de Negócios

O tempo total de teste é reduzido no modelo RAD, pois os protótipos são testados independentemente
durante cada iteração. No entanto, o fluxo de dados e as interfaces entre todos os componentes precisam ser
exaustivamente testados com cobertura de teste completa. Como a maioria dos componentes de
programação já foi testada, reduz o risco de problemas maiores.

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

Modelo RAD vs SDLC tradicional

O SDLC tradicional segue um modelo de processo rígido com grande ê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 sente o produto, pois não há construção disponível há muito 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 todo o ciclo 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 em que a modularização clara é possível. Se o
projeto não puder ser dividido em módulos, o RAD poderá falhar.

Os ponteiros a seguir descrevem os cenários típicos em que o RAD pode ser usado -

 O RAD deve ser usado somente quando um sistema pode ser modularizado para ser entregue de
maneira incremental.
 Deve ser usado se houver alta disponibilidade de designers para Modelagem.
 Deve ser usado somente se o orçamento permitir o uso de ferramentas automatizadas de geração de
código.
 O modelo RAD SDLC deve ser escolhido somente se especialistas de domínio estiverem disponíveis
com conhecimento de negócios relevante.
 Deve ser usado onde 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 desenvolvimento paralelo. O RAD funciona bem somente se engenheiros
altamente qualificados estiverem disponíveis e o cliente também estiver comprometido em alcançar o
protótipo desejado no prazo determinado. Se houver falta de comprometimento de ambos os lados, o modelo
pode falhar.

As vantagens do modelo RAD são as seguintes −

 A mudança de requisitos pode ser acomodada.

 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 pouco tempo.
 Tempo de desenvolvimento reduzido.
 Aumenta a reutilização de componentes.
 Rápidas revisões iniciais ocorrem.
 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.

 Somente 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 da gestão é maior.
 Adequado para sistemas baseados em componentes e escaláveis.
 Requer o envolvimento do usuário durante todo o ciclo de vida.
 Adequado para projetos que exigem tempos de desenvolvimento mais curtos.
SDLC - Modelo de Protótipo de Software

A Prototipagem de Software refere-se à 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 modelo de desenvolvimento de software,
pois permite entender os requisitos do cliente em um estágio inicial de desenvolvimento. Ele ajuda a obter
feedback valioso do cliente e ajuda os designers e desenvolvedores de software a entender exatamente o que
é esperado do produto em desenvolvimento.

O que é Prototipagem de Software?

Protótipo é um modelo funcional de software com algumas funcionalidades limitadas. O protótipo nem
sempre contém a lógica exata usada na aplicação 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 dos desenvolvedores e as
experimentem 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 Requisitos Básicos

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.

Desenvolvimento do protótipo inicial

O protótipo inicial é desenvolvido nesta etapa, 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 forma organizada e usado para melhorias adicionais no produto em desenvolvimento.

Revisar e aprimorar o protótipo

O feedback e os comentários de revisão são discutidos durante esta etapa 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 no 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 de
usuário do produto e oferece uma visão mais ampla de todo o sistema, sem se concentrar em funções
internas. Por outro lado, um protótipo Vertical é uma elaboração detalhada de uma função específica ou de
um subsistema no produto.

A finalidade do protótipo horizontal e vertical é diferente. Os protótipos horizontais são usados para obter
mais informações sobre o nível de interface do usuário e os requisitos de negócios. Ele 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 utilizados -

Prototipagem descartável/rápida

A prototipagem descartável também é chamada de prototipagem rápida ou fechada. Este tipo de

prototipagem usa muito poucos esforços com análise de requisitos mínimos para construir um protótipo.
Uma vez que os requisitos reais são entendidos, 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 prototipagem, é baseada na construção de

protótipos funcionais reais com funcionalidade mínima no início. O protótipo desenvolvido forma o coração
dos futuros protótipos sobre os quais todo o sistema é construído. Ao usar a prototipagem evolutiva, os
requisitos bem compreendidos são incluídos no protótipo e os requisitos são adicionados à medida que 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, à integração de 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.
Primeiramente, 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. Esse processo é chamado de Extreme
Prototyping usado para chamar a atenção para a segunda fase do processo, onde uma interface do usuário
totalmente funcional é desenvolvida com muito pouca consideração pelos serviços reais.

Prototipagem de Software – Aplicação

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 passem
por várias telas antes que os dados sejam processados podem usar a prototipagem de forma muito eficaz
para dar a aparência exata mesmo antes que o software real seja 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 de
protótipos 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 é utilizada 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 valor considerável ao software final
desenvolvido. O modelo tem seus próprios prós e contras discutidos a seguir.
As vantagens do Modelo de Prototipagem são as seguintes −

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

 Uma vez que um modelo de trabalho 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.
 O feedback mais rápido do usuário está disponível, levando a melhores soluções.
 A 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 a muita dependência do protótipo.

 Os usuários podem ficar confusos nos protótipos e 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 não for tecnicamente viável.
 O esforço investido na construção de protótipos pode ser excessivo se não for monitorado
adequadamente.