Onderzoek naar de ontwerpmethodiek ten behoeve van CAAD programmapakketten. Deel 3: De bouwstenen van het ontwerpproces : IOP - GOM - CAD - projekt GOM 3; Fase 1984-1985

Onderzoek naar de ontwerpmethodiek ten behoeve van

CAAD programmapakketten. Deel 3: De bouwstenen van het

ontwerpproces : IOP - GOM - CAD - projekt GOM 3; Fase

1984-1985

Citation for published version (APA):

Dinjens, P. J. M., & Schaefer, W. F. (1986). Onderzoek naar de ontwerpmethodiek ten behoeve van CAAD programmapakketten. Deel 3: De bouwstenen van het ontwerpproces : IOP - GOM - CAD - projekt GOM 3; Fase 1984-1985. Technische Hogeschool Eindhoven.

Document status and date: Gepubliceerd: 01/01/1986 Document Version:

Uitgevers PDF, ook bekend als Version of Record Please check the document version of this publication:

• A submitted manuscript is the version of the article upon submission and before peer-review. There can be important differences between the submitted version and the official published version of record. People interested in the research are advised to contact the author for the final version of the publication, or visit the DOI to the publisher's website.

• The final author version and the galley proof are versions of the publication after peer review.

• The final published version features the final layout of the paper including the volume, issue and page numbers.

Link to publication

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.

If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, please follow below link for the End User Agreement:

www.tue.nl/taverne

Take down policy

If you believe that this document breaches copyright please contact us at:

openaccess@tue.nl

G

Afdeling Bouwkunde 1 _Vakgroep

6

'

1

Architectuur en

Q

0

~ Urbanistiek M045227

-.:

Technische

Hogeschool

~

... _____ ...

~irtdho~era

~~:_:___.

Gom deelnemers in 1985 :

DEEL 3 DE BOUWSTENEN

VAN HET

ONTWERPPROCES

IOP - GOM - CAD - Projekt GOM 3: FASE 1984 - 1985

Auteurs:

Ir. p.J.M. Dinjens Ir. W.F. Schaefer

Januari 1986

Prof.dr.ir. M.F.Th. Bax, Dr.ir. M.R. Beheshti, Dr.ir.J.Th. Boekholt, F.v.d. Bosch, Ir. E. Botma, p. Coppelmans, Ir. P.J.M. Dinjens, Ing. J.P.M. van Geest, M.Janneman, M. van Kempen, Ir.

\l.s.

Schaefer,

Ir A.P. Thijssen, arch. H.B.Q.,Dr. ir. H.M.G. Trum. Gast :Ir. M. Monrooy.

DE BOUWSTENEN VAN HET ONTWERPPROCES

INHOUD

pag

Hoofdstuk 1. INLEIDING 3

Hoofdstuk 2. DOELSTELLINGEN VAN HET ONDERZOEK 6 2.1 MAKEN LOGISCH MODEL VAN HET ONTWERPPROCES 6 2.2 IDENTIFICATIE BESLUITVORMINGSBOUWSTENEN 7 2.3 SPECIFICATIE BESLUITVORMINGSBOUWSTENEN 8

Hoofdstuk 3. INRICHTING VAN HET ONDERZOEK. 10 3.1 OPBOUW VAN DE STUDIE 10 3.2 DE KEUZE VAN DE METHODE YOURDON/DEMARCO 11 3. 3 DOCUMENTATIE METHODE "YOURDON/DEMARCO" 13 3.3 COMPUTERPROGRAMMA "ANALYST" 17

Hoofdstuk 4. ONDERZOEKRESULTAAT 19 4.1 LOGISCH MODEL ONTWERPPROCES 19 4.2 IDENTIFICATIE BESLUITVQRMINGSBOUWSTENEN 21 4.3 SPECIFICATIE BESLUITVORMINGSBOUWSTENEN 26

Hoofdstuk 5 CONCLUSIES EN AANBEVELINGEN 34 •

LITERATUURLIJST 37

BIJLAGEN :zie deel 6.

Bijlage A: Systeem analyse van het Ontwerpproces Fase: "Voorlopig Ontwerp"

Ni vo: "Gebouw"

Bijlage B: Analyst: Introduction to the program manual

Hoofdstuk l.T~L.EIDING

Dit rapport geeft een verslag van de fase 1984-1985 van GOM 3, als deel van het IOP-projekt "Onderzoek naar ontwerpmethodieken t.b. v .CAAD-prograrnma pak-ketten" ( l i t.17). Het projekt beoogt ... "in eerste instantie het identificeren van zgn. besluitvor-mingsbouwstenen met behulp waarvan op een open wijze vorm gegeven kan worden aan besluit c.q. ontwerpprocessen".

Als taakste 11 ing voor GOM 3 wordt genoemd : "Inte-gratie van een tweetal CAD-programmapakketten als aanzet tot onderlinge coördinatie van bestaande programmatuur. Hiervoor zal uitgegaan worden van GOAL en SMOOC".

Beide programma's zijn aanwezig in de afdeling der Bouwkunde en worden, in wisselende mate, in het on-derwijs toegepast. Niet zozeer deze, wat triviale overeenkomsten vormden de aanleiding tot de stu-die,maar wel de principiele verschillen. SMOOC is een genererend programma, GOAL is een evaluerend programma. SëU.1en verzorgen ze de hoofd-activiteiten van het ontwerpen: bij de genererende activiteit wordt een vorm ontwikkeld, die bij de evaluatie wordt getoetst. Het lag daarom voor de hand,een koppeling van beide pakketten na te streven: het daaruit ontstane pakket zou model kunnen staan voor een nieuw gereedschap voor de ontwerper. Een compu-terprogramma, waarop de ontwerper kan steunen,

zowel bij het genereren van vormen als bij de toetsing van die vormen aan gestelde uitgangspun-ten, kan een onschatbare hulp betekenen.

Een eventuele koppeling van GOAL en SMOOC kan pas gestart worden, nadat

-nagegaan is, welk soort programma zij bevatten, vergeleken met andere, te verkrijgen programmatuur -de programma's op hun eigen merites zijn beoor-deeld.

voor de vergelijking met andere programma's is gebruik gemaakt van de studie "Inventarisatie be-schikbare CAD-programmatuur", door ir. P. Dinjens en ing.

c.

Snoeijs (lit.18). In dit rapport, dat ontstond als onderdeel van een afstudeerprojekt, wordt een op3omming gegeven van beschikbare

pro-grammatuur, waarover in de vakliteratuur gepubli-ceerd is. Deze, op het ontwerpen in brede zin gerichte programma's zijn gerubrïceerd met behulp van de terminologie van het GOM-model. De informa-tie is gerangschikt in matrices, op basis van tref-woorden.( zie schema 1). Opvallende conclusies uit de studie zijn:

-er zijn veel programma's, die op een (klein) deel van het ontwerpproces betrekking hebben. Het proces als geheel komt nergens aan bod.

-de meeste programma's bevinden zich in het domein van het gebruik, op het nivo van het gebouw.

-er is sprake van veel doublures en veel lacunes. Een eerste analyse van GOAL en SMOOC leverde een beeld op van gedateerde programma's, die duidelijk de sporen dragen van een ontwikkeling in een tijd met geringe grafische mogelijkheden.

Op grond van de inventarisaties en de analyses is het onderzoekdoel bijgesteld. Het heeft immers wei-nig zin om twee betrekkelijk willekeurige, lichte-lijk verouderde programma's te koppelen, zonder dat er inzicht bestaat in het ontwerpproces als geheel en de plaats die specifieke programma's daarin kunnen innemen. Dit inzicht kan verkregen worden door te onderzoeken:

