ROBUUSTHEID VAN SOFTWARE ENGINEERING DOOR MIDDEL VAN HYPER-AUTOMATISERING

AUTOMATISERING OP HOOG NIVEAU: HYPER-AUTOMATISERING

HIGHLIGHTS

• “Robuuste engineering” is erop gericht producten te creëren die van hoge kwaliteit, betrouwbaar en kosteneffectief zijn [1.][2.].
• De snelheid van softwareontwikkeling moet omhoog.
• De behoefte aan Software engineers groeit 5–10x sneller dan de wereldbevolking.
• Groei door alleen maar meer engineers aan te nemen is een anti-patroon voor Robuustheid en Software Kwaliteit.
• Wij zien Hyper-automatisering als de belangrijkste onderscheidende factor in het software-engineeringproces en geloven dat robuustheid niet kan worden bereikt zonder hyper-automatisering.

Robuuste engineering is erop gericht producten te creëren die bestand zijn tegen variaties in hun omgeving en gebruik en welke tevens van hoge kwaliteit, duurzaam, betrouwbaar en kosteneffectief zijn.

ROBUUSTHEID

De Taguchi-methode is een populaire benadering van robuuste engineering. De methode werd na de Tweede Wereldoorlog ontwikkeld door Dr. Genichi Taguchi en wordt door veel bedrijven over de hele wereld gebruikt om de product kosten te verlagen, de kwaliteit te verbeteren en de ontwikkelingstijd te verkorten.

De snelheid van softwareontwikkeling is één van de overlevingsfactoren van bedrijven geworden om zich te onderscheiden van de concurrentie. Groeiende softwarestacks, snellere product leveringen, groeiende behoefte aan functies, en een sneller personeelsverloop van ingenieurs, stellen steeds hogere eisen aan het softwareontwikkelingsproces.

Wij zien hyper-automatisering als de belangrijkste onderscheidende factor in het software-engineeringproces. Het maakt een strategie mogelijk om fouten zo vroeg mogelijk in het ontwikkelproces te voorkomen, door het gebruik van formele modelleringstalen, het genereren van code en geautomatiseerde verificatie en validatie. Wij geloven dat onze klanten met hyper- automatisering de robuustheid van de softwaresystemen die zij ontwikkelen aanzienlijk kunnen verbeteren.

AUTOMATISERING

In het algemeen proberen we met automatisering een proces te versnellen en waarde te verhogen. Het zorgt voor kortere feedbackloops en minder menselijke fouten in werk met repetitieve stappen, met een hogere kwaliteit en robuustheid tot gevolg.

We kunnen automatisering zowel in de primaire waarde stroom toepassen (het bouwen van het product) als in de secundaire waarde stroom (het bouwen van de ontwikkelomgeving).

Er zijn twee algemeen gebruikte strategieën om waarde te verhogen:

Vergroot het aantal engineers dat waarde creëert.
Deze strategie raden we af omdat dit hooguit een oplossing is voor de korte termijn. Ook is dit een erg dure oplossing omdat er voor elke engineer kosten moeten gemaakt worden voor het rekruteren en stroomlijnen van processen, en er blijvend kosten gemaakt moeten worden voor educatie, licenties, tooling e.d.

Vergroot de hoeveelheid waarde creatie per engineer.
Dit heeft onze voorkeur waarbij we zien dat vooral in de secundaire waarde stroom extra veel waarde toegevoegd kan worden door middel van automatisering.

Bij traditionele R&D investeringen is het doel om bij een jaarlijkse investering van X Euro daar elk jaar Y Euro aan waarde uit terug te krijgen maar meestal wordt dit niet gerealiseerd. De ROI op een R&D investering daalt meestal bij een gelijkblijvende jaarlijkse investering.

Dit patroon kunnen we doorbreken met behulp van Hyper-automatisering.

R&D Spend vs ROI (reality)

WAAROM AUTOMATISERING ALLEEN NIET GENOEG IS

Er zijn een aantal belangrijke mondiale trends die ons aanzetten om ‘meer’ te doen:

• Time-to-Market.
  Het te laat betreden van de markt heeft een verlies in marktpositie tot gevolg.
• Toenemende handhaving van regelgeving.
  De huidige regelgeving vereist dat de kwaliteit, duurzaamheid en robuustheid van onze producten verbeterd moeten worden. Acceptabele kwaliteit van gisteren is vandaag de dag niet langer acceptabel.
• De Software-Explosie.
  De software in producten worden steeds belangrijker en omvangrijker. Adobe Photoshop bijvoorbeeld bestond uit 10 duizend regels code in 1990 en maar liefst 4.5 miljoen regels in 2020.
