Finalidade

Desenvolver um plano de granulação fina para uma única iteração, que consista em:

  • uma estrutura detalhada da divisão de trabalho para a atividade e as atribuições de responsabilidade
  • marcos e produtos liberados entre as iterações
  • critérios de avaliação para a iteração
Função:  Coordenador de Projeto  
Freqüência: Uma vez por iteração 
Etapas
Artefatos de Entrada:    Artefatos Resultantes:   
Mentores de Ferramentas:   

Detalhes de Workflow:   

A iteração em si é um conjunto de tarefas timeboxing cujo objetivo é produzir um executável. Para todas as tarefas, exceto a última iteração de transição, este é um produto intermediário, produzido para diminuir riscos e orientar o projeto para que seja liberado com sucesso. A ênfase em um produto executável liberado impõe uma integração quase contínua, além de permitir que o projeto identifique riscos técnicos logo no início, o que diminui riscos subordinados.

Iteração implica um certo volume de retrabalho (de artefatos existentes) e uma mudança de atitude em relação ao que é retrabalho. Em resumo, uma determinada quantidade de retrabalho é necessária, a fim de fornecer um produto de qualidade: através da criação de produtos intermediários e da avaliação da aplicabilidade da arquitetura do produto cedo e sempre, a qualidade do produto final aumenta e as mudanças são menos dispendiosas e mais fáceis de serem incorporadas.

Determinar o Escopo da Iteração Ir para o início da página

Finalidade Selecionar um conjunto de casos de uso ou cenários a serem considerados durante a iteração.
Selecionar um conjunto de requisitos não-funcionais que devem ser tratados durante a iteração.  
Guidelines: O Plano de Iteração 

O escopo de uma iteração é orientado por quatro fatores:

  • os principais riscos do projeto
  • a funcionalidade necessária ao sistema
  • o tempo alocado para a iteração no Plano de Projeto
  • a fase e seus objetivos específicos (Consulte Fases)

No planejamento inicial de uma iteração, um volume suficiente de trabalho é selecionado para preencher o tempo já planejado para a iteração - embora o Coordenador de Projeto tenha alguma liberdade para considerar as restrições de recursos e outras questões táticas no momento em que o Plano de Iteração está sendo desenvolvido. Obviamente, o trabalho planejado para a iteração anterior e que ainda não foi concluído (porque o escopo da iteração anterior foi reduzido para atender à programação) terá alta prioridade.

O escopo do trabalho também tem que ser definido por uma abordagem que aproveite ao máximo o nível da equipe durante a iteração. Por exemplo, em geral, não é possível duplicar o trabalho concluído por uma iteração dobrando a equipe, mesmo que esses recursos estejam disponíveis. O número aproximado de membros da equipe que pode ser utilizado com eficiência é determinado pelo tamanho geral do software e sua arquitetura e modelos de estimativa, como COCOMO II (consulte BOE00]), podem fornecer essa informação.

A execução de uma iteração é, então, gerenciada por ../glossary.htm#timeboxing -- This hyperlink in not present in this generated websitetimeboxing - ou seja, o escopo e a qualidade (em termos dos defeitos descobertos não corrigidos) são ativamente gerenciados para atenderem a data de encerramento.

Durante a Fase de Elaboração:

Três drivers principais definem os objetivos de uma iteração na fase de elaboração:

  • Risco
  • Importância
  • Cobertura

Os riscos são o driver principal para a definição de objetivos da iteração. É preciso diminuir ou eliminar os riscos o mais cedo possível. Essa é, em geral, a questão principal da fase de elaboração, quando a maioria dos riscos deve ser diminuída. No entanto, ela pode continuar sendo um elemento-chave durante a fase de construção, já que alguns riscos permanecem altos e outros novos são descobertos. Entretanto, como o objetivo da fase de elaboração é criar a baseline da arquitetura, algumas outras considerações devem ser feitas, como garantir que a arquitetura englobe todos os aspectos do software a ser desenvolvido (cobertura). Isto é importante, pois a arquitetura será usada para planejamento adicional: organização da equipe, avaliação do código a ser desenvolvido, etc.

