Hoofdstuk 4 Projectplanning en softwareprojecten

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’s54. 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.

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,

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.

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


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. Intern rendement Economische factoren

Kapitaalkosten

Kwantitatief

Terugverdientijd

Omvang

Prioriteit informatiesysteem

Structuur Ervaring met technologie

Risico

Complexiteit Organisatie

Kwalitatief

Technologie 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

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 42 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


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 ingesteld55 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. 2. 3. 4.

het gewenste resultaat weliswaar niet volstrekt nieuw is maar wel veel nieuwe elementen of aspecten omvat, mensen uit verschillende disciplines of vakgebieden dat resultaat samen moeten bereiken, men eenmalig een maximale prestatie moet leveren, men over beperkte middelen beschikt om dat resultaat te bereiken.

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 bedrijven56.

56 Zie bijvoorbeeld het informatiemodel technische- en onderhoudsdiensten (Smit en Slaterus, 1989).


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 Jong57 (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).

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


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 drie58 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. 4.4.1 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.

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). 4.4.2 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. 4.4.3 Kwaliteit59 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).


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

Projectmanagement projectvoorbereiding en projectstart

projectvoering

projectafsluiting

nazorg

methoden voor het opdrachtmanagement

methoden voor het projectmanagement

projectuitvoering

Ontwikkeling van de informatievoorziening

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

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.


105

4.5.1 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:

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 verwerkt60. Indien een wijziging wordt goedgekeurd kan dit aanleiding zijn tot het aanpassen van de planning. 4.5.2 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.


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. Delivery

Increment 1 Specifi- Architectural Detailed Code and Integration design unit test cation design and test

Delivery Increment 2 Architectural Detailed Code and Integration design unit test design and test

Increment 3 Architectural Detailed Code and Integration design unit test design 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 opgesteld61, 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.

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

Risk analysis

Determine objectives, alternatives, constraints

Risk analysis Risk analysis Risk analysis

Commitment Review

Requirements plan life-cycle plan

Partition

Development plan

Integration and test plan

Plan next phases

Prototype 2

Prototype 1

Concept of operation

Prototype 3

Operational prototype

Simulations, models, benchmarks Software requirements

Requirements validation Design validation and verification Acceptance Implementation test

Integration and test

Software product design Detailed design

Unit test

Code

Develop, verify next-level product

Figuur 4-6: Het spiraalmodel (Boehm, 1988) Boehm (1988) beschrijft een spiraalmodel62 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.’


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. 4.5.3 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 specificeren63. 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.’

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


111

is en blijft een prototype. Het prototype is slechts bedoeld om de functionele eisen te achterhalen en eventueel de technische haalbaarheid te beoordelen. Het prototype is niet ontwikkeld om echt in gebruik te worden genomen. Aan kwaliteits- en prestatieeisen wordt hierdoor minder aandacht besteed. De systemen die via de incrementele aanpak totstandkomen, zijn daadwerkelijk bedoeld om operationeel te worden. De totale functionaliteit wordt echter in een aantal stappen geïmplementeerd. 4.5.4 Het watervalmodel nader bekeken Uit de case-beschrijvingen (zie paragraaf 5.3 en appendix A) blijkt dat de meeste bedrijven volgens de lineaire methode werken. Daarom zal deze methode nader worden toegelicht in deze paragraaf. De lineaire systeemontwikkelingsmethoden bestaan uit een aantal fasen die lineair oftewel sequentieel worden doorlopen. In al deze methoden zijn de meer bekende stappen van analyse, ontwerp, bouw, invoering en tenslotte gebruik en beheer te onderscheiden. Voorbeelden van deze lineaire ontwikkelingsmethoden zijn Infomod en SDM. Een soortgelijke opsplitsing in de uitvoering van activiteiten binnen software-ontwikkelingsprojecten is eveneens te herkennen in de fasering van andere type projecten. Fasering. Wijnen et al. (1992) onderscheiden zes fasen in een project. De fasen worden sequentieel doorlopen en geven een beeld van de activiteiten die in het algemeen in een project worden uitgevoerd (zie Figuur 4-7). Algemeen wil hierbij zeggen dat de toepasbaarheid van het model niet is gelimiteerd tot softwareontwikkelingsprojecten, maar ook zinvol is bij andersoortige projecten. 0

1

2

3

4

5

Idee

Wat

Hoe

Hoe te maken

Doen

In stand houden

initiatief fase

definitie fase

ontwerpfase

voorbereidingsfase

realisatiefase

nazorg fase

Figuur 4-7: Fasering van een project. 0

1

In de initiatieffase wordt het probleem in kaart gebracht en wordt onderzocht of het uitvoeren van een project een oplossing kan bieden. In deze fase moet worden aangegeven wat men wenst te bereiken met het uitvoeren van het project. De initiatieffase omvat eveneens een beoordeling van de haalbaarheid van het project. In de definitiefase wordt het gewenste resultaat van het project zo duidelijk mogelijk gedefinieerd. De eisen die aan het resultaat worden gesteld, moeten expliciet worden gespecificeerd.

112 2

3

4 5

Hoofdstuk 4 In de ontwerpfase wordt een oplossing ontwikkeld gegeven de gedefinieerde doelstelling. Dit ontwerp moet voldoen aan de in de vorige fase gedefinieerde eisen. De voorbereidingsfase is gericht op het treffen van allerlei voorbereidingen zodat de realisatiefase vlekkeloos kan verlopen. De in de vorige fase gekozen oplossing moet worden vertaald naar activiteiten die gedurende de realisatiefase moeten worden uitgevoerd. De realisatiefase is gericht op het realiseren van het gewenste projectresultaat door het uitvoeren van de noodzakelijke activiteiten. De nazorgfase heeft betrekking op het onderhoud van het systeem. Het onderhoud bestaat uit alle activiteiten die nodig zijn om het systeem operationeel te houden (Van Vliet, 1988). Het onderhoud kan bestaan uit het verbeteren van fouten (corrective maintenance), maar ook uit het aanbrengen van eventuele veranderingen (adaptive en perfective maintenance64) (Drigani, 1989).

De hier beschreven fasering toont een samenhang met het in hoofdstuk 1 beschreven beslissingsproces (zie Figuur 1-4) en de in Figuur 2-1 beschreven opeenvolging van stappen om van een probleem te komen tot een oplossing. In de initiatieffase wordt het probleem beschreven. In deze fase is sprake van een empirisch beschrijvend model. In de definitiefase wordt een beschrijvend conceptueel model opgesteld. Vervolgens wordt in de ontwerpfase een oplossing gegenereerd in de vorm van een conceptueel voorschrijvend model. In de vertaling van het globale ontwerp naar de realisatie wordt dit conceptuele model empirisch gemaakt. System Development Methodology. De fasering in de voorgaande paragraaf geeft een beschrijving van een reeks voor de hand liggende activiteiten die vanaf idee tot realisatie moeten worden uitgevoerd. Voor de ontwikkeling van informatiesystemen zijn er meer specifieke faseringen ontwikkeld. Systeemontwikkelingsmethoden geven een beschrijving van de fasen en activiteiten die binnen een software ontwikkelingsproject moeten worden uitgevoerd. SDM zal hier uitvoeriger worden beschreven omdat deze methode, of varianten daarvan, het meest wordt toegepast. SDM richt zich met name op de planning en de organisatie van de systeemontwikkeling. In feite is SDM een grote verzameling procedures voor de systeemontwikkeling. SDM biedt een opeenvolging van uit te voeren activiteiten, te ontwikkelen produkten, te bereiken mijlpalen en te beoordelen fasen. SDM geeft een beschrijving van wat er moet gebeuren binnen een software-ontwikkelingsproject, en niet zo zeer van hoe dit moet gebeuren. SDM zal dan ook moeten worden aangevuld met technieken die dieper ingaan op de verschillende aspecten van de systeemontwikkeling. Hierbij kunnen allerlei technieken worden gebruikt zoals dataflow diagrammen, Nassi-Schneider diagrammen, formele specificatie talen etc. 64 Adaptief onderhoud is gericht op het aanpassen van de programmatuur naar aanleiding van veranderingen in hardware, besturingssystemen etc. Perfectief onderhoud heeft betrekking op het aanbrengen van veranderingen die een gevolg zijn van nieuwe gebruikerswensen.


113

