Engenharia de Software

Prévia do material em texto

ENGENHARIA DE 
SOFTWARE
Izabelly Soares de Morais
Conhecer as fases de ciclo 
de vida do software
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Reconhecer os problemas de um projeto e a influência de ciclo de 
vida de software. 
 � Identificar as fases de ciclo de vida de software genérico. 
 � Caracterizar o funcionamento das fases modelo.
Introdução
O ciclo de vida de software pode ser conceituado como uma estru-
tura contendo processos, atividades e tarefas envolvidas na criação, na 
operação ou na manutenção de um software. Ele abrange toda a vida 
de um sistema desde o início, em que a definição de seus requisitos é 
reconhecida, até o final, quando ele não é mais utilizado. No começo de 
um projeto de software, o tipo de ciclo de vida geralmente é a primeira 
decisão a ser tomada.
Neste capítulo, você irá adquirir conhecimentos fundamentais para 
avançar no aprendizado sobre o ciclo de vida de software. Atualmente, 
contamos com um grande conjunto de ciclos de vida de software, sendo 
alguns deles: Cascata, Modelo em V, Incremental, Evolutivo, RAD, Proto-
tipagem, Espiral e Modelo de Ciclo de Vida Associado ao RUP. Cada um 
deles tem características que podem ser uma vantagem ou uma desvan-
tagem, dependendo do contexto do software que será desenvolvido.
Ciclo de vida de um software
Atualmente, uma enorme indústria de software tornou-se fator dominante nas 
economias do mundo industrializado. Equipes de especialistas em software, 
cada qual concentrando-se numa parte da tecnologia necessária para distribuir 
uma aplicação complexa, substituíram o programador solitário de antigamente. 
Esses são conceitos trazidos por Pressman e Maxim (2016, p. 4), que retrará a 
realidade social e a necessidade de se ter técnicas para produzir um software. 
Para justificar sua afirmação, o autor selecionou algumas perguntas:
 � Por que a conclusão de um software leva tanto tempo?
 � Por que os custos de desenvolvimento são tão altos?
 � Por que não conseguimos encontrar todos os erros antes de entregarmos 
o software aos clientes?
 � Por que gastamos tanto tempo e esforço realizando a manutenção de 
programas existentes?
 � Por que ainda temos dificuldades de medir o progresso de desenvolvi-
mento e a manutenção de um software? 
Um dos objetivos da Engenharia de Software é trazer metodologias para 
desenvolvimento de software, para isso, os modelos de ciclo de vida de software 
retratam as técnicas que podem ser utilizadas para desenvolver um sistema 
na prática. Devido ao avanço dos recursos tecnológicos, podemos notar a 
evolução pela qual esses modelos passaram, e, com isso, o impacto que esse 
processo trouxe para o software, até mesmo porque termos como produto final 
um sistema funcional, o qual deverá atender às necessidades de um cliente. 
O cliente é o indivíduo que gostaria que um produto fosse criado (desen-
volvido). Os desenvolvedores são os membros de uma equipe responsável pela 
criação desse produto. Os desenvolvedores podem ser os responsáveis por 
todos os aspectos do processo, desde o levantamento das necessidades até as 
etapas subsequentes, ou então ser responsáveis apenas pela implementação 
de um produto já concebido (SCHACH, 2010, p. 24).
Geralmente um software é concebido para trazer soluções para problemas 
específicos, dessa forma, são desenvolvidos com base em diversas especifi-
cações. Após a definição do objetivo do projeto, ou seja, do software, em que 
todas as necessidades do cliente são descritas, deve haver uma análise do 
que é válido ou não para ser implementado, inserido, no sistema. Devemos 
estar cientes de que nem toda informação passada pelo cliente é válida para 
solucionar o seu problema, e, dessa forma, para ser inserida no processo de 
produção.
Para Schach (2010, p. 36), “[...] o desenvolvimento de software é considera-
velmente diferente na prática por duas razões. Primeiramente, os profissionais 
de software são seres humanos e, portanto, cometem erros. Em segundo lugar, 
Conhecer as fases de ciclo de vida do software2
as necessidades do cliente podem mudar enquanto o produto de software está 
sendo desenvolvido”. Esse é um dos motivos pelos quais o software passa por 
diversos processos para ser classificado como pronto. Outro fato importante 
sobre esse assunto é que um software nunca é finalizado, no sentido de que 
nunca irá passar por alguma modificação futura. Na verdade, ele está em 
constante evolução, pois pode muito bem passar por atualizações conforme 
a necessidade do cliente. Veremos mais adiante, neste capítulo, um ciclo 
genérico de produção de software.
Há muitos mecanismos de avaliação de processos de software que possibilitam 
às organizações determinar o nível de “maturidade” de seu processo de software. 
Entretanto, a qualidade, o cumprimento de prazos e a viabilidade em longo prazo 
do produto que se desenvolve são os melhores indicadores da eficácia do processo 
utilizado (PRESSMAN; MAXIM, 2016, p. 41).
Fases do ciclo de vida de um software 
O processo pode ser definido como um conjunto de atividades de trabalho, 
ações e tarefas realizadas quando algum artefato de software deve ser criado. 
Cada uma dessas atividades, ações e tarefas se alocam dentro de uma meto-
dologia ou um modelo que determina sua relação com o processo e umas com 
as outras. Cada atividade metodológica é composta por um conjunto de ações 
de Engenharia de Software. Cada ação é definida por um conjunto de tarefas, 
o qual identifica as tarefas de trabalho a serem completadas, os artefatos 
de software que serão produzidos, os fatores de garantia da qualidade que 
serão exigidos e os marcos utilizados para indicar progresso (PRESSMAN; 
MAXIM, 2016, p. 35).
Podemos relacionar a Engenharia de Software com um procedimento 
organizacional, em que o processo é a base para as técnicas trazidas pela 
Engenharia. Ela é composta por algumas camadas. Dentre elas, podemos 
destacar: as ferramentas, que fornecem suporte, muitas vezes por meio de 
software específico automatizando a solução dos processos; os métodos que 
3Conhecer as fases de ciclo de vida do software
trazem as técnicas de desenvolvimento; o processo, o qual já definimos an-
teriormente; e o foco na qualidade, que demonstrará a eficiência do software 
diante das necessidades do cliente. 
Segundo Sommerville (2011, p. 18), um processo de software é um con-
junto de atividades relacionadas que levam à produção de um produto de 
software. Essas atividades podem envolver o desenvolvimento de software 
em uma linguagem de programação. No entanto, em razão da exigência do 
mercado, os sistemas passaram a ser desenvolvidos tendo como base extensões 
e modificações por meio de integrações entre componentes já existentes ou 
até mesmo criação de novos. O autor diz que, apesar de existirem diferentes 
processos de software, todos devem incluir quatro atividades fundamentais:
1. Especificação de software
2. Projeto e implementação de software
3. Validação de software
4. Evolução de software
Essas atividades possuem outras subatividades, tais como validação de 
requisitos, projeto de arquitetura, testes unitários, dentre outros. As descrições 
do processo, de acordo com Sommerville (2011, p. 19), podem incluir:
 � Produtos, que são os resultados de uma das atividades do processo.
 � Papéis, que refletem as responsabilidades das pessoas envolvidas no 
