Hoofdstuk 4 Projectplanning en softwareprojecten

Transcriptie

1 Hoofdstuk 4 Projectplanning en softwareprojecten 4.1 Inleiding In het vorige hoofdstuk is beschreven dat een generieke DSS is gericht op een klasse van problemen. De methoden die bij het oplossen van die klasse van problemen worden gebruikt, worden hiertoe in de vorm van een conceptueel model in het generieke DSS ondergebracht. Het gebruik van een dergelijk generieke DSS kan worden ondersteund met behulp van een kennissysteem. Deze ondersteuning is mogelijk doordat het generieke DSS is gericht op een probleem dat zich herhaalde malen voordoet. In hoofdstuk 5 zal worden aangegeven hoe een dergelijk systeem voor de projectplanning kan worden opgezet. Een generieke DSS bevat methoden die bij het oplossen van problemen uit een vooraf gedefinieerde klasse van problemen worden gebruikt. Een generieke DSS voor de projectplanning dient dan ook planningmethoden te bevatten. In dit hoofdstuk zal worden beschreven welke methoden bij de projectplanning een rol spelen. Ondanks de beschikbaarheid van een groot aantal methoden, worden veel van deze methoden niet gebruikt. Voor een groot deel kan dit worden verklaard uit het feit dat de benodigde kennis bij de projectplanners ontbreekt. Dit gebrek aan kennis kan worden ondervangen door het gebruik van een kennissysteem. Een kennissysteem dat aansluit op het generieke DSS kan kennis aanleveren voor de keuze en het gebruik van de planningmethoden. Het gebruik van de methode wordt ondersteund door het ter beschikking stellen van inhoudelijke kennis in de vorm van vuistregels, normen en ratio s 54. Projectplanning maakt deel uit van een hiërarchie van planningen. Deze hiërarchie van planningen vloeit voort uit de werkverdeling in het secundaire proces (zie Hoofdstuk 1). Op basis van de strategische planning dient het topmanagement aan te geven welke rol zij ziet voor de informatievoorziening binnen de organisatie. 54 Zie hoofdstuk 5 voor een beschrijving van het functioneel ontwerp van een beslissingsondersteunend kennissysteem.

2 92 Hoofdstuk 4 Uit deze strategische visie kan een informatiebeleid worden gedistilleerd dat de leidraad vormt voor de informatieplanning welke onder andere resulteert in een beschrijving van de gewenste informatievoorziening binnen de organisatie. Binnen ontwikkelingsprojecten worden delen van deze gewenste informatievoorziening gerealiseerd in de vorm van concrete informatiesystemen. Deze verschillende stappen zullen in de paragrafen 4.2 en 4.3 worden besproken. Voor de projectplanning zijn een aantal planningmethoden beschikbaar. Deze methoden dienen een centrale plaats in te nemen in een generieke DSS voor projectplanning. In paragraaf 4.6 worden de planningmethoden beschreven die in meer of mindere mate in de praktijk worden gebruikt. De veel gebruikte netwerkplanningmethoden zullen hierbij een belangrijke plaats innemen. Tevens wordt aandacht besteed aan varianten van de netwerkplanningmethoden zoals PERT. Vervolgens wordt aandacht besteed aan methoden die specifiek voor de projectplanning van softwareprojecten worden gebruikt. Dit zijn de begrotingsmodellen zoals COCOMO en FPA. De methoden van planning zijn met name gericht op één fase van het beslissingsproces en zijn derhalve, gezien de in paragraaf 1.6 gegeven definitie van planning, geen methoden van planning maar van beslissen. Dit hoofdstuk sluit echter aan bij het in de literatuur gebruikelijke gebruik van de term planningmethode. Planningmethoden vatten wij op als methoden die bij de projectplanning kunnen worden gebruikt (zie paragraaf 1.6). Evenals bij het begrip beslissen, bestaan er ten aanzien van het begrip planning verschillende opvattingen. Mietus (1994) en van Wezel et al. (1996) hanteren een definitie van planning als determining the sequence of actions over time. De planningactiviteit splitsen zij op in een aantal deelactiviteiten. Deze deelactiviteiten zijn administration, problem solving en evaluation. Deze opsplitsing biedt richtlijnen bij de aard van de ondersteuning die wenselijk is voor een bepaalde deelactiviteit. Het administreren bestaat bijvoorbeeld onder andere uit tellen. Een dergelijke activiteit kan van oudsher uitstekend door een computer worden uitgevoerd. Een activiteit als onderhandelen kan niet worden geautomatiseerd en kan slecht ten dele worden ondersteund met bijvoorbeeld een group decision support system. De opvatting over planning is van invloed op de manier waarop een planningproces kan worden ondersteund. Mietus stelt dat het planningproces start met een definitie van de begin- en eindsituatie. Het planningproces bestaat hiermee uit het zoeken naar een oplossing binnen deze probleemruimte. Dit legt de nadruk op de latere fasen van het beslissingsproces en is daarin te vergelijken met het zogenaamde algoritmisch rationeel handelen. 4.2 Informatiebeleid en informatieplanning Informatiesystemen hebben een steeds grotere invloed op het functioneren van organisaties. Het niet op tijd ontwikkelen van de juiste systemen kan de concurrentie een voorsprong geven (Lederer en Mendelow, 1993). Deze systemen maken deel uit van het concrete informatiesysteem. Dergelijke systemen bestaan uit hardware,

3 Projectplanning en softwareprojecten 93 software, databases en organisatorische procedures, die binnen een organisatie worden gebruikt. Tenzij anders vermeld, wordt met informatiesysteem het concrete informatiesysteem bedoeld. De complexiteit van de informatievoorziening in de organisatie vereist de ontwikkeling van een plan voor de lange termijn. Recent onderzoek heeft aangetoond dat het management de informatieplanning zeer belangrijk vindt (Brancheau en Wetherbe, 1987; Earl, 1993; Finnegan en Fahy, 1993). Informatieplanning dient dan ook een centraal element in de organisatie van de informatievoorziening te zijn. De informatieplanning resulteert in een beschrijving oftewel een afbeelding van de in de toekomst gewenste informatievoorziening. Dit model of plaatje vormt het abstracte informatiesysteem (Bosman, 1977; Boersma, 1989). Binnen de afzonderlijke ontwikkelingsprojecten wordt dit abstracte informatiesysteem gebruikt om delen van de gewenste informatievoorziening te realiseren. Het topmanagement van een organisatie zal zich moeten uitspreken over de rol van de informatievoorziening binnen een organisatie. Hierbij moeten vragen worden beantwoord als (Theeuwes, 1987): hoe zien we de rol van de informatievoorziening bij de toekomstige bedrijfsvoering? welke eisen stellen we aan de kwaliteit en efficiency van de informatievoorziening? volgens welke principes willen we de informatiesystemen en het gegevensbeheer organiseren? welke informatietechnologie is voor de komende jaren het meest geschikt? De globale antwoorden op deze vragen moeten in het informatiebeleid tot uitdrukking worden gebracht. Deze strategische visie omtrent de informatievoorziening is vervolgens het uitgangspunt voor het formuleren van een informatieplan. Dit plan geeft een uitwerking aan het informatiebeleid in de vorm van structuurschetsen van de gewenste en noodzakelijke informatievoorziening (Theeuwes, 1987). Het doel van de informatieplanning kan worden omschreven als (Lederer en Sethi, 1988): (1) the process of identifying a portfolio of computer-based applications that will assist an organization in executing its business plans and consequently realizing its business goals and/or (2) the process of searching for applications with a high impact and the ability to create an advantage over competitors. Vitale et al. (1986) noemt het eerste doel van de informatieplanning de alignment mode. De informatievoorziening is hierbij gericht op het behalen van de organisatiedoelstellingen. Het tweede doel wordt de impact mode genoemd. Informatievoorziening wordt hierbij gebruikt voor het behalen van een concurrentievoordeel.

