Onderzoek naar de ontwerpmethodiek ten behoeve van CAAD programmapakketten. Deel 2: ADIS : ontwikkeling van het systeem : IOP - GOM - CAD - projekt GOM 1; fase 1984-1985

Onderzoek naar de ontwerpmethodiek ten behoeve van

CAAD programmapakketten. Deel 2: ADIS : ontwikkeling van

het systeem : IOP - GOM - CAD - projekt GOM 1; fase

1984-1985

Citation for published version (APA):

Beheshti, M. R., Monroy, M. R., & Botma, E. F. (1986). Onderzoek naar de ontwerpmethodiek ten behoeve van CAAD programmapakketten. Deel 2: ADIS : ontwikkeling van het systeem : IOP - GOM - CAD - projekt GOM 1; 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

p

6

G

Afdeling Bouwkunde Vakgroep

0

O

Architectuur en Urbanistiek · M045226 • . .

-"=

Technische

Hogeschool

~----~

Eiraaraeven

Gom deelnemers in 1985

DEEL 2 ADIS:

ONTWIKKELING VAN HET SYSTEEM

IOP - GOM - CAD - Project GOM l; FASE 1984 -1985 Auteurs: M.R. Beheshti M.R. Monroy E.F. Botma 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. Coppelrnans, Ir. P.J.M. Dinjens, Ing. J.P.M. van Geest, M.Janneman, M. Ir.

w.s.

Schaefer,Ir A.P. Thijssen, Dr. ir. H.M.G. Trum.

Gast :Ir. M.R. Monrooy.

van Kempen, arch. H.B.o.,

0 1 1 .1 1 .1 .1 1.1.2 1 .1. 2 1. 2. 1 1.2.2 1.2.3 1.2.4 1. 2. 5 1 . 3 . 1. 3 .1 1. 3. 2 1. 3. 3 1 • 3. 4 L.3.5 INHOUDSOPGAVE SAMENVATTING Dankzegging Introductie

Het doel van ADIS

Het beà:>gde resultaat van dit onderzoek

Theoretisch kader van het onderzoek

Definities

Data en informatie Het be9rip 'systeem' Data-base en data-bank Hypothesen Hypothese 1 Hypothese 2 Hypothese 3 Hypothese 4 Hypothese 5 Het GOM-mode 1 De Domeinen Theorie Architectonische ontwerpmodellen

Logische volgorde binnen het architec-tonische ontwerpproces 4 6 7 8 9 11 12 13 14 15 16 17 20 22 23 26 27 30 30 40

Modellen van het ontwerpproces 51 Het ARGOM-model van de architectonische ontwerpactiviteit 54

1.3.5.1 1.3.5.2 1.3.5,3 1. 3. 6 1.4.1 1.4.2 1.4.3 2 Domeinen Niveau's Fasen

Analyse van het ARGOM-model Het begrip 'ADIS'

Zaken gerelateerd aan de ontwikkeling van ADIS

De basis-vereisten van ADIS

De doelgroepidentificaties van ADIS

CONCLUSIES 57 60 62 67 74 74 75 77 79

Samenvatting

Dit is het rapport van fase 2 van een onder-zoeksproject met als doel de ontwikkelings-voorbereiding van een Architectural Design Information System (ADIS), een architectonisch ontwerpinformatiesysteem. Het doel van deze onderzoeksfase was het verkrijgen van een theoretische basis voor ADIS alsmede het zo

scherp mogelijk defini~ren van deze basis; het

leren omgaan met de terminologie, de technie-ken en de theorieên van data-bases en, ten

laatste, het inpassen van deze verworven ken-nis in de op voorhand geformuleerde

doelstel-lingen en idee~n inzake ADIS.

De bedoeling van ADIS is het verschaffen van een werktuig ter bevrediging van de informa-tiebehoeften van architecten in Nederland. Daarenboven dient ADIS de architecten te voor-zien van alle artefacten (methodes en/of

pro-gram~a' s) die nodig zijn voor het uitvoeren van architectonische ontwerpactiviteiten.

ADIS is een systeem dat ontwerpbesluitvorming dient te ondersteunen (Design Decision Support

System, DDSS), 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 leden zijn al diegenen die betrokken zijn bij, actief meewerken aan en invloed kunnen

ui toef enen op het proces van ontwerpbeslui

t-vormi ng. ADIS dient in een netwerk van ver-spreide data-bases te voorzien die de informa-tiebehoeften van alle leden van het design coalition team moeten vervullen. Daarnaast zal ADIS communicatiekanalen tussen deze leden tot stand brengen voor de data flow en voor het overzicht van de procesvoortgang. Deze struc-tuur hebben wij BIT! (Bouw Informatica Techni-sche Infrastructuur) genoemd.

In dit rapport hebben we onze argumentatie

gebaseerd op de toepassing van de Domeinen

Dit heeft geleid tot de noodzaak van een be-schouwing binnen het kad~r van dit rapport van de logische volgorde van het architectonische ontwerpproces, dat volgens de Domeinen Theorie gedef inieêrd is in termen van domeinen, ni-veau' s en fasen, die respectievelijk de inte-gratie, de coördinatie en de ontwikkeling binnen de architectonische ontwerpactiviteiten voorstellen. Deze argumenten vormen de basis voor het herkennen en afbakenen van de data-stromen en processen, voorgesteld door het GOM-model. Dit model beschrijft de structuur van een architectonisch ontwerpproces. Daar-naast draagt het de 'bouwstenen' aan voor BITI. Wij menen dat de toepassing van het GOM-model een grote mate van keuzevrijheid ten aanzien van een ontwerpmethode toestaat zodat de eindgebruiker zeer flexibel kan werken.

SLEUTELWOORDEN

*

*

*

*

*·

*

*

*

Architectural Design Informatie Systeem (ADIS)

Design Coalition Team (DCT)

architectonische ontwerpparticipatie project data-base

algemene data-base (data-bank en pro-gramma-bank)

logische volgorde van architectonische ontwerpactiviteiten

Domeinen, Niveau's en Fasen

DANKZEGGING

De auteurs van dit rapport willen op deze plaats hun dank uiten aan het adres van de

instantie die dit project financi~el en

ander-zijds mogelijk maakte: de IOP-commissie van het Ministerie van Economische Zaken. Zonder

hun aanmoediging en steun (in zowel financi~el

als moreel opzicht) zou dit onderzoek niet zijn uitgevoerd. voorts willen de samenstel-lers de auteurs van het in dit rapport ge-bruikte en aangehaalde bronmateriaal bedanken. Hoewel door ons inzake de aanhalingen de grootst mogelijke zorgvuldigheid werd be-tracht, zijn eventuele fouten geheel voor onze rekening.

0. Introductie

In dit raport wordt het concept van een Archi-tectural Design Information System (ADIS) besproken. Omwille van de duidelijkheid defi-niêren wij hierbij de termen die worden ge-bruikt:

het eerste woord is 'Architectural', waardoor aangegeven wordt dat de architect als eind-gebruiker van het systeem wordt gezien. Uit de combinatie 'Architectural' en 'Design' moge duidelijk worden dat ADIS bedoeld is om de architect ontwerpmiddelen en -informatie aan te reiken ten behoeve van de verschillende fasen van de architectonische ontwerpaktivi-tei t. Deze middelen en gegevens dienen hem/haar te voorzien van 'Informatie' voor het besluitvormingsproces. 'Systeem' verwijst naar de samenhang, het apparaat als het ware, waar-in deze hulpmiddelen en data worden geplaatst. Naarmate het architectonische ontwerp voort-schrijdt zal het ontwerpteam een verscheiden-heid aan data behoeven om over die informatie te beschikken waarop de beslissingen worden gebaseerd. Alle benodigde informatie moet

opgeslagen en uiteindelijk worden verwerkt in

het besluitvormingsproces.

Naast de data heeft de architect geschikte hulpmiddelen en van toepassing zijnde proce-dures tijdens de verschillende stadia van het architectonische ontwerpproces nodig om voor-uit te kunnen met het ontwerpwerk. De comple-xiteit van het proces zal toenemen wanneer men de participatie van het design coalition team bij het proces betrekt.

Het systeem dient een weerspiegeling te zijn van het ontwerpproces en de hieraan gerela-teerde activiteiten. Het kan voorgesteld wor-den als het opbouwen van een datavoorraad die het bouwkundige ontwerpproces, de ontwerp-beslissingen, -evaluaties, -activiteiten etc. consistent en compleet beschrijft.

De architecten dienen in staat te worden

1

van de Informatie- en Computertechnologi~n te

aanvaarden met als doel de kwaliteit van hun vakmatige prestaties te verbeteren en een

nieuwe, betere werkomgeving tot stand te

brengen.

De inhoud van ADIS zal regelmatig aan verande-ringen en aanpassingen onderhevig zijn als reactie op de vanuit de dagelijkse praktijk

ontvangen si~nalen. Dit is een evolutionaire

ontwikkeling waarbinnen de gebruikers, de architecten dus, een essentiêle rol zullen spelen.

0.1 Het doel van ADIS

Dit onderzoeksproject is een onderzoek naar de

behoeften van de architecten inzake de

Infor-matietechnologie en het Computer-ondersteund ontwerpen (CAAD). Het streven is om methoden te ontwikkelen voor het verkrijgen en in de praktijk toepassen van de benodigde gegevens. Uiteindélijk zal deze benadering leiden tot de ontwikkeling van een Architectural Design Informatie Systeem (ADIS). Dit informatiesys-teem moet in staat zijn om twee typen objecten te bevatten, te weten 'entiteiten' en

'rela-tie s ' [ Date , 1 9 8 1 , p. 7 8·] . A 0 I S he e f t tot doe 1

de architect ondersteuning te verschaffen bij ontwerpbeslissingen, zowel in termen van data

als van processen. Om dit te bereiken moeten

data op het niveau van de gebruiker worden

gestructureerd. Dit feit is van kritieke

invloed op vele componenten van het systeem. Het systeem moet het voor de eind-gebruiker (vnl. de architect; zie deel 5) uiteindelijk

mogelijk maken om toegang te hebben tot de

gegevens in de data-base en bovendien een referentiekader te scheppen waarbinnen de rauwe data via verwerking tot nuttige, beteke-nisvolle informatie worden omgevormd.

Het doel van dit onderzoek is derhalve het

belichten van de mogelijkheden en openen van

voordeel zullen kunnen putten uit de informa-tietechnologie en de bijbehorende computer-technologie. Het zal ook een basis vormen voor participatie door leden van het Design Coali-tion Team (DCT). Het participatoire kader van het systeem zal naar alle waarschijnlijkheid leiden tot een opeenhoping van grote hoeveel-heden gegevens en tot meer gecompliceerde ontwerpbesluitvormingsprocessen vanwege een verscheidenheid aan inzichten die door de leden van het design coalition team naar voren zal worden gebracht.

0.2 Het beöogde resultaat van dit onderzoek ADIS beöogt een netwerk van verspreide com-puterfaciliteiten te zijn die de behoeften aan dataverwerking van het bouwkundig ontwerp-proces ten dienste staan. Dit data-base sys-teem zal de leden van het design coalition team ten dienste staan als een hulpmiddel bij het ontwerp en de besluitvorming. Het netwerk van verspreide data-bases zal de potentiêle gebruikers op het gebied van het bouwkundige

ontwerpen een· drietal belangrijke hulpmiddelen

bieden (zie fig. 6):

(a) feiten die nodig zijn voor het

ontwerp-proces en de besluitvorming rond het ontwerp (algemene gegevens)

(b) specifieke ge_gevens die nodig zijn voor

een bepaald ontwerp en een bepaalde besluitvorming (projectgebonden gege-vens)

(c) artefacten/modellen die nodig zijn om

het ontwerpen en de besluitvorming fei-telijk uit te voeren. Dit kunnen

metho-den of technieken zijn danwel

ontwerp-apparatuur/ faciliteiten

Het laatste type kan deels of geheel geäutoma-tiseerd zijn (dwz. CAAD programma pakketten,

geäutomatiseerde ontwerpmethoden, etc.).

ADIS is gebaseerd op modellen van het ontwerp proces, verwerkt in een organisatorisch model (ontwerp-managementprocedures/-modellen) die verband houden met participatie van het design coalition team. Daarom is het nodig het ont-werpproces en het organisatiemodel diepgaand

te beschrijven teneinde een fundamentee 1 be-grip te verkrijgen van de vereiste structuur van de data-base.

Het ontwerp van een architectonische ontwerp data-base verschilt niet en zou ook niet moe-ten verschillen van enige binnen andere ge-bieden bestaande data-bases. De bepalende

factoren voor de structuur van deze data-base zijn:

(a) de karakteristieken van het bouwkundig ontwerpproces en/of besluitvorming

(b) de karakteristieken van het design coa-1 i tion team, zijn leden en hun rollen/ functies

(c) potentiêle toepassingen van de data-base.

Bovenstaanden dienen bestudeerd te worden in relatie met het programma van eisen van het netwerk dat op zijn beurt gerelateerd is aan de gebruiker van het systeem (hoofdzakelijk de architect). Klaarblijkelijk zullen alle be-sprekingen van de laatste plaatsvinden op twee niveau's:

(a) hardware (b) ::;oftware.

Dit weerspiegelt een noodzaak tot een constan-te herziening van de netwerkstructuur en tot verdere aanpassingen van het systeem naar behoeften die vanuit de praktijk voortkomen.

De toepassingen van het systeem houden verband met factoren die vooraf bepaald moeten worden. Daarom zouden de toepassingen gerelateerd aan het betrokken functiegebied (dwz. de gebouwde omgeving, het bouwkundige ontwerpen, het ar-chitectonische ontwerpen, enz.) kunnen worden beschouwd als de constante factoren. De varia-bele factor binnen het systeem zijn de gebrui-kers.

ADIS zal een multi-user systeem zijn,

toege-past op een specifiek vakgebied (het bouwkun~

dige ontwerpen). Het sleutelwoord in dit

sys-teem is verandering hetgeen verband houdt met

de t i j<ls factor. verandering doet een dynami-sche basis voor het systeem veronderstellen. ADIS dient te voorzien in een simultane toe-gang en manipulatie van de data door ver-schillende gebruikers. Het dient in een maxi-mum beschikbaarheid van data-bewerkingen voor een maximum aantal gebruikers te voorzien. Tevens dient een gebruiker het simultane ver-werken van data met de mogelijkheid tot door-koppeling van data c.q. informatie van andere systemen geboden te worden. De architect zal de mogelijkheid hebben zijn/haar eigen

ent-. werpmethode (bv. het beslissen over het aantal

en de definities van de niveau's, domeinen en fasen) te bepalen.

Het beoögde resultaat van dit onderzoek zal de uitkomst zijn van een onderzoek naar de

moge-lijkheden om te komen tot een totaaloverzicht van ADIS op basis van de behoeften van de architecten aan data en processen. Deze uit-komst dient op zijn beurt weer de basis te

vormen voor verdere ontwikkeling en implemen-tatie van het systeem en het uiteindelijke gebruik ervan.

1. Theoretisch kader van het onderzoek

Dit hoofdstuk is gewijd aan de hoofdzaken van de ontwikkeling van het Archi tectural Design Information System (ADIS). Onder meer betreft het hier de fundamente 1 e ontwerptheorieên waarop de argumentatie van dit onderzoek is gebaseerd. De belangrijkste argumenten van dit onderzoek grijpen terug op de Domeinen Theorie zoals door Bax gelntroduceerd [Bax, 1975]. Sindsdien is deze theorie verrijkt en verder ontwikkeld tot de huidige status. In dit rap-port wordt aan de Domeinen Theorie kort gere-fereerd. voor uitgebreide informatie wordt verwezen naar publikaties van de Groep Ontwerp Methoden (GOM) van de THE door Bax en anderen. Deze theorie wordt toegepast op het architec-tonische ontwerpproces met als doel het komen tot een algemene beschrijving van de archi-tectonische ontwerpactiviteit. Dit leidt ver-volgens tot de definitie van de types data die men voor zulke processen nodig heeft en tot het bepalen van de types computer die men voor het verwerken en manipuleren van data bij ontwerpprocessen moet gebruiken.

Zoa 1 s 1 a ter za 1 worden opgemerkt, kan en mag het architectonische ontwerp, als een creatief en probleem-oplossend proces, niet beperkt blijven tot een vantevoren vastgelegde of standaard volgorde. Daarom heeft het onder-zoeksteam geprobeerd om het begrip f lexibili-teit in het model (in dit rapport GOM-model geheten) tot uiting te brengen. De drie hoofd-punten van dit model zijn:

( a) (b) ( c) DOMEINEN NIVEAU'S FASEN (zie 1.3.5.1) (zie 1.3.S.2) (zie 1.3.S.3)

De bovengenoemde grootheden moeten gezien worden als respectievelijk Integratie, Coördi-natie en Ontwikkeling in het proces van de architectonische ontwerpactiviteit.

Het GOM-model introduceert een mate van f lexi-bil i tei t teneinde de architect in staat te stellen zijn/haar kijk op domeinen, niveau's en fasen te definiêren. Bovendien zal de aard van de ontwerpproblematiek een duidelijk

in-zicht in deze materie eisen omdat telkenmale

specifieke definities van domeinen, niveau's en fasen met betrekking tot het onderhavige ontwerpprobleem onontkoombaar zijn. De in dit rapport gegeven voorbeelden zijn gebaseerd op de outline of Work van de RIBA (Royal

Insti-tute of British Architects: vergelijkbaar met de BNA) en het BNA-model van het bouwproces

(PIM-model).

In dit hoofdstuk wordt een aantal essenti"El.e definities ten tonele gevoerd. verdere

defini-ties kunnen ~n d~ Glossary gevonden worden

(zie dee 1 8).

Met de theoretische studie van dit onderzoek als achtergrond werden enkele hypothesen

ge-formuleerd. Deze hypothesen zullen in de

volgende fase van het onderzoek getoetst wor-den via een aantal 'case-studies' . De nadruk

van dit onderzoek ligt niet op het definiêren van een model van de architectonische

ont-werpactiviteit, maar op h~t definiêren van de

karakteristieken van de data- base, de ontwik-keling waarvan dit onderzoek immers tot doel heeft, evenals die van de structuur, de in-houd, het ontwerp en de organisatie ervan. Tenslotte verwijst dit hoofdstuk kort naar het netwerk van data-bases (verspreide data-bases) gerelateerd aan de verschillende leden van het design coalition team.

1.1 Definities

Bij het beschrijven van de ontwikkeling van ADIS heeft het onderzoeksteam gedurende de gehele samenstel lingsperiode van dit rapport in hoge mate baat gehad bij het gebruik van diverse technische termen welke gebruikt wor-den binnen de gebiewor-den Informatie- en/of Com-putertechnologie, evenals de terminologie van

het gebied der architectuur en der belangrijke

theori~n die in verband staan met dit onder-zoek. De binnen het kader van dit onderzoek belangrijkste vart deze termen worden in dit gedeelte kort beschreven. De Glossary van dit rapport dient te worden geraadpleegd voor een gedetailleerde definitie van elke term en ook

voor termen die hier niet aan de orde komen. 1.1.1 DATA EN INFORMATIE

Een analyse van informatiesystemen begint met een functionele definitie van data en informa-tie en een bespreking van hun onderlinge ver-houdingen. Dit eerste inzicht wordt uitgebouwd door het kunnen maken van onderscheid tussen informele en formele informatie, het bespreken van de eigenschappen die een bepaalde waarde toekennen aan bepaalde informatie en het

ana-lyseren van de wijze waarop men uit data tot informatie komt.

De termen 'data' en 'informatie' worden vaak voor onderling uitwisselbaar versleten maar ze verwijzen wel degelijk naar twee verschillende begrippen. DATA zijn taalmatige, wiskundige en andere symbolische surrogaten, waaromtrent men is overeengekomen dat zij mensen, objecten, gebeurtenissen en concepten kunnen

beschrij-ven. INFORMATIE plaatst de data in een bepaal-de context die voor bepaal-de ontvanger begrijpelijk

is (Burch, 1983, p.4). Met andere woorden, informatie is het uitdrukken van waarden bin-nen een gegeven kader, terwijl data het ruwe opbouwmateriaal is [Beer, 1975].

Formele informatiesystemen zijn gebaseerd op de vooronderstelling dat we de informatie-behoeften van een individu kunnen bepalen en dat we ook de methoden om van data informatie te produceren (om deze behoeftes te bevredi-gen) kunnen vaststellen. Daarentegen behelst informele informatie meningen, beoordelingen, intu!ties, persoonlijke ervaringen, aannamen en zo verder.

1.1.2 HET BEGRIP 'SYSTEEM'

De term 'systeem' is gebruikt om die activi-teiten te beschrijven welke nodig zijn voor het bewerken van data. Een SYSTEEM kan worden gedefinieêrd als elke set van objecten of

ide~n en hun onderlinge samenhangen die zijn

gerangschikt ten behoeve van een gemeenschap-pelijk doel of streven [Burch, 1983, p.9]. Een systeem, en elke component en elk subsysteem ervan, kan als zodanig worden aangetroffen in de werkelijkheid maar kan even goed van een puur logische aard zijn. Het nut van een wer-kelijkheidsbenadering vanuit een systeem-in-va 1 shoek kan eenvoudigweg toege 1 icht worden door te stellen dat het geheel groter is dan de optelsom van alle elementen. Met andere woorden, het effect van de componenten, als

systeem beschouwd, kan groter zijn dan de

optelling van de effecten van elk afzonderlijk onderdeel [ibid].

Elke organisatie of activiteit kan worden beschouwd als een systeem, dat is opgebouwd uit co~ponente~ of subsystemen. Alle organisa-ties of activiteiten hebben een informaorganisa-tiesys- informatiesys-teem. Dit informatiesysteem is een formele

eenheid, bestaande uit een verscheidenheid

aan logische en fysieke hulpbronnen. Organisa-ties c.q.activiteiten alsmede informaOrganisa-tiesyste- informatiesyste-men zijn dynamische hulpbronnen. Derhalve is een concept nodig dat de structuur van een informatiesysteem logisch uitbeeldt, al zijn fysieke hulpmiddelen weergeeft, toepasbaar is

op informatiesystemen van elke omvang en op

elk type organisatie of activiteit en niette-min relatief constant blijft [op.cit., p. 12].

Inf

orMo. tion SysteM

/

L

Pr"oc:essrng

c

(J) lnfor"l'la1:ron A1:1:r"lbu1:es Da1:a Pr"oc:essrng Reql.llr"el'len1:s (5

c

d

E

Q.J

LJ

LJ

--

Sws1:el'ls Clr"ganrza 1:1onal

lfl

ReqUlrel'lents rac:tor"S

OJ

~ _~

Cutp1.1t Data

v

Cost reurb1t1tw

Pr"oc:essrng Effec:tlveness Requlr'el'lents

Resources Del'lands

Figuur 1: De logische struktuur van een

in-formatiesysteem (Burch, 1983, 12)

1.1.3 DATA-BASE EN DATA-BANK

In wezen i~ een data-base een massaopslag van

gegevens. Zij kan worden gezien als de meest moderne techniek voor dataopslag in vergelij-king tot andere manieren van data-opslag zoals boeken, microfilms enz. Een DATA-BASE kan

worden gedefini~rd als een ge-generaliseerde,

ge-structureerd op basis van gangbare data-relaties. Het biedt alle gewenste toegangswe-gen naar elke data-eenheid teneinde de ver-schil lende behoeften van alle gebruikers te bevredigen [Deen, 1977]. Een data-base is ook

gedefinie~rd als een uitgebreide verzameling bibliotheken [Clason, 1971] en een verzameling van samenhangende bestanden, waar een bestand is gedefinieêrd als een verzameling records met een gemeenschappelijke logische structuur [Mitchell, 1977]. De term DATA-BANK is gedefi-nieêrd als een verzameling van data die ver-band houden met een gegeven set van contexten [Martin, 1976]. In dit rapport zullen we aan alle data-bases met een algemene data-inhoud als aan data-banken refereren. Deze data-banken

vormen een integraal deel van ADIS. We

ge-bruiken de term data-base om te verwijzen naar projectgebonden data-bases of die data-bases die door een ADIS-gebruiker aangewend worden om gegevens, die zij vanwege hun specifieke informatie(verwerkings)behoefte of ontwerpwerk nodig hebben, op te roepen, te manipuleren, en op te slaan.

1.2 HYPOTHESEN

De navolgende hypothesen zijn bedoeld om ADIS en de bijbehorende grondslagen en begrippen te beschrijven. De in dit hoofdstuk aangevoerde hypothesen worden gepostuleerd op basis van

theori~n over en theoretische studies naar de

architectonische ontwerpactiviteit bezien van-uit het standpunt van de Informatie- en Compu-tertechnologieên. Deze hypothesen dienen te worden getoetst door het uitvoeren van 'case-studies'. Dit dient te geschieden in een vol-gende projectfase. Een voorlopig onderzoek, uitgevoerd als onderdeel van de GOM-2-module van dit onderzoeksproject, beschrijft sommige van deze hypothesen gedeeltelijk. Details van

deze onderzoekingen kunnen worden gevonden in

1.2.1 HYPOTHESE 1

HET DOEL VAN HET ARCHITECTONISCHE ONTWERP-PROCES, ALS EEN PARTICIPATOIRE EN CREATIEVE ACTIVITEIT, IS HET OMVORMEN VAN SLECHT GEDEFI-NIE!RDE ARCHITECTONISCHE ONTWERPPROBLEMEN TOT GOED GEDEFINIE!RDE ARCHITECTONISCHE ONTWERP-OPLOSSINGEN DOOR HET NEMEN VAN COLLECTIEVE

ONTWERPBESLISSINGEN WAARAAN DE LEDEN VAN HET

DESIGN COALITION TEAM AKTIEF EN EFFECTIEF DEELNEMEN.

Deze hypothese verwijst naar de deelname van leden van het design coalition team.

Het belangrijkste ontwerpprobleem wordt meestal ingebracht door de opdrachtgever in de vorm van een vaag idee dat omgevormd dient te worden in een {in eerste instantie) slecht gedefinieêrde probleemomschrijving. Brown meent dat "hoewel deze problemen normaliter

slecht gedefini~rd zijn, de

probleemomschrij-ving van de zijde van de opdrachtgever reeds een beperking van het aantal mogelijkheden inhoudt omdat het al een poging is om enige structuur in het probleem aan te brengen" (1985, p.73] ILL-D!:F'!N!:D l'ROBL04 Wf:U..-De:F'!N(D SOLUTIOtt

0 """"' '"'"

Figuur 2: Ontwikkeling van een ontwerpidee

De hoofdtaak van de architect is het omzetten van de onsamenhangende probleemomschrijving in een duidelijke definitie en het vinden van een oplossing of oplossingen. In dit opzicht hebben we geprobeerd om bij de invoering van een algemeen begrip van het (algemeen geaccep-teerde) ontwerpproces te beginnen met de pro-bleemdefinitie als het eerste stadium van de ontwerpactiviteit.

Het Strathclyde-model van het ontwerpproces onderscheidt drie stadia tijdens elke fase van de ontwerpactiviteit:

(a) analyse (b) synthese (c) evaluatie [voeg fig. 3 toe]

FROM PREVIDUS PHASE

ANAL YSIS

_SYNTHESIS

CEACH PHASE)

APPRAISAL

TO NEXT PHASE

Figuur 3 Het Strathclyde-model van het

ont-werpproces

Archer stelt dat elke fase van de ontwerpacti-viteit met een beslissingsstadium zal eindi-gen, tijdens welk stadium de optimale oplos-sing wordt gekozen [1984, p. 58-64]. Ook wordt dit idee duidelijk aangegeven in Roy's be-schrijving van het ontwerpproces [1976, p.3] (zie fig. 4).

PROBLEM WDRLD'S EXIST:CNG SOLUTIIJN NEW WORLD'S

Figuur 4 Roy's beschrijving van het ontwerp-proces

Dit idee is verder uitgewerkt in het kader van ontwerpparticipatie en betrokkenheid van leden van het design coalition team [Beheshti, 1981,

p.57].

x

USE:R/ <t CLIE:NT

w

...

z: Cl DESIGNER

-

CDl'tSUl.TAl'fT

...

-

...J <t Cl u CCtfTRACltR z: L:J

-

(1)

w

~ ETC. Fig. 5: 'WORLD" SlTUATlDl't DECIDING PRCBLEH WHAT TC DErINITICN DESIGN PRCBLEM DESIGNING SCLVING IMPLE:MEN-BUILDING TATICN IJf"

DESIGN

l'€W 'WDRUI" SllUATlDl't

Het ontwerpproces vanuit een participatoir gezichtspunt

1.2.2 HYPOTHESE 2

NAARMATE MEN TIJDENS EEN ARCHITECTONISCHE ONTWERPACTIVITEIT OVER MEER ONTWERPINFORMATIE KAN BESCHIKKEN, DES TE WAARSCHIJNLIJKER IS HET DAT MEN TOT DE OPTIMALE OPLOSSING ZAL KOMEN. Deze hypothese refereert aan de eis dat het architectonische ontwerpproces moet worden ondersteund door een, in de ideale situatie, onbeperkte hoeveelheid informatie, die gedu-rende de verschillende stadia van de ontwerp-ontwikkeling gewenst wordt geacht. Het is

onvermijdelijk dat ADIS, immers een

'onpartijdig' informatiesysteem, alle gegevens moet bevatten die tijdens elke fase van het ontwerpproces van belang zouden kunnen zijn. Dat betekent dus dat ook die gegevens zullen worden opgeslagen die in die bepaalde fase van dat bepaalde project een alternatieve of zelfs een tegengestelde betekenis kunnen inhouden. Echter, de systeemgebruiker za 1 als enige kunnen beoordelen welke gegevens hij uit de data-bank wil oproepen. Dit impliceert dat deze enorme massa gegevens op een zodanige wijze moet zijn geordend dat de gewenste gegevens met een minimum aan t i jd en moeite ter beschikking van de gebruiker kunnen staan. De hoeveelheid van de beschikbare data en de structuur die voor hun ordening nodig is heeft

onverir.ijdelijk een zekere mate van

systeemcomplexiteit tot gevolg. Indirect heeft deze hypothese dus ook te maken met de gewenste vermindering van de complexiteit van zo'n gigantisch systeem tot overzichtelijke proporties zonder dat de aanwezige hoeveelheid beschikbare gegevens de facto verminderd wordt. Volgens Ashby. kan de grootte of omvang van dergelijke systemen alleen begrijpelijk worden door in termen van hun complexiteit te denken [1964, p.61].

voorts heeft deze hypothese betrekking op de capaciteit van bestaande communicatie-kanalen, het tot stand doen komen van nieuwe kanalen

voor informatieoverdracht en het invoeren van mechanismen voor ontwerp-besluitvorming. Dit is volgens Galbraith "het opzetten van een organisatorische structuur voor de thans ter beschikking staande hulpbronnen en hun toekom-stige ontwikkelingen" [1977, p.96], hetgeen van belang is voor het ontwerp van ADIS.

Anders gezegd suggereert de hypothese een toename van de besluitvaardigheid van archi-tecten door het invoeren van betrouwbare en op hun taak berekende mechanismen ter

ondersteu-ning van die besluitvaardigheid. Daar deze mechanismes gebaseerd zijn op het beschikbaar zijn van afdoende en terzake doende informa-tie, zal het gevolg hiervan zijn dat er een immense hoeveelheid data wordt verzameld, nodig tijdens maar ook gegenereerd door het architectonische ontwerpproces. Deze gegevens moeten worden gestructureerd, georganiseerd,

gecoördineerd, gereguleerd en ook nog

pro-bleemloos toegankelijk zijn.

De architect zou de stroom van gegevens moeten kunnen beheersen en de complexiteit van het systeem het hoofd moeten kunnen bieden. Tevens moet hij/zij in staat zijn om de architectoni-sche ontwerpactiviteit te volbrengen met een maximum gelegenheid tot creativiteit, nauwkeu-righeid en participatie. verderop in dit rap-port tespreken we deze punten in detail en introduceren het ontwerpinformatiesysteem met de erbijbehorende vereisten terwijl tevens de ontwerpbesluitvormende processen binnen het kader van een organisatie en/of managementsi-tuatie aan de orde zullen komen.

1.2 .3 Hypothese 3

DE HOOFDZAAK BIJ EEN ARCHITECTONISCH

ONTWERP-PROCES IS VERANDERING. DEZE WORDT GEDEFINI~ERD

ALS E~N VERSCHIL, ONTSTAAN OVER EEN BEPAALDE

TIJDSPERIODE ALS GEVOLG VAN EEN ARCHITECTONI-SCHE ONTWERPACTIVITEIT.

verandering is het meest fundamentele begrip

binnen de ontwerpactiviteit, verklaard in termen van ontwikke 1 ing. In dit rapport valt de definitie van ontwikkeling duidelijk samen met de fasen van het ontwerpproces en de bij-behorende mijlpalen [Bax, 1985]. Hij stelt dat het introduceren van het begrip ontwikkeling niet voldoende is om verandering te verklaren en voert de begrippen integratie en co8rdina-tie in het proces in. Deze drie begrippen corresponderen met respectievelijk fasen, ni-veau' s en domeinen. Zij vormen de basis van het GOM-model.

Ontwerpen is een dynamisch proces waarin con-tinu veranderingen optreden via stappen die

ofwel vantevoren zijn gedefinie~rd ofwel door

de architect worden bepaald. Deze flexibili-teit van het begrip veroorzaakt een aantal moeilijkheden. Deze komen vooral duidelijk naar voren bij het ontwerpen van een systeem als ADIS. Ashby stelt voor, het optreden van veranderingen via de invoering van meetbare stappen te beheersen, welke weliswaar kunst-matig (en dus feitelijk niet bestaand) zijn maar door de continuiteit van het systeem onder controle kunnen worden gehouden [ 1964, p. 9]. Deze stappen moeten van herkenbare

waardetoekenningen voorzien z~jn. Galbraith

legt uit dat de structurering van de vereiste

informatie als uitgangspunt al voldoende is en

dat de ontwikkeling van het systeem tijdens gebruik op den duur tot 'volwassenheid' zal

leiden [1977, pp. 35-38].

Binnen het kader van dit rapport kennen wij aan de fasen meetbare afmetingen toe. Deze fasen zijn herkenbaar binnen de dagelijkse

praktijk van de architect en verwijzen naar punten in de tijd die met herkenbare (deel)-ontwerpoplossingen (fase-afrondingen) corres-ponderen. Domeinen zijn behoorlijk vastlig-gende kenmerken die beredeneerbaar geschikt zijn als maatstaven bij het analyseren en evalueren van het ontwerpprobleem [Bax, 1985]. In dit rapport verwijzen we naar bepaalde domeinen als voorbeelden bij het ontwikkelen van het GOM-mode 1, maar het mode 1 zelf biedt ook een mate van flexibiliteit in termen van het aantal domeinen, niveau's en fasen. Het is goed om te onthouden dat gedurende alle ont-wikkelingsfasen van de ontwerpactiviteit zowel domeinen als nivo's aanwezig zijn die het proces zullen beïnvloeden in een hoedanigheid die door de fase bepaald wordt. Dit concept is de basis van een faseanalyse die elders in dit rapport aan de orde komt (zie 1.3 .6).

1.2 .4 Hypothese 4

ADIS IS EEN NETWERK VAN VERSPREIDE COMPU-TERFACILITEITEN DIE DE INFORMATIEVERWERKING EN DE SYSTEMATIEK VAN DE BESLUITVORMING GEDURENDE HET BOUWKUNDIG ONTWERPEN TEN DIENSTE STAAN. Deze data-basesystemen staan zowel de archi-tect als de andere leden van het design coa-lition team ten dienste als een ondersteunend systeem bij zowel het ontwerpen als de be-sluitvorming daaromtrent. Met andere woorden, ADIS is een belangrijk hulpmiddel voor de bouwkundige ontwerpactiviteit. Het vervult de informatiebehoeften ervan, maakt de datacommu-nicatie tussen de deelnemers eraan mogelijk en voorziet in de interactiemiddelen en in de integratie c.q. beheersing van de archi tecto-nische ontwerpbeslissingen van de leden van het design coalition team. ADIS dient onderde

-len te bevatten die van belang zijn voor hen die betrokken zijn bij, verbonden zijn met of op enigerlei wijze geraakt worden door het bouwkundige ontwerpproces. De verspreide data-bases zullen de architecten (of elke poten-tiêle gebruiker op het gebied van het bouw-kundige ontwerpen) voorzien van een drietal belangrijke ondersteuningen:

(a) feiten, nodig voor het ontwerpen van elk

specifiek architectonisch project en voor het nemen van eraan gerelateerde besluiten

(b) specifieke data, op te vatten als

alge-mene gegevens voor het bouwkundig ont-werpen en aanverwante gebieden, evenals

middelen ter manipulatie en oproeping

van deze data

(c) artefacten ter ontwerp- en

besluitvor-ming (modellen, theorieên, technieken, computerprogramma's, etc.)

CONTENTS DECISION SUPPORTING COMMUNICATION ADMINISTRATION ARCHITECT/DF.SICNF.R FEASIBILITY STUDY ANALYSIS LOOICAL Df:SIGN PllYSICAL DESIGN IMPLEMENTATION/lNSTALL. PROJECT-RELATED DATA SOFTWARE TRAD. PAPER-BASED TOOLS SITE DESCRIPTION BUILDING DESCR. l>ATI\ J CJ.IMATOLOGICAL r>. 81.DG. PROO. DATA COMMUNICATlON S. DESIGN RES. MF.TH. STATISTICS THEORY DECI S!ON-M/\KHIG PUB!.ICATIONS

Figuur 6: De data-base voor ontwerpen

1.2 .5 Hypothese 5

HET MODEL VAN DE ARCHITECTONISCHE ONTWERP-ACTIVITEIT IS EEN DYNAMISCH MODEL DAT CONTINU VERANDERLIJK IS TENEINDE TE VOORZIEN IN FLEXI-BILITEIT BIJ ONTWERPPROCEDURES.

In verband met deze karakteristieken van de architectonische ontwerpactiviteit zal de or-ganisatorische structuur van ADIS ook een dynamisch model vereisen om de veranderende status van procedures aan te kunnen, ook al in samenhang met het overeenkomstig veranderende data-milieu.

Modellen zijn simulaties van de werkelijkheid. Ze kunnen statisch zijn (voorstellingen van de werkelijkheid in een momentopname zoals

bij-voorbeeld een bouwkundig model) of dynamisch (voorstellingen van de werkelijkheid over een bepaalde periode van tijd gerekend zodat de gevolgen van bepaalde acties bestudeerd kunnen worden). Anders gezegd bieden dynamische mo-de 11 en ons mo-de kans om veranmo-deringen te be-schritven. In tegenstelling tot statische modellen zijn ze niet rigide. Hierdoor kan men

via dynamische modellen inzicht krijgen in de consequenties van de diverse richtingen die men kan inslaan bij de beschouwing van een probleem.

A STA TIC MODEL '1t DVMHIC MODEL

Figuur 7: Een voorstelling van statische resp. dynamische modellen

1.3 H:E:T GOM-MODEL

Het Gom-model, in eerste instantie een visua-1 isering van het architectonische ontwerp-proces, vormt de basis voor de ontwikkeling van ADIS. Tengevolge van de cruciale rol die het Gom-model speelt in de ontwikkeling van ADIS is het noodzakelijk dit model grondig uit te leggen. Klaarblijkelijk zal een uitleg van de architectonische ontwerpactiviteit in het

kader van ontwerpmethodologie~n een

samenvat-ting van bestaande ontwerptheorieên zijn en verschaft hoogstens een catalogus van bestaan-de literatuur. We bespreken bestaan-deze methobestaan-den in de context van de doelstellingen van dit on-derzoek en in samenhang met de ontwikkeling van A'l"'IIS.

Het is zeker dat ontwerpinformatie thans in vele vormen beschikbaar is en de hoeveelheid neemt toe. De nadruk van deze bespreking ligt niet op de inhoudelijke karakteristieken van deze informatie maar op de organisatorische aspecten van de architectonische ontwerpacti-viteit. Dit systeem zal een systeem zijn ter ondersteuning van ontwerpbesluiten. Daarenbo-ven richt ADIS zich op het verschaffen van alle middelen noodzakelijk ter uitvoering van de architectonische ontwerpactiviteit en zijn organisatorische aspecten. Het Gom-model, ge-zien als een eerste stap in de ontwikkeling van ADIS, ~s gebaseerd op de introductie van de Domeinen Theorie [Bax, 1978] in de RIBA

'Outline of Work' en de BNA Project

Informa-tie-matrix.

Het Gom-model is een universeel artefact dat wordt gebruikt ter ordening van besluitvor-mingsprocessen. Zulk een proces-orde kan ge-zien wvrden als zijnde samengesteld uit diver-se sub-'ordes' (de term 'orde' wordt gebruikt in de betekenis van een specifiek besluitvor-mingsgebied waarbinnen zekere normen en waar-den van toepassing zijn). Deze 'ordes' kunnen ruimtelijk/fysiek, sociaal,

Elke orde kan opgedeeld worden in 'domeinen' (deel-ordes die belanggebonden zijn en waar-binnen dezelfde karakteristieken als die van een sub-'orde' aangetroffen kunnen worden), 'niveau's' en 'fasen'.

De ontwikkeling van ADIS stoelt op de ruimte-lijke/fysieke 'orde' van het Gom-model en heeft uitsluitend betrekking op het

architec-tonische aspect hiervan. In dit rapport wordt dit als het ARGOM-model voorgesteld.

LEVELS

-• -~ ~clflC ( ... 1) L QJ ë:5 L 0 __, L QJ ë:5 L 0

u

E L d

_o.

QJ

u

IDO MAINS

• wtllty • car&bllty

..

,.,...,"~

(who.'\ how, who 1>

lil >... _c 0.. «$ c ë:5 L 0

_u

L 0 QJ QJ ë:5

'

-s.... __, _d 0 d

u

u

..p c

PHASES

(.twft" d c ~

The

GOM-Mode~

Figuur 8.1: Algemene uitbeelding van het Gom-model [Bax, 1985] L lil 1 Q; _l. ë:5 QJ L ë:5 0 s.... 0 __, d s.... L _QJ ~ _.s:.. ..p __, ..p ~ 0

u

J> :J p ,.-'< lil lil r'1

<

p

,--c

p c+ 0 :J ProbleM-sto. te ORDERS DoMo.lns Levels Levels DoMo.ins ORDE.RS

Solut1on o.l terno. trves

DoMo.lns Levels Levels Dol"'lo.lns ORDERS Solutron-sto. te

Figuur 8.2: Procesmatige uitbeelding van het GOM-model

1.3.1 De Domeinen Theorie

De Domeinen Theorie wordt ingevoerd om de functionele, ruimtelijke en technische aspec-ten van de bouwkundige elemenaspec-ten te kunnen verklaren. Zij verklaart de mogelijkheid om deze elementen in termen van domeinen,

ni-veau's en fasen te beschouwen. De toepassing van deze zal het architectonische ontwerp-proces ordenen. De stelling is verdedigbaar dat dit een simultane uitvoering van ontwerp en participatie mogelijk maakt.

In het kader van dit rapport worden de domei-nen, niveau's en fasen in detail uitgelegd. Zij stellen respectievelijk de integratie, coördinatie en ontwikkeling binnen de archi-tectonische ontwerpactiviteit voor. Voor een uitgebreide beschrijving hiervan zie deel 1 van dit rapport.

1.3.2 Architectonische ontwerpmodellen

Eerder in dit rapport beschreven we verschil-lende invalshoeken op het ontwerpproces en op de fasen, niveau's en domeinen. Nu volgt een beschouwing van de stadia van het ontwerp-proces tijdens elke fase van zijn ontwikkeling

waaraan we zullen refereren als de logische

volgorde van een fase van het ontwerpproces.

"~

~

PROBLEM _{~ SYNTHESIS} ~ ~

DEFINITIDN v ANALYSIS i----v APPRAISAL v DESIGN

ï

1

Het architectonische ontwerp is een vorm van een probleem-oplossende activiteit maar dan met de eigenaardigheid van slechte

gedefini-~rdheid in vergelijking met andere vormen van goed gedef ineêrde probleem-oplossende taken

zoals schaak, semantische processen, etc.

[Akin, 1984, p. 192]. Alle probleem-oplossende processen worden verondersteld te bestaan uit het transformeren van een gegeven staat van informatie omtrent een probleem in een andere staat zodanig dat de tweede staat dichter bij het bevatten van de oplossing-beschrijvende informatie is dan de eerste. Gegeven dit argu-ment begint de operatie (de handeling van het transformeren van een probleemstatus in een andere) met een aanvangsinformatiestaat, in

dit rapport probleemdefinitie of

probleembe-schrijving genoemd. Deze zal worden gevolgd door allerhande tussenstaten voordat de

afron-dende staat wordt bereikt, de oplossingsstaat.

Elke staat kan worden verkregen door het uit-voeren van een handeling met de voorgaande staat. Om dit punt te verhelderen kunnen we naar elk probleem-oplossend proces verwijzen als een keten of netwerk van staten (data dus) en handelingen (processen dus) op een zodanige manier dat er geen sprake is van loshangende draden.

LOOSE

END

Figuur 10: De causale volgorde van handelingen

De taak van het probleemoplossen komt overeen met het vinden van de juiste volgordes van handelingen die de probleem-beschrijvende staat in de oplossingsstaat veranderen. De 'losse-eindjes' operatie geeft volgordes van handelingen weer die overeenkomen met niet-gelukte pogingen om tot een oplossing te gera-ken - doodlopende straten als het ware.

Het architectonische ontwerpen is een dyna-misch proces en als zodanig een opeenvolging

van probleemoplossende acties. Men kan berede-neren dat in iedere fase van het ontwerpproces de staat van een artefact in een andere staat verandert. Deze nieuwe staat is de prob 1 eem-staat voor de volgende fase. Hierdoor wordt deze probleemopvolging tot een keten zonder einde. Mocht, om welke reden ook, de volgende fase niet bereikt kunnen worden, is er sprake van een doodlopende weg. Normaal gesproken vindt er dan feed-back naar de voorgaande fase of een of meer fases die hier weer aan vooraf-ging(en) om daar eventueel nieuwe beïnvloeden-de factoren aan het artefact toe te voegen door nieuwe gegevens te vinden of .andere pro-cessen toe te passen.

De architectonische ontwerpactivi~eit is een

hi~rarchisch proces dat de volgorde waarin een

reeks van hande 1 ingen moet worden uitgevoerd bepaalt. Om menselijke behoeften en intenties te vervullen zal de architect een reeks van handelingen bedenken en uitvoeren. Dit

ver-schaft volgens Miller inzicht in "het wezen van elk menselijk gedragspatroon bij het na-streven van doelen of het oplossen van proble-men [1960, p.212]." Op een of andere manier dient de complexiteit opgebroken te worden in

hi~rarchische ketens van minder ingewikkelde

condities van input-output, gerelateerd aan het logische pad van de ontwerpactiviteit. De

complexiteit van de verhoudingen en de daarop-volgende decompositie kan een basis

verschaf-fen voor gelijktijdig uit te voeren

probleem-oplossende activiteiten [Beheshti en Bax,

Simultane ontwerpaktiviteiten vereisen een organisatiestructuur van de ontwerpactiviteit met een systeem van regels en/of patronen/-maatstaven via welk een analyse van de pro-bleemstaat en de daaropvolgende synthese moge-1 ijk is om de beslissingstaat te bereiken. Dit

gezegd hebben~e, stellen we dat er een hele

reeks moge 1 i jke structuren bestaat, die ver-deeld is over drie dimensies. De relatie tus-sen deze structuren zou goed moeten worden begrepen.

o.i.

heeft dit begrip meer dimensies die echter buiten het bestek van dit onderzoek vallen. Bij het introduceren van het begrip structuren vervangen we feitelijk atomistische houdingen of holistische verklaringen door een structuralistische opvatting. Het structura-lisme is volgens Piaget "het poneren van interactieve of transformatieve systemen als de primaire werkelijkheid en derhalve dus het a priori ondergeschikt maken van elementen aan de hen omringende relaties en, omgekeerd, het geheel visualiseren als het produkt van de compositie van deze formatieve interacties" [1972, p. 480].

Structuralisme kan worden gezien als een cor-relationeel systeem van relaties en

transfor-maties dat ook nog de elementen volledigheid

en zelfregulering bevat. In dit opzicht is het ontwerpproces, zoals Teymur dat stelt, meer gefdentificeerd via "zijn struktuur en effec-ten dan door enige andere eigenschap" [ 1982, pp. 55-59]. Levi-Strauss stelt dat "de univer-sele elementen van de menselijke cultuur al-leen op het niveau van structuren te vinden zijn en nimmer op het niveau van de manifeste feit" [1970, p. 27].

Wanneer we deze argumentatie inpassen in het architectonische ontwerpproces, kunnen we het standpunt innemen dat een structuralistische benadering van het ontwerpproces in een kaart van het ontwerpproces kan voorzien via welke alle elementen en hun relaties als een eenheid

kunnen worden verklaard. Structuren zijn

daad-werkelijke ontwerpproces of de synthese ver-der ontwikkeld kunnen worden. Zij voorzien ook in een behoefte aan relevante attributen om de mogelijke effecten die door het ontwerpproces waarschijnlijk worden voortgebracht te

be-spreken.

"De structurele eigenschappen van een archi-tectonische context zijn echter niet beperkt tot vormen; ook regels maken er in belangrijke mate deel van uit. Regels bepalen het vermogen van de structuur tot verdere ontwikkeling gedurende de toekomstige stadia van zijn be-staan. Deze structurele karakteristieken kun-nen worden begrepen via de bestudering van

bestaande varianten, hetg~en de manier waarop

men structuren kan voorstellen verduidelijkt. Structuren kunnen aldus worden ontworpen wan-neer men reeds ideeên omtrent de algemene ontwerpkarakteristieken bezit. Deze zijn geba-seerd op de ontwerpervaring van de architect, zijn opvatting van de ontwerpactiviteit en een duidelijke omschrijving van de ontwerpeisen in de vorm van een goed gedef iniêerde ontwerppro-b leemste 11 ing [Beheshti en Bax, 1984, p. 5]. Deze structuureigenschappen, door middel van welke informatie omtrent kwaliteit kan worden vergaard, afgebakend en verder ontwikkeld,

zijn machtige hulpmiddelen bij het defini~ren

van niveau's in een hiêrarchisch systeem. In dit opzicht kunnen systemen en structuralisti-sche benaderingen zeer wel met elkaar in over-eenstemming worden gebracht. Deze denkbeelden zijn, onder deze omstandigheden althans, noch contradictoire opvattingen noch alternatieven -zoals Hillier en Leaman ons willen doen

gelo-ven [1973]. Ze maken deel uit van een meer algemeen concept dat de grondslag van het

Gom-mode l vormt. Systemen zullen, doordat ze

tructuren als ordenende elementen in zich hebben, mogelijkheden bieden om tot

coördina-tie, ontwikkeling, integratie en participatie

te komen [ ibid].

Structuur is een levendig en krachtig begrip

ont-werpactiviteit en er ook toe bijdraagt dat potentiêle conflicten niet tot uitbarsting geraken doordat tegenstrijdige factoren worden gefntegreerd. Het ARGOM-model biedt een dyna-misch gezichtspunt inzake architectonisch ont-werpen dat is gebaseerd op weliswaar theoreti-sche aannamen, die echter wel zijn afgeleid van praktische ervaringen [op.cit., p.12]. De bepalende faktor in dit model is VERANDERING die "min of meer constant in de tijd" ge-schiedt [Blalock, 1969, p. 88]. Hij meent dat

verandering plaatsgrijpt in een mate die bij

het proces past. Derhalve moet tijd, immers de enige factor via welk deze mate gemeten kan

worden, behandeld worden in termen van

onder-ling gescheiden tijdspannen omdat het verande-ringsproces als zodanig niet bestudeerd kan worden [ibid]. In dit opzicht moeten we deze tijdsintervallen voor het architectonisch ont-werp def iniêren teneinde de veranderingen aanschouwelijk te kunnen maken om ze te kunnen meten. Het begrip fase wordt ingevoerd ter

beschrijving van een hiertoe geschikt t~jdsin­

terval binnen het architectonische ontwerp-proces. De mate van verandering kan volgens Blalock worden bestudeerd via empirische

gege-vens, verzameld om de juiste tijdsintervallen te kunnen bepalen [op.cit., pp. 90-92].

hx

r

= ---

-r

=

mate van verandering

b,x

=

kleine verandering

~t

=

kort tijdsinterval

Problemen aangaande stabiliteit en verandering zijn van aanzienlijk belang bij het verklaren van het ARGOM-mode 1, dat er naar streeft een evenwicht te bereiken in de ontwerpactiviteit door reeksen van veranderingen die van een slecht gedefinieêrd ontwerpprobleem tot een

optimale ontwerpoplossing l eiden. We benaderen

dialectisch proces waarbij integratie al leen kan worden bereikt door participatie. Dit vereist in hoge mate de ondersteuning van een ADIS en het gebruik van computers tijdens verschillende fasen van de ontwerpontwikke-ling. Volgens ons betekent dit de nadruk leg-gen op verandering, structuur en participatie zodat nuttige ontwerphulpmiddelen geschapen kunnen worden. Ontwerpen wordt gezien als het instrument voor de plaatsbepaling van waarden binnen een complex proces van integratie van

vele verschillende belangen. Om de basis van het ARGOM-model aanschouwelijk te kunnen maken

verwi~zen we naar drie dimensies of gebieden

die het model in een meer tastbare realiteit kunnen beschrijven:

(a) gebieden van kennis en de wijzen waarop

kennis kan worden vergaard en georgani-seerd. Onderzoek verschaft een solide basis voor de architectonische ontwerp-activiteit. Wanneer het ontwerpproces uitgevoerd wordt volgens specifieke met-hodologische regels brengt het informa-tie voort voor de navolgende fasen van de ontwerpactiviteit en/of toekomstige ontwerpen. Het architectonische ontwerp-proces is, in dit opzicht, een leer-proces. Wanneer de informatie op een expliciete wijze is geformuleerd, ver-groot deze het totaal van de geäccumu-leerde kennis. Architecten moeten de uitdaging aannemen om hun beroep steeds beter uit te oefenen en dus hun kennis

bij te houden, in het bij zonder met

betrekking tot Computer- en

Informatie-technologi~n, teneinde hun werkmilieu

aan te passen. Dit is ook een basis voor het ARGOM-model. Het model kan gezien worden als een kaart, die de bestaande informatie ordent, hetgeen een primaire

vereiste is bij de uitvoering van het

Het ARGOM-model verschaft een instrument voor het overzien van de gevolgen van beslissingen en zal architecten

stimule-ren om tijdens het ontwerpen bepaalde

wegen in te slaan. In dit opzicht is het model een theorie en het te bereiken doel is technieken. Het gebied van kennis wordt beschreven in het kader van systemen (in dit verband concepten en theorieên), strategieên of methoden en technieken. Dit laatste is het gebied van ontwikkeling en de eerste begrippen bakenen het gebied van onderzoek in de architectuur af. In dit opzicht ver-schaft de theorie mogelijkheden voort die echter afhankelijk zijn van de be-schikbare ontwerptechnieken. De ontwerp-strategie is altijd specifiek en hangt af van de specifieke omstandigheden van het ontwerpprojekt zoals kwaliteit, tijd, budget, sociale omstandigheden, omgeving, etc. Methoden worden

geformu-leerd en regels opgesteld aan de hand van operationele ontwerpstrategieên. Hier is noch sprake van technieken noch van standaardoplossingen. Deze methoden en regelingen zijn algemene procedures, logisch volgend uit de toepassing van

technieken. Systemen, strategieên en

technieken kennen algemene karakteris-tieken die toepasbaar zijn op een breed skala van architectonische ontwerpacti-viteiten. Deze activiteiten worden [op theoretische, methodologische en techni-sche nivo's] verklaard in termen van

waarden. De architectonische

ontwerp-activiteit kan terdege worden gepland

door gebruik te maken van alle bes~hik­

bare hulpbronnen en kennis gedurende

(b) gebieden van waarden zoals gerelateerd aan de verscheidenheid van functies in de architectonische ontwerpactiviteit. Waarden worden toegekend door de archi-tect (en andere leden van het design coalition team) aan ruimtelijke

ele-menten binnen een gegeven ruimte 1 i jke,

functionele en procedurele samenhang. Deze waarden komen overeen met

ruimte-lijke elementen die zijn gedefinieêrd in termen van maten, plaats en functie, etc. Functies kunnen worden vervuld door fysieke elementen,zijn gebaseerd op de fysieke eigenscha,Ppen van deze e le-menten. In een complexe situatie kan een architectonisch ontwerpprobleem zodanig worden gestructureerd dat het in

deel-problemen verdeeld kan worden. Deze

deelproblemen kunnen worden opgelost binnen hun respectievelijke ordes. Deze ordes kunnen worden gezien als bijdragen aan een meer complexe orde waarin zij een systeemevenwicht handhaven. Waarden worden verklaard in termen van domeinen (waar integratie mogelijk wordt gemaakt en in een bepaalde relatie kan staan tot het begrip verandering)1 niveau's, (die in verband staan met het coördinatie-proces) en fasen (die de ontwikkeling van het ontwerpproces beschrijven).

(c) verschillende gebieden waarbinnen kennis

en waarden kunnen worden toegepast op

het ontwerpen van verschillende

arte-facten.

Bovengenoemde gebieden worden weergegeven in

figuur 11 die in principe gelijk is aan het

Gom-model, maar hier ertoe dient om een orga-nisatorische structuur aan de architectonische ontwerpactiviteit te geven door het te

+' Q.

~

1

~I

QI 1 ~

-t-::l'I ' :::c UI ::l'I u t.. a:: 0 <t: QI l.&J .s:: Cl) +' 1 l.&J a:: w L.:J UI ~ QI UI w Ö> ~ _J QI _.s:: 0 3 +' _+' d CJ t.. QI z: +'

c

j

~ 111 QI

!

~I 1- _+' 3 ' z: _UI Cl-l.&J QI 0 ~ UI Q., j CJ r::r ...J ë

-l.&J .s::

>

u _QI QI l.&J _+> t. ~ _d 3 ~ t.. d .s::

de studie van architectuur is het noodzakelijk het studiegebied uit te breiden van ui ts

lui-tend zichtbare naar structurele vormen. Het is beredeneerbaar dat de structurele eigenschap-pen van een architectonisch concept niet slechts tot vorm beperkt blijven.

1

1 •

.

1

eve s d oMo.lns pho.ses orders

Morphologlco.l _functlono.l po.rtles/ soclo-econoMIC,

o.spects o.spec-ts processes etc.

ph~slca.l orders ether orders

DESIGN 8. PLANNING

VALUES

Figuur 11: Model van het ontwerpproces in de context van gebieden van kennis en waarden

1. 3. 3 Logische volgorde binnen het archi tec-ronische ontwerpproces

zoals eerder gezegd zijn domeinen en nivo's al tijd geïntegreerde en onafscheidelijk ver-bonden onderdelen van elke fase of subfase

(stappen genoemd} van het architectonische ontwerpproces. Dit maakt een degelijke defini-tie van fasen, die zijn gedefinieerd als her-kenbare mijlpalen in het architectonische ontwerpproces, in termen van duidelijk te onderscheiden tijdsintervallen ontontbeerlijk. Men kan op verschillende manieren tegen het begrip fase aan kijken. Het ARGOM-model werkt met een aangepaste combinatie van fase-defini-tie s die respecfase-defini-tievelijk door de BNA en de RIBA ontwikkeld zijn (zie figuren 12 en 13). Het RIBA Plan of Work voorziet in een model-procedure voor het methodisch werken van het ontwerpteam en dient als een raamwerk voor de fasen van de architectonische ontwerpactivi-teit. Als een modelprocedure voor het ontwerp-team wordt het Plan of Work verondersteld toepasbaar te zijn op projecten met voldoende gemeenschappelijke factoren. Deze modelproce-dure dient te worden aangepast aan speciale omstandigheden. Onder dergelijke omstandighe-den dienen de gevolgen zorgvuldig bekeken te worden. Het Plan of Work geeft alleen een werkkader weer. Het dient te worden ingevuld voor elk project en elk bureau. De vereiste handelingen zullen ook moeten worden aangepast om geschikt te zijn voor kleine en grote

pro-jecten. Het Plan of Werk geeft een logische volgorde van handelingen weer die ondernomen dienen te worden om te zorgen dat de juiste beslissingen genomen kunnen worden op tijd-stippen waarop de voortgang van het werk geen schade ondervindt [RIBA, 1983, pp. 347-373].

In wezen vertonen zowel het RIBA-model als het

BNA-model een duidelijk punt van overeenkomst.

een tijdstip waarop een tastbare doelstelling is gerealiseerd zodat de opdrachtgever een duidelijk (deel)resultaat onder ogen krijgt waarop hij kan reageren en commentaar leveren. Zulke presentaties kunnen in rapport-, diag-ram- of ontwerpvorm voorkomen. voorts drukken beide modellen de verwachting van een (deel)betaling uit aan het einde van elke

fase. Dit laatste zou als een belangrijke en

zeer wel haalbare determinantiefactor bij het vaststellen van de fasen van de architectoni-sche ontwerpactiviteit kunnen fungeren.

•tau• Purpo•• of work and Dec:i•lona to be reached

A. lnceptlon To prepare general outllne of

requlrementa and plan fulure ac:tlon.

8. _Feuibllltv To provid• the cllent wlth an

appralaal and rec:ommendalion In order !hel he may determlne the form In whlch the project la to procHd, enauring that Il 11 feaslble, lunctlonall)', tec:hnlcall)' and flnanclall)'.

C. Outllne To determlne ganeral approach

Propoaala to layout. dealgn and construct ion

In order to obt.\ln authoritative approval of the cllent on the outllne propo1al1 and accom-p\nylng report.

D.Scheme To complete the brief and deelde

Dealgn on partlc:ular propoHla,

lncl11dlng planning arrangement appeerance, conatructlonal method, outlln• apeclflcatlon,

and coat. and to obtaln all

çprovala.

•1lef alto11/d _,be lftOlll{lefl •(ter Utla ~nl.

L Detail DH.i1111 G. 81Ue of ctuutfti•• J. Prolact Plu•l11t1 k..Operatlo" onatte L C:ompletiotl • · FHd•Sack

To obtaln flnal dec:lalon on every matter related to dealgn, apeclflcatlon, conatructlon and

coat

To prepare productlon Informa-tion and make flnal detalled declalonä to CeiTy out work.

To prepare and complet• all Information and arrangementa

tor obtalnlng tender.

Actlon H recommend•d In NJCC

Code of Procedure (or SlngM Si.g11

S./KUre T11nd1t1lng 1en.

To enable the contractorto program me the work in accord· ance with contract condition•; brief site lnapactorate; and make arrangement& to commence work on site.

To follow plan• through to practical complation of the building.

To hand over the building to the client tor occupation, remedy any defecta, aettle the flnal account, and complete all work in accordance with the contract.

To analyH tha management, conatruction and performance of the project

Tuk• to be don•

Set up ellen! organl1allon lor briefing. Conalder requlremenls, appolnt architect.

Carry out 1tudlea of uHr requlrement1, alle condltlona, planning, design, and co•t, etc.,

H neceHary to reach dec:lalona.

Davelop the brief further. Carry out studies on uaer requorttmenta,

technica! problema, planning, design and coats, as necenary to reach dec:lalona.

Flnal development of the brief, full dHlgn of the project b)' architect, prelimlnary dealgn b)' englnHra, preparatlon of coat plan and full e.qilanaltir)' report. SubmlHion of proposala lor all approvala.

Full dealgn of

••etY

part and

, ~omponent of the building by ollaboratlon of all concerned. Complete coat chec:klng of dHlgna.

Preparatlon of flnal productlon

Information I.e. dr-lng1,. _

ac:hedulff and apeclflcallona.

PrepVatlon of Bllla of OuanlltlH .nd lander documents.

Acllon H racommend•d In NJCC

Code of Proef/dur• (or Slngl• Sgg•

s.lecUr• T11nd1t1ing 1en.·

Action In acçordance with The

M•n•ge~nt of Building Contr.cU• and Diagram ll.

Actlon In acçordance with The

M•n•g•ment of Building Contr.cts• and Diagram 10.

Actlon In acçordance wilh Th•

Man•gemenl of Building

Contr«t•• end Diagram 11.

Analy1l1 of job records. lnapectlonaof çompleted building. StudiH of building In u".

People dlrec:llll lnvolved

All dient lnlerHta, architect.

Clients' repreHntatlvea, architect&, englnHra, and OS accordlng to nature of project.

All cllent lntereata, architect•, engineers, OS and 1pec:lali1ta

aa requlred.

AU dient lntereata, architect&, englnHra, OS and apec:lllllata

and all atalulory and othef'

approvlng authorltlea,

Architect&, OS, engln-• and

1peciall1!1, contractor (Il

appolnted).

Arc:hltecta, englnHra and

ai;aclallata, contractor (Il

•PPolnted) •

.

Architect•, QS, contractor (Il

appolnted). Architect•, OS. englnHra, contreçtor, cllenL Con tractor, 1ub-contractora. Architect•, enginHra, çontraçtora. sub· contractora, OS, cllent.

Arçhllecta. engineers, contractor. OS, çllent.

Arçhitect enginHra. OS contreçtor. çlient.

Figuur 12: Het RIBJ't-Plan of Work

Uaual Termlnoloei 8rleflng Sketch Plans Workln11 Drawln111 Site Operatlona