Desenvolvimento incremental e iterativo

Eduardo Bezerra- eduardo.bezerra@uol.com.br

O desenvolvimento de um sistema de software envolve diversas fases onde, em cada
uma delas, diversas atividades so desenvolvidas. A um encadeamento especfico
dessas fases para construo do sistema d-se o nome de modelo de ciclo de vida de
desenvolvimento, ou simplesmente modelo de desenvolvimento. H diversos Modelos
de Ciclo de Vida. A diferena entre um e outro est na maneira como as diversas fases
so encadeadas. Neste artigo, dois modelos de desenvolvimento so descritos: o
modelo em cascata e o modelo incremental e iterativo.
O modelo em cascata
O modelo em cascata tambm chamado de clssico ou linear. O modelo em cascata
com certeza o mais conhecido dos modelo de desenvolvimento. Ele foi amplamente
usado pela comunidade de desenvolvimento de software at a dcada de 1980 e ainda
o .
Segundo a proposta inicial de Winston Royce (Royce, 1970), considerado o inventor
do modelo em cascata, este modelo se caracteriza por possuir uma tendncia na
progresso seqencial entre uma fase de desenvolvimento e a seguinte. No entanto,
essa proposta prev possveis retro-alimentaes de uma fase para a fase anterior
(vide Figura 1). Essas retro-alimentaes teriam o objetivo de consertar eventuais
inconsistncias em resultados produzidos em atividades anteriores.

