Projekt zur Vorlesung Datenbanken Teil 4b: Deputatsplanung

Projekt zur Vorlesung
Datenbanken
Teil 4b:
Deputatsplanung
Aufgabenbeschreibung
Beispielapplikation
Testdaten
Projektablauf:
Anforderungen an die Dokumentation
Anforderungen an das Projektmanagement
Anforderungen an das Vorgehen
Die Abnahme
Prof. Nonnast
Version 2.4
vom 15.05.09

Aufgabenbeschreibung
In einer Hochschule führen die Studiengangleiter die Kapazitätsplanung der Professoren und
die Stundenplanung der Studiensemester auf Basis von Word-Tabellen manuell durch.
Mehrere Tabellen mit zum Teil redundanten und voreinander abhängigen Daten führen selbst
bei äußerster Umsicht während der Planung und Datenpflege leicht zu inkonsistenten Daten.
Ein datenbankgestütztes Planungs- und Informationssystem soll Eingabemasken und
Datenbestand voneinander trennen, Daten frei von Redundanz abspeichern und den
Planungsprozess beschleunigen.
Eine Analyse der Abläufe ergab folgende Geschäftsprozesse:
Die Planung der Vorlesungen für das kommende Semester umfasst im Wesentlichen die
Festlegung der angebotenen Fächer und die Zuordnung von Professoren und
Lehrbeauftragten. Jedem Fach ist gemäß der Studien- und Prüfungsordnung (StuPO) eine
vorgegebene Anzahl Wochenstunden zugeordnet. Da in verschiedenen Studiengängen
teilweise Fächer gleichen Namens existieren, besitzt jedes Fach eine eindeutige Fachnummer.
Die Planung erfolgt studiengang- und semesterspezifisch.
Ereignisse wie Forschungssemester von Professoren, längere Krankheiten oder
Studiensemester mit ungewöhnlich wenig Studenten kann zur Kopplung von Fächern über
Studiengänge hinweg führen.
Die Belastbarkeit von Professoren ist im Prinzip unendlich. Die tatsächliche Belastung
repräsentiert das Deputat.
Das Deputat eines Professors ergibt sich aus der Anzahl der wöchentlich von ihm insgesamt
in allen Fächer geleisteten Vorlesungs-, Übungs- und Laborstunden. Die Summe, der in einem
einzelnen Fach angerechneten Wochenstunden, den Dozenten-Wochenstunden, kann größer
als die für dieses Fach in der StuPO angegebene Wochenstundenzahl sein. Dies ist dann der
Fall, wenn Labore oder Übungen wegen großer Studentenzahlen geteilt und mehrmals
angeboten werden müssen. Teilen sich mehrere Professoren eine Vorlesung, Übung oder
Labor mit anderen Kollegen oder Lehrbeauftragten, dann kann die Summe der in diesem
einzelnen Fach angerechneten Wochenstunden geringer sein, als die in der StuPO angegebene
Wochenstundenzahl. Mehrleistungen über die 18 Pflichtstunden hinaus werden auf einem
Stundenkonto gutgeschrieben, Minderleistungen werden diesem Stundenkonto belastet.
Mehraufwände, die durch Ausübung von Funktionen in der Selbstverwaltung der Hochschule
entstehen, werden durch einen Stundenrabatt ausgeglichen, dessen Höhe von der jeweiligen
Funktion abhängt und jedes Semester individuell neu festgesetzt wird. Beispiele für solche
Funktionen wären Praktikantenamtsleiter, Laborleiter, Dekan. Die Ausübung von Funktionen
ist zeitlich befristet und nicht an eine konkrete Person gebunden.
Lehrbeauftragte besitzen kein Deputat. Sie können ebenfalls keine Funktionen ausüben.
Part_4b_IM_Planungstool.doc Seite 2 von 7 Prof. Nonnast, 15.05.09

Folgende Berichte müssen aus dem Datenbestand zu erzeugen sein:
Deputate der einzelnen Professoren als Auflistung der einzelnen gehaltenen Vorlesungen,
Übungen und Labore und den ausgeübten Funktionen, jeweils mit Angabe der verrechneten
Wochenstunden. Zusätzlich ist noch der aktuelle Stand des Stundenkontos angegeben.
Verzeichnis der angebotenen Vorlesungen, Übungen und Labore, getrennt nach
Studiengang und Studiensemester.
Meldung der Lehrbeauftragten mit ihrer geplanten Anzahl von Wochenstunden an das
Rektorat. Um die Lehrbeauftragten anschreiben zu können, enthält diese Meldung auch deren
Adressen. Adressen von Professoren werden nicht in diesem System hinterlegt.
Meldung erbrachter Serviceleistungen für andere Fachbereiche an das Rektorat. Beispiel
hierfür wäre das Fach Datenverarbeitung für den Fachbereich Maschinenbau. Diese Meldung
beinhaltet jeweils das betreffende Fach, den erbringenden Dozenten, die Wochenstundenzahl
und den nutznießenden Fachbereich.
Meldung genutzter Serviceleistungen von anderen Fachbereichen an das Rektorat. Beispiel
hierfür wäre das Fach Mathematik vom Fachbereich Grundlagen.
Part_4b_IM_Planungstool.doc Seite 3 von 7 Prof. Nonnast, 15.05.09

