Uni Bremen

Software-Projekt 2009/10

Begleitende Unterlagen / Ressourcen / Informationen zum Software-Projekt 2008/09
Dozent zur Vorlesung: Prof. Dr. rer. nat. Rainer Koschke

FB3


Scheinbedingungen für Studierende der Informatik

Vorbemerkungen

Ein paar Bemerkungen vorweg: Die Scheinbedingungen berücksichtigen diese Aspekte.

Notenzusammensetzung

Die Gesamtnote der Lehrveranstaltung setzt sich zusammen aus:
  1. zu einem Drittel der Note aus der Prüfung zur Vorlesung Software-Projekt (SWP) und Datenbankgrundlagen (DBG)
  2. zu zwei zwei Dritteln der Note zum Projektteil
Die Gewichtung entspricht den Anteilen an CP, die es für die Veranstaltung gibt. Beide stellen eine Teilprüfung dar und müssen beide mit mindestens 4,0 bestanden werden, um einen Schein zu bekommen.

Zusätzliche Übungsaufgaben

Im Gegensatz zu anderen Lehrveranstaltungen im Grundstudium müssen in SWP keine regelmäßigen Übungszettel abgegeben werden. Der Übungsanteil findet hauptsächlich in Form des Projektes statt. Unterstützend für das Projekt werden wir aber dennoch kleinere Aufgaben vorsehen, die in die folgenden Kategorien fallen:
  1. obligatorische Implementierungsaufgaben
  2. freiwillige Aufgaben für das Selbststudium

Obligatorische Implementierungsaufgaben

Die Erfahrung der letzten Jahre hat gezeigt, dass Studierende Schwierigkeiten insbesondere bei den abstrakten Konzepten der Softwarearchitektur haben, die sie später konkret implementieren sollen. Aus diesem Grund werden wir dieses Jahr auch den umgekehrten Weg vom Konkreten zum Abstrakten beschreiten.

Begleitend zur Vorlesung werden deshalb zwei Aufgaben gestellt, für die Lösungen abgegeben werden müssen. Sie werden nicht benotet, müssen aber erkennbar bearbeitet sein. Ohne erkennbare Bearbeitung - das heißt, die Abgabe muss zumindest eine partielle Lösung darstellen - gilt die Veranstaltung als nicht bestanden.

In beiden Aufgaben geht es darum, eine existierende Implementierung eines Bibliotheksverwaltungssystems namens Bibi zu ergänzen. Das Lernziel, das wir dabei verfolgen, ist ein besseres Verständnis von Architekturkonzepten und ihrer Implementierung. Es dient dazu, die Bedeutung von Dokumentationen darzustellen, und ist eine Vorübung für die eigene Architekturspezifikation. Für die erste Aufgabe wird nur der Quellcode von Bibi veröffentlicht. Für die zweite Aufgabe werden ergänzende Dokumentationen (insbesondere die Architekturbeschreibung) nachgereicht.

Freiwillige Aufgaben für das Selbststudium

Zur Vorbereitung auf die theoretische Prüfung werden weitere Übungsaufgaben mit Musterlösungen ausgegeben. Sie dienen allein dem Selbststudium. Sie werden nicht abgegeben und nicht bewertet.

Projektteil

Die Projektnote ergibt sich aus den abgegebenen Dokumenten, der Code-Inspektion, dem individuellen Beitrag zum Projekt und der Abschlusspräsentation. Die Gewichte sind wie folgt:

Dokument Gewicht
Projektplan 14%
Anforderungsspezifikation und Angebot 22%
Architekturbeschreibung 20%
Schnittstellentests (JUnit) und Testplan 10%
Implementierung 24%
Benutzerdokumentation 7%
Abschlusspräsentation (kein Dokument) 3%

Primär ergibt dies eine Gruppennote; jeder Einzelne steht damit in der Verantwortung für den Erfolg des Projekts. Ich behalte mir jedoch vor, von der Gruppennote sowohl nach oben als auch nach unten abzuweichen, wenn für mich erkennbar ist, dass einzelne Gruppenmitglieder mehr bzw. weniger geleistet haben (z.B. durch die Code-Inspektion oder das Berichtsheft).

