NWT9 - Fehler als Teil des Entwicklungsprozesses nutzen
NWT9 - Fehler als Teil des Entwicklungsprozesses nutzen
NWT9 - Fehler als Teil des Entwicklungsprozesses nutzen
Einleitung
Ein Fehler ist in einem technischen Entwicklungsprozess nicht nur ein unerwünschtes Ergebnis. Wenn Du ihn genau beobachtest, messbar beschreibst und systematisch untersuchst, liefert er Informationen darüber, wie ein Produkt, ein Experiment, eine Schaltung oder ein Programm verbessert werden kann. In diesem aiMOOC trainierst Du deshalb einen zentralen Arbeitszyklus aus NWT:
Fehlerbild beobachten → Ursachenhypothesen bilden → eine gezielte Veränderung vornehmen → erneut testen → Ergebnisse dokumentieren und optimieren.
Dieser Zyklus wird auch als iteratives Vorgehen bezeichnet. Eine Entwicklung wird dabei nicht in einem einzigen Schritt „fertig“, sondern durch mehrere begründete Test- und Verbesserungsrunden immer besser an vorher festgelegte Anforderungen angepasst.
Das Foto oben zeigt einen fehlgeschlagenen 3D-Druck. Ein solches Ergebnis ist zunächst nur ein Fehlerbild. Erst eine Untersuchung klärt mögliche Ursachen. Beim abgebildeten Beispiel wird auf Wikimedia Commons eine unzureichende Haftung auf der Druckplatte als Ursache genannt. Für die technische Arbeit ist entscheidend: Du sollst nicht sofort möglichst viele Einstellungen gleichzeitig ändern, sondern eine plausible Ursache auswählen, eine Variable gezielt verändern und anschließend unter vergleichbaren Bedingungen erneut testen.
Das NASA-Video zeigt einen technischen Entwicklungsprozess als Abfolge von Problemklärung, Ideen, Konstruktion, Test und Verbesserung. Übertrage beim Ansehen die Schritte auf ein eigenes NWT-Projekt: Wo wird ein Fehler sichtbar? Welche Daten könnten helfen? Welche Veränderung wäre ein fairer nächster Test?
Lernziele
Nach diesem aiMOOC kannst Du Fehler nicht nur benennen, sondern als Datenquelle für Entwicklung nutzen. Du kannst ein gewünschtes Soll-Verhalten formulieren, ein beobachtetes Ist-Verhalten davon unterscheiden, Messdaten erfassen, mögliche Ursachen als Hypothesen formulieren, eine Veränderung begründet auswählen, einen erneuten Test planen und das Ergebnis nachvollziehbar dokumentieren.
Du lernst außerdem, zwischen einem Defekt, einer ungeeigneten Konstruktion, einem Bedienfehler, einer Messabweichung, einer fehlerhaften Annahme und einem Programmfehler zu unterscheiden. Diese Unterscheidung ist wichtig, weil unterschiedliche Ursachen unterschiedliche Verbesserungsmaßnahmen verlangen.
G-M-E-Differenzierung
| Niveau | Was Du bei der Fehleranalyse leisten sollst | Typische Dokumentation |
|---|---|---|
| G – grundlegendes Niveau | Du beschreibst das Fehlerbild, nennst eine plausible Ursache, veränderst genau einen gut begründeten Faktor und vergleichst Vorher und Nachher. | Foto oder Skizze, kurze Messwerttabelle, eine Hypothese, eine Veränderung, ein Ergebnis. |
| M – mittleres Niveau | Du formulierst mehrere Ursachenhypothesen, priorisierst sie, planst vergleichbare Tests und wertest eine Messreihe aus. | Kriterien, Messreihe, Hypothesenrangfolge, begründete Variablenwahl, Vergleich mehrerer Iterationen. |
| E – erweitertes Niveau | Du unterscheidest konkurrierende Ursachen, berücksichtigst Messunsicherheit und Störgrößen, planst Kontrolltests und bewertest Zielkonflikte. | Versuchsplan, Kontrollvariable, Unsicherheitsbetrachtung, begründete Entscheidung, Optimierung unter mehreren Kriterien. |
Die Niveaus sind keine getrennten Themen. Alle bearbeiten denselben Entwicklungszyklus, aber mit unterschiedlicher Tiefe der Begründung, Datenauswertung und Kontrolle von Einflussgrößen.
Fehler als technische Information
Ein technisches System erfüllt Anforderungen nicht automatisch. Ein Fahrzeug kann zu langsam sein, eine Brücke kann sich zu stark durchbiegen, ein Sensor kann unplausible Werte liefern, ein 3D-Druck kann sich vom Druckbett lösen oder ein Programm kann eine falsche Ausgabe erzeugen. Entscheidend ist, den Fehler beobachtbar zu formulieren.
Ungünstig wäre: „Der Prototyp funktioniert nicht.“
Besser wäre: „Der Wagen soll auf zwei Metern geradeaus fahren. Beim Test weicht er nach 1,5 Metern etwa 25 Zentimeter nach links ab.“
Die zweite Formulierung enthält bereits ein Kriterium, eine Beobachtung und eine messbare Abweichung. Dadurch kann die Suche nach Ursachen beginnen.
Ein Prototyp ist ein Versuchsmodell, mit dem Funktionen, Maße, Bedienbarkeit oder technische Konzepte überprüft werden können. Ein Prototyp muss deshalb noch nicht perfekt sein. Sein Wert liegt gerade darin, dass er Risiken und Schwächen sichtbar macht, bevor ein endgültiges Produkt entsteht.
Soll, Ist und Abweichung
Für eine gute Fehleranalyse brauchst Du drei Fragen:
- Soll: Was sollte nach den Anforderungen passieren?
- Ist: Was ist tatsächlich beobachtet oder gemessen worden?
- Abweichung: Wie unterscheiden sich Soll und Ist?
Beispiel: Eine selbst gebaute Halterung soll eine Masse von 500 g mindestens 30 Sekunden tragen. Im Test verformt sie sich nach 12 Sekunden dauerhaft. Die Aussage „zu schwach“ ist noch keine Ursache. Sie beschreibt nur das Ergebnis. Mögliche Ursachen könnten Materialstärke, Geometrie, Verbindung, Lastverteilung oder Fertigungsfehler sein.
Fehlerbild und Ursache nicht verwechseln
Ein Fehlerbild ist das, was Du wahrnimmst: etwa ein Riss, eine falsche Richtung, ein flackerndes Signal oder eine unplausible Zahl. Eine Ursache ist eine Erklärung dafür, warum dieses Fehlerbild entsteht.
Mehrere Ursachen können dasselbe Fehlerbild erzeugen. Wenn eine LED nicht leuchtet, könnten unter anderem eine falsche Polung, eine unterbrochene Verbindung, eine ungeeignete Spannungsversorgung, ein Programmfehler oder ein defektes Bauteil verantwortlich sein.
Deshalb gilt: Eine Vermutung wird erst dann zu einer belastbaren Erklärung, wenn sie durch Tests gestützt wird.
Der Optimierungszyklus
Ein bewährtes Vorgehen besteht aus fünf wiederholbaren Phasen:
- Fehler analysieren: Beschreibe das beobachtete Problem möglichst konkret und sichere Messwerte, Fotos, Skizzen oder Fehlermeldungen.
- Ursachenhypothesen bilden: Formuliere mehrere mögliche Erklärungen und begründe, warum sie zum Fehlerbild passen könnten.
- Gezielt verändern: Wähle nach Möglichkeit nur eine Einflussgröße für den nächsten Test.
- Erneut testen: Nutze dieselben Erfolgskriterien und möglichst vergleichbare Bedingungen.
- Optimierung dokumentieren: Halte fest, was verändert wurde, welche Daten entstanden und was daraus für die nächste Iteration folgt.
Beim Ansehen kannst Du auf die Reihenfolge achten: Problem verstehen, Lösungsideen entwickeln, bauen, testen und verbessern. Für Klasse 9 ist besonders wichtig, nicht nur „noch einmal“ zu bauen, sondern begründen zu können, warum die nächste Version anders ist.
Warum nur eine gezielte Veränderung?
Wenn Du gleichzeitig Material, Form, Länge, Spannung und Programmcode änderst und das Ergebnis danach besser ist, weißt Du nicht, welche Veränderung tatsächlich geholfen hat. Ein kontrollierter Test versucht deshalb, möglichst viele Bedingungen gleich zu halten und nur die untersuchte Einflussgröße zu verändern.
G: Verändere einen Faktor und vergleiche vorher/nachher.
M: Begründe, warum gerade dieser Faktor wahrscheinlich wichtig ist.
E: Plane zusätzlich eine Kontrollbedingung oder Wiederholungsmessung und beschreibe mögliche Störgrößen.
Ursachenhypothesen entwickeln
Eine gute Ursachenhypothese verbindet eine Beobachtung mit einem technisch oder naturwissenschaftlich begründeten Zusammenhang.
Beispiel: „Der 3D-Druck löst sich in der ersten Schicht vom Druckbett. Eine mögliche Ursache ist zu geringe Haftung. Wenn diese Hypothese stimmt, sollte eine geeignete Verbesserung der ersten Schicht die Ablösung verringern.“
Bei einem fehlgeschlagenen Druck kannst Du sichtbare Spuren als Hinweise verwenden. Verschobene Schichten, Fäden, fehlende Haftung oder verzogene Bauteile können auf unterschiedliche Ursachen hinweisen. Das Bild ist deshalb nicht bloß Illustration, sondern ein Ausgangspunkt für Diagnosefragen.
Hypothesen priorisieren
Wenn mehrere Ursachen denkbar sind, musst Du entscheiden, welche zuerst geprüft wird. Hilfreich sind folgende Kriterien: Passt die Hypothese wirklich zum Fehlerbild? Kann sie mit vorhandenen Mitteln geprüft werden? Ist sie wahrscheinlich? Ist der Test sicher? Lässt sich eine Veränderung eindeutig zuordnen?
Ein guter Entwicklungsprozess beginnt häufig mit einer einfach prüfbaren, plausiblen Ursache. Bleibt das Fehlerbild bestehen, wird die Hypothese verworfen, verändert oder nachrangig behandelt.
Fehlermessungen und Messabweichungen
Technische Optimierung braucht Messdaten. Doch auch Messungen sind nicht fehlerfrei. Fachlich wird zwischen verschiedenen Formen von Messabweichungen unterschieden.
Eine systematische Messabweichung verschiebt Ergebnisse in eine bestimmte Richtung. Ein Beispiel ist ein Messschieber, der bei vollständig geschlossenen Backen nicht 0,00 mm anzeigt. Eine zufällige Messabweichung führt dagegen zu Streuung, obwohl Du unter möglichst gleichen Bedingungen wiederholt misst.
Die Animation zeigt einen Nullfehler am Messschieber. Wenn ein Gerät bei geschlossenen Messflächen nicht den erwarteten Nullwert zeigt, kann jede folgende Messung systematisch verschoben sein. Ein einzelner „präzise aussehender“ Zahlenwert ist deshalb noch kein Beweis für eine gute Messung.
Beim Messen musst Du nicht nur das Instrument, sondern auch die Messmethode kontrollieren. Ableseposition, Anpresskraft, Messstelle und Wiederholung können Ergebnisse beeinflussen.
Messreihe statt Einzelwert
Angenommen, ein Gummiband-Katapult soll ein Projektil 200 cm weit befördern. Ein einzelner Test ergibt 203 cm. Daraus kannst Du kaum schließen, wie zuverlässig die Konstruktion ist.
Eine Messreihe von 198 cm, 205 cm, 202 cm, 197 cm und 204 cm zeigt dagegen die Streuung. Für M- und E-Niveau solltest Du zusätzlich Mittelwert, Spannweite oder eine andere geeignete Beschreibung der Streuung verwenden und überlegen, ob sich die Verbesserung gegenüber der Messstreuung tatsächlich erkennen lässt.
Das Video führt in Mittelwert und Unsicherheit bei Messreihen ein. Für die Arbeit im NWT-Unterricht reicht nicht, eine Formel zu übernehmen: Entscheidend ist die Frage, ob die Unsicherheit so groß ist, dass zwei Varianten praktisch nicht sicher voneinander unterschieden werden können.
Systematisch oder zufällig?
Systematische Abweichungen können unter anderem durch Justierung, Messaufbau oder Geometrie entstehen. Zufällige Abweichungen zeigen sich als Streuung bei Wiederholungen. In realen Versuchen können beide gleichzeitig vorkommen.
G: Wiederhole eine Messung und erkenne, dass Werte streuen können.
M: Vergleiche Streuung und Mittelwert mehrerer Varianten.
E: Prüfe zusätzlich, ob eine systematische Verschiebung oder ein ungeeigneter Messaufbau die Interpretation verfälschen könnte.
Debugging als Fehleranalyse
In der Informatik heißt die systematische Suche nach Programmfehlern Debugging. Das Grundprinzip ist dem technischen Testen sehr ähnlich: erwartetes Verhalten festlegen, tatsächliches Verhalten beobachten, mögliche Ursache eingrenzen, gezielt verändern und erneut testen.
Ein einfaches Beispiel:
temperatur = 34
wenn temperatur < 30:
luefter = EIN
sonst:
luefter = AUS
Angenommen, der Lüfter soll bei Temperaturen über 30 °C eingeschaltet werden. Bei 34 °C bleibt er in diesem Beispiel aus. Das Fehlerbild ist also klar. Eine plausible Hypothese lautet: Der Vergleichsoperator ist falsch gewählt. Der gezielte Test besteht darin, nur „<“ durch „>“ zu ersetzen und dasselbe Testszenario erneut auszuführen.
Das CS50-Video zeigt Debugging als methodische Tätigkeit. Übertrage die Idee auf Technik: Eine Fehlersuche wird effizienter, wenn Du das Problem eingrenzt, Zustände sichtbar machst und nicht wahllos mehrere Dinge gleichzeitig änderst.
Debugging-Werkzeuge
Professionelle Debugger können ein Programm an bestimmten Stellen anhalten, Variablenwerte anzeigen und Programmschritte nachvollziehbar machen. Auch ohne spezielles Werkzeug kannst Du ähnlich arbeiten: Zwischenwerte ausgeben, Teilfunktionen einzeln testen, Eingaben vereinfachen und bekannte Testfälle verwenden.
Das historische Logbuch mit einer in einem Rechner gefundenen Motte ist ein bekanntes Bild aus der Geschichte des Begriffs „Bug“. Für Deine heutige Arbeit ist die wichtigere Idee: Ein Fehler sollte belegt, lokalisiert und dokumentiert werden.
Dokumentierte Optimierung
Eine Verbesserung ist erst dann technisch überzeugend, wenn andere nachvollziehen können, was Du getan hast. Ein Entwicklungsprotokoll sollte deshalb nicht nur das Endprodukt zeigen.
| Bestandteil | Leitfrage |
|---|---|
| Anforderung | Was soll das System leisten? |
| Fehlerbild | Was passiert tatsächlich? |
| Messdaten | Welche Daten, Bilder oder Beobachtungen belegen das? |
| Ursachenhypothese | Welche Ursache vermutest Du und warum? |
| Gezielte Veränderung | Welche eine Größe veränderst Du? |
| Test | Unter welchen Bedingungen prüfst Du erneut? |
| Ergebnis | Wurde das Kriterium besser, schlechter oder unverändert erfüllt? |
| Folgerung | Welche Hypothese wird gestützt oder geschwächt? |
| Nächste Iteration | Was ist der nächste begründete Schritt? |
Beispiel einer Optimierungsfolge
Ein Fahrzeug soll zwei Meter geradeaus fahren.
Version A: Es weicht stark nach links ab. Du misst die Raddurchmesser und vermutest einen Unterschied zwischen linkem und rechtem Rad.
Version B: Du tauschst nur das auffällige Rad aus. Das Fahrzeug fährt gerader, weicht aber noch leicht ab. Die erste Hypothese wird dadurch gestützt, erklärt aber möglicherweise nicht die gesamte Abweichung.
Version C: Du prüfst nun die Achsparallelität. Eine Achse ist schräg montiert. Nach der Korrektur verbessert sich die Spur erneut.
So entsteht eine Argumentationskette aus Beobachtung, Hypothese, gezielter Änderung und neuem Test. Nicht jede Hypothese muss richtig sein. Auch eine widerlegte Hypothese bringt den Entwicklungsprozess weiter, weil sie den Suchraum verkleinert.
Reflexionskarten
Die folgenden Karten kannst Du nach jedem Testlauf nutzen. Wähle mindestens zwei Karten aus und beantworte sie schriftlich oder im Team.
| Reflexionskarte | Impuls |
|---|---|
| Beobachtung | Was sehe oder messe ich tatsächlich, ohne schon eine Ursache zu behaupten? |
| Beleg | Welche Daten stützen meine Aussage? |
| Hypothese | Welche Ursache halte ich im Moment für wahrscheinlich und warum? |
| Alternative | Welche andere Ursache könnte dasselbe Fehlerbild erklären? |
| Variable | Welche eine Größe verändere ich im nächsten Test? |
| Fairer Test | Welche Bedingungen müssen gleich bleiben? |
| Unsicherheit | Wie sicher sind meine Messwerte und Schlussfolgerungen? |
| Widerlegung | Welches Testergebnis würde gegen meine Hypothese sprechen? |
| Optimierung | Ist die neue Version wirklich besser nach dem vorher festgelegten Kriterium? |
| Dokumentation | Könnte eine andere Gruppe meinen Test anhand meines Protokolls wiederholen? |
Beispielprojekt: Vom gescheiterten Prototyp zur verbesserten Version
Baue oder untersuche einen einfachen Prototypen, zum Beispiel eine Papierbrücke, einen Gummiband-Antrieb, eine Halterung, eine sensorgesteuerte Schaltung oder ein kleines Programm.
Lege vor dem ersten Test mindestens ein messbares Erfolgskriterium fest. Beispiele sind Traglast, Fahrstrecke, Reaktionszeit, Temperaturgrenze, Genauigkeit oder Energieverbrauch.
Teste anschließend die erste Version. Fotografiere oder skizziere das Fehlerbild. Formuliere mindestens eine Ursachenhypothese. Verändere genau eine geeignete Größe und teste erneut. Wiederhole den Zyklus mindestens zweimal.
Bei kleinen Bauteilen kann eine präzise Längenmessung entscheidend sein. Doch eine größere Zahl von Nachkommastellen bedeutet nicht automatisch, dass ein Messergebnis zuverlässig ist. Instrument, Messverfahren und Unsicherheit müssen zusammen betrachtet werden.
Differenzierter Arbeitsauftrag G
Du dokumentierst mindestens zwei Versionen. Für jede Version hältst Du Soll, Ist, eine plausible Ursache, eine gezielte Veränderung und das neue Ergebnis fest. Du verwendest mindestens eine Messgröße.
Differenzierter Arbeitsauftrag M
Du dokumentierst mindestens drei Versionen. Vor jeder Veränderung nennst Du mindestens zwei mögliche Ursachen und begründest, welche Du zuerst testest. Für eine wichtige Messgröße erstellst Du eine Messreihe und vergleichst die Varianten.
Differenzierter Arbeitsauftrag E
Du dokumentierst mindestens drei Versionen mit kontrolliertem Versuchsplan. Du beschreibst eine abhängige Größe, mindestens eine gezielt veränderte Einflussgröße und wichtige konstant zu haltende Bedingungen. Du diskutierst Messunsicherheit oder Streuung und bewertest mindestens einen Zielkonflikt, zum Beispiel Stabilität gegen Masse, Genauigkeit gegen Aufwand oder Leistung gegen Energieverbrauch.
Interaktive Aufgaben
Quiz: Teste Dein Wissen
Was ist der erste sinnvolle Schritt bei einem technischen Fehler? (Das beobachtete Fehlerbild konkret beschreiben) (!Sofort mehrere Bauteile austauschen) (!Die letzte Version löschen) (!Nur das Endergebnis bewerten)
Was ist eine Ursachenhypothese? (Eine begründete Vermutung über die Ursache eines Fehlerbildes) (!Eine sichere Tatsache ohne Test) (!Eine Liste aller verwendeten Werkzeuge) (!Ein Messwert ohne Erklärung)
Warum sollte bei einem Vergleichstest möglichst nur eine Einflussgröße gezielt verändert werden? (Damit die Wirkung der Veränderung besser zugeordnet werden kann) (!Damit keine Messwerte benötigt werden) (!Damit jede Hypothese automatisch richtig ist) (!Damit der Prototyp sofort fertig ist)
Was kennzeichnet eine systematische Messabweichung? (Sie verschiebt Messergebnisse in eine bestimmte Richtung) (!Sie verschwindet immer bei einer zweiten Messung) (!Sie entsteht nur durch Rechenfehler) (!Sie betrifft ausschließlich digitale Messgeräte)
Wozu dient eine Messreihe? (Sie macht Streuung und typische Werte besser sichtbar) (!Sie ersetzt ein Erfolgskriterium) (!Sie verhindert jede Messabweichung) (!Sie macht Vergleichstests unnötig)
Was bedeutet Debugging? (Programmfehler systematisch diagnostizieren und beheben) (!Ein Programm ohne Test veröffentlichen) (!Nur die Benutzeroberfläche gestalten) (!Messgeräte auf Null stellen)
Wann ist eine Optimierung gut dokumentiert? (Wenn Veränderung Testdaten und Folgerung nachvollziehbar festgehalten sind) (!Wenn nur die beste Version fotografiert wurde) (!Wenn alle Fehlversuche entfernt wurden) (!Wenn keine Hypothesen notiert wurden)
Welches Ergebnis kann eine Hypothese sinnvoll schwächen? (Ein kontrollierter Test zeigt trotz erwarteter Veränderung keine Verbesserung) (!Die Hypothese klingt technisch) (!Eine andere Gruppe kennt das Problem nicht) (!Der Prototyp sieht schöner aus)
Was ist ein Fehlerbild? (Die beobachtbare oder messbare Abweichung vom erwarteten Verhalten) (!Die endgültig bewiesene Ursache) (!Die Materialliste eines Projekts) (!Die Bewertung einer Person)
Was gehört zu einer iterativen Entwicklung? (Testen auswerten gezielt verändern und erneut testen) (!Einmal bauen und danach nichts mehr verändern) (!Jede Version unter anderen Kriterien bewerten) (!Messwerte nur am Ende erfassen)
Memory
| Fehlerbild | beobachtbare Abweichung |
| Hypothese | begründete Ursachenvermutung |
| Prototyp | Versuchsmodell |
| Messreihe | wiederholte Messungen |
| Debugging | systematische Programmsuche |
| Iteration | wiederholter Verbesserungszyklus |
| Kontrollvariable | konstant gehaltene Bedingung |
| Dokumentation | nachvollziehbare Entwicklungsaufzeichnung |
Drag and Drop
| Ordne die richtigen Begriffe zu. | Thema |
|---|---|
| Beobachtung | Fehlerbild beschreiben |
| Hypothese | mögliche Ursache begründen |
| Veränderung | eine Einflussgröße gezielt anpassen |
| Retest | unter vergleichbaren Bedingungen erneut prüfen |
| Dokumentation | Daten auswerten und nächsten Schritt festhalten |
Kreuzworträtsel
| Prototyp | Wie heißt ein Versuchsmodell für Tests vor der endgültigen Lösung? |
| Hypothese | Wie heißt eine begründete und prüfbare Vermutung über eine Ursache? |
| Messwert | Wie heißt das Ergebnis einer einzelnen Messung? |
| Debugging | Wie nennt man die systematische Suche nach Programmfehlern? |
| Iteration | Wie heißt eine wiederholte Entwicklungs- und Verbesserungsrunde? |
| Streuung | Wie heißt die Verteilung unterschiedlicher Werte einer Messreihe? |
LearningApps
Lückentext
Offene Aufgaben
Leicht – G
- Fehlerfoto untersuchen: Wähle das Bild eines gescheiterten 3D-Drucks aus diesem aiMOOC. Beschreibe nur sichtbare Merkmale und formuliere danach zwei mögliche Ursachen, ohne sie bereits als sicher darzustellen.
- Papierprototyp testen: Baue aus einem Blatt Papier eine kleine tragende Konstruktion. Definiere ein Erfolgskriterium, teste sie und verändere anschließend genau einen Faktor.
- Messreihe erstellen: Miss dieselbe Strecke oder dasselbe Bauteil fünfmal. Dokumentiere die Werte und erkläre, warum sie gleich oder unterschiedlich sein könnten.
- Reflexionskarten nutzen: Wähle nach einem eigenen Versuch drei Reflexionskarten aus dem aiMOOC und beantworte sie vollständig.
Standard – M
- Ursachenbaum erstellen: Erstelle zu einem Fehlerbild mindestens vier Ursachenhypothesen. Ordne sie nach Plausibilität und Testbarkeit und begründe Deine Reihenfolge.
- Vergleichstest planen: Entwickle für zwei Prototypvarianten einen fairen Vergleich mit identischen Erfolgskriterien und mindestens fünf Messungen pro Variante.
- Debugging-Protokoll: Untersuche ein kurzes fehlerhaftes Programm oder eine Mikrocontroller-Steuerung. Halte für jeden Test Hypothese, Codeänderung, Ergebnis und Folgerung fest.
- Entwicklungsinterview: Befrage eine Person, die technisch entwickelt, programmiert, repariert oder experimentiert, dazu, wie Fehler erkannt und dokumentiert werden. Vergleiche die Antworten mit dem Optimierungszyklus dieses aiMOOCs.
Schwer – E
- Kontrollierten Versuch entwickeln: Plane ein Experiment, bei dem Du eine Einflussgröße veränderst, eine Ergebnisgröße misst und mindestens drei wichtige Bedingungen konstant hältst.
- Messunsicherheit bewerten: Vergleiche zwei technische Varianten mit Messreihen und entscheide, ob der beobachtete Unterschied gegenüber der Streuung groß genug ist, um eine belastbare Verbesserung zu behaupten.
- Mehrkriterielle Optimierung: Optimiere einen Prototyp gleichzeitig nach zwei widersprüchlichen Kriterien, zum Beispiel geringer Masse und hoher Stabilität. Begründe, warum Deine Endversion einen sinnvollen Kompromiss darstellt.
- Fehleranalyse als Video: Produziere ein zwei- bis vierminütiges Video, das nicht nur das Endprodukt, sondern mindestens einen gescheiterten Test, die Ursachenhypothese, die gezielte Veränderung, den Retest und Deine Schlussfolgerung sichtbar macht.
|
|
Lernkontrolle
- Unbekannter Fehlerfall: Ein selbst gebautes Fahrzeug fährt nach einer Änderung schneller, aber deutlich weniger geradeaus. Entwickle mindestens drei Ursachenhypothesen und plane eine Testreihenfolge, mit der Du die Ursachen möglichst eindeutig unterscheiden kannst.
- Messdaten interpretieren: Zwei Brückenversionen tragen im Mittel 610 g und 625 g. Die Messwerte beider Varianten streuen jedoch stark zwischen 560 g und 670 g. Erkläre, warum die Aussage „Version B ist sicher besser“ problematisch sein kann und welche zusätzlichen Tests Du fordern würdest.
- Fairer Vergleich: Eine Gruppe verändert gleichzeitig Raddurchmesser, Achsabstand und Motorleistung und erreicht danach eine bessere Fahrstrecke. Beurteile die Aussagekraft des Tests und entwickle einen besseren Versuchsplan.
- Hypothese widerlegen: Formuliere zu einem technischen Fehler eine plausible Hypothese und beschreibe ausdrücklich ein mögliches Testergebnis, das gegen Deine Hypothese sprechen würde.
- Technik und Informatik vergleichen: Vergleiche die Fehlersuche in einer elektrischen Schaltung mit dem Debugging eines Programms. Arbeite mindestens drei gemeinsame Prinzipien und einen Unterschied heraus.
- Entwicklungsprotokoll beurteilen: Eine Gruppe zeigt nur die erfolgreiche Endversion und sagt, die vorherigen Versuche seien „nicht wichtig“. Beurteile diese Entscheidung aus Sicht wissenschaftlich-technischer Nachvollziehbarkeit.
- Optimierung begründen: Ein Prototyp ist nach einer Veränderung stabiler, aber schwerer und teurer. Entwickle Kriterien, mit denen Du entscheiden kannst, ob die Veränderung trotzdem als Verbesserung gelten soll.
Lernnachweis
Für einen Lernnachweis zu diesem Thema ist wichtig, dass Du nicht nur ein funktionierendes Endprodukt präsentierst. Bewertbar ist vor allem die Qualität Deines Entwicklungsprozesses.
- Anforderung: Du formulierst mindestens ein überprüfbares Zielkriterium.
- Fehleranalyse: Du beschreibst Fehlerbilder sachlich und trennst Beobachtung von vermuteter Ursache.
- Ursachenhypothese: Du entwickelst plausible und prüfbare Hypothesen.
- Versuchsplanung: Du veränderst Einflussgrößen gezielt und hältst wichtige Bedingungen möglichst konstant.
- Messung: Du erhebst geeignete Daten und berücksichtigst bei höherem Niveau Streuung oder Messunsicherheit.
- Retest: Du prüfst die veränderte Version unter vergleichbaren Bedingungen.
- Dokumentation: Du hältst Versionen, Änderungen, Daten und Folgerungen nachvollziehbar fest.
- Reflexion: Du erklärst, welche Hypothese gestützt oder geschwächt wurde und was der nächste sinnvolle Entwicklungsschritt wäre.
- G-M-E-Differenzierung: Auf G-Niveau genügt eine klar nachvollziehbare Ursache-Veränderung-Test-Kette. Auf M-Niveau werden mehrere Hypothesen und Messreihen erwartet. Auf E-Niveau kommen kontrollierte Versuchsplanung, Unsicherheitsbetrachtung und begründete Zielkonflikte hinzu.
OERs zum Thema
Passende Wikipedia-Artikel vertiefen Teilbereiche dieses aiMOOCs.
Mediengestützte Vertiefung
Die Medien in diesem aiMOOC erfüllen unterschiedliche Lernfunktionen: Die Bilder gescheiterter 3D-Drucke dienen der visuellen Fehlerdiagnose. Die Messschieber-Animationen zeigen, dass Messergebnisse selbst überprüft werden müssen. Die Breadboard-Aufnahmen veranschaulichen vorläufige technische Aufbauten. Debugging-Bilder übertragen dieselbe Denkweise auf Software. Die Videos zeigen Entwicklung, Fehlersuche und Messauswertung in verschiedenen fachlichen Kontexten.
Nutze Medien deshalb aktiv: Stoppe ein Video vor einer Lösung, formuliere eine eigene Hypothese, vergleiche sie mit dem gezeigten Vorgehen und dokumentiere, welche Information Deine Vermutung gestützt oder verändert hat.
Verknüpfte Lernbereiche