As práticas do AUP se baseiam em técnicas ágeis como, como exemplo, Test Driven Development (TDD), Agile Model Driven Development (AMDD), Agile Change Management, Database Refactoring e Agile Architecture. Além disso, a filosofia do AUP parte dos seguintes princípios:

1. A equipe sabe o que está fazendo.
2. Simplicidade.
3. Agilidade.
4. Foco em atividades de alto valor.
5. O processo será personalizável conforme as necessidades de quem o usa.

O AUP concentra as atividades de análise, desenho e requisitos em uma única disciplina conhecida por Modelagem. Exatamente por interessar ao tema de Arquitetura de Software, nos concentraremos nessa disciplina. Afinal, como o AUP orienta o trabalho de arquitetura?

Arquitetura Ágil é o conceito que permeia o trabalho arquitetural. Para Ambler, a arquitetura é um dos fatores que, assim como no EUP, permitem escalar o desenvolvimento de software sem perder o caráter ágil. De uma forma geral, a proposta da Arquitetura Ágil, assim como várias outras práticas propostas por Ambler, é dirigida pelo conceito de bom o suficiente (nossa tradução contextualizada para Just Barely Good Enough ou JBGE). Nenhum excesso é cometido e procura-se sempre obter a melhor relação valor/tempo. Não significa que os modelos devam ser ruins ou o trabalho negligenciado – apenas destaca-se que uma atividade não precisa ser executada até a perfeição do produto e, sim, apenas o suficiente para a otimização do esforço.

Da mesma forma que o RUP e o EUP, o AUP propõe a evolução da arquitetura ao longo de duas fases. Na Iniciação, obtém-se uma arquitetura de alto nível, levando em consideração os requisitos técnicos. O objetivo é identificar uma estratégia arquitetural viável capaz de oferecer insumos ao planejamento do projeto e ao cálculo de esforços (lembre-se, o UP é dirigido pela arquitetura). Nesse momento, o diagrama recomendado mais importante é o esboço do modelo de implantação.

Já na Elaboração, o objetivo é refinar a arquitetura até atingir sua estabilidade. A modelagem da arquitetura é dirigida aos maiores riscos técnicos identificados. Tipicamente, protótipos são construídos para provar alguns aspectos da arquitetura. O principal objetivo dessa fase é a arquitetura estável, comprovada através da implementação dos requisitos estruturalmente críticos.

Historicamente, o AUP foi derivado da compreensão e refinamento dos princípios e valores expostos no livro Modelagem Ágil (Agile Modeling), quando Scott Ambler demonstra a possível aplicação da Modelagem Ágil através do RUP. O AUP, influenciado por métodos populares como o XP, RUP e EUP, foi um dos primeiros processos a tentar convergir conceitos do UP e técnicas ágeis Por sua vez, o AUP influenciou fortemente outros processos mais recentes como o notável OpenUP.

Para mais informações:

• The Agile Unified Process (AUP)
• Agile Architecture: Strategies for Scaling Agile Development
• Agile Modeling and the Rational Unified Process (RUP)
• The Enterprise Architecture Discipline: Scaling Agile Software Development
• Making RUP Agile, por Michael Hirsch 
• Modelagem Ágil (Agil Modeling), de Scott Ambler 

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

De fato, muitos sistemas funcionam bem e tiveram boas arquiteturas desenhadas sem ajuda do QAW. Isso, muitas vezes, é proporcionado pela experiência de arquitetos e analistas (um tanto acostumados em tentar adivinhar as necessidades do usuário) que identificam os requisitos de qualidade artesanalmente ou com base em experiências místicas. Entretanto, sistemas muito complexos necessitam de maior precisão na obtenção de tais atributos de qualidade. O QAW pode facilitar a vida até mesmo de arquitetos experientes. 

Além de endereçar uma precisão do requisitos, o QAW também facilita sua priorização. Muitos requisitos de qualidade conflitam entre si e tentam se equilibrar como que numa complexa balança. Por exemplo: confiabilidade pode implicar em menor performance; segurança pode afetar a usabilidade; etc.

A idéia é envolver os stakeholders em um evento de um dia objetivando identificar um conjunto de cenários com os atributos de qualidade categorizados, priorizados e refinados. Recomenda-se um número entre 5 e 30 stakeholders para contribuir na oficina de requisitos de qualidade e as discussões devem ser limitadas a um dia.

O QAW envolve os seguintes passos:

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 capturam 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, fundindo cenários parecidos. 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 mais prioritários, garantindo que cada cenário prioritário seja descrito, entre outras coisas, pelos seis elementos (vide figura) e apresente atributos de qualidade associados a ele.

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

Os resultado de uma sessão de QAW incluem:

• lista de diretrizes arquiteturais;
• cenários “crus”
• lista priorizada de cenários
• cenários mais importantes refinados

Com requisitos de qualidade mais refinados e devidamente balanceados por vários stakeholder, a equipe de arquitetura terá como insumo uma fonte extremamente valiosa. Em seu próximo projeto de software, sugiro que avalie a possibilidade de usar o QAW. Possivelmente, os riscos envolvidos serão bem menores.

Mais informações: Relatório Técnico sobre o QAW, 3a Edição