INFORMATIE SYSTEEM ONTWIKKELING ALS EEN PROCES

Afstudeerscriptie

nr. 319

door

Coen Verleur

Katholieke Universiteit Nijmegen 15 juli 1994Faculteit Wiskunde en InformaticaVakgroep InformaticaAfdeling Informatiesystemen

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

1

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 InformatieSysteem. . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . 46

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

1 Introductie . . . . . . . . . . . . . . . . . . . . . 7

1.1 Vraagstelling . . . . . . . . . . . . . . . . . . . 7

1.2 Opzet van het onderzoek . . . . . . . . . . . . . . 7

2 Analyse van de problemen en behoeften . . . . . . . . 8

2.1 Inleiding . . . . . . . . . . . . . . . . . . . . . 8

2.2 Slagen en/of falen van Informatie Systemen . . . . . 8

2.2.1 Factoren van het slagen en/of falen . . . . . . . 8

2.3 Functionele vereisten . . . . . . . . . . . . . . . 9

2.3.1 Eisen aan ontwikkelmethoden . . . . . . . . . . . 10

2.4 Vereisten aan het Informatie Systeem . . . . . . . . 10

2.4.1 Informatie en communicatie . . . . . . . . . . . . 10

2.4.2 Organisaties veranderen . . . . . . . . . . . . . 12

2.4.2.1 Greiner . . . . . . . . . . . . . . . . . . . . 12

2.4.2.2 Quin en Cameron . . . . . . . . . . . . . . . . 12

2.5 Vereisten aan het EIS . . . . . . . . . . . . . . . 13

3 De globale structuur . . . . . . . . . . . . . . . . . 14

3.1 Inleiding . . . . . . . . . . . . . . . . . . . . . 14

3.2 Het startpunt van het ontwikkel proces . . . . . . . 14

3.3 Het conceptuele informatie model . . . . . . . . . . 14

3.3.1 De verschillende modellen van een IS . . . . . . . 15

3.4 Strategieën voor informatie behoefte bepaling . . . 16

3.4.1 Ordening in de strategieën . . . . . . . . . . . . 16

3.4.2 Ondersteuning van de verschillende processen . . . 17

3.5 De rol van de formele representaties . . . . . . . . 19

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 Aanpassingen in Evolutionair Informatie Systeem. . 20

3.6 De rol van grafische representaties . . . . . . . . 22

3.6.1 Uitdrukkingskracht en compleetheid . . . . . . . . 22

3.6.2 Begrijpbaarheid . . . . . . . . . . . . . . . . . 24

3.7 Beheersing van de ontwikkeling . . . . . . . . . . . 24

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

3.8.9 Conclusie . . . . . . . . . . . . . . . . . . . . 34

3.9 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

4 Het proces in detail . . . . . . . . . . . . . . . . 43

4.1 Inleiding . . . . . . . . . . . . . . . . . . . . . 43

4.2 Gemodelleerde beschrijving . . . . . . . . . . . . . 43

4.2.1 Strategieën en hun methoden . . . . . . . . . . . 44

4.2.1.1 De groter_dan relatie . . . . . . . . . . . . . 44

5

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

4.2.4.1 Eigenschappen . . . . . . . . . . . . . . . . . 55

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 . . . . . . . . . . . . . . . . . . . . 70Korte samenvatting

Dit artikel gaat over het opstellen van eenraamwerk voor de ontwikkeling van een InformatieSysteem voor evaluerende organisaties. Het raamwerkgeeft aan, aan welke voorwaarden moet wordenvoldaan om tot een succesvol project te komen.Het artikel is speciaal toegespitst op managers eneindgebruikers. De managers en eindgebruikers zijnsamengenomen, omdat de splitsing tussenautomatiseerders en niet-automatiseerders isgemaakt. De rol die de managers en eindgebruikersbij de ontwikkeling van Informatie Systemen spelenis vergelijkbaar met betrekking tot de verhoudingmet de automatiseerders, ook al spelen beide eengeheel verschillende rol binnen het proces vanautomatisering.

6

1 Introductie

1.1 Vraagstelling

Bij de ontwikkeling van Informatie Systemen blijkt er nog aleens sprake te zijn van het niet slagen van automatiserings-projecten. De vraag die hier onmiddellijk bij rijst, is: " Watis de oorzaak van dit falen van automatiseringsprojecten" en"Hoe kan dit falen worden voorkomen?"Hieruit volgt de volgende vraag: "Zijn de beschikbare methodengeschikt voor de ontwikkeling van Informatie Systemen?". Dezevraag bevat impliciet de volgende vraag: "Sluiten de eisen,die de methoden stelt aan de betrokkenen, aan bij wat erredelijkerwijs van de betrokkenen verwacht mag worden, of zijndeze eisen te hoog gegrepen?"In de traditionele Informatie Systeem ontwikkeling wordt ergeen rekening gehouden met veranderende organisaties. Tijdenshet gebruik van het Informatie Systeem verandert de organisa-tie met als gevolg, dat de aansluiting tussen het InformatieSysteem en de organisatie niet optimaal meer is. Hettraditionele Informatie Systeem is applicatie afhankelijk,waardoor de traditionele aanpassing neerkomt op het opnieuwontwerpen en ontwikkelen van het Informatie Systeem. Deaanpassingen kunnen niet meer in termen van onderhoudgebeuren.Is het mogelijk om het Informatie Systeem zodanig teontwikkelen, dat het Informatie Systeem applicatieonafhankelijk is? Is het mogelijk om het onderhoud zodanig uitte voeren, dat de reguliere arbeidsprocessen hier niet onderlijden? Is hieruit een methode te ontwikkelen om hetInformatie Systeem te ontwikkelen, zodanig dat het InformatieSysteem blijvend aansluit op de informatie behoefte van deorganisatie? Is zo’n methode praktisch toepasbaar?

1.2 Opzet van het onderzoek

Aan dit onderzoek is een gedegen literatuur studievoorafgegaan om tot een inzicht te komen in de problematiekdie bij de organisaties speelt. In het kader van het onderzoekheb ik als uitgangspunt het boek ’Grondslagen van deinformatica voor managers en eindgebruikers’ [Nijssen] en hetartikel ’Evolution and time in Information Systems’ [FOP]gebruikt. Het eerste geeft een raamwerk voor InformatieSysteem ontwikkeling op de traditionele manier, terwijl hettweede inzicht geeft in de vereisten van een evoluerendInformatie Systeem.

7

2 Analyse van de problemen en behoeften

2.1 Inleiding

In dit hoofdstuk worden ten eerste problemen aan de ordegesteld, waarbij het gaat om de problemen van het(des)functioneren van het Informatie Systeem in deorganisatie. Verder worden er, mede aan de hand van degeanalyseerde problemen, eisen geformuleerd, waaraan hetInformatie Systeem en de ontwikkelmethode minimaal moetenvoldoen.

2.2 Slagen en/of falen van Informatie Systemen

Veel systemen die ontwikkeld worden, lijden aan de SoftwareCrisis. De oorzaak hiervan is hoofdzakelijk te wijten aan eenoverschrijding van de kosten, een overschrijding van deopleverdatum en het niet voorzien in de werkelijke behoeftevan de gebruikers. In werkelijkheid bestaat de Software Crisisuit twee delen: De Systeem Software Crisis en de InformationSoftware Crisis. Het eerste houdt in, dat de basisoperationele software niet effectief geproduceerd enbetrouwbaar gebruikt kan worden. Het tweede deel houdt in, datde applicatie specifieke software niet effectief geproduceerden 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 vaneen project om het als mislukt, problematisch of geslaagd tekunnen beschouwen moeten tegen elkaar afgewogen worden.[Doorewaard]Als indicatie voor het aantal geslaagde systemen kan hetvolgende gegeven worden, naar een onderzoek uit ’88 doorRiesewijk en Warmerdam:

Geslaagd 51.1 %Problematisch 43.8 %Mislukt 4.7 %

Allereerst zijn er de relationele factoren. Hiervan is sprakeals er op het gebied van communicatie problemen ontstaan,doordat de betrokken partijen niet, of niet op de juistemanier, bij het communicatie netwerk van het project betrokkenworden. Er bestaan verschillende semantieken, die voor deverschillende partijen een duidelijke betekenis hebben. Dezeverschillende semantieken kunnen bij een gebrekkigecommunicatie voor problemen zorgen.Verder zijn er de conditionerende factoren. Deze hebbenbetrekking op de voorwaarden of condities waarin de betrokkenorganisaties moeten werken. Hieronder vallen de kenmerken vande organisatie cultuur en structuur, kenmerken van hetproject, kenmerken van het personeelsbestand etc.

8

Er kan een ordening in de kritische factoren gegeven worden.Als zeer problematische factoren gelden de doorlooptijd en dekosten, de project bewaking vanuit een extern bureau en decommunicatie tussen automatiseerders en management.Een klasse factoren die als minder problematisch geldt is dievan de organisatorische inpassing van het systeem, deafstemming van de verschillende belangen, het overleg tussende betrokkenen en de acceptatie van het systeem door hetpersoneel.Als minst problematisch geldt de gebruiksvriendelijkheid, detraining en opleiding van het personeel en herplaatsing enomscholing.Een bijkomend probleem bij het slagen en/of falen van deontwikkeling van Informatie Systemen is, dat er een periodevan ± 10 jaar ligt tussen de ontwikkeling van een theorie enhet toepassen hiervan in de praktijk. Hiervoor zijn een aantaloorzaken te noemen.Allereerst gaat de wetenschapper ervan uit, dat de manageraltijd de beste oplossing zal kiezen. In de praktijk echterblijkt dat de manager echt slechte oplossingen vermijdt en hetliefst kiest voor een bruikbaar alternatief, dat niet teveelrisico inhoudt en wat snel te realiseren is.Vervolgens is het een gegeven, dat de manager altijdtijdgebrek heeft, dus een dag cursus is taboe, en mocht demanager al naar een cursus toegaan, dan blijkt dat daar denieuwe theorieën uitgelegd worden in plaats van hoe hetbedrijf ervan kan profiteren. De manager is dus eigenlijk opzoek naar recepten in plaats van theorieën. Nu rijst dus hetprobleem: Hoe draag je de wetenschap over op de manager? Alslaatste is er de aard van het wetenschappelijk onderzoek. Eengroot deel van het wetenschappelijk onderzoek betreftproblemen, die de manager niet als het belangrijkstebeschouwd. Als gevolg hiervan worden de ontwikkelingen in detheorie, niet (snel genoeg) in de praktijk gebracht.Een factor waar bij automatiserings-projecten geen rekeningmee gehouden wordt is het bestaan van een informeleorganisatie structuur naast de bestaande formele structuur.Deze informele organisatie structuur is te beschouwen als eenvoortdurend veranderend sociaal systeem, dat uit wisselenderelaties tussen personen bestaat. Het werkt over het algemeenals smeerolie waarop de organisatie loopt. Het gevaar bestaat,dat bij automatiseringsprojecten deze informele structuurverloren gaat.

2.3 Functionele vereisten

Alle ontwikkel methoden bevatten een onderdeel, waar defunctionele vereisten achterhaald worden. De functionele eisenzijn afhankelijk van de soort organisatie, het beslissings-niveau van het Informatie Systeem, de functie en de soortbeslisser. De functionele eisen van Informatie Systemen zijnaf te leiden uit de karakteristieken van het bestuurde systeemen het besturend orgaan.

9

2.3.1 Eisen aan ontwikkelmethoden

Elke ontwikkelmethode moet aan bepaalde eisen voldoen, wil demethode kans van slagen hebben. Deze eisen liggen op hetgebied van de effectiviteit en efficiency.Voor de eisen aan de effectiviteit geldt, dat de methodezodanig van opzet moet zijn, dat deze effectieve ondersteuningbiedt bij het ontwerp- en constructieproces, met alsuiteindelijk resultaat een functioneel goed InformatieSysteem.Voor de eisen aan de efficiency geldt, dat de methodevoldoende aanknopingspunten dient te bieden voor efficiëntbeheer van het ontwikkelproces als zodanig.

2.4 Vereisten aan het Informatie Systeem

Aan het Informatie Systeem kunnen verschillende eisen wordengesteld ten aanzien van de informatie behoefte en decommunicatie. De eisen ten aanzien van de communicatie kunnenworden afgeleid uit de architectuur van het bestaandeInformatie 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 Systeemwordt ontworpen om de communicatie tussen mensen teondersteunen. Dus we beginnen de ontwikkeling van dearchitectuur van een Informatie Systeem met een eenvoudigmodel van menselijke communicatie. Communicatie is deuitwisseling van informatie tussen meerdere (groepen)personen. Hieruit is het volgende basis axioma af te leiden:’Een Informatie Systeem is een systeem, die de communicatievan taalkundige zinnen (feiten) tussen mensen ondersteunt.’Hieruit ontwikkelen we een model van een Informatie Systeem,dat iedere relevante component van zo’n Informatie Systeembevat en hun interacties beschrijft (grafische taal). Ditmodel bestaat uit twee componenten, te weten de SoftwareInformation Processor en de Human Information Processor. DeSoftware Information Processor is een actieve component dieinformatie kan behandelen volgens van te voren vastgestelderegels. De Human Information Processor is een mens, die eenproces uitvoert.

10

