Onderzoek naar de ontwerpmethodiek ten behoeve van CAAD programmapakketten : samenvattend rapport

Onderzoek naar de ontwerpmethodiek ten behoeve van

CAAD programmapakketten : samenvattend rapport

Citation for published version (APA):

Bax, M. F. T. (1986). Onderzoek naar de ontwerpmethodiek ten behoeve van CAAD programmapakketten : samenvattend rapport. 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

providing details and we will investigate your claim.

0

Afdeling Bouwkunde Vakgroep

J

Architectuur en · Urbanistiek • M045224

Technische

Hogeschool

Eindhoven

DEEL 0 SAMENVATTEND

RAPPORT

IOP- GOM- CAD- Project'

GOM 0~ FASE 1984 -1985

Auteur:

Prof.dr.ir. M.F.Th. Bax

Gom dee1nemers in 1985 :

Pro f . d r . i r . M . F . Th . B a x , Dr . i r . M . R. Dr.ir.J.Th. Boekho1t, F.v.d. Bosch, P. Coppe1mans, Ir. P.J.M. Dinjens,

Januari 1986

Beheshti, rr. E. Botma, Ing. J.p.M. van Geest, M.Janneman, M. van Kempen, I r . W. S . S c h a e fer , I r A. P . Th i j s sen , arch . H . B . 0 . , Dr.ir. H.M.G. Trum.

Gast :Ir. M. Monrooy.

INHOUDSOPGA VE SAME NV ATTEND RAPPORT

0. lf'\ILEIDING biz. 3

0.1 ORGANISA TIE V Al\1 HET ONDERZOEK biz. 3 0.2 PLAATSBEPALING VAN HET ONDERZOEK blz. 4 0.3 INHOUD VAN HET ONOERZOEK biz. 5

1. OPDRACHT ; INTERPRET A TIE biz. 8 1.1 WERKPLAN "BOUWINFORMA TICA EN COMPUTERGEBEUREN" biz. 8 1.2 INTERNATIONAL DESIGN PARTICIPATION CONFERENCE (DPC'85) blz. 10 1.3 OVERIGE INTERPRET A TIES biz. 10

2 ONDERZOEK STRA TEGIE biz. 11

2.1 BENADERING biz. 11

2.2 MODEL blz. 11

2.3 RELEV ANTlE VAN HET MODEL blz. 12

3 UITVOERlNG VAN HET ONDERZOEK; KORTE UITEENZETTING

VAN DE DEELPROJECTEN blz. 15 3.1 HET GOM- MODEL; ONTWIKKELING VAN EEN ONTWERP

INFORMA TIEMA TRIX blz. 15

3.2 DEELPROJECT GOM 1 blz. 18 3.3 DEELPROJECT GOM 2 blz. 20 3.4 DEELPROJECT GOM 3 blz. 21

4 CONCLUSIES EN AANBEVELINGEN blz. 23

0 INLEIDING

0.1 ORGANISA TIE V Al\1 HET 01\IDERZOEK

Het onderzoek is uitgevoerd in opdracht van de Innovatie-gerichte Onderzoek Programmacommissie Bouw (lOP cie-Bouw)

Meer in het bijzonder gaat het om de uitvoering van het werkplan "Bouwinformatica en computergebeuren" zoals dat is opgesteld door de werkgroep "Procesbeheersing" van de lOP- cie Bouw •• Doelgroep van het onderzoek is de groep van architectonische

ontwerpers. Om die reden is het onderzoek begeleid door een begelei-dingsgroep waarin ruim plaats voor mensen uit de praktijk van

het arc hi tectonisch ontwerpen is ingeruimd.

Samenstelling van de begeleidingsgroep:

Prof.dr.ir. M.F.Th. Sax, THE, (Projectleider en voorzitter), Ir.drs. J. Buijs, programmabureau lOP

Ir. M. Groosman, werkgroep "Proc.esbeheersing" van de lOP cie Bouw.

L. Kraal, EGM- architekten, Dordrecht.

P. van der Toorn Vrijthoff architekt HBO, Bureau van Harmelen en van der Toorn Vrijthoff, 's-Gravenhage.

Jr. F .M. de Jong, Bureau de Jong en van Olphen, Maarssen. Jr. W.J.M. Welling, BNA.

Het onderzoekproject werd verdeeld in drie deelprojecten:

GOM 1, 2 en 3. De projectgroep werd daarom geleed in drie onderzoek-groepen, die werkten onder een centraal management.

Projectleiding en management:

Prof.dr.ir. M.F.Th. Sax, projectleider, Prof. T. Maver,

Ir. G.T.A. Smeltzer, Ing. J. van Geest.

Werkgroep GOM 1: Dr. M.R. Beheshti, Ir. E. Botma.

Werkgroep GOM 2: Dr. R.M. Beheshti, Ir. M. Monroy. Werkgroep GOM 3: Ir. P.J.M. Dinjens, Ir. W .F. Schaefer.

Bax, van Geest en Dinjens behoren tot de vaste staf van de afdeling Bouwkunde, vakgroep Architectuur en Stedebouw (BAS), Groep Ontwerp Methoden (GOM);

Smeltzer en Maver zijn lid van de afdeling Bouwkunde, vakgroep Bouwvoorbereiding en Uitvoerings Techniek (BBU), groep Computer Aided Design. (CAD)

-Botma en Schaefer zijn werkzaam op een tijdelijk contract binnen de afdeling Bouwkunde, vakgroep BAS, GOM.

Monroy is werkzaam binnen een tijdelijk contract tussen THE en SAR.

In de rapportagefase van het project werd dankbaar gebruik gemaakt van de diensten van Dr.ir. H.M.G.J. Trum ten aanzien van het

inhoudelijk becommentarieren van de manuscripten.

Drs. P. Uit den Bogaart van de afdeling Wijsbegeerte en Maatschappij-wetenschappen heeft de onderzoekgroep geassisteerd bij de taalkun-dige vormgevingsaspecten van de rapportage.

Administratieve ondersteuning werd verzorgd door Mevr. M. Janneman en Mej. M. van Kempen.

O.Z.PLAA TSBEPALING VAN HET ONDERZOEK

Het onderzoek maakt deel uit van het meerjarenprogramma van de lOP- commissie Bouw.

Binnen dit programma valt het onder het werkplan "Bouwinformatica en Computergebeuren", een werkplan dat overigens pas gereed

kwam na de start van het onderzoek.

Binnen dit werkplan is het een zogenaamd geselecteerd applicatieproject, dat een ondersteunende functie vervult ten aanzien van het hoofdlijn-project. Dit hoofdlijnproject is gericht op de ontwikkeling van

een zogenaamde informatietechnische infrastructuur. Aan deze ontwikkeling staat het ontwikkelen van modellen van respectievelijk

Het is de bedoeling dat de geselecteerde applicatieprojecten aanzetten opleveren, bijvoorbeeld in de vorm van (deel) modellen, voor de

ontwikkeling van de infrastructuur.

Binnen de geselecteerde applicatieprojecten is een onderzoek

opgedragen aan de THE, afdeling Bouwkunde, Groep Ontwerp Methoden met als titel: "Onderzoek naar ontwerpmethodiek ten behoeve

van CAAD- programmapakketten".

Dit onderzoek sluit inhoudelijk aan op een door de IOP-cie georganiseerd symposium "lnformatie en besluitvorming in de bouw".

Het onderzoek maakt deel uit van een onderzoekprogramma "An inquiry into the design methodology for CAAD program packages", GOM Research proposal, March 1984.

Dit programma is een vijf jaren programma corresponderend met evenzoveel fasen.

Fase 1 is afgerond met het uitbrengen van het onderzoekvoorstel en een bijbehorende bibliografie. Het onderhavige onderzoek is fase 2 van bovengenoemd onderzoekprogramma.

Het onderzoek maakt tevens deel uit van het voorwaardelijk gefinan-cierd onderzoekprogramma "Innoverend Ontwerpen" van de afdeling Bouwkunde THE.

0.3 INHOUD VAN HET ONDERZOEK

Het onderzoekprogramma "An Inquiry into the design methodology for CAAD program packages" geeft de volgende omschrijving van het doel van het onderzoek:

Abstract

The goal of this research programme is to develop a design methodology for computer aided architectural design -CAAD-program packages. The main characteristics of the prospective CAAD program packages are measures displayed to the participants (members of the design coalition team) in a simplified but unambiguous manner. These program packages will be based upon design research and design methods, theories and models.

The field of architecture is the main area of this research programme. The process. of research will cover three main areas for investigation:

1. Systems.

2. Strategies (methods) 3. Techniques.

This research programme intends to develop an arc hi tectura! design methodology open to modern information and computer technology, with an emphasis on participatory potentials of information technology. This suggests that a program package should be developped, which will be an adequate decision-making aid to the design coalition team, in a design participation process.

Consideration of related theoretical studies will provide a concrete basis for arguments which will lead to the development of program packages. These program packages are representative of both generative and evaluative programs.

Binnen dat raamwerk werd als fase 2 van de uitvoering van dat

programma een voorstel geformuleerd voor het onderhavige onderzoek

"Onderzoek naar ontwerpmethodiek ten behoeve van CAAD programmapakketten". Samenvatting van het project.

Het onderzoekprogramma beoogt de ontwikkeling van een architecto-nische ontwerpmethodiek, inspelend op de mogelijkheden van informatie en computertechnologie, in het bijzonder bij participatie- processen. Het onderzoekvoorstel beoogt in eerste instantie het identificeren van zogenaamde besluitvormingsbouwstenen met behulp waarvan op een open wijze vorm gegeven kan worden aan besluitvormings c.q. ontwerpprocessen. Deze bouwstenen bestaan in principe uit besluitvormingsactiviteiten waarbinnen betrokken partijen uitspraken doen ten aanzien van qua schaal en functie bepaalde ruimtelijke elementen binnen een ruimtelijke situatie en daarvoor ge!dende spelregels.

Deze bouwstenen maken het mogelijk vorm te geven aan innovatieve besluitvormingsprocessen. Door uit te gaan van een principiEHe

gelijkwaardigheid van de deelnemende partijen c.q. disciplines kunnen zich afhankelijk van het type project en met gebuikmaking van dezelfde bouwstenen nieuwe evenwichten in de vorm van proces-varianten instellen. Door deze eigenschap wordt een relatie gelegd met parallel uit te voeren onderzoek dat gericht is op bouwstystemen en processen.

Deze bouwstenen worden in wetenschappelijk opzicht bestudeerd op het niveau van ontwerpsytemen, methoden en technieken met de daarvoor geldende specifieke onderzoekmethoden.

Het onderzoek richt zich primair op de aspecten besluitvorming en integratie en richt zich tevens, mede ter toetsing en mogelijke ontwikkeling van de te identificeren besluitvomringsbouwstenen, op het aspect van de inpassing van CAD- processen op het gebied van het architectonisch ontwerpen.

HOOFDSTUK1,0NDERZOEKOPDRACHT

De uitvoering van de onderzoekopdracht

gaf aanleiding tot een nadere interpretatie daarvan. Deze werd ingegeven door een aantal gebeurtenissen tijdens het onderzoek. 1. Het gerP,edkomen van het werkplan "Bouwinformatica en Computer-gebeuren",

2. Bevindingen bij de International Design Participation Conference '85. (DPC- '85)

3. Bevindingen bij de uitvoering van het onderzoek.

1.1 WERKPLAN 'BOUWII\IFORMA TICA EN COMPUTERGEBEUREN'. Het werkplan 'Bouwinformatica en computergebeuren' maakt deel uit van het meerjarenprogramma van de lOP- cie Bouw.

Door het tussentijds gereed komen van het werkplan wordt het mogelijk de probleemstelling uit de inleiding te vertalen in de termen van het werkplan. Het werkplan stelt de ontwikkeling van een informatietechnische infrastructuur centraal. Het plan zegt hiervan het volgende:

"De leidende gedachte is nu dat een goede en algemeen aanvaarde informatie technische infrastructuur voor de bouw een belangrijke conditite vormt voor optimale innovatieve ontwikkelingen, waarbij de kansen die de ontwikkelingen op het gebied van automatisering en informatie bieden door de bouw benut worden en de bedreiging ervan vermeden wordt.

Onder zo'n informatie technische infrastructuur moet men een stelsel van afspraken verstaan dat het mogelijk maakt dat partijen in het bouwproces met elkaar communiceren met behulp van geautoma-tiseerde informatiesystemen, zodat automatisering van dit in wezen interorganisationele proces zich volop kan ontplooien. Dit stelsel van afspraken zal zowel betrekking moeten hebben op techische zaken als op procedurele aangelegenheden.

Wanneer deze infrastructurele basis eenmaal is gelegd, kan pas goed gewerkt worden aan een bouwinformatica-beleid en zijn voor tal van betrokkenen volop stimulansen aanwezig om daarop in te spelen.

De doelstelling van het voorliggend onderzoekprogramma is dan ook een bijdrage te leveren aan het tot stand brengen van een informatietechnische infrastructuur voor de bouw in al haar gele-dingen."

Voor het onderzoek betekent dit dat de resultaten hiervan voorstellen zullen moeten inhouden ten aanzien van de ontwikkeling van de

informatietechnische infrastructuur. Het gaat er dan om hoe in besluitvormingstechnische zin een bijdrage geleverd kan worden aan de modellen, die ontwikkeld moeten worden aan het beginpunt van het zogenaamde hoofdlijnproject dat moet leiden tot antwerp en implementatie van de informatietechnische infrastructuur. Deze bijdrage zal de vorm krijgen van een model, dat nog voldoende ruimte biedt voor interpretatie. Voor deze vorm wordt gekozen, omdat de bedoelde bijdrage op conceptueel niveau verenigbaar moet zijn, dan wei geintegreerd moet kunnen worden met de inbreng van andere onderzoekgroepen, die eveneens op het hoofdlijnproject betrokken worden.

De term "Methodiek" in de titel van het onderzoekvoorstel vraagt in dit Iicht om een enige uitleg. Het gaat om een zogenaamde

meta- methode, een theorie van het ontwerpen, die een veld beschrijft, waarbinnen op adequate wijze methoden beschreven, getest en

ontwikkeld kunnen worden. Binnen een ontwerptheorie komen naast kwesties van methodologische aard ook epistemologische

zaken aan de orde, waardoor een eigen veld van wetenschapsbeoefening betreden wordt.

Voor verdere uitwerking hiervan wordt verwezen naar Dee! l, GOM-model, bijlage l, Discussie.

Deze theoretische benadering vindt zijn uitdrukking in de vorm van een model, waarin alle inzichten omtrent de bouwkundige ruimte (in verandering) op een overzichtelijke en toetsbare wijze gebundeld kunnen worden.

