1. A Evolução dos Processos de Desenvolvimento de
Software
Resumo
O desenvolvimento de software passou por sensível melhora com o
crescimento da Engenharia de Software. O primeiro processo formal
estabelecido foi o Cascata, que significou um salto qualitativo para o
desenvolvimento de software. Atualmente, há processos de desenvolvimento
de software melhores que o processo Cascata, mas este continua sendo o
mais utilizado, pois a mudança exige adaptações na forma de trabalho e na
cultura das empresas.
1. Engenharia de Software – Processos de Software
Mal o homem começou a produzir software, já se deparou com uma
série de problemas de qualidade e com uma demanda maior que a
capacidade produtiva. A solução foi introduzir conceitos de engenharia a esse
trabalho. Assim, consolidou-se a Engenharia de Software que, com a
introdução de metodologias e ferramentas, proporcionou condições para a
melhoria da qualidade do produto.Pela primeira vez, falou-se em um
processo de desenvolvimento de software.
No dicionário Michaelis, uma das definições de processo é “maneira de
operar, resolver”. Assim, processo de desenvolvimento de software é a
maneira como se produz software.
2. Processos Cascata
O primeiro processo criado foi o modelo Cascata (ou waterfall). Esse
processo estabeleceu um ciclo de vida básico para o desenvolvimento de um
software. Esse ciclo é formado por etapas que dividem o trabalho de

2. desenvolvimento de software em etapas claras, conforme demonstrado na
figura 1. Isso trouxe alguma organização para as equipes de desenvolvimento
e, também, para os usuários, que passaram a ter que definir melhor suas
solicitações, antes de ver iniciado o trabalho de codificação de programas.
O ciclo de vida Cascata é bastante utilizado atualmente e, apesar de ter
ajudado muito a organizar o desenvolvimento de software, traz consigo uma
série de problemas.
Figura 1: O ciclo de vida Cascata (PRESSMAN, 1995).
3. Problemas com o Ciclo de Vida cascata
O processo Cascata tem muitas qualidades, mas nem sempre é
possível aplicá-lo na íntegra, por vários motivos. O modelo tem algumas
desvantagens que serão discutidas a seguir. A maioria dos problemas está
ligada aos requisitos do software que se vai construir.
Segundo Pressman (1995), as principais críticas a esse modelo são:

3. a) Os projetos raramente seguem o fluxo seqüencial, gerando, por
vezes, iterações;
b) É muito difícil para o cliente declarar todas as suas necessidades
corretamente e de forma clara logo no início do projeto;
c) Decorre muito tempo entre o início do projeto e a disponibilização de
uma primeira versão minimamente utilizável do sistema (durante
esse período, os requisitos podem sofrer modificações ou mesmo
deixar de fazer sentido);
d) O risco de insucesso é alto, visto que, se um erro de grande impacto
for cometido e não detectado, provavelmente só será descoberto
muito tarde - o que pode ser desastroso para o projeto.
O ciclo Cascata presume que o projeto terá uma seqüência correta, sem
desvios e sem problemas. Nesse ponto, temos outra grande deficiência dele:
não considera riscos que podem impactar negativamente e até mesmo
inviabilizar o projeto.
3.1. Requisitos
Dos motivos destacados por Pressman, o maior foco está no tratamento
de requisitos.
Sobre isso, Sommerville (2003) destaca que os acordos com os clientes
devem ser feitos em um estágio inicial do processo de desenvolvimento em
que, geralmente, os requisitos são desconhecidos ou não são claros.
Quando esses requisitos são alterados posteriormente, causam impacto
negativo no produto de software, que deve ser refeito, ao menos em parte.
Assim, Sommerville aconselha a só utilizar esse modelo quando os requisitos
forem bem compreendidos.
Embora o ciclo de vida Cascata constitua uma abordagem melhor que a
abordagem casual (abordagem livre, antes da Engenharia de Software), a