Die Abgaben werden von Tutor und/oder Prüfer in einem Gespräch mit der Gruppe auf die individuelle Leistung überprüft.

Die Abgaben erfolgen zu verschiedenen Zeitpunkten. Sie werden von uns rechtzeitig im Web bekannt gegeben. Die Endabgabe erfolgt zeitnah zum Ende der Vorlesungszeit im Sommer und umfasst neben Dokumenten zum Test und dem Benutzerhandbuch noch die Implementierung.

Erfolgt eine Abgabe nicht, wird sie mit einer 5,0 bewertet. Bei verspäteten Abgaben ist ebenso mit einer 5,0 zu rechnen. Im Falle der Abschlusspräsentation gilt das Abhalten der Präsentation als Abgabe.

Bei zwei oder mehr Abgaben, die mit einer 5,0 bewertet sind, wird der gesamte Kurs als nicht bestanden gewertet. Ich behalte mir vor, nicht abgegebene oder nicht ausreichende Abgaben nochmals einzufordern, auch wenn dies auf die Benotung der Abgabe keinen Einfluss hat. Geschieht dies nicht, gilt der Kurs ebenso als nicht bestanden.

Zum Ende des Kurses im Sommer erfolgt die abschließende vollständige Abgabe aller Dokumente und der Implementierung. Erfolgt sie nicht rechtzeitig oder unvollständig, wird der gesamte Kurs als nicht bestanden bewertet. Die Implementierung gilt als unvollständig, wenn die Mindestkriterien nicht erfüllt sind.

Falls die Implementierung nicht die Mindestkriterien erfüllt, können wir in Ausnahmefällen und allein nach unserer Einschätzung eine Verlängerung für die Abgabe einräumen. In diesem Falle muss die vollständige Implementierung aller Mindestanforderungen innerhalb einer von uns gesetzten Frist nachgereicht werden. Die Bewertung der Implementierung kann dadurch jedoch nicht verbessert werden und bleibt bei einer 5,0; aber zumindest kann damit das Nichtbestehen abgewendet werden (sofern dies die erste 5,0 für eine Abgabe ist; siehe oben). Diese Regel ist eine Kann-Regel, die wir anwenden können, wenn wir den Eindruck haben, dass die Implementierung bereits nahe beim Erfüllen der Mindestkriterien ist. Keinesfalls kann man diese Regel "einklagen".

Theorieteil

Prüfungsformen und Anmeldung

Die Prüfung im Theorieteil kann in zwei unterschiedlichen Varianten abgelegt werden: entweder mündlich oder schriftlich. Die Entscheidung muss bis zur Anmeldefrist getroffen werden und ist dann endgültig.

Die Anmeldung folgt circa 4 Wochen vor den ersten Prüfungsterminen. Nach Festlegung des Termins kann der Termin nicht mehr ohne Zustimmung des Prüfers geändert werden (und auch nur unter Nennung gewichtiger Gründe).

Bei einer nicht rechtzeitigen Anmeldung für eine der beiden Prüfungsformen gilt der Prüfungsversuch als nicht bestanden.

Das Fehlbleiben von der Prüfung wird mit 5,0 bewertet, es sei denn der Prüfling konnte aus Krankheitsgründen oder anderen gravierenden Umständen nicht teilnehmen. Im Falle einer Krankheit muss umgehend ein ärztliches Attest vorgelegt werden, welches die Prüfungsunfähigkeit bescheinigt. Eine Arbeitsunfähigkeitsbescheinigung reicht nicht.

Mündliche Prüfungsform

Die mündliche Prüfung ist individuell, d.h. wird nicht in Gruppen durchgeführt. Der Ablauf ist wie folgt (in Anlehnung an das mündliche Abitur):

