Disaini kontrollimise ja kinnitamise protsess

Disaini kontrollimine

Disaini kontrollimine on meetod, mille abil kontrollimise ja tõendite esitamise teel kinnitada, et kavandatud tarkvaratoote väljund vastab sisendspetsifikatsioonidele. Tarkvaraarenduse käigus toimuva disaini verifitseerimise protsessi eesmärk on tagada, et kavandatud tarkvaratoode vastab spetsifikatsioonile.

Projekteerimise sisend on iga füüsiline ja jõudlusnõue, mida kasutatakse projekteerimise alusena. Projekteerimise väljund on iga projekteerimisetapi ja kogu projekteerimispingutuse tulemus. Reguleeritud tööstusharudes, näiteks meditsiiniseadmete puhul, saab lõplikust projekteerimise väljundist seadme põhidokumendi alus, mistõttu projekteerimisjuhtimise terminoloogia esineb verifitseerimisdokumentatsioonis nii sageli.

Praktikas võrreldakse kontrollimisel kahte dokumentide komplekti: esitatud spetsifikatsioone, standardeid ja piiranguid väljastatud jooniste, koodi ja katsejuhistega. Iga nendevaheline lahknevus on kontrollimisel leitud tulemus.

Disaini kinnitamine

Verifitseerimine tõestab sisemist järjepidevust. Valideerimine esitab keerulisema küsimuse, kas spetsifikatsioon kirjeldas üldse õiget toodet.

Disaini kinnitamine on tarkvaratoote hindamise protsess lõppkasutajate või sidusrühmade täpsete nõuete alusel. Disaini valideerimise eesmärk on testida tarkvaratoodet pärast arendamist, et kinnitada selle vastavust nõuetele, kui seda kasutatakse kasutaja enda keskkonnas.

Valideerimine tegeleb disaini järjepidevuse ja täielikkuse demonstreerimisega vastavalt kasutaja vajadustele. See on etapp, kus te tegelikult toote versiooni loote ja valideerite selle vastavust kasutaja nõuetele.

Allolev ribareklaam tähistab tegevuse kahte poolt nii, nagu neid tavaliselt kujundusdokumentides esitatakse.

Järgnev diagramm näitab disaini valideerimisprotsessi ennast, alates kasutaja vajadustest kuni valideeritud tooteni.

Eesmärk on objektiivsete tõenditega tõestada, et toode vastab dokumenteeritud kasutaja vajadustele. Objektiivne tõend on lihtsalt väljundi füüsiline tõend – pilt, tekstifail, helifail või allkirjastatud aruanne –, mis näitab, et protseduur tegelikult läbi viidi.

Selle objektiivse tõendusmaterjali abil kontrollitakse protsessi käigus järjepidevalt, kas toode vastab eelnevalt määratletud nõuetele. See hõlmab testimist, kontrolli, analüüsi ja sarnaseid tehnikaid, mistõttu valideerimine tavaliselt tugineb... süsteemi testimine ja kasutaja aktsepteerimise testimine mitte üksuse tasemel kontrollide põhjal.

Disaini kontrollimise ja kinnitamise erinevus

Verifitseerimise ja valideerimise vahel esineb alati väärarusaamu. Need on erinevad tegevused ja mõlemat tehakse arendusprotsessi igas etapis, mitte üksiku verstaposti saavutamisel.

Kasulik otsetee: kontrollimine on enamasti staatiline töö dokumentide vastu, samas kui valideerimine on enamasti dünaamiline testimine töötava ehituse vastu.

Disaini kontrollimise protsess

Kontrollimisprotsess koosneb viiest etapist ja igaüks neist loob artefakti, millest järgmine etapp sõltub.

Identifitseerimine ja ettevalmistamine:

• Spetsifikatsiooni väljatöötamise ajal määratakse paralleelselt kindlaks ka verifitseerimistegevused. See võimaldab disaineril veenduda spetsifikatsiooni tegelikus verifitseeritavuses, et testimisinsener saaks alustada üksikasjalike testimisplaanide ja -protseduuride väljatöötamist. Kõik spetsifikatsiooni muudatused tuleb edastada.
• Tehke kindlaks parim lähenemisviis kontrollimise läbiviimiseks ning määratlege mõõtmismeetodid, vajalikud ressursid, tööriistad ja vahendid.
• Enne plaani lõplikku vormistamist vaadatakse valminud kontrolliplaan koos projekteerimismeeskonnaga üle, et esile tõsta probleeme.

Planeerimine:

• Verifitseerimise planeerimine on põhimeeskonna ja arendusmeeskonna samaaegne tegevus. See toimub kogu projekti elutsükli vältel ja seda ajakohastatakse iga kord, kui projekteerimisandmed muutuvad.
• Selle etapi käigus dokumenteeritakse testitav tarkvara või süsteem ulatuse järgi.
• Kirjutatakse esialgne testimisplaan ja seejärel täpsustatakse seda. Plaan hõlmab kriitilisi verstaposte, mis vähendavad projekti riski.
• Valitakse tööriistad, testimiskeskkond ja arendusstrateegia ning määratakse kindlaks nõuded, mida kontrolli või analüüsi abil kinnitada.

Developing:

• Katsejuhtum areng langeb kokku SDLC metoodika projektimeeskond on rakendanud. Selles etapis tuvastatakse mitmesuguseid testimismeetodeid.
• Projekteerimise sisendandmed tuleb välja töötada nii, et isegi kõige lihtsamad kontrollimistegevused oleksid üheselt mõistetavad ja kontrollitavad.
• Sarnaste kontseptsioonide järjestikuse kontrollimise korral lüheneb kontrollimisaeg, sest ühe testi väljundit saab järgmise testi sisendina uuesti kasutada.
• TracTestijuhtumite ja nende vastavate disaini sisendite vahel luuakse teostatavuslingid, et tagada iga nõude testimine ja disaini väljundi vastavus disaini sisenditele.

Täitmine:

• Arendusfaasis loodud testimisprotseduurid viiakse ellu vastavalt testimisplaanile ja neid järgitakse rangelt verifitseerimistegevuse ajal.
• Kui ilmnevad kehtetud tulemused või kui mõnda protseduuri on vaja muuta, tuleb muudatused dokumenteerida ja ametlikult heaks kiita.
• Kõik leitud probleemid registreeritakse defektina tavapärasel viisil. defektide haldamise protsess.
• A tracvõimekusmaatriks on loodud selleks, et kontrollida, kas kõiki kontrolltesti plaanis tuvastatud disaini sisendandmeid on testitud, ja määrata kindlaks läbimise suhtarv.

Aruanded:

• See toiming viiakse läbi iga kontrollimise etapi lõpus.
• Projekteerimise kontrollimise aruanne annab üksikasjaliku kokkuvõtte kontrollimise tulemustest, sealhulgas konfiguratsioonihaldusest, iga testitüübi tulemustest ja kontrollimise käigus leitud probleemidest.
• Projekteerimise kontrollimine tracNõuete ja vastavate testitulemuste vahel luuakse toimivusaruanne, et kinnitada kõigi nõuete testimist ja asjakohaste tulemuste registreerimist.
• Kõik mittevastavused dokumenteeritakse ja nendega tegeletakse asjakohaselt.
• RevPärast projekti kontrollimise lõpetamist viiakse läbi kontrollid ja tulemused kiidetakse ametlikult heaks.

Disaini valideerimise protsess

Valideerimisel ei ole võrdselt jäika järjestust. Selle asemel tugineb see väikesele hulgale aktsepteeritud meetoditele ja projekt kasutab tavaliselt rohkem kui ühte neist.

