SDLC Visão Tradicionalista

Conteudista: Prof. Me. Artur Marques

Revisão Textual: Esp. Jéssica Dante

Objetivo da Unidade:

Conhecer o ciclo de vida do desenvolvimento de software tradicional.

ʪ Material Teórico

ʪ Material Complementar

ʪ Referências
1 /3

ʪ Material Teórico

Ciclo de Vida de Software (SDLC) 

Nas décadas de 50 e 60 do século XX, a ciência da computação progrediu rapidamente, tivemos na sequência a grande crise de desenvolvimento
de software que gerou como consequência quase todos os novos paradigmas de engenharia de software que conhecemos atualmente. 

Essa rápida evolução desencadeou o início de uma estrutura de produção que acabou se transformando no SDLC que conhecemos hoje.

Antes da década de 50, a computação não era elaborada o suficiente para exigir uma abordagem detalhada com um SDLC. À medida que a
complexidade e a escala da programação cresciam, surgiu o conceito de programação estruturada. 

Ao longo do tempo, a programação estruturada exigiu modelos de desenvolvimento mais táticos, desencadeando assim os primórdios do SDLC. 

O Ciclo de Vida de Desenvolvimento de Software – SDLC, sigla em inglês, é um processo estruturado que possibilita a produção de software de alta
qualidade e baixo custo, no menor tempo de produção possível. 

O seu objetivo é produzir software superior com qualidade e que atenda e supere todas as expectativas e demandas dos clientes. 

O SDLC define e descreve um plano detalhado com estágios ou fases, cada um abrangendo seu próprio processo e entregas. Sua adesão aumenta
a velocidade de desenvolvimento e minimiza os riscos e custos do projeto associados a métodos alternativos de produção.

Por outro lado, ele fornece uma estrutura padronizada que define atividades e entregas, auxilia no planejamento, estimativa e programação de
projetos, facilita o rastreamento e o controle do projeto de software, aumenta a visibilidade de todos os aspectos do ciclo de vida para todas as
partes interessadas envolvidas no processo de desenvolvimento, aumenta a velocidade de desenvolvimento, melhora o relacionamento com o
cliente, diminui os riscos, e por fim, reduz as despesas de gerenciamento e o custo geral de produção do software.

Veja o Ciclo de Vida de Desenvolvimento de Software como uma aplicação de práticas de negócios padrão para construir aplicativos de software.
Normalmente é dividido entre cinco e oito etapas. Vejamos: 

Um SDLC com 8 componentes:

Planejamento; 

Requisitos; 

Projeto; 

Construção; 

Documentação; 

Teste; 

Implantação; 

Manutenção.
 Um SDLC com 7 componentes, muito usado:

Análise de requisitos;

Definição;

Design;

Codificação;

Teste;

Implantação;

Manutenção.

Esse foi o início, porém com o passar das décadas de desenvolvimento de software e engenharia de software ele foi se expandindo, mas sua
essência permaneceu.

Percebemos que aqui não foi mencionada a Documentação, entretanto, se compararmos com o de oito níveis, percebemos que os nomes apenas
mudaram, mas em última análise representam a mesma coisa. Por exemplo (Planejamento + Requisitos) = Análise de requisitos + Definição;
Projeto = Design; Construção = Codificação e assim por diante.

Como foi concebido o SDLC original:

Planejamento;

Análises;

Design;

Implementação;

Manutenção.

Alguns autores irão combinar, dividir ou omitir etapas, dependendo do escopo de atuação ou dos projetos aos quais se referirem. Todavia, esses
são os componentes principais recomendados para todos os projetos de desenvolvimento de software, mesmo os que seguem paradigmas ágeis.

Então, você já deve ter percebido que o SDLC é uma forma de medir e melhorar o processo de desenvolvimento de software e que permite uma
análise detalhada de cada etapa do processo. Isso, por sua vez, ajuda as empresas a maximizar a eficiência em cada estágio. 

À medida que o poder de computação cresce, aumenta a demanda por software e desenvolvedores. As empresas devem reduzir custos, entregar
software mais rapidamente e atender ou exceder as necessidades de seus clientes. É por isso que o SDLC ajuda a atingir esses objetivos
identificando ineficiências e custos mais altos e corrigindo-os para que funcionem de maneira ótima.

Aderir a esse processo leva ao desenvolvimento do software de forma sistemática e disciplinada.