Figura 1 Abordagem de desenvolvimento de software em cascata.
No entanto, com o decorrer do tempo, a proposta inicial de Royce foi sendo deturpada,
e a segunda caracterstica (retro-alimentao) relegada ao desuso. Por conseqncia,
o uso do modelo em cascata na prtica enfatizou a primeira caracterstica. Isso fez
com que as fases de desenvolvimento de um sistema de software seguissem de uma
forma quase estritamente seqencial (para a anlise comear, o levantamento de
requisitos de ter terminado; para a fase de projeto comear, a fase de anlise de ter
terminado, etc).
H diversos problemas associados a essa aplicao desvirtuada do modelo em cascata,
todos provenientes de sua caracterstica principal: a seqencialidade das fases na
construo do sistema como um todo. A seguir, vou descrever alguns desses
problemas. Voc deve notar no entanto que, quando falo em "modelo em cascata" nas
sees a seguir, estou fazendo referncia a essa forma deturpada de uso do modelo
em cascata original. O modelo proposto por Royce em 1970 na verdade guarda
grandes semelhanas com o segundo modelo que descreve aqui, o incremental e
iterativo.
No pensamos seqencialmente
Ns seres humanos temos srias dificuldades em lidar de uma s vez com sistemas
complexos (sejam eles computacionais ou no). No conseguimos construir sistemas
complexos de uma forma puramente seqencial. E essa exatamente uma das
principais caractersticas do modelo em cascata. Segundo essa caracterstica, as
atividades seguem de uma forma seqencial: aps a anlise chegar ao fim, a fase de
projeto tem incio; quando a fase de projeto termina, a fase de implementao tem
incio, etc.
Acontece que, para entendermos (e construirmos) sistemas complexos, ns no
adotamos uma estratgia seqencial, mas sim uma estratgia incremental e iterativa.
Para entender um sistema complexo, vamos entendendo suas partes gradativamente.
Para entendermos uma determinada parte do sistema, voltamos a essa parte vrias
vezes. Alm disso, o entendimento de uma das partes do sistema nos fornece a
possibilidade de melhor entendermos as demais partes.
Como um amigo meu costuma dizer, ns seres humanos entendemos o mundo atravs
de "cliques. Ou seja, no decorrer do estudo de algum assunto, h um momento em que
o conhecimento adquirido atravs deste estudo chega a um limiar tal que nos permite
dizer: "puxa, finalmente entendi isso!.
Mas esses "cliques s surgem depois de passarmos diversas vezes sobre o mesmo
aspecto do assunto em questo, a cada passada confirmando conceitos corretos
formados anteriormente ou reformulando conceitos formados incorretamente (ou seja,
aprendendo com nossos erros). Certamente tentar estabelecer uma seqencialidade
nesse processo de entendimento como um todo no factvel. O entendimento
acontece de forma incremental.
O desenvolvimento de sistemas de software, como tarefa complexa que , segue a
caracterstica de no seqencialidade que mencionei h pouco. Por exemplo, quando
estou trabalhando em alguma atividade da fase de projeto, posso detectar alguma
inconsistncia nos modelos de anlise. Essa inconsistncia revela um conceito incorreto
formado durante a anlise e que deve ser revisto. Vrios outros exemplos poderiam
ser dados em que uma atividade do desenvolvimento fornece o "clique que faltava em uma
atividade anterior.
Pensamos aos poucos
Quando nos deparamos com um problema complexo, tentamos dividi-lo em um grupo
de problemas menores. Fazemos isso com o objetivo de entendermos o problema
original aos poucos, subproblema aps subproblema. Se consideramos um problema
complexo de um s vez, a possibilidade de falharmos ou de cometermos erros na
soluo do problema bem maior.
Um bom processo de desenvolvimento deve fornecer a possibilidade de a equipe de
desenvolvimento "pensar aos poucos". Ou seja, esse processo deve permitir que o
sistema possa ser desenvolvido em incrementos para que, a cada incremento
construdo, possamos averiguar se cometemos erros na sua construo. Esse processo
deve tambm nos dizer que atividades devemos realizar durante a considerao de
cada subproblema.
Agora, leitor, considere o que acontece no modelo em cascata: uma verso de
produo do sistema de software no estar pronta at que o desenvolvimento chegue
ao final. Como as fases so realizadas seqencialmente, a implantao do sistema
pode ficar muito distanciada no tempo da fase inicial em que o sistema foi
encomendado. E se algum erro tiver sido cometido em alguma fase (por exemplo, na
anlise)? Isso perfeitamente possvel de acontecer, visto que seres humanos podem
cometer erros e, pelo menos por enquanto, so seres humanos que desenvolvem
sistemas de software. Nessa situao, recursos de vrias naturezas (tempo, dinheiro,
mo-de-obra, etc.) foram desperdiados na construo de uma funcionalidade cujo
erro somente ser detectado tarde demais.
As coisas mudam com o tempo
O levantamento de requisitos a etapa mais importante em termos de retorno em
investimentos feitos para um projeto de desenvolvimento. Muitos sistemas foram
abandonados ou nem chegaram a uso porque os membros da equipe no dispensaram
tempo suficiente para compreender as necessidades do cliente em relao ao novo
sistema. Em um estudo baseado em 6.700 sistemas feito em 1997, Carper Jones
mostrou que os custos resultantes da m realizao desta etapa de entendimento
podem chegar a 200 vezes o realmente necessrio (Jones, 1997). Veja a tabela a seguir,
que mostra a relao entre diversas fases do desenvolvimento e o custo relativo para
se realizar o reparo de um erro.
Fase do desenvolvimento Custo relativo de reparo
Requisitos 0,1 a 0,2
Anlise e projeto 0,5
Implementao 1
Testes 2 a 5
Manuteno 20
Um outro ponto importante sobre os requisitos sua caracterstica de volatilidade. Um
requisito voltil aquele que pode sofrer modificaes durante o desenvolvimento do
sistema. No modelo em cascata, comum a prtica de "congelar os requisitos
levantados antes de se iniciar a realizao das demais fases do desenvolvimento. Isto
, os requisitos considerados eram os mesmos do incio ao fim do projeto de
desenvolvimento.
Sistemas grandes em complexidade podem levar meses ou at anos para serem
desenvolvidos. Nesses tempos de grande concorrncia entre as empresas, difcil
pensar que o usurio espere pacientemente at que o sistema todo esteja pronto para
ser utilizado. Mesmo se isso acontecer, pode haver o risco de que o sistema j no
corresponda mais s reais necessidades de seus usurios, em virtude de os requisitos
terem mudado durante o tempo de desenvolvimento.
De fato, atualmente, a volatilidade dos requisitos um fato com o qual a equipe de
desenvolvimento tem de conviver. um fato da vida. Conseqentemente o
congelamento de requisitos impraticvel para organizaes que precisam se adaptar
a mudanas cada vez mais rapidamente.
A menos que o sistema a ser desenvolvido seja bastante simples e esttico
(caractersticas raras nos dias de hoje), praticamente impossvel pensar em todos os
detalhes a princpio. Alm disso, quando o sistema entrar em produo e os usurios
comearem a utiliz-lo, eles prprios descobriro requisitos nos quais no tinham
pensado inicialmente. Ou ento descobriro incoerncias entre o que eles
necessitavam e o que foi desenvolvido. Em resumo, os requisitos de um sistema
complexo inevitavelmente iro mudar durante o seu desenvolvimento.
Entretanto, o modelo em cascata assume que possvel
declarar detalhadamente todos os requisitos antes do incio
das demais fases do desenvolvimento. Se esta hiptese for
assumida, possvel que recursos sejam desperdiados na
construo de um requisito incorreto. Tal falha pode se
propagar por todas as fases do processo, s sendo detectada
quando o usurio comea a utilizar o sistema.
Precisamos pisar em terreno firme
Talvez o maior problema do modelo em cascata seja o fato de a sua aplicao no
desenvolvimento de um sistema de software no produzir informaes suficientes para
que o gerente do projeto possa mensurar o andamento do mesmo.
Quando estamos desenvolvendo um sistema, uma tarefa bem mais concreta estimar
o seu andamento a partir das funcionalidades j desenvolvidas (implementadas). Se j
se passaram 6 meses do incio do desenvolvimento e 25% das funcionalidades foram
implementadas, 24 meses uma estimativa razovel para o tempo total do projeto.
No entanto, o que dizer se, passados 6 meses, temos pginas e pginas de
documentao resultantes das fases de anlise e projeto? Nessa situao, fazer
qualquer estimativa para o trmino do projeto como pisar em areia movedia.
Simplesmente no possvel ao gerente realizar uma boa estimativa para o tempo de
implementao com base no tempo que se levou para preparar os documentos de
anlise e projeto. Quase posso ouvir esse gerente se lastimar: "Se ao menos houvesse
uma parte do sistema j implementada, testada e em uso, eu teria algo de concreto
para fazer as estimativas..."
Portanto, outra caracterstica importante em um processo de desenvolvimento que
ele permita a produo de informaes necessrias para a avaliao do andamento do
projeto. Certamente essa uma caracterstica na qual o modelo em cascata deixa a
desejar.
O modelo incremental e iterativo
Apesar de todos os seus problemas, o modelo em cascata (na sua forma deturpada)
vem sendo utilizado durante anos (juntamente com o paradigma de modelagem
estruturada). Ultimamente, devido complexidade cada vez maior dos sistemas, os
modelos mais utilizados para o desenvolvimento de sistemas complexos so os que
usam a abordagem incremental e iterativa.
O modelo incremental e iterativo foi proposto como uma resposta aos problemas
encontrados no modelo em cascata. Um processo de desenvolvimento segundo esse
modelo divide o desenvolvimento de software em iteraes . Em cada iterao, so
realizadas as atividades de anlise, projeto, implementao e testes para uma parte do
sistema. Esta caracterstica contrasta com o modelo em cascata, no qual as fases de
anlise, projeto, implementao e testes so realizadas uma nica vez para o sistema
como um todo.
Uma vez alocados os requisitos a uma iterao de desenvolvimento, estes requisitos
so analisados, projetados, implementados, testados e implantados. Na prxima
iterao, um outro subconjunto dos requisitos considerado para ser desenvolvido, o
que produz uma nova verso (ou incremento) do sistema que contm extenses e
refinamentos sobre a verso anterior. Desta forma, o desenvolvimento evolui em
verses, atravs da construo incremental e iterativa de novas funcionalidades at
que o sistema completo esteja construdo.
No
desenvolvimento
de sistemas de
software, a
existncia de
requisitos volteis
mais a regra do
que a exceo

Note que apenas uma parte dos requisitos considerada em cada iterao. Na
verdade, o modelo incremental e iterativo pode ser visto como a aplicao do modelo
em cascata vrias vezes: o software desenvolvido em incrementos, e cada
incremento desenvolvido segundo uma "mini-cascata" (vide Figura 2). (O modelo em
cascata tambm pode ser visto como o modelo incremental e iterativo no qual h
somente uma iterao.)

Figura 2 No desenvolvimento incremental e iterativo, cada iterao pode ser vista
como uma "mini-cascata".
Nas primeiras iteraes, uma verso mnima do sistema construda. Normalmente
essas primeiras iteraes ocorrem de uma forma seqencial, pois elas estabelecem a
arquitetura geral do software. Normalmente, essas primeiras iteraes podem fazer
maior uso de tcnicas de prototipagem. No entanto, uma vez que essa arquitetura est
estabelecida, algumas iteraes seguintes podem ser desenvolvidas em paralelo.
Para ser utilizado, o modelo incremental e iterativo requer um mecanismo para dividir
o conjunto de requisitos do sistema em subconjuntos disjuntos, e que cada
subconjunto seja alocado a uma iterao. Os fatores que devem ser considerados na
diviso dos requisitos so a prioridade (importncia do requisito para o cliente) e o
risco de cada requisito. Um mtodo de alocar os requisitos s iteraes de
desenvolvimento atravs dos casos de uso definidos para o sistema. Esse mtodo
denominado desenvolvimento dirigido a casos de uso. Pretendo tratar desse
assunto em um prximo artigo.
O modelo incremental e iterativo incentiva a participao
do usurio nas atividades de desenvolvimento. Isso
porque os usurios desde o incio do projeto j possuem
uma verso do sistema para utilizar. De fato, as verses
iniciais do sistema no contm a implementao de
todas a funcionalidades necessrias. Mas essa situao
muito melhor do que a situao em que o usurio recebe
o sistema todo de uma vez, somente no final do projeto,
conforme ocorre no modelo em cascata.
Vrios autores consideram que uma desvantagem do
modelo incremental e iterativo que o usurio pode se
entusiasmar excessivamente com a primeira verso do
sistema e pensar que tal verso j corresponde ao
sistema como um todo. Na minha opinio, isso no
No modelo
incremental e
iterativo, um sistema
de software
desenvolvido em
vrios passos
similares (iterativo). A
cada passo, o sistema
estendido com mais
funcionalidades
(incremental).

