docs/Development-Case

view development-case.tex @ 6:b9b93523dc05

a lot of content and restructuring and even more :-)
author meillo@marmaro.de
date Wed, 16 Jan 2008 21:53:40 +0100
parents a967aa02ee99
children 1f955918cf53
line source
1 % V. 1.0
2 \documentclass[a4paper,12pt,titlepage,DIV12,parskip]{scrreprt}
3 \setlength{\parskip}{3mm} %abstand abs\"{a}tze und listen
4 \usepackage{setspace}
5 \usepackage[utf8]{inputenc}
6 \usepackage{ngerman}
7 \usepackage[pdftex]{graphicx}
8 \usepackage[table]{xcolor}
9 %\usepackage{SIunits}
10 \usepackage{ragged2e,array}
11 \usepackage{wrapfig}
12 \usepackage[footnotesize]{caption2}
13 \usepackage{supertabular}
14 \usepackage{chngcntr}
15 \usepackage{longtable}
16 %\usepackage{lastpage}
17 \usepackage{caption2}
18 \usepackage[right]{eurosym}
19 %\usepackage{float}
20 \usepackage[ngerman]{varioref}
21 %\usepackage{enumitem}
22 \usepackage[colorlinks,linkcolor=black,urlcolor=blue,bookmarks,bookmarksopen,bookmarksnumbered]{hyperref}
24 %PDF Infos
25 \pdfinfo{
26 /Title (development-case.tex)
27 /Subject (Development Case)
28 %/Creator (TeX / pdfTeX)
29 %/Producer (Christoph Galler)
30 /Author (markus schnalke)
31 /CreationDate (D:20080113090000)
32 /ModDate (D:20080113090000)
33 }
35 %neues Kommando fuer Breitenangabe in der Tabelle mit vorgegebener Breite:
36 \newcommand{\preserveBackslash}[1]{\let\temp=\\#1\let\\=\temp}
37 \newcolumntype{R}[1]{>{\preserveBackslash\RaggedLeft}p{#1}}
38 % Font Familie
39 \renewcommand{\familydefault}{\sfdefault}
40 %\nofiles
41 % Fuer tabellenkopf
42 \newcommand{\hoehe}{\parbox[1pt][2em][c]{0cm}{}}
44 \definecolor{gray09}{gray}{0.9}
45 \definecolor{gray07}{gray}{0.7}
47 %Counternummerierung \"{a}ndern -> 1.1 2.1 3.1 etc.
48 \counterwithin{section}{chapter}
50 % Name f\"{u}r autoref bei figure Umgebungen: Abbildung x.z
51 \renewcommand{\figureautorefname}{Abbildung}
52 \renewcommand{\chapterautorefname}{Kapitel}
53 \renewcommand{\sectionautorefname}{Unterkapitel}
54 \renewcommand{\tableautorefname}{Tabelle}
57 % Textkoerperhoehe
58 \setlength{\headsep}{0.6cm}
59 \addtolength{\textheight}{0.9cm}
60 \setlength{\footskip}{0.9cm}
62 % Kopf- und Fu{\ss}zeile
63 \setlength{\headheight}{2cm}
64 \usepackage[automark]{scrpage2}
65 \automark[section]{section}
66 \setheadwidth{15.8cm}
67 \ihead{\headmark}
68 \ihead{Online Seminarbuchungssystem}
69 \chead{{\color{blue}\color{black}\rule[-10pt]{18.4cm}{0.1pt}\color{black}}}
70 \ohead{\headmark}
71 \setfootwidth[-74pt]{18.3cm}
72 \setfootsepline[foot]{.1pt}
73 \ifoot{} %~~~~~~~~~~~~~~~~~~~\footnotesize Christoph Galler}
74 \cfoot{}
75 \ofoot{\footnotesize Seite \thepage} % ~von \pageref{LastPage}}
76 \renewcommand*{\chapterpagestyle}{scrheadings}
77 \renewcommand*{\indexpagestyle}{scrheadings}
78 \pagestyle{scrheadings}
80 % Kapitel nicht zu tief beginnen
81 \renewcommand*\chapterheadstartvskip{\vspace*{0cm}}
84 \begin{document}
86 %
87 % Titelei
88 %
89 \begin{titlepage}
90 \vspace*{-0cm}
91 {\hspace*{11cm}\includegraphics*[scale=0.5]{pictures/png/logo_hsu_klein}}
92 \begin{center}
93 \vspace*{1.9cm}
94 {\normalsize\textsc{Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, \\Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler}} \par
95 \vspace*{0.6cm}
96 \Large \textbf{Online-Seminarbuchungssystem} \par
97 \Huge \textbf{Development Case} \par
98 \vspace*{0.8cm}
99 \Large \textbf{Verfasser: Markus Schnalke} \par
100 {\large{} \par
101 \vspace*{0.7cm}
102 {\textsc{Ulm, \today}}} \par
103 \vspace*{5cm}
104 {\normalsize\textsc{Betreut durch: \\
105 Prof. Dr. Klaus Baer \\
106 Hochschule Ulm \\
107 Prittwitzstra{\ss}e 10\\
108 89075 Ulm\\}}
109 \end{center}
110 \vfill
111 \end{titlepage}
113 % \addsec{Bitte beachten}
114 Version vom \today: Das Dokument befindet sich noch im Aufbau, \"{A}nderungen sind dadurch jederzeit M\"{o}glich.
115 \addsec{Version dieses Dokuments}
116 \begin{tabular}{|p{1.5cm}|p{3.cm}|p{1.6cm}|p{2cm}|p{1.4cm}|p{4cm}|}
117 \hline
118 \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}}} \\
119 \hline\hline
120 \hoehe{\textbf{Version}} & \textbf{Person} & \textbf{Aktion} & \textbf{Datum} & \textbf{Status} & \textbf{Kommentar} \\
121 \hline\hline
122 0.1 & Markus Schnalke & E & 2007-11-27 & O & Erste Version \\ \hline
123 0.2 & Markus Schnalke & AE & 2008-01-13 & O & Neue Struktur des Dokuments \\ \hline
124 0.3 & Markus Schnalke & AE & 2008-01-14 & O & Glossar erstellt \\ \hline
125 0.4 & Markus Schnalke & AE & 2008-01-16 & O & Struktur überarbeitet; Glossar ausgelagert \\ \hline
126 \end{tabular}
127 {\footnotesize\vspace*{-0.1cm}Aktion: E – Erstellung; AE – \"{A}nderung; QS – Review; AB – Abnahme} \par
128 {\footnotesize\vspace*{-0.4cm} Status: O – Offen; D – Diskussion; A – Akzeptiert}
129 \clearpage
131 % Inhaltsverzeichnis
132 \setcounter{tocdepth}{3}
133 %\renewcommand\contentsname{"Uberblick}
134 \tableofcontents
136 \clearpage
141 % Content
145 \chapter{Einleitung}
147 \section{Zweck des Dokuments}
149 Dieses Dokument beschreibt den Entwicklungsprozess nach dem wir in unserem Projekt vorgehen.
152 \section{Definitionen und Abkürzungen}
154 Die verwendeten Begriffe sind im Projekt-Glossar erklärt. Bei Bedarf kann dort nachgeschlagen werden.
156 % Im Glossar sind: Workflow Entwicklungsprozess Zyklus Iteration Phase RUP Iterativer Entwicklungsprozess Manntag Release
159 \section{Verweise auf andere Artefakte}
161 \begin{itemize}
162 \item \textbf{Glossar}: Dort werden die verwendeten Fachbegriffe erklärt.
163 \item \textbf{Software Development Plan}: Der \emph{Development Case} ist ein Unterdokument des \emph{Software Development Plan}s.
164 \item \textbf{Projekt Plan}: Die konkrete zeitliche Planung.
165 \item
166 \item
167 \item
168 \end{itemize}
174 %%%%%%%%%%%%%%
175 \chapter{Entwicklungsprozess}
177 \section{Überblick}
179 Wir werden unser Projekt nach dem \emph{Rational Unified Process} (kurz RUP) entwickeln.
181 Der RUP ist ein dynamischer und iterativer Entwicklungsprozess, der das Projekt in zwei Dimensionen betrachtet.
182 Er ist ausführlich spezifiziert und umfangreich dokumentiert. (\texttt{http://www-306.ibm.com/software/awdtools/rup/}).
184 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.
186 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.
188 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).
190 Wie unsere Adaptation des RUP genau aussieht, das beschreibt diese Dokument.
193 \section{Der RUP auf einen Blick}
195 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.
197 \begin{figure}[htb]
198 \centering
199 \includegraphics[width=10cm]{pictures/png/RationalUnifiedProcess.png}
200 \caption{Übersicht über einen Zyklus des RUP}
201 \label{fig:rationalunifiedprocess}
202 \end{figure}
211 %%%%%%%%%%%%%%
212 \chapter{Zeitliche Dimension}
214 \section{Anpassungen}
216 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.
218 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}.)
220 Iterationen innerhalb der Zyklen werden wir, auf Grund der kurzen Zyklen, komplett außen vor lassen.
222 Die einzelnen Phasen in den Zyklen versuchen wir, so gut es geht, zu berücksichtigen.
226 \subsection{Probleme und Konsequenzen}
228 Der RUP ist sehr umfangreich und
229 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.
231 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.
233 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.
237 \section{Konkrete Projektplanung}
239 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.
241 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.
249 %%%%%%%%%%%%%%%%%%%%
250 \chapter{Inhaltliche Dimension}
252 Diese zweite Dimension beschreibt die inhaltliche Seite der Entwicklung. Hier wird genau festgelegt, \emph{wer} \emph{wie} \emph{was} \emph{wann} macht.
254 Dabei gibt es vier Elemente:
255 \begin{itemize}
256 \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}.
257 \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.
258 \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.
259 \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.
260 \end{itemize}
262 \section{Kern-Workflows}
264 \subsection{Geschäftsprozessmodellierung}
265 (Business Modeling)
267 Dokumentation der relevanten Geschäftsprozesse in Use Cases, mit dem Ziel eines gemeinsamen Verständnisses zwischen Entwicklern und Anwendern.
269 \paragraph{Artefakte}
270 \begin{itemize}
271 \item Glossar
272 \item Business Use-Cases
273 \end{itemize}
277 \subsection{Anforderungen}
278 (Requirements)
280 Ermitteln, was das System leisten soll. Die funktionalen Anforderungen sollen erfasst werden.
282 \paragraph{Artefakte}
283 \begin{itemize}
284 \item Use-Case
285 \item Use-Case Modell
286 \item Vision
287 \end{itemize}
291 \subsection{Analyse \& Design}
292 (Analysis \& Design)
294 Aufbau und Technologie des Systems festlegen. Festlegung wie wird das System realisiert wird.
296 \paragraph{Artefakte}
297 \begin{itemize}
298 \item Software Architecture Document
299 \end{itemize}
303 \subsection{Implementierung}
304 (Implementation)
306 Systemteile entwickeln und zusammenfügen. Komponententests.
308 \paragraph{Artefakte}
311 \subsection{Test}
312 (Testing)
314 Test des Zusammenspiels der Komponenten. Funktionsweise des Systems gegen die Anforderungen prüfen.
316 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.
320 \subsection{Verteilung}
321 (Deployment)
323 Auslieferung des Systems an den Kunden und Inbetriebnahme. Schulung der Benutzer.
325 \paragraph{Artefakte}
330 \section{Unterstützungs-Workflows}
332 \subsection{Konfigurations- \& Änderungsmanagement}
333 (Configuration \& Changemanagement)
335 Verwaltung der zum Projekt gehörenden Daten. Versionierung und Konsistenz.
337 \paragraph{Artefakte}
338 \begin{itemize}
339 \item Project Repository
340 \end{itemize}
343 \subsection{Projektmanagement}
344 (Projectmanagement)
346 Zwischen konkurrierenden Zielen vermitteln. Auf Risiken reagieren.
348 \paragraph{Artefakte}
349 \begin{itemize}
350 \item Software Development Plan
351 \item Risikoliste
352 \item Iteration Plan % FIXME
353 \end{itemize}
356 \subsection{Entwicklungsumgebung}
357 (Environment)
359 Bereitstellung von Hardware, Software und Know-How.
361 \paragraph{Artefakte}
362 \begin{itemize}
363 \item Development Case
364 \item Tools
365 \item User Interface Guidlines % FIXME
366 \end{itemize}
380 \appendix
381 %\chapter{Glossar}
382 \chapter{Quellen}
383 \begin{itemize}
384 \item Dokumentation zum \emph{Rational Unified Process}
385 \item Skript von Herrn Baer zur Vorlesung \emph{Softwaretechnik 1} an der Hochschule Ulm
386 \item http://wikipedia.org
387 \item \emph{Rational Unified Process - Best Practices for Software Development Teams}
388 \end{itemize}
390 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.
394 \end{document}
399 %%%%%%%% HowTo %%%%%%%%%%
401 % picture block
402 \begin{figure}[h]
403  \includegraphics[scale=0.65]{pictures/png/logistiksicht_v6}
404  \caption{Logistiksicht für SAP}
405  \label{fig:logistiksicht}
406 \end{figure}
408 % picture inline
409 \begin{wrapfigure}[11]{r}[0pt]{6.4cm}
410  \centering %OPTIONAL
411  \includegraphics[scale=0.7]{pictures/png/werkdresden}
412  \caption{OptiBoard Werk Dresden}
413 \end{wrapfigure}
415 % tabellen
416 \begin{table}[h]
417 \centering
418 \begin{tabular}{p{4cm}|p{3cm}|p{3.3cm}}
419  \rowcolor{gray07} \textbf{Teil} & \textbf{Menge} & \textbf{Einheit}\\
420  \hline
421  \rowcolor{white}  LED-Block          & 105 & Stück\\
422  \rowcolor{gray09} Feder              & 105 & Stück\\
423  \rowcolor{white}  Platine            & 1   & Stück\\
424  \rowcolor{gray09} Chip               & 1   & Stück\\
425  \rowcolor{white}  Kabel              & 1   & Stück\\
426  \rowcolor{gray09} Kunststoffgranulat & 350 & Gramm\\
427 \end{tabular}
428 \caption{Mengenübersichtstückliste OptiBoard Pro}
429 \label{tbl:mengenPro}
430 \end{table}