-welke elementen het ontwerpproces omvat. Hierbij wordt niet gedacht aan een concreet praktijkgeval met al zijn toevalligheden, maar aan een algemeen, imaginair proces.

-welke elementen de bouwstenen van het proces vormen. Kennis van de bouwstenen wordt gezien als een noodzake-lijke stap op weg naar automatisering.

Als uitgangspunt van deze studie is het GOM-model gekozen. Dit vervult een tweeledige functie: het wordt gebruikt en getoetst als instrumentarium voor het onderzoek. Gebruikt, door uit te gaan van de erin voorkomende benamingen en begrippen. Getoetst, door na te gaan, of het inderdaad mogelijk is het proces en zijn bouwstenen te beschrijven in termen van het model.

Language Graphlc ayatem program program package Orden1: social order economicel order spatie 1 order Domalnr. utility physical physiological psychological feasibility production management durability support separating installation Spatial level1: detail room building site tissue Design procea problem/goal definitlon data c:ollec:tion - classification generating of (variant) solution(s) evaluation of (variant) solutlon(s) presentation of (variant) solution(s)

Output te ict diagrams 0 ~ ffi~ ~Ë . N ~~ W ~ ~~ o ~ u ~ cq ~ u .~ o ~ ~ c~~ ~ ~ •.• ~ ~~ z ~

~N~~Nw ~ ~~ra~ ~ t~ w~w z ~w~uu~~o~~ ~c z~~~ww~~ ON~~~

9~~~~~~~~~s~~~~~~~~~~g~~~~~~~~~~§~~~~~~sgi~~~~~~x~~~s

ccm~om~~uuuuuo~ooowaaaaaar~--~~~~oo~~~~~~~~~~~~~~~~~>

ml

,

I

Il

1

.

1

.

1

U Il

~

.

1111111111

U

111

U

.

11111

11

~

-

~

:

.

111 [;

U

111111

500 510 511 512 513 520 521 522 5JO 5Jl 532 5JJ 1 1 1 1 800 810 820 1 1 1 1 1 1 1 1

--1

•

1 1 1

~

1 1 1 1 1 1 1 1 1 1 1 1 1

Ml

1

~

_•

•

Il) f\1

~

f\1 M 01 0 1-l ~ 1 0

~

l() Q)

...

+' f\1 Ul

...

M f\1 +' ~ Q) :> ~ H

..

r--1 f\1 E Q)

..c

u U)

Hoofdstuk 2. Doelstellingen van het onderzoek

2.1 MAKEN LOGISCH MODEL ONTWERPPROCES

De inschakeling van computers als ondersteuning bij het ontwerpen kan pas zinnig gebeuren, nadat het ontwerpproces op "logische" wijze is beschreven door duidelijk gedefinieerde deelprocessen. Daartoe is nodig dat het ontwerpproces wordt vertaald in, wat met inforrnat~ca termen heet, een "logisch

model". Dit is een gestruktureerde beschrijving van alle ge1dentificeerde deel-processen en hun

onder-linge samenhang. De samenhang is beschreven door de informatie, welke in deze deel-processen wordt

ontvangen, getransformeerd en doorgegeven.

Met het logisch model wordt beschreven "~IAT" er in de processen gebeurt. over de wijze waarop de p~o­

cessen verlopen - anders gezegd "HOE" processen verlopen - wordt geen beschrijving gegeven, zodat de analyse zich uitsluitend beperkt tot de essentie van de processen. Hoe processen verlopen heeft te maken met mens- en situatiegebonden faktoren. Het bedoelde model geeft inzicht in:

plaats en betekenis van de deelprocessen binnen het gehele ••ontwerpproces"

benodigde invoergegevens voor elk afzonder-lijk deelproces

te verkrijgen uitvoergegevens van elk afzon-derlijk deelproces

plaats en inhoud van alle voorkomende infor-matiestromen

In een latere fase van het onderzoek zal aangegeven worden elke delen van het model geschikt zijn voor

automatisering of voor welke delen automatisering gewenst is. Deze automatisering kan plaats vinden middels (eigen) programmering en/of implementatie

van bestaande software.

Uitgaande van het GOM-model (lit.1,2,3) kunnen drie processoorten onderscheiden worden~

1. integratie processen, waarin afstemming van de (sub)domeinen en orden op elkaar plaats-vindt.

2. coördinatieprocessen, waarin de afstemming van de onderscheiden nivo's op elkaar plaats-vindt.

3, ontwikkelingsprocessen, waarin de afstemming van de fasen op elkaar geschiedt of anders gezegd, processen waarin de tijdsfactor mee-speelt.

In eerste instantie is het logisch model gemaakt van ontwerpen als integratieproces. Als belangrijk-ste motivering geldt dat hierbij alle orden en domeinen "aan de orde" komen. Bij de andere twee processoorten wordt de informatie mede bepaald door het nivo en de tijd. Het logisch model van het

ontwerpproces heeft betrekking op: de fysiek-ruimtelijke orde de financieel-economische orde de sociaal-culturele orde.

In latere onderzoekfasen zal de invloed, die de andere processoorten op het model hebben, worden onderzocht.

2.2 IDENTIFICATIE BESLUITVORMINGSBOUWSTENEN

Alvorens nader in te gaan op besluitvormingsaspek-ten bij het bouwkundig ontwerpproces, i s het zinvol om de term "besluitvorming" te verklaren aan de hand van definities uit: "Kramers woordenboek der Nederlandse taal" (lit.10). Besluitvorming is hierin beschreven als: "de mogelijkheid, of de wijze om tot een beslissing te komen". Beslissen wordt omschreven als "een besluit nemen omtrent iets waarover verschil van gevoelen bestaat". De voortgang van bouwkundige ontwerp-processen wordt gestuurd door besluitvorming. De genomen besluiten hebben een veelal arbitrair karakter en komen tot stand in een spel van maatschappelijke krachten. Het nemen van een besluit is een typisch mens-gebonden aktiviteit. De voorbereiding tot het nemen van een besluit is algemeen gebaseerd op het verwerken van informatie. In de besluitvoorberei-dende of besluitondersteunende informatieverwerken-de systemen (informatieverwerken-decision support systems) oninformatieverwerken-derscheidt pro f. K . van Hee in z i j n in aug ure 1 e rede ( 1 i t .1 3 ) de volgende funkties:

i . Bij volledig door de beslisser gekozen akties bepaalt het systeem de consequenties in de

vorm van kengetallen.

2. Bij een door de beslisser gekozen criterium berekent het systeem optimaliserende akties

en uiteraard alle relevante kengetallen. 3. Bij gekozen akties bepaalt het systeem de

gevoeligheid voor variaties in de parameter-waarden door de effecten van deze variaties op de kengetallen weer te geven.

Gesteld kan daarom worden, dat besluitvoorbereidende systemen tenminste inzicht geven in de relevante kengetallen.

Bouwkundige ontwerpprocessen kunnen grote verschil-len vertonen, omdat de omstandigheden, waaronder de processen verlopen gevormd worden door het type projekt, aard van de organisatie, het tijdsbestek en last but not least de betrokken personen.

vanuit het logisch model worden duidelijk gedefi-nieerde procesonderdelen {deel-processen) aange-dragen, die zo wezenlijk zijn, dat ze binnen het stelsel van besluitvorming sleutelposities bekle-den. De stelling is dat deze geselekteerde deel-processen in elk ontwerpproces vttrkomen en daarom de bouwstenen van ontwerpprocessen genoemd kunnen worden. In termen van besluitvorming, zoals in het voorgaande beschreven,spreekt dit rapport van be-sluitvormingsbouwstenen. Het bepalen van de identi-teit van deze besluitvormingsbouwstenen is nodig als stap naar de mogelijkheid tot automatiseren van delen van ontwerpprocessen. Een bekendheid met de aard van deze processen biedt een handvat voor nadere uitwerking in informatie-technische zin.

