A rendszertechnikusok régóta a V-t a jó tervezés alapvető részének tekintik. Az utóbbi időben azonban a rendszermérnöki V rossz hírét keltette. A mérnökök új generációja a lassú, vízeséses mérnöki gyakorlat szimbólumaként tekint rá. Ezeket a gyakorlatokat irrelevánsnak tartják a szoftverfejlesztéshez szükséges sebesség szempontjából.
A hagyományos mérnöki módszerek hívei a V-t az “agilis” módszerekkel szemben részesítik előnyben. Ez különösen akkor igaz, ha kritikus rendszerekről van szó.
Kinek higgyünk?
Hát, ha őszinték vagyunk, amikor a V egyetlen dicsőséges passzusként létezik egy egész rendszerre, az új generációnak nagyszerű érvei vannak. A V valóban lelassíthatja a jó szoftverfejlesztést.
A rendszermérnöki V lényegét tekintve egy logikai konstrukció. A rendszerkövetelmények feltárását írja le a rendszer kisebb részekre bontásával, majd e részek összeszerelésével és validálásával.
A rendszermérnökök a V-t különböző kontextusokban alkalmazzák. Leggyakrabban a V nagy szervezetekben, például az Egyesült Államok Védelmi Minisztériumában jelenik meg. Az akadémiai intézményekben is feltűnő.
Ezek a nagy programok vagy szervezetek a V-t a legfelső szintű végrehajtási folyamat részeként használják. Az általános munkafolyamat hét fázisból áll:
A folyamat a V bal oldalán kezdődik, ahol (1) fogalmakat generálnak. Ezután (2) a teljes rendszerre vonatkozó követelményeket meghatározzák, dekomponálják és kiosztják. Ezután (3) részletesen megtervezik a rendszerelemeket.
A V alján (4) történik a megvalósítás. Itt jönnek létre a tervezett komponensek a folyamat korábbi szakaszában megfogalmazott követelményeknek megfelelően.
A V jobb oldalán felfelé haladva ezeket a komponenseket (5) integrálják a végleges rendszerbe. Az integrált rendszert ezután ellenőrzik, hogy megfelel-e az eredeti követelményeknek, és validálják, hogy megfelel-e a felhasználói igényeknek (6). Végül (7) a rendszert átadják és karbantartják.
A V kihívásai
A V folyamat végrehajtása sok nagy projekt esetében problémásnak bizonyul – különösen azoknál, amelyek szoftvereket tartalmaznak.
Integráció
Az egyik fő probléma az, hogy az integráció túl későn történik a fejlesztési folyamatban. A V-re támaszkodó programok megvárják, amíg a szoftverkomponensek elkészülnek, hogy csökkentsék a költséges integrációs utómunkálatokat.
A szoftverkomponensek manuális integrációja rengeteg időt vesz igénybe. Mindannyian tudjuk, hogy a valóság az, hogy a szoftver sosincs kész. A végére hagyott integrációs tevékenységeket siettetik a program ütemtervének betartása érdekében.
A V-ben az integrált komponensek általában megfelelnek a funkcionális követelményeknek, de gyakran nem biztonságosak, biztonságosak vagy helyesek.
Verifikáció & Validálás
A verifikáció és validálás (V&V) elvégzésével megvárni a rendszer teljes integrációját, tovább súlyosbítja ezt a problémát. A javítások végrehajtása hullámzást okoz az egész rendszerben, ami kihívássá és költségessé teszi a V&V során felmerülő problémák kezelését.
A programok gyakran “rendszerszintű” javításokat vezetnek be ahelyett, hogy a probléma gyökerét oldanák meg – ez egy sebtapaszos megközelítés. A szoftverek kockázatát gyakran olyan gyakorlatokkal csökkentik, mint a rendszerszintű tűzfalak és vírusirtó szoftverek, ahelyett, hogy a kódban kezelnék azt.
A tapaszok csökkentik annak az esélyét, hogy a felhasználók találkoznak a hibával, de magát a hibát nem javítják ki, és az továbbra is ott lappang a rendszerben.
A kihívásnak való megfelelés
Nem a rendszertechnika V-ben szereplő fogalmak jelentik a problémát – a V szerkezete az, ami nem alkalmazható a szoftverekre
A modern technikák lehetővé teszik a szoftverek folyamatos integrálását, akár nagy programok esetében is. A korai integrációt és verifikációt magába foglaló eszközök és folyamatok használata nem negligálja a V alapkoncepcióit – továbbfejlesztik a V-t, hogy az a szoftverfejlesztésben is működjön.
A végeredmény egy olyan szoftver, amely a létrehozáskor helyes, és egy olyan rendszer, amely olcsóbb, biztonságosabb és gyorsabban szállítható.