Benutzer-Werkzeuge
orga:kursbewertung
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen gezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
|
orga:kursbewertung [2019/04/25 20:50] d.golovko [Geamtbewertung des Projektergebnisses] |
orga:kursbewertung [2022/01/27 17:03] (aktuell) d.golovko |
||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| ====== Bewertung der Projektarbeit ====== | ====== Bewertung der Projektarbeit ====== | ||
| + | |||
| + | <note>In diesem Semester ist es das erste Mal, dass wir Projekte nach diesem neuen Schema bewerten. Kleine Änderungen zu eurem Vorteil sind möglich. </note> | ||
| + | |||
| Die Bewertung eurer Projektarbeit geht mit einer Gewichtung von 40% in eure Gesamtnote ein. | Die Bewertung eurer Projektarbeit geht mit einer Gewichtung von 40% in eure Gesamtnote ein. | ||
| Folgende Einflussfaktoren berücksichtigen wir dabei: | Folgende Einflussfaktoren berücksichtigen wir dabei: | ||
| - | ===== Projektbegleitend: Herangehensweise, Teamwork, Engagement ===== | + | ===Anzahl der unterschiedlichen Elektrobauteilen (die auch funktionieren):=== |
| - | Während des Semesters machen wir uns immer wieder formlos Notizen zu eurer Arbeit: | + | |
| - | ==== Arbeitsdisziplin und Engagement ==== | + | * Gleiche Bauteile werden als 1 Bauteil gezählt. D.h. wenn eurer Roboter 6 Magnetventile hat, zählen sie als 1 Magnetventil. |
| - | * War eure Gruppe anwesend? | + | * Bauteile, die wie ein PT oder Button funktionieren (einfacher Anschluss an einen analogen oder digitalen Pin), zählen als 0,5 Teile. LEDs zählen nicht. |
| - | * Ist euer Material parat? | + | * Kommunikation zwischen Arduino und einem Computer zählt als 1 Bauteil. |
| - | * Ist erkennbar, dass ihr konzentriert arbeitet, oder sehen wir euch nur beim Quatschen und Computerspielen? | + | |
| - | ==== Teamwork ==== | + | Pro Teil 2-3 Punkte, jedoch maximal 15 Punkte |
| - | * Ist eine sinnvolle Aufteilung von Aufgaben und Zuständigkeiten erkennbar? | + | |
| - | * Schafft ihr es, auch schwächere Teammitglieder einzubinden, indem ihr ihnen etwas erklärt und ihnen sinnvolle Aufgaben gebt? | + | |
| - | * Arbeiten alle oder nur eine/r? | + | |
| - | * Haben alle Teammitglieder die Chance, bei Entscheidungen Gehör zu finden? | + | ===Zusätzliche komplexe Elemente (Halbeelemente möglich):=== |
| - | * Ist der Umgangston freundlich? | + | * Algorithmen aus der Bildverarbeitung |
| - | ==== Selbstständiges Denken und Recherchieren ==== | + | * Algorithmen aus dem maschinellen Lernen |
| - | * Ist erkennbar, dass ihr zu Hause zur Theorie hinter eurem Roboter recherchiert habt? | + | * Verwendung von sonstigen komplexeren Bibliotheken (einfache Übernahme von Arduino/Processing-Beispielen reicht nicht aus) |
| - | * Finden an eurem Tisch zielführende Diskussionen zu Theorie, Aufbau, Messungen und Vorgehensweisen statt? | + | * Verwendung von selbst geschriebenen Klassen (wo es sinnvoll ist und der Umfang angemessen ist. In den meisten Fällen wird es bedeuten, dass die Klasse Attribute, Konstruktoren und Methoden beinhaltet und sich wiederholende Gegenstände oder Prozesse sinnvoll modelliert. Nicht gezählt werden Klassen, die nur aus wenigen Zeilen bestehen und keine zentrale Rolle im kompletten Code haben.) |
| - | * Könnt ihr Fragen beantworten, deren Klärung wir euch in der vorherigen Session empfohlen haben? | + | * Geometrische Berechnungen (z.B. Anwendung des Kosinussatzes). Voraussetzung: Dokumentation im Wiki |
| - | * Habt ihr selbstständig Ansätze zur Suche nach Fehlern? | + | * Elektrotechnische Berechnungen (z.B. des geeigneten Widerstandswertes in einer komplexeren Schaltung). Voraussetzung: Dokumentation im Wiki |
| + | * Mechanische Elemente (z.B. Hebel, Welle, selbst ausgerechnete Übersetzung durch Zahnräder usw.) | ||
| + | * Physikalische Berechnungen (z.B. Flugbahn). Voraussetzung: Dokumentation im Wiki | ||
| + | * Komplexe Datenauswertung (z.B. Regressionsmodelle, Erfassung von Messdaten nach einem im Voraus definierten Ansatz und ihre statistische Auswertung). Voraussetzung: Dokumentation im Wiki | ||
| + | * 3D-Druck von selbst erstellten Modellen | ||
| + | |||
| + | Pro Element 3-4 Punkte, jedoch maximal 15 Punkte | ||
| + | |||
| + | |||
| + | ===Code: 10 Punkte:=== | ||
| + | * Variablen-, Funktions- und Klassennamen: 2 Punkte | ||
| + | * Aufteilung in Funktionen, Verwendung von Parametern: 2 Punkte | ||
| + | * Redundanz: Abzug von bis zu 2 Punkten | ||
| + | * Variablen möglichst lokal: 2 Punkte | ||
| + | * Kommentare: 2 Punkte | ||
| + | * Extra Umfang / Logik: 2 Punkte | ||
| + | |||
| + | |||
| + | ===Arbeit im Team:=== | ||
| + | * Haben alle in vergleichbarem Maß mitgearbeitet? 2 Punkte | ||
| + | * War die Kommukation mit den Lehrenden im Laufe des Semesters transparent? 2 Punkte | ||
| - | ===== Nach Projektende: Bewertung von Umfang und Qualität des Projektergenisses ===== | + | ===Weitere Aspekte:=== |
| - | Nach Abschluss euerer Projekte treffen sich die Dozenten und schauen sich euren Roboter und den Quellcode genau an. | + | * Stabilität und Sicherheit der Konstruktion: 2 Punkte |
| + | * Verkabelung (ob sie ordentlich ist und die Farbkodierung passt): 2 Punkte | ||
| + | * Zusätzliche Punkte für die Komplexität oder interessante Projektidee möglich | ||
| - | Zu jeder der folgenden Kategorien schreiben wir einen kurzen Kommentar, den ihr einsehen könnt und bewerten jede Kategorie mit 10% der Endnote (vier Kategorien ergeben dann 40% der Endnote): | ||
| - | ==== 1. Auslegung des Gesamtsystems, Designideen und Arbeitsstil ==== | ||
| - | * Ist das angestrebte Zusammenspiel von Soft- und Hardware grundsätzlich geeignet, das Projektziel zu erreichen? | ||
| - | * Hätte es Designalternativen gegeben, die das Erreichen des Ziels signifikant vereinfacht hätten? | ||
| - | * Hat die Koordination der Arbeit in der Gruppe funktioniert? | ||
| - | ==== 2. Mechanischer Aufbau ==== | ||
| - | * Macht die gewählte Form des Roboters Sinn? | ||
| - | * Ist der Aufbau sicher? (keine herausstehenden spitzen Teile, keine vorhersehbaren Defekte bei Kollisionen mit Hindernissen oder durch andere Umgebungseinflüsse wie z.B. auslaufende Flüssigkeiten) | ||
| - | * Ist der Funktionsumfang besonders beeindruckend? | ||
| - | * Ist der Roboter einfach wartbar? | ||
| - | * Ist er angemessen stabil? | ||
| - | * Sind intelligente Lösungen erkennbar, die ein besonders gutes Ergebnis bei besonders kleinem Aufwand ermöglichen? | ||
| - | * Bonus für kreative Ideen. | ||
| - | ==== 3. Elektronik ==== | ||
| - | * Sind Kabel und Module so aufgebaut, dass sie sicher gegen Kurzschlüsse und Schäden durch Transport und Erschütterungen sind? | ||
| - | * Ist die Verkabelung übersichtlich und die Farbkodierung (rot, schwarz) richtig? | ||
| - | * Sind besonders komplizierte selbstentwickelte Schaltungen vorhanden? | ||
| - | * Sind intelligente Lösungen erkennbar, die ein Problem mit besonders geringem Aufand lösen? | ||
| - | ==== 4. Programmcode ==== | ||
| - | === Formales === | ||
| - | * Ist der abgegebene Code vollständig? | ||
| - | * Compiliert er? | ||
| - | === Übersichtlichkeit und Stil === | ||
| - | * Ist bei Durchsicht des Codes auf den ersten Blick (z.B. durch Kommentare) erkennbar, was er macht? | ||
| - | * Wurden sprechende Namen für Variablen verwendet? | ||
| - | * Wurden Variablen möglichst lokal deklariert? | ||
| - | * Ist der Code sinnvoll kommentiert? (Alles, was nicht völlig "trivial" ist, verdient eine Erläuterung, wozu es dient) | ||
| - | * Wurde das Programm sinnvoll in Klassen und Methoden aufgeteilt? | ||
| - | === Umfang und Qualität === | ||
| - | * Beeindruckt der Funktionsumfang des Programms? | ||
| - | * Wurden Kontrollstrukturen (if/then/else, for, while, switch...case) sinnvoll eingesetzt? | ||
| - | * Wurden fortgeschrittene Algorithmen implementiert? | ||
| - | * Sind offensichtliche Fehler erkennbar? | ||
orga/kursbewertung.1556218256.txt.gz · Zuletzt geändert: 2019/04/25 20:50 von d.golovko
Seiten-Werkzeuge