• Toenemende domein complexiteit.
  Voor het domein van de deeltjesfysica zijn steeds complexere systemen nodig, zoals het CERN.
• Toename van de historische complexiteit.
  Bij een systeem zoals een serverrek wordt er in de loop der jaren steeds meer aan toegevoegd, waardoor het onoverzichtelijk dreigt te worden.
• De wereld biedt niet voldoende talent om aan de vraag naar Software engineers te voldoen.
  De behoefte aan Software-engineers groeit 5–10x sneller dan de wereldbevolking [3.]. Dit betekent dat we niet kunnen blijven schalen met het aantal software- engineers.

Verwachte aantal benodigde software engineers

DAXX [3.]

Daarnaast gaat een groei in het aantal software engineers ten koste van de robuustheid:

• Mensen maken fouten, dus een verdubbeling van het aantal mensen verdubbelt ook het aantal fouten (denk aan het begrip ‘maandagochtendauto’ [4.].
• We weten dat er gemiddeld per duizend regels code een X aantal fouten gemaakt worden. Verdubbeling van de code betekent dus ook een gemiddelde verdubbeling van het aantal fouten.
• Groei van een organisatie veroorzaakt groeipijn op het gebied van management en van het integreren/trainen van de nieuwe engineers in de bedrijfscultuur en werkwijze, met een meetbare verlaging in snelheid en kwaliteit tot gevolg.

We kunnen hieruit concluderen dat het alleen maar groeien met het aantal software-engineers een anti-patroon is voor robuustheid en software kwaliteit.

Als we naar het V-model kijken, zien we dat automatisering momenteel voornamelijk aan de rechterzijde plaatsvindt [5.].

Denk aan statische code checks, test- en bouwactiviteiten die geautomatiseerd worden waarvoor Quality gates worden ingericht.

Hierbij wordt echter voorbijgegaan aan alle andere aspecten zoals de eerdergenoemde trends en de groei in kennis en de organisatie waar engineers mee te maken krijgen.

Het is belangrijk dat een bedrijf blijft focussen op hun kernactiviteiten en alle context activiteiten bij voorkeur (hyper-)automatiseert zodat de eigen engineers zich niet bezig hoeven te houden met het eigen maken van nieuwe tools, technieken en standaarden en zich kunnen concentreren op het bouwen van het product.

Hyper-automatisering V-model

HYPER-AUTOMATISERING

Door middel van het verschuiven van een (gedeelte) van het R&D budget naar hyper-automatisering kunnen we dit ombuigen naar een stijging van de ROI.

ROI met hyper-automatisering

Met hyper-automatisering van tools en middelen voor de primaire waarde stroom, zorgt hyper-automatisering ervoor dat engineers zich kunnen focussen op hun kernactiviteiten en steeds sneller hun waarde kunnen opleveren.

Om het verschil uit te leggen tussen automatisering en hyper-automatisering nemen we het voorbeeld van een shuttlebus op een vliegveld die passagiers van en naar hun vliegtuig brengt.

Eén van de kerntaken van een vliegveld is om de passagiers van en naar het vliegtuig te brengen. Dit is een dynamisch proces omdat op het laatste moment pas duidelijk is op welke landingsbaan het vliegtuig zal landen. Het vliegveld moet de geüpdatete dienstregeling constant communiceren naar de bus en de buschauffeur moet zich houden aan wetgeving, zoals het in bezit zijn van een bus rijbewijs en het hebben van domeinkennis van het vliegveld (waar te rijden, op welke tijden, de lokale regels e.d.).

Door automatisering van dit proces kan het efficiënter gemaakt worden en geeft het de passagiers een betere en veiligere ervaring. De dienstregeling kan constant geüpdate worden op het scherm van de chauffeur en tractie control en remmen kunnen (deels) geautomatiseerd worden. De passagierservaring zal echter nog steeds verschillen per busrit door het verschil in rijstijl van de chauffeur en het vliegveld moet veel investeren in het voortdurend bijscholen en her certificeren van chauffeurs.

Door middel van hyper-automatisering verbergen we alle contextuele domeinkennis (rijvaardigheid, wetgeving e.d.) en krijgen we een autonoom rijdende shuttlebus. De ervaring voor de passagiers is nu hetzelfde voor elke rit en alle domeinkennis van het ‘besturen van een bus’ ligt nu bij de organisatie die de autonoom rijdende shuttlebus bouwt, en niet langer bij het vliegveld.

Automatisering en hyper-automatisering

Dit is vergelijkbaar met de verschuiving in ander industrieën, zoals bijvoorbeeld bij autofabrikanten. Zij huren geen lassers meer in, maar deze worden ingehuurd door de lasrobotfabrikant. De autofabrikanten kopen de lasrobots.

Waarde verhoging door hyper-automatisering

Door te hyper-automatiseren hebben engineers meer ‘tijd’ om aan kernactiviteiten te werken en dus waarde toe te voegen. Menselijke fouten worden verminderd hetgeen de kwaliteit, robuustheid en Time-to-Market ten goede komen.

De traditionele aanpak om de waarde per engineer te verhogen is om steeds meer standaarden en generieke/COTS tools toe te voegen in het software ontwikkelproces, welke software- engineers moeten leren beheersen. Dit vereist meer kennis en opleiding voor elke engineer. Niet elke engineer zal dit even gemakkelijk en snel beheersen wat vaak te herkennen is aan het feit dat er binnen de organisatie dan gefocust wordt op ‘senior’ engineers die in het team nodig zijn om succesvol te kunnen worden.

Bij hyper-automatisering zien we een andere aanpak: Die van een op maat gemaakte omgeving met hyper- geschaalde automatisering met focus op toegevoegde waarde. De kennis en kunde die de engineers zouden moeten opdoen voor deze nieuwe tooling, wordt nu verborgen in het geautomatiseerde deel, waardoor we ook minder afhankelijk worden van senior-level engineers.

Hyper-automatisering passen we toe met de systeem denkmethode. Niet alleen aan de rechter kant van het V-Model passen we het toe, maar juist gedurende het gehele engineering proces waarbij met name aan de linker kant van het V-Model nog veel winst valt te behalen.

Onder hyper-automatisering vallen de volgende maatregelen:

• Model-Driven (Software) Engineering ondersteund door geautomatiseerde tools.
• Interfacemodellering en het genereren van interfacecodes, bijvoorbeeld met COTS-tools zoals ASD, Dezyne, CocoTech e.d.
• Generieke modellering en codegeneratie zoals U/Sys-ML, State Machine-modellering e.d.
• Het automatiseren van alle repetitieve taken om menselijke fouten te verwijderen en de snelheid te verhogen.
• Domein specifieke modellering en codegeneratie: Hyper- automatisering om domein specifieke kennis en vaardigheden te ‘verbergen’.

Al deze maatregelen hebben een effect op kwaliteit en het is belangrijk dat een organisatie niet valt voor de mythe dat er een afweging gemaakt moet worden tussen snelheid en kwaliteit. Uit empirische gegevens blijkt dat we code van hoge kwaliteit nodig hebben om snel te kunnen handelen [6.].

SAMENVATTEND

• Hyper-automatisering
  Automatiseer alle repetitieve taken (met behulp van experts/partners) en doe dit over het gehele engineering proces.
• “Get rid of bugs”
  Het is kosteneffectiever om bugs te voorkomen dan deze tijdens het testen op te sporen en te herstellen door bijvoorbeeld gebruik te maken van coderingsrichtlijnen, interfacemodellering en MD(S)E-initiatieven.
• “Shift Left” & Testen
  Het is belangrijk om niet alleen een goede agile testpiramidestrategie te implementeren [7.][8.][9.] maar een ‘Shift Left’ door te voeren naar de linkerkant van het V-Model.
• “Fail Fast / Early Feedback”
  Het is bekend dat korte feedbackcycli de kwaliteit verbeteren. Hogere kwaliteit betekent dat we in staat zijn te versnellen.
• Handhaving
  ‘Regels’ werken niet als ze niet worden gehandhaafd. Definieer en meet KPI’s voor het gebruik in quality gates, overal in het V-Model.

References:

1. “Robust Engineering: Learn How to boost Quality While Reducing Costs & Time to Market” by Genichi Taguchi, Subir Chowdhury, Shin Taguchi
2. “Robust Engineering” by Shin Taguchi\
3. DAXX, Feb 2020, https://www.daxx.com/nl/blog/ontwikkeling-trends/aantal-software-ontwikkelaars-developer-statistics
4. https://www.ensie.nl/betekenis/maandagmorgenexemplaar-maandagochtendexemplaar-maandagauto & https://topgear.nl/autonieuws/maandagochtendmodellen-bestonden-echt
5. https://en.wikipedia.org/wiki/V-model
6. Capers, Jones. Applied Software Measurement: Global Analysis of Productivity and Quality. 1996
7. 2022 Paper “Code Red: The Business Impact of Code Quality — A Quantitative Study of 39 Proprietary Production Codebases”
   Adam Tornhill (CodeScene) & Markus Borg (RISE Research Institutes of Sweden, Lund University Lund, Sweden). https://arxiv.org/abs/2203.04374v1
8. Mike Cohn, ‘Test Pyramid’ Succeeding with Agile, 2009
9. Agile testing: A practical guide for testers and agile teams