Plano de Iteração de Exemplo: Fase de Elaboração

A ilustração mostra o relacionamento dos fluxos de trabalho em uma iteração inicial da elaboração. Ela será construída a partir dos Detalhamentos do Fluxo de Trabalho da forma como aparecerem naquele momento. O intuito é indicar as dependências e mostrar onde ocorrem fluxos de trabalho em paralelo. Os comprimentos das barras no gráfico (indicando a duração) não têm significado absoluto. Por exemplo, não se pretende transmitir que Planejar a Próxima Iteração e Gerenciar o Escopo do Sistema devem ter a mesma duração. Também não é a intenção sugerir a aplicação de um nível de esforço uniforme no decorrer dos fluxos de trabalho. Uma indicação do esforço relativo pode ser vista em Visão Geral do Processo. É possível navegar para as páginas correspondentes do Detalhamento do Fluxo de Trabalho a partir de cada linha do gráfico; basta clicar no nome do Detalhamento do Fluxo de Trabalho. Essa ilustração foi criada a partir de um Plano do Microsoft Project.

Observe que, embora este seja um plano para uma única iteração, nem todo trabalho de Requisitos e Análise e Design realizado durante essa iteração destina-se à Implementação

nessa iteração. Isso explica porque o esforço relativo, dentro de uma iteração, para Requisitos, Análise e Design, Implementação e Teste, muda ao longo do ciclo de vida. No entanto, o Plano de Iteração ditará quais requisitos serão explorados e refinados e quais componentes serão projetados, mesmo se eles forem projetados para Implementação e Teste em uma iteração posterior.

Plano de Iteração de Exemplo

