OpenUP – Agilidade, Controle de Riscos e Disciplina Arquitetural

Métodos ágeis são, sem dúvida, excelentes paradigmas para o desenvolvimento de software. Eles possuem excelentes premissas tais como: foco na comunicação, geração de valor para os clientes e desenho orientado à mudanças; entre outros. Por outro lado, métodos mais robustos como o RUP trazem uma forte orientação por riscos através da decomposição do processo em fases temporais, onde os requisitos mais prioritários e complexos são identificados, detalhados e implementados nas fases iniciais (concepção e elaboração).

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.