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

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:

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

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.

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

é 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.

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.

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.

FASES

D

I

S

C

I

P

L

I

N

A

S

Concepção Elaboração Construção Transição

Requisitos

Análise

Design

Implementação

Testes

Iter.

#1

Iter.

#2

_ _ _ _ _ Iter.

#n-1

Iter.

#n

Concepção Elaboração Construção Transição

Requisitos

Análise

Design

Implementação

Testes

Iter.

#1

Iter.

#2

_ _ _ _ _ Iter.

#n-1

Iter.

#n

Concepção Elaboração Construção Transição

Requisitos

Análise

Design

Implementação

Testes

Iter.

#1

Iter.

#2

_ _ _ _ _ Iter.

#n-1

Iter.

#n

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.

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.

:Ciclo

Iniciação :Fase

Elaboração :Fase

Construção :Fase

Transição :Fase

Implantação:Disciplina

Teste:Disciplina

Análise e Projeto :Disciplina

Requisito:Disciplina

Implementação :Disciplina

Modelagem de Negócio:Disciplina

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

Indivisibilidade

das Fases

Só passamos para a

próxima fase após

concluirmos 100% da fase

atual.

Passamos pela fase várias

vezes, o que permite

refinamento incremental dos

artefatos e do sistema.

Fluxo de

Trabalho

Há progresso serial por

meio das disciplinas.

Pode progredir para frente ou

para trás por meio das fases,

para mudar o foco e envolver

várias disciplinas, a fim de

endereçar o risco.

Reação às

Mudanças

Não oferece

oportunidades claras para

entregas parciais de um

sistema ou para a

introdução de mudanças

dentro do ciclo de vida. É,

portanto, reativa a

mudanças.

Oferece oportunidades claras

para entregas parciais de um

sistema ao final de uma

iteração, permitindo a

introdução de mudanças no

ciclo de vida ao final de uma

iteração e antes da próxima. É,

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

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.

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

Custo de Alteração em um processo de software

Tempo

Custo

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.

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.

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.

Desenvolvimento Cascata

Cascata X Iterativo

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

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.

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

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.