1

ESCOLA SUPERIOR ABERTA DO BRASIL – ESAB

DESENVOLVIMENTO DE SOFTWARE: Análise Comparativa dos Modelos

Sequencial, Iterativo e Incremental, Espiral e Prototipação

Cláudio César Sardinha do Amaral1

Resumo

Este estudo teve o objetivo de analisar comparativamente os modelos de processo de software

sequencial, iterativo e incremental, espiral e de prototipação. Dentre os autores pesquisados
para a constituição conceitual deste trabalho, destacaram-se Sommerville (2011), Pressman
(2002), Bezerra (2002), Pfleeger (2004) e Wazlawick (2013). A metodologia utilizada foi a
pesquisa exploratória, tendo como coleta de dados o levantamento bibliográfico. As
conclusões mais relevantes são: 1) existe um modelo mais adequado para cada tipo de projeto;
2) a causa mais comum dos fracassos na engenharia de software está relacionada com a
dificuldade de se especificar os requisitos.

Palavras-chave: Engenharia de Software. Modelo de Processo. Análise Comparativa.

1 Introdução

Desde que a engenharia de software surgiu, muitos modelos de processos de software

foram propostos para trazer ordem ao caos existente na área de desenvolvimento de software
e aumentar a quantidade de projetos bem-sucedidos (PRESSMAN, 2002). Cada modelo, por
sua vez, tenta solucionar as deficiências dos modelos precedentes, prescrevendo novas
abordagens, técnicas e atividades (WAZLAWICK, 2013). Entretanto, porque cada projeto de
software tem suas peculiaridades, nenhum modelo pode ser aplicável em todas as situações.
Por exemplo, um modelo usado em um projeto para desenvolver um site de comércio
eletrônico na Internet pode não ser adequado em um projeto de software para um componente
de uma aeronave (PRESSMAN, 2002).
O assunto “Modelos de processos de software” é discutido amplamente nos livros de
autores renomados da engenharia de software, como Pressman (2002, p. 24) e Sommerville
(2011, p. 19). Neste trabalho, porém, foi delimitado pela seguinte questão: “Quais são as
características básicas, as vantagens e as desvantagens dos modelos sequencial, iterativo e
incremental, espiral e prototipação e em que situações esses modelos devem ser aplicados?”.

1
Pós-graduando em Engenharia de Sistemas na Escola Superior Aberta do Brasil – ESAB.
claudio.amaral@stf.jus.br.
 2

O objetivo geral da pesquisa foi analisar comparativamente esses modelos e destacar

suas vantagens, desvantagens e aplicabilidade.
Esse tema foi escolhido porque os problemas ainda continuam, isto é, a taxa de
fracassos nos projetos de software ainda é alta (PRESSMAN, 2002) e porque uma das razões
pode estar relacionada com a escolha incorreta do modelo de processo de desenvolvimento de
software (SOMMERVILLE, 2011). Para fazer a escolha certa, é de suma importância
conhecê-los bem (PETERS; PEDRYCZ, 2001). Por isso, a análise comparativa das
vantagens, desvantagens e da aplicabilidade desses modelos ajudará engenheiros de software
e gerentes de projetos, principalmente os recém-formados, a serem mais bem-sucedidos.
A metodologia adotada para este artigo foi a pesquisa exploratória com coleta de
dados por meio da pesquisa bibliográfica.

2 Desenvolvimento

2.1 Visão geral da engenharia de software

A engenharia de software surgiu com os computadores, mas só começou a receber a

