Suunnittelun tarkastus- ja validointiprosessi

โšก ร„lykรคs yhteenveto

Suunnittelun varmennus varmistaa, ettรค suunnittelun tulos vastaa dokumentoitua suunnittelutietoa, kun taas suunnittelun validointi varmistaa, ettรค lopputuote tรคyttรครค kรคyttรคjiensรค todelliset tarpeet. Molemmat suoritetaan koko kehitysvaiheen ajan, ei kertaakaan lopussa.

  • ๐Ÿ”˜ Kaksi eri kysymystรค: Verifioinnissa kysytรครคn, onko tuote suunniteltu oikein, ja validoinnissa kysytรครคn, onko oikea tuote ylipรครคtรครคn suunniteltu.
  • โ˜‘๏ธ Tulot ja lรคhdรถt: Suunnittelun lรคhtรถtiedot ovat joukko fyysisiรค ja suorituskykyvaatimuksia; suunnittelun tuotos on se, mitรค kukin suunnitteluvaihe tuottaa ja mitรค verifioinnissa tarkastellaan.
  • โœ… Objektiivinen nรคyttรถ: Validointi on valmis vasta, kun on olemassa fyysinen nรคyttรถ siitรค, ettรค tuote tรคyttรครค dokumentoidut kรคyttรคjรคtarpeet.
  • ๐Ÿงช Viisivaiheinen todentaminen: Tunnistaminen ja valmistelu, suunnittelu, kehittรคminenping, toteutus ja raportointi muodostavat vakiomuotoisen todennussekvenssin.
  • ๐Ÿ› ๏ธ Trackรคytettรคvyys kaikkialla: Suunnittelun lรคhtรถtietojen, testitapausten ja tulosten vรคliset yhteydet todistavat, ettรค jokainen vaatimus todella katettiin.
  • ๐Ÿ“ˆ Jรคrjestyksellรค on merkitystรค: Validointi seuraa onnistunutta todentamista, eikรค todentaminen ole koskaan hyvรคksyttรคvรค korvike sille.

Suunnittelun todentamis- ja validointiprosessi ohjelmistokehityksessรค

Suunnittelun todentaminen

Suunnittelun todentaminen on menetelmรค, jolla varmistetaan tutkimalla ja esittรคmรคllรค todisteita siitรค, ettรค suunnitellun ohjelmistotuotteen tuotos tรคyttรครค sen lรคhtรถtiedot. Suunnittelun varmennusprosessin tavoitteena ohjelmistokehityksen aikana on varmistaa, ettรค suunniteltu ohjelmistotuote on sama kuin mรครคriteltiin.

Suunnittelun lรคhtรถtiedot ovat kaikki fyysiset ja suorituskykyvaatimukset, joita kรคytetรครคn suunnittelun perustana. Suunnittelun tuotos on kunkin suunnitteluvaiheen ja koko suunnittelutyรถn tulos. Sรครคnnellyillรค toimialoilla, kuten lรครคkinnรคllisten laitteiden valmistuksessa, lopullisesta suunnittelutuloksesta tulee laitteen pรครคtietueen perusta, minkรค vuoksi suunnittelun ohjaussanastoa esiintyy niin usein varmennusdokumentaatiossa.

Kรคytรคnnรถssรค todentamisessa vertaillaan kahta asiakirjasarjaa: sisรครคn tulleita spesifikaatioita, standardeja ja rajoituksia laadittuihin piirustuksiin, koodiin ja testausohjeisiin. Jokainen niiden vรคlinen ero on todentamisessa havainto.

Suunnittelun validointi

Verifiointi osoittaa sisรคisen johdonmukaisuuden. Validointi kysyy vaikeampaa kysymystรค siitรค, kuvailiko spesifikaatio alun perin oikeaa tuotetta.

Suunnittelun validointi on prosessi, jossa ohjelmistotuotetta arvioidaan loppukรคyttรคjien tai sidosryhmien tarkkojen vaatimusten perusteella. Suunnittelun validoinnin tarkoituksena on testata ohjelmistotuotetta kehityksen jรคlkeen sen varmistamiseksi, ettรค se tรคyttรครค kyseiset vaatimukset, kun sitรค kรคytetรครคn kรคyttรคjรคn omassa ympรคristรถssรค.

Validoinnilla pyritรครคn osoittamaan suunnittelun johdonmukaisuus ja tรคydellisyys kรคyttรคjien tarpeiden suhteen. Tรคssรค vaiheessa tuotteesta rakennetaan versio ja validoidaan se kรคyttรคjรคn vaatimuksia vasten.