4 94 Hoofdstuk 4 Bowman et al. (1983) beschrijven een drie-fasen-model voor het uitvoeren van de informatieplanning. 1. De eerste fase is gericht op het opstellen van doelstellingen en strategieën voor de informatiefunctie. Begin jaren tachtig werden deze afgeleid van de organisatiedoelstellingen en -strategieën (de alignment mode). Nadat de strategische waarde van informatiesystemen werd erkend, werd een wisselwerking tussen de organisatiedoelstellingen en de doelstellingen van de informatiefunctie nagestreefd (de impact mode). Deze wederzijdse afstemming wordt belangrijker naarmate de informatietechnologie belangrijker is voor het functioneren van organisaties (b.v. het bankwezen) en (daarmee) belangrijker voor het herkennen en behalen van strategische voordelen. 2. De tweede fase van de informatieplanning is gericht op het analyseren van de informatiebehoeften van de organisatie en van onderdelen van die organisatie. Deze fase resulteert ondermeer in een informatie-infrastructuur. Deze infrastructuur van de informatievoorziening (het abstracte informatiesysteem) bevat een beschrijving van de in de toekomst te realiseren concrete informatiesystemen. In de loop van de tijd zijn er diverse methoden ontwikkeld die bij de informatieplanning kunnen worden gebruikt. Voorbeelden zijn Information Engineering (Martin en Leben, 1989), Business Systems Planning (Sebus, 1981) en Critical Success Factors (Rockart, 1979) (zie Mehrez et al. (1993) voor een bespreking van deze en andere methoden). Van Dissel en Park (1989) concluderen dat de strategische informatieplanningmethoden vooral geschikt zijn voor de identificatie van een portfolio van informatiesystemen voor de ondersteuning van de operationele gang van zaken in de organisatie. Stegwee (1992) stelt dat de huidige informatieplanningmethoden met name zijn gericht op het vinden van oplossingen en niet zozeer op het genereren en evalueren van alternatieven. De methoden resulteren in een mogelijke specificatie van de toekomstige informatievoorziening. Alternatieve specificaties komen hierbij niet expliciet aan de orde. Het expliciet aandacht besteden aan alternatieven kan echter nieuwe gezichtspunten opleveren die mogelijk leiden tot een betere informatievoorziening. Het verdient dus aanbeveling aandacht te besteden aan alternatieve specificaties om vervolgens een weloverwogen keuze te maken. 3. Nadat een specificatie is gemaakt van hoe de informatievoorziening er in de toekomst uit komt te zien, moet worden besloten welke delen het eerst worden gerealiseerd. Gezien de beperkte capaciteit van zowel menskracht als (financiële) middelen is het vrijwel altijd zo dat niet alle projecten tegelijkertijd kunnen worden uitgevoerd. Naast deze middelenrestricties kunnen zich ook bepaalde logische opeenvolgingsrelaties voordoen. Een interactief verkoopsysteem is alleen zinvol indien men een real-time voorraadsysteem heeft, zodat direct gezien kan worden of produkten in voorraad zijn. Deze restricties maken het noodzakelijk dat het management prioriteiten van de verschillende projecten vaststelt. Deze prioriteitstelling vormt de derde fase van het informatieplanningsproces en is van groot belang voor de overgang van de informatieplanning naar de daadwerkelijke systeemontwikkeling. Mantz et al. (1990) tonen aan dat deze overgang in veel gevallen moeizaam verloopt. Omdat verschillende afdelingsbelangen een rol spelen zal het management de

5 Projectplanning en softwareprojecten 95 prioriteitstelling zo objectief mogelijk dienen uit te voeren. Het vaststellen van de prioriteiten moet dan ook plaatsvinden op basis van kenmerken van de te bouwen systemen en het operationele en strategische belang van deze systemen voor de organisatie. Bij de prioriteitstelling van projecten speelt een groot aantal factoren een rol, zoals de kosten en opbrengsten, het risico, de strategische aspecten en de gebruikersbehoeften (zie Figuur 4-1). Deze factoren kunnen op verschillende manieren in groepen worden ingedeeld. Een belangrijk onderscheid is dat tussen kwantitatieve en kwalitatieve factoren. De kwantitatieve factoren zijn in numerieke eenheden uit te drukken. De omvang van een systeem kan bijvoorbeeld in het aantal regels code of functiepunten worden uitgedrukt. Kwantitatieve factoren hebben in veel gevallen betrekking op geld, zoals de opbrengsten en kosten van een informatiesysteem. Kwalitatieve factoren zijn moeilijker in eenheden uit te drukken. Voordelen zoals betere besluitvorming of snellere marktinformatie zijn moeilijk te kwantificeren. Toch spelen kwalitatieve factoren een belangrijke rol in de uiteindelijke beslissing welke systemen te implementeren. Economische factoren Intern rendement Kapitaalkosten Terugverdientijd Kwantitatief Omvang Structuur Ervaring met technologie Complexiteit Organisatie Technologie Risico Kwalitatief Prioriteit informatiesysteem Politiek Gebruikersbehoeften Strategie Concurrentievoordeel Concurrentienoodzaak Ondersteuning management Figuur 4-1: Factoren die de prioriteitstelling van informatiesystemen beïnvloeden Mehrez et al. (1993) stellen dat er geen uniforme verzameling van factoren bestaat die in alle gevallen voor alle organisaties geldt. Een aantal veelvuldige gehanteerde factoren die bij de prioriteitstelling van projecten een rol spelen zijn in Figuur 4.1 afgebeeld (gebaseerd op Agarwal et al. (1992), Parker et al. (1988), Oosterhaven (1992), McFarlan (1981)). Een organisatie moet zelf beslissen welke factoren zij van belang acht. Wel zijn de gebruikte factoren afhankelijk van het type automatisering. Bij het vervangen van handmatige

