Hoofdstuk 4 Projectplanning en softwareprojecten

Maat: px
Weergave met pagina beginnen:

Download "Hoofdstuk 4 Projectplanning en softwareprojecten"

Transcriptie

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Evo Evolutionary Project Management. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Evo Evolutionary Project Management. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Evo Evolutionary Project Management Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. INLEIDING... 3 2. EVO... 4 3. FASERING...

Nadere informatie

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces Software Processen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Het software proces Een gestructureerd set van activiteiten nodig om een software systeem te ontwikkelen Specificatie;

Nadere informatie

SDM II - System Development Methodology II. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

SDM II - System Development Methodology II. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. SDM II - System Development Methodology II Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 12 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2

Nadere informatie

Competenties met indicatoren bachelor Civiele Techniek.

Competenties met indicatoren bachelor Civiele Techniek. Competenties met indicatoren bachelor Civiele Techniek. In de BEROEPSCOMPETENTIES CIVIELE TECHNIEK 1 2, zijn de specifieke beroepscompetenties geformuleerd overeenkomstig de indeling van het beroepenveld.

Nadere informatie

Functiepuntanalyse. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

Functiepuntanalyse. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. Functiepuntanalyse Een introductie Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3 2 WAT

Nadere informatie

voorbeeldexamen Information Systems Foundation

voorbeeldexamen Information Systems Foundation voorbeeldexamen Information Systems Foundation I-Tracks voorbeeldexamen ISyF Information Systems Foundation uitgave oktober 2003 inhoud 3 inleiding 4 examenvragen 11 antwoordindicatie eerste uitgave oktober

Nadere informatie

IV SDM - FASE 2 BASISONTWERP

IV SDM - FASE 2 BASISONTWERP IV SDM - FASE 2 BASISONTWERP IV.1 Inleiding Zoals reeds besproken onderkent het in Nederland veel gebruikte SDM II (System Development Methodology, versie II), bij de bouw van informatiesystemen de volgende

Nadere informatie

Socio-technisch systemen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1

Socio-technisch systemen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1 Socio-technisch systemen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1 Systeem categoriën Technische op computer gesteunde systemen Systemen die HW en SW bevatten, maar waar

Nadere informatie

GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter

GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter 2 Opdrachtgever : Opdrachtnemers : Ing. P. van den Berg Michel van Reenen Thijs Mommen GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter

Nadere informatie

TESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE. 1. Inleiding. 2. TMap methode. Kwaliteit zonder gestructureerd testen is toeval.

TESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE. 1. Inleiding. 2. TMap methode. Kwaliteit zonder gestructureerd testen is toeval. TESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE Kwaliteit zonder gestructureerd testen is toeval Inhoudsopgave 1. Inleiding 2. De TMap methode 3. De fase Planning & Beheer 4. De fase testspecificatie 5. De

Nadere informatie

De strategische keuzes die moeten gemaakt worden zijn als volgt: Interne controle of zelfcontrole/sociale controle

De strategische keuzes die moeten gemaakt worden zijn als volgt: Interne controle of zelfcontrole/sociale controle 1 Hoofdstuk 1 1.1 Dirigeren en coördineren p43 1.1.1 Dirigeren Dirigeren is een synoniem voor delegeren. Dirigeren houdt in dat bepaalde bevoegdheden overgedragen worden naar een persoon met een lagere

Nadere informatie

RAD Rapid application development. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

RAD Rapid application development. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. RAD Rapid application development Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER...

Nadere informatie

Ontwikkelaar ICT. Context. Doel

Ontwikkelaar ICT. Context. Doel Ontwikkelaar ICT Doel Ontwikkelen en ontwerpen van ICT-producten, binnen overeen te komen dan wel in een projectplan vastgelegde afspraken ten aanzien van tijd, budget en kwaliteit, opdat overeenkomstig

Nadere informatie

Functioneel ontwerp. Een introductie. Algemene informative voor medewerkers van SYSQA B.V. Almere

Functioneel ontwerp. Een introductie. Algemene informative voor medewerkers van SYSQA B.V. Almere Functioneel ontwerp Een introductie Algemene informative voor medewerkers van SYSQA B.V. Almere Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 Inleiding... 3 1.1 Algemeen... 3 2 Inleiding... 4 2.1

Nadere informatie

Scrum. Een introductie

Scrum. Een introductie Organisatie SYSQA B.V. Pagina 1 van 10 Scrum Een introductie Almere 1999 Proud of it Pagina 1 van 10 Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 Inleiding... 3 2 Scrum... 4 3 Scrum rollen...

Nadere informatie