Finalmente, apesar da importância de concentrar-se nos riscos, não se esqueça da missão principal do sistema. Solucionar todos os problemas é aconselhável, mas isto não deve ser feito em detrimento da funcionalidade central: certifique-se de que as funções ou os serviços críticos do sistema estejam realmente cobertos (criticalidade), mesmo que nenhum risco associado a eles seja percebido.

Na Lista de Riscos, para os riscos que causam maiores danos, identifique algum cenário em alguns casos de uso que force a equipe de desenvolvimento a "confrontar" o risco.

Exemplos

  • se houver algum risco de integração, como "banco de dados D funcionando corretamente com S.O. Y", certifique-se de incluir um cenário que envolva alguma interação do banco de dados, mesmo que seja bem reduzida.
  • se houver algum risco de desempenho, como "tempo para calcular a trajetória da aeronave", certifique-se de ter um cenário que inclua esse cálculo, pelo menos para o caso mais óbvio e freqüente.

Quanto à criticalidade, garanta que as funções ou os serviços mais fundamentais fornecidos pelo sistema sejam incluídos. Selecione algum cenário no caso de uso que represente a forma mais comum e freqüente do serviço ou da característica oferecidos pelo sistema. O Artefato: Documento de Arquitetura de Software é utilizado para orientar esse esforço, fornecendo um conjunto priorizado de Casos de Uso ou subfluxos de casos de uso, selecionado pela Atribuição: Arquiteto de Software, a fim de refletir os casos de uso ou cenários significativos de forma arquitetural.

Exemplo

  • no caso de uma central telefônica, uma chamada comum estabelecida entre estações é o elemento óbvio para uma iteração inicial. O estabelecimento correto dessa condição inicial é mais importante do que os modos complexos de falha na configuração do operador do subsistema de tratamento de erros.

Quanto à cobertura, ao fim da fase de elaboração, inclua cenários que abordem as áreas que precisarão de desenvolvimento, mesmo elas não sejam críticas nem apresentem riscos.

Costuma ser mais econômico criar cenários longos, de ponta a ponta, que englobem várias questões de uma vez.

Em geral, o perigo consiste em cenários muito "densos", ou seja, aqueles que tentam cobrir demasiados aspectos, variantes e casos de erros distintos (Consulte Diretrizes: Plano de Iteração)

Além disso, na fase de elaboração, lembre-se de que a natureza de alguns riscos pode ser mais humana ou programática: cultura de equipe, treinamento, seleção de ferramentas, técnicas novas e outros. O prosseguimento da iteração consiste na diminuição desses riscos.

Exemplos

  1. Crie um registro de assinante em uma estação de trabalho cliente, que deverá ser armazenado no banco de dados do servidor. Ele deve conter caixas de diálogo do usuário, mas não todos os campos e pressupor que nenhum erro foi detectado.
    Combina alguma função crítica com alguns riscos de integração (banco de dados e software de comunicação) e questões de integração (trabalhar com duas plataformas distintas). Também força os designers a se familiarizarem com a nova ferramenta de design da interface gráfica do usuário. Por fim, produz um protótipo que pode ser demonstrado para o feedback do usuário.
  2. Certifique-se de que até 20.000 assinantes possam ser criados e de que o acesso a um deles não dure mais do que 200 milissegundos.
    Aborda algumas questões fundamentais de desempenho (volume ou dados e tempo de resposta), que podem afetar dramaticamente a arquitetura se não forem solucionadas.
  3. Desfaça uma mudança de endereço do assinante.
    Um simples recurso que força os designers a elaborarem um design de todas as funções de "desfazer". Por outro lado, também pode apresentar alguma desvantagem para os usuários, no sentido do que pode ser desfeito por um custo razoável.
  4. Complete todos os casos de uso relativos ao gerenciamento da cadeia de suprimentos.
    O objetivo da fase de elaboração também é concluir a captura de requisitos, que pode ser feita conjunto a conjunto.

Durante a Fase de Construção:

