cm2rc inleiding(onderhanden June 2015, the 24th)

Cm2RC
Een route naar betrouwbare Ketens
I have developed, in course of my career, a personal view on Chain testing. This is my
Methodology of Chain management, to hands-on, organize and manage chain testing as
Chainmanagement!
flutsch-it
Willem Flutsch
June 2015
Route naar betrouwbare Ketens, een
inleiding
I have, in course of my career, developed my personal view on Chain Testing. At the moment (may
2015), I'm converting this to a useful methodology of Chain management to, hands-on, organize
and manage chain testing.
-
Cm2RC ’s-Heerenberg, June 2015 –
Hier ga ik nog even over op het Nederlands,
daar mijn "brain drain" ook in het Nederlands gaat.
Later, als ik tevreden ben, en mijn reviewers ;), zal dit vertaald worden in het Engels!
Momenteel(June 2015) ben ik begonnen mijn visie hieromtrent in boekvorm te bundelen; mijn
voortgang kunt u hier downloaden, evenals op mijn LinkedIn pagina.
Ook zal ik u verwijzen, middels een Link op de pagina: "goed om te weten", naar artikelen,
waarvan ik denk dat ze belangrijk kunnen zijn voor u om te komen tot, wat ik noem: Een "Route
naar betrouwbare Ketens!" Cm2RC; zaken die ik ook zal benoemen en voorzien van tips in mijn
boek met dezelfde naam.
Mijn methodiek lijkt op het volgen van een route, of dat nu per fiets, wandelend of met de motor
is. Je hebt 2 soorten routes, 1 die loopt van A naar B, en 1 die loopt van A naar A waarbij je dus
uitkomt waar je begonnen bent.
Deze laatste categorie gebruik ik ook in mijn methodiek om chainmanagement uit te voeren, daar
het niet altijd mogelijk is te beginnen bij het echte begin, maar je dus wel de ronde kunt
voltooien en dus alsnog kunt uitkomen waar je begonnen bent!
Hiervoor is het iets minder belangrijk welke testmethode u kiest, dat kan per organisatie
verschillen!
Ik ga u misschien teleurstellen als u iets heel nieuws van mij denk te horen, sorry! De afgelopen
15 jaar heb ik veel ervaring opgedaan en door veel leeswerk en zelfstudie ben ik tot de slotsom
gekomen dat, “het Ketendenken” om te zetten in een praktische methodiek waar u wat aan heeft.
Cm2RC - flutschit
Pagina 2/15
Er is veel theorie te vinden, die, bij de juiste selectie, een heel werkbare en betrouwbare
werkwijze opleveren.
Het enige wat ontbreekt, is een juiste methodiek. Ik heb er geen kunnen vinden, anders dan mijn
methodiek, die ik zelf ook wel "Common Sense" noem en als zodanig ook al een aantal jaren in
mijn CV heb opgenomen. Je kunt het ook pragmatisme noemen.
Het punt is namelijk dat ik vaak in een programma en/ of project stap, vaak Prince2, waarbij “het
Ketendenken” wel bekend is, en ook wel onderkend wordt binnen het programma/project, maar
(nog) niet volledig door de organisatie. Dat is, volgens mij, geen onwil maar onder meer een
gebrek aan de juiste methodiek. Daarbij spelen natuurlijk nog wel meer zaken zoals wegebbende
kennis, outsourcing, het inzetten van mij en mijn collega's ;) en de techniek, om er maar een paar
te noemen. Op de techniek kom ik nog uitgebreid terug, daar dit een van de grootste
veroorzakers is van het groeien van de Ketens. Ook zal ik dieper ingaan op de huidige project
management methoden, waar best wel iets over testen gezegd moet worden(Prince2, het
product/deliverable MTP(Master Test Plan)). Daar mag je over het algemeen niet afwijken van de
gebruikelijke testmethode binnen de organisatie, maar als er geen planning in staat, is deze niet
volledig en wordt dan ook niet geaccepteerd. “Gebaseerd op wat”, is dan steevast mijn vraag, er
moet zelfs nog maar een begin gemaakt worden met het eerste functioneel ontwerp? Dit is
waardoor ik redelijk vaak met natte vingers zit. ;)
Hier gaat mijn methodiek Cm2RC, “Chainmanagement to reliable Chains” u bij helpen!
Ik ben normaliter niet iemand die met een handboek door het testleven gaat. Niet dat ik vind dat
theorie er niet toe zou doen, maar als ik moet kiezen tussen een theoretisch tester of een
tester uit de praktijk, dan zou ik gaan voor de laatste. Een boek is snel gepakt, daarentegen
praktijkervaring moet je gewoon opdoen!
Dus ga ik in deze methodiek, mijn praktische kennis koppelen aan de theorie en zal van elke, bij
mij bekende, theorie die ik in de praktijk ben tegen gekomen het beste en/of bruikbaarste
onderdeel lenen(uiteraard zal ik overal de bron vermelden!).
 Tot zover mijn inleiding op dit moment, June 2015.
Mijn planning is, per maand, één hoofdstuk(samenvatting) te publiceren!
Mocht u vragen en/of opmerkingen hebben, mij af willen schieten(ik ga geen enkele discussie uit
de weg!) of een mogelijke positieve bijdrage willen leveren, kijkt u op mijn sites:
www.chainmanagement.eu, www.cm2rc.eu of www.flutsch-it.eu, om hier nog wat extra informatie
over mij te vinden. Daar kunt u ook uw mening aan mij mailen.
De sites hierboven genoemd zijn nu nog aan elkaar gelinkt, maar zullen gaandeweg dit jaar los van
elkaar, hun eigen gezicht en inhoud krijgen!
Uiteraard mag dat ook direct, via: [email protected]
Ik hoor graag wat u er van vindt, zowel positief als negatief.
Cm2RC - flutschit
Pagina 3/15
Inhoud
Inleiding. ............................................................................................................................................................... 5
Maar eerst nog even dit:
waar ga ik het hierna allemaal over hebben ................................................ 6
Projectmanagement ............................................................................................................................................ 7
Niets mis met de huidige Projectmanagement methodieken ............................................................... 7
Traceability ........................................................................................................................................................ 10
Traceability matrix ...................................................................................................................................... 11
Bijlages ................................................................................................................................................................ 12
1.
Mijn startpunt ...................................................................................................................................... 12
Index ................................................................................................................................................................... 15
Cm2RC - flutschit
Pagina 4/15
Inleiding.
Er is mij, een jaar geleden, gevraagd of ik, voor een boek met 100 tips voor testers, ook een duit
in het testzakje wilde doen. Dat is het document “Mijn startpunt” zie bijlage 1.
Het moest in, ik meen 300 woorden max, het werden er wat meer. U begrijpt al, dit was niet een
tip maar een andere kijk op testen, dus hier zaten ze niet op te wachten.
Ik had toch wel wat energie en tijd hierin gestoken en dacht toen; hier wil ik meer mee doen!
Uiteindelijk heeft dit mij tot de slotsom gebracht dat er iets ontbreek in de huidige methoden
voor systeemontwikkeling. Of dit nu Waterval, Agile, Rapid Development of noem ze allemaal
maar op. Allen missen dezelfde basisgedachte, te weten “Ketenregie”.
Uiteraard doet elk zichzelf respecterende tester geen uitspraak of de uiteindelijke oplevering
voldoet aan alle kwaliteitseisen zonder Ketentesten. De scope is echter al bepaald bij initiatie
van het programma/project. Het budget is al bepaald, en ga zo maar door.
Dit laatste kan niet zonder een bepaalde manier van projectmatig werken, zelfs met Agile, wat
mij brengt tot mijn volgende punt.
Cm2RC - flutschit
Pagina 5/15
Maar eerst nog even dit: waar ga ik het hierna allemaal over hebben?
In alfabetische volgorde(althans nu nog in deze versie), als het goed is wordt deze lijst
steeds korter, totdad hij verdwenen is in de inhoud en ik dus tevreden bem met hetgeen ik
wil vertellen!

Business Intelligence Software

Business Reporting

Data Modelling – CDM

Governance

Het Ketendenken
o
Ketenmanagement
o
Ketenregie

Kwaliteitsmanagement

Outsourcing Testen

Procesmanagement

Projectmanagement

Requirements en acceptatie

Risicomanagement

Software ontwikkeling

Testautomation

Testen

Testmanagement

Traceability
o

Traceability matrix
Tools
Hierbij wil ik, de door mij onderzochte methodieken, methoden etc. gebruiken.
Ik wil n.l. voorkomen dat er in uw organisatie onrust zou ontstaan bij het idee, weer andere
tooling etc. te moeten gaan leren en gebruiken.
Mijn uitganspunt is dat er, zoveel mogelijk, geprobeerd wordt aan te sluiten op/bij reeds
bekende zaken.
U kunt natuurlijk er voor kiezen om op dit punt andere keuzes te maken, die meer op elkaar
aansluiten. Dit zou dan het moment zijn, gericht op “het Ketendenken” en het Ketenmanagement!
Cm2RC - flutschit
Pagina 6/15
Projectmanagement
Niets mis met de huidige Projectmanagement methodieken
Tot op heden wordt nog vaak gesproken over
a) “het testen als onderdeel van een project en/of programma”, en daarnaast
b) kom ik ook tegen dat er een “Test project” moet worden ingericht, gemanaged of worden
uitgevoerd. Dit is naar mijn mening niet helemaal meer van deze tijd, althans niet in de
context, dat er een of meerdere testactiviteiten moeten worden uitgevoerd om de
changes binnen de scope van dat project en/of programma te controleren/testen op
betrouwbaarheid, robuustheid etc..
c) … nog wel een paar, maar niet relevant om mijn punt te maken!
Deze definities zijn correct, maar in de meeste gevallen niet meer volledig.
Nemen we Prince2. Een van de deliverables (op te leveren producten), waarvan een
testverantwoordelijke uit moet gaan is het PID 1(Project Initiation Documentation).
De scopeafbakening van het probleem(of opdracht) wordt al in de Feasibility Study2 bepaald en
afgebakend. Dan hebben we nog de Business Case. Dit gaat over het beantwoorden van de
'waarom' vraag. Waarom zou het project moeten worden gestart, waarom zou het uitgevoerd
moeten worden, waarom zijn de producten die het project gaat opleveren nuttig voor de
organisatie. Het gaat om de afweging tussen de inspanningen (in tijd, geld, middelen etc.) die het
project vergt en de baten die het gaat opleveren. Niet eenmalig, maar gedurende de gehele
levensloop van het project. Elke keer als een fase (stage) van het project is afgelopen, wordt de
Business Case3 bijgewerkt, en wordt beoordeeld of het nog zinvol is om het project door te
zetten. Ergens in de Product Breakdown Structure4(PBS) moet een Master Test Plan(MTP)
worden opgeleverd. Gaan we even uit van T-map, dan hoort daar het volgende in te staan:
De globale planning behoord minimaal het volgende te omvatten:




uit te voeren activiteiten (op faseniveau per testsoort); relaties met en afhankelijkheden
van andere activiteiten (binnen of buiten het testproces en tussen de diverse
testsoorten);
te besteden tijd per testsoort;
benodigde en beschikbare resources (organisatie en infrastructuur);
benodigde en beschikbare doorlooptijd.
1
Een document waarin alle benodigde relevante informatie wordt samengevoegd, om het project een goede
start te geven en alle betrokkenen te informeren over de aanpak. Met het Projectinitiatiedocument wordt de
basis gelegd voor het project.
2
Een studie waarin wordt onderzocht of een oplossing of benadering voor een bepaald probleem of doel
haalbaar is. Het onderzoek zal normaal gesproken het probleem afbakenen, een aantal mogelijke oplossingen
identificeren en uitwerken en een aanbeveling over de te ondernemen actie. Het berekenen van een globale
Business Case voor iedere optie is onderdeel van het werk. Het is een van de aspecten waarmee de opties
onderling worden vergeleken.
3
De informatie die de rechtvaardiging voor het opzetten en continueren van een PRINCE2-project beschrijft.
Het geeft aan waarom (de redenen) het project moet worden uitgevoerd en beantwoord het ‘waarom?’. De
Business Case wordt op belangrijke momenten in het project bijgewerkt.
4
Een hiërarchische overzicht van alle producten, die binnen een plan moeten worden geproduceerd.
Cm2RC - flutschit
Pagina 7/15
Het woord Keten kom ik nergens tegen, dus hier is dan de eerste taak voor
Chainmanagement(Keten regie), een overall Teststrategie voor Ketens!
Hierin zullen de Ketens onderkend moeten worden, met de Ketenparameters die empirisch
bepaald kunnen zijn in uw vorige projecten!
Als het goed is zijn er gedurende het project(Prince2) een “Issue Log 5” en “Lessons Learned
Report6” geproduceerd; dit zijn de uitgelezen producten van Prince2 die hiervoor gebruikt dienen
te worden, dus geen extra inspanning vereist!
Ik ken op het moment 2 goede boeken over testen met Ketens:
 Testen van Ketens met TMap NEXT, van Rob Smit & Rob Baarda Sogeti 2009, en
 Praktijkgerichte aanpak voor End to End (E2E) testen, van Gerard Numan-Polteq 2014-15.
