Het begroten van softwareprojecten : meten is weten!

Het begroten van softwareprojecten : meten is weten!

Heemstra, F. J. (1987). Het begroten van softwareprojecten : meten is weten! (EUT - BDK report. Dept. of Industrial Engineering and Management Science; Vol. 28). Technische Universiteit Eindhoven.

Document status and date: Gepubliceerd: 01/01/1987

Document Version:

Uitgevers PDF, ook bekend als Version of Record

Please check the document version of this publication:

• A submitted manuscript is the version of the article upon submission and before peer-review. There can be important differences between the submitted version and the official published version of record. People interested in the research are advised to contact the author for the final version of the publication, or visit the DOI to the publisher's website.

• The final author version and the galley proof are versions of the publication after peer review.

• The final published version features the final layout of the paper including the volume, issue and page numbers.

Link to publication

General rights

Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain

• You may freely distribute the URL identifying the publication in the public portal.

If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, please follow below link for the End User Agreement:

www.tue.nl/taverne

Take down policy

If you believe that this document breaches copyright please contact us at:

openaccess@tue.nl

providing details and we will investigate your claim.

tuJ

Onderzoek Rapport

Technische Universiteit

Eindhoven

F A C U L T E I T T E C H N I S C H E B E D R I J F S K U N D E

Het begroten van

softwarenprojecten :

meten is weten !

_ BEDRIJFSKUNDE

HET BEGROTEN VAN SOFTWAREPROJECTEN :

Report EUT/BDK/28 ISBN 90-6757-028-1 Eindhoven, 1987

Eindhoven University of Technology

Department of Industrial Engineering and Management Science

CIP-GEGEVENS KONINKLIJKE BIBLIOTHEEK . DEN HAAG Heemstra . F .J .