Alla oleva banneri nimeรครค toiminnan kaksi puoliskoa sellaisina kuin ne yleensรค esitetรครคn suunnittelutiedoissa.

Suunnittelun validointi -otsikkobanneri, jota kรคytetรครคn suunnittelun ohjaustietueissa

Seuraava kaavio nรคyttรครค itse suunnittelun validointiprosessin kรคyttรคjรคn tarpeista validoituun tuotteeseen asti.

Suunnittelun validointiprosessi kรคyttรคjรคn tarpeista validoituun tuotteeseen

Tarkoituksena on osoittaa objektiivisella nรคytรถllรค, ettรค tuote tรคyttรครค dokumentoidut kรคyttรคjรคtarpeet. Objektiivinen nรคytรถllรค tarkoitetaan yksinkertaisesti fyysistรค todistusaineistoa โ€“ kuvaa, tekstitiedostoa, รครคnitiedostoa tai allekirjoitettua raporttia โ€“ joka osoittaa, ettรค toimenpide on todella suoritettu.

Tรคmรคn objektiivisen nรคytรถn avulla prosessissa tarkastellaan johdonmukaisesti, tรคyttรครคkรถ tuote ennalta mรครคritellyt vaatimukset. Se sisรคltรครค testausta, tarkastusta, analyysia ja vastaavia tekniikoita, minkรค vuoksi validointi yleensรค hyรถdyntรครค jรคrjestelmรคn testaus ja kรคyttรคjรคn hyvรคksyntรคtestaus eikรค yksikkรถkohtaisiin tarkastuksiin.

Ero suunnittelun todentamisen ja validoinnin vรคlillรค

Todentamisen ja validoinnin vรคlillรค on aina vรครคrinkรคsityksiรค. Ne ovat eri toimintoja, ja molempia suoritetaan kehitysprosessin jokaisessa vaiheessa yksittรคisen virstanpylvรครคn sijaan.

Suunnittelun todentaminen Suunnittelun validointi
Suunnittelun varmennusta kรคytetรครคn silloin, kun todellisen suunnittelutuloksen tulee olla sama kuin odotettu suunnittelutulos ja tรคyttรครค tuotteen vaatimukset. Suunnittelun validointia kรคytetรครคn varmistamaan, ettรค lopullinen suunnittelu vastaa kรคyttรคjรคn odotuksia.
Suunnittelun varmentamisessa kysytรครคn: suunnittelitko tuotteen oikein? Suunnittelun validointi kysyy: suunnittelitko oikean tuotteen?
Suunnittelun varmennus sisรคltรครค yksikรถn ja ensisijaisen integrointitason testaus. Suunnittelun validointi sisรคltรครค toissijaisen tai ylemmรคn tason integroinnin ja jรคrjestelmรคtason testauksen.
Tietyt suunnittelun validoinnin osa-alueet voidaan suorittaa suunnittelun verifioinnin aikana, mutta suunnittelun verifiointi ei korvaa suunnittelun validointia. Suunnittelun validointi seuraa onnistuneen suunnittelun todentamista.
Suunnittelun verifiointi voidaan suorittaa yksittรคiselle moduulille tai valmiille jรคrjestelmรคlle missรค tahansa olosuhteissa. Suunnittelun validointi on suoritettava tietyissรค olosuhteissa kรคyttรคjรคn vaatimusten mukaisesti.
Suunnittelun todentamisessa voidaan kรคyttรครค staattisia tekniikoita. Se sisรคltรครค jรคrjestelmรคtarkastuksia, analyysiรค ja muodollisia todentamistoimia. Suunnittelun validointi koostuu testitulosten loppuraportista, joka tarkistetaan, hyvรคksytรครคn ja allekirjoitetaan. Nรคmรค asiakirjat tallennetaan myรถhempรครค tarvetta varten.

Hyรถdyllinen oikotie: vahvistus on enimmรคkseen staattinen tyรถ asiakirjoja vastaan, kun taas validointi on enimmรคkseen dynaaminen testaus kรคynnissรค olevaa rakennetta vastaan.

Suunnittelun varmennusprosessi

Vahvistusprosessi tapahtuu viidessรค vaiheessa, ja jokainen niistรค tuottaa artefaktin, josta seuraava vaihe on riippuvainen.

