Softwarekwaliteit? Natuurlijk! Resultaten van 4 jaar EQuA project

Transcriptie

1 Softwarekwaliteit? Natuurlijk! Resultaten van 4 jaar EQuA project

2

3 Softwarekwaliteit? Natuurlijk! Uitgave ter gelegenheid van de afsluiting van het RAAK-PRO EQuA project November 2014

4 Colofon Samenstelling: Jacob Brunekreef Eindredactie: Annemarie Diepenbroek Cartoons: Andrea Almering

5 Inhoud Voorwoord 5 Early Quality Assurance 7 Het belang van requirements 9 Waar zijn de requirements? 11 Neem Requirements Serieus! 15 Symbiosis en de praktijk van Beech.it 18 Een stage rond het genereren van code 21 Software voor game development 25 Talen voor Game Productie 27 De kracht van serious games 31 Agile software ontwikkelen 35 Vijf jaar agile. Hosanna of Drama? 37 Samenwerking tussen agile teams 43 Toegepast wetenschappelijk onderzoek 47 Onderzoek in opleiding 51 De EQuA deliverables 54

6

7 Voorwoord Deze uitgave is samengesteld ter gelegenheid van de afsluiting van het EQuA project. EQuA staat voor Early Quality Assurance (in software production). In het project hebben hogescholen, universiteiten en bedrijven samen gewerkt aan de centrale vraag: hoe kunnen we fouten bij het produceren van software zo vroeg mogelijk opsporen en daarbij herstelkosten op een later moment besparen? Aandacht voor kwaliteit van softwaresystemen, vanaf de start van de ontwikkeling het lijkt zo voor de hand te liggen. Toch blijkt het een weerbarstig onderwerp te zijn. Softwarekwaliteit? Natuurlijk! De titel van deze uitgave kan op twee manier worden gelezen. Natuurlijk is het zinnig en noodzakelijk om aandacht te besteden aan kwaliteit bij het ontwikkelen van software. Dat hoort bij de professionele werkwijze van de huidige generatie ontwikkelaars. Maar, wat is de natuurlijke manier om tot die kwaliteit te komen? Meer inzet van tools? Betere ontwikkelmethoden? Hoger opgeleide ontwikkelaars? Aan die vragen is binnen het EQuA project vier jaar lang gewerkt. Deze uitgave geeft u een indruk van de resultaten. Niet alle geschreven papers, handleidingen, afstudeerverslagen, zijn in z n geheel opgenomen. Dat is teveel van het goede en zou deze uitgave veel te dik maken. Achterin is een lijst opgenomen met die documenten, en waar ze te vinden zijn. In deze uitgave komen alle partijen die hebben bijgedragen aan het project aan het woord. Onderzoekers die de afgelopen jaren het grootste deel van hun werktijd (en het nodige van hun privé-tijd) aan het EQuA project hebben gewerkt vertellen waar ze aan gewerkt hebben, over hun resultaten. Medewerkers van bedrijven die bij het EQuA project betrokken zijn geweest maken duidelijk wat het project voor de praktijk van hun bedrijf heeft betekend. Drie universiteiten hebben deelgenomen aan het EQuA project. Hoe wordt in die wereld aangekeken tegen toegepast wetenschappelijk onderzoek, samenwerken met hogescholen en het bedrijfsleven? In een rondetafelgesprek laten drie universitaire medewerkers hun licht schijnen over dit onderwerp. Studenten hebben in het EQuA project een belangrijke rol gespeeld: als onderzoeker en als proefkonijn. Van beide wordt een voorbeeld beschreven. Daarnaast is een interview opgenomen met een stage-student die gewerkt heeft aan de ontwikkeling van een tool. Softwarekwaliteit? Natuurlijk! 5

8 De artikelen zijn gegroepeerd rond een viertal onderwerpen: de kwaliteit en structuur van requirements, software voor het interactief ontwikkelen van games, agile ontwikkelen en toegepast onderzoek algemeen. Tenslotte past een woord van dank. Allereerst aan de medewerkers en studenten van de betrokken partners hogescholen, universiteiten, bedrijven die met hun inzet voor de resultaten van het project hebben gezorgd. Ten tweede aan de Stichting Innovatie Alliantie (SIA), die met haar subsidie dit project mogelijk heeft gemaakt. En, last but not least, aan Fontys Hogeschool ICT die als penvoerder van het project zich keer op keer een uitstekend gastheer heeft getoond. Ik wens u veel leesplezier met deze uitgave! Jacob Brunekreef Projectleider EQuA-project Fontys Hogeschool ICT 6 Softwarekwaliteit? Natuurlijk!

9 Early Quality Assurance Jacob Brunekreef, Fontys Hogeschool ICT Van oudsher speelt kwaliteit een prominente rol in de wereld van software ontwikkelaars. Want, de gevolgen van achterblijvende kwaliteit kunnen groot zijn. Iedereen heeft wel ervaring met applicaties die plotseling dienst weigeren (net voordat je weer wilde saven ), iedereen kent verhalen van falende automatiseringsprojecten waar vaak miljoenen euro s mee zijn gemoeid. Maar, hoe voorkom je die problemen? Het antwoord op deze vraag is niet simpel, er bestaat niet zoiets als een silver bullet. Maar, er zijn wel inzichten die helpen. Zo weten we sinds onderzoek van de Amerikaanse software goeroe Barry Boehm uit begin jaren 80 van de vorige eeuw dat de kosten van foutherstel exponentieel oplopen naarmate een project in de tijd vordert. Dus loont het om al in een vroeg stadium aandacht te besteden aan het opsporen, verhelpen en vermijden van fouten. Bij de start van het EQuA project, in het najaar van 2010, hebben we bovenstaand inzicht als uitgangspunt genomen. De centrale vraag binnen het project was: Hoe kunnen wetenschappelijke kennis en inzichten op het terrein van vroegtijdige foutdetectie en herstel in software productie en in het werkveld op dit terrein toegepaste methoden en technieken samengebracht worden?. Daarbij was de veronderstelling dat zowel wetenschappers als het werkveld weten dat vroegtijdig opsporen van fouten loont maar wat doe je met die kennis? Wij hadden niet de illusie dat wij in het project het hele probleem op zouden kunnen lossen. Zoeken naar een aantal goede en bruikbare handvatten, dat was het idee. En, is er wat terecht gekomen van dat idee? Ik denk het wel! Binnen het EQuA project hebben onderzoekers zich gestort op een verscheidenheid aan onderwerpen, variërend van een kwaliteitsmodel voor requirements tot succesfactoren voor het samenwerken in een ontwikkelteam, van volwaardig gereedschap om requirements te kunnen formuleren en beheren tot een software bibliotheek om het ontwikkelen van spelgedrag in games te ondersteunen. Daarmee is nog niet alles genoemd. De volledige lijst met resultaten, verderop in deze uitgave, laat goed zien hoe omvangrijk en breed het onderzoek is geweest dat in het kader van het EQuA project is uitgevoerd. Uit de voorgaande opsomming is al wel duidelijk dat er niet alleen papier is geproduceerd. Er zijn ook producten ontwikkeld. Producten die al tijdens het project hun bruikbaarheid in de praktijk hebben bewezen. Zo wordt het Symbiosis tool voor Softwarekwaliteit? Natuurlijk! 7

