1                Introductie

Een bekende methode die vaak in verband wordt gebracht met enterprise-architectuur is het Rational Unified Process (RUP). Enterprise-architecten zijn behalve uit de bedrijfskundige en de infrastructuurtechnische hoek ook vaak afkomstig uit de wereld van de softwareontwikkeling waar zij voor het eerst in aanraking kwamen met softwarearchitectuur. De enterprise-architectuurkwalificatie van RUP wordt hier verder besproken.

In deze paragraaf wordt niet alleen de modelleer- en ontwikkelmethode RUP behandeld, maar ook diverse methoden zoals het Unified Process (UP), waarop RUP is gebaseerd, het Enterprise Unified Process (EUP) en het Agile Unified Process (AUP) die alle nauw met het UP samenhangen en daar doorontwikkelingen van zijn. De Unified Modeling Language (UML) waarin RUP wordt uitgedrukt en waarin de niet op tekst gebaseerde RUP-producten worden vervaardigd, wordt in een afzonderlijk hoofdstuk besproken. RUP maakt deel uit van de wereld van softwareontwikkeling, waarin naast RUP enerzijds de Agile-ontwikkelmethoden (AM) en anderzijds de dynamische projectmanagementmethoden (zoals de Dynamische Systems Development Method – DSDM) een plaats verworven hebben. Van deze methoden wordt de relatie met RUP belicht, en ook zullen we hun relatie met de enterprise-architectuur toelichten.

Hoewel aandacht voor architectuur een prominente plaats inneemt in alle hierboven genoemde methoden, is het doel van deze methoden zonder uitzondering om uiteindelijk kwalitatief goede applicaties of informatiesystemen op te leveren. In de methoden die op het Unified Process gebaseerd zijn is er wel aandacht voor de gehele levenscyclus van informatiesystemen onder regie van de enterprise-architectuur, maar het opleveren of beschrijven van de enterprise-architectuur zelf is geen doelstelling. Er zijn echter bewegingen gaande om het Unified Process te richten op het architectuurproces, als ook om met behulp van UML enterprise- of businessarchitecturen te beschrijven. IBM, als eigenaar van RUP, legt met het op RUP-gebaseerde product Rational Method Composer ook nadrukkelijk het accent op architectuur. Met dit product kunnen binnen RUP aangepaste metamodellen worden opgevoerd met nog niet in RUP bestaande typedefinities, sjablonen en niet te vergeten afhankelijkheidsrelaties. Daarmee is de deur geopend naar tal van gebieden buiten de directe softwareontwikkeling, met name naar de enterprise-architectuur.

Hoewel de RUP-methoden niet direct enterprise-architectuur ‘ademen’ is het goed om te beseffen dat zij het resultaat zijn van bijna een halve eeuw grip krijgen op en structuur brengen in het fenomeen softwareontwikkeling door mensen die vaak hun wortels hadden in de (productie-)industrie. Het werken met gemeenschappelijke standaarden is daar al veel langer gebruikelijk. Het vakgebied van enterprise-architectuur is daarmee vergeleken in zijn tweede decennium tamelijk jong. Het dilemma generiek versus specifiek, dat speelt bij de ontwikkeling van software, zien we ook terug in

de enterprise-architectuur. Daarom kan het vakgebied enterprise-architectuur voortbouwen op verworvenheden uit de historie van de softwareontwikkeling.

Geschiedenis

Figuur 1: Spiraalmodel van Barry Boehm.

De oorsprong van RUP wordt meestal gelegd bij het spiraalmodel van Barry Boehm, dat een incrementeel ontwikkelproces beschrijft [Boehm, 1988]. In hetzelfde jaar wordt de directe voorloper van RUP, de Objectory opgericht door Ivar Jacobson [Jacobson, 1988].

