Specificatiefase Training Versie 0.2, laatste update 2009/04/01 MS.

Presentatie over: "Specificatiefase Training Versie 0.2, laatste update 2009/04/01 MS."— Transcript van de presentatie:

1 Specificatiefase Training Versie 0.2, laatste update 2009/04/01 MS

2 Inhoud Introductie Specificatieproces Specificatiedocument Requirements Use Cases

3 Introductie Specificatiefase Iteratief proces Gezamenlijk proces
Het opstellen van specificaties is een proces wat niet louter de leverancier moet realiseren: dit is een gezamenlijk proces waarin alle stakeholders bij moeten worden betrokken – dus niet alleen de ICT! - De business - De (eind)gebruikers - Inhoudsdeskundigen bij de opdrachtgevers - De consultant - De projectleider - De programmeurs - (Derde partijen) Hoe verder in proces van requirements hoe technischer (business --> gebruiker --> systeem), hoe meer de verantwoordelijkheid en het beheer verschuift van de business naar de ICT. Van ontwikkeling naar validatie en management. Introductie

4 Introductie Projecten..

5 Projecten… succesvol volbrengen start bij goede specificaties!
Introductie Projecten… succesvol volbrengen start bij goede specificaties! Goede set specificaties zorgt voor: overeenstemming tussen opdrachtgever en leverancier over het beoogde systeem een gezamenlijke visie is over het project bij alle stakeholders een gedegen basis is voor schattingen en planningen een soepeler verloop van de bouw van de applicatie Immers: Garbage In… Garbage Out! Projecten succesvol volbrengen start bij goede requirements! Dit is verwachtingsmanagement zoals we dat ook kennen vanuit de Prince2 methodiek! Goede specs zorgen (er) voor overeenstemming tussen opdrachtgever en leverancier over het beoogde systeem een gezamenlijke visie is over het project bij alle stakeholders (klant, business, gebruiker, leverancier, pl, am, programmeur) een gedegen basis is voor schattingen en planningen dat de bouw van de applicatie dadelijk soepeler verloopt Als de specificaties niet correct, inconsistent of niet volledig zijn opgesteld, kan het vervolgtraject nooit goed zijn. Garbage In = Garbage Out! De kans dat het eindproduct dan voldoet aan de verwachtingen van de klant is dan erg klein. Dit heeft hoge herstelkosten, uitloop van projecten en een ontevreden klant tot gevolg. Je mag dan ook stellen dat je het belang van de specificatiefase absoluut niet mag onderschatten.

6 Introductie Het opstellen van specificaties is niet louter een zaak van de consultant of leverancier: dit is een gezamenlijk proces waarin alle stakeholders bij moeten worden betrokken – dus niet alleen de ICT! Dit is een sterk vereenvoudigde fasenplan in een IT project. Na het opstellen van de specificaties vangen we aan met de ontwikkeling. Binnen deze ontwikkeling wordt er mogelijk een prototype gebouwd, maar uiteindelijk levert dit het systeem op. Dit wordt getest, opgeleverd en uiteindelijk in productie genomen waarna het wordt onderhouden. Het opstellen van specificaties is een proces wat niet louter de leverancier moet realiseren: dit is een gezamenlijk proces waarin alle stakeholders bij moeten worden betrokken – dus niet alleen de ICT! - De business - De (eind)gebruikers - Inhoudsdeskundigen bij de opdrachtgevers - De consultant - De projectleider - De programmeurs - (Derde partijen) Specificatie Bouw Test Beheer Het opstellen van juiste specificaties bepaalt in hoge mate het succes van het project

