
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Project Description}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Aufgabenstellung}
\bigskip

Aus dem in der Einleitung definierten Business Case ist eine
ausf"uhrliche \emph{Problembeschreibung} zu erstellen. Dabei sollen
sich Auftraggeber und Software-Entwickler klar werden, was eigentlich
zu machen ist.

In der Problembeschreibung sollte erfa"st sein, WAS erreicht werden
soll, nicht WIE. Falls wichtige Aspekte auftauchen, die NICHT
Bestandteil des Projektes sein sollten, dann mu"s das ebenfalls in der
Problembeschreibung enthalten sein.

\bigskip

Im ersten Schritt sind dazu die anf"anglich nur grob spezifizierten
Anforderungen (initial statement of needs) an das zu erstellende
System aus dem Business Case zu identifizieren. Diese stellen
vorl"aufig die sogenannten \emph{key features} des Systems dar.
Weiters sollen bereits vorgegebenen \emph{Randbedingungen} erfa"st
werden. 

\bigskip

Um diese vorerst nur grob umrissenen Anforderungen pr"azisieren,
erweitern und erg"anzen zu k"onnen, mu"s nun der Dialog mit dem
Auftraggeber und den zuk"unftigen Benutzern des zu erstellenden
Systems gesucht werden. Zus"atzlich sollen weitere 
\emph{Ansprechpartner} f"ur spezielle Teilbereiche des zu
behandelnden Problems identifiziert werden. 

\bigskip

Damit sollten in dieser ersten Phase der Projektdefinition
haupts"achlich \emph{Fragen} an den Auftraggeber (dh. an einen
repr"asentativen Teil der zuk"unftigen Benutzer des Systems) im
Vordergrund stehen. Aus der \emph{Beantwortung} dieser Fragen mu"s
nun die Problembeschreibung ausgearbeitet werden. Da diese Antworten
ebenfalls wieder neue Fragen aufwerfen werden, ist dies ein iterativer
Prozess. Dieser wird fortgesetzt bis eine detaillierte
Problembeschreibung vorliegt, aus der im n"achsten Schritt unmittelbar
die Anforderungen entnommen werden k"onnen.

\bigskip

Es sollte dabei auf Vermutungen und unbegr"undete Annahmen bez"uglich
der Funktionalit"at des Systems verzichtet werden. In jenen Bereichen,
die nicht speziell dem zu untersuchenden Fachgebiet (sondern mehr der
Software-seitigen Implementierung) zuzuordnen sind, sollen dem
Auftraggeber jedoch Vorschl"age zur Orientierung und eventuell
Prototypen zur Demonstration der M"oglichkeiten der zu erstellenden
Software vorgelegt werden. 

\bigskip


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Key features und Umgebungsbedingungen}
\bigskip

Das zu erstellende Software-System soll den Benutzern die folgenden
aus dem Business Case identifizierten \emph{Funktionen} zur
Verf"ugung stellen. 

\begin{itemize}
  \setlength{\itemsep}{0mm}
  \item Erfassen und Pflege von arch"aologischen Daten in einer
    Datenbank ("uber ein Web-Frontend).
  \item Datenbankabfragen zur Darstellung der erfa"sten Daten.
  \item Unterschiedliche Zugriffsrechte auf die Inhalte der
    Datenbank.
  \item Erstellen von virtuellen Museen aus den erfa"sten Daten mit
    der M"oglichkeit der visuellen Gestaltung der darzustellenden
    Information.
  \item Erstellung von CD-ROM's und gedruckten Katalogen dieser
    virtuellen Museen.
\end{itemize}

\bigskip

Dabei sind die folgenden \textit{Umgebungsbedingungen} zu
ber"ucksichtigen.
\begin{itemize}
  \setlength{\itemsep}{0mm}
  \item Es wird vom Kunden eine zentrale Datenhaltung gew"unscht, er
    will diese Aufgabe jedoch nicht selbst "ubernehmen. Daher wird
    diese Aufgabe von uns in der Rolle eines ASP (Application Service 
    Provider) "ubernommen. Dies impliziert die Verwendung von
    entsprechenden Betriebsmitteln (Hard- und Software, Werkzeuge zur
    Datenbank-Administration, etc.).
  \item Es ist der \emph{Rational Unified Process} als Grundlage
    f"ur die Systementwicklung zu verwenden.
  \item F"ur die Pr"asentation der Inhalte ist der Einsatz von XML
    gefordert.
\end{itemize}


\bigskip

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Verzeichnis der Ansprechpartner}
\bigskip

