A Evoluo dos Processos de Desenvolvimento de Software

Resumo O desenvolvimento de software passou por sensvel 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 mudana exige adaptaes na forma de trabalho e na cultura das empresas.

1. Engenharia de Software Processos de Software

Mal o homem comeou a produzir software, j se deparou com uma srie de problemas de qualidade e com uma demanda maior que a capacidade produtiva. A soluo foi introduzir conceitos de engenharia a esse trabalho. Assim, consolidou-se a Engenharia de Software que, com a introduo de metodologias e ferramentas, proporcionou condies para a melhoria da qualidade do produto.Pela primeira vez, falou-se em um processo de desenvolvimento de software. No dicionrio Michaelis, uma das definies 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 bsico para o desenvolvimento de um software. Esse ciclo formado por etapas que dividem o trabalho de

desenvolvimento de software em etapas claras, conforme demonstrado na figura 1. Isso trouxe alguma organizao para as equipes de desenvolvimento e, tambm, para os usurios, que passaram a ter que definir melhor suas solicitaes, antes de ver iniciado o trabalho de codificao 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 srie 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 possvel aplic-lo na ntegra, por vrios motivos. O modelo tem algumas desvantagens que sero discutidas a seguir. A maioria dos problemas est ligada aos requisitos do software que se vai construir. Segundo Pressman (1995), as principais crticas a esse modelo so:

a) Os projetos raramente seguem o fluxo seqencial, gerando, por vezes, iteraes; b) muito difcil para o cliente declarar todas as suas necessidades corretamente e de forma clara logo no incio do projeto; c) Decorre muito tempo entre o incio do projeto e a disponibilizao de uma primeira verso minimamente utilizvel do sistema (durante esse perodo, os requisitos podem sofrer modificaes ou mesmo deixar de fazer sentido); d) O risco de insucesso alto, visto que, se um erro de grande impacto for cometido e no detectado, provavelmente s ser descoberto muito tarde - o que pode ser desastroso para o projeto.

O ciclo Cascata presume que o projeto ter uma seqncia correta, sem desvios e sem problemas. Nesse ponto, temos outra grande deficincia dele: no 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 estgio inicial do processo de desenvolvimento em que, geralmente, os requisitos so desconhecidos ou no so claros. Quando esses requisitos so 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

forma altamente dinmica como se desenvolve software exige um processo mais gil e dinmico.

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 no ocorrem todas de uma vez, no incio do desenvolvimento. O modelo Espiral mantm como princpio as mesmas etapas do modelo Cascata. Porm, elas so executadas vrias 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 incio do desenvolvimento. medida que o desenvolvimento ocorre, caminha-se, na espiral, para sua parte mais externa, passando pelas disciplinas de desenvolvimento vrias vezes. O efeito dessa forma de trabalho so entregas parciais de software para o cliente, em vez de uma entrega nica ao final do processo.

Figura 2 Ciclo de Vida Espiral (SOMMERVILLE, 2003).

