Download whitepapers, case studies
en onderzoeken over ICT-onderwerpen
Computable IT Knowledge Base
  Dagelijks het laatste
ICT-nieuws in je inbox?
Computable e-mail nieuwsbrief

Development / Opinie

04-06-2004 00:00 | Door Rik (e.a.) Marselis | Er zijn nog geen reacties op dit artikel | Permalink

Testen binnen Prince II

"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
reageer print stuur door
Reageer
rssMeer Development
Development Whitepapers

Vendor lock-in behoort tot het verleden met open standaarden

Open standaarden en open software maken het mogelijk om IT weer te zien als opportunity en niet als een beperkende factor. Inhaken op trends en ontwikkelingen gaat sneller met open standaarden en open source software, zo wordt betoogd in deze whitepaper.... Download nu

Meerwaarde Agile in kaart gebracht

Wat is Agile Development. Hoe werkt het? Wat is de meerwaarde ten opzichte traditionele ontwikkelmethoden en welke veranderingen zijn noodzakelijk om goed gebruik te maken van Agile. Deze en meer antwoorden leest u in deze whitepaper.... Download nu

Meer Development whitepapers

SAP-maatwerk, duur beheer

Als er veel wordt gesleuteld aan een SAP-applicatie, zorgt dat voor hogere beheerkosten na het project. Maar het is lastig aan de organisatie duidelijk te maken dat maatwerk niet altijd de beste oplossing is.

Meer maatwerk bij SAP maakt beheer duurder
Development Producten

ATG introduceert ATG Commerce Suite 9

01-12 16:53   Art Technology Group (ATG), aanbieder van software voor e-handel die beschikbaar is als platform van optimaliseringdiensten voor uitbreiding, presenteert ATG Commerce Suite 9. Met...

Meer development producten
Development Praktijk

Booking.com zweert bij open source

10-03 14:24   De capaciteit van de infrastructuur van reserveringswebsite Booking.com is de afgelopen jaren vertienvoudigd. Dat levert niet alleen hoofdbrekens op over onder andere...

Meer development praktijk
Development Achtergrond

Oude bugs blijven bijten

12-11 10:19   Oude bugs in software hebben nog een flinke nasleep. Soms worden oude fouten simpelweg niet hersteld, soms gebeurt het afdekken van gaten niet goed, en ook blijken ze in meer...

Meer development achtergrond
Development Opinie

Omzetcontrole bij e-commerce

01-12 14:47   Laatst sloot mijn buurman, een niet-ict’er, een doorlopende reisverzekering af via internet. De website van de verzekeringsmaatschappij waar hij de verzekering in eerste instantie...

Meer development opinie
IT Directory

Bekijk de leveranciers op het gebied van Development.