1.2. INTERNATIONAL DESIGN PARTICIPATION CONFERENCE - 85. (DPC- '85)

De term "Participatie" uit het onderzoekvoorstel vraagt een nadere beschouwing. Het gaat hier om participatie in de meest wijde

zin van het woord, dat wil zeggen participatie van alle bij het proces betrokken partijen, inclusief de gebruikers. Met het doel inzicht te verwerven in de "state of the art" op dit gebied werd met steun van de lOP -cie de International Design Participation Conference (DPC '85) gehouden in april 1985.

De participatorische benadering van het ontwerpproces vraagt om een dusdanige uitwerking van het model dat alle ontwerptaken van alle mogelijke partijen en hun mogelijke interakties geidentificeerd en gespecificeerd kunnen worden. Het model zal zijn waarde moeten blijven behouden, oak wanneer de procedurele context van de besluit-vorming onder invloed van sociaal- economische ontwikkelingen veranderingen ondergaat.

1.3.0VERIGE INTERPRET A TIES

Bevindingen bij de uitvoering van het project hebben eveneens geleid tot een nadere interpretatie van de opdracht. Deze komen aan de orde in hoofdstuk 2, Onderzoek strategie, en in

hoofdstuk 3, Uitvoering van het onderzoek.

Samenvattend kan gesteld worden dat het bij de uitvoering van de opdracht gaat om het ontwikkelen van een model dat in moet

kunnen spelen op bestaande en nieuwe c.q. te verwachten ontwikkelingen in de technologische context van de besluitvormingssituatie. Oak

hier is een fundamentele aanpak van het probleem noodzakelijk, daar aileen hierdoor een basis van voldoende duurzaamheid wordt gecreeerd, op grand waarvan de omvangrijke inspanning in termen

van tijd en geld, als nodig voor de ontwikkeling van een informatietechnische infrastructuur gerechtvaardigd is. Niet aileen zal ingespeeld moeten

worden op de dynamiek tijdens de ontwikkeling van het systeem, maar oak op die van het gebruik en het beheer van het systeem.

HOOFDSTUK 2 ONDERZOEK STRA TEGIE

2.1. BENADERING

Bij het vaststellen van een onderzoekstrategie moest een principiele keuze gemaakt worden voor een inductieve, dan wel een deductieve benadering van het probleemveld.

Bij een inductieve benadering is de werkwijze erop gericht wetmatigheden op te sporen in de processen, die zich in de praktijk van de bouw

voordoen, en deze wetmatigheden af te beelden in de vorm van een model. Het primaire doe! ervan is theorievorming.

Bij een deductieve benadering is de werkwijze erop gericht, uitgaande van een theorie, uitgewerkt in de vorm van van een model, na

te gaan of processen in de bouw conform dit model te beschrijven zijn. Het primaire doe! ervan is instrumentatie.

Het verschil tussen beide benaderingen ligt in de positionering

van het model respectievelijk aan het eind, dan wel aan het beginpunt van het onderzoekproces.

2.2. MODEL

Bij de uitvoering van het onderzoek is gekozen voor een deductieve benadering, waarbij een verondersteld model als hypothese geformu-leerd wordt, en deze hypothese getoetst wordt, door na te gaan, of processen met behulp van het model beschreven kunnen worden. Het model kan in dit geval oak processen genereren, die nu niet bestaan, maar die gegeven de veranderingen in de omstandigheden van de bouw wenselijk zijn. Oak bij deze werkwijze is het model in principe ontstaan op basis van een inductief proces. De daartoe benodigde observaties zijn echter in een betrekkelijk klein veld gedaan, en wordt er gebruik gemaakt van algemeen theoretische

ontwikkelingen in gebieden die qua structuur in bouwkundige processen toegepast kunnen worden bijvoorbeeld de algemene systeemtheorie, de cybernetica, en bepaalde structuralistische theorieen.

Als uitgangspunt is een model geconcipieerd dat primair op grand van de reflectie op de ontwerppraktijk in de vorm van een aantal gecoordineerde studies tot stand is gekomen.

Het GOM- model heeft een lange antwikkelingsgeschiedenis

daarge-maakt. Zie hiervaar Deel 1, GOM- model, bijlage 2 Ontwikkelingsgeschiedenis van het GOM- model. Het model representeert een thearie, die

als kaart fungeert vaar de uitvaering van het anderzaek. Op grand van het model is het dan oak magelijk anderzaekprajecten sirriultaan plaats te daen vinden. Het anderzaek kan ten aanzien van het

model als taetsingsanderzaek warden getypeerd. Deze taetsing heeft in eerste instantie een canceptueel karakter, waarbij primair gekeken wardt naar cansistentie en campleetheid van een stelsel van begrippen. In tweede instantie zal de taetsing empirisch zijn, waarbij de praktijk van het antwerpen, eerst in het anderwijs en dan daarbuiten de gezachte taetsingsresultaten ap zal leveren. Afhankelijk van de resultaten zal het model al of niet bijgesteld maeten warden. Deze beschrijving van het praces maakt al duidelijk dat het gaat am het antwerpen van een model.

Enerzijds is het model een hypothese, die getaetst kan en maet

warden, en anderzijds is het het concept vaar een stuctureel systeem, waarmee pracessen in kaart gebracht kunnen warden en dat in

canfrantatie met de amgeving pracessen kan genereren.

Dit model, wardt als een apart anderdeel van de rappartage beschreven in Deel 1, GOM- model, antwikkeling van een Ontwerp Infarmatie Matrix.

2.3. RELEV ANTlE VAN HET MODEL.

De relevantie van het model vaar het antwikkelen van een infarmatietechnische infrastructuur kan blijken uit haar vermagen als basis te dienen

vaar de antwikkeling van een informatiesysteem. In het kader van dit anderzaek is vaar deze wijze van benaderen gekazen amdat deze aanpak twee vaardelen heeft: :

1. Bepaling van de relevantie van het model ap een vaar het lOP werkplan adequate wijze,

2. antwikkeling van een infarmatiesysteem dat oak ap zichzelf genamen bruikbaar is.

ad1 de bijdrage van het anderhavige project aan de antwikkeling van de infarmatietechnische infrastructuur, dient te lapen via een model, en niet via een daarvan afgeleid

infarmatie-systeem, amdat aileen daardaar aan het begin van de antwikkeling van de infrastructuur een open besluitvarmingssituatie gecreeerd

kan worden. Het is een pluspunt dat het model in besluitvormings-informatie en computertechnische zin de ontwikkeling van

een informatiesysteem mogelijk maakt, omdat dit juist eigenschappen moeten zijn van het model, dat aan het begirtpunt staat van

het hoofdlijnproject, dat tot een informatie-technische infrastructuur moet leiden.

adZ Een op zich zelf staande ontwikkeling van een informatiesysteem, in het vervolg van het onderzoek aan te duiden als Architectural Design Information System (ADIS), is van belang voor ontwikkelingen binnen het meer algemeen onderzoek programma van de GOM

en de groep CAD. Afhankelijk van de keuze die door de lOP cie gedaan wordt ten aanzien van een model kan de

ADIS-ontwikkelingslijn gemakkelijk in de hoofdlijn van het informatietechnische infrastructuur ontwikkelingsproject ingevoegd worden.

Een bijkomend voordeel is, dat hierdoor de mogelijkheid geopend wordt andere financieringsbronnen, bijvoorbeeld op EEG niveau, te openen ten behoeve ·van verbreding en verdieping van het project.

Juist de bepaling van de relevantie van het model door middel

van de ontwikkeling van ADIS als een architectonisch ontwerpinformatie systeem is uiterst belangrijk, omdat zich bij het architectonisch

c.q. bouwkundig ontwerpen de structuur van de bouwnijverheid

in klein bestek heel precies aftekent in de structuur van de benodigde data bases en programma bases van het systeem. De feitelijk te ontwikkelen informatietechnische infrastructuur is omvangrijker, maar qua structuur zeker vergelijkbaar met het ADIS.

Bij het antwerp van het ADIS zijn in termen van informatie drie aspecten van belang, namelijk het identificeren en het specificeren van:

1. informatiesoorten,

2. informatiestromen en informatiedragers, 3. informatieve ver- en bewerkende processen.

Ontwerp van het systeem en toetsing daarvan maken dee! uit van een cyclisch en iteratief proces. De drie bovengenoemde aspecten corresponderen met drie technische aspecten van het ADIS, namelijk:

1. database, 2. dataflow,

3. dataprocessing, operations.

-13-Deze drie aspecten worden gecoordineerd door de structuur van het GOM- model, tevens coordineert het model de uitvoering van

deeltaken bij de ontwikkeling van het systeem binnen drie deelonderzoeken, namelijk:

1. GOM 1, database, informatiesoorten,

2. GOM 2, dataflow, informatiestromen en dragers, 3. GOM 3, dataprocessing, informatiever- en bewerking.

GOM 1 is vooral theoretisch van aard; GOM 2 is gericht op de

praktijk van werkelijk optredende informatiestromen tussen partijen, en GOM 3 is vooral technisch van aard, hierbij gaat het om al

of niet automatische be- en verwerking van informatie.

Bij GOM 3 ligt in deze fase van het onderzoek de nadruk op het identificeren en specificeren van zogenaamde

besluitvormings-bouwstenen als mogelijke, in formele zin standaardiseerbare deelproces-sen.

AI deze deelprojecten toetsen bij de ontwikkeling van het ADIS het GOM -model door het stelselmatig als uitgangspunt te nemen. Een geheel andere vorm van toetsing heeft plaats op het vlak van parallelle theoretische en praktische ontwikkelingen. Weer een andere vorm van toetsing heeft plaats bij de empirische toetsing van het model bij analyse en synthese van ontwerpprocessen binnen het kader van het onderwijs en de beroepspraktijk. Deze toetsingscate-gorieen vallen bij deze rapportage buiten de hoofdopzet. In Deel

1, GOM-model, wordt hieraan aandacht besteed in bijlage 1, Discussie.

Zowel de ontwikkeling van het model als de deelonderzoeken GOM 1, 2 en 3 gebruiken elk hun eigen methoden en technieken.

Deze zijn vermeld in de voorstellen van het meerjarenprogramma en het onderzoekvoorstel voor de tweede fase. In de rapporten van de verschillende deelonderzoeken ~omt dit aspect opl")ieuw aan de orde binnen het specifieke betoog over dat onderwerp.

HOOFDSTUK 3 UITVOERING VAN HET ONDERZOEK, KORTE UITEENZETTING VAN DE DEELPROJECTEN.

Over de uitvoering van het onderzoek wordt gerapporteerd in vijf delen die corresponderen met de verschillende deel onderzoeken. Ddeel 1,GOM- model; ontwikkeling van een Ontwerp Informatie Matrix,

Deel 2, GOM 1, ADIS, theoretische opzet,

Deel 3, GOM 3, De bouwstenen van het ontwerpproces. Deel 4, GOM 1, ADIS , praktische uitwerking,

Deel 5, GOM 2, Case- studies.

Ten behoeve van een algemeen overzicht worden korte uiteenzettingen gegeven van:

1. het GOM- model,

2. GOM 1, ADIS,

3. GOM 3, besluitvormingsbouwstenen,

4. GOM 2, case- studies.

3.l.HET GOM - MODEL; DE ONTWIKKELING VAN EEN ONTWERP INFORMA TIE MATRIX.

Het GOM- model is een stelsel van begrippen met behulp waarvan het mogelijk is een adequate beschrijving van de werkeiijkheid te geven, en die het tevens mogelijk maken op deze werkelijkheid in te grijpen. Dit stelsel van begrippen is verbonden met een visuele voorstelling in de vorm van een drie- dimensionale matrix. De werkelijkheid, het model met zijn begrippen, en de matrix kunnen als volgt schematisch weergegeven worden:

Werkelijkheid

'

__.--Matrix

Model~

Matrix en werkelijkheid zijn via het model met elkaar verbonden,

maar de stelling wordt ingenomen dat de werkelijkheid ook rechtstreeks met behulp van de matrix afgebeeld en beinvloed kan worden.

De matrix bestaat uit lijnen, vlakken en volumina, die elk een eigen betekenis hebben. De lijnen zijn assen, die de richting van een proces aangeven; de vlakken zijn projectievlakken, waarop

-15-een ruimtelijke toestand geprojecteerd kan worden; de volumina geven de activiteiten aan die nodig zijn om ruimtelijke toestanden te veranderen. Voor een schematisch overzicht van de matrix: zie fig. 0. overzichtsblad.

Conform de drie dimensies van de matrix gaat het om:

1. een geleding van de toetstand in ruimtelijke niveaus, 2. een geleding van de toestand in functionele domeinen, 3. een geleding van de toestand in temporele fasen.

De beschrijving van elke dimensie heeft plaats volgens principes die het onderwerp waren van een diepgaande studie in de vorm van een dissertatie.

1. Sax, Meten met twee maten, dissertatie THE 1976,

2. Trum, Over het normbegrip in de bouwkunde, dissertatie THE 1979,

3. Soekholt, Souwkundig ontwerpen, dissertatie THE 1984. Sij elke studie werd aandacht besteed aan specifieke begrippen.

1. bij de geleding in niveaus: structuur begrip, systeem theoretisch en structuralistische benadering met spel als analogon,

2. bij de geleding in domeinen: norm- en functiebegrip, doel en middelen benadering en beleid als analogon,

3. bij de geleding in fasen: het begrip activiteit volgens Sax, en het begrip bewerkingscyclus op verschillende procesniveaus volgens Soekholt ten aanzien van processen die niveaus en domeinen op elkaar afstemmen, en ten aanzien van gefaseerde ontwikkelingsprocessen. In het laatste geval gaat het om een psychologische benadering vanui t "probleemsol ving".

Deze begrippen leveren de principes volgens welke de drie dimensies beschreven worden.

Afhankelijk van de context van het model worden de geledingen van het model gespecificeerd.

ORDONNANTIE PROCES RUIMTELIJKE TOESTA!'lD (ANALYSE, SYNTHESE, EVALUATI (NIVE/.U)

INTEGRATIE PROCES FUNCTIONELE TOESTAND (AHALYSE, SYNTHESE, EVALUATI (DOMEIN)

----t>

~---ONTWIKKELINGSPROCES RU!f1TELIJK - FUNCTIONELE (ANALYSE, SYNTHESE, EVALUATI TOESTAND (FASE)

BOUWKUNDIG ONTWERPPROCES BOUWKUNDIGE TOEST1-.ND (N,ALYSE, SYNTHESE, EVALUATI

PROCESSEN TOESTANDEN ACTIVITEIT IN ORDON~ANTIE PROCES CTIVITEIT IN NTEGRATIE PROC£5 ACTIVITEITEN, IN NIVEAU FASE ....---, ACTIVITEITEN IN DOME IN FASE

ACTIVITEIT IN ONTWIKKELINGS- ACTIVITEITEN IN 1 FASE PROCES / I L /

vv

v

/ BOU~:KUNDIG ACTIVITEITEN DEEL-PROCESSEN

i:l

z H w ~ 0 0 -o 10 r-1.0 C> ..0 ~ (/) • +-' 01...1:: N .• u r -4- .,.... .0 N s... Q) > 0

De ruimtelijke toestand kan in temporele zin begin- en eindpunt zijn van een activiteit. Binnen deze ontwerpactiviteit voltrekt zich in een cyclisch en iteratief proces de bewerkingscyclus over drie procestoestanden: analyse, synthese en evaluatie. Ontwerp-activiteiten kunnen in serie dan wel parallel geschakeld worden in fasen, die op hun beurt weer de componenten vormen voor een gestructureerd proces. Op deze manier kunnen op een hierarchische wijze bewerkingen op verschillende procesniveaus onderscheiden worden.

Conform de geleding van het GOM- model kunnen in de werkelijkheid drie processoorten onderscheiden worden.

1. Ordonnantieprocessen, (ook wel als coordinatieprocessen aangeduid) afstemming van verschillende ruimtelijke niveaus, waartoe

een vorm behoort,

2. Integratieprocessen, vereniging van verschillende functionele domeinen, binnen een vorm,

3. Ontwikkelingsprocessen, ontwikkeling van de vorm in fasen. Bij al deze processen gaat het. om specifieke activiteiten met specifiek ruimtelijke begin- en eindtoestanden, die corresponderen met de geleding van de dimensies van het model. Binnen deze

ontwerpactiviteiten kunnen, zeals reeds gezegd, drie procestoestanden: analyse, synthese en evaluatie voorkomen.

Ruimtelijke toestand en procestoestand worden binnen het GOM-model in een conceptie samengebracht. Daarvandaan wordt het GOM- model ook wei aangeduid als het model van de bouwkundige ruimte "in verandering". Deze verandering geeft het model zijn dynamisch karakter. De verandering is het gevolg van sociaal economische krachten die uitgeoefend worden door partijen.

De ontwerpactiviteiten corresponderen principieel met mogelijke partijen in het proces: op verschillende niveaus, binnen verschillende domeinen, binnen verschillende fasen.

Juist deze correspondentie maakt het mogelijk informatie bestanden behorende tot de bevoegdheden van de bepaalde partijen, informatie-stromen tussen partijen, en bewerkingen van informatie door partijen te identificeren en te specificeren. Op deze eigenschap wordt

van het ADIS project. Of het model deze eigenschappen heeft wordt door middel van onderzoek nagegaan. Een eerste theoretische toetsing wordt gevonden in het laatste boek van Habraken "The Appearance of the Form" dat langs een andere wijze van benaderen op een model uitkomt, dat structureel gezien grate overeenkomsten heeft met het GOM- model.

Een praktische toetsing biedt het PIM- model van de BNA, dat, ontwikkeld volgens een geheel eigen benaderingswijze, oak een vergelijkbare structuur oplevert.

Empirische toetsingen in een onderwijssituatie, zowel bij de beschrij-ving van gebouwen als processen, !evert (nag) geen conflicten

op bij hantering van het model als beschrijvingswijze.

3.2. DEELPROJECT GOM 1

In dit onderzoek wordt het GOM- model als basis gebruikt voor het ontwerpen van een Architectural Design Information System (ADIS).

Het doel van deze onderzoeksfase was het verkrijgen van een theoretische basis voor ADIS alsmede het zo scherp mogelijk definieren van

deze basis; het leren omgaan met de terminologie, de ~echnieken

en de theorieen van data- bases en, ten laatste, het inpassen van deze verworven kennis in de op voorhand geformuleerde doelstellingen en ideeen inzake ADIS.

De bedoeling van ADIS is het verschaffen van een werktuig ter

bevrediging van de informatiebehoeften van architecten in Nederland. Daarenboven dient ADIS de architecten te voorzien van aile artefacten (methodes en/of programma's) die nodig zijn voor het uitvoeren

van architectonische ontwerpactiviteiten.

ADIS is een systeem dat ontwerpbesluitvorming dient te ondersteunen (Design Decision Support System, DOSS), bedoeld om de architect bij te staan in zijn/haar ontwerpbeslissingen. Dit systeem zal de architect in staat stellen om leden van een design coalition team actief en doelmatig te betrekken bij het ontwerpproces. Deze !eden zijn al diegenen die betrokken zijn bij, actief meewerken

aan en invloed kunnen uitoefenen op het proces van ontwerpbesluitvor-ming. ADIS dient in een netwerk van verspreide data- bases te

voorzien die de informatiebehoeften van aile leden van het design coalition team moe ten vervullen. Daarnaast zal ADIS communicatieka-nalen tussen deze !eden tot stand brengen voor de data flow en

-18-voor het overzicht van de proces-18-voortgang. Deze structuur hebben wij BITI (Bouw Informatica Technische Infrastructuur) genoemd. In dit rapport hebben we onze argumentatie gebaseerd op de toepassig van de Domeinen Theorie op het architectonische ontwerpproces. Dit heeft geleid tot de noodzaak van een beschouwing binnen het

kader van dit rapport van de logische volgorde van het architectonische ontwerpproces, dat volgens de Domeinen Theorie gedefinieerd

is in termen van domeinen, niveau's en fasen, die respectievelijk

de integratie, de coordinatie en de ontwikkeling binnen de architectonische ontwerpactiviteiten voorstellen. Deze argumenten vormen de

basis voor ht herkennen en afbakenen van de datastromen en processen, voorgesteld door het GOM- model. Dit model beschrijft de structuur van een architectonisch ontwerpproces. Daarnaast draagt het

de 'bouwstenen' aan voor BITI. Wij menen dat de toepassing van het GOM- model een grate mate van keuzevrijheid ten aanzien van een ontwerpmethode toestaat zodat de eindgebruiker zeer flexibel kan werken.

Gedurende deze fase van het onderzoek is enerzijds aandacht besteed aan de theoretische basis in de vorm van een uitgebreid literatuur onderzoek, zowel wat de besluitvormingsaspecten als de

informatie-technische aspecten betreft, anderzijds heeft een orientatie plaatsgevonden op de behoeften in de architektenpraktijk. De nadruk heeft daarbij

gelegen op de voorbereiding van het antwerp van een database. De structuur van de database wordt vooral bepaald door het GOM model; dit geldt eveneens voor de programma base.

Zie hiervoor: figuur 1, Ontwerp Data base.

De ontwerpdata base maakt deel uit van een netwerk van verspreide data bases;

CONTENTS COMMUNICATION ADMINISTRATION ARCHITF.CT/DF.SlGNF.R PROJECT-RELATED DATA SOFTWARE TRAO. PAPER-BASED TOOLS

fig. 1 Ontwerp Data Base (pag.19)

SITE DESCRIPTION BU!LDING DF.SCR. OATfl

I

CI.IMATOLOC.lCI\L f). BLDG. PROO. DATA DATI\ 01\Sf: M!INA.S COMMUNICATION S.

DESIGN RES. METIL

STATISTICS TIIEORY Df.ClSlON-MfiKING PUBLICATIONS

BUILDING MANAGEMENT DATA BASE.

fig. 2 Verspreide Data Bases (pag. 19)

~ECHANICAL ENGINEERING DATA BASE BUILDING INDUSTRY DATA BASE.

In deze fase is tevens een model vervaardigd van het bouwkundig ontwerpproces, waarbij is aangegeven op welke momenten in het proces toegang verkregen dient te worden tot de database. Dit model refereert daarbij aan het GOM-model, en aan modellen zoals die in de praktijk (PIM)_ ontwikkeld zijn. Het model van het proces is afgebeeld in figuur 3, Model van een fase.

Voor de vraagstelling, methoden en technieken, en de resultaten van het onderzoek wordt verwezen naar het betreffende deelrapport. De conclusies maken dee! uit van dit deelrapport, hoofdstuk 4.

3.3. DEELPROJECT GOM 2

In dit deel project wordt een onderzoek uitgevoerd naar informatie-stromen tussen en informatiebehoeften bij de verschillende partijen in de bouw. Het onderzoek wordt uitgevoerd door middel van interviews. De structuur van de vragenlijsten wordt bepaald door een drietal

elementen:

Thema's, het GOM- model en de bewerkingscyclus. 1. Vier thema's:

Thema 1:

Inventarisatie van CAAD- programmatuur die op dit moment gebruikt wordt door de betrokkenen ten behoeve van het ontwerpproces.

Thema 2:

Algemene bedrijfsgegevens en een inventarisatie van de informatiestromen tussen ontwerpende en adviserende disciplines in het ontwerpproces.

Thema 3:

Inventariseren van gewenste ontwikkelingen met betrekking tot het gebruik van CAAD- gereedschappen in het ontwerpproces. Thema 4:

Systeemontwerp en de mogelijkheden en beperkingen van hard en software.

-20-l> :J p

-'<, VI VI fTl

<

p

,--c

p ~ 0 :::;,

ProbleM-sto. te

DoMo.lns

Levels

Levels

DoMo.lns

~---L---

ORDERS

Solution o.t tern

a.

t!V(iS

DoMo.lns

Levels

Levels

DoMo.lns

Solutlon-sto. te

2. GOM- model.

Als structuur voor de uitwerking van de interviews is het drie dimensionale GOM- model gehanteerd (fasen, niveaus, domeinen, zie Deel 1, GOM- model)

3. Bewerkingscyclus

Het onderscheid invoer- bewerking - uitvoer heeft bij de samenstelling van de vragenlijst een rol gespeeld. Dit om een zo helder mogelijk onderscheid te kunnen maken tussen wat anderen aan informatie

aanleveren (invoer), welke waarde er op welke wijze door de betrokkenen aan wordt toegevoegd (bewerking) en welke informatie aan anderen wordt aangeleverd (uitvoer).

Om praktische redenen wordt het onderzoek in drie fasen uitgevoerd, waarbij de volgende groepen geinterviewd werden:

fase 1. adviserende (technische en goedkeurende) disciplines, fase 2. ontwerpende disciplines,

fase 3. informatietechnologie leverende disciplines, te weten hard- en software ontwikkelaars en leveranciers.

De eerste fase van het onderzoek is nu uitgevoerd. De resultaten van het onderzoek bepalen mede de vraagstelling aan de disciplines in de volgende fasen van het onderzoek.

Voor vraagstelling, methoden en technieken, en resultaten van het onderzoek wordt verwezen naar het betreffende deelrapport. De conclusies maken deel uit van dit deelrapport, hoofdstuk 4.

3.4. DEELPROJECT GOM 3

In dit deelproject is een onderzoek uitgevoerd naar de bouwstenen van het ontwerpproces. Het gaat hierbij om het identificeren en specificeren van zogenaamde besluitvormings-bouwstenen, die relevant dienen te zijn ten aanzien van twee aspecten, namelijk:

1. het besluitvormingsaspect, 2. het programmeringsaspect.

Bij de bestudering van de besluitvorming is uitgegaan van het GOM model; bij de bestudering van de programmeringsaspecten werden gebruik gemaakt van de methode DeMarco en het computerprogramma "Analyst".

De technische hulpmiddelen werden gehanteerd in een onderzoek-strategie die voor deze fase nag beperkt van opzet was.

-21-Daarbij werd uitgegaan van een fase van het ontwerpproces, waarbij dit proces bovendien nag imaginair was (fig.4) In wezen ging het om een proefonderzoek om na te gaan of de gekozen techniek.en adequaat zijn voor een meer uitgebreid onderzoek in de praktijk van het ontwerpen.

Op basis van de resultaten van de analyse van het ontwerpproces is een voorstel gedaan voor een categorisering van bouwstenen in een matrix; zie fig.5. Hierbij werden twee uitgangspunten gehan-teerd:

1. procesrichtingen en procestoestanden van het GOM- model, 2. een hierarchie van processen, waarbij de

besluitvormings-bouwstenen geflankeerd worden door grotere zogenaamde besluitvormingsmodulen en kleinere zogenaamde programma-modulen,zie fig.6

Het verband tussen de matrix en de uitgevoerde analyse is nag

niet eenduidig aan te geven; oak is nag niet nagegaan of het mogelijk is met deze bouwstenen daadwerkelijk willekeurige bouwkundige processen te analyseren en te ontwerpen. Dit onderzoek zal in de derde fase uitgevoerd moeten worden. Een groat probleem bij de identificatie van de bouwstenen is de bepaling van het niveau van algemeenheid, omdat ze hanteerbaar moeten zijn voor zowel bouwkundige ontwerpers als voor systeemontwerpers.

Vooruitlopend op de resultaten van nader onderzoek is er wei een proeve gegeven van de wijze van specificatie van de bouwstenen. Deze in programmatuur vertaalbare besluitvormingsbouw-stenen bepalen het procesmatig bestanddeel van de inhoud van het ADIS.

Voor vraagstelling, methoden en technieken, en resultaten van het onderzoek wordt verwezen naar het betreffende deel rapport. De conclusies maken deel uit van dit deelrapport, hoofdstuk.4

Voor het gedetailleerd verslag van de uitvoering van het onderzoek wordt verwezen naar de geannoteerde agenda's plus verslagen van de vergaderingen van de begeleidingscie., zoals die gehouden

zijn op respectievelijk 29 november 1984, 26 februari 1985, 28 mei 1985 en 24 september 1985.

Deze stukken hebben ook gediend als voortgangsverslag ten behoeve van de lOP- cie bouw.

\

HAALBAARHEID

-SYSTEM-

_STUDIE

FLOW-CHART

~

INTEGRAAL-

-

PROGRAMMA-MAKEN

\ I PROGRAMMA

FASE

-UIT SORTCR£11 tiAAR DRDCN

VDDRLOPIG

J;

DNTWERP

VDOR ELK£ DRDC• GCGCV£NS UITSORT£R[I1 tiAAR llOME:Jtittl

~

Gt!RUJKSDOM£111 ~JT SPLIT SCN 11AAR UB-DOME:IN£:11

J

...

,.

,

.-t

<I f4AAK Ol'fTI.Jt:RP GE:SRUIKSVARIAHT

I

oluu., ftlp't ..,

okay

' /

/ I TOI:TS VARIAHT AAI1

I

"' rrs...t- L DUURZMMH.LVE:RVAARD.

-toot

okoy _{-...1 TOLTS VARIANT AAI'1}

I

'i:.~-

"'I reo • sco

ot

.... I 11'1T[GqAAL

I

olcoy / j VOORLOPJG OHTI.Jt:RP

\1

DEFINITIEF

DNTWERP

MAKEN

B E S L U I T V 0 R M I N G S B 0 U W S T E N E N

CAT EGO-

_<

_...

...

-RIEEN

X

-

_CJ t-X ex

_z:

_<

<

t-

-::l

PRO-

ex

...

""

_,

CJ :::E

t-<

CESSEN

c c

...

>

I ex

...

c ' a. CJ t-

...

ONTWIKKELE:NDE COORDINEREND£ INTEGRERENDE

BESLUIT- ~S- ~- PRfJGRAHHA-BDUWSTENEN

BESLUITVDRMING

HOOFDSTUK 4 CONCLUSIES EN AANBEVELINGEN.

Het algemene kader van de conclusies is gegeven in de uiteenzettingen van het vorige hoofdstuk. In dit hoofdstuk worden de teksten uit

conclusies van deelrapporten letterlijk overgenomen.

De gebezigde terminologie is binnen elk deel- onderzoek constistent. Ondanks de hantering van het GOM- model als algemeen uitgangspunt treden tach inconsistenties op in de terminologie tussen de deelonder-zoeken. Voor een deel is dit terug te voeren op de ontwikkelingen die het GOM- model juist waar het de terminologie en de definities van begrippen betreft, tijdens de looptijd van het onderzoek heeft doorgemaakt. Voor deze rapportage, die gezien meet worden als een interimrapportage, wordt de authenticiteit van de samenvattingen en de conclusies van de twee deelprojectleiders gerespecteerd.

ALGEMENE CONCLUSIE

Het GOM- model, en de afbeelding daarvan in de vorm van een ontwerpinformatiematrix wordt als een bruikbaar hulpmiddel gezien ten aanzien van de analyse en synthese van bouwkundige objecten en processen.

Het GOM- model Ievert een bruikbaar kader voor de ontwikkeling van procesmodellen, die relevant zijn, zowel ten aanzien van de inrichting van de besluitvorming, als ten aanzien van de informatie en computertechnische vertaling daarvan.

Het GOM- model kan een bijdrage leveren aan de formulering van modellen, die als uitgangspunt dienen voor de ontwikkeling van een informatietechnische infrastructuur als bedoeld in het werkplan "Bouwinformatica en Computergebeuren".

Het GOM- model meet in het kader van deze rapportage gezien worden als een middel om een doel te bereiken. Dit doel is het

leveren van een bijdrage aan de ontwikkeling van een informatie-technische infrastructuur. Deze structuur wordt daarbij primair bepaald door de informatiestromen tussen de verschillende partijen in het ontwerpproces, de zogenaamde 'interfaces'.

Kuypers geeft in zijn boek 'Grondbegrippen van politiek' een opsomming van eigenschappen van een middel. Door na te gaan over welke

eigenschappen het GOM- model beschikt in relatie met zijn doe! kan "van buitenaf" een concluderend beeld geschetst worden van

1. Effectiviteit

Het GOM- model is effectief, daar het de mogelijkheid biedt alle partijen, met hun rollen en taken, te identificeren, en hun informatie vraag- en aanbod te specificeren, terwijl tevens aangegeven kan worden welke kwaliteiten zij aan het te ontwerpen object toevoegen.

2. Alternatieve aanwendbaarheid.

Het GOM- model heeft een veelvoudige aanwendbaarheid.

Het is niet aileen een middel bij het ontwerpen van een informatie-technische infrastructuur, maar oak, zeals in dee! 2, ADIS,

is aangetoond, voor de ontwikkeoling van een ontwerpinformatie-systeem, een zogenaamd design decision support system. Daarnaast heeft het model, zeals uit de ontwikkelingsgeschiedenis (dee!

1, GOM- model, bijlage 1) kan blijken, een functie vermeld

bij de opstelling van onderwijs en onderzoek programma, leerstoelen-plan en eindtermen van de afdeling der Bouwkunde van de

THE. Een geheel ander toepasingsveld heeft gelegen in de praktijk van het uitvoeren van grootschalige ontwerpprojecten in binnen - en buitenland.

3. Totale werking.

In dit kader dienen oak de negatieve effecten van het model begrepen te worden. Het zou kunnen zijn dat de geledingen van het model ontwerpprocessen in een te strak keurslijf persen. Dit zou dan moeten blijken uit de toepassing van het model

bij beschrijving en antwerp van antwerp- en besluitvormingsproces-sen. Deze toepassing heeft tot nu toe slechts op beperkte

schaal plaats genomen, waardoor mogelijke nadelen van het model nag niet aan het daglicht gekomen zijn.

4. Onmisbaarheid.

Het GOM- model als zodanig is niet als onmisbaar te beschouwen. Wel kan gesteld worden dat alle aspecten die het model tracht te ordenen bij het ontwerpen van een infratechnische infrastructuur aan bod zullen moeten komen, maar mogelijkerwijs in een

ander structureel verband. Wellicht dienen tussen nag andere aspecten geordend te worden die de opstellers van het model onterecht buiten beschouwing hebben gelaten.

5. Toereik.endheid.

Het GOM- model is zeker niet toereikend met betrekking tot het nagestreefde doel. Dit kan al blijken uit het gebied,

waartoe het model zich beperkt, namelijk dat van het bouwkundig ontwerpen. Andere gebieden, name~ijk die van de bouw, het

gebruik en het beheer worden niet afgedekt. Deze gebieden zullen een eigen inbreng moeten hebben bij de ontwikkeling van de informatietechnische infrastructuur.

6. Efficientheid.

Hierbij moet de vraag beantwoord worden, of er geen alternatief middel is, dat hetzelfde doel, eventueel ten koste van minder offers kan bereiken. Deze vraag kan aileen beantwoord worden, wanneer alternatieve middelen vergelijkenderwijs onderzocht worden. Dit is tot op heden nag niet gebeurd.

CONCLUSIES GOM - 1. UIT DEEL 2, ADIS.

De resultaten van dit onderzoek bestrijken de GOM- deelprojecten 1 en 2. Het eerste was een onderzoek naar het theoretische referentie-kader van ADIS; het tweede behelsde de uitvoering van een aantal case-studies. De conclusies van deze fase werden gebaseerd op zowel de theoretische onderbouw als de uitkomsten van de case studies.

De conclusies wijzen op de noodzaak van een aantal veranderingen in de werkaanpak binnen de praktijk van de architectuur. Deze voorgestelde verandering dient gezien te worden in de context van de invoering van lnformatie- en Computertechnologieen in het werkmilieu van een archtiectenpraktijk. De uitkomsten van de case- studies tonen een toenemende belangstelling van de zijde van het architectenvak aan in de toepassingsmogelijkheden van deze technologieen om tot een verbetering van hun vakmatige kwaliteiten te komen. Bovendien duiden ze op het belang en de onontbeerlijkheid van zulke ontwikkelingen. Het ADIS- concept werd ter invulling hiervan ontwikkeld.

In onze argumentatie kwam naar voren dat de hoeveelheid voor het architectonische ontwerpproces benodigde informatie snel toeneemt. ADIS zal de mogelijkheid bieden om tijdens dit proces continu toegang tot deze informatie te hebben. Bovendien bevat

informatie die door de architect ten behoeve van :zijnihaar project kunnen worden opgevraagd c.q. gebruikt.

Deze worden met middelen of artefacten aangeduid. De middelen kunnen modellen, methoden en technieken zijn. Zij kunnen bovendien deels of geheel geautomatiseerd :zijn. In dit verband noemen wij ze Programma's, bijvoorbeeld de CAAD Programma Pakketten etc. Deze programma's zijn hulpmiddelen bij de uitvoering van de architectonische ontwerpactiviteit en kunnen varieren van ontwerpprogramma's tot evaluatieprogrammapakketten. Deze middelen zijn beslist noodzakelijk voor een juiste bedrijfsvoering van een architectenpraktijk en zullen ontegenzeggelijk de vakmatige deskundigheid van de architecten op een hager plan brengen door hen bredere mogelijkheden te bieden om hun intuitie en creativiteit verder te ontplooien.

Voorts beargumenteerden wij dat een tweede aspect, dat van groat belang is, van ADIS deel moet ui tmaken: een systeem tot ondersteuning bij het nemen van ontwerpbeslissingen (Design Decision Support

System, oak DOSS). Wij hebben uitgelegd dat deze faciliteit van ADIS de participatie van !eden van het design coalition team zal vergemakkelijken. De !eden van het design coalition team worden gedefinieerd als al diegenen die betrokken zijn bij, geraakt worden door of in staat zijn om direct of indirect invloed uit te oefenen

op het proces van het ontwerpen van de gebouwde omgeving. Participatie is een begrip dat, noodzakelijkerwijs, in verband met de imagoverandering van het architectuurvak werd ingevoerd.

AI de door ADIS te verlenen diensten geschieden via een aantal data- bases waarin alle benodigde middelen en gegevens opgeslagen zijn. Deze worden aangeduid met de termen projectgebonden base en algemene base. De laatste wordt gemakshalve data-bank (waarin alle architectonische ontwerpgegevens te vinden

zijn) en programma- bank (waarin alle ontwerphulpmiddelen, inclusief de computerprogrammatuur te vinden :zijn genoemd.

Tevens verwijzen wij in het rapport in algemene termen naar het eisenpatroon voor de totstandkoming van ADIS zelf. Wij hebben

geredeneerd dat, teneinde tot een juiste omschrijving van de betrokken typen data en processen te kunnen komen, eerst de logische volgorde van het architectonische ontwerpproces vastgelegd moet worden. Dit model, dat op de Domeinen Theorie is gebaseerd, zal ons als leidraad dienen bij het bepalen van de datastromen en processen.

-26-De logische volgorde van het architectonische ontwerpproces wordt bepaald door een drietal dimensies: domeinen, niveau's en fasen. Deze staan voor respectievelijk de integratie, de coordinatie en de ontwikkeling binnen de architectonische ontwerpactiviteit .

. Deze drie dimensies zijn onlosmakelijke onderdelen van ordes (bijvoorbeeld ruimtelijk/fysieke, sociaal/economsiche of politiek/-culturele ordes).

Tenslotte worden de resultaten van deze onderzoeksfase gezien als een concreet startpunt voor de vlgende fasen van het onderzoek. De doelstelling zal zijn, deze resultaten te gebruken en ze verder te ontwikkelen. Deze fase van het onderzoek heeft te doen met

eisenspecificaties en een initieel overzicht van ADIS. De eropvolgende fasen van het onderzoek behelzen onder meer een haalbaarheidsstudie en systeemontwerpmatige aspecten van ADIS. Een aantal volgende fasen wordt aanbevolen, die echter buiten het kader van dit onderzoek vallen. Tijdens deze volgende fasen zou het onderzoeksteam een nauwe samenwerkingsrelatie moeten hebben met deskundigen

vanuit de gebieden der syteemanalyse en informatica om de \lerdere, te weten logische en fysieke, ontwikkeling van ADIS uit te kunnen voeren. Dit zal achtereenvolgens leiden tot de programmatische, implementoire en operationele fasen van ADIS.

De doelstelling van deze onderzoeksfase was het formuleren van een theoretische basis van deze ontwikkeling, het vertrouwd geraken met terminologieen, technieken en theorieen van data- bases en, uiteindelijk, het inpassen van de verworven kennis in de vantevoren geformuleerde doelstellingen voor en ideeen omtrent ADIS.

ADIS moet de architect in Nederland een artefact voor zijn/haar informatiebehoefte bieden. Daarnaast moet het de architect een veelheid aan hulpmiddelen voor de uitvoering van het ontwerpproces bieden (methoden en/of programma's)

ADIS is in wezen een netwerk van verspreide data- bases dat de ontwerpmatige informatiebehoeften van de leden van het design coalition team zal vervullen. Oak zal het geschikte communicatie-kanalen scheppen tussen deze leden in termen van data en processen. ADIS is een geintegreerd onderdeel van BITI. (Bouw Informatica Technische Infrastructuur). De BITI is in wezen een netwerk van verspreide data- bases dat de gehele bouwindustrie ten dienste staat, de architecten, de aannemers, de technici etc. Het ARGOM

gericht op de toepassing bij de ontwikkeling van ADIS) is, menen wij, van belang bij de toepassingskeuze van de versschillende ontwerp-rnethodieken. Het verschaft ADIS een hoge mate van flexibiliteit zodat de gebruiker van het syteem de vijheid zal hebben omelke gewenste ontweprmethode te kiezen.

De volgende fasen van het onderzoek zullen gewijd zijn aan het

ontwikkelen van de structuur van ADIS, voorafgaaand aan de systeem-ontwikeklingsfase.

CONCLUSIES GOM 2, UIT DEEL 5, CASE STUDIES.

1. Verschuiving van werkzaamheden, rollen en functies

Een groat aantal van de geinterviewde personen maakt melding van een verschuiving van werkzaamheden door bepaalde partijen in het bouwproces, mede onder invloed van de automatiseringsontwik-keling. Traditioneel gegroeide rolpatronen en te vervullen functies zijn hierbij aan verandering onderhevig.

Zo signaleert de bouwkostendeskundige dat het maken van uittrekstaten en begrotingen steeds vaker door architectenbureaus zelf wordt

gedaan, en voor minder geld.

Het bouwbedrijf signaleert een duidelijke teruggang in het werken met bouwteams, met name in de woningbouw.

Plannen worden in toenemende mate geinitieerd en ontwikkeld voor risico van het bouwbedrijf. Men zal steeds meer gaan werken op basis van produktspecificaties. Met betrekking tot de uitvoering signaleert men het in toenemende mate werken met multidisciplinaire teams, die het werk van de huidige onderaannemers voor een groat dee! overnemen.

De architect zou zich volgens de aannemer meer moeten gaan

richten op het nemen van initiatieven en het initieren van projecten. Tevens wordt grate waarde gehecht aan kosteninzicht bij de architect en samenwerking in een vroegtijdig stadium. Volgens de organisatieadviseur komt het ontwerpen onder grate druk te staan, enerzijds vanuit

de programmeringskant, die opschuift naar het maken van het functionele antwerp, en anderzijds vanuit de uitvoering., Een andere trend die gesignaleerd kan worden is dat de opdrachtgever steeds hardere eisen aan het antwerp gaat stellen. Verwacht wordt dat

de rol van de architect in de woningbouw sterker aan belang zal inboeten dan in de utiliteitsbouw.

Men stelt dat de huidige situatie, waarin werkmethoden sterk aan verandering onderhevig zijn, aan de ene kant bedreigend is, maar oak kansen biedt voor degene die ze oppakt, inclusief de architect. CAD- en expertsystemen bieden de architect kansen om kennisgebieden te betreden die voorheen voor hem niet open lagen.

In de toekomst zal men in toenemende mate gaan werken met bij het gebouw behorende datasets. Men ziet in relatie hiermee een ontwikkeling die gaat van projectmanagement naar informatie-management.

De toeleverancier ziet in de toekomst het werk van de vertegenwoordiger ('de bedrijvenbezoeker') van zijn bedrijf sterk veranderen of zelfs

verdwijnen onder invloed van toekomstige communicatiemogelijkheden. Met name de rol van de architect zal in de woningbouw sterk veranderen. Deze zal zich meer op het gemeenschapsgedeelte (de drager) en

de stedebouw gaan richten en de aannemer op het totaalproduckt. De overheid trekt zich terug als financier van volkshuisvesting. Er zal meer gebouwd worden voor eigen risico. Produktontwikkeling zal meer plaatsvinden binnen een samenwerkingsverband van uitvoering . en leverancier.

De bouwfysich adviseur signaleert onder invloed van automatisering een trend, waarbij de architect zich in toenemende mate beizg houdt met bouwfysische aspecten. Hij acht het niet waarschijnlijk dat onder invloed van automatisering disciplines zullen verdwijnen of nieuwe discplines zullen ontstaan. Er zullen wei verschuivingen plaatsvinden, waarbij in eerste instantie gedacht wordt aan een versterking van de coordinerende functie binnen het antwerp-en bouwproces.

2. Knelpunt informatieoverdracht en automatisering

Volgens de bouwkostendeskundige vormt de volgorde en coderingswijze van begrotingen een belemmering in het kader van informatieoverdracht en automatisering. In Nederland wordt gewerkt met vele bestekken en wijzen van coderen.

Men ziet grate gevaren in het automatisch uittrekken en prijzen van elementen omdat men zich bij het prijzen continu moet realiseren in welke context het element zit. Automatisering hiervan wordt desondanks niet afgewezen, maar wordt beschouwd als iets dat aileen een (beperkt) hulpmiddel kan zijn.

De constructieadviseur geeft aan de stand van de techniek op dit moment nog niet ver genoeg is voor het effectief toepassen

- .

van een CAD- systeem binnen zijn bedrijf. Als oorzaken hiervoor

worden aangegeven de grate varatie in werkzaamheden, de kleinschaligheid en het specifieke karakter ervan en de grate diversiteit aan partijen

en produkten in de bouw.

In dit verband wordt het belang onderstreept van een integrale

aanpak van automatisering in de bouw, waarbij de diverse werkzaamheden meer op elkaar afgestemd dienen te worden.

Het bouwbedrijf signaleert een belangrijk knelpunt. Door het ontbreken van adequate controlemethoden worden veel fouten gemaakt (zowel

in teken- als calculatieprogramma's). Pogingen om de automatiseringafdeling te verzelfstandigen (oak als softwareleverancier) zijn gestopt,

omdat iedere aannemer blijkbaar zijn eigen methodes hanteert. Voor het maken van bestellijsten wordt opnieuw uitgetrokken. Als reden hiervoor wordt met name gewezen op het feit dat dit nu eenmaal de traditie is en dat het moeilijk is om te zien waar

bepaalde materialen zitten. Men wijst in dit verband op de moeilijkheden die kunnen ontstaan bij het hanteren van verschillende coderingen

door verschillen de afdelingen van het bedrijf.

Men ziet weing heil in het werken met zogenaamde 'recepten': deze zijn gevoelig voor het maken van fouten doordat er geen gedetailleerde informatie meer in het hoofd van de calculator

zit. Gezien de grate risico's die de aannemer loopt, moeten dergelijke foutkansen zo veel mogeljk voorkomen worden. Oak in een aparte afdeling voor het het bijhouden van prijsgegevens ziet men niets, vanwege het ontbreken van het "contact met het gebouw".

Gecentraliseerde ontwikkelingen zijn gedoemd te mislukken, omdat de vraag altijd specifieker is dan op deze algemene wijze aangeboden wordt.

De bouwfysisch adviseur signaleert de discrepantie tussen de verschillende niveau's van gedetailleerdheid waarop gewerkt wordt en de gedetailleerdheid waarop gewerkt wordt en de gedetailleerdheid van computerprogramma's. Vaak moet meer informatie ingevoerd worden dan in het betreffende stadium aanwezig of noodzakelijk is. Daarnaast heeft niet elke discipline behoefte aan dezelfde gedetailleerdheid van informatie. Het werken met informatiedragers die al deze informatie bevatten leidt veelal tot onnodig lange respons(wacht)tijden. Aan de andere kant komt het voor dat informatie die juist wel relevant is blijkt te ontbreken. In het algmeen kan gesteld worden dat er bij program-matuurontwikkeling een te grate mate van gedetailleerdheid wordt nagestreeft in een te vroeg stadium.

Oak wordt het gevaar gesignaleerd van een black-box-effect. De architecten hebben vaak niet de tijd om zich echt met programmatuur vertrouwd te raken, en computerresultaten hebben geen absolute waarde en dienen met de nodige deskundigheid geevalueerd te worden.

De vertegenwoordiger van de overheid signaleert eveneens een belangrijk probleem met betrekking tot informatieoverdracht tussen de verschillende participanten in verband met de grate diversiteit aan informatie.

3. Opleiding en onderwijs

Een beperkt aantal bedrijven stimuleert zijn personeel in verband met de automatiseringsontwikkeling, door hen op cursus te sturen. Verder :iiet men voor de opleidingen een taak weggelegd, niet zo zeer in het ontwikkelen van toepassingen, maar meer in het vertrouwd maken van mensen met nieuwe ontwikkelingen. Op

4. Relatie kosten- kwaliteit

Met name de toeleverancier geeft aan dat een beter produkt alleen met behulp van automatisering tegen aanvaardbare kosten geproduceerd kan worden.

De installatie adviseur signaleert dat dankzij automatisering grate voordelen zijn behaald abij het berekenen van leidingen. Door de complexiteit van het leidingstelsel bij wat grotere gebouwen was het in het verleden niet mogelijk de installatie als geheel handmatig uit te rekenen. Hierdoor was men genoodzaakt met forse overmaten te werken. Met behulp van de computer is dit wel mogelijk. De huidige berekeningen leveren hierdoor niet aileen materiaalbesparing op, maar verhogen de kwaliteit van de installatie omdat de verschillende onderdelen beter op elkaar zijn afgestemd. Daarnaast ligt het grate voordeel in het snel kunnen wijzigen en opnieuw kunnen doorrekenen vna de installatie bij wijziging van het antwerp.

Het bouwbedrijf ziet automatisering als een belangrijk hulpmiddel om de produktie in de toekomst op peil te houden (dit in verband met de vergrijzing van de bevolking en het gebrek aan goed geschoold personeel voor het bouwbedrijf).

5.· Informatieoverdracht en modulaire coordinatie

In het kader van informatieoverdracht en automatisering zal er volgens de toeleverancier in toenemende mate gewerkt worden op basis van plaats- en maatafspraken (modulaire coordinatie).

Men is niet overtuigd van het f.eit dat computers het produktieproces dermate flexibel maken dat deze afspraken niet meer nodig zijn. Modulaire coordinatie is noodzakelijk voor fundamentele produktont-wikkeling.

6. Informatieoverdracht bij de diverse partijen

a. De overheid

De informatie waarmee de afdeling Stadsontwikekling aan het

werk gaat, wordt voornamelijk geleverd door de afdeling Landmeetkunde door middel van kadasterkaarten. De meeste gegevens blijven

-32-binnen de dienst. Wat near buiten komt (near architect, opdrachtgevers en goedkeurende instanties) zijn bebouwingsvoorstellen. Resultaten van stedebouwkundige plannen gaan voor toetsing van maatgegevens terug naarde dienst Landmeetkunde.

b. De constructieadviseur.

Men !evert meestal op basis van een voorlopig antwerp meerdere constructieve varianten met kostenconsequenties aan de architect. Deze beoordeelt op basis van kosten en esthetica. In geval van prefabconstructies wordt gewerkt met gegevens van de fabrikant. Bestandsinformatie, voorzover daar sprake van is, wordt binnen het bedrijf bijgehouden.

Gedacht wordt aan de aanschaf van een CAD-systeem, met name vanuit de gedachte om meer service te kunnen leveren naar de opdrachtgevers (uitholling markt door meer prefab-constructies). De snelheid van leveren is hierbij een belangrijk punt.

De constructuer !evert constructieve berekeningen bestektekeningen en bestek, in de meeste gevallen aan architect, en soms aan de opdrachtgever. Oak infrormatie met betrekking tot goedkeuring en aanvraag bouwvergunning van het constructieve gedeelte. De constructeur maakt aileen indirect gebruik van getekend materiaal van de architect, dat wil zeggen de informatie wordt overgetekend.

c. Het bouwbedrijf.

· Een groat belang wordt gehecht a an communicatie tussen verschillende computersystemen, zowel binnen het bedrijf als tussen verschillende bedrijven: tijdwinst, voorkomen van papierhandel, gerichter overleg mogelijk op afstand.

De belangrijkste informatie wordt door de architect in de ontwerpfase op tekening aangeleverd. Men hecht door het ontbreken van adequate controlemethoden niet veel waarde aan de informatie die door

middel vari geautomatiseerd tekenwerk tot stand is gekomen. Duidelijke ei&en aan het door de .architect te verrichten tekenwerk, om in

de uitvoering optimaal duidlejk te zijn, kan (nog) niet worden gegeven. Men onderstreept het feit dat naar verschillende partijen toe verschil-lende soorten informatie nodig is (bv. naar een bouwer, leverancier, opdrachtgever, koper of gemeente).

d. De organisatieadviseur.

Men betrekt ontwerpers bij voorkeur bij de planontwikkleing aan het einde van de formulering van het eisenpakket.

Of het de kant van integratie (bedrijven pakken het hele veld) of communicatie (informatie tussen bedrijven wordt uitgewisseld) op zal gaan, blijft vooralsnog onduidelijk.

De twee stromen confectie en maatwerk zullen blijven bestaan

en zullen zich onder invloed van automatisering sterker gaan onderscheiden. De confectie leent zich bij uitstek voor automatisering, voor maatwerk kunnen binnen korte tijd meer mogelijkheden worden afgestast

dan voorheen.

e. De toeleverancier.

Bij produktontwikleing vindt overleg plaats met goedkeurende instanties (bijvoorbeeld gaskeuringen). In enkele gevallen vindt projectgebonden overleg met de architect plaats. Tevens !evert men prijsinformatie naar aannemers, architecten, opdrachtgevers en adviseurs.

De geleverde informatie moet voor de ontwerper voldoende zijn om mee uit de voeten te kunen • De uniforme presentatie van produkten (Sf /B) heeft een beperkte waarde doordat vanuit een

beperkte hoek (uniformiteit) wordt gekeken en niet vanuit de optimaliseringshoek.

f. De bouwfysisch adviseur.

Een gunstige omstandigheid is het feit dat bouwfysische berekeningen in hoge mate zijn gestandaardiseerd. De werkwijze van verschillende bureau's zullen hierdoor, in tegenstelling tot veel andere werkzaamheden die in het ontwerpproces plaatsvinden, niet ver uit elkaar liggen.

De bestandsinformatie is afkomstig van (NEN) normen, materiaalinformatie (bestand wordt intern bijgehouden) afkomstig uit literatuur, TNO,

en fabrikanten. Uitganspunt wordt meestal gevormd door de ontwerptekeningen van de architect. De (eind)rapportage is, afhankelijk van de opdracht,

bestemd voor architecten, opdrachtgevers, controlerende instanties en eventueel de kostendeskundige en het bouwbedrijf.