1

PROCESVISIE - INTRODUCTIE

W W W. I N F O C O N. N L

ROSMALEN, VOORJAAR 2013

Specialist in de Test discipline

© Infocon

1. PRO C E SVI S I E : FASE N E N DI SC I PL I N E S

2. WE RKPR O DUC T E N

3. DI SC I PL I NE : RE Q UI RE ME NT S

4. DI SC I PL I NE : ANALYSI S&DE SI G N

5. DI SC I PL I NE : T E ST

6. AFSLUI T I N G

© Infocon

Agenda

2

1. Procesvisie: fasen en disciplines (1)

© Infocon

Processen en fasering

3

Kwaliteits-definitie

Afron-ding

Kwaliteitsborging

Kwaliteitsverbetering

Kwaliteitscontrole

Projectmanagement en Configuratiemanagement

Project

Con-ception

fase

Inceptionfase

Elabo-rationfase

Con-struction

fase

Tran-sitionfase

Primair

Kwaliteit

Secundair

1. Procesvisie: fasen en disciplines (2)

© Infocon

Fasering en beslissen

4

Tussen de verschillende fasen van een project is steeds een duidelijk beslispunt aanwezig

Beslispunt betekent: enerzijds: goedkeuring en vastlegging resultaat voorafgaande fase anderzijds: vaststelling welke activiteiten in de volgende fase(n) zullen

plaatsvinden Elk beslispunt wordt ondersteund door zowel inhoudelijke als

beheersmatige beslisdocumenten

Con-ception

fase

Inceptionfase

Elabo-rationfase

Con-struction

fase

Tran-sitionfase

Projectresultaat

Projectweg

1. Procesvisie: fasen en disciplines (3)

© Infocon

Inception-fase

5

Inceptionfase

Producten• PID• Risk list• Business Case• Business Model• Vision• SAD• PAP / MTP

Te beantwoorden vragen:• Zijn we het eens over de scope? (Vision)• Is er op zijn minst één oplossing of

oplossingsrichting bekend? (SAD)• Zijn we het eens over de wensen en eisen?

(Use Case Model en Acceptatieplan)• Hebben we de belangrijkste risico’s en

afdoende tegenmaatregelen in beeld? (Risicolijst)

• Zijn we het erover eens dat de globale planning en kosteninschatting realistisch zijn? (Software Development Plan)

• Zijn we het eens over het te volgen proces en de tools waarmee we de oplossing realiseren?

Planvorming

1. Procesvisie: fasen en disciplines (4)

© Infocon

Elaboration-fase

6

Creëren stabiele situatie

Elabo-rationfase

Te beantwoorden vragen:• Hebben we een gedetailleerd beeld van de

meest kritische requirements? (Enkele Use Case Specifications uitgewerkt)

• Hebben we een stabiele architectuur in werkende code? (Architecturele Prototypen en SAD)

• Is de ontwikkelomgeving ingericht en adequaat gebleken?

• Hebben we de belangrijkste risico’s overwonnen? (Proof of Concept)

• Hebben we een accuraat idee van kosten, planning en scope?

• Wordt de business case nog gehaald?

Producten• Adm. Organisatie• SAD• SRS• Testdesign• PID• Business Case• Stageplan

1. Procesvisie: fasen en disciplines (5)

© Infocon

Dambord

7

DisciplinesInfocon

2. Werkproducten (1)

© Infocon

Belanghebbenden Business Proces Model

Inhoud: levert een overzicht van de relevante bedrijfsprocessen en toont de samenhang tussen de business objecten die daarin een rol spelen

Wie schrijft: business (proces) analist Project Start Architectuur (PSA)

Inhoud: architecturele kaders en richtlijnen waarbinnen het nieuwe product zal gaan functioneren

Wie schrijft: ICT-architect Product Acceptatie Plan (PAP)

Inhoud: verschaft een meetbare basis voor de te accepteren werkproducten

Wie schrijft: testmanager8

2. Werkproducten (2)

© Infocon

Requirements Vision

Inhoud: beschrijft het gezamenlijk perspectief van opdrachtgever en opdrachtnemer met betrekking tot het project

Wie schrijft: informatie/system analist SRS (System Requirement Set)

Inhoud: Use Case Model: een overkoepelend overzicht van de

onderkende Use Cases, hun samenhang, gewicht en classificatie

Use Case Specification(s): de uitgewerkte beschrijving van de interactie van een Actor met het te bouwen systeem

Supplementary Specifications: niet functionele specs Wie schrijft: informatie/system analist

9

2. Werkproducten (3)

© Infocon

Analysis&Design Software Architectuur Document

Inhoud: bevat de hoofdlijnen van de oplossing, bestaande uit zowel de logische opdeling in componenten als de toe te passen patronen en alle ontwerpkeuzes

Wie schrijft: Software/Project Architect Analysis Model

Inhoud: verdere uitwerking van de logische interne samenhang tussen de onderkende componenten (Use Case Realizations)

