V veida modelis ir sava veida SDLC modelis kur process tiek izpildīts secīgi V formā. To sauc arī par verifikācijas un validācijas modeli. Tas ir balstīts uz testēšanas fāzes asociāciju katram atbilstošajam izstrādes posmam. Katra posma izstrāde ir tieši saistīta ar testēšanas posmu. Nākamā fāze sākas tikai pēc iepriekšējās fāzes pabeigšanas, t.i., katrai izstrādes darbībai tiek veikta tai atbilstoša testēšanas darbība.

Satura rādītājs

• V modeļa dizains
• V modeļa nozīme
• V modeļa principi
• Kad izmantot V modeli?
• V modeļa priekšrocības
• V-modeļa trūkumi
• Secinājums

V-Model ir programmatūras izstrādes dzīves cikla (SDLC) modelis, kas nodrošina sistemātisku un vizuālu programmatūras izstrādes procesa attēlojumu. Tas ir balstīts uz V formas ideju, un abas V kājiņas attēlo V formas progresēšanu programmatūras izstrādes process no prasību apkopošana un analīze, lai izstrādātu, ieviestu, testētu un uzturētu.

virkne līdz veseliem skaitļiem

V modeļa dizains

1. Prasību apkopošana un analīze : V-Model pirmā fāze ir prasību apkopošanas un analīzes fāze, kurā tiek apkopotas un analizētas klienta prasības programmatūrai, lai noteiktu projekta apjomu.
2. Dizains: Projektēšanas fāzē tiek izstrādāta programmatūras arhitektūra un dizains, ieskaitot augsta līmeņa dizainu un detalizētu dizainu.
3. Īstenošana: Ieviešanas fāzē programmatūra tiek veidota, pamatojoties uz dizainu.
4. Testēšana: Testēšanas posmā programmatūra tiek pārbaudīta, lai pārliecinātos, ka tā atbilst klienta prasībām un ir kvalitatīva.
5. Izvietošana: Izvēršanas fāzē programmatūra tiek izvietota un nodota lietošanā.
6. Apkope: Apkopes fāzē programmatūra tiek uzturēta, lai nodrošinātu, ka tā arī turpmāk atbilst klienta vajadzībām un vēlmēm.
7. V-modelis bieži tiek izmantots drošībā: kritiskām sistēmām, piemēram, aviācijas un aizsardzības sistēmām, jo ​​tās liek uzsvaru uz rūpīgu testēšanu un spēj skaidri definēt programmatūras izstrādes procesā iesaistītās darbības.

SDLC V-modelis

Nākamajā attēlā ir attēlotas dažādas SDLC V modeļa fāzes.

Pārbaude Fāzes :

Tas ietver statiskās analīzes paņēmienu (pārskatīšanu), kas tiek veikts bez koda izpildes. Tas ir produkta izstrādes posma novērtēšanas process, lai noskaidrotu, vai noteiktās prasības ir izpildītas.

V-modelī ir vairākas verifikācijas fāzes:

Uzņēmuma prasību analīze:

Šis ir pirmais solis izstrādes cikla noteikšanai, kurā produkta prasības ir jārisina no klienta viedokļa. šajās fāzēs ietver pareizu saziņu ar klientu, lai izprastu klientu prasības. šīs ir ļoti svarīgas darbības, ar kurām ir jārīkojas pareizi, jo vairumā gadījumu klienti nezina, ko tieši viņi vēlas, un tajā brīdī nav par to pārliecināti, tad mēs izmantojam pieņemšanas testa dizains plānošana, kas tiek veikta uzņēmējdarbības nepieciešamības laikā, tiks izmantota kā ievade pieņemšanas pārbaudei.

ddl pret dml

Sistēmas dizains:

Sistēmas projektēšana sāksies, kad kopumā būsim skaidrībā ar produkta prasībām, un pēc tam sistēma būs jāizstrādā pilnībā. Šī izpratne tiks pabeigta produkta izstrādes procesa sākumā. tie būs noderīgi turpmākai testa gadījumu izpildei.

Arhitektūras dizains:

Šajā posmā tiek izprastas un izstrādātas arhitektūras specifikācijas. Parasti tiek izmantotas vairākas tehniskas pieejas, un galīgā izvēle tiek veikta, ņemot vērā gan tehnisko, gan finansiālo dzīvotspēju. Sistēmas arhitektūra ir sadalīta moduļos, no kuriem katrs veic noteiktu funkciju. Cits nosaukums tam ir augsta līmeņa dizains (HLD).