2.3 SPECIFICATIE BESLUITVORMINGSBOUWSTENEN

In procedurele zin kan bij besluitvormingsbouwste-nen gesproken worden over maat en plaats in een proces.

De plaats van besluitvormingsbouwstenen kan, per proces, var1eren, afhankelijk van de keuze van de ontwerper. De maat wordt bepaald door de inhoud van

het door de besluitvormingsbouwstenen gedefinieerde proces.

De bepaling van de maat is belangrijk. Besluitvor-mingsbouwstenen leveren middelen tot organisatie van het ontwerpproces en als zodanig ook de middel-len tot automatisering van dat proces. Specificatie van de besluitvormingsbouwsteen houdt in, dat zowel de belangen ~an de bouwkundige ontwerpdiscipline als die van de informaticadiscipline worden ge-diend. Te grote besluitvormingsbouwstenen brengen het gevaar met zich mee, dat ze voor de programmeur niet bruikbaar zijn, omdat ze ruimte bieden aan diverse computerprogramma's. Ook voor de ontwerper kunnen ze verkeerd uitpakken: weliswaar zal hij het ontwerpproces in de weergave met enkele, grote

procesnamen herkennen, maar het resultaat kan on-aangenaam triviaal zijn. Te denken valt aan be. na-mingen als analyse, synthese, evaluatie. Termen die overbekend zijn, maar niets toevoegen aan de kennis omtrent het ontwerpproces.

Te kleine besluitvormingsbouwstenen, waarin te

kleine deelprocessen worden benoemd, zijn omgekeerd ongeschikt. De kans is groot dat de programmeur er bruikbare benamingen in ziet, omdat de processen basisprocessen zijn, zoals optellen, verzamelen,

vergelijken, en dérgelijke. Processen, die

em-duidig in algoritmen kunnen worden omgezet, maar waarin de ontwerper op geen enkele wijze het geheel

van zijn activiteiten zal herkennen.

Daartoe zal bij de specificatie van de besluitvor-mingsbouwstenen een maat moeten worden bepaald die

relevant is, zowel voor het ontwerpproces in het algemeen als voor de te ontwikkelen programma's in het bijzonder.

In eerste instantie zal de maatbepaling plaatsvin-den vanuit de ontwerpmethodiek: de beschrijving van het ontwerpproces, die gebaseerd is op het GOM-model, zal de middelen hiervoor moeten aanreiken. Toetsing aan de criteria vanuit de informatica geschiedt in een latere fase van het onderzoek. In globale zin geeft de gehanteerde analysemethode hiervoor garantie.

Hoofdstuk 3 . . TOEGEPASTE ONDERZOEKMETHODE

3.1 DE.OPBOUW VAN DE STUDIE

Het logisch model van het ontwerpproces is ontwik-keld aan de hand van een imaginair proces. Bewust is niet gekozen voor een praktijkgeval, omdat het naast de voordelen van concreetheid, ook de nadelen van toevalligheid en onvolledigheid met zich mee-brengt.

Als fase is het "voorlopig ontwerp" gekozen. Een fase, die begint nadat de eerste aftastingen om-trent de haalbaarheid zijn geschiedt en eindigt, voordat de uitwerking t.b.v. uitvoering middels werktekeningen plaats vindt. De term "voorlopig ontwerp" is ontleend aan het BNA-rapport "Informa-tieverwerking tijdens het Bouwproces"(lit.12). Dit sluit aan bij een in de nederlandse architecten-praktijk gebruikelijke terminologie. Het houdt geen adhaesie voor het genoemde rapport in. Voor een vergelijkend commentaar op het BNA- en GOM-model wordt verwezen naar de betreffende publicatie

(lit.16).

Als motief voor deze keuze kan gegeven worden, dat in deze fase de elementaire bewerkingen, die ge-noemd worden in het proefschrift van Dr. Ir. J.T. Boekhol t "Bo1.1wkundig ontwerpen" ( 1 i t.2) (formuleren doelstelling, formuleren uitgangspunten, genereren varianten en evalueren) evenwichtig aan bod komen. Dit in tegenstelling tot de begin- of de eindfase van het ontwerpproces, waarbij het accent veeleer zal komen te liggen op éS"l van de genoemde bewer-kingen.

Als nivo is het "gebouw" gekozen. Op dit nivo, dat 1 igt tussen de "omgeving" en het "detai 1", treedt een zeker evenwicht op tussen de aandacht, besteed aan de andere orden, op het hogere nivo en de aan-dacht voor het technische domein, op het lagere nivo.

De gehanteerde terminologie is ontleend aan het GOM-model. Het ontwerpproces wordt onderscheiden naar orden en domeinen. Er wordt aandacht besteed aan de fysiek-ruimtelijke orde, de financieel-economische orde en de sociaal-culturele orde. In

de ruimtelijke orde worden het domein van·het gebruik, het domein van de vervaardiging en het domein van dd duurzaamheid onderscheiden. Het domein van het gebruik wordt op zijn beurt onderverdeeld in subdomeinen van het fysiek,

fysiologisch en psychologisch gebruik.

Inhoudelijk, gemeten naar het soort informatie, dat in het ontwerpproces een rol vervult, kan een

onderverdeling gemaakt worden die gebaseerd is op orden, domeinen en subdomeinen. Informatie-tech-nisch, d.w.z. gemeten naar de verwerkingswijze, kan een onderverdeling worden gemaakt, die gebaseerd is op de wijze waarop de informatie behandeld wordt.

Zo wordt de relatie met het vakgebied (Architek-tonisch Ontwerpen) gegarandeerd en de deur naar de informatica open gehouden. De kombinatie van inhoud en verwerking is een absoluut noodzakelijke stap om te komen tot het einddoel van deze studie, nl.

toegepaste informatica voor architekten.

3.2 DE KEUZE VAN DE METHODE YOURDON/DEMARCO

In de inleiding is geschetst, hoe het onderzoek is

g~volueerd van een koppeling van een voorhanden

zijnd tweetal programma's naar een diepgaande ver-kenning van de structuur van het ontwerpproces,de bouwstenen ervan en de daarop te baseren computer-hu lpmidde l en. In feite wordt zo de aanzet genomen naar een informatiesysteem van grote omvang.

In grote lijnen kan de ontwikkeling van een systeem beschreven worden aan de hand van drie fasen:

Fase 1, Fase 2, Fase 3,

waarin het programma van eisen voor het systeemontwerp wordt gemaakt

waarin het systeem wordt ontworpen aan de hand van het programma van eisen waarin het systeem wordt gerealiseerd

volgens het systeemontwerp.

De bestaandè methoden voor het ontwikkelen van systemen onderscheiden zich door hun min of meer specifieke geschiktheid voor een bepaalde fase. Een methode volgens welke het programma van eisen wordt gespecificeerd verschilt wezenlijk van een methode, waarmee programmatuur kan worden ge1mplernenteerd.

Fase 1, waarin het programma van eisen tot stand komt, wordt beschreven door Tom DeMarco in "Struc-tured Analysis and System Specification". Hierin.

worden zowel het proces, waarmee het programma van eisen tot stand komt (structured analysis) als de wijze van beschrijven (system specification)

uit-voerig behandeld en zeer gedetailleerd gedocumen-teerd (lit.5}. Het werk van DeMarco maakt overi-gens deel uit van de omvangrijke "System Develop-ment Methodology" welke met name door PANDATA in Nederland is geïntroduceerd (lit.6).

Fase 2, waarin het systeem wordt ontworpen, is

