Introductie User Stories. SYSQA B.V. Almere

Maat: px
Weergave met pagina beginnen:

Download "Introductie User Stories. SYSQA B.V. Almere"

Transcriptie

1 Introductie User Stories SYSQA B.V. Almere

2 Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 Inleiding Wat zijn User Stories? Definitie Voordelen Verschillen tussen user stories en use cases User Stories zijn geen Requirements Voorbeelden van user stories Eisen te stellen aan User Stories Hoe User Stories te gebruiken? Waar begin je? Wanneer is user story succesvol afgerond? User stories en de planning Referenties... 9 Versiebeheer Versie Datum Opmerkingen Auteur Initiële versie Sysqa Vertaling resterende Engelse teksten Sysqa Review Sysqa Aanpassen opmaak Sysqa Verzendlijst Versie Ontvanger 0.1 Sysqa 0.2 Sysqa 0.9 Sysqa

3 Organisatie SYSQA B.V. Pagina 3 van 9 1 Inleiding Een user story is een definitie van een requirement op een erg hoog niveau. Het wordt veel gebruikt in SCRUM en Extreme Programming (XP) project teams. Het bevat nét genoeg informatie om de ontwikkelaars in staat te stellen een schatting te maken van de inspanning benodigd voor de implementatie ervan. In deze introductie komen de volgende onderwerpen kort aan de orde: Wat zijn User stories? Eisen te stellen aan User stories. Hoe User stories te gebruiken.

4 Organisatie SYSQA B.V. Pagina 4 van 9 2 Wat zijn User Stories? 2.1 Definitie User Stories is de bij agile softwareontwikkeling aanbevolen requirementsontwikkeltechniek voor het ontwikkelen van requirements. Een user story geeft aan wat het systeem voor de gebruiker moet doen. Dit moet voor de gebruiker of voor de klant van waarde zijn en in de terminologie van de business zijn geformuleerd. De beschrijving van een user story bevat slechts één of enkele zinnen. De definitie van een user story is: Een user story is functionaliteit van het systeem dat waarde heeft voor de gebruikers, gezien vanuit het gezichtspunt van de gebruiker. User stories hebben een vaste zinsopbouw: Als <gebruikersrol> wil ik <iets doen> zodat ik <er iets aan heb>. Deze zinsbouw dwingt af de user story vanuit het gezichtspunt van de gebruiker te schrijven en de aandacht te richten op de toegevoegde waarde voor de gebruiker. 2.2 Voordelen Omdat stories sommige karakteristieken van use cases of traditionele requirements statements vertonen, is het van belang na te gaan wat stories onderscheidt van deze requirements technieken. Deze verschillen kunnen leiden tot vele voordelen van user stories, waarvan enkele onderstaand zijn opgesomd. 1. User stories leggen de nadruk op verbale communicatie. Geschreven taal is vaak voor meerdere interpretaties vatbaar, en er is geen garantie dat de klant en de ontwikkelaar een statement op dezelfde manier zullen interpreteren. 2. User stories maken planning mogelijk: User stories kunnen worden gebruikt in project planning. Ze zijn zo geschreven dat van elk een schatting kan worden gemaakt van de moeilijkheidsgraad en de benodigde ontwikkelingstijd; use cases zijn over het algemeen te groot om een bruikbare inschatting te kunnen maken. Tevens wordt een story in een enkele iteratie van een agile project geïimplementeerd, terwijl het gebruikelijk is een use case te verdelen over meerdere iteraties (hoewel die iteraties normaal langer duren dan in een story gedreven project). 3. IEEE 830 style requirements statements ( Het systeem zal... ) representeren een ander probleem. Als je denkt aan de duizenden of zelfs tienduizenden items in een software requirements specificatie voor een typische applicatie, en daarbij hun onderlinge afhankelijkheden in beschouwing neemt, is het duidelijk dat het prioriteren hiervan bijna onbegonnen werk is. Als die prioritering beperkt blijft tot de gebruikelijke indeling 'hoog - middel - laag' is het onmogelijk om de requirements in een iteratief en incrementeel ontwikkelproces, dat elke 2 tot 4 weken een werkende versie moet opleveren, aan te pakken. User stories moedigen het team aan om het verzamelen van details uit te stellen. Een algemene user story ("Een recruiter kan een nieuwe vacature publiceren") kan als referentiekader dienen dat later wordt vervangen door meerdere gedetailleerde userstories. Deze techniek maakt User stories geschikt voor projecten met strenge tijdsbeperkingen, time boxes. Een team kan in korte tijd enkele tientallen user stories opstellen om een totaalbeeld van het systeem te krijgen. Vervolgens kunnen ze voor een klein aantal stories de details verzamelen en veel eerder aan het ontwerp beginnen dan wanneer ze besluiten eerst een complete set specificaties volgens IEEE 830-normen uit te werken.

5 Organisatie SYSQA B.V. Pagina 5 van Verschillen tussen user stories en use cases User stories en use cases hebben hetzelfde doel, namelijk de gebruikersrequirements communiceren aan de ontwikkelaars en de testers. Het verschil is dat user stories dit zoveel mogelijk mondeling doen en use cases hoofdzakelijk schriftelijk. Een ander belangrijk verschil tussen user stories en use cases is de scope. User stories zijn kleiner dan use cases. Een user story moet binnen tien dagen gebouwd kunnen worden. Een use case moet daarentegen alle requirements bevatten die nodig zijn bij het uitvoeren van een procestaak inclusief alle uitzonderingssituaties. 2.4 User Stories en requirements Hoewel User Stories hetzelfde effect beogen als andere software requirementspecificaties, use cases en soortgelijke documenten, wijken ze op een aantal subtiele maar fundamentele punten hiervan af. Het zijn geen gedetailleerde requirements (iets wat het systeem moet doen), maar eerder uitspraken over het doel van het systeem (het moet bij benadering dit kunnen doen), waarbij over de noodzaak en details nog onderhandeld kan worden; Ze zijn bondig en eenvoudig te lezen, en daardoor begrijpelijk voor ontwikkelaars, belanghebbenden en gebruikers; Ze representeren kleine maar waardevolle delen van de functionaliteit, die binnen enkele dagen tot weken kunnen worden gerealiseerd; Door hun geringe grootte is het eenvoudig de hoeveelheid werk die voor ontwerp, bouw en ontwikkeling nodig is te schatten; Ze zijn niet ondergebracht in grote onhandelbare documenten, maar opgenomen in lijsten, waardoor herschikking op basis van nieuwe inzichten makkelijker is; Ze zijn bij aanvang van het project nog niet gedetailleerd vastgelegd, maar worden via een 'just in time' methode uitgewerkt. Hierdoor wordt vertraging van het project vermeden, het beheer van de requirements vereenvoudigd, en voorkomen dat er te veel constraints in het ontwerp worden ingebouwd; Ze hebben weinig onderhoud nodig, en kunnen na implementatie worden afgevoerd. De user stories en de daaruitvolgende programmacode zijn input voor de documentatie, die daardoor incrementeel groeit. 2.5 Voorbeelden van user stories. Onderstaand enkele voorbeelden van user stories: Als klant wil ik de beoordelingen van een geselecteerd boek lezen zodat ik beter kan beslissen of ik het boek wil kopen. Al student wil ik mijn cijfers online bekijken zodat ik sneller weet of ik het examen heb gehaald. Als sollicitant wil ik mijn CV op de vacaturesite publiceren zodat ik hopelijk benaderd wordt door geïnteresseerde werkgevers.

