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.
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:
-
Apresentação do método QAW pelo moderador acrescida das devidas introduções.
-
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.
-
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.
-
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.
-
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”.
-
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.
-
Priorização de cenários usando um esquema baseado em votação.
-
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.
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”.