processo.
 � Pré e pós-condições, que são declarações verdadeiras antes e depois de 
uma atividade do processo ou da produção de um produto.
Assim como o entendimento e a interpretação do modo representativo de 
um ser humano, que, neste caso, se configura como o papel de nosso cliente, 
um processo de software é algo bem complexo, tendo em vista que envolve 
ferramentas práticas para desenvolvimento de software e diversas tomadas de 
decisões que influenciarão diretamente no resultado final, ou seja, no software.
Uma metodologia de processo genérica para Engenharia de Software esta-belece também cinco atividades metodológicas: comunicação, planejamento, 
modelagem, construção e entrega. Além disso, um conjunto de atividades de 
apoio é aplicado ao longo do processo, como o acompanhamento e o controle 
do projeto, a administração de riscos, a garantia da qualidade, o gerenciamento 
Conhecer as fases de ciclo de vida do software4
das configurações, as revisões técnicas, entre outras. Um fluxo de processo, 
como apresentado na Figura 1 a seguir, descreve como são organizadas as 
atividades metodológicas, bem como as ações e as tarefas que ocorrem dentro 
de cada atividade em relação à sequência e ao tempo (SCHACH, 2010, p. 31).
Figura 1. Metodologia do processo de software.
Fonte: Adaptada de Schach (2010, p. 31).
Devemos ter em mente que, apesar de termos todas essas informações, 
não temos obrigação nenhuma de utilizá-las da maneira que são expostas. 
Não existe um modelo ou uma técnica ideal, dita como correta, para todas 
as situações. A escolha dos processos e das métricas deverá ser realizada 
conforme o contexto do projeto. 
5Conhecer as fases de ciclo de vida do software
Em sua obra, Pressman e Maxim (2016, p. 41) indicam 
um “jogo de simulação de processos”, que inclui os mais 
importantes modelos de processo prescritivos. Pode ser 
encontrada em:
https://goo.gl/1pmbqv
Caracterizar o funcionamento das fases modelo
As etapas comuns em todos os modelos de processo de software têm como 
função nortear as demais fases que vão sendo inseridas conforme os modelos de 
processo foram sendo criados. Sabemos que a era tecnológica está sempre em 
movimento, pois cada vez mais recursos estão sendo desenvolvidos. Citamos 
anteriormente quatro atividades fundamentais da Engenharia de Software 
diante dos processos de software: especificação, projeto e implementação, 
validação e evolução de software. Porém, outras atividades vistas como com-
plementares são citadas por Schach (2010, p. 43):
1. Fase de levantamento de necessidades
2. Fase de análise (especificação)
3. Fase de projeto
 ■ Projeto de arquitetura (extrair os módulos)
 ■ Projeto detalhado
4. Fase de implementação
 ■ Codificar os módulos em uma linguagem de programação apropriada
 ■ Integrar