(zie Pottjegort (1992) voor een overzicht van technieken voor de ontwikkeling van informatiesystemen). SDM-fasering SDM biedt een beschrijving van de fasen (en van de activiteiten binnen deze fasen) die moeten worden uitgevoerd om een informatiesysteem te ontwikkelen (Vreven, 1991). De fasen die binnen SDM worden onderscheiden zijn: 1. De informatieplanning omvat het ontwikkelen van een plan, dat een kader schept voor het ontwikkelen van nieuwe informatiesystemen binnen de organisatie65. Het informatieplan is gebaseerd op de doelstellingen van de organisatie en de informatievoorziening, zoals die zijn vastgelegd in het organisatie- en informatiebeleid (zie Figuur 4-2). Het informatieplan heeft als doel de te ontwikkelen systemen in te passen in een totaalconcept, zodat een afstemming van de diverse systemen mogelijk is, en de zogenaamde 'eilandautomatisering' wordt vermeden. 2. De definitiestudie heeft betrekking op de planning van één afzonderlijk systeem. De definitiestudie is gericht op het vaststellen van de haalbaarheid van het project. Vervolgens wordt de beste benaderingswijze voor ontwerp en ontwikkeling vastgesteld. 3. Het basisontwerp is gericht op het definiëren van eisen en het maken van een ontwerp van het te ontwikkelen systeem zodat de verschillende deelsystemen kunnen worden onderscheiden en gedefinieerd. 4. In de fase detailontwerp worden de eisen voor en het ontwerp van de verschillende deelsystemen ontwikkeld. De specificaties moeten gedetailleerd zijn, zodat met de realisatie van dat deelsysteem kan worden begonnen. 5. De realisatiefase omvat ondermeer de vervaardiging van de programmatuur en het ontwikkelen van de organisatorische procedures. Tevens moet de noodzakelijke apparatuur in deze fase worden geïnstalleerd. 6. De invoering omvat het operationeel maken van het systeem in de organisatie. De invoering gaat gepaard met de conversie van oude handmatige- systemen en procedures en/of van oude geautomatiseerde systemen naar het nieuwe informatiesysteem. 7. In de fase gebruik en beheer wordt het ontwikkelde en opgeleverde systeem in de organisatie gebruikt en beheerd. Het onderhoud kan betrekking hebben op het ongedaan maken van geconstateerde fouten, maar kan ook bestaan uit het veranderen en/of uitbreiden van het systeem om aan nieuwe gebruikerswensen te voldoen. SDM en het plannen van projecten Binnen de verschillende fasen worden activiteiten gespecificeerd die nodig zijn voor het ontwikkelen van een informatiesysteem. De specificatie van de activiteiten omvat ondermeer een beschrijving van de rol van die activiteit in de gehele ontwikkeling, 65 Zie paragraaf 4.2 voor een beschrijving van informatieplanning in relatie tot het informatiebeleid en projectplanning.

114

Hoofdstuk 4

de samenhang met andere activiteiten, de specifieke processen voor de uitvoering, en de produkten die worden ontwikkeld in die activiteit. Deze beschrijving van de fasen en activiteiten biedt aanknopingspunten voor de projectplanning in de vorm van een specificatie van uit te voeren activiteiten, de samenhang tussen de activiteiten en de te realiseren mijlpaalprodukten. Of alle fasen en activiteiten die binnen SDM zijn gespecificeerd, daadwerkelijk moeten worden uitgevoerd is afhankelijk van het type project. SDM is gericht op de meer gebruikelijke soorten, van administratieve- en transaktieverwerkende-systemen. Voor andere systemen kan de structurering van SDM worden aangepast. Kleine projecten kunnen bijvoorbeeld aanleiding zijn om fasen en/of activiteiten samen te voegen. Zeer grote projecten kunnen daarentegen leiden tot een verdere verfijning van de activiteiten en fasen. De opsplitsing in fasen en activiteiten kan worden gebruikt bij het maken van een plan voor het project. De opsplitsing kan in een Work Breakdown Structure (WBS) worden weergegeven die vervolgens wordt gebruikt als uitgangspunt bij het specificeren van een activiteitennetwerk. Door uit te gaan van een dergelijke WBS wordt de kans verkleind dat bepaalde activiteiten buiten beschouwing worden gelaten (Levine, 1986). Voor de afzonderlijke activiteiten kan worden gespecificeerd hoe lang een dergelijke activiteit zal gaan duren, welke middelen hiervoor nodig zijn, en welke samenhang er bestaat met andere activiteiten. Op basis van deze gegevens wordt een volledig activiteitennetwerk gespecificeerd, dat vervolgens wordt geanalyseerd. Tausworth (1980) stelt dat de tijdplanning kan worden verbeterd door het project op te splitsen in fasen en activiteiten. In deze situatie kunnen de fouten in schattingen elkaar opheffen. Als de tijdsduur van de ene activiteit wordt overschat en een andere onderschat dan kan de totale schatting nog wel goed zijn. Deze redenering gaat echter alleen op wanneer de validiteit van de schattingen groot is. Als de validiteit van de schattingen te wensen overlaat zullen de activiteiten systematisch overschat of onderschat worden. Het uitmiddelen van schattingsfouten op basis van de wet van de grote aantallen zal dan niet van toepassing zijn.

4.6 Planningmethoden Zoals in hoofdstuk 1 is beschreven kan het beslissingsproces worden ondersteund door gebruik te maken van methoden. In deze paragraaf worden planningmethoden besproken die kunnen worden gebruikt bij het formuleren van beslissingsproblemen, het genereren en evalueren van alternatieven en het maken van een keuze. Ten eerste worden de netwerkplanningmethoden en de verschillende varianten daarvan besproken. Deze methoden zijn er op gericht het uit te voeren project in de vorm van een activiteitennetwerk te modelleren. Dit netwerk dient vervolgens als basis voor verdere analyses. Na de bespreking van de netwerkplanningmethoden zal aandacht worden besteed aan een aantal begrotingsmodellen, die specifiek zijn gericht op het doen van uitspraken over de kosten en doorlooptijd van softwareontwikkelingsprojecten.


115

4.6.1 Netwerkplanningmethoden Het gebruik van netwerkplanningmethoden is gericht op het maken van een probleembeschrijving in de vorm van een activiteitennetwerk. Dit activiteitennetwerk vormt vervolgens de basis voor het doorlopen van de daaropvolgende fasen van het beslissingsproces. Het toepassen van deze methoden kan in een aantal stappen worden opgesplitst (zie Figuur 4-8).

Specificeren activiteiten

Specificeren opeenvolgingsrelaties

Opbouwen netwerk

Specificeren tijdschattingen en middelen

Analyse netwerk

Analyse netwerk

Figuur 4-8: Het toepassen van netwerkplanningmethoden. In het vervolg van deze paragraaf worden de stappen besproken. Daarbij worden enkele theoretische en praktische problemen behandeld. Specificatie van de activiteiten en specificatie van de opeenvolgingsrelaties. Bij het opstellen van een plan met behulp van een netwerkplanningmethode wordt begonnen met het opbouwen van een netwerk. Dit netwerk geeft de uit te voeren activiteiten in het project weer. Tevens worden de opeenvolgingsrelaties tussen de diverse uit te voeren activiteiten weergegeven. Het betreft hier logische c.q. technische opeenvolgingsrelaties (Moder en Phillips, 1970). Het testen van een softwarecomponent kan bijvoorbeeld niet plaatsvinden voordat deze component is gerealiseerd (testen van een module is wellicht wel eerder mogelijk). In deze fase wordt nog geen aandacht besteed aan tijdsaspecten. De prioriteit ligt bij de logische

116

Hoofdstuk 4

opbouw van het netwerk in de vorm van de uit te voeren activiteiten en opeenvolgingsrelaties tussen deze activiteiten66. Bij het grafisch weergeven van een activiteitennetwerk bestaat de keuze uit een ‘activity-on-arrow’ representatie (AoA) en een ‘activity-on-node’ (AoN) representatie. In het gebruik van deze termen is er een groot verschil tussen de wetenschappelijke literatuur en de populaire project management literatuur waar te nemen. Elmaghraby (1995) illustreert dit aan de hand van het volgende voorbeeld: ‘For instance it is street language to speak of arrow diagrams and precedence diagrams instead of activity-on-arc and activity-on-node diagrams. The street language is meaningless since both modes of representation have arrows and both represent precedence!’

Bij het gebruik van AoN representatie worden de activiteiten als knooppunten weergegeven en de opeenvolgingsrelaties als pijlen tussen deze knooppunten. Dit heeft ten opzichte van de activity-on-arrow representatie als voordeel dat er geen dummy-relaties nodig zijn (Wiest and Levy, 1969). Ook komt deze methode meer overeen met de normale wijze van probleembeschrijving, waarbij de uit te voeren activiteiten in de vorm van een black-box worden beschreven en de samenhang met behulp van pijlen wordt weergegeven (Studiecentrum voor administratieve automatisering, 1970). De AoN representatie geeft een directe en sobere representatie van het netwerk en geeft bovendien een unieke representatie van het netwerk. Bij de AoA representatie kan een activiteitennetwerk op meerdere manieren worden gerepresenteerd. De activity-on-arrow representatie beeldt de activiteiten op de pijlen af. Deze manier heeft als voordeel dat de knooppunten, die de activiteiten verbinden, expliciet kunnen worden gekoppeld aan momenten in de tijd. Een knooppunt representeert een ‘event’ (Wiest en Levy, 1969). Een event beschrijft het gereedkomen van een specifiek deel van het project en kan daarom expliciet aan een tijdstip worden gekoppeld. Hierdoor biedt de AoA representatie voordelen indien men het accent wenst te leggen op de events in een netwerk. Het gebruik van events heeft met name voordelen bij de koppeling van verschillende netwerken (Archibald en Villoria, 1966). De koppeling tussen de netwerken kan via gezamenlijke events plaatsvinden. Een slot-event van een activiteit van het ene netwerk vormt een start-event van een activiteit van het andere netwerk. Daarnaast kan de nadruk op events wenselijk zijn indien betalingen zijn gekoppeld aan gebeurtenissen in het project. Bovendien biedt AoA het voordeel dat pijlen de tijdsduur van activiteiten weergeven door de lengte van de pijl proportioneel te laten toenemen met de tijdsduur. Ondanks deze voordelen van de AoA representatie, wordt in het overgrote deel van de gevallen gebruikgemaakt van de AoN representatie. De meeste planningpakketten gaan uit van deze representatie (zie Levine, 1986; Badiru and Whitehouse, 1989). Meer dan 70% van de netwerken worden in de AoN vorm gerepresenteerd (Harhalakis, 1990). 66 In de grafentheorie wordt het onderscheid gemaakt tussen een graaf en een netwerk. ‘A graph defines the purely structural relationships between the nodes, while a network bears also the quantitative charachteristics of the nodes and arcs’ Elmaghraby (1970).