7 Introductie De Wet de Boehm:
Fouten en verkeerde aannamen bij start van het project hebben een progressieve impact op de ‘technical debt‘. Maw: dit resulteert in een verlies in geld en/of tijd in latere fasen. Fout in de specificaties heeft Het investeren in goede requirements van goede kwaliteit lijkt op het eerste gezicht wellicht een intensief en kostbaar proces binnen het IT project. De Boehm-grafiek later echter duidelijk zien dat het fouten in de specificaties echter een progressieve impact op de zogenaamde technical debt in het verdere proces. Dr. Boehm, een vooraanstaande Amerikaanse software engineer, publiceerde in 1981 de wet van Boehm. Ter illustratie: 10 fouten die naar voren komen in de acceptatietesten kosten 320 keer zo veel tijd om te herstellen als dat deze aan tijd nodig waren geweest in de requirementsfase. In de productiefase (na oplevering) is dat nog eens een factor hoger! De kosten van herstel lopen dus exponentieel op wanneer het moment van detectie later ligt. Of je zou ook kunnen zeggen dat wanneer we vroeger ingrijpen, de effectiviteit en efficiëntie van de maatregelen groter wordt Beter nog is om dit natuurlijk geheel te voorkomen, maar we leven nu eenmaal niet in een ideale wereld. Investeren in deze fase verdient zich dus in elk geval terug: dit betreft niet alleen de herstelkosten van de fouten in de software, maar ook het kwijtraken van de klant!

8 Introductie Technical debt
In short het verschil tussen (werkelijke) technische voortgang en de voortgang in budget en planning. Verminderen fouten en onduidelijkheden Technical debt Hier zie je een sterk vereenvoudigd projectverloop. De voortgang wordt gemeten in kosten en planning. Bij start moeten we nog 100% doen en uiteindelijk leveren we op. De werkelijke voortgang loopt echter niet confrm het geplande projectverloop; er zijn altijd wel zaken die anders lopen dan voorzien. Sommige zaken kosten meer tijd voor de programmeur, soms zijn er zaken die niet eerder zijn geidentificeerd waardoor er meer werk moet worden verzet of er zijn zelfs situatie mogelijk waarin bepaalde code binnen het project herschreven moet worden waardoor de voortgang eigenlijk achteruit gaat. Dit resulteerd in een zogenaamde technical debt: de technische achterstand in de voortgang ten opzichte van de reeds verbruikte uren of verstreken tijd. Deze achterstand loopt in praktijk vaak op in de tijd omdat de voortgang niet met de zelfde snelheid verloopt als men had gewild. Sturing is hier de invulling maar een deel kan worden voorkomen door een juiste set specificaties! Hiermee trachten we onduidelijkheden en verkeerde aannames in de bouw te voorkomen maar ook om beter te plannen omdat we beter zicht hebben op wat er nu echt moet gebeuren. Sturing door PL

9 Specificatieproces Specificatiefase Iteratief proces
Gezamenlijk proces Het opstellen van specificaties is een proces wat niet louter de leverancier moet realiseren: dit is een gezamenlijk proces waarin alle stakeholders bij moeten worden betrokken – dus niet alleen de ICT! - De business - De (eind)gebruikers - Inhoudsdeskundigen bij de opdrachtgevers - De consultant - De projectleider - De programmeurs - (Derde partijen) Hoe verder in proces van requirements hoe technischer (business --> gebruiker --> systeem), hoe meer de verantwoordelijkheid en het beheer verschuift van de business naar de ICT. Van ontwikkeling naar validatie en management. Specificatieproces

10 Weet iedereen wat er wordt gebouwd?
Specificatieproces Doel Weet iedereen wat er wordt gebouwd? Weet iedereen waarom het wordt gebouwd? Is iedereen het eens over hoe het wordt gebouwd? Bereik van het project (bouwtechnisch, zie blz 4) Wat zien jullie voor ogen als resultaat? Wat zijn volgens jullie de doelstellingen van het project? Doelstellingen: Blz 3

11 De rol van de consultant
Specificatieproces De rol van de consultant Business (vertegenwoordiging) Opdrachtgever De Consultant Zoals de projectleider binnen de uitvoering van het project is binnen de specificatiefase de consultant de spin in het web. Hij communiceert met veel verschillende personen en partijen om uit te zoeken wat de specificaties zijn van het project. Vanuit de inventarisatie, vanuit de mogelijk aanwezige businesscase of het programma van eisen kijkt hij welke zaken nodig zijn in het project. Wat zijn de features en functionaliteiten in het systeem, waaraan moeten deze voldoen, wat wil de eindgebruiker, hoe zit het met de externe partij, vinden de programmeurs het project technisch haalbaar, zijn de doelstellingen haalbaar en hoe vullen we deze in en hoe wordt de planning ingevuld samen met de projectleider. Gezamenlijk proces Het opstellen van specificaties is dus een proces wat niet louter de leverancier moet realiseren: dit is een gezamenlijk proces waarin alle stakeholders bij moeten worden betrokken – dus niet alleen de ICT! - De business - De (eind)gebruikers - Inhoudsdeskundigen bij de opdrachtgevers - De consultant - De projectleider - De programmeurs - (Derde partijen) Account Manager Gebruikers (vertegenwoordiging) Project Manager Klant Medewerkers Ontwikkelaars en testers Overige stakeholders