5. Manutenção pós-entrega
6. Retirada do produto
Conhecer as fases de ciclo de vida do software6
Figura 2. Desenvolvimento ideal 
de software.
Fonte: Pressman e Maxim (2016, p. 36).
Levantamento
de necessidade
Análise
Projeto
Implementação
Desenvolvimento
Apesar de obviamente ter algumas etapas em comum, Schach (2010) traz 
algumas atividades complementares a cada uma das fases, como podemos 
visualizar na Figura 2. Porém, vamos debater um pouco sobre as principais, que 
são comuns a todos os modelos, seguindo as definições de Sommerville (2011):
7Conhecer as fases de ciclo de vida do software
1. Especificação de software: “[...] é o processo de compreensão e definição 
dos serviços requisitados do sistema e identificação de restrições relati-
vas à operação e ao desenvolvimento do sistema.” (SOMMERVILLE, 
2011, p. 24). Os requisitos são bem importantes nesta fase, pois, por 
estar presente na fase inicial do desenvolvimento, todas as demais etapas 
irão depender dela. Algumas informações complementares podem ser 
visualizadas na Figura 3.
Figura 3. Requisitos da Engenharia de Processos.
Fonte: Sommerville (2011, p. 25).
Estudo de
viabilidade
Relatório de
viabilidade
Elicitação
e análise
Modelos de
Sistema
cação
Req. Usuário e
de sistema
Validação
Documento
Requisitos
2. Projeto e implementação de software: “[...] é o processo de conversão 
de uma especificação do sistema em um sistema executável. Sempre 
envolve processos de projeto e programação de software, mas, se for 
usada uma abordagem incremental para o desenvolvimento, também 
pode envolver o refinamento da especificação do software.” (SOM-
MERVILLE, 2011, p. 25). Após essa definição dada por Sommerville 
(2011), já começa a ficar mais claro que uma etapa depende, de alguma 
maneira, da sua etapa anterior. Como já dito, pode haver outras etapas 
adicionais em cada uma delas, o que chamamos de subatividades, porém, 
as principais sempre serão utilizadas. Podemos visualizá-las na Figura 4.
Conhecer as fases de ciclo de vida do software8
Figura 4. Um modelo geral do processo de projeto.
Fonte: Sommerville (2011, p. 26).
Informação
de plataforma
Especificação
de requisitos
Descrição
de dados
Projeto
de arquitetura
Projeto
de interface
Projeto de
compenentes
Projeto de banco de dados
Arquitetura
de sistema
Especificação de
banco de dados
Especificação
de interface
Especificação
de componentes
Entradas de projeto
Atividades de projeto
Saídas de projeto
3. Validação de software: É uma fase conhecida também como de ve-
rificação e validação(V&V), “[...] tem a intenção de mostrar que um 
software se adequa a suas especificações ao mesmo tempo em que 
satisfaz as especificações do cliente do sistema.[...] A validação também 
pode envolver processos de verificação, como inspeções e revisões, em 
cada estágio do processo de software, desde a definição dos requisitos 
de usuários até o desenvolvimento do programa.” (SOMMERVILLE, 
2011, p. 27). A Figura 5 traz os estágios do processo de teste.
Figura 5. Estágio de processo de teste.
Fonte: Adaptada de Sommerville (2011, p. 27).
Teste
de Componente
Teste de
Sistema
Teste de
Aceitação
9Conhecer as fases de ciclo de vida do software
4. Evolução do software: “Historicamente, sempre houve uma separação
entre o processo de desenvolvimento e o de evolução do software, ou
seja, a manutenção de software. [...] Poucos sistemas de software são
completamente novos, e faz muito mais sentido ver o desenvolvimento 
e a manutenção como processos contínuos.” (SOMMERVILLE, 2011,
p. 29).
As mudanças são inevitáveis. O que podemos aprender diante dos conceitos 
vistos é que temos essas ferramentas para auxiliar a equipe desenvolvedora a 
produzir o software com qualidade no processo e, por fim, no sistema final.
Conhecer as fases de ciclo de vida do software10
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 
8. ed. Porto Alegre: AMGH, 2016.
SCHACH, S. R. Engenharia de software: os paradigmas clássicos e orientado a objetos. 
7. ed. Porto Alegre: AMGH, 2010.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
Leituras recomendadas
OLIVEIRA. R. C. Engenharia de software. 2011. Disponível em: <http://www.facom.
ufu.br/~ronaldooliveira/ESOF-2011-2/Aula8-ESOF-AnaliseEstruturada.pdf>. Acesso 
em: 13 ago. 2017.
SLACK, N. et al. Gerenciamento de operações e de processos: princípios e práticas de 
impacto estratégico. 2. ed. Porto Alegre: Bookman, 2013.
YOURDON, E.; CONSTANTINE, L. L. Structured design: fundamentals of a discipline of 
computer program and systems design. Englewood Cliffs: Prentice-Hall, 1979.
ENGENHARIA 
DE SOFTWARE 
Aline Zanin 
Conhecer os modelos 
tradicionais 
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Reconhecer o modelo cascata, seu funcionamento, suas vantagens 
e suas desvantagens.
 � Aplicar o modelo prototipação, seu funcionamento, suas vantagens 
