V-modelis yra tam tikros rūšies SDLC modelis kur procesas vykdomas nuosekliai V forma. Jis taip pat žinomas kaip Patvirtinimo ir patvirtinimo modelis. Jis pagrįstas kiekvieno atitinkamo kūrimo etapo testavimo etapo susiejimu. Kiekvieno žingsnio kūrimas yra tiesiogiai susijęs su testavimo etapu. Kitas etapas prasideda tik baigus ankstesnį etapą, t. y. kiekvienai kūrimo veiklai yra atitinkama testavimo veikla.

Turinys

• V modelio dizainas
• V modelio svarba
• V modelio principai
• Kada naudoti V modelį?
• V modelio privalumai
• V modelio trūkumai
• Išvada

„V-Model“ yra programinės įrangos kūrimo gyvavimo ciklo (SDLC) modelis, suteikiantis sistemingą ir vaizdinį programinės įrangos kūrimo proceso vaizdą. Jis pagrįstas V formos idėja, o dvi V raidės kojos reiškia raidės progresavimą programinės įrangos kūrimo procesas iš reikalavimų rinkimas ir analizė, skirta projektavimui, įgyvendinimui, testavimui ir priežiūrai.

V modelio dizainas

1. Reikalavimų surinkimas ir analizė : Pirmasis V modelio etapas yra reikalavimų rinkimo ir analizės etapas, kai surenkami ir analizuojami kliento reikalavimai programinei įrangai, siekiant nustatyti projekto apimtį.
2. Dizainas: Projektavimo etape kuriama programinės įrangos architektūra ir dizainas, įskaitant aukšto lygio dizainą ir detalųjį dizainą.
3. Įgyvendinimas: Diegimo etape programinė įranga kuriama remiantis dizainu.
4. Testavimas: Testavimo fazėje programinė įranga yra testuojama, siekiant užtikrinti, kad ji atitinka kliento reikalavimus ir yra aukštos kokybės.
5. Diegimas: Diegimo etape programinė įranga įdiegiama ir pradedama naudoti.
6. Priežiūra: Techninės priežiūros etape programinė įranga prižiūrima siekiant užtikrinti, kad ji ir toliau atitiktų kliento poreikius ir lūkesčius.
7. V modelis dažnai naudojamas saugos tikslais: ypatingos svarbos sistemos, pvz., aviacijos ir gynybos sistemos, nes jose pabrėžiamas kruopštus testavimas ir gebėjimas aiškiai apibrėžti programinės įrangos kūrimo proceso veiksmus.

SDLC V modelis

Toliau pateiktoje iliustracijoje pavaizduotos skirtingos SDLC V modelio fazės.

Patikrinimas Fazės :

Tai apima statinės analizės metodą (peržiūrą), atliekamą nevykdant kodo. Tai yra produkto kūrimo etapo įvertinimo procesas, siekiant nustatyti, ar tenkinami nurodyti reikalavimai.

Yra keletas V modelio patvirtinimo etapų:

java while ciklas

Verslo reikalavimų analizė:

Tai pirmasis žingsnis nustatant kūrimo ciklą, kai reikia atsižvelgti į produkto poreikį iš kliento perspektyvos. šiuose etapuose apima tinkamą bendravimą su klientu, kad suprastų klientų reikalavimus. tai labai svarbi veikla, kurią reikia tinkamai atlikti, nes dažniausiai klientai tiksliai nežino, ko nori, ir tuo metu nėra dėl to tikri, tada naudojame priėmimo testo dizainas planavimas, kuris atliekamas verslo reikalavimo metu, jis bus naudojamas kaip įvestis priėmimo testavimui.

Sistemos dizainas:

Sistemos projektavimas prasidės, kai bus aiškūs gaminio reikalavimai, o tada reikės visiškai suprojektuoti sistemą. Šis supratimas bus baigtas produkto kūrimo proceso pradžioje. tai bus naudinga ateityje atliekant bandomuosius atvejus.

Architektūrinis dizainas:

Šiame etape yra suvokiamos ir suprojektuotos architektūrinės specifikacijos. Paprastai pateikiami keli techniniai metodai, o galutinis pasirinkimas daromas įvertinus tiek techninį, tiek finansinį pagrįstumą. Sistemos architektūra dar padalinta į modulius, kurių kiekvienas atlieka atskirą funkciją. Kitas to pavadinimas yra aukšto lygio dizainas (HLD).