Het is niet genoeg dat twee communicatie partners dezelfdetaal spreken, ze moeten ook de taal in dezelfde contextplaatsen, zodanig dat er geen andere interpretatie mogelijkkan zijn. Met andere woorden: de twee communicatie partnersmoeten hetzelfde woord model gebruiken, zodat ze dezelfdebetekenis aan dezelfde zinnen geven. [Nijssen]

Voorbeelden:A: Reagan en Bush (communicatie partners) spreken dezelfde

taal (Engels) en delen hetzelfde interpretatie model alshet om politiek gaat.

B: Bush en Dukakis (communicatie partners) spreken dezelfdetaal (Engels), maar delen niet hetzelfde interpretatiemodel. Bijvoorbeeld: Bij de uitwisseling van kennis oversociale zekerheidspolitiek is een goed uitgangspunt vooreen debat, maar geen effectieve uitwisseling van feiten.

C: Een Chinees en een Cubaan delen hetzelfde interpretatiemodel (beide communist), maar ze spreken niet dezelfdetaal.

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, omdatdit het enige voorbeeld is waarbij sprake is van dezelfde taalen hetzelfde interpretatie model. Bij allen is er sprake vanhetzelfde communicatie kanaal.Eisen die tot dusver voor een effectieve menselijkecommunicatie gesteld worden zijn het gemeenschappelijkcommunicatie kanaal, de gemeenschappelijke taal en hetgemeenschappelijk interpretatie model.Eisen die gesteld worden aan de menselijke communicatie,worden ook aan de architectuur van het Informatie Systeemgesteld, omdat dit het communicatie middel met de mens is. Ermoet dus sprake zijn van een gemeenschappelijk communicatiekanaal, gemeenschappelijke taal en een gemeenschappelijkinterpretatie model.Indien het gemeenschappelijke communicatie kanaal ontbreekt,dan betekent dit, dat er geen communicatie mogelijk is tussende gebruiker en het Informatie Systeem.Voor de gemeenschappelijke taal zijn er twee mogelijkheden.Ten eerste is er de natuurlijke taal. Het is echter nietmogelijk de computer direct in een menselijke taal te latencommuniceren. Een tweede mogelijkheid is de computertaal. Eenvoorbeeld hiervan is SQL, wat wordt gebruikt om informatieover te brengen naar het relationeel database managementsysteem.In veel Informatie Systemen is de formele taal geïmplementeerdin het Informatie Systeem, zodat er geen fysieke Database isdie de definitie van de formele taal bevat. Voor hetgemeenschappelijk interpretatie model moet het InformatieSysteem een formeel model bevatten, wat exact definieert welkefeiten zijn toegestaan. Elk bericht van de gebruiker moetworden gecontroleerd op zijn correctheid.

11

2.4.2 Organisaties veranderen

Samen met de organisaties verandert de informatie behoefte vande organisaties. In de loop der jaren zijn er verschillendemodellen van organisaties ontwikkeld. Bij al deze modellendoorloopt de organisatie een aantal fasen of stadia.[Bemelmans]

2.4.2.1 Greiner

Organisaties doorlopen verschillende groeifasen. Elke fase iste beschouwen als een soort evolutie, die aan het eindafgesloten wordt met een crisis situatie (revolutie). Elkefase heeft een aantal kenmerken, die weer consequenties hebbenvoor de vorm en de opzet van het Informatie Systeem (soortinformatie).

2.4.2.2 Quin en Cameron

Uit een vergelijking van 9 verschillende modellen komen Quinen Cameron tot een model met vier stadia. Elk stadium heeftzijn eigen kenmerken, die terug te voeren zijn tot drieessentiële dimensies, namelijk de oriëntatie van deorganisatie, de organisatie cultuur en structuur en hethoofdobject van beslissingen.De oriëntatie van de organisatie is ten eerste extern gericht.Dit houdt in, dat er afzetmarkten gecreëerd en produktiemidde-len verworven moeten worden. Ten tweede is deze dimensieintern gericht. Dit houdt het motiveren van het personeel enconsolideren van resultaten in.De organisatie cultuur en structuur houdt de flexibiliteit vande organisatie de formalisering en bureaucratisering in. Hethoofdobject van beslissingen legt het zwaartepunt op hetverwerven en efficiënt inzetten van noodzakelijke middelen enop het ontwikkelen ven nieuwe produkt/markt combinaties en hetformuleren van nieuwe strategieën. Hierbij moet echter dekanttekening geplaatst worden, dat niet alle onderdelen van deorganisatie zich noodzakelijkerwijs in dezelfde fase bevinden.

Samenvattend betekent dit, dat de organisatie vaak en snelverandert en dus verandert de informatie behoefte van deorganisatie ook. Dus er is behoefte aan een doelmatigestrategie om het Informatie Systeem ook vaak en snel te kunnenlaten veranderen, om bij de informatie behoefte aan te kunnensluiten.

12

2.5 Vereisten aan het EIS

De grootste eis die gesteld kan worden aan een EvolutionairInformatie Systeem, is dat het ’meegroeit’ met de organisatie,zonder dat er een onderbreking komt van de processen van deorganisatie. Dit meegroeien houdt in, dat het InformatieSysteem de veranderingen van de organisatie volgt, op eenzodanige wijze, dat het verschil tussen de afbeelding en dewerkelijkheid klein blijft. Uit deze vereiste kunnen verschil-lende eisen gespecificeerd worden.Ten eerste staat het Informatie Systeem aanpassingen toe vanalle informatie, die afhankelijk is van het Universe ofDiscourse van het Informatie Systeem. De specificatie vaninformatie die afhankelijk is van een specifiek organisatiedomein is deel van de architectuur van het EvolutionairInformatie Systeem.Ten tweede staat het Informatie Systeem correctie toe van(eerder) opgeslagen informatie. Het kan blijken, dat deopgeslagen informatie niet (meer) blijkt te voldoen aan devereisten. De noodzaak voor correctie wordt gegeven doorvalidatie. Consistentie wordt gecontroleerd door het systeem.Ten derde vergeet het systeem geen informatie, tenzij hetexpliciet gevraagd wordt. Met andere woorden de completegeschiedenis van informatie binnen het Informatie Systeemblijft bewaard.Als laatste mogen aanpassingen van het Informatie Systeem deorganisatie activiteiten niet onderbreken. De intentie van hetEvolutionair Informatie Systeem is het verschil tussenbehoefte en aanbod van informatie te minimaliseren. Als gevolghiervan moet de factor tijd moet aan het Informatie Systeemworden toegevoegd, om verschillende soorten tijdstippen tekunnen opslaan. De eerste soort is het tijdstip van degebeurtenis. Deze wordt gebruikt voor het opslaan van degeschiedenis van informatie. De tweede soort is het tijdstipvan de opslag van gegevens. Deze wordt gebruikt om correctiesuit 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 behoeftebinnen de organisaties verandert, doordat de organisatiesveranderen. Aan de hand hiervan worden de eisen ten aanzienhet Informatie Systeem geformuleerd.In dit hoofdstuk worden, voor de in het vorige hoofdstukgeformuleerde problemen en behoeften, alternatievengeformuleerd.

3.2 Het startpunt van het ontwikkel proces

Bij het vastleggen van de vereisten bestaat de initiële invoeruit ruw materiaal bestaan. Dit is een niet precieze, nietbruikbaar gestructureerde, vage en incomplete specificatie vande vereisten. Dit ruwe materiaal kan niet worden uitgedrukt ingoed gedefinieerde interpreteerbare computertaal.De eerste en meest essentiële taak bij Informatie Systeemontwikkeling is de informele vereisten uitdrukken in eenformele taal. Dit kan niet door software gerealiseerd worden.Met andere woorden betekent dit, dat er ruimte is tussen deinformele en de formele representatie. Deze ruimte, desemantische leemte, ook wel ’semantic gap’ genaamd, moetoverbrugd worden. Het doel van iedere Informatie Systeemontwikkelmethode is het leveren van een effectieveoverbrugging. De meeste ontwikkelmethoden missen zo’neffectieve overbrugging. Ze gaan er van uit dat de gebruikerdeze leemte overbrugt, waarbij hij elke methodischeondersteuning mist. De vraag rijst nu, hoe de gebruiker deinvoer betrouwbaar kan leveren en hoe de analist de geleverdeinvoer kan interpreteren in een formele representatiestructuur.

3.3 Het conceptuele informatie model

De verschillende partijen, die betrokken zijn bij deontwikkeling van een Informatie Systeem moeten een grote matevan overeenstemming hebben over de relevant geachteconceptuele 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 Systeemis het opstellen van conceptuele informatie modellen van eenbesturing situatie. Hierin wordt aangegeven voor welkmanagement en voor welke beslissing informatie nodig is,waarom en wanneer. We onderscheiden hier als eerste hetsystologisch model. Dit model beschrijft de pragmatischeaspecten (het wat en waarom van de informatie).Daarnaast bestaat het infologisch model. Dit model beschrijftde semantische aspecten. Hier wordt ingegaan op de gegevens-en verwerkingsprocessen die nodig zijn om die informatie tekunnen produceren.Verder is er het datalogische model. Dit model beschrijft desyntactische aspecten (op welke wijze en in welke vorm moethet systeem worden verwezenlijkt).Als laatste is er het technische model. Hierin wordt concreetaangegeven welke technische faciliteiten zullen wordengebruikt.

Afbeelding 1:De verschillende modellen

15

3.4 Strategieën voor informatie behoefte bepaling

De meest eenvoudige strategie voor het bepalen van deinformatie behoefte is het simpelweg vragen naar deinformatiebehoefte aan gebruikers. Dit levert veelal slechteresultaten. Als oorzaak hiervoor wordt gegeven, dat deinformatiebehoefte divers en complex van aard is, deinteractie tussen gebruikers en ontwerpers veelal lacunesvertoont, sommige gebruikers weigeren mee te werken aan hetinventariseren en structureren van de informatiebehoefte endat gebruikers beperkt zijn in hun mogelijkheden om deinformatiebehoefte te specificeren.De capaciteit van de gebruikers blijkt in het algemeenontoereikend te zijn om een volledig overzicht van de behoeftete specificeren.Verder blijkt dat de gebruikers een afwijking vertonen bij hetspecificeren. Ze refereren bij voorkeur aan bestaande systemenen maken zich zodoende onvoldoende los van het bestaande om debehoeften te specificeren, ze geven een zwaarder gewicht aanrecent opgetreden behoeften en ze kunnen moeilijk oorzaak-gevolg relaties onderkennen, en geven hierdoor de verkeerdeinformatie.

3.4.1 Ordening in de strategieën

Olsen en Davis geven verschillende strategieën om deinformatie behoefte te bepalen, gerangschikt van hoge naarlage mate van onzekerheid.De strategie met de hoogste mate van onzekerheid is deoberstrategie. Dit is het ondervragen van gebruikers. Hiervoorzijn diverse methoden, zoals het houden interviews enenquêtes, brainstorming en de Delphi-methode. Dit laatste iseen gestructureerde ondervraging met het doel extreme visiesmet argumenten te onderbouwen. Deze strategie is te hanterenbij goed te structureren problemen, waarbij kennis- enervaringsniveau bij gebruikers hoog is, er een beperkt aantalgebruikers en er goed getrainde informatie deskundigen bij hetproject 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 hetvergelijken van besturing situaties met soortgelijke situatiesen daarvoor ontwikkelde Informatie Systemen. De strategie iste hanteren bij goed te structureren problemen, die stabiel inde tijd zijn. Het referentie systeem moet een goede afspie-geling zijn van het gewenste Informatie Systeem. De hieropvolgende strategie is de ontwikkel strategie. Hier wordt eenzorgvuldige analyse en structurering van de besturingssituatieen het te ontwikkelen Informatie Systeem door informatiedeskundigen en gebruikers gemaakt. Methoden hiervoor zijn dekritische succes-factor analyse, Socio-technische analyse,beslissings (operational research) georiënteerde aanpak enproces georiënteerde aanpak en methoden (bijv ISAC).De ontwikkel strategie is te hanteren als referentie systemenontbreken, problemen minder goed te structureren zijn, het

16

kennis/ervarings niveau gebruikers middelmatig is, informatiedeskundigen van hoog niveau zijn of het Informatie Systeemcomplex is met tal van interfaces.De strategie met de laagste mate van onzekerheid is deevolutionaire strategie (ook wel de iteratieve strategie): Hetontwerp en de constructie gebeurt in een aantal kleineincrementele stappen. De methoden hierbij is de prototypebenadering of de data-georiënteerde methode. Deze strategie iste hanteren bij hoge onzekerheid met betrekking tot specifica-ties, sterk groeiende informatie behoeften of als gebruikersen informatie deskundigen de expertise missen om een Informa-tie Systeem in zijn totaliteit te ontwikkelen. [Bemelmans]

3.4.2 Ondersteuning van de verschillende processen

