Koskmudel

Allikas: Vikipeedia

Koskmudel (nimetatakse ka jada-, kaskaad- ja klassikaliseks mudeliks inglise keeles waterfall model) [1][2] on üks enimteatud ja vanimaid tarkvaraarenduse meetodeid [3], mis on oma nimetuse saanud järjestikuse veekoskede analoogiast – vesi langeb ühelt astmelt järgmisesse ning ei pöördu tagasi. [4] Töös liigutakse samuti samm sammult madalamale astmele ning kõik etapid peavad olema täielikult lõpetatud enne järgmise etapi alustamist. [5]

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. [6]

Koskmudeli ajalugu[muuda | muuda lähteteksti]

Koskmudel

Koskmudelit kirjeldas esmakordselt Winson W. Royce 1970. aastal. Koskmudel on järjestikune mudel, mida kasutatakse erineva tarkvara loomiseks, kus projekt kulgeb pidevalt allapoole ning ei pöördu tagasi samamoodi nagu koskede puhul. Niisiis tähendab kose mudel, et järgmise sammu juurde peaks liikuma ainult siis, kui eelmine etapp on lõpule viidud, kuigi mõne mudeli puhul võivad mõningad variatsioonid ja muutused olla. [7]

Royce ütles, et programmi arendamiseks on kaks olulist sammu: 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 nii väga 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. [8]

Koskmudelit järgivad süsteemiarendajad teostavad järjestikku järgmised etapid: nõuete analüüs, disainimine, realiseerimine, testimine ja hooldamine.

Koskmudeli etapid[muuda | muuda lähteteksti]

Koskmudeli etapid [9]

Nõuete analüüs ja kirjeldamine: [2][muuda | muuda lähteteksti]

  • Süsteemianalüüs
  • Tarkvaraanalüüs

Süsteemi ja tarkvara kavandamine: [2][muuda | muuda lähteteksti]

  • Andmestruktuurid
  • Tarkvara arhitektuur
  • Liideste omadused
  • Algoritmilised detailid

Realisatsioon ja moodulite testimine: [2][muuda | muuda lähteteksti]

  • Luuakse programmiosad (funktsioonid, klassid)
  • Luuakse moodulid (programmiosad ühendatakse)
  • Kõike testitakse eraldi

Integratsioon ja süsteemi testimine: [2][muuda | muuda lähteteksti]

  • Programmid ja moodulid ühendatakse
  • Testitakse süsteemi loogikat ja osade liidestamist
  • Testitakse vastavust nõuetele (valideerimine)

Kasutamine ja hooldus:[2][muuda | muuda lähteteksti]

  • Tarkvara kasutatakse
  • Tarkvara muudetakse / täiendatakse, sest:
    • Kasutajad avastavad vigu
    • Ümbrus ja töökeskkond muutuvad
    • Klient tahab lisafunktsionaalsuseid

Koskmudeli skeem[muuda | muuda lähteteksti]

Koskmudeli skeem [4]

Põhiidee kohaselt jagatakse tegevused nii, et iga tegevus toimub jadamisi eraldi etapina. Olulise tähelepanekuna tuleb märkida, et erinevatel autoritel on erinev etappide nimekiri. [9]

Koskmudelit järgivad süsteemiarendajad teostavad järjestikku hulga samme: [4]

  • 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 sammu sooritamise järel sooritatakse järgmine samm. Käesoleva sammu sisendiks on eelneva sammu väljund, käesoleva sammu väljund on järgneva sammu sisendiks (nt arhitektuur baseerub nõuetel ning programm luuakse arhitektuuri alusel). Eelnevate sammude 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 sammu juurde, läbida uuesti programmeerimise samm ning minna teisele testimise ringile. [4]

Eelnevalt kirjeldatud samme 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. [4]

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. [10]

Koskmudeli eelised ja puudused[muuda | muuda lähteteksti]

Eelised[muuda | muuda lähteteksti]

  • Kergesti arusaadav ja kasutatav; [5]
  • Lihtne hallata tänu selle jäikusele – igast faasist on spetsiifiline ülevaade;[5]
  • Üks etapp lõpetatakse, enne kui alustatakse teisega;[5]
  • Töötab hästi väikeste projektidega, kus nõudmised on kindlalt paigas.[5]
  • Protsessi ja tulemused dokumentatsioon on korras. [11]

Puudused[muuda | muuda lähteteksti]

  • Hiline testimisperiood – muudatusi on raske ellu viia, kui testimise käigus selgub, et midagi on valesti; [5][3]
  • Tarkvara on kasutatav vaid arenduse lõpus, mitte varem; [5]
  • Kõrge riskitase ja teadmatus; [5]
  • Mudel ei sobi keeruliste projektide jaoks; [5]
  • Kehv mudel pikkade ja jätkuvate projektide jaoks; [5]
  • Ei sobi ka projektidele, kus nõuetel on suur risk muutuda; [5]
  • Projekti paindumatu jaotus faasideks; [2]
  • Klient näeb tulemust alles lõpus ja valesti mõistetud nõuded lõppevad katastroofiga. [2]

Millal kasutada koskmudelit?[muuda | muuda lähteteksti]

Koskmudelit saab kasutada kui :

  • Projekt on väike; [5]
  • Nõuded on hästi tuntud, selged ja fikseeritud; [5]
  • Toote määratlus on stabiilne;[5]
  • Tehnoloogia ja tehtavad muudatused on arusaadavad;[5][2]
  • Puuduvad mitmetähenduslikud nõuded;[5]
  • Kvaliteetsed allikad on vabalt kättesaadavad;[5]
  • Tarkvara on suhteliselt väikesemahuline. [2]

Viited[muuda | muuda lähteteksti]

  1. Katrin Kaljula. Tarkvara testimine nõuete formuleerimise, analüüsi ja disaini etapis. Tartu 2004. Lk 11 [1]
  2. 2,0 2,1 2,2 2,3 2,4 2,5 2,6 2,7 2,8 2,9 (vaadatud 27.11.2017) [2]
  3. 3,0 3,1 [3]
  4. 4,0 4,1 4,2 4,3 4,4 (vaadatud 25.11.2017) [4]
  5. 5,00 5,01 5,02 5,03 5,04 5,05 5,06 5,07 5,08 5,09 5,10 5,11 5,12 5,13 5,14 5,15 5,16 (vaadatud 25.11.2017) [5]
  6. Margo Siilber. Tee Nii. Projektijuhtimise konspekt. Tallinn 2014. Lk 42
  7. Waterfall Software Developement Model Oxagile (vaadatud 24.11.2017) [6]
  8. Waterfall (vaadatud 24.11.2017) [7]
  9. 9,0 9,1 (vaadatud 27.11.2017) [8]
  10. Understanding the Pros and Cons of the Wterfall Model of Software Developement (vaadatud 27.11.2017) [9]
  11. Waterfall Model (vaadatud 27.11.2017) [10]