Vandfaldsteknikken er opdelt i etaper. Projektledere skal inkludere estimater for mængden af tid (og derfor penge), der kræves for hvert trin i deres projektplaner. Vi har tidligere konstateret, at tidsestimater i sagens natur er problematiske for ethvert projekt, meget mere når de skal sættes tidligt i projektets levetid. Det er bare ikke muligt for softwareprojekter. Overvej muligheden for, at en kvalitativt acceptabel liste over kapaciteter kan blive kompileret i løbet af definitionsfasen. Dette skulle i princippet gøre det muligt for projektgruppen at give et realistisk skøn over den tid, det tager at udvikle hver funktion. Men i virkeligheden er der for mange usikkerheder til at give en rimelig tilnærmelse:
Men i virkeligheden er der for mange usikkerheder til at give en rimelig tilnærmelse:
- Ofte, efter at en funktion er udviklet, opdages det, at klienten ikke har brug for den. Derfor kan de timer, der bruges på at udvikle denne funktion, betragtes som forgæves.
- I løbet af projektet kan kravene ændre sig.
- Skal kapaciteten leveres til en høj pris eller til en lav pris? Der er mange implementerings- og realiseringsteknikker.
- Hvordan vil funktionaliteten være teknisk designet? Designet har stor indflydelse på, hvor lang tid det tager at skabe det.
- I hvilket omfang skal funktionsevnen være af høj standard? Skal en webapplikation for eksempel være fuldt tilgængelig til enhver tid, eller skal den have lov til at være nede et par timer om året?
- Den tid, der kræves for at opdage og rette softwareproblemer, varierer fra minutter til uger.
- Hvor lang tid tager den nye software at installere og integrere med kundens nuværende systemer?
- Mangel på information om potentielle løsninger påvirker yderligere tidsestimater. Derudover er det udfordrende at vurdere den tid, der kræves for at erhverve den nødvendige ekspertise.
Listen ovenfor viser, at en række variabler kan have indflydelse på, hvor lang tid det tager at udvikle et nyt stykke software. Estimater af den tid, det tager at udvikle en funktion ved starten af et projekt, er ofte fire gange for lavt eller fire gange for højt. Dette indebærer, at den nødvendige tid kan være fire gange mere eller fire gange mindre end et fejlagtigt skøn. Efterhånden som projektet udvikler sig, bliver disse skøn mere præcise. Efter at have afsluttet det funktionelle design, reduceres marginen til 25% for meget eller for lidt. Først når funktionen er udviklet, er det muligt at give et skøn med en høj grad af tillid.
Software risici #
Software til projektstyring vil aldrig være helt fejlfri. Selv for velkendte programmer, der er meget udbredte (f.eks. Word, Excel, Explorer, OS X, PHP og Flash), har internettet lister over kendte fejl. Med jævne mellemrum bliver der gjort nye versioner tilgængelige på markedet, som løser softwarefejl. Kunder kræver nogle gange, at software er fejlfri. I virkeligheden ville et sådant mål dog gøre det umuligt at færdiggøre et stykke software. Derudover er softwarefejl ofte ikke iboende i programmet.
Flash blev brugt til at lave et instruktionsspil. Klienten indvilligede i at hente spillet som en fil og installere det på sin egen server. I løbet af projektet bad klienten om, at en high score-funktion blev tilføjet til spillet for at forbedre spillernes konkurrenceevne. Dette ville kræve noget PHP-scriptkode. Spiludviklerne udviklede og testede scriptkoden på deres egen server, der kører Linux. Det lykkedes. Klienten modtog spillet og scriptkoden. Klienten brugte dog en Windows-server, og af en eller anden grund holdt scriptet op med at fungere korrekt. De bedste karakterer blev ikke bibeholdt. Programmøren har i sidste ende brug for en uge til at løse problemet. Som det viser sig, fungerer PHP og Windows ikke altid godt sammen. Manuskriptet i sin helhed havde ingen fejl overhovedet! Han var i stand til at få det til at fungere ved hjælp af et hack, og alle var tilfredse – men hvem skulle betale for den ekstra uges arbejde?
Et andet softwareudviklingsprojekt omfattede også skabelsen af instruktionsapplikationer. Problemet var, at softwaren fungerede godt for udviklerne, men ikke godt for klienten. Efter at have udtømt alle andre muligheder besluttede programmøren at aflægge klienten et besøg. Som det viste sig, kørte kunden en Pentium III-maskine fra begyndelsen af 1990’erne. Computerens langsommelighed bidrog til softwarens dårlige ydeevne. Derudover prøvede programmørerne softwaren på en Pentium III, og det fungerede godt. Yderligere undersøgelser viste, at kundens pc kørte langsomt på grund af en virus- og spywareinfektion.
Håndtering af usikkerheder i projektudvikling #
Den usikkerhed, som ovenstående tilfælde viser, komplicerer processen med udarbejdelse af projektplaner . Derudover komplicerer det forhandlinger mellem parterne. Nogen må bære de risici, der er forbundet med den ekstra arbejdskraft, der skal udføres. Hvis der betales på timebasis, bærer kunden al risiko. Når der aftales et fast honorar (som det er tilfældet med tilskudsfinansierede projekter), bærer softwareudvikleren risikoen. Når der er mere end to personer involveret, bliver situationen mere kompleks. Hvem skal i dette scenarie afholde udgifterne til de ekstra timer, der arbejdes på projektet?
Der opstår ofte uenigheder om, hvem der skal holdes ansvarlig for forsinkelser. Ofte er den ansvarlige person svær at identificere. Det er ganske tænkeligt, at ingen af de involverede parter er skyldige, da “forsinkelsen” skyldes et ukorrekt indledende skøn over det nødvendige antal timer. For mange projekttimer og spørgsmålet om, hvem der skal betale, er almindelige årsager til stridigheder i informationsteknologiindustrien.
