O Open-UP, que detalhamos em um artigo anterior, é um processo de domínio público e aberto para extensões que mescla a escola de agilidade de métodos ágeis como o XP com o rigor do ataque aos riscos do RUP.

O OpenUP é baseado em quatro princípios básicos:

• Balanço: Balanceamento entre as prioridades conflitantes do projeto (custo, tempo, qualidade, escopo) de forma a maximizar o valor para os clientes.
• Colaboração: Colaboração para alinhar os interesses e fomentar o entendimento comum da missão e prioridades do projeto.
• Foco: Desde o início, foco na arquitetura para mitigar riscos e organizar o desenvolvimento de software.
• Evolução: Evoluir através de feedbacks contínuos dos stakeholders e através da demonstração de valor agregado regularmente.

O gráfico abaixo com a espinha dorsal do Open-UP mostra o rigor do ataque a riscos neste processo ágil.

Perfil de Riscos do OpenUP

Fonte: OpenUP – Licença EPL

A fase de elaboração é normalmente finalizada por volta do 3/10 temporal de um projeto e deve apresentar um perfil de riscos muito baixos para que seja dada como encerrada. Para que os riscos estejam mitigados, é fundamental um foco permanente em atividades arquiteturais.

No OpenUP, diferentemente do RUP, a arquitetura é enfatizada como um produto coletivo e não como um produto do arquiteto. A arquitetura não deve ser arremessada para a equipe pelo arquiteto da torre de marfim. Além disso, a arquitetura é considerada evolutiva, embora ela tenha suas linhas de base salvas dentro do ciclo de vida do projeto (prática da Arquitetura Evolutiva).

O OpenUP produz apenas um único e ligeiro documento para a “disciplina” de arquitetura, chamado de Caderno Arquitetural (Architectural Notebook). Este documento compila as decisões realizadas pelo time, liderado pelo arquiteto de software, e formaliza as decisões técnicas tomadas para facilitar comunicações futuras.

A disciplina arquitetural do OpenUP pode ser observada também na lista de verificação do Caderno Arquitetural, colocada abaixo, e também na lista de atividades que documentamos anteriormente.

Lista de Verificação de Arquitetura do OpenUP

• A arquitetura está totalmente compreensível para todos os envolvidos do projeto?
• Os objetivos da arquitetura, restrições de desenho e implementação e os requisitos foram descritos e endereçados?
• Os mecanismos arquiteturais foram identificados e descritos?
• As partições do sistema foram suficientes definidas?
• Os elementos chave da arquitetura foram definidos adequadamente?
• As interfaces com sistemas externos foram representadas?
• Os pontos de reuso foram identificados?
• A arquitetura foi feita para evoluir?
• A arquitetura conseguirá ser entregue pelo time nas restrições de tempo e custo do projeto?
• O software foi mapeado adequadamente para o hardware?

O OpenUP foi originalmente desenhado para times pequenos (< 10 pessoas), embora acreditemos na sua escala até mesmo para projetos maiores. De toda forma, por ser um processo público, ágil e com forte ênfase em controle de riscos através de atividades arquiteturais, este processo é sem dúvida uma excelente escolha para desenvolvimento de software na realidade brasileira.

Um artigo bem interessante sobre o OpenUP, inspirou o método de trabalho usado para criar o Eclipse, pode ser encontrado na Rational Edge.

Curiosidade do Dia: O criador do OpenUP é o Ricardo Balduíno, um brasileiro que trabalha como Engenheiro de Software Sênior pela IBM Rational.

Diferentemente das outras abordagens ágeis, como o XP, a forte orientação à mitigação de riscos do OpenUP (premissa do UP, claro) enfatiza o trabalho arquitetural no início do ciclo de desenvolvimento. Ao balancear o ataque aos riscos técnicos com as práticas ágeis, o OpenUP adota a Arquitetura Evolucionária (Evolutionary Architecture), uma influência da Arquitetura Ágil (Agile Architecture) de Ambler. A Arquitetura Evolucionária se baseia em: realizar o trabalho arquitetural “just in time”, isto é, na medida que é necessário; documentar principais premissas arquiteturais; implementar e testar capacidades-chave através de protótipos.

As tarefas cujo principalmente responsável é do arquiteto são “Esboçar a Arquitetura” (Outline the Architecture) e “Refinar a Arquitetura” (Refine the Architecture). Basicamente, a tarefa de “Refinar a Arquitetura” complementa com maiores detalhes as informações identificadas em “Esboçar a Arquitetura”.

Relacionamentos do Arquiteto de Software (OpenUP)

Fonte: OpenUP – Licença EPL

Abaixo apresentamos uma correlação entre os passos das tarefas arquiteturais:

Apesar de ser um processo minimalista, as tarefas arquiteturais indicadas pelo OpenUP são suficientes para suprir as necessidades de modelagem da arquitetura de grande parte dos projetos de software. Ambas tarefas fornecem insumos para o preenchimento do “Caderno de Arquitetura” (“Architecture Notebook”, também traduzido por “Descrição Arquitetural” no OpenUP 0.9 em português). O Caderno de Arquitetura, único artefato da disciplina, registra todos os apontamentos relevantes do time de arquitetura. Não é pretensão do OpenUP documentar toda a atividade de arquitetura – para isto, conta com o valor ágil de “Comunicação”.

Para maiores informações aos interessados, seguem referências.

1. As Atividades de Arquitetura do Processo Unificado 
2. OpenUP
3. Agile Manifesto
4. Agile Architecture: Strategies for Scaling Agile Development
5. Architecture Envisioning: An Agile Best Practice
6. Agile Enterprise Architecture
7. Architecture Paradox