EQuA project slotsymposium

Leon Schrijvers

Het EQuA project (Early Quality Assurance in software production) is een 4 jarig project wat gericht is op het bereiken van een zo hoog mogelijke kwaliteit in een zo vroeg mogelijk stadium. Het project is uitgevoerd door een consortium van 10 partijen (o.a CWI, TU Delft, TU/e, SIG, Sogeti) onder de vleugels van Fontys ICT. Als afsluiting van het project heeft Fontys ICT een symposium georganiseerd met sprekers vanuit het onderzoeksproject en werkveld.

EQuA slotsymposium

Het symposium werd geopend door EQuA projectleider Jacob Brunekreef. In de opening gaf hij aan dat software kwaliteit steeds belangrijker wordt. Terugkijkend op de afgelopen 4 jaar wordt dit ondersteund door een aantal ontwikkelingen:

  • Software kwaliteit heeft raakvlakken met security. Security komt steeds vaker in het nieuws.
  • Bring your own device (ook weer relatie tot security)
  • Sterke toename in omarming Agile projectaanpak
  • Nieuwsberichten over falende ICT overheidsprojecten

In de introductie haalt Brunekreef de centrale vraagstelling van het project aan: "Hoe kunnen we fouten bij het produceren van software zo vroeg mogelijk opsporen - en daarbij herstelkosten op een later moment besparen?". De presentaties van het symposium zouden hier inzicht in moeten geven.

Hoe sneller hoe slechter

Rini van Solingen (co-auteur van het boekje 'De kracht van Scrum')

Van Solingen start met een aardig verhaal over Scrum. Het gaat vooral over de basics (wat/hoe/waarom), maar hij stipt toch een interessante gedachten aan:

De tijd die het kost voordat nieuwe technologie een gebruikersaantal van 50 miljoen bereikt, is drastisch afgenomen. Vergelijk: het kostte de telefoon 75 jaar om 50 miljoen gebruikers te krijgen, en Angry Birds slechts 7 dagen. Belangrijk component van deze versnelling is de inzet van software.

Omdat de wereld steeds sneller gaat, is het onverstandig om langdurende projecten uit te voeren: tegen de tijd dat het project is afgerond is de wereld alweer veranderd en loop je met het resultaat alweer achter. Het feit dat Scrum de scope flexibel houdt, is dus niet vervelend (onvoorspelbaar), maar kan je zien als kans: de kans om de snelle wereld bij te benen.

Van Solingen zegt dat Scrum/Agile dwingt tot kwaliteit. Hij geeft hiervoor 7 redenen; een beknopte opsomming:

  • Ritme: dit geeft houvast en het project wordt voorspelbaar door herhaalbaarheid
  • Altijd klaar (DoD): sturen op product, niet op proces
  • Leren (iteraties)
  • Samenwerking met klant (feeback)
  • Waarde leveren vanaf dag 1
  • Opknippen, project/onderdelen niet groter maken. Kleine dingen afronden geeft energie!
  • Automatiseren (testen, continuous integration, continuous delivery)

Size doesn't matter

Evelyn van Kelle (SIG)

Het afstudeeronderzoek van van Kelle [1] ging over sociale succesfactoren in Agile projecten: welke sociale succesfactoren zijn aanwezig en in hoeverre dragen ze bij aan het succes van een project?

Binnen projecten is de kwaliteit van de communicatie belangrijk: (grote) projecten zijn complex en de betrokkenheid van meer mensen leidt tot meer meningen.

In het onderzoek is er een model opgesteld. Dit model beschouwt de volgende onderzoeksonderwerpen:

  • Leiderschapsstijl (transformationeel of transactioneel)
  • Communicatiestijl (informeel of formeel)
  • Value congruence (eendracht)
  • Mate van agility (hoe agile vinden we onszelf?)
  • Projectgrootte (aantal mensen)

Leiderschapsstijl is als volgt te typeren:

  • Transformationeel:
    • Het goede voorbeeld geven
    • Inspireren
    • Motiveren
    • Faciliteren
    • Coachen
    • Visie uitdragen
    • Persoonlijke relaties
    • Effectief in complexe, turbulente omgevingen
  • Transactioneel:
    • Sociale transactie
    • Verwachtingen en beloningen communiceren
    • Fouten op de voet volgen
    • Controleren
    • Effectief in stabiele, voorspelbare omgevingen

Communicatiestijl is als volgt te typeren:

  • Informeel:
    • Spontane conversaties
    • Communicatie kanalen: Rijke media (face-to-face), Weinig documentatie
    • Fysieke nabijheid: Belangrijk
    • Onderlinge persoonlijke relaties: Goed, belangrijk
  • Formeel:
    • Geplande meetings
    • Communicatie kanalen: Arme media (e-mail), Veel documentatie
    • Fysieke nabijheid: Minder belangrijk
    • Onderlinge persoonlijke relaties: Minder belangrijk

