Systemingeniører har længe set V’et som en grundlæggende del af god ingeniørkunst. På det seneste har det systemtekniske V dog fået et dårligt ry. Den nye generation af ingeniører ser det som et symbol på langsommelig, vandfaldsagtig ingeniørpraksis. De mener, at disse metoder er irrelevante i forhold til den hastighed, der er nødvendig for softwareudvikling.
Traditionelle ingeniørforkæmpere foretrækker V’et frem for “agile” metoder. Det gælder især, når det drejer sig om kritiske systemer.
Hvem skal vi tro?
Jamen, hvis vi skal være ærlige, når V’et eksisterer som ét herligt pas for et helt system, så har den nye generation en god pointe. V’et kan virkelig bremse god softwareudvikling.
I sin kerne er Systems Engineering V’et en logisk konstruktion. Det beskriver opdagelsen af systemkrav ved at bryde et system ned i mindre dele og derefter samle og validere disse dele.
Systemingeniører anvender V’et i forskellige sammenhænge. Oftest optræder V’et i store organisationer, som f.eks. det amerikanske forsvarsministerium. Det er også fremtrædende i akademiske institutioner.
Disse store programmer eller organisationer bruger V’et som en del af deres eksekveringsproces på højeste niveau. Den generelle arbejdsgang har syv faser:
Processen starter på venstre side af V’et, hvor (1) der genereres koncepter. Dernæst defineres (2) krav til hele systemet, dekomponeres og allokeres. Derefter (3) designes systemkomponenterne i detaljer.
Implementeringen sker nederst i V’et (4). Her oprettes de designede komponenter i overensstemmelse med kravene fra tidligere i processen.
Ved at bevæge sig opad i højre side af V’et integreres disse komponenter (5) sammen til det endelige system. Det integrerede system verificeres derefter for at sikre, at det opfylder de oprindelige krav, og valideres for at sikre, at det opfylder brugernes behov (6). Endelig (7) leveres og vedligeholdes systemet (7).
Udfordringer ved V
Udførelsen af V-processen viser sig at være besværlig for mange store projekter – især dem, der omfatter software.
Integration
Et af de største problemer er, at integrationen sker for sent i udviklingsprocessen. Programmer, der er afhængige af V, venter, indtil softwarekomponenterne er færdige, for at reducere det dyre genarbejde med integrationen.
Manuel integration af softwarekomponenter tager enormt meget tid. Den virkelighed, som vi alle ved er sand, er, at software aldrig er færdig. Integrationsaktiviteter, der er overladt til slutningen, bliver hastet for at overholde programtidsplanen.
I V opfylder de integrerede komponenter normalt de funktionelle krav, men ofte er de ikke sikre, sikre eller korrekte.
Verifikation & Validering
At vente med at udføre verifikation og validering (V&V), indtil systemet er fuldt integreret, forværrer dette problem. Implementering af rettelser forårsager krusninger i hele systemet, hvilket gør det udfordrende og dyrt at løse problemer, der opstår under V&V.
Programmer indfører ofte rettelser på “systemniveau” i stedet for at løse roden til problemet – en lappeløsning. Softwarerisikoen afbødes ofte ved hjælp af praksis som f.eks. firewalls på systemniveau og antivirusprogrammer i stedet for at løse den i koden.
Sikringsmidler mindsker chancen for, at brugerne støder på fejlen, men selve fejlen bliver ikke rettet og fortsætter med at lure i systemet.
Mød udfordringen
Begreberne i V’et for systemteknik er ikke problemet – det er V’ets struktur, der ikke gælder for software
Moderne teknikker kan muliggøre kontinuerlig integration af software, selv på store programmer. Brug af værktøjer og processer, der omfatter tidlig integration og verifikation, negerer ikke V’s kernekoncepter – de forbedrer V’et, så det fungerer for softwareudvikling.
Det endelige resultat er software, der er korrekt ved oprettelsen, og et system, der er billigere, mere sikkert og hurtigere at levere.