Reviewaspecten in een moderne ontwikkelomgeving

Bij de klassieke manier van automatiseren krijgt de gebruikersorganisatie aan het begin van de ontwerpfase de gelegenheid om aan te geven welke functionaliteit hij wenst. Daarna trekt de ontwerper zich terug en komt na verloop van tijd met een product dat het concept-ontwerp heet. Op dit ontwerp kon de gebruiker dan commentaar leveren waarna een definitief-ontwerp het leven zag. In de praktijk bleek dit niet voldoende zodat al gauw een uitsplitsing naar functioneel- en technisch-ont­werp werd gemaakt. Het technische deel diende als uitgangspunt voor de programmeurs, terwijl het functio­nele deel diende als praatpapier met de gebruikersorganisatie. Toen het mogelijk werd om steeds complexere databases op te zetten was deze verdeling nog niet voldoende. Het maken van een ontwerp vergde namelijk een grote inspanning terwijl de gebruikers­orga­nisatie de mogelijkheid had om op het laatst de boel nog om te gooien of helemaal af te blazen.

Daarom werd de Informatie analyse geïntroduceerd dat een meer conceptuele kijk op het toekomstige informatiesysteem beoogd. Na de Informatie analyse volgt dan het ont­werp.

De huidige technieken stellen de automatiseerders instaat om snel een aantal schermen en lijsten op te zetten en deze in een soort prototype samen te laten werken. Het prototype wordt aan enkele gebruikers getoond waarbij om een oordeel wordt gevraagd. Deze techniek wordt prototyping genoemd. Kern van deze techniek is dat de opmerkin­gen direct in het prototype worden verwerkt zodat een nieuw prototype ontstaat. Pas na deze acties weet de automatiseerder welke verwachting de gebruiker heeft zodat aan het ontwerp kan worden begonnen.

Nog eens stap verder gaat Rapid Application Development (RAD) waarbij in plaats van een prototype direct een werkende applicatie wordt gebouwd. Ook bij deze ontwikkeltechniek zal er echter nog veel te reviewen zijn. Er dienen ontwerpdocumenten te zijn die iets zeggen over:

–       De gebruikers interface.
–       De interfaces met andere systemen.
–       De beveiligingsmaatregelen.
–       Enz.

De review van een ICT product

Een goede manier om ontwerpen en andere projectproducten te toetsen is het uitvoeren van een review. Het gaat hierbij om leesbare producten, zoals rapporten, ontwerpen en handleidingen. Bij een review wordt een projectproduct door een team uit de organisatie getoetst aan de normen die de organisatie zelf voor deze producten heeft vastgesteld. Daarbij wordt bijvoorbeeld gelet op de ontwerpstandaard van de organisatie, het gebruik van reeds eerder ontwikkelde toepassingen, hergebruik van delen van het vorige systeem, de juiste toepassing van de methodologie, de haalbaarheid van de projectplan­ning, aansluiting op het Informatieplan enzovoort. Het doel van de review is zelf fouten in een zo vroeg mogelijk­ stadium te ontdekken omdat ze dan nog zonder al te hoge kosten zijn te herstellen. Reviews passen dus in een kwaliteitsverbetercirkel en moeten als integraal onderdeel van het software­proces worden gezien. Dit in tegenstelling tot een audit.

Het moment waarop een review plaatsvindt is afhankelijk van de projectplanning en het soort projectproduct dat moet worden beoordeeld. Het aantal reviews dat tijdens een project plaatsvindt kan zeer groot zijn en is afhankelijk van de omvang van het project en de gekozen methodologie. Bij een project vindt een review plaats op alle plannen van aanpak (5), op alle eindrapporten (5) en alle projectproducten (vaak tientallen). Het is duidelijk dat er voor het uitvoeren van review tijd moet worden ingepland.

De checklisten van ITpedia kunnen bij een review worden toegepast; zij geven een overzicht van de kwaliteitseisen die aan het projectproduct worden gesteld. Tevens kunnen verschillende producten met behulp van de checklisten eenduidig worden beoordeeld. Hoewel de checklisten door iedere reviewer tijdens de projectproduct-beoordeling worden ingevuld kan de checklist tevens als leidraad voor de review-vergadering dienen.

Het reviewtype.

Niet ieder projectproduct kan op dezelfde wijze worden gereviewd. Daarom zijn reviews in een aantal typen onder te verdelen.

Er zijn een aantal typen reviews te onderkennen, t.w. 1. Review op de plannen; 2. Review op consistentie projectproduct; 3. Review op risico’s projectproduct en 4. Review op eindrapport.