6 96 Hoofdstuk 4 processen door geautomatiseerde informatiesystemen kunnen klassieke investeringsanalyses worden toegepast omdat het dan met name gaat om kostenbesparingen. Naarmate het informatiesysteem meer gericht is op het behalen van strategische doelen of managementondersteuning, spelen kwalitatieve- en risico factoren een steeds grotere rol (Van Irsel en Swinkels, 1992). Klassieke investeringsanalyses bieden weinig mogelijkheden om met deze factoren rekening te houden. In dergelijke gevallen zal dus gezocht moeten worden naar andere methoden voor de prioriteitstelling van projecten. In de loop van de tijd zijn er een groot aantal methoden ontwikkeld die bij de prioriteitstelling van projecten kunnen worden gebruikt. Voorbeelden van deze methoden zijn: kosten-baten analyse (King en Schrem, 1978; Groenendijk en de Groot, 1992), risico-analyse (McFarlan, 1981), ranking (Buss, 1983; Earl 1993), score-modellen (Melone en Wharton, 1984), zero-one programming (Santhanam et al., 1989), kennissystemen (Agarwal et al.., 1992), steering committees (McKeen en Guimares, 1985, Lederer en Mendelow, 1993) en tenslotte Analytic Hierarchy Process (Saaty, 1980; Muralidhar et al., 1990). Zie (Huizingh en Vrolijk, 1994 en Huizingh en Vrolijk, 1996) voor een beschrijving en evaluatie van de hierboven genoemde methoden. Het informatieplan bevat ondermeer een beschrijving van de toekomstige structuur van de informatievoorziening en van de benodigde informatiesystemen. In Figuur 4-2 is de samenhang tussen de beleidsuitspraken omtrent de informatievoorziening, de gespecificeerde structuur en de uit te voeren projecten weergegeven. Informatiebeleid Informatieplanning Projectplanning Informatievoorziening Figuur 4-2: Informatiebeleid en -planning

7 Projectplanning en softwareprojecten 97 In Figuur 4-2 bepaalt het informatiebeleid het informatieplan en op basis van dit plan worden de verschillende projecten gedefinieerd en bijbehorende projectplannen opgesteld. De Jong en Gazendam (1991) noemen dit de blauwdrukbenadering. Bij de door hen beschreven bestemmingsplanbenadering vindt een interactie plaats tussen het informatiebeleid en het informatieplan. Het informatieplan en -beleid worden niet voor langere tijd bevroren, maar er vindt voortdurend een terugkoppeling plaats naar het bovenliggende niveau. Het informatieplanningproces resulteert in bepaalde projecten die nu of in de toekomst in uitvoering worden genomen. Voorafgaand aan het uitvoeren van een dergelijk project wordt een projectplan opgesteld. Deze hiërarchie van planning vloeit voort uit de werkverdeling rond beslissen (zie hoofdstuk 1). 4.3 Projectplanning De informatieplanning resulteert in een beschrijving van de informatievoorziening zoals die in de toekomst moet worden gerealiseerd (het abstracte informatiesysteem). Aan de hand van deze beschrijving worden vervolgens delen van deze informatievoorziening in de vorm van informatiesystemen ontwikkeld. Het informatieplan biedt slechts globale richtlijnen voor de ontwikkeling van de afzonderlijke informatiesystemen. Deze richtlijnen dienen in de projectplanning nader te worden uitgewerkt. Het ontwikkelen van informatiesystemen vindt meestal plaats binnen een projectorganisatie. Een projectorganisatie wordt gedefinieerd als een tijdelijk samenwerkingsverband voor het verrichten van een complex van activiteiten gericht op het doen ontstaan van een van tevoren gespecificeerd produkt (Völlmar, 1989). Bemelmans (1988) noemt drie redenen waarom de ontwikkeling van informatiesystemen in een projectvorm wordt gegoten: 1. het ontwikkelen van een informatiesysteem is een interdisciplinaire aangelegenheid, waarbij verschillende disciplines (eindgebruikers, organisatiekundigen, etc.) worden betrokken, 2. het opzetten van een informatiesysteem wordt vaak beschouwd als een eenmalige, tijdelijke inspanning met een duidelijk begin- en eindpunt, 3. nieuwe informatiesystemen hebben aanzienlijke consequenties op technisch, financieel en organisatorische terrein. Een dergelijk veranderingsproces moet goed worden bestuurd. Een projectgroep wordt ingesteld 55 teneinde met een beperkte hoeveelheid middelen en binnen een afgebakende periode een duidelijk omlijnd doel te bereiken. Binnen 55 Projectmatig werken ligt voor de hand indien (Wijnen et al. 1992): 1. het gewenste resultaat weliswaar niet volstrekt nieuw is maar wel veel nieuwe elementen of aspecten omvat, 2. mensen uit verschillende disciplines of vakgebieden dat resultaat samen moeten bereiken, 3. men eenmalig een maximale prestatie moet leveren, 4. men over beperkte middelen beschikt om dat resultaat te bereiken.

8 98 Hoofdstuk 4 een projectorganisatie is, net als binnen andere organisatievormen, sprake van werkverdeling en niveauvorming. Wijnen et al. (1992) definiëren leidinggevende en uitvoerende functies binnen een projectgroep. Deze indeling komt overeen met de in hoofdstuk 1 beschreven indeling in primaire en secundaire taken en het daarbij beschreven besturingsparadigma. De projectleiding vervult de leidinggevende functies en vormt het besturende orgaan van het project. Het bestuurd systeem bestaat uit de uitvoerende c.q. de systeemontwikkelingsactiviteiten. Bij het realiseren van eenmalige complexe opdrachten is het project als organisatievorm niet nieuw (Morris and Hough, 1987). Bij de constructie van fysieke produkten zoals wegen, tunnels, gebouwen en bruggen is de projectvorm een niet weg te denken organisatievorm. Softwareprojecten zijn echter niet op alle punten volledig vergelijkbaar met fysieke constructieprojecten. Projecten die gericht zijn op de ontwikkeling van software onderscheiden zich op de volgende drie punten van fysieke projecten (Van Vliet, 1988; Heemstra, 1989; Simons, 1987): Ten eerste is software een niet-fysiek produkt. Het type eindprodukt is direct van invloed op de binnen het project uit te voeren activiteiten. Het niet concreet zijn van het eindprodukt is van invloed op de controle van de voortgang van het project. Indien het te realiseren produkt niet concreet is, moet op een indirecte wijze worden gecontroleerd hoe het met de voortgang is gesteld, bijvoorbeeld in de vorm van bepaalde op te leveren documenten en specificaties. Ten tweede is het ontwikkelproces inhoudelijk ook veel minder duidelijk. De tussenprodukten van een softwareproject bestaan slechts uit documenten en andere ontwerp- en eisenspecificaties. Hierdoor is het moeilijk de tussenliggende stappen eenduidig te definiëren. Als gevolg hiervan bestaan er diverse visies ten aanzien van de activiteiten en de volgorde van deze activiteiten die noodzakelijk zijn om softwareprodukten te produceren. Deze verschillende visies komen tot uiting in de diverse modellen van het ontwikkelproces. Een derde verschil is dat bij softwareprojecten de nadruk ligt op de eerste fasen van de ontwikkeling. Het bestuderen van de huidige situatie, het opstellen van eisen, en het definiëren van de grenzen van het systeem krijgen meer aandacht, omdat deze afhankelijk zijn van de specifieke situatie waarvoor of waarin de software wordt ontwikkeld. Hieruit volgt dat software-ontwikkelingsprojecten ook een meer eenmalig karakter vertonen. Elk afzonderlijk systeem moet op de specifieke situatie worden toegepast. Voor het construeren van bijvoorbeeld gebouwen kan meer van standaardspecificaties worden uitgegaan. Een eerste stap in deze richting binnen de software-ontwikkeling wordt gevormd door de referentieinformatiemodellen die voor enkele typen van organisaties zijn ontwikkeld. Deze modellen geven een beschrijving van de typische informatiestromen binnen een bepaald type bedrijf of binnen een specifieke functie van een groep van bedrijven Zie bijvoorbeeld het informatiemodel technische- en onderhoudsdiensten (Smit en Slaterus, 1989).

