Modelgedreven Software Ontwikkeling

Maat: px
Weergave met pagina beginnen:

Download "Modelgedreven Software Ontwikkeling"

Transcriptie

1 Bronvermelding [1] Beck et al. Manifesto for Agile Software Development. [2] Evans Domain Driven Design. Addison Wesley, Boston (2004) Modelgedreven Software Ontwikkeling [3] Wirfs-Brock, McKean. Object Design: Roles, Responsibilities and Collaborations. Addison Wesley, Boston (2003) [4] Martin, Agile Principles, Patterns, and practices in C#. Martin Prentice Hall, Upper Saddle River (2007) [5] Kleppe et al. MDA Explained. Addison Wesley, Boston (2003) [6] Shore, Warden. The Art of Agile Development. O Reilly, Sebastopol (2007) [7] Nilsson Applying Domain-Driven Design and Patterns. Addison Wesley, Boston (2006) [8] Génova et al. Mapping UML Associations into Java code. Journal of Object Technology, ETH Zurich (2003). [9] Cook et al. Domain Specific Development with Visual Studio DSL Tools. Addison Wesley, Boston (2006). [10] André Boonzaaijer 5 oktober

2 Inhoud Inleiding... 3 Modellering... 5 Scoping... 5 Initiele draft... 7 Dive... 8 Interaction Design Planning Architectuur Basisstructuur Layering Componenten Feedback Modellering Ontwikkelstraat Code generatie Source Control Continuous Integration Planning / Work Item Tracking Bijlage 1: Manifesto for Agile Software Development Bronvermelding Bijlage 1: Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice. 2 23

3 Inleiding Softwarebouw is een complexe onderneming. Er is al veel over gezegd en geschreven, en ik pretendeer niet de oplossing voor alle problemen gevonden te hebben. Het onderwerp waar ik in dit werk specifiek op in wil gaan is het neerzetten van een ontwikkelraamwerk met daarbij specifiek de focus op requirementsverzameling en vertaling richting software. Rode draad binnen alle onderwerpen die behandeld worden is het Manifesto for Agile Software Development [1], ook opgenomen in bijlage 1. Alvorens dit boek verder te lezen is het aan te raden om dit door te nemen. Dit verheldert vooraf al waarom bepaalde onderdelen minder expliciet belicht worden. De basis die ik hiervoor gebruik is het door Eric Evans [2] omschreven: Domain Driven Design (DDD). Deze ontwerpmethodiek stelt het te automatiseren probleemdomein centraal in het werken naar een oplossing. Hiertoe wordt gestreefd naar het definiëren van een ubiquitous language een taal die zowel ontwikkelaars als domeindeskundigen begrijpen. Daarnaast wordt het domein omschreven in deze taal als model centraal maar ontkoppeld van techniek in de software opgenomen. Er is in de afgelopen jaren al ontzettend veel geschreven over DDD. In de meeste publicaties op dit gebied ligt de focus vooral op de technische invulling en ontkoppeling van het domeinmodel. In mijn optiek is het probleem om te komen tot een goed domeinmodel een veel interessanter onderwerp. Ik zal dan ook in dit boekje vooral ingaan op het vertalen van domein- of klantspecifieke omschrijvingen, die ik zal aanduiden met Customer Specific Models (CSP s) naar domeinmodellen die ook voor ontwikkelaars begrijpelijk zijn. In het tweede deel zal ik meer ingaan op de vertaling van Domain Model (DM) naar wat ik noem Object Models (OM s). In de meeste publicaties over DDD worden deze als gelijk gezien. Ik trek ze met opzet uit elkaar. Ik vind het bijvoorbeeld niet logisch om met domeindeskundigen te praten over design patterns. Dit zijn wel onderdelen die in (domeinspecifieke) onderdelen van de software terugkomen, bij velen dus ook in het 22 3

4 domeinmodel. Om domeinmodellen echter twee kanten op communiceerbaar te houden mogen deze alleen concepten en constructies bevatten die alle partijen begrijpen. Plan workitems minimaal wekelijks in in een centrale meeting. Zorg ervoor dat iedereen evenveel Must-have en Should-have load heeft, en dat de items ook in die volgorde worden opgepakt. Spreek daarnaast ook duidelijk af wat er met het overige werk uit vorige iteraties gedaan wordt. In principe heeft een nieuwe iteratie een nieuw thema en kan het beter zijn om daarin niet terug te kijken. Als echter de must-haves uit iteratie n-1 niet allen afgekomen zijn kan het noodzakelijk zijn om deze naar het begin van iteratie n te tillen. Een mogelijke oplossing kan zijn om een tusseniteratie te introduceren om het overblijfsel uit een eerdere iteratie op te pakken. Deze kan dan ook korter zijn (misschien maar 1 of 2 dagen) maar dit heeft als voordeel dat je bij je thema blijft. Het laatste deel van dit boekje zal vooral ingaan op een aantal concrete handvatten die ingezet kunnen worden voor het opleveren van software d.w.z. inrichting van acceptatietests, hulpmiddelen voor ontwikkelteams etc. Dit vat ik onder het kopje Ontwikkelstraat. 4 21

5 dat systeem bewerkt worden. Daarnaast is het belangrijk afspraken te maken over: - Communicatie tussen teamgenoten over genomen acties in het versiebeheersysteem - Update en commit je sources minimaal een aantal keren per dag, liefst bij het afronden van elk work item (zie hieronder work item tracking ). - Commit nooit gebroken source code. In veel moderne systemen is het mogelijk om hier regels voor aan te maken (check-in policies) maar zoals alle systemen begint het met het gedrag van de mensen die ermee moeten werken. Continuous Integration Continuous Integration (of kortweg CI) is in de agile ontwikkelstraat niet meer weg te denken. Het betreft in feite een centrale servergebaseerde component die een bepaalde source repository in de gaten houdt op wijzigingen. Op moment dat er dingen gewijzigd zijn wordt door dit component een script uitgevoerd. Dit soort scripts zijn veelal een combinatie van het afvuren van een build van de dan recente sources alsmede het uitvoeren van een aantal unit-tests. Een continuous Integration oplossing is een constante monitor op de kwaliteit van de dan geldende actuele source code en is als zodanig een essentieel onderdeel voor projecten met een korte iteratieperiode. Planning / Work Item Tracking Zowel voor planning vooruit alsmede het kunnen meten van verzet werk is het bijhouden van work items een belangrijk onderdeel. Zoals al eerder is aangegeven onder het hoofdstuk Modellering is het belangrijk dat werk opgeknipt wordt in overzichtelijke brokken en dat hier een prioriteit aan gegeven wordt. Zo kunnen projectleden ook werk aan elkaar toewijzen en op verschillende momenten werken om hun lijstje af te werken zonder dat daar continue discussie en overleg voor nodig is. 20 Modellering Essentieel in het software ontwikkelproces is de afstemming tussen opdrachtgever (ofwel klant ) en opdrachtnemer (ofwel software bouwer ). Eric Evans [2] omschrijft deze afstemming als het creëren van een Ubiquitous Language. Dit is een vorm van werken die mij de afgelopen jaren heeft geïnspireerd; ik heb veel van zijn ideeën nu een aantal keer toegepast. Mijn grote voorkeur gaat uit naar het modelleren van een klantprobleem. Wat we van oudsher onder modelleren verstaan is het kiezen van een bepaalde modelsoort en hiervan een invulling maken voor een specifiek probleem. Ik zie het breder dan dat; ook code schrijven beschouw ik als modelleren. Ik heb hiertoe in het vorige hoofdstuk een cyclus opgenomen met hoe ik over de evolutie van een model nadenk; van klantspecifiek model naar software. UML class diagrammen hebben voor domeinmodellering mijn grote voorkeur. Het domeinmodel is in mijn optiek een vertaling van een omschrijving in klantspecifieke taal naar eentje in een meer generieke taal; hiertoe moet een taal gebruikt worden die meer mensen begrijpen. Of UML nu wel of niet de beste keuze is wil ik graag in het midden laten; feit is dat verreweg het grootste deel van de moderne software engineers UML in ieder geval deels kent vandaar deze keuze. Maar hoe vlieg je het modelgedreven ontwikkelen zoals hij het omschrijft nu aan? Wat komt er allemaal in een domeinmodel terecht, en wellicht nog belangrijker voor velen, wanneer weet ik dat ik mijn model correct heb opgesteld? Ik zal in dit deel proberen een aantal zeer concrete technieken te beschrijven waar je direct mee aan de slag kunt. Scoping Een van de meest belangrijke zaken als je iteratief te werk wilt gaan (met een iteratie bedoel ik één cyclus in het hierboven omschreven cyclisch ontwikkelmodel) het inperken van wat je in een iteratie gaat uitvoeren. Het is echter zeer wenselijk om na iedere iteratie min of meer productieklare software op te leveren. Dit heeft een aantal grote voordelen zoals planbaarheid van tests en dergelijke. Over het hoe en waarom van 5