devida atenção algumas décadas depois, quando os prejuízos causados pelos fracassos nos
projetos de software começaram a incomodar (PRESSMAN, 2002). Até o final da década de
60, o desenvolvimento de software era bastante artesanal, isto é, não seguia nenhuma
metodologia ou processo predefinido (WAZLAWICK, 2013). Por causa disso, eram comuns
atrasos e custos elevados nos projetos. O software desenvolvido costumava apresentar muitas
características indesejáveis, tais como: baixa confiabilidade, desempenho insatisfatório e
difícil manutenção (PRESSMAN, 2002).
Segundo Sommerville (2003, p. 4), “essa experiência inicial na construção de sistemas
mostrou que o desenvolvimento informal não era suficiente. Novas técnicas e métodos eram
necessários para controlar a complexidade inerente aos grandes sistemas de software”.
Passaram-se 50 anos desde que a “crise do software” foi discutida, muitas
metodologias foram propostas para resolver os problemas, mas, “apesar de alguns sucessos
espetaculares e da aceitação geral do software como parte da vida diária, ainda há muito o que
aprimorar na qualidade do software que produzimos” (PFLEEGER, 2004, p. 6).
Antes de começar a discutir essa questão, entretanto, é necessário rever alguns
conceitos básicos: o que é software, engenharia de software, ciência da computação,
engenharia de sistemas? O que é processo de software? O que é modelo de processo de
software?
 3

Pressman (2002, p. 6) fornece a seguinte definição formal para software:

Softwares são (1) instruções (programas de computadores) que quando executadas

fornecem a função e o desempenho desejados, (2) estruturas de dados que permitem
aos programas manipular adequadamente a informação e (3) documentos que
descrevem a operação e o uso dos programas.

Mais informal, Sommerville (2011) explica que um sistema de software é o conjunto

de programas, arquivos de configuração e a documentação do sistema. Os programas são as
instruções que serão executadas quando o software estiver em funcionamento; os arquivos de
configuração serão utilizados pelos programas; a documentação do sistema descreve como o
sistema está estruturado e ensina como deve ser operado.
Existem muitas definições para engenharia de software. Para o Instituto de
Engenheiros Eletricistas e Eletrônicos (IEEE, 1990, p. 67), é a “aplicação de uma abordagem
sistemática, disciplinada e quantificável ao desenvolvimento, operação e manutenção do
software”. Para Sommerville (2011, p. 4), “é uma disciplina de engenharia que se preocupa
com todos os aspectos de produção de software”. E para Pressman (2002, p. 19), “é a análise,
o projeto, a construção, a verificação e a gestão” de um elemento chamado software.
É importante não confundir engenharia de software com engenharia de sistemas ou
com ciência da computação. As três áreas estão relacionadas, mas têm objetivos bem
diferentes. Engenharia de software se ocupa com os problemas práticos da produção de
software (análise, projeto e construção de software). Ciência da computação é responsável por
desenvolver teorias e métodos que sustentam os sistemas computacionais. Já engenharia de
sistemas foca no desenvolvimento de sistemas complexos que incluem hardware, software,
políticas e processos de implantação de sistemas. Engenharia de software é, portanto, uma
subárea da engenharia de sistemas. (SOMMERVILLE, 2011).
Processo de software é, segundo Pressman (2002), uma série de passos que se seguem
para criar um produto de software dentro do tempo, custo e qualidade combinados.
Sommerville (2011) acrescenta ainda que alguns desses passos são comuns a todos os
processos de software: a especificação, o desenvolvimento, a validação e a evolução do
software. Durante a especificação, os engenheiros definem o quê será produzido e as
restrições; na fase de desenvolvimento, o software é projetado e codificado; na validação,
verifica-se se atende ao que o cliente deseja; e na evolução, o software é modificado para se
ajustar às mudanças necessárias.
 4

Modelo de processo, que também é conhecido como ciclo de vida do software ou

paradigma da engenharia de software, é uma representação de um esqueleto de processo que
inclui atividades, ordem de precedência e artefatos, sem descrever um curso de ação preciso,
os recursos, os procedimentos e as restrições para o desenvolvimento do software. Em outras
palavras, um modelo de processo descreve uma filosofia de organização das atividades, como
as atividades estão estruturadas em fases e como as fases estão relacionadas, mas sem entrar
em muitos detalhes. Por isso, não é suficiente para guiar um projeto na prática
(SOMMERVILLE, 2011).

2.2 Modelo sequencial

