Conceitos: Iteração
Tópicos
Tradicionalmente, os projetos foram organizados para percorrer cada disciplina em seqüência apenas uma vez.
Isso leva ao ciclo de vida em cascata:

Freqüentemente, ele resulta em um acúmulo de integração tardia na implementação, quando, pela primeira vez, o produto é criado e o teste começa.
Aparecem os problemas que permaneceram ocultos por todo o processo de Análise, Design e Implementação, e o projeto é paralisado enquanto começa um longo ciclo de correção de erros.
Uma maneira mais flexível (e menos arriscada) de continuar é percorrer várias vezes as diversas disciplinas de desenvolvimento, construindo um melhor entendimento dos requisitos, planejando uma arquitetura robusta, elevando a organização do desenvolvimento e, por fim, liberando uma série de implementações que são gradualmente mais completas.
Isso se chama ciclo de vida iterativo.
Cada passagem através da seqüência de disciplinas do processo chama-se iteração.

Portanto, de uma perspectiva de desenvolvimento o ciclo de vida do software é uma sucessão de iterações, através da qual o software é desenvolvido incrementalmente. Cada iteração é concluída com o release de um produto executável. Esse produto pode ser um subconjunto da visão completa, mas mesmo assim ser útil do ponto de vista da engenharia ou do usuário.
Cada release é acompanhado por artefatos de suporte: descrição do release, documentação do usuário, planos, e assim por diante, e os modelos atualizados do sistema.
A conseqüência principal dessa abordagem iterativa é que osconjuntos de artefatos, descritos anteriormente, crescem e amadurecem com o tempo, conforme mostrado no seguinte diagrama.

Evolução do conjunto de informações ao longo das fases de desenvolvimento.
Uma iteração envolve as atividades de desenvolvimento que levam ao
release de um produto - uma versão estável e executável do produto, junto com
qualquer outro elemento periférico necessário para utilizar esse release. Portanto, uma
iteração de desenvolvimento é, de alguma forma, uma passagem completa por pelo menos todas as disciplinas: Requisitos,
Análise & Design, Implementação e Teste. É como um pequeno projeto cascata em si mesmo.
Observe que os critérios de avaliação são estabelecidos quando cada iteração é planejada.
O release terá planejado a capacidade que é demonstrável.
A duração de uma iteração variará de acordo com o tamanho e a natureza
do projeto, mas é provável que várias construções
sejam feitas em cada iteração, conforme especificado no Plano de Construção de
Integração para a iteração. Essa é uma conseqüência da abordagem de integração
contínua recomendada no RUP (Rational Unified Process): conforme os componentes testados
da unidade ficam disponíveis, eles são integrados, em seguida, uma construção é
produzida e sujeita ao teste de integração. Dessa maneira, a capacidade do software integrado cresce quando a iteração continua, em direção às metas definidas quando a iteração foi planejada.
Pode ser demonstrado que cada build representa uma mini-iteração por si mesmo; a diferença está no planejamento necessário e na formalidade da avaliação realizada.
Pode ser apropriado e conveniente em alguns projetos fazer construções
diariamente, mas isso não representará as iterações como o RUP as define -
exceto, talvez, para um projeto muito pequeno de uma única pessoa. Mesmo em projetos pequenos com várias pessoas (por exemplo, envolvendo cinco pessoas criando 10.000 linhas de código), seria muito difícil alcançar uma duração de iteração de menos de uma semana.
Release
Um release pode ser interno ou externo.
Um release interno é usado apenas pela organização de desenvolvimento, como parte de um marco, ou para fazer uma demonstração para usuários ou clientes.
Um release externo é liberado para os usuários finais.
Um release não é necessariamente um produto completo, mas pode ser apenas uma etapa ao longo do caminho, com sua utilidade avaliada apenas do ponto de vista da engenharia.
Os releases agem como uma função imposta que conduz a equipe de desenvolvimento a
encerrar em intervalos regulares, evitando a síndrome de "90% concluídos, 90% restantes".
As iterações e os releases permitem com o tempo um uso melhor das várias
especialidades na equipe; designers, testadores, escritores e assim por diante. Releases regulares permitem que você fragmente os problemas de integração e teste, e os distribua pelo ciclo de desenvolvimento.
Esses problemas freqüentemente são as enxurradas de projetos grandes, porque todos os problemas foram descobertos de uma vez durante a única etapa de integração em massa, que ocorreu muito tarde no ciclo, e onde um único problema detém a equipe toda.
A cada iteração, os artefatos são atualizados.
Diz-se que isso é como um software
"em crescimento". Em vez de desenvolver artefatos uns após os outros, como em um pipeline, eles são desenvolvidos através do ciclo, apesar das taxas diferentes.
Marco menor
Cada iteração é concluída por um marco menor, onde o resultado da iteração é avaliado em relação aos critérios de êxito do objetivo dessa iteração específica.

