vrijdag 29 mei 2015

PRINCE2 overzicht

Volgens de  methode PRINCE2®
is er sprake van een project als voldaan wordt aan de volgende kenmerken:
  • projecten worden gebruikt om veranderingen door te voeren
  • een project speelt zich af op een onbekend gebied (er is een mate van onzekerheid)
  • een project is tijdelijk, er is sprake van een tijdelijke organisatie
  • een project is uniek (het werk is nog niet eerder gedaan op die plek)
  • een project is multidisciplinair
Het PRINCE2 procesmodel ziet er op hoofdlijnen als volgt uit.
P2PROCESMODEL
Starting Up a project
Deze processtap heeft tot doel te zorgen dat is voldaan aan de randvoorwaarden voor het Initiëren van een Project waarbij de belangrijkste vraag luidt: Is het project zinvol en levensvatbaar?
Belangrijkste activiteiten van deze processtap zijn:
  • benoemen van de Executive (opdrachtgever)
  • benoemen van de Projectmanager
  • benoemen van het (Projectmanagement)team
  • leerpunten verwerken uit het readiness assessment en eerdere vergelijkbare trajecten
  • de projectaanpak bepalen (wat gaan we zelf doen en waarvoor moeten inhuren)
  • de Business Case opstellen
  • de Project Brief opstellen
Het thema Organisatie geeft handvatten voor het inrichting voor de organisatie.  De volgende rollen worden onderkent
  • Executive (lid Projectboard)
  • Senior User (lid Projectboard)
  • Senior Supplier(lid Projectboard)
  • Projectassurance
  • Change-authority
  • Projectmanager
  • Projectsupport
  • Teammanager

Business Case opstellen
De Business Case beschrijft de reden van het project. Waarom doen we dit project. Wat willen we precies bereiken. Welke opties zijn er om ons doel te bereiken. Wat zijn de voordelen, wat zijn de nadelen, wat zijn de baten en wat zijn de kosten. De business case vormt de drive onder het project. Veelal mislukken projecten doordat er geen goede business case onder ligt.
De belangrijkste punten die in de Business Case moeten worden beschreven zijn:
–      Samenvatting voor opdrachtgever
–      Redenen
–      Alternatieven
–      Verwachte benefits
–      Verwachte dis-benefits
–      Tijdschema
–      Kosten
–      Investeringsvoorstel
–      Belangrijkste risico’s
 Project Brief
De Project Brief zou je het beslisdocument kunnen noemen dat naar de projectboard zal worden gestuurd met als doel goedkeuring te krijgen voor het verder vervolgen van het traject. In de Project Brief worden onder andere de volgende zaken beschreven:
–      Projectdefinitie
–      Business Case op hoofdlijnen
–      Project Product Description (samenvatting van het te realiseren resultaat)
–      Projectaanpak
–      Projectmanagementteamstructuur
–      Rolbeschrijvingen
Directing Project
Doel van deze processtap is de Projectboard in staat te stellen eindverantwoordelijk te zijn voor het slagen van het project, d.m.v. het nemen van belangrijke beslissingen en het uitoefenen van beheersing over het geheel terwijl zij het dagelijks management delegeert aan de Projectmanager.
Initiating a Project
Doel van de processtap Initiating a Project is het leggen van een stevige basis voor het project, waardoor de organisatie duidelijkheid krijgt over het werk dat moet worden gedaan om de producten van het project op te leveren voordat aanzienlijke uitgaven worden gedaan.
Deze processtap valt samen met de fase initiëren van het project. In deze fase worden alle belangrijke voorbereidingen getroffen zoals het nauwkeurig plannen van de op te leveren projectresultaten en het plannen van de verschillende fasen die nodig zijn om dit resultaat te realiseren.
Hierin spelen de PRINCE2  principes een belangrijke rol. Dit zijn o.a. Productgerichte Aanpak voor de definitie van het te realiseren projectresultaat en o.a. Managen per Fase om het project in haalbare brokken te verdelen, waarmee geborgd wordt dat de Projectboard via de juiste en gewenste frequentie betrokken wordt voor besluitvorming en autorisatie. Beide principes worden toegepast in het PRINCE2 thema Plan, dit thema geeft richting aan de aanpak om het Projectplan op te stellen. Dit is het overkoepelende plan voor het project.
Het projectplan omvat onder andere de Product Breakdown Structure en de Fasering en vormt hiermee de basis voor de separaat op te stellen Faseplannen welke worden op gesteld in het proces Stage Boundaries.
Het eindresultaat van Initiating a Project is de zogenaamde PID, dit staat voor Project Initiating Documentation. Naast de Business Case is het Projectplan met daarin de PBS en de fasering 1 van de belangrijkste onderdelen van de PID. Deze documentatie is een verdere verfijning en meer gedetailleerde uitwerking van de Project Brief. In de PID worden onder andere de volgende onderdelen beschreven:
–      Projectdefinitie
–      Projectaanpak
–      Projectmanagementteamstructuur en rolbeschrijvingen
–      Kwaliteits-, Configuratie-, Risico- en Communicatiemanagementstrategie
–      Projectplan
–      Business case
–      Projectbeheersing
Deze documentatie geeft dus duidelijkheid over het te realiseren resultaat, de wijze waarop het resultaat gerealiseerd zal worden, de planning hiervan, de kosten, de baten en wordt ter autorisatie naar de Projectboard gestuurd ter goedkeuring van de formele start van het project.

