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 de casos de uso que são considerados "arquiteturalmente significativos" (por exemplo,
constituir a visualização do caso de uso da arquitetura) é direcionada por alguns fatores de direcionamento-chave
resumidos a seguir.
-
Benefícios do cenário aos investidores: crítico, importante, útil.
-
O impacto arquitetural do cenário: nenhum, estende, modifica. É possível que haja casos de uso críticos com pouco
ou nenhum impacto na arquitetura e casos de uso de pouco benefício com um grande impacto. Os casos de uso de pouco
benefício com grandes impactos na arquitetura devem ser revisados pelo coordenador de projeto para um possível
cancelamento do escopo.
-
Os riscos a serem diminuídos (desempenho, disponibilidade de um produto e adequação de um componente).
-
A abrangência total da arquitetura (assegurando que, no final da fase de elaboração, cada parte do software a ser
desenvolvido encontrou um espaço na Visão de Implementação).
-
Outros objetivos ou restrições táticas: demonstração para o usuário, etc.
É 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.
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.
Um último ponto a ressaltar: embora o objetivo seja priorizar cenários ou casos de uso, os fatores de
direcionamento acima listados envolvem diversos outros aspectos do produto de software: requisitos funcionais e não
funcionais, decisões de design e restrições de gerenciamento do projeto. Além disso, eles têm relevâncias
diferentes para diferentes interessados do projeto de software. Pode ser necessário mapear as diferenças de
percepção dos fatores entre os interessados, de forma a identificar conflitos que podem alterar a significância dos
casos de uso na arquitetura. Veja a Guideline: Teia de Conflitos de Modelo como técnica sugerida para
identificar conflitos.
|