Reflita no seguinte exemplo: um software tem que ser desenvolvido, e uma equipe é dividida para trabalhar em um recurso do produto e tem
permissão para trabalhar como quiser. Um dos desenvolvedores decide projetar primeiro, enquanto outro decide codificar primeiro e um outro
decide primeiro fazer a parte de documentação. Isso levará ao fracasso do projeto, por isso é necessário ter um bom conhecimento e
compreensão entre os membros da equipe para entregar um produto esperado. A forma de organizar essas entregas e colocá-las numa ordem
conhecida é o SDLC.

Veja a seguir quais fases passamos em um projeto de software:

Fase de planejamento: abrange todos os aspectos do gerenciamento de projetos e produtos. Isso normalmente inclui alocação
de recursos, planejamento de capacidade, programação de projetos, estimativa de custos e provisionamento. Nessa fase, a
equipe de desenvolvimento coleta informações das partes interessadas envolvidas no projeto: clientes, vendas, especialistas
internos e externos e desenvolvedores, por exemplo. Essa entrada é sintetizada em uma definição detalhada dos requisitos
para a criação do software desejado. A equipe também determina quais recursos são necessários para satisfazer os requisitos
do projeto e, em seguida, infere o custo associado. Além disso, as expectativas também são claramente definidas durante esta
fase; a equipe determina não apenas o que é desejado no software, mas também o que não é. As entregas tangíveis produzidas a
partir desta fase incluem planos de projeto, custos estimados, cronogramas projetados e necessidades de aquisição;

Fase de codificação: inclui o design do sistema em um ambiente de desenvolvimento integrado. Também inclui análise estática
de código e revisão de código para vários tipos de dispositivos;

Fase de construção: pega os requisitos de código determinados anteriormente e os usa para começar a construir o software;

Fase de teste: envolve a avaliação do software criado. A equipe de teste analisa o produto desenvolvido para avaliar se eles
atendem aos requisitos especificados na fase de planejamento. As avaliações envolvem o desempenho de testes funcionais:
teste de unidade, teste de qualidade de código, teste de integração, teste de sistema, teste de segurança, teste de desempenho e
teste de aceitação, bem como os testes não funcionais. Se um defeito for identificado, os desenvolvedores serão notificados. Os
defeitos validados, ou seja, defeitos reais, são resolvidos e uma nova versão do software é produzida. O melhor método para
garantir que todos os testes sejam executados de forma regular e confiável é implementar testes automatizados. As
ferramentas de integração contínua auxiliam nessa necessidade;

Fase de lançamento: a fase de lançamento envolve o empacotamento do sistema para os lançamentos em diferentes
ambientes;

Fase de implantação: o software é lançado oficialmente no ambiente de produção;

Fase de operação: envolve o uso do software no ambiente de produção;

Fase de monitoramento: vários elementos do software são monitorados. Isso pode incluir o desempenho geral do sistema, a
experiência do usuário, novas vulnerabilidades de segurança, uma análise de bugs ou erros no sistema.

A melhor e mais importante prática a ser implementada em seu SDLC é a comunicação eficaz em toda a equipe. Quanto mais alinhamento,
maiores as chances de sucesso.

Os sinais de um SDLC bem implementado incluem:

A implantação bem-sucedida de um programa abrangente de segurança de aplicativos;

Padrões de qualidade do código;

Colaboração eficaz entre equipes;

Fluxos de trabalho simplificados;

Envolvimento cruzado das equipes ao longo do ciclo de vida;

Erros e desafios comuns do SDLC.

Existem várias armadilhas que ameaçam impactar negativamente uma implementação do SDLC. Talvez o erro mais problemático seja a falha em
contabilizar e acomodar adequadamente as necessidades dos clientes e das partes interessadas no processo. Isso resulta em um mal-entendido
dos requisitos do sistema e uma decepção inevitável com o produto. Além disso, a complexidade do SDLC geralmente faz com que um projeto saia
dos eixos, mesmo os com paradigmas ágeis, ou as equipes percam de vista as especificidades e os requisitos. Sem uma adesão estrita a todos os
aspectos dos parâmetros e planos de design, um projeto pode facilmente errar o alvo.

Modelos de Processos de Software

Como comentei, há diversos modelos de SDLC, vamos conhecer os mais tradicionais nesta Unidade:

Modelo Cascata;

Modelo V;

Modelo Incremental;

