Inženierprojektēšanas process ir virkne darbību, ko inženieri veic, mēģinot atrisināt problēmu un izstrādāt risinājumu kaut kam; tā ir metodiskā pieeja problēmu risināšanai. Nav viena vispārpieņemta projektēšanas procesa, un lielākajai daļai inženieru ir savs process, kā tas darbojas. Process parasti sākas ar problēmu un beidzas ar risinājumu, bet vidus posmi var atšķirties.
Viena kopīga iezīme lielākajai daļai projektēšanas procesu ir tā, ka tie ir iteratīvi, un dizaineriem var nākties atgriezties pie iepriekšējiem procesa posmiem un/vai atkārtot visu procesu atkal un atkal, līdz tiek sasniegts minimāli dzīvotspējīgs risinājums.
Šajā rakstā aprakstītais inženiertehniskās projektēšanas process nav vienīgā pareizā procesa versija, tas ir tikai viens piemērs. Tam ir jānodrošina labs sākumpunkts, lai studenti varētu izpētīt inženiertehnisko procesu.
Ļoti vienkāršs projektēšanas process var ietvert tikai 3 darbības, kā parādīts zemāk: Definēšana, risinājumu izstrāde un optimizēšana (šī ilustrācija ir pieejama kā pilna izmēra plakāts vietnē posters.vex.com , ja vēlaties tādu savā klasē!).
Vēl viens projektēšanas procesa piemērs ir Project Lead The Way's Gateway Design Process.
Inženierprojektēšanas procesa soļi
Šajā rakstā mēs apsvērsim izstrādes procesu, kas atbilst tam, ko meklē tiesneši, intervējot komandas un pārskatot to inženierzinātņu piezīmju grāmatiņas REC Foundation sacensībās.
Identificējiet & izaicinājumu, uzstādiet mērķus
To dažreiz sauc par “jautāt” vai “definēt”. Izaicinājuma identificēšanai vienmēr jābūt pirmajam solim, kas tiek risināts projektēšanas procesā.
Pirmajā projektēšanas procesa atkārtojumā komandas piezīmju grāmatiņā jāiekļauj ļoti īss spēles vispārējā izaicinājuma apraksts un tas jāsadala mazākos izaicinājumos, kas jāizpilda, lai gūtu panākumus. Labākā prakse ir uzskaitīt jautājumus, uz kuriem jāatbild, izmantojot pētījumu vai testēšanu, piemēram:
- Kāda ir visefektīvākā spēles stratēģija?
- Kādi ir veidi, kā gūt punktus?
- Cik ātri robotam jāpārvietojas?
- Kā robots var paņemt punktus?
- Cik vērtēšanas objektu robotam ir jātur?
Izmantojot šo procesu, komandām ir jāsagatavo to funkciju saraksts, kuras tās varētu vēlēties savā robotā, kā arī spēles prasību un ierobežojumu saraksts. Piemēram, ja izaicinājums liek robotam sakraut objektus pēc iespējas augstāk, komanda var izlemt, ka vēlas, lai robots būtu garš. Tomēr spēles rokasgrāmatā var būt ierobežojumi attiecībā uz robota garumu jebkurā laikā. Visi šie kritēriji ir jāizpēta un jāsaprot, pirms pāriet uz prāta vētras fāzi.
Vēlākos projektēšanas procesa ciklos šis solis varētu būt robotā kaut ko tādu identificēt, kas nedarbojas tik labi, kā paredzēts vai vajadzīgs, un aprakstīt, kas būtu labs risinājums. Piemēram, izaicinājums varētu būt šāds: "Robota rokai ir jāspēj sasniegt augstāk, lai gūtu bumbu", un uzdevuma izpildes mērķis varētu būt: "Spīles apakšdaļai ir jāspēj sasniegt līdz 16. "turot bumbu." Ierobežojumi šim izaicinājumam var pārklāties ar lielākiem spēles ierobežojumiem, piemēram, izmēra un vertikālās paplašināšanas ierobežojumiem.
Prāta vētra & diagramma
Laba prāta vētra sākas ar kopīgu izpratni par problēmu, tostarp visām prasībām un ierobežojumiem. Neizprotot problēmu, laiks var tikt tērēts neatbilstošām idejām, kas neapmierina galveno problēmu. Prātalaikā ir svarīgi arī izvairīties noideju vērtēšanas. Tas var apslāpēt radošo procesu un atturēt komandas locekļus no līdzdalības.
Ja kļūst skaidrs, ka komandas locekļi pilnībā neizprot problēmu, komandai jāsāk no jauna ar procesa pirmo posmu (ti, “Identificējiet problēmu” vai “Jautājiet”).
Prāta vētras laikā skolēni var arī vēlēties izpētīt izaicinājumus no reālās pasaules, kas ir līdzīgi spēles radītajiem izaicinājumiem. Viņi var arī noskaidrot, vai kādas citas robotikas sacensības agrāk ir izmantojušas līdzīgas problēmas. Prāta vētra ietver datu vākšanu no citiem avotiem, lai palīdzētu studentiem izveidot veiksmīgu risinājumu.
Daudzsološie risinājumi ir jādokumentē komandas piezīmju grāmatiņā, iekļaujot marķētus zīmējumus vai attēlus. Ja komanda gūst idejas no citiem avotiem, šie avoti ir skaidri jānorāda piezīmju grāmatiņā.
Izvēlieties risinājumu & Izveidojiet plānu
Kad prāta vētra ir pabeigta un vairākas idejas ir ģenerētas, komandām ir objektīvi jāizvērtē katra ideja. Mērķis ir atrast labāko risinājumu komandai neatkarīgi no avota. Tabula var palīdzēt komandām apsvērt un salīdzināt katras idejas priekšrocības saistībā ar konkrētām dizaina vēlmēm un ierobežojumiem. Tālāk esošajā piemērā katrs kritērijs ir novērtēts 0-5 ballu skalā, kur 0 neatbilst un 5 pārsniedz gaidīto. Tā kā “Idejai 4” ir visaugstākais kopējais punktu skaits, tā būtu objektīva izvēle.
|
Ideja |
1. kritērijs |
2. kritērijs |
3. kritērijs |
4. kritērijs |
Kopējais rezultāts |
|
1. ideja |
3 |
3 |
2 |
1 |
9 |
|
2. ideja |
5 |
5 |
0 |
0 |
10 |
|
3. ideja |
1 |
1 |
5 |
5 |
12 |
|
4. ideja |
4 |
4 |
4 |
4 |
16 |
Komandai šis process jādokumentē piezīmju grāmatiņā un jāpaskaidro, kā un kāpēc viņi izvēlas savu risinājumu. Viņiem arī pilnībā jāapraksta risinājums savā inženiertehniskajā piezīmju grāmatiņā, tostarp plāns, kā tas tiks izveidots. Uzlabotām komandām šis plāns var ietvert CAD modeļu vai detalizētu montāžas rasējumu izveidi.
Programma Build &
Šeit komandas pavadīs lielāko daļu sava laika, un tiek izveidoti prototipi un galīgie roboti un programmas. Buildes — gan kodam, gan robotiem — parasti sākas kā pamata dizains un attīstās, kad vēlākos projektēšanas procesa ciklos tiek pievienota informācija. Studentiem savā piezīmju grāmatiņā jāveic detalizētas piezīmes, veidojot & programmēšanu, ierakstot redzēto, mēģinot noskaidrot, kāpēc dažas lietas darbojas labāk nekā citas, un pēc tam izveidojot papildu prototipus vai programmas, lai pārbaudītu jaunas idejas. Datu vākšana un ierakstīšana piezīmjdatorā ir svarīga veidošanas un programmēšanas sastāvdaļa.
Pārbaudiet risinājumu
Šīs darbības laikā skolēni pārbaudīs, ko viņi ir izveidojuši vai ieprogrammējuši, lai redzētu, kas darbojas, kas nedarbojas un ko var uzlabot. Testēšanas procedūrām jābūt labi dokumentētām piezīmju grāmatiņā, un tajās jāietver visi izmērāmie rezultāti. Šīs darbības galvenais mērķis ir izlemt, vai būvējums vai kods atbilst izaicinājumam un darbojas, kā paredzēts un nepieciešams.
Atkārtojiet projektēšanas procesu
Kas notiek, ja testēšanā kaut kas nedarbojas? Studenti analizē problēmu, lai noteiktu jauno izaicinājumu, ko tā rada, un viņi sāk jaunu projektēšanas procesa ciklu!
Ne visiem projektēšanas procesa cikliem būs nepieciešamas visas darbības, un daži var pāriet no soļa uz soli vai atkārtot darbību vairākas reizes, pirms pāriet uz nākamo. Dizaina komandām nevajadzētu baidīties no projektēšanas procesa atkāpšanās. Galīgais mērķis ir izveidot vislabāko iespējamo dizainu, to atkal un atkal uzlabojot. Iespējams, ka arī projektēšanas cikli pārklājas, īpaši starp robotu apakšsistēmām un kodu. Grupām ir jādara viss iespējamais, lai noteiktu, kurā(-ās) projektēšanas procesa solī(-s) tās strādā, veicot ierakstus piezīmju grāmatiņā.
Tātad, kā komanda izlemj, kad viņu robots ir pabeigts? Vienkārši: komandai ir jāizveido grafiks un pēc tam jāpieturas pie tā. Šis grafiks dažādās komandās ļoti atšķirsies atkarībā no apstākļiem. Ja komandai ir sešas nedēļas, lai izstrādātu un izveidotu savu robotu pirms pirmajām sacensībām, tai ir jāizstrādā sava veida grafiks šim laika periodam. Dažas komandas plānos katru soli savā veidošanas procesā, savukārt citas veiks tikai ātru pārskatu.
Grafiks ne vienmēr ir akmenī cirsts; galu galā vienīgie noteiktie datumi ir projekta sākuma datums un robota pabeigšanas termiņš (parasti sacensību datums). Viss pārējais, visticamāk, mainīsies procesam attīstoties.