Atividade:
|
Finalidade
|
|
Função: Revisor Técnico | |
Freqüência: Pelo menos uma vez por iteração, especialmente durante a fase de elaboração. | |
Etapas | |
Artefatos de Entrada: | Artefatos Resultantes: |
Mentores de Ferramentas: | |
More Information: |
Detalhes de Workflow: |
Finalidade | Recomendações gerais para cada revisão. |
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 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.
O revisor "parceiro" tem o mesmo perfil profissional da Função:
Arquiteto de Software, embora com enfoque mais
minucioso nas questões técnicas. 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.
Finalidade | Definir o escopo e as metas da revisão. Definir as abordagens utilizadas para cada combinação específica de escopo/meta. |
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 é chamado ainda 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.
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.
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 acusar ninguém, nem tratar o problema como se fosse uma "catástrofe". Você pode utilizar 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, 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).
Finalidade | Corrigir os defeitos identificados. |
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.
Rational Unified Process
|