6 opleveren van werkende software ga ik hier niet verder in, maar diverse bronnen in het gebied van XP [4,6] kunnen hier op nageslagen worden. Productieklare software, hoe kunnen we dat beloven? Belangrijk is om verticale strepen te trekken door de applicatie. Van user interface tot en met database moet alles van de applicatie geraakt worden om dit te bewerkstelligen. Toch is het zo dat er voor welke smalle streep je ook kiest ook andere onderdelen van het systeem geraakt kunnen worden. Denk bijvoorbeeld aan het uitwerken van een orderregistratiemodule; tiemodule; hiervoor is het waarschijnlijk noodzakelijk om een bepaalde minimale kennis en/of implementatie in het systeem te hebben van concepten als klant of product. Een grafische weergave van de impact van een iteratie op de modelleringactiviteiten heb ik hieronder weergegeven. Voor een iteratie is het belangrijk om op hoog abstractieniveau met een groter aantal concepten bezig te zijn die geraakt worden door de daadwerkelijk relevante concepten. De meest relevante concepten worden wel tot op het laagste abstractieniveau uitgewerkt. Ontwikkelstraat Zodra er meer dan één ontwikkelaar aan een project komt te werken zijn een aantal (server side) onderdelen in een ontwikkelstraat onontbeerlijk. Daarnaast kan het bij teams met maar één ontwikkelaar wel degelijk meerwaarde hebben om deze onderdelen in te vullen (denk aan standaardisering en opschalen van de projectgrootte). Het is echter in de dagelijkse werkzaamheden minder van toepassing. Binnen de in dit boekje gepresenteerde werkwijze gaan we eigenlijk standaard uit van meerdere ontwikkelaars in een team; de hieronder genoemde onderdelen zijn dus eigenlijk standaard aanwezig in elke ontwikkelstraat. Code generatie De modelleringscyclus die hier wordt voorgesteld impliceert een vorm van model lifecycle management die zeer gebaat zou kunnen zijn bij (gedeeltelijke) code generatie. Het model wordt beschouwd als een centraal punt van definitie (in welke vorm dan ook UML ligt in mijn optiek het meest voor de hand). Vervolgens is het wenselijk om bepaalde aspecten van een model (associaties tussen modelclasses, koppelvlakken met omringende componenten) te kunnen genereren en synchroniseren met het model. <<Verder uitwerken [9]>> Source Control Een standaard plaats om sources te beheren als subversion (svn) of Team Foundation Server (TFS) komen meer en meer voor in software onwtikkelstraten. Er zijn talrijke open source en gratis alternatieven als Visual SVN of Tortoise SVN, dus voor de investeringskosten hoeft het niet gelaten te worden. Het verdient aanbeveling om voor een dergelijk systeem in gebruik te nemen bewustwording te kweken in het team en standaarden af te spreken voor inchecken en uitchecken van sources. Het uitdiepen van een bepaald smal stuk van het model duid ik ook wel aan als het nemen van een dive. De scoping van de modelleringactiviteiten te Werken in een sourcecontrolsysteem vereist een minimale mindshift; sources die in een dergelijk systeem beheerd worden moeten ook altijd via 6 19

7 2. Validatielogica definieren / implementeren 3. Generatie / implementatie objectmodel equivalent a. Inpassen binnen toegepaste design patterns b. Schrijven unit tests 4. Ontsluiting richting servicelaag 5. Aansluiten nieuwe servicelaag op UI 6. Mappen object richting database 7. Analyse richting overige componenten Heel plat en concreet kan bij elke mutatie van het domeinmodel de bovenstaande development workflow uitgevoerd worden. Het is aan te bevelen om de meest voorkomende mutaties in dit soort workflows vast te leggen. Veel meer dan bovenstaand stappenplan hoeft het niet te zijn. Door het echter op deze manier vast te leggen is uitbreiding van bestaande applicaties ineens een stuk beter over te dragen aan anderen. nemen in één iteratie zijn dus onder te verdelen in twee onderdelen die ik nu zal behandelen. Initiele draft Het brede ondiepe stuk in het bovenstaande T-model stellen we samen in een model dat ik aanduid met initiele draft. Dit model bevat de concepten die relevant zijn met bijbehorende definities en een aanzet van hun onderlinge relaties. In feite is dit dus de start van het eerder omschreven DM. Hoe kom je nu echter concreet op een dergelijk DM? Een veel gebruikte techniek is het zoeken naar zelfstandig naamwoorden. Hier is zeker een basis mee te leggen. Concreet gezegd kan de klant in eerste instantie vertellen wat het probleemdomein inhoudt; wie zijn betrokken, wat zijn de taken of doelen van de betrokkenen en hoe hangt dit alles samen. Een techniek die ik zelf graag toepas in dit soort sessies is notuleren op postits tijdens de uitleg schrijft één van de mensen alle (significante) zelfstandig naamwoorden met een eventuele korte definitie op één post-it per stuk. Na deze eerste verkennende gesprekken hebben we dus al een fysieke delivery; een stapel post-its. Uiteraard is dit een vrij onsamenhangend geheel; het zou zelfs zo kunnen zijn dat de structuur van een potentieel te bouwen systeem op dit moment minder duidelijk is voor de opdrachtnemer dan voor deze activiteit. Structurering is een volgende stap die met veel opdrachtgevers in hun eigen domein vaak prima te doen is; vanuit de stapel post-its gaan we een eerste draft van een domeinmodel samenstellen. Hou hierbij in gedachten: De verzamelde post-its zijn allen object-kandidaten, geen class-kandidaten! Dit is een essentieel verschil. Een eerste draft domeinmodel bevat vaak maar zo n 10 a 20 domeinclasses, waar er wel honderd of meer domeinobjecten geadresseerd kunnen zijn! Doordat we alle termen op post-its hebben geschreven kunnen we doormiddel van een groot vel papier of white board het eerste model gaan draften. Je zult het snel eens worden over de meest voor de hand liggende 18 7