Modelo Iterativo;

Modelo Prototipagem;

Modelo Espiral;

Modelo Processo Unificado.

Modelo Cascata/Waterfall
Foi introduzido na década de 70 do século XX por Winston Royce. Possui cinco fases: 

Análise e especificação de requisitos;

Projeto;

Implementação e teste de unidade;

Integração e teste de sistema;

Operação e manutenção.

As etapas sempre seguem essa ordem e não se sobrepõem. O desenvolvedor deve concluir todas as fases anteriores antes do início da próxima
fase. Este modelo é denominado Cachoeira ou Cascata, pois sua representação diagramática se assemelha a uma série de quedas d’água.
 Figura 1 – Modelo Cascata/Waterfall

#ParaTodosVerem: Imagem do modelo em cascata. Imagem colorida contendo 5 retângulos ligados por uma seta na cor
preta contendo em seu interior o nome de cada fase do ciclo de desenvolvimento de software para esse modelo. Em seu
exterior, na lateral direita de cada retângulo, há dois itens descrevendo sua função geral. O retângulo mais alto é
nomeado como requisitos e como saída de fase produz os documentos de requisitos e casos de uso. O próximo retângulo
descendente é nomeado como design e tem como saída de fase a arquitetura de software e o mapeamento das partes
interessadas. O terceiro retângulo é chamado de implementação e tem como saídas a construção do software e o
armazenamento e a recuperação de dados. O quarto retângulo é chamado de verificação, como saída de fase se produz o
teste e a depuração do software. Por fim, o quinto retângulo é chamado de manutenção e como saída produz correções de
erros e otimizações. Fim da descrição.

Vamos descrever rapidamente as fases:

Fase de análise e especificação de requisitos: o objetivo desta fase é entender os requisitos exatos do cliente e documentá-los
adequadamente. Tanto o cliente quanto o desenvolvedor de software trabalham juntos para documentar todas as funções,
desempenho e requisitos de interface do software. Ele descreve o “o quê” do sistema a ser produzido e não o “como”;

Fase de projeto: esta fase visa transformar os requisitos reunidos no SRS – Especificação dos Requisitos do Sistema, em uma
forma adequada que permita codificação posterior em uma linguagem de programação. Ele define a arquitetura geral do
software juntamente com um design detalhado e de alto nível. Todo esse trabalho é documentado como um Documento de
Design de Software – SDD em inglês. Implementação e teste de unidade: durante esta fase, o design é implementado. Se o SDD
estiver completo, a fase de implementação ou codificação prossegue sem problemas, pois todas as informações necessárias
aos desenvolvedores de software estão contidas no SDD. Durante o teste, o código é minuciosamente examinado e modificado.
Os módulos pequenos são testados isoladamente inicialmente. Depois disso, esses módulos são testados escrevendo algum
código de sobrecarga para verificar a interação entre esses módulos e o fluxo de saída intermediária;

Fase de implementação e teste de unidade: na fase de implementação começamos a construir o software e a escrever o código
para o produto. O resultado desta fase é o Documento de Código Fonte e o produto desenvolvido. Quando o software está pronto,
ele é enviado para o departamento de teste, onde a equipe de teste o testa minuciosamente para diferentes defeitos. Podemos
testar o software manualmente, quando ele é considerado pequeno e com pouca complexidade ou usando ferramentas de teste
automatizadas, quando for grande e complexo, ou seja, depende do processo definido. O teste de unidade é um processo de
desenvolvimento de software no qual as menores partes testáveis de um aplicativo, chamadas de unidades, são examinadas
individual e independentemente. Antes que o teste possa começar, a equipe do projeto desenvolve um plano de teste;
 Fase de integração e teste do sistema: esta fase é altamente crucial, pois a qualidade do produto é determinada pela eficácia dos
testes realizados. A melhor produção levará a clientes satisfeitos, custos de manutenção mais baixos e resultados precisos. O
teste de unidade determina a eficiência de módulos individuais. No entanto, nesta fase, os módulos são testados quanto às suas
interações entre si e com o sistema;

Fase de operação e manutenção: manutenção é a tarefa realizada por cada usuário uma vez que o software foi entregue ao
cliente, instalado e operacional.

Vantagens do modelo cascata:

O modelo em cascata é o modelo simples e de fácil compreensão e é aquele em que todas as

fases são feitas passo a passo;

