1.1 --- a/development-case-content.tex	Mon Jan 14 20:48:46 2008 +0100
     1.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.3 @@ -1,198 +0,0 @@
     1.4 -\chapter{Einleitung}
     1.5 -
     1.6 -\section{Zweck}
     1.7 -
     1.8 -Dieses Dokument beschreibt den Entwicklungsprozess nach dem wir in unserem Projekt vorgehen.
     1.9 -
    1.10 -
    1.11 -\section{Definitionen und Abkürzungen}
    1.12 -
    1.13 -Die verwendeten Begriffe sind im Projekt-Glossar erklärt. Bei Bedarf kann dort nachgeschlagen werden.
    1.14 -
    1.15 -\textbf{Workflow}
    1.16 -Aufeinander folgende Aktivitäten die ein messbares Ergebnis erzeugen.
    1.17 -%The sequence of activities performed in a business that produces a result of observable value to an individual actor of the business.
    1.18 -
    1.19 -\textbf{Entwicklungsprozess}
    1.20 -Definiertes Vorgehensmodell zur Erstellung einer Software. Ein Entwicklungsprozess soll die Softwareentwicklung übersichtlicher gestalten und die Komplexität beherrscbar machen.
    1.21 -
    1.22 -\textbf{Zyklus}
    1.23 -Ein kompletter Durchlauf der vier Phasen: Konzeption (Inception), Entwurf (Elaboration), Konstruktion (Construction) und Übergabe (Transition).
    1.24 -%One complete pass through the four phases: inception, elaboration, construction and transition. The span of time between the beginning of the inception phase and the end of the transition phase.
    1.25 -
    1.26 -\textbf{Iteration}
    1.27 -Eine geplante Abfolge von Aktivitäten mit einem messbaren Ergebnis, die in einem Release enden (intern oder extern).
    1.28 -%A distinct sequence of activities with a base-lined plan and valuation criteria resulting in a release  (internal or external).
    1.29 -
    1.30 -\textbf{Phase}
    1.31 -Die Zeit zwischen zwei bedeutenden Projekt-Meilensteinen. Während einer Phase werden, eine festgelegte Menge an Aufgaben bearbeitet, Artefakte erstellt und die Entscheidung gefällt, ob man in die nächste Phase einsteigt, oder nicht.
    1.32 -%The time between two major project milestones, during which a well-defined set of objectives is met, artifacts are completed, and decisions are made to move or not move into the next phase.
    1.33 -
    1.34 -\textbf{RUP}
    1.35 -Der Rational Unified Process (RUP) ist ein objektorientiertes Vorgehensmodell zur Softwareentwicklung und ein kommerzielles Produkt der Firma Rational Software. Der RUP ist ein iterativer Entwicklungsprozess.
    1.36 -
    1.37 -
    1.38 -\textbf{Iterativer Entwicklungsprozess}
    1.39 -Ein Entwicklungsprozess, der in Iterationen unterteilt ist. Dies ermöglicht Flexibilität, Risiken werden frühzeitig erkannt und es wird berücksichtigt, dass sich Anforderungen während eines Projektes oftmals ändern.
    1.40 -
    1.41 -\textbf{Manntag}
    1.42 -Ein Manntag ist die Menge an Arbeit, die eine Person durchschnittlich an einem Arbeitstag (8 Stunden) schafft. Man verwendet diesen Begriff, um Schätzungen für die Gesamtmenge an Arbeit für die Erledigung einer Aufgabe zu errechnen.
    1.43 -
    1.44 -\textbf{Release}
    1.45 -%Die fertige und veröffentlichte Version einer Software wird als Release bezeichnet.
    1.46 -%A subset of the end-product that is the object of evaluation at a major milestone. A release is a stable, executable version of product, together with any artifacts necessary to use this release, such as release notes or installation instructions. A release can be internal or external. An internal release is used only by the development organization, as part of a milestone, or for a demonstration to users or customers. An external release (or delivery) is delivered to end users. A release is not necessarily a complete product, but can just be one step along the way, with its usefulness measured only from an engineering perspective. Releases act as a forcing function that drives the development team to get closure at regular intervals, avoiding the "90\% done, 90\% remaining" syndrome. See also prototype, baseline.
    1.47 -
    1.48 -
    1.49 -\section{Verweise}
    1.50 -
    1.51 -
    1.52 -
    1.53 -
    1.54 -
    1.55 -
    1.56 -%%%%%%%%%%%%%%
    1.57 -\chapter{Entwicklungsprozess}
    1.58 -\section{Überblick}
    1.59 -
    1.60 -Wir werden unser Projekt nach dem Rational Unified Process (kurz RUP) entwickeln.
    1.61 -
    1.62 -Der RUP ist ein dynamischer und iterativer Entwicklungsprozess, der das Projekt in zwei Dimensionen betrachtet.
    1.63 -Er ist ausführlich spezifiziert und umfangreich dokumentiert. (http://www-306.ibm.com/software/awdtools/rup/).
    1.64 -
    1.65 -An sich ist der RUP für große Projekte, mit vielen Mannjahren, ausgelegt. 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.66 -
    1.67 -
    1.68 -\section{Anpassungen}
    1.69 -
    1.70 -Es gilt also diesen mächtigen und umfangreichen Entwicklungsprozess für unser klares Projekt abzuspecken und anzupassen. 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.71 -Wir werden deshalb ein paar Ungenauigkeiten bei unserem Verhalten im Kauf nehmen; versuchen aber natürlich, uns möglichst nah an die Leitlinie RUP zu halten.
    1.72 -
    1.73 -Wir werden drei Zyklen des Projekts durchführen. Insgesamt soll das Projekt sechs Zyklen umfassen, von denen die letzten drei Zyklen aber nur grob geplant werden.
    1.74 -Jeder Zyklus wird circa vier Wochen umfassen (18 Manntage). An dessen Ende ein Release steht.
    1.75 -Iterationen innerhalb der Zyklen werden wir, aufgrund der kurzen Zyklen, außen vor lassen.
    1.76 -
    1.77 -Die einzelnen Phasen (zweite Dimension) in den Zyklen versuchen wir, so gut es geht, zu berücksichtigen.
    1.78 -
    1.79 -
    1.80 -
    1.81 -
    1.82 -
    1.83 -
    1.84 -\chapter{Projektplanung}
    1.85 -
    1.86 -siehe \emph{Projektplan} diesbezüglich
    1.87 -
    1.88 -
    1.89 -
    1.90 -
    1.91 -
    1.92 -\chapter{Kern-Workflows}
    1.93 -
    1.94 -
    1.95 -\subsection{Geschäftsprozessmodellierung}
    1.96 -(Business Modeling)
    1.97 -
    1.98 -Dokumentation der relevanten Geschäftsprozesse in Use Cases, mit dem Ziel eines gemeinsamen Verständnisses zwischen Entwicklern und Anwendern.
    1.99 -
   1.100 -\paragraph{Artefakte}
   1.101 -\begin{itemize}
   1.102 -	\item Glossary
   1.103 -	\item Use-Case
   1.104 -	\item Use-Case Model
   1.105 -	\item Vision
   1.106 -\end{itemize}
   1.107 -
   1.108 -
   1.109 -
   1.110 -\subsection{Anforderungen}
   1.111 -(Requirements)
   1.112 -
   1.113 -Ermitteln, was das System leisten soll. Die funktionalen Anforderungen sollen erfasst werden.
   1.114 -
   1.115 -\paragraph{Artefakte}
   1.116 -\begin{itemize}
   1.117 -	\item Use-Case
   1.118 -	\item Use-Case Model
   1.119 -	\item Vision
   1.120 -\end{itemize}
   1.121 -
   1.122 -
   1.123 -
   1.124 -\subsection{Analyse \& Design}
   1.125 -(Analysis \& Design)
   1.126 -
   1.127 -Aufbau und Technologie des Systems festlegen.
   1.128 -
   1.129 -\paragraph{Artefakte}
   1.130 -\begin{itemize}
   1.131 -	\item Software Architecture Document
   1.132 -\end{itemize}
   1.133 -
   1.134 -
   1.135 -
   1.136 -\subsection{Implementierung}
   1.137 -(Implementation)
   1.138 -
   1.139 -Systemteile entwickeln und zusammenfügen.
   1.140 -
   1.141 -\paragraph{Artefakte}
   1.142 -
   1.143 -
   1.144 -\subsection{Test}
   1.145 -(Testing)
   1.146 -
   1.147 -Funktionsweise des Systems gegen die Anforderungen prüfen.
   1.148 -
   1.149 -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.150 -
   1.151 -
   1.152 -
   1.153 -\subsection{Verteilung}
   1.154 -(Deployment)
   1.155 -
   1.156 -Auslieferung des Systems an den Kunden und Inbetriebnahme. Schulung der Benutzer.
   1.157 -
   1.158 -\paragraph{Artefakte}
   1.159 -
   1.160 -
   1.161 -
   1.162 -
   1.163 -\section{Unterstützungs-Workflows}
   1.164 -
   1.165 -\subsection{Konfigurations- \& Änderungsmanagement}
   1.166 -(Configuration \& Changemanagement)
   1.167 -
   1.168 -Verwaltung der zum Projekt gehörenden Daten. Versionierung und Konsistenz.
   1.169 -
   1.170 -\paragraph{Artefakte}
   1.171 -\begin{itemize}
   1.172 -	\item Project Repository
   1.173 -\end{itemize}
   1.174 -
   1.175 -
   1.176 -\subsection{Projektmanagement}
   1.177 -(Projectmanagement)
   1.178 -
   1.179 -Zwischen konkurrierenden Zielen vermitteln. Auf Risiken reagieren.
   1.180 -
   1.181 -\paragraph{Artefakte}
   1.182 -\begin{itemize}
   1.183 -	\item Software Development Plan
   1.184 -	\item Iteration Plan % FIXME
   1.185 -\end{itemize}
   1.186 -
   1.187 -
   1.188 -\subsection{Entwicklungsumgebung}
   1.189 -(Environment)
   1.190 -
   1.191 -Bereitstellung von Hardware, Software und Know-How.
   1.192 -
   1.193 -\paragraph{Artefakte}
   1.194 -\begin{itemize}
   1.195 -	\item Development Case
   1.196 -	\item Tools
   1.197 -	\item User Interface Guidlines % FIXME
   1.198 -\end{itemize}
   1.199 -
   1.200 -
   1.201 -

     2.1 --- a/development-case.tex	Mon Jan 14 20:48:46 2008 +0100
     2.2 +++ b/development-case.tex	Wed Jan 16 11:46:36 2008 +0100
     2.3 @@ -142,7 +142,217 @@
     2.4      %\clearpage
     2.5  %
     2.6  %   Inhalt
     2.7 -		\input{development-case-content}
     2.8 +%		\input{development-case-content}
     2.9 +
    2.10 +
    2.11 +
    2.12 +\chapter{Einleitung}
    2.13 +
    2.14 +\section{Zweck}
    2.15 +
    2.16 +Dieses Dokument beschreibt den Entwicklungsprozess nach dem wir in unserem Projekt vorgehen.
    2.17 +
    2.18 +
    2.19 +\section{Definitionen und Abkürzungen}
    2.20 +
    2.21 +Die verwendeten Begriffe sind im Projekt-Glossar erklärt. Bei Bedarf kann dort nachgeschlagen werden.
    2.22 +
    2.23 +\textbf{Workflow}
    2.24 +Aufeinander folgende Aktivitäten die ein messbares Ergebnis erzeugen.
    2.25 +%The sequence of activities performed in a business that produces a result of observable value to an individual actor of the business.
    2.26 +
    2.27 +\textbf{Entwicklungsprozess}
    2.28 +Definiertes Vorgehensmodell zur Erstellung einer Software. Ein Entwicklungsprozess soll die Softwareentwicklung übersichtlicher gestalten und die Komplexität beherrscbar machen.
    2.29 +
    2.30 +\textbf{Zyklus}
    2.31 +Ein kompletter Durchlauf der vier Phasen: Konzeption (Inception), Entwurf (Elaboration), Konstruktion (Construction) und Übergabe (Transition).
    2.32 +%One complete pass through the four phases: inception, elaboration, construction and transition. The span of time between the beginning of the inception phase and the end of the transition phase.
    2.33 +
    2.34 +\textbf{Iteration}
    2.35 +Eine geplante Abfolge von Aktivitäten mit einem messbaren Ergebnis, die in einem Release enden (intern oder extern).
    2.36 +%A distinct sequence of activities with a base-lined plan and valuation criteria resulting in a release  (internal or external).
    2.37 +
    2.38 +\textbf{Phase}
    2.39 +Die Zeit zwischen zwei bedeutenden Projekt-Meilensteinen. Während einer Phase werden, eine festgelegte Menge an Aufgaben bearbeitet, Artefakte erstellt und die Entscheidung gefällt, ob man in die nächste Phase einsteigt, oder nicht.
    2.40 +%The time between two major project milestones, during which a well-defined set of objectives is met, artifacts are completed, and decisions are made to move or not move into the next phase.
    2.41 +
    2.42 +\textbf{RUP}
    2.43 +Der Rational Unified Process (RUP) ist ein objektorientiertes Vorgehensmodell zur Softwareentwicklung und ein kommerzielles Produkt der Firma Rational Software. Der RUP ist ein iterativer Entwicklungsprozess.
    2.44 +
    2.45 +
    2.46 +\textbf{Iterativer Entwicklungsprozess}
    2.47 +Ein Entwicklungsprozess, der in Iterationen unterteilt ist. Dies ermöglicht Flexibilität, Risiken werden frühzeitig erkannt und es wird berücksichtigt, dass sich Anforderungen während eines Projektes oftmals ändern.
    2.48 +
    2.49 +\textbf{Manntag}
    2.50 +Ein Manntag ist die Menge an Arbeit, die eine Person durchschnittlich an einem Arbeitstag (8 Stunden) schafft. Man verwendet diesen Begriff, um Schätzungen für die Gesamtmenge an Arbeit für die Erledigung einer Aufgabe zu errechnen.
    2.51 +
    2.52 +\textbf{Release}
    2.53 +%Die fertige und veröffentlichte Version einer Software wird als Release bezeichnet.
    2.54 +%A subset of the end-product that is the object of evaluation at a major milestone. A release is a stable, executable version of product, together with any artifacts necessary to use this release, such as release notes or installation instructions. A release can be internal or external. An internal release is used only by the development organization, as part of a milestone, or for a demonstration to users or customers. An external release (or delivery) is delivered to end users. A release is not necessarily a complete product, but can just be one step along the way, with its usefulness measured only from an engineering perspective. Releases act as a forcing function that drives the development team to get closure at regular intervals, avoiding the "90\% done, 90\% remaining" syndrome. See also prototype, baseline.
    2.55 +
    2.56 +
    2.57 +\section{Verweise}
    2.58 +
    2.59 +
    2.60 +
    2.61 +
    2.62 +
    2.63 +
    2.64 +%%%%%%%%%%%%%%
    2.65 +\chapter{Entwicklungsprozess}
    2.66 +\section{Überblick}
    2.67 +
    2.68 +Wir werden unser Projekt nach dem Rational Unified Process (kurz RUP) entwickeln.
    2.69 +
    2.70 +Der RUP ist ein dynamischer und iterativer Entwicklungsprozess, der das Projekt in zwei Dimensionen betrachtet.
    2.71 +Er ist ausführlich spezifiziert und umfangreich dokumentiert. (http://www-306.ibm.com/software/awdtools/rup/).
    2.72 +
    2.73 +An sich ist der RUP für große Projekte, mit vielen Mannjahren, ausgelegt. 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.
    2.74 +
    2.75 +
    2.76 +\section{Anpassungen}
    2.77 +
    2.78 +Es gilt also diesen mächtigen und umfangreichen Entwicklungsprozess für unser klares Projekt abzuspecken und anzupassen. 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.
    2.79 +Wir werden deshalb ein paar Ungenauigkeiten bei unserem Verhalten im Kauf nehmen; versuchen aber natürlich, uns möglichst nah an die Leitlinie RUP zu halten.
    2.80 +
    2.81 +Wir werden drei Zyklen des Projekts durchführen. Insgesamt soll das Projekt sechs Zyklen umfassen, von denen die letzten drei Zyklen aber nur grob geplant werden.
    2.82 +Jeder Zyklus wird circa vier Wochen umfassen (18 Manntage). An dessen Ende ein Release steht.
    2.83 +Iterationen innerhalb der Zyklen werden wir, aufgrund der kurzen Zyklen, außen vor lassen.
    2.84 +
    2.85 +Die einzelnen Phasen (zweite Dimension) in den Zyklen versuchen wir, so gut es geht, zu berücksichtigen.
    2.86 +
    2.87 +
    2.88 +
    2.89 +
    2.90 +
    2.91 +
    2.92 +\chapter{Projektplanung}
    2.93 +
    2.94 +siehe \emph{Projektplan} diesbezüglich
    2.95 +
    2.96 +
    2.97 +
    2.98 +
    2.99 +
   2.100 +\chapter{Kern-Workflows}
   2.101 +
   2.102 +
   2.103 +\subsection{Geschäftsprozessmodellierung}
   2.104 +(Business Modeling)
   2.105 +
   2.106 +Dokumentation der relevanten Geschäftsprozesse in Use Cases, mit dem Ziel eines gemeinsamen Verständnisses zwischen Entwicklern und Anwendern.
   2.107 +
   2.108 +\paragraph{Artefakte}
   2.109 +\begin{itemize}
   2.110 +	\item Glossary
   2.111 +	\item Use-Case
   2.112 +	\item Use-Case Model
   2.113 +	\item Vision
   2.114 +\end{itemize}
   2.115 +
   2.116 +
   2.117 +
   2.118 +\subsection{Anforderungen}
   2.119 +(Requirements)
   2.120 +
   2.121 +Ermitteln, was das System leisten soll. Die funktionalen Anforderungen sollen erfasst werden.
   2.122 +
   2.123 +\paragraph{Artefakte}
   2.124 +\begin{itemize}
   2.125 +	\item Use-Case
   2.126 +	\item Use-Case Model
   2.127 +	\item Vision
   2.128 +\end{itemize}
   2.129 +
   2.130 +
   2.131 +
   2.132 +\subsection{Analyse \& Design}
   2.133 +(Analysis \& Design)
   2.134 +
   2.135 +Aufbau und Technologie des Systems festlegen.
   2.136 +
   2.137 +\paragraph{Artefakte}
   2.138 +\begin{itemize}
   2.139 +	\item Software Architecture Document
   2.140 +\end{itemize}
   2.141 +
   2.142 +
   2.143 +
   2.144 +\subsection{Implementierung}
   2.145 +(Implementation)
   2.146 +
   2.147 +Systemteile entwickeln und zusammenfügen.
   2.148 +
   2.149 +\paragraph{Artefakte}
   2.150 +
   2.151 +
   2.152 +\subsection{Test}
   2.153 +(Testing)
   2.154 +
   2.155 +Funktionsweise des Systems gegen die Anforderungen prüfen.
   2.156 +
   2.157 +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.
   2.158 +
   2.159 +
   2.160 +
   2.161 +\subsection{Verteilung}
   2.162 +(Deployment)
   2.163 +
   2.164 +Auslieferung des Systems an den Kunden und Inbetriebnahme. Schulung der Benutzer.
   2.165 +
   2.166 +\paragraph{Artefakte}
   2.167 +
   2.168 +
   2.169 +
   2.170 +
   2.171 +\section{Unterstützungs-Workflows}
   2.172 +
   2.173 +\subsection{Konfigurations- \& Änderungsmanagement}
   2.174 +(Configuration \& Changemanagement)
   2.175 +
   2.176 +Verwaltung der zum Projekt gehörenden Daten. Versionierung und Konsistenz.
   2.177 +
   2.178 +\paragraph{Artefakte}
   2.179 +\begin{itemize}
   2.180 +	\item Project Repository
   2.181 +\end{itemize}
   2.182 +
   2.183 +
   2.184 +\subsection{Projektmanagement}
   2.185 +(Projectmanagement)
   2.186 +
   2.187 +Zwischen konkurrierenden Zielen vermitteln. Auf Risiken reagieren.
   2.188 +
   2.189 +\paragraph{Artefakte}
   2.190 +\begin{itemize}
   2.191 +	\item Software Development Plan
   2.192 +	\item Iteration Plan % FIXME
   2.193 +\end{itemize}
   2.194 +
   2.195 +
   2.196 +\subsection{Entwicklungsumgebung}
   2.197 +(Environment)
   2.198 +
   2.199 +Bereitstellung von Hardware, Software und Know-How.
   2.200 +
   2.201 +\paragraph{Artefakte}
   2.202 +\begin{itemize}
   2.203 +	\item Development Case
   2.204 +	\item Tools
   2.205 +	\item User Interface Guidlines % FIXME
   2.206 +\end{itemize}
   2.207 +
   2.208 +
   2.209 +
   2.210 +
   2.211 +
   2.212 +
   2.213 +
   2.214 +
   2.215 +
   2.216 +
   2.217 +
   2.218 +
   2.219  
   2.220      \appendix
   2.221      \chapter{Glossar}