comparison development-case.tex @ 9:3bae83d50dc5

lots of changes ... restructuring
author meillo@marmaro.de
date Mon, 21 Jan 2008 23:25:42 +0100
parents 5f939d777552
children 06bd2953d319
comparison
equal deleted inserted replaced
8:5f939d777552 9:3bae83d50dc5
112 \vfill 112 \vfill
113 \end{titlepage} 113 \end{titlepage}
114 114
115 115
116 116
117 % \begin{titlepage}
118 % \vspace*{-0cm}
119 % {\hspace*{11cm}\includegraphics*[scale=0.5]{pictures/png/logo_hsu_klein}}
120 % \begin{center}
121 % \vspace*{1.9cm}
122 % {\normalsize\textsc{Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, \\Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler}} \par
123 % \vspace*{0.6cm}
124 % \Large \textbf{Online-Seminarbuchungssystem} \par
125 % \Huge \textbf{Development Case} \par
126 % \vspace*{0.8cm}
127 % \Large \textbf{Verfasser: Markus Schnalke} \par
128 % {\large{} \par
129 % \vspace*{0.7cm}
130 % {\textsc{Ulm, \today}}} \par
131 % \vspace*{5cm}
132 % {\normalsize\textsc{Betreut durch: \\
133 % Prof. Dr. Klaus Baer \\
134 % Hochschule Ulm \\
135 % Prittwitzstra{\ss}e 10\\
136 % 89075 Ulm\\}}
137 % \end{center}
138 % \vfill
139 % \end{titlepage}
140
141 % \addsec{Bitte beachten} 117 % \addsec{Bitte beachten}
142 Version vom \today: Das Dokument befindet sich noch im Aufbau, \"{A}nderungen sind dadurch jederzeit M\"{o}glich. 118 Version vom \today: Das Dokument befindet sich noch im Aufbau, \"{A}nderungen sind dadurch jederzeit M\"{o}glich.
143 \addsec{Version dieses Dokuments} 119 \addsec{Version dieses Dokuments}
144 \begin{tabular}{|p{1.5cm}|p{3.cm}|p{1.6cm}|p{2cm}|p{1.4cm}|p{4cm}|} 120 \begin{tabular}{|p{1.5cm}|p{3.cm}|p{1.6cm}|p{2cm}|p{1.4cm}|p{4cm}|}
145 \hline 121 \hline
182 158
183 \section{Definitionen und Abkürzungen} 159 \section{Definitionen und Abkürzungen}
184 160
185 Die verwendeten Begriffe sind im Projekt-Glossar erklärt. Bei Bedarf kann dort nachgeschlagen werden. 161 Die verwendeten Begriffe sind im Projekt-Glossar erklärt. Bei Bedarf kann dort nachgeschlagen werden.
186 162
187 % Im Glossar sind: Workflow Entwicklungsprozess Zyklus Iteration Phase RUP Iterativer Entwicklungsprozess Manntag Release
188 163
189 164
190 \section{Verweise auf andere Artefakte} 165 \section{Verweise auf andere Artefakte}
191 166
192 \begin{itemize} 167 \begin{itemize}
193 \item \textbf{Glossary}: Dort werden die verwendeten Fachbegriffe erklärt. 168 \item \textbf{Software Development Plan}
194 \item \textbf{Software Development Plan}: Der \emph{Development Case} ist ein Unterdokument des \emph{Software Development Plans}. 169 \item \textbf{Glossary}
195 \item \textbf{Project Plan}: Die konkrete zeitliche Planung. (Der Project Plan findet sich im Software Development Plan.)
196 \item
197 \item
198 \item
199 \end{itemize} 170 \end{itemize}
200 171
201 172
202 173
203 174
205 %%%%%%%%%%%%%% 176 %%%%%%%%%%%%%%
206 \chapter{Entwicklungsprozess} 177 \chapter{Entwicklungsprozess}
207 178
208 \section{Überblick} 179 \section{Überblick}
209 180
210 Wir werden unser Projekt nach dem \emph{Rational Unified Process} (kurz RUP) entwickeln. 181 Wir werden unser Projekt nach dem \emph{Rational Unified Process}$^{\ddagger}$ (kurz RUP) entwickeln.
211 182
212 Der RUP ist ein dynamischer und iterativer Entwicklungsprozess, der das Projekt in zwei Dimensionen (zeitlich und inhaltlich) betrachtet. 183 Der RUP ist ein dynamischer und iterativer Entwicklungsprozess, der das Projekt in zwei Dimensionen (zeitlich und inhaltlich) betrachtet.
213 Er ist ausführlich spezifiziert und umfangreich dokumentiert. 184
214 185 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.
215 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. 186
216 187 Wir haben diesen mächtigen und umfangreichen Prozess für unser kleines Projekt abgespeckt und angepasst. Wie unsere Adaptation des RUP genau aussieht, das beschreibt dieses Dokument.
217 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. 188
218 189
219 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).
220
221 Wie unsere Adaptation des RUP genau aussieht, das beschreibt dieses Dokument.
222
223
224 \newpage
225 \section{Der RUP auf einen Blick} 190 \section{Der RUP auf einen Blick}
226 191
227 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. 192 Natürlich kann man diesen umfassenden Entwicklungsprozess nicht in einem Bild komplett abbilden, jedoch zeigt die nachfolgende Grafik sehr schön, wie die Entwicklung im Bezug auf die zwei Dimensionen aussieht. Dieser Übersichtplan, soll den Aufbau des Prozesses nochmal ins Gedächtnis rufen.
228 193
229 \begin{figure}[htb] 194 \begin{figure}[htb]
230 \centering 195 \centering
231 \includegraphics[width=10cm]{pictures/png/RationalUnifiedProcess.png} 196 \includegraphics[width=9cm]{pictures/png/RationalUnifiedProcess.png}
232 \caption{Übersicht über einen Zyklus des RUP} 197 \caption{Übersicht über einen Zyklus im RUP$^{\ddagger}$ }
233 \label{fig:rationalunifiedprocess} 198 \label{fig:rationalunifiedprocess}
234 \end{figure} 199 \end{figure}
235 200
236 201
237 202
243 %%%%%%%%%%%%%% 208 %%%%%%%%%%%%%%
244 \chapter{Zeitliche Dimension} 209 \chapter{Zeitliche Dimension}
245 210
246 \section{Anpassungen} 211 \section{Anpassungen}
247 212
248 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. 213 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})
249 % FIXME: was ist das/unser Projekt (3Zyklen oder das komplette)? 214
250 215 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.
251 Jeder der drei Zyklen wird circa fünf Wochen (30 Manntage %FIXME
252 ) umfassen. An dessen Ende jeweils ein Release stehen wird. (Näheres zu den Releases findet sich im \emph{Software Development Plan}.)
253 216
254 Iterationen innerhalb der Zyklen werden wir, auf Grund der kurzen Zyklen, komplett außen vor lassen. 217 Iterationen innerhalb der Zyklen werden wir, auf Grund der kurzen Zyklen, komplett außen vor lassen.
255 218
256 Die einzelnen Phasen in den Zyklen versuchen wir, so gut es geht, zu berücksichtigen. 219
257 220
258 221 Ein Beispiel um ein Gefühl für die Größenverhältnisse zu bekommen: Unsere 90 Manntage, entsprechen realistischerweise eher einer einzelnen Iteration, als den drei Zyklen die wir für uns geplant haben.
259 222
260 \subsection{Probleme und Konsequenzen} 223 %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.
261 224
262 Der RUP ist sehr umfangreich und mächtig. Unser Projekt dagegen, ist ziemlich klein, und so bedarf es größerer Anpassungen, um den Entwicklungsprozess unserem Projekt entsprechend zurechtzustutzen. %FIXME: mit "stuzen" oder "stutzen"?? 225 %Wir finden es trotzdem wichtig, diesen Prozess zu wählen, weil die theoretischen Inhalte der Vorlesung ``Softwaretechnik 1'' sich erst durch ihre tatsächliche Anwendung im realen Projekt richtig verfestigen können.
263 226
264 Hier ein Anhaltspunkt, um welche Größenordnungen es dabei geht: Unsere 90 Manntage, entsprechen realistischerweise eher einer einzelnen Iteration, als den drei Zyklen, die wir für uns geplant haben. 227
265 228
266 Dabei muss 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.
267
268 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.
269
270 Trotz all dieser Schwierigkeiten finden wir es wichtig, diesen Prozess zu wählen, weil die theoretischen Inhalte der Vorlesung ``Softwaretechnik 1'' erst durch ihre tatsächliche Anwendung im realen Projekt vollständig zur Entfaltung kommen. So befassen wir uns intensiv (theoretisch sowie praktisch) mit einem Entwicklungsprozess, anstatt zwei Prozesse nur teilweise kennenzulernen.
271 229
272 230
273 \section{Konkrete Projektplanung} 231 \section{Konkrete Projektplanung}
274 232
275 Die konkrete Planung der einzelnen Zyklen und ihrer Meilensteine sollen sich laut RUP im \emph{Projekt Plan} befinden. Dieser gibt eine zeitliche und inhaltliche Komplettübersicht über das Projekt. 233 Die konkrete Planung der einzelnen Zyklen und ihrer Meilensteine finden sich im \emph{Software Development Plan}.
276
277 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 die Inhalte unseres Iterations Plans mit denen des Projekt Plans verschmolzen, und sie in den \emph{Software Development Plan} integriert.
278 234
279 235
280 236
281 237
282 238
283 239
284 240
285 %%%%%%%%%%%%%%%%%%%% 241 %%%%%%%%%%%%%%%%%%%%
286 \chapter{Inhaltliche Dimension} 242 \chapter{Inhaltliche Dimension}
287 243
288 Diese zweite Dimension beschreibt die inhaltliche Seite der Entwicklung. Hier wird genau festgelegt, \emph{wer} \emph{wie} \emph{was} \emph{wann} macht. 244 In der zweiten Dimension wird festgelegt, \emph{wer} (Rolle), \emph{wie} (Aktivität), \emph{was} (Artefakt), \emph{wann} (Workflow) macht.
289 245
290 Dabei gibt es vier Elemente: 246
291 \begin{itemize} 247
292 \item Rolle, das \emph{Wer}. Die \emph{Rolle} ist eine Verantwortlichkeit, die jemand 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} (siehe Software Development Plan). 248 \section{Business Modeling}
293 \item Aktivität, das \emph{Wie}. Eine Aktivität ist ein bestimmte Arbeitseinheit, die der Arbeiter mit einer bestimmten Rolle erledigen muss. Üblicherweise soll dabei ein Artefakt erstellt oder aktualisiert werden. 249
294 \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. 250 \paragraph{Zweck}
295 \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 (Rolle, Aktivität und Artefakt) zu einer direkt wertschaffenden Struktur zusammengebaut. 251 Gemeinsames Verständniss zwischen Entwicklern und Anwendern schaffen
296 \end{itemize} 252
297 253 \paragraph{Wird erreicht durch}
298 \section{Core Workflows} 254 Dokumentation der relevanten Geschäftsprozesse in Use Cases
299 255
300 \subsection{Business Modeling} 256 %\paragraph{Anpassungen}
301 (Geschäftsprozessmodellierung) 257 %Keine besonderen.
302 258
303 \paragraph{Zweck} 259 \paragraph{Wer} Fachliches Team, Kunde
304 Dokumentation der relevanten Geschäftsprozesse in Use Cases, um ein gemeinsames Verständniss zwischen Entwicklern und Anwendern zu schaffen. 260 \paragraph{Wie} im Gespräch
261 \paragraph{Was} Glossary
262
263 %\paragraph{Artefakte}
264 %\begin{itemize}
265 % \item Glossary
266 %\end{itemize}
267
268
269
270 \section{Requirements}
271
272 \paragraph{Zweck}
273 Ermitteln, was das System leisten soll. Die funktionalen Anforderungen sollen erfasst werden.
305 274
306 \paragraph{Anpassungen} 275 \paragraph{Anpassungen}
307 Keine besonderen. 276 Keine besonderen.
308 277
309 \paragraph{Artefakte} 278 \paragraph{Artefakte}
310 \begin{itemize} 279 \begin{itemize}
311 \item Glossary 280 \item Vision
312 \item Business Use Cases %% FIXME 281 \item Use Cases
313 \end{itemize} 282 \end{itemize}
314 283
315 284
316 285
317 \subsection{Requirements} 286 \section{Analysis \& Design}
318 (Anforderungen) 287
319 288 \paragraph{Zweck}
320 \paragraph{Zweck} 289 Aufbau und Technologie des Systems festlegen. Festlegung wie wird das System realisiert wird.
321 Ermitteln, was das System leisten soll. Die funktionalen Anforderungen sollen erfasst werden. 290
291 \paragraph{Anpassungen}
292 Die Technologie und Teile der Umsetzung sind durch das Projekt vorgegeben und somit fix.
293
294 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.
295
296 \paragraph{Artefakte}
297 \begin{itemize}
298 \item Software Architecture Document
299 \end{itemize}
300
301
302
303
304 \section{Implementation}
305
306 \paragraph{Zweck}
307 Systemteile entwickeln und zusammenfügen. Komponententests.
308
309 \paragraph{Anpassungen}
310 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.
311
312 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.
313
314 \paragraph{Artefakte}
315 Momentan keine.
316
317
318
319 \section{Testing}
320
321 \paragraph{Zweck}
322 Test des Zusammenspiels der Komponenten. Funktionsweise des Systems gegen die Anforderungen prüfen.
323
324 \paragraph{Anpassungen}
325 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.
326
327 Dies heißt aber keineswegs, dass wir ihn zum geeigneten Zeitpunkt nicht voll ausbauen werden.
328
329 \paragraph{Artefakte}
330 Noch keine.
331
332
333
334 \section{Deployment}
335
336 \paragraph{Zweck}
337 Auslieferung des Systems an den Kunden und Inbetriebnahme. Schulung der Benutzer.
338
339 \paragraph{Anpassungen}
340 Auch hier sparen wir um dafür die Entwicklung voran zu treiben.
341
342 \paragraph{Artefakte}
343 \begin{itemize}
344 \item Release Notes (empfohlen) %FIXME rechtschreibung
345 \end{itemize}
346
347
348
349
350
351 \section{Configuration \& Changemanagement}
352
353 \paragraph{Zweck}
354 Verwaltung der zum Projekt gehörenden Daten. Versionierung und Konsistenz.
355
356 \paragraph{Anpassungen}
357 Alle Daten müssen im Project Repository abgelegt werden. Dieses soll die zentrale Informationsstelle sein.
358
359 Jeder Mitarbeiter darf an jeder Stelle des Projekts Änderungen durchführen.
360
361 % FIXME: Inhalte für Karl einfügen
362
363 \paragraph{Artefakte}
364 \begin{itemize}
365 \item Project Repository
366 \end{itemize}
367
368
369
370 \section{Projectmanagement}
371
372 \paragraph{Zweck}
373 Zwischen konkurrierenden Zielen vermitteln. Auf Risiken reagieren.
322 374
323 \paragraph{Anpassungen} 375 \paragraph{Anpassungen}
324 Keine besonderen. 376 Keine besonderen.
325 377
326 \paragraph{Artefakte} 378 \paragraph{Artefakte}
327 \begin{itemize} 379 \begin{itemize}
328 \item Vision 380 \item Software Development Plan
329 \item Use Case
330 \item Use Case Diagram
331 \end{itemize}
332
333
334
335 \subsection{Analysis \& Design}
336 (Analyse \& Design)
337
338 \paragraph{Zweck}
339 Aufbau und Technologie des Systems festlegen. Festlegung wie wird das System realisiert wird.
340
341 \paragraph{Anpassungen}
342 Die Technologie und Teile der Umsetzung sind durch das Projekt vorgegeben und somit fix.
343
344 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.
345
346 \paragraph{Artefakte}
347 \begin{itemize}
348 \item Software Architecture Document
349 \end{itemize}
350
351
352
353
354 \subsection{Implementation}
355 (Implementierung)
356
357 \paragraph{Zweck}
358 Systemteile entwickeln und zusammenfügen. Komponententests.
359
360 \paragraph{Anpassungen}
361 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.
362
363 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.
364
365 \paragraph{Artefakte}
366 Momentan keine.
367
368
369
370 \subsection{Testing}
371 (Test)
372
373 \paragraph{Zweck}
374 Test des Zusammenspiels der Komponenten. Funktionsweise des Systems gegen die Anforderungen prüfen.
375
376 \paragraph{Anpassungen}
377 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.
378
379 Dies heißt aber keineswegs, dass wir ihn zum geeigneten Zeitpunkt nicht voll ausbauen werden.
380
381 \paragraph{Artefakte}
382 Noch keine.
383
384
385
386 \subsection{Deployment}
387 (Verteilung)
388
389 \paragraph{Zweck}
390 Auslieferung des Systems an den Kunden und Inbetriebnahme. Schulung der Benutzer.
391
392 \paragraph{Anpassungen}
393 Auch hier sparen wir um dafür die Entwicklung voran zu treiben.
394
395 \paragraph{Artefakte}
396 \begin{itemize}
397 \item Release Notes (empfohlen) %FIXME rechtschreibung
398 \end{itemize}
399
400
401
402
403 \section{Supplymentary Workflows} %FIXME: korrekter Name?
404
405 \subsection{Configuration \& Changemanagement}
406 (Konfigurations- \& Änderungsmanagement)
407
408 \paragraph{Zweck}
409 Verwaltung der zum Projekt gehörenden Daten. Versionierung und Konsistenz.
410
411 \paragraph{Anpassungen}
412 Alle Daten müssen im Project Repository abgelegt werden. Dieses soll die zentrale Informationsstelle sein.
413
414 Jeder Mitarbeiter darf an jeder Stelle des Projekts Änderungen durchführen.
415
416 \paragraph{Artefakte}
417 \begin{itemize}
418 \item Project Repository
419 \end{itemize}
420
421
422
423 \subsection{Projectmanagement}
424 (Projektmanagement)
425
426 \paragraph{Zweck}
427 Zwischen konkurrierenden Zielen vermitteln. Auf Risiken reagieren.
428
429 \paragraph{Anpassungen}
430 Keine besonderen.
431
432 \paragraph{Artefakte}
433 \begin{itemize}
434 \item Software Development Plan (Project Plan)
435 \item Risklist 381 \item Risklist
436 \end{itemize} 382 \end{itemize}
437 383
438 384
439 385
440 \subsection{Environment} 386 \section{Environment}
441 (Entwicklungsumgebung)
442 387
443 \paragraph{Zweck} 388 \paragraph{Zweck}
444 Bereitstellung von Hardware, Software und Know-How. 389 Bereitstellung von Hardware, Software und Know-How.
445 390
446 \paragraph{Anpassungen} 391 \paragraph{Anpassungen}
465 410
466 \appendix 411 \appendix
467 %\chapter{Glossar} 412 %\chapter{Glossar}
468 \chapter{Quellen} 413 \chapter{Quellen}
469 \begin{itemize} 414 \begin{itemize}
470 \item Dokumentation zum \emph{Rational Unified Process} (\texttt{http://www-306.ibm.com/software/awdtools/rup/}) 415 \item Dokumentation zum \emph{Rational Unified Process} \\ (\texttt{http://www-306.ibm.com/software/awdtools/rup/})
471 \item Skript von Herrn Baer zur Vorlesung \emph{Softwaretechnik 1} an der Hochschule Ulm 416 \item Skript von Herrn Baer zur Vorlesung \emph{Softwaretechnik 1} an der Hochschule Ulm
472 \item http://wikipedia.org 417 \item http://wikipedia.org
473 \item \emph{Rational Unified Process - Best Practices for Software Development Teams} 418 \item \emph{Rational Unified Process - Best Practices for Software Development Teams}
474 \end{itemize} 419 \end{itemize}
475 420
476 Anmerkung zur Abbildung \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. 421 $\ddagger{}$ The image \ref{fig:rationalunifiedprocess} is from the Rational Unified Process (software product) version 2003.06.12.01. This image and the names ``Rational Unified Process'' and ``RUP'' are copyright by Rational Software Corporation, now a division of IBM.
477 422
478 423
479 424
480 \end{document} 425 \end{document}
481 426