title: Rational Unified Process
text: Rational Unified Process of RUP is een iteratief softwareontwikkelingsproces. Dit proces is een uitgebreide verfijning van het generieke Unified Process (UP) en is ontwikkeld door Rational Software Corporation dat nu een divisie is van IBM.
  
  Algemeen 
  
  Het Rational Unified Process (RUP) vindt zijn oorsprong in het originele spiraalmodel van Barry Boehm. Ken Hartman, een van de belangrijkste RUP-bedenkers, ging samenwerken met Boehm op grond van praktijk- en literatuuronderzoek. De Rational Approach (rationele benadering) is oorspronkelijk ontwikkeld door het bedrijf Rational Software in de jaren 80 en 90. Het Rational Unified Process is ontstaan uit een samenvoeging van het product Rational Approach (van Rational Software) en Objectory Process (van Objectory AB, ontwikkeld door oprichter Ivar Jacobson). De eerste versie van Rational Unified Process V5 werd uitgegeven in 1998.
  
  Totstandkoming 
  De bedenkers en ontwikkelaars van RUP hebben zich geconcentreerd op het analyseren van de karakteristieken waardoor projecten mislukken. Hierdoor konden ze de hoofdproblemen herkennen waardoor projecten vaak mislukken. Op deze lijst staan bijvoorbeeld:
   Ad-hoc requirements
   Vage, dubbelzinnige en onduidelijke requirements
   Overmatige complexiteit
   Onvoldoende testen
  De uitkomst van hun onderzoek was een verzameling van best practices die ze hadden afgeleid van de projecten die wel slaagden. Deze best practices samengevoegd is wat het nu genoemd wordt: Rational Unified Process.
  
  Filosofie achter RUP 
  RUP is gebaseerd op een aantal principes en best practices (versie 6), zoals:
  
  Ontwikkel software incrementeel/iteratief 
  Gezien de tijd die het kost om grote softwaresystemen te bouwen, is het niet mogelijk om een heel systeem in één keer te maken. Requirements kunnen veranderen in de loop van het traject door technische beperkingen, veranderende eisen/wensen of een beter begrip van het daadwerkelijke probleem. Incrementeel ontwikkelen stelt je in staat om het project op te delen in een aantal deelproducten en deze afzonderlijk van elkaar op te leveren. Dit verkleint het risico dat het eindproduct niet is wat de klant wil en de klant kan nu per deelproduct zijn feedback geven wat je weer kunt meenemen tijdens de ontwikkeling van het volgende deelproduct.
  
  Management van software requirements 
  Requirements management heeft te maken met het achterhalen, vastleggen en beheren van de behoeften van de klant. Daaronder vallen de volgende activiteiten:
   Analyseer het probleem
   Definieer wat de klant wil
   Definieer het op te leveren systeem
   Beheer de randvoorwaarden van het systeem
   Verfijn de systeemeisen/systeemomschrijvingen
   Beheer de wijzigende requirements
  
  Maak gebruik van op componenten gebaseerde architectuur 
  Systemen met een op componenten gebaseerde architectuur zijn eenvoudig uit te breiden, inzichtelijk, begrijpelijk en bevorderen het hergebruik van bepaalde delen code. Aangezien de systemen steeds groter worden neemt het belang van een goede architectuur toe. RUP is erop gericht de basisarchitectuur in een vroeg stadium te bepalen, en naarmate het systeem groter wordt zal de architectuur zich verder uitbreiden. Bij iteratief ontwikkelen is het mogelijk de componenten geleidelijk aan in kaart te brengen om ze vervolgens te ontwikkelen, te kopen of te hergebruiken.
  
  Maak prototypes 
  Door de gebruiker een grafische voorstelling te geven van het product (prototyping), wordt voor het project de faalkans verkleind. Een globale, grafische oplossing voor het probleem is door de gebruiker beter te begrijpen dan pagina's vol broncode. Het is een versimpeling van de complexiteit. Naast prototypes komen in deze fase ook usecases, usecasediagrammen, klassediagrammen en andere objecten naar voren.
  
  Test het systeem 
  Het bepalen van de kwaliteit van een systeem gebeurt op basis van testen. Dit is een van de punten waarop softwareprojecten vaak falen, omdat het testen vaak aan het einde van het project wordt gedaan, soms helemaal niet en soms door andere teams. RUP vangt dit probleem af door het testen in het gehele proces terug te laten komen en daarbij alle belanghebbenden (stakeholders) te betrekken (zowel programmeurs als klanten). RUP gaat ervan uit dat elke belanghebbende verantwoordelijk is voor de kwaliteit gedurende het gehele project.
  
  Maak gebruik van versiebeheer tijdens de softwareontwikkeling 
  Zoals bij alle andere softwareprojecten zijn veranderingen in de software onvermijdelijk. RUP beschrijft een aantal methoden om deze veranderingen te beheersen en nauwkeurig te volgen. RUP beschrijft ook beveiligde werkruimtes, hierin staat bijvoorbeeld dat het systeem van een programmeur niet aangetast mag worden door veranderingen in een ander systeem.
  
  Fasering 
  Het RUP voorziet een verdeling van elk project in vier hoofdfases:
   Inceptiefase (Aanvang) - De haalbaarheid van het project, de inhoud (scope) en de begrenzingen worden bepaald. Gedurende de inceptiefase wordt het oorspronkelijke idee omgezet in een productvisie (vision). De business drivers worden geëvalueerd om ze helder te krijgen. De globale kostprijs en de verwachte baten van het project worden geschat. De belangrijkste risico's worden geïdentificeerd en ingeschat. Het uiteindelijke doel van deze fase is een haalbaarheidsstudie (business case) voor het project, of anders gesteld een GO/NOGO voor het project.
   Elaboratiefase (Detaillering) – Het merendeel van de functionele requirements (usecases) wordt gespecificeerd en de systeemarchitectuur wordt ontworpen. De nadruk ligt op de technische haalbaarheid van het project. Uiteindelijke doel van deze fase is een projectplan, waarin onder meer de gedetailleerde inhoud (scope), timing (schedule) en kostenraming (estimations) voor het project zijn opgenomen.
   Constructiefase (Bouw) – Het product wordt ontwikkeld vanaf de architectuur tot een systeem dat compleet genoeg is om te testen.
   Transitiefase (Overgang) – Via testen wordt het product gevalideerd door de belanghebbenden. Andere activiteiten in deze fase zijn: voorbereiding en inproductiename (deployment), nazorg, en overdracht van de verantwoordelijkheden. Deze fase wordt afgesloten met een inventarisatie van de opgedane ervaringen (lessons learned) voor volgende projecten.
  
  Disciplines 
  Er zijn negen disciplines die gedurende de duur van een project zullen voorkomen. De intensiteit waarmee een bepaalde discipline wordt uitgevoerd is vooral afhankelijk van de fase waarin het project zich bevindt. De negen disciplines zijn verdeeld over twee hoofdgroepen: Ontwikkeling en Ondersteuning. De ontwikkelingsdisciplines zijn: Business Modeling, Requirements Engineering, Analysis and Design, Implementatie, Test en Deploy. De ondersteunende disciplines zijn: Project Management, Environment en Configuration en Change Management.
  
  Business Modeling 
  Organisaties worden steeds meer afhankelijk van IT-systemen. Dit maakt het verplicht dat informatieanalisten de kennis hebben hoe applicaties in organisaties kunnen passen. Bedrijven investeren pas in IT als ze de voordelen erin zien en weten wat de toegevoegde waarde zal zijn. Het doel van Business Modeling is om allereerst het wederzijdse begrip en de communicatie tussen business en IT te verbeteren. Wanneer het projectteam kennis heeft van de business, de structuur en doelen van de betreffende organisatie, de problemen binnen de organisatie en mogelijke verbeteringen, dan pas is het in staat om een organisatie in kaart te brengen. Het Business Model omschrijft de visie van de organisatie waarbinnen het systeem zal worden geplaatst; hoe deze visie gebruikt zal worden als uitzetlijn voor het proces, rollen en verantwoordelijkheden.
  Artefacten kunnen hier zijn: mission statement, goal-problem diagram en SWOT matrix.
  
  Requirements Engineering 
  Het doel van Requirements Engineering, het achterhalen en documenteren van de requirements, is te bepalen wat het systeem zal moeten gaan doen. Requirements worden vastgelegd op basis van informatie verkregen van de belanghebbenden. Ze worden vervolgens gestructureerd en gedocumenteerd en nodige functionaliteit en business rules worden eruit gedestilleerd. Ten slotte worden de requirements gevalideerd door de klant alvorens de volgende stap van het proces start.
  
  Tussenproducten die in deze fase naar voren komen zijn:
   Usecases
   Aanvullende functionele en technische specificaties, zoals reactietijden, verwachte volumes, kwaliteits- en beschikbaarheidseisen, gebruiksvriendelijkheid, ...
   Verklarende woordenlijst (Glossary)
   Storyboards; als basis voor de user-interface-prototypes
  Deze deelproducten bij elkaar vormen een SRS: de Software Requirements Specification.
  
  Requirements Engineering start in de inceptiefase, is de belangrijkste activiteit tijdens de elaboratiefase en wordt afgerond tijdens de constructiefase. De requirements worden verder gebruikt in de analyse en het ontwerp van de nieuwe toepassing.
  
  Analysis & Design 
  Het doel van de analyse- en ontwerpactiviteiten (Design) is te bepalen hoe de requirements gerealiseerd gaan worden  in een nieuwe of aangepaste toepassing. Daarbij moet erop worden gelet dat de software:
  
   voldoet aan de taken en functies beschreven in de usecase en functionele specificaties,
   voldoet aan alle technische vereisten,
   eenvoudig aan te passen is wanneer functionele eisen wijzigen.
  
  Deze fase heeft als resultaat een ontwerpmodel en zo mogelijk ook een analysemodel. Het ontwerpmodel dient als abstractie van de broncode; het is een (gedetailleerd) plan met hoe de broncode wordt gestructureerd en geschreven. Het ontwerpmodel bestaat uit klassen, gestructureerd in modules en subsystemen, met duidelijk beschreven interfaces. Het bevat ook de beschrijving over hoe deze klassen met elkaar samenwerken.
  
  Analyse en design starten meestal tijdens de elaboratiefase en lopen door in de constructiefase. De resultaten ervan worden gebruikt in de implementatie.
  
  Implementation 
  Tijdens de implementatieactiviteiten (ook wel: Building) komen naar voren:
  
   Het vastleggen van de organisatie van de broncode, in termen van het implementeren van subsystemen
   Het vastleggen van klassen en objecten
   Het testen van de ontwikkelde componenten (unittesten)
   Het integreren van de resultaten van individuen tot een systeem
  
  Systemen worden gerealiseerd door het implementeren van componenten. Het implementatieproces beschrijft hoe bestaande componenten herbruikt kunnen worden, en hoe nieuwe herbruikbare componenten gebouwd kunnen worden om zo het systeem beter onderhoudbaar te maken.
  
  De implementatie gebeurt overwegend in de constructiefase. De opgeleverde software wordt vervolgens getest.
  
  Testing 
  Testen houdt in:
  
   Het controleren van de interactie tussen verschillende objecten
   Het controleren van de integratie van verschillende componenten
   Het controleren van het systeem om te kijken of alle requirements juist zijn geïmplementeerd
   Het in kaart brengen en prioriteren van defecten
  
  RUP is een iteratief proces wat inhoudt dat tests in verschillende fasen van het project kunnen plaatsvinden. Dit maakt het mogelijk om fouten in een vroeg stadium van het project op te sporen en zorgt ervoor dat de kosten van herstel zo laag mogelijk blijven. Hoe later een fout wordt ontdekt, hoe hoger de kosten van herstel.
  
  De meeste tests zullen in principe plaatsvinden in de constructiefase.
  
  Deployment 
  In de Deployment (ook wel Put-into-Production) worden productreleases voorbereid en wordt de software aan de eindgebruiker opgeleverd. Activiteiten die hierbij naar voren komen zijn:
  
   Het produceren van externe releases van de software
   Het verpakken van de software
   Het distribueren van de software
   Het installeren van de software
   Hulp en assistentie verlenen aan gebruikers
   Oplossen van fouten na oplevering
   Overdracht van de verantwoordelijkheid van de software
  
  Deployment gebeurt in principe tijdens de transitiefase.
  
  Project Management 
  Het plannen van een project in RUP gebeurt op twee niveaus. Er is een gefaseerd plan dat het gehele project beschrijft en een lijst met iteratieplannen die de iteraties beschrijven. Dit onderdeel richt zich voornamelijk op de belangrijke onderdelen van een iteratief ontwikkelproces:
   Onderhouden van risico's
   Het plannen van een iteratief project tijdens de uitvoering van het project en voor een specifieke iteratie
   Het bijhouden van de voortgang van een iteratief project
  
  Dit onderdeel van Rational Unified Process (RUP) dekt echter niet alle onderdelen van het onderhouden van een project. Zo dekt het bijvoorbeeld geen zaken als:
   Werknemers onderhouden: huren, trainen en coachen
   Het budget onderhouden: vaststellen en toewijzen
   Het onderhouden van contracten met leveranciers en klanten
  
  Project management bevat een aantal plannen en onderdelen om het project te sturen en om de voortgang te onderhouden zoals:
   Het faseringsplan
   Het iteratieplan
  
  Environment 
  Dit onderdeel houdt zich bezig met de benodigde acties om de voortgang aan te passen bij een project. Het beschrijft welke acties er nodig zijn om richtlijnen te ontwikkelen die het project ondersteunen. Het doel van deze activiteiten is om de software ontwikkelingsorganisaties te voorzien van een softwareontwikkelomgeving om het ontwikkelteam te ondersteunen.
  Het environment-onderdeel is opgedeeld in drie hoofdlijnen:
  
  De omgeving voorbereiden voor het project 
  Het voorbereiden van een ontwikkelomgeving voor een project betekent dat het onderliggende ontwikkelproces bijgesteld moet worden tot een accepteerbaar projectspecifiek ontwikkelproces. Hierbij komt kijken:
   Aangeven hoe het project gebruik gaat maken van het aangepaste ontwikkelproces
   Het ontwikkelen van een ontwikkelverslag dat de afwijkingen van het onderliggende proces beschrijft
   Kwalificeren van onderdeelselecties door timing en formele vereisten
   Het voorbereiden van projectspecifieke onderdelen, zoals richtlijnen en sjablonen, aan de hand van een ontwikkelverslag
   Het produceren van een lijst met mogelijke toepassingen die gebruikt kunnen worden bij de ontwikkeling
  
  Het voorbereiden van een ontwikkelomgeving voor een iteratie 
  Het doel van het in kaart brengen van deze details is om zeker te stellen dat de projectomgeving klaar is voor de volgende iteratie. Dit maakt gebruik van processen en toepassingen.
  Dit richt zich voornamelijk op:
   Het afronden van het ontwikkelverslag om klaar te zijn voor de iteratie
   Toepassingen voorbereiden en waar nodig aanpassen om te gebruiken binnen de iteratie
   Controleren of de toepassingen correct zijn aangepast en geïnstalleerd
   Het voorbereiden van een aantal projectspecifieke sjablonen en richtlijnen om het ontwikkelen van project onderdelen te ondersteunen in de iteratie
   Zekerstellen dat alle veranderingen in de projectomgeving correct gecommuniceerd zijn naar de projectleden
  
  Ondersteunen van de ontwikkelomgeving tijdens de iteratie 
  Ondersteunt de ontwikkelaars bij hun gebruikmaken van de toepassingen en processen tijdens een iteratie. Hieronder valt de installatie van benodigde software, zekerstellen dat de hardware correct werkt en dat potentiële netwerkproblemen opgelost zijn zonder vertragingen.
  
  Configuration and Change Management 
  Configuration and Change Management in RUP overlapt drie onderdelen:
   Configuration management
   Change request management
   Status and measurement management
  
  Configuration management 
  Configuration management is verantwoordelijk voor het systematisch structureren van de producten. Alle gemaakte onderdelen van een project, zoals documenten en modellen, moeten met behulp van versiebeheer onderhouden worden waarbij alle wijzigingen ongedaan te maken zijn. Ook moet deze oplossing rekening houden met onderlinge relaties tussen bestanden en deze correct bijwerken als er iets veranderd wordt.
  
  Change request management 
  Gedurende het ontwikkelproces bestaan er veel bestanden met verschillende versies. CRM houdt alle verzoeken voor verandering bij.
  
  Status and measurement management 
  Elk verzoek voor verandering heeft zijn eigen status. Zo kan deze nieuw, gelogd, goedgekeurd, toegewezen of compleet zijn. Ook heeft zo'n verzoek attributen zoals oorsprong, origineel, prioriteit enz. Deze statussen en attributen zijn opgeslagen in een database zodat alle bruikbare informatie over de gang van zaken van het project weergegeven kunnen worden. Rational heeft ook software om deze verzoeken voor verandering te onderhouden. Dit programma heet ClearQuest.
  
  Zie ook 
   Unified Modeling Language (UML)
  
  Software engineering