De systeemontwikkelmethode RUP lijkt terrein te winnen op Dsdm. RUP lijkt ‘gebruiksklaar’ doordat het concrete producten biedt voor het uitvoeren van ontwikkelprojecten, terwijl nieuwkomers Dsdm ervaren als een ‘lege huls’. Het is jammer als Dsdm achterblijft in deze methodestrijd, omdat het meer dan RUP gericht is op het tijdig leveren van een juist systeem dat nauw aansluit op de eisen en wensen van de organisatie. Praat Dsdm veelvuldig over gebruikers en hun inbreng, bij RUP is het even zoeken daarnaar. Het ontbreken van een concrete invulling hoeft geen belemmering te zijn, en ook bij RUP is vaak aanpassing aan organisatiespecifieke zaken nodig.
De inslag van Dsdm (Dynamic Systems Development Method) is dat systeemontwikkelprojecten vaak falen door gebrekkige samenwerking tussen de bedrijfsactiviteiten en de it-organisatie. De nadruk ligt dan ook op het in projecten effectief samenwerken van gebruikers en ontwikkelaars om de bedrijfsdoelen te verwezenlijken. De methode is tool- en techniekonafhankelijk, waardoor ze toepasbaar is in elke technische omgeving, en leverancieronafhankelijk, waardoor gebruikers niet gebonden zijn aan één aanbieder.
RUP (Rational Unified Process) richt zich op het software-ontwikkelproces. Het bevat een gedisciplineerde benadering om taken en verantwoordelijkheden toe te wijzen in een ontwikkelorganisatie. De gedachte achter RUP is dat projecten succesvoller zijn als het team als eenheid opereert en het project de onderkende best practices toepast. Het raamwerk van RUP is toegeschreven naar de eigen invulling van software-engineering, gebaseerd op UML (Unified Modelling Language) en objectoriëntatie. Hierdoor past deze methode het best bij omgevingen waarin UML en objectoriëntatie worden toegepast. De methode bevat een nauwe integratie met tools van IBM Rational, waarvoor ’toolmentors’ zijn opgenomen.
Diepgaand
RUP biedt een aantal zaken die Dsdm niet heeft. Het kent een diepgaande beschrijving van disciplines als vereisten (requirements) en bedrijfsmodellering (business modeling). Per discipline worden een aantal concepten en het proces uitgelegd, en richtlijnen gegeven voor het opstellen van producten. Verder zijn voor elke discipline sjablonen opgenomen. In totaal zijn ongeveer veertig sjablonen beschikbaar. Ook is er aandacht voor de diepgang van activiteiten. Naast een opsomming van de activiteiten wordt uitgebreid beschreven hoe elke activiteit moet worden uitgevoerd.
Bovendien zijn er toolmentors. Aangezien IBM Rational de methode levert, is het gebruik van diens tools erin opgenomen. Van in totaal zeventien van die tools wordt uitgelegd hoe je verschillende activiteiten kunt uitvoeren met behulp van een tool. Hierdoor is direct een koppeling gelegd tussen de uit te voeren activiteiten (welke) en hoe je die moet uitvoeren met behulp van een tool (wat). Daarnaast zijn er werkrichtlijnen; beschrijvingen van technieken die het uitvoeren van bepaalde taken in het ontwikkelproces ondersteunen. Deze technieken variëren van het uitvoeren van een gebruisscenario-workshop tot richtlijnen voor beoordelingen. Ook worden voor een aantal artefacten ingevulde voorbeelden gegeven. Tot slot is er de proces engineer toolkit, waarmee je per project een aangepast ontwikkelproces gebaseerd op RUP kunt maken en beschikbaar kunt stellen als website.
Dit alles is gebaseerd op moderne technieken als UML en objectoriëntatie. RUP is dus vooral ‘klaar voor gebruik’ in omgevingen waarbij al ervaring is opgedaan met moderne modelleringtechnieken en tools.
Overdonderen
De omvangrijke invulling van RUP levert op het eerste gezicht een voorsprong op bij het gebruik van de methode. Toch zal een organisatie ook bij het gebruik van RUP vaak een eigen concrete invulling moeten realiseren. Daar zijn diverse redenen voor. Enkele daarvan betreffen de gebruikte tools, de sjablonen en bestaande documentatie, het ontwikkelplatform, de variëteit in het ontwikkelproces en het implementatiegemak.
Veel organisaties hebben al gekozen voor bepaalde tools voor het ontwikkelproces. Ze hebben vaak al geïnvesteerd in licenties en de opleidingen daarvoor. Het invoeren van een set nieuwe tools met de bijbehorende licenties en opleidingen is dan geen optie. De bestaande tools zullen geïntegreerd moeten worden in de gekozen methode.
Binnen organisaties zijn door de jaren heen sjablonen ontstaan voor belangrijke producten, zoals projectplannen en ontwerpdocumenten. De documentatie van systemen is vaak gebaseerd op deze sjablonen. Bij kleine organisaties hoeft een rigoureuze overgang op nieuwe sjablonen geen probleem op te leveren. Bij grote organisaties zal dit minder eenvoudig gaan. Hier zal vaak een aanpassing van bestaande sjablonen aan de nieuwe methode een betere oplossing zijn.
Binnen grotere organisaties is vaak een veelheid aan ontwikkelplatformen beschikbaar. Naast moderne platformen, waarvoor de concrete invulling van RUP bedoeld is, worden vaak ook andere ontwikkelplatformen gebruikt. Indien de gekozen methode tevens in deze (legacy) omgevingen moet worden toegepast, moet je hiervoor ook een concrete invulling realiseren.
Bij grote ontwikkelorganisaties, die een ruime variëteit aan ontwikkelprojecten hebben, zal het ontwikkelproces zeer divers zijn (van kleine aanpassingen op systemen tot grootschalige maatwerkprojecten). Voor elk van de onderkende hoofdsoorten ontwikkelprocessen is een diepgaande beschrijving van de activiteiten en op te leveren documenten gewenst. Hoewel RUP ondersteuning biedt voor het aanpassen van het standaard ontwikkelproces, is hiervoor net als bij Dsdm een expert nodig.
De hoeveelheid materiaal die RUP biedt kan de toekomstige gebruikers daarvan overdonderen. Bij de invoering zal je daarom vaak een invoeringspad moeten kiezen waarbij je geleidelijk onderdelen introduceert.
Niet ingewikkeld
De volgende casus beschrijft hoe een concrete invulling van het beheer van de vereisten gerealiseerd is in een Dsdm-project. Een organisatie heeft gekozen voor Dsdm omdat ze in een aantal projecten hiermee positieve ervaringen heeft opgedaan. In het project wordt gebruik gemaakt van moderne technieken (UML en objectoriëntatie) en tools (Microsoft .Net en IBM Rational Rose en Requisite Pro). In Dsdm ontbreken enkele zaken die nodig zijn voor een goede invulling van het management van de vereisten: de technieken voor het inventariseren en beheren van de eisen en wensen; sjablonen voor documentatie van eisen en wensen; een beschrijving van de activiteiten en de volgorde waarin die moeten worden uitgevoerd (proces); en een handleiding over hoe de tools inzetbaar zijn bij het uitvoeren van bepaalde activiteiten in het ontwikkelproces (toolmentors).
Die zaken zijn in het project ingevuld. Voor de technieken zijn onderdelen van de requirements-discipline van RUP gebruikt, waaronder het vastleggen van functionele eisen en wensen in gebruiksscenario’s en het vastleggen van niet functionele eisen en wensen op basis van ‘urps’.
Requisite Pro biedt een sjabloon voor zowel het vastleggen van beschrijvingen van gebruiksscenario’s (use-case document) als niet functionele eisen en wensen (supplementary specifications). Naast deze documenten is ook het Dsdm-product bad (business area definition) opgeleverd, van waaruit wordt verwezen naar de documenten. Het sjabloon voor de bad is bedacht op basis van de doelen die benoemd zijn in het Dsdm-handboek.
Uit de white paper van Dsdm met betrekking tot UML (Unified Modelling Language) was een eenvoudige werkwijze te destilleren. Dit proces is vastgelegd in een document, waarin per Dsdm-fase een aantal stappen is beschreven. Bij sommige stappen wordt verwezen naar zelf ontwikkelde toolmentors.
Voor een aantal taken in het proces zijn toolmentors ontwikkeld. Basis hiervoor vormen de toolmentors van RUP. Deze waren niet één op één toepasbaar vanwege voor Dsdm specifieke zaken als moscow-prioriteitstelling (must, should, could en won’t have).
Bovenstaande invulling kostte in totaal drie mandagen. Het realiseren van de concrete invulling van vereistenbeheer hoeft dus niet ingewikkeld en duur te zijn. De werkwijze is eenmalig beschreven en in de toekomst voor alle gelijksoortige projecten toepasbaar.
Keuze
RUP biedt een concretere invulling van het ontwikkelproces dan Dsdm. Bij RUP is dit gebaseerd op moderne technieken (UML, objectoriëntatie) en tools (IBM Rational Requisite Pro, Rose), waardoor deze methode toepasbaar is in ‘moderne’ ontwikkelomgevingen. In veel gevallen zal de organisatie voor RUP, net als voor Dsdm, een eigen invulling moeten realiseren. Dat vereist een relatief lage investering. Het voorhanden zijn van een concrete invulling is dus niet altijd een geldig argument voor RUP; deze goedgevulde methode is niet altijd beter dan het relatief lege raamwerk van Dsdm.
RUP is alleen beter als: de organisatie integraal wil overstappen naar een nieuwe en moderne werkwijze, compleet met concrete voorschriften voor modelleringtechnieken en de te doorlopen activiteiten, met voorbeelden en sjablonen; al objectgeoriënteerde technologie in gebruik heeft of dat op niet al te lange termijn wil gaan doen; en al gebruik maakt van IBM Rational tools of deze wil gaan inzetten.
Indien deze argumenten niet opgaan, moet de organisatie bij de keuze voor een methode kijken naar andere argumenten (zie Eric Bunk en Gemma Kuijpers: ‘Mens gaat boven methode’, Computable, 28 november 2003). Het belangrijkste argument bij de keuze tussen RUP of Dsdm is het antwoord op de vraag ‘welk probleem wil een organisatie oplossen met behulp van een methode’. Luidt het antwoord ‘de oplevering van systemen loopt vaak uit en gebruikers zijn vaak ontevreden over de geleverde systemen’, kies dan voor Dsdm. Luidt het antwoord ‘de ontwikkelaars doen maar wat, ze leveren vaak verschillende producten op en weten niet goed hoe ze tot een werkend systeem moeten komen’, kies dan voor RUP.< BR>
| Mischa van den Brand, managing consultant Capgemini |
 |