As entregas de cada fase são bem definidas, o que não leva a nenhuma complexidade e torna o projeto facilmente gerenciável.

Desvantagens do modelo waterfall:

O modelo em cascata é demorado e não pode ser usado em projetos de curta duração, pois neste modelo uma nova fase não
pode ser iniciada até que a fase em andamento seja concluída;

O modelo em cascata não pode ser usado para os projetos que têm requisitos incertos ou nos
quais o requisito continua mudando, pois este modelo espera que o requisito seja claro na
própria fase de coleta e análise de requisitos, uma vez que qualquer alteração nos estágios
posteriores levaria a um custo maior, porque seriam necessárias mudanças em todas as fases.

Algumas circunstâncias em que o uso do modelo cascata é mais adequado:

Quando os requisitos são constantes e não são alterados regularmente;

Um projeto é curto;

A situação é calma;

Onde as ferramentas e a tecnologia usadas são consistentes e não mudam;

Quando os recursos estão bem preparados e disponíveis para uso.

Modelo V
O Modelo V também é conhecido como Modelo de Verificação e Validação. Neste modelo, verificação e validação andam de mãos dadas, ou seja,
desenvolvimento e teste são paralelos. O modelo V e o modelo em cascata são os mesmos, exceto que o planejamento de teste e o próprio teste
começam em um estágio inicial no Modelo V.

Vamos conhecer as fases desse SDLC:

Fase de Verificação:
 Análise de Requisitos: nesta fase, todas as informações necessárias são coletadas e
analisadas. As atividades de verificação incluem a revisão dos requisitos;

Projeto do Sistema: uma vez que o requisito é claro, um sistema é projetado, ou seja,

arquitetura, componentes do produto são criados e documentados em um documento de
projeto;

Projeto de Alto Nível: o design de alto nível define a arquitetura/design dos módulos. Ele
define a funcionalidade entre os dois módulos;

Projeto de Baixo Nível: o design de baixo nível define a arquitetura/design de componentes

individuais;

Codificação: o desenvolvimento do código é feito nesta fase.

Fase de Validação:

Teste de Unidade: é realizado usando os casos de teste de unidade que são projetados e é
feito na fase de projeto de baixo nível. O teste de unidade é realizado pelo próprio
desenvolvedor. É realizado em componentes individuais que levam à detecção precoce de
defeitos;

Teste de Integração: é realizado usando casos de teste de integração na fase de design de

alto nível. O teste de integração é o teste feito em módulos integrados. É realizado por
testadores;

Teste do Sistema: é realizado na fase de design do sistema. Nesta fase, todo o sistema é
testado, ou seja, toda a funcionalidade do sistema é testada;

Teste de Aceitação: está associado à fase de Análise de Requisitos e é feito no ambiente do

cliente.
Figura 2 – Exemplo de Modelo V
Fonte: Adaptada de UFPE

#ParaTodosVerem: Modelo V. Figura em tons de azul contendo o modelo V. Possui uma série de retângulos com
instruções internas, quatro deles descendentes: um na base e outros quatro em ascendência, formando algo que lembra
uma letra V maiúscula. Da esquerda para direita descendentemente do topo para a base a ordem dos retângulos
conectados por uma linha é: requisitos do usuário, requisitos do sistema, projeto global e projeto detalhado. Na base
desse V encontra-se a caixa nomeada Implementação. Iniciamos de baixo para cima ascendentemente as seguintes
caixas: teste de unidade, teste de integração, teste de sistema e teste de aceitação. Cada uma dessas caixas em seu nível é
ligada por uma seta que sai da caixa da esquerda para a direita. Fim da descrição.

Vantagens:

É um modelo simples e de fácil compreensão;

A abordagem de modelo V é boa para projetos menores em que o requisito é definido e

congela no estágio inicial;

É um modelo sistemático e disciplinado que resulta em um produto de alta qualidade.

Desvantagens:

O modelo em forma de V não é bom para projetos em andamento;

A mudança de requisito no estágio posterior custaria muito alto.

Modelo Incremental
Esse modelo quebra o produto em pequenos pedaços, ou seja, divide o produto em pequenos pedaços. Temos aqui o melhor de dois mundos. 

No Modelo Incremental os requisitos são divididos em vários módulos autônomos do ciclo de desenvolvimento de software. Cada módulo passa
pelas fases de requisitos, design, implementação e testes. Cada versão subsequente do módulo adiciona funções à versão anterior. O processo
continua até que o sistema completo seja alcançado.