De samenhang tussen de onderwerpen en de bijdrage hiervan aan het succes van projecten is getoetst via interviews. In de interviews is er met projectleden van succesvolle projecten gesproken om te bepalen wat de bijdrage aan het succes van de projecten was. Hieruit waren de volgende conclusies af te leiden:

  • De projectgrootte (aantal mensen) heeft geen invloed op het succes.
  • De belangrijkste succesfactoren waren:
    • Transformationeel leiderschap: Deze stijl past het beste bij Agile projecten.
    • Mate van agility: zitten we qua Agile gedachten en doelstellingen op een lijn?
    • Value congruence (eendracht), waarbij dit het gevolg is van de eerste twee factoren.

Het is interessant om te kijken hoe we projecten succesvoller kunnen laten verlopen door te kijken naar sociale aspecten binnen teams. Hierbij kunnen we dus het beste focussen op het transformationeel leiderschap en de mate van agility.

Moeten we requirements serieus nemen?

Frank Peeters, Petra Heck

Een duo presentatie met een interactief onderdeel. Aan de hand van een aantal stellingen over requirements wordt om de mening van het publiek gevraagd. Via smartphone kan gestemd worden en de resultaten zijn direct zichtbaar op het grote scherm. Een leuke gimmick, maar helaas wordt er matig op feedback vanuit het publiek gereageerd en discussies vervallen snel in definitiekwesties.

Het onderzoek van Peeters omvat de analyse en validatie van requirements. Een onderdeel hiervan is een Symbiosis tool, die vanuit requirements automatisch code (domein model, use cases) kan genereren. De tool is toegespitst op traditioneel waterval ontwikkeling.

Het tweede deel van de presentatie werd gegeven door Petra Heck, die zich bezig houdt met het ontwikkelen van een methodiek ter bepaling van de kwaliteit van requirements/user stories. Ze zegt hierbij dat in Scrum, een user story net 'goed' genoeg beschreven moet zijn, zodat het development team en de Product Owner elkaar begrijpen. Wat 'goed' betekent in deze context wordt vastgesteld via het Agile Requirements Verfication Framework. Dit framework kan gebruikt worden als checklist om te bepalen wat de kwaliteit van user stories zijn, en kan ons in projecten helpen bij het correct formuleren van user stories. Een overzicht van het framework wordt hieronder getoond. Een paper met uitgebreide uitleg over het framework is te vinden in [2].

AgileRequirementsVerificationFramework

BYOM (Bring Your Own Metric)

Paul Klint

Klint geeft een aardige presentatie over static analysis tools. De ervaring leert dat het standaard gebruik van tools kan leiden tot:

  • Veel false positives (overweldigd door resultaat)
  • Veel false negatives (onbekend)

False positives zullen beoordeeld moeten worden of het relevant is of niet. Bij teveel focus op metrics ontstaat er meetverlamming bij het ontwikkelteam.

Hoe dit op te lossen?

  • Niks meer meten
  • Focussen op een selectie van metrics
  • BYOM: implementeer specifieke metrics die voor jouw project waardevol zijn.

Je kan zelf metrics implementeren door de volgende tools in te zetten:

  • M3 [3]: extraheert informatie uit code base en bouwt hiermee een meta model op.
  • Rascal [4]: implementeert metrics op basis van meta model.

De voorbeelden die Klint geeft, geven een aardig beeld van welk type informatie uit het meta model op te vragen zijn. Ik denk alleen dat de uitdaging niet in de techniek zit, maar dat het lastige is om een goede set aan metrics op te stellen. Het geeft wel stof tot nadenken: het is erg lastig uit te drukken wanneer code van goede kwaliteit is, en wat we daarin belangrijk vinden.

Live game software verbeteren

Loren Roosendaal (IC3D Media), Riemer van Rozen (CWI)

In deze duo presentatie begint Roosendaal met een promopraatje over IC3D Media: wie zijn ze en wat doen ze. Hierna komt een interessanter onderdeel: game design is een samenwerking tussen (o.a.) een game designer en een developer. De game designer bepaalt het concept, en kan game mechanics tweaken om het spel interessanter te maken of beter te balanceren. Traditioneel heeft de game designer de developer nodig om de aanpassingen in het spel door te voeren. Dit kost extra tijd, en onder tijdsdruk zou dit tot slordige code kunnen leiden.

De oplossing hiervoor is de inzet van een DSL (Domain Specific Language). Via de DSL kan een game designer live (dus in een draaiende game) de gewenste aanpassingen zelf doorvoeren. Dit versimpelt het uiteindelijke ontwikkelproces. Micro Machinations (MM) [5] is een voorbeeld van een DSL: het is een game design language wat door game designers gebruikt kan worden om live aanpassingen door te voeren. Helaas is er momenteel nog geen laagdrempelige (grafische) editor voor MM beschikbaar. Er is dus nog wel kennis van de MM taal nodig voordat je er mee aan de slag kan gaan.

Referenties:

[1] http://193.23.143.188/~equaprojec/media/Uploaded_documents/Thesis_E.C.A._van_Kelle_522604_Final.pdf

[2] http://swerl.tudelft.nl/twiki/pub/Main/TechnicalReports/TUD-SERG-2014-006.pdf

[3] http://tutor.rascal-mpl.org/Rascal/Libraries/analysis/m3/m3.html

[4] http://www.rascal-mpl.org/

[5] https://github.com/vrozen/MM-Lib