Nem modelos, nem requisitos. A primeira atividade de um arquiteto é alinhar as expectativas com todos os envolvidos de um projeto, i.e., definir a Visão Arquitetural.

Visão Arquitetural – As Expectativas do Trabalho de Arquitetura em Um Projeto

Visão Arquitetural

A visão arquitetural promove alinhamento. Ela define o norte, o alvo, o objetivo primário para todas as atividades de arquitetura e calibra as expectativas com todos os envolvidos do projeto tais como clientes, patrocinadores, diretores, gerentes e time técnico do projeto.

A visão implementa um dos sete hábitos de uma arquiteto e de equipe altamente eficaz que é: “Comece com um Objetivo em Mente”,  do guru Stephen Covey.  Um excelente exemplo para tornar este conceito concreto é imaginar a visão de Steve Jobs na concepção do iPhone, cuja visão é “trazer para os seus usuários uma experiência única em termos de usabilidade, interatividade  e convergência de mídias em um telefone celular”.

iPhone

Um outro exemplo, em um contexto da criação de um portal para uma instituição bancária, é trazer segurança real para os seus usuários em suas transações financeiras realizadas de suas casas.

Considere estes dois exemplos. Suas  visões são o norte para os seus arquitetos. Elas definem a priorização de suas atividades na dúvida entre dois mecanismos ou escolhas dentro de um projeto. No primeiro exemplo, a usabilidade, acessibilidade e aspectos de interatividade norteiam as escolhas primárias dos mecanismos e decisões táticas para o time de arquitetura. No segundo exemplo, aspectos de confidencialidade, integridade, autenticação, autorização, não-repúdio terão importância primária nas decisões, prioridades e atividades de um time de arquitetura.

A visão precede os requisitos, embora os requisitos possam ajudar a expressar parte da visão. A visão pode ser escrita em texto livre ou em algum formato estruturado.  Em termos simples, uma boa forma de coletar a visão junto aos usuários chave é através de três perguntas que modelem o estado desejado (processo de imaginação) para cada usuário chave.

• O que conseguimos com o produto, agora que a arquitetura está implementada?
• Como sabemos que atingimos o objetivo do produto?
• Como você se sente, agora que o objetivo do produto foi alcançado?

A visão, portanto, é o compromisso do valor esperado pelos usuários e estabelece o princípio das ações do arquiteto e do time de arquitetura.

Vários arquitetos experientes enfatizam o conceito da visão arquitetural. Destacamos abaixo duas referências para os interessados em como criar uma visão arquitetural em projetos:

1. Criação da Visão Arquitetural – Dana Bredemeyer (Apresenta um processo de entrevistas com usuários para definir a visão de arquitetura).
2. A Visão dos Objetivos do Cliente – Gerrit Muller (Apresenta um processo de identificação de “Condutores Chave” – Key Drivers, que expressa a visão a ser alcançada com uma arquitetura de software).

Pensamento do Dia:  “Meça duas vezes. Corte uma vez”, Regra do Carpinteiro.

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