Capitolo primo Progettazione collaborativa
8
Capitolo primo
Progettazione collaborativa
La progettazione di un'opera di architettura è un processo che
recentemente, nei paesi industrializzati, è stato via via reso più complesso dalla
crescente complessità del prodotto architettonico, dal numero e dalle
specializzazioni degli operatori coinvolti o “attori”, dalle accresciute richieste di
adempimenti normativi, procedurali e tecnici, da nuovi prodotti resi disponibili
dalla tecnologia e dall'industria, dalla ridotta disponibilità di tempo. Si presenta così
l'esigenza di ricorrere a forme di gestione del processo progettuale che consentano
di facilitarne il governo nella riduzione dei tempi. La ricerca di più efficienti sistemi
di gestione della complessità progettuale in edilizia come in altri settori, ha
interessato la comunità scientifica per molti anni, e ha portato a metodologie e
tecniche di pianificazione e controllo del progetto nella progettazione industriale
meccanica e manifatturiera. Tuttavia la specificità del prodotto architettonico
legato ad una precisa contestualizzazione di luogo e di utenza, rende inefficaci tali
tecniche e metodologie per la gestione del progetto. Questa va considerata come
processo, articolato in fasi, in ciascuna delle quali sono coinvolti determinati
personaggi o attori con proprie competenze specialistiche. In tal senso il progetto
nasce per decisioni collettive, assunte gerarchicamente da uno o più attori.
La natura intrinseca della progettazione in architettura è la multidisciplinarità
e interdisciplinarità e nella conseguente complessità del problema progettuale,
indipendentemente dalle dimensioni del progetto e dagli ambiti disciplinari. Lo
scopo complessivo della ricerca è una maggiore efficacia e qualità del processo
progettuale conseguite attraverso il controllo e la gestione dei conflitti che nascono
Capitolo primo Progettazione collaborativa
9
nel processo stesso rendendo note, partecipate, e condivisibili le scelte operate.
Queste dovranno avvenire in modo più consapevole e mirato, grazie all'immediato
avviso delle conseguenze che tali scelte potrebbero produrre. Obiettivo di questa
ricerca è quindi la costruzione di un modello di sistema software che sia di
supporto alla progettazione architettonica rispettando le specificità e i ruoli
di ogni attore del processo.
In questo modello gli attori sono assistiti da “assistenti” più o meno
“intelligenti” in grado di supplire compiti più o meno complessi; in una prima
istanza ci si riferirà a questi come ad una interfaccia grafica che consenta ad un
attore di dialogare col sistema e, attraverso questo, con gli altri attori. Ogni
“assistente” è quindi, in questo primo approccio al problema, costituito da una
interfaccia che oltre a dialogare col sistema permette di interagire con gli usuali
programmi applicativi e, se presenti, con i propri motori inferenziali, con la propria
base di conoscenza, con la propria base di dati, le proprie primitive grafiche, e
quant’altro.
Questo modello sarà impostato e definito in modo collaborativo tra le Unità
di Ricerca, UdR, di ambiti disciplinari diversi: architettura, tecnologia
dell'architettura, ingegneria economica, informatica, ingegneria strutturale, fisica
tecnica, ecc., attraverso la simulazione di un gioco e di un caso di studio reale.
Il paradigma della progettazione collaborativa, attraverso il quale si innesca
un “circolo virtuoso” fra i vari attori del progetto che contribuisce ad aumentare la
propria conoscenza, porta a scelte progettuali più consapevoli, incrementa
l'esplorazione di soluzioni progettuali in numero e qualità, migliora il progetto e il
prodotto, riduce i tempi e/o i costi, aumenta l'efficienza del processo. L'obiettivo
generale è la definzione di un modello e la messa a punto di metodologie,
tecnologie e strumenti idonei a supportare il paradigma della progettazione
collaborativa, in grado di assistere i vari attori del processo progettuale nello
Capitolo primo Progettazione collaborativa
10
svolgimento dello stesso, secondo la tempistica e le gerarchie ritenute più
opportune dall'insieme degli attori partecipanti. Poiché esistono più attori che
variano durante il processo progettuale, e che le regole procedurali sono specifiche
delle varie fasi del processo, anche gli “spazi delle soluzioni progettuali” variano
nel tempo.
Il progetto complessivo, facendo un parallelo matematico, si può
considerare come dato dall'intersezione nello “spazio delle soluzioni progettuali”,
di quelle derivanti dal contesto operativo, di quelle proposte dagli attori e di quelle
definite dalle regole procedurali. Questa intersezione può risultare un insieme
vuoto ed allora non esiste alcuna soluzione, oppure nello “spazio delle soluzioni
progettuali”, le soluzioni sopra definite sono parzialmente sovrapponentisi, ed
allora esiste un insieme di soluzioni più o meno condivise.
Il Collaborative Design (progettazione collaborativa) può essere inteso come
il processo che modificando gli “spazi di soluzioni progettuali” dei singoli attori,
persegue la loro armonizzazione, sino a costruirne una intersezione maggiormente
condivisa. [1]
Capitolo secondo Struttura del sistema - obiettivi
11
Capitolo secondo
Struttura del sistema - obiettivi
2.1 Scopi e motivazioni
Alla progettazione collaborativa – intesa nel senso di computer aided
architectural collaborative design – è richiesto di offrire un ambiente con relativo
supporto informatico in grado di porre in evidenza gli obiettivi progettuali
(problema della rappresentazione di un oggetto) e di far dialogare fra loro
specialisti in settori diversi interpretando e traducendo le esigenze e i vincoli che
ognuno di loro impone agli altri nelle varie fasi di elaborazione del progetto.
Guardando ad un esempio pratico, i vari attori dovrebbero concorrere alla
modifica di un medesimo oggetto e nel farlo potrebbero assegnargli caratteristiche
fisiche e dimensionali incompatibili; il sistema dovrebbe individuare questi conflitti
in modo automatico ed evidenziarli ai singoli attori interessati .
Il paradigma della progettazione collaborativa prevede la possibilità per ogni
attore coinvolto nell’elaborazione tecnica di lavorare supportato dai suoi strumenti,
ovunque egli preferisca e nello stesso tempo di collaborare con gli altri personaggi
allo sviluppo del progetto. Dovrebbe essere dunque snellito il processo di
progettazione permettendo ad ogni attore di lavorare in parallelo agli altri, senza
più la necessità di doversi frequentemente e periodicamente riunire per analizzare
lo stato di avanzamento del progetto e le relative strade alternative che via via si
aprono. Ognuno dovrebbe essere a conoscenza delle modifiche e dei vincoli altrui
così da poter regolare la propria progettazione; ad ognuno dovrebbe essere data la
possibilità di interagire direttamente e tempestivamente con gli altri attori per
Capitolo secondo Struttura del sistema - obiettivi
12
discutere delle problematiche emergenti. Questo permetterebbe di ridurre i tempi
di sviluppo del progetto, diminuendo (se non eliminando) le riunioni “faccia a
faccia” tra gli attori e apportando comodità e flessibilità sul luogo e i tempi del
lavoro (ad esempio, un architetto canadese ed un ingegnere fisico-tecnico italiano
potrebbero concorrere alla progettazione della stessa struttura pur stando ognuno
nel proprio paese e, per di più, ognuno alla propria scrivania). Ogni attore deve
avere, quindi, a disposizione degli strumenti che gli permettano di interagire con gli
altri colleghi e di portare a termine la propria parte di progetto coerentemente con
le decisioni altrui e i vincoli da essi imposti. Ciò richiede la comunicazione non
solo dei dati puramente progettuali come la disposizione e la geometria degli
elementi costruttivi realizzati, ma anche il passaggio di regole e vincoli (richieste
peculiari di ogni attore nonché regole di “buona progettazione”) che devono essere
analizzati e, a seconda della loro natura e rilevanza, accettati o respinti.
Ogni attore porta con se un bagaglio culturale di norme che utilizza
costantemente nello svolgere la sua arte e che, in questo contesto, deve essere
messo a disposizione di tutti coloro che partecipano al progetto, in maniera tale
che sia comprensibile, facilmente interpretabile e rispettato da ognuno, senza che
ci sia la necessità di incontrarsi fisicamente e discuterne. Ogni attore ha dunque
una base di conoscenza propria che racchiude le “sue” regole e che andrà scandita
all’interno del sistema, per poi essere considerata e condivisa da tutti i partecipanti.
Al fine di rispettare le regole proposte da ogni partecipante alla fase di
progettazione, con l’obiettivo finale di creare un’opera accettata da tutti e
qualitativamente valida per il cliente, è possibile l’apertura di più strade alternative,
ognuna delle quali rappresenta un momento di analisi e valutazione fino a
raggiungere la scelta unanimemente considerata la migliore. Il tutto rispettando
l’idea di rimanere al proprio posto di lavoro e sfruttando gli strumenti messi a
disposizione dalla tecnologia. L’aspetto trattato tocca un punto cruciale nell’ambito
Capitolo secondo Struttura del sistema - obiettivi
13
della progettazione architettonica, è infatti richiesto come elemento innovativo e di
grande valore pratico, la rilevazione dei vincoli o regole non rispettate, che
permette non solo la presa visione si questi ultimi (con le conseguenti modifiche)
ma anche la creazione di soluzioni diverse da valutare.
Ciò che viene richiesto è dunque un sistema completo che sia in grado di
permettere il disegno di architetture minuziose, particolareggiate e visibili a tutti gli
utenti, adornate da mezzi che permettano la comunicazione tra gli attori e la
sensibilizzazione alle regole da loro imposte. Si tratta, quindi, sia di mera
comunicazione sincrona tra le parti, comprensiva di scambio di messaggi istantanei
e audio/video conferenza; sia di creazione e visualizzazione di disegni e progetti in
ambiente distribuito; sia di analisi e validazione di regole con conseguente
rilevazione di incompatibilità o errore.
Figura 1: Esempio di interfaccia per la progettazione collaborativa
Capitolo secondo Struttura del sistema - obiettivi
14
2.2 Specifica dei requisiti
Il sistema prodotto, per le funzionalità che è chiamato ad esplicare e per le
caratteristiche richieste, deve soddisfare alcuni requisiti importanti che possono
essere suddivisi in requisiti funzionali e requisiti non funzionali, di seguito esposti.
I primi riguardano le funzionalità che devono essere sviluppate mentre i secondi si
riferiscono alle caratteristiche dell’implementazione e agli effetti che il software ha
sul sistema[12].
Requisiti non funzionali:
• Usabilità: Il sistema deve essere user friendly. L’interfaccia grafica
permette la comunicazione con l’utente e la personalizzazione della
struttura; è necessario quindi che questa sia facilmente comprensibile
da esso.
• Modularità – Estendibilità: Il sistema deve essere modulare, cioè
diviso in moduli a se stanti che interagiscono tra di loro, per conferire
al software chiarezza, pulizia e facilità nell’applicare cambiamenti in
corso d’opera così come in occasione di espansioni future.
• Robustezza: Il sistema deve essere in grado di mantenere un
comportamento corretto e deterministico anche nel caso di situazioni
inattese.
• Interoperabilità: Il sistema deve poter interagire facilmente con gli
altri moduli e le altre parti della struttura al fine di svolgere i suoi
compiti.
• Portabilità: Il sistema deve essere agevolmente adattato alle esigenze
degli utenti di modificarne strumenti e/o ambienti operativi.
Capitolo secondo Struttura del sistema - obiettivi
15
Requisiti funzionali:
• Creazione e salvataggio progetto: Il sistema deve permettere agli
utenti la creazione e il salvataggio del progetto (o delle fasi di un
progetto) architettonico in via di realizzazione.
• Comunicazione: Il sistema deve mettere in comunicazione, sia di tipo
testuale che audio/visiva, i vari partecipanti alla progettazione.
• Verifica vincoli: Il sistema deve verificare il rispetto dei vincoli e delle
regole imposte dagli utenti e permettere il proseguo o il cambiamento
del progetto.
• Valutazione: Il sistema deve permettere la valutazione singola e
complessiva di un’opera.
Al fine di analizzare i requisiti raccolti e facilitare la comprensione delle
proprietà del sistema e delle sue caratteristiche di funzionamento, sono stati
adottati modelli di specifica software orientati agli oggetti. Questi si esplicano nei
diagrammi UML[2][3], tra cui diagramma delle classi, dei casi d’uso, delle attività
attraverso cui si può far luce sulle prestazioni e sugli aspetti funzionali del sistema.
La scelta dell’utilizzo di questi formalismi per l’analisi dei dati è stata dettata dal
fatto che UML focalizza l'attenzione sul processo di lavoro e non sulle tecnologie.
In questo modo, l'avere un meta-modello comune, favorisce la comunicazione tra
strumenti di supporto alla progettazione diversi e soprattutto tra i diversi ambienti
utilizzabili dai progettisti. Infine UML ha la capacità di adattarsi ad ogni tipologia
di progetto, grazie alla sua complessa articolazione.
I diagrammi UML presentati sono stati redatti utilizzando Microsoft Office
Visio 2003[4].
Nella fase di raccolta dei requisiti e intensa attività di relazione con il cliente,
i diagrammi più utilizzati sono stati quelli dei casi d’uso (use case diagram). Questi
Capitolo secondo Struttura del sistema - obiettivi
16
rappresentano una tipica interazione tra un utente (persona o sistema esterno) ed il
sistema software da realizzare e, dato il loro linguaggio altamente compatibile con
il cliente, sono usati sopratutto per le prime fasi di interazione con esso. In questi
diagrammi vengono fatti confluire i requisiti funzionali ai quali il sistema deve
rispondere mentre gli altri requisiti trovano maggiore collocazione in documenti
più specifici.
Il sistema sviluppato è chiamato a svolgere le seguenti “macro-attività”:
Creazione e salvataggio di un progetto
Favorire la comunicazione tra gli utenti
Verificare regole e vincoli
Permettere la valutazione di un progetto
Utente
crea
progetto
valutazione
comunicazione
validazione
<<
include>>
<
<
in
c
lu
d
e>
>
<<
inc
lud
e>
>
Figura 2: Diagramma use-case dell'applicazione