Ugrás a tartalomhoz

V modell (szoftverfejlesztés)

Ellenőrzött
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]