Estratto del documento

PARENTESI SULL’INERZIA PSICOLOGICA NELLA PROGETTAZIONE

La fase iniziale della progettazione (Conceptual design) è determinante per il costo finale del prodotto

inquanto:

• Nella fase iniziale il problema è sicuramente meno definito, comportando la possibilità/necessità di

esplorare diverse aree del design space.

• Man mano che si procede con la progettazione, si converge verso la soluzione finale sulla base delle

scelte fatte durante le fasi iniziali della progettazione che determinano quindi i costi e le performance

del prodotto finale.

Citando Nigel Cross, la tradizione didattica ingegneristica (o tecnica in generale), porta spesso (non sempre

volutamente) a formare persone che prediligono approcci con «convergenza» predominante, e quindi scarsa

«divergenza» e conseguente scarsa esplorazione del Design Space. Approcci del genere si dicono «SOLUTION

BASED» ovvero basati sulla veloce definizione di una soluzione/idea di partenza per passare velocemente alla

sua concretizzazione ed ottimizzazione durante il processo di progettazione. È vero che in questo modo la

fase concettuale è molto rapida, ma ci vuole una discreta dose di fortuna nello scegliere la soluzione di

partenza.

Approcci solution-based portano quindi ad una ripartizione delle tempistiche progettuali nettamente spostata

verso le fasi di embodiment e di dettaglio.

Spesso nella pratica vengono adottati processi intuitivi che affrontano i problemi ingegneristici iniziando con

il proporre una prima soluzione, per poi affinarla via via. Esempio:

Problema: Macchinario industriale che processa cemento e sabbia, da cui cade continuamente parte della

materia prima processata, la quale deve essere quindi recuperata.

Soluzione proposta dall’azienda: nastro trasportatore per il recupero della materia prima In questo modo

l’attività di progettazione prosegue con l’affinamento della soluzione atta a «recuperare qualcosa che è

caduto».

Ma in questo modo il progettista si mette una sorta di «paraocchi» trascurando la possibilità di soluzioni

che, ad esempio, «evitino che il materiale cada».

Ma è veramente necessario ridurre i tempi della progettazione concettuale, a scapito di una esplorazione

più profonda del design space? La risposta è NO! Infatti sappiamo che la fase concettuale «costa» poco ma

«pesa» molto sulla probabilità di successo del prodotto.

Inoltre che succede se durante una fase avanzata della progettazione ci rendiamo conto che la soluzione

scelta non può raggiungere i livelli di performance desiderati? Le iterazioni sono naturalmente previste nella

progettazione. Ma più è avanzato lo stato in cui ci accorgiamo di dover iterare, più sono ovviamente alti i

costi di progettazione andati letteralmente in fumo.

Approfondire la progettazione concettuale non significa semplicemente dedicarci più tempo. Questo perché

purtroppo gli esseri umani hanno un modo di pensare prevalentemente convergente (in misura soggettiva

ovviamente), che si basa fortemente sul bagaglio di conoscenze personalmente a disposizione di ciascun

individuo. Il che significa che senza l’ausilio di strumenti metodologici opportunamente sviluppati, il

progettista tende ad affrontare il problema direttamente, incappando però nelle limitazioni indotte

dall’inerzia psiocologica. Lo strumento metodologico dovrebbe quindi consentire al progettista di superare

le barriere psicologiche ed andare quindi oltre l’esperienza e la conoscenza personale.

L’arma per superare suddette barriere è quella della astrazione. In altre parole, anziché affrontare il

problema direttamente, si cerca di analizzarlo a fondo, ricondurlo ad un problema generico fuori dal

contesto reale, e di generare una o più soluzioni. Dopodiché, non resta che riadattare la soluzione generica

al caso specifico.

L’astrazione aiuta quindi a svincolarsi da preconcetti iniziali. Ma i problemi ingegneristici sono per loro

natura spesso molto complessi, ragion per cui non è facile ricondursi da una soluzione generica alla

soluzione concreta (che rispetta cioè tutti i vincoli e gli obiettivi caratterizzanti il task di progettazione

specifico). Fortunatamente, la pratica ingegneristica ci insegna a SCOMPORRE un problema complesso in

una serie di sotto-problemi più elementari da risolvere (Non esiste nessun processo/strumento capace di

automatizzare i passi necessari per generalizzare il problema principale, trovare le soluzioni ai problemi

elementari e quindi ricomporle in una soluzione globale).

Sono però stati sviluppati dei metodi di progettazione sistematica di ausilio al progettista, che

comprendono anche una parte dedicata alla progettazione concettuale basata su approccio al problema di

tipo problem based.

Da ricordare:

• La progettazione concettuale è una fase critica del processo di sviluppo del prodotto,

principalmente perché:

o Ha costi limitati.

o Le decisioni prese in tale fase incidono pesantemente sui costi dell’intero processo di sviluppo

prodotto.

• L’inerzia psicologica (o Design Fixation) può ostacolare una esaustiva esplorazione del Design Space.

• L’astrazione è l’arma da usare contro l’inerzia psicologica.

• La scomposizione di problemi in sotto-problemi elementari, è la tecnica ingegneristica per ridurre la

complessità del problema da affrontare.

Approccio Classico: Functional Decomposition and Morphology

Pahl e Beitz propongono un approccio alla progettazione concettuale basato su un modello prescrittivo. Un

modello cioè, che di fatto indica al progettista gli step da seguire, guidandolo nel processo di progettazione

concettuale.

Tuttavia, ciò non significa che il processo possa essere completamente automatizzato, in quanto il processo

di analisi e sintesi caratteristico della mente umana rimane fondamentale (dando quindi adito ad una certa

soggettività).

Questa prima parte è dedicata all’interpretazione ed all’astrazione delle informazioni contenute nella

requirement list.

Il concetto di astrazione:

Nell’analisi della lista dei requisiti, ignorare tutto ciò che «specifico» e/o «accessorio» ed enfatizzare invece

tutto ciò che è «generale» e «fondamentale».

In questo modo è possibile saltare direttamente al nodo cruciale del Task di progettazione, evitando (per

quanto possibile) di trascinare nel processo di progettazione i, purtroppo, sempre presenti preconcetti

derivanti da inerzia psicologica.

Problema specifico:

Pulire gli abiti dallo sporco:

- Capacità produttiva di X kg ora

- Ingombro X x Y x Z < tot

- Peso < 50 kg

- Rumorosità < 50 dB

Astrazione:

Problema generale:

Separare una sostanza da un’altra

Le strutture funzionali:

Questa è invece una delle due caratteristiche fondamentali che distinguono questo tipo modello

prescrittivo. Infatti, non vengono considerati problemi nel senso più generico del termine, bensì funzioni

che il sistema deve implementare.

Sistema tecnico:

Sotto tale definizione ricadono, in generale, tutti quegli artefatti tecnici (macchine, impianti, componenti,

sottoassiemi, ecc) che svolgono un determinato compito, ovvero, soddisfano un determinato bisogno.

In generale, è possibile definire un sistema tecnico come un sistema capace di processare flussi di

ENERGIA, MATERIALE e SEGNALE definiti in maniera qualitativa, quantitativa ed esprimibili in termini

tecnico-economici. Ovvero, un sistema tecnico è capace di trasformare i flussi in ingresso in flussi di uscita.

Funzione:

Azione che un elemento di un sistema tecnico è in grado di compiere e per il quale è stato concepito.

Definisce la relazione funzionale tra ingresso ed uscita di un sistema tecnico.

Dalla fase di astrazione si riesce ad identificare la funzione principale del sistema con i relativi flussi

principali. Tale funzione principale viene quindi scomposta in sotto-funzioni più elementari. Di fatto la

scomposizione funzionale consiste nell’interpretare come i flussi vengano processati da un punto di vista

prettamente funzionale, cercando di non prendere in considerazione nessuna soluzione specifica. Una

volta identificate le funzioni, è il momento di identificare i Working Principles WP (principi di

funzionamento) capaci di implementarle. Questo va fatto per ogni singola funzione, dopodichè si cerca di

comporre un concept complessivo, a partire da questi building blocks.

I working principles (WP) sono la combinazione tra il

principio fisico e le caratteristiche fisiche (geometria,

materiale) utilizzate per risolvere un dato problema

(implementare una funzione). Lo strumento che

consente di archiviare i principi di funzionamento e di

comporli in diverse varianti di concept, è la cosiddetta

mappa morfologica.

La combinazione di diversi WP (implementanti funzioni

distinte) identifica una working structure (WS),

associata alla struttura funzionale del sistema. I WP

archiviati nella mappa/matrice morfologica devono

essere combinati insieme in maniera logica, al fine di

ottenere le varianti di WS.

Una volta che il funzionamento delle WS è stato preliminarmente confermato (tramite primi calcoli, semplici

riflessioni e/o confronti) ed è possibile identificare chiaramente il funzionamento del sistema, allora si parla

di principle solutions (ovvero le varianti di concept). Una volta generate le varianti di concept (in numero

ragionevole), queste vengono selezionate in funzione di una serie di parametri di valutazione, estraibili dalla

versione finale della lista dei requisiti. Alcuni strumenti per la selezione dei concept generati saranno

