Projecten hebben baat bij combinatie van RUP en Dsdm

In 1999 verscheen een white paper over de interoperabiliteit van Dsdm met RUP. Dit kwam voort uit de behoefte binnen de Dsdm-gemeenschap aan een leidraad voor het integreren van onderdelen van RUP met Dsdm. We komen de combinatie nog steeds niet vaak tegen, terwijl veel projecten baat kunnen hebben bij het gebruik van de competenties en technieken uit beide methoden. Wat kan de toegevoegde waarde zijn van het combineren van Dsdm en RUP? Hoe is deze combinatie op praktische wijze vorm te geven?

RUP (Rational Unified Process) en Dsdm (Dynamic Systems Development Methodology) hanteren in hun aanpak voor softwareontwikkeling veel gemeenschappelijke elementen, waaronder iteratieve ontwikkeling, ontwikkeling van software die tegemoetkomt aan de behoeften van de gebruikers, continu testen en prioriteitstelling van de vereisten. Toch zijn de denkwerelden achter de methoden behoorlijk verschillend. Dsdm biedt een sterk mensgerichte invulling, terwijl RUP meer een instrumentele benadering heeft.

Aanvullen

De gedachte achter Dsdm is dat projecten meer toegevoegde waarde voor de opdrachtgever leveren als de projectleden onderling beter samenwerken en de prioriteiten gebaseerd zijn op bedrijfsmatige overwegingen. Daarom houdt deze methode het ontwerp- en bouwproces zichtbaar voor de opdrachtgever en de gebruikers. Het helpt daarmee het project te richten op het wat en wanneer.
De gedachte achter RUP is dat projecten succesvoller zijn als het team als een eenheid opereert en het project de onderkende best practices toepast. Architecturale risico’s worden in deze methode zo vroeg mogelijk opgelost, zodat de hiermee gepaard gaande gevaren beheersbaar blijven. RUP helpt daarmee een haalbare, stabiele en toekomstvaste architectuur te creëren.