Dieses Modell gibt ausreichend Zeit für die Vorbereitung und trägt der Tatsache Rechnung, dass zwei Vorlesungen mit einem erheblichen Anteil an Credit Points geprüft werden. Im Gegensatz zu anderen Lehrveranstaltungen gibt es zur Vorlesung keine Übungsaufgaben, die einzeln bewertet werden.

Das Projekt dient zwar der praktischen Umsetzung des Vorlesungsinhalts. Dafür gibt es jedoch separat 12 CP über die Vorlesung hinaus. Der Vorlesungsinhalt soll also auch separat geprüft werden. Außerdem wird der Vorlesungsinhalt zeitnah in der vorlesungsfreien Zeit des Wintersemesters geprüft. Das Projekt selbst geht jedoch im Sommersemester weiter.

Schriftliche Prüfungsform

Weil manche Studierende ungern mündlich geprüft werden, biete ich optional eine schriftliche Prüfung an, sofern dafür eine kritische Masse an Interessenten existiert (ab ca. 20 Studierenden).

Die schriftliche Prüfung wird in den ersten Wochen der vorlesungsfreien Zeit noch in diesem Wintersemester und zwar nach den mündlichen Prüfungen statt finden. Die Dauer der Prüfung ist 60 min. Die Aufgaben sind vergleichbar mit jenen der mündlichen Prüfung.

Gegenstand der Prüfung

Gegenstand der Prüfung sind die Inhalte der beiden Vorlesungen SWP und DBG im Verhältnis ihrer Credit Points. In beiden Prüfungsgebieten müssen mindestens 50% der erreichbaren Punkte erreicht werden, damit die Prüfung insgesamt als bestanden gilt.

Ich weise ausdrücklich darauf hin, dass Programmieren mit Java, in dem Maße wie es in PI 1 und 2 vermittelt wird, auch Bestandteil der Prüfung sein kann. Die Prüfung kann auch Bezug nehmen auf Aspekte des begleitenden Projekts.

Beide Vorlesungen, SWP und DBG, zusammen mit dem Projekt bilden eine Einheit und ergeben eine Note für den theoretischen Teil (gewichtet nach den Anteilen). Es gibt keinen separaten Schein für DBG oder den SWP-Vorlesungsanteil alleine.

Wiederholung der Prüfung

Die Wiederholung der Prüfung ist grundsätzlich mündlich.

Ein Nichtbestehen der theoretischen Prüfung hat zur Folge, dass das Modul als nicht bestanden gilt, das heißt, ein Schein mit einer 5,0 wird ausgestellt. Dem Prüfling wird jedoch die Gelegenheit gegeben, nach ca. 4 Wochen die Prüfung einmal zu wiederholen. Ist die Wiederholung erfolgreich, kann der Prüfling mit der Veranstaltung fortfahren. Maßgebend für die Endnote der Veranstaltung ist dann die zweite Note aus der Wiederholung. Wird der Wiederholungsversuch wieder nicht bestanden, gilt die Veranstaltung als nicht bestanden (mit zwei fehlgeschlagenen Prüfungsversuchen) und der Prüfling hat gegebenenfalls die Möglichkeit, die Veranstaltung im nächsten Durchgang zu wiederholen, sofern er oder sie noch ausreichend Prüfungsversuche hat.

Sonderregeln für Wiederholer des gesamten Kurses

Für Wiederholer des gesamten Kurses gelten folgende Sonderregeln:

Code-Inspektion

In der Code-Inspektion erläutert ein Projektmitglied den Quellcode, den es selber geschrieben hat. Das Projektmitglied muss Fragen hierzu und zur Java-Programmierung im Allgemeinen, soweit sie für das SWP vorausgesetzt wird, beantworten können. Gegebenenfalls muss die Code-Inspektion wiederholt werden. Sie kann einmal wiederholt werden. Die Code-Inspektion kann vom Tutor bzw. der Tutorin und dem Prüfer abgenommen werden.

Die Code-Inspektion muss bestanden werden. Ansonsten wird der Kurs insgesamt als nicht bestanden gewertet.