1.         Review op plan van aanpak. In dit reviewtype wordt beoordeeld of de projectleider een goed het plan van aanpak heeft gemaakt. Er wordt bekeken of de planning haalbaar is, of de juiste technieken toegepast gaan worden en of de juiste project­producten zijn gedefinieerd. Tevens wordt reeds bepaalt of het project aansluit bij de Business analyse.

2.         Review op consistentie projectproduct. Het is van belang om vast te stellen of het projectproduct aansluit bij de andere projectproducten en in zichzelf een consistent geheel vormt. Bij een technisch-ontwerp dient bijvoorbeeld te worden gecontroleerd of het aansluit bij de functies zoals die in het functionele deel zijn ontworpen; alle functies die in de Informatie analyse gedefinieerd zijn dienen in het Functionele ontwerp te worden beschreven; alle “datastores” in een Dataflowdia­gram dienen in de datadictionary te zijn opgenomen enzovoort. Veel van deze controles wordt door ontwikkeltools ondersteund waardoor het review werk een stuk lichter is geworden.

3.         Review op risico’s projectproduct. Het type review dat voornamelijk met de gebruikers­organisa­tie wordt uitgevoerd. De gebruiker dient namelijk als opdrachtge­ver akkoord te gaan met de beslissingen die tijdens het project worden genomen. Tevens dient hij zich voortdurend voor ogen te houden wat straks de gevolgen van deze beslissin­gen zullen zijn, komt dat systeem waar iedereen graag mee wil werken er, of buigen we hoe langer hoe meer van dit ideaal af met het risico dat het systeem straks niet aan de verwachtingen voldoet.

4.         Review op eindrapport. Het eindrapport van een ontwikkelfase is een samenstelling van de projectpro­ducten uit die fase waarmee de fase wordt afgerond. Het eindrap­port mag geen openstaande vragen meer bevatten en dient compleet te zijn. De kwaliteit van het eindrapport dient zodanig te zijn dat de opdrachtgever de beslissing kan nemen de volgende projectfase te starten of het project geheel af te blazen, tevens moeten de medewerkers van de volgende projectfase kunnen vertrouwen op het eindrapport. Met andere woorden het eindrapport mag geen aannames meer bevatten maar slechts onderbouwde definities.

De betrokkenen.

Een review wordt doorgaans door een groep personen uitgevoerd die ieder een bepaalde rol tijdens de review vervullen. Deze personen dienen in ieder geval een professionele instelling t.a.v. kwaliteit te hebben en de review niet als een persoonlijke beoordeling te zien. Dit geldt voor zowel de persoon wiens product wordt gereviewd als voor de personen die de review uitvoeren. Daarnaast dienen de reviewers een bepaalde persoon­lijkheid te hebben zodat zij de juiste toon kunnen zetten en de door hun gewenste acties worden uitgevoerd.

Tijdens de review worden door de betrokkenen checklisten ingevuld waardoor een eenduidige wijze van beoordelen ontstaat.
Afhankelijk van het reviewtype, de omvang en de complexiteit van het project worden de volgende rollen onderkend:

De reviewleider.
•           De reviewleider coördineert het reviewproces en is verantwoordelijk voor de te volgen procedures. Tevens maakt hij de afspraken voor vergaderingen en benadert hij (externe) reviewers.
De reviewleider zal het reviewproces tevens evalueren op zijn bruikbaarheid zodat het eventueel kan worden verbeterd.

Het hoofd-informatievoorziening.
•           Het hoofd-informatievoorziening is verantwoordelijk voor een juiste inpassing van het project binnen de andere systemen van de organisatie. Hij zal het IT-product dus moeten toetsen aan de doelstelling van het project zoals dat in het informatieplan is vastge­legd.

De consultant.
•           De consultant bewaakt de juiste toepassing van de gekozen methodologie en de technieken die deze methodologie voorschrijft. Accent ligt daarbij op de consistentie tussen de toegepaste technie­ken. Tevens stelt hij vast welke aandachtspunten voor deze specifieke review van toepassing zijn.

De reviewer.
•           De reviewer is een van de betrokken automatiseerders wiens product echter niet wordt gereviewd.
De reviewer beoordeelt mede het product en let daarbij met name op de interface met andere (deel)systemen die ook bij het project zijn betrokken.Tevens stelt hij de reviewrapportage op.