Het beqroten van softwareprojecten _{: meten is weten /} F .J . Heemstra . - Eindhoven _{: Technische Universiteit} Eindhoven, Faculteit Bedrijfskunde . - (EUT report / Eindhoven University of Technology, Department of Industrial Engineering & _{Management Science, ISSN} 0 1 67-9708 ; BDK!281

ISBN 90-6757-01á- :

SISO 5 2 0 .9 UDC 6S7 .31 :681 .3 .06 Trefw . : software _{; begroten .}

HET BEGROTEN VAN SOFTWAREPROJECTEN : METEN IS WETEN ! ir . F .J .Heemstra

Technische Universiteit Eindhoven, faculteit Bedrijfskunde, vakgroep Bestuurlijke Informatiesystemen en Automatisering .

Samenvatting .

De noodzaak om betrouwbare schattingen van de o ntwikkelkosten var, software te kunnen maken, wordt alom erkend . In dit licht zijn de afgelopen jaren een aantal schattingsmodellen ontwikkeld zoals COCOMO, PRICE-S, JENSEN JS2, ESTIMACS enz . De waarde die dergelijke modellen voor een specifieke organisatie hebben, wordt

in belangrijke mate bepaald door de beschikbaarheid van voldoende ervaringsgegevens van afgesloten softwareprojecten . In dit artikel wordt nagegaan op welke wijze dergelijk soort gegevens een hulpmiddel kunnen zijn bij het beheersen (het begroten, plannen, bewaken en bijsturen) van softwareprojecten . In het bijzonder zal worden ingegaan op het nut van historische projectgegevens bij het schatten van softwarekosten, met name bij het gebruik van schattingsmodellen .

1 . Inleiding .

Bij de opdracht tot het bouwen van een huis verwacht men een nauwkeurige opgave van prijs, opleverdatum, benodigde materialen en personeel . De architect is in staat om op basis van het aantal kubieke meter inhoud van het huis en de specifieke wensen van de opdrachtgever een begroting te maken . Over het algemeen zal de uiteindelijke prijs en opleverdatum weinig afwijken van die begroting . Wie eenzelfde beeld verwacht bij het ontwikkelen van software komt bedrogen uit . Terwijl in de bouwwereld een overschrijding van 107% op het budget als een behoorlijke misser wordt beschouwd, zal dit in de softwarewereld gezien worden al, ; een staaltje van vakmanschap op begrotingsgebied . De ervaring leert dat het begroten van de kosten, inspanning en tijd die nod'g is om een sofwareprodukt te ontwikkelen, moeilijk is .

In sektie 2 van dit artikel zal worden aangegeven welke de belangrijkste oorzaken zijn van de problemen bij het opstellen van een begroting . Op een van deze oorzaken, te weten "een gebrek aan gegevens over reeds voltooide projecten" zal in de rest van het artikel nader worden ingegaan . In sektie 3 worden een aantal methoden voor het begroten van softwarekosten besproken . Hierbij zal het accent worden gelegd op het belang van historische projectgegevens bij het gebruik van dergelijke methoden en zal duidelijk worden gemaakt dat succesvol begroten niet mogelijk is zonder dit soort gegevens . In sektie 4 wordt dieper ingegaan op een van de genoemde begrotingsmethoden, namelijk parametrische modellen . Aan de hand van een voorbeeld van zo'n model - in dit geval het COnstructive COst MOdel (COCOMO) - wordt de noodzaak van voltooide projectgegevens toegelicht . Vervolgens wordt in sektié 5 aangegeven waarom er zo'n gebrek is aan deze zo

-1-noodzakelijke gegevens . Na de constatering van de noodzaak van en het gebrek aan oude projectgegevens, wordt in sektie 6 beschreven hoe deze gegevens gebruikt kunnen worden als een zinvolle en zelfs noodzakelijke ondersteuning voor het softwareproject management . Daarbij wordt niet uitsluitend gekeken naar een ondersteuning bij het begroten, maar ook naar de betekenis van historische projectgegevens voor het beheersen van softwareprojecten en voor het het proces van software-ontwikkeling . In sektie 7 wordt een overzicht gegeven van bestaande databanken van projectgegevens . Het artikel eindigt

tenslotte met een aantal conclusies (sektie 8) .

2 . Problemen bij het begroten .

De ervaring leert dat het begroten van softwareprojecten moeilijk is . Het is in de praktijk geen uitzondering dat na voltooing van het project de werkelijke kosten en doorlooptijd twee tot driemaal zo hoog blijken als oorspronkelijk voorspeld . Zonder uitputtend te zijn, kunnen de volgende oorzaken voor dit probleem worden genoemd (HEEMSTRA86) :

1 . een gebre~ aan gegeyens ov_e l: reeds voltooide oro 1 ectei~_

Een voorspelling van kosten, inspanning en doorlooptijd van een nieuw softwareproject dient mede gebaseerd te zijn op kennis en ervaring die is opgedaan met oude projecten . Over het algemeen vindt er echter geen systematische registratie plaats van deze kennis en ervaring . In sektie 4 van dit artikel zal worden aangegeven wat mogelijk de oorzaak is van dit manco .

2 . beinvloedende factoren .

Het aantal factoren dat van invloed is op kosten, inspanning en doorlooptijd blijkt zeer groot te zijn . Daarbij ontbreekt het voor het merendeel van deze factoren aan een eenduidige definiering, zijn ze moeilijk te kwantificeren en is er sprake van subjectiviteit bij de bepaling ervan . Het is lastig na te gaan wat de invloed van een factor op kosten, inspanning en doorlooptijd is . Onderzoeken in deze spreken elkaar meer dan eens tegen . Tenslotte treden er extra problemen op als men bij het begroten van een softwareproject schattingen moet maken over de waarde van beinvloedende factoren . Bijvoorbeeld : uit hoeveel regels code zal het programma gaan bestaan (of uit hoeveel funktiepunten), wat is de complexiteit van het programma enz . In

(HEEMSTA87 en HEEMSTRA87a) wordt uitvoerig op deze problematiek ingegaan .

3 . een system_atische onderschatting v_an kostens inspanning eri d_oor looet iA_

Softwareontwikkelaars blijken over het algemeen veel te optimistisch te zijn over de hoeveelheid tijd en inspanning die zij nodig denken te hebben voor de ontwikkeling van een systeem (BROOKS75) . Daarnaast is men geneigd, bewust of onbewust naar een bepaalde uitkomst 'toe te rekenen' . Dit geldt zeker als men als belanghebbende nauw betrokken is bij het te ontwikkelen systeem (BEMELMANS87) . In sektie 3 worden een aantal schattingsmethoden

behandeld waaronder de methode Price-To-Win en de methode Parkinson . Beide methoden illustreren op welke (vaak legitieme) gronden een onderschatting kan plaatsvinden .

4 . de foutieve veronderstelling dat er een lineair verband is _{- - -} --tussen li-i!9 en men-sen .

Putnam en Fitzsimmons (PUTNAM79) tonen aan dat mensen en tijd niet onderling uitwisselbaar zijn . Uitwisselbaarheid zou betekenen dat de inspanning om een programma te ontwikkelen het produkt zou zijn van mensen en tijd . Een programma dat door 25 mensen in twee jaar gerealiseerd zou worden, zou volgens deze redenering met 50 mensen in een jaar gereed zijn . De praktijk heeft uitgewezen dat deze veronderstelling onjuist is . Putnam poneert de stelling dat naarmate de ontwikkeltijd korter wordt het aantal benodigde mensmaanden meer dan proportioneel stijgt, tot zelfs een limiet wordt bereikt waarbij het inzetten van meer personeel niet leidt tot verkorting maar zelfs tot een verlenging van de doorlooptijd . Deze verlenging is het gevolg van toenemende communicatie en coordinatie .

5 . een gebrekkige definie-ring v-an software en softwareontwikkeling,

Het blijkt dat een deel van de problemen bij het begroten van softwareprojecten terug te voeren is tot een onduidelijke omschrijving van wat men verstaat onder informatiesysteem ontwiikeling, softwareontwikkeling, software en een softwareproject (HEEMSTRAB5) . Brooks (BROOKS75) laat dit verschil zien aan de hand van onderstaand figuur .

---PROGRAM

het 'kale' programma zonder documentatie, niet getest en gekoppeld met andere programma's

~ 3

* 3

* 9

PROGRAMMING SYSTEM het kale programma

is mbv interfaces gekoppeld met andere programma's

PROGRAMMING PRODUCT ~ PROGRAMMING SYSTEM --- --- een gedocumenteerd, getest PRODUCT

en onderhoudbaar programma volwaardig programma ---figuur 1 . Verschillende omschrijvingen van een programma en de

gevol-gen voor de benodigde kosten, inspanning en doorlooptijd . Ervaringscijfers leren dat het maken van een programming product ongeveer driemaal zoveel inspanning kost dan het maken van een kaal programma . Voor het koppelen met andere programma's moet de inspanning nogmaals met een factor drie verhoogd worden . Men moet de verhalen over software, die "op een zolderkamertje in een recordtijd in elkaar geknutseld is" op zijn juiste waarde schatten . In bijna alle gevallen betreft het hier software die o .a . op geen enkele manier gedocumenteerd is en daardoor moeilijk overdraagbaar en nauwlijks onderhoudbaar is . Verder is het veelal software die niet geintegreerd is met andere software en niet of

-3-niet volledig is uitgetest . Als ookk deze noodzakelijk ontwikkelactiviteiten worden ingevuld, zal de ontwikkeltijd en

-inspanning met sprongen toenemen .

Het voorafgaande duidt erop dat software-ontwikkeling meer is dan alleen coderen . Veel tijd wordt in beslag genomen door de eerste fasen van ontwikkeling (vaststellen en analyseren van het objectsysteem, opstellen specificaties, maken ontwerp) en het

testen van de programmatuur . Thibodeau en Dodson (THIBODEAU80) tonen aan dat men bij verdeling van ontwikkeltijd kan sprek :en van de 40-20-40 regel . 40'/% van de tijd komt voor rekening van analyse en ontwerp, 20'/% voor coderen en 40'/% voor testen .

3 . Methoden voor het begroten van softwarekosten .

In de praktijk treft men een groot aantal methoden aan voor tiet begroten van een softwareproject . Over het algemeen zijn deze terug te voeren tot een van de onderstaande basismethoden of een combinatie daarvan .

3 .1 beoordeling door een ex2ert .

Bij deze basismethode gaat men af op het advies van een of meerdere experts . Zij baseren zich bij het begroten van het softwareproject op hun ervaring en inzicht in het op stapel staande project . De kwaliteit van de afgegeven schattingen is ondermeer afhankelijk van de mate waarin het nieuwe project aansluit bij de ervaring van de expert en van het vermogen van de expert om zich feiten van oude projecten te herinneren . In de meeste gevallen maakt de expert gebruik van een aantal vuistregels . De schattingen zijn kwalitatief van aard en veelal niet objectiveerbaar . Het belangrijke probleem bij deze methode is dat het voor iemand anders lastig is deze ervaring en kennis te reproduceren en te gebruiken . Het gevaar bestaat dat vuistregels die op deze wijze zijn ontstaan en zijn voorzien van de kwaliteitsgarantie 'expert-proof' binnen een organisatie de status krijgen van kengetallen en vervolgens toegepast worden in situaties en omgevingen waar deze getallen niet toepasbaar zijn . Deze bezwaren zouden voor een goed deel weggenomen kunnen worden als de expert zijn kennis en ervaringen over oude projecten meer

zou kunnen objectiveren en vastleggen .

De gemiddelde ervaring van een expert is overigens gering als men ervan uitgaat dat softwareprojecten een doorlooptijd hebben van een tot enkele jaren en de expert zijn ervaring in zijn loopbaan slechts kan opbouwen aan de hand van een beperkt aantal projecten . Door de toenemende omvang, complexiteit en verscheidenheid aan softwareprojekten wordt de kans dat de ervaring van een expert niet representatief genoeg is voor een nieuw projekt steeds groter . Daarbij komt dat door de steeds sneller voortschrijdende technologie en veranderingen in de methodologie van software-ontwikkeling, ervaringsfeiten sneller verouderd raken en in waarde verminderen . Voorbeelden van die ontwikkelingen en veranderingen zijn er te over ; denk hierbij aan vierde generatie hulpmiddelen, ontwikkelomgevingen, work-benches, prototyping, end-user computing enz . De ervaring die een expert hiermee heeft opgedaan zal over het algemeen gering zijn terwijl

het gebruik van deze gereedschappen, technieken en methoden bij nieuwe projecten naar verwachting aanzienlijk zal zijn .

Ondanks deze nadelen wordt de "Expert-methode" vaak gebruikt in situaties waarin men snel een eerste indicatie van benodigde tijd, geld, personeel en middelen wil hebben . Met name in de allereerste fase van software-ontwikkeling waarin de specificaties van het produkt nog vaag zijn en voortdurend bijgesteld moeten worden is het gebruik van deze snelle en efficiente methode te verkiezen boven (de nog te bespreken) schattingsmodellen, die veelal om een gedetailleerde en kwantitatieve aanpak vragen .

3 .2 Begroten o_e basis van analogieen .

Bij het schatten op basis van analogieen baseert de schatter zich expliciet op de gegevens van vergelijkbare oude projecteh of vergelijkbare delen c .q . modules hiervan . Wil men in staat zijn een overeenkomst te vinden tussen het nieuwe project en een of meerdere oude projecten dan is een klassificatie en registratie van oude projecten noodzakelijk . Veelal ontbreekt een dergelijk registratiesysteem en is de kennis van een project (of delen ervan) ongestruktureerd aanwezig in de hoofden van enkelen . Voor anderen, die geconfronteerd worden met schattingsproblemen is deze kennis niet toegankelijk . Het is moeilijk aan te geven in hoeverre een vorig project representatief genoeg is voor tiet nieuwe project en wat het effect is van bepaalde verschillen . Door het onderhouden en raadplegen van een (geautomatiseerd) registratiesysteem van oude software-projecten wordt een deel van deze moeilijkheden minder ; er ontstaat een vollediger beeld van het verleden . Wat moeilijk blijft, is het karakteriseren van een

nieuw project . De kwaliteit van een begroting op basis van analogieen is ondermeer afhankelijk van de mate waar-in de schatter in staat is een nieuw project te karakteriseren . Op basis van deze karakteristieken wordt er immers gezocht naar overeenkomsten . Tijdens de voortgang van het project zal men een steeds duidelijker beeld krijgen van het vereiste produkt en zal men steeds beter in staat zijn het project te karakteriseren, daardoor betere analogieen te leggen en tenslotte betere begrotingen te maken . Deze gedachte sluit goed aan bij de opvatting dat het begroten en beheersen van softwarekosten een onde-deel dient te zijn van een projectbeheersingsmethode . Kenmerkend van zo'n beheersingsmethode is de aanwezigheid van mijlpalen/meetpunten . Bij het bereiken van zo'n meetpunt dient men ondermeer de begrotingen bij te stellen op basis van een verbeterd inzicht in het project .

3 .3 De_ methode Price-To-Win .

De methode Price-To-Win is nauwlijks een schattingsmethode te noemen . Het zijn voornamelijk commerciele motieven die een software-ontwikkelaar verleiden tot deze methode . Voorbeelden hiervan zijn te vinden in de literatuur _{(VLlETB7) :}

"Over een half jaar is de efficiency beurs . We moeten kost wat kost onze nieuwe software-produkt dan presenteren" .

-5-"Willen we deze opdracht binnenhalen dan moeten we de prijs laten zakken beneden de fl . 2 .000 .000 . Dan zitten we zeker beneden de prijs van onze concurrenten" .

Deze methode wordt veel gebruikt ondanks het feit dat de afgegeven budgetten en levertermijnen vaak weinig realistisch zijn en het gevaar voor overschrijding ervan levensgroot aanwezig is . De bekende berichten van budgetoverschrijdingen met een factor drie en levertijdoverschrijdingen met een factor twee (MARTIN84) komen veelal op het conto van deze Price-To-Win methode . Mede door de keiharde concurentiestrijd en een gebreF : aan krachtige en betrouwbare hulpmiddelen bij het begroten wordt deze methode vaak gekozen .

3 .4 De methode gebaseerd _ge de wet van Parkinson .

De wet van Parkinson luidt : "Work expands to fill the available volume" . Bij het begroten van een softwareproject betekent dit dat de vereiste programmatuur met het beschikbare budget, tijd, middelen en personeel gerealiseerd moeten worden . Een voorbeeld van deze aanpak is de volgende :

"Gezien onze capaciteitsplanning kunnen we de komende 8 maanden voor de ontwikkeling van dit programma drie mensen vrij maken . De werktijd van het project bedraagt dus 24 mensmaanden" .

Evenals de Price-To-Win methode is ook bij deze methode amper sprake van het maken van een realistische begroting . Het zijn vooral pragmatische overwegingen die bij de keuze voor de Parkinson methode een rol spelen . Ondanks de gebrekkige basis blijkt de methode bij gebruik succesvoller te zijn dan op voorhand wordt verwacht . In veel gevallen wordt een prognose a la Parkinson door het projectteam gedaan en is men verzekerd van het commitment van de teamleden . Juist zo'n commitment blijkt een zeer belangrijke drijfveer te zijn zich te houden aan de afgegeven prognoses . Dit onderscheidt deze methode van de vorige waarbij het bepalen van prijs en levertijd sterk verkoopgedreven zijn en veelal buiten het fiat van de ontwikkelafdeling gebeurt .

3 .5 Earametrische modellen .

Bij het gebruik van het merendeel van de parametrische modellen volgt de schatter een min of meer gelijke aanpak, die steeds gebaseerd is op de volgende negen stappen .

stap 1 . CALIBREER HET MODEL

Voordat een model voor de eerste keer in een bepaalde ontwikkelomgeving toegepast wordt, dient het eerst gecalibreerd te worden . De omgeving waarin het model is ontwikkeld en de projectgegevens die ten grondslag liggen aan het model zullen in de meeste gevallen verschillen van de projectkenmerken van een specifieke ontwikkelomgeving . Om dit calibreren, het op maat maken van het model, mogelijk te maken is het noodzakelijk dat

men beschikt over de gegevens van een representatieve afgesloten projecten . Het structureren en vastleggen ervan zou men als beschouwen . Door Cuelenaere, Heemstra en Genuchten en CUELENAERE87b) wordt de noodzaak van calibratie

