Vattenfallsmodellen: Sekventiell utvecklingsprocess för projekt

Innan ett projekt ska påbörjas så kan man läsa på om olika metoder för hur man ska gå tillväga för sitt projekt.

Det finns olika projektmetoder som är lämpliga för olika sorters projekt.

De har alla sina fördelar och nackdelar och beroende på vilket projekt man ska ta sig an så kan man bestämma vilken metod som är mest effektiv.

Vattenfallsmodellen

Vattenfallsmodellen är en av dessa metoder och är också en av de vanligaste och äldsta projektledningsmetoderna.

Metodens ursprung är från bygg- och tillverkningsindustrin och fokuserar på att utföra projektets faser sekventiellt.

Det finns många typer av projekt som kan gynnas utav denna projektmetodiken och beroende på vilken tidigare erfarenhet man har som projektledare och vilket sätt man föredrar att arbeta på så kan detta vara den bästa metoden för ett projekt.

 

Vad är Vattenfallsmodellen?

Vattenfallsmodellen

Vattenfallsmodellen även känd som vattenfallsmetoden – är en sekventiell utvecklingsprocess som flyter som ett vattenfall genom alla faser av ett projekt (till exempel krav, analys, design, utveckling och testning), där varje fas avslutas helt innan nästa fasen börjar.

Vattenfallsmodellen är en traditionell projektledningsmetod som är baserad på enkelriktad utvecklingsprocess. Det innebär att man har en plan för hur ett projekt ska gå till och man följer planen i en riktning endast. När man avslutat en fas eller en uppgift så går man inte tillbaka till den i efterhand utan man fortsätter vidare enligt plan. Om man identifierar problem eller motstånd så försöker man lösa det i just den fasen och istället för att gå tillbaka till en tidigare fas.

Modellen har sitt ursprung från tillverkningsindustrin där utvecklingsprocessen oftast var lång och krävde många olika komponenter, därför var det mer fördelaktigt att arbeta i projektfaser och efter att man avslutat en fas och påbörjat en ny så gick man inte tillbaka till en tidigare fas. Även om det hade sina fördelar så fanns det också en del problem med metoden eftersom att testning kunde komma sent i projektet och om man då upptäckte problem med sin produkt så var det försent att gå tillbaka och göra ändringar.

I vattenfallsmodellen så arbetar man utifrån specifika faser vilka kan variera beroende vilken typ av projekt man har. Vanligtvis är faserna: kravspecifikation, analys, design, implementation och testning.

 

Kravspecifikation

Kravspecifikation

I den första fasen som kallas kravspecifikation ska all information om projektet samlas in. Då går man igenom projektets mål, objektiv, krav och begränsningar. All information som anses relevant för projektet ska samlas och sammanställas i ett dokument som blir projektets kravspecifikation.

 

Analys

Analys

I den andra fasen analyseras projektets potential baserat på det tidigare dokumentet man har skapat för kravspecifikationen. Man analyserar alla specifikationer och hur projektet kan fortsätta så att man snabbt kan identifiera projektets möjligheter och avgöra om projektet är genomförbart. Utifrån analysen skapas modeller, scheman, och policys. Man börjar undersöka hur man ska gå tillväga för att få fram det resultat som önskas av kunden och man analyserar därför också kraven så att man är säker på att man vet vad resultatet ska bli.

 

Design

Design

I den tredje fasen skapas en design för projektet med hjälp av analysen man gjort i analysfasen. Designen kommer vara basen för arkitekturen av projektet så att man vet hur man ska fortsätta för att nå målet med projektet. Beroende på vilket typ av projekt man arbetar med så kan designen komma att bli annorlunda. Om man arbetar på att skapa en fysisk produkt så är det under designfasen som tekniska modeller, specifikationer, och instruktioner skapas så att man inför nästa fas vet hur man ska börja skapa och bygga sin produkt.

 

Implementation

Implementation

I den fjärde fasen skapas och implementeras det man planerat i designfasen, alltså designen av det som planerats byggas. Om man arbetar mot ett mål som är fysiskt, som exempelvis en produkt, så är det nu man kommer se produkten skapas.

 

