V modell (szoftverfejlesztés)

A Wikipédiából, a szabad enciklopédiából
A szoftverfejlesztés folyamatának V modellje[1]

A szoftverfejlesztés során a V modell[2] olyan fejlesztési folyamatot képvisel, amelyet a vízesésmodell kiterjesztésének tekinthetünk, és egy esete az általános V modellnek. A V modell a nevét onnan kapta, hogy két szára van, és így egy V betűhöz hasonlít.[3] A modell ábrája a fejlesztés két folyamatának két megközelítését tükrözi, bemutatja a kapcsolatokat a fejlesztési életciklus egyes szakaszai és a kapcsolódó tesztelési szakaszok között. Top-down megközelítésként kifejezi a tervezési folyamat fentről lefelé történő haladását a diagram bal oldali ágában, míg bottom-up megközelítésben a jobb oldali ágban a tesztelési folyamat lentről felfelé halad. A vízszintes és a függőleges tengely az időt vagy a projekt teljességét (balról jobbra) és az absztrakció szintjét jelöli.

A projekt meghatározásának fázisai[szerkesztés]

Követelmények elemzése[szerkesztés]

A követelményelemzési fázisban, a verifikációs folyamat első lépésében a rendszer követelményeit a felhasználó(k) igényeinek elemzésével gyűjtik össze. Ez a szakasz annak meghatározására irányul, hogy miként kell működnie az ideális rendszernek. Ez azonban nem befolyásolja a szoftver tervezésének vagy készítésének módját. Általában a felhasználókkal egy interjút készítenek és ez alapján alkotják meg a felhasználói követelmények dokumentációját.

A felhasználói követelményekről szóló dokumentum tipikusan a rendszer funkcionális, interfész, teljesítmény, adat, biztonság és egyéb követelményeit, a felhasználó elvárásainak megfelelően írja le. Ezt a dokumentációt az üzleti elemzők használják, hogy kommunikálni tudjanak a felhasználókkal a rendszer működéséről. A felhasználók gondosan áttekintik ezt a dokumentumot, mivel iránymutatásként szolgál majd a rendszer tervezői számára a tervezési szakaszban. A felhasználói elfogadási teszteket (user acceptance tests) is ebben a fázisban tervezik meg. Lásd még: Funkcionális követelmények.

Különböző módszereket alkalmaznak a felhasználói követelmények összegyűjtésére. Ilyenek például a felhasználókkal készített interjúk, kérdőívek, dokumentumelemzések, megfigyelések, prototípusok készítése, használati esetek (use case), statikus és dinamikus nézetek használata.

Rendszertervezés[szerkesztés]

A rendszertervezés az a szakasz, amelyben a rendszermérnökök a felhasználói követelményekről szóló dokumentum tanulmányozásával elemzik és megértik a javasolt rendszer üzleti tevékenységét. Megtalálják azokat a lehetőségeket és technikákat, amelyekkel a felhasználói igények megvalósíthatók. Ha valamelyik követelmény nem valósítható meg, a felhasználót értesítik a problémáról, közös megoldást keresnek, és a felhasználói követelményt ennek megfelelően átszerkesztik.

Elkészül a szoftver specifikációs dokumentuma, amely konkrét tervként szolgál a fejlesztési szakasz számára. Ez a dokumentum tartalmazza az általános rendszer felépítést, menüszerkezeteket, adatszerkezeteket stb. Tartalmazhat például üzleti forgatókönyveket, mintafelületeket és jelentéseket a megértés elősegítése érdekében. Ebben a szakaszban más műszaki dokumentáció is készül, például egyed-kapcsolat diagramok, adatszótár. A rendszer tesztelésére szolgáló dokumentumok is itt készülnek.

Architekturális terv[szerkesztés]

A számítógépes és a szoftverarchitektúra tervezésének fázisára utalhatunk úgy is, mint magas szintű tervezés. Az architektúra kiválasztásának alapja az, hogy megvalósítsa mindazt, amely jellemzően a modulok listájából, az egyes modulok rövid funkcionalitásából, az interfészkapcsolatokból, függőségekből, adatbázis-táblázatokból, architekturális diagramokból, technológiai részletekből stb. áll. Az integrációs tesztelés tervezését mindig az adott szakaszban hajtják végre.[4]

Modul megtervezése[szerkesztés]