De verschillende processen in een organisatie wordenondersteund, de verschillende onderdelen uit de onderstaandefiguur. Deze ondersteuning is ook van belang voor deverschillende onderdelen van IS ontwikkeling. Zetten we dezeondersteuning af tegen de strategieën om de informatiebehoefte te bepalen, dan volgt hieruit het volgende.Bij de oberstrategie staat de wijze van werken vast. Hierdoorwordt de wijze van ondersteuning en besturing bepaald. Aan dehand 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 eenbestaand systeem als referentiekader te nemen, waar hetbesturingssysteem vergelijkbaar is. Als gevolg hiervan moet demanier van denken ook grote overeenkomsten vertonen met deondersteuning van het bestaande systeem. De resterendeonderdelen, de manier van werken, modelleren en ondersteunen,worden hierdoor in grote lijnen bepaalt door de tweevaststaande onderdelen.Bij de ontwikkel strategie wordt een zorgvuldige analyse eneen structurering van de besturingssituatie gemaakt. Dit houdtin, dat de manier van besturen en modelleren hierdoorvaststaat. De wijze van werken en ondersteunen wordt aan dehand hiervan bepaald.Bij de evolutie strategie wordt het ontwerp en constructie inkleine incrementele stappen gemaakt. Hierdoor staat de wijzevan werken en besturen vast. Aan hand hiervan worden de wijzevan ondersteunen en modelleren bepaald.

17

Afbeelding 2:Proces ondersteuning

Uit het bovenstaande blijkt, dat de gekozen strategie bepaalthoe de wijze van denken, besturen, modelleren, werken enondersteunen moet worden ingevuld. Hierbij staat er eengedeelte vast, terwijl de rest aan de hand hiervan wordenbepaald. Zie voor een schematisch overzicht de onderstaandefiguur.

Wijze van .. Model- Onder-Werken leren Besturen steunen Denken

Strategie

Ober V B B B IReferentie B B V B VOntwikkel B V V B IEvolutie V B V B I

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 ontwikkelproces. Allereerst spelen zij de rol van een tussenliggendefase tussen de initiële, informele specificatie en deuiteindelijke, uitvoerbare implementatie. Een tweede rol diezij spelen is de rol van formeel referentie document, wat desysteem vereisten beschrijft.

3.5.1 Formele representatie als tussenliggende stap

De initiële representatie moet worden uitgedrukt in een taaldie zo dicht mogelijk bij de taal van de gebruiker ligt,zonder gebruik te maken van computer georiënteerdeuitdrukkingen. De uiteindelijke representatie is een formeelInformatie Systeem, dat aan de gespecificeerde eisen voldoet.Het verschil tussen deze twee representaties is te groot omhet in algemeenheid in één keer op te lossen.Zodra er een formele representatie is, moet deze gevalideerdworden. Een effectief validatie proces moet de inhoud van deformele specificatie vertalen naar de gebruiker, zodat hetvoor de gebruiker duidelijk is, wat er gespecificeerd is. Duselk van de formele tussenfasen moet een duidelijke verbandaangeven met de initiële representatie.Deze tussenliggende fasen moeten bij elkaar compleet zijn,zodat de programmeur geen arbitraire beslissingen meer hoeftte nemen.

19

3.5.2 Formele representatie als referentie document

Formele representaties leveren een consistentie envisualiseerbaarheid gedurende het ontwerp proces. Het bevat deeisen van de gebruiker en een ontwerp dat hieraan voldoet. Aaniedere formele representatie in het ontwerp proces moet devolgende vraag worden gesteld. Hoe betrouwbaar kunnen deformele specificaties worden geïmplementeerd en gevalideerd.Ofwel: Kunnen de specificaties rechtstreeks wordengeïmplementeerd, of moet de programmeur nog terug naargebruiker? Begrijpt de gebruiker de inhoud van despecificaties werkelijk om te beslissen of ze voldoen aan zijnvereisten?

3.5.3 Soorten documentatie

Er bestaan verschillende soorten documenten, die opverschillende wijzen worden gemaakt. Allereerst zijn er deessentiële ontwerp documenten. Deze worden direct gemaakt, alseen resultaat van een ontwerp of analyse activiteit en dieworden gebruikt als invoer verder in het proces. Verder zijner de niet essentiële ontwerp documenten. Deze worden gemaaktals een op zichzelf staande ontwerp activiteit, meestal nadatde ontwikkeling is afgerond.De essentiële documentatie representeert een betrouwbare basisvoor onderhoud en toekomstige wijzigingen. De tweede groepdocumentatie is lastig aan te passen en bevatten daardoorgemakkelijk redundantie of voortdurende onjuistheden.

3.5.4 Aanpassingen in Evolutionair Informatie Systeem.

Het is de bedoeling, dat het Informatie Systeem de informatiebehoefte van de organisatie vervult. Omdat de behoefte en deinformatie zelf verandert moet het Informatie Systeemaangepast 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 deorganisatie weergeeft. Hierbij dient er gecontroleerd teworden of de informatie betrouwbaar en consistent is.Aanpassingen bestaan hier gewoonlijk uit toevoeging,verwijdering of verandering (van delen) van informatie. Hetresultaat is een nieuwe toestand, waarbij de vorige toestandverloren gaat. Er is geen ondersteuning van het begrip tijd.Als gevolg hiervan kunnen vorige toestanden niet wordenteruggehaald. 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 correctetoestand van de organisatie weer. Elke gebeurtenis, ofwel elketoestandsverandering, in de organisatie heeft een aanpassingvan het Informatie Systeem als gevolg. Dit soort aanpassingenheet opslag van een gebeurtenis.Een andere mogelijkheid tot aanpassing is, dat de informatiedie afgeleid wordt van de opgeslagen gebeurtenissen niet, ofniet meer, correct is. Hier is een aanpassing nodig, om deafbeelding van de organisatie op het Informatie Systeem tecorrigeren. Zo’n soort aanpassing heet correctie. Hetverandert de opslag van een gebeurtenis die al eerder heeftplaatsgevonden.De laatste soort aanpassing die kan plaatsvinden is hetverwijderen van informatie. Het betreft hier een verzoek totverwijderen van informatie, bijvoorbeeld door de wet gegeven.

3.5.4.2.1 Opslag

Als er een gebeurtenis optreedt in de organisatie, dan moet ermet het Informatie Systeem gecommuniceerd worden door middelvan een aanpassingsverzoek. De gebeurtenis wordt afgebeelddoor het uitvoeren van dit verzoek. De aanpassing wordtuitgevoerd door een aantal elementaire overgangen. Er wordendrie soorten elementaire overgangen onderscheiden: geboorte,overlijden en verandering. Bij de eerste wordt een nieuwelement aan het applicatie model toegevoegd, bij de tweedewordt een element uit het applicatie model verwijderd terwijlbij de laatste er een overgang plaatsvindt van het ene naareen ander element in het applicatie model.Aangezien er geen informatie verloren mag gaan, wordt degeschiedenis van de applicatie model elementen bewaard, doorde veranderingen samen met de tijdstippen waarop dit gebeurtop te slaan.

3.5.4.2.2 Correctie

Een Informatie Systeem geeft de organisatie correct weer danen slechts dan, als er een isomorfisme bestaat tussen detoestanden in de organisatie en het Informatie Systeem. Het iseen vereiste, dat de afbeelding van de organisatie op hetInformatie Systeem elke gebeurtenis in de organisatieweergeeft als een gebeurtenis in het Informatie Systeem.Doordat het tijdstip waarop de gebeurtenis heeftplaatsgevonden wordt opgeslagen, is de volgorde van degebeurtenis af te leiden. Heeft er een foute opslagplaatsgevonden 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, omeen vorige toestand terug te halen. De operatie waar hiergebruik van wordt gemaakt is de roll back operator.

3.5.4.2.3 Vergeten

In de meeste gevallen zou een ideaal Informatie Systeem geeninformatie kwijtraken. Het kan echter gebeuren, dat er insommige gevallen, bijvoorbeeld om privacy redenen, informatiemoet worden vergeten. Dit mag echter niet leiden tot eensituatie, waarin andere informatie niet meer teruggehaald kanworden of inconsistent wordt.

3.6 De rol van grafische representaties

Grafische representaties kunnen verschillende voordelenhebben. Ze kunnen namelijk veel informatie in een compactevorm bevatten (één plaatje zegt meer dan 1000 woorden). Verderzijn grafische representaties intuïtief eenvoudig te begrijpenvoor gebruikers.

3.6.1 Uitdrukkingskracht en compleetheid

Met de uitdrukkingskracht wordt aangegeven of elke formelecategorie van de onderliggende specificatie uitgedrukt kanworden. Met de compleetheid wordt aangegeven of het diagramalle onderliggende specificaties weergeeft.Het blijkt echter, dat geen enkele overzichtelijke grafischerepresentatie compleet is. Stel een representatie is compleeten overzichtelijk, dus elke beperking wordt hierinweergegeven, dan betekent dit dat het niet meer overzichtelijken dus niet meer eenvoudig begrijpbaar is.

3.6.1.1 Soorten incompleetheid

Er bestaan verschillende soorten van incompleetheid.Allereerst is er veilige incompleetheid. Elke bevolkbareconstructor kan worden weergegeven in het diagram, maar nietelke beperking heeft een representatie. Het is dus compleet inde zin, dat het alle soorten informatie die opgeslagen moetenkunnen worden representeert, maar dat het niet elke beperkingop de populatie representeert.Met andere woorden de grafische specificatie staat bepaaldeimplementaties toe die voldoen aan de gebruikers informatievereisten, maar het staat ook implementaties toe die niet aande gebruikers eisen voldoen.

22

Daarnaast bestaat er onveilige incompleetheid. Deze geeft nochelke bevolkbare constructor, noch elke beperking weer. Hierinkunnen dus ook niet-legale database toestanden voorkomen.

3.6.1.2 Relatie veilige en onveilige incompleetheid

Bij de geïmplementeerde database toestanden, die toegestaanzijn door de gebruiker en door de specificaties, kan veiligeen onveilige compleetheid bestaan. Hiertussen bestaat devolgende relatie.Elke database toestand die de gebruiker wenst, kan wordenweergegeven door een veilige incomplete grafische taal.Bepaalde database toestanden die de gebruiker wenst uit tesluiten kunnen worden toegestaan in een veilige incompletegrafische taal.Bepaalde database toestanden die de gebruiker wenst, kunnenworden weergegeven in een onveilige incomplete grafische taal.Bepaalde database toestanden die de gebruiker wenst, kunnenniet worden weergegeven in een onveilige incomplete grafischetaal.Bepaalde database toestanden die de gebruiker wenst uit tesluiten, kunnen niet worden weergegeven in een onveiligeincomplete grafische taal.

Afbeelding 3:Soorten DB toestanden

23

3.6.2 Begrijpbaarheid

Met begrijpbaarheid wordt aangegeven of de gebruiker debedoeling van het diagram begrijpt. Diagrammen kunnen eenabstracte, formele specificatie weergeven aan de gebruiker.Als de gebruiker getraind is om deze diagrammen te begrijpen,dan zijn de diagrammen een effectieve manier om despecificaties weer te geven. Dit is slechts zelden het geval.Als gevolg hiervan kunnen de diagrammen alleen alstoevoegingen worden bijgevoegd.

3.7 Beheersing van de ontwikkeling

De ontwikkeling van een Informatie Systeem is een omvangrijketaak. Het is hierbij van belang, dat de ontwikkelingbeheersbaar blijft.Deze beheersing kan op verschillende manieren wordenverwezenlijkt.

3.7.1 Beheersen door faseren

Doel van de faseringen van het ontwikkelen van informatiesystemen is het aanbrengen van duidelijke mijlpalen. Elke fasedient daarbij te worden afgesloten met een goede documentatie,waarin de bereikte resultaten en de vervolgstappen wordenvastgelegd. Dit levert een doelmatige besturing van hetontwikkel proces.

3.7.2 Beheersen door documenteren

Om de ontwikkeling beheersbaar te houden wordt er tijdens deontwikkeling en het onderhoud diverse soorten documentatiegeproduceerd. Tussen de verschillende soorten documentatiebestaat verschil in gebruiksduur van de documentatie enverschil in de doelstelling van de documentatie.

3.7.2.1 Systeem documentatie

Deze omvat de beschrijvingen die direct te maken hebben methet geautomatiseerde Informatie Systeem. Het doel van desysteem documentatie is het verschaffen van inzicht voor niet-direct betrokkenen en het verschaffen van een handleiding voorhet gebruik en het beheer van het Informatie Systeem.Het gedeelte, voor de niet-direct betrokkenen, bestaat uit eenglobale beschrijving.Het handleiding gedeelte is veel uitgebreider en verschilt percategorie van betrokkenen.

24

3.7.2.2 Ontwerp documentatie

Deze omvat alle inhoudelijke beschrijvingen van het InformatieSysteem, zoals dat tijdens de ontwikkeling tot stand isgekomen. Het is dus een ’databank’ van ontwerpalternatieven.

3.7.2.3 Project management documentatie

Deze omvat alle gegevens met betrekking tot het beheersen vanhet project. Het doel van deze documentatie is het leveren vanzinvolle 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 eenprojectmatige manier. Hierbij construeert men een projectorganisatie als een samenwerkingsverband tussen personen uitdiverse afdelingen van de organisatie, eventueel aangevuld metexterne personen. De project organisatie bestaat uitverschillende groepen.

Afbeelding 4:De project organisatie

25

3.7.3.1 De beleidsgroep

De beleidsgroep geeft algemene richtlijnen voor deontwikkeling van alle informatie systemen en controleert denaleving 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 inspecifieke doelen en taken voor een bepaald Informatie Systeemen verzorgt de coördinatie van de onder haar groepressorterende projectgroepen. De stuurgroep bestaat uit demanagers van de afdelingen waarvoor het Informatie Systeembedoeld is, aangevuld met de projectleiders.

3.7.3.3 De projectgroep