117

Volledigheid van de specificatie van de activiteiten Een belangrijk aandachtspunt bij de constructie van het activiteitennetwerk is de correctheid van de activiteitenspecificatie. Het gebruik van een netwerkplanningmethode voor de projectplanning en scheduling is alleen zinvol indien er een volledige specificatie van de activiteiten en de samenhang tussen de activiteiten wordt vervaardigd. Een activiteit kan worden opgevat als een verzameling van taken, die om organisatorische of andere redenen als een eenheid worden opgevat (Bosman, 1977). Een activiteit representeert een afgebakend deel van het werk dat moet worden uitgevoerd om het project te voltooien. Activiteiten op verschillende aggregatieniveaus kunnen hiërarchisch in een Work Breakdown Structure worden weergegeven (Archibald, 1966). Een essentiële voorwaarde voor de constructie van het netwerk is het waarborgen van de volledigheid van de activiteitenspecificatie. Deze fase kan worden ondersteund door middel van een checklist waaraan de specificatie kan worden getoetst of door middel van een ‘template’ (Chandrashekar et al., 1993) die nader moet worden ingevuld. In een dergelijke template dienen met name activiteiten te worden opgenomen die makkelijk over het hoofd worden gezien. Het betreft hier vooral activiteiten die niet direct noodzakelijk zijn voor het totstandkomen van de software zelf. Voorbeelden van deze activiteiten zijn de marketing- en projectmanagement-activiteiten. Een template of checklist moet ondersteunend en niet knellend werken. Het moet dus mogelijk zijn van de vooraf vastgelegde specificatie af te wijken. Wanneer inderdaad wordt afgeweken, zal er wel sprake zijn van een meer doordachte keuze van bepaalde activiteiten. Indien een Work Breakdown Structure van het project wordt vervaardigd dan kan deze structuur worden gebruikt als leidraad voor de constructie van het netwerk. De volledigheid van de specificatie zal afhankelijk zijn van de mate van aggregatie van de activiteiten. Bij een sterke mate van aggregatie (een hoger niveau in de Work Breakdown Structure) zal de kans op een volledige specificatie groter zijn. Geaggregeerde activiteiten zullen minder snel over het hoofd worden gezien. Een van de overwegingen bij de keuze van het niveau van aggregatie is de mogelijkheid tot het specificeren van de benodigde produktiefactoren en de tijdsduur van de activiteiten. Op een hoog niveau van aggregatie zal het minder goed mogelijk zijn een volledig beeld van de inhoud van de activiteiten te verkrijgen. Het zal daarom moeilijker zijn de tijdsduur en de benodigde produktiefactoren te specificeren. Het niveau van aggregatie is ook van belang voor de beslissing om activiteiten al dan niet parallel uit te voeren. Op een lager niveau zijn er meer mogelijkheden om bepaalde activiteiten parallel uit te voeren. Gekozen moet worden voor een zodanig niveau van aggregatie dat inzicht wordt verkregen in de mogelijkheden tot parallel uitvoeren van activiteiten. Een belangrijke kwestie bij de beoordeling van de volledigheid is de vraag hoe de volledigheid moet worden getoetst. De specificatie van de activiteiten moet aan iets anders worden getoetst. Dit sluit een kritische beoordeling van de specificatie door de planner natuurlijk niet uit. De beoordeling van de volledigheid kan worden gebaseerd op referentie-modellen, die als toetssteen worden gebruikt. Een bekend voorbeeld uit de software-ontwikkeling is SDM (System Development

118

Hoofdstuk 4

Methodology). SDM is vooral gericht op de planning en organisatie van de systeemontwikkeling. In de ontwikkeling van het systeem worden een aantal fasen onderscheiden. Volledigheid van de opeenvolgingsrelaties Na het specificeren van de uit te voeren activiteiten moeten de opeenvolgingsrelaties tussen de activiteiten worden aangegeven. Het betreft hier de logische samenhang tussen activiteiten. Een activiteit kan pas worden gestart zodra alle voorgaande activiteiten zijn voltooid (Moder en Phillips, 1970). Diverse typen van opeenvolgingsrelaties kunnen worden onderscheiden, namelijk: de finish-start-relatie (de meest gebruikte opeenvolgingsrelatie); de start-start-relatie en de finish-finishrelatie (Studiecentrum voor administratieve automatisering, 1970). Op basis van de gespecificeerde opeenvolgingsrelaties tussen de activiteiten kan een volledigheidscontrole plaatsvinden. Indien het gehele project wordt begonnen met een symbolische startactiviteit en wordt afgesloten met een symbolische eindactiviteit, kunnen activiteiten worden gesignaleerd waarvoor geen opeenvolgingsrelatie is gespecificeerd, of waarvoor alleen een opvolger of voorganger is gespecificeerd. Deze controle signaleert echter uitsluitend activiteiten die geen voorganger en/of geen opvolger hebben. De vraag hoe de volledigheid wordt beoordeeld, moet ook hier worden beantwoord. De opeenvolgingsrelaties zullen vaak gebaseerd zijn op gewoontes. Een kritische analyse is nodig, teneinde te bepalen of bepaalde activiteiten wellicht gesplitst of parallel kunnen worden uitgevoerd. De juiste specificatie van de opeenvolgingsrelaties zal afhangen van de mate van aggregatie van de specificatie. Wanneer het netwerk op faseniveau wordt gespecificeerd is de kans op een volledige specificatie veel groter. Aard van de gemodelleerde samenhang tussen de activiteiten Het antwoord op de vraag wat al dan niet in een netwerk wordt opgenomen, wordt vaak bepaald door de mate van samenhang tussen de activiteiten. In een activiteitennetwerk wordt de directe samenhang tussen de verschillende activiteiten weergegeven. Wanneer er sprake is van een minder directe samenhang, is het minder gebruikelijk om een netwerkplanningmethode toe te passen. De toepassing blijft echter wel degelijk mogelijk. Ook in het geval waarbij min of meer onafhankelijke componenten worden ontwikkeld, zullen er nog relaties bestaan. Ten eerste is er een mogelijk gezamenlijk gebruik van produktiefactoren. Ten tweede zal er zelfs bij relatief onafhankelijke componenten samenhang bestaan. Het eindprodukt kan niet worden samengesteld voordat de diverse componenten zijn vervaardigd. Deze samenhang is wel degelijk met een netwerk te beschrijven. Het netwerk wordt weergegeven als een gericht acyclisch netwerk. De fasen worden gericht doorlopen zonder onzekerheid omtrent de volgorde van uitvoering van de fasen. Parallel uitvoeren van activiteiten in een netwerk is mogelijk. In tegenstelling tot bepaalde kortste-pad-netwerken moeten in activiteitennetwerken alle paden en dus alle activiteiten, worden doorlopen. Alle activiteiten zijn van wezenlijk belang voor het realiseren van het doel van het project. In de praktijk worden software-ontwikkelingsprojecten gekenmerkt door diverse onzekerheden


119

omtrent de volgorde van de uitvoering van activiteiten. Het is mogelijk dat een voorgaande activiteit geheel of gedeeltelijk moet worden herhaald indien bepaalde wensen, eisen, logische of technische specificaties moeten worden herzien of verduidelijkt. Uiteraard, zal men deze in eerste instantie zo duidelijk mogelijk wensen te specificeren, zodat er geen, of zo min mogelijk onzekerheden bestaan. Onzekerheden hebben echter wel invloed op de voortgang van het project. De huidige planning-pakketten laten geen cyclische netwerken toe. Om toch rekening te houden met het heruitvoeren van voorgaande activiteiten kunnen deze expliciet als afzonderlijke activiteiten in het netwerk worden opgenomen. Het is echter moeilijk aan een dergelijke activiteit invulling te geven, omdat het streven gericht is op het voorkomen van deze activiteiten en hen dus een tijdsduur van nul toe te kennen. Een alternatieve manier om dit probleem te ondervangen, is het modelleren van de onzekerheden in een opslag voor het gehele project. Wanneer de probleembeschrijving is gericht op een specificatie van de doorlooptijd van een project, kan de onzekerheid omtrent de volgorde van het uitvoeren van activiteiten worden gemodelleerd. Hiertoe moeten de waarschijnlijkheden worden gespecificeerd die uitdrukken hoe groot de kans is dat een activiteit wordt uitgevoerd en welke opeenvolgingsrelaties optreden (Moder en Phillips, 1970). Deze onzekerheden kunnen in ‘Generalized Networks’ worden gemodelleerd (Van Laar, 1990). Indien deze kansen zijn gespecificeerd kan met behulp van simulatie of Markov- modellen de doorlooptijd van het gehele project worden bepaald. Bij gebruik van simulatie zal niet elke replicatie dezelfde activiteitsvolgorde kennen. Welke activiteiten worden uitgevoerd is afhankelijk van de toevalstrekkingen uit kansverdelingen. Een dergelijke kansverdeling dient de kans te representeren dat een bepaalde activiteit wordt uitgevoerd. Uit de diverse replicaties wordt een kansverdeling van de doorlooptijd van het gehele project afgeleid. Specificatie van de tijdsduur en de middelen. Nadat de activiteiten en de opeenvolgingsrelaties tussen deze activiteiten zijn gespecificeerd, moet de tijdsduur van de diverse activiteiten worden geschat. Tevens moet worden aangegeven welke middelen er nodig zijn om een activiteit tot een goed einde te brengen. De samenhang tussen de middelen en de tijdsduur kan beter in het oog worden gehouden indien deze beide aspecten van een activiteit tegelijkertijd worden gespecificeerd. Hieronder volgen een aantal richtlijnen voor het toewijzen van activiteiten aan mensen (Rakos, 1988). • assign tasks to individuals whose skill levels suits the task • assign similar tasks to the same person • assign time critical tasks to your most reliable people • assign tasks that communicate to the same individual • do not forget the project leader needs time to supervise Het schatten van de tijdsduur kan op diverse manieren plaatsvinden. Mogelijkheden hierbij zijn schattingen door een expert of schattingen op basis van voorgaande

