FRIEDRICH-AUGUST

H A S E LWA N DE R
G E W E R B L I C H -T E C H N I S C H E
SCHULEN OFFENBURG

TG-1 / IT

Name:
Klasse:

Projekt

Datum:

Hinweise zur Erstellung der Projekt-Dokumentation sowie zur Projektdurchfhrung

Hardware

Hardwareprojekte knnen mit den bekannten 8051-Systemen, alternativ mit in der

Schule vorhandenen ARM oder Arduino Systemen (sehr gute Dokumentationen sind
im Internet zu finden) realisiert werden. Dabei gilt insbesondere fr ARM und
Arduino: Es muss ein merklicher Teil selbst entwickelter Programmcode vorhanden
sein, es reicht nicht aus, ausschlielich fertig exisiterende Routinen miteinander zu
verknpfen.

Die Dokumentation muss gut aufgebaut und strukturiert sein. Sie muss ein
Inhaltsverzeichnis enthalten und die Seiten mssen nummeriert sein.

Am Anfang soll das Projektthema beschrieben/erklrt werden; Was soll das

Programm knnen ?

Falls bestimmte Produkte verwendet werden (z.B. zustzliche SW-/HW-Pakete) oder

gewisse Voraussetzungen (z.B. Starten einer Datenbank) fr die Lauffhigkeit des
Projektes gelten, sind diese zu beschreiben.

Die Bedienung des Programms muss erklrt werden (vor allem wenn es nicht
selbsterklrend ist !), evtl knnen ein paar Screenshots hilfreich sein.

Es muss beschrieben werden, welche Funktionalitt das Programm hat (d.h. was das
Programm alles kann).

Die wesentlichen Aspekte der Realisierung sind zu erklren: Aufteilung in

Teilaufgaben/Unterprogramme und bersichtliche Darstellung von Zusammenhngen.
Bei der Realisierung in Assembler sind PAPs, ansonsten Struktogramme abzugeben,
fr jedes Haupt, bzw. Unterprogramm 1 Element (PAP oder Struktogramm)

Falls es Probleme gab, wre es ganz gut, diese zu erlutern und zu beschreiben, wie
diese gelst wurden oder warum sie nicht gelst werden konnten.

Zusammenfassung: Beurteilung (und evtl denkbare Erweiterungen )

Quellcode ist nicht Bestandteil der Dokumentation, sondern wird zusammen mit dem fertigen
Produkt auf Datentrger abgegeben, er muss mit sinnvollen Kommentaren versehen sein. Zu
Erklrungszwecke drfen natrlich einzelne Codeteile in der Dokumentation erscheinen !

/var/www/apps/conversion/tmp/scratch_1/323293636.docx

08.07.16

Frdrique Haas / Tobias Fahrner

FRIEDRICH-AUGUST
H A S E LWA N DE R
G E W E R B L I C H -T E C H N I S C H E
SCHULEN OFFENBURG

TG-1 / IT

Name:
Klasse:

Projekt

Datum:

Stichpunkte fr die Produkt-Bewertung

Fr die Bewertung des Produkts wird zuerst die Dokumentation gelesen und dann das Produkt
selbst entsprechend getestet. Anschlieend werden die Quellen untersucht. Alles, was dabei
auffllig ist, wird notiert und hat einen Einflu auf die zu vergebenden Teilpunkte. Beispiele:
Lauffhigkeit
Schwierigkeitsgrad, Originalitt, Umfang der Lsung
Aufbau in logisch zusammengehrige Teile
Programmierstil: Wahl der Bezeichner, Kommentare, sinnvollen Einsatz von
Kontrollstrukturen und Methoden
Benutzerfreundlichkeit
Wartbarkeit, Erweiterbarkeit

Nichtkonzentriertes Arbeiten (z.B. ewiges Surfen im Internet) in den Unterrichtsstunden kann sich
negativ auf die Note auswirken !
Plagiate, also unerlaubtes und vor allem undokumentiertes Verwenden von fremdem geistigem
Eigentum werden mit 0 Punkten bewertet.
Natrlich ist es das primre Ziel, am Ende ein funktionierendes Projekt zu erstellen. Jedoch kann
auch ein nicht fehlerfrei funktionierendes Projekt zu einer guten oder sehr guten Note fhren,
wenn begrndet ist, warum nicht alles 100 %ig funktioniert und wenn der Betreuer erkennt, dass
auch wirklich Zeit und Mhe in die Beseitigung des Fehlers investiert wurde.
Dagegen bedeutet ein - zumindest auf den ersten Blick fehlerfrei funktionierendes Produkt nicht
zwangslufig, dass daraus eine gute oder sehr gute Note resultieren muss, da auch Komplexitte,
Erweiterbarkeit usw. in die Bewertung einflieen.

/var/www/apps/conversion/tmp/scratch_1/323293636.docx

08.07.16

Frdrique Haas / Tobias Fahrner