8 class kandidaten deze kunnen eigenlijk al vanaf het begin een vaste prominente plaats innemen op het papier. Associaties tussen deze kandidaten kunnen we meteen met een stift trekken. Vervolgens zal er een aantal actoren of stakeholders genotuleerd zijn; deze hangen we voor nu apart van het model. De kleinere objecten zoals ordernummer kunnen bij hun corresponderende class geplakt worden. Het is tijdens het draften van dit model belangrijk om continue vragen te blijven stellen over de samenhang van de verschillende concepten in het probleemdomein. Blijf hierbij alert op aannames die domeinspecialisten al snel maken; de associaties tussen concepten moet zo expliciet mogelijk worden uitgewerkt. Wees echter niet bang om fouten te maken in het model in deze fase; we komen later terug op dit model en we zullen zien dat we ruim voldoende gelegenheid hebben om dit model te verifiëren. Dive Na een breedteanalyse op hoog abstractieniveau gaan we op een klein deel de diepte in. Blijf hierbij sturen op het smal houden van deze detailuitwerking om de zaak binnen beperkte tijd te kunnen uitdiepen. Deze dive voeren we uit aan de hand van één specifiek scenario. Een scenario is een concrete omschrijving van een aantal opeenvolgende stappen die in context van het probleemdomein genomen moeten worden om een bepaald doel te bereiken. Een handig startpunt van scenariodenken is het einde; wat is het doel dat we met dit scenario willen bereiken? Denk hierbij aan het facturatiescenario dat als doel een facuur heeft maar ook het reserveren van een stoel in een vliegtuig dat als doel een nieuwe reservering heeft, of een medewerker die verhuist. Vaak is het zo dat het doel een nieuw object in het systeem is of dat er een statusverandering van een bepaald object in het systeem moet plaatsvinden. Bij het aanmaken van een nieuw object start je dus eigenlijk met het definieren van een constructor of factory methode die een nieuw object oplevert; bij een statusovergang maak je een methode op een klasse aan. 1. Koppeling via inversion of control <<Uitleg>> 2. Koppeling via events / delegates (Observer / Observable pattern) <<Uitleg>> 3. Koppeling via code generatie <<Uitleg>> Voor sommige van deze koppelingsstrategieën wordt het relevant om bij de start van de levenscyclus van een applicatie te kiezen welke componenten gebruikt moeten worden. We noemen dit proces ook wel bootstrapping. Ook hiervoor zijn verschillende strategieën mogelijk. Als er gekozen wordt voor IoC containers wordt de bootstrapping vaak al door het gebruikte framework opgelost. Bij interface of event gebaseerde koppeling zal er bij start van een applicatie een bootstrap-proces ingeregeld moeten worden. Het verdient aanbeveling om hierover na te denken. Bootstrapping gebeurt in feite in elke applicatie in C# /.NET in de main() methode. Eenzelfde soort punt bestaat voor een webapplicatie in de global.asax in de Session_Start(), of meer statisch georiënteerd in de Application_Start(). Let bij webapplicaties goed op en doordenk de gekozen strategie goed aangezien dit minder voorspelbaar verloopt dan een (single) client applicatie. Bij (eenvoudige) service gebaseerde implementatie verdienen windows service hosts en/of consolehosts dan ook de voorkeur boven hosting in IIS, aangezien de ontwikkelaar geen invloed heeft op proces recycling en dergelijke. Feedback Modellering Na een eerste dive, waarin vaak veel architectuurwerk gedaan moet worden, ontstaat er een aantal stappenplannen waarin alle onderdelen van de te bouwen applicatie aangeraakt worden en deels geïmplementeerd. Zo kan er bijvoorbeeld een stappenplan voor het toevoegen van een domeinclass ontstaan dat er als volgt uitziet: 1. Toevoegen class aan domeinmodel 8 17

9 Vervolgens is het de vraag welke artefacten uit het businessdomein we allemaal nodig hebben om de statusovergang of objectcreatie te kunnen realiseren. Wederom is het hier handig om al deze artefacten op post-its (nieuwe kleur!) te notuleren en bij het bijbehorende doelobject op te plakken. Als de lijst eenmaal compleet is kunnen we gaan discussiëren welke class in ons draftmodel verantwoordelijk zou moeten zijn voor het beheren van bepaalde artefacten. Zo kan het goed zijn dat voor het verhuizen van een medewerker een nieuwe straat, huisnummer en postcode noodzakelijk is. Als er echter al een klasse Adres aanwezig is zou het kunnen zijn dat dit aan deze klasse gedelegeerd kan worden. Bij het moeten invoeren van nieuwe waarden kan het wel eens lastig worden om de vraag aan een bepaald object te stellen. Hiervoor kunnen we een extra object introduceren: de User. [Bron] De virtuele repository als hierboven omschreven delegeert de CRUD activiteit naar een component die dit kan uitvoeren. Deze benadering veroorzaakt een tweetal relevante vragen: - Wie garandeert bij goede ontkoppeling dat deze component aanwezig is? - Hoe koppel ik deze component correct gericht aan de domeincomponent? De eerste vraag is een kwestie die in de praktijk gek genoeg niet speelt. In feite is het vrij triviaal om hier een signaleringsmechanisme voor te maken maar de ervaring leert dat dit toch nooit nodig is. Het kan echter zeer relevant worden als ervoor gekozen wordt om de datacomponent op een aparte locatie te hosten (N-Tier architectuur) en dan dient er wel degelijk rekening mee gehouden te worden. Voor nu ga ik niet verder op dit punt in. Bedenk echter wel dat bij grotere ontkoppeling er ook minder validatie van de code is op compile time. <<Verder op ingaan?>> De tweede vraag, de koppeling tussen domeincomponent en datacomponent, is op meerdere manieren mogelijk. Ik presenteer hier drie mogelijke oplossingen. Nu we alle specifieke post-its verdeeld hebben over het model is het een kwestie van de sequence opschrijven voor dit scenario. Dit kan nu vrij simpel door alle classes die de anders gekleurde post-its hebben gekregen een eigen swimlane te geven in een nieuw sequence diagram. Het zou nu triviaal moeten zijn om de sequence op te schrijven. Initiele draft Om dit toch wat theoretische verhaal wat meer concreet te maken zal ik nu een klein voorbeeld uitwerken. Schrijf tijdens het lezen van de volgende alinea alle belangrijke zelfstandige naamwoorden in enkelvoud op. <<Case text >> <<Draft model>> Dive <<Dive text>> 16 9

