Koskmudell / Waterfall model

Koskmudell on lähenemine projektijuhtimisele, mille puhul ülesandeid täidetakse järjestikku. Enne uue etapi alustamist peab eelmine etapp olema lõpule viidud. Faaside vahelejätmine või kattumine ei ole lubatud.

Mudeli ajalugu

Tarkvara insener Winston Royce pakkus 1970. aastal välja veepaiskumismudeli. Oma artiklis „Managing the Development of Large Software Systems“ kirjeldas ta arendusmeetodit, mida hiljem nimetati veejooksu mudeliks. Royce pakkus välja järjestikuse mudeli, milles iga arendusfaas (nõuded, projekteerimine, rakendamine, testimine, kasutuselevõtt ja tugi) järgneb rangelt eelmisele. Kuigi ta ei nimetanud oma mudelit „veejooksuks“ (see nimetus tuli hiljem), sarnaneb selle tegevuste järjestus veejooksuga, kus iga etapp lõpetab eelmise ja viib järgmisse.

Millised on Koskmudelli etapid?

Walker Royce mõtles 50 aastat tagasi välja koskmudelid ja need ei ole sellest ajast saadik muutunud. Pealegi järgivad projekti loomise etapid alati sama järjekorda ja ühtegi neist on võimatu vahele jätta.

• Analüüsid. Kõige pikem etapp. Töövõtja arutab tellijaga toote üle, saab nõuded, määrab ja kiidab heaks plaanid, eesmärgid ja eelarve, tööplaanid, protsessid, riskid. Pärast seda tuleb koostada lähteülesanded ja juhised. Neist ei saa järgmistes etappides kõrvale kalduda.
• Projekteerimine. Selles etapis luuakse tarkvara prototüüp. Samuti tuleb valida programmeerimisplatvorm ja kinnitada meeskonna rollid.
• Arendus. Siin tuleb kirjutada toote kood selgelt vastavalt spetsifikatsioonile.
• Testimine. Selles etapis kontrollitakse koodi vastavust spetsifikatsioonile.
• Kasutamine. Töövõtja annab toote välja ja kooskõlastab selle kliendiga. Pärast seda on vaja analüüsida tulemust, koguda tagasisidet ja täpsustada kriitilisi vigu. Kui neid on palju, tuleb kogu protsess uuesti alustada.
• Toetus. Viimases etapis peab töövõtja säilitama töövõime, kõrvaldama vead ja koguma kasutajatelt tagasisidet, et laiendada või asendada funktsionaalsust.

Plussid ja miinused

Plussid:

1. Selge ja struktureeritud – üksikasjalikud juhised ja reeglid protsessi igas etapis. Kõik algab nõuete analüüsiga ja projektiplaanid on eelnevalt fikseeritud, mis aitab vältida ebakindlust ja hõlbustab projekti kontrollimist.
2. Kindlus ajalises ja eelarvelises plaanis – projekti maksumus ja tarnekuupäevad määratakse kindlaks arenduse alguses ja need jäävad kogu projekti jooksul samaks. See muudab projekti kliendi ja töövõtja jaoks prognoositavamaks.
3. Lihtsus uute töötajate koolitamisel – meeskonna vahetamisel või uue arendaja või testija lisamisel on protsess tänu selgelt kirjeldatud reeglitele ja dokumentatsioonile selge, mis kiirendab töösse sisseelamist.
4. Järelevalve lihtsus – igal tööetapil on fikseeritud piirid ja edasiminekut on lihtne jälgida. See võimaldab töövõtjal projekti tõhusalt juhtida.
5. Sobib väikestele ja stabiilsetele projektidele – veepaisumismudel sobib ideaalselt hästi määratletud nõuetega projektidele, kus arendusprotsessi käigus ei ole oodata muudatusi.

Miinused:

1. Paindlikkuse puudumine – mudel ei võimalda paindlikult reageerida muudatustele arengu käigus. Kui tekivad uued nõuded või probleemid, on raske nendega tegeleda ilma eelmiste sammude juurde tagasi pöördumata, mis võib kaasa tuua lisakulusid.
2. Kliendi vähene kaasamine arendusprotsessi – klient on kaasatud ainult nõuete kogumise ja lõpliku testimise etapis. Ta ei saa arendusprotsessi ajal teha muudatusi või märkusi, mis võib viia ootuste ja lõpptoote vahelisele ebakõlale.
3. Probleemide hiline avastamine – testimine algab alles pärast arenduse lõppu, mis tähendab, et kõik probleemid ja vead avastatakse hilja. Nende parandamine lõpus võib olla kulukas ja aeganõudev.
4. Raskused seoses projekti muudatustega – kui arendusprotsessi käigus ilmnevad muudatused nõuetes või tingimustes, on neid raske kohandada ilma eelmiste etappide juurde tagasi pöördumata, mis võib ajakava ja eelarvet oluliselt pikendada.
5. Ebatõhusus suurte või dünaamiliste projektide puhul – surge-mudel ei sobi ebakindlate või sageli muutuvate nõuetega projektide puhul, nagu näiteks keerulised süsteemid või uuenduslikud arendused.