120

Hoofdstuk 4

projecten67 (Rakos, 1990; Drigani, 1989). Schattingen van meerdere experts kunnen een meer afgewogen beoordeling opleveren68. Met behulp van de Delphi-methode worden schattingen van diverse experts in meerdere ronden herleid tot een algemeen oordeel (Van Doorn en Van Vught, 1978). Bij een schatting aan de hand van voorgaande projecten worden parallellen gezocht met voorgaande projecten op basis waarvan de tijdsduur wordt geschat. Een mogelijke invulling van de schatting aan de hand van historische projecten is het opstellen van richtlijnen of normtijden. Een vereiste bij het gebruik van deze richtlijnen en normtijden is dat het uit te voeren project in grote lijnen vergelijkbaar is met de historische projecten. De schatting op basis van voorgaande vergelijkbare projecten vereist de beschikbaarheid van gegevens. Uit onderzoek blijkt dat deze projectgegevens vaak niet worden vastgelegd (Heemstra en Kusters, 1989). Het beschikbaar krijgen van gegevens vergt maatregelen teneinde de projectgegevens vast te leggen ten behoeve van nieuwe projecten. Het onderscheid tussen de twee methoden is niet scherp, omdat zowel de schatting van de expert als de normtijden zullen zijn gebaseerd op voorgaande projecten. Bij het schatten van de tijdsduur door een expert zal impliciet rekening worden gehouden met de benodigde produktiefactoren. De expert zal in grote lijnen nagaan wat er moet gebeuren binnen een bepaalde activiteit en welke produktiefactoren hiervoor nodig zijn. Op basis van deze afwegingen zal met behulp van bepaalde regels een tijdschatting totstandkomen. De schatting zal waarschijnlijk in meer of mindere mate afwijken van de uitvoering. Deze afwijking kan te wijten zijn aan de schatting en/of aan de uitvoering. Het gedeelte van de afwijking dat veroorzaakt wordt door fouten in de schatting kan wellicht worden verminderd door de benodigde produktiemiddelen explicieter bij het begrotingsproces te betrekken. Diverse activiteiten kunnen met een verschillende inzet van produktiemiddelen worden uitgevoerd. De naïeve veronderstelling dat een verdubbeling van de ingezette produktiefactoren leidt tot een halvering van de tijdsduur gaat vaak niet op (Brooks, 1977). De inzet van extra produktiefactoren kan leiden tot een vergroting van het coördinatieprobleem. Het oplossen van dit probleem kost tijd en produktiefactoren. In eerste instantie zal een schatting worden gemaakt van de normale c.q. meest efficiënte tijdsduur van een activiteit. In een later stadium kan een afweging worden gemaakt of een tijdsbesparing opweegt tegen de extra kosten van deze versnelling. Na het schatten van de duur van activiteiten kan een redelijkheidscontrole plaatsvinden op de tijdsduur van fasen van een project. In de literatuur zijn bepaalde verdelingen van tijd over de verschillende fasen te vinden. Met behulp van deze gegevens kan een indicatie worden verkregen of een bepaalde fase, zoals ontwerp of testen, onderbelicht blijft.

67 Modellen om de benodigde inzet van produktiefactoren vast te stellen worden verderop in dit hoofdstuk besproken. 68 Hierbij wordt afgezien van de mogelijkheid van politiek gekleurde schattingen zoals (Van Vliet, 1988): de wet van Parkinson ‘work fills the time available’, ‘price to win’ en de budget-methode.


121

Analyse netwerk. Gegeven de opeenvolgingsrelaties en de gespecificeerde tijdsduur van activiteiten is het mogelijk om de kritieke paden in het netwerk te bepalen. Dit zijn de ketens van activiteiten die minder speling hebben dan een bepaalde kritieke waarde (vaak wordt de grens op een speling van nul gezet). Tevens kan de speling van de overige nietkritische activiteiten worden bepaald. Hierbij wordt een onderscheid gemaakt tussen de vrije en de totale speling (Elmaghraby, 1970; Moder en Phillips, 1970). Buffa en Miller (1979) definiëren deze als: ‘Total slack means then that an activity has slack which is shared with other production factors. Free slack makes possible the delay of an activity without affecting the starting times of any other activity.’

De totale speling van een activiteit wordt vastgesteld door het verschil te nemen tussen het laatst mogelijk begin van de opvolgers en het vroegst mogelijke einde van de activiteit. De vrije speling is het verschil tussen de vroegst mogelijke start van de opvolgers en het vroegst mogelijke einde van de activiteit. Indien een koppeling wordt gemaakt met de opleverdata van de activiteiten, kan het zijn dat het vroegstmogelijke-einde eerder is dan de vereiste c.q. contractuele opleverdata. In dit geval hebben ook de activiteiten op het kritieke pad een speling ongelijk aan nul (Wiest and Levy, 1969). De beschikbaarheid van de gegevens omtrent de speling is van belang bij de allocatie van middelen en de scheduling, Elmaghraby (1995): ‘these floats play an important role in two issues of central concern to managers: resource allocation and activity scheduling, since floats give a measure of the flexibility in scheduling the activities during the project execution without delaying the project completion time.’

4.6.2 Program Evaluation and Review Technique In de vorige paragraaf is gesteld dat de onzekerheid omtrent de tijdschatting te reduceren is door het expliciet te koppelen aan de benodigde produktiemiddelen. Het betreft hier een poging om de kwaliteit van de schatting te vergroten. Daarnaast bestaat een methode waarbij niet één tijdsduur wordt geschat, maar waarbij een kansverdeling van de tijdsduur wordt gespecificeerd. PERT is met name toepasbaar indien de tijdsduur van de activiteiten onzeker is (Randolph en Posner, 1988). De onzekerheid wordt gemodelleerd met behulp van een kansverdeling. Een grotere standaarddeviatie van deze verdeling weerspiegelt een grotere onzekerheid omtrent de activiteitsduur. Op basis van een drietal schattingen wordt de verdelingsfunctie van de activiteitsduur geconstrueerd. PERT gaat hierbij uit van de Beta-verdeling69 (Sasieni, 1986; Sculli, 1989). De drie schattingen hebben betrekking op de meest 69 De kansverdeling, die de tijdsduur van een activiteit beschrijft, heeft de vorm van een Beta-verdeling. De Beta-verdeling wordt veelvuldig gebruikt in situaties waarin weinig data beschikbaar is. De Betafunctie heeft twee parameters α1 en α2, dit zijn beide 'shape'-parameters.

122

Hoofdstuk 4

waarschijnlijke, de langst denkbare en de kortst denkbare tijdsduur. De meest waarschijnlijke tijdsduur hoeft niet gelijk te zijn aan de gemiddelde tijdsduur. De langst mogelijke tijdsduur heeft betrekking op een situatie waarin alles tegenzit wat in een dergelijke situatie ook maar enigszins kan tegenzitten. De kortst mogelijke tijdsduur veronderstelt daarentegen dat alles soepel verloopt zonder tegenslagen. Aan de hand van deze drie tijdschattingen wordt een gemiddelde en een variantie bepaald (formule 1 en 2). Een activiteit met een grotere onzekerheid wordt gekarakteriseerd door een grotere variantie.

tv = Vt = tv to tp tm Vt

to + 4 * tm + tp 6 (t p − to ) 2 36

(1)

(2)

: verwachte waarde van de tijdsduur. : optimistische tijdschatting. : pessimistische tijdschatting. : meest waarschijnlijke tijdsduur. : variantie van de tijdsduur.

PERT wordt door weinig computerpakketten voor projectplanning ondersteund (Levine, 1986). Toch stelt Kidd (1989) dat projectmanagers behoefte hebben aan een analyse van de onzekerheden voorafgaand aan een project. PERT is dus gericht op het modelleren van de onzekerheid omtrent de activiteitsduur in de vorm van een verdelingsfunctie op basis van het gewogen gemiddelde van een drietal schattingen. Wanneer nu met dit gewogen gemiddelde (eq. 1) verder wordt gewerkt (uitgaande van de veronderstelling dat de geschatte tijdsduur van een activiteit gelijk is aan dit gewogen gemiddelde) kan vervolgens weer een kritiek pad worden berekend. Op basis van de tijdsduur van activiteiten en de variantie hiervan kan de kans worden berekend dat een activiteit op een bepaald moment is afgerond. Stel dat het kritieke pad70 een verwachte tijdsduur heeft van dertig dagen en een standaard deviatie van 2 dagen, dan is de kans dat het project binnen 35 dagen is afgerond P[ Z <= ((35-30) / 2)] = P[ Z <= 2,5] = 0,9938 (Ragsdale, 1989). Schonberger (1981) toont aan dat deze methode als nadeel heeft dat een vertekening van het gehele project plaatsvindt, omdat met sub-kritieke paden geen rekening wordt gehouden71. Wanneer de doorlooptijd van de sub-kritieke paden niet 70 Ragsdale (1989) wijst op het probleem dat het niet duidelijk is welk pad als kritiek pad aan te merken. Het kritieke pad kan worden gedefinieerd als het pad met hoogste verwachte waarde van de tijdsduur of het pad met de laagste kans dat het is afgerond op de beoogde datum. 71 Gong en Hugsted (1993) noemen dit de ‘merge event bias’. Zij beschrijven een ‘merge event time estimation technique’ teneinde in de analyse van het netwerk onzekerheden van zowel activiteiten op het kritieke pad als op de subkritieke paden te combineren. De uitkomsten van de analyses met behulp van deze techniek zijn vergelijkbaar met de uitkomsten van een netwerksimulatie.


