1 \chapter{Einleitung}

2

3 \section{Zweck}

4

5 Dieses Dokument beschreibt den Entwicklungsprozess nach dem wir in unserem Projekt vorgehen.

6

7

8 \section{Definitionen und Abkürzungen}

9

10 Die verwendeten Begriffe sind im Projekt-Glossar erklärt. Bei Bedarf kann dort nachgeschlagen werden.

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

30

31 \section{Verweise}

32

33

34

35

36

37

38 %%%%%%%%%%%%%%

39 \chapter{Entwicklungsprozess}

40 \section{Überblick}

41

42 Wir werden unser Projekt nach dem Rational Unified Process (kurz RUP) entwickeln.

43

44 Der RUP ist ein dynamischer und iterativer Entwicklungsprozess, der das Projekt in zwei Dimensionen betrachtet.

45 Er ist ausführlich spezifiziert und umfangreich dokumentiert. (http:// FIXME ).

46

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}

51

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.

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.

54

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.

56 Jeder Zyklus wird circa vier Wochen umfassen (18 Manntage). An dessen Ende ein Release steht.

57 Iterationen innerhalb der Zyklen werden wir, aufgrund der kurzen Zyklen, außen vor lassen.

58

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