Agile systeemontwikkeling. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Agile systeemontwikkeling. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Agile systeemontwikkeling Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding... 3 2. Terminologie... 4 3. Uitgangspunten...

Nadere informatie

voorbeeldexamen I-Tracks Project Participation Foundation (PPF) voorbeeldexamen PPF uitgave oktober 2007

voorbeeldexamen I-Tracks Project Participation Foundation (PPF) voorbeeldexamen PPF uitgave oktober 2007 voorbeeldexamen Project Participation Foundation (PPF) I-Tracks Project Participation Foundation (PPF) voorbeeldexamen PPF uitgave oktober 2007 Inhoud inleiding 2 voorbeeldexamen 3 antwoordindicatie 12

Nadere informatie

Service Level Agreement (SLA)

Service Level Agreement (SLA) Service Level Agreement (SLA) Marcel Spruit Wat is een SLA Een SLA (Service Level Agreement) is een schriftelijke overeenkomst tussen een aanbieder en een afnemer van bepaalde diensten. In een SLA staan,

Nadere informatie

Het BiSL-model. Een whitepaper van The Lifecycle Company

Het BiSL-model. Een whitepaper van The Lifecycle Company Het BiSL-model Een whitepaper van The Lifecycle Company Met dit whitepaper bieden we u een overzicht op hooflijnen van het BiSL-model. U vindt een overzicht van de processen en per proces een beknopte

Nadere informatie

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. BISL Business Information Services Library Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2

Nadere informatie

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe SPIDER werkgroep Requirements Management Subwerkgroep Methoden Toelichting inhoud en voortgang tot nu toe donderdag 17 januari 2008 Frans van Veen Bert Dubbelman Robert van Lieshout Erwin Bolwidt Jan-Willem

Nadere informatie

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil eagileagileagileagileagileagileagileagi leagileagileagileagileagileagileagileag

Nadere informatie

Checklist basisontwerp SDM II

Checklist basisontwerp SDM II Organisatie SYSQA B.V. Pagina 1 van 5 Checklist basisontwerp SDM II Documentatie. Zijn de uitgangspunten voor het basisontwerp Is een plan van aanpak Zijn er wijzigingen op het Software Quality Assurance

Nadere informatie

QSM Benchmark Project ABC

QSM Benchmark Project ABC QSM Benchmark De intelligentie Voor u ligt de QSM benchmarkrapportage over. Deze rapportage geeft antwoord op de vraag of dit project marktconform is uitgevoerd in vergelijking met projecten in bedrijfsomgevingen

Nadere informatie

Expert Panel. Awareness Information. 25 June 2013. Challenge the future

Expert Panel. Awareness Information. 25 June 2013. Challenge the future Expert Panel Awareness Information 25 June 2013 1 Structure Doel Proces Classificatie van de practices waarvan je al dan niet direct op de hoogte gehouden wilt worden Classificatie van de practices waarbij

Nadere informatie

Medical device software

Medical device software Medical device software Medical device software Software ontwikkeling voor de medische wereld Nspyre Herculesplein 24 3584 AA Utrecht T 088-827 50 00 F 088-827 50 99 www.nspyre.nl Medical devices zijn

Nadere informatie

Risk & Requirements Based Testing

Risk & Requirements Based Testing Risk & Requirements Based Testing Tycho Schmidt PreSales Consultant, HP 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Agenda Introductie

Nadere informatie

Ontwikkelen en testen van e-business: beheerste dynamiek

Ontwikkelen en testen van e-business: beheerste dynamiek Ontwikkelen en testen van e-business: beheerste dynamiek Het ontwikkelen en gestructureerd testen van administratieve systemen is gebaseerd het watervalprincipe. Bij het ontwikkelen volgens het watervalprincipe

Nadere informatie

RUM. requirements Management. SPIder session Project. driven by requirements 25th april. Risk assessed User

RUM. requirements Management. SPIder session Project. driven by requirements 25th april. Risk assessed User RUM Risk assessed User requirements Management - SPIder session Project driven by requirements 25th april Copyright 2006 ps_testware - Gijs Kuiper Risk assessed User requirement Management Personalia Gijs

Nadere informatie

IN ZES STAPPEN MVO IMPLEMENTEREN IN UW KWALITEITSSYSTEEM

IN ZES STAPPEN MVO IMPLEMENTEREN IN UW KWALITEITSSYSTEEM IN ZES STAPPEN MVO IMPLEMENTEREN IN UW KWALITEITSSYSTEEM De tijd dat MVO was voorbehouden aan idealisten ligt achter ons. Inmiddels wordt erkend dat MVO geen hype is, maar van strategisch belang voor ieder

Nadere informatie