12 Specificatieproces Specificatie Requirements Ontwerp
Algemeen Specificatie Requirements Ontwerp Specificaties achterhalen De Specificatiefase bestaat uit een aantal stappen, maar is tevens een Iteratief proces Elk aspect, of dat nu in detail of een groot component is, wordt langzaam via een inventarisatie met de betrokkenen via een analyse tot requirement opgesteld. Indien in de analyse blijkt dat er zaken niet duidelijk zijn of er informatie mist dient deze nader te worden besproken of onderzocht. De inventarisatie vind plaats door studie van relevante documentatie, interviews met betrokkenen, workshops, brainstormsessies, marktonderzoek, haalbaarheids- en gebruikeronderzoeken etc etc. (ook analyses bestaandebesteem, G/F analyse) De input voor de requirements kan (o.a.) bestaan uit: * Bedrijfsdoelen – wat wil de organisatie bereieken; * business rules – inhoudelijke eisen mbt beleid, standaarden of regels; * Kwaliteitseisen – bijvoorbeeld snelheid, beveiliging en gebruiksvriendelijkheid * Beperkingen – deze limiteren ontwerpkeuzes en zijn veelal technisch of organisatorisch van aard; De requirements worden gecontroleerd door de betrokken, de programmeurs, de projectleider, de opdrachtgever en deskundge medewerkers. Indien bij controle blijkt dat er iets niet klopt wordt dit gecorrigeerd of moet het zelfs opnieuw worden beoordeeld. Indien er nieuwe zaken aan het licht komen, of bepaalde zaken niet volledig zijn wordt het stappenplan per subonderdeel opnieuw gevolgd. Uiteindelijk levert het proces een volledige set aan requirements op. Gedetailleerd ‘Twin Peaks’ model (Nuseibeh 2001)

13 Specificatieproces Inventarisatie Specificaties Controle Analyse
Verdieping Nieuwe informatie en hyaten input Specificaties achterhalen De Specificatiefase bestaat uit een aantal stappen, maar is tevens een Iteratief proces Elk aspect, of dat nu in detail of een groot component is, wordt langzaam via een inventarisatie met de betrokkenen via een analyse tot requirement opgesteld. Indien in de analyse blijkt dat er zaken niet duidelijk zijn of er informatie mist dient deze nader te worden besproken of onderzocht. De inventarisatie vind plaats door studie van relevante documentatie, interviews met betrokkenen, workshops, brainstormsessies, marktonderzoek, haalbaarheids- en gebruikeronderzoeken etc etc. (ook analyses bestaandebesteem, G/F analyse) De input voor de requirements kan (o.a.) bestaan uit: * Bedrijfsdoelen – wat wil de organisatie bereieken; * business rules – inhoudelijke eisen mbt beleid, standaarden of regels; * Kwaliteitseisen – bijvoorbeeld snelheid, beveiliging en gebruiksvriendelijkheid * Beperkingen – deze limiteren ontwerpkeuzes en zijn veelal technisch of organisatorisch van aard; De requirements worden gecontroleerd door de betrokken, de programmeurs, de projectleider, de opdrachtgever en deskundge medewerkers. Indien bij controle blijkt dat er iets niet klopt wordt dit gecorrigeerd of moet het zelfs opnieuw worden beoordeeld. Indien er nieuwe zaken aan het licht komen, of bepaalde zaken niet volledig zijn wordt het stappenplan per subonderdeel opnieuw gevolgd. Uiteindelijk levert het proces een volledige set aan requirements op. Verduidelijken Specificaties Controle Analyse Opnieuw beoordelen Corrigeren Specificatie requirements specificaties

