Download de presentatie
De presentatie wordt gedownload. Even geduld aub
GepubliceerdJuliaan Kuiper Laatst gewijzigd meer dan 10 jaar geleden
1
EQUA Moeten we requirements serieus nemen?
2
Traditioneel Iteratief Agile Open Source Frank Peeters f.peeters@fontys.nl Petra Heck p.heck@fontys.nl
3
Traditioneel & Iteratief
4
Principes Requirements Design Bridge Design Bridge Software De klant is de koning De klant is de keurmeester Wij zijn aansprakelijk 4
5
Kwaliteit Software 792239 m.socrative.com Niet te veel en niet te weinig 1.Mijn ontwikkelteam garandeert dat de software matcht met de requirements. In verband met onderhoud: 2.Mijn ontwikkelteam garandeert dat de software matcht met het design.
6
Symbiosis methodologie 1. garandeert een match tussen requirements en design. 2. garandeert een match tussen design en software.
7
Symbiosis: Aanpak + Tool Requirements Design Bridge Design Bridge Software Tool stelt realisatie van requirement vast Validatie + Realisatie = KLAAR Requirements Design Geen verspilde aandacht voor documentatie
8
Programmeren Requirements Design Bridge Design Bridge Software Geen Boilerplate Broncode Domeinlaag Geschikte operaties, Juiste parameters, Implementatie operaties, Afstemming tussen klassen, … Rules m.b.t. Afleidbaarheid Rules m.b.t. Automatische Toestandsovergang Domain Class Library wordt gegenereerd Na Use Case Modelling wordt UseCase Class Library gegenereerd 8
9
Agile & Open Source Petra Heck
10
Kwaliteit van requirements A. Davis et al., Identifying and measuring quality in a software requirements specification, 1993 Hoe vertalen we dit naar agile?
11
STELLING De kwaliteit van agile user stories is minder belangrijk dan bij traditionele requirementsdocumenten.
12
VRAAG 1 “With user stories … we just need to understand each other enough to know when we have struck a proper bargain” (Leffingwell 2011, Agile Software Requirements) In welke vorm leggen jullie agile requirements vast? 1) Helemaal niet (alleen mondeling) 2) Alleen kort statement wat gebruiker wil 3) Een use-case achtige omschrijving (scenario met stappen) 4) Meer detail in vorm van attachments, modellen, algoritmes
13
VRAAG 2 “user stories need little or no maintenance and can be safely discarded after implementation” (Leffingwell 2011, Agile Software Requirements) Bewaren jullie de agile requirements? 1) Nee 2) Ja, op papier 3) Ja, digitaal als naslag 4) Ja, digitaal voor hergebruik
14
Conclusie De kwaliteit van agile user stories is net zo belangrijk als bij traditionele requirementsdocumenten.
15
Heeft u agile requirements die we kunnen analyseren? p.heck@fontys.nl a.e.zaidman@tudelft.nl
16
Neem requirements serieus!
Verwante presentaties
© 2024 SlidePlayer.nl Inc.
All rights reserved.