Koskmudell ja Inkrementaalne mudell

1. Koskmuudeli ajalugu, autorid ja arendamine:

Ajalugu:

• Kes: Koskmuudeli arendas välja Winston W. Royce 1970. aastatel. Ta tutvustas seda oma teadusartiklis “Managing the Development of Large Software Systems” 1970
• Millal: Mudel sai laialdaselt tuntuks pärast 1970. aasta teadusartiklit
• Arendamine: Koskmuudel on traditsiooniline arenduse protsess, kus iga etapp viiakse lõpule enne järgmise etapi algust

Etapid:

1. Nõuded (Requirements) — Kogutakse kõik süsteemi nõuded
2. Kavandamine (Design) — Süsteemi arhitektuuri ja disaini planeerimine
3. Rakendamine (Implementation) — Arendatakse tarkvara vastavalt eelnevalt tehtud kavanditele
4. Testimine (Testing) — Kontrollitakse, kas tarkvara töötab vastavalt nõuetele
5. Hooldus (Maintenance) — Vead parandatakse ja süsteemi uuendatakse

Koskmuudeli plussid:

1. Lihtne ja arusaadav struktuur
2. Kõik nõuded on alguses täpselt määratud
3. Sobib projektidele, kus nõuded ei muutu
4. Hea suurematele ja keerukamatele projektidele
5. Kõik etapid on selgelt määratletud

Koskmuudeli miinused:

1. Vähenenud paindlikkus – nõuded ei saa hiljem muutuda
2. Pikk arendusaeg, kuna iga etapp on lõpetatud enne järgmise alustamist
3. Vähenenud kasutajate tagasiside võimalus enne lõppversiooni
4. Keeruline kohandada, kui algusnõuded olid ebatäpsed
5. Probleemide leidmine hilises arenguetapis võib olla kallis

Skeem:

2. Inkrementaalne mudel ajalugu, autorid ja arendamine:

Ajalugu:

• Kes: Inkrementaalset mudelit hakati arendama 1980ndatel, põhinedes varasematele iteratiivsetele arengumudelitele
• Millal: Inkrementaalne mudel sai tuntuks 1980ndate lõpus ja 1990ndate alguses
• Arendamine: Mudel keskendub tarkvara järkjärgulisele arendamisele, kus iga uus osa lisatakse ja testitakse pärast eelnevat etappi

Etapid:

1. Nõuded — Algseid nõudeid kogutakse, kuid kõik ei pea olema täpselt määratud
2. Esmane disain ja planeerimine — Arhitektuur ja esimesed versioonid luuakse
3. Tarkvara arendamine — Esimesed funktsioonid arendatakse ja testitakse
4. Testimine ja tagasiside — Testimine ja kasutajate tagasiside kogumine igas etapis
5. Täiendamine ja täiustamine — Igasse järgnevasse iteratsiooni lisatakse täiendavad funktsioonid ja parandused

Inkrementaalse mudeli plussid:

1. Kõrge paindlikkus ja kohandatavus.
2. Erinevaid funktsioone saab lisada järk-järgult.
3. Kasutajate tagasiside on võimalik igas etapis.
4. Kiire prototüüpimine.
5. Madalam risk, kuna vigu saab kiiresti tuvastada.

Inkrementaalse mudeli miinused:

1. Kogu süsteemi lõppversioon võib olla keeruline arendada, kuna erinevad osad võivad erineda.
2. Pidev vajadus testimiseks ja kohandamiseks.
3. Määramatud algnõuded võivad muuta arenduse keerukaks.
4. Hoolduse ja täienduste tegemine võib olla keeruline.
5. Algse kavandi järgimine võib olla keeruline.

Skeem:

Mudelite võrdlustabel

	Koskmuudel (Waterfall)	Inkrementaalne mudel (Incremental)
Ilmumis aasta	1970ndad	1980ndad
Etappide arv	5 (Nõuded, Kavandamine, Arendamine, Testimine, Hooldus)	5 (Nõuded, Kavandamine, Arendamine, Testimine, Funktsioonide lisamine)
Mudeli põhisisu	Järkjärguline, lineaarne protsess, kus iga etapp lõpetatakse enne järgmisse liikumist.	Arendus jaguneb väikesteks iteratsioonideks, kus iga uus osa sisaldab kavandamist, arendamist ja testimist.
Raskused kasutamisel	Kõrged — hilisemad muudatused on keerulised ja kallid.	Keskmised — muudatusi saab teha igas etapis, kuid iga iteratsioon vajab hoolikat testimist.
Kulud	Kõrged — suurte algusfaasi kulud, kuna kogu protsess on lineaarne ja pikk.	Keskmised — odavam alguses, kuna arendamine toimub samm-sammult.
Riskide kontroll	Madal — riske on raske kontrollida enne, kui projekt on valmis.	Kõrge — iga iteratsiooni jooksul on võimalik riske paremini hallata.
Muudatuste arvestamine	Keeruline — muudatused on kallid ja raske sisse viia hilisemates etappides.	Paindlik — muudatusi saab sisse viia igas etapis.
Kasutamine	Sobib projektidele, kus nõuded on täpselt määratud ja ei muutu.	Sobib projektidele, kus nõuded võivad arengu käigus muutuda.
Plussid	1. Selge struktuur. 2. Lihtne juhtida ja kontrollida. 3. Sobib selgelt määratletud nõudega projektidele. 4. Kergem hinnata aega ja eelarvet. 5. Sobib suurematele projektidele.	1. Paindlik nõuete muutmiseks. 2. Väiksem risk, kuna igal etapil on testimine. 3. Kiire vigu tuvastada ja parandada. 4. Väiksemad algkulud. 5. Sobib projektidele, kus nõuded võivad muutuda.
Miinused	1. Vähenenud paindlikkus. 2. Muudatused on keerulised ja kallid. 3. Pikk arendusperiood. 4. Vead on kallid hilises etapis. 5. Vähe tagasisidet lõppkasutajatelt enne lõpptooteni jõudmist.	1. Erinevate süsteemi osade integreerimine võib olla keeruline. 2. Muutuvate nõudmiste juhtimine võib olla keeruline. 3. Kõikide iteratsioonide testimine on vajalik. 4. Pikem arendusperiood kui algselt planeeritud. 5. Vähem prognoositav lõpptähtaeg.