Šiuo metu keitimasis duomenimis ir ryšys tarp vidinių modulių ir išorinių sistemų yra gerai suprantamas ir apibrėžtas. Šio etapo metu integracijos testai gali būti sukurti ir dokumentuojami naudojant pateiktą informaciją.

java skyriklis

Modulio dizainas:

Šis etapas, žinomas kaip žemo lygio projektavimas (LLD), nurodo išsamų kiekvieno sistemos modulio vidinį dizainą. Dizaino ir kitų išorinių sistemų bei kitų sistemos architektūros modulių suderinamumas yra labai svarbus. Vienetų testai yra esminis bet kurio kūrimo proceso komponentas, nes jie padeda ankstyvame etape nustatyti ir pašalinti daugumą klaidų ir trūkumų. Remiantis vidinio modulio konstrukcijomis, dabar galima sukurti šiuos vienetų testus.

Kodavimo fazė:

Kodavimo veiksmas apima kodo rašymą sistemos moduliams, kurie buvo sukurti projektavimo etape. Sistemos ir architektūros reikalavimai naudojami nustatant, kuri programavimo kalba yra tinkamiausia.

Atliekant kodavimą vadovaujamasi kodavimo standartais ir principais. Prieš įkeliant galutinę versiją į saugyklą, kodas yra daug kartų peržiūrimas ir optimizuojamas siekiant optimalaus veikimo.

Patvirtinimas Fazės :

Tai apima dinaminės analizės metodus (funkcinius ir nefunkcinius) ir testavimą, atliekamą vykdant kodą. Patvirtinimas – tai programinės įrangos įvertinimo procesas pasibaigus kūrimo etapui, siekiant nustatyti, ar programinė įranga atitinka kliento lūkesčius ir reikalavimus.

Taigi V-Model turi patvirtinimo fazes vienoje pusėje, o patvirtinimo fazes kitoje. Patikrinimo ir patvirtinimo fazės sujungiamos V formos kodavimo faze. Taigi jis vadinamas V modeliu.
Yra keli Patvirtinimas V modelio fazės:

Vieneto bandymas:

Vieneto testavimo planai rengiami modulio projektavimo etape. Šie vieneto testavimo planai vykdomi siekiant pašalinti kodo ar vieneto lygio klaidas.

Integracijos testavimas:

Užbaigus vienetų testavimą, atliekamas integracijos testavimas. Integravimo testavimo metu moduliai integruojami ir sistema testuojama. Integracijos testavimas atliekamas Architektūros projektavimo etape. Šis testas patikrina modulių tarpusavio ryšį.

Sistemos testavimas:

Sistemos testavimas išbando visą programą su jos funkcionalumu, tarpusavio priklausomybe ir ryšiu. Jis išbando sukurtos programos funkcinius ir nefunkcinius reikalavimus.

abstrakti klasė

Vartotojo priėmimo testavimas (UAT):

burbulų rūšiavimas java

UAT atliekama vartotojo aplinkoje, kuri panaši į gamybos aplinką. UAT patikrina, ar pristatyta sistema atitinka vartotojo reikalavimus ir ar sistema yra paruošta naudoti realiame pasaulyje.

Projektavimo etapas:

• Reikalavimų analizė: Šiame etape vyksta išsamus bendravimas su klientu, siekiant suprasti jo reikalavimus ir lūkesčius. Šis etapas žinomas kaip reikalavimų rinkimas.
• Sistemos dizainas: Šiame etape yra sistemos projektavimas ir visa aparatinė įranga bei ryšio sąranka gaminiui kurti.
• Architektūrinis dizainas: Sistemos dizainas yra suskirstytas į modulius, atliekančius skirtingas funkcijas. Aiškiai suprantamas duomenų perdavimas ir komunikacija tarp vidinių modulių ir su išoriniu pasauliu (kitomis sistemomis).
• Modulio dizainas: Šiame etape sistema suskaidoma į mažus modulius. Nurodytas detalus modulių dizainas, dar žinomas kaip žemo lygio projektavimas (LLD).

Bandymo etapai:

• Vieneto bandymas: Vieneto testavimo planai rengiami modulio projektavimo etape. Šie vieneto testavimo planai vykdomi siekiant pašalinti klaidas kodo arba vieneto lygiu.
• Integracijos testavimas: Užbaigus vienetų testavimą, atliekamas integracijos testavimas. Integravimo testavimo metu moduliai integruojami, sistema testuojama. Integracijos testavimas atliekamas Architektūros projektavimo etape. Šis testas patikrina modulių tarpusavio ryšį.
• Sistemos testavimas: Sistemos testavimas išbando visą programą su jos funkcionalumu, tarpusavio priklausomybe ir ryšiu. Jis išbando sukurtos programos funkcinius ir nefunkcinius reikalavimus.
• Vartotojo priėmimo testavimas (UAT): UAT atliekama vartotojo aplinkoje, kuri panaši į gamybos aplinką. UAT patikrina, ar pristatyta sistema atitinka vartotojo reikalavimus ir ar sistema yra paruošta naudoti realiame pasaulyje.

Pramonės iššūkis:

Tobulėjant pramonei, technologijos tapo sudėtingesnės, spartesnės ir nuolat kinta, tačiau išlieka pagrindinių principų ir sąvokų rinkinys, kurie šiandien yra tokie pat taikomi, kaip ir tada, kai IT buvo pradiniame etape.

• Tiksliai apibrėžkite ir patikslinkite vartotojo reikalavimus.
• Sukurkite ir sukurkite taikomąją programą pagal įgalioto vartotojo reikalavimus.
• Patvirtinkite, kad jų sukurta programa atitiko įgaliotus verslo reikalavimus.

V modelio svarba

1. Ankstyvas defektų nustatymas

Įtraukdamas tikrinimo ir patvirtinimo užduotis į kiekvieną kūrimo proceso etapą, „V-Model“ skatina ankstyvą testavimą. Tai sumažina išlaidas ir pastangas, kurių reikia norint ištaisyti problemas vėliau kūrimo ciklo metu, nes padeda anksti aptikti ir pašalinti gedimus.

2. kūrimo ir testavimo fazių nustatymas

V modelyje yra testavimo fazė, atitinkanti kiekvieną kūrimo proceso etapą. Užtikrindamas, kad testavimo ir kūrimo procesai būtų aiškiai suplanuoti, šis aiškus planavimas skatina metodinį ir tvarkingą požiūrį į programinės įrangos inžineriją.

3. Apsaugo nuo Didžiojo sprogimo bandymų

Bandymai dažnai atliekami pačioje tradicinių kūrimo modelių kūrimo ciklo pabaigoje, o tai lemia Didžiojo sprogimo metodą, kai visos testavimo operacijos sutelkiamos vienu metu. Integruodamas testavimo veiklą į kūrimo procesą ir skatindamas progresyvesnį bei reglamentuotą testavimo metodą, V modelis to užkerta.

4. Gerina bendradarbiavimą

Kiekviename lygyje „V-Model“ skatina bandymų ir kūrimo komandų bendradarbiavimą. Dėl šio bendradarbiavimo geriau suprantami projekto reikalavimai, dizaino pasirinkimai ir testavimo metodikos, o tai pagerina kūrimo proceso efektyvumą ir efektyvumą.

5. Geresnis kokybės užtikrinimas

Bendrą kokybės užtikrinimą pagerina V-modelis, kuris apima visų lygių testavimo operacijas. Prieš pasiekiant galutinį diegimo etapą, programa įsitikina, kad ji atitinka reikalavimus, ir atlieka griežtą patvirtinimo ir tikrinimo procesą.

V modelio principai

• Nuo didelio iki mažo: „V-Model“ testavimas atliekamas hierarchine perspektyva, pavyzdžiui, pagal reikalavimus, kuriuos nustato projekto komanda, kuriant aukšto lygio dizaino ir detalaus projekto etapus. Kai kiekvienas iš šių etapų atitinka reikalavimus, jie tampa vis tobulesni ir išsamesni.
• Duomenų / procesų vientisumas: Šis principas teigia, kad norint sėkmingai suplanuoti bet kokį projektą, reikia įtraukti ir suderinti duomenis ir procesus. Proceso elementai turi būti nurodyti kiekvienu reikalavimu.
• Mastelio keitimas: Šis principas teigia, kad „V-Model“ koncepcija yra lanksti, kad būtų galima pritaikyti bet kokį IT projektą, nepaisant jo dydžio, sudėtingumo ar trukmės.
• Kryžminės nuorodos: Tiesioginė koreliacija tarp reikalavimų ir atitinkamos testavimo veiklos vadinama kryžmine nuoroda.

Apčiuopiama dokumentacija:

Šis principas teigia, kad kiekvienam projektui reikia sukurti dokumentą. Šių dokumentų reikalauja ir taiko ir projekto kūrimo komanda, ir palaikymo komanda. Dokumentacija naudojama programai prižiūrėti, kai ji pasiekiama gamybinėje aplinkoje.

