**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
------------------

Koskmudel
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
-----------------

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
----------------

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
------

1. ↑  Katrin Kaljula. Tarkvara testimine nõuete formuleerimise, analüüsi ja disaini etapis. Tartu 2004. Lk 11
2. 1 2 3 4 5 6 7 8 9 10  (vaadatud 27.11.2017)
3. 1 2
4. 1 2 3 4 5  (vaadatud 25.11.2017)
5. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17  (vaadatud 25.11.2017)
6. ↑  Margo Siilber. Tee Nii. Projektijuhtimise konspekt. Tallinn 2014. Lk 42
7. ↑  Waterfall Software Developement Model Oxagile (vaadatud 24.11.2017)
8. ↑  Waterfall (vaadatud 24.11.2017)
9. 1 2  "(vaadatud 27.11.2017)". Originaali arhiivikoopia seisuga 2.03.2018. Vaadatud 27.11.2017.
10. ↑  Understanding the Pros and Cons of the Wterfall Model of Software Developement (vaadatud 27.11.2017)
11. ↑  Waterfall Model (vaadatud 27.11.2017)