10 <<Dive sequence>> Interaction Design Tot nu toe heb ik in het omschrijven van de kennisoverdrachtssessies van klant aan engineers niets gezegd over requirements verzameling vanuit gebruikersinteractie met het systeem. Dit is een activiteit die in mijn optiek parallel uitgewerkt dient te worden en zeker niet overgeslagen kan worden; een domeinmodel kan vooral op dit gebied incompleet zijn! Aan de andere kant is het ook zo dat er veel systemen zijn met mindere gebruikersinteractie of juist interactie geïnitieerd vanuit het systeem zelf. Wat dat betreft is het goed om zowel vanuit de ubiquitous language te werken als vanuit scherm mock-ups of storyboards. Storyboarding is een techniek die ikzelf het liefst begin op een whiteboard en zo samen met een klant kom tot een draft user interface. Ook dit model is aan verandering onderhevig, dus het is handig om hier zo snel mogelijk een demonstrabele electronische versie van te maken zodat men ermee kan spelen. Deze activiteit, parallel uitgevoerd aan domeinmodellering, kan potentiele gaten in domeinmodel opvullen en vice versa. Om terug te komen op het cyclische model; voor veel klanten is het CSP min of meer gelijk aan een aantal schermvoorbeelden met uitleg bij de op de schermen uit te voeren taken. In dit geval kan domeinmodellering veel meerwaarde bieden voor verborgen scenario s en functionaliteiten die weinig tot geen user interactie vereisen. Een val van een 100% UI gedreven benadering is een explosie van gerapporteerde bugs/issues uit gebruikerstesten. Als 80% van de UI staat maar slechts 10% van de achterliggende logica en opslag zijn er dus voor 70% van het systeem incomplete use-cases geïmplementeerd. Communiceren van alles dat wel en niet is geïmplementeerd is meer werk dan het simpelweg enkel opleveren wat is gebouwd; maak dus onderscheid tussen demo-ui elementen en daadwerkelijk geimplementeerde onderdelen! (hou je bij je verticale strepen ) Componenten Een meer natuurlijke manier van opdeling in lijn met wat eerder is gezegd betreft domain driven design is componentsgewijze opdeling, met één centrale businesscomponent. In feite mapt dit direct naar de hierboven omschreven structurering van de oplossing. We buigen het koppelvlak van de business logic layer als het ware rond zodat deze van alle kanten benaderd kan worden. Dit stelt ons tevens in staat om meer componenten aan te sluiten op hetzelfde businesscomponent. Door de interfacing van verschillende componenten op deze businesscomponent dienen we goed na te denken welke diensten deze businesscomponent aanbiedt. Zo zijn er een aantal standaardfaciliteiten die door user interfaces vaak gebruikt worden, veelal aangeduid als CRUD (Create, Read, Update en Delete) activiteiten. In meer standaard 2 of 3- laags architecturen worden deze zaken afgehandeld door een onderliggende database. Bedenk goed dat in de componentgebaseerde architectuur als hierboven omschreven dus helemaal geen database aanwezig hoeft te zijn! Wie biedt nu de CRUD interface aan die een user interface (vaak) verlangt? Eric Evans [2] spreekt van een repository component buiten het domein maar waar andere componenten ook gebruik van maken. De meer pure oplossing waarbij alle componenten slechts één afhankelijkheid hebben die met de businesscomponent is wat ik persoonlijk mooier vind. Er zijn meerdere strategieën mogelijk om deze vorm van repository integratie te bewerkstelligen zonder de ontkoppeling te offeren. Zo kan een virtuele repository opgenomen worden in het domein die alle functionaliteiten delegeert naar een (later) aangesloten component. Koppelmogelijkheden zijn dan publish/subscribe of inversion of control. <<Verdere uitleg patterns?>> 10 15

11 Layering Een veel gebruikte vorm van architectonische opdeling is layering. Een kenmerk van layering is dat onderdelen die bij elkaar horen in een eigen laag opgedeeld worden en dat deze lagen een éénweg afhankelijkheid kennen naar beneden. Alles rust bij layering dus op de onderste laag, en dit is vaak de datalaag. Deze vorm van opdeling wordt vaak en met succes toegepast. Toch sluit het niet geheel aan met de hier omschreven manier van structureren; immers er is een ketting aan afhankelijkheden. Om echt probleemgericht te werken en het de business logic centraal te stellen hebben we een andere manier van opdelen nodig. Planning Vaak wordt planning onder het kopje proces geschoven in standaard software engineering methodes. In mijn optiek vloeit de basisplanning direct voort uit de modelleringscyclus. Door het T-model te hanteren en de scope continue zoveel mogelijk in te perken is het mogelijk om met vaste iteratieperiodes te gaan diven. Een aanvullend concreet hulpmiddel dat hierbij kan helpen is het hanteren van een MoSCoW lijst. Door samen met betrokkenen de (beperkte!) workitem-lijst voorafgaande aan uitvoering van een iteratie door te nemen met een ingeperkt aantal Must-haves, Shouldhaves, Could-haves dwing je mensen na te denken over prioriteit van zaken. De eerste twee iteraties zijn waarschijnlijk nodig voor de projectteamleden om gevoel te krijgen bij workitemgrootte in context van het project, dus er zal initieel op basis van trial-and-error geprobeerd moeten worden welke aantallen handig zijn. Het is belangrijk voor deze planning om de velocity van een project te kennen, maar dat is reëel gesproken in het begin gewoon niet te doen. Ervaring hierin loont, het is dus zeker handig om in het begin een (klein) aantal meer ervaren mensen te laten meelopen. Om ergens te beginnen is het goed om workitems te nemen die om en nabij een dag kosten, zodat met een team van twee mensen er ongeveer 5 Must haves en 5 Should haves gemaakt kunnen worden in een eerste iteratie. Denk eraan zoveel mogelijk verticaal te blijven werken, hoe moeilijk dat vaak ook is! Dit neem overigens niet weg dat layering een goed concept is dat wel degelijk goed toe te passen is en toegepast wordt. Er wordt alleen een afhankelijkheid richting een datalaag gecreëerd die wat strakker is dan soms wenselijk. In de praktijk is dit echter in de meeste gevallen geen probleem

