Softwarekwaliteit? Natuurlijk! Resultaten van 4 jaar EQuA project

Softwarekwaliteit? Natuurlijk! Resultaten van 4 jaar EQuA project

Softwarekwaliteit? Natuurlijk!

Uitgave ter gelegenheid van de afsluiting van het RAAK-PRO EQuA project

November 2014

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

Inhoud Voorwoord

5

Early Quality Assurance

7

Het belang van requirements Waar zijn de requirements? Neem Requirements Serieus! Symbiosis en de praktijk van Beech.it Een stage rond het genereren van code

9 11 15 18 21

Software voor game development Talen voor Game Productie De kracht van serious games

25 27 31

Agile software ontwikkelen Vijf jaar agile. Hosanna of Drama? Samenwerking tussen agile teams

35 37 43

Toegepast wetenschappelijk onderzoek Onderzoek in opleiding

47 51

De EQuA deliverables

54

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.


5

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


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


7

het modelleren van requirements inmiddels actief gebruikt in enkele bedrijven, en is de Micro-Machinations1 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 MicroMachinations 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


Het belang van requirements


9

10 Softwarekwaliteit? Natuurlijk!

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 http://agilesurvey2013. 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 http:// 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

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] Compleetheid: Zijn alle belangrijke onderdelen of attributen van de JIT requirement ingevuld? [VC2] Uniformiteit: Zijn de JIT requirements in een uniform format vastgelegd? [VC3] 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 wil ik zodat ’. Als een team hiermee werkt dan kan dit onder [VC2] worden toegevoegd. In Figuur 1 staat een voorbeeldlijst van criteria voor user


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


13

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. 37–55, 2010 • Leffingwell, D., Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, 1st ed. Addison-Wesley Professional, 2011.


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 domeinklassen2 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

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


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]


17

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!

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

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.”


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.


21

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


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.


23


Software voor game development


25


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 DomeinSpecifieke 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

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 Rascal3 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.”

3

http://www.rascal-mpl.org


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 Library4 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 MicroMachinations 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

https://github.com/vrozen/MM-Lib Softwarekwaliteit? Natuurlijk!

29

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, 222-289. Over game mechanics: • Adams, E., & Dormans, J., Game Mechanics: Advanced Game Design New Riders Publishing, 2012.


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!


31

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.


Onderzoek en opleiding Het ontwerpen en bouwen van (serious) games is een samenspel tussen game designers en game bouwers – de software ontwikkelaars. De een is vooral bezig met hoe het spel verloopt, hoe het er uit ziet, de ander vooral met hoe dat softwarematig te realiseren is. Op het snijvlak van die twee interessegebieden heeft IC3D Media samen met Riemer van Rozen van de Hogeschool van Amsterdam onderzoek gedaan, begeleid door het Centrum Wiskunde & Informatica. Zie ook het vorige artikel. Met de op de HvA ontworpen en gebouwde bibliotheek van Micro-Machinations (spelelementen) heeft IC3D Media een prototype van een game ontwikkeld. Het gebruik van de Micro-Machinations bibliotheek maakt het mogelijk om run-time elementen in het spel te wijzigen. Dat is zeer waardevol voor game designers. Loren ervaart de samenwerking met de onderzoekers van de Hogeschool van Amsterdam en CWI als zeer positief. “Het is erg leuk om samen uit te zoeken waar en hoe hun technologie bij ons in te zetten is en op basis van onze ervaring aanpassingen in die technologie voor te stellen.” Een voorbeeld van dat laatste is het ontwikkelen van een grafische editor voor Micro-Machinations. “Game designers zijn erg grafisch georiënteerd, die willen niet met teksten werken.” Loren is positief over zijn contacten met de (inter)nationale onderzoekswereld. ”Een onderzoeksomgeving stelt je in staat om te werken aan nieuwe concepten; erkenning in de internationale onderzoekswereld helpt je ook als bedrijf weer verder.” Hij weet dan ook zeker dat IC3D Media dit soort samenwerkingsverbanden in de toekomst voort gaat zetten. “Het is voor ons een natuurlijke manier van leven.” Hoe kijkt een bedrijf als IC3D Media aan tegen de Nederlandse wereld van software ontwikkelaars? Loren heeft een uitgesproken mening over hoe met name de grote softwareleveranciers omgaan met hun werknemers. “Die mensen worden snel aan een specialisme gekoppeld, zeg C# programmeren, en blijven daar heel lang in hangen. Dat bevordert routinematig werken en doodt creativiteit.” Loren is een fan van het bekende T-profiel: brede kennis, met op één of enkele punten veel diepgang. “Brede kennis is noodzakelijk. Maar, daarnaast moet je als software engineer het vermogen hebben om waar nodig de diepte in te gaan. Als je eenmaal die duik in de diepte ervaren hebt, dan ben je in staat om die op te zoeken als het nodig is.” Opleidingen moeten in zijn ogen dan ook zowel diversiteit als diepgang bieden. “Iedere drie maanden een ander onderwerp, een ander project, prima!” Docenten hebben, naar zijn ervaring, wel vaak brede kennis maar missen soms de vaardigheid om, met studenten, de diepte in te gaan. Daar kunnen mensen uit het bedrijfsleven, zoals Loren, een rol bij spelen.


33


Agile software ontwikkelen


35


Vijf jaar agile. Hosanna of Drama? Leo van der Aalst – Fontys Hogeschool ICT, Sogeti

In dit artikel wordt een top vijf van vier onderwerpen op het terrein van agile werken geschetst: vijf agile misvattingen, vijf agile valkuilen, vijf agile voordelen en vijf agile succesfactoren. Deze zijn gebaseerd op vijf jaar ervaring als agile consultant en agile trainer in meer dan 300 agile projecten. Dit waren niet alleen projecten in Nederland maar ook in vele andere landen. Hoewel het ruim 300 subjectieve meningen zijn, geeft dit uiteindelijk een objectief beeld van de actuele situatie met betrekking tot agile projecten. Daar waren zowel Hosanna als Drama projecten bij.

