Einführung
Unter Klausurorganisationssystem ist eine Software zu verstehen, die Lehrende der Fachhochschule Dortmund nutzen können, um Klausuren mit Hilfe der elektronischen Datenverarbeitung zu organisieren. Es stellt einen Bestand an Funktionen bereit, welche die Aufgaben der Klausurvorbereitung und -bewertung unterstützen. Dabei wird darauf gebaut, daß die klausurrelevanten Daten, von der Fachhochschul-verwaltung, in einer elektronisch verarbeitbaren Form zur Verfügung gestellt werden. Dem System liegt eine relationale Datenbank zugrunde, welche Microsoft Access mit dem Anwendungsprogramm vereint. Dabei ist das Anwendungsprogramm derart konzipiert, daß zur Bedienung der Software weder Kenntnisse über Datenbanken im allgemeinen, noch über Microsoft Access im speziellen erforderlich sind. Insofern kann das Klausurorganisationssystem aus Sicht des Anwender als eigenständiges Programm betrachtet werden. Die Entwicklung der Software bezieht sich auf Zweierlei: einerseits auf die Entwicklung der Datenbank und andererseits auf die
Anwendungsprogrammierung. Diese Diplomarbeit beschreibt die verschiedenen Entwicklungsstufen und bildet zusammen mit den Anhängen die Entwicklungs- und Systemdokumentation.
1.1 Aufbau der Diplomarbeit
Im Anschluß an diese Einführung befaßt sich das zweite Kapitel mit der Planung der Softwareentwicklung. Dabei werden stets theoretische Ausarbeitungen mit der praktischen Entwicklungsarbeit in Zusammenhang gebracht. Im ersten Teil dieses Kapitels sollen
verschiedene Phasenmodelle der Softwareentwicklung dargestellt werden, um diesen die realisierten Phasen der Entwicklung gegenüberzustellen. In den darauffolgenden Teilen des zweiten Kapitels soll erläutert werden, wie aus einer Problemerkenntnis ein detailliertes Sollkonzept entsteht. In diesem Zusammenhang wird eine Problemstellung herausgearbeitet, welche die Entwicklung eines Klausurorganisationssystems begründet. Dazu wird der Prozeß
Klausurorganisation näher untersucht und eine Struktur erarbeitet, die Grundlage für die Entscheidung über die zum Einsatz kommende Entwicklungssoftware ist. Im fünften und letzten Teil des zweiten Kapitels wird das Sollkonzept und dessen Entstehung ausführlich erörtert.
Dieses Sollkonzept besteht aus einer verbalen Beschreibung der Softwareanforderungen, der Darstellung des Sollprozesses sowie der Darstellung des Datenbankentwurfs.
[...]
Inhaltsverzeichnis
Abbildungsverzeichnis
1 Einführung
1.1 Aufbau der Diplomarbeit
1.2 Ziel der Arbeit
2 Entwicklungsplanung
2.1 Phasenkonzeption
2.1.1 Phasenmodelle
2.1.2 Realisierte Phasen der Softwareentwicklung
2.2 Vom Problem zum Sollkonzept
2.3 Problemstellung
2.3.1 Der Prozeß Klausurorganisation
2.3.2 Prozeßkettenanalyse und Problembeschreibung
2.3.3 Sollstruktur
2.4 Lösungsalternativen und Entscheidung
2.5 Sollkonzept
2.5.1 Der Prozeß Klausurorganisation mit KOSY-Funktionalität
2.5.2 Das Entity Relationship Modell
3 Die Realisierung der Softwareentwicklung
3.1 Die Entwicklungsumgebung Microsoft Access 97
3.1.1 Struktur und Objekte
3.1.2 Die Programmiersprache Visual Basic für Applikationen für Office 97
3.2 Das relationale Datenmodell des Klausurorganisationssystems
3.3 Die Entwicklung der Funktionen des Klausurorganisationssystems
3.3.1 Die Menü- und Dialoggestaltung
3.3.2 Raum- und Platzbelegung
4 Systemtest und Softwareeinführung
4.1 Der Systemtest
4.1.1 Prüfung des Funktionsumfangs
4.1.2 Prüfung der Qualitätsanforderungen
4.2 Die Softwareeinführung
Literaturverzeichnis
Versicherung
Anhang C - Sollprozeß der Klausurorganisation
Anhang D - Fragebogen zur Ermittlung der Softwarequalität
Abbildungsverzeichnis
Abbildung 1 Wasserfallmodell mit Rückkopplung nach Boehm
Abbildung 2 Spiralmodell nach Boehm
Abbildung 3 Prototyping - Modell
Abbildung 4 Entwicklungsphasen des Klausurorganisationssystems
Abbildung 5 Prozeß der Sollkonzeptentwicklung
Abbildung 6 Klausurstruktur
Abbildung 7 Der Prozeß Klausurorganisation i.e.S
Abbildung 8 Struktur der Zulassungsliste
Abbildung 9 Der Prozeß Klausurorganisation im Kontext
Abbildung 10 Abruf der Daten aus Pluto
Abbildung 11 Weitergabe der Daten auf Diskette
Abbildung 12 Bewertung der Entwicklungssysteme
Abbildung 13 Der Funktionsbaum des Klausurorganisationssystems
Abbildung 14 Fensteraufbau des Klausurorganisationssystems
Abbildung 15 Entitättyp Fachprüfung
Abbildung 16 Entitättyp LEHREINHEIT
Abbildung 17 Entitättyp KLAUSUR
Abbildung 18 ER-Modell für die Entitättypen Klausur, Fachprüfung und Lehreinheit
Abbildung 19 ISA - Beziehungen
Abbildung 20 ERM der Klausurorganisation
Abbildung 21 Die Beziehung zwischen Klausur und Fachprüfung
Abbildung 22 Beziehung zwischen Fachprüfung und Lehreinheit
Abbildung 23 Benutzerzuordnungen
Abbildung 24 Zuordnung der Menüs zu den Benutzergruppen
Abbildung 25 Prinzip der Einblendung von Zusatzmenüleisten
Abbildung 26 Querverweise zwischen Dialogformularen
Abbildung 27 Programmablaufplan der Raum- und Platzbelegung
Abbildung 28 Tabellen für die Raum- und Platzbelegung
Abbildung 29 Abfrage: Anzahl Kandidaten je Klausur
Abbildung 30 Prozedur "Weiter" der Klausurauswahl
Abbildung 31 Aufbau der Funktion "AutoRaumzuteilung"
Abbildung 32 Zusammenhang von Klassen- und Standardmodulen
Abbildung 33 Beispiel eines Projektplans zur Softwareeinführung
1 Einführung
Unter Klausurorganisationssystem ist eine Software zu verstehen, die Lehrende der Fachhochschule Dortmund nutzen können, um Klausuren mit Hilfe der elektronischen Datenverarbeitung zu organisieren. Es stellt einen Bestand an Funktionen bereit, welche die Aufgaben der Klausurvorbereitung und -bewertung unterstützen. Dabei wird darauf gebaut, daß die klausurrelevanten Daten, von der Fachhochschulverwaltung, in einer elektronisch verarbeitbaren Form zur Verfügung gestellt werden. Dem System liegt eine relationale Datenbank zugrunde, welche Microsoft Access mit dem Anwendungsprogramm vereint. Dabei ist das Anwendungsprogramm derart konzipiert, daß zur Bedienung der Software weder Kenntnisse über Datenbanken im allgemeinen, noch über Microsoft Access im speziellen erforderlich sind. Insofern kann das Klausurorganisationssystem aus Sicht des Anwender als eigenständiges Programm betrachtet werden. Die Entwicklung der Software bezieht sich auf Zweierlei: einerseits auf die Entwicklung der Datenbank und andererseits auf die Anwendungsprogrammierung. Diese Diplomarbeit beschreibt die verschiedenen Entwicklungsstufen und bildet zusammen mit den Anhängen die Entwicklungs- und Systemdokumentation.
1.1 Aufbau der Diplomarbeit
Im Anschluß an diese Einführung befaßt sich das zweite Kapitel mit der Planung der Softwareentwicklung. Dabei werden stets theoretische Ausarbeitungen mit der praktischen Entwicklungsarbeit in Zusammenhang gebracht. Im ersten Teil dieses Kapitels sollen verschiedene Phasenmodelle der Softwareentwicklung dargestellt werden, um diesen die realisierten Phasen der Entwicklung gegenüberzustellen. In den darauffolgenden Teilen des zweiten Kapitels soll erläutert werden, wie aus einer Problemerkenntnis ein detailliertes Sollkonzept entsteht. In diesem Zusammenhang wird eine Problemstellung herausgearbeitet, welche die Entwicklung eines Klausurorganisationssystems begründet. Dazu wird der Prozeß Klausurorganisation näher untersucht und eine Struktur erarbeitet, die Grundlage für die Entscheidung über die zum Einsatz kommende Entwicklungssoftware ist. Im fünften und letzten Teil des zweiten Kapitels wird das Sollkonzept und dessen Entstehung ausführlich erörtert. Dieses Sollkonzept besteht aus einer verbalen Beschreibung der Softwareanforderungen, der Darstellung des Sollprozesses sowie der Darstellung des Datenbankentwurfs.
Das dritte Kapitel befaßt sich mit der eigentlichen Entwicklung des Klausurorganisations-systems. Dazu wird im ersten Teil das Datenbankmanagementsystem Microsoft Access 97 vorgestellt, welches die Entwicklungsumgebung liefert. Darauf aufbauend soll im zweiten Teil, in enger Anbindung an den Datenbankentwurf des Sollkonzepts, die Definition des relationalen Datenmodells erfolgen. Dieses Datenmodell ist Grundlage für die Funktionsentwicklung, wie sie im dritten Teil dieses Kapitels dargestellt wird. Dieser Teil gliedert sich in die Erläuterung des Konzeptes der Menü- und Dialogsteuerung und in die Beschreibung der Programmierung der Funktionen anhand eines Beispiels.
Letztlich soll das vierte Kapitel Aufschluß über die Grundlagen von Softwaretests und Softwareeinführungen geben, um die Testphase des Klausurorganisationssystems beschreiben sowie Maßnahmen zur Systemeinführung nennen zu können.
1.2 Ziel der Arbeit
Diese Diplomarbeit soll die praktische Softwareentwicklungstätigkeit dokumentieren und dabei den Bezug zu theoretischen Modellen, wie Phasenmodellen, Datenmodellen oder Prozeßkettendiagrammen herstellen. Dabei sollen Problembereiche, die sich aus diesem Bezug ergeben aufgezeigt werden. Der Anhang A, das Handbuch des Klausurorganisationssystems, dient dem Anwender als Nachschlagewerk im Rahmen der Benutzung des Systems. Nicht zuletzt soll die Arbeit zur Weiterentwicklung des Klausurorganisationssystems animieren, denn mit dem Vorliegen der aktuellen Version kann die Entwicklung, aus Sicht des Autors keineswegs als abgeschlossen betrachtet werden. Hierzu können die Objektdefinitionen, die dem Anhang B zu entnehmen sind, dienlich sein. Die Hauptsache der Entwicklung liegt jedoch in dem Vorliegen eines Systems, das die Klausurorganisationstätigkeiten erheblich vereinfachen kann, wie diese Arbeit zeigen wird.
2 Entwicklungsplanung
Planung dient dem Zweck, eine Ereignis- und Aktionsabfolge festzulegen, die von einem Istzustand zu einem gewünschten Sollzustand führt. Dabei bezeichnet der Istzustand eine Ausgangssituation, die in der Gegenwart liegt und der Sollzustand ein bestimmtes Ziel, das in der Zukunft liegt. Unter einem Plan kann somit eine definierte Abfolge von Ereignissen und Aktionen zur Erreichung eines gewünschten, zukünftigen Zustands verstanden werden. Die Erfordernis zur Planung ergibt sich aus einem, als unbefriedigend empfundenen Istzustand. Das Ziel der Planung ist somit eine Zustandsverbesserung. Bezogen auf die Softwareentwicklungsplanung bedeutet dies, daß ein Istzustand durch den Einsatz oder der Veränderung einer Software verbessert werden soll. Dabei bezieht sich die Planung auf folgende Bereiche:
- Analyse des Prozesses, der durch den Einsatz einer Software zu verändern ist.
- Planung des Softwareentwicklungsprozesses.
- Projektmanagement
Diese Bereiche können zusammenfassend als Software-Engineering bezeichnet werden. Nach Denert[1] besteht Software-Engineering aus dem Softwareentwicklungsprozeß sowie aus dem Projektmanagement, wobei letzteres Planen, Kontrollieren und Verwalten, vor allem aber Führen und Koordinieren aller Beteiligten bedeute. Etwas weiter faßt Zilahi-Szabó den Begriff: "Die Disziplin Software-Engineering umfaßt (...) den Gesamtprozess der Systemanalyse, -entwicklung und -nutzung."[2]
Die Planung von Softwareentwicklungen kann je nach Projektumfang unterschiedliche Ausmaße annehmen. Dabei können Fragen des Budgets, des einzusetzenden Personals oder des Zeitrahmens in Abhängigkeit von der Zielsetzung, mit unterschiedlicher Gewichtung in die Projektplanung eingehen. Die Entwicklungsplanung des Klausurorganisationssystems bezieht sich zum einen auf den zu optimierenden Prozeß Klausurorganisation und zum anderen auf den Gesamtprozeß der Softwareentwicklung. Ein Projektmanagement kam aus folgenden Gründen nicht in Betracht:
- Das Projekt wurde nur durch eine Person bearbeitet.
- Die Entwicklung verursachte der Fachhochschule keine Prozeß- oder Zusatzkosten und unterlag somit keinen Budgetrestriktionen.
Zusammenfassend kann die Entwicklungsplanung in die Bereiche Planung der Vorgehensweise anhand von Phasenmodellen sowie der Problemanalyse und Sollkonzeptentwicklung geteilt werden.
2.1 Phasenkonzeption
Das Konzept der Entwicklungsphasen spielt in der Softwareentwicklung eine große Rolle. In der Literatur wird eine nahezu unüberschaubare Vielfalt an Phasenmodellen diskutiert. An dieser Stelle sei ein kleiner Überblick der verschiedenen Modelle gegeben, um im folgenden die Phasen der Klausurorganisationssystementwicklung zu erläutern.
2.1.1 Phasenmodelle
Lineare Phasenmodelle kennzeichnen sich durch Ihren, nach vorn gewandten Ablauf der Phasen aus, wobei eine Phase erst beginnt, wenn die vorhergehende vollständig abgearbeitet wurde. Die Abschnitte gliedern sich nach Stahlknecht[3] in die Grundphasen:
- Systemanalyse,
- Systementwicklung,
- Systemeinführung und
- Systempflege.
Diese Grundphasen werden durch unterschiedliche Gewichtung auf die Phasen in verschiedenster Art verfeinert. So bezeichnet Eberleh[4] die folgenden Phasen als typisch:
- Planung,
- Analyse,
- Design,
- Programmierung,
- Installation und Test sowie
- Betrieb und Wartung
Weiterentwicklungen des linearen Phasenmodells resultieren aus der Frage, ob von einer Phase in eine vorangegangene zurückgesprungen werden darf. Bei einer sequentiellen "Abarbeitung" der Phasen werden ggf. Fehler, die in einer der ersten Phasen gemacht werden, bis in die Letzte mitgezogen. Aus diesem Dilemma entstand das sogenannte Wasserfallmodell mit Rückkopplung nach Boehm[5].
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1 Wasserfallmodell mit Rückkopplung nach Boehm[6]
Dieses Modell soll ein frühstmögliches Aufspüren von Fehlern ermöglichen und deren Beseitigung in derjenigen Phase gewährleisten, in welcher sie aufgetreten sind. Als besonderen Nachteil empfand Boehm selbst, daß in frühen Phasen des Projekts der Gesamtumfang nicht oder nur schwer überschaubar ist mit der Folge, daß z.B. erst bei der Codierung klar wird, daß das Projekt u.U. nicht realisierbar ist. Somit schlug Boehm das sogenannte Spiralmodell vor. Bei diesem Modell werden vier Phasen der Softwareentwicklung mehrfach durchlaufen, wobei angestrebt wird, möglichst früh Prototypen vorliegen zu haben, die bewertet werden können. Anhand dieser Bewertung wird entschieden, ob eine Weiterentwicklung des Projekts bzw. von Projektteilen lohnt oder nicht.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2 Spiralmodell nach Boehm[7]
Das Spiralmodell wurde im Laufe der Zeit verschiedentlich modifiziert und weiterentwickelt.
Letztlich sei das Prototyping als Vorgehensmodell erwähnt. Hier geht es darum, möglichst schnell ein ablauffähiges Programm zu erstellen, an dem die Eigenschaften des Produkts untersucht werden können. Aus dieser Untersuchung ergeben sich die Anforderungen, die in das Endprodukt eingehen sollen. Insofern kann die Prototyperstellung als besonderes Hilfsmittel der Systemanalyse verstanden werden, obgleich der Prototyp in alle Entwicklungsphasen einfließt, wie Abbildung 3 zeigt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3 Prototyping - Modell[8]
2.1.2 Realisierte Phasen der Softwareentwicklung
Im vorangegangenem Kapitel wurden einige Phasenmodelle erwähnt und kurz beschrieben. Nun geht es darum, die Entwicklungsphasen der Klausurorganisationssystementwicklung aufzuzeigen. Die Entwicklung des Klausurorganisationssystems war durch eine lange Entwicklungszeit geprägt, in der sich Anforderungen und Aufgabenstellungen verändert haben. Gestartet wurde die Entwicklung im Rahmen einer Projektarbeit, betreut von Dr. Unterstein der Fachkonferenz Informatik, des Fachbereichs Wirtschaft im Wintersemester 96/97. Die Aufgabenstellung bezog sich zunächst auf die Auslotung von technischen Möglichkeiten zur Datenübernahme aus dem Rechner der Fachhochschulverwaltung, zur Weiterbearbeitung in einer Tabellenkalkulations- oder Datenbankanwendung. Dabei ging es um diejenigen Daten, die zur Organisation der Fachprüfung Datenverarbeitung I, relevant waren. In diesem Zusammenhang war ein Konzept und eine Anwendung für die Automatisierung von Organisationstätigkeiten wie Raum- und Sitzplanung oder Notenberechnungen zu erarbeiteten. Dazu wurde eine Microsoft Access Datenbankanwendung entwickelt, die diese Funktionen zur Verfügung stellte. Anhand dieser Datenbankanwendung konnten neue Anforderungen an das System definiert werden, welche wiederum umgesetzt wurden. Schließlich war die Projektarbeit abgeschlossen und das Klausurorganisationssystem sollte im Rahmen dieser Diplomarbeit weiterentwickelt werden. Die Betreuung fand nun durch Prof. Dr. Großmann statt. Dieser personelle Wechsel zog wiederum einen Wechsel der Anforderungen nach sich. So sollte sich z.B. die Anwendung nicht nur auf eine bestimmte Fachprüfung beziehen, sondern die Organisation beliebiger Fachprüfungen durch beliebige Prüfer ermöglichen. Somit wurde das gesamte Konzept überarbeitet.
Diese Beschreibung der verschiedenen Entwicklungsstufen lassen einen Vergleich zum Spiralmodell oder zum Prototyping zu. In der Tat lagen schon mehrere Versionen des Klausurorganisationssystems vor, welche als Prototypen bezeichnet werden können. Die folgende Abbildung stellt die Entwicklungsphasen der Systemprototypen dar:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 4 Entwicklungsphasen des Klausurorganisationssystems
Die Abbildung stellt die Entwicklungsphasen der Prototypen des Klausurorganisationssystems dar, wobei es jedoch noch nicht zu einer Systemeinführung gekommen ist. Der graue Balken in der Zeile Systemeinführung soll andeuten, daß das System noch einzuführen ist (vgl.: Kapitel 4, Seite 47).
Im folgenden sollen nicht die einzelnen Phasen der Entwicklung jeder Version erläutert werden. Es wird vielmehr von der Entwicklung des Klausurorganisationssystems in der aktuellen Version ausgegangen. Dabei fließen die Ergebnisse der Vorversionen in die Beschreibungen der Phasen mit ein.
2.2 Vom Problem zum Sollkonzept
Ausgangspunkt aller Tätigkeiten im Rahmen der Entwicklung von Individualsoftware, ist ein unbefriedigender Zustand. Seitens der betroffenen Person kommt der Wunsch auf, diesen Zustand zu verändern. Diese Phase stellt das Erkennen eines Problems dar. Das bedeutet nicht, das es bereits eine konkrete Beschreibung des Problems geben muß. In den meisten Fällen herrscht vielmehr das Gefühl vor: "Hier ist etwas nicht in Ordnung!", oder "Kann man das nicht besser machen?", wobei jedoch die Erkenntnis besteht, daß der Einsatz einer Software den Prozeß zum Positiven verändern könnte. In diesem Fall kann zur Problemanalyse eine außenstehende Person, ein Softwareentwickler hinzugezogen werden. Sie wird in enger Zusammenarbeit mit dem Anwender eine Istaufnahme vornehmen um Schwachstellen aufzuzeigen und erste Lösungsansätze entwickeln. Das Ergebnis dieser Phase ist eine grobe Sollstruktur, welche eine Sollprozeßbeschreibung und die daraus entwickelten Systemanforderungen dokumentiert. Diese Dokumentation der Lösungsalternativen sei als feine Sollstruktur bezeichnet, die dem Anwender als unabdingbare Entscheidungsunterlage dient. Erst nach Auswahl der, aus Sicht des Anwenders, besten Alternative kann diese näher konkretisiert werden. Das bedeutet die Erweiterung der feinen Sollstruktur, um den Bezug zu einer konkreten Software, zum Sollkonzept. Das Sollkonzept ist somit keine Aufzählung von Möglichkeiten mehr, sondern eine Auswahl aus diesen und deren konkrete Beschreibung, z.B. in einem Pflichtenheft.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 5 Prozeß der Sollkonzeptentwicklung
Diese Abbildung stellt den Prozeß der Sollkonzeptentwicklung modellhaft dar. In der Realität wird es Abweichungen in unterschiedlichen Ausprägungen geben. Dies kann vom Umfang des Projekts, von der Art der Beziehung der Beteiligten zueinander oder anderen Faktoren abhängen. So war die Sollkonzeptentwicklung des Klausurorganisationssystems durch die Professor (Anwender) - Student (Entwickler) - Beziehung und der Tatsache der nicht anfallenden Kosten geprägt.
2.3 Problemstellung
2.3.1 Der Prozeß Klausurorganisation
Vor der Analyse des Klausurorganisationsprozesses, seien die im folgenden verwandten Begriffe erläutert:
Eine Klausur ist eine Zusammenfassung für die Fachprüfungen, die fachlich, terminlich und organisatorisch eine Einheit bilden. Eine Fachprüfung bezieht sich auf ein bestimmtes Fach eines Studiengangs mit der entsprechenden Version der Studienordnung. Des weiteren können Fächer in Lehreinheiten unterteilt sein. Dementsprechend werden Lehreinheiten den Fachprüfungen zugeordnet. Sie stellen in diesem Zusammenhang einen Teil der Fachprüfung dar, welche durch verschiedene Personen gestellt und korrigiert werden. Diese Personen seien als Prüfer bezeichnet. Derjenige Prüfer, der für die Organisation der gesamten Klausur verantwortlich ist, sei als Hauptprüfer bezeichnet. Die folgende Abbildung faßt diese Begriffe beispielhaft zusammen:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 6 Klausurstruktur
Wie die Abbildung zeigt, muß nicht jede Lehreinheit jeder Fachprüfung zugeordnet sein. So ist z.B. die Lehreinheit x nicht der Fachprüfung, Studiengang 1, Studienordnung A zugeordnet. Andererseits muß jedoch jede Fachprüfung zumindest aus einer Lehreinheit bestehen.
Der Vollständigkeit halber sei erwähnt, daß die starre Zuordnung des Prüfers zur Lehreinheit nicht korrekt ist. Denn es sind Konstellationen möglich, bei der eine Lehreinheit durch verschiedene Prüfer, in Abhängigkeit von der Fachprüfung, geprüft wird. Dementsprechend müßte sich die Zuordnung des Prüfers auf die Verbindung von Lehreinheit zu Fachprüfung beziehen. Dieser Fall wird später berücksichtigt, aufgrund der Darstellbarkeit jedoch an dieser Stelle ausgespart.
Eine Analyse des Geschäftsprozesses Klausurorganisation des Fachbereichs Wirtschaft erfolgte durch Befragungen, z.B. von Dozenten oder Angestellten des Prüfungsamtes und durch Beobachtungen. Das Ergebnis der Analyse ist die Darstellung des Prozesses in Form eines Ereignisprozeßkettendiagramms nach der ARIS-Methode[9]. Das hier dargestellte Diagramm beschreibt die Klausurorganisation im eigentlichen Sinne (i.e.S.)[10]. Diese bezieht sich auf die Organisationstätigkeiten des Hauptprüfers:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 7 Der Prozeß Klausurorganisation i.e.S.
Die durch das Prüfungsamt erstellten Zulassungslisten werden an die jeweiligen Hauptprüfer weitergereicht. Dieses Ereignis ist für den Hauptprüfer das Signal für den Start der Klausurorganisation. Ferner erhält der Hauptprüfer einen Prüfungsplan.
Die Zulassungslisten beziehen sich jeweils auf eine Fachprüfung, und somit auf den Studiengang und der entsprechenden Studienordnung. Eine Zulassungsliste hat folgende Struktur.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 8 Struktur der Zulassungsliste
Zusätzlich steht dem Hauptprüfer der Prüfungsplan, ebenfalls in Form einer Liste zur Verfügung. Der Prüfungsplan ist gruppiert nach Studiengang, Studienordnung und dem Kriterium "Grund- oder Hauptstudiumsklausur". Innerhalb dieser Gruppierung sind alle Fachprüfungen des Fachbereichs aufgeführt, mit folgenden Angaben:
Fachnummer, Fachbezeichnung, Gewichtung, Reguläres Semester, Tag der Prüfung, Uhrzeit, Dauer in Minuten, Form, Anzahl der Meldungen, Prüfer und Raum/Aufsicht.
Zusätzlich stehen dem Hauptprüfer Informationen über die Räumkapazitäten und über Notenschemata zur Verfügung. Ein Notenschema ist Grundlage für die Bewertung einer Klausur. Es gibt an, in welchen Ergebnisbereichen, welche Note zu vergeben ist. Dem Hauptprüfer ist die Variation des Schemas jedoch freigestellt.
Der Hauptprüfer greift bei der Klausurorganisation auf die ihm, in Form von Papierlisten zur Verfügung stehenden Daten zu. Auf eine detaillierte Beschreibung der Teilprozesse der Klausurorganisation wird an dieser Stelle bewußt verzichtet, da jeder Hauptprüfer bei der Bearbeitung eine eigene Vorgehensweise hat, so daß viele verschiedene Verfahren denkbar sind und angewandt werden. So werden z.B. die Zulassungslisten kopiert und verschiedentlich weiterbearbeitet oder es kommen Computerprogramme zum Einsatz, wobei die erforderlichen Daten erst eingegeben werden müssen.
Klausurvorbereitung
Zur Vorbereitung der Klausur durch den Hauptprüfer gehören die folgenden Aufgaben:
Raum- und Sitzplanung
Die Raum- und Sitzplanung hat den Zweck Listen zu erstellen, denen der Student am Tag der Prüfung die Raum- und Sitzordnung entnehmen kann.
Punktelistenerstellung
Die Punktelisten dienen dem Prüfer, um die erreichten Teilpunkte je Student notieren zu können. Die ausgefüllten Listen werden an den Hauptprüfer zurückgegeben.
Klausurbewertung
Die Klausurbewertung umfaßt die Sammlung der Teilpunkte und deren Addition. Die berechneten Gesamtpunkte müssen ggf. ins Verhältnis zu den maximal erreichbaren Punkten gesetzt werden um ein relatives Ergebnis zu ermitteln. Über dieses Ergebnis kann der Hauptprüfer in Verbindung mit dem Notenschema, jedem Kandidaten eine Note zuweisen.
Notenlistenerstellung
Die im Rahmen der Klausurbewertung ermittelten Noten müssen in die Zulassungslisten übertragen werden. Danach gibt der Hauptprüfer diese Listen, nunmehr als Notenlisten, zurück an das Prüfungsamt.
2.3.2 Prozeßkettenanalyse und Problembeschreibung
Bei der Analyse des Prozesses geht es um die Bewertung der ermittelten Istdaten in bezug auf Schwachstellen und Problembereiche. Dazu ist es erforderlich, den Prozeß Klausurorganisation auf angrenzende Prozesse zu erweitern. Der Gesamtprozeß sei in der folgenden Abbildung dargestellt:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 9 Der Prozeß Klausurorganisation im Kontext
Der Kontext zeigt auf, daß das Prüfungsamt direkten Zugriff auf die Datenbank des Rechners der Fachhochschulverwaltung hat, welcher gemeinhin als Pluto bezeichnet wird. Aus dieser Datenbank werden alle Listen, die den Hauptprüfern zukommen, erzeugt. Damit wird das ursächliche Problem sofort deutlich. Der Hauptprüfer verfügt über die Daten nur in Form von Papierlisten, obgleich alle Daten EDV-technisch gespeichert sind. Aus diesem Umstand folgt, daß es für die Bearbeitung der vielfältigen Aufgaben des Hauptprüfers keine vordefinierten Funktionen gibt, die mit Hilfe der EDV z.B. Listen erstellen oder Berechnungen durchführen. Die Bearbeitung der Listen "von Hand" sowie die Erfassung von Teilpunkten auf verschiedenen Listen, bergen nicht nur ein hohes Fehlerpotential, sondern sind auch sehr mühsame Tätigkeiten bei der Ergebnisermittlung.
2.3.3 Sollstruktur
Aus der Problemerkenntnis und -analyse, kann nun eine erste grobe Sollstruktur abgeleitet werden:
I Datenverfügbarkeit
Die klausurrelevanten Informationen sollten dem Hauptprüfer nicht nur auf Papierdokumenten zur Verfügung gestellt werden. Er sollte Daten aus Pluto abrufen können oder die Daten sollten ihm in einer elektronisch verarbeitbaren Form vorgelegt werden. Dies ist Voraussetzung für den Einsatz eines Klausurorganisationssystems.
II Funktionsumfang
Der Funktionsumfang soll den Bereich der Klausurorganisation i.e.S. vollständig unterstützen. Aus der Prozeßanalyse ergeben sich somit folgende Anforderungen an die Funktionalität der Software:
II.1 Klausurvorbereitung
II.1.a Automatische Erstellung der Raum- und Sitzplanung sowie Generierung der entsprechenden Listen.
II.1.b Generierung von Punktelisten für die Prüfer der Lehreinheiten oder Ermöglichung der direkten Erfassung der Teilpunkte durch die Prüfer.
II.2 Klausurbewertung
II.2.a Automatische Addition der Teilpunkte sowie Ermittlung des relativen Ergebnisses je Kandidat.
II.2.b Automatische Zuweisung von Noten auf Basis des relativen Ergebnisses in Verbindung mit dem Notenschema.
II.2.c Generierung von Notenlisten, die an das Prüfungsamt weitergeleitet werden können.
III Softwarequalität
Die Anwendung sollte den Grundsätzen der Softwarequalität entsprechen. Darunter sind Eigenschaften des Systems zu verstehen, die sich einerseits im Rahmen der Benutzerakzeptanz auf die Effizienz, Effektivität und die Zuverlässigkeit beziehen und andererseits im Rahmen der Ausbaufähigkeit auf die Wartungsfreundlichkeit, Anpassungsfähigkeit und die Maschinenabhängigkeit.[11]
III.1 Benutzungsfreundlichkeit
III.1.a Der Benutzer sollte in jeder Phase der Klausurorganisation durch einen selbsterklärenden Bildschirmaufbau, durch aussagekräftige Dialoggestaltung sowie durch eine Menüführung vom Klausurorganisationssystem unterstützt werden.
III.1.b Dem System sollte eine umfassende Online-Hilfe beigefügt sein, über die der Benutzer zu jeder Zeit, z.B. über eine Stichwortsuche, Hilfestellung erhält.
III.1.c Die Anwendung sollte mehrbenutzerfähig sein. Dadurch können Datenbestände redundanzfrei gehalten werden und der Datenpflegedienst wird, mit dem Ziel den Benutzer von diesen Aufgaben möglichst freizuhalten, zentralisiert.
III.2 Zuverlässigkeit
III.2.a Die Korrektheit der Ergebnisse von Berechnungen, Datenmanipulationen muß gewährleistet sein.
III.2.b Alle in 3.2.1. genannten Ergebnisse sollten prüfbar und nachvollziehbar sein.
III.2.c Das System sollte Bedienungsfehler frühzeitig erkennen und abweisen können, also robust sein.
III.2.d Daten sollten vor Verlust oder Beschädigung, z.B. bei Systemabsturz oder ungewollter Anwendungsbeendigung geschützt sein.
III.2.e Das System soll die Eingabe unzulässiger Werte z.B. in Form von falschen Datentypen oder Überschreitungen zulässiger Wertebereiche verhindern können.
III.3 Funktionserfüllung
Die Funktionen müssen geeignet sein, die Aufgaben erwartungsgerecht auszuführen. Das Funktionsergebnis muß somit mit der Erwartungshaltung des Anwenders übereinstimmen.
III.4 Wartungsfreundlichkeit
III.4.a Anforderungen, die sich im Laufe der Zeit verändern, sollten leicht in das System integriert werden können. Dies betrifft die Hinzufügung neuer Funktionen ebenso, wie die Änderung oder Entfernung bestehender Funktionen.
III.4.b Die Datenstrukturen des Klausurorganisationssystems sind abhängig von den Strukturen der Daten, die zur Verfügung gestellt werden. Auf diesbezügliche Veränderungen sollte das System flexibel reagieren können.
Diese grobe Sollstruktur gilt es im nächsten Schritt zu verfeinern. Dazu sind konkrete Lösungsalternativen zu entwickeln, die den genannten Anforderungen gerecht werden.
2.4 Lösungsalternativen und Entscheidung
Die Entwicklung von Lösungsalternativen hat eine Aufstellung konkreter Lösungsvorschläge zum Ziel (vgl.: Abschnitt 2.2). Aufgrund der groben Sollstruktur ist zunächst die Art der Datenverfügbarkeit näher zu untersuchen, da diese die Softwareauswahl wesentlich beeinflußt. Diese Untersuchung erfolgt schemenhaft und unter Ausschluß von technischen Details.
Abruf der Daten aus Pluto durch den Hauptprüfer
Bei der Datenbank des Pluto-Rechners der Fachhochschulverwaltung, handelt es sich um das relationale Datenbanksystem INFORMIX auf einer Unix-Umgebung. Grundsätzlich ist ein Zugriff auf die Datenbank mit Hilfe geeigneter Datenfernübertragungssoftware möglich. Voraussetzung ist eine exakte Definition und Pflege der Zugriffsrechte durch die Systemadministration. Zu Unterscheiden sind einerseits die Zugriffsrechte auf den Unix-Rechner und andererseits die Abfragerechte innerhalb der INFORMIX-Datenbank. Das bedeutet, daß alle Hauptprüfer sowohl als Anwender des Unixsystems als auch als Anwender der Datenbank zu pflegen sind. Möglich ist eine Steuerung der Zugriffsrechte über die Dozentenkennung. Diese ist in der Datenbank im Feld "dozent" der Tabelle Fachprüfung bereits hinterlegt. Voraussetzung für die Nutzung dieser Kennung ist jedoch dessen ständige Aktualität. Ein Schema dieses Ablaufs stellt die folgende Abbildung dar:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 10 Abruf der Daten aus Pluto
Vorlegen der Daten in elektronisch verarbeitbarer Form
Die Alternative zum Direktzugriff ist das Erstellen der Zulassungslisten, sowohl durch Ausdruck auf Papier wie auch durch Erstellen einer Datei. Diese Datei kann, z.B. auf einer Diskette, zusammen mit den Papierlisten an die Hauptprüfer gegeben werden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 11 Weitergabe der Daten auf Diskette
Bewertung der Alternativen
Ein Direktzugriff auf die sensiblen Daten der Fachhochschule per DFÜ durch die Hauptprüfer, ist rechtlich aus Datenschutz- und aus Datensicherheitsgründen nicht unproblematisch. Unter Datenschutz ist der Schutz personenbezogener Daten vor unberechtigtem Lesen, Vervielfältigen oder Weitergeben zu verstehen. Die Datensicherheit bezieht sich auf unberechtigtes Ändern oder Löschen von Daten aller Art. Ein weiteres Problem stellt die Aktualität der Dozentenkennung dar. Die Erfahrung hat gezeigt, daß dieses Feld entweder gar nicht oder mangelhaft gepflegt wird. Hier wären also zusätzlich personelle Maßnahmen erforderlich. Ein Zugriff auf Pluto müßte aufgrund der Anforderung der leichten Bedienbarkeit derart entwickelt werden, daß der Anwender letztlich gar nicht bemerkt, daß er auf die Daten eines entfernten Rechners zugreift. Somit ist schließlich zu beachten, daß diese Version nur durch einen erheblichen technischen und administrativen Aufwand zu realisieren ist. Die Frage des Datenschutzes tritt auch bei der zweiten Alternative auf, denn hier werden personenbezogene Daten auf einen Datenträger kopiert, weitergegeben und im Klausurorganisationssystem gehalten und weiterbearbeitet. Daher ist einerseits der Datenträger besonders zu schützen und andererseits eine Regelung über die Haltung und Verarbeitung der Daten im Klausurorganisationssystem zu treffen. Ferner ist eine Regelung zu vereinbaren, welche die Administration der Informix Datenbank veranläßt, die Zulassungslisten nicht nur auszudrucken, sondern auch auf einer Diskette zu speichern und weiterzugeben. Andererseits entfällt bei dieser Alternative die Datensicherheitsproblematik und der hohe Entwicklungs- und Pflegeaufwand. Eine Gegenüberstellung der Alternativen, erlaubt aufgrund der Einfachheit der Realisierung, eine Entscheidung zu Gunsten der zweiten Alternative.
Lösungsalternativen
Bei der Erarbeitung der Lösungsalternativen stellt sich zunächst die Frage, mit welcher Entwicklungssoftware die entsprechenden Funktionen am ehesten erstellt werden können. Zur Disposition sei die Entwicklung einer Datenbankanwendung, einer Tabellenkalkulations-anwendung oder einer eigenständigen Software mit einer Programmiersprache gestellt.
1.) Datenbankanwendung
Nach ZILAHI-SZABÓ ist unter einer Datenbank die systematische Sammlung von Datenbeständen zu verstehen, die durch ein Datenverwaltungssystem verwaltet und über ein Datenzugriffssystem mehreren Benutzern für beliebige Anwendungen zur Verfügung stehen.[12] Somit kann unter einer Datenbankanwendung eine Software verstanden werden, die sich die Eigenschaften von Datenbanksystemen zunutze macht.
2.) Tabellenkalkulationsanwendung
Eine Tabellenkalkulationssoftware ermöglicht die Speicherung von Daten in Form von Tabellen. Der wesentliche Unterschied dieser Tabellen zu Datenbanktabellen liegt in der Beziehung der Tabellenfelder zueinander. Eine Zeile einer Datenbanktabelle stellt stets einen zusammengehörenden Datensatz dar. Dies ist bei Kalkulationstabellen nicht der Fall. Die Felder einer Kalkulationstabelle haben somit keinen unmittelbaren Bezug zueinander. Es besteht die Möglichkeit, Formeln, Ausdrücke oder Funktionen in Tabellenfeldern zu hinterlegen, die sich wiederum auf andere Felder beziehen. Dadurch können umfangreiche Berechnungen automatisiert werden.
3.) Erstellung einer eigenständigen Software mit einer Programmiersprache
Durch die Erstellung einer Softwareanwendung, ohne Rückgriff auf ein Datenbank- oder Tabellenkalkulationssystem, z.B. mit C oder Visual Basic, ist eine Unabhängigkeit von den Entwicklungswerkzeugen des zugrundeliegenden Systems gegeben und eine eigene Definition der Datenstrukturen und Speichermethoden möglich.
Zur Ermöglichung einer Auswahl des geeignetsten Entwicklungssystems, seien die Alternativen in bezug auf die Systemanforderungen bewertet. Dazu werden in einem ersten Schritt die Anforderungen nach Ihrer Bedeutung im Gesamtzusammenhang gewichtet. Die Gewichtung erfolgt durch die Vergabe eines Faktors zwischen Null (= keine Bedeutung) und Eins (= unabdingbar erforderlich). Da jeder potentielle Benutzer unterschiedlichen Wert auf einzelne Funktionen legen wird, ist die Faktorvergabe eher subjektiv zu beurteilen.
In einem zweiten Schritt wird die Brauchbarkeit des Entwicklungssystems in bezug auf die Funktion bewertet. Als Maßstab gilt dabei die Höhe des Aufwandes, der vermutlich erforderlich ist, die Funktion zu entwickeln. Dazu wird eine Zahl zwischen Null (= unbrauchbar) und Zehn (= sehr brauchbar) vergeben. Dieser Wert wird mit dem Gewichtungsfaktor multipliziert, um die Brauchbarkeit mit der Bedeutung zu relativieren.
Letztlich werden die gewichteten Bewertungen addiert, um einen Vergleich der Systeme vornehmen zu können. Abbildung 12 stellt das Ergebnis der Bewertung zusammen. Sie zeigt folgende Besonderheiten auf:
Dem Anspruch der Mehrbenutzerfähigkeit wird eine Tabellenkalkulationssoftware nicht gerecht. Theoretisch ist eine gemeinsame Benutzung von Daten und Funktionen, z.B. durch Kopieren und Weitergeben der Dateien oder Anlegen einzelner Arbeitsmappen pro Benutzer denkbar, aber entweder werden die Daten nicht redundanzfrei gehalten oder es ist kein simultaner Zugriff auf die Daten möglich.
Im Rahmen der Verfügbarkeit der Software wurden Produkte benannt, die dem Fachbereich Wirtschaft unmittelbar zur Verfügung stehen, d.h. bereits im Netzwerk installiert sind. Zu unterscheiden ist des weiteren die Verfügbarkeit eines Datenbank- oder Tabellenkalkulations-systems, von der einer Programmiersprache. Letztere muß nur dem Entwickler zur Verfügung stehen, um anschließend die entwickelte Software dem Benutzer bereitzustellen, während dem Benutzer bei Anwendung eines Datenbank- oder Tabellenkalkulationssystems auch dieses zur Verfügung gestellt werden muß.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 12 Bewertung der Entwicklungssysteme
Nach dieser Bewertung scheint ein Datenbanksystem für die Entwicklung des Klausurorganisationssystems am geeignetsten. Weitere Vorteile von Datenbanksystemen stellt Walter heraus: "Der Vorteil der Datenbanksysteme liegt darin, daß sehr schnell einfache Dialoganwendungen entwickelt werden können und daß umfangreiche Auswertungs-möglichkeiten von Datenbeständen zu Verfügung stehen. Der Nachteil liegt darin, daß das entwickelte System stets abhängig ist vom Datenbanksystem und der darin verwendeten Speicherungsstruktur sowie der speziellen Programmiersprache des Herstellers."[13] Dieser Nachteil entfiele durch die Entwicklung einer eigenständigen Software mit einer Programmiersprache, was wegen des wesentlich höheren Entwicklungsaufwands jedoch nicht zu rechtfertigen wäre.
Somit blieben als Lösungsalternativen die Datenbanksysteme Oracle und Microsoft Access, wenn man von der Installation weiterer Datenbanksysteme absehen will. Microsoft Access soll jedoch, aufgrund des Bekanntheitsgrades und der Verfügbarkeit durch das Microsoft Office 97 - Paket, das auf allen Client-Rechnern des Fachbereichs installiert ist, den Vorzug erhalten.
[...]
[1] Vgl.: [Denert], Seite 13
[2] So: [Zilahi-Szabó], Seite 293
[3] Vgl.: [Stahlknecht], Seite 220
[4] Vgl.: [Eberleh], Seite 350
[5] Vgl.: [Boehm], Seite 494ff.
[6] entnommen aus [Boehm], Seite 495
[7] Vgl.: [Balzert], Seite 129ff.
[8] entnommen aus [Chroust], Seite 165
[9] Vgl.: [Scheer98], Seite 20ff.
[10] Vgl.: Anhang A: "Klausurorganisationssystem, Handbuch", Seite 1ff.
[11] Vgl.: [Chroust], Seite 200
[12] Vgl.: [Zilahi-Szabó], Seite 268
[13] Vgl.: [Walter], Seite 239