Temos quatro fases nesse modelo:

Análise de requisitos: na primeira fase do modelo incremental, a expertise em análise de produto identifica os requisitos. E os
requisitos funcionais do sistema são entendidos pela equipe de análise de requisitos. Para desenvolver o software sob o modelo
incremental, esta fase desempenha um papel crucial;

Design & Desenvolvimento: nesta fase do modelo incremental de SDLC, o design da funcionalidade do sistema e o método de
desenvolvimento são finalizados com sucesso. Quando o software desenvolve uma nova praticidade, o modelo incremental usa
estilo e fase de desenvolvimento;

Teste: no modelo incremental, a fase de teste verifica o desempenho de cada função existente, bem como funcionalidades
adicionais. Na fase de teste, os vários métodos são usados para testar o comportamento de cada tarefa;

Implementação: a fase de implementação permite a fase de codificação do sistema de desenvolvimento. Envolve a codificação
final que projeta na fase de projeto e desenvolvimento e testa a funcionalidade na fase de teste. Após a conclusão desta fase, o
número do produto funcionando é aprimorado e atualizado até o produto do sistema.

Usamos o modelo incremental quando?

Quando os requisitos são altos (não muito detalhados, mais gerais);

Um projeto tem um longo cronograma de desenvolvimento;

Quando a equipe de software não é muito bem qualificada ou treinada;

Quando o cliente exige uma liberação rápida do produto;

Você pode desenvolver requisitos priorizados primeiro.

Modelo Iterativo
Por outro lado, no Modelo Iterativo temos uma outra situação. 

Podemos começar o projeto de software com algumas especificações e desenvolver a primeira versão do software. Após a primeira versão, se
houver necessidade de alterar, uma nova versão do software é criada com uma nova iteração. Cada lançamento do Modelo Iterativo termina em
um período exato e fixo que é chamado de iteração. Aqui creio que você comece a perceber um embrião dos modelos ágeis.

Cada iteração passa pelas fases: Análise de Requisitos, Projeto, Codificação e Teste. O planejamento detalhado não é necessário nas iterações.

Quando a iteração é concluída, um produto é verificado e entregue ao cliente para avaliação e feedback. O feedback do cliente é implementado na
próxima iteração junto com o recurso recém-adicionado.
Assim, o produto aumenta em termos de recursos e, uma vez que as iterações são concluídas, a compilação final contém todos os recursos do
produto.

Fases do Modelo de Desenvolvimento Iterativo:

Levantamento e análise de requisitos: requisitos são coletados dos clientes e verificados por um analista se serão atendidos ou
não. O analista verifica se a necessidade vai atingir dentro do orçamento ou não. Depois de tudo isso, a equipe de software pula
para a próxima fase;

Design: a equipe projeta o software pelos diferentes diagramas, como diagrama de fluxo de dados, diagrama de atividades,
diagrama de classes, diagrama de transição de estado etc.;

Implementação: os requisitos são escritos na linguagem de codificação e transformados em programas de computador que
são chamados de Software;

Teste: começa usando diferentes métodos de teste. Existem muitos métodos de teste, mas os mais comuns são os métodos de
teste de caixa branca, caixa preta e caixa cinza;

Implantação: o software é implantado em seu ambiente de trabalho;

Revisão: verificar o comportamento e a validade do produto desenvolvido. E se houver algum erro encontrado, o processo será
reiniciado a partir da coleta de requisitos;

Manutenção: após a implantação do software no ambiente de trabalho podem ocorrer alguns bugs, alguns erros ou novas
atualizações são necessárias. A manutenção envolve depuração e novas opções de adição.

Vantagens:

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

Um desenvolvimento paralelo pode planejar;

É facilmente aceitável para as necessidades em constante mudança do projeto;

Os riscos são identificados e resolvidos durante a iteração.

Desvantagens:

Não é adequado para projetos menores;

Mais recursos podem ser necessários;

O design pode ser alterado várias vezes devido a requisitos imperfeitos.