Aan de basis van RUP staan Grady Booch, James Rumbaugh en Ivar Jacobson, later bekend als de drie amigos. In samenwerking met anderen ontwikkelden zij in de jaren negentig van de vorige eeuw modelleerwijzen en ontwikkelaanpakken in net zo veel smaken als architectuurmethoden vandaag de dag. Hoewel internet – zoals we dat nu kennen – nog niet bestond, is er een wijdverbreide kruisbestuiving van ideeën tussen de toenmalige IT-pioniers.

De drie amigos waren de eersten die concludeerden dat het samenwerking vereist om een methode te formuleren die zo breed mogelijk gedragen kan worden. Dit soort samenwerking is geheel in lijn met de totstandkoming van tal van open standaarden, maar de ontwikkeling van het Unified Process is toch enigszins apart te noemen, gedreven als zij is door de fusies van bedrijven en bedrijfjes op het terrein van softwareontwerp [Jacobson, 1998]. Maar het heeft wel gewerkt, gelet op het aandeel dat RUP en UML in huidige softwareontwikkeling hebben.

Een belangrijk moment voor RUP is de Amerikaanse conferentie over software- ontwikkeling OOPSLA in 1995. Op deze conferentie zijn de vertegenwoordigers van SCRUM, Agile en het toekomstige RUP allemaal aanwezig en ziet een aantal ontwikkelingen het licht. Vanaf dat moment zullen RUP en DSDM zich ontwikkelen tot alles omvattende methoden. Terwijl methoden als Extreme Programming [FowlerBeck1996], SCRUM [SCRUM1995], Agile Modeling [AM2002] (dat RUP voor het eerst combineerde met de Agile-methoden), het OpenUP [OUP2005], het Agile Unified Process [AUP1999] en het Enterprise Unified Process [EUP2005] zich richten op het snel leveren van resultaten die goed bij de vraag van de organisatie aansluiten.

Nadat Philippe Kruchten – bekend van de ‘4 + 1 aanpak van softwarearchitectuur’ [Kruchten, 1995] – zich bij het drietal voegt, beschikt Rational over voldoende instrumenten om begin 1999 de volledig door software ondersteunde RUP-suite te lanceren. Eerder, in 1998, is het Unified Process aan de open community overgedragen, namelijk aan de Object Management Groep (OMG).

Terwijl UP en RUP zich in 1998 wenden tot de OMG, levert het ‘Agile Manifesto’ (www.agilealliance.org) in 2001 een gezamenlijk uitgangspunt en ontwikkelt Agile/ SCRUM zich tot een begrip dat aanspreekt in de softwareontwikkeling. RUP is daardoor genoodzaakt om zich opnieuw uit te vinden als bibliotheek van ‘best practices’ die ook SCRUM-achtige aanpakken ondersteunt, naast de meer gestructureerde enterprise-brede ontwikkelingen.

In 2003 wordt Rational overgenomen door IBM. Vanaf dat moment wordt de ontwikkellijn van IBM (Eclipse, WSAD development workbench) samen met RUP en de RUP–hulpmiddelen, zoals Rational Rose, ondergebracht in de IBM Rational-lijn. Het product in de Rational-lijn dat RUP ondersteunt, is Rational Method Composer. Een ander product, de Rational Process Library, bevat RUP als één van de ondersteunde ontwikkelprocessen wat aantoont dat IBM zich in de Rational-lijn ook richt op de Agile-methoden.

2                Beschrijving

RUP is gebaseerd op een set van zes basisprincipes die in het Engels ook wel met ‘ABCDEF’ worden aangeduid. Deze principes zijn (vrij vertaald):

  1. Pas het proces aan het doel aan.
  2. Ga evenwichtig om met de prioriteiten van alle belanghebbende.
  3. Werk samen in teams of taakgroepen.
  4. Toon de toegevoegde waarde aan in iteratieve (en evalueerbare) opeenvolgende fasen.
  5. Verhoog het abstractieniveau boven het niveau van de directe doelstelling (de eerste stap van ‘think big, act small’).
  6. Houd voortdurend de kwaliteit in het oog.