De projectgroep zorgt voor het ontwerp, de bouw, de invoeringen de nazorg van het betreffende Informatie Systeem. Deprojectgroep groep bestaat uit een projectleider, medewerkersuit de organisatie, eventueel aangevuld met externe mede-werkers (adviesbureaus, softwarehuizen e.d.).

3.7.3.4 Eisen aan de project organisatie

Om de projectorganisatie een kans van slagen te geven, moet eraan verschillende voorwaarden worden voldaan.Als eerste moet er een goede organisatie structuur zijn. Dithoudt in, dat de organisatie moet beschikken over een goedopgezette organisatie met duidelijke afspraken over taken,verantwoordelijkheden en beslissingsbevoegdheden om deverschillende partijen op een gecoördineerde manier te latensamenwerken.Verder moeten er goede procedures geformuleerd zijn. Deze zijnnodig om aan te geven op welke wijze de tijdsbesteding van dediverse medewerkers vastgesteld en bewaakt wordt, hoeconflicten moeten worden opgelost en hoe er moet wordengerapporteerd.Vervolgens moet er over goed personeel worden beschikt. Erzijn mensen nodig, die op niveau de verschillende disciplineskunnen vertegenwoordigen. Als laatste moet het juisteveranderingsklimaat binnen de organisatie aanwezig zijn. Demensen binnen de organisatie moeten overtuigd zijn van denoodzaak van de verandering en ze moeten vertrouwen hebben inde 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 vande vereisten in de gevraagde invoer taal?

* Kan de Informatie Systeem ontwerper de initiële vereistenbetrouwbaar interpreteren in termen van een formeelrepresentatie schema, gegeven door de Informatie Systeemontwikkelmethode?

Aan de formele ontwerp representaties, die worden gebruikttijdens het ontwerp proces, kunnen de volgende sleutelvragenworden gesteld.

* Is de formele representatie precies genoeg om direct teworden geïmplementeerd?

* Is de formele representatie begrijpbaar genoeg omeffectief gevalideerd te worden door de gebruiker?

Voor de representatie schema’s kunnen de volgendealternatieven gesteld worden. Deze alternatieven worden hiernabesproken, waarna ze worden geverifieerd aan de hand vanbovenstaande 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 informatievereisten te beschrijven in een op normalisatie gebaseerdontwikkel aanpak. Normalisatie vereist dat de initiële invoerwordt uitgedrukt als een verzameling record typen (relatieen/of entiteit typen), die samengesteld zijn uit velden en eenspecificatie van wiskundige afhankelijkheden tussen de veldenonderling.

3.8.1.1 Doel van normalisatie

Het doel van normalisatie is, om het initiële tabel ontwerp omte zetten in een aantal kleinere goede tabel ontwerpen. Devraag die hierbij rijst is de volgende. Kan de gebruikerbetrouwbare informatie verschaffen over het applicatie domein,als het in zo’n vorm uitgedrukt moet worden?Het blijkt, dat als de gebruiker geen (geschikte) uitvoerrapporten heeft, het lastig voor de gebruiker is om devereisten uit te drukken. Omdat de normalisatie vereist dat deinvoer uitgedrukt wordt in een computer georiënteerde taal, iser geen formele invoer definitie. Hierdoor moet de gebruikerdit doen zonder enige assistentie van de normalisatie ontwerpprocedure.

27

Verder gaat de normalisatie er vanuit, dat de initiële’slechte’ tabellen significant en compleet zijn. Het grotenadeel is, dat de initiële tabellen nergens wordengevalideerd.Normalisatie dient slechts als een ontwerp procedure in pogingde initiële tabellen te verbeteren. De normalisatie verwacht,dat de afhankelijkheden tussen de tabellen wordengedefinieerd. Er blijkt echter dat geen van de partijen instaat zijn dit te doen. Het is namelijk zo dat de ontwerper devereiste applicatie kennis mist, de gebruiker niet over deonderlinge verbanden beschikt in zijn natuurlijke taal. Verderis het ook niet in zijn algemeenheid te stellen, dat hetafleidbaar 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 degebruiker 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 derepresentatie van de belangrijke feiten in hettoepassingsgebied als een verzameling relationele tabellenweer te geven. Dit betekent, dat de gebruiker in staat is tecontroleren dat deze verzameling tabellen de informatievereisten definieert. Verder houdt het in dat de gebruiker deafhankelijkheden kan definiëren en valideren. Dit betekentweer, dat de gebruiker de volgende vaardigheden bezit.Het impliciet representeren van kennis van de semantiek van deinformatie in het toepassingsgebied als een verzamelingwiskundige afhankelijkheden tussen de kolommen van derelationele tabellen en controleren dat deze afhankelijkhedende informatie vereisten definieert. Verder is het zo dat ditalles moet plaatsvinden voordat er aan de normalisatiebegonnen wordt. Tijdens de normalisatie is er geen enkelevalidatie meer mogelijk. Een fout aan het begin werkt dus hethele proces door. De kwaliteit van de normalisatie ligt dus inde kwaliteit van het proces dat aan de normalisatievoorafgaat.

3.8.1.3 Verificatie van de relationele strategie

Zetten we de bovenstaande eisen, die aan de gebruiker wordengesteld af tegen de sleutel vragen, dan volgt hieruit hetvolgende.De gemiddelde gebruiker is niet goed genoeg getraind om eenbetrouwbare specificatie te leveren en om deze specificatie tevalideren.Indien er een betrouwbare initiële formele bewering is, dankan de ontwerper deze betrouwbaar interpreteren en dan is dezebewering precies genoeg om deze direct te implementeren.

28

Bij deze representatie wordt de gebruiker buiten schotgehouden, omdat hij er te weinig van begrijpt. Hierdoor wordtde gebruiker pas vrij laat (tijdens de acceptatie procedure)bij het project betrokken, waardoor hij weinig werkelijkemedezeggenschap en inbreng heeft.

3.8.2 Verhalende specificaties

Verhalende specificaties worden gebruikt om de informatie ende functionele vereisten in vele Informatie Systeem ontwikkelmethoden te beschrijven. Het voordeel van deze representatieis, 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 manifesterenzijn, dat de verhalende beschrijving van de gebruiker van deinformatie vereisten een niet concrete beschrijving is en datde ontwerper de beschrijving moet interpreteren in een formelespecificatie taal.

3.8.2.1 Verificatie van de verhalende strategie

Zetten we dit af tegen de bovenstaande sleutel vragen, danvolgt hieruit het volgende.Het hangt van de vaardigheden van de gebruiker af, of degebruiker een betrouwbare specificatie kan leveren in degevraagde invoer taal. Het is voor de gemiddelde gebruikerlastig om expliciet op het type niveau te redeneren.De gemiddelde gebruiker beschikt niet over kennis om eencorrecte interpretatie van de verhalende beschrijving tegeven.De initiële representatie is niet formeel en kan dus nietdirect geïmplementeerd en gevalideerd worden. Dezerepresentatie zal eerst vertaald moeten worden in een formelebeschrijving.

3.8.3 Entiteit-Relatie diagrammen

Entiteit-Relatie diagrammen worden in veel Informatie Systeemontwikkelmethoden gebruikt om de informatie vereisten vast teleggen. Mogelijke uitgangspunten voor een ontwikkel strategiezijn, dat de gebruiker (zelf) het initiële ER diagram moetproduceren, of dat de gebruiker een initiële specificatie vande inhoud van het diagram produceert, maar de ontwerperconverteert dit tot een ER diagram.Het eerste uitgangspunt werkt zelden of nooit, want degebruiker beschikt niet over de vereiste kennis.Het tweede uitgangspunt levert de volgende mogelijkheden op.Ten eerste kan de gebruiker de initiële specificatie in eenverhalende specificatie maken. De nadelen hiervan zijnhiervoor al besproken.

29

Ten tweede kan de gebruiker de inhoud van het diagramspecificeren, door de relevante entiteit types, attributen enrelaties te specificeren. Dit is de meest gebruikelijkemethode. 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 ERmodel te begrijpen is cruciaal, of hij het initiële diagram nugemaakt heeft of niet.Om de initiële invoer te geven moet de gebruiker een abstracteformele representatie geven van het toepassingsgebied, waarbijimpliciet ook ontwerp beslissingen horen.Het is niet duidelijk welke feiten gemodelleerd moeten wordenals relaties en welke als attributen. Verder kan dit tijdenshet proces niet veranderen, wat instabiliteit met zichmeebrengt. Het is nog erger, dat het niet beschreven is,wanneer de uiteindelijke classificatie bereikt is en hetmigratie proces kan stoppen. De gebruiker moet een gekunsteldonderscheid maken tussen entiteit typen, relaties enattributen. Het bestaat niet in het toepassingsgebied en nietin de dagelijkse taal van de gebruiker.

3.8.3.1 Verificatie van de ER strategie

Zetten we deze representatie methode af tegen de sleutelvragen, dan volgt hieruit het volgende.De gemiddelde gebruiker kan de ER specificaties niet volledigbegrijpen en kan dus geen betrouwbare specificatie leveren.Hierdoor kan hij de representatie ook niet effectiefvalideren.De formele representatie is niet precies genoeg om directgeïmplementeerd te worden, omdat de ER specificatie incompleetis.Indien er sprake is van een specificatie in het ER model, dankunnen de vereisten betrouwbaar geïnterpreteerd worden.

3.8.4 Data Flow Diagrammen

Data Flow diagrammen zijn bedoeld om op een betrouwbare manierde gegevens stromen van het systeem weer te geven. Ze wordengebruikt om de formele gebruikers vereisten van de processenweer te geven. Om dit overzichtelijk te laten gebeuren wordthet hele systeem in deelsystemen opgedeeld. De processen opalle niveaus, behalve het laagste niveau, zijn abstracteprocessen. De actuele processen die geïmplementeerd moetenworden, zijn die op het laagste niveau.

30

3.8.4.1 Werkwijze

De gebruiker moet alle externe datastromen identificerentezamen met de relevante externe entiteiten. De analist kan nuhet initiële data-flow diagram tekenen, wat één proces bevat(het hele systeem) en een aantal data stromen. De gebruikeridentificeert nu alle relevante subprocessen, wat resulteertin het tweede niveau. Dit proces blijft zich herhalen totdathet onderste niveau bereikt is.

3.8.4.2 Verificatie van de DFD strategie

Zetten we deze representatie af tegen de sleutel vragen, danvolgt hieruit het volgende.Het is voor de gemiddelde gebruiker lastig om abstract teredeneren over de vereisten om ze vervolgens in een formeletaal weer te geven.Indien de initiële vereisten gespecificeerd zijn, dan kan deontwerper deze betrouwbaar interpreteren.De formele representatie is niet precies genoeg om directgeïmplementeerd te worden. Er moet hier eerst een tussenstapgemaakt worden. De processen zijn namelijk anoniem en moetenderhalve eerst geïdentificeerd worden, voordat zegeïmplementeerd kunnen worden.De DFD strategie is een grafische representatie van eenabstracte specificatie. Het is voor de gebruiker lastig omabstracte specificaties te valideren.

3.8.5 Toestandsovergang diagrammen

Toestandsovergang diagrammen worden gebruikt om tijdafhankelijk gedrag te specificeren. Het diagram geeft degrafische representatie van vier formele categorieën, namelijktoestanden, overgangen tussen toestanden, conditiesvoorafgaande aan overgangen, en acties die nieuwe toestand totgevolg hebben. Het gedeelte van de gebruikers eisen moeten intermen van deze categorieën gegeven worden.

3.8.5.1 Verificatie van de toestandsovergang strategie

Zetten we deze representatie af tegen de sleutel vragen, danvolgt hieruit het volgende.De gemiddelde gebruiker kan geen betrouwbare specificatieleveren in de gevraagde taal. Hij moet hier namelijk allemogelijke toestanden en hun onderlinge overgangen, tezamen metde condities en acties weergeven.Indien de vereisten formeel weergegeven zijn, dan is deinterpretatie van de ontwerper triviaal.

31

De formele representatie is niet precies genoeg omgedefinieerd te worden. De definitie van toestand is namelijkniet implementeerbaar. Elke toestand van het systeem is tevertalen naar een database toestand, maar deze liggen nietvast.De formele representatie is niet begrijpbaar genoeg omeffectief gevalideerd te worden. De gemiddelde gebruiker kannamelijk niet valideren of een abstractie op de juiste manierheeft plaatsgevonden.

3.8.6 Wiskundige grammatica’s

Er zijn verschillende soorten formele specificatie voorInformatie Systeem ontwikkeling. Allereerst zijn er despecificaties, die gebaseerd zijn op formele computer data-geheugen concepten. Voorbeelden hiervan zijn normalisatie enER modellering.Als tweede zijn er de formele specificaties, die gebaseerdzijn op de wiskunde van de eindige toestandsmachines.Voorbeeld hiervan is het toestandsovergang netwerk. Als derdezijn er de formele specificaties, die afgeleid worden vantaalkundige structuur representaties. Een voorbeeld hiervan isNIAM.Als laatste zijn er de formele specificaties, die afgeleidzijn van wiskundige logica of wiskundige grammatica’s. Dit iseen belangrijke klasse van formele specificaties.De wiskundige grammatica’s zijn ongeschikt als taalkundigebeschrijving van de complexe grammaticale structuur vannatuurlijke talen. De grootste toepassing vindt dan ook plaatsin de specificaties van datastructuren en in het ontwerp vanparseer algoritmen voor compilers.Verder wordt het gebruikt om de Data-Dictionary te definiëren.De Data-Dictionary is een lijst van alle data elementen diehet systeem gebruikt, tezamen met de toegestane groeperingenvan deze elementen. De Data-Dictionary is bedoeld als basisvoor een algeheel begrip van de data elementen tussenontwerpers en gebruikers.

3.8.6.1 Verificatie van de wiskundige grammatica

Zetten we het gebruik van de wiskundige grammatica’s af tegende sleutelvragen, dan volgt hieruit het volgende.De gemiddelde gebruiker mist de training om de vereisten ineen formele abstracte taal te specificeren en om derepresentatie effectief te valideren.Indien de formele eisen in het raamwerk zijn uitgedrukt, dankan de ontwerper ze betrouwbaar interpreteren.Zelfs als de formele representatie precies genoeg is om alsbasis te dienen voor de database specificatie, dan is het voorde gemiddelde programmeur lastig om ze als zodanig tegebruiken.

32

3.8.7 Data structuur diagrammen (Bachman Diagrammen)

Deze strategie is één van de oudste manieren om grafischerepresentaties te maken. Deze methode wordt nog steedsveelvuldig gebruikt. Het blijkt echter zo te zijn, dat de datastructuur diagrammen onveilig incompleet zijn.Elk record bestaat uit een aantal velden. Deze velden wordenniet getoond in het diagram en moeten dus tekstueel wordenvastgelegd.

3.8.7.1 Verificatie van de datastructuur diagrammen

Zetten we het gebruik van de datastructuur diagrammen af tegende sleutelvragen, dan volgt hieruit het volgende.De gemiddelde gebruiker kan zijn vereisten niet betrouwbaarvastleggen in een computer georiënteerd formalisme. Hij mistook de capaciteiten om de representatie effectief tevalideren.Indien de vereisten betrouwbaar zijn vastgelegd, dan is hetvoor de ontwerper triviaal om de specificaties op een juistemanier te interpreteren.De formele representatie is niet precies genoeg om direct teworden geïmplementeerd.De mogelijkheden van de specificatie isonveilig incompleet, dus er blijven teveel ’gaten’ over.

3.8.8 Voorbeelden uit het werk van de gebruiker

De gebruiker doet zijn werk dagelijks, dus hij komt dagelijksvoorbeelden tegen. Hij kent de betekenis van deze voorbeeldenen verder zijn ze voldoende aanwezig. De voorbeelden bevatteneen verzameling feiten, die de gebruiker wenst op te slaan.

3.8.8.1 Verificatie van de voorbeeld strategie

Zetten we het gebruik van de voorbeeld strategie af tegen desleutelvragen, dan volgt hieruit het volgende.De gebruiker kan een betrouwbare specificatie leveren. Hijhoeft er hier slechts voor te zorgen, dat een aantalrepresentatieve voorbeelden in zinnen worden omgezet.De ontwerper kan de initiële vereisten betrouwbaarinterpreteren 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 omtot een formele beschrijving te komen.

33

De formele representatie is precies genoeg om direct te wordengeïmplementeerd. Het resulterende conceptuele schema is eenexacte specificatie van alle typen die in het InformatieSysteem moeten worden opgenomen, tezamen met de constraintsdie bepalen wat voor acties er zijn toegestaan. Er is zelfseen formeel algoritme, dat zo’n conceptueel schema omzet ineen relationeel database schema in de vijfde normaalvorm,zonder tussenkomst van de gebruiker.De formele representatie is begrijpbaar genoeg om effectiefgevalideerd te worden door de gebruiker. De gestructureerdezinnen hebben een sterke overeenkomst met de alledaagse taalvan de gebruiker. Hij kan deze formele beschrijving dus goedbegrijpen.

3.8.9 Conclusie

Uit de bovenstaande figuur blijkt hoe de externerepresentaties onderverdeeld zijn. De representaties in denatuurlijke taal kunnen concreet (bijv. ’Verbaliserendevoorbeelden’) of abstract (bijv. ’Vertellende beschrijvingen’)zijn. Uit de verificatie blijkt, dat hiervan alleen deverbaliserende voorbeelden voldoen.

34

De formele representaties hebben een diepere hiërarchie,waarbij er geen voorbeelden zijn van de concrete. Ditzelfdegeldt voor de complete grafische representaties.Uit de verificatie blijkt, dat geen van de abstracte formelerepresentaties voldoet, omdat de gemiddelde gebruiker hiervoorniet genoeg getraind is. Een deel van de representaties iszelfs onveilig incompleet.Is er sprake van een project, waarbij gebruikers zijnbetrokken, die deze formele representatie wel beheersen, danvoldoen de representaties, die niet onveilig incompleet zijn.

3.9 IS ontwikkeling in evoluerende organisaties

De organisatie verandert vaak en snel, dus er is vraag naareen doelmatige strategie om de door het Informatie Systeemgeleverde informatie te laten aansluiten op de informatiebehoefte. Een oplossing hiervoor is het verkorten ofveranderen van het levenscyclus proces.De levensverwachting van een Informatie Systeem kan wordenvergroot door bij het ontwerp en ontwikkeling de produkten inde levenscyclus geschikt te maken voor hergebruik. Produktendie met een CASE-tools zijn ontwikkeld (bijvoorbeeld analyseen/of ontwerp) kunnen als basis dienen voor het te ontwikkelenInformatie Systeem. De traditionele Informatie Systeemontwikkel strategie kan worden vervangen door een meerevolutionaire aanpak: De strategie van prototyping latendoorwerken tijdens onderhoud. Er is dan geen essentieelverschil meer tussen ontwikkeling en onderhoud. [FOP]

35

Afbeelding 6:De prototype benadering

Afbeelding 7:De evolutionaire aanpak

3.9.1 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 ontwerperte ondersteunen bij het ontwikkelen van software. Case toolsvoor Informatie Systeem ontwikkeling zijn nauw verbonden metde Informatie Systeem ontwikkel methoden. Het levertautomatische ondersteuning voor het gebruik van een methode.De Case tool kan verschillende functies vervullen. Ten eerstekan de Case tool automatisch uitvoerbare code genereren. Dezecode is van een formeel, hoog niveau. Vervolgens kan de Casetool de definitie, opslag en modificatie van verschillendeformele grafische representaties (Data Flow, ER) ondersteunen.Ook het automatische genereren van de bijbehorende ontwerpdocumentatie van een opgeslagen formele specificatie hoort bijde functies die de Case tool kan vervullen.De volgende functie die de Case tool kan vervullen is deanalyse van de opgeslagen formele specificaties voor decontrole op syntactische fouten. Syntactische kruiscontrolevan de verschillende opgeslagen formele specificaties(compatibiliteit) hoort hier ook bij.

36

Als laatste kan de Case tool ondersteuning geven bij hetgenereren en het maken van een prototype van alternatieveontwerpen van een formele specificatie.Er zijn twee soorten Case tools: De upper-case en de lower-case. De eerste geeft ondersteuning voor de processen van devereiste specificatie, validatie en ontwerp. Het tweede geeftondersteuning voor de processen van software ontwikkeling,implementatie en verificatie, met betrekking tot despecificaties.

3.9.2 Architectuur voor een IS

Uit de bestaande Informatie Systemen kunnen we de architectuurafleiden, wat een basismodel van een geautomatiseerdInformatie Systeem levert. Er is het conceptueel schema. Ditbevat de formele specificatie van de feiten die opgeslagenkunnen worden in Database.Daarnaast is er de informatie processor. Dit is een actieveprocessor die berichten accepteert van de omgeving(bijvoorbeeld van gebruikers en eventueel andere InformatieSystemen), deze berichten controleert volgens het conceptueleschema, goedgekeurde boodschappen doorvoert in de database enberichten teruggeeft aan de gebruiker. De database is deopslagplaats van alle feiten die in Informatie Systeem zijnopgeslagen.De huidige inhoud van database moet op elk tijdstip voldoenaan de eisen van het conceptuele schema.Als laatste is er de program base. Deze bevat programma’s(proces definities), die uitgevoerd kunnen worden door deinformatie processor.De Program Base is onder te verdelen in de Event Base en deProces Description Base. De Event Base bevat iederegebeurtenis, die de oorzaak van het uitvoeren van een proceskan veroorzaken. De Proces Description Base bevat debeschrijving van alle processen die door een gebeurtenisgetriggered 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 organisatiesysteem uit een verzameling onderling verbonden actoren,activiteiten, toestanden en tijdstippen. Actoren voeren actiesuit, wat resulteert in een toestandsverandering op een bepaaldtijdstip. Een informatie realisatie systeem kan gedefinieerdworden als een geformaliseerd subsysteem van een organisatiesysteem.De Informatie Systemen die hier van belang zijn, zijn beperkttot die Informatie Systemen, waar de actor die de informatieprocessen uitvoert is geautomatiseerd. Deze actor, deinformatie processor, kan uit verschillende sub-processorenbestaan.

38

Afbeelding 9:Architectuur van het EIS

De informatie processor accepteert invoer berichten(verzoeken), die toestandsveranderingen tot gevolg kunnenhebben in de Universe of Discourse, en de informatie processoraanzet tot het uitvoeren van activiteiten. Als resultaat vandeze activiteiten kan de informatie processor uitvoerberichten produceren (antwoorden).De beschrijving van dat deel van het Informatie Systeem, datgeconsulteerd wordt door de informatie processor, heet hetprocessing model. De verzoeken van de gebruiker worden hierniet bijgerekend.Het processing model wordt onderverdeeld in eenapplicatiemodel en een metamodel. Het applicatiemodelbeschrijft een specifiek Universe of Discourse, terwijl hetmetamodel de taal (techniek) beschrijft, waarin hetapplicatiemodel is gespecificeerd en waarin hetapplicatiemodel gemanipuleerd kan worden. Het metamodel bevatde beschrijving van een classificatie van de domein elementen,algemene regels over deze elementen, hun gedrag en hoe zekunnen worden behandeld.

39

Afbeelding 10: Structuurvan het applicatie model

Afbeelding 11:Model eigenschappen

Het metamodel is applicatie onafhankelijk en tijd-invariant.Het applicatie model echter is applicatie afhankelijk en kantijd-variant zijn. Als resultaat hiervan wordt het metamodelin een Informatie Systeem eenmalig geïmplementeerd, terwijlhet applicatiemodel opgebouwd en onderhouden moet worden voorelke nieuwe applicatie.Het opbouwen en onderhouden van het applicatiemodel wordt doorde informatie processor gedaan, die handelt of reageert opgebeurtenissen in de Universe of Discourse door middel van hetraadplegen van het metamodel en van het applicatiemodel. Hetapplicatie model is dus, in tegenstelling tot het metamodel,niet alleen input, maar ook uitvoer van de activiteiten van deinformatie processor.Buiten het bijwerken van het applicatiemodel kan ookinformatie worden verkregen uit het applicatiemodel. De taalwaarin berichten geformuleerd worden, worden afgeleid uit hetmetamodel. [FOP]

40

Het applicatiemodel kan worden onderverdeeld in eenwereldmodel en een actiemodel.Het wereldmodel modelleert de interactie tussen het InformatieSysteem en de omgeving (Universe of Discourse). Het kan wordenbeschreven in modelleringstechnieken, zoals ER, NIAM of PSM.Het actiemodel specificeert de regels die de acties van deinformatie processor bepaalt. Het actiemodel kan weer wordenonderverdeeld in een activiteiten model en een gedragsmodel.Het activiteiten model specificeert de activiteiten en hetgedragsmodel beschrijft de relaties tussen het activiteitenmodel en het wereldmodel.Met andere woorden: Het gedragsmodel beschrijft de ’wanneer’activiteiten, onder welke condities, en welke activiteitendoor de information processor moeten worden uitgevoerd,terwijl het activiteiten model specificeert ’hoe’ dezeactiviteiten moeten worden uitgevoerd.Modellerings technieken voor het activiteiten model zijn DFD-diagrammen, activiteiten schema’s in ISAC. Modelleringstechnieken voor het gedragsmodel zijn petrinetten en When-If-Then regels in Remora.

41

3.9.4 Verschil tussen IS en EIS

Op basis van deze architectuur kan het verschil tussen hettraditionele Informatie Systeem en het Evolutionair InformatieSysteem meer specifiek worden beschreven. In een traditioneelInformatie Systeem, waar het schema (type) versus instantieonderscheid is aangebracht in het applicatie model, kunnenalleen de instanties bijgewerkt worden. Dus noch de schemaspecificaties, noch de activiteiten en gedrag specificaties,die verborgen zijn in de programma procedures, kunnenbijgewerkt worden in het traditionele Informatie Systeem. Deintentie van het Evolutionair Informatie Systeem daarentegenis dat het complete applicatie model aanpasbaar is. Gegevenhet metamodel van een Evolutionair Informatie Systeem kan eensoftware omgeving worden ontwikkeld, dat tijd-invariant enonafhankelijk van elk Universe of Discourse is. Zo’n omgevingheet een Evolutionair Informatie Systeem shell. Wanneer eenEvolutionair Informatie Systeem moet worden ontwikkeld vooreen specifiek Universe of Discourse wordt een applicatiemodel, dat dit domein beschrijft, ontwikkeld en onderhoudenconform de taal die is gedefinieerd in het (metamodel van de)Evolutionair Informatie Systeem shell.De Evolutionair Informatie Systeem shell moet dus wordenontworpen zodanig dat het onafhankelijk is van elke softwareomgeving en dus onafhankelijk van elke Database managementsysteem en/of operating system.