Beispielapplikation
Screenshots und generierte Listen stehen zur Verfügung.
Testdaten
Als Grundlage dienen der Online-Stundenplan des Intranets der Hochschule, die Studien- und
Prüfungsordnung (StuPO) und eine Auswahl von Berichten, generiert aus dem
Produktivsystem Aus diesen Produktivdaten ist eine repräsentative Untermenge zu definieren
und zu extrahieren. Die Testdaten sollen beim Funktionstest des Systems plausible, schlüssige
und vollständige Bildschirmausgaben liefern.
Projektablauf:
Das Projekt wird nach den in vorangegangenen Vorlesungen erlernten Vorgehensweisen zum
Software-Engineering und Projektmanagement abgewickelt. Projektteams definieren
unmittelbar zu Beginn eine klare Aufgabenteilung mit Verantwortlichkeiten und erstellen
einen Terminplan. Ein Regeltermin erleichtert die Terminfindung für Projektbesprechungen.
Jedes Projektmitglied führt sein eigenes Projekttagebuch.
Alle Präsentationen sind vorab einzuüben. Die Projektdateien müssen vom Präsentationsraum
aus zugänglich sein. Software-Versionen müssen kompatibel sein. Notwendige Passwörter
müssen bekannt sein. Alle im Terminplan angegebenen Besprechungen und Präsentationen
sind Pflichttermine und zu Semesterbeginn bekannt. Abwesenheit führt in der Regel zu einem
Nachtermin im folgenden Semester.
Folgender Meilensteinplan gibt den Grundablauf des Projektes mit seinen wichtigsten
Teilergebnissen wieder.
M1: Analysemodell:
- Identifizierung und textuelle Beschreibung der gefunden Use-Cases und der daraus
abgeleiteten Requirements.
- Aufstellen des Datenmodells:
• für jeden Use-Case ein ER-Diagramm
• genau ein ER-Diagramm, das ausschließlich die Bewegungsdaten mit allen
Attributen ohne ihre Stammdaten darstellt
• eine Gesamtübersicht ohne Attribut
• Spezifikation des Modells, aller Diagramme, aller Entitäten und Attribute
• Beseitigung aller Fehlermeldungen des Engineering-Werkzeugs
• Generieren eines PDF-Dokuments.
Part_4b_IM_Planungstool.doc Seite 4 von 7 Prof. Nonnast, 15.05.09

Das Analysemodell wird in Form eines Review vorgestellt und eingehend diskutiert. Dabei
gilt die Grundannahme, dass alle Modelle prinzipiell funktionsfähig sind und jedes Modell
besondere Stärken aber auch Schwächen enthält, die es aufzudecken und zu bewerten gilt.
M2: Testfälle
Die Spezifikation der Testfälle soll helfen, einen Datenbestand zu finden, mit dem das fertige
System mit allen seinen Funktionalitäten getestet werden kann. Die Testdaten bilden eine
Untermenge der realen Daten. Das System bleibt in doppelter Hinsicht handhabbar: es ist
klein und überschaubar, und die Korrektheit der Funktionalität spiegelt sich in der
Plausibilität der am Bildschirm dargestellten Daten wider.
Die Testdaten könnten folgende Fälle abdecken:
- Abdeckung mindestens zweier aufeinanderfolgender Semester
- Professoren und Lehrbeauftragte
- Kopplung von Vorlesungen
- Duplizierung von Vorlesungen durch Laborgruppen
- Professoren in Selbstverwaltungsfunktionen
- Guthabenübertrag aus Vorsemester
- Abgerechnete Semester, laufende Semester, in Planung befindliche Semester
- Dozenten mit Stundenkonto in fremden Fakultäten
- Service aus fremder Fakultät
- Service für andere Fakultät
Die Testdaten müssen die Testfälle vollständig und widerspruchsfrei darstellen können.
Die handwerklichen Arbeitsschritte sind:
- Erstellen eines physikalischen Datenmodells
- Entladen der DDL-Definitionen und anlegen der Tabellen in der Projekt-Datenbank.
- Einpflegen der Testdaten.
Part_4b_IM_Planungstool.doc Seite 5 von 7 Prof. Nonnast, 15.05.09

