Na maioria das vezes, não faz muito sentido identificar requisitos fora do contexto de um projeto. Sendo assim, geralmente o QAW é empregado como uma atividade (ou conjunto de atividades) de um processo responsável por todo o ciclo de vida de desenvolvimento do software como o RUP (Rational Unified Process) ou o XP (eXtreme Programming). Neste texto, descrevemos uma possível combinação do QAW com esses processos.

QAW e o ciclo de vida do RUP
O QAW deve ser empregado antes de se modelar a arquitetura. A atividade de arquitetura do RUP mais relacionada ao contexto do QAW é “Desenvolver Especificações Suplementares” (Develop Supplementary Specifications) que deve ser realizada no início do desenvolvimento, isto é, nas fases de Iniciação (ou Concepção) e Elaboração. Conforme o gabarito do RUP, os requisitos não-funcionais podem ser enquadrados como especificações suplementares nos casos de uso.

Algumas tarefas do RUP que também podem ser influenciadas pelo método do QAW são a “Análise Arquitetural” (Architectural Analysis) e “Priorizar Casos de Uso” (Prioritize Use Cases), respectivamente associadas às disciplinas de “Análise e Desenho” e “Requisitos”.

Maiores informações podem ser encontradas no relatório técnico “Integrating Software-Architecture-Centric Methods into the Rational Unified Process”. Ponto de atenção: neste post, adaptei a nomenclatura para ficar coerente com o RUP 7.

QAW e o ciclo de vida do XP
Apesar do XP dar muito pouca ênfase à arquitetura de software (por confiar no valor da “coragem” para uma possível refatoração arquitetural, se necessário), geralmente a arquitetura é capturada na “Metáfora do Sistema” (System Metaphor).

Ao contrário do RUP, o XP originalmente não contempla um gabarito formal que inclua requisitos suplementares. Mas sugere-se suplementar as “Estórias de Usuário” (User Stories) com os requisitos de qualidade (representados com os seis tradicionais atributos). A primeira iteração do projeto é o momento perfeito para o evento de QAW, quando seriam capturados os requisitos de qualidade que devem nortear a metáfora sistêmica. A prática “Cliente presente” facilita o acontecimento do evento.

Outra prática que também contribui para o emprego do QAW é “Jogo de Planejamento” (Planning Game), pois a priorização dos requisitos de qualidade pode auxiliar na escolha das estórias de cada iteração.

Além disto, a prática “Desenvolvimento Guiado por Testes” (Test Driven Development) que potencialmente é favorecida pela identificação dos cenários no evento de QAW. Neste caso, os cenários podem ser usados posteriormente para avaliar o desenho e fornecer insumos para análise dos testes.

Maiores informações podem ser encontradas no relatório técnico “Integrating Software-Architecture-Centric Methods into Extreme Programming”.

QAW e outros processos de desenvolvimento de software
Mesmo que você não use diretamente o RUP ou o XP, possivelmente emprega alguma variante do RUP (ex: EUP, EssUP, OpenUP, etc) ou alguma metodologia ágil (ex: SCRUM, FDD, Crystal Clear). Ou ainda uma combinação de ambos como o AUP e a “dobradinha” RUP + Scrum. Assim poderá aplicar facilamente os fundamentos aqui expostos em qualquer método.

Outras referências:

1. Quality Attribute Workshops (QAWs), Third Edition
2. IBM Rational Unified Process
3. Integrating Architecture Methods: The Case of Extreme Programming
4. RUP in the dialogue with Scrum