O modelo sequencial, documentado por Winston Royce em 1970, estabelece uma

abordagem sistemática linear para o desenvolvimento de software, que começa no nível de
sistema e avança através das fases de análise, projeto, codificação, testes e manutenção
(PRESSMAN, 2002). É base de quase todos os outros modelos propostos, pois é estruturado
com base na engenharia convencional (PFLEEGER, 2004). “Devido à forma com que se dá a
passagem de uma fase para outra, esse paradigma também é conhecido como cascata”
(CARVALHO; CHIOSSI, 2001).
Em cada fase, são produzidos documentos, chamados artefatos, que serão requisitos
para a fase posterior. Esses documentos são revisados ao final de cada fase e, se forem
aprovados, o projeto passará para a próxima fase. Se não forem aprovados durante a revisão, o
projeto permanecerá na mesma fase. O modelo é, portanto, dirigido por documentação, já que
é ela que determina se as fases foram concluídas ou não (WAZLAWICK, 2013).
Pressman (2002) agrupa as atividades do modelo em seis fases.
A primeira delas é a fase de modelagem e engenharia do sistema. Isto é necessário
porque todo software é parte de um sistema maior, que envolve pessoas, máquinas, recursos e
outros sistemas. Portanto, é necessário pensar no sistema como um todo e especificar os
requisitos para todos os elementos. Só depois dessa análise, pode-se alocar parte dos
requisitos levantados para o software que será desenvolvido.
A segunda fase é chamada de análise de requisitos. Nela, o foco é a especificação dos
requisitos para o software. Esses requisitos precisam ser documentados e aprovados antes de
avançar para a próxima fase.
 5

A terceira é a fase de projeto. Nessa fase, serão definidas as estruturas de dados, a

arquitetura do software, as representações da interface com o usuário e com outros sistemas,
além de um maior detalhamento das lógicas de processamento necessárias.
Na quarta fase, geração de código, todas as especificações produzidas nas fases
anteriores serão traduzidas para a linguagem de máquina.
Na fase de testes, a quinta, testes serão realizados com o objetivo de encontrar erros. O
software será executado para verificar tanto aspectos internos quanto externos, com dados
predefinidos para certificar-se de que produz os resultados esperados.
Na sexta e última, a fase de manutenção, o software passará por mudanças para
corrigir erros que não foram encontrados nas fases anteriores ou por causa de mudanças no
ambiente externo, isto é, novas exigências. Também poderá ser alterado para melhorar
funcionalidades já existentes ou melhorar o desempenho.
Cada uma das atividades do modelo cascata fornece um feedback para os
desenvolvedores das atividades anteriores, que estimula a melhoria e a evolução do software
(PETERS; PEDRYCZ, 2001).
O modelo contempla ainda uma atividade de revisão ao final de cada fase, de suma
importância, pois permite “encontrar e corrigir defeitos o mais cedo possível” (PFLEEGER,
2004, p. 7).
O modelo sequencial promove a estabilidade dos requisitos, facilitando a detecção de
erros logo no início do processo. Deve ser empregado quando o projeto possui requisitos bem
definidos e estáveis, quando a qualidade está acima de custo e prazo e também quando a
equipe de desenvolvimento é inexperiente (WAZLAWICK, 2013).
Por ser o mais antigo de todos, facilita a gerência de um conjunto fixo de documentos
predefinidos (PETERS; PEDRYCZ, 2001).
Nesse modelo, entretanto, o cliente precisa esperar até a fase de implantação para ver
como o software funciona (PETERS; PEDRYCZ, 2001). Também é difícil especificar
completamente os requisitos, desenvolvedores reclamam da capacidade dos usuários de
expressar os requisitos, muitos problemas só aparecem quando o produto entra em operação e
voltar atrás para corrigir problemas nos requisitos é trabalhoso (WAZLAWICK, 2013).

2.3 Modelo iterativo e incremental

O modelo iterativo e incremental foi proposto para resolver os problemas do modelo

cascata, principalmente os relacionados com o tempo de desenvolvimento (PFLEEGER,
 6

2004). Para conseguir atingir esse objetivo, o modelo fraciona o trabalho de desenvolvimento
em incrementos, que incorporam alguma funcionalidade necessária para o cliente
(SOMMERVILLE, 2011), considerando apenas parte dos requisitos em cada ciclo. Assim,
cada ciclo produz um incremento do sistema, refinando e estendendo o anterior. Decide-se o
que incluir em cada incremento pelo grau de importância e de risco para o projeto.
Segundo Bezerra (2002), o modelo iterativo e incremental pode ser visto como uma
generalização do modelo cascata, tendo em vista que cada incremento é desenvolvido
seguindo as fases de análise, projeto, codificação e testes.
De acordo com Pfleeger (2004), no desenvolvimento iterativo entrega-se um sistema
completo desde o começo e então se aprimora a funcionalidade de cada subsistema a cada
nova versão. E no desenvolvimento incremental, segundo Bezerra (2002), o sistema é
estendido com mais funcionalidades em versões cada vez mais completas até ficar pronto. As
duas abordagens são combinadas no modelo iterativo e incremental.
Considerando "que o custo de correção na fase inicial seja um décimo do custo para
corrigir um erro semelhante depois que o sistema já foi entregue", como ensina Pfleeger
(2004, p. 7), o modelo considera os requisitos mais arriscados primeiro para evidenciar mais
cedo os problemas e reduzir os custos de correção. Também se incentiva a participação do
usuário no processo de desenvolvimento para diminuir a probabilidade de interpretações
erradas dos requisitos (BEZERRA, 2002).
O modelo iterativo e incremental pode ser analisado a partir da dimensão temporal e
da dimensão de atividade. Na dimensão temporal, pode-se ver que o modelo está estruturado
em fases, cada fase pode passar uma ou mais iterações e cada iteração tem uma duração
preestabelecida. Ao final de cada iteração é produzido um incremento que é parte do sistema
final e que pode, ou não, ser liberado para os usuários. Na dimensão de atividade podem-se
ver as atividades realizadas em uma fase (levantamento de requisitos, análise, projeto,
implementação, testes e implantação), os artefatos que são produzidos ou estendidos
(documentação, executável) e o marco que sinaliza o fim da fase (BEZERRA, 2002).
O modelo iterativo e incremental apresenta diversas vantagens e desvantagens.
Quando comparado ao modelo em cascata, o custo de acomodar mudanças é reduzido;
é mais fácil obter feedback dos clientes; é possível realizar a entrega mais rápida
(SOMMERVILLE, 2011); incentiva a participação do usuário e riscos do desenvolvimento
podem ser mais bem gerenciados (BEZERRA, 2002).
 7

Mas é mais difícil de gerenciar (BEZERRA, 2002); a estrutura do sistema tende a se

degradar com a adição de novos incrementos (SOMMERVILLE, 2011) e problemas difíceis
tendem a ser deixados para o futuro (BEZERRA, 2002).

2.4 Modelo espiral

Em 1986, Barry W. Boehm propôs o modelo em espiral. Ele analisou o processo de

desenvolvimento e sugeriu que um modelo em espiral poderia combinar as atividades de
desenvolvimento e gerenciamento de risco (PFLEEGER, 2004).
Segundo Peters e Pedrycz (2001), o modelo em espiral parte do princípio de que a
forma do desenvolvimento de software não pode ser completamente determinada de antemão.
Por isso, prevê uma série de atividades para assumir um compromisso com um projeto
detalhado de sistema de software: prototipação, análise de riscos, simulação, modelagem,
análise financeira e benchmarks.
O modelo em espiral é um modelo evolucionário que organiza o desenvolvimento em
um processo que combina a natureza iterativa da prototipação com os aspectos controlados do
modelo sequencial. É uma abordagem realista para sistemas de grande porte, que permite que
se reaja aos riscos em cada nível evolucionário do software. O modelo usa a prototipação para
reduzir os riscos em qualquer estágio da evolução, mantém a abordagem do ciclo de vida
clássico incorporada numa estrutura iterativa, além de exigir a consideração direta dos riscos
antes que se tornem problemas. Ele adverte, entretanto, que pode ser difícil convencer os
clientes de que essa abordagem evolucionária é controlável (PRESSMAN, 2002).
Esse ciclo de vida se adéqua bem a projetos de pesquisa e desenvolvimento (P&D) e
jogos eletrônicos, onde os riscos são altos do ponto de vista tecnológico e os requisitos, pouco
conhecidos (WAZLAWICK, 2013).
Cada ciclo do modelo em espiral envolve definição de objetivos, alternativas e
restrições; análise de risco; desenvolvimento e validação e planejamento (CARVALHO;
CHIOSSI, 2001).
O modelo espiral apresenta vantagens significativas quando comparado aos outros
modelos. Nesse modelo, as primeiras iterações são as mais baratas e ao mesmo tempo são as
que resolvem os maiores problemas (WAZLAWICK, 2013), pois foca na redução dos riscos
antes que se tornem problemas (PRESSMAN, 2002). Assim, à medida que os custos
aumentam, o risco diminui e, se o projeto não puder ser concluído por razões técnicas, isso
 8

será descoberto cedo. Além disso, possui fases bem definidas, que permitem o
acompanhamento objetivo do desenvolvimento (WAZLAWICK, 2013).
O modelo exige, entretanto, competência na avaliação de riscos e depende dessa
competência para ter sucesso; é pouco utilizado (PRESSMAN, 2002); não fornece indicação
da quantidade de trabalho esperada a cada ciclo e aumenta a complexidade da gerência
(WAZLAWICK, 2013).

2.5 Prototipação

A prototipação pode ser a base de um modelo de processo efetivo (PFLEEGER, 2004)

sempre que o cliente tiver uma ideia geral do que precisa ser desenvolvido, mas não for capaz
de explicitar claramente os requisitos. Quando faltar detalhes de entrada, processamento e
saída para as funcionalidades, existir insegurança no momento de escolher um algoritmo ou
sistema operacional, houver dúvidas relacionadas com a forma de interação homem/máquina,
a prototipação pode ser a melhor abordagem (PRESSMAN, 2002).
O modelo de prototipação é próprio para desenvolver um produto que possa evoluir ao
longo do tempo (PRESSMAN, 2002). As atividades são organizadas em um fluxo que
começa com a definição de objetivos gerais, identificação de áreas que precisam de mais
definições e realização de um projeto rápido (protótipo), concentrando-se mais nos aspectos
visíveis do sistema (WAZLAWICK, 2013).
A cada iteração, o protótipo será usado para melhorar o entendimento das
necessidades do cliente e refinar os requisitos. Para criar rapidamente o protótipo, podem-se
utilizar geradores de código, relatórios e telas disponíveis no mercado.
Desenvolvedores e clientes gostam muito desse modelo, pois permite que se comece a
construir algo imediatamente. Mas a abordagem pode ser problemática por diversas razões: o
cliente vê o que parece ser uma versão executável, mas não vê que funciona precariamente,
nem a falta de qualidade ou manutenibilidade em longo prazo. O desenvolvedor pode fazer
concessões para conseguir rapidamente um protótipo executável e todos correrem o risco de
dar por terminado o trabalho. Por causa dessas concessões, um sistema operacional, uma
linguagem inapropriada ou até mesmo um algoritmo ineficiente pode acabar fazendo parte do
sistema final (PRESSMAN, 2002).
Segundo Pressman (2002), é um paradigma válido para a engenharia de software. Mas
é importante definir certas regras logo no início. Cliente e desenvolvedor devem concordar
 9