stap 2 . DECOMPONEER HET PROJECT ---groot aantal verzamelen, stap 0 kunnen (CUELENAERE87a toegelicht .

Voordat een projectbegroting gemaakt kan worden, dient men een raming te maken van al het werk dat gedaan moet worden om het project met succes af te ronden . Daarvoor is het nodig dat een antwoord gegeven moet worden op ondermeer de volgende twee essentiele vragen :

* Welke fasen c .q . activiteiten onderscheiden .

kunnen in het ~ Welke delen, modules, componenten

wareprodukt onderscheiden .

e .d .

project worden kan men in het soft-Een geschikt hulpmiddel bij de beantwoording van dit

is een zogenaamde _{Software Work Breakdown Structure (WBS) .} een lijst van activiteiten, taken, subtaken, modules, door een software-afdeling worden uitgevoerd TAUSWORTHEBO) . Door de begroter kan deze WBS als worden gebruikt .

stap 3 . BEPAAL DE OMVANG VAN DE SOFTWARE ---een Dit is enz . die (REIFER85, checklist

De volgende stap is het bepalen van de omvang . Veelal wordt deze omvang uitgedrukt in het aantal regels code of het aantal funktiepunten .

stap 4 . VERTAAL DE SCHATTING VAN DE OMVANG NAAR EEN ---SCHATTING VAN DE BENODIGDE INSPANNING

Over het algemeen wordt bij deze omrekening gebruik gemaakt van produktiviteitsmetrieken . Een voorbeeld hiervan is de vergelijking van het type "kosten per instructie" . Deze heeft de vorm :

(b+c)

INSPANNING = a * OMVANG (1)

De benodigde INSPANNING wordt daarbij uitgedrukt in het aantal benodigde mensmaanden of geld om het programma te ontwikkelen . De variabelen a, b en c krijgen hun waarde door middel van regressie analyses op gegevens van oude software-projecten . Naarmate er -1- meer oude projecten geregistreerd zijn

-2- de gegevens per project vollediger zijn en

-3- de totale projectregistratie meer aansluit bij de ontwikkel-omgeving voor het nieuwe programma,

zal men beter in staat zal zijn de waarden van deze variabelen te bepalen .

stap 5 . STEL DE BENODIGDE INSPANNING BIJ DOOR REKENING ---TE HOUDEN MET KOS---TENBEPALENDE FACTOREN

---De benodige inspanning voor een project wordt door een groot aantal factoren bepaald . In (HEEMSTRA87) wordt hiervan een overzicht gegeven . Vergelijking (1) wordt als gevolg daarvan als volgt aangepast :

(b+c)

INSPANNING = a * OMVANG * correctiefactor ~C> waarbij de correctiefactor staat voor :

n

íi' invloedfactor( i ) (3) i=1

Invloedfactor(i) geeft de invloed van de factor i op de softwarekosten weer, behorende bij een bepaalde waarde van die factor voor het nieuw te ontwikkelen produkt . Zo kan de waarde van de factor "kwaliteit van het te ontwikkelen programma" hoog zijn . Invloedfactor(kwaliteit) krijgt dan de waarde die overeenkomt met de invloed van hoge kwaliteitseisen op de softwarekosten . Door de waarden van de afzonderlijke invloedsfactoren met elkaar te vermenigvuldigen, verkrijgt men de correctiefactor . De waarden van de kostenbepalende factoren worden afgeleid uit de gegevens van oude projecten . Degene die de begroting uitvoert zal moeten aangeven wat de waarden van de kostenbepalende factoren zijn voor het nieuwe project . Hij zal dus moeten inschatten wat bijvoorbeeld de complexiteit, vereiste kwaliteit, de mate van gebruikersparticipatie e .d . is . Dit is een moeilijke taak die de nodige expertise vereist en waarbij het beschikken over goede specificaties noodzakelijk is .

stap 6 . STEL DE BEGROTING BIJ DOOR REKENING TE HOUDEN MET ---SPECIALE SOFTWARE EN/OF PROJECTKARAKTERISTIEKEN ---In sommige gevallen kan het nodig zijn de uiteindelijke begroting bij te stellen omdat de programmatuur zo specifiek is, zo afwijkend is van het gangbare assortiment, dat in de verzameling oude projectgegevens te weinig aanknopingspunten zijn . Ook kan het zijn dat de wijze waarop het produkt gemaakt gaat worden anders is dan in het verleden en men zich niet alleen kan baseren op (geregistreerde) ervaringsfeiten . Men kan in zo'n geval denken aan het gebruik van geavanceerde geautomatiseerde hulpmiddelen of een prototyping benadering . De invloed van dergelijke factoren op de kosten worden dan vaak intuitief bepaald ; ervaringsgegevens ontbreken immers .

stap 7 . VERDEEL DE TOTALE INSPANNING OVER DE VERSCHIL- ---LENDE FASEN VAN HET PROJECT

Het percentage van de totale inspanning dat toegewezen wordt aan de verschillende ontwikkelfasen moet empirisch worden bepaald met behulp van opnieuw oude projectgegevens . Een veel gehanteerde verdeling is weergegeven in tabel 1(MARTIN84) . Over de verdeling

bestaat geen eensluidend oordeel . Zo toont een studie van Thibodeau en Dodson aan (THIBODEAU80) dat andere verdelingen evenzo goed in aanmerking komen en dat het percentage in iedere fase in belangrijke mate wordt bepaald door de karakteristieken van het softwareproject . Sommige modellen, zoals PRICE-S (FREIMAN79, SIEREVELT86), veronderstellen dat de verdeling van menskracht gedurende de ontwikkeltijd van een project verloopt

volgens een beta-verdeling . Het bekende model van Putnam (PUTNAM78, PUTNAM79) gaat uit van een Rayleigh-verdeling . Alle studies baseren zich overigens op oude projectgegevens .

fase Y_{% van de ontwikkelinspanning} ---bepalen eisen/behoeften 10

globaal ontwerp 10 detail ontwerp 20 coderen en testen modules 20 integratie en testen 40

---tabel 1 . Verdeling van de inspanning over de fasen in de

ontwikkeling van een softwareprodukt . stap 8 . BEPAAL DE DOORLOOP/ONTWIKKELTIJD

---Behalve het begroten van de benodigde inspanning voor het ontwikkelen van een programma zal ook een prognose gemaakt moeten worden van de' benodigde doorlooptijd en een verdeling hiervan over de fasen c .q . activiteiten . Het begroten van de doorlooptijd zal op een soortgelijke wijze moeten gebeuren als het bepalen van de benodigde inspanning . In een aantal onderzoeken is aangetoond dat de ontwikkeltijd vrij nauwkeurig gerelateerd kan worden aan de inspanning via de volgende vergelijking :

b

ONTWIKKELTIJD = a * INSPANNING (4) waarbij de waarden van a en b empirisch worden vastgesteld met behulp van alweer oude projectgegevens . Als INSPANNING wordt weergegeven in mensmaanden en ONTWIKKELTIJD in maanden dan liggen in de meeste gevallen de waarden van a tussen 2 en 4 en van b tuss--n 0 .25 en 0 .4 (BIRRELL85) . In sommige parametrische modellen wordt aangegeven hoe de ontwikkelinspanning verandert als men gaat afwijken van de nominale waarde voor de ontwikkeltijd, zoals die in (4) is bepaald . Zo gaat het model van Putnam (PUTNAM78) ervan uit dat een geringe verkorting van de ontwikkeltijd een meer dan proportionele inspanning tot gevolg heeft . Andere modellen zoals COCOMO van Boehm (BOEHM81) gaan ervan uit dat de waarde van de ontwikkeltijd voor een project niet beneden een zekere ondergrens kan komen, ongeacht de hoeveelheid extra inspanning die men aan het project toevoegt . Deze extra inspanning gaat verloren in overhead, met name in toenemende communicatie tussen het stijgend aantal leden van het projectteam . Klassiek is uitspraak van Brooks (BROOKS75) in deze :

"Adding manpower to a late software project makes it later"

-9-De verdeling van de ontwikkeltijd over de verschillende fasen c .q . activiteiten zal wederom moeten gebeuren op basis van oude projectgegevens .

stap 9 . VOER GEVOELIGHEIDSANALYSES UIT

Slechts weinig modellen bieden de mogelijkheid gevoeligheidsanalyses uit te voeren . Een uizondering hierop is het model PRICE-S . Door het met kleine stapjes laten wijzigen van de waarde van een (of meerdere) kostenbepalende factor(en) kan men nagaan wat het effect hiervan is op de benodigde inspanning en doorlooptijd . Op deze wijze wordt een stuk "optimalisatie" in het schattingsproces geintroduceerd .

4 . COCOMO : een voorbeeld van een parametrisch model .

4 .1 Inleiding .

Het model COCOMO (COnstructive COst MOdel) is een voorbeeld van een parametrisch schattingsmodel . In deze sektie zal beschreven worden hoe met behulp van dit model een schatting van de software kosten wordt uitgevoerd . Tevens zal aangetoond worden dat de kwaliteit van een model als COCOMO valt of staat met de beschikbaarheid van een uitgebreide verzameling van oude projectgegevens . Er is gekozen voor een beschrijving van COCOMO omdat er geen model is dat op zo'n duidelijke en toegankelijke manier is vastgelegd als dit (BOEHM81 , BOEHM84) .

Van COCOMO bestaan drie versies die onderling verschillen in de mate van detaillering van het schattingsproces .

In de meest eenvoudige versies, BASIC COCOMO, wordt de benodigde inspanning en ontwikkeltijd bepaald volgens soortgelijke formules als (1) en (4) .

INTERMEDIATE COCOMO, de tweede versie, gaat een stap verder in detaillering door naast de omvang nog 15 andere factoren mee te nemen bij het schatten van de kosten . Voor beide versies van COCOMO wordt op basis van historische projectgegevens een verdeling van de inspanning over de ontwikkelfasen van een project gemaakt . Beide versies gaan uit van een top-down benadering . Zij beschouwen het ontwikkelproject in zijn totaliteit, bepalen hiervoor de kosten en ontwikkeltijd en verdelen deze tenslotte over de fasen .

DETAILLED COCOMO, de meest verfijnde versie van COCOMO, gaat uit van een bottom-up benadering . Een nieuw softwareprodukt wordt met behulp van een Work-Breakdown-Structure aanpak gedecomponeerd in een zogenaamd drie hierarchienivo (systeem subsystemen -modules) . De totale inspanning en ontwikkeltijd wordt stap voor stap opgebouwd door eerst de schattingsalgoritmen op module nivo toe te passen, vervolgens op het nivo van subsystemen en tenslotte voor het totale softwareprodukt . Bovendien wordt in DETAILLED COCOMO rekening gehouden met het feit dat een kostenbepalende factor per fase een verschillende invloed op kosten en doorlooptijd kan hebben . In deze sektie zal alleen van INTERMEDIATE COCOMO een beschrijving worden gegeven .

4 .2 INTERMEDIATE COCOMO .

---Bij gebruik van INTERMEDIATE COCOMO moeten de volgen stappen genomen worden :

Stap 1 . Bepaal de ontwikkelomgeving

---In COCOMO worden drie ontwikkelomgevingen onderscheiden : - Organic .

De ontwikkeling vindt plaats in een klein team, dat software in een voor hen vertrouwde omgeving ontwikkelt . Over het algemeen heeft het betreffende ontwikkelteam veel ervaring met

soortgelijke projecten in hun organisatie . De projecten zijn veelal niet groot . Er hoeven weinig initiele kosten te worden gemaakt, men kan snel aan de slag .

- Embedded .

In dit geval heeft men te maken met het ontwikkelen van complexe systemen, waarbij strenge eisen gesteld worden vanuit de omgeving . Het softwareprodukt zal ingebed moeten worden in een weinig flexibele omgeving (bijvoorbeeld :

luchtverkeersgeleidingsysteem) . - Semi-detached .

Een tussenvorm van organic en embedded .

De eerste stap bij het gebruik van COCOMO is het inschatten van de ontwikkelomgeving in kwestie .

Stap 2 . Bepaal de nominale inspanning

---Bij de opzet van COCOMO heeft Boehm gebruik gemaakt van gegevens van 63 oude software-projecten . Met behulp van deze gegevens is de nominale ontwikkelinspanning (in mensmaanden) voor een software-project afgeleid als een funktie van de software-omvang en de ontwikkelomgeving . In tabel 2 zijn deze nominale waarden weergegeven .

ontviikkelomgeving MM(nom) TONT(nom)

---Organic Semi-detached Embedded 1 .05 3 .2*KDSI 1 .12 3 . 0*KDS I 1 .20 2 .8*KDSI 0 .38 2 .5*MM(nom) 0 .25 2 .5*MM(nom) 0 .32 2 .5*MM(nom)

---Tabel 2 . De nominale inspanning als funktie van de ontwikkel-omgeving en het aantal regels code . MM(nom) staat voor het aantal nominale mensmaanden . TONT(nom) staat voor de nominale ontwikkeltijd . KDSI is het aantal

delivered source instructions _{* 1000 (aantal} code-regels maal duizend) .

-11-Stel dat in stap 1 bepaald is dat de ontwikkelomgeving semi-detached is en dat in stap 2 de omvang van het programma geschat is op 100 .000 regels code dan kan aan de hand van tabel 2 de nominale waarden voor inspanning en ontwikkeltijd worden bepaald . Een zwak punt in COCOMO is het schatten van het aantal coderegels . Boehm laat de schatter in de kou staan als het gaat om een manier om deze schatting uit te voeren . De meest geschikte aanpakk in deze situatie lijkt het zoeken naar soortgelijke projecten in het verleden om van daaruit een schatting te maken van de omvang . De kritiek uit de hoek van aanhangers van de Funktiepunt analyse (FPA) of de methode ESTIMACS (RUBIN85) is in deze terecht . COCOMO zou er wat betreft praktische toepasbaarheid op vooruitgaan als voor de bepaling van de nominale inspanning een aanpak volgens de FPA of ESTIMACS gevolgd zou worden .

Stap 3 . Karakteriseer het project aan de hand van

-kostenbepalende factoren .

---In COCOMO worden 15 factoren (cost drivers) onderscheiden die de inspanning en ontwikkeltijd beinvloeden . De mate van de invloed van elke afzonderlijke factor wordt bepaald door de waarde van die factor . Zo zal er meer inspanning nodig zijn naarmate de kwaliteitseisen die aan het programma worden gesteld toenemen . Aan de hand van een uitgebreide analyse van de gegevens van de 63 historische projecten en het oordeel van experts (m .b .v . de Delphi-methode) is in COCOMO voor elke waarde van de 15 factoren de invloed op de nominale waarden kwantitatief bepaald . In tabel 3 is hiervan een overzicht gegeven .

waarde factoren

erg erg e)•:tr- a kostenbepalende factoren laag laag nominaal hoog hoog hoog ---betrouwbaarheid software omvang database complexiteit software beperkingen executietijd beperkingen werkgeheugen vervangingsgraad computer responsietijd kwaliteit analisten

