Kosemudel (ehk waterfall) on üks esimesi tarkvaraarenduse elutsükli mudeleid. ta põhineb tavalise toomis-
protsessi eeskujul, kus iga etapp eelneb järgmisele. 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 etapis, mis rahuldab kõiki üldise tarkvaraarenduse elutsükli etappe
Nendeks on nõuete määratlemine, Süsteemi ja tarkvara kavandamine, Teostus ning moodulite testimine, Intergratsioon 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, kesksendudes 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 teostuses hinnatakse
projekti kvaliteeti - Mida rohkem kavandist tehtud, seda rohkem on projektist valminud.
Eelnevalt valminud kavandi järgi toimub selles etapib toote arendus. Arendustöö käigus arendatakse programm moodulihaaval
või moodulite kogumikuna. Peale arendustööd testitakse valmissaadud mooduleid ja moodulikogumikku. Olenevalt eelnevalt
dokumenteeritud kavandi detailsusest tuleneb selles etapis projekti arenduslihtsus. Mida rohkem on detaile kavandatud, seda
lihtsam on arendustöö.
Toimub kogu valmis saanud 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 refaktoreerimine.
Arendustöö teostamiseks korratakse kõiki eelmisi etappe, kuid siis ainult süsteemi muutmise tarbeks, mitte nullist
Millega 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 planeerimata 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 kordineerida