Categorie: Blogs

Kris van Rens kijkt naar de toekomst van systeemontwikkeling en hoe het geluk van ontwikkelaars een belangrijk aspect is van software engineering

Kunstmatige intelligentie in het algemeen en grote taalmodellen (LLM’s) in het bijzonder veranderen ontegenzeggelijk de manier waarop we werken en code schrijven. Vooral voor het leren, uitleggen, refactoren, documenteren en reviewen van code blijken ze erg nuttig te zijn.

Voor mij is het genereren van productiecode door een LLM in chatstijl echter nog steeds een twijfelgeval. De zorgvuldig ontworpen prompt voor een complexe, beperkte taak is vaak vele malen groter dan de resulterende code, waardoor ik de productiviteitswinst in twijfel trek. Soms betrap ik mezelf erop dat ik de prompt iteratief moet bevechten om de juiste code voor mij te genereren, om er vervolgens achter te komen dat de prompt terloops is vergeten om een van mijn eerdere vereisten te implementeren. Soms ook genereren de LLM’s code met ongeldige constructies: ze hallucineren antwoorden, steevast met veel zelfvertrouwen. Sterker nog, gezien de manier waarop LLM’s werken, kunnen de antwoorden compleet anders zijn elke keer dat je een soortgelijke vraag invoert of in ieder geval sterk afhankelijk zijn van de gegeven prompt.

OpenAI medeoprichter Andrej Karpathy verwoordde het goed: “In zekere zin is hallucinatie alles wat LLM’s doen. Het zijn droommachines.” Dit schijnbaar ‘zwarte magie’ gedrag van LLM’s is enigszins onverenigbaar met mijn innerlijke tech-gedreven drang om een deterministisch proces te volgen. Misschien komt het door mijn volslagen incompetentie in prompt engineering, maar van waar ik sta, ondanks de kracht van generatieve AI binnen handbereik, moeten we nog steeds absoluut begrijpen wat we doen in plaats van blindelings te vertrouwen op de juistheid van de code die door deze droommachines is gegenereerd. Het vreemde gevoel en de eigenaardigheid van LLM’s zullen in de toekomst waarschijnlijk slijten, maar ik wil nog steeds graag de code begrijpen die ik produceer en waar ik verantwoordelijk voor ben.

Waarschijnlijk zal AI in het algemeen een abstractieverschuiving mogelijk maken in toekomstige softwareontwikkeling, waardoor we op een hoger abstractieniveau kunnen ontwerpen dan we nu vaak doen. Dit zou op zijn beurt de noodzaak om handmatig code te schrijven kunnen verminderen. Toch zie ik niet in hoe het gebruik van gegenereerde code in productie goed zal werken zonder de correctheidsgaranties van rigoureus testen en formele verificatie – dit is niet de realiteit van vandaag.

Positief verschil

Een ander toepassingsgebied van LLM’s is in-line code voltooiing in een editor/IDE. Zelfs dit is voor mij geen onverdeeld succes. Meer dan eens ben ik overweldigd door de LLM-gebaseerde code completer die een multiline oplossing voorstelt van wat hij denkt dat ik wilde typen. In plaats van het code-idee direct uit mijn verbeelding te implementeren, lees ik een klodder gegenereerde suggestiecode en vraag ik me af wat het doet en waarom. Het is raak en mis met deze aanvullingen en ze zetten me vaak op het verkeerde been. Ik heb de laatste tijd geëxperimenteerd met ingebedde ontwikkeling voor microcontrollers en ik heb gemerkt dat vooral met code in deze context, de LLM-gebaseerde aanvulling gewoon gissingen doet, soms zelfs onbestaande GPIO (general-purpose IO) pinnummers verzint. Ik hou wel van de combinatie van code completion LLM’s met een AI-model dat editorbewegingen voorspelt voor refactoring. Refactoren zijn vaak reeksen van vergelijkbare kleine bewerkingen die de modellen goed kunnen voorspellen.

Een aspect van software-engineering waar LLM’s een algemeen positief verschil kunnen maken, is het interpreteren van compilerfeedback. C++ is bijvoorbeeld berucht om zijn moeilijk te lezen en vaak erg lange compilerfouten. De komst van concepten in C++20 zou hier voor een drastische verbetering moeten zorgen, maar ik heb het niet zien gebeuren. Misschien is dit nog werk in uitvoering, maar tot die tijd moeten we het doen met complexe en vaak lange foutmeldingen (soms zelfs honderden regels lang). Vanwege hun vermogen om compilerberichten te interpreteren of samen te vatten, gecombineerd met hun educatieve en generatieve functies, zijn LLM’s met een groot contextvenster geschikt om dergelijke feedback te verwerken, waardoor ze een geweldig hulpmiddel zijn voor C++ ontwikkelaars. Er is een enorme hoeveelheid reeds bestaande C++ code en documentatie om van te leren, wat een goede basis vormt voor het trainen van een LLM.

Andere nadelen van C++ zijn de steeds toenemende complexiteit van de taal en de neiging van de compiler om te vechten in plaats van te helpen. Effectief gebruik van LLM’s om deze problemen te bestrijden zou de taal op korte termijn kunnen redden. De evolutie van de C++-taal gaat langzaam, maar het potentieel van de tools is enorm. Gezien de enorme hoeveelheid bestaande C++ code die vandaag de dag in gebruik is, is de taal een blijvertje en elk hulpmiddel dat ontwikkelaars helpt ermee te werken wordt gewaardeerd.

Ontwikkelaarsgeluk

Het gebruik van LLM’s voor het genereren van code neemt voor mij ook een deel van het plezier in programmeren weg. Voor mij is het schrijven van code een zeer creatieve, leerzame en plezierige bezigheid, waarbij ik al doende mijn vaardigheden aanscherp; door een magische doos het werk voor mij te laten doen, gaat deze ervaring tot op zekere hoogte verloren – zelfs het handmatig schrijven van de saaie stukken en de tests heeft enige leerzame waarde.

Collega-ontwikkelaar Ger Cloudt beweert in zijn werk over softwarekwaliteit dat organisatorische kwaliteit, waarvan ontwikkelaarsgeluk een onderdeel is, het halve verhaal is. Volgens hem is organisatorische kwaliteit de sleutel tot ontwerp-, code- en productkwaliteit. Natuurlijk, schone code en architectuur zijn belangrijk, maar zonder de juiste hulpmiddelen, mentaliteit, cultuur, opleiding enzovoort, zal het ontwikkelingsproces uiteindelijk tot stilstand komen.