Essa diviso do desenvolvimento em pequenos pacotes, como se fossem subprojetos, uma boa alternativa ao problema com requisitos, que so tratados (capturados, especificados e validados) em vrios estgios e no em um estgio nico, permitindo revises do usurio medida que o desenvolvimento avana. Certamente, mais fcil para todos vislumbrar os requisitos medida que o projeto ganha maturidade. Nesse modelo, no necessrio detalhar todos os requisitos no incio do desenvolvimento. So identificados os pontos principais e separados em pacotes de trabalho. Aps a priorizao dos pacotes, apenas o primeiro ser detalhado e desenvolvido. Aps a entrega deste, os prximos, um por vez, tero seus requisitos detalhados e sero desenvolvidos. O candidato mais forte a primeiro pacote a ser desenvolvido aquele que contm a funcionalidade principal do sistema com seus cadastros bsicos. Por exemplo, em um sistema de informaes comerciais, a essncia

 registrar o pedido do cliente. Consultas, relatrios, clculos estatsticos e contabilizaes, ficam para um momento posterior. Isso tem uma lgica: se o primeiro pacote tiver sucesso, os demais que dependem dele tero grandes chances de serem bem sucedidos, pois partem de uma base slida. Se esse primeiro pacote no estiver bom o suficiente, possvel corrigi-lo e aperfeio-lo antes de iniciar o desenvolvimento dos demais (caso contrrio, 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 dcada de 80. Outros processos foram criados baseados nele. O mais famoso o Processo Unificado, desenvolvido aps 1995, com a juno do Processo Objectory com a abordagem da Rational. O Processo Unificado mais recente e teve mais penetrao no mercado que o prprio modelo Espiral. O Processo Unificado o tpico modelo Iterativo-Incremental.Iterativo significa repetio (no confundir com INterao). Como o dicionrio Michaelis define, iterao 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 cdigo repetido vrias vezes. Os princpios do Modelo Iterativo so 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 relao ao cenrio anterior.

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

Concepo Elaborao
D I S C I P L I N A S

Construo

Transio

Requisitos Anlise Design Implementao Testes

Iter. Iter. #1 #2 _ _ _ _ _ Iter. #n-1 Iter. #n

Figura 3 Processo Unificado, fases X disciplinas X trabalho realizado (JACOBSON, 1999).

5.1. Seqncia de trabalho do Processo Unificado

A primeira idia de seqncia temporal dada pelas fases que ocorrem em seqncia, 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 comea na fase de Concepo, tem seu auge entre essa fase e a de Elaborao, reduzindo muito na fase de Construo e ficando ausente na fase de Transio. Isso indica que a disciplina de Requerimentos, mesmo com o desenvolvimento sendo dividido em pacotes, tem mais presena no incio que no final de um projeto de software. A figura 3 indica como est distribudo o trabalho das demais disciplinas.

5.2. Fases X Iteraes

O trabalho de desenvolvimento executado dentro de cada fase. Assim, quando estamos na fase de Concepo, passamos por todas as disciplinas (descendo na vertical), algumas com mais nfase e outras com menos. H uma segunda rodada de trabalho (outra iterao), ainda dentro da fase de Concepo - o que caracteriza a segunda Iterao. 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): Concepo - requisitos do sistema; Elaborao - anlise e design do sistema; Construo - implementao em linguagem de programao; Transio - testes, implantao e documentao do software.

O grfico do Processo Unificado exibido na figura 3 traz uma sugesto de iteraes por fase, mas h de se destacar que esse nmero no absoluto. Dependendo do porte e complexidade do projeto, a quantidade de iteraes dentro de cada fase pode aumentar ou diminuir. Em um projeto muito pequeno, por exemplo, as fases de Concepo e de Elaborao podem constituir uma nica iterao. J em um projeto muito grande ou complexo, a fase de Construo poderia ter cinco iteraes.

:Ciclo Iniciao :Fase Elaborao :Fase Construo :Fase Transio :Fase

Model agem de Negcio:Disciplina

Requisito:Disciplina

Anlise e Projeto :Disciplina

Implementao :Disciplina

Teste:Disciplina

Implantao:Disciplina

Figura 4 distribuio do esforo: fases X disciplinas no modelo Iterativo (ALHIR, 2002).

A figura 4 demonstra a seqncia do esforo em um projeto por meio de fases e disciplinas. As setas na vertical indicam a seqncia. Uma fase executada quando a anterior concluda. O objetivo entregar pacotes de software mais constantemente para os usurios, no acumulando toda a entrega para o final.

6. Principais diferenas entre Cascata e Iterativo

Uma comparao entre os processos de desenvolvimento de software Cascata e os Iterativo-Incrementais est demonstrada na Tabela 1:

Caracterstica S

Processo Cascata passamos fase para

Processo Iterativo a Passamos o pela fase vrias permite dos

Indivisibilidade prxima das Fases

aps vezes,

que

concluirmos 100% da fase refinamento atual.

incremental

artefatos e do sistema. Pode progredir para frente ou

Fluxo de Trabalho

H progresso serial por meio das disciplinas.

para trs por meio das fases, para mudar o foco e envolver vrias disciplinas, a fim de enderear o risco.