Dabei sind das logische und das physikalische Modell permanent miteinander abzugleichen.
Modellanpassungen sollten Sie dabei minimal halten. Nicht das Modell ist den Testdaten
anzupassen, sondern die Testdaten sind in das jeweilige Modell des Projektteams zu
überführen. Geschickter Weise erledigen selbst erstellte Skripten das Befüllen des Modells
mit den Testdaten. Modellanpassungen sind so rasch umzusetzen. Denkbar wäre auch eine
Verknüpfung der Testdaten-Datei direkt mit der Projekt-Datenbank über MS-ACCESS,
EXCEL und ODBC.
M3: Systemabnahme
- Erstellen der SQL-Skripten zur Realisierung der Use-Cases
- Pflege der Daten in einer einfachen grafischen Oberfläche
- Darstellung der Daten in einem Bericht.
Jeder Use-Case wird in einem einzigen SQL-Skript abgebildet und in Form einer View
abgelegt. Ein MS-ACCESS-Bericht stellt die View in ansprechender Form dar. Die 3-Ebenen-
Architektur ist strikt einzuhalten. Insbesondere ist die Logik für die Use-Cases in den SQL-
Skripten, nicht in der Oberfläche, enthalten. Die Abnahme ist dann erfolgreich, wenn alle
beschriebenen Funktionen fehlerfrei arbeiten.
Anforderungen an die Dokumentation
Die Dokumentation besteht aus den Entwurfunterlagen, dem Skript zum Erzeugen des
Datenbankschemas und den Skripten zur Realisierung der Use-Cases. Die Entwurfsunterlage
beschreibt die gefundenen Use-Cases, das daraus abgeleitete Datenmodell mit seinen
Datensichten, die Entitäten und Attribute. Mit der gegebenen Dokumentationsvorlage ist aus
dem CASE-Werkzeug die Dokumentation als PDF-Dokument zu erzeugen. Diesem
Dokument sind der Projektplan und die Projekttagebücher der Teammitglieder beizufügen.
Anforderungen an das Projektmanagement
Die Aufgabe ist in Teams von drei bis fünf Studenten zu bearbeiten. Die Gruppengröße ergibt
sich aus der jeweiligen Semesterstärke dividiert durch zehn Gruppen. Bei Gruppen mit vier
und fünf Personen erhöht sich die Aufgabenstellung entsprechend der zusätzlich zur
Verfügung stehenden Kapazität. Jede Gruppe bestimmt einen Gruppensprecher und für jeden
Meilenstein einen Teilprojektleiter. Das Projekt kann, insbesondere in der Phase der
Implementierung, arbeitsteilig erledigt werden. Jedes Gruppenmitglied führt ein
Projekttagebuch, aus dem die Projekttreffen und ihre Ergebnisse, die eigenen
Arbeitsergebnisse und der Aufwand hervorgehen. Es ist ein Terminplan zu führen.
Part_4b_IM_Planungstool.doc Seite 6 von 7 Prof. Nonnast, 15.05.09

Anforderungen an das Vorgehen
Die Arbeit gliedert sich in drei Abschnitte: der Analyse der Aufgabenstellung und dem
Entwurf eines passenden Datenbankmodells, dem Aufbau einer Testumgebung und der
Implementierung der Anforderungen. In der Analysephase sind anhand der Aufgabenstellung
die Use-Cases zu finden und zu beschreiben. Dazu gehört zwingend die Auseinandersetzung
mit dem abzubildenden Geschäftsprozess.
Die Abnahme
Die Abnahme erstreckt sich über die in den einzelnen Projektphasen erarbeiteten
Teilergebnisse. Überprüft wird die funktionale Korrektheit der Implementierung durch einen
Soll-Ist-Abgleich der Bildschirmausgaben mit den gegebenen Beispieldaten. Im Falle einer
Bedienoberfläche wird auf eine strikte Trennung zwischen Präsentation und Logik
besonderen Wert gelegt. Die Dokumentation muss vollständig sein und dem tatsächlich
Implementierten entsprechen. Dazu muss das physikalische Modell bei der Abnahme aus dem
konzeptionellen Modell nochmals aufgebaut werden können und mit den gegebenen
Testdaten befüllbar sein.
Abgabe
Abzugeben ist eine ZIP-Datei (GrpXX.zip) mit der Innovatordokumentation im PDF-Format,
den SQL-Skriptdateien und der ACCESS-Datei (MDB).
Bewertungsschema
In die Bewertung geht die Qualität des Produkts als auch der Produktentstehungsprozess ein.
Abgenommen bedeutet, dass ein Industrieeinsatz möglich wäre.
Schema:
NB:
nicht anwesend, nicht abgegeben
0% Annahme nicht möglich
5%-10% Abnahme nur nach Fehlerbeseitigung möglich
15%-20% Abnahme mit Fehlerprotokoll
Part_4b_IM_Planungstool.doc Seite 7 von 7 Prof. Nonnast, 15.05.09