123

veel afwijkt van die van het kritieke pad, kan een situatie optreden waarbij het subkritieke pad eigenlijk het kritieke pad vormt. Dit wordt veroorzaakt door de variabiliteit van de activiteitsduur (Wiest en Levy, 1970). Schonberger (1981) stelt dat naarmate meer activiteiten parallel worden uitgevoerd en naarmate de activiteitsduur een grotere variantie bezit, het verschil groter wordt tussen de daadwerkelijke projectduur en de duur volgens het deterministische kritieke pad. Een andere mogelijkheid is de projectduur met behulp van Monte Carlo Simulatie vast te stellen op basis van a-selecte trekkingen uit kansverdelingen van de tijdsduur van afzonderlijke activiteiten. Hiervoor moeten verschillende replicaties doorgerekend worden, omdat er sprake is van a-selecte trekkingen72 uit kansverdelingen. Door deze a-selecte trekkingen kan het kritieke pad per replicatie verschillen doordat de tijdsduur van individuele activiteiten per replicatie kan verschillen. Op basis van de kansverdelingen van de tijdsduur wordt de doorlooptijd van het gehele project en de mate van kritiek zijn van individuele activiteiten bepaald. De mate van kritiek zijn van een activiteit kan uitgedrukt worden in een 'criticality index'73 (Wiest and Levy, 1969; Pritsker en Sigal, 1990). Deze geeft aan in welk percentage van de replicaties een activiteit op het kritieke pad ligt. De criticality index geeft zo een indicatie van de mate waarin een activiteit kritiek kan zijn voor het gehele project. Het projectmanagement zal dan ook bijzondere aandacht dienen te besteden aan activiteiten die in hoge mate kritiek zijn (Dodin en Elmagrahby, 1985). Ondanks het voordeel dat PERT met een onzekere activiteitsduur rekening houdt, zijn er enkele problemen aan de methode verbonden: • PERT veronderstelt dat de activiteiten onderling onafhankelijk zijn (Wiest en Levy, 1969; Elmaghraby, 1970). Dit betekent dat een langer dan normale tijdsduur van de ene activiteit geen invloed heeft op de tijdsduur van een andere activiteit. In de praktijk zullen ze wel afhankelijk zijn doordat de activiteiten onder invloed staan van dezelfde factoren. • Het gebruik van PERT vereist de schatting van drie soorten tijdsduur: de meest waarschijnlijke tijdsduur, de kortst mogelijke tijdsduur en de langst mogelijke tijdsduur. Het is met name moeilijk een uitspraak te doen omtrent de laatste twee. Om een betrouwbare schatting te maken van deze tijden is veel ervaring nodig met voorgaande projecten. Een schatting van het absolute minimum en maximum is niet mogelijk (de kans op het optreden van het minimum of

72 Een methode om random waarden uit een beta-verdeling te genereren is gebaseerd op de samenhang tussen de Gamma- en Beta-verdeling. Deze methode is beschreven in (Law en Kelton, 1982). Als G1 ≈ gamma( α1 , 1 ) en G2 ≈gamma(α2 , 1) dan geldt dat beta(α1, α2) ≈ G1/(G1 + G2). Een Beta-waarde kan dus worden gegenereerd door twee trekkingen uit een gamma-verdeling. 73 Kuklan et al. (1993) herdefinieren de ‘criticality index’. De index is niet alleen afhankelijk van de vraag of de activiteit op het kritieke pad ligt, maar wordt ook beinvloed door de benodigde tijd onder tegenvallende omstandigheden, de extra tijd die nodig is om een hogere zekerheid van uitvoering te bewerkstelligen en de kans dat de activiteit is uitgevoerd binnen een maximaal toegestane tijd.

124

•

Hoofdstuk 4 maximum is nul, gegeven een continue verdeling van de doorlooptijd). Daarom wordt vaak de tijdsduur geschat waarbinnen 95 of 99% van de projecten vallen. Buffa en Miller (1979) wijzen op het gevaar dat er een idee van nauwkeurigheid wordt opgeroepen dat niet waargemaakt kan worden: ‘The PERT computational algorithm reduces these 3 time estimates to a single average time estimate, the mean of a beta distribution. The output is no better than the input data and there is a danger that the very existence of the precise probability statements tends to give an aura of accuracy which may not necessarily be justified.’

•

•

Het gebruik van simulatie om een netwerk door te rekenen kent enkele nadelen ten opzichte van de traditionele kritieke-pad-methode (Schonberger, 1981). Ten eerste geldt dat het toepassen van simulatie meer moeite kost omdat er diverse iteraties nodig zijn om de mate van kritiek zijn van activiteiten te berekenen. Ten tweede geldt dat simulatie moeilijker is te begrijpen. Veel project managers hebben slechts een vaag begrip van kansverdelingen. Om aan deze bezwaren tegemoet te komen zijn er diverse benaderingswijzen ontwikkeld om de mate van kritiek zijn van activiteiten te benaderen zonder gebruik te maken van een simulatiemodel (zie Gong en Hugsted, 1993; Dodin en Elmaghraby, 1985). PERT is geschikt voor het omgaan met een onzekere activiteitsduur, teneinde de doorlooptijd van het project te berekenen, of deze met behulp van simulatie vast te stellen. De methode is echter niet geschikt voor de toewijzing van produktiefactoren. De onzekerheid maakt een éénduidige toewijzing van produktiefactoren aan activiteiten en de koppeling van specifieke uitvoeringsmomenten aan de activiteiten onmogelijk.

4.6.3 Scheduling Na het schatten van de tijdsduur en het vaststellen van de benodigde produktiefactoren kan blijken dat zich bepaalde knelpunten voordoen. Activiteiten die gegeven hun logische samenhang gelijktijdig kunnen worden uitgevoerd, kunnen in de uitvoering worden belemmerd door capaciteitsrestricties. Twee activiteiten die dezelfde beperkt beschikbare produktiefactor nodig hebben, moeten achter elkaar worden uitgevoerd. De mate waarin knelpunten optreden, zal afhankelijk zijn van de mate van capaciteitsrestricties van de produktiefactoren. Bij fysieke projecten kunnen produktiefactoren zoals personeel, machines, grondstoffen etc. capaciteitsrestricties vormen, bij software-ontwikkelingsprojecten is met name het personeel een restrictiefactor. Indien de activiteiten wegens capaciteitsrestricties niet gelijktijdig in uitvoering kunnen worden genomen, dient te worden bepaald welke activiteit op welk moment in uitvoering wordt genomen. Hierbij moet uiteraard rekening worden gehouden met de gespecificeerde opeenvolgingsrelaties en de middelen die nodig zijn om een activiteit uit te voeren. Dit zogenaamde ‘resource constrained project scheduling’ wordt gedefinieerd als (Boctor, 1990):


125

‘Given a set of interrelated activities (precedence relations) where each activity can be performed in one of several modes (ways), each mode is characterised by a known duration and given resource requirements, when should each activity begin and which resource-duration mode should be adopted so as to optimize some managerial objective? Obviously the solution has to respect the precedence relations and resource limits.’

De in deze definitie genoemde managerial objectives kunnen bijvoorbeeld betrekking hebben op (Elmaghraby, 1995, Boctor 1990; Elmaghraby en Herroelen, 1990): • het minimaliseren van de doorlooptijd van het project, • het minimaliseren van de totale projectkosten, • het maximaliseren van de netto contante waarde, • minimalisatie van het maximale middelengebruik, • het vereffenen van het middelen gebruik, • het minimaliseren van de kosten van het middelengebruik. Bij de middelen kan onderscheid worden gemaakt naar situaties waarin de middelen eenmalig of meermalig kunnen worden gebruikt. Menskracht kan elke periode opnieuw worden ingezet. Een heipaal voor het bouwen van een huis kan slechts één keer worden gebruikt. Daarnaast kan onderscheid worden gemaakt tussen situaties waarin een plan voor één project of voor meerdere projecten (Kurtulis en Davis, 1982; Tsubakitani en Deckro, 1990) wordt opgesteld. Het probleem van de optimale middelentoewijzing en activiteitenscheduling onder de voorwaarde van de gespecificeerde opeenvolgingsrelaties is bijzonder complex (Elmaghraby, 1995). Het vinden van een optimale oplossing zal bij grotere problemen veel tijd in beslag nemen en zal al snel onmogelijk worden (Russell, 1986). Praktische problemen worden daarom middels heuristieken opgelost. Willis (1985) omschrijft het principe van deze heuristieken als: ‘The idea behind heuristic algorithms for resource constrained project scheduling is to rank the activities by some rule- this may be managerial priority, earliest start times, most resource ‘greedy’ or any other project related value, and to schedule the activities in that ranking order ensuring that the resource limits on the project are never exceeded’

