Der technische Entwurfsprozess besteht aus einer Reihe von Schritten, die Ingenieure befolgen, wenn sie versuchen, ein Problem zu lösen und eine Lösung für etwas zu entwerfen. Es handelt sich um einen methodischen Ansatz zur Problemlösung. Es gibt keinen einheitlichen, allgemein akzeptierten Entwurfsprozess, und die meisten Ingenieure haben ihre eigene Vorstellung davon, wie der Prozess funktioniert. Der Prozess beginnt im Allgemeinen mit einem Problem und endet mit einer Lösung, die mittleren Schritte können jedoch variieren.
Ein gemeinsames Merkmal der meisten Designprozesse ist, dass sie iterativ sind und Designer möglicherweise zu vorherigen Schritten im Prozess zurückkehren und/oder den gesamten Prozess immer wieder wiederholen müssen, bis sie zu einer minimal realisierbaren Lösung gelangen.
Der in diesem Artikel beschriebene Konstruktionsprozess ist nicht die einzig korrekte Version des Prozesses, sondern nur ein Beispiel. Es soll den Studierenden einen guten Ausgangspunkt für die Erkundung des Ingenieurprozesses bieten.
Ein sehr einfacher Designprozess umfasst möglicherweise nur drei Schritte, wie unten gezeigt: Definieren, Lösungen entwickeln und optimieren (diese Illustration ist als Poster in Originalgröße unter posters.vex.com verfügbar, wenn Sie eines für Ihr Klassenzimmer wünschen!).
Ein weiteres Beispiel für einen Designprozess ist Project Lead The Way's Gateway Design Process.
Schritte des technischen Designprozesses
In diesem Artikel betrachten wir einen Designprozess, der den Anforderungen von Juroren entspricht, wenn sie Teams befragen und ihre technischen Notizbücher bei REC Foundation-Wettbewerben überprüfen.
Identifizieren Sie die Herausforderung & Setzen Sie sich Ziele
Dies wird manchmal als „Fragen“ oder „Definieren“ bezeichnet. Die Identifizierung der Herausforderung sollte immer der erste Schritt im Designprozess sein.
Für die erste Iteration des Designprozesses sollte das Notizbuch des Teams eine sehr kurze Beschreibung der gesamten Spielherausforderung enthalten und diese in kleinere Herausforderungen aufteilen, die für den Erfolg bewältigt werden müssen. Best Practice besteht darin, Fragen aufzulisten, die durch Recherche oder Tests beantwortet werden müssen, zum Beispiel:
- Was ist die effektivste Strategie, um das Spiel zu spielen?
- Welche Möglichkeiten gibt es, Punkte zu sammeln?
- Wie schnell muss sich der Roboter bewegen?
- Wie kann der Roboter die Punkteobjekte aufnehmen?
- Wie viele Punkteobjekte muss der Roboter halten?
Durch diesen Prozess sollten die Teams eine Liste der Funktionen erstellen, die sie sich für ihren Roboter wünschen könnten, sowie eine Liste der Anforderungen und Einschränkungen des Spiels. Wenn beispielsweise eine Herausforderung erfordert, dass ein Roboter Objekte so hoch wie möglich stapelt, könnte das Team entscheiden, dass der Roboter groß sein soll. Allerdings gibt es im Spielhandbuch möglicherweise eine Einschränkung, wie groß der Roboter zu einem bestimmten Zeitpunkt sein darf. Alle diese Kriterien sollten untersucht und verstanden werden, bevor mit der Brainstorming-Phase begonnen wird.
Für spätere Zyklen des Designprozesses könnte dieser Schritt darin bestehen, etwas am Roboter zu identifizieren, das nicht so gut funktioniert wie erwartet oder benötigt, und zu beschreiben, was eine gute Lösung beinhalten würde. Eine Herausforderung könnte beispielsweise lauten: „Der Roboterarm muss in der Lage sein, höher zu greifen, um den Ball zu erzielen“, und ein Ziel zur Bewältigung der Herausforderung könnte lauten: „Die Unterseite der Klaue muss in der Lage sein, bis zu 16 zu erreichen.“ „wenn man einen Ball hält.“ Einschränkungen für diese Herausforderung können sich mit größeren Einschränkungen aus dem Spiel überschneiden, z. B. Größen- und vertikale Erweiterungsbeschränkungen.
Brainstorming & Diagramm
Gutes Brainstorming beginnt mit einem gemeinsamen Verständnis des Problems, einschließlich aller Anforderungen und Einschränkungen. Ohne das Problem zu verstehen, wird möglicherweise Zeit mit irrelevanten Ideen verschwendet, die das vorliegende Grundproblem nicht lösen. Beim Brainstorming ist es außerdem wichtig, dass man die Ideen des anderenbeurteilt. Dies kann den kreativen Prozess behindern und Teammitglieder von der Teilnahme abhalten.
Wenn sich herausstellt, dass die Teammitglieder das Problem nicht vollständig verstehen, sollte das Team mit dem ersten Schritt des Prozesses (z. B. „Identifizieren Sie das Problem“ oder „Fragen“) von vorne beginnen.
Während des Brainstormings möchten die Schüler möglicherweise auch Herausforderungen aus der realen Welt untersuchen, die denen des Spiels ähneln. Sie können auch prüfen, ob andere Robotik-Wettbewerbe in der Vergangenheit ähnliche Herausforderungen genutzt haben. Brainstorming umfasst das Sammeln von Daten aus anderen Quellen, um den Schülern bei der Entwicklung einer erfolgreichen Lösung zu helfen.
Erfolgsversprechende Lösungen sollten im Notizbuch des Teams dokumentiert werden, inklusive beschrifteter Zeichnungen oder Bilder. Wenn das Team Ideen aus anderen Quellen erhält, sollten diese Quellen im Notizbuch deutlich gekennzeichnet werden.
Wählen Sie eine Lösung & Machen Sie einen Plan
Sobald das Brainstorming abgeschlossen ist und mehrere Ideen generiert wurden, sollten die Teams jede Idee objektiv bewerten. Ziel ist es, unabhängig von der Quelle die beste Lösung für das Team zu finden. Eine Tabelle könnte Teams dabei helfen, die Vorzüge jeder Idee im Verhältnis zu spezifischen Designwünschen und -beschränkungen zu prüfen und zu vergleichen. Im folgenden Beispiel wird jedes Kriterium auf einer Punkteskala von 0 bis 5 bewertet, wobei 0 die Erwartungen nicht erfüllt und 5 die Erwartungen übertrifft. Da „Idee 4“ die höchste Gesamtpunktzahl hat, wäre sie die objektive Wahl.
Idee |
Kriterium 1 |
Kriterium 2 |
Kriterium 3 |
Kriterium 4 |
Gesamtpunktzahl |
Idee 1 |
3 |
3 |
2 |
1 |
9 |
Idee 2 |
5 |
5 |
0 |
0 |
10 |
Idee 3 |
1 |
1 |
5 |
5 |
12 |
Idee 4 |
4 |
4 |
4 |
4 |
16 |
Das Team sollte diesen Prozess im Notizbuch dokumentieren und erklären, wie und warum es seine Lösung wählt. Außerdem sollten sie die Lösung in ihrem technischen Notizbuch vollständig beschreiben, einschließlich eines Plans, wie sie sie bauen werden. Für fortgeschrittene Teams kann dieser Plan die Erstellung von CAD-Modellen oder detaillierten Montagezeichnungen umfassen.
Build & Programm
Hier verbringen die Teams die meiste Zeit und hier werden Prototypen sowie endgültige Roboter und Programme erstellt. Builds – sowohl für Code als auch für Roboter – beginnen im Allgemeinen als grundlegende Designs und entwickeln sich weiter, wenn in späteren Zyklen des Designprozesses Details hinzugefügt werden. Die Schüler sollten sich beim Erstellen von & Programmen detaillierte Notizen in ihrem Notizbuch machen, aufzeichnen, was sie sehen, versuchen herauszufinden, warum einige Dinge besser funktionieren als andere, und dann zusätzliche Prototypen oder Programme erstellen, um neue Ideen zu testen. Das Sammeln von Daten und deren Aufzeichnung im Notizbuch ist ein wichtiger Teil des Bauens und Programmierens.
Testen Sie die Lösung
In diesem Schritt testen die Schüler, was sie gebaut oder programmiert haben, um zu sehen, was funktioniert, was nicht und was verbessert werden kann. Testverfahren sollten im Notizbuch gut dokumentiert sein und alle messbaren Ergebnisse enthalten. Das Hauptziel dieses Schritts besteht darin, zu entscheiden, ob der Build oder Code die Herausforderung erfüllt und die erwartete und benötigte Leistung erbringt.
Wiederholen Sie den Designprozess
Was passiert, wenn beim Testen etwas nicht funktioniert? Die Schüler analysieren das Problem, um die neue Herausforderung zu erkennen, die es darstellt, und beginnen einen neuen Zyklus des Designprozesses!
Nicht alle Designprozesszyklen erfordern alle Schritte, und einige springen möglicherweise von Schritt zu Schritt oder wiederholen einen Schritt mehrmals, bevor sie mit dem nächsten fortfahren. Designteams sollten keine Angst davor haben, im Designprozess Rückschritte zu machen. Das ultimative Ziel besteht darin, das bestmögliche Design zu schaffen, indem man es immer wieder verbessert. Auch die Entwurfszyklen werden sich wahrscheinlich überschneiden, insbesondere zwischen Roboter-Subsystemen und Code. Teams sollten ihr Bestes tun, um zu erkennen, an welchen Entwurfsprozessschritten sie arbeiten, während sie Einträge in das Notizbuch vornehmen.
Wie entscheidet ein Team, wann sein Roboter fertig ist? Ganz einfach: Das Team muss einen Zeitplan festlegen und sich dann daran halten. Dieser Zeitplan variiert stark von Team zu Team, abhängig von den jeweiligen Umständen. Wenn ein Team vor dem ersten Wettbewerb sechs Wochen Zeit hat, seinen Roboter zu entwerfen und zu bauen, sollte es sich für diesen Zeitraum einen Zeitplan ausdenken. Einige Teams planen jeden einzelnen Schritt in ihrem Build-Prozess, während andere nur einen kurzen Überblick geben.
Der Zeitplan ist nicht immer in Stein gemeißelt; Letztlich sind die einzigen festen Termine das Projektstartdatum und die Roboterfertigstellungsfrist (normalerweise das Datum eines Wettbewerbs). Alles andere wird sich im Verlauf des Prozesses wahrscheinlich ändern.