Tunnistaminen ja valmistelu:

  • Spesifikaation kehittรคmisen aikana rinnakkain tunnistetaan myรถs todentamistoimet. Nรคin suunnittelija voi varmistaa, ettรค spesifikaatio on todella todennettavissa, jotta testausinsinรถรถri voi aloittaa yksityiskohtaisten testaussuunnitelmien ja -menettelyjen laatimisen. Kaikista spesifikaation muutoksista on tiedotettava.
  • Mรครคritรค paras lรคhestymistapa todentamisen suorittamiseen ja mรครคrittele mittausmenetelmรคt, tarvittavat resurssit, tyรถkalut ja tilat.
  • Valmis varmennussuunnitelma tarkistetaan suunnittelutiimin kanssa mahdollisten ongelmien nostamiseksi esiin ennen suunnitelman viimeistelyรค.

Suunnittelu:

  • Todentamisen suunnittelu on samanaikaista ydin- ja kehitystiimien kanssa. Sitรค tapahtuu koko projektin elinkaaren ajan ja sitรค pรคivitetรครคn aina, kun suunnittelun lรคhtรถtiedot muuttuvat.
  • Tรคssรค vaiheessa testattavan ohjelmiston tai jรคrjestelmรคn laajuus dokumentoidaan.
  • Alustava testaussuunnitelma kirjoitetaan ja sitรค sitten tarkennetaan. Suunnitelma tallentaa kriittiset virstanpylvรครคt, jotka vรคhentรคvรคt projektin riskiรค.
  • Tyรถkalut, testiympรคristรถ ja kehitysstrategia valitaan ja tarkastuksen tai analyysin avulla vahvistettavat vaatimukset tunnistetaan.

Developing:

  • Testitapaus kehitys on yhdenmukainen SDLC-metodologia projektitiimi on toteuttanut. Tรคssรค vaiheessa tunnistetaan useita testausmenetelmiรค.
  • Suunnittelun lรคhtรถtiedot on kehitettรคvรค siten, ettรค yksinkertaisimmatkin todentamistoimet ovat yksiselitteisiรค ja todennettavissa.
  • Todennusaika lyhenee, kun samanlaiset kรคsitteet todennetaan perรคkkรคin, koska yhden testin tulosta voidaan kรคyttรครค uudelleen seuraavan testin syรถtteenรค.
  • TracTestitapausten ja niitรค vastaavien suunnittelutietojen vรคlille luodaan toimivuuslinkkejรค sen varmistamiseksi, ettรค jokainen vaatimus testataan ja ettรค suunnittelutulos vastaa suunnittelutietoja.

toteutus:

  • Kehitysvaiheen aikana luodut testausmenettelyt suoritetaan testaussuunnitelman mukaisesti ja niitรค noudatetaan tarkasti todentamistoiminnan aikana.
  • Jos ilmenee virheellisiรค tuloksia tai jos jotakin menetelmรครค on muutettava, muutokset on dokumentoitava ja hyvรคksyttรคvรค virallisesti.
  • Kaikki lรถydetyt ongelmat kirjataan vikana normaalisti vianhallinnan prosessi.
  • A trackyvykkyysmatriisi on luotu varmistamaan, ettรค jokainen varmennustestaussuunnitelmassa yksilรถity suunnittelutieto on testattu, ja mรครคrittรคmรครคn lรคpรคisysuhde.

Raportit:

  • Tรคmรค toiminto suoritetaan jokaisen vahvistusvaiheen lopussa.
  • Suunnittelun todentamisraportti antaa yksityiskohtaisen yhteenvedon todentamisen tuloksista, mukaan lukien konfiguraation hallinnan, kunkin testaustyypin tulokset ja todentamisen aikana havaitut ongelmat.
  • Suunnittelun varmennus tracVaatimusten ja vastaavien testitulosten vรคlille luodaan toimivuusraportti, jolla vahvistetaan, ettรค kaikki vaatimukset testattiin ja ettรค asianmukaiset tulokset kirjattiin.
  • Kaikki poikkeamat dokumentoidaan ja niihin puututaan asianmukaisesti.
  • RevTarkastukset suoritetaan suunnittelun todentamisen pรครคtyttyรค ja tuotokset hyvรคksytรครคn virallisesti.

Suunnittelun validointiprosessi