beschreven door Larry constantine en Edward Yourdon in "Structured Design". Ook hierbij worden zowel het "proces" als het ."product" van deze fase

uit-voerig behandeld (lit.4).

Er bestaan ook methodieken voor systeem ontwikke-1 ing, welke gebaseerd zijn op het simultaan bestu-deren van systeemanalyse - en systeemontwerp-vraag-stukken. SADT is een voorbeeld van een dergelijke methode ( l i t.c). Deze methode vindt vooral

toepas-sing bij meer overzichtelijke probleemgebieden, waarbij snel naar een oplossing - in termen van programmeren - kan worden toegewerkt. Gezien de grote komplexiteit van de te bestuderen materie hebben de onderzoekers gekozen voor een aanpak, welke is gebaseerd op een formeel onderscheid tus-sen systeemanalyse en systeemontwerp.

voor fase 3, waarin het systeem wordt gerealiseerd, is nog geen formele keuze gedaan t.a.v. een me-thode. Mogelijk dat de "methode Jackson"(lit.7) hierbij een rol kan spelen.

Het geheel van activiteiten en procedures, waarmee het systeem wordt ontwikkeld, gebruikt en gewij-zigd, wordt aangeduid met de term "system life cycle". Alle aspecten, die daarbij een rol spelen. worden beschreven door Edward Yourdon in "Managing the System Life Cycle" ( lit.11).

In overleg met Prof. dr. K.M. van Hee (Onderafde-ling der Wiskunde en Informatica, THE) is de me-thode Yourdon/DeMarco gekozen bij dit onderzoek. Deze keuze is verklaarbaar. Het uitgangspunt, om

een imaginair proces te analyseren, leidt ertoe,dat wel uitspraken kunnen gedaan worden over wat er gebeurt maar niet over hoe iets gebeurt. De gekozen methode laat de invulling over de wijze waarop

processen plaatsvinden open, terwijl toch de latere invulling op vele manieren mogelijk blijft. Er is, anders gezegd, sprake van een uitspraak over het thema van de invulling, waarbij de de variant in elk praktijkgeval nog ter keuze is. De methode Yourdon/DeMarco sluit hiermee goed aan op de in de onderzoekgroep gebruikelijke denkwijze.

De gemaakte keuze werd, lopende het onderzoek door twee praktische feiten onderbouwd:

1. De mogelijkheid ontstond, gebruik te maken van het programma "Analyst" (van "IMACS"). Dit pro-gramma is volledig op de methode DeMarco toegesne-den en registreert alle gedane analyses en

contro-leert deze op hun onderlinge consistentie ( bijlage

B).

2. De firma Tektronix, een van de belangrijkste computerhardware fabrikanten heeft voor de ontwik-keling van systemen voor computer-ondersteund ont-werpen gekozen voor de probleem-analyse volgens De Marco (bij lage C).

3.3 DOCUMENTATIE "METHODE YOURDON/DEMARCO"

voor het opdoen van de noodzakelijke kennis over de gekozen methode en omwille van de overdracht aan andere teamleden en belangstellenden is een docu-mentatie gemaakt, die bestaat uit een compleet

uittreksel van de beschikbare literatuur.(lit.15)

In het onderstaande wordt de methode kort toege-licht.

"Structured Analysis and System Specification"

Kenmerken van de methode.

a. Top-Down benadering voor het opsplitsen van activiteiten, zodat het bestuderen en oplos-sen van analyse-vraagstukken telkens binnen strikte grenzen gebeurt.

b. De analyse concentreert zich in de eerste plaats op de "dataf low" en aan de hand

daar-van worden de "processen" beschreven.

c. Grafische presentatie van de relaties tussen de verschillende onderdelen van het systeem

in de vorm van diagrammen (Data Flow Diagrams).

d. Schriftelijke documentatie van de onderdelen van het systeem (Specifications en dictiona-ries)

Het Context Diagram, zijnde het diagram op het hoogste niveau, beschouwt het systeem binnen de gebruiksomgeving. De "bronnen" en "putten" geven de grenzen aan van het systeem en representeren ge-bruikers, instanties ofwel andere (aangrenzende) systemen. Zie als voorbeeld schema 2.

Diagram 0 geeft de eerste FUNCTIONELE DECOMPOSITIE. (opdeling in deelactiviteiten). Het is de "top

level" opdeling van het Context Diagram. Zie als voorbeeld schema 3.

voor de presentatie van de analyse in de vorm van de diagrammen worden vier verschillende symbolen gebruikt:

'°""'

E NAM l

D

- een pijl voor elke data-flow

- een cirkel voor elk proces

- twee evenwijdige lijnen voor iedere data-file

- een blok voor elke infor-matie"bron" of -"put".

Zodra een diagram is opgetekend, wordt telkens elke term, die op een diagram voorkomt, verklaard en kan er tussen de participanten in de analyse-fase geen misvatting bestaan over de inhoud van het diagram.

FASE1 VOORLOPIG ONTWERP NIV01 GEBOUW

DIAGRAMNUMMER c.oNTEXr- l>1A6'-AM.

~~~---~---~---_..;..~---~---1

OMSCHRIJVING GOM 3-PitO.Je!C.T'

OM1'Wtkf'.

NOll.MlN•

,,0

T!AN\ ~----..w

AUTEURS DlnJens & Schaefer

wn61tAAL·

..----°"'-' ....

w ....

•_kP

__

oti &ouw • Tl'AM

DATUM r 5E.fT. 'Bi

Schema 2: Context Diagram _{Schema 3:}

TJif:.

ram 0

.F ASE1 VOORLOPIG ONTWERP .,_D=I:.:..A~G:.:..R~A~M~N:..=U:..:_M:.:_M:.::E~R~----=0=---~---1

NIV01 GEBOUW OMSCHRIJVING 1 /i\A1tt>1-WIOILLOPt6-oNT'W!.llf

INTUlAAL·

De schriftelijke systeem-specificaties worden inge-deeld in vier groepen:

a. data flows

b. processen

c. data elements

d. data files.

voor elke groep wordt een zogenaamd woordenboek aangelegd ("dictionary"), waarin de samenstelling van gehanteerde begrippen volgens vaste conventies wordt genoteerd. Hieronder volgt een overzicht van deze conventies:

= "is gelijk aan"

+ "plus"

[/] "of"

( } "iteraties van", d.w.z~ kan herhaald worden

( ) "optioneel", d.w.z. staat ter keuze

voorbeeld:

Dataf lownaam: Elementen-Posities-Programma

Samenstelling: (Element-Plaats+ ({Element-Relatie})} (d.w.z. -herhaalde malen- de plaats van een of meer elementen plus -ter keuze- de relaties ervan)

Het is goed om bij deze eerste opdeling volgens diagram 0 even s t i l te staan bij de betekènis van de ondernomen "actie" en bij de betekenis van het gerepresenteerde diagram. Het is zeker niet de bedoeling om te demonstreren hoe een bepaald

"gege-vensblokje" door het systeem stroomt. De bedoeling van "Functionele Decompositie" is uitsluitend om het systeem en de daarmee verbonden problematiek zo op te delen, dat elk stuk als redelijk zelfstandig kan worden herkend en geisoleerd kan worden bestu-deerd. Daarbij zijn dan de interfaces tussen de afzonderlijke stukken eenduidig gedefinieerd door de da taf lows.

Hiermee wordt de doelstelling van het "Data Flow Diagram" duidelijk: het is niet een stroom-diagram in de traditionele betekenis, maar een instrument voor FUNCTIONELE DECOMPOSITIE.