acontece na prtica. De qualquer forma, um fato que o modelo incremental e
iterativo incentiva a participao do usurio no processo de desenvolvimento atravs
do uso de verses desde o incio do desenvolvimento. E isso de longe compensa
qualquer falsa expectativa que este usurio possa ter sobre a verso inicial do sistema.
Uma outra vantagem desse modelo que os riscos do projeto podem ser melhor
gerenciados. Um risco de projeto a possibilidade de ocorrncia de algum evento que
cause prejuzo ao processo de desenvolvimento, juntamente com as conseqncias
desse prejuzo. O prejuzo pode incorrer na alterao de diversos parmetros do
desenvolvimento, como custos do projeto, cronograma, qualidade do sistema sendo
desenvolvido, satisfao do cliente, etc. Exemplos de riscos inerentes ao
desenvolvimento de software:
O projeto pode no satisfazer aos requisitos do usurio.
A verba do projeto pode acabar.
O sistema de software pode no ser adaptvel, manutenvel ou extensvel.
O sistema de software pode ser entregue ao usurio tarde demais.
Um consenso geral no desenvolvimento de software que os riscos de projeto no
podem ser eliminados por completo. Portanto, todo processo de desenvolvimento deve
levar em conta esses riscos.
No modelo incremental e iterativo, os requisitos mais arriscados so considerados
primeiramente. Visto que cada iterao gera um incremento do sistema que liberado
para o usurio, inconsistncias entre os requisitos e sua implementao se tornam
evidentes mais cedo no desenvolvimento. No modelo em cascata, o sistema como um
todo implantado de uma nica vez, e conseqentemente a correo dos erros
detectados aps a implantao bastante custosa. bem menos custoso corrigir os
erros cometidos em uma iterao e detectados quando a verso correspondente do
software comeou a ser utilizada. Isso evita a propagao de erros.
Se as inconsistncias detectadas em uma verso recm-liberada no so to graves,
elas so rapidamente removidas e uma nova verso do sistema entregue ao usurio.
Por outro lado, se as inconsistncias descobertas so graves e tm um impacto (risco)
grande no desenvolvimento do sistema, pelo menos a sua identificao torna possvel
reagir a elas mais cedo sem tantas conseqncias graves
para o projeto.
Ou seja, quanto mais cedo a equipe de desenvolvimento
considerar os requisitos mais arriscados, menor a
probabilidade de ocorrerem prejuzos devido a estes
requisitos. Para resumir todas essa histria sobre
gerenciamento de riscos, seja lembrar uma frase do
consultor Tom Gilb (Gilb, 1988): "Se voc no atacar os
riscos [do projeto] ativamente, ento estes iro ativamente
atacar voc."
Concluses
importante que voc note que as vantagens que descrevi
aqui sobre o modelo incremental e iterativo so reais, mas
esse modelo no uma panacia que pode curar todos os
problemas do desenvolvimento de software. Desenvolver software um tarefa
inerentemente complexa.
Primeiramente, o envolvimento mais estreito do usurio no processo de
desenvolvimento e o seu constante feedback em relao s verses que so liberadas
resultam em uma quantidade de trabalho significativa para fazer as alteraes e
correes necessrias. Assim, se o re-trabalho resultante dos requisitos em evoluo
Os requisitos a
serem
considerados
primeiramente
devem ser
selecionados com
base nos riscos
que eles fornecem.
Os requisitos mais
arriscados devem
ser considerados
to logo quanto
possvel.

