4. 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
5. 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
8. 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;•
9. 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
10. 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.
11. 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
14. 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.
15. 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);
16. 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.
17. 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-
18. 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.
19. 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
20. 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.
21. 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.
23. 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
24. 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.
25. 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.
26. 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.
27. 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
28. 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
29. 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;
30. 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).
31. 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.
32. 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.
33. 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.
35. 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
36. 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
40. 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.
41. 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.
44. 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-
45. 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;
46. 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:
47. 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.
50. 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:
53. 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.
54. 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
56. 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.
57. 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.
59. 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.
60. 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.
61. 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.
66. 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).
67. 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
68. 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.
69. 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.•
70. 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-
71. 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.
72. 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.
74. 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.
75. 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-
76. 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
77. 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.
80. 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•
84. 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”.
85. 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.
86. 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)•
89. 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
90. 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.
92. 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.