Wird in der Code-Inspektion hinreichend deutlich, dass das Projektmitglied den Quellcode nicht selbst geschrieben hat, muss es damit rechnen, dass dies als Täuschungsversuch gewertet wird. In diesem Falle wird das Projektmitglied vom Kurs ausgeschlossen und erhält eine 5,0 sowie einen Eintrag in seine Prüfungsakte.

Berichtsheft

Jeder Teilnehmer führt ein Berichtsheft über ein von uns zur Verfügung gestelltes System (MEMS). Das Berichtsheft dokumentiert den individuellen Beitrag am Projekt.

Drei Tage nach Abgabe des Produkts der gerade abgeschlossenen Phase müssen alle Einträge der eben abgeschlossenen Phase aktuell sein. Nach drei Tagen wird das System für diese Phase gesperrt, und es sind keine Eintragungen mehr möglich. Nur in begründeten Fällen öffnen wir das System für Nachtragungen. Dies wird jedoch höchstens einmal pro Student geschehen. Die Grundlage für die Bewertung des individuellen Eintrags sind dann die Einträge im System. Folglich kann für jemanden, der versäumt hat, seinen Beitrag im elektronischen Berichtsheft zu dokumentieren, die Abgabe, die mit der Phase verbunden ist, mit einer 5,0 bewertet werden. Aus diesem Grund empfehlen wir dringend, das Berichtsheft kontinuierlich zu pflegen.

Zum Ende jeden Semesters erhält jede Gruppe ein Formular mit der Zusammenfassung der eingetragenen Stunden aller Gruppenmitglieder. Jedes Gruppenmitglied bestätigt mit seiner Unterschrift die Korrektheit der eigenen Angaben im Berichtsheft mit der folgenden Formulierung:

Durch ihre Unterschriften bestätigen die Teilnehmer des Software-Projekts 2009/2010 der Gruppe ... für den Zeitraum vom ... bis zum ..., dass ihre jeweils für sich selbst im elektronischen Berichtsheft eingetragenen Stunden der tatsächlich geleisteten Arbeitszeit entsprechen. Tutor und Prüfer können nach jeder Abgabe den individuellen Beitrag jedes Gruppenmitglieds in einem Gespräch überprüfen.

Regelung für Durchfaller (Quick-SWP)

Wer die Lehrveranstaltung nicht mit Erfolg beendet (Teilnahme mit Gesamtbewertung 5,0), weil er/sie im praktischen Teil durchgefallen ist, aber den theoretischen Teil (mündliche oder schriftliche Prüfung) mit Erfolg bestanden hat, der kann in der vorlesungsfreien Zeit im Sommer (Zeitraum ungefähr August bis Anfang November; Genaueres werden wir noch festlegen) den praktischen Anteil wiederholen. Die Art der Abgaben und der Arbeitsaufwand sind die selben, nur die Bearbeitungszeit wird gestrafft. Der Inhalt der Aufgabe ändert sich natürlich.

Die Teilnahme an diesem "Quick-SWP" gilt als erneuter Prüfungsversuch.

Diese Regelung ist für Studierende gedacht, die im Herbst ihr Hauptstudiumsprojekt ohne Zeitverlust beginnen möchten. Diese Möglichkeit ist eine Option. Es steht allen frei, statt dessen im nächsten Jahr wieder regulär teilzunehmen.

Scheinbedingungen für Studierende des System-Engineerings

Studierende des Studiengangs Systems-Engineering nehmen nicht am praktischen Teil der Vorlesung teil. Sie geben keine für Studierende der Informatik obligatorischen Übungsaufgaben ab. Sie werden nur über den Stoff der Vorlesung Software-Projekt geprüft (also nicht über DBG). Ihre Endnote ist die Note aus der theoretischen Prüfung. Die Prüfungsmodalitäten sind ansonsten die gleichen wie bei den Studierenden der Informatik.

Seite erstellt von Rainer Koschke - $Id: scheinbedingungen.html 6902 2009-07-07 09:43:46Z tmende $

Valid HTML 4.01 Transitional