mostrati nelle prossime slide. Per ora basti sapere che si tratta di semplici matrici di valutazione, da

compilare attentamente assieme al committente.

L’approccio funzionale-morfologico (FDM) non consente una gestione esaustiva dell’esplorazione del Design

Space, in quanto non consente di controllare la co-evoluzione di problemi e soluzioni durante la fase di

scomposizione.

Da ricordare:

• Suddivide il processo di progettazione concettuale in diverse fasi, tra cui la generazione della

struttura funzionale e la compilazione della relativa morphological chart.

• Si ragiona in termini prettamente funzionali

• Una funzione è vista come una scatola nera che processa dei flussi in ingresso e li trasforma in flussi

in uscita.

• Non esiste una definizione universalmente accettata di funzione

• La scomposizione funzionale è fortemente influenzata dalle necessarie ipotesi preliminari sul

prodotto finale

• Per ogni diversa mappa funzionale è necessario realizzare una diversa mappa morfologica.

11.

Anteprima
Vedrai una selezione di 18 pagine su 82
Appunti di Sviluppo e ingegnerizzazione del prodotto  Pag. 1 Appunti di Sviluppo e ingegnerizzazione del prodotto  Pag. 2
Anteprima di 18 pagg. su 82.
Scarica il documento per vederlo tutto.
Appunti di Sviluppo e ingegnerizzazione del prodotto  Pag. 6
Anteprima di 18 pagg. su 82.
Scarica il documento per vederlo tutto.
Appunti di Sviluppo e ingegnerizzazione del prodotto  Pag. 11
Anteprima di 18 pagg. su 82.
Scarica il documento per vederlo tutto.
Appunti di Sviluppo e ingegnerizzazione del prodotto  Pag. 16
Anteprima di 18 pagg. su 82.
Scarica il documento per vederlo tutto.
Appunti di Sviluppo e ingegnerizzazione del prodotto  Pag. 21
Anteprima di 18 pagg. su 82.
Scarica il documento per vederlo tutto.
Appunti di Sviluppo e ingegnerizzazione del prodotto  Pag. 26
Anteprima di 18 pagg. su 82.
Scarica il documento per vederlo tutto.
Appunti di Sviluppo e ingegnerizzazione del prodotto  Pag. 31
Anteprima di 18 pagg. su 82.
Scarica il documento per vederlo tutto.
Appunti di Sviluppo e ingegnerizzazione del prodotto  Pag. 36
Anteprima di 18 pagg. su 82.
Scarica il documento per vederlo tutto.
Appunti di Sviluppo e ingegnerizzazione del prodotto  Pag. 41
Anteprima di 18 pagg. su 82.
Scarica il documento per vederlo tutto.
Appunti di Sviluppo e ingegnerizzazione del prodotto  Pag. 46
Anteprima di 18 pagg. su 82.
Scarica il documento per vederlo tutto.
Appunti di Sviluppo e ingegnerizzazione del prodotto  Pag. 51
Anteprima di 18 pagg. su 82.
Scarica il documento per vederlo tutto.
Appunti di Sviluppo e ingegnerizzazione del prodotto  Pag. 56
Anteprima di 18 pagg. su 82.
Scarica il documento per vederlo tutto.
Appunti di Sviluppo e ingegnerizzazione del prodotto  Pag. 61
Anteprima di 18 pagg. su 82.
Scarica il documento per vederlo tutto.
Appunti di Sviluppo e ingegnerizzazione del prodotto  Pag. 66
Anteprima di 18 pagg. su 82.
Scarica il documento per vederlo tutto.
Appunti di Sviluppo e ingegnerizzazione del prodotto  Pag. 71
Anteprima di 18 pagg. su 82.
Scarica il documento per vederlo tutto.
Appunti di Sviluppo e ingegnerizzazione del prodotto  Pag. 76
Anteprima di 18 pagg. su 82.
Scarica il documento per vederlo tutto.
Appunti di Sviluppo e ingegnerizzazione del prodotto  Pag. 81
1 su 82
D/illustrazione/soddisfatti o rimborsati
Acquista con carta o PayPal
Scarica i documenti tutte le volte che vuoi
Dettagli
SSD
Ingegneria industriale e dell'informazione ING-IND/15 Disegno e metodi dell'ingegneria industriale

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher IngMecUnifi di informazioni apprese con la frequenza delle lezioni di Sviluppo e ingegnerizzazione del prodotto e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Università degli Studi di Firenze o del prof Rotini Federico.
Appunti correlati Invia appunti e guadagna

Domande e risposte

Hai bisogno di aiuto?
Chiedi alla community