Koskmudel

Koskmudel (ka jada-, kaskaad- ja klassikaline mudel inglise keeles waterfall model)  on üks enimteatud ja vanimaid tarkvaraarenduse meetodeid , mis on oma nimetuse saanud järjestikuse veekoskede analoogiast – vesi langeb ühelt astmelt järgmisse ega pöördu tagasi. Töös liigutakse samuti samm-sammult madalamale astmele ning kõik etapid peavad olema täielikult lõpetatud enne järgmise etapi alustamist.

Kose mudeli puhul keskendutakse projekti käigus tehtavate tööde kirjeldustele. Pannakse kirja tööd, mis tuleb tulemuse saavutamiseks teha ning määratakse nende järjestus, tähtajad, vajalikud ressursid ja tegijad.

Koskmudeli ajalugu 

Koskmudelit kirjeldas esmakordselt Winston W. Royce 1970. aastal. Koskmudel on järjestikune mudel, mida kasutatakse erineva tarkvara loomiseks, kus projekt kulgeb pidevalt allapoole ega pöördu tagasi samamoodi nagu koskede puhul. Niisiis tähendab kose mudel, et järgmise etapi juurde peaks liikuma alles siis, kui eelmine etapp on lõpule viidud, kuigi mõne mudeli puhul võivad mõningad variatsioonid ja muutused olla.

Royce ütles, et programmi arendamiseks on kaks olulist etappi: analüüs ja kodeerimine, kuid just seetõttu, et haldama peab kogu tarkvaraarendusega seotud intellektuaalset vabadust, peab kasutama ka mitmeid teisi üldkulude etappe, mis suuremahulise projekti jaoks on nõuded süsteemile, tarkvara nõuded, analüüs, programmi kujundus, kodeerimine, testimine, toimingud. Paljusid Royce'i ideid peetakse tänapäeval iganenuks, kuid probleem ei ole mitte niivõrd koskmudeli raskes mõistmises, vaid selles, et tema väärtuslikest ideedest kiputakse liiga kergekäeliselt loobuma. Mõned koskmudeli omadused on vältimatud ja probleemide vältimiseks tuleb olla eriti tähelepanelik.

Koskmudelit järgivad süsteemiarendajad teostavad järjestikku järgmised etapid: nõuete analüüs, disainimine, realiseerimine, testimine ja hooldamine.

Koskmudeli etapid

Nõuete analüüs ja kirjeldamine  
 Süsteemianalüüs
 Tarkvaraanalüüs

Süsteemi ja tarkvara kavandamine 
 Andmestruktuurid 
 Tarkvara arhitektuur 
 Liideste omadused 
 Algoritmilised detailid

Realisatsioon ja moodulite testimine 
 Luuakse programmiosad (funktsioonid, klassid) 
 Luuakse moodulid (programmiosad ühendatakse) 
 Kõike testitakse eraldi

Integratsioon ja süsteemi testimine 
 Programmid ja moodulid ühendatakse 
 Testitakse süsteemi loogikat ja osade liidestamist 
 Testitakse vastavust nõuetele (valideerimine)

Kasutamine ja hooldus 
 Tarkvara kasutatakse 
 Tarkvara muudetakse/täiustatakse, sest: 
Kasutajad avastavad vigu
Ümbrus ja töökeskkond muutuvad 
Klient tahab lisafunktsionaalsuseid

Koskmudeli skeem 

Põhiidee kohaselt jagatakse tegevused nii, et iga tegevus toimub jadamisi eraldi etapina. Olulise tähelepanekuna tuleb märkida, et eri autoritel on erinev etappide nimekiri.

Koskmudelit järgivad süsteemiarendajad läbivad järjest mitmesuguseid etappe:
 Eeluuring – sooritatakse süsteemiarenduse tasuvusuuring;
 Süsteemi nõuete püstitamine – kaardistatakse kasutajate jt huvipoolte vajadused ning nõuded süsteemile;
 Süsteemi nõuete analüüs – süstematiseeritakse nõuded, nõudeid täpsustatakse, lahendatakse vastuolud nõuetes;
 Süsteemi arhitektuuri projekteerimine ehk nõuetele vastava lahenduse disain;
 Kodeerimine ehk programmeerimine;
 Testimine;
 Levitamine ehk kasutuselevõtt;
 Hooldus.

Iga etapi sooritamise järel sooritatakse järgmine. Käesoleva etapi sisendiks on eelneva etapi väljund, käesoleva etapi väljund on järgneva etapi sisendiks (nt arhitektuur baseerub nõuetel ning programm luuakse arhitektuuri alusel). Eelnevate etappide juurde tagasi ei pöörduta. Kui testimise käigus avastatakse viga, mille juured on arhitektuuris, siis koskmudel jääb hätta juhiste andmisega, kuidas pöörduda tagasi arhitektuuri etapi juurde, läbida uuesti programmeerimise etapp ning minna teisele testimisringile.

Eelnevalt kirjeldatud etappe ei pea organisatsioon täielikult ise läbi viima – võimalik on osta sisse teatud tegevuste täitmist või osta sisse valmistarkvara ja seda kohandada. Tüüpiliselt tuleb eeluuring, süsteemi nõuete püstitamise ja testimise tegevused siiski läbi viia organisatsiooni töötajate olulise osalusega tagamaks tarnitava süsteemi sobivuse organisatsiooni tööprotsessidega. Otsuse – kas valmistada süsteem ise, osta sisse arendus või valmistarkvara ja seda kohandada – tegemisel tuleks lähtuda tulu-kulu analüüsimisest, samuti edasiarenduse jätkusuutlikkusest.

Kuigi mudelil on palju kriitikud on koskmudel teatud tüüpi projektide jaoks väga kasulik ning võib oluliselt kokku hoida nii aega kui ka kulusid. Mudeli kasutamine sõltub suuresti sellest, kui hästi mõistetakse oma kliendi vajadusi ja kui muutlikud need vajadused on. Muutlike projektide jaoks on olemas teised mudelid.

Koskmudeli eelised ja puudused

Eelised 
 Kergesti arusaadav ja kasutatav;
 Lihtne hallata tänu selle jäikusele – igast faasist on spetsiifiline ülevaade;
 Üks etapp lõpetatakse, enne kui alustatakse teisega;
 Töötab hästi väikeste projektidega, kus nõudmised on kindlalt paigas.
 Protsessi ja tulemused dokumentatsioon on korras.

Puudused 
 Hiline testimisperiood – muudatusi on raske ellu viia, kui testimise käigus selgub, et midagi on valesti;
 Tarkvara on kasutatav vaid arenduse lõpus, mitte varem; 
 Kõrge riskitase ja teadmatus;
 Mudel ei sobi keeruliste projektide jaoks; 
 Kehv mudel pikkade ja jätkuvate projektide jaoks; 
 Ei sobi ka projektidele, kus nõuetel on suur risk muutuda; 
 Projekti paindumatu jaotus faasideks;
 Klient näeb tulemust alles lõpus ja valesti mõistetud nõuded lõppevad katastroofiga.

Millal kasutada koskmudelit? 
Koskmudelit saab kasutada, kui: 
 Projekt on väike;
 Nõuded on hästi tuntud, selged ja fikseeritud;
 Toote määratlus on stabiilne;
 Tehnoloogia ja tehtavad muudatused on arusaadavad;
 Puuduvad mitmetähenduslikud nõuded;
 Kvaliteetsed allikad on vabalt kättesaadavad;
 Tarkvara on suhteliselt väikesemahuline.

Viited 

Tarkvaraarendus