LLM’s helpen ongetwijfeld op het gebied van tools en opleiding, maar er komt meer kijken bij programmeren dan alleen code produceren als een robot. Een deel van het ambacht van software engineering – zoals bij elk ambacht – is het ervaren van plezier en trots in je werk en de resultaten die je produceert. Ik vind het maar raar, maar het geeft me enorm veel voldoening om met mijn eigen handen mooie code te maken.

Ondanks een groot aantal opkomende alternatieven is C++ nog steeds een kracht om rekening mee te houden, zeker in de door legacy geplaagde high-tech industrie. In een serie artikelen plaatst High Tech Institute trainer Kris van Rens de taal in een modern perspectief. In onze nieuwe 4-daagse training laat Kris van Rens deelnemers kennismaken met de basisprincipes van de taal en essentiële best practices.

Om de paar jaar worden C en C++ doodverklaard. Onlangs verklaarde Microsoft Azure CTO Mark Russinovich publiekelijk dat ze afgeschreven zouden moeten worden ten gunste van Rust. Hoewel dit op persoonlijke titel is geuit, is het een interessant standpunt voor iemand van Microsoft, dat een enorme C++ codebase heeft en veel actieve leden in de C++ commissie.

Hoe dan ook, C en C++ zijn nog steeds springlevend – elk de lingua franca van veel industriële softwareontwikkelomgevingen. Toch is Rust tegenwoordig blijkbaar de ‘place to be’ in systeemprogrammeerland. Wat maakt deze taal zo aantrekkelijk? Laten we het eens bekijken vanuit het perspectief van C++.

Opmerkelijke verschillen

Ten eerste biedt Rust een duidelijk en objectief voordeel ten opzichte van C++: gegarandeerde geheugenveiligheid voor het gecompileerde resultaat. In wezen ruilt Rust compilatietijd (en compilercomplexiteit) voor een veiligere runtime. De compiler zal zichzelf proberen te bewijzen dat de code die je hem geeft geheugenveilig is, door gebruik te maken van zijn typesysteem en soms de hulp van de ontwikkelaar om dingen aan te geven zoals afhankelijkheden van variabele of referentielevensduur.

Er zijn meerdere onafhankelijke beveiligingsonderzoeken uitgevoerd op grote C en C++ codebases waaruit is gebleken dat maar liefst 70 procent van alle bugs en beveiligingsproblemen te maken heeft met geheugenveiligheid. In het licht hiervan lijkt het inruilen van compileertijd voor een geheugenveilige runtime een no-brainer. Het schrijven van C++ van hoge kwaliteit met behulp van de juiste tools, tests, best practices en compiler sanitizers kan u daar ook brengen, maar het biedt geen harde garanties vanaf het begin. De ‘vangrails’ die Rust implementeert om u te beschermen tegen jezelf in de voet schieten kunnen soms complex of zelfs irritant zijn, maar denk eens aan de aanzienlijke voordelen die een runtime geheugenveiligheidsgarantie met zich meebrengt voor het programmeren van gelijktijdige software.

Een ander opmerkelijk verschil met C++ is de manier waarop Rust de afhandeling van fouten en functieresultaatwaarden integreert. In tegenstelling tot C++ heeft het geen uitzonderingen; het biedt mechanismen om met fouten om te gaan met behulp van reguliere controlestroom. Resultaatwaarden moeten worden verwerkt, wat de ontwikkelaar dwingt om foutafhandeling te implementeren en onjuiste code te voorkomen, dus fouten of uitzonderingen vliegen zelden onder de radar. Als het tijdens runtime echt misgaat – bijvoorbeeld als het geheugen uitgeput raakt – zal Rust een zogenaamde panic genereren, een fatale fout, waardoor de thread in kwestie stopt (wat netjes afgehandeld kan worden).

De Rust compiler, gebouwd bovenop de LLVM compiler back-end, is duidelijk erg pedant, om geheugenveiligheid en correctheid van code te handhaven, maar tegelijkertijd erg behulpzaam. Beschouw het als een koppel programmeurs, die over je schouder meekijkt en leesbare foutmeldingen geeft, en zelfs mogelijke oplossingen voorstelt. Afgezien van de compiler, draait het grootste deel van het ecosysteem van Rust rond Cargo, dat een buildsysteem, een pakket- en afhankelijkheidsmanager en nog veel meer is, alles in één. Ondanks de overvloed aan pakketbeheerders, bouwsystemen en andere tools die beschikbaar zijn voor C++, kan het opzetten van een serieus C++ project nog steeds een lastige klus zijn.

Omdat Rust relatief jong is, heeft het de luxe gehad om meer dan 40 jaar taalontwikkeling te verwerken in zijn syntaxis en structuur. Veel van de inspiratie is gehaald uit zowel imperatieve talen als C++ en functionele talen als Haskell en Scheme. Dit geeft het het subjectieve voordeel van een zeer ‘modern’ gevoel. Bovendien zijn veel dingen in Rust expressies, wat zorgt voor meer flexibiliteit in de codenotatie.

In mijn vorige bijdrage heb ik betoogd dat de gebruikersbasis van een programmeertaal van het grootste belang is. Rust, met hulp van de Rust Foundation, bouwt geleidelijk aan deze gebruikersbasis, zoals kan worden afgeleid uit vele indicatoren, zoals de Tiobe-index en het Stack Overflow-onderzoek, en door de adoptie van Rust in de Linux v6.1 kernel – geen geringe prestatie. Naarmate meer en meer beveiligingsrapporten melding maken van netto positieve effecten die sterk gerelateerd zijn aan het gebruik van geheugenveilige talen zoals Rust, zal de gebruikersbasis blijven groeien. Elke aanwijzing (geen woordspeling bedoeld) lijkt te wijzen op een mooie toekomst voor Rust.

Niet alles rozengeur en maneschijn

Moeten we dan gewoon C en C++ afschrijven ten gunste van Rust? Naar mijn mening is dit een valse dichotomie. Waarom zouden we moeten kiezen tussen het een of het ander? Als software-ingenieurs moeten we het juiste gereedschap voor de klus gebruiken.

Migreren naar Rust is ook niet allemaal rozengeur en maneschijn. Als je een grote hoeveelheid bestaande C++ code hebt, zal Rust niet direct helpen, tenzij je bereid bent om C API’s te gebruiken voor interactie. Er zijn tools voor C++-niveau interoperabiliteit, maar deze staan nog in de kinderschoenen. U kunt natuurlijk ook uw code herschrijven, maar dat zal niet eenvoudig zijn, vooral niet als u zwaar leunt op geavanceerde sjablonen. En als je vertrouwt op absolute maximale prestatie-eisen, is safe Rust daar misschien (nog?) niet op berekend. Bovendien, in strengere omgevingen zoals de auto- of luchtvaartindustrie, schrijven standaarden vaak het gebruik van een formeel gespecificeerde programmeertaal voor, wat Rust op dit moment niet is.