9 Projectplanning en softwareprojecten 99 De vraag kan worden gesteld of de beschreven verschillen te wijten zijn aan een essentieel onderscheid tussen softwareprojecten en fysieke projecten. De grotere duidelijkheid bij fysieke projecten omtrent de uit te voeren activiteiten en de samenhang tussen deze activiteiten, wordt voor een groot deel verklaard uit de ruime ervaring die al gedurende een lange periode is opgedaan (zie bijvoorbeeld De Jong 57 (1985)). Ook bij fysieke projecten kan de onzekerheid groot zijn indien het een nieuw type project betreft (Morris and Hough, 1987). Bij de constructie van de onderzeeboten in het zogenaamde 'Walrus-project', en bij de aanleg van de kanaaltunnel was er sprake van onzekere factoren door het ontbreken van de benodigde kennis. Hudson (1988) stelt: The treatment of a computer system as a project is very little different from the treatment of any other type of project such as building a house, a bridge or a motorcar. (..) The newness of the technology in computer projects makes the project approach both more important and more difficult; the problems are of themselves not new. Wij onderschrijven die conclusie. De cumulatie van ervaring, op basis van in het verleden uitgevoerde projecten, leidt ook in de automatiseringswereld tot een trend die is gericht op een betere beheersing van de software-ontwikkeling. Dit gaat zelfs zover dat wordt gesproken over softwarefabrieken (Cusumano, 1989; Swanson et al., 1991; Van Genuchten et al., 1993). De eerste softwarefabriek was de Hitachi Software Works (Cusumano, 1989). De doelstellingen van deze fabriek waren: 1. verbetering van de produktiviteit en betrouwbaarheid door standaardisatie van de produktieprocessen en de besturing. 2. transformatie van software van een ongestructureerde dienst tot een produkt met een gegarandeerd kwaliteitsniveau. De softwarefabriekconcepten zijn gericht op een betere beheersing van het ontwikkelproces, een efficiëntere aanpak van het ontwikkelproces, een constantere produktiviteit van de ontwikkelaars, het hergebruik van code en tenslotte fabrieksachtige procedures en organisatiestructuren. Deze verschuiving leidt er toe dat software-ontwikkeling steeds meer wordt beschouwd als een kunde dan als een kunst. Dit alles vergroot de mogelijkheden tot het opbouwen van ervaringsgegevens waarmee het verschil, voor wat betreft de planning van dergelijke projecten, verder kan worden verkleind. Zoals beschreven in hoofdstuk 1 beschouwen wij planning als een geformaliseerde vorm van beslissen. Projectplanning kan hierbij worden gedefinieerd als een subcategorie van planning. Projectplanning heeft betrekking op het specificeren van regels voor het nemen van beslissingen en het uitvoeren van 57 In het boek bouwkundig begroten wijdt de Jong een hoofdstuk aan gemiddelde bewerkingstijden voor allerlei bouwerkzaamheden (uiteenlopend van het aantal benodigde mensuren voor het slopen van een vierkante meter gewapend beton tot het aanleggen van steigers en het metselen van gevelwerk).

10 100 Hoofdstuk 4 activiteiten binnen een projectorganisatie. Badiru en Whitehouse (1989) beschrijven projectplanning als: Planning, in a project management context, refers to the process of establishing courses of action within the prevailing environment to achieve predetermined goals. Tot slot van deze paragraaf geven wij een lijst van redenen waarom een projectplan moet worden opgesteld (Badiru et Whitehouse, 1989): verminderen van onzekerheden, verhelderen van de doelstellingen van het project, het plan vormt de basis voor de evaluatie van de voortgang, het opstellen van standaards voor de activiteiten, vastleggen van de verantwoordelijkheden van het personeel. 4.4 Software engineering De nauwkeurigheid van de projectplanning zal afhankelijk zijn van het type project en de ervaring die is opgedaan met dergelijke projecten. Van veel typen projecten is een uitgebreide 'engineering'- kennis opgebouwd. Deze kennis is gebaseerd op zowel theoretische modellen als op praktische ervaringen. Engineering kan worden gedefinieerd als: 'the activities and work involved in designing and constructing machinery, engines, electrical devices, or roads and bridges.' Engineering is erop gericht produkten tot stand te brengen die aan vooraf gestelde eisen voldoen. Software engineering is nauw verwant aan andere vormen van engineering. De aard van het te ontwikkelen produkt -de software- en het ontwikkelproces om dit produkt tot stand te brengen veroorzaken enkele verschillen. In de vorige paragraaf zijn enkele redenen genoemd waarom softwareontwikkelingsprojecten ten opzichte van veel andere projecten een grotere mate van onzekerheid kennen. Galbraith (1989) definieert onzekerheid als het verschil tussen de hoeveelheid informatie die nodig is om een taak te vervullen en de hoeveelheid informatie waarover de organisatie beschikt. De onzekerheid wordt zichtbaar in het beginstadium van een project waarin het veel moeilijker is een eenduidige eisenspecificatie op te stellen. Door de onzekerheid in de eisen- en ontwerpspecificaties bestaat de mogelijkheid dat er zich iteraties in het ontwikkelproces zullen voordoen. In een later stadium kan blijken dat de in een vorige fase opgestelde eisen- en ontwerpspecificaties nader moeten worden uitgewerkt of verduidelijkt. Door de grotere onzekerheid is het moeilijker een schatting te maken van de kosten en doorlooptijd van diverse activiteiten. Gegeven de gebruikte specificatie van planning moeten de planningmethoden de mogelijkheid bieden alternatieven door te rekenen. Het gebruik van dergelijke methoden levert een beschrijving op van het probleem, waardoor meer zicht wordt verkregen op het onzekerheidsprobleem door middel van het evalueren van