vanuit de technische en organisatorische omgeving, werk-verdeling, budget, planning, en hergebruik van componenten. Het documenteren van SA dient

vanuit de technische en organisatorische omgeving, werk-verdeling, budget, planning, en hergebruik van componenten. Het documenteren van SA dient 9 Samenvatting Software heeft vooruitgang in veel vakgebieden mogelijk gemaakt en heeft een toenemend invloed op ons leven en de samenleving in zijn geheel. Software wordt gebruikt in computers, communicatienetwerken,

Nadere informatie

Handout. Pagina 1. SYSQA B.V. Almere. Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven SYSQA SYSQA.

Handout. Pagina 1. SYSQA B.V. Almere. Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven SYSQA SYSQA. Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven Johan Zandhuis SYSQA Start: 1999 Onafhankelijk Quality Assurance in IT 150 medewerkers (en groeiend) 2 SYSQA Operationeel

Nadere informatie

Checklist risicofactoren IT-projecten

Checklist risicofactoren IT-projecten Organisatie SYSQA B.V. Pagina 1 van 5 Checklist risicofactoren IT-projecten In onderstaande checklists zijn de factoren die het slagen van een project beïnvloeden opgenomen. Projectomvang Hoe groot is

Nadere informatie

Praktijkplein Titel: Toepassing: Koppeling met het Operational Excellence Framework: Implementatiemethodieken: ontwerpen en ontwikkelen.

Praktijkplein Titel: Toepassing: Koppeling met het Operational Excellence Framework: Implementatiemethodieken: ontwerpen en ontwikkelen. Praktijkplein Titel: Implementatiemethodieken: ontwerpen en ontwikkelen. Toepassing: Beknopte samenvatting van twee implementatiemethodieken en hun toepassing bij het implementeren van een operational

Nadere informatie

Oplossingsvrij specificeren

Oplossingsvrij specificeren Oplossingsvrij specificeren ir. J.P. Eelants, projectmanager Infrabouwproces CROW Samenvatting De methodiek van oplossingsvrij specificeren richt zich niet alleen op het formuleren van functionele eisen.

Nadere informatie

CMM 3: levert het wat op?

CMM 3: levert het wat op? CMM 3: levert het wat op? Philips Analytical De noodzaak en voordelen van Software Process Improvement Wie is Philips Analytical? Waarom is voor ons software proces verbetering zo essentieel? Hoe hebben

Nadere informatie

Tweede Kamer der Staten-Generaal

Tweede Kamer der Staten-Generaal Tweede Kamer der Staten-Generaal 2 Vergaderjaar 1987-1988 Rijksbegroting voor het jaar 1988 20 200 Hoofdstuk X Ministerie van Defensie Nr. 34 BRIEF VAN DE STAATSSECRETARIS VAN DEFENSIE Aan de Voorzitter

Nadere informatie

6. Project management

6. Project management 6. Project management Studentenversie Inleiding 1. Het proces van project management 2. Risico management "Project management gaat over het stellen van duidelijke doelen en het managen van tijd, materiaal,

Nadere informatie

Stichting NIOC en de NIOC kennisbank

Stichting NIOC en de NIOC kennisbank Stichting NIOC Stichting NIOC en de NIOC kennisbank Stichting NIOC (www.nioc.nl) stelt zich conform zijn statuten tot doel: het realiseren van congressen over informatica onderwijs en voorts al hetgeen

Nadere informatie

4.1 Simulatie in de analysefase

4.1 Simulatie in de analysefase 1 Bijlage 4 Simulatietechnieken Simulatie is een toetstechniek waarmee door middel van het nabootsen van een bepaalde situatie (bijvoorbeeld een herontworpen bedrijfsproces) in een afgeschermde omgeving

Nadere informatie

Examen ISyF Information Systems Foundation

Examen ISyF Information Systems Foundation Examen ISyF Information Systems Foundation Publicatiedatum Startdatum 1 september 2006 1 juli 2003 Doelgroep Information Systems Foundation richt zich op starters in de IT. De module richt zich op mensen

Nadere informatie

Test naam Marktgerichtheidsscan Datum 28-8-2012 Ingevuld door Guest Ingevuld voor Het team Team Guest-Team Context Overige

Test naam Marktgerichtheidsscan Datum 28-8-2012 Ingevuld door Guest Ingevuld voor Het team Team Guest-Team Context Overige Test naam Marktgerichtheidsscan Datum 28-8-2012 Ingevuld door Guest Ingevuld voor Het team Team Guest-Team Context Overige Klantgerichtheid Selecteren van een klant Wanneer u hoog scoort op 'selecteren

Nadere informatie