10 het modelleren van requirements inmiddels actief gebruikt in enkele bedrijven, en is de Micro-Machinations 1 bibliotheek in het open source domein beschikbaar gesteld. Onderzoek en producten zijn gepresenteerd aan de buitenwereld, op congressen, symposia en andere bijeenkomsten, en in artikelen. Ondertussen dringt zich vanuit de praktijk een interessante vraag op: hoe relevant is de nadruk op vroegtijdig foutherstel in het licht van de sterke toename in de laatste jaren van de iteratieve, agile, manier van software ontwikkelen? Vandaag de dag wordt een toenemend deel van de software ontwikkeld in agile projecten, waarin opdrachtgever en opdrachtnemer samenwerken, om in kortlopende cycli (iteraties) een product iedere keer een stukje verder te ontwikkelen. Nu is er geen sprake meer van een opdrachtgever die een lijst met eisen (requirements) aanlevert en een jaar later eens komt kijken wat er van geworden is, maar van een opdrachtgever die bewust iedere kleine toevoeging aan of wijziging van het product-in-wording controleert en accepteert. De kans op het in een laat stadium van een project ontdekken van fouten is zo een stuk kleiner geworden. De trend om op een agile manier software te ontwikkelen bestond al bij de start van het EQuA project. Maar in de looptijd van het project, de afgelopen vier jaar, heeft deze manier van werken een grote vlucht genomen. Is het EQuA project daarmee achterhaald? Zeker niet! Juist hulpmiddelen als het Symbiosis tool en de Micro- Machinations Library, die in het EQuA project zijn ontwikkeld, ondersteunen de agile aanpak om snel tot een resultaat te komen dat met de opdrachtgever kan worden gedeeld. Juist het onderzoek in het EQuA project naar het belang van verschillende aspecten van teamwerk en de samenwerking tussen agile teams draagt bij aan goed functionerende ontwikkelteams. Zo omvat het EQuA project een aantal mooie voorbeelden van toegepast onderzoek waarbij onderzoekers en werkveld samen tot oplossingen van praktische problemen zijn gekomen. Early quality assurance is een stukje concreter geworden. 1 Micro-Machinations zijn elementaire spelhandelingen van waaruit het verloop van een spel kan worden samengesteld. 8 Softwarekwaliteit? Natuurlijk!

11 Het belang van requirements Softwarekwaliteit? Natuurlijk! 9

12 10 Softwarekwaliteit? Natuurlijk!

13 Waar zijn de requirements? Kwaliteit van wijzigingsverzoeken in open source en agile projecten Petra Heck, Fontys Hogeschool ICT Steeds meer bedrijven gaan agile werken (zie bijvoorbeeld xebia.nl/ebook/). Deze manier van werken houdt onder andere in dat de requirements (binnen agile ook wel in de vorm van use cases of user stories) aan het begin van een ontwikkeltraject vaag gespecificeerd worden en pas op het moment van implementeren verder in detail worden uitgewerkt. Zo wordt voorkomen dat van tevoren veel tijd besteed wordt aan het detailleren van requirements die later toch weer wijzigen. De detailuitwerking wordt bij een agile manier van werken ook niet altijd op papier vastgelegd, maar bijvoorbeeld in mondelinge conversaties met de klant of op whiteboards. Het beheren van de requirements gebeurt soms op papieren kaarten op een zogenaamd scrum board maar vaak ook in digitale varianten daarvan (tools als Excel, VersionOne, Jira, Scrumwise, Trello, zie agilescout.com/best-agile-scrum-tools/). Open source projecten kennen al langer een vergelijkbare manier van werken. Zij gebruiken issue trackers als Bugzilla en Jira om personen van binnen en buiten het project de mogelijkheid te geven online nieuwe wijzigingsverzoeken (vraag voor toevoegen, wijzigen of uitbreiden van een feature) door te geven. Op het moment dat een van de ontwikkelaars aan de feature gaat werken, kan hij real-time feedback vragen aan de aanvrager of aan andere deelnemers door commentaar toe te voegen aan het wijzigingsverzoek. Het bijzondere hieraan is dat zo dus ook de informele discussie wordt vastgelegd (bij agile werken gebeurt dit vaak niet). Dit vastleggen is bij open source projecten ook nodig omdat de ontwikkelaars vaak niet gelijktijdig en ook niet op dezelfde locatie aan het project werken. De vraag `waar zijn de requirements? kan voor agile en open source projecten dus beantwoord worden met: `niet in complete van tevoren geschreven requirementsdocumenten, maar wel als losse (initiële) requirements in digitale tools. Wij zullen dit soort requirements samenvattend Just-In-Time (JIT) noemen. Een eerste analyse van wijzigingsverzoeken in open source projecten heeft ons laten zien dat er diverse problemen rondom de kwaliteit zijn. Een belangrijk voorbeeld is het grote aantal dubbele wijzigingsverzoeken in open source projecten: meerdere aanvragers vragen onafhankelijk van elkaar eenzelfde wijziging aan. Voor sommige projecten is het aantal dubbelen wel 30%. Dit vertroebelt het zicht op de werkelijke Softwarekwaliteit? Natuurlijk! 11

