PowerPoint-presentatie

Specialist in de Test discipline
PROCESVISIE - INTRODUCTIE
WWW.INFOCON.NL
ROSMALEN, VOORJAAR 2013
© Infocon
1
Agenda
1.
PROCESVISIE: FASEN EN DISCIPLINES
2. WERKPRODUCTEN
3. DISCIPLINE: REQUIREMENTS
4. DISCIPLINE: ANALYSIS&DESIGN
5. DISCIPLINE: TEST
6. AFSLUITING
© Infocon
2
1. Procesvisie: fasen en disciplines (1)
 Processen en fasering
Project
Conception
fase
Inception
fase
Elaboration
fase
Primair
Construction
fase
Transition
fase
Kwaliteit
Kwaliteitsborging
Kwaliteitsdefinitie
Kwaliteitscontrole
Kwaliteitsverbetering
© Infocon
Projectmanagement en Configuratiemanagement
Afronding
Secundair
3
1. Procesvisie: fasen en disciplines (2)
 Fasering en beslissen
Conception
fase
Inception
fase
Elaboration
fase
Construction
fase
Transition
fase
Project
resultaat
Projectweg
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
© Infocon
4
1. Procesvisie: fasen en disciplines (3)
 Inception-fase
Te beantwoorden vragen:
Inception
fase
•
•
•
•
•
Producten
•
•
•
•
•
•
•
PID
Risk list
Business Case
Business Model
Vision
SAD
PAP / MTP
© Infocon
•
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
5
1. Procesvisie: fasen en disciplines (4)
 Elaboration-fase
Te beantwoorden vragen:
Elaboration
fase
•
•
•
•
Producten
• Adm. Organisatie
• SAD
• SRS
• Testdesign
• PID
• Business Case
• Stageplan
© Infocon
•
•
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?
Creëren stabiele situatie
6
1. Procesvisie: fasen en disciplines (5)
 Dambord
Disciplines
Infocon
© Infocon
7
2. Werkproducten (1)
 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: testmanager

© Infocon
8
2. Werkproducten (2)
 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

© Infocon
9
2. Werkproducten (3)
 Analysis&Design

Software Architectuur Document



Analysis Model



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
Inhoud: verdere uitwerking van de logische interne samenhang tussen de
onderkende componenten (Use Case Realizations)
Wie schrijft: Designer/Ontwikkelaar
Design Model


© Infocon
Inhoud: vertaling logische gewenste structuur naar de implementatie
ervan (o.a. Data Model)
Wie schrijft: Designer/Ontwikkelaar
10
2. Werkproducten (4)
 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

© Infocon
11
3. Discipline: Requirements (1)
 Doel
 Vaststellen en vastleggen van de eisen en wensen die aan een
oplossing worden gesteld: de requirements
 Rollen
 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
© Infocon
12
3. Discipline: Requirements (2)
 Taken System Analist
• 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
•
•
© Infocon
Storyboards
User Interface Specificaties
1) Proces Architectuur Model
2) Software Architecture Document
3) Geldig voor meerdere use cases en niet13
functionele specificaties
3. Discipline: Requirements (3)
 Samenhang deliverables
• 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)
© Infocon
14
4. Discipline: Analysis&Design (1)
 Keyrol: Project Architect
© Infocon
15
4. Discipline: Analysis&Design (2)
 Rol: Ontwikkelaar
© Infocon
16
4. Discipline: Analysis&Design (3)
 Samenhang begrippen/producten
© Infocon
17
5. Discipline: Test (1)
 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
© Infocon
18
5. Discipline: Test (2)
 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
© Infocon
19
5. Discipline: Test (3)
 Samenhang deliverables
Vision
Perspectief van
opdrachtgever en
opdrachtnemer
Verantw.heid:
Projectmanager
Eisen/
wensen
SAD (Software Architecture)
SRS (Use Cases, e.d.)
PAP
Acceptatiestrategie
MTP
Teststrategie
Verantw.heid:
Testmanager
Testplanning
© Infocon
Detail
TP
Test
design
Test
results
Test
report
Voor elke fase
Testspecificatie
Testuitvoering
Testafronding
20
5. Discipline: Test (4)
 Testsoorten
“Whitebox”
“Blackbox”
© Infocon
21
5. Discipline: Test (5)
 Testomgevingen
Leverancier
© Infocon
Klant
22
5. Discipline: Test (6)
 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 installatieprocedure/-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
 …
© Infocon
23
6. Afsluiting
UW PARTNER IN TESTEN
DANK VOOR UW AANDACHT
Infocon Services
Kooikerstraat 7
5241 MC Rosmalen
© Infocon
T 073 52 19 567
E [email protected]
W www.infocon.nl
24