Problemspezifische Informationen k"onnten aus den folgenden Quellen
akquiriert werden:

\begin{itemize}
  \setlength{\itemsep}{0mm}
  \item Kompetenzen des Auftraggebers ber"ucksichtigen.
  \item Interviews mit Repr"asentanten der aus der vorl"aufigen
    Problembeschreibung identifizieren Benutzer-Klassen.
  \item F"ur den Aufbau der Datenbank Experten aus dem Bereich der
    Multimedia-Datenbanken zurate ziehen. Beantwortung von Fragen der
    Art - Wie k"onnen multimediale Inhalte optimal in einer Datenbank
    gespeichert werde? - Welche Tools und Werkzeuge stehen zur Wartung
    und Pflege von Datenbanken bereits standardm"a"sig zur Verf"ugung?
  \item Um die Aufgaben der Erfasser zu untersuchen, kann eine
    Ausgrabung besucht werden. Dabei k"onnen die T"atigkeiten der
    Erfasser direkt vor Ort untersucht werden.
  \item Durch den Besuch von Museen, die sehr wahrscheinlich ihren
    Bestand bereits in einer Art Datenbank (schriftlich oder
    elektronisch) aufgelistet haben. Aus diesen k"onnen unter anderem
    Informationen "uber die ben"otigten Datenfelder extrahiert
    werden. Auch der Ablauf der Erfassung von arch"aologische Daten
    kann hier vielleicht verfolgt werden. 
  \item Evaluation von bereits bestehenden arch"aologischen
    Datenbanken und virtuellen Museen im Internet.
  \item Es sollte vor allem untersucht werden, ob f"ur arch"aologische
    Daten bereits eine einheitliche Standardschnittstellen zur
    Verf"ugung stehen! 
\end{itemize}

\bigskip


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Die erste Iteration}
\bigskip

Im ersten Schritt des iterativen Verfeinerungsprozesses sollten vor
allem jene Fragen gekl"art werden, die wichtig f"ur das
Problemverst"andnis sind. 



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Verzeichnis der zu kl"arenden Fragen}
\bigskip

Die sich aus dem Business Case ergebenden Fragen in diesem Abschnitt
sind grob nach den identifizierten Key Features strukturiert.

\bigskip

Zu Begin sollte das sehr zentrale Problem der \textbf{Rollen der
verschiedenen Benutzer} des Systems analysiert werden. Die
vorliegende Problembeschreibung bietet in diesem Zusammenhang nur sehr
ungen"ugende Ans"atze. Es werden lediglich die beiden Aktoren
``Erfasser'' und ``wissenschaftlicher Erfasser'' eingef"uhrt und deren
grundlegende T"atigkeiten angegeben. Die folgenden Fragen sollen hier
zu mehr Transparenz f"uhren und sie sollend die beiden Rollen
voneinander abgrenzen.

\begin{fragen}
  \item Wie werden arch"aologische Funde im jetzigen System
    dokumentiert?
  \item Wie sieht die Verteilung von \emph{Kompetenzen} bei der
    Erfassung von arch"aologischen Daten zwischen den beiden Aktoren
    ``Erfasser'' und ``wissenschaftlicher Erfasser'' aus? 
  \item Sind die durchzuf"uhrenden Aufgabenbereiche disjunkt oder gibt
    es hier "Uberschneidungen? 
  \item Wer hat die \emph{Rechte} zur Datenfreigabe?
  \item Auf welchen Teil der Daten darf ein wissenschaftlicher
    Erfasser zugreifen? 
  \item Gibt es in diesem Zusammenhang eine aktorenbezogene
    Bearbeitung bzw. Freigabe von Daten?  
  \item Kann also ein wissenschaftlicher Erfasser die Daten des
    Erfassers bearbeiten bzw. freigeben und umgekehrt? 
  \item Soll bei der Eingabe eines arch"aolog. Artefakts die
    Identit"at des Erfasser mit gespeichert werden?
  \item Falls ein Erfasser ein bestimmtes Artefakt nicht freigeben
    hat, soll dann dieses Artefakt nur f"ur ihn sichtbar sein, oder
    aber auch f"ur alle anderen Mitglieder der Erfassergruppe?
  \item Soll es eine Art von Redaktionssystem geben, soda"s nur
    bestimmte Anwender die Daten erst nach einer redaktionellen
    Pr"ufung freigeben k"onnen?
