Mercurial > docs > Development-Case

comparison development-case-content.tex @ 1:3b7bede36504

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
added real content structure; added first real content
author meillo@marmaro.de
date Mon, 14 Jan 2008 07:25:25 +0100
parents 662d647b9e94
children 64246b8cbb50
comparison
equal deleted inserted replaced
0:662d647b9e94 1:3b7bede36504
7 7
8 \section{Definitionen und Abkürzungen} 8 \section{Definitionen und Abkürzungen}
9 9
10 Die verwendeten Begriffe sind im Projekt-Glossar erklärt. Bei Bedarf kann dort nachgeschlagen werden. 10 Die verwendeten Begriffe sind im Projekt-Glossar erklärt. Bei Bedarf kann dort nachgeschlagen werden.
11 11
12 Workflow
13
14 Entwicklungsprozess
15
16 Zyklus
17
18 Iteration
19
20 Phase
21
22 RUP
23
24 Iterativer Entwicklungsprozess
25
26 Manntag
27
28 Release
29
12 30
13 \section{Verweise} 31 \section{Verweise}
14 32
15 33
16 34
17 35
18 \chapter{Lebenszyklus-Modell}
19
20 FIXME
21 36
22 37
23 38 %%%%%%%%%%%%%%
24 39 \chapter{Entwicklungsprozess}
25 40 \section{Überblick}
26 \chapter{Kern-Workflows}
27
28 \section{Workflow}
29
30 FIXME
31
32
33 \section{Artefakte}
34
35 FIXME
36
37
38 \section{Iterationsplanung}
39
40 FIXME
41
42
43 \section{}
44 \section{}
45
46
47
48 \chapter{Kern Workflows}
49
50
51
52
53
54
55 41
56 Wir werden unser Projekt nach dem Rational Unified Process (kurz RUP) entwickeln. 42 Wir werden unser Projekt nach dem Rational Unified Process (kurz RUP) entwickeln.
57 43
58 Der RUP ist ein dynamischer und iterativer Entwicklungsprozess, der das Projekt in zwei Dimensionen betrachtet. 44 Der RUP ist ein dynamischer und iterativer Entwicklungsprozess, der das Projekt in zwei Dimensionen betrachtet.
59 Er ist ausführlich spezifiziert und umfangreich dokumentiert. (http:// FIXME ). 45 Er ist ausführlich spezifiziert und umfangreich dokumentiert. (http:// FIXME ).
60 46
61 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. 47 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.
48
49
50 \section{Anpassungen}
62 51
63 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. 52 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.
64 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. 53 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.
65 54
66 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. 55 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.
67 Jeder Zyklus wird circa vier Wochen umfassen (18 Manntage). An dessen Ende ein Release steht. 56 Jeder Zyklus wird circa vier Wochen umfassen (18 Manntage). An dessen Ende ein Release steht.
68 Iterationen innerhalb der Zyklen werden wir, aufgrund der kurzen Zyklen, außen vor lassen. 57 Iterationen innerhalb der Zyklen werden wir, aufgrund der kurzen Zyklen, außen vor lassen.
69 58
70 Die einzelnen Phasen (zweite Dimension) in den Zyklen versuchen wir, so gut es geht, zu berücksichtigen. 59 Die einzelnen Phasen (zweite Dimension) in den Zyklen versuchen wir, so gut es geht, zu berücksichtigen.
60
61
62
63
64
65
66 \chapter{Projektplanung}
67
68 siehe \emph{Projektplan} diesbezüglich
69
70
71
72
73
74 \chapter{Kern-Workflows}
75
76
77 \subsection{Business Modeling}
78
79 FIXME
80
81 \paragraph{Artefakte}
82
83
84
85 \subsection{Requirements}
86
87 \paragraph{Artefakte}
88 \begin{itemize}
89 \item Glossary
90 \item Use-Case
91 \item Use-Case Model
92 \item Vision
93 \end{itemize}
94
95
96
97 \subsection{Analysis \& Design}
98
99 \paragraph{Artefakte}
100 \begin{itemize}
101 \item Software Architecture Document
102 \end{itemize}
103
104
105
106 \subsection{Implementation}
107
108 \paragraph{Artefakte}
109
110
111 \subsection{Testing}
112
113 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.
114
115
116
117 \subsection{Deployment}
118
119 \paragraph{Artefakte}
120
121
122 \subsection{Configuration \& Changemanagement}
123
124 \paragraph{Artefakte}
125 \begin{itemize}
126 \item Project Repository
127 \end{itemize}
128
129
130 \subsection{Projectmanagement}
131
132 \paragraph{Artefakte}
133 \begin{itemize}
134 \item Software Development Plan
135 \item Iteration Plan % FIXME
136 \end{itemize}
137
138
139 \subsection{Environment}
140
141 \paragraph{Artefakte}
142 \begin{itemize}
143 \item Development Case
144 \item Tools
145 \item User Interface Guidlines % FIXME
146 \end{itemize}
147
148
149