V modell
A V-Model (vagy VEE modell) egy információs rendszerek (IS) fejlesztési modell, amelynek célja a rendszerfejlesztéssel kapcsolatos bonyolultságok megértésének egyszerűsítése. A szoftvertermékek , hardver és ember-gép interfészek fejlesztésének egységes eljárásának meghatározására szolgál .
Áttekintés
Történelem
A V-modell koncepcióját Németország és az Egyesült Államok az 1980-as évek végén, egymástól függetlenül dolgozta ki:
- A német V-modellt az IABG repülőgépgyártó cég fejlesztette ki a München melletti Ottobrunnban a koblenzi Szövetségi Fegyverbeszerzési Osztály közreműködésével a Német Védelmi Minisztérium számára. A modellt a német szövetségi közigazgatás 1992 nyarán vette át polgári használatra [1] .
- Az amerikai V-modellt (VEE) a National Council for Systems Engineering (nemzetközi – 1995 óta) fejlesztette ki műholdas rendszerekre, beleértve a hardvert, szoftvert és a felhasználói interakciót [2] .
A V-Model jelenlegi verziója a V-Model XT, amelyet 2005 februárjában hagytak jóvá . A V-modellt a német szövetségi közigazgatás szoftverfejlesztési folyamatának kezelésére használják. Ma már a német kormányzati és védelmi projektek, valamint a németországi szoftvergyártók szabványa. A V-Model inkább az új termékek fejlesztésére vonatkozó projektszabványok összessége. Ez a modell sok tekintetben hasonlít a PRINCE2 -höz , és mind a projektmenedzsment, mind a rendszerfejlesztés módszereit írja le.
Alapelvek
A V alakú modell alapelve, hogy az idő múlásával egyidejűleg balról jobbra haladva nő a projekt részletessége, és egyik sem tud visszafordulni. A projektben az iterációk vízszintesen, a levél bal és jobb oldala között történnek.
Az információs rendszerek fejlesztésében a V-modell a vízesés modell egyik változata , amelyben a fejlesztési feladatok felülről lefelé haladnak az V betű bal oldalán, a tesztfeladatok pedig az V betű jobb oldalán. Vízszintes vonalak A V belsejében láthatók, hogy az egyes fejlesztési fázisok eredményei hogyan befolyásolják a tesztelési rendszer fejlődését az egyes tesztelési fázisokban. A modell azon alapul, hogy az elfogadási tesztelés elsősorban a követelményeken, a rendszertesztelés a követelményeken és az architektúrán, a komplex tesztelés a követelményeken, az architektúrán és az interfészeken, a komponens tesztelése pedig a követelményeken, az architektúrán, az interfészeken és az algoritmusokon alapul [ 4]. ] .
Célok
A V-modell támogatást nyújt a projektek tervezésében és megvalósításában. A projekt során a következő feladatokat tűzzük ki:
- Kockázatminimalizálás: A V-alakú modell átláthatóbbá teszi a projektet és javítja a projektellenőrzés minőségét a közbülső célok szabványosításával, a megfelelő eredmények és felelősök leírásával. Ez lehetővé teszi a projekt eltéréseinek és kockázatainak korai szakaszban történő azonosítását, és javítja a projektmenedzsment minőségét, csökkentve a kockázatokat.
- Minőségfejlesztés és minőségbiztosítás: A V-Model egy szabványosított fejlesztési modell, amely a kívánt minőségi eredményeket hozza a projektből. A köztes eredmények már korai szakaszban ellenőrizhetők. Az univerzális dokumentáció megkönnyíti az olvashatóságot, érthetőséget és ellenőrizhetőséget.
- A projekt összköltségének csökkentése: A fejlesztésre, termelésre, menedzsmentre és támogatásra szánt források előre kiszámíthatók és ellenőrizhetők. A kapott eredmények szintén univerzálisak és könnyen megjósolhatók. Ez csökkenti a következő szakaszok és projektek költségeit.
- A projekt résztvevői közötti kommunikáció minőségének javítása: Az összes elem és feltétel egyetemes leírása elősegíti a projekt valamennyi résztvevőjének kölcsönös megértését. Így csökkennek a felhasználó, a vevő, a szállító és a fejlesztő közötti értelmezési pontatlanságok [5] .
Előnyök
- A V-Model felhasználói részt vesznek a V-Model fejlesztésében és karbantartásában. A Változásellenőrző Bizottság karbantartja a projektet, és évente egyszer ülésezik, hogy feldolgozza a V-modell módosítására vonatkozó összes kérelmet [6] .
- Bármely projekt indításakor a V alakú modell ehhez a projekthez adaptálható, mivel ez a modell nem függ a szervezetek és projektek típusától [7] .
- A V-modell lehetővé teszi a tevékenység külön lépésekre bontását, amelyek mindegyike tartalmazza a hozzá szükséges műveleteket, az azokhoz szükséges utasításokat, ajánlásokat és a tevékenység részletes magyarázatát [8] .
Korlátozások
A következő pontokat a V-modell nem veszi figyelembe, de külön is figyelembe vehető, illetve lehetőség van a modell hozzájuk való adaptálására:
- A szolgáltatási szerződések elhelyezése nem szabályozott.
- A rendszer kezelésének, karbantartásának, javításának és ártalmatlanításának megszervezését és végrehajtását a V-modell nem veszi figyelembe. A modell azonban figyelembe veszi ezen műveletek tervezését és előkészítését.
- A V-alakú modell inkább egy projekt szoftverfejlesztéséről szól, mint a folyamat teljes megszervezéséről [9] .
Kritika
Előnyök
- A modell a tervezésre helyezi a hangsúlyt, amelynek célja a fejlesztés alatt álló termék ellenőrzése és validálása a fejlesztés korai szakaszában. Az egységtesztelési szakasz érvényesíti a részletes tervet. Az integrációs és tesztelési szakaszok az építészeti tervezést vagy a legfelső szintű tervezést valósítják meg. A rendszertesztelési szakasz megerősíti, hogy a termékre és annak specifikációjára vonatkozó követelmények szakaszát megfelelően teljesítették [10] .
- A modell biztosítja az összes kapott külső és belső adat hitelesítését és ellenőrzését, nem csak magának a szoftverterméknek [10] [11] [12] .
- A V-alakú modellben a követelményeket a rendszertervezés előtt határozzák meg, a szoftvertervezést pedig a komponensek fejlesztése előtt [10] .
- A modell meghatározza a fejlesztési folyamat eredményeként előállítandó termékeket, és minden kapott adatot tesztelni kell [10] [12] .
- A modellnek köszönhetően a projektmenedzserek nyomon követhetik a fejlesztési folyamat előrehaladását, hiszen ebben az esetben teljesen lehetséges egy idővonal használata, és az egyes fázisok teljesítése mérföldkőnek számít [10] [12] .
Hátrányok
- A modell nem tesz lehetővé párhuzamos eseményekkel való munkát [10] .
- A modell nem rendelkezik a dinamikus változások követelményének bevezetéséről az életciklus különböző szakaszaiban [10] [11] [13] .
- A követelmények tesztelése az életciklusban túl későn történik, ami lehetetlenné teszi a változtatások végrehajtását a projekt ütemezésének befolyásolása nélkül [10] [11] .
- A modell nem tartalmaz kockázatelemzést célzó intézkedéseket [10] .
- Valamilyen eredmény csak akkor látható, ha elérjük a V betű alját [14] .
Lásd még
Jegyzetek
- ↑ V-Model - Életciklus folyamatmodell Archivált 2016. március 3. (Angol)
- ↑ Forsberg, K. és Mooz, H., "The Relationship of Systems Engineering to the Project Cycle" , First Annual Council on Systems Engineering Symposium, 1991. október
- ↑ Clarus működési koncepciója. Archiválva 2014. szeptember 12-én a Wayback Machine No. FHWA-JPO-05-072, Szövetségi Autópálya-igazgatás (FHWA), 2005
- ↑ Economicus: közgazdasági, pénzügyi és menedzsment szótárak sorozata (hozzáférhetetlen hivatkozás)
- ↑ A V-modell célkitűzései archiválva 2011. április 20. (Angol)
- ↑ A V-modell továbbfejlesztése Archiválva 2011. április 23. (Angol)
- ↑ A V-modell kezelési mechanizmusai - Szabás , Archiválva : 2011. július 19. (Angol)
- ↑ A V-modell tevékenységi modelljének áttekintése archiválva 2011. július 19. (Angol)
- ↑ A V-modell korlátai Archiválva : 2011. május 21. (Angol)
- ↑ 1 2 3 4 5 6 7 8 9 A szoftverfejlesztési életciklus modellek áttekintése . Letöltve: 2011. június 5. Az eredetiből archiválva : 2016. június 15. (határozatlan)
- ↑ 1 2 3 Kiválóság tesztelése – V-modell archiválva : 2011. június 25. a Wayback Machine -nél
- ↑ 1 2 3 Sameeradilhan - A Waterfall Model és a V-Model előnyei és hátrányai Archiválva : 2012. augusztus 29. a Wayback Machine -nél
- ↑ TestManagement – A V-modell előnyei és hátrányai archiválva 2015. június 20-án a Wayback Machine -nél
- ↑ V-Model archiválva : 2015. június 20. a Wayback Machine -nél : Expert Program Management
Linkek