ervaring met applicaties kwaliteit programmeurs ervaring met apparatuur ervaring met prog .taal

gebruik moderne prog .techn . gebruik software tools

eisen aan projectduur

.75 .88 1 .00 1 .15 1 .40 .94 1 .00 1 .08 1 .16 .70 .85 1 .00 1 .15 1 .30 1 .65 1 .00 1 .11 1 .3 0 1 .66 1 .00 1 .06 1 .21 1 .56 .87 1 .00 1 .15 1 .30 .87 1 .00 1 .07 1 .15 1 .46 1 .19 1 .00 .86 .71 1 .29 1 .13 1 .00 .91 .82 1 .42 1 .17 1 .00 .86 .70 1 .21 1 .10 1 .00 .90 1 .14 1 .07 1 .00 .95 1 .24 1 .10 1 .00 .91 .82 1 .24 1 .10 1 .00 .91 .83 1 .23 1 .08 1 .00 1 .04 1 .10 ---tabel 3 . De invloed van de verschillende cost drivers op de

nominale waarden van ontwikkelinspanning en tijd .

-12-In COCOMO wordt van iedere kostenbepalende factor uitvoerig aangegeven wat de betekenis van een zeer lage, lage, nominale enz . factorwaarde is . In deze stap zal de schatter het softwareproject aan de hand van de 15 factoren moeten karakteriseren . In welke mate zal er gebruik worden gemaakt van tools, wat is de kwaliteit van de programmeurs die ingezet worden op het project, wat is de complexiteit van de programmatuur enz . Afhankelijk van die karakterisering geeft COCOMO de bijbehorende beinvloedingswaarden . In het model wordt niet verteld hoe de schatter de karakterisering moet uitvoeren ; een soortgelijk probleem dus als bij de bepaling van de omvang . De meest geschikte aanpak lijkt hierbij een combinatie van de expert-methode en de analogie-expert-methode, waarbij de schatter een uitgebreide databank van oude projecten moet kunnen raadplegen .

Stap 4 . Bepaal de ontwikkelinspanning .

---De totale ontwikkelinspanning voor een nieuw project wordt berekend door de waarde van de nominale inspanning uit stap 2 te vermenigvuldigen met het produkt van de 15 beinvloedingswaarden . De totale inspanning wordt dan bepaald met behulp van de volgende vergelijking :

n

MM = MM(nom) * jT F(i) (5) i=1

waarbij F(i) staat voor de invloed van cost driver i op de inspanning .

Stap 5 . Schat de verdeling van de inspanning en ---tijd over de software-ontwikkelingsfasen .

---De schatting van de ontwikkeltijd wordt afgeleid van de bepaling van de inspanning ; namelijk met behulp van de volgende vergelijking (zie ook tabel 2) :

a

TONT = 2 .5 * MM (6) waarbij de waarde van a afhankelijk is van de soort ontv,ikkelomgeving .

Voor de verdeling van het aantal mensmaanden en de tijd over de verschillende fasen en aktiviteiten per fase biedt INTERMEDIATE COCOMO uitgebreide "verdelingstabellen" . Het principe van een dergelijke tabel is weergegeven in tabel 4 .

Ontwikkelomgeving : Embedded

---fase ---> analyse + bepalen eisen ontwerp enz . omvang software ---> 2 8 32 128 512 (KDSI) 2 8 . . . .

