1.1 --- a/development-case.tex	Wed Jan 16 11:46:50 2008 +0100
     1.2 +++ b/development-case.tex	Wed Jan 16 21:53:40 2008 +0100
     1.3 @@ -119,12 +119,10 @@
     1.4          \hline\hline
     1.5          \hoehe{\textbf{Version}} & \textbf{Person} & \textbf{Aktion} & \textbf{Datum} & \textbf{Status} & \textbf{Kommentar} \\
     1.6          \hline\hline
     1.7 -        0.1 & Markus Schnalke & E & 2007-11-27 & O & Erste Version \\
     1.8 -        \hline
     1.9 -        0.2 & Markus Schnalke & AE & 2008-01-13 & O & Neue Struktur des Dokuments \\
    1.10 -        \hline
    1.11 -        0.3 & Markus Schnalke & AE & 2008-01-14 & O & Glossar erstellt \\
    1.12 -        \hline
    1.13 +        0.1 & Markus Schnalke & E & 2007-11-27 & O & Erste Version \\ \hline
    1.14 +        0.2 & Markus Schnalke & AE & 2008-01-13 & O & Neue Struktur des Dokuments \\ \hline
    1.15 +        0.3 & Markus Schnalke & AE & 2008-01-14 & O & Glossar erstellt \\ \hline
    1.16 +        0.4 & Markus Schnalke & AE & 2008-01-16 & O & Struktur überarbeitet; Glossar ausgelagert \\ \hline
    1.17        \end{tabular}
    1.18  {\footnotesize\vspace*{-0.1cm}Aktion: E – Erstellung; AE – \"{A}nderung; QS – Review; AB – Abnahme} \par
    1.19  {\footnotesize\vspace*{-0.4cm} Status: O – Offen; D – Diskussion; A – Akzeptiert}
    1.20 @@ -136,19 +134,17 @@
    1.21      \tableofcontents
    1.22  
    1.23      \clearpage
    1.24 -    %\setcounter{tocdepth}{3}
    1.25 -    %\renewcommand\contentsname{Detailliertes Inhaltsverzeichnis}
    1.26 -    %\tableofcontents
    1.27 -    %\clearpage
    1.28 -%
    1.29 -%   Inhalt
    1.30 -%		\input{development-case-content}
    1.31 +
    1.32 +
    1.33 +
    1.34 +
    1.35 +%   Content
    1.36  
    1.37  
    1.38  
    1.39  \chapter{Einleitung}
    1.40  
    1.41 -\section{Zweck}
    1.42 +\section{Zweck des Dokuments}
    1.43  
    1.44  Dieses Dokument beschreibt den Entwicklungsprozess nach dem wir in unserem Projekt vorgehen.
    1.45  
    1.46 @@ -157,42 +153,19 @@
    1.47  
    1.48  Die verwendeten Begriffe sind im Projekt-Glossar erklärt. Bei Bedarf kann dort nachgeschlagen werden.
    1.49  
    1.50 -\textbf{Workflow}
    1.51 -Aufeinander folgende Aktivitäten die ein messbares Ergebnis erzeugen.
    1.52 -%The sequence of activities performed in a business that produces a result of observable value to an individual actor of the business.
    1.53 +% Im Glossar sind: Workflow Entwicklungsprozess Zyklus Iteration Phase RUP Iterativer Entwicklungsprozess Manntag Release
    1.54  
    1.55 -\textbf{Entwicklungsprozess}
    1.56 -Definiertes Vorgehensmodell zur Erstellung einer Software. Ein Entwicklungsprozess soll die Softwareentwicklung übersichtlicher gestalten und die Komplexität beherrscbar machen.
    1.57  
    1.58 -\textbf{Zyklus}
    1.59 -Ein kompletter Durchlauf der vier Phasen: Konzeption (Inception), Entwurf (Elaboration), Konstruktion (Construction) und Übergabe (Transition).
    1.60 -%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.61 +\section{Verweise auf andere Artefakte}
    1.62  
    1.63 -\textbf{Iteration}
    1.64 -Eine geplante Abfolge von Aktivitäten mit einem messbaren Ergebnis, die in einem Release enden (intern oder extern).
    1.65 -%A distinct sequence of activities with a base-lined plan and valuation criteria resulting in a release  (internal or external).
    1.66 -
    1.67 -\textbf{Phase}
    1.68 -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.69 -%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.70 -
    1.71 -\textbf{RUP}
    1.72 -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.73 -
    1.74 -
    1.75 -\textbf{Iterativer Entwicklungsprozess}
    1.76 -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.77 -
    1.78 -\textbf{Manntag}
    1.79 -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.80 -
    1.81 -\textbf{Release}
    1.82 -%Die fertige und veröffentlichte Version einer Software wird als Release bezeichnet.
    1.83 -%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.84 -
    1.85 -
    1.86 -\section{Verweise}
    1.87 -
    1.88 +\begin{itemize}
    1.89 +	\item \textbf{Glossar}: Dort werden die verwendeten Fachbegriffe erklärt.
    1.90 +	\item \textbf{Software Development Plan}: Der \emph{Development Case} ist ein Unterdokument des \emph{Software Development Plan}s.
    1.91 +	\item \textbf{Projekt Plan}: Die konkrete zeitliche Planung.
    1.92 +	\item
    1.93 +	\item
    1.94 +	\item
    1.95 +\end{itemize}
    1.96  
    1.97  
    1.98  
    1.99 @@ -200,43 +173,94 @@
   1.100  
   1.101  %%%%%%%%%%%%%%
   1.102  \chapter{Entwicklungsprozess}
   1.103 +
   1.104  \section{Überblick}
   1.105  
   1.106 -Wir werden unser Projekt nach dem Rational Unified Process (kurz RUP) entwickeln.
   1.107 +Wir werden unser Projekt nach dem \emph{Rational Unified Process} (kurz RUP) entwickeln.
   1.108  
   1.109  Der RUP ist ein dynamischer und iterativer Entwicklungsprozess, der das Projekt in zwei Dimensionen betrachtet.
   1.110 -Er ist ausführlich spezifiziert und umfangreich dokumentiert. (http://www-306.ibm.com/software/awdtools/rup/).
   1.111 +Er ist ausführlich spezifiziert und umfangreich dokumentiert. (\texttt{http://www-306.ibm.com/software/awdtools/rup/}).
   1.112  
   1.113 -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.114 +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.115  
   1.116 +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.117 +
   1.118 +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.119 +
   1.120 +Wie unsere Adaptation des RUP genau aussieht, das beschreibt diese Dokument.
   1.121 +
   1.122 +
   1.123 +\section{Der RUP auf einen Blick}
   1.124 +
   1.125 +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.126 +
   1.127 +\begin{figure}[htb]
   1.128 +	\centering
   1.129 +	\includegraphics[width=10cm]{pictures/png/RationalUnifiedProcess.png}
   1.130 +	\caption{Übersicht über einen Zyklus des RUP}
   1.131 +	\label{fig:rationalunifiedprocess}
   1.132 +\end{figure}
   1.133 +
   1.134 +
   1.135 +
   1.136 +
   1.137 +
   1.138 +
   1.139 +
   1.140 +
   1.141 +%%%%%%%%%%%%%%
   1.142 +\chapter{Zeitliche Dimension}
   1.143  
   1.144  \section{Anpassungen}
   1.145  
   1.146 -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.147 -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.148 +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.149  
   1.150 -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.151 -Jeder Zyklus wird circa vier Wochen umfassen (18 Manntage). An dessen Ende ein Release steht.
   1.152 -Iterationen innerhalb der Zyklen werden wir, aufgrund der kurzen Zyklen, außen vor lassen.
   1.153 +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.154  
   1.155 -Die einzelnen Phasen (zweite Dimension) in den Zyklen versuchen wir, so gut es geht, zu berücksichtigen.
   1.156 +Iterationen innerhalb der Zyklen werden wir, auf Grund der kurzen Zyklen, komplett außen vor lassen.
   1.157  
   1.158 +Die einzelnen Phasen in den Zyklen versuchen wir, so gut es geht, zu berücksichtigen.
   1.159  
   1.160  
   1.161  
   1.162 +\subsection{Probleme und Konsequenzen}
   1.163  
   1.164 +Der RUP ist sehr umfangreich und 
   1.165 +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.166  
   1.167 -\chapter{Projektplanung}
   1.168 +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.169  
   1.170 -siehe \emph{Projektplan} diesbezüglich
   1.171 +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.172  
   1.173  
   1.174  
   1.175 +\section{Konkrete Projektplanung}
   1.176  
   1.177 +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.178  
   1.179 -\chapter{Kern-Workflows}
   1.180 +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.181  
   1.182  
   1.183 +
   1.184 +
   1.185 +
   1.186 +
   1.187 +
   1.188 +%%%%%%%%%%%%%%%%%%%%
   1.189 +\chapter{Inhaltliche Dimension}
   1.190 +
   1.191 +Diese zweite Dimension beschreibt die inhaltliche Seite der Entwicklung. Hier wird genau festgelegt, \emph{wer} \emph{wie} \emph{was} \emph{wann} macht.
   1.192 +
   1.193 +Dabei gibt es vier Elemente:
   1.194 +\begin{itemize}
   1.195 +	\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.196 +	\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.197 +	\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.198 +	\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.199 +\end{itemize}
   1.200 +
   1.201 +\section{Kern-Workflows}
   1.202 +
   1.203  \subsection{Geschäftsprozessmodellierung}
   1.204  (Business Modeling)
   1.205  
   1.206 @@ -244,10 +268,8 @@
   1.207  
   1.208  \paragraph{Artefakte}
   1.209  \begin{itemize}
   1.210 -	\item Glossary
   1.211 -	\item Use-Case
   1.212 -	\item Use-Case Model
   1.213 -	\item Vision
   1.214 +	\item Glossar
   1.215 +	\item Business Use-Cases
   1.216  \end{itemize}
   1.217  
   1.218  
   1.219 @@ -260,7 +282,7 @@
   1.220  \paragraph{Artefakte}
   1.221  \begin{itemize}
   1.222  	\item Use-Case
   1.223 -	\item Use-Case Model
   1.224 +	\item Use-Case Modell
   1.225  	\item Vision
   1.226  \end{itemize}
   1.227  
   1.228 @@ -269,7 +291,7 @@
   1.229  \subsection{Analyse \& Design}
   1.230  (Analysis \& Design)
   1.231  
   1.232 -Aufbau und Technologie des Systems festlegen.
   1.233 +Aufbau und Technologie des Systems festlegen. Festlegung wie wird das System realisiert wird.
   1.234  
   1.235  \paragraph{Artefakte}
   1.236  \begin{itemize}
   1.237 @@ -281,7 +303,7 @@
   1.238  \subsection{Implementierung}
   1.239  (Implementation)
   1.240  
   1.241 -Systemteile entwickeln und zusammenfügen.
   1.242 +Systemteile entwickeln und zusammenfügen. Komponententests.
   1.243  
   1.244  \paragraph{Artefakte}
   1.245  
   1.246 @@ -289,7 +311,7 @@
   1.247  \subsection{Test}
   1.248  (Testing)
   1.249  
   1.250 -Funktionsweise des Systems gegen die Anforderungen prüfen.
   1.251 +Test des Zusammenspiels der Komponenten. Funktionsweise des Systems gegen die Anforderungen prüfen.
   1.252  
   1.253  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.254  
   1.255 @@ -326,6 +348,7 @@
   1.256  \paragraph{Artefakte}
   1.257  \begin{itemize}
   1.258  	\item Software Development Plan
   1.259 +	\item Risikoliste
   1.260  	\item Iteration Plan % FIXME
   1.261  \end{itemize}
   1.262  
   1.263 @@ -355,14 +378,53 @@
   1.264  
   1.265  
   1.266      \appendix
   1.267 -    \chapter{Glossar}
   1.268 -    \chapter{Quellen und Links}
   1.269 +    %\chapter{Glossar}
   1.270 +    \chapter{Quellen}
   1.271  			\begin{itemize}
   1.272  				\item Dokumentation zum \emph{Rational Unified Process}
   1.273  				\item Skript von Herrn Baer zur Vorlesung \emph{Softwaretechnik 1} an der Hochschule Ulm
   1.274  				\item http://wikipedia.org
   1.275 +				\item \emph{Rational Unified Process - Best Practices for Software Development Teams}
   1.276  			\end{itemize}
   1.277  
   1.278 +			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.279 +
   1.280  
   1.281  
   1.282  \end{document}
   1.283 +
   1.284 +
   1.285 +
   1.286 +
   1.287 +%%%%%%%% HowTo %%%%%%%%%%
   1.288 +
   1.289 +% picture block
   1.290 +\begin{figure}[h]
   1.291 + \includegraphics[scale=0.65]{pictures/png/logistiksicht_v6}
   1.292 + \caption{Logistiksicht für SAP}
   1.293 + \label{fig:logistiksicht}
   1.294 +\end{figure}
   1.295 +
   1.296 +% picture inline
   1.297 +\begin{wrapfigure}[11]{r}[0pt]{6.4cm}
   1.298 + \centering %OPTIONAL
   1.299 + \includegraphics[scale=0.7]{pictures/png/werkdresden}
   1.300 + \caption{OptiBoard Werk Dresden}
   1.301 +\end{wrapfigure}
   1.302 +
   1.303 +% tabellen
   1.304 +\begin{table}[h]
   1.305 +\centering
   1.306 +\begin{tabular}{p{4cm}|p{3cm}|p{3.3cm}}
   1.307 + \rowcolor{gray07} \textbf{Teil} & \textbf{Menge} & \textbf{Einheit}\\
   1.308 + \hline
   1.309 + \rowcolor{white}  LED-Block          & 105 & Stück\\
   1.310 + \rowcolor{gray09} Feder              & 105 & Stück\\
   1.311 + \rowcolor{white}  Platine            & 1   & Stück\\
   1.312 + \rowcolor{gray09} Chip               & 1   & Stück\\
   1.313 + \rowcolor{white}  Kabel              & 1   & Stück\\
   1.314 + \rowcolor{gray09} Kunststoffgranulat & 350 & Gramm\\
   1.315 +\end{tabular}
   1.316 +\caption{Mengenübersichtstückliste OptiBoard Pro}
   1.317 +\label{tbl:mengenPro}
   1.318 +\end{table}

     2.1 Binary file pictures/png/RationalUnifiedProcess.png has changed