Requirements Traceability. Marcel de Baas, Jan Bank, Edwin Buisman, Frits Jacobs, Kitty Spaas, Erik Venema, Arno Zandman

Requirements Traceability. Marcel de Baas, Jan Bank, Edwin Buisman, Frits Jacobs, Kitty Spaas, Erik Venema, Arno Zandman Requirements Traceability Marcel de Baas, Jan Bank, Edwin Buisman, Frits Jacobs, Kitty Spaas, Erik Venema, Arno Zandman 22 Mei 2008 Werkgroep Traceability Doel van de werkgroep: Aanbieden van hulpmiddelen

Nadere informatie

Test rapportage Waarom eigenlijk?

Test rapportage Waarom eigenlijk? Testrapportage Boodschappers van de koning? Test rapportage Waarom eigenlijk? TestNet voorjaarsevenement 2015 Jurian van de Laar Jurian van de Laar @JurianvdL 30 april 2015 @JurianvdL Jurian van de Laar

Nadere informatie

ORGANISATORISCHE IMPLENTATIE BEST VALUE

ORGANISATORISCHE IMPLENTATIE BEST VALUE ORGANISATORISCHE IMPLENTATIE BEST VALUE EEN ONDERZOEK NAAR DE IMPLEMENTATIE VAN BEST VALUE BINNEN EEN SYSTEMS ENGINEERING OMGEVING STEPHANIE SAMSON BEST VALUE KENNIS SESSIE WESTRAVEN 17 JUNI 09.00 12.00

Nadere informatie

Medewerker administratieve processen en systemen

Medewerker administratieve processen en systemen processen en systemen Doel Voorbereiden, analyseren, ontwerpen, ontwikkelen, beheren en evalueren van procedures en inrichting van het administratieve proces en interne controles, rekening houdend met

Nadere informatie

2 e webinar herziening ISO 14001

2 e webinar herziening ISO 14001 2 e webinar herziening ISO 14001 Webinar SCCM 25 september 2014 Frans Stuyt Doel 2 e webinar herziening ISO 14001 Planning vervolg herziening Overgangsperiode certificaten Korte samenvatting 1 e webinar

Nadere informatie

Doe eens gek! Houd rekening met de mensen in uw organisatie bij het implementeren van ICT oplossingen.

Doe eens gek! Houd rekening met de mensen in uw organisatie bij het implementeren van ICT oplossingen. Doe eens gek! Houd rekening met de mensen in uw organisatie bij het implementeren van ICT oplossingen. ERP, CRM, workflowmanagement en documentmanagement systemen, ze hebben één ding gemeen: Veel van de

Nadere informatie

Bantopa (Samen)werken aan Samenwerken

Bantopa (Samen)werken aan Samenwerken Bantopa (Samen)werken aan Samenwerken Masterclass - Alliantievaardigheden Een praktische leidraad voor toekomstige alliantiemanagers Samenwerken als Kerncompetentie De complexiteit van producten, processen

Nadere informatie

Doel. Context VSNU UFO/INDELINGSINSTRUMENT FUNCTIEFAMILIE ICT FUNCTIONEEL (INFORMATIE) BEHEERDER VERSIE 1 MEI 2012

Doel. Context VSNU UFO/INDELINGSINSTRUMENT FUNCTIEFAMILIE ICT FUNCTIONEEL (INFORMATIE) BEHEERDER VERSIE 1 MEI 2012 Functioneel (informatie) beheerder Doel Zorgdragen voor het inrichten, aanpassen, vernieuwen en onderhouden van de informatievoorziening (processen, procedures en/of systemen), passend binnen het informatiebeleid

Nadere informatie

READ: de informatiestrategieaanpak van Steenwinkel Kruithof Associates (SKA)

READ: de informatiestrategieaanpak van Steenwinkel Kruithof Associates (SKA) READ: de informatiestrategieaanpak van (SKA) INLEIDING HET SPANNINGSVELD TUSSEN KORTETERMIJNVERWACHTINGEN EN LANGETERMIJNBEHOEFTEN In veel bedrijven volgen businessgerelateerde veranderingen elkaar snel

Nadere informatie

Op de computer kan naar eigen inzicht software op worden geïnstalleerd, een andere besturingssysteem is mogelijk.

Op de computer kan naar eigen inzicht software op worden geïnstalleerd, een andere besturingssysteem is mogelijk. Planningsfase 1. Afspraken maken over doelstelling en randvoorwaarden De doelstelling van het project: De doelstelling van het project: het maken van het gewenste product. De doelstelling van de student:

Nadere informatie

Bantopa Terreinverkenning

