Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

vanbegintoteind

634 views

Published on

  • Be the first to comment

  • Be the first to like this

vanbegintoteind

  1. 1. VAN BEGIN TOT EIND.managen van impliciete requirements
  2. 2. Van Begin tot Eind, managen van impliciete requirements D.A. Seelig © 2011 D.A. Seelig Ontwerp westerlaken.com Uitgeverij lulu.com ISBN: 978-1-105-55687-6 Drukker lulu.com Disclaimer Alle rechten voorbehouden. Niets uit deze uitgave mag worden verveel- voudigd, opgeslagen in een geautomatiseerd gegevensbestand, of openbaar gemaakt, in enige vorm of op enige wijze, hetzij elektronisch, mechanisch, door fotokopieën, opnamen of op enige andere manier, zonder voorafgaande schriftelijke toestemming van de auteur.
  3. 3. Inhoud Van begin tot eind............................................ 6 Een woord van dank ..................................................11 Van behoefte naar model............................... 12 De inventarisatie ........................................................19 Proza ..........................................................................21 Proza – casus ..................................................23 DSL van termen en definities – casus .............27 Proza – wetgeving ...........................................28 DSL van termen en definities – wetgeving ......31 Requirements .............................................................32 Requirements van de “requirements” ..............34 Requirements van de casus ............................35 Requirements wetgeving .................................38 Visualisatie .................................................................39 Requirements visualisatie informatiemodel .....42 Quick scan .................................................................44 Vertaling informatiemodel  ...............................49 Requirements vertaling informatiemodel .........52 Vertaling informatiemodel casus ......................52 Bedrijfsregels .............................................................53 Proactieve of reactieve beperkingen ...............54 Werkstroom ................................................................56 De cirkel .....................................................................59
  4. 4. Van model naar applicatie............................. 64 Vuxen 1 ......................................................................67 Vuxen 2 ......................................................................70 Vuxen 3 ......................................................................72 Vuxen 4 ......................................................................74 Vuxen 5 ......................................................................75 Tot slot............................................................. 78 DSL Van begin tot eind.................................. 82 Referentie materiaal ...................................................86 De kunst in dit boek....................................... 88 Oldrich Tichý  .............................................................90 Theo Niermeijer  ........................................................92
  5. 5. Van begin tot eind
  6. 6. 8 Een boodschap overbrengen lijkt makkelijk, maar blijkt soms in praktijk een stuk lastiger. Ik stel mij al snel de volgende vragen: “Is datgene wat ik denk goed verwoord?”, “Zijn die woorden ook zo overgekomen bij mijn gesprekspartner?” of “Heeft deze daar zijn eigen interpretatie bij?” of “Heb ik daar mijn eigen interpretatie bij?”. Communicatie behelst niet alleen de verbale communicatie of datgene wat op schrift gecommuniceerd wordt. Communicatie is ook de bewegwijzer- ing op straat, de vormgeving van een gebouw, de indeling van een spoor- boekje, het logo van een bedrijf of de frons op je wenkbrauw. Communicatie binnen de ICT behelst eenduidigheid in representaties van diagrammen, de gebruikte terminologie, de toegepaste constructieprinci- pes, de notatiestijl in programmacode, de mappenstructuur en -benaming, documentbenaming en -indeling et cetera. Communicatie is cultuur afhankelijk. De barrières die daardoor ontstaan zijn vrijwel onzichtbaar. Vanuit de achtergrond: 274.000 inwoners in Värm- land Zweden (oppervlakte  17.583 km²), winterse kou (-20), sneeuw en altijd moeten kunnen terugvallen op je buren, al wonen deze 10km ver- derop, beïnvloeden in grote mate de omgangsvormen, de manier van communiceren en de interpretatie van een boodschap. Ik ga er vanuit dat de onderlinge communicatie prettig verloopt er geen culturele barrières zijn. Dit boek gaat over communicatie, de communicatie momenten en het voorkomen van miscommunicatie in ICT-projecten. Bij één-op-één communicatie kan al miscommunicatie ontstaan, laat staan binnen projecten waarin de communicatie plaats vind tussen geledingen die ieder hun eigen perceptie hebben. Bijvoorbeeld de communicatie tussen: klant – projectmanagement;• klant – ontwerper;• projectmanagement – ontwerper;• ontwerper – ontwikkelaars;•
  7. 7. 9 projectmanagement – ontwikkelaars;• projectmanagement – beheerorganisatie.• Dit boek is geschreven voor het management van ICT-organisaties en een ieder die zich bezig houdt met het ontwikkelen van software. Het boek is geschreven vanuit het ICT-domein (iets wat later wordt toegelicht). We werken het thema communicatie uit via de aansprekende hedendaags aanvaarde methoden en met voorbeelden uit de dagelijkse praktijk. Daarnaast volgen we een casus met betrekking tot een galerie met kunstu- itleen van begin tot eind. Aan de hand van deze casus volgen we de com- municatiemomenten en laten we zien hoe miscommunicatie kan ontstaan. Tevens geven we handvatten om miscommunicatie te voorkomen. Bij de casus gaan we er vanuit dat software-ontwikkeling gestuurd moeten worden op het initiële idee en vanuit een bedrijfsmatig perspectief. Wij vin- den eenduidige perceptie noodzakelijk om adequaat in te kunnen spelen op de continu veranderende behoefte. Deze behoefte kan veranderen als gevolg van onder meer milieu, politiek, economisch, sociaal en technolo- gische omstandigheden. Het bedrijfsleven wil in staat zijn zich op relatief korte termijn aan te passen aan die veranderende omstandigheden,waarbij deze verandering de posi- tie van een bedrijf kan versterken of verzwakken. Bedrijven willen blijvend inspelen op de wijzigende markt door doelgroep en producten/diensten op elkaar af te stemmen en daarvoor de activiteiten uit te voeren zoals: marketing, fusering, centralisering, decentralisering, specialisering, gen- eralisering, et cetera. Technologische omstandigheden veranderen snel. Zowel hard- als soft- wareontwikkeling is permanent in beweging. Soms resulteert dit in oude wijn in nieuwe zakken. Soms in wijn die nog niet gerijpt is en soms in wijn die jong gedronken had moeten worden en nu al reeds azijn is. Dankzij so- cial community networks (zoals Hyves en LinkedIn) en webfora, verspre- iden nieuwe ontwikkelingen en inzichten zich snel. Voor je het weet, werk je met een technologie die hopeloos verouderd is en niet meer voldoet aan
  8. 8. 10 de eisen van de tijd. Het risico wat hier in ligt is dat IT projecten in plaats van business gedreven, technologisch gedreven worden. De twee focus gebieden; kunnen inspelen op de veranderende markt;• kunnen inspelen op de laatste trend in de techniek.• zijn met traditionele ontwikkel methodieken slecht verenigbaar. Het zou goed zijn bedrijfsprocessen en techniek van elkaar los te kop- pelen, zodat we zonder de ballast van de techniek kunnen inspelen op de veranderende behoefte van de markt en zonder de ballast van de veran- derende behoefte van de markt kunnen inspelen op de nieuwe inzichten van de techniek. Allereerst behandelen we de impact van de veranderende behoefte in het hoofdstuk “Van behoefte naar model”. In dit hoofdstuk beschrijven we de transitie van de veranderende behoefte naar een techniek onafhankelijk informatiemodel en we leggen tevens uit hoe u de impact van deze veran- deringen inzichtelijk kan maken. In het hoofdstuk “Van model naar applicatie” gaan we in op het techniek onafhankelijk ontwikkelen van software. De daarbij behorende rollen en de daarbij behorende do’s en don’ts.
  9. 9. 11 Een woord van dank Een boek schrijven, daar kwam ik al snel achter doe je niet alleen, de sponsoring, feedback van vrienden, collega’s, familie waren als een warm bad. Met dank aan Rik Visser (ICT Filosoof), Martin Bos (Project Man- ager), Hans Slagmolen (Project Manager), Henk van Dijken (Applicatie Ar- chitect) Mirk Oppenhuis de Jong (Marketeer), Jaap Seelig (Gymnasiast en Taalpurist), Richard Bollee (Sparring partner), Gerard van Mierlo (Galerie/ kunstuitleen Dijkstra) en Wim Dijkgraaf (Requirements Goeroe). December 2010, Dino Seelig
  10. 10. Van behoefte naar model
  11. 11. 14 In het vorige hoofdstuk constateerden we dat het goed zou zijn bedrijfspro- cessen en techniek van elkaar los te koppelen, zodat we zonder de ballast van de techniek kunnen inspelen op de veranderende behoefte van de markt en zonder de ballast van de veranderende behoefte van de markt kunnen inspelen op de nieuwe inzichten van de techniek. In dit hoofdstuk beschrijven we de transitie van behoefte naar een techniek onafhankelijk informatiemodel. We geven handvatten om de behoefte te inventariseren, te beschrijven, inzichtelijk te maken en te visualiseren. Door middel van terugkoppelmomenten kan “datgene wat niet gezegd is maar wel bedoeld is” onder woorden worden gebracht. Tot slot behande- len we de continu veranderende behoefte in de vorm van een continue verbeteringcycli, waarin naast inzicht in de impact van deze wijziging ook handvatten worden verstrekt om op kwaliteit te managen. Waarom is inzicht in de behoefte zo belangrijk? Er zijn nog veel automatiseerders die denken vanuit een oplossing, in plaats van uit continu veranderende behoeften. Een gevolg van te oploss- ingsgericht denken is dat er te kortzichtig naar het probleemdomein wordt gekeken. De consequentie is dat je inboet op de behoefte of de perceptie daarvan en dat daarmee de oplossing haar eigen leven gaat leiden. Een voorbeeld hiervan is het QWERTY-toetsenbord. Het idee achter het ontwerp was om te voorkomen dat de hamertjes van de typemachine klem raakten in elkaar. Deze behoefte is lang geleden verdwenen, en verworden tot de facto standaard (in de Angelsaksische landen) Handvatten om inzicht te behouden in de behoefte en de daarbij behorende oplossing is het terrein van requirements management. We leggen het waarom vast en plaatsen koppelingen tussen het waarom en het hoe. En beheersen daarmee de perceptie tot aan de realisatie. Binnen de behoeftebepaling spelen impliciete behoeften (datgene wat niet gezegd is, maar wel gewenst of bedoeld wordt) een rol. Deze kunnen voor onaangename verassingen zorgen.
  12. 12. 15 Als geboren en getogen Bourgondiër bestelde ik nog ‟niet zo lang geleden in een restaurant het verrassings- menu. Het voorgerecht was heerlijk. Het hoofdgerecht was precies datgene waar mijn smaakpapillen van geschof- feerd werden. De volgende keer wil ik me wel weer laten verrassen, maar geef ik tevens datgene aan wat ik niet wil. Met andere woorden: als je geen eisen stelt, dan krijg je datgene wat de ander biedt. Een organisatie waarbij projecten een belangrijke rol ‟speelden, wilde graag de communicatie tussen de dienst- verleners vereenvoudigen door het centraal beschikbaar stellen van documenten en foto’s. Daarbij kreeg ik de vraag “kunnen mijn klanten documenten en foto’s vlot uploaden met behulp van een webbrowser”. Mijn perceptie was “een Nikon D300 camera maakt plaatjes van hooguit 10MB. Een document van 10MB is extreem”. 10MB bij de huidige bandbreedte is geen probleem. We hadden al eer- der ervaring met soort gelijke functionaliteit. Kortom geen vuiltje aan de lucht. Offerte gemaakt, product gemaakt, getest en opgeleverd. De eindgebruiker deelde mede dat het uploaden van foto’s van 10Mb probleemloos verliep, maar dat het uploaden van afbeelding van 1GB niet lukte. Vlot is daarnaast ook een vaag begrip. Vlot kan daarmee ook gemakkelijk in conflict komen met het volume van de foto. Met alle gevolgen van dien: additionele eisen aan programmeeromgevingen en de oplossingstrategie. De volgende keer vraag ik door en doe ik geen aanname bij het in kaart brengen van de klant zijn behoefte. We onderscheiden de volgende communicatiemomenten in de vertaling van dit hoofdstuk, ‘behoefte naar model’: Het inventariseren van de veranderende behoefte (interview)1. en uitwisselen van de terminologie (begrippenlijst);
  13. 13. 16 De behoefte opschrijven in een tekst (proza);2. De behoefte samenvatten uit de tekst en verwerken tot re-3. quirements; De behoefte visualiseren (informatiemodel);4. De “quick scan” van het informatiemodel.5. Voor dat we hier verder op ingaan, mag het duidelijk zijn dat communicatie een beladen woord is. Communicatie is volgens Van Dale “contact, gemeenschap; verbinding, verkeer”. Voor de een betekent het “alles wat je doet om je zin te krijgen”, voor de ander “verwachtingen (be)sturen”. In de context van dit hoofdstuk bedoel- en we met communicatie “alles staat of valt met definities, zonder begrip- penkader zijn sommige woorden meervoudig interpreteerbaar”. Communicatie lijkt eenvoudig. We spreken en gaan er vanuit dat de an- dere kant oren heeft en hoort en begrijpt wat we zeggen. Cultureel gezien vinden we dit terug in gezegden als “kleine potjes hebben grote oren”, “dat is niet aan dovenmansoren gezegd” en “met een half oor luisteren”. Het tegendeel is echter waar. Horen en begrijpen wat er gezegd is, staan los van elkaar, dat merken we in de dagelijkse praktijk en zeker als je je in een vreemde taal goed wilt uitdrukken. In Zweden bestelde ik rode verf van het merk Falu en ‟kreeg een val voor een rat door de woorden “Falu röd” ver- keerd uit te spreken. Met handen en voeten heb ik alsnog het juiste product verkregen: “Falu röd färg”. Met andere woorden: binnen één op één communicatie kan je elkaar met handen en voeten en een beetje goede wil begrijpen.

  14. 14. 17 Een presentatie met het doel een boodschap voor een specifieke doel- groep over te brengen kan daarentegen al veel meer voorbereiding vergen. Het woordgebruik zal nauwkeurig afgestemd moeten worden op de doel- groep. Wanneer bij de toehoorders met betrekking tot het woordgebruik het referentiekader (domeinspecifieke taal) ontbreekt, zal de boodschap niet of nauwelijks overkomen. 
