1 % V. 1.0

2 \documentclass[a4paper,12pt,titlepage,DIV12,parskip]{scrreprt}

3 \setlength{\parskip}{3mm} %abstand abs\"{a}tze und listen

4 \usepackage{setspace}

5 \usepackage[utf8]{inputenc}

6 \usepackage{ngerman}

7 \usepackage[pdftex]{graphicx}

8 \usepackage[table]{xcolor}

9 %\usepackage{SIunits}

10 \usepackage{ragged2e,array}

11 \usepackage{wrapfig}

12 \usepackage[footnotesize]{caption2}

13 \usepackage{supertabular}

14 \usepackage{chngcntr}

15 \usepackage{longtable}

16 %\usepackage{lastpage}

17 \usepackage{caption2}

18 \usepackage[right]{eurosym}

19 %\usepackage{float}

20 \usepackage[ngerman]{varioref}

21 %\usepackage{enumitem}

22 \usepackage[colorlinks,linkcolor=black,urlcolor=blue,bookmarks,bookmarksopen,bookmarksnumbered]{hyperref}

23

24 %PDF Infos

25 \pdfinfo{

26 /Title (development-case.tex)

27 /Subject (Development Case)

28 %/Creator (TeX / pdfTeX)

29 %/Producer (Christoph Galler)

30 /Author (markus schnalke)

31 /CreationDate (D:20080113090000)

32 /ModDate (D:20080113090000)

33 }

34

35 %neues Kommando fuer Breitenangabe in der Tabelle mit vorgegebener Breite:

36 \newcommand{\preserveBackslash}[1]{\let\temp=\\#1\let\\=\temp}

37 \newcolumntype{R}[1]{>{\preserveBackslash\RaggedLeft}p{#1}}

38 % Font Familie

39 \renewcommand{\familydefault}{\sfdefault}

40 %\nofiles

41 % Fuer tabellenkopf

42 \newcommand{\hoehe}{\parbox[1pt][2em][c]{0cm}{}}

43

44 \definecolor{gray09}{gray}{0.9}

45 \definecolor{gray07}{gray}{0.7}

46

47 %Counternummerierung \"{a}ndern -> 1.1 2.1 3.1 etc.

48 \counterwithin{section}{chapter}

49

50 % Name f\"{u}r autoref bei figure Umgebungen: Abbildung x.z

51 \renewcommand{\figureautorefname}{Abbildung}

52 \renewcommand{\chapterautorefname}{Kapitel}

53 \renewcommand{\sectionautorefname}{Unterkapitel}

54 \renewcommand{\tableautorefname}{Tabelle}

55

56

57 % Textkoerperhoehe

58 \setlength{\headsep}{0.6cm}

59 \addtolength{\textheight}{0.9cm}

60 \setlength{\footskip}{0.9cm}

61

62 % Kopf- und Fu{\ss}zeile

63 \setlength{\headheight}{2cm}

64 \usepackage[automark]{scrpage2}

65 \automark[section]{section}

66 \setheadwidth{15.8cm}

67 \ihead{\headmark}

68 \ihead{Development Case}

69 \chead{{\color{blue}\color{black}\rule[-10pt]{18.4cm}{0.1pt}\color{black}}}

70 \ohead{\headmark}

71 \setfootwidth[-74pt]{18.3cm}

72 \setfootsepline[foot]{.1pt}

73 \ifoot{\hspace{2.6cm}\footnotesize Gruppe 2: Seminarverwaltungssystem (Topcased)}

74 \cfoot{}

75 \ofoot{\footnotesize Seite \thepage} % ~von \pageref{LastPage}}

76 \renewcommand*{\chapterpagestyle}{scrheadings}

77 \renewcommand*{\indexpagestyle}{scrheadings}

78 \pagestyle{scrheadings}

79

80 % Kapitel nicht zu tief beginnen

81 \renewcommand*\chapterheadstartvskip{\vspace*{0cm}}

82

83

84 \begin{document}

85

86 %

87 % Titelei

88 %

89 \begin{titlepage}

90 \vspace*{-0cm}

91 {\hspace*{11cm}\includegraphics*[scale=0.5]{pictures/png/logo_hsu_klein}}

92 \begin{center}

93 \vspace*{1.9cm}

94 {\normalsize\textsc{Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu,

95 Dimitar Dimitrov, \\Karl Oppermann, Nathalie Hrycej, Markus Schnalke,

96 Christoph Galler}} \par

97 \vspace*{0.6cm}

98 \large \textbf{Modellgetriebene Softwareentwicklung auf Basis von

99 TOPCASED am Beispiel eines Seminarverwaltungssystems} \par

100 \Huge \textbf{Development Case} \par

101 \vspace*{0.8cm}

102 {\Large{} \par

103 \vspace*{0.7cm}

104 {\textsc{Ulm, \today}}} \par

105 \vspace*{4.5cm}

106 {\normalsize\textsc{Betreut durch: \\

107 Prof. Dr. Klaus Baer \\

108 Hochschule Ulm \\

109 Prittwitzstraße 10\\

110 89075 Ulm\\}}

111 \end{center}

112 \vfill

113 \end{titlepage}

114

115

116

117 \addsec{Version dieses Dokuments}

118 \begin{tabular}{|p{1.5cm}|p{3.cm}|p{1.6cm}|p{2cm}|p{1.4cm}|p{4cm}|}

119 \hline

120 \multicolumn{5}{|l}{\parbox[0pt][3.4em][l]{12cm}{\vspace{0.2cm}\large Dokument: \textbf{Development Case} \newline \emph{ Online-Seminarbuchungssystem}}} & \multicolumn{1}{r|}{\parbox[0pt][3.4em][r]{1.9cm}{\includegraphics*[scale=0.25]{pictures/png/logo_hsu}}} \\

121 \hline\hline

122 \hoehe{\textbf{Version}} & \textbf{Person} & \textbf{Aktion} & \textbf{Datum} & \textbf{Status} & \textbf{Kommentar} \\

123 \hline\hline

124 0.1 & Markus Schnalke & E & 2007-11-27 & O & Erste Version \\ \hline

125 0.2 & Markus Schnalke & AE & 2008-01-13 & O & Neue Struktur des Dokuments \\ \hline

126 0.4 & Markus Schnalke & AE & 2008-01-16 & A & Struktur überarbeitet \\ \hline

127 0.4.1 & Karl Oppermann & QS & 2008-01-17 & A & Allgemeines Review \\ \hline

128 0.5 & Markus Schnalke & AE & 2008-01-18 & A & Überarbeitung; Fachbegriffe jetzt englisch \\ \hline

129 0.5.1 & Veysel Imamoglu & QS & 2008-01-18 & A & Rechtschreibkorrektur \\ \hline

130 1.0 & Markus Schnalke & AB & 2008-01-22 & A & Finale Version für R3 \\ \hline

131 \end{tabular}

132 {\footnotesize\vspace*{-0.1cm}Aktion: E – Erstellung; AE – \"{A}nderung; QS – Review; AB – Abnahme} \par

133 {\footnotesize\vspace*{-0.4cm} Status: O – Offen; D – Diskussion; A – Akzeptiert}

134 \clearpage

135

136 % Inhaltsverzeichnis

137 \setcounter{tocdepth}{3}

138 %\renewcommand\contentsname{"Uberblick}

139 \tableofcontents

140

141 \clearpage

142

143

144

145

146 % Content

147

148

149

150 \chapter{Einleitung}

151

152 \section{Zweck des Dokuments}

153

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

155

156

157 \section{Definitionen und Abkürzungen}

158

159 Die verwendeten Begriffe sind im Glossary erklärt. Bei Bedarf kann dort nachgeschlagen werden.

160

161

162

163 \section{Verweise auf andere Artefakte}

164

165 Der \textbf{Software Development Plan} ist an vielen Stellen mit diesem Dokument verknüpft.

166

167 Zur Klärung der verwendeten Fachbegriffe kann im \textbf{Glossary} nachgeschlagen werden.

168

169

170

171

172

173 %%%%%%%%%%%%%%

174 \chapter{Entwicklungsprozess}

175

176 \section{Überblick}

177

178 Wir werden unser Projekt nach dem \emph{Rational Unified Process}$^{\ddagger}$ (kurz RUP) entwickeln.

179

180 Der RUP ist ein dynamischer und iterativer Entwicklungsprozess, der das Projekt in zwei Dimensionen (zeitlich und inhaltlich) betrachtet.

181

182 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.

183

184 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.

185

186

187 \section{Der RUP auf einen Blick}

188

189 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.

190

191 \begin{figure}[htb]

192 \centering

193 \includegraphics[width=9cm]{pictures/png/RationalUnifiedProcess.png}

194 \caption{Übersicht über einen Zyklus im RUP$^{\ddagger}$ }

195 \label{fig:rationalunifiedprocess}

196 \end{figure}

197

198

199

200

201

202

203

204

205 %%%%%%%%%%%%%%

206 \chapter{Zeitliche Dimension}

207

208 \section{Anpassungen}

209

210 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})

211

212 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.

213

214 Iterationen innerhalb der Zyklen werden wir, auf Grund der kurzen Zyklen, komplett außen vor lassen.

215

216

217

218 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.

219

220 %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.

221

222 %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.

223

224

225

226

227

228 \section{Konkrete Projektplanung}

229

230 Die konkrete Planung der einzelnen Zyklen und ihrer Meilensteine finden sich im \emph{Software Development Plan}.

231

232

233

234

235

236

237

238 %%%%%%%%%%%%%%%%%%%%

239 \chapter{Inhaltliche Dimension}

240

241 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.

242

243 Hier beschreiben wir, wie wir die vorgegebenen Workflows des RUP anpassen.

244

245

246

247 \section{Business Modeling}

248

249 \subsection*{Zweck}

250 Gemeinsames Verständniss zwischen Entwicklern und Anwendern schaffen.

251

252 \subsection*{Anpassungen}

253 Wir erstellen keinen Business Use Case, weil das Seminarsystem ein gestelltes abgeschlossenes Szenario ist und nicht in bestehende Geschäftsabläufe eingebunden werden muss.

254

255 \subsection*{Artefakte}

256 \begin{tabular}{p{4cm}p{10cm}}

257 \rowcolor{gray07} Artefakt & \textbf{Glossary} \\

258 \rowcolor{white} Rolle & Fachliches Team, Kunde \\

259 \rowcolor{gray09} Aktivität & erstellen gemeinsam \\

260 \rowcolor{white} Wann & Inception, Ergänzungen jeder Zeit \\

261 \rowcolor{gray09} Review & Fachliches Team und Kunde durch gemeinsames Erstellen \\

262 \end{tabular}

263

264

265

266 \section{Requirements}

267

268 \subsection*{Zweck}

269 Ermitteln, was das System leisten soll. Die funktionalen Anforderungen erfassen.

270

271 \subsection*{Anpassungen}

272 Keine besonderen.

273

274 \subsection*{Artefakte}

275 \begin{tabular}{p{4cm}p{10cm}}

276 \rowcolor{gray07} Artefakt & \textbf{Vision} \\

277 \rowcolor{white} Rolle & Fachliches Team, Kunde \\

278 \rowcolor{gray09} Aktivität & erarbeiten im Gespräch \\

279 \rowcolor{white} Wann & Inception \\

280 \rowcolor{gray09} Review & Fachliches Team und Kunde durch gemeinsames Erarbeiten \\

281 & \\

282 \rowcolor{gray07} Artefakt & \textbf{Use Cases} \\

283 \rowcolor{white} Rolle & Fachliches Team, Kunde \\

284 \rowcolor{gray09} Aktivität & erarbeiten im Gespräch \\

285 \rowcolor{white} Wann & Inception und Elaboration \\

286 \rowcolor{gray09} Review & Fachliches Team und Kunde durch gemeinsames Erarbeiten \\

287 \end{tabular}

288

289

290

291 \section{Analysis \& Design}

292

293 \subsection*{Zweck}

294 Aufbau und Technologie des Systems festlegen. Festlegung wie wird das System realisiert wird.

295

296 \subsection*{Anpassungen}

297 Die Technologie und Rahmenbedingungen der Umsetzung sind durch das Projekt vorgegeben und somit fix.

298

299 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.

300

301 \subsection*{Artefakte}

302 \begin{tabular}{p{4cm}p{10cm}}

303 \rowcolor{gray07} Artefakt & \textbf{Software Architecture Document} \\

304 \rowcolor{white} Rolle & Team Technische Architektur \\

305 \rowcolor{gray09} Aktivität & erstellt \\

306 \rowcolor{white} Wann & Elaboration \\

307 \rowcolor{gray09} Review & Entwickler nach Änderungen \\

308 \end{tabular}

309

310

311

312

313 \section{Implementation}

314

315 \subsection*{Zweck}

316 Systemteile entwickeln und zusammenfügen. Komponententests.

317

318 \subsection*{Anpassungen}

319 Momentan besteht dieser Workflow in erster Line aus der Entwicklung von Prototypen jeder Art (Modelle, Templates, etc) um die Technologie zu erforschen.

320

321 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.

322

323 \subsection*{Artefakte}

324 Keine definiert.

325 % \begin{tabular}{p{4cm}p{10cm}}

326 % \rowcolor{gray07} Artefakt & \textbf{Glossary} \\

327 % \rowcolor{white} Rolle & Fachliches Team, Kunde \\

328 % \rowcolor{gray09} Aktivität & erstellen gemeinsam \\

329 % \rowcolor{white} Wann & Inception (ergänzend jeder Zeit) \\

330 % \rowcolor{gray09} Review & \\

331 % \end{tabular}

332

333

334

335 \section{Testing}

336

337 \subsection*{Zweck}

338 Test des Zusammenspiels der Komponenten. Funktionsweise des Systems gegen die Anforderungen prüfen.

339

340 \subsection*{Anpassungen}

341 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.

342

343 Alle Dokumente müssen von mindestens einer weiteren Person begutachtet werden. Die genauen Vorgaben stehen bei den Artefaktbeschreibungen in diesem Kapitel.

344

345 \subsection*{Artefakte}

346 Keine definiert.

347 % \begin{tabular}{p{4cm}p{10cm}}

348 % \rowcolor{gray07} Artefakt & \textbf{Dokument Reviews} \\

349 % \rowcolor{white} Rolle & Beliebiger Mitarbeiter \\

350 % \rowcolor{gray09} Aktivität & prüfen gemeinsam das Dokument \\

351 % \rowcolor{white} Wann & nachdem Dokument erstellt/geändert wurde \\

352 % \rowcolor{gray09} Review & \\

353 % \end{tabular}

354

355

356

357

358 \section{Deployment}

359

360 \subsection*{Zweck}

361 Auslieferung des Systems an den Kunden und Inbetriebnahme.

362

363 \subsection*{Anpassungen}

364 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.

365

366 \subsection*{Artefakte}

367 \begin{tabular}{p{4cm}p{10cm}}

368 \rowcolor{gray07} Artefakt & \textbf{Release Notes} \\

369 \rowcolor{white} Rolle & Projektleiter, Entwickler \\

370 \rowcolor{gray09} Aktivität & sollen erstellen \\

371 \rowcolor{white} Wann & Transition \\

372 \rowcolor{gray09} Review & anderer Entwickler vor Auslieferung \\

373 \end{tabular}

374

375

376

377

378

379 \section{Configuration \& Changemanagement}

380

381 \subsection*{Zweck}

382 Verwaltung der zum Projekt gehörenden Daten. Versionierung der Daten. Change-Request-Management.

383

384 \subsection*{Anpassungen}

385 Alle Daten müssen im zentralen Project Repository abgelegt werden.

386

387 Jeder Mitarbeiter darf an jeder Stelle des Projekts Änderungen durchführen.

388

389 Change-Requests werden nach dem vertraglich festgelegten Verfahren bearbeitet.

390

391 \subsection*{Artefakte}

392 Keine definiert.

393

394

395

396

397 \section{Projectmanagement}

398

399 \subsection*{Zweck}

400 Planung des Projekts. Zwischen konkurrierenden Zielen vermitteln. Auf Risiken reagieren.

401

402 \subsection*{Anpassungen}

403 Keine besonderen.

404

405 \subsection*{Artefakte}

406 \begin{tabular}{p{4cm}p{10cm}}

407 \rowcolor{gray07} Artefakt & \textbf{Software Development Plan} \\

408 \rowcolor{white} Rolle & Projektleiter \\

409 \rowcolor{gray09} Aktivität & erstellt \\

410 \rowcolor{white} Wann & Inception \\

411 \rowcolor{gray09} Review & Entwickler und Risikomanager nach Änderungen \\

412 & \\

413 \rowcolor{gray07} Artefakt & \textbf{Risk Management Plan} \\

414 \rowcolor{white} Rolle & Riskmanager \\

415 \rowcolor{gray09} Aktivität & erstellt \\

416 \rowcolor{white} Wann & Alle Phasen \\

417 \rowcolor{gray09} Review & Komplettes Team in Inception Phase \\

418 \end{tabular}

419

420

421

422 \section{Environment}

423

424 \subsection*{Zweck}

425 Rahmenbedingungen schaffen. Bereitstellung von Hardware, Software und Know-How.

426

427 \subsection*{Anpassungen}

428 Die Hochschule Ulm stellt uns ein Project Repository zur Verfügung.

429

430 Die offiziellen Kommunikationwege im Team sind das wöchentliche Teammeeting und die Projekt-Mailingliste.

431

432 \subsection*{Artefakte}

433 \begin{tabular}{p{4cm}p{10cm}}

434 \rowcolor{gray07} Artefakt & \textbf{Development Case} \\

435 \rowcolor{white} Rolle & Projektleiter \\

436 \rowcolor{gray09} Aktivität & erstellt \\

437 \rowcolor{white} Wann & Inception \\

438 \rowcolor{gray09} Review & Komplettes Team in Inception Phase \\

439 & \\

440 \rowcolor{gray07} Artefakt & \textbf{Tutorials} \\

441 \rowcolor{white} Rolle & Toolspezialist \\

442 \rowcolor{gray09} Aktivität & kann erstellen \\

443 \rowcolor{white} Wann & Alle Phasen \\

444 \rowcolor{gray09} Review & eine Person für die das Tutorial geschrieben wurde \\

445 \end{tabular}

446

447

448

449

450

451

452

453

454

455

456

457

458 \appendix

459 %\chapter{Glossar}

460 \chapter{Quellen}

461 \begin{itemize}

462 \item Dokumentation zum \emph{Rational Unified Process} \\ (\texttt{http://www-306.ibm.com/software/awdtools/rup/})

463 \item Skript von Herrn Baer zur Vorlesung \emph{Softwaretechnik 1} an der Hochschule Ulm

464 \item http://wikipedia.org

465 \item \emph{Rational Unified Process - Best Practices for Software Development Teams}

466 \end{itemize}

467

468 $\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.

469

470

471

472 \end{document}

473

474

475

476

477 %%%%%%%% HowTo %%%%%%%%%%

478

479 % picture block

480 \begin{figure}[h]

481  \includegraphics[scale=0.65]{pictures/png/logistiksicht_v6}

482  \caption{Logistiksicht für SAP}

483  \label{fig:logistiksicht}

484 \end{figure}

485

486 % picture inline

487 \begin{wrapfigure}[11]{r}[0pt]{6.4cm}

488  \centering %OPTIONAL

489  \includegraphics[scale=0.7]{pictures/png/werkdresden}

490  \caption{OptiBoard Werk Dresden}

491 \end{wrapfigure}

492

493 % tabellen

494 \begin{table}[htb]

495 \centering

496 \begin{tabular}{p{4cm}|p{3cm}|p{3.3cm}}

497  \rowcolor{gray07} \textbf{Teil} & \textbf{Menge} & \textbf{Einheit}\\

498  \hline

499  \rowcolor{white}  LED-Block          & 105 & Stück\\

500  \rowcolor{gray09} Feder              & 105 & Stück\\

501  \rowcolor{white}  Platine            & 1   & Stück\\

502  \rowcolor{gray09} Chip               & 1   & Stück\\

503  \rowcolor{white}  Kabel              & 1   & Stück\\

504  \rowcolor{gray09} Kunststoffgranulat & 350 & Gramm\\

505 \end{tabular}

506 \caption{Mengenübersichtstückliste OptiBoard Pro}

507 \label{tbl:mengenPro}

508 \end{table}