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 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.

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.

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]

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.

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.

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.

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.

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.

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.

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.

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]}

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.

• 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

• The SDLC and SixSigma
• SDLC for small and medium DB applications

• Rendszerfejlesztési életciklus