“J. Roos geeft een goed beeld van de algemene opzet van een Prince II-project en gaat dieper in op het kwaliteitsmanagement dan voor ons in ons artikel mogelijk was, dus een prima aanvulling”, schrijven Rik Marselis en Erik Brouwer.
Roos reageert met ‘Basis Prince II aangetast’ (Computable, 14 mei 2004) op ons artikel ‘Testen binnen Prince II’ (23 april 2004). Hoewel zijn reactie een prima aanvulling is, willen wij een nadere toelichting geven, want op het gebied van testen binnen een Prince II-project missen we het inzicht in zijn reactie.
Wij zien het toepassen van de rrbt-aanpak (risk & requirement based testing) voor het managen van het testen binnen een project als een goede invulling van de lacunes op testvlak in de Prince II-methodiek; complementair dus en niet verweven, zoals Roos stelt. Met rrbt geef je het managen van het testtraject in elke willekeurige omgeving uitstekend vorm. Het past naadloos in een Prince II-projectomgeving. Door de toepassing van rrbt is op elk gewenst moment tijdens het project inzicht te geven in de kwaliteit van de (sub)producten. Een project is de som van (sub)producten. Derhalve valt door het toepassen van rrbt een antwoord te geven op de vraag of voldaan wordt aan de zakelijke rechtvaardiging op elk moment van de looptijd van het project.
Wij vinden het vreemd om te stellen dat binnen een open methode als Prince II elke aanvulling onmiddellijk moet worden goedgekeurd en opgenomen in de dikke boeken; dan laat je de theorie boven de praktijk prevaleren.
Praktijkervaring
Roos somt een groot aantal aspecten uit het officiële Prince II-boek op. Wij missen daarbij echter het volgende citaat (uit Managing Succesfull Projects with Prince II. 3de editie 5de druk 2003, the Office of Government Commerce, p. 260): “Het plannen van de kwaliteit in een project moet de volgende aspecten bestrijken om te borgen dat het project een acceptabel niveau van kwaliteit oplevert: hoe, wanneer en door wie wordt elk product getest tegen de kwaliteitscriteria; hoe wordt acceptatie gemeld.”
Bij het beantwoorden van deze vragen in de processen ip1 (planning quality) en sb1 (planning a stage) kan uitstekend gebruik gemaakt worden van de rrbt-aanpak zoals in ons artikel beschreven. Deze testmanagementaanpak richt immers het testproces in op basis van een productrisicoanalyse en de vereisten. De productrisicoanalyse vormt de essentiële input voor de teststrategie. Deze analyse stelt vast welke productrisico’s aan het product verbonden zijn. De belangrijkste risico’s krijgen meer aandacht en worden als eerste getest.
Op het vlak van het testen als zodanig heeft Roos klaarblijkelijk weinig praktijkervaring. Anders had hij zich gerealiseerd dat sommige kwaliteitsattributen simpelweg niet te verifiëren zijn door de teammanager die verantwoordelijk is voor het realiseren van een bepaald product. Stel dat de teammanager een product moet opleveren dat afhankelijk is van twee andere producten voor respectievelijk invoer en uitvoer, waarbij een kwaliteitscriterium is dat het totale proces niet langer dan een bepaalde tijd mag duren. In dat geval heeft de teammanager een testomgeving nodig die overeenkomt met de uiteindelijke situatie. Dit is pas mogelijk als alle producten zijn opgeleverd. Zo’n omgeving is doorgaans niet beschikbaar in het stadium waarin het afzonderlijke product opgeleverd moet worden.
In een later stadium, tijdens een acceptatietest, zal dit kwaliteitscriterium wel te testen zijn. Zo’n acceptatietest zal dan voor een groot aantal producten dergelijke kwaliteitscriteria beoordelen. Het zou onwerkbaar zijn om dat onder verantwoordelijkheid van de respectievelijke teammanagers te laten doen. In dat geval wordt een apart testproduct gedefinieerd waarvoor een testmanager in de rol van teammanager verantwoordelijk is.
Wij delen met Roos het enthousiasme voor het gebruik van Prince II als aanpak voor projectbesturing en hopen dat deze discussie ertoe bijdraagt dat nog meer mensen hierin een nuttige bijdrage aan het vervullen van projectdoelstellingen zien.< BR>
Rik Marselis, Erik Brouwer, Test Research Centre, Logica CMG