totaal fase %---> 8 8 8 8 8 18 18 ---% per activiteiten act . 1 : analyse 50 48 46 44 42 act . 2 : ontwerp 12 13 14 15 16 act . 3 : coderen 2 4 6 8 10 act . 4 : testplannen 2 3 4 5 6 act . 5 : verificatie + 6 7 8 9 10 validatie 10 10 . . . . . 42 42 . . . . . 10 11 . . . . . 4 5 . . . . . 6 7 . . . . . act . 6 : administratie 16 14 12 10 8 15 13 . . . . . act . 7 : configuratie 5 4 4 4 3 4 3 . . . . . management en kwaliteitbeheer act . 8 : handleidingen 7 7 6 5 5 9 9 . . . . . ---Tabel 4 . Verdeling van de ontwikkelinspanning over de

verschil-lende fasen c .q . activiteiten .

In regel 1 (fase) staan de verschillende ontwikkelfasen genoemd . In regel 2 (omvang software) wordt per fase een onderscheid gemaakt in qua omvang verschillende produkten . In regel 3 wordt aangegeven het percentage

van de totale ontwikkelinspanning voor de betreffende fase en de betreffende produktomvang . In de volgende regels worden per fase en per produktomvang de

verde-ling van de inspanning over de verschillende activitei-ten aangegeven . Bijvoorbeeld : voor de fase ontwerp en voor een softwareprodukt met een omvang van 8 KDSI gaat 10% van de ontwikkelinspanning zitten in activiteit 1

(analyse), 42% in activiteit 2 (ontwerp), etc . Boven-dien wordt aangegeven dat 18% van de totale ontwikkel inspanning voor een programma met een omvang van 8 KDSI voor rekening komt van de fase ontwerp .

5 . Een gebrek aan historische projectgegevens .

Als de genoemde begrotingsmethoden aanspraak willen maken op praktische toepasbaarheid dan dienen zij gebaseerd te zijn op gegevens die verzameld zijn over oude software-projecten . (De methoden Price-To-Win en Parkinson laat ik hierbij buiten beschouwing) . Over het algemeen zijn dergelijke gegevens slechts sporadisch aanwezig . Hiervoor zijn een aantal redenen aan te geven .

Veelal strookt het niet met de geaardheid van de ontwikkelaar om nauwkeurig en in detail zijn activiteiten op papier vast te

-14-leggen . Een veel gehoorde argumentatie onder analisten, ontwerpers en programmeurs in deze is dat zij hun kostbare tijd beter kunnen besteden aan het bouwen van een systeem dan aan het invullen van de meest uiteenlopende formulieren ten behoeve van projectdocumentatie (DAWES85) . Vaak wordt een dergelijk registratiesysteem door de betrokkenen gezien als een stuurinstrument voor het projectmanagement waar zij eerder nadeel dan voordeel van zullen ondervinden . Bestaat binnen een organisatie een dergelijke houding dan is succesvolle registratie van softwareprojecten bij voorbaat uitgesloten . De direct betrokkenen moeten er zelf van overtuigd zijn dat een dergelijk systeem voor hen voordelen biedt . Pas dan kan men rekenen op medewerking en loopt men niet het gevaar dat het systeem wordt geboycot door het aanleveren van onbetrouwbare, onvolledige en loze gegevens . Een en ander betekent dat er een mentaliteitsverandering nodig is en dat de noodzaak van een goede begroting van kosten, inspanning en doorlooptijd en de rol van oude projectgegevens daarin, wordt ingezien . Goede, dat wil zeggen realistische begrotingen, hebben een direct positief effect voor de ontwikkelaars . Zo zal ondermeer de overspannen tijdsdruk waaronder gewerkt moet worden, afnemen en kan men met meer zorg en oog voor kwaliteit een produkt maken .

Het registreren van projectgegevens vindt momenteel hoofdzakelijk vanuit financieel oogpunt plaats ; namelijk het doorberekenen van ontwikkelkosten . Deze gegevens hebben ondermeer betrekking op de totale kosten aan programmeren, analyse en ontwerp, reis- en verblijfkosten, apparatuurkosten e .d . Voor dit doel worden geen gegevens vastgelegd zoals de mate van gebruikersparticipatie, de vereiste kwaliteit en complexiteit van de software, enz . Voor het begroten van de automatiseringsprojecten zijn deze gegevens

echter wel nodig .

Zijn er al gegevens beschikbaar dan blijken deze over meerdere afdelingen en ontwikkelteams verspreid te liggen, waarbij er veelal weinig sprake is van uniformiteit . Zo worden niet altijd dezelfde gegevens verzameld, wordt hetzelfde begrip dooi-verschillende personen verschillend gedefinieerd, zijn el, ver ;chillen in de wijze waarop gegevens worden verzameld en vastgelegd enz . Wil men komen tot een omvangrijke verzameling consistente projectgegevens, die als basis moet dienen voor begrotingsmethoden dan zijn afspraken en richtlijnen in deze een voorwaarde .

Het is vooralsnog niet duidelijk welke gegevens precies geregistreerd moeten worden . In sektie 7 wordt een overzicht gegeven van bestaande project-databases . Wat hierin opvalt is dat in de ene database een andere soorten gegevens worden geregistreerd dan in een andere database . Voor een deel zijn deze verschillen te verklaren uit de verscheidenheid van ontwikkelomgevingen die als basis hebben gediend bij de opbouw van de databases . Bij de goedwillende projectmanager schept dit onduidelijkheid en verwarring . Op het antwoord van de vraag -welke gegevens zijn relevant om geregistreerd te worden - zal hij vanuit de literatuur geen bevredigend antwoord krijgen .

-15-Het belang van goede prognoses van kosten, inspanning ei' doorlooptijd wordt algemeen geaccepteerd . Dat een eigen registratiesyteem van oude projecten hiervoor noodzakelijk is, wordt nog niet alom erkend . Met hoge verwachtingen worden vaak begrotingsmodellen in huis gehaald . Het gemis aan eigen oude projectgegevens wordt, naar men dan verwacht, gecompenseerd door de uitgebreide database die de basis vormt van het model . In de meeste gevallen worden de begrotingen volgens deze aanpak eerder slechter dan beter . Het model krijgt dan ten onrechte de schuld . Eerst van alles zal gezorgd moeten worden voor een calibratie van het begrotingsmodel : dat wil zeggen een aanpassing van tiet model aan de omgeving waarin het gebruikt zal worden . Voor deze aanpassing is het beschikken over een eigen verzameling van oude projecten nodig .

Het feit dat de ontwikkeling van software plaatsvindt in een project organisatievorm heeft een negatieve invloed op het vermogen een adequate registratie van projecten te realiseren . De samenstelling van een ontwikkelteam is van project tot project verschillend . Men werkt niet steeds met dezelfde bemanning . Bovendien verandert de samenstelling van een project gedurende de looptijd voortdurend en wordt het team bij het einde van het project ontbonden . Een dergelijke wisselende samenstelling vereist een snellere en dwingendere vorm van registratie dan bij een vast team . Men kan zich niet veroorloven hiermee te wachten tot aan het einde van het project . Een groot gedeelte van het ontwikkelteam is reeds werkzaam in andere projecten en voelt er weinig voor om alsnog een stuk registratie te verzorgen .

Het is moeilijk in een dergelijke omgeving, die zich bovendien nog kenmerkt door werken onder hoge tijdsdruk, een hoge mate van specialisatie en een grote verscheidenheid van typen projecten een gestruktureerde verzameling van de vet-eiste gegevens van projecten te realiseren .

6 . Het doel van oude projectgegevens .

Het beschikken over historische projectgegevens wordt in de literatuur en de praktijk steeds vaker genoemd als een zinvolle en zelfs noodzakelijke ondersteuning voor de beheersing van het software-ontwikkelingstraject . In deze sektie zal worden aangetoond dat oude projectgegevens als hulpmiddel kunnen dienen bij :

1 . het calibreren van een begrotingsmodel, 2 . het gebruik van begrotingsmethoden,

3 . het beheersen van automatiseringsprojecten, 4 . het analyseren van software-ontwikkeling . 6 .1 OUDE PROJECTGEGEVENS T .B .V HEI

De literatuur over begrotingsmodellen is eensluidend in haar oordeel dat calibratie van ongeacht welk model noodzakelijk is . Modellen als COCOMO, SLIM, JENSEN enz . zijn gebaseerd op projectgegevens van een specifieke software-ontwikkelomgeving . Zo

zijn de vergelijkingen in het COCOMO model van B .Boehm (BOEHM81) afgeleid van een database van 63 projecten die tussen de jaren 1964 en 1979 werden uitgevoerd door het Amerikaanse bedrijf TRW Systems Inc . Het valt te betwijfelen of een dergelijke verzameling van projectgegevens representatief genoeg is voor een ontwikkelomgeving in Nederland anno 1987 . Kunnen in beide situaties dezelfde kostenbepalende factoren worden onderscheiden en is de invloed ervan op de kosten en doorlooptijd gelijk ? Zo zijn in de COCOMO database slechts 7 van de 63 projecten ontwikkeld in een zgn . semi-detached omgeving . Van deze 7 heeft er maar 1 betrekking op de categorie administratieve toepassingen . Het bewuste programma heeft een omvang van 132 .000 regels code en is geprogrammeerd in PL/1 . De waarden van de kostenbepalende factoren wijken over het algemeen weinig af van de nominale waarden . Het is duidelijk dat een organisatie die zich met name richt op de ontwikkeling van administratieve software en RPG als programmeertaal gebruikt en opereert in een semi-detached omgeving, weinig of geen aanknopingspunten vindt in de COCOMO database . Dit wordt nog eens versterkt als in de betreffende organisatie gebruik wordt gemaakt van methoden en technieken die ten tijde van de COCOMO-projecten nog niet bestonden . Om deze redenen is het noodzakelijk een model, voordat het de eerste keer in een specifieke ontwikkelomgeving wordt gebruikt, op maat te maken voor die omgeving . Met andere woorden : het is noodzakelijk het model te calibreren .