14 requirements en als men met een aantal ontwikkelaars remote probeert samen te werken is er zelfs kans op het verschillend implementeren van dezelfde requirement (doordat ieder ontwikkelaar een verschillend verzoek van het dubbele paar als uitgangspunt neemt en zo de dubbeling onopgemerkt blijft). Dit eerste onderzoek heeft ons bij de vraag gebracht: hoe moet je kwaliteit van dit soort wijzigingsverzoeken definiëren? Sommige criteria die voor traditionele requirements (het document waarin alles van te voren is gedetailleerd) gelden, hoeven niet per se te gelden voor JIT requirements. Die mogen bijvoorbeeld op papier vaag (niet SMART) zijn omdat discussies later de details gaan invullen. Maar toch wordt een deel van de JIT requirements wel degelijk vastgelegd. En het is algemeen aanvaard dat wat we vastleggen in ontwikkeltrajecten moet voldoen aan bepaalde kwaliteitscriteria. Maar welke kwaliteitscriteria gelden dan voor JIT requirements? Om die vraag te beantwoorden hebben wij een onderzoek opgezet in vier stappen: Analyseren van literatuur over traditionele requirements om te kijken welke criteria nog steeds gelden voor JIT requirements; 1. Analyseren van literatuur over JIT requirements om te kijken welke nieuwe criteria wij kunnen toevoegen; 2. De criteria samenvatten in een overzichtelijk raamwerk (zie Figuur 1); 3. Het raamwerk valideren met een aantal practitioners. Voor stap 1 en 3 hebben wij onder andere gebruik gemaakt van eerder werk op het gebied van kwaliteit van traditionele requirements. Het product-certificatie-model (zie de literatuurverwijzing aan het eind van dit artikel) bevat een indeling en een aantal criteria die zonder meer bruikbaar zijn voor JIT requirements. Zoals te zien is in Figuur 1 bestaat het raamwerk uit 3 onderdelen die wij graag willen controleren: [VC1] [VC2] [VC3] Compleetheid: Zijn alle belangrijke onderdelen of attributen van de JIT requirement ingevuld? Uniformiteit: Zijn de JIT requirements in een uniform format vastgelegd? Correctheid & Consistentie: Voldoet de inhoud van wat er beschreven staat aan de richtlijnen voor JIT requirements? Deze drie onderdelen zijn het belangrijkste van het raamwerk. Ieder project of team kan dan voor de eigen situatie nagaan welke criteria daar onder zouden moeten vallen. Zo is er voor user stories een apart template in de vorm als <rol> wil ik <functie> zodat <business value>. Als een team hiermee werkt dan kan dit onder [VC2] worden toegevoegd. In Figuur 1 staat een voorbeeldlijst van criteria voor user 12 Softwarekwaliteit? Natuurlijk!

15 stories en feature requests (wijzigingsverzoeken in open source projecten). Voor meer details over de verschillende criteria verwijzen we graag naar ons uitgebreide artikel. Figuur 1: De criteria in italic gelden alleen voor user stories, de rest geldt voor user stories en feature requests Voor het valideren van het raamwerk hebben wij de verschillende criteria vertaald in een Excel checklist en die vervolgens voorgelegd aan 8 personen uit de Nederlandse agile community. Wij hebben hun mening over kwaliteit van agile requirements in het algemeen gevraagd, maar ze ook met de checklist een aantal open source requirements laten beoordelen zodat ze hun mening over het raamwerk konden geven. Voor dat laatste doel hadden wij zelfs een scoringsalgoritme in de checklist ingebouwd om de kwaliteit van verschillende requirements te kunnen vergelijken. Ieder van de deelnemers was het erover eens dat kwaliteit van agile requirements belangrijk is. Zij vonden het raamwerk over het algemeen nuttig als hulpmiddel om de kwaliteit van agile requirements te beoordelen. Zij hadden twee soorten opmerkingen: 1) aanvullingen op de criteria en 2) over de scoringsregels. Voor wat betreft de aanvullende criteria waren dit vaak bedrijf- of projectspecifieke criteria (bijv. is er een akkoord van de product owner?) die wij niet in het algemene model hebben opgenomen. Maar zoals gezegd laat het raamwerk voldoende ruimte voor het schrappen of toevoegen van eigen criteria. Voor wat betreft de scoringsregels is de conclusie dat deze in de meeste gevallen niet nodig zullen zijn: men wil agile Softwarekwaliteit? Natuurlijk! 13

16 requirements niet scoren op een absolute schaal maar vooral kijken waar nog mogelijkheden voor verbetering zijn. Samengevat kan men het raamwerk gebruiken om eenmalig vast te leggen wat de organisatie of het team acceptabel vindt voor JIT requirements, maar ook bijvoorbeeld opnemen in de Definition of Ready (een agile term die een quality gate voor requirements aangeeft) zodat iedere keer snel gecheckt wordt of er nog kwaliteitsproblemen met een agile requirement zijn. De criteria en requirements hoeven dan niet gescoord te worden op een schaal van 1 tot 10, maar veel meer wordt er dan gezocht naar mogelijke schendingen van één van de criteria. Als er schendingen zijn dan is het nog altijd aan de beoordelaar om te bepalen of dat in dit geval wel of niet acceptabel is. Bijvoorbeeld een hele duidelijke of standaard requirement hoeft niet per se een beschreven rationale te hebben. In de toekomst willen wij dit raamwerk graag toepassen in bestaande open source en agile projecten om meer praktijkervaring op te doen met de verschillende criteria. Maar u kunt ook alvast uw voordeel doen met dit raamwerk als checklist van wat belangrijk is bij kwaliteit van JIT requirements of om de discussie hierover in uw team of organisatie op gang te brengen. Succes met de requirements! Wie meer wil lezen: Project deliverables [6], [7] en [8] Ernst N., Murphy G., Case studies in just-in-time requirements analysis. Int l Workshop on Empirical Requirements Engineering (EmpiRE), IEEE, 2012 Heck P., Klabbers M., and Eekelen, M. C. J. D. van., A software product certification model, Software Quality Journal, vol. 18, no. 1, pp , 2010 Leffingwell, D., Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, 1st ed. Addison-Wesley Professional, Softwarekwaliteit? Natuurlijk!

17 Neem Requirements Serieus! Frank Peeters, Fontys Hogeschool ICT Te ontwikkelen software zou moeten beantwoorden aan de behoefte van zijn toekomstige gebruikers. Het is bovendien wel zo professioneel als er bij de oplevering kan worden vastgesteld of dat doel inderdaad is bereikt. Als de softwareontwikkeling doelgericht is ingericht, zal deze behoefte op de een of andere manier in kaart moeten worden gebracht. Dit leidt tot een verzameling (user) requirements, in welke vorm dan ook. Acceptatietesten geven meestal aan dat er een mismatch bestaat tussen de opgeleverde software en de requirements. Er ontbreekt te vaak voldoende zorg voor de realisatie van alle requirements. Hoe verder men in het ontwikkelingstraject op stoom raakt, des te meer dreigen de requirements uit beeld te geraken. Ze worden dan niet in voldoende mate serieus genomen. Softwareontwikkeling is vergelijkbaar met het bouwen van een huis of een brug of het fabriceren van een printplaat. Toch zijn er een aantal aspecten die het doelgericht bouwen van software, in vergelijking tot andere engineering disciplines, nogal compliceren. De toekomstige gebruikers staan meestal aan de zijlijn. Zij worden normaliter vertegenwoordigd door een of meer personen; wij noemen hen de producteigenaren. Het proces van afstemmen tussen ontwikkelaars en gebruikers lijkt hierdoor eenvoudiger te worden. Doch, al te vaak blijkt dat een producteigenaar niet in voldoende mate rekening kan houden met de, verschillende, behoeften van zijn of haar toekomstige gebruikers. Requirements zijn bij de aanvang bovendien niet volledig duidelijk. Mede naar aanleiding van tussentijdse validaties zullen requirements regelmatig worden aangepast. De extra handicap waarmee software engineers, in vergelijking tot de meeste andere engineers, dus opgescheept worden, zijn de wijzigingen in de requirements die er gedurende de bouw optreden. Een softwareontwikkelmethode moet hierop voorbereid zijn. Ons onderzoek was gericht op het doelgericht realiseren van de software die de domeinklassen 2 omvat. Niet-functionele requirements, zoals gebruiksvriendelijkheid, betrouwbaarheid, beveiliging en snelheid lagen buiten het bereik van ons onderzoek. Onze kernvraag was: Hoe kun je ervoor zorgen dat de domeinklassen blijven matchen met de, aan verandering onderhevige, user requirements? 2 Ofwel de klassen die de business logic vastleggen. Softwarekwaliteit? Natuurlijk! 15

18 Omdat rechtstreekse vertaling van user requirements naar domeinklassen ons onmogelijk lijkt, zal de brug tussen requirements en software, in de vorm van een of ander design (zie figuur 1), ook moeten blijven matchen. Figuur 1: Design als brug tussen User Requiremenst en Domain Software Wij hebben een model driven methode en ondersteunend tool, met de naam Symbiosis, ontwikkeld, die afdwingt dat elk requirement expliciet is verankerd in een element van het design. Vanuit het design worden de domeinklassen automatisch gegenereerd. Als de requirements veranderen, dan zal het design veranderen en de domein software zal zich hierin slaafs schikken. Als een ontwikkelaar het design autonoom aanpast, worden er extra requirements gegenereerd. Elk, handmatig ingevoerde of automatisch gegenereerde, requirement moet uiteindelijk door een producteigenaar worden gevalideerd. Om ervoor te zorgen dat het validatieproces op een nauwkeurige manier verloopt, is er voor gekozen om alle requirements in de natuurlijke taal van de producteigenaar uit te drukken. De requirements zijn opgedeeld in vier categorieën: actie, regel, feit en kwaliteitsattribuut. Een actie beschrijft een handeling die een gebruiker met de software moet kunnen uitvoeren. Een actie kan worden beschouwd als een voorbereidende stap op een use case. Een regel beschrijft een beperking op de toestand of de toestandsovergang van domeinobjecten, of er wordt door middel van een regel een automatische toestandsovergang gedefinieerd. Acties en regels zijn gebaseerd op vereiste informatie. Elk vereist informatie-element wordt in de vorm van een feit requirement vastgelegd. Ten slotte, een kwaliteitsattribuut is niets anders dan een niet-functionele eis. Gedurende de ontwerpfase worden de relaties tussen objecten volledig gebaseerd op de aanwezige fact requirements. Tijdens de transformatie van fact requirements naar een design worden default rule en action requirements gegenereerd. De ontwikkelaar configureert vervolgens het design met extra constraints en permissies voor het toevoegen, veranderen en verwijderen van objecteigenschappen. Elke configuratiestap leidt tot een synchronisatie met de actuele requirements. De handmatig ingevoerde rule requirements die nog niet binnen het design zijn gerealiseerd, vereisen wel nog een algoritmische specificatie die binnen het design 16 Softwarekwaliteit? Natuurlijk!

19 zelf wordt verankerd. Nadat het design de check op een aantal meta-regels heeft doorstaan, kan de volledige broncode van alle domeinklassen worden gegenereerd. De feit en de regel requirements zitten dan inmiddels in de domeinklassen opgesloten; resteert nog de realisatie van de actie requirements. Een substantieel deel van deze acties is gegenereerd naar aanleiding van het configureren van het design. Elke gegenereerde actie kan automatisch worden getransformeerd in een zogenaamde action case, hetgeen een gecompileerde class realisatie van de normale flow in een atomaire use case omvat. De overblijvende, handmatig ingevoerde, acties worden vervolgens gerealiseerd op basis van een assemblage van de tool box met action cases, hierbij kan dan en passant rekening worden gehouden met de nietfunctionele eisen. Tijdens het ontwikkelen van software worden de requirements regelmatig toegevoegd, aangepast of verwijderd. Elke wijziging moet worden gekeurd door de verantwoordelijke producteigenaar. Na de goedkeuring wordt het design op orde gebracht en kunnen de domeinklassen en action cases weer worden gegenereerd. Onze werkwijze maakt het mogelijk dat een design exclusief op zijn requirements is gebaseerd. Zodra alle requirements goedgekeurd zijn, heb je ook de zekerheid dat het design en daarmee alle gegenereerde domeinklassen en action cases compleet zijn. De niet-functionele eisen kunnen vervolgens op een elegante manier worden meegenomen zodra men toekomt aan de verfijning van de samengestelde action requirements. Ons devies luidt: Neem requirements serieus! Wie meer wil lezen: Project deliverables [13], [16], [18], [21] Softwarekwaliteit? Natuurlijk! 17

20 Symbiosis en de praktijk van Beech.it Interview met Bram Verhaegh, directeur Beech.it Vooraf In het EQuA project is de Symbiosis tool ontwikkeld, zie het voorafgaande artikel van Frank Peeters. De tool is, tijdens de ontwikkeling, in pilots uitgetest door Beech. it uit Venlo. Beech.it is een bedrijf dat zich vooral richt op het verzorgen van de techniek van technisch complexe websites en applicaties. Het bedrijf werkt voor diverse klanten in diverse sectoren. Sinds het begin van 2013 neemt Beech.it deel aan het EQuA project. In dit interview legt directeur Bram Verhaegh uit wat de beweegredenen waren om in het project te stappen en kijkt hij terug op het project. Beech.it Beech.it maakt gebruik van open source software, met als kern TYPO3 producten. TYPO3 is een open source enterprise CMS. Het bedrijf is actief lid van de TYPO3 community (alles bij elkaar zo n 75,000 ontwikkelaars wereldwijd) en is active contributer aan de core. Daarnaast is Beech.it al 2 jaar mede organisator van een succesvol internationaal barcamp voor de community. De kwaliteit van software staat bij Beech.it hoog aangeschreven. Code reviews, coding guidelines, automatische tests op code kwaliteit en security issues Beech.it maakt er gebruik van. In de TYPO3 community is er veel aandacht voor de kwaliteit van ontwikkelde code. Bram: Het kritisch vermogen van de community is groot: bijvoorbeeld van alle uitbreidingen wordt de kwaliteit gemeten met Sonar. Een ontwikkelaar is verplicht om belangrijke issues te verhelpen. Code wordt door veel mensen kritisch beken en meerdere malen gerefactord voordat ze geaccepteerd wordt en in productie gaat. Dat gaat niet altijd vanzelf. Soms zie je stevige discussies, als iemand lang heeft zitten werken aan code die vervolgens niet direct geaccepteerd wordt. Maar, ontwikkelaars kennen ook veel passie om kwaliteit te leveren en zijn voortdurend bezig om zichzelf te verbeteren en te leren van elkaar. Bij een bedrijf moet de mindset er zijn om kwaliteit van software vanaf de eerste ontwikkelfase centraal te stellen. Je moet daar vanaf het begin aandacht aan schenken. Dit halverwege het project inbrengen gaat niet lukken. Tijdsdruk leidt soms tot sub-optimale code, ook bij Beech.it. Het bedrijf gaat daar zo zorgvuldig 18 Softwarekwaliteit? Natuurlijk!

21 mogelijk mee om: de code wordt gemarkeerd om later alsnog verbeterd te worden. Zoals bij veel bedrijven is ook bij Beech.it de ervaring dat klanten daar niet altijd voor willen betalen. Dit blijft een grote uitdaging en vraagt ook bewustwording bij de klant. Aandacht voor requirements In juni 2012 was Bram één van de bezoekers van het EQuA symposium in Eindhoven. Tijdens dat symposium vertelde onderzoeker Frank Peeters over zijn onderzoek naar het omgaan met requirements en de Symbiosis tooling die hij daarvoor aan het ontwikkelen was. Het scherp neerzetten van requirements en het automatisch genereren van code vanuit de requirements sprak aan. De afspraak voor samenwerking was snel gemaakt. Zakelijk werd de samenwerking vormgegeven door het opnemen van Beech.it in het EQuA consortium. Inhoudelijk werd gestart met het gezamenlijk uitwerken in Symbiosis van een aantal use cases voor een applicatie die Beech.it aan het bouwen was. Dat ging niet vanzelf, het was wel nodig om de ontwikkelaars van Beech.it te trainen in de zienswijze achter de tool en de werkwijze van de tool. Daarnaast was inspanning nodig om de tooling stabiel te krijgen. Beech.it fungeerde min of meer als bèta-tester. Bram vond dat geen probleem. Ik ben heel goed in het om zeep helpen van de tooling! Bram kan het niet laten om een opmerking in de zijlijn te plaatsen: als ook in dit project bij de ontwikkeling van de tool de kwaliteitsrichtlijnen voor het ontwikkelen van software zouden zijn gehanteerd, bijvoorbeeld op het vlak van automatische tests en versiebeheer, dan zouden de stabiliteitsproblemen wellicht minder geweest zijn. Toch pleit Bram niet voor een redesign op dit moment. De tool kan beter eerst conceptueel verder ontwikkeld worden. Bram beschouwt de tool als een veelbelovende ontwikkeling op het vlak van samenspel tussen requirements en code. De tool kan je helpen bij het dichten van de gap tussen die twee. De mogelijkheden voor het genereren van code en het bijwerken van deze gegenereerde code vanuit wijzigende requirements spreekt Bram bijzonder aan. Nu wordt bij Beech.it een deel van de code al gegenereerd door het TYPO3 framework. Dat gaat vooral om de simpele basis als models, standaard acties binnen controllers en views, het type werk waar je je medewerkers niet mee wil belasten. Symbiosis voegt daar echt iets aan toe. Het maakt de software niet alleen goedkoper en beter beheerbaar, maar ook beter van kwaliteit. In de toekomst, als de tool stabieler is, dan is het naar verwachting een prima hulpmiddel bij het ontwikkelen van goede Softwarekwaliteit? Natuurlijk! 19

22 software. In een waterval project zou de tool volgens Bram onmisbaar zijn het geeft een goed beeld van de overall architectuur van de software. In een agile project (met kleine iteraties) kan het verwerken van de specificaties soms veel werk zijn. Contacten met het HBO Beech.it werkt al langer samen met het HBO, onder andere met de ICT opleiding van Fontys in Venlo en Eindhoven. Binnen projecten van het onderwijs, en via het verzorgen van een gastcollege. Daarnaast biedt Beech.it stageplaatsen aan. Bram ervaart wel een kloof tussen bedrijfsleven en onderwijs. In zijn ogen loopt het onderwijs soms achter ontwikkelingen zoals het gebruik van modern versie beheer, continuous intregration, automatische test frameworks e.d. Daarnaast is er in het onderwijs (te) weinig aandacht voor de kwaliteit van software, er wordt veel gesproken over kwaliteit terwijl dit concreet gemaakt kan worden en meetbaar. Bram staat dan ook positief tegenover de plannen van Fontys Hogeschool ICT voor het ontwikkelen van een minor rond het thema softwarekwaliteit. In de ogen van Bram zouden docenten vaker in contact moeten komen met het bedrijfsleven zij zouden bij voorkeur enkele dagen per week samen op moeten trekken met bedrijven. Bram staat open voor de samenwerking met het HBO, zeker met docenten. Zij kunnen die praktijkervaring vervolgens overbrengen op studenten. Het EQuA project Bram heeft een genuanceerde mening over het verloop en de resultaten van het EQuA project. De deelnemers vormden met elkaar een zeer gemêleerd gezelschap. De verschillende onderzoeken die in het project zijn uitgevoerd kenden te weinig verbinding, de schotten tussen de onderzoeken waren wel erg hoog. Daardoor ontstond te weinig binding met andere partijen, iedereen werkte te veel op een eigen eilandje. We hadden meer van elkaar kunnen leren dan nu is gebeurd. Bram vindt het jammer dat er niet een concrete toolkit voor softwarekwaliteit uit het project gekomen is. Het bedrijfsleven wil graag iets dat direct toepasbaar is. Toch kijkt Bram positief terug op het project. Het contact met Frank Peeters zal naar verwachting blijven bestaan. We willen samen een doel bereiken, met zijn tool! Zeker als we de testfase hebben afgerond is het een prima hulpmiddel. En, het enthousiasme en de gedrevenheid van Frank werken zeer aanstekelijk. 20 Softwarekwaliteit? Natuurlijk!