Modelo Prototipagem
O modelo de protótipo é um modelo que possui capacidades funcionais limitadas e desempenho ineficiente quando comparado ao software real.
Funções fictícias são usadas para criar protótipos. Porém, é um mecanismo valioso para entender as necessidades dos clientes.
Um protótipo é uma implementação de brinquedo do sistema. Um protótipo geralmente acaba sendo uma versão muito rudimentar do sistema
real, possivelmente exibindo capacidades funcionais limitadas, baixa confiabilidade e desempenho ineficiente em comparação com o software
real. Em muitos casos, o cliente tem apenas uma visão geral do que se espera do produto de software. Nesse cenário, onde não há informações
detalhadas sobre a entrada do sistema, as necessidades de processamento e o requisito de saída, o modelo de prototipagem pode ser empregado.

Os protótipos de software são construídos antes do software real para obter feedback valioso do cliente. Os feedbacks são implementados e o
protótipo é novamente revisado pelo cliente para qualquer alteração. Esse processo continua até que o modelo seja aceito pelo cliente. 

Feito o levantamento de requisitos, é criado o design rápido e construído o protótipo que é apresentado ao cliente para avaliação. O feedback do
cliente e o requisito refinado são usados para modificar o protótipo e são novamente apresentados ao cliente para avaliação. Depois que o cliente
aprova o protótipo, ele é usado como requisito para a construção do software real. O software real, todavia, é construído usando a abordagem do
modelo cascata.

Etapas do modelo de protótipo:

Levantamento de Requisitos e Analista;

Decisão rápida;

Construir um protótipo;

Avaliação ou Avaliação do Usuário;

Refinamento de protótipo;

Produto.

Vantagens:

O modelo de protótipo reduz o custo e o tempo de desenvolvimento, pois os defeitos são

encontrados muito mais cedo;

Recurso ou funcionalidade ausente ou uma mudança no requisito podem ser identificados

na fase de avaliação e podem ser implementados no protótipo refinado;

O envolvimento de um cliente desde o estágio inicial reduz qualquer confusão no requisito

ou compreensão de qualquer funcionalidade.

Desvantagens:

Como o cliente está envolvido em todas as fases, o cliente pode alterar o requisito do
produto, o que aumenta a complexidade do escopo e pode aumentar o tempo de entrega do
produto final. Lembre-se que o desenvolvimento é feito via método cascata.
 Figura 3 – Modelo de Protótipo

#ParaTodosVerem: Esquema de Protótipo. A imagem contém um círculo azul dividido em seis partes contendo o nome
de cada fase. O início é nomeado como: obtenção dos requisitos. A próxima divisão do círculo é nomeada de projeto
rápido. A terceira divisão é chamada de construção do protótipo. A quarta é chamada de avaliação do protótipo. A quinta é
chamada de refinamento do protótipo e, por fim, a sexta é chamada de construção do produto, onde há sobre ela a
palavra FIM. O ciclo se repete no protótipo até se obter um resultado satisfatório. Fim da descrição.

Modelo Espiral
O Modelo Espiral foi proposto inicialmente por Barry Boehm e é um modelo de processo de software evolutivo que acopla a característica iterativa
da prototipagem com os aspectos controlados e sistemáticos do modelo sequencial linear. 

As fases do modelo espiral são seguidas nas iterações. Há loops (referências circulares) no modelo que representam a fase do processo SDLC, ou
seja, o loop mais interno é de Coleta e Análise de Requisitos que segue o planejamento, análise de risco, desenvolvimento e avaliação. O próximo
loop é Design, seguido de Implementação e Teste. 

O modelo espiral implementa o potencial de desenvolvimento rápido de novas versões do software. Usando esse modelo, o software é
desenvolvido em uma série de versões incrementais (por isso a representação em loops: cada volta vai diminuindo a carga de produção até que
não reste mais nada de trabalho e o sistema seja entregue). Portanto, durante as iterações iniciais, a versão adicional pode ser um modelo de
papel ou protótipo, como mencionei anteriormente. Durante as iterações posteriores, são produzidas versões cada vez mais completas do
sistema projetado.

Sommerville (2011) descreve o modelo em espiral como um paradigma de engenharia de software que combina a prevenção e a tolerância às
mudanças, e assume que estas últimas são um resultado de riscos de projeto e inclui atividades explícitas de gerenciamento de riscos para sua
mitigação.

Por outro lado, Pressman (2006) relata que o modelo espiral é uma abordagem realista do desenvolvimento de sistemas e softwares de grande
porte usando a prototipagem como mecanismo de redução de riscos. Portanto, completamente aderente e em acordo com Ian Sommerville
citado no parágrafo anterior.