11 Projectplanning en softwareprojecten 101 alternatieven. In de loop van de tijd is dan ook geprobeerd de engineering methoden en technieken uit andere vakgebieden op analoge wijze toe te passen op softwareontwikkelingsprojecten. Op deze manier kwam de software engineering tot stand. Macro (1990) definieert software engineering als: the establishment and use of sound engineering principles and good management practice, and the evolution of applicable tools and methods, and their use as appropriate in order to obtain -within known but adequate resource limitations - software that is of high quality in an explicitly defined sense. Sommerville (1991) noemt een aantal kenmerken van software engineering. Software engineering houdt zich bezig met software die wordt gebouwd door teams, maakt gebruik van engineering principes en heeft betrekking op zowel technischeals niet-technische aspecten. De essentie van software engineering is het ontwikkelen van software die aan vooraf gestelde eisen voldoet; op tijd gereed is zonder kostenoverschrijdingen en eenvoudig te onderhouden is (Simons, 1987). In deze definities wordt verwezen naar het financiële aspect van projecten. Met de ontwikkeling van informatiesystemen is veel geld gemoeid. Programma s moeten daarom op een economische manier worden ontwikkeld zonder grote kostenoverschrijdingen. Bemelmans (1987) wijst hierbij op het belang van het genereren en evalueren van alternatieven. De voor- en nadelen van elk alternatief dienen daarbij expliciet te worden gemaakt. Geld is echter niet de enige factor die moet worden beheerst binnen een project. Naast de kosten spelen ook de doorlooptijd van het project en de kwaliteit van het eindprodukt een belangrijke rol. Rosenau (1991) noemt dit de driedimensionale doelstelling van een project. Deze drie 58 kenmerken zijn niet onafhankelijk van elkaar. De kosten zijn bijvoorbeeld afhankelijk van de gewenste kwaliteit en de doorlooptijd van een project. De samenhang van deze drie kenmerken vereist een goede planning en beheersing. De kosten van een oplossing, de kwaliteit van het eindprodukt en de benodigde tijd om dit te realiseren moeten tegen elkaar worden afgewogen. De drie kenmerken kosten, kwaliteit en tijd, zullen nader worden toegelicht. Tijd en kosten komen uitgebreid aan bod in de volgende paragrafen en zullen hier slechts summier worden behandeld Tijd Projectmanagement met betrekking tot het kenmerk tijd vereist het maken van afspraken over het gebruik van produktiemiddelen, de te verwachten hoeveelheid uren die deze middelen aan het project zullen besteden en de bewaking van deze afspraken (Wijnen,1990). Het bewaken van de afspraken vereist het op regelmatige momenten in de tijd vergelijken van de voortgang met het plan. Op een dergelijk moment moet eenduidig kunnen worden vastgesteld of de uit te voeren activiteiten 58 In de literatuur (zie bijvoorbeeld Wijnen et al. 1992) worden naast geld, tijd en kwaliteit de kenmerken informatie en organisatie onderscheiden. Deze kenmerken worden hier buiten beschouwing gelaten omdat deze gericht zijn op de omschrijving van het te leveren produkt.

12 102 Hoofdstuk 4 daadwerkelijk zijn uitgevoerd. Deze controle kan het best worden uitgevoerd indien een bepaald produkt of een bepaald document als afsluiting van de fase wordt opgeleverd. Een dergelijke gebeurtenis is eenvoudiger te controleren dan een vage eis dat 60% van het uit te voeren werk voltooid moet zijn. Hieruit volgt dat het ontwikkelingsproces moet worden opgedeeld in diverse fasen en activiteiten die op regelmatige momenten in de tijd concrete en te controleren produkten opleveren. Dergelijke mijlpalen geven houvast bij de planning en het vaststellen van de voortgang van het project (Randolph en Posner, 1988) Kosten De kosten van een project hangen zeer sterk samen met de benodigde tijd en de daarbij ingezette middelen. Dit geldt met name bij softwareprojecten waarbij de grootste kostenpost bestaat uit de salarissen van de medewerkers. Het uitlopen van een project heeft tot gevolg dat de personeelskosten navenant zullen stijgen Kwaliteit 59 In het laatste decennium is kwaliteit steeds meer in de belangstelling komen te staan. Mulder (1985) noemt als redenen voor deze belangstelling: de noodzaak om de prestatie/prijs verhouding van produkten en diensten te verhogen; de druk op de produktiekosten; sterk gestegen eisen van de afnemers; wettelijke regelingen en ontwikkelingen op het gebied van de produktaansprakelijkheid. De aandacht voor kwaliteit komt ondermeer tot uitdrukking in de ISO-kwaliteitsnormen en de certificatie van ondernemingen die aan deze normen voldoen. In de loop van de tijd is een ontwikkeling in het kwaliteitsbewustzijn waar te nemen. Het kwaliteitsbewustzijn wordt in een drietal fasen opgedeeld (Moir, 1988; Challink en Wassink, 1990; Bruggen et al., 1991): 1. Kwaliteitscontrole achteraf. De kwaliteit van een produkt wordt na de bewerking vastgesteld. Deze controle achteraf komt tot uitdrukking in de validatie- en verificatiestappen na afloop van elke fase in het ontwikkeltraject (zie bijvoorbeeld SDM, 1989). Met name het watervalmodel (Boehm, 1981) is gericht op het nemen van een go/no-go beslissing na elke fase in de systeemontwikkeling. 2. Kwaliteitsbeheersing in het proces. In deze fase wordt niet uitsluitend naar de produkten gekeken, maar ook naar het proces. Er wordt meer aandacht besteed aan de procedures en richtlijnen die gedurende het ontwikkeltraject worden toegepast. 'Quality circles' worden toegepast om de medewerkers te betrekken bij het optimaliseren van het proces, het verhogen van de kwaliteit en het verhogen van de tevredenheid. 3. Totale kwaliteitsbeheersing. De derde fase omvat 'total quality control'. Deze fase is er op gericht de uiteindelijke gebruikersbehoeften te vervullen. De gehele organisatie wordt hierbij betrokken. Een kwaliteitssysteem gebaseerd op de 59 Deze paragraaf is gebaseerd op (Vrolijk, 1995).