Zodra het laagste decompositie-niveau is bereikt (''bottom level"), worden ook de processen gespeci-ficeerd. Proces-specificatie gebeurt volgens ge-structureerd taalgebruik, waarbij getracht wordt het proces te beschrijven aan de hand van een

aantal ondubbelzinnige tekstregels (algoritmisch). Daarbij stellen de ontwikkelaars van de methode, dat indien er voor de proces-specificatie meer

ruimte nodig is dan 1 A4 pagina, het "bottom level" nog niet is bereikt. Een verdere decompositie is dan nog nodig.

3 .3 HET COMPUTERPROGRAMMA "ANALYST"

Het computerprogramma "Analyst" (lit.14) dient ter ondersteuning van de onderzoekers bij de analyse en het maken van de specificaties van systemen. De gebruikte termen en begrippen zijn rechtstreeks ontleend aan DeMarco's "Structured Analysis and System Specification" (Bij lage B).

De bij paragraaf 3.1 genoemde analyse fase, als fase l van de systeem ontwikkeling, kan nader wor-den onderverdeeld in:

analyse van de bestaande situatie: "de projektfase",

analyse van de gewenste situatie: "de systeemfase".

De informatie mbt. het te ontwikkelen systeem wordt in de projectfase ingevoerd en gecontroleerd op consistentie en dient als basis voor de

systeem-fase. De ingevoerde informatie voor de projektfase is in dit geval ontleend aan het GOM model.

Het programma is een belangrijk hulpmiddel voor de systeemanalist. Het biedt als mogelijkheden:

alle informatie kan, zodra ze beschikbaar is, ingevoerd worden. Het programma laat te allen tijde de mogelijkheid tot nader detailleren en/of toevoeging van gegevens open.

de ingevoerde informatie wordt automatisch gechecked op consistentie en volledigheid. Afwijkingen worden meteen aan de gebruiker gemeld.

de in de "project" fase ingevoerde informatie (afkomstig van de analyse), wordt automatisch overgeheveld naar de "system" fase, waarin de nieuwe software wordt ontwikkeld.

automatisch wordt een "dictionary" opgebouwd van alle gedefinieerde begrippen.

Als belangrijkste nadeel dient het ontbreken van een grafische presentatie gemeld te worden.

Hoofdstuk 4. ONDERZOEKRESULTAAT 4.1 LOGISCH MODEL ONTWERPPROCES

Het ontwerpproces is geanalyseerd, uitgaande van de in hoofdstuk 3 genoemde punten:

-de fase is het voorlopig ontwerp -het ni vo is het gebouw

-de informatie wordt gedefinieerd m.b.v. orden en domeinen, volgens het GOM-model

-de informatie wordt gerangschikt naar data, pro-ces, file, bron of put, volgens de methode

Yourdon/DeMarco.

Het ontwerpproces is "top-down" ontleed. Dit houdt in dat de fase "voorlopig ontwerp" is uiteengera-feld in kleinere fasen, waarin

-de programmagegevens worden gesorteerd -de geometrie wordt gegenereerd

-het ontwerp wordt getoetst

-de fase wordt afgesloten (zie schema 4). De decompositie van het proces, d.w.z. het

uiteenrafelen in steeds kleinere deelprocessen, is daarna verder doorgevoerd en de resultaten zijn in schema's vastgelegd (bijlage A). De in de schema's gedefinieerde begrippen zijn genoteerd, zowel ter plaatse als in een aparte "dictionary" (bij lage B). Aangezien, zoals vermeld,een imaginair

ontwerpproces gevolgd werd is de analyse het

resultaat van discussies binnen de onderzoekgroep. Hierbij is gestreefd naar een zo volledig mogelijke opsomming van alle activiteiten en data, die vanuit het gehanteerde GOM-model te benoemen zijn. Twee overwegingen zijn hierbij belangrijk:

-het gaat bij de analyse om erachter te komen,

welke informatie verwerkt wordt. Hoe die informatie in een concreet proces gerangschikt wordt is niet wezenlijk.

-de methode Yourdon/DeMarco biedt ruimte voor aan-vu 11 ing en wijziging van de analyse. Sterker nog, het is juist de bedoeling middels de notatie in de

vorm van schema's en dictionaries de discussie te stimuleren om zo, in een iteratief proces, de analyse-resultaten te verbeteren.

ver-HAALBAARHEID

-SYSTEM-

_STUDIE

FLOW-CHART

INTEGRAAL-

PROGRAMMA-MAKEN

' I PROGRAMMA

FASE

-Uil SORTE:RE:l'I l'IAAR ORDE:l'I

VOORLOPIG

J,

ONTWERP

VOOR ELKE: ORDE:• GE:GE:VEl"IS UITSORTE:RCl'I l'IAAR DOMaNCl'I

~

GE:BRUIKSDOME:Iti UITSPLITSE:N l'IAAR SUB-DOMC:ll'IE:l'I

1

-·

MAAK Ol'ITWl:RP 1 nl•'t <I GCBRUIKSVARIAl'IT Dk1111 _nl•'t ~ okClt,j

'"1."

,., 1 _{TOE:TS VARIAl'IT AAN} 1

~ ' _r•sul- 1 DWRZAAM!i.I. VE:RVAARD.

't1111't

okcay _{.... r}

TOCTS VARIAl'll AAl'I

1

li:r~-

' I rro + sec

01. r .... 1 _INTE:GRAAL 1 okcay ...-1 VOORLOPIG DNlwtRP ' I

DEFINITIEF

ONTWERP

MAKEN

richt is en de gehanteerde notatie-wijze dat het onderzoek naar het model van het ontwerpproces op

zichzelf als een ontwerp is opgevat: met een "trial and error" methode is een voorstel genoteerd, dat open staat voor aanvulling en bijstelling.

4.2 IDENTIFICATIE BESLUITVORMINGSBOUWSTENEN

In bijlage A is het logisch model van het ontwerp-proces gegeven. De schema's tonen de deelontwerp-processen, die zijn gedefinieerd als resultaat van de decompo-sitie. Dit model dient als basis voor de inschake-ling van computer-gereedschap. In par. 2 .2 is ge-steld, dat de identificatie van besluitvormings-bouwstenen hierin een noodzakelijke stap vormt. Aangezien de besluitvorrningsbouwstenen deelproces-sen zijn van het ontwerpproces, kunnen ze geselec-teerd worden uit het geanalyseerde logische model. De selectie wordt verricht op grond van 3 criteria: a. het GOM-model

b. de elementaire bewerkingen c. de hierarchie van processen

a. Het GOM-model

De besluitvormingsbouwstenen kunnen bepaald worden op basis van nivo's, fasen of domeinen. In hoofd-stuk 2.1 is aangegeven, dat het ontwerpproces in eerste instantie wordt gezien als een verzameling van integratie-processen. Dit zijn processen, waar-bij de nadruk ligt op de onderlinge afstemming van domeinen en orden. Het zijn processen die niet afhankelijk zijn van het nivo, waarop het ontwerp betrekking heeft en van de fase, waarin het ont-werpproces zich bevindt. De besluitvormingsbouw-steen wordt daarom primair gedefinieerd in termen van orden en domeinen.

Om tot een werkbare situati~ te komen ligt het voor de hand, alleen dan van een besluitvormingsbouw-steen te spreken, als een proces betrekking heeft op informatie binnen èèn orde of èèn domein àf op informatie over de relatie van twee domeinen met elkaar of van èèn domein met èèn orde.

b. De ~lementaire bewerkingen.

Het nemen van bes 1 is singen is niet beperkt tot de evaluatie. Het opstellen van het programma van

eis~n en de vaststelling van de geometrie zijn ook

stappen in het beslissingsproces. Daarom is uitge-gaan van de indeling van het ontwerpproces, zoals gegeven in het proefschrift van Dr.Ir.J.T.Boekholt

(lit. 2.), waarin als bewerkingen worden genoemd: Formuleren probleem- en doelstelling

Het formuleren van de uitgangspunten.

Het genereren van varianten. Dit leidt tot de vaststelling van de geometrie.

Het evalueren van de variant(en}.

De eerste twee bewerkingen leiden tot uitspraken over het programma van eisen van het te ontwerpen gebouw. In het verdere rapport wordt dan ook, kort-heidshalve, over de programmabepaling gesproken. Bij nadere beschouwing kunnen in de laatst genoemde bewerking twee aparte aktiviteiten worden onder-scheiden, nl. de toetsing van de geometrie aan het programma èn het uitspreken van een oordeel over de toetsing. Het toetsen kan in veel gevallen met

behulp van een informatie-verwerkende machine wor-d-en verricht. In wezen gaat het al leen om de

verge-lijking van de op basis van het ontwerp berekende waarde, met een gewenste waarde.

De uitspraak of de toetsing leidt tot het accepte-ren van het ontwerp

of

tot aanpassing ontwerp en/of programma, kan alleen door de ontwerper (cq. het ontwerpteam} gedaan worden. Het lijkt daarom

alles-zins gerechtvaardigd, in het proces van evalueren onderscheid te maken tussen de toetsing en de

eva-1 ua tie. Dit is tevens in overeenstemming met de door prof. T.Maver gebruikte termen: "Appraisal" en

"Evaluation" (lit.9}.

De processen kunnen derhalve gerubriceerd worden in vier categorieên: (zie schema 5}

1. De programmabepaling : alle processen die plaats vinden met betrekking tot de informa-tie over de gewenste kenmerken en eigenschap-pen van het te ontwereigenschap-pen artefact. Deze in-formatie kan gerangschikt worden naar de ruimtelijke orde, de financieel- economische orde en de sociaal-culturele orde.

2. De vaststelling van de geometrie: alle pro-cessen, die plaatsvinden met betrekking tot het ontstaan van de vorm van het te ontwerpen artefact.

3. De toetsing: alle processen die plaatsvinden met betrekking tot het toetsen van de

geome-trie aan het programma.

4. De evaluatie: op grond van de evaluatie wordt door de ontwerper een beslissing genomen

omtrent het al dan niet accepteren van het ontwerpresultaat. De uiteindelijke

besluit-vorming vindt in deze categorie plaats, maar wordt gedragen door alle voorgaande proces-sen.

c. De hierarchie van processen

De processen in de besluitvorming zijn onder te verdelen naar twee soorten, nl. processen die te automatiseren zijn en processen die niet te automa-tiseren zijn. Deze zgn. "man-machine-boundary" is geen keiharde lijn, zij zal verschuiven al naar gelang de mogelijkheden tot automatiseren enerzijds en de behoeften aan automatisering anderzijds.

De te automatiseren processen kunnen op hun beurt verdeeld worden· in "programmamodulen" en "program-mabouwstenen".

Onder programmamodulen worden de samenhangende gehelen van geautomatiseerde processen verstaan, waarmee bepaalde ontwerpactiviteiten uitgevoerd kunnen worden, bijv. genereren van plattegrondva-rianten, toetsing in de sfeer van de kosten, e.d. Onder programmabouwstenen worden basisactiviteiten

verstaan, die met behulp van een computer verricht kunnen worden, zoals: sorteren, vergaren, opslaan, tekenen, vergelijken, e.d.

Het zal duidelijk zijn, dat programmamodulen altijd opgebouwd zijn uit vele programmabouwstenen.

In par. 2.3 is aangegeven, dat de besluitvormings-bouwstenen een maat moet hebben, die herkenbaar is

voor de ontwerper en hanteerbaar voor de program-meur. De stelling luidt daarom: een besluitvormings-bouwsteen is een proces, dat groter is dan een pro-grammabouwsteen. Het omvat minstens

een

programma-module. (Zie schema 6).

De definitie luidt dan ook:

- een besluitvormingsbouwsteen is een proces, waar-in waar-informatie wordt getransformeerd.

- een besluitvormingsböuwsteen wordt bepaald binnen een van de vier categorieen van besluitvorming, n.l. bepaling programma, vaststelling geometrie, toetsing en evaluatie.

- als besluitvormingsbouwstenen worden alleen die processen onderkend waarin sprake is Yan infor-matie:

- binnen een uniek domein of orde

- of omtrent de relatie van domeinen met elkaar

- of orntrent de relatie van èèll domein met één orde

-besluitvormingsbouwstenen kunnen èèll of meer programmamodulen bevatten.

BESLUITVORMINGSBOUWSTENEN

--CATEGD-

< w

RIEEN

2:

-

_l:J 2: Q: _z: <

...

PRO-

Q: _w

-

~ l:J 2:

...

CESSEN

CJ CJ w Q: _w CJ a.. l:J

...

ONTWIKKELENDE CCDRDINERENDE INTEGRERENDE

Schema 5: Categoriêen besluitvorminsbouwstenen

1

E:St.:UlTVDR-ilNGS

QJWSTDEt

~-PROGRAMMA

Schema 6: Hiêrarchie van processen

w

-...

< ~ ...J <

>

w

4. 3 SPECIFICATIE VAN DE BESLUITVORMINGSBOmlSTENEN

Op grond van de analyse van het ontwerpproces en de hierboven gegeven definities kunnen de besluitvor-mingsbouwstenen gespecificeerd worden. Hierbij dient onderscheid gemaakt te worden tussen de vorm van de specificatie en het aantal bouwstenen. Het aantal van de besluitvormingsbouwstenen kan wijzi-gen, afhankelijk van een nadere uitwerking van het model (zie de opmerkingen hierover in par. 4.1). De

vorm za~₁naar de mening van de onderzoekers, niet wijzigen: hij bevat immers alle, voor de definitie

van een proces noodzakelijke elementen.

De nummers van de hieronder genoemde besluitvor-mingsbouwstenen corresponderen met de schema's in bij lage A.

Categorie .!_ :Formu1eren Programma

De in deze categorie gerangschikte besluitvormings-bouwstenen zijn processen, waarin het programma met daarin beschreven ~isen en wensen voor het te ont-werpen artifact, wordt gesorteerd of gewijzigd.

Proces naam Procesnummer Omschrijving Input informatie Output informatie Integraal-programma-sorteren-naar-orden 0.1

Het integraal programma wordt gesorteerd naar drie orden:

de ruimtelijke orde (RO) - de sociaal-culturele orde (SCO) - de financieel-economische orde (FEO) Integraal-programma Programma-RO Programma-SCO Prograrnrna-FEO

; ) .. Procesnaam Procesnr. Omschrijving Input informatie Output informatie Proces naam Procesnummer Omschrijving Input informatie output informatie Procesnaam Procesnummer Omschrijving Input informatie Programma-Ra-sorteren-naar-de-drie-domeinen 0.2

Programma RO wordt gesorteerd naar de drie domeinen

- het domein van gebruik

- het domein van vervaardigen - het domein van duurzaamheid Programma-RO

Programma-RO-gesorteerd

Aanpassen-programma-Ra-gebruik

0.s.1.2.2

Het programma-Ra-gebruik wordt aangepast op grond van

scores voortkomende uit de toetsing van het ontwerp aan de gestelde eisen en vigerende normen van FEO en de

sco.

Programma-RO-gebruik Normen-RO-gebruik Score-toetsing-van-ontwerp-Ra-aan-FEO Score-toetsing-v~n-ontwerp-RO­ aan-SCO Getoetst-en-gewijzigd-program-ma-Re-gebruik Aanpassen-programma-Ra-ver-vaardigen 0.s.1.2.4 Het programma-RO-vervaardigen wordt aangepast op grond van de scores voortkomend uit de toetsing van het ontwerp aan de FEO en de SCO, binnen de daar vigerende normen en ge-stelde mogelijkheden.

Programma-Ra-vervaardigen Normen-RO-vervaardigen

Score van de toetsing ontwerp -FEO

Score van de toetsing ontwerp

output informatie: Proces naam Procesnummer Omschrijving Input informatie Categorie 2

Getoetst en gewijzigd program-ma-RO-vervaardigen

Aanpassen-progranuna-RO-duur-zaamheid

0.s.1.2.6

Het programma-Re-duurzaamheid wordt aangepast op grond van de scores voortkomende uit de

toetsing van het ontwerp aan de FEO en de SCO, binnen de daar vigerende normen en ge-stelde mogelijkheden. Programma-RO-duurzaamheid Normen-RO-duurzaamheid Score-toetsing-ontwerp-RO-aan-FEO Score-toetsing-ontwerp-RO-aan-SCO Genereren Geometrie

De in deze categorie gerangschikte besluitvormings-bouwstenen, zijn processen waarin uitspraken worden gedaan over de geomet~ie. Dit op grond van alle gewenste eig~uschappen van het te ontwerpen arte-fact (fysiek, fysiologisch, psychologisch) die te formuleren zijn in termen van maat en plaats. Deze uitspraken hebben betrekking op het geometrisch kader (het raster, de drager) en de daarin te plaatsen elementen. Procesnaam Procesnummer Omschrijving vertaal-programma-gebruik-fy-siologisch- fysiek. 0.6.1.4.1

Het programma dat betrekking heeft op het fysiologische subdomein, wordt vertaald naar het fysieke subdomein van het gebruik. Deze vertaling resul-teert in uitspraken over maat en plaats van het raster, de drager en de elementen.

Input informatie output informatie Procesnaam Procesnummer omschrijving Input informatie output informatie Procesnaam Procesnummer Omschrijving Input informatie Output informatie Programma-gebruik-fysiologisch Fysiologische-drager-kondities Fysiologische-raster-kondities Fysiologische-element-kondi ties Fysiologische-programma-kondi ties vertaal-programma-gebruik-· psychologisch- fysiek 0.6.1.4.3

Het programma dat betrekking heeft op het psychologische

subdomein, wordt vertaald naar het fysieke subdomein van het gebruik. Deze vertaling resul-teert in uitspraken over maat en plaats van het raster, de drager en de elementen. Programma-gebruik-psycholo-gisch Psychologische-drager-kondi-ties Psychologische-raster-kondi-ties Psychologische-elementen-kon-di ties Psychologische-programma-kon-di ties · Genereer-variant-RO-gebruik 0.6.1.4.2.4

In het domein van het gebruik worden de geometrische

varian-ten gegenereerd, binnen een gegeven situatie (de drager) en op basis van omschreven funkties (elementen).

Drager-plan

Specifiek-elementen-programma Elementen-katalogus

Categorie

2

De toetsing

De in deze categorie gerangschikte besluitvormings-bouwstenen zijn processen, waarin het ontwerp, dat ontstaat in de fysieke subdomeinen, wordt getoetst aan de ander (sub-)domeinen en orden.

Proces naam Procesnummer Omschrijving Input informatie Output informatie P~ocesnaam Procesnummer Omschrijving Input informatie output informatie Procesnaam Procesnummer Omschrijving Ontwerp-RO-toetsen-aan-FEO 0.3

Het Ontwerp-RO wordt getoetst aan het Programma-FEO. De toetsing levert zowel bereke-ningsresultaten in termen van een ontwerp-FEO, alswel de waardering van het ontwerp in termen van Toetsresulaten-FEO. Ontwerp-RO Programma-FEO Normen-FEO Ontwerp-FEO Toets-resultaat-RO-FEO Ontwerp-gebruik-toetsen-aan-vervaardigen 0.6.1.s

Het ontwerp wordt binnen het gebruiksdomein getoetst aan de criteria van het programma mbt. het domein van vervaardi-gen.

Ontwerp-RO-gebruik

Programma-RO-vervaardigen Ontwerp-RO-vervaardigen

Toets-resultaat-gebruik-ver-vaardigen (gesorteerd naar de subdomeinen van het gebruik)

Ontwerp-gebruik-toetsen-aan-duurzaamheid.

0.6.1.6

Het ontwerp wordt binnen het gebruiksdomein getoetst aan de criteria van het programma mbt. duurzaamheid.

Input informatie output informatie Procesnaam Procesnummer Omschrijving Input informatie Output informatie Proces naam Procesnummer Omschrijving Input informatie output informatie Procesnaam Procesnummer Omschrijving Input informatie output informatie Procesnaam Procesnummer Omschrijving Ontwerp-RO-gebruik Programma-RO-duurzaamheid Ontwerp-RO-duurzaamheid Toets-resultaat-gebruik-duur-zaamheid (gesorteerd naar de subdomeinen van het gebruik)

Toets-gebruik-kosten

0.3.2.5

De berekende gebruikskosten worden getoetst aan de eisen, zoals gesteld in het Program-ma-FEO Gebruikskosten Programma-FEO-gebruik-kosten Toets-resultaat-FEO-duurzaam-heid Toets-stichtings-kosten 0.3.2.s De stichtingskosten worden getoetst aan het Programma-FEO Stichtingskosten Programma-FEO-stichtings-kos-ten ToetsresultaatFEOvervaardi -gen Toets-gebruik-opbrengst 0.3.2.3

De berekende opbrengst van het ontworpen gebouw wordt

ge-toetst aan de eisen, zoals gesteld in het Programma-FEO. Opbrengst-gebouw

Programma-FEO-opbrengst Toets-resultaat-FEO-gebruik

Ontwerp-RO-toetsen-aan-SCO

0.4

Input informatie

output informatie

aan het Programma mbt. de sociaal-culturele orde. Ontwerp-RO Programma-sco Normen-sco Ontwerp-SCO Toets-resultaat-RO-SCO Categorie± : De evaluatie

De in deze categorie gerangschikte besluitvor-mingsbouwstenen zijn processen, waarin de toetsre-sultaten uit categorie 3, worden ge~valueerd en genoteerd dmv. scores. Deze evaluaties leiden tot beslissingen omtrent het programma en/of het ont-werp. Procesnaam Procesnummer Omschrijving Input informatie output informatie Procesnaam Procesnummer Omschrijving Input informatie Output informatie Evalueer-ontwerp-gebruik-ver-vaardigen 0.6.1.3.1

·· De toetsing van het gebruik wordt geêvalueerd tav. de ver-vaardigingsaspekten.

Toets-resultaten-gebruik-ver-vaardigen (gesorteerd naar de subdomeinen van gebruik}

Score-gebruik-vervaardigen

Evalueer-ontwerp-gebruik-duur-zaamheid

0.6.1.3.3

De toetsresultaten van het gebruik worden geêvalueerd tav. de duurzaamheidsaspekten. Toets-resultaten-gebruik-duur-zaamheid (gesorteerd naar de subdomeinen van gebruik} Score-gebruik-duurzaamheid

Procesnaam Procesnummer Omschrijving Input informatie output informatie Procesnaam Procesnummer Omschrijving Input informatie output informatie Evalueer-ontwerp-RO-FEO 0.s.1.1

De toetsresultaten van de FEO mbt. de drie domeinen worden geêvalueerd en uitgedrukt in scores. Toets-resultaat-FEO-gebruik Toets-resultaat-FEO-vervaardi-gen Toets-resultaat-FEO-duurzaam-heid Score-RO-FEO Evalueer-ontwerp-RO-SCO 0.5.1.3

De toetsings resultaten van SCO mbt. de drie domeinen worden geêvalueerd en uitge-drukt in scores. Toets-resultaat-SCO-gebruik Toets-resultaat-SCO-vervaardi~ gen Toets-resultaat-SCO-duurzaam-heid Score-RO-SCO

Hoofdstuk 5 : CONCLUSIES EN AANBEVELINGEN

In dit hoofdstuk worden de bevindingen van het onderzoek kort weergegeven en voorstellen

geformu-leerd voor nader onderzoek. Het GOM-model

Het GOM-model is zeer bruikbaar gebleken voor de beschrijving van het ontwerpproces. Alle

deelprocessen kunnen ermee getraceerd en gedefinieerd worden. De bepaling van de

besluitvormingsbouwstenen gaf meer moeilijkheden. Hierop wordt nader ingegaan in de betreffende alinea.

De methode Yourdon/DeMarco

De methode Yourdon/DeMarco dwingt de gebruiker om bij de analyse alleen te denken in termen van data en proces. Omdat dit onderzoek niet gebaseerd is op een bestaand praktijk voorbeeld,maar tracht het ontwerpproces in zijn algemene contouren te schet-sen, werkte de methode zeer verhelderend. De moge-lijkheid, zich uitsluitend te concentreren op het "wat" van·een proces, zonder vooralsnog een uit-spraak te moeten doen over het "hoe", ontslaat de onderzoeker van een aantal problemen, terwijl de zekerheid, het "hoe" in een latere fase op

verschillende manieren te kunnen vormgeven, blijft bestaan.

Logisch model ontwerpproces

Bij het opzetten van het logisch model van het ontwerpproces is een strikte scheiding aangehouden tussen de twee begrippen die Yourdon/DeMarco hante-ren, n.l. "Structured Analysis" en "System

specificat~on". Dit heeft tot gevolg, dat geen

poging is gedaan, om het aantal bewerkingen, dat in de processen is benoemd, te beperken. Bij nadere studie zal blijken, dat verschillende bewerkingen onder èEn noemer te brengen zijn. Het aantal in de processen gebruikte termen (bepalen, benoemen, sorteren, genereren, enz.) zal, naar alle

15 à 20. Bewust is deze studie verschoven naar een volgende fase van het onderzoek, waarin de "System Specification" plaatsvindt.

Programma Analyst

Aangezien het programma "Analyst" volledig op de leest van de methode Yourdon/DeMarco geschoeid is, leverde het gebruik ervan veel voordelen op. Alle door de onderzoekers gedefinieerde processen en data werden nauwkeurig geregistreerd en op hun onderlinge samenhang getoetst. Beide activiteiten zijn administratief van aard, maar in een complexe analyse als in deze studie is verricht, vormt de "boekhouding" een wezenlijk onderdeel van het werk. Bruikbaar gereedschap hiervoor wordt dan ook

gewaardeerd. Het ontbreken van de mogelijkheid om de ingevoerde info~matie af te beelden, werd als een groot gemis ervaren.

·• Besluitvormingsbouwstenen

De ruimte, die de beslui~Yfnïngsböuwstenen in het rapport innemen, is omgekeerd evenredig met het belang dat ze hebben voor de vaststelling van soort en aard van het te ontwikkelen computer-gereedschap voor ontwerpers. Dit is geen indicatie voor een gebrek aan aandacht, ~aar voor de hoeveelheid onderzoek die in dit opzicht nog verricht moet worden.

De besluitvormingsbouwstenen zijn gedefinieerd van-uit integrerende processen. Nagegaan zal moeten worden, hoe en in welke mate deze definities wijzi-gen, gezien vanuit de ontwikkelende en coordineren-de processen.

De besluitvormingsbouwstenen zijn gerangschikt naar vier categorieên, n.l. formuleren programma,

genereren geometrie, toetsing en evaluatie. Deze indeling sluit aan bij in de pràktijk gangbare begrippen. Er is echter geen aansluiting op de terminologie van het GOM-model. Wellicht is hier sprake van optisch bedrog: de gehanteerde indeling komt hoogstwaarschijnlijk overeen met de term

"ontwikkelende processen" uit het GOM-model. Nader onderzoek is hier nodig.

De geometrie

De centrale plaats, die de geometri~ inneemt in het

ontwerpproces, komt nog niet tot uiting bij de be~

noemde besluitvormingsbouwstenen. IP de studie wordt uitgegaan van de stelling, dat de vorm van een artefact ontstaat in het gebruiksdomein. Deze stelling dient nader onderzocht te worden. Aantal en soort van de besluitvormingsbouwstenen kan

hierdoor gewijzigd worden, met name in de categorie geometrie.

In het ontwerpproces wordt de vorm van het arte-fact, na een globale vaststelling in de aanvangs-fase, steeds specifieker. De informatie omtrent maat en plaats van de bouwdelen kan, in elke fase en op elk nivo, vastgelegd worden in een raster. Met recht kan dit een "groeiraster" worden genoemd: het ontwikkelt mee met het groeien van het ontwerp. Ook de aan het raster te verbinden niet-grafische informatie wijzigt constant. Onderzoek van dit "groeiraster" is daarom noodzakelijk, om zinnige uitspraken te kunnen doen over het mogelijk te ontwikkelen computer-gereedschap voor ontwerpers.

LITERATUURLIJST

BOEKEN

1 Bax Prof.Dr.Ir.M.F.T "Meten met twee Maten"

Proefschrift, TH Eindhoven 1975

2 Boekholt Dr.Ir.J.T.Boekholt "Bouwkundig Ontwerpen"

Proefschrift, TH Eindhoven 1984

3 Trum Dr. Ir. H.M.G.J.

"Over het normbegrip in de bouwkunde" Proefschrift, TH Eindhoven 1979

4 Constantine L. & Yourdon E. "Structured Design Techniques" Yourdon Press 1976

5 Demarco T.

"Structured Analysis and System Specification" Yourdon Press 1979

6 Eilers H.B.

"Systeem Ontwikkeling volgens SDM" Academie Service, 4e druk 1983

7 Jackson M .A.

"Principles of Program Design" Academie Press 7e druk 1983

8 Maarssen Ing. L.A. & McGowan Ph.d. C.L.

"Structured Analysis and Design (SADT) 11

INFORMATIE jaargang 23 nr. 7/8, aug 81

9 Maver Prof.T.W.

"The impact of computer based models on design

decision making" REBUILD Chapter 7

Editors Derricot & Chissick publ. Wiley & Sons Ltd 1982

10 Kramers

"Woordenboek der Nederlandse taal"

11 Yourdon E.

"Managing the systems life cycle" Yourdon press 1982

12 "Informatieverwerking tijdens het bouwproces" BNA Rapport aug. 1984

ARTIKELEN

13 van Hee Prof.Dr.Ir. K.

"Tijd voor informatiesystemen" Inaugurele rede TH Eindhoven 1984

14 "Analyst"

IMACS Program Manual

15 Aantekeningen bij Tom DeMarco Ir.w.schaefer

Ir.P.Dinjens Intern rapport

Juni 1985 •

16 vergelijkende analyse GOM- en BNA-{PIM)model Prof .dr.ir.M.F.Th.Bax

Ir.G.Smeltzer Intern rapport Februari 1985

1 7 Onderzoek naar ontwerpmethoden t.b. v .CAAD-programma pakketten

IOP aanvraag 1 Oct 1984

18 Inventarisatie beschikbare CADprogrammatuur Ir.P.J.M.Dinjens

Ing.C.A.Snoeys GOM,januari 1985