Este artigo, visa apresentar uma metodologia que está em propagação no exterior, porém ainda é pouco conhecida no Brasil. Metodologia que provê qualidade de software, aumento de produtividade, melhorias em sua manutenção e que controla todas as fases de desenvolvimento do software.


O Rational Unified Process® (processo RUP®) é um processo de engenharia de software criado pela Rational Software Corporation, adquirida pela IBM a partir de 2003, ganhando um novo nome IRUP (IBM Rational Unified Process).  Ele oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento. 

Sua meta
Sua meta é garantir a produção de software de alta qualidade de forma que atenda às necessidades dos usuários dentro de um cronograma e de um orçamento previsível. Através de ferramentas para as necessidades específicas do projeto, ferramentas para desenvolvimento de conhecimento interno em componentes de processo, ferramentas de implementação eficientes e personalizáveis baseadas na web e comunidade online para troca de melhores práticas entre usuários e lideres do mercado.
O RUP usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos em ação. O RUP é amplamente customizável, visto que todo seu produto é modelar e automatizado, sendo possível em seu desenvolvimento, selecionar e implementar apenas os componentes de processo necessários para cada estágio do projeto. Assim  podendo ser utilizado tanto para grandes projetos, como adaptado para projetos de média ou baixa escala.

O RUP está fundamentado em três princípios básicos: orientação a casos de uso, arquiteturae iteração. Ele é dito dirigido a casos de uso, pois são os casos de uso que orientam todo oprocesso de desenvolvimento. Com base no modelo de casos de uso, são criados uma série de modelos de análise, projeto e implementação, que realizam estes casos de uso. É centrado em arquitetura, pois defende a definição de um esqueleto para a aplicação (a arquitetura), a ganhar corpo gradualmente ao longo do desenvolvimento.. Esses três conceitos são igualmente importantes. A arquitetura provê a estrutura para guiar o desenvolvimento do sistema em iterações, enquanto os casos de uso definem as metas e conduzem o trabalho de cada iteração. e em basicamente quatro fases(Iniciação, Elaboração, Construção, Transição)  onde são tratadas questões sobre planejamento, levantamento de requisitos, análise, implementação, teste e implantação do software. E também através de 6 disciplinas básicas(Modelagem de negócio, Requisitos, Análise e Design, Implementação, Teste, Implantação).
Cada fase do desenvolvimento de software tem um papel fundamental para que o objetivo seja cumprido, distribuídos entre vários profissionais como o Analista de sistema, Projetista, Projetista de testes, entre outros.

Diagrama do RUP.



Fases

Fase de Concepção / Iniciação: Nesta fase do RUP são abrangidas as tarefas de comunicação com o cliente e planejamento. É feito um plano de projeto avaliando os possíveis riscos, assim como suas origens e provisões, as estimativas de custo e prazos, estabelecendo as prioridades, levantamento dos requisitos do sistema e preliminarmente analisá-lo. Assim, haverá uma anuência das partes interessadas na definição do escopo do projeto, onde são examinados os objetivos para se decidir sobre a continuidade do desenvolvimento.

Fase de Elaboração: Nesta fase é criada a baseline da arquitetura do sistema, abrangendo a modelagem do modelo genérico do processo. O objetivo desta fase é analisar de forma mais detalhada a análise do domínio do problema, revisando os riscos que o projeto pode sofrer e a arquitetura do projeto começa a ter sua forma básica. Indagações como "O plano do projeto é confiável?", "Os custos são admissíveis?" deverão ser esclarecidas nesta fase, onde a estabilidade da arquitetura do projeto devera ser desenvolvida e avaliada através de um ou mais protótipos de arquitetura

Fase de Construção: É a fase da conclusão do desenvolvimento, ou aquisição dos componentes de Software com base na arquitetura baseline elaborada na fase anterior. O principal objetivo desta fase é a construção do sistema de software, com foco no desenvolvimento e gerenciamento de componentes e outros recursos do sistema e no controle de operações, afim de otimizar os lucros, programação e a qualidade . É na fase de Construção que a maior parte de codificação ocorre.

Fase de Transição: É a fase com objetivo de entrega do software ao usuário final e a fase de testes e correções com base nos feedbacks do usuario. O objetivo desta fase é disponibilizar o sistema, tornando-o disponível e compreendido pelo usuário final através de atividades que incluem o treinamento dos usuários finais, testes da versão beta do sistema, visando garantir que o software possua o nível adequado e aceitável de qualidade.

Disciplinas

Uma disciplina é um conjunto de atividades relacionadas a uma área de interesse importante em todo o projeto. O principal objetivo do agrupamento de atividades em disciplinas é ajudar a compreender o projeto a partir de uma perspectiva em cascata  tradicional . Por exemplo, geralmente é mais comum executar determinadas atividades de requisitos em coordenação direta com as atividades de análise e de design. A separação dessas atividades em disciplinas distintas facilita a compreensão, mas dificulta a programação.

Modelagem de Negócios: Definimos a arquitetura de negócios como um conjunto organizado de elementos com relacionamentos transparentes uns com os outros que, juntos, formam um todo definido pela correspondente funcionalidade. Os elementos representam a estrutura organizacional e comportamental de um sistema e mostra abstrações dos principais processos e estruturas do negócio. Nesta fase é criado o Organograma da organização  dos processos, a elaboração da visão estrutural da organização, da cultura da mesma, assim como o desenvolvimento das habilidades da equipe e na definição dos mecanismos e padrões e a serem aplicados.

Requisitos: Explica como levantar pedidos das partes interessadas ("stakeholders") e transformá-los em um conjunto de requisitos que os produtos funcionam no âmbito do sistema a ser construído e fornecem requisitos detalhados para o que deve fazer o sistema
Análise e Design: Mostra como o sistema vai ser realizado, de forma que o mesmo execute as tarefas e funções especificadas nas descrições dos casos de uso criado, e que cumpra todas as necessidades preestabelecidas, e estável quando ocorrem mudanças dos requisitos funcionais

Implementação: Define a organização do código , em termos de subsistemas de implementação organizadas em camadas, implementa classes e objetos em termos de componentes e realiza testes nos componentes desenvolvidos como unidade, alem de integrar os resultados produzidos em sistemas executáveis.

Teste: Verifica a interação entre objetos, a integridade adequada de todos os componentes do software e se todos os requisitos foram implementados.Também identifica e garante que os defeitos sejam corrigidos antes da implantação do software, re-análisados e encerrados. O Rational Unified Process propõe uma abordagem iterativa, o que significa que deve-se testar todo o projeto. Isto permite encontrar defeitos tão cedo quanto possível, o que reduz radicalmente o custo de reparar o defeito. Os testes são realizados ao longo de quatro dimensões da qualidade:confiabilidade, funcionalidade, desempenho da aplicação, e o desempenho do sistema

Implantação: Sistemas são realizados através da aplicação de componentes. O processo descreve como a reutilização de componentes existentes ou implementar novos componentes com responsabilidades bem definidas, tornando o sistema mais fácil de manter e aumentar as possibilidades de re-utilização.