A modul tervezési szakaszát alacsony szintű tervezésnek is nevezhetjük. A tervezett rendszert kisebb egységekre (units) vagy modulokra (modules) bontják, és mindegyiket részletesen kifejtik, hogy a programozók közvetlenül neki tudjanak kezdeni a kód megírásának. Az alacsony szintű tervezési dokumentum vagy programspecifikációk tartalmazni fogják a modul részletes funkcionális logikáját, pszeudokódban kifejtve:

  • adatbázis-táblázatokat az összes elemmel, beleértve azoknak a típusát és a méretét
  • összes interfészt részletes és teljes API-referenciákkal
  • összes függőségi kérdést
  • hibaüzenetek felsorolását
  • teljes bemeneti és kimeneti modulokat.

Ebben a szakaszban tervezik meg az egységtesztek tesztelésének folyamatát is.

Érvényesítési fázisok[szerkesztés]

A V modellben a verifikációs fázis minden szakaszának van egy megfelelő fázisa az érvényesítési szakaszban.[5] Az alábbiak a V modell elfogadásának tipikus fázisai, bár más néven is ismertek.

Egységtesztelés[szerkesztés]

A V modellben az egységtesztelési terveket a modul tervezési szakaszában fejlesztik ki. Ezeket az egységteszteket még a kódolási vagy egységi (unit) szinten lefuttatják, hogy ki tudják küszöbölni a felmerülő hibákat. Az egység a legkisebb entitás, amely függetlenül létezhet, ilyen például egy programmodul. Az egységtesztelés ellenőrzi, hogy a legkisebb entitás megfelelően tud-e működni, ha elkülönül a többi kódtól vagy más egységektől.

Integrációs tesztelés[szerkesztés]

Az integrációs tesztterveket az architekturális tervezési szakaszban dolgozzák ki. Ezek a tesztek vizsgálják, hogy az önállóan létrehozott és tesztelt egységek nem ütköznek és kommunikálni is tudnak egymással. Ezeket a teszteredményeket már megosztják az ügyfél csapatával.

Rendszertesztelés[szerkesztés]

A rendszertesztelési terveket a rendszer tervezési szakaszában dolgozzák ki. Az egység és integrációs teszttervektől eltérően a rendszerteszt terveket az ügyfél üzleti csapata állítja össze. A rendszerteszt biztosítja, hogy a kifejlesztett alkalmazás elvárásai teljesüljenek. A teljes alkalmazás funkcionalitását, kölcsönös függőségét és más alkalmazásokkal való kommunikációját tesztelik. A rendszer tesztelése azt vizsgálja, hogy a funkcionális és nem funkcionális követelmények teljesültek-e. A terheléses tesztelés, a teljesítmény teszt, a stressz tesztelés, a regressziós tesztelés mind a rendszer tesztelésének a része.

Felhasználói elfogadási tesztelés[szerkesztés]

A felhasználói elfogadási tesztterveket a követelményelemzés fázisában dolgozzák ki. A tesztterveket üzleti felhasználók állítják össze. A felhasználói elfogadási tesztet olyan felhasználói környezetben hajtják végre, amely hasonlít a valós termelési környezetre, ahol már valósághű adatokat használnak fel. Ez a teszt ellenőrzi, hogy az elkészített és leszállított rendszer megfelel-e a felhasználó igényeinek, illetve a rendszer már készen áll-e a használatra a mindennapokban.

Kritika[szerkesztés]