Validoinnilla ei ole yhtรค jรคykkรครค jรคrjestystรค. Sen sijaan se hyรถdyntรครค pientรค joukkoa hyvรคksyttyjรค menetelmiรค, ja projektissa kรคytetรครคn yleensรค useampaa kuin yhtรค niistรค.

  • Vertailu vastaaviin malleihin. Jotkin mallit voidaan validoida vertaamalla niitรค samankaltaisiin laitteisiin, jotka palvelevat samaa tarkoitusta. Tรคmรค on erityisen tรคrkeรครค validoidessa olemassa olevan infrastruktuurin kokoonpanomuutoksia tai uuteen jรคrjestelmรครคn tai sovellukseen sisรคllytettรคviรค vakiomalleja.
  • Esittely ja tarkastus. Jompaakumpaa tai molempia voidaan kรคyttรครค vaatimusten ja tuotteen muun toiminnallisuuden validointiin.
  • Analyysi. Suunnittelua voidaan analysoida matemaattisen mallinnuksen tai simulaation avulla, joka luo uudelleen vaaditun toiminnallisuuden.
  • Testaus. Lopulliselle suunnitelmalle suoritetaan testejรค sen varmistamiseksi, ettรค jรคrjestelmรค toimii mรครคritellyllรค tavalla, mikรค on seuraava vaihe: toiminnallinen testaus ja ei-toiminnallinen testaus tรคytรค kรคyttรคjรคn vaatimukset.
  • Dokumentointi. Testaussuunnitelma, suoritus ja tulokset tulee dokumentoida ja sรคilyttรครค osana suunnittelutietueita. Validointi on viime kรคdessรค kaikkien validointitoimien koottuja tuloksia.
  • Vastaavuuden perustelu. Kun lopullisessa suunnittelun validoinnissa kรคytetรครคn vastaavia tuotteita, valmistajan on dokumentoitava niiden samankaltaisuus ja mahdolliset erot alkuperรคiseen tuotantoon verrattuna.

esimerkki

Lyhyt kรคytรคnnรถn esimerkki tekee eron konkreettiseksi.

  • Otetaan esimerkiksi yksinkertainen tuote: vedenpitรคvรค kello.
  • Tuotevaatimusasiakirjassa saatetaan todeta, ettรค โ€kellon on oltava vedenpitรคvรค uinnin aikanaโ€. Tรคmรค on kรคyttรคjรคn tarve, ja validointia mitataan sen perusteella.
  • Suunnittelumรครคrityksissรค saatetaan todeta, ettรค โ€kellon tulisi toimia, vaikka kรคyttรคjรค uisi pitkรครคnโ€. Tรคmรค on suunnittelun lรคhtรถtieto, ja sitรค vasten todentamista mitataan.
  • Testitulosten tulisi vahvistaa, ettรค kello tรคyttรครค nรคmรค vaatimukset. Jos ne eivรคt tรคytรค vaatimuksia, uudelleensuunnittelua jatketaan, kunnes se tรคyttรครค vaatimukset.

Huomaa, miten kello voi lรคpรคistรค tarkistuksen, mutta silti epรคonnistua validoinnissa. Jos spesifikaatio mรครคrittelee pitkรคn uinnin viideksitoista minuutiksi ja oikeat uimarit viipyvรคt vedessรค tunnin, suunnittelun tuloste vastaa tรคydellisesti syรถtettรค ja silti pettรครค kรคyttรคjรคn odotukset.

Suunnittelun validoinnin ja todentamisen edut

Molempien toimintojen suorittaminen jatkuvasti sen sijaan, ettรค ne olisivat vain lopullinen portti, tuottaa alla olevat hyรถdyt.

  • Suunnitelmia voidaan seurata jatkuvasti, mikรค mahdollistaa kรคyttรคjรคn mรครคrittelemien vaatimusten tรคyttรคmisen jokaisessa vaiheessa.
  • Suunnittelun validointi osoittaa eron toiminnallisuuden toiminnan ja sen odotetun toiminnan vรคlillรค.
  • Validointimenettelyjen dokumentointi helpottaa toiminnallisuuden ymmรคrtรคmistรค myรถhemmin, aina kun tehdรครคn muutoksia tai parannuksia.
  • Kehitysaika lyhenee jatkuvasti ja tuottavuus paranee, mikรค auttaa toimittamaan tuotteen odotetulla tavalla.
  • Prosessi mรครคrittelee kunkin kรคytettรคvรคn validointimenetelmรคn laajuuden ja soveltamisalan.
  • Validointi voidaan suorittaa kรคyttรคmรคllรค yksityiskohtaisia โ€‹โ€‹suunnittelutietoja, jotka edustavat loppukรคyttรคjรคn vaatimuksia.
  • Kaikki lopputuloksen ja kรคyttรคjรคn tarvitsemien dokumenttien vรคliset erot tallennetaan sen sijaan, ettรค ne katoaisivat.
  • Validoituun suunnitteluun tehdyt muutokset kรคynnistรคvรคt uudelleenvalidoinnin, joten tietue ei koskaan katoa tuotteen ulkopuolelle.
  • Jokaisen validoinnin aikana tapahtuvan toiminnan dokumentointi on se, mikรค osoittaa riittรคvรคsti, ettรค suunnittelu tรคyttรครค kรคyttรคjรคn vaatimukset.

