Postagem em destaque

Procurando Profissional em Análise de Processos de Negócios, BPM, BPMS e Melhoria de Processos, para atuar na Região Metropolitana de Belo Horizonte?

Marco Gandra Brasileiro – Casado 41 anos - CNH B Nascido em Belo Horizonte e-mail gandraribeiro@gmail.com ...

Pesquisar neste blog

15 de mai de 2012

Reduzindo a incerteza arquitetural

Por:  Marco Mendes
Em: http://marcomendes.com/blog/2012/05/reduzindo-a-incerteza-arquitetural/


Uma das grandes dificuldades no processo de criação de arquiteturas é capturar os requisitos que realmente importam para a arquitetura (Requisitos Arquiteturais).
Uma técnica para auxílio neste processo é fornecida por uma ferramenta da psicologiachamada de Janela de Johari que também usada em alguns círculos de engenharia de requisitos.
Adapto este conceito para o contexto de arquitetura de software, exibido na figura abaixo.
A figura mostra nem todo requisito é conhecido pelo nosso time e pelos nossos usuários e este desconhecimento (nosso, dos usuários ou de ambos) é fonte de muitos problemas.
Vamos contextualizar o conceito em um exemplo didático de um sistema de Internet Banking. É natural (para qualquer arquiteto e para os usuários chave de um Banco de Crédito) que aspectos de segurança devem afetar a arquitetura executável do produto sendo criado. Portanto, aspectos de autenticação, autorização e transporte seguro estariam no quadrante Q1, que é o dos requisitos arquiteturais óbvios. Até agora não temos nenhum problema.
Vamos considerar agora alguns requisitos de qualidade interna como a manutenibilidade ou a testabilidade, que são normalmente conhecidos pelo nosso time. Normalmente aspectos de qualidade interna não são percebidos diretamente pelos usuários chave, o que os coloca no quadrante Q4. Portanto, arquitetos devem tomar cautela extrema com estes requisitos pois eles não são normalmente percebidos pelos usuários e portanto não valorizados. A consequência é que eles podem causar aos usuários a sensação de baixa produtividade na execução de código pelo time de desenvolvimento. Ainda pior, eles podem encarecer o seu projeto sem percepção de valor similar para os seus usuários.
Vamos agora considerar alguma norma obscura do Banco Central que lide com algum aspecto regulatório. Se a maturidade dos usuários envolvidos no projeto e da equipe de arquitetura for baixa, este requisito regulatório, que pode afetar a arquitetura, estaria colocado no quadrante Q3. A lição aqui é óbvia. Os usuários normalmente não conhecem todos os requisitos e portanto devemos buscar requisitos que podem afetar a arquitetura em outras fontes de informação.
Finalmente, vamos lidar os requisitos mais perigosos, que são elementos óbvios para os usuários mas não óbvios para o time. Por exemplo, o usuário pode assumir que a portabilidade entre navegadores para dispositivos móveis é dada. O time, por sua vez, pode nem ter considerado esta possibilidade. Tipicamente estes requisitos do quadrante Q2 são fontes de desgaste durante o projeto e envolvem retrabalho para o time pois afinal eles são“óbvios” para os usuários.
Em cenários ideais gostaríamos de mover todos os requisitos para o quadrante 01, mas o fato é que sempre haverá requisitos nos quadrantes Q2, Q3 e Q4 também. Naturalmente a aplicação de métodos arquiteturais de coleta de requisitos reduzirá a probabilidade que isto aconteça. Algumas dicas rápidas para isso incluem:
  • Realizar reuniões e oficinas de trabalho para mover os requisitos do quadrante Q2 para o quadrante Q1. Técnicas de leitura ambiental também são úteis neste contexto.
  • Buscar outras fontes de informação além do ambiente e informações fornecidos pelos próprios usuários podem mover alguns requisitos do quadrante Q3 para o quadrante Q1.
  • Educar usuários sobre os requisitos que eles não conhecem pode ajudar a levar requisitos do quadrante Q4 para Q1. Em outras situações, talvez devamos remover alguns requisitos de Q4 do escopo do nosso projeto.

Nenhum comentário:

Postar um comentário