Twee werelden voor het schatten van softwareprojecten

Het lijkt op het eerste gezicht dat er twee werelden zijn voor het inschatten van softwareprojecten, voor eenvoud, Ik zal de ‘Chaotische’ en de ‘Gecontroleerde’ werelden noemen. De chaotische wereld wordt gekenmerkt door de meerderheid van de organisaties wiens projecten vaak op tijd en budget worden overschreden, of die helemaal mislukken. De gecontroleerde wereld heeft een veel kleinere populatie van voorbeeldorganisaties waarvan wordt beweerd dat projecten routinematig op tijd en binnen budget worden opgeleverd. De interessante vraag is waarom organisaties in de Chaotische wereld niet zomaar het gedrag van degenen in de Gecontroleerde wereld leren en kopiëren en daarmee zichzelf een hoop geld besparen..
Dit artikel verkent de twee werelden en probeert de verschillen uit te leggen die deels intrinsiek en tot op zekere hoogte onvermijdelijk zijn, en deels door een mix van cultureel, proces- en technische factoren, waarvan er verschillende kunnen worden overwonnen met voldoende inspanning en doorzettingsvermogen.
Eerste, het bewijs voor de twee werelden.

De chaotische wereld

Er zijn meerdere onderzoeken geweest, over het resultaat van duizenden softwareprojecten, voornamelijk in de VS en het VK en voornamelijk van projecten op het gebied van bedrijfsapplicatiesoftware, in de publieke of private sector. Strikt genomen moeten we spreken van ‘software-intensieve systeemprojecten’, aangezien voor veel van dergelijke projecten de levering van de software slechts een onderdeel is van een project dat een hardware-/softwaresysteem moet opleveren en vaak ook een organisatorische verandering. Ik gebruik 'softwareprojecten' voor de eenvoud. De resultaten variëren maar geven aan dat tussen 10% – 30% van de softwareprojecten mislukken volledig, d.w.z. ze worden gestopt voordat ze iets nuttigs afleveren. Een ander ongeveer 50% overschrijding van tijd en/of budget met minimaal 10%. Dit laat alleen 20% – 40% projecten op tijd en binnen budget opgeleverd.

Echter, deze cijfers weerspiegelen niet het feit dat veel projecten minder functionaliteit of bedrijfswaarde opleveren dan oorspronkelijk was gepland. Verder, een onbekend deel van de projecten die 'op tijd en binnen budget' zijn voltooid, is mogelijk in de eerste plaats overschat en had dus sneller en tegen lagere kosten kunnen worden opgeleverd. Abdel-Hamid merkte op dat de wet van Parkinson net als elke andere activiteit van toepassing is op softwareprojecten, d.w.z. het werk breidt zich uit om de tijd te vullen die beschikbaar is voor de voltooiing ervan.

De kosten van deze overschrijdingen en mislukkingen zijn enorm. Een goed gedocumenteerde analyse van 105 gecontracteerde softwareprojecten die in de loop van de tien jaar zijn voltooid 2007 tussen klanten in de Britse publieke sector en externe leveranciers hadden een totale waarde van £ 29,5 miljard. Van deze, 30% werden beëindigd, 57% ervaren kostenoverschrijdingen gemiddeld 30.5% (in totaal £ 9 miljard aan overschrijdingen), terwijl 33% grote vertraging opgelopen. Een belangrijk punt om op te merken is dat al deze projecten zijn uitgevoerd door externe leveranciers die wereldwijd opereren en in hun marketing beweren 'van wereldklasse' te zijn. Verder, de winstmarge van de leveranciers op de contracten was bijna altijd voorbij 10%, oplopend tot 25%.

Dezelfde redenen voor deze storingen en overschrijdingen worden herhaaldelijk genoemd, tenminste teruggaan 30 jaar zoals beschreven in het boek Crash! Ze vallen uiteen in twee hoofdgroepen.

1. Gebrek aan betrokkenheid van senior management en betrokkenheid van gebruikers, resulterend in onduidelijke doelstellingen, wat leidt tot belangenconflicten, en onduidelijke en verschuivende eisen.
2. Slecht projectmanagement (bv. bij het managen van voortgang en veranderingen), onervarenheid personeel, vooral als er nieuwe technologie bij komt kijken, en personeelsverloop.