\end{fragen}

\bigskip



Die folgenden Fragen sollen die Thematik der \textbf{Erfassung und
  Pflege der Daten} pr"azisieren. 

\begin{fragen}
  \item Welche verschiedenen \emph{Typen} (Text, Ton, Bild, ...) von
    Daten sind zu erfassen? 
  \item Welche Aktoren erfassen welche Daten? 
  \item Wie werden die Daten in die Datenbank integriert?
  \item K"onnen die zu erfassenden Artefakte \emph{klassifiziert}
    werden (zB. Klassifikation "uber eine allgemeine Bezeichnung wie
    Grab, Vase, etc.)? Kann also jedes Artefakt einer bestimmten
    Gruppe zugeordnet werden? 
  \item Falls solch eine Einteilung erfolgen soll, kann es Artefakte
    geben, die in das vorhandene Klassifikationsschema nicht
    eingeordnet werden k"onnen? Welche Strategien sollen in solch
    einem Fall verfolgt werden? 
  \item Gibt es gemeinsame Attribute, die allen zu erfassenden
    Artefakten zugeordnet werden k"onnen?
  \item Ist in einer vorgegeben Klasse von Artefakten die Menge der
    Attribute vorgegeben? 
  \item Ist die verf"ugbare Menge der Datenfelder einer Klasse von
    Artefakten statisch, oder k"onnen bei der Dateneingabe neue
    Datenfelder definiert werden, die dann eventuell auch als
    klasseninh"arente Datenfelder "ubernommen werden k"onnen?
  \item Wurden bereits \emph{Standards} zur Archivierung von
    arch"aologischen Daten definiert? Diese Frage kann von einer
    immensen Bedeutung f"ur den Erfolg des Produktes sein. Falls
    solche Standards vorhanden sind, k"onnen diese auf das vorliegende
    Problem angewendet werden?   
  \item Soll ein eigener Standard definiert werden? In diesem
    Zusammenhang sollten bereits existierende Systeme evaluiert
    werden.
  \item Aus der Problematik der Rollenteilung zwischen den Gruppen der
    Erfasser resultiert weiters die Frage nach der unterschiedlichen
    Gestaltung der Eingabeoberfl"ache. Kann dabei eine gemeinsame
    Eingabemaske verwendet werden oder sollen spezifische Formulare
    verwendet werden? 
  \item Wie werden die geforderten Querverweise hergestellt?
\end{fragen}

Durch die unterschiedlichen Rechte wird es notwendig werden, die
verschiedenen Benutzer der Datenbank zu unterscheiden. 

\bigskip


Die folgenden Fragen sollen die Funktion der \textbf{Abfrage der
Daten} pr"azisieren.

