Product Risico Analyse

Harry Storimans

Introductie

     

Wie ben ik: Harry Storimans Functie: Testconsultant IT-Zamna E-Mail: [email protected]

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): • 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 1 0

Procedure PRA-Activiteiten

Wie

Testmanager Testmanager Testmanager TM, Stakeholders, Externe moderator TM, Stakeholders TM

Stap

1 2 3 4 5 6

Wat

Identificeren stakeholders Vooronderzoek productrisico’s, requirements en acceptatiecriteria Bepalen aanpak vervolg Aanvullen/matchen productrisico’s, requirements, acceptatiecriteria Prioriteren productrisico’s, requirements en acceptatiecriteria Opstellen rapport PRA

Waarmee: I:Input O:Output

I:Business case, PID vooronderzoek, checklist productrisicos O: overzicht stakeholders I: user/business requirements, business case, risk log O: overzicht productrisico’s I: product risico’s, overzicht stakeholders, checklist product risico’s O: aanpak tbv opstellen productrisico’s I: procedure productrisico’s, inventarisatie, overzicht stakeholders, Criteria (MoSCoW) I: productrisico’s, requirements O: overzicht koppeling productrisico’s 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 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

Schade bij falen Hoog Midden Laag B c Hoog A

Kans op falen

Midden Laag B B B c 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 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

Bedrijfsprocessen Deelsystemen Productrisico’s Acceptatiecriteria User requirements Use cases Kritische succes factoren kwaliteitsattributen

voorbeelden

Facturering en orders blijven correct werken met ondersteuning vh nieuwe systeem Correct werkend systeem klantbeheer, orders, toevoegen klant, wijzigen klant Klant krijgt incorrecte factuur Gebruikers kunnen niet met systeem omgaan Koppelingen werken goed Vaststellen kredietwaardigheid aanvrager gebeurt door BKR-toetsing Opvoeren nieuwe klant, open rekening Online hypotheek moet binnen 1 minuut verschijnen op scherm Functionaliteit, performance, gebruikersvriendelijkheid, inpasbaarheid.

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

Soort testdoel

Bedrijfsprocessen Deelsystemen Productrisico’s Acceptatiecriteria User requirements Use cases Kritische succes factoren kwaliteitsattributen

Tabel

Voorbeelden

Facturering en orders blijven correct werken met ondersteuning vh nieuwe systeem Correct werkend systeem klantbeheer, orders, toevoegen klant, wijzigen klant Klant krijgt incorrecte factuur Gebruikers kunnen niet met systeem omgaan Koppelingen werken goed

Kwaliteitsattribu ten

Functionaliteit, gebruikersvriendelijkheid, performance Functionaliteit, gebruikersvriendelijkheid, performance Functionaliteit Gebruikersvriendelijkheid Vaststellen kredietwaardigheid aanvrager gebeurt door BKR toetsing Opvoeren nieuwe klant, open rekening Online hypotheek moet binnen 1 minuut verschijnen op scherm Functionaliteit, performance, gebruikersvriendelijkheid, inpasbaarheid.

Functionaliteit, performance, beveiliging Functionaliteit Functionaliteit, gebruikersvriendelijkheid, performance performance 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

Functionaliteit Performance

Deelobjecten(systeem)

Deelsys1 Deelsys2 Totale systeem Batch Online 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

Schade bij falen Hoog Midden laag B c Hoog A B c

Kans op falen

Midden Laag B B C 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 Bedrijfsproces 1 Bedrijfsproces 2 Bedrijfsproces 3 Schade H H L 27

Faalkans per deelobject

• Inschatting van de faalkans voor elk deelobject maken • Inbreng nodig van techniek en ontwikkelproces

Functionaliteit

Faalkans

Deelsys 1

H

Deelsys 2

M

Deelst 3

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

Testdoelen Proce s1 Proces 2 Proces 3

Deelobjecten

H H faalkans Schade L A A C

Deelsys1

H

Deelsys 2

M -,* A, ** C C C

Totale sys

L 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

S amenvoegen kenmerken/deelobjecten/risicoklassen

   PRA-totaaloverzicht opstellen Geen inbreng meer nodig van derden De volgende tabel is een voorbeeld van een totaaloverzicht.

Kenmerk

Functionaliteit -deelsys 1

Risicoklasse Argumentatie

-deelsys 2 -totaal gebruikersvriendelijkheid A B C B Hoge faalkans, wordt in cruciale processen 1 en 2 gebruikt Gemiddelde faalkans, slechts beperkt gebruikt in crucialeproces 2 als 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 32

Voorbeeld PRA-document

1

nr Risico omschrijving

Klant kan geen geld pinnen bij eigen bank

Stakeholder

PM Business

kwaliteitsatt ribuut

Functionaliteit M

MoSCoW Testfase

Expliciet-FAT Impliciet-GAT 33

Einde workshop PRA

®