docs/Development-Case: development-case.tex comparison

comparison development-case.tex @ 11:fb6ee4e487da Abgabeversion

review by dad

author	meillo@marmaro.de
date	Tue, 22 Jan 2008 23:40:34 +0100
parents	06bd2953d319
children

comparison

equal deleted inserted replaced

-:06bd2953d319
+:fb6ee4e487da
 \hline\hline
 0.1 & Markus Schnalke & E & 2007-11-27 & O & Erste Version \\ \hline
 0.2 & Markus Schnalke & AE & 2008-01-13 & O & Neue Struktur des Dokuments \\ \hline
 0.4 & Markus Schnalke & AE & 2008-01-16 & A & Struktur überarbeitet \\ \hline
 0.4.1 & Karl Oppermann & QS & 2008-01-17 & A & Allgemeines Review \\ \hline
-0.5 & Markus Schnalke & AE & 2008-01-18 & A & Überarbeitung; Fachbegriffe jetzt englisch \\ \hline
+0.5 & Markus Schnalke & AE & 2008-01-18 & A & Überarbeitung \\ \hline
 0.5.1 & Veysel Imamoglu & QS & 2008-01-18 & A & Rechtschreibkorrektur \\ \hline
 1.0 & Markus Schnalke & AB & 2008-01-22 & A & Finale Version für R3 \\ \hline
 \end{tabular}
 {\footnotesize\vspace*{-0.1cm}Aktion: E – Erstellung; AE – \"{A}nderung; QS – Review; AB – Abnahme} \par
 {\footnotesize\vspace*{-0.4cm} Status: O – Offen; D – Diskussion; A – Akzeptiert}
 \section{Verweise auf andere Artefakte}
 Der \textbf{Software Development Plan} ist an vielen Stellen mit diesem Dokument verknüpft.
-Zur Klärung der verwendeten Fachbegriffe kann im \textbf{Glossary} nachgeschlagen werden.
+%Zur Klärung der verwendeten Fachbegriffe kann im \textbf{Glossary} nachgeschlagen werden.
 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.
 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.
-\section{Der RUP auf einen Blick}
+\section{Der Rational Unified Process auf einen Blick}
-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.
+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.
 \begin{figure}[htb]
 	\centering
 	\includegraphics[width=9cm]{pictures/png/RationalUnifiedProcess.png}
 	\caption{Übersicht über einen Zyklus im RUP$^{\ddagger}$ }
 %%%%%%%%%%%%%%
 \chapter{Zeitliche Dimension}
 \section{Anpassungen}
-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})
+Wir führen in unserem Projekt drei Zyklen durch. Jeder der drei Zyklen wird circa fünf Wochen (30 Manntage) umfassen. An deren Ende wird jeweils ein Release stehen. (siehe \emph{Software Development Plan})
-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.
+Die einzelnen Phasen in den Zyklen versuchen wir, so gut es geht, zu berücksichtigen. Es muss bedacht werden, dass bei uns pro Phase ganz grob nur etwa 4 Manntage (d.h. circa 4 Stunden pro Person) zur Verfügung stehen.
 Iterationen innerhalb der Zyklen werden wir, auf Grund der kurzen Zyklen, komplett außen vor lassen.
-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.
+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.
 %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.
 %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.
 %%%%%%%%%%%%%%%%%%%%
 \chapter{Inhaltliche Dimension}
-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.
+In der zweiten Dimension wird festgelegt, \emph{wer} (Rolle), \emph{wie} (Aktivität), \emph{was} (Artefakt), \emph{wann} (Zeitpunkt) macht. Diese Elemente werden in Workflows vereint.
 Hier beschreiben wir, wie wir die vorgegebenen Workflows des RUP anpassen.
 \section{Business Modeling}
 \subsection*{Zweck}
-Gemeinsames Verständniss zwischen Entwicklern und Anwendern schaffen.
+Gemeinsames Verständnis zwischen Entwicklern und Anwendern schaffen.
 \subsection*{Anpassungen}
-Wir erstellen keinen Business Use Case, weil das Seminarsystem ein gestelltes abgeschlossenes Szenario ist und nicht in bestehende Geschäftsabläufe eingebunden werden muss.
+Wir erstellen keinen Business Use Case, weil das Seminarsystem ein gestelltes, abgeschlossenes Szenario ist und nicht in bestehende Geschäftsabläufe eingebunden werden muss.
 \subsection*{Artefakte}
 \begin{tabular}{p{4cm}p{10cm}}
-	\rowcolor{gray07} Artefakt  & \textbf{Glossary} \\
+	\rowcolor{gray09} Artefakt  & \textbf{Glossary} \\
 	\rowcolor{white}  Rolle     & Fachliches Team, Kunde \\
 	\rowcolor{gray09} Aktivität & erstellen gemeinsam \\
-	\rowcolor{white}  Wann      & Inception, Ergänzungen jeder Zeit \\
+	\rowcolor{white}  Zeitpunkt & Inception, Ergänzungen jeder Zeit \\
 	\rowcolor{gray09} Review    & Fachliches Team und Kunde durch gemeinsames Erstellen \\
 \end{tabular}
 \subsection*{Anpassungen}
 Keine besonderen.
 \subsection*{Artefakte}
 \begin{tabular}{p{4cm}p{10cm}}
