Процес інженерного проектування — це серія кроків, яких дотримуються інженери, коли вони намагаються вирішити проблему та розробити рішення для чогось; це методичний підхід до вирішення проблеми. Немає єдиного загальноприйнятого процесу проектування, і більшість інженерів мають свій власний спосіб роботи цього процесу. Зазвичай процес починається з проблеми і закінчується вирішенням, але середні кроки можуть відрізнятися.

Одна загальна характеристика більшості процесів проектування полягає в тому, що вони повторюються, і дизайнерам, можливо, доведеться повертатися до попередніх етапів процесу та/або повторювати весь процес знову і знову, доки не досягнуть мінімально життєздатного рішення.

Процес інженерного проектування, описаний у цій статті, не є єдиною правильною версією процесу, це лише один приклад. Це повинно стати хорошою відправною точкою для студентів, щоб досліджувати інженерний процес.

Дуже простий процес проектування може включати лише 3 кроки, як показано нижче: визначення, розробка рішень та оптимізація (ця ілюстрація доступна як повнорозмірний постер на posters.vex.com , якщо ви бажаєте його для свого класу!).

Basic_design_process.png

Іншим прикладом процесу проектування є Project Lead The Way's Gateway Design Process.

Етапи процесу інженерного проектування

У цій статті ми розглянемо процес проектування, який відповідає тому, що шукають судді під час співбесіди з командами та перегляду їхніх інженерних записників на змаганнях REC Foundation.

Визначте виклик & Ставте цілі

Це іноді називають «Запитати» або «Визначити». Першим кроком у процесі проектування завжди має бути визначення проблеми. 

Для першої ітерації процесу проектування блокнот команди повинен містити дуже короткий опис загального завдання гри та розбити його на менші завдання, які необхідно виконати для успіху. Найкраща практика полягає в тому, щоб перерахувати запитання, на які потрібно отримати відповідь шляхом дослідження або тестування, наприклад:

  • Яка стратегія найефективніша для гри?
  • Які існують способи набору очок?
  • З якою швидкістю повинен рухатися робот?
  • Як робот може підібрати залікові предмети?
  • Скільки залікових предметів повинен утримати робот?

За допомогою цього процесу команди повинні скласти список функцій, які вони можуть забажати у своєму роботі, а також списки вимог і обмежень гри. Наприклад, якщо завдання вимагає від робота складати об’єкти якомога вище, команда може вирішити, що хоче, щоб їхній робот був високим. Однак інструкція з гри може мати обмеження щодо висоти робота в будь-який момент часу. Усі ці критерії слід вивчити та зрозуміти перед тим, як переходити до фази мозкового штурму.

Для пізніших циклів процесу проектування цей крок може полягати в тому, щоб визначити щось на роботі, що працює не так добре, як очікувалося чи потрібно, і описати, що міститиме гарне рішення. Наприклад, завдання може полягати в тому, що «Рука робота має мати можливість дотягнутися вище, щоб забити м’яч», а мета для виконання завдання може бути такою: «Нижня частина кігтя має мати можливість дотягнутися до 16 «коли тримає м’яч». Обмеження для цього завдання можуть перекривати більші обмеження гри, наприклад обмеження розміру та вертикального розширення.

Діаграма мозкового штурму &

Хороший мозковий штурм починається зі спільного розуміння проблеми, включаючи всі вимоги та обмеження. Без розуміння проблеми можна витратити час на нерелевантні ідеї, які не задовольняють основну проблему. Під час мозкового штурму також важливооцінювання ідейодного. Це може загальмувати творчий процес і перешкодити членам команди брати участь.

Якщо стає зрозуміло, що члени команди не повністю розуміють проблему, команда повинна почати спочатку з першого кроку процесу (тобто «Визначити проблему» або «Запитати»).

Під час мозкового штурму учні також можуть захотіти дослідити виклики з реального світу, які схожі на ті, які створює гра. Вони також можуть перевірити, чи використовувалися подібні завдання в інших змаганнях з робототехніки в минулому. Мозковий штурм включає збір даних з інших джерел, щоб допомогти студентам створити успішне рішення.

