Tilburg University
De ontwikkeling van de informatiesysteemontwikkeling van Reeken, A.J.
Document version: Publisher final version (usually the publisher pdf)
Publication date: 1986 Link to publication
Citation for published version (APA): van Reeken, A. J. (1986). De ontwikkeling van de informatiesysteemontwikkeling. (pp. 1-21). (Ter Discussie FEW). Tilburg: Faculteit der Economische Wetenschappen.
General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal Take down policy If you believe that this document breaches copyright, please contact us providing details, and we will remove access to the work immediately and investigate your claim.
Download date: 28. aug. 2015
f? CBM R 7627 1986
8
IIIIN ~II~B~ Nln lllll ~ll~ll' ll l l faculteit der economische wetenschappen
REEKS "TER DISCUSSIE"
iii~~
-~~,,,,
ií~ 3{. r ;. ~.~,
QiB~Í~~4~i~~~C TP~.D~J~U
No. 36.03 De ontwikkeling van de iniormatiesys teemontwilclcel ing Drs .
mei
~~. J.
1936
van Reeken
De
ontwikkeling van de informatiesysteemontwikkeling - een samenvattend
overzicht.
Drs. A.J. van Reeken Katholieke Hogeschool Tilburg Faculteit der Economische Wetenschappen Vakgroep Informatiesystemen en Accountancy 5000 LE Tilburg
Samenvatting
Het
i nformatiesysteemontwikkeling
werkveld
keling in deze context)
i n in beweging.
tot
( verkort
systeemontwik-
Tien jaar geleden was iedereen
gefaseerd in het vakgebied het erover eens dat een ontwikkelingsproject moest worden aangepakt. SDM is daar een voorbeeld van. en geld Ondanks deze gefaseerde aanpak bleek het noodzakelijk veel tijd te steken i n het onderhouden van systemen. die Sindsdien i s er een aantal systeemontwikkelingsmethoden gepubliceerd vooral gericht zijn op het voorkomen van dat euvel. ISAC is daar een voorbeeld van. taal en Een andere ontwikkeling i s die van prototyping, vierde generatie -hulpmiddelen, microcomputers en standaard pakketten. Deze laatste ontwikkelingen lijken haaks op de klassieke projectfasering en de systeemontwikkelingsmethoden te staan. In
dit
memorandum,
voordracht,
naar
aanleiding
van
een
op
13
maart
1986
gegeven
zal een uitgebreider schets van deze ontwikkelingen gegeven
worden.
Inhoudsopgave
1. Inleiding 2. Achtergrondschets 3. De verdere ontwikkelingen 4. Andere ontwikkelíngen;
er is nog meer
5. Literatuur 6. Index van systeemontwikkelmethoden (N.B. de figuren zijn achterin opgenomen)
1
De ontwikkeling van de informatiesysteemontwikkeling
- een samenvattend overzicht -
1.
Inleiding
Het werkveld informatiesysteemontwikkeling is in beweging. Het
woord
zal
systeemontwikkelingsmethoden, "systeemontwikkeling"
tot
en zeker het
informatiesysteemontwikkeling
of
in
zelfs
deze
context
woord
vaak
informatie-
worden
als daar geen misverstand
verkort over
kan
zijn tot "ontwikkeling". Wanneer in dit opstel sprake is van een informatiesysteem dan wordt bedoeld: "Een
samenhangend
geheel
van technische middelen,
procedures,
program-
ma's en gegevensverzamelingen ten behoeve van de stelselmatige en geformaliseerde informatieverzorging".
In
deze
definitie
informatiesysteem
(1984)
van Kranendonk gerekend.
Laagland
worden de mensen niet tot het
(1986)
b.v.
doet
dat
wel.
Bij
Kranendonk en ook in dit opstel maken mensen deel uit van de informatieverzorging - niet van het informatiesysteem. Het
is
in dit
recentere
opstel de
bedoeling
een
overzicht
te geven
van
de meer
ontwikkelingen in dit werkveld van zeg de laats2~aecade.
F.n
met name zal het effect dat deze ontwikkelingen hebben op de aanpak van de systeemontwikkeling, besproken worden. Ter
oriëntatie
zal
vooraf
een achtergrondschets
gegeven worden van de
ontwikkelingen van de voorlaatste decade. Daarna zullen aan de orde komen - de projectfaseringsmethoden - de ontwerpmethoden en - het effect van ontwikkelingen zoals prototyping, vierde generatie taal en -hulpmiddelen en microcomputers.
Tenslotte
zullen,
worden geponeerd.
ook met
het
oog
op
de
discussie,
enkele
stellingen
2
2. Achtergrondschets
Met
komst
de
ordevergroting programmeren
derde
van de van de
generatie de
schaal
duidelijk
computers
onmacht
aangetoond.
Het
van
(in
de
liep
1964)
werd
toenmalige
gierend
uit
door de
manier de
van
hand;
de
software crisis - gratis meegeleverd - was ui.tgebroken met een vloed van niet werkende,
gebrekkige, onhandelbare software. Het is eigenlijk, als
je er over nadenkt, nog een wonder dat die software althans soms werkte. Bovendien liepen projecten uit in tijd en kosten. De
NATO
Conferentie
over
Software
in
Engineering
1968
en vervolgd
in
1969 moest daar wat op vinden. Om U een indruk te geven waarom het ging, het volgende voorbeeld. Op die conferentie in 1968
(Buxton,
1969) vertelde Hopkins van IBM dat er 1000
fouten per release van het IBM O~S
(5 miljoen instructies) worden gevon-
is maar 0,02i van de instructies en dat vond hij relatief wei-
den. Dat
nig. Maar een paar jaar later rapporteerde Tom Gilb (1974) het
IBM
1972
O~S
370
(inmiddels
uitgave van het
reeds
IBM-manual
10 miljoen instructies 11763
ontdekte
dat hij voor groot)
in de
geteld.
fouten had
Hoe
komt zo iets?
Dergelijke grote
systemen zoals een O~S
voor de
IBM 360 en 370 werden
natuurlijk niet door één man gemaakt. Men wilde het O~S liefst nog tijdens de levensduur van de apparatuur leveren. op te
lossen met de
IBM trachtte dat probleem
zogenaamde Chinese Army Approach:
de
gelijktijdige
inzet van 5000 programmeurs die in ploegendienst de nog warme zetels van de voorgaande ploeg innamen en verder gingen waar de vorige collega was gebleven.
En
bovendien met
dat
"programmeermethoden"
zoals
die
helaas
vandaag de dag nog wel in het wild voorkomen. John Buxton een van de organisatoren van de NATO conferentie drukte zijn kritiek ín 1974
(!)
zo uit:
De
constructie van software laat
zích niet
samendrukken in de tijd door veel arbeid per tijdseenheid in te zetten; zoals het maken van een schilderij ook niet kan worden bespoedigd met a) multiple brush technique, of b) canvas sharing. Sinds een jaar of tien is iedereen het er in het vakgebied dan ook over eens dat het zo niet moet en dat een ontwikkelingsproject anders en wel
3
"gefaseerd" moet worden aangepakt. Dat is geen resultaat van de genoemde Daar is wel de zogenaamde Gestructureerde Programme-
NAVO conferenties.
ringsdiscipline uit voortgekomen, waarover later meer. De fasegewijze aanpak is vooral een antwoord op het uitlopen van projecten in tijd en geld. fasegewijze aanpak van een informatiesysteemontwikkelingsproject
Aan de
is door Nederland veel bijgedragen door middel van de System Development Methodology (SDM). PANDATA ontwikkelde SDM in opdracht van de NederlandNationale Nederlanden en de AKZO. De eerste versie verscheen in
se PTT,
1970. De eerste druk verscheen in 1974 en de tweede in 1978. Vorig jaar is een geheel herziene en vernieuwde versie gepubliceerd. Om U daarvan een indruk te geven, volgen hier beide faseringen. a) de oude fasering (figuur 1) b) de níeuwe fasering (figuur 2) In dit verband moet de term Life Cycle (aanpak) vallen. De vernieuwing van SDM heeft veel te maken met de ontwikkelingen die we hier nog zullen bespreken. Interessant is te onthouden dat met deze fasering primair de doelmatigheid, der
van de systeemontwikkeling wordt gediend en,
de efficiëntie,
doeltreffendheid,
de
worden
opgeleverd
wordt daar
ook geen hulpmiddelen aan, systemen
de
zouden kunnen
ontwikkelproject. De
effectiviteit.
Welke
bv.
bepaald.
niet door
informatie De
min-
hoe
fasering
moet reikt
aan de ontwikkelaars waardoor zij tot betere SDM
komen.
is
gericht
op
de proceskant van het
naam Development Methodology is dus
op zijn zacht
gezegd iets te hoog gegrepen. Dat deze bijdrage uit het management komt, is
te merken. We vinden er de documentatie-
en
-richtlijnen
in
terug
van
hen
die
en
terecht
rapportagevoorschriften wat
onafhankelijker
van
uitvoerders wilden zijn en ook het produkt wat zichtbaarder
specifieke
en controleerbaarder wilden maken. Deze werkwijze was in de werktuigbouw en de civiele bouw al goed bekend. Een
soortgelijke
andere,
PRODOSTA.
Dit
staat
voor
ontwikkeling Project
welke is ontwikkeld binnen Philips,
ook
Control
van
and
Nederlandse
Documentation
bodem
ís
Standards
op de markt gebracht door VOLMAC en
thans ook binnen DSM wordt gehanteerd. Een buitenlandse ontwikketing op dit
vlak
Management
is
PROMPT,
hetgeen
staat
Planning Techniques,
en
voor Project Resources is uitgebracht door
Organization
Simpact
Systems
Ltd, UK. PROMPT wordt bv. sinds 1983 bij Centraal Beheer gebruikt. En er
4
zijn er nog een aantal meer (PARAET - Project Aanpak Raet, METHOD~1). deze methoden hadden als primair doel te voorkomen dat de sys-
Nogmaals:
teemontwikkeling qua doorlooptijd en~of qua kosten uit de hand liep. We gaan nu eerst terug naar de resultaten van de door de NAVO-conferenties ontstane Software Engineering discipline. Daarbij moet men bedenken jaren geleden de verschillende
tot enkele
dat
(bij
de ontwikkeling van
op enigerlei wijze betrokken groepen van vakgenoten
informatiesystemen)
elkaar zelden spraken. Wiskundige Informatici en Administratieve Automatiseerders hadden elkaar blijkbaar weiníg te zeggen. Het Nederlands Rekenmachine Genootschap en het Genootschap voor Administratieve Automatisering fuseerden pas in 1977. Dit is internationaal soms nog niet zover. Informatica is wiskunde en administratieve organisatie was nog het een nog
het
ander.
Het
was
o.a.
maak
een
Dijkstra noemde dat:
ook veel verguisde
nederiger en let op de consequenties van schaal-
wees bescheiden,
vergroting,
geroemde maar
die de oorzaak van de softwarecrisis aan-
Nederlander Edsger Dijkstra, wees:
de veel
gebruik"
"wijs
van
de
"machtige"
hulpmíddelen.
"ons onvermogen veel te doen". Hij komt (in 1970)
tot de conclusie dat we naar de structuur van het programma moeten kijken:
"Testen
programma
toont
foutloos
hooguit is".
aan dat
er fouten in zitten,
We moeten dus
testen zien
nooit dat het
te voorkomen en het
programma zo ontwikkelen dat het bewijsbaar correct is. Dat doen we door bij het ontwikkelen die structuur te kiezen, waarvoor we kunnen aantonen dat het programma correct is en slaan dan twee vliegen in één klap: a) het programma is correct b) we hebben een effectieve heuristische gids bij de constructie van het programma. Dat doe je door a)
stapsgewijze verfijning van abstract naar concreet
b) uitstellen van beslissingen, die je nu niet persé hoeft te nemen en c) beperking while do,
tot
beheersbare
gesloten
(volgorde,
if then else)
Hiermee werd duidelijk dat
programmeren niet moest worden gedaan in de
volgorde waarin de computer het algemeen wel
besturingsstructuren
programma uitvoert.
te werk en je ziet het op PC's nu weer,
meert de input,
Zo ging men in het d.w.z. je program-
dan de transformaties daarop en berekeningen daarmee en
5
tenslotte de uitvoer van het programma, en dat in de machinetaal of (lain een programmeertaal. Dat laatste onderscheid is nog niet eens zo
ter)
van belang. Hoewel over de vraag welke taal het beste is een hele godsdienststrijd is gevoerd. Van belang is het feit dat de hele ontwikkeling werd gedaan rechtstreeks in de beschikbare taal. Dijkstra leerde dat het precies andersom moest. Op het vlak van de (wat toen
in twee dimensies
de administratieve automatisering,
heette) werkt
door
Dominique strengst:
de
Engelsman
Michael
(1975).
Warnier
De
Jackson
ingenieur
werden deze gedachten uitge(1974) Warnier
en was
Fransman
de
daarbij
Jean-
nog
het
zijn werkwijze was
- specificeer de gewenste resultaten - analyseer die in logische deelverzamelingen - specificeer en structureer de daarbij behorende invoerverzameling - leidt daaruit de structuur van het programma af en controleer die met de logische uitvoerverzameling - vul deze programmastructuur in met de gewenste transformaties, ringscondities,
bestu-
lees- en schrijfinstructies
- codeer in een programmeertaal. Om het verschil met de tot dan toe meestal gevolgde werkwijze te illustreren,
maak ik gebruik van een denkmodel van de Duitser Hesse (1981):
Hesse kent in dat model drie dimensies,
waarvan ik hier de eerste twee
nodig heb (zie figuur 3): 1) Abstractiongrad (Entfernung zur ausfiihrenden Maschine) 2)
Sprachliche Freiheit
3) Automatisierung
De eerste noemt hij ook Het programmeertalenspectrum en de
eerste
twee
dimensies samen het Programma-ontwikkelingsvlak.
De
abstractiegraad
via Assemblers,
loopt
van concreet naar abstract,
van Machineniveau
Hoog niveau Talen naar Zeer hoog niveau Talen. Het tra-
ject tussen HN en ZHN is nog onderverdeeld in algorithmisch en niet-algorithmisch.
De linquistische vrijheid loopt van formeel naar informeel, van code via Pseudo-code en Proza naar ldeeën.
6
uitgangspunt
Het
van
de
doel ervan is concreet, De
weg
conventionele
programmeeropgave
is
informeel.
abstract,
Het
formeel. is
naar
het
taalniveau
beschikbare
(vroeger
dus
eerst informeel en pro-
MN!) en dan oplossen in de taal van dat niveau, beren steeds formeler te worden. De aanbevolen weg
eerst op h~og
is duidelijk:
abstractie
niveau forma-
liseren en daarna het geformaliseerde concretiseren. We kunnen dus van een specificatietraject en van een constructietraject spreken. Bij de knik zouden we "Bestek" kunnen schrijven. Het specificatietraject is minstens ook: ontwerptraject . De extra winst van deze voorstellingswijze is dat twee geheel verschilwelke
lende activiteiten zichtbaar worden, vonden.
Als
we
zo
dadelijk over over
4de
eerder
verstrengeld plaats-
automatisering van de
automatisering,
generatietaal en -hulpmiddelen zullen spre-
over
prototyping,
ken,
dan kunnen we die hiermee een plaats geven. Want wat nu reeds dui-
delijk zal zijn,
is dat automatisering heel goed in het constructietra-
ject kan plaatsvinden, terwijl het specificatie c.q. ontwerptraject zich slechts voor ondersteuning zal lenen.
De voor deze aanpak nodige High order Languages van
de
universitaire wereld.
(HN)
waren een produkt
Van daaruit werd, met Dijkstra,
benadrukt
dat niet het instructie repertoire van de machine als uitgangspunt genomen moest worden, maar het denkproces en de daarbij noodzakelijke taal. Toch speelden en spelen op korte termijn vaak overwegingen van economische aard (namelijk de reeds gedane investeringen) een rol en wordt met verouderd gereedschap gewerkt. Verder is relevant de inbreng van de hardwarewereld in de vorm van System Engineering technieken zoals de Top-down-aanpak toen zij de overeenkomsten
software
tussen
en hardware
inzagen.
Dijkstra's
"stapsgewijze
hieraan verwant. Het laat "specificatie met stapsgewijze
verfijning"
is
verfijning"
toe en betekent ook stapsgewijze documentatie en bewijsvoe-
ring. Testmethoden die testen na elke stap, versnellen de voortgang, verkorten de
feedback loop en verbeteren
eruit haalt
hoe
goedkoper
het
het is
leerproces. om die
ontdekt aan het eind van de rit kost
100
Hoe
eerder
fout
te
keer
zoveel als
je een
fout
Een
fout
verbeteren.
een fout
ont-
7
in de volgende stap. Dijkstra zag testen niet zitten, dat begrijpt
dekt U nu. Het
onderzoeken
alternatieven
van
globale - graad van detail)
(steeds
verhoogt
per
stap
en
met
passende
-
de kwaliteit en betekent
eveneens
uiteindelijk ook tijdwinst. Zie voor verdere beschouwingen over software engineering bijvoorbeeld Van Reeken (1981,
'82,
'83,
'85).
3. De verdere ontwikkelingen Het werd duidelijk dat met de gefaseerde aanpak het onderhoudsprobleem nog niet was derhoud te figuur 4:
opgelost
steken, het
(het bleef
noodzakelijk veel tijd en geld in on-
en hier zijn dramatische ervaringen van bekend.
soupeert je hele staf op!).
Zie
Toen dat bleek, zijn gelukkig
de twee ontwikkelingslijnen bij elkaar gekomen. En zijn mede door mensen als Jackson en Warnier de resultaten van de
Software Engineering in de
informatiesysteemontwikkeling gebracht. Dat kun je bijvoorbeeld zien aan het steeds verder "naar voren" uitbreiden van de bestaande methoden. De kritiek op het zoveel
tijd en geld kostende onderhoud werd namelijk
beantwoord met de verwijzing naar fouten in de functionele specificatie welke pas zeer laat in het ontwikkelingsproject boven water kwamen. Want fouten in het functionele ontwerp,
blijven fouten in het
technisch ont-
werp en dus ook in het programmeren, worden bij het testen niet ontdekt, maar komen pas bij de invoering boven water. Het
repareren daarvan werd
onderhoud genoemd. Wat
zijn echter fouten? Waren het wel
fouten? Want ondertussen is na-
tuurlijk de nodíge tijd verlopen sinds de functíonele specificatie werd opgesteld.
Zeker bij ambitieuze projecten was dat het geval.
Functiona-
rissen waren gegaan en gekomen en de omgeving stelt wellicht thans andere eisen. Een plaatje dat deze bij Aron (1974)
twee "fouten"-soorten goed
laat uitkomen,
kwam ik
tegen. (Figuur 5)
We moeten ons dít goed blijven realiseren. Desalniettemin is overal ter wereld nagedacht over de vraag hoe een kwalitatief
goede
resultaat is
functionele
specificatie gemaakt zou kunnen worden.
Het
een stortvloed van ontwikkelingsmethoden. Er zijn gemakke-
lijk 40 acronymen bij elkaar te sprokkelen.
(Zie Index achterin)
In een
8
uitgave van het NGI van 1984 het
tijdschrift
zijn 31
artikelen gebundeld die eerder in
Informatie werden gepubliceerd onder de titel Methodie-
ken voor informatiesysteemontwikkeling. Daaronder vindt men geen herhalingen.
een methode gezien wordt als
Omdat
een werkwijze
(praktijk)
kan worden,
is
een theorie
(denkwijze)
ongemakkelijk dat
het
die
er zo
veel zijn. Een andere poging om wat zicht te krijgen op deze methodieken werd
(en wordt
Onder de
nog
ondernomen door een taakgroep van de IFIP.
steeds)
Comparative Review on
titel CRIS -
Information Systems Design
Methodologies - worden vanaf 1982 allerlei methoden onder de loupe genomen. Om duidelijk te maken welke aspecten van informatiesystemen aan de orde komen bij het bespreken daarvan, maken we een zijstap naar de cyclus van het ontwerpen van informatiesystemen
modellen bij 1980).
De cyclus van modellen (zie
figuur 6)
(Van Nek S~ Van Rees,
geeft aan dat er vier ma-
nieren zijn om te denken over informatiesystemen: waarover en waarom informatie
Systelogisch:
Infologisch: welke gegevenstypen in en uit Datalogisch: wijze van verwerking á~ presentatie Technologisch: middelen voor vastlegging, transport en bewerking En dit is geen detaillering maar telkens een ander aspect. Deze zijn in het denken niet goed te scheiden, maar in documentatie wel. Essentieel is,
dat het denken in een cyclus gaat. Met name bij het de-
tailleren van elk model. Nu hebben van deze cyclus van modellen anderen weer
een
uitwerking
DSM (1985).
gepubliceerd.
Ik vraag me af
Bijvoorbeeld
Vandenbulcke
(1982)
en
of nu net het essentiële niet teniet is ge-
daan en we in feite een aangeklede projectfasering hebben overgehouden. Zie figuur 7. Merk overigens op dat
de
cyclus
van modellen gezien kan worden als de
creatie van een taal om over informatiesysteemontwikkeling te spreken. Merk ook op dat we het hier dus in feite hebben over een informatiesysteem
voor
informatiesysteemontwikkeling.
Het
gaat
over
de
ontwikkel-
methoden die ter onderscheiding van de projectfaseringsmethoden het beste ontwerpmethoden genoemd kunnen worden, omdat ze met name ten dienste van die activiteit staan.
Ze zijn gericht op een effectief produkt. Dit
in tegenstellíng tot de projectfaseringsmethoden, die zoals gezegd, meer op de efficiency van de ontwikkeling gericht waren.
9
literatuur wordt momenteel hoofdzakelijk langs
In de
twee verschillende
invalshoeken getracht een ordening tot stand te brengen. De
ene
de methoden
tracht
hun benaderingswijze van de
te ordenen naar
problematiek. De andere gaat uit van de contingency-theorie bij de ordening. Daarnaast zijn nog twee (en wellicht drie) andere visies te vermelden. Ik zal in het kort ingaan op al deze ordeningen omdat dat inzicht geeft in de ontwikkelíngen op dit gebied. ter Eerst de benaderingswijze als invalshoek. Ik geef enkele voorbeelden verduidelijking. De Boer (1984) maakt expliciet onderscheid tussen de procesbenadering
en
de
M.i.
Omdat
deze
volkomen
duaal
lijkt mij het onderscheid (dat er zeker is) niet zo
(zie figuur 8) zijn, interessant.
gegevensbenadering.
is
dit
meer
een
onderscheid
dat
te maken heeft met
waar je het houvast of vaste punt
waar het handvat aan het probleem zit;
kunt vinden. Een bruikbare methode zou eigenlijk wel de twee benaderingen mogelijk moeten maken. Wat dat betreft is het onderscheid dus wel relevant. Laagland (1983) onderscheidt naast de twee eerder genoemde bovendien nog de
Vereistenbenadering
(BSP,
ISAC-AS,
SADT)
en
de
gedragsbenadering
(JSD). Dit onderscheid wordt later wat duidelijker. Er kan hier m.i.
geen sprake
zijn van vier onafhankelijke benaderings-
wijzen. Wellicht dat een matrix van 2 x 2 gemaakt kan worden. Traunmuller
(1984)
onderscheidt
naast
de
de
procedurebenadering,
gege-
vensbenadering en de gedragsbenadering nog de prototyping en de logical modelling. Interessant is zijn opvatting over de gedragsbenadering waarin hij o.a. PSL~PSA en REMORA plaatst, maar niet JSD. Zie figuur 9. Ook hier denk ik dat de benaderingen niet onafhankelijk zijn. Van
Steenwijk
oriënteerd ook nog sche
onderscheidt
(1986)
benadering
STAA (Kranendonk,
naast
mensgeoriënteerd,
zoals
functiegeoriënteerd
met als
exemplarisch bij
ETHICS
stroming de
en datage-
socio-techni-
(Enid Mumford,
1979)
en
1984) aangetroffen wordt.
Mensgeoriënteerd is blijkbaar niet hetzelfde als gedragsbenadering.
Het
zal
duidelijk zijn dat nog een
was
het
maar
in de
steentje bijgedragen kan worden, al
synthese van de genoemde
standpunten.
Belangrijker
10
lijkt
het
aanpak
om waar
echter
sprake
is van
projectbeheersing de
lifecycle
stellen tegen de recent opgang makende evolutionaire aanpak.
te
De mensgeoriënteerde aanpak bij Van Steenwijk heeft met die evolutionaire
te maken.
aanpak
namen
Andere
bij
deze
aanpak
zijn
die van Lehman
(1982) en Floyd (1985). Hierop wordt aan het eind nog teruggekomen. Voorts lijkt het dat onderscheid gemaakt zou moeten worden naar methoden voor
embedded
versus
NIAM
toepassing
en
bijvoorbeeld.
zulke
die
Wanneer
we
zich
daar
echter
niet
niet
toe
lenen.
oppassen,
ISAC
zijn
er
straks nog meer indelingen dan methoden zelf.
Dat was
de benaderingswijze. De
de ene invalshoek:
andere gaat uit van
de Contingency-theorie, het eerst door Davis (1980) naar voren gebracht. theorie gaat
Deze
bepaalde
van de veronderstelling,
uit
omstandigheden
"toevallige"
dat de aanwezigheid van
(contingencies)
de
keuze
van
het
gereedschap bepalen. Hij hanteert vier contingencies
- projectomvang in tijd en kosten - mate van structuur in het beslissingsproces (organisatiegraad) - materiedeskundigheid van de gebruiker - vakbekwaamheid van de ontwerper. Van Steenwijk (1986) meent dat deze lijst nog wel ís uit te breiden. Hij noemt - typologie van organisaties - branche - niveau van besturing - mate van gewenste gebruikersparticipatie - plaats in de groeicurven (van Nolan) - al of niet stabiel Reëel Systeem - functiegebied (logistiek, personeel, financieel, etc.) ~ - schaalgrootte van het bedrijf en~of project - cultuur in een bedrijf(ratíonaliteit)
Gielkens (1985) van
Davis
en
komt in zijn afstudeerwerk op basis van de contingencies
een
enquête
volgende conclusies:
~) Davies'
onder
103
bedrijven in België
(41y respons)
eerste contingency-factor impliceert deze.
echter
tot
de
11
a)
er ís een verband tussen de toepassing en de bekendheid met de inhoud maar van de methodieken (!) behalve voor BSP en Method~l (wel bekend, recent geíntroduceerd)
b) methodieken ontwikkeld door de leverancier van hard- en software vinden de grootste toepassing c) slechts
8
bedrijven
passen verschillende methodieken
toe
voor ver-
schillende situaties d) de methodiekkeuze wordt veelal gedaan door de dataprocessing manager vaak toee) ISAC en NIAM (daar is met name naar gekeken) worden minder gepast dan je op grond van de contingencies van Davis zou verwachten. Naast deze twee wat meer belichte
invalshoeken,
zijn nog minstens
twee
ordeningsprincipes~`) te noemen. Namelijk
een van Traunmuller
(1984)
die verband
Cognitieve Ergonomie en een van de reeds
tracht
te
leggen met
genoemde Gielkens die de vol-
gende indeling voorstelt: Methodieken - voor het in kaart brengen van het totale informatiesysteem en opdeling in subsystemen (BSP, PRISMA, COS) - voor het ontwikkelen van informatiesystemen - voor efficiënte ondersteuning (SDM, PROMPT, PRODOSTA, PARAET) - voor effectieve ondersteuning - voor data base ontwikkeling - volledige methode (PRISMA) - voor deelontwikkeling (NIAM, CIAM) - overige - volledige methode (ISAC, SASO) - voor deelontwikkeling (MOS) Zelf denk i k een poging te gaan doen - en dat i s dan een vijfde ordening - om de ontwerpmethoden
te vergelijken op de grammaticale aspecten er-
van. Als zij een theorie zijn en dus taal om over ontwerpen te spreken
~) Bij het druk gereed maken van dit onderzoekverslag kwam ik een ordening tegen op basis van toepassingsgebieden. Zie daarvoor Bijvoet en Zomer (1986).
12
homoniemen en witte vlekken en wellicht
synoniemen,
moeten daarmee
een
ander denken te voorschijn komen. het
op
ontwikkelingen
Enkele
gebied
revue
lingsmethoden hebben we de
van
informatiesysteemontwikke-
de
passeren.
laten
U
zich dat
herinnert
verkrijgen van een goedie ontwikkeling werd ingezet met het oog op het de functionele specificatie. Wat
aanpak
de
werk
gemaakt
van
betreft
systeemontwikkeling
van wat
genoemd wordt
wordt
thans
Requirement Engineering
nogal
veel
(zie Yadav,
een verdere uitbreiding 'naar voren'. Men stelt zich daarbij voor wanneer nu maar de vereisten nauwkeurig en formeel verwoord worden,
1983), dat in
het
Mijns len,
verdere inziens
traject
fouten meer
geen
zal men bij
behoeven
te
onderzoek van allerlei nuttigs
dit
maar deze doelstelling
gemaakt
lijkt mij
onhaalbaar.
worden.
ontwikke-
Mijn argumenten zijn
als volgt: a) ten aanzien van gebruikerseisen zoals juistheid en volledigheid van de informatie
- betrouwbaarheid, - gedetailleerdheid - het tijdsaspect
- de mate van veredeling - de beveiliging en privacy-aspecten - de onderhoudbaarheid en de flexibiliteit presteren de huídige ontwerpmethoden weinig. De meeste methoden geven niet
eens
(Wieland,
aan,
dat
dit
soort
eisen
gespecificeerd
moet
worden
1982).
gedetailleerd b) Geen enkele methode kan bepalen op welk moment er gepreciseerd moet worden, ook niet in welke mate.
en
en de Dit wordt door de ontwerper, afhankelijk van de omstandigheden bereikte situatie bepaald (Van Rees, 1984). De rol van de methode gaat niet verder dan het bieden van een documentatiehulpmiddel en het structubieden van een hulpmíddel om het denken van de ontwerper te reren.
c) We hebben er al (en passant)
op gewezen, dat ook de werkelijkheid aan
verandering onderhevig is, en wel langer en dus sterker naarmate het
13
project
groter
is,
en
het
dus
des
te
noodzakelijker
wordt
om
deze
vereisten precies en formeel vast te leggen.
d) De werkelijkheid verandert
onvoorspelbaar door ingebruikname van het
zojuist ontwikkelde systeem.
Waar moeten we dan de oplossíng zoeken?
4. Andere ontwikkelingen; er is nog meer.
De
voortschrijding der
techniek en de verbeterde software-tools hebben
prototyping mogelijk gemaakt,
waarbij iteratief de functionele specifi-
catie ontstaat. De prototyping aanpak is gebaseerd op één simpele veronbederstelling, namelijk dat gebruikers gemakkelijker punten in een staand systeem kunnen aanwijzen die ze niet willen of juist wensen, dan dat ze kunnen opschrijven wat zij denken dat een toekomstig systeem zou moeten doen. Dus in
plaats van de gebruiker te dwingen om zich door de
vele details van een systeemontwerpspecificatie heen te worstelen (vaak honderden pagina's), presenteert de ontwerper een reeks globale benaderingen (op prototypen)
van dat
specificatie maar een echt
systeem. Het prototype is geen papieren
werkend model van het systeem,
wijls onvolledig.
(Burns b~ Dennis,
Het wordt meestal
als een nadeel
jectfasering daardpakket
wordt
doorbroken.
aanpassingen
tot
zij het dik-
1985) gezien dat daardoor de klassieke
Overigens
aanleiding
heeft
ook het
gegeven.
Er
is
fenomeen
prostan-
namelijk nooit
een pakket dat aan de functionele specificaties precies voldoet.
De
prototyping
uit
voortgekomen
zogenaamde
vierde
generatietalen
en
-hulpmiddelen hebben "tot overmaat van ramp" te samen met de microcomputer
gezorgd
zelf.
Van
voor een
een
systeemontwíkkeling
projectfasering
en
van
uitgevoerd
door de gebruiker
systeemontwikkelingsmethoden
is
hierbij in klassieke zin nauwelijks meer sprake. En ondertussen neemt de zorg voor de beheersbaarheid, de continuiteit en de beveiliging bij het management toe. Dat moet duidelijk zijn waar alles nu inmiddels op de klassieke aanpak is ingesteld. Kwaliteitsbeheersing van door gebruikers ontwikkelde toepassingen is een, zoek
van
Mary
Summers
(1985)
naar
voren gekomen
in een onder-
probleem.
Thans
zijn
14
vele gebruikerssystemen armzalig gedocumenteerd, meldt zij.
Ze komt tot
de volgende conclusies: informatiecentrum
- Het
stellen met
betrekking
dient
kwaliteitsbeheersingsrichtlijnen
tot documentatie,
systeemintegriteit
voorzieningen,
en
op
te
datadictionary, veiligheids-
eisen met
betrekking
tot
gege-
vensretentie. op het nale- Het dient te zorgen dat het management van de gebruikers ven van deze richtlijnen toeziet. - Tenslotte
dient
het
DP-management
normen op
kerssystemen die uit kunnen groeien tot
te
stellen
voor gebrui-
toepassingen waarbij de
faci-
liteiten van het mainframe en bedrijfsgegevens worden gebruikt.
Het
duidelijk dat
is
ondertussen uit een aantal
automatiseringsstrate-
aan een nog gieën gekozen kan en zal moeten worden, hetgeen de behoefte verder naar voren liggende activiteit heeft doen toenemen: het opstellen van het automatiseringsbeleid. SDM-2
Terzijde zij opge-
poogt op al deze ontwikkelingen in te spelen.
merkt dat de voorlopige versie van het handboek langs de zijkant gemeten met dunne volbedrukte bladzijden, 6 cm dík is. Het telt - het zij toegegeven -
inclusief de verantwoording en de indices:
995
blz. Hoe iemand
dat onder de pols krijgt is míj een raadsel. Bij SDM-2 komt men bijvoorbeeld het opstellen van het automatiseringsbeleid tegen als onderdeel van de (eerste)
fase:
informatieplanning. Deze
fase moet de gewenste ontwikkeling van de organisatie en de informatievoorziening op korte en lange termijn, alsmede de te ontwikkelen toepassingen, de technische infra-structuur daarbij en de gewenste organisatie van de informatievoorziening opleveren.
Inmiddels is -
uit de
literatuur en mondeling van vakgenoten in het be-
drijfsleven - duidelijk geworden dat het opstellen van zo'n informatieplan niet eenvoudig is. Ten eerste niet, door de interactie die er bestaat met de ontwikkelingen in de bedrijfsdoelstellingen, -mogelijkheden en -beleid.
Ten
tweede
niet
door
de
interactie
die
er
bestaat met
de
technische ontwikkelingen vooral door de snelheid waarmee deze ontwikkelingen plaatsvinden en de inmiddels gegroeide afstand tussen de plannenmakers op dit strategische niveau en de plaats waar deze technische ontwikkelingen worden opgenomen.
15
En daar staan we dan. Maar we zijn er nog niet. Allerwege worden vandaag de
geautomatiseerde
dag
gebracht.
markt
de
Met
Maestro,
Blues,
menen er
goed aan
meest
Graphdoc te
voor
hulpmiddelen
namen
exotische
om er enkele
doen deze
te
'tools'
op
systeemontwikkeling als
Wizard
Excelerator,
noemen.
Sommige
de
leveranciers
aan te bieden aan het
(gratis)
onderwijs. Dat er ook nog andere belangen een rol spelen, als het ondersteunen van
systeemontwikkelaars
het maken van kwaliteitssystemen,
bij
zal duidelijk zijn. Zouden de eerdergenoemde problemen met deze schitterende tools
opgelost worden of
haalt men er
zoals zo vaak,
nog grotere
problemen mee in huis?
Als aanzet voor een discussie zou ik het volgende willen stellen. a) er
zullen
blijven
systeemontwikkelingsprojecten
zeker
waarbij
de
klassieke aanpak goed blijkt te werken (zeer complex project met weinig onzekerheid) b) de verschillende
benaderingswijzen blijken nodig
geweest
te zijn en
zullen dus nodig blijven, maar alleen de systeemontwikkelmethoden met een
consequente
tekenwijze)
eenduidige
over de
geharmoniseerde
taal
(c.q.
notatie
c.q.
benaderingswijzen en over de hele
verschillende
cyclus van modellen, zullen overleven. c) de socio-technische,
evolutionaire aanpak zal in de meeste situaties
de aangewezen aanpak blijken te opzichte
van de
klassieke
zijn. Dit
aanpak,
is
wel een revolutie ten
hoewel vele verworvenheden daarin
een plaats zullen vinden. Over deze socio-technische aanpak nog het volgende. de Dat
praktijk kan is
betoog
deze
aanpak
thans
nog
In de literatuur en
als marginaal
beschouwd
worden.
in dit opstel niet de bedoeling, door daar aan het slot van dit enkele
woorden
aan
te wijden.
Ik zal dat
doen met
woorden
van
Christiane Floyd, hoogleraar aan de Technische Universiteit van Berlijn. Zij
pleit
voor
een
perspectiefverandering
van
een
produktgeoriënteerd
perspectief naar een procesgeoriënteerd perspectief. Thans wordt een informatiesysteem veelal beschouwd als een produkt,
ge-
baseerd op vastgelegde en dus vaste vereisten, en bestaande uit een verzameling gerelateerde documenten, dat in een projectaanpak lineair wordt ontwikkeld. Zij stelt daar de opvatting tegenover van een informatiesysteem als een object
(hulp of beperking) van menselijke leer-,
werk- en
16
syteemontwikkeling
in
communicatieprocessen
waardoor mensen samenwerken;
en
-gebruik;
met flexibele vereisten;
als
medium
dat in een conti-
nue aanpak cyclisch wordt ontwikkeld. De klassieke aanpak noemt zij methoden zonder mensen, de door haar voorgestelde noemt zij mensen met methoden. Ik denk dat daar de oplossing gezocht moet worden.
5. Literatuur (1974): The Program Development Process;
Aron, Joel D.,
part 1; Addisotr-
Wesley, Reading~Mass. L.C.L.
Bijvoet,
en H.
Zomer
voor IS-ontwikkeling; Boer,
J.G.
(1986):
Toepassingsgebieden voor methoden
Informatie 28, 4,
p. 280-288.
(1984): Het ontwikkelen van geautomatiseerde informatie-
de,
systemen
in
organísaties
drijfskunde 56,
en de
rol daarin van methodieken;
1, p. 9-18. Selecting The Appropriate Application
Burns, R.N. en Dennis A.R. (1985):
Development Methodology; Data Buse: fall 1985, p. Buxton,
(1974):
J.N.
Be-
Software Engineering;
19-23.
UNIVAC Seminar Computers in
Education, Rome. Buxton, J.N. ~ Randell B. (eds.) (1969): Software Engineering Technique; NATO Science Committee Conference, Rome. CRIS, Zie Olle T.W. Davis,
G.B.,
Nauman, J.D., McKeen,
requirements: ments
Dijkstra,
E.W.
WSK-03,
strategy;
The
Determining information
(1980):
A contingency method
assurance
nr. 1,
J.D.
for
Journal
selection of
of a require-
System and Software,
1980. (1970):
Notes
on
structured
programming,
TH Report
70-
Technological University, Eindhoven (Neth.)
Dijkstra, E.W. (1972): The humble programmes (1972 ACM Turing Award Lecture); DSM
(1985):
CACM 15,
10, 859-886.
Modellen-cyclus
systeemontwikkeling;
IS-Support,
versie
1,
7.10.1985. Floyd, Christiane (1985):
Paradigm change in Software Engineering; voor-
dracht voor sectie Informatiesystemen NGI, 10-12-1985.
17
Geest,
Frans
T.
Generalized
(1974): 16,
Gielkens,
van
Supplement
Computable
p. 26-29.
7.2.1986, Gilb,
Het
Applicatie-ontwikkeling,
ín
in COBOL-generator,
DB~DC expertise gevat
van der (1986):
3, 210-219
management
Informatie
systems;
(Dutch).
(1985):
J.M.G.
base
data
over
Studie
informatiesysteemontwikkeling
in
het algemeen en de ontwikkelmethodieken ISAC en NIAM in het bijzonder; afstudeerverslag Kath. Hogeschool Tilburg. Hesse, Wolfgang (1981): Methoden und Werkzeuge zur Sofware-Entwicklung ein Marsch durch die Technologie-Landschaft; Informatik-Spektrum 4, p. 229-245. Vier generaties talen; wat bepaalt de keuze,
Hoefnagels, Joop (1986):
in
Het Computable Supplement van 7.2.1986,
Applicatie-ontwikkeling, p. 6-9. Hoptaken,
B.A.A. en Kranendonk R.A., A.
(1985):
Informatieplanning:
een
Informatie 27,
11,
aanpak voor een complex probleem;
eenvoudige
p. 988-999 (nov. 1985). Program Desígn: An objective method; Proceedings B4,
Jackson, M. (1974):
INFO Software, L ondon. Jackson, M.A.
Academic Press, New
Principles of Program Design;
(1975):
York. Klappe,
A.
Het
(1986):
selecteren van een vierde generatietaal,
plicatie-ontwikkeling,
Het
Computable
Supplement
van
in Ap-
7.2.1986,
p. 11-15. Kranendonk R.A., voor
A.
de
(1984):
rechter
Een Socio-technische aanpak: automatisering
hersenhelft;
in
Methodieken
ontwikkeling, NGI. rapport 3a, 1984, A'dam, Laagland,
P.T.M.
(1983):
Modeling
in
information
Informatiesysteem
p. 275-286. systems
development;
Proefschrift, VU-A'dam. L aagland,
P.T.M.
(1986):
PRISMA
Workshop,
Klijnveld
Bosboom
Hegener,
Utrecht, 3-4.2.1986. Lehman, M.M. (1982):
Program Evolution; Research Report DoC 82~1, Imper-
ial College, London, dec. Lith, P. van (1984): dieken
1982.
Development of data sharing system D252,
Informatiesysteem
A'dam. p. 264-274.
ontwikkeling,
NGI.
rapport
in Metho3a,
1984,
18
Mumford, E. en Henshall, D. (1979): system design, Nek, H.
1979, Londen, ABP.
van en Van Rees,
J.R.
(ed)
(1980):
datalogisch en hele-
Infologisch,
Informatie 22, 4,
maal niet logisch: Olle, T.W. e.a.
A participative approach to computer
(april 1980).
Information Systems Desígn Methodologies:
(1982):
a
comparative review; North-Holland Publ. Co., Amsterdam. Randell, B. ~ Naur, P. (eds.)
(1968):
Software Engineering; NATO Science
Committee Conference, Garmish (G). Reeken,
A.J. van (1981): voor
de
HIOG
Ontwikkelingen in het programmeren (Voordracht
op
november
17
1980);
nr.
RC-notitie
20,
Kath.
Hogeschool Tilburg. Reeken,
A.J. van (1982):
Informatie 24,
Wat is goede software?;
12,
p.
Warnier-recept;
in
685-690. Reeken,
A.J.
van
(1983):
Software Crisis,
naar
Software-engineering
Bundel van de zomercursus 1983 van de Systeem-
groep Nederland, AG, p. 13-20. Reeken,
A.J.
van
(1985):
Informatie 27, Rees, J.R. van (1984):
Over het
begrip
1985),
12 (dec.
p.
de term documentatíe;
achter 1053.
De methode doet het niet; in Methodieken Informa-
tiesysteem ontwikkeling,
NGI.
rapport
3a,
1984,
A'dam,
p.
223-
234. Rolland,
C. en C.
Ríchard (1982):
The REMORA Methodology;
in:
CRIS, p.
369-426. Steenwijk,
J. van (1986):
De alchemie en de Informatica,
(te
publiceren
concept). Stevens,
W.P.,
Myers
en Constantine, L.L.
G.J.
sign, IBM Systems Journal, Summer,
Mary
R.
(1985):
How
(1974):
Structured De-
13, 2.
should
applications
be
developed?;
Data
Base, fall 1985, p. 25-34. Traunmuller, Roland (1984):
Information Systems Design Methodologies and
their compliance with Cognitive Ergonomy; tive
ergonomics-mind
and
in:
Readings on Cogni-
proceedings
computers,
Conference, Veer, G. van der e.a (ed.),
2nd
European
Springer New York,
1984,
p. 44-61. Vandenbulcke, J.
(1984):
Systeemmethodieken,
systeem ontwikkeling, NGI.
in Methodieken Informatie-
rapport 3a, 1984, A'dam, p.
305-318.
Warnier,
J.D.
(Ned.
vert.
Logische
opbouw van programma's,
Leiden (Neth.).
Stenfert Kroese,
Wieland, A.J.M.
19 LOP,
1975)
(1982): Het vergelijken van ontwerpmethoden; afstudeer-
verslag Kath. Hogeschool Tilburg. Yadav,
Dr.
B.
Surya
(1983):
Determining
an
organization's
requirements: a state of the art su~vey; Data Base,
information spring 1983,
p. 3-20. Yourdon, E. en Constantine, L.L.
(1975): Structured Design, Yourdon Inc.
6. Index van Systeemontwikkelmethoden
N.S. Deze lijst is niet volledig.
(~ - project beheersingsmethode)
ACM~PCM
Component
Active
and
Passive
Maryland, Mll, AIDES
University
Design
Willis, Hughes Aircraft,
and
Evaluation
zie in Hunke, H.
System,
(ed):
R.R.
Symposium on
Software Engineering Environments, North-Holland, BISAD
of
USA
Interactive
Automated
Modelling,
1981
Business Information Systems Analysis and Design, Honeywell, Waltham~MA,
1968
BUP
Prototyping, 0. Jordanger, SINTEF, Noorwegen,
BSP
Business Systems Planning, IBM Nederland NV, A'dam
CADES
Computer Aided Desígn Evaluation System, Zie
in Hunke,
H.
(ed):
Symposium
Environments, North-Holland,
on
1981
R.A.
Snowdon,
Software
ICL,
Engineering
1981
CIAM
Conceptual Information Analysis Methodology,
CIM
Conceptual Information Modeling,
J.A.
(zie CIM)
Bubenko jr.,
Univers-
ity of Góteborg COS
Classification of Urganisation and System functions
DelMarco
Structured Analysis and System Specification, Prentice-Kall, 1979
DREAM
Design,
Realization,
Boulder,
University
Evaluation
of Colorado,
and zie W.
Modelling Riddle
System,
in Hunke H.
(ed): Symposium on Software Engineering Environments, NorthHolland, D2S2
1981
llevelopment of Data Sharing Systems, CACI Europe BV, Amstelveen (Ian Palmer)
20
~`ETHICS
Effective Technical and Human Implementation of Computer Systems, Enid Mumford e.a., Manchester Business School en Rolls Royce,
HDM
1979 Development
Hierarchical
Methodology,
Stanford Research Institute, HIPO
Levitt
K.
al.,
et
1979 IBM Nederland NV, Amster-
Hierarchical Input-Process-Output, dam
IML
Information Systems,
ISAC
Language,
Management
6,
1(1981),
pp.
Systems
Information
Richter,
G.
Informatton
53-71
and
Work
Analysis
of
Changes,
M.
System,
D.
L undeberg, University of Stockholm ISDOS
Systems
Information
and
Design
Optimisation
Teichrow, University of Michigan, USA ISMS
Science 25, ISS~ISM
Structural
Interpretive
Information
11
(nov.
1979),
Systems
IBM België NV,
Modelíng
zie
Software,
Management
pp. 1069-1081
Study~Information
Systems
Management,
Brussel
JSD
Jackson System Development, M.A. Jackson,
Langefors
Theoretical Analysís of information systems, Sweden,
L ITOS
Linzer
Technique
of
Software
1983
development,
Johannes
1973 Kepler
Universitët, L inz, A., 1978 ~
Method~l
Miller
Arthur Anderssen International B.V., Den Haag Conceptual Models Determining Information Requirements, J.C. Miller, 1964 (Proceedings-Spring JCC)
MOS
Methodisch
Ontwikkelen van
Systemen,
Desisco Nederland
BV,
Amsterdam NIAM
Nijssens Informatie Analyse Methode, Control Data BV, Rijswijk
OAM~OSL
Office MIT,
Analysis
Methodology~Office
Specification Language,
1981
~PARAET
Project Aanpak RAET, RAET, Arnhem
PRISMA
Planning and Requírements a Modelling
Approach,
Analysis
for Information Systems,
P. Laagland,
Klijnveld,
Documentation
Standards,
Kraayenhof á~
Co, A'dam ~
PRODOSTA
Project
Control
Eindhoven
and
NV
Philips,
21
~`PROMPT
Project Resources Organization Management ques; Simpact Systems Ltd, U.K.
PSL~PSA
Problem
Language~Problem
Statement
Teichrow,
Techni-
Planning
Analyzer,
Statement
D.
ISDOS-project, University of Michigan, USA Sorbonne, Parijs en Thomson - CSF
Colette Rolland,
REMORA
,
SA
Structured Analysis, D.T. Ross,
SADT
Structured
Analysis
and
1977
Design Technique,
Ross
e.a.,
Soft
1977
Tech. Inc., Waltham~Mass. USA, SASO
Systeemanalyse en Systeemontwerp, IBM Nederland NV, A'dam
SD
Structured Design, Yourdon en Constantine,
SDEM~SDSS
Software Development Engineering Methodology~Support System,
1979
Fujitsu ~SDM
System Development Methodology, Pandata, Den Haag
S~E~TEC
Software Engineering Technologie,
SMX
Systematrix,
~
1979
CAP Gemini Nederland N.V., Utrecht (ontwikkeld Systematik AB,
door C. J~derlund, SSA
Softlab, Munchen,
Structured Systems Analysis,
Stockholm,
1980) Improved
C. Gane en T. Sarson,
System Technology Inc., New York, USA STAA
Socio-Technische
Aanpak
van
A.
Automatisering,
Kranendonk
R.A., Klijnveld Kraanenhof ó~ Co. en Institute for Social and Organizational Development, A'dam resp. Leuven STEPS
Prof. Dr. Christiane Floyd, TU-Berlin
TELL
(Naar Willem Tell), representation
and
S.N. Zilles en P.G. Hebalkar; analysis
of
information systems desígn;
Data Base 11, 3(winte~spring 1980), USE
User
Environment, Francisco, Warnier~Orr J.D.
p. 93-98.
Engineering methodology plus
Software
A.I.
Wasserman,
Graphical
Unified
Support
Universíty of California,
San
1975
Warnier
(1974)
en K.T. Orr (1977):
Structured Systems
Development Young á~
Abstract formulation of data processing problems, The Jour-
Kent
nal of Industrial Engineering, Nov-Dec 1958, pp. 471-479
MODEL INFORMATIE SYSTEEMONTWIKKELING
methodology
technieken
r ~I r~r ~r.t~,y~;h~~ rm .w,dy ,c
TIA SDM 1 Detinitiestudu~
model nieuw
1.1
obl
1.2
model huidig
7
-
systeem
13 14 i5
rnformatie analyse
~ model informatie behoefte - GOS ~ --~~
TOT
- 2. Functioneel -16 --
ontwerp
gegevens analyse
functieanalyse
~
I
logisch gegevensmodel
1.7 -
3. Technisch ontwerp
logisch
-
functiemodel
-
TOP
technisch ontwerp
1.8 f
-
fysiek gegevens
-
model
programma
procedure
r
e - 4. Bouw
I
systeembouw
voorbereiding
testen
invoering
1
I
- 5. Testen
systeem invoeringsplan
documentatie - 6. Conversie invoering 1.9 --:--.-. t10
1 conversie invoenng I acceptatie rapport
Figuur 1.
Informatiesysteemontwikkeling volgens SDM-1
(projectfasering)
(zie linkerkolom).
-~
projectbreedte
fase 0: Informatieplanning tijd fase 1: Definitiestudie
F1
fase 2: Basisontwerp
F2
fase 3: Detailontwerp
F3
F3
fase 4: Realisatie
F4
F4
fase 5: Invoering
F5
F5
F6
F6
fase 6: Gebruik en beheer
Figuur 2.
Informatiesysteemontwikkeling volgens SDM-2.
(projectfasering)
specificatie-traject (formalisering) uitgangspunt ~
ZHN
.
aanbev ole~
nietalgorithmische talen algorithmische talen
HN
ALGOL 68 Fortran LN Assembler
a~ a~ ~
U C
0
MN
U
~~
code
(formeel)
Figuur 3.
pseudocode
Sprachliche Freiheit
Programma-ontwikkeling volgens Hesse: programma-ontwikkelingsvlak".
idee
proza
(informeel)
"Het
productie c.q. capaciteit (in statements)
onderhoud
tijd (in jaren)
Figuur 4.
Productie van een vaste groep programmeurs productiviteitstoename)
wanneer X~ van
statements onderhoud behoeft.
de
(zonder
Environment at start of project
Installation of system as built in current environment
Figuur 5.
Systeemontwikkeling in de praktijk
(bron:
J.
Aron).
infologisch model datalogische aspecten
infologische aspecten
object model
data model
~ `~--~~
i~
technologische aspecten modellen werkelijkheid
informatie systeem
reéel systeem
Figuur 6. Cyclus van Modellen Zweedse School).
(bron:
Van Nek en Van Rees;
Reëel Systeem - Object Systeem
~
objectanalyse ~ conceptie van object deelsystemen
functionele decompositie informatie
activiteiten analyse
anaiyse
activiteiten model
informatie model functioneel ontwerp gegevens
functie analyse
analyse operationeel gegevens
technisch
model
ontwerp programma
implementatie
ontwerp
analyse conceptueel
programma model
gegevens model bouw data-base bouw~ontw.
programma bouw
data-base model (fysisch)
testen gestructuréerd testen 1
r
Figuur 7.
Informatiesysteemontwikkeling in het kader van de 3e generatie ontwikkel methodes DSM-"op elkaar gelegd").
(bron:
Vandenbulcke;
Strategisch
gegevensbenadering
organisatieniveaus
Tactisch
proces benadering
Operationeel
Figuur 8.
Procesbenadering en Gegevensbenadering duaal.
zijn
operations
ascertain (vaststellen) `
Fíguur
9.
Taal
van REMORA
~
(bron:
trigger ( uitlokken)
Colette Rolland).
1
IN 1985 REEDS VERSCHENEN Betalingsproblemen van niet olieexporterende ontwikkelingslanden en IMF-beleid, 1973-1983
febr.
02. P. Kort
Aanpassingskosten in een dynamisch model van de onderneming
maart
03. G.J.C.Th. van Schijndel
Optimale besturing en dynamisch ondernemingsgedrag
maart
04. J. Kriens
Toepassing van de regressieschatter in de accountantscontrole
mei
O1. H. Roes
J.J.M.
Peterse
05.
J. Kriens R.H. Veenstra
Statistical Sampling in Internal Control by Using the A.O.Q.L.-system (revised version of Ter Discussie juni no. 83.02)
06.
A. van den Elzen D. Talman
A new strategy-adjustment process for computing a Nash equilibrium in a noncooperative more-person game
juli
07. W. van Eijs W. de Freytas T. Mekel
Automatisering, Arbeídstijd en Werkgelegenheid
juli
08. A. van Soest P. Kooreman
Nederlanders op vakantie Een micro-economische analyse
sept.
09.
H. Gremmen
Macro-economisch computerspel Beschrijving van een model
okt.
10.
F. van der Ploeg
Inefficiency of credible strategies in oligopolistic resource markets with uncertainty
okt.
Some tossing experiments with biased coins.
dec.
The effects of a tax and income policy on government finance, employment and capital formation
dec.
11.
J.
Moors
12. F. van der Ploeg
vernieuwing van
13. C.P. van Binnendijk P.A.M. Versteijne
Stadsvernieuwing: het stadhuis?
14. R.J. Casimir
Infolab Een laboratorium voor i nformatiesystemen
dec.
dec.
ii
IN 1986 REEDS VERSCHENEN Monopoly Unions, Investment and Employment: Benefits of Contingent Wage Contracts
jan.
Gewone differentievergelijkingen met niet-constante coëfficiënten en partiële differentievergelijkingen (vervolg R.T.D. no. 84.32)
febr.
03. J.J.A. Moors
Het Bayesiaanse Cox-Snell-model by accountantscontroles.
maart
04. G.J. van den Berg
Nonstationarity in job search theory
april
Small-sample properties of estimators of the autocorrelation coefficient
april
Huishoudproduktie en de analyse van tijdsbesteding
april
DSS, Information systems and Management Games
mei
O1. F. van der Ploeg
02.
OS.
J. van Mier
G.J. van den Berg
06. P. Kooreman
07. R.J.
Casimir
I n I~1~N ~NWI w~I Y I I I I ~W~ I I ~
