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.
Softwarekwaliteit? Natuurlijk!
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
Softwarekwaliteit? Natuurlijk!
Early Quality Assurance
Jacob Brunekreef, Fontys Hogeschool ICT
Van oudsher speelt kwaliteit een prominente rol in de wereld van software
ontwikkelaars. Want, de gevolgen van achterblijvende kwaliteit kunnen groot
zijn. Iedereen heeft wel ervaring met applicaties die plotseling dienst weigeren
(net voordat je weer wilde saven …), iedereen kent verhalen van falende
automatiseringsprojecten waar vaak miljoenen euro’s mee zijn gemoeid. Maar, hoe
voorkom je die problemen? Het antwoord op deze vraag is niet simpel, er bestaat
niet zoiets als een “silver bullet”. Maar, er zijn wel inzichten die helpen. Zo weten we
sinds onderzoek van de Amerikaanse software goeroe Barry Boehm uit begin jaren
80 van de vorige eeuw dat de kosten van foutherstel exponentieel oplopen naarmate
een project in de tijd vordert. Dus loont het om al in een vroeg stadium aandacht te
besteden aan het opsporen, verhelpen en vermijden van fouten.
Bij de start van het EQuA project, in het najaar van 2010, hebben we bovenstaand
inzicht als uitgangspunt genomen. De centrale vraag binnen het project was: “Hoe
kunnen wetenschappelijke kennis en inzichten op het terrein van vroegtijdige
foutdetectie en –herstel in software productie en in het werkveld op dit terrein
toegepaste methoden en technieken samengebracht worden?”. Daarbij was de
veronderstelling dat zowel wetenschappers als het werkveld weten dat vroegtijdig
opsporen van fouten loont – maar wat doe je met die kennis? Wij hadden niet de
illusie dat wij in het project het hele probleem op zouden kunnen lossen. Zoeken
naar een aantal goede en bruikbare handvatten, dat was het idee.
En, is er wat terecht gekomen van dat idee? Ik denk het wel! Binnen het EQuA
project hebben onderzoekers zich gestort op een verscheidenheid aan onderwerpen,
variërend van een kwaliteitsmodel voor requirements tot succesfactoren voor het
samenwerken in een ontwikkelteam, van volwaardig gereedschap om requirements
te kunnen formuleren en beheren tot een software bibliotheek om het ontwikkelen
van spelgedrag in games te ondersteunen. Daarmee is nog niet alles genoemd.
De volledige lijst met resultaten, verderop in deze uitgave, laat goed zien hoe
omvangrijk en breed het onderzoek is geweest dat in het kader van het EQuA project
is uitgevoerd.
Uit de voorgaande opsomming is al wel duidelijk dat er niet alleen papier is
geproduceerd. Er zijn ook producten ontwikkeld. Producten die al tijdens het project
hun bruikbaarheid in de praktijk hebben bewezen. Zo wordt het Symbiosis tool voor
Softwarekwaliteit? Natuurlijk!
7
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
Softwarekwaliteit? Natuurlijk!
Het belang van requirements
Softwarekwaliteit? Natuurlijk!
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 <rol> wil ik
<functie> zodat <business value>’. Als een team hiermee werkt dan kan dit onder
[VC2] worden toegevoegd. In Figuur 1 staat een voorbeeldlijst van criteria voor user
12 Softwarekwaliteit? Natuurlijk!
stories en feature requests (wijzigingsverzoeken in open source projecten). Voor meer
details over de verschillende criteria verwijzen we graag naar ons uitgebreide artikel.
Figuur 1: De criteria in italic gelden alleen voor user stories, de rest geldt voor user stories en feature requests
Voor het valideren van het raamwerk hebben wij de verschillende criteria vertaald in
een Excel checklist en die vervolgens voorgelegd aan 8 personen uit de Nederlandse
agile community. Wij hebben hun mening over kwaliteit van agile requirements
in het algemeen gevraagd, maar ze ook met de checklist een aantal open source
requirements laten beoordelen zodat ze hun mening over het raamwerk konden
geven. Voor dat laatste doel hadden wij zelfs een scoringsalgoritme in de checklist
ingebouwd om de kwaliteit van verschillende requirements te kunnen vergelijken.
Ieder van de deelnemers was het erover eens dat kwaliteit van agile requirements
belangrijk is. Zij vonden het raamwerk over het algemeen nuttig als hulpmiddel
om de kwaliteit van agile requirements te beoordelen. Zij hadden twee soorten
opmerkingen: 1) aanvullingen op de criteria en 2) over de scoringsregels. Voor wat
betreft de aanvullende criteria waren dit vaak bedrijf- of projectspecifieke criteria
(bijv. is er een akkoord van de product owner?) die wij niet in het algemene model
hebben opgenomen. Maar zoals gezegd laat het raamwerk voldoende ruimte voor
het schrappen of toevoegen van eigen criteria. Voor wat betreft de scoringsregels
is de conclusie dat deze in de meeste gevallen niet nodig zullen zijn: men wil agile
Softwarekwaliteit? Natuurlijk!
13
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.
14 Softwarekwaliteit? Natuurlijk!
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
16 Softwarekwaliteit? Natuurlijk!
zelf wordt verankerd. Nadat het design de check op een aantal meta-regels heeft
doorstaan, kan de volledige broncode van alle domeinklassen worden gegenereerd.
De feit en de regel requirements zitten dan inmiddels in de domeinklassen
opgesloten; resteert nog de realisatie van de actie requirements. Een substantieel
deel van deze acties is gegenereerd naar aanleiding van het configureren van het
design. Elke gegenereerde actie kan automatisch worden getransformeerd in een
zogenaamde action case, hetgeen een gecompileerde class realisatie van de normale
flow in een atomaire use case omvat. De overblijvende, handmatig ingevoerde, acties
worden vervolgens gerealiseerd op basis van een assemblage van de tool box met
action cases, hierbij kan dan en passant rekening worden gehouden met de nietfunctionele eisen.
Tijdens het ontwikkelen van software worden de requirements regelmatig
toegevoegd, aangepast of verwijderd. Elke wijziging moet worden gekeurd door de
verantwoordelijke producteigenaar. Na de goedkeuring wordt het design op orde
gebracht en kunnen de domeinklassen en action cases weer worden gegenereerd.
Onze werkwijze maakt het mogelijk dat een design exclusief op zijn requirements is
gebaseerd. Zodra alle requirements goedgekeurd zijn, heb je ook de zekerheid dat
het design en daarmee alle gegenereerde domeinklassen en action cases compleet
zijn. De niet-functionele eisen kunnen vervolgens op een elegante manier worden
meegenomen zodra men toekomt aan de verfijning van de samengestelde action
requirements. Ons devies luidt: Neem requirements serieus!
Wie meer wil lezen:
• Project deliverables [13], [16], [18], [21]
Softwarekwaliteit? Natuurlijk!
17
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.”
20 Softwarekwaliteit? Natuurlijk!
Een stage rond het genereren van code
Interview met Joery van den Hoff, student Software Engineering,
Fontys Hogeschool ICT
Vooraf
Joery van den Hoff is nu (najaar 2014) vierdejaars student bij Fontys Hogeschool ICT.
In het voorjaar van 2014 heeft hij stage gelopen bij het bedrijf ISAAC in Eindhoven.
Het onderwerp van zijn stage: codegeneratie voor het Symbiosis tool van EQuA
onderzoeker Frank Peeters (zie het artikel eerder in deze uitgave). In dit interview
kijken wij naar wat Joery gedaan heeft, horen wat zijn ideeën zijn over het Symbiosis
tool en praten met hem door over de relaties tussen werkveld en opleiding.
Het stagebedrijf
ISAAC is specialist op het terrein van web- en middleware oplossingen, gebaseerd
op betrouwbare en veilige (open source) software. Het bedrijf is gastheer geweest
voor een aantal stages en afstudeerprojecten in het kader van het EQuA project,
zowel van Fontys Hogeschool ICT als van de Technische Universiteit Eindhoven. ISAAC
gelooft sterk in de noodzaak van het vroegtijdig opsporen van fouten en omarmt het
gedachtengoed van het EQuA project.
Codegeneratie
De oorspronkelijke stageopdracht luidde: “Voeg aan de codegeneratie in Symbiosis
de mogelijkheid van JPA notatie toe.” JPA (Java Persistence API) is een persistentie
framework uit de Java wereld. Maar, aan die opdracht is Joery niet toegekomen,
om de simpele reden dat er nog helemaal geen sprake was van codegeneratie
in Symbiosis. Dus is Joery daar aan gaan bouwen. Concreet houdt dat in dat
vanuit het objectmodel code wordt gegenereerd, met name voor de domeinlaag:
klassedefinities met onder andere getters en setters. Aan het genereren van code
voor het dynamische deel van een applicatie, vanuit het requirements model, is Joery
niet toegekomen. Dat was ook niet zijn opdracht. Hij is er wel in geslaagd om een
werkend geheel op te leveren. Codegeneratie werkt nu voor twee tot drie kleine
casussen. De code die gegenereerd wordt is nog niet erg complex. Hieronder staat
een voorbeeld, voor een internet boekwinkel.
Softwarekwaliteit? Natuurlijk!
21
Figuur 1: Voorbeeld van gegenereerde code
Joery is er nog niet van overtuigd dat de door hem gebouwde codegenerator in alle
gevallen succesvol zal zijn. Bij toevoegen van meer casussen verwacht hij nieuwe
problemen tegen te komen.
Op de vraag wat hij van Symbiosis vindt volgt na enig nadenken een genuanceerd
antwoord. De methode is interessant. Het is een leuke, nieuwe aanpak van het
werken met requirements. Maar, het ontbreekt wel aan schaalbaarheid. Bij kleine
casussen is het aantal requirements te overzien en lukt het wel om ze op te stellen
in het formaat dat Symbiosis vereist. Maar bij grote projecten met heel veel
requirements gaat dat naar verwachting niet meer lukken.
Het oordeel van Joery over de kwaliteit van de tool is minder positief. Het
gebruikersinterface is in zijn ogen zwak, de tool bevat een aantal bugs. Er is zo te
zien onvoldoende nagedacht over de opzet, de architectuur. Blijkbaar was zorgvuldig
ontwerpen en coderen niet het hoofddoel van het deelproject rond Symbiosis.
Ervaringen in een bedrijf
22 Softwarekwaliteit? Natuurlijk!
Tijdens het grootste deel van zijn stage heeft Joery in z’n eentje aan het Symbiosis
tool gewerkt. Ongeveer een kwart van de tijd heeft hij meegedraaid in een
projectteam van ISAAC. Dat was eigenlijk wel erg leuk. Daar zag hij van dichtbij
hoe in de praktijk door een team software wordt ontwikkeld. Opmerkelijk: het
heeft Joery ook tot het inzicht gebracht dat hij later niet software ontwikkelaar wil
worden. “Dag in dag uit code schrijven en testen, dat is me te beperkt.” Bij voorkeur
houdt hij zich ook bezig met ontwerpen en klantcontacten. “Maar ja, zo begin je
niet als software engineer.”
Opleiding en werkveld
Hoe kijk je als student naar het bedrijfsleven? Lopen ze voorop bij nieuwe
ontwikkelingen, of kunnen ze nog wat leren van de opleidingen? Joery heeft nog
niet veel bedrijven van binnen gezien. Toch ervaart hij soms al wel een verschil, bij
voorbeeld het gebruik in de opleiding van Svn voor versiebeheer, terwijl het werkveld
al massaal is overgestapt op Git. Daar blijft de opleiding duidelijk achter bij nieuwe
ontwikkelingen. Een ander verschil is het gebruik van een ontwikkelomgeving (IDE).
Bij Fontys wordt, zoals bij veel opleidingen, gewerkt met NetBeans, terwijl je in de
praktijk meer Eclipse tegenkomt. Maar, in het algemeen heeft Joery niet het idee dat
de opleiding erg wereldvreemd is. Via de ‘Partners in Education’ (bedrijven die actief
een bijdrage leveren aan het onderwijs) komt veel informatie uit de praktijk bij de
opleiding binnen.
Joery vindt bedrijfscontacten tijdens de opleiding belangrijk. In die contacten zie je
welke methoden en technieken in het bedrijfsleven gebruikt worden. En zie je hoe
het werk van afgestudeerden er uit ziet.
Softwarekwaliteit? Natuurlijk!
23
24 Softwarekwaliteit? Natuurlijk!
Software voor game development
Softwarekwaliteit? Natuurlijk!
25
26 Softwarekwaliteit? Natuurlijk!
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
28 Softwarekwaliteit? Natuurlijk!
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.
30 Softwarekwaliteit? Natuurlijk!
De kracht van serious games
Een interview met Loren Roosendaal, IC3D Media
IC3D Media
IC3D Media uit Breda is een belangrijke speler op de internationale markt van
serious games. Sinds begin 2013 nemen ze deel aan het EQuA project. Samen
met onderzoekers van de Hogeschool van Amsterdam en Centrum Wiskunde &
Informatica (CWI) heeft het bedrijf gewerkt aan software om het ontwerpen van
games te vereenvoudigen. In een interview met Loren Roosendaal, oprichter en CEO,
passeren veel onderwerpen de revue: het belang van serious games, het specifieke
karakter van game software, de aandacht voor kwaliteit, de relatie met opleidingen
en onderzoeksinstituten.
Loren is op 11-jarige leeftijd begonnen met het programmeren van games. Via
internet werkte hij samen met mede-ontwikkelaars over de hele wereld. Samen
hebben ze een WO II variant van een bestaand spel ontwikkeld. Die variant werd in
korte tijd 2,5 miljoen maal gedownload. Dat gaf wel een kick.
IC3D Media is van het begin af aan een internationaal bedrijf. Na de start groeide
IC3D Media tot 12 mensen. Daarvan zaten er twee (Loren en zijn broer) in Nederland,
de rest zat over de hele wereld. Dat waren (deels) de jeugdcontacten van Loren.
Serious games
IC3D Media maakt trainingssoftware voor bedrijven en organisaties. Bijvoorbeeld: het
trainen van reddingwerkers bij aardbevingen in Indonesië. Die kunnen met behulp
van de trainingssoftware oefenen hoe te handelen in levensechte situaties: wat doe
je als een gebouw ingestort is, welke hulpmiddelen heb je tot je beschikking, hoe
kan je die het beste inzetten?
Dit soort trainingssoftware heeft in de ogen van Loren een grote toekomst: mensen
die vroeger in klaslokalen of uit dikke boeken leerden kunnen nu in 10 minuten
per dag op hun tablet, laptop of pc interactief kennis en vaardigheden opdoen.
Bovendien loont het trainen van hulpverleners. Er gaat veel mis omdat die mensen
slecht getraind zijn. Loren geeft een voorbeeld: “een groot deel van de dwarslaesies
die ontstaan na een ongeluk is te voorkomen als mensen de apparatuur die ze
gebruiken om iemand te bevrijden beter zouden gebruiken. Dat kun je trainen,
aanleren, met serious games!” Dit soort opbrengsten toont het maatschappelijk
belang van serious games aan. Serious games dragen direct bij aan de kwaliteit van
leven!
Softwarekwaliteit? Natuurlijk!
31
Leerstrategieën spelen een belangrijke rol bij het ontwikkelen van serious games.
Je moet op het juiste moment de juiste uitdagingen en beloningen aanbieden. Doe
je dat niet dan haken mensen af omdat het spel te moeilijk of te makkelijk is. IC3D
Media heeft op basis van eigen praktijkervaring hier veel inzicht in gekregen, grote
stappen in gemaakt.
Naast een goede leerstrategie is realisme in trainingen erg belangrijk. Er bestaat
wetenschappelijk onderzoek dat zegt aan te tonen dat het niet zo belangrijk is hoe
een poppetje er uit ziet. Loren is, op basis van eigen ervaring, overtuigd dat in een
aantal gevallen het tegendeel geldt. “IC3D Media is op dit vlak veel verder dan de
meeste ontwikkelaars/bedrijven. Wij zijn in staat om veel meer details in onze games
op te nemen. En daarmee maken we echt een verschil.”
Early quality assurance
Hoe benadert IC3D Media early quality assurance? Dat begint met goed nadenken
over de inhoud en de opbouw van een game: je moet van meet af aan de
complexiteit en daarmee de omvang goed beheersen. Bij games ontstaat heel snel
een zeer grote toestandsruimte. Die moet je vanaf het begin inperken. Ook besteedt
IC3D Media veel aandacht aan code kwaliteit. Onderlinge code reviews houden de
ontwikkelaars scherp. Daarbij is er ook expliciet aandacht voor de performance.
Loren houdt een gloedvol betoog waarom het noodzakelijk is om bij het schrijven
van performance-gevoelige code nauwkeurig te weten hoe de code door de
hardware wordt verwerkt. De manier waarop een processor bijvoorbeeld gegevens
in zijn cache zet, is zeer bepalend voor de performance, code (met name ook de
gebruikte datastructuur) moet daarop afgestemd zijn.
IC3D Media stelt hoge eisen aan de kwaliteit van haar medewerkers. De game design
opleiding bij de NHTV (Breda) is in de ogen van Loren de beste in Nederland. Stagiairs
van die opleiding zijn regelmatig te vinden bij IC3D Media. Maar ook de kwaliteit
van afgestudeerden bij die opleiding is nog niet voldoende om bij IC3D Media als
zelfstandig ontwikkelaar aan het werk te gaan.
Het testen van games is een verhaal apart. Door het grote aantal mogelijkheden
in een spel is test-driven development geen optie – het is niet een kwestie van de
juiste output leveren bij bepaalde inputwaarden. Uiteraard wordt er ook bij IC3D
Media veel getest. Unit-tests worden gebruikt als het om meer technische zaken
gaat, acceptatietests met opdrachtgevers en gebruikers als het meer om de gameplay
elementen gaat. Probleem daarbij is wel dat opdrachtgevers soms van tevoren niet
concreet weten wat ze willen. Pas tijdens de ontwikkeling van een game wordt een
opdrachtgever zich bewust van wat de mogelijkheden zijn en van hoe die aan te
passen zijn aan zijn wensen.
32 Softwarekwaliteit? Natuurlijk!
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.
Softwarekwaliteit? Natuurlijk!
33
34 Softwarekwaliteit? Natuurlijk!
Agile software ontwikkelen
Softwarekwaliteit? Natuurlijk!
35
36 Softwarekwaliteit? Natuurlijk!
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.
Softwarekwaliteit? Natuurlijk!
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.
38 Softwarekwaliteit? Natuurlijk!
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 wet- en 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 test- en 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
40 Softwarekwaliteit? Natuurlijk!
‘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
ontwikkel- en 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!
42 Softwarekwaliteit? Natuurlijk!
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
44 Softwarekwaliteit? Natuurlijk!
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
Softwarekwaliteit? Natuurlijk!
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]
46 Softwarekwaliteit? Natuurlijk!
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.
Softwarekwaliteit? Natuurlijk!
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…”
50 Softwarekwaliteit? Natuurlijk!
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!
Softwarekwaliteit? Natuurlijk!
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
Softwarekwaliteit? Natuurlijk!
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.
54 Softwarekwaliteit? Natuurlijk!
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.
Softwarekwaliteit? Natuurlijk!
57
58 Softwarekwaliteit? Natuurlijk!
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.

Speakers and Content

De rol van Architectuur in de Agile omgeving van

Selectiecriteria aangepast wielrennen voor WK 2015

CV Huib Schoots

Volmacht voor het neerleggen van de boeken

Van Gantt chart naar Burn up chart: het doen van een eerste

Requirements professionaliseren

programmaoverzicht - Night of the Nerds

Brochure testopleidingen downloaden

Java Software Ontwikkelaar Zomerstage

requirements-specificatie-aanpakken in software