V-modelis tiek saukts arī par verifikācijas un validācijas modeli. Šajā gadījumā katra SDLC fāze ir jāpabeidz pirms nākamās fāzes sākuma. Tas seko secīgam projektēšanas procesam, tāpat kā ūdenskrituma modelim. Ierīces testēšana plānota paralēli atbilstošam izstrādes posmam.
Pārbaude: Tas ietver statiskās analīzes metodi (pārskatīšanu), kas tiek veikta bez koda izpildes. Tas ir produkta izstrādes procesa novērtēšanas process, lai noskaidrotu, vai noteiktās prasības atbilst.
Validācija: Tas ietver dinamiskās analīzes metodi (funkcionālā, nefunkcionālā), testēšana tiek veikta, izpildot kodu. Validācija ir programmatūras klasificēšanas process pēc izstrādes procesa pabeigšanas, lai noteiktu, vai programmatūra atbilst klienta vēlmēm un prasībām.
Tātad V-modelis satur verifikācijas fāzes vienā pusē, bet apstiprinājuma fāzes otrā pusē. Verifikācijas un validācijas process tiek apvienots ar kodēšanas fāzi V formā. Tādējādi tas ir pazīstams kā V-modelis.
Ir dažādas V modeļa verifikācijas fāzes fāzes:
| Uzņēmējdarbības prasību analīze: | Šis ir pirmais solis, kurā produkta prasības tiek saprastas no klienta puses. Šajā fāzē ir ietverta detalizēta komunikācija, lai izprastu klienta vēlmes un precīzas prasības.
| Sistēmas dizains: | Šajā posmā sistēmu inženieri analizē un interpretē piedāvātās sistēmas darbību, izpētot lietotāja prasību dokumentu.
| Arhitektūras dizains: | Arhitektūras izvēles pamatā ir tas, ka tai ir jāsaprot viss, kas parasti sastāv no moduļu saraksta, katra moduļa īsas funkcionalitātes, to interfeisa attiecībām, atkarībām, datu bāzes tabulām, arhitektūras diagrammām, tehnoloģiju detaļām utt. Tiek izmantots integrācijas testēšanas modelis. ārā noteiktā fāzē.
| Moduļa dizains: | Moduļu projektēšanas fāzē sistēma sadalās mazos moduļos. Ir norādīts detalizēts moduļu dizains, kas pazīstams kā zema līmeņa dizains
| Kodēšanas fāze: | Pēc projektēšanas tiek uzsākta kodēšanas fāze. Pamatojoties uz prasībām, tiek izlemts par piemērotu programmēšanas valodu. Ir dažas vadlīnijas un standarti kodēšanai. Pirms reģistrēšanās repozitorijā galīgā versija tiek optimizēta, lai nodrošinātu labāku veiktspēju, un kodam tiek veiktas daudzas koda pārskatīšanas, lai pārbaudītu veiktspēju.
Ir dažādas V modeļa validācijas fāzes fāzes:
| Vienības pārbaude: | V-modelī vienību pārbaudes plāni (UTP) tiek izstrādāti moduļa projektēšanas fāzē. Šīs UTP tiek izpildītas, lai novērstu kļūdas koda vai vienības līmenī. Vienība ir mazākā vienība, kas var pastāvēt neatkarīgi, piemēram, programmas modulis. Vienību pārbaude pārbauda, vai mazākā entītija var pareizi darboties, ja tā ir izolēta no pārējiem kodiem/vienībām.
| Integrācijas pārbaude: | Integrācijas pārbaudes plāni tiek izstrādāti arhitektūras projektēšanas posmā. Šie testi pārbauda, vai grupas, kas izveidotas un pārbaudītas neatkarīgi, var pastāvēt līdzās un sazināties savā starpā.
| Sistēmas pārbaude: | Sistēmas testu plāni tiek izstrādāti sistēmas projektēšanas fāzē. Atšķirībā no vienības un integrācijas pārbaudes plāniem, sistēmas testu plānus veido klienta biznesa komanda. Sistēmas pārbaude nodrošina, ka tiek izpildītas lietojumprogrammu izstrādātāja cerības.
| Pieņemšanas pārbaude: | Pieņemšanas pārbaude ir saistīta ar biznesa prasību analīzes daļu. Tas ietver programmatūras produkta testēšanu lietotāja atmosfērā. Pieņemšanas testi atklāj saderības problēmas ar dažādām sistēmām, kas ir pieejamas lietotāja vidē. Tas vienlaikus atklāj nefunkcionālas problēmas, piemēram, slodzes un veiktspējas defektus reālajā lietotāja atmosfērā.
Kad lietot V modeli?
- Ja prasība ir labi definēta un nav viennozīmīga.
- V-veida modelis būtu jāizmanto maziem un vidējiem projektiem, kur prasības ir skaidri noteiktas un fiksētas.
- V-veida modelis ir jāizvēlas, ja ir pieejami tehniskie resursi ar būtiskām tehniskām zināšanām.
V modeļa priekšrocības (plusi):
- Viegli saprast.
- Testēšanas metodes, piemēram, plānošana, testu izstrāde notiek krietni pirms kodēšanas.
- Tas ietaupa daudz laika. Tādējādi lielāka iespēja gūt panākumus, salīdzinot ar ūdenskrituma modeli.
- Izvairās no defektu plūsmas lejup.
- Labi darbojas maziem plāniem, kur prasības ir viegli saprotamas.
V modeļa trūkums (mīnusi):
- Ļoti stingrs un vismazāk elastīgs.
- Tas nav piemērots sarežģītam projektam.
- Programmatūra tiek izstrādāta ieviešanas stadijā, tāpēc netiek ražoti programmatūras agrīnie prototipi.
- Ja pa vidu notiek kādas izmaiņas, tad pārbaudes dokumenti kopā ar nepieciešamajiem dokumentiem ir jāatjaunina.
