Aanwijzingen en richtlijnen voor een beslismodel. Van ontwerp tot validatie

Maat: px
Weergave met pagina beginnen:

Download "Aanwijzingen en richtlijnen voor een beslismodel. Van ontwerp tot validatie"

Transcriptie

1 Aanwijzingen en richtlijnen voor een beslismodel Van ontwerp tot validatie

2 Inhoudsopgave 1. Inleiding p. 3 a. Inhoud p. 3 b. Bereik van het document p Leeswijzer p Algemene richtlijnen ten aanzien van regel intensieve applicaties p. 5-7 a. Internationale Standaarden p. 5-7 i. Business Rules Manifest p. 5-6 ii. De Object Management Group p. 6-7 iii. Agile Manifesto p.7 4. Ontwerp Beslismodel p.8-13 a. De schets van het beslismodel p. 8 b. Ontwerp en Prototype p. 9 c. Modelleerrichtlijnen p d. Overige aspecten die bij het ontwerpen betrokken kunnen worden p Het bouwen van een beslismodel p a. Inleiding p. 14 b. Tips bij het bouwen van een beslismodel p c. Analyse van juridische vaagheden en verwijzingen p De Rapportage p a. Inleiding p. 18 b. Rapportfunctie van de Publisher p c. Van papier naar digitaal p d. Informatieschets p e. Modelleerrichtlijnen p. 22 f. Extra informatie en lay-out p. 22 g. Specifieke opmerkingen in relatie tot de huidige rapportage p i. Rapport als basis voor ontwerp p. 23 ii. Inbouwen intelligentie p iii. Tussenconclusies p. 24 iv. Gebruik waardelijsten p. 24 h. Bewijsstukken p. 24 i. Import/Export rekengegevens p Acceptatie Beslismodel p a. Acceptatiecriteria p. 26 b. Algemene richtlijnen uit de praktijk p Bijlage p Berkeley Bridge: Richtlijnen voor een beslismodel 2

3 1. Inleiding A. Inhoud In dit document worden algemene en specifieke aanwijzingen en (modelleer)richtlijnen beschreven voor het ontwerp en de bouw van een beslismodel. Aangevuld met algemene beschrijvingen worden deze voorgesteld als aanbeveling, tip en/of leidraad voor het ontwerp en de bouw van beslismodellen. Als onderdeel van het beslismodel wordt bovendien een lijst met attentiepunten geboden voor het ontwerpen/bouwen van een rapportage met de resultaten van deze beslisboom. B. Bereik van het document Het technisch platform voor de beslismodel en rapportage betreft de Berkeley Bridge Publisher. Hoewel het doel van dit document niet is om een functionele beschrijving te geven van het daadwerkelijke modelleren en rapporteren binnen de Publisher, zal bij het uitwerken van de richtlijnen wel zoveel mogelijk rekening worden gehouden met de (on)mogelijkheden van de Publisher en zullen ook concrete tips gegevens worden. Dit document is geen handleiding bij het gebruik van de Publisher, wel bij het maken van beslismodellen. Berkeley Bridge: Richtlijnen voor een beslismodel 3

4 2. Leeswijzer De indeling van dit document is als volgt: als eerste worden internationale standaarden voor het ontwerpen en bouwen van regelintensieve systemen beschreven. Deze standaarden geven inzicht hoe om te gaan met kennisintensieve regels (hierna te noemen business rules). Deze standaarden zullen niet altijd onverkort van toepassing zijn, maar geven een interessant beeld hoe nagedacht wordt over gebruik van business rules. Vervolgens zal nader ingegaan worden op het ontwerpen van een beslismodel. Een rapportage kan niet bestaan zonder een gedegen onderliggend beslismodel en daarom biedt dit document ook aanbevelingen voor het ontwerpen en bouwen van beslismodellen. Ook worden er, onder andere, vragen beantwoord zoals wat is de noodzaak van een ontwerp en wat dient het ontwerpt te bevatten. Vervolgens wordt aandacht besteed aan de bouw. Wanneer tijdens de ontwerpfase al goed is nagedacht over het beslismodel, kan de bouwfase meestal redelijk snel doorlopen worden. In het daaropvolgende onderdeel wordt nader naar de rapportage gekeken. Waar moet bijvoorbeeld rekening mee gehouden worden bij het ontwerp van de rapportage? Daarna wordt kort stilgestaan bij interfacing, de mogelijkheden op het gebied van communicatie, met andere systemen. Tenslotte wordt aandacht besteed aan het accepteren van het beslismodel. Figuur 1: fasering van de ontwikkeling van een beslismodel. Testen hoort hier natuurlijk ook bij, maar is in dit document buiten beschouwing gebleven. Berkeley Bridge: Richtlijnen voor een beslismodel 4

5 3. Algemene richtlijnen ten aanzien van regelintensieve applicaties A. Internationale Standaarden Zowel vanuit wetenschappelijk kader als vanuit het bedrijfsleven is aandacht besteed aan standardisatie en implementatie van het gebruik van business rules. Eensgezindheid in het denken over business rules betekent immers een versnelling en betere beheersing van het voortbrengingsproces. Ook de uitwisselbaarheid van kennis en de onderlinge aansluitbaarheid van systemen is hierbij gebaat. Deze standaarden zijn door hun ofwel algemene karakter of juist gerichtheid op een specifieke tooling of methode niet allemaal onverkort van toepassing, maar bieden wel een leidraad bij het nadenken, ontwerpen en/of bouwen van beslismodellen. Dit deel zal dan ook niet extensief alle internationale standaarden bespreken, want dat kan een boekwerk op zichzelf worden en valt daardoor buiten het bestek van het specifieke doel van dit document. Een aantal standaarden is echter wel interessant om toe te lichten. Als eerste wordt het business rules manifest een aantal leidende principes voor het omgaan met regels in softwaretoepassingen aangestipt. Daarna wordt ingegaan op de object management group. Dit geeft een beeld van standaarden bij het ontwerpen van systemen en tot slot wordt de Agile-aanpak, gekenmerkt door het ontwikkelen van software in korte, overzichtelijke perioden om de risico s te verminderen, de directe communicatie, de nadruk op voortgang en het testen hiervan door middel van prototypes. Een voorbeeld van een projectaanpak voor het bouwen van systemen, gebruik makend van de Agile-aanpak, wordt besproken. i. Business Rules Manifest Het Business rules manifest van de Business Rules Group bevat een aantal algemene regels geformuleerd in een manifest, welke als leidraad dienen voor regelintensieve systemen (en dus voor het omgaan met business rules). Daarnaast is in het kader van BRG de regeltaal SVBR[1] ontwikkeld. Dit is een gestructureerde taal voor het formuleren van regels. De aard van natuurlijke taal (en zeker juridisch taalgebruik) het per definitie onduidelijk en is om die reden niet geschikt voor het formuleren van business rules.[2] De bedrijfsregel ( business rule ) wordt door BRG gezien als een van het proces onafhankelijk deel en vooral als het kennisintensieve hart van systemen. Dat is een zeer belangrijk kenmerk van de business rule. Deze worden ontwikkeld dooren zijn eigendom van de business zelf en zijn daardoor in ontwerp, beheer en onderhoud dus flexibeler en meer aanpasbaar dan ingewikkelde softwarecode in handen van techneuten. Zie de bijlage voor een integraal overzicht van dit manifest. Feitelijk valt het uitschrijven van een regel in een Publisherdiagram ook onder het beheren van de regels door de business zelf (artikel 6.2 van het manifest). Vandaar dat het business rules manifest een algemene leidraad kan bieden bij het ontwikkelen van beslismodellen. Hoewel het hele manifest interessant is, verdienen de Berkeley Bridge: Richtlijnen voor een beslismodel 5

6 artikelen 2.3, 3.3, 4, 5.1, 6.2, 6.3 (de rapportage dus), 8 en 9 extra aandacht bij het ontwerpen van de beslisboom. [1] Semantics of Business Vocabulary and Business Rules [2] Het oplossen van vaagheden in (juridische) teksten en deze daarmee geschikt maken voor systeemontwikkeling is een niet te onderschatten activiteit bij het omzetten van (juridische) regels naar business rules. Natuurlijke taal is per definitie vaak meerduidig, terwijl de binaire wereld zwart/wit denkt. Zie ook het voorbeeld verder in dit document. ii. De Object Management Group De Object Management Group (OMG) is een in 1989 opgericht consortium, dat zich richt op de ontwikkeling van standaarden voor applicatieonafhankelijke,objectgeoriënteerde systemen. Dit bedrijf focust zich tegenwoordig op modelvorming (programma s, systemen en bedrijfsprocessen) en modelgebaseerde standaarden. Bij de oprichting waren 11 bedrijven betrokken, waaronder Apple, Hewlett-Packard, IBM, en Sun. Ondertussen zijn meer dan 800 bedrijven betrokken en werkt het consortium verder aan het beheer en de ontwikkeling van verschillende internationaal erkende standaarden.[1] Figuur 2: Een UML Klassediagram Berkeley Bridge: Richtlijnen voor een beslismodel 6