Algemene trends Agile aanpakken zijn al langer bekend, in ieder geval al vanaf 2001. Dat was het jaar waarin het agile manifesto met haar vier waarden en twaalf principes werd opgesteld door zeventien prominente softwareontwikkelaars. Toch heeft het daarna nog een tijd geduurd voordat agile aanpakken door IT-organisaties werden omarmd. Pas in de laatste vijf jaar is dit substantieel toegenomen. Het gebruik van een agile aanpak is van minder dan 20% in 2010 gestegen naar bijna 80% in 2014 (zie figuur 1).

Figuur 1: Gebruik van een agile aanpak in enigerlei vorm (%)

In 70% van de organisaties die een agile aanpak gebruiken, is dat scrum. Minder dan 15% van de organisaties gebruiken een andere aanpak, zoals Kanban, Feature Driven Development, Agile Unified Process, DSDM/Atern, Lean of Extreme Programming.


37

Een andere interessante trend is de afname van een agile aanpak in outsource trajecten. Van bijna 80% vijf jaar geleden, naar minder dan 40% nu (zie figuur 2).

Figuur 2: Gebruik van een agile aanpak in outsource trajecten (%)

Als gevraagd wordt naar de tevredenheid over het resultaat van een agile project, dan zegt meer dan 50% tevreden te zijn. Dit wordt enigszins gekwantificeerd door een veronderstelde productiviteitstoename van 0 tot 50% met een gemiddelde van 20%, een kostenreductie van 0 tot 50% met een gemiddelde van 30% en een snellere time-to-market van 10 tot 60% met een gemiddelde van 30%.

Agile Misvattingen

Agile is het antwoord op alles! In ieder geval beter dan een traditionele softwareontwikkelaanpak, zo wordt gezegd. Helaas, in de praktijk blijkt dat niet zo te zijn. Iedere organisatie moet, misschien zelfs op projectniveau, een afweging maken welke aanpak te kiezen. Dat kan een agile aanpak zijn, maar in omgevingen met veel hiërarchie, vast omschreven procedures en processen, of enige vorm van certificering (o.a. luchtvaart, security) lijkt agile minder geschikt te zijn dan een traditionele aanpak.


In agile ontbreken processen, in agile wordt niet gepland en in agile ontbreekt discipline! Dit zijn wel heel vaak gehoorde misvattingen. In agile aanpakken bestaan, net als in traditionele aanpakken, wel degelijk processen. Dit zijn weliswaar lichtgewicht processen, die door het agile team worden aangepast aan hun eigen behoeften. En dan wordt er gezegd, iedereen doet maar wat, zonder planning en discipline. Het tegendeel is eerder waar! Ga maar na, hoe kun je in een iteratie van bijvoorbeeld twee weken werkende software opleveren zonder planning en discipline? Inderdaad. Niet dus! Release en iteratieplanningen maken vast onderdeel uit van agile aanpakken, waarbij scrum- of kanban borden, burndown charts en de daily scrum worden gebruikt om werkzaamheden transparant te maken en af te stemmen. Dit alles ondersteunt de planning om te komen tot het gewenste resultaat. En in plaats van het ontbreken van discipline is eerder een ijzeren discipline van de agile teamleden gewenst om dit resultaat als team binnen de iteratie te kunnen bereiken. Een hardnekkige vijfde misverstand is dat er in agile niet wordt gedocumenteerd. In het algemeen wordt door het agile team alleen gedocumenteerd wat nodig is om als agile team het werk te kunnen doen of waar stakeholders een belang bij hebben. In het ene geval is dat minimaal, omdat de teamleden precies weten wat ze moeten doen en wat ze van elkaar kunnen verwachten. In het andere geval kan dat meer zijn, omdat er wellicht eisen zijn gesteld aan bijvoorbeeld onderhoudbaarheid of overdraagbaarheid van producten. Of omdat er wellicht een weten regelgeving-, of certificeringseis is, die meer documentatie vraagt dan voor het team nodig was om het product te maken.

Agile Valkuilen

Je zult maar als IT-er al jaren met een bewezen goedwerkende softwareontwikkelaanpak werken en dan beslist het management op een goede - of kwade? - dag dat er nu agile gewerkt moet gaan worden en dat, ‘by the way’, die goedwerkende aanpak niet meer kan worden gebruikt. Het overboord gooien van bestaande softwareontwikkelprocessen is een vaak voorkomende valkuil. Want wat staat er nu helemaal in het agile manifesto of in de scrumaanpak over hoe je software moet ontwikkelen? Over hoe je requirements, functionele specificaties Softwarekwaliteit? Natuurlijk!

39

als user stories of use cases, technische specificaties, datamodellering, systeemen software architectuur, software, tests, moet opstellen en maken? Niets toch? Dus dan lijkt het verstandig niet het kind met het badwater weg te gooien, maar goedwerkende onderdelen van de softwareontwikkelaanpak – en testaanpak - te blijven gebruiken of aan c.q. in te passen aan de agile situatie. Vrijwel alle methoden zijn goed doordacht en werken prima als ze worden gebruikt zoals ze zijn bedoeld. Denk aan SDM, JSD, RUP of PRINCE2. Bij de implementatie van een agile aanpak als scrum is vaak een gedeeltelijke adoptie te zien. Even zo vaak blijkt dat zowel een bewuste als een onbewuste keuze te zijn. Zelfs een bewuste keuze door middel van ‘cherry picking’ leidt in de meeste gevallen tot – veel – minder succes dan een volledige adoptie. Het bekende gezegde ‘hinken op twee gedachten’ doet hier opgang en is een notoire valkuil. Programmeren tot de laatste minuut. Wie komt dat niet bekend voor? Dit is een diepe valkuil, want dit betekent per definitie dat er geen werkende software aan het eind van een iteratie wordt opgeleverd. Alle agile aanpakken zeggen, in iets van elkaar afwijkende bewoordingen, dat een product pas gereed (‘done’) is, als het is getest en is geaccepteerd (‘ge-demo’t’) door de stakeholders. Daarbij brengt het korte termijn denken het risico op testen technical debt met zich mee. Door wel snel ‘iets’ - omdat bijvoorbeeld de ‘product owner’ dat wil - op een ‘quick and dirty’ wijze aan het eind van de iteratie op te leveren, kunnen code-, architectuur- en testgerelateerde onvolkomenheden in volgende iteraties aan het licht komen, die tot grote, kostbare of tijdrovende herstelactiviteiten kunnen leiden. En ineens zit je niet meer in een traditioneel ontwikkelproject, maar in een scrumteam. Nu maar hopen dat de andere teamleden hiermee kunnen omgaan, denk je. Dit is een heel typische valkuil, alles verandert, behalve …………. ik! Een menselijke eigenschap is dat mensen al gauw van zichzelf vinden dat ze iets wel kunnen, terwijl ze denken dat andere mensen daar meer moeite mee hebben. Maar in scrum is het van belang dat je zelf ook mee verandert. Dat gaat niet vanzelf, daar moet je echt iets aan doen.