Deze 2 uitgaves overlappen elkaar op sommige punten, maar zeker het boek van Numan is een
goede aanvulling op het boek van Smit/Baarda! Heel goed bruikbaar, mits de juiste
Keteninformatie wordt aangeleverd.
Echter het testen staat in beide centraal, en hoe je dit kunt inrichten, maar niet hoe je zover
kunt komen. Dit wordt overgelaten aan de desbetreffende Testmanager, die deze methode zou
gebruiken, om in te richten. Ik ben dit tegen gekomen(en heb het ook zo uitgevoerd), en op zich
functioneerde dat. Maar omdat er geen ‘standaard’ voor is doet ieder dat op zijn eigen wijze,
zelfs binnen één organisatie in verschillende projecten met dus verschillende testmanagers. U
begrijpt, op de lange termijn gaat dit ook niet werken!
Wat er mist is een schil of, misschien beter, een manier van werken, om dit alles te
verbinden, en géén nieuwe testmethode daar er al diverse goede methoden(niet enkel
TMap) zijn, en géén nieuwe projectmanagent methode, Prince2 voldoet naar mijn mening
heel goed, zelfs in combinatie met Agile!
 De Octopus, en die mag zelfs best meer dan 8 armen hebben, zoveel als nodig in uw
organisatie!
Ik spreek hier trouwens géén voorkeur uit maar noem de 2 meest gebruikte methoden. U
kunt gerust andere methoden combineren, als u mijn methodiek zou omarmen. Verderop in
dit boek zal ik een aantal hiervan bespreken, zowel projectmanagement- als testmethoden.
Als bijlage zal ik andere m
Dit heeft het grote voordeel dat uw medewerkers, zowel management als mensen op de
vloer, gewoon de hun bekende methoden kunnen blijven gebruiken. Hooguit hier en daar
selectief of iets aangepast.
5
Een lijst met alle tijdens het project ingediende Project Issues, inclusief Wijzigingsverzoeken. Het bevat van elk
Project Issue de details, de evaluatie, de genomen besluiten en de huidige status.
6
Een rapport dat de leerpunten uit het project beschrijft, inclusief de resultaten van de kwaliteitscontrole van
managementproducten. Het rapport wordt goedgekeurd door de Stuurgroep en daarna centraal bewaard,
zodat toekomstige projecten ervan kunnen profiteren.
Cm2RC - flutschit
Pagina 8/15
 Dit zou moeten blijken uit de methodiek die nu voor u langzaam gestalte moet
gaan krijgen!
Waar wil ik naartoe zult u zo langzamerhand wel denken want eigenlijk heb ik alleen nog maar
open deuren ingetrapt.
Traceabilty dus, dat is waar het allemaal om moet draaien.
Hier ga ik bij het vervolg mee verder!
Cm2RC - flutschit
Pagina 9/15
Traceability
Waar wil ik naartoe zult u zo langzamerhand wel denken want eigenlijk heb ik alleen nog maar
open deuren ingetrapt.