Afbeelding 12: EIS-shell

42

4 Het proces in detail

4.1 Inleiding

In dit hoofdstuk worden de verschillende onderdelen uithoofdstuk 3 gemodelleerd, aan de hand van de beschrijvingenvan het vorige hoofdstuk. Hierbij wordt het evolutionaireaspect en de case tools buiten beschouwing gelaten. Hetevolutionaire aspect wordt buiten beschouwing gelaten, omdathet evolutionaire aspect onafhankelijk is van de te kiezenontwikkelmethode. De case tools, die de diverseontwikkelmethoden ondersteunen, worden buiten beschouwinggelaten, omdat eerst bepaald moet worden welke methodenvoldoen. Daarna kan er gebruik gemaakt worden van een bepaaldecase tool, als deze beschikbaar is.

4.2 Gemodelleerde beschrijving

De verschillende onderdelen uit het vorige hoofdstuk zijnformeel uit te drukken aan de hand van NIAM schema’s. Het doelvan de NIAM schema’s is het overzichtelijk weergeven van deonderlinge verbanden. De NIAM schema’s zijn vervolgens weeruit te drukken in zinnen, in plaats van de veelal gebruiktetabellen. Aan de hand van deze zinnen kan er een verbandgelegd worden tussen de formele taal en de experttaal. Verderkunnen er uit deze zinnen eigenschappen worden afgeleid in devorm van axioma’s, waar weer lemma’s en strategieën uit kunnenvolgen.In dit hoofdstuk worden, bij de beschrijving in de formeletaal en bij de bewijsvoering de volgende notaties gebruikt:

Æ Voor alle= Is gelijk aan«» Is ongelijk aan∩ Doorsnedeφ Lege verzameling§ ParagraafE Er is eenε Is element van

≡ Per definitie ===> Implicatieor Logische ofand Logische en¬ Logische not[Ai] Axioma i[Li] Lemma i

De ’i’ bij de axioma’s en de lemma’s staan voor het nummer vanhet axioma resp. lemma in de paragraaf.

43

4.2.1 Strategieën en hun methoden

1. heeft_grotere_mate_van_onzekerheid_dan

2. heeft_kleinere_mate_van_onzekerheid_dan

3. wordt_gebruikt_door4. maakt_gebruik_van5. is_oberstrategie6. is_referentie_strategie7. is_evolutionaire_

strategie8. is_ontwikkel_strategie

Het bepalen van de informatie behoefte is ingewikkeld.Derhalve zijn er in de loop der jaren verschillendestrategieën ontwikkeld om de informatie behoefte te bepalen,die onderling verschillen in de mate van onzekerheid. Aan dehand hiervan kan een rangschikking gemaakt worden tussen deverschillende strategieën. In de bovenstaande figuur wordt hetverschil in onzekerheid tussen de verschillende strategieënweergegeven door de binaire relatie <1,2> (= heeft_grotere_mate_van_onzekerheid, heeft_kleinere_mate_van_onzekerheid)over Strategie. Voor deze relatie kunnen diverse eigenschappenworden afgeleid, die in de volgende paragrafen wordenbesproken.De verschillende strategieën sluiten elkaar onderling uit.Deze eigenschap wordt weergegeven door het volgende axioma:

[A1] Oberstrategie ∩ Referentie Strategie ∩ OntwikkelStrategie ∩ Evolutie Strategie = φ.

44

4.2.1.1 De groter_dan relatie

De verschillende strategieën zijn met elkaar te vergelijken opgrond van de mate van onzekerheid van de desbetreffendestrategieën.De eerste eigenschap van de groter_dan relatie is, dat eenstrategie niet idempotief is: Een strategie kan niet metzichzelf vergeleken worden op grond deze relatie. Dezeeigenschap wordt tot uitdrukking gebracht in het volgendeaxioma:

[A2] ¬ (Strategie X heeft_een_grotere_mate_van_onzekerheid_danStrategie X).

Vervolgens moet ook de transitieve eigenschap gelden: Als degroter_dan relatie tussen de strategieën X en Y en tussen destrategieën Y en Z geldt, dan geldt deze relatie ook tussen destrategieën X en Z. Deze eigenschap wordt tot uitdrukkinggebracht in het volgende axioma:

[A3] Strategie X heeft_een_grotere_mate_van_onzekerheid_danStrategie Y and Strategie Y heeft_een_grotere_mate_van_onzekerheid_dan Strategie Z ==>Strategie X heeft_een_grotere_mate_van_onzekerheid_danStrategie 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 totuitdrukking in het volgende axioma:

[A4] ¬ (Strategie X heeft_een_grotere_mate_van_onzekerheid_danStrategie Y and Strategie Y heeft_een_grotere_mate_van_onzekerheid_dan Strategie X).

Als laatste moet bij de groter-dan relatie gelden, dat allevan elkaar verschillende strategieën met elkaar vergelekenmoeten kunnen worden op grond van deze relatie. Dezeeigenschap wordt door het volgende axioma weergegeven:

[A5] Æ X,Y : Strategie X «» Strategie Y ==>Strategie X heeft_een_grotere_mate_van_onzekerheid_danStrategie 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_danrelatie: Ze zijn elkaars inverse. Deze eigenschap wordt doorhet volgende axioma weergegeven:

[A6] Strategie X heeft_een_grotere_mate_van_onzekerheid_danStrategie Y <==>

Strategie Y heeft_een_kleinere_mate_van_onzekerheid_dan Strategie X.

Analoog aan de beschreven eigenschappen voor de groter_danrelatie kunnen eigenschappen beschreven worden voor dekleiner_dan relatie.Allereerst moet er gelden dat de kleiner_dan relatie nietidempotief is. Deze eigenschap wordt door het volgende lemmaweergegeven:

[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_danStrategie 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 relatietransitief is. Deze eigenschap wordt door het volgende lemmaweergegeven:

[L2] Strategie X heeft_een_kleinere_mate_van_onzekerheid_danStrategie Y and Strategie Y heeft_een_kleinere_mate_van_onzekerheid_dan Strategie Z ==>

Strategie X heeft_een_kleinere_mate_van_onzekerheid_danStrategie 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_danStrategie 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_danStrategie X.

Vervolgens volgt uit axioma [A6]:Strategie X heeft_een_kleinere_mate_van_onzekerheid_danStrategie Z.

46

Vervolgens moet de eigenschap gelden, dat de kleiner_danrelatie niet reflexief is. Deze eigenschap wordt totuitdrukking 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 uitaxioma [A6]:

Strategie Y heeft_een_grotere_mate_van_onzekerheid_danStrategie 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 Yheeft_een_kleinere_mate_van_onzekerheid_danStrategie X).

Als laatste moet er gelden, dat alle van elkaar verschillendestrategieën met elkaar vergeleken moeten kunnen worden opgrond van de kleiner_dan relatie. Deze eigenschap wordt doorhet volgende lemma weergegeven:

[L4] Æ X,Y : Strategie X «» Strategie Y ==>Strategie X heeft_een_kleinere_mate_van_onzekerheid_danStrategie 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_danStrategie 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_danStrategie 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 deinformatie behoefte te bepalen. In de figuur aan het begin vandeze paragraaf komt dit tot uiting in de relatie <3,4> (=wordt_gebruikt_door, maakt_gebruik_van) tussen Methode enStrategie.Aan de hand van de hiervoor beschreven eigenschappen kan ereen ordening in de strategieën worden gegeven met betrekkingtot de mate van onzekerheid. Al deze strategieën zijnonafhankelijk van de gekozen Informatie Systeemontwikkelmethode. De keuze is echter wel afhankelijk van deorganisatie waarvoor het Informatie Systeem bedoeld is.Zoals in hoofdstuk 3 al beschreven is, is de ordening in demate van onzekerheid van de diverse strategieën afhankelijkvan de structureerbaarheid van de problemen, van het kennis-enervaringsniveau van de gebruiker en de ontwerper. Dezeafhankelijkheid levert het volgende diagram.

48

Om te bepalen welke strategie gekozen dient te worden om deinformatie behoefte te bepalen, moeten de strategieën wordendoorlopen, totdat er een strategie wordt gevonden die voldoet,en wel door te beginnen met de strategie met kleinste mate vanonzekerheid.Om te bepalen of een strategie voldoet dienen alle betrokkenfactoren te worden doorlopen. Met behulp van de axioma’s A2t/m A6 is de strategie met de minimale mate van onzekerheid tebepalen.Laat b ≡ Probleem te structureren

S ≡ Strategie met onzekerheid =min(onzekerheid van de strategieën)

if Automatiseerders voldoende deskundigand Gebruikers voldoende deskundigand b

then Hanteer S

Een strategie om te bepalen of de gebruiker en de ontwerpervoldoende deskundig zijn wordt in § 4.2.4 behandeld insamenhang met de te hanteren representatie technieken voorinformatie systeem ontwikkeling.

49

4.2.2 De rol van formele representatie

1. is_referentie_document2. bevat3. is_bevat_in4. levert5. wordt_geleverd_door6. begrijpt7. wordt_begrepen_door8. verband_wordt_aangegeven

_door9. geeft_verband_aan_met

Formele representaties spelen een dubbele rol in hetontwikkelproces, namelijk die van referentie document en dievan een tussenliggende representatie. Voor de formelerepresentaties geldt dat het of een referentie document is ofeen tussenliggende representatie is, dus niet beide. Dezeeigenschap 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 vande gebruiker. Dit komt in het bovenstaande schema tot uitingin de relatie <2,3> (= <bevat, is_bevat_in>) tussen FormeleRepresentatie en Eisen. Hierbij worden de eisen worden gegevendoor de gebruiker. Dit blijkt uit de relatie <4,5> (= <levert,wordt_geleverd_door>) tussen Gebruiker en Eisen. De gebruikeris in staat om elke formele representatie te valideren. Ditwordt gegeven door de relatie <6,7> (= <begrijpt, wordt_begrepen_door>) tussen Gebruiker en Formele Representatie.Vervolgens wordt het verband aangegeven tussen de formele ende niet-formele representatie. Dit komt in het schema totuiting in de relatie <8,9> (= <verband_wordt_aangegeven_door,geeft_verband_aan_met>) tussen Informele Probleem Specificatieen Formele Representatie.

50

De formele specificatie dient een voor de gebruiker duidelijkverband aan te geven met de informele probleem specificatie.Derhalve moet aan de volgende eigenschap worden voldaan: Deformele representatie geeft een voor de gebruiker duidelijkespecificatie. Deze eigenschap wordt door het volgende axiomaweergegeven:

[A3] Formele Representatie geeft_verband_aan_met InformeleProbleem Specificatie.

Als laatste bestaat er een relatie tussen de initiële niet-formele representatie en de gebruiker. Dit komt in het schematot uiting in de relatie <2,3> (= <bevat, is_bevat_in >)tussen Informele Probleem Specificatie en Eisen. Dezeeigenschap wordt door het volgende axioma weergegeven:

[A4] Informele Probleem Specificatie bevat Eisen.

De formele representatie bevat natuurlijk ook de eisen van degebruiker. Deze eigenschap wordt door het volgende lemmaweergegeven:

[L1] Formele Representatie bevat Eisen.Bewijs:

Uit de axioma’s [A3] en [A4] volgt:Formele Representatie geeft_verband_aan_met InformeleProbleem Specificatie bevat Eisen.

Dus: Formele Representatie bevat Eisen.

Definitie:Formele representatie ≡ Verzameling formele regels

Er kan nu een strategie worden opgesteld aan de hand waarvaner kan worden bepaald of het validatie proces naar behoren kanworden uitgevoerd.Laat FR = Formele Representatie

= {FR1, FR2, ..., FRn} waarbij FRi = formele regel.

if Gebruiker begrijpt FRthen Gebruiker kan FRi validerenelse Probleem: De representatie techniek voldoet niet.

Hierbij houdt het begrip ’Gebruiker begrijpt FR’ in, dat degebruiker de formele representatie voldoende beheerst, waarFRi deel van uit maakt.Om het probleem op te lossen kan er gekozen worden om degebruiker om of bij te scholen, of om een andere representatietechniek te kiezen. Voordat er besloten tot om- ofbijscholing, dient er te worden bepaald of deze scholinghaalbaar is.Een strategie om te bepalen of de gebruiker in staat geachtmoet worden, om de formele representatie te begrijpen en tevalideren wordt in § 4.2.4 behandeld in samenhang met de tehanteren representatie techniek voor informatie systeemontwikkeling.

51

4.2.3 De rol van grafische representaties

1. wordt_weergegeven_door2. geeft_weer3. wordt_uitgesloten_door4. sluit_uit5. is_gewenste_toestand6. is_tekstuele_

representatie7. is_complete_

representatie8. is_veilige_representatie

Representaties kunnen onderverdeeld worden in grafische entekstuele representaties. Voor de grafische representatiesgeldt, dat zij niet tekstueel zijn. Deze eigenschap wordt doorde volgende axioma’s weergegeven:

[A1] Grafisch ∩ Tekstueel = φ.

[A2] Grafisch or Tekstueel = Representatie.

