Rational Unified Process (RUP) E-mail

Rational Unified Process (RUP) is een iteratief softwareontwikkelingsproces.
Dit proces is een uitgebreide verfijning van het generieke Unified Process (UP) en is ontwikkeld door Rational Software Corporation.

 

Algemeen
De wortels van het Rational Unified Process (RUP) liggen in het spiraalmodel van Barry Boehm. Ken Hartman, één 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 van de twintigste eeuw. 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.
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 werden samengevoegd tot wat nu genoemd wordt: Rational Unified Process.

 

Filosofie achter RUP
RUP is gebaseerd op een aantal principes en best practices, zoals:

  1. Ontwikkel software incrementeel/iteratief
    Gezien de tijd die het kost om grote software-systemen te bouwen, is het niet mogelijk om een heel systeem in één keer te maken. Requirements kunnen gedurende het traject veranderen door technische beperkingen, veranderende eisen/wensen of een beter begrip van het daadwerkelijke probleem. Incrementeel ontwikkelen stelt de ontwikkelaar 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. De klant kan nu per deelproduct feedback geven wat de ontwikkelaar vervolgens kan meenemen tijdens de ontwikkeling van het volgende deelproduct.
  2. 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.
  3. 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 in kaart te brengen om ze vervolgens te ontwikkelen, te kopen of te hergebruiken.
  4. Maak prototypes
    Door de gebruiker een grafische voorstelling te geven van het product (prototyping), verkleint de faalkans van het project. 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 use cases, use case diagrammen, klassediagrammen en andere objecten naar voren.
  5. Test het systeem
    Het bepalen van de kwaliteit van een systeem gebeurt op basis van testen. Dit is een van de punten waarop software projecten 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 er vanuit dat elke belanghebbende verantwoordelijk is voor de kwaliteit gedurende het gehele project.
  6. Maak gebruik van versiebeheer tijdens de software-ontwikkeling
    Zoals bij alle andere software-projecten 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 4 hoofdfases:

 

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 9 disciplines zijn verdeeld over twee hoofdgroepen: Ontwikkeling en Ondersteuning.
De Ontwikkeling disciplines zijn: Business Modeling, Requirements Engineering, Analysis and Design, Implementatie, Test en Deploy.
De Ondersteunende disciplines zijn: Project Management, Environment en Configuration en Change Management.

  1. Business Modeling
    Organisaties worden steeds meer afhankelijk van IT systemen. Dit maakt het verplicht dat informatie-analisten 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.
  2. 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. Tenslotte worden de requirements gevalideerd door de klant alvorens de volgende stap van het proces start.
    Tussenproducten die in deze fase naar voren komen zijn:
    - Use cases;
    - Aanvullende functionele en technische specificaties;
    - 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. Het 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.
  3. Analysis & Design
    Het doel van de analyse- en ontwerpactiviteiten (Design) is te bepalen hoe de requirements gaan worden gerealiseerd in een nieuwe of aangepaste toepassing. Daarbij moet worden gelet dat de software:
    - Voldoet aan de taken en functies beschreven in de Use Case 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 klasses, gestructureerd in modules en subsystemen, met duidelijk beschreven interfaces. Het bevat ook de beschrijving over hoe deze klasses 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.
  4. Implementation
    Tijdens de implementatie-activiteiten (ook wel: Building) komen naar voren:
    - Het vastleggen van de organisatie van de broncode,
       in termen van het implementeren van subsystemen;
    - Het vastleggen van klasses 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 kunnen gebouwd worden om zo het systeem beter onderhoudbaar te maken.
    De implementatie gebeurt overwegend in de constructiefase. De opgeleverde software wordt vervolgens getest.
  5. 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 prioritiseren 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.
  6. 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.
  7. Project Management
    Het plannen van een project in RUP gebeurt op 2 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.
  8. 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 software-ontwikkelomgeving 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 ontwikkel proces;
      - 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.
  9. Configuration and Change Management
    Configuration and Change Management in RUP overlapt 3 onderdelen:
    - Configuration management;
    - Change request management;
    - Status and measurement management.

 

 
< Vorige   Volgende >
Joomla Template by Joomlashack
Free Joomla Templates