Kodėl pirmenybė?

• Jį lengva valdyti dėl modelio tvirtumo. Kiekvienas „V-Model“ etapas turi konkrečius rezultatus ir peržiūros procesą.
• Proaktyvus defektų sekimas – tai yra defektai nustatomi ankstyvoje stadijoje.

Kada naudoti apie V-modelis ?

• Reikalavimų atsekamumas: V-modelis yra naudingas tais atvejais, kai būtina sukurti tikslų reikalavimų ir su jais susijusių bandymų atsekamumą.
• Sudėtingi projektai: „V-Model“ siūlo metodinį būdą valdyti testavimo veiklą ir sumažinti su integravimo ir sąsajos problemomis susijusią riziką projektams, turintiems didelį sudėtingumo lygį ir sistemos komponentų tarpusavio priklausomybę.
• Į krioklį panašūs projektai : Kadangi V-modelis siūlo prieinamą struktūrą, leidžiančią organizuoti, atlikti ir stebėti testavimo veiklą kiekviename kūrimo lygyje, jis tinka projektams, kuriuose naudojamas nuoseklus kūrimo metodas, panašiai kaip krioklio modelis.
• Saugumui svarbios sistemos: Šios sistemos naudojamos aviacijos, automobilių ir sveikatos priežiūros pramonėje. Juose didelis dėmesys skiriamas griežtoms tikrinimo ir patvirtinimo procedūroms, kurios padeda užtikrinti, kad būtų įvykdyti esminiai sistemos reikalavimai ir kad galima rizika būtų randama ir pašalinama ankstyvame kūrimo procese.

Privalumai V modelio

• Tai labai disciplinuotas modelis, o etapai baigiami po vieną.
• V-Model naudojamas mažiems projektams, kur projekto reikalavimai yra aiškūs.
• Paprasta ir lengva suprasti bei naudoti.
• Šiame modelyje pagrindinis dėmesys skiriamas tikrinimo ir patvirtinimo veiklai ankstyvame gyvavimo ciklo etape, taip padidinant tikimybę, kad bus sukurtas be klaidų ir geros kokybės produktas.
• Tai leidžia projekto valdymui tiksliai sekti pažangą.
• Aiškus ir struktūrizuotas procesas: V-modelis suteikia aiškų ir struktūrizuotą procesą programinės įrangos kūrimas , kad būtų lengviau suprasti ir sekti.
• Dėmesys testavimui: „V-Model“ daug dėmesio skiria testavimui, kuris padeda užtikrinti programinės įrangos kokybę ir patikimumą.
• Patobulintas atsekamumas: V-Model suteikia aiškią sąsają tarp reikalavimų ir galutinio produkto, todėl lengviau atsekti ir valdyti programinės įrangos pakeitimus.
• Geresnė komunikacija: aiški V modelio struktūra padeda pagerinti kliento ir kūrėjų komandos bendravimą.

V modelio trūkumai

• Didelė rizika ir netikrumas.
• Tai netinka sudėtingiems ir į objektą orientuotiems projektams.
• Jis netinka projektams, kuriuose reikalavimai neaiškūs ir yra didelė rizika pasikeisti.
• Šis modelis nepalaiko fazių iteracijos.
• Tai nelengva valdyti tuo pačiu metu vykstančius įvykius.
• Nelankstumas: V modelis yra linijinis ir nuoseklus modelis, dėl kurio gali būti sunku prisitaikyti prie kintančių reikalavimų ar netikėtų įvykių.
• Atimanti daug laiko: V modeliui gali prireikti daug laiko, nes reikia daug dokumentacijos ir bandymų.
• Per didelis pasikliovimas dokumentacija: V modelyje didelis dėmesys skiriamas dokumentacijai, todėl gali būti per daug pasikliaujama dokumentacija faktinio kūrimo darbo sąskaita.

Išvada

Programinės įrangos inžinerijos V modelis suteikia mokslinį ir organizuotą požiūrį į programinės įrangos kūrimo gyvavimo ciklą (SDLC). Renkantis bet kokius SDLC modelius, įskaitant V-Model, reikia atsižvelgti į komandos patirtį taikant pasirinktą metodiką, unikalias projekto ypatybes ir reikalavimų pobūdį.

Žinynas:

Programinės įrangos inžinerija: praktikų požiūris, Roger S. Pressman, išleido McGraw-Hill Education, 2017 m.