Het beste advies is om je niet vast te pinnen op één programmeertaal. Het leren van meerdere talen is over het algemeen echt nuttig en zal uw competentie, stijl en kennis verbeteren in elke taal die u beheerst. Kijk dus eens naar C++, Rust en andere alternatieven om je perspectief te verbreden – of gewoon voor de lol.

Ondanks een groot aantal opkomende alternatieven is C++ nog steeds een kracht om rekening mee te houden, zeker in de door legacy geplaagde high-tech industrie. In een serie artikelen plaatst High Tech Institute trainer Kris van Rens de taal in een modern perspectief. In onze nieuwe 4-daagse training laat Kris van Rens deelnemers kennismaken met de basisprincipes van de taal en essentiële best practices.

“Er zijn maar twee soorten programmeertalen: de talen waar mensen over klagen en de talen die niemand gebruikt.” Dit is een beroemde uitspraak van Bjarne Stroustrup, de bedenker van C++. Er zitten een paar waarheden in verborgen.

Ten eerste en meest voor de hand liggend: geen enkele programmeertaal is perfect voor het oplossen van elk probleem in elk domein. Vooral wanneer een taal wordt aangeprezen als “universeel”, zoals C++, kan deze bijna overal worden toegepast, maar de kans is groot dat er een mismatch is tussen het gebruikte gereedschap en het vereiste gereedschap. Het is bijvoorbeeld heel goed mogelijk om een complete webapplicatie in C++ te schrijven, maar is het ook het juiste gereedschap voor deze taak? Persoonlijk zou ik zeggen van niet.

Dan, als een taal evolueert en veroudert, is het erg belangrijk dat er een duidelijk proces is om om te gaan met (brekende?) veranderingen. Een conservatieve en veilige aanpak is het handhaven van achterwaartse compatibiliteit vanaf de eerste stabiele release. Dit is de aanpak die C++ al tientallen jaren volgt en naleeft – wat helaas ook de adoptie van sommige taalverbeteringen blokkeert.

Nog een verborgen waarheid uit het openingscitaat: de gebruikersbasis is extreem belangrijk. Je kunt de mooiste, veiligste, veiligste en prettigste programmeertaal ooit ontwerpen. Maar wat heb je daaraan als maar een paar mensen het gebruiken?

Goede kanshebbers

Een goed model voor het belang van programmeertaal is een mechanisch vliegwiel; hoe groter de gebruikersbasis, hoe groter het vliegwiel en de rotatiesnelheid. De grootte van de gebruikersbasis wordt bepaald door het aantal actieve ontwikkelaars, bestaande codebases, onderlinge afhankelijkheid van afzonderlijke codebases en andere factoren zoals integratieondersteuning door derden. Voor C++ heeft dit vliegwiel tenminste nog een enorm momentum. Toch zijn er krachten aan het werk die dit momentum langzaam wegvreten. Andere talen op het gebied van systeemprogrammering zijn delen van de C++ gebruikersbasis aan het overnemen.

Eerder schreef ik over de aankondiging van de programmeertaal Carbon, een C++ opvolger gestart door Google, maar er zijn veel meer alternatieven. Sommige daarvan, zoals Zig, Odin en Go, zijn meer gericht op C dan op C++ – die ga ik hier niet behandelen. Verder sla ik, om pragmatisch te zijn, talen over die te klein of experimenteel zijn, zoals Nim, Val, Vale, Cpp2 en Jakt. Dan blijft er slechts een handvol ‘serieuze’ alternatieven over, waaronder Rust, Swift, D en Circle.

Wat maakt een taal een goede kanshebber voor grootschalige adoptie door gebruikers van C++? We kunnen beginnen met te kijken naar de eigenschappen waar C++ over het algemeen tekortschiet. Heeft het alternatief bijvoorbeeld een ‘moderne syntaxis’? Heeft het een soort ingebouwde gegarandeerde veiligheid, zoals veiligheid van geheugen of wiskundige bewerkingen? Wordt het geleverd met een tooling/packaging ecosysteem? C++ interoperabiliteit is een ander zeer belangrijk aspect. Een C-stijl foreign function interface (FFI) is leuk, maar het voelt als een downgrade als we onze C++ interfaces daaraan moeten aanpassen.

Het hebben van één van deze eigenschappen is echter niet genoeg. Een moderne en schone syntax is erg mooi, maar is op zichzelf niet genoeg. Een geweldig tooling ecosysteem is fantastisch maar, nogmaals, niet goed genoeg op zichzelf. Naar mijn mening, als je enige kans van slagen wilt hebben in C++, heb je op zijn minst de volgende drie ingrediënten nodig: een 10x verbetering op een bepaald aspect van de taal, gegarandeerde geheugenveiligheid en goede interoperabiliteit met bestaande C++ code.

De vakjes aanvinken

Als we kijken naar onze serieuze alternatieven, dan mist een taal als D de 10x verbetering. Daarom denk ik dat het nooit echt van de grond is gekomen, ook al is het al 20 jaar oud. Het eenmansproject Circle is erg indrukwekkend, vooral vanwege de experimenteermogelijkheden op het gebied van taalontwikkeling. En bovenal, met uitzondering van het nemen van feature flags om taalverbeteringen mogelijk te maken, is het volledig compatibel met C++. Helaas is Circle niet openlijk bestuurd en mist het gegarandeerde geheugenveiligheid. Swift wordt geleverd met uitstekende tooling, maar het is te veel gericht op het Apple-platform en het heeft slechts gedeeltelijke/werk-in-uitvoering interoperabiliteit met C++.

Rust voldoet aan de meeste eisen. Het heeft zelfs al een behoorlijke gebruikersbasis. Hoewel het ook echte, volwassen C++ interoperabiliteit mist, is het vandaag de dag de meest veelbelovende mededinger. Meer over Rust in mijn volgende bijdrage.

Ondanks een groot aantal opkomende alternatieven is C++ nog steeds een kracht om rekening mee te houden, zeker in de door legacy geplaagde high-tech industrie. In een serie artikelen plaatst High Tech Institute trainer Kris van Rens de taal in een modern perspectief. In onze nieuwe 4-daagse training laat Kris van Rens deelnemers kennismaken met de basisprincipes van de taal en essentiële best practices.