7 Een resultaat van OMG is bijvoorbeeld de ontwerptaal UML (Unified Modeling Language), nu gebruikt als standaard bij het ontwerpen van veel verschillende soorten systemen. UML bestaat uit een aantal grafische elementen die tot diagrammen worden gecombineerd. Omdat het eigenlijk een taal is, bevat UML ook regels voor het combineren van deze elementen. Dit is ruwweg vergelijkbaar met de grafische weergave in de Publisher, waarbij nodes met elkaar worden verbonden door relaties en beperkingen op deze relaties. Hiernaast een voorbeeld van een UML schema. In dit voorbeeld worden de relatie weergegeven van een persoon met een bedrijf. Dit model beschrijft een statische situatie, waarbij het mogelijk is door het model heen te navigeren. In de Publisher hebben de modellen meer een procedureel karakter, maar de grafische weergave is vergelijkbaar. [1] Zie iii. Agile Manifesto Het Agile Manifesto (Manifesto for Agile Software Development) is opgesteld tijdens een bijeenkomst van zeventien softwareontwikkelaars begin Veel ontwikkelaars beroepen zich erop dat hun aanpak agile (behendig/lenig) is. Daarmee is agile softwareontwikkeling een te gebruiken standaard geworden. De meeste agile methoden proberen risico s te verminderen door software te ontwikkelen in korte overzichtelijke perioden (timeboxes), die iteraties genoemd worden. Elke iteratie is als het ware een miniatuurproject op zichzelf, en omvat alle noodzakelijke taken: planning, analyse, ontwerp, testen en documentatie. Een iteratie levert niet altijd genoeg op om het eindproduct vrij te geven. Desondanks is het de bedoeling van een agileproject om na iedere iteratie iets bruikbaars voor de markt op te leveren. Voor software gaat dat vaak op als ze webgebaseerd is. Agile ontwikkeling levert dus steeds stukjes werkende software op, in plaats van een bigbangoplevering na een lange periode. De in het manifest genoemde samenwerking tussen business en ontwikkelaars is van groot belang voor regelintensieve systemen. Voor beslismodellen is dit dan ook een uitstekende aanpak, omdat niet alleen vrij snel resultaten getoond kunnen worden, maar ook de business zelf de ontwikkeling uitvoert. Berkeley Bridge: Richtlijnen voor een beslismodel 7

8 4. Ontwerp Beslismodel A. De schets van het beslismodel Hoewel de Publisher een zeer laagdrempelige tool is waarmee vrij snel een goed werkend beslismodel mee gemodelleerd kan worden en het beslismodel eigenlijk al het ontwerp is, verdient het aanbeveling om eerst goed na te denken over het uitwerken van een idee in een opzet van het model, vooral om onnodig werk en teleurstelling te voorkomen wanneer het model achteraf toch niet aan de verwachtingen blijkt te voldoen. Een ontwerp maken helpt daarbij. Het van te voren uittekenen van een beslismodel in een workshop met alle benodigde betrokkenen (kenniseigenaar, proceseigenaar, modelleur, etc.) helpt nadenken over de logische opbouw van een beslismodel en kan voorts als hulpmiddel dienen bij de nadere afstemming over het model met de kenniseigenaar. Dit geeft inzicht in de logische opzet van het beslismodel. Hiervoor zijn talloze meer of minder gedetailleerde, elektronische of papieren mogelijkheden beschikbaar, maar een ruwe schets van de opbouw, loop en verbanden van het programma is wel een minimaal vereiste om een beeld te krijgen van het uiteindelijke beslismodel. Hieronder is een aantal voorbeelden weergegeven: Figuur 3: Voorbeeld van een ontwerp met eenvoudige middelen (foto van een white board) Figuur 4: voorbeeld van een uitgebreidere schets van een applicatie, inclusief schermverloop. Figuur 5: voorbeeld van een al bijna volledig werkend ontwerp in PowerPoint, werking eigenlijk als een prototype Berkeley Bridge: Richtlijnen voor een beslismodel 8

9 B. Ontwerp en prototype Naast het maken van schetsen is het ook aan te raden om middels prototyping in de Publisher te proberen of gewenste (delen van) modellen te maken zijn. Dit geeft inzicht in de (on)mogelijkheden van de Publisher. Prototypes kunnen bovendien ook gebruikt worden bij de nadere afstemming tussen de verschillende betrokkenen bij het ontwerp. Een goed prototype kan bovendien bij de bouw ook hergebruikt worden (maar dat is niet het doel op zichzelf). C. Modelleerrichtlijnen In de ontwerpfase is het bovendien handig om alvast aandacht te besteden aan zaken als modelleerrichtlijnen, naamgevingconventies en metadatering van gegevens. Door de laagdrempelige manier van beslisbomen maken in de Publisher kan men snel een model maken. Stel: het model werkt en is opgeleverd door persoon x. Na een jaar verandert de wetgeving en moet persoon y het aanpassen. Persoon x werkt inmiddels elders. Het kan uitermate lastig zijn voor persoon y om de gedachtegang van persoon x te doorgronden. Wanneer het beslismodel echter volgens vastgestelde modelleerrichtlijnen gebouwd is, die door persoon y te raadplegen zijn, dan zal dit al een stuk eenvoudiger zijn voor persoon y. Enkele voorbeelden van richtlijnen in relatie tot het maken van beslismodellen met de Publisher zijn: Figuur 6: voorbeeld van een onduidelijk model; uit de nodes is niet af te leiden wat de betekenis is. Voor onderhoud zul je dus altijd de bijbehorende schermen moeten raadplegen. Berkeley Bridge: Richtlijnen voor een beslismodel 9

10 Begin met het stellen van de meest discriminatoire vragen (de algemene deler); d.w.z. stel de vraag die voor iedereen van toepassing is aan het begin en niet aan het einde van het model. Plaats vragen die slechts voor een geringe doelgroep van belang zijn zoveel mogelijk achteraan het beslispad. Stel een eenduidige naamgeving vast voor de name van nodes en graphs (naamgevingconventies). Maak de naam desnoods wat langer als dit de duidelijkheid dient. Geef nodes en graphs een betekenisvolle en declaratieve naam.[1] Houd de formulering van vragen (question) kort en bondig en voorkom dubbele ontkenningen en/of tangconstructies in de vraagstelling. Voeg een toelichting bij de vraag toe indien dat ondersteunend aan de vraag is. Vermijd echter algemeenheden in dergelijke toelichtingen (de Publisher biedt een aantal fraaie mogelijkheden voor interactieve toelichtingen). Maak verschillende soorten kennis als zodanig herkenbaar in de naamgeving (metadatering). Bijvoorbeeld de grondslag minimum loon met een prefix GSL_ gevolgd door het onderwerp (bijvoorbeeld MinLoon). Wanneer deze grondslag wijzigt, dan kunnen deze vrij eenvoudig in het beslismodel aangepast worden. Ook intern beleid en externe wetgeving kan door middel van prefixen uit elkaar gehouden worden. Een andere mogelijkheid is om deze grondslagen in eensubgraph te groeperen. Neem een bronvermelding op van de betreffende regel. Traceerbaarheid naar een specifieke regel dient niet alleen voor het beter om kunnen gaan met wijzigingen in regelgeving, maar dient ook ter verantwoording van het feit of een bepaalde regel afgedekt is. Dit kan bijvoorbeeld als information bij de node, maar zou ook opgenomen kunnen worden in de naamgeving van de node. Bedenk patronen in het beslismodel voor veelvoorkomende constructies, zodat deze makkelijk hergebruikt kunnen worden. Een te herbruiken model wordt gemodelleerd in een aparte graph (patronen is een dynamisch iets, hoe verder men beslismodellen ontwikkeld, hoe meer patronen men gaat onderkennen). Werk details alleen uit indien deze noodzakelijk zijn (granulariteit). Wanneer inkomen bijvoorbeeld een gegeven is dat als geheel ingevoerd kan worden, hoeven niet alle losse inkomenscomponenten uitgevraagd te worden. Bouw niet alles in één keer, maar verdeel het werk in los op te leveren componenten. Houd je aan het ontwerp, maar wanneer het ontwerp niet klopt, bespreek dan een aanpassing van het ontwerp. [2] Wanneer iedereen volgens dezelfde richtlijnen werkt aan beslismodellen, dan is het niet meer zo relevant welk specifiek persoon aan een model werkt. Richtlijnen kunnen bovendien in andere projecten eenvoudig hergebruikt worden. Bedenk wel dat het richtlijnen zijn, gegronde afwijking is mogelijk, maar moet wel vastgelegd worden (en leiden tot een aanpassing van de richtlijn). Berkeley Bridge: Richtlijnen voor een beslismodel 10

11 [1] Zie voor een uitleg [2] Deze lijst is niet limitatief en dient als voorbeeld van mogelijke modelleerrichtlijnen. Modelleerrichtlijnen worden in eerste instantie in workshopvorm opgesteld. Input wordt vooral gegeven door aan te geven wat men als lastig ervaart bij het modelleren. In latere projecten zijn deze richtlijnen vanzelfsprekend herbruikbaar. Berkeley Bridge: Richtlijnen voor een beslismodel 11