e suas desvantagens.
 � Caracterizar e identificar o modelo espiral, seu funcionamento, suas 
vantagens e suas desvantagens.
Introdução
Os modelos clássicos foram criados entre os anos 1970 e 1990 por evolu-
ções ocorridas no desenvolvimento de software para resolver problemas 
que representavam barreiras na criação de sistemas de alta qualidade. 
O modelo cascata foi um dos primeiros a serem propostos, referenciado 
em livros e amplamente conhecido até hoje. Após sua criação, diversos 
problemas foram apontados, levando ao surgimento de outros modelos, 
como o espiral e o prototipação. Ainda, houve a evolução dos modelos de 
ciclo de vida, possibilitando atualmente a utilização de diversos modelos. 
Para aprender sobre os modelos atuais, é muito importante entender os 
modelos tradicionais,identificar quais foram as evoluções que ocorreram 
e o motivo da presença de determinadas características nos modelos 
que utilizamos hoje.
Neste capítulo, você adquirirá conhecimentos fundamentais sobre os 
modelos de ciclo de vida tradicionais. Para isso, abordaremos os modelos 
cascata, espiral e prototipação, apresentando conceitos básicos sobre 
eles, além de suas vantagens e desvantagens.
1 Modelo cascata
Oficialmente, foi o primeiro modelo de ciclo de vida de desenvolvimento de 
software, motivo pelo qual é o mais conhecido entre os profissionais e estu-
dantes da área de desenvolvimento de sistemas, sobretudo de engenharia de 
software. O modelo recebe o nome de cascata por ser um processo executado 
em sequência, sem que de uma etapa posterior seja possível retornar a uma 
etapa anterior — esse fluxo se assemelha ao do funcionamento de uma cascata, 
na qual o fluxo da água é contínuo para apenas uma direção. 
Também chamado de ciclo de vida clássico, esse modelo sugere uma abor-
dagem sequencial e sistemática para o desenvolvimento de software, come-
çando com a especificação dos requisitos do cliente, avançando pelas fases 
de planejamento, modelagem, construção e disponibilização, e culminando 
no suporte contínuo do software concluído (Figura 1) (PRESSMAN 2011).
Figura 1. Modelo cascata. 
Fonte: Adaptada de Pressman (2011). 
Comunicação
 início do projeto
 levantamento de requisitos
Planejamento
 estimativas
 cronograma
 acompanhamento
Modelagem
 análise
 projeto
Construção
 código
 teste
Entrega
 entrega
 suporte
 feedback