Cada iteração em uma fase resulta em um release executável do sistema.
Cada fase no RUP pode ser ainda mais dividida em iterações.
Uma iteração é um loop completo de desenvolvimento que resulta em um release (interno ou externo) de um produto executável, um subconjunto do produto final em desenvolvimento, que cresce por incrementos, a cada iteração, para se tornar o sistema final.
Padrão de Iteração: Ciclo de Vida Incremental

"A estratégia incremental determina as necessidades do usuário e define os requisitos do sistema e, em seguida, executa o restante do desenvolvimento em uma seqüência de construções. A primeira construção incorpora partes dos recursos planejados, a próxima construção inclui mais recursos e assim por diante até o sistema estar completo." [DOD94]
As seguintes iterações são características:
- uma iteração curta de Iniciação para estabelecer o escopo e a visão, e para definir o caso de negócio
- uma única iteração de Elaboração, durante a qual os requisitos são definidos e a arquitetura estabelecida
- várias iterações de Construção durante as quais os casos de uso são realizados e a arquitetura é aprimorada
- várias iterações de Transição para migrar o produto para a comunidade de usuários

Essa estratégia é apropriada quando:
- O domínio do problema é familiar.
- Os riscos são bem entendidos.
- A equipe do projeto é experiente.
Padrão de Iteração: Ciclo de Vida Evolucionário

"A estratégia evolucionária difere da incremental ao reconhecer que o
as necessidades do usuário não são completamente entendidas e todos os requisitos não
podem ser definidos imediatamente, eles são refinados em cada construção sucessiva." [DOD94]
As seguintes iterações são características:
- uma iteração curta de Iniciação para estabelecer o escopo e a visão, e para definir o caso de negócio
- várias iterações de Elaboração, durante as quais os requisitos são refinados em cada iteração
- uma única iteração de Construção, durante a qual os casos de uso são realizados e a arquitetura é expandida
- várias iterações de Transição para migrar o produto para a comunidade de usuários

Essa estratégia é apropriada quando:
- O domínio do problema é novo ou não é familiar.
- A equipe é inexperiente.
Alguns autores também fizeram em fases as entregas da funcionalidade incremental para o cliente [GIL88]. Isso pode ser necessário quando há pressões de mercado sobre o tempo restrito, onde a liberação antecipada de certos recursos importantes pode render benefícios de negócio significativos.
Em termos da abordagem da iteração de fase, a fase de transição começa cedo e tem a maioria das iterações.
Essa estratégia requer uma arquitetura bastante estável, que é
difícil de se conseguir em um ciclo de desenvolvimento inicial, para um sistema
"sem precedentes".
As seguintes iterações são características:
- uma iteração curta de Iniciação para estabelecer o escopo e a visão, e para definir o caso de negócio
- uma única iteração de Elaboração, durante a qual é criada uma baseline de arquitetura estável
- uma única iteração de Construção, durante a qual os casos de uso são realizados e a arquitetura é aprimorada
- várias iterações de Transição para migrar o produto para a comunidade de usuários

Essa estratégia é apropriada quando:
- O domínio do problema é familiar:
- a arquitetura e os requisitos podem ser estabilizados antecipadamente no ciclo de desenvolvimento
- há um baixo grau de novidade no problema
- A equipe é experiente.
- Releases incrementais de funcionalidade têm alto valor para o cliente.
Padrão de Iteração: Ciclo de Vida "Design Design" 
A abordagem em cascata tradicional pode ser vista como um caso degenerado em que há apenas uma iteração na fase de construção.
Ela é chamada "design
global" em [DOD94]. Na prática, é difícil evitar iterações adicionais na fase de transição.
As seguintes iterações são características:
- uma iteração curta de Iniciação para estabelecer o escopo e a visão, e para definir o caso de negócio
- uma única iteração muito longa de Construção, durante a qual os casos de uso são realizados e a arquitetura é aprimorada
- várias iterações de Transição para migrar o produto para a comunidade de usuários

Essa estratégia é apropriada quando:
- um pequeno incremento de funcionalidade bem definida está sendo adicionado a um produto muito estável
- a nova funcionalidade é bem definida e bem entendida
- A equipe é experiente, tanto no domínio do problema quando no produto existente
Na prática, poucos projetos seguem estritamente uma estratégia.
Você freqüentemente acaba com uma evolução híbrida no início, uma construção incremental e várias entregas. Uma das vantagens do modelo de iteração de fase é que ele permite acomodar uma abordagem híbrida, simplesmente aumentando o tamanho e o número de iterações em determinadas fases:
- Para domínios complexos ou de problemas não familiares, nos quais há um alto grau
de exploração: aumente o número de iterações na fase de elaboração e seu
comprimento.
- Para problemas de desenvolvimento mais complexos, nos quais há complexidade de
tradução do design em código: aumente o número de iterações na fase de construção
e seu comprimento.
- Para entregar software em uma série de releases incrementais: aumente o número de
iterações na fase de transição e seu comprimento.
|