De tekstuele representaties worden hier verder buitenbeschouwing gelaten. De grafische representaties kunnen weeronderverdeeld worden in complete en incomplete representaties.Hier geldt, dat de grafische representaties niet zowelcompleet als incompleet kunnen zijn. Deze eigenschap wordtdoor de volgende axioma’s weergegeven:

[A3] Incompleet ∩ Compleet = φ.

[A4] Incompleet or Compleet = Grafisch.

52

Het grote voordeel van grafische representaties is, dat dezeveel informatie overzichtelijk kunnen weergeven. Er geldthier, dat één plaatje meer zegt dan duizend woorden. Hetblijkt echter zo te zijn, dat geen enkele overzichtelijkegrafische representatie compleet is.De incomplete grafische representaties zijn weer onder teverdelen in veilige en onveilige representaties. Ook hiergeldt, dat de incomplete representaties niet zowel veilig alsonveilig kunnen zijn. Deze eigenschap wordt door de volgendeaxioma’s weergegeven:

[A5] Veilig ∩ Onveilig = φ.

[A6] Veilig or Onveilig = Incompleet.

Beide soorten incomplete representaties geven alle gewenstetoestanden weer, maar niet elke beperking op de populatie kanworden weergegeven. Deze eigenschap wordt in het bovenstaandeschema weergegeven door de relatie <1,2> (= <wordt_weergegeven_door, geeft_weer >) tussen Toestand en IncompleteRepresentatie. Deze eigenschap wordt door het volgende axiomaweergegeven:

[A7] Incomplete Representatie geeft_weer Toestand.

De toestanden kunnen worden onderverdeeld in gewenste enongewenste toestanden. Ook hier geldt, dat een toestand nietzowel gewenst als ongewenst kan zijn. Deze eigenschap wordtdoor de volgende axioma’s weergegeven:

[A8] Gewenst ∩ Ongewenst = φ.

[A9] Gewenst or Ongewenst = Toestand.

De veilige representaties sluiten, in tegenstelling tot deonveilige representaties, alle ongewenste toestanden uit. Dezeuitsluiting wordt in het bovenstaande schema weergegeven doorde relatie <3,4> (= <wordt_uitgesloten_door, sluit_uit >)tussen Toestand en Incomplete Representatie. Deze eigenschapwordt 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 ongewenstetoestanden uit. Als een incomplete representatie (veilig ofonveilig) een toestand uitsluit, dan is dit een ongewenstetoestand. Deze eigenschap wordt weergegeven door het volgendeaxioma:

[A11] ¬ (X is_complete_representatie) and X sluit_uit T ==>¬ (T is_gewenste_toestand).

53

Voor de toestanden geldt verder dat deze niet zoweluitgesloten als weergegeven kunnen worden. Deze eigenschapwordt door het volgende axioma weergegeven:

[A12] ¬ (E Incomplete Representatie R [R sluit_uit Toestand Tand R geeft_weer Toestand T] ).

Laat OT = Verzameling ongewenste toestanden= {OT1, OT2, ..., OTn}

R = Representatie

Voor de verzameling ongewenste toestanden moet gelden, dat eenrepresentatie deze verzameling uitsluit dan en slechts dan alsde representatie alle elementen van deze verzamelingafzonderlijk uitsluit. Deze eigenschap wordt door het volgendeaxioma weergegeven:

[A13] R sluit_uit OT <==> R sluit_uit OT1 and R sluit_uitOT2 and ... and R sluit_uit OTn.