4. forma altamente dinâmica como se desenvolve software exige um processo
mais ágil e dinâmico.
4. Ciclo de Vida Espiral
O Ciclo de Vida Espiral traz uma alternativa interessante a esse
problema, pois divide a tarefa de levantar requisitos em etapas que não
ocorrem todas de uma vez, no início do desenvolvimento.
O modelo Espiral mantém como princípio as mesmas etapas do modelo
Cascata. Porém, elas são executadas várias vezes ao longo do ciclo de
desenvolvimento do software (uma vez para cada pacote de
desenvolvimento). A figura 2 ilustra essas etapas. O centro da figura assinala
o início do desenvolvimento. À medida que o desenvolvimento ocorre,
caminha-se, na espiral, para sua parte mais externa, passando pelas
disciplinas de desenvolvimento várias vezes.
O efeito dessa forma de trabalho são entregas parciais de software para
o cliente, em vez de uma entrega única ao final do processo.

5. Figura 2 – Ciclo de Vida Espiral (SOMMERVILLE, 2003).
Essa divisão do desenvolvimento em pequenos pacotes, como se
fossem subprojetos, é uma boa alternativa ao problema com requisitos, que
são tratados (capturados, especificados e validados) em vários estágios e
não em um estágio único, permitindo revisões do usuário à medida que o
desenvolvimento avança. Certamente, é mais fácil para todos vislumbrar os
requisitos à medida que o projeto ganha maturidade.
Nesse modelo, não é necessário detalhar todos os requisitos no início
do desenvolvimento. São identificados os pontos principais e separados em
pacotes de trabalho. Após a priorização dos pacotes, apenas o primeiro será
detalhado e desenvolvido. Após a entrega deste, os próximos, um por vez,
terão seus requisitos detalhados e serão desenvolvidos.
O candidato mais forte a primeiro pacote a ser desenvolvido é aquele
que contém a funcionalidade principal do sistema com seus cadastros
básicos. Por exemplo, em um sistema de informações comerciais, a essência

6. é registrar o pedido do cliente. Consultas, relatórios, cálculos estatísticos e
contabilizações, ficam para um momento posterior.
Isso tem uma lógica: se o primeiro pacote tiver sucesso, os demais que
dependem dele terão grandes chances de serem bem sucedidos, pois partem
de uma base sólida. Se esse primeiro pacote não estiver bom o suficiente, é
possível corrigi-lo e aperfeiçoá-lo antes de iniciar o desenvolvimento dos
demais (caso contrário, os problemas com ele seriam propagados para os
demais pacotes do sistema e, muitas vezes, podendo potencializar os
problemas).
5. Ciclo de Vida Iterativo-Incremental
O modelo Espiral surgiu na década de 80. Outros processos foram
criados baseados nele. O mais famoso é o Processo Unificado, desenvolvido
após 1995, com a junção do Processo Objectory com a abordagem da
Rational. O Processo Unificado é mais recente e teve mais penetração no
mercado que o próprio modelo Espiral.
O Processo Unificado é o típico modelo Iterativo-Incremental.Iterativo
significa repetição (não confundir com INteração). Como o dicionário
Michaelis define, iteração significa “feito ou repetido muitas vezes”. Iterar é o
ato de fazer uma ou mais coisas repetidas vezes, como em um loop dentro
de um programa, em que um trecho de código é repetido várias vezes.
Os princípios do Modelo Iterativo são os mesmos do Modelo Espiral:
dividir o trabalho em pacotes de trabalho menores, ordenar por prioridades,
desenvolvendo e implantando um pacote por vez.
Quanto ao termo Incremental, como o software é entregue aos poucos
para o cliente, cada entrega significa aumento, ou incremento, em relação ao
cenário anterior.

7. O Processo Unificado é o mais famoso entre os Iterativo-Incrementais.
Esse processo de desenvolvimento de software divide seu trabalho em Fases
e Disciplinas, como em uma matriz.
A figura 3 demonstra as fases (no topo, na horizontal) e as disciplinas
(coluna à esquerda, na vertical) do processo Unificado.
FASES
Concepção Elaboração Construção Transição
D
I Requisitos
S
C Análise
I
P Design
L
I
Implementação
N
A
Testes
S
Iter. Iter. _ _ _ _ _ Iter. Iter.
#1 #2 #n-1 #n
Figura 3 – Processo Unificado, fases X disciplinas X trabalho realizado (JACOBSON, 1999).
5.1. Seqüência de trabalho do Processo Unificado
A primeira idéia de seqüência temporal é dada pelas fases que ocorrem
em seqüência, da esquerda para a direita.
Na figura 3, dentro da matriz, vemos áreas de trabalho assinaladas para
cada disciplina. Por exemplo, na disciplina de Requerimentos, o trabalho
começa na fase de Concepção, tem seu auge entre essa fase e a de
Elaboração, reduzindo muito na fase de Construção e ficando ausente na
fase de Transição. Isso indica que a disciplina de Requerimentos, mesmo
com o desenvolvimento sendo dividido em pacotes, tem mais presença no
início que no final de um projeto de software.
A figura 3 indica como está distribuído o trabalho das demais disciplinas.

