No curso de pós graduação (Engenharia de Software Centrada em Métodos Ágeis coordenado pelo Edgard Davidson), durante a matéria de Arquitetura, o professor Marco Mendes nos pediu um resumo sobre Quality Atribute Workshop. Como meu tempo é bem curto, eu fiz um resumo me baseando em 2 referências:

http://blog.arkhi.com.br/2008/11/01/qaw/

http://www.sei.cmu.edu/architecture/tools/establish/qaw.cfm

Vocês vão notar que é uma mescla do que está escrito em ambos os sites, portanto, deixo aqui os créditos aos autores.

O Quality Atribute Workshop (QAW) fornece um método para identificar requisitos não funcionais que são derivados da missão e das regras de negócio (ex: disponibilidade, performance, segurança, interoperabilidade e modificabilidade).

O QAW não assume que a arquitetura do software já exista. Foi feito para complementar o Architecture Tradeoff Analysis Method (ATAM) do Software Engineering Institute (SEI) como resposta a pedidos por um método que identificasse atributos importantes de qualidade e clareasse requisitos do sistema antes que exista uma arquitetura na qual o ATAM possa ser aplicado.

Em geral, sem o uso de um método para captura dos requisitos de qualidade, há uma lacuna entre a exposição das necessidades de negócio e a identificação dos requisitos arquiteturais.Imagem demonstrando onde o QAW age

Fonte: Quality Attribute Workshops (QAWs), Third Edition – Barbacci et al

Desafios

  • Como você pode determinar quais requisitos de atributos de qualidade são importantes antes do sistema ser construído?

  • Como você pode descobrir necessidades e expectativas dos stakeholders de forma organizada e efetiva?

  • Como você aumenta e melhora a comunicação entre stakeholders?

No QAW, um time externo facilita reuniões entre os stakeholders durante as quais os cenários que representam os requisitos de atributos de qualidade são gerados, priorizados e refinados. O processo de refinar cenários permite aos stakeholders comunicar entre eles, expondo fatos que não emergiram durante a elicitação de requisitos.

Tudo termina com uma lista de cenários priorizados e refinados que pode ser usada de formas diferentes, como por exemplo, alimentar cenários para ATAM ou casos de teste.

 Os seguintes passos estão envolvidos:

  1. Apresentação do método QAW pelo moderador acrescida das devidas introduções.

  2. Apresentação das diretrizes de negócio / missão mostrando os interesses envolvidos, contexto do sistema, requisitos funcionais de alto-nível, restrições, etc.

  3. Apresentação de um plano arquitetural: Embora a arquitetura em si ainda não exista, é possível demonstrar uma estrutura candidata para solução do problema, diagramas de contexto, restrições chave (ex: SGBD, SO, middleware, padrões), etc.

  4. Identificação das diretrizes arquiteturais: Aproveitando um intervalo de 15 minutos entre os passos 3 e 4, os facilitadores consolidam suas notas sobre os requisitos e objetivos identificados nos passos anteriores.

  5. Brainstorming de cenários: Seguindo uma cerimônia no estilo round-robin, procura-se identificar com os stakeholders os cenários relevantes. O facilitador deve ajudar o stakeholder a obter cenários bem formados, isto é, com estímulo, ambiente e resposta. Exemplo de cenário: “um usuário remoto submete um formulário via web durante o período de pico e recebe uma resposta em até seis segundos”.

  6. Consolidação de cenários: Além de reduzir as informações a serem tratadas, a consolidação evita a dispersão de votos do passo 7.

  7. Priorização de cenários usando um esquema baseado em votação.

  8. Refinamento dos cenários prioritários garantindo que cada cenário prioritário seja descrito, entre outras coisas, pelos seis elementos (figura 2) e apresente atributos de qualidade associados a ele.

Cenário que envolve o QAW

Fonte: Software Architecture in Practice, 2n Edition – Bass, Clements, Kazman

 Organizações podem usar o QAW para:

  • atualizar a visão arquitetural

  • refinar requisitos de sistema e software

  • guiar a criação de protótipos

  • exercitar simulações

  • entender e clarear as diretivas arquiteturais de sistema

  • influenciar a ordem em que a arquitetura é desenvolvida

  • descrever a operação do sistema

Benefícios

Determinar as qualidades do seu sistema antes que ele seja desenvolvido é crucial para a satisfação dos stakeholders e para o sucesso do projeto. Clarear os requisitos e alcançá-los na primeira versão do seu sistema poupa dinheiro e evita retrabalho.

Com requisitos de qualidade mais refinados e devidamente balanceados por vários stakeholders, a equipe de arquitetura terá como insumo uma fonte extremamente valiosa.

Conclusão

O QAW é parecido com Joint Application Design (JAD), porém com uma abrangência menor e em um período de tempo menor. Ambos são importantes para que a elicitação de requisitos seja bem feita e evite o máximo de retrabalho e de erros ao longo do projeto.

Em relação ao JAD, o QAW cabe muito melhor em um projeto que segue diretivas de metodologias ágeis, podendo envolver time e PO para criação de um “backlog arquitetural”.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *