V-mudel on arendusmudel, mis seob iga arendusfaasi vastava testimisfaasiga, rõhutades varajast testimise
planeerimist, vigade ennetamist ja selgeid nõudeid. See sobib projektidele, millel on täpselt määratud
ulatus ning mis prioritiseerib esikohale kvaliteedi ja dokumentatsiooni.
V-mudel koosneb kontrollimis ning valideerimis faasidest.
Kontrollimis etappides viitab tootearendusprotsessi hindamise praktikale, kus tagatakse meeskonna vastavus
kehtestatud nõuetele. Kontrollimis faasil on viis etappe:
1. Ärinõuete analüüsis, meeskond püüab aru saada, mis klient nõuab toodelt.
1.1 Süsteemi disainis, süsteemiinsenerid analüüsivad ning mõistavad kavandatava süsteemi äritegevust, uurides kasutajanõuete
dokumenti. Nad selgitavad välja võimalused ja tehnikad, mille abil saab kasutajanõudeid rakendada. Kui mõni nõuetest pole
teostatav, teavitatakse kasutajat probleemist. Leitakse lahendus ja vastavalt sellele redigeeritakse kasutajanõuete dokumenti.
1.3 Tarkvara arhitektuuri disainis, valitakse tarkvara struktuur tuginedes tuvastatud moodulitele, nende funktsionidele,
liideste suhted, sõltuvused ning asjakohased tehnilised elemendid, näiteks andmebaasi skeem ja diagrammid. Arhitektuuri
kujundamise etapis kirjeldatakse ka esialgseid integratsioonitestimise strateegiad, mis juhendavad, kuidas mooduleid
hiljem koos testitakse.
1.4 Moodul disainis, arendusmeeskond jotab süsteemi väikesteks mooduliteks ning täpsustab detailset disaini iga mooduli
kohta, seda kutsutakse madala taseme disainiks.
1.5 Koodimises, arendusmeeskond valib sobilikku programmeerimis keele tuginedes disanile ning toode vajadustele. On olemas
juhised ning standardid koodimisel. Kood läbib mitut ülevaatamist, et kontrollida loogikat, jõudlust, turvalisust ning
vastavus kodeerimisstandarditele.
Valideerimis etappides võetakse kasutusele dünaamilist analüüsimist ning testimist, et tagada tarkvara toode kohtuks kliendi
vajadustele ning ootustele. Selles faasis on neli etappe:
2. Üksuse testimisel, meeskond arendab ning täidab üksuse test plaane, et tuvastada vigasid koodis. See testimine toimub
väikseimates üksustes, nagu programm moodulites, et tagada nad tunktsioneerivad õigesti kui on eraldatud ülejäänud koodist.
2.1 Integratsiooni testimisel, täidakse integratsiooni test plaane, mis on arendatud arhitektuuri disaini etappi ajal
kontrollimis faasis, et kontrollida kas iseseisvalt loodud ning testitud rühmad saavad koos eksisteerida ning omavahel
suhelda.
2.2 Süsteemi testimisel täidakse süsteemi test plaane arendatud süsteemi disain etappilt. Süsteemi test plaane arendavad
kvaliteedi tagamise meeskonnad kasutades äri vajadused, mida tuvastasid sidurühmad. Süsteemi testimine tagab, et
ootused rakenduselt on kohtud.
2.3 Vastuvõtu testimises testitakse tarkvara toodet kasutaja keskkonnas, et tuvastada ühilduvuse vigasid erinevate
süsteemidega kasutaja keskkonnas. Vastuvõtu testimine tuvastab probleeme nagu koormus- ja jõudlusvead reaalses kasutajakeskkonnas.
Jah, V-mudelil on olemas alamvariante, siin on paar näiteks:
W-mudelis, testimised toimuvad kohe algusest peale koos arendus etappidega.
Sawtooth mudelis koostakse prototüüpe ning näidatakse kliendile valideerimiseks.
Sharktooth mudelis samut koostakse prototüüpe, kuid selles mudelis keskendub ka juht,kelel kaudu tulevad uued tegevused.
Joonis:
Arendusmudeli tähstaim omadus on vigade ennetamine ning tuvastamine, kuna mudelis on palju tegevusi, mis tagastavad et ei oleks mingi vigasid toodega.
| Head: | Vead: |
|---|---|
| Lihtne ning arusaadav; | Ei kohane hästi muudetustega; |
| Vigade ennetamine | Kõrge risk ning ebakindlus |
| Täpne edu jälgimine; | Aega nõutav |
| Muudatuste hallatamine; | Ei toeta iteratsioone; |
| Etappe läbitakse ükshaaval; | Ei ole sobilik keeruliste projektide jaoks. |
V mudeli alamvariantid: ijarcs
W mudel: shiftasia
V-mudel: geeksforgeeks
V-mudel süsteemi disain: wikipedia