23 Een stage rond het genereren van code Interview met Joery van den Hoff, student Software Engineering, Fontys Hogeschool ICT Vooraf Joery van den Hoff is nu (najaar 2014) vierdejaars student bij Fontys Hogeschool ICT. In het voorjaar van 2014 heeft hij stage gelopen bij het bedrijf ISAAC in Eindhoven. Het onderwerp van zijn stage: codegeneratie voor het Symbiosis tool van EQuA onderzoeker Frank Peeters (zie het artikel eerder in deze uitgave). In dit interview kijken wij naar wat Joery gedaan heeft, horen wat zijn ideeën zijn over het Symbiosis tool en praten met hem door over de relaties tussen werkveld en opleiding. Het stagebedrijf ISAAC is specialist op het terrein van web- en middleware oplossingen, gebaseerd op betrouwbare en veilige (open source) software. Het bedrijf is gastheer geweest voor een aantal stages en afstudeerprojecten in het kader van het EQuA project, zowel van Fontys Hogeschool ICT als van de Technische Universiteit Eindhoven. ISAAC gelooft sterk in de noodzaak van het vroegtijdig opsporen van fouten en omarmt het gedachtengoed van het EQuA project. Codegeneratie De oorspronkelijke stageopdracht luidde: Voeg aan de codegeneratie in Symbiosis de mogelijkheid van JPA notatie toe. JPA (Java Persistence API) is een persistentie framework uit de Java wereld. Maar, aan die opdracht is Joery niet toegekomen, om de simpele reden dat er nog helemaal geen sprake was van codegeneratie in Symbiosis. Dus is Joery daar aan gaan bouwen. Concreet houdt dat in dat vanuit het objectmodel code wordt gegenereerd, met name voor de domeinlaag: klassedefinities met onder andere getters en setters. Aan het genereren van code voor het dynamische deel van een applicatie, vanuit het requirements model, is Joery niet toegekomen. Dat was ook niet zijn opdracht. Hij is er wel in geslaagd om een werkend geheel op te leveren. Codegeneratie werkt nu voor twee tot drie kleine casussen. De code die gegenereerd wordt is nog niet erg complex. Hieronder staat een voorbeeld, voor een internet boekwinkel. Softwarekwaliteit? Natuurlijk! 21

24 Figuur 1: Voorbeeld van gegenereerde code Joery is er nog niet van overtuigd dat de door hem gebouwde codegenerator in alle gevallen succesvol zal zijn. Bij toevoegen van meer casussen verwacht hij nieuwe problemen tegen te komen. Op de vraag wat hij van Symbiosis vindt volgt na enig nadenken een genuanceerd antwoord. De methode is interessant. Het is een leuke, nieuwe aanpak van het werken met requirements. Maar, het ontbreekt wel aan schaalbaarheid. Bij kleine casussen is het aantal requirements te overzien en lukt het wel om ze op te stellen in het formaat dat Symbiosis vereist. Maar bij grote projecten met heel veel requirements gaat dat naar verwachting niet meer lukken. Het oordeel van Joery over de kwaliteit van de tool is minder positief. Het gebruikersinterface is in zijn ogen zwak, de tool bevat een aantal bugs. Er is zo te zien onvoldoende nagedacht over de opzet, de architectuur. Blijkbaar was zorgvuldig ontwerpen en coderen niet het hoofddoel van het deelproject rond Symbiosis. Ervaringen in een bedrijf 22 Softwarekwaliteit? Natuurlijk!

25 Tijdens het grootste deel van zijn stage heeft Joery in z n eentje aan het Symbiosis tool gewerkt. Ongeveer een kwart van de tijd heeft hij meegedraaid in een projectteam van ISAAC. Dat was eigenlijk wel erg leuk. Daar zag hij van dichtbij hoe in de praktijk door een team software wordt ontwikkeld. Opmerkelijk: het heeft Joery ook tot het inzicht gebracht dat hij later niet software ontwikkelaar wil worden. Dag in dag uit code schrijven en testen, dat is me te beperkt. Bij voorkeur houdt hij zich ook bezig met ontwerpen en klantcontacten. Maar ja, zo begin je niet als software engineer. Opleiding en werkveld Hoe kijk je als student naar het bedrijfsleven? Lopen ze voorop bij nieuwe ontwikkelingen, of kunnen ze nog wat leren van de opleidingen? Joery heeft nog niet veel bedrijven van binnen gezien. Toch ervaart hij soms al wel een verschil, bij voorbeeld het gebruik in de opleiding van Svn voor versiebeheer, terwijl het werkveld al massaal is overgestapt op Git. Daar blijft de opleiding duidelijk achter bij nieuwe ontwikkelingen. Een ander verschil is het gebruik van een ontwikkelomgeving (IDE). Bij Fontys wordt, zoals bij veel opleidingen, gewerkt met NetBeans, terwijl je in de praktijk meer Eclipse tegenkomt. Maar, in het algemeen heeft Joery niet het idee dat de opleiding erg wereldvreemd is. Via de Partners in Education (bedrijven die actief een bijdrage leveren aan het onderwijs) komt veel informatie uit de praktijk bij de opleiding binnen. Joery vindt bedrijfscontacten tijdens de opleiding belangrijk. In die contacten zie je welke methoden en technieken in het bedrijfsleven gebruikt worden. En zie je hoe het werk van afgestudeerden er uit ziet. Softwarekwaliteit? Natuurlijk! 23

26 24 Softwarekwaliteit? Natuurlijk!

27 Software voor game development Softwarekwaliteit? Natuurlijk! 25

28 26 Softwarekwaliteit? Natuurlijk!

