docs/Development-Case
diff development-case.tex @ 10:06bd2953d319
lots of changes, mainly in the workflows
author | meillo@marmaro.de |
---|---|
date | Tue, 22 Jan 2008 20:43:40 +0100 |
parents | 3bae83d50dc5 |
children | fb6ee4e487da |
line diff
1.1 --- a/development-case.tex Mon Jan 21 23:25:42 2008 +0100 1.2 +++ b/development-case.tex Tue Jan 22 20:43:40 2008 +0100 1.3 @@ -114,8 +114,6 @@ 1.4 1.5 1.6 1.7 -% \addsec{Bitte beachten} 1.8 - Version vom \today: Das Dokument befindet sich noch im Aufbau, \"{A}nderungen sind dadurch jederzeit M\"{o}glich. 1.9 \addsec{Version dieses Dokuments} 1.10 \begin{tabular}{|p{1.5cm}|p{3.cm}|p{1.6cm}|p{2cm}|p{1.4cm}|p{4cm}|} 1.11 \hline 1.12 @@ -129,7 +127,7 @@ 1.13 0.4.1 & Karl Oppermann & QS & 2008-01-17 & A & Allgemeines Review \\ \hline 1.14 0.5 & Markus Schnalke & AE & 2008-01-18 & A & Überarbeitung; Fachbegriffe jetzt englisch \\ \hline 1.15 0.5.1 & Veysel Imamoglu & QS & 2008-01-18 & A & Rechtschreibkorrektur \\ \hline 1.16 - 0.6 & Markus Schnalke & AE & 2008-01-21 & O & \\ \hline 1.17 + 1.0 & Markus Schnalke & AB & 2008-01-22 & A & Finale Version für R3 \\ \hline 1.18 \end{tabular} 1.19 {\footnotesize\vspace*{-0.1cm}Aktion: E – Erstellung; AE – \"{A}nderung; QS – Review; AB – Abnahme} \par 1.20 {\footnotesize\vspace*{-0.4cm} Status: O – Offen; D – Diskussion; A – Akzeptiert} 1.21 @@ -158,16 +156,15 @@ 1.22 1.23 \section{Definitionen und Abkürzungen} 1.24 1.25 -Die verwendeten Begriffe sind im Projekt-Glossar erklärt. Bei Bedarf kann dort nachgeschlagen werden. 1.26 +Die verwendeten Begriffe sind im Glossary erklärt. Bei Bedarf kann dort nachgeschlagen werden. 1.27 1.28 1.29 1.30 \section{Verweise auf andere Artefakte} 1.31 1.32 -\begin{itemize} 1.33 - \item \textbf{Software Development Plan} 1.34 - \item \textbf{Glossary} 1.35 -\end{itemize} 1.36 +Der \textbf{Software Development Plan} ist an vielen Stellen mit diesem Dokument verknüpft. 1.37 + 1.38 +Zur Klärung der verwendeten Fachbegriffe kann im \textbf{Glossary} nachgeschlagen werden. 1.39 1.40 1.41 1.42 @@ -210,7 +207,7 @@ 1.43 1.44 \section{Anpassungen} 1.45 1.46 -Wir werden in unserem Projekt drei Zyklen durchführen. Jeder der drei Zyklen wird circa fünf Wochen (30 Manntage) umfassen. An dessen Ende jeweils ein Release stehen wird. (siehe \emph{Software Development Plan}) 1.47 +Wir führen in unserem Projekt drei Zyklen durch. Jeder der drei Zyklen wird circa fünf Wochen (30 Manntage) umfassen. An dessen Ende jeweils ein Release stehen wird. (siehe \emph{Software Development Plan}) 1.48 1.49 Die einzelnen Phasen in den Zyklen versuchen wir, so gut es geht, zu berücksichtigen. Es muss bedacht werden, dass pro Phase bei uns ganz grob nur etwa 4 Manntage (d.h. circa 4 Stunden pro Person) zur Verfügung stehen. 1.50 1.51 @@ -241,108 +238,139 @@ 1.52 %%%%%%%%%%%%%%%%%%%% 1.53 \chapter{Inhaltliche Dimension} 1.54 1.55 -In der zweiten Dimension wird festgelegt, \emph{wer} (Rolle), \emph{wie} (Aktivität), \emph{was} (Artefakt), \emph{wann} (Workflow) macht. 1.56 +In der zweiten Dimension wird festgelegt, \emph{wer} (Rolle), \emph{wie} (Aktivität), \emph{was} (Artefakt), \emph{wann} macht. Diese Elemente werden in Workflows vereint. 1.57 + 1.58 +Hier beschreiben wir, wie wir die vorgegebenen Workflows des RUP anpassen. 1.59 1.60 1.61 1.62 \section{Business Modeling} 1.63 1.64 -\paragraph{Zweck} 1.65 -Gemeinsames Verständniss zwischen Entwicklern und Anwendern schaffen 1.66 +\subsection*{Zweck} 1.67 +Gemeinsames Verständniss zwischen Entwicklern und Anwendern schaffen. 1.68 1.69 -\paragraph{Wird erreicht durch} 1.70 -Dokumentation der relevanten Geschäftsprozesse in Use Cases 1.71 +\subsection*{Anpassungen} 1.72 +Wir erstellen keinen Business Use Case, weil das Seminarsystem ein gestelltes abgeschlossenes Szenario ist und nicht in bestehende Geschäftsabläufe eingebunden werden muss. 1.73 1.74 -%\paragraph{Anpassungen} 1.75 -%Keine besonderen. 1.76 - 1.77 -\paragraph{Wer} Fachliches Team, Kunde 1.78 -\paragraph{Wie} im Gespräch 1.79 -\paragraph{Was} Glossary 1.80 - 1.81 -%\paragraph{Artefakte} 1.82 -%\begin{itemize} 1.83 -% \item Glossary 1.84 -%\end{itemize} 1.85 +\subsection*{Artefakte} 1.86 +\begin{tabular}{p{4cm}p{10cm}} 1.87 + \rowcolor{gray07} Artefakt & \textbf{Glossary} \\ 1.88 + \rowcolor{white} Rolle & Fachliches Team, Kunde \\ 1.89 + \rowcolor{gray09} Aktivität & erstellen gemeinsam \\ 1.90 + \rowcolor{white} Wann & Inception, Ergänzungen jeder Zeit \\ 1.91 + \rowcolor{gray09} Review & Fachliches Team und Kunde durch gemeinsames Erstellen \\ 1.92 +\end{tabular} 1.93 1.94 1.95 1.96 \section{Requirements} 1.97 1.98 -\paragraph{Zweck} 1.99 -Ermitteln, was das System leisten soll. Die funktionalen Anforderungen sollen erfasst werden. 1.100 +\subsection*{Zweck} 1.101 +Ermitteln, was das System leisten soll. Die funktionalen Anforderungen erfassen. 1.102 1.103 -\paragraph{Anpassungen} 1.104 +\subsection*{Anpassungen} 1.105 Keine besonderen. 1.106 1.107 -\paragraph{Artefakte} 1.108 -\begin{itemize} 1.109 - \item Vision 1.110 - \item Use Cases 1.111 -\end{itemize} 1.112 +\subsection*{Artefakte} 1.113 +\begin{tabular}{p{4cm}p{10cm}} 1.114 + \rowcolor{gray07} Artefakt & \textbf{Vision} \\ 1.115 + \rowcolor{white} Rolle & Fachliches Team, Kunde \\ 1.116 + \rowcolor{gray09} Aktivität & erarbeiten im Gespräch \\ 1.117 + \rowcolor{white} Wann & Inception \\ 1.118 + \rowcolor{gray09} Review & Fachliches Team und Kunde durch gemeinsames Erarbeiten \\ 1.119 + & \\ 1.120 + \rowcolor{gray07} Artefakt & \textbf{Use Cases} \\ 1.121 + \rowcolor{white} Rolle & Fachliches Team, Kunde \\ 1.122 + \rowcolor{gray09} Aktivität & erarbeiten im Gespräch \\ 1.123 + \rowcolor{white} Wann & Inception und Elaboration \\ 1.124 + \rowcolor{gray09} Review & Fachliches Team und Kunde durch gemeinsames Erarbeiten \\ 1.125 +\end{tabular} 1.126 1.127 1.128 1.129 \section{Analysis \& Design} 1.130 1.131 -\paragraph{Zweck} 1.132 +\subsection*{Zweck} 1.133 Aufbau und Technologie des Systems festlegen. Festlegung wie wird das System realisiert wird. 1.134 1.135 -\paragraph{Anpassungen} 1.136 -Die Technologie und Teile der Umsetzung sind durch das Projekt vorgegeben und somit fix. 1.137 +\subsection*{Anpassungen} 1.138 +Die Technologie und Rahmenbedingungen der Umsetzung sind durch das Projekt vorgegeben und somit fix. 1.139 1.140 -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.141 +Zum jetzigen Zeitpunkt arbeiten wir uns vor allem in die neue Technologie ein. Unsere Softwarearchitektur ist bisher vor allem einen Vorarbeit für später. 1.142 1.143 -\paragraph{Artefakte} 1.144 -\begin{itemize} 1.145 - \item Software Architecture Document 1.146 -\end{itemize} 1.147 +\subsection*{Artefakte} 1.148 +\begin{tabular}{p{4cm}p{10cm}} 1.149 + \rowcolor{gray07} Artefakt & \textbf{Software Architecture Document} \\ 1.150 + \rowcolor{white} Rolle & Team Technische Architektur \\ 1.151 + \rowcolor{gray09} Aktivität & erstellt \\ 1.152 + \rowcolor{white} Wann & Elaboration \\ 1.153 + \rowcolor{gray09} Review & Entwickler nach Änderungen \\ 1.154 +\end{tabular} 1.155 1.156 1.157 1.158 1.159 \section{Implementation} 1.160 1.161 -\paragraph{Zweck} 1.162 +\subsection*{Zweck} 1.163 Systemteile entwickeln und zusammenfügen. Komponententests. 1.164 1.165 -\paragraph{Anpassungen} 1.166 -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.167 +\subsection*{Anpassungen} 1.168 +Momentan besteht dieser Workflow in erster Line aus der Entwicklung von Prototypen jeder Art (Modelle, Templates, etc) um die Technologie zu erforschen. 1.169 1.170 -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.171 +Konkrete Artefakte werden bisher nicht erstellt, weil es zum jetzigen Stand nicht sinnvoll ist nach festen Plänen vorzugehen. Unser Kenntnissstand ändert sich sehr schnell und wir wollen flexibel reagieren können. 1.172 1.173 -\paragraph{Artefakte} 1.174 -Momentan keine. 1.175 +\subsection*{Artefakte} 1.176 +Keine definiert. 1.177 +% \begin{tabular}{p{4cm}p{10cm}} 1.178 +% \rowcolor{gray07} Artefakt & \textbf{Glossary} \\ 1.179 +% \rowcolor{white} Rolle & Fachliches Team, Kunde \\ 1.180 +% \rowcolor{gray09} Aktivität & erstellen gemeinsam \\ 1.181 +% \rowcolor{white} Wann & Inception (ergänzend jeder Zeit) \\ 1.182 +% \rowcolor{gray09} Review & \\ 1.183 +% \end{tabular} 1.184 1.185 1.186 1.187 \section{Testing} 1.188 1.189 -\paragraph{Zweck} 1.190 +\subsection*{Zweck} 1.191 Test des Zusammenspiels der Komponenten. Funktionsweise des Systems gegen die Anforderungen prüfen. 1.192 1.193 -\paragraph{Anpassungen} 1.194 -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.195 +\subsection*{Anpassungen} 1.196 +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. Test bremst die Entwicklungsgeschwindigkeit zugunsten von Qualität. Unser Hauptaugenmerk ist es voran zu kommen, nicht komplett fehlerfreie Ergebnisse zu liefern, deshalb verzichten wir komplett auf Software-Tests. So können wir die dadurch verfügbaren Ressourcen an anderer Stelle effektiv nutzen. Sobald wir nicht mehr nur Prototypen erzeugen, werden wir natürlich Software-Tests einführen. 1.197 1.198 -Dies heißt aber keineswegs, dass wir ihn zum geeigneten Zeitpunkt nicht voll ausbauen werden. 1.199 +Alle Dokumente müssen von mindestens einer weiteren Person begutachtet werden. Die genauen Vorgaben stehen bei den Artefaktbeschreibungen in diesem Kapitel. 1.200 1.201 -\paragraph{Artefakte} 1.202 -Noch keine. 1.203 +\subsection*{Artefakte} 1.204 +Keine definiert. 1.205 +% \begin{tabular}{p{4cm}p{10cm}} 1.206 +% \rowcolor{gray07} Artefakt & \textbf{Dokument Reviews} \\ 1.207 +% \rowcolor{white} Rolle & Beliebiger Mitarbeiter \\ 1.208 +% \rowcolor{gray09} Aktivität & prüfen gemeinsam das Dokument \\ 1.209 +% \rowcolor{white} Wann & nachdem Dokument erstellt/geändert wurde \\ 1.210 +% \rowcolor{gray09} Review & \\ 1.211 +% \end{tabular} 1.212 + 1.213 1.214 1.215 1.216 \section{Deployment} 1.217 1.218 -\paragraph{Zweck} 1.219 -Auslieferung des Systems an den Kunden und Inbetriebnahme. Schulung der Benutzer. 1.220 +\subsection*{Zweck} 1.221 +Auslieferung des Systems an den Kunden und Inbetriebnahme. 1.222 1.223 -\paragraph{Anpassungen} 1.224 -Auch hier sparen wir um dafür die Entwicklung voran zu treiben. 1.225 +\subsection*{Anpassungen} 1.226 +Solange wir keine lauffähigen Ergebnisse haben, vernachlässigen wir diesen Workflow. Wenn dies nicht mehr der Fall ist, muss eine Anleitung zur Inbetriebnahme des Programms erstellt werden. Ebenso muss der genaue Funktionsumfang des Systems beschrieben sein. 1.227 1.228 -\paragraph{Artefakte} 1.229 -\begin{itemize} 1.230 - \item Release Notes (empfohlen) %FIXME rechtschreibung 1.231 -\end{itemize} 1.232 +\subsection*{Artefakte} 1.233 +\begin{tabular}{p{4cm}p{10cm}} 1.234 + \rowcolor{gray07} Artefakt & \textbf{Release Notes} \\ 1.235 + \rowcolor{white} Rolle & Projektleiter, Entwickler \\ 1.236 + \rowcolor{gray09} Aktivität & sollen erstellen \\ 1.237 + \rowcolor{white} Wann & Transition \\ 1.238 + \rowcolor{gray09} Review & anderer Entwickler vor Auslieferung \\ 1.239 +\end{tabular} 1.240 1.241 1.242 1.243 @@ -350,52 +378,71 @@ 1.244 1.245 \section{Configuration \& Changemanagement} 1.246 1.247 -\paragraph{Zweck} 1.248 -Verwaltung der zum Projekt gehörenden Daten. Versionierung und Konsistenz. 1.249 +\subsection*{Zweck} 1.250 +Verwaltung der zum Projekt gehörenden Daten. Versionierung der Daten. Change-Request-Management. 1.251 1.252 -\paragraph{Anpassungen} 1.253 -Alle Daten müssen im Project Repository abgelegt werden. Dieses soll die zentrale Informationsstelle sein. 1.254 +\subsection*{Anpassungen} 1.255 +Alle Daten müssen im zentralen Project Repository abgelegt werden. 1.256 1.257 Jeder Mitarbeiter darf an jeder Stelle des Projekts Änderungen durchführen. 1.258 1.259 -% FIXME: Inhalte für Karl einfügen 1.260 +Change-Requests werden nach dem vertraglich festgelegten Verfahren bearbeitet. 1.261 1.262 -\paragraph{Artefakte} 1.263 -\begin{itemize} 1.264 - \item Project Repository 1.265 -\end{itemize} 1.266 +\subsection*{Artefakte} 1.267 +Keine definiert. 1.268 + 1.269 1.270 1.271 1.272 \section{Projectmanagement} 1.273 1.274 -\paragraph{Zweck} 1.275 -Zwischen konkurrierenden Zielen vermitteln. Auf Risiken reagieren. 1.276 +\subsection*{Zweck} 1.277 +Planung des Projekts. Zwischen konkurrierenden Zielen vermitteln. Auf Risiken reagieren. 1.278 1.279 -\paragraph{Anpassungen} 1.280 +\subsection*{Anpassungen} 1.281 Keine besonderen. 1.282 1.283 -\paragraph{Artefakte} 1.284 -\begin{itemize} 1.285 - \item Software Development Plan 1.286 - \item Risklist 1.287 -\end{itemize} 1.288 +\subsection*{Artefakte} 1.289 +\begin{tabular}{p{4cm}p{10cm}} 1.290 + \rowcolor{gray07} Artefakt & \textbf{Software Development Plan} \\ 1.291 + \rowcolor{white} Rolle & Projektleiter \\ 1.292 + \rowcolor{gray09} Aktivität & erstellt \\ 1.293 + \rowcolor{white} Wann & Inception \\ 1.294 + \rowcolor{gray09} Review & Entwickler und Risikomanager nach Änderungen \\ 1.295 + & \\ 1.296 + \rowcolor{gray07} Artefakt & \textbf{Risk Management Plan} \\ 1.297 + \rowcolor{white} Rolle & Riskmanager \\ 1.298 + \rowcolor{gray09} Aktivität & erstellt \\ 1.299 + \rowcolor{white} Wann & Alle Phasen \\ 1.300 + \rowcolor{gray09} Review & Komplettes Team in Inception Phase \\ 1.301 +\end{tabular} 1.302 1.303 1.304 1.305 \section{Environment} 1.306 1.307 -\paragraph{Zweck} 1.308 -Bereitstellung von Hardware, Software und Know-How. 1.309 +\subsection*{Zweck} 1.310 +Rahmenbedingungen schaffen. Bereitstellung von Hardware, Software und Know-How. 1.311 1.312 -\paragraph{Anpassungen} 1.313 -Keine besonderen. 1.314 +\subsection*{Anpassungen} 1.315 +Die Hochschule Ulm stellt uns ein Project Repository zur Verfügung. 1.316 1.317 -\paragraph{Artefakte} 1.318 -\begin{itemize} 1.319 - \item Development Case 1.320 -\end{itemize} 1.321 +Die offiziellen Kommunikationwege im Team sind das wöchentliche Teammeeting und die Projekt-Mailingliste. 1.322 1.323 +\subsection*{Artefakte} 1.324 +\begin{tabular}{p{4cm}p{10cm}} 1.325 + \rowcolor{gray07} Artefakt & \textbf{Development Case} \\ 1.326 + \rowcolor{white} Rolle & Projektleiter \\ 1.327 + \rowcolor{gray09} Aktivität & erstellt \\ 1.328 + \rowcolor{white} Wann & Inception \\ 1.329 + \rowcolor{gray09} Review & Komplettes Team in Inception Phase \\ 1.330 + & \\ 1.331 + \rowcolor{gray07} Artefakt & \textbf{Tutorials} \\ 1.332 + \rowcolor{white} Rolle & Toolspezialist \\ 1.333 + \rowcolor{gray09} Aktivität & kann erstellen \\ 1.334 + \rowcolor{white} Wann & Alle Phasen \\ 1.335 + \rowcolor{gray09} Review & eine Person für die das Tutorial geschrieben wurde \\ 1.336 +\end{tabular} 1.337 1.338 1.339 1.340 @@ -444,7 +491,7 @@ 1.341 \end{wrapfigure} 1.342 1.343 % tabellen 1.344 -\begin{table}[h] 1.345 +\begin{table}[htb] 1.346 \centering 1.347 \begin{tabular}{p{4cm}|p{3cm}|p{3.3cm}} 1.348 \rowcolor{gray07} \textbf{Teil} & \textbf{Menge} & \textbf{Einheit}\\