Afgelopen juli werd de programmeertaal Carbon officieel aangekondigd tijdens de CppNorth C++ conferentie in Toronto, Canada. Carbon wordt gepresenteerd als “een experimentele opvolger van C++” en is gestart als een open-source project, nota bene door Google. Wacht… Google gaat een C++-opvolger maken? Tot voor kort was het bedrijf sterk betrokken bij de ontwikkeling van de C++ taal en de ontwikkeling van de Clang C++ front-end voor de LLVM compiler. Met tienduizenden engineers binnen Google die werken aan miljarden regels code, lijkt het kiezen van een compleet nieuwe taal nogal gewaagd.

Waarom zou een enorm bedrijf als Google zich wagen aan zo’n gewaagd project? Nou, het is een symptoom van de staat en ontwikkeling van C++. Voor degenen die nog niet op de hoogte zijn van de evolutie van de taal in de afgelopen jaren: er zijn enkele grote discussies geweest. Natuurlijk is het voeren van discussies het hele doel van de C++ commissievergaderingen, maar één onderwerp duikt steeds weer op zonder dat er een oplossing voor is: of het al dan niet de moeite waard is om het taalontwerp te verbeteren ten koste van achterwaartse compatibiliteit.

Slanker bestuur

C++ bestaat nu ongeveer veertig jaar en wordt over de hele wereld gebruikt om prestatiegerichte software te maken. Na een periode van relatieve rust na de eerste ISO-standaardisatie in 1998, is de commissie er sinds 2011 in geslaagd om elke drie jaar grote verbeteringen door te voeren. Als gevolg daarvan is de taal heel anders geworden dan diegenen onder ons die oud genoeg zijn om er in de jaren negentig en negentig mee te werken. Alleen al de toevoeging van functies zoals concepten, bereiken en modules in C++20 is een krachtige slag.

Tegelijkertijd staat het evolutieproces van de C++ taal echter bekend als extreem uitdagend. Het gewicht van decennia aan technische schuld met behoud van achterwaartse compatibiliteit is aanzienlijk – te veel voor sommigen, lijkt het. Proberen om een belangrijke taalfunctie toe te voegen kan wel tien jaar aan lobbyen, discussies, reviews, testen, meer reviews en nauwgezette formulering kosten. Natuurlijk is het introduceren van aanzienlijke veranderingen in een project met zoveel belanghebbenden geen sinecure, maar tien jaar is in de huidige technische wereld letterlijk een mensenleven. Een andere uitdaging is dat het ISO comité overwegend westers is, met een zware ondervertegenwoordiging van grote Aziatische C++ gebruikers zoals India of China. Deze nadelen zien er niet goed uit, zeker niet in het licht van snelgroeiende, moderne, openlijk bestuurde (en relatief jonge) talen als Rust of Swift.

Sigasi uitbreiding voor Visual Studio Code

Sigasi kondigt de release aan van de VS Code Extension met uitgebreide ondersteuning voor SystemVerilog, Verilog en VHDL. Onze uitbreiding biedt functies en taalondersteuning zoals codenavigatie, projectbeheer, linting, codeopmaak, tooltips, outline, autocomplete, hover en nog veel meer!

Is de technische schuld van de C++ taal echt zo gigantisch dat het bijna onmogelijk is om nieuwe krachtige functies toe te voegen? Eenmansleger Sean Baxter van de Circle C++ compiler heeft aangetoond dat dit niet zo is. Alleen al in de afgelopen maanden heeft hij in zijn eentje aangetoond dat het mogelijk is om aanzienlijke functies toe te voegen, zoals een echt somtype en tuples op taalniveau. Toegegeven, een implementatie in een enkele compiler van een C++ dialect zonder een grondig herzien voorstel is verre van een officiële C++ taalfunctie, maar het laat in ieder geval zien hoeveel speelruimte en mogelijkheden er zijn in de syntaxis en de taal als geheel – als we er echt onze zinnen op zetten. Het laat ook zien dat de last van de technische schuld alleen niet de beperkende factor is in de taalontwikkeling.

Het bestuursmodel van C++ zal waarschijnlijk niet snel veranderen, omdat het zo verbonden is met het ISO-proces en de belanghebbenden van de commissie. Toch denk ik dat dit een zeer belangrijk moment is voor de taal om na te denken over haar positie in het universum van systeemprogrammering; ze kan de signalen niet langer negeren. Misschien zal een slankere bestuursstructuur helpen, of het toestaan van brekende veranderingen om de technische schuld in een toekomstige versie weg te werken – wie weet. Helaas zullen dergelijke substantiële wijzigingen in het proces waarschijnlijk ook jaren duren.

Afwachten

Zullen de nadelen ertoe leiden dat C++ binnenkort wordt afgeschaft? Nee, zeker niet. Het momentum van de bestaande code en gebruikers is overweldigend. ‘Gewoon’ overstappen naar een andere taal is niet voor iedereen een optie, zelfs niet voor Google. Daarvoor is echte interoperabiliteit met C++ (niet alleen C) nodig, en daar schieten alternatieven als Rust en Swift nog tekort. Niet voor niets adverteert Google met C++ interoperabiliteit als een belangrijk kenmerk van Carbon, waardoor het mogelijk wordt om de taal stap voor stap over te nemen vanuit een grote bestaande C++ codebase.

Op dit moment is Carbon echter niet veel meer dan een ruwe specificatie en een aankondiging. We zullen moeten afwachten of het aan de verwachtingen kan voldoen. In de tussentijd zal C++ ook evolueren, hopelijk positief geïnspireerd door de mogelijkheden van Circle en andere talen op dit gebied.

 

Daar, onder de parasol, pet, zonnebril, bier, dat moet onze minister-president zijn.
Als ik nog een biertje regel, mag ik er dan bij?

Bier is welkom en als je niet over politiek praat, mag je ook meedoen.

Afgesproken! Ik ben een politiek analfabeet. Ik geef hier een training en kan alleen een beetje praten over hightech systeemarchitectuur.

Klinkt interessant! Ik ben op heel wat handelsmissies geweest en ik weet dat Nederland daar een leidende rol speelt.

Dat doet het zeker! Ik heb de kans gehad om voor bedrijven te werken die konden voorspellen welk high-tech product ze binnen drie jaar op de markt moesten hebben en die geniale onderzoekers en uiterst bekwame ingenieurs aan het werk zetten om dat doel te bereiken.

Juist omdat er veel verschillende expertises nodig zijn om zo’n hightech product te ontwikkelen, te produceren en te onderhouden, ontstaat er een wirwar van tegenstrijdige eisen uit die veelheid van disciplines. Maar de succesvolle bedrijven onderscheiden zich doordat ze het ondanks deze wirwar eens kunnen worden over een aanpak en zo tijdig de juiste beslissingen kunnen nemen.