Agile Voordelen


‘Burndown charts’, scrumborden met user stories, taken en kolommen, die laten zien of een user story bijvoorbeeld ‘in progress’ of al ‘done’ is. De actuele status van een scrumproject is vaak in één oogopslag te zien. In het algemeen kun je zeggen dat agile projecten transparanter zijn. En door de korte iteraties, de nabijheid van de stakeholders - via de ‘product owner’ - en de nauwe samenwerking in het scrumteam kunnen prioriteiten makkelijker worden bijgestuurd, waardoor sneller - op wat voor verandering dan ook -, kan worden gereageerd. De kwaliteit van producten is beter. Iedere IT-er kent wel de figuur met de schommel, die laat zien hoe de wens van de klant uiteindelijk – afwijkend – wordt gerealiseerd. Onderzoeken laten zien dat in traditionele omgevingen van de oorspronkelijk honderd gedefinieerde requirements er vijftig worden gerealiseerd, waarvan er uiteindelijk maar vijfentwintig door de klant worden gebruikt. Dat is nogal wat ’waste’, volgens Lean begrippen. Maar in een scrumproject zitten de stakeholders, zoals in vorige alinea beschreven, dicht op het ontwikkelteam. Een afwijking op het gewenste product wordt snel gezien en kan net zo snel worden hersteld. Ook als er nieuwe wensen zijn, of juist wensen die zijn vervallen, kan er snel worden ingegrepen, waardoor het gerealiseerde product (heel) dicht bij het gewenste product komt. Een ander voordeel is dat de ‘time-to-market’ in een agile project vaak met 10 tot 60% wordt verkort. Met andere woorden, de juiste producten worden ook nog eens sneller productieklaar opgeleverd! Vaak leven uitgebluste IT-ers helemaal op als ze in een agile project gaan werken. Of dat nu komt door het verlaten van een jarenlange sleur, of door het werken in een team aan een gezamenlijk doelstelling, of doordat het team meer verantwoordelijkheid heeft? Feit is, dat in agile projecten medewerkers vaak gemotiveerder zijn. Ze zijn gewoon ook blijer. Een niet te onderschatten emotie voor het behalen van goede resultaten.

Agile Succesfactoren

Ja managers, nu komt het er op aan. In het verleden was het zo, dat een team of de medewerkers de beslissingen van de manager vertrouwde en die opvolgden. Nu, in de agile aanpakken, is het de manager die de beslissingen van het agile team moet accepteren. Het is de manager die de mensen in het team moet vertrouwen en aan hen zoveel mogelijk vrijheden en (beslis)bevoegdheden moet geven. Om Softwarekwaliteit? Natuurlijk!

41

écht succesvol te kunnen zijn met de invoering van een agile aanpak is bedrijfsbreed commitment nodig. De invoering vereist meestal een cultuuromslag of minimaal een cultuuraanpassing, waardoor het bijvoorbeeld heel gebruikelijk is dat mensen die niet in een agile omgeving kunnen werken het bedrijf verlaten en andere mensen daarvoor in de plaats komen. Ook voor de teamleden komt het er nu op aan. Succes wordt alleen bereikt als het team daadwerkelijk als team acteert. Dus niet werken in silo’s van ontwerpers, programmeurs, testers en gebruikers. Maar allemaal samen. Verder moeten alle ontwikkelprocessen worden geïntegreerd. Dus bijvoorbeeld geen losstaand ontwikkelen testproces, maar volledig geïntegreerd gelijktijdig ontwerpen, programmeren en testen. Deze integratie geldt ook voor alle teamleden en activiteiten. Iemand in een programmeursrol moet bereid zijn andere activiteiten op te pakken, bijvoorbeeld testactiviteiten. Iemand in de testrol moet ook bereid zijn bijvoorbeeld testautomatiseringsactiviteiten op te pakken of de product owner te helpen bij het opstellen van de user stories. Dit alles is uiteraard afhankelijk van de kennis en kunde van de desbetreffende persoon. In het algemeen kun je zeggen, ieder teamlid beheerst één discipline uitstekend en is bereid een tweede of een derde bij te leren. Teamleden in een agile team zijn multidisciplinair. Zoals uit bovenstaande alinea’s blijkt, heeft de invoering van een agile aanpak nogal wat voeten in de aarde. Er zijn veel organisaties die daar mee worstelen, om niet te zeggen, maar wat aan modderen. Zeker ook omdat er, vooral bij bepaalde managers, weerstand tegen de verandering bestaat. De echte ‘key’ succesfactor is dan ook voor het zorgen van begeleiding bij de invoering van een agile aanpak. Bijvoorbeeld in de persoon van een veranderingsmanager of scrum coach. De invoering van een agile aanpak is een leertraject en gaat gepaard met vallen en opstaan. De ene keer is de invoering sneller succesvol dan de andere keer. Het is belangrijk om telkens te leren van de gemaakte fouten en die in bijvoorbeeld een volgende iteratie weer te verbeteren. Dus niet te snel opgeven. Wees ook niet bang fouten te maken. Want hier geldt, ‘fail to succeed’!

Conclusie Thomas Edison heeft ooit gezegd, “I haven’t failed. I’ve just found 10.000 ways that won’t work.” In dit artikel vindt u hopelijk voldoende inspiratie om een eventueel Drama project in een Hosanna project te veranderen. Of nog beter, direct een Hosanna agile project te starten! Waardoor u niet op poging 10.001 hoeft te wachten!