6 Organisatie SYSQA B.V. Pagina 6 van 9 3 Eisen te stellen aan User Stories De eisen waaraan User Stories dienen te voldoen zijn gevangen in het Engelse acroniem INVEST. I N V E S T Independent (Onafhankelijk) Negotiable (Onderhandelbaar) Value (Waarde) Estimable (Inschatbaar) Small (Klein) Testable (Testbaar) Stories moeten zo veel mogelijk los van elkaar staan. Immers, hoe onafhankelijker ze van elkaar zijn hoe makkelijker het is om de prioriteiten tussen stories te wijzigen. Dit is soms lastig, maar op te lossen door maar soms kun je dit oplossen door de story te splitsen of twee stories juist te combineren. De beschrijving van de story moet het mogelijk maken tijdens de bouw discussie te voeren over de beschreven requirements. Stories zijn geen vervanging van het functioneel ontwerp, maar te zien als referentiepunt, om tijdens de bouw samen met de product eigenaar de details uit te werken. Userstories die functioneel helemaal afgerond zijn, kunnen de impressie wekken dat er geen discussie meer nodig of mogelijk is, terwijl dat nou juist de essentie is van user stories. De user story moet toegevoegde waarde hebben gezien vanuit de business. Een voorbeeld hiervan is wederom de eerder genoemde productcatalogus. Alleen het scherm voor het opvoeren van producten heeft geen business waarde. Immers, zolang een potentiële klant die producten nog niet kan bekijken heb je daar weinig aan. Beide schermen volledig realiseren is ook geen optie omdat dat mogelijk te lang kan duren. Maar voor de product eigenaar zou het voldoende kunnen zijn als de klant in een eerste versie alleen nog een beschrijving en een prijs kan zien. De mogelijkheid om er een foto bij te plaatsen zou wellicht in de volgende versie gebouwd kunnen worden, en is dus een aparte user story. Helaas is deze manier van opsplitsen niet zonder gevaar, dus is het zaak om samen met de product eigenaar te bekijken wanneer een story nog toegevoegde waarde heeft. Elke story dient estimable oftewel inschatbaar te zijn. Zodra je merkt dat het moeilijk is om de omvang van een user story te schatten, dan is het waarschijnlijk dat de scope van die story te groot is. Overigens mogen de schattingen voor stories die in een vroeg stadium van het project worden opgesteld nog best grof zijn. Pogingen hier een gedetailleerde schatting aan te hangen creëeren de illusie dat alle belangrijke aspecten bekend waren ten tijde van de schatting. Dit is echter zelden het geval. Het is veel belangrijker om later met alle kennis en ervaring die dan beschikbaar is een realistischer schatting te maken. Een belangrijk middel of te zorgen dat user stories schatbaar zijn is door ze klein (Small) te houden. Een goed voorbeeld: iemand in het team vragen een schatting te geven van de hoeveelheid werk voor een redelijk grote story. Als hij/zij deze vraag beantwoordt met: "Ehm, iets van een maandje of zo", dan kun je er vergif op innemen dat de ontwikkelaar nog helemaal geen beeld heeft van de inhoud en de scope van die story. In zo'n geval is het verstandig om te proberen deze story op te splitsen in een aantal kleinere stories met business value en een beperkte scope. Een user story moet voorzien zijn van een aantal meetbare criteria waarmee ondubbelzinnig bepaald kan worden of de interpretatie van het team overeenkomt met de story zoals die door de product eigenaar bedoeld was. Omdat de product eigenaar het resultaat natuurlijk nog niet gezien heeft, krijg je dit niet makkelijk boven water. Maar een hulpmiddel kan zijn te vragen hoe product eigenaar de gewenste functionaliteit zou demonstreren aan andere gebruikers. Dit wordt ook wel de how-to-demo van een story genoemd.

7 Organisatie SYSQA B.V. Pagina 7 van 9 4 Hoe User Stories te gebruiken? 4.1 Waar begin je? Stel dat je na veel overleg een lijst van user stories hebt en je begint met het realiseren van een nieuw systeem. De eerste story zal buiten de gewenste functionaliteit ook het bouwen van het skelet van je architectuur omvatten. Hoe voorkom je dat dit veel te lang duurt 1? Eén van die oplossingen is om in overleg met de product eigenaar een story te definiëren die weliswaar minimale functionaliteit biedt, maar toch toegevoegde waarde voor het project heeft. Zo n story wordt vaak de backbone story genoemd, omdat je daarmee de ruggengraat van je systeem realiseert. Een vaak voorkomend compromis is om de backbone story te gebruiken als proof-of-concept van de gekozen architectuur. Omdat hij daarmee het vertrouwen verkrijgt dat het team in staat is om een dergelijk product te bouwen, zou dat voor de product eigenaar al voldoende toegevoegde waarde kunnen bieden. 4.2 Wanneer is user story succesvol afgerond? Hoe weet je of een user story succesvol is afgerond? Als het goed is conformeren alle stories aan INVEST en zijn ze voorzien van een aantal criteria (de how-to-demo) opgesteld door de product eigenaar. Daarmee is al bepaald of een gerealiseerde story functioneel correct is. Wat dan nog ontbreekt zijn een aantal afspraken zodat alle stakeholders, inclusief de product eigenaar, weten wanneer het team vindt dat de story af is. Wat dat precies inhoudt kan per team wisselen, maar meestal worden meerdere van de onderstaande criteria aangehouden. De code compileert en er zijn geen warnings of errors. De code voldoet aan de coding standards van het project of de organisatie. De code is gereviewed. Alle unit- en integratietesten zijn geslaagd. De Code Analysis van Visual Studio geeft geen waarschuwingen. ReSharper geeft geen meldingen over potentiële fouten (alles is groen ). De dagelijkse integratiebuild heeft succesvol gedraaid. De functionaliteit is getest door een ander lid van het team dan de ontwikkelaar. De oplossing is gecontroleerd aan de hand van een interne checklist. De functionaliteit is getest door een systeemtester. De look-and-feel is gecontroleerd door een medewerker van de afdeling communicatie. Het totaal van die afspraken en de how-to-demo van de story wordt de definition-of-done genoemd. 4.3 User stories en de planning. Stories zijn ook uitstekend geschikt om te gebruiken als eenheid in je planning. In principe hebben Agile projecten geen lange termijn planning en wordt de functionaliteit iteratief gerealiseerd waarbij de prioriteit continu kan worden bijgesteld. Maar in de realiteit, vaak door de omgeving afgedwongen, ontkom je er vaak niet aan om een planning te maken. Hoe los je dat dan op? Vaak worden workshops georganiseerd, waarin met alle stakeholders en met behulp van de use case modellen als context alle stories op papier worden gezet. Daarbij moet je waken dat je niet te veel in de detail treedt. Dat zou alle betrokkenen een vals gevoel van precisie 1 Het artikel Managing the Bootstrap Story van Jennitta Andrea behandelt deze uitdaging in meer detail en biedt een aantal alternatieve oplossingen.

8 Organisatie SYSQA B.V. Pagina 8 van 9 kunnen geven waardoor ze de stories toch als functioneel ontwerp gaan zien. Zijn er brokken functionaliteit waarvan niemand nog precies weet hoe dat zou moeten gaan werken, maak er dan een epic story (user stories, die te groot zijn om in één iteratie te worden geïmplementeerd, en daarom dienen te worden opgesplitst in kleinere user stories die aan de eisen (INVEST) voldoen) van en introduceer een spike (een speciaal type story dat wordt gebruikt om risico s en onzekerheden in een user story of een ander facet van het project weg te werken) om later in het project tijd te reserveren om die epic verder uit te werken. Organiseer daarna een aantal korte meetings met het projectteam, of, als dat er nog niet is, met een aantal ervaren ontwikkelaars. Laat hier alle stories de revue passeren en probeer de omvang te schatten in zogenaamde story points. Sommige mensen uit de Agile community zeggen dat je hier alleen relatief moet schatten. Dus een story die gevoelsmatig twee keer zo veel werk is als een andere story moet ook dubbel zoveel story points krijgen. Een uitgangspunt kan zijn dat elke story point overeenkomt met de ideale dag van een ervaren senior software ontwikkelaar. Met andere woorden, één story point betekent dat een ervaren ontwikkelaar die bekend is met de gekozen architectuur, aanpak en technologie 8 uur lang moet werken, zonder gestoord te worden door telefoon, en andere afleidingen 2. Idealiter is elke story tussen de 1 en 8 story points, maar vooral aan het begin van het project kunnen er nog epics zijn die nog niet op te splitsen zijn. Na die meetings heb je een schatting van de totale omvang van het systeem. Om nu tot een aantal uren te komen moet je een schatting maken van de productiviteit van het verwachte team ten opzichte van die ideale senior ontwikkelaar. Mike Cohn doet dit door een tabel te maken met de verwachte rollen, hun inzet, en hun productiviteit in een percentage af te zetten. Het aantal mandagen kun je bepalen door het aantal story points te delen door de gemiddelde productiviteit. Bijvoorbeeld, een team met een gemiddelde van 75% heeft voor 10 story points 10 / 0,75 = 13,5 mandagen nodig. Het resultaat van dit alles is een planning om een vast aantal story points te realiseren. Natuurlijk is het maar een schatting, want zowel de productiviteit kan tegenvallen als de schatting in story points kunnen afwijken, maar het geeft je wel een initiële schatting die gebruikt kan worden voor een globale planning en budgetbesprekingen. Uiteraard is het van belang om te zorgen dat je de daadwerkelijke productiviteit continu blijft meten. 2 Mike Cohn, schrijver van het boek User Stories Applied, heeft hier een groot aantal hoofdstukken aan gewijd.

9 Organisatie SYSQA B.V. Pagina 9 van 9 5 Referenties 1 Ron Jeffries, Essential XP: Card, Conversation, and Confirmation, XP Magazine, August 30, Ivar Jacobson, Object-Oriented Software Engineering (Addison-Wesley, 1992, ISBN ). 3 Alistair Cockburn, Writing Effective Use Cases (Addison-Wesley, 2000, ISBN ). 4 Larry L. Constantine and Lucy A. D. Lockwood, Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design (Addison-Wesley, 1999, ISBN ). 5 IEEE Computer Society, IEEE Recommended Practice for Software Requirements Specifications, John M. Carroll, Making Use: Scenario-Based Design of Human-Computer Interactions (MIT Press, 2000). 7 Adapted from Alan Cooper s The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How To Restore The Sanity (Sams, 1999, ISBN ). 8 Personal communication, November 7, 2003.

De Agile Analist. Ebook over requirements en agile. Deel II

De Agile Analist. Ebook over requirements en agile. Deel II De Agile Analist Ebook over requirements en agile Deel II 2 Inhoud Deel I... 3 1 Inleiding... 3 2 Just in time requirements... 3 3 Just enough requirements... 3 Deel II... 4 4 Samenwerken met de business...

Nadere informatie

Scrum. Een introductie

Scrum. Een introductie Organisatie SYSQA B.V. Pagina 1 van 10 Scrum Een introductie Almere 1999 Proud of it Pagina 1 van 10 Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 Inleiding... 3 2 Scrum... 4 3 Scrum rollen...

Nadere informatie

Cecile Davis & Leo van der Aalst cecile.davis@sogeti.nl & leo.vander.aalst@sogeti.nl

Cecile Davis & Leo van der Aalst cecile.davis@sogeti.nl & leo.vander.aalst@sogeti.nl (fr)agile Balance Cecile Davis & Leo van der Aalst cecile.davis@sogeti.nl & leo.vander.aalst@sogeti.nl Voorstelronde Naam Organisatie Ervaring met testen in agile omgevingen Verwachting 2 Agenda 09:30

Nadere informatie

Scrum bij Hosting. Philippus Baalman

Scrum bij Hosting. Philippus Baalman Scrum bij Hosting Philippus Baalman TriMM Projecten 2012 ontwikkelaars (vanuit de strategie) TriMM ontwikkelmethode introduceren op basis van Scrum Werkwijze Welkom Scrum by Hosting 10 december 2014 Sprint

Nadere informatie

Agile bij grote administratieve systemen. Omgaan met requirements

Agile bij grote administratieve systemen. Omgaan met requirements Agile bij grote administratieve systemen Omgaan met requirements 1 Agenda Wat is een groot systeem? Aanpak van een groot systeem Agile alignment Agile en requirements (en architectuur) Agile en governance

Nadere informatie

Evo Evolutionary Project Management. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Evo Evolutionary Project Management. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Evo Evolutionary Project Management Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. INLEIDING... 3 2. EVO... 4 3. FASERING...

Nadere informatie

XP Extreme Programming. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

XP Extreme Programming. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. XP Extreme Programming Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. INLEIDING...3 2. EXTREME PROGRAMMING...4 3. FASERING...5

Nadere informatie

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil eagileagileagileagileagileagileagileagi leagileagileagileagileagileagileagileag

Nadere informatie

Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Unified Process Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding... 3 2. Unified Process... 4 3. Fasering... 5 3.1.

Nadere informatie

1. De watervalmethode... 2. 2. Agile softwareontwikkeling... 2. 3. Iteratief werken... 3. 4. Agile technieken voor teams... 3

1. De watervalmethode... 2. 2. Agile softwareontwikkeling... 2. 3. Iteratief werken... 3. 4. Agile technieken voor teams... 3 Naar Voren: Tijdschrift voor webwerkers» Artikel #155 Agile (web)ontwikkeling Omarm de verandering Als ICT-professional heb je het liefst dat de klant exact weet wat hij wil, dat jij exact weet hoe je

Nadere informatie

Agile systeemontwikkeling. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Agile systeemontwikkeling. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Agile systeemontwikkeling Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding... 3 2. Terminologie... 4 3. Uitgangspunten...

Nadere informatie

Informatica 2 Studiehandleiding

Informatica 2 Studiehandleiding Informatica 2 Studiehandleiding Embedded Systems Engineering Groep: ES1D ir drs E.J Boks 25-02-2010 Inhoud 1 Inleiding... 2 2 Doelstelling... 3 3 Beoordeling... 4 4 Eisen aan het verslag... 6 Voorbeeld

Nadere informatie

De Agile Analist. Ebook over requirements en agile. Deel I

De Agile Analist. Ebook over requirements en agile. Deel I De Agile Analist Ebook over requirements en agile Deel I 2 Inhoud Deel I... 3 1 Inleiding... 3 1.1 Voor welk type projecten is Scrum geschikt?... 3 1.1.1 Empirische procesbesturing... 4 1.2 Agile werkt

Nadere informatie

Wie ben ik? Agile Software Development. Het waterval model. Inhoud

Wie ben ik? Agile Software Development. Het waterval model. Inhoud gile Software Development Februari 2008, Philippe Dirkse Wie ben ik? 2002: fgestudeerd TU/e 1999-2005: Mondo izzarro, rystal Interactive, Siemens tea 2005 heden: PTS: Leica Microsystems SES/MiPlaza Inhoud

Nadere informatie

14-9-2015. Scrum in het kort

14-9-2015. Scrum in het kort Les 3 Scrum in het kort Scrum is een agile proces dat het ons mogelijk maakt om de hoogste waarde in de kortste tijd te realiseren. Het maakt het ons mogelijk om snel en regelmatig echt werkende software

Nadere informatie

Titel, samenvatting en biografie

Titel, samenvatting en biografie Titel, samenvatting en biografie \ Peter Wanders De Black Box Dialog methode Voorjaarsevent Testnet: 22 juni 2009 Samenvatting Nog nooit heb ik heb een klant horen zeggen: Enorm vervelend dat het IT project

Nadere informatie

Agile Testen in de praktijk

Agile Testen in de praktijk 1 Agenda 2 Agile Testen in de praktijk Summerschool 13 Juli 2011 Introductie Agile de context van agile Testen2.0 de tester in een agile project Waarden en principes DoD, PRA en MTP Testen3.0 in een agile

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren November 2014 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 1 Inhoudstafel 1 Introductie 3 1.1

Nadere informatie

WHITEPAPER IN 5 MINUTEN. 11. Scrum

WHITEPAPER IN 5 MINUTEN. 11. Scrum WHITEPAPER IN 5 MINUTEN A U G U S T U S 2 0 1 4 11. Scrum Deze whitepaper gaat over Scrum. Kort en bondig: Scrum is een software-ontwikkelmethode met vaste sprints van enkele weken waarin steeds een verbeterde

Nadere informatie

RAD Rapid application development. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

RAD Rapid application development. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. RAD Rapid application development Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER...

Nadere informatie

bedrijfsprocessen en vormt daarmee de kapstok voor de producten van andere disciplines. Het PAM is geen RUP concept.

bedrijfsprocessen en vormt daarmee de kapstok voor de producten van andere disciplines. Het PAM is geen RUP concept. 1. 1.1. Inleiding Doel De Requirementdiscipline richt zich op het vaststellen en vastleggen van de eisen en wensen die aan een oplossing worden gesteld: de requirements. Rollen De keyrol binnen deze discipline

Nadere informatie

Software Test Documentation

Software Test Documentation FACULTEIT INGENIEURSWETENSCHAPPEN & WE- TENSCHAPPEN DEPARTMENT OF COMPUTER SCIENCE AND APPLIED COMPUTER SCIENCE Software Test Documentation Software Engineering Nicolas Carraggi, Youri Coppens, Christophe

Nadere informatie

BDD/Gherkin. Een introductie

BDD/Gherkin. Een introductie BDD/Gherkin Een introductie Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding... 3 2. BDD... 4 3. Gherkin... 5 4. BDD-Tools... 6 5. Voordelen... 7 6. Benodigde kennis en vaardigheden...

Nadere informatie

WHITE PAPER. Agile/Scrum

WHITE PAPER. Agile/Scrum WHITE PAPER Agile/Scrum Belangrijkste kenmerk van Scrum is de ontwikkeling via een serie van korte - iteraties, in Scrum terminologie sprints genoemd. Introductie Heel in het kort gezegd is Scrum een Agile

Nadere informatie

Tmap Dag 2015. Ik test, jij test, wij testen. Testen binnen een Wendbare Belastingdienst. 29 september 2015. Laurens Kremer

Tmap Dag 2015. Ik test, jij test, wij testen. Testen binnen een Wendbare Belastingdienst. 29 september 2015. Laurens Kremer Tmap Dag 2015 Ik test, jij test, wij testen Testen binnen een Wendbare Belastingdienst 29 september 2015 Laurens Kremer Introductie Naam: Laurens Kremer, SPC, CISA Rol: Agile coach Informatie Management

Nadere informatie

EXIN Agile Scrum Foundation

EXIN Agile Scrum Foundation Voorbeeldexamen EXIN Agile Scrum Foundation Editie april 2014 Copyright 2014 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored in a data processing system

Nadere informatie

Software Project Management Plan

Software Project Management Plan Software Project Management Plan GameTrac Versie Datum Auteur(s) Opmerking 0.1 3/11/2010 Brecht Van Laethem 1 Door hieronder te tekenen verklaart u akkoord te zijn met dit document en zijn inhoud. Het

Nadere informatie

Plan van Aanpak. project Tetris Packing

Plan van Aanpak. project Tetris Packing Plan van Aanpak project Tetris Packing Inleiding! 4 Projectomschrijving! 5 Producten! 5 Testplan! 5 Ontwerprapport! 5 Implementatierapport! 5 Testrapport! 5 Systeemdocumentatie! 5 Aanpak! 6 Projectmethodiek!