que o protótipo será construído para definir os requisitos e, depois, descartado e que um novo
software será submetido à engenharia a fim de buscar qualidade e manutenibilidade.
A prototipação ajuda na comunicação dos requisitos quando estes são difíceis de
explicitar e na especificação ou detalhamento dos requisitos quando isto não é possível sem
ver o software funcionando (WAZLAWICK, 2013). Usuários e desenvolvedores gostam
desse modelo, porque podem ter uma ideia prévia de como ficará o sistema e começam a
codificar imediatamente (PRESSMAN, 2002).
Como realizar mudanças em protótipos é mais fácil do que em sistemas completos, a
prototipação pode ser um meio eficiente de reduzir riscos nos projetos de software (PETERS;
PEDRYCZ, 2001).
Pressman (2002), por sua vez, lembra que existe o risco de liberar para a produção um
produto instável, já que a equipe pode ser pressionada a fazer ajustes no protótipo e liberá-lo
antes de garantir sua qualidade.
Na visão de Wazlawick (2013), esse modelo dificulta a previsão de término do projeto
e a gerência do processo, já que é difícil avaliar quando cada fase foi efetivamente concluída.

3 Conclusão

O objetivo geral da pesquisa foi analisar comparativamente os modelos de processos

sequencial, iterativo e incremental, espiral e de prototipação, destacando suas vantagens,
desvantagens e aplicabilidade.
Revendo os principais conceitos da engenharia de software e, mais detidamente, os
pontos fortes e fracos dos modelos de ciclo de vida, conclui-se que existe um modelo mais
adequado para cada tipo de projeto e que, para encontrar esse modelo ideal, é preciso
considerar as necessidades do projeto real em função das características de cada modelo.
Além disso, é possível combinar dois ou mais modelos em um único projeto para maximizar
suas chances de sucesso. Essa combinação é indicada nos projetos de grandes sistemas,
garantindo a entrega com qualidade, custo e prazo esperados.
Conclui-se também que a causa mais comum dos fracassos na engenharia de software
está relacionada diretamente com a dificuldade de se especificar corretamente os requisitos.
Por isso, a escolha do modelo de processo é de vital importância. Quando os requisitos
são claros e há mão de obra suficiente para atacá-los de uma vez, o modelo cascata é o mais
indicado. Se os requisitos são claros, mas não há mão de obra suficiente, então o modelo
iterativo e incremental é a escolha certa. Porém, se os requisitos não são claros, isto é, nem o
 10

cliente nem a equipe de desenvolvimento conhecem bem o domínio do problema, é melhor

optar por um modelo que permita construir um produto que possa evoluir com o passar do
tempo. Neste caso, a escolha ficará entre o modelo espiral ou o modelo de prototipação. Se o
engenheiro de software escolher bem, minimizará os riscos e conduzirá o projeto ao sucesso.
Caso contrário, poderá frustrar a equipe e levar o projeto ao fracasso.
Como proposta de trabalho futuro, sugere-se a realização de uma pesquisa para
comparar os modelos tradicionais com a metodologia ágil, buscando balancear a rigidez dos
modelos prescritivos com a flexibilidade dos métodos ágeis.

Referências

BEZERRA, E. Princípios de Análise e Projeto de Sistemas Com UML. São Paulo:

Campus. 2002.

CARVALHO, ARIADNE M. B. R.; CHIOSSI, THELMA C. S. Introdução à Engenharia

de Software. Campinas: Editora da UNICAMP, 2001.

IEEE. IEEE Standard Glossary of Software Engineering Terminology, Std 610.12-1990,

1990.

PETERS, JAMES F.; PEDRYCZ, WITOLD. Engenharia de Software: Teoria e Prática.

Rio de Janeiro: Campus, 2001.

PFLEEGER, S.L. Engenharia de Software: Teoria e Prática, 2. ed. São Paulo: Prentice
Hall, 2004.

PRESSMAN, R. S. Engenharia de Software: uma abordagem profissional. 5. ed. Rio de

Janeiro: McGraw-Hill, 2002.

SOMMERVILLE, I. Engenharia de Software. 6. ed. São Paulo: Pearson Addison Wesley,

2003.

SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall,

2011.

WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. Rio de Janeiro:

Elsevier, 2013.