Dat moet inderdaad enorm ingewikkeld zijn. Maar gelukkig weten die knappe koppen en handige handen welke berekeningen en modellen ze moeten toepassen. In mijn werk passen we ook modellen toe, maar die zijn meer voer voor discussie dan dat ze leiden tot consensus en juiste beslissingen. Bij ons is het meer mensenwerk.

Er zijn meer overeenkomsten dan je zou denken. Alle experts in hightech zijn heer en meester in hun vakgebied en betreden vaak het podium om precies dat te laten zien: bèta superioriteit.

Aan de ene kant heb je de expertise, modellen en berekeningen hard nodig om ervoor te zorgen dat die professionals blijven innoveren in hun vakgebied en steeds diepere tunnels graven. En aan de andere kant wordt elk nieuw inzicht in een bepaald vakgebied gebruikt als wapen om experts uit andere tunnels de hersens in te slaan.

Er ontstaan eilanden, soms zelfs kampen, en de pest is dat ze allemaal een geldig punt hebben.

Oké, oké, dus het is ook mensenwerk. Maar je zei net dat ze wel tot een overeenkomst komen. Hoe doen ze dat dan?

Het draait allemaal om systeemarchitectuur. Ze maken werkafspraken – je kunt het een aanpak noemen – waarin de verschillende disciplines elkaar inzicht geven in waar zich in essentie de tegenstelling manifesteert en voor welke parameters een evenwichtige oplossing moet worden gevonden. Het gaat dus niet om onderhandelen of consensus proberen te bereiken, maar om het maken van gezamenlijk gewogen keuzes. Zodra ze allemaal het overzicht hebben en het eens zijn over het hele systeem, maken deze knappe koppen hun eigen tunnelwijsheid ondergeschikt aan, zeg maar, het hogere goed.

Check out the Sysarch training

Leuk dat het zo werkt in de hightech, maar hoe anders is het bij ons. Ongetwijfeld heb je debatten gezien waar mensen te druk zijn met het verkondigen van hun eigen partijwaarheid en niet bereid zijn om naar elkaar te luisteren, laat staan elkaar te begrijpen. Die systeemarchitectuur werkt niet bij ons.

Ik ga advocaat van de duivel spelen; die debatten hebben niet het gemeenschappelijke doel dat wel heerst binnen succesvolle bedrijven. In de debatten schittert het systeemdoel door afwezigheid.

Nee, daar kan het niet aan liggen. We hebben bijvoorbeeld een heel duidelijk doel gesteld voor de vermindering van stikstof: de helft minder in 2030. Hoe concreet wil je dan dat het doel is?

Hier raak je een fundamentele fout. Je ziet dat vermindering geen systeemdoel is. Dit is precies waar constructieve bedrijven verschillen van de politiek. Ik zal het uitleggen.

Het doel van het systeem omvat termen als voedselhoeveelheid, voedselkwaliteit, duurzame bedrijfsvoering en behoud van het milieu. Er is echter nog nooit een systeem ontwikkeld met als doel het verminderen van stikstof, en dat is precies waarom velen protesteren zodra je dat als doel stelt. Begrijp me niet verkeerd, ik ben geen klimaatwimp. Ik zie het teveel aan stikstofdepositie als een negatief effect dat moet worden opgelost.

Ik ben er vrij zeker van dat boeren, burgers en bedrijven het systeemdoel onderschrijven om op een duurzame manier voedsel te produceren in Nederland. Als je ze had uitgenodigd om dat systeemdoel te blijven nastreven terwijl het stikstofoverschot gerepareerd moet worden, dan had je coöperatieve denkers gekregen in plaats van tegendenkers. Het systeemdoel heeft altijd een gewenst effect en daarom willen de meeste mensen eraan meewerken.

Ik begrijp wat je bedoelt. Dus Nederland kan geregeerd worden door systeemarchitecten?

Gouverneur niet, maar zelfs politici zouden baat hebben bij praktijken en methoden zoals die binnen systeemarchitectuur:

''Proclaiming system goals results in solution supporters.''

''Proclaiming solutions results in aimless opponents.''

 

Dus we hebben het verknald?

In deze benadering zeker wel! Er zijn echter ook dingen verknoeid in de hightech, en missers zullen blijven bestaan, maar elke fout is een kans om te verbeteren. Hoe denk je dat systeemarchitectuur anders is ontstaan?

Je zou het trouwens niet over politiek hebben!

Dat deed ik niet, we hadden het alleen over beslissingen nemen.

High Tech Institute trainer Cees Michielsen belicht een handvol trends op het gebied van system requirements engineering. Voor High Tech Institute verzorgt hij meerdere keren per jaar de 2-daagse training‘System requirements engineering‘.

 

In de hightech wordt vaak verwezen naar het V-model als het gaat om het proces van eerste ideeën tot productimplementatie als het gaat om system requirements engineering. Dit model begint met een functionele uitsplitsing, de linkerpoot van de V. In de praktijk kun je echter niet alle vereisten opnemen in de traditionele functionele uitsplitsing. Typische voorbeelden zijn de fysieke eigenschappen van producten – massa, volume, dat soort informatie.

Het zou verstandig zijn om het V-model uit te breiden naar wat ik het W-model noem. Dit model begint met twee parallelle trajecten in het linkerbeen: de functionele en de fysieke stroom. Beide hebben betrekking op afzonderlijke systeemaspecten: de functionele stroom zorgt er vooral voor dat de vereiste functionaliteit wordt geïmplementeerd, terwijl de fysieke stroom ervoor zorgt dat de fysieke aspecten worden gebudgetteerd tot op de relevante systeemelementen.

De twee linkerbenen bundelen hun krachten op het zogenaamde ‘bouwsteen’-niveau, waar de elementen van een functioneel systeem, bijvoorbeeld het remsysteem van een auto, worden gespecificeerd en ontworpen op basis van hun vereisten. Deze elementen hebben zowel functionele als fysieke eigenschappen. In het voorbeeld van het remsysteem is een van de bouwstenen het rempedaal, dat wordt gespecificeerd door functionele eisen die duidelijk maken wat het pedaal moet doen en door fysieke eisen die de beperkingen specificeren met betrekking tot de massa van het pedaal, de toegestane ontwerpomhullende, het materiaal en meer.