Deze noodzaak wordt onderstreept door ondermeer _{een aantal} onderzoeken . Zo gaat Kemerer (KEMERER87) na of begrotingsmodellen te generaliseren zijn naar andere omgevingen dan die waarin ze zijn ontwikkeld . Om deze vraag te beantwoorden maakt hij gebruik van gegevens van 15 afgesloten projecten . Alle projecten hebben betrekking op omvangrijke administratieve applicaties . Met behulp van deze gegevens wordt een schatting gemaakt van het aantal benodigde mensmaanden . Kemerer maakt hierbij gebruik van de modellen COCOMO, SLIM, ESTIMACS en Funktie-Punt-Analyse (FPA) . Per model en per project wordt nagegaan wat de afwijking is tussen het geschatte en het werkelijke aantal mensmaanden . Zowel bij COCOMO als SLIM blijkt bij alle projecten de afgegeven schatting veel te ruim te zijn . Bij het gebruik van SLIM blijkt de gemiddelde overschrijding 772'/, te zijn, bij COCOMO 600% . FPA en ESTIMACS geven duidelijk betere resultaten met overschrijdingen van respectievelijk 100 en 85% . Deze cijfers tonen aan dat begrotingsmodellen niet straffeloos overgeplant kunnen worden in een andere omgeving . Kernerer pleit dan ook voor calibratie .

Een soortgelijk onderzoek is uitgevoerd door Rubin (RUBIN85) . Hij heeft een vergelijking gemaakt tussen de modellen JENSEN, SLIM, GECOMO (een variant van COCOMO) en ESTIMACS . Met behulp van deze modellen is een begroting gemaakt van het aantal mensmaanden en de duur voor de ontwikkeling van een specifiek (administratief) programma . Uit tabel 5 valt af te lezen dat de schattingen onderling sterk verschillen . Rubin geeft als verklaring hiervoor dat de modellen gebaseerd zijn op verschillende databases van oude projecten en niet gecalibreerd zijn op de specifieke ontwikkelomgeving .

-17-modellen .

JENSEN SLIM GECOMO ESTIMACS ---schatting inspanning 940MM 200MM 363MM 17100uur van duur 31 m 17 m 23 m 16 m

tabel 5 . Vergelijking modellen voor wat betreft de schatting van inspanning en duur, (MM = mensmaanden en m= maanden) .

Ook in het onderzoek van Kitchenham en Taylor (KITCHENHAM85) wordt de noodzaak van calibratie aangetoond door de modellen COCOMO en SLIM te evalueren aan de hand van een groot aantal projecten . Evenals Kemerer tonen zij voor beide modellen aan dat in bijna alle gevallen de schattingen van kosten, inspanning en doorlooptijd veel hoger uitvallen dan de-werkelijkheid .

Een aantal onderzoeken hebben zich wat betreft het aspect calibratie geconcentreerd op het model COCOMO . De keuze voor dit model ligt voor de hand omdat Boehm in zijn boek Software Engineering Economics (BOEHM81) een zeer duidelijke uiteenzetting geeft van het model, de benodigde input, output en de gehanteerde database van oude projectgegevens . Twee onderzoeken moeten in dit kader worden genoemd . Miyazaki en Mori (MIYAZAKI85) hebben een uitvoerige evaluatie uitgevoerd van COCOMO . Zij hebben hierbij gebruik gemaakt van de gegevens van 33 oude projecten . Deze verschilde van de COCOMO-projecten inzoverre dat ze over het algemeen ontwikkeld waren in een semi-detached omgeving, veelal geprogrammeerd waren in COBOL en gemiddeld genomen aanzienlijk groter waren in omvang . Ook in dit onderzoek wordt aangetoond dat bij het achterwege blijven van calibratie er een duidelijke overschatting van kosten en duur plaats vindt ; gemiddeld een afwijking van 166% ; slechts in 6'/% van de gevallen was die afwijking minder dan 20% . Op basis van deze onderzoeksresultaten pa ss en Miyazaki en Mori het model COCOMO aan door rekening te houden met de specifieke eigenschappen van de omgeving waarin de projecten tot stand waren gekomen . Zij doen dit door ondermeer een aantal (in hun situatie) niet relevante kostenbepalende factoren uit het model te elimineren . Bovendien stellen zij het model bij door de invloedswaarden van de verschillende factoren te veranderen op basis van hun oude projectgegevens . Het effect van deze calibratie spreekt voor zich . De gemiddelde afwijking bedroeg na calibratie circa 17% . Plaatsen we de evaluatiegegevens van Kemerer en van Miyazaki en Mori naast elkaar dan zien we dat er in het eerste geval sprake is van een overschatting van gemiddeld 600'/% en in het tweede geval van gemiddeld 166'/. . Deze

verschillen alleen al tonen aan dat ontwikkelomgevingen sterk kunnen verschillen en calibratie daarom noodzakelijk is .

Een soortgelijk onderzoek is uitgevoerd door Saalfrank e .a . (SAALFRANK87) . Zij beschrijven een procedure met de naam COKAL waarmee modellen van het type COCOMO gecalibreerd kunnen worden . Een evaluatie van COCOMO met toepassing van COKAL levert significant betere resultaten dan zonder gebruik ervan .

De conclusie uit het bovenstaande is dat calibratie van een begrotingsmodel aan een specieke ontwikkelomgeving noodzakelijk is . Om calibratie mogelijk te maken is het beschikken over voltooide projectgegevens een voorwaarde . Tenslotte moet erop gewezen worden dat calibratie niet een eenmalige activiteit is, maar periodiek herhaald moet worden . Door technologische en methodologische veranderingen bij software-ontwikkeling en door personele en organisatorische wijzigingen kunnen de kenmerken van een ontwikkelomgeving in de loop der tijd wijzigen . Opnieuw calibreren wordt dan noodzakelijk, waarbij men door de introductie van weegfactoren de invloed van projecten op de calibratie kan laten toenemen naarmate het project van recentere datum is .

Een probleem waar vooralsnog vanuit de literatuur geen oplossing is gegeven, is het inschatten van het effect van met name de hierboven genoemde nieuwe technologieen . Zo zal de toepassing van bijvoorbeeld een nieuwe applicatie generator naar verwachting de productiviteit verbeteren en daarmee dus een besparing opleveren van benodigde kosten, ontwikkeltijd en inspanning . Hoe groot die verbetering zal zijn, kan pas gezegd worden als enige ervaring is opgedaan met het nieuwe hulpmiddel . Pas dan is calibratie van het model (wat betreft dit hulpmiddel) mogelijk .

Sceptici beweren dat door het hoge temp waarin veranderingen in de software-ontwikkeling elkaar opvolgen, het gebruik van begrotingsmodellen zinloos is . Men holt immers doorlopend achter de feiten aan .

6 .2 OUDE PROJECTGEGEVENS T .B .V GEBRUIK BEGROTINGSMETHODEN

---- --- --- Het maakt geen verschil of bij het begroten van een automatiseringsproject gebruik wordt gemaakt van de expertmethode, de analogiemethode of parametrische modellen . De begrotingen moeten altijd gebaseerd zijn op oude projectgegevens . Bij gebrek aan dit soort gegevens blijft de kennis van en ervaring met het ontwikkelen van software, met specifieke produkt- en projectkenmerken, met de invloed van kostenbepalende faktoren slechts aanwezig in de hoofden van enkelen . Voor anderen die met soortgelijke problemen geconfronteerd worden, is het moeilijk zoniet onmogelijk deze versnipperde en niet gestruktureerde kennis en ervaring te achterhalen . Op deze wijze worden fouten herhaald . Een databank met oude projectgegevens, waarin die kennis en ervaring uit de hoofden van die enkelingen expliciet wordt gemaakt, kan het projectmanagement ondersteune~, bij het schatten van benodigde tijd, geld en middelen door de relevante informatie over voltooide en vergelijkbare projecten aan te bieden (NOTHB7) .

Bij het gebruik van begrotingsmodellen kunnen oude projectgegevens het projectmanagement ondersteunen bij het bepalen van de invoer voor die modellen . Over het algemeen vereist een dergelijke invoerbepaling veel ervaring in het gebruik van modellen en een ruime kennis en inzicht in het ontwikkelen van software . Zo zal de gebruiker van een model antwoord moeten geven op vragen als ; wat zal de omvang, complexiteit, kwaliteit van het op stapel staande project worden,

-19-in welke mate kan er gebruik gemaakt worden van bestaande ontwerpen, programmatuur e .d . en meer van dergelijk moeilijk te beantwoorden vragen . Oude projectgegevens kunnen hierbij een gerichte ondersteuning bieden . Op basis van karakteristieken van het nieuwe project, zoals type applicatie, soort klant, aantal klanten, te gebruiken programmeertaal e .d ., zou het mogelijk moeten zijn met behulp van geavanceerde raadpleegtechnieken in een databank van oude projecten te zoeken naar projecten met soortgelijke karakteristieken . Als van deze projecten de invoer voor het model is geregistreerd dan kunnen deze gegevens een waardevolle ondersteuning vormen bij elke volgende invoerbepaling . Z ijn bovendien evaluatie- c .q . validatiegegevens van de invoer in de vorm van expertise in de databank opgenome n , dan wordt het projectmanagement niet alleen gesteund door puur cijfermateriaal maar ook door ervaringsfeiten . Zo'n ervaringsfeit zou kunnen zijn dat bij soortgelijke projecten in de fase vooronderzoek in 60% van de gevallen de omvang met een factur 1 .75 te hoog wordt opgegeven .