De heuristische regels kunnen betrekking op verschillende aspecten van de betrokken activiteiten. Voorbeelden van deze heuristische regels zijn (Boctor, 1991; Kurtulis en Davis, 1982; ): • activiteiten met de minste speling het eerst • activiteiten met de laagste laatst mogelijk einddatum eerst • random volgorde • activiteiten die het grootst aantal middelen nodig hebben eerst • activiteiten met de kortste tijdsduur eerst

126

Hoofdstuk 4 • •

activiteiten met laagste middelenbehoefte eerst activiteiten met de langste tijdsduur eerst

Boctor (1991) vergelijkt de verschillende regels en concludeert dat specifieke combinaties van de hiervoor genoemde heuristieken de beste resultaten opleveren. Het probleem hierbij is echter dat er niet één combinatie van regels bestaat die in alle gevallen het beste presteert. De karakteristieken van het te plannen project zijn bepalend voor de optimale combinatie van regels (Kurtulis en Davis, 1982). Kurtulis en Davis operationaliseren deze karakteristieken aan de hand van twee variabelen. De ‘average resource load factor’ die aangeeft waar de piek in het middelenverbruik op het kritieke pad ligt en de ‘average utilization factor’ die aangeeft hoe knellend de capaciteitsrestricties voor de verschillende middelen zijn. Deze twee kenmerken kunnen vervolgens worden gebruikt bij het selecteren van heuristische regels. 4.6.4 Kostenbegrotingen De in de vorige paragrafen besproken methoden zijn met name gericht op de beheersing van tijdaspecten van het project. De indeling van de activiteiten in de loop van de tijd, gegeven de opeenvolgingsrelaties en de benodigde produktiefactoren, speelt hierbij een belangrijke rol. Daarnaast zullen in een project uitspraken gedaan moeten worden over de kosten die samenhangen met de uitvoering van dit project. Het kosten-aspect wordt in de komende paragrafen uiteengezet. Het doen van uitspraken over de kosten van een project op basis van een activiteitennetwerk veronderstelt dat er reeds beslissingen zijn genomen ten aanzien van de inrichting van dit netwerk. De kosten van een project kunnen op verschillende momenten en op verschillende manieren worden bepaald. In sommige gevallen zal een offertecalculatie worden gemaakt. Het is dan (nog) niet zinvol om een gedetailleerd plan op te stellen. Wanneer de offertecalculatie gebaseerd is op meer globale gegevens zullen diverse veiligheden zijn ingebouwd om onzekerheden te ondervangen. Dit kan door speling in de vorm van opslagpercentages in te bouwen. De offertecalculatie op een globaal niveau zal plaatsvinden aan de hand van globale vuistregels op basis van ervaringen met voorgaande projecten. Ongeacht de vraag of een offertecalculatie is gemaakt, zal bij de uiteindelijke opstelling van een projectplan een gedetailleerde kostenbegroting moeten worden gemaakt. De kosten van een project zijn voor een groot deel uit een activiteitennetwerk af te leiden. Immers, indien een netwerk is opgesteld, kunnen de kosten worden bepaald aan de hand van de in het plan gebruikte produktiefactoren en de tijdsduur van dit gebruik. Bij het schatten van de tijdsduur van individuele activiteiten is een koppeling met het gebruik van produktiefactoren voorgesteld. In de huidige projectmanagementpakketten vindt de vaststelling van de kosten plaats door de aan de diverse activiteiten toegewezen produktiefactoren te vermenigvuldigen met het tarief van deze factor. Hierbij is sprake van bottom-up vaststelling van de kosten. Vanuit de kosten van individuele activiteiten worden de kosten van de verschillende fasen en de kosten van het gehele project bepaald door middel van aggregatie over de afzonderlijke activiteiten en fasen. In tegenstelling tot


127

deze aanpak worden de kosten in veel begrotingsmodellen top-down vastgesteld. Uitgaande van een schatting van de kosten van het gehele project worden de kosten verbijzonderd naar de diverse fasen van het project door het toepassen van bepaalde verhoudingscijfers. Bij de kostencalculatie wordt gebruikgemaakt van diverse tarieven. Het is hierbij van belang na te gaan, hoe een tarief tot stand is gekomen. Zolang de capaciteit rationeel is zullen de ongebruikte produktiefactoren moeten worden doorberekend. De werkelijke kosten van de produktiefactoren zullen over het normale aantal declarabele uren worden omgeslagen. Het tarief moet zijn gebaseerd op de totale kosten gedeeld door het normale aantal uren. De in een netwerk uitgezette activiteiten hebben met name betrekking op de uitvoerende taken binnen een project. Naast deze taken zijn er beheersmatige activiteiten te onderscheiden. Deze categorie van activiteiten is er op gericht het project, en dus de inhoudelijke taken, doelmatig en doelgericht te laten verlopen. Indien in het netwerk uitsluitend de uitvoerende taken worden afgebeeld, zal de kostenaggregatie geen goed beeld geven van de werkelijke kosten. Een expliciete specificatie van deze activiteiten zal nodig zijn indien men de kosten middels de hiervoor beschreven aggregatie wil berekenen. Een andere manier om deze beheersmatige activiteiten in de uiteindelijke kostenschatting op te nemen is het verwerken van deze kosten in een opslag. Over de kosten van de uitvoerende taken wordt dan een opslag gelegd die de management- en marketingkosten moet afdekken. 4.6.5 Begrotingsmodellen Naast het op basis van een netwerkspecificatie op een bottom-up manier vaststellen van de kosten van een project zijn er andere mogelijkheden om een uitspraak te doen over de kosten van een project. Met behulp van formele en informele beslissingsregels kan een specificatie van de kosten en doorlooptijd worden gemaakt. De beslissingsregels zijn gebaseerd op het aantal regels programma-code of op de functionaliteit van het te ontwikkelen programma in samenhang met een maatstaf voor de complexiteit en de onzekerheid van een project. In het verlengde hiervan zijn in de literatuur diverse begrotingsmodellen beschreven. Deze modellen zijn over het algemeen sterk geaggregeerd waarbij een schatting wordt gemaakt van de kosten en de doorlooptijd van het gehele project op basis van een of meerdere onafhankelijke variabelen, zoals het aantal regels code of de functionaliteit van het systeem. De begrotingsmodellen zijn in de regel gebaseerd op historische data. Aan de hand van de gegevens van oude projecten wordt de invloed van bepaalde factoren vastgesteld. Dit heeft als nadeel dat de projectgegevens veel ruis bevatten. Achteraf moet worden vastgesteld wat nu precies de invloed van de verschillende factoren is geweest, terwijl de gegevens waarschijnlijk niet voor dit doel zijn vastgelegd. De modellen bevatten vaak waarden die zijn geschat op basis van projecten van andere organisaties. Het is de vraag of de gegevens van die organisaties klakkeloos op de eigen situatie kunnen worden toegepast. Om het model toe te spitsen op de specifieke situatie van de eigen

128

Hoofdstuk 4

organisatie moeten de parameters worden gekalibreerd en de waarden van het model moeten worden aangepast aan de specifieke ontwikkelkarakteristieken van de eigen organisatie. Het maken van een schatting van de kosten en doorlooptijd kan worden gesplitst in het maken van een schatting van de omvang van het uit te voeren werk en een schatting van de produktiviteit waarmee dit werk zal worden uitgevoerd. In de meeste modellen wordt naast de omvang gebruikgemaakt van factoren die de produktiviteit beïnvloeden. Er zijn veel factoren die de kosten van een softwareontwikkelingsproject beïnvloeden. Voorbeelden van groepen van dergelijke factoren zijn: middelenafhankelijke factoren, produktafhankelijke factoren, personeelsafhankelijke factoren en procesafhankelijke factoren (Boehm, 1980). 4.6.6 Specifieke begrotingsmodellen In de loop van de tijd zijn diverse modellen ontwikkeld voor het schatten van de inspanning voor de ontwikkeling van informatiesystemen (Albrecht en Gaffney, 1983; Van Vliet en Heemstra, 1988; Van Vliet, 1988; Rowold, 1989; Heemstra, 1989; Pottjegort, 1992). Bekende voorbeelden hiervan zijn Cocomo en FPA. Cocomo Het Cocomo-model is een door Boehm (1981) ontwikkeld model voor de schatting van het aantal mensmaanden dat nodig is voor de ontwikkeling van een informatiesysteem. Op basis daarvan kan een schatting van de kosten en de doorlooptijd van software-ontwikkelingsprojecten worden gemaakt. Het Cocomomodel is een mathematisch model waarbij de schatting is gebaseerd op het aantal regels programmacode van het te ontwikkelen systeem. Boehm maakt een onderscheid naar drie situaties waarbinnen software kan worden ontwikkeld: de organic mode, de semi-detached mode en de embedded mode. In de organic mode wordt het informatiesysteem relatief onafhankelijk van andere systemen ontwikkeld. Daarentegen is in de embedded mode sprake van een grote complexiteit door een verwevenheid met andere (deel-)systemen. In de semi-detached mode is er sprake van een situatie tussen deze beide uitersten. De mode is van invloed op de waarden van de parameters die binnen het model worden gebruikt. Drie varianten van het Cocomo-model Eigenlijk is er bij het Cocomo-model niet sprake van één model, maar bestaat het model uit een drietal modellen. Het basic Cocomo-model maakt uitsluitend een schatting op basis van het aantal te ontwikkelen regels code. Het intermediate Cocomo-model voegt hier een groot aantal factoren aan toe die de produktiviteit beïnvloeden. Dit zijn de zogenaamde cost-drivers. De eerste globale schatting op basis van het aantal regels code wordt gecorrigeerd aan de hand van deze costdrivers. Het detailed Cocomo-model specificeert schattingen per component. Detailed Cocomo-model Het detailed Cocomo-model gaat uit van het aantal te ontwikkelen regels code. Op basis van dit aantal wordt vervolgens een schatting van de kosten en doorlooptijd


