tipps.tex 43.3 KB
Newer Older
1
\documentclass[parskip=full]{scrartcl}
denis.lohner's avatar
denis.lohner committed
2
3
4
5
6
7
8

\usepackage[utf8]{inputenc} % utf8 file encoding
\usepackage[T1]{fontenc} % powerful pdf output encoding

\usepackage[color]{PPaushang}
\usepackage{helvet}
\usepackage{csquotes}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
9
10
11
12
13
14
15
16
17
\usepackage{hyperref}
\hypersetup{
  pdftitle={PSE: Tipps},
  pdfcreator={KIT, IPD Snelting},
  debug=true,
  bookmarks=true,
  bookmarksopen=true,
  bookmarksopenlevel=2,
}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
18
19
20
% Use \cref instead of \autoref !
\usepackage[nameinlink]{cleveref}
\Crefname{figure}{Abbildung}{Abbildungen}
denis.lohner's avatar
denis.lohner committed
21
22

\usepackage[german]{babel}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
23
\usepackage{pgfplotstable}
denis.lohner's avatar
denis.lohner committed
24
25
26
27
28
29
30
31

\title{Praxis der Software-Entwicklung \\
  \Large{Tipps und Tricks}}
\author{%
  \normalsize{Lehrstuhl Programmierparadigmen}\\
  \normalsize{Karlsruher Institut f\"ur Technologie (KIT)}}
\date{\normalsize{Stand: \today}}

32
33
34
35
\let\Sectionmark\sectionmark
\def\sectionmark#1{\def\Sectionname{#1}\Sectionmark{#1}}
\newcommand{\artefakt}[1]{\textbf{Artefakt der Phase \Sectionname :} #1}

denis.lohner's avatar
denis.lohner committed
36
37
38
\begin{document}
\maketitle

Andreas Zwinkau's avatar
typo    
Andreas Zwinkau committed
39
Manche Tipps und Tricks wiederholen wir häufig.
denis.lohner's avatar
denis.lohner committed
40
41
42
Dies ist eine Sammlung, um nichts zu vergessen
und weniger Fehler beim Erklären zu machen.

Andreas Zwinkau's avatar
Andreas Zwinkau committed
43
\section{Tools für alle Phasen}
44
45
46
47
48
49

\dictum[Francis Glassborow]{
Good programmers use their brains,
but good guidelines save us having to think out every case.
}

denis.lohner's avatar
denis.lohner committed
50
51
52
53
54
55
56
57
58
59
60
61
62
63
\subsection{Versionskontrollsystem}

Wir empfehlen Subversion oder Git,
weil wir als Betreuer damit Erfahrung haben.

Git-Tipps:

\begin{itemize}
  \item \href{http://try.github.io}{Interactive Git Tutorial}: für Anfänger.
  \item \href{http://gitref.org/}{Git Reference}: relativ kompakte Anleitung.
  \item \href{http://git-scm.com/}{Offizielle Git Projektseite}
  \item \href{http://eagain.net/articles/git-for-computer-scientists/}
    {Git for Computer Scientists}:
    \enquote{Quick introduction to git internals for people who are not scared by words like Directed Acyclic Graph.}
64
  \item Vermeide den Parameter \texttt{-{}-force} bzw. \texttt{-f}.
denis.lohner's avatar
denis.lohner committed
65
    Häufig schiebst du damit Probleme nur deinen Teamkollegen zu.
66
67
  \item Benutze den Parameter \texttt{-{}-rebase} bei einem \texttt{git pull},
    damit vermeidest du, dass alles voller merge-commits ist.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
68
69
    Alternativ kann man das (ab git 1.7.9) auch als globalen Standard einstellen
    mit \texttt{git config --global pull.rebase true}.
denis.lohner's avatar
denis.lohner committed
70
71
\end{itemize}

72
Genereller Tip:
denis.lohner's avatar
denis.lohner committed
73
Keine generierten Dateien einchecken.
74
75
76
77
78
Zum Beispiel erzeugt \TeX{} üblicherweise einige Dateien
(Endungen wie log, aux, out oder blg)
beim Erstellen einer pdf.
Diese sollten nicht im Versionskontrollsystem landen.
Ebensowenig die erzeugte pdf.
denis.lohner's avatar
denis.lohner committed
79
Bei Git kann man hierzu z.B. die Datei \texttt{.gitignore} erstellen/verwenden.
80

Andreas Zwinkau's avatar
Andreas Zwinkau committed
81
82
83
84
Man kann sich optional auch
Issue Tracker, Code Review, und ähnliche Tools gleich dazuholen,
beispielweise bei Github, Bitbucket, Gitlab oder
\href{https://git.scc.kit.edu}{git.scc.kit.edu}.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
85
86

\subsection{Dokumentenformat: \LaTeX}
denis.lohner's avatar
denis.lohner committed
87
88
89
90
91
92

Wir empfehlen \LaTeX,
weil es sich gut mit Versionskontrollsystemen vereinbaren lässt
und man hier schon für die Bachelorarbeit üben kann.
Office o.ä. ist aber auch möglich.

93
Statt den normalen Dokumentklassen
94
empfehlen wir vor allem für deutsche Dokumente
95
96
97
die KOMA-Scriptklassen zu verwenden.
Diese sind flexibler und besser für deutsche Typografie ausgelegt.
Das bedeutet deutsche Dokumente starten
98
mit der folgenden Deklaration:
99
100
101
102
103
104

\begin{verbatim}
\documentclass[parskip=full]{scrartcl}
\end{verbatim}

Das \texttt{parskip=full} sorgt
105
für einen Absatzabstand von einer Zeile
106
und die erste Zeile eines Absatzes wird nicht eingerückt.
107
Das ist im Deutschen das übliche Format,
108
109
aber nicht im Englischen.

110
Weitere für (deutsche) \LaTeX-Dokumente fast immer gute Einstellungen:
Andreas Zwinkau's avatar
Andreas Zwinkau committed
111
112
113
114

\begin{verbatim}
\usepackage[utf8]{inputenc} % use utf8 file encoding for TeX sources
\usepackage[T1]{fontenc}    % avoid garbled Unicode text in pdf
115
\usepackage[german]{babel}  % german hyphenation, quotes, etc
Andreas Zwinkau's avatar
Andreas Zwinkau committed
116
\usepackage{hyperref}       % detailed hyperlink/pdf configuration
117
\hypersetup{                % `texdoc hyperref` for options
Andreas Zwinkau's avatar
Andreas Zwinkau committed
118
  pdftitle={PSE: Tipps},
119
  bookmarks=true,
Andreas Zwinkau's avatar
Andreas Zwinkau committed
120
}
121
\usepackage{csquotes}       % provides \enquote{} macro for "quotes"
Andreas Zwinkau's avatar
Andreas Zwinkau committed
122
123
\end{verbatim}

124
125
126
127
Die Dokumentation der Pakete ist häufig lesenswert,
insbesondere bei den Paketen  hyperref und scrguide (KOMA-Script).
Wer TeXLive per Kommandozeile benutzt,
kann einfach \texttt{texdoc scrguide} aufrufen.
128

Andreas Zwinkau's avatar
Andreas Zwinkau committed
129
130
131
132
133
Zum Erzeugen eines PDFs aus den \LaTeX-Sourcen
empfehlen wir einen Wrapper wie \texttt{latexmk} zu verwenden.
Dieser übernimmt beispielsweise das mehrfache Ausführen von \texttt{pdflatex},
wo es notwendig ist.

Andreas Zwinkau's avatar
Andreas Zwinkau committed
134
135
136
137
\section{Technisches Schreiben}
\dictum[Donald Knuth]{Anything that helps communication is good.
Anything that hurts is bad.
And that’s all I have to say.}
138

Andreas Zwinkau's avatar
Andreas Zwinkau committed
139
140
141
142
Technisches Schreiben ist wichtig für alle Arten von technischen und wissenschaftlichen Dokumenten,
also auch API-Dokumentation, Bachelorarbeit, Pflichtenheft und Testbericht.
Es bedeutet vor allem eine präzise Ausdrucksweise
und widerspricht dabei einigen Regeln,
143
die man im Deutsch\-unterricht gelernt hat.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
144
Ein paar praktische Tipps:
denis.lohner's avatar
denis.lohner committed
145
146

\begin{itemize}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
147
148
149
  \item Vermeide Adjektive.
    Oft (nicht immer) sind sie unnötig oder
    ein schlechter Ersatz für einen ungenauen Begriff.
150
  \item Nebensatzkonstruktionen vermeiden; Hauptsätze verwenden!
Andreas Zwinkau's avatar
Andreas Zwinkau committed
151
  \item Definiere Begriffe klar und verwende keine Synonyme.
152
153
    Synonyme lassen offen, ob genau das Gleiche gemeint ist
    oder nur etwas Ähnliches.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
  \item Abkürzungen sollten bei der ersten Verwendung (EV)
    ausgeschrieben werden. Nach der EV reicht dann die Kurzform.
  \item Versuche konkrete Zahlen und Namen anzugeben.
    Vermeide ungenaue Ausflüchte wie:
    meistens, viele, oft, möglichst, üblich, jemand, manche.
  \item Viele kurze Sätze sind einfacher zu verstehen als wenige lange Sätze.
  \item Beispiele machen das Endprodukt greifbarer.
  \item Illustrationen minimalistisch halten (z.B. IKEA Bauanleitung).
    Eine Information, ein Bild.
    Lieber mehrere ähnliche Bilder als ein komplexes Bild.
  \item Vermeide Wiederholung, stattdessen Referenzen benutzen.
    Wiederholungen haben oft subtile Unterschiede,
    was zu Unklarheit und Verwirrung führt.
    Bei Änderungen wird oft vergessen,
    dass Wiederholungen auch angepasst werden müssen.
  \item Versionskontrolle ergibt auch für technische Texte Sinn
    und nicht nur für Code.
171
172
173
  \item Benutze nicht die automatische Umbruch-Funktion des Editors.
    Setze stattdessen im Source\-code einen Zeilenumbruch nach jedem Satz.
    Damit werden die Diffs des Versionskontroll\-systems lesbarer.
denis.lohner's avatar
denis.lohner committed
174
175
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
176

Andreas Zwinkau's avatar
Andreas Zwinkau committed
177
178
\section{Kolloquium}

179
180
181
182
183
\dictum[Lilly Walters]{
The success of your presentation will be judged not by the knowledge you send
but by what the listener receives.
}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
184
185
186
187
188
189
190
191
192
193
Ein paar Hinweise für die Kollquien bzw. für Präsentation allgemein.

\begin{itemize}
  \item Alleine Üben!
    Daheim vor dem Spiegel üben.
    Einen Vortrag nur alleine, aber im Stehen und laut sprechend, vorzutragen
    ist meist schon lehrreich im Vergleich zu stillem Folienbasteln.
  \item Vor dem eigenen Team üben und konstruktiv gegenseitig kritisieren.
    Oft sehen die Kollegen Ticks, die man selbst nicht wahrnimmt.
    Beispielsweise häufige Ähs, häufiges Wegschauen vom Publikum,
194
195
    verschränkte Arme, Nuscheln, nervöses Herumlaufen, etc.
  \item Laut und deutlich sprechen.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
196
197
198
199
200
201
202
203
204
205
  \item 10 Minuten sind nicht lange,
    aber man kann viel Information darin unterbringen.
  \item Prof. Snelting achtet sehr auf die Zeit.
    10 Minuten sind nicht 12 Minuten und auch nicht 7 Minuten.
  \item Daumenregel: 2 Minuten pro Folie, also 5 Folien.
    Ein Folie umfasst dabei möglicherweise Animationen / Overlays.
  \item Die Folien dem Betreuer zur Durchsicht geben.
  \item Auf die interessanten Punkte konzentrieren
    und sich nicht in den Details verlieren.
    Trotzdem sollte natürlich der Inhalt möglichst vollständig sein.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
206
207
  \item Keine Agenda-/Inhaltsverzeichnis-/Gliederungsfolie.
    Ist nicht mehr zeitgemäß und langweilt nur.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
208
209
210
211
  \item Ihr seid nicht gezwungen den KIT Folienstil zu verwenden.
    Es ist sogar eher falsch,
    schließlich repräsentiert ihr nicht das KIT,
    sondern nur euch als Team von Studenten.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
212
213
\end{itemize}

214
\newpage
denis.lohner's avatar
denis.lohner committed
215
216
\section{Organisatorisches}

217
218
219
220
\dictum[Bjarne Stroustrup]{
Design and programming are human activities; forget that and all is lost.
}

denis.lohner's avatar
denis.lohner committed
221
\begin{itemize}
andreas.fried's avatar
andreas.fried committed
222
223
224
225
226
\item Meldet euch so früh wie möglich im \href{https://campus.studium.kit.edu}{Studierendenportal} für PSE und TSE an:
  \begin{itemize}
  \item QISPOS: Prüfungsnummern 529 und 455
  \item Campus: Prüfungsnummern 7500076 und 7500075
  \end{itemize}
denis.lohner's avatar
denis.lohner committed
227
228
229
  \item Mails an den Betreuer sollten vom Phasenverantwortlichen kommen.
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
230
\newpage
denis.lohner's avatar
denis.lohner committed
231
232
\section{Pflichtenheft}

233
234
235
236
\dictum[Dwight Eisenhower]{
I have always found that plans are useless, but planning is indispensable.
}

237
238
\artefakt{PDF Dokument}

denis.lohner's avatar
denis.lohner committed
239
240
241
242
243
244
245
246
247
248
Das fertige (Software-)Produkt wird am Ende der gesamten Entwicklung am Pflichtenheft gemessen (Stichwort Endabnahme).
Stellt der Auftraggeber zu große Unterschiede fest, wird er nicht bezahlen.
D.h.\ schon das Pflichtenheft muss es dem Leser ermöglichen, eine exakte Vorstellung des fertigen Produkts zu bekommen.
Insbesondere müssen \emph{alle} Produktfunktionen und -daten genannt und hinreichend genau beschrieben werden,
(G)UI-Entwürfe sind Pflicht, Bedienelemente müssen erklärt sein (z.B. Menüführung), und der Leser muss durch das Pflichtenheft
wissen, wie er das fertige Produkt verwenden kann (Stichwort Testfallszenarien).

\begin{description}
  \item[Musskriterien]
    Mindestanforderungen, gehen aus Aufgabenstellung hervor.
249
    Diese \emph{müssen} im fertigen Produkt implementiert sein, und reichen i.d.R.\ zum Bestehen von PSE.
denis.lohner's avatar
denis.lohner committed
250
251
252
    Möglichst klein halten.
  \item[Wunschkriterien]
    Von den Gruppen selbst definierte, zusätzliche Funktionalität.
253
254
    Kein einzelnes der Wunschkriterien muss am Ende implementiert sein.
    Wunschkriterien können im Zweifelsfall sehr optimistisch ausgelegt werden, da vorausschauende Projektplanung schwierig ist und es nicht schlimm ist, wenn am Ende nicht alle Wunschkriterien implementiert sind.
denis.lohner's avatar
denis.lohner committed
255
256
257
258
  \item[Abgrenzungskriterien]
    Was unterstützt unser Produkt explizit \emph{nicht}.
\end{description}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
Und noch einige generelle Anforderungen an das Pflichtenheft.

\begin{itemize}
  \item Wird jedes Kriterium durch mindestens einen Testfall geprüft?
    Zumindest intern (möglicherweise auch direkt im Pflichtenheft selbst)
    sollte für jedes Kriterium eine Liste an Testreferenzen
    und für jeden Test eine Liste an Kriteriumsreferenzen feststehen.
  \item Man stelle sich vor, das Pflichtenheft wird
    für Entwurf und Implementierung
    an ein anderes Team übergeben
    und das Ergebnis kommt zur Qualitätssicherung zurück.
    Wie zuversichtlich seid ihr,
    dass das Ergebnis euren Vorstellungen entspricht?
    Abweichungen von euren Vorstellung dürfen nur kritisiert werden,
    wenn dadurch Testfälle fehlschlagen.
274
  \item Das Pflichtenheft sollte auch von nicht technisch versierten Menschen
Andreas Zwinkau's avatar
Andreas Zwinkau committed
275
    zu großen Teilen verstanden werden können.
276
    Am besten jemand fachfremdem zum Lesen geben
Andreas Zwinkau's avatar
Andreas Zwinkau committed
277
    und danach Verständnisfragen stellen.
278
  \item Das Pflichtenheft ist das entscheidendste Dokument
Andreas Zwinkau's avatar
Andreas Zwinkau committed
279
280
    zwischen Kunde und Entwickler am Ende eines Projekts.
    Es darf \textbf{keinen Spielraum für Interpretationen} offen lassen.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
281
  \item Erfahrungsgemäßer Umfang: ca. 40 Seiten
Andreas Zwinkau's avatar
Andreas Zwinkau committed
282
283
284
285
\end{itemize}

\subsection{Struktur}

denis.lohner's avatar
denis.lohner committed
286
287
Beschreibung und Beispiele von Pflichtenheften
finden sich in der Vorlesung Softwaretechnik 1.
288
289
290
291
292

Als \enquote{erweitertes Lastenheft} enthält es zusätzlich: Produktumgebung, Testfälle sowie Entwürfe der Benutzerschnittstelle.
Objektmodell und dynamische Modelle sind i.d.R. nicht verpflichtender Teil des PSE-Pflichtenhefts (detaillierte Klassen- und Sequenzdiagramme sind Teil des \emph{Entwurfs}).

Die Struktur aus SWT1 muss nicht exakt übernommen werden.
denis.lohner's avatar
denis.lohner committed
293
294
295
Sinnvolle Änderungen könnten sein:

\begin{itemize}
296
297
  \item Reihenfolge der Kapitel verändern,
    so dass es flüssiger von vorne nach hinten gelesen werden kann.
298
299
  \item Kapitel, die im Kontext des eigenen Projektes keinen Sinn machen oder
    übermäßig redundant werden würden, können potenziell weggelassen werden.
300
301
302
    Eventuell kann es auch sinnvoll sein, Kapitel zusammenzufassen.
  \item Funktionale Anforderungen von Muss- und Wunschkriterien mischen oder nach Programmbereich aufteilen
    und stattdessen durch Layout, Stil, Marker, Icons entsprechend kennzeichnen.
denis.lohner's avatar
denis.lohner committed
303
304
305
306
  \item
    Ein Pflichtenheft darf mehr enthalten als nur einen Katalog an Kriterien.
    Das Endprodukt soll komplett erklärt werden,
    also könnte Hintergrundwissen aus anderen Quellen hilfreich sein.
307
    Auch Bilder und Grafiken sind erlaubt.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
308
309
310
  \item Testfallszenarien als Liste formatieren,
    so dass es als Checkliste für den Tester fungiert.
    Ein Punkte sollte dabei immer genau eine Aktion des Testers
311
    und die erwartete Reaktion des Programms sein.
312
313
314
315
    Beispiel:
    \paragraph{T1337} Einloggen
    \begin{enumerate}
      \item \begin{description}
316
        \item[Stand] Offenes Browserfenster.
317
318
        \item[Aktion] Benutzer gibt \enquote{facebook.com} in die Kopfzeile
          ein und drückt Enter.
319
        \item[Reaktion] Der Browser wechselt zur Facebook-Frontseite.
320
321
      \end{description}
      \item \begin{description}
322
        \item[Stand] Facebook-Frontseite ist geladen.
323
324
325
326
327
          Loginmöglichkeit oben rechts.
        \item[Aktion] Benutzer gibt \enquote{zuckerberg@facebook.com} als Email
          und \enquote{admin} als Passwort ein.
          Dann klickt der Benutzer auf den \enquote{Log In} Knopf.
        \item[Reaktion] Erfolgreich eingeloggt.
328
          Der Browser wird zur Newsfeedseite des Benutzers umgeleitet.
329
330
      \end{description}
    \end{enumerate}
331
    Diese Testfallszenarien eignen sich als Startpunkt für den Entwurf, und werden bei der internen Abnahme benutzt um das Produkt zu validieren.
denis.lohner's avatar
denis.lohner committed
332
333
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
334
\subsection{GUI Entwürfe}
denis.lohner's avatar
denis.lohner committed
335
336

\begin{itemize}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
337
338
339
340
  \item \href{http://www.inkscape.org/de/}{Inkscape} ist ein freies Vektorzeichenprogramm
  \item \href{http://pencil.evolus.vn/}{Pencil} ist ein Open-Source GUI Prototyping Tool (enthält Formen für Android, iOS, Web, GTK, Windows XP, Sketch, ...)
  \item Die \href{http://developer.android.com/tools/index.html}{Android Developer Tools} enthalten einen grafischen UI Builder
  \item Papier und Tusche geht natürlich auch
denis.lohner's avatar
denis.lohner committed
341
342
\end{itemize}

343
344
\subsection{Inhalt der Präsentation}

345
346
347
Die Präsentation muss nicht das komplette Pflichtenheft abbilden oder gar ersetzen.
Konzentriert euch auf die Aspekte, die technisch interessant sind oder euer Produkt von den anderen abheben.

348
349
\begin{itemize}
  \item Kurze Einführung zur Aufgabenstellung
350
  \item Überblick über \emph{die wichtigsten} Features
351
  \item Grundsätzliche selbst gesetzte Rahmenbedingungen
352
353
354
  \item Ein Testfallszenario als anschauliches durchgehenden Beispiel
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
355
\newpage
denis.lohner's avatar
denis.lohner committed
356
\section{Entwurf}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
357

358
\dictum[Bob Martin]{
Andreas Zwinkau's avatar
Andreas Zwinkau committed
359
Design is the art of separation, grouping, abstraction, and hiding. The fulcrum of design decisions is change. Separate those things that change for different reasons. Group together those things that change for the same reason.
360
}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
361

362
\artefakt{PDF Dokument mit UML-Diagrammen,
363
  Klassenbeschreibungen, Erläuterungen, Designentscheidungen; evtl. großformatiges Klassendiagramm}
364

Andreas Zwinkau's avatar
Andreas Zwinkau committed
365
366
\subsection{Inhalt}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
367
\begin{itemize}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
368
369
370
371
372
373
  \item Einleitung mit grobem Überblick.
    Dieser Abschnitt soll an das Pflichtenheft anschließen
    und die Aufteilung in die Pakete erklären.
  \item Detaillierte Beschreibung \emph{aller} Klassen.
    Das beinhaltet (JavaDoc) Beschreibungen zu allen Methoden,
    Konstruktoren, Packages und Klassen.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
374
375
    Was hier \emph{nicht} reingehört sind private Felder und Methoden.
    Das sind Implementierungsdetails.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
376
377
378
379
  \item Beschreibung von charakteristischen Abläufen
    anhand von Sequenzdiagrammen.
    Beispielsweise bieten sich Testszenarien aus dem Pflichtenheft hier an.
    Wir empfehlen Sequenzdiagramme möglichst früh zu erstellen,
380
381
382
    denn dabei werden die Schnittstellen zwischen Packages und Klassen klar.
  \item Mit Blick auf den Implementierungsplan:
    Aufteilung in Klassen/Pakete,
Andreas Zwinkau's avatar
Andreas Zwinkau committed
383
    die unabhängig voneinander implementiert und getestet werden können.
384
  \item Änderungen zum Pflichtenheft, z.B. gekürzte Wunschkriterien.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
385
386
387
  \item Vollständiges großformatiges Klassendiagramm im Anhang.
    Ausschnitte/Teile können bereits vorher verwendet werden,
    um Teilkomponenten zu beschreiben.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
388
389
390
    Assoziationen zwischen Klassen dabei bitte
    mit entsprechenden Pfeilen darstellen,
    statt nur durch Feldtypen.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
391
    Ein kleines Beispiel ist in \Cref{fig:example_class_diagram} gezeigt.
392
  \item Identifikation von Entwurfsmustern
Andreas Zwinkau's avatar
Andreas Zwinkau committed
393
    um Struktur gröber zu beschreiben.
394
395
  \item Erfahrungsgemäßer Umfang:
    \begin{itemize}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
396
397
      \item 100 Seiten, primär Klassenbeschreibungen
      \item 40--80 Klassen ohne Interfaces
398
399
400
    \end{itemize}
  \item Möglicherweise weitere UML-Diagrammarten?
  \item Formale Spezifikation von Kernkomponenten?
Andreas Zwinkau's avatar
Andreas Zwinkau committed
401
402
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
403
404
405
406
407
408
409
410
411
412
\begin{figure}[hbp]
\includegraphics[width=\textwidth]{example_class_diagram.png}
\caption{\label{fig:example_class_diagram}
Klassendiagrammbeispiel:
Grobe Paketstruktur farblich hervorgehoben.
Ausgewählte Verwendungen als Assoziation eingetragen,
um auch Beziehungen durch Parameter oder lokale Variablen zu verdeutlichen.
}
\end{figure}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
Unserer Erfahrung nach ist die Entwurfsphase die schwierigste,
da Studenten hier so gut wie keine Erfahrung haben
(im Gegensatz zur Implementierungsphase).
Deswegen hier ein paar konkrete Schritte,
die helfen sollen einen Anfang zu finden.

\begin{enumerate}
  \item Sucht alle relevanten Substantive im Pflichtenheft heraus.
    Viele davon lassen sich direkt als Klassen abbilden.
    Zum Beispiel: Button, Level, Spielfigur, Bild, etc.
  \item Was kann man mit diesen Objekten tun?
    So erhält man die Methoden.
    Beispielsweise kann man ein Bild drehen, anzeigen und umfärben.
  \item In welcher Beziehung stehen die Objekte miteinander?
    So erhält man die Pfeile im UML Diagramm.
    Zum Beispiel weiß eine Spielfigur vielleicht in welchem Level sie ist.
429
430
431
  \item Spielt die Testfallszenarien durch.
    So finden sich noch fehlende Methoden und Assoziationen.
    Außerdem könnt ihr dabei schon die ersten Sequenzdiagramme sammeln.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
  \item Organisiert die Klassen sinnvoll in Gruppen.
    So erhält man die Paketstruktur.
    Beispielsweise Model-View-Controller könnte hier sichtbar werden.
  \item Diese ersten Schritte kann man erstmal zügig in einer Sitzung
    mit dem ganzen Team machen.
    Anschließend kann man die Pakete oder Klassen einzelnen Personen zuordnen,
    die dann eigenverantwortlich die Details ausarbeiten.
  \item Nun ist die erste Woche rum.
    Man hat einiges an Material produziert und kann es dem Betreuer zeigen.
  \item Jetzt ist es auch an der Zeit mit dem eigentlichen Dokument zu beginnen.
    Inbesondere sollten technische Fragen geklärt sein.
    Womit erstellen wir unsere UML Diagramme?
    Automatisches Erzeugen von Java-Code mit JavaDoc-Kommentaren
    und daraus LaTeX und PDF erzeugen?
    Das alles sollte man in der zweiten Woche zum Laufen bringen.
  \item Da man nun bereits ein Dokument hat,
    kann man grundlegende Entwurfsentscheidung sofort niederschreiben.
    Sammelt erstmal alles in dem Dokument.
    Ordnen und polieren kann man das später in der Phase.
  \item Ein weiterer großer Brocken ist die Anbindung an die Platform,
    die man benutzt. Beispielsweise Qt, Android oder ein anderes Framework.
    Hier ist es oft ratsam ein paar minimale Beispielanwendungen zu bauen,
    um ein Gefühl für die API zu bekommen.
  \item Nach zwei Wochen sollten die meisten Klassen entworfen sein.
    Allerdings hat üblicherweise jedes Teammitglied seinen Bereich für
    sich bearbeitet.
    Nun wird es Zeit sich mit der Integration zu beschäftigen.
459
460
    Nehmt euch noch einmal die Testfallszenarien aus dem Pflichtenheft vor
    und geht diese anhand des Klassendiagramms detailliert durch.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
461
462
463
464
465
466
467
468
469
470
471
    Wer ruft wen mit welchen Argumenten auf?
    Üblicherweise fallen dabei viele Details auf,
    wo man mehr Informationen weitergeben muss.
  \item Auch nicht zu vergessen sind Dinge die nicht im UML auftauchen.
    Bilder, SQL-Schema, JSON-Schema, Tools wie ein Leveleditor, etc.
  \item Nun sind drei von vier Wochen rum
    und eigentlich sollte der Entwurf so ziemlich vollständig sein.
    Jetzt ist genügen Zeit für Feinschliff, Präsentation
    und Konsistenzprüfung.
\end{enumerate}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
472
473
474
\subsection{Bewertung eines Entwurfs}

Hier ein paar Tipps, wie man einen Entwurf einschätzen kann.
475
Paradoxe Anforderungen zeigen, dass gutes Design eine Kunst ist.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
476
477
478
479
480
481
482
483

\begin{itemize}
  \item Geheimnisprinzip (information hiding) beachtet?
    Jede Entwurfsentscheidung sollte in genau einer Klasse gekapselt sein,
    so dass eine Änderung dieser Entscheidung
    auch nur diese eine Klasse betrifft.
    Allgemein sollte ein Klasse/Paket möglichst wenig interne Details
    nach außen preisgeben.
484
485
486
487
488
489
  \item Dazu gehört: Behalten Klassen ihre internen Datenstrukturen für sich?
    Eine Klasse, die eine Liste von Objekten verwaltet,
    sollte selbst Methoden zum Hinzufügen, Löschen, u.\,s.\,w.\ bereitstellen.
    Sie sollte \emph{keine} veränderbare Referenz auf die Liste nach außen geben
    und ihre Aufrufer die Liste verändern lassen.
    Für Java siehe z.\,B.~\href{https://docs.oracle.com/javase/10/docs/api/java/util/Collection.html#unmodview}{Unmodifiable View Collections}.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
490
491
492
  \item Lose Koppelung zwischen Klassen/Paketen?
    Abhängigkeiten zu fremden Schnittstellen
    machen spätere Änderungen aufwendiger.
andreas.fried's avatar
andreas.fried committed
493
    Im UML-Diagramm sollten möglichst wenig Verbindungen
Andreas Zwinkau's avatar
Andreas Zwinkau committed
494
    zwischen Klassen zu sehen sein.
495
496
497
498
  \item Keine indirekten Abhängigkeiten?
    Wenn eine Abhängigkeit zwischen Objekten sein muss, soll sie direkt und explizit sein.
    Sich stattdessen an Referenzen entlangzuhangeln sieht auf dem Papier aus wie lose Kopplung,
    koppelt aber tatsächlich mehr Klassen enger aneinander.
499
    Siehe auch \href{http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/general-formulation.html}{Law of Demeter}.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
500
501
502
503
504
505
506
  \item Starke Kohäsion innerhalb von Klasse/Paket?
    Wenn Methoden einer Klasse eigentlich unabhängig voneinander sind,
    ist es ein Zeichen,
    dass eine Auftrennung in zwei Klassen sinnvoll sein könnte.
    Kohäsion führt zu besserer Wiederverwendbarkeit der einzelnen Klassen.
  \item Klassen/Pakete sind gleichzeitig erweiterbar und stabil?
    Erweiterbarkeit bei stabilem Interface ist der große Vorteil
Andreas Zwinkau's avatar
typos    
Andreas Zwinkau committed
507
    von objekt-orientiertem gegenüber prozeduralem Entwurf,
Andreas Zwinkau's avatar
Andreas Zwinkau committed
508
    der durch Vererbung und Polymorphie erreicht wird.
509
    Siehe auch \href{https://en.wikipedia.org/wiki/Open/closed_principle}{Open-Closed Principle}.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
510
  \item Liskovsches Substitutionsprinzip bei Vererbung erfüllt?
andreas.fried's avatar
andreas.fried committed
511
    Unterklassen sollten alle Nachbedingungen
Andreas Zwinkau's avatar
Andreas Zwinkau committed
512
    und alle Invarianten der Oberklasse erfüllen.
Andreas Zwinkau's avatar
minors    
Andreas Zwinkau committed
513
    Andernfalls könnte es zu Fehlern kommen,
Andreas Zwinkau's avatar
Andreas Zwinkau committed
514
515
516
517
518
519
520
521
522
523
524
525
526
527
    wenn eine Unterklasse als Oberklasse verwendet wird.
  \item Verhalten von Implementierung getrennt?
    Das Verhalten (Was soll getan werden) ändert sich sehr viel häufiger
    als die Implementierung (konkrete Algorithmen).
    Beispielsweise sind Sortieralgorithmen recht statisch,
    während die Frage wonach sortiert werden soll,
    sehr flexibel sein sollte.
  \item Keine zyklischen Abhängigkeiten?
    Beispielsweise ist eine zyklische Abhängigkeit
    von Konstruktoren schlicht nicht möglich.
    Eine zyklische Abhängigkeit von größeren Modulen bedeutet,
    dass man alles auf einmal implementieren muss,
    bevor irgendwas funktioniert.
    Entwurfsmuster um Abhängigkeiten zu entfernen:
Andreas Zwinkau's avatar
Andreas Zwinkau committed
528
    Observer, Visitor, Strategy
Andreas Zwinkau's avatar
Andreas Zwinkau committed
529
  \item Lokalitätsprinzip beachtet?
530
    Eine Änderung der Spezifikation sollte nur lokale Änderungen benötigen.
531
    Das impliziert:
Andreas Zwinkau's avatar
Andreas Zwinkau committed
532
    Eine Klasse/Paket/Methode sollte für sich verständlich sein,
533
    ohne dass Kontext notwendig ist.
534
535
536
537
538
539
  \item Sind Methoden frei von unerwarteten Nebeneffekten?
    Eine Methode, die Informationen aus einem Objekt zurückgibt,
    sollte nichts Wesentliches am Objektzustand verändern.
    Auch eine Methode, die dazu dient, den Objektzustand zu verändern,
    sollte nur eine überschaubare Änderung durchführen.
    Siehe auch \href{https://en.wikipedia.org/wiki/Command%E2%80%93query_separation}{Command-query separation}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
540
541
\end{itemize}

andreas.fried's avatar
andreas.fried committed
542
Ähnlich zu den üblichen Entwurfsmustern gibt es auch Anti-Entwurfsmuster.
andreas.fried's avatar
andreas.fried committed
543
Also Muster, die man im Entwurf erkennen kann,
Andreas Zwinkau's avatar
Andreas Zwinkau committed
544
die praktisch immer zu Problemen führen.
andreas.fried's avatar
andreas.fried committed
545
Ein paar Beispiele, die in vergangenen PSE-Projekten auftraten:
Andreas Zwinkau's avatar
Andreas Zwinkau committed
546
547
548
549
550
551
552
553
554

\begin{itemize}
  \item God Object.
    Wenn zuviel Funktionalität in eine Komponente (Klasse) gesteckt wird.
    Es verletzt Lokalitäts- und Geheimnisprinzip.
  \item Anemic domain model.
    Wenn das Model praktisch nur noch Datenspeicher ist.
    Objekt-Orientiertes Design zeichnet sich gerade dadurch aus,
    dass Daten \emph{und} Verarbeitung in Objekten zusammengebaut werden.
andreas.fried's avatar
andreas.fried committed
555
    Objekte, die nur zur Datenhaltung da sind,
Andreas Zwinkau's avatar
Andreas Zwinkau committed
556
557
558
559
    erzwingen prozedurale Programmierung.
  \item \texttt{switch} und \texttt{instanceof}.
    Sieht man im Entwurf zwar noch nicht direkt,
    ist aber manchmal absehbar.
andreas.fried's avatar
andreas.fried committed
560
    Dynamische Bindung ist meistens die bessere Wahl.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
561
562
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
563
564
565
\subsection{UML Diagramme}

\begin{itemize}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
566
  \item \href{http://www.umlet.com/}{UMLet} noch ein UML Tool
Andreas Zwinkau's avatar
Andreas Zwinkau committed
567
568
569
570
  \item \href{http://umbrello.kde.org/}{Umbrella} um einfach nur Diagramme zu zeichnen
  \item \href{http://www.bouml.fr}{BOUML} noch ein UML Tool
  \item \href{http://www.umlgraph.org/}{UMLGraph}
    für Versions-Control-freundliche UML Diagramme.
571
572
573
    (Tipp: Alles in eine Datei und erst in der Implementierungsphase aufspalten)
  \item \href{http://plantuml.sourceforge.net/}{PlantUML} noch ein Tool
    für Versions-Control-freundliche UML Diagramme.
574
    Allerdings eigene Syntax, so dass kein Java-Code daraus erzeugt werden kann.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
575
576
  \item \href{http://www.objectaid.com/}{ObjectAid UML Explorer for Eclipse}
    ein Source-to-Diagram plugin.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
577
  \item \href{http://www.eclipse.org/papyrus/}{Eclipse Papyrus}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
578
  \item \href{http://www.visual-paradigm.com}{Visual Paradigm}
579
  \item \href{http://argouml.tigris.org/}{ArgoUML} um auch Code zu generieren und beim Entwurf zu helfen (Vorsicht: keine \enquote{Undo}-Funktionalität)
Andreas Zwinkau's avatar
Andreas Zwinkau committed
580
581
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
582
583
\subsection{Mehr Links}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
584
585
\begin{itemize}
  \item \href{https://github.com/MatzeB/texdoclet}{TeXdoclet}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
586
587
588
589
    um mit JavaDoc \LaTeX{} zu erzeugen.
    Das ermöglicht den automatischen Flow:
    ArgoUML $\rightarrow$ JavaDoc+TeXdoclet $\rightarrow$
    \LaTeX{} $\rightarrow$ Section \enquote{Klassenbeschreibung} im Entwurf.
Andreas Zwinkau's avatar
minors    
Andreas Zwinkau committed
590
591
592
593
  \item \href{http://www.iste.uni-stuttgart.de/se-old/links/links-se/entwurfsregeln-fuer-den-objektorientierten-entwurf/principles.html}{Prinzipien für den objektorientierten Entwurf},
    Guter Überblicksartikel.
  \item \href{http://prinzipien-der-softwaretechnik.blogspot.de/}{Prinzipien Der Softwaretechnik},
    Blog zum Thema Prinzipien im Software Engineering.
594
595
  \item \href{http://gameprogrammingpatterns.com/}{Game Programming Patterns}
    Buch zu Design Patterns in der Spieleprogrammierung
596
597
598
  \item \href{https://github.com/qznc/uml_generation}{Example Toolchain} zum Wiederverwenden
  \item \href{http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html}{How to Write Doc Comments for the Javadoc Tool}
    mit einigen Tipps und Beispielen.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
599
600
\end{itemize}

601
602
603
\subsection{Inhalt der Präsentation}

\begin{itemize}
andreas.fried's avatar
andreas.fried committed
604
  \item Gerade für UML-Diagramme wäre eine unkonventionelle Präsentation
Andreas Zwinkau's avatar
Andreas Zwinkau committed
605
606
607
    mit \href{http://prezi.com/}{Prezi} einen Versuch wert.
    Man kann ein großes allumfassendes Klassendiagram zeigen
    und dann in Packages und Klassen reinzoomen.
608
609
610
  \item Kurze Einführung und Verbindung zum Pflichtenheft
  \item Ein Sequenzdiagram als anschauliches Beispiel
    mit Ausschnitten aus dem Klassendiagramm.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
611
    Hier kann man ein Testfallszenario aus dem Pflichtenheft auswählen.
612
  \item Überblick über das Gesamtklassendiagramm, Pakete, Module geben.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
613
    Hier kann man über die Verwendung von Entwurfsmustern erzählen.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
614
    Das \textbf{Klassendiagramm} sollte den Kern der Präsentation bilden,
andreas.fried's avatar
andreas.fried committed
615
    also sollte man hierfür auch die meiste Zeit aufwenden.
616
617
  \item Ein großformatig ausgedrucktes Klassendiagramm vermittelt einen Eindruck von der Gesamtarchitektur
    und ist für die folgende Diskussion nützlich.
618
  \item Einhaltung softwaretechnischer Prinzipien zeigen
andreas.fried's avatar
andreas.fried committed
619
    (z.B. Kohäsion, Lokalitätsprinzip, etc.)
620
  \item Gestrichene Wunschkriterien können, aber müssen nicht erwähnt werden.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
621
622
623
    Man muss hier aufpassen, dass kein negativer Eindruck zurückbleibt.
    Für manches gibt es gute Gründe, aber oft ist es geschickter
    Streichungen nur im Dokument zu erwähnen.
624
  \item Verwendete externe Resourcen
andreas.fried's avatar
andreas.fried committed
625
    (Bilder, Frameworks, Bibliotheken, Sounds, Musik, etc.)
626
  \item Nur kurz erwähnen weil eher langweilig:
andreas.fried's avatar
andreas.fried committed
627
    eigene Formate, Datenbankschemata, Einstellungen, Menüstruktur
628
629
630
    und Dialoge.
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
631
\newpage
denis.lohner's avatar
denis.lohner committed
632
\section{Implementierung}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
633

634
\dictum[Linus Torvalds]{Talk is cheap. Show me the code.}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
635

636
\artefakt{Implementierungsplan zu Beginn,
Andreas Zwinkau's avatar
Andreas Zwinkau committed
637
  Implementierungsbericht als PDF Dokument
638
  und vollständiger Sourcecode}
639

Andreas Zwinkau's avatar
Andreas Zwinkau committed
640
\subsection{Plan}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
641
642
643
644
645

\begin{itemize}
  \item Klarer zeitlicher Ablauf der Implementierungsphase,
    um frühzeitig Verzögerungen zu bemerken.
  \item Abhängigkeiten aus dem Entwurf müssen beachtet werden.
646
    Wo ist der \href{http://projektmanagement-definitionen.de/glossar/kritischer-pfad/}{Critical Path}?
647
648
  \item Wie können Teile der Anwendung möglichst früh getestet werden?
    Braucht es dafür Stub-/Mock-Klassen?
649
650
  \item Klare Aufgabenverteilung im Team.
    Dabei muss eine faire Verteilung und die Abhängigkeiten beachtet werden.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
651
652
  \item Als Form bietet sich ein GANTT Chart an,
    wie das Beispiel in \Cref{fig:GANTT}.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
653
    Verpflichtend ist es aber nicht.
654
655
656
657
658
659
660
    Zum Beispiel lässt sich auch eine Tabelle oder \texttt{dot} benutzen.
  \item Einzelne Jobs kann man Klassen oder Packages zuordnen,
    aber häufig ist das nicht möglich.
    Zwischen vielen Klassen gibt es zirkuläre Abhängigkeiten.
    Manche Aufgaben erfordern nur Teile von Klassen.
    Da bietet es sich an, gröbere Aufgaben festzulegen.
    Auch könnte man die Testszenarien als Aufgabenbeschreibung nutzen.
661
  \item Zu \emph{Beginn} der Implementierungsphase (d.h. nach 1-2 Tagen)
Andreas Zwinkau's avatar
Andreas Zwinkau committed
662
663
664
    beim Betreuer abzugeben.
\end{itemize}

665
\begin{figure}[h]
Andreas Zwinkau's avatar
Andreas Zwinkau committed
666
667
668
669
670
671
672
673
674
\includegraphics[width=0.8\textwidth]{GANTT_example}
\caption{\label{fig:GANTT}
Beispiel GANTT Chart:
Jede einzelne Klasse ist als Aufgabe eingetragen.
Abhängigkeiten sind als Pfeile erkennbar.
Der kritische Pfad ist in rot gekennzeichnet.}
\end{figure}


Andreas Zwinkau's avatar
Andreas Zwinkau committed
675
\subsection{Bericht}
676
677

\begin{itemize}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
678
  \item Erfahrungsgemäßer Umfang: ca. 20 Seiten
679
680
  \item Einleitung mit Anschluss auf Pflichtenheft und Entwurf
  \item Dokumentation über Änderungen am Entwurf,
681
682
683
    beispielsweise entfernte oder neu hinzugefügte Klassen und Methoden.
    Gruppiert (und zusammengefasst) werden sollte nach dem Grund für die Änderung
    und nicht nach der geänderten Klasse.
684
685
686
  \item Welche Muss- und Wunschkriterien sind implementiert?
  \item Welche Verzögerungen gab es im Implementierungsplan?
    Kann beispielsweise als zweites GANTT Diagramm am Ende dargestellt werden.
687
  \item Übersicht zu Unittests
688
689
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
690
691
692
693
694
695
696
697
698
699
700
701
702
703
\subsection{Unittests}

\begin{itemize}
  \item Von Anfang an Unittests benutzen.
    Diese Tests gehören \emph{nicht} in die Phase Qualitätssicherung.
  \item Vor allem nicht-graphische Klassen können so
    frühzeitig getestet und Regressionen vermieden werden.
  \item Nur öffentliche Schnittstellen testen.
    Private Methoden werden nicht getestet.
  \item Unittests testen nur kleine \enquote{units}
    (üblicherweise einzelne Klassen) für sich.
    Es sollen nicht ganze Testszenarien getestet werden.
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
704
705
706
707
708
709
710
711
712
713
714
715
716
\subsection{Sonstiges}

\begin{itemize}
  \item Warnungen reparieren.
    Es ist empfehlenswert,
    dass ein Projekt beim Bauen keine Warnungen ausgibt.
    Eine Warnung bedeutet,
    dass der Code üblicherweise aber nicht garantiert fehlerhaft ist.
    In Ausnahmen kann der Programmierer in Java
    dann Annotationen einfügen um Warnungen zu unterdrücken.
  \item Warnungen anschalten.
    In Eclipse kann man zusätzliche Warnungen anschalten:
    Project properties
Andreas Zwinkau's avatar
Andreas Zwinkau committed
717
    $\rightarrow$ Java $\rightarrow$ Compiler
Andreas Zwinkau's avatar
Andreas Zwinkau committed
718
719
720
    $\rightarrow$ Errors/Warnings.
    Standardmäßig wird das meiste ignoriert.
    Beispielsweise kann man aktivieren,
Andreas Zwinkau's avatar
Andreas Zwinkau committed
721
722
    eine Warnung anzuzeigen wenn eine Klasse \texttt{equals} überläd
    aber nicht auch \texttt{hashCode}.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
723
724
725
726
727
728
729
730
731
732
733
734
735
  \item Kommentare im Code (also nicht API Doku)
    sollten das \enquote{Warum} klären,
    nicht das \enquote{Wie}.
    Es ist naturgemäß schwierig vorherzusehen,
    welche Warum-Fragen sich jemand stellt,
    der ein Stück Code liest.
    Die Fragen sind üblicherweise
    \enquote{Warum ist X hier notwendig?},
    \enquote{Warum ist kein X hier?} oder
    \enquote{Warum X, wobei Y doch besser wäre?}.
  \item Exceptions (nicht RuntimeException) für Fehler beim Aufrufer.
    Assertions für interne Konsistenzfehler
    bzw. um Annahmen explizit zu machen.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
736
737
738
739
  \item Keine \href{https://en.wikipedia.org/wiki/Magic_number_(programming)#Unnamed_numerical_constants}{Magic Numbers}.
    Explizite Zahlen im Quellcode sind entweder selbsterklärend
    oder durch benannte Konstanten zu ersetzen.
    Am besten immer letzteres.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
740
741
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
742
743
744
745
746
747
748
749
750
\subsection{Inhalt der Präsentation}

\begin{itemize}
  \item Was wurde implementiert? Welche Wunschkriterien gestrichen?
  \item Zeitplan eingehalten? Wo nicht?
  \item Unerwartete Probleme bei der Implementierung?
  \item Größere Änderungen am Entwurf?
  \item Grobe Statistiken.
    Lines of Code, Wieviele Commits, Arbeitsaufteilung im Team.
751
752
  \item Entwicklungsmodell.
    Wie wurde im Team kommuniziert?
753
754
755
    Wie wurde Git benutzt
    (Gab es Feature-Branches?
    War das Mergen in den master-Branch beschränkt? $\ldots$)
Andreas Zwinkau's avatar
Andreas Zwinkau committed
756
757
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
\begin{figure}\centering
\begin{tikzpicture}
\pgfplotstableread{ % Read the data into a table macro
Label    Alice    Bob    Carol    Dan    Eve
1       623      523        923    323    133
2      1223      923       1426    923   1433
3      1125     1523       1222   1523   1734
4      1328     1226       1821   1923   2435
5      2126     1998       1987   2123   2539
}\datatable

\begin{axis}[
  ybar stacked,   % Stacked horizontal bars
  ymin=0,         % Start x axis at 0
  xtick=data,     % Use as many tick labels as y coordinates
  xticklabels from table={\datatable}{Label}
]
\addplot [fill=green!70!blue]table [y=Bob, x expr=\coordindex] {\datatable};
\addplot [fill=red!80!yellow] table [y=Carol, x expr=\coordindex] {\datatable};
\addplot [fill=blue] table [y=Dan, x expr=\coordindex] {\datatable};
\addplot [fill=yellow] table [y=Alice, x expr=\coordindex] {\datatable};
\addplot [fill=red!50!blue]table [y=Eve, x expr=\coordindex] {\datatable};
\end{axis}
\end{tikzpicture}
\label{fig:loc-per-person}
\caption{Anzahl Codezeilen je Person über 5 Wochen hinweg.
Diese Art von Graph zeigt dass die Verteilung im Team fair aussieht.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
785
Man sieht auch das kontinuierliche Wachstum.}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
786
787
\end{figure}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
788
\newpage
denis.lohner's avatar
denis.lohner committed
789
\section{Qualitätssicherung}
790
791
792
793
794
795

\dictum[Edsger Dijkstra]{
Program testing can be used to show the presence of bugs,
but never to show their absence!
}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
796
\artefakt{Testbericht}
797

798
\begin{itemize}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
799
  \item Überdeckung der Unittests maximieren.
800
    (Siehe bspw.: \href{https://www.jacoco.org/jacoco/}{JaCoCo})
Andreas Zwinkau's avatar
Andreas Zwinkau committed
801
    Wenn GUIs im Spiel sind,
802
803
    ist 100\% Überdeckung üblicherweise nicht möglich,
    aber 90\% sollten schon angestrebt werden.
804
  \item Komplette Testszenarien aus dem Pflichtenheft durchgehen.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
805
    Ein Testdurchlauf sollte möglichst automatisch ablaufen.
806
  \item \href{http://developer.android.com/tools/help/monkeyrunner_concepts.html}{Monkey Testing}
andreas.fried's avatar
andreas.fried committed
807
    für einfaches Testen der GUI.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
808
    Der Ertrag ist erfahrungsgemäß nicht sehr groß,
Andreas Zwinkau's avatar
Andreas Zwinkau committed
809
    also nicht zuviel Aufwand hineinstecken.
810
  \item \href{http://developer.android.com/tools/debugging/improving-w-lint.html}{Lint}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
811
812
    und andere statische Werkzeuge recherchieren.
    Codequalität kann gar nicht gut genug sein.
813
814
    Ein weiteres Tool wäre \href{http://www.sonarqube.org/}{SonarQube}
    oder \href{https://pmd.github.io/}{PMD}.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
815
816
817
818
819
820
821
822
  \item \href{http://en.wikipedia.org/wiki/Usability_testing#Hallway_testing}{Hallway Usability Testing}.
    Systematisches Vorgehen ist wichtig,
    also vorher Fragen, Aufgaben und Umfang festlegen.
    Qualitative (Interviewzitate) und
    quantitative (Durchschnitt über alle Tester)
    Ergebnisse dokumentieren.
  \item Alle gefunden Bugs und deren Reparatur dokumentieren.
    So entsteht der Testbericht am Ende.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
823
    Schema im Bericht: Fehlersymptom, -grund und -behebung
824
  \item Erfahrungsgemäßer Umfang: ca. 10--20 Seiten
825
826
\end{itemize}

827
\subsection{Interne Abnahme}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
828

andreas.fried's avatar
andreas.fried committed
829
Von der Phaseneinteilung her gehört die interne Abnahme zur Qualitätssicherung.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
830
831
Terminlich ist sie entweder zusammen mit dem Kolloquium der Qualitätssicherung
oder kurz danach.
832
833
Hier ist der Code nun endgültig \enquote{fertig},
eure Anwendung wird danach bewertet, was jetzt läuft.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
834

835
Vollständigkeit der Abgabe ist das Wichtigste.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
836
837
838
839
840
Der Sinn dahinter ist, dass euer Betreuer verpflichtet ist
Prüfungsunterlagen 5 Jahre lang aufzubewahren.
Da niemand so genau weiß, was das im Fall von PSE bedeutet,
wird am einfachsten \textsc{Alles} archiviert.
\begin{itemize}
andreas.fried's avatar
andreas.fried committed
841
  \item Sourcecode (TeX, Java, Makefile, C++, Python, HTML, etc.):
842
    vermutlich einfach der Inhalt eures Versionskontrollsystems.
andreas.fried's avatar
andreas.fried committed
843
  \item Artefakte (compiliertes Programm, Dokumente, etc.).
Andreas Zwinkau's avatar
Andreas Zwinkau committed
844
845
846
847
    Zwischenstufen (TeX .aux Dateien) kann man sich sparen,
    andererseits sind die auch nicht so groß.
\end{itemize}

andreas.fried's avatar
andreas.fried committed
848
849
Außerdem ist das der Zeitpunkt,
zu dem euer Betreuer zum letzten Mal euer Produkt testet.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
850
851
852
853
Falls es aufwendiger ist es lauffähig zu bekommen
(bspw. auf ein Androidgerät laden)
am einfachsten ein Gerät mit fertiger Software mitbringen.

Andreas Zwinkau's avatar
Andreas Zwinkau committed
854
\section{Abschlusspräsentation}
denis.lohner's avatar
denis.lohner committed
855

856
857
858
859
\dictum[George Torok]{
We love to hear stories. We don’t need another lecture. Just ask kids.
}

860
861
\artefakt{Präsentationsfolien}

Andreas Zwinkau's avatar
minors    
Andreas Zwinkau committed
862
863
Showtime!

864
865
866
867
868
869
870
\subsection{Inhalt}

Wichtigster Inhalt ist \enquote{\textbf{Was rauskam}}.
Präsentiert eure Applikation.
Das darf so kreativ sein, wie ihr euch traut.
Von der Livedemo bis zum Theaterspielen ist alles erlaubt.

871
872
873
Allerdings soll es kein reiner Werbevortrag sein,
schließlich präsentiert ihr trotzdem vor akademischem Publikum.
Es sollten auch folgende Informationen in den Vortrag:
874
875
876
\begin{itemize}
  \item Kurze Statistik:
    Wieviel Zeilen Code, wieviele Commits und Tests, wieviel Überdeckung?
877
878
879
880
  \item Einblick in die Softwaretechnik:
    Interessante Fakten aus den vorherigen Phasen.
    Kernkomponenten skizzieren.
    Wie fandet ihr \enquote{Wasserfall mit Rückkopplung}?
881
882
883
884
885
886
  \item Lernerfahrung:
    Was hat erstaunlich gut funktioniert?
    Was war aufwendiger als gedacht?
    Was würden wir beim nächsten Mal anders machen?
    Insbesondere Soft-Skill Erfahrung in Sachen
    Teamarbeit und Organisation sind hier interessant.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
887
888
889
890
  \item Die ganze Gruppe:
    Mindestens sollten alle Namen auf den Folien stehen.
    Alle Teammitglieder sollten sich mal zeigen.
    Vielleicht können sogar alle sinnvoll in die Präsentation eingebunden werden?
Andreas Zwinkau's avatar
Andreas Zwinkau committed
891
892
  \item Welche Tools hab ihr für die verschiedenen Aufgaben benutzt
    und wie gut fandet ihr sie?
893
  \item Zeitrahmen sind 15 Minuten plus Fragen.
894
895
896
897
898
\end{itemize}

Zu diesem Zeitpunkt habt ihr erfolgreich ein ordentliches Softwareprojekt
von Anfang bis Ende durchgeführt.
Selbst wenn nicht alles glatt lief,
andreas.fried's avatar
andreas.fried committed
899
so könnt ihr trotzdem stolz auf euch sein.
900
901
902
Egal was ihr gemacht habt,
völlig falsch kann es nicht gewesen sein.

Andreas Zwinkau's avatar
Andreas Zwinkau committed
903
\pagebreak
Andreas Zwinkau's avatar
Andreas Zwinkau committed
904
905
Wie bereits gesagt,
seid ihr nicht gezwungen den KIT Folienstil zu verwenden.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
906
907
908
909
910
Lasst euch stilistisch also woanders inspirieren.

\includegraphics[width=\textwidth]{iPad-2-Keynote-by-Steve-Jobs.png}
{\tiny Image source: \url{http://abovethecrowd.com/2015/07/07/in-defense-of-the-deck/}}

911
912
913
914
915
916
917
918
919
\subsection{Mehr Links}

\begin{itemize}
  \item \href{http://www.presentationzen.com/}{Presentation Zen}
  \item \href{http://beza1e1.tuxen.de/articles/technical_presentation.html}{9 Tips How to Give a Technical Presentation}
  \item \href{http://dilbert.com/blog/entry/the_science_of_making_your_story_memorable/}{The Science of Making Your Story Memorable}
  \item \href{http://www.nytimes.com/2013/10/06/magazine/and-then-steve-said-let-there-be-an-iphone.html?pagewanted=all}{Backstage at the First iPhone Presentation}
\end{itemize}

920
\newpage
921
922
\section{Probleme im Team}

andreas.fried's avatar
andreas.fried committed
923
924
Am schönsten ist PSE, wenn alle Teammitglieder hochmotiviert sind,
sodass alle ihren Beitrag leisten.
925
926
927
928
929
930
931
932
933
934
935
936
Manchmal läuft es auch so.
Manchmal kracht es aber auch.

An vorderster Front und bewusst in der Verantwortung
steht der Phasenverantwortliche.
Falls dieser ein Problem nicht lösen kann,
eskaliert es zum Betreuer.
Falls dieser ein Problem nicht lösen kann,
eskaliert es zur PSE-Organisation.
In jedem Fall hofft man aber natürlich,
dass eine Eskalation nicht notwendig ist.

937
938
939
940
941
942
\subsection{Wie vermeidet man Probleme?}

Ein wichtiger Punkt ist klare Erwartungen auszusprechen.
Besprecht in der Gruppe Fragen wie die Folgenden:

\begin{itemize}
andreas.fried's avatar
andreas.fried committed
943
  \item Welche Note/Teilnote erwarte ich?
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
    Ist eine 1,0 das klare Ziel oder bin ich schon mit 1,7 zufrieden?
  \item Welche Aufgaben müssen zu welchen Deadlines erledigt sein?
    Sollte der Phasenverantwortliche wöchentliche Deadlines festlegen?
  \item Wie hart darf man mich kritisieren?
    Studenten kommen oft aus sehr unterschiedlichen Kulturen,
    wo Fleiß, Ehre, Respekt oder Pünktlichkeit ganz anders bewertet werden.
  \item Wieviel Zeit kann ich wann für PSE aufbringen?
    Es geht dabei nicht nur um Zeitplanung.
    Häufig investieren PSE-Teilnehmer mehr in ihr Projekt als gefordert,
    falls nur einzelne aus dem Team das tun,
    kann es sich negativ auf die Gruppenmoral auswirken.
\end{itemize}

Es kann hilfreich sein einige Regeln schriftlich festzuhalten.
Empfehlenswert ist dabei ein Minimum an Zeremonie,
indem beispielsweise jedes Teammitglied das Regelwerk unterschreibt.

\subsection{Was tun bei Problemen?}

963
964
965
Häufigstes Problem ist,
dass ein oder mehrere Teammitglieder kaum mithelfen.
Die Aufgabenverteilung wird unfair
966
und diejenigen, die die Arbeit machen, sind frustriert.
967

968
969
Wichtig ist als erstes Fakten zu sammeln und aufzuschreiben.
Wer hat wann welche Aufgabe mit welcher Deadline zugeteilt bekommen?
970
Wer hat wann wieviel Stunden gearbeitet?
971
Welche Deadlines wurden wie schlecht oder gar nicht eingehalten?
andreas.fried's avatar
andreas.fried committed
972
Man braucht konkrete Fakten.
973
974
Die Aufgabenverteilung kann der Phasenverantwortliche kontrollieren.
Stundenzettel muss jeder für sich führen.
975
976
977
978
979
980
981
982
983
984
985
986
987

Nun bespricht man diese Fakten.
Fokus ist primär die Suche nach einer gemeinsamen Diskussionsgrundlage.
Sind wir uns einig, was wirklich geschehen ist?
Hier ist Vollständigkeit wichtig.
Bei stilleren Studenten ist Nachbohren mit Fingerspitzengefühl notwendig.
Sind wir uns einig, dass es so nicht weitergehen soll?
Falls nicht, wird eskaliert.
Falls ja, hat man gemeinsames Ziel
und kann gemeinsam an einer Lösung arbeiten.
Falls man keine Lösung findet,
sollte man nach Hilfe suchen.

988
\newpage
Andreas Zwinkau's avatar
Andreas Zwinkau committed
989
990
991
992
993
994
995
996
997
998
\section{Feedback}

Wir wissen gerne was wir besser machen könnten.
Falls ihr also den Jahrgängen nach euch etwas Gutes tun wollt,
dann gebt eurem Betreuer ein Feedback.
Zum Beispiel könnt ihr die folgenden beiden Fragen beantworten:

\begin{enumerate}
  \item Auf einer Skala von 0 (schlecht) bis 10 (perfekt),
    wie fandet ihr PSE/TSE?
999
1000
1001
    \hfill\fbox{\begin{minipage}{1cm}
    \hspace{0.4cm}\vspace{10pt}
    \end{minipage}}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
1002
  \item Warum in Frage 1 genau diese Zahl? Warum nicht mehr? Warum nicht weniger?
Andreas Zwinkau's avatar
Andreas Zwinkau committed
1003
1004
\end{enumerate}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
1005
1006
1007
1008
1009
1010
1011
1012
\vfill
\begin{center}
when you don't create things, you become defined by your tastes rather than ability.
your tastes only narrow \& exclude people. so \textbf{create}.

\hfill --- Why The Lucky Stiff
\end{center}

denis.lohner's avatar
denis.lohner committed
1013
\end{document}