• Võrdlus samaväärsete disainidega. Mõne konstruktsiooni valideerimiseks saab võrrelda seda sarnaste seadmetega, millel on sarnane eesmärk. See on eriti oluline olemasoleva infrastruktuuri konfiguratsioonimuudatuste või uude süsteemi või rakendusse lisatavate standardkonstruktsioonide valideerimisel.
• Demonstratsioon ja ülevaatus. Toote nõuete ja muu funktsionaalsuse valideerimiseks võib kasutada kumbagi või mõlemat.
• Analysis. Disaini saab analüüsida matemaatilise modelleerimise või simulatsiooni abil, mis taasloob vajaliku funktsionaalsuse.
• Testimine. Lõpliku disainiga tehakse katseid, et kinnitada süsteemi võimet töötada ettenähtud viisil, st. funktsionaalne testimine ja mittefunktsionaalne testimine vastama kasutaja nõuetele.
• Dokumentatsioon. Testiplaan, teostus ja tulemused tuleks dokumenteerida ja säilitada osana projekteerimisdokumentidest. Valideerimine on lõppkokkuvõttes kõigi valideerimistegevuste tulemuste kogum.
• Samaväärsuse põhjendus. Kui lõplikul disainivalideerimisel kasutatakse samaväärseid tooteid, peab tootja dokumenteerima sarnasuse ja kõik erinevused esialgsest toodangust.

Näide

Lühike näide illustreerib seda eristust.

• Võtke näiteks lihtne toode: veekindel käekell.
• Toote nõuete dokument võib väita, et „kell peab ujumise ajal veekindel olema“. See on kasutaja vajadus ja selle alusel valideerimist mõõdetakse.
• Disainispetsifikatsioonis võidakse öelda, et „kell peaks toimima isegi siis, kui kasutaja pikka aega ujub“. See on disaini sisend ja selle alusel mõõdetakse ka kontrolli.
• Testi tulemused peaksid kinnitama, et kell vastab neile nõuetele. Kui need ei vasta, jätkub ümberkujundamine seni, kuni see vastab nõuetele.

Pane tähele, kuidas kell võib läbida kontrolli, aga ikkagi kontrollist läbi kukkuda. Kui spetsifikatsioon defineerib pika ujumise viieteistkümne minutina ja päris ujujad viibivad vees tund aega, siis disaini väljund vastab sisendile ideaalselt, kuid kasutajat ikkagi ei kontrollita.

Disaini valideerimise ja kontrollimise eelised

Mõlema tegevuse pidev läbiviimine, mitte lõpus väravana tegutsemine, annab allpool toodud eelised.

• Projekte saab pidevalt jälgida, mis võimaldab igal etapil täita kasutaja määratletud nõudeid.
• Kujunduse valideerimine toob välja erinevuse funktsionaalsuse toimimise ja selle eeldatava toimimise vahel.
• Valideerimisprotseduuride dokumenteerimine muudab funktsionaalsuse hiljem hõlpsasti mõistetavaks, kui tehakse muudatusi või täiustusi.
• Arendusaeg väheneb pidevalt ja tootlikkus paraneb, mis aitab toodet ootuspäraselt tarnida.
• Protsess määratleb iga kasutatava valideerimismeetodi ulatuse ja ulatuse.
• Valideerimist saab läbi viia detailsete projekteerimisandmete abil, mis esindavad lõppkasutaja nõudeid.
• Kõik erinevused tulemuse ja kasutaja vajaduste dokumentide vahel jäädvustatakse, mitte ei kao.
• Valideeritud kujunduse muudatused käivitavad uuesti valideerimise, seega ei kao dokument kunagi tootest eemale.
• Iga valideerimise käigus toimuva tegevuse dokumenteerimine on see, mis piisavalt tõestab, et disain vastab kasutaja nõuetele.

Seetõttu on disaini kontrollimine ja valideerimine kõige parem planeerida laiemas kontekstis. tarkvara testimise elutsükkel ja kaardistatud teise vastu tarkvara testimise tüübid, selle asemel, et käsitleda seda eraldi vastavuskontrollina.

KKK