Processo iterativo

Este modelo combina as vantagens do modelo cascata e prototipação, devido a limitações que o modelo cascata apresenta, trazendo a ideia central do desen- volvimento incremental, sendo que a cada incremento são adicionadas novas funções ao sistema até atingir os objetivos finais, efetuando-se adaptações e mudanças necessárias a cada passo realizado (MAZZOLA, 2010, p.14). Este mo- delo iterativo pode ser representado por meio da figura 3 abaixo.

a) Modelo cascata

Planejamento Analise Desenho e modelagem Codificação 3 - 24 meses Teste Entrega $ b) Processo iterativo $ = Entrega potencial Planejamento Análise _Desenho Codificação Teste $ Entrega 1 - 3 meses Planejamento Análise _Desenho Codificação Teste $ Entrega 1 - 3 meses Planejamento Análise _Desenho Codificação Teste $ Entrega 1 - 3 meses

Figura 4.3 – Esquema comparativo entre o modelo cascata (a) e o processo iterativo (b). Fonte:  Shore e Warden (2008, p. 35) (Adaptado pelo autor).

O desenvolvimento incremental foi proposto por H. Mills em 1980 como for- ma de redução do retrabalho no processo de desenvolvimento e por permitir que os requisitos pudessem ser definidos em outro momento, sem a necessidade de ter a definição completa logo no início do projeto (SOMMERVILLE, 2006, p.43).

Nesta abordagem, o desenvolvimento incremental possui algumas carac- terísticas marcantes, como, por exemplo, o desenvolvimento do sistema por partes; classificação dos requisitos por ordem de prioridade, identificados pe- los clientes; definição do número e tamanho dos incrementos; utilização do processo de desenvolvimento preferido para estes incrementos e adição de um novo requisito à cada novo incremento, conforme pode ser visto no esquema da figura 4.4. Define requisitos preliminares Estabelece no _de incrementos Atribui requisitos aos incrementos Projeta arquitetura do sistema Desenvolve

incremento incrementoValida o

Sistema incompleto Integra

incremento Valida osistema Sistemafinal

Uma vez que os incrementos a serem implementados são identificados, são detalhados os requisitos para as funções a serem entregues, e esta implemen- tação é efetuada pelo processo de desenvolvimento que for mais apropriado. Durante o desenvolvimento destes incrementos, podem surgir outras análises de requisitos, mas as mudanças ou alterações só ocorrem no próximo incre- mento e não no atual (SOMMERVILLE, 2006, p.44).

Depois de concluído e entregue o incremento, este pode ser colocado em operação pelos clientes, o que vale notar que estes clientes podem receber com antecedência uma parte da funcionalidade do sistema. Com isso, estes podem testar e experimentar o sistema, oferecendo condições de levantar outros re- quisitos para incrementos seguintes, proporcionando um processo de melho- ria a cada entrega. As funcionalidades podem ser implementadas no início do processo ou de forma gradativa, à medida que surge a necessidade ou que estas sejam exigidas (SOMMERVILLE, 2006, p.44).

No desenvolvimento incremental existe um fato interessante, pois não há a necessidade de se utilizar o mesmo processo de desenvolvimento a cada incre- mento, sendo que, quando as funções presentes em um incremento possuírem especificações detalhadas e bem definidas, o modelo cascata pode ser utilizado especificamente naquele incremento, já que este modelo lida muito bem com requisitos definidos. Mas se a especificação estiver mal-definida, pode-se usar outro modelo de desenvolvimento evolucionário, por ser um modelo mais ade- quado que o cascata nestas condições, já que não exige definição dos requisitos desde o início, podendo identificar novos requisitos ao longo do processo.

De acordo com Sommerville (2006, p.44), esse processo de desenvolvimento incremental tem diversas vantagens:

•  Os clientes não precisam esperar até que todo o sistema seja entregue, para então tirarem proveito dele. O primeiro estágio satisfaz seus requisitos mais importantes e o software pode ser imediatamente utilizado.

•  Os clientes podem utilizar os primeiros incrementos como um protótipo e obter uma experiência que forneça os requisitos para estágios posteriores do sistema.

•  Existe um risco menor de fracasso completo do sistema. Embora possam ser encontrados problemas em alguns incrementos, é provável que alguns in- crementos sejam entregues com sucesso ao cliente.