8. 5.2. Fases X Iterações
O trabalho de desenvolvimento é executado dentro de cada fase. Assim,
quando estamos na fase de Concepção, passamos por todas as disciplinas
(descendo na vertical), algumas com mais ênfase e outras com menos.
Há uma “segunda rodada” de trabalho (outra iteração), ainda dentro da
fase de Concepção - o que caracteriza a segunda Iteração.
O foco principal de cada fase vem, justamente, da disciplina que tem
mais trabalho concentrado ali. Assim, para as fases abaixo, destacam-se as
seguintes disciplinas (como observado na figura 3):
- Concepção - requisitos do sistema;
- Elaboração - análise e design do sistema;
- Construção - implementação em linguagem de programação;
- Transição - testes, implantação e documentação do software.
O gráfico do Processo Unificado exibido na figura 3 traz uma sugestão
de iterações por fase, mas há de se destacar que esse número não é
absoluto. Dependendo do porte e complexidade do projeto, a quantidade de
iterações dentro de cada fase pode aumentar ou diminuir. Em um projeto
muito pequeno, por exemplo, as fases de Concepção e de Elaboração podem
constituir uma única iteração. Já em um projeto muito grande ou complexo, a
fase de Construção poderia ter cinco iterações.

9. :Ciclo
Iniciação Elaboração Construção Transição
:Fase :Fase :Fase :Fase
Model agem de
Negócio:Disciplina
Requisito:Disciplina
Análise e Projeto
:Disciplina
Implementação
:Disciplina
Teste:Disciplina
Implantação:Disciplina
Figura 4 – distribuição do esforço: fases X disciplinas no modelo Iterativo (ALHIR, 2002).
A figura 4 demonstra a seqüência do esforço em um projeto por meio de
fases e disciplinas. As setas na vertical indicam a seqüência. Uma fase é
executada quando a anterior é concluída.
O objetivo é entregar pacotes de software mais constantemente para os
usuários, não acumulando toda a entrega para o final.

10. 6. Principais diferenças entre Cascata e Iterativo
Uma comparação entre os processos de desenvolvimento de software
Cascata e os Iterativo-Incrementais está demonstrada na Tabela 1:
Característica Processo Cascata Processo Iterativo
Só passamos para a Passamos pela fase várias
Indivisibilidade próxima fase após vezes, o que permite
das Fases concluirmos 100% da fase refinamento incremental dos
atual. artefatos e do sistema.
Pode progredir para frente ou
para trás por meio das fases,
Fluxo de Há progresso serial por
para mudar o foco e envolver
Trabalho meio das disciplinas.
várias disciplinas, a fim de
endereçar o risco.
Não oferece Oferece oportunidades claras
oportunidades claras para para entregas parciais de um
entregas parciais de um sistema ao final de uma
Reação às sistema ou para a iteração, permitindo a
Mudanças introdução de mudanças introdução de mudanças no
dentro do ciclo de vida. É, ciclo de vida ao final de uma
portanto, reativa a iteração e antes da próxima. É,
mudanças. portanto, proativa a mudanças.
Tabela 1 – Principais diferenças entre processo Cascata e Iterativo
7. Vantagens dos Processos Iterativos
O processo Iterativo, ao entregar pacotes de software com mais
constância para os usuários, possibilita que estes dêem feedback mais cedo

