VirtL Allgemeine Anforderungen

Alle Informationen, die noch nicht in eigene Dokumente eingegliedert werden konnten, sind in diesem Dokument zusammengefasst.

Nichtfunktionale Anforderungen

Alle Nichtfunktionalen Anforderungen an die Webapplikation sind in den folgenden Kapiteln beschrieben.

Applikationsstart Position restaurieren

Der Anwender soll die Möglichkeit haben beim erneuten Aufruf der Webapplikation seine vorigen Einstellungen zu nutzen. Er soll an die zuletzt angewählte Position im Programmablauf geführt werden. Diese Funktionalität ist mit dem Neustart des KDE Systems vergleichbar, bei dem alle Applikationen wieder an die letzte Verarbeitungsposition gefahren werden.

Verwendbare Webbrowser

Folgende gängigen Webbrowser, deren Versionen nicht älter als drei Jahre alt sind, sollen verwendet werden können.

• Opera
• Netscape Mozilla
• Internet Explorer
• Fire Fox
• Safari

Der Zugriff mit einem textbasierten Webbrowser soll möglich sein. Hierfür muss eine äußerst saubere Navigation bereit stehen.

Designvorschriften für die Darstellung

Es sollen keine Frames verwendet werden. Ansonsten sind die Probleme mit Palms, Suchmaschinen usw. zu groß.

Sicherheitsanforderungen

Der Zugriff muss mindestens über User Passwort geschützt sein. Es muss mindestens zwei Anwendergruppen in diesem System geben. Die User Gruppe, welche alle User und Administratoren beinhaltet und die Systemadministratorengruppe. Die einzelnen User Zugänge müssen mit den gängigen Mitteln (LDAP oder Mailserververifikation) abgesichert werden. Die Emailadressen der Systemadministratoren müssen bekannt sein um schnell bei Regelverstößen reagieren zu können und User aus dem System zu entfernen.

Performance und Verfügbarkeit

Die Webapplikation muss hoch verfügbar sein. Wartungsarbeiten müssen den Anwendern bekannt gemacht werden. Die Performance muss normalen Internetansprüchen genügen. Mit einem ISDN Zugriff soll es möglich sein, die einzelnen Seiten der Webapplikation in drei Sekunden anzuzeigen. Nachladen von Bildern ist erlaubt. Bei komplexen Abfragen ist es erlaubt längere Antwortzeiten zu definieren.

Testing

In diesem Kapitel wird festgelegt, wie was und wann getestet wird.

Dokumentationsreview

Die einzelnen Dokumente können von den Erstellern stets zu Reviews vorgelegt werden. Die Experten, die diese Reviews durchführen, können ihre Befunde in Befundlisten hinterlegen.
Das Kernteam gibt ein Dokument frei. Falls es sich für das Projekt um ein sehr wichtiges Dokument, wie beispielsweise die Systemarchitektur, handelt lädt das Kernteam zu einer Reviewsitzung ein.

Modultests

Beschreibung befindet sich unter Modultests.

Integrationstests

Die Integrationstests sollen so weit wie möglich automatisiert werden. Es ist angedacht, dass die Eigenschaften von JUnit auf die Integrationstestumgebung mit übernommen werden. Die Entwickler führen den Integrationstest durch. Dabei ist darauf zu achten, dass die Testinstallationen durch Scripts erzeugt werden sollen. Manuelle Änderungen und Anpassungen sollen auf ein Minimum reduziert werden. Ohne diese Maßnahme müssen die Entwickler unter Umständen bis zur Produktion eingreifen.
Die Baselines, und somit die Releasebuilds, werden direkt aus dem Sourcecode Verwaltungssystem entnommen und alle Umgebungsanpassungen durch konfigurierbare Parser erstellt. Der eigentliche Integrationstest wird vom Entwickler durchgeführt. Falls ein Release nicht korrekt funktioniert, wird der Installationsablauf so lange komplett durchgeführt, bis kein manueller Eingriff beim Installieren mehr notwendig ist. Dieser Prozess sieht zunächst sehr aufwendig aus, führt jedoch zu einer sehr schnellen und sicheren Installation bei der viele Seiteneffekte sofort ausgemerzt werden können.

Systemtest

Die Tester lassen von den Systemadministratoren das zu testende System in die Testumgebung einspielen. Mit dieser Maßnahme werden die Systemadministratoren das erste Mal mit dem neuen Release konfrontiert. Die Installation muss ohne Mithilfe der Entwickler möglich sein. Die Tester erstellen die Testfälle und das Testdrehbuch für diesen Testlauf. Um ein einfaches und effizientes Testen durchführen zu können sollen so viel wie möglich Tests automatisiert werden.

Abnahmetest (Betriebstest)

Hierfür wird der im Systemtest befindliche Release von den Systemadministratoren neu installiert und die Funktionalität überprüft. Wenn sie die Installation einschließlich der Migration der alten Datenbestände in die neuen Datenbankschemen durchführen können, wird die Produktionsumgebung umgestellt.

Werkzeuge

Alle Werkzeuge und deren Einsatzgebiet, die in diesem Projekt Verwendung finden, werden hier aufgelistet.

JBoss

Hierbei handelt es sich um einen Application Server der für den Betrieb der Software eingesetzt wird.

Struts, JFace oder PHP

Um die Generierung der HTML Seiten durchzuführen, wird Struts oder JFace eingesetzt. Die meisten Seiten können mit PHP erstellt werden. Auf diese Weise ist die Entwicklung der HTML Seiten schneller durchführbar. Im Januar 2006 wurde entschieden, dass nur statische HTML Seiten zum Einsatz kommen sollen. So lange dies gut möglich ist, werden wir dies beibehalten.

Datenbank

Als Datenbank wird Postgres oder MySql eingesetzt. Dies muss noch weiter erarbeitet werden.

Verrechnungsmodell und Verwaltung des Systems

Hier sind erste Ideen aufgenommen, wie das System später betrieben werden kann. Es geht hierbei darum wie ein Provider dieses System betreiben und seine Unkosten decken kann. Die Ideen werden nach dem Prototyp nochmals aufgegriffen und weiter geführt.

User die länger als ein Jahr inaktiv sind sollen durch einen Cleanup Job aus dem System entfernt werden. Die User Stammdaten werden dabei nicht gelöscht sondern auf ein Speichermedium, wie DVD oder Band, ausgelagert. Eine manuelle Einspielung soll immer möglich bleiben. Das zurückschreiben von Band ist jedoch ein kostenpflichtiger Service, da ein Mitarbeiter die Arbeiten durchführen Muss. Der User soll für die Verwaltung seiner Daten einen gewissen Betrag bezahlen. Das Verrechnungsmodell Muss hierfür erstellt werden. Es gibt mehrere Ansätze. Jeder User bezahlt einen Betrag (z.B. fünf Franken pro Monat) um das System benutzen zu können. Ein weiterer Ansatz ist, die UserGroups zu berechnen. Hier können größere Gruppen (mehr User) auch mehr bezahlen. Das Modell könnte eine Einstufung von 1-10, 10-50, 50-100 und 100-1000 User vorsehen. Die Kosten würden je mehr User in einer Gruppe desto günstiger werden. Ein Projektteil Muss sich mit dem Betreiben beschäftigen. Wieviel kostet das Hosten der Maschinen? Wann werden die Kosten günstiger? Wo sind die Sprungkosten?