No

oferece Oferece oportunidades claras

oportunidades claras para para entregas parciais de um entregas parciais de um sistema Reao s Mudanas sistema ou para a iterao, ao final de uma a no

permitindo de mudanas

introduo de mudanas introduo

dentro do ciclo de vida. , ciclo de vida ao final de uma portanto, mudanas. reativa a iterao e antes da prxima. , portanto, proativa a mudanas.

Tabela 1 Principais diferenas entre processo Cascata e Iterativo

7. Vantagens dos Processos Iterativos

O processo Iterativo, ao entregar pacotes de software com mais constncia para os usurios, possibilita que estes dem feedback mais cedo

sobre o produto de software que receberam. No processo Cascata, esse feedback s aconteceria tardiamente, quando os usurios tivessem contato com o software, ou seja, de maneira parcial, na fase de testes, e, total, na entrega final. Essa caracterstica confere uma srie de vantagens ao processo Iterativo sobre o Processo Cascata. So elas: Antecipa mudanas; Controla riscos; Foca o desenvolvimento no produto do cliente; Aumenta a qualidade do produto final.

71. Antecipa Mudanas

Se h um erro no projeto, quanto antes ele for descoberto e corrigido, menor ser o impacto e menor ser o custo para a correo necessria. Corrigir um erro significa, em geral, refazer uma parte ou todo o trabalho at aquele ponto, ou seja, gera retrabalho e, conseqentemente, mais custo para o projeto.
Custo de Alterao em um processo de software

Custo

Tempo

Figura 5 Custo das Mudanas ao longo do Ciclo de Desenvolvimento.

Quanto mais tardia a correo for disparada, maior ser o retrabalho e, inevitavelmente, maior o custo da correo. A figura 5 mostra um esboo do

aumento do custo para se efetuarem alteraes no software ao longo do tempo em que o sistema est sendo desenvolvido. As mudanas devem vir o quanto antes no projeto. Em um processo Iterativo, a captura dos requerimentos feita parcialmente, a cada iterao. comum que os clientes solicitem alteraes ou inspirem-se com novas idias, quando se entregam verses de software (ainda que reduzidas). No momento em que o usurio recebe parte da soluo, comea a vislumbrar algumas funcionalidades que no havia considerado anteriormente. Assim, conforme Kroll, 2001, devem-se encorajar as mudanas, pois a abordagem iterativa foi otimizada exatamente para isso. Entretanto, essas transformaes devem ser gerenciadas para que aconteam no tempo adequado.

7.2. Controla Riscos

Ao desenvolver um projeto de software, a preocupao 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 ocorrncia de um risco pode atrasar o projeto, aumentar seu custo, alterar a qualidade do produto final. Assim, necessrio 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 enderear seus riscos, podemos estar investindo em esforos que podem no nos trazer o retorno esperado. O modelo Cascata no trata os riscos diretamente. No modelo Iterativo, como temos iteraes, ou seja, fases repetitivas, os riscos do projeto so avaliados a cada nova iterao. Ainda, o fato de termos entregas parciais ajuda na reduo do risco, pois, uma vez que o mdulo ou parte do software aprovado e instalado, deixa de haver o risco de rejeio.

A figura 6 mostra dois grficos comparando a reduo 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, no se pode verificar se um risco est claro at um ponto tardio do Ciclo de Vida. Assim, no primeiro grfico da figura 6, o risco s comea a cair quando se chega fase de testes do sistema.

J no segundo grfico 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 reavaliaes da lista de riscos do projeto. As entregas parciais de funcionalidades permitem o feedback dos usurios e as correes, se houver. Isso aumenta a chance de sucesso do projeto. No processo Iterativo, a cada iterao, deve-se fazer uma pausa e considerar quais so os riscos envolvidos naquele momento e nas etapas seguintes. Quanto mais se antecipam os riscos, menor a chance de sua ocorrncia. Nesse processo, podemos selecionar qual incremento desenvolver em uma iterao a partir de uma lista de riscos-chave. Como cada iterao produz um executvel testvel, possvel verificar se o risco foi mitigado ou no, e se ele foi ou no bem aceito pelo cliente. Os riscos so mais bem tratados no processo Iterativo, pois so revistos a cada iterao.