Testning

Testning

I den femte fasen så har man en period av testning. Man har då implementerat allt som planerats för och nu är det dags att testa funktionerna och se om det uppstår några problem. Man kollar om man har uppnått resultatet enligt kravspecifikationen och om man har lyckats så kan man leverera till kunden och avsluta projektet.

 

Hur använder man Vattenfallsmodellen?

När man vill använda sig utav vattenfallsmodellen så börjar man med att analysera vad för typ av projekt man har. Beroende på vilket typ av projekt man ska arbeta med så vet man bättre vilka faser man kan använda sig utav för projektet. Om resultatet förväntas vara fysiskt så kan man använda sig utav faserna: kravspecifikation, analys, design, implementation, och testning. Om man arbetar med mjukvara, systemutveckling, eller annat digitalt, så kan man använda sig utav faserna: kravspecifikation, analys, systemdesign, första implementationen, testning, andra implementationen, och underhåll.

Efter att man samlat grundläggande information för projektet så påbörjas den första fasen, kravspecifikation. Under denna fasen behövs all nödvändig information för projektet samlas in och sammanställas i kravspecifikationen. Man frågar kunden vad det är de förväntar sig, vilka resurser man beräknas ha, och när projektet ska vara färdigt. Kravspecifikationen är det dokumentet man följer under hela projektets gång, som en instruktionsbok. Om projektet handlar om att utveckla en ny produkt, exempelvis en kamera, så kan några krav se ut såhär:

  • Kameran ska kunna kopplas till WiFi för att direkt kunna dela bilder, exempelvis till en mobiltelefon
  • Kameran ska vara portabel och lätt så att den är resevänlig
  • Kameran ska kunna ta foton i hög kvalité i mörkret

 

Under den andra fasen börjar man analysera hur man ska gå tillväga för att få fram det resultat projektet har. Man skapar modeller och scheman för att få en tydlig bild av vad som skapas. Varje krav som man identifierat i kravspecifikationen ska analyseras och relevanta modeller skapas utifrån dessa. Man går igenom kraven och ställer frågor tillbaka. Om vi utgår ifrån de tidigare kraven så kan frågor man ställer vara:

  • Kan det uppstå problem när man för över högupplösta foton via WiFi kan det bli en långsam överföring?
  • Kan kameran tappas i marken eller tål den slitage om den samtidigt ska vara portabel och lätt?
  • Vilka tekniker kan man använda för att få bra kvalité på foton i mörkret? Har vi någon erfarenhet av liknande kameror med denna funktionen?

 

I nästa fas så går man igenom design vilket innebär att man börjar ta fram tekniska specifikationer på hur man ska få fram sin produkt eller resultat. Baserat på de krav och frågor man tidigare gått igenom så har man nu en idé om hur man ska gå tillväga för att skapa sin produkt. Man har specifikationer på vilka komponenter som behövs, hur lång tid det beräknas ta att sätta ihop produkten, och vilket material som ska användas. Om den tekniska specifikationen godkänns så kan man fortsätta till nästa fas, implementationsfasen.

Under implementationsfasen så börjar man nu skapa det som man planerat i tidigare projektfaser. Man implementerar eller producerar utifrån de specifikationer som skapats. Implementeringen brukar vara den kortaste fasen under projektets gång eftersom att alla analyser, dokument, och specifikationer redan är klara. Det är nu bara dags att sätta ihop produkten enligt planerna.

Sista fasen är testning och nu har man något man kan börja använda och se hur det fungerar. Man testar om det finns problem med funktionerna av produkten, kvalitén, och om resultatet är som kunden förväntat sig. Om man har producerat en kamera som nämndes i tidigare exempel så kan man ha en testgrupp som testar alla funktionerna av kameran och ger sin bedömning. Man samlar in feedback och respons på produkten och lägger till det i dokumentation för projektet.