Samenwerking tussen agile teams Een interview met Evelyn van Kelle, Software Improvement Group / Universiteit van Tilburg

Vooraf Als je het over het verbeteren van de kwaliteit van software hebt, dan gaat de aandacht al snel uit naar producten: code, documenten, ondersteunende tools. Kort na de start van het EQuA project is een onderzoek in het werkveld uitgevoerd naar onder andere de factoren die bepalend zijn voor de kwaliteit van de opgeleverde software. Daar kwamen, om eerlijk te zijn een beetje tot onze verrassing, niet aspecten als heldere requirements, goede tools, voldoende tijd voor testen, als eerste naar voren. De belangrijkste succesfactor voor de softwareontwikkelaar bleek de kwaliteit van de teamgenoten en de samenwerking met de teamgenoten te zijn. Reden om in het EQuA project ook hier onderzoek naar te doen.

SIG en Evelyn van Kelle De Software Improvement Group (SIG) is één van de bedrijfspartners in het EQuA project. Het meten van de kwaliteit van software is een van de speerpunten van SIG. Zij zijn zeer geïnteresseerd in de vraag welke factoren het werk van softwareontwikkelteams positief beïnvloeden. SIG heeft, in het kader van het EQuA project, een aantal afstudeeronderzoeken rond dit thema opgezet en begeleid. In 2013 heeft Emily Weimar, master studente Communicatie- en Informatiewetenschappen aan de Universiteit van Tilburg, bij SIG haar afstudeeronderzoek uitgevoerd rond het onderwerp ‘teamwerkkwaliteit’. In 2014 heeft Evelyn van Kelle, in het kader van haar afstuderen bij dezelfde studierichting, samen met SIG een onderzoek uitgevoerd naar succesfactoren in de samenwerking tussen en rondom agile teams. Twee voorbeelden van onderzoek uitgevoerd door niet-ITers, naar de “menselijke” kant van softwareontwikkeling. In dit interview vertelt Evelyn over haar onderzoek.

Agile teams en communicatie, leiderschap Al is ze geen ITer, Evelyn was vanuit een eerdere stage bij een software leverancier al wel bekend met de wereld van IT en agile software ontwikkelen. De stap naar SIG was dus niet helemaal een stap in het duister. Haar onderzoeksopdracht kwam op een vrij natuurlijke manier tot stand. Bij agile wordt vaak gedacht dat deze manier van werken vooral geschikt is voor kleine teams, kleine organisaties, kleine projecten. Softwarekwaliteit? Natuurlijk!

43

De vraag van SIG was hoe het kan dat in hun praktijk soms ook grote organisaties in grote projecten met meerdere teams met veel succes agile werken. Welke vormen van communicatie en leiderschap, binnen en tussen de teams, zijn van invloed op dat succes? Als student communicatiewetenschappen wil je daar best je tanden in zetten. Op zoek naar menselijke factoren op het vlak van leiderschap en communicatie die het succes van grote agile projecten beïnvloeden.

Een conceptueel model Als je in de literatuur gaat kijken dan vind je heel weinig over dit onderwerp. Daarom is Evelyn allereerst op zoek gegaan naar goede voorbeelden uit de praktijk. Wat werkt wel, wat werkt niet goed? Op basis van interviews met 7 mensen die hun sporen verdiend hebben in de agile praktijk bij grote organisaties heeft Evelyn een conceptueel model ontwikkeld met de belangrijkste factoren die invloed kunnen hebben op het succes van agile projecten, waarbij de focus ligt op communicatie en leiderschap. In het model zijn factoren opgenomen waarvan Evelyn verwacht dat ze invloed zouden hebben op project succes. De focus ligt op de sociale factoren die kunnen leiden tot gedeelde (werk)normen en –waarden en goede persoonlijke relaties; factoren die volgens de literatuur bepalend zijn voor effectieve samenwerking en goede performance.

Figuur 1: Conceptueel model


In de tweede fase van haar onderzoek heeft Evelyn op basis van dit model een vragenlijst opgesteld en die online voorgelegd aan een veertigtal agile projecten binnen 18 verschillende bedrijven. Dat waren heel verschillende bedrijven, ook niet allemaal heel groot. Wel ging het in veel gevallen om grote(re) projecten. Van ieder project zijn mensen met drie verschillende rollen benaderd: de product owner, een scrum master en een teamlid. In totaal hebben 141 mensen die vragenlijst ingevuld. De antwoorden zijn vervolgens met behulp van statistische technieken geanalyseerd, om een aantal opgestelde hypotheses te kunnen toetsen, om te kijken of het conceptuele model bruikbaar is. Hoe vind je 40 agile projecten in 18 bedrijven bereid om mee te doen aan zo’n onderzoek? Dat ging niet vanzelf. Evelyn: “Het netwerk van SIG was een goed startpunt. Daarnaast ben ik naar een aantal agile seminars en andere evenementen geweest, om mijn gezicht te laten zien en mensen te benaderen om mee te werken aan mijn onderzoek. Dat werkte goed, en zo terloops heb ik op die bijeenkomsten ook aardig wat opgestoken over agile werken! Mensen waren ook vaak enthousiast over agile werken en mede daarom snel bereid om mee te doen aan mijn onderzoek.”

Resultaten Evelyn: “Uit de resultaten blijkt dat project succes meer afhankelijk is van transformationeel leiderschap, perceived agility en value congruence dan van projectgrootte. Perceived agility en hoge value congruence zijn hierbij de belangrijkste factoren. Naast deze directe effecten zijn er ook indirecte effecten: leiderschap en communicatie zorgen ervoor dat aan het begin van een project de neuzen dezelfde kant op staan. In het model heet dit value congruence; die moet hoog zijn. Daardoor ontstaan er minder conflicten en krijg je betere resultaten. Hoge value congruence verklaart dus ook de relatie tussen leiderschap, communicatie en succes. Gemeenschappelijkheid – dezelfde normen en waarden – maakt ook dat je tijdens een project sneller op veranderingen kan reageren. En dat is zeker in (agile) IT-projecten heel belangrijk. Daarnaast zijn de resultaten wellicht ook bruikbaar buiten agile projecten of zelfs de IT. Het is aannemelijk dat deze factoren ook in andere sectoren belangrijk zijn binnen projecten. In dit onderzoek lag de focus op agile, maar vervolgonderzoek zou zich ook kunnen richten op andere sectoren om generaliseerbaarheid te toetsen.” Het uitvoeren van haar onderzoek leverde Evelyn ook een aardig inkijkje op in de Nederlandse IT-wereld. Evelyn is onder de indruk. “Ik ben veel zeer professionele bedrijven tegengekomen. Mensen wisten waar ze mee bezig waren en konden


