RUP - Rational Unified Process

A Rational é bem conhecida pelo seu investimento em orientação em objetos. A empresa foi a criadora da Unified Modeling Language (UML), assim como de várias ferramentas que a suportam, sendo a mais conhecida o Rational Rose. O Rational Unified Process (RUP) é uma metodologia completa criada pela Rational para viabilizar que grandes projetos de software sejam bem sucedidos. O RUP é na verdade um produto composto de material de referência na forma de páginas HTML, descrevendo toda a metodologia.

Princípios Básicos

Um grande problema nos projetos atuais é o grande dinamismo e complexidade dos negócios nos dias de hoje. Cada vez mais os sistemas são complexos e precisam estar prontos em menos tempo. Mais do que isso, as necessidades mudam ao longo do tempo e a especificação de um sistema provavelmente será alterada durante seu desenvolvimento. Além disso, temos tecnologias novas (software e hardware) surgindo a cada dia. Algumas funcionam bem. Outras não. Visando atacar estes problemas, o RUP adota as seguintes premissas básicas:

Uso de iterações para evitar o impacto de mudanças no projeto, Gerenciamento de mudanças e Abordagens dos pontos de maior risco o mais cedo possível.

Estrutura Básica do RUP

Nesta metodologia, o projeto passa por 4 fases básicas. Estas fases são:

• Inception - entendimento da necessidade e visão do projeto,
• Elaboration - especificação e abordagem dos pontos de maior risco,
• Construction - desenvolvimento principal do sistema,
• Transition - ajustes, implantação e transferência de propriedade do sistema

Apesar de parecer um modelo em cascata, na verdade cada fase é composta de uma ou mais iterações, o que se assemelha a um modelo em espiral. Estas iterações são em geral curtas (1-2 semanas) e abordam algumas poucas funções do sistema. Isto reduz o impacto de mudanças, pois quanto menor o tempo, menor a probabilidade de haver uma mudança neste período para as funções em questão.

Além das fases e iterações, existem os workflows. Cada workflow é na verdade uma sequência de tarefas encadeadas e relacionadas a um aspecto importante do projeto, tal como análise do negócio, testes, etc. Os gráficos da figura mostram a ênfase de cada workflow em cada etapa do projeto.

Conteúdo do RUP

que é o RUP afinal? Sabemos neste ponto que é uma metodologia completa e vimos sua estrutura básica. Porém o que ele oferece?

O RUP, além de uma metodologia, é um produto comercializado pela Rational, que é uma grande documentação baseada em hipertexto (HTML). Do conteúdo deste material, destaco os seguintes assuntos:

• Workflows: Cada workflow é descrito em detalhe, apresentando passo a passo as tarefas, subprodutos a serem gerados e papéis de profissionais envolvidos. Cada tarefa, subproduto e papel é descrito em detalhe. Este modelo pode ser seguido à risca ou adaptado conforme sua necessidade específica.
• Tarefas: Cada tarefa é descrita em detalhe, incluindo que papel é responsável por ela, a qual workflow ela pertence e quais são os subprodutos de entrada e saída.
• Modelo de equipe: Os diversos papéis necessários no projeto são descritos em detalhe. Assim como no MSF, cada papel pode ser representado por mais de uma pessoa, ou uma pessoa pode ter mais de um papel, dependendo da carga de trabalho necessário. Porém o RUP aborda os papéis em um maior nível de detalhe. Ao todo são mais de 30. Exemplos de papéis são: analista de sistemas, analista de negócio, etc.
• Modelos de documentos: O RUP apresenta modelos e exemplos para os diversos documentos (artifacts) gerados ao longo do projeto. Estes documentos são descritos em detalhe, assim como as tarefas que os geram e as que os utilizam. Para os usuários das ferramentas Rational, existe um recurso adicional e-coach, que orienta o usuário a usar ferramentas como o Requisite Pro passo a passo. Os documentos são totalmente compatíveis com a UML, o que reforça a questão de padronização.

Como Adotar

Com base nestes recursos a adoção do RUP pode ser feita de mais de uma maneira. Um extremo seria usar o RUP à risca, ou seja, aplicar todos os métodos e processos exatamente como são propostos. A vantagem desta abordagem é que nada deve ser alterado, pois o RUP é bem completo e detalhado. Porém existe um preço a ser pago, pois o RUP na íntegra é complexo. Esta abordagem implicaria em treinamentos, projetos piloto, etc. Propostas de projetos de adoção do RUP são descritos no próprio produto.

O extremo oposto seria adotar outro modelo de processo mais simples ou conhecido (o atual, se existir) e utilizar o material do RUP como fonte de referência complementar para assuntos não abordados em outro modelo como, por exemplo, os modelos de documentos.

A primeira abordagem é interessante para empresas que precisam de uma grande formalização do processo de desenvolvimento de software e cujo método atual seja totalmente inadequado ou inexistente. A segunda abordagem seria interessante para quem já tem alguma metodologia que considera adequada, mas que tem deficiência em alguma área como, por exemplo, suporte a UML. Soluções intermediárias também são possíveis.