11. sobre o produto de software que receberam. No processo Cascata, esse
feedback só aconteceria tardiamente, quando os usuários tivessem contato
com o software, ou seja, de maneira parcial, na fase de testes, e, total, na
entrega final.
Essa característica confere uma série de vantagens ao processo
Iterativo sobre o Processo Cascata. São elas:
• Antecipa mudanças;
• Controla riscos;
• Foca o desenvolvimento no produto do cliente;
• Aumenta a qualidade do produto final.
71. Antecipa Mudanças
Se há um erro no projeto, quanto antes ele for descoberto e corrigido,
menor será o impacto e menor será o custo para a correção necessária.
Corrigir um erro significa, em geral, refazer uma parte ou todo o trabalho até
aquele ponto, ou seja, gera retrabalho e, conseqüentemente, mais custo para
o projeto.
Custo de Alteração em um processo de software
Custo
Tempo
Figura 5 – Custo das Mudanças ao longo do Ciclo de Desenvolvimento.
Quanto mais tardia a correção for disparada, maior será o retrabalho e,
inevitavelmente, maior o custo da correção. A figura 5 mostra um esboço do

12. aumento do custo para se efetuarem alterações no software ao longo do
tempo em que o sistema está sendo desenvolvido.
As mudanças devem vir o quanto antes no projeto. Em um processo
Iterativo, a captura dos requerimentos é feita parcialmente, a cada iteração. É
comum que os clientes solicitem alterações ou inspirem-se com novas idéias,
quando se entregam versões de software (ainda que reduzidas). No momento
em que o usuário recebe parte da solução, começa a vislumbrar algumas
funcionalidades que não havia considerado anteriormente.
Assim, conforme Kroll, 2001, devem-se encorajar as mudanças, pois
a abordagem iterativa foi otimizada exatamente para isso. Entretanto, essas
transformações devem ser gerenciadas para que aconteçam no tempo
adequado.
7.2. Controla Riscos
Ao desenvolver um projeto de software, a preocupação com os riscos
deve ser constante. Risco é tudo aquilo que pode atrapalhar o
desenvolvimento de um projeto ou, até mesmo, levar a seu cancelamento. A
ocorrência de um risco pode atrasar o projeto, aumentar seu custo, alterar a
qualidade do produto final.
Assim, é necessário atacar os riscos antes que eles possam, de alguma
forma, com intensidade maior ou menor, impactar o projeto. Se seguirmos
com o projeto sem avaliar e endereçar seus riscos, podemos estar investindo
em esforços que podem não nos trazer o retorno esperado.
O modelo Cascata não trata os riscos diretamente. No modelo Iterativo,
como temos iterações, ou seja, fases repetitivas, os riscos do projeto são
avaliados a cada nova iteração. Ainda, o fato de termos entregas parciais
ajuda na redução do risco, pois, uma vez que o módulo ou parte do software
é aprovado e instalado, deixa de haver o risco de rejeição.

13. A figura 6 mostra dois gráficos comparando a redução do risco ao longo
do processo de desenvolvimento para os modelos Cascata e Iterativo.
Desenvolvimento Cascata
Cascata X Iterativo
Figura 6 – Risco do projeto ao longo do ciclo de desenvolvimento (RUP, 2000).
No Ciclo de Vida Cascata, não se pode verificar se um risco está claro
até um ponto tardio do Ciclo de Vida. Assim, no primeiro gráfico da figura 6, o
risco só começa a cair quando se chega à fase de testes do sistema.

14. Já no segundo gráfico da figura 6, a curva de riscos do Cascata está
comparada com a curva do Ciclo de Vida Iterativo, que mostra queda do risco
bem mais acentuada que no processo Cascata, devido às entregas parciais e
às constantes reavaliações da lista de riscos do projeto.
As entregas parciais de funcionalidades permitem o feedback dos
usuários e as correções, se houver. Isso aumenta a chance de sucesso do
projeto.
No processo Iterativo, a cada iteração, deve-se fazer uma pausa e
considerar quais são os riscos envolvidos naquele momento e nas etapas
seguintes. Quanto mais se antecipam os riscos, menor a chance de sua
ocorrência.
Nesse processo, podemos selecionar qual incremento desenvolver em
uma iteração a partir de uma lista de riscos-chave. Como cada iteração
produz um executável testável, é possível verificar se o risco foi mitigado ou
não, e se ele foi ou não bem aceito pelo cliente.
Os riscos são mais bem tratados no processo Iterativo, pois são revistos
a cada iteração.
7.3. Foca o desenvolvimento no produto do cliente
Em um projeto de desenvolvimento, além do produto final entregue aos
clientes, é comum a produção de artefatos intermediários. Cada processo de
desenvolvimento de software sugere seus próprios artefatos, mas,
geralmente, não mudam, de forma radical, de um processo para outro.
A idéia, aqui, é gerar o menor número possível de artefatos
intermediários, ou seja, direcionar o máximo de esforço para o artefato
principal: o produto de software que será entregue ao usuário.
Alguns artefatos podem ser estrategicamente indispensáveis durante o
desenvolvimento de um projeto, mas, “para qualquer projeto, devemos nos