De zes hierboven genoemde basisprincipes misstaan niet in een aanpak voor enterprise-architectuur. Dat verklaart ook de claim dat RUP geschikt is als architectuurmethode. De eigenaar van de methode, IBM, gaat echter niet verder dan de uitspraak dat RUP geschikt is voor de ontwikkeling van software-intensieve systemen.

Welbeschouwd is RUP gefundeerd op vier pijlers, te weten projectmanagement, wijziging- en configuratiebeheer, architectuurcentrisch visueel modelleren en gestructureerde iteratieve ontwikkeling.

RUP is opgezet als een ontwikkelraamwerk voor ‘software intensieve systemen’. Om als methode gebruikt te kunnen worden, moet dit raamwerk worden gevuld met eigen bouwstenen. De meeste bouwstenen kunnen worden gebaseerd op een uitgebreide, meegeleverde bibliotheek van generieke componenten voor allerlei doelen.

Het raamwerk bestaat uit een samenspel van meerdere dimensies of invalshoeken met elk een generieke invulling. In RUP onderkennen we als invalshoeken best practices, fasen, interne en externe disciplines en bouwstenen. Hieronder worden deze invalshoeken besproken.

De zes best practices

  1. Ontwikkel Een informatiesysteem wordt niet in een ‘big bang’ opgeleverd, maar in een aantal stappen waarbij de opdrachtgever en de toekomstige gebruikers de mogelijkheid hebben feedback te geven. Daardoor komt het uiteindelijke resultaat veel dichter bij het gewenste resultaat. Bovendien krijgen de gebruikers ook de tijd om aan het nieuwe systeem te wennen.
  2. Beheers de eisen. De eisen aan een informatiesysteem veranderen voortdurend onder invloed van het voortschrijdend inzicht bij de belanghebbenden. Als deze ‘requirements creep’ en het effect ervan op de te realiseren functionaliteit van het informatiesysteem onvoldoende worden gecontroleerd, ontstaat al snel een onbeheersbare situatie die leidt tot een groeiend gat tussen het gerealiseerde en gewenste resultaat.
  3. Gebruik componenten. Door de omvang en het doel van de componenten af te stemmen op de toepassing in de reële wereld, wordt het makkelijker om complexe systemen te Componenten zijn in essentie herbruikbare systeemonderdelen. Elke keer dat een component opnieuw wordt gebruikt, worden de kosten gedeeld door een groter aantal gebruikers, wat gunstig uitwerkt op de kosten van het informatiesysteem.
  4. Modelleer Alle moderne complexe systemen zijn vooraf of soms achteraf gevisualiseerd in tekeningen volgens een bepaalde standaard. Het systeem is daardoor veel makkelijker te begrijpen, en, wat belangrijker is, het wordt veel eenvoudiger om met de opdrachtgevers en gebruikers over het systeem te communiceren. Voorwaarde is wel dat er een gemakkelijk te begrijpen visuele standaard bestaat, zoals de NEN-normen voor bouwkundige tekeningen. In het geval van RUP is dat UML.
  5. Bewaak de kwaliteit. De kwaliteit van een informatiesysteem wordt voor een belangrijk deel bepaald door de mate waarin het systeem voldoet aan de gestelde eisen. Daarbij gaat het vooral om eisen als continuïteit, capaciteit of effectiviteit die misschien niet expliciet door een belanghebbende zijn gesteld maar wel een groot effect hebben op het operationele en financiële risico dat de eigenaar van het systeem
  6. Beheers wijzigingen in de De drijfveer voor het realiseren van elk RUP- product ligt in het wijziging- en configuratiebeheer. Zowel de eerste als de tweede best practice zijn gebaat bij dit controlerende proces dat ook wel wordt aangeduid met ‘releasemanagement’. RUP onderkent dat er aan het eind van het ontwikkeltraject niet plotseling een systeem wordt opgeleverd, maar dat gedurende de levenscyclus van een informatiesysteem er zo veel opleveringen worden gedaan als nodig is om aan de wijzigende eisen tegemoet te komen zolang dat kostentechnisch verantwoord is. Wijziging- en configuratiebeheer zijn inmiddels in alle ontwikkel- en beheermethoden het sleutelproces tussen de bouw- en onderhoudsfase en de exploitatiefase.

