Rational Unified Process - RUP

O RUP ´e a implementa¸c˜ao da Rational Corporation para o Processo Unificado (UP) de desen-volvimento de software [60]. Na d´ecada de 80, ela investiu na defini¸c˜ao de seu processo a partir da estrutura criada por Ivar Jacobson, o ObjectOry [61], e produziu o que hoje conhecemos como Rational Unified Process (RUP) [80]. Desde sua cria¸c˜ao at´e a atualidade, diversas caracter´ısticas mudaram. Durante os anos 80 e 90, dentre v´arias evolu¸c˜oes, o aspecto iterativo foi absorvido do modelo Espiral criado por Barry Boehm [11] e cada vez mais, RUP mostra-se menos prescritivo e mais flex´ıvel aos diferentes contextos da ind´ustria de software. O RUP ´e um extenso arcabou¸co de pr´aticas, artefatos e papeis, por´em a recomenda¸c˜ao de uso sugere fortemente a an´alise e sele¸c˜ao de um subconjunto desses elementos de acordo com as caracter´ısticas do projeto e da empresa [62].

Ao longo do tempo, o UP/RUP teve seu uso canalizado para o desenvolvimento de grandes

aplica¸c˜oes, o que o deixou com um estigma de processo pesado. Por´em, a atual defini¸c˜ao do processo d´a liberdade para flexibiliza¸c˜ao de sua implementa¸c˜ao, sendo poss´ıvel aproximar sua utiliza¸c˜ao das premissas ´ageis. Com o crescimento das metodologias ´ageis, a pr´opria Rational² tem se empenhado para refor¸car a imagem de processo flex´ıvel e adapt´avel [39], ao estabelecer compara¸c˜oes e paralelos entre RUP e XP [112] e ao sugerir que, apesar da vastid˜ao de elementos no arcabou¸co, ´e determinante a escolha de um n´umero reduzido de artefatos em cada caso de desenvolvimento³ [79] e . Recente-mente, Ivar Jacobson publicou um artigo nomeado “Enough of Processes - Lets do Practices” [62], refor¸cando a tendˆencia por flexibilidade e leveza nos processos.

A partir das premissas do RUP podemos identificar algumas caracter´ısticas do processo:

1. Ataque os riscos r´apido e sempre, sen˜ao eles ir˜ao atacar vocˆe.

2. Entregue valor r´apido e sempre ao seu cliente.

3. Foque em entregar software funcionando nas primeiras itera¸c˜oes.

4. Descubra e acomode as mudan¸cas no in´ıcio do projeto.

5. Defina a arquitetura cedo.

6. Prefira arquiteturas orientadas a componentes e reutilize os componentes.

7. Trabalhe como uma ´unica equipe.

8. Qualidade ´e um estilo de vida, n˜ao um privil´egio.

Os valores ´ageis (Subse¸c˜oes 2.3.1 e 2.3.2) s˜ao percebidos nas premissas de n´umero 1, 2, 3, 6 e 7. Em paralelo, conceitos caracter´ısticos de metodologias tradicionais aparecem claramente nas premissas 4 e 5⁴.

2No in´ıcio de 2003, a IBM adquiriu a Rational Corporation, no entanto, preservou o nome do processo e suas ferramentas.

3Conjunto de artefatos escolhidos especificamente para cada aplica¸c˜ao do UP.

4A 8^a premissa, que diz respeito `a qualidade, decidimos n˜ao atribuir como caracter´ıstica de nenhuma metodologia, uma vez que todas visam `a produ¸c˜ao de software com alta qualidade.

Artefatos

Uma das capacidades do UP ´e a possibilidade de escalar seu grau de formalismo e documenta¸c˜ao para uso em equipes de diversos tamanhos. Desde equipes com menos de uma dezena de participantes, at´e grandes projetos com v´arias centenas de colaboradores. Ao todo, o arcabou¸co conta com cerca de uma centena de tipos de artefatos que podem ser criados durante o projeto [80]. Fica a crit´erio da empresa e do projeto a escolha de quais deles estar˜ao presentes em cadacaso de desenvolvimento. No entanto, aVis˜aoe aLista de Risco s˜ao o m´ınimo que o processo precisa possuir para ser considerado UP. Esta liberdade para escolha sobre uma grande gama de artefatos permite que a implementa¸c˜ao do UP seja t˜ao leve ou pesada quanto se queira [79]. A grande dificuldade ´e justamente a percep¸c˜ao do conjunto ideal de pr´aticas e documentos.

Os artefatos compreendem uma grande variedade de itens produzidos durante o processo. Dentre eles est˜ao diversos tipos de diagramas UML, gloss´arios, listas de regras, especifica¸c˜oes, modelagens, solicita¸c˜oes, planos de trabalho, formul´arios, componentes, testes, relat´orios, an´alises, manuais, dados de carga, entre outros [98]. No entanto, a flexibiliza¸c˜ao do processo permite substituir alguns deles por outros de car´ater menos formal, como cartazes na parede, fotos, diagramas na lousa ou v´ıdeos explicativos, contanto que recebam nomes de acordo com um vocabul´ario comum para n˜ao prejudicar a comunica¸c˜ao e permitir que empresas com centenas de desenvolvedores possam reutilizar artefatos e integrar novos participantes com mais facilidade.