1. Coletar Requisitos Suplementares. O RUP enfatiza através de um método chamado FURPS+ criado por Robert Grady e disponibilizado no livro Practical Software Metrics for Project Management and Process Improvement. Prentice-Hall, 1992. Este método enfatiza a captura de requisitos como usabilidade, confiabilidade, desempenho, suportabilidade, entre diversos outros. Um artigo chave para o entendimento do método FURPS+ é o artigo Capturing Architectural Requirements, de Peter Eeles. Um versão em formato de questionário pode ser encontrado aqui.
2. Identificar os casos de uso significativos para análise arquitetural. Em um sistema, apenas um sub-conjunto dos casos de uso são críticos para o negócio e complexos tecnicamente. Este sub-conjunto deve ser exercitado e provado através de uma arquitetura.
3. Realizar a análise arquitetural. A análise arquitetural visa produzir uma arquitetura candidata e refiná-la sucessivamente ao longo do projeto. Esta é uma atividades claramente iterativa e incremental e compreende as definições dos mecanismos (Soluções) que irão realizar os requisitos do projeto.  Um aspecto endereçado aqui é a decomposição em camadas.  A série de artigos referenciados ao final deste blog fornece, também, mais informações sobre este processo.
4. Construir Provas de Conceito Arquiteturais. Durante o processo da análise arquitetural, aspectos de risco do projeto podem merecer uma investigação mais detalhada. Uma prova de conceito no processo unificado pode tomar as seguintes formas: Modelagem conceitual; Protótipo ‘Rápido; Simulação; Conversão automática de especificações em código; Especificações ‘executáveis’ou a Construção de  ‘picos invertidos’ como protótipos – fatias verticais através de camadas.
5. Avaliar Viabilidade das Provas de Conceito Arquiteturais. Toda prova de conceito deve ser avaliada contra os objetivos e requisitos que ela pretende realizar de forma que os riscos associados sejam mitigados.
6. Identificar os mecanismos de design. Esta tarefa lida com o processo de seleção e escolha das tecnologias que irão realizar uma arquitetura.
7. Identificar e incorporar elementos de design. Dado que uma tecnologia esteja escolhida, é necessário refinar os elementos da arquitetura em elementos de design e também melhorá-lo através de soluções como design patterns.
8. Estrutura o modelo de implementação. Esta tarefa estabelece a estrutura dos elementos de implementação baseados nas responsabilidades designadas para subsistemas de implementação e seu conteúdo.

Os principais artefatos produzidos pelo time de arquitetura (arquiteto de software, analistas de sistemas,  analista de requisitos e projetistas) são:

• Requisitos Suplementares
• Documento de Arquitetura de Software
• Provas de Conceito
• Modelo de Design
• Modelo de Implementação

Um outro aspecto importante no RUP é o momento temporal onde estas tarefas se concentram – até 3/10 do tempo do projeto. Por exemplo, se tivéssemos executando um projeto de 4 meses (18 semanas), teríamos o seguinte padrão:

• Até duas semanas (1/10 do tempo) para identificar os requisitos suplementares.
• Até duas semanas para gerar uma primeira proposta de arquitetura candidata e mais quatro semanas (+ 2/10 do tempo) para refinamentos desta arquitetura.
• Até seis semanas (3/10 do tempo) para a execução de provas de conceito e verificação da viabilidade destas provas de conceito.
• Até seis semanas (3/10 do tempo) para o detalhamento de uma arquitetura com os elementos de desenho instalados e um modelo de implementação definido.

Temporalmente do RUP, portanto, o alvo a ser atingido até o 3/10 do tempo de um projeto  com as tarefas acima é produzir um artefato chave chamado arquitetura executável. Esta arquitetura executável acomoda entre 5 e 20% dos casos de uso de um sistema (que foram implementados em paralelo as atividades acima por um pequeno time de projetistas e desenvolvedores) e cria a fundação para acomodar o restante dos casos de uso. É o fim da fase de elaboração no RUP!

Para mais informações a respeito, coloco abaixo algumas referências interessantes sobre atividades de arquitetura no RUP

• Architectural Manifesto – The Benefits of The Software Architecture
• Developing a J2EE Architecture with Rational Software Architect Using the Rational Unified Process
• Architectural manifesto: Evaluating architectures
• Designing Software Architectures – Parte 1
• Designing Software Architectures – Parte 2
• Designing Software Architectures – Parte 3
• Designing Software Architectures – Parte 4
• Designing Software Architectures – Parte 5
• Planejamento de Iterações no RUP (Descreve o fluxo de arquitetura do RUP e principais artefatos associados).