Download de presentatie
De presentatie wordt gedownload. Even geduld aub
GepubliceerdAlfred Christiaens Laatst gewijzigd meer dan 10 jaar geleden
1
Specialist in de Test discipline
Procesvisie - Introductie Rosmalen, voorjaar 2013 © Infocon
2
Agenda Procesvisie: fasen en disciplines WerkpRoducten
Discipline: requirements Discipline: Analysis&Design Discipline: test Afsluiting © Infocon 2
3
1. Procesvisie: fasen en disciplines (1)
Processen en fasering Primair Project Con- ception fase Inception fase Elabo- ration fase Con- struction fase Tran- sition fase Kwaliteit Kwaliteitsborging Kwaliteits- definitie Afron- ding Kwaliteitscontrole Secundair Kwaliteitsverbetering Projectmanagement en Configuratiemanagement © Infocon 3
4
1. Procesvisie: fasen en disciplines (2)
Fasering en beslissen Con- ception fase Inception fase Elabo- ration fase Con- struction fase Tran- sition 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
5
1. Procesvisie: fasen en disciplines (3)
Inception-fase 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? Inception fase Producten PID Risk list Business Case Business Model Vision SAD PAP / MTP Planvorming © Infocon 5
6
1. Procesvisie: fasen en disciplines (4)
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? Elaboration-fase Elabo- ration fase Producten Adm. Organisatie SAD SRS Testdesign PID Business Case Stageplan Creëren stabiele situatie © Infocon 6
7
1. Procesvisie: fasen en disciplines (5)
Dambord Disciplines Infocon © Infocon 7
8
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
9
2. Werkproducten (2) Requirements Vision SRS (System Requirement Set)
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 © Infocon 9
10
2. Werkproducten (3) 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) © Infocon 10
11
2. Werkproducten (4) Test (Master) Test Plan Testontwerp
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
12
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
13
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 Storyboards User Interface Specificaties Proces Architectuur Model Software Architecture Document Geldig voor meerdere use cases en niet functionele specificaties © Infocon 13
14
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
15
4. Discipline: Analysis&Design (1)
Keyrol: Project Architect © Infocon 15
16
4. Discipline: Analysis&Design (2)
Rol: Ontwikkelaar © Infocon 16
17
4. Discipline: Analysis&Design (3)
Samenhang begrippen/producten © Infocon 17
18
5. Discipline: Test (1) Doel Rollen
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
19
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
20
Perspectief van opdrachtgever en opdrachtnemer
5. Discipline: Test (3) Samenhang deliverables Vision Eisen/ wensen SAD (Software Architecture) SRS (Use Cases, e.d.) Perspectief van opdrachtgever en opdrachtnemer PAP Verantw.heid: Projectmanager MTP Acceptatie- strategie Teststrategie Verantw.heid: Testmanager Detail TP Test design Test results Test report Testplanning Voor elke fase Test- specificatie Testuitvoering Testafronding © Infocon 20
21
5. Discipline: Test (4) Testsoorten “Whitebox” “Blackbox” © Infocon 21
22
5. Discipline: Test (5) Testomgevingen Leverancier Klant © Infocon 22
23
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 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 … © Infocon 23
24
Uw partner in testen Dank voor uw aandacht
6. Afsluiting Uw partner in testen Dank voor uw aandacht Infocon Services Kooikerstraat 7 5241 MC Rosmalen T E W © Infocon
Verwante presentaties
© 2024 SlidePlayer.nl Inc.
All rights reserved.