INFORMATIE SYSTEEM ONTWIKKELING ALS EEN PROCES

INFORMATIE SYSTEEM ONTWIKKELING ALS EEN PROCES
Afstudeerscriptie
nr. 319
door
Coen Verleur
Katholieke Universiteit Nijmegen
Faculteit Wiskunde en Informatica
Vakgroep Informatica
Afdeling Informatiesystemen
15 juli 1994
INHOUDSOPGAVE
Inhoudsopgave . . . . . . . . . . . . . . . . . . . . . .
1
Korte samenvatting
. . . . . . . . . . . . . . . . . . .
4
1
Introductie . . . . . . . . . . . . . . . . . .
5
1.1
Vraagstelling . . . . . . . . . . . . . . . . .
5
1.2
Opzet van het onderzoek . . . . . . . . . . . .
5
2
Analyse van de problemen en behoeften . . . . .
6
2.1
Inleiding . . . . . . . . . . . . . . . . . . .
6
2.2
Slagen en/of falen van Informatie Systemen
. .
6
2.2.1
Factoren van het slagen en/of falen . . . . . .
6
2.3
Functionele vereisten . . . . . . . . . . . . .
7
2.3.1
Eisen aan ontwikkelmethoden . . . . . . . . . .
8
2.4
Vereisten aan het Informatie Systeem
. . . . .
8
2.4.1
Informatie en communicatie
. . . . . . . . . .
8
2.4.2
Organisaties veranderen . . . . . . . . . . . .
10
2.4.2.1
Greiner . . . . . . . . . . . . . . . . . . . .
10
2.4.2.2
Quin en Cameron . . . . . . . . . . . . . . . .
10
2.5
Vereisten aan het EIS . . . . . . . . . . . . .
11
3
De globale structuur
. . . . . . . . . . . . .
12
3.1
Inleiding . . . . . . . . . . . . . . . . . . .
12
3.2
Het startpunt van het ontwikkel proces
. . . .
12
3.3
Het conceptuele informatie model
. . . . . . .
12
3.3.1
De verschillende modellen van een IS
. . . . .
13
3.4
Strategieën voor informatie behoefte bepaling .
14
3.4.1
Ordening in de strategieën
14
3.4.2
Ondersteuning van de verschillende processen
1
. . . . . . . . . .
.
15
3.5
De rol van de formele representaties
. . . . .
17
3.5.1
Formele representatie als tussenliggende stap .
17
3.5.2
Formele representatie als referentie document .
18
3.5.3
Soorten documentatie
. . . . . . . . . . . . .
18
3.5.4
Aanpassingen in Evolutionair Informatie
Systeem. . . . . . . . . . . . . . . . . . . .
18
3.6
De rol van grafische representaties . . . . . .
20
3.6.1
Uitdrukkingskracht en compleetheid
. . . . . .
20
3.6.2
Begrijpbaarheid . . . . . . . . . . . . . . . .
22
3.7
Beheersing van de ontwikkeling
. . . . . . . .
22
3.7.1
Beheersen door faseren
. . . . . . . . . . . .
22
3.7.2
Beheersen door documenteren . . . . . . . . . .
22
3.7.3
Beheersen door organiseren
. . . . . . . . . .
23
3.8
Effectieve representatie voor IS ontwikkeling .
25
3.8.1
Het relationele model . . . . . . . . . . . . .
25
3.8.2
Verhalende specificaties
. . . . . . . . . . .
27
3.8.3
Entiteit-Relatie diagrammen . . . . . . . . . .
27
3.8.4
Data Flow Diagrammen
28
3.8.5
Toestandsovergang diagrammen
. . . . . . . . .
29
3.8.6
Wiskundige grammatica’s . . . . . . . . . . . .
30
3.8.7
Data structuur diagrammen . . . . . . . . . . .
31
3.8.8
Voorbeelden uit het werk van de gebruiker . . .
31
3.8.9
Conclusie . . . . . . . . . . . . . . . . . . .
32
3.9
IS ontwikkeling in evoluerende organisaties . .
33
3.9.1
Case tools en Informatie Systeem-ontwikkeling .
34
3.9.2
Architectuur voor een IS
. . . . . . . . . . .
35
3.9.3
Architectuur van het EIS
. . . . . . . . . . .
36
3.9.4
Verschil tussen IS en EIS . . . . . . . . . . .
40
. . . . . . . . . . . . .
2
4
Het proces
in detail . . . . . . . . . . . . .
41
4.1
Inleiding . . . . . . . . . . . . . . . . . . .
41
4.2
Gemodelleerde beschrijving
. . . . . . . . . .
41
4.2.1
Strategieën en hun methoden . . . . . . . . . .
42
4.2.1.1
De groter_dan relatie . . . . . . . . . . . . .
43
4.2.1.2
De kleiner_dan relatie
44
4.2.1.3
Ordening tussen de strategieën
4.2.2
De rol van formele representatie
. . . . . . . . . . . .
. . . . . . . .
46
. . . . . . .
48
4.2.3
De rol van grafische representaties . . . . . .
50
4.2.4
Representatie technieken voor IS ontwikkeling .
53
4.2.4.1
Eigenschappen . . . . . . . . . . . . . . . . .
53
4.2.4.2
Verband eigenschappen - representatie . . . . .
54
4.2.5
De conceptuele informatie modellen
. . . . . .
58
4.2.6
Beheersmethoden voor IS ontwikkeling
. . . . .
62
4.2.7
Aanpassingen in het Informatie Systeem
. . . .
64
4.3
Verband tussen de talen . . . . . . . . . . . .
67
4.3.1
Begrijpbaarheid . . . . . . . . . . . . . . . .
67
4.3.2
Omvang
68
4.3.3
Uitdrukkingskracht
. . . . . . . . . . . . . .
68
4.3.4
Conclusie . . . . . . . . . . . . . . . . . . .
68
. . . . . . . . . . . . . . . . . . . .
3
Korte samenvatting
1
Introductie
. . . . . . . . . . . . . . . . . . .
6
. . . . . . . . . . . . . . . . . . . . .
7
1.1
Vraagstelling
1.2
Opzet van het onderzoek
2
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . .
Analyse van de problemen en behoeften
7
7
. . . . . . . .
8
2.1
Inleiding
. . . . . . . . . . . . . . . . . . . . .
8
2.2
Slagen en/of falen van Informatie Systemen . . . . .
8
2.2.1
2.3
Functionele vereisten
2.3.1
2.4
Factoren van het slagen en/of falen
. . . . . . .
8
. . . . . . . . . . . . . . .
9
Eisen aan ontwikkelmethoden
. . . . . . . . . . .
10
Vereisten aan het Informatie Systeem . . . . . . . .
10
2.4.1
Informatie en communicatie . . . . . . . . . . . .
10
2.4.2
Organisaties veranderen
. . . . . . . . . . . . .
12
. . . . . . . . . . . . . . . . . . . .
12
2.4.2.1
Greiner
2.4.2.2
Quin en Cameron
. . . . . . . . . . . . . . . .
12
. . . . . . . . . . . . . . .
13
De globale structuur . . . . . . . . . . . . . . . . .
14
2.5
3
Vereisten aan het EIS
3.1
Inleiding
. . . . . . . . . . . . . . . . . . . . .
14
3.2
Het startpunt van het ontwikkel proces . . . . . . .
14
3.3
Het conceptuele informatie model . . . . . . . . . .
14
3.3.1
3.4
De verschillende modellen van een IS . . . . . . .
Strategieën voor informatie behoefte bepaling
. . .
16
. . . . . . . . . . . .
16
Ondersteuning van de verschillende processen . . .
17
De rol van de formele representaties . . . . . . . .
19
3.4.1 Ordening in de strategieën
3.4.2
3.5
15
3.5.1
Formele representatie als tussenliggende stap
. .
19
3.5.2
Formele representatie als referentie document
. .
20
3.5.3
Soorten documentatie . . . . . . . . . . . . . . .
20
4
3.5.4
3.6
Aanpassingen in Evolutionair Informatie Systeem. .
. . . . . . . .
22
3.6.1
Uitdrukkingskracht en compleetheid . . . . . . . .
22
3.6.2
Begrijpbaarheid
. . . . . . . . . . . . . . . . .
24
Beheersing van de ontwikkeling . . . . . . . . . . .
24
3.7
De rol van grafische representaties
20
3.7.1
Beheersen door faseren . . . . . . . . . . . . . .
24
3.7.2
Beheersen door documenteren
. . . . . . . . . . .
24
3.7.3
Beheersen door organiseren . . . . . . . . . . . .
25
3.8
Effectieve representatie voor IS ontwikkeling
. . .
27
3.8.1
Het relationele model
. . . . . . . . . . . . . .
27
3.8.2
Verhalende specificaties . . . . . . . . . . . . .
29
3.8.3
Entiteit-Relatie diagrammen
. . . . . . . . . . .
29
3.8.4
Data Flow Diagrammen . . . . . . . . . . . . . . .
30
3.8.5
Toestandsovergang diagrammen . . . . . . . . . . .
31
3.8.6
Wiskundige grammatica’s
. . . . . . . . . . . . .
32
3.8.7
Data structuur diagrammen
. . . . . . . . . . . .
33
3.8.8
Voorbeelden uit het werk van de gebruiker
3.8.9
Conclusie
3.9
. . . .
33
. . . . . . . . . . . . . . . . . . . .
34
IS ontwikkeling in evoluerende organisaties
. . . .
35
3.9.1
Case tools en Informatie Systeem-ontwikkeling
. .
36
3.9.2
Architectuur voor een IS . . . . . . . . . . . . .
37
3.9.3
Architectuur van het EIS . . . . . . . . . . . . .
38
3.9.4
Verschil tussen IS en EIS
. . . . . . . . . . . .
42
. . . . . . . . . . . . . . . .
43
4
Het proces
in detail
4.1
Inleiding
. . . . . . . . . . . . . . . . . . . . .
43
4.2
Gemodelleerde beschrijving . . . . . . . . . . . . .
43
4.2.1
Strategieën en hun methoden
4.2.1.1
De groter_dan relatie
5
. . . . . . . . . . .
44
. . . . . . . . . . . . .
44
4.2.1.2
De kleiner_dan relatie . . . . . . . . . . . . .
46
4.2.1.3
Ordening tussen de strategieën . . . . . . . . .
48
4.2.2
De rol van formele representatie . . . . . . . . .
48
4.2.3
De rol van grafische representaties
50
4.2.4
Representatie technieken voor IS ontwikkeling
. . . . . . .
. .
52
. . . . . . . . . . . . . . . . .
55
4.2.4.1
Eigenschappen
4.2.4.2
Verband eigenschappen - representatie
. . . . .
56
4.2.5
De conceptuele informatie modellen . . . . . . . .
60
4.2.6
Beheersmethoden voor IS ontwikkeling . . . . . . .
63
4.2.7
Aanpassingen in het Informatie Systeem . . . . . .
64
4.3
Verband tussen de talen
. . . . . . . . . . . . . .
69
4.3.1
Begrijpbaarheid
. . . . . . . . . . . . . . . . .
69
4.3.2
Omvang . . . . . . . . . . . . . . . . . . . . . .
70
4.3.3
Uitdrukkingskracht . . . . . . . . . . . . . . . .
70
4.3.4 Conclusie . . . . . . . . . . . . . . . . . . . .
Korte samenvatting
70
Dit artikel gaat over het opstellen van een
raamwerk voor de ontwikkeling van een Informatie
Systeem voor evaluerende organisaties. Het raamwerk
geeft aan, aan welke voorwaarden moet worden
voldaan om tot een succesvol project te komen.
Het artikel is speciaal toegespitst op managers en
eindgebruikers. De managers en eindgebruikers zijn
samengenomen, omdat de splitsing tussen
automatiseerders en niet-automatiseerders is
gemaakt. De rol die de managers en eindgebruikers
bij de ontwikkeling van Informatie Systemen spelen
is vergelijkbaar met betrekking tot de verhouding
met de automatiseerders, ook al spelen beide een
geheel verschillende rol binnen het proces van
automatisering.
6
1
Introductie
1.1
Vraagstelling
Bij de ontwikkeling van Informatie Systemen blijkt er nog al
eens sprake te zijn van het niet slagen van automatiseringsprojecten. De vraag die hier onmiddellijk bij rijst, is: " Wat
is de oorzaak van dit falen van automatiseringsprojecten" en
"Hoe kan dit falen worden voorkomen?"
Hieruit volgt de volgende vraag: "Zijn de beschikbare methoden
geschikt voor de ontwikkeling van Informatie Systemen?". Deze
vraag bevat impliciet de volgende vraag: "Sluiten de eisen,
die de methoden stelt aan de betrokkenen, aan bij wat er
redelijkerwijs van de betrokkenen verwacht mag worden, of zijn
deze eisen te hoog gegrepen?"
In de traditionele Informatie Systeem ontwikkeling wordt er
geen rekening gehouden met veranderende organisaties. Tijdens
het gebruik van het Informatie Systeem verandert de organisatie met als gevolg, dat de aansluiting tussen het Informatie
Systeem en de organisatie niet optimaal meer is. Het
traditionele Informatie Systeem is applicatie afhankelijk,
waardoor de traditionele aanpassing neerkomt op het opnieuw
ontwerpen en ontwikkelen van het Informatie Systeem. De
aanpassingen kunnen niet meer in termen van onderhoud
gebeuren.
Is het mogelijk om het Informatie Systeem zodanig te
ontwikkelen, dat het Informatie Systeem applicatie
onafhankelijk is? Is het mogelijk om het onderhoud zodanig uit
te voeren, dat de reguliere arbeidsprocessen hier niet onder
lijden? Is hieruit een methode te ontwikkelen om het
Informatie Systeem te ontwikkelen, zodanig dat het Informatie
Systeem blijvend aansluit op de informatie behoefte van de
organisatie? Is zo’n methode praktisch toepasbaar?
1.2
Opzet van het onderzoek
Aan dit onderzoek is een gedegen literatuur studie
voorafgegaan om tot een inzicht te komen in de problematiek
die bij de organisaties speelt. In het kader van het onderzoek
heb ik als uitgangspunt het boek ’Grondslagen van de
informatica voor managers en eindgebruikers’ [Nijssen] en het
artikel ’Evolution and time in Information Systems’ [FOP]
gebruikt. Het eerste geeft een raamwerk voor Informatie
Systeem ontwikkeling op de traditionele manier, terwijl het
tweede inzicht geeft in de vereisten van een evoluerend
Informatie Systeem.
7
2
Analyse van de problemen en behoeften
2.1
Inleiding
In dit hoofdstuk worden ten eerste problemen aan de orde
gesteld, waarbij het gaat om de problemen van het
(des)functioneren van het Informatie Systeem in de
organisatie. Verder worden er, mede aan de hand van de
geanalyseerde problemen, eisen geformuleerd, waaraan het
Informatie Systeem en de ontwikkelmethode minimaal moeten
voldoen.
2.2
Slagen en/of falen van Informatie Systemen
Veel systemen die ontwikkeld worden, lijden aan de Software
Crisis. De oorzaak hiervan is hoofdzakelijk te wijten aan een
overschrijding van de kosten, een overschrijding van de
opleverdatum en het niet voorzien in de werkelijke behoefte
van de gebruikers. In werkelijkheid bestaat de Software Crisis
uit twee delen: De Systeem Software Crisis en de Information
Software Crisis. Het eerste houdt in, dat de basis
operationele software niet effectief geproduceerd en
betrouwbaar gebruikt kan worden. Het tweede deel houdt in, dat
de applicatie specifieke software niet effectief geproduceerd
en betrouwbaar gebruikt kan worden.
2.2.1
Factoren van het slagen en/of falen
De factoren die een rol spelen bij het slagen en/of falen van
een project om het als mislukt, problematisch of geslaagd te
kunnen beschouwen moeten tegen elkaar afgewogen worden.
[Doorewaard]
Als indicatie voor het aantal geslaagde systemen kan het
volgende gegeven worden, naar een onderzoek uit ’88 door
Riesewijk en Warmerdam:
Geslaagd
51.1 %
Problematisch
43.8 %
Mislukt
4.7 %
Allereerst zijn er de relationele factoren. Hiervan is sprake
als er op het gebied van communicatie problemen ontstaan,
doordat de betrokken partijen niet, of niet op de juiste
manier, bij het communicatie netwerk van het project betrokken
worden. Er bestaan verschillende semantieken, die voor de
verschillende partijen een duidelijke betekenis hebben. Deze
verschillende semantieken kunnen bij een gebrekkige
communicatie voor problemen zorgen.
Verder zijn er de conditionerende factoren. Deze hebben
betrekking op de voorwaarden of condities waarin de betrokken
organisaties moeten werken. Hieronder vallen de kenmerken van
de organisatie cultuur en structuur, kenmerken van het
project, kenmerken van het personeelsbestand etc.
8
Er kan een ordening in de kritische factoren gegeven worden.
Als zeer problematische factoren gelden de doorlooptijd en de
kosten, de project bewaking vanuit een extern bureau en de
communicatie tussen automatiseerders en management.
Een klasse factoren die als minder problematisch geldt is die
van de organisatorische inpassing van het systeem, de
afstemming van de verschillende belangen, het overleg tussen
de betrokkenen en de acceptatie van het systeem door het
personeel.
Als minst problematisch geldt de gebruiksvriendelijkheid, de
training en opleiding van het personeel en herplaatsing en
omscholing.
Een bijkomend probleem bij het slagen en/of falen van de
ontwikkeling van Informatie Systemen is, dat er een periode
van ± 10 jaar ligt tussen de ontwikkeling van een theorie en
het toepassen hiervan in de praktijk. Hiervoor zijn een aantal
oorzaken te noemen.
Allereerst gaat de wetenschapper ervan uit, dat de manager
altijd de beste oplossing zal kiezen. In de praktijk echter
blijkt dat de manager echt slechte oplossingen vermijdt en het
liefst kiest voor een bruikbaar alternatief, dat niet teveel
risico inhoudt en wat snel te realiseren is.
Vervolgens is het een gegeven, dat de manager altijd
tijdgebrek heeft, dus een dag cursus is taboe, en mocht de
manager al naar een cursus toegaan, dan blijkt dat daar de
nieuwe theorieën uitgelegd worden in plaats van hoe het
bedrijf ervan kan profiteren. De manager is dus eigenlijk op
zoek naar recepten in plaats van theorieën. Nu rijst dus het
probleem: Hoe draag je de wetenschap over op de manager? Als
laatste is er de aard van het wetenschappelijk onderzoek. Een
groot deel van het wetenschappelijk onderzoek betreft
problemen, die de manager niet als het belangrijkste
beschouwd. Als gevolg hiervan worden de ontwikkelingen in de
theorie, niet (snel genoeg) in de praktijk gebracht.
Een factor waar bij automatiserings-projecten geen rekening
mee gehouden wordt is het bestaan van een informele
organisatie structuur naast de bestaande formele structuur.
Deze informele organisatie structuur is te beschouwen als een
voortdurend veranderend sociaal systeem, dat uit wisselende
relaties tussen personen bestaat. Het werkt over het algemeen
als smeerolie waarop de organisatie loopt. Het gevaar bestaat,
dat bij automatiseringsprojecten deze informele structuur
verloren gaat.
2.3
Functionele vereisten
Alle ontwikkel methoden bevatten een onderdeel, waar de
functionele vereisten achterhaald worden. De functionele eisen
zijn afhankelijk van de soort organisatie, het beslissingsniveau van het Informatie Systeem, de functie en de soort
beslisser. De functionele eisen van Informatie Systemen zijn
af te leiden uit de karakteristieken van het bestuurde systeem
en het besturend orgaan.
9
2.3.1
Eisen aan ontwikkelmethoden
Elke ontwikkelmethode moet aan bepaalde eisen voldoen, wil de
methode kans van slagen hebben. Deze eisen liggen op het
gebied van de effectiviteit en efficiency.
Voor de eisen aan de effectiviteit geldt, dat de methode
zodanig van opzet moet zijn, dat deze effectieve ondersteuning
biedt bij het ontwerp- en constructieproces, met als
uiteindelijk resultaat een functioneel goed Informatie
Systeem.
Voor de eisen aan de efficiency geldt, dat de methode
voldoende aanknopingspunten dient te bieden voor efficiënt
beheer van het ontwikkelproces als zodanig.
2.4
Vereisten aan het Informatie Systeem
Aan het Informatie Systeem kunnen verschillende eisen worden
gesteld ten aanzien van de informatie behoefte en de
communicatie. De eisen ten aanzien van de communicatie kunnen
worden afgeleid uit de architectuur van het bestaande
Informatie Systeem en uit de eisen die ten aanzien van de
(menselijke) communicatie moeten gelden.
2.4.1
Informatie en communicatie
Het uitgangspunt is de aanname, dat een Informatie Systeem
wordt ontworpen om de communicatie tussen mensen te
ondersteunen. Dus we beginnen de ontwikkeling van de
architectuur van een Informatie Systeem met een eenvoudig
model van menselijke communicatie. Communicatie is de
uitwisseling van informatie tussen meerdere (groepen)
personen. Hieruit is het volgende basis axioma af te leiden:
’Een Informatie Systeem is een systeem, die de communicatie
van taalkundige zinnen (feiten) tussen mensen ondersteunt.’
Hieruit ontwikkelen we een model van een Informatie Systeem,
dat iedere relevante component van zo’n Informatie Systeem
bevat en hun interacties beschrijft (grafische taal). Dit
model bestaat uit twee componenten, te weten de Software
Information Processor en de Human Information Processor. De
Software Information Processor is een actieve component die
informatie kan behandelen volgens van te voren vastgestelde
regels. De Human Information Processor is een mens, die een
proces uitvoert.
10
Het is niet genoeg dat twee communicatie partners dezelfde
taal spreken, ze moeten ook de taal in dezelfde context
plaatsen, zodanig dat er geen andere interpretatie mogelijk
kan zijn. Met andere woorden: de twee communicatie partners
moeten hetzelfde woord model gebruiken, zodat ze dezelfde
betekenis aan dezelfde zinnen geven. [Nijssen]
Voorbeelden:
A: Reagan en Bush (communicatie partners) spreken dezelfde
taal (Engels) en delen hetzelfde interpretatie model als
het om politiek gaat.
B: Bush en Dukakis (communicatie partners) spreken dezelfde
taal (Engels), maar delen niet hetzelfde interpretatie
model. Bijvoorbeeld: Bij de uitwisseling van kennis over
sociale zekerheidspolitiek is een goed uitgangspunt voor
een debat, maar geen effectieve uitwisseling van feiten.
C: Een Chinees en een Cubaan delen hetzelfde interpretatie
model (beide communist), maar ze spreken niet dezelfde
taal.
D: Fidel Castro en Ronald Reagan spreken noch dezelfde taal,
noch delen zij hetzelfde interpretatie model.
Alleen bij A is er sprake van effectieve communicatie, omdat
dit het enige voorbeeld is waarbij sprake is van dezelfde taal
en hetzelfde interpretatie model. Bij allen is er sprake van
hetzelfde communicatie kanaal.
Eisen die tot dusver voor een effectieve menselijke
communicatie gesteld worden zijn het gemeenschappelijk
communicatie kanaal, de gemeenschappelijke taal en het
gemeenschappelijk interpretatie model.
Eisen die gesteld worden aan de menselijke communicatie,
worden ook aan de architectuur van het Informatie Systeem
gesteld, omdat dit het communicatie middel met de mens is. Er
moet dus sprake zijn van een gemeenschappelijk communicatie
kanaal, gemeenschappelijke taal en een gemeenschappelijk
interpretatie model.
Indien het gemeenschappelijke communicatie kanaal ontbreekt,
dan betekent dit, dat er geen communicatie mogelijk is tussen
de gebruiker en het Informatie Systeem.
Voor de gemeenschappelijke taal zijn er twee mogelijkheden.
Ten eerste is er de natuurlijke taal. Het is echter niet
mogelijk de computer direct in een menselijke taal te laten
communiceren. Een tweede mogelijkheid is de computertaal. Een
voorbeeld hiervan is SQL, wat wordt gebruikt om informatie
over te brengen naar het relationeel database management
systeem.
In veel Informatie Systemen is de formele taal geïmplementeerd
in het Informatie Systeem, zodat er geen fysieke Database is
die de definitie van de formele taal bevat. Voor het
gemeenschappelijk interpretatie model moet het Informatie
Systeem een formeel model bevatten, wat exact definieert welke
feiten zijn toegestaan. Elk bericht van de gebruiker moet
worden gecontroleerd op zijn correctheid.
11
2.4.2
Organisaties veranderen
Samen met de organisaties verandert de informatie behoefte van
de organisaties. In de loop der jaren zijn er verschillende
modellen van organisaties ontwikkeld. Bij al deze modellen
doorloopt de organisatie een aantal fasen of stadia.
[Bemelmans]
2.4.2.1
Greiner
Organisaties doorlopen verschillende groeifasen. Elke fase is
te beschouwen als een soort evolutie, die aan het eind
afgesloten wordt met een crisis situatie (revolutie). Elke
fase heeft een aantal kenmerken, die weer consequenties hebben
voor de vorm en de opzet van het Informatie Systeem (soort
informatie).
2.4.2.2
Quin en Cameron
Uit een vergelijking van 9 verschillende modellen komen Quin
en Cameron tot een model met vier stadia. Elk stadium heeft
zijn eigen kenmerken, die terug te voeren zijn tot drie
essentiële dimensies, namelijk de oriëntatie van de
organisatie, de organisatie cultuur en structuur en het
hoofdobject van beslissingen.
De oriëntatie van de organisatie is ten eerste extern gericht.
Dit houdt in, dat er afzetmarkten gecreëerd en produktiemiddelen verworven moeten worden. Ten tweede is deze dimensie
intern gericht. Dit houdt het motiveren van het personeel en
consolideren van resultaten in.
De organisatie cultuur en structuur houdt de flexibiliteit van
de organisatie de formalisering en bureaucratisering in. Het
hoofdobject van beslissingen legt het zwaartepunt op het
verwerven en efficiënt inzetten van noodzakelijke middelen en
op het ontwikkelen ven nieuwe produkt/markt combinaties en het
formuleren van nieuwe strategieën. Hierbij moet echter de
kanttekening geplaatst worden, dat niet alle onderdelen van de
organisatie zich noodzakelijkerwijs in dezelfde fase bevinden.
Samenvattend betekent dit, dat de organisatie vaak en snel
verandert en dus verandert de informatie behoefte van de
organisatie ook. Dus er is behoefte aan een doelmatige
strategie om het Informatie Systeem ook vaak en snel te kunnen
laten veranderen, om bij de informatie behoefte aan te kunnen
sluiten.
12
2.5
Vereisten aan het EIS
De grootste eis die gesteld kan worden aan een Evolutionair
Informatie Systeem, is dat het ’meegroeit’ met de organisatie,
zonder dat er een onderbreking komt van de processen van de
organisatie. Dit meegroeien houdt in, dat het Informatie
Systeem de veranderingen van de organisatie volgt, op een
zodanige wijze, dat het verschil tussen de afbeelding en de
werkelijkheid klein blijft. Uit deze vereiste kunnen verschillende eisen gespecificeerd worden.
Ten eerste staat het Informatie Systeem aanpassingen toe van
alle informatie, die afhankelijk is van het Universe of
Discourse van het Informatie Systeem. De specificatie van
informatie die afhankelijk is van een specifiek organisatie
domein is deel van de architectuur van het Evolutionair
Informatie Systeem.
Ten tweede staat het Informatie Systeem correctie toe van
(eerder) opgeslagen informatie. Het kan blijken, dat de
opgeslagen informatie niet (meer) blijkt te voldoen aan de
vereisten. De noodzaak voor correctie wordt gegeven door
validatie. Consistentie wordt gecontroleerd door het systeem.
Ten derde vergeet het systeem geen informatie, tenzij het
expliciet gevraagd wordt. Met andere woorden de complete
geschiedenis van informatie binnen het Informatie Systeem
blijft bewaard.
Als laatste mogen aanpassingen van het Informatie Systeem de
organisatie activiteiten niet onderbreken. De intentie van het
Evolutionair Informatie Systeem is het verschil tussen
behoefte en aanbod van informatie te minimaliseren. Als gevolg
hiervan moet de factor tijd moet aan het Informatie Systeem
worden toegevoegd, om verschillende soorten tijdstippen te
kunnen opslaan. De eerste soort is het tijdstip van de
gebeurtenis. Deze wordt gebruikt voor het opslaan van de
geschiedenis van informatie. De tweede soort is het tijdstip
van de opslag van gegevens. Deze wordt gebruikt om correcties
uit te kunnen voeren is een roll back operator vereist. [FOP]
13
3
De globale structuur
3.1
Inleiding
Uit het vorige hoofdstuk blijkt, dat de informatie behoefte
binnen de organisaties verandert, doordat de organisaties
veranderen. Aan de hand hiervan worden de eisen ten aanzien
het Informatie Systeem geformuleerd.
In dit hoofdstuk worden, voor de in het vorige hoofdstuk
geformuleerde problemen en behoeften, alternatieven
geformuleerd.
3.2
Het startpunt van het ontwikkel proces
Bij het vastleggen van de vereisten bestaat de initiële invoer
uit ruw materiaal bestaan. Dit is een niet precieze, niet
bruikbaar gestructureerde, vage en incomplete specificatie van
de vereisten. Dit ruwe materiaal kan niet worden uitgedrukt in
goed gedefinieerde interpreteerbare computertaal.
De eerste en meest essentiële taak bij Informatie Systeem
ontwikkeling is de informele vereisten uitdrukken in een
formele taal. Dit kan niet door software gerealiseerd worden.
Met andere woorden betekent dit, dat er ruimte is tussen de
informele en de formele representatie. Deze ruimte, de
semantische leemte, ook wel ’semantic gap’ genaamd, moet
overbrugd worden. Het doel van iedere Informatie Systeem
ontwikkelmethode is het leveren van een effectieve
overbrugging. De meeste ontwikkelmethoden missen zo’n
effectieve overbrugging. Ze gaan er van uit dat de gebruiker
deze leemte overbrugt, waarbij hij elke methodische
ondersteuning mist. De vraag rijst nu, hoe de gebruiker de
invoer betrouwbaar kan leveren en hoe de analist de geleverde
invoer kan interpreteren in een formele representatie
structuur.
3.3
Het conceptuele informatie model
De verschillende partijen, die betrokken zijn bij de
ontwikkeling van een Informatie Systeem moeten een grote mate
van overeenstemming hebben over de relevant geachte
conceptuele modellen. Wordt aan deze voorwaarde niet voldaan,
dan is de kans op communicatie stoornissen groot.
14
3.3.1
De verschillende modellen van een IS
Eén onderdeel bij het ontwikkelen van een Informatie Systeem
is het opstellen van conceptuele informatie modellen van een
besturing situatie. Hierin wordt aangegeven voor welk
management en voor welke beslissing informatie nodig is,
waarom en wanneer. We onderscheiden hier als eerste het
systologisch model. Dit model beschrijft de pragmatische
aspecten (het wat en waarom van de informatie).
Daarnaast bestaat het infologisch model. Dit model beschrijft
de semantische aspecten. Hier wordt ingegaan op de gegevensen verwerkingsprocessen die nodig zijn om die informatie te
kunnen produceren.
Verder is er het datalogische model. Dit model beschrijft de
syntactische aspecten (op welke wijze en in welke vorm moet
het systeem worden verwezenlijkt).
Als laatste is er het technische model. Hierin wordt concreet
aangegeven welke technische faciliteiten zullen worden
gebruikt.
Afbeelding 1:
De verschillende modellen
15
3.4
Strategieën voor informatie behoefte bepaling
De meest eenvoudige strategie voor het bepalen van de
informatie behoefte is het simpelweg vragen naar de
informatiebehoefte aan gebruikers. Dit levert veelal slechte
resultaten. Als oorzaak hiervoor wordt gegeven, dat de
informatiebehoefte divers en complex van aard is, de
interactie tussen gebruikers en ontwerpers veelal lacunes
vertoont, sommige gebruikers weigeren mee te werken aan het
inventariseren en structureren van de informatiebehoefte en
dat gebruikers beperkt zijn in hun mogelijkheden om de
informatiebehoefte te specificeren.
De capaciteit van de gebruikers blijkt in het algemeen
ontoereikend te zijn om een volledig overzicht van de behoefte
te specificeren.
Verder blijkt dat de gebruikers een afwijking vertonen bij het
specificeren. Ze refereren bij voorkeur aan bestaande systemen
en maken zich zodoende onvoldoende los van het bestaande om de
behoeften te specificeren, ze geven een zwaarder gewicht aan
recent opgetreden behoeften en ze kunnen moeilijk oorzaakgevolg relaties onderkennen, en geven hierdoor de verkeerde
informatie.
3.4.1 Ordening in de strategieën
Olsen en Davis geven verschillende strategieën om de
informatie behoefte te bepalen, gerangschikt van hoge naar
lage mate van onzekerheid.
De strategie met de hoogste mate van onzekerheid is de
oberstrategie. Dit is het ondervragen van gebruikers. Hiervoor
zijn diverse methoden, zoals het houden interviews en
enquêtes, brainstorming en de Delphi-methode. Dit laatste is
een gestructureerde ondervraging met het doel extreme visies
met argumenten te onderbouwen. Deze strategie is te hanteren
bij goed te structureren problemen, waarbij kennis- en
ervaringsniveau bij gebruikers hoog is, er een beperkt aantal
gebruikers en er goed getrainde informatie deskundigen bij het
project betrokken zijn.
De strategie die hierop volgt is de referentie strategie.
Hierbij worden bestaande systemen als referentiekader genomen
(bijv. standaard pakketten). De methode is gebaseerd op het
vergelijken van besturing situaties met soortgelijke situaties
en daarvoor ontwikkelde Informatie Systemen. De strategie is
te hanteren bij goed te structureren problemen, die stabiel in
de tijd zijn. Het referentie systeem moet een goede afspiegeling zijn van het gewenste Informatie Systeem. De hierop
volgende strategie is de ontwikkel strategie. Hier wordt een
zorgvuldige analyse en structurering van de besturingssituatie
en het te ontwikkelen Informatie Systeem door informatie
deskundigen en gebruikers gemaakt. Methoden hiervoor zijn de
kritische succes-factor analyse, Socio-technische analyse,
beslissings (operational research) georiënteerde aanpak en
proces georiënteerde aanpak en methoden (bijv ISAC).
De ontwikkel strategie is te hanteren als referentie systemen
ontbreken, problemen minder goed te structureren zijn, het
16
kennis/ervarings niveau gebruikers middelmatig is, informatie
deskundigen van hoog niveau zijn of het Informatie Systeem
complex is met tal van interfaces.
De strategie met de laagste mate van onzekerheid is de
evolutionaire strategie (ook wel de iteratieve strategie): Het
ontwerp en de constructie gebeurt in een aantal kleine
incrementele stappen. De methoden hierbij is de prototype
benadering of de data-georiënteerde methode. Deze strategie is
te hanteren bij hoge onzekerheid met betrekking tot specificaties, sterk groeiende informatie behoeften of als gebruikers
en informatie deskundigen de expertise missen om een Informatie Systeem in zijn totaliteit te ontwikkelen. [Bemelmans]
3.4.2
Ondersteuning van de verschillende processen
De verschillende processen in een organisatie worden
ondersteund, de verschillende onderdelen uit de onderstaande
figuur. Deze ondersteuning is ook van belang voor de
verschillende onderdelen van IS ontwikkeling. Zetten we deze
ondersteuning af tegen de strategieën om de informatie
behoefte te bepalen, dan volgt hieruit het volgende.
Bij de oberstrategie staat de wijze van werken vast. Hierdoor
wordt de wijze van ondersteuning en besturing bepaald. Aan de
hand hiervan wordt de wijze van modellering ingevuld.
Bij de referentie strategie staat de wijze van besturen vast.
Zoals beschreven gaat het er bij deze strategie om een
bestaand systeem als referentiekader te nemen, waar het
besturingssysteem vergelijkbaar is. Als gevolg hiervan moet de
manier van denken ook grote overeenkomsten vertonen met de
ondersteuning van het bestaande systeem. De resterende
onderdelen, de manier van werken, modelleren en ondersteunen,
worden hierdoor in grote lijnen bepaalt door de twee
vaststaande onderdelen.
Bij de ontwikkel strategie wordt een zorgvuldige analyse en
een structurering van de besturingssituatie gemaakt. Dit houdt
in, dat de manier van besturen en modelleren hierdoor
vaststaat. De wijze van werken en ondersteunen wordt aan de
hand hiervan bepaald.
Bij de evolutie strategie wordt het ontwerp en constructie in
kleine incrementele stappen gemaakt. Hierdoor staat de wijze
van werken en besturen vast. Aan hand hiervan worden de wijze
van ondersteunen en modelleren bepaald.
17
Afbeelding 2:
Proces ondersteuning
Uit het bovenstaande blijkt, dat de gekozen strategie bepaalt
hoe de wijze van denken, besturen, modelleren, werken en
ondersteunen moet worden ingevuld. Hierbij staat er een
gedeelte vast, terwijl de rest aan de hand hiervan worden
bepaald. Zie voor een schematisch overzicht de onderstaande
figuur.
Wijze van ..
Werken
Modelleren
Besturen
Ondersteunen
Denken
B
B
V
B
B
V
V
V
B
B
B
B
I
V
I
I
Strategie
Ober
Referentie
Ontwikkel
Evolutie
V
B
B
V
Legenda: V = Staat vast.
B = Wordt bepaald aan de hand van het vaststaande.
I = In te vullen aan de hand van B en V.
18
3.5
De rol van de formele representaties
Formele representaties spelen een dubbele rol in het ontwikkel
proces. Allereerst spelen zij de rol van een tussenliggende
fase tussen de initiële, informele specificatie en de
uiteindelijke, uitvoerbare implementatie. Een tweede rol die
zij spelen is de rol van formeel referentie document, wat de
systeem vereisten beschrijft.
3.5.1
Formele representatie als tussenliggende stap
De initiële representatie moet worden uitgedrukt in een taal
die zo dicht mogelijk bij de taal van de gebruiker ligt,
zonder gebruik te maken van computer georiënteerde
uitdrukkingen. De uiteindelijke representatie is een formeel
Informatie Systeem, dat aan de gespecificeerde eisen voldoet.
Het verschil tussen deze twee representaties is te groot om
het in algemeenheid in één keer op te lossen.
Zodra er een formele representatie is, moet deze gevalideerd
worden. Een effectief validatie proces moet de inhoud van de
formele specificatie vertalen naar de gebruiker, zodat het
voor de gebruiker duidelijk is, wat er gespecificeerd is. Dus
elk van de formele tussenfasen moet een duidelijke verband
aangeven met de initiële representatie.
Deze tussenliggende fasen moeten bij elkaar compleet zijn,
zodat de programmeur geen arbitraire beslissingen meer hoeft
te nemen.
19
3.5.2
Formele representatie als referentie document
Formele representaties leveren een consistentie en
visualiseerbaarheid gedurende het ontwerp proces. Het bevat de
eisen van de gebruiker en een ontwerp dat hieraan voldoet. Aan
iedere formele representatie in het ontwerp proces moet de
volgende vraag worden gesteld. Hoe betrouwbaar kunnen de
formele specificaties worden geïmplementeerd en gevalideerd.
Ofwel: Kunnen de specificaties rechtstreeks worden
geïmplementeerd, of moet de programmeur nog terug naar
gebruiker? Begrijpt de gebruiker de inhoud van de
specificaties werkelijk om te beslissen of ze voldoen aan zijn
vereisten?
3.5.3
Soorten documentatie
Er bestaan verschillende soorten documenten, die op
verschillende wijzen worden gemaakt. Allereerst zijn er de
essentiële ontwerp documenten. Deze worden direct gemaakt, als
een resultaat van een ontwerp of analyse activiteit en die
worden gebruikt als invoer verder in het proces. Verder zijn
er de niet essentiële ontwerp documenten. Deze worden gemaakt
als een op zichzelf staande ontwerp activiteit, meestal nadat
de ontwikkeling is afgerond.
De essentiële documentatie representeert een betrouwbare basis
voor onderhoud en toekomstige wijzigingen. De tweede groep
documentatie is lastig aan te passen en bevatten daardoor
gemakkelijk redundantie of voortdurende onjuistheden.
3.5.4
Aanpassingen in Evolutionair Informatie Systeem.
Het is de bedoeling, dat het Informatie Systeem de informatie
behoefte van de organisatie vervult. Omdat de behoefte en de
informatie zelf verandert moet het Informatie Systeem
aangepast worden.
3.5.4.1
Aanpassingen in het traditionele IS
Aanpassingen moeten resulteren in een toestandsverandering,
zodanig dat de nieuwe toestand de huidige toestand van de
organisatie weergeeft. Hierbij dient er gecontroleerd te
worden of de informatie betrouwbaar en consistent is.
Aanpassingen bestaan hier gewoonlijk uit toevoeging,
verwijdering of verandering (van delen) van informatie. Het
resultaat is een nieuwe toestand, waarbij de vorige toestand
verloren gaat. Er is geen ondersteuning van het begrip tijd.
Als gevolg hiervan kunnen vorige toestanden niet worden
teruggehaald. Er is hier sprake van een snapshot systeem.
20
3.5.4.2
Aanpassingen in Evolutionair Informatie Systeem
Een ideaal Informatie Systeem geeft op elk moment de correcte
toestand van de organisatie weer. Elke gebeurtenis, ofwel elke
toestandsverandering, in de organisatie heeft een aanpassing
van het Informatie Systeem als gevolg. Dit soort aanpassingen
heet opslag van een gebeurtenis.
Een andere mogelijkheid tot aanpassing is, dat de informatie
die afgeleid wordt van de opgeslagen gebeurtenissen niet, of
niet meer, correct is. Hier is een aanpassing nodig, om de
afbeelding van de organisatie op het Informatie Systeem te
corrigeren. Zo’n soort aanpassing heet correctie. Het
verandert de opslag van een gebeurtenis die al eerder heeft
plaatsgevonden.
De laatste soort aanpassing die kan plaatsvinden is het
verwijderen van informatie. Het betreft hier een verzoek tot
verwijderen van informatie, bijvoorbeeld door de wet gegeven.
3.5.4.2.1
Opslag
Als er een gebeurtenis optreedt in de organisatie, dan moet er
met het Informatie Systeem gecommuniceerd worden door middel
van een aanpassingsverzoek. De gebeurtenis wordt afgebeeld
door het uitvoeren van dit verzoek. De aanpassing wordt
uitgevoerd door een aantal elementaire overgangen. Er worden
drie soorten elementaire overgangen onderscheiden: geboorte,
overlijden en verandering. Bij de eerste wordt een nieuw
element aan het applicatie model toegevoegd, bij de tweede
wordt een element uit het applicatie model verwijderd terwijl
bij de laatste er een overgang plaatsvindt van het ene naar
een ander element in het applicatie model.
Aangezien er geen informatie verloren mag gaan, wordt de
geschiedenis van de applicatie model elementen bewaard, door
de veranderingen samen met de tijdstippen waarop dit gebeurt
op te slaan.
3.5.4.2.2
Correctie
Een Informatie Systeem geeft de organisatie correct weer dan
en slechts dan, als er een isomorfisme bestaat tussen de
toestanden in de organisatie en het Informatie Systeem. Het is
een vereiste, dat de afbeelding van de organisatie op het
Informatie Systeem elke gebeurtenis in de organisatie
weergeeft als een gebeurtenis in het Informatie Systeem.
Doordat het tijdstip waarop de gebeurtenis heeft
plaatsgevonden wordt opgeslagen, is de volgorde van de
gebeurtenis af te leiden. Heeft er een foute opslag
plaatsgevonden dan kan er een correctie plaatsvinden.
21
De correctie kan bestaan uit het invoegen van een gebeurtenis,
het verwijderen van een opslag of vervanging van een opslag.
Om de correctie te verwezenlijken moet het mogelijk zijn, om
een vorige toestand terug te halen. De operatie waar hier
gebruik van wordt gemaakt is de roll back operator.
3.5.4.2.3
Vergeten
In de meeste gevallen zou een ideaal Informatie Systeem geen
informatie kwijtraken. Het kan echter gebeuren, dat er in
sommige gevallen, bijvoorbeeld om privacy redenen, informatie
moet worden vergeten. Dit mag echter niet leiden tot een
situatie, waarin andere informatie niet meer teruggehaald kan
worden of inconsistent wordt.
3.6
De rol van grafische representaties
Grafische representaties kunnen verschillende voordelen
hebben. Ze kunnen namelijk veel informatie in een compacte
vorm bevatten (één plaatje zegt meer dan 1000 woorden). Verder
zijn grafische representaties intuïtief eenvoudig te begrijpen
voor gebruikers.
3.6.1
Uitdrukkingskracht en compleetheid
Met de uitdrukkingskracht wordt aangegeven of elke formele
categorie van de onderliggende specificatie uitgedrukt kan
worden. Met de compleetheid wordt aangegeven of het diagram
alle onderliggende specificaties weergeeft.
Het blijkt echter, dat geen enkele overzichtelijke grafische
representatie compleet is. Stel een representatie is compleet
en overzichtelijk, dus elke beperking wordt hierin
weergegeven, dan betekent dit dat het niet meer overzichtelijk
en dus niet meer eenvoudig begrijpbaar is.
3.6.1.1
Soorten incompleetheid
Er bestaan verschillende soorten van incompleetheid.
Allereerst is er veilige incompleetheid. Elke bevolkbare
constructor kan worden weergegeven in het diagram, maar niet
elke beperking heeft een representatie. Het is dus compleet in
de zin, dat het alle soorten informatie die opgeslagen moeten
kunnen worden representeert, maar dat het niet elke beperking
op de populatie representeert.
Met andere woorden de grafische specificatie staat bepaalde
implementaties toe die voldoen aan de gebruikers informatie
vereisten, maar het staat ook implementaties toe die niet aan
de gebruikers eisen voldoen.
22
Daarnaast bestaat er onveilige incompleetheid. Deze geeft noch
elke bevolkbare constructor, noch elke beperking weer. Hierin
kunnen dus ook niet-legale database toestanden voorkomen.
3.6.1.2
Relatie veilige en onveilige incompleetheid
Bij de geïmplementeerde database toestanden, die toegestaan
zijn door de gebruiker en door de specificaties, kan veilige
en onveilige compleetheid bestaan. Hiertussen bestaat de
volgende relatie.
Elke database toestand die de gebruiker wenst, kan worden
weergegeven door een veilige incomplete grafische taal.
Bepaalde database toestanden die de gebruiker wenst uit te
sluiten kunnen worden toegestaan in een veilige incomplete
grafische taal.
Bepaalde database toestanden die de gebruiker wenst, kunnen
worden weergegeven in een onveilige incomplete grafische taal.
Bepaalde database toestanden die de gebruiker wenst, kunnen
niet worden weergegeven in een onveilige incomplete grafische
taal.
Bepaalde database toestanden die de gebruiker wenst uit te
sluiten, kunnen niet worden weergegeven in een onveilige
incomplete grafische taal.
Afbeelding 3:
Soorten DB toestanden
23
3.6.2
Begrijpbaarheid
Met begrijpbaarheid wordt aangegeven of de gebruiker de
bedoeling van het diagram begrijpt. Diagrammen kunnen een
abstracte, formele specificatie weergeven aan de gebruiker.
Als de gebruiker getraind is om deze diagrammen te begrijpen,
dan zijn de diagrammen een effectieve manier om de
specificaties weer te geven. Dit is slechts zelden het geval.
Als gevolg hiervan kunnen de diagrammen alleen als
toevoegingen worden bijgevoegd.
3.7
Beheersing van de ontwikkeling
De ontwikkeling van een Informatie Systeem is een omvangrijke
taak. Het is hierbij van belang, dat de ontwikkeling
beheersbaar blijft.
Deze beheersing kan op verschillende manieren worden
verwezenlijkt.
3.7.1
Beheersen door faseren
Doel van de faseringen van het ontwikkelen van informatie
systemen is het aanbrengen van duidelijke mijlpalen. Elke fase
dient daarbij te worden afgesloten met een goede documentatie,
waarin de bereikte resultaten en de vervolgstappen worden
vastgelegd. Dit levert een doelmatige besturing van het
ontwikkel proces.
3.7.2
Beheersen door documenteren
Om de ontwikkeling beheersbaar te houden wordt er tijdens de
ontwikkeling en het onderhoud diverse soorten documentatie
geproduceerd. Tussen de verschillende soorten documentatie
bestaat verschil in gebruiksduur van de documentatie en
verschil in de doelstelling van de documentatie.
3.7.2.1
Systeem documentatie
Deze omvat de beschrijvingen die direct te maken hebben met
het geautomatiseerde Informatie Systeem. Het doel van de
systeem documentatie is het verschaffen van inzicht voor nietdirect betrokkenen en het verschaffen van een handleiding voor
het gebruik en het beheer van het Informatie Systeem.
Het gedeelte, voor de niet-direct betrokkenen, bestaat uit een
globale beschrijving.
Het handleiding gedeelte is veel uitgebreider en verschilt per
categorie van betrokkenen.
24
3.7.2.2
Ontwerp documentatie
Deze omvat alle inhoudelijke beschrijvingen van het Informatie
Systeem, zoals dat tijdens de ontwikkeling tot stand is
gekomen. Het is dus een ’databank’ van ontwerpalternatieven.
3.7.2.3
Project management documentatie
Deze omvat alle gegevens met betrekking tot het beheersen van
het project. Het doel van deze documentatie is het leveren van
zinvolle informatie aan het management van het project
(bijvoorbeeld projectleider of stuurgroep).
3.7.3
Beheersen door organiseren
Het bouwen van een Informatie Systeem gebeurt op een
projectmatige manier. Hierbij construeert men een project
organisatie als een samenwerkingsverband tussen personen uit
diverse afdelingen van de organisatie, eventueel aangevuld met
externe personen. De project organisatie bestaat uit
verschillende groepen.
Afbeelding 4:
De project organisatie
25
3.7.3.1
De beleidsgroep
De beleidsgroep geeft algemene richtlijnen voor de
ontwikkeling van alle informatie systemen en controleert de
naleving ervan. De groep bestaat uit het top management,
aangevuld met de voorzitters van de stuurgroepen.
3.7.3.2 De stuurgroep
De stuurgroep concretiseert de algemene richtlijnen in
specifieke doelen en taken voor een bepaald Informatie Systeem
en verzorgt de coördinatie van de onder haar groep
ressorterende projectgroepen. De stuurgroep bestaat uit de
managers van de afdelingen waarvoor het Informatie Systeem
bedoeld is, aangevuld met de projectleiders.
3.7.3.3 De projectgroep
De projectgroep zorgt voor het ontwerp, de bouw, de invoering
en de nazorg van het betreffende Informatie Systeem. De
projectgroep groep bestaat uit een projectleider, medewerkers
uit de organisatie, eventueel aangevuld met externe medewerkers (adviesbureaus, softwarehuizen e.d.).
3.7.3.4 Eisen aan de project organisatie
Om de projectorganisatie een kans van slagen te geven, moet er
aan verschillende voorwaarden worden voldaan.
Als eerste moet er een goede organisatie structuur zijn. Dit
houdt in, dat de organisatie moet beschikken over een goed
opgezette organisatie met duidelijke afspraken over taken,
verantwoordelijkheden en beslissingsbevoegdheden om de
verschillende partijen op een gecoördineerde manier te laten
samenwerken.
Verder moeten er goede procedures geformuleerd zijn. Deze zijn
nodig om aan te geven op welke wijze de tijdsbesteding van de
diverse medewerkers vastgesteld en bewaakt wordt, hoe
conflicten moeten worden opgelost en hoe er moet worden
gerapporteerd.
Vervolgens moet er over goed personeel worden beschikt. Er
zijn mensen nodig, die op niveau de verschillende disciplines
kunnen vertegenwoordigen. Als laatste moet het juiste
veranderingsklimaat binnen de organisatie aanwezig zijn. De
mensen binnen de organisatie moeten overtuigd zijn van de
noodzaak van de verandering en ze moeten vertrouwen hebben in
de mensen die de verandering doorvoeren.
26
3.8
Effectieve representatie voor IS ontwikkeling
Aan de taal, waarin de initiële invoer moet worden uitgedrukt,
kunnen de volgende sleutelvragen worden gesteld.
* Kan de gebruiker een betrouwbare specificatie leveren van
de vereisten in de gevraagde invoer taal?
* Kan de Informatie Systeem ontwerper de initiële vereisten
betrouwbaar interpreteren in termen van een formeel
representatie schema, gegeven door de Informatie Systeem
ontwikkelmethode?
Aan de formele ontwerp representaties, die worden gebruikt
tijdens het ontwerp proces, kunnen de volgende sleutelvragen
worden gesteld.
* Is de formele representatie precies genoeg om direct te
worden geïmplementeerd?
* Is de formele representatie begrijpbaar genoeg om
effectief gevalideerd te worden door de gebruiker?
Voor de representatie schema’s kunnen de volgende
alternatieven gesteld worden. Deze alternatieven worden hierna
besproken, waarna ze worden geverifieerd aan de hand van
bovenstaande sleutelvragen.
* Het relationele model.
* Verhalende specificaties.
* ER diagrammen.
* DFD’s.
* Toestandsovergang diagrammen.
* Wiskundige grammatica’s.
* Data structuur diagrammen.
3.8.1
Het relationele model
Het relationele model, wat gebruikt wordt om de informatie
vereisten te beschrijven in een op normalisatie gebaseerd
ontwikkel aanpak. Normalisatie vereist dat de initiële invoer
wordt uitgedrukt als een verzameling record typen (relatie
en/of entiteit typen), die samengesteld zijn uit velden en een
specificatie van wiskundige afhankelijkheden tussen de velden
onderling.
3.8.1.1
Doel van normalisatie
Het doel van normalisatie is, om het initiële tabel ontwerp om
te zetten in een aantal kleinere goede tabel ontwerpen. De
vraag die hierbij rijst is de volgende. Kan de gebruiker
betrouwbare informatie verschaffen over het applicatie domein,
als het in zo’n vorm uitgedrukt moet worden?
Het blijkt, dat als de gebruiker geen (geschikte) uitvoer
rapporten heeft, het lastig voor de gebruiker is om de
vereisten uit te drukken. Omdat de normalisatie vereist dat de
invoer uitgedrukt wordt in een computer georiënteerde taal, is
er geen formele invoer definitie. Hierdoor moet de gebruiker
dit doen zonder enige assistentie van de normalisatie ontwerp
procedure.
27
Verder gaat de normalisatie er vanuit, dat de initiële
’slechte’ tabellen significant en compleet zijn. Het grote
nadeel is, dat de initiële tabellen nergens worden
gevalideerd.
Normalisatie dient slechts als een ontwerp procedure in poging
de initiële tabellen te verbeteren. De normalisatie verwacht,
dat de afhankelijkheden tussen de tabellen worden
gedefinieerd. Er blijkt echter dat geen van de partijen in
staat zijn dit te doen. Het is namelijk zo dat de ontwerper de
vereiste applicatie kennis mist, de gebruiker niet over de
onderlinge verbanden beschikt in zijn natuurlijke taal. Verder
is het ook niet in zijn algemeenheid te stellen, dat het
afleidbaar is uit de door de gebruiker gegeven voorbeelden.
3.8.1.2
Eisen die aan de gebruiker worden gesteld
De eigenschappen van normalisatie zorgen ervoor, dat de
gebruiker de volgende afzonderlijke taken moet (kunnen)
uitvoeren: Het definiëren en valideren van tabel definities.
Dit houdt in, dat de gebruiker de vaardigheid bezit om de
representatie van de belangrijke feiten in het
toepassingsgebied als een verzameling relationele tabellen
weer te geven. Dit betekent, dat de gebruiker in staat is te
controleren dat deze verzameling tabellen de informatie
vereisten definieert. Verder houdt het in dat de gebruiker de
afhankelijkheden kan definiëren en valideren. Dit betekent
weer, dat de gebruiker de volgende vaardigheden bezit.
Het impliciet representeren van kennis van de semantiek van de
informatie in het toepassingsgebied als een verzameling
wiskundige afhankelijkheden tussen de kolommen van de
relationele tabellen en controleren dat deze afhankelijkheden
de informatie vereisten definieert. Verder is het zo dat dit
alles moet plaatsvinden voordat er aan de normalisatie
begonnen wordt. Tijdens de normalisatie is er geen enkele
validatie meer mogelijk. Een fout aan het begin werkt dus het
hele proces door. De kwaliteit van de normalisatie ligt dus in
de kwaliteit van het proces dat aan de normalisatie
voorafgaat.
3.8.1.3
Verificatie van de relationele strategie
Zetten we de bovenstaande eisen, die aan de gebruiker worden
gesteld af tegen de sleutel vragen, dan volgt hieruit het
volgende.
De gemiddelde gebruiker is niet goed genoeg getraind om een
betrouwbare specificatie te leveren en om deze specificatie te
valideren.
Indien er een betrouwbare initiële formele bewering is, dan
kan de ontwerper deze betrouwbaar interpreteren en dan is deze
bewering precies genoeg om deze direct te implementeren.
28
Bij deze representatie wordt de gebruiker buiten schot
gehouden, omdat hij er te weinig van begrijpt. Hierdoor wordt
de gebruiker pas vrij laat (tijdens de acceptatie procedure)
bij het project betrokken, waardoor hij weinig werkelijke
medezeggenschap en inbreng heeft.
3.8.2
Verhalende specificaties
Verhalende specificaties worden gebruikt om de informatie en
de functionele vereisten in vele Informatie Systeem ontwikkel
methoden te beschrijven. Het voordeel van deze representatie
is, dat de gebruiker alles in zijn eigen taal kan weergeven,
waardoor hij vanaf het begin bij het project betrokken wordt.
De problemen die zich bij deze representatie manifesteren
zijn, dat de verhalende beschrijving van de gebruiker van de
informatie vereisten een niet concrete beschrijving is en dat
de ontwerper de beschrijving moet interpreteren in een formele
specificatie taal.
3.8.2.1
Verificatie van de verhalende strategie
Zetten we dit af tegen de bovenstaande sleutel vragen, dan
volgt hieruit het volgende.
Het hangt van de vaardigheden van de gebruiker af, of de
gebruiker een betrouwbare specificatie kan leveren in de
gevraagde invoer taal. Het is voor de gemiddelde gebruiker
lastig om expliciet op het type niveau te redeneren.
De gemiddelde gebruiker beschikt niet over kennis om een
correcte interpretatie van de verhalende beschrijving te
geven.
De initiële representatie is niet formeel en kan dus niet
direct geïmplementeerd en gevalideerd worden. Deze
representatie zal eerst vertaald moeten worden in een formele
beschrijving.
3.8.3
Entiteit-Relatie diagrammen
Entiteit-Relatie diagrammen worden in veel Informatie Systeem
ontwikkelmethoden gebruikt om de informatie vereisten vast te
leggen. Mogelijke uitgangspunten voor een ontwikkel strategie
zijn, dat de gebruiker (zelf) het initiële ER diagram moet
produceren, of dat de gebruiker een initiële specificatie van
de inhoud van het diagram produceert, maar de ontwerper
converteert dit tot een ER diagram.
Het eerste uitgangspunt werkt zelden of nooit, want de
gebruiker beschikt niet over de vereiste kennis.
Het tweede uitgangspunt levert de volgende mogelijkheden op.
Ten eerste kan de gebruiker de initiële specificatie in een
verhalende specificatie maken. De nadelen hiervan zijn
hiervoor al besproken.
29
Ten tweede kan de gebruiker de inhoud van het diagram
specificeren, door de relevante entiteit types, attributen en
relaties te specificeren. Dit is de meest gebruikelijke
methode. In ieder geval is het initiële diagram compleet.
Verdere communicatie geschiedt door middel van het ER diagram,
dus de mogelijkheid van de gebruiker om het onderliggende ER
model te begrijpen is cruciaal, of hij het initiële diagram nu
gemaakt heeft of niet.
Om de initiële invoer te geven moet de gebruiker een abstracte
formele representatie geven van het toepassingsgebied, waarbij
impliciet ook ontwerp beslissingen horen.
Het is niet duidelijk welke feiten gemodelleerd moeten worden
als relaties en welke als attributen. Verder kan dit tijdens
het proces niet veranderen, wat instabiliteit met zich
meebrengt. Het is nog erger, dat het niet beschreven is,
wanneer de uiteindelijke classificatie bereikt is en het
migratie proces kan stoppen. De gebruiker moet een gekunsteld
onderscheid maken tussen entiteit typen, relaties en
attributen. Het bestaat niet in het toepassingsgebied en niet
in de dagelijkse taal van de gebruiker.
3.8.3.1
Verificatie van de ER strategie
Zetten we deze representatie methode af tegen de sleutel
vragen, dan volgt hieruit het volgende.
De gemiddelde gebruiker kan de ER specificaties niet volledig
begrijpen en kan dus geen betrouwbare specificatie leveren.
Hierdoor kan hij de representatie ook niet effectief
valideren.
De formele representatie is niet precies genoeg om direct
geïmplementeerd te worden, omdat de ER specificatie incompleet
is.
Indien er sprake is van een specificatie in het ER model, dan
kunnen de vereisten betrouwbaar geïnterpreteerd worden.
3.8.4
Data Flow Diagrammen
Data Flow diagrammen zijn bedoeld om op een betrouwbare manier
de gegevens stromen van het systeem weer te geven. Ze worden
gebruikt om de formele gebruikers vereisten van de processen
weer te geven. Om dit overzichtelijk te laten gebeuren wordt
het hele systeem in deelsystemen opgedeeld. De processen op
alle niveaus, behalve het laagste niveau, zijn abstracte
processen. De actuele processen die geïmplementeerd moeten
worden, zijn die op het laagste niveau.
30
3.8.4.1
Werkwijze
De gebruiker moet alle externe datastromen identificeren
tezamen met de relevante externe entiteiten. De analist kan nu
het initiële data-flow diagram tekenen, wat één proces bevat
(het hele systeem) en een aantal data stromen. De gebruiker
identificeert nu alle relevante subprocessen, wat resulteert
in het tweede niveau. Dit proces blijft zich herhalen totdat
het onderste niveau bereikt is.
3.8.4.2
Verificatie van de DFD strategie
Zetten we deze representatie af tegen de sleutel vragen, dan
volgt hieruit het volgende.
Het is voor de gemiddelde gebruiker lastig om abstract te
redeneren over de vereisten om ze vervolgens in een formele
taal weer te geven.
Indien de initiële vereisten gespecificeerd zijn, dan kan de
ontwerper deze betrouwbaar interpreteren.
De formele representatie is niet precies genoeg om direct
geïmplementeerd te worden. Er moet hier eerst een tussenstap
gemaakt worden. De processen zijn namelijk anoniem en moeten
derhalve eerst geïdentificeerd worden, voordat ze
geïmplementeerd kunnen worden.
De DFD strategie is een grafische representatie van een
abstracte specificatie. Het is voor de gebruiker lastig om
abstracte specificaties te valideren.
3.8.5
Toestandsovergang diagrammen
Toestandsovergang diagrammen worden gebruikt om tijd
afhankelijk gedrag te specificeren. Het diagram geeft de
grafische representatie van vier formele categorieën, namelijk
toestanden, overgangen tussen toestanden, condities
voorafgaande aan overgangen, en acties die nieuwe toestand tot
gevolg hebben. Het gedeelte van de gebruikers eisen moeten in
termen van deze categorieën gegeven worden.
3.8.5.1
Verificatie van de toestandsovergang strategie
Zetten we deze representatie af tegen de sleutel vragen, dan
volgt hieruit het volgende.
De gemiddelde gebruiker kan geen betrouwbare specificatie
leveren in de gevraagde taal. Hij moet hier namelijk alle
mogelijke toestanden en hun onderlinge overgangen, tezamen met
de condities en acties weergeven.
Indien de vereisten formeel weergegeven zijn, dan is de
interpretatie van de ontwerper triviaal.
31
De formele representatie is niet precies genoeg om
gedefinieerd te worden. De definitie van toestand is namelijk
niet implementeerbaar. Elke toestand van het systeem is te
vertalen naar een database toestand, maar deze liggen niet
vast.
De formele representatie is niet begrijpbaar genoeg om
effectief gevalideerd te worden. De gemiddelde gebruiker kan
namelijk niet valideren of een abstractie op de juiste manier
heeft plaatsgevonden.
3.8.6
Wiskundige grammatica’s
Er zijn verschillende soorten formele specificatie voor
Informatie Systeem ontwikkeling. Allereerst zijn er de
specificaties, die gebaseerd zijn op formele computer datageheugen concepten. Voorbeelden hiervan zijn normalisatie en
ER modellering.
Als tweede zijn er de formele specificaties, die gebaseerd
zijn op de wiskunde van de eindige toestandsmachines.
Voorbeeld hiervan is het toestandsovergang netwerk. Als derde
zijn er de formele specificaties, die afgeleid worden van
taalkundige structuur representaties. Een voorbeeld hiervan is
NIAM.
Als laatste zijn er de formele specificaties, die afgeleid
zijn van wiskundige logica of wiskundige grammatica’s. Dit is
een belangrijke klasse van formele specificaties.
De wiskundige grammatica’s zijn ongeschikt als taalkundige
beschrijving van de complexe grammaticale structuur van
natuurlijke talen. De grootste toepassing vindt dan ook plaats
in de specificaties van datastructuren en in het ontwerp van
parseer algoritmen voor compilers.
Verder wordt het gebruikt om de Data-Dictionary te definiëren.
De Data-Dictionary is een lijst van alle data elementen die
het systeem gebruikt, tezamen met de toegestane groeperingen
van deze elementen. De Data-Dictionary is bedoeld als basis
voor een algeheel begrip van de data elementen tussen
ontwerpers en gebruikers.
3.8.6.1
Verificatie van de wiskundige grammatica
Zetten we het gebruik van de wiskundige grammatica’s af tegen
de sleutelvragen, dan volgt hieruit het volgende.
De gemiddelde gebruiker mist de training om de vereisten in
een formele abstracte taal te specificeren en om de
representatie effectief te valideren.
Indien de formele eisen in het raamwerk zijn uitgedrukt, dan
kan de ontwerper ze betrouwbaar interpreteren.
Zelfs als de formele representatie precies genoeg is om als
basis te dienen voor de database specificatie, dan is het voor
de gemiddelde programmeur lastig om ze als zodanig te
gebruiken.
32
3.8.7
Data structuur diagrammen (Bachman Diagrammen)
Deze strategie is één van de oudste manieren om grafische
representaties te maken. Deze methode wordt nog steeds
veelvuldig gebruikt. Het blijkt echter zo te zijn, dat de data
structuur diagrammen onveilig incompleet zijn.
Elk record bestaat uit een aantal velden. Deze velden worden
niet getoond in het diagram en moeten dus tekstueel worden
vastgelegd.
3.8.7.1
Verificatie van de datastructuur diagrammen
Zetten we het gebruik van de datastructuur diagrammen af tegen
de sleutelvragen, dan volgt hieruit het volgende.
De gemiddelde gebruiker kan zijn vereisten niet betrouwbaar
vastleggen in een computer georiënteerd formalisme. Hij mist
ook de capaciteiten om de representatie effectief te
valideren.
Indien de vereisten betrouwbaar zijn vastgelegd, dan is het
voor de ontwerper triviaal om de specificaties op een juiste
manier te interpreteren.
De formele representatie is niet precies genoeg om direct te
worden geïmplementeerd.De mogelijkheden van de specificatie is
onveilig incompleet, dus er blijven teveel ’gaten’ over.
3.8.8
Voorbeelden uit het werk van de gebruiker
De gebruiker doet zijn werk
voorbeelden tegen. Hij kent
en verder zijn ze voldoende
een verzameling feiten, die
3.8.8.1
dagelijks, dus hij komt dagelijks
de betekenis van deze voorbeelden
aanwezig. De voorbeelden bevatten
de gebruiker wenst op te slaan.
Verificatie van de voorbeeld strategie
Zetten we het gebruik van de voorbeeld strategie af tegen de
sleutelvragen, dan volgt hieruit het volgende.
De gebruiker kan een betrouwbare specificatie leveren. Hij
hoeft er hier slechts voor te zorgen, dat een aantal
representatieve voorbeelden in zinnen worden omgezet.
De ontwerper kan de initiële vereisten betrouwbaar
interpreteren in termen van een formeel representatie schema.
De ontwerper kan namelijk, in samenwerking met de gebruiker,
elk element classificeren als entiteit type, label type enz om
tot een formele beschrijving te komen.
33
De formele representatie is precies genoeg om direct te worden
geïmplementeerd. Het resulterende conceptuele schema is een
exacte specificatie van alle typen die in het Informatie
Systeem moeten worden opgenomen, tezamen met de constraints
die bepalen wat voor acties er zijn toegestaan. Er is zelfs
een formeel algoritme, dat zo’n conceptueel schema omzet in
een relationeel database schema in de vijfde normaalvorm,
zonder tussenkomst van de gebruiker.
De formele representatie is begrijpbaar genoeg om effectief
gevalideerd te worden door de gebruiker. De gestructureerde
zinnen hebben een sterke overeenkomst met de alledaagse taal
van de gebruiker. Hij kan deze formele beschrijving dus goed
begrijpen.
3.8.9
Conclusie
Uit de bovenstaande figuur blijkt hoe de externe
representaties onderverdeeld zijn. De representaties in de
natuurlijke taal kunnen concreet (bijv. ’Verbaliserende
voorbeelden’) of abstract (bijv. ’Vertellende beschrijvingen’)
zijn. Uit de verificatie blijkt, dat hiervan alleen de
verbaliserende voorbeelden voldoen.
34
De formele representaties hebben een diepere hiërarchie,
waarbij er geen voorbeelden zijn van de concrete. Ditzelfde
geldt voor de complete grafische representaties.
Uit de verificatie blijkt, dat geen van de abstracte formele
representaties voldoet, omdat de gemiddelde gebruiker hiervoor
niet genoeg getraind is. Een deel van de representaties is
zelfs onveilig incompleet.
Is er sprake van een project, waarbij gebruikers zijn
betrokken, die deze formele representatie wel beheersen, dan
voldoen de representaties, die niet onveilig incompleet zijn.
3.9
IS ontwikkeling in evoluerende organisaties
De organisatie verandert vaak en snel, dus er is vraag naar
een doelmatige strategie om de door het Informatie Systeem
geleverde informatie te laten aansluiten op de informatie
behoefte. Een oplossing hiervoor is het verkorten of
veranderen van het levenscyclus proces.
De levensverwachting van een Informatie Systeem kan worden
vergroot door bij het ontwerp en ontwikkeling de produkten in
de levenscyclus geschikt te maken voor hergebruik. Produkten
die met een CASE-tools zijn ontwikkeld (bijvoorbeeld analyse
en/of ontwerp) kunnen als basis dienen voor het te ontwikkelen
Informatie Systeem. De traditionele Informatie Systeem
ontwikkel strategie kan worden vervangen door een meer
evolutionaire aanpak: De strategie van prototyping laten
doorwerken tijdens onderhoud. Er is dan geen essentieel
verschil meer tussen ontwikkeling en onderhoud. [FOP]
35
Afbeelding 6:
De prototype benadering
3.9.1
Afbeelding 7:
De evolutionaire aanpak
Case tools en Informatie Systeem-ontwikkeling
Case is de afkorting van Computer Aided Software Engineering.
Het is een Software systeem, dat ontwikkeld is om de ontwerper
te ondersteunen bij het ontwikkelen van software. Case tools
voor Informatie Systeem ontwikkeling zijn nauw verbonden met
de Informatie Systeem ontwikkel methoden. Het levert
automatische ondersteuning voor het gebruik van een methode.
De Case tool kan verschillende functies vervullen. Ten eerste
kan de Case tool automatisch uitvoerbare code genereren. Deze
code is van een formeel, hoog niveau. Vervolgens kan de Case
tool de definitie, opslag en modificatie van verschillende
formele grafische representaties (Data Flow, ER) ondersteunen.
Ook het automatische genereren van de bijbehorende ontwerp
documentatie van een opgeslagen formele specificatie hoort bij
de functies die de Case tool kan vervullen.
De volgende functie die de Case tool kan vervullen is de
analyse van de opgeslagen formele specificaties voor de
controle op syntactische fouten. Syntactische kruiscontrole
van de verschillende opgeslagen formele specificaties
(compatibiliteit) hoort hier ook bij.
36
Als laatste kan de Case tool ondersteuning geven bij het
genereren en het maken van een prototype van alternatieve
ontwerpen van een formele specificatie.
Er zijn twee soorten Case tools: De upper-case en de lowercase. De eerste geeft ondersteuning voor de processen van de
vereiste specificatie, validatie en ontwerp. Het tweede geeft
ondersteuning voor de processen van software ontwikkeling,
implementatie en verificatie, met betrekking tot de
specificaties.
3.9.2
Architectuur voor een IS
Uit de bestaande Informatie Systemen kunnen we de architectuur
afleiden, wat een basismodel van een geautomatiseerd
Informatie Systeem levert. Er is het conceptueel schema. Dit
bevat de formele specificatie van de feiten die opgeslagen
kunnen worden in Database.
Daarnaast is er de informatie processor. Dit is een actieve
processor die berichten accepteert van de omgeving
(bijvoorbeeld van gebruikers en eventueel andere Informatie
Systemen), deze berichten controleert volgens het conceptuele
schema, goedgekeurde boodschappen doorvoert in de database en
berichten teruggeeft aan de gebruiker. De database is de
opslagplaats van alle feiten die in Informatie Systeem zijn
opgeslagen.
De huidige inhoud van database moet op elk tijdstip voldoen
aan de eisen van het conceptuele schema.
Als laatste is er de program base. Deze bevat programma’s
(proces definities), die uitgevoerd kunnen worden door de
informatie processor.
De Program Base is onder te verdelen in de Event Base en de
Proces Description Base. De Event Base bevat iedere
gebeurtenis, die de oorzaak van het uitvoeren van een proces
kan veroorzaken. De Proces Description Base bevat de
beschrijving van alle processen die door een gebeurtenis
getriggered kunnen worden. Basis operaties hierbij zijn add,
modify, delete en retrieve. [Nijssen]
37
Afbeelding 8:
Het traditionele IS
3.9.3
Architectuur van het EIS
Zoals uit het voorafgaande blijkt, bestaat een organisatie
systeem uit een verzameling onderling verbonden actoren,
activiteiten, toestanden en tijdstippen. Actoren voeren acties
uit, wat resulteert in een toestandsverandering op een bepaald
tijdstip. Een informatie realisatie systeem kan gedefinieerd
worden als een geformaliseerd subsysteem van een organisatie
systeem.
De Informatie Systemen die hier van belang zijn, zijn beperkt
tot die Informatie Systemen, waar de actor die de informatie
processen uitvoert is geautomatiseerd. Deze actor, de
informatie processor, kan uit verschillende sub-processoren
bestaan.
38
Afbeelding 9:
Architectuur van het EIS
De informatie processor accepteert invoer berichten
(verzoeken), die toestandsveranderingen tot gevolg kunnen
hebben in de Universe of Discourse, en de informatie processor
aanzet tot het uitvoeren van activiteiten. Als resultaat van
deze activiteiten kan de informatie processor uitvoer
berichten produceren (antwoorden).
De beschrijving van dat deel van het Informatie Systeem, dat
geconsulteerd wordt door de informatie processor, heet het
processing model. De verzoeken van de gebruiker worden hier
niet bijgerekend.
Het processing model wordt onderverdeeld in een
applicatiemodel en een metamodel. Het applicatiemodel
beschrijft een specifiek Universe of Discourse, terwijl het
metamodel de taal (techniek) beschrijft, waarin het
applicatiemodel is gespecificeerd en waarin het
applicatiemodel gemanipuleerd kan worden. Het metamodel bevat
de beschrijving van een classificatie van de domein elementen,
algemene regels over deze elementen, hun gedrag en hoe ze
kunnen worden behandeld.
39
Afbeelding 10: Structuur
van het applicatie model
Afbeelding 11:
Model eigenschappen
Het metamodel is applicatie onafhankelijk en tijd-invariant.
Het applicatie model echter is applicatie afhankelijk en kan
tijd-variant zijn. Als resultaat hiervan wordt het metamodel
in een Informatie Systeem eenmalig geïmplementeerd, terwijl
het applicatiemodel opgebouwd en onderhouden moet worden voor
elke nieuwe applicatie.
Het opbouwen en onderhouden van het applicatiemodel wordt door
de informatie processor gedaan, die handelt of reageert op
gebeurtenissen in de Universe of Discourse door middel van het
raadplegen van het metamodel en van het applicatiemodel. Het
applicatie model is dus, in tegenstelling tot het metamodel,
niet alleen input, maar ook uitvoer van de activiteiten van de
informatie processor.
Buiten het bijwerken van het applicatiemodel kan ook
informatie worden verkregen uit het applicatiemodel. De taal
waarin berichten geformuleerd worden, worden afgeleid uit het
metamodel. [FOP]
40
Het applicatiemodel kan worden onderverdeeld in een
wereldmodel en een actiemodel.
Het wereldmodel modelleert de interactie tussen het Informatie
Systeem en de omgeving (Universe of Discourse). Het kan worden
beschreven in modelleringstechnieken, zoals ER, NIAM of PSM.
Het actiemodel specificeert de regels die de acties van de
informatie processor bepaalt. Het actiemodel kan weer worden
onderverdeeld in een activiteiten model en een gedragsmodel.
Het activiteiten model specificeert de activiteiten en het
gedragsmodel beschrijft de relaties tussen het activiteiten
model en het wereldmodel.
Met andere woorden: Het gedragsmodel beschrijft de ’wanneer’
activiteiten, onder welke condities, en welke activiteiten
door de information processor moeten worden uitgevoerd,
terwijl het activiteiten model specificeert ’hoe’ deze
activiteiten moeten worden uitgevoerd.
Modellerings technieken voor het activiteiten model zijn DFDdiagrammen, activiteiten schema’s in ISAC. Modellerings
technieken voor het gedragsmodel zijn petrinetten en When-IfThen regels in Remora.
41
3.9.4
Verschil tussen IS en EIS
Op basis van deze architectuur kan het verschil tussen het
traditionele Informatie Systeem en het Evolutionair Informatie
Systeem meer specifiek worden beschreven. In een traditioneel
Informatie Systeem, waar het schema (type) versus instantie
onderscheid is aangebracht in het applicatie model, kunnen
alleen de instanties bijgewerkt worden. Dus noch de schema
specificaties, noch de activiteiten en gedrag specificaties,
die verborgen zijn in de programma procedures, kunnen
bijgewerkt worden in het traditionele Informatie Systeem. De
intentie van het Evolutionair Informatie Systeem daarentegen
is dat het complete applicatie model aanpasbaar is. Gegeven
het metamodel van een Evolutionair Informatie Systeem kan een
software omgeving worden ontwikkeld, dat tijd-invariant en
onafhankelijk van elk Universe of Discourse is. Zo’n omgeving
heet een Evolutionair Informatie Systeem shell. Wanneer een
Evolutionair Informatie Systeem moet worden ontwikkeld voor
een specifiek Universe of Discourse wordt een applicatie
model, dat dit domein beschrijft, ontwikkeld en onderhouden
conform de taal die is gedefinieerd in het (metamodel van de)
Evolutionair Informatie Systeem shell.
De Evolutionair Informatie Systeem shell moet dus worden
ontworpen zodanig dat het onafhankelijk is van elke software
omgeving en dus onafhankelijk van elke Database management
systeem en/of operating system.
Afbeelding 12:
42
EIS-shell
4
Het proces
4.1
in detail
Inleiding
In dit hoofdstuk worden de verschillende onderdelen uit
hoofdstuk 3 gemodelleerd, aan de hand van de beschrijvingen
van het vorige hoofdstuk. Hierbij wordt het evolutionaire
aspect en de case tools buiten beschouwing gelaten. Het
evolutionaire aspect wordt buiten beschouwing gelaten, omdat
het evolutionaire aspect onafhankelijk is van de te kiezen
ontwikkelmethode. De case tools, die de diverse
ontwikkelmethoden ondersteunen, worden buiten beschouwing
gelaten, omdat eerst bepaald moet worden welke methoden
voldoen. Daarna kan er gebruik gemaakt worden van een bepaalde
case tool, als deze beschikbaar is.
4.2
Gemodelleerde beschrijving
De verschillende onderdelen uit het vorige hoofdstuk zijn
formeel uit te drukken aan de hand van NIAM schema’s. Het doel
van de NIAM schema’s is het overzichtelijk weergeven van de
onderlinge verbanden. De NIAM schema’s zijn vervolgens weer
uit te drukken in zinnen, in plaats van de veelal gebruikte
tabellen. Aan de hand van deze zinnen kan er een verband
gelegd worden tussen de formele taal en de experttaal. Verder
kunnen er uit deze zinnen eigenschappen worden afgeleid in de
vorm van axioma’s, waar weer lemma’s en strategieën uit kunnen
volgen.
In dit hoofdstuk worden, bij de beschrijving in de formele
taal en bij de bewijsvoering de volgende notaties gebruikt:
Æ
=
«»
∩
φ
§
E
ε
≡
==>
or
and
¬
[Ai]
[Li]
Voor alle
Is gelijk aan
Is ongelijk aan
Doorsnede
Lege verzameling
Paragraaf
Er is een
Is element van
Per definitie =
Implicatie
Logische of
Logische en
Logische not
Axioma i
Lemma i
De ’i’ bij de axioma’s en de lemma’s staan voor het nummer van
het axioma resp. lemma in de paragraaf.
43
4.2.1
Strategieën en hun methoden
1.
2.
3.
4.
5.
6.
7.
8.
heeft_grotere_mate_van_
onzekerheid_dan
heeft_kleinere_mate_van_
onzekerheid_dan
wordt_gebruikt_door
maakt_gebruik_van
is_oberstrategie
is_referentie_strategie
is_evolutionaire_
strategie
is_ontwikkel_strategie
Het bepalen van de informatie behoefte is ingewikkeld.
Derhalve zijn er in de loop der jaren verschillende
strategieën ontwikkeld om de informatie behoefte te bepalen,
die onderling verschillen in de mate van onzekerheid. Aan de
hand hiervan kan een rangschikking gemaakt worden tussen de
verschillende strategieën. In de bovenstaande figuur wordt het
verschil in onzekerheid tussen de verschillende strategieën
weergegeven door de binaire relatie <1,2> (= heeft_grotere_
mate_van_onzekerheid, heeft_kleinere_mate_van_onzekerheid)
over Strategie. Voor deze relatie kunnen diverse eigenschappen
worden afgeleid, die in de volgende paragrafen worden
besproken.
De verschillende strategieën sluiten elkaar onderling uit.
Deze eigenschap wordt weergegeven door het volgende axioma:
[A1] Oberstrategie ∩ Referentie Strategie ∩ Ontwikkel
Strategie ∩ Evolutie Strategie = φ.
44
4.2.1.1
De groter_dan relatie
De verschillende strategieën zijn met elkaar te vergelijken op
grond van de mate van onzekerheid van de desbetreffende
strategieën.
De eerste eigenschap van de groter_dan relatie is, dat een
strategie niet idempotief is: Een strategie kan niet met
zichzelf vergeleken worden op grond deze relatie. Deze
eigenschap wordt tot uitdrukking gebracht in het volgende
axioma:
[A2] ¬ (Strategie X heeft_een_grotere_mate_van_onzekerheid_dan
Strategie X).
Vervolgens moet ook de transitieve eigenschap gelden: Als de
groter_dan relatie tussen de strategieën X en Y en tussen de
strategieën Y en Z geldt, dan geldt deze relatie ook tussen de
strategieën X en Z. Deze eigenschap wordt tot uitdrukking
gebracht in het volgende axioma:
[A3] Strategie X heeft_een_grotere_mate_van_onzekerheid_dan
Strategie Y and Strategie Y heeft_een_grotere_mate_van_
onzekerheid_dan Strategie Z ==>
Strategie X heeft_een_grotere_mate_van_onzekerheid_dan
Strategie Z.
Verder kan er geen sprake zijn van de reflexieve eigenschap:
Als de groter_dan relatie geldt tussen de strategieën X en Y,
dan kan deze relatie niet gelden tussen de strategieën Y en X.
Er is dus sprake van strikt groter. Deze eigenschap komt tot
uitdrukking in het volgende axioma:
[A4] ¬ (Strategie X heeft_een_grotere_mate_van_onzekerheid_dan
Strategie Y and Strategie Y heeft_een_grotere_mate_van_
onzekerheid_dan Strategie X).
Als laatste moet bij de groter-dan relatie gelden, dat alle
van elkaar verschillende strategieën met elkaar vergeleken
moeten kunnen worden op grond van deze relatie. Deze
eigenschap wordt door het volgende axioma weergegeven:
[A5] Æ X,Y : Strategie X «» Strategie Y ==>
Strategie X heeft_een_grotere_mate_van_onzekerheid_dan
Strategie Y or Strategie Y heeft_een_grotere_mate_van_
onzekerheid_dan Strategie X.
45
4.2.1.2
De kleiner_dan relatie
Er bestaat een verband tussen de kleiner_dan en de groter_dan
relatie: Ze zijn elkaars inverse. Deze eigenschap wordt door
het volgende axioma weergegeven:
[A6] Strategie X heeft_een_grotere_mate_van_onzekerheid_dan
Strategie Y <==>
Strategie Y heeft_een_kleinere_mate_van_
onzekerheid_dan Strategie X.
Analoog aan de beschreven eigenschappen voor de groter_dan
relatie kunnen eigenschappen beschreven worden voor de
kleiner_dan relatie.
Allereerst moet er gelden dat de kleiner_dan relatie niet
idempotief is. Deze eigenschap wordt door het volgende lemma
weergegeven:
[L1] ¬ (Strategie X heeft_een_kleinere_mate_van_onzekerheid_
dan Strategie X)
Bewijs:
Stel Strategie X heeft_een_kleinere_mate_van_onzekerheid_
dan Strategie X, dan volgt uit axioma [A6]:
Strategie X heeft_een_grotere_mate_van_onzekerheid_dan
Strategie X. Dit is echter in tegenspraak met axioma [A2],
dus er geldt: ¬ (Strategie X heeft_een_kleinere_mate_van_
onzekerheid_dan Strategie X).
Vervolgens moet er gelden, dat de kleiner_dan relatie
transitief is. Deze eigenschap wordt door het volgende lemma
weergegeven:
[L2] Strategie X heeft_een_kleinere_mate_van_onzekerheid_dan
Strategie Y and Strategie Y heeft_een_kleinere_mate_van_
onzekerheid_dan Strategie Z ==>
Strategie X heeft_een_kleinere_mate_van_onzekerheid_dan
Strategie Z.
Bewijs:
Stel Strategie X heeft_een_kleinere_mate_van_onzekerheid_
dan Strategie Y and Strategie Y heeft_een_kleinere_mate_
van_onzekerheid_dan Strategie Z, dan volgt uit axioma [A6]:
Strategie Z heeft_een_grotere_mate_van_onzekerheid_dan
Strategie Y and Strategie Y heeft_een_grotere_mate_van_
onzekerheid_dan Strategie X, dan volgt uit axioma [A3]:
Strategie Z heeft_een_grotere_mate_van_onzekerheid_dan
Strategie X.
Vervolgens volgt uit axioma [A6]:
Strategie X heeft_een_kleinere_mate_van_onzekerheid_dan
Strategie Z.
46
Vervolgens moet de eigenschap gelden, dat de kleiner_dan
relatie niet reflexief is. Deze eigenschap wordt tot
uitdrukking gebracht in het volgende lemma:
[L3] ¬ (Strategie X heeft_een_kleinere_mate_van_onzekerheid_
dan Strategie Y and Strategie Y heeft_een_kleinere_
mate_van_onzekerheid_dan Strategie X).
Bewijs:
Stel Strategie X heeft_een_kleinere_mate_van_onzekerheid_
dan Strategie Y and Strategie Y heeft_een_kleinere_
mate_van_onzekerheid_dan Strategie X, dan volgt uit
axioma [A6]:
Strategie Y heeft_een_grotere_mate_van_onzekerheid_dan
Strategie X and Strategie X heeft_een_grotere_mate_van_
onzekerheid_dan Strategie Y.
Dit is echter in tegenspraak met axioma [A4], dus
¬ (Strategie X heeft_een_kleinere_mate_van_
onzekerheid_dan Strategie Y and Strategie Y
heeft_een_kleinere_mate_van_onzekerheid_dan
Strategie X).
Als laatste moet er gelden, dat alle van elkaar verschillende
strategieën met elkaar vergeleken moeten kunnen worden op
grond van de kleiner_dan relatie. Deze eigenschap wordt door
het volgende lemma weergegeven:
[L4] Æ X,Y : Strategie X «» Strategie Y ==>
Strategie X heeft_een_kleinere_mate_van_onzekerheid_dan
Strategie Y or Strategie Y heeft_een_kleinere_mate_van_
onzekerheid_dan Strategie X.
Bewijs:
Stel Strategie X «» Strategie Y, dan volgt uit axioma [A5]:
Strategie X heeft_een_grotere_mate_van_onzekerheid_dan
Strategie Y or Strategie Y heeft_een_grotere_mate_van_
onzekerheid_dan Strategie X.
Wordt axioma [A6] hierop toegepast, dan volgt hieruit:
Strategie Y heeft_een_kleinere_mate_van_onzekerheid_dan
Strategie X or Strategie X heeft_een_kleinere_mate_van_
onzekerheid_dan Strategie Y.
47
4.2.1.3
Ordening tussen de strategieën
Iedere strategie maakt gebruik van bepaalde methoden om de
informatie behoefte te bepalen. In de figuur aan het begin van
deze paragraaf komt dit tot uiting in de relatie <3,4> (=
wordt_gebruikt_door, maakt_gebruik_van) tussen Methode en
Strategie.
Aan de hand van de hiervoor beschreven eigenschappen kan er
een ordening in de strategieën worden gegeven met betrekking
tot de mate van onzekerheid. Al deze strategieën zijn
onafhankelijk van de gekozen Informatie Systeem
ontwikkelmethode. De keuze is echter wel afhankelijk van de
organisatie waarvoor het Informatie Systeem bedoeld is.
Zoals in hoofdstuk 3 al beschreven is, is de ordening in de
mate van onzekerheid van de diverse strategieën afhankelijk
van de structureerbaarheid van de problemen, van het kennis-en
ervaringsniveau van de gebruiker en de ontwerper. Deze
afhankelijkheid levert het volgende diagram.
48
Om te bepalen welke strategie gekozen dient te worden om de
informatie behoefte te bepalen, moeten de strategieën worden
doorlopen, totdat er een strategie wordt gevonden die voldoet,
en wel door te beginnen met de strategie met kleinste mate van
onzekerheid.
Om te bepalen of een strategie voldoet dienen alle betrokken
factoren te worden doorlopen. Met behulp van de axioma’s A2
t/m A6 is de strategie met de minimale mate van onzekerheid te
bepalen.
Laat
b ≡ Probleem te structureren
S ≡ Strategie met onzekerheid =
min(onzekerheid van de strategieën)
if Automatiseerders voldoende deskundig
and Gebruikers voldoende deskundig
and b
then Hanteer S
Een strategie om te bepalen of de gebruiker en de ontwerper
voldoende deskundig zijn wordt in § 4.2.4 behandeld in
samenhang met de te hanteren representatie technieken voor
informatie systeem ontwikkeling.
49
4.2.2
De rol van formele representatie
1.
2.
3.
4.
5.
6.
7.
8.
9.
is_referentie_document
bevat
is_bevat_in
levert
wordt_geleverd_door
begrijpt
wordt_begrepen_door
verband_wordt_aangegeven
_door
geeft_verband_aan_met
Formele representaties spelen een dubbele rol in het
ontwikkelproces, namelijk die van referentie document en die
van een tussenliggende representatie. Voor de formele
representaties geldt dat het of een referentie document is of
een tussenliggende representatie is, dus niet beide. Deze
eigenschap wordt door de volgende axioma’s weergegeven:
[A1] Referentie Document ∩ Tussenliggende Representatie = φ.
[A2] Referentie Document or Tussenliggende Representatie =
Formele Representatie.
In beide gevallen bevat de formele representatie de eisen van
de gebruiker. Dit komt in het bovenstaande schema tot uiting
in de relatie <2,3> (= <bevat, is_bevat_in>) tussen Formele
Representatie en Eisen. Hierbij worden de eisen worden gegeven
door de gebruiker. Dit blijkt uit de relatie <4,5> (= <levert,
wordt_geleverd_door>) tussen Gebruiker en Eisen. De gebruiker
is in staat om elke formele representatie te valideren. Dit
wordt gegeven door de relatie <6,7> (= <begrijpt, wordt_
begrepen_door>) tussen Gebruiker en Formele Representatie.
Vervolgens wordt het verband aangegeven tussen de formele en
de niet-formele representatie. Dit komt in het schema tot
uiting in de relatie <8,9> (= <verband_wordt_aangegeven_door,
geeft_verband_aan_met>) tussen Informele Probleem Specificatie
en Formele Representatie.
50
De formele specificatie dient een voor de gebruiker duidelijk
verband aan te geven met de informele probleem specificatie.
Derhalve moet aan de volgende eigenschap worden voldaan: De
formele representatie geeft een voor de gebruiker duidelijke
specificatie. Deze eigenschap wordt door het volgende axioma
weergegeven:
[A3] Formele Representatie geeft_verband_aan_met Informele
Probleem Specificatie.
Als laatste bestaat er een relatie tussen de initiële nietformele representatie en de gebruiker. Dit komt in het schema
tot uiting in de relatie <2,3> (= <bevat, is_bevat_in >)
tussen Informele Probleem Specificatie en Eisen. Deze
eigenschap wordt door het volgende axioma weergegeven:
[A4] Informele Probleem Specificatie bevat Eisen.
De formele representatie bevat natuurlijk ook de eisen van de
gebruiker. Deze eigenschap wordt door het volgende lemma
weergegeven:
[L1] Formele Representatie bevat Eisen.
Bewijs:
Uit de axioma’s [A3] en [A4] volgt:
Formele Representatie geeft_verband_aan_met Informele
Probleem Specificatie bevat Eisen.
Dus: Formele Representatie bevat Eisen.
Definitie:
Formele representatie ≡ Verzameling formele regels
Er kan nu een strategie worden opgesteld aan de hand waarvan
er kan worden bepaald of het validatie proces naar behoren kan
worden uitgevoerd.
Laat FR = Formele Representatie
= {FR1, FR2, ..., FRn}
waarbij FRi = formele regel.
if
Gebruiker begrijpt FR
then Gebruiker kan FRi valideren
else Probleem: De representatie techniek voldoet niet.
Hierbij houdt het begrip ’Gebruiker begrijpt FR’ in, dat de
gebruiker de formele representatie voldoende beheerst, waar
FRi deel van uit maakt.
Om het probleem op te lossen kan er gekozen worden om de
gebruiker om of bij te scholen, of om een andere representatie
techniek te kiezen. Voordat er besloten tot om- of
bijscholing, dient er te worden bepaald of deze scholing
haalbaar is.
Een strategie om te bepalen of de gebruiker in staat geacht
moet worden, om de formele representatie te begrijpen en te
valideren wordt in § 4.2.4 behandeld in samenhang met de te
hanteren representatie techniek voor informatie systeem
ontwikkeling.
51
4.2.3
De rol van grafische representaties
1.
2.
3.
4.
5.
6.
7.
8.
wordt_weergegeven_door
geeft_weer
wordt_uitgesloten_door
sluit_uit
is_gewenste_toestand
is_tekstuele_
representatie
is_complete_
representatie
is_veilige_representatie
Representaties kunnen onderverdeeld worden in grafische en
tekstuele representaties. Voor de grafische representaties
geldt, dat zij niet tekstueel zijn. Deze eigenschap wordt door
de volgende axioma’s weergegeven:
[A1] Grafisch ∩ Tekstueel = φ.
[A2] Grafisch or Tekstueel = Representatie.
De tekstuele representaties worden hier verder buiten
beschouwing gelaten. De grafische representaties kunnen weer
onderverdeeld worden in complete en incomplete representaties.
Hier geldt, dat de grafische representaties niet zowel
compleet als incompleet kunnen zijn. Deze eigenschap wordt
door de volgende axioma’s weergegeven:
[A3] Incompleet ∩ Compleet = φ.
[A4] Incompleet or Compleet = Grafisch.
52
Het grote voordeel van grafische representaties is, dat deze
veel informatie overzichtelijk kunnen weergeven. Er geldt
hier, dat één plaatje meer zegt dan duizend woorden. Het
blijkt echter zo te zijn, dat geen enkele overzichtelijke
grafische representatie compleet is.
De incomplete grafische representaties zijn weer onder te
verdelen in veilige en onveilige representaties. Ook hier
geldt, dat de incomplete representaties niet zowel veilig als
onveilig kunnen zijn. Deze eigenschap wordt door de volgende
axioma’s weergegeven:
[A5] Veilig ∩ Onveilig = φ.
[A6] Veilig or Onveilig = Incompleet.
Beide soorten incomplete representaties geven alle gewenste
toestanden weer, maar niet elke beperking op de populatie kan
worden weergegeven. Deze eigenschap wordt in het bovenstaande
schema weergegeven door de relatie <1,2> (= <wordt_
weergegeven_door, geeft_weer >) tussen Toestand en Incomplete
Representatie. Deze eigenschap wordt door het volgende axioma
weergegeven:
[A7] Incomplete Representatie geeft_weer Toestand.
De toestanden kunnen worden onderverdeeld in gewenste en
ongewenste toestanden. Ook hier geldt, dat een toestand niet
zowel gewenst als ongewenst kan zijn. Deze eigenschap wordt
door de volgende axioma’s weergegeven:
[A8] Gewenst ∩ Ongewenst = φ.
[A9] Gewenst or Ongewenst = Toestand.
De veilige representaties sluiten, in tegenstelling tot de
onveilige representaties, alle ongewenste toestanden uit. Deze
uitsluiting wordt in het bovenstaande schema weergegeven door
de relatie <3,4> (= <wordt_uitgesloten_door, sluit_uit >)
tussen Toestand en Incomplete Representatie. Deze eigenschap
wordt door het volgende axioma weergegeven:
[A10]
X is_veilige_representatie and ¬ (T is_gewenste_
toestand) ==> X sluit_uit T.
De onveilige representaties sluiten niet alle ongewenste
toestanden uit. Als een incomplete representatie (veilig of
onveilig) een toestand uitsluit, dan is dit een ongewenste
toestand. Deze eigenschap wordt weergegeven door het volgende
axioma:
[A11]
¬ (X is_complete_representatie) and X sluit_uit T ==>
¬ (T is_gewenste_toestand).
53
Voor de toestanden geldt verder dat deze niet zowel
uitgesloten als weergegeven kunnen worden. Deze eigenschap
wordt door het volgende axioma weergegeven:
[A12]
¬ (E Incomplete Representatie R [R sluit_uit Toestand T
and R geeft_weer Toestand T] ).
Laat OT = Verzameling ongewenste toestanden
= {OT1, OT2, ..., OTn}
R = Representatie
Voor de verzameling ongewenste toestanden moet gelden, dat een
representatie deze verzameling uitsluit dan en slechts dan als
de representatie alle elementen van deze verzameling
afzonderlijk uitsluit. Deze eigenschap wordt door het volgende
axioma weergegeven:
[A13]
R sluit_uit OT <==>
R sluit_uit OT1 and R sluit_uit
OT2 and ... and R sluit_uit OTn.
Er kan nu een strategie opgesteld worden om te bepalen of een
representatie veilig of onveilig is:
if R sluit_uit OT
(1) then R is_veilige_representatie
(2) else ¬ (R is_veilige_representatie)
Bewijs:
(1) Stel R sluit_uit OT T, dan volgt uit axioma [A10]:
R is_veilige_representatie and
¬ (T is_gewenste_toestand)
Dus: R is_veilige_representatie
(2)
Stel ¬ (R sluit_uit OT), dan volgt uit axioma [A13]:
E T ε OT: ¬ (R sluit_uit T)
Stel vervolgens R is_veilige_representatie, dan volgt uit
axioma [A10]: R sluit_uit T.
Dus er geldt: R sluit_uit T and ¬ (R sluit_uit T).
Dit is in tegenspraak met elkaar, dus er geldt:
¬ (R is_veilige_representatie).
4.2.3.1
Conclusie
Door de overzichtelijkheid van de grafische representaties is
het aan te raden deze toch te gebruiken, ook al kunnen deze
niet alles uitdrukken. Een minimale eis die hierbij gesteld
moet worden is, dat alle ongewenste toestanden uitgesloten
moeten kunnen worden. Dit heeft tot gevolg, dat de onveilige
grafische representaties niet voldoen, dus dat alleen de
veilige representaties voldoen. De incompleetheid van de
grafische representaties kan worden opgevangen door het
uitbreiden van de grafische representaties met tekstuele
aanvullingen.
54
4.2.4
Representatie technieken voor IS ontwikkeling
1. ondersteunt_betrouwbaar
2. wordt_betrouwbaar_
ondersteund
3. is_specificatie_van_
gebruiker
4. is_implemeteerbare_
representatie
5. is_interpretatie_
ontwerper
6. is_wiskundige_grammatica
_strategie
7. is_datastructuur_
strategie
8. is_voorbeeld_strategie
9. is_verhalende_strategie
10. is_toestandsovergang_
strategie
11. is_relationeel_model_
strategie
12. is_ER_strategie
13. is_valideerbare_
expressie
4.2.4.1
Eigenschappen
Van de betrokkenen bij automatiseringsprojecten mag in alle
redelijkheid worden verwacht, dat zij een bepaald basis niveau
hebben om hun dagelijkse taak naar behoren uit kunnen voeren.
Definitie:
Specificatie van de gebruiker ≡
De gebruiker beheerst de techniek naar behoren om zijn
eisen te kunnen specificeren.
Implementeerbaarheid van de representatie ≡
De formele representatie is precies genoeg om direct
geïmplementeerd te worden, zonder tussenkomst van de
gebruiker.
Valideerbaarheid van de representatie ≡
De representatie is begrijpbaar genoeg om door de
gebruiker te kunnen worden gevalideerd.
Interpretatie van de ontwerper ≡
De ontwerper kan de initiële vereisten van de gebruiker
betrouwbaar interpreteren.
55
4.2.4.2
Verband eigenschappen - representatie
Het verband tussen de verschillende eigenschappen en de
representatie technieken wordt gegeven door de relatie <1,2>
(= <ondersteunt_betrouwbaar, wordt_betrouwbaar_ondersteund >)
tussen Representatie Techniek en Eigenschap, waarbij elke
representatie techniek minstens één eigenschap ondersteunt.
Deze eigenschap wordt door het volgende axioma weergegeven:
[A1] E E [ Representatie Techniek RT ondersteunt_betrouwbaar
Eigenschap E ].
Uit het vorige hoofdstuk valt af te leiden bij welke
representatie techniek aan welke eigenschap en aan welke
eigenschap niet wordt voldaan. Dit wordt in de volgende tabel
weergegeven.
Repres.
Techniek
Specif.
Gebruiker
Rel. model
Verhalend
ER
DFD
Toest. overg.
Wisk. gramm.
Data struct.
Voorb. strat.
Niet
Niet
Niet
Niet
Niet
Niet
Niet
Wel
Implement.
Represent.
Direct
Indirect
Niet
Indirect
Indirect
Niet
Niet
Direct
Valideerb.
Represent.
Niet
Niet
Niet
Niet
Niet
Niet
Niet
Wel
Interpr.
Ontwerper
Wel
Niet
Wel
Wel
Wel
Wel
Wel
Wel
Uit deze tabel kunnen verschillende eigenschappen worden
afgeleid. Aan de eigenschap specificatie van de gebruiker
wordt alleen voldaan bij de verbaliserende voorbeelden. Deze
eigenschap wordt door het volgende axioma beschreven:
[A2] Representatie Techniek RT ondersteunt_betrouwbaar E and
E is_specificatie_gebruiker ==>
RT = Verbaliserende Voorbeelden.
Aan de eigenschap implementeerbaarheid van de representatie
wordt voldaan bij de verbaliserende voorbeelden en het
relationeel model. Deze eigenschap wordt door het volgende
axioma weergegeven:
[A3] Representatie Techniek RT ondersteunt_betrouwbaar E and
E is_implementeerbare_representatie ==>
RT = Verbaliserende Voorbeelden OR
RT = Relationeel Model.
56
Aan de eigenschap valideerbaarheid van de representatie wordt
alleen voldaan bij de verbaliserende voorbeelden. Deze
eigenschap wordt door het volgende axioma weergegeven:
[A4] Representatie Techniek RT ondersteunt_betrouwbaar E and
E is_valideerbare_representatie ==>
RT = Verbaliserende Voorbeelden.
Aan de eigenschap interpretatie van de ontwerper wordt alleen
niet voldaan bij de verhalende strategie. Deze eigenschap
wordt door het volgende axioma weergegeven:
[A5] Representatie Techniek RT ondersteunt_betrouwbaar E and
E is_interpretatie_ontwerper ==>
RT ε {Relationeel Model, DFD, ER, Toestandsovergangen,
Wiskundige Grammatica’s, Datastructuren, Verbaliserende
Voorbeelden}.
Een representatie techniek voldoet dan en slechts dan als aan
alle beschreven eigenschappen (axioma’s A2 t/m A5) wordt
voldaan.
Definitie:
Representatie Techniek RT voldoet <==>
A2 and A3 and A4 and A5.
Uit de bovenstaande axioma’s kan geconcludeerd worden, dat bij
het gestelde basisniveau van de betrokkenen slechts de
representatie techniek ’Verbaliserende Voorbeelden’ voldoet.
Deze eigenschap wordt door het volgende axioma weergegeven:
[L1] RT voldoet ==> RT = Verbaliserende Voorbeelden.
Bewijs:
Stel RT voldoet, dus E bevat zeker de eigenschap
is_specificatie_van_gebruiker, dus RT = Verbaliserende
Voorbeelden (A2).
Er is gebleken, dat het niveau van de gebruiker en de
ontwerper een grote rol speelt, waarbij met name het niveau
van de gebruiker een beperkende factor is voor het voldoen van
een representatie techniek.
Tot nu toe is de aanname gemaakt, dat de gebruiker en de
ontwerper slechts een basisniveau hebben. Echter als hun
niveau groter is dan het gestelde basisniveau, dan zal dit
gevolgen hebben voor het voldoen van meerdere representatie
technieken. Als de eis dat een representatie techniek direct
implementeerbaar moet zijn wordt verruimd, waardoor de
representaties ook indirect implementeerbaar mogen zijn, dan
zal dit ook van invloed zijn op het aantal representatie
technieken die voldoen.
Aan de hand van deze wetenschap is de volgende strategie op te
stellen om te bepalen welke representatie technieken voldoen.
57
Definitie:
RT ≡ Representatie Techniek.
RO ≡ RT door de ontwerper beheerst.
RG ≡ RT door de gebruiker beheerst.
Eigenschappen:
[E1]: De gebruiker
[E2]: De ontwerper
[E3]: RT is direct
[E4]: RT is direct
is van basisniveau.
is van basisniveau.
implementeerbaar.
of indirect implementeerbaar.
Indien de gebruiker van een hoger niveau is, dan het gestelde
basisniveau, dan zijn de te hanteren representatie technieken
mede afhankelijk van de technieken die de gebruiker beheerst.
Deze eigenschap komt tot uitdrukking in het volgende axioma:
[A6] ¬ (De gebruiker is van basisniveau) ==> RG
Ofwel: ¬ E1 ==> RG.
Indien de ontwerper van een hoger niveau is dan het gestelde
basisniveau, dan zijn de te hanteren representatie technieken
mede afhankelijk van de technieken die de ontwerper beheerst.
Deze eigenschap komt tot uitdrukking in het volgende axioma:
[A7]
¬ (De ontwerper is van basisniveau) ==> RO
Ofwel: ¬ E2 ==> RO.
Indien de eis vervalt dat een representatie niet alleen direct
implementeerbaar hoeft te zijn, maar indirect implementeerbaar
kan zijn, dan zijn er meer representatie technieken die
voldoen. Deze eigenschap wordt door het volgende axioma
weergegeven:
[A8]
RT is direct of indirect implementeerbaar ==>
RT ε { Relationeel Model, Verhalende Beschrijving,
Toestandsovergangen, Verbaliserende Voorbeelden, DFD}
Strategie:
if Gebruiker is van basisniveau
(1) then Verbaliserende Voorbeelden
else if
Ontwerper is van basisniveau and RT is direct
implementeerbaar
(2)
then RG and (Relationeel Model or Verbaliserende
Voorbeelden
else if
Ontwerper is van basisniveau and RT is
implementeerbaar
(3)
then RG and (Relationeel Model or DFD
Verbaliserende Voorbeelden or
Toestandsovergangen)
(4)
else RG and RO and not (ER or Wiskundige
Grammatica’s or Datastructuren)
58
Bewijs van de strategie:
(1) Stel [E1], dan volgt uit axioma [A2]:
RT = Verbaliserende Voorbeelden
(2)
Stel ¬[E1] and [E2] and [E3], dan volgt uit [A3], [A5] en
[A6]:
RG and (RT ε {Relationeel Model, DFD, ER,
Toestandsovergangen, Wiskundige Grammatica’s,
Datastructuren, Verbaliserende Voorbeelden}) and ( RT =
Verbaliserende Voorbeelden OR RT = Relationeel Model)
Vereenvoudiging van deze uitdrukking levert:
RG and (RT = Verbaliserende Voorbeelden OR RT =
Relationeel Model)
(3)
Stel ¬[E1] and [E2] and [E4], dan volgt uit [A6], [L3] en
[A8]:
RG and (RT ε {Relationeel Model, DFD, ER,
Toestandsovergangen, Wiskundige Grammatica’s,
Datastructuren, Verbaliserende Voorbeelden}) and ( RT ε
{Relationeel Model, Verhalende Beschrijving, DFD,
Toestandsovergangen, Verbaliserende Voorbeelden}
Vereenvoudiging van deze uitdrukking levert:
RG and RT ε {Relationeel Model, Verbaliserende
Voorbeelden, Toestandsovergangen, DFD}
(4)
Stel ¬[E1] and ¬[E2] and [E4], dan volgt uit [A6], [A7]
en [A8]:
RG and RO and RT ε { Relationeel Model, Verhalende
Beschrijving, Toestandsovergangen, Verbaliserende
Voorbeelden, DFD}
59
4.2.5
De conceptuele informatie modellen
1. drukt_formeel_uit
2. wordt_formeel_
uitgedrukt_door
3. is_geschikt_voor
4. is_modelleerbaar_door
5. wordt_beschreven_door
6. beschrijft
7. is_systologisch
8. is_datalogisch
9. is_infologisch
Definitie:
CIM ≡ Conceptueel Informatie Model.
De meest essentiële taak bij Informatie Systeem ontwikkeling
is de informele vereisten uit te drukken in een formele taal.
In de bovenstaande figuur komt dit uiting in de relatie <1,2>
(= <drukt_formeel_uit, wordt_formeel_uitgedrukt_in>) tussen
CIM en de Informele Probleem Specificatie.
Als een model een Conceptueel Informatie Model is, dan is dit
model of een Systologisch Model of een Datalogisch Model of
een Infologisch Model of een Technisch Model, ofwel als een
model een CIM is, dan is het precies één van deze modellen.
Deze eigenschap wordt door de volgende twee axioma’s
uitgedrukt:
[A1] Systologisch Model ∩ Infologisch Model ∩ Datalogisch
Model ∩ Technisch Model = φ.
[A2] Systologisch Model OR Infologisch Model OR Datalogisch
Model OR Technisch Model = CIM.
60
Uit de figuur blijkt vervolgens, dat de ontwikkelmethode het
conceptuele informatie model opstelt. Dit wordt weergegeven
door de relatie <3,4> (= <is_geschikt_voor, is_modelleerbaar_
door>) tussen ISDM en Informele Probleem Specificatie. De
informele vereisten, gegeven door de informele probleem
specificatie, worden formeel uitgedrukt door het conceptuele
informatie model, indien de informele probleem specificatie
modelleerbaar is door de ontwikkel methode. Deze eigenschappen
worden door het volgende axioma weergegeven:
[A3] Aspecten worden_beschreven_door CIM drukt_formeel_uit
Informele Probleem Specificatie is_modelleerbaar_door
ISDM.
Een andere eigenschap die bij de laatste relatie moet gelden
is dat elke informele probleem specificatie modelleerbaar is
door een informatie systeem ontwikkelmethode. Deze eigenschap
wordt door het volgende axioma weergegeven:
[A4] E M [ Informele Probleem Specificatie S is_modelleerbaar_
door ISDM M ]
Als laatste moet de eigenschap gelden, dat elke informele
probleem specificatie uitgedrukt moet kunnen worden door een
CIM. Deze eigenschap wordt door het volgende axioma
weergegeven:
[A5] E C [ Informele Probleem Specificatie S wordt_formeel_
uitgedrukt_door CIM C ]
Bij de ontwikkeling van een Informatie Systeem moet een grote
mate van overeenstemming bestaan omtrent de relevant geachte
conceptuele modellen. Wordt aan deze voorwaarde niet voldaan,
dan is de kans op communicatie stoornissen groot. Er zijn
verschillende soorten conceptuele modellen te onderscheiden,
die elk een aantal aspecten beschrijven. In de bovenstaande
figuur wordt dit weergegeven door de relatie <5,6> (=
<wordt_beschreven_door, beschrijft>) tussen Aspecten en
Conceptueel Informatie Model. Uit de populatie valt af te
leiden welke soorten CIM welke aspecten beschrijven.
61
Hieruit volgt dat alle aspecten van de UoD kunnen worden
beschreven, ofwel de UoD kan gemodelleerd worden. Bij deze
modelleerbaarheid kan een verband worden gelegd met de kosten.
Dit is als volgt grafisch weer te geven:
1. kan_gemodelleerd_worden_
door
2. geeft_modellering_voor
3. heeft
4. zijn_voor
Een UoD kan gemodelleerd worden door een ISDM. De systeem
ontwikkeling met behulp van een zekere ISDM heeft bepaalde
kosten.
62
Iedere UoD is te beschrijven als een aantal bij elkaar
behorende kenmerken van de desbetreffende UoD. Dit
resulteert in de volgende definitie:
[D2] UoD ≡ Verzameling kenmerken.
Dit is als volgt grafisch weer te geven:
Uit het verband tussen de UoD en de kosten en uit de kenmerken
van de UoD kan de volgende strategie voor de bepaling van de
te kiezen methode geabstraheerd worden:
Bepaal de kenmerken van de UoD -> instantie van UoDinschatting.
if nieuwe instantie
then Probleem: ontwikkel procedure is onbekend
else selecteer ISDM met minimale ontwikkel kosten
Dit betekent, dat indien de kenmerken niet voorkomen in de UoD
inschatting, dat er dan een nieuwe ontwikkel procedure
gecreëerd moet worden. Bevat de UoD inschatting de kenmerken
wel, kies dan die methode waarbij deze kenmerken voorkomen en
waar de kosten minimaal zijn.
63
4.2.6
Beheersmethoden voor IS ontwikkeling
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
beheerst
wordt_beheerst_door
wordt_afgesloten_door
sluit_af
wordt_geleverd_door
levert
concretiseert
wordt_geconcretiseerd_door
geeft
wordt_gegeven_door
volgt_op
wordt_opgevolgd_door
is_systeem_documentatie
is_ontwerp_documentatie
is_beleidsgroep
is_stuurgroep
is_fasering
is_documentering
is_project_organisering
Zoals in het vorige hoofdstuk is beschreven kan de beheersing
van de ontwikkelingsprojecten op verschillende manieren worden
verwezenlijkt.
Dit komt in de bovenstaande figuur tot uiting in de relatie
<1,2> (= beheerst, wordt_beheerst_door>) tussen Beheersmethode
en IS Ontwikkeling.
Beheersmethode wordt onderverdeeld in Fasering, Documentering
en Project Organisatie. Bij fasering wordt elke fase
afgesloten door een document. Dit wordt weergegeven door de
relatie <3,4> (= <wordt_afgesloten_door, sluit_af>) tussen
Fasering en Document. De documenten worden geleverd door
documentering. Dit wordt weergegeven door de relatie <5,6> (=
<wordt_geleverd_door,levert>) tussen Document en
Documentering. Document wordt onderverdeeld in Systeem,
Ontwerp en Project. Deze eigenschap wordt door het volgende
axioma weergegeven:
[A1] Fasering wordt_afgesloten_door Document wordt_geleverd_
door Beheersmethode.
64
De project organisatie bestaat uit een beleidsgroep, een
stuurgroep en diverse project groepen. De beleidsgroep stelt
richtlijnen op. Dit wordt weergegeven door de relatie <9,10>
(= <geeft, wordt_gegeven_door>) tussen Beleidsgroep en
Richtlijnen. De stuurgroep werkt de richtlijnen verder uit.
Dit wordt weergegeven door de relatie <7,8> (= <concretiseert,
wordt_geconcretiseerd_door>) tussen Stuurgroep en Richtlijnen.
De projectgroepen zorgen voor ontwerp, bouw, invoering en
nazorg. Dit wordt weergegeven door de relatie <11,12> (=
<volgt_op, wordt_opgevolgd_door>) tussen Projectgroep en
Richtlijnen. Bij de drie relaties (<7,8>, <9,10> en <11,12>)
moet de volgende eis omtrent de volgorde geformuleerd worden:
De richtlijnen die door de beleidsgroep worden gegeven worden
eerst door de stuurgroep geconcretiseerd, om vervolgens door
de projectgroep te worden opgevolgd. Deze eigenschap wordt
door de volgende axioma’s weergegeven:
[A2] Beleidsgroep geeft Richtlijnen R1 wordt_geconcretiseerd_
door Stuurgroep.
[A3] Projectgroep volgt_op Richtlijnen R1 wordt_
geconcretiseerd_door Stuurgroep.
[A4] Beleidsgroep geeft Richtlijnen R1 wordt_geconcretiseerd_
door Stuurgroep ==>
Projectgroep volgt_op Richtlijnen R1 wordt_
geconcretiseerd_door Stuurgroep.
[A5] ¬(Beleidsgroep geeft Richtlijnen RL) ==>
¬(Richtlijnen RL worden_geconcretiseerd_door Stuurgroep).
[A6] ¬(Stuurgroep concretiseert Richtlijnen RL) ==>
¬(Richtlijnen RL worden_opgevolgd_door Projectgroep).
Een Document bestaat of uit Systeemdocumentatie of uit
Ontwerpdocumentatie of uit Projectdocumentatie. Deze
eigenschap wordt weergegeven in de volgende axioma’s:
[A7] Systeem or Ontwerp or Project = Document
[A8] Systeem ∩ Ontwerp ∩ Project = φ
De project organisatie wordt gevormd door verschillende
project- en stuurgroepen en door een beleidsgroep. Dit is als
volgt te formuleren:
[A9] Beleidsgroep or Stuurgroep or Projectgroep = Project
Organisatie.
[A10]
Beleidsgroep ∩ Stuurgroep ∩ Projectgroep = φ
65
4.2.7
Aanpassingen in het Informatie Systeem
1 . is_snapshot_systeem
2 . vervult_informatie_
behoefte
2’. informatie_behoefte_wordt_
vervuld_door
3 . corrigeert
3’. wordt_gecorrigeerd_door
4 . vergeet
4’. wordt_vergeten_door
5 . geeft_weer
5’. wordt_weergegeven_door
6 . voegt_element_toe_aan
6’. element_wordt_toegevoegd_
door
7 . transformeert_element_in
7’. element_wordt_
getransformeerd_door
8 . element_wordt_verwijderd_
door
8’. verwijdert_element_uit
9 . wordt_aangepast_door
9’. past_aan
10 . zorgt_voor_aanpassing_van
11 . wordt_aangepast_o.i.v
Het traditionele en het evoluerende Informatie Systeem wordt
in de bovenstaande figuur weergegeven door respectievelijk
Snapshot Systeem en EIS. Er geldt hierbij, dat een Informatie
Systeem of een snapshot systeem of een Evoluerend Informatie
Systeem is. Deze eigenschap wordt door de volgende axioma’s
weergegeven:
[A1] Snapshot Systeem OR EIS = IS.
[A2] Snapshot Systeem ∩ EIS = φ
Voor beide soorten Informatie Systeem geldt, dat de informatie
behoefte vervuld dient te worden. In de bovenstaande figuur
wordt dit weergegeven door de relatie <2,2’> (= <vervult_
informatie_behoefte, informatie_behoefte_wordt_vervuld_door>)
tussen IS en Organisatie. Hierbij dient aan de volgende
eigenschap te worden voldaan: Elke informatie behoefte van de
organisatie wordt vervuld door het Informatie Systeem. Deze
eigenschap wordt door het volgende axioma weergegeven:
[A3] IS vervult_informatie_behoefte Organisatie.
66
Voor beide soorten Informatie Systemen geldt ook, dat de
aanpassingen moeten resulteren in een toestandsverandering,
zodanig dat de nieuwe toestand van het Informatie Systeem de
nieuwe toestand van de organisatie weergeeft. Dit wordt in de
bovenstaande figuur weergegeven door de relatie <5,5’> (=
<geeft_weer, wordt_weergegeven_door>) tussen IS en
Organisatie. Deze eigenschap wordt door het volgende axioma
weergegeven:
[A4] Organisatie wordt_weergegeven_door IS.
Definitie:
[D1] Opslag ≡ IS geeft_weer Organisatie.
Bij de toevoeging van een nieuw element, ook wel geboorte
genaamd, moet dit element worden toegevoegd aan het applicatie
model. Dit wordt weergegeven door de relatie <6,6’> (=
<voegt_element_ toe_aan, element_wordt_toegevoegd_aan>) tussen
Opslag en Applicatie Model. Deze eigenschap wordt door het
volgende axioma weergegeven:
[A5] Opslag voegt_element_toe_aan Applicatie Model.
Bij het Evoluerende Informatie Systeem bestaat de aanvullende
eis, dat de eerder opgeslagen informatie gecorrigeerd moet
kunnen worden. In de bovenstaande figuur wordt dit weergegeven
door de relatie <3,3’> (= <corrigeert, wordt_gecorrigeerd_
door>) tussen EIS en Opslag.
Deze correctie zal nu nog in het applicatie model moeten
worden doorgevoerd. Dit wordt weergegeven door de relatie
<7,7’> (= <transformeert_element_in, element_wordt_
getransformeerd_door>) tussen Opslag en Applicatie Model. De
correctie wordt door het volgende axioma weergegeven:
[A6] EIS corrigeert Opslag transformeert_element_in Applicatie
Model.
Een volgende aanvullende eis bij het Evoluerende Informatie
Systeem is, dat eerder opgeslagen informatie vergeten moet
kunnen worden. Dit wordt weergegeven door de relatie <4,4’> (=
< vergeet, wordt_vergeten_door>) tussen EIS en Opslag.
Deze verwijdering zal nu nog in het applicatie model moeten
worden doorgevoerd. Dit wordt weergegeven door de relatie
<8,8’> (= <verwijdert_element_uit, element_wordt_verwijderd_
door>) tussen Opslag en Applicatie Model. Deze verwijdering
van een element, ook wel overlijden genoemd, wordt door het
volgende axioma weergegeven:
[A7] EIS vergeet Opslag verwijdert_element_uit Applicatie
Model.
67
Bij de relaties betreffende de opslag, verwijdering en
aanpassing van een element aan het applicatie model dienen nog
aanvullende eisen betreffende de volgorde worden gedefinieerd.
Ten eerste moet een element eerst worden toegevoegd aan het
applicatie model voordat het veranderd kan worden. Deze
eigenschap wordt door het volgende axioma weergegeven:
[A8] Opslag voegt_element_toe_aan Applicatie Model
element_wordt_ getransformeerd_door Opslag.
Vervolgens moet een element eerst worden toegevoegd aan het
applicatie model voordat het eruit verwijderd kan worden. Deze
eigenschap wordt door het volgende axioma weergegeven:
[A9] Opslag voegt_element_toe_aan Applicatie Model element_
wordt_verwijderd_door Opslag.
De organisatie kan onder invloed van de omgeving veranderen,
met als resultaat dat de informatie behoefte eventueel kan
veranderen. De verandering die de organisatie ondergaat wordt
weergegeven door de relatie <10,11> (= <zorgt_voor_aanpassing_
van, wordt_aangepast_o.i.v>) tussen Omgeving en Organisatie.
Deze eigenschap wordt door het volgende axioma weergegeven:
[A10]
Organisatie wordt_aangepast_o.i.v Omgeving.
Deze eigenschap kan als gevolg hebben, dat de informatie
behoefte verandert. Als dit het geval is dan moet het
Evoluerende Informatie Systeem ook aangepast worden. Dit wordt
weergegeven door de relatie <9,9’> (= <wordt_aangepast_door,
past_aan>). Deze eigenschap wordt door het volgende axioma
weergegeven:
[A11] EIS wordt_aangepast_door Verandering.
Definitie:
[D2] Uitvoer ≡ Levering van informatie.
Om te bepalen of een informatie systeem nog in de informatie
behoefte voorziet, wanneer een organisatie een verandering
ondergaat is de volgende strategie te volgen:
Organisatie ondergaat verandering:
if informatie behoefte is deel van mogelijke uitvoer
then Informatie systeem levert informatie
else Probleem: IS moet aangepast worden.
68
Om te bepalen of de informatie behoefte deel is van de
mogelijke uitvoer, kan de vraag gesteld worden, of de gewenste
informatie geleverd kan worden. Het aanpassen van het
informatie systeem dient zodanig te gebeuren, dat de gewenste
informatie geleverd wordt door het informatie systeem. Deze
aanpassingscyclus is als volgt grafisch weer te geven:
4.3
Verband tussen de talen
In dit hoofdstuk zijn er bij de verschillende schema’s eisen
en eigenschappen beschreven. Deze beschrijvingen zijn gegeven
in een gemodelleerde taal "M". Bij deze beschrijvingen is een
vertaling gegeven in de alledaagse taal. Dit is de zogenaamde
experttaal "E".
4.3.1
Begrijpbaarheid
Uit de beschreven eisen en eigenschappen in de gemodelleerde
taal M, blijkt dat al deze beschrijvingen te vertalen zijn in
de experttaal E. Beide beschrijvingen zijn begrijpbaar voor de
gebruiker.
Met andere woorden geldt, dat elke zin uit M ook te begrijpen
is en te vertalen is naar een zin in E. De vraag die hier
onmiddellijk bij rijst, is of elke zin uit E ook uit drukken
is in M. Met andere woorden wat is de kracht en de beperking
van M.
69
4.3.2
Omvang
Uit de zinnen in de gemodelleerde taal M beschreven
eigenschappen en eisen en de bijbehorende in de experttaal E
beschreven vertaling blijkt, dat de zinnen in de experttaal
over het algemeen langer zijn.
De experttaal E blijkt niet voldoende te zijn om de eisen van
de gebruiker vast te leggen, omdat deze taal dubbelzinnigheden
kan bevatten. Dit komt, omdat de betekenis van de experttaal
afhankelijk is van het wereldmodel van degene die een zin in E
geeft. Deze dubbelzinnigheden komen in de gemodelleerde taal M
niet voor. In de taal M zijn alleen zinnen te maken, die uit
de bijbehorende schema’s afgeleid kunnen worden. Met andere
woorden geldt er dat het wereldmodel beperkt wordt tot de
gegeven schema’s. Er bestaat overeenstemming omtrent de
geldigheid van deze schema’s, ofwel deze schema’s geven weer
wat de gebruiker wenst en de ontwerper weet exact wat er mee
bedoeld wordt.
4.3.3
Uitdrukkingskracht
Om een zin uit de experttaal E uit te drukken in de
gemodelleerde taal M moet er eerst overeenstemming bestaan
omtrent het wereldmodel, ofwel er moet eerst een schema
ontwikkeld worden waaruit deze zin in M af te leiden is.
4.3.4
Conclusie
Er is gebleken, dat de kracht van de gemodelleerde taal M is,
dat elke zin uit de experttaal E ondubbelzinnig is uit te
drukken in M. Een beperking hierbij is echter, dat de zinnen
in taal M aan strakkere regels zijn gebonden dan in taal E, om
de ondubbelzinnigheid te garanderen. De oorzaak hiervan is,
dat het wereldmodel vrij beperkt is.
Een andere beperking is, dat er eerst een wereldmodel
ontwikkeld moet worden, waarover overeenstemming moet bestaan
tussen de betrokkenen, in dit geval de gebruiker en de
ontwerper, voordat er iets beschreven kan worden in de
gemodelleerde taal M.
70