4.2 Projectmanagementmethoden
De te onderscheiden fasen bij de ontwikkeling van een kennisgebaseerd systeem zijn vergelijkbaar met de fasen in het ontwikkeltraject van andere informatiesystemen.
Ook de verschillende manieren om deze fasen te doorlopen, komen voor een groot deel overeen met de methoden die in de informatietechnologie worden gebruikt. Door de jaren heen zijn verschillende methoden ontwikkeld om een ontwikkeltraject te doorlopen. Iedere methode heeft haar voor- en nadelen, die per traject tegen elkaar moeten worden afgewogen. Afhankelijk van de wensen en eisen die er worden gesteld, verdienen verschillende methoden in verschillende situaties de voorkeur. Hoewel trajecten in de kennistechnologie in bepaalde opzichten van conventionele systeemontwikkeling verschillen, vormen bestaande projectmanagementmethoden in dit hoofdstuk het uitgangspunt. Stefik behandelt aanvullend een aantal aspecten die met name in kennistechnologietrajecten een rol spelen en die de ene methode geschikter maken dan de ander.
4.2.1 Product- en proces gerichte ontwikkeling
Lees uit Stefik paragraaf 3.3.3 vanaf Process versus product (paginas 351 tot en met 358).
Stefik gaat in op het verschil tussen een productgerichte en een procesgerichte ontwikkeling. In het vervolg van deze paragraaf volgen enkele concrete invullingen om de verschillende fasen te doorlopen. In de terminologie van Stefik is de lineaire benadering een productgerichte benadering en zijn alle alternatieve benaderingen in meer of mindere mate procesgericht. Afhankelijk van de situatie en de aard van het domein, het systeem of project wordt het te volgen het proces bepaald. Stefik noemt aspecten als terugkoppelingsmogelijkheden van gebruikers en het in kaart brengen van de ideeën en verwachtingen van de klant als aandachtspunten bij het maken van een keuze. Zo is het in de ene situatie alleen belangrijk om snel een zichtbaar resultaat te hebben, en in de andere ook van belang een bruikbaar resultaat te hebben. Hierna worden een aantal mogelijke inrichtingen van het proces, hun toepasbaarheid en hun voor- en nadelen toegelicht.
De lineaire benadering is een traditionele en enigszins ouderwetse projectmanagementmethode. Bij deze methode worden de verschillende fasen, zoals besproken in paragraaf 4.1, sequentieel doorlopen. Na iedere fase wordt een mijlpaalproduct opgeleverd dat de basis is voor de volgende fase, zie figuur 4.2.1.
Figuur 4.2.1 De lineaire benadering
Een fase wordt telkens in haar geheel afgerond. Het voordeel van deze methode is, dat de te volgen stappen duidelijk zijn en dat elke fase iets concreets oplevert (meestal een document). De keerzijde van deze aanpak is echter, dat er geen mogelijkheid is een voorgaand mijlpaalproduct te herzien. Wanneer in een later stadium blijkt dat er verkeerde keuzes zijn gemaakt, is het moeilijk om hierop terug te komen en fouten te herstellen.
Dit maakt een paradigm shift, een veranderende visie op of benadering van het probleem, tot een van de grootste risicos. Een paradigm shift kan optreden tijdens het ontwikkeltraject wanneer de kennistechnoloog ontdekt dat de gekozen kennisrepresentatiestructuur, de gekozen tools of andere ontwerpkeuzes niet geschikt zijn. Dit is meestal te wijten aan een onderschatting van de complexiteit van het probleem in de beginfase van de ontwikkeling. Het kan tot serieuze problemen leiden wanneer een paradigm shift in een vergevorderd stadium van het ontwikkeltraject optreedt. De kennistechnoloog wordt dan geconfronteerd met het dilemma: doorgaan met een inadequate infrastructuur, waardoor later nog meer problemen zouden kunnen optreden, of opnieuw beginnen met een nieuwe infrastructuur. Beide keuzes kunnen leiden tot drastische vertragingen van het project.
Het gebruik van de lineaire benadering betekent ook dat de gebruiker pas aan het einde van het traject, als het gehele systeem compleet is, een mening over het systeem kan geven. Eventuele terugkoppeling van de gebruiker is dan niet gemakkelijk meer te verwerken. Zeker in een kennistechnologietraject waar complexe redeneerprocessen en kennis gemodelleerd moeten worden, kan dit een groot nadeel blijken. De lineaire benadering is alleen dan geschikt, wanneer de eisen aan het systeem vanaf het begin helder zijn en wanneer van tevoren met grote zekerheid is vast te stellen of bepaalde keuzes (bijvoorbeeld de representatiewijzen) goede keuzes zullen blijken. Omdat in een kennistechnologietraject deze keuzes nogal complex zijn en de ontwikkeling van een kennissysteem zelf ook van invloed kan zijn op het te modelleren domein, is deze methode eigenlijk niet geschikt voor een kennistechnologietraject.
Een bekende variant op de strikt lineaire aanpak is de watervalmethode, zie figuur 4.2.2.
Figuur 4.2.2 De watervalmethode
De watervalmethode is een lineaire benadering, waarbij wel terugkoppeling plaatsvindt naar de voorgaande fase. De watervalmethode komt enigszins tegemoet aan de nadelen van de lineaire benadering. De methode blijft echter gericht op de oplevering van producten (documenten) na iedere fase, zodat pas aan het einde van het project een fucntionerend systeem resulteert.
4.2.3 Prototyperende ontwikkeling
Om problemen zoals de paradigm shift in een vroeg stadium te onderkennen en verdere problemen en vertraging te vermijden, worden er steeds vaker methoden gebruikt waarin het mogelijk is om op gemaakte keuzes terug te komen, zoals de prototyperende benadering, ook wel rapid prototyping genoemd.
Bij de prototyperende benadering wordt van het systeem eerst een gedeeltelijk functionerend prototype opgeleverd. Welke functionaliteit het prototype heeft, varieert. Het kan gaan om de gebruikers-interface alleen, maar ook om nieuwe redeneer-technieken die moeten worden uitgeprobeerd om daarna het gehele systeem beter te kunnen ontwerpen. Zeker binnen de kennistechnologie blijkt het maken van één of meer prototypen vaak een nuttige keuze. De te modelleren kennis is immers niet altijd in één oogopslag duidelijk en kan zelfs gedurende het project veranderen. Ook heeft de gebruiker vaak nog minder dan bij conventionele systemen een idee van welke mogelijkheden een te ontwikkelen systeem biedt. Op basis van het prototype kunnen de eisen aan het systeem worden bijgesteld. Het ontwikkelde prototype kan als uitgangspunt dienen voor de rest van het ontwikkeltraject, maar het kan ook worden weggegooid, als blijkt dat de ontwikkeling van het systeem anders aangepakt moet worden.
Door middel van prototyping kunnen vragen als: "Is wat we willen mogelijk" en "Hoe kunnen we het probleem het beste aanpakken" bijtijds beantwoord worden.
Het grote voordeel van deze benadering is de mogelijkheid om op verschillende keuzes in een vroeg stadium terug te koppelen. Bovendien is het een methode die snel een zichtbaar resultaat oplevert. De methode is daarom met name geschikt wanneer er onzekerheid bestaat over de te maken keuzes en de mogelijkheid tot terugkoppeling en aanpassing van het model of systeem in een vroeg stadium gewenst is. Ook wanneer er twijfel bestaat over het nut of de haalbaarheid van het traject, kan de toepassing van deze methode op korte termijn duidelijkheid verschaffen. Het nadeel van deze aanpak is echter dat het ontwikkelde prototype verkeerde verwachtingen kan wekken. Zo kan een overtuigend prototype de indruk wekken dat er nog maar weinig extra tijd nodig is om tot een eindproduct te komen. Dit kan leiden tot uitspraken als "Wanneer kunnen we productie draaien met dit prototype?"
De prototyperende aanpak is vooral geschikt wanneer er weinig zekerheid bestaat over te maken keuzes en er behoefte is om op korte termijn op gemaakte keuzes terug te kunnen komen. Ook wanneer men op korte termijn behoefte heeft aan een zichtbaar resultaat of voorbeeld van het systeem, is deze methode heel geschikt. Doordat het steeds makkelijker wordt om met behulp van tools snel een werkend systeem te maken, blijkt de prototyperende benadering steeds vaker een te verkiezen alternatief boven een lineaire aanpak.
4.2.4 Incrementele ontwikkeling
Bij een incrementele aanpak wordt de uiteindelijke functionaliteit van het systeem in afzonderlijke stappen ontwikkeld. Hierbij wordt het traject van de lineaire benadering verschillende malen doorlopen, zie figuur 4.2.3.
Figuur 4.2.3 Incrementele ontwikkeling
Bij de incrementele benadering wordt er allereerst een systeem met een gedeelte van de uiteindelijke functionaliteit ontwikkeld. Elke keer wanneer het traject opnieuw doorlopen wordt, wordt er nieuwe functionaliteit toegevoegd. Het systeem wordt in gedeelten opgeleverd. Elk increment levert een bruikbaar resultaat op en kosten kunnen per toe te voegen functionaliteit opnieuw worden bekeken. Deze methode is daarom bij een budgetgestuurd ontwikkeltraject heel geschikt. Het kunnen tonen van gedeeltelijke functionaliteit draagt bij aan het opbouwen van vertrouwen bij de opdrachtgever. Verder draagt deze aanpak bij tot een gefaseerde invoering van het systeem; gebruikers kunnen geleidelijk wennen aan het systeem en eventueel terugkoppeling geven.
4.2.4 Iteratieve ontwikkeling
Waar bij incrementele ontwikkeling steeds het gehele traject wordt doorlopen alvorens er nieuwe functionaliteit wordt toegevoegd, kan bij iteratieve ontwikkeling ook over en binnen een traject geïtereerd worden. Elke fase kan aanleiding geven om terug te gaan naar een willekeurige voorgaande fase om gemaakte keuzes ter herzien of aan te vullen, zie figuur 4.2.4.
Figuur 4.2.4 Iteratieve ontwikkeling
Iteratieve ontwikkeling is vooral geschikt als een gewenste (deel)functionaliteit nog niet helemaal duidelijk is. Op basis van een keuze kan worden uitgeprobeerd of het de juiste is. Een gevaar van deze benadering is, dat er steeds maar weer keuzes worden herzien en aanpassingen worden gemaakt, zonder dat dit leidt tot een tastbaar of beter resultaat.
4.2.5 Risicogestuurde ontwikkeling
Niet zozeer een aparte methode, maar meer een leidraad bij het kiezen van de juiste aanpak, is de risico gedreven ontwikkeling. Hierbij wordt allereerst vastgesteld welke risicos die de ontwikkeling bemoeilijken, er aan het traject verbonden zijn, hoe waarschijnlijk het is dat deze situaties zich voordoen en hoeveel invloed ze dan hebben op het project. Aan de hand hiervan kunnen passende maatregelen worden genomen om de risicos te beperken. Wanneer gebruikersacceptatie bijvoorbeeld een grote rol speelt, is het belangrijk om te zorgen dat er voldoende mogelijkheden zijn om terugkoppeling van gebruikers te verwerken, terwijl voor betrokkenheid van het management een snel en zichtbaar resultaat van belang kan zijn.