Bantopa Terreinverkenning Bantopa Terreinverkenning Het verwerven en uitwerken van gezamenlijke inzichten Samenwerken als Kerncompetentie De complexiteit van producten, processen en services dwingen organisaties tot samenwerking

Nadere informatie

Agile in Projecten minimalisme of strak pak? Richard Weber PMP

Agile in Projecten minimalisme of strak pak? Richard Weber PMP Agile in Projecten minimalisme of strak pak? Richard Weber PMP De Spreker Richard Weber Directeur & oprichter Adviseur & coach Projectmanagement Profile Dynamics ICT & Bedrijfskundige achtergrond Trainer

Nadere informatie

Goed functioneel beheer noodzaak voor effectievere SPI

Goed functioneel beheer noodzaak voor effectievere SPI getronicspinkroccade.nl Goed functioneel beheer noodzaak voor effectievere SPI Machteld Meijer Zeist, 3 oktober 2006 Inhoud Domeinen en modellen Functioneel beheer en BiSL Rol van BiSL in SPI 1 Goed functioneel

Nadere informatie

Business Process Management

Business Process Management Business Process Management Prof. dr. Manu De Backer Universiteit Antwerpen Katholieke Universiteit Leuven Hogeschool Gent Wat is een bedrijfsproces? Een verzameling van (logisch) gerelateerde taken die

Nadere informatie

Les E-01 Projectmanagement

Les E-01 Projectmanagement Les E-01 Projectmanagement 1.1 Werken op projectbasis Op allerlei manieren werken mensen in het sociale leven samen om bepaalde doelen te verwezenlijken. Buurtbewoners organiseren een pleinfeest, verenigingsleden

Nadere informatie

Projectvoorstellen maken

Projectvoorstellen maken Projectvoorstellen maken 1. Kader 1.1. Gebruiksaanwijzing 1.2. Wat zijn de eisen aan een projectvoorstel? 2. Inleiding 2.1 Signalering 2.2 Vooronderzoek 2.3 Probleemsituatie 3. Doelstellingen en randvoorwaarden

Nadere informatie

PRINCE2 Symposium: Zin en Onzin van een Methode. PRINCE 2 versus CMMI; raakvlakken, overlap en aanvullingen SYSQA B.V.

PRINCE2 Symposium: Zin en Onzin van een Methode. PRINCE 2 versus CMMI; raakvlakken, overlap en aanvullingen SYSQA B.V. PRINCE2 Symposium: PRINCE 2 versus CMMI; raakvlakken, overlap en aanvullingen Jan Jaap Cannegieter SYSQA B.V. SYSQA B.V. Operationeel Tactisch Strategisch Testen Requirements Quality assurance Auditing

Nadere informatie

MDA in de praktijk. Freek Bosch, Business Unit Manager Amsterdam, 4 juni 2009

MDA in de praktijk. Freek Bosch, Business Unit Manager Amsterdam, 4 juni 2009 Functional Model Driven Development MDA in de praktijk Freek Bosch, Business Unit Manager Amsterdam, 4 juni 2009 FMDD agenda FMDD Waarom FMMD De praktijk Wat is FMDD Ervaringen en lessons learned Ervaringen

Nadere informatie

Auteurs: Jan van Bon, Wim Hoving Datum: 9 maart 2009. Cross reference ISM - COBIT

Auteurs: Jan van Bon, Wim Hoving Datum: 9 maart 2009. Cross reference ISM - COBIT Auteurs: Jan van Bon, Wim Hoving Datum: 9 maart 2009 Cross reference ISM - COBIT ME: Monitor & Evaluate Cross reference ISM - COBIT Management summary Organisaties gebruiken doorgaans twee soorten instrumenten

Nadere informatie

Plan van aanpak <> <>

Plan van aanpak <<projectnaam>> <<Organisatie>> Plan van aanpak SYSQA B.V. Almere Datum : Status : Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van 11 Inhoudsopgave 1 Managementsamenvatting...

Nadere informatie

Stakeholder behoeften beschrijven binnen Togaf 9

Stakeholder behoeften beschrijven binnen Togaf 9 Stakeholder behoeften beschrijven binnen Togaf 9 Inventarisatie van concerns, requirements, principes en patronen Bert Dingemans Togaf 9 kent verschillende entiteiten om de behoeften van stakeholders te

Nadere informatie

Enterprisearchitectuur

Enterprisearchitectuur Les 2 Enterprisearchitectuur Enterprisearchitectuur ITarchitectuur Servicegeoriënteerde architectuur Conceptuele basis Organisatiebrede scope Gericht op strategie en communicatie Individuele systeemscope

Nadere informatie

Offshore Outsourcing van Infrastructure Management