Controlling a Stage
Controlling a Stage heeft tot doel het toewijzen van het werk dat gedaan moet worden, dat bewaken, issues behandelen, voortgang rapporteren aan de Project Board en corrigerende maatregelen nemen om te zorgen dat de fase binnen de tolerantie blijft. Dit proces beschrijft de werkzaamheden van de projectmanager waarbij het in de kern gaat het aansturen van de realisatie van de resultaten door issue’s op te lossen, risico’s te bewaken en het bijsturen op die momenten waarop dat nodig is.
Managing Productdelivery
In dit proces gaat het erom dat de producten van de betreffende fase gerealiseerd worden. De verschillende teams worden door de Teammanager aangestuurd en begeleid in het realiseren van de inhoudelijk resultaten (deel producten).
Stage Boundaries
Het proces Stageboudaries heeft tot doel de Project Board te voorzien van voldoende informatie, zodat het succes van de huidige fase en het geactualiseerde Project Plan kan worden beoordeeld, ze het volgende Stage Plan kan goedkeuren en de voortdurende zakelijke rechtvaardiging en aanvaardbaarheid van risico’s kan bevestigen.
Dit is dus het proces waarbij een faseovergang wordt gepland. In dit proces wordt even een pas op de plaats gemaakt. De voorgaande fase wordt verantwoord en vormt samen met de oorspronkelijke planning in het Projectplan de basis voor het plan waarin de vervolgfase wordt gepland. In PRINCE2 Faseplan genoemd. Hierdoor wordt de Projectboard in de gelegenheid gesteld haar verantwoordelijkheid te nemen door de volgende fase te autoriseren en tevens de resultaten tot nu toe te beoordelen.
Closing a Project
Closing a Project heeft tot doel ervoor te zorgen dat de acceptatie van het projectproduct wordt bevestigd, vaststellen dat doelstellingen zoals vastgelegd in de oorspronkelijke PID zijn gerealiseerd of dat het project niets meer heeft bij te dragen.

Belangrijke activiteiten in dit proces zijn de evaluatie van het traject om zodoende te kunnen leren voor vervolgprojecten. Daarnaast worden de gerealiseerde producten overgedragen aan de lijn. M.a.w. de informatie-architect kan overgaan tot het onderhouden, bewaken en indien nodig bijstellen en documenteren van de informatievoorzieningsarchitectuur. Eigenlijk is het werk van de informatievoorzieningsarchitectuur nooit af. Dit rechtvaardigt het inrichten van een proces, hierbij kan dan projectmanagement worden ingezet bij de meer grootschalige herdefinities bijvoorbeeld wijzigingen in de missie, visie en strategie. Verder kunnen projecten worden geïnitieerd voor het ontwikkelen van onderdelen van de informatievoorzieningsarchtectuur.


  • •  ©Crown copyright material taken from the Cabinet Office publication, Managing Successful Projects with PRINCE2.
  • •  This is a Value Added Product which falls outside the scope of HMSO Class Licence. Reproduced by kind permission of the Cabinet Office
  • •  PRINCE2® is a Registered Trade Mark of the Cabinet Office
  • •  The Swirl logoTM is a Trade Mark of the Cabinet Office
PRINCE2® is a registered trade mark of the Cabinet Office.
The Swirl logo ™ is a trade mark of the Cabinet Office.

PRINCE2 overview

PRINCE2, of beter gezegd de afkorting ´PRINCE´, staat voor ´PRojects IN Controlled Environments´. Het betreft een set van ´best practices´ die heeft geleid tot een generieke, gestructureerde methode voor het voeren van effectief projectmanagement.
Het PRINCE2 raamwerk zorgt voor een beheerste opstart, realisatie en afronding van projecten die een duidelijk businessdoelstelling kennen in een professionele klant-leveranciers context. Net als ITIL is het Britse OGC (Office of Government Commerce) eigenaar - en registrant van het merk PRINCE2. De doorontwikkeling van PRINCE2 is uitbesteed aan The Stationary Office (TSO) en APMG, respectievelijk de voormalige Britse staatsdrukker en een private examenontwikkelaar.
De basis voor het huidige PRINCE2 is gelegd in 1996 nadat was onderzocht wat de faal- en succesfactoren waren binnen het vak projectmanagement. Inmiddels is de PRINCE2 methodiek reeds meerdere keren (2002, 2005 en 2009) geactualiseerd om blijvend aan te sluiten bij de ontwikkelingen in de praktijk.
Wat is het werkgebied van PRINCE2®?
Projectmanagement! Dat is het werkgebied van PRINCE2; en wel het ´succesvol´ uitvoeren van projecten. Hiertoe zijn er binnen de PRINCE2 methode specifieke spelregels opgesteld die tot dit succes moeten leiden. Ofwel het opleveren van datgene wat is afgesproken binnen de daarvoor overeengekomen tijd, geld en kwaliteit en met het resultaat zoals dit aanvankelijk was beoogd.
PRINCE2 biedt dus handvatten voor:
  • Het op een gestructureerde en logische wijze managemen van het project
  • Het hele proces dat gedurende het project doorlopen wordt: van het begin tot het einde
  • Het organiseren van draagvlak en betrokkenheid bij de betrokkenen en de omgeving