7.3. Foca o desenvolvimento no produto do cliente

Em um projeto de desenvolvimento, alm do produto final entregue aos clientes, comum a produo de artefatos intermedirios. Cada processo de desenvolvimento de software sugere seus prprios artefatos, mas,

geralmente, no mudam, de forma radical, de um processo para outro. A idia, aqui, gerar o menor nmero possvel de artefatos intermedirios, ou seja, direcionar o mximo de esforo para o artefato principal: o produto de software que ser entregue ao usurio. Alguns artefatos podem ser estrategicamente indispensveis durante o desenvolvimento de um projeto, mas, para qualquer projeto, devemos nos

esforar para reduzir o nmero de artefatos produzidos a fim de reduzir o desperdcio. (KROLL, 2001). Focar os esforos no produto final reduz o desperdcio do projeto. O foco no software executvel, 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 esforo para outras atividades acessrias.

7.4. Aumenta a qualidade do produto final

Se, de um lado, as mudanas podem ser um obstculo para os que desenvolvem e para os que controlam prazo e oramento do projeto, elas podem tambm indicar que o produto de software est passando por ajustes e vai, paulatinamente, aproximando-se da soluo ideal para o cliente. uma outra forma de olhar para as mudanas em um projeto de software. Mudanas permitem melhorar a soluo de software. importante entender que as mudanas fazem parte de um projeto de desenvolvimento (raramente um projeto tem todos os requerimentos, anlise e design sem mudanas 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, so melhores que o processo Cascata, ento por que este , ainda, o mais utilizado? Certamente, o primeiro motivo porque muito mais fcil para os que desenvolvem e para os que usam entenderem a seqncia do modelo Cascata do que a dinmica dos modelos Iterativos.

Alm disso, a aplicao de modelos espirais exige treinamento e mudana cultural. Deve haver sinergia muito maior entre os que usam e os que desenvolvem do que se costuma ter (o processo Cascata tambm exige isso, mas, no modelo Iterativo, essencial). Para utilizao de um processo iterativo, os usurios devem ter grande confiana naqueles que desenvolvem, a comunicao deve ser intensa e o projeto deve ter uma gerncia capaz de controlar as caractersticas de um projeto iterativo (essa gerncia, por si s, um captulo parte). Se a gerncia do projeto no for adequada, corre-se o risco de perder o foco das iteraes, gerando-se iteraes desnecessrias, em nome do refinamento incremental -o que prolongaria, em demasia, o projeto e, a sim, consumiria muito mais tempo e oramento do que o planejado. No processo Iterativo, importante no perder o foco do trabalho a realizar. Aumentos de escopo devem ser tratados e aprovados devidamente, aliados com os ajustes nas previses de custo e prazo. Todavia, o fator cultural ainda o preponderante. A inrcia dos processos instalados nas empresas traz resistncia s mudanas. O conceito popularmente conhecido como eu sempre fiz desse jeito mostra o quanto difcil convencer algum a mudar. Nesses casos, a mudana cultural deve vir de cima, patrocinada pelo alto escalo da empresa, que deve ser convencido de que o novo modo de trabalho vantajoso.

Concluso
Apesar de suas deficincias, o modelo Cascata de fcil compreenso para os que usam e para os que desenvolvem e, se for bem trabalhado, pode trazer, ainda, resultados muito satisfatrios para a empresa. Mesmo com tantas vantagens, os modelos Iterativos no permitem aplicao imediata sem treinamento e aculturao prvios. Deve haver grande entrosamento das partes envolvidas e necessrio que esteja muito

claro para todos a nova forma de trabalho. Se isso no estiver bem entendido, o projeto tende ao fracasso. Nesse caso, melhor a utilizao do tradicional processo Cascata. Considerado esse panorama, vale a pena aprofundar o conhecimento sobre os processos iterativos, investindo tempo para conhec-lo e empreglo em projetos-piloto, visto que suas vantagens so bastante considerveis.