Post on 08-Jun-2015
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