Offshore Outsourcing van Infrastructure Management Offshore Outsourcing van Infrastructure Management an emerging opportunity dr. Erik Beulen Atos Origin/Tilburg University 1 Agenda Introductie Ontwikkelingen Risicovergelijking Best practices Conclusies

Nadere informatie

Business. IT in charge. Met resultaten CIO Survey en 9 CIO s aan het woord. Analytics

Business. IT in charge. Met resultaten CIO Survey en 9 CIO s aan het woord. Analytics Business Analytics IT in charge Met resultaten CIO Survey en 9 CIO s aan het woord Informatie is van en voor mensen CIO speelt belangrijke rol in nieuw spanningsveld Door Guus Pijpers Een van de eerste

Nadere informatie

RISICO MANAGEMENT, BASIS PRINCIPES

RISICO MANAGEMENT, BASIS PRINCIPES RISICO MANAGEMENT, BASIS PRINCIPES AGENDA Leerdoelen van vandaag Wat en waarom Risico Management? Validatie bij Automatisering GMP-Z, GAMP 5, ASTM 2500 en Risico Management Overzicht Risk Management Proces

Nadere informatie

PRINCE2 2009 is overzichtelijker

PRINCE2 2009 is overzichtelijker PRINCE2 2009 is overzichtelijker 29 mei 2009 door: Lia de Zoete en Reinier de Koning Half juni presenteert het Office of Government Commerce in Londen PRINCE2 2009. Het grote voordeel van de nieuwe versie

Nadere informatie

Deelprojectplan. Bestuurlijke Informatie Voorziening

Deelprojectplan. Bestuurlijke Informatie Voorziening Deelprojectplan Bestuurlijke Informatie Voorziening Beheersing van risico s en verbetering van de besturing van de Hogeschool van Utrecht, door middel van effectieve en efficiënte informatiestromen, als

Nadere informatie

Balanced Scorecard. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

Balanced Scorecard. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. Balanced Scorecard Een introductie Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3 2 DE

Nadere informatie

Bedrijfsprocessen theoretisch kader

Bedrijfsprocessen theoretisch kader Bedrijfsprocessen theoretisch kader Versie 1.0 2000-2009, Biloxi Business Professionals BV 1. Bedrijfsprocessen Het procesbegrip speelt een belangrijke rol in organisaties. Dutta en Manzoni (1999) veronderstellen

Nadere informatie

Bijlage 9. UNI 120621.9 REB GD. Releasebeleid

Bijlage 9. UNI 120621.9 REB GD. Releasebeleid Releasebeleid Ondanks alle aan de samenstelling van de tekst bestede zorg, kan Newway Retail Solutions bv (Newway) géén enkele aansprakelijkheid aanvaarden voor eventuele directe en/of indirecte schade,

Nadere informatie

Het stuurmodel voor een opdrachtgever

Het stuurmodel voor een opdrachtgever Het stuurmodel voor een opdrachtgever Ir. Derk K. Kremer 1. Inleiding In één van mijn eerdere artikelen heb ik al aangegeven dat de rol van opdrachtgever op zich geen moeilijke rol is. Voor een ervaren

Nadere informatie

Ordening van processen in een ziekenhuis

Ordening van processen in een ziekenhuis 4 Ordening van processen in een ziekenhuis Inhoudsopgave Inhoud 4 1. Inleiding 6 2. Verantwoording 8 3. Ordening principes 10 3.0 Inleiding 10 3.1 Patiëntproces 11 3.2 Patiënt subproces 13 3.3 Orderproces

Nadere informatie

Kwaliteitsbewaking en testen in ICT beheerorganisaties

Kwaliteitsbewaking en testen in ICT beheerorganisaties DKTP Informatie Technologie Veembroederhof 1 1019 HD Amsterdam Telefoon 020 427 52 21 Kwaliteitsbewaking en testen in ICT beheerorganisaties Voor de meeste projectgroepen die software ontwikkelen vormt

Nadere informatie

Bewaren van digitale informatie: hoe kom je tot een goede beslissing?

Bewaren van digitale informatie: hoe kom je tot een goede beslissing? Bewaren van digitale informatie: hoe kom je tot een goede beslissing? Hans Hofman Nationaal Archief Netherlands NCDD Planets dag Den Haag, 14 december 2009 Overzicht Wat is het probleem? Wat is er nodig?

Nadere informatie

Risk Based Testing. TestNet Voorjaarsbijeenkomst. Johan Vink. A reality check

Risk Based Testing. TestNet Voorjaarsbijeenkomst. Johan Vink. A reality check Risk Based Testing A reality check TestNet Voorjaarsbijeenkomst Johan Vink Even voorstellen - Johan Vink - 42 jaar testervaring - 15 jaar betaald - Test competence leader Risk Based Testing, a reality

