Vattenfallsmodellen känns för många som en ganska självklar utvecklingsmodell. I praktiken visar det sig dock att det finns en del problem med modellen.
Låt oss titta på några ganska självklara önskemål man kan ha på ett projekt.
Vi vill kunna
Många problem uppstår i ett tidigt skede. I värsta fall löser vi fel problem, på grund av slarvig analys eller missförstånd i diskussioner med kunden. Det kan också hända att kunden inte vet vad han vill ha eller att problemets förutsättningar hinner förändras innan projektet är klart. En extrem situation kan vara att ett mera tekniskt komplicerat projekt inte ens går att genomföra till en kostnad som motsvarar värdet av projektet. I så fall ligger ju misstaget i att man startade projektet. Om man har gjort fel i något skede vill man förstås få reda på det så tidigt som möjligt.
När man skissar på det system som ska byggas är ett vanligt problem att det är svårt att uppskatta hur svåra delproblem är att lösa. Det är vanligt att vissa aspekter får för mycket uppmärksamhet medan andra ignoreras. Det är lätt att man underskattar (eller överskattar) prestandaproblem, väljer lösningar som är onödigt svåra att implementera eller missar att ta hänsyn till viktiga aspekter av problemet.
Naturligtvis kan det även gå snett i implementationsfasen; lösningar fördröjs eller håller för dålig kvalitet eller missförstånd leder till att fel uppgift löses. Det kan vara svårt att bedöma hur ett projekt ligger till tidsmässigt. I de fall ett projekt blir försenat är det ofta till och med i efterhand svårt att avgöra var problemen uppstod. Om den färdiga lösningen gör fel sak, handlar det om ett misstag i implementationsarbetet eller skedde misstagen i analys- eller designfasen?
Det tråkiga med vattenfallsmodellen är att den inte har (åtminstone inte i sin enklaste form) någon naturlig mekanism för att fånga upp och rätta till fel av de typer som jag tog upp i föregående avsnitt.
Ett annat problem med vattenfallsmodellen är att den kräver att viktiga beslut fattas tidigt. Det finns dessutom inget bra sätt att få återkoppling om man fattat dåliga beslut i analys- eller designfasen. Det är svårt att upptäcka om projektet är försenat, eller om det implementerar fel sak. Det finns inte heller nåt bra sätt att hantera förändringar i problemspecifikationen.
Ett vanligt problem med projekt är att vi fattar de viktigaste besluten om systemet tidigt:
men vi lär oss mer om problemet vi vill lösa efterhand:
Så vi fattar de viktigaste besluten tidigt, när vi vet minst om konsekvenserna. När vi har utvecklat en förståelse för problemställningen och de tekniska aspekterna är det redan försent.
Detta problem gäller förstås alla projekt, oavsett vilken modell man använder. Kritiken mot vattenfall är att det inte finns någon naturlig mekanism för att hantera detta.
Vattenfallsmodellen verkar vara svår att tillämpa för större projekt, särskilt när man möter problem som man inte har så stor erfarehet av. Trots det verkar den ändå vara vanlig.
Ett citat:
"Actually, to be very critical, our experience is that a rigid waterfall life cycle is a fundamentally poor process, and generally violates many of the principles of sound engineering practice." (Booch, Object Oriented Design, 1991)