Atividade:
| ||||||||||||||||
| Finalidade Desenvolver um plano de granulação fina para uma única iteração, que consista em:
|
|
| Passos | |
| Artefatos Informados: | Artefatos Resultantes:
|
| Freqüência: Uma vez por iteração | |
| Papel: Gerente de Projeto | |
| Detalhamentos do Fluxo de Trabalho: |
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 suma, para liberar um produto de qualidade, é preciso algum retrabalho, como: criar produtos intermediários e avaliar a adequação da arquitetura do produto no início e com freqüência. A qualidade do produto final aumenta e as mudanças são menos dispendiosas e mais fáceis de serem incorporadas.
Finalidade
|
| Diretrizes: O Plano de Iteração |
O escopo de uma iteração é orientado por quatro fatores:
No planejamento inicial de uma iteração, é selecionado um volume suficiente de trabalho para preencher o tempo já planejado para a iteração (com base nas considerações exploradas em Diretrizes: Plano de Desenvolvimento de Software) - embora o Gerente de Projeto tenha alguma liberdade para considerar as limitaçõ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. Modelos de estimativa, como COCOMO II (consulte [BOE00]), podem fornecer essa informação.
A execução de uma iteração é, então, gerenciada por timeboxing - ou seja, o escopo e a qualidade (em termos dos defeitos descobertos não corrigidos) são ativamente administrados para que atendam ao prazo final.
Quatro principais impulsionadores definem os objetivos de uma iteração durante a fase de elaboração:
O principal impulsionador para a definição de objetivos da iteração são os riscos. É preciso diminuir ou eliminar os riscos assim que possível. Essa é, em geral, a questão principal da fase de elaboração, quando a maioria dos riscos devem ser diminuídos. No entanto, ela pode continuar sendo um elemento-chave durante a fase de construção, já que alguns riscos permanecem e outros são descobertos. 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). Esse é um fator importante, pois a arquitetura será usada para melhor planejar: a organização da equipe, a análise do código a ser desenvolvido etc.
Por fim, embora seja importante prestar atenção aos riscos, não se esqueça da missão principal do sistema. Solucionar todos os problemas é uma atitude aconselhável, mas essa tarefa não pode ser realizada em detrimento da funcionalidade central: certifique-se de que as funções ou os serviços críticos do sistema sejam realmente cobertos (importância), mesmo que não seja percebido nenhum risco associado a eles.
Na Lista de Riscos, no caso dos riscos que causam maiores danos, identifique algum cenário em um caso 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 SO Y", certifique-se de incluir um cenário que envolva alguma interação do banco de dados, mesmo que seja pequena.
- 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 à importância, 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 é usado para orientar esse esforço. Para isso, oferece um conjunto de casos de uso ou subfluxos de casos de uso priorizados, selecionados por Papel: Arquitetura de Software para refletir os casos de uso ou cenários em termos arquiteturais.
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 muitos aspectos, variantes e casos de erros distintos (consulte Diretrizes: Plano de Iteração)
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
- 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 estações 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.
- 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 drasticamente a arquitetura se não forem solucionadas.
- Desfaça uma mudança de endereço do assinante.
Uma simples característica 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.
- 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 por cada conjunto.
À 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
- Implemente todas as variantes de encaminhamento de chamada, inclusive as erradas.
É um conjunto de características relacionadas. Uma delas pode ter sido implementada durante a fase de elaboração e servirá como protótipo para o resto do desenvolvimento.
- Complete todas as características do operador telefônico, exceto o serviço noturno.
Um outro conjunto de características.
- Obtenha 5.000 transações por hora em uma configuração de dois computadores.
Pode ser configurado o desempenho necessário relacionado ao que foi realmente obtido na iteração anterior (somente 2.357/hora)
- Integre a nova versão do Sistema de Informações Geográficas.
Essa pode ser uma pequena mudança arquitetural, requisitada por algum problema descoberto anteriormente.
- Solucione todos os defeitos de nível 1 e 2
Soluciona os defeitos descobertos durante os testes da iteração anterior e que não foram solucionados imediatamente, mas adiados.
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 usabilidade que serão incluídas. Se alguma característica tiver que ser eliminada (ou desativada) para obedecer ao prazo final da construção (marcos de IOC ou "beta"), elas poderão ser concluídas agora, ou ativadas, caso não comprometam o que já foi obtido até o momento.
Exemplos
- Solucione todos os problemas de gravidade 1 descobertos em locais beta do cliente.
Um objetivo em termos de qualidade pode estar relacionado à credibilidade no mercado.
- Elimine todas as falhas de inicialização provocadas por dados incorretos.
Um outro objetivo expresso em termos de qualidade.
- Obtenha 2.000 transações por minuto.
Ajuste de desempenho, que envolva alguma otimização: mudança de estrutura de dados, armazenamento em cache e algoritmos inteligentes.
- Reduza em 30% o número das diversas caixas de diálogo.
Melhore a usabilidade reduzindo a desorganização visual
- 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.
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.
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 iniciação, 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 iniciação.
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:
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.
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 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 também os critérios de avaliação para a fase de transição.
De acordo com os objetivos 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:
O grau de realização dessas atividades varia de acordo com a iteração e a fase do projeto. As disciplinas individuais (Requisitos, Análise e Design, Teste e outras) definem as atividades genéricas, que, por sua vez, são adaptadas à organização durante a configuração de processos.
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:
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.
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:
Sem um único ponto de contato, garantir a consistência é uma tarefa quase impossível.
|
Rational Unified Process
|