\begin{fragen}
  \item Welche Suchkriterien dh.~welche Datenfelder der Datenbank
    k"onnen f"ur die Benutzer von Interesse sein?
  \item Welche Suchmethoden (Volltextsuche, Suche durch bestimmten
    Klassifizierungsmerkmalen, weiche Suche, ...) sollen zur
    Verf"ugung gestellt werden? 
  \item Wie k"onnen bestimmte Ton oder Bild-Dokumente gesucht werden
    -- mittels Beschreibungen der Inhalte dieser Datentypen? 
  \item Wie soll das Ergebnis der Suche pr"asentiert werden? 
  \item Sollen dabei verschiedene Ansichten auf das Suchergebnis
    m"oglich sein? 
  \item Soll das aktuelle Suchergebnis durch Eingabe weiterer
    Kriterien verfeinert werden k"onnen? 
  \item Sortierung des Ergebnisses nach bestimmten Kriterien?
  \item Wie schr"anken die verschiedenen Rechte der Benutzer der
    Datenbank das Ergebnis der Suchanfrage ein? Dazu k"onnte ein
    ``anonymer'' Benutzer eingerichtet werden, der sich f"ur die
    Abfrage nicht anzumelden hat, dem jedoch nur eine eingeschr"ankte
    Information (geregelt durch die Freigabe der Erfasser)
    pr"asentiert wird ("ahnlich dem ALEPH-System der
    Bibliothek). Erfassern und wissenschaftlichen Erfassern kann nach
    einer erfolgten positiven Autorisierung der volle Datenbestand
    oder auch je nach Gruppenzugeh"origkeit ein definierter Subset
    davon freigegeben werden. 
\end{fragen}

\bigskip


Sehr aufwendig erscheint mir die Forderung nach der M"oglichkeit der
\textbf{Erstellung von virtuellen Museen}. Daher wurden vorl"aufig
haupts"achlich jene Aspekte ber"ucksichtigt, die einen Zusammenhang
mit der zu erstellenden Datenbank haben.

\begin{fragen}
  \item Werden an die Daten der ``Austellungsst"ucke'' bestimmte
    Anforderungen gestellt (zB. bestimmte zwingend vorhandene
    Attribute)?
  \item Welche Benutzergruppe soll aus dem Datenbestand virtuelle
    Museen erstellen k"onnen? 
  \item D"urfen auch nicht freigegebene Artefakte vom Ersteller der
    Datenbank in einem virtuellen Museum verwendet werden? 
  \item Sollen die zugrundeliegenden Daten nach der Erstellung eines
    virtuellen Museums statisch sein, oder sollen "Anderungen in der
    Datenbank automatisch auch in den anh"angigen Museen erfolgen?
  \item Soll das Museum nach bestimmten ``Austellungsst"ucken''
    durchsucht werden k"on\-nen? 
  \item Sollen dabei "ahnliche Suchmechanismen zum Einsatz kommen wie
    bei den Datenbankabfragen?  
  \item Welcher Freiraum soll dem Ersteller eines virtuellen Museums
    bei der textuellen und graphischen Gestaltung einger"aumt werden? 
  \item K"onnen bzw. sollen bestimmte Gestaltungselemente vorgegeben
    werden? 
  \item Wie soll die Navigation in den Museen aussehen?
\end{fragen}

\bigskip


Zur \textbf{Erstellung von CD-ROM's und gedruckten Katalogen} ist zu
"uberlegen:

\begin{fragen}
  \item Welchen Datenumfang werden die zu erstellenden Museen
    normalerweise haben? Falls der Datenumfang sehr viel gr"o"ser als
    die Speicherkapazit"at einer CD-ROM sein sollte, dann sollte
    "uberlegt werden, ob nicht gewisse (unwesentliche oder
    umfangreiche) Teile der zugrundeliegenden Daten aus dem Museum nur
    online zur Verf"ugung gestellt werden. 
  \item Welche Informationen werden aus den Museen in die gedruckte
    Kataloge "ubernommen. 
  \item In welchem Format/Layout (ganz allgemein) sollen die
    gedruckten Kataloge erzeugt werden? Hier sollte ein realer Katalog
    als Vorlage dienen. 
\end{fragen}

\bigskip