De zeven processen van PRINCE2 v2009®
PRINCE2 is een procesgedreven projectmanagement methode. PRINCE2 versie 2009 onderkent 40 afzonderlijke activiteiten binnen een totaal van zeven processen. De volgende processen maken deel uit van PRINCE2:
  1. Starting up a project
  2. Initiating a project
  3. Directing a project
  4. Controlling a stage
  5. Managing stage boundaries
  6. Managing product delivery
  7. Closing a project
Verder onderscheid PRINCE2 zich door het voorschrijven van een aantal ´technieken´, waaronder: Product Based Planning, Change Control Technique en de Quality Review Technique.

PRINCE2 processen

PRINCE2 kent de volgende 7 processen
Starting up a Project  SU
Directing a Project  DP
Initiating a Project  IP
Managing a Stage Boundary  SB
Controlling a Stage  CS
Managing Product Delivery  MP
Closing a Project  CP

PRINCE2 structuur

• principes> de grondslagen waaraan een project moet voldoen
• thema’s > de minimale managementaspecten die beheerst moeten worden
• processen > stapsgewijze beschrijving van de route
• op maat maken > de aanpassing aan het type project en de omgeving

PRINCE2 principes

1.Continued business justification
2.Learn from experience
3.Defined roles and responsibilities
4.Manage by stages
5.Manage by exception
6.Focus on products
7.Tailor to suit the project environment

Definitie PRINCE2

PRINCE2 definieert een project als:
Een tijdelijke organisatie die in het leven is geroepen met als doel de oplevering van één of meer producten op grond van een overeengekomen Business Case

Afkorting PRINCE2

PRINCE2, of beter gezegd de afkorting ´PRINCE´, staat voor ´PRojects IN Controlled Environments´. Het betreft een set van ´best practices´ die heeft geleid tot een generieke, gestructureerde methode voor het voeren van effectief projectmanagement.

Overzicht TMap

Fase: planning
Doel: conform BDTM een testplan opzetten
Als iets niet uit het mastertestplan aanwezig is moet dit alsnog worden gedaan vooral de PRA!
Verder moet alles uit met MTP worden aangescherpt
Uitvoerder: testmanager (werkwijze iteratief) i.s.m. opdrachtgever
Randvoorwaarden (zie blz 156):
  • OG moet beschikbaar zijn
  • Doel en belang moet van systeem voor de organisatie moet bekend zijn
  • Globale eisen en requirements
  • Bij voorkeur masterplan aanwezig
  • Het ontwikkelproces
  • Opleverdatum
  • Inzicht in de omgevingen
  • Bereidheid in de organisatie of info te verschaffen
Activiteiten
Doel
Product
Vaststellen opdracht
Duidelijke TVB, inzicht in opdracht, goede afbakening (wel of geen procedures, conversies, enz)
Opdrachtformulering
Orienteren opdracht
Inzicht in project, doelstelling, opzet, systeemontwikkeling, systeem, FO, specs, enz.
Opdrachtformulering
Bepalen testbasis
Zo vroeg mogelijk eenduidig definieren
Aanpak
PRA
Tot gezamenlijk beeld komen van wat de risicovolle delen van het systeem zijn
PRA
Bepalen teststrategie
Op basis van de hiervoor verzamelde info keuzes maken voor testvormen, testzwaarte voor alle te testen onderdelen, zie voorbeeld blz 176
Teststrategie
Bepalen begroting
Op basis van de strategie een begroting opstellen per testsoort ter voorlegging aan de OG
Begroting
Bepalen planning
Vastleggen uit te voeren act, tijdsbesteding, benodigde resources en op te leveren producten
Planning
Toewijzen testeenh en testtechnieken
Op basis van teststrategie bepalen van testeenheden en testteschnieken zodat de test beheersbaar wordt. Lees blz 190 tm 195
Aanpak
Definieren testproducten
Definieren op te leveren testware, bijv, testplan, testspecs,testinvoerbestanden, test uitvoeringsdossier (zie blz 198)
Aanpak
Definieren organisatie
TVB voor de testmanager, testteamleider, tester, beheerder, toolspecialist
Organisatiestructuur
Definieren infrastructuur
Bepalen benodigde testomgeving, testtools, kantoorinrichting en planning wanneer dit nodig is
Infrastructuur
Inrichten beheer
Vastleggen van de wijze waarop het beheer van het testproces, de infrastruct, de testproducten en bevindingen wordt geregeld
Beheer
Bepalen testproject risico’s en maatregelen
Benoemen van risico’s per testsoort (bijv. ingangskwaliteit, infrastruct voldoet niet, resources niet beschikbaar) en voorgestelde maatregelen
Bedreigingen, risico’s en maatregelen
Terugkoppelen en fixeren plan
Verkrijgen van goedkeuring van de OG
Testplan
PRA toegelicht:
Analyseren van het te testen product met als doel tot een gezamenlijk beeld te komen met de OG (belanghebbenden) van wat de meer en minder risicovolle kenmerken en delen van het product zijn zodat de grondigheid van testen hieraan gerelateerd kan worden.
Essentie is testinspanning relateren en verwachte productrisico’s.
Productrisico = faalkans * schade
Faalkans = foutkans * frequentie van gebruik
Foutkans: complexe functies, nieuwe functies, veelvuldig aangepaste functies, functies die gebouwd zijn met nieuwe tools of technieken, functies die gedurende de ontwikkeling aan anderen zijn overgedragen, functies waarin al eerder veel fouten zijn gevonden, functies met veel interfaces.
Schade: omzet verlies, schade aan derden, economisch verlies, fysieke schade, milieuschade, imagoschade, klantverlies, verlies van vertrouwen, overbelasting helpdesk, enz.
Stappen:
  • Bepalen deelnemers
  • Bepalen aanpak
  • Voorbereiden sessie of interviews
  • Verzamelen en analyseren
  • Volledigheidscontrole
Technieken:
  • Strategiebepaling
  • PRA
  • Kwaliteitsattributen
  • Begrotingstechnieken
  • Stappenplan opstellen begroting
  • Checklist randvoorwaarden en uitgangspunten
  • Checklist orienteren testopdracht
  • Checklist testomgevingen
  • Checklist kantoorinrichting
  • Checklist risico’s testproces
Tools:
  • Testware beheertool
  • Bevindingen beheertool
  • Plannings- en voortgangsbewakingstool
  • Workflowtool
Fase: Beheer
Doel: geven van inzicht en sturingsmogelijkheden aan OG over voortgang, kwaliteit testobject en kwaliteit testproces
Uitvoerder: testmanager rapporteert aan OG
Randvoorwaarden:
Start na opstellen testplan
Activiteiten
Doel
Product
Uitvoeren beheer
Beheren proces, bevindingen en testproducten om voortdurend inzicht te kunnen verschaffen in de voortgang en kwaliteit
Beheerd testproces,
Bewaken
Bewaking t.a.v. duivelsvierkant tegen scopecreep
Kosten batenanalyse
Rapporteren
Opstellen van (BDTM) rapportages om inzicht te verschaffen zodat sturing door OG mogelijk is. Voorbeeld op blz  242
Rapportages (voortgang, risico’s vrijgave, enz), bijgesteld plan
Bijsturen
Indien nodig na overleg OG bijsturen van het testproces
Voorgesteld sturingsmaatregelen, sturingsmaatregelen
Technieken:
  • metricslijst
  • checklist evaluatie
Tools:
  • Testwarebeheertool
  • Bevindingenbeheertool
  • Plannings en voortgangsbewakingstool
  • Workflowtool
Fase: Inrichten beheer en infrastuur
Doel: beschrijven, realiseren en beheren van de testinfrastructuur tbv de verschillende fasen
Uitvoerder: testmanager of test-infrastructuur-coordinator
Randvoorwaarden:
Beschrijving van de infrastructuur op overkoepelend niveau moet bekend zijn
Activiteiten
Doel
Product
Specificeren infrastructuur
Denk aan backup, benodigde interfaces, autorisaties, kunnen wijzigen van systeemdatum, enz, maar ook beheerafspraken.
Detailspecs werkplek, Detailspecs testomgeving, PVA testtools,Werkplekken, testomving, geinstalleerde testtools, ckl intake werkplek ckl intake testomg, ckl intake testtools, procedureintake, testbevindingen, bruikbare werkplek, bruikbare testomg.,bruikbaretesttools, intakeverslag, beheerde infrastruct., Bevindingen testinfrastruct. Geconserveerde testinfrastructuur
Realiseren infrastructuur
Realiseren infrastructuur
Specificeren intake infrastructuur
Opstellen diverse ckl’s
Intake testinfrastructuur
Uitvoeren van de intake van de operationele infra, werkplek, enz.
Beheren infrastructuur
Beschikbaarheid op een bepaald niveau garanderen
Conserveren infrastructuur
Identificeren, actualiseren en overdragen zodat het in de toekomst hergebruikt kan worden.
Technieken:
n.v.t.
Tools:
  • Testwarebeheertool
  • Bevindingen beheertool
