Il processo di progettazione ingegneristica è una serie di passaggi che gli ingegneri seguono quando cercano di risolvere un problema e progettare una soluzione per qualcosa; è un approccio metodico alla risoluzione dei problemi. Non esiste un unico processo di progettazione universalmente accettato e la maggior parte degli ingegneri ha una propria interpretazione del funzionamento del processo. Il processo generalmente inizia con un problema e termina con una soluzione, ma i passaggi intermedi possono variare.
Una caratteristica comune della maggior parte dei processi di progettazione è che sono iterativi e i progettisti potrebbero dover tornare ai passaggi precedenti del processo e/o ripetere l'intero processo più e più volte fino a raggiungere una soluzione minimamente praticabile.
Il processo di progettazione tecnica descritto in questo articolo non è l'unica versione corretta del processo, è solo un esempio. Dovrebbe fornire agli studenti un buon punto di partenza per esplorare il processo di ingegneria.
Un processo di progettazione molto semplice può includere solo 3 passaggi, come mostrato di seguito: Definisci, Sviluppa soluzioni e Ottimizza (questa illustrazione è disponibile come poster a grandezza naturale su posters.vex.com se ne desideri uno per la tua classe!).
Un altro esempio di processo di progettazione è Project Lead The Way's Gateway Design Process.
Fasi del processo di progettazione ingegneristica
Per questo articolo, prenderemo in considerazione un processo di progettazione che corrisponda a ciò che i giudici cercano quando intervistano i team e rivedono i loro quaderni di ingegneria alle competizioni della REC Foundation.
Identificare la sfida & obiettivi prefissati
Questo a volte viene chiamato “Chiedi” o “Definisci”. Identificare la sfida dovrebbe sempre essere il primo passo da affrontare nel processo di progettazione.
Per la prima iterazione del processo di progettazione, il taccuino del team dovrebbe includere una breve descrizione della sfida complessiva del gioco e suddividerla in sfide più piccole che devono essere completate per avere successo. La migliore pratica è elencare le domande a cui è necessario rispondere attraverso la ricerca o i test, ad esempio:
- Qual è la strategia più efficace per giocare?
- Quali sono i modi per segnare punti?
- A quale velocità deve muoversi il robot?
- Come può il robot raccogliere gli oggetti da segnare?
- Quanti oggetti con punteggio deve contenere il robot?
Attraverso questo processo, i team dovrebbero elaborare un elenco di funzionalità che potrebbero desiderare nel proprio robot e un elenco dei requisiti e dei vincoli del gioco. Ad esempio, se una sfida richiede che un robot impila gli oggetti il più in alto possibile, il team potrebbe decidere di volere che il proprio robot sia alto. Tuttavia, il manuale del gioco potrebbe imporre un limite all'altezza massima del robot in un dato momento. Tutti questi criteri dovrebbero essere esplorati e compresi prima di passare alla fase di brainstorming.
Per i cicli successivi del processo di progettazione, questo passaggio potrebbe consistere nell'identificare qualcosa sul robot che non funziona come previsto o necessario e nel descrivere cosa includerebbe una buona soluzione. Ad esempio, una sfida potrebbe essere "Il braccio del robot deve essere in grado di arrivare più in alto per segnare la palla" e un obiettivo per portare a termine la sfida potrebbe essere "La parte inferiore dell'artiglio deve essere in grado di raggiungere fino a 16 punti" "quando si tiene in mano una palla." I vincoli per questa sfida potrebbero sovrapporsi a vincoli più grandi del gioco, ad esempio dimensioni e limiti di espansione verticale.
Brainstorming & Diagramma
Un buon brainstorming inizia con una comprensione condivisa del problema, compresi tutti i requisiti e i vincoli. Senza comprendere il problema, si può perdere tempo con idee irrilevanti che non soddisfano il problema di base in questione. Durante il brainstorming, è anche importante evitare chegiudichino le idee degli altri. Ciò può soffocare il processo creativo e scoraggiare i membri del team dalla partecipazione.
Se diventa chiaro che i membri del team non comprendono appieno il problema, il team dovrebbe ricominciare dalla prima fase del processo (ad esempio, "Identificare il problema" o "Chiedere").
Durante il brainstorming, gli studenti potrebbero anche voler indagare su sfide del mondo reale simili a quelle poste dal gioco. Possono anche verificare se altre competizioni di robotica hanno utilizzato sfide simili in passato. Il brainstorming include la raccolta di dati da altre fonti per aiutare gli studenti a creare una soluzione di successo.
Le soluzioni promettenti dovrebbero essere documentate nel taccuino del team, includendo disegni o immagini etichettati. Se il team trae idee da altre fonti, tali fonti dovrebbero essere chiaramente identificate nel taccuino.
Scegli una soluzione & Crea un piano
Una volta completato il brainstorming e generate diverse idee, i team dovrebbero valutare obiettivamente ciascuna idea. L’obiettivo è trovare la soluzione migliore per la squadra, indipendentemente dalla fonte. Una tabella potrebbe aiutare i team a considerare e confrontare i meriti di ciascuna idea in relazione a desideri e vincoli di progettazione specifici. Nell'esempio seguente, ciascun criterio viene valutato su una scala da 0 a 5 dove 0 non soddisfa e 5 supera le aspettative. Poiché “Idea 4” ha il punteggio complessivo più alto, sarebbe la scelta obiettiva.
|
Idea |
Criteri 1 |
Criteri 2 |
Criteri 3 |
Criterio 4 |
Punteggio totale |
|
Idea 1 |
3 |
3 |
2 |
1 |
9 |
|
Idea 2 |
5 |
5 |
0 |
0 |
10 |
|
Idea 3 |
1 |
1 |
5 |
5 |
12 |
|
Idea 4 |
4 |
4 |
4 |
4 |
16 |
Il team dovrebbe documentare questo processo nel quaderno e spiegare come e perché ha scelto la soluzione. Dovrebbero inoltre descrivere in modo completo la soluzione nel loro taccuino di progettazione, incluso un piano su come la costruiranno. Per i team avanzati, questo piano può includere la creazione di modelli CAD o disegni di assieme dettagliati.
Costruisci & programma
È qui che i team trascorreranno la maggior parte del loro tempo e dove verranno creati i prototipi, i robot e i programmi finali. Le costruzioni, sia per il codice che per i robot, generalmente iniziano come progetti di base e si evolvono man mano che i dettagli vengono aggiunti nei cicli successivi del processo di progettazione. Gli studenti dovrebbero prendere appunti dettagliati sul loro quaderno mentre sviluppano & programmazione, registrando ciò che vedono, cercando di capire perché alcune cose funzionano meglio di altre e quindi creando prototipi o programmi aggiuntivi per testare nuove idee. La raccolta dei dati e la loro registrazione sul notebook è una parte importante della costruzione e della programmazione.
Testare la soluzione
Durante questa fase, gli studenti metteranno alla prova ciò che hanno costruito o programmato per vedere cosa funziona, cosa no e cosa può essere migliorato. Le procedure di test dovrebbero essere ben documentate nel quaderno e dovrebbero includere tutti i risultati misurabili. L'obiettivo principale di questo passaggio è decidere se la build o il codice soddisfa la sfida e funziona come previsto e necessario.
Ripeti il processo di progettazione
Cosa succede quando qualcosa non funziona nei test? Gli studenti analizzano il problema per identificare la nuova sfida che presenta e iniziano un nuovo ciclo del processo di progettazione!
Non tutti i cicli del processo di progettazione richiederanno tutti i passaggi e alcuni potrebbero saltare da un passaggio all'altro o ripetere un passaggio più volte prima di passare a quello successivo. I team di progettazione non dovrebbero aver paura di tornare indietro nel processo di progettazione. L'obiettivo finale è creare il miglior design possibile migliorandolo più e più volte. Probabilmente anche i cicli di progettazione si sovrapporranno, soprattutto tra i sottosistemi robot e il codice. I team dovrebbero fare del loro meglio per identificare a quali fasi del processo di progettazione stanno lavorando mentre inseriscono le voci nel taccuino.
Allora come fa una squadra a decidere quando il suo robot ha finito? Semplice: il team deve stabilire un programma e poi rispettarlo. Questo programma varierà notevolmente da squadra a squadra a seconda delle circostanze. Se una squadra ha sei settimane per progettare e costruire il proprio robot prima della prima competizione, dovrebbe elaborare una sorta di programma per questo periodo di tempo. Alcuni team pianificheranno ogni singola fase del processo di creazione, mentre altri si limiteranno a fare una rapida panoramica.
Il programma non è sempre scolpito nella pietra; alla fine le uniche date fisse sono la data di inizio del progetto e la scadenza per il completamento del robot (di solito la data di un concorso). Tutto il resto probabilmente cambierà man mano che il processo si svolge.