Kurzbeschreibung des Projekts:

Aufgabe dieses Projekts war die Entwicklung eines Software Systems zur Erfassung von archäologischen Daten über ein Web Front End
und Repräsentation dieser Daten in Form von virtuellen Museen, repräsentativen Katalogen und CD-ROMs. Bei der Entwicklung des
Softwaresystems wurde nach dem "Rational Unified Process" vorgegangen, welcher die "UnifiedModeling Language" (UML) verwendet. Der
"Rational Unified Process" ist eine Menge von Aktivitäten, die die Benutzeranforderungen in ein Software System transformieren.

Das erste Teilziel bestand darin in der "Inception Phase" aus der sehr ungenauen Beschreibung des geforderten Softwaresystems (vom
Kunden erhalten), mit Hilfe von Gesprächen mit dem Kunden eine ausführliche Problembeschreibung (erste Interation) und in weiterer
Folge daraus, eine Anforderungsdefinition zu erstellen. Hier ging es also darum, festzulegen welche Aufgaben unter welchen Bedingungen
computergestützt gelöst werden sollen. Die Problembeschreibung und Anforderungsdefinition wurden in weiteren Iterationen verfeinert
und ergänzt.

Eine weitere Aufgabe bestand darin eine Risikoabschätzung durchzuführen. Zweck dieser Abschätzung war, festzustellen ob die
Implementierung möglich ist oder nicht, bzw. ob es ökonomisch Sinn macht dieses Projekt weiterzuführen. Hier waren unter anderem
Risiken persönlicher-, rechtlicher-, zeitlicher- und technischer Natur zu betrachten und zu bewerten.

Im "Rational Unified Process" wird das Verhalten eines zu entwickelnden Systems in "Use Case Models" dokumentiert. Diese zeigen die
geplanten Funktionen des Systems (Use Cases), ihre Umgebung (actors) und die Beziehungen zwischen den "Use Cases" und den "Actors"
(Use Case Diagramme). Das "Use Case Model" startet nun in der "Inception Phase" mit der Identifikation der "Actors" und der "Primary Use
Cases". Mit diesem Wissensstand konnte durch eine auf "Use Cases" basierenden Schätzmethode eine erste, grobe Abschätzung des Zeit-
und Geldaufwandes durchgeführt werden. Das Ergebnis dieser Abschätzung diente als Grundlage um unter anderem folgende Fragen zu
beantworten. Soll (kann) unter diesen finanziellen Bedingungen das ganze System aufeinmal realisiert werden, oder werden gewisse
Funktionalitäten in ihrer Priorität herabgestuft um den finanziellen Rahmen einhalten zu können ?  Welcher Termin wird vom Kunden für
die Fertigstellung gewünscht und kann er nach dieser Abschätzung eingehalten werden?

Anschließend in der "Elaboration Phase" wurde eine detailierte Beschreibung der "Primary Use Cases" durchgeführt.Hier ging es darum,
sich Gedanke über die prinzipielle Funktionalität, Alternativen, Fehlerbedingungen, Voraussetzungen (Preconditions) und
"Exitbedingungen" (Postconditions) der "Use Cases" zu machen. Desweiteren wurden hier auch Bedingungen, Verzweigungen und Schleifen
der "Use Cases" lokalisiert und dargestellt (Flow of Events, Activity Diagram). Um den Rahmen eines zweistündigen Proseminars nicht
zu sprengen wurden nur bestimmte "Use Cases" für die detailierte Beschreibung ausgewählt.

Im nächsten Schritt galt es das System in Teile zu zerlegen (Architektur) die eine Größe haben um sie zu realisieren, bzw. damit
arbeiten zu können. Als Grundstruktur und Ausgangspunkt um unser System in einzelne Teile (Subsysteme) zu zerlegen haben wir den
"Object-Oriented Pattern" gewählt. Dieser Pattern definiert Subsysteme um Daten und den zugehörigen Funktionen. Der erste Entwurf der
Architektur unseres Systems wurde nach und nach mit Hilfe der identifizierten "Use Cases" durch Module und Interfaces ergänzt und
vervollständigt. Schließlich wurde anschließend ein Projektplan für die "Construction Phase" erstellt. Hier wurde also eine Serie von
Iterationen, zur Konstruktion und Definition von Funktionalitäten geplant, welche jeweils am Ende der Iterationen geliefert werden.

Anschließend wurde ein Prototypen für einen erkannten und lokalisierten Risikobereich erstellt, um diesen abzusichern. Hier haben wir
das Anlegen eines neuen archäologischen Objekts in der Datenbank realisiert.

Zum Abschluss unseres Projekts habe wir für die erste Iteration der "Construction Phase" ein konzeptionelles "Class Diagramm" und für
ausgesuchte Fälle, "Interaktionsdiagramme" und "Statediagramme" erstellt.