29 Talen voor Game Productie Riemer van Rozen, CREATE-IT, Hogeschool van Amsterdam Een focus op games Binnen het project is Riemer van Rozen docent-onderzoeker bij de Hogeschool van Amsterdam (HvA), en promovendus bij de Software Analyse en Transformatie (SWAT) groep van Centrum Wiskunde en Informatica (CWI). Met zijn begeleiders van CWI, Paul Klint en Tijs van der Storm, heeft hij ervoor gekozen om zijn onderzoek te richten op de creatieve industrie, een speerpunt voor de HvA, en op Domein- Specifieke Talen (Domain Specific Languages, DSLs), een onderzoekslijn van SWAT. DSLs worden gebruikt om met behulp van software problemen op te oplossen in een bepaald domein, bijvoorbeeld het beschrijven van financiële producten, het uitvoeren van digitaal forensisch onderzoek of het ontwikkelen van game spelregels. DSLs leveren experts formalismen en notaties die dichter bij hun belevingswereld liggen dan algemene programmeertalen, zodat een taak als het creëren en onderhouden van applicaties of het analyseren ervan geautomatiseerd kan worden. De onderzoeksvraag waar Riemer aan gewerkt heeft luidt: Hoe kan met DSLs voor game development een verbetering in productiviteit en kwaliteit behaald worden? Zoeken naar synergie tussen onderwijs, onderzoek en de beroepspraktijk is een hoofddoel van RAAK projecten. De kloof tussen software prototypes die worden geconstrueerd voor publish-or-perish onderzoek en de time-to-market realiteit van de beroepspraktijk is groot. Voor het begaanbaar maken van nieuwe paden zoals het beschrijven en uitproberen van nieuwe methoden en technieken is in de beroepspraktijk weinig tijd beschikbaar. Mislukte experimenten kunnen een faillissement betekenen. Binnen het onderwijs bestaat er een gebrek aan tijd en expertise om onderzoek naar talen voor game ontwikkeling effectief vorm te geven. Daarnaast gaan technisch complexe onderzoeksresultaten al snel zo ver de diepte in dat ze voor onderwijsdoeleinden op hogescholen onbruikbaar zijn. Riemer ziet het als de uitdaging van docent-onderzoekers om in onderzoek, onderwijs en de beroepspraktijk gezamenlijke doelen te vinden en bruggen te bouwen, zodat problemen vanuit verschillende perspectieven kunnen worden opgelost. Die perspectieven geven een soort van ingrediënten die onderdeel zijn van de oplossing, en die kunnen worden gebruikt om een praktisch kader voor het onderzoek te bouwen. Dit kan door theorie en praktijkkennis toe te passen, nieuwe werkwijzen te formuleren, uit te voeren en hanteerbaar te maken voor de beroepspraktijk en voor het onderwijs. Wenselijke resultaten zijn begrijpelijk en Softwarekwaliteit? Natuurlijk! 27

30 toepasbaar, publicaties werpen licht op de onderzoeksvraag, afgeleid lesmateriaal is leerbaar, studeerbaar en toetsbaar, en opgeleverde tool prototypes zijn praktisch toepasbaar, simpel, flexibel, onderhoudbaar, robuust en snel. Het is de taak van de industrie om software prototypes verder te ontwikkelen. Aanpak: ontwikkelen, toepassen, valideren Softwarekwaliteit en game development zien wij inmiddels als een voor de hand liggende combinatie. Omdat de toenmalige consortiumpartners te kennen gaven niet over game development expertise te beschikken, hebben Riemer en CWI een partner gezocht om hun onderzoek mee te kunnen valideren. In november 2011 kwamen ze via tussenpersonen o.a. van Syntens in contact met Loren Roosendaal van IC3D Media. Samen delen ze een interesse in het verbeteren van de kwaliteit van game software en het automatiseren van onderdelen van productieprocessen. De samenwerking geeft gronding en praktische situaties om conceptuele problemen en vraagstukken te valideren. Ze hebben eerst enige tijd samengewerkt aan de analyse van de scripttaal Lua, een veelgebruikte taal in game development om delen van de software aanpasbaar te maken terwijl de software draait. Een nadeel van dynamische talen is dat vroegtijdig fouten vinden lastig is omdat fouten zich pas run-time manifesteren. Ze hebben met behulp van Rascal 3 enkele bestaande technieken voor statische analyse op Lua toegepast. Rascal is een meta-programmeertaal en een language workbench waarmee je talen en tools kunt bouwen, analyseren en onderhouden. Rascal wordt ontwikkeld bij de SWAT groep van CWI. Het praktisch toepassen van Rascal laat zien dat dit onderzoek waardevol is voor ander onderzoek. Het levert prototypes op die kunnen worden doorontwikkeld in de beroepspraktijk. Collega docent-onderzoeker Joris Dormans heeft bij de Hogeschool van Amsterdam de taal Machinations ontwikkeld. Dat is een visuele taal die dient als conceptueel gereedschap, informeel hulpmiddel en communicatiemiddel voor game designs. Het probleem is dat, hoewel het game designers zijn die spelregels formuleren en begrijpen hoe deze spelregels spelerservaringen beïnvloeden, het veelal software engineers zijn die ze in software implementeren. Riemer: Joris en ik onderzoeken hoe met Micro-Machinations (MM), een uitgebreide geformaliseerde subset van Machinations, game software verbeterd kan worden. Game designers kunnen ook schetsen met MM maar het grote verschil is dat de analyses ervan iets zeggen over hoe de game werkt, omdat de diagrammen functioneren als geïntegreerd onderdeel van een spel Softwarekwaliteit? Natuurlijk!

31 Wellicht is game design niet het eerste gebied waar je aan denkt bij het toepassen van formele methoden een collectie van wiskundige formalismen, algoritmen, methodes en tools om software mee te analyseren. Riemer: middels Rascal hebben we een vertaling gemaakt van MM naar PROMELA, de proces specificatie taal voor een model-checker. Het checken van systeem eigenschappen tegen alle mogelijkheden die het systeem kan aannemen stelt designers in staat om rigoureus spelregels te testen zonder de game te spelen. Het mooie eraan is dat designers feedback krijgen op het conceptuele niveau van MM omdat tegenvoorbeelden in tegenspraak met systeemeigenschappen het model in beweging zetten waardoor dit gedrag begrepen en gerepareerd kan worden. Hergebruik van software is ook in game development belangrijk. De MM Library 4 is een herbruikbare software bibliotheek voor het integreren van spelregels. MM is live, dat wil zeggen dat designers spelregels kunnen aanpassen terwijl het spel draait, tijdens het testen. Riemer werkt aan het valideren van de aanname dat meer kansen op het verbeteren van spelregels leidt tot betere game software en betere spelerservaringen. Vooruitblik De uitdaging in de laatste fase van een project is om de uitkomsten te borgen en voor langere tijd beschikbaar te maken zodat deze ook in de toekomst gebruikt kunnen worden. Riemer stipt enkele stappen aan die hij noodzakelijk acht. - Onderwijs. We hebben workshops georganiseerd voor derdejaars game development studenten over Micro-Machinations. Het dient als voorbeeld voor ontwikkelen van tools en talen. Rond dit topic zijn tal van afstudeeropdrachten denkbaar. - Publicaties. Om te garanderen dat onze publicaties te vinden zijn hebben we een website gehost op GitHub waar al het materiaal te vinden is. Dit is ook een uitstekende plek om slides te delen. - Onderzoek. In het SIA RAAK project Automated Game Design zetten we Micro- Machinations opnieuw in. Het biedt een platform voor toekomstig onderzoek, o.a. op het gebied van procedurele content generatie. - Disseminatie. We hebben de code van de Micro-Machinations taal beschikbaar gemaakt onder de 3-clause BSD open source license op GitHub, een open source repository. We pogen een levende community rond Micro-Machinations te bouwen zodat deze niet in de vergetelheid raakt nadat het project eindigt. - Valorisatie. We werken met IC3D Media aan het aanpasbaar maken van de game mechanics van de game Johnny Jetstream middels MM. We pogen een 4 Softwarekwaliteit? Natuurlijk! 29