15. esforçar para reduzir o número de artefatos produzidos a fim de reduzir o
desperdício”. (KROLL, 2001).
Focar os esforços no produto final reduz o desperdício do projeto. O
foco no software executável, conforme Kent Beck (2000) é a melhor forma de
verificar como está o andamento do projeto e de se manter concentrado em
entregar ao cliente o que realmente ele necessita, direcionando menos
esforço para outras atividades acessórias.
7.4. Aumenta a qualidade do produto final
Se, de um lado, as mudanças podem ser um obstáculo para os que
desenvolvem e para os que controlam prazo e orçamento do projeto, elas
podem também indicar que o produto de software está passando por ajustes
e vai, paulatinamente, aproximando-se da solução ideal para o cliente. É uma
outra forma de olhar para as mudanças em um projeto de software.
Mudanças permitem melhorar a solução de software. É importante
entender que as mudanças fazem parte de um projeto de desenvolvimento
(raramente um projeto tem todos os requerimentos, análise e design sem
mudanças ao longo do Ciclo de Vida do Desenvolvimento).
8. Por que o processo Cascata é o mais utilizado
Se os modelos iterativos, como o Processo Unificado, são melhores que
o processo Cascata, então por que este é, ainda, o mais utilizado?
Certamente, o primeiro motivo é porque é muito mais fácil para os que
desenvolvem e para os que usam entenderem a seqüência do modelo
Cascata do que a dinâmica dos modelos Iterativos.

16. Além disso, a aplicação de modelos espirais exige treinamento e
mudança cultural. Deve haver sinergia muito maior entre os que usam e os
que desenvolvem do que se costuma ter (o processo Cascata também exige
isso, mas, no modelo Iterativo, é essencial). Para utilização de um processo
iterativo, os usuários devem ter grande confiança naqueles que desenvolvem,
a comunicação deve ser intensa e o projeto deve ter uma gerência capaz de
controlar as características de um projeto iterativo (essa gerência, por si só, é
um capítulo à parte).
Se a gerência do projeto não for adequada, corre-se o risco de perder o
foco das iterações, gerando-se iterações desnecessárias, em nome do
refinamento incremental -o que prolongaria, em demasia, o projeto e, aí sim,
consumiria muito mais tempo e orçamento do que o planejado.
No processo Iterativo, é importante não perder o foco do trabalho a
realizar. Aumentos de escopo devem ser tratados e aprovados devidamente,
aliados com os ajustes nas previsões de custo e prazo.
Todavia, o fator cultural é ainda o preponderante. A inércia dos
processos instalados nas empresas traz resistência às mudanças. O conceito
popularmente conhecido como “eu sempre fiz desse jeito” mostra o quanto é
difícil convencer alguém a mudar. Nesses casos, a mudança cultural deve vir
de cima, patrocinada pelo alto escalão da empresa, que deve ser convencido
de que o novo modo de trabalho é vantajoso.
Conclusão
Apesar de suas deficiências, o modelo Cascata é de fácil compreensão
para os que usam e para os que desenvolvem e, se for bem trabalhado, pode
trazer, ainda, resultados muito satisfatórios para a empresa.
Mesmo com tantas vantagens, os modelos Iterativos não permitem
aplicação imediata sem treinamento e aculturação prévios. Deve haver
grande entrosamento das partes envolvidas e é necessário que esteja muito

17. claro para todos a nova forma de trabalho. Se isso não estiver bem
entendido, o projeto tende ao fracasso. Nesse caso, é melhor a utilização do
tradicional processo Cascata.
Considerado esse panorama, vale a pena aprofundar o conhecimento
sobre os processos iterativos, investindo tempo para conhecê-lo e empregá-
lo em projetos-piloto, visto que suas vantagens são bastante consideráveis.