Suunnittelun todentaminen ja validointi on siksi parasta suunnitella laajemman kokonaisuuden sisรคllรค. ohjelmistotestauksen elinkaari ja kartoitettu toista vasten ohjelmistotestauksen tyypitsen sijaan, ettรค sitรค kรคsiteltรคisiin erillisenรค vaatimustenmukaisuuden valvontana.

UKK

Vasen alasvetoinen haara sisรคltรครค verifiointitoiminnot โ€“ vaatimus-, suunnittelu- ja koodikatselmukset. Oikea ylรถsvetoinen haara sisรคltรครค validointitoiminnot yksikkรถ- ja integrointitarkastuksista jรคrjestelmรค- ja hyvรคksymistestaukseen asti, joista jokainen taso vastaa vastapรครคtรค olevaa spesifikaatiota.

Pรครคasiassa, mutta ei tรคysin. Verifiointi nojaa katselmointiin, tarkastuksiin ja lรคpikรคvelyihin, kun taas validointi suorittaa koontiprosessin. Verifiointi voi silti sisรคltรครค yksikkรถtasolla suoritettuja testejรค, joten kรคsittele staattista ja dynaamista eroa taipumuksena eikรค sรครคntรถnรค.

IEEE 1012, jรคrjestelmien, ohjelmistojen ja laitteistojen todentamisen ja validoinnin standardi, on tรคrkein viitekehys. Laadunhallintastandardit, kuten ISO 9001, edellyttรคvรคt sekรค suunnittelun ettรค kehityksen valvontaa, ja sรครคnnellyt sektorit lisรครคvรคt omat suunnittelun valvontaa koskevat sรครคntรถnsรค.

Verifioinnin suorittavat yleensรค insinรถรถrit ja tarkastajat, jotka ovat riippumattomia suunnittelutuloksen tuottaneesta henkilรถstรค. Validointiin osallistuvat loppukรคyttรคjรคt tai heidรคn edustajansa, koska vain he voivat arvioida, vastaako toimitettu tuote todellista tarvetta.

Tekoรคlyavusteiset tyรถkalut merkitsevรคt epรคselviรค tai testaamattomia vaatimuksia tarkistuksen aikana ja ehdottavat tracsuunnittelutietojen ja testitapausten vรคliset toimivuusyhteydet ja kattavuusaukkojen korostaminen varmennusmatriisissa. Hyvรคksymispรครคtรถs pysyy tarkastajan tehtรคvรคnรค, koska todisteiden on oltava puolustettavissa.

GitHub Copilot voi laatia testikoodin, joka toteuttaa varmennusmenettelyn ja selittรครค tuntemattomia moduuleja koodikatselmuksen aikana. Se ei voi itse toimittaa objektiivista todistusaineistoa, joten tuotettu tulos vaatii silti tarkistuksen ja virallisen hyvรคksynnรคn.

Validoinnin kรคsittely muodollisuutena todennuksen lรคpรคisyn jรคlkeen, mitattavissa olevien suunnittelutietojen kirjoittaminen ja trackรคyttรถkelpoisuutta loppuun asti. Jokainen tuottaa tietueen, joka nรคyttรครค tรคydelliseltรค, mutta ei kestรค tarkastusta tai todellista kรคyttรคjรครค.

Aina kun muutos voi vaikuttaa kรคyttรคjรคn tarpeeseen tai tuotteen validointiolosuhteisiin. Vaikutusanalyysi mรครคrittรครค laajuuden: rajoitettu korjaus voi olla tarpeen. regressiotestaus vain, kun taas muuttunut tyรถnkulku vaatii muuttuneen validoinnin toistamisen.

Tiivistรค tรคmรค viesti seuraavasti: