Qual é um bom método para fazer a avaliação de arquitetura leve?

Estou familiarizado com os métodos de avaliação de arquitetura, como o ATAM (Architecture Tradeoff Analysis Method) técnico e o CBAM (Cost Benefit Analysis Method ) mais voltado para os negócios . No entanto, esses métodos são de grande escala: eles prescrevem várias sessões de brainstorming, apresentações, desenvolvimento de uma série de cenários que descrevem trocas, etc. Embora úteis para projetos de um determinado tamanho, são grandes demais para projetos internos ou aplicativos de desktop desenvolvido por um punhado de desenvolvedores (ou menos), que, apesar de pequenos, possuem algumas restrições de qualidade bastante acentuadas (desempenho, escalabilidade, adaptabilidade).

Uma prática típica que usei no passado é ter um desenvolvedor (ou o arquiteto se uma equipe tiver um) para criar uma arquitetura geral para o aplicativo e discuti-la em um quadro branco com o restante da equipe, normalmente usando alguma notação pseudo-UML fácil de desenhar e entender. Isso normalmente leva a comentários e algumas iterações na arquitetura. Mas tende a ser um pouco informal demais, fazendo com que todos os tipos de suposições sejam feitas e que possam vir a ser decisões erradas.

Métodos como o ATAM normalmente forçam todos os interessados ​​a pensar profundamente sobre a arquitetura, o que leva a discussões até que todos pelo menos concordem com o que exatamente é a arquitetura .

Alguém tem experiência em fazer avaliação leve de arquitetura inicial? Em caso afirmativo, quais são as boas práticas?

A chave para uma avaliação leve é ​​avaliar as coisas certas no momento certo. Conheço duas maneiras de fazer isso de maneira eficaz. Com a avaliação baseada em cenário, você usa cenários de atributos de qualidade e casos de uso para conduzir a avaliação focando apenas nos atributos de qualidade de alta prioridade. Com a avaliação baseada em riscos , você identifica riscos e permite que os riscos identificados direcionem suas atividades de design de arquitetura.

Posso recomendar dois livros que exploram essas duas abordagens (um pouco relacionadas).

O software Architecting Intensive Systems, de Anthony Lattanze, apresenta a Metodologia de Projeto Centrado na Arquitetura e abrange avaliações leves baseadas em cenários. Você pode reconhecer Lattanze no Workshop de atributos de qualidade do SEI e há idéias semelhantes envolvidas.

Arquitetura de software suficiente: uma abordagem orientada a riscos de George Fairbanks introduz, bem, uma abordagem orientada a riscos para projetar e avaliar a arquitetura de um sistema de software. Há também alguns capítulos gratuitos disponíveis no site dele, se você quiser uma prévia. Embora os princípios deste livro sejam imediatamente aplicáveis, a abordagem não vem com um método específico; portanto, você precisará combinar idéias de outras áreas. Eu recomendo a abordagem de gerenciamento de riscos contínua do SEI para identificar / priorizar riscos.

A idéia básica por trás dessas abordagens é que você reduz o custo da avaliação (e do design) avaliando à medida que avança, em vez de esperar até o final. Embora isso certamente seja um pouco mais pesado do que falar em torno de um quadro branco, não é tão caro quanto um ATAM totalmente queimado. E se você estiver confortável, poderá escolher práticas práticas para atender às suas necessidades específicas.

Não importa qual abordagem você use para conduzir a avaliação, a idéia geral será a mesma ...

Antes que você comece:

• Cenários ou riscos de atributos de qualidade, priorizados (podem ser informais se você tiver tudo isso)
• Definição clara para a decisão de não aprovação (como você sabe que a arquitetura é "suficientemente boa")
• Corte mais recente da descrição da arquitetura (o artefato que você está avaliando)

Sente-se para uma sessão de avaliação:

• Arquiteto apresenta uma visão geral da arquitetura
• Percorra uma visão, mostre como o cenário ou risco é satisfeito
• Os problemas são registrados para serem corrigidos posteriormente
• As funções e os procedimentos gerais são semelhantes aos usados ​​para uma inspeção Fagan (arquiteto ou autor, moderador, gravador).
• A sessão pode levar apenas uma ou duas horas, dependendo do tamanho do seu sistema.

Depois que a sessão terminar:

• Revise os problemas identificados e determine se os critérios de aprovação / não aprovação são atendidos. Geralmente, são necessárias cerca de três avaliações para que tudo funcione. Se não for atendido, continue refinando e experimentando (ou mitigando os riscos da arquitetura).
• Esta não é uma avaliação "tudo ou nada" - diferentes partes da sua arquitetura podem "passar" enquanto outras ainda precisam de aprimoramento.

Para ajudar você a ter uma ideia de como pode ser a abordagem com base em cenários, há alguma documentação pública de um projeto no qual eu trabalhei na pós-graduação. A documentação é um pouco grosseira, mas poderia ajudar a dar alguns exemplos da abordagem baseada em cenário no contexto do ACDM. Nós éramos uma equipe de 5 pessoas e construímos um aplicativo típico baseado na Web, cerca de 35 KLOC Java / GWT.

Eu gosto de discussões informais no quadro branco, para começar. Gosto de escrever apenas a parte do aplicativo necessária hoje e depois gradualmente deixar a arquitetura emergir durante a implementação. É mais como "encontrar a arquitetura", em vez de tentar inventá-la de antemão. Essa abordagem não requer muita avaliação inicial e ajuda a manter o foco no que é importante (fornecer software de trabalho).

Obviamente, se seus requisitos não funcionais exigirem (restrições de memória, tempos de resposta, número de usuários simultâneos etc.), você deve levar isso em consideração ao implementar o sistema.