Atividade
|
Finalidade
|
|
Função: Arquiteto de Software | |
Freqüência: Conforme necessário, normalmente uma vez em cada iteração, iniciando com a Elaboração. | |
Etapas | |
More Information: |
Artefatos de Entrada: | Artefatos Resultantes: |
Mentores de Ferramentas: |
Detalhes de Workflow: |
Um arquiteto de software propõe o conteúdo técnico e a ordem das iterações sucessivas, selecionando um determinado número de cenários e casos de uso para serem analisados e projetados. Essa proposta técnica é concluída e refinada pelas várias equipes de desenvolvimento, com base na disponibilidade de pessoal, nos requisitos do cliente em termos de produtos liberados, na disponibilidade das ferramentas e dos produtos de terceiros (COTS) e nas necessidades de outros projetos.
A seleção dos cenários e dos casos de uso que constituem a visualização do caso de uso baseia-se em alguns fatores de direcionamento-chave resumidos a seguir.
É possível haver dois cenários que atinjam os mesmos componentes e tratem de riscos semelhantes. Se A for implementado primeiro, então B não é significativo do ponto de vista da arquitetura. Se B for implementado primeiro, então A não é significativo do ponto de vista da arquitetura. Desse modo, esses atributos podem depender da ordem de iteração e deverão ser reavaliados quando a ordem for alterada, assim como quando os próprios requisitos forem alterados.
Esses fatores de direcionamento devem ser capturados como atributos dos requisitos, para que possam ser gerenciados com eficiência.
Os casos de uso significativos do ponto de vista da arquitetura que são malcompreendidos ou que têm a probabilidade
de serem alterados devem ser priorizados para esclarecimento e estabilização. Em alguns
casos, isso significa a necessidade de análise adicional dos requisitos antes da implementação
do requisito. Em outros, seria melhor alguma forma de realização de protótipo.
A visão de casos de uso é documentada na seção correspondente do Documento de Arquitetura de Software. Essa seção contém uma listagem dos casos de uso e cenários significativos dentro de cada pacote do modelo de casos de uso, além de propriedades significativas, como as descrições do fluxo de eventos, dos relacionamentos, dos diagramas de casos de uso e dos requisitos especiais relacionados a cada caso de uso. Observe que, se a visão de casos de uso for desenvolvida no início da iteração, algumas dessas propriedades talvez não existam ainda.
A visão de casos de uso deve ser verificada nesta fase, apenas para confirmar se o trabalho está caminhando bem. Não é necessária uma revisão detalhada da visão de casos de uso. Consulte principalmente os pontos de verificação da visualização de casos de uso em Atividade: Revisar a Arquitetura.
Rational Unified Process
|