Klients (pieteikuma iesniedzējs). Šī loma pieder tās organizācijas pārstāvim, kura pasūtījusi sistēmas izstrādi. Parasti pretendents ir ierobežots savā mijiedarbībā un sazinās tikai ar projektu vadītājiem un sertifikācijas vai ieviešanas speciālistu. Parasti klientam ir tiesības mainīt produkta prasības (tikai mijiedarbībā ar vadītājiem), iepazīties ar projektēšanas un sertifikācijas dokumentāciju, kas ietekmē izstrādājamās sistēmas netehniskās īpašības.
Projektu menedžeris. Šī loma nodrošina saziņas kanālu starp klientu un projekta komandu. Produktu vadītājs pārvalda klientu vēlmes un izstrādā un uztur projekta biznesa kontekstu. Viņa darbs nav tieši saistīts ar pārdošanu, viņš ir orientēts uz preci, viņa uzdevums ir noteikt un nodrošināt klientu prasībām. Projekta vadītājam ir tiesības mainīt preces prasības un gala produkta dokumentāciju.
Programmas vadītājs. Šī loma pārvalda komunikāciju un attiecības projekta komandā, darbojas kā koordinators, izstrādā un pārvalda funkcionālās specifikācijas, uztur projekta grafiku un ziņo par projekta statusu, kā arī ierosina lēmumus, kas ir svarīgi projekta virzībai.
Testēšana- programmas izpildes process, lai atklātu kļūdu.
Testa dati- ievades, kas tiek izmantotas, lai pārbaudītu sistēmu.
Pārbaudes gadījums- ieejas sistēmas testēšanai un paredzamās izejas atkarībā no ieejām, ja sistēma darbojas saskaņā ar prasību specifikāciju.
Laba testa situācija- situācija, kurā ir liela varbūtība atklāt vēl neatklātu kļūdu.
Veiksmīgs tests- tests, kas atklāj vēl neatklātu kļūdu.
Kļūda- programmētāja darbība izstrādes stadijā, kas noved pie tā, ka programmatūrā ir iekšējs defekts, kas programmas darbības laikā var novest pie nepareiza rezultāta.
Atteikums- neparedzama sistēmas uzvedība, kas noved pie negaidīta rezultāta, ko varētu izraisīt tajā esošie defekti.
Tādējādi programmatūras testēšanas procesā parasti tiek pārbaudīts tālāk norādītais.
Programmatūras verifikācija Verifikācija ir testēšanas veids. Tas tika izstrādāts 80. gados. Klārks un Emersons ASV, un neatkarīgi Kveils un Sifakis Francijā. Programmatūras testēšana ir programmatūras kļūdu identificēšanas process. Pašreizējās programmatūras testēšanas metodes neļauj mums viennozīmīgi noteikt analizējamās programmas pareizu darbību. Verifikācija (no latīņu verus — taisnība, facere — darīt) — pārbaude, pārbaudāmība, veids, kā pamatot (apstiprināt) jebkurus teorētiskos apgalvojumus, salīdzinot tos ar eksperimentāliem datiem. Verifikācija ir apstiprinājums, kas balstīts uz objektīvu pierādījumu sniegšanu, ka noteiktās prasības ir izpildītas (saskaņā ar GOST ISO).
Formālā pārbaude Formālā pārbaude Parasti lielākā daļa programmatūras sistēmu izstrādātāju izmanto simulācijas modelēšanas un testēšanas metodes, lai pārbaudītu dizaina pareizību. Tās ir diezgan efektīvas agrīnā atkļūdošanas stadijā, kad projektētajā sistēmā joprojām ir daudz kļūdu, taču šo metožu efektivitāte ātri samazinās, sistēmai kļūstot tīrākai. Formālās verifikācijas metodes ir cienīga alternatīva simulācijas modelēšanai un testēšanai. Simulācijas modelēšana un testēšana pārbauda tikai dažus no projektētās sistēmas iespējamiem uzvedības scenārijiem, tāpēc paliek atklāts jautājums, vai neizmantotās trajektorijas satur fatālu kļūdu. Formālā pārbaude nodrošina visu iespējamo sistēmas darbības iespēju izsmeļošu analīzi.
Formālās verifikācijas metodes Automātiskā teorēmu pierādīšana – programmatūrā realizēto teorēmu pierādīšana. Tas ir balstīts uz matemātiskās loģikas aparātu. Izmanto arī idejas no mākslīgā intelekta teorijas. Pierādīšanas process balstās uz propozicionālu un predikātu loģiku. Modeļa pārbaude. Metode paralēlu sistēmu automātiskai verifikācijai ar ierobežotu stāvokļu skaitu. Simbolisks izpildījums (grafiki). Abstrakta interpretācija.
Formālās verifikācijas posmi uz modeļa Formālās verifikācijas posmi uz modeļa Modelēšana. Projektētajai sistēmai ir nepieciešams izveidot tās abstrakto modeli (piemēram, ierobežotu pāreju sistēmu), kas ir pieņemams programmu modeļu pārbaudes rīkiem. Specifikācija. Šis uzdevums sastāv no īpašību formulēšanas, kurām vajadzētu būt projektētajai sistēmai. Nav iespējams noteikt, vai konkrētā specifikācija aptver visas īpašības, kurām vajadzētu būt sistēmai. Aparatūrai un programmatūrai, kā likums, tiek izmantota dinamiskā loģika, laika loģikas un to varianti ar fiksētiem punktiem. Algoritmu aprēķini. Globālā modeļa pārbaudes algoritma aprēķinu rezultāts ir modeļa stāvokļu kopa, kurā specifikācija ir izpildīta, un lokālais modeļa pārbaudes algoritms kā pretpiemēru konstruē kādu aprēķinu (kļūdas izsekošanu), kas parāda, kāpēc formula nav spēkā. Pretpiemēri ir īpaši svarīgi, lai sarežģītās pārejas sistēmās atrastu smalkas kļūdas.
Modeļa pārbaudes metode Salīdzinājumā ar citām formālās programmas pārbaudes pieejām, modeļa pārbaudes metodei ir divas ievērojamas priekšrocības: tā ir pilnībā automātiska, un tās pielietošanai lietotājam nav vajadzīgas īpašas zināšanas matemātiskās disciplīnās, piemēram, loģikas un teorēmu pierādīšanas teorijā. Ikviens, kurš var simulēt projektējamo sistēmu, ir pilnībā spējīgs pārbaudīt šo sistēmu. Ja projektētajai sistēmai nav vēlamās īpašības, tad modeļa pārbaudes rezultāts būs pretpiemērs, kas demonstrē sistēmas uzvedību, kas atspēko šo īpašību. Šī kļūdas izsekošana sniedz nenovērtējamu informāciju, lai izprastu kļūdas cēloni, kā arī svarīgas problēmas risināšanas norādes. Modeļa pārbaudes metodes galvenais trūkums ir "kombinatoriskais sprādziens", kas rodas, ja pārejas dažos sistēmas komponentos tiek veiktas paralēli. 1987. gadā K. Makmilans parādīja, ka, izmantojot simbolisku pārejas grafa attēlojumu, var pārbaudīt ļoti sarežģītas sistēmas. Jaunā simboliskā attēlojuma pamatā bija Braiena pasūtītās binārās izšķirtspējas diagrammas (OBDD).
BKU programmatūras verifikācijas jēdziens RSC Energia nevar pilnībā izmantot verifikācijas jēdzienu, jo, veidojot ļoti sarežģītas sistēmas, nav iespējams veikt pilnīgu verifikāciju, jo pastāv laika un izmaksu ierobežojumi. Kvalitātes rādītājs izstrādei un testēšanai pēc BKU KA
BKU programmatūras izstrāde un testēšana. RSC Energia uzņēmumā BKU programmatūras testēšanai tiek izmantotas NPO, kas darbojas reāllaikā. Visaptverošu programmatūras izstrādi un testēšanu veic integrācijas un testēšanas grupa, izmantojot speciāli izstrādātas programmas un testēšanas metodes (TMP) (testa scenārijus). NKO-1 NKO-2 (īstā BCWS iekārta) Izmanto BKU programmatūras integrācijai un sekojošai atkļūdošanai, lai: selektīvi pārbaudītu galvenos ceļus visticamākajām avārijas situācijām; saskarnes vadība, t.i. programmatūras testēšana ietvaros: datu masīvu un vārdu apmaiņa; komandu masīvu pārsūtīšana; TM datu pārsūtīšana; pārbaudot resursu sadalījumu (atmiņa, CPU laiks, I/O kanāli). Izmanto BKU programmatūras testēšanai vai citai pārbaudei šādā apjomā: BKU programmatūras testēšana saskaņā ar lidojuma plānu (FP) un kosmosa kuģa režīmiem; pārbaudīt programmatūras atbilstību specifikācijām.
Testa metožu programma Programmatūras testēšanas veikšanai tiek izstrādātas testēšanas metožu programmas (TMP). Katra scenārija MPI ir jāsatur informācija, lai noteiktu atbilstību starp faktiskajiem testa rezultātiem un plānotajiem testa rezultātiem, kā arī katra kontrolētā parametra pielaides.
Testa scenārijs Sarežģītas atkļūdošanas testa scenārijs ir izveidots, pamatojoties uz atkļūdošanas procesu loģisko diagrammu. Scenārijam ir jāatspoguļo notikumu rašanās un to savstarpējās attiecības laikā. Diskrētu laika momentu izvēle, kurā tiek veikts novērtējums un kontroles darbības, ir atkarīga no programmatūras specifikas un atkļūdošanas ieviešanas procesa gaitas. Testa skripti tiek rakstīti valodās, kas izstrādātas uzņēmumā. Šajās valodās ietilpst: D Dipole (izmantota Jamalas satelītu sakaru sistēmas SM, TGK un KA izveidē, tiek izmantota arī CIS kontroles testēšanas stendā); L Lua (šobrīd tiek izmantots MRM1 - mazs pētniecības modulis); iekšējās pārbaudes valodās.
Prasību izsekojamības matrica (NKO2) Prasību izsekojamības matrica satur visu prasību sarakstu, programmas vienības identifikatoru, programmas vienības nosaukumu, augstākas tehniskās specifikācijas prasību numuru un šīs prasības apstiprinošā testa identifikatoru.
Testa ziņojums Testa ziņojums ir teksta fails, kurā hronoloģiskā secībā ir iekļautas sistēmas reakcijas uz ievades ietekmi testēšanas laikā. Protokolā ir norādīts notikuma Maskavas laiks, laiks attiecībā pret testa sākumu, iestatāmo parametru vērtības un piezīmes ar komentāriem par notikumiem.
TM arhīvs Telemetrijas arhīvs ir fails, kas kodētā veidā satur telemetrijas ziņojumu kopu, kas saņemta no sistēmas testēšanas laikā. Arhīvā ir ietverts notikumu laiks un telemetrisko parametru vērtības. Programma Telemet2 ļauj prezentēt telemetrijas arhīvu teksta faila veidā ar komentāriem un parametru vērtībām decimālā un heksadecimālā formātā.
Pieņemšanas kritēriji Katra testa PMI jāietver prasības, kas nosaka pieņemšanas kritēriju. Pārbaužu apjoms un dziļums tiek uzskatīts par pietiekamu, ja tiek ievērotas šādas pārbaudes pilnības prasības: BKU programmatūrai jādarbojas visās iespējamās lidojumu konfigurācijās; visas funkcionālās alternatīvas ir pārbaudītas saskaņā ar ārējo specifikāciju; ir izstrādātas pamata avārijas situācijas; Robežvērtības pārbaudītas. Katra testa PMI sadaļā “Novērtēšanas kritēriji” ir jāsatur informācija, kas ļauj noteikt atbilstību starp faktiskajiem testa rezultātiem un plānotajiem testa rezultātiem, kā arī katra kontrolētā parametra pielaides.
Verifikācija un apstiprināšana ( verifikācija un apstiprināšana-V& V) ir paredzēti analīzei, pareizas izpildes un programmatūras atbilstības specifikācijām un klientu prasībām pārbaudei. Šīs programmas un sistēmu pareizības pārbaudes metodes attiecīgi nozīmē:
- verifikācija ir pārbaude, vai sistēma ir pareizi uzbūvēta atbilstoši tās specifikācijai;
- Validācija ir noteikto sistēmas prasību pareizas izpildes pārbaude.
Pārbaude palīdz izdarīt secinājumu par izveidotās sistēmas pareizību pēc tās projektēšanas un izstrādes pabeigšanas. Validācija ļauj noteikt noteikto prasību iespējamību un ietver vairākas darbības, lai iegūtu pareizas programmas un sistēmas, proti:
- plānošanas procedūras projektēšanas lēmumu un prasību pārbaudei un uzraudzībai;
- programmu izstrādes automatizācijas līmeņa nodrošināšana ar CASE rīkiem;
- programmu pareizas darbības pārbaude, izmantojot testēšanas metodes mērķa testu komplektos;
- produkta pielāgošana darbības videi u.c.
Validācija veic šīs darbības, pārskatot un pārbaudot dzīves cikla fāžu specifikācijas un projektēšanas rezultātus, lai apstiprinātu, ka sākotnējās prasības ir pareizi īstenotas un ka ir ievēroti noteiktie nosacījumi un ierobežojumi. Pārbaudes un validācijas uzdevumi ietver prasību specifikācijas pilnīguma, konsekvences un nepārprotamības un sistēmas funkciju pareizas izpildes pārbaudi.
Pārbaude un apstiprināšana ir pakļauta:
- galvenās sistēmas sastāvdaļas;
- komponentu (programmatūras, tehniskā un informācijas) saskarnes un objektu (protokolu un ziņojumu) mijiedarbības, kas nodrošina sistēmas darbību izkliedētās vidēs;
- līdzekļi, lai piekļūtu datubāzei un failiem (transakcijām un ziņojumiem) un pārbaudītu aizsardzības līdzekļus pret nesankcionētu piekļuvi dažādu lietotāju datiem;
- programmatūras un sistēmas dokumentācija kopumā;
- testus, testēšanas procedūras un ievades datus.
Citiem vārdiem sakot, galvenās programmas pareizības sistemātiskās metodes ir:
- pārbaude programmatūras komponentu un prasību specifikāciju validācija;
- PS pārbaude noteikt programmas atbilstību dotajām specifikācijām;
- testēšana programmatūras izejas kods uz testa datiem konkrētā darbības vidē, lai identificētu kļūdas un defektus, ko izraisījuši dažādi defekti, anomālas situācijas, iekārtu atteices vai sistēmas avārijas izslēgšana (sk. 9. nodaļu).
ISO/IEC 3918-99 un 12207 standarti ietver verifikācijas un validācijas procesus. Viņiem tiek noteikti mērķi, uzdevumi un darbības, lai pārbaudītu radītā produkta (tostarp darba un starpproduktu) pareizību dzīves cikla posmos un atbilstību tā prasībām.
Verifikācijas un apstiprināšanas procesu galvenais mērķis ir pārbaudiet un apstipriniet vai galīgā programmatūra ir piemērota mērķim un klienta prasībām. Šie procesi ļauj identificēt kļūdas dzīves cikla posmu darba produktos, nenoskaidrojot to rašanās iemeslus, kā arī noteikt programmatūras pareizību attiecībā pret tās specifikāciju.
Šie procesi ir savstarpēji saistīti un tiek definēti ar vienu terminu – “verifikācija un validācija” (V&V 7).
Pārbaudes laikā tiek veiktas šādas darbības:
- atsevišķu komponentu tulkojuma pareizības pārbaude izvades kodā, kā arī saskarnes apraksti, izsekojot komponentu savstarpējos savienojumus atbilstoši noteiktajām klienta prasībām;
- pieejas failiem vai datubāzēm pareizības analīze, ņemot vērā izmantotajos sistēmas rīkos pieņemtās datu manipulācijas un rezultātu pārsūtīšanas procedūras;
- pārbaudīt komponentu aizsardzības aprīkojumu, lai tie atbilstu klientu prasībām, un veiktu to izsekošanu.
Pēc atsevišķu sistēmas komponentu pārbaudes tiek veikta to integrācija, kā arī integrētās sistēmas verifikācija un validācija. Sistēma tiek pārbaudīta pret dažādiem testu komplektiem, lai noteiktu šo komplektu atbilstību un pietiekamību, lai pabeigtu testēšanu un noteiktu sistēmas pareizību.
Ideju izveidot starptautisku projektu par formālu verifikāciju ierosināja T. Hoārs, tā tika apspriesta simpozijā par verificētu programmatūru 2005. gada februārī Kalifornijā. Pēc tam tā paša gada oktobrī IFIP konferencē Cīrihē tika pieņemts starptautisks projekts 15 gadu periodam, lai izstrādātu "visaptverošu automatizētu rīku komplektu programmatūras pareizības pārbaudei".
Tajā formulēti šādi galvenie uzdevumi:
- vienotas programmas veidošanas un analīzes teorijas izstrāde;
- izveidojot visaptverošu, integrētu verifikācijas rīku komplektu visiem ražošanas posmiem, tostarp specifikāciju izstrādi un verifikāciju, testa gadījumu ģenerēšanu, programmu pilnveidošanu, analīzi un verifikāciju;
- dažādu veidu un veidu formālo specifikāciju un pārbaudītu programmatūras objektu repozitorija izveide.
Šis projekts paredz, ka verifikācija aptvers visus programmatūras izveides un pareizības pārbaudes aspektus un kļūs par panaceju visām kaitēm, kas saistītas ar pastāvīgu kļūdu rašanos izveidotajās programmās.
Daudzas formālas noteiktu programmu pierādīšanas un pārbaudes metodes ir pārbaudītas praktiski. Starptautiskā komiteja ISO/IEC ir paveikusi lielu darbu ISO/IEC 12207:2002 standarta ietvaros, lai standartizētu programmatūras verifikācijas un validācijas procesus. Daudzsološa ir dažādu programmēšanas objektu pareizības pārbaude, izmantojot formālas metodes.
Repozitorijs ir programmu, specifikāciju un rīku krātuve, ko izmanto izstrādē un testēšanā, gatavo komponentu, rīku un metožu sagatavošanas novērtēšanā. Viņam ir uzticēti šādi vispārīgi uzdevumi:
- pārbaudītu specifikāciju, pārbaudes metožu, programmatūras objektu un koda implementāciju uzkrāšana sarežģītām lietojumprogrammām;
- dažādu verifikācijas metožu uzkrāšana, to noformēšana realizētas teorētiskās idejas meklēšanai un atlasei piemērotā formā tālākai pielietošanai;
- standarta veidlapu izstrāde dažādu programmēšanas objektu formālo specifikāciju, kā arī rīku un gatavu sistēmu precizēšanai un apmaiņai;
- sadarbspējas un mijiedarbības mehānismu izstrāde gatavo verificēto produktu pārsūtīšanai no repozitorija uz jaunu izplatītu un tīkla vidi, lai izveidotu jaunu programmatūru.
Šo projektu paredzēts attīstīt 50 gadu laikā. Iepriekšējie projekti izvirzīja līdzīgus mērķus: uzlabot programmatūras kvalitāti, formalizēt pakalpojumu modeļus, samazināt sarežģītību, izmantojot PIC, izveidot atkļūdošanas rīkus vizuālai kļūdu diagnostikai un to novēršanai utt. Taču arī programmēšanā nebija būtisku izmaiņu vizuālās atkļūdošanas ziņā. vai augstas programmatūras kvalitātes sasniegšana. Attīstības process turpinās.
Jauns starptautisks programmatūras verifikācijas projekts no tā dalībniekiem prasa ne tikai zināšanas par programmu specifikāciju teorētiskajiem aspektiem, bet arī augsti kvalificētus programmētājus tā ieviešanai turpmākajos gados.
Termini verifikācija un validācija ir saistīti ar programmatūras kvalitātes pārbaudi. Mēs izmantojam šos terminus savos rakstos un pārskatos. Esam vairākkārt dzirdējuši dažādus komentārus un argumentus par to, vai programmas pirmkoda statiskā analīze ir klasificējama kā pārbaude un validācija un kāda ir atšķirība starp šiem jēdzieniem. Kopumā rodas iespaids, ka katrs šajos terminos ieliek savus jēdzienus, un tas noved pie savstarpējas nesaprašanās.
Mēs nolēmām izprast terminoloģiju, lai ievērotu šo jēdzienu vispareizāko interpretāciju. Pētījuma laikā mēs atradām darbu V.V. Kuljamins "Programmatūras verifikācijas metodes". Tajā sniegts detalizēts šo terminu apraksts, un mēs nolēmām turpmāk paļauties uz šajā darbā sniegtajām definīcijām. Šeit ir daži izvilkumi no šī darba, kas saistīti ar verifikāciju un validāciju.
Verifikācija un apstiprināšana ir darbības, kuru mērķis ir uzraudzīt programmatūras kvalitāti un atklāt tajā esošās kļūdas. Viņiem ir kopīgs mērķis, tie atšķiras ar to īpašību avotiem, noteikumiem un ierobežojumiem, kas pārbaudīti to gaitā, kuru pārkāpšana tiek uzskatīta par kļūdu.
Tālākai apskatei mums jāievieš termins “programmatūras dzīves cikla artefakts”. Programmatūras dzīves cikla artefakti ir dažādas informācijas vienības, dokumenti un modeļi, kas izveidoti vai izmantoti programmatūras izstrādes un uzturēšanas laikā. Tādējādi artefakti ir tehniskā specifikācija, arhitektūras apraksts, priekšmeta jomas modelis kādā grafiskā valodā, pirmkods, lietotāja dokumentācija utt. Par artefaktiem nevar uzskatīt dažādus modeļus, ko izmanto atsevišķi izstrādātāji, veidojot un analizējot programmatūru, bet kas nav reģistrēti citiem cilvēkiem pieejamu dokumentu veidā.
Verifikācija pārbauda dažu programmatūras izstrādes un uzturēšanas laikā izveidoto artefaktu atbilstību citiem, kas iepriekš izveidoti vai izmantoti kā ievades dati, kā arī šo artefaktu un to izstrādes procesu atbilstību noteikumiem un standartiem. Jo īpaši verifikācija pārbauda atbilstību standartiem, prasību aprakstiem (tehniskajām specifikācijām) programmatūrai, dizaina risinājumiem, pirmkodu, lietotāja dokumentāciju un pašas programmatūras darbību. Papildus tiek pārbaudīts, vai prasības, dizaina risinājumi, dokumentācija un kods, izstrādājot programmatūru, ir noformēti atbilstoši attiecīgajā valstī, nozarē un organizācijā pieņemtajām normām un standartiem, kā arī, vai to izveides laikā tiek veiktas visas darbības, kas noteiktas standarti tika veikti vajadzīgajā secībā. Pārbaudes laikā atklātās kļūdas un defekti ir neatbilstības vai pretrunas starp vairākiem no uzskaitītajiem dokumentiem, starp dokumentiem un programmas faktisko darbību, starp standartiem un faktiskajiem programmatūras izstrādes un uzturēšanas procesiem. Tajā pašā laikā izlemt, kurš dokuments ir labojams (varbūt abiem), ir atsevišķs uzdevums.
Validācija pārbauda programmatūras izstrādes un uzturēšanas laikā izveidoto vai izmantoto artefaktu atbilstību šīs programmatūras lietotāju un klientu vajadzībām un prasībām, ņemot vērā tēmas jomas likumus un programmatūras lietošanas konteksta ierobežojumus. . Šīs vajadzības un prasības visbiežāk netiek dokumentētas – ierakstot tās pārvēršas par prasību aprakstu, kas ir viens no programmatūras izstrādes procesa artefaktiem. Tāpēc validācija ir mazāk formalizēta darbība nekā verifikācija. Tas vienmēr tiek veikts, piedaloties klientu pārstāvjiem, lietotājiem, biznesa analītiķiem vai priekšmetu ekspertiem – tiem, kuru viedokli var uzskatīt par pietiekami labu lietotāju, klientu un citu interesentu reālo vajadzību un prasību izpausmi. Tās īstenošanas metodēs bieži tiek izmantotas īpašas metodes, lai noteiktu dalībnieku zināšanas un faktiskās vajadzības.
Atšķirība starp verifikāciju un validāciju ir parādīta 1. attēlā.
Dotās definīcijas ir iegūtas, nedaudz paplašinot definīcijas no IEEE 1012 standarta verifikācijas un validācijas procesiem. 1990. gada IEEE 610.12 standarta programmatūras inženierijas terminu vārdnīcā verifikācijas definīcija ir aptuveni vienāda, taču validācijas definīcija ir nedaudz atšķirīga - tajā teikts, ka validācijai jāpārbauda izstrādes rezultātā iegūtās programmatūras atbilstība oriģinālam. prasības tai. Šajā gadījumā validācija būtu īpašs verifikācijas gadījums, kas programmatūras inženierijas literatūrā nekur nav minēts, tāpēc, kā arī tāpēc, ka tā tika labota 2004. gada IEEE 1012, šī definīcija ir uzskatāma par neprecīzu. Bieža B. Bēma frāzes lietošana:
Verifikācija atbild uz jautājumu "Vai mēs ražojam produktu pareizi?", un validācija atbild uz jautājumu "Vai mēs izgatavojam pareizo produktu?"
arī rada neskaidrības, jo šī apgalvojuma aforisms diemžēl ir apvienots ar neskaidrību. Tomēr daudzi tā autora darbi liecina, ka ar pārbaudi un apstiprināšanu viņš domāja aptuveni tos pašus jēdzienus, kas definēti iepriekš. Šīs neatbilstības var izsekot arī programmatūras inženierijas standartu saturā. Tādējādi ISO 12207 standartā testēšana tiek uzskatīta par validācijas veidu, bet ne par verifikāciju, kas acīmredzot izriet no neprecīzas definīcijas no standarta vārdnīcas izmantošanas.
Nobeigumā vēlos atzīmēt, ka saskaņā ar iepriekš minētajām definīcijām programmas pirmkoda statiskā analīze atbilst programmatūras pārbaudei, piemēram, programmas koda atbilstības pārbaudei dažādiem kodēšanas standartiem. Statiskā analīze pārbauda programmatūras sistēmas projektēšanas posma rezultātu atbilstību iepriekš formulētajām prasībām un ierobežojumiem.
Bibliogrāfija
- V.V. Kuljamins "Programmatūras verifikācijas metodes". Sistēmu programmēšanas institūts RAS 109004, Maskava, st. B. Kommunisticheskaya, nr.25.
http://www.ict.edu.ru/ft/005645/62322e1-st09.pdf - IEEE 1012-2004 programmatūras verifikācijas un validācijas standarts. IEEE, 2005.
- IEEE 610.12-1990 Programmatūras inženierijas terminoloģijas standarta glosārijs, labotais izdevums. IEEE, 1991. gada februāris.
- B. V. Bēms. Programmatūras inženierijas; Pētniecības un attīstības tendences un aizsardzības vajadzības. In R. Wegner, ed. Pētījumi. Norādījumi programmatūras tehnoloģijās. Kembridža, MA: MIT Press, 1979.
- ISO/IEC 12207 Sistēmas un programmatūras inženierija — programmatūras dzīves cikla procesi. Ženēva, Šveice: ISO, 2008.
Termini “verifikācija” un “validācija” ļoti bieži tiek lietoti tehniskajā literatūrā un ir saistīti ar jebkuras programmatūras kvalitātes analīzi. Zinātniskajā literatūrā var atrast dažādas šo jēdzienu interpretācijas. Tātad, mēģināsim izprast šo jautājumu.
Pareizākā, no mūsu viedokļa, ir šāda definīcija. Validācija un verifikācija ir darbības, kuru mērķis ir veikt kvalitātes kontroli, lai agrīnā stadijā atklātu tajā kļūdas. Šķiet, ka viņiem ir kopīgs mērķis. Bet tomēr šiem veidiem ir atšķirības pārbaudīto īpašību, ierobežojumu un noteikumu avotos, kuru neievērošanu var uzskatīt par kļūdu.
Verifikācija ir programmatūras atbilstības pārbaude uzrādītajām tehniskajām specifikācijām, arhitektūra vai Šī termina “pienākumi” ietver arī aprēķinu procedūras salīdzināšanu ar to izstrādes procesu, noteikumiem un standartiem.
Datu pārbaudi var veikt, lai konstatētu programmas darbības atbilstību noteiktajiem standartiem, prasībām, dizaina risinājumiem un lietotāja dokumentācijai. Šajā gadījumā tiem dokumentiem, ar kuriem tiek veikta salīdzināšana, lai nodrošinātu atbilstību to standartiem un noteikumiem, kas noteikti valstī, kurā programmatūra tiek izmantota, tiek veikta obligāta iepriekšēja pārbaude. Jāņem vērā atbilstība visām veikto darbību secībām.
Ja programmas darbībā tiek konstatēta kļūda vai defekts, vai tiek konstatēta pretruna starp augstāk minētajiem dokumentiem un programmas pašreizējo darbību, lēmuma pieņemšanai par dokumenta izvēli labošanai jābūt atsevišķas problēmas risinājumam.
Atšķirībā no pārbaudes, validācija ir atbildīga par izstrādāto vai uzturēto programmatūras produktu atbilstības pārbaudi klientu vai lietotāju vajadzībām vai vajadzībām. Šīs vajadzības bieži vien nav ierakstītas nevienā dokumentācijā. Tāpēc validācija ir mazāk formalizēta nekā verifikācija. Šis ir process, kurā klienta, lietotāja pārstāvis, kā arī var piedalīties analītiķis vai eksperts Citiem vārdiem sakot, tie, kas var izteikt ieinteresēto pušu īpašās vajadzības un patiesās vajadzības.
Verifikācija ir atbilde uz jautājumu "Vai programmatūra ir izveidota pareizi?" un validācija ir atbilde uz "Vai programmatūra ir pareizi izveidota?"
Meklējot atbildi uz uzdotajiem jautājumiem, var konstatēt, ka satura validācijai (vai sertifikācijai) ir plašāka nozīme nekā pārbaudei (pārbaudei). Tomēr pārbaude ir diezgan cieši saistīta ar programmatūras produkta kvalitātes kontroles nodrošināšanu.
Piemēram, datorprogrammu verifikācija ietver procesu, kura mērķis ir nodrošināt, lai noteiktā produkta dzīves ciklā iegūtās datu prasības atbilstu iepriekšējā posmā iegūtajām prasībām.
Ja mēs runājam par modeļa verifikāciju, tad šeit mēs runāsim par dotā skaitļošanas modeļa kartēšanas pareizības pārbaudi uz nepieciešamo konceptuālo vai
Pārbaudot sistēmas kodu, tiek analizēts avota kodējums un pārbaudīts, vai tas atbilst tā dokumentārajam aprakstam.
Pārbaudes process var ietvert darījumus, kas ietver alternatīvus aprēķinus. Jaunā projekta tehniskā un zinātniskā dokumentācija tiek salīdzināta ar esošā projekta atbilstošo dokumentāciju, tiek veikta obligātā testēšana, jaunā programmatūras produkta aprobācija un rezultātu demonstrēšana.