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 right|333px 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