Software Engineering Projecten (SEP): Review Info
Alle op te leveren artefacten dienen
aan een review onderworpen te worden.
Het doel van een review is om in een zo vroeg mogelijk stadium
eventuele gebreken te onderkennen in artefacten
van hoge kwaliteit.
Herstellen van gebreken hoort daar niet bij.
We onderscheiden
- interne reviews, uitgevoerd binnen de groep zelf,
bij voorkeur door een paar personen die minder te maken hebben
gehad bij de productie van het artefact, maar die het later wel gaan
gebruiken; eigen adviseur dient hierbij betrokken te zijn
- externe reviews, uitgevoerd door personen buiten de groep
Kanttekeningen:
- Een review is niet efficient als het artefact van slechte kwaliteit is.
(Dan kost het teveel personen teveel tijd om evidente gebreken aan te wijzen.)
- Een review kan en hoeft niet uitputtend te zijn.
(Steekproef)
- Een review richt zich bij voorkeur op aspecten met verhoogd risico.
Bijv. aspecten waarvan uit het verleden bekend is dat er veel fouten bij
worden gemaakt, of aspecten waarvan de consequenties bij fouten verstrekkend
zijn.
Daarbij kan een checklist van nut zijn.
- Een review gebeurt in een aantal stappen:
- Materiaal wordt tijdig toegezonden aan de reviewers
- Reviewers beoordelen het en noteren hun bevindingen (op eigen gelegenheid)
- In een vergadering (2 uur max) worden de bevindingen uiteengezet en
geinventariseerd (geen discussie; geen oplossingen;
wel relevantie en urgentie vaststellen;
eventueel lastigere punten uitstellen);
tegen het einde worden openstaande zaken doorgenomen;
vergadering beslist over status (geaccepteerd, verworpen, welke aanpassingen nodig zijn)
- Notulist notuleert
(datum, wie aanwezig, lijst met bevindingen en reacties;
wel/niet iets aan doen; eindbeslissing); notulen worden gearchiveerd
- Eventueel "rework" wordt uitgevoerd en gecontroleerd
- Een eventuele vervolg-review richt zich alleen op punten,
die bij vorige review in gebreke (b)leken te zijn
Zie ook:
Organisatie van Interne en Externe Reviews in 2002/2003
Elke groep heeft een adviseur.
Documenten worden door de groep geproduceerd en intern op kwaliteit
gecontroleerd in samenspraak met de adviseur, aan de hand van een
checklist.
Interne reviews kunnen als walkthrough georganiseerd worden.
De interne bespreking en de goedkeuring van de adviseur moeten
traceerbaar zijn in het configuration management systeem.
Als zo'n document dan van voldoende kwaliteit is
(ter beoordeling van de eigen adviseur),
dan wordt het ter review voorgelegd aan studenten uit andere groepen.
Dit zijn voor een gegeven project steeds dezelfde andere groepen.
De groepen zijn opgedeeld in twee clusters van vier groepen
(1,2,3,4 en 5,6,7,8).
Zo'n externe review is een formeel review,
de rollen zijn:
- organisator / initiatiefnemer (maakt afspraken e.d.)
- moderator: adviseur
- auteur(s): uit gereviewde groep
- notulist: uit gereviewde groep (quality engineer)
- reviewers: één uit elke groep van de cluster,
en waar nodig ook de klant.
Bij deze externe reviews dient ieder groepslid
een keer aan de beurt geweest te zijn als reviewer.
Opmerkingen van de externe reviewers worden van tevoren op schrift volgens
sjabloon ingeleverd bij de moderator.
In de vergadering worden deze
besproken om vast te stellen of het document een aanpassing behoeft
(geen oplossingen zoeken) en wordt de status van het document bepaald:
- ok
- rework zonder nieuwe review
- rework met nieuwe review.
Het verslag van de notulist (inclusief de ingeleverde opmerkingen) wordt
opgenemen in het configuration management systeem en
ook bij het senior management ingeleverd.
Dit verslag vermeld in ieder geval:
- wanneer (datum, tijd) de reviewvergadering gehouden is
- wie daarbij aanwezig waren en in welke rol
- belangrijkste discussiepunten
- samenvatting van de ingeleverde opmerkingen
- lijst van beslissingen en afspraken die gemaakt zijn
- status van het gereviewde document
Tenminste de volgende productdocumenten worden extern gereviewed:
- URD (de klant levert ook een reviewer)
- SRD (de klant mag ook een reviewer leveren)
- User interface prototype (alleen de klant levert een reviewer; geen vergadering)
- ADD
- DDD (zonder code)
- SUM (alleen de klant levert een reviewer; geen vergadering)
- ATP (met testcases, de klant levert ook een reviewer)
- TR (alleen de klant levert een reviewer; geen vergadering)
Het SPMP, SCMP, SVVP en SQAP
dienen goedgekeurd te worden door het senior management.
©2001, Tom Verhoeff (TUE)
Feedback about this page is welcome