14 Specificatie Document(en)
Specificatieproces Programma van eisen Doelstellingen Businessrules Kwaliteitseisen Beperkingen Requirements Specificatie Document(en) Ontwerp GO! Business In onze werkwijze betekent dat de flow volgens diagram. Requirements Hoe verder in proces van requirements hoe technischer, hoe meer de verantwoordelijkheid en het beheer verschuift van de business naar de ICT. Dit zie je terugkomen binnen de requirements in de scheiding van businessrequirements naar gebruikersrequirements naar de systeem requirements Business Requirements – doelstellingen van de business: waarom moet het systeem worden gemaakt? Deze requirements zijn leidend voor de projectscope en richting van de overige requirements. User Requirements – de doelen en taken die de eindgebruikers van het systeem moeten kunnen uitvoeren: wat moet het systeem kunnen doen? Systeem requirements – dit zijn de eisen of restricties van het systeem die volgen uit de business (BRQ) en systeem (SRQ) requirements Dit is de meest voorkomende verdeling die wordt gebruikt. documenten Gebruiker Systeem Interviews en meetings Inventarisatie Analyse Specificatie Controle

15 Requirements Requirements businessrule eis prioriteit doel wens
behoefte beperking doelstelling eis businessrule betrokkenen bron prioriteit doel categorie afhankelijkheid Applicatie Requirements vaststellen Bij het opstellen van de requirements moet je je afvragen: Wat moeten de gebruikers kunnen? Wat ontbreekt er in de huidige software en waarom? Wat zou het wel moeten doen? Er dient kritisch te worden gekeken wat de prioriteiten zijn van alle requirements. Zijn deze wel van belang voor de doelstellingen van het project? Zijn er requirements die andere requirements uitsluiten of in met elkaar in conflict zijn? Een requirement is beperkt qua inhoud, deze bestaan uit: - alleen eisen en beperkingen, - gèèn inconsistenties of overlappingen, - gèèn onderlinge conflicten of hyaten. Iedere requirement krijgt een unieke naam en of code en heeft een aantal attributen (zie tekening) Bij het organiseren van requirements moet je hou je in aanvang een lijst bij (de requirementslist). Hou wijzigingen in de lijst onder controle door versiebeheer. De lijst kan je bijhouden in een Excelsheet of in MS Sharepoint. Ook is het raadzaam een matrix bij te houden, of per item wat de afhankelijkheden onderling zijn en evt in welke usecase deze is verbijzonderd.

16 Requirements Voorbeeld ‘Functionals’ ‘Non-Functionals’
138 - De website dient snel de lijst met records aan de gebruiker te tonen. 138a – De website toont onder menu x de lijst met records aan de gebruiker in het hoofdscherm 138b De lijst wordt binnen 10 seconden (marge: 5 sec) aangeboden 138c – Per record wordt de naam, datum en nummer getoond 138d – De lijst is gebruiksvriendelijk 138e – De lijst is onderhoudbaar 138f – De gegevens zijn alleen wijzigbaar door de beheerder Requirements vaststellen Goede requirements zijn compleet en ondubbelzinnig! Iedere betrokkenen begrijpt dus exact wat de requirement betekent voor het project en kan niet op meerdere manieren worden uitgelegd! Dus niet: ‘het website dient snel de lijst te laten zien’ maar ‘het systeem presenteert de lijst aan de gebruiker binnen 15 seconden’. Maw: maak de requirement, indien mogelijk, meetbaar zodat deze later bij oplevering kan worden gecontroleerd op kwaliteit. Het is niet nodig om alle requirements geheel uit te schrijven en van kwaliteitseisen (en toleranties!) te voorzien (dit geldt niet voor SRQ), zolang het maar duidelijk is hoe we het kunnen bouwen en hoe het kan worden gecheckt. Functionals vs Non-functionals Functionele requirements hebben meer betrekking op de functies die het systeem moet vervullen: Gedrag Gegevens Foutafhandeling Dynamiek Presentatie & Interfaceing Niet-Functionele requirements beschrijven meer de eigenschappen en kenmerken van het systeem: Functionaliteit Betrouwbaarheid Gebruikersvriendelijkheid Efficiëntie Onderhoudbaarheid Portabiliteit - ‘Functionals’ ‘Non-Functionals’