(volteis) no for bem gerenciado, ele pode ser um fator de desacelerao do ritmo do
projeto.
Em segundo lugar, um fato que a utilizao do modelo incremental e iterativo torna
mais complicada a tarefa de gerenciamento das atividades do projeto. De fato,
gerenciar um desenvolvimento onde anlise, projeto, implementao, testes e
implantao podem ocorrer em paralelo (na caso de haver duas ou mais iteraes
ocorrendo ao mesmo tempo) de fato mais complicado do que gerenciar o
desenvolvimento de um sistema que utilize o modelo em cascata, onde as fases
ocorrem de forma seqencial.
No entanto, como compensao, o modelo incremental e iterativo permite a produo
de informaes concretas que o gerente de um projeto pode utilizar para avaliar o
andamento do desenvolvimento. Se uma verso produzida em um incremento tiver
erros, a equipe de desenvolvimento fica sabendo que a verso tem erros. A frase
anterior pode parecer redundante. Afinal de contas, quando uma verso de um
incremento liberada ao usurio, o uso da verso resulta na deteco de erros.
Mas no modelo em cascata, quando h um erro ou inconsistncia nos modelos de
anlise ou de projeto, eles so bem menos detectveis do que os erros de uma verso
produzida em uma iterao do modelo incremental e iterativo. E isso pelo simples fato
de que o usurio no usa modelos de software para realizar suas tarefas, e sim o
prprio software. "Em um pedao de papel, tudo funciona". J ouvi (e falei) essa frase
algumas vezes. E se esse erro ou inconsistncia que no foi detectado nos modelos
tiver tal importncia que comprometa toda a arquitetura do software? E se esse erro
ou inconsistncia s for detectado quando o sistema como um todo for entregue aos
usurios? Voc, gostaria de ser usurio desse software?
Conforme j falei anteriormente, construir software no tem nada de soft. Cada
projeto diferente. Os requisitos, as tecnologias necessrias e as pessoas envolvidas
so diferentes em cada um desses projetos. O que deu certo uma vez pode no dar
certo de outra. No entanto, o mais correto reconhecermos essas dificuldades e
imprevisibilidades e as encararmos de frente.
O avestruz um bicho excntrico em virtude de que, na presena de algum risco a sua
vida, ele enterra a cabea debaixo da terra. Ao desenvolvermos software complexo e
de requisitos volteis, estamos sujeitos a riscos impreterivelmente. Ao utilizarmos o
modelo em cascata, no entanto, estamos assumindo uma postura de avestruz:
fingimos que o risco no existe e esperamos para ver o que acontece. Ao utilizarmos o
modelo incremental e iterativo, reconhecemos os riscos como reais e tentamos atac-
los assim que ocorrem para que eles no se agravem mais ainda no futuro.
Para saber mais
Neste artigo, no menciono qualquer modelo de desenvolvimento em particular. Na
verdade, existem vrios modelos que se baseiam na abordagem incremental e
iterativa. Voc pode saber mais sobre essa abordagem, assim como obter detalhes
sobre cada modelo em particular a partir dos seguintes endereos : OPEN, RUP,
Scrum, XP.
Referncias
(Jones, 1997) Jones, Carper: Applied Software Measurement, 1997.
(Gilb, 1988) Gilb, T. e Susannah F.: Principles of Software Engineering
Management. Addison-Wesley, Wokingham, England, 1988.
(Royce, 1970) Royce, Winston W., "Managing the Development of Large
Software Systems," Proceedings, IEEE Wescon, Agosto 1970