Traceabilty dus, dat is waar het allemaal om moet draaien, dit en uiteraard zijn product,
de traceability matrix!
Dit is, alweer, niet iets wat ik ter plekke bedenk!
Cm2RC - flutschit
Pagina 10/15
Traceability matrix
Cm2RC - flutschit
Pagina 11/15
Bijlages
1. Mijn startpunt
Willem Flutsch/flutschit, Test- en kwaliteitsmanagement, Ketenregie
Mijn vrije interpretatie van de gestelde vraag was; schrijf een tip voor testen en testers.
Toevallig denk ik al een aantal jaren hoe het testen zou moeten worden ingericht t.b.v. het
leveren van kwaliteit. Ik kan dan ook geen echte tip geven binnen de huidige testarchitectuur.
Van een auto kan ik ook geen betere auto maken door er een ander stuur in te zetten. Toch zal ik
hieronder een richting aan proberen te geven waaraan testprofesionals iets kunnen hebben. Ik
weet dat ik niet de enige testprofessional ben die hier wel eens zijn gedachte over laat gaan.
Mijn achtergrond in de IT is gebaseerd op de financiële branche, hoofdzakelijk banken, dus
vanuit die optiek zal ik dit dan ook benaderen. In deze branche is de scope toch wel aanzienlijk
veranderd t.o.v. vroeger. Naar mijn mening kun je niet iets over testen zeggen zonder eerst iets
te zeggen hoe er ontwikkeld wordt, of beter, hoe er ontwikkeld dient te worden.
Ik begin met het aangeven van het kader waarbinnen ik de vraag wil beantwoorden. Het testen op
zich is niet wezenlijk veranderd wel de plaats die het zou moeten innemen in de huidige
ontwikkeling van software. Niet binnen het project of het programma, maar het is eerder
andersom. Dit is natuurlijk niet logisch; de software ontwikkeling binnen het testen. Hiervoor is
dan ook een andere mind set nodig. Een kwaliteitsspectrum voor het ontwikkelen van software,
kwaliteitsmanagement i.p.v. testmanagement. In dit kader volgt dus vanzelf de omzetting;
software ontwikkeling binnen kwaliteitsmanagement. Hierbij verschuift dus de scope van het
testen van de ontwikkelde software naar het testen van de ontwikkeling van die software, het
uiteindelijke product. Natuurlijk moet ook dit, technisch en functioneel getest zijn, alleen de
start hiervan begint al bij de opdracht door de kwaliteitseis als basis te nemen. Uiteraard zal de
kwaliteitseis een som zijn van de onderliggende kwaliteits requirements, dat spreekt voor zich.
Deze requirements kom je dan weer tegen als eisen door het hele traject en kunnen op elk
willekeurig moment getoetst worden.
Was het vroeger het product en de klant die centraal stonden, tegenwoordig lijkt het om te
slaan naar interfacing met de klant, zeg maar de buitenkant. Nieuwe producten zijn er natuurlijk
wel, de klanten scope kan verschuiven; maar dit is uiteindelijk alleen maar een verschuiving binnen
de bekende verzamelingen. Dit is natuurlijk ook belangrijk om voortbestaan en/of groei te
bewerkstelligen. Dit alles heeft natuurlijk te maken met de technische ontwikkelingen t.a.v.
internet, het gebruik van pc, de mobile telefoon en de tablets. Dit met alle gevolgen van dien,
gelet op de ophef(terecht) die ontstaan is n.a.v. de recente DDOS aanvallen en de zorg
betreffende cyber aanvallen en virussen. Parallel daaraan zijn we momenteel ook bezig om onze
administraties aan te passen n.a.v. Europe(SEPA).Verder zijn de afgelopen jaren outsourcen en
externe partijen die worden ingehuurd een reden tot zorg, zeker gezien de huidige situatie
waarin ook de financiële branche aan het afslanken is qua vast personeel.
Cm2RC - flutschit
Pagina 12/15
Waar moeten we alert op zijn.
De gevaren van het internet in zijn algemeenheid en de verschuiving van de verhouding tussen
eigen personeel en externen, of dit nu via outsourcing of via inhuur van externe medewerkers is.
Hoe valt dit alles te rijmen met de opdracht aan mij? Kort en goed, een veilig Internet en alles
wat daarbij komt is iets voor specialisten die niet per betrokkene moet worden aangepakt. Dit
betreft nl alle gebruikers van het internet, zowel de aanbieders van diensten als wel de
gebruikers daarvan. De bedrijven onderling hebben dezelfde verdeling(Equens biedt een dienst
aan, welke wordt afgenomen door banken maar ook energieleveranciers; Netwerkbeheer leveren
op afstand uitleesbare meters die in huis worden geplaatst). M.a.w. de lead zou moeten liggen bij
de aanbieders en niet de gebruikers. En dan niet in Amsterdam, Nederland of Europa maar
wereldwijd. Hier ligt de uitdaging ;)(ik begrijp dat ik nu misschien iets doorschiet, of niet?).
Dan blijft over de infrastructuur binnen eigen muren. Hier hebben de bedrijven de plicht om een
stabiele omgeving te garanderen en ook waarborging van de klantgegevens.
Natuurlijk dient de software te voldoen aan zijn eigen specificaties, dat is evident. Dus uiteraard
moeten hier dan ook de gebruikelijke functionele- en gebruikerstesten gedaan worden. Verder
bestaat er haast geen software meer die op zichzelf functioneert zonder ergens een interface
naar…
Dus wat is uiteindelijk de belangrijkste test, de Ketentest. En ook hier zeg ik niets nieuws,
echter hiervoor dient, veel meer dan in het verleden, het besef te gaan ontstaan dat dit de
belangrijkste test is waar ook het meeste effort in gestoken dient te worden, en wel op twee
fronten; de testinfrastructuur en een overzicht waar alle informatie vandaan komt, waar deze
allemaal wordt opgeslagen, waar deze allemaal voor gebruikt wordt, te pas en te onpas maar
zeker ook waar welke informatie het bedrijf in- en uitgaat, dus komen we al gauw uit op een
CDM(Canonical Data Model) of bedrijf breed data model. Dit laatste lijkt ook niet nieuw maar
met het ontstaan van de huidige, lange en complexe Ketens, is dit iets wat door de tijdsdruk
en/of onderschatte waarde niet of nauwelijks aanwezig is. Dit is op zich niet zo gek, daar het
onderhouden van een CDM een niet te onderschatten inspanning vergt. Het gebrek hieraan
echter heeft met operaties zoals die nu t.b.v. SEPA zijn en worden uitgevoerd een grote invloed
op m.n. het inrichten van een testinfrastructuur. Nu wordt er vaak besloten dit tijdens de
ontwikkeling, gedeeltelijk, te doen; Trial and error. Dit was vroeger niet zo erg daar de kennis
altijd wel voorhanden was bij de eigen medewerkers, echter in de huidige tijd zijn of worden die
schaars.
Dit was slechts een voorbeeld, maar zeker niet de minste, waar al aan begonnen dient te worden
op het moment dat een project of programma van start gaat en op zijn minst niet kan ontbreken
bij de projectplanning, een kwaliteitseis. Dit geld trouwens voor alle missende of niet up-to-date
documentatie. Natuurlijk als er en algemene achterstand is qua documentatie zal die bijgewerkt
dienen te zijn. Maar, nogmaals, gezien het gebrek aan kennis dat aan het ontstaan is binnen de
branche, één die niet mag uitblijven.
Dit alles heeft dus te maken met kwaliteit. Hiervoor moet dan ook, voordat überhaupt met de
ontwikkeling begonnen kan worden, aan deze eis voldaan zijn. Dit is dan de taak van de nieuwe
Cm2RC - flutschit
Pagina 13/15
tester in het kader van kwaliteitsmanagement waar het testen een onderdeel van is en niet meer
een afsluitend deel van het project.
Kwaliteit en testen zijn onlosmakelijk met elkaar verbonden en is dan ook geen project
aangelegenheid meer, maar project overstijgend. Een projectleider kan niet meer zijn invloed op
de acceptatie uitoefenen maar is uiteindelijk de eindverantwoording van de kwaliteitsmanager of
zijn gedelegeerde binnen het bedrijf.
Uiteraard heb ik hierboven niet even in een paar zinnen gezegd hoe het zou moeten maar wat ik
wel hoop dat dit genoeg discussie zal opleveren dat het testen op een andere manier aangepakt
dient te worden in de huidige tijd waarbij de techniek het mogelijk heeft gemaakt de bestaande
testmethodieken voorbij te vliegen.
Cm2RC - flutschit
Pagina 14/15
Index
Agile ...................................................................... 5
Chainmanagement to reliable Chains.............. 3
Cm2RC .............................................................. 2, 3
Common Sense .................................................... 3
De Octopus .......................................................... 8
deliverable ........................................................... 3
deliverables ......................................................... 7
Feasibility Study ................................................ 7
functioneel ontwerp........................................... 3
het Ketendenken .......................................2, 3, 6
het Ketenmanagement ...................................... 6
Issue Log.............................................................. 8
Ketens ................................................................... 3
kwaliteitseis ...................................................... 13
Cm2RC - flutschit
Lessons Learned Report ................................... 8
Master Test Plan ........................................... 3, 7
methodiek ....................................................... 2, 3
MTP .................................................................. 3, 7
outsourcing .......................................................... 3
PBS ........................................................................ 7
PID ........................................................................ 7
planning ................................................................. 3
Prince2 ............................................................. 3, 7
Product Breakdown Structure ........................ 7
routes ................................................................... 2
testmethode........................................................ 3
Traceability ....................................................... 10
Traceability matrix .......................................... 11
Pagina 15/15
flutsch-it
www.chainmanagement
June 2015