17 Specificatiedocument Projectdefinitie
Specificaties Specificatiedocument Projectplan (PM) Projectdefinitie (Visie, scope, relaties, uitsluitingen etc) Functionele Analyse (Functionaliteiten, Businessrules, gegevensstromen) Specificatiedocument Met de requirements kunnen we tenslotte de specificaties opstellen in de vorm van productbeschrijvingen, functionaliteiten en use cases. Requirements Technisch Ontwerp (LD) Requirements doc. (Product Beschrijvingen) Architectuur & Infrastructuur (PBS, PFD, HLA, globaal ERD, standaarden en technieken) Use Case Specificaties

18 Specificaties Specificatiedocument - projectdefinitie (businesscase, scope, relaties, aannamen etc) - functionele analyse (functionaliteiten, infra- en architectuur, standaarden en technieken) - Requirements (lijst, document, businessrules) - overzicht Use Case Model (UC Specificaties, actoren, top UML) - overzicht globaal gegevensmodel (top ERD, ) - overzicht tracering Verklarende Woordenlijst

19 Use Case Model Use Case Specificaties
Specificeert een doel van een gebruiker in het systeem via een stappenplan: 1. Definieer het doel en de actoren 2. Definieer de samenvatting van de Use Case 3. Definieer het hoofdscenario (succes) en de gegevensstroom 4. Definieer alternatieve scenario’s (succes) en de foutscenario’s (falen) 5. Verder neem je ook op: - Traceringsmatrix en de relevante businessrules - Relevante informatiemodel (gebruikte entiteiten) - Functionele testen 6. Dynamisch gedeelte: - openstaande vragen  ontwerpbeslissingen  ontwerpkeuzes Bij het opstellen van de Use Cases bepalen we feitelijk wat de gebruiker kan doen in de applicatie. De Use Case bepaalt via een stappenplan hoe hij zijn doel kan behalen, wat de alternatieve paden zijn om dit doel te bepalen en wat er moet gebeuren bij fouten. Er zijn verschillende rollen – actoren – voor verschillende gebruikers mogelijk, het systeem is OOK een actor!! Het is er handig om eerst een stroomschema te maken van (in elk geval het hoofdscenario van) de Use Case. Dit stroomschema (of gegevensstroom) maak je in visio met in de vorm van een beslisboom of DFD (Data Flow Diagram). Hierin laat je schematisch het verloop van het proces zien dat relevant is voor de Use Case. Beschrijf in de inleiding wat het doel is en waarom deze Use Case in de applicatie gebruikt wordt en mogelijk wat de context is binnen het geheel. Daarna beschrijf je het hoofdscenario in stappen wat de gebruiker en het systeem aan opvolgede acties doet en wat de gebruiker in deze stappen ziet of invult (en kiest). Dit is het succescenario. [document voorbeeld] Er zijn mogelijk zijpaden te definiëren die al dan niet terug komen op het hoofdscenario: dit zijn de alternatieve scenario’s. Het kan ook zijn dat er een fout optreed of dat de gebruiker een handeling uitvoert die niet wordt geaccepteerd. Deze uitzonderingen definiëren we in de foutscenario’s. In het hoofdscenario geef je aan waar er foutscenario’s en alternatieven scenario’s mogelijk zijn. In de matrix (en lijst van businessrules) geef je aan welke requirements van toepassing zijn in de Use Case. Het informatiemodel kan optioneel in ruwe vorm worden opgesteld: welke velden zijn nodig uit de database om zaken te presenteren of op te slaan? Dit model wordt later door de ontwikkelaar verder gespecificeerd. Tevens dienen zij in de matrix aan te geven in welke technische componenten de Use Cases (en daarme welke requirement) is gerealiseerd. Op deze manier kunnen we in latere fasen zien wat de impact is bij een RFC of bij een Fout, of waar de oorspronkelijke vraag of eis vandaan kwam. Verder geven we één of meerdere functionele testen op, waarmee we snel kunnen controleren of de Use Case later in orde is uitgevoerd. De scenario’s en deze functionele testen geven eigenlijk al een grote voorzet voor de uiteindelijke testfase en de testplannen. Tot slot hebben we een dynamisch gedeelte tijdens de inventarisatie en analyse van de specificaties. Zaken die onduidelijk zijn in de analyse, en op de usecase betrekking hebben, ze je in de openstaande vragen. Zo hou je een goed overzicht en geef je proactief de mogelijkheid aan de klant (en andere betrokkenen) om deze vragen te beantwoorden. Het kan zijn dat je verschillende input krijgt van verschillende personen over bepaalde zaken. Over deze issues moet je overeenstemming bereiken – deze zet je in de ontwerpbeslissingen. Als hierover een beslissing is gegeven (of uitsluitsel over een vraag) leggen we de gemaakte afspraken vast door de issue en bepaling te verplaatsen naar de lijst ontwerpkeuzes.