12 Architectuur Modellen kunnen - naar mate verder uitgewerkt een volledige en accurate simulatie van de te automatiseren business executeren. Met executeerbare modellen zijn we er echter niet; ze moeten in een bepaalde context draaien en vaak is het noodzakelijk dat zaken opgeslagen worden en is een bepaalde gebruikersinteractie wenselijk. Een eerste stap richting een opleverbare oplossing noem ik expliciet in het circulaire model en dat is de conversie van DM naar OM. Niet iedereen zal het hiermee eens zijn maar in mijn optiek zijn deze twee stadia van een model niet te voorkomen. In het DM wil je bij concepten blijven die opdrachtgevers ook begrijpen. In een OM komen zaken als design patterns, algoritmiek en koppelingen om de hoek kijken. Dit soort zaken doet harten van software engineers vaak sneller kloppen maar hiermee moeten opdrachtgevers niet lastig gevallen hoeven worden. Architectuur binnen deze systematiek bestaat grofweg uit twee delen; het neerzetten van een uitbreidbare structuur voor het te bouwen systeem als geheel alsmede het neerleggen van een aantal richtlijnen voor deze steeds verdere uitbreidingen. De eerste is vrij handig concreet neer te zetten; vaak wordt hier over framework ontwikkeling gesproken. Dit zou een goed thema kunnen zijn van een 0 e iteratie, of eventueel iets dat uit de gereedschapskoffer getoverd wordt. Veel lastiger is het concreet maken van de richtlijnen voor de transformatie van domeinmodel naar objectmodel. Een transformatie van domeinmodel naar objectmodel zou voor 80% uit standaard stappen en routines moeten bestaan (ontwikkeling van een DSL ligt voor de hand?) maar helaas is dit in de praktijk niet zo. Hoewel het in mijn optiek wel zo zou moeten zijn, er is geen standaard manier om een many-to-many associatie uit een UML diagram te vertalen naar een Java of C# implementatie. <<Verder uitwerken: [8]>> Naast de transformatie van het model zelf is het belangrijk om hier rekening te gaan houden met koppelingen tussen het model en externe, technische componenten. Hieronder vallen user interface, database en andere technisch georiënteerde onderdelen. We willen deze koppeling zo los mogelijk realiseren, en hiervoor zijn een aantal strategieën van toepassing. Denk aan IOC / DI (Inversion of Control of Dependency Injection) of event-gebaseerde communicatie (Observer / Observable pattern). Toch moet een oplossing wel werkbaar en onderhoudbaar blijven! Houdt dingen in dit opzicht dus ook zo simpel mogelijk. Een active record pattern (of liever gezegd Persistent Object ) hoeft helemaal niet verkeerd te zijn als dit de eenvoud ten goede komt. Iets dat veel initiele onduidelijkheid kan voorkomen is een goede duidelijke keuze voor de structurering van een oplossing. Denk hierbij aan indeling in namespaces of packages. Een goede duidelijke keuze en ook het communiceren hiervan zodat bij uitbreidingen helder is waar wat moet komen kan veel ellende voorkomen. Basisstructuur Zorg voor een component dat de domeinlogica (object model) bevat. Je kunt ervoor kiezen om het domein model te scheiden in een eigen component (zo zijn er ook meerdere object modellen mogelijk bij één domeinmodel) maar dit is niet noodzakelijk. Daarnaast zijn er vaak twee hoofdcomponenten die in vrijwel elk systeem voorkomen aanwezig: een user interface en een database component. <projectnaam>.domain //Domein / Object model <projectnaam>.ui //Algemene UI zaken <projectnaam>.ui.winforms //Windows forms specifieke zaken <projectnaam>.ui.web //Web specifieke zaken <projectnaam>.data //Algemene data access zaken <projectnaam>.data.ado //Dataontsluiting via ADO UML heeft voor het vastleggen en communiceren van dit soort structuren een diagramsoort, namelijk het package diagram. Hiermee is ook aan te geven wat de afhankelijkheden tussen de componenten zijn

De mens als essentiële factor in software development. hoe agile teams omgaan met software process improvement

De mens als essentiële factor in software development. hoe agile teams omgaan met software process improvement De mens als essentiële factor in software development hoe agile teams omgaan met software process improvement Rob Westgeest 21 mei 2007 Voorstellen Rob Westgeest Getrouwd 3 kinderen 16 Jaar in I(C)T Onafhankelijk

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

Kwaliteit en Testen binnen Agile Project Management volgens Scrum bij Planon. David Griffioen 11 april 2006

Kwaliteit en Testen binnen Agile Project Management volgens Scrum bij Planon. David Griffioen 11 april 2006 Kwaliteit en Testen binnen Agile Project Management volgens Scrum bij Planon David Griffioen april 2006 Agenda Planon Agile Scrum Scrum bij Planon Kwaliteit en Testen Planon Planon maakt productsoftware

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

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

Sparse columns in SQL server 2008

Sparse columns in SQL server 2008 Sparse columns in SQL server 2008 Object persistentie eenvoudig gemaakt Bert Dingemans, e-mail : info@dla-os.nl www : http:// 1 Content SPARSE COLUMNS IN SQL SERVER 2008... 1 OBJECT PERSISTENTIE EENVOUDIG

Nadere informatie

Verantwoording van het Logica In Lagen referentiemodel

Verantwoording van het Logica In Lagen referentiemodel Verantwoording van het Logica In Lagen referentiemodel Bijlage bij Meer inzicht in gelaagde architectuur - Deel 1: Uitleg, terminologie en methoden [Pruijt10]. Leo Pruijt, Lectoraat Architectuur van Digitale

Nadere informatie

Technisch Ontwerp W e b s i t e W O S I

Technisch Ontwerp W e b s i t e W O S I Technisch Ontwerp W e b s i t e W O S I WOSI Ruud Jungbacker en Michael de Vries - Technisch ontwerp Website Document historie Versie(s) Versie Datum Status Omschrijving / wijzigingen 0.1 20 nov 2008 Concept

Nadere informatie

your reference in testing services WorkShop Agile in de praktijk - Erik Boelen - 18 december 2008

your reference in testing services WorkShop Agile in de praktijk - Erik Boelen - 18 december 2008 your reference in testing services WorkShop Agile in de praktijk - Erik Boelen - 18 december 2008 Onderwerpen vandaag Geen theoretische achtergrond Gebaseerd op eigen praktijk Niet uit boeken te halen

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

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

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

Uitdagingen performancetesten in een Agile omgeving Best Practices & Demo

Uitdagingen performancetesten in een Agile omgeving Best Practices & Demo Uitdagingen performancetesten in een Agile omgeving Best Practices & Demo Henrik Rexed & Joerek van Gaalen Voorstellen Joerek van Gaalen Performancetest specialist sinds 2005 Sinds 2014 CTO Computest Voorstellen

Nadere informatie

Ervaringen met Agile Software Development volgens SCRUM

Ervaringen met Agile Software Development volgens SCRUM Ervaringen met Agile Software Development volgens SCRUM Erik J.H. Jaspers CTO Planon B.V. Contents Introductie Planon Agile Development Scrum Waarom Agile/Scrum toegepast? Ervaringen, leerpunten 1 Development

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

UML. From weblog http://dsnippert.wordpress.com. Dennis Snippert

UML. From weblog http://dsnippert.wordpress.com. Dennis Snippert UML From weblog http://dsnippert.wordpress.com Naam: Dennis Snippert Inhoudsopgave 1. Wat is Uml?... 3 2. UML diagrammen... 4 3. Uitleg diagrammen... 5 3.1. Usecase diagram:... 5 3.2. Class diagram:...

Nadere informatie

Modulebeschrijving voor MOD1

Modulebeschrijving voor MOD1 Modulebeschrijving voor MOD1 Fontys Venlo Afd. informatica 12 april 2013 Samenvatting 1 Identificatie Module Modeling 1 ProgressCode MOD1 Docenten Ferd van Odenhoven Afdeling Fontys Hogeschool Techniek

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

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

Model driven Application Delivery

Model driven Application Delivery Model driven Application Delivery Fast. Flexible. Future-proof. How Agis streamlines health procurement using Mendix Model driven Application Platform Mendix in a nutshell Mendix delivers the tools and

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 Maart 2015 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 2 December 2014 Yannick Verschueren

Nadere informatie

Agile Project Management volgens Scrum. David Griffioen 21 mei 2007

Agile Project Management volgens Scrum. David Griffioen 21 mei 2007 Agile Project Management volgens Scrum David Griffioen 21 mei 2007 Agenda Agile Scrum Proces verbetering in Scrum Verbeteren bij Planon Vragen Een aantal vragen hand opsteken graag Wie is bekend met Agile

Nadere informatie

