Asymmetrische of publieke-sleutelcryptografie kan een zware wissel trekken op de processor, zowel op het vlak van berekeningen als qua geheugenverkeer. Barco Silex legt uit hoe zijn...
Het waren pijnlijke jaren, maar het gaat weer de goede kant op met zijn bedrijf, vertelt CTO René Penning de Vries van NXP. Een gesprek...
Beste lezers, dit is mijn laatste reguliere column. Ik heb de afgelopen jaren geschreven over intelligente pleisters en punaises, waar we nu het Holst Centre voor hebben. Ik heb geschreven over de...
29 juni 2010
Wat zijn de trends in software-engineering? Welke technieken zijn in, welke impact hebben deze op de organisatie en wat betekenen ze voor de ontwikkelaar? Bits&Chips zette een aantal deskundigen uit de academische wereld en de industrie aan tafel voor een discussie.
Software-engineering kan niet meer zonder modellen, daar zijn de deelnemers aan het Bits&Chips-kringgesprek het roerend over eens. Om grip te houden op de groeiende systeemcomplexiteit en de toenemende configuratiediversiteit in softwareproductlijnen moeten we naar een hoger abstractieniveau. ‘Een aantal jaar geleden hadden we veel meer de neiging om te denken: tijdens de integratie krijgen we het allemaal wel aan de praat met een paar softwarewhizzkids. En na wat gefröbel slaagden die daar inderdaad ook in’, herinnert Jan Stoeten zich. ‘De ASML-organisatie is nu echter zo groot geworden, dat je het niet meer bij elkaar houdt met een paar whizzkids. We moesten wel toe naar andere werkwijzen.’
In Veldhoven proberen ze modelgedreven engineering zo ver mogelijk door te voeren, vertelt Stoeten. ‘Waar we ons op dit moment bedienen van modellen is dat vooral als basis voor codegeneratie. We zijn bezig modellen te introduceren in de verificatieslag, om bijvoorbeeld te kunnen bepalen of er geen geheugenproblemen of racecondities optreden. Dat doen we onder meer samen met het Embedded Systems Institute. Als je de interface eenmaal hebt gedefinieerd, dan kun je van daaruit beginnen met de codegeneratie én er later op ingrijpen met je verificatie.’
Modellen zijn ook een middel om de communicatie tussen disciplines te stroomlijnen. ‘Maar iedereen dezelfde taal laten praten is het moeilijkste om voor elkaar te krijgen’, weet Stoeten uit ervaring. ‘Fysici en mechatronici zetten toch meer requirements neer dan designs. Wat zij afleveren, gieten de software-engineers zo veel mogelijk in modellen, meestal UML, waarmee ze dan de communicatie aangaan. Als de andere afdelingen hun documenten terugzien in de modellen, begint het ineens te leven voor ze. Het abstractieniveau van mensen opkrikken blijft echter bijzonder lastig.’ John Kesseler van Océ sluit zich hierbij aan: ‘Modellering is een krachtige techniek, maar je bent afhankelijk van het niveau van je stakeholders in andere disciplines.’
Ook binnen de eigen softwarediscipline maakt niet iedereen de stap naar een hoger abstractieniveau even gemakkelijk. ‘Je hebt mannen die software correct krijgen door uit te proberen, bugs te fiksen. Dat kunnen we allemaal’, vindt Hans Aerts van Tomtom. ‘Maar je moet ook mensen hebben die van tevoren stevig nadenken over een probleem en met modelleringstechnieken kunnen abstraheren. De ervaring die ik heb uit mijn Philips-tijd is dat er maar weinig zijn die dat beheersen. Bijna elke poging om het breed in te voeren, is toen gestrand omdat het grootste deel van het team niet meekon.’
‘Belangrijker nog dan kunnen denken in abstracties is het vermogen om de juiste abstracties te leggen, abstracties die onderhoudbaar zijn, robuust in de tijd’, voegt Dirk-Jan Swagerman van Fei toe. ‘Ik zie een groot verschil tussen mensen die dat van nature goed doen en mensen die dat helemaal niet kunnen. Normaal gesproken heb je in een organisatie geen metrieken om te bepalen wie de juiste, onderhoudbare keuzes maakt en wie niet, maar de stap naar een hoger abstractieniveau laat je die lijn vrij scherp trekken.’
Aan de universiteiten de schone taak om de gewenste capaciteiten bij te brengen. TUE-hoogleraar Mark van den Brand neemt die handschoen graag op. ‘In de colleges die ik nu in het masterprogramma geef, richt ik mij heel sterk op bijvoorbeeld het opstellen van modeltransformaties en het leren denken in termen van metamodelleringen, modeltransformaties en codegeneratoren - richting executeerbare dan wel verifieerbare code.’
De universiteiten zouden wel wat meer aandacht mogen besteden aan software-engineering op grote schaal, en aan het omgaan met legacy in het bijzonder. ‘In de softwareproductlijnen van bedrijven zit een grote bak bestaande software waar de helft van je mensen geen flauw benul van heeft, maar waar ze bij tijd en wijle wel aan moeten sleutelen’, legt Aerts uit. Ook bij ASML krijgen schoolverlaters meer te maken met bestaande code dan met nieuwe. ‘Er is maar heel weinig greenfield-ontwikkeling’, aldus Stoeten. ‘Ik schat dat tachtig procent legacy is.’
De software-engineers die bij Fei komen solliciteren vanuit het academische traject brengen een overcapaciteit aan modelleertechnieken mee en hebben te weinig met hun voeten in de modder gestaan, vindt Swagerman. ‘Van school hebben ze een enorme bak conceptueel abstracte bagage meegekregen, maar daar heb je niet zo veel aan als je aan die twintig miljoen regels moet beginnen die we bij Fei hebben liggen. Aan de ene kant heb je een hoog conceptueel niveau nodig; aan de andere kant moet je ook gewoon meters kunnen maken.’
Van den Brand erkent het bestaan van dit legacygat in de opleiding en heeft al een stap gezet om het te dichten. ‘Tot nu toe leerden software-engineers alleen maar om nieuwe dingen te bouwen en niet om bestaande code te onderhouden. Aan de TUE geven we dit jaar voor het eerst het vak software-evolutie. Daarin bereiden we de studenten voor op het werken in een organisatie waar die twintig miljoen regels code al liggen en leren we ze omgaan met evoluerende software en evoluerende modellen. Doel is om ze er bewust van te maken dat er legacy is en ze technieken bij te brengen om die legacy te analyseren en ermee te werken.’
Swagerman merkt ook dat de universiteitsverlaters te hoge verwachtingen hebben, waardoor ze bij Fei eerst even schrikken. ‘Ze komen solliciteren met het idee dat ze binnen twee jaar architect of consultant zijn. Dat is totaal irreëel, want je hebt veel domeinkennis nodig voor je überhaupt iets kunt. Bovendien zijn ze onvoldoende pragmatisch: ik mis de mindset om een praktisch probleem praktisch op te lossen. Wat we veel meer nodig hebben, is de combinatie van software-engineering, een goed abstractieniveau, de wil om het domein te leren kennen en resultaatgerichtheid.’ Laquso-directeur Harold Weffers, voorheen aan het hoofd van de TUE-ontwerpersopleiding Ooti, beaamt dit: ‘Je ziet dat steeds meer studenten tegenwoordig geen code meer willen kloppen, maar inderdaad binnen twee jaar architect of consultant willen zijn.’
Kesseler onderschrijft het geschetste beeld niet. ‘Bij Océ zien we juist dat de mensen op de arbeidsmarkt resultaatgericht werk willen doen, werk dat hen ook intellectueel uitdaagt, hen aanspreekt op een hoog abstractieniveau en hen trots maakt. We zien mensen met een goede opleiding, die ervoor gaan en die oppakken wat wij ze aanreiken. De vernuftigheid is er gewoon en de drang om te maken, ook bij de schoolverlaters die we onlangs hebben aangenomen.’
Op het hbo denken ze liever niet na op een hoger abstractieniveau, maar willen ze wel code kloppen, geeft Ger Schoeber van Sioux aan. Volgens Swagerman hoeven we daar weinig van te verwachten. ‘Waar de academen te conceptueel zijn en onvoldoende verbonden met de realiteit, hebben de hbo’ers gewoon het juiste niveau niet. Dat ze wiskunde daar uit het pakket hebben gegooid, is funest voor de informatica. De hbo-opleidingen zijn alleen nog maar gericht op sociale vaardigheden. Het programmeren moet je ze bij wijze van spreken zelf bijbrengen.’ In de ogen van Aerts zou het juist andersom moeten: ‘Die communicatieve vaardigheden leren ze wel als ze meer ervaren worden.’
Voor een bredere inzet van modellen zijn behalve capabele mensen ook goede tools nodig. Op dit moment is het ondersteunende gereedschap echter niet volwassen genoeg, is de teneur tijdens het rondetafelgesprek. ‘Vergeleken met tien jaar geleden is er gigantisch veel verbeterd’, vindt Mark van den Brand. ‘Zo weet ik dat ze bij ASML grote stappen hebben gezet: ze werken veel met Eclipse en doen veel aan metamodellering. Maar we zijn er nog lang niet. Het meeste gereedschap staat nog in de kinderschoenen. We kunnen op dit moment geen standaard tooltje uit de kast trekken en er plug-and-play mee aan de slag. We moeten er nog heel veel zelf aan sleutelen om het werkend te krijgen. Met Eclipse kun je bijvoorbeeld metamodellen maken, maar dan moet je ook je eigen modeltransformaties en codegeneratoren bouwen.’
‘Tomtom haalt zestig procent van zijn spulletjes van de opensourcemarkt’, haakt Aerts in. ‘Als ik die met drie handige engineers aan de praat krijg, heb ik geen businesscase voor eigen generatoren. En dan weet ik dat die drie slimme jongens over twee jaar, als het allemaal is gegroeid, tegen problemen aanlopen die hun bevattingsvermogen te boven gaan. Maar het probleem van vandaag en zelfs morgen is opgelost.’ ‘Uiteindelijk zijn het de kosten en de time-to-market die dicteren wat je doet’, vult TMC’er Luud Engels aan.
‘Bij Océ gebruiken we Rational Rose Realtime om grafen te tekenen en daar code uit te genereren. De visuele modellen helpen ook om teamleden uit verschillende disciplines met elkaar te laten praten, maar meer doen we er multidisciplinair niet mee op dit moment’, vertelt John Kesseler, die zegt wel toe te zijn aan een volgende stap. ‘Voor de systeemdecompositie leunen wij nu op het vakmanschap van de engineer. Daar zouden we veel meer ondersteuning willen hebben van modelgebaseerde technieken en tools. Verder stroomopwaarts varen we eerder op de intuïtie en de ervaring van de engineer dan dat we alles in een model stoppen.’
Formele methodes zullen het vak de gewenste stap verder brengen, daar zijn alle deelnemers het over eens. ‘Het moet fors meer formeel’, stelt Luud Engels. ‘Zolang die formele onderkant er niet is, blijft software-engineering een ambacht.’ Ook voor de wiskundig gefundeerde technieken geldt echter, misschien zelfs wel sterker dan bij ‘gewone’ modelgebaseerde methodes, dat engineers op een hoog abstractieniveau moeten kunnen denken om ze te gebruiken. ‘Een oplossing is om formele technieken zo veel mogelijk onder de motorkap te stoppen’, brengt Mark van den Brand in. ‘De engineers modelleren dan in de meest geschikte taal voor hen, waarbij de tooling de juiste back-ends aanroept om de berekeningen en checks uit te voeren – allemaal op de achtergrond, zonder de engineer uit zijn vakgebied te halen.’
Dit is precies de route die Verum volgt met zijn Analytical Software Design-methode. Hoewel de bijbehorende tooling nog verre van volwassen is, vindt iedereen aan de ronde tafel dat het bedrijf uit Waalre op de goede weg is. ‘De wiskundige basis van ASD - CSP en model-checking – is wel al een eeuwigheid oud’, tekent Harold Weffers aan. ‘Bovendien zijn er veel alternatieven voor Verums aanpak.’ ‘Die zijn echter grotendeels blijven hangen in de wetenschappelijke wereld’, valt Van den Brand in. ‘Het sterke punt van Verum is dat ze ondersteuning bieden en verantwoordelijkheid nemen. Bij academische tooling is het vaak garantie tot de deur.’
‘Het is een mooie prestatie van Verum dat ze complexe wiskunde toegankelijk hebben gemaakt voor het bedrijfsleven’, vindt Engels. Ook Swagerman is onder de indruk. ‘Bij Fei hebben we het nog niet toegepast op een volledig systeem, alleen op onze tafelmicroscoop Phenom. Dan heb je het over een vrij beperkte hoeveelheid van zo’n zestigduizend regels. Onlangs heeft CCM echter een snelle scanner geïntroduceerd met 225 duizend regels code, waarvan tachtig procent gegenereerd met ASD. Daar hebben ze met acht mensen een jaar aan gewerkt. Dat begint al ergens op te lijken. Misschien komen er nog concurrenten, maar voorlopig is Verum de enige die formele methodes productierijp heeft gemaakt.’
Uiteraard hebben formele technieken zo hun beperkingen. ‘Systeemgedrag kun je heel goed vastleggen in toestandsmachines, met Verum of op een andere manier. Die modellen kun je vervolgens formeel doorrekenen om te controleren of ze voldoen aan je wensen’, legt Van den Brand uit. ‘Algoritmes kunnen we echter nog niet zo goed vangen. Daar zul je moeten werken met tests als je wilt checken of ze doen wat ze zouden moeten doen.’
Dirk-Jan Swagerman kan dit beamen. ‘Wij werken ook veel met plaatjes in onze elektronenmicroscopen, data dus, en veel met algoritmes in de optiek. Daar kun je Verum niet gebruiken.’ ‘Voor datagedreven architecturen in de printercontroller fabriceren wij UML-diagrammen in Magicdraw, die we vervolgens met de hand omzetten’, zegt Kesseler van Océ. ‘Dat is low-key model-driven engineering, maar we maken er geen fouten mee.’ ASML gebruikt al jaren een eigen methode om toestandsmachines te maken en om te zetten naar code. Stoeten: ‘Het werkt goed en dan ga je het niet meer openbreken voor iets anders.’
Voor de specificatie vindt Hans Aerts formele methodes niet zo nuttig. ‘Daar is veel mee geëxperimenteerd, maar het schiet niet echt op.’ Ook Kesseler is nog niet enthousiast over de bruikbaarheid in die beginfase. ‘Bij tooling als die van Verum zie je de neiging om details naar voren te halen, om er alles in te stoppen. Het gereedschap helpt je niet om abstractie-afwegingen te maken in die belangrijke eerste fase van keuzes. Bij ASD moet je de toestanden opsommen in tabellen, zelf alle overgangen aangeven en invullen wat er uit moet komen. Dat is niet de engineer weghouden van de details.’
De rondetafel verbaast zich erover dat de IC-ontwerpwereld zo veel verder is dan de software-engineeringdiscipline. ‘Daar hebben ze een goede toolketen, veel meer standaardisatie, veel meer componentbibliotheken; in software is er helemaal niks’, chargeert Aerts. ‘Als je kijkt naar de werkplek van een IC-designer, dan is ontwerpgereedschap goed voor 50 procent van de kosten. Bij een software-engineer is dat maar een fractie. En dat terwijl beide disciplines zo dicht bij elkaar staan.’ Swagerman: ‘We zijn nog niet erg volwassen als vakgebied.’ ‘Maar als je het vergelijkt met tien jaar geleden, zijn we wel heel wat verder’, voegt Kesseler toe.
Het valt Aerts ook op dat IC-ontwerpers veel meer hergebruiken. ‘Dat heeft te maken met time-to-reuse en time-to-do-it-yourself’, meent Swagerman. ‘Als het voor een engineer makkelijker is om zijn eigen logfunctie te maken dan om de standaard functie te gebruiken, dan doet hij het gewoon zelf.’ ‘Die jongen denkt alleen maar in zijn eigen kader’, stelt Harold Weffers, ‘terwijl de impact in een toekomstige productlijn catastrofaal kan zijn.’ Kesseler neemt het op voor de software-engineer: ‘Ik vind dat ze al best veel standaard componenten gebruiken. De wereld is Api. Toegegeven, iets meer not invented here zou wel mogen.’ ASML’er Stoeten ziet ook veel hergebruik van functies, maar volgens hem gaat het mis als software-engineers hun werk willen automatiseren. ‘Als je niet oppast, maken ze daar elke keer weer hun eigen tooltje voor.’
Fei heeft zijn eigen buildgereedschap gebouwd. ‘We proberen veel te delen met andere organisaties’, vertelt Swagerman. ‘Voor de buildtooling hebben we bijvoorbeeld gekeken bij ASML en Philips Healthcare, maar die hadden net niet wat wij zochten, zodat we uiteindelijk hebben moeten doe-het-zelven. Door onze technologiekeuzes kunnen we veel minder van onze non-coretooling delen dan we zouden willen.’ ‘Vergelijk dat eens met de IC-wereld’, reageert Aerts. ‘Geen hond die daar zelf een Cad/Cam-omgeving gaat maken.’
‘In de IC-wereld is ‘standaardisatie’ het kernbegrip, in de software is dat ‘diversificatie’’, observeert Van den Brand. ‘We hebben zo veel verschillende formalismen, zo veel verschillende paradigma’s. Ongeveer ieder jaar wedden we wel weer op een ander paard.’ Weffers is het daarmee eens: ‘Op het moment dat we tien goede manieren hebben, bedenkt iemand een elfde waarvan hij vindt dat die beter is. En vervolgens loopt iedereen daar weer vrolijk achteraan.’ Aerts: ‘We zijn zo blij met dingetjes die ons even vooruithelpen dat we elke keer weer nieuwe technologieën in huis willen halen.’
Niet zelden ontaardt de diversificatie zo in een stammenstrijd. Stoeten kan daarover meepraten: ‘Elke keer als ik iets ga doen met een andere academische groep, krijg ik weer iets anders op mijn bureau. ‘Wij hebben onze eigen tool’, zeggen ze dan. ‘Die is veel beter.’ Natuurlijk.’ Van den Brand doet daar niet aan mee. ‘Bij mijn aanstelling in Eindhoven heb ik er heel bewust voor gekozen om niet opnieuw mijn eigen systeem te bouwen en te gaan slijten. In plaats daarvan ben ik gaan kijken wat anderen gebruiken. Met mijn promovendi bestudeer ik nu bijvoorbeeld het Eclipse Modeling Framework en Openarchitectureware. Ik geef toe dat ik hierin een uitzondering ben.’
Stoeten tekent hierbij aan dat bedrijven niet op iedere passerende trein kunnen springen. ‘Je hebt al je eigen aanpak waaraan je je hebt gecommitteerd. Je bent ergens ingedoken en je hebt je opgehangen aan een toolleverancier. Als er dan iets anders langskomt, moet je de hele boel weer ombouwen en die kans krijg je niet, ook al is dat andere misschien beter.’ ‘Je hebt al een flinke investering gedaan en bent daarmee een beetje in die strop gaan hangen’, concludeert Ger Schoeber. ‘Dan ga je eerder door op de ingeslagen weg dan terug.’
Het vermoeden aan tafel is dat de kosten van de fysieke realisatie ten grondslag liggen aan het verschil tussen IC-ontwerp en software-engineering. ‘Je betaalt een godsvermogen om een chipdesign in hoge volumes te laten maken’, zegt Engels van TMC. ‘Dan wil je er wel tijd en geld in steken om van tevoren te weten dat het goed komt. Software is goedkoop om te maken, is de heersende gedachte.’ ‘Daarom gaan we ook veel sneller naar een trial-and-error-aanpak’, denkt Aerts. ‘In de bouwkunde zetten ze niet eerst een brug neer om er dan auto’s overheen te sturen en te kijken of hij wel blijft staan, maar zo werken software-engineers wel. Als elke keer dat je de compiler aanzet een ton zou kosten, was dit vakgebied veel sneller volwassen.’ ‘Dat is overigens wel het businessmodel van Verum’, merkt Swagerman op. ‘Daar kost ook elke druk op de knop geld.’
‘Bedrijven denken vaak heel erg hardwaregericht’, is de ervaring van Van den Brand. ‘Vijf euro uitsparen op een sensor, terwijl je vervolgens drieduizend euro moet verspijkeren om de programmatuur aan te passen.’ Swagerman weet er alles van: ‘Het komt wel eens voor dat we nieuwe functionaliteit toevoegen aan een bestaande microscoop, bijvoorbeeld een moderne camera op een oude kolom. Dat we daarvoor een miljoen regels code moeten aanpassen, daar wordt niet bij stilgestaan. Het gaat er bij de interne stakeholders ook niet in waarom dat zo duur moet zijn.’ ‘Wij splitsen oudere platforms op een gegeven moment af in een aparte configuratiebranche, met een apart team erop’, meldt Stoeten van ASML. ‘Die onderhouden we wel, maar nieuwe functionaliteit komt er niet meer automatisch op. Moet dat wel, dan is er even een investering nodig. Dat is echter goedkoper dan alles meenemen in de baseline.’
Volgens Kesseler van Océ kiezen bedrijven ook bewust voor software die niet per se functioneel perfect is, maar wel goed genoeg. ‘Geef ons meer tijd en we leveren meer functionaliteit af. We weten hoe goede software eruitziet, maar om op tijd te zijn, nemen we genoegen met minder functionaliteit.’ ‘En het is kennelijk zo dat het toekan’, stelt Swagerman. ‘We komen als software-engineeringdiscipline nog steeds weg met geklungel omdat de meerwaarde van software in producten ondanks alle problemen blijkbaar groot genoeg is.’
Ontwikkelen doen de meeste aanwezigen volgens het Agile-gedachtegoed: incrementeel en iteratief met korte cycli en snelle feedback, ook van de klant. Dat laatste is een belangrijk aspect voor Aerts van Tomtom: ‘Je maakt niet vooraf de volledige specificatie - het is een illusie dat dat alles oplost en er is toch geen mens die precies begrijpt wat erin staat. In plaats daarvan voeg je meer details toe gaande de rit, waarbij je klant aangeeft of het de goede kant uitgaat of niet.’ ‘De specificatie wil nog wel eens veranderen over tijd’, vult Kesseler aan, ‘als die in het begin al klopte.’
Dat documentatie verleden tijd is bij Agile, is een wijdverbreid misverstand, aldus de manager software-engineering van Océ. ‘Dat begonnen mensen bij ons ook te roepen: we doen Agile, dus we hoeven niet meer te documenteren. Zo bestaat Agile niet. Het wordt wel eerder losgelaten dan vroeger, toen het meer verplicht was. Nu moeten we soms de teugels even aanhalen.’ ‘We zijn wel uitermate kritisch geworden’, merkt Aerts. ‘We schrijven alleen maar documentatie die we ook lezen en gebruiken.’
Agile is moeilijker toepasbaar als moet worden samengewerkt met disciplines waar de aanpak nog niet is doorgedrongen. ‘Iteratief werken zit in de genen van ASML, maar de stap naar echt Agile is vaak te eng’, vertelt Stoeten. ‘We passen het wel toe in de pure softwareprojecten. Daar vergemakkelijkt het de samenwerking met onze softwaretoeleveranciers, die ook zo werken.’ Aerts heeft hetzelfde probleem met de andere disciplines: ‘Heb ik in de vroege sprints een potentially shippable product, maar geen hardware. Die is nog in ontwikkeling.’ Kesseler heeft daar bij Océ minder last van: ‘Ook de andere disciplines hebben inmiddels begrepen dat ze op tijd bij elkaar moeten komen en zijn in Agile gestapt.’
In één tak van sport is het software-engineeringvak de afgelopen jaren zeker beter geworden: testgedreven ontwikkeling. Mede dankzij de korte cycli van Agile is er meer aandacht gekomen voor tests, testframeworks en testsuites. ‘Engineers brengen met meer vertrouwen wijzigingen aan’, observeert Aerts. ‘Ze weten minstens dat ze niks kapot hebben gemaakt. En als ze zelf iets nieuws bouwen, schrijven ze nu eerst een paar tests.’ ‘De test wordt bijna je specificatie’, voegt Engels toe. ‘Bij Océ proberen we de requirements om te zetten naar testcases’, vertelt Kesseler. ‘En met de Radboud Universiteit Nijmegen zijn we nu bezig om de testcases automatisch te genereren, zodat we ze niet meer zelf hoeven te schrijven. Dat is eigenlijk modelgebaseerd testen.’
Tomtom gebruikt verschillende hulpmiddelen om de tests te optimaliseren. Aerts: ‘Met CTC++ meten we bijvoorbeeld de dekking van de unittests: code coverage, branche coverage, statement coverage, hoe je het hebben wil. Vervolgens zou je een tool als Tics van Tiobe kunnen inzetten om de resultaten mooi weer te geven.’ Het dekkingspercentage neemt hij liever niet als maat voor de codekwaliteit. ‘Ik geef de voorkeur aan een echte kwaliteitsmeting, die laat zien hoeveel fouten er doorheen komen. Als er dat te veel zijn, weten we dat de dekking omhoog moet.’
Er is inmiddels een heel arsenaal aan hulpmiddelen beschikbaar om inzicht te krijgen in de codekwaliteit. Bedrijven kunnen zelf aan de slag met tools van bijvoorbeeld SolidsourceIT of Tiobe, of het werk neerleggen bij partijen als het Laboratory for Quality Software. ‘Wij lichten voor een bedrijf de hele software van een systeem door, vaak met een hele lijst van aandachtspunten als resultaat’, legt labdirecteur Weffers uit. ‘Dat is helemaal niet erg, als je er vervolgens ook wat mee doet. Je moet je ogen er niet voor sluiten en pas in actie komen als er echt stront aan de knikker is, maar gelijk een risicogebaseerde bril opzetten en kijken wat je belangrijk vindt en wat niet.’
Volgens Weffers zouden bedrijven ook de software die ze betrekken bij derden meer en beter moeten testen. ‘Er komen een heleboel third-party componenten binnen, van andere afdelingen, externe commerciële partijen of de opensourcegemeenschap. De meesten kijken er eens functioneel naar, testen een keer en dat is het. Ze kijken niet of het goede code is, terwijl daar wel methodes en technieken voor zijn. Als ze in de IC-wereld IP-blokken inkopen, rekenen ze die op RTL-niveau compleet door.’
Swagerman erkent dat codekwaliteit van third-party software bij Fei niet boven aan de prioriteitenlijst staat. ‘Als wij een module van derden integreren om de microscoopresolutie te verhogen, is de softwarekwaliteit secundair. Dan forceren de andere disciplines en de klanten ons om de code te integreren, ondanks dat deze misschien niet zo stabiel is. En wij gaan ermee door omdat het toekan. Het systeem crasht wel wat vaker, daar worden we ook op aangesproken, maar het is geen reden voor ons om die module niet te kopen. Het gaat om die betere resolutie. Daar betalen onze klanten voor.’ Aerts ziet wel verbetering: ‘Opensource komt steeds meer binnen met testframeworks erbij. Wij runnen die testcases ook, zodat we in ieder geval weten dat die stukken overeind blijven.’
‘Testcode is eigenlijk een zwaktebod’, werpt Swagerman tegen. ‘Als we scherpere methodes hadden om de logica gegarandeerd volgens spec te krijgen, zouden we die niet nodig hebben. Bij de stukken die wij formeel hebben gedaan, zie ik al dat we zonder kunnen. Het is voor die andere delen dat we die testcode nu nog nodig hebben. Voor third-party componenten zou ik ernaartoe willen dat we die inpakken in een Verum-achtige interface, zodat we eenvoudig kunnen zien of ze werken.’
Hans Aerts is manager softwareontwikkeling bij de businessunit Automotive van Tomtom en in het verleden onder meer verantwoordelijk voor de introductie van CMM bij Philips.
‘In de IC-wereld hebben ze een goede toolketen, veel meer standaardisatie, veel meer componentbibliotheken; in de software is er helemaal niks.’
Mark van den Brand is hoogleraar software-engineering aan de Technische Universiteit Eindhoven en wetenschappelijk directeur van Laquso.
‘Het meeste gereedschap staat nog in de kinderschoenen.’
Luud Engels is COO bij TMC en in het verleden gedetacheerd geweest bij onder meer ASML, Océ en Philips.
‘Zolang die formele onderkant er niet is, blijft software-engineering een ambacht.’
John Kesseler is hoofd software-engineering bij Océ.
‘Modellering is een krachtige techniek, maar je bent afhankelijk van het niveau van je stakeholders in andere disciplines.’
Gespreksleider Ger Schoeber is consultant en verantwoordelijk voor het kennismanagement bij Sioux Embedded Systems.
‘Doordat je al een flinke toolinvestering hebt gedaan, ben je een beetje in die strop gaan hangen en ga je niet zo snel meer terug.’
Jan Stoeten is verantwoordelijk voor de embedded-softwareontwikkeling bij ASML.
‘Iedereen dezelfde taal laten praten is het moeilijkste om voor elkaar te krijgen.’
Dirk-Jan Swagerman is hoofd software-engineering bij Fei in Eindhoven.
‘We hebben software-engineers nodig die een goed abstractieniveau combineren met de wil om het domein te leren kennen en resultaatgerichtheid.’
Harold Weffers is directeur van Laquso en in het verleden zakelijk directeur van de Eindhovense ontwerpersopleiding Ooti.
‘Op het moment dat we tien goede manieren hebben, bedenkt iemand een elfde waarvan hij vindt dat die beter is.’
© Bits & Chips | Deze pagina op internet: http://www.bits-chips.nl/nieuws/achtergrond/bekijk/artikel/langzaam-ontstijgen-we-het-geklungel.html
