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.
|
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:
|
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
MI is de auteur niet alleen Eric Bunk, maar heb ik dat samen met hem geschreven.