Figura 4– Modelo em Espiral

#ParaTodosVerem: Modelo Espiral de Barry Boehm. Imagem colorida contendo ao centro uma espiral descendente
cortada em seu centro por uma cruz cujos braços chegam até suas extremidades formando um quadrante. No quadrante
superior esquerdo, uma caixa com borda azul nomeada Definição de Objetivos. No quadrante superior direito, uma caixa
com borda azul nomeada Avaliação e Redução de riscos. No quadrante inferior direito, uma caixa com borda azul
nomeada Implementação e Validação. Por fim, no quadrante inferior esquerdo, uma caixa com borda azul nomeada
Planejamento e Especificação. E o ciclo se repete até que a espiral se feche e o projeto encerre. Fim da descrição.

O Modelo Espiral tem quatro fases:

Definição de objetivos: cada ciclo na espiral começa com a identificação do propósito desse ciclo, as várias alternativas
possíveis para atingir as metas e as restrições existentes;
 Avaliação e redução de riscos: a próxima fase do ciclo é calcular essas várias alternativas com base nas metas e restrições. O
foco da avaliação nesta etapa está localizado na percepção de risco para o projeto;

Desenvolvimento e validação: a próxima fase é desenvolver estratégias que resolvam incertezas e riscos. Esse processo pode
incluir atividades como benchmarking, simulação e prototipagem;

Planejamento: finalmente, o próximo passo é planejado. O projeto é revisto e é feita a escolha de continuar com mais um
período da espiral. Se for determinado que se mantenha, são elaborados planos para a próxima etapa do projeto.

Vantagens:

A Análise de Risco é feita extensivamente usando os modelos de protótipos;

Qualquer aprimoramento ou alteração na funcionalidade pode ser feito na próxima iteração.

Desvantagens:

O modelo espiral é mais adequado apenas para grandes projetos;

O custo pode ser alto, pois pode levar muitas iterações, o que pode levar a um tempo elevado para chegar ao produto.

Modelo Espiral
O Modelo Espiral foi proposto inicialmente por Barry Boehm e é um modelo de processo de software evolutivo que acopla a característica iterativa
da prototipagem com os aspectos controlados e sistemáticos do modelo sequencial linear.

As fases do modelo espiral são seguidas nas iterações. Há loops (referências circulares) no modelo que representam a fase do processo SDLC, ou
seja, o loop mais interno é de Coleta e Análise de Requisitos que segue o planejamento, análise de risco, desenvolvimento e avaliação. O próximo
loop é Design, seguido de Implementação e Teste.

O modelo espiral implementa o potencial de desenvolvimento rápido de novas versões do software. Usando esse modelo, o software é
desenvolvido em uma série de versões incrementais (por isso a representação em loops: cada volta vai diminuindo a carga de produção até que
não reste mais nada de trabalho e o sistema seja entregue). Portanto, durante as iterações iniciais, a versão adicional pode ser um modelo de
papel ou protótipo, como mencionei anteriormente. Durante as iterações posteriores, são produzidas versões cada vez mais completas do
sistema projetado.

Sommerville (2011) descreve o modelo em espiral como um paradigma de engenharia de software que combina a prevenção e a tolerância às
mudanças, e assume que estas últimas são um resultado de riscos de projeto e inclui atividades explícitas de gerenciamento de riscos para sua
mitigação.

Por outro lado, Pressman (2006) relata que o modelo espiral é uma abordagem realista do desenvolvimento de sistemas e softwares de grande
porte usando a prototipagem como mecanismo de redução de riscos. Portanto, completamente aderente e em acordo com Ian Sommerville
citado no parágrafo anterior.
 Figura 4 – Modelo em Espiral

#ParaTodosVerem. Modelo Espiral de Barry Boehm. Imagem colorida contendo ao centro uma espiral descendente
cortada em seu centro por uma cruz cujos braços chegam até suas extremidades formando um quadrante. No quadrante
superior esquerdo, uma caixa com borda azul nomeada Definição de Objetivos. No quadrante superior direito, uma caixa
com borda preta nomeada Avaliação e Redução de riscos. No quadrante inferior direito, uma caixa com borda preta
nomeada Implementação e Validação. Por fim, no quadrante inferior esquerdo, uma caixa com borda preta nomeada
Planejamento e Especificação. E o ciclo se repete até que a espiral se feche e o projeto encerre. Fim da descrição.