Bouwstenen worden gedefinieerd op het niveau waarop specifieke functionaliteit wordt gespecificeerd, ontworpen en geïmplementeerd. Dit betekent niet dat het altijd losse onderdelen zijn; ze kunnen behoorlijk complex zijn, zoals de motor van een elektrische auto. Het is echter belangrijk dat ze altijd twee ‘ouders’ hebben: een functionele ouder (om ervoor te zorgen dat het remsysteem kan vertrouwen op de functionaliteit van het rempedaal) en een fysieke ouder (om ervoor te zorgen dat het pedaal past op de beoogde locatie en dat het voldoet aan de volumebeperkingen in de bestuurderscabine en andere interfaces).

Het gebruik van bouwstenen voorkomt dat modellen te gedetailleerd worden. Tegelijkertijd maakt het praktisch productbeheer mogelijk, vooral voor complexe systemen, zowel binnen het productontwerp als binnen het productiedomein. Voor een gemiddelde personenauto zijn ongeveer 400 bouwstenen gedefinieerd; de nieuwste ASML machines hebben er ongeveer 2000.

Eenmaal vrijgegeven wordt het bouwsteenontwerp virtueel geïntegreerd in de functionele en fysieke structuur, beide tot op systeemniveau. Het doel is om aan te tonen dat het ontwerp voldoet aan de eisen op elk niveau, zowel functioneel als fysiek. Dit zijn de twee opwaartse poten die het middelste deel van het W-model vormen.

Deze aanpak heeft verschillende voordelen. Het zorgt voor duidelijke verantwoordelijkheden op systeemniveau voor zowel functionele als fysieke vereisten gedurende de levenscyclus van het systeem. Het maakt ondubbelzinnige budgettering van fysieke aspecten zoals massa en volume downstream mogelijk. Het vergemakkelijkt de vroegtijdige detectie van mogelijke integratieproblemen (“het past niet, product niet in balans, te zwaar, interfaces niet nageleefd”) tijdens de ontwerpfase, vóór de reguliere productintegratie. Het maakt de verantwoordelijkheden voor het ‘functioneren’ van de elementen expliciet – het team dat het remsysteem ontwerpt moet aantonen dat het werkt volgens de eisen; er zijn geen excuses om te wachten tot het hele product geïntegreerd is.

Het is goed om te beseffen dat het gemiddelde functionele subsysteem, zoals een remsysteem of een niveausensor, niet op een stuklijst staat. Je bestelt geen remsysteem, je bestelt de bouwstenen. Dit betekent dat het in de productie- of logistieke omgeving moeilijk (zo niet onmogelijk) is om te zeggen welke functie een component op de fabrieksvloer of zelfs in het eindproduct vervult. Als je echter de logica zou volgen zoals uitgelegd in het W-model, zou het een fluitje van een cent zijn omdat de implementatie van de bouwsteen ook terug te voeren is op zijn functionele ouder(s).

 

 

High Tech Institute trainer Cees Michielsen belicht een handvol trends op het gebied van system requirements engineering. Voor High Tech Institute verzorgt hij meerdere keren per jaar de 2-daagse training‘System requirements engineering‘.

 

Het principe van traceerbare requirements is echt cool: in staat zijn om zowel top-down een requirement te volgen vanaf de creatie tot de implementatie en bottom-up vanaf de implementatie tot de oorsprong. De meeste handboeken geven mooie diagrammen en tabellen die laten zien hoe requirements zijn gekoppeld aan andere requirements en testgevallen. Helaas hebben deze diagrammen en tabellen weinig te maken met de dagelijkse praktijk.
Systeemeisen volgen systems engineering principes. Laten we het voorbeeld nemen van een sluis. Op systeemniveau zal er een vereiste zijn die stelt dat de sluis boten in staat moet stellen om stroomopwaarts en stroomafwaarts door het kanaal te varen. Hoe kunnen we dit opsplitsen als we nog niet hebben besloten hoe we het probleem gaan oplossen, of in de terminologie van eisen: hoe kunnen we aan deze eis voldoen?
In de praktijk zien we een grote verscheidenheid aan oplossingen, van het prachtige Schotse Falkirk Wheel (een echte bootlift) tot de Nederlandse sluizen bij Eefde. Twee totaal verschillende oplossingen voor hetzelfde probleem. Dus wat te doen met de traceerbaarheid van onze systeemvereisten?
In het geval van Eefde bestaat een sluis uit twee poorten en een kamer. Elk onderdeel heeft zijn eigen mogelijkheden, maar geen van de onderdelen kan alleen aan de systeemvereisten voldoen. Daarom hebben we de ontwerpbeslissingen nodig als ankerpunt in de eisenstroom (top-down, eis naar ontwerpbeslissing naar eis) en in de trace-back (bottom-up). Door het ontwerp begrijpen we dat wanneer we een van de poorten openen, het waterniveau in de kamer gelijk wordt aan het niveau bij de geopende poort. Vervolgens kunnen de boten door de geopende poort de kamer in varen. Daarom is een van de zogenaamde afgeleide eisen aan het poortsubsysteem dat het geopend en gesloten kan worden.