När man ser att man har uppnått resultatet och levererat till kunden så kan projektet avslutas. Under hela projektets gång har man gjort noggrann dokumentation av det som analyserats och genomförts som i efterhand kan utvärderas. Om några problem uppstod på vägen så bör man försöka analysera varför de uppstod så att man kan förebygga att liknande situationer uppstår i framtiden. Om man kan identifiera saker som gick effektivt så kan man notera vad som gick effektivt till och hur man kan använda liknande lösningar och metoder i framtiden.

 

Varför ska man använda Vattenfallsmodellen?

Innan man sätter igång med ett projekt där man vill applicera vattenfallsmodellen så bör man först se om vattenfallsmodellen är den lämpligaste metodiken för just det projektet. Det finns både fördelar och nackdelar med att använda vattenfallsmodellen och därför kan man innan ett projekt startar gå igenom för- och nackdelarna med denna och även andra metoder för projektledning. Om projektledaren har erfarenhet av att använda vattenfallsmodellen så vet projektledaren också på vilket sätt vattenfallsmodellen används bäst för olika typer av projekt. Om man är osäker på vilken metod man ska använda för sitt projekt så kan man diskutera med mer erfarna projektledare eller läsa metodböcker för projektledning.

 

Fördelar med Vattenfallsmodellen

Fördelen med att använda sig utav vattenfallsmodellen är att man i den första fasen, kravspecifikation, snabbt kan upptäcka problem med projektet. Detta är för att man i den initiala fasen samlar in all information som är relevant för projektet så som krav, begränsningar, och vilka resurser man har för projektet. Om man har samlat all information på ett effektivt sätt så bör man ha det tydligt för sig om projektet kan påbörjas eller inte. Om man direkt märker att exempelvis resurserna inte kommer räcka till eller att man inte förstår exakt vad resultatet förväntas bli så ska inte projektet sättas igång utan då får man börja om och se om man kan få mer information till kravspecifikationen så att projektet kan starta. Det är bättre att gå igenom det en extra gång i början med risk för lite försening istället för att starta ett projekt med brister i kravspecifikationen. Om man exempelvis inte gått igenom kraven från kunden tydligt eller missat någon viktig information så kan resultatet komma att bli helt annorlunda än vad kunden tänkt sig. Om man inte är säker på vad målet för projektet ska vara så kan man använda sig utav stöd från andra projektmetoder som SMARTa mål.

En annan fördel med att använda sig utav vattenfallsmodellen är just metodiken med att enbart arbeta i en riktning och avsluta varje fas innan man påbörjar nästa. Det blir tydligt för alla i projektet var i processen man är och i varje fas blir det ett tydligt fokus på vad man ska göra. Om man stöter på problem eller motstånd i en fas så löser man det innan man går vidare till nästa fas. Eftersom att man arbetar metodiskt steg för steg så blir det också tydligt för kunden i vilket skede projektet är och när kunden kan förvänta sig ett resultat. Under hela processens gång följer man kravspecifikationen och utför dokumentation så att alla i projektgruppen är uppdaterade om vad som sker.

 

Nackdelar med Vattenfallsmodellen

Problemet som kan uppstå när man arbetar utifrån vattenfallsmodellen är att problem som man inte räknat med kan uppstå i en senare fas och det blir då mycket svårare att göra någon förändring eftersom tidigare faser redan är låsta och avslutade. Om det exempelvis sker problem vid testning och man inser att resultatet inte är som man förväntade sig så går det inte att gå tillbaka och börja om med analys och design, utan man får arbeta med det man har i sin nuvarande fas. Vattenfallsmodellen är inte väldigt flexibel och även om man från början skapat en tydlig kravspecifikation så kan något annat förändras i omgivningen eller för kraven på projektet som man inte kan påverka. Nyckeln till ett lyckat projekt baserat på vattenfallsmodellen är att allt från start är tydligt definierat och all information som är nödvändig för projektet finns tillgänglig via dokumentation och i kravspecifikationen. Om kraven definierats på ett tydligt sätt så kan projektet påbörjas och följas ut till fullo.

 

Vattenfallsmodellen vs Agila metoder

Vattenfallsmodellen vs. Agila metoder