De projectleider.
•           De projectleider neemt als eerst verantwoordelijke voor het projectproduct ook deel aan de reviews.
Tevens draagt hij er zorg voor dat de producten die gereviewd worden voldoende af zijn op het moment dat de review is gepland. De distributie van het product ligt in zijn handen en dient op tijd plaats te vinden zodat de reviewgroep nog voldoende tijd heeft om het product door te nemen.

Na de review koppelt de projectleider de bevindingen terug met de maker van het product via de rapportage en zorgt dat het product wordt aangepast.

De methodologie-deskundige.
•           De methodologie-deskundige geeft zijn oordeel over het IT-product ten aanzien van de volledig­heid. Daarbij geeft hij aan of er geen informatie in het IT-product ontbreekt die de toegepaste methodologie minimaal voorschrijft voor de specifieke situatie van dit project.

De materiedeskundige.
•           De materiedeskundige is veelal tevens het hoofd van de afdeling waarvoor de automatisering plaatsvindt. Meestal zal hij voorafgaand aan de reviewvergadering het product met enkele van zijn medewerkers in een aparte sessie doornemen om zo vast te stellen of de inhoud van het product in overeenstemming is met de beleving van de gebruiker.

De review activiteiten.

Het houden van een review valt uiteen in een aantal activiteiten die op zich grote overeenkomsten vertonen met de opzet van een ontwikkelfase. Naast het houden van de reviews zelf moet ook de wijze waarop de reviews zijn opgezet worden onderhouden. Bij elke review dient dus geëvalueerd te worden hoe de review is verlopen en of de review voldoende effect heeft gehad. Tevens kan een pool van vaste reviewers worden samengesteld van mensen die daar speciaal voor zijn opgeleid.

De review zelf kent de volgende fasen :

1          Plannen review.
• Vaststellen reviewopdracht.
• Vaststellen reviewtype.
• Vaststellen review moment.
• Vaststellen reviewgroep.
• Vaststellen checklisten.
• Vaststellen reviewlocatie.
• Verzamelen reviewobjecten (documenten, PC, software, enzovoort).

2          Projectproduct beoordeling.
• Versturen te reviewen reviewobject en achtergronddocumentatie.
• Vaststellen volledigheid van het object volgends de rol van betrokkene.
• Vaststellen juistheid naar eigen rol betrokkene.
• Vaststellen consistentie naar eigen rol betrokkene.
• Invullen / verwerken checklisten.

3          Houden reviewvergadering.
• Vaststellen status reviewobject.
• Doornemen individuele beoordelingen.
• Vaststellen gebruikersstandpunt.
• Vaststellen aansluiting op informatieplan.
• Vaststellen bevindingen en oordeel.

4          Opstellen reviewrapport.
• Opstellen rapport.
• Rapport doorlaten nemen door betrokkenen.
• Rapport distribueren.
• Rapport archiveren.
• Toezien op naleving adviezen.

Boeken over dit onderwerp

PMC Compact

Auteur: Jo Bos
Vele malen kwam het verzoek om de belangrijkste principes en werkvormen van de methode Projectmatig Creeëren in een compacte uitgave samen te brengen. In ‘PMC Compact’, een handzame gids voor projectmanagers, opdrachtgevers en teamleden, vindt u de werkvormen van Projectmatig Creëren in overzichtelijke stappen uitgelegd, voorzien van veel tips uit de praktijk.
Europrijs: 18,95
Bestellen

Projectmanagement op basis van PRINCE2, Editie 2009

Auteur: Bert Hedeman
Ten eerste is dit boek bedoeld voor iedereen die zich op een degelijke wijze wil voorbereiden op het PRINCE2 Foundation examen. Ten tweede is het een praktisch gebruikersboek.
Europrijs: 31,75
Bestellen

Meer boeken over testen vinden.


-- Printbare PDF-versie --


No votes yet.
Please wait...

Aanvullingen

Geef zelf een aanvulling.

Geef een aanvulling

Licentie: Creative Commons (Naamsvermelding/Gelijkdelen)

Checklisten:
Risico-analyse keuze voor Agile 13 vragen.
Kostenbepaling Informatie analyse 15 vragen.
Kader bepaling Informatie analyse 26 vragen.
Risico-analyse Informatie analyse 17 vragen.
Planning Ontwerp 24 vragen.
Kader bepaling Ontwerp 24 vragen.
Valideer functionele aspecten 31 vragen.
Valideer controle aspecten 17 vragen.
Valideer gevolgde procedures 10 vragen.
Beoordeel gevolgde ontwerpprocedure 11 vragen.
Kader bepaling Realisatie 19 vragen.
Risico-analyse Invoering 18 vragen.
Sidebar