Fases

O processo de desenvolvimento passa por quatro fases: Concep¸c˜ao, Elabora¸c˜ao, Constru¸c˜ao e Transi¸c˜ao. Cada uma ´e composta por itera¸c˜oes idealmente curtas, de duas a seis semanas. O avan¸co para a pr´oxima fase acontece quando os objetivos da fase atual s˜ao alcan¸cados. Tais objetivos s˜ao apresentados na listagem abaixo. Contudo, o modo de alcan¸c´a-los n˜ao ´e estritamente determinado pela metodologia. O projeto e as condi¸c˜oes de trabalho da empresa devem ser levados em considera¸c˜ao para a escolha das atividades e artefatos criados para atingir as metas.

• Concep¸c˜ao - Dura geralmente poucos dias. O suficiente para estabelecer uma vis˜ao de alto n´ıvel sobre os objetivos, o escopo e as prioridades, para colher os 10% dos requisitos mais relevantes, identificar os principais riscos e elaborar uma estimativa de esfor¸cos. Isso ´e feito atrav´es de oficinas de requisitos [80], com hist´orias e cen´arios de uso, de prototipa¸c˜ao, de rascunhos de interface e da identifica¸c˜ao de regras, restri¸c˜oes e requisitos n˜ao-funcionais.

Figura 2.1: As fases do RUP e a distribui¸c˜ao do volume de atividades em cada uma delas, obtido de [98].

• Elabora¸c˜ao- A compreens˜ao dos requisitos se estende em quantidade e em profundidade para o todo o software. O n´ucleo da arquitetura e as partes mais cr´ıticas s˜ao desenvolvidos e testados de forma que os principais riscos s˜ao minimizados e ´e poss´ıvel obter uma estimativa razo´avel de dura¸c˜ao e esfor¸co. Essas metas s˜ao alcan¸cadas atrav´es de itera¸c˜oes curtas contendo oficinas de requisitos, modelagem, programa¸c˜ao e testes.

• Constru¸c˜ao- Com base em uma estrutura est´avel criada nas fases anteriores, a implementa¸c˜ao do sistema ´e realizada nesta fase, portanto esta tende a ser a fase mais longa do processo. Uma vers˜aoalphacom documenta¸c˜ao ´e produzida a partir de itera¸c˜oes curtas com pouca modelagem e muita programa¸c˜ao, testes e avalia¸c˜oes dos clientes.

• Transi¸c˜ao- O sistema fica pronto para entrar em produ¸c˜ao. Uma vers˜ao beta ´e produzida e avaliada, e com base no feedback, alguma programa¸c˜ao e ajustes s˜ao feitos para chegar `a vers˜ao que entrar´a em produ¸c˜ao acompanhada da documenta¸c˜ao completa.

Pr´aticas

As pr´aticas do UP traduzem seus princ´ıpios ematividades que s˜ao realizadas pelo participantes.

Apesar de UP definir in´umeras pr´aticas e atividades para o desenvolvimento de um software, seis delas se destacam como mais importantes pois re´unem o m´ınimo necess´ario para expressar a essˆencia do processo [80].

1. Utilize timebox⁵ de duas a seis semanas para cada itera¸c˜ao realizando programa¸c˜ao desde o in´ıcio. Isso tornar´a o processo iterativo e as decis˜oes ser˜ao embasadas pelo conhecimento ganho a partir do esfor¸co de programa¸c˜ao. O software poder´a ser adaptado `a medida que o conhecimento sobre os requisitos aumentar e os maiores riscos forem ou descobertos ou minimizados.

2. Foque em desenvolver primeiro os requisitos de alto risco e alto valor e reaproveite componentes prontos pois eles tamb´em diminuem o risco uma vez que o c´odigo j´a foi testado.

3. Verifique a qualidade constantemente. Desenvolva, crie testes, execute testes e integre o c´odigo freq¨uentemente. Valide tamb´em a qualidade do processo atrav´es de reuni˜oes de reflex˜ao sobre o andamento do desenvolvimento.

4. Rascunhe a itera¸c˜ao. Antes de come¸car a programar, desenhe e discuta os principais pontos da modelagem. Para isso, diagramas UML podem ser esbo¸cados em uma lousa ou criados com ajuda de ferramentas CASE.

5. Gerencie os requisitos. Descubra os requisitos iterativamente e, com aux´ılio de uma ferramenta, organize-os, refine-os e acompanhe os seus estados.

6. Gerencie mudan¸cas definindo regras para altera¸c˜oes e mantenha as regras atualizadas.