Šobrīd datu apmaiņa un komunikācija starp iekšējiem moduļiem un ārējām sistēmām ir labi saprotama un definēta. Šajā posmā integrācijas testus var izveidot un dokumentēt, izmantojot sniegto informāciju.

Moduļa dizains:

Šī fāze, kas pazīstama kā zema līmeņa projektēšana (LLD), nosaka visaptverošu iekšējo dizainu katram sistēmas modulim. Izšķiroša nozīme ir saderībai starp dizainu un citām ārējām sistēmām, kā arī citiem sistēmas arhitektūras moduļiem. Vienību testi ir būtiska jebkura izstrādes procesa sastāvdaļa, jo tie palīdz identificēt un novērst lielāko daļu kļūdu un trūkumu agrīnā stadijā. Pamatojoties uz iekšējo moduļu projektiem, tagad var izveidot šīs vienības pārbaudes.

Kodēšanas fāze:

Kodēšanas darbība ietver koda rakstīšanu sistēmas moduļiem, kas tika izveidoti projektēšanas fāzē. Sistēmas un arhitektūras prasības tiek izmantotas, lai noteiktu, kura programmēšanas valoda ir vispiemērotākā.

Veicot kodēšanu, tiek ievēroti kodēšanas standarti un principi. Pirms galīgā versija tiek pārbaudīta repozitorijā, kods tiek daudzkārt pārskatīts un tiek optimizēts optimālai veiktspējai.

Validācija Fāzes :

Tas ietver dinamiskas analīzes metodes (funkcionālas un nefunkcionālas) un testēšanu, ko veic, izpildot kodu. Validācija ir programmatūras novērtēšanas process pēc izstrādes fāzes pabeigšanas, lai noteiktu, vai programmatūra atbilst klienta vēlmēm un prasībām.

rekursija java

Tātad V-modelis satur verifikācijas fāzes vienā pusē, bet apstiprinājuma fāzes otrā pusē. Verifikācijas un validācijas fāzes tiek savienotas ar kodēšanas fāzi V formā. Tādējādi to sauc par V-modeli.
Ir vairāki Validācija fāzes V-modelī:

Vienības pārbaude:

Vienību pārbaudes plāni tiek izstrādāti moduļa projektēšanas fāzē. Šie vienības pārbaudes plāni tiek izpildīti, lai novērstu kļūdas koda vai vienības līmenī.

Integrācijas pārbaude:

Pēc vienības testēšanas pabeigšanas tiek veikta integrācijas pārbaude. Integrācijas testēšanā moduļi tiek integrēti un sistēma tiek testēta. Integrācijas testēšana tiek veikta Arhitektūras projektēšanas fāzē. Šis tests pārbauda moduļu savstarpējo saziņu.

Sistēmas pārbaude:

Sistēmas testēšana pārbauda visu lietojumprogrammu ar tās funkcionalitāti, savstarpējo atkarību un saziņu. Tā pārbauda izstrādātās lietojumprogrammas funkcionālās un nefunkcionālās prasības.

stīgu maiņa c

Lietotāju pieņemšanas pārbaude (UAT):

UAT tiek veikta lietotāja vidē, kas līdzinās ražošanas videi. UAT pārbauda, ​​vai piegādātā sistēma atbilst lietotāja prasībām un sistēma ir gatava lietošanai reālajā pasaulē.

Projektēšanas posms:

• Prasību analīze: Šis posms ietver detalizētu saziņu ar klientu, lai izprastu viņa prasības un cerības. Šis posms ir pazīstams kā prasību apkopošana.
• Sistēmas dizains: Šajā fāzē ir iekļauts sistēmas dizains un pilnīga aparatūras un sakaru iestatīšana produkta izstrādei.
• Arhitektūras dizains: Sistēmas dizains ir sīkāk sadalīts moduļos, kas nodrošina dažādas funkcijas. Ir skaidri saprotama datu pārraide un komunikācija starp iekšējiem moduļiem un ārpasauli (citām sistēmām).
• Moduļa dizains: Šajā fāzē sistēma sadalās mazos moduļos. Ir norādīts detalizēts moduļu dizains, kas pazīstams arī kā zema līmeņa projektēšana (LLD).

Pārbaudes fāzes:

• Vienības pārbaude: Vienību pārbaudes plāni tiek izstrādāti moduļa projektēšanas fāzē. Šie vienības pārbaudes plāni tiek izpildīti, lai novērstu kļūdas koda vai vienības līmenī.
• Integrācijas pārbaude: Pēc vienības testēšanas pabeigšanas tiek veikta integrācijas pārbaude. Integrācijas testēšanā moduļi tiek integrēti un sistēma tiek testēta. Integrācijas testēšana tiek veikta Arhitektūras projektēšanas fāzē. Šis tests pārbauda moduļu savstarpējo saziņu.
• Sistēmas pārbaude: Sistēmas testēšana pārbauda visu lietojumprogrammu ar tās funkcionalitāti, savstarpējo atkarību un saziņu. Tā pārbauda izstrādātās lietojumprogrammas funkcionālās un nefunkcionālās prasības.
• Lietotāju pieņemšanas pārbaude (UAT): UAT tiek veikta lietotāja vidē, kas līdzinās ražošanas videi. UAT pārbauda, ​​vai piegādātā sistēma atbilst lietotāja prasībām un sistēma ir gatava lietošanai reālajā pasaulē.

Rūpnieciskais izaicinājums:

Nozarei attīstoties, tehnoloģijas ir kļuvušas sarežģītākas, arvien ātrākas un pastāvīgi mainās, tomēr joprojām ir pamatprincipu un koncepciju kopums, kas ir tikpat piemērojami kā tad, kad IT bija sākumstadijā.

mīlivecricket

• Precīzi definējiet un precizējiet lietotāju prasības.
• Izstrādājiet un izveidojiet lietojumprogrammu atbilstoši autorizēto lietotāju prasībām.
• Pārbaudiet, vai viņu izveidotā lietojumprogramma atbilst autorizētajām uzņēmējdarbības prasībām.

V modeļa nozīme

1. Agrīna defektu identificēšana

Iekļaujot verifikācijas un validācijas uzdevumus katrā izstrādes procesa posmā, V-Model veicina agrīnu testēšanu. Tas samazina izmaksas un pūles, kas nepieciešamas problēmu novēršanai vēlāk izstrādes dzīves ciklā, palīdzot agrīni atklāt un novērst kļūdas.

2. izstrādes un testēšanas fāžu noteikšana

V-Modelis satur testēšanas fāzi, kas atbilst katram izstrādes procesa posmam. Nodrošinot, ka testēšanas un izstrādes procesi ir skaidri iezīmēti, šī skaidrā kartēšana veicina metodisku un sakārtotu pieeju programmatūras inženierijai.

3. Novērš Lielā sprādziena testēšanu

Tradicionālajos izstrādes modeļos testēšana bieži tiek veikta izstrādes cikla pašās beigās, kā rezultātā tiek izmantota Lielā sprādziena pieeja, kurā visas testēšanas darbības tiek koncentrētas vienlaikus. Integrējot testēšanas darbības izstrādes procesā un veicinot progresīvāku un regulētāku testēšanas pieeju, V-Model to novērš.

4. Uzlabo sadarbību

Katrā līmenī V-Model veicina sadarbību starp testēšanas un izstrādes komandām. Pateicoties šai sadarbībai, tiek labāk izprastas projekta prasības, dizaina izvēles un testēšanas metodoloģijas, kas uzlabo izstrādes procesa efektivitāti un efektivitāti.

5. Uzlabota kvalitātes nodrošināšana

Vispārējo kvalitātes nodrošināšanu uzlabo V-Model, kas ietver testēšanas darbības visos līmeņos. Pirms programma sasniedz pēdējo izvietošanas posmu, tā pārliecinās, ka tā atbilst prasībām, un iziet stingru validācijas un verifikācijas procesu.

V modeļa principi

• No liela līdz mazam: V-modelī testēšana tiek veikta hierarhiskā perspektīvā, piemēram, projekta komandas noteiktās prasības, izveidojot projekta augsta līmeņa dizaina un detalizētā dizaina fāzes. Kad katrs no šiem posmiem ir izpildīts, prasības tiek noteiktas, kļūst arvien izsmalcinātākas un detalizētākas.
• Datu/procesa integritāte: Šis princips nosaka, ka jebkura projekta veiksmīgai izstrādei ir nepieciešama datu un procesu iekļaušana un kohēzija. Procesa elementi ir jāidentificē katrā prasībā.
• Mērogojamība: Šis princips nosaka, ka V-Model koncepcija ir elastīga, lai pielāgotos jebkuram IT projektam neatkarīgi no tā lieluma, sarežģītības vai ilguma.
• Savstarpējās atsauces: Tieša korelācija starp prasībām un atbilstošo testēšanas darbību ir pazīstama kā savstarpēja atsauce.

Materiāla dokumentācija:

Šis princips nosaka, ka katram projektam ir jāizveido dokuments. Šo dokumentāciju pieprasa un piemēro gan projekta izstrādes komanda, gan atbalsta komanda. Dokumentācija tiek izmantota, lai uzturētu lietojumprogrammu, kad tā ir pieejama ražošanas vidē.

Kāpēc priekšroka?

• Modeļa stingrības dēļ to ir viegli pārvaldīt. Katrai V-Model fāzei ir konkrēti rezultāti un pārskatīšanas process.
• Proaktīva defektu izsekošana – tas ir, defekti tiek atklāti agrīnā stadijā.

Kad lietot no V-modelis ?

• Prasību izsekojamība: V-modelis izrādās noderīgs situācijās, kad ir obligāti jārada precīza izsekojamība starp prasībām un ar tām saistītajiem testa gadījumiem.
• Sarežģīti projekti: V-Model piedāvā metodisku veidu, kā pārvaldīt testēšanas darbības un samazināt riskus, kas saistīti ar integrācijas un saskarnes problēmām projektiem ar augstu sarežģītības līmeni un sistēmas komponentu savstarpēju atkarību.
• Ūdenskritumam līdzīgi projekti : Tā kā V-Model piedāvā pieejamu struktūru testēšanas aktivitāšu organizēšanai, veikšanai un uzraudzībai visos attīstības līmeņos, tas ir piemērots projektiem, kuros izmanto secīgu pieeju izstrādei, līdzīgi kā ūdenskrituma modelim.
• Drošībai kritiskās sistēmas: Šīs sistēmas tiek izmantotas kosmosa, automobiļu un veselības aprūpes nozarēs. Tie liek lielu uzsvaru uz stingrām verifikācijas un validācijas procedūrām, kas palīdz garantēt būtisku sistēmas prasību izpildi un iespējamo risku atrašanu un novēršanu izstrādes procesa sākumā.

Priekšrocības no V modeļa

• Šis ir ļoti disciplinēts modelis, un fāzes tiek pabeigtas pa vienai.
• V-Model tiek izmantots maziem projektiem, kur projekta prasības ir skaidras.
• Vienkāršs un viegli saprotams un lietojams.
• Šis modelis koncentrējas uz verifikācijas un validācijas darbībām dzīves cikla sākumā, tādējādi palielinot iespēju izveidot bezkļūdu un labas kvalitātes produktu.
• Tas ļauj projektu vadībai precīzi izsekot progresam.
• Skaidrs un strukturēts process: V-modelis nodrošina skaidru un strukturētu procesu programmatūras izstrāde , padarot to vieglāk saprotamu un izsekojamu.
• Uzsvars uz testēšanu: V-Model liek lielu uzsvaru uz testēšanu, kas palīdz nodrošināt programmatūras kvalitāti un uzticamību.
• Uzlabota izsekojamība: V-Model nodrošina skaidru saikni starp prasībām un galaproduktu, atvieglojot programmatūras izmaiņu izsekošanu un pārvaldību.
• Labāka komunikācija: V-Model skaidrā struktūra palīdz uzlabot saziņu starp klientu un izstrādes komandu.

V-modeļa trūkumi

• Augsts risks un nenoteiktība.
• Tas nav piemērots sarežģītiem un objektorientētiem projektiem.
• Tas nav piemērots projektiem, kur prasības nav skaidras un ietver lielu izmaiņu risku.
• Šis modelis neatbalsta fāžu iterāciju.
• Tas nav viegli apstrādāt vienlaicīgus notikumus.
• Neelastība: V-Model ir lineārs un secīgs modelis, kas var apgrūtināt pielāgošanos mainīgajām prasībām vai negaidītiem notikumiem.
• Laikietilpīgs: V-modelis var būt laikietilpīgs, jo tas prasa daudz dokumentācijas un testēšanas.
• Pārmērīga paļaušanās uz dokumentāciju: V-modelis liek lielu uzsvaru uz dokumentāciju, kas var novest pie pārmērīgas paļaušanās uz dokumentāciju uz faktiskā izstrādes darba rēķina.

Secinājums

Zinātnisku un organizētu pieeju programmatūras izstrādes dzīves ciklam (SDLC) nodrošina programmatūras inženierijas V-modelis. Izvēloties visus SDLC modeļus, tostarp V-Model, jāņem vērā komandas zināšanas par izvēlēto metodoloģiju, projekta unikālās iezīmes un prasību būtība.

Rokasgrāmata:

Programmatūras inženierija: praktizētāja pieeja, Roger S. Pressman, izdevis McGraw-Hill Education, 2017.