Proces projektowania inżynierskiego to seria kroków, które wykonują inżynierowie, próbując rozwiązać problem i zaprojektować rozwiązanie dla czegoś; jest to metodyczne podejście do rozwiązywania problemów. Nie ma jednego, powszechnie akceptowanego procesu projektowania, a większość inżynierów ma swoje własne podejście do sposobu działania tego procesu. Proces zazwyczaj zaczyna się od problemu i kończy rozwiązaniem, ale etapy pośrednie mogą się różnić.
Wspólną cechą większości procesów projektowania jest to, że są one iteracyjne i projektanci mogą być zmuszeni wracać do poprzednich etapów procesu i/lub powtarzać cały proces w kółko, aż do osiągnięcia minimalnie wykonalnego rozwiązania.
Proces projektowania inżynierskiego opisany w tym artykule nie jest jedyną poprawną wersją procesu, to tylko jeden przykład. Powinien stanowić dobry punkt wyjścia dla studentów do poznania procesu inżynieryjnego.
Bardzo prosty proces projektowania może obejmować tylko 3 kroki, jak pokazano poniżej: Zdefiniuj, opracuj rozwiązania i optymalizuj (ta ilustracja jest dostępna w postaci pełnowymiarowego plakatu na stronie posters.vex.com , jeśli chcesz mieć ją w swojej klasie!).
Innym przykładem procesu projektowania jest Kierownik projektu Proces projektowania bramy Way's Gateway.
Etapy procesu projektowania inżynierskiego
Na potrzeby tego artykułu rozważymy proces projektowania zgodny z oczekiwaniami sędziów podczas przeprowadzania wywiadów z zespołami i przeglądania ich notatek inżynierskich podczas konkursów Fundacji REC.
Zidentyfikuj wyzwanie. & Wyznacz cele
Nazywa się to czasem „Zapytaj” lub „Określ”. Identyfikacja wyzwania powinna zawsze być pierwszym krokiem w procesie projektowania.
W przypadku pierwszej iteracji procesu projektowania notatnik zespołu powinien zawierać bardzo krótki opis ogólnego wyzwania w grze i podzielić go na mniejsze wyzwania, które należy wykonać, aby odnieść sukces. Najlepszą praktyką jest sporządzenie listy pytań, na które należy odpowiedzieć w drodze badań lub testów, na przykład:
- Jaka jest najskuteczniejsza strategia gry?
- Jakie są sposoby na zdobywanie punktów?
- Jak szybko robot musi się poruszać?
- W jaki sposób robot może podnosić punktowane obiekty?
- Ile ocenianych obiektów musi utrzymać robot?
W ramach tego procesu zespoły powinny sporządzić listę funkcji, których mogą chcieć w swoim robocie, oraz listę wymagań i ograniczeń gry. Na przykład, jeśli wyzwanie wymaga od robota ułożenia obiektów jak najwyżej, zespół może zdecydować, że chce, aby robot był wysoki. Jednakże instrukcja gry może zawierać ograniczenia dotyczące wysokości robota w danym momencie. Wszystkie te kryteria należy zbadać i zrozumieć przed przejściem do fazy burzy mózgów.
W późniejszych cyklach procesu projektowania ten krok może obejmować identyfikację elementu w robocie, który nie działa tak dobrze, jak oczekiwano lub jest potrzebny, oraz opisanie, co obejmowałoby dobre rozwiązanie. Na przykład wyzwanie może brzmieć: „Ramię robota musi być w stanie sięgnąć wyżej, aby zdobyć piłkę”, a celem umożliwiającym wykonanie wyzwania może być: „Dół pazura musi być w stanie sięgnąć do 16 „kiedy trzymasz piłkę”. Ograniczenia tego wyzwania mogą nakładać się na większe ograniczenia gry, na przykład ograniczenia rozmiaru i ekspansji pionowej.
Schemat burzy mózgów &
Dobra burza mózgów zaczyna się od wspólnego zrozumienia problemu, łącznie ze wszystkimi wymaganiami i ograniczeniami. Bez zrozumienia problemu można marnować czas na nieistotne pomysły, które nie rozwiązują podstawowego problemu. Podczas burzy mózgów ważne jest równieżaby unikaćoceniania pomysłów. Może to stłumić proces twórczy i zniechęcić członków zespołu do udziału.
Jeśli stanie się jasne, że członkowie zespołu nie w pełni rozumieją problem, zespół powinien zacząć od pierwszego etapu procesu (tj. „Zidentyfikuj problem” lub „Zapytaj”).
Podczas burzy mózgów uczniowie mogą również chcieć zbadać wyzwania z prawdziwego świata, podobne do tych stawianych przez grę. Mogą także sprawdzić, czy w przeszłości jakiekolwiek inne zawody robotyki wykorzystywały podobne wyzwania. Burza mózgów obejmuje gromadzenie danych z innych źródeł, aby pomóc uczniom w stworzeniu skutecznego rozwiązania.
Obiecujące rozwiązania należy udokumentować w notatniku zespołu, włączając w to oznaczone rysunki lub zdjęcia. Jeśli zespół czerpie pomysły z innych źródeł, należy je wyraźnie wskazać w notatniku.
Wybierz rozwiązanie & Zrób plan
Po zakończeniu burzy mózgów i wygenerowaniu kilku pomysłów zespoły powinny obiektywnie ocenić każdy pomysł. Celem jest znalezienie najlepszego rozwiązania dla zespołu, niezależnie od źródła. Tabela może pomóc zespołom rozważyć i porównać zalety każdego pomysłu w odniesieniu do konkretnych potrzeb i ograniczeń projektowych. W poniższym przykładzie każde kryterium jest oceniane w skali od 0 do 5 punktów, gdzie 0 nie spełnia, a 5 przekracza oczekiwania. Ponieważ „Pomysł 4” uzyskał najwyższą ogólną liczbę punktów, byłby to wybór obiektywny.
|
Pomysł |
Kryteria 1 |
Kryteria 2 |
Kryteria 3 |
Kryteria 4 |
Całkowity wynik |
|
Pomysł 1 |
3 |
3 |
2 |
1 |
9 |
|
Pomysł 2 |
5 |
5 |
0 |
0 |
10 |
|
Pomysł 3 |
1 |
1 |
5 |
5 |
12 |
|
Pomysł 4 |
4 |
4 |
4 |
4 |
16 |
Zespół powinien udokumentować ten proces w notatniku i wyjaśnić, w jaki sposób i dlaczego wybrał swoje rozwiązanie. Powinni także szczegółowo opisać rozwiązanie w swoim notatniku inżynierskim, łącznie z planem jego zbudowania. W przypadku zaawansowanych zespołów plan ten może obejmować tworzenie modeli CAD lub szczegółowych rysunków montażowych.
Zbuduj program &
To tutaj zespoły będą spędzać większość czasu i powstają prototypy oraz finalne roboty i programy. Kompilacje — zarówno kodu, jak i robotów — zazwyczaj rozpoczynają się od podstawowych projektów i ewoluują w miarę dodawania szczegółów w późniejszych cyklach procesu projektowania. Podczas tworzenia programowania w & uczniowie powinni robić szczegółowe notatki w swoim notatniku, zapisywać to, co widzą, próbować zrozumieć, dlaczego niektóre rzeczy działają lepiej niż inne, a następnie tworzyć dodatkowe prototypy lub programy w celu testowania nowych pomysłów. Gromadzenie danych i zapisywanie ich w notatniku jest ważną częścią budowania i programowania.
Przetestuj rozwiązanie
Na tym etapie uczniowie przetestują to, co zbudowali lub zaprogramowali, aby zobaczyć, co działa, a co nie, a co można ulepszyć. Procedury testowania powinny być dobrze udokumentowane w notatniku i powinny obejmować wszystkie mierzalne wyniki. Głównym celem tego kroku jest podjęcie decyzji, czy kompilacja lub kod spełnia wyzwanie i działa zgodnie z oczekiwaniami i potrzebami.
Powtórz proces projektowania
Co się stanie, jeśli coś nie wyjdzie podczas testów? Studenci analizują problem, aby zidentyfikować nowe wyzwanie, jakie stanowi, i rozpoczynają nowy cykl procesu projektowania!
Nie wszystkie cykle procesu projektowania będą wymagały wszystkich etapów, a niektóre mogą przeskakiwać z kroku na krok lub powtarzać krok wielokrotnie przed przejściem do następnego. Zespoły projektowe nie powinny bać się cofania się w procesie projektowania. Ostatecznym celem jest stworzenie możliwie najlepszego projektu poprzez ciągłe jego ulepszanie. Cykle projektowe prawdopodobnie również będą się na siebie nakładać, szczególnie pomiędzy podsystemami robotów a kodem. Podczas dokonywania wpisów w notatniku zespoły powinny dołożyć wszelkich starań, aby zidentyfikować etapy procesu projektowania, nad którymi pracują.
W jaki więc sposób zespół decyduje, kiedy robot jest gotowy? Proste: zespół musi ustalić harmonogram, a następnie się go trzymać. Harmonogram ten będzie się znacznie różnić w zależności od zespołu, w zależności od ich sytuacji. Jeśli zespół ma sześć tygodni na zaprojektowanie i zbudowanie robota przed pierwszymi zawodami, powinien opracować jakiś harmonogram na ten okres. Niektóre zespoły zaplanują każdy etap procesu kompilacji, inne natomiast dokonają jedynie krótkiego przeglądu.
Harmonogram nie zawsze jest ustalony; ostatecznie jedynymi ustalonymi datami są data rozpoczęcia projektu i termin ukończenia robota (zwykle data konkursu). Wszystko inne prawdopodobnie ulegnie zmianie w miarę rozwoju procesu.