Er kan nu een strategie opgesteld worden om te bepalen of eenrepresentatie 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 uitaxioma [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 ishet aan te raden deze toch te gebruiken, ook al kunnen dezeniet alles uitdrukken. Een minimale eis die hierbij gesteldmoet worden is, dat alle ongewenste toestanden uitgeslotenmoeten kunnen worden. Dit heeft tot gevolg, dat de onveiligegrafische representaties niet voldoen, dus dat alleen deveilige representaties voldoen. De incompleetheid van degrafische representaties kan worden opgevangen door hetuitbreiden van de grafische representaties met tekstueleaanvullingen.

54

4.2.4 Representatie technieken voor IS ontwikkeling

1. ondersteunt_betrouwbaar2. wordt_betrouwbaar_

ondersteund3. is_specificatie_van_

gebruiker4. is_implemeteerbare_

representatie5. is_interpretatie_

ontwerper6. is_wiskundige_grammatica

_strategie7. is_datastructuur_

strategie8. is_voorbeeld_strategie9. is_verhalende_strategie

10. is_toestandsovergang_strategie

11. is_relationeel_model_strategie

12. is_ER_strategie13. is_valideerbare_

expressie

4.2.4.1 Eigenschappen

Van de betrokkenen bij automatiseringsprojecten mag in alleredelijkheid worden verwacht, dat zij een bepaald basis niveauhebben om hun dagelijkse taak naar behoren uit kunnen voeren.

Definitie:Specificatie van de gebruiker ≡De gebruiker beheerst de techniek naar behoren om zijneisen te kunnen specificeren.

Implementeerbaarheid van de representatie ≡De formele representatie is precies genoeg om directgeïmplementeerd te worden, zonder tussenkomst van degebruiker.

Valideerbaarheid van de representatie ≡De representatie is begrijpbaar genoeg om door degebruiker te kunnen worden gevalideerd.

Interpretatie van de ontwerper ≡De ontwerper kan de initiële vereisten van de gebruikerbetrouwbaar interpreteren.

55

4.2.4.2 Verband eigenschappen - representatie

Het verband tussen de verschillende eigenschappen en derepresentatie technieken wordt gegeven door de relatie <1,2>(= <ondersteunt_betrouwbaar, wordt_betrouwbaar_ondersteund >)tussen Representatie Techniek en Eigenschap, waarbij elkerepresentatie techniek minstens één eigenschap ondersteunt.Deze eigenschap wordt door het volgende axioma weergegeven:

[A1] E E [ Representatie Techniek RT ondersteunt_betrouwbaarEigenschap E ].

Uit het vorige hoofdstuk valt af te leiden bij welkerepresentatie techniek aan welke eigenschap en aan welkeeigenschap niet wordt voldaan. Dit wordt in de volgende tabelweergegeven.

Repres. Specif. Implement. Valideerb. Interpr.Techniek Gebruiker Represent. Represent. Ontwerper

Rel. model Niet Direct Niet WelVerhalend Niet Indirect Niet NietER Niet Niet Niet WelDFD Niet Indirect Niet WelToest. overg. Niet Indirect Niet WelWisk. gramm. Niet Niet Niet WelData struct. Niet Niet Niet WelVoorb. strat. Wel Direct Wel Wel

Uit deze tabel kunnen verschillende eigenschappen wordenafgeleid. Aan de eigenschap specificatie van de gebruikerwordt alleen voldaan bij de verbaliserende voorbeelden. Dezeeigenschap wordt door het volgende axioma beschreven:

[A2] Representatie Techniek RT ondersteunt_betrouwbaar E andE is_specificatie_gebruiker ==>

RT = Verbaliserende Voorbeelden.

Aan de eigenschap implementeerbaarheid van de representatiewordt voldaan bij de verbaliserende voorbeelden en hetrelationeel model. Deze eigenschap wordt door het volgendeaxioma weergegeven:

[A3] Representatie Techniek RT ondersteunt_betrouwbaar E andE is_implementeerbare_representatie ==>

RT = Verbaliserende Voorbeelden ORRT = Relationeel Model.

56

Aan de eigenschap valideerbaarheid van de representatie wordtalleen voldaan bij de verbaliserende voorbeelden. Dezeeigenschap wordt door het volgende axioma weergegeven:

[A4] Representatie Techniek RT ondersteunt_betrouwbaar E andE is_valideerbare_representatie ==>

RT = Verbaliserende Voorbeelden.

Aan de eigenschap interpretatie van de ontwerper wordt alleenniet voldaan bij de verhalende strategie. Deze eigenschapwordt door het volgende axioma weergegeven:

[A5] Representatie Techniek RT ondersteunt_betrouwbaar E andE is_interpretatie_ontwerper ==>

RT ε {Relationeel Model, DFD, ER, Toestandsovergangen,Wiskundige Grammatica’s, Datastructuren, VerbaliserendeVoorbeelden}.

Een representatie techniek voldoet dan en slechts dan als aanalle beschreven eigenschappen (axioma’s A2 t/m A5) wordtvoldaan.

Definitie:Representatie Techniek RT voldoet <==>

A2 and A3 and A4 and A5.

Uit de bovenstaande axioma’s kan geconcludeerd worden, dat bijhet gestelde basisniveau van de betrokkenen slechts derepresentatie 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 eigenschapis_specificatie_van_gebruiker, dus RT = VerbaliserendeVoorbeelden (A2).

Er is gebleken, dat het niveau van de gebruiker en deontwerper een grote rol speelt, waarbij met name het niveauvan de gebruiker een beperkende factor is voor het voldoen vaneen representatie techniek.Tot nu toe is de aanname gemaakt, dat de gebruiker en deontwerper slechts een basisniveau hebben. Echter als hunniveau groter is dan het gestelde basisniveau, dan zal ditgevolgen hebben voor het voldoen van meerdere representatietechnieken. Als de eis dat een representatie techniek directimplementeerbaar moet zijn wordt verruimd, waardoor derepresentaties ook indirect implementeerbaar mogen zijn, danzal dit ook van invloed zijn op het aantal representatietechnieken die voldoen.Aan de hand van deze wetenschap is de volgende strategie op testellen 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 is van basisniveau.[E2]: De ontwerper is van basisniveau.[E3]: RT is direct implementeerbaar.[E4]: RT is direct of indirect implementeerbaar.

Indien de gebruiker van een hoger niveau is, dan het gesteldebasisniveau, dan zijn de te hanteren representatie techniekenmede afhankelijk van de technieken die de gebruiker beheerst.Deze eigenschap komt tot uitdrukking in het volgende axioma:

[A6] ¬ (De gebruiker is van basisniveau) ==> RGOfwel: ¬ E1 ==> RG.

Indien de ontwerper van een hoger niveau is dan het gesteldebasisniveau, dan zijn de te hanteren representatie techniekenmede afhankelijk van de technieken die de ontwerper beheerst.Deze eigenschap komt tot uitdrukking in het volgende axioma:

[A7] ¬ (De ontwerper is van basisniveau) ==> ROOfwel: ¬ E2 ==> RO.

Indien de eis vervalt dat een representatie niet alleen directimplementeerbaar hoeft te zijn, maar indirect implementeerbaarkan zijn, dan zijn er meer representatie technieken dievoldoen. Deze eigenschap wordt door het volgende axiomaweergegeven:

[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 Voorbeeldenelse if Ontwerper is van basisniveau and RT is direct

implementeerbaar(2) then RG and (Relationeel Model or Verbaliserende

Voorbeeldenelse if Ontwerper is van basisniveau and RT is

implementeerbaar(3) then RG and (Relationeel Model or DFD

Verbaliserende Voorbeelden orToestandsovergangen)

(4) else RG and RO and not (ER or WiskundigeGrammatica’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, VerbaliserendeVoorbeelden, Toestandsovergangen, DFD}

(4) Stel ¬[E1] and ¬[E2] and [E4], dan volgt uit [A6], [A7]en [A8]:

RG and RO and RT ε { Relationeel Model, VerhalendeBeschrijving, Toestandsovergangen, VerbaliserendeVoorbeelden, DFD}

59

4.2.5 De conceptuele informatie modellen

1. drukt_formeel_uit2. wordt_formeel_

uitgedrukt_door3. is_geschikt_voor4. is_modelleerbaar_door5. wordt_beschreven_door6. beschrijft7. is_systologisch8. is_datalogisch9. is_infologisch

Definitie:CIM ≡ Conceptueel Informatie Model.

De meest essentiële taak bij Informatie Systeem ontwikkelingis 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>) tussenCIM en de Informele Probleem Specificatie.

Als een model een Conceptueel Informatie Model is, dan is ditmodel of een Systologisch Model of een Datalogisch Model ofeen Infologisch Model of een Technisch Model, ofwel als eenmodel een CIM is, dan is het precies één van deze modellen.Deze eigenschap wordt door de volgende twee axioma’suitgedrukt:

[A1] Systologisch Model ∩ Infologisch Model ∩ DatalogischModel ∩ Technisch Model = φ.

[A2] Systologisch Model OR Infologisch Model OR DatalogischModel OR Technisch Model = CIM.

60

Uit de figuur blijkt vervolgens, dat de ontwikkelmethode hetconceptuele informatie model opstelt. Dit wordt weergegevendoor de relatie <3,4> (= <is_geschikt_voor, is_modelleerbaar_door>) tussen ISDM en Informele Probleem Specificatie. Deinformele vereisten, gegeven door de informele probleemspecificatie, worden formeel uitgedrukt door het conceptueleinformatie model, indien de informele probleem specificatiemodelleerbaar is door de ontwikkel methode. Deze eigenschappenworden door het volgende axioma weergegeven:

[A3] Aspecten worden_beschreven_door CIM drukt_formeel_uitInformele Probleem Specificatie is_modelleerbaar_doorISDM.

Een andere eigenschap die bij de laatste relatie moet geldenis dat elke informele probleem specificatie modelleerbaar isdoor een informatie systeem ontwikkelmethode. Deze eigenschapwordt 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 informeleprobleem specificatie uitgedrukt moet kunnen worden door eenCIM. Deze eigenschap wordt door het volgende axiomaweergegeven:

[A5] E C [ Informele Probleem Specificatie S wordt_formeel_uitgedrukt_door CIM C ]

Bij de ontwikkeling van een Informatie Systeem moet een grotemate van overeenstemming bestaan omtrent de relevant geachteconceptuele modellen. Wordt aan deze voorwaarde niet voldaan,dan is de kans op communicatie stoornissen groot. Er zijnverschillende soorten conceptuele modellen te onderscheiden,die elk een aantal aspecten beschrijven. In de bovenstaandefiguur wordt dit weergegeven door de relatie <5,6> (=<wordt_beschreven_door, beschrijft>) tussen Aspecten enConceptueel Informatie Model. Uit de populatie valt af teleiden welke soorten CIM welke aspecten beschrijven.

61

Hieruit volgt dat alle aspecten van de UoD kunnen wordenbeschreven, ofwel de UoD kan gemodelleerd worden. Bij dezemodelleerbaarheid kan een verband worden gelegd met de kosten.Dit is als volgt grafisch weer te geven:

1. kan_gemodelleerd_worden_door

2. geeft_modellering_voor3. heeft4. zijn_voor

Een UoD kan gemodelleerd worden door een ISDM. De systeemontwikkeling met behulp van een zekere ISDM heeft bepaaldekosten.

62

Iedere UoD is te beschrijven als een aantal bij elkaarbehorende kenmerken van de desbetreffende UoD. Ditresulteert 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 kenmerkenvan de UoD kan de volgende strategie voor de bepaling van dete kiezen methode geabstraheerd worden:

Bepaal de kenmerken van de UoD -> instantie van UoD-inschatting.if nieuwe instantie

then Probleem: ontwikkel procedure is onbekendelse selecteer ISDM met minimale ontwikkel kosten

Dit betekent, dat indien de kenmerken niet voorkomen in de UoDinschatting, dat er dan een nieuwe ontwikkel proceduregecreëerd moet worden. Bevat de UoD inschatting de kenmerkenwel, kies dan die methode waarbij deze kenmerken voorkomen enwaar de kosten minimaal zijn.

63

4.2.6 Beheersmethoden voor IS ontwikkeling

1. beheerst2. wordt_beheerst_door3. wordt_afgesloten_door4. sluit_af5. wordt_geleverd_door6. levert7. concretiseert8. wordt_geconcretiseerd_door9. geeft

10. wordt_gegeven_door11. volgt_op12. wordt_opgevolgd_door13. is_systeem_documentatie14. is_ontwerp_documentatie15. is_beleidsgroep16. is_stuurgroep17. is_fasering18. is_documentering19. is_project_organisering

Zoals in het vorige hoofdstuk is beschreven kan de beheersingvan de ontwikkelingsprojecten op verschillende manieren wordenverwezenlijkt.Dit komt in de bovenstaande figuur tot uiting in de relatie<1,2> (= beheerst, wordt_beheerst_door>) tussen Beheersmethodeen IS Ontwikkeling.

Beheersmethode wordt onderverdeeld in Fasering, Documenteringen Project Organisatie. Bij fasering wordt elke faseafgesloten door een document. Dit wordt weergegeven door derelatie <3,4> (= <wordt_afgesloten_door, sluit_af>) tussenFasering en Document. De documenten worden geleverd doordocumentering. Dit wordt weergegeven door de relatie <5,6> (=<wordt_geleverd_door,levert>) tussen Document enDocumentering. Document wordt onderverdeeld in Systeem,Ontwerp en Project. Deze eigenschap wordt door het volgendeaxioma weergegeven:

[A1] Fasering wordt_afgesloten_door Document wordt_geleverd_door Beheersmethode.

64

De project organisatie bestaat uit een beleidsgroep, eenstuurgroep en diverse project groepen. De beleidsgroep steltrichtlijnen op. Dit wordt weergegeven door de relatie <9,10>(= <geeft, wordt_gegeven_door>) tussen Beleidsgroep enRichtlijnen. 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 ennazorg. Dit wordt weergegeven door de relatie <11,12> (=<volgt_op, wordt_opgevolgd_door>) tussen Projectgroep enRichtlijnen. 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 wordeneerst door de stuurgroep geconcretiseerd, om vervolgens doorde projectgroep te worden opgevolgd. Deze eigenschap wordtdoor 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 uitOntwerpdocumentatie of uit Projectdocumentatie. Dezeeigenschap wordt weergegeven in de volgende axioma’s:

[A7] Systeem or Ontwerp or Project = Document

[A8] Systeem ∩ Ontwerp ∩ Project = φ

De project organisatie wordt gevormd door verschillendeproject- en stuurgroepen en door een beleidsgroep. Dit is alsvolgt te formuleren:

[A9] Beleidsgroep or Stuurgroep or Projectgroep = ProjectOrganisatie.

[A10] Beleidsgroep ∩ Stuurgroep ∩ Projectgroep = φ

65

4.2.7 Aanpassingen in het Informatie Systeem

1 . is_snapshot_systeem2 . vervult_informatie_

behoefte2’. informatie_behoefte_wordt_

vervuld_door3 . corrigeert3’. wordt_gecorrigeerd_door4 . vergeet4’. wordt_vergeten_door5 . geeft_weer5’. wordt_weergegeven_door6 . voegt_element_toe_aan6’. element_wordt_toegevoegd_

door7 . transformeert_element_in7’. element_wordt_

getransformeerd_door8 . element_wordt_verwijderd_

door8’. verwijdert_element_uit9 . wordt_aangepast_door9’. past_aan

10 . zorgt_voor_aanpassing_van11 . wordt_aangepast_o.i.v

Het traditionele en het evoluerende Informatie Systeem wordtin de bovenstaande figuur weergegeven door respectievelijkSnapshot Systeem en EIS. Er geldt hierbij, dat een InformatieSysteem of een snapshot systeem of een Evoluerend InformatieSysteem is. Deze eigenschap wordt door de volgende axioma’sweergegeven:

[A1] Snapshot Systeem OR EIS = IS.

[A2] Snapshot Systeem ∩ EIS = φ

Voor beide soorten Informatie Systeem geldt, dat de informatiebehoefte vervuld dient te worden. In de bovenstaande figuurwordt dit weergegeven door de relatie <2,2’> (= <vervult_informatie_behoefte, informatie_behoefte_wordt_vervuld_door>)tussen IS en Organisatie. Hierbij dient aan de volgendeeigenschap te worden voldaan: Elke informatie behoefte van deorganisatie wordt vervuld door het Informatie Systeem. Dezeeigenschap wordt door het volgende axioma weergegeven:

[A3] IS vervult_informatie_behoefte Organisatie.

66

Voor beide soorten Informatie Systemen geldt ook, dat deaanpassingen moeten resulteren in een toestandsverandering,zodanig dat de nieuwe toestand van het Informatie Systeem denieuwe toestand van de organisatie weergeeft. Dit wordt in debovenstaande figuur weergegeven door de relatie <5,5’> (=<geeft_weer, wordt_weergegeven_door>) tussen IS enOrganisatie. Deze eigenschap wordt door het volgende axiomaweergegeven:

[A4] Organisatie wordt_weergegeven_door IS.

Definitie:[D1] Opslag ≡ IS geeft_weer Organisatie.

Bij de toevoeging van een nieuw element, ook wel geboortegenaamd, moet dit element worden toegevoegd aan het applicatiemodel. Dit wordt weergegeven door de relatie <6,6’> (=<voegt_element_ toe_aan, element_wordt_toegevoegd_aan>) tussenOpslag en Applicatie Model. Deze eigenschap wordt door hetvolgende axioma weergegeven:

[A5] Opslag voegt_element_toe_aan Applicatie Model.

Bij het Evoluerende Informatie Systeem bestaat de aanvullendeeis, dat de eerder opgeslagen informatie gecorrigeerd moetkunnen worden. In de bovenstaande figuur wordt dit weergegevendoor de relatie <3,3’> (= <corrigeert, wordt_gecorrigeerd_door>) tussen EIS en Opslag.Deze correctie zal nu nog in het applicatie model moetenworden doorgevoerd. Dit wordt weergegeven door de relatie<7,7’> (= <transformeert_element_in, element_wordt_getransformeerd_door>) tussen Opslag en Applicatie Model. Decorrectie wordt door het volgende axioma weergegeven:

[A6] EIS corrigeert Opslag transformeert_element_in ApplicatieModel.

Een volgende aanvullende eis bij het Evoluerende InformatieSysteem is, dat eerder opgeslagen informatie vergeten moetkunnen 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 moetenworden doorgevoerd. Dit wordt weergegeven door de relatie<8,8’> (= <verwijdert_element_uit, element_wordt_verwijderd_door>) tussen Opslag en Applicatie Model. Deze verwijderingvan een element, ook wel overlijden genoemd, wordt door hetvolgende axioma weergegeven:

[A7] EIS vergeet Opslag verwijdert_element_uit ApplicatieModel.

67

Bij de relaties betreffende de opslag, verwijdering enaanpassing van een element aan het applicatie model dienen nogaanvullende eisen betreffende de volgorde worden gedefinieerd.Ten eerste moet een element eerst worden toegevoegd aan hetapplicatie model voordat het veranderd kan worden. Dezeeigenschap wordt door het volgende axioma weergegeven:

[A8] Opslag voegt_element_toe_aan Applicatie Modelelement_wordt_ getransformeerd_door Opslag.

Vervolgens moet een element eerst worden toegevoegd aan hetapplicatie model voordat het eruit verwijderd kan worden. Dezeeigenschap 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 kanveranderen. De verandering die de organisatie ondergaat wordtweergegeven 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 informatiebehoefte verandert. Als dit het geval is dan moet hetEvoluerende Informatie Systeem ook aangepast worden. Dit wordtweergegeven door de relatie <9,9’> (= <wordt_aangepast_door,past_aan>). Deze eigenschap wordt door het volgende axiomaweergegeven:

[A11] EIS wordt_aangepast_door Verandering.

Definitie:[D2] Uitvoer ≡ Levering van informatie.

Om te bepalen of een informatie systeem nog in de informatiebehoefte voorziet, wanneer een organisatie een veranderingondergaat is de volgende strategie te volgen:

Organisatie ondergaat verandering:if informatie behoefte is deel van mogelijke uitvoer

then Informatie systeem levert informatieelse Probleem: IS moet aangepast worden.

68

Om te bepalen of de informatie behoefte deel is van demogelijke uitvoer, kan de vraag gesteld worden, of de gewensteinformatie geleverd kan worden. Het aanpassen van hetinformatie systeem dient zodanig te gebeuren, dat de gewensteinformatie geleverd wordt door het informatie systeem. Dezeaanpassingscyclus is als volgt grafisch weer te geven:

4.3 Verband tussen de talen

In dit hoofdstuk zijn er bij de verschillende schema’s eisenen eigenschappen beschreven. Deze beschrijvingen zijn gegevenin een gemodelleerde taal "M". Bij deze beschrijvingen is eenvertaling gegeven in de alledaagse taal. Dit is de zogenaamdeexperttaal "E".

4.3.1 Begrijpbaarheid

Uit de beschreven eisen en eigenschappen in de gemodelleerdetaal M, blijkt dat al deze beschrijvingen te vertalen zijn inde experttaal E. Beide beschrijvingen zijn begrijpbaar voor degebruiker.Met andere woorden geldt, dat elke zin uit M ook te begrijpenis en te vertalen is naar een zin in E. De vraag die hieronmiddellijk bij rijst, is of elke zin uit E ook uit drukkenis in M. Met andere woorden wat is de kracht en de beperkingvan M.

69

4.3.2 Omvang

Uit de zinnen in de gemodelleerde taal M beschreveneigenschappen en eisen en de bijbehorende in de experttaal Ebeschreven vertaling blijkt, dat de zinnen in de experttaalover het algemeen langer zijn.De experttaal E blijkt niet voldoende te zijn om de eisen vande gebruiker vast te leggen, omdat deze taal dubbelzinnighedenkan bevatten. Dit komt, omdat de betekenis van de experttaalafhankelijk is van het wereldmodel van degene die een zin in Egeeft. Deze dubbelzinnigheden komen in de gemodelleerde taal Mniet voor. In de taal M zijn alleen zinnen te maken, die uitde bijbehorende schema’s afgeleid kunnen worden. Met anderewoorden geldt er dat het wereldmodel beperkt wordt tot degegeven schema’s. Er bestaat overeenstemming omtrent degeldigheid van deze schema’s, ofwel deze schema’s geven weerwat de gebruiker wenst en de ontwerper weet exact wat er meebedoeld wordt.

4.3.3 Uitdrukkingskracht

Om een zin uit de experttaal E uit te drukken in degemodelleerde taal M moet er eerst overeenstemming bestaanomtrent het wereldmodel, ofwel er moet eerst een schemaontwikkeld 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 tedrukken in M. Een beperking hierbij is echter, dat de zinnenin taal M aan strakkere regels zijn gebonden dan in taal E, omde ondubbelzinnigheid te garanderen. De oorzaak hiervan is,dat het wereldmodel vrij beperkt is.Een andere beperking is, dat er eerst een wereldmodelontwikkeld moet worden, waarover overeenstemming moet bestaantussen de betrokkenen, in dit geval de gebruiker en deontwerper, voordat er iets beschreven kan worden in degemodelleerde taal M.

70