Tervezési ellenőrzési és érvényesítési folyamat
Thomas Hamilton
⚡ Okos összefoglaló
A tervverifikáció megerősíti, hogy a terv kimenete megfelel a dokumentált terv bemenetének, míg a tervvalidáció megerősíti, hogy a késztermék kielégíti a felhasználók valós igényeit. Mindkettő végigfut a fejlesztés során, soha nem a végén.
Tervezési ellenőrzés
Tervezési ellenőrzés egy olyan módszer, amely vizsgálattal és bizonyítékokkal igazolja, hogy a tervezett szoftvertermék kimenete megfelel a bemeneti specifikációknak. A szoftverfejlesztés során a tervezés-ellenőrzési folyamat célja annak biztosítása, hogy a tervezett szoftvertermék megegyezzen a specifikációval.
A tervezési bemenet minden olyan fizikai és teljesítménykövetelmény, amelyet a tervezés alapjául használnak. A tervezési kimenet az egyes tervezési fázisok és a teljes tervezési erőfeszítés eredménye. A szabályozott iparágakban, például az orvostechnikai eszközöknél, a végső tervkimenet képezi az eszköz törzsadatainak alapját, ezért a tervezés-ellenőrzési szókincs olyan gyakran megjelenik az ellenőrzési dokumentációban.
A gyakorlatban az ellenőrzés két dokumentumkészletet hasonlít össze: a bevitt specifikációkat, szabványokat és korlátozásokat a kiadott rajzokkal, kóddal és tesztutasításokkal. Minden eltérés közöttük ellenőrzési megállapítás.
Tervezési érvényesítés
A verifikáció a belső konzisztenciát bizonyítja. A validáció a nehezebb kérdést teszi fel, hogy a specifikáció egyáltalán a megfelelő terméket írta-e le.
Tervezési érvényesítés A tervvalidáció (designvalidation) egy olyan folyamat, amelynek során a szoftverterméket a végfelhasználók vagy az érdekelt felek pontos követelményei alapján értékelik. A tervvalidáció célja a szoftvertermék tesztelése a fejlesztés után annak megerősítésére, hogy a felhasználó saját környezetében használva megfelel ezeknek a követelményeknek.
A validáció a terv felhasználói igényekhez való igazodó konzisztenciájának és teljességének bemutatásával foglalkozik. Ez az a szakasz, ahol ténylegesen felépítjük a termék egy verzióját, és validáljuk azt a felhasználói követelmények alapján.
Az alábbi szalagcím a tevékenység két felét jelöli, ahogyan azokat általában a tervezési feljegyzésekben bemutatják.
Az alábbi ábra magát a tervvalidációs folyamatot mutatja be, a felhasználói igényektől kezdve egészen a validált termékig.
A cél objektív bizonyítékokkal bizonyítani, hogy a termék kielégíti a dokumentált felhasználói igényeket. Az objektív bizonyíték egyszerűen a kimenet fizikai bizonyítéka – egy kép, egy szöveges fájl, egy hangfájl vagy egy aláírt jelentés –, amely igazolja, hogy az eljárást ténylegesen végrehajtották.
Ezen objektív bizonyítékok révén a folyamat következetesen azt vizsgálja, hogy a termék megfelel-e az előre meghatározott követelményeknek. Magában foglalja a tesztelési tevékenységet, az ellenőrzést, az elemzést és hasonló technikákat, ezért a validálás általában a következőkre támaszkodik: rendszertesztelés és a felhasználói elfogadási tesztelés nem pedig egységszintű ellenőrzéseken.
A tervezési ellenőrzés és az érvényesítés közötti különbség
Mindig vannak félreértések a verifikáció és a validáció között. Különböző tevékenységekről van szó, és mindkettőt a fejlesztési folyamat minden szakaszában végzik, nem pedig egyetlen mérföldkőnél.
| Tervezési ellenőrzés | Tervezési érvényesítés |
|---|---|
| A tervellenőrzést ott alkalmazzák, ahol a tényleges tervértéknek meg kell egyeznie a várt tervértékkel, amely megfelel a termék specifikációinak. | A tervvalidáció (validation) célja annak megállapítása, hogy a végső terv megfelel-e a felhasználói igények elvárásainak. |
| A tervellenőrzés a következő kérdést teszi fel: jól tervezted meg a terméket? | A tervvalidáció kérdése: a megfelelő terméket tervezted-e? |
| A tervellenőrzés magában foglalja az egységet és az elsődleges integrációs szintű tesztelés. | A tervérvényesítés másodlagos vagy magasabb szintű integrációt és rendszerszintű tesztelést foglal magában. |
| A tervellenőrzés bizonyos aspektusai elvégezhetők a tervellenőrzés során, de a tervellenőrzés nem helyettesíti a tervvalidációt. | A terv érvényesítése a sikeres tervellenőrzést követi. |
| A tervellenőrzés elvégezhető egyedi modulon vagy a kész rendszeren bármilyen körülmények között. | A tervezési hitelesítést meghatározott feltételek mellett kell elvégezni, a felhasználói igényeknek megfelelően. |
| A tervellenőrzés statikus technikákat is alkalmazhat. Magában foglalja a rendszerellenőrzéseket, az elemzést és a formális ellenőrzési tevékenységeket. | A tervvalidáció a tesztvégrehajtási eredmények végleges jelentéséből áll, amelyet felülvizsgálnak, jóváhagynak és aláírnak. Ezeket a dokumentumokat későbbi hivatkozás céljából tárolják. |
Hasznos rövidítés: az ellenőrzés többnyire statikus munka dokumentumokkal szemben, míg az érvényesítés többnyire dinamikus tesztelés egy futó builddel szemben.
Tervezési ellenőrzési folyamat
Az ellenőrzési folyamat öt szakaszban fut, és mindegyik egy olyan műterméket hoz létre, amelytől a következő szakasz függ.
Azonosítás és előkészítés:
- Amíg egy specifikáció fejlesztés alatt áll, a verifikációs tevékenységeket párhuzamosan azonosítják. Ez lehetővé teszi a tervező számára, hogy megbizonyosodjon arról, hogy a specifikáció valóban verifikálható, így a tesztmérnök elkezdheti a részletes teszttervek és eljárások kidolgozását. A specifikáció bármilyen változását kommunikálni kell.
- Határozza meg a hitelesítés elvégzésének legjobb megközelítését, és határozza meg a mérési módszereket, a szükséges erőforrásokat, eszközöket és létesítményeket.
- A kész ellenőrzési tervet a tervezőcsapattal közösen felülvizsgálják, hogy a terv véglegesítése előtt feltárják a felmerülő problémákat.
Tervezés:
- Az ellenőrzés megtervezése a központi és a fejlesztőcsapatok egyidejű tevékenysége. A projekt teljes életciklusa alatt zajlik, és a tervezési bemeneti adatok változása esetén frissül.
- Ebben a fázisban a tesztelt szoftvert vagy rendszert hatókörében dokumentálják.
- Egy előzetes tesztelési tervet írnak, majd finomítanak. A terv rögzíti a projekt kockázatát csökkentő kritikus mérföldköveket.
- Kiválasztják az eszközöket, a tesztkörnyezetet és a fejlesztési stratégiát, és azonosítják az ellenőrzéssel vagy elemzéssel megerősítendő követelményeket.
Fejlesztőping:
- Vizsgálati eset a fejlődés egybeesik a SDLC módszertan a projektcsapat által megvalósított. Ebben a szakaszban számos tesztelési módszert azonosítanak.
- A tervezési bemeneteket úgy kell kidolgozni, hogy még a legegyszerűbb ellenőrzési tevékenységek is egyértelműek és ellenőrizhetők legyenek.
- Az ellenőrzési idő csökken, ha hasonló fogalmakat egymás után ellenőriznek, mivel az egyik teszt kimenete újra felhasználható bemenetként egy következő teszthez.
- TracA tesztesetek és a hozzájuk tartozó tervezési bemenetek között teljesítőképességi kapcsolatokat hoznak létre, hogy minden követelmény tesztelésre kerüljön, és a tervezési kimenet megfeleljen a tervezési bemeneteknek.
Végrehajtás:
- A fejlesztési fázisban létrehozott teszteljárásokat a teszttervnek megfelelően hajtják végre, és szigorúan betartják a verifikációs tevékenység során.
- Ha érvénytelen eredmények merülnek fel, vagy ha bármely eljárás módosításra szorul, a változtatásokat dokumentálni és hivatalosan jóvá kell hagyni.
- Minden talált problémát a szokásos módon hibaként naplózunk. hibakezelési folyamat.
- A tracteljesítőképességi mátrix azért jön létre, hogy ellenőrizze, hogy a verifikációs teszttervben azonosított összes tervezési bemenetet tesztelték-e, és hogy meghatározza a sikeres teljesítési arányt.
Jelentések:
- Ezt a tevékenységet az ellenőrzés végrehajtásának minden fázisának végén hajtják végre.
- A tervellenőrzési jelentés részletes összefoglalást tartalmaz az ellenőrzési eredményekről, beleértve a konfigurációkezelést, az egyes tesztelési típusok eredményeit és az ellenőrzési tevékenység során talált problémákat.
- Tervellenőrzés tracA követelmények és a hozzájuk tartozó teszteredmények között teljesítési jelentés készül, amely megerősíti, hogy minden követelményt teszteltek, és hogy a megfelelő eredményeket rögzítették.
- Minden meg nem felelés dokumentálva és megfelelően kezelve van.
- RevA tervellenőrzési tevékenység befejezését követően felülvizsgálatokat végeznek, és a kimeneteket hivatalosan jóváhagyják.
Tervezési érvényesítési folyamat
A validációnak nincs egyformán merev sorrendje. Ehelyett elfogadott módszerek egy kis csoportjára támaszkodik, és egy projekt általában többet is használ ezekből.
- Összehasonlítás hasonló kialakításokkal. Egyes tervek validálhatók hasonló, hasonló célt szolgáló berendezésekkel való összehasonlítással. Ez különösen fontos a meglévő infrastruktúra konfigurációs változásainak, vagy az új rendszerbe vagy alkalmazásba beépülő szabványos tervek validálásakor.
- Bemutató és ellenőrzés. Bármelyik vagy mindkettő felhasználható a termék követelményeinek és egyéb funkcióinak validálására.
- Elemzés. A terv elemezhető matematikai modellezéssel vagy szimulációval, amely újraalkotja a szükséges funkcionalitást.
- Tesztelés. A végleges terven teszteket végeznek, hogy igazolják a rendszer működési képességét a specifikációknak megfelelően, ami funkcionális tesztelés és a nem funkcionális tesztelés megfeleljen a felhasználói követelményeknek.
- Dokumentáció. A teszttervet, a végrehajtást és az eredményeket dokumentálni és a tervezési feljegyzések részeként meg kell őrizni. A validáció végső soron az összes validációs tevékenység összegyűjtött eredményeit jelenti.
- Egyenértékűség igazolása. Amennyiben a végső tervellenőrzés során egyenértékű termékeket használnak, a gyártónak dokumentálnia kell a hasonlóságot és a kezdeti gyártástól való eltéréseket.
Példa
Egy rövid, gyakorlatias példa kézzelfoghatóvá teszi a különbséget.
- Vegyünk egy egyszerű terméket: egy vízálló órát.
- A termékkövetelmény-dokumentum kimondhatja, hogy „az órának vízállónak kell lennie úszás közben”. Ez a felhasználói igény, és ez alapján mérik a validációt.
- A tervezési specifikáció kimondhatja, hogy „az órának akkor is működnie kell, ha a felhasználó hosszabb ideig úszik”. Ez a tervezési bemenet, és ez alapján mérik az ellenőrzést.
- A teszteredményeknek meg kell erősíteniük, hogy az óra megfelel ezeknek a követelményeknek. Ha nem, akkor az újratervezési iterációk addig folytatódnak, amíg meg nem felel.
Figyeljük meg, hogyan mehet át egy óra az ellenőrzésen, és mégis megbukhat a validáción. Ha a specifikáció egy hosszabb úszást tizenöt percben határoz meg, és az igazi úszók egy órát töltenek a vízben, a tervezett kimenet tökéletesen megegyezik a bemenettel, és a felhasználó még mindig nem kapja meg a kívánt eredményt.
A tervezési érvényesítés és ellenőrzés előnyei
Az alábbi előnyöket az hozza, ha mindkét tevékenységet folyamatosan futtatjuk, ahelyett, hogy a végén kapuként lennének.
- A tervek folyamatosan monitorozhatók, ami lehetővé teszi a felhasználó által meghatározott követelmények minden szakaszban történő teljesítését.
- A terv validálása rámutat a funkcionalitás működése és a várt működés közötti különbségre.
- A validációs eljárások dokumentálása megkönnyíti a funkciók megértését később, amikor változtatást vagy fejlesztést hajtanak végre.
- A fejlesztési idő folyamatosan csökken, a termelékenység pedig javul, ami segít a termék vártnak megfelelő leszállításában.
- A folyamat meghatározza az egyes alkalmazandó validációs módszerek körét és hatókörét.
- A validáció elvégezhető részletes tervadatok felhasználásával, amelyek a végső felhasználói követelményeket képviselik.
- Az eredmény és a felhasználói igények dokumentumai közötti bármilyen különbség rögzítésre kerül, nem pedig elveszik.
- A validált terv módosításai újravalidálási tevékenységet indítanak el, így a rekord soha nem vesz el a terméktől.
- A validáció során végrehajtott minden tevékenység dokumentálása az, ami megfelelően bizonyítja, hogy a terv megfelel a felhasználói követelményeknek.
A tervellenőrzést és -validálást ezért a legjobb a tágabb környezeten belül megtervezni. szoftvertesztelés életciklusa és egymáshoz viszonyítva leképezve a szoftvertesztelés típusaiahelyett, hogy különálló megfelelési gyakorlatként kezelnék.