Wie schrijft: Designer/Ontwikkelaar Design Model

Inhoud: vertaling logische gewenste structuur naar de implementatie ervan (o.a. Data Model)

Wie schrijft: Designer/Ontwikkelaar

10

2. Werkproducten (4)

© Infocon

Test (Master) Test Plan

Inhoud: een document dat de testaanpak voor het gehele project beschrijft (testscope, testorganisatie, testtypen, testhulpmiddelen, testtooling en testomgeving)

Wie schrijft: testmanager Testontwerp

Inhoud: een document, al dan niet vergezeld van testscripts en testdata, waarin wordt vastgelegd welke elementen getest zullen worden (bijvoorbeeld Use Case Scenario's, niet-functionele requirements, compleetheid), en welke test cases daarvoor zullen worden gebruikt

Wie schrijft: test analist/tester

11

3. Discipline: Requirements (1)

© Infocon

Doel Vaststellen en vastleggen van de eisen en wensen die

aan een oplossing worden gesteld: de requirementsRollen

Keyrol: System Analist (verantwoordelijk voor het vaststellen van de eisen en wensen en het vertalen van deze eisen en wensen in specificaties voor de realiseren oplossing

System Analist wordt hierbij ondersteund door de User Interface Designer die de specificaties ten aanzien van de User Interface uitwerkt

Belangrijke reviewers binnen het projectteam voor de System Analist zijn de Project Architect en de Test Analist 12

3. Discipline: Requirements (2)

© Infocon

Taken System Analist

13

• Vastleggen specificaties in een Software Requirements Set (SRS) bestaande uit:• Use Case Model met

gebruik making van het PAM1) en SAD2) model

• Use Case Specifications• Supplementary

Specifications2)

• Parallel aan opstellen Use Case Model werkt User Interface Designer de specificaties van het User Interface uit in• Storyboards• User Interface Specificaties

1) Proces Architectuur Model2) Software Architecture Document3) Geldig voor meerdere use cases en

niet functionele specificaties

3. Discipline: Requirements (3)

© Infocon

Samenhang deliverables

14

• Vision: beeldvorming en scope; onderbouwing PID• SRS: contract tussen gebruikers en project en vormt de

baseline voor bouwers• Use Case Realizations: vertaling Use Case naar welke

interactie daarvoor binnen systeem tussen componenten moet plaatsvinden (discipline: Analysis&Design)

4. Discipline: Analysis&Design (1)

© Infocon

Keyrol: Project Architect

15

4. Discipline: Analysis&Design (2)

© Infocon

Rol: Ontwikkelaar

16

4. Discipline: Analysis&Design (3)

© Infocon

Samenhang begrippen/producten

17

5. Discipline: Test (1)

© Infocon

Doel Validatie van datgene wat binnen het project is

gerealiseerd, van unittest tot en met de acceptatietest door gebruikers en beheerorganisatie (wordt voldaan aan de vooraf vastgelegde specificaties?)

Rollen Keyrol: Testmanager (verantwoordelijk) Ondersteund door Testcoördinator, Testanalist/-

Designer (inhoudelijk), Tester (uitvoering) en Gebruiker (uitvoering)

Afhankelijk van project kunnen rollen worden gecombineerd

18

5. Discipline: Test (2)

© Infocon

V-Model Standaard uitgangspunt voor testen binnen de

procesvisie Uitgegaan wordt een verband tussen de mate ven

detaillering in de ontwikkeling van het systeem en de teststages

19

5. Discipline: Test (3)

© Infocon

Samenhang deliverables

20

Vision

PAP

Perspectief van opdrachtgever en opdrachtnemer

Acceptatie-strategie

DetailTP

Testdesign

Testresults

Testreport

Eisen/wense

n

Voor elke fase

SAD (Software Architecture)SRS (Use Cases, e.d.)

Test-specificatie

MTP

Testuitvoering TestafrondingTestplanning

Verantw.heid:Projectmanag

er

Teststrategie

Verantw.heid:Testmanager

5. Discipline: Test (4)

© Infocon

Testsoorten

21

“Whitebox”“Blackbox

”

5. Discipline: Test (5)

© Infocon

Testomgevingen

22

Leverancier Klant

5. Discipline: Test (6)

© Infocon

Testvormen Securitytest: test op ongeautoriseerde toegang Performancetest: test op performance eisen Regressietest: test of wijzigingen geen ongewenste

neveneffecten teweegbrengen in andere delen van het systeem

Installatietest: test of software middels de installatie-procedure/-programma kan worden geïnstalleerd

GUI/User Interfacetest: test of User Interface voldoet aan de hieraan gestelde eisen

Documentatietest: test of documentatie voldoet aan eisen

Portabilitytest: test vervangbaarheid hardware/software … 23

24

UW PARTNER IN TESTEN

DANK VOOR UW AANDACHT

6. Afsluiting

© Infocon

Infocon ServicesKooikerstraat 75241 MC Rosmalen

T 073 52 19 567E info@infocon.nlW www.infocon.nl