45

me goed uitleggen hoe ze werken, en vooral ook het waarom. En, wat meehielp: mensen waren er vaak trots op om agile te werken. Ze geloofden erin.” Heeft ze iets gemerkt van het hype-karakter van agile, bedrijven die alleen “agile in-name-only” toepassen? Evelyn: “ja, niet ieder bedrijf waarmee ik in gesprek kwam wist duidelijk uit te leggen waarom ze agile werkten. Maar dat is een minderheid, en het heeft geen rol gespeeld in mijn onderzoek.”

Terzijde: onderzoek in de opleiding Voor haar afstuderen heeft Evelyn een volwaardig onderzoek uitgevoerd, inclusief literatuurstudie, opstellen hypotheses, verzamelen gegevens en het verwerken van de gegevens tot onderzoeksresultaten. “Dat heb ik zo geleerd, eigenlijk vanaf het allereerste begin van mijn opleiding. In allerlei vakken en projecten werd aandacht besteed aan het uitvoeren van een literatuurstudie, het opzetten en uitvoeren van kwalitatief en kwantitatief onderzoek, inclusief de statistische verwerking van resultaten.” Die bagage werkte zeer ondersteunend in haar afstudeeronderzoek. Zouden informatica-studenten op universiteiten en hogescholen nu ook die kennis en vaardigheden mee moeten krijgen? Evelyn: “Ik denk dat iedere HBO of WO student een basis moet hebben in die kennis en vaardigheden, en informatica-studenten dus ook. In verschillende vakgebieden worden deze vaardigheden wellicht anders en in verschillende mate toegepast. Dit neemt echter niet weg dat ik van mening ben dat iedere student basiskennis moet hebben van de verschillende onderzoeksmethoden. Het opstellen en toetsen van hypotheses en modellen, en statistische analyses uitvoeren is universeel, dus de basiskennis zou dat ook moeten zijn, vind ik.” Wie meer wil lezen: • Project deliverables [17], [19]


Toegepast wetenschappelijk onderzoek Verslag van een rondetafelgesprek met Andy Zaidman (TU Delft), Ion Barosan (TU Eindhoven), Tijs van der Storm (CWI)

In het EQuA project is vier jaar lang toegepast wetenschappelijk onderzoek uitgevoerd. Wat is dat eigenlijk? Wat maakt toegepast onderzoek bruikbaar? Wat doen universiteiten aan toegepast onderzoek? Wat is de rol van HBO-instellingen? Vragen die aan bod zijn gekomen in een rondetafelgesprek met drie universitaire wetenschappers die intensief aan het EQuA project hebben meegewerkt: Andy Zaidman (Technische Universiteit Delft), Ion Barosan (Technische Universiteit Eindhoven) en Tijs van der Storm (Centrum Wiskunde en Informatica in Amsterdam). In dit artikel een neerslag van dat gesprek.

Wat is toegepast wetenschappelijk onderzoek? Daar zijn de heren aan tafel het snel over eens: toegepast wetenschappelijk onderzoek moet problemen uit de praktijk (het werkveld) oplossen. En de gevonden oplossingen moeten gevalideerd worden: er moet in de praktijk bewezen worden dat een oplossing werkt. Daarbij valt ook de term “actionable research”: onderzoek waarvan de resultaten direct toepasbaar zijn in de praktijk. Uiteraard kent informatica veel toegepast onderzoek. Toepassingen van IT vind je overal in de maatschappij, veel informatica onderzoek is gericht op het creëren en verbeteren van die toepassingen. Als je meer specifiek naar software engineering kijkt, als wetenschap van het ontwikkelen van software, dan is bijna al het onderzoek eigenlijk wel toepassingsgericht. Het woord “engineering” in de naam geeft dat ook al aan. Het onderzoek in software engineering heeft wel een bijzondere kant in vergelijking met andere wetenschappen: het bouwen van de hulpmiddelen voor het onderzoek (tools, repositories) is op zich ook weer software engineering. “Wij zijn astronomen die hun eigen telescopen bouwen.” Dat maakt je eigen werk in potentie ook onderwerp van je onderzoek. Niet al het onderzoek dat op universiteiten plaats vindt is een direct antwoord op een vraag uit het werkveld. Zo werkt de TU Delft veel aan “software analytics”, het analyseren van data die afkomstig zijn uit repositories van grote programmeerprojecten. De inzichten die dat oplevert zijn wel relevant voor het werkveld. Zie het onderzoek van Petra Heck naar de kwaliteit van requirements, eerder in deze uitgave.


47

De scheidslijn tussen theoretisch en toegepast onderzoek is ook niet altijd even scherp: een bijna wiskundig vakgebied als grafentheorie kan zomaar belangrijk zijn in het analyseren van Facebook vriendennetwerken.

Het publicatieprobleem Veel onderzoek, ook op de universiteiten, is aan te merken als toegepast onderzoek. Voor een deel omdat het voor de financiering afhankelijk is van geld uit het bedrijfsleven en dus het bedrijfsleven invloed heeft op wat er onderzocht wordt. Maar ook omdat de onderzoeksvragen sowieso al vaak gericht zijn op het oplossen van praktische problemen. Daarbij wordt de universitaire onderzoeker wel geconfronteerd met het “publicatieprobleem”: onderzoeksresultaten worden doorgaans pas voor publicatie op een conferentie of in een tijdschrift in de wetenschappelijk wereld geaccepteerd als ze een zekere mate van universele geldigheid hebben. Soms werk je aan het oplossen van een probleem voor een specifiek bedrijf. Met name door niet-IT bedrijven worden software engineers dan nog wel eens gezien als de “loodgieters”: mensen die je helpen om specifieke praktische problemen op te lossen. Het bedrijf is dan niet geïnteresseerd in het veralgemenisering van de oplossing zodat die in de wetenschappelijke wereld gepubliceerd kan worden. En ja, publiceren is voor iedere universitaire wetenschapper een must, daar word je op afgerekend.

