Vattenfallsmodellen

Den traditionella projektledningsmetoden heter vattenfallsmodellen (water fall method) och termen “vattenfall” sägs komma från Winston Royce, år 1970. Han var en av de ledande mjukvaruutvecklarna i den sista halvan av 1900-talet.

Huvudsakligen grundar sig metoden i följande steg (illustrerat som ett vattenfall):

Analys

Basdesign

Teknisk design

Konstruktion

Testning

Integrering

Underhåll.

Det är uppdelat i olika faser, och varje fas ska vara avklarad innan nästa påbörjas. Skulle ett fel uppstå, försöker man lösa detta innan man går vidare.

“Först tar men reda på vad som ska göras, sen planerar man sin lösning, sen implementerar man den.”

Vattenfallsmetoden medför dock en del risker i projektet. Även om basupplägget kan kännas naturligt är det inte nödvändigtvis detta vid problemlösning. Eftersom metoden inte är agil, är den ej heller särskilt flexibel. Ett vattenfallsprojekt med specifika uppgifter, blir svårare att ändra under projektets gång. Omvärlden kanske förändras, och andra krav kan eventuellt uppstå. Vattenfallsmodellen förutsätter att kraven/uppgifterna/features inte kommer att ändras under projektets gång, detta kan i sin tur medföra att den externa kunden inte blir nöjd, eller får vad denna eftersträvar. Vid agilt arbete, finns hela tiden ett nära samarbete med kunden/produktägaren, och levererar ett mer ständigt nyhetsflöde till alla inblandade. Vid traditionell ledning är produktägaren/bossen endast närvarande vid leverans, och har inte samma statusuppdatering. Vattenfallsprojektets tidsestimat kan bli felberäknat i och med att att metoden inte nyttjar ständiga avstämningar, eller planerar “velocity” därefter.

Dessutom sker testningen av projektet i de sista faserna, vilket innebär att om en bugg skulle uppstå, skulle det i sin tur medföra en hel del backtracking (och tillbaka till redan avklarade faser, och det tar både tid och pengar). Kortfattat kan metoden kännas bekväm vid första anblick, och noggrann bland de första faserna, men kan i slutändan innebära ett ojämnt arbetsflöde/resultat. I regel slösas det för mycket tid kring dokumentationen om projektet, som istället hade kunnat nyttjas till effektivt arbete.

Fördelar och nackdelar med att jobba efter vattenfallsmodellen:

Man upptäcker problem i början av projektet, som i sin tur sparar tid och pengar.

Ett hierarkiskt tänkande, arbeta klart med den nuvarande fasen helt, innan man går vidare på nästa fas, vilket leder till en mer naturlig arbetsprocess. Arbeta A, B, C, D

Beställaren (den som betalar) har/kan alltid besluta efter hurvida projektet utvecklas bestämma om hur projektet ska gå tillväga, om det ska avslutas eller läggas på is.Om ett projekt ska återupptas i framtiden så ska det finnas dokumentation som ska hjälpa till att se var man avslutade sitt arbete och hur långt man kom och vad som ska göras.

Vattenfallsmodellen är överskådlig och lätt att förstå. Detta i sin tur sparar tid igenom att man slipper förklara strukturens modell för projektgruppen, i alla fall inte lika ingående som andra alternativa modeller (agila).

-Men, det hela bottnar i att man ska ha en 100% överblick från början till slut för att metoden ska fungera. Planering är alltså A-O inom modellen, att hela tiden ligga steget före, för att kunna förutse eventuella problem som kan uppkomma i arbetsprocessen.Även genom ordentlig planering inom den ekonomiska fronten så har man lättare att stämma av efter och inför nästa steg i den hierarkiska strukturen som man följer i denna modell.

Några av dessa fördelar kan se bättre ut på papper, men fungerar inte nödvändigtvis jättebra i verkligheten.

Källor:

http://www.informatik.uni-bremen.de/gdpa/director/pr051.htm
http://en.wikipedia.org/wiki/Winston_W._Royce
http://www.it.uu.se/edu/course/homepage/oopjava/st09/notes/f09-vattenfall.html
http://www.youtube.com/watch?v=gDDO3ob-4ZY