Rational Unified Process

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)