Goede onderzoeksonderwerpen Niet ieder bedrijf is in staat om goede onderzoeksvragen op te stellen. Dat maakt het lastig om samen met ze aan onderzoek te werken. Er is nog steeds sprake van een kloof tussen deze bedrijven en de wetenschappelijk wereld. Maar, er zijn zeker ook bedrijven die wel goede onderwerpen aandragen. Uit eigen ervaring geven de onderzoekers aan dat het persoonlijke contact een belangrijke factor in de samenwerking vormt. Vaak loont het om een langer lopend en productief contact tussen universiteit en bedrijf in stand te houden. Dan begrijp je elkaar van lieverlee steeds beter. Zowel kleine bedrijven als grote bedrijven kunnen goede partners zijn in toegepast onderzoek. Kleine bedrijven zijn doorgaans wendbaarder, minder bureaucratisch dan grote bedrijven. Daar staat tegenover dat grote bedrijven meer continuïteit kunnen bieden en aan grotere problemen werken. Als je de vakbladen leest dan draait het in de IT op dit moment vooral om een paar buzzwords: cloud computing, agile, big data. Spelen die onderwerpen nu ook een rol in het toegepast wetenschappelijk onderzoek? Het antwoord is genuanceerd: 48 Softwarekwaliteit? Natuurlijk!

“ja, want het bedrijfsleven heeft hier geld voor over en er zijn zeker interessante onderzoeksvragen te formuleren voor deze onderwerpen – nee, want wij geloven niet in iedere hype, dat zijn deels verkoopverhalen”. Opmerkelijk is de ervaring (uit het verleden) dat bedrijven nog wel eens alleen in naam achter een hype aanlopen: een bedrijf dat graag zijn applicatieportfolio in wilde brengen bij een onderzoek naar Service Oriented Architecture (SOA) bleek bij nader inzien welgeteld één service gedefinieerd te hebben. Deels wordt het (toegepast) onderzoek gestuurd door landelijke en Europese subsidiegevers. In Nederland speelt momenteel het ‘topsectorenbeleid’ een sturende rol bij het bepalen van de onderzoeksvragen. Handig als je daar bij aan kan sluiten, maar ook lastig als jouw onderzoek daar niet direct in onder te brengen is.

Onderzoek op het HBO Is (toegepast) wetenschappelijk onderzoek voorbehouden aan universiteiten of spelen hogescholen hier ook een rol in? In eerste instantie ligt het antwoord op deze vraag snel op tafel: ook van HBO studenten verwacht je dat ze op de hoogte zijn van de nieuwste inzichten en in hun werk gemotiveerde keuzes kunnen maken. En dat vereist onderzoeksvaardigheid. Op basis waarvan neem je beslissingen? Een kritische en inventieve houding is daarbij noodzakelijk. In tweede instantie komen de relativeringen: HBO studenten hoeven niet echt opgeleid te worden tot onderzoekers. Ze hoeven niet zelf een omvangrijk empirisch onderzoek of een diepgaand literatuuronderzoek uit te kunnen voeren. Want het onderzoek dat ze doen staat in dienst van het oplossen van problemen in het werk – voor software engineering studenten is dat doorgaans het zo efficiënt en effectief mogelijk bouwen van software voor een opdrachtgever. Daarvoor is die kritische en inventieve houding belangrijker dan een omvangrijke set van specifieke onderzoeksvaardigheden. Op dat vlak zie je trouwens grote verschillen tussen studenten, niet alleen op het HBO maar ook op het WO. Het onderscheid tussen HBO en WO moet in dit opzicht niet overdreven worden. Ook WO studenten komen in hun opleiding niet allemaal toe aan het ontwikkelen van onderzoeksvaardigheden. Eigenlijk leer je dat pas goed als je na je studie aan een promotietraject begint en daarin zelfstandig onderzoek uit gaat voeren.

Het EQuA project Een belangrijke doelstelling van het EQuA project was om de veronderstelde kloof tussen de wetenschappelijke wereld van de software engineering (de universiteiten) en het werkveld (de Nederlandse softwarebedrijven) te verkleinen. Is dat gelukt? De meningen zijn kritisch positief. Zo zijn de doelstellingen van een project soms Softwarekwaliteit? Natuurlijk!

49

anders dan de doelstellingen van wetenschappelijk onderzoek. Voor het project wil je bruikbare, direct toepasbare, tooling, ideeën, resultaten. En dat is, zeker voor een wetenschapper, soms niet meer dan simpelweg productiewerk. En bij wetenschappelijk onderzoek draait het toch nog steeds voor een belangrijk deel om publicaties. Om je werk gepubliceerd te krijgen moet het uniek zijn, moeten er duidelijke onderzoeksvragen beantwoord worden. Specifieke oplossingen voor een specifiek probleem worden daarbij vaak niet of minder gewaardeerd. Alle drie de gesprekspartners hebben dat probleem in het project aan den lijve ervaren. Daar staat tegenover dat de contacten met het werkveld positief worden gewaardeerd. Uiteraard was voor ieder van de onderzoeksinstellingen het EQuA project niet de eerste kennismaking met het bedrijfsleven, maar het project heeft wel geleid tot interessante nieuwe contacten. Ook met een buitenlands onderzoeksinstituut dat zeer geïnteresseerd bleek in binnen het EQuA project ontwikkelde tooling. De samenwerking met de HBO-instellingen wordt als positief ervaren. De HBO docenten waarmee in het onderzoek werd samengewerkt waren stuk voor stuk zeer gemotiveerd. HBO studenten bleken soms verrassend vaardig in het oplossen van praktische problemen. De samenwerking met de partnerbedrijven in het project wordt als wisselend ervaren. Er zijn zeker zeer interessante en goede onderzoeken uitgevoerd door of in samenwerking met deze bedrijven. Maar, helaas zag je ook de eerder genoemde moeite die bedrijven soms hebben om goede onderzoeksvragen te formuleren en daar capaciteit voor vrij te maken af en toe terug in het project. Een van de gesprekspartners vat zijn relaas op dit punt bondig samen: “voor mij is bijna 80% van de oorspronkelijke doelstellingen bereikt, en daar ben ik best tevreden mee. Want, laten we wel wezen: het realiseren van 80% van de doelstellingen is meer dan (helaas) tot op de dag van vandaag het gemiddelde IT project oplevert…”