Empregamos o modelo cascata em casos nos quais os requisitos de um 
problema são bem compreendidos e razoavelmente estáveis, ou seja, quando 
o trabalho flui da comunicação à disponibilização de modo relativamente 
linear (PRESSMAN 2011).
Justamente por sua característica sequencial, esse modelo apresenta etapas 
muito bem definidas, o que facilita o gerenciamento dos projetos que o adotam. 
Isso acontece porque a cada etapa são gerados produtos entregáveis, o que 
possibilita que os gestores do projeto acompanhem claramente os resultados.
Outra vantagem do método cascata, também relacionada à separação do 
projeto em etapas, reside no fato de que os requisitos costumam estar bem 
definidos. O modelo não prevê alterações de requisitos no meio do processo, 
mas apenas uma definição detalhada no início que será implementada crite-
riosamente para ser entregue ao final do fluxo.
Conhecer os modelos tradicionais2
Contudo, embora a definição de requisitos no início do projeto permita um 
detalhamento maior, esse modelo desperta um problema clássico da engenha-
ria de software: mudanças de requisitos, sejam por necessidades do cliente, 
necessidades tecnológicas ou viabilidade de mercado, não são bem recebidas 
e podem causar grandes transtornos para o projeto. Isso porque os requisitos 
nesse modelo são alterados apenas após a entrega da última etapa do modelo 
cascata, motivo pelo qual as mudanças podem ser significativas e demandar 
um alto tempo e custo.
Ainda, assim como os requisitos não são mutáveis, quando identificada 
uma falha na etapa imediatamente anterior à etapa corrente, o processo não 
permite que se retroceda a uma fase para realizar a correção, obrigando a 
seguir o fluxo até o final, uma característica que eventualmente se torna uma 
dificuldade ou até mesmo um empecilho para a execução real desse modelo.
Por fim, outra de suas desvantagens é que o cliente apenas visualizará 
o produto que está comprando e terá a oportunidade de ofertar feedback no 
último ciclo, faltando uma interação maior do cliente com a equipe de desen-
volvimento e entre a própria equipe de uma fase para outra.
O modelo cascata considera as fases de análise e definição de requisitos, projeto de 
sistema e de software, implementação e teste de unidades, integração e teste de 
sistemas, operação e manutenção.
2 Modelo prototipação
Assemelha-se ao modelo cascata, considerando que também tem etapas bem 
definidas, mas apresenta uma peculiaridade como característica principal: tem 
em conta uma prototipação ao início do ciclo de vida. Essa prototipação é feita 
após um primeiro contato com o cliente e objetiva que todos os envolvidos 
consigam interagir com esse protótipo, tendo uma ideia de como o software 
funcionará para aprovar ou sugerir modificações. 
3Conhecer os modelos tradicionais
O processo de prototipar antes do início da criação do sistema apresenta 
vantagens e desvantagens. A principal vantagem consiste no fato de que os 
requisitos se tornam mais visuais e intuitivos, uma vez que o profissional 
redigirá o documento de especificação de requisitos tendo o protótipo como 
base. Além disso, possibilita que o cliente tenha maior certeza de que expressou 
suas necessidades corretamente e que, por isso, receberá o software esperado. 
Contudo, o protótipo pode ser considerado uma fonte de retrabalho e 
alto custo, uma vez que, caso o protótipo inicial não atenda às necessidades 
do cliente, precisará ser reconstruído, e, mesmo que seja aceito o primeiro 
protótipo, sua criação representa uma etapa extra, que envolve um trabalho 
de produção e validação. Além disso, por considerar um tempo de criação 
e validação do protótipo, o ciclo de vida do software como um todo pode 
demandar maior tempo para ser executado, processo visualizado na Figura 2.
Figura 2. Modelo prototipação.
Fonte: Adaptada de Schach (2009, p. 53).
Desenvolvimento
Manutenção
Descontinuação
do produto
Manuteção
pós-entrega
Implementação
Projeto
Análise
Protótipo
rápido
Necessidades
de alteração
Conhecer os modelos tradicionais4
3 Modelo espiral
Trata-se de um modelo que busca reunir características dos demais modelos 
de ciclos de vida tradicionais, considera também a criação de protótipos e a 
execução por fases bem definidas. 
Sua principal diferença em relação ao modelo cascata é que o modelo espiral 
acrescenta ao cascata uma análise criteriosa de riscos ao início de cada etapa, 
beneficiando-se, assim, da principal característica do modelo prototipação, 
a criação de protótipos.
Pelo fato de unificar características dos demais modelos, o modelo espiral 
também tem vantagens e desvantagens quanto aos outros, pois apresenta 
requisitos e etapas bem definidos, mas com um alto custo de execução, por 
considerar diversas prototipações, uma para cada fase percorrida.
Criado por Barry Boehm em 1988, o modelo espiral é uma melhoria do mo-
delo incremental e teve seu nome cunhado em virtude de sua representação, 
em que cada volta no espiral percorre todas as fases do processo de software 
(DIAS, 2019). De acordo com Pressman (2011) e Boehm e Hansen (2001), 
o modelo espiral de desenvolvimento é um gerador de modelos de processos 
dirigidos a riscos e utilizado para guiar a engenharia de sistemas com muito 
software, que ocorre de forma concorrente e tem vários envolvidos. Além disso, 
há duas características principais que o distinguem: a primeira consiste em 
uma estratégia cíclica voltada para ampliar, de modo incremental, o grau de 
definição e a implementação de um sistema, enquanto diminui o seu grau de 
risco; e a segunda reside no fato de dispor de uma série de marcos de pontos-
-âncora para garantir o comprometimento dos envolvidos quanto à busca de 
soluções de sistema mutuamente satisfatórias e viáveis. O modelo de ciclo 
de vida espiral (BOEHM, 1998 apud SCHACH, 2009) pode ser observado 
na Figura 3. 
5Conhecer os modelos tradicionais
Figura 3. Modelo espiral de Boehm.
Fonte: Adaptada de Boehm (2000).
Custo
acumulado
Avanço
nas etapas
Avaliar alternativas, identi�car
e minimizar os riscos
Análise
de riscosAnálise
de riscosAnálise
de riscos
Protótipo
2
Protótipo
1A
ná
lis
e
de
 ri
sc
os
Protótipo
3
Protótipo
operacional
Conceito de
operação
Plano de levantamento
de necessidades
Plano de ciclo
de vida
Divisão da
responsabilidade
Plano de
desenvolvimento
Revisão
Determinar
objetivos,
alternativas,
restriçõesValidação das
necessidades
Necessidades
de software
Projeto do
produto de
software
Projeto 
detalhado
Código
Teste
de uni-
dadesTeste de
integração
Teste de
aceitação
Implementação
Planejar próxima fase
Plano de
integração
e testes
Veri�cação e validação
do projeto
Desenvolver, veri�car
produto do próximo nível
Simulações, modelos e benchmarks
Na Figura 3, a dimensão radial representa o custo acumulado até o momento, 
e a dimensão angular o processo ao longo da espiral. Os ciclos correspondem 
às fases, em que uma fase se inicia (no quadrante superior esquerdo) concomi-
tantemente à determinação de seus objetivos, com alternativas para atingi-los 
e restrições impostas sobre eles. Na sequência, essa estratégia é analisada 
sob o ponto de vista de riscos, que passam por tentativas de minimização, 
construindo-se, em alguns casos, protótipos. Se os riscos não puderem ser mi-
nimizados, o projeto pode ser interrompido imediatamente; contudo, se forem 
minimizados com sucesso, a próxima etapa de desenvolvimento é iniciada 
(quadrante direito inferior, que corresponde ao modelo cascata clássico). Por 
fim, os resultados são avaliados e se planeja a fase seguinte (SCHACH, 2009). 
Conhecer os modelos tradicionais6
Pressman (2011) também aponta que, com o uso do modelo espiral, 
o software será desenvolvido em uma série de versões evolucionárias, que, 
nas primeiras, iterações poderão consistir em um modelo ou em um protótipo. 
Já nas iterações posteriores, são produzidas versões cada vez mais completas do 
sistema que passa pelo processo de engenharia. Ainda de acordo com o autor, 
o modelo espiral divide-se em um conjunto de atividades que representam um 
segmento do caminho espiral, no qual, assim que o processo evolucionário 
começa, a equipe de software realiza atividades indicadas por um circuito 
em torno da espiral, no sentido horário, iniciando pelo seu centro. Para tal, os 
riscos são levados em conta à medida que se realiza cada revolução. Por fim, 
o primeiro circuito em volta da espiral pode resultar no desenvolvimento de 
uma especificação de produto, enquanto as passagens subsequentes em torno 
da espiral podem ser usadas para desenvolver um protótipo e, então, progressi-
vamente, versões cada vez mais sofisticadas do software (PRESSMAN, 2011). 
A empresa Xpto tem trabalhado em um projeto com o objetivo desenvolver um 
sistema de um e-commerce. 
 � Caso opte por utilizar o modelo cascata, reunir-se-á com o cliente uma única vez, 
documentará os requisitos que o cliente solicitou e os apresentará para validação 
do cliente. Uma vez aceitos os requisitos, o e-commerce é criado e o cliente apenas 
o visualiza após todos os testes terem sido executados e o projeto encerrado.
 � Caso se opte pelo modelo prototipação, antes de iniciar o desenvolvimento, 
os profissionais criarão as telas do e-commerce e as mostrarão para o cliente. O cliente 
deverá interagir como se estivesse usando o software real, para, então, aprovar 
o desenvolvimento ou sugerir alterações.
 � No caso de utilizar o modelo espiral, será feito inicialmente o protótipo de uma tela 
de cadastro dos produtos, que será avaliada pelo cliente e, depois, desenvolvida. 
Em seguida, será feita uma tela para compras, também avaliada pelo cliente e, 
então, desenvolvida, e assim sucessivamente, prototipando cada parte do pro-
grama antes de ele ser desenvolvido. Além da prototipação, a cada etapa serão 
analisados os riscos possíveis em cada etapa, por exemplo, ter um estagiário que 
está se formando e que precisará deixar a equipe, uma mudança de versão de 
alguma tecnologia durante o processo, entre outros riscos previsíveis que, nesse 
modelo, são analisados previamente a cada ciclo.
7Conhecer os modelos tradicionais
BOEHM, B. Spiral development: experience, principles, and refinements spiral develop-
ment workshop. 2000. Disponível em: https://resources.sei.cmu.edu/library/asset-view.
cfm?assetid=5053. Acesso em: 08 jun. 2020.
BOEHM, B.; HANSEN, W. J. The spiral model as a tool for evolutionary software acquisition. 
2001. Disponível em: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.642.8
250&rep=rep1&type=pdf . Acesso em: 08 jun. 2020.
DIAS, R. P. O modelo em espiral de Boehm. 2019. Disponível em: https://medium.com/
contexto-delimitado/o-modelo-em-espiral-de-boehm-ed1d85b7df. Acesso em: 
08 jun. 2020.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 7. ed. Porto 
Alegre: AMGH, 2011.
SCHACH, S. R. Engenharia de software: os paradigmas clássico e orientado a objetos. 
Porto Alegre: AMGH, 2009.
Os links para sites da web fornecidos neste capítulo foram todos testados, e seu fun-
cionamento foi comprovado no momento da publicação do material. No entanto, a 
rede é extremamente dinâmica; suas páginas estão constantemente mudando de 
local e conteúdo. Assim, os editores declaram não ter qualquer responsabilidade 
sobre qualidade, precisão ou integralidade das informações referidas em tais links.
Conhecer os modelos tradicionais8
ENGENHARIA 
DE SOFTWARE
Aline Zanin
Revisão técnica:
Jeferson Faleiro Leon
Desenvolvimento de Sistemas 
Especialista em Formação Pedagógica de Professores
Catalogação na publicação: Karin Lorien Menoncin CRB-10/2147
M827e Morais, Izabelly Soares de.
 Engenharia de software [recurso eletrônico] / Izabelly
 Soares de Morais, Aline Zanin ; revisão técnica : Jeferson
 Faleiro Leon. – Porto Alegre : SAGAH, 2017.
 
 ISBN 978-85-9502-253-9
 Engenharia. 2. Engenharia de software auxiliada por 
 computador. I. Zanin, Aline. II. Título.
 
