De uitdaging van de Systems Engineering V

Don Barrett, PMP, CSEP

Volg

9 okt, 2019 – 4 min read

Systems engineers hebben de V lang gezien als een fundamenteel onderdeel van goed engineering. De laatste tijd heeft de V van systeemengineering echter een slechte naam gekregen. De nieuwe generatie ingenieurs ziet de V als een symbool voor langzame, waterval engineeringpraktijken. Zij beschouwen deze praktijken als irrelevant voor de snelheid die nodig is voor software ontwikkeling.

Traditionele voorstanders van engineering prefereren de V boven “agile” methoden. Dit geldt vooral als het gaat om kritieke systemen.

Wie moeten we geloven?

Wel, als we eerlijk zijn, als de V bestaat als één glorieuze pas voor een heel systeem, heeft de nieuwe generatie een geweldig punt. De V kan de ontwikkeling van goede software echt vertragen.

In de kern is de Systems Engineering V een logische constructie. Het beschrijft de ontdekking van systeemeisen door een systeem op te splitsen in kleinere delen en deze delen vervolgens samen te voegen en te valideren.

Systeemingenieurs passen de V in verschillende contexten toe. De V komt het meest voor in grote organisaties, zoals het Amerikaanse Ministerie van Defensie. Het is ook prominent aanwezig in academische instellingen.

Deze grote programma’s of organisaties gebruiken de V als onderdeel van hun top-level uitvoeringsproces. De algemene workflow bestaat uit zeven fasen:

Het proces begint aan de linkerkant van de V waar (1) concepten worden gegenereerd. Vervolgens worden (2) vereisten voor het gehele systeem gedefinieerd, uitgesplitst en toegewezen. Vervolgens worden (3) systeemcomponenten in detail ontworpen.

Implementatie vindt plaats aan de onderkant van de V (4). Dit is waar de ontworpen componenten worden gecreëerd volgens de eisen van eerder in het proces.

Volgend naar de rechterkant van de V, worden deze componenten (5) samen geïntegreerd in het uiteindelijke systeem. Het geïntegreerde systeem wordt vervolgens geverifieerd om er zeker van te zijn dat het voldoet aan de oorspronkelijke eisen en gevalideerd om er zeker van te zijn dat het voldoet aan de behoeften van de gebruiker (6). Tenslotte (7) wordt het systeem opgeleverd en onderhouden.

Uitdagingen van het V

Het uitvoeren van het V-proces blijkt voor veel grote projecten lastig te zijn – vooral voor projecten die software bevatten.

Integratie
Een groot probleem is dat integratie te laat in het ontwikkelingsproces plaatsvindt. Programma’s die op de V vertrouwen wachten tot softwarecomponenten compleet zijn om kostbaar integratie-herwerk te beperken.

Handmatige integratie van softwarecomponenten kost enorm veel tijd. De realiteit waarvan we allemaal weten dat die waar is, is dat software nooit af is. Integratieactiviteiten die tot het eind worden uitgesteld, worden gehaast om het programmaschema te halen.

In de V voldoen geïntegreerde componenten meestal aan de functionele eisen, maar zijn vaak niet veilig, beveiligd of correct.

Verificatie & Validatie
Wachten tot het systeem volledig is geïntegreerd om verificatie en validatie (V&V) uit te voeren, verergert dit probleem. Het doorvoeren van fixes veroorzaakt rimpelingen in het hele systeem, waardoor het een uitdaging en kostbaar wordt om problemen aan te pakken die zich voordoen tijdens V&V.

Programma’s voeren vaak fixes op ‘systeemniveau’ door in plaats van het probleem bij de wortel op te lossen – een pleisteraanpak. Softwarerisico’s worden vaak beperkt door firewalls op systeemniveau en antivirussoftware in plaats van ze in de code aan te pakken.

De lapmiddelen verkleinen de kans dat gebruikers op de fout stuiten, maar de fout zelf wordt niet hersteld en blijft in het systeem sluimeren.

De uitdaging aangaan

De concepten in de Systems Engineering V zijn niet het probleem – het is de structuur van de V die niet van toepassing is op software

Moderne technieken kunnen continue integratie van software mogelijk maken, zelfs bij grote programma’s. Het gebruik van hulpmiddelen en processen die vroege integratie en verificatie omarmen, ontkennen de kernconcepten van de V niet – ze verbeteren de V zodat deze werkt voor softwareontwikkeling.

Het eindresultaat is software die correct is bij de creatie, en een systeem dat goedkoper, veiliger en sneller te leveren is.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.