Onderzoek in opleiding Jacob Brunekreef, Fontys Hogeschool ICT

Binnen het EQuA project hebben studenten een belangrijke bijdrage geleverd aan diverse onderzoeken. Soms als onderzoeker, soms als object van onderzoek. In dit artikel geven we van allebei die rollen een voorbeeld.

De student als onderzoeksobject Voor de software ontwikkelaar van nu is het gebruik van unit testen bijna vanzelfsprekend. Unit tests zijn bedoeld om kleine stukjes code (methods, functies) te testen. Je kan zo snel controleren of de code die je geschreven hebt daadwerkelijk doet wat je verwacht. Je kan unit tests ook gebruiken om na het aanbrengen van niet-functionele wijzigingen in de code te controleren of de code functioneel nog steeds hetzelfde doet. Niet-functionele wijzigingen, ook vaak refactorings genoemd, hebben veelal als doel om de code beter leesbaar, onderhoudbaar, te maken. In het najaar van 2011 hebben studenten meegewerkt aan een onderzoek naar de vraag of de beschikbaarheid van unit tests invloed heeft op de snelheid en de kwaliteit van refactorings. De groep van 35 studenten werd in tweeën verdeeld. Beide groepen kregen dezelfde code onder ogen. De ene groep kreeg ook unit tests voor die code, de andere groep niet. Beide groepen kregen de opdracht om individueel zeven refactorings op de code uit te voeren. De verwachting was dat de groep die de beschikking had gekregen over unit tests de refactoring opdrachten sneller en beter uit zou voeren. Om die verwachting te kunnen toetsen is gemeten hoe lang de studenten over een refactoring opdracht deden, en is de herschreven code achteraf nader geïnspecteerd. De uitkomsten van het onderzoek waren verrassend: er bleek geen statistisch aantoonbaar significant verschil aanwezig tussen de snelheid en kwaliteit van de refactorings zoals uitgevoerd door beide groepen. Zie ook de figuur op de volgende bladzijde. Daar waar de theorie zegt dat de beschikbaarheid van unit testen het refactoren van code sneller en beter maakt, bleek dat in dit experiment niet aantoonbaar. Dat levert de interessante vraag op of de theorie niet klopt, of dat het experiment niet deugde. Voor allebei is wat te zeggen. De theorie is gebaseerd op verwachtingen en een aantal experimenten. De keuze van de in het experiment uit te voeren refactorings en de metingen eromheen zijn misschien voor verbetering vatbaar. De uitkomst van het experiment was dan ook: meer onderzoek is wenselijk!


51

Figuur 1: Statistische analyse van de resultaten (voorbeeld)

De student als onderzoeker Voor informatica studenten, ook in het HBO, wordt het kunnen uitvoeren van een onderzoek steeds belangrijker. Waar je ook mee bezig bent, voortdurend dienen nieuwe ontwikkelingen zich aan. Als IT-er in het werkveld moet je die ontwikkelingen op hun waarde kunnen schatten, het belang voor jouw situatie kunnen vaststellen. Dat vereist onderzoek. Niet theoretisch onderzoek, maar praktijkgericht onderzoek. In het HBO onderwijs krijgt het opzetten en uitvoeren van een eigen onderzoek dan ook een steeds prominentere plaats. Gedurende de gehele looptijd van het EQuA project hebben vierdejaars software engineering studenten van Fontys Hogeschool ICT binnen hun opleiding meegewerkt aan het uitvoeren van onderzoeken die voor het EQuA project relevant waren. Een voorbeeld. In het voorjaar van 2013 hebben studenten meegewerkt aan het uitvoeren van een onderzoek naar de Nederlandse testpraktijk. Voor de kwaliteit van software is het zorgvuldig opzetten en uitvoeren van een aantal testtrajecten van groot belang. Toch komt in de praktijk het testen door tijdsdruk nog wel eens in de knel. Hoe vaak gebeurt dat nou? En, hoe ervaart de ontwikkelaar of tester die met beide benen in die praktijk staat dat? Wat kan er beter? Om dat te onderzoeken is een korte vragenlijst opgesteld (zie de lijst met projectresultaten verderop in deze uitgave). Vierdejaars studenten van Fontys Hogeschool ICT hebben die vragenlijst voorgelegd aan software ontwikkelaars van bedrijven waar ze eerder in hun studie 52 Softwarekwaliteit? Natuurlijk!

stage hadden gelopen. Dezelfde vragenlijst is ook voorgelegd aan een groep professionele testers van een grote Nederlandse IT-leverancier. In totaal zijn ruim 200 vragenlijsten ingevuld teruggekomen. De antwoorden zijn verzameld in een groot bestand en overhandigd aan de studenten met de opdracht om ze te verwerken tot een onderzoeksrapport, met tabellen, diagrammen en conclusies.

Figuur 2: Voorbeeld resultaten test enquête


53

De EQuA deliverables Het EQuA project heeft een groot aantal resultaten opgeleverd: artikelen, conferentiepapers, scripties, software. De resultaten staan hieronder opgesomd in een lijst. Alle artikelen zijn te downloaden vanaf de EQuA website www.equaproject. nl.

