Product Risico Analyse Harry Storimans

Introductie Wie ben ik: Harry Storimans Functie: Testconsultant IT-Zamna E-Mail: h.storimans@caiway.nl Web: www.IT-Zamna.com Mobiel IT-Zamna: 06-43498737 Mobiel H. Storimans: 06-29573633

Definitie PRA volgens Tmap-Next Analyseren van het te testen product met als doel dat TM en de verschillende andere belanghebbenden tot een gezamenlijk beeld komen van wat de meer of minder risicovolle kenmerken en delen van het te testen product zijn, zodat de grondigheid van testen hieraan gerelateerd kan worden. Focus: productrisico’s, ofwel wat is het risico voor de organisatie wanneer het product niet de verwachte kwaliteit heeft. 3

Definitie productrisico Een productrisico is de kans dat het product faalt in relatie tot de verwachte schade wanneer dit optreedt Productrisico = Faalkans * schade Waarbij Faalkans = Foutkans * frequentie van gebruik. 4

Doel van de PRA Het in kaart brengen van de productrisico’s met als uiteindelijk doel een onderbouwd advies kunnen geven over de uiteindelijke dekking van de requirements geldend voor het op te leveren informatiesysteem Alles testen is praktisch onmogelijk Rangorde aanbrengen bij het testen (prioriteren) Rangorde bepalen voor de risico’s Wat doet het meest pijn als het misgaat Hoe groot is de kans dat het mis gaat Risico’s hebben relatie met Requirements (wat moet het systeem kunnen/zijn) Acceptatiecriteria (wanneer is het goed) Er belangrijk voor de Business (requirements, eisen/wensen) 5

PRA: Afzonderlijke factoren van een risico Om de analyse goed uit te kunnen voeren, worden daarom de afzonderlijke factoren van een risico beschouwd Frequentie van gebruik Foutkans (overzicht van plaatsen waar de fouten zich vaak concentreren Complexe functies Totaal nieuwe functies Veelvuldig aangepaste functies Functies met veel interfaces Functies die onder hoge tijdsdruk zijn gemaakt Functies waarin al eerder veel fouten zijn gevonden Onervaren ontwikkelaars Onvoldoende betrokkenheid van gebruikers Onvoldoende kwaliteitszorg tijdens de ontwikkeling Onvoldoende kwaliteit ontwikkeltest Nieuwe ontwikkel tools 6

PRA: Factoren van een risico Schade: Directe schade: omzet verlies, schade aan derden, economisch verlies, kosten voor correctie en herstel Indirecte schade: imagoverlies, verlies van klanten, schadeclaims van derden, overbelasting helpdesk 7

Subactivieiten PRA Bepalen deelnemers Bepalen van de PRA-aanpak Voorbereiden sessie / interviews Verzamelen en analyseren productrisico’s Volledigheidscontrole 8

Bepalen deelnemers Afnemende partijen(Afnemers): Leveranciers Opdrachtgever, (kern)gebruikers, stuurgroepleden, projectmanager, beheerders Leveranciers Architecten, requirementmanagers, ontwikkelaars, ontwerpers, projectmanager 9

Testmanager actie Inschatting hoeveel en welke partijen en personen nodig zijn om een voldoende betrouwbare PRA te kunnen uitvoeren. Rekening houdend met: Wat is de testopdracht (PRA voor een MTP, of een (aanvullende) PRA voor een testsoort (ST, FAT, GAT) Onderstaande dia geeft activiteiten weer 1010

Procedure PRA-Activiteiten Wie Stap Wat Waarmee: I:Input O:Output Testmanager 1 Identificeren stakeholders I:Business case, PID vooronderzoek, checklist productrisicos O: overzicht stakeholders 2 Vooronderzoek productrisico’s, requirements en acceptatiecriteria I: user/business requirements, business case, risk log O: overzicht productrisico’s 3 Bepalen aanpak vervolg I: product risico’s, overzicht stakeholders, checklist product risico’s O: aanpak tbv opstellen productrisico’s TM, Stakeholders, Externe moderator 4 Aanvullen/matchen productrisico’s, requirements, acceptatiecriteria I: procedure productrisico’s, inventarisatie, overzicht stakeholders, Criteria (MoSCoW) TM, Stakeholders 5 Prioriteren productrisico’s, requirements en acceptatiecriteria I: productrisico’s, requirements O: overzicht koppeling productrisico’s TM 6 Opstellen rapport PRA I: overzicht productrisico’s, overzicht koppelingen O: Rapport PRA 11

Bepalen van de PRA-aanpak Testmanager bepaalt op welke wijze de PRA gaat plaatsvinden Op welke wijze wordt de PRA georganiseerd, in sessies of interviews Welke risico-classificatie wordt gebruikt. Organiseren PRA: TM organiseert bij voorkeur een, maar zo nodig meerdere sessies met alle deelnemers TM doet individuele interviews met de deelnemers in plaats van sessies Diverse middenwegen tussen mogelijkheid 1 en 2 Duur van een sessie maximaal halve dag Duur van een interview maximaal 2 uur Voor interviews is op www.tmap.net een checklist van een interview-agenda PRA-Interview opgenomen. 12

Bepalen classificatiewijze risico’s Bepalen of iets een hoog of laag risico vormt Absolute classificatie: afzonderlijk gewaardeerd Relatieve classificatie: ten opzichte van elkaar gewaardeerd In de onderstaande sheets worden beide manieren uitgelegd 13

Absolute classificatie Kans op falen Hoog Midden Laag Schade bij falen A B C c 14

Bepalen classificatiewijze risico’s Relatieve classificatie: Worden de verschillende risico’s ten opzichte van elkaar in een volgorde van belangrijkheid geplaatst. Met een aantal belanghebbenden worden de onderkende risico’s geanalyseerd. Vervolgens wordt vastgesteld waar het risico ten opzichte van de overige geplaatst moet worden. Voorbeeld: Voor systeem X onderkennen we de volgende risico’s De performance van de nachtbatch is te laag waardoor de medewerkers ’ s ochtends geen toegang hebben tot het systeem De factuur die naar de klant wordt gestuurd, bevat onjuiste bedragen De lijst met controletotalen ten behoeve van de interne accountantsdienst bevat onjuiste gegevens. De belanghebbenden analyseren in een bijeenkomst de verschillende risico’s en komen tot de volgorde: 2,1,3. zij zien risico 2 als het belangrijkste risico. 15

Voorbereiden sessie/interviews Evt organiseren van een kick-off Korte toelichting pra, teststrategie, visie op testen, komende testproces Vrijheid tot vragen stellen. Voorbereiding deelnemers gevraagd op evt sessie/interview(ivm risico’s kunnen aangeven) Deelnemers een uitnodiging sturen voor sessie/interview Vermijd vakjargon = duidelijke taal spreken Systeemdocumentatie, processen kunnen dienen als input 16

Indirecte input PRA Opdrachtformulering Projectvoorstel en business case Business requirements: vaak gebruikt voor uitvoeren PRA Projectrisicoanalyse Business-risico’s Directe input PRA: Testbasis Bedrijfs-en beheerprocessen 17

Verzamelen/analyseren productrisico’s TM uiteindelijke doel PRA niet uit het oog verliezen: Wat allemaal getest moet worden(deelobjecten) Waar naar gekeken moet worden(kenmerken) Hoe zwaar getest moet worden(risicoklassen) 18

Deelactiviteiten Bepalen testdoelen Vaststellen relevante kenmerken per testdoel Onderscheiden deelobjecten per kenmerk Per kenmerk invullen van de risicotabel voor testdoelen en deelobjecten, substappen Schade per testdoel Faalkans per deelobject Risicoklasse per testdoel/deelobject Bepalen risicoklasse per deel object Samenvoegen kenmerken/deelobjecten/risicoklassen in totaaloverzicht. 19

Bepalen testdoelen Definitie: een testdoel is een voor de opdrachtgever relevant doel voor het testen, vaak geformuleerd in termen van door IT ondersteunende bedrijfsprocessen, gerealiseerde user requirements of use cases, kritische succesfactoren, wijzigingsvoorstellen of benoemde ( af te dekken ) risico’s Testdoelen van opdrachtgever en andere acceptanten verzamelen en vastleggen (zie voorbeeld v0lgende dia) 20

Bepalen testdoelen Soort testdoel voorbeelden 21 Bedrijfsprocessen Facturering en orders blijven correct werken met ondersteuning vh nieuwe systeem Deelsystemen Correct werkend systeem klantbeheer, orders, toevoegen klant, wijzigen klant Productrisico’s Klant krijgt incorrecte factuur Gebruikers kunnen niet met systeem omgaan Acceptatiecriteria Koppelingen werken goed User requirements Vaststellen kredietwaardigheid aanvrager gebeurt door BKR-toetsing Use cases Opvoeren nieuwe klant, open rekening Kritische succes factoren Online hypotheek moet binnen 1 minuut verschijnen op scherm kwaliteitsattributen Functionaliteit, performance, gebruikersvriendelijkheid, inpasbaarheid. TM moet vermijden dat er teveel testdoelen benoemd worden. Vuistregel: tussen de 3 en 20 21

Vaststellen relevante kenmerken per testdoel Per testdoel bepalen wat voor testen relevante kenmerken zijn Waar moet het testteam allemaal naar kijken om later de testdoelen te kunnen halen Gebruik maken van kwaliteitsattributen(testvormen mogen ook) Installeerbaarheid, multi user, regressie Meest voorkomende kenmerk: functionaliteit Zie onderstaande tabel 22

Tabel Soort testdoel Voorbeelden Kwaliteitsattributen 23 Bedrijfsprocessen Facturering en orders blijven correct werken met ondersteuning vh nieuwe systeem Functionaliteit, gebruikersvriendelijkheid, performance Deelsystemen Correct werkend systeem klantbeheer, orders, toevoegen klant, wijzigen klant Productrisico’s Klant krijgt incorrecte factuur Gebruikers kunnen niet met systeem omgaan Functionaliteit Gebruikersvriendelijkheid Acceptatiecriteria Koppelingen werken goed Functionaliteit, performance, beveiliging User requirements Vaststellen kredietwaardigheid aanvrager gebeurt door BKR-toetsing Use cases Opvoeren nieuwe klant, open rekening Kritische succes factoren Online hypotheek moet binnen 1 minuut verschijnen op scherm performance kwaliteitsattributen Functionaliteit, performance, gebruikersvriendelijkheid, inpasbaarheid. 1-op-1 23

Onderscheiden deelobjecten per kenmerk Kenmerken worden verzameld Voor elk kenmerk delen de deelnemers het testobject nu op in een aantal deelobjecten Deelobject: is een vanuit het te testen kenmerk bezien, logisch samenhangend deel van het testobject. 2 deelsystemen Kenmerk Deelobjecten(systeem) Functionaliteit Deelsys1 Deelsys2 Totale systeem Performance Batch Online Beide deelsystemen kunnen afzonderlijk getest worden, daarnaast is altijd nog een integrale test nodig op het totale systeem. 24

Per kenmerk invullen van de risicotabel voor testdoel en deelobjecten Per kenmerk worden de testdoelen uitgezet tegen de deelobjecten (functionele deelsystemen, performance online/batch,…) en bepalen de deelnemers de risicoclassificatie. Dit geschiedt middels substappen Schade per testdoel Faalkans per deelobject Risicoklasse per testdoel/deelobject Bepalen risicoklasse per deelobject Samenvoegen kenmerken/deelobjecten/risicoklasse in totaaloverzicht. 25

Absolute classificatie Kans op falen Hoog Midden Laag Schade bij falen A B C laag c 26

Schade per testdoel Schatting deelnemers per testdoel voor wat de schade betreft wanneer testdoel onvoldoende is Gebruikersinbreng voor nodig Zie onderstaand voorbeeld( bedrijfsprocessen) Kenmerk: Functionaliteit Testdoelen Schade Bedrijfsproces 1 H Bedrijfsproces 2 Bedrijfsproces 3 L 27

Faalkans per deelobject Inschatting van de faalkans voor elk deelobject maken Inbreng nodig van techniek en ontwikkelproces Functionaliteit Deelsys 1 Deelsys 2 Deelst 3 Faalkans H M L 28

Risicoklasse per testdoel/deelobject De risicoklasse wordt afgeleid uit de schade per testdoel en de faalkans per deelobject Is de combinatie relevant? Kenmerk: Functionaliteit Deelobjecten Deelsys1 Deelsys 2 Totale sys faalkans H M L Testdoelen Schade Proce s1 A -,* - Proces 2 A, ** C Proces 3 *: combinatie niet relevant is voor testen **: er is iets speciaals te melden (klein onderdeel van het deelsysteem is, afwijkend risico aan verbonden is. 29

Bepalen risicoklasse per deelobject Benodigde eind resultaat: dat in de risicotabel vastgelegd moet worden, is een risicoklasse per deelobject (van een kenmerk/kwaliteitsattribuut) Op basis hiervan kan in de teststrategie de keuze gemaakt worden de combinatie kenmerk/deelobject licht, gemiddeld of zwaar te testen. 30

Samenvoegen kenmerken/deelobjecten/risicoklassen PRA-totaaloverzicht opstellen Geen inbreng meer nodig van derden De volgende tabel is een voorbeeld van een totaaloverzicht. Kenmerk Risicoklasse Argumentatie Functionaliteit -deelsys 1 A Hoge faalkans, wordt in cruciale processen 1 en 2 gebruikt -deelsys 2 B Gemiddelde faalkans, slechts beperkt gebruikt in crucialeproces 2 -totaal C als gebruikersvriendelijkheid deelst 1 en 2 goed werken, is de kans op integratiefouten laag performance 31

Kwaliteitsattributen Tmap-Next kent de volgende Beheerbaarheid Beveiliging Bruikbaarheid Connectiviteit Continuïteit Controleerbaarheid Flexibiliteit Functionaliteit Gebruikersvriendelijkheid Herbruikbaarheid Geschiktheid (INFRA) Inpasbaarheid Onderhoudbaarheid Performance Portabiliteit Testbaarheid Zuinigheid Voor verder info zie boek Tmap-Next (blz 504,…….) 32

Voorbeeld PRA-document nr Risico omschrijving Stakeholder kwaliteitsattribuut MoSCoW Testfase 1 Klant kan geen geld pinnen bij eigen bank PM Business Functionaliteit M Expliciet-FAT Impliciet-GAT Unieknummer, eenduidige risico omschrijving, wie is verantwoordelijke, kwaliteitsattribuut (kenmerk), prio uit MoSCoW, gedurende welke testsoort afgedekt 33

Einde workshop PRA ®