Terwijl de kosten van de storingen en overschrijdingen zwaar kunnen worden gewogen door afschrijvingen op hardware, de kosten van het inhuren van extra personeel, verloren voordelen, enzovoort., de oorzaken zijn bijna altijd te wijten aan problemen met het specificeren en ontwikkelen van de software.

In alle verschillende analyses van waarom softwareprojecten mislukken of uitlopen, het komt niet vaak voor dat ‘slechte inschatting’ als een van de oorzaken wordt vermeld. Dat is niet verwonderlijk voor de projecten die mislukken. Een slechte schatting lijkt een onwaarschijnlijke reden om een ​​project te staken. Het is waarschijnlijker dat het is gestopt omdat de prioriteiten sinds het begin zijn gewijzigd en het niets nuttigs meer zal opleveren, of het is zo lang voorbij het oorspronkelijke budget gegaan dat het management besluit de verliezen te beperken. Maar als, inspraak, 57% van alle softwareprojecten overlopen met gemiddeld meer dan 30%, men moet zich afvragen 'is er systematisch iets mis met het schattingsproces in deze omgevingen'?’

De gecontroleerde wereld

Van tijd tot tijd vangen we een glimp op van deze andere wereld wanneer een organisatie resultaten publiceert die haar successen bij het schatten van softwareprojecten laten zien. Het voorbeeld dat ik zal gebruiken is Renault, de Franse autofabrikant, die zijn voortgang in het schatten van succesvolle softwareprojecten heeft gepubliceerd, laatst binnen 2014.

