2. Conceitos Básicos do Open UP

O desenvolvimento de software utilizando a Open UP tem uma definição de processo muito semelhante à definição para o Processo Unificado. A máxima "Quem fará o quê, quando e de que forma" também é válida para a metodologia Open UP. No caso, Quem é definido pelos Papéis; O Quê é definido pelos Produtos de Trabalho; Quando é definido pelos Processos e De Que Forma é definido pelas Tarefas. A Open UP acrescenta também a possibilidade da customização dos elementos definidos anteriormente para atender uma determinada demanda de produção.

Podemos definir os elementos acima espeficicados como:

Produtos de Trabalho
São os diversos resultados produzidos durante o processo de desenvolvimento. Os Produtos de Trabalho podem ser classificados como: Artefatos, se os mesmos são concretos; Resultados, se eles não são concretos e "Releases" se eles são pacotes de artefatos para entrega. São eles:

  1. Visão (Requisitos)
  2. Modelo de Caso de Uso (Requisitos)
  3. Requisitos Suplementares (Requisitos)
  4. Arquitetura (Arquitetura)
  5. Implementação (Implementação)
  6. Executável (Requisitos)
  7. Planos de Teste (Requisitos)
  8. Caso de Teste (Teste)
  9. Script de Teste (Teste)
  10. Histórico de Teste (Teste)
  11. Lista de Risco (Gerência de Projeto)
  12. Plano de Projeto (Gerência de Projeto)
  13. Plano de Iteração (Gerência de Projeto)

Tarefas
São as atividades desempenhadas para gerar os Produtos de Trabalho. Em geral, as Tarefas são definidas como séries de passos que envolvem a criação ou atualização de um Produto de Trabalho. As tarefas do Open UP são:
  1. Definir Visão do Problema (Requisitos)
  2. Especificar Requisitos Funcionais (Requisitos)
  3. Definir e Refinar o Modelo de Caso de Uso (Requisitos)
  4. Especificar Requisitos Não Funcionais (Requisitos)
  5. Especificar e Refinar a Arquitetura (Arquitetura)
  6. Projetar Aplicação (Desenvolvimento)
  7. Gerar Planos de Teste (Desenvolvimento)
  8. Implementar Aplicação (Desenvolvimento)
  9. Executar Testes (Desenvolvimento)
  10. Integrar e Criar Executável (Desenvolvimento)
  11. Criar Casos de Teste (Teste)
  12. Implementar Testes (Teste)
  13. Executar Testes (Teste)
  14. Planejar Projeto (Gerência de Projeto)
  15. Planejar Iteração (Gerência de Projeto)
  16. Avaliar Iteração (Gerência de Projeto)
  17. Solicitar Mudanças (Gerência de Projeto)

Papel 
Define quem serão os elementos que irão desempenhar as tarefas que darão origem aos Produtos de Trabalho. Os papéis assumidos no desenvolvimento utilizando a Open UP são:
  1. Analistas
  2. Arquitetos
  3. Desenvolvedores
  4. Gerente de Projeto
  5. Stakeholders (qualquer envolvido no processo de desenvolvimento da solução proposta)
  6. Testadores

Processo
Define uma sequência de Tarefas que são desempenhadas por papéis, gerando produtos de trabalho, visando atingir um determinado objetivo. Tarefas e/ou Produtos de Trabalho podem ser agrupados em atividades de mais alto nível chamadas de Divisões de Trabalho.


Podemos ainda utilizar Workflows (Diagramas de Atividades) para especificar de forma clara a sequência das ações e artefatos gerados.

Minimalista, Completa e Customizável

Algumas das grandes vantagens da Open UP enquanto metodologia ágil são seu caráter minimalista, sua completude enquanto processo de desenvolvimento de software e sua capacidade de customização de forma prática e simples. A Open UP apresenta um conjunto mínimo de Processos (veja a definição acima) necessários para equipes de desenvolvimento de pequeno porte (de 5 a 20 pessoas). A possibilidade de customização permite adaptá-la às mais diversas necessidades e especificidades das equipes de desenvolvimento.