Het bepalen van kosten, inspanning en doorlooptijd is niet een eenmalige gebeurtenis . In meerdere stadia van het ontwikkeltraject zullen begrotingen gemaakt moeten worden . Gaandeweg de ontwikkeling van een project zal men een steeds beter inzicht krijgen in het eindprodukt en steeds beter in staat zijn dit te karakteriseren . Het zoeken naar analogieen zal daardoor steeds gerichter plaats kunnen vinden en overeenkomsten en verschillen ( en de gevolgen daarvan op de uiteindelijke begroting) zijn beter aan te geven . Dergelijke "evaluatiegegevens" geven het projectmanagement meer inzicht in het schattingsproces, in de mate van onzekerheid bij de invoerbepaling, de fouten die hierbij kunnen optreden en de gevolgen hiervan .

6 .3 . OUDE PROJECTGEGEVENS T .B .V . PROJECTBEHEERSING

Het is niet voldoende een begroting te maken van de hoeveel tijd, geld, personeel, hardware, software en overige middelen die in de verschillende fasen c .q . activiteiten ingezet moeten worden . Het ontwikkelingstraject moet beheerst worden, dat wil zeggen er moet een planning c .q . begroting opgesteld worden ; planning en begroting moeten bewaakt (monitoring), geevalueerd en eventueel bijgesteld worden . Oude projectgegevens kunnen hierbij een waardevol hulpmiddel zijn . Van lopende projecten wordt periodiek gecontroleerd in hoeverre de . afgegeven planning en begroting haalbaar zal zijn . Door gebruik te maken van kengetallen is het mogelijk al in een vroeg stadium een waarschuwing te krijgen over een mogelijke overschrijding van kosten en doorlooptijd . Dergelijke kengetallen zijn gebaseerd op gegevens en ervaring over oude projecten . Een voorbeeld van een dergelijke kengetal

zou kunnen zijn :

als bij de ontwikkeling van een bepaald soort systemen na afronding van het functionele ontwerp 60% van het budget op is dan heeft dat voor de kosten en doorlooptijd die en die gevolgen . Het blijkt dat vaak niet of niet tijdig door het projectmanagement gereageerd wordt op signalen van het

ontwikkelteam en/of de gebruikersorganisatie . Signalen die wijzen op een verstoring van het ontwikkelproces en die een vertragende werking hebben op de doorlooptijd van een project . Door een kritische analyse van oude projecten is het mogelijk een overzicht te geven van dergelijke signalen en aan te geven wat de mogelijke gevolgen zijn van wel of niet hierop reageren . Met behulp van een dergelijke diagnosesysteem kan het projectmanagement een snellere en gerichtere bewaking van de projectvoortgang realiseren . Binnen de afdeling bedrijfskunde van de Technische Universiteit Eindhoven loopt een project voor de ontwikkeling van zo'n diagnosesysteem .

Nog een stap verder is de koppeling van oude projectgegevens en ervaringsfeiten met een projectontwikkelings en -beheersingsmethode . Door bij aanvang van een nieuw project te zoeken naar analoge historische projecten is het mogelijk ontwikkelervaring in de vorm van bestaande ontwerpen, modules e .d . te gebruiken . Tevens is het mogelijk de kennis en ervaring met de beheersing van analoge projecten toe te passen voor het nieuwe project .

6 .4 OUDE _{PROJECTGEGEVENS T .B .V . ANALYSES}

Onder deze noemer kunnen een aantal toepassingen worden gerangschikt .

- Projectgegevens kunnen in de vorm van metrieken gebruikt worden voor produktiviteitsanalyses _{(HA1186) . Hierdoor is het mogelijk}

trends in de produktiviteit van een ontwikkelomgeving te analyseren . Ook kan men nagaan wat het effect op de produktiviteit is van het gebruik van vierde generatiehulpmiddelen, van organisatorische veranderingen, speciaal soort computers, team-samenstelling en andere productiviteits-beinvloedende factoren .

- Door oude projectgegevens te analyseren is het mogelijk marketing strategieen te ondersteunen . Zo kan men onderzoeken met welk type applicatie men de meeste ervaring heeft, in welke taal

in tioofdzaak wordt geprogrammeerd, met welk type computers en operating systemen men veelal werkt, enz . Op deze wijze is het mogelijk een overzicht te krijgen van zaken waarin men veel ervaring heeft c .q . sterk is en waarop een gerichte benadering van de markt gebaseerd kan zijn . De database die als basis diende voor het onderzoek van Walston en Felix _{(WALSTON77) was zo} ingericht dat dergelijke algemene vragen beantwoord konden worden . Door het analyseren van oude projecten is een betere toewijzing van personeel naar projecten mogelijk . Zo kan de databank geraadpleegd worden over welke ontwikkelaars het best wat betreft ervaring en aanleg ingezet kunnen worden op een nieuw project met bepaalde kenmerken .

- Een niet te verwaarlozen resultaat van projectregistratie is een leereffect . Door alleen al impliciet aanwezige kennis, ervaring en feiten expliciet te maken is elk lid van een ontwikkelorganisatie verplicht zich bewuster te verdiepen in een

-21-aantal inhoudelijke en projectmatige zaken van software-ontwikkeling . Omdat van elk project dezelfde verzameling gegevens geregistreerd moeten worden, ontstaat een standaardisatie van projektdocumentatie . Door het uitvoeren van statistische analyses op historische projecten wordt eveneens het inzicht in met name de projectmatige aspecten van software-ontwikkeling vergroot .

7 . Databanken met gegevens over oude softwareprojecten .

De voordelen die behaald kunnen worden met een databank van oude projecten zijn evident . Ondanks deze voordelen is er een groot gebrek aan dit soort gegevensverzamelingen . In sektie 5 zijn een aantal mogelijke oorzaken hiervoor genoemd . In de literatuur over dit onderwerp worden slechts een beperkt aantal databanken van oude projecten genoemd . Veelal is de inhoud dusdanig vertrouwelijk dat uitgebreide informatie niet voorhande is . Een

(niet uitputtend) overzicht van de literatuur laat de volgende databanken zien (zie ook DEKKERB3) :

- Wolverton (WOLVERTON74) beschrijft in algemene termen een database waarin projecten zijn geregistreerd die door TRW Systenis

Inc . ten behoeve van eigen gebruik zijn ontwikkeld .

- Walston en Felix (WALSTON77> hebben in de jaren zeventig een omvangrijke databank van oude projecten opgebouwd . Alle projecten

zijn uitgevoerd bij IBM Federal Systems ( IBM-FSD) en zijn zeer uiteenlopend van aard . Helaas is de opbouw en inhoud van deze databank nooit openbaar gemaakt .

- De meest bekende en meest toegankelijke database is de al eerder genoemde COCOMO database . Hierin zijn 63 projecten opgenomen die tussen de jaren 1964 en 1979 werden uitgevoerd door TRW Systems Inc . De projecten verschillen onderling sterk . Wat omvang betreft lopen de programma's uiteen van 2 .000 tot 1 .000 .000 regels code . De programmeertalen zijn ondermeer assembler, COBOL, FORTRAN en PL/1 . Een breed spectrum van soorten applicaties wordt afgedekt ; administratieve en wetenschappelijke toepassingen maar ook applicaties voor ondere andere procescontroles . Juist die grote verscheidenheid maken de toepassingsmogelijkheden van deze database voor een schattingsmodel als COCOMO twijfelachtig ondanks het groot aantal projecten dat geinventariseerd is .

Gesteld mag worden dat de database te klein en teveel uiteenlopende projecten beschrijft om betrouwbare en algemene uitspraken te kunnen doen over de invloed van de 15 factoren (die door COCOMO worden onderscheiden) op kosten, inspanning en doorlooptijd . Het is aan te bevelen (zie ook CONTEB6) het aantal cost drivers te beperken tot uitsluitend de meest relevante en in een database de gegevens van een homogenere groep projecten vast

te leggen .

- Het Rome Air Development Center beschikt over een uitgebreide databank van oude software-projecten ten behoeve van het Amerikaanse leger . Een aantal modellen zijn hiermee getoetst . Zo

beweert Putnam (PUTNAM78) dat zijn model voor deze projecten goede begrotingen afgeeft . Deze databank is voor buitenstaanders niet toegankelijk .

- Bailey en Basili (BAILEY81) geven een beperkt overzicht van gegevens van 18 NASA projecten die zijn opgenomen in een databank . Een veel uitgebreidere databank is de SDC (Systems Development Corporation) databank . Hierin zijn de gegevens van 169 projecten vastgelegd . Alle projecten zijn uitgevoerd voor 1966 en zijn derhalve niet meer representatief voor 1987 .

- Een groot aantal projecten uitgevoerd voor het ministerie van defensie in Groot-Britannie zijn vastgelegd in een databank (STANLEY84) . Hierin wordt echter geen duidelijk onderscheid gemaakt in software- en hardwaregegevens .

- Bij de ontwikkeling van het PRICE model (FREEMAN79) is gebruik gemaakt van gegevens van honderden projecten . De algoritmen en veronderstellingen waarop het model is gebaseerd, zijn niet gepubliceerd . Hetzelfde geldt voor de gegevens van de oude projecten .

De laatste jaren wordt er op beperkte schaal onderzoek uitgevoerd dat zich expliciet richt op het registreren var] automatiseringsprojecten . Het centrale thema in al deze onderzoeken is de inhoud van een projecten-databank : met andere woorden, welke gegevens dienen opgenomen te worden in een dergelijke databank .

Dekker en van den Bosch (DEKKER83) gevel-] aan dat een softwareproject met behulp van 47 variabelen gekarakteriseerd kan worden . Zij maken daarbij, geinspireerd door het model COCOMO, onderscheid in de volgende 8 categorieen :

variabelen die betrekking hebben op * de projectomvang,

* de moeilijkheidsgraad van het project,