Een moderne doorsnee gezinsauto heeft ongeveer 50 Elektronische regeleenheden (ECU's), kleine processors die een gedistribueerd netwerk vormen om bijna elke functie te bewaken en/of te besturen, bv. motor, lichten, airconditioning, bandenspanning, navigatie, bestuurder informatie, enzovoort. De ECU's en hun embedded software worden meestal gekocht bij leveranciers van componenten met hun bijbehorende sensoren, afhankelijk van de specificaties van Renault.
Renault verzamelt al enkele jaren gegevens over de kosten en prestaties van zijn leveranciers van ECU-software. Het proces waarmee het contracteert om ECU's aan te schaffen, is kort:

• Softwareafdelingen van Renault, gespecialiseerd per voertuigfunctioneel gebied (bv. aandrijflijn), specificaties ontwikkelen voor nieuwe of verbeterde ECU-software en deze opslaan in de Matlab Simulink-tool;
• Een door Renault ontwikkelde tool berekent vervolgens automatisch de functionele omvang van elke specificatie (of de toename in grootte als een verbetering) met behulp van de ISO-norm COSMIC methode;
• Metingen uit het verleden en statistisch vastgestelde verbanden worden gebruikt om de inspanning te voorspellen die de leverancier nodig heeft om de software te ontwikkelen (zie afb. 1) en de geheugengrootte (Afb. 2);
• Deze informatie wordt door de inkoopafdeling gebruikt om te onderhandelen over de prijs van de ECU. Verder, de informatie waarover Renault beschikt is nu voldoende betrouwbaar om te kunnen onderhandelen over jaarlijkse prijsveranderingen, op dezelfde manier waarop autofabrikanten periodiek onderhandelen over prijzen van andere materialen, zoals staal, verven enz., en andere componenten. (Afb. 3);
• COSMIC-functionaliteitsgroottes worden ook gebruikt om de prestaties van de interne softwareafdeling te bewaken, omdat Renault voor hun werk een relatie heeft opgebouwd tussen specificatiegrootte en personeelsniveau.

Renault stelt dat aan het einde van een nieuwe softwareontwikkeling, het verschil tussen de aanvankelijk geschatte inspanning uit de vastgestelde correlatie en de werkelijke waarde ‘moet kleiner zijn dan 5%’ (zie afb. 4).

Afb. 1 Inspanning versus COSMIC-grootte voor ECU-software

Afb. 2 Geheugengebruik versus COSMIC-grootte

Afb. 3 Onderhandelingen afdeling inkoop

Afb. 4 Controle van de nauwkeurigheid van kostenramingen

Verschillen tussen de chaotische en gecontroleerde wereld van het schatten van softwareprojecten

In de volgende, aangezien projectschattingen voor de hele levensduur vereist zijn, ongeacht de projectmanagementbenadering, Ik zal voor het gemak een watervalmodel van projectfasen gebruiken. Verschillen bij het gebruik van een iteratief of agile model worden vermeld zodra ze zich voordoen. Dat moeten we ook aannemen in de vergelijkingen van de Chaotische en Gecontroleerde werelden, de organisaties in beide werelden hebben redelijk herhaalbare processen en gebruiken technologie waarmee ze redelijk vertrouwd zijn, d.w.z. we negeren omgevingen waar de onvolwassenheid van processen en de risico's die gepaard gaan met het gebruik van nieuwe technologie weinig kans laten om nauwkeurige schattingsmethoden te ontwikkelen.

Verschillende voorwaarden voor de schatting. In een zin, het is oneerlijk om een ​​vergelijking te maken tussen de twee werelden, aangezien er een paar intrinsieke verschillen tussen zijn.

Het eerste en meest voor de hand liggende verschil is dat in de chaotische wereld, een kostenraming voor de hele levensduur is meestal nodig voor een vroeg stadium van een bedrijfstoepassingsproject, voordat de vereisten in detail bekend zijn, om de kosten/batenanalyse voor de software te informeren.

In tegenstelling tot, projecten in de gecontroleerde wereld van Renault worden pas gemaakt als het softwareontwerp volledig is gespecificeerd, d.w.z. het zijn niet echt levenslange schattingen. Door dit stadium, schattingen kunnen ook worden gemaakt op een laag niveau van ontbinding (Simulink blokkeert in het geval van Renault) voordat ze worden opgeteld bij de kosten van de hele ECU.

Het is duidelijk dat men zou verwachten dat de schattingen van Renault veel nauwkeuriger zijn dan die in de vroege stadia van een typisch zakelijk toepassingsproject. Dat gezegd te hebben, het is dan legitiem om te vragen waarom schattingen zo vroeg in het leven van een project zijn gemaakt, terwijl er nog zoveel onzekerheid is, geaccepteerd worden als vast, zodat overschrijdingen vaak voorkomen. Verder, lopende onderhouds- en ondersteuningskosten die bijdragen aan de businesscase blijken vaak veel hoger uit te vallen dan in dit vroege stadium was voorspeld.

Culturele verschillen. Een studie van Jorgensen over schattingspraktijken vertelt ons veel over de cultuur van de chaotische wereld. Uit zijn onderzoek bleek dat 'schatting door deskundigen' de dominante strategie is voor het inschatten van de inspanning van ontwikkelingsprojecten gedurende het hele leven. Hij definieerde deskundige schatting als 'werk uitgevoerd door een persoon die wordt erkend als een expert op het gebied van de taak', en dat een aanzienlijk deel van het schattingsproces is gebaseerd op een niet-expliciet en niet-herstelbaar redeneerproces, d.w.z. 'intuïtie''. Hoewel dit onderzoek is gepubliceerd in 2004, Jorgensen vertelde me onlangs dat hij geen gepubliceerde gegevens kende die deze opvatting veranderden dat schatting door experts nog steeds de schatting van de projectinspanning domineert.

In tegenstelling tot, mijn informele observatie is dat de organisaties in de gecontroleerde wereld die gegevens publiceren die wijzen op een hoge nauwkeurigheid voor projectschattingen, meestal hi-tech productiebedrijven zijn, produceren vaak veiligheidskritische of bedrijfskritische software. Deze projecten vragen veel aandacht voor kwaliteit, dus beginnen ze met het voordeel van een 'echte' ingenieursmentaliteit, vertrouwen op gegevens in plaats van alleen oordeel.

Deze culturele verschillen zijn van invloed op de nauwkeurigheid van projectschattingen. Daniël Kahneman, een psycholoog die won 2002 Nobelprijs voor economie beschrijft twee manieren van menselijk denken, intuïtief en rationeel. Meestal denken we intuïtief; het vereist echte discipline om op de rationele manier te denken. Zijn belangrijkste bevinding die relevant is voor schatten is dat intuïtief denken bijna altijd optimistisch is en de neiging heeft om statistieken en ervaringen uit het verleden te negeren (bv. gelovend 'deze keer doen we het goed'). Hij beveelt aan om definitieve voorspellende beslissingen aan formules over te laten, en bij voorkeur eenvoudige met weinig variabelen.

Deze aanbeveling toepassen op een projectkostenraming op basis van intuïtief denken, bv. naar analogie, suggereert dat als het milieu de hierboven genoemde staat van dienst heeft voor projecten in de Britse publieke sector, dan moet de business case rekening houden met de 30% risico op totale mislukking, en elke intuïtieve kostenraming moet automatisch worden verhoogd met 15% – 20% met een overeenkomstige toename van de onzekerheid.

Kahneman heeft nog andere aanbevelingen die van belang zijn om in te schatten wanneer harde data ontbreken, bv. het gebruik van processen zoals breedband Delphi (of ‘Planning Poker’ in de agile wereld), in plaats van te vertrouwen op de expertise van een individu.

Inzicht in de rollen van de verschillende spelers die betrokken zijn bij schattingen. De verantwoordelijkheid van een schatter is om een ​​projectinspanningscijfer te produceren op basis van de best beschikbare gegevens, met een passende vermelding van het bereik van de onzekerheid van de schatting. Dat is alles.

Het is de taak van de manager om de aannames van de schatter te begrijpen, het risico en de onzekerheid beoordelen, en uiteindelijk om te beslissen over de projectbegroting. Als de mentaliteit van de manager is om op de schatter te vertrouwen en risico's te negeren (bv. met de houding van de manager van Dilbert van 'geef me maar een nummer') het project is gedoemd zijn budget te missen.

Verder, wanneer een klant een ITT afgeeft om software aan te schaffen bij een externe leverancier, de klant moet andere factoren begrijpen die van invloed zijn op hoe een leverancier tot zijn schattingen en biedprijzen komt.

Leveranciers van uitbestede softwaresystemen zijn voor hun voortbestaan ​​afhankelijk van betrouwbare schattingen - en we hebben hierboven opgemerkt dat ze normaal gesproken een goede staat van dienst hebben op het gebied van winstgevendheid. Daarom nemen ze het verzamelen van softwarestatistieken en het gebruik ervan voor schattingen normaal gesproken zeer serieus, veel meer dan een typische interne IT-afdeling of de behouden IT-functie van een klant die zijn uitbestede IT-leveranciers beheert.

Bij een leverancier, de kostenraming op basis van de vereisteninformatie in de ITT van de klant wordt door het verkoopteam omgezet in een winprijs. In dit proces, ze houden rekening met veel voor de hand liggende factoren, zoals het verwachte budget van de klant, de waarschijnlijke concurrentie, toekomstige cashflow, gewenste winstgevendheid, enzovoort.

Twee andere minder gewaardeerde maar belangrijke factoren worden ook overwogen. Eerste, naarmate het project vordert, de klant zal onvermijdelijk nieuwe of gewijzigde eisen bedenken die boven de biedprijs extra in rekening kunnen worden gebracht. Tweede, de winnaar van het initiële ontwikkelingsproject is het best geplaatst om het lopende onderhouds- en ondersteuningswerk gedurende de levensduur van het systeem binnen te halen. Zowel deze aanvullende als lopende activiteiten kunnen veel winstgevender zijn dan het initiële ontwikkelingswerk. bijgevolg, een leverancier kan laag bieden voor de initiële ontwikkeling om een ​​overwinning te verzekeren.

helaas, toen de eerste grote golf van IT-outsourcing in de Britse publieke sector meer dan twintig jaar geleden begon, de meeste ervaring met softwarestatistieken en schattingen werd uitbesteed aan de leveranciers in het kader van langetermijncontracten. Dit heeft geleid tot ernstige 'informatieasymmetrie' tussen klanten en hun leveranciers en is vrijwel zeker een belangrijke oorzaak van de hoge budgetoverschrijdingen van IT-projecten in de Britse publieke sector.

Voor een autofabrikant, inkoop is een van de belangrijkste functies. In het geval van IT-aanbestedingen in de Britse publieke sector, in feite droeg de jachtopziener zijn metrische expertise over aan de stropers.

Een andere oorzaak van projectoverschrijdingen kan ontstaan ​​in de manier waarop reserves voor onvoorziene uitgaven worden beheerd. Deze moeten worden bijgehouden door een manager op projectportfolioniveau en indien nodig worden vrijgegeven aan projectmanagers, in plaats van aan het begin toegewezen te worden aan individuele projecten. Eerste, kennis van de onvoorziene omstandigheden die in een schatting zijn opgenomen, geeft de projectmanager troost en de wet van Parkinson zorgt ervoor dat deze zal worden gebruikt. Hetzelfde geldt voor een uitbestede relatie, waar Kahneman citeert 'een budgetreserve is voor aannemers zoals rood vlees voor leeuwen; ze verslinden het'.

Inschattingstechnieken. Veel software projectschatten in de gecontroleerde wereld, zoals Renault illustreert, probeert de dominante kostengedreven vraag 'hoe groot is het' te beantwoorden?' door op ervaring gebaseerde schattingen te maken van het aantal broncoderegels (SLOC). De bekende COCOMO II-schattingsmethode en de meeste in de handel verkrijgbare schattingstools zijn gekalibreerd met behulp van SLOC-maten als invoer. Ondanks de vele, vaak gepubliceerde nadelen van SLOC-maten, schattingsnauwkeurigheid op basis van het oordeel van deskundigen op basis van gedetailleerde ontwerpen wordt doorgaans als tot op het bot nauwkeurig geacht 10% op componentniveau.

In de chaotische wereld, als er meer nodig is dan intuïtie of deskundig oordeel voor schattingen wanneer er alleen vereisten op hoofdlijnen bestaan, het is het meest gebruikelijk om eerst de omvang van de vereisten in te schatten met behulp van functiepuntanalyse (FPA). Grootte wordt vervolgens omgezet in inspanning met behulp van productiviteitsbenchmarks die zijn afgeleid van eerdere vergelijkbare projecten. Albrechts oorspronkelijke FPA-idee eind jaren 70 om een ​​maatstaf voor de grootte van een softwaresysteem voor te stellen op basis van de functionele vereisten, was een briljant staaltje lateraal denken.. Maar deze methode, nu ontwikkeld en ondersteund door de IFPUG-organisatie, toont zijn leeftijd.

De COSMIC-methode gebruikt door Renault is ontworpen door een internationale groep experts op het gebied van softwaremetrie om toepasbaar te zijn in het bedrijfsleven, real-time en infrastructuursoftware, gebaseerd op fundamentele software-engineeringprincipes. Variaties van de methode om geschatte maten te produceren zijn beschikbaar om vereisten te meten voordat ze voldoende gedetailleerd bekend zijn voor een nauwkeurige meting, en de werkwijze is of wordt op verschillende manieren geautomatiseerd. (Geautomatiseerde metingen zijn cruciaal voor Renault; handmatig tellen zou te traag zijn voor hun ontwikkelingsproces.) De methode is bij uitstek geschikt voor het meten van eisen op elk aggregatieniveau in agile ontwikkelingen, bv. Gebruikersverhalen. Iteraties, releases, enzovoort., en voor de componenten van gedistribueerde systemen.

Een voorbeeld van een probleem dat vermeden kan worden door het gebruik van de COSMIC-methode deed zich voor bij een groot Europees pensioenfonds dat de IFPUG FPA-methode had gebruikt voor dimensionering als basis voor schattingen. De FPA-schaal biedt slechts een beperkt aantal maten voor transacties; de COSMIC-methode meet op een verhoudingsschaal zonder bovengrens. Eén project werd onderzocht om erachter te komen hoe het ernstig was onderschat. Sommige transacties scoorden het IFPUG-maximum van 6 of 7 FP's werden opnieuw gemeten met behulp van de COSMIC-methode en bleken voorbij te zijn 60 COSMIC FP's. De transacties met omvang over 40 COSMIC FP's waren goed voor bijna 80% van de budgetoverschrijding.

Wat kan er worden gedaan om de schattingskloof van de chaotische naar de gecontroleerde wereld te overbruggen?

Het advies van Jorgensen over hoe u het beste kunt halen uit het maken van schattingen door deskundigen wordt sterk aanbevolen en er moet rekening worden gehouden met de opmerkingen van Kahneman over prognoses op basis van intuïtief oordeel.. Maar als de chaotische wereld de kloof moet overbruggen, het moet meer doen dan vertrouwen op intuïtieve schattingen. Het moet harde prestatiegegevens over voltooide projecten verzamelen en eenvoudige schattingsmethoden ontwikkelen met behulp van moderne methoden voor het meten van vereisten. Als u bij een externe leverancier koopt, klanten moeten leren hoe leveranciers hun biedprijzen bepalen.

Zelfs met deze stappen, er blijft het intrinsieke probleem in de chaotische wereld dat schattingen vaak nodig zijn en budgetten vroeg in het leven van een softwaresysteem moeten worden vastgesteld voordat de vereisten in detail bekend zijn. In dit stadium moet een schatting onvermijdelijk een zeer brede onzekerheidsmarge hebben. Dus wat kan er worden gedaan om de effecten van deze uitdaging te verzachten?

Het antwoord is een proces dat is ontwikkeld 15 jaar geleden door de regering van de staat Victoria in Australië, maar is nooit op grote schaal toegepast.
In vereenvoudigde schets, wanneer een klant een ITT afgeeft met een eerste programma van eisen, leveranciers wordt gevraagd om de uiteindelijke totale omvang in te schatten en een vaste prijs per functionele eenheid te bieden. De totale biedprijs is dan het product van deze twee factoren. Wanneer een contract wordt gegund en naarmate de eisen evolueren, de eenheidsprijs blijft vast, maar de totale prijs zal variëren in verhouding tot de omvang van de vereisten. De werkelijke grootte wordt bewaakt door een onafhankelijke Scope Manager, een ‘kwantiteitsmeter’ van software. De klant draagt ​​dus het risico van variatie in de omvang van de eisen; de leverancier draagt ​​het risico de juiste eenheidsprijs te bieden op basis van zijn kennis van de behoeften van de klant en van zijn eigen capaciteiten. Met dit proces, de informatie- en risico-asymmetrieën tussen klant en leverancier worden enorm verminderd.

Het Australische proces is verfijnd in Finland, waar het bekend staat als 'Northern Scope'. Het wordt in verschillende landen toegepast of uitgeprobeerd. Voorstanders van de methode beweren dat kostenoverschrijdingen tot binnen kunnen worden teruggebracht 10%.

Maar de grootste geclaimde voordelen zijn zeer substantiële verlagingen van de eenheidskosten van software en verbeteringen in de snelheid van oplevering van softwareprojecten. Het vermogen om eisen te meten speelt hier een grotere rol dan men zich zou kunnen voorstellen, namelijk als kwaliteitscontrolefactor. Als de vereisten niet nauwkeurig genoeg zijn om ze te kunnen meten, de software kan zeker niet betrouwbaar worden gebouwd en getest! Het zal duidelijk zijn dat zowel het Renault-proces voor het beheer van de levering van ingebedde software voor zijn ECU's als het Northern Scope-proces berusten op software-eenheidsprijzen als een belangrijk kenmerk.

Het vinden van alle koppelingen tussen componenten kan voor sommige technologieën moeilijk of onmogelijk zijn, de tools zijn beschikbaar voor de chaotische wereld om de kloof met de gecontroleerde wereld grotendeels te dichten bij het schatten van softwareprojecten. Maar er zijn geen zilveren kogels, geen snelle en pasklare antwoorden. Een ingenieursmentaliteit en de bereidheid om te investeren in het verzamelen en analyseren van actuele prestatiegegevens zijn essentieel.

Over de auteur

Charles Symons is oprichter en voormalig voorzitter van de Common Software Measurement International Consortium. U kunt contact met hem opnemen via cr.symons@btinternet.com. Dit bericht verscheen eerder in de 2015 winterse nieuwsbrief van de Vereniging voor kostenanalyse en prognoses.

Een blogpost vertegenwoordigt de persoonlijke mening van de auteur
en hoeft niet noodzakelijkerwijs samen te vallen met het officiële Nesma-beleid.