-	\rowcolor{gray07} Artefakt  & \textbf{Vision} \\
+	\rowcolor{gray09} Artefakt  & \textbf{Vision} \\
 	\rowcolor{white}  Rolle     & Fachliches Team, Kunde \\
 	\rowcolor{gray09} Aktivität & erarbeiten im Gespräch \\
-	\rowcolor{white}  Wann      & Inception \\
+	\rowcolor{white}  Zeitpunkt & Inception \\
 	\rowcolor{gray09} Review    & Fachliches Team und Kunde durch gemeinsames Erarbeiten \\
 	& \\
-	\rowcolor{gray07} Artefakt  & \textbf{Use Cases} \\
+	\rowcolor{gray09} Artefakt  & \textbf{Use Cases} \\
 	\rowcolor{white}  Rolle     & Fachliches Team, Kunde \\
 	\rowcolor{gray09} Aktivität & erarbeiten im Gespräch \\
-	\rowcolor{white}  Wann      & Inception und Elaboration \\
+	\rowcolor{white}  Zeitpunkt & Inception und Elaboration \\
 	\rowcolor{gray09} Review    & Fachliches Team und Kunde durch gemeinsames Erarbeiten \\
 \end{tabular}
 \section{Analysis \& Design}
 \subsection*{Zweck}
-Aufbau und Technologie des Systems festlegen. Festlegung wie wird das System realisiert wird.
+Aufbau und Technologie des Systems festlegen. Festlegung, wie das System realisiert wird.
 \subsection*{Anpassungen}
-Die Technologie und Rahmenbedingungen der Umsetzung sind durch das Projekt vorgegeben und somit fix.
+Die Technologie und die Rahmenbedingungen der Umsetzung sind durch das Projekt vorgegeben und somit fix.
-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.
+Zum jetzigen Zeitpunkt arbeiten wir uns vor allem in die neue Technologie ein. Unsere Softwarearchitektur ist bisher vor allem eine Vorarbeit für später.
 \subsection*{Artefakte}
 \begin{tabular}{p{4cm}p{10cm}}
-	\rowcolor{gray07} Artefakt  & \textbf{Software Architecture Document} \\
+	\rowcolor{gray09} Artefakt  & \textbf{Software Architecture Document} \\
-	\rowcolor{white}  Rolle     & Team Technische Architektur \\
+	\rowcolor{white}  Rolle     & Team ``Technische Architektur'' \\
 	\rowcolor{gray09} Aktivität & erstellt \\
-	\rowcolor{white}  Wann      & Elaboration \\
+	\rowcolor{white}  Zeitpunkt & Elaboration \\
 	\rowcolor{gray09} Review    & Entwickler nach Änderungen \\
 \end{tabular}
 Systemteile entwickeln und zusammenfügen. Komponententests.
 \subsection*{Anpassungen}
 Momentan besteht dieser Workflow in erster Line aus der Entwicklung von Prototypen jeder Art (Modelle, Templates, etc) um die Technologie zu erforschen.
-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.
+Konkrete Artefakte werden bisher nicht erstellt, weil es zum jetzigen Stand nicht sinnvoll ist nach festen Plänen vorzugehen. Unser Kenntnisstand ändert sich sehr schnell und wir wollen flexibel reagieren können.
 \subsection*{Artefakte}
 Keine definiert.
 %	\begin{tabular}{p{4cm}p{10cm}}
-%		\rowcolor{gray07} Artefakt  & \textbf{Glossary} \\
+%		\rowcolor{gray09} Artefakt  & \textbf{Glossary} \\
 %		\rowcolor{white}  Rolle     & Fachliches Team, Kunde \\
 %		\rowcolor{gray09} Aktivität & erstellen gemeinsam \\
-%		\rowcolor{white}  Wann      & Inception (ergänzend jeder Zeit) \\
+%		\rowcolor{white}  Zeitpunkt & Inception (ergänzend jeder Zeit) \\
 %		\rowcolor{gray09} Review    &  \\
 %	\end{tabular}
 \subsection*{Zweck}
 Test des Zusammenspiels der Komponenten. Funktionsweise des Systems gegen die Anforderungen prüfen.
 \subsection*{Anpassungen}
-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.
+Wir erkunden eine neue Technologie. Unser Ziel ist es, in kurzer Zeit möglichst viele Bereiche und Möglichkeiten zu erkunden. Tests bremsen 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.
 Alle Dokumente müssen von mindestens einer weiteren Person begutachtet werden. Die genauen Vorgaben stehen bei den Artefaktbeschreibungen in diesem Kapitel.
 \subsection*{Artefakte}
 Keine definiert.
 %	\begin{tabular}{p{4cm}p{10cm}}
-%		\rowcolor{gray07} Artefakt  & \textbf{Dokument Reviews} \\
+%		\rowcolor{gray09} Artefakt  & \textbf{Dokument Reviews} \\
 %		\rowcolor{white}  Rolle     & Beliebiger Mitarbeiter \\
 %		\rowcolor{gray09} Aktivität & prüfen gemeinsam das Dokument \\
-%		\rowcolor{white}  Wann      & nachdem Dokument erstellt/geändert wurde \\
+%		\rowcolor{white}  Zeitpunkt & nachdem Dokument erstellt/geändert wurde \\
 %		\rowcolor{gray09} Review    &  \\
 %	\end{tabular}
 \subsection*{Zweck}
 Auslieferung des Systems an den Kunden und Inbetriebnahme.
 \subsection*{Anpassungen}
-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.
+Solange wir keine lauffähigen Ergebnisse haben, vernachlässigen wir diesen Workflow. Wenn dies nicht mehr der Fall sein wird, muss eine Anleitung zur Inbetriebnahme des Programms erstellt werden. Ebenso muss dann der genaue Funktionsumfang des Systems beschrieben sein.
 \subsection*{Artefakte}
 \begin{tabular}{p{4cm}p{10cm}}
-	\rowcolor{gray07} Artefakt  & \textbf{Release Notes} \\
+	\rowcolor{gray09} Artefakt  & \textbf{Release Notes} \\
 	\rowcolor{white}  Rolle     & Projektleiter, Entwickler \\
 	\rowcolor{gray09} Aktivität & sollen erstellen \\
-	\rowcolor{white}  Wann      & Transition \\
+	\rowcolor{white}  Zeitpunkt & Transition \\
-	\rowcolor{gray09} Review    & anderer Entwickler vor Auslieferung \\
+	\rowcolor{gray09} Review    & anderer Entwickler vor der Auslieferung \\
 \end{tabular}
 \subsection*{Anpassungen}
 Keine besonderen.
 \subsection*{Artefakte}
 \begin{tabular}{p{4cm}p{10cm}}
-	\rowcolor{gray07} Artefakt  & \textbf{Software Development Plan} \\
+	\rowcolor{gray09} Artefakt  & \textbf{Software Development Plan} \\
 	\rowcolor{white}  Rolle     & Projektleiter \\
 	\rowcolor{gray09} Aktivität & erstellt \\
-	\rowcolor{white}  Wann      & Inception \\
+	\rowcolor{white}  Zeitpunkt & Inception \\
 	\rowcolor{gray09} Review    & Entwickler und Risikomanager nach Änderungen \\
 	& \\
-	\rowcolor{gray07} Artefakt  & \textbf{Risk Management Plan} \\
+	\rowcolor{gray09} Artefakt  & \textbf{Risk Management Plan} \\
 	\rowcolor{white}  Rolle     & Riskmanager \\
 	\rowcolor{gray09} Aktivität & erstellt \\
-	\rowcolor{white}  Wann      & Alle Phasen \\
+	\rowcolor{white}  Zeitpunkt & Alle Phasen \\
 	\rowcolor{gray09} Review    & Komplettes Team in Inception Phase \\
 \end{tabular}
 Die offiziellen Kommunikationwege im Team sind das wöchentliche Teammeeting und die Projekt-Mailingliste.
 \subsection*{Artefakte}
 \begin{tabular}{p{4cm}p{10cm}}
-	\rowcolor{gray07} Artefakt  & \textbf{Development Case} \\
+	\rowcolor{gray09} Artefakt  & \textbf{Development Case} \\
 	\rowcolor{white}  Rolle     & Projektleiter \\
 	\rowcolor{gray09} Aktivität & erstellt \\
-	\rowcolor{white}  Wann      & Inception \\
+	\rowcolor{white}  Zeitpunkt & Inception \\
 	\rowcolor{gray09} Review    & Komplettes Team in Inception Phase \\
 	& \\
-	\rowcolor{gray07} Artefakt  & \textbf{Tutorials} \\
+	\rowcolor{gray09} Artefakt  & \textbf{Tutorials} \\
 	\rowcolor{white}  Rolle     & Toolspezialist \\
 	\rowcolor{gray09} Aktivität & kann erstellen \\
-	\rowcolor{white}  Wann      & Alle Phasen \\
+	\rowcolor{white}  Zeitpunkt & Alle Phasen \\
 	\rowcolor{gray09} Review    & eine Person für die das Tutorial geschrieben wurde \\
 \end{tabular}
 \appendix
 %\chapter{Glossar}
 \chapter{Quellen}
 			\begin{itemize}
 				\item Dokumentation zum \emph{Rational Unified Process} \\ (\texttt{http://www-306.ibm.com/software/awdtools/rup/})
-				\item Skript von Herrn Baer zur Vorlesung \emph{Softwaretechnik 1} an der Hochschule Ulm
+				\item Skript von Herrn Prof. Dr. Baer zur Vorlesung \emph{Softwaretechnik 1} an der Hochschule Ulm
 				\item http://wikipedia.org
 				\item \emph{Rational Unified Process - Best Practices for Software Development Teams}
 			\end{itemize}
 			$\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.

Mercurial > docs > Development-Case

comparison development-case.tex @ 11:fb6ee4e487da Abgabeversion