Nadere informatie

MDA in de praktijk. Freek Bosch, Business Unit Manager Amsterdam, 4 juni 2009

MDA in de praktijk. Freek Bosch, Business Unit Manager Amsterdam, 4 juni 2009 Functional Model Driven Development MDA in de praktijk Freek Bosch, Business Unit Manager Amsterdam, 4 juni 2009 FMDD agenda FMDD Waarom FMMD De praktijk Wat is FMDD Ervaringen en lessons learned Ervaringen

Nadere informatie

Agile, Scrum en Kanban in de praktijk

Agile, Scrum en Kanban in de praktijk Agile, Scrum en Kanban in de praktijk Wat is agile en wat kenmerkt agile projecten? Agile in de praktijk: rollen, teams en best practices Hoe om te gaan met requirements in agile projecten? Hoe agile projecten

Nadere informatie

TFS als perfecte tool voor Scrum

TFS als perfecte tool voor Scrum TFS als perfecte tool voor Scrum René van Osnabrugge renevo@delta-n.nl About me René van Osnabrugge Communicate @renevo renevo@delta-n.nl http://osnabrugge.wordpress.com Agenda Wat is Scrum? Wat is ALM

Nadere informatie

Verzamelde vragen en antwoorden Agile Applicatie ontwikkeling. Agile Methodiek en Technologie. Zest Application Professionals

Verzamelde vragen en antwoorden Agile Applicatie ontwikkeling. Agile Methodiek en Technologie. Zest Application Professionals Verzamelde vragen en antwoorden Agile Applicatie ontwikkeling Agile Methodiek en Technologie Zest Application Professionals Hoe is de aansluiting op ontwikkelmethoden voor Legacy-systemen? Out of the Box

Nadere informatie

Summary report. Time entries. Users 2015-09-01-2015-10-07. Luc Schols 112:52:38. Other 545:11:53. Rasjaad Basarat 112:30:08. Jesse Baas 108:26:26

Summary report. Time entries. Users 2015-09-01-2015-10-07. Luc Schols 112:52:38. Other 545:11:53. Rasjaad Basarat 112:30:08. Jesse Baas 108:26:26 Summary report 2015-09-01-2015-10-07 Total 545 h 11 min 109:00 113:30 100:59 96:00 114 h 80:45 86 h 44:56 57 h 29 h 31.08 07.09 14.09 21.09 28.09 05.10 Users Time entries Luc Schols 112:52:38 Other 545:11:53

Nadere informatie

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe SPIDER werkgroep Requirements Management Subwerkgroep Methoden Toelichting inhoud en voortgang tot nu toe donderdag 17 januari 2008 Frans van Veen Bert Dubbelman Robert van Lieshout Erwin Bolwidt Jan-Willem

Nadere informatie

Scrum. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Scrum. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Scrum Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 INLEIDING... 3 2 SCRUM... 4 3 FASERING... 5 4 KENMERKEN... 6 4.1 DE SCRUM-MEETING...

Nadere informatie

Use-Case 2.0. Requirements Kenniscentrum 15 November 2012. Eric Lopes Cardozo elcardozo@ivarjacobson.com

Use-Case 2.0. Requirements Kenniscentrum 15 November 2012. Eric Lopes Cardozo elcardozo@ivarjacobson.com Use-Case 2.0 Requirements Kenniscentrum 15 November 2012 Eric Lopes Cardozo elcardozo@ivarjacobson.com Agenda Use cases: Een korte geschiedenis Waarom nog steeds use cases gebruiken? Waarom Use-Case 2.0?

Nadere informatie

Vereenvoudigd sjabloon requirementsdocument. <>

Vereenvoudigd sjabloon requirementsdocument. <<Organisatie>> Vereenvoudigd sjabloon requirementsdocument SYSQA B.V. Almere Versie : Datum : Status : Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van

Nadere informatie

Software Quality Assurance Plan

Software Quality Assurance Plan FACULTEIT WETENSCHAPPEN Software Quality Assurance Plan Software Engineering groep 3 Jeroen Van den haute Versie Datum Auteur Commentaar 0.1 09/11/2010 Jeroen Van den haute Eerste versie 0.2 12/11/2010

Nadere informatie

Zest Application Professionals Training &Workshops

Zest Application Professionals Training &Workshops De requirements trainingen van Zest Application Professionals geven u de handvatten die nodig zijn om uw requirementsproces te verbeteren. U doet hands-on ervaring op en leert omgaan met lastige praktijksituaties.

Nadere informatie

Op de computer kan naar eigen inzicht software op worden geïnstalleerd, een andere besturingssysteem is mogelijk.

Op de computer kan naar eigen inzicht software op worden geïnstalleerd, een andere besturingssysteem is mogelijk. Planningsfase 1. Afspraken maken over doelstelling en randvoorwaarden De doelstelling van het project: De doelstelling van het project: het maken van het gewenste product. De doelstelling van de student:

Nadere informatie

Agile testen - kwaliteit onder controle

Agile testen - kwaliteit onder controle Agile testen - kwaliteit onder controle Marc Evers Piecemeal Growth Anko Tijman Ordina TestNet 16 maart 2006 www.testnet.org Agenda Wat betekent agile en agile testen Kwaliteitsborging in agile projecten

Nadere informatie

Ontwikkelmethoden en technieken. Ontwikkelmethoden & Technieken HC 4

Ontwikkelmethoden en technieken. Ontwikkelmethoden & Technieken HC 4 Ontwikkelmethoden en technieken 1 Projectinrichting Ontwikkelmethoden & Technieken HC 34 2 Vandaag Terugblik? Projectinrichting Afsluiting Leestip Introductie/overzicht Week 1 Afbakening Verwachtingen

Nadere informatie

Werkgroep ISO29119. TestNet thema-avond 9 oktober 2014

Werkgroep ISO29119. TestNet thema-avond 9 oktober 2014 Werkgroep ISO29119 TestNet thema-avond 9 oktober 2014 Is dit n gezonde maaltijd? Ja toch!! Om jezelf een oordeel te kunnen vormen heb je informatie nodig!! Vandaag brengen we kennis en informatie bij elkaar

Nadere informatie

Aliens? http://www.youtube.com/watch?v=e5pqleh2hz8

Aliens? http://www.youtube.com/watch?v=e5pqleh2hz8 Aliens? http://www.youtube.com/watch?v=e5pqleh2hz8 Ontwikkelmethoden en technieken Kenmerken van ontwikkelmethoden POMT HC2 2 Vorige week 3 Rollenspel Klant is koning Communicatie en afspraken Documentatie

Nadere informatie

Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken

Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken De business organisatie heeft altijd stijgende verwachtingen van uw IT organisatie. Meer dan ooit is het van