De vier fasen

Tijdens de vier fasen die RUP onderkent en die in feite de bouw- en onderhoudsfasen uitmaken in de levenscyclus van een informatiesysteem, verschuift de aandacht gaandeweg van een focus op het ontwerp naar een focus op het bouwen en testen. Hieronder zijn deze fasen beschreven.

  1. In de aanvangsfase worden de eisen aan het te realiseren informatie- systeem op hoofdlijnen vastgesteld. Het systeem wordt op hoofdlijnen ontworpen, de ‘architectuur van het systeem’ wordt opgesteld en de impact op de systeem- omgeving wordt bepaald. Dit resulteert in de ‘business case’ voor het systeem.
  2. In de uitwerkfase wordt de architectuur verder gedetailleerd. Deze fase moet resulteren in een realistisch ontwerp dat kan worden gebouwd.
  3. In de bouwfase wordt het systeem bouwsteen voor bouwsteen gerealiseerd. In deze fase wordt elke bouwsteen getoetst aan zijn ontwerp en de daaraan gestelde eisen. De eisen en het ontwerp en daarmee het bouwresultaat kunnen in deze fase nog veelvuldig worden aangepast.
  4. In de overgangsfase wordt het informatiesysteem aangeboden aan de opdrachtgever en gebruikers en na acceptatie wordt het systeem in gebruik genomen.

De zes interne en drie externe disciplines

De fasen die RUP doorloopt volgen elkaar in de tijd min of meer op. In elke fase worden dezelfde soorten werkzaamheden verricht met dit verschil dat het zwaartepunt in de werkzaamheden verschuift van de ene discipline naar de andere. In figuur 2 is dit te zien (gebaseerd op EUP).

De disciplines die in RUP worden onderkend, volgen de werkzaamheden die nodig zijn gedurende het ontwikkeltraject. De zes plus drie disciplines zijn:

  1. Business modeling. Modelleren van de bedrijfsarchitectuur en bedrijfsprocessen die als context en uitgangspunt dienen voor het vervolg
  2. Categoriseren, analyseren, koppelen aan belanghebbenden en verifiëren van wensen.
  3. Analyse en Oplossingen specificeren, eerst in grote lijnen, daarna in detail.
  4. Tegen de specificaties bouwen van de oplossing.
  5. Testen of het systeem werkt op systeemniveau en daarna op gebruikersniveau.

Figuur 2: Procesplaat van EUP.

  1. Het installeren voor gebruik en opleveren van het systeem.
  2. Projectmanagement.
  3. Wijziging- en configuratiebeheer.
  4. Omgevingsbeheer.

De drie belangrijkste bouwstenen

De drie bouwstenen van RUP zijn wellicht nog het eenvoudigst uit te leggen. In het proces van het ontwikkelen van een informatiesysteem of het opstellen van een architectuur, moet een aantal verantwoordelijkheden worden genomen. Als blijk daarvan wordt een opdracht uitgevoerd die resulteert in een product dat door de volgende verantwoordelijke als uitgangspunt wordt gebruikt. Deze opdrachten of taken kunnen eenvoudig in een takenplanning worden opgenomen. Aan de producten kan de voortgang worden afgemeten. Degene die vanuit een bepaalde rol een opdracht uitvoert, wordt de eigenaar van het product. Alle betrokkenen dragen zo hun steentje bij aan het eindresultaat. De drie bouwstenen zijn:

  1. Rollen, ook wel verantwoordelijkheden genoemd.
  2. Producten c.q. resultaten.
  3. Taken q. verplichtingen.