Fase: Voorbereiding
Doel: beschikken over een met de OG overeengekomen testbasis van voldoende kwaliteit voor het ontwerpen van testgevallen (inzicht in de testbaarheid van het systeem).
Besparing vroege foutdetectie = 50 tot 80 % besparing
Opmerking bijvoorbeeld bijsturen van plannen hoort altijd bij de fase beheer! Dus niet in de fase waar het ontdekt wordt!
Uitvoerder: testmanager of testcoordinator
Randvoorwaarden:
Zo snel mogelijk starten na fixatie van het testplan en n het beschikbaar zijn van de gefixeerde testbasis
Activiteiten
Doel
Product
Verzamelen testbasis
Verzamelen van definitieve (geactualiseerde) testbasis.Alternatieve testbasis kan zijn: huidig syst als referentiesysteem, prototype als testbasis, infosessie, systeemdocumentatie uit voorlaatste iteratie (zie ook blz. 281, 282)
Gefixeerde testbasis
Opstellen checklists
Opstellen CKL adhv testplan en teststrategie
Diverse checklists
Beoordelen testbasis
Vaststellen van de testbaarheid, dwz volledigheid, consitentie, toegankelijkheid, vertaalbaarheid van testgevallen van de testbasis.
Testbasis bevindingen
Opstellen rapport detailintake
Terugkoppeling over kwaliteit testbasis, stelt zwakke plekken in het systeemontwerp ter discussie en informeert op projectrisico’s
Rapport detailintake
Technieken:
  • HICCUPP
  • 18 attacks van Whittaker
  • 480 bugs van Kaner
  • CKL beoordelen testbasis
  • CKL testontwerptechnieken
  • Toetstechnieken
Tools:
  • Bevindingenbeheertool
Fase: Specificatie
Doel: het specificeren van de tests en uitgangssituatie zodat tijden de uitvoering alles zo vlot mogelijk kan verlopen
Uitvoerder: testers
Randvoorwaarden:
Testbasis is beschikbaar en staat onder configuratiebeheer
Bevindingen uit de detailtestintake testbasis zijn verwerkt.
Activiteiten
Doel
Product
Opstellen testspecificaties
  • identificeren testsituaties
  • opstellen logische testgevallen
  • opstellen fysieke testgevallen
  • vaststellen uitgangssituatie
  • opstellen testscript