Nadere informatie

Risk & Requirements Based Testing

Risk & Requirements Based Testing Risk & Requirements Based Testing Tycho Schmidt PreSales Consultant, HP 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Agenda Introductie

Nadere informatie

Webtesten onder schaarste

Webtesten onder schaarste Testnet najaarsevenement 2005 B e y o n d t h e o r d i n a r y Webtesten onder schaarste Vincent Staal ORDINA NV Ringwade 1 Postbus 7101 3430 JC Nieuwegein Tel: 030 6637000 Fax: 030 6637099 www.ordina.nl

Nadere informatie

Product Risico Analyse

Product Risico Analyse Product Risico Analyse Jurian van de Laar TestNet Avond 9 oktober 2013 www.improveqs.nl (info@improveqs.nl) Versie 2.0 1 Herkenbaar? In ons testproces wordt product risico analyse toegepast Wij gebruiken

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren Maart 2015 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 2 December 2014 Yannick Verschueren

Nadere informatie

HERGEBRUIK VAN REQUIREMENTS

HERGEBRUIK VAN REQUIREMENTS HERGEBRUIK VAN REQUIREMENTS EEN PRAKTISCHE AANPAK BUSINESS ANALYSE CENTER OF EXCELLENCE - SYNERGIO Inhoudsopgave 1 HERGEBRUIK VAN REQUIREMENTS... 3 1.1 GEBRUIKEN VERSUS HERGEBRUIKEN... 4 2 STRATEGIE...

Nadere informatie

Software Quality Assurance Plan

Software Quality Assurance Plan Software Quality Assurance Plan GameTrac Versie Datum Auteur(s) Opmerking 1.0 10-12-2010 Bram Bruyninckx Eerste iteratie 1 Door hieronder te tekenen verklaart u akkoord te zijn met dit document en zijn

Nadere informatie

Agile werken: zó doen we dat

Agile werken: zó doen we dat Agile werken: zó doen we dat Bij Freshheads werken we graag volgens de Agile aanpak. De voordelen? Verhoogde efficiëntie en flexibiliteit, snellere resultaten en grotere betrokkenheid. Maar hoe gaat het

Nadere informatie

Doe eens gek! Houd rekening met de mensen in uw organisatie bij het implementeren van ICT oplossingen.

Doe eens gek! Houd rekening met de mensen in uw organisatie bij het implementeren van ICT oplossingen. Doe eens gek! Houd rekening met de mensen in uw organisatie bij het implementeren van ICT oplossingen. ERP, CRM, workflowmanagement en documentmanagement systemen, ze hebben één ding gemeen: Veel van de

Nadere informatie

Hoe ver moet je gaan?

Hoe ver moet je gaan? Hoe ver moet je gaan? Requirements verzamelen in agile John Copier; Marcel Steur 8 oktober 2015 Introductie Marcel + Qquest Informatica TU Delft Bedrijfskunde HSA + VU IT combineren met bedrijfskunde Qquest

Nadere informatie

Gewone jongens die mooie dingen maken. Wat we doen en hoe we het doen

Gewone jongens die mooie dingen maken. Wat we doen en hoe we het doen Gewone jongens die mooie dingen maken Wat we doen en hoe we het doen Wij zijn studio fonkel Wij zijn Studio Fonkel en wij maken mooie dingen. Of het nu gaat om een website, webapplicatie, landkaart of

Nadere informatie

Agile in Projecten minimalisme of strak pak? Richard Weber PMP

Agile in Projecten minimalisme of strak pak? Richard Weber PMP Agile in Projecten minimalisme of strak pak? Richard Weber PMP De Spreker Richard Weber Directeur & oprichter Adviseur & coach Projectmanagement Profile Dynamics ICT & Bedrijfskundige achtergrond Trainer

Nadere informatie

Een website ontwerpen met agile design en scrum, wat heb je nodig?

Een website ontwerpen met agile design en scrum, wat heb je nodig? Een website ontwerpen met agile design en scrum, wat heb je nodig? door admin - 03-19-2012 http://www.itpedia.nl/2012/03/19/een-website-ontwerpen-met-agile-design-en-scrum-wat-heb-je-nodig/ Door Pieter

Nadere informatie

Ontwikkelmethoden en technieken. Ontwikkelmethoden & Technieken HC 2

Ontwikkelmethoden en technieken. Ontwikkelmethoden & Technieken HC 2 Ontwikkelmethoden en technieken 1 Vandaag Een kleine geschiedenis (vervolg) Klein stukje XP Afbakening verwachtingen 2 Werkwijze theorie Lesstof Presentaties Boek Aantekeningen Introductie/overzicht Week

Nadere informatie

Business Case. <>

Business Case. <<Naam project>> Business Case SYSQA B.V. Almere Versie : Datum : Status : Opgesteld door : Pagina 2 van 8 Inhoudsopgave 1 Inleiding... 1.1 Doel van dit document...

Nadere informatie

Auditen van Agile projecten

Auditen van Agile projecten Auditen van Agile projecten Platform voor Informatiebeveiliging 10 december 2013 Merijn van der Zalm & Marcel Trijssenaar Agenda Belang van assurance op agile ontwikkelen Agile versus Waterval Perspectief

Nadere informatie

B.Sc. Informatica Module 4: Data & Informatie

B.Sc. Informatica Module 4: Data & Informatie B.Sc. Informatica Module 4: Data & Informatie Djoerd Hiemstra, Klaas Sikkel, Luís Ferreira Pires, Maurice van Keulen, en Jan Kamphuis 1 Inleiding Studenten hebben in modules 1 en 2 geleerd om moeilijke

Nadere informatie

Scoren met je project Projectmatig werken mag géén last zijn!

Scoren met je project Projectmatig werken mag géén last zijn! blauw Scoren met je project Projectmatig werken mag géén last zijn! Ives De Saeger 17/11/2015 1 scoren met project Doel van deze sessie blauw Inzichten in hoe te scoren met project. Geleerde direct toepassen

Nadere informatie

Introductie Use Case Point Analyse. SYSQA B.V. Almere

Introductie Use Case Point Analyse. SYSQA B.V. Almere Introductie Use Case Point Analyse SYSQA B.V. Almere Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1 Managementsamenvatting... 3 2 Inleiding... 4 3 Use Case Points... 5 3.1 Geschiedenis van de Use

Nadere informatie

Agile ervaring Ir.ing. Erik van Daalen

Agile ervaring Ir.ing. Erik van Daalen Agile ervaring Ir.ing. Erik van Daalen Eneco Rotterdam 3 december 2013 03-12-2013 Agile Erik van Daalen 1 Hoofdsponsor Sponsors IPMA-N Jaarsponsors 03-12-2013 Agile Erik van Daalen 2 Korte introductie