I många fall jämför man vattenfallsmodellen med agila metoder. Den agila metoden uppstod som ett svar på vattenfallsmodellens brister. Med den agila metoden så arbetar man flexibelt och anpassar sig efter projektets utveckling. Istället för att försöka förutse vad som kommer hända och spendera mycket tid på planer, analyser, och dokumentation, så är man istället reaktiv och anpassar sig utifrån projektet. När ett problem uppstår så löser man det på bästa sätt just då, istället för att innan planera och försöka förutse vilka problem som skulle kunna uppstå.

Vattenfallsmodellen är baserad på bygg- och tillverkningsindustrin vilket oftast innebär att resultatet man förväntar sig från ett projekt är fysiskt, som en produkt. Det är därför testningsfasen är i slutet när man har den fysiska produkten och kan börja testa den. Den agila metoden har baserats på projekt där utveckling av mjukvara och andra program som kan testas direkt sker. När man exempelvis utvecklar ett digitalt system så kommer projektgruppen att arbeta på att designa och programmera vilket direkt kan testas. Man behöver alltså inte vänta med att testa koderna i en senare fas. Fokus för den agila metoden är att man har möjligheten att hela tiden testa så att man snabbt kan åtgärda problem som upptäcks innan det är för sent. I den agila metoden arbetar man därför i iterationer, istället för faser, vilket innebär att man kan återkommer till samma uppgift i flera iterationer tills allt fungerar som det ska.

 

Dokumentation

När man använder sig utav vattenfallsmodellen så får man räkna med att mycket dokumentation ska göras. Detta kan vara båda en fördel och nackdel. Att göra mycket dokumentation både innan och under projektets gång gör att mycket blir tydligt och alla inom projektgruppen vet vad som ska ske härnäst. Man har planerat för möjliga hot och problem så att man är förberedd och man vet också var i projektets faser man befinner sig och därför kan man också snabbt identifiera förseningar. Nackdelen med att det finns och görs så mycket dokumentation i projektet är att mycket tid går åt att analysera och dokumentera. Redan i första fasen för projektet, innan projektet officiellt påbörjats, så skapas kravspecifikationen som är det dokument som innehåller planer, scheman, och all nödvändig information för hela projektets gång. Man har redan analyserat projektet från start till slut. Samtidigt kan dokumentationen vara väldigt användbar när projektet har avslutats då man kan analysera hur det gick och varför. Det blir också hjälpsamt för framtida projekt.

Vattenfallsmodellen är baserad på att all information i kravspecifikationen är tydligt definierad. Om det från början är tydligt vad som ska göras och hur man förväntar sig att resultatet ska bli så kan man uppnå ett lyckat projektresultat. Under varje fas kan man följa kravspecifikationen för att se till att det som var planerat för fasen har uppnåtts. Om något saknas så märker man det snabbt och kan göra en påverkan. Om man dock gått vidare till nästa fas så kan man inte längre gå tillbaka och försöka åtgärda problemet utan man får istället fokusera på nuvarande fas.

De projektledare som har mer erfarenhet av att arbeta med vattenfallsmodellen kan lära sig att reagera snabbare på problem i faserna så att man inte gör misstaget med att gå vidare till nästa fas utan att ha löst problemet. Erfarna projektledare är också noggranna med kravspecifikationen och dokumentationen så att det finns mindre risk för att problem uppstår. De projektledare som har mindre erfarenhet av vattenfallsmodellen kan läsa mer om metoden och diskutera med mer erfarna projektledare. Fördelen med vattenfallsmodellen som tidigare nämnts är att det finns mycket dokumentation som också kan användas i efterhand. Projektledare som är osäkra på om vattenfallsmodellen är rätt metod för deras projekt kan använda gammal dokumentation för liknande projekt för att lära sig mer om metoden.

Caroline Hasl

Caroline Hasl

Caroline Hasel är skribent inom projektledning, kommunikation och ledarskap. Caroline har en examen inom företagsekonomi Högskolan i Borås samt en master's degree från Luleå Tekniska Universitet.