* de vereiste betrouwbaarheid van de software, * beperkingen wat betreft doorlooptijd en geheugen, * mate van hergebruik,

* _{karakterisering van de ontwikkelomgeving,} * typering van het toepassingsgebied,

* karakterisering van de gebruikte middelen .

Van elke variabele geven zij aan na welke fase(n) registratie ervan moet plaatsvinden . Bijvoorbeeld : ervaring met randapparatuur moet vastgelegd worden na de fasen ontwerp en implementatie ; het aantal statements na de fase testen . Het onderzoek gaat niet verder dan een opsomming van relevante variabelen en geeft niet aan .hoe deze variabelen gedefinieerd, gekwantificeerd, verzameld en geregistreerd moeten worden .

Het onderzoek van Kitchenham en Smith (KITCHENHAM80), uitgevoerd als onderdeel van het Alvey Software Data Library project, concentreert zich niet uitsluitend op een inventarisatie van projectgegevens die verzameld moeten worden, maar levert ook een zogenaamd projectregistratie-formulier op . Elk project wordt na afronding door het beantwoorden van een uitgebreide lijst van

-23-vragen op dit formulier beschreven . Doordat de meeste -23-vragen een gesloten karakter hebben, is er impliciet sprake van een (beperkte) definiering en kwalificering . Zo dient het projectteam ondermeer een antwoord te geven op vragen als :

- verwerkingstijd van een programma? enkele seconden < 4 uur

4 - 12 uur > 12 uur

- complexiteit programmatuur? extreem hoog erg hoog hoog

gemiddeld laag

erg laag

- welke technieken zijn in de verschillende fasen gebruikt? - enz .

Bij deze vragen wordt onderscheid gemaakt in vragen die betrekking hebben op het verzamelen van ero,~ectg~gev_ens1 eroduktgege-vens en erocesgegegev_ens_

Projectgegevens hebben primair betrekking op de omgeving waarin het produkt is ontwikkeld . Produktgegevens beschrijven de programmatuur in termen van bijvoorbeeld complexiteit, omvang, e .d . Procesgegevens geven aan met behulp van welke methoden en technieken het produkt ontwikkeld is . Hoewel het onderzoek niet aangeeft wat verstaan moet worden onder bijvoorbeeld erg hoge complexiteit of lage betrokkenheid van de gebruiker, geeft het een eerste aanzet op te komen tot een registratie van oude projecten .

8 . Conclusies .

In dit artikel is een pleidooi gehouden voor het registreren van gegevens van automatiseringsprojecten . De waarde van een dergelijk registratiesysteem voor een organisatie is groot . Zo dient een organisatie te beschikken over vastgelegde feiten, kennis en ervaring van voltooide projecten om op zinvolle wijze begrotingen te kunnen maken van kosten, inspanning en doorlooptijd van een nieuw project . Daarnaast kunnen gegevens van oude projecten nuttig zijn bij het beheersen van softwareprojecten, het uitvoeren van produktiviteitsanalyses en het ontwikkelen van nieuwe programmatuur . Zo kunnen een of

meerdere projecten die grote overeenkomst vertonen met het onderhavige project het management informatie verschaffen over bijvoorbeeld afwijkingen tussen geschatte en gerealiseerde planning, over factoren die de voortgang hebben verstoord, samenstelling van het ontwikkelteam enz . Met behulp van dergelijk soort (beschikbare) ervaringen kan het management sneller en beter plannen door onder andere (delen van) planningen te hergebruiken, maar ook door de samenstelling van het ontwikkelteam gelijk te maken aan die van een succesvol voltooid en vergelijkbaar project . Behalve hergebruik van planningen opent een registratief systeem van voltooide projecten de mogelijkheid van hergebruik van ontwerpen en delen van programma's .

dergelijke registratieve systemen gerealiseerd te zijn . Het onderzoek in deze staat nog in de kinderschoenen . Binnen de afdeling Bedrijfskunde van de Technische Universiteit Eindhoven houdt het onderzoeksteam "Kostenbeheersing van Automatiseringsprojecten" zich bezig met deze problematiek .

9 . literatuurlijst .

(BAILEY81) . Bailey J .W ., Basili V .R ., A meta-model for software development resource expenditures, in : Proceedings of the 5th

international conference on software engineering, IEEE, 1981 _. (BEMELMANS87) . Bemelmans T .M .A ., Bestuurlijke informatiesystemen en automatisering, hoofdstuk 8, derde druk, Stenfert Kroese,

1987 .

(BIRRELL85) . Birrell N .D ., Ould M .A ., A practical handbook for software development, hoofdstuk 2, Cambridge University Press, 1985 .

(BOEHM81) . Boehm B .W ., Software engineering economics, Prentice-Hall, 1981 .

(BOEHM84) . Boehm B .W ., Software engineering economics, in : IEEE transactions on software engineering, SE-10, 1, 1984 .

(BROOKS75) . Brooks F .B ., The mythical Man-Month, essays on software engineering, Addison Wesley Publ . Comp ., London, 1975 .

(CONTE86) . Conte S .D ., Dunsmore H .E ., Shen V .Y ., Software engineering metrics and models, Benjamin Cummins, _{1986 .}

(CUELENEARE87a) . Cueleneare A .M .E ., van Genuchten M .J .I .M ., Heemstra F .J ., Een expert systeem voor het gebruik van een softwarebegrotingsmodel, in : Informatie jrg . 29 nr . 7 special, 1987 .

(CUELENEARE87b) . Cueleneare A .M .E ., van Genuchten M .J .I .M ., Heemstra F .J ., Calibrating a software estimation model : why and how ; Information and software technology, to be published, nov . 87 .

(DAWES85) . Dawes B ., Management techniques to control software development, in : Data Processing, vol . 27 nr . 9, nov . 1985 .

(DEKKER83) . Dekker G .J ., van den Bosch F .J ., Functional requirements for the development and use of a software-cost database, in : Information and Management, nr .6, 1983 .

(FREIMAN79) . Freiman F .R ., Park R .E ., The PRICE software cost model : RCA government systems division, in : IEEE 1979 .

-25-(HALL86) . Hall D .L ., Gibbons J .J ., Knell M ., Quantifying productivity : A software metric database to support realistic cost estimation, in : Proceedings of the international society of parametric analists, 8th annual conference, vol . 5 nr . 1, 1986 .

(HEEMSTRA85) . Heemstra F .J ., problemen bij het ontwikkelen van software : Produktiviteit van programmeurs is laag, in : de automatiseringsgids, nov . 1985 .

(HEEMSTRAB6) . Heemstra F .J ., Het schatten van softwarekosten : een inventarisatie, researchrapport, Technische Universiteit Eindhoven, 1986 .

(HEEMSTRA87) . Heemstra F .J ., Wat bepaalt de kosten van software, in : Informatie irg . 29 nr . 7 special, 1987 .

(HEEMSTRA87a) . Heemstra F .J ., Het begroten van automatiseringsprojecten, in : conferentieverslag Stichting Nederlandse Organisatie voor Bedrijfskundig Onderzoek (NOBO), wordt gepubliceerd in nov . 1987 .

(KEMERER87) . Kemerer C .F ., An empirical validation of software cost estimation models, in : Communications of the ACM, vol . 30 nr . 5, mei 1987 .

(KITCHENHAM85) . Kitchenham B .A ., Taylor N .R ., Software project development cost estimation, in : the journal of systems and software, 5 , 1985 .

(KITCHENHAM85a) . Kitchenham B .A ., Smith M ., Software data library phase 1 manual software collection, in SDM SIG/DP(86), 1985 .

(MARTIN84) . Martin J ., An information systems manifesto, Englewood cliffs, New Jersey, 1984 .

(MIYAZAKI85) . Miyazaki Y ., Mori K ., COCOMO evaluation and tailoring, in : Proceedings of the 8th international conference on software engineering, IEEE 1985 .

(NOTH87) . Noth T ., Unterstutzung des Softwareprojektmanagements durch eine Erfahrungsdatenbank, in : Proceedings Compas '87 Erfolgsfaktoren der integrierten Informationsverarbeitung, AMK Berlijn, mei 1987 .

(PUTNAM78) . Putnam L .H ., A general empirical solution to the macro software sizing and estimating problem, in : IEEE transactions on software engineering, SE-4, 4, 1978 .

(PUTNAM79) . Putnam L .H ., Fitzsimmons A ., Estimating software costs, Datamation, september, oktober en november 1979 .

(REIFERBS) . Reifer D .J ., A poor man's guide to estimating software Costs, in : Texas instruments inc . technical report RC1-TR-012, revised nov . 1, 1985 .

(RUBIN85) . Rubin H .A

., A comparison of cost estimation tools, in : Proceedings of the 8th international conference on software engineering, IEEE, 1985 .

(SAALFRANK87) . Saalfrank R .F ., Schelle H_{., Schnopp R .,} Produktivitatseffekte van AufwandeinfluBgroBe bei der Softwareentwicklung, in : Angewandte Informatik nr . 3, 1097 .

(SIEREVELT86) . Sierevelt H ., PRICE-SP : voordracht op de Technische Universiteit Eindhoven, september 1986 .

(TAUSWORTHE80) . Tausworthe R .C ., the work-breakdown-structure in software project management, in_{: the journal of systems and} software,1,1980 .

(THIBODEAU80) . Thibodeau R ., Dodoson E .N_{., Life cycle phase} interrelationships, in

: the journal of systems and software, 1980 .

(WALSTON77) . _{Walston C .E ., Felix C .P ., A method of programming} measurement and estimation, in : IBM systems journal 16, 1 , 1977 _. (WOLVERTON74) . _{Wolverton R .W ., The cost of developing large-scale} software, in IEEE transactions on computers, _{juni 1974 .}

---Fred Heemstra, okt . 1987 .