Nadere informatie

Project methodiek. Auxilium BV Oude Delft 48 2611 CD Delft. T: 015-261 23 16 F: 015-213 34 83 E: info@auxilium.nl

Project methodiek. Auxilium BV Oude Delft 48 2611 CD Delft. T: 015-261 23 16 F: 015-213 34 83 E: info@auxilium.nl Project methodiek Auxilium BV Oude Delft 48 2611 CD Delft T: 015-261 23 16 F: 015-213 34 83 E: info@auxilium.nl Inhoud 1 PROJECTMETHODIEK... 3 1.1 TIME-BOXING... 3 1.2 USER-STORIES EN STORY-POINTS... 3

Nadere informatie

Ontwikkelmethoden en technieken DSDM POMT HC3

Ontwikkelmethoden en technieken DSDM POMT HC3 DSDM Ontwikkelmethoden en technieken DSDM POMT HC3 HC WG rollenspel praktijktoets 1 praktijktoets 2 praktijktoets 3 Mei week 1 week 2 week 3 Week 4 vakantie Inleiding Ontwikkel methodiek DSDM Technieken

Nadere informatie

fantestische middag 7 Agile en SCRUM

fantestische middag 7 Agile en SCRUM fantestische middag 7 Agile en SCRUM fantestische middag 7 - Copyright Improve Quality Services Bart Bouwers RISK BASED TESTING & SCRUM: RISK POKER Bart Bouwers Topics Productkwaliteit Productrisico het

Nadere informatie

Plan van Aanpak. project Tetris Packing. Groep: eii7aab. Geert Weening Mark Rietveld Ron Talman Ingmar te Raa Leander Nijland Daniël van Cleef

Plan van Aanpak. project Tetris Packing. Groep: eii7aab. Geert Weening Mark Rietveld Ron Talman Ingmar te Raa Leander Nijland Daniël van Cleef Plan van Aanpak project Tetris Packing Groep: eii7aab Geert Weening Mark Rietveld Ron Talman Ingmar te Raa Leander Nijland Daniël van Cleef Versie: 1.0 Inleiding 4 Projectomschrijving 5 Doel van het project

Nadere informatie

De Agile Analist. Henk Jan Huizer

De Agile Analist. Henk Jan Huizer De Agile Analist Henk Jan Huizer Software Ontwikkeling Dat is Software Ontwikkeling is Voor veel organisaties van steeds grote belang! Agile Software ontwikkeling Is een aanpak die past bij het type werk

Nadere informatie

De overstap naar Agile De overstap naar Agile

De overstap naar Agile De overstap naar Agile De overstap naar Agile De overstap naar Agile Wat als niet alleen de requirements veranderen, maar alles verandert? Inleiding Start project met waterval aanpak Overstap naar agile Hoe hebben we het gedaan?

Nadere informatie

Testen. Presentatie. Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2

Testen. Presentatie. Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2 Testen Presentatie Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2 Algemeen Tegenwoordig behoeft het belang van testen nauwelijks nog te worden uitgelegd. Binnen organisaties speelt

Nadere informatie

Introductie. Hoofdstuk 1. 1.1 Over softwareontwikkeling

Introductie. Hoofdstuk 1. 1.1 Over softwareontwikkeling Hoofdstuk 1 Introductie 1.1 Over softwareontwikkeling In de meeste gevallen zijn er veel mensen betrokken bij de ontwikkeling van software: niet alleen de klant die de opdrachtgever is en de programmeurs

Nadere informatie

Testen binnen agile methoden Anko Tijman

Testen binnen agile methoden Anko Tijman Testen binnen agile methoden Anko Tijman Introductie sinds 1997 in software testen testcoördinator Van Meijel Automatisering verbeterproces aansluiten bij extreme Programming agile proces 2 Testen binnen

Nadere informatie

Scrum. Veranderingen. Product development of product manufacturing?

Scrum. Veranderingen. Product development of product manufacturing? Scrum Nu op veel plekken de Oracle Developer en Designer ontwikkelstraat aangevuld wordt met, en steeds vaker zelfs vervangen wordt door JDeveloper, komt vaak de vraag naar boven welke project management

Nadere informatie

Business Sprint LOOT-scholen en Zo.Leer.Ik in kader van project Leerling 2020. Door Madelief Keyser en Michael van Wetering

Business Sprint LOOT-scholen en Zo.Leer.Ik in kader van project Leerling 2020. Door Madelief Keyser en Michael van Wetering Business Sprint LOOT-scholen en Zo.Leer.Ik in kader van project Leerling 2020 Door Madelief Keyser en Michael van Wetering Aanleiding Business Sprints Inzicht krijgen in behoeftes van nieuwe onderwijsconcepten

Nadere informatie

Stichting NIOC en de NIOC kennisbank

Stichting NIOC en de NIOC kennisbank Stichting NIOC Stichting NIOC en de NIOC kennisbank Stichting NIOC (www.nioc.nl) stelt zich conform zijn statuten tot doel: het realiseren van congressen over informatica onderwijs en voorts al hetgeen

Nadere informatie

Richtlijnen voor het ontwerpen een Intranetportal Door Bas Fockens

Richtlijnen voor het ontwerpen een Intranetportal Door Bas Fockens Richtlijnen voor het ontwerpen een Intranetportal Door Bas Fockens Copyright Datacon www.datacon.nl Wat is een intranetportal? Een intranet is een online gepersonaliseerde en geïntegreerde toegang tot

Nadere informatie

Software Test Document

Software Test Document Software Test Document PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie

Nadere informatie

VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER

VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER Sander Hoogendoorn Versie 1.0 15 april 2002 Documentbeheer Versie Datum Auteur Omschrijving 0.1 15 April 2002 Sander Hoogendoorn 0.2 15 april

Nadere informatie

Riskpoker - Confirmation - Planningpoker. Opfrissing TMap NEXT in scrum en toelichting op de opdracht Leo van der Aalst - Jos Punter - Hans Lantink

Riskpoker - Confirmation - Planningpoker. Opfrissing TMap NEXT in scrum en toelichting op de opdracht Leo van der Aalst - Jos Punter - Hans Lantink Riskpoker - Confirmation - Planningpoker 10-7-2013 Opfrissing TMap NEXT in scrum en toelichting op de opdracht Leo van der Aalst - Jos Punter - Hans Lantink 1 Presentatie (sprint) backlog items 1 2 3 4

Nadere informatie

De tester als bruggenbouwer

De tester als bruggenbouwer De tester als bruggenbouwer Tim Koomen Testnet voorjaarsevenement 9 juni 2004 Agenda Bruggen Enkele bruggen toegelicht De bruggenbouwer Trends Sogeti Nederland B.V. Pagina 1 Bruggen Systeem Beheer Stuur

Nadere informatie

