De watervaltechniek is onderverdeeld in fasen. Projectleiders moeten schattingen opnemen voor de hoeveelheid tijd (en dus geld) die nodig is voor elke stap in hun projectplannen. We hebben eerder vastgesteld dat tijdsschattingen inherent problematisch zijn voor elk project, veel meer wanneer ze vroeg in de levensduur van het project moeten worden vastgesteld. Het is gewoon niet haalbaar voor softwareprojecten. Overweeg de mogelijkheid dat er tijdens de definiëringsfase een kwalitatief aanvaardbare lijst van capaciteiten kan worden samengesteld. In principe moet dit het projectteam in staat stellen een realistische inschatting te maken van de tijd die nodig is om elk kenmerk te ontwikkelen. In werkelijkheid zijn er echter te veel onzekerheden om een eerlijke benadering te geven:
In werkelijkheid zijn er echter te veel onzekerheden om een eerlijke benadering te geven:
- Vaak, nadat een functie is ontwikkeld, blijkt dat de klant deze niet nodig heeft. De uren die aan het ontwikkelen van deze functie zijn besteed, kunnen dus als tevergeefs worden beschouwd.
- In de loop van het project kunnen eisen veranderen.
- Moet de mogelijkheid worden geleverd tegen hoge kosten of tegen lage kosten? Er zijn veel implementatie- en realisatietechnieken.
- Hoe wordt de functionaliteit technisch vormgegeven? Het ontwerp is van grote invloed op de hoeveelheid tijd die nodig is om het te maken.
- In hoeverre moet het functioneren van een hoog niveau zijn? Moet een webapplicatie bijvoorbeeld altijd volledig toegankelijk zijn of mag deze een paar uur per jaar uit de lucht?
- De tijd die nodig is om softwareproblemen op te sporen en te verhelpen, varieert van minuten tot weken.
- Hoe lang duurt het voordat de nieuwe software is geïnstalleerd en geïntegreerd met de huidige systemen van de klant?
- Gebrek aan informatie over mogelijke oplossingen beïnvloedt de tijdschattingen verder. Bovendien is het een uitdaging om de benodigde tijd voor het verwerven van de benodigde expertise in te schatten.
De bovenstaande lijst laat zien dat verschillende variabelen van invloed kunnen zijn op de tijd die nodig is om een nieuw stuk software te ontwikkelen. Inschattingen van de tijd die nodig is om een feature te ontwikkelen aan het begin van een project zijn vaak vier keer te laag of vier keer te hoog. Dit houdt in dat de benodigde tijd vier keer meer of vier keer minder kan zijn dan een foutieve schatting. Naarmate het project vordert, worden deze schattingen nauwkeuriger. Na afronding van het functioneel ontwerp wordt de marge verlaagd naar 25% te veel of te weinig. Pas als de feature is ontwikkeld, is het mogelijk om met een hoge mate van zekerheid een schatting te geven.
Softwarerisico’s #
Projectbeheersoftware zal nooit volledig foutloos zijn. Zelfs voor bekende programma’s die veel worden gebruikt (bijv. Word, Excel, Explorer, OS X, PHP en Flash), heeft internet lijsten met bekende fouten. Regelmatig komen er nieuwe versies op de markt die softwarefouten verhelpen. Klanten eisen soms dat software foutloos is. In werkelijkheid zou een dergelijk doel het voltooien van een stuk software echter onhaalbaar maken. Bovendien zijn softwarefouten vaak niet inherent aan het programma.
Flash werd gebruikt om een instructiespel te maken. De klant stemde ermee in om het spel als een bestand te krijgen en het op zijn eigen server te installeren. In de loop van het project vroeg de klant om een highscore-functie aan het spel toe te voegen om het concurrentievermogen van de speler te verbeteren. Dit zou wat PHP-scriptcode nodig hebben. De game-ontwikkelaars ontwikkelden en testten de scriptcode op hun eigen server met Linux. Het was succesvol. De klant heeft de game- en scriptcode ontvangen. De client gebruikte echter een Windows-server en om de een of andere reden werkte het script niet meer goed. De beste cijfers werden niet behouden. De programmeur heeft uiteindelijk een week nodig om het probleem op te lossen. Het blijkt dat PHP en Windows niet altijd goed samen werken. Het script in zijn geheel had helemaal geen fouten! Hij was in staat om het te laten functioneren met behulp van een hack, en iedereen was tevreden – maar wie zou die extra werkweek moeten betalen?
Een ander softwareontwikkelingsproject omvatte ook het maken van educatieve applicaties. Het probleem was dat de software prima werkte voor de ontwikkelaars, maar niet goed voor de klant. Nadat alle andere mogelijkheden waren uitgeput, besloot de programmeur om de klant een bezoek te brengen. Het bleek dat de klant een Pentium III-machine uit het begin van de jaren negentig had. De traagheid van de computer droeg bij aan de slechte prestaties van de software. Bovendien probeerden de programmeurs de software op een Pentium III, en het werkte goed. Nader onderzoek wees uit dat de pc van de klant traag draaide als gevolg van een virus- en spyware-infectie.
Omgaan met onzekerheden in projectontwikkeling #
De onzekerheid die wordt getoond door de bovenstaande gevallen bemoeilijkt het proces van: het ontwikkelen van projectplannen . Bovendien bemoeilijkt het de onderhandelingen tussen partijen. Iemand moet de risico’s dragen die verbonden zijn aan de extra arbeid die moet worden verricht. Bij betaling per uur draagt de opdrachtgever alle risico’s. Wanneer er een vaste vergoeding wordt afgesproken (zoals bij gesubsidieerde projecten het geval is), draagt de softwareontwikkelaar het risico. Wanneer er meer dan twee personen bij betrokken zijn, wordt de situatie complexer. Wie moet in dit scenario de kosten dragen van de extra uren die aan het project zijn gewerkt?
Er ontstaan vaak geschillen over wie verantwoordelijk moet worden gehouden voor vertragingen. Vaak is de verantwoordelijke persoon moeilijk te identificeren. Het is goed denkbaar dat geen van de betrokken partijen schuld treft, aangezien de ‘vertraging’ is veroorzaakt door een verkeerde initiële inschatting van het aantal benodigde uren. Buitensporige projecturen en de vraag wie moet betalen zijn veelvoorkomende twistpunten in de informatietechnologie-industrie.