O Modelo Espiral tem quatro fases:

Definição de objetivos: cada ciclo na espiral começa com a identificação do propósito desse ciclo, as várias alternativas
possíveis para atingir as metas e as restrições existentes;

Avaliação e redução de riscos: a próxima fase do ciclo é calcular essas várias alternativas com base nas metas e restrições. O
foco da avaliação nesta etapa está localizado na percepção de risco para o projeto;

Desenvolvimento e validação: a próxima fase é desenvolver estratégias que resolvam incertezas e riscos. Esse processo pode
incluir atividades como benchmarking, simulação e prototipagem;

Planejamento da próxima etapa do projeto: finalmente, o próximo passo é planejado. O projeto é revisto e é feita a escolha de
continuar com mais um período da espiral. Se for determinado que se mantenha, são elaborados planos para a próxima etapa
do projeto.

Vantagens:
 A Análise de Risco é feita extensivamente usando os modelos de protótipos;

Qualquer aprimoramento ou alteração na funcionalidade pode ser feito na próxima iteração.

Desvantagens:

O modelo espiral é mais adequado apenas para grandes projetos;

O custo pode ser alto, pois pode levar muitas iterações, o que pode levar a um tempo elevado para chegar ao produto.

Modelo Processo Unificado

O processo unificado é um processo de desenvolvimento iterativo e incremental, centrado na arquitetura, orientado a casos de uso. Ele
reconhece a importância da comunicação com o cliente e os métodos simplificados para descrever a visão do cliente de um sistema. Ele enfatiza
o importante papel da arquitetura de software e ajuda o arquiteto a se concentrar nos objetivos certos, como compreensão, confiança em
mudanças futuras e reutilização.

Este processo se divide em cinco fases:

Começo: abrange tanto a comunicação com o cliente quanto as atividades de planejamento. Ao colaborar com as partes
interessadas, os requisitos de negócios para o software são identificados; é proposta uma arquitetura aproximada para o
sistema; e um plano para a natureza iterativa e incremental do projeto subsequente é desenvolvido;

Elaboração: engloba as atividades de comunicação e modelagem do modelo de processo genérico. Ela refina e expande os
casos de uso preliminares que foram desenvolvidos como parte da fase inicial e expande a representação arquitetônica para
incluir cinco visões diferentes do software: o modelo de caso de uso, o modelo de requisitos, o modelo de design, o modelo de
implementação e a implantação;

Construção: cria uma base arquitetural executável que representa um sistema. Usando o modelo de arquitetura como entrada, a
fase de construção desenvolve ou adquire os componentes de software que tornarão cada caso de uso operacional para os
usuários finais. Para isso, requisitos e modelos de projeto que foram iniciados durante a fase de elaboração são concluídos para
refletir a versão final do incremento de software. Todos os recursos e funções necessários para o incremento de software são
então implementados no código-fonte;

Transição: abrange as últimas fases da atividade genérica de construção e a primeira parte da atividade genérica de
implantação: entrega e feedback. O software é fornecido aos usuários finais para testes beta e o feedback do usuário relata
defeitos e alterações necessárias. Na conclusão da fase de transição, o incremento de software torna-se uma versão de software
utilizável;

Produção: é monitorado o uso contínuo do software, fornecido suporte para o ambiente operacional (infraestrutura) e
apresentados e avaliados relatórios de defeitos e solicitações de alterações.

É provável que, ao mesmo tempo em que as fases de construção, transição e produção estejam sendo conduzidas, o trabalho já tenha começado
no próximo incremento de software. Isso significa que as cinco fases não ocorrem em sequência, mas sim com simultaneidade escalonada.
2/3

ʪ Material Complementar

Indicações para saber mais sobre os assuntos abordados nesta Unidade:

  Vídeos  

Modelo em Cascata – Ciclos de Vida de Desenvolvimento de Software 

Modelo em Cascata - Ciclos de Vida de Desenvolvimento de Software

Desenvolvimento Incremental

06 - Desenvolvimento Incremental
Engenharia de Software – Modelo em Espiral de Boehm 

Engenharia de Software - Modelo em Espiral de Boehm

Modelos de Processo (Prototipação)

A2.3 Modelos de Processo (Prototipação)

3/3

ʪ Referências

PRESSMAN, R. S. Engenharia de software. 6. ed. Porto Alegre: AMGH, 2006.

SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Education do Brasil, 2011.