Uma boa forma para compreender a Open UP é visualizá-la como uma metodologia direcionada às equipes que em geral possuem os seguintes objetivos:
  • Aplicação apenas de Processos que agregam valor;
  • Aplicação otimizada e produtiva de Produtos de Trabalho;
  • Uso de Processos que possam ser adaptados e extendidos conforme o surgimento de necessidades adicionais durante o Ciclo de Vida de Projeto.
Almejando a capacidade de aplicação ao maior número de projetos possíveis, bem como, à maior gama de equipes possíveis, independentemente de suas culturas de trabalho, a equipe Eclipse projetou a Open UP buscando atingir às seguintes características [Balduino2007]:

  • Metodologia Minimalista: os Processos são estruturados de forma a oferecer apenas seus elementos mais necessários. É importante lembrar que os elementos que compõem um Processo são: Papéis, Tarefas e Produtos de Trabalho.
  • Metodologia Completa: O Open UP pode ser considerada como completa por oferecer todos os recursos necessários para um Processo de Software. É importante destacar a diferença entre Processos e Processo de Software para esse texto. Processos, como definido pelo Open UP, é uma sequência de Tarefas pré definida e Processo de Software, segundo [Pressman2001] pode ser definido como um paradigma de desenvolvimento de software (linear, iterativo, RAD, espiral, etc.).
  • Metodologia Customizável: O termo originalmente empregado em inglês para esta característica é "Extensible" (extendível). Porém, acredito que o termo Customizável se aplica melhor como característica do Open UP, considerando que a mesma pode ser adaptada de acordo com as reais necessidades da equipe e/ou, com as características inerentes de cada projeto.

A Open UP pode ser considerada como uma metodologia ágil e que promove algumas das melhores práticas do desenvolvimento de software universal, como por exemplo:
  • Desenvolvimento Iterativo
  • Desenvolvimento Colaborativo
  • Integração contínua de executáveis
  • Fácil adaptação às mudanças
  • Desenvolvimento dirigido a testes
entre outras.

A intenção do Open UP é prover o conjunto de Produtos de Trabalho necessário para capturar e comunicar decisões. O Processo em si não é regido pelo ato de criação de Produtos de Trabalho em si, mas pelos atos que possibilitam o desenvolvimento de software seguindo as práticas acima citadas. Por exemplo, o ato de planejar uma iteração está focado em promover a colaboração entre os membros da equipe de desenvolvimento e não na criação de regras rígidas de ação, uma liturgia por assim dizer.

As Tarefas devem ser claramente focadas em resultados. As instruções de uma Tarefa devem ser claras, objetivas e sucintas. Textos breves e objetivos devem guiar os membros das equipes de desenvolvimentos no desempenho de seus Papéis durante a execução das Tarefas. Os passos de uma Tarefa devem ser breves e descrever os objetivos que deverão ser atigidos naquele momento e, se possível, como fazê-los.

o Open UP é considerada uma metodologia completa de desenvolvimento por abordar as principais fases do ciclo de vida tradicional de desenvolvimento de software: Requisitos, Arquitetura (Análise e Design), Implementação, Teste e Gerência de Projetos. É importante frisar que estas fases foram escolhidas por que estão focadas nos papéis específicos da equipe de desenvolvimento, e não nas fases que focam os papéis ditos organizacionais, como Análise de Negócios, Configuração de Ambientes, Gerência de Configuração e Mudança e Implantação.

Isso porém não impede que uma empresa possua pessoas dedicadas a atuar nessas fases. Indica apenas que o Open UP não se preocupa com elas.

O Open UP é considerada customizável por permitir que novas elementos de Processo sejam criados ou que elementos atuais sejam retirados, além é claro, de permitir criação e exclusão dos próprios Processos. Mais uma vez, por elementos de Processos podemos entender como Papéis, Produtos de Trabalho e Tarefas.

Referências




[OpenUP2010] Open UP; Version 1.0.5.4(c) Copyright Eclipse contributors and others 2004, 2009; www.eclipse.org/epf; Acessado em 09 de abril de 2010.

[Pressman2001] Pressman, Roger S.; Software Engineering: A Practitioner's Approach; Fifth Edition; 2001; McGraw Hill; New York.

[Balduino2007] Balduino, Ricardo; Introduction to Open UP (Open Unified Process); White Paper; 2007; http://www.eclipse.org/epf/general/OpenUP.pdf ; Acessado em 09 de abril de 2010.