CDU 004.41
Conhecer modelo 
incremental
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Relacionar os elementos dos modelos linear e prototipação com o
modelo incremental.
 � Identificar os incrementos.
 � Descrever o funcionamento, as vantagens e as desvantagens do
modelo incremental.
Introdução
No modelo incremental, o sistema é dividido em partes que são 
desenvolvidas e entregues de forma independente. Quando uma 
dessas partes é finalizada, ela é “incrementada” ao sistema, formando,
ao final, o sistema completo. Conhecer este modelo é muito interes-
sante, pois muitas empresas ainda o utilizam quando existe pouca mão 
de obra para implementar um software.
Neste capítulo, você vai adquirir conhecimentos fundamentais para 
avançar no aprendizado sobre o modelo incremental. Vamos abordar 
conceitos básicos sobre o modelo e as suas vantagens/desvantagens.
Como o modelo incremental se relaciona ou se 
diferencia dos modelos cascata e prototipação
Para falarmos do modelo incremental, vamos primeiramente instanciar a 
relação dele com os demais modelos que já foram ou serão estudados neste 
curso, ou seja, os modelos cascata (linear) e prototipação. 
O modelo incremental considera diversas entregas parciais do produto 
antes de uma entrega final, sendo esta a sua principal diferença em relação aos 
modelos prototipação e cascata. Nesses modelos, o ciclo de desenvolvimento é 
contínuo e o cliente recebe um entregável do produto solicitado apenas quando 
o todo for concluído, ou seja, quando percorridas as seguintes etapas: análise 
e definição de requisitos, projeto de sistema e de software, implementação e 
teste de unidades, integração e teste de sistemas, operação e manutenção e, 
ainda, a prototipação no modelo de prototipação. Já no modelo incremental, 
são intercaladas as atividades de especificação, desenvolvimento e valida-
ção. Neste sentido, o sistema é desenvolvido como uma série de versões 
(incrementos), de maneira que cada versão adiciona funcionalidade à anterior 
(SOMMERVILE, 2011).
Figura 1. Exemplo de incrementos de funcionalidades.
Fonte: Nepomuceno (2012).
Comunicação
Comunicação
Comunicação
Planejamento
Planejamento
Planejamento
Modelagem
Modelagem
Modelagem
Construção
Construção
ConstruçãoImplantação
Implantação
Implantação
Incremento 1
Incremento 2
Fu
n
ci
o
n
al
id
ad
e
s 
e
 c
ar
ac
te
rí
st
ic
as
 d
o
 P
ro
je
to
Tempo do Projeto
Entrega 1 - núcleo do
produto
Entrega 2
Entrega n
Incremento n
Identificar os incrementos
Como descrito anteriormente, o princípio fundamental do modelo incremental 
é a presença de ciclos de incrementos. Pode-se dizer que o modelo incremental 
une os modelos cascata e prototipação justamente por reunir características de 
Conhecer modelo incremental2
ambos. Desta forma, o princípio básico para a identificação de um incremento 
neste modelo é analisar as etapas do processo de desenvolvimento que estão 
sendo executadas. 
Um incremento sempre inicia no levantamento das necessidades ou dos 
requisitos, sendo que, se estiver sendo executado o início do processo de 
desenvolvimento, esse incremento irá iniciar pela conversa com o cliente 
e pela identificação das necessidades dele. Já no caso de um incremento 
que complementa ou é realizado para corrigir algo no software que está em 
desenvolvimento, inicia-se analisando aquilo que já foi programado e compa-
rando com o que foi solicitado pelo cliente. Em um processo ideal, o cliente 
participa do processo, analisando cada entrega ao final de um incremento e 
especificando o que espera do próximo incremento.
A empresa Xpto está desenvolvendo um site para divulgação de produtos atendidos por 
um determinado representante comercial. Em um primeiro momento, foi desenvolvida 
a página principal em que são exibidos os produtos. Ao analisar a página recebida, 
o cliente solicitou mudanças de layout. Sendo assim foi executado um incremento 
em que foi adicionado ao site as melhorias solicitadas. Já em um terceiro momento, 
foi incrementado ao site uma página “Fale Conosco”, para que o cliente possa solicitar 
o produto ao vendedor.
Vantagens e desvantagens do modelo 
incremental
A utilização deste modelo apresenta algumas vantagens para as empresas que 
optam por utilizá-lo. Todas as vantagens estão diretamente relacionadas com 
a estrutura de trabalho por incrementos. A seguir, listamos algumas dessas 
vantagens (IFSC, 2006):
 � Redução dos custos com manutenção do sistema: esta vantagem se ma-
nifesta uma vez que, quando acontecem problemas no desenvolvimento 
por erros técnicos ou por não entendimento dos requisitos do cliente, 
os problemas serão rapidamente identificados, dado que cada ciclo é 
executado de forma curta e completa.
3Conhecer modelo incremental
 � Melhor controle de cronograma: por estarem executando pequenos 