129

gemaakt. Hieronder is de formule voor het schatten van de inspanning uitgedrukt in het aantal mensmaanden, en de formule voor de bepaling van de doorlooptijd van het project op basis van het aantal mensmaanden afgebeeld.

MM = a KLOC T MM KLOC T a,b,c,d

= c MM

b

d

: aantal mensmaanden : aantal duizenden regels : doorlooptijd : parameters.

Het aantal mensmaanden dat nodig is voor het ontwikkelen van het systeem wordt geschat aan de hand van het aantal regels code. De doorlooptijd wordt vervolgens geschat op basis van het aantal mensmaanden. De waarden van de parameters die binnen het model worden gebruikt zijn afhankelijk van de typering van het project. De waarden voor de verschillende modi zijn in Tabel 4-1 afgebeeld. Tabel 4-1: parameterwaarden voor de drie Cocomo-modellen. Mode Organic Semi-detached Embedded

a 3.2 3.0 2.8

b 1.05 1.12 1.20

c 2.5 2.5 2.5

d 0.38 0.35 0.32

De b-parameter is voor alle 3 situaties groter dan 1. Dit betekent dat de benodigde inspanning, uitgedrukt in het aantal mensmaanden, meer dan evenredig stijgt met het aantal regels code. Er is dus sprake van een afnemende produktiviteit bij een stijgende omvang van het aantal regels. Dit kan ondermeer worden verklaard uit de toename van het coördinatieprobleem, doordat het werk van meer mensen op elkaar moet worden afgestemd. Intermediate Cocomo-model Het intermediate Cocomo-model betrekt andere factoren dan alleen het aantal regels code in de schatting. Het aantal regels code blijft wel het uitgangspunt, maar wordt gecorrigeerd voor factoren die de produktiviteit beïnvloeden. Bij het maken van een schatting moet worden aangegeven in welke mate een factor van invloed is op het project. De beoordeling wordt vervolgens omgezet in een vermenigvuldigingsfactor (zie Tabel 4-2). Het produkt van alle waarden van alle factoren wordt vervolgens gebruikt als correctie op de eerste globale schatting, die uitsluitend op het aantal regels code is gebaseerd.

130

Hoofdstuk 4

Tabel 4-2: Cocomo-factoren. FACTORNAAM betrouwbaarheid grootte database complexiteit beperkingen executietijd geheugen beperkingen wijzigingen hardware verwerkingssnelheid jobs capaciteit analisten ervaring met toepassing capaciteit programmeurs ervaring met software ervaring met taal moderne programmeertechnieken gebruik hulpmiddelen planning eisen

ZEER LAAG 0.75

LAAG

NORMAAL

HOOG

0.70

0.88 0.94 0.85

1.46 1.29 1.42 1.21 1.14 1.24

0.87 0.87 1.19 1.13 1.17 1.10 1.07 1.10

1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00

1.15 1.08 1.15 1.11 1.06 1.15 1.07 0.86 0.91 0.86 0.90 0.95 0.91

1.24 1.23

1.10 1.08

1.00 1.00

0.91 1.04

ZEER HOOG 1.40 1.16 1.30 1.30 1.21 1.30 1.15 0.71 0.82 0.70

0.82 0.83 1.10

Detailed Cocomo-model De voorgaande modellen maken een schatting van de inspanning en de doorlooptijd van het gehele project. Deze schatting kan eventueel via een verdeelsleutel over de verschillende fasen worden verdeeld. Het meest gedetailleerde Cocomo-model beschouwt het te ontwikkelen systeem als opgebouwd uit een aantal componenten. Er wordt een schatting gemaakt per component, zodat verschillen tussen de componenten voor wat betreft de beïnvloedingsfactoren beter worden verwerkt. Problemen rond het Cocomo-model Het Cocomo-model is gebaseerd op het aantal regels code van het te ontwikkelen systeem. Deze maatstaf brengt een aantal problemen met zich mee: • Ten eerste is het niet altijd duidelijk wat onder een regel code moet worden verstaan (Low en Jeffery, 1990). Moeten regels commentaar, blanco regels en regels met declaraties worden meegeteld of juist niet? • Ten tweede is de schatting van het aantal regels code niet eenvoudig. In het voortraject van de systeemontwikkeling, wanneer er nog geen gedetailleerd ontwerp is gemaakt, is het bijna ondoenlijk het aantal regels code te schatten. Pas na de afronding van het technisch ontwerp kan een goede en betrouwbare uitspraak over het aantal regels code worden gedaan. Daarnaast is er kritiek mogelijk op de constructie van het Cocomo-model. Voor het schatten van de beïnvloedingsfactoren is gebruikgemaakt van de gegevens van 80 projecten. Gegeven het aantal parameters dat moeten worden geschat en de vuistregel dat er minimaal vijf waarnemingen per parameter nodig zijn voor een betrouwbare schatting, moet worden geconcludeerd dat de beschikbare gegevens niet voldoende zijn. Daarnaast geldt dat de projecten waarop de parameters zijn


131

gebaseerd sterk uiteenlopen. Dit maakt het maken van betrouwbare schattingen moeilijk. Ook is het gezien de aard van de factoren waarschijnlijk dat er een samenhang bestaat tussen de diverse factoren. Indien er een correlatie bestaat tussen de factoren is het moeilijk een betekenis toe te kennen aan de waarden van de parameters. De mate waarin een individuele variabele een bijdrage levert aan de verklaring van de te verklaren variabele is dan onduidelijk. Het gebruik van deze en andere begrotingsmodellen geeft geen antwoord op de vraag hoe de produktiefactoren te alloceren. Wanneer de doelstelling de allocatie van middelen omvat moet een andere methode (al dan niet in samenhang met het begrotingsmodel) worden toegepast. De begrotingsmodellen kunnen daarbij worden gebruikt voor het maken van een schatting van de kosten en doorlooptijd. Deze gegevens kunnen vervolgens worden gebruikt bij het specificeren van bijvoorbeeld een activiteitennetwerk. Functiepuntanalyse In de vorige paragraaf zijn een aantal problemen geschetst die gelden voor het maken van schattingen op basis van het aantal regels code. Als reactie op deze problemen zijn er modellen ontwikkeld die zijn gebaseerd op andere maatstaven. Een van deze alternatieve modellen is functiepuntanalyse (Albrecht, 1979; Albrecht en Gaffney, 1983) waarbij een schatting wordt gemaakt op basis van de functionaliteit van het systeem (zie Figuur 4-9). Invoer functies

Uitvoer functies

Bepaal aantal bruto FP factoren

bestanden

Bepaal aantal netto FP interfaces

prod. cijfers

triggers

Bepaal aantal uren

Figuur 4-9: Functiepuntanalyse

132

Hoofdstuk 4

Een voordeel van deze methode is dat in het project eerder een beeld van de functionaliteit van het te ontwikkelen systeem beschikbaar is dan van het aantal regels code. Na de fase van het functioneel ontwerp is al een volledige beschrijving van de functionaliteit beschikbaar. Een betrouwbare schatting van het aantal regels code is pas na het technisch ontwerp mogelijk. Low en Jeffery (1990, pag. 71) concluderen op basis van een experiment: ‘Function points counts appear to be a more consistent a priori measure of software size than source line of code’

Dit verschil wordt door hen verklaard uit het feit dat schattingen van het aantal regels code niet gebaseerd zijn op regels of procedures maar op ervaringen met historische projecten. Functiepunt-schattingen, daarentegen, zijn gebaseerd op regels zoals die zijn beschreven door Albrecht (1979). Kemerer en Porter (1992) concluderen uit hun case-studie dat FPA-schattingen betrouwbaarder zijn dan gewoonlijk wordt gedacht . Toepassen van FPA Het oorspronkelijke doel van FPA was het aanbieden van een betrouwbare maatstaf voor het meten van de produktiviteit van de software-ontwikkeling en een manier om de ontwikkelingen in de produktiviteit in de loop van de tijd te kunnen volgen. Low en Jeffery (199) beschrijven het verloop van het a posteriori gebruik van de methode naar het maken van a priori schattingen. ‘This a posteriori use of function points appears to be the starting point in many organizations for the use of functions points in project management. Once this relationship between function points and hours worked has been determined the next step taken is to estimate a project’s size in function points and then use the predetermined relationship to predict anticipated work hours.’

FPA schat de omvang van het uit te voeren werk op basis van de beoogde functionaliteit (zie Figuur 4-9). Hierbij wordt de functionaliteit gedefinieerd op basis van vijf functies: invoer, uitvoer, bestanden, triggers en interfaces. Bruto functiepunten Bij het gebruik van FPA moet het aantal functies van elk type worden aangegeven. Vervolgens moet de complexiteit van elke functie afzonderlijk worden beoordeeld. Door voor elk type functie de complexiteit van de individuele functies te vermenigvuldigen met de bijbehorende complexiteitsfactor en vervolgens deze over de functies binnen een type en vervolgens over de verschillende type functies op te tellen, resulteert het bruto aantal functiepunten. Per type functie moet dus worden aangegeven hoeveel functies er binnen het systeem gerealiseerd moeten worden. Tevens moet worden aangegeven hoe complex iedere functie is. Hierbij bestaat de keuze uit eenvoudig, gemiddeld of complex. In een tabel kan vervolgens worden opgezocht hoeveel functiepunten een dergelijke functie representeert (zie Tabel 4-3).


