Systemingenjörer har länge betraktat V som en grundläggande del av god teknik. På senare tid har dock V:et för systemteknik fått ett dåligt rykte. Den nya generationen ingenjörer ser det som en symbol för långsamma vattenfallsmetoder. De anser att dessa metoder är irrelevanta för den hastighet som krävs för programvaruutveckling.
Traditionella ingenjörsförespråkare föredrar V:et framför ”agila” metoder. Detta är särskilt sant när det gäller kritiska system.
Vem ska vi tro?
Nja, om vi ska vara ärliga, när V:et existerar som ett enda härligt pass för ett helt system har den nya generationen en bra poäng. V kan verkligen bromsa bra mjukvaruutveckling.
I sin kärna är Systems Engineering V en logisk konstruktion. Den beskriver upptäckten av systemkrav genom att bryta ner ett system i mindre delar och sedan sätta ihop och validera dessa delar.
Systemingenjörer tillämpar V:et i olika sammanhang. Oftast förekommer V i stora organisationer, t.ex. det amerikanska försvarsdepartementet. Det är också framträdande i akademiska institutioner.
Dessa stora program eller organisationer använder V som en del av sin exekveringsprocess på högsta nivå. Det allmänna arbetsflödet har sju faser:
Processen startar på vänster sida av V:et där (1) koncept genereras. Därefter definieras, dekomponeras och allokeras (2) krav för hela systemet. Därefter (3) utformas systemkomponenterna i detalj.
Implementeringen sker längst ner på V:et (4). Här skapas de utformade komponenterna i enlighet med kraven från tidigare i processen.
Om man rör sig uppåt på den högra sidan av V:et integreras dessa komponenter (5) tillsammans till det slutliga systemet. Det integrerade systemet verifieras sedan för att säkerställa att det uppfyller de ursprungliga kraven och valideras för att säkerställa att det uppfyller användarens behov (6). Slutligen (7) levereras och underhålls systemet.
Utmaningar med V
Uppförandet av V-processen visar sig vara besvärligt för många stora projekt – särskilt de som inkluderar mjukvara.
Integration
Ett av de största problemen är att integrationen sker för sent i utvecklingsprocessen. Program som förlitar sig på V väntar tills programvarukomponenterna är färdiga för att minska det kostsamma integrationsarbetet.
Den manuella integrationen av programvarukomponenter tar enormt mycket tid. Den verklighet som vi alla vet är att programvaran aldrig är färdig. Integrationsaktiviteter som lämnas till slutet skyndas på för att hålla programtidtabellen.
I V uppfyller de integrerade komponenterna vanligen funktionskraven, men misslyckas ofta med att vara säkra, trygga eller korrekta.
Verifiering &Validering
Att vänta tills systemet har integrerats fullständigt för att genomföra verifiering och validering (V&V) förvärrar detta problem. Genomförandet av korrigeringar orsakar krusningar i hela systemet, vilket gör det utmanande och kostsamt att ta itu med problem som uppstår under V&V.
Programmen inför ofta korrigeringar på ”systemnivå” i stället för att lösa roten till problemet – ett plåster på såren. Programvarurisker minskas ofta genom metoder som brandväggar på systemnivå och antivirusprogram i stället för att åtgärda dem i koden.
Skyddslösningar minskar risken för att användarna stöter på felet, men felet i sig åtgärdas inte utan fortsätter att ligga på lur i systemet.
Möta utmaningen
Begreppen i systemteknikens V är inte problemet – det är V:s struktur som inte gäller för programvara
Moderna tekniker kan möjliggöra kontinuerlig integrering av programvara, även på stora program. Användning av verktyg och processer som omfattar tidig integration och verifiering förnekar inte V:s kärnkoncept – de förbättrar V så att det fungerar för mjukvaruutveckling.
Slutresultatet är en mjukvara som är korrekt vid skapandet och ett system som är billigare, säkrare och snabbare att leverera.