12 D. Overige aspecten die bij het ontwerp betrokken kunnen worden Naast een schets van de beslisboom en het vastleggen van modelleerrichtlijnen valt nog een aantal andere zaken te noemen, die van belang zijn in de ontwerpfase. De volgende punten helpen vooral de scope en omgeving van het beslismodel te bepalen: Wat is de context van het model? Beantwoording van deze vraag bakent descope van de bouw goed af. Het is aan te raden dergelijke afbakening van te voren vast te leggen om de verwachtingen ten aanzien van het eindproduct te managen. Welk probleem moet opgelost worden? Waarom wordt gekozen voor een beslismodel? Wat zijn de feitelijke knelpunten? Hierbij moet goed nagedacht worden of ook werkelijk alle benodigde input voorhanden is. Ook hier is een ontwerp een uitstekend conversatiehulpmiddel. Wat moet het product kunnen? Deze vraag wordt beantwoord in het licht van de context en het op te lossen probleem. De verschillende eisen die worden gesteld aan het model kunnen betekenen dat andere processen moeten worden herzien of moeten worden verandert. Bestaan (herbruikbare) vergelijkbare producten? Waarom het wiel opnieuw uitvinden? Wanneer een ander beslismodel herbruikbare componenten heeft, gebruik deze dan. De Publisher biedt uitgebreide copy/pastefunctionaliteit. Welke kennis moet ontsloten worden? In het kader van de scope van het beslismodel zal onderzocht moeten worden welke kennis ontsloten moet worden. Is deze kennis voorhanden? Wie is eigenaar van deze kennis? Betreft het wetgeving, beleid of expertkennis? Inzicht hierin helpt bij de domeinafbakening en voorkomt dat in de bouwfase teruggegaan moet worden naar de kenniseigenaar met de vraag wat heb ik nou eigenlijk nodig? Welke veranderingen brengt het product met zich mee? Wil het op te leveren product succesvol zijn, dan moet het gebruikt worden. Wanneer een papieren proces vervangen wordt door een digitaal dan zal dat veranderingen met zich meebrengen. Medewerkers moeten daar op voorbereid zijn en mee om kunnen gaan. Mogelijk zal dit een verschuiving van taken betekenen en wellicht hebben betreffende medewerkers nog aanvullende eisen/wensen voor het beslismodel. Betrek deze dus ook in het ontwerpproces. Wat zijn de moeilijkheden? Van te voren nadenken over welke moeilijkheden men tegen kan komen, helpt om alvast maatregelen te benoemen mocht dit zich voordoen. Vaak is bijvoorbeeld de geringe capaciteit van de expert een probleem. Dit kan voorkomen worden door van te voren afspraken in te plannen om bevindingen terug te kunnen koppelen. Houd rekening houden met complexiteit, impact en omvang. Niet alles hoeft op een digitale wijze uitgewerkt te worden. Zeker wanneer de inspanningen hiervan niet in verhouding staan tot het resultaat. Een goede afweging in het beslismodel kan voor een efficiëntere werkwijze zorgen. Denk ook alvast na over eventuele kwaliteits- en acceptatiecriteria (waar moet het systeem aan getoetst worden, wanneer voldoet het?). In het kader van begrijpelijkheid van de applicatie kun je bijvoorbeeld Berkeley Bridge: Richtlijnen voor een beslismodel 12

13 het criterium benoemen dat namen van nodes overeenkomen met de normen die deze nodes dekken. Aan acceptatie wordt in dit document nog in een apart onderdeel aandacht besteed. Wanneer deze en eventueel nog andere vragen benoemd en beantwoord zijn (deze opsomming is vanzelfsprekend niet beperkt tot de bovengenoemde punten), dan kan dit ontwerp gelden als een uitgangspunt voor het te bouwen beslismodel. Alle partijen weten nu wat ze kunnen verwachten van het beslismodel. Het modelleren kan nu beginnen. Overigens is het ontwerpen en bouwen een iteratief traject; vanuit de bouw kunnen inzichten ontstaan die een aanpassing van het ontwerp kunnen betekenen. Figuur 7: Resultaat ontwerpsessie relevante wetgeving voor vastlegging business rules t.a.v. registratie van schepen. Berkeley Bridge: Richtlijnen voor een beslismodel 13

14 5. Het bouwen van een beslismodel A. Inleiding Met het ontwerp als leidraad is bouwen (of eigenlijk modelleren) van de beslisboom een activiteit die met voldoende kennis van de Publisher redelijk snel uitgevoerd kan worden. Onder de activiteit bouwen wordt niet alleen het feitelijke beslismodel bouwen verstaan, maar ook het vullen van de content bij het beslismodel (achtergrondinformatie, juridische bronnen en teksten). Naast de bovengenoemde (op te stellen) richtlijnen is er nog een aantal algemene tips die bij het bouwen handig van pas kunnen komen. Deze worden in dit deel behandeld. B. Tips bij het bouwen van een beslismodel Als het goed is, zijn de algemene loop en de (hoofd)onderdelen van het beslismodel al in het ontwerp opgenomen, is de context en scope bepaald en is nagedacht over richtlijnen bij het modelleren, zodat de bouw kan beginnen en snel kan vorderen. Richt je eerst op de hoofdlijn van het beslismodel en vul bij volgende iteraties de details meer en meer in. Figuur 8: het kruimel- of sprongpad Bouw binnen deze hoofdlijn de als afzonderlijk te benoemen onderdelen in detail en vermijd om alles tegelijk te willen doen. Voor grotere modellen is het aan te raden om een stappenplan op te stellen van de aanpak van de verschillende onderdelen.[1] Besteed voor deze hoofdlijn aandacht aan het kruimelpad (overzicht van het model), zodat je bij het doorlopen van het beslismodel weet waar je bent. Dit is uitermate handig bij het testen van het beslismodel, een activiteit die de modelleur ook continu moet uitvoeren. Wacht hier niet mee totdat alles klaar is, want dan is het meestal lastig(er) te achterhalen waar de fout zit. Houd bij de bouw in de eerste plaats altijd de beheersbaarheid van het beslismodel in het oog: niet teveel nodes in een scherm, een logische naamgeving van de modelelementen en houd onderwerpen, die bij elkaar horen, bij elkaar. Maak modellen niet te uitgebreid of te complex en stel geen onnodige vragen. [1] Net als de activiteit testen is het hele planningsaspect en projectmanagement buiten beschouwing gelaten. Berkeley Bridge: Richtlijnen voor een beslismodel 14

15 Figuur 9: gebruik van graphs: elke deelonderwerp is opgenomen in een aparte graph. Knip complexe modellen op wanneer deze als zelfstandig onderwerp zijn te beschouwen. Maak voor deze afgebakende onderwerpen gebruik van graphs. Dit dient bovendien de herbruikbaarheid, want deze kunnen vanuit meerdere kanten aangeroepen worden. Bedenk bij het modelleren (en in het bijzonder bij complexe modellen) waarom je voor een bepaalde constructie kiest, wanneer dat niet logischerwijze uit het model blijkt (modelleerbeslissing). Leg deze modelleerbeslissingen vast (bij voorkeur in het model zelf in de yellow note, maar eventueel ook in een apart document, met verwijzing(en) naar de node(s) waar deze bijhoren), zodat de tester en degene die het beslismodel moet valideren en/of goedkeuren deze gedachtegang kan achterhalen. Ook degene die soms jaren later het model moet aanpassen/onderhouden kan deze modelleerbeslissingen goed gebruiken. Hergebruik delen van het model (of van andere beslismodellen), indien dat mogelijk is. Bijvoorbeeld persoonsgegevens, deze zijn vaak voor de verschillende personen hetzelfde. Bouw deze één keer goed voor één type persoon en kopieer deze dan. Stel eenduidige ja/nee vragen in plaats van complexe samengestelde vragen, splits vragen desnoods op. Geef deelmodellen altijd een kop (start) en een staart (einde). In veel gevallen is het doorlopen van een (deel van) het model niet meer nodig (zie hierboven bij de richtlijnen), na het stellen van een aantal vragen. Dit geeft in de modelweergave bovendien een goed overzicht in de loop van het beslismodel (vooral in combinatie met een goed doordachte naamgeving van modelelementen). Maak gebruik van datatypes voor het stellen van vragen met een waardelijst. Zo kunnen deze vragen eenvoudig hergebruikt worden. Richt daarnaast templates in voor de lay-out van de vraagschermen, zodat dit niet bij elke afzonderlijke vraag ingesteld hoeft te worden. Figuur 10: voorbeeld van een model met een start/einde: vanuit verschillende vragen (de grijsgeteinte) wordt naar het einde van het model gesprongen. Berkeley Bridge: Richtlijnen voor een beslismodel 15

16 C. Analyse van juridische vaagheden en verwijzingen Een onderwerp wat speciale aandacht verdiend bij het bouwen van juridische beslismodellen is het oplossen van vaagheden in de regelgeving en het in acht nemen van verwijzingen. Volgens de jurist is de wet helder, maar wanneer wetgeving uitgevoerd moet worden in een it-toepassing dan zul je de kennis van deze expert nodig hebben om de juiste afleidingen te kunnen maken. De expert maakt normaliter deze afwegingen in het hoofd (weet hoe de vaagheid te interpreteren of wat de verwijzing inhoudt), maar dat is een activiteit die het beslismodel niet kan uitvoeren. Een voorbeeld uit de vreemdelingenwetgeving: Ogenschijnlijk zijn dit correcte teksten. Maar bij een nadere lezing zullen de rood gearceerde vaagheden nader ingevuld moeten worden, wil je dit in een beslismodel kunnen verwerken. Het woord kan betekent dat iets kan, maar moethet of mag het? Tussen moeten en mogen zit de nodige ruimte. Wanneer is ietsredelijk of billijk? En is onmiddellijk binnen 24 uur of binnen een week? Wetgeving bestaat daarnaast voor een groot deel uit verwijzingen naar andere delen van wetgeving. Soms volstaat het om de verwijzing te laten voor wat deze is. Vooral wanneer de achterliggende regels niet relevant zijn, maar veelal moet via deze verwijzing de betreffende regel binnen het bereik van het model gehaald worden. Verwijzingen zijn vaak expliciet ( zoals bedoeld in artikel x ) maar soms ook erg impliciet, zoals in het voorbeeld hierboven ( de aanwijzingen ). Figuur 11: onduidelijkheden in wetgeving Berkeley Bridge: Richtlijnen voor een beslismodel 16

17 Kortom, terminologie kan voor meerdere uitleg vatbaar zijn en verwijzingen zijn niet altijd duidelijk. Maak deze vaagheden en verwijzingen in regelgeving dan ook zoveel mogelijk samen met de expert expliciet of benoem deze als bewuste vaagheid en besteed hier aandacht aan in de toelichting. Voeg in dat geval bijvoorbeeld jurisprudentie of een beleidsregel toe die uitleg geeft (bijvoorbeeld: in het Petorska-arrest[1] heeft de Hoge Raad onmiddellijk uitgelegd als binnen 24 uur). [1] Fictief Berkeley Bridge: Richtlijnen voor een beslismodel 17

18 6. De Rapportage A. Inleiding In dit deel wordt in detail naar de rapportage gekeken en een aantal algemene opmerkingen over rapportages afgeleid. B. Rapportfunctie van de Publisher In de Publisher is de rapportage, zoals ook al in de inleiding van dit document is opgemerkt, eigenlijk een resultante van het doorlopen van het beslismodel. Met de Add document functie in de Publisher kan op elk moment in het programma een rapport aangemaakt worden. Is het rapport daarmee klaar? Nee. Omdat de rapportage voor vele modellen het belangrijksteoutputproduct van het beslismodel is, is het ook voor de rapportage van belang om, allereerst een aantal afwegingen te maken, omdat dit van invloed kan zijn op de loop van het beslismodel. Bepaalde keuzes beïnvloeden de opzet van het beslismodel in grote mate en het is daarom verstandig om hier van te voren naar te kijken. C. Van papier naar digitaal Beslismodellen worden vaak gemaakt om een papieren stroom te vervangen met een digitale. Om deze transitie succesvol uit te voeren, moet eerst worden vastgelegd wat de karakteristieke verschillen zijn tussen het bestaande papieren product en het gewenste digitale. Verwijzingen op papier worden bijvoorbeeld intelligente vragen/beslissingen die door het beslismodel uitgevoerd worden in de digitale oplossing. Een ander aspect wat alleen op papier terugkomt, is de ondertekening. Hoe moet daarmee omgegaan worden? Volstaat het om een rapport te printen en deze alsnog handmatig te ondertekenen? In een volledig digitale omgeving (lees: zonder printen, uitsluitend elektronische verzending) zal dat niet altijd gaan (e.g. het is niet handig om een document met de online rapportfunctie van de Publisher uit te printen) en moet voor een andere oplossing gekozen worden (in de Publisher dus voor een printbaar rapport). Verzending is overigens een punt op zichzelf: wordt het rapport ook elektronisch verzonden of alleen geprint en per post verzonden? Een ander aspect is (pagina)nummering: waar in een papieren rapport men eenvoudig doorverwezen kan worden naar een onderwerp dat op pagina x staat, is dit digitaal lastig omdat het voor de intelligentie van de beslisboom niet helemaal vanzelfsprekend is dat dat ook op de verwezen pagina staat. Daar heb je echter specifieke functies voor zoals de jumplist om terug te gaan. Maar als ten volle gebruik gemaakt wordt van intelligentie in een beslismodel, wat is dan nog het nut van heen- en weer navigeren behoudens controle wat ingevuld is (en zelfs dat is niet altijd nodig, bijvoorbeeld door de mogelijkheid van tussensamenvattingen/conclusies in het beslismodel). Ditzelfde geldt voor vraagnummering; door de intelligentie in het beslismodel worden alleen de voor de casus relevante vragen gesteld. Daardoor kunnen vragen overgeslagen worden, die niet relevant zijn. Vraagnummering heeft dan geen zin, omdat dan gaten in de nummering ontstaan. Berkeley Bridge: Richtlijnen voor een beslismodel 18

19 Bedenk van te voren dan ook hoe om te gaan met de specifieke papieren elementen van het rapport. Wat is het nut van het papieren element en is deze nog wel nodig na digitalisering? Maak een analyse van de papieren eigenschappen van het bestaande rapport en bedenk hoe deze in de digitale omgeving te verwerken. In relatie tot het ontwerp van het beslismodel kan ook afgevraagd worden hoeveel intelligentie in het model gestopt moet worden. Moet het de bedoeling zijn dat alle informatie in het rapport middels slimme vraagbomen achterhaald wordt, of kan ook op bepaalde plaatsen volstaan worden met memovelden waarin extra uitleg opgenomen wordt? Soms is dit erg handig om bepaalde keuzes, of hele specifieke omstandigheden nader toe te lichten. Voor intelligent hergebruik van informatie zijn memovelden echter niet bruikbaar. Berkeley Bridge: Richtlijnen voor een beslismodel 19

20 D. Informatieschets Net als voor de beslisboom, is het handig om voor de rapportage van te voren een schets te maken, de informatieschets. Stel hierbij de vragen: wat heb ik nodig om, wat moet ik weten om, hoe kom ik aan: iedere vraag is te vertalen naar een element in het beslismodel waarin uit-gemodelleerd kan worden hoe de op te leveren informatie te achterhalen valt. Het opstellen van een informatieschets heeft als doel het ondersteunen van de communicatie met de gebruiker over de structuur en de inhoud van de benodigde informatie. Deze schets toont alle relevante onderdelen eventueel in de vorm van concrete voorbeelden, of juist betekenisloze teksten ( lorum ipsum ) als het alleen om lay-out gaat. Ook de structuur wordt getoond in de schets aan de rechterkant. Bij het uitwerken van de informatieschets wordt top-down gewerkt. Het ontwerp van de rapportage wordt steeds verder opgedeeld in groeperingen die ieder op zich nog betekenisvol zijn. Figuur 12: voorbeeld van een vrij algemene schets van een formulier voor aanvraag van een vergunning. In de marges is aangegeven wat de herkomst is van de formulierdelen. Bijvoorbeeld: de Schadesamenvatting wordt onderverdeeld in de onderdelen Zonder ongeval, Na ongeval en Berekeningsgegevens. Binnen deze groepen valt weer een verdere verdeling te maken naar loongegevens, pensioengegevens, belastinggegevens. Ook deze onderdelen zijn weer onder te verdelen. Voor elke te onderscheiden groep wordt onderzocht onder welke condities de informatie in het rapport verschijnt. Daarnaast wordt ook het aantal iteraties van de groep(en) bepaald (hoeveel verschillende dienstverbanden kan iemand hebben?). Deze condities en iteraties worden verwerkt in het beslismodel. De Berkeley Bridge: Richtlijnen voor een beslismodel 20

21 informatieschets zal doorgaans redelijk 1-op-1 het ontwerp van het beslismodel volgen. Maar mogelijk is het niet wenselijk om alle gestelde vragen van de beslisboom op te nemen in de rapportage (denk bijvoorbeeld aan stuurvragen). De informatieschets is dan ook onlosmakelijk verbonden met het ontwerp van het beslismodel, aangezien het beslismodel eigenlijk bepaalt wat in het rapport kankomen, maar vanuit het rapport bekeken moet worden wat in het beslismodel uitgevraagd moet worden. Zo nodig moet het beslismodel dan aangepast worden om de gewenste gegevens in het rapport te krijgen. Ook kan overwogen worden om het rapport anders in te richten, wanneer een dergelijke aanpassing tot ongewenste resultaten in het beslismodel zal leiden. Figuur 13: voorbeeld waarin in de schets al rekening is gehouden met feitelijke teksten en opmaak. Berkeley Bridge: Richtlijnen voor een beslismodel 21

22 E. Modelleerrichtlijnen Ook voor het opstellen van de rapportage gelden modelleerrichtlijnen, aangezien rekening gehouden moet worden met de eventuele beperkingen en (on)mogelijkheden van de weer te geven kennis vanuit de beslisboom. Een greep hieruit:[1] Wat zijn de vaste tekstblokken (d.w.z. welke worden niet intelligent bepaald in het beslismodel? Welke van deze teksten wil je wel/niet in het beslismodel zien? Houdt rekening met een logische volgorde (van algemeen naar specifiek) in de indeling van het rapport. Lijn (financiële) gegevens uit ten behoeve van de leesrust. Formuleren van rubrieksomschrijvingen zoveel mogelijk even lang definiëren, om te voorkomen dat het rapport een rommelig aanzien krijgt. De afstand tussen omschrijving en rubriek wordt kleiner en daarmee de lay-out duidelijker. Is het nodig dat het product geprint moet worden (in dat geval is formaat staand meer geschikt dan liggend (voor brede tabellen is liggend weer meer geschikt). Etcetera [1] Ook deze richtlijnen worden in een ontwerpsessie opgesteld. Beantwoord vooraleerst de vraag hoe wil ik dat het rapport eruit ziet?. Op basis daarvan kunnen vervolgens nadere richtlijnen geformuleerd worden. F. Extra informatie en lay-out Meestal zal je wel het hele beslismodel doorlopen willen hebben om een rapport op te kunnen stellen; gegevens die na het maken van het rapport nog uitgevraagd worden, kunnen immers niet in het rapport komen. Naast de inhoud van het beslismodel is bij het configureren van de output het verder nog mogelijk om extra tekst toe te voegen (dit is niet aan te raden omdat deze tekst niet uit het beslismodel zelf komt) of de lay-out nader vorm te geven (bijvoorbeeld om te voldoen aan de huisstijl). Ook voor het onderhoud is het handiger om deze extra informatie in het beslismodel zelf op te nemen. Zo houd je bovendien die informatie ook bij het deel van het model waar het bij hoort. Berkeley Bridge: Richtlijnen voor een beslismodel 22

23 G. Specifieke opmerkingen in relatie tot de huidige rapportage i. Rapport als basis voor ontwerp Het verdient aanbeveling om het rapport als basis voor het ontwerp van het beslismodel te nemen, maar neem wel de verschillen tussen papier en digitaal in ogenschouw. Let ook op dat het rapport de weergave van een casus is en dus waarschijnlijk niet alle mogelijke informatie zal bevatten. Voor het ontwerp van het beslismodel zijn alle mogelijke routes in de beslisboom nodig. Het rapport is nu vooral verhalend van opzet. Daar is een beslismodel niet helemaal geschikt voor, tenzij alle secties via memovelden ingevoerd worden. In dat geval is er niet echt meer sprake van een beslismodel, maar meer van een invoermodule. Probeer hier dan ook zoveel mogelijk vragen voor op te stellen en vanzelf ook zoveel mogelijk onderlinge samenhang (intelligentie) daartussen. Het rapport met vrije tekst wordt daarmee een product met gestructureerde informatie. Het voordeel van gestructureerde informatie is bovendien deze informatie dan altijd op dezelfde plaats staat. Het rapport kan op die manier dan ook sneller en gerichter gelezen worden. ii. Inbouwen intelligentie Het opzetten van een tekst naar een logisch beslismodel kan lastig zijn, de logische verbanden zijn niet altijd eenvoudig te herkennen. Probeer in de ontwerpfase deze verbanden eerst uit te tekenen. Een paar voorbeelden op basis van signaalwoorden (deel tussen ) wordt gegeven: Een zinsdeel waar zoals blijkt in voorkomt, suggereert dat informatie valt af te leiden. Modelleer deze informatie uit en gebruik deze informatie om dergelijke afleidingen te doen. Een zin met vanaf duidt erop dat vanaf deze datum een verandering plaats heeft gevonden / zal vinden. In het kader van beslismodellen worden dit tijdsversies of tijdreizen genoemd. Dit is in het juridisch domein een veel voorkomende situatie. De Publisher biedt verscheidene mogelijkheden om hiermee om te gaan: Zo kan er per norm voor elke periode een afzonderlijke berekening gemaakt worden, waarin als voorwaarde de periode wordt gebruikt. In de source kan deze methode eventueel nog met een if then begin / end worden vereenvoudigd, zodat de periodevoorwaarde maar eenmaal gebruikt hoeft te worden in plaats van bij elke berekening opnieuw. Je kan de normen ook extern opslaan, bijvoorbeeld in een database. Bij het inlezen uit die database bepaald je dan aan de hand van de periode welke rij ingelezen moet worden. Er kan een kopie van de gehele graph gemaakt worden met daarin zowel het beslismodel als de van toepassing zijnde normen. Afhankelijk van de periode doorloop je dan de juiste graph. Je kan ook verschillende versies van het model maken. Denk aan de aangifteprogramma s van de Belastingdienst. Dat matcht vaak ook met de praktijk, namelijk het verstrekken van een licentie per versie/jaar. Berkeley Bridge: Richtlijnen voor een beslismodel 23

24 Bepaal van te voren dus goed welke gegevens uitgevraagd moeten worden, welke gegevens af te leiden zijn, wat precies de grondslagen zijn en hoe de informatie getoond moet worden. Kortom, maak een ontwerp/informatieschets. iii. Tussenconclusies Het is een optie om voor de deelonderwerpen in het beslismodel gebruik te maken van tussenconclusies voor een overzicht van afgeleide elementen. Dit is enerzijds voor de gebruiker van het systeem handig, zodat bekend is met welke informatie de afleidingen gedaan worden, maar ook voor het maken van de rapportage. Deze afleidingen kunnen in het rapport hergebruikt worden en overzichtelijk getoond worden. Maak hierin vooral ook duidelijk met welke informatie de afleidingen zijn gemaakt, zodat dit altijd valt te valideren. Bovendien blijft het beslismodel zo ook overzichtelijk, omdat het voor de gebruiker duidelijk is waar hij is in het programma en wat met de gegevens gedaan wordt. iv. Gebruik waardelijsten Maak vooral gebruik van waardelijsten bij de invoer in het beslismodel (de Publisher biedt hier tal van mogelijkheden voor, variërend van ja/nee-drop down menus tot volledig te configureren radiobuttons). De specifieke waarde van een dergelijke lijst kan in een ander deel van de beslisboom weer hergebruikt worden (zoals hierboven al eerder aangestipt, is hergebruik van de inhoud van memovelden een stuk lastiger). Een ander voordeel is dat er geen waarde ingevoerd kan worden, die niet bestaat of die net even anders geformuleerd is, maar hetzelfde betekent; de Publisher toont alleen de mogelijke verwijzingen. Ook bedragen en percentages worden als numerieke gegevens ingevoerd om mee te kunnen rekenen. Daar waar het echt nodig is om situaties nader toe te lichten kunnen vanzelfsprekend memovelden toegevoegd worden. H. Bewijsstukken Rapportages kunnen worden aangevuld met een aantal bewijsstukken, zoals bijvoorbeeld een loonstrook etc. Probeer in de (tussen)conclusies ook af te leiden welke documenten als bewijsstukken toegevoegd moeten worden. Het beslismodel levert dan dus een checklist op voor relevante documenten. I. Import/Export rekengegevens Het kan voorkomen dat het rapport uit verschillende delen bestaat waarin veel verschillende informatie moet worden ingevuld. Het complete rapport kan dan erg onoverzichtlijk voorkomen. Met het beslismodel zijn hier verschillende oplossingen voor. De eenvoudigste is om simpelweg een aparte rapportage te maken, waarin alleen een bepaald deel van de invoer wordt weergegeven. In datatypiste kan dan met de verscheidene deelrapporten gemakkelijk aan de slag. De beslisboom heeft immers de afleiding gedaan van alle relevante invoergegevens. Berkeley Bridge: Richtlijnen voor een beslismodel 24

25 Een meer geautomatiseerde oplossing is om een interface te bouwen welke bepaalde gegevens van een webserver haalt. Handmatige invoer van deze gegevens is dan niet meer nodig. Andersom is deze opmerking ook te maken. Een aantal gegevens komt uit gestructureerde overzichten, zoals loonstroken, pensioenoverzichten of salarisadministraties. Om invoer in het beslismodel te versnellen zou deze gestructureerde informatie uit andere systemen ingelezen kunnen worden. Met deze informatie wordt dan in het beslismodel rekening gehouden. Ook hier geldt, net zoals hierboven, dat dit een punt van nader onderzoek is. Ook al zijn vele standaarden geformuleerd in de wereld van de automatisering, helaas kunnen nog niet alle systemen eenvoudig met elkaar communiceren. Berkeley Bridge: Richtlijnen voor een beslismodel 25

26 7. Acceptatie Beslismodel A. Acceptatiecriteria Na een rondgang langs ontwerp, bouw, het maken van een rapportage en waarschijnlijk een aantal keren terug naar het ontwerp en (her)bouw is het beslismodel klaar. Maar wanneer is een beslismodel echt klaar en hoe kan dat gemeten worden? De vraag die nu dan nog gesteld moet worden is of de uitkomst van het model ook de verwachte uitkomst is? Verwachte uitkomst heeft al in zich dat degene die accepteert bepaalde verwachtingen heeft. Het is verstandig om deze verwachtingen al voor de bouw in kaart te hebben, zodat de modelleur hier al van te voren rekening mee kan houden. Deze verwachtingen bestaan vaak voor een deel uit de verwachte functionaliteit, de persoonlijke verwachtingen, zoals het ontwerp, maar ook of de rekenuitkomsten voldoen en andere nietfunctionele eisen zoals de lay-out en privacy-eisen. Dit bij elkaar worden de acceptatiecriteria genoemd. Deze helpen de eindbeslisser bij het geven van zijn/haar acceptatie op het opgeleverde model. B. Algemene richtlijnen uit de praktijk Ook ten aanzien van acceptatiecriteria zijn standaarden ontwikkeld, zodat niet voor elk systeem opnieuw de volledige set bedacht hoeft te worden. Hieronder een aantal aandachtspunten bij de acceptatie van een beslismodel, voor een deel gebaseerd op de norm ISO/IEC 9126: Een beslismodel is begrijpelijk: dit wordt verstaan in het licht van de doelgroep. Voor een groep van expertgebruikers kan de terminologie ingewikkelder zijn dan wanneer niet inhoudelijk deskundigen het beslismodel gebruiken. De overheid hanteert bijvoorbeeld taalniveau eenvoudig Nederlands als richtlijn voor haar formulieren. Een beslismodel moet toepasbaar zijn. Het moet de werkelijkheid zodanig weergeven dat het voldoende basis biedt voor de gewenste acties. Voor een geldig rijbewijs geldt bijvoorbeeld dat deze een pasfoto moet bevatten. Maar niet elke pasfoto is geschikt op een rijbewijs. Je gezicht moet in een bepaalde hoek zichtbaar zijn, je mag geen hoofddeksel dragen. De vraag of een pasfoto aanwezig is dus niet voldoende en is dus geen gewenste actie, aangezien nadere eisen te benoemen zijn aan de foto. Een beslismodel is waarheidsgetrouw als het een correcte afspiegeling van de beschreven situatie vormt. Voor het toetsen van de waarheidsgetrouwheid is de traceerbaarheid van de kennis in beslismodellen erg belangrijk. Dit betreft de bron van de kennis (bijvoorbeeld wet- en regelgeving), maar ook de historie van deze kennis (is het beslismodel veranderd en zo ja wanneer en door wie (versiebeheer)). Als de kennis in een beslismodel niet traceerbaar is, kan de waarheidsgetrouwheid van dit kennismodel nooit voldoende worden bevonden. Een beslismodel is onderhoudbaar. Beslismodellen moeten gemakkelijk en snel aan te passen zijn naar aanleiding van veranderingen in wetgeving of beleid. Berkeley Bridge: Richtlijnen voor een beslismodel 26

27 Een beslismodel is volledig en bevat dan ook alle informatie voor het betreffende doel. Hierbij moet aan één kant gekeken worden of informatie ontbreekt in de beslismodellen en aan de andere kant of er niet te veel irrelevantie informatie is. Berkeley Bridge: Richtlijnen voor een beslismodel 27

28 8. Bijlage Berkeley Bridge: Richtlijnen voor een beslismodel 28

29 Berkeley Bridge: Richtlijnen voor een beslismodel 29

ABN AMRO Verzekeringen Project: Documentbeheer Verzekeringen

ABN AMRO Verzekeringen Project: Documentbeheer Verzekeringen Opdrachtformulering Het in kaart brengen van de structuur achter verzekeringsdocumenten met het doel deze op een efficiënte manier productief te maken in een daarvoor te realiseren tool. De applicatie

Nadere informatie

Nederland haalt de XBRL buit nog niet binnen. Door Ron van Ardenne

Nederland haalt de XBRL buit nog niet binnen. Door Ron van Ardenne Nederland haalt de XBRL buit nog niet binnen. Door Ron van Ardenne Ondanks de belofte die extensible Business Reporting Language (XBRL) inhoudt, blijft het gebruik ervan beperkt. Softwareontwikkelaars

Nadere informatie

Canonieke Data Modellering op basis van ArchiMate. Canonieke Data Modellering op basis van Archimate Bert Dingemans

Canonieke Data Modellering op basis van ArchiMate. Canonieke Data Modellering op basis van Archimate Bert Dingemans Canonieke Data Modellering op basis van ArchiMate Canonieke Data Modellering op basis van Archimate Bert Dingemans Abstract Modelleren op basis van de open standard ArchiMate is een goed uitgangspunt voor

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

Handleiding RoosterGenerator

Handleiding RoosterGenerator Inleiding Handleiding RoosterGenerator, deel II Handleiding RoosterGenerator Deel II: Aan de slag met RoosterGenerator De module RoosterGenerator is bedoeld als aanvulling op het maken van een competitie

Nadere informatie

De beheerrisico s van architectuur

De beheerrisico s van architectuur De beheerrisico s van architectuur Een overzicht van de ArChimate Risico Extensie versie 0.2 Bert Dingemans Inleiding Het implementeren van een (enterprise) architectuur brengt altijd risico s met zich

Nadere informatie

Methodiek. Versie: 16/05/2012 13:42:35

Methodiek. Versie: 16/05/2012 13:42:35 Methodiek Versie: 16/05/2012 13:42:35 Inhoudsopgave Methodiek... 2 Onze visie op het functioneel ontwerp... 2 Stappen in het ontwerpproces... 3 Methodiek Inleiding In dit deel van de encyclopedie wordt

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

4.1 Simulatie in de analysefase

4.1 Simulatie in de analysefase 1 Bijlage 4 Simulatietechnieken Simulatie is een toetstechniek waarmee door middel van het nabootsen van een bepaalde situatie (bijvoorbeeld een herontworpen bedrijfsproces) in een afgeschermde omgeving

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

Portal Planning Process

Portal Planning Process BROCHURE Portal Planning Process SAMENWERKEN AAN EEN WAARDEVOL PORTAAL BROCHURE PORTAL PLANNING PROCESS 2 Axians PORTAL PLANNING PROCESS BROCHURE Inhoud Introductie 4 3 Portal Planning Process 5 4 Uitdagingen

Nadere informatie

PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D

PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D Auteur : P. van der Meer, Ritense B.V. Datum : 17 juli 2008 Versie : 1.3 2008 Ritense B.V. INHOUD 1 VERSIEBEHEER...1 2 PROJECT

Nadere informatie

Whitepaper. One language, one source, one truth

Whitepaper. One language, one source, one truth Whitepaper One language, one source, one truth Contact Voor meer informatie of een demo kunt u contact opnemen met John Vermolen of Bas de Graaf: 06-53943650 / 06-53289168 Postbus 79075, 1070 NC Amsterdam

Nadere informatie

BIM Laatste BIM ontwikkelingen efficiency, kwaliteit en euro s. A.M. Slockers Admea / Smits van Burgst

BIM Laatste BIM ontwikkelingen efficiency, kwaliteit en euro s. A.M. Slockers Admea / Smits van Burgst BIM Laatste BIM ontwikkelingen efficiency, kwaliteit en euro s A.M. Slockers Admea / Smits van Burgst Voorstellen Anton Slockers Directeur Admea / Smits van Burgst Admea is onderdeel van de Smits van Burgst

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

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

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

Microsoft Excel. It s all about Excel - VBA

Microsoft Excel. It s all about Excel - VBA X Microsoft Excel Stap in de wereld van Visual Basic for Applications (VBA) binnen het Microsoft Office programma Excel. Leer hoe deze programmeertaal precies in elkaar zit en hoe u deze in de dagelijkse

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

Van Samenhang naar Verbinding

Van Samenhang naar Verbinding Van Samenhang naar Verbinding Sogeti Page 2 VAN SAMENHANG NAAR VERBINDING Keuzes, keuzes, keuzes. Wie wordt niet horendol van alle technologische ontwikkelingen. Degene die het hoofd koel houdt is de winnaar.

Nadere informatie

Bedrijfssystemen vervangen door Slim Software Nabouwen

Bedrijfssystemen vervangen door Slim Software Nabouwen Bedrijfssystemen vervangen door Slim Software Nabouwen Codeless White Paper Roland Worms, Directeur Wouter van der Ven, Lead Software Architect Inhoudsopgave 1. Introductie 2. Het IT dilemma. Als standaard

Nadere informatie

Afstudeeronderwerpen Lex Wedemeijer

Afstudeeronderwerpen Lex Wedemeijer Afstudeeronderwerpen Lex Wedemeijer Hierbij een aantal onderwerpen die wellicht geschikt zijn als afstudeeronderwerp. Het accent van mijn onderzoek ligt op het (steeds beter) ondersteunen van bedrijfsprocessen,

Nadere informatie

Handleiding OSIRIS Self Service. Schermen en procedures in OSIRIS voor docenten en studenten

Handleiding OSIRIS Self Service. Schermen en procedures in OSIRIS voor docenten en studenten Schermen en procedures in OSIRIS voor docenten en studenten Onderhoud en versiebeheer Dit document is eigendom van de projectleider Implementatie Osiris Volg. Wijzigingen aan het document worden geïnitieerd

Nadere informatie

Whitepaper Intranet 2

Whitepaper Intranet 2 Intranet 2 Maakt uw oranisatie kleiner Inleiding - Wat is Intranet 2? Laat u direct uit de droom helpen: Intranet 2 is niet iets fundamenteel nieuws. Uiteindelijk is het nog steeds een middel om bepaalde

Nadere informatie

Elektronisch factureren

Elektronisch factureren Elektronisch factureren Inleiding Elektronisch Factureren in RADAR is mogelijk vanaf versie 4.0. Deze module wordt niet standaard meegeleverd met de RADAR Update maar is te bestellen via de afdeling verkoop

Nadere informatie

CaseMaster CRM Customer Relationship Management

CaseMaster CRM Customer Relationship Management CaseMaster CRM Customer Relationship Management CaseMaster CRM Meer omzet uit uw bestaande of nieuwe relaties halen of een klantprofiel samenstellen doormiddel van een analyse op het aankoopgedrag en vervolg

Nadere informatie

De bouwtekening. Datum: Auteur: Alibox. Bouwtekening, pagina 1

De bouwtekening. Datum: Auteur: Alibox. Bouwtekening, pagina 1 De bouwtekening Alibox is een programma voor advocaten en particulieren om alimentatie te berekenen. Het rapport van de werkgroep alimentatienormen is de basis voor Alibox. Op basis van dit rapport gecombineerd

Nadere informatie

Release datum: 11 juni 2012

Release datum: 11 juni 2012 Highlights 1 HSExpert versie 5.2 Begin juni is versie 5.2 van HSExpert gereleased. In versie 5.2 zijn vooral wijzigingen op het RiAxion (Arbo) dossier doorgevoerd. Daarnaast zijn er wat kleinere wijzigingen

Nadere informatie

HET PROJECTPLAN. a) Wat is een projectplan?

HET PROJECTPLAN. a) Wat is een projectplan? HET PROJECTPLAN a) Wat is een projectplan? Vrijwel elk nieuw initiatief krijgt de vorm van een project. In het begin zijn het wellicht vooral uw visie, ideeën en enthousiasme die ervoor zorgen dat de start

Nadere informatie

Oplossingsvrij specificeren

Oplossingsvrij specificeren Oplossingsvrij specificeren ir. J.P. Eelants, projectmanager Infrabouwproces CROW Samenvatting De methodiek van oplossingsvrij specificeren richt zich niet alleen op het formuleren van functionele eisen.

Nadere informatie

Competenties met indicatoren bachelor Civiele Techniek.

Competenties met indicatoren bachelor Civiele Techniek. Competenties met indicatoren bachelor Civiele Techniek. In de BEROEPSCOMPETENTIES CIVIELE TECHNIEK 1 2, zijn de specifieke beroepscompetenties geformuleerd overeenkomstig de indeling van het beroepenveld.

Nadere informatie

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil

Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil Scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum scrumscrumscrumscrumscrumscrum agileagileagileagileagileagileagileagil eagileagileagileagileagileagileagileagi leagileagileagileagileagileagileagileag

Nadere informatie

SmartScrum: Agile én duurzaam

SmartScrum: Agile én duurzaam SmartScrum: Agile én duurzaam SmartScrum: slimmer, sneller, goedkoper! 20% tot 30% snellere time-to-market 20% tot 30% kostenbesparing 100% voorspelbaar 100% duurzaam 100% begrijpelijk PNA Group lanceert

Nadere informatie

SQL Plan Management in Oracle11g Harald van Breederode

SQL Plan Management in Oracle11g Harald van Breederode SQL Plan Management in Oracle11g Harald van Breederode Sinds de introductie van de Cost Based Optimizer (CBO) in Oracle7 hebben zowel database beheerders als database ontwikkelaars de wens om deze optimizer

Nadere informatie

Change Management. beschrijving van procedures

Change Management. beschrijving van procedures Change Management beschrijving van procedures Aan: Projectgroep Ontwikkeling FlorEcom (PROF) Van: G. Heemskerk Betreft: FlorEcom change management Versie: 1.3 Datum: 31 januari 2002 1. Inleiding Deze notitie

Nadere informatie

STAPPENPLAN: ONTWIKKELEN VAN VRAAGGERICHTE MODULAIRE ZORG EN DIENSTVERLENING

STAPPENPLAN: ONTWIKKELEN VAN VRAAGGERICHTE MODULAIRE ZORG EN DIENSTVERLENING STAPPENPLAN: ONTWIKKELEN VAN VRAAGGERICHTE MODULAIRE ZORG EN DIENSTVERLENING Inhoudsopgave Inleiding Stap 1: Identificeren van doelgroepen en hun behoeften Stap 2: Samenstellen multidisciplinaire projectgroep

Nadere informatie

Het digitaal samenstellen en uniformeren van projectdocumentatie.

Het digitaal samenstellen en uniformeren van projectdocumentatie. Het digitaal samenstellen en uniformeren van projectdocumentatie. As-Built Documentatie digitaal op orde Als uw bedrijf actief is in de Marine, Off-Shore, energie of chemische industrie, dan heeft u voor

Nadere informatie

geen dag zonder een goed CV White Label

geen dag zonder een goed CV White Label White Label Als intermediair, detacheringorganisatie of uitzendbureau bestaat uw core business uit het verzamelen, beoordelen en herlabelen van CV s. Met name het herlabelen van CV s is een van de punten

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

case: toestandsdiagrammen

case: toestandsdiagrammen Hoofdstuk 13 case: toestandsdiagrammen In dit hoofdstuk wordt het maken van de eerste versie van de toestandsdiagrammen voor het boodschappensysteem van Hans en Jacqueline uitgewerkt. 13.1 Vind klassen

Nadere informatie

De SYSQA dienst auditing. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

De SYSQA dienst auditing. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. De SYSQA dienst auditing Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3

Nadere informatie

HANDLEIDING TOOLS4EVER ISUPPORT ONLINE WEBOMGEVING

HANDLEIDING TOOLS4EVER ISUPPORT ONLINE WEBOMGEVING HANDLEIDING TOOLS4EVER ISUPPORT ONLINE WEBOMGEVING Inhoudsopgave 1. Belangrijkste spelregels... 3 2. Contact met tools4ever international support... 4 isupport webomgeving... 4 Eerste maal inloggen...

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

ACCEPETEREN RESERVERING

ACCEPETEREN RESERVERING E-mail Templates In i-reserve is het mogelijk gestandaardiseerde e-mails te verzenden. Het verzenden van dergelijke mails kan volledig worden geautomatiseerd: u maakt dan gebruik van zogenaamde automatische

Nadere informatie

6. Project management

6. Project management 6. Project management Studentenversie Inleiding 1. Het proces van project management 2. Risico management "Project management gaat over het stellen van duidelijke doelen en het managen van tijd, materiaal,

Nadere informatie

ORGANISATORISCHE IMPLENTATIE BEST VALUE

ORGANISATORISCHE IMPLENTATIE BEST VALUE ORGANISATORISCHE IMPLENTATIE BEST VALUE EEN ONDERZOEK NAAR DE IMPLEMENTATIE VAN BEST VALUE BINNEN EEN SYSTEMS ENGINEERING OMGEVING STEPHANIE SAMSON BEST VALUE KENNIS SESSIE WESTRAVEN 17 JUNI 09.00 12.00

Nadere informatie

Whitepaper implementatie workflow in een organisatie

Whitepaper implementatie workflow in een organisatie Whitepaper implementatie workflow in een organisatie Auteur: Remy Stibbe Website: http://www.stibbe.org Datum: 01 mei 2010 Versie: 1.0 Whitepaper implementatie workflow in een organisatie 1 Inhoudsopgave

Nadere informatie

Marlin Family. Marlin

Marlin Family. Marlin PCA Mobile PCA Mobile Organisatie PCA Mobile BV maakt deel uit van de Mobile Solution Group en biedt met ruim 40 enthousiaste collega s een veelomvattend pakket van innovatieve en gebruiksvriendelijke

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

Bijlage 9. UNI 120621.9 REB GD. Releasebeleid

Bijlage 9. UNI 120621.9 REB GD. Releasebeleid Releasebeleid Ondanks alle aan de samenstelling van de tekst bestede zorg, kan Newway Retail Solutions bv (Newway) géén enkele aansprakelijkheid aanvaarden voor eventuele directe en/of indirecte schade,

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

Functioneel applicatiebeheer in het ziekenhuis

Functioneel applicatiebeheer in het ziekenhuis Functioneel applicatiebeheer in het ziekenhuis Auteur : Liesbeth van Erp Review : Hugo Roomans, Winnifred de Keizer Versie : 1.0 Datum : 1 oktober 2009 Bruggebouw Bos en Lommerplein 280 Postbus 9204 1006

Nadere informatie

Draaiboek Invoering Basisregistratie Personen l Afnemers

Draaiboek Invoering Basisregistratie Personen l Afnemers Draaiboek Invoering Basisregistratie Personen l Afnemers Van Oriëntatie naar Gebruik van de BRP Inleiding & toelichting op de vijf hoofdstappen Publicatiedatum: oktober 2014 Ten geleide Voor u ligt de

Nadere informatie

Rapportages instellen

Rapportages instellen Versie 2.0 Introductie In Finchline is het mogelijk om over de ingestelde widgets (grafische weergaven) een rapportage te ontvangen en versturen in PDF of Excel. In deze handleiding komen alle opties,

Nadere informatie

Handleiding helpdesk. Datum: 08-10-2014 Versie: 1.0 Auteur: Inge van Sark

Handleiding helpdesk. Datum: 08-10-2014 Versie: 1.0 Auteur: Inge van Sark Datum: 08-10-2014 Versie: 1.0 Auteur: Inge van Sark Inhoudsopgave Inhoudsopgave... 2 1. Beheer helpdesk... 3 1.1. Settings... 3 1.2. Applicaties... 4 1.3. Prioriteiten... 5 1.4. Gebruik mailtemplates...

Nadere informatie

Opfrisdocument elektronische aangifte

Opfrisdocument elektronische aangifte Opfrisdocument elektronische aangifte Inleiding: Omdat wij regelmatig vragen krijgen over de elektronische aangifte, hebben wij e.e.a. maar eens voor u op een rijtje gezet. Uitgangspunt van dit document

Nadere informatie

Les F-02 UML. 2013, David Lans

Les F-02 UML. 2013, David Lans Les F-02 UML In deze lesbrief wordt globaal beschreven wat Unified Modeling Language (UML) inhoudt. UML is een modelleertaal. Dat wil zeggen dat je daarmee de objecten binnen een (informatie)systeem modelmatig

Nadere informatie

BRP-BZM Business Rule Guidelines

BRP-BZM Business Rule Guidelines BRP-BZM Business Rule Guidelines Versie 2.0 02-09-2011 Definitef Versiehistorie Datum Versie Omschrijving Auteur November 1.0 Eerste versie Eric Lopes Cardozo 2011 22-7-2011 1.1 Nette variant van business

Nadere informatie

PRINCE2 2009 is overzichtelijker

PRINCE2 2009 is overzichtelijker PRINCE2 2009 is overzichtelijker 29 mei 2009 door: Lia de Zoete en Reinier de Koning Half juni presenteert het Office of Government Commerce in Londen PRINCE2 2009. Het grote voordeel van de nieuwe versie

Nadere informatie

PlanCare Dossier V11.4 Carrouselkaarten. Inhoudsopgave

PlanCare Dossier V11.4 Carrouselkaarten. Inhoudsopgave Inhoudsopgave Inleiding... 2 maken... 2 Matrixkaart... 3 Open vragen kaart... 5 wijzigen... 6 verwijderen... 7 gebruiken... 7 Handelingen met huidige selectie... 8 PlanCare Dossier V11.4 - Pagina 1 van

Nadere informatie

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. BISL Business Information Services Library Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2

Nadere informatie

Eerste uitwerking strategisch thema 'Betrouwbare digitale informatie is de basis'

Eerste uitwerking strategisch thema 'Betrouwbare digitale informatie is de basis' Eerste uitwerking strategisch thema 'Betrouwbare digitale informatie is de basis' versie 30 augustus 2013 De beschikbaarheid van betrouwbare digitale overheidsinformatie is de basis voor het goed kunnen

Nadere informatie

Handleiding voor aansluiten op Digilevering

Handleiding voor aansluiten op Digilevering Handleiding voor aansluiten op Digilevering Versie 1.0 Datum 1 augustus 2013 Status definitief Colofon Projectnaam Digilevering Versienummer 1.0 Contactpersoon Servicecentrum Logius Organisatie Logius

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

Protocol Bouwen in het gesloten seizoen aan primaire waterkeringen

Protocol Bouwen in het gesloten seizoen aan primaire waterkeringen Protocol Bouwen in het gesloten seizoen aan primaire waterkeringen Plan van Aanpak POV Auteur: Datum: Versie: POV Macrostabiliteit Pagina 1 van 7 Definitief 1 Inleiding Op 16 november hebben wij van u

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

MA!N Rapportages en Analyses

MA!N Rapportages en Analyses MA!N Rapportages en Analyses Auteur Versie CE-iT 1.2 Inhoud 1 Inleiding... 3 2 Microsoft Excel Pivot analyses... 4 2.1 Verbinding met database... 4 2.2 Data analyseren... 5 2.3 Analyses verversen... 6

Nadere informatie

Exporteren naar imuis versie 4.2.3. of hoger

Exporteren naar imuis versie 4.2.3. of hoger Exporteren naar imuis versie 4.2.3. of hoger Inhoud Keuzes in werken met combinatie The Nanny & imuis... 1 Automatische koppeling... 2 Controle stappen... 2 Exporteren machtigingen vanuit The Nanny...

Nadere informatie

Welkom! Christiane Buschman (IND) Cornelie Kagenaar (IND) Rosalie van Oostrom (Juris) Tim Klein Robbenhaar (Juris)

Welkom! Christiane Buschman (IND) Cornelie Kagenaar (IND) Rosalie van Oostrom (Juris) Tim Klein Robbenhaar (Juris) Welkom! Christiane Buschman (IND) Cornelie Kagenaar (IND) Rosalie van Oostrom (Juris) Tim Klein Robbenhaar (Juris) Agenda Voorbereiding Doelstellingen Wat doet Juridische Analyse en Begrippen (JA&B) De

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 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

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

1 Inleiding. 3 Handmatig... invoeren zaken basis 4 Verwerken... zaken 5 Afhandelen... van zaken. 7 Uitgebreidere... zaak opties

1 Inleiding. 3 Handmatig... invoeren zaken basis 4 Verwerken... zaken 5 Afhandelen... van zaken. 7 Uitgebreidere... zaak opties 2 Supportdesk Pro Introductie Inhoudsopgave I Supportdesk Pro 3 1 Inleiding... 3 2 Werkwijze... 3 II Zaken 4 1 Introductie... 4 2 Zaken beheren... 4 3 Handmatig... invoeren zaken basis 4 4 Verwerken...

Nadere informatie

Applicatierationalisatie? Probeer het eens met BPM

Applicatierationalisatie? Probeer het eens met BPM Applicatierationalisatie? Probeer het eens met BPM Applicatierationalisatie? Probeer het eens met BPM Vrijwel iedere CIO streeft naar lagere kosten en een grotere flexibiliteit van de IT-omgeving. Organisaties

Nadere informatie

Dit voorbeeldproject beschrijft het gebruik van web services (open standaarden) voor de ontsluiting van kernregistraties bij de gemeente Den Haag.

Dit voorbeeldproject beschrijft het gebruik van web services (open standaarden) voor de ontsluiting van kernregistraties bij de gemeente Den Haag. Voorbeeldproject Een Haagse SOA Dit voorbeeldproject beschrijft het gebruik van web services (open standaarden) voor de ontsluiting van kernregistraties bij de gemeente Den Haag. Aanleiding Vanuit de visie

Nadere informatie

Data Governance van visie naar implementatie

Data Governance van visie naar implementatie make connections share ideas be inspired Data Governance van visie naar implementatie Frank Dietvorst (PW Consulting) deelprogrammamanager Caesar - Vernieuwing Applicatie Landschap Leendert Paape (SAS

Nadere informatie

BIJLAGE A: TAAK 1: IMPLEMENTATIE PECKELSHEIM Voor de uitvoering van deze taak waren in het projectvoorstel de activiteiten in Tabel B.1 gedefinieerd. Tabel A.1: Activiteiten Taak 1 1.1. Aanpassen en complementeren

Nadere informatie

Tien tips voor canonieke datamodellering. Bert Dingemans

Tien tips voor canonieke datamodellering. Bert Dingemans Tien tips voor canonieke datamodellering Bert Dingemans Abstract Modelleren is een vakgebied gebaseerd op eenvoudige notaties. Echter op het moment dat en model opgesteld wordt blijkt de te modelleren

Nadere informatie

Roadmap. RIE Manager

Roadmap. RIE Manager Roadmap RIE Manager Look & Feel Rapportage/ Documentatie Uploaden Documenten Major Release 3 Lokaal beheer Major Release 2 Regie in eigen hand Submodules Major Release 1 Introductie In deze roadmap geeft

Nadere informatie

IN ZES STAPPEN MVO IMPLEMENTEREN IN UW KWALITEITSSYSTEEM

IN ZES STAPPEN MVO IMPLEMENTEREN IN UW KWALITEITSSYSTEEM IN ZES STAPPEN MVO IMPLEMENTEREN IN UW KWALITEITSSYSTEEM De tijd dat MVO was voorbehouden aan idealisten ligt achter ons. Inmiddels wordt erkend dat MVO geen hype is, maar van strategisch belang voor ieder

Nadere informatie

Project Fasering Documentatie Applicatie Ontwikkelaar

Project Fasering Documentatie Applicatie Ontwikkelaar Project Fasering Documentatie Applicatie Ontwikkelaar Auteurs: Erik Seldenthuis Aminah Balfaqih Datum: 31 Januari 2011 Kerntaak 1 Ontwerpen van applicaties De volgordelijke plaats van de documenten binnen

Nadere informatie

Procesmanagement. Hoe processen beschrijven. Algra Consult

Procesmanagement. Hoe processen beschrijven. Algra Consult Procesmanagement Hoe processen beschrijven Algra Consult Datum: juli 2009 Inhoudsopgave 1. INLEIDING... 3 2. ORGANISATIE VAN PROCESMANAGEMENT... 3 3. ASPECTEN BIJ HET INRICHTEN VAN PROCESMANAGEMENT...

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

nemen van een e-depot

nemen van een e-depot Stappenplan bij het in gebruik nemen van een e-depot CONCEPT VOOR FEEDBACK Bijlage bij Handreiking voor het in gebruik nemen van een e-depot door decentrale overheden 23 juli 2015 Inleiding Dit stappenplan

Nadere informatie

Central Station. CS website

Central Station. CS website Central Station CS website Versie 1.0 18-05-2007 Inhoud Inleiding...3 1 De website...4 2 Het content management systeem...5 2.1 Inloggen in het CMS... 5 2.2 Boomstructuur... 5 2.3 Maptypen... 6 2.4 Aanmaken

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

In de volgende paragraven worden de zes fases in de methodiek toegelicht:

In de volgende paragraven worden de zes fases in de methodiek toegelicht: Adoptiemethode Om een verandering in werkgedrag op een juiste manier bij mensen te bewerkstelligen kan gebruik gemaakt worden van onderstaande methodiek. De methodiek is opgebouwd uit zes fases met als

Nadere informatie

Manage Medewerkers Slim, Simpel & Succesvol

Manage Medewerkers Slim, Simpel & Succesvol Manage Medewerkers Slim, Simpel & Succesvol Manage Medewerkers Slim, Simpel & Succesvol zorgt ervoor dat je je managementtijd halveert en meer rust in je hoofd ervaart. Terwijl je de productiviteit en

Nadere informatie

Update documentatie. KraamZorgCompleet versie 4.0. KraamzorgCompleet versie 4.0

Update documentatie. KraamZorgCompleet versie 4.0. KraamzorgCompleet versie 4.0 Update documentatie KraamZorgCompleet versie 4.0 KraamzorgCompleet versie 4.0 Inhoudsopgave Update documentatie versie 4.0 Hoofdstuk 1 Declareren partusassistentie...1 1.1 Declareren partusassistentie

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

Starters Handleiding DuboCalc Project versie 4.0 21 juni 2015. DuboCalc Project 4.0 StartersHandleiding

Starters Handleiding DuboCalc Project versie 4.0 21 juni 2015. DuboCalc Project 4.0 StartersHandleiding Starters Handleiding DuboCalc Project versie 4.0 21 juni 2015 DuboCalc Project 4.0 StartersHandleiding Inhoud 1 Aan de slag met DuboCalc Project... 5 1.1 Wat is DuboCalc Project?... 5 1.2 Starten van

Nadere informatie

4orange Connect. 4orange, 2015. Hogehilweg 24 1101 CD Amsterdam Zuidoost www.4orange.nl

4orange Connect. 4orange, 2015. Hogehilweg 24 1101 CD Amsterdam Zuidoost www.4orange.nl 4orange Connect 4orange, 2015 Hogehilweg 24 1101 CD Amsterdam Zuidoost www.4orange.nl 2 Inhoud Inhoud... 2 1. Achtergrond... 3 2) Browsen... 4 3) Scheduler... 4 4) Frequenties en kruistabellen... 4 5)

Nadere informatie

Procestool; sleutel tot succes?

Procestool; sleutel tot succes? Procestool; sleutel tot succes? Gerard Hebenaar Gerard Hebenaar Adviesgilde 1 Even voorstellen.. Gerard Hebenaar Bedrijfskunde Adviesvaardigheden 15 jaar ervaring in de consultancy Verkoop en advies van

Nadere informatie

Beschrijving Evaluatiemodule Analysefunctie Coachview.net

Beschrijving Evaluatiemodule Analysefunctie Coachview.net Beschrijving Evaluatiemodule Analysefunctie Coachview.net Uitwerking gewenste analyse-mogelijkheden van de evaluatiemodule. Dé nieuwe manier van samenwerken 05 december 2012 Inleiding Binnen Coachview.net

Nadere informatie

Het belang van. Data Modellering. GEMINIT Training. Data Modellering. Frédéric BARBIER

Het belang van. Data Modellering. GEMINIT Training. Data Modellering. Frédéric BARBIER Het belang van Data Modellering Studiedag Informatiemanagement Politeia, 22 februari 2013, Gent Open data en de cloud: een revolutie in de informatiehuishouding van de overheid Training Data Modellering

Nadere informatie

Gebruikershandleiding

Gebruikershandleiding Gebruikershandleiding Inhoudsopgave 1 Inleiding 1 Snel aan de slag 3 Per Enquete 3 Een enquête + vragen toevoegen 6 Layout aanpassen 7 Een uitnodiging versturen 8 Resultaten bekijken 8 Tips en trucs 13

Nadere informatie

Wijzigingen 2012-2013

Wijzigingen 2012-2013 Wijzigingen 2012-2013 1. Nieuwe lay-out & snelheidsverbetering 2. Overzichten op maat 3. Verbeteringen gebruiksvriendelijkheid: DOD importeren Waarschuwingen bij didactisch blok IQ blok Alleen definitieve

Nadere informatie

Outlook 2010 tips & trucs

Outlook 2010 tips & trucs Outlook 2010 tips & trucs I N H O U D S O P G A V E 1 Algemeen... 1 1.1 Werkbalk snelle toegang... 1 1.2 Snelle stappen... 1 2 E-mail... 2 2.1 Regels... 2 2.2 CC mail onderscheiden... 2 2.3 Verwijderde

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

Handleiding Merge items

Handleiding Merge items Handleiding Merge items Copyright, Connexys Versie 3.2.0.1-30 september 2013 Niets uit dit document mag worden verveelvoudigd en/of openbaar worden gemaakt door middel van druk, fotokopie, microfilm of

Nadere informatie