Início: Descrever o plano de iteração, os riscos e os objetivos de arquitetura.	O Artefato: Plano de Iteração para esta iteração foi construído pelo Papel: Gerente do Projeto depois que a iteração anterior foi avaliada, e o escopo e o risco do projeto foram reavaliados. Os critérios de avaliação da arquitetura são descritos pelo Papel: Arquiteto de Software em Artefato: Documento de Arquitetura do Software, levando em consideração os "riscos de arquitetura" que serão amenizados (consulte Artefato: Lista de Riscos). Lembre-se de que uma das metas da Elaboração é estabelecer uma arquitetura sofisticada e executável; o plano para fazê-lo precisa ser desenvolvido na iteração Elaboração inicial.
Ambiente: Preparar ambiente para a iteração.	O Papel: Engenheiro do Processo e o Papel: Especialista em Ferramentas preparam o ambiente para a iteração (consulte Detalhamento do Fluxo de Trabalho: Preparar Ambiente para uma Iteração). Uma informação importante é a avaliação da iteração anterior. O Papel: Engenheiro do Processo conclui o Artefato: Caso de Desenvolvimento e adapta os templates (consulte Artefato: Templates Específicos do Projeto), para estarem prontos para a iteração, adaptando (pelo menos) a disciplina Análise e Design e a disciplina Implementação. O Papel: Especialista em Ferramentas define as ferramentas (consulte Artefato: Ferramentas) que serão utilizadas na iteração. Se necessário, produzirá um Artefato: Guia de Ferramentas. As diretrizes relevantes são desenvolvidas (consulte Detalhamento do Fluxo de Trabalho: Preparar Diretrizes para uma Iteração).
Requisitos: Decidir o que "conduzirá" o desenvolvimento da arquitetura.	O Papel: Arquiteto de Software e o Papel: Gerente de Projeto definem quais casos de uso e/ou cenários devem ser tratados na iteração atual; eles, por sua vez, direcionam o desenvolvimento da arquitetura (consulte Detalhamento do Fluxo de Trabalho: Gerenciar o Escopo do Sistema na Disciplina Requisitos). O Artefato: Plano de Iteração criado no passo anterior deve ser atualizado da forma apropriada.
Compreender bem os "geradores", se necessário, inspecionar os resultados.	Vários dos Papéis: Especificadores de Requisitos descrevem detalhadamente os subconjuntos dos casos de uso ou cenários selecionados significativos para a arquitetura (consulte Detalhamento do Fluxo de Trabalho: Refinar a Definição do Sistema na disciplina Requisitos). À medida que o modelo evolui, o Papel: Analista de Sistemas poderá reestruturar o Artefato: Modelo de Casos de Uso para melhorar a capacidade de compreensão do modelo. As mudanças no Artefato: Modelo de Casos de Uso são, então, examinadas e aprovadas (consulte Detalhamento do Fluxo de Trabalho: Gerenciar Requisitos Variáveis na Disciplina Requisitos).
Os "geradores" da arquitetura são reconsiderados com base nas novas informações, os riscos também precisam ser reconsiderados.	A visão de caso de uso é revista novamente pelo Papel: Arquiteto de Software, levando em consideração novas descrições de caso de uso e, possivelmente, uma estrutura nova do Artefato: Modelo de Casos de Uso (reveja Detalhamento do Fluxo de Trabalho: Gerenciar o Escopo do Sistema na Disciplina Requisitos). A tarefa agora é selecionar qual conjunto de casos de uso e/ou cenários deve ser analisado, projetado e implementado na iteração atual. Observe novamente que o desenvolvimento desses casos de uso e/ou cenários define a arquitetura do software. O Papel: Gerente de Projeto atualiza mais uma vez o plano de iteração atual de forma conveniente (consulte Artefato: Plano de Iteração), e também pode reconsiderar o gerenciamento de riscos, pois novos riscos podem ter se tornado visíveis com base nas novas informações (consulte Artefato: Lista de Riscos).
Análise de Caso de Uso: Encontrar classes óbvias, fazer um particionamento do subsistema (de alto nível) inicial e começar a observar com cuidado os "geradores".	Para obter um sentimento geral das classes óbvias necessárias, o Papel: Arquiteto de Software considera os requisitos do sistema, o glossário, a visão de casos de uso (exceto as descrições dos casos de uso) e o conhecimento geral do domínio pela equipe para esboçar a descrição dos subsistemas, possivelmente em camadas (consulte Atividade: Identificar Elementos de Design na Disciplina Análise e Design). Os mecanismos de análise (soluções usuais para problemas de análise freqüentes) também são identificados pelo arquiteto de software. Paralelamente a esse esforço, uma equipe de Papel: Designers, possivelmente junto com o arquiteto de software, iniciará a pesquisa de Artefato: Classes de Análise para os casos de uso e/ou cenários desta iteração, bem como a alocação de responsabilidades para as classes identificadas e os mecanismos de análise do processo, atualizando Artefato: Realizações de Casos de Uso. Os designers usarão as classes óbvias encontradas pelo arquiteto de software como informação. Em seguida, vários designers refinam as classes identificadas no passo anterior, alocando responsabilidades às classes e atualizando seus relacionamentos e atributos. É estabelecida detalhadamente a forma como os mecanismos de análise disponíveis são usados por cada classe. Quando isso é feito, o Papel: Arquiteto de Software identifica várias classes que devem ser consideradas significativas para a arquitetura, e inclui essas classes na seção de visão lógica do Artefato: Documento de Arquitetura de Software. Os artefatos de análise resultantes são examinados.
Design: Ajustar o ambiente de implementação, decidir como os "geradores" devem ser projetados e refinar a definição de classes, pacotes e subsistemas; examinar os resultados.	O Papel: Arquiteto de Software refina a arquitetura gerando os mecanismos de design (por exemplo, linguagem de programação, banco de dados, mecanismo de distribuição, mecanismo de comunicação) necessários pelos mecanismos de análise identificados anteriormente (consulte Atividade: Identificar Mecanismos de Design na Disciplina Análise e Design). Artefato: Subsistemas de Design são definidos e classes de design são alocadas para eles; as interfaces dos subsistemas são definidas. As classes de design restantes são particionadas em pacotes, e as responsabilidades dos subsistemas são alocadas para o Papel: Designers. Os designers usam instâncias de classes e subsistemas para descrever as realizações dos casos de uso e/ou cenários selecionados (consulte Detalhamento do Fluxo de Trabalho: Projetar Componentes na disciplina Análise e Design). Isso impõe requisitos aos elementos do modelo implantado e seus mecanismos de design associados; no processo, os diagramas de interações anteriormente criados são refinados. Os requisitos impostos a cada mecanismo de design são tratados pelo arquiteto de software (reveja Atividade: Identificar Mecanismos de Design na disciplina Análise e Design). A visão lógica é atualizada de forma adequada pelo arquiteto de software. Os artefatos de design resultantes são examinados.
Considerar o aspecto da concorrência e da distribuição na arquitetura.	O próximo passo para o arquiteto de software é considerar a concorrência e a distribuição exigidas pelo sistema. Isso é feito pelo estudo das tarefas e processos obrigatórios, da rede física de processadores e de outros dispositivos (consulte Atividade: Descrever a Arquitetura em Tempo de Execução e Atividade: Descrever a Distribuição na Disciplina Análise e Design). Uma informação importante para o arquiteto de software envolve os casos de uso projetados como objetos de colaboração em diagramas de interações; esses objetos são alocados para tarefas e processos, que, por sua vez, são alocados para processadores e outros dispositivos. Isso resulta em uma distribuição lógica e física da funcionalidade.
Inspecionar a arquitetura.	A arquitetura é analisada. Consulte Atividade: Revisar a Arquitetura.
Implementação: Considerar o empacotamento físico da arquitetura.	Um Papel: Arquiteto de Software considera o impacto do design da arquitetura no modelo de implementação e define a estrutura inicial do modelo de implementação (reveja Atividade: Estruturar o Modelo de Implementação na disciplina Análise e Design).
Implementação: Planejar a integração.	Um integrador do sistema (Papel: Integrador) estuda os casos de uso que devem ser implementados nesta iteração e define a ordem em que os subsistemas devem ser implementados e, posteriormente, integrados em um protótipo da arquitetura (consulte Detalhamento do Fluxo de Trabalho: Planejar a Integração na disciplina Implementação). Os resultados desse planejamento devem estar presentes em Artefato: Plano de Desenvolvimento de Software.
Teste: Definir Missão de Avaliação.	O gerente de teste (Papel: Gerente de Teste) entra em acordo com os envolvidos sobre os objetivos do teste dessa iteração. O analista de teste (Papel: Analista de Teste) e o designer de teste (Papel: Designer de Teste) definem os detalhes da abordagem - o que será testado e como isso será feito.
Teste: Verificar Abordagem do Teste.	O designer de teste (Papel: Designer de Teste) e o testador (Papel: Testador) implementam infra-estrutura de teste suficiente para verificar se a abordagem de teste funcionará e se é relevante. O analista de teste (Papel: Analista de Teste) detalha esses testes de verificação que serão depois implementados e executados pelo testador. O gerente de teste (Papel: Gerente de Teste) assegura que a equipe de desenvolvimento esteja comprometida a dar suporte à abordagem de teste.
Implementação: Implementar as classes e integrar.	Vários dos implementadores (Papel: Implementador) implementam e testam as classes identificadas no design de arquitetura (Passos 5, 6 e 7). As implementações das classes são fisicamente empacotadas em componentes e subsistemas no modelo de implementação. Os implementadores (Papel: Implementador) também corrigem defeitos (consulte Detalhamento do Fluxo de Trabalho: Implementar Componentes na disciplina Implementação). Os desenvolvedores e testadores testam a integração do subsistema de implementação (consulte Detalhamento do Fluxo de Trabalho: Integrar cada Subsistema na disciplina Implementação e Detalhamento do Fluxo de Trabalho: Testar e Avaliar na disciplina Teste), e os implementadores (Papel: Implementador) lançam o release dos subsistemas de implementação testados para a integração do sistema.
Integrar as partes implementadas.	Os integradores do sistema (Papel: Integrador) integram os subsistemas em incrementos em um protótipo de arquitetura executável (consulte Detalhamento do Fluxo de Trabalho: Integrar o Sistema na disciplina Implementação). Cada build é testado para assegurar a estabilidade para os testes seguintes (consulte Detalhamento do Fluxo de Trabalho: Validar a Estabilidade do Build na disciplina Teste) e o trabalho de teste detalhado inicia (consulte Detalhamento do Fluxo de Trabalho: Testar e Avaliar na disciplina Teste).
Teste: Testar e Avaliar, Realizar Missão Aceitável, Aprimorar Vantagens do Teste.	Os testes prosseguem ao longo do ciclo seguinte (organizado em torno dos builds principais e envolvendo todos os papéis de teste): Testar e Avaliar - os testes são implementados, executados e avaliados. Realizar Missão Aceitável - os resultados dos testes são avaliados em comparação com os objetivos do teste. Testes adicionais são feitos se necessário. Aprimorar Vantagens do Teste - os artefatos de teste são melhorados conforme a necessidade de suportar o próximo ciclo de testes.
Avaliar a iteração propriamente dita.	Por fim, o Papel: Gerente do Projeto compara o custo real, a programação e o conteúdo da iteração com o plano da iteração; determina se haverá necessidade de retrabalho e, caso positivo, atribui-o a iterações futuras; atualiza a lista de riscos (consulte Artefato: Lista de Riscos); atualiza o plano do projeto (consulte Artefato: Plano de Desenvolvimento de Software); e prepara uma descrição de um plano para a próxima iteração (consulte Artefato: Plano de Iteração). Convém considerar aqui os números sobre a produtividade, o tamanho do código e o tamanho do banco de dados. O Papel: Gerente do Projeto, em cooperação com o Papel: Engenheiro do Processo e o Papel: Especialista em Ferramentas, avalia o processo de uso e as ferramentas.

Resultado

O resultado dessa iteração inicial seria uma primeira redução na arquitetura, consistindo em visões de arquitetura bem descritas (visão de caso de uso, visão lógica, visão de processos, visão da implantação, visão da implementação) e em um protótipo de arquitetura executável.

Iterações Subseqüentes na Elaboração

As iterações subseqüentes podem ser iniciadas para melhorar a compreensão da arquitetura. Talvez isso implique um aperfeiçoamento do design ou do modelo de implementação (isto é, a realização de mais casos de uso, em ordem de prioridade, é claro). A necessidade de isso acontecer dependerá de considerações, como a complexidade do sistema e a sua arquitetura, os riscos associados e a experiência do domínio.

Em cada iteração, o ambiente de suporte é refinado. Se a primeira iteração de Elaboração estiver concentrada no preparo do ambiente para Análise e Design, e Implementação, a segunda iteração poderá focalizar o preparo do ambiente de teste. A preparação do ambiente de teste inclui configurar o processo de teste e escrever a parte do caso de desenvolvimento, preparar templates e diretrizes para testes e configurar as ferramentas de teste.