Per testeenheid opstellen van testspecificaties met gebruikmaking van testontwerptechnieken gericht op het bereiken van de gewenste dekking en testzwaarte.Zie blz. 295 voor generieke inhoudsopgave testscript.
Bevindingen op de testbasis, testspecificaties (CKL, testgevallen, testscripts), testbasisbevindingen, testscript pre-test
Definieren centrale uitgangssituaties (bijv. kopie prod.omg)
Opstellen van 1 of meer uitgangssituaties waar testers gegevens voor hun testspecs kunnen uithalen  zoals de vulling van stambestanden zoals kortings tabellen, klanten, producten. (denk daarnaast ook aan systeemtoestand (bijv. bepaalde systeemdatum, of batches die gedraaid moeten hebben)
Beschrijving centrale uitgangsituatie
Specificeren intake testobject
Opstellen CKL intake testobject tbv de betreffende versie van het testobject en opstellen testscript pre-test (vaststellen of het of het object wel goed genoeg is om te testen, voorbeeld MDL test) Controle of alle functies aanwezig zijn, representatieve functies met een eenvoudig geval testen en enkele op integratie gerichte testgevallen.
CKL intake testobject,
Nb. Testgeval = initiele situatie > actie > resultaatvoorspelling
Nb. Actie = input > processing > output
Dekking = dekkingsvorm en dekkingsgraad
Dekkingsvorm = welke mogelijkheden worden onderscheiden
Dekkingsgraad = hoeveel van die mogelijkheden wordt er getest
Opbouwen van testgegevens: (bestudeer blz 302 t/m 303 voor voor- en nadelen)
  • Opbouwen met reguliere systeemfuncties (voorkeur)
  • Opbouwen met aparte laadprogrammatuur
  • Gebruik van productiegegevens
Ook mogelijk om deze 3 te combineren.
Gebruik van uitgangssituaties gedurende de test: (bestudeer 305 t/m 306 voor- en nadelen)
  • Cumulatief opbouwen van de centrale uitgangssituatie
  • Periodiek verversen met de centrale uitgangssituatie.
  • Parallel gebruiken van meerdere versies
Technieken:
  • Testontwerptechnieken
  • CKL diverse kwaliteitsattributen
Tools:
  • Testwarebeheertool
  • Bevindingenbeheertool
  • Testdatatool
  • Testontwerptool
  • Model based testing tool
  • Geautomatiseerde testuitvoering tool
  • Performance-,  load- en stresstesttool
Fase: Uitvoering
Doel: het verkrijgen van inzicht in de kwaliteit van het testobject dmv het uitvoeren van tests
Uitvoerder: alle teamleden, alleen de controle op volledigheid van het testobject gebeurd door de testmanager.
Randvoorwaarden:
  • Testobject moet opgeleverd zijn
  • Testscripts hiervoor moeten beschikbaar zijn
  • Intake testinfrastructuur moet succesvol zijn
Activiteiten
Doel
Product
Intake testobject
Vaststellen of zinvol getest kan worden
Geinstalleerd en testbaar testobject
Klaar zetten uitgangs situatie
Alles klaar zetten voor de uitvoering.
Centrale uitgangssituatie, initiele situatie
Uitvoeren (her)tests
Uitvoeren dynamisch expliciete en impliciete tests, Uitvoeren statische tests. (lezen 318, 319 en 320)
Bevindingen, testresultaten
Controleren en beoordelen testresultaten
Vaststellen van de overeenkomsten en het analyseren van de verschillen tussen de verkregen resultaten en de voorspelde resultaten. (vergelijken, analyseren (zie blz 323) en bepalen hertests). Rapporteren volgens H12 rapporteren bevindingen in de fase beheer.
Loggen van testresultaten,
Technieken:
  • Exploratory testing
  • Error guessing
Tools:
  • Testwarebeheertool
  • Bevindingenbeheertool
  • Testdatatool
  • Monitor tool
  • Comparator
  • Simulator
  • Performance
  • Driver en stubs
  • Enz. zie boek
Fase: Afronding
Doel: leren van de ervaringen en het conserveren van de testware voor een volgende test
Uitvoerder: alle teamleden
Randvoorwaarden:
De testuitvoering is in een afrondend stadium
Activiteiten
Doel
Product
Evalueren testproces
Leren van ervaringen (doe dit niet alleen op het eind maar regelmatig vanaf het begin van het project)
Evaluatie testproces
Conserveren testware
Selecteren en actualiseren van de vervaardigde testware
Paklijst testware, herbruikbare testware
   
NB. In de fase beheer wordt door de testmanager een eindrapport opgesteld
Technieken:
  • CKL evaluatie testproces
Tools:
  • Testwarebeheertool
  • Bevindingen beheertool
Hoe dan ook H14 supergoed bestuderen!!!!!
Testontwerptechniek = gestandaardiseerde werkwijze om vanuit de testbasis testgevallen af te leiden die tot een bepaalde dekking leiden.
Op basis van:
-          opdrachtformulering
-          risicoanalyse
-          teststrategie
Vertalen naar juiste dekking dmv testontwerptechniek in testgevallen.
Zie blz 592, figuur testontwerptechnieken
Belang van testontwerp
Technieken:
  • onderboude invulling van de teststrategie
  • leidt tot efficiente  en per geval tot gerichte opsporing van fouten
  • tests zijn reproduceerbaar
  • gestandaardiseerde werkwijze maakt de uitvoering onafhankelijk van de opsteller
  • overdraagbaarheid en onderhoudbaarheid van de testgevallen
  • testproces is beter planbaar en beheersbaar
Testsituatie >< logisch testgeval/fysiek testgeval > testscript
Testgeval =  fig blz 596
Testsituatie = bestelling van een of meer  boeken
Logisch testgeval =
  • bestelling van precies 1 boek
  • bestelling van meer dan 1 boek
  • orderbedrag boven drempelwaarde
  • orderbedrag onder drempelwaarde
Fysiek testgeval=
  • Drempelbedrag  = 50
  • Korting = 10%
  • Prijs boek 1 = 25
  • Prijs boek 2 = 19
  • Prijs boek 3 = 61
  • TG1 = Actie: bestel boek 1 en boek 2
    • Resultaatvoorspelling is …….
  • TG2 = Actie= bestel boek 3
    • Resultaatvoorspelling is……
Testscript: meerder soortgevallen van practisch oogpunt samenvoegen omdat:
  • ze gebruiken dezelfde initiele situatie
  • ze vereisen dezelfde tijdrovende voorbereiding
  • ze gaan over dezelfde situatie (klanten buitenland)
  • er is een afhankelijkheid in tijdsvolgorde
Dekking is
  • dekkingsvorm: welke mogelijkheden worden onderscheiden (paden, beslispunten, CRUD, grenswaarden, enz)
  • dekkingsgraad: hoeveel van die mogelijkheden wordt er getest en hoe zwaar worden ze toegepast
Mogelijkheden:
  • een zwaardere dekkingsvorm
  • meerdere dekkingsvormen
  • hogere dekkinggraad van een bepaalde vorm
Dekkingsvormen:
  • paden = dekken van de variaties in het procesverloop, vereiste testbasis is processchema, verzwaren via testmaat-N, zie 610
  • beslispunten = dekken van de verschillende mogelijkheden van een beslispunt, testbasis is formele beschrijving beslispunt, verzwaren condition/deccision, modified en multiple condition, zie 615
  • Equivalentieklassen = waardebereik opdelen in klassen waarbij systeem ander gedrag vertoond, zie 624
  • Pairwise testing = combineren van alle mogelijkheden van iedere set van 2 parameters, zie 625
  • Grenswaardenanalyse = testen van de grenswaarde, de waarde eronder en de waarde erboven, verzwaren door meerdere waarden rond de grens te testen, zie 636
  • CRUD = dekken van de basis bewerkingen op alle entiteiten, zie 638
  • Statisch gebruik = simuleren realistisch gebruik, zie 641
  • Goedpaden, foutpaden = dekken van goedpad en foutpad bij iedere gedefinieerde foutsituatie, zie 646
  • Afvinklijst = ieder element testen via in ieder geval 1 testgeval, zie 648
Ontwerptechniek: BTT
Bevindingenbeheer:
Bevinding is geconstateerd verschil tussen de verwachting/voorspelling en de feitelijke uitkomst.
Let wel: fout heeft een negatieve klank. Testers moeten zich realiseren dat ze andermans werk beoordelen dat het resultaat is van samenwerking tussen alle partijen.
Testmanager communiceert de bevindingen buiten het testteam.
Stappen van een bevinding doen:
  • Verzamel bewijsmateriaal (memorydump, screenprint)
  • Reproduceer de bevinding
  • Controleer op eigen fouten (let op fouten in de testspecificatie, uitgangssituatie, testomgeving, testuitvoering of beoordeling)
  • Bepaal vermoedelijke externe oorzaak (bijv. testbasis, testobject, documentatie)
  • Isoleer zo mogelijk de oorzaak
  • Generaliseer de bevinding (kijk of op soortgelijke plekken zich dezelfde fout voordoet)
  • Vergelijk met andere bevindingen (kijk of de bevinding al bestaat in bijv. eerdere release)
  • Schrijf bevindingenrapport (stijl neutraal, helder, eenduidig, to the point, inclusief de gevolgen)
  • Laat reviewen ( op volledigheid, juistheid en toonzetting)
Bevindingenrapport (bij voorkeur in velden). Zie blz. 572 e.v. voor de minimale velden.
Zie blz. 579 voor de levenscyclus van een bevinding.

BiSL overzicht

Business Information Services Library, voorheen Business Information Service Management Library, is een raamwerk voor het uitvoeren van functioneel beheer en informatiemanagement.
BiSL is een standaard in het publieke domein sinds 2005, die wordt beheerd door de ASL BiSL Foundation, voorheen ASL Foundation. Anders dan frameworks als ASL en ITIL richt BiSL zich niet op ICT-organisaties (supply), maar juist op de gebruikersorganisatie (demand). In dit framework staat beschreven, hoe een gebruikersorganisatie ervoor kan zorgen dat informatievoorziening adequaat werkt, hoe men behoeften in het bedrijfsproces vertaalt naar ICT-oplossingen en niet-ICT-oplossingen, hoe men de informatievoorziening en ICT-dienstverlening vanuit een gebruiksoptiek stuurt en hoe men de informatievoorziening op lange termijn vormgeeft. Het is derhalve voor alle organisaties bestemd.
Het BiSL raamwerk omvat 23 taken op richtinggevend, sturend en uitvoerend niveau en wordt ondersteund door een aantal best practices, waarmee men invulling kan geven aan functioneel beheer en informatiemanagement binnen een organisatie. Het raamwerk wordt al door diverse grote Nederlandse organisaties gebruikt en toegepast en sluit aan op de procesframeworks ASL en ITIL.
Bron: wikipedia

Procesclusters BiSL

Strategisch / Richtinggevend niveau
  • Opstellen IV-organisatiestrategie (organisatie)
    • Relatiemanagement gebruikersorganisatie
    • Strategie inrichting IV-functie
    • Leveranciersmanagement
    • Ketenpartnersmanagement
  • Verbindende processen (richtinggevend niveau)
    • Informatiecoördinatie
  • Opstellen informatiestrategie (vormgeving)
    • Informatie lifecyclemanagement
    • Informatie portfoliomanagement
    • Bepalen keten-ontwikkelingen
    • Bepalen technologieontwikkelingen
    • Bepalen bedrijfsprocesontwikkelingen
Sturend niveau
  • Sturende processen (management)
    • Planning en control
    • Financieel management
    • Behoeftemanagement
    • Contractmanagement
Uitvoerend niveau
  • Gebruiksbeheer (organisatie)
    • Gebruikersondersteuning
    • Operationele IT-aansturing
    • Beheer bedrijfsinformatie
  • Verbindende processen (uitvoerend niveau)
    • Wijzigingenbeheer
    • Transitie
  • Functionaliteitenbeheer (vormgeving)
    • Specificeren
    • Vormgeven niet-geautomatieerde IV
    • Voorbereiden transitie
    • Toetsen en testen
Bron: Wikipedia

Gebruiksbeheer

Het cluster gebruiksbeheer beschrijft de processen van het BISL model die er voor zorgen dat er een continue en optimale ondersteuning plaatsvindt bij het dagelijks gebruik van de informatievoorziening door eindgebruikers.
De 3 belangrijke onderwerpen voor het gebruik van de informatievoorziening:
  • gebruikers;
  • IT-middelen zoals infrastructuur en geautomatiseerde informatiesystemen/applicaties;
  • Inhoud van het informatiesysteem;
Binnen gebruiksbeheer leiden bovenstaande onderwerpen tot 3 te onderscheiden processen:
  • gebruikersondersteuning
  • beheer bedrijfsinformatie
  • operationele ICT-aansturing
4.1. GEBRUIKERSONDERSTEUNING
Doel:
richt zich op het gebruik van en het functioneren van de informatievoorziening in de dagelijkse praktijk. Concreet: inrichten van aanspreekpunt voor gebruikers en communicatie met gebruikers.
Onderwerpen:
- communicatie van gebruikers naar functioneel beheer (call-beheer; het helpdeskproces)
- pro-actieve communicatie met gebruikers (opleidingen, instructies, nieuwsbrief etc)
Activiteiten:
- call registratie en afhandeling
- gebruikerscommunicatie (pro-actief)
- call-rapportage (opstellen van rapporten over call-afhandeling)
- Twee datastores: gebruikersdata (autorisaties, functieomschr) en Call registratie (alle calls)
Resultaten:
- afgehandelde calls
- communicatie met gebruikersorganisatie (org. geïnformeerd over aanstaande wijzigingen)
- rapportage ten behoeve van sturende processen (uitvoering en resultaten proces, inzicht in gemelde calls)
Relaties:
- ICT-leverancier; technisch beheer geleverd door ICT leverancier
- Overige beheerprocessen binnen BISL (beheer bedrijfsinf. en operationele ICT aansturing)
- Wijzigingenbeheer; call/incident kan aanleiding zijn voor een wijziging
- Sturende processen; contracten/afspraken (contractmanagement), knelpunten oplossen in inf.voorz. (behoeftemanagement), voortgang en inzet (planning en control) en budgetten bestedingen (financieel management)
4.2. BEHEER BEDRIJFSINFORMATIE
Doel:
Verantwoordelijk voor een correcte opzet en inhoud van de gegevens in de informatie-voorziening. Operationele, logische informatie binnen de informatievoorziening.
Onderwerpen:
Bedrijfsinformatie (geautomatiseerd en niet geautomatiseerd)
bedrijfsgegevens van belang voor procesuitvoering
stuurgegevens (paramaters zoals btw-percentages)
Informatiemodel; beheer v/d gebruikte structuur waarin gegevens passen
Activiteiten:
bewaken/controleren (gegevens- integriteit en correctheid)
informeren en rapporteren (managementinformatie)
wijzigen van (stuur)gegevens nav vragen/verandering/wijzigingen/knelpunten. Tevens controle op correcte doorvoering.
Drie datastores:
  • informatievoorziening (inhoudelijke gegevens)
  • systeemparameters (gegevensdefinitie)
  • bedrijfsinformatiemodel
Resultaten:
Informatiemodel; volledig, actueel en bruikbaar geeft inzicht in relevante gegevens.
Gegevens; inhoudelijk juist, aangepaste stuurgegevens, parameters.
Informatieverstrekkingen; ad-hoc en periodieke gegevensverstrekking
Relaties (belangrijkste):
Gebruikersondersteuning; uit calls verzoeken om overzichten, wijzigen van systeemparameters of bedrijfsgegevens.
Transitie; initieert wijzigingen in de bedrijfsgegevens. Aanpassingen in inhoudelijke gegevens of systeemparameters.
Wijzigingsbeheer; controle van gegevens kan leiden tot wijzigingen
Operationele ICT aansturing; geautomatiseerde vragen vanuit Beheer bedrijfsinformatie verloopt via proces operationele ICT aansturing
Behoeftemanagement; aandachtspunten uit B.B.I. kunnen input vormen voor kwaliteits-maatregelen ter verbetering van de I.V. Ook zijn gegevens input voor Audits, controles en Management info.
4.3. OPERATIONELE ICT-AANSTURING
Richt zich op het geven van opdrachten aan de ICT-dienstverlener en op de bewaking van de werking van de ICT en van de ICT-dienstverlener.
Onderwerpen:
de producten; die externe of interne leveranciers leveren
de opdrachten; die naar de externe of interne leveranciers gaan
de diensten; die met de leveranciers zijn afgesproken
Aspecten van de sturing:
capaciteitsbeheer; noodzakelijke capaciteit in kaart brengen; optimale inzet IT-middelen
beschikbaarheidsbeheer; huidige en toekomstige beschikbaarheid. Ook autorisatiebeheer
continuïteitsbeheer; maatregelen om te kunnen blijven functioneren (vb. fraude, sabotage)
Activiteiten:
Verstrekking; operationele opdrachten aan ICT leveranciers. Bijv. bestellen pc
Planning; informatie leveren/beoordelen t.a.v. beschikbaarheid, continuïteit etc.
Bewaking; bewaken en controleren of de door ICT leverancier geleverde dienstverlening is uitgevoerd conform afspraken.
Resultaten:
Opdrachten; uitvoeringsopdrachten voor ICT leverancier en inzicht in status opdrachten
Behoefteplanning; inzicht op gebied van beschikbaarheid, continuïteit en inzicht in de resultaten en uitvoering van de ICT dienstverlening
Relaties:
Contractmanagement; levert kaders/richtlijnen en afspraken die als input gelden.
- ICT-Leverancier; partij waaraan vragen worden gesteld en opdrachten worden verstrekt
- Gebruikersondersteuning; stuurt calls/incidenten door adhv waarvan ICT wordt
aangestuurd.
- Beheer bedrijfsinformatie; kan geautomatiseerde verzoeken indien voor verkrijgen info.