Capita Selecta Design Patterns voor administratieve applicaties

Capita Selecta Design Patterns voor administratieve applicaties Capita Selecta voor administratieve applicaties Bij afstudeerproject: Generiek framework voor administratieve toepassingen in een webgeörienteerde omgeving Henk van de Ridder 26 augustus 2006 Inhoud 26

Nadere informatie

Domeinmodellen en klassendiagrammen

Domeinmodellen en klassendiagrammen Overview Architectuur Deployment-diagram Software-architectuur 1 Architectuur Deployment-diagram Software-architectuur 2 3 Architectuur Architectuur Deployment-diagram Software-architectuur Webapplicatie

Nadere informatie

Kenmerken van DLArchitect

Kenmerken van DLArchitect Kenmerken van DLArchitect Bert Dingemans, e-mail : bert@dla-os.nl www : http://www.dla-os.nl 1 Inhoud KENMERKEN VAN DLARCHITECT... 1 INHOUD... 2 INLEIDING... 3 ARCHITECTUUR... 3 Merode... 3 Methode en

Nadere informatie

Continuous Delivery. Sander Aernouts

Continuous Delivery. Sander Aernouts Continuous Delivery Sander Aernouts Info Support in een notendop Maatwerk softwareontwikkeling van bedrijfskritische kantoorapplicaties Business Intelligence oplossingen Managed IT Services Eigen Kenniscentrum

Nadere informatie

Archimate risico extensies modelleren

Archimate risico extensies modelleren Archimate risico extensies modelleren Notatiewijzen van risico analyses op basis van checklists versie 0.2 Bert Dingemans 1 Inleiding Risico s zijn een extra dimensie bij het uitwerken van een architectuur.

Nadere informatie

Inhoudstafel. UML (Unified Modeling Language)

Inhoudstafel. UML (Unified Modeling Language) UML (Unified Modeling Language) Inhoudstafel Inleiding...2 Waarvoor dient UML...2 Wat is UML... 2 Use-cases... 2 Inleiding...2 Voorbeeld...3 Eigenschappen van een goede use-case...3 Wat is een actor...4

Nadere informatie

Agile Beheer: Mythe of werkelijkheid? Odile Moreau BlinkLane Consulting NIOC 2013 - Arnhem, 5 april 2013

Agile Beheer: Mythe of werkelijkheid? Odile Moreau BlinkLane Consulting NIOC 2013 - Arnhem, 5 april 2013 Agile Beheer: Mythe of werkelijkheid? Odile Moreau BlinkLane Consulting NIOC 2013 - Arnhem, 5 april 2013 Achtergrond 2 Agile methoden zijn al een tijd heel populair geworden Zoals Scrum voor software ontwikkeling

Nadere informatie

NHibernate als ORM oplossing

NHibernate als ORM oplossing NHibernate als ORM oplossing Weg met de SQL Queries Wat is ORM? ORM staat in dit geval voor Object Relational Mapping, niet te verwarren met Object Role Modeling. ORM vertaalt een objectmodel naar een

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

Adding value to test tooling Hoe en waarom DevOps de wereld van performance testen verandert

Adding value to test tooling Hoe en waarom DevOps de wereld van performance testen verandert Hoe en waarom DevOps de wereld van performance testen verandert Najaarsevenement 14 oktober 2015 Inleiding Wie zijn we Marc Koper: Specialist in performancetesten / testautomatisering HenkJaap van den

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

Zelftest OOAD/UML. Document: N0767Test.fm 30/08/2010. ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium

Zelftest OOAD/UML. Document: N0767Test.fm 30/08/2010. ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium Zelftest OOAD/UML Document: N0767Test.fm 30/08/2010 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INTRODUCTIE Deze test is gebaseerd op de inhoud van onze cursus OO

Nadere informatie

WAT BETEKENT BUSINESS AGILITY VOOR UW ONTWIKKELSTRAAT? SAMENVATTING BUSINESS AGILITY ITERATIEVE AANPAK ONTWIKKELSTRAAT

WAT BETEKENT BUSINESS AGILITY VOOR UW ONTWIKKELSTRAAT? SAMENVATTING BUSINESS AGILITY ITERATIEVE AANPAK ONTWIKKELSTRAAT WAT BETEKENT BUSINESS AGILITY VOOR UW ONTWIKKELSTRAAT? SAMENVATTING Voor het bereiken van business agility is meer nodig dan een juiste architectuur en is een iteratieve aanpak essentieel. Daarvoor is

Nadere informatie

Benefits Management. Continue verbetering van bedrijfsprestaties

Benefits Management. Continue verbetering van bedrijfsprestaties Benefits Management Continue verbetering van bedrijfsprestaties Agenda Logica 2010. All rights reserved No. 2 Mind mapping Logica 2010. All rights reserved No. 3 Opdracht Maak een Mindmap voor Kennis Management

Nadere informatie

Complexiteit van een DDD 1 implementatie In DDD wordt het business domein centraal gesteld. De grondlegger van deze benadering,

Complexiteit van een DDD 1 implementatie In DDD wordt het business domein centraal gesteld. De grondlegger van deze benadering, 14 Enterprise Edwin van Dillen is principal consultant bij Sogyo en bereikbaar via evdillen@sogyo.nl. Andre Boonzaaijer is senior consultant bij Sogyo en bereikbaar via aboonzaaijer@sogyo.nl. Domain Driven

Nadere informatie

Rijnlands denken en Agile ICT. Patrick van Burgel 7 december

Rijnlands denken en Agile ICT. Patrick van Burgel 7 december 1 Rijnlands denken en Agile ICT Patrick van Burgel 7 december Even terug naar 1911 F. W. Taylor: Scientific management 2 Vroeger stond de mens voorop; in de toekomst moet het systeem (regels, procedures)

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

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

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

Workflows voor SharePoint met forms en data K2 VOOR SHAREPOINT

Workflows voor SharePoint met forms en data K2 VOOR SHAREPOINT Slimmer samenwerken met SharePoint Workflows voor SharePoint met forms en data K2 VOOR SHAREPOINT Workflows, forms, reports en data WAAROM KIEZEN VOOR K2? Of u nu workflows moet maken voor items in SharePoint

Nadere informatie

Application interface. service. Application function / interaction

Application interface. service. Application function / interaction Les 5 Het belangrijkste structurele concept in de applicatielaag is de applicatiecomponent. Dit concept wordt gebruikt om elke structurele entiteit in de applicatielaag te modelleren: softwarecomponenten

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

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

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

Tools voor canonieke datamodellering Bert Dingemans

Tools voor canonieke datamodellering Bert Dingemans Tools voor canonieke datamodellering Tools voor canonieke datamodellering Bert Dingemans Abstract Canonieke modellen worden al snel omvangrijk en complex te beheren. Dit whitepaper beschrijft een werkwijze

Nadere informatie

UML is een visuele taal om processen, software en systemen te kunnen modeleren.