Nadere informatie

Prince2 audit. Kwaliteitsmaatregel met rendement

Prince2 audit. Kwaliteitsmaatregel met rendement Prince2 audit Kwaliteitsmaatregel met rendement Niek Pluijmert Dga INQA (samen met Hans) Project- en kwaliteitmanagement Sedert 1979 in ICT Bestuurslid Spider Bestuurslid KvK Midden Nederland TU Delft

Nadere informatie

Naast basiscompetenties als opleiding en ervaring kunnen in hoofdlijnen bijvoorbeeld de volgende hoofd- en subcompetenties worden onderscheiden.

Naast basiscompetenties als opleiding en ervaring kunnen in hoofdlijnen bijvoorbeeld de volgende hoofd- en subcompetenties worden onderscheiden. Competentieprofiel Op het moment dat duidelijk is welke kant de organisatie op moet, is nog niet zonneklaar wat de wijziging gaat betekenen voor ieder afzonderlijk lid en groep van de betreffende organisatorische

Nadere informatie

Onderhoud van kwaliteitszorg

Onderhoud van kwaliteitszorg (versie 1.0, 21 maart 2001) Onderhoud van kwaliteitszorg Frans Bank, Pink Elephant Business Online Services Maikel Mardjan, TSM Business School In dit artikel wordt beschreven hoe in een praktijk situatie

Nadere informatie

Organisatieprestatiescan. Deze techniek wordt gebruikt in de focus- en analysefase bij het analyseren van de huidige situatie.

Organisatieprestatiescan. Deze techniek wordt gebruikt in de focus- en analysefase bij het analyseren van de huidige situatie. 1 Bijlage 2 De organisatieprestatiescan Techniek: Organisatieprestatiescan Toepassingsgebied: Achtergrond: Deze techniek wordt gebruikt in de focus- en analysefase bij het analyseren van de huidige situatie.

Nadere informatie

De nieuwe ISO norm 2015 Wat nu?!

De nieuwe ISO norm 2015 Wat nu?! De nieuwe ISO norm 2015 Wat nu?! Stichting QualityMasters Nieuwland Parc 157 3351 LJ Papendrecht 078-3030060 info@qualitymasters.com www.qualitymasters.com 02-2015 Inhoud Inleiding pagina 3 Van Oud naar

Nadere informatie

PROJECT INITIATION DOCUMENT

PROJECT INITIATION DOCUMENT PROJECT INITIATION DOCUMENT Versie: Datum: x.x dd-mm-jj DOCUMENTATIE Versie Naam opdrachtgever Naam opsteller Datum: dd-mm-jj Voor akkoord: Datum:. INHOUDSOPGAVE 1. Managementsamenvatting

Nadere informatie

Aliens? http://www.youtube.com/watch?v=e5pqleh2hz8

Aliens? http://www.youtube.com/watch?v=e5pqleh2hz8 Aliens? http://www.youtube.com/watch?v=e5pqleh2hz8 Ontwikkelmethoden en technieken Kenmerken van ontwikkelmethoden POMT HC2 2 Vorige week 3 Rollenspel Klant is koning Communicatie en afspraken Documentatie

Nadere informatie

PROJECTMANAGEMENT 1 SITUATIE

PROJECTMANAGEMENT 1 SITUATIE PROJECTMANAGEMENT George van Houtem 1 SITUATIE Het werken in en het leidinggeven aan projecten is tegenwoordig eerder regel dan uitzondering voor de hedendaagse manager. In elk bedrijf of organisatie komen

Nadere informatie

CobiT. Drs. Rob M.J. Christiaanse RA PI themabijeenkomst Utrecht 29 juni 2005 9/2/2005 1

CobiT. Drs. Rob M.J. Christiaanse RA PI themabijeenkomst Utrecht 29 juni 2005 9/2/2005 1 CobiT Drs. Rob M.J. Christiaanse RA PI themabijeenkomst Utrecht 29 juni 2005 9/2/2005 1 Control objectives for information and related Technology Lezenswaardig: 1. CobiT, Opkomst, ondergang en opleving

Nadere informatie

Service Niveau Overeenkomst Digikoppeling

Service Niveau Overeenkomst Digikoppeling Service Niveau Overeenkomst Digikoppeling Versie 1.3 Datum 26 mei 2015 Status Definitief Colofon Logius Servicecentrum: Postbus 96810 2509 JE Den Haag t. 0900 555 4555 (10 ct p/m) e. servicecentrum@logius.nl

Nadere informatie

Project methodiek. Auxilium BV Oude Delft 48 2611 CD Delft. T: 015-261 23 16 F: 015-213 34 83 E: info@auxilium.nl

