Inžinerinio projektavimo procesas – tai eilė žingsnių, kurių laikosi inžinieriai, kai bando išspręsti problemą ir kuria kažkokį sprendimą; tai metodinis požiūris į problemų sprendimą. Nėra vieno visuotinai priimto projektavimo proceso, o dauguma inžinierių turi savo posūkį, kaip šis procesas veikia. Procesas paprastai prasideda nuo problemos ir baigiasi sprendimu, tačiau viduriniai žingsniai gali skirtis.
Viena bendra daugelio projektavimo procesų ypatybė yra ta, kad jie kartojasi ir dizaineriams gali tekti grįžti prie ankstesnių proceso žingsnių ir (arba) kartoti visą procesą vėl ir vėl, kol pasieks minimaliai perspektyvų sprendimą.
Šiame straipsnyje aprašytas inžinerinio projektavimo procesas nėra vienintelė teisinga proceso versija, tai tik vienas pavyzdys. Tai turėtų būti geras atspirties taškas studentams tyrinėti inžinerinį procesą.
Labai paprastas projektavimo procesas gali apimti tik 3 veiksmus, kaip parodyta toliau: Apibrėžimas, sprendimų kūrimas ir optimizavimas (šią iliustraciją galite rasti kaip viso dydžio plakatą adresu posters.vex.com , jei norite tokio savo klasėje!).
Kitas projektavimo proceso pavyzdys yra Project Lead The Way's Gateway projektavimo procesas.
Inžinerinio projektavimo proceso žingsniai
Šiame straipsnyje mes apsvarstysime projektavimo procesą, atitinkantį tai, ko teisėjai ieško apklausdami komandas ir peržiūrėdami jų inžinerinius bloknotus REC fondo varžybose.
Nustatykite & iššūkį, nustatykite tikslus
Tai kartais vadinama „Klausti“ arba „Apibrėžti“. Iššūkio nustatymas visada turėtų būti pirmasis žingsnis, į kurį atsižvelgiama projektavimo procese.
Pirmą kartą kūrimo proceso metu komandos užrašų knygelėje turėtų būti labai trumpas viso žaidimo iššūkio aprašymas ir jis suskirstytas į mažesnius iššūkius, kuriuos reikia atlikti norint pasiekti sėkmės. Geriausia praktika yra išvardyti klausimus, į kuriuos reikia atsakyti atliekant tyrimus arba bandymus, pavyzdžiui:
- Kokia yra efektyviausia žaidimo strategija?
- Kokie yra taškų rinkimo būdai?
- Kaip greitai robotas turi judėti?
- Kaip robotas gali paimti balų objektus?
- Kiek taškų turinčių objektų turi laikyti robotas?
Per šį procesą komandos turėtų sudaryti funkcijų, kurių jos gali norėti savo robote, sąrašą ir žaidimo reikalavimų bei apribojimų sąrašus. Pavyzdžiui, jei dėl iššūkio robotas turi sukrauti objektus kuo aukščiau, komanda gali nuspręsti, kad nori, kad jų robotas būtų aukštas. Tačiau žaidimo vadove gali būti apribotas roboto ūgis bet kuriuo metu. Visi šie kriterijai turėtų būti ištirti ir suprasti prieš pereinant prie minčių šturmo etapo.
Vėlesniuose projektavimo proceso cikluose šis veiksmas gali būti identifikuoti robote ką nors, kas neveikia taip, kaip tikėtasi ar reikalinga, ir apibūdinti, koks būtų geras sprendimas. Pavyzdžiui, iššūkis gali būti toks: „Roboto ranka turi turėti galimybę pasiekti aukščiau, kad įmuštų kamuolį“, o užduoties tikslas gali būti: „Letenos apačia turi turėti galimybę pasiekti iki 16 "laikant kamuolį". Šio iššūkio apribojimai gali sutapti su didesniais žaidimo apribojimais, pavyzdžiui, dydžio ir vertikalios išplėtimo ribomis.
Brainstorm & diagrama
Geras minčių šturmas prasideda nuo bendro problemos supratimo, įskaitant visus reikalavimus ir apribojimus. Nesuprantant problemos, laikas gali būti švaistomas nereikšmingoms idėjoms, kurios nepatenkina pagrindinės problemos. Protų šturmo metu taip pat svarbu vengtivertinti vienas kito idėjas. Tai gali užgniaužti kūrybinį procesą ir atgrasyti komandos narius nuo dalyvavimo.
Jei tampa aišku, kad komandos nariai nevisiškai supranta problemos, komanda turėtų pradėti iš naujo nuo pirmojo proceso žingsnio (ty „Nustatykite problemą“ arba „Klauskite“).
Protų šturmo metu mokiniai taip pat gali norėti ištirti realaus pasaulio iššūkius, panašius į žaidimo keliamus iššūkius. Jie taip pat gali pažiūrėti, ar kitose robotikos varžybose praeityje buvo naudojami panašūs iššūkiai. Smegenų šturmas apima duomenų rinkimą iš kitų šaltinių, kad padėtų studentams sukurti sėkmingą sprendimą.
Perspektyvūs sprendimai turėtų būti dokumentuojami komandos užrašų knygelėje, įskaitant paženklintus brėžinius ar paveikslėlius. Jei komanda semiasi idėjų iš kitų šaltinių, tie šaltiniai turi būti aiškiai nurodyti sąsiuvinyje.
Pasirinkite sprendimą & Sudarykite planą
Baigus minčių šturmą ir sugeneravus keletą idėjų, komandos turėtų objektyviai įvertinti kiekvieną idėją. Tikslas – rasti geriausią sprendimą komandai, nepriklausomai nuo šaltinio. Lentelė gali padėti komandoms apsvarstyti ir palyginti kiekvienos idėjos pranašumus, atsižvelgiant į konkrečius dizaino norus ir apribojimus. Toliau pateiktame pavyzdyje kiekvienas kriterijus vertinamas 0–5 balų skalėje, kur 0 neatitinka, o 5 viršija lūkesčius. Kadangi „Idėja 4“ surinko aukščiausią bendrą balą, tai būtų objektyvus pasirinkimas.
|
Idėja |
1 kriterijus |
2 kriterijus |
3 kriterijus |
4 kriterijus |
Galutinis rezultatas |
|
1 idėja |
3 |
3 |
2 |
1 |
9 |
|
2 idėja |
5 |
5 |
0 |
0 |
10 |
|
3 idėja |
1 |
1 |
5 |
5 |
12 |
|
4 idėja |
4 |
4 |
4 |
4 |
16 |
Komanda turėtų dokumentuoti šį procesą užrašų knygelėje ir paaiškinti, kaip ir kodėl jie pasirenka sprendimą. Jie taip pat turėtų išsamiai aprašyti sprendimą savo inžinerijos bloknote, įskaitant planą, kaip jį sukurti. Pažengusioms komandoms šis planas gali apimti CAD modelių arba detalių surinkimo brėžinių kūrimą.
„Build & “ programa
Čia komandos praleis didžiąją laiko dalį ir bus kuriami prototipai bei galutiniai robotai ir programos. Tiek kodo, tiek robotų versijos paprastai prasideda kaip pagrindinis dizainas ir vystosi, kai detalės pridedamos vėlesniuose projektavimo proceso cikluose. Mokiniai turėtų užsirašyti išsamias pastabas savo sąsiuvinyje, kurdami & programavimą, įrašydami tai, ką mato, bandydami išsiaiškinti, kodėl kai kurie dalykai veikia geriau nei kiti, o tada kurdami papildomus prototipus ar programas naujoms idėjoms išbandyti. Duomenų rinkimas ir įrašymas į nešiojamąjį kompiuterį yra svarbi kūrimo ir programavimo dalis.
Išbandykite Sprendimą
Atlikdami šį veiksmą, mokiniai išbandys, ką sukūrė ar užprogramavo, kad pamatytų, kas veikia, kas ne ir ką galima patobulinti. Testavimo procedūros turi būti gerai dokumentuotos bloknote ir turėtų apimti visus išmatuojamus rezultatus. Pagrindinis šio veiksmo tikslas yra nuspręsti, ar versija ar kodas atitinka iššūkį ir veikia taip, kaip tikimasi ir reikia.
Pakartokite projektavimo procesą
Kas atsitinka, kai testuojant kažkas neveikia? Studentai analizuoja problemą, kad nustatytų naują jos keliamą iššūkį, ir pradeda naują projektavimo proceso ciklą!
Ne visiems projektavimo proceso ciklams reikės visų veiksmų, o kai kurie gali pereiti nuo žingsnio prie žingsnio arba pakartoti žingsnį kelis kartus, prieš pereinant prie kito. Dizainerių komandos neturėtų bijoti grįžti atgal projektavimo procese. Galutinis tikslas – sukurti geriausią įmanomą dizainą, nuolat jį tobulinant. Projektavimo ciklai tikriausiai taip pat sutaps, ypač tarp robotų posistemių ir kodo. Darydami įrašus bloknote komandos turėtų padaryti viską, ką gali, kad nustatytų, kuriame (-iuose) projektavimo proceso etape (-iuose) jos dirba.
Taigi, kaip komanda nusprendžia, kada jų robotas bus baigtas? Paprasta: komanda turi sudaryti tvarkaraštį ir jo laikytis. Šis tvarkaraštis labai skirsis kiekvienoje komandoje, priklausomai nuo jų aplinkybių. Jei komanda turi šešias savaites suprojektuoti ir sukurti savo robotą iki pirmųjų varžybų, ji turėtų sudaryti tam tikrą tvarkaraštį šiam laikotarpiui. Kai kurios komandos suplanuos kiekvieną kūrimo proceso žingsnį, o kitos tiesiog atliks greitą apžvalgą.
Grafikas ne visada iškaltas akmenyje; galiausiai vienintelės nustatytos datos yra projekto pradžios data ir roboto užbaigimo terminas (dažniausiai konkurso data). Visa kita greičiausiai pasikeis vykstant procesui.