133

Tabel 4-3: Functiepunten per functie van een gegeven type en complexiteit Functie type Invoer Uitvoer Bestanden Triggers Interfaces

eenvoudig 3 4 7 3 5

gemiddeld 4 5 10 4 7

complex 6 7 15 6 10

Uit de beschrijving van de factoren blijkt dat FPA met name is gericht op administratieve systemen. Bij systemen waarbij meer de nadruk ligt op rekenkundige en logische bewerkingen en minder op de in- en uitvoer geeft FPA geen goed beeld van de functionaliteit. Wel is er steeds meer aandacht in de literatuur voor het toepassen van FPA in andere omgevingen. Netto functiepunten Daarnaast zijn een veertiental factoren gedefinieerd die als correctie op het aantal bruto functiepunten worden gebruikt. De factoren die hiervoor zijn gedefinieerd zijn (zie o.a. Pottjegort, 1992): Tabel 4-4: Produktiviteitsbeinvloedende factoren. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.

Factor Invoer / uitvoer door middel van datacommunicatie. Informatiesysteem maakt gebruik van distributed data processing. Eisen aan performance/responsietijd. Eisen aan computergeheugen en processing tijd. Aantal transacties Gebruik van on-line data entry. Invoer/uitvoer is conversationeel. Databases worden on-line bijgewerkt. Complexiteit van het informatiesysteem. Mate van hergebruik van software componenten. Complexiteit van conversie en implementatie. Bedieningsgemak. Geïnstalleerd op meerdere plaatsen. Aanpasbaarheid van het informatiesysteem.

Voor een specifiek project moeten deze factoren worden beoordeeld. Voor elke factor of cost driver moet op een schaal van 0 tot 5 worden aangegeven in welke mate de factor van invloed is op de te leveren inspanning. De totale invloed heeft dus een bereik van 0 tot 70 (14 keer de score 0, respectievelijk 14 keer de score 5). De correctiefactor wordt berekend door de totale invloed te delen door 100 en deze op te tellen bij 0.65.

134

Hoofdstuk 4

Netto aantal functiepunten = bruto aantal functiepunten * correctiefactor invloed) Correctiefactor = 0.65 + (totale100

Het gemiddelde van het bereik van de totale invloed van de cost-drivers levert dus de waarde van één op voor de correctiefactor (gemiddelde invloed (14 * 0 + 14 * 5) / 2 = 35). De correctiefactor die resulteert moet vervolgens worden vermenigvuldigd met het bruto aantal functiepunten. Dit resulteert in het netto aantal functiepunten. Het netto aantal functiepunten moet vervolgens worden omgezet in een schatting omtrent het benodigde aantal mensmaanden. Voor deze omrekening schrijft FPA zelf geen waarden voor. De omrekening kan het beste plaatsvinden aan de hand van gegevens van uitgevoerde projecten binnen de eigen organisatie. Door gegevens van historische projecten te registreren, kan een organisatie een goed beeld opbouwen van de benodigde inspanning per functiepunt. Problemen rond Functiepuntanalyse Gegeven de functies waarop FPA is gebaseerd, kan gesteld worden dat de techniek voornamelijk geschikt is voor het schatten van administratieve systemen. De interne complexiteit van een systeem komt onvoldoende tot uitdrukking bij het vaststellen van het aantal functiepunten (Symons, 1988). Dit is op zich geen bezwaar zolang men zich deze beperking maar realiseert bij het gebruik74. Het beoordelen van het gewicht van een beïnvloedingsfactor bij een specifiek project is niet altijd even eenvoudig. Om tegemoet te komen aan deze bezwaren zijn er hulpmatrices ontwikkeld, die de beoordeling van een functie moeten verbeteren. Een hulpmatrix voor de classificatie van de uitvoer is bijvoorbeeld: Tabel 4-5: hulpmatrix voor de classificatie van de complexiteit van de uitvoerfunctie.

Ð

Aantal velden bestanden 1 2 of 3 >3

Î

1-6

6 - 19

>19

eenvoudig eenvoudig gemiddeld

eenvoudig gemiddeld complex

gemiddeld complex complex

De beïnvloeding van de overige factoren is gelimiteerd tot plus of min 35% van het aantal bruto functiepunten. Als alle cost-drivers worden aangemerkt als niet van belang zijnde dan heeft de correctiefactor een waarde van 0.65. Indien alle costdrivers van groot belang worden geacht heeft de factor een waarde van 1.35. De vraag is in hoeverre het bereik van deze correctiefactor reëel is. Wanneer de organisatie over gegevens beschikt van historische projecten kan dit bereik worden geëvalueerd en eventueel worden aangepast.

74 Onvlee en Siskens (1992) tonen aan dat FPA door enkele wijzigingen wel toepasbaar is bij het vaststellen van het aantal functiepunten van Computer Aided Manufacturing Software.


135

Symons (1988) stelt dat het classificeren van een functie als eenvoudig, gemiddeld of complex, het probleem te eenvoudig weergeeft. Een functie die betrekking heeft op 100 data elementen krijgt bijvoorbeeld maar twee keer zo veel functiepunten als een functie die slechts één data-element omvat. Verder stelt Symons vragen bij de algemene toepasbaarheid van de gewichten (punten per functie) zoals die door Albrecht zijn gespecificeerd. Deze gewichten zijn vastgesteld door - zoals Albrecht het formuleert - ‘discussion and trial’.

4.7 Conclusies In dit hoofdstuk is gebleken dat er een groot aantal methoden beschikbaar is voor de projectplanning. Ondanks het grote aantal Operations Research methoden worden slecht weinig van deze methoden gebruikt (Schelle, 1990; Brandenberger, 1990). Deze conclusie kan eveneens worden getrokken op basis van de case beschrijvingen (zie Appendix A, en paragraaf 5.3). De belangrijkste redenen voor het niet gebruiken van de methoden zijn: een gebrek aan kennis, een gebrek aan training en opleiding, de complexiteit van de modellen die ten grondslag liggen aan deze methoden, gebrekkig onderzoek naar de gebruikersbehoeften, het niet beschikbaar zijn van de vereiste gegevens en tenslotte de hoge kosten die samenhangen met het toepassen van de OR methoden. Schelle (1990) concludeert dat er ruimte is voor de ontwikkeling en toepassing van nieuwe methoden. Met name wanneer deze methoden systematisch gebruikmaken van kennis en ervaring van de managers. Rich en Waters (1992) stellen dat software engineering tools krachtiger worden indien deze kennisintensief zijn. Wij zijn van mening dat hetzelfde geldt voor een sub-set van deze tools, namelijk de tools voor de planning en beheersing van projecten. Het onderontwikkeld zijn van het gebruik van planningmethoden in projectplanning is vooral een gevolg van de beperkte hoeveelheid formele regels die zijn ondergebracht in de planningmethoden. Naast de formele regels spelen ook de informele regels een belangrijke rol. Op taakniveau spelen bijvoorbeeld allerlei ervaringen met voorgaande projecten een rol. Op basis van die ervaringen kan de planner een uitspraak doen over de capaciteitsbehoefte, de tijdsduur en andere aspecten van een taak van het nieuwe project. Projectplanning zonder domeinkennis is welhaast onmogelijk. Zoals uit de in het volgende hoofdstuk beschreven cases zal blijken, spelen op vele plaatsen in het beslissingsproces naast de methoden ook (informele) beslissingsregels een belangrijke rol. Informatiesystemen die uitsluitend de methoden beschikbaar stellen vergen dus veel kennis bij de gebruiker van het planningproces en de planningmethoden. De methoden besteden nauwelijks tot geen aandacht aan de domeinkennis. Zoals wij eerder hebben gesteld zijn er pogingen gedaan om domeinkennis te modelleren met behulp van meer traditionele methoden. Constraint Satisfaction Programming (CSP) biedt bijvoorbeeld de mogelijkheid domeinkennis te modelleren in de vorm van kwalitatieve restricties (zie bijvoorbeeld Raghunathan, 1992). Deze regels worden dan omgezet in bepaalde randvoorwaarden. CSP is met name gericht op het zoeken naar een oplossing gegeven een gedefinieerde probleemruimte. Hierbij wordt een vorm van

136

Hoofdstuk 4

algortimische rationaliteit gehanteerd waarbij wel opgemerkt dient te worden dat de verzameling van randvoorwaarden die gemodelleerd kan worden groter is dan in traditionele OR methoden. Een andere aanpak tot het modelleren van domeinkennis in constraints als invoer voor een LP model vindt men in het proefschrift van Van Dam (1995). Deze manieren van aanpak leveren een verrijking van het model. Deze verrijking is gericht op kennis die gebruikt wordt bij het zoeken naar een oplossing. De relatie met de informele regels kan nauwelijks of niet worden gelegd. In onze aanpak staat het procedureel rationeel handelen centraal waarbij de ondersteuning ook in de andere fasen van het planningproces wordt toegepast. In het volgende hoofdstuk beschrijven wij het ontwerp en het prototype van een systeem ter ondersteuning van de projectplanning die zowel gebruikt maakt van de domeinkennis als van de beschikbare methoden. Hiertoe wordt gebruikgemaakt van de in dit hoofdstuk beschreven methoden en de in hoofdstuk 3 beschreven integratie van generieke decision support systemen en kennissystemen.

Hoofdstuk 4 Projectplanning en softwareprojecten

Recommend Documents