À medida que o projeto passa para a fase de construção, os riscos continuam sendo um impulsionador importante, principalmente porque riscos novos e imprevisíveis são descobertos. No entanto, a conclusão do caso de uso começa a ser também um impulsionador. Cada característica das iterações pode ser planejada, na tentativa de concluir as mais críticas antes, para que possam ser totalmente testadas durante mais de uma iteração. Próximo ao fim da fase de construção, a resistência de casos de uso completos será o principal objetivo.

Exemplo

  1. Implemente todas as variantes de encaminhamento de chamada, inclusive as erradas.
    Esse é um conjunto dos recursos relacionados. Uma delas pode ter sido implementada durante a fase de elaboração e servirá como protótipo para o resto do desenvolvimento.
  2. Complete todas as características do operador telefônico, exceto o serviço noturno.
    Mais um conjunto de recursos.
  3. Obtenha 5.000 transações por hora em uma configuração de dois computadores.
    Isto pode progredir até o desempenho necessário relativo ao que foi realmente obtido na iteração anterior (somente 2.357/hora)
  4. Integre a nova versão do Sistema de Informações Geográficas.
    Essa pode ser uma pequena mudança arquitetural, exigida por algum problema descoberto anteriormente.
  5. Corrija todos os defeitos dos níveis 1 e 2
    Corrige os defeitos descobertos durante os testes da iteração anterior e que não foram corrigidos imediatamente, mas adiados.

Durante a Fase de Transição:

O objetivo principal é a conclusão da construção do produto. Os objetivos de uma iteração são definidos em termos dos bugs que serão solucionados, das melhorias de desempenho ou de utilização que serão incluídas. Se recursos precisaram ser eliminados (ou desativados) para manter o prazo final da construção (marcos de IOC ou "beta"), eles poderão ser concluídos agora ou ativados, caso não comprometam o que já foi obtido até o momento.

Exemplos

  1. Corrija todos os problemas de gravidade 1 descobertos em locais beta do cliente.
    Um objetivo em termos de qualidade pode estar relacionado à credibilidade no mercado.
  2. Elimine todos os travamentos de inicialização provocados por dados incompatíveis.
    Mais um objetivo expresso em termos de qualidade.
  3. Obtenha 2.000 transações por minuto.
    Ajuste de desempenho, envolvendo alguma otimização: mudança de estrutura de dados, armazenamento em cache e algoritmos mais inteligentes.
  4. Reduza em 30% o número das diversas caixas de diálogo.
    Melhore a utilização reduzindo a interferência visual
  5. Produza versões em alemão e japonês.
    A versão beta foi produzida apenas para os clientes do idioma inglês por falta de tempo e para reduzir a carga de retrabalho.

Definir os Critérios de Avaliação de Iteração Ir para o início da página

Cada iteração resulta em um release executável. Em geral, o release não é de alta qualidade (exceto no final da iteração de Transição), mas, ainda assim, pode ser avaliado.

Avaliando Iterações de Abertura

Em geral, a iteração de Iniciação enfoca a prova de conceito do produto e a criação do suporte necessário à aprovação de fundos para o projeto. Como conseqüência, o release da Iteração é, geralmente, um protótipo de prova de conceito, que ainda não teve um verdadeiro código de implementação sob uma camada superficial da interface do usuário. Os critérios de avaliação são orientados para a aceitação do usuário e medidas qualitativas.

Em algumas circunstâncias, questões técnicas importantes devem ser solucionadas na fase de abertura, antes da liberação do financiamento do produto. Nesse caso, os critérios de avaliação devem refletir esse aspecto.

Consulte os critérios de avaliação para a fase de abertura.

Avaliando Iterações de Abertura

As Iterações de Elaboração enfatizam a criação de uma arquitetura estável. Conseqüentemente, os critérios da avaliação da fase de Elaboração devem enfocar a avaliação da estabilidade da arquitetura. As medidas que podem ser usadas são:

  • Estabilidade (ou quebra) da interface
  • A taxa de mudanças efetuadas na Arquitetura (comparadas a uma baseline arquitetural)
  • Desempenho de funcionalidade-chave

O objetivo-chave é garantir que as mudanças efetuadas durante a fase de Construção não se propaguem pelo sistema, causando excesso de retrabalho.

