Rational unified process

El Rational Unified Process (RUP) és un marc de processos de desenvolupament de programari iteratiu creat per Rational Software Corporation, una divisió d'IBM des del 2003. RUP no és un únic procés prescriptiu concret, sinó un marc de processos adaptable, pensat per ser adaptat per les organitzacions de desenvolupament i els equips de projectes de programari que seleccionaran els elements del procés que siguin adequats per a les seves necessitats. RUP és una implementació específica del Procés Unificat.^[1]

Rational Software va desenvolupar originalment el RUP com un producte de procés de programari. El producte inclou una base de coneixement amb hipervincles amb exemples d'artefactes i descripcions detallades per a molts tipus diferents d'activitats. El RUP s'inclou al producte Rational Method Composer (RMC), que permet la personalització del procés.

Philippe Kruchten, un representant tècnic experimentat de Rational, va ser l'encarregat d'encapçalar l'equip RUP original.

Aquestes versions inicials combinaven l'àmplia experiència de camp de l'organització Rational Software en la construcció de sistemes orientats a objectes (anomenats pel personal de camp de Rational com a Rational Approach) amb l'orientació d'Objectory sobre pràctiques com ara casos d'ús, i incorporaven un extens contingut de l'enfocament de modelització Object Modeling Technology (OMT) de Jim Rumbaugh, el mètode Booch de Grady Booch i el recentment publicat UML 0.8.^[2][3]

Per ajudar a fer més accessible aquesta base de coneixement creixent, Philippe Kruchten va ser encarregat de muntar un marc de processos explícit per a l'enginyeria de programari moderna. Aquest esforç va emprar el mecanisme de lliurament de processos basat en HTML desenvolupat per Objectory. El "Rational Unified Process" (RUP) resultant va completar un trípode estratègic per a Rational:

• un procés adaptable que va guiar el desenvolupament
• eines que automatitzaven l'aplicació d'aquest procés
• serveis que van accelerar l'adopció tant del procés com de les eines.

Aquesta guia es va ampliar en versions posteriors amb coneixements basats en l'experiència de les empreses que Rational havia adquirit.

El 1997, es van afegir requisits i una disciplina de proves a l'enfocament, gran part del material addicional prové del mètode Requirements College desenvolupat per Dean Leffingwell et al. a Requisite, Inc., i del mètode SQA Process desenvolupat a SQA Inc., ambdues empreses adquirides per Rational Software.

El 1998, Rational Software va afegir dues noves disciplines:

1. modelatge de negoci, gran part d'aquest contingut ja havia estat al Procés Objectori
2. una disciplina de gestió de configuració i canvi, obtinguda a través de l'adquisició de Pure Atria Corporation.

Aquestes addicions condueixen a un conjunt general de principis que van ser definits per Rational i articulats dins de RUP com les sis millors pràctiques per a l'enginyeria de programari moderna:

1. Desenvolupar iterativament, amb el risc com a principal impulsor de la iteració^[4]
2. Gestiona els requisits
3. Emprar una arquitectura basada en components
4. Programari de modelatge visual
5. Verificar contínuament la qualitat
6. Canvis de control

Aquestes bones pràctiques estaven estretament alineades amb la línia de productes de Rational i van impulsar el desenvolupament continu dels productes de Rational, a més de ser utilitzades pels equips de camp de Rational per ajudar els clients a millorar la qualitat i la predictibilitat dels seus esforços de desenvolupament de programari.

S'hi van incloure tècniques addicionals, com ara proves de rendiment, disseny d'IU i enginyeria de dades, i una actualització per reflectir els canvis a UML 1.1.

El 1999, es va introduir una disciplina de gestió de projectes, així com tècniques per donar suport al desenvolupament de programari en temps real i les actualitzacions per reflectir UML 1.3. A més, el primer llibre que descriu el procés, The Unified Software Development Process ( ) d'Ivar Jacobson, Grady Booch i James Rumbaugh., es va publicar el mateix any.

Entre el 2000 i el 2003, diversos canvis van introduir orientacions basades en l'experiència de camp de Rational amb el desenvolupament iteratiu, a més del suport d'eines per a la implementació d'instàncies de RUP i per a la personalització del marc de treball de RUP. Aquests canvis van incloure:

1. la introducció de conceptes i tècniques d'enfocaments com ara eXtreme Programming (XP), que més tard es coneixerien col·lectivament com a mètodes àgils. Això incloïa tècniques com la programació en parells, el disseny de prova primer i articles que explicaven com RUP permetia que XP s'escalés per al seu ús en projectes més grans.
2. una revisió completa de la disciplina de proves per reflectir millor com es va dur a terme el treball de proves en diferents contextos de desenvolupament iteratiu.
3. la introducció de guies de suport, conegudes com a "mentors d'eines", per implementar les pràctiques RUP en diverses eines. Aquestes, essencialment, proporcionaven suport de mètode pas a pas als usuaris de l'eina Rational.
4. automatitzar la personalització de RUP de manera que permeti als clients seleccionar parts del marc de processos RUP, personalitzar la seva selecció amb les seves pròpies addicions i, alhora, incorporar millores en versions posteriors de Rational.

IBM va adquirir Rational Software el febrer de 2003.

El 2006, IBM va crear un subconjunt de RUP adaptat per a l'execució de projectes Agile, publicat com a mètode OpenSource anomenat OpenUP a través del lloc web d'Eclipse.^[5]

El RUP es basa en un conjunt de blocs de construcció i elements de contingut que descriuen què s'ha de produir, les habilitats necessàries i l'explicació pas a pas que descriu com s'han d'aconseguir els objectius de desenvolupament específics. Els principals blocs de construcció, o elements de contingut, són els següents:

• Productes de treball (què): un producte de treball representa quelcom resultant d'una tasca, incloent-hi tots els documents i models produïts mentre es treballa en el procés.
• Tasques (com): una tasca descriu una unitat de treball assignada a un rol que proporciona un resultat significatiu.

Dins de cada iteració, les tasques es classifiquen en nou disciplines:

• Sis "disciplines d'enginyeria"
  • Modelització de negocis
  • Requisits
  • Anàlisi i disseny
  • Implementació
  • Prova
  • Desplegament
• Tres disciplines de suport
  • Configuració i gestió de canvis
  • Gestió de projectes
  • Medi ambient

El RUP ha determinat un cicle de vida del projecte que consta de quatre fases. Aquestes fases permeten presentar el procés a un nivell superior de manera similar a com es podria presentar un projecte en forma de "cascada", tot i que, en essència, la clau del procés rau en les iteracions de desenvolupament que es troben dins de totes les fases. A més, cada fase té un objectiu clau i una fita al final que denota l'objectiu que s'està assolint. La visualització de les fases i disciplines del RUP al llarg del temps es coneix com a diagrama de transició del RUP.

L'objectiu principal és definir adequadament l'abast del sistema com a base per validar els costos i els pressupostos inicials. En aquesta fase s'estableix el cas de negoci, que inclou el context empresarial, els factors d'èxit (ingressos previstos, reconeixement del mercat, etc.) i la previsió financera.

L'objectiu principal és mitigar els elements de risc clau identificats per l'anàlisi fins al final d'aquesta fase. La fase d'elaboració és on el projecte comença a prendre forma. En aquesta fase es fa l'anàlisi del domini del problema i l'arquitectura del projecte pren la seva forma bàsica.

L'objectiu principal és construir el sistema de programari. En aquesta fase, l'enfocament principal és el desenvolupament de components i altres característiques del sistema. Aquesta és la fase en què es duu a terme la major part de la codificació. En projectes més grans, es poden desenvolupar diverses iteracions de construcció en un esforç per dividir els casos d'ús en segments manejables per produir prototips demostrables.

L'objectiu principal és fer la "transició" del sistema del desenvolupament a la producció, fent-lo disponible i comprensible per l'usuari final. Les activitats d'aquesta fase inclouen la formació dels usuaris finals i dels mantenidors, i les proves beta del sistema per validar-lo segons les expectatives dels usuaris finals. El sistema també passa per una fase d'avaluació, en què qualsevol desenvolupador que no produeixi el treball requerit és substituït o eliminat. El producte també es comprova segons el nivell de qualitat establert a la fase inicial.

El producte IBM Rational Method Composer és una eina per crear, configurar, visualitzar i publicar processos. Vegeu IBM Rational Method Composer i una versió de codi obert del projecte Eclipse process framework (EPF) per obtenir més informació.