Schriftelijke communicatie daarentegen biedt de mogelijkheid woorden te gebruiken die buiten het referentiekader van de lezer vallen. Vanzelfsprekend dienen de binnen het domein ge- bruikte woorden (termen) wel omschreven (gedefinieerd) te worden. Deze woorden zijn domeinspecifiek en vallen bijvoorbeeld binnen het domein van de Nederlandse taal of meer specifiek in het domein van de advoca- tuur, de geneeskunde, et cetera. Eén woord kan een domeinafhankelijk betekenis hebben. Het woord “bank” is binnen het domein van een meubelmaker een “zitmeubel voor twee of meer personen”. Binnen het domein van de administrateur een “financiële instelling”. Binnen het domein van een computer hardware leverancier de plek waar je een computergeheugen in stopt. Een eenduidige uitleg zorgt ervoor dat de juiste betekenis aan een woord wordt toegekend of een pas- send synoniem wordt gebruikt. Het woord klant wordt gebruik om nadruk te leggen op hoe binnen de organisatie het contact met de buitenwereld beleeft moet worden. Binnen een organisatie waar dit gebruikelijk is kan gemakkelijk begripsverwarring ontstaan. Het woord “klant” zal binnen de afdeling verkoop een geheel andere betekenis hebben dan binnen de afdeling boekhouding of binnen de zorg (waar de klant synoniem is voor patiënt of cliënt). De verwarring komt dus voort uit de gebruikte verzamelterm. De oplossing is die termen te gebruiken die binnen het domein van verkoop, debiteurenadministratie en zorgverlener gebruikelijk zijn. Een begrippenlijst kan inzicht verstrekken in de samenhang van deze termen tussen de verschillende domeinen. Binnen één domein kunnen ook synoniemen voorkomen. Er dient een keuze gemaakt te worden welk woord binnen het domein voortaan ge- bruikt zal worden. Het volgende voorbeeld maakt het duidelijk: gebruiken we het woord “zitmeubel” of gebruiken we het woord “canapé” of zetten we beide woorden om naar de term “bank”. Deze keuze lijkt in eerste in-
  15. 15. 18 stantie niet relevant, maar voor het begrijpen van de business voor een buitenstaander is eenduidig woordgebruik van groot belang. De lezer zal in eerste instantie denken dat een “zitmeubel” iets anders is dan een “can- apé” en er pas later achter komen dat het synoniemen van elkaar zijn en zich afvragen waarom er geen eenduidig woordgebruik is toegepast. Organisaties die zich bezighouden met normalisatie zoals de Organiza- tion for Standardization (ISO) standaardiseren het woordgebruik van de verschillende domeinen. Denk hierbij aan het domein van landcodes (ISO 3166), taalcodes (ISO639-2/T), valutacodes (ISO 4217), et cetera. Als we in detail naar het landcodedomein kijken, zien we dat de volgende zaken worden omschreven: “driecijferige landcode”, “drieletterige land- code”, “tweeletterige landcode” en “land”. Naast dat het woord “driecijfer- ige landcode” betekenisvol is, hebben de gebruikte codes ook semantiek gekregen. Met andere woorden: de codes zijn betekenisvol binnen het domein landcodes. De “driecijferige landcode” 752, de “drieletterige land- code” SWE en de “tweeletterige landcode” SE staan synoniem voor de aanduiding “land” Zweden. Met andere woorden: naast standaardisatie in woordgebruik voor het omschrijven van de informatiebehoefte, zullen ook de aan het woordgebruik gekoppelde semantische codes omschreven moeten worden. Een goede start voor alle vormen van communicatie binnen een bedrijf is het vastleggen van termen, definities, semantische codes en hun betek- enis. Naast het vermijden van begripsverwarringen, zullen deze domein- specifieke termen eenduidig gaan leven binnen de gehele organisatie. Het wordt de taal van de gebruiker, de automatiseerder, de manager, et cetera, we spreken als het ware één taal. Deze taal is net zoals andere talen te leren. De teksten zullen voor personen die buiten het domein werkzaam zijn, te begrijpen zijn. Internationalisatie dwingt u ook verder te denken dan de Nederlandse taal alleen. “SE” betekent in Duitsland “Sweden”, in Sweden “Sverige” de code is gelijk, de vertaling is echter anders. Vanzelfsprekend zal het woordgebruik in een stuk proza de begrippenlijst aanvullen, of de begrippenlijst zal het woordgebruik beperken. Van belang is, dat het woord en semantische code gebruik eenduidig is.
  16. 16. 19 De inventarisatie Het beschrijven van de behoefte wordt voor een belangrijk deel verkregen door middel van interviews met belanghebbenden en beschrijft datgene wat de klant wil en niet wil. Wie zijn de belanghebbenden? Wie heeft de waarheid in pacht? Wie bepaalt binnen een organisatie welke waarheid de waarheid is? Op al deze vragen zal je eerst een antwoord moeten hebben voordat je kan beginnen met interviewen. Pas in het interview de “wie, wat, waar, waarom, waarmee, wanneer, en welke wijze1 ” vragen toe. Deze vor- men de basis van ieder goed interview. Daarnaast kan je met de techniek luisteren, samenvatten en doorvragen de geïnterviewde een terugkoppel- ing te geven vanuit de perceptie van de interviewer. Samenvatten geeft met andere woorden de geïnterviewde inzicht of de verstrekte gegevens dezelfde informatie herbergt zoals de zender dit aan de ontvanger heeft bedoelt. Het resultaat van het interview dient te resulteren in een SMART- 1.) Gevers, Zijlstra, Praktisch Project Management
  17. 17. 20 model. De aspecten van het interview dienen met andere woorden Speci- fiek, Meetbaar, Acceptabel, Realistisch en Tijdgebonden te zijn. SMART kunnen we makkelijk uitleggen aan de hand van het volgende voorbeelden: Specifiek: Specifiek is to the point en laat niets in het ongewisse.• “Ga over precies 200 meter rechtsaf” mag duidelijk zijn is “specifiek”. Meetbaar: Een foto van 2Kb moet binnen 2 seconden verwerkt• kunnen worden is een meetbare eis. Realistisch: één vrouw baart normaliter een kind in negen• maanden, twee vrouwen doen dat niet in vierenhalve maand. Zo’n eis stellen gebeurt echter regelmatig. De wetgever houdt over het algemeen geen rekening met de problematiek rond de implementatie van een wet. Acceptabel: betekent 100 procent draagvlak binnen de eigen• gelederen. Het mag duidelijk zijn dat verborgen agenda’s uitgesloten zijn en niet uitgespeeld moeten worden in het verwoorden van het interview. Tijdsgebonden: Beschrijf je prioriteiten in de tijd gezien.• “Must have”, “Should have”, “Could have”, “Would like to have” (MoSCoW). Verwachtingmanagement noodzakelijk voor het prioriteren van het project.
  18. 18. 21 Proza Terugkoppeling van het interview in de vorm van het proza (een stuk tekst dat is geschreven in de vorm van gewone spraak) aan de belanghebbende is essentieel. Na goedkeuring van het proza door alle belanghebbenden kan men beginnen met het uitschrijven van de requirements. Het eendui- dig verwoorden van het interview is mogelijk door de gebruikte woorden op te nemen in een domein specifieke lijst van termen en definities. Ontdek je een woord dat al gebruikt is en die een geheel andere definitie heeft, dan kan je het woordgebruik heroverwegen of in de context van een ander domein plaatsen. De Proza dien je zodanig te schrijven dat de boodschap in 30 minuten te begrijpen is. Bij de wat grotere projecten zal proza begin- nen met een globale omschrijving met een onderverdeling in functionele deelgebieden. De benaming van deze functionele deelgebieden dient de lading te dekken. De later te realiseren architectuur documenten dienen deze onderverdeling en de benaming van deze functionele deelgebieden te volgen. In kleine projecten kan je volstaan met een sectie, sub-sectie indeling binnen één document. Bij grote projecten zal je deze sectie, sub- sectie indeling regelen met behulp van het benamen van folders, docu- menten en door middel van aanbrengen van secties en sub-secties binnen documenten. Eenduidige communicatie betekent dat voor ieder project de structuur identiek is.
  19. 19. 22 Regelmatig worden wij uitgenodigd voor een audit op een applicatie. We constateren vaak dat de programmatuur min of meer redelijk georgani- seerd is, tevens constateren we dat de samenhang tussen de verschillende documenten ver te zoeken is. Valideren of de documentatie compleet is, de programmatuur aansluit op de documentatie blijkt dan een zoekplaatje. In praktijk zal om die reden een wijziging in de programmatuur zonder lezen/bijwerken van documentatie worden verricht. Met alle bijbehorende consequenties. In het begin zal de documentatie nog van waarde zijn, en min of meer het reilen en zijlen van de business onder woorden brengen. Wij hebben ook grote ondernemingen gezien waarin de praktijk van de dag alleen terug te vinden is in de programmacode. De behoefte “dezelfde taal spreken” kunnen we managen met behulp van een aantal eenvoudige requirements. Requirements “Proza” Probleemdomein (behoefte) De zelfde taal spreken Oplossingsdomein Domein Specifieke Lijst van termen en definities (DSL) Beschrijf de woorden en hun betekenis Beschrijf de semantische codes en hun betekenis Voorkom synoniemen Gebruik in het proza alleen de woorden uit het DSL-woordenboek Gebruik in de requirements alleen de woorden uit het DSL-woordenboek Gebruik voor de benaming van folders en documenten alleen de woorden uit het DSL- woordenboek Gestandaardiseerde benaming van folders en documenten Gestandaardiseerde folder structuur Gestandaardiseerde document structuur © Van begin tot eind
  20. 20. 23 Proza – casus De galerie/kunstuitleenorganisatie beschrijft in haar bedrijfsdoelstelling, dat zij de drempel zowel naar particulieren als naar het bedrijfsleven wil verlagen door betaalbare kunstwerken aan te bieden. De galerie/kunstu- itleenorganisatie koopt alleen kunstwerken aan van gerenommeerde kun- stenaars (die vaak ook met vergelijkbare kunstwerken in museumcollec- ties vertegenwoordigd zijn), zowel in Europa als in de Verenigde Staten. De gekozen oplossingsstrategie bestaat uit de combinatie van een groot aanbod kunstwerken met een gunstige prijs/kwaliteit verhouding. Drem- pelverlagend naar de afnemer toe door deze kunstwerken aan te bieden met een flexibele huur/spaarregeling en recht op koop.; Groot aanbod; De galerie/kunstuitleenorganisatie heeft op dit• moment een aanbod van ongeveer 3500 kunstwerken. Gunstige prijs/kwaliteit; Criterium voor opname in de collectie, is• de artistieke waarde van een kunstwerk en een gunstige prijs/ kwaliteit verhouding. Flexibele huur/spaarregeling met recht op koop; Naast de• mogelijkheid een kunstwerk te kopen, is het als lid ook mogelijk om een kunstwerk te huren, of te huren met een opbouw van een kooptegoed. Het lid spaart dan terwijl hij huurt. Het lid kan op ieder moment een aanpassing doen en bepalen welk beschikbaar huursysteem het beste past bij de gehuurde kunstwerken. De kunstuitleenorganisatie onderkent 3 verschillende huursystemen. Een 1% regeling waarbij per maand 1% van de verkoopprijs als huur in rekening wordt gebracht. Een 2% regeling waarbij per maand 2% van de verkoopprijs als huur in rekening wordt gebracht. Bij deze regeling wordt 50% van het huurbedrag opgebouwd als kooptegoed. Een 3% regeling waarbij per maand 3% van de verkoopprijs als huur in rekening wordt gebracht. Bij deze regeling wordt 100% van de huurbedrag opgebouwd als kooptegoed
  21. 21. 24 Behoefte “geautomatiseerd administreren” Wegens succes is bij deze galerie/kunstuitleenorganisatie door groeiende vraag en de wens de klant nog beter van dienst te kunnen zijn, behoefte ontstaan om een aantal bedrijfsprocessen (de inkoop, verkoop, verhuur en transport van kunstwerken) geautomatiseerd te administreren. Inkoop kunstwerken 
De galerie/kunstuitleen organisatie koopt werken direct van de kunste- naar. Een inkoper selecteert die kunstwerken die in zijn optiek van mu- seale waarde zijn en die hij/zij zelf mooi vindt. Op het moment dat de aangekochte kunstwerken binnen komen bij de galerie/kunstuitleen or- ganisatie worden deze kunstwerken voorzien van een inventarisnummer. Tevens wordt de verkoopprijs vastgesteld en wordt het kunstwerk verzek- erd. Ten behoeve van de verzekering van het kunstwerk, wordt voor ieder kunstwerk de inventarisnummer, de titel, het formaat, omschrijving, foto de kostprijs (aankoopbedrag plus de kosten voor een lijst, sokkel, etc.) vastgelegd. Indien een kunstwerk schadegevoelig is, denk hierbij aan glassculpturen, dan kan voor zo’n kunstwerk aangegeven worden dat deze alleen aangekocht kan worden en niet voor verhuur in aanmerking komt. Ieder kunstwerk wordt door middel van een sticker voorzien van een inventarisnummer. Eén keer per jaar worden van de kunstwerken die aanwezig zijn bij de galerie/kunstuitleen organisatie de verkoopprijzen aangepast. De verk- oopprijzen van kunstwerken, die gehuurd worden, worden na inname aangepast. Verkoop kunstwerken 
Diegene (rechtspersoon, klant) die een kunstwerk wil kopen kan in overleg met de galerie/kunstuitleenorganisatie het kunstwerk direct kopen of re- serveren. Werken die tentoongesteld zijn op een expositie kunnen alleen gereserveerd worden, de definitieve koop vindt plaats na afloop van deze expositie.
  22. 22. 25 Diegene die een kunstwerk gekocht heeft, krijgt voor ieder kunstwerk een factuur waarin is aangegeven welk met welk bedrag het kunstwerk gekocht is. De verrekening van de betaling kan met behulp van het inmiddels opge- bouwde kooptegoed, door een pin betaling, of een combinatie van beide. Op het moment van aankoop vervalt de verzekering van het kunstwerk. Huur kunstwerken
 Diegene die een kunstwerk wil huren dient eerst lid te worden van de galerie/kunstuitleen organisatie. De rechtspersoon tekent naast een lid- maatschap contract ook een automatische incasso verklaring. De laatste is voor de verrekening van het lidmaatschap en de verrekening van de eventueel gehuurde kunstwerken. De galerie/kunstuitleen schrijft de rechtspersoon in. En overhandigt deze een verklaring van lidmaatschap en de leveringsvoorwaarde. Na bestendigen lidmaatschap kan de rechtspersoon een kunstwerk huren. Deze krijgt per kunstwerk een huurovereenkomst waarin is aangegeven welk kunstwerk hij huurt, de ingangsdatum, het afgesproken huursysteem en de maandelijks te betalen vergoeding. Het contract is in duplo. De con- tracten worden door zowel de galerie/kunstuitleen als door de afnemer ondertekend. Na ondertekenen huurovereenkomst zal op iedere 15de van de maand de huur middels een automatische incasso-opdracht in rekening worden gebracht. Dit impliceert dat een huurder een kunstwerk kan huren van de 16de van een maand tot de 15de van de volgende maand zonder een vergoeding voor de huur te hoeven te betalen. Het opgebouwde kooptegoed kan niet worden opgenomen, maar kan alleen gebruikt worden voor de aanschaf van een beschikbaar kunstwerk van de galerie/kunstuitleenorganisatie.
  23. 23. 26 Beëindigen huurovereenkomst 
 Diegene die een gehuurd kunstwerk terugbrengt, krijgt per kunstwerk een bevestiging van ontvangst waarbij tevens de huurovereenkomst van het kunstwerk wordt beëindigd. Aankoop beëindigd de huurovereenkomst. Het kunstwerk kan aangekocht worden tegen de verkoopprijs die bekend was bij aangaan van de huurovereenkomst. Transport
 Bedrijven kunnen van een extra service gebruik maken, waarbij zij vooraf een groot aantal kunstwerken kunnen zien op hun eigen locatie. De opge- geven kunstwerken worden op transport gezet naar de eigen locatie. Vervolgens kunnen zij uit deze kunstwerken op eigen locatie een selectie maken en worden ze geholpen bij het plaatsen van de kunstwerken Status overzicht 
In de galerie/kunstuitleen kan een rechtspersoon inzage krijgen in de opbouw van zijn kooptegoed, gehuurde kunstwerken en aangekochte kunstwerken. Kunstprofiel
 De galerie/kunstuitleenorganisatie stelt voor ieder lid een kunstpro- fiel samen. Het kunstprofiel is af te leiden uit de gehuurde/gekochte kunstwerken en de periode dat de kunstwerken bij het lid op locatie war- en. Financiële administratie 
De financiële administratie is in de vorm van een standaard pakket reeds geautomatiseerd. De koppeling met dit pakket valt buiten de scope van deze casus.
  24. 24. 27 DSL van termen en definities – casus Term Definitie 1% regeling Zie huursysteem 2% regeling Zie huursysteem 3% regeling Zie huursysteem Automatische Incasso Betaalwijze waarbij een rekeninghouder aan een organisatie (de gemachtigde) toestemming geeft voor eenmalige of periodieke afschrijving van bedragen van een bank- of girorekening Extra Service Bedrijven kunnen van een extra service gebruik maken waarbij zij vooraf een groot aantal kunstwerken kunnen reserveren Collectie Internationale kunst van gerenommeerde kunstenaars Galerie Verkooporganisatie Gehuurde kunstwerken Kunstwerken die verhuurd zijn Gereserveerde kunstwerken Kunstwerken die verkocht gaan worden Gerenommeerd kunstenaar Curriculum Vitae opleiding, exposities Huur Maandelijkse bijdrage voor het in huis hebben van één of meerdere kunstwerken Huursysteem 1%, 2% en 3% regeling, waarbij maandelijks het afgesproken percentage van de waarde van een kunstwerk als huur in rekening wordt gebracht. Bij een 1% regeling wordt geen kooptegoed opgebouwd. Bij een 2% regeling wordt 50% van de huur gereserveerd als kooptegoed. En bij een 3% regeling wordt 100% van de huur gereserveerd als kooptegoed. Inventarisnummer Kunstwerk identificatienummer. Rechtspersoon Voorkeur synoniem “Klant”. Een rechtspersoon die kunstwerken koopt of huurt van de galerie/kunstuitleenor- ganisatie Klant Synoniem voor rechtspersoon Kooptegoed Tegoed dat alleen gebruikt kan worden voor de aanschaf van een beschikbaar kunstwerk van de galerie/kunstuitleen- organisatie Kunstuitleenorganisatie Verhuurorganisatie Kunstwerk Werk van een gerenommeerde kunstenaar
  25. 25. 28 Term Definitie Kunstprofiel Profiel van de door de klant gehuurde en gekochte kunstwerken Lid Klant die lid is van de kunstuitleenorganisatie Particulier Privé persoon Prospect Potentiële klant Transport Kunstwerken op route van en naar de klant Statusoverzicht Overzicht per klant van welke werken er gehuurd of gekocht zijn en het totaal opgebouwde kooptegoed in euro's. Impliciete behoefte – casus De term garantie is niet gevallen. Is garantie een requirement, of een van uit de wetgever afgedwongen impliciete requirement? Terugkoppeling van de proza, vragen stellen, is de manier om daar achter te komen. De term factuur is gevallen, vanuit de wetgeving een requirement. Voor ons een impliciete requirement. Vanuit de wetgeving is de onderstaande proza ge- schreven: Proza – wetgeving Bewaarplicht
 U bent als ondernemer verplicht de boeken en andere gegevensdragers die op de onderneming betrekking hebben, gedurende een periode van 7 jaar te bewaren. De bewaarplicht geldt voor bijvoorbeeld in- en uitgaande facturen. De bewaarplicht geldt zowel voor papieren versies als elektronis- che versies. BTW plicht
 Als u hoofdzakelijk aan ondernemers goederen en diensten levert, bent u de BTW verschuldigd op het moment dat u de factuur hebt uitgereikt: u vult de BTW in op de aangifte van het tijdvak waarin de datum van de factuur valt. Dit heet het factuurstelsel. Als u de factuur te laat uitreikt, bent u de BTW toch verschuldigd op het moment dat u de factuur had moeten
  26. 26. 29 uitreiken. Als uw klant de factuur meteen betaalt, is er geen verschil tussen het kasstelsel en het factuurstelsel. Als u het factuurstelsel toepast, kan het gebeuren dat een klant de factuur niet of niet helemaal betaalt terwijl u de BTW al wel hebt aangegeven en betaald. In dat geval kunt u deze BTW aan ons terugvragen. U kunt daar- voor per brief een verzoek om teruggaaf sturen naar uw belastingkantoor. U moet dan wel kunnen aantonen dat de factuur inderdaad niet of maar gedeeltelijk is betaald. Het is daarom raadzaam om bewijsstukken met uw verzoek mee te sturen. Als uw klanten vooral particulieren zijn, bent u de BTW verschuldigd op het moment waarop u de vergoeding ontvangt voor uw product of dienst. U vult dan het verschuldigde BTW in op het aangiftebiljet van het tijdvak waarin u de vergoeding hebt ontvangen. Dit heet het kasstelsel. Het kass- telsel mag onder andere worden toegepast door winkeliers, marktkooplie- den, schoenmakers, kappers, rijwielherstellers en horecabedrijven. Factuur opmaken
 De facturen die u uitreikt, moeten voldoen aan de wettelijke eisen. Als dit niet het geval is, is het mogelijk dat uw afnemer geen recht heeft op aftrek van de BTW. Op alle facturen die u uitreikt, moet u in elk geval de onder- staande, door de wet bepaalde basisgegevens duidelijk vermelden: een opeenvolgend nummer;• de datum van uitreiking van de factuur;• naam en adres van de ondernemer die de levering of de dienst• verricht; het BTW-identificatienummer van de ondernemer die de levering• of de dienst heeft verricht; naam en adres van de afnemer aan wie de levering wordt verricht• of de dienst wordt verleend; een duidelijke omschrijving van de geleverde goederen of de• verleende dienst; de hoeveelheid (of omvang) en aard van de geleverde goederen• of de verleende dienst;
  27. 27. 30 het toegepaste algemene BTW-tarief;• het BTW-bedrag uitgedrukt in euro’s;• de vergoeding. (De vergoeding is het totale bedrag exclusief• BTW, dat u in rekening brengt voor de levering van goederen en het verrichten van diensten. Er moet sprake zijn van een rechtstreeks verband tussen de verrichte prestatie en de ontvangen tegenprestatie (de vergoeding).
  28. 28. 31 DSL van termen en definities – wetgeving Term Definitie Hoeveelheid De hoeveelheid of omvang van de verrichte dienst De vergoeding De vergoeding is het totale bedrag exclusief BTW dat u in rekening brengt voor de levering van goederen en het verrichten van diensten. Er moet sprake zijn van een rechtstreeks verband tussen de verrichte prestatie en de ontvangen tegenprestatie (de vergoeding). Omschrijving Een duidelijke omschrijving van de geleverde goederen of de verleende dienst DSL van termen en definities – automatische incasso Term Definitie IBAN-nummer Het IBAN-nummer( International Bank Account Number) is een extra lange versie van je gewone bankrekening en is speciaal in het leven geroepen voor betalingen in het buitenland. Aan je rekeningnummer wordt een aantal letters en cijfers toegevoegd: de afkorting voor je bank(RABO=Rabobank, PSTB=Postbank, FTSB=Fortis) de letters NL(Nederland) en een controle getal bestaande uit 2 cijfers. Dit voorkomt een overschrijving naar een verkeerde rekening.
  29. 29. 32 Requirements Proza geeft een goed beeld over wat de klant wil. Door het proza punt voor punt uit te werken in een behoeftelijst, ontstaat helder en meetbaar inzicht. 
Na het in kaart brengen van de behoefte, kunnen we oplossingen gaan koppelen aan de behoeften. Het koppelen van oplossingen aan de behoeften geeft naast inzicht in de waarom vraag ook inzicht in de impact van een verandering. Oplossingen die blijven hangen als de behoefte reeds verdwenen is, kunt u vergelijken met het vervetting van de bloedvaten. In het begin zullen we er weinig last van hebben, maar na een wat langere periode slibt het au- tomatiseringssysteem geleidelijk dicht. Uiteindelijk zitten we met een au- tomatiseringsinfarct. Met een bypass kunnen we vervolgens het systeem in leven houden. Na verloop van tijd zal het systeem opnieuw ontwikkeld moeten worden en zal het systeem vervolgens, als u niets organiseert, hetzelfde traject ingaan. Met een beetje zorg, voorkomt u vervuiling van uw systeem, voorkomt u dat oplossingen een eigen leven gaan leiden.
  30. 30. 33 Iedereen kan goede requirements schrijven aan de hand van de volgende simpele regels. Beschrijf de behoefte in plaats van de oplossing;• Gebruik alleen de woorden die opgenomen zijn in de domein• specifieke lijst van termen en definities. Gebruik alleen de semantische codes die opgenomen zijn in de domein specifieke lijst van termen en definities. Gebruik een beperkte woordenschat. Gebruik een uniforme zinsbouw (bijvoorbeeld: het vastleggen van klanten kan). Schrijf een bondig zin. Het volgen van deze regels maakt dat requirements vertaalbaar zijn. Men kan met eenvoudige hulpmiddelen de requirements vertalen van Nederlands naar Engels of (naar behoefte) van Nederlands naar Swahili; Schrijf slechts één requirement per keer en voorzie deze van• een unieke aanduiding (bijvoorbeeld een nummer). Door in een later stadium de oplossing (oplossingsdomein) te koppelen aan het probleemdomein en het werkdomein te koppelen aan het oplossingsdomein, ontstaat inzicht over de impact van de veranderende behoefte. Bijvoorbeeld: Behoefte aan verkoeling (probleemdomein) wordt gekoppeld aan de specificaties van een zwembad (oplossingsdomein) welke gekoppeld worden aan de realisatie van het zwembad (werkdomein). Veranderende behoefte kan bijvoorbeeld betekenen dat een oplossing voor een probleem niet meer van toepassing is; Gebruik vaagheden bij het beschrijven van de requirements en• kwantificeer deze vaagheden. Door vaagheden te gebruiken en deze te kwantificeren verlies je geen kostbare informatie. Het volgende zinnetje schetst het voorbeeld: “Het uploaden van een grote foto is mogelijk. Met groot bedoel ik 10Mb”. De lezer krijgt direct inzicht in wat de perceptie van de schrijver is. Naast de perceptie van de schrijver is de requirement meetbaar geworden. Requirements en de domein specifieke lijst van termen en definities zijn één. Indien een term een andere betekenis krijgt, dan kan dat impact heb- ben op de gekozen oplossing.
  31. 31. 34 Requirements van de “requirements” Het probleem “inzicht in de behoefte, inzicht in de gekozen oplossing, im- pact van veranderende behoefte en inzicht of de oplossing voldoet aan onze eisen”, kunnen we verkrijgen met behulp van een aantal eenvoudige requirements. Requirements van de “Requirements” Probleemdomein (behoefte) Inzicht in de behoefte Oplossingsdomein Gebruik een unieke aanduiding Schrijf een volwaardige zin Schrijf een bondige zin Beschrijf de behoefte in plaats van de oplossing Beschrijf niet meer dan één behoefte Gebruik een uniforme zinsbouw Gebruik een beperkte woordenschat Gebruik alleen begrippen uit het DSL-woordenboek Probleemdomein (behoefte) Inzicht in of er een oplossing is voor onze behoefte Oplossingsdomein Koppel de requirements aan de oplossing Probleemdomein (behoefte) Inzicht in de impact van onze veranderde behoefte Oplossingsdomein Koppel de oplossing aan het werkdomein Probleemdomein (behoefte) Inzicht of de oplossing voldoet aan onze eisen Oplossingsdomein Identificeer de vaagheden Kwantificeer de vaagheden © Van begin tot eind
  32. 32. 35 Requirements van de casus De behoefte kan uit het proza worden afgeleid. Alle termen die gebruikt zijn in de requirements, zijn verklaard in de lijst van termen en definities. Voorbeeld: Diegene die een kunstwerk wil huren dient eerst ‟lid te worden van de galerie/kunstuitleen organisatie. De rechtspersoon tekent naast een lidmaatschap contract ook een automatische incasso verklaring. De laatste is voor de verrekening van het lidmaatschap en de verreke- ning van de eventueel gehuurde kunstwerken. De vet gedrukt zin is direct te vertalen naar een requirement. Als een klant een kunstwerk wil huren, dient hij lid te zijn. Requirements “galerie/ kunstuitleenorganisatie” nr Probleemdomein (behoefte) Wegens succes is bij deze galerie/kunstuitleenorganisatie door groeiende vraag en de wens de klant nog beter van dienst te kunnen zijn, behoefte ontstaan om een aantal bedrijfsprocessen geautomatiseerd te administreren. 0 Oplossingsdomein Klant Het administreren van klant gegevens kan 1 Het vastleggen van de klant naam kan 2 Het vastleggen van een bezoek adres kan 3 Het vastleggen van een bezoek huisnummer kan 4 Het vastleggen van een bezoek postcode kan 5 Het vastleggen van een bezoek woonplaats kan 6 Het vastleggen van een bezoek land kan 7 Het vastleggen van contact gegevens kan 8
  33. 33. 36 Contact gegevens = telefoonnummer werk 9 Contact gegevens = telefoonnummer mobiel 10 Contact gegevens = telefoonnummer privé 11 Een klant kan lid zijn 12 Een klant kan een prospect zijn 13 Een klant kan een bedrijf zijn 14 Een klant kan een particulier zijn 15 Het vastleggen van een IBAN nummer kan 16 Kunstenaar Het administreren van kunstenaars kan 17 Het vastleggen van het geboorteland kan 18 Het vastleggen van de naam kan 19 Het vastleggen van het CV kan 20 Kunstwerk Het administreren van veel kunstwerken kan 21 veel is “3500” 22 Het vastleggen van een kunstwerk identificatie kan 64 Het administreren van “niet voor verhuur” kan 23 Het vastleggen van de titel van het kunstwerk kan 24 Het vastleggen van een korte omschrijving van het kunstwerk kan 25 Het vastleggen van het formaat (hxb) kan 26 Het vastleggen van een foto van het kunstwerk kan 27 Het administreren van het “soort kunstwerk” kan 28 soort kunstwerk = glas 65 soort kunstwerk = olieverf 66 soort kunstwerk = ets 67 soort kunstwerk = zeefdruk 68 Het administreren van de kostprijs kan 29 Het administreren van de verkoopprijs kan 69 Huursysteem Het administreren van een huursysteem kan 30 huursysteem “1% regeling”, “reservering percentage is 0%” 31 huursysteem “2% regeling”, “reservering percentage is 50%” 32 huursysteem “3% regeling”,”reservering percentage is 100%” 33 Het lid kan het beschikbaar huursysteem altijd aanpassen 34 Klant huurt kunstwerk Het administreren van verhuurde kunstwerken kan 35
  34. 34. 37 Als een klant een kunstwerk wil huren, dient hij lid te zijn 36 Als een klant een kunstwerk wil huren, dient zijn IBAN nummer correct te zijn 75 Het vastleggen van de aanvangsdatum kan 71 Het vastleggen van de einddatum kan 72 Het vastleggen van het huurbedrag kan (afleiding van het gekozen huursys- teem) 73 Het vastleggen van het spaarbedrag kan (afleiding van het gekozen huursys- teem) 74 Klant koopt kunstwerk Het administreren van verkochte kunstwerken kan 37 Het vastleggen van de aankoopdatum kan 38 Het vastleggen van het aankoopbedrag kan 39 Klant transporteert kunstwerk Het administreren van te transporteren kunstwerken kan 40 Het vastleggen van de transportdatum kan 41 Alleen bedrijven kunnen kunstwerken op locatie selecteren 42 Klant reserveert kunstwerk Het reserveren van bepaalde kunstwerken kan 43 Het vastleggen van de aanvraagdatum kan 70 Kooptegoed Het administreren van het kooptegoed kan 44 Het administreren kan automatisch iedere 15de van de maand 45 © Van begin tot eind
  35. 35. 38 Requirements wetgeving Requirements van de “Requirements” Probleemdomein (behoefte) Controle vanuit wetgever Oplossingsdomein Bewaarplicht Het bewaren van documenten voldoet aan de wettelijke verplichting 46 bewaarplicht is “7 jaar” 47 Factuur Het opnemen van verplicht basis gegevens is mogelijk 48 Verplicht basis gegeven is "een opvolgend factuurnummer" 49 Verplicht basis gegeven is "de datum van uitreiking" 50 Verplicht basis gegeven is "uw naam" 51 Verplicht basis gegeven is "uw adres" 52 Verplicht basis gegeven is "uw BTW-identificatienummer" 53 Verplicht basis gegeven is "de naam van uw afnemer" (klant) 54 Verplicht basis gegeven is "het adres van uw afnemer" (klant) 55 Verplicht basis gegeven is "de vergoeding" 56 Verplicht basis gegeven is "het toegepaste algemene BTW-tarief" 57 algemene BTW-tarief is "19%" 58 Verplicht basis gegeven is "het BTW-bedrag in euro's" 59 Verplicht basis gegeven is "een duidelijke omschrijving van de geleverde goederen of de verleende dienst" 60 omschrijving is "huur periode" 61 omschrijving is "aankoop kunstwerken" 62 Verplicht basis gegeven is "de hoeveelheid (of omvang) en aard van de geleverde goederen of de verleende dienst" 63 © Van begin tot eind
  36. 36. 39 Visualisatie
  37. 37. 40 Proza is geschreven, de requirements zijn uit het proza gedestilleerd. We maakten bij het schrijven van proza en de requirements gebruik van de domein specifieke lijst van termen en definities. Visualisatie geeft versnelt inzicht. Het spreekwoord “een plaatje zegt meer dan duizend woorden” verwoord dat uitstekend. Visualiseren van de infor- matie behoefte, de bedrijfsregels en de werkstromen ligt dan ook voor de hand. Bij het visualiseren zullen we afspraken moeten maken welk sym- bool welke betekenis heeft. Een in de ICT wereld breed geaccepteerde visualisatie hulpmiddel is “de Unified Modeling Language” (UML). Een modelleer omgeving waarin de informatiebehoefte wordt gevisualiseerd in een vorm van een klassediagram. De werkstromen worden gevisuali- seerd in de vorm van een activiteitendiagram. Deze modelleer omgeving is echter nog niet in staat de bedrijfsregels te visualiseren in de vorm van een schema’s of diagrammen. Complexe bedrijfsregels kunnen gevisuali- seerd worden met behulp van klassiekers zoals de Nassi-Shneidermann diagrammen, of de programma stroom schema’s (PSS). We beginnen met de visualisatie van een informatiemodel: een fase in het applicatie-ontwikkelingstraject gericht op het vormen van de klasse en hun attributen en de samenhang tussen de verschillende klasse. Tijdens deze fase bepalen we welke gegevens vastgelegd moeten worden om uiteindelijk de informatiebehoefte te dekken. We kunnen volstaan met het definiëren van een klassediagram met daarin de klasse, de attributen en de associaties tussen de klassen. Ook in het UML-model gebruiken we alleen die termen die zijn opgenomen in de lijst van termen en definities. We koppelen tevens de klassen, attributen en associaties aan de oploss- ing beschreven in de requirements. Normaliter zul je in het UML-model met behulp van “tagged values” het requirementnummer associëren met de klasse, attributen en associaties. In dit klassediagram zijn om didac- tische redenen de requirementnummers als prefix opgenomen in de naam van de klasse en attributen. Inzicht in de impact van een wijziging is direct aanwezig. Daarnaast is gemakkelijk te valideren of het model de require- ments dekt.
  38. 38. 41 We volgen daarbij een paar simpele regels. Er zijn vier soorten klassen: “mensen”, “dingen”, “gebeurtenissen” en “locaties”. Alles wat je in een in- formatiemodel zou willen zetten, past in deze categorieën. Als het er niet in past is het geen klasse maar een eigenschap van een klasse. Het kiezen van een huursysteem, het maken van een factuur en het op- bouwen van een kooptegoed, de verkoop, huur, transport of reservering van een kunstwerk zijn gebeurtenissen. Klant en kunstenaar zijn mensen. Kunstwerken zijn dingen. Dit zijn dus allemaal klassen die in het informati- emodel komen. Klant Het administreren van klant gegevens kan 1 Het vastleggen van de klant naam kan 2 Het vastleggen van een bezoek adres kan 3 Het vastleggen van een bezoek huisnummer kan 4 Het vastleggen van een bezoek postcode kan 5 Het vastleggen van een bezoek woonplaats kan 6 Het vastleggen van een bezoek land kan 7 Het vastleggen van contact gegevens kan 8 Contact gegevens = telefoonnummer werk 9 Contact gegevens = telefoonnummer mobiel 10 Contact gegevens = telefoonnummer privé 11 Een klant kan lid zijn 12 Een klant kan een prospect zijn 13 Een klant kan een bedrijf zijn 14 Een klant kan een particulier zijn 15 Het vastleggen van een IBAN nummer kan 16 Kunstenaar Het administreren van kunstenaars kan 17 De klant klasse is voorzien van prefix 1 (een verwijzing naar requirement nummer 1). De “isLid” attribuut is voorzien van prefix 12. De “isBedrijf” (en geen particulier) attribuut is voorzien van prefix 14 en prefix 15 et cetera.
  39. 39. 42 Requirements visualisatie informatiemodel Inzicht in de relatie tussen behoefte en informatiemodel is mogelijk met behulp van een aantal simpele requirements, zo ook controle of de infor- matiebehoefte de requirements dekt. Requirements “visualisatie informatiemodel” Probleemdomein (behoefte) Inzicht in de relatie tussen informatiebehoefte en de requirements Oplossingsdomein Verwijs vanuit de informatiebehoefte naar de unieke requirement aanduiding Gebruik alleen woorden uit het DSL-woordenboek © Van begin tot eind
  40. 40. factuur-klant klant-huurtKunstwerk klant-reserveertKunstwerk klant-transporteertKunstwerk klant-kooptKunstwerk kunstwerk-gehuurd kunstwerk-gereserveerd kunstwerk-gekocht kunstwerk-getransporteerd kooptegoed-kunstwerk 1-klant Atrributes 2-54 naam : String 55 factuurAdres : String 55 factuurPostcode : String 55 factuurWoonplaats : String 55 factuurLand : Enum 3-4 bezoekAdres : String 3-5 bezoekPostcode : String 3-6 bezoekPlaats : String 3-7 bezoekLand : Enum 8-9 telefoonnummerWerk : String 8-10 telefoonnummerMoiel : String 8-11 telefoonnummerPrive : String 16 IBANnummer : String 13 statusKlant : Enum 12 isLid : Boolean 14-15 isBedrijf : Boolean Operations 48-factuur Attributes 50 datumVanUitreiking : DateTime 49 factuurNummer : int 60 omschrijving : String 56 vergoeding : Currency 59 btwBedrag : Currency 57 toegepastBtwTarief : int 54 naamAfnemer : String 55 adresAfnemer : String 55 postCodeAfnemer : String 55 plaatsAfnemer : String 55 landAfnemer : String Operations 30-huurSysteem Attributes 31/33 regeling : String 31/33 percentageVerkoopPrijs : int 31/33 percentageSpaartegoed : int Operations 21-kunstwerk Atrributes 64 kunstwerkId : String 24 titel : String 28-65/68 soortKunstwerk : Enum 26 formaatHoog : Int 26 formaatBreed : Int 25 korteBeschrijving : Int 29 kostPrijs : Currency 69 verkoopPrijs : Currency 37-30-43-50 statusKunstwerk : Enum 23 nietVoorVerhuur : Enum 27 foto : String Operations 35-huurtKunstwerk Attributes 71 huurdatumAanvang : DateTime 72 huurdatumEind : DateTime 34-73 huurBedrag : Currency 34-74 reserveringSpaartegoed : Currency Operations 43-reserveertKunstwerk Attributes 70 datumAanvraag : DateTime Operations 40-transporteertKunstwerk Attributes 41 datumOpTransport : DateTime Operations 37-kooptKunstwerk Attributes 38 aankoopDatum : DateTime 39 bedrag : Currency Operations 44-kooptegoed Attributes 45 bedrag : Currency Operations 20-curriculumVitae Attributes 20 tekst : String Operations 17-kunstenaar Attributes 19 naam : String 18 land : Enum Operations
  41. 41. 44 Quick scan We hebben het informatiemodel, maar geeft het informatiemodel ook de gewenste informatie? De praktijk kan weerbarstiger zijn dan de theorie. In theorie dien je met interview en de vertaling van deze “in proza” en “requirements” en de vi- sualisatie van deze in een “informatie model” volledig in kaart te hebben gekregen. In praktijk houden diegene, die een beslissing nemen, zich niet bezig met het hoe. De visualisatie van de behoefte in de vorm van een in- formatiemodel sluit dan ook niet aan met de wereld van de opdrachtgever, maar wel met de wereld van de ontwikkelaar. Rapportages in de vorm van de gewenste overzichten sluiten daarentegen wel aan met de beleving-
  42. 42. 45 swereld van de opdrachtgever. Feedback in de vorm van deze, kunnen tekortkomingen in het voorgaande traject vroegtijdig tackelen. In het verleden werd met behulp van de in de organisatie toegepaste for- mulieren en rapporten een bubble chart werd gemaakt. Deze bubble chart werd vervolgens gebruikt om met behulp van de normalisatie stappen van Codd, ERD modellen te maken. De oude werkwijze passen we als het ware nu omgekeerd toe. En geven daarmee een terugkoppelmoment waarmee de opdrachtgever kan valideren of zijn informatiebehoefte gedekt is. Een ERD model kan gedestilleerd worden uit een UML Klasse Diagram. Met behulp van views op de ERD entiteiten kan vervolgens bekeken worden of de informatiebehoefte gedekt is. In theorie zal de informatiebe- hoefte gedekt zijn. In praktijk kan men kosten besparen door in dit niveau alle gewenste rapportage te realiseren. Naast voordeel op testvlak, inzicht of de data daadwerkelijk de gewenste informatie geeft, kan vroegtijdige detectie van onvolkomenheden verrassingen voorkomen aan het einde van een project. Vanzelfsprekend zal het repareren van een onvolkomen- heid op dit niveau aanzienlijk minder kosten dan die zelfde reparatie aan het einde van een project. De in de requirement definities beschreven volumes kunnen vervolgens opgevoerd worden. Voordat er wordt gestart met de bouwwerkzaam- heden, weten we dat de informatiebehoefte gedekt is en detecteren we of de informatie binnen de gestelde tijd beschikbaar is. Speciale aandacht zal uit moeten gaan naar de eisen die gesteld zijn. In de galerie/kunstuitleen casus het “Het administreren van veel kunstwerken kan [21]”, “veel=3500 [22]” dient nu gevalideerd te worden. Voor het vertalen van een UML Klasse Diagram naar een ERD dienen de volgende regels gevolgd te worden: klasse:• Creëer voor iedere klasse een entiteit met de naam van de• klasse;
  43. 43. 46 Voeg voor iedere entiteit één primaire sleutel attribuut van het• datatype GUID toe. De naam van de primaire sleutel attribuut kan worden samengesteld uit de naam van de entiteit met de toevoeging “Id”. Een “land” entiteit wordt dus voorzien van een primair sleutel attribuut “landId”. 1-N Associatie:• Voeg voor iedere 1-N associatie één verwijzende sleutel at-• tribuut toe op de N associatie. De naam van de verwijzende sleutel attribuut kan worden samengesteld uit de naam van de 1-entiteit met de toevoeging “IdFk”. In de situatie “klant” kan 1 of meer “facturen” hebben zal de “factuur” entiteit worden aan- gevuld met de verwijzende sleutel “klantIdFk”. N-M Associatie:• Voeg voor iedere N-M associatie één koppel entiteit toe met de• naam van beide geassocieerde klassen; Voeg voor iedere N associatie één verwijzende sleutel attribuut• toe in de koppelentiteit. De naam van de verwijzende sleutel at- tribuut kan worden samengesteld uit de naam van de N-entiteit met de toevoeging “IdFk”;. Voeg voor iedere M associatie één verwijzende sleutel attribuut• toe in de koppel entiteit. De naam van de verwijzende sleutel attribuut kan worden samengesteld uit de naam van de M-en- titeit met de toevoeging “IdFk”. Generalisatie Specialisatie:• Generalisatie en specialisatie worden gewoon behandeld als• andere klassen. Datatype:• Vertaal ieder datatype naar het database datatype.• Meta info:• Voeg voor iedere sleutel attribuut als metadata het type sleutel• attribuut toe (primair, verwijzend). Voor de vertaling van de klasse attributen naar ERD attributen gebruiken wij de volgende regels:
  44. 44. 47 De “• Datum” klasse attributen worden vertaald naar ERD attributen van het type “Datim”; De “• String” klasse attributen worden vertaald naar ERD attributen van het type “Varchar(200)”; De “• Boolean” klasse attributen worden vertaald naar ERD attributen van het type “Boolean”; De “• Currency” klasse attributen worden vertaald naar ERD attributen van het type “Double”; De “• Enum” klasse attributen worden vertaald naar ERD attributen van het type “String”, en een enumeratie tabel of Constante; De “• verplichte” attributen worden vertaald naar ERD attributen met een “Required” vlag. Voor het vertalen van de associaties gebruiken we de volgende regels: Alleen composiet associaties krijgen een “• Cascading Delete Contraint”. Bij een verwijder activiteit van de 1 associatie zullen ook alle kinderen van deze associatie verwijderd worden. Alle overige associaties krijgen een “• Restricted Delete Contraint”. Het verwijderen van de 1 associatie mag alleen als deze associatie geen kinderen meer heeft. De “Nullify Delete Contraint” wordt in praktijk vrijwel niet gebruikt. Bij het verwijderen van de 1 associatie worden alle verwijzingen opgenomen in de N associatie op Null gezet. De Data Definitie Language (SQL) kan vervolgens worden aangemaakt uit de gegevens beschikbaar in de ERD en worden geëxecuteerd. In onderstaand voorbeeld zijn de door vertaling toegevoegde attributen inzichtelijk gemaakt.
  45. 45. kooptegoed Attributes kooptegoedId : GUID factuurIdFk : GUID kunstwerkIdFK : GUID Operations huurtKunstwerk Attributes huurtKunstwerkId : GUID klantIdFk : GUID kunstwerkIdFk : GUID huurSysteemIdFk : GUID Operations klant Attributes klantId : GUID Operations kunstenaar Attributes kunstenaarId : GUID Operations factuur Attributes factuurId : GUID klantIdFk : GUID Operations curriculumVitae Attributes kunstenaarId : GUID Operations kunstwerk Attributes kunstwerkId : GUID kunstenaarIdFk : GUID Operations huurSysteem Attributes huurSysteemId : GUID Operations transporteertKunstwerk Attributes transporteertKunstwerkId : GUID klantIdFk : GUID kunstwerkIdFk : GUID Operations reserveertKunstwerk Attributes reserveertKunstwerkId : GUID klantIdFk : GUID KunstwerkIdFk : GUID Operations kooptKunstwerk Attributes kooptKunstwerkId : GUID klantIdFk : GUID kunstwerkIdFk : GUID Operations
  46. 46. 49 De curriculum vitae gegevens zijn vanwege performance redenen niet opgenomen in de kunstenaar entiteit, maar als een 1 op 1 associatie geko- ppeld aan de kunstenaar entiteit. De curriculum vitae entiteit krijgt in zo’n situatie een primaire sleutel met de naam van de primaire sleutel van de “kunstenaar” entiteit. Een quick scan “of de oplossing aansluit met de belevingswereld van de klant” kunnen we verkrijgen met behulp van een aantal eenvoudige re- quirements. Requirements “Quick scan” Probleemdomein (behoefte) De oplossing sluit aan met de belevingswereld van de klant Oplossingsdomein Views Rapportage Probleemdomein (behoefte) De informatie dient binnen de gestelde tijd beschikbaar te zijn Oplossingsdomein Opvoeren testdata Queries © Van begin tot eind Vertaling informatiemodel Woordgebruik bij het ontwikkelen van automatiseringssystemen kent haar beperkingen, omdat deze woorden ook gereserveerd kunnen zijn als commando in de ontwikkelomgeving. Menig Relationele DataBase Management Systeem (RDBMS) heeft het woord “min” als gereserveerd woord. Stel dat de term “min” is opgenomen met als definitie “afkorting voor ministerie” dan zouden we, als we geen rekening houden met de gereserveerde woorden van een ontwikkelomgeving, kunnen vast lopen bij het executeren van de applicatie. Naast gereserveerde woorden kent een ontwikkelomgeving ook beperkingen in de maximale woordlengte met
  47. 47. 50 als gevolg dat we de woorden in de domein specifieke lijst van termen en definities dienen af te korten als we deze ook in de programmatuur willen toepassen. Ook de software ontwikkelaars hebben behoefte aan eenduidig woordge- bruik. Tijdens het ontwikkel proces is de behoefte lager. De ontwikkelaar zal niet snel in verwarring raken, omdat de materie nog vers in zijn geheugen zit. In een onderhoud of zelfs bij overdracht van onderhoudswerkzaam- heden zal echter niet-eenduidig woordgebruik gelijk staan aan een lange leercurve. Zonder direct op de techniek te willen ingaan “c = a+b” is zonder context lastig te doorgronden. “bedragInclusiefBtw = bedrag + btwBedrag” daar in tegen is zelf verklarend. Verwarring kan als snel ontstaan als on- voldoende aandacht is besteed aan de benaming van elementen “bdrgIn- clBtw = prijs + btwSom” (brdg, prijs en som zijn synoniemen van bedrag). Het is met andere woorden verstandig de lijst van termen en definities als basis te gebruiken voor het maken van de afkortingenlijst. Wanneer we naast deze lijst een lijst bijhouden van gereserveerde woorden, voorkomen we tegelijkertijd conflicten met gereserveerde woorden uit onze ontwikkel- omgeving (operating systeem, RDBMS, XML, et cetera). Ter voorkoming van miscommunicatie dienen afkortingen consistent te worden doorge- voerd. Combinatiewoorden zoals “landnummer” en “nummerinformatie” worden als we het woord “nummer” afkorten tot “nr” getransformeerd tot de woorden “landnr” en “nrinformatie”. Automatiseringssystemen bieden steeds vaker hun interface aan de buit- enwereld aan in de vorm van XML berichten verkeer. De termen en defini- ties en de gebruikte afkortingen dienen zoveel mogelijk aan te sluiten op bestaande standaarden. Voor financiële instellingen bestaat bijvoorbeeld de uitwissel standaard EbXML. Business rapportages maken gebruik van rapportage taal XBRL et cetera. Gereserveerde woorden Een conflict met een gereserveerd woord ligt zeker voor de hand als we de voertaal Engels toepassen. De onderstaande woorden “schrik niet het zijn er meer dan ik dacht” zijn over het algemeen gereserveerd door een RDBMS:
  48. 48. 51 access, add, all, alter, analyse, analyze, and, any, array, as, asc, asensitive, asymmetric, audit, authorization, avg, backup, before, begin, between, bigint, binary, blob, both, break, browse, bulk, by, call, cascade, case, cast, change, char, character, check, checkpoint, close, cluster, clustered, coalesce, collate, column, comment, commit, committed, compress, compute, condition, confirm, connect, connection, constraint, contains, containstable, continu, controlrow, convert, count, create, cross, current, current_date, current_role, current_time, current_timestamp, current_user, cursor, database, databases, date, day_hour, day_micro- second, day_minute, day_second, dbcc, deallocate, dec, decimal, declare, default, deferrable, delayed, delete, deny, desc, describe, deterministic, disk, distinct, distinctrow, distributed, div, do, double, drop, dual, dummy, dump, each, else, elseif, enclosed, end, errlvl, errorexit, escape, escaped, except, exclusive, exec, execute, exists, exit, explain, external, false, fetch, file, fillfactor, float, floppy, for, force, foreign, freetext, freetexttable, freeze, from, full, fulltext, function, goto, grant, group, having, high_priority, holdlock, hour_microsecond, hour_minute, hour_second, identified, identity, identity_insert, identitycol, if, ignore, ilike, immediate, in, increment, index, infile, initial, initially, inner, inout, insensitive, insert, int, integer, intersect, interval, into, is, isnull, isolation, iterate, join, key, keys, kill, leading, leave, left, level, like, limit, lineno, lines, load, localtime, localtimestamp, lock, long, longblob, longtext, loop, low_priority, match, max, maxextents, mediumblob, mediumint, mediumtext, middleint, min, minus, minute_second, mirrorexit, mlslabel, mod, mode, modifies, modify, national, natural, new, no_write_to_binlog, noaudit, nocheck, nocompress, nonclustered, not, notnull, nowait, null, nullif, number, numeric, of, off, offline, offset, offsets, old, on, once, online, only, open, opendatasource, openquery, openrowset, openxml, optimize, option, optionally, or, order, out, outer, outfile, over, overlaps, pctfree, percent, perm, permanent, pipe, pivot, placing, plan, precision, prepare, primary, print, prior, privileges, proc, procedure, processexit, public, purge, raid0, raiserror, raw, read, reads, readtext, real, reconfigure, references, regexp, release, rename, repeat, repeatable, replace, replication, require, resource, restore, restrict, return, revoke, right, rlike, rollback, row, rowcount, rowguidcol, rowid, rownum, rows, rule, save, schema, schemas, second_microsecond, select, sensitive, separator, serializable, session, session_user, set, setuser, share, show, shutdown, similar, size, smallint, some, soname, spatial, specific, sql, ssl, start, starting, statistics, straight_join, successful, sum, symmetric, synonym, sysdate, table, tape, temp, temporary, terminated, textsize, then, tinyblob, tinyint, tinytext, to, top, trailing, tran, transaction, trigger, true, truncate, tsequal, uid, uncommitted, undo, union, unique, unlock, unsigned, update, updatetext, upgrade, usage, use, user, using, utc_date, utc_time, utc_timestamp, validate, values, varbinary, varchar, varchar2, varcharac- ter, varying, verbose, view, waitfor, when, whenever, where, while, with, work, write, writetext, xor, year_month, zerofill
  49. 49. 52 Requirements vertaling informatiemodel De behoefte “voorkomen van conflicten met onderliggende systemen” kun- nen we managen met behulp van een aantal eenvoudige requirements. Requirements “Vertaling informatiemodel” Probleemdomein (behoefte) Voorkomen van conflicten met onderliggende systemen (operating systeem, RDBMS, XML, et cetera) Oplossingsdomein Gereserveerde woordenlijst Naamgevingsconventies Eenduidige afkortingen © Van begin tot eind Vertaling informatiemodel casus In deze casus is de benaming in het Nederlands gelaten. We verwachten om die reden geen conflicten met gereserveerde woorden. In deze casus hebben we geen beperking in de woord lengte om die reden hebben we in de domein specifieke lijst van termen en definities geen afkortingen kolom opgenomen.
  50. 50. 53 Bedrijfsregels Naast het informatiemodel zijn ook de bedrijfsregels uit de requirements te destilleren. Een belangrijke drijfveer voor de adoptie van bedrijfsregels is de verplichting tot het garanderen van de zogenaamde regulatory compli- ance: bedrijven moeten aan de hand van interne controle-instrumenten kunnen garanderen dat hun bedrijfsprocessen en boekhoudkundige reg- istratie conform wetten en kwaliteitsnormen, zoals Sarbanes Oxley, Basel II, ISO 9000, zijn.
  51. 51. 54 Bedrijfsregel Requirement Verplicht basis gegeven is “een opvolgend factuurnummer” 49 Als een klant een kunstwerk wil huren, dient hij lid te zijn 36 Alleen bedrijven kunnen werken op locatie selecteren 42 Als een klant een kunstwerk wil huren, dient zijn IBAN nummer correct te zijn 75 Verplicht basis gegeven is “de datum van uitreiking” 50 Verplicht basis gegeven is “uw naam” 51 Verplicht basis gegeven is “uw adres” 52 Verplicht basis gegeven is “uw BTW-identificatienummer” 53 Verplicht basis gegeven is “de naam van uw afnemer” 54 Verplicht basis gegeven is “het adres van uw afnemer” 55 Verplicht basis gegeven is “de vergoeding” 56 Verplicht basis gegeven is “het toegepaste algemene BTW-tarief” 57 Et cetera Proactieve of reactieve beperkingen De implementatie van de bedrijfsregels is afhankelijk van het gebruik van proactieve of reactieve beperking. Een reactieve beperking zal, wanneer een klant geen lid is en toch een kunstwerk wil huren, de melding geven “klant dient lid te zijn [36]”. Een proactieve beperking (bedrijfsregel) zal alleen de aankoop mogelijkheid tonen. De gebruiker zal dan direct zien dat de klant geen lid is en de klant eerst lid maken [12]. Een proactieve beperking zal het factuurnummer bij de daadwerkelijke transactie ophogen [49]. Een proactieve beperking zal de datum van uitreiking initieel voorzien van de systeemdatum [50]. et cetera. Daarnaast zullen bedrijfsregels op verschillende plaatsen in de program- matuur opgenomen worden. De bedrijfsregel “veld is verplicht” zal zowel op de presentatie laag (browser), als op de business logica laag (server) als op database niveau geïmplementeerd moeten worden. De reden hier- voor is dat data op verschillende manieren aangeboden kan worden. Via een user interface (browser), via een business to business bericht en met behulp van een SQL workbench. Met name bij webapplicaties is er onvol- doende aandacht bij deze implementatie van deze bedrijfsregels. Over het algemeen vindt deze alleen plaats op de presentatie laag (browser) met
  52. 52. 55 als gevolg dat kwaad willenden het systeem kunnen verstoren. Vertalen van bedrijfsregels naar de verschillende lagen toe behoeft dan ook extra aandacht. Een beslissingsmatrix, waarin aangegeven wordt welke type bedrijfsregel in welke lagen opgenomen moeten worden, is dan ook geen overbodige luxe. Ook hier dus communicatie. Communicatie onder welke omstandigheden bedrijfsregels op meerdere plaatsen geïmplementeerd moeten worden. Requirements “Bedrijfsregels” Probleemdomein (behoefte) Inzicht in de relatie tussen behoefte en oplossing Oplossingsdomein Gebruik naast de unieke aanduiding in de requirements ook een “attribuut” die de require- ment identificeert als een bedrijfsregel Maak een overzicht van de requirements die zijn geïdentificeerd als een bedrijfsregel Maak een beslissingsmatrix waar aangegeven staat welk type bedrijfsregel in welke lagen opgenomen moeten worden © Van begin tot eind
  53. 53. 56 Werkstroom Het proza is geschreven, de requirements zijn uit het proza gedestilleerd. We maakten bij het schrijven van het proza en de requirements gebruik van domein specifieke taal van termen en definities. Het klassediagram staat, de in de “quick scan” vertaling van dit model naar een ERD, en de creatie van views op deze gaf nog extra feedback. De kans is groot dat het informatiemodel de lading dekt en daarnaast voldoende kan performen. Bedrijfsregels zijn geïsoleerd. We dienen nog één onderdeel in kaart te brengen en we zijn klaar met de voorbereiding aan de functionele kant.
  54. 54. 57 Ook de activiteiten in de vorm van een werkstroom of een UML activiteiten diagram is goed uit de proza te vertalen, zeker als we bij het schrijven van die proza daar aandacht aan hebben besteed. We isoleren in de uitvoering van de casus de activiteiten die plaatsvinden wanneer iemand besluit lid te worden. Diegene die een kunstwerk wil huren dient eerst lid ‟te worden van de galerie/kunstuitleen organisatie. De rechtspersoon tekent naast een lidmaatschap contract ook een automatische incasso verklaring. De laatste is voor de verrekening van het lidmaatschap en de verrekening van de eventueel gehuurde kunstwerken. De galerie/kunstuit- leen schrijft de rechtspersoon in. En overhandigt deze een verklaring van lidmaatschap en de leveringsvoorwaarde. persoon kunstuitleen Accordeer automatische incasso formulier Check IBAN nummer klant Accordeer contract lidmaatschap 2 Accordeer contract lidmaatschap 1 voorzie klant- gegevens van IBAN nummer zet klant lidmaatschap op true eind Het isoleren van werkstromen uit de requirements maakt het bedrijfsproc- es inzichtelijk. Daarnaast worden de verschillende rollen in een organisatie en de verantwoordelijkheden binnen een rol duidelijk. Deze diagrammen sluiten goed aan op de belevingswereld van een eindgebruiker. En kunnen uitstekend gebruikt worden als communicatie middel.
  55. 55. 58 Requirements “Werkstromen” Probleemdomein (behoefte) Inzicht in het bedrijfsproces Oplossingsdomein Visualiseren werkstroom in een diagram Diagram = UML Activitity Diagram Diagram = XML Process Definition Language (XPDL) Gebruik alleen woorden uit het DSL-woordenboek Probleemdomein (behoefte) Inzicht in de rollen en verantwoordelijkheden Oplossingsdomein Activiteiten Swimlanes Rol beschrijving © Van begin tot eind
  56. 56. 59 De cirkel Het proces dat bestaat uit “het definiëren van een lijst van termen en defini- ties, het schrijven van proza, het schrijven van requirements, het vertalen van de proza en requirements naar een informatie model, de bedrijfsregels en de werkstroom” is cyclisch. Cyclisch wil zeggen dat het laatste uitgang- spunt wordt bevroren en gebruikt voor de start van het vervolgtraject.
  57. 57. 60 De documentatie is met zo’n aanpak altijd up to date. Te allen tijde bes- chrijft de documentatie de werkwijze die op dat moment wordt uitgevoerd binnen de organisatie. We zeggen wat we doen, we doen wat we zeggen. Dit onderdelen in dit cyclische proces kunnen geoptimaliseerd worden door het proces te standaardiseren, te monitoren en te analyseren. Het cyclische proces is beschreven door Barry Boehm in “The Spiral Soft- ware Process Model” en door Dr. Deming in de “Plan, Do, Check, Act cyclus (PDCA cyclus)”. Met behulp van deze techniek wordt tijd, kosten en kwaliteit beheersbaar. Als bedrijf kennen we een verscheidenheid aan behoeften. Denk maar aan omzet, winstmarges, sociaal gezicht, et cetera. Om deze doelstellingen te kunnen halen zal er behoefte zijn aan: inzicht in het reilen en zijlen van het bedrijf;• kunnen (bij)sturen van het bedrijf;• inspelen op wensen en eisen van de markt;• nakomen van wettelijke verplichtingen;• nakomen van kwaliteitsnormen;• et cetera.• Bij veel bedrijven zal er een oplossing geboden worden voor deze be- hoeften met behulp van maatwerk ICT-processen. Veel automatisering- sprojecten starten met het schrijven van documenten. Na veel inspanning is er inzicht in de behoefte van een organisatie. Vervolgens zal na een creatief proces een oplossing zijn beschreven die de behoefte dekt in de vorm van architectuurdocumenten, waarna het bouwproces begint, al dan niet voorafgegaan door een technisch ontwerp. Tijdens het bouwproces is de kans groot dat een ontwikkelaar afwijkt van de initiële oplossing. Dat kan vanwege voortschrijdend inzicht vanuit belanghebbenden, maar ook door voortschrijdend inzicht van een ontwikkelaar. Men dient op zo’n mo- ment terug te stappen naar het begin. Requirements dienen te worden bijgesteld en architectuurdocumenten moeten worden aangepast.
  58. 58. 61 Eigenlijk zou op ieder document moeten staan: “niet bijwerken van de documentatie kan schade berokkenen aan de bedrijfsvoering”. Het niet bijwerken van de documentatie betekent dat: inzicht over de business langzaam verloren gaat. De werkelijkheid gaat steeds verder afwijken van datgene wat beschreven is. Uiteindelijk zal de werkelijkheid alleen nog in de werking van de programmatuur terug te vin- den zijn. Daarnaast is het gevaar aanwezig dat bij een normaal person- eelsverloop de nog aanwezige bedrijfsspecifieke kennis verloren gaat; het wordt steeds lastiger om nog te voldoen aan de verplichting tot het garanderen van de zogenaamde regulatory compliance. Bedrijven moeten aan de hand van interne controle instrumenten kunnen garanderen dat hun bedrijfsprocessen en boekhoudkundige registratie conform zijn aan wetten en kwaliteitsnormen zoals beschreven in Sarbanes Oxley, Basel II, ISO 9000. Instappen in de cirkel kost energie. Met name als een softwareontwikkel traject reeds jaren loopt en er onvoldoende aandacht is besteed aan het vastleggen van de behoefte. Het voordeel van een helder geschreven ver- haal over de werkwijze van een bedrijf is dat derden zich sneller kunnen inwerken in de materie.
  59. 59. Requirements “De circel” Probleemdomein (behoefte) Besturen van een organisatie Oplossingsdomein We zeggen wat we doen We doen wat we zeggen Probleemdomein (behoefte) Naast sturen op tijd en geld, sturen op kwaliteit Oplossingsdomein Dr. Deming: Plan, Do, Check, Act cyclus Barry Boehm: Spiral Software Process Model © Van begin tot eind
  60. 60. 64 Van model naar applicatie
  61. 61. 65
  62. 62. 66 Het cyclische model in hoofdstuk 2, “van behoefte naar model”, is ook aanwezig bij het vertalen van het model naar een applicatie. De manier waarop deze vertaling wordt uitgevoerd, bepaalt in grote mate de volwas- senheid van een organisatie. De organisatie niveaus die worden gebruikt in dit hoofdstuk verwijzen met een knipoog naar het Zweedse woord voor volwassen de Vuxen levels. De daarbij behorende karakteristieken zijn herkenbaar voor veel automatiseerders. Ik geef geen waardeoordeel, maar schets wel de karakteristieken die overduidelijk bij een bepaald niveau ho- ren. Mensen, middelen en uw visie bepalen in grote mate welk niveau het beste bij uw organisatie past. In dit hoofdstuk beschrijven we de verschillende organisatien-1. iveaus en de daarbij behorende karakteristieken. Initial is chaotisch en ad hoc. Een niveau waar alle organisat-2. ies ooit mee gestart zijn. Repeatable is het niveau waarbij de organisatie zover is3. geprofessionaliseerd (bijvoorbeeld door het invoeren van pro- jectmanagement), dat bij het ontwikkelproces gebruik wordt gemaakt van de kennis die eerder is opgedaan. Defined is het niveau waarbij de belangrijkste processen zijn4. gestandaardiseerd. Managed is het niveau waarbij de kwaliteit van het ontwik-5. kelproces wordt gemeten, zodat het kan worden bijgestuurd. Optimizing is het niveau waarbij het ontwikkelproces als een6. geoliede machine loopt en er alleen maar sprake is van fine- tuning (de puntjes op de i).
  63. 63. 67 Vuxen 1 Initial is chaotisch en ad hoc. Basisniveau voor iedere organisatie. In een Vuxen 1-organisatie zal iedereen zijn eigen werkwijze volgen. De kwaliteiten van het individu is bepalend en daarbij sterk afhankelijk van hun eigen referentiekader. Normaliter werkt een groep ontwikkelaars gezamenlijk aan een applicatie, er ontstaat al snel een ratjetoe aan al dan niet correct uitgevoerde coderingsstijlen en oplossingsstrategieën. De veel toegepaste knip-en-plakmethode waarin een routine wordt gedupliceerd en vervolgens aangepast, kent haar eigen voor en nadelen. De voordelen “snel klaar”, “ieder programma staat op zich” kennen ook nadelen. Bi- jvoorbeeld een fout die in het begin geproduceerd is, zal in alle kopieën aanwezig zijn. Voortschrijdend inzicht zal in praktijk alleen in die kopie ver- werkt worden, waar de individuele ontwikkelaar op dat moment mee bezig is. De historie van inzichten is als het ware terug te vinden in de applicatie. Karakteristiek voor dit soort applicaties is dat de kwaliteit, de robuustheid onvoorspelbaar is. Met behulp van uitgebreide testen kunnen de risico’s bij het live gaan van de applicatie beperkt worden. Steekproefsgewijs
  64. 64. 68 testen zal echter onvoldoende zekerheid bieden. Productiviteit wordt niet gemeten, er is geen inzicht in de kosten van de realisatie en in het onder- houd van de programmatuur. Als er beperkt personeelsverloop is levert de bovenbeschreven werkwijze geen direct gevaar op voor de organisatie. Het wegvallen van één persoon binnen de organisatie heeft impact, omdat degene die de taken overneemt van die persoon diens al dan niet correct uitgevoerde oplossing moet begrijpen. Anders gezegd Vuxen 1 organisaties schenken onvoldoende aandacht aan de communicatie binnen alle disciplines. De impact kan groot zijn: In praktijk zagen we: Het meten of het systeem voldoet aan de behoeft is niet mogelijk.• reden: requirements niet conform richtlijnen geschreven. Geen inzicht in de compleetheid van de documentatie. Reden:• geen afspraken gemaakt over de folder structuur en de benaming van de folders en documenten. De samenhang tussen documenten is onduidelijk. Reden: geen• afspraken gemaakt over de folder structuur en de benaming van de folders en documenten. De functionele beschrijving niet kan worden gevonden. Reden:• daar er geen afspraak zijn gemaakt in welk document en in welke sectie van het document deze beschrijving opgenomen had moeten worden. De lezer heeft moeite met het begrijpen van het document. Reden:• Woordgebruik in de functionele beschrijving is niet eenduidig. De aangeboden hoeveelheid informatie is onvoldoende gestructureerd. De programmeur heeft moeite met het begrijpen van de code.• Reden: onvoldoende relatie tussen programmacode en de functionele oplossing. Onvoldoende toepassen van naamgeving conventies, codering standaarden en toe te passen constructie technieken. Het gedrag van de applicatie is onvoorspelbaar. Reden:• onvoldoende aandacht op het vlak error afhandeling.
  65. 65. 69 De bediening van de applicatie kent een hoge leercurve. Reden:• onvoldoende aandacht voor het onderdeel gebruikersinterface ontwerp. Geen inzicht in de stichtingskosten en kosten voor het• onderhoud. Reden: onvoldoende aandacht op weging, en uren administratie. Etc.•
  66. 66. 70 Vuxen 2 Repeatable is het niveau waarbij de organisatie zover is geprofessiona- liseerd (bijvoorbeeld door het invoeren van projectmanagement) dat bij het ontwikkelproces gebruik wordt gemaakt van de kennis die eerder is opgedaan. In een Vuxen 2-organisatie zal iedere softwareontwikkelaar, infor- matiearchitect, applicatiearchitect, et cetera een gestandaardiseerde werkwijze volgen. De kwaliteiten van de individuele ontwikkelaars vor- men de basis voor een gezamenlijke aanpak. Door middel van een open discussie zullen standaards en richtlijnen ontwikkeld worden, waarbij de ontwikkelaar met de meeste ervaring ook de meeste input zal leveren. Vanuit verschillende disciplines ontstaan documenten vanuit de verschil- lende architectuur gezichtspunten. Zo beschrijft een ontwikkelaar vanuit de rol IT architect de technische hardware en infrastructuur vanuit een beheers optiek. Een ontwikkelaar in de rol van applicatie architect bes- chrijft de samenhang tussen de verschillende gereedschappen, de op-
  67. 67. 71 lossingsstrategieën en de toe te passen standaards. De ontwikkelaar in de rol van web architect (een specialisatie op applicatie architectuur) zal extra focus leggen op toegankelijkheid met nadruk op de gebruikersbelev- enis. De ontwikkelaar in de rol van informatiearchitect legt vervolgens de nadruk op informatie als middel voor de organisatie, de ontwikkelaar in de rol van bedrijfsarchitect legt de nadruk op de werkprocessen en de manier van werken, et cetera. De basis voor al deze documenten is een domein specifieke lijst van termen en definities die worden gebruikt binnen de organisatie (DSL), aangevuld met omgevingsspecifieke afspraken. Zo dien je afspraken te maken over de benaming van folders, de benaming van documenten, de benaming van de hoofdstukken binnen een specifiek document, maar ook afspraken maken over de benaming van elementen gebruikt in een programmeertaal. Karakteristiek van Vuxen 2-organisaties is, dat de groep ontwikkelaars de afgesproken standaards volgt. Wegvallen van één persoon binnen de organisatie heeft, behalve eventuele toename van werkdruk, geen im- pact. De gekozen oplossingsstrategieën zijn voor iedereen hetzelfde. Een opvolger kan na het zich inlezen in de materie, snel aansluiting vinden op de afgesproken werkwijze. Anders gezegd Vuxen 2 organisaties schenken aandacht aan de com- municatie binnen alle disciplines. De sturing en focus op kwaliteit zou in onze optiek niet vanuit een individu, maar vanuit een organisatie moeten komen.
  68. 68. 72 Vuxen 3 Defined is het niveau waarbij de belangrijkste processen zijn gestandaar- diseerd. IneenVuxen3-organisatiezaliederesoftwareontwikkelaar,informatiearchi- tect, applicatiearchitect, et cetera, gebruik maken van sjablonen, standaard procedures en daarmee een gestandaardiseerde werkwijze volgen. Er zullen routines ontwikkeld worden voor het geautomatiseerd inrichten van een folder structuur voor het opbergen van documentatie, broncode, et cetera. Daarnaast zijn de authenticatie en autorisatie gestandaardis- eerd. Ontwikkelaars volgen implementatie patronen: zaken die zich keer op keer herhalen, over het algemeen generiek zijn en generiek worden opgelost.
  69. 69. 73 Een voorbeeld: Code tabellen komen in ieder systeem voor. Code tabellen hebben geli- jke eigenschappen, namelijk het creëren, raadplegen, bijwerken en ver- wijderen van codes en zijn representaties. Denk hierbij aan landcodes, valutacodes, taalcodes, et cetera. Er zijn legio oplossingsstrategieën om dit probleem generiek op te lossen: Code tabel Soort code (bijvoorbeeld land, valuta, taal) Code Omschrijving © Van begin tot eind We normaliseren alle code tabellen tot één tabel en schrijven• één onderhoudsprogramma waarmee we de verschillende code tabellen kunnen onderhouden. De generieke code tabel bevat dan meta informatie over het soort code tabel. We maken een sjabloon voor het onderhouden van de code• tabellen en vervangen de naam van de tabel, waarbij we er vanuit gaan dat de velden code en omschrijving generiek zijn. We maken een object voor het onderhouden van de code tabellen• en geven de naam van de tabel door als parameter. Karakteristiek voor de oplossingsstrategie is, dat deze generiek is en specifiek is voor de ontwikkelomgeving. Bedrijven op Vuxen 3 besparen veel tijd en geld door het herkennen en het generiek oplossen van repe- terende werkzaamheden. De afbakening van verantwoordelijkheden geeft houvast in de keuze van op welke plaats welk probleem opgelost moet worden. Karakteristiek van Vuxen 3-organisaties is, dat de groep ontwikke- laars de afgesproken standaards volgt en daarbij wordt ondersteund door sjablonen, scripts en componenten die een probleemgebied hebben geï- soleerd en opgelost. Veel voorkomende werkzaamheden zijn geautomati- seerd, organisaties kunnen vlot inspelen op de vraag uit de markt.
  70. 70. 74 Vuxen 4 Managed is het niveau waarbij de kwaliteit van het ontwikkelproces wordt gemeten zodat het kan worden bijgestuurd. Vuxen 4-organisaties meten de productiviteit. Met betrekking tot de soft- ware productie kan met behulp van Global Functie Punt Analyse (GFPA) het gewicht van een applicatie bepaald worden. De vuistregel van 30 functiepunten per tabel (gemiddeld complex) geeft al snel inzicht in de productiviteit van een specifieke ontwikkelomgeving en geeft ook inzicht in de productiviteit van de individuele ontwikkelaar. Knelpunten kunnen ge- detecteerd worden en gestandaardiseerd worden opgelost. De ontwikkel- cyclus volgt de Dr. Demings Plan, Do, Check, Act paradigma. Door middel van inspectiewerkzaamheden op alle resources verkrijgt men inzicht in de kennis en kunde van de individuele medewerkers, zodat men vervolgens gericht kan gaan scholen. Daarnaast zal feedback naar degene die de standaards bijhouden ervoor zorgen dat werkwijze up-to-date is en aanslu- it op de praktijk. Het toepassen van PDCA zal het software ontwikkeltra- ject professionaliseren. Het ontwikkeltraject wordt transparant, de kosten worden voorspelbaar en niet onbelangrijk: de time-to-market neemt toe.
  71. 71. 75 Vuxen 5 Optimizing is het niveau waarbij het ontwikkelproces als een geoliede ma- chine loopt en er alleen nog sprake is van finetuning (de puntjes op de i). Organisaties op Vuxen 5 zijn in staat programmatuur transparant te ontwik- kelen. De functionele en technische werelden zijn daarbij volledig van el- kaar gescheiden. Dit paradigma wordt beschreven door de Object Man- agement Group (OMG). Het OMG beschrijft het Model Driven Architectuur paradigma, waarin een platform onafhankelijk model (Engels: Platform Independent Model (PIM)), dat wordt omschreven in UML, de eisen van de business vertegenwoordigt. (Requirements, Informatie Model, Werkst-
  72. 72. room en bedrijfsregels). Het Platform Specifieke Model (Engels: Platform Specific Model (PSM) de technische implementatie. Met behulp van een High Level - Domain Specific Language (HL-DSL) kan het Platform Independent Model aangevuld worden met details die niet in de UML modeleer omgeving zijn vast te leggen. (formulieren, formulieren flow, rapportages, et cetera). Vanuit de combinatie PIM en HL-DSL kan vervolgens de broncode worden gegenereerd (zie World Wide Web Model 2 Tekst (M2T) transformaties). In de praktijk vertalen we eerst het Klasse Diagram naar een Entity Re- lationship Diagram (ERD), op het World Wide Web staat dit beschreven onder de titel Query View Transformation (QVT). De volgende stappen worden daarin gemaakt: het vertalen van een ERD met behulp van een QVT naar een generieke query taal, het transformeren van de generieke query taal naar de database specifieke query taal, het zorgen voor het eenvoudig en overzichtelijk houden van de transformaties. Met behulp van de informatie van de Klasse Diagram, de vertaalregels, waarbij rekening wordt gehouden met de gereserveerde woordenlijst, kunnen onder andere tabellen en de daarbij behorende Data Access Objecten (DAO) gecreëerd worden. Met behulp van het klasse diagram en de HL-DSL formulier defini- ties kan men vervolgens de code genereren die noodzakelijk is om de for- mulieren te representeren. De rol van ontwikkelaar is veranderd. Deze zal zich of op een functionele manier met de business bezig houden of met het implementeren van techniek met behulp van een HL-DSL tussentaal. Met behulp van deze werkwijze zullen applicaties niet meer verouderen. Men kan als het ware de laatste inzichten verwerken vanuit zowel een business perspectief als technisch inzicht. Valkuil Het ontwerpen van een HL-DSL kent echter een valkuil. Menig profes- sional is daar reeds met beide benen ingetuind. Techniek onafhankelijk ontwikkelen kan alleen als men voldoende generiek blijft. Op het moment dat een HL-DSL steeds specifieker wordt, verkrijgt de HL-DSL steeds meer programmeertaal eigenschappen. De valkuil van het onbewust namaken van een programmeertaal ligt voor de hand. Een karakteristiek die terug
  73. 73. te vinden is in menig visuele ontwikkelomgevingen, waar bron code en visualisatie synoniemen zijn van elkaar. Keuze De keuze is aan u, welk type organisatie past het best bij u. Indien er geen behoefte bestaat meer grip te krijgen op het automatiseringsproces, zal uw huidige niveau uitstekend passen. In de meest extreme zin kent zelfs Vux- en 1 voordelen. Met beperkte overhead kan met beperkte kennis en kunde functionaliteit geboden worden. Vuxen 1 toepassen bij grote automatiser- ingsprojecten is daarentegen een garantie voor het zwaar overschrijden van het budget, zowel in de realisatie als onderhoud. Vuxen 5 is behoorlijk extreem, dit niveau zal een leverancier van software producten graag toepassen. Het behoud van sleutel rollen is hierbij het gevaar. De informatie is overdraagbaar en eenduidig. Maar wat als deze niet meer gestuurd wordt in de organisatie. Dan wordt het slagschip van de organisatie snel een modderschuit. Binnen één organisatie kan voor het maken van wegwerp software Vuxen 1 worden toegepast, terwijl voor de grote projecten Vuxen 3 wordt toegepast. Daarbij zullen de ontwikkelaars voor Vuxen 1 bij een willekeurige partij kunnen worden ingekocht. Vuxen 3 en hoger eist een strenge selectie en monitoring van de project-leden. Strenge selectie: op kennis en kunde (systeem van grondige kennis). op de wil om samen te werken, de ken- nis en kunde te delen, adoptie en verbeteren van de werkwijze binnen de organisatie.
  74. 74. 78 Tot slot
  75. 75. 79
  76. 76. Ik heb u in dit boekje heel wat stof gegeven om over na te denken. Com- municatie is de rode draad in ieder ICT project. Miscommunicatie kun- nen we voorkomen door afspraken te maken, en het nakomen van deze. Afspraken te monitoren, te verbeteren waar mogelijk en zelfs te optima- liseren we kunnen binnen de ICT in ieder geval afspraken maken met be- trekking tot; spreek en schrijftaal in de vorm van een “Een domein specifieke lijst van termen en definities”. folder en documentatie structuur• het verwoorden van behoefte middels SMART proza• inzichtelijk maken van deze behoefte• visualiseren van deze behoefte• coderen en toepassen van constructie principes•
  77. 77. 82 DSL Van begin tot eind
  78. 78. 83
  79. 79. 84 Term Definitie DRY DRY staat voor Don’t Repeat Yourself. Een paradigma (mind set, voorbeeld dienend model). DRY stelt dat het uitvoeren van identieke acties voorkomen moet worden. DSL Domein Specifieke lijst van termen en definities OCC Observeren, Corrigeren en Controleren. De Nederlandse equivalent van PDCA. PDCA Dr. Deming Kwaliteits Circel (Plan, Do, Check, Act) bedrijfsregels Een bedrijfsregel is een beperking (bijvoorbeeld: factuur- nummer dient aaneensluitend en oplopend te zijn) of een formule (bijvoorbeeld: een loonberekening) impliciete requirements Datgene wat niet gezegd is, maar wel gewenst is informatiemodel Een abstract model van de werkelijkheid oplossingsdomein Oplossing gekoppeld aan de behoefte paradigma Mind set, voorbeeld dienend model proactieve beperkingen Een proactieve beperking (bedrijfsregel) zal alleen de aank- oop mogelijkheid tonen. De gebruiker zal dan direct zien dat de klant geen lid is en de klant eerst lid maken probleemdomein De behoefte, zonder de oplossingen proza Het verwoorden van de behoefte reactieve beperkingen Een reactieve beperking zal, wanneer een klant geen lid is en toch een kunstwerk wil huren, de melding geven “klant dient lid te zijn”.
  80. 80. 85 requirements Inzicht in de behoefte termen en definities Zie DSL werkdomein De te plannen werkzaamheden (na een maak en haalbaar- heids analyse op het oplossingsdomein). werkstroom Activiteiten die ondernomen moeten worden om tot een gewenst resultaat te komen.
  81. 81. 86 Referentie materiaal BEGIN BIJ HET EIND met SMART requirements: Wim Dijkgraaf• en Mike van Spall Vier dagen met Dr. Deming: William Latzko, David Saunders• Spiral Software Process Model: Barry Boehm• MDA Explained: The Model Driven Architecture: Practice and• Promise: Anneke Kleppe, Jos Warmer en Wim Bast Praktisch UML: Anneke Kleppe, Jos Warmer• An introduction to database systems, Chris Date• Functiepunt analyse: www.nesma.nl• Capability Maturity Model: (diverse bronnen internet)•
  82. 82. 87
  83. 83. 88 De kunst in dit boek
  84. 84. 89 De foto’s van kunstwerken die gebruikt zijn in dit boek, zijn beschikbaar gesteld door gallerie/kunstuitleen Dijkstra Waalwijk. Galerie | Kunstuitleen DIJKSTRA 5141 HD Waalwijk (NL) Grotestraat 180 Telefoon: +31 (0)416 33 42 03 Website: http://www.kunstuitleendijkstra.com E-mail: waalwijk@kunstuitleendijkstra.com
  85. 85. 90 Oldrich Tichý (Tsjechië, 1959) Zijn benadering van een binnen- en buitenrealiteit resulteert in schilderijen met krachtige details en symbolen van de visuele wereld, die gelijktijdig, in keuze en manier waarop het motief wordt bekeken, attributen vormen van de aanwezigheid van de mens in de wereld. Zij vertelt ook over de plaats die de kunstenaar zelf inneemt in zijn existen- tiële beleving van de wereld in zijn ondoorgrondelijkheid, zijn voortduring, zijn onveranderlijkheid en in de dynamiek van de fenomenen van leven en kunst, kosmos en ritme van de natuur. De robuuste, kleurrijke en meesterlijk uitgevoerde vormen van de ‘echte’wereld zijn een integraal onderdeel van de imaginaire ruimte van een schilderij, waarmee ze een eenheid vormen, een polyfonische arche- type uit de symbolische wereld vol betekenislagen.
  86. 86. 91
  87. 87. 92 Theo Niermeijer (Nederland, 1940-2005) Niermeijer schilderde, tekende, aquarelleerde, etste en lithografeerde, maar was vooral beeldhouwer. Hij maakte veelvuldig gebruik van ijzer, ijzerafval, autoschroot en staal. Hij noemde zichzelf eens de ‘archeoloog van de schroothoop’. In ‘Museum- journaal 17.2’ zei Hans Sizo over het werk van Theo Niermeijer: ‘Als een soort vuilnisraper van onze westerse, technische beschaving behoeft hij zijn buit slechts van wat rangschikkingen te voorzien, om een aspect van die beschaving voor ons en voor het nageslacht te fixeren...’ Het werk van Theo Niermeijer is stellig niet op de eerste plaats realistisch, ook niet op de eerste plaats mooi of expressief, het is op de eerste plaats Theo Niermeijer.
  88. 88. 93
  89. 89. 94

×