•  Como as funções prioritárias são entregues primeiro e incrementos posteriores são integrados a elas, é inevitável que as funções de sistema mais

importantes passem pela maior parte dos testes. Isso significa que é menos provável que os clientes encontrem falhas de software na parte mais importan- te do sistema.

Marcoratti (2004) também apresenta algumas vantagens do processo incre- mental e iterativo:

•  Possibilidade de avaliar mais cedo os riscos e pontos críticos do projeto, e identificar medidas para os eliminar ou controlar;

•  Redução dos riscos envolvendo custos a um único incremento. Se a equi- pe que desenvolve o software precisar repetir a iteração, a organização perde somente o esforço mal direcionado de uma iteração, não o valor de um produto inteiro;

•  Definição de uma arquitetura que melhor possa orientar todo o desenvolvimento;

•  Disponibilização natural de um conjunto de regras para melhor controlar os inevitáveis pedidos de alterações futuras;

•  Permite que os vários intervenientes possam trabalhar mais efetivamente pela interação e partilha de comunicação daí resultante.

No entanto, o desenvolvimento incremental também possui alguns proble- mas ou pontos que devem ser considerados. Incrementos devem ser pequenos, com menos de 20 mil linhas de código, sendo que cada incremento deve reali- zar pelo menos um serviço e isto pode ser difícil, pois não é simples mapear os requisitos exigidos em incrementos e com o número certo do tamanho. Outro ponto é que os requisitos só são detalhados no momento em que os incremen- tos são desenvolvidos, sendo difícil identificar facilidades comuns que todos os incrementos tenham como exigência.

De acordo com Wikipedia (2015), os dois padrões mais conhecidos de siste- mas iterativos de desenvolvimento são o RUP (Processo Unificado da Rational) e o Desenvolvimento ágil de software. Por isso o desenvolvimento iterativo e incre- mental é também uma parte essencial da Programação Extrema (XP) e outros.

Como sabemos, o desenvolvimento de um produto complexo de software, no meio comercial, pode levar meses, em torno de um ano ou até um pouco mais. Assim, dividir o trabalho por meio de iterações e partes menores é mais prático, resultando em incrementos a cada iteração (repetição de uma ou mais ações).

Um dos princípios desta abordagem incremental é permitir que o sistema possa ser refinado e ir ampliando sua qualidade e detalhes por parte da equipe envolvida a cada iteração.Assim, inicialmente, numa primeira iteração, identi- fica-se uma visão geral e determina a viabilidade econômica do sistema, efetu- ando grande parte da análise e também uma parte do desenho e implementa- ção. Em seguida, na segunda iteração, após a conclusão da análise, executa-se outra parte do desenho e avança um pouco mais nas implementações. Após a conclusão do desenho, numa terceira iteração, evolui-se a implementação, jun- tamente com testes e um pouco de integração.

Com estas seguidas iterações, notamos que o amadurecimento do produto de software vai evoluindo ao longo do tempo e que a cada iteração é produzido um conjunto de produtos finais, conforme afirma Marcoratti (2014), por meio da realização das seguintes tarefas abaixo e representadas na figura 4.5:

•  Análise (refinamento de requisitos, refinamento do modelo conceitual) •  Projeto (refinamento do projeto arquitetural, projeto de baixo nível) •  Implementação (codificação e testes)

•  Transição para produto (documentação, instalação, ...)

Planejamento Análise Desenho Teste Análise Desenho Codificação Teste Manutenção 2a _versão 1a _versão Figura 4.5 – Abordagem incremental. Fonte: MARCORATTI (2014) (Adaptado pelo autor).

Um detalhe importante a ser observado sobre a essência dos processos iterativos é que, conforme Sommerville (2006, p. 43) aponta, “a especificação é desenvolvida em conjunto com o software. Contudo, isso entra em conflito com o modelo de suprimentos de muitas organizações, em que a especifica- ção completa do sistema faz parte do contrato” para o desenvolvimento do software. Como nesta abordagem incremental e gradativa não há uma especi- ficação completa do sistema, até que o estágio final seja especificado, muitas

vezes isto requer um novo tipo de contrato e aí isto pode ser um entrave para grandes clientes, como órgãos de governo, que geralmente não aceitam este tipo de contrato ou esta abordagem (SOMMERVILLE, 2006, p.43).