13 Projectplanning en softwareprojecten 103 ISO-9000 norm, behoort tot deze fase. Een kwaliteitssysteem is het geheel van de organisatorische structuur, verantwoordelijkheden, procedures, processen en voorzieningen voor het ten uitvoer brengen van de kwaliteitszorg (De Heer en Ahaus, 1991). Kwaliteit is op een aantal manieren van invloed op het ontwikkelproces. Rijsenbrij (1993) stelt dat bij de uitvoering van een automatiseringsproject sprake is van een drietal processen, te weten het opdrachtmanagement, het projectmanagement en de ontwikkeling van de informatievoorziening. De drie processen hebben elk hun eigen kwaliteitseisen (zie Figuur 4-3). Kwaliteitssysteem Opdrachtmanagement contact offerte en contract decharge nazorg methoden voor het opdrachtmanagement Projectmanagement projectvoorbereiding en projectstart projectvoering projectuitvoering projectafsluiting Ontwikkeling van de informatievoorziening methoden voor het projectmanagement methoden voor de ontwikkeling van de inf. voorziening Figuur 4-3: Drie processen binnen een automatiseringsproject. De drie niveaus komen terug in de definitie van het kwaliteitssysteem (Rijsenbrij, 1989). In dit systeem worden bij de kwaliteitsvoorwaarden methoden voor het opdrachtmanagement, het projectmanagement en de ontwikkeling van de informatievoorziening onderscheiden. Delen en Rijsenbrij (1990) beschrijven de invloed van de te leveren produktkwaliteit op de systeemontwikkeling. Als model van de systeemontwikkeling gebruiken ze de System Development Methodology (SDM, 1989). In de definitiestudie worden de globale kwaliteitseisen geformuleerd. Per kwaliteitsaspect wordt aangegeven in hoeverre dat van belang is voor het systeem. In de fase basisontwerp worden de kwaliteitseisen vertaald naar maatregelen. Een maatregel kan bijvoorbeeld bestaan uit het toevoegen van een beveiligingsschil. In deze fase kunnen de eisen eventueel nog worden bijgesteld. In het detailontwerp komt de nadruk te liggen op de maatregelen. De maatregelen worden verder uitgewerkt. Tijdens de realisatie worden de maatregelen die uit de kwaliteitseisen voortvloeien geïmplementeerd. Tijdens de acceptatietest gaan de eisen weer een rol spelen omdat in deze fase de eigenschappen van het systeem worden getoetst aan de

14 104 Hoofdstuk 4 gespecificeerde kwaliteitseisen. De uiteindelijke invoering heeft geen effect meer op de produktkwaliteit. Uit de voorgaande alinea blijkt dat de kwaliteit doorwerkt in de verschillende fasen van de systeemontwikkeling. In hoeverre hier op managementniveau in de planning expliciet aandacht aan moet worden besteed is afhankelijk van de aard van de kwaliteitseisen. Sommige eisen resulteren in afzonderlijke deelsystemen zoals een dialoogmonitor of een beveiligingsschil. In dergelijke situaties is het aannemelijk dat de planning hier expliciet aandacht aan moet besteden. Relevant hierbij is het onderscheid tussen impliciete en expliciete kwaliteit (Rijsenbrij, 1993). Impliciete kwaliteit is de kwaliteit die wordt geleverd door het met de juiste aandacht en discipline uitvoeren van processen. Daarentegen heeft expliciete kwaliteit betrekking op eisen die leiden tot maatregelen of extra programmatuur, die een aanvulling zijn op de normale functionaliteit. Hieruit volgt dat de impliciete kwaliteit impliciet in de planning wordt verwerkt bij het maken van prognoses van de kosten en tijdsduur van activiteiten. De impliciete kwaliteitseisen zijn opgenomen in de normale wijze van werken in de organisatie. De ervaringen en vuistregels die de planner op basis van voorgaande projecten heeft opgebouwd zijn gebaseerd op deze normale manier van werken. De schattingen van nieuwe activiteiten op basis van ervaringen met voorgaande projecten zullen deze impliciete kwaliteit bevatten. De expliciete kwaliteit moet expliciet worden meegenomen omdat de expliciete kwaliteitseisen leiden tot extra activiteiten. Het ontwikkelen van een beveiligingsschil leidt tot extra activiteiten in de verschillende fasen. Het niet specificeren van deze activiteiten resulteert in een onderschatting van de kosten en doorlooptijd van het project. De fase van het project is daarnaast ook van belang voor het al dan niet expliciet aandacht besteden aan de kwaliteit van het op te leveren produkt. In de ontwerp-fase worden de kwaliteitseisen vertaald in maatregelen. Pas na deze fase is het mogelijk in te schatten welke invloed de eisen zullen hebben op het uit te voeren werk en op de kosten en de doorlooptijd. 4.5 Modellen van het ontwikkelproces Zoals in de vorige paragraaf is beschreven, is het ontwikkelproces van softwareprojecten inhoudelijk veel minder concreet dan het ontwikkelproces van bijvoorbeeld een gebouw. De tussenprodukten van een softwareproject bestaan slechts uit documenten en andere vastgelegde specificaties. Het is daarom moeilijk de tussenliggende stappen eenduidig te definiëren. Door deze onduidelijkheid zijn er in de loop van de tijd diverse visies ontwikkeld omtrent de activiteiten en de volgorde van deze activiteiten, die noodzakelijk zijn om softwareprodukten voort te brengen. Deze verschillende visies komen tot uiting in de diverse modellen van het ontwikkelproces (zie bijvoorbeeld Davis et al. (1988) voor een vergelijking van alternatieve modellen). Het model dat als eerste grote bekendheid heeft verkregen is het Watervalmodel.

15 Projectplanning en softwareprojecten Het Watervalmodel Het eerste model dat voor het ontwikkelproces werd gespecificeerd was het watervalmodel (Royce, 1970; Boehm, 1981). Het watervalmodel beschrijft het ontwikkelproces als een lineaire uitvoering van een reeks van activiteiten. Het watervalmodel onderscheidt een aantal fasen die achtereenvolgens moeten worden doorlopen. Het resultaat van een fase dient als invoer voor de volgende fase. De fasen die in het watervalmodel worden onderscheiden zijn: system requirements, software requirements, preliminary design, detailed design, code and debug, test and pre-operations, operations and maintenance (zie Figuur 4-4). System requirements Software requirements Preliminary Design Detailed design Code and debug Test and preoperations Operations and maintenance Figuur 4-4: Watervalmodel (Davis et al., 1988) Deze fasen die binnen een softwareproject moeten worden uitgevoerd, zijn in grote lijnen vergelijkbaar met de activiteiten die binnen fysieke projecten moeten worden uitgevoerd. De cyclus van analyse, ontwerp en ontwikkeling dient in alle typen projecten te worden doorlopen. In het waterval model wordt elke fase afgesloten met een formele validatie- en verificatie procedure. Deze procedures zijn erop gericht de tussenliggende software produkten te valideren en te verifiëren. De waarde van het watervalmodel is gelegen in het feit dat het model richtlijnen levert voor de werkverdeling binnen projecten. Daarmee worden volgens Boehm (1981) in elk geval twee dingen bereikt:

16 106 Hoofdstuk 4 Ten eerste geldt dat voor de oplevering van een succesvol softwareprodukt hoe dan ook alle subdoelstellingen oftewel tussenprodukten (functioneel ontwerp, technisch ontwerp etc.) moeten worden opgeleverd. Ten tweede stelt Boehm dat een andere volgorde van het opleveren van de tussenprodukten dan de volgorde beschreven in het watervalmodel, resulteert in een minder optimaal eindprodukt of in hogere kosten. Het aanbrengen van wijzigingen brengt bijvoorbeeld meer kosten met zich mee naarmate deze wijzigingen langer worden uitgesteld. De reden dat het watervalmodel nog steeds wordt gebruikt is dat dit model goed aansluit bij de eisen die vanuit managementoogpunt worden gesteld. De uitvoering van een project is in een aantal fasen verdeeld en een fase resulteert in een produkt. Afhankelijk van de fase kan dit produkt een eisenspecificatie, een ontwerpspecificatie, een stuk programmatuur, geteste en geaccepteerde software of geïmplementeerde software omvatten. Deze produkten, samen met enkele vormen van documentatie en de opsplitsing van het project in een aantal fasen, vergroot de beheersbaarheid van de ontwikkeling. De beheersbaarheid wordt tevens vergroot door iedere fase te besluiten met een formele beoordeling van die fase. Aan de hand van deze analyse kan een afgewogen 'go/no-go'-beslissing worden genomen. In de loop van de tijd is er veel kritiek gekomen op het watervalmodel. Bij grote onzekerheid omtrent de eisen- en ontwerpspecificaties bestaat het softwareontwikkelproces niet uit een reeks van activiteiten die achtereenvolgens worden doorlopen. Aanpassingen in de eisen- of ontwerpspecificaties leiden tot iteraties in het ontwikkelproces. Het watervalmodel veronderstelt dat de specificaties in een vroeg stadium kunnen worden bevroren. Deze specificaties worden vervolgens in de rest van het ontwikkeltraject ongewijzigd gehanteerd. Wanneer toch wijzigingen moeten worden aangebracht, zullen deze op een goede manier moeten worden verwerkt 60. Indien een wijziging wordt goedgekeurd kan dit aanleiding zijn tot het aanpassen van de planning Incrementeel ontwikkelen De kritiek op het watervalmodel heeft er toe geleid dat er vanuit andere benaderingen andere modellen van het ontwikkelproces zijn opgesteld. Deze modellen houden beter rekening met de onzekerheid die gepaard gaat met een dergelijk project. Een voorbeeld van een ander model is de zogenaamde incrementele aanpak. De incrementele aanpak is erop gericht de uiteindelijke software in een aantal delen te ontwikkelen (zie Figuur 4-5). McDermid and Rook (1991) definiëren de incrementele aanpak als: a core system is first designed and implemented, then additional functionality is implemented in a series of overlapping subprojects 60 Een goedkeuringsprocedure moet worden doorlopen waarin de consequentie van de voorgestelde verandering voor alle andere componenten van het project worden geëvalueerd.

17 Projectplanning en softwareprojecten 107 In elke fase, elke uitbreiding op het initiële systeem, wordt een gedeelte van de gewenste functionaliteit aan het systeem toegevoegd. Bij elke stap worden in grote lijnen dezelfde fasen onderscheiden als in het watervalmodel. Davis et al. (1988) noemen als voordelen van de incrementele methode de verkorte doorlooptijd om een initieel systeem te ontwikkelen en de grotere aanpasbaarheid van het systeem. Increment 1 Increment 2 Specification Architectural design Detailed design Architectural design Code and unit test Detailed design Integration and test Code and unit test Delivery Integration and test Delivery Increment 3 Architectural design Detailed design Code and unit test Integration and test Time Figuur 4-5: Incrementeel ontwikkelen (McDermid en Rook, 1991). In Figuur 4-5 is een voorbeeld van incrementeel ontwikkelen opgenomen waarbij in eerste instantie een complete verzameling van eisenspecificaties wordt opgesteld en waarbij de verschillende delen vervolgens via een incrementele aanpak worden ontwikkeld. Het is echter ook mogelijk de eisenspecificaties pas bij elke uitbreiding vast te stellen. Daarnaast kan nog een onderscheid worden gemaakt naar de mate van overlap tussen de verschillende uitbreidingen. In het voorbeeld worden de uitbreidingen ten dele parallel ontwikkeld. Het is echter ook mogelijk de verschillende delen sequentieel uit te voeren. Het watervalmodel biedt goede aanknopingspunten voor de planning en beheersing van projecten, maar de incrementele aanpak doet dat ook. In de incrementele aanpak kan eveneens een reeks van activiteiten worden onderscheiden. Bij een uitbreiding van de functionaliteit van het systeem zal eerst een eisenspecificatie worden opgesteld 61, vervolgens wordt een ontwerp gemaakt en tenslotte wordt het ontwerp gerealiseerd, getest en uiteindelijk geïmplementeerd. In deze aanpak wordt dezelfde reeks activiteiten onderscheiden als in het watervalmodel. Elke uitbreiding van de functionaliteit van de software kan als een afzonderlijk project worden beschouwd. Een project, op deze manier gedefinieerd, kan via planning op dezelfde wijze worden beheerst. Bij significante uitbreidingen van het systeem zal het uit het oogpunt van beheersing zelfs van essentieel belang 61 Tenzij deze eisen vooraf voor alle delen worden gespecificeerd zoals in het voorbeeld is beschreven.

18 108 Hoofdstuk 4 zijn de uitbreiding als een project te definiëren. Het voorgaande kan inzichtelijk worden gemaakt aan de hand van het zogenaamde spiraalmodel. Cumulative cost Progress through steps Evaluate alternatives, Identify, resolve risks Determine objectives, alternatives, constraints Risk analysis Risk analysis Risk analysis Review Commitment Partition Plan next phases Requirements plan life-cycle plan Development plan Integration and test plan Risk analysis Prototype 1 Prototype 2 Prototype 3 Concept of operation Requirements validation Design validation and verification Implementation Acceptance test Software requirements Integration and test Software product design Unit test Code Develop, verify next-level product Operational prototype Simulations, models, benchmarks Detailed design Figuur 4-6: Het spiraalmodel (Boehm, 1988) Boehm (1988) beschrijft een spiraalmodel 62 voor de software-ontwikkeling. In elke omgang van de spiraal worden de volgende stappen ondernomen. identificeer het deelprobleem dat het hoogste risico oplevert. vind een oplossing voor dat probleem Van Vliet (1988) onderschrijft deze aanpak door te stellen dat tijdens de ontwikkeling van een programmatuursysteem een aantal problemen moet worden opgelost. Een goede gang van zaken is dat men eerst de lastige problemen of de problemen met een hoog risico probeert op te lossen. Deze problemen hebben de grootste invloed op het welslagen van het project. In Figuur 4-6 is te zien dat elke cyclus een zelfde reeks van activiteiten omvat voor elk deel van het produkt en voor elk detailniveau (concept of operation tot de code van afzonderlijke programma s) (McDermid en Rook, 1991). In geval van incrementeel ontwikkelen wordt de spiraal meerdere malen doorlopen (Van Vliet, 1988). Elke cyclus in de spiraal begint (tweede kwadrant Figuur 4-6) met het vaststellen van: (1) de doelstellingen voor het deel van het produkt dat in die cyclus 62 Het spiraalmodel is een algemeen meta-model van het ontwikkelproces (McDermid and Rook, 1991). Andere ontwikkelmodellen zijn af te beelden in het spiraalmodel. Van Vliet (1988) geeft als voorbeeld: als, uitgaande van een nauwkeurige definitie van eisen, het verkrijgen van een robuust en goed gedocumenteerd systeem de belangrijkste kwestie is, wordt de spiraal eenmaal doorlopen met de traditionele fasen en mijlpalen als tussenstappen.

