1.1 --- a/development-case.tex	Mon Jan 21 07:15:04 2008 +0100
     1.2 +++ b/development-case.tex	Mon Jan 21 20:31:34 2008 +0100
     1.3 @@ -65,12 +65,12 @@
     1.4  \automark[section]{section}
     1.5  \setheadwidth{15.8cm}
     1.6  \ihead{\headmark}
     1.7 -\ihead{Online Seminarbuchungssystem}
     1.8 +\ihead{Development Case}
     1.9  \chead{{\color{blue}\color{black}\rule[-10pt]{18.4cm}{0.1pt}\color{black}}}
    1.10  \ohead{\headmark}
    1.11  \setfootwidth[-74pt]{18.3cm}
    1.12  \setfootsepline[foot]{.1pt}
    1.13 -\ifoot{} %~~~~~~~~~~~~~~~~~~~\footnotesize Christoph Galler}
    1.14 +\ifoot{\hspace{2.6cm}\footnotesize Gruppe 2: Seminarverwaltungssystem (Topcased)}
    1.15  \cfoot{}
    1.16  \ofoot{\footnotesize Seite \thepage} % ~von \pageref{LastPage}}
    1.17  \renewcommand*{\chapterpagestyle}{scrheadings}
    1.18 @@ -91,25 +91,53 @@
    1.19      {\hspace*{11cm}\includegraphics*[scale=0.5]{pictures/png/logo_hsu_klein}}
    1.20      \begin{center}
    1.21          \vspace*{1.9cm}
    1.22 -        {\normalsize\textsc{Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, \\Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler}} \par
    1.23 +        {\normalsize\textsc{Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu,
    1.24 +Dimitar Dimitrov, \\Karl Oppermann, Nathalie Hrycej, Markus Schnalke,
    1.25 +Christoph Galler}} \par
    1.26          \vspace*{0.6cm}
    1.27 -        \Large \textbf{Online-Seminarbuchungssystem} \par
    1.28 +        \large \textbf{Modellgetriebene Softwareentwicklung auf Basis von
    1.29 +TOPCASED am Beispiel eines Seminarverwaltungssystems} \par
    1.30          \Huge \textbf{Development Case} \par
    1.31          \vspace*{0.8cm}
    1.32 -        \Large \textbf{Verfasser: Markus Schnalke} \par
    1.33 -        {\large{} \par
    1.34 +        {\Large{} \par
    1.35          \vspace*{0.7cm}
    1.36          {\textsc{Ulm, \today}}} \par
    1.37 -        \vspace*{5cm}
    1.38 +        \vspace*{4.5cm}
    1.39          {\normalsize\textsc{Betreut durch: \\
    1.40          Prof. Dr. Klaus Baer \\
    1.41          Hochschule Ulm \\
    1.42 -        Prittwitzstra{\ss}e 10\\
    1.43 +        Prittwitzstraße 10\\
    1.44          89075 Ulm\\}}
    1.45 -	\end{center}
    1.46 +        \end{center}
    1.47          \vfill
    1.48   \end{titlepage}
    1.49  
    1.50 +
    1.51 +
    1.52 +%    \begin{titlepage}
    1.53 +%    \vspace*{-0cm}
    1.54 +%    {\hspace*{11cm}\includegraphics*[scale=0.5]{pictures/png/logo_hsu_klein}}
    1.55 +%    \begin{center}
    1.56 +%        \vspace*{1.9cm}
    1.57 +%        {\normalsize\textsc{Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, \\Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler}} \par
    1.58 +%        \vspace*{0.6cm}
    1.59 +%        \Large \textbf{Online-Seminarbuchungssystem} \par
    1.60 +%        \Huge \textbf{Development Case} \par
    1.61 +%        \vspace*{0.8cm}
    1.62 +%        \Large \textbf{Verfasser: Markus Schnalke} \par
    1.63 +%        {\large{} \par
    1.64 +%        \vspace*{0.7cm}
    1.65 +%        {\textsc{Ulm, \today}}} \par
    1.66 +%        \vspace*{5cm}
    1.67 +%        {\normalsize\textsc{Betreut durch: \\
    1.68 +%        Prof. Dr. Klaus Baer \\
    1.69 +%        Hochschule Ulm \\
    1.70 +%        Prittwitzstra{\ss}e 10\\
    1.71 +%        89075 Ulm\\}}
    1.72 +%	\end{center}
    1.73 +%        \vfill
    1.74 +% \end{titlepage}
    1.75 +
    1.76  %    \addsec{Bitte beachten}
    1.77        Version vom \today: Das Dokument befindet sich noch im Aufbau, \"{A}nderungen sind dadurch jederzeit M\"{o}glich.
    1.78        \addsec{Version dieses Dokuments}
    1.79 @@ -119,12 +147,13 @@
    1.80          \hline\hline
    1.81          \hoehe{\textbf{Version}} & \textbf{Person} & \textbf{Aktion} & \textbf{Datum} & \textbf{Status} & \textbf{Kommentar} \\
    1.82          \hline\hline
    1.83 -        0.1 & Markus Schnalke & E & 2007-11-27 & A & Erste Version \\ \hline
    1.84 -        0.2 & Markus Schnalke & AE & 2008-01-13 & A & Neue Struktur des Dokuments \\ \hline
    1.85 -        0.3 & Markus Schnalke & AE & 2008-01-14 & A & Glossar erstellt \\ \hline
    1.86 -        0.4 & Markus Schnalke & AE & 2008-01-16 & A & Struktur überarbeitet; Glossar ausgelagert \\ \hline
    1.87 +        0.1 & Markus Schnalke & E & 2007-11-27 & O & Erste Version \\ \hline
    1.88 +        0.2 & Markus Schnalke & AE & 2008-01-13 & O & Neue Struktur des Dokuments \\ \hline
    1.89 +        0.4 & Markus Schnalke & AE & 2008-01-16 & A & Struktur überarbeitet \\ \hline
    1.90          0.4.1 & Karl Oppermann & QS & 2008-01-17 & A & Allgemeines Review \\ \hline
    1.91 -        0.5 & Markus Schnalke & AE & 2008-01-18 & O &  \\ \hline
    1.92 +        0.5 & Markus Schnalke & AE & 2008-01-18 & A & Überarbeitung; Fachbegriffe jetzt englisch \\ \hline
    1.93 +        0.5.1 & Veysel Imamoglu & QS & 2008-01-18 & A & Rechtschreibkorrektur \\ \hline
    1.94 +        0.6 & Markus Schnalke & AE & 2008-01-21 & O &  \\ \hline
    1.95        \end{tabular}
    1.96  {\footnotesize\vspace*{-0.1cm}Aktion: E – Erstellung; AE – \"{A}nderung; QS – Review; AB – Abnahme} \par
    1.97  {\footnotesize\vspace*{-0.4cm} Status: O – Offen; D – Diskussion; A – Akzeptiert}
    1.98 @@ -183,13 +212,13 @@
    1.99  Der RUP ist ein dynamischer und iterativer Entwicklungsprozess, der das Projekt in zwei Dimensionen (zeitlich und inhaltlich) betrachtet.
   1.100  Er ist ausführlich spezifiziert und umfangreich dokumentiert.
   1.101  
   1.102 -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.103 +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 entschieden, da wir ihn in der Vorlesung Softwaretechnik 1 ausführlich behandelt hatten und wir dieses Theoriewissen nun in der Praxis anwenden wollen.
   1.104  
   1.105  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.106  
   1.107  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.108  
   1.109 -Wie unsere Adaptation des RUP genau aussieht, das beschreibt diese Dokument.
   1.110 +Wie unsere Adaptation des RUP genau aussieht, das beschreibt dieses Dokument.
   1.111  
   1.112  
   1.113  \newpage
   1.114 @@ -219,7 +248,7 @@
   1.115  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.116  % FIXME: was ist das/unser Projekt (3Zyklen oder das komplette)?
   1.117  
   1.118 -Jeder der drei Zyklen wird circa vier Wochen (18 Manntage %FIXME
   1.119 +Jeder der drei Zyklen wird circa fünf Wochen (30 Manntage %FIXME
   1.120  		) umfassen. An dessen Ende jeweils ein Release stehen wird. (Näheres zu den Releases findet sich im \emph{Software Development Plan}.)
   1.121  
   1.122  Iterationen innerhalb der Zyklen werden wir, auf Grund der kurzen Zyklen, komplett außen vor lassen.
   1.123 @@ -271,12 +300,16 @@
   1.124  \subsection{Business Modeling}
   1.125  (Geschäftsprozessmodellierung)
   1.126  
   1.127 -Dokumentation der relevanten Geschäftsprozesse in Use Cases, mit dem Ziel eines gemeinsamen Verständnisses zwischen Entwicklern und Anwendern.
   1.128 +\paragraph{Zweck}
   1.129 +Dokumentation der relevanten Geschäftsprozesse in Use Cases, um ein gemeinsames Verständniss zwischen Entwicklern und Anwendern zu schaffen.
   1.130 +
   1.131 +\paragraph{Anpassungen}
   1.132 +Keine besonderen.
   1.133  
   1.134  \paragraph{Artefakte}
   1.135  \begin{itemize}
   1.136  	\item Glossary
   1.137 -	\item Business Use Cases
   1.138 +	\item Business Use Cases %% FIXME
   1.139  \end{itemize}
   1.140  
   1.141  
   1.142 @@ -284,8 +317,12 @@
   1.143  \subsection{Requirements}
   1.144  (Anforderungen)
   1.145  
   1.146 +\paragraph{Zweck}
   1.147  Ermitteln, was das System leisten soll. Die funktionalen Anforderungen sollen erfasst werden.
   1.148  
   1.149 +\paragraph{Anpassungen}
   1.150 +Keine besonderen.
   1.151 +
   1.152  \paragraph{Artefakte}
   1.153  \begin{itemize}
   1.154  	\item Vision
   1.155 @@ -298,8 +335,14 @@
   1.156  \subsection{Analysis \& Design}
   1.157  (Analyse \& Design)
   1.158  
   1.159 +\paragraph{Zweck}
   1.160  Aufbau und Technologie des Systems festlegen. Festlegung wie wird das System realisiert wird.
   1.161  
   1.162 +\paragraph{Anpassungen}
   1.163 +Die Technologie und Teile der Umsetzung sind durch das Projekt vorgegeben und somit fix.
   1.164 +
   1.165 +Zum jetzigen Zeitpunkt ist unser hauptsächliches Bestreben, uns in die neue Technologie einzuarbeiten. Was damit dann später architektonisch möglich ist, und wo Grenzen sitzen, ist noch unklar. Unsere Umsetzung dieses Workflows ist deshalb noch recht weitläufig und frei. Sobald unsere Kenntnis über die Möglichkeiten der Technologie groß genug ist, wird dieser Workflow zunehmend an Bedeutung gewinnen.
   1.166 +
   1.167  \paragraph{Artefakte}
   1.168  \begin{itemize}
   1.169  	\item Software Architecture Document
   1.170 @@ -307,29 +350,52 @@
   1.171  
   1.172  
   1.173  
   1.174 +
   1.175  \subsection{Implementation}
   1.176  (Implementierung)
   1.177  
   1.178 +\paragraph{Zweck}
   1.179  Systemteile entwickeln und zusammenfügen. Komponententests.
   1.180  
   1.181 +\paragraph{Anpassungen}
   1.182 +In dieser frühen Phase des Projekts besteht dieser Workflow in erster Line aus der Entwicklung von Prototypen jeder Art (Modelle, Templates, etc). Mit diesen wollen wir die Technologie erforschen.
   1.183 +
   1.184 +Konkrete Artefakte werden nicht erstellt, weil es zum jetzigen Stand nicht sinnvoll wäre nach festen Plänen vorzugehen. Unser Kenntnissstand ändert sich sehr schnell und wir wollen flexibel reagieren können.
   1.185 +
   1.186  \paragraph{Artefakte}
   1.187 +Momentan keine.
   1.188 +
   1.189  
   1.190  
   1.191  \subsection{Testing}
   1.192  (Test)
   1.193  
   1.194 +\paragraph{Zweck}
   1.195  Test des Zusammenspiels der Komponenten. Funktionsweise des Systems gegen die Anforderungen prüfen.
   1.196  
   1.197 -Da wir eine neue Technologie erkunden, macht Test keinen wirklichen Sinn. Unser Ziel ist es, in kurzer Zeit möglichst viele Bereiche und Möglichkeiten zu erkunden. Dabei würde Testing nur bremsen. Unser Hauptaugenmerk ist es vorran zu kommen, nicht komplett fehlerfreie Ergebnisse zu liefern, deshalb verzichten wir komplett auf diesen Workflow.
   1.198 +\paragraph{Anpassungen}
   1.199 +Da wir eine neue Technologie erkunden, macht Test keinen wirklichen Sinn. Unser Ziel ist es, in kurzer Zeit möglichst viele Bereiche und Möglichkeiten zu erkunden. Dabei würde Testing nur bremsen. Unser Hauptaugenmerk ist es voran zu kommen, nicht komplett fehlerfreie Ergebnisse zu liefern, deshalb verzichten wir komplett auf diesen Workflow. So können wir die dadurch verfügbaren Ressourcen an anderer Stelle effektiv nutzen.
   1.200 +
   1.201 +Dies heißt aber keineswegs, dass wir ihn zum geeigneten Zeitpunkt nicht voll ausbauen werden.
   1.202 +
   1.203 +\paragraph{Artefakte}
   1.204 +Noch keine.
   1.205  
   1.206  
   1.207  
   1.208  \subsection{Deployment}
   1.209  (Verteilung)
   1.210  
   1.211 +\paragraph{Zweck}
   1.212  Auslieferung des Systems an den Kunden und Inbetriebnahme. Schulung der Benutzer.
   1.213  
   1.214 +\paragraph{Anpassungen}
   1.215 +Auch hier sparen wir um dafür die Entwicklung voran zu treiben.
   1.216 +
   1.217  \paragraph{Artefakte}
   1.218 +\begin{itemize}
   1.219 +	\item Release Notes (empfohlen) %FIXME rechtschreibung
   1.220 +\end{itemize}
   1.221  
   1.222  
   1.223  
   1.224 @@ -339,19 +405,30 @@
   1.225  \subsection{Configuration \& Changemanagement}
   1.226  (Konfigurations- \& Änderungsmanagement)
   1.227  
   1.228 +\paragraph{Zweck}
   1.229  Verwaltung der zum Projekt gehörenden Daten. Versionierung und Konsistenz.
   1.230  
   1.231 +\paragraph{Anpassungen}
   1.232 +Alle Daten müssen im Project Repository abgelegt werden. Dieses soll die zentrale Informationsstelle sein.
   1.233 +
   1.234 +Jeder Mitarbeiter darf an jeder Stelle des Projekts Änderungen durchführen.
   1.235 +
   1.236  \paragraph{Artefakte}
   1.237  \begin{itemize}
   1.238  	\item Project Repository
   1.239  \end{itemize}
   1.240  
   1.241  
   1.242 +
   1.243  \subsection{Projectmanagement}
   1.244  (Projektmanagement)
   1.245  
   1.246 +\paragraph{Zweck}
   1.247  Zwischen konkurrierenden Zielen vermitteln. Auf Risiken reagieren.
   1.248  
   1.249 +\paragraph{Anpassungen}
   1.250 +Keine besonderen.
   1.251 +
   1.252  \paragraph{Artefakte}
   1.253  \begin{itemize}
   1.254  	\item Software Development Plan (Project Plan)
   1.255 @@ -359,11 +436,16 @@
   1.256  \end{itemize}
   1.257  
   1.258  
   1.259 +
   1.260  \subsection{Environment}
   1.261  (Entwicklungsumgebung)
   1.262  
   1.263 +\paragraph{Zweck}
   1.264  Bereitstellung von Hardware, Software und Know-How.
   1.265  
   1.266 +\paragraph{Anpassungen}
   1.267 +Keine besonderen.
   1.268 +
   1.269  \paragraph{Artefakte}
   1.270  \begin{itemize}
   1.271  	\item Development Case