[Courseinstructor heading=”‘Waarom hebben we deze vereiste en waarom heeft het deze waarde?'”.

De vragen die we moeten beantwoorden en waarvoor we de bottom-up sporen nodig hebben zijn: waarom hebben we deze eis en waarom heeft het deze waarde? De antwoorden kunnen alleen worden gevonden via sporen van eisen op subsysteemniveau naar de ontwerpbeslissingen een niveau hoger, in ons geval het systeemniveau van de sluis.
Systeemingenieurs hebben ook te maken met budgetten voor middelen, zoals massa, volume, energie, operationele ruimte en materiaalkosten. Al deze zaken komen in de specificatie van eisen op systeemniveau als individuele eisen, maar ze worden nooit doorgegeven aan de subsystemen zonder ze in samenhang te analyseren, een ontwerp te maken dat alle voors en tegens in overweging neemt en uiteindelijk te beslissen welke oplossing het beste voldoet aan deze systeemeisen.
In werkelijkheid zijn er veel afhankelijkheden tussen, in dit geval, de eisen aan middeleneigenschappen. Vooral in de auto-industrie zijn massa en materiaalkosten twee voertuigeigenschappen die sterk met elkaar verweven zijn. Op systeemniveau wordt het totale massabudget vastgesteld: het voertuig moet minder wegen dan 1.500 kg, en hetzelfde geldt voor het materiaalkostenbudget: de totale materiaalkosten mogen niet hoger zijn dan 7.000 euro. Vervolgens wordt, als er moeilijke beslissingen moeten worden genomen, een prioriteit bepaald, bijvoorbeeld minder gewicht is belangrijker dan materiaalkosten.
Het ontwerp probeert hier een oplossing voor te vinden en wijst budgetten toe voor massa en materiaalkosten, waarbij deze vereisten in evenwicht worden gebracht en tegelijkertijd wordt uitgegaan van bepaalde capaciteiten van de subsystemen die bijdragen aan deze budgetten. Uiteindelijk, wanneer een beslissing is genomen voor een oplossing, worden delen van de budgetten voor massa en materiaalkosten toegewezen aan de subsystemen.
Als je verantwoordelijk bent voor een van deze subsystemen en je krijgt een massabudget van 100 kg, waar zou je dan zoeken naar antwoorden op de vragen: waarom heb ik een massabudget en waarom is het 100 kg?

High Tech Institute trainer Cees Michielsen belicht een handvol trends op het gebied van system requirements engineering. Voor High Tech Institute verzorgt hij meerdere keren per jaar de 2-daagse training‘System requirements engineering‘.

 

Kunnen we objectief zeggen dat een vereiste van goede kwaliteit is? Wat zou de maatstaf voor goed zijn? Bestaat er zoiets als ‘goed genoeg’? De meeste antwoorden op deze vragen zijn te vinden in het werk van Philip Crosby, William Edwards Deming en Joseph Juran. Deze drie kwaliteitsgoeroes zijn niet meer onder ons, maar hun ideeën blijven een grote bron van inspiratie.

Aangezien requirements het resultaat zijn van een requirements engineering proces, lijkt het logisch om te controleren of een requirement voldoet aan de doelen van het proces. Ten eerste zijn de behoeften van de belanghebbenden vastgesteld en ten tweede is een correcte en volledige overgang van de behoeften van de belanghebbenden gewaarborgd tot het decompositieniveau waarop de eisen kunnen worden geïmplementeerd in hardware- of softwarecomponenten. Ik zal me hier richten op het tweede doel.

Er wordt onderscheid gemaakt tussen intrinsieke en extrinsieke requirementskwaliteit. Intrinsiek betekent dat de kwaliteit van een requirement wordt bepaald door de manier waarop het is gedocumenteerd of gepresenteerd aan de lezer – de syntax van de requirement. Dit kan puur tekstueel zijn of verfraaid met afbeeldingen, tabellen en meer. De controle kan in theorie worden uitgevoerd door personen of applicaties zonder kennis van het onderwerp. Ze hoeven niet te begrijpen waar de eis over gaat, maar ze moeten eerder kijken of het in strijd is met de regels voor het schrijven van eisen. Deming spreekt van “trots op vakmanschap” en “goed opgestelde eisen”. In de loop van de laatste 10-15 jaar zijn softwaretools om deze kwaliteitscontroles te ondersteunen steeds geavanceerder geworden. In tools zoals QVScribe zijn checklists zoals de Writing Requirements richtlijn van de International Council on Systems Engineering (Incose) volledig ingebed en intrinsieke kwaliteitscontroles zijn volledig geautomatiseerd (inclusief diverse requirements templates zoals EARS en IREB).

Merk op dat de intrinsieke kwaliteit slechts een derde van de totale kwaliteit van de vereisten dekt. Maar de intrinsieke kwaliteitscontroles hebben wel degelijk waarde. Als ze worden uitgevoerd en correcties worden aangebracht voordat de requirement wordt beoordeeld door materiedeskundigen en relevante belanghebbenden, kunnen deze tools tijd besparen en inderdaad nuttig zijn om de kwaliteit van requirements te verbeteren.

Maar tools helpen je niet om te bepalen of je requirement zinvol is voor het beoogde publiek. Dit is waar de extrinsieke kwaliteit van requirements om de hoek komt kijken. Het is van toepassing in twee richtingen: terug naar de belanghebbenden die vroegen om een specifieke eigenschap van het te ontwikkelen product of een productkenmerk of gedrag (het bronpubliek), en vooruit naar de ontvangers van de vereiste (het doelpubliek).

Laten we eens kijken naar de volgende eis: “De reactiesnelheid van het systeem mag niet groter zijn dan 0,5 ms.” Deze eis zal waarschijnlijk met vlag en wimpel door de geautomatiseerde kwaliteitscontroles komen. In de praktijk wordt deze eis vaak geformuleerd als: “Systeemresponsiviteit: ≤ 0,5 ms.” Zou je zeggen dat deze eisen van gelijke kwaliteit zijn? Vanuit een syntactisch perspectief zal de eerste een hogere score opleveren omdat deze een richtlijn bevat, maar pas als we het de relevante belanghebbenden vragen, hebben we enig idee of de bedoelde betekenis correct is vertaald.

[Courseinstructor heading=”‘equirements engineers moeten hun eisen laten controleren en beoordelen.'”

Kwaliteit is conformiteit aan de vereisten, zegt Crosby. Hebben wij, als requirements engineers of business analisten, de behoefte van de stakeholder correct vertaald naar een systeemvereiste? Dit kan alleen worden beantwoord door de belanghebbenden die de oorspronkelijke behoefte hebben geformuleerd. Dus requirements engineers moeten hun requirements laten controleren en beoordelen – een activiteit die als moeilijk wordt ervaren.

Stel dat de klant zegt dat de ingenieur het verzoek niet heeft begrepen? Of dat hij het punt volledig heeft gemist? Zulke feedback is niet altijd prettig en dat zorgt ervoor dat een requirements engineer deze confrontaties uit de weg gaat. Hij neemt vaak de veilige weg door contact op te nemen met iemand van het project om de klant of stakeholder te vertegenwoordigen.

Dat is geen slimme houding. We willen er zeker van zijn dat we de behoeften van de belanghebbenden hebben begrepen en dat we ze correct en volledig hebben vertaald in vereisten. Daarom is er geen andere manier dan deze moeilijke vragen direct te stellen.

Kwaliteit is geschiktheid voor het doel, zegt Juran. Requirements moeten voldoende informatie en details bevatten voor ontwerpers om oplossingen te bedenken. Van de requirements wordt verwacht dat ze gekwantificeerd zijn zodat testers de succesvolle implementatie ervan kunnen verifiëren en valideren. Kortom, ze moeten duidelijk, ondubbelzinnig en zinvol zijn en voldoende gedetailleerd voor degenen die de vereisten ontvangen als input voor hun werk.

Ik heb gevallen gezien waarin er geen documentatie over vereisten bestond tussen een OEM en een van zijn leveranciers van onderdelen. Alleen een mondelinge overeenkomst. Hoewel dit in sommige culturen een onaanvaardbare situatie lijkt, werden de doelen van het requirements engineering proces gehaald. De leverancier levert het onderdeel nu al meer dan twaalf jaar met constante kwaliteit tot tevredenheid van de klant.

Wat zou jij doen in dit soort situaties? Hoe kijk je aan tegen de kwaliteit van requirements in jouw bedrijf? Hoe zou jij omgaan met behoeften van stakeholders zoals “ik wil dat de volgende versie van de auto energiezuiniger is”? Ik hoor graag van je, om te leren en door te geven.

High Tech Institute trainer Cees Michielsen belicht een handvol trends op het gebied van system requirements engineering. Voor High Tech Institute verzorgt hij meerdere keren per jaar de 2-daagse training‘System requirements engineering‘.

 

Een vraag die in bijna al mijn lessen over systeemvereisten opduikt, is: hoe kunnen we ervoor zorgen dat onze specificatie van vereisten volledig is? Dit is een terechte vraag. Ontbrekende requirements betekent meestal dat we mogelijkheden missen van de producten die we ontwikkelen. Dat heeft gevolgen voor het succes van die producten. Ofwel zijn de gebruikers van een product teleurgesteld omdat ze iets verwachtten dat niet geleverd wordt, ofwel is het product niet competitief genoeg in vergelijking met andere producten met vergelijkbare functionaliteit.

 

De praktijk wijst uit dat eisenspecificaties zelden volledig zijn. Het is gewoon erg moeilijk om ze compleet te maken en te houden. Gelukkig hebben we in de afgelopen decennia een aantal technieken en methoden geleerd die ons kunnen helpen in ons streven naar volledigheid.

'Templates and checklists really work.'

Ten eerste werken sjablonen en checklists echt. Ze stammen uit de begindagen van engineering en helpen ons om de voor de hand liggende vereisten niet te vergeten. Vandaag de dag is er hulp in overvloed. Het internet staat vol met checklists die speciaal gericht zijn op requirements.

Je moet zelf ook wat graven: zoek alle belanghebbenden met een potentiële impact op het succes van het product. Stakeholders vergeten betekent vaak dat je ook hun behoeften en verwachtingen van de mogelijkheden van het product niet zult vastleggen. Dat is een recept voor mislukking. Natuurlijk moet je je stakeholders bevragen en uitdagen om erachter te komen wat hun echte behoeften zijn. Het helpt ook om deze behoeften expliciet te maken. Nodig de brandweer niet uit wanneer je een nieuw gebouwde tunnel in gebruik neemt om er vervolgens achter te komen dat je misschien een aantal essentiële veiligheidsmaatregelen over het hoofd hebt gezien. Je moet de brandweer al in een vroeg stadium betrekken bij het verzamelen van eisen.

Zorg ervoor dat je het te bouwen product vanuit verschillende perspectieven bekijkt. Bekijk het door de ogen van daadwerkelijke gebruikers, eigenaren en investeerders. Betrek ook belanghebbenden die ook de negatieve effecten ervaren. Deze perspectieven kunnen soms het beste worden beschreven in een concept of operations, user stories, use cases en scenario’s.

Realiseer je dat de requirements elicitation stap (waar je stakeholders en hun behoeften identificeert) plaatsvindt op elk decompositie niveau van je productarchitectuur voor elk systeemelement! Op elk niveau vind je nieuwe belanghebbenden die specifiek zijn voor dat systeemelement op dat niveau. Denk aan software coderingsstandaarden in een multidisciplinair product.

Analyseer de behoeften op een gestructureerde manier. Dit betekent onderscheid maken tussen de hoofdfunctie van een product en zijn subfuncties, tussen een functie, zijn eigenschappen en zijn ontwerpbeperkingen. Uiteindelijk moet je een balans vinden tussen de eisen die functies stellen aan prestaties en resource-eigenschappen.

Als we een personenauto als voorbeeld nemen en zeggen dat “mensen vervoeren” de belangrijkste functie is, dan moeten we uitdrukken en kwantificeren hoe goed we mensen moeten vervoeren: hoe comfortabel, hoe betrouwbaar, hoeveel mensen, hoe veilig? Dit zijn voorbeelden van prestatie-eigenschappen (of kwaliteiten) van een functie. Ze worden afgewogen tegen de resource-eigenschappen, zoals: hoeveel energie mag deze prestatie kosten, hoeveel materiaal mag het kosten, hoeveel lawaai? Terwijl de analyse de functies, eigenschappen en beperkingen identificeert, kwantificeert de specificatiestap de eigenschappen.

Dit maakt deel uit van de gestructureerde methode voor eisenanalyse en is een van de effectieve manieren om de zogenaamde opkomende eigenschappen te ontdekken – eigenschappen waar geen enkele belanghebbende om heeft gevraagd, maar die een specifiek productaspect vertegenwoordigen als gevolg van keuzes die tijdens het ontwerp zijn gemaakt. Bijvoorbeeld, de keuze voor een verbrandingsmotor geeft geluid en uitstoot van giftige gassen als opkomende eigenschappen. Sommige van deze opkomende eigenschappen kunnen plotseling heel belangrijk worden na lange tijd genegeerd te zijn, zoals we hebben gezien bij de NOx-uitstoot. Het punt is dat als er eenmaal een ontwerpkeuze is gemaakt, je moet kijken naar de gevolgen (goed, slecht en lelijk) om te zien of er nieuwe vereisten moeten worden opgesteld om de opkomende eigenschappen te beheren.

In de loop der jaren zijn de namen van de productontwikkelingsafdelingen nogal veranderd, vooral de groepen die verantwoordelijk zijn voor het schrijven van de requirements op product- (of systeem-) niveau. Van productdefinitie via systeemengineering zien we nu groepen (soms afdelingen) die zo heten dat het heel duidelijk is waar ze voor staan, zoals “Producteigenschappen en klantfuncties”. Op dezelfde manier zegt de titel van Hansjörg Maier van Porsche alles: “Leiter Produkt-Eigenschaften und Kunden-Funktionen.” Dit geeft een enorme focus op wat belangrijk is voor het product, zowel de functionaliteit als de eigenschappen, en wat het product onderscheidt van de concurrentie.

Als technisch leider moet je zowel het project als het bedrijf in de juiste richting sturen. Om dat te doen, moet je belanghebbenden kunnen overtuigen, invloed kunnen uitoefenen zonder autoriteit en persoonlijk leiderschap tonen.

Wat zou jij zeggen om de situatie en samenwerking te verbeteren? Bekijk 5 verschillende situaties en vertel ons hoe jij zou reageren. Je krijgt persoonlijke feedback van trainer Jaco Friedrich en misschien win je wel een Tiny Tony’s uitdeelbox.