| Kriteerium | Inkrementaalne mudel | Spiraalne mudel |
|---|---|---|
| Põhikontseptsioon | Funktsionaalsuse järk-järguline lisamine baasversioonile | Tsükliline arendus põhjaliku riskianalüüsiga igas iteratsioonis |
| Tüüpiline töövoog | [Tuumaosa] → [Inkrement 1] → [Inkrement 2] → [Valmis toode] | [Plaan → Riskid → Arendus → Hindamine] → Kordus |
| Riskihaldus | Riskid vähenevad astmeliselt (iga inkrement vähendab üldriski) | Formaalne riskianalüüs igas tsüklis (spetsiaalne etapp) |
| Kulutused | Keskmised (optimeeritud struktuur) | Kõrged (vajab riskianalüüsi eksperte) |
| Ressursinõuded | Tavaline arendusmeeskond | Eksperdid riskianalüüsiks + arendusmeeskond |
| Paindlikkus | Keskmine (muudatused on võimalikud inkrementide vahel) | Väga kõrge (iga iteratsioon võimaldab muudatusi) |
| Kliidi kaasatuse tase | Mõõdukas (tagasiside pärast iga inkrementi) | Kõrge (klient osaleb igas iteratsiooni hindamisetapis) |
| Dokumenteerimise tase | Standardne | Väga põhjalik (eriti riskianalüüside kohta) |
| Parimad kasutusviisid | Projektid stabiilsete nõuetega (nt ettevõtete süsteemid, veebirakendused) | Kõrge riskiga projektid (nt kaitse-, meditsiinitarkvara) |
| Tüüpilised probleemid | Inkrementide kooskõla raskused, arhitektuuri planeerimise keerukus | Kõrged kulud, iteratsioonide pikkus, ekspertide vajadus |
| Eelised | Varajane toote väljalase, väiksemad iteratsioonid, parem kliidisuhe | Väga hea riskide tuvastamine, sobib keerukatele projektidele, suur paindlikkus |
| Puudused | Võib vajada ümbertegemist, kui baasarhitektuur on vale | Ressursimahukas, keeruline hallata, aeganõudev |
| Testküsimus (näide) | “Mis iseloomustab inkrementaalset mudelit?” ✓ Funktsionaalsuse järkjärguline lisamine | “Mis on spiraalse mudeli põhielement?” ✓ Riskianalüüs igas tsüklis |