ciclos completos de desenvolvimento, as equipes têm maior certeza de 
que, ao chegar ao último ciclo o programa, atenderão o esperado pelo 
cliente e, assim, evitam problemas de cronograma ocasionados por 
mudanças ou correções inesperadas.
 � Maior probabilidade de atendimento dos requisitos do cliente: por estar 
realizando entregas contínuas e o cliente recebendo pequenas partes do 
produto solicitado, o cliente consegue ter uma melhor visão do produto 
que está sendo desenvolvido e, com isso, tem oportunidade de reportar 
quando os requisitos não estão sendo atendidos, desta forma, recebendo, 
ao final, um produto dentro do esperado.
Porém, como todos os processos, este modelo tem algumas desvantagens, 
dentre elas (IFSC, 2006):
 � dificuldade de gerenciamento: isso ocorre porque as fases de do ciclo 
podem estar ocorrendo de forma simultânea.
 � para que o projeto tenha sucesso, o cliente precisa estar disposto a 
prover feedbacks constantes.
 � a arquitetura do projeto precisa ser bem estruturada para que possa 
receber os incrementos quando solicitado.
 � o cliente precisa estar ciente de que é um processo incremental e que 
não estará recebendo, nas primeiras entregas, o software final. Por isso, 
pode não estar completo.
Você pode aprender mais assistindo um vídeo que ilustra 
o modelo incremental. (INFORMÁTICA, 2015) 
Veja em:
https://goo.gl/MWn9gy
Conhecer modelo incremental4
Para saber mais sobre este processo, você pode ver artigos interessantes, que estão 
disponíveis gratuitamente na Internet, utilizando o seu site de buscas preferido. Busque 
por “wiki edu ciclo de vida iterativo e incremental”. Com isso, você encontrará materiais 
bem interessantes sobre o assunto que está sendo estudado.
1. No primeiro incremento do modelo 
incremental, que tipo de solução é 
oferecido ao cliente? 
a) São oferecidos elementos 
do sistema que permitem a 
operação básica ao usuário.
b) É oferecido um sistema 
completo, com todas 
as funcionalidades.
c) São oferecidas partes do sistema 
que ainda apresentam erros.
d) É oferecido apenas um 
protótipo de telas para o 
cliente saber como o sistema 
será implementado.
e) Não é oferecido um sistema 
funcional, já que este modelo 
linear só oferece o produto 
ao final de todo o projeto.
2. O que é esperado do 
cliente ao término de cada 
incremento? 
a) Um manual de utilização 
do sistema.
b) Descarte do protótipo.
c) Uso exaustivo do sistema 
para encontrar erros.
d) Uso, avaliação e feedback 
sobre o sistema.
e) Pagamento pelo projeto.
3. No final do último incremento, o que 
é esperado na entrega? 
a) Apenas uma parte, um 
incremento ou uma 
funcionalidade básica do 
sistema que esteja em 
funcionamento e bem testado.
b) Um sistema parcialmente 
funcional.
c) Espera-se um sistema 
completo e funcional.
d) Espera-se que o cliente tenha 
as funcionalidades básicas 
do sistema funcionando 
bem e testadas, mas não 
funções complementares.
e) Espera-se um sistema que não 
atenda a nenhum dos requisitos.
4. Qual destas é uma vantagem do 
modelo incremental? 
a) Podem surgir problemas 
com a integração de cada 
entrega incremental.
b) Usuários podem solicitar 
modificações no sistema 
durante o desenvolvimento.
c) Os usuários podem ver um 
protótipo de tela antes do 
5Conhecer modelo incremental
ddsilva
Caixa de texto
desenvolvimento do sistema.
d) O sistema é entregue 
somente no final do projeto 
de forma integral.
e) O custo do projeto é 
sempre respeitado.
5. Qual destas opções é uma 
desvantagem do modelo 
incremental? 
a) O orçamento previsto do 
projeto pode ser ultrapassado.
b) O sistema é desenvolvido 
respeitando os prazos.
c) Redução de riscos de 
atraso da entrega.
d) As partes entregues 
durante os incrementos não 
oferecem integração.
e) O projeto é alinhado com as 
necessidades do cliente.
IFSC. Ciclo de Vida Iterativo e Incremental. Wiki Instituto Federal de Santa Catarina, 
São José, out. 2006. Disponível em: <https://wiki.sj.ifsc.edu.br/wiki/index.php/Ci-
clo_de_Vida_Iterativo_e_Incremental>. Acesso em: 31 ago. 2017.
INFORMÁTICA 2014 IFRS. Iterativo Incremental. YouTube, 2015. Disponível em: <https://
www.youtube.com/watch?v=A5xWN3i1aUE>. Acesso em: 15 set. 2017.
NEPOMUCENO, D. Modelos Incremental, Espiral e de Prototipação. Blog Engenharia 
de Software, Jequié, dez. 2012. Disponível em: <http://engenhariadesoftwareuesb.
blogspot.com.br/2012/12/blog-post.html/>. Acesso em: 27 ago. 2017.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
Conhecer modelo incremental6
ddsilva
Caixa de texto