Das Thema \textbf{Pr"asentation der Inhalte mittels XML} wurde vorerst
noch nicht recherchiert.

\bigskip


Zu den \textbf{nichtfunktionalen Anforderungen} ergeben sich die
folgenden Fragen.

\begin{fragen}
  \item Wie gro"s ist die zu erwartende Kapazit"at der zu erfassenden
    Daten? 
  \item Welche durchschnittliche/maximale Abfragerate an die Datenbank
    ist zu erwarten? 
  \item Maximale Anzahl der sich gleichzeitig im System befindenden
    Benutzer?
  \item Welche Anforderungen an die Verf"ugbarkeit der Datenbank gibt
    es?
\end{fragen} 

Diese Faktoren bestimmen wesentlich die Dimensionierung des zu
verwendenden Datenbanksystems. 

\bigskip

Da die Bereitstellung und Pflege der Datenbank in unserem
Aufgabenbereich liegt, soll auf eine aufw"andige Entwicklung von Tools
und Werkzeugen zur Wartung und f"ur sonstige Aufgaben m"oglichst
verzichtet werden. 
Da benutzerspezifische Zugriffsrechte auf die Inhalte der Datenbank
ben"otigt werden, wird ein umfangreiches Benutzermanagement
erforderlich sein. 

\bigskip

\emph{Bemerkung:} 
Es w"are (in der Praxis) sehr sinnvoll, wenn man zu den gestellten
Fragen die jeweiligen Ansprechpartner notieren w"urde! Au"serdem
sollten die Fragen mit Priorit"aten versehen werden, soda"s wichtige
Fragen (u.a. jene von denen wieder weitere Fragen abh"angen) zuerst
gekl"art werden k"onnen.

\bigskip


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Evaluierung der Gespr"achsprotokolle}
\bigskip

Aus der Diskussion der obigen Fragen mit den entsprechenden
Ansprechpartnern (in unserem Fall ja nur mit dem Proseminarleiter)
ergeben sich nunmehr eine Reihe von Gespr"achsprotokollen.

\bigskip

Bei der Evaluierung dieser Protokolle soll nun untersucht werden, wie
die Antworten auf die gestellten Fragen ausgefallen sind (z.B.:
kl"aren diese die Frage nur zum Teil, entstehen dadurch neue Fragen,
etc.), und wie sich diese in den bestehenden Business-Case einordnen
lassen (z.B.: sind dabei Widerspr"uche zu den urspr"unglichen Angaben
entstanden, sind zus"atzliche Aufgaben dazu gekommen, etc.).

\bigskip

[todo ...]

\bigskip


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Verfeinerte Problembeschreibung}
\bigskip

%Nach der Evaluierung der Gespr"achsprotokolle wird eine verfeinerte
%Problembeschreibung erstellt.

Aus der Diskussion der obigen Fragen mit den entsprechenden
Ansprechpartnern ergibt sich nunmehr eine verfeinerte
Problembeschreibung. 
Dabei ist als formale Grundlage das Ergebnis der Diskussion (in
unserem Fall das vom project leader erstellte Gespr"achsprotokoll) zu
verwenden.

\bigskip

[todo ...]

\bigskip



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Literaturverzeichnis}
\bigskip

Ein gro"ser Teil der Vorbereitungszeit wurde f"ur das Einlesen in die
themenspezifische Literatur und in die Einarbeitung der angegebenen
Referenzen verwendet. Dazu wurden die folgenden Literaturquellen
herangezogen: 

\begin{itemize}
  \setlength{\itemsep}{0mm}
  \item Jacobson, Booch, Rumbaugh: 
    The Unified Software Development Process \newline
    In Kapitel 3 ist eine Motivation der Use-Cases.
    Im Kapitel 6.3 ``From Vision to Requirements'' (u.a.) werden die
    ersten Schritte zur Anforderungserfassung ausf"uhrlich
    beschrieben. Eine detaillierte Beschreibung der Inception Phase
    findet sich in Kapitel 13.
    
  \item "Osterreicher: 
    Objektorientierte Software und UML \newline
    Es ist das Kapitel ``Anforderungsanalyse'' relevant. Insbesondere
    der Abschnitt ``Vorstudie'' mit einer Liste der der zu
    erstellenden Ergebnisdokumente und einer Checkliste!
    
  \item Sommerville: 
    Software Engineering \newline
    Enth"alt einen Anforderungskatalog.
    
  \item Vossen: Datenbank-Management-Systeme

  \item Artikel "uber XML im Computermagazin iX von 2/1999 und 6/1997
\end{itemize}

