Kosemudel (ehk waterfall) on üks esimesi tarkvaraarenduse elutsükli mudeleid. Ta põhineb tavalise tootmis-
protsessi eeskujul, kus iga etapp eelneb järgimisele. Tagasipöördumine eelmisesse etappi on keeruline ning kui
eelnevas etapis avastatakse viga, tähendab see seda, et vea juurde saab tagasi tulla alles siis kui tarkvara
on kasutusse läinud
Kosemudel koosneb viiest etapist, mis rahuldab kõiki üldise tarkvaraarenduse elutsükli etappe
Nendeks on: Nõuete määratlemine, Süsteemi ja tarkvara kavandamine, Teostus ning moodulite testimine, Integratsioon ja
süsteemi testimine ning Kasutamine ja hooldus.
Siin etapis dokumenteeritakse arendatava toote või süsteemi nõuded, käitumine, sihtriistvara jms. Vahest jaotatakse
see etapp kaheks - Süsteemi analüüs ja nõuete analüüs.
Teises etapis kavandatakse arendusele mineva tarkvaratoote süsteem ja struktuur, keskenduses selle funktsionaalsetele
omadustele. Need võivad olla erinevad andmestruktuurid, toote enda arhitektuur, erinevad liidesed, nende liideste omadused
ja muud algoritmilised detailid. Kavandamise tulemused dokumenteeritakse, ning mille järgi hiljem teosustes hinnatakse projekti
kvaliteeti - Mida rohkem on kavandist tehtud, seda rohkem on projektist valminud.
Eelnevalt valinud kavandi järgi toimib selles etapis tootearendus. Arendustöö käigus arendatakse programm moodulhaaval
või moodulite kogumikuna. Peale arendustööd testitakse valmis saadud mooduleid ja moodulikogumikke. Olenevalt eelnevalt dokumenteeritud
kavandi detailsusest tuleneb nüüd sleles etapis projekti arenduslihtsus. Mida rohkem on detaile kavandatud, seda lihtsam on arendustöö.
Toimub kogu valmissaadud tarkvarasüsteemi testimine. Peale testimist tarnitakse toode kliendile ja/või sihtrühmale.
Testitakse sellest vaatepunktist, kas süsteem teeb seda mis eelnevalt dokumenteeritud ning testitakse ka, et süsteemis olevad
erinevad detailid on loogilised.
Tegu on kõige pikema tarkvara elutsüklis oleva etapiga. Siin toimub vigade parandus, funktsionaalsuse muutmine (kas siis kliendi,
turu, keskkonna või sihtrühma sisendi tagajärjel või vajadusel) ja koodi enda refraktoreerimine.
Arendustöö teostamiseks korratakse kõiki eelmisi etappe, kuid siis ainult süsteem muutmise tarbeks, mitte enam nullist.
Millegi uue arendamise jaoks.
| Head küljed | Halvad küljed |
|---|---|
| Nõuded on projekti alguses selgelt paigas | Nõudeid ei saa muuta projekti käigus |
| Valminud toode on 1:1 nõuetele vastav | Arendusmudel ei ole paindlik muudatuste tegemiseks |
| Kulude hindamine on lihtsam, kuna plaanipäraseid ootamatusi tekib vähem, sest nõuded on paigas | Nõuete paikapanek on keerulisem, kuna arendustööd ei alustata enne, kui kõik nõuded on detailselt paigas, absoluutselt kogu projekti kohta. |
Kosemudel sobib kõige paremini suurtele süsteemidele kui seda arendatakse
mitmes kohas korraga. Korralik eelnev planeerimine aitab eri paikades asuvaid
meeskondi paremini koordineerida.