Az agilis szoftverfejlesztés támogatói és mások a V modellt számos okból kifogásolták, a szoftverfejlesztés nem megfelelő modelljeként tartották számon.[6] [7] [8] A kritikák a következőket tartalmazzák:

  1. A modell túl egyszerű ahhoz, hogy pontosan tükrözze a szoftverfejlesztési folyamatot, illetve a menedzsereknek hamis biztonságérzetet nyújt. A V modell a szoftverfejlesztés projektmenedzsment szemléletét tükrözi, és a szoftverfejlesztők vagy felhasználók helyett inkább a projektmenedzserek, könyvelők és ügyvédek igényeinek felel meg.
  2. Noha a kezdők könnyen megértik a különböző fázisokat, ez a kezdeti megértés csak akkor lehet hasznos, ha a kezdők elmélyítik a fejlesztési folyamat megértését, és azt, hogy a V modellt miként kell átdolgozni és kibővíteni a gyakorlatban. Ha a résztvevők továbbra is naivan fognak hozzá a V modell használatához, akkor csak nagy nehézségek árán lesz sikeresen alkalmazható.
  3. Rugalmatlan, a szoftverfejlesztés merev és lineáris szemléletét helyezi az előtérbe, és nem rendelkezik olyan eszközökkel, amelyekkel gyorsan és hatékonyan tudna reagálni a változásokra.
  4. A vízesésmodelltől nem sokban különböző változat, és ezért ugyanazon kritika vonatkozhat rá, mint az említett modellre. Nagyobb hangsúlyt fektet a tesztelésre, különös tekintettel a korai tesztelés tervezésének fontosságára. Ugyanakkor a V modell gyakorlatra vonatkozó kritikája gyakran az, hogy a tesztelést szoros idősávokra szorítják a fejlesztés végén, amikor a korábbi szakaszokon már túlléptek, de az implementáció dátuma továbbra sem változik.
  5. Összhangban áll a tesztelés eredménytelen és hatástalan megközelítésével, és ezért implicit módon ösztönzi azt. A teszt szkriptek előzetes írását segíti elő, nem pedig a feltáró tesztelést. Arra ösztönzi a tesztelőket, hogy azt keressék, amit találni szeretnének, ahelyett, hogy felfedeznék azt, ami valóban ott van. Továbbá a két szár azonos szintjei közé egy merev kapcsolat létrehozását ösztönzi (például: felhasználói elfogadási teszttervek, amik a felhasználói követelmények dokumentációban vannak származtatva), ahelyett hogy arra biztatná a tesztelőket, hogy a leghatékonyabb módszert válasszák a tesztelés megtervezésére és végrehajtására.
  6. Hiányzik a koherencia és a pontosság, illetve széles körben elterjedt az a bizonytalanság, hogy mi is pontosan a V modell. Ha visszavezetjük azokra az alapfogalmakra, amelyekben a legtöbb ember egyetért, a szoftverfejlesztésnek egy sablonos, és haszontalan reprezentációjává válik. A V modell érdemeivel kapcsolatos nézeteltérések okai gyakran azt tükrözik, hogy a fogalom meghatározásban nem értenek egyet a résztvevők.

Jelenlegi állapot[szerkesztés]

A V modell támogatói azt állítják, hogy a modell az idők során sokat fejlődött, és már támogatja a rugalmasságot és az agilitást a fejlesztési folyamat során.[9] Úgy gondolják, hogy a rendkívül fegyelmezett megközelítés mellett elősegíti a stabil szoftvertermékek felépítéséhez szükséges aprólékos tervezést, fejlesztést és dokumentációt. Az utóbbi időben ezt a modellt már hasznosítja az orvostechnikai eszközipar is.[10] [11]

Források[szerkesztés]

  1. ↑ Clarus Concept of Operations. Archiválva 2009. július 5-i dátummal a Wayback Machine-ben. Publication No. FHWA-JPO-05-072, Federal Highway Administration (FHWA), 2005
  2. ↑ Kevin Forsberg and Harold Mooz, "The Relationship of System Engineering to the Project Cycle", in Proceedings of the First Annual Symposium of National Council on System Engineering, October 1991: 57–65.
  3. ↑ Kusper Gábor. Programozási technológiák. Líceum K (2015). ISBN 978-615-5509-44-5  
  4. ↑ What is V model - Advantages, disadvantages and when to use it
  5. ↑ DeSpautz, Joseph: GAMP Standards For Validation of Automated Systems. Pharmaceutical Processing, 2008. március 11. [2012. május 8-i dátummal az eredetiből archiválva]. (Hozzáférés: 2012. február 28.)
  6. ↑ "The Death of the V-Model" Archiválva 2022. január 21-i dátummal a Wayback Machine-ben, accessed January 6, 2013
  7. ↑ "The Dangerous & Seductive V Model" Archiválva 2017. június 27-i dátummal a Wayback Machine-ben, accessed January 6, 2013
  8. ↑ "New Models for Test Development" Archiválva 2012. szeptember 3-i dátummal a Wayback Machine-ben, accessed January 6, 2013
  9. ↑ "Toward Agile Systems Engineering Processes"[halott link], accessed January 6, 2013
  10. ↑ "Barriers to Adopting Agile Practices When Developing Medical Device Software"
  11. ↑ "A Software Process Development, Assessment and Improvement Framework, for the Medical Device Industry "

Fordítás[szerkesztés]

Ez a szócikk részben vagy egészben a V-Model (software development) című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

További irodalom[szerkesztés]

  • Roger S. Pressman:Software Engineering: A Practitioner's Approach, The McGraw-Hill Companies, ISBN 0-07-301933-X
  • Mark Hoffman & Ted Beaumont: Application Development: Managing the Project Life Cycle, Mc Press, ISBN 1-883884-45-4
  • Boris Beizer: Software Testing Techniques. Second Edition, International Thomson Computer Press, 1990, ISBN 1-85032-880-3

További információk[szerkesztés]

Kapcsolódó szócikk[szerkesztés]

A lap eredeti címe: „https://hu.wikipedia.org/w/index.php?title=V_modell_(szoftverfejlesztés)&oldid=25848562”