RUP-factoren – De ontwikkelaars hebben veel vakinhoudelijke ondersteuning nodig in de vorm van concrete voorschriften voor modelleringtechnieken en de te doorlopen activiteiten, met voorbeelden en templates. De huidige engineering-aanpak(ken) voldoen niet. De organisatie heeft behoefte aan een formele aanpak voor complexe it-projecten. De organisatie wil een standaard aanpak in de vorm van concrete voorschriften voor modelleringtechnieken en de te doorlopen activiteiten, met voorbeelden en templates. De organisatie zoekt voor een specifieke engineeringdiscipline (bijvoorbeeld beheer van vereisten) houvast in de vorm van concrete gedetailleerde voorschriften voor de te doorlopen activiteiten, ondersteund door voorbeelden en templates. De organisatie heeft al objectgeoriënteerde technologie in gebruik of wil dat op niet al te lange termijn gaan doen. De ontwikkelorganisatie is onvolwassen. De organisatie gebruikt Rational-tools of wil deze gaan inzetten. Ondersteuning voor specifieke ontwikkelomgevingen is gewenst (bijvoorbeeld Java, XML, Websphere, C#, .Net, Java Portal, BEA). De methode moet wereldwijd bekend zijn.

Het raamwerk van RUP is toegeschreven naar de eigen invulling van software-engineering, gebaseerd op UML (Unified Modelling Language) en objectoriëntatie, terwijl het raamwerk van Dsdm onafhankelijk is van de gebruikte vorm van software-engineering. RUP past daardoor het best bij omgevingen waarin UML en objectoriëntatie worden toegepast, terwijl Dsdm makkelijker bij verschillende soorten ontwikkelomgevingen te gebruiken valt.
Een Dsdm-gebruiker kan in RUP gedetailleerde begeleiding vinden voor diverse aspecten van systeemontwikkeling in de vorm van ’templates’, voorbeelden en adviezen voor de stappen die je kunt doorlopen om een bepaald resultaat te bereiken.
RUP-gebruikers kunnen hun voordeel doen met de technieken en het gedachtegoed van Dsdm. De technieken kunnen helpen het ontwikkelproces effectiever te laten verlopen, terwijl het gedachtegoed kan helpen om het project beter toegespitst te houden op de bedrijfsactiviteiten.
De belangrijkste onderdelen van beide methoden zijn weergegeven in de figuur. Op onderdelen die slechts in één van beide bollen vallen, vullen de methoden elkaar aan. Ook voor de onderwerpen die ze gemeenschappelijk hebben (die in beide bollen vallen) vullen ze elkaar aan doordat elke methode eigen accenten legt. Inzake de fasering, rollen en producten (waarmee zowel Dsdm-‘products’ als RUP-‘artifacts’ bedoeld worden) is het verstandig de terminologie van één van beide te hanteren, anders ontstaat verwarring.

Verwarring

Volgens het white paper uit 1999 is het een probleem dat projectmanagers eerst goed onderlegd moeten zijn in de methoden voordat ze hun project kunnen starten. De pda (process design assistant) kan op dit punt helpen door op basis van vragen over de karakteristieken van het project een aantal technieken aan te bevelen. Als het project bijvoorbeeld een vaste deadline heeft, worden moscow (must have, should have, could have, want to have, but won’t have this time) en ’timeboxing’ aanbevolen.
Ook zonder deze pda is het mogelijk om ‘krenten’ uit de andere methode te selecteren en toe te voegen aan de eigen aanpak. Kies dan eerst een basismethode. Kies vervolgens uit de andere methode onderdelen die essentieel zijn, maar die in de basismethode ontbreken of onvoldoende ingevuld zijn. Het door elkaar gebruiken van begrippen uit twee verschillende methoden kan aanleiding geven tot verwarring. Dit is te voorkomen door een basismethode te kiezen, zodat er één gemeenschappelijke taal is voor de fases, producten en rollen. Daaraan kan je later eventueel onderdelen van de andere methode toevoegen.
Kies de basismethode aan de hand van de in de gegeven situatie belangrijkste factoren (zie kader). Een voorbeeld van een dergelijke discriminerende factor is dat de methode moet aansluiten op UML.

Niet tevreden

Dsdm-factoren Vóór Dsdm pleiten de volgende factoren: De ontwikkelaars verstaan hun vak goed, zijn vertrouwd met de huidige ontwikkelomgeving(en), hebben weinig additionele vakinhoudelijke ondersteuning nodig en zijn in staat producten op te leveren die vanuit it-perspectief goed in elkaar zitten. De gebruikersorganisatie is echter niet tevreden over de opgeleverde producten (te laat, onnodige toeters en bellen, sluit niet goed aan op de werkwijze enzovoort). Projectterminologie over meerdere technologische omgevingen (ontwikkelstraten) willen standaardiseren, terwijl de huidige engineering-aanpakken voldoen. Een overzichtelijke, niet complexe methode zoeken. Draagvlak bij de toekomstige gebruikers voor de gekozen oplossing is cruciaal. De samenwerking tussen de bedrijfsactiviteiten en it moet verbeterd worden. Er zijn tools in gebruik van andere leveranciers dan Rational. Beter willen opleveren wat het bedrijf nodig heeft (de juiste dingen doen). Oplossingen willen opleveren die beter werkbaar zijn voor het bedrijf en die beter aansluiten op het werk van de gebruikers.

Neem een organisatie waar de ontwikkelaars hun vak goed verstaan, vertrouwd zijn met de huidige ontwikkelomgeving(en), weinig additionele vakinhoudelijke ondersteuning nodig hebben en producten kunnen opleveren die vanuit it-perspectief goed in elkaar zitten. De gebruikersorganisatie is echter niet tevreden over de opgeleverde producten. In dat geval zou Dsdm de logische keuze zijn om de projecten meer op de bedrijfsactiviteiten georiënteerd te maken. Een bijkomend voordeel van die keuze is de lage kostprijs van de methode.
Als de ontwikkelaars juist veel vakinhoudelijke ondersteuning nodig hebben, zou RUP de logische keuze zijn om ondersteuning te bieden in de vorm van concrete voorschriften voor modelleringtechnieken en de te doorlopen activiteiten, met voorbeelden en templates.
Aan de hand van dezelfde factoren waarmee de basismethode is gekozen, kan deze worden aangevuld met onderdelen vanuit de andere methode. Daarnaast kunnen er andere overwegingen zijn die aanleiding geven tot toevoegingen.

Gezond verstand

Een organisatie die voor RUP gekozen heeft, kan ook behoefte hebben om beter op te leveren wat het bedrijf nodig heeft. Dit is bijvoorbeeld te realiseren door de Dsdm-rollen ‘Visionary’ en ‘Ambassador User’ op te nemen in de aanpak, en door het principe te hanteren dat alle prioriteiten worden bepaald op grond van bedrijfsmatige overwegingen. Het omgekeerde is ook mogelijk; een organisatie die voor Dsdm heeft gekozen, heeft behoefte aan concrete voorschriften voor bedrijfsmodellering, compleet met voorbeelden en templates. Dit valt te realiseren door de RUP-discipline ‘Business Modeling’ toe te voegen.
Tot nu toe hebben we steeds gesproken over het vormgeven van de combinatie Dsdm en RUP voor een organisatie. Het vraagstuk speelt ook voor individuele projecten, zelfs als op organisatieniveau al voor één methode is gekozen. Wanneer bijvoorbeeld een RUP-project wordt geconfronteerd met een harde deadline, zijn de moscow- en ‘Timeboxing’-technieken uit Dsdm bruikbaar om maximale toegevoegde waarde te leveren op de einddatum.
Het combineren van twee methoden is geen exacte wetenschap. Het komt neer op een aantal vuistregels hanteren en gezond verstand gebruiken. Daarnaast is de methode niet meer en niet minder dan een hulpmiddel om de mensen die het werk moeten doen te ondersteunen. De kwaliteit van de mensen is belangrijker dan de kwaliteit van de methode. Goede mensen met een goede methode presteren wel beter dan goede mensen zonder methode.< BR>
 
Eric Bunk, it process consulting Cgey