Kosemudel (ehk waterfall) on üks esimesi tarkvaraarenduse elutsükli mudeleid. Ta põhineb tavalise
tootmisprotsessi 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 etapist, mis rahuldab kõik ü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, keskendudes selle
funktsionaalsetele omadustele. Need võivad olla erinevad Andmestruktuurid, toote enda arhitektuur, erinevad
liidesed, nende liideste omadused ja muud algorütmilised detailid. Kavandamise tulemused dokumenteeritakse,
ning mille järgi hiljem teostuses hinnatakse projekti kvaliteeti - Mida rohkem kavandist on tehtud, seda
rohkem on projektist valminud.
Eelnevalt valminud kavandi järgi toimub selles etapis toote arendus. Arendustöö käigus arendatakse
programm moodulhaaval või moodulite kogumikuna. Peale arendustööd testitakse valmissanud mooduleid ja
moodulikogumikke. Olenevalt eelnevalt dokumenteeritud kavandi detailsusest tuleneb nüüd selles 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 seelest vaatepunktist, kas süsteem teb 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 sihtyrühma sisendi tagajärjel või vajadusena) ja koodi
enda refaktoreerimine.
Arendustöö teostamiseks korratakse kõiki eelmiseid etappe kuid siis ainult
süsteemi muutmise tarbeks mitte enam nullist millegi uue arendamise jaoks.
Iga etapi tulemusena tekib dokument või dokumentatsioon (üks või mitu) mis kirjeldab vastavas etapis
saavutatud tulemit. Kõik dokumendid kinnitatakse. Järgmine etapp ei tohi olla samaaegselt töös kui
eelmine pole lõpetatud. Kuigi ülekate mingisugune siiski on, ning info edastatakse ühest etapist järgmisesse
edasi.
| Head küljed: | Halvad küljed: |
|---|---|
| Struktuur on väga selge | Kohandumine muutustega on väga halb |
| Dokumentatsioon on tugev, jätab maha iga sammuga dokumente, mis aitab koordineerida. | Klient näeb süsteemi alles lõpus, millal on juba liiga hilja ümber asju teha |
| Sobib stabiilsete nõuetega projektidele, kus on kirjas mida on täpselt vaja. | Projekt on aeglane, sest tiimid ei saa koos väga paindlikult töötada |
Viited infole: eõpearhiiv