Перспективні рішення повинні бути задокументовані в записній книжці команди, включаючи малюнки або малюнки з написами. Якщо команда отримує ідеї з інших джерел, ці джерела мають бути чітко визначені в блокноті.

Виберіть рішення & Складіть план

Після завершення мозкового штурму та створення кількох ідей команди повинні об’єктивно оцінити кожну ідею. Мета — знайти найкраще рішення для команди, незалежно від джерела. Таблиця може допомогти командам розглянути та порівняти переваги кожної ідеї щодо конкретних проектних бажань і обмежень. У наведеному нижче прикладі кожен критерій оцінюється за шкалою від 0 до 5, де 0 не відповідає очікуванням, а 5 перевищує. Оскільки «Ідея 4» має найвищий загальний бал, це буде об’єктивний вибір.

Ідея

Критерій 1

Критерій 2

Критерій 3

Критерій 4

Загальний рахунок

Ідея 1

3

3

2

1

9

Ідея 2

5

5

0

0

10

Ідея 3

1

1

5

5

12

Ідея 4

4

4

4

4

16

Команда повинна задокументувати цей процес у зошиті та пояснити, як і чому вони обирають своє рішення. Вони також повинні повністю описати рішення у своєму інженерному зошиті, включаючи план того, як вони його побудують. Для досвідчених команд цей план може включати створення моделей САПР або детальних складальних креслень.

Програма Build &

Саме тут команди проводитимуть більшу частину свого часу, а також створювати прототипи та остаточні роботи та програми. Збірки — як для коду, так і для роботів — зазвичай починаються з базових проектів і розвиваються в міру додавання деталей у наступних циклах процесу проектування. Студенти повинні робити детальні нотатки у своєму зошиті під час створення & , записуючи те, що вони бачать, намагаючись з’ясувати, чому деякі речі працюють краще, ніж інші, а потім створюючи додаткові прототипи або програми для перевірки нових ідей. Збір даних і запис їх у блокнот є важливою частиною побудови та програмування.

Перевірте рішення

Під час цього кроку учні перевірять те, що вони створили або запрограмували, щоб побачити, що працює, а що ні, а що можна покращити. Процедури тестування мають бути добре задокументовані в зошиті та включати всі вимірювані результати. Основна мета цього кроку — вирішити, чи збірка чи код відповідає вимогам і працює належним чином.

Повторіть процес проектування

Що відбувається, коли щось не працює під час тестування? Студенти аналізують проблему, щоб визначити новий виклик, який вона представляє, і починають новий цикл процесу проектування!

Не всі цикли процесу проектування потребуватимуть усіх кроків, і деякі можуть переходити від кроку до кроку або повторювати крок кілька разів, перш ніж перейти до наступного. Команди дизайнерів не повинні боятися повернутися назад у процесі проектування. Кінцева мета — створити найкращий можливий дизайн, вдосконалюючи його знову і знову. Цикли проектування, ймовірно, також будуть збігатися, особливо між підсистемами роботів і кодом. Команди повинні зробити все можливе, щоб визначити, на якому етапі процесу проектування вони працюють, коли вони роблять записи в блокноті.

Отже, як команда вирішує, коли їхній робот готовий?  Просто: команда повинна скласти графік, а потім його дотримуватися. Цей графік значно відрізнятиметься від команди до команди залежно від їхніх обставин. Якщо у команди є шість тижнів, щоб спроектувати та створити свого робота до першого змагання, вони повинні скласти якийсь графік на цей період часу. Деякі команди плануватимуть кожен крок у процесі створення, тоді як інші просто зроблять короткий огляд.

Розклад не завжди встановлено в камені; зрештою єдиними фіксованими датами є дата початку проекту та кінцевий термін завершення робота (зазвичай дата конкурсу). Все інше, ймовірно, зміниться в міру розвитку процесу.