19 Projectplanning en softwareprojecten 109 wordt ontwikkeld; (2) alternatieven voor het ontwikkelen van dat deel en (3) restricties die gelden voor het ontwikkelen van dat deel. In de volgende stap worden de alternatieven geëvalueerd met betrekking tot de gestelde doelen en restricties. Deze evaluatie dient eventuele projectrisico s te identificeren. In de derde stap wordt een deel van het produkt ontwikkeld. Vervolgens wordt een plan opgesteld voor de volgende cyclus. Elke cyclus wordt afgesloten met een review procedure. Alle produkten die in de cyclus zijn opgeleverd, inclusief het plan voor de volgende cyclus, worden hierbij beoordeeld Prototyping Incrementeel ontwikkelen en prototyping worden vaak ten onrechte niet duidelijk onderscheiden. Prototyping is met name gericht op die situaties waarin grote onzekerheid bestaat omtrent de functionele eisen. Prototyping is niet een afzonderlijk model van het ontwikkelproces, maar een techniek die binnen de andere genoemde ontwikkelmodellen zoals het watervalmodel en de incrementele aanpak kan worden toegepast. Vonk (1987) definieert prototyping als: een benadering voor het achterhalen van functionele specificaties, die gekarakteriseerd wordt door een hoge mate van iteratie, een zeer nauwe samenwerking tussen ontwikkelaars en toekomstige gebruikers van het informatiesysteem, en een uitgebreid gebruik van prototypes. Prototyping is met name geschikt indien de informatiebehoeften van de gebruikers c.q. de functionele eisen van het systeem niet volledig vooraf zijn te specificeren 63. Prototyping wordt in dergelijke situaties toegepast om de informatiebehoeften te achterhalen (Rakos, 1988). Prototyping wordt bijvoorbeeld vaak gebruikt bij het ontwikkelen van Decision Support Systemen (Guimaraes en Saraph, 1991). Davis en Olson (1987) beschrijven prototyping als een 4-staps-proces: 1. Identify the user's basic information requirements. 2. Develop the initial prototype system 3. Use of the prototype system to refine the user's requirements. 4. Revise and enhance the prototype system. Prototyping start met het op een snelle wijze opleveren van een initieel systeem op basis van een eerste inventarisatie van de gebruikersbehoeften. Van Vliet (1988) definieert een prototype als: een werkend model van een [concreet, HV] informatiesysteem dat bepaalde aspecten benadrukt als hulpmiddel bij de probleemanalyse 63 Naast het gebruik van een prototype om de functionele eisen vast te stellen wordt in bepaalde gevallen een technisch prototype ontwikkeld om technische aspecten te beoordelen (Aldershof-Eikelenboom en de Vroed, 1990). Kieback et al. (1992) beschrijven een demonstratie prototype Bei der Akquisition soll der Demonstrationsprototyp den Auftraggeber überzeugen, daß ein Anwendungs entweder prinzipiell gebaut werden kann oder daß seine Handhabung den Vorstellungen des Anwenders und der Benutzer entspricht.

20 110 Hoofdstuk 4 Vervolgens zullen de gebruikers tijdens het gebruik van dit initiële systeem op nieuwe behoeften stuiten. Deze nieuwe behoeften worden in het volgende prototype verwerkt. Deze laatste twee stappen worden iteratief doorlopen. Het prototype wordt gebruikt en gedurende dit gebruik worden fouten en discrepanties met de feitelijke wensen van de gebruikers ontdekt. Deze fouten en afwijkingen leiden vervolgens tot aanpassingen in het prototype waarmee vervolgens weer opnieuw wordt geëxperimenteerd. Het aanpassen van het systeem gaat door totdat de gebruiker tevreden is met het systeem, of totdat blijkt dat het prototype niet bruikbaar is. Op dit punt wordt dan de ontwikkeling gestopt. Prototyping, als een methode om de informatiebehoeften te definiëren, veronderstelt dat de ontwikkeling van het prototype wordt gevolgd door de ontwikkeling van een volwaardig systeem. Het prototype vormt hierbij de basis voor het definiëren van de informatiebehoeften. Vonk (1987) beschrijft twee mogelijkheden om van het prototype te komen tot het definitieve systeem. De eerste mogelijkheid bestaat uit het van de hand doen van het prototype, het zogenaamde 'throw-away-prototype', en het systeem van de grond af aan te ontwikkelen. Het prototype wordt in deze aanpak uitsluitend gebruikt om inzicht te krijgen in de functionele eisen. Prototyping wordt hierbij dus gevolgd door een traditionele systeemontwikkeling. De tweede mogelijkheid is het prototype niet weg te gooien maar te 'upgraden'. Met het prototype is reeds een aanzienlijk deel van het systeem ontwikkeld en in deze tweede opvatting is het jammer dit weg te gooien. Het systeem moet wel verbeterd worden omdat binnen een prototype minder aandacht wordt besteed aan kwaliteits- en prestatie-eisen. In welke mate het upgraden van een prototype mogelijk is, zal afhankelijk zijn van de gebruikte gereedschappen voor het ontwikkelen van het prototype. Als deze gereedschappen ook geschikt zijn voor een volwaardige systeemontwikkeling dan zal het upgraden makkelijk te realiseren zijn. Prototyping is de minst gestructureerde aanpak; planning en beheersing van prototypingactiviteiten zal dan ook het moeilijkst zijn. Desondanks is er wel degelijk sprake van enige mate van structurering (zie de fasen van Davis en Olson). De ontwikkeling van het initiële prototype zal in een aantal stappen plaatsvinden. Bij het ontwikkelen van een initieel prototype zal moeten worden gestart met een definitie van eisen, gevolgd door een ontwerp, realisatie en ingebruikname. Deze activiteiten en de afhankelijkheid tussen deze activiteiten is in een activiteitennetwerk weer te geven. Dit netwerk kan vervolgens als probleembeschrijving in de verdere projectplanning worden gebruikt. De daaropvolgende aanpassingen aan het initiële prototype bestaan eveneens uit een aantal goed te definiëren stappen. Eerst moeten bepaalde additionele wensen en eisen worden gedefinieerd, de haalbaarheid moet worden beoordeeld, de ontwerpimplicaties moeten worden vastgesteld, de veranderingen moeten worden doorgevoerd en tenslotte moeten deze veranderingen worden getest voordat het prototype weer aan de gebruiker kan worden overgedragen. Deze cyclus van activiteiten is met behulp van planningmethoden te modelleren. De planning en beheersing wordt moeilijker naarmate de doorgevoerde veranderingen per iteratie geringer zijn en dus meer iteraties plaatsvinden. Uit het voorgaande blijkt dat er wezenlijke verschillen bestaan tussen prototyping en incrementeel ontwikkelen. Het met behulp van prototyping ontwikkelde systeem