TESTAUTOMATISERING IN EEN ETL-OMGEVING

TESTAUTOMATISERING IN EEN ETL-OMGEVING Pagina 21 TESTAUTOMATISERING IN EEN ETL-OMGEVING Door John Kronenberg John.Kronenberg@bartosz.nl @johnkronenberg Edward Crain Edward.crain@divetro.nl Welke groeifasen werden doorlopen in testautomatisering

Nadere informatie

Software Project Management Plan

Software Project Management Plan Software Project Management Plan GameTrac Versie Datum Auteur(s) Opmerking 0.1 3/11/2010 Brecht Van Laethem Eerste versie voor klant 1.0 27/11/2010 Brecht Van Laethem Aanbrengen verduidelijkingen + toevoegen

Nadere informatie

Leiderschap in een organisatie met technische professionals

Leiderschap in een organisatie met technische professionals Quintor Leiderschap in een organisatie met technische professionals Johan Tillema CEO Quintor Professionele softwareontwikkeling ICT Architectuur Java,.NET en Mobile Informatieanalyse Opgericht in 2005

Nadere informatie

RUM. requirements Management. SPIder session Project. driven by requirements 25th april. Risk assessed User

RUM. requirements Management. SPIder session Project. driven by requirements 25th april. Risk assessed User RUM Risk assessed User requirements Management - SPIder session Project driven by requirements 25th april Copyright 2006 ps_testware - Gijs Kuiper Risk assessed User requirement Management Personalia Gijs

Nadere informatie

Testgedreven ontwikkeling dat is pas veilig!

Testgedreven ontwikkeling dat is pas veilig! Testgedreven ontwikkeling dat is pas veilig! INTRODUCTIE ANKO TIJMAN 2 Software tester sinds 1997 (TMap, ISEB Practitioner) Eerste agile ervaring in 2001 Presentaties op (inter)nationale congressen Nov

Nadere informatie

Software Test Plan. PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015

Software Test Plan. PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Software Test Plan PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie 1 Versie

Nadere informatie

Scrum: where Business drives IT

Scrum: where Business drives IT Scrum: where Business drives IT De simpelste oplossingen zijn meestal de beste Nu op veel plekken de Oracle Developer en Designer ontwikkelstraat aangevuld wordt met, of vervangen wordt door JDeveloper,

Nadere informatie

Agile buiten de IT. Bent u al onbewust bekwaam met agile? Bert Leibbrand bert.leibbrand@itri.nl +31 6 27 74 60 88

Agile buiten de IT. Bent u al onbewust bekwaam met agile? Bert Leibbrand bert.leibbrand@itri.nl +31 6 27 74 60 88 Agile buiten de IT Bent u al onbewust bekwaam met agile? Bert Leibbrand bert.leibbrand@itri.nl +31 6 27 74 60 88 Agenda Overzicht Agile: een hype? Agile termen Planningpoker: zelf ervaren Samenvatten Volgende

Nadere informatie

Test rapportage Waarom eigenlijk?

Test rapportage Waarom eigenlijk? Testrapportage Boodschappers van de koning? Test rapportage Waarom eigenlijk? TestNet voorjaarsevenement 2015 Jurian van de Laar Jurian van de Laar @JurianvdL 30 april 2015 @JurianvdL Jurian van de Laar

Nadere informatie

Requirements Traceability. Marcel de Baas, Jan Bank, Edwin Buisman, Frits Jacobs, Kitty Spaas, Erik Venema, Arno Zandman

Requirements Traceability. Marcel de Baas, Jan Bank, Edwin Buisman, Frits Jacobs, Kitty Spaas, Erik Venema, Arno Zandman Requirements Traceability Marcel de Baas, Jan Bank, Edwin Buisman, Frits Jacobs, Kitty Spaas, Erik Venema, Arno Zandman 22 Mei 2008 Werkgroep Traceability Doel van de werkgroep: Aanbieden van hulpmiddelen

Nadere informatie

Betere dienstverlening financiële organisaties met continuous delivery Flexibeler, efficiënter en in kort tijdsbestek software ontwikkelen

Betere dienstverlening financiële organisaties met continuous delivery Flexibeler, efficiënter en in kort tijdsbestek software ontwikkelen Betere dienstverlening financiële organisaties met continuous delivery Flexibeler, efficiënter en in kort tijdsbestek software ontwikkelen Sinds de kredietcrisis en door opkomende technologieën staan banken

Nadere informatie

Software Engineering Groep 3

Software Engineering Groep 3 Software Engineering Groep 3 Post Mortem Review 1 Kristof Van Moffaert (QA Manager) 3 e Bachelor Computerwetenschappen Kristof.Van.Moffaert@vub.ac.be se3@tinf.vub.ac.be 22 februari 2009 Document geschiedenis

Nadere informatie

Cyberpesten: social media platform mining tools

Cyberpesten: social media platform mining tools Cyberpesten: social media platform mining tools ABI team 27: Pascal Pieters, Stephaan Declerck Begeleider: dr. Rik Bos Opdrachtgever: prof. dr. ir. Remko Helms Inhoud Achtergrond Opdracht Projectaanpak

Nadere informatie

Het W-model: de groei naar voren. Jan Jaap Cannegieter. Praktijk van ICT-projecten

Het W-model: de groei naar voren. Jan Jaap Cannegieter. Praktijk van ICT-projecten Het W-model: de groei naar voren Jan Jaap Cannegieter Adjunct Directeur SYSQA B.V. Praktijk van ICT-projecten Req Ontwerp Realisatie Testen Testen Testen 44% van de projecten overschrijdt budget of tijd

Nadere informatie

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces Software Processen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Het software proces Een gestructureerd set van activiteiten nodig om een software systeem te ontwikkelen Specificatie;

Nadere informatie

Ontwikkelen en testen van e-business: beheerste dynamiek

Ontwikkelen en testen van e-business: beheerste dynamiek Ontwikkelen en testen van e-business: beheerste dynamiek Het ontwikkelen en gestructureerd testen van administratieve systemen is gebaseerd het watervalprincipe. Bij het ontwikkelen volgens het watervalprincipe

Nadere informatie

Kwaliteit. 1. Introductie. Deel 1. Algemene Kennis

Kwaliteit. 1. Introductie. Deel 1. Algemene Kennis 1. Introductie Kwaliteit In deze module gaan we iets verder in op het begrip "kwaliteit". Het is de bedoeling om wat achtergrondinformatie te geven die van pas kan komen bij de andere modules. Kwaliteit

Nadere informatie

Business Analyse en User Experience

Business Analyse en User Experience Business Analyse en User Experience Een handreiking voor de Business Analyst Auteur: Marco Theunissen Versie: 1.0 Datum: Januari 2012 Copyright: Marco Theunissen, onder een licentie van Creative Commons

Nadere informatie