Project methodiek. Auxilium BV Oude Delft 48 2611 CD Delft. T: 015-261 23 16 F: 015-213 34 83 E: info@auxilium.nl Project methodiek Auxilium BV Oude Delft 48 2611 CD Delft T: 015-261 23 16 F: 015-213 34 83 E: info@auxilium.nl Inhoud 1 PROJECTMETHODIEK... 3 1.1 TIME-BOXING... 3 1.2 USER-STORIES EN STORY-POINTS... 3

Nadere informatie

TE LAAT OPGELEVERD, IS DUURDER DAN GEPLAND OF BIEDT NIET DE GEWENSTE FUNCTIONALITEIT EN KWA- VAN ZIJN TERUG TE VOEREN OP EEN ONJUISTE PLANNING

TE LAAT OPGELEVERD, IS DUURDER DAN GEPLAND OF BIEDT NIET DE GEWENSTE FUNCTIONALITEIT EN KWA- VAN ZIJN TERUG TE VOEREN OP EEN ONJUISTE PLANNING SOFTWARETOOLS VOOR PROJECTNAVIGATIE CIJFERMATIGE ONDERBOUWING NOG STEEDS ONMISBAAR IN ICT-PROJECTEN Auteur: Ernst van Waning ZO N ZEVENTIG PROCENT VAN ALLE ICT-PROJECTEN WORDT TE LAAT OPGELEVERD, IS DUURDER

Nadere informatie

Verzamelde vragen en antwoorden Agile Applicatie ontwikkeling. Agile Methodiek en Technologie. Zest Application Professionals

Verzamelde vragen en antwoorden Agile Applicatie ontwikkeling. Agile Methodiek en Technologie. Zest Application Professionals Verzamelde vragen en antwoorden Agile Applicatie ontwikkeling Agile Methodiek en Technologie Zest Application Professionals Hoe is de aansluiting op ontwikkelmethoden voor Legacy-systemen? Out of the Box

Nadere informatie

Functieprofiel: Beleidsmedewerker Functiecode: 0301

Functieprofiel: Beleidsmedewerker Functiecode: 0301 Functieprofiel: Beleidsmedewerker Functiecode: 0301 Doel Ontwikkelen, implementeren, evalueren en bijstellen van beleid op één of meerdere aandachtsgebieden/beleidsterreinen ten behoeve van de instelling,

Nadere informatie

Plan van Aanpak. project Tetris Packing

Plan van Aanpak. project Tetris Packing Plan van Aanpak project Tetris Packing Inleiding! 4 Projectomschrijving! 5 Producten! 5 Testplan! 5 Ontwerprapport! 5 Implementatierapport! 5 Testrapport! 5 Systeemdocumentatie! 5 Aanpak! 6 Projectmethodiek!

Nadere informatie

Oplossingen voor het testen van objectgeoriënteerde software

Oplossingen voor het testen van objectgeoriënteerde software Oplossingen voor het testen van objectgeoriënteerde software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14 maart 2013 HOM/FHTeL Oplossingen voor het testen

Nadere informatie

Functieprofiel: Projectleider Functiecode: 0302

Functieprofiel: Projectleider Functiecode: 0302 Functieprofiel: Projectleider Functiecode: 0302 Doel Voorbereiden en opzetten van en bijbehorende projectorganisatie, alsmede leiding geven aan de uitvoering hiervan, binnen randvoorwaarden van kosten,

Nadere informatie

INITIATIEFVOORSTEL Gemeente Velsen

INITIATIEFVOORSTEL Gemeente Velsen INITIATIEFVOORSTEL Gemeente Velsen Raadsvergadering d.d. : 1 december 2011 Raadsbesluitnummer : R11.081 Carrousel d.d. : 17 november 2011 Onderwerp : Eindrapport Rekenkamercommissie kwaliteit Grondbeleid

Nadere informatie

Ant: B Dit is het doel van het proces.

Ant: B Dit is het doel van het proces. In welk proces vormt het voor aanpassingen in de informatievoorziening beschikbaar gestelde budget een mandaat voor besluitvorming? A: Contractmanagement B: Financieel management C: Transitie D: Wijzigingenbeheer

Nadere informatie

Wat heeft een tester aan ASL en BiSL?

Wat heeft een tester aan ASL en BiSL? TestNet Noord, Heerenveen, 20 november 2012 Wat heeft een tester aan ASL en BiSL? Eibert Dijkgraaf Intro Wie zit er in een typische beheer omgeving? Wat is kenmerkend voor testen : IN BEHEER? IN ONDERHOUD?

Nadere informatie