Wetenschappelijke artikelen Refactoren, testen 1. Frens Vonken & Andy Zaidman: Refactoring with Unit Testing: A Match Made in Heaven? Gepresenteerd op de 2012 Working Conference on Reverse Engineering (WCRE 2012), Kingston, Canada. 2. Vincent Hurdugacy & Andy Zaidman: Aiding Software Developers to Maintain Developer Tests. Gepresenteerd op de 16e European Conference on Software Maintenance and Reengineering (CSMR 2012), Szeged, Hongarije. 3. Steven Raemaekers, Arie van Deursen & Joost Visser: An Analysis of Dependence on Third-party Libraries in Open Source and Proprietary Systems. Gepresenteerd op de 16e European Conference on Software Maintenance and Reengineering (CSMR 2012) ), Szeged, Hongarije. 4. Quinten David Soeters, Serge Demeyer & Andy Zaidman: Change-Based Test Selection in the Presence of Developer Tests. Gepresenteerd op de 17e European Conference of Software Maintenance and Reengineering (CSMR 2013), Genua, Italië. 5. Dimitrios Athanasiou, Ariadi Nugroho, Joost Visser & Andy Zaidman: Test Code Quality and Its Relation to Issue Handling Performance. Verschijnt binnenkort in IEEE Transactions on Software Engineering Requirements 6. Petra Heck & Andy Zaidman: An Analysis of Requirements Evolution in Open Source Projects: Recommendations for Issue Trackers. Gepresenteerd op de 13e International Workshop on the Principles of Software Engineering (IWPSE 2013), Sint Petersburg, Rusland. 7. Petra Heck & Andy Zaidman: A quality framework for agile requirements: A practitioner’s perspective.


Software Engineering Research Group, Delft University of Technology, Tech. Rep. TUD-SERG-2014-006. http://swerl.tudelft.nl/bin/view/Main/TechnicalReports 8. Petra Heck & Andy Zaidman: Horizontal Traceability For Just-In-Time Requirements: The case for Open Source Feature Requests. Verschijnt binnenkort in Journal of Software: Evolution and Process. Game software, Domain Specific Languages 9. Paul Klint, Loren Roosendaal & Riemer van Rozen: Game Developers need Lua AiR - Static Analysis of Lua using Interface Models. Gepresenteerd op de 2012 Game Development & Model-driven Software Development Workshop (september 2012), Bremen, Duitsland. 10. Paul Klint & Riemer van Rozen: Micro-Machinations – A DSL for Game Economies. Gepresenteerd op de 6e International Conference on Software Engineering Languages (SLE 2013), Indianapolis, USA. 11. Riemer van Rozen & Joris Dormans: Adapting Game Mechanics with Micro-Machinations. Gepresenteerd op de 9e International Conference on the Foundations of Digital Games (FDG 2014), Florida, USA.

Artikelen vakbladen 12. Jacob Brunekreef: Softwareontwikkelaar tevreden met zichzelf. Automatisering Gids 09, 10 mei 2012.

Afstudeerscripties 13. Gino Rombley: Towards a valid object model. Master’s thesis TU Eindhoven. 2012. 14. Raditeo Warma: The success of Agile Software Development. Bachelor’s thesis Fontys ICT, 2012. 15. Liling Bao: Improvement Research on the Quality of the Software Development Process. Bachelor’s thesis Fontys ICT, 2012. 16. Maurice Hagemeijer: EQuA – Symbiosis: multi-user aspects. Bachelor’s thesis Fontys ICT, 2013. Softwarekwaliteit? Natuurlijk!

55

17. Emily Weimar: The influence of Teamwork Quality on Software Development Team Performance. Master’s thesis Universiteit Tilburg, 2013. 18. Waldo Ramirez Montano: Use case modeling within Object-Role Modelling. Master’s thesis TU Eindhoven, 2013. 19. Evelyn van Kelle: Social Factors of Agile Development Success - The influence of transformational leadership, value congruence, communication, perceived agility and project size on Agile project success. Master’s thesis Universiteit Tilburg, 2014.

Niet-gepubliceerde documenten 20. Frens Vonken, Jacob Brunekreef, Andy Zaidman & Frank Peeters: Software Engineering in the Netherlands: The State of the Practice. Niet gepubliceerd artikel, 2011. 21. Frank Peeters: Naar een valide objectmodel. Intern projectdocument, 2011.

Software 22. Symbiosis tool Onder leiding van Frank Peeters is een tool ontwikkeld voor het modeleren en onderhouden van requirements. Zie ook [20] Sources, executable en documentatie van Symbiosis zijn te downloaden vanaf de site www.fhict.nl/docent/symbiosis. 23. Micro-Machinations library Door Riemer van Rozen is een software library ontwikkeld van micromachinations: elementen waarmee gameplay kan worden gemodelleerd. Zie ook de publicaties over deze library (10, 11). De library is te downloaden vanaf https://github.com/vrozen/MM-Lib.

En verder … 24. Survey praktijk Nederlandse software ontwikkelaars. (2011) Bij de aanvang van het project, in het voorjaar van 2013, is een omvangrijke vragenlijst voorgelegd aan een honderdtal software ontwikkelaars en hun directe managers. Zie ook de publicatie over deze survey. 56 Softwarekwaliteit? Natuurlijk!

De gebruikte vragenlijst en een overzicht van de antwoorden zijn te vinden via de eerder genoemde link. 25. Beknopt onderzoek naar de Nederlandse testpraktijk. (2013) In het voorjaar van 2013 is samen met studenten van Fontys ICT onder ongeveer tweehonderd ontwikkelaars en testers in Nederland een beknopte enquête afgenomen over de Nederlandse testpraktijk. De gebruikte vragenlijst en een overzicht van de antwoorden zijn te vinden via de eerder genoemde link.


57


EQuA staat voor Early Quality Assurance (in software production). Het EQuA project is een RAAK-PRO project. In de periode 2010 – 2014 heeft een aantal partijen gewerkt aan inzichten, methoden en tools om de early quality assurance bij het produceren van software op een hoger plan te brengen. Deze uitgave bevat een aantal artikelen over de onderwerpen die in het project aan de orde zijn geweest. Onderstaande instellingen en bedrijven hebben bijgedragen aan het EQuA project.

Softwarekwaliteit? Natuurlijk! Resultaten van 4 jaar EQuA project

Recommend Documents