20 Use Case Model Use Case Specificaties ontwikkelen
1. ‘blanco’ use case naar klant  inleiding, samenvatting actoren en doel  Feedback van de klant mbt successcenario 2. Uitbreiden Use Case  opstellen hoofdscenario  opstellen gegevensstroom  bepalen waar een alternatief of foutscenario mogelijk is  bepalen beperkingen en regels (bussinessrules)  vaststellen onduidelijkheden en conflicten (openstaande vragen en beslissingen) Controle van Use Case  validatie door klant / in vergadering  wijzigingen en correcties doorvoeren  validatie door klant / in vergadering  maken van ontwerpkeuzes 4. Overige zaken bijvoegen  gegevensstroom  traceringsmatrix Bij het opstellen van de Use Cases bepalen we feitelijk wat de gebruiker kan doen in de applicatie. De Use Case bepaalt via een stappenplan hoe hij zijn doel kan behalen, wat de alternatieve paden zijn om dit doel te bepalen en wat er moet gebeuren bij fouten. Er zijn verschillende rollen – actoren – voor verschillende gebruikers mogelijk, het systeem is OOK een actor!! Het is er handig om eerst een stroomschema te maken van (in elk geval het hoofdscenario van) de Use Case. Dit stroomschema (of gegevensstroom) maak je in visio met in de vorm van een beslisboom of DFD (Data Flow Diagram). Hierin laat je schematisch het verloop van het proces zien dat relevant is voor de Use Case. Beschrijf in de inleiding wat het doel is en waarom deze Use Case in de applicatie gebruikt wordt en mogelijk wat de context is binnen het geheel. Daarna beschrijf je het hoofdscenario in stappen wat de gebruiker en het systeem aan opvolgede acties doet en wat de gebruiker in deze stappen ziet of invult (en kiest). Dit is het succescenario. [document voorbeeld] Er zijn mogelijk zijpaden te definiëren die al dan niet terug komen op het hoofdscenario: dit zijn de alternatieve scenario’s. Het kan ook zijn dat er een fout optreed of dat de gebruiker een handeling uitvoert die niet wordt geaccepteerd. Deze uitzonderingen definiëren we in de foutscenario’s. In het hoofdscenario geef je aan waar er foutscenario’s en alternatieven scenario’s mogelijk zijn. In de matrix (en lijst van businessrules) geef je aan welke requirements van toepassing zijn in de Use Case. Het informatiemodel kan optioneel in ruwe vorm worden opgesteld: welke velden zijn nodig uit de database om zaken te presenteren of op te slaan? Dit model wordt later door de ontwikkelaar verder gespecificeerd. Tevens dienen zij in de matrix aan te geven in welke technische componenten de Use Cases (en daarme welke requirement) is gerealiseerd. Op deze manier kunnen we in latere fasen zien wat de impact is bij een RFC of bij een Fout, of waar de oorspronkelijke vraag of eis vandaan kwam. Verder geven we één of meerdere functionele testen op, waarmee we snel kunnen controleren of de Use Case later in orde is uitgevoerd. De scenario’s en deze functionele testen geven eigenlijk al een grote voorzet voor de uiteindelijke testfase en de testplannen. Tot slot hebben we een dynamisch gedeelte tijdens de inventarisatie en analyse van de specificaties. Zaken die onduidelijk zijn in de analyse, en op de usecase betrekking hebben, ze je in de openstaande vragen. Zo hou je een goed overzicht en geef je proactief de mogelijkheid aan de klant (en andere betrokkenen) om deze vragen te beantwoorden. Het kan zijn dat je verschillende input krijgt van verschillende personen over bepaalde zaken. Over deze issues moet je overeenstemming bereiken – deze zet je in de ontwerpbeslissingen. Als hierover een beslissing is gegeven (of uitsluitsel over een vraag) leggen we de gemaakte afspraken vast door de issue en bepaling te verplaatsen naar de lijst ontwerpkeuzes.