Koskmudell — 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.
Kes ja millal leiutas koskmudell?
Ameerika arvutiteadlane Winston Walker Royce leiutas ja kirjeldas seda juba 1970. aastal ning 1976. aastal andsid sellele nime teadlased Thomas Bell ja Thomas Thayer.
Koskmudeli etapid:
- Analüütika. Pikim etapp. Töövõtja arutab tellijaga toote üle, saab nõuded, määrab ja kiidab heaks plaanid, eesmärgid ja eelarve, tööplaanid, protsessid, riskid. Pärast seda tuleb koostada lähteülesanded ja juhised. Neist ei saa järgmistes etappides kõrvale kalduda.
- Projekteerimine. Selles etapis luuakse tarkvara prototüüp. Samuti tuleb valida programmeerimisplatvorm ja kinnitada meeskonna rollid.
- Arendus. Siin tuleb kirjutada toote kood selgelt vastavalt spetsifikatsioonile.
- Testimine. Selles etapis kontrollitakse koodi vastavust spetsifikatsioonile.
- Kasutamine. Töövõtja annab toote välja ja kooskõlastab selle kliendiga. Pärast seda on vaja analüüsida tulemust, koguda tagasisidet ja täpsustada kriitilisi vigu. Kui neid on palju, tuleb kogu protsess uuesti alustada.
- Toetus. Viimases etapis jääb töövõtjale ülesanne säilitada töövõime, kõrvaldada vead ja koguda kasutajatelt tagasisidet, et laiendada või asendada funktsionaalsust.
plusse+
- mudel on tarbijatele hästi teada;
- see käsitleb keerukust korrapäraselt ja toimib hästi nende projektide puhul, mis on küllaltki hästi mõistetavad, kuid siiski raskesti lahendatavad;
- seda on väga lihtne mõista;
- see on lihtne ja hõlpsasti rakendatav, kuna arendusprotsess toimub etappide kaupa;
- struktuuri saavad järgida isegi tehniliselt kehvad või kogenematud töötajad;
miinused—
- kasutajal puudub võimalus süsteemiga järk-järgult harjuda. Õppeprotsess toimub elutsükli lõpus, kui tarkvara on juba kasutusel;
- kõik nõuded peavad olema teada elutsükli alguses. Mudel ei ole mõeldud nõuete dünaamiliste muutuste jaoks kogu elutsükli jooksul, kuna saadud andmed on «külmutatud».
- on vaja ranget juhtimist ja kontrolli, kuna mudel ei võimalda nõudeid muuta;
- mudel põhineb dokumentatsioonil, mis tähendab, et dokumentide arv võib olla liiga suur;
- kogu tarkvaratoode arendatakse korraga. Süsteemi ei ole võimalik osadeks jagada.
