RATIONAL UNIFIED PROCESS RUP Criado na década de 90 (a partir do Objectory [ver Jacobson, 1990] e utilizando os conceitos do Modelo em Espiral [ver Boehm, 1988]) como alternativa para resolução dos problemas encontrados no então atual modelo de desenvolvimento de software (o modelo cascata ), o Rational Unified Process (RUP) é um produto/processo iterativo, incremental e customizável de Engenharia de Software que foi inicialmente desenvolvido e comercializado pela Rational, e desde 2003 pertencente à IBM. Processo por definição e produto pela maneira como é comercializado (passível de suporte, atualizações, etc.), o RUP prove de uma maneira disciplinada, a atribuição de tarefas e responsabilidades dentro de um time de desenvolvimento. Seu maior objetivo é garantir a produção de softwares de alta qualidade e que satisfaçam as expectativas e necessidades dos usuários finais dentro de um prazo e orçamento aceitáveis por parte dos patrocinadores. 1 (figura 01 A arquitetura do RUP) A arquitetura básica do RUP se divide em duas dimensões (figura 01): Horizontal: Representam o tempo de vida de um projeto, os aspectos do ciclo de vida do processo de engenharia de um sistema, de acordo com o decorrer do projeto. Essa dimensão demonstra o aspecto dinâmico do processo, suas fases, iterações e milestones; Vertical: Representam os grupos de atividades lógicas que são realizadas durante o decorrer do tempo. Essa dimensão demonstra o aspecto estático do processo, que será composto por disciplinas, atividades, fluxos, artefatos e papéis. O RUP incorpora as melhores práticas de desenvolvimento de software (http://spmn.com) de acordo com as causas de sucesso apontadas pela indústria de software:
1) Desenvolvimento iterativo; 2) Gerenciamento de requisitos; 3) Arquitetura baseada em componentes; 4) Modelo visual de software; 5) Verificação contínua da qualidade de software; 6) Controle de mudança de software; DESENVOLVIMENTO ITERATIVO E INCREMENTAL O RUP trata o desenvolvimento de software de uma maneira iterativa e incremental, ou seja, substitui o modelo clássico de desenvolvimento em cascata (Waterfall) para uma abordagem um pouco mais dinâmica, dividida em iterações, onde, dentro de cada iteração, teremos a execução de cada uma de suas Disciplinas (figura 02), em proporção de acordo com a Fase do projeto: ARQUITETURA E CASOS DE USO 2 (figura 02 Waterfall X RUP) Em sua essência, dizemos que o RUP é centrado na arquitetura e dirigido por casos de uso. Isso significa que, para o RUP, os aspectos mais importantes do desenvolvimento de softwares (ou seja, os aspectos relacionados aos maiores riscos de um projeto de desenvolvimento) estão intimamente ligados à arquitetura, visto que ele mesmo define arquitetura como tudo o que sobra quando você não pode mais tirar nada mais do sistema, mas ainda continua entendendo-o e explicando como ele funciona. Sendo assim, devemos então tratar como centro (core) do nosso desenvolvimento, nossos requisitos arquiteturais do projeto. Além disso, quando dizemos que o RUP é dirigido por casos de uso, mostramos que para solucionarmos um problema (o grande e único motivo para a criação de um sistema), devemos primeiro entender da melhor forma possível esse problema, dividi-lo e organizá-lo de uma maneira que todos os envolvidos no projeto de construção desse sistema (todos os
stakeholders) possam compreender a situação. Para realizar essas atividades, o RUP encontra na UML a solução: Use Cases e seus atores. FASES Como dito anteriormente, o RUP é dividido em fases. Cada uma de suas quatro fases compreende um momento distinto dentro do ciclo de vida de um projeto de engenharia de software e, portanto, dão maior ou menor foco em algumas disciplinas, de acordo com a necessidade do projeto no decorrer de sua execução. São elas: Início (Inception): Deve-se aqui conseguir dos stakeholders do projeto um consenso relacionado aos objetivos do ciclo de vida do projeto. Essa fase é focada em endereçar riscos de requisitos e negócio antes de continuar com o projeto. Primariamente, para projetos de novos sistemas, essa fase certamente será mais demorada, porém, para projetos relacionados a sistemas já existentes, a fase de início é mais breve, porém continuará com foco em garantir que o projeto é possível e viável. Os objetivos primários da fase de início incluem: Estabelecer a visão do projeto: escopo, limites, condições, critérios de aceitação, etc.; Elencar os casos de uso críticos do sistema e conhecer os principais cenários das funcionalidades core do sistema; Exibir e demonstrar ao menos uma arquitetura candidata para atender a esses casos de uso críticos; Estimar o custo e prazo total do projeto como um todo e estimar de maneira detalhada a fase seguinte (Elaboração); Estimar os potenciais riscos do projeto; Preparar o ambiente de suporte para o projeto; As disciplinas mais aplicadas nessa fase são: Modelagem de Negócio, Requisitos, Gerenciamento de Projeto e Ambiente. Elaboração (Elaboration): Aqui se fecha a baseline da arquitetura do sistema, estabelecendo uma base sólida para o design e implementação do sistema. A arquitetura deverá considerar os requisitos mais significantes (aqueles que impactam muito a arquitetura do sistema) e uma avaliação de riscos. Essa arquitetura deverá ser avaliada através de um ou mais protótipos arquiteturais. Objetivos primários da fase de elaboração incluem: Garantir que a arquitetura, seus requisitos e planejamento do projeto estão estáveis o suficiente para que seja possível prever custo e prazo da completude do desenvolvimento; Endereçar todos os riscos arquiteturais significantes do projeto; Estabelecer a baseline arquitetural do projeto; 3
Demonstrar que a arquitetura selecionada suportará os requisitos do sistema através de custo e prazo razoáveis; Estabelecer o ambiente de suporte para o projeto; As disciplinas mais aplicadas nessa fase são: Requisitos (já em declínio), Análise e Design, Implementação, Testes, Gerenciamento de Projeto e Ambiente. Construção (Construction): Na fase de construção, fecham-se os requisitos restantes e se completa o desenvolvimento do sistema, baseado na arquitetura definida. A ênfase aqui é passarmos do desenvolvimento de propriedade intelectual criado nas fases anteriores para o desenvolvimento de um produto passível de entrega. Objetivos primários da fase de construção incluem: Minimizar custos de desenvolvimento, evitando retrabalho desnecessário; Alcançar uma qualidade adequada para o produto; Criar-se versões utilizáveis do sistema; Completar a Análise e Design e os testes da aplicação; Desenvolver um produto completo de maneira incremental e iterativa; Decidir se o sistema e os usuários estão prontos para o Deploy; Alcançar certo nível de paralelismo nos trabalhos dos times de desenvolvimento; As disciplinas mais aplicadas nessa fase são: Análise e Design (já em declínio), Implementação, Testes, Deployment, Gerenciamento de Configuração e Mudança, Gerenciamento de Projeto e Ambiente. Transição (Transition): O foco da fase de transição é garantir que o produto desenvolvido esteja disponível para seus usuários finais. Essa fase pode estar dividida em várias iterações e inclui testar o produto na preparação para seu lançamento, pequenos ajustes de mercado baseados no feedback de usuários, etc. Ao final da fase de transição, os objetivos do ciclo de vida do projeto deverão ter sido alcançados e o projeto está prestes a ser finalizado. Objetivos primários da fase de transição incluem: Teste beta para validar o novo sistema de acordo com as expectativas dos usuários; Operação paralela com os sistemas legados que serão substituídos; Conversão de base de dados; Treinamento de usuários; Roll-out para forças de mercado, distribuição e vendas; Empacotamento e Deploy do sistema; Validação da baseline de Deploy em relação à visão completa do projeto e seus critérios de aceitação do produto; Alcançar o auto-suporte dos usuários; 4
Conseguir a validação final do usuário em relação ao produto; As disciplinas mais aplicadas nessa fase são: Deployment, Gerenciamento de Configuração e Mudança e Gerenciamento de Projeto e Ambiente. DISCIPLINAS Durante cada fase do RUP, faz-se uso de suas nove disciplinas. Cada uma dessas disciplinas possui atividades que serão executadas por um papel distinto no processo e poderão ou não gerar artefatos. Seus focos e objetivos podem ser resumidos em: Modelagem de Negócio (Business Modeling): Garantir que os objetivos e expectativas de todos os stakeholders do projeto estejam alinhados com os objetivos da organização derivar desses objetivos, os requisitos de sistema que deverão ser atendidos para solucionar problemas e/ou necessidades; Requisitos (Requirements): Definir os limites do sistema e, de acordo com os requisitos desse novo sistema, criar os casos de uso que serão a base sólida para se estimar os custos e esforços de desenvolvimento desse sistema. Aqui, todos os stakeholders do projeto devem compreender e aceitar tudo que o sistema deverá fazer; Análise e Design (Analysis & Design): Transformar os requisitos em desenhos do sistema que será construído. Devem-se produzir as especificações técnicas que deverão ser seguidas na implementação de cada caso de uso do sistema; Implementação (Implementation): Transformar os modelos lógicos e físicos criados na Análise e Design em código-fonte utilizável e testar unitariamente o código produzido; Testes (Test): Encontrar, documentar e endereçar os defeitos encontrados na qualidade do software produzido. Esses defeitos surgem da comparação entre o que foi produzido com o que foi exposto nos requisitos e modelos lógicos e físicos do produto; Deployment (Deployment): Garantir que o software produzido fique disponível para seus usuários finais; Gerenciamento de Configuração e Mudança (Configuration & Change Management): Controlar as mudanças e manter a integridade de cada um dos artefatos produzidos no projeto. Cada um desses artefatos (ou itens de configuração) deve ser identificado, auditado e possuir níveis de configuração e manutenção definidos; Gerenciamento de Projeto (Project Management): Balancear objetivos que competem entre si, gerenciar riscos, monitorar o projeto e tratar regras que garantirão a entrega de um produto que irá atender às expectativas de Clientes (os patrocinadores do projeto) e usuários finais; 5
Ambiente (Environment): Configurar o ambiente para que o processo e suas atividades possam ser executados. Devem-se prover aqui os processos e ferramentas necessárias para que todas as atividades do projeto possam ser devidamente executadas por cada papel. RUP HOJE - CONCLUSÃO Em uma era onde metodologias Agile estão emergindo como respostas para problemas persistentes na produção de softwares de qualidade, falar em RUP pode parecer, em uma rápida e errônea análise, um passo para trás. Porém, se entendermos os conceitos por trás de cada modelo, processo ou framework, passamos a compreender que nenhum desses arcabouços deve prometer (e sequer faz essa promessa) a resolução de todos os problemas encontrados no dia-a-dia da Tecnologia de Informação. O desenvolvimento iterativo e incremental apareceu no mercado na década de 90 e, infelizmente, vem sendo muito mal utilizado, principalmente quando analisamos empresas que dizem utilizar o RUP, por exemplo. Vale ressaltar que os conceitos básicos desse processo/produto são: Iteratividade, Desenvolvimento Incremental e Customização. Por ser um produto que traz uma série de modelos de artefatos (templates e guidelines) e uma quase infinidade de fluxos, atividades, etc., usuários do RUP geralmente esquecem o conceito Customização do tripé citado acima e passam a acreditar que, para se ter bons resultados com o processo, é necessária a adoção de todo o pacote. Bem, se pensarmos assim, e cotarmos a terceira perna dessa mesa, a mesa certamente irá cair ao primeiro sinal de movimento rumo a um projeto. Além disso, o conceito de iterações, muito pregado também por frameworks como o SCRUM, por exemplo, nem sempre são levados a sério quando tratamos da implantação do RUP, muitas vezes, talvez, por essa informação vital ser ofuscada por tantas outras que o processo traz, diferente do framework SCRUM, onde as Sprints ficam sempre muito claras em todas as palestras, workshops, etc. Sendo assim, ficamos então com uma ferramenta poderosa que, não permanecerá em seu único pé restante (Desenvolvimento Incremental) por mais de 5 minutos, ou, se preferimos exemplificar, durante uma simples reunião com nosso grupo de processos. O RUP é um processo fabuloso e que, certamente traz ótimos resultados e controle sobre as atividades de produção de um software com qualidade, desde que seja bem implementado e, como qualquer outra ferramenta, seja devidamente entendida e que dela se utilize apenas o que é útil para um determinado cenário. A aplicação do RUP em parceria com metodologias ágeis, processos em cascatas e em ambientes com muita documentação ou pouca (ou quase nenhuma!) é possível e todos 6
ficariam gratamente surpresos ao constatar resultados provenientes de projetos de processos como esses. Ainda vale a máxima que devemos sempre utilizar quando tratamos de processo: Um bom processo é um processo que atende às nossas necessidades. E, sendo assim, o RUP obviamente traz grandes ferramentas e conceitos que podem ser aproveitados para atender a essas necessidades, basta saber do que se fala, e como se utiliza. 7 Adilson Taub Júnior Process Manager TecPo.IT adilson.taub@tecproit.com.br
REFERÊNCIAS KRUTCHEN, Philippe, The Rational Unified Process: An Introduction. Addison-Wesley, 2007 IBM, Rational Unified Process. IBM WebSite, disponível em: http://www-01.ibm.com/software/awdtools/rup/?s_tact=105agy59&s_cmp=wiki&ca=dtl- 08rupsite http://www-01.ibm.com/software/rational/ 8