UML is een visuele taal om processen, software en systemen te kunnen modeleren. Vragen inleinding UML 1. Wat is UML? UML is een visuele taal om processen, software en systemen te kunnen modeleren. 2. Waar bestaat UML uit? Notaties(zijn symbolen, commentaar en waarden etc.) en diagrammen(grafische

Nadere informatie

Testen = Monitoren. Hoe de werkzaamheden van de boodschapper van de koning gaan veranderen. Datum: 30 April 2015

Testen = Monitoren. Hoe de werkzaamheden van de boodschapper van de koning gaan veranderen. Datum: 30 April 2015 Testen = Monitoren Hoe de werkzaamheden van de boodschapper van de koning gaan veranderen. Spreker: Ide Koops Datum: 30 April 2015 1 2 Agenda Testrapportages in het verleden Impact nieuwe ontwikkelingen

Nadere informatie

Keteininformatiemodellering op basis van Archimate

Keteininformatiemodellering op basis van Archimate Keteininformatiemodellering op basis van Archimate Notatie en voorbeelden versie 0.1 Bert Dingemans Inhoudsopgave Inhoudsopgave... 2 Inleiding... 3 Archimate... 3 Domeininformatiemodellen... 4 Modellering...

Nadere informatie

CORA 1.0 Bedrijfs- en ICT-referentiearchitectuur voor woningcorporaties

CORA 1.0 Bedrijfs- en ICT-referentiearchitectuur voor woningcorporaties CORA 1.0 Bedrijfs- en ICT-referentiearchitectuur voor woningcorporaties Hoe zorgen we ervoor dat we nieuwe diensten en producten soepel in onze bedrijfsvoering op kunnen nemen? Hoe geven we betere invulling

Nadere informatie

Betreft: Verzoek tot Offerte AmersfoortBreed Cultuureducatie / Website Scholen in de Kunst Datum: 10 oktober 2011

Betreft: Verzoek tot Offerte AmersfoortBreed Cultuureducatie / Website Scholen in de Kunst Datum: 10 oktober 2011 Betreft: Verzoek tot Offerte AmersfoortBreed Cultuureducatie / Website Scholen in de Kunst Datum: 10 oktober 2011 Geachte heer, mevrouw, Gemeente Amersfoort is in 2010 gestart met het project AmersfoortBreed.

Nadere informatie

Reshaping the way you think and act to deal with the complex issues of today s world

Reshaping the way you think and act to deal with the complex issues of today s world Reshaping the way you think and act to deal with the complex issues of today s world HOE GAAT HET NU? We zetten allemaal verschillende methoden in om vraagstukken op te lossen, oplossingen te ontwerpen

Nadere informatie

Propositie van de werkgroep Agile Architecting. Louis Stevens Niklas Odding Herman van den Berg Frank Langeveld

Propositie van de werkgroep Agile Architecting. Louis Stevens Niklas Odding Herman van den Berg Frank Langeveld Propositie van de werkgroep Agile Architecting Louis Stevens Niklas Odding Herman van den Berg Frank Langeveld Hanoi traffic Factsheet Werkgroep AA Probleem: Agile zijn is moeilijk. Behoefte aan praktijk

Nadere informatie

ARE methodiek Het ontwikkelen van Informatie Elementen

ARE methodiek Het ontwikkelen van Informatie Elementen ARE methodiek Het ontwikkelen van Informatie Elementen WI1: Het opstarten van het project Milestone 1 WI2: Ontwikkel een Vison WI3: Modelleer het Business Domain WI4: Creëer een Glossary WI7: Beheer wijzigingen

Nadere informatie

Vraag 1. Vraag 1a TERUGKOPPELING PROEFTENTAMEN. Software architecture

Vraag 1. Vraag 1a TERUGKOPPELING PROEFTENTAMEN. Software architecture Software architecture IM0203 TERUGKOPPELING PROEFTENTAMEN Vraag 1 Vraag 1a Veel van de in het werkboek besproken patterns kunnen ingezet worden voor het referentiesysteem. We lopen de patterns hier stuk

Nadere informatie

Vincent. Hierbij het profiel van.net developer Vincent uit Delft. Vincent presenteert zichzelf graag door onderstaande drie vragen te beantwoorden:

Vincent. Hierbij het profiel van.net developer Vincent uit Delft. Vincent presenteert zichzelf graag door onderstaande drie vragen te beantwoorden: Contact the Agency Laurens Simonse 06 22801031 laurens@rockstars-it.nl Bart Nijskens 06 52302211 bart@rockstars-it.nl Vincent Hierbij het profiel van.net developer Vincent uit Delft. Vincent presenteert

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

Ervaringen met het opzetten van een MDD omgeving

Ervaringen met het opzetten van een MDD omgeving Ervaringen met het opzetten van een MDD omgeving Introductie (1/3) Eric Jan Malotaux Software architect Mod4j Software architect Ordina Johan Vogelzang Developer Mod4j Projectleider Java ontwikkelstraat

Nadere informatie

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil eagileagileagileagileagileagileagileagi leagileagileagileagileagileagileagileag

Nadere informatie

Ontwikkelmethodiek voor software

Ontwikkelmethodiek voor software voor software Sonja Rouwhorst Instituut voor interactieve media Hogeschool van Amsterdam Datum: 28 januari 2008 Versie: 1 Status: definitief Inhoudsopgave Inleiding... 3 Het proces van software ontwikkelen...

Nadere informatie

Doel is, dat dit document uiteindelijk een visie formuleert, waar de volgende partijen achter kunnen staan:

Doel is, dat dit document uiteindelijk een visie formuleert, waar de volgende partijen achter kunnen staan: User Profile Repository Art Recommender Visie document Versie 2.0 1 juli 2011 Auteurs Hennie Brugman, technisch coordator CATCHPlus hennie.brugman@meertens.knaw.nl Doel is, dat dit document uiteindelijk

Nadere informatie

dcroho; Ketenintegratie in opleidingenland Door: Patries van de Kamp, Relatiemanager HO Sandra Warmolts, Projectleider dcroho

dcroho; Ketenintegratie in opleidingenland Door: Patries van de Kamp, Relatiemanager HO Sandra Warmolts, Projectleider dcroho dcroho; Ketenintegratie in opleidingenland Door: Patries van de Kamp, Relatiemanager HO Sandra Warmolts, Projectleider dcroho SISLink 2010: 17 juni 2010 Inhoud Hoe werkt het nu Waarom dcroho Resultaat

Nadere informatie

Design Data Management voor FPGA ontwikkeling

Design Data Management voor FPGA ontwikkeling Design Data Management voor FPGA ontwikkeling Al snel heb je bij electronica ontwikkeling met Design Data Management te maken, zo ook bij FGPA ontwikkeling. Er wordt immers code gegenereerd die beheerd

Nadere informatie

Dynamiek met VO-Script

Dynamiek met VO-Script Dynamiek met VO-Script Door Bert Dingemans DLA Ontwerp & Software bert@dla-architect.nl Inleiding Op de SDGN nieuwsgroep voor Visual Objects ontstond laatst een draad van berichten over de nieuwe libraries

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

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

Genereren van een webapplicatie op basis van DLA

Genereren van een webapplicatie op basis van DLA Genereren van een webapplicatie op basis van DLA ir Bert Dingemans DLA Ontwerp en Software info@dla-architect.nl Inleiding Bij het ontwikkelen van maatwerk software loopt men al snel tegen het probleem

Nadere informatie

Zelftest Java concepten

Zelftest Java concepten Zelftest Java concepten Document: n0838test.fm 22/03/2012 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INLEIDING BIJ DE ZELFTEST JAVA CONCEPTEN Om de voorkennis nodig

Nadere informatie

1. Welke diagrammen beschrijven het dynamisch gedrag van een applicatie?

1. Welke diagrammen beschrijven het dynamisch gedrag van een applicatie? 1. Welke diagrammen beschrijven het dynamisch gedrag van een applicatie? -Use case-diagram -Use case-beschrijving -Activity diagram -Sequentie diagram 2. Welke diagrammen beschrijven de structuur van de

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

Niels Malotaux. 25 jaar West

Niels Malotaux. 25 jaar West Niels Malotaux niels@malotaux.nl www.malotaux.nl 1 Niels Malotaux Project Coach Evolutionair Project Management (Evo) Requirements Engineering Reviews and Inspecties Betrouwbaarheid Systemen die het gewoon

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

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

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

Continuous testing in DevOps met Test Automation

Continuous testing in DevOps met Test Automation Continuous ing in met Continuous testing in met Marco Jansen van Doorn Tool Consultant 1 is a software development method that emphasizes communication, collaboration, integration, automation, and measurement

Nadere informatie

Het CIBG ervaart een hogere kwaliteit met applicatie-ontwikkeling in Microsoft Visual Studio 2010

Het CIBG ervaart een hogere kwaliteit met applicatie-ontwikkeling in Microsoft Visual Studio 2010 Het CIBG ervaart een hogere kwaliteit met applicatie-ontwikkeling in Microsoft Visual Studio 2010 Organisatie Het CIBG is een uitvoeringsorganisatie van het ministerie van Volksgezondheid, Welzijn en Sport.

Nadere informatie

Thinking of development

Thinking of development Thinking of development Databases Arjan Scherpenisse HKU / Miraclethings Agenda voor vandaag Opdracht tussenstand State diagram / Observer pattern Bret Victor Databases 2/42 Opdracht tussenstand Slides

Nadere informatie

Zelftest Java EE Architectuur

Zelftest Java EE Architectuur Zelftest Java EE Architectuur Document: n1218test.fm 22/03/2012 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INLEIDING BIJ DE ZELFTEST JAVA EE ARCHITECTUUR Nota:

Nadere informatie

Factsheet CONTINUOUS VALUE DELIVERY Mirabeau

Factsheet CONTINUOUS VALUE DELIVERY Mirabeau Factsheet CONTINUOUS VALUE DELIVERY Mirabeau CONTINUOUS VALUE DELIVERY We zorgen ervoor dat u in elke volwassenheidsfase van uw digitale platform snel en continu waarde kunt toevoegen voor eindgebruikers.

Nadere informatie

OOAA. Object Oriented Analysis Advanced. Arie Bubberman 12/10/2009

OOAA. Object Oriented Analysis Advanced. Arie Bubberman 12/10/2009 OOAA Object Oriented Analysis Advanced Arie Bubberman 12/10/2009 Contents 1 Analyse...3 Kiezen van een ontwikkelproces...3 Agile Methoden...3 Deelprocessen in het OO-ontwikkelproces...Fout! Bladwijzer

Nadere informatie

Generiek framework voor administratieve toepassingen in een webgeörienteerde omgeving

Generiek framework voor administratieve toepassingen in een webgeörienteerde omgeving Generiek framework voor administratieve toepassingen in een webgeörienteerde omgeving Henk van de Ridder Stand van zaken 17 Maart 2007 Inhoud Probleemgebied afstudeerproject Oplossingsgebied afstudeerproject

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

End-to-End testen: de laatste horde

End-to-End testen: de laatste horde End-to-End testen: de laatste horde Dieter Arnouts Agenda Begrip End-to-End testen in het test proces Praktische aanpak End-to-End Test Omgeving Uitdagingen End-to-End testen: De laatste horde 11/10/2010

Nadere informatie

Effectief Geautomatiseerd Testen in de Praktijk TestNet Summer School

Effectief Geautomatiseerd Testen in de Praktijk TestNet Summer School Effectief Geautomatiseerd Testen in de Praktijk TestNet Summer School Den Haag, 13 juli 2011 Martin Gijsen Jan Reurings Programma -Even voorstellen -Aanleiding & doel -Kennen we elkaar? -Theorie van effectief

Nadere informatie

Portfolio Innovation Manager & Reisleider in de Digitale Wereld. Copyright 2015 ITpreneurs. All rights reserved.

Portfolio Innovation Manager & Reisleider in de Digitale Wereld. Copyright 2015 ITpreneurs. All rights reserved. Portfolio Innovation Manager & Reisleider in de Digitale Wereld Usability in Courseware Development Ellen Schuurink Gastcollege Usability Engineering Agenda Leren en usability Usability van cursusmateriaal

Nadere informatie

Service Virtualization @RABOBANK

Service Virtualization @RABOBANK Service Virtualization @RABOBANK TMA Dag 2015 eter Claassen RABOBANK Marc van Lint - IBM Agenda 1. Rabobank Context 2. DevOps Vision 3. roof en Implementeren 4. Voorbeelden 5. Ervaringen & Best ractices

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

Resultaat gerichter Testen

Resultaat gerichter Testen Resultaat gerichter Testen Verandering van test beleid bij Rabobank International De Rabobank 1 Rabobank International Information Systems &Development IS&D Global Services & IT Risk Management Strategy

Nadere informatie

Satisfy the real (and changing) customer expectation

Satisfy the real (and changing) customer expectation Han Duisterwinkel Test & Quality competence RUP competence LogicaCMG Nederland B.V. Eemsgolaan 1 P.O. Box 70237 9704 AE Groningen The Netherlands www.logicacmg.com @logicacmg.com

Nadere informatie

Object Oriented Programming

Object Oriented Programming Object Oriented Programming voor webapplicaties Door Edwin Vlieg Waarom OOP? Basis uitleg over OOP Design Patterns ActiveRecord Model View Controller Extra informatie Vragen OOP Object Oriented Programming

Nadere informatie

Kennis na het volgen van de training. Na het volgen van deze training bent u in staat:

Kennis na het volgen van de training. Na het volgen van deze training bent u in staat: Training Trainingscode Duur Gepubliceerd Taal Type Leermethode Kosten SF2015V8 4 dagen 02/02/2015 Nederlands & Engels Developer, basis Invidueel & klassikaal Op aanvraag Deze training richt zich op het

Nadere informatie

Customer Case: WoningNet

Customer Case: WoningNet Customer Case: WoningNet WoningNet en Webservices Woonruimtebemiddeling Shared service center Business uitdaging Architectuur visie Woonruimtebemiddeling Woningzoekende Corporatiemedewerker Corporatiemedewerker

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

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

EXIN WORKFORCE READINESS professional

EXIN WORKFORCE READINESS professional EXIN WORKFORCE READINESS professional DE ERVARING LEERT ICT is overal. Het is in het leven verweven geraakt. In een wereld waarin alles steeds sneller verandert, is het lastig te bepalen wat er nodig is

Nadere informatie

Projectdocument Minecraft Mod Builder

Projectdocument Minecraft Mod Builder Projectdocument Minecraft Mod Builder Projectgroep Twintro 11 december 2015 Inhoudsopgave 1 Probleemstelling 2 2 Productbeschrijving 2 3 Requirements analyse 3 3.1 Functional requirements................................

Nadere informatie