32 overtuigend voorbeeld te geven dat gebruikt kan worden om game mechanics mee te leren modelleren. Afsluitend Samen met CWI heeft Riemer in het EQuA project uniek onderzoek gedaan en verrassende resultaten behaald met een bruikbare domein-specifieke taal voor game design en game development. Natuurlijk kan er met meer tijd, energie en financiering meer onderzoek gedaan worden. Van alle mogelijke ongebaande paden hebben ze er maar één bewandeld en begaanbaar gepoogd te maken. De hoop is dat die aanpak navolging zal vinden zodat er meer kennis ontstaat over het toepassen van taal georiënteerde oplossingen voor game productie. Wie meer wil lezen: Project deliverables [9], [10], [11] Over Rascal: Klint, P., van der Storm, T., & Vinju, J., EASY Meta-Programming with Rascal. Proceedings of the 3rd international summer school conference on Generative and transformational techniques in software engineering III, Springer-Verlag, 2011, Over game mechanics: Adams, E., & Dormans, J., Game Mechanics: Advanced Game Design New Riders Publishing, Softwarekwaliteit? Natuurlijk!

33 De kracht van serious games Een interview met Loren Roosendaal, IC3D Media IC3D Media IC3D Media uit Breda is een belangrijke speler op de internationale markt van serious games. Sinds begin 2013 nemen ze deel aan het EQuA project. Samen met onderzoekers van de Hogeschool van Amsterdam en Centrum Wiskunde & Informatica (CWI) heeft het bedrijf gewerkt aan software om het ontwerpen van games te vereenvoudigen. In een interview met Loren Roosendaal, oprichter en CEO, passeren veel onderwerpen de revue: het belang van serious games, het specifieke karakter van game software, de aandacht voor kwaliteit, de relatie met opleidingen en onderzoeksinstituten. Loren is op 11-jarige leeftijd begonnen met het programmeren van games. Via internet werkte hij samen met mede-ontwikkelaars over de hele wereld. Samen hebben ze een WO II variant van een bestaand spel ontwikkeld. Die variant werd in korte tijd 2,5 miljoen maal gedownload. Dat gaf wel een kick. IC3D Media is van het begin af aan een internationaal bedrijf. Na de start groeide IC3D Media tot 12 mensen. Daarvan zaten er twee (Loren en zijn broer) in Nederland, de rest zat over de hele wereld. Dat waren (deels) de jeugdcontacten van Loren. Serious games IC3D Media maakt trainingssoftware voor bedrijven en organisaties. Bijvoorbeeld: het trainen van reddingwerkers bij aardbevingen in Indonesië. Die kunnen met behulp van de trainingssoftware oefenen hoe te handelen in levensechte situaties: wat doe je als een gebouw ingestort is, welke hulpmiddelen heb je tot je beschikking, hoe kan je die het beste inzetten? Dit soort trainingssoftware heeft in de ogen van Loren een grote toekomst: mensen die vroeger in klaslokalen of uit dikke boeken leerden kunnen nu in 10 minuten per dag op hun tablet, laptop of pc interactief kennis en vaardigheden opdoen. Bovendien loont het trainen van hulpverleners. Er gaat veel mis omdat die mensen slecht getraind zijn. Loren geeft een voorbeeld: een groot deel van de dwarslaesies die ontstaan na een ongeluk is te voorkomen als mensen de apparatuur die ze gebruiken om iemand te bevrijden beter zouden gebruiken. Dat kun je trainen, aanleren, met serious games! Dit soort opbrengsten toont het maatschappelijk belang van serious games aan. Serious games dragen direct bij aan de kwaliteit van leven! Softwarekwaliteit? Natuurlijk! 31

34 Leerstrategieën spelen een belangrijke rol bij het ontwikkelen van serious games. Je moet op het juiste moment de juiste uitdagingen en beloningen aanbieden. Doe je dat niet dan haken mensen af omdat het spel te moeilijk of te makkelijk is. IC3D Media heeft op basis van eigen praktijkervaring hier veel inzicht in gekregen, grote stappen in gemaakt. Naast een goede leerstrategie is realisme in trainingen erg belangrijk. Er bestaat wetenschappelijk onderzoek dat zegt aan te tonen dat het niet zo belangrijk is hoe een poppetje er uit ziet. Loren is, op basis van eigen ervaring, overtuigd dat in een aantal gevallen het tegendeel geldt. IC3D Media is op dit vlak veel verder dan de meeste ontwikkelaars/bedrijven. Wij zijn in staat om veel meer details in onze games op te nemen. En daarmee maken we echt een verschil. Early quality assurance Hoe benadert IC3D Media early quality assurance? Dat begint met goed nadenken over de inhoud en de opbouw van een game: je moet van meet af aan de complexiteit en daarmee de omvang goed beheersen. Bij games ontstaat heel snel een zeer grote toestandsruimte. Die moet je vanaf het begin inperken. Ook besteedt IC3D Media veel aandacht aan code kwaliteit. Onderlinge code reviews houden de ontwikkelaars scherp. Daarbij is er ook expliciet aandacht voor de performance. Loren houdt een gloedvol betoog waarom het noodzakelijk is om bij het schrijven van performance-gevoelige code nauwkeurig te weten hoe de code door de hardware wordt verwerkt. De manier waarop een processor bijvoorbeeld gegevens in zijn cache zet, is zeer bepalend voor de performance, code (met name ook de gebruikte datastructuur) moet daarop afgestemd zijn. IC3D Media stelt hoge eisen aan de kwaliteit van haar medewerkers. De game design opleiding bij de NHTV (Breda) is in de ogen van Loren de beste in Nederland. Stagiairs van die opleiding zijn regelmatig te vinden bij IC3D Media. Maar ook de kwaliteit van afgestudeerden bij die opleiding is nog niet voldoende om bij IC3D Media als zelfstandig ontwikkelaar aan het werk te gaan. Het testen van games is een verhaal apart. Door het grote aantal mogelijkheden in een spel is test-driven development geen optie het is niet een kwestie van de juiste output leveren bij bepaalde inputwaarden. Uiteraard wordt er ook bij IC3D Media veel getest. Unit-tests worden gebruikt als het om meer technische zaken gaat, acceptatietests met opdrachtgevers en gebruikers als het meer om de gameplay elementen gaat. Probleem daarbij is wel dat opdrachtgevers soms van tevoren niet concreet weten wat ze willen. Pas tijdens de ontwikkeling van een game wordt een opdrachtgever zich bewust van wat de mogelijkheden zijn en van hoe die aan te passen zijn aan zijn wensen. 32 Softwarekwaliteit? Natuurlijk!