1.1 --- a/development-case.tex	Wed Jan 16 21:53:40 2008 +0100
     1.2 +++ b/development-case.tex	Mon Jan 21 07:15:04 2008 +0100
     1.3 @@ -115,14 +115,16 @@
     1.4        \addsec{Version dieses Dokuments}
     1.5        \begin{tabular}{|p{1.5cm}|p{3.cm}|p{1.6cm}|p{2cm}|p{1.4cm}|p{4cm}|}
     1.6          \hline
     1.7 -        \multicolumn{5}{|l}{\parbox[0pt][3.4em][l]{12cm}{\vspace{0.2cm}\large Dokument: \textbf{Name des Dokumentes} \newline \emph{ Online-Seminarbuchungssystem}}} & \multicolumn{1}{r|}{\parbox[0pt][3.4em][r]{1.9cm}{\includegraphics*[scale=0.25]{pictures/png/logo_hsu}}} \\
     1.8 +        \multicolumn{5}{|l}{\parbox[0pt][3.4em][l]{12cm}{\vspace{0.2cm}\large Dokument: \textbf{Development Case} \newline \emph{ Online-Seminarbuchungssystem}}} & \multicolumn{1}{r|}{\parbox[0pt][3.4em][r]{1.9cm}{\includegraphics*[scale=0.25]{pictures/png/logo_hsu}}} \\
     1.9          \hline\hline
    1.10          \hoehe{\textbf{Version}} & \textbf{Person} & \textbf{Aktion} & \textbf{Datum} & \textbf{Status} & \textbf{Kommentar} \\
    1.11          \hline\hline
    1.12 -        0.1 & Markus Schnalke & E & 2007-11-27 & O & Erste Version \\ \hline
    1.13 -        0.2 & Markus Schnalke & AE & 2008-01-13 & O & Neue Struktur des Dokuments \\ \hline
    1.14 -        0.3 & Markus Schnalke & AE & 2008-01-14 & O & Glossar erstellt \\ \hline
    1.15 -        0.4 & Markus Schnalke & AE & 2008-01-16 & O & Struktur überarbeitet; Glossar ausgelagert \\ \hline
    1.16 +        0.1 & Markus Schnalke & E & 2007-11-27 & A & Erste Version \\ \hline
    1.17 +        0.2 & Markus Schnalke & AE & 2008-01-13 & A & Neue Struktur des Dokuments \\ \hline
    1.18 +        0.3 & Markus Schnalke & AE & 2008-01-14 & A & Glossar erstellt \\ \hline
    1.19 +        0.4 & Markus Schnalke & AE & 2008-01-16 & A & Struktur überarbeitet; Glossar ausgelagert \\ \hline
    1.20 +        0.4.1 & Karl Oppermann & QS & 2008-01-17 & A & Allgemeines Review \\ \hline
    1.21 +        0.5 & Markus Schnalke & AE & 2008-01-18 & O &  \\ \hline
    1.22        \end{tabular}
    1.23  {\footnotesize\vspace*{-0.1cm}Aktion: E – Erstellung; AE – \"{A}nderung; QS – Review; AB – Abnahme} \par
    1.24  {\footnotesize\vspace*{-0.4cm} Status: O – Offen; D – Diskussion; A – Akzeptiert}
    1.25 @@ -159,9 +161,9 @@
    1.26  \section{Verweise auf andere Artefakte}
    1.27  
    1.28  \begin{itemize}
    1.29 -	\item \textbf{Glossar}: Dort werden die verwendeten Fachbegriffe erklärt.
    1.30 -	\item \textbf{Software Development Plan}: Der \emph{Development Case} ist ein Unterdokument des \emph{Software Development Plan}s.
    1.31 -	\item \textbf{Projekt Plan}: Die konkrete zeitliche Planung.
    1.32 +	\item \textbf{Glossary}: Dort werden die verwendeten Fachbegriffe erklärt.
    1.33 +	\item \textbf{Software Development Plan}: Der \emph{Development Case} ist ein Unterdokument des \emph{Software Development Plans}.
    1.34 +	\item \textbf{Project Plan}: Die konkrete zeitliche Planung. (Der Project Plan findet sich im Software Development Plan.)
    1.35  	\item
    1.36  	\item
    1.37  	\item
    1.38 @@ -178,18 +180,19 @@
    1.39  
    1.40  Wir werden unser Projekt nach dem \emph{Rational Unified Process} (kurz RUP) entwickeln.
    1.41  
    1.42 -Der RUP ist ein dynamischer und iterativer Entwicklungsprozess, der das Projekt in zwei Dimensionen betrachtet.
    1.43 -Er ist ausführlich spezifiziert und umfangreich dokumentiert. (\texttt{http://www-306.ibm.com/software/awdtools/rup/}).
    1.44 +Der RUP ist ein dynamischer und iterativer Entwicklungsprozess, der das Projekt in zwei Dimensionen (zeitlich und inhaltlich) betrachtet.
    1.45 +Er ist ausführlich spezifiziert und umfangreich dokumentiert.
    1.46  
    1.47 -An sich ist der RUP für große Projekte, mit vielen Mannjahren, ausgelegt. Für unser kleines Projekt (85 Manntage) ist er eher weniger gut geeignet. Wir haben uns trotzdem für den RUP entscheiden, da wir ihn in der Vorlesung Softwaretechnik 1 ausführlich behandelt hatten und wir dieses Theoriewissen nun in der Praxis anwenden wollen.
    1.48 +An sich ist der RUP für große Projekte, mit vielen Mannjahren, ausgelegt. Für unser kleines Projekt (90 Manntage) ist er eher weniger gut geeignet. Wir haben uns trotzdem für den RUP entscheiden, da wir ihn in der Vorlesung Softwaretechnik 1 ausführlich behandelt hatten und wir dieses Theoriewissen nun in der Praxis anwenden wollen.
    1.49  
    1.50 -Um einen Entwicklungsprozess für ein Projekt anzuwenden, muss er für eben dieses Projekt angepasst werden. Als Daumenregel kann man sagen: Je aufwändiger ein Prozess ist, desto stärker wird er auf ein spezifisches Projekt zurecht geschneidert werden müssen.
    1.51 +Um einen Entwicklungsprozess für ein Projekt anzuwenden, muss er für eben dieses Projekt angepasst werden. Als Daumenregel kann man sagen: Je aufwändiger ein Prozess ist, desto stärker wird er auf ein spezifisches Projekt zurechtgeschneidert werden müssen.
    1.52  
    1.53  Wir haben also diesen mächtigen und umfangreichen Rational Unified Process für unser kleines Projekt abgespeckt und angepasst. Diese Anpassungen betreffen dabei natürlich beide Dimensionen, die zeitliche (Zyklen, Phasen, Iterationen) und die inhaltliche (Workflows).
    1.54  
    1.55  Wie unsere Adaptation des RUP genau aussieht, das beschreibt diese Dokument.
    1.56  
    1.57  
    1.58 +\newpage
    1.59  \section{Der RUP auf einen Blick}
    1.60  
    1.61  Natürlich kann man diesen umfassenden Entwicklungsprozess nicht in einem Bild komplett abbilden, jedoch zeigt die nachfolgende Grafik doch sehr schön, wie die Entwicklung im Bezug auf die zwei Dimensionen aussieht. Dieser Übersichtplan, soll primär eine greifbare Vorstellung des Prozesses geben. Sie kann quasi als ``Landkarte'' für die in diesem Dokument beschriebene ``Landschaft'' zur Hilfe genommen werden.
    1.62 @@ -213,9 +216,11 @@
    1.63  
    1.64  \section{Anpassungen}
    1.65  
    1.66 -Wir werden drei Zyklen des Projekts durchführen. Insgesamt wird das Projekt mehr als diese drei Zyklen umfassen. Unser Team aber nur eben diese ersten drei Zyklen durchführen.
    1.67 +Wir werden in unserem Projekt drei Zyklen durchführen. Anschließend wird das Projekt nicht abgeschlossen sein. Für unser Team endet dann zwar die Arbeit an diesem Projekt, ein anderes Team kann die Arbeit zu einem beliebigen späteren Zeitpunkt wieder aufgreifen und daran weiterarbeiten.
    1.68 +% FIXME: was ist das/unser Projekt (3Zyklen oder das komplette)?
    1.69  
    1.70 -Jeder Zyklus wird circa vier Wochen umfassen (18 Manntage). An dessen Ende jeweils ein Release stehen wird. (Näheres zu den Releases findet sich im \emph{Project Plan}.)
    1.71 +Jeder der drei Zyklen wird circa vier Wochen (18 Manntage %FIXME
    1.72 +		) umfassen. An dessen Ende jeweils ein Release stehen wird. (Näheres zu den Releases findet sich im \emph{Software Development Plan}.)
    1.73  
    1.74  Iterationen innerhalb der Zyklen werden wir, auf Grund der kurzen Zyklen, komplett außen vor lassen.
    1.75  
    1.76 @@ -225,20 +230,22 @@
    1.77  
    1.78  \subsection{Probleme und Konsequenzen}
    1.79  
    1.80 -Der RUP ist sehr umfangreich und 
    1.81 -Dies ist natürlich nicht ganz einfach, da unsere 85 Manntage realistischerweise eher einer einzelnen Iteration entsprechen, als den drei Zyklen, die wir für uns geplant haben.
    1.82 +Der RUP ist sehr umfangreich und mächtig. Unser Projekt dagegen, ist ziemlich klein, und so bedarf es größerer Anpassungen, um den Entwicklungsprozess unserem Projekt entsprechend zurechtzustutzen. %FIXME: mit "stuzen" oder "stutzen"??
    1.83 +
    1.84 +Hier ein Anhaltspunkt, um welche Größenordnungen es dabei geht: Unsere 90 Manntage, entsprechen realistischerweise eher einer einzelnen Iteration, als den drei Zyklen, die wir für uns geplant haben.
    1.85 +
    1.86 +Dabei muss auch bedacht werden, dass pro Phase ganz grob nur etwa 4 Manntage (d.h. circa 4 Stunden pro Person) zur Verfügung stehen. Wenn man auch an die unterschiedlichen Arbeitszeiten der einzelnen Personen denkt, so dürfte klar sein, dass wir unserem Konzept, dem RUP, nur annäherungsweise folgen können.
    1.87  
    1.88  Wir werden deshalb ein paar Ungenauigkeiten bei unserem Verhalten im Kauf nehmen; versuchen aber natürlich, uns möglichst nahe an die Leitlinie RUP zu halten.
    1.89  
    1.90 -Dabei muss allerdings auch bedacht werden, dass pro Phase ganz grob nur etwa 4 Manntage (d.h. circa 4 Stunden pro Person) zur Verfügung stehen. Wenn man auch an die unterschiedlichen Arbeitszeiten der einzelnen Personen denkt, so dürfte klar sein, dass wir unserem Konzept, dem RUP, nur annäherungsweise folgen können.
    1.91 -
    1.92 +Trotz all dieser Schwierigkeiten finden wir es wichtig, diesen Prozess zu wählen, weil die theoretischen Inhalte der Vorlesung ``Softwaretechnik 1'' erst durch ihre tatsächliche Anwendung im realen Projekt vollständig zur Entfaltung kommen. So befassen wir uns intensiv (theoretisch sowie praktisch) mit einem Entwicklungsprozess, anstatt zwei Prozesse nur teilweise kennenzulernen.
    1.93  
    1.94  
    1.95  \section{Konkrete Projektplanung}
    1.96  
    1.97 -Die konkrete Planung der einzelnen Zyklen und ihrer Meilensteine befindet sich im \emph{Projekt Plan}. Dieser gibt eine zeitliche und inhaltliche Komplettübersicht über das Projekt.
    1.98 +Die konkrete Planung der einzelnen Zyklen und ihrer Meilensteine sollen sich laut RUP im \emph{Projekt Plan} befinden. Dieser gibt eine zeitliche und inhaltliche Komplettübersicht über das Projekt.
    1.99  
   1.100 -Zudem ist nach dem RUP auch ein \emph{Iterations Plan} definiert, in dem ausgehend von der aktuellen Iteration, jeweils die nächste geplant wird. Dieses Artefakt existiert bei uns nicht, da wir keine Iterationen haben. Wir haben unseren \emph{Iterations Plan} mit dem \emph{Projekt Plan} verschmolzen.
   1.101 +Zudem ist nach dem RUP auch ein \emph{Iterations Plan} definiert, in dem ausgehend von der aktuellen Iteration, jeweils die nächste geplant wird. Dieses Artefakt existiert bei uns nicht, da wir keine Iterationen haben. Wir haben die Inhalte unseres Iterations Plans mit denen des Projekt Plans verschmolzen, und sie in den \emph{Software Development Plan} integriert.
   1.102  
   1.103  
   1.104  
   1.105 @@ -253,43 +260,43 @@
   1.106  
   1.107  Dabei gibt es vier Elemente:
   1.108  \begin{itemize}
   1.109 -	\item Arbeiter, das \emph{Wer}. Der \emph{Arbeiter} ist eine Rolle, die jemand inne hat. Eine einzelne Person, oder eine Gruppe kann eine solche Rolle haben. Andererseits kann auch eine Person mehrer Rollen haben. In jedem Fall muss klar sein, wer welche Rolle hat. Diese Information findet sich bei uns im \emph{Organigramm}.
   1.110 -	\item Aktivität, das \emph{Wie}. Eine Aktivität ist ein bestimmte Arbeitseinheit, die ein bestimmter Arbeiter erledigen soll. Üblicherweise soll dabei ein Artefakt erstellt oder aktualisiert werden.
   1.111 +	\item Rolle, das \emph{Wer}. Die \emph{Rolle} ist eine Verantwortlichkeit, die jemand hat. Eine einzelne Person, oder eine Gruppe kann eine solche Rolle haben. Andererseits kann auch eine Person mehrer Rollen haben. In jedem Fall muss klar sein, wer welche Rolle hat. Diese Information findet sich bei uns im \emph{Organigramm} (siehe Software Development Plan).
   1.112 +	\item Aktivität, das \emph{Wie}. Eine Aktivität ist ein bestimmte Arbeitseinheit, die der Arbeiter mit einer bestimmten Rolle erledigen muss. Üblicherweise soll dabei ein Artefakt erstellt oder aktualisiert werden.
   1.113  	\item Artefakt, das \emph{Was}. Ein Artefakt ist Information, die von einem Prozess verwendet, verändert oder produziert wird. Artefakte sind häufig Diagramme, Quellcode, Textdokumente und ähnliches.
   1.114 -	\item Workflow, das \emph{Wann}. Ein Workflow ist eine Aneinanderreihung von Aktivitäten, die ein Ergebnis von messbarem Wert erzeugen. Im Worflow werden die ersten drei Elemente (Arbeiter, Aktivität und Artefakt) zu einer konkret wertschaffenden Struktur zusammengebaut.
   1.115 +	\item Workflow, das \emph{Wann}. Ein Workflow ist eine Aneinanderreihung von Aktivitäten, die ein Ergebnis von messbarem Wert erzeugen. Im Worflow werden die ersten drei Elemente (Rolle, Aktivität und Artefakt) zu einer direkt wertschaffenden Struktur zusammengebaut.
   1.116  \end{itemize}
   1.117  
   1.118 -\section{Kern-Workflows}
   1.119 +\section{Core Workflows}
   1.120  
   1.121 -\subsection{Geschäftsprozessmodellierung}
   1.122 -(Business Modeling)
   1.123 +\subsection{Business Modeling}
   1.124 +(Geschäftsprozessmodellierung)
   1.125  
   1.126  Dokumentation der relevanten Geschäftsprozesse in Use Cases, mit dem Ziel eines gemeinsamen Verständnisses zwischen Entwicklern und Anwendern.
   1.127  
   1.128  \paragraph{Artefakte}
   1.129  \begin{itemize}
   1.130 -	\item Glossar
   1.131 -	\item Business Use-Cases
   1.132 +	\item Glossary
   1.133 +	\item Business Use Cases
   1.134  \end{itemize}
   1.135  
   1.136  
   1.137  
   1.138 -\subsection{Anforderungen}
   1.139 -(Requirements)
   1.140 +\subsection{Requirements}
   1.141 +(Anforderungen)
   1.142  
   1.143  Ermitteln, was das System leisten soll. Die funktionalen Anforderungen sollen erfasst werden.
   1.144  
   1.145  \paragraph{Artefakte}
   1.146  \begin{itemize}
   1.147 -	\item Use-Case
   1.148 -	\item Use-Case Modell
   1.149  	\item Vision
   1.150 +	\item Use Case
   1.151 +	\item Use Case Diagram
   1.152  \end{itemize}
   1.153  
   1.154  
   1.155  
   1.156 -\subsection{Analyse \& Design}
   1.157 -(Analysis \& Design)
   1.158 +\subsection{Analysis \& Design}
   1.159 +(Analyse \& Design)
   1.160  
   1.161  Aufbau und Technologie des Systems festlegen. Festlegung wie wird das System realisiert wird.
   1.162  
   1.163 @@ -300,16 +307,16 @@
   1.164  
   1.165  
   1.166  
   1.167 -\subsection{Implementierung}
   1.168 -(Implementation)
   1.169 +\subsection{Implementation}
   1.170 +(Implementierung)
   1.171  
   1.172  Systemteile entwickeln und zusammenfügen. Komponententests.
   1.173  
   1.174  \paragraph{Artefakte}
   1.175  
   1.176  
   1.177 -\subsection{Test}
   1.178 -(Testing)
   1.179 +\subsection{Testing}
   1.180 +(Test)
   1.181  
   1.182  Test des Zusammenspiels der Komponenten. Funktionsweise des Systems gegen die Anforderungen prüfen.
   1.183  
   1.184 @@ -317,8 +324,8 @@
   1.185  
   1.186  
   1.187  
   1.188 -\subsection{Verteilung}
   1.189 -(Deployment)
   1.190 +\subsection{Deployment}
   1.191 +(Verteilung)
   1.192  
   1.193  Auslieferung des Systems an den Kunden und Inbetriebnahme. Schulung der Benutzer.
   1.194  
   1.195 @@ -327,10 +334,10 @@
   1.196  
   1.197  
   1.198  
   1.199 -\section{Unterstützungs-Workflows}
   1.200 +\section{Supplymentary Workflows} %FIXME: korrekter Name?
   1.201  
   1.202 -\subsection{Konfigurations- \& Änderungsmanagement}
   1.203 -(Configuration \& Changemanagement)
   1.204 +\subsection{Configuration \& Changemanagement}
   1.205 +(Konfigurations- \& Änderungsmanagement)
   1.206  
   1.207  Verwaltung der zum Projekt gehörenden Daten. Versionierung und Konsistenz.
   1.208  
   1.209 @@ -340,29 +347,26 @@
   1.210  \end{itemize}
   1.211  
   1.212  
   1.213 -\subsection{Projektmanagement}
   1.214 -(Projectmanagement)
   1.215 +\subsection{Projectmanagement}
   1.216 +(Projektmanagement)
   1.217  
   1.218  Zwischen konkurrierenden Zielen vermitteln. Auf Risiken reagieren.
   1.219  
   1.220  \paragraph{Artefakte}
   1.221  \begin{itemize}
   1.222 -	\item Software Development Plan
   1.223 -	\item Risikoliste
   1.224 -	\item Iteration Plan % FIXME
   1.225 +	\item Software Development Plan (Project Plan)
   1.226 +	\item Risklist
   1.227  \end{itemize}
   1.228  
   1.229  
   1.230 -\subsection{Entwicklungsumgebung}
   1.231 -(Environment)
   1.232 +\subsection{Environment}
   1.233 +(Entwicklungsumgebung)
   1.234  
   1.235  Bereitstellung von Hardware, Software und Know-How.
   1.236  
   1.237  \paragraph{Artefakte}
   1.238  \begin{itemize}
   1.239  	\item Development Case
   1.240 -	\item Tools
   1.241 -	\item User Interface Guidlines % FIXME
   1.242  \end{itemize}
   1.243  
   1.244  
   1.245 @@ -381,13 +385,13 @@
   1.246      %\chapter{Glossar}
   1.247      \chapter{Quellen}
   1.248  			\begin{itemize}
   1.249 -				\item Dokumentation zum \emph{Rational Unified Process}
   1.250 +				\item Dokumentation zum \emph{Rational Unified Process} (\texttt{http://www-306.ibm.com/software/awdtools/rup/})
   1.251  				\item Skript von Herrn Baer zur Vorlesung \emph{Softwaretechnik 1} an der Hochschule Ulm
   1.252  				\item http://wikipedia.org
   1.253  				\item \emph{Rational Unified Process - Best Practices for Software Development Teams}
   1.254  			\end{itemize}
   1.255  
   1.256 -			Anmerkung zur \ref{fig:rationalunifiedprocess}: This image is from the Rational Unified Process (software product) version 2003.06.12.01. This image is copyright by Rational Software Corporation, now a division of IBM.
   1.257 +			Anmerkung zur Abbildung \ref{fig:rationalunifiedprocess}: This image is from the Rational Unified Process (software product) version 2003.06.12.01. This image is copyright by Rational Software Corporation, now a division of IBM.
   1.258  
   1.259  
   1.260