Tijdens een inspectie van een software product (code, ontwerp, test specificatie, requirement) lezen de collega's van de auteur het product. Ze gaan op zoek naar mogelijke fouten. Dit is een soort testen voordat je daadwerkelijk de software zelf gaat testen.
Waarom doen we inspecties?
Het is goedkoper dan testen omdat het veranderen van een tekst of diagram makkelijker is dan het veranderen van reeds geimplementeerde code, deze opnieuw compileren en opnieuw testen en dan alsnog alle voorgaande documenten aanpassen.
Het is een goede manier om informatie binnen het project met elkaar uit te wisselen.
Het is een goede manier om te leren van collega's. Dit geldt voor zowel de auteur als de reviewers.
bron: http://geek-and-poke.com
Na deze bouwsteen kun je:
Een checklist voor inspectie maken.
Het werk van collega's inspecteren aan de hand van zo'n checklist.
Als auteur het commentaar van jouw collega's gebruiken om jouw werk te verbeteren.
Heb je vragen of opmerkingen over deze bouwsteen? Neem dan contact op met Esther Hageraats (Saxion).
Een korte geschiedenis
Inspecties worden ook peer reviews genoemd. Wanneer het object van de inspectie softwarecode is, wordt dit ook een statische code-analyse genoemd. Naast inspecties zijn er veel gerelateerde methoden zoals walkthroughs en audits. De eerste formele methode voor inspecties werd in 1972 door Michael Fagan ontwikkeld om de zero-fault-code te produceren. Deze methode wordt Fagan Inspection genoemd. Later werd deze methode door Tom Gilb uitgebreid tot documentatie reviews. Er zijn momenteel veel tools beschikbaar voor zogenaamde statische code-inspecties zoals Soot, Findbugs, Infer en PHP Mess Detector.
Omdat het woord "peer review" vaak wordt gebruikt om elkaar feedback te geven over persoonlijk gedrag in een project, kiezen we het woord "inspecties" voor de technische beoordelingen van documentatie of code waarbij de feedback betrekking heeft op het product, niet op de auteur.
Het proces heeft drie rollen: Auteur, Reviewer, Moderator.
Reviewers lezen het werk en duiden MOGELIJKE problemen aan.
De auteur lost de problemen achteraf op.
De moderator faciliteert een efficiënt proces en een kalme en objectieve sfeer.
Combinatie van rollen:
Een reviewer kan moderator zijn
De auteur kan geen moderator of reviewer zijn
Iedere reviewer een andere checklist
We passen altijd filters toe
De volgende situatie is waarschijnlijk bekend: je kijkt op je horloge om te zien of je nog tijd hebt voor een kop koffie. Je concludeert dat dat best nog kan. Dan vraagt iemand in de rij van de koffiecorner hoe laat het is. Je moet opnieuw naar je horloge kijken.
Dit gebeurt omdat je de eerste keer naar je horloge keek met de vraag : "heb ik tijd voor koffie?", wat een berekening vereist met de huidige tijd en de deadline die je hebt. De huidige tijd is niet 'opgeslagen in het geheugen', je vergeet het zodra je het antwoord op je vraag weet. Misschien heb je iets opgeslagen als "Ik heb vijf minuten".
Nog een voorbeeld: Je bent op zoek naar een meisje in een menigte (café? Treinstation? Klaslokaal?). Zie je haar? Nee. Je loopt verder. Wanneer iemand vraagt: Wie heb je gezien? weet je dat niet. Het enige dat je weet is dat zijer niet was.
Checklists bieden het juiste filter
Als we iets zoeken, filteren we onze waarnemingen naar onze zoekvraag. Vertaald naar inspecties betekent dit dat het uitermate moeilijk is om spelfouten en goede ontwerpkeuzes op hetzelfde moment te zoeken.
De checklist zal het filter van de reviewer focussen en ervoor zorgen dat elke reviewer een andere focus heeft, waardoor het resultaat gemaximaliseerd wordt (het aantal mogelijke verschillende gevonden problemen).
Format van een inspectiechecklist
Een inspectiechecklist bestaat uit vragen die twee mogelijke antwoorden hebben:
Ja (alles is goed)
Nee (hier is mogelijk een probleem)
Wanneer je nog nooit een inspectie hebt gedaan kun je de volgende drie basisvragen gebruiken voor iedere checklist:
Beschrijf het probleem en de positie (regelnummer), beschrijf de oplossing niet. Alsreviewerweet jeniet zeker of je de oplossing kent. Het was niet jouw werk. Bijv. "Regel 67. De kleurindicatie 'in felle kleuren' is niet specifiek genoeg", is een goede opmerking. Terwijl "dit moet rood en geel zijn" een oplossing is, en nog een slechte ook, omdat het niet bepaald specifieker is.
Met een zeer gedetailleerde checklist zou een probleembeschrijving alleen een verwijzing kunnen zijn naar de checklist, bijv. "Regel 76, checklist Code-invoer, punt 4."
Voor spelfouten kun je de oplossingen wel geven. Bijv. "Leezrechten moet leesrechten zijn". Maar zelfs korter is een speciale code voor spelfouten: "SP Leezrechten".
We hebben geleerd om bij feedback over het persoonlijk functioneren van mensen, de verbeterpunten te verpakken in een zogenaamde ‘sandwich’. Eerst een positief commentaar, dan het verbeterpunt en dan weer een positieve afsluiting.
Bij inspecties kost dit veel te veel tijd. Maar er is natuurlijk wel het gevaar dat auteurs hun zelfvertrouwen verliezen als er veel commentaar is en dat reviewers te zelfverzekerd en arrogant worden omdat ze zo veel opmerkingen maken.
De basishouding van de reviewers moet zijn dat ze een tijdelijke rol vervullen; dat ze de volgende keer op de stoel van de auteur zitten en graag alle hulp krijgen die ze kunnen vinden om die blinde vlekken te vinden die ook zij hebben. Wees objectief, duidelijk en ruimdenkend.
Het inspectierecord bevat alle gemaakte opmerkingen en het geeft aan of en hoe de opmerkingen zijn opgelost.
Gebruik Word, Excel, opmerkingen in een Google-document, een zelfgemaakte NoSQL-database—wat je maar een prettige methode vind. De methode moet het volgende faciliteren:
Alle opmerkingen van dereviewersworden in één document beschikbaar. Dit wordt het inspectierapport genoemd.
Een inspectierapport kan het werk zelf zijn met opmerkingen eraan toegevoegd.
Het inspectierapport blijft beschikbaar nadat alles is gedaan.
Nota bene:
Binnen het project kan het beste voor alle inspecties een zelfde methode gebruikt worden voor het registreren van problemen.
Een goed gestructureerde vergadering
De inspectievergadering
De link hierboven is van een video met een paar voorbeelden van de gedragsregels
De vergadering is zeer gestructureerd en doorloopt de lijst van begin tot einde. Wanneer alle deelnemers het spel kennen, krijgt de vergadering bijna een ritme.
De moderator bepaalt het tempo.
Wanneer de auteur het probleem begrijpt, is het niet nodig om verder uit te werken. De auteur is de klant van deze vergadering. We doen dit allemaal om de auteur een lijst met problemen te geven die zijn/haar product zullen verbeteren.
Er kunnen mogelijk problemen geïdentificeerd worden die groter zijn dan het werk van deze auteur. Misschien zijn er misverstanden binnen het project die nu pas boven tafel komen. In dat geval eindigt de vergadering met actiepunten voor meer mensen dan alleen de auteur.
Wat kan er nog mis gaan?
Individuele opdracht
De bijlage bevat een inspectie checklist voor SMART requirements. De criteria (checklistvragen) zijn afgeleid van de bouwsteen voor SMART requirements die elders op deze Blackboard-site te vinden is.
De opdracht is om 5 requirements te inspecteren met behulp van alle vragen in de checklist en om alle opmerkingen schriftelijk te noteren.
Voorbereiding:
Als je in een project werkt, is de meest effectieve werkwijze om de requirements onder het team te verdelen, zodat uiteindelijk alle requirements grondig worden geïnspecteerd.
Bespreek ook met elkaar hoe het inspectierapport eruit moet zien. Je kunt het sjabloon gebruiken dat hier is bijgevoegd.
Opmerking: In een project zal meestal iedere reviewer alle requirements inspecteren, maar dan op andere checklistvragen. In deze eerste opdracht willen we je juist laten zien hoe diep de inspectie van één enkele requirement kan gaan. Op voorwaarde natuurlijk dat men de betekenis van SMART serieus neemt.
Verschillende studenten in een projectgroep hebben al iets geïnspecteerd bij de vorige opdracht. De groepsopdracht is om de opmerkingen tot één grote lijst samen te voegen en een inspectievergadering te houden:
Als meer reviewers dezelfde requirements met dezelfde checklist hebben bekeken: vergelijk de commentaren en voeg ze samen in één lijst.
Wijs een moderator aan en stuur alle lijsten naar die persoon.
De moderator voegt de lijsten samen tot één inspectie-rapport.
Houd een inspectievergadering.
In deze oefening heb je twee items om bij elk commentaar te bespreken:
de kwaliteit van de opmerking:
het probleem en niet de oplossing,
het werk en niet de persoon,
specifiek genoeg om de auteur te helpen.
begrijpt de auteur van de requirements het probleem?
Bespreek na de bijeenkomst wat je anders zou doen de volgende keer dat je een inspectie doet.
Dit lesmateriaal is gepubliceerd onder de Creative Commons Naamsvermelding 4.0 Internationale licentie. Dit houdt in dat je onder de voorwaarde van naamsvermelding vrij bent om:
het werk te delen - te kopiëren, te verspreiden en door te geven via elk medium of bestandsformaat
het werk te bewerken - te remixen, te veranderen en afgeleide werken te maken
voor alle doeleinden, inclusief commerciële doeleinden.
Van dit lesmateriaal is de volgende aanvullende informatie beschikbaar:
Toelichting
Dit is een bouwsteen van het project Open OiO (Onderzoek in Onderwijs) van HBO-ICT.
Het is een compleet stuk onderwijs voor HBO-ICT studenten.
Een inspectie is een werkwijze om collegiale feedback te krijgen en daarmee het beroepsproduct te verbeteren. Studenten leren fouten zoeken, feedback geven en feedback gebruiken. Het lesmateriaal is gebaseerd op het Inspectieproces van Tom Gilb.
Dit is een bouwsteen van het project Open OiO (Onderzoek in Onderwijs) van HBO-ICT.
Het is een compleet stuk onderwijs voor HBO-ICT studenten.
Een inspectie is een werkwijze om collegiale feedback te krijgen en daarmee het beroepsproduct te verbeteren. Studenten leren fouten zoeken, feedback geven en feedback gebruiken. Het lesmateriaal is gebaseerd op het Inspectieproces van Tom Gilb.
Details bij de procesflow van het inspectieproces
