Version: 1.1 Datum: 22.05.09-1 -
Inhaltsverzeichnis 1. Zielbestimmung...3 1.1 Kurzbeschreibung...3 1.1 Muss Kriterien...3 1.2 Kann Kriterien...3 1.3 Abgrenzungskriterien...3 2. Produkteinsatz...4 2.1 Anwendungsbereiche...4 2.2 Zielgruppen...4 2.3 Betriebsbedingungen...4 2.4 Technische Produktumgebung...4 2.4.1 Software...4 2.4.2 Hardware...4 2.4.2.1 Client...4 2.4.2.2 Server...4 2.4.3 Orgware...4 2.5 Produkt-Schnittstellen...5 3. Produktübersicht...5 4. Produktfunktionen...6 4.1. Authentifizierung...7 4.1.1 Login // AF01...7 4.1.2 Logout // AF02...7 4.1.3 Registrieren // AF03...7 4.1.4 Sperren // AF04...7 4.2 Administration // AF05...8 4.3 Raumnr. Ergänzen // AF06...8 4.4 Klausurtermin ändern // AF07 / Klausurtermin festlegen // AF08...8 4.5 Klausurtermin Abfrage // AF09...8 5. Benutzerschnittstelle...9 6. Daten...10 6.1 Account...10 6.2 Kursdaten...10 6.3 Klausurtermine...10 7. Qualitätsanforderungen...11 7.1 Technische Qualtitätsanforderungen...11 7.1.1 Zuverlässigkeit...11 7.1.3 Portabilität...11 7.2 Interaktions- und Ergonomieanforderungen...11 7.2.1 Nutzungsschnittstellen...11 7.1.2 Fehlertoleranz...11 7.2.2 Interaktionsleistungen...11 7.2.2.1 Nutzer...11 7.2.2.2 Performanz...11 7.2.2.3 Robustheit...11 7.3 Wirtschaftliche Qualitätsanforderungen...12 7.4 Rechtliche und normative Vorgaben...12 8. Gliederung in Teilprodukte...12 9. Entwicklungs- Konfiguration...12 10. Beschaffungsanforderungen...12 11. Glossar...13-2 -
1. Zielbestimmung 1.1 Kurzbeschreibung Das Projekt soll Dozenten und Studenten helfen eine gute Übersicht über ihre Klausuren zu bieten und die Kommunikation untereinander verbessern. 1.2 Muss Kriterien System muss Administratoren ermöglichen, auf die Datenbank und auf das System zuzugreifen. Raumplanern die Möglichkeit bieten, Raumnummern zu ergänzen. ein öffentlicher und nicht öffentlicher Bereich haben ein Login für Dozenten der BHT bieten. Dozenten die Möglichkeit bieten, Klausurtermine festzulegen. Dozenten die Möglichkeit bieten, Klausurtermine zu ändern. Dozenten und Studenten auf Terminüberschneidungen hinweisen. alle Klausurtermine verwalten Usern ihre Klausurtermine ausgeben. verschiedene Auswahlmasken haben alle Kurs-Daten in der Datenbank vorliegen haben jedes Semester neue Kurs-Daten aufnehmen oder alte aktualisieren. eine grafische Benutzeroberfläche haben immer das Logo anzeigen online verfügbar sein auf Firefox 3 oder höher korrekt angezeigt werden 1.3 Kann Kriterien Login für die Studenten der BHT. Studenten können sich für die Teilnahme an einer Klausur einschreiben. Korrekte Darstellung auf anderen Browsern. Liste der Klausurtermine speichern oder ausdrucken. Erweiterbar auf andere Hochschulen. Login Daten der HRZ-Schnittstelle benutzen. Admin durch Automatisierung entlasten. Mit Kalender erweiterbar. 1.4 Abgrenzungskriterien System muss nicht die Raumplanung übernehmen. unbedingt auf allen Browsern korrekt laufen. auf Handys oder anderen Endgeräten mit kleiner Auflösung korrekt dargestellt werden. die Kommunikation bei Klausurtermin-Überscheidungen übernehmen. - 3 -
2. Produkteinsatz 2.1 Anwendungsbereiche Das System soll von Studenten und Dozenten der BHT aktiv benutzt werden. Bevor das System in den Online-Betrieb geht, muss es erst eine ausreichend geschlossene Testphase absolviert haben. 2.2 Zielgruppen Die Nutzer der Anwendung sind Studenten und Dozenten der BHT, diese brauchen minimale Internet Kenntnisse, damit sie die Anwendung bedienen können. Allgemein liegt die Altersklasse ca. zwischen 20 und 60 Jahren. 2.3 Betriebsbedingungen Der Server und die Datenbank sollten, wenn möglich von überall und rund um die Uhr Online erreichbar sein. Dabei werden außerhalb der Klausuren nicht mehr als 200 Anfragen pro Minute erwartet und zur Klausurenzeit ca. 1000 Anfragen pro Minute. 2.4 Technische Produktumgebung 2.4.1 Software Das System braucht einen Server der MySQL 5 und Apache Tomcat 6 unterstützt und um die Anwendung einwandfrei als User benutzen zu können, benötigt man den Browser von Firefox. 2.4.2 Hardware Der Server braucht im Vergleich zum Client wesentlich mehr Rechenleistung, daher wird Client und Server getrennt behandelt. 2.4.2.1 Client Die Hardware Anforderung des Client ist gering, denn er braucht nur einen PC mit dem man ins Internet kann und der Html Seiten darstellen kann. So einen PC bekommt man für ~150. 2.4.2.2 Server Die Hardware Anforderung des Servers ist schon sehr hoch, denn er muss mehrere und unterschiedliche Abfragen auf die Datenbank verwalten und errechnen, und natürlich muss der Server eine sehr gute Internetanbindung haben. Der Server sollte über einen Core 2 Duo Prozessor mit mindestens 2 GHz, 2 GB Ram sowie über zwei in raid geschaltete 100 GB Festplatten verfügen. So einen Server erhält man für ~ 500-900. So einen Server kann man für ~60-100 / Monat mieten. 2.4.3 Orgware Bei der Installation der Software auf dem Server muss ein Administrator- Benutzerkonto angelegt werden, damit er weitere Benutzer anlegen oder die Software updaten kann. - 4 -
2.5 Produkt-Schnittstellen Die Anwendung wird eine grafische Benutzeroberfläche besitzen, die die Schnittstelle zwischen Benutzer und System bildet. Diese Benutzeroberfläche kann mit Standarteingabe Geräte bedient werden, wie zum Beispiel Maus, Tastatur oder Mauspad. 3. Produktübersicht - 5 -
4. Produktfunktionen Die Benutzeroberfläche vom Klausur- System soll aus XHTML und CSS bestehen. Für die Eingabe der Daten werden übersichtliche Formulare genutzt, damit jeder Anwender diese benutzen kann. - 6 -
4.1. Authentifizierung 4.1.1. Login // AF01 Der Dozent muss sicht gegenüber dem System authentifizieren, damit er die Rechte eines Dozenten nutzen kann Dafür muss der Dozent einen geprüften/ gültigen Account besitzen, und sich damit anmelden. Dabei werden Benutzername und Passwort vom System auf Richtigkeit überprüft und bei Erfolg werden die Rechte eines Dozenten gewährt. Ein Dozent will eine neue Klausur reinstellen, damit er die benötigten Rechte hat, muss er sich vorher einloggen. Ein Dozent will eine Übersicht über seine Klausuren sehen, damit er die Übersicht sehen kann, muss er sich vorher einloggen. 4.1.2 Logout // AF02 Der Logout erfolgt wenn der Eingeloggte für 10 Minuten keine Aktivität zeigt, oder wenn der Eingeloggte sich Manuell ausloggt über den Button Logout. Der Eingeloggte loggt sich aus, wenn er fertig ist, damit nicht andere Personen über seinen PC Klausurtermine ändern, gewollt oder ungewollt. Der Eingeloggte geht schnell was einkaufen und läst seinen PC laufen und vergisst sich auszuloggen. Dann kann es passieren, dass ein Kind oder eine Katze über die Tastatur läuft und bestimmte Termine löscht. Damit das ansatzweise verhindert wird, wird eingeloggt automatisch nach 10 Minuten ausgeloggt. 4.1.3 Registrieren // AF03 Es können sich nur Dozenten Registrieren, dabei muss der Account von einem Admin auf seine Richtigkeit überprüft werden, bevor der Dozent sich damit einloggen kann. Wenn ein Dozent zum ersten Mal die Anwendung benutzt, muss er sich Registrieren. Die Registration muss vor der Benutzung von einem Admin auf seine Richtigkeit überprüft werden. 4.1.4 Sperren // AF04 Wenn sich ein Benutzer 5mal hintereinander, mit einem falschen Passwort anmeldet, wird das Benutzerkonto für die IP 15 Minuten gesperrt. Wenn ein User versucht ein Dozenten Passwort zu knacken, wird seine IP für die nächsten 15 Minuten gesperrt. - 7 -
4.2 Administration // AF05 Der Administrator kann Updates- und Wartungsprozesse starten. dazu kann er Administrator- und Benutzerkonten erstellen und freigeben. Der Admin muss jedes Semester, die Kursinformationen in der Datenbank auf den neusten Stand bringen. Wenn sich ein Dozent registriert, dann muss der Admin überprüfen ob es sich dabei wirklich um einen Dozenten handelt Wenn es 2010 einen neuen Studiengang gibt, dann updatet der Admin die Datenbank mit Informationen über den Studiengang. 4.3 Raumnr. Ergänzen // AF06 Der Raumplaner kann bei einem Klausurtermin den Raum ergänzen. Wenn ein Dozent leinen Klausurtermin festlegt, dann muss der Raumplaner für diesen Klausurtermin einen passenden Raum finden und in das System eintragen. 4.4 Klausurtermin ändern // AF07 / Klausurtermin festlegen // AF08 Der Dozent kann alle benötigten Daten in eine Eingabemaske eintragen. Wenn das System die Eingaben akzeptiert dann werden diese in die Datenbank gespeichert und können abgerufen werden, ansonsten wird dem Dozenten eine Fehlermeldung ausgegeben. Ein Dozent bekommt von einem Studenten eine E-Mail, dass er doch bitte den einen Klausurtermin verschieben solle. Der Dozent wird dann nach einer Alternative gucken, und wenn er eine gefunden hat, wird er die Klausur öffnen und das Datum ändern. Ein Dozent muss eine Klausur schreiben, weil es so vorgeschrieben ist. Dann loggt sich der Dozent ein und legt eine neue Klausur an. 4.5 Klausurtermin Abfrage // AF09 User können die Klausurtermine von Regelsemestern oder einer selbst zusammengestellter Liste von Kursen anzeigen lassen. Ein Student möchte wissen, wann er seine Klausuren schreiben muss. Ein Dozent möchte nach gucken, wann seine Studenten Klausuren schreiben, damit er einen Tag auswählen kann, der den Studenten am besten passen könnte. - 8 -
5. Benutzerschnittstelle - 9 -
6. Daten Das System muss folgende Daten speichern können oder in der Datenbank vorliegen haben, damit das System fehlerfrei funktionieren kann. Genauere Informationen dazu sind in der folgenden Tabelle erfasst. 6.1 Account Name Name Passwort Email Benutzergruppe (Standart) Integer / Datentype/ Beschreibung VarChar(max. 100 Zeichen) VarChar(max. 50 Zeichen), SHA verschlüsselt VarChar(max. 100 Zeichen) Einstellung ist nur für den Admin sichtbar 6.2 Kursdaten Kursname (kurz) Kursname (lang) Kursnummer(unique) Studiengang (kurz) Studiengang (lang) Semester VarChar(max. 20 Zeichen) VarChar(max. 100 Zeichen) Integer VarChar(max. 20 Zeichen) VarChar(max. 100 Zeichen) Integer 6.3 Klausurtermine Kursnummer Datum Uhrzeit Dauer (Minuten) Anzahl Studenten Raum Nr. Dozent Email (von Dozent) Kommentar Fremdschlüssel Date Date Integer Integer VarChar(max. 20 Zeichen) VarChar(max. 100 Zeichen) VarChar(max. 100 Zeichen) VarChar(max. 500 Zeichen) - 10 -
7. Qualitätsanforderungen 7.1 Technische Qualtitätsanforderungen 7.1.1 Zuverlässigkeit Die Anwendung muss zu jeder Zeit erreichbar sein, aber wegen technischen Störungen oder Wartungen und Updates kann dies nicht immer gewährleistet werden. Dadurch ist maximal nur die Verfügbarkeit von 99% realistisch. Eine Verfügbare Internetleitung und ein laufender Server werden vorausgesetzt. 7.1.3 Portabilität Die Portabilität ist durch die online Erreichbarkeit gegeben, da die Anwendung von der ganzen Welt aufgerufen und benutzt werden kann. 7.2 Interaktions- und Ergonomieanforderungen 7.2.1 Nutzungsschnittstellen Für die grafische Nutzungsschnittstelle wird ein Browser verwendet. Eine Schnittstelle für externe Programme wird es nicht geben. 7.1.2 Fehlertoleranz Sämtliche Eingaben und Abfragen werden vom System überprüft und werden nur bei Erfolgreicher Prüfung ausgeführt, ansonsten wird eine Fehlermeldung an den Benutzer gesendet. 7.2.2 Interaktionsleistungen Dem Benutzer werden Buttons und Dropdown- Menüs sowie Listen geboten, die man mit der Maus und Tastatur bedienen kann. 7.2.2.1 Nutzer Die Anwendung ist eine reine Online-Anwendung, d.h. der Benutzer muss über einen Internetanschluss verfügen damit er die Anwendung nutzen kann. Die Anzahl der Nutzer wurde auf 100 Nutzer pro Stunde geschätzt (zur Klausurzeit), damit kommt ein Server mit einer 50mbit Anbindung gut zurecht. 7.2.2.2 Performanz Die unter Punkt 2.4.2.2 Hardware beschriebene Server- Hardware, kann jede MySQL Abfrage in weniger als 0.1 Sekunden bearbeiten. Die Ergebnisse der Abfrage werden dann an den User geschickt, was nicht länger als 0,3 Sekunden bei einer ISDN Leitung dauert, weil nur kleine Datenmengen und keine Bilder übertragen werden müssen. Somit dauert eine Abfrage von der Bestätigung bis zur Ausgabe rund 0,4 Sekunden, was ein schnelles und fehlerfreies Arbeiten mit der Anwendung ermöglicht. 7.2.2.3 Robustheit Wie unter 7.1.2 Fehlertoleranz beschrieben soll dem Benutzer bei fehlerhaften Eingaben geholfen werde. Dies wird durch eine Markierung und einem Hinweis- Satz realisiert. - 11 -
7.3 Wirtschaftliche Qualitätsanforderungen Es wird nur eine Variante der Anwendung geben, bei der Variante werden sich die Hostingkosten um ~100 / Monat drehen. Es wird jeden Tag um 4:00 Uhr die Sicherheitskopie von der Datenbank auf den neusten Stand gebracht, und vorliegende Updates installiert. Der Admin kann jederzeit auf den Server und auf die Datenbank zugreifen, um dringende Wartungsabreiten durch zuführen. 7.4 Rechtliche und normative Anforderungen Damit sich normale User nicht als Admins oder Dozenten einloggen und somit mehr Rechte auf das System haben, müssen die Passwörter eine bestimmte Sicherheitsstufe haben und dürfen auch nur verschlüsselt übertragen werden. Zusätzliche gibt es die 15 Minuten lange Sperrung nach 5 Fehlversuchen um Passwort Hacker zu kontern. 8. Gliederung in Teilprodukte Das System funktioniert nur als Ganzes und kann nicht in Teilprodukte gegliedert werden, da die einzelnen Funktionen aufeinander aufbauen. Das System braucht ein Raumplanungs-System damit es vollständig funktionieren kann. Das System bietet 5 Funktionen (Login, Registrieren, Klausurtermin abfragen, Klausurtermin festlegen und Klausurtermin ändern). Das System kann durch einen Kalender erweitert werden, 9. Entwicklungskonfiguration Für die Entwicklung der Anwendung sollte auf den PCs Eclipse und Subversion laufen, damit eine gute und schnelle Zusammenarbeit bei der Entwicklung gewährleistet ist. Die PCs sollten dafür mindestens einen 1.4 GHz Prozessor und 512 GB Arbeitspeicher haben. Als Testdatenbestand stehen eine fehlerhafte, fehlerlose und eine veränderbare Datenbankdateien zur Verfügung. Als Server wird ein bereits konfigurierter vserver verwendet. 10. Beschaffungsanforderungen Die Beschaffungsanforderungen sind bereits erfüllt, da der Entwicklungsserver mit allen nötigen Programmen (Java, Apache, Tomcat, MySQL, Subversion) bereits läuft und die für die Programmierung benötigten PCs bereits installiert und konfiguriert sind. - 12 -
11. Glossar Dozent Ausbilder/ Lehrer der Studenten Darf Klausurtermine festlegen und ändern Studenten Schüler/Kommilitonen kann Klausurtermine abfragen Vorlesung Theoretischer- Unterricht Übung Praxis- Unterricht Klausur Arbeit/Test hat Termin, Uhrzeit zu der begonnen wird und Länge Liste von zu lösenden Aufgaben Studiengang Ausbildungsrichtung, Fachrichtung z.b. Informatik oder Medieninformatik Semester Halbjahr, 1/2 Jahr 1 Semester beschreibt das Schuljahr eines Studenten. Kurs Unterricht, Fach z.b. Mathe oder Informatik Raumplanung Bearbeitet die RaumNr. bei neuen oder geänderten Klausuren Firefox Ein Open-Source Web-Browser Browsern Ein Programm, was das betrachten von Webseiten ermöglicht MySQL Eine sehr beliebte schnelle und kostenlose Datenbank Datenbank Speichert Daten und kann diese gefiltert und sortiert ausgeben Server Ein PC (ohne Monitor) der immer am Internet angeschossen ist und immer an ist. Ein PC, auf dem Daten gespeichert oder ausgegeben werden. XHTML Eine Sprache für Browser um Webseiten darzustellen. Java Eine Programmiersprache um Programme und Anwendungen zu schreiben. Eclipse Ein Programm, das Programmieren mit Java ermöglicht. Subversion Ein Programm, das Dateien und Verzeichnisse verwaltet - 13 -