Software Engineering Projecten (SEP): Review Info

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

• 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

• IEEE Standard for Software Reviews (IEEE Std 1028-1997).
• Review Checklists

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.

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