Vista a uma distância de 6.000 metros, não há muito que diferencie uma avaliação de arquitetura de software de qualquer outra avaliação ou revisão.

No entanto, uma característica importante da arquitetura de software é a falta de medições específicas para vários atributos de qualidade arquitetural - somente algumas qualidades arquiteturais podem ser objetivamente medidas. O desempenho é um exemplo em que a métrica é possível. Outras qualidades são mais qualitativas ou subjetivas: integridade conceitual, por exemplo. Além do mais, geralmente é difícil decidir o que significa uma métrica na ausência de outros dados ou referências que possibilitem uma comparação. Se um sistema de referência estiver disponível e for compreendido pelo público-alvo, em geral, é conveniente expressar alguns resultados da revisão relativos a esse sistema de referência. Isso pode acontecer em um contexto em que o sistema que está sendo projetado possa ser comparado com um design anterior.

Quando essa avaliação ocorre no ciclo de vida, sua finalidade ou utilidade também é afetada.

1. No final da fase de iniciação de um ciclo de desenvolvimento inicial, há geralmente muito pouco que possa ser considerado uma arquitetura concreta. No entanto, uma revisão pode revelar alguns objetivos realistas, partes ausentes, falta de oportunidades para reutilização de produtos existentes etc.
2. O momento mais comum para uma avaliação da arquitetura de software é no final da fase de elaboração. Essa fase enfoca basicamente a exploração detalhada dos requisitos e a criação da linha de base de uma arquitetura. Uma revisão de arquitetura é administrada pelo RUP nesse marco. Nesse ponto, uma vasta gama de qualidades arquiteturais é examinada.
3. Avaliações mais focalizadas podem desenrolar-se na fase de construção para examinar atributos de qualidade específicos, como o desempenho ou a segurança e, no final da fase de construção, para quaisquer problemas remanescentes que possam tornar o produto inadequado para a liberação aos seus usuários.
4. As avaliações de controle de danos podem ser efetuadas no final da fase de construção ou mesmo na de transição, quando tudo já saiu realmente errado: a construção não foi concluída ou um nível inaceitável de problemas surgiu na base instalada durante a transição.
5. Finalmente, uma avaliação pode ser realizada no final da fase de transição, mais especificamente para inventariar ativos reutilizáveis de um novo produto ou ciclo de evolução.

O revisor "parceiro" tem o mesmo perfil profissional da Função: Arquiteto de Software, embora com um enfoque mais minucioso nos problemas técnicos. Liderança, maturidade, pragmatismo e orientação com base em resultados são aspectos importantes em menor grau, mas, ainda assim, importantes - um revisor pode revelar defeitos de arquitetura que podem não vir a ser conhecidos se ameaçarem o cronograma do projeto. Todavia, é melhor levantar problemas críticos no início, quando eles podem ser resolvidos, do que seguir cegamente um cronograma que leva a equipe do projeto para o caminho errado. O revisor de arquitetura deve contrabalançar os riscos e os custos, permanecendo sensível a questões mais amplas que influenciam no êxito do projeto. O revisor de arquitetura também deve ser um comunicador persuasivo, que possa levantar e discutir questões importantes.

Diversas abordagens podem ser usadas para realizar a revisão:

• orientada a representações
• orientada a informações
• orientada a cenários

Revisão orientada a representações

Obtenha (ou crie) uma representação da arquitetura e, em seguida, faça perguntas e colocações com base nessa representação.

Há uma variedade de situações aqui: organizações que são letradas em arquitetura e fornecerão alguma descrição inteligível para começar, organizações em que você precisará identificar quem é o arquiteto de software (que poderá, até mesmo, estar oculto sob algum outro nome) e extrair informações dessa pessoa, um local em que a arquitetura de software é um conceito totalmente desconhecido. Esse processo é então chamado de "extração da arquitetura" e, na prática, parece literalmente a extração do software ou de sua documentação com uma picareta, examinando o código fonte, as interfaces, os dados de configuração, etc.

Um modelo que pode ser utilizado para organizar a representação encontra-se no formato das visualizações arquiteturais apresentadas no Documento de Arquitetura de Software: a visualização lógica organiza as classes principais (o modelo de objeto), a visualização do processos descreve os principais encadeamentos de controle e como eles se comunicam, a visualização de desenvolvimento mostra os vários subsistemas e suas dependências e a visualização física descreve o mapeamento dos elementos das outras visualizações em uma ou várias configurações físicas. Organize os problemas de acordo com as várias visões.

Revisão orientada a informações

Estabeleça a lista de informações - dados, medições - que será necessária para o raciocínio, obtenha as informações e compare-as com os requisitos ou com um padrão de referência aceito. Isso se aplica bem à investigação de determinados atributos de qualidade, como o desempenho ou a sofisticação.

Revisão orientada a cenários

Trata-se de uma abordagem "condicional" sistemática. Transforme as questões gerais que estão sendo perguntadas em um conjunto de cenários que o sistema deve percorrer e faça perguntas com base nos cenários. Aqui estão alguns exemplos desses cenários:

• O sistema é executado nas plataformas X e Y. (O atributo de qualidade real investigado é a portabilidade.)
• O sistema executa essa função F (adicional). (O atributo de qualidade real é a extensibilidade.)
• O sistema processa 200 solicitações por hora. (O atributo de qualidade real é a escalabilidade.)
• O sistema está sendo instalado neste tipo de site pelo usuário. (O atributo de qualidade real é a totalidade ou usabilidade.)

A vantagem dessa abordagem é que ela coloca a tarefa em uma perspectiva bastante concreta, que pode ser compreendida por todas as partes. Ela também permite investigar omissões ou falhas nos requisitos, especialmente quando estes são informais ou tradicionais ou muito gerais e concisos. A desvantagem é que ela não captura a própria arquitetura como objeto da revisão, mas considera o sistema como uma caixa preta que estamos somente investigando.

Na prática, essas abordagens não são tão claramente separadas e, por isso, acabamos adotando um pouco das três abordagens.

Identificação de problemas

Revelar possíveis problemas é, na maioria das vezes, uma decisão tomada por seres humanos com base no conhecimento e na experiência. Determinados padrões de falha são repetidos a cada projeto e em todas as organizações. Uma certa heurística pode ser usada para revelar as áreas problemáticas. As listas de verificação podem ser úteis (algumas bastante genéricas são propostas mais adiante), bem como os resultados das revisões anteriores, se houver alguma.

Capture os possíveis problemas conforme eles aparecerem, descrevendo-os em um tom neutro - sem acusações, nem "catastrofismo". Você pode utilizar pequenos cartões como fazem os revisores da AT&T ou como fazemos com os cartões de CRC, para ajudar a priorizar, organizar e eliminar.

Posteriormente, classifique os possíveis problemas diminuindo o escopo ou o impacto e, se houver muitos, ataque primeiro aqueles que estão diretamente relacionados à questão que interessa no momento, deixando as "outras sugestões" para depois, se o tempo permitir. Em seguida, seja realista com relação ao problema; muitas vezes, alguém detecta um problema, mas talvez não se trate realmente de um problema. Simplesmente não falamos com a pessoa certa, não observamos as informações certas. Classifique novamente. Confirme vários pontos de dados para verificar a realidade do problema. (Os avaliadores inexperientes tendem a ser muito simplistas.)

Quando o problema for confirmado, analise rapidamente o que poderia eliminá-lo, sem que seja necessário trabalhar em um novo design do sistema às pressas. Anote as possíveis simplificações, reaproveitamento e alternativas (por exemplo, comprar vs. criar).

Após a revisão, aloque responsabilidade para cada defeito identificado. "Responsabilidade" nesse caso, talvez não signifique corrigir o defeito, mas coordenar uma investigação adicional de alternativas ou coordenar a resolução do defeito, caso ela seja difícil de se obter ou tenha um escopo amplo.