Atividade:
| |||||||||||||||||
Finalidade
|
|
| Passos | |
| Artefatos Informados: | Artefatos Resultantes: |
| Papel: Revisor de Arquitetura | |
| Diretrizes: | |
| Pontos de Verificação: | |
| Detalhamentos do Fluxo de Trabalho: |
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: a 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 com relação 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.
Diversas abordagens podem ser usadas para realizar a revisão:
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 é denominado "explorar a arquitetura" e, na prática, se parece literalmente com a escavação do software ou de sua documentação com uma picareta, observando códigos-fonte, interfaces, dados de configuração etc.
Um modelo que pode ser usado para organizar a representação está no formato das visões arquiteturais apresentadas no Documento de Arquitetura de Software: a visão lógica organiza as classes principais (o modelo de objetos), a visão de processos descreve os principais threads de controle e como eles se comunicam, a visão de desenvolvimento mostra os vários subsistemas e suas dependências, e a visão física descreve o mapeamento dos elementos das outras visões em uma ou várias configurações físicas. Organize os problemas de acordo com as várias visõ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 algum padrão de referência aceito. Isso se aplica bem à investigação de determinados atributos de qualidade, como o desempenho ou a sofisticação.
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:
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.
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 quando eles aparecerem, descrevendo-os em um tom neutro - sem indicações diretas, sem "catastrofismo'. Você pode usar pequenos cartões como fazem os revisores da AT&T ou como fazemos com os cartões de CRC, para ajudar na priorização, organização e eliminação.
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, descreva o 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 eliminar o problema, sem que seja necessário trabalhar em um novo design do sistema às pressas. Anote possíveis simplificações, reutilizações, alternativas: comprar x criar.
Finalidade
|
Após a revisão, aloque responsabilidade para cada defeito identificado. "Responsabilidade", neste 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.
|
Rational Unified Process
|