Consulte os critérios de avaliação para a fase de elaboração.

Avaliação de Iterações de Construção e de Transição

As iterações de Construção e Transição são medidas durante os testes tradicionais de software e dimensões de gerenciamento de mudanças, como quebra, densidade do defeito e taxas de detecção de falhas. A ênfase dessas iterações está em encontrar erros para que eles possam ser solucionados.

Os erros são descobertos de diversas maneiras: inspeções e revisões de código, testes funcionais, testes de desempenho e testes de carga. Cada técnica é orientada para a descoberta de determinado conjunto de defeitos e cada uma tem seu espaço. As especificações dessas técnicas serão abordadas na disciplina Teste do Rational Unified Process (RUP).

Consulte os critérios de avaliação para a fase de construção e veja também os critérios de avaliação para a fase de transição.

Definir as Atividades de Iteração Ir para o início da página

De acordo com as metas da iteração, o conjunto de atividades a serem realizadas durante a iteração deve ser selecionado. Normalmente, cada iteração percorrerá parcialmente todas as atividades do ciclo de vida do software:

  • Os casos de uso e os cenários selecionados que testam a funcionalidade requerida
  • O comportamento do caso de uso (ou do cenário) é pesquisado e documentado
  • O comportamento é analisado e alocado entre os subsistemas e classes que apresentam esse comportamento necessário
  • As classes e os subsistemas são projetados, implementados e testados por unidade
  • O sistema é integrado e testado como um todo
  • Para os releases externos (alfa, beta e disponibilidade geral), o produto é empacotado em uma forma apresentável e que pode ser utilizado no ambiente do usuário.

O grau de realização dessas atividades varia de acordo com a iteração e a fase do projeto. As disciplinas individuais (Requisitos, Análises, Design, Testes e outras) definem as atividades genéricas que, por sua vez, são adaptadas à organização durante a configuração do processo.

Identificar os Artefatos Afetados e as Atividades Envolvidas

Depois que os cenários ou os casos de uso completos que serão desenvolvidos (e os defeitos que serão corrigidos) forem selecionados e rapidamente esboçados, será preciso identificar os artefatos que serão afetados:

  • Que classes serão revistas?
  • Que subsistemas serão afetados ou mesmo criados?
  • Que interfaces serão provavelmente modificadas?
  • Que documentos têm que ser atualizados?

Em seguida, retire das disciplinas de processo as atividades envolvidas e insira-as em seu plano. Algumas atividades são realizadas uma vez por iteração (exemplo), outras têm que ser realizadas uma vez por classe, por caso de uso, por subsistema (exemplo). Relacione as atividades às suas respectivas dependências óbvias e aloque algum esforço estimado. A maioria das atividades descritas para o processo são rápidas o suficiente para serem realizadas por uma pessoa ou por um pequeno grupo em um período que pode variar de algumas horas a alguns dias.

É provável que o caso descoberto não tenha tempo suficiente para ser completamente desenvolvido na fase de iteração. Em vez de estender a iteração (e, portanto, adiar o prazo final de liberação ou reduzir o número de iterações), reduza os objetivos da iteração. Dependendo da fase em que você está, simplifique cenários, elimine ou desative características.

Atribuir Responsabilidades Ir para o início da página

Depois de definido o conjunto de atividades para a iteração, ele deve ser atribuído a membros individuais da equipe do projeto. Dependendo dos recursos de equipe disponíveis e do escopo da iteração, as atividades podem ser realizadas por uma única pessoa ou por uma equipe. Naturalmente, Revisões e Inspeções são atividades de equipe. Outras atividades, como a criação de casos de uso ou o design e a implementação de classes, são inerentemente individuais (exceto no caso em que um membro júnior da equipe trabalhe com um sênior que atue como mentor).

Em geral, cada produto de trabalho deve ser de responsabilidade de uma única pessoa, mesmo que o trabalho seja feito por uma equipe:

  • Casos de uso
  • Subsistemas
  • Classes
  • Testes e planos de teste
  • etc.

Sem um único ponto de contato, garantir a consistência torna-se quase impossível.



Rational Unified Process   2003.06.15