Elk van de hierboven genoemde invalshoeken geeft een eigen zicht op RUP, maar RUP komt pas tot zijn recht op het snijvlak van de invalshoeken, waar gewerkt wordt aan resultaten met inachtneming van alle invalshoeken. Door dit een plaats te geven slaagt RUP erin het proces te sturen op kenmerken die impliciet altijd al in ontwikkelprocessen aanwezig waren.

Het is van belang om vast te stellen dat het de gebruiker vrij staat voor een bepaalde doelstelling een willekeurig deel van de invalshoeken te gebruiken. In die zin is RUP meer een gereedschapskist dan een werkwijze. Als de gebruiker echter niet wil kiezen, zijn er in de diverse cases en richtlijnen voldoende manieren aanwezig om de probleemstelling aan te passen. Niet kiezen houdt voor de gebruiker wel in dat hij vanwege het gebrek aan ‘out-of-the-box’ doelgerichtheid een complexer ontwikkeltraject moet doorlopen.

De werking van RUP

RUP gaat ervan uit dat aan een informatiesysteem gedurende de hele levenscyclus nieuwe eisen gesteld zullen worden. De wijzigingen die daarvoor moeten worden aangebracht, zullen leiden tot nieuwe opleveringen van het informatiesysteem dat in productie moeten worden genomen. Het wijziging- en configuratiebeheer in RUP is toegerust om de gerealiseerde functies in een oplevering te blijven correleren aan de daaraan gestelde eisen. Doordat een informatiesysteem in meerdere iteraties wordt opgeleverd, ontstaat de ruimte om aan de eisen verschillende prioriteiten toe te kennen zodat ze in andere opleveringen kunnen worden gerealiseerd.

Als aan een nieuwe oplevering wordt begonnen, wordt de bestaande oplevering als uitgangspunt gekozen. De nieuwe of veranderde eisen worden via een (impact)analyse aan de nieuwe of wijzigende functionaliteit gerelateerd. Voor de realisatie van deze functionaliteit wordt een ontwikkeltraject gestart dat via het opstellen van ‘use- case’-scenario’s, een analysefase en een ontwerpfase overgaat in een bouwtraject. Als de functionaliteit is gebouwd, wordt die getest op de correcte werking waarna de volledige oplevering getest wordt voordat die in productie kan worden genomen.

De ontwikkeltrajecten worden aangestuurd door het projectmanagement. Het projectmanagement laat een cyclische benadering van een traject toe. In RUP zijn de opvolgende taken beschreven waaruit een traject bestaat. Van een taak is in algemene zin beschreven wat de rol is van degene die de taak uitvoert en welk resultaat de taak moet opleveren. Voor het uitvoeren van taken zijn in RUP voorbeelden, richtlijnen en aftekenlijsten voorhanden, terwijl voor de meeste resultaten of producten sjablonen of documentindelingen bestaan.

RUP beschrijft, voordat met een bepaalde taak kan worden begonnen, welke eerdere taken eerst moeten zijn afgerond. RUP beschrijft ook welke taken daarna volgen.

Hetzelfde geldt voor producten die gereed moeten zijn voordat met andere producten kan worden begonnen. In alle gevallen werkt RUP incrementeel, wat inhoudt dat producten niet definitief hoeven te zijn afgerond, maar wel voldoende informatie moeten bevatten om te kunnen starten met de volgende taak.

In de eerste opleveringen ligt het accent iets anders, omdat daar het fundament gelegd moet worden voor het informatiesysteem gedurende de hele levenscyclus. In de eerste opleveringen ligt de nadruk op de architectuur en het realiseren van architectuur- producten. Omdat het informatiesysteem in zijn context moet passen, ligt hier de sterkste verbinding met de enterprise-architectuur van de organisatie die het systeem straks gaat gebruiken.

RUP en de Agile-methoden

Agile-methoden volgen de meeste basisprincipes, best practices en overige inzichten van RUP redelijk dicht. Wat zij in algemene zin niet doen is verantwoordelijkheid nemen voor besluiten of activiteiten die niet direct zijn gericht op het vervaardigen van kwalitatief goed afgestemde softwareresultaten, of daar slechts ondersteunend aan zijn. In weerwil van de opkomst van de Agile-methoden blijft RUP zich daarom richten op de ondersteuning van meer gestructureerde enterprise-brede ontwikkelingen. Dat is in de RUP-benadering nodig omdat de Agile-methoden slechts een min of meer beperkt deel van het realiseren van informatiesystemen naar zich toe trekken. De Agile-methoden verwachten bijvoorbeeld dat de enterprise- en systeemarchitecturen buiten het ontwikkeltraject worden opgezet en klaar zijn om de resultaten op de juiste manier op te nemen. Enerzijds laat dat de enterprise-architecten de ruimte om het architectuurproces met eigen methoden volgens eigen inzichten in te richten, anderzijds bevordert dat de afstand in de communicatie tussen twee sleutelprocessen binnen de marktgerichte ontwikkeling van een organisatie. In het laatste geval wordt de inbreng van de architecten niet belangrijk gevonden door de Agile-teams, wat leidt tot problemen bij hergebruik, consolidatie, rationalisatie, harmonisatie, systeemdocumentatie en bedrijfsstandaarden. En dat leidt weer tot nog meer geboden, verboden en blauwdrukken die door de architecten worden opgelegd aan de Agile-teams. RUP benoemt de samenhang tussen al deze belangen en maakt het mogelijk die te bewaken. RUP schrijft echter niet voor hoe de best practices moeten worden gebruikt. Men kan RUP dus ook foutief gebruiken.

Processen als AUP proberen de Agile-aanpakken te combineren met RUP om toch

een lichtgewicht maar allesomvattend bereik te krijgen.

Op internet woedt al geruime tijd de discussie of Agile-methoden wel te combineren zijn met enterprise-architectuur. De meningen zijn verdeeld, maar de benadering van RUP laat zien dat de verschillen in elk geval overbrugd kunnen worden. Ook dat maakt RUP een belangrijke factor in de beleving van architectuur bij software- ontwikkeling.

 

3                Positionering

De focus van RUP ligt op systeemontwikkeling. De hoge scores op de werkwijze, representatiewijze, ondersteuningswijze en beheer- en exploitatiewijzen in figuur 3 laten zien dat RUP een zeer volledige methode is voor systeemontwikkeling. De representatiewijze van RUP is vooral toegerust om systeemtechnisch te modelleren en te documenteren. RUP kent als interne modelleertaal alleen UML dat in dit boek separaat is beschreven. De beheer- en exploitatiewijze van de eigenaar scoort iets lager, namelijk 4,21 op een schaal van 5, wat vooral veroorzaakt wordt doordat RUP geen echte open methode is. De relatief lage score voor de bruikbaarheid laat vooral zien dat RUP moet worden ingericht voor gebruik met een bepaald doel en dat dit niet per se eenvoudig is. De reden daarvoor is dat RUP een generieke aanpak beschrijft en een zeer uitgebreide bibliotheek bevat van best practices waar voor elk project wel een goede start bij zit. Zonder best practices zou de score nog lager uitgevallen zijn. De gemiddelde score op de denkwijze laat duidelijk zien dat de focus niet ligt op enterprise-architectuur, maar benadrukt dat alle voorwaarden aanwezig zijn om de ondersteuning voor enterprise-architectuur in te richten.

Figuur 3: RUP gepositioneerd op het vergelijkingsmodel.

Denkwijze

De denkwijze achter RUP bestaat vooral uit het gedachtegoed dat wordt uitgedrukt in de zes basisprincipes. RUP heeft een duidelijke visie op software-intensieve systemen en dan vooral op het realiseren daarvan. De omgeving waartoe RUP zich beperkt is de softwareontwikkelomgeving. RUP houdt zich enigszins bezig met de onderliggende infrastructuur, maar bemoeit zich niet met de organisatie of cultuur waarin een systeem draait anders dan dat tot uitdrukking is gekomen in de eisen die aan het systeem zijn gesteld.

RUP is van de allesomvattende systeemontwikkelmethoden en van de meer specialistische Agile-methoden degene die het meeste belang hecht aan softwarearchitectuur en aan enterprise-architectuur. Maar hoewel er tal van best practices zijn die ingaan op softwarearchitectuur en de rol daarvan in de totstandkoming van softwaresystemen, is dat voor enterprise-architectuur niet het geval. De methode blijft gericht op het realiseren van software en niet op het realiseren van architecturen. Het alles- omvattende karakter van de methode met aandacht voor programmamanagement, wijzigingsbeheer en softwarearchitectuur maakt het een veelgebruikte methode voor omvangrijke IT-projecten en -programma’s.

RUP heeft geen visie op aspecten van de werkelijkheid waarin een systeem moet draaien, behalve dat de stakeholders veelvuldig moeten geraadpleegd over hun requirements, zodat ze aangehaakt blijven. In de best practices is een aantal specifieke werkelijkheden gemodelleerd als voorbeelden, maar de afstemming daarvan gedurende het gebruik wordt niet ondersteund.

In een door de gebruiker of een community aangepaste vorm van RUP kan echter een willekeurig aantal aanvullende denkwijzen schuilen. In de praktijk worden deze variaties ook aangetroffen.

RUP schrijft niet voor hoe het gebruikt moet worden. RUP is en heeft geen besturingsfunctie. De gebruiker kan RUP gebruiken voor projectmanagement en zo de regie nemen in het ontwikkelproces, maar RUP schrijft dat niet voor. De gebruiker is bijvoorbeeld ook vrij om RUP in te zetten voor enterprise-architectuur, terwijl het ontwikkelproces Agile verloopt en zodoende de uitgebreide RUP-toolset kan gebruiken voor de afstemming tussen beide, maar hij zal dit zelf moeten inrichten.

Beheer- en exploitatiewijze eigenaar

De eigenaar van de methode RUP is IBM. RUP maakt deel uit van de IBM Rational- productlijn. UML is ondergebracht bij de Object Management Group (OMG), waarin de meeste grote softwarehuizen zijn vertegenwoordigd. Het UP is echter nooit door de OMG in beheer genomen.

Zowel RUP als de andere van het UP afgeleide methoden maken ontwikkelingen door. RUP is inmiddels aangekomen bij versie 7, een versienummering die gelijk loopt met de Rational Method Composer. De suite van hulpmiddelen rondom RUP wordt verder geprofessionaliseerd voor andere systeemontwikkelmethoden naast RUP.

Nadat RUP globaal door meer dan een half miljoen ontwikkelaars is gebruikt, heeft IBM in het najaar van 2005 een deel van RUP aan de open source community overgedragen. De daarmee beoogde doelen waren betere softwarekwaliteit en betere communicatie over software. UML, UP en RUP kennen elk een community die door leveranciers volop wordt bediend met communityversies van hulpmiddelen en suites. Er is op het gebied van UML en RUP een groot aantal opleidingen.

Rondom de Agile- en Enterprise-varianten van het UP hebben zich kleinere communities gevormd, in elk geval in verhouding tot de Agile-methoden zoals SCRUM die zich in de volle aandacht weten van leveranciers en klanten.

Beheer- en exploitatiewijze gebruiker

De gebruiker wordt door RUP in de watten gelegd. Nadat de gebruiker RUP aan de eigen wensen heeft aangepast, beschikt RUP over alle mogelijke hulpmiddelen om de in het kader van RUP te produceren producten te maken, op te slaan en te wijzigen. Zoals dat met RUP het geval is, moet de gebruiker ook het beheer van de producten die RUP oplevert zelf inrichten. RUP werkt samen met het merendeel van de verkrijgbare versiebeheerpakketten.

Werkwijze

Aangezien een groot deel van dit hoofdstuk de werkwijze van RUP al beschreven heeft, kunnen we er hier kort over zijn. RUP is een werkwijze, gericht op het realiseren van software-intensieve systemen en na aanpassing geschikt voor het realiseren van elk gewenst resultaat. RUP bevat aanpakken voor de functionele inhoud, de projectbesturing, de architectuur enzovoort. Hier kan ten overvloede worden herhaald dat RUP doet waarvoor het door de gebruiker is ingericht: de gebruiker krijgt wat hem toekomt.

Representatie- en modelleerwijze

RUP heeft alle mogelijke producten van het softwareontwikkelproces opgenomen in de methode. Van veel producten zijn sjablonen, afvinklijsten of voorbeelden beschikbaar, aangevuld met het advies om ze voor eigen gebruik aan te passen. De grafische presentatietaal van RUP is UML, waarbij UML de mogelijkheid biedt om op verschillende niveaus van detaillering te worden toegepast. Gebruikers van RUP hoeven maar heel weinig representaties zelf te verzinnen.

Zoals bij de meeste visuele talen kunnen verschillende presentaties in UML in een visuele weergave niet gecombineerd worden. UML, en dit geldt ook voor andere visuele symbooltalen, wordt ook al vlug te technisch en te gedetailleerd. Soms ligt de kracht van goede communicatie juist in het weglaten van details.

De steeds terugkerende discussie met de gebruikers is dan of die details wel mógen worden weggelaten.

Ondersteuningswijze

RUP en de op UP gebaseerde varianten kennen een groot aantal zeer diverse hulpmiddelen. Er is een grote inspanning gedaan om de modellen in al die hulpmiddelen onderling uitwisselbaar te maken. Zo kan een UML-model via XMI in een ander hulpmiddel worden ingeladen en kunnen diagrammen naar elkaar worden omgezet en geëxporteerd naar diverse andere talen, zoals XML en ArchiMate.

Door het fundament van best practices onder RUP en de overal aanwezige uitgebreide toelichtingen is RUP ook goed te combineren met andere standaarden, zoals PRINCE2 en Agile-methoden.

Bruikbaarheid

RUP en ook UML zijn uitermate goed bruikbaar. Beide worden in Nederland erg veel toegepast en worden ook onderwezen binnen diverse opleidingen. Beide kunnen flexibel worden ingezet voor talloze doelen, waarbij ze niet beperkt worden tot het ontwikkel- en ontwerpproces, maar ook toepassing vinden in processen van organisaties en daarbij te maken krijgen met het modelleren van cultuur, wetgeving enzovoort.

Gebruikers hoeven geen wijzigingen in RUP of UML aan te vragen, omdat beide een mechanisme bevatten waarmee ze kunnen worden aangepast aan de wensen van de gebruiker.

4                Conclusies

RUP is geen enterprise-architectuurmethode en pretendeert ook niet dat te zijn. Er is op dit front echter beweging geconstateerd. RUP is wel geschikt te maken voor een meer expliciete architectuurtoepassing. Dit gebeurt al door veel organisaties en ligt ook als voorstel bij de OMG. RUP is goed te combineren met andere methoden,

vooral omdat RUP voorziet in een stevig gefundeerde methode voor het onderhoud van architectuurproducten. RUP dient (nog steeds) als voorbeeld voor ondermeer TOGAF. Vanwege de wereldwijde acceptatie van RUP als ontwikkelstandaard en van UML als de taal van die standaard, zijn er een uitgebreide gereedschapskist en veel hulpmiddelen beschikbaar. Ook het aantal belanghebbenden dat vertrouwd is met delen van RUP en UML groeit globaal nog steeds. Organisaties die de enigszins kostbare moeite willen nemen om RUP geschikt te maken voor de toepassing van enterprise-architectuur, zullen door alle mogelijkheden die RUP in zich heeft niet teleurgesteld worden.

Wegwijzer voor methoden bij enterprise-architectuur - 2de herziene druk

Please wait...

X
Added to your cart