tipps.tex 25.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,
}
denis.lohner's avatar
denis.lohner committed
18
19

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

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

29
30
31
32
\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
33
34
35
\begin{document}
\maketitle

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

\section{Technisches}
41
42
43
44
45
46

\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
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
\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.}
  \item Vermeide den Parameter \texttt{--force} bzw. \texttt{-f}.
    Häufig schiebst du damit Probleme nur deinen Teamkollegen zu.
\end{itemize}

65
66
67
68
69
70
71
72
Genereller Tip:
Keine generierten Dateien ins einchecken.
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
73
74
75
76
77
78
79
\subsection{Dokumentenformat}

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.

80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
\subsubsection{\LaTeX}

Statt den normalen Dokumentklassen,
empfiehlen wir vor allem für deutsche Dokumente
die KOMA-Scriptklassen zu verwenden.
Diese sind flexibler und besser für deutsche Typografie ausgelegt.
Das bedeutet deutsche Dokumente starten
mit der folgenden Deklaration.

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

Das \texttt{parskip=full} sorgt
für eine Absatzabstand von einer Zeile
und die erste Zeile eines Absatzes wird nicht eingerückt.
Das ist im Deutsch das übliche Format,
aber nicht im Englischen.

Weitere für (deutsche) \LaTeX-Dokument fast immer gute Einstellungen:
Andreas Zwinkau's avatar
Andreas Zwinkau committed
100
101
102
103

\begin{verbatim}
\usepackage[utf8]{inputenc} % use utf8 file encoding for TeX sources
\usepackage[T1]{fontenc}    % avoid garbled Unicode text in pdf
104
\usepackage[german]{babel}  % german hyphenation, quotes, etc
Andreas Zwinkau's avatar
Andreas Zwinkau committed
105
\usepackage{hyperref}       % detailed hyperlink/pdf configuration
106
\hypersetup{                % `texdoc hyperref` for options
Andreas Zwinkau's avatar
Andreas Zwinkau committed
107
  pdftitle={PSE: Tipps},
108
  bookmarks=true,
Andreas Zwinkau's avatar
Andreas Zwinkau committed
109
}
110
\usepackage{csquotes}       % provides \enquote{} macro for "quotes"
Andreas Zwinkau's avatar
Andreas Zwinkau committed
111
112
\end{verbatim}

113
114
115
116
117
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.

Andreas Zwinkau's avatar
Andreas Zwinkau committed
118
119
120
121
122
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.

123
124
125
126
127
128
129
130
131
\subsection{GUI Entwürfe}

\begin{itemize}
  \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
\end{itemize}

denis.lohner's avatar
denis.lohner committed
132
133
134
135
136
137
\subsection{UML Diagramme}

\begin{itemize}
  \item \href{http://umbrello.kde.org/}{Umbrella} um einfach nur Diagramme zu zeichnen
  \item \href{http://argouml.tigris.org/}{ArgoUML} um auch Code zu generieren und beim Entwurf zu helfen
  \item \href{http://www-01.ibm.com/software/rational/uml/}{IBM Rational Software Architect} ist im ATIS Pool installiert.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
138
139
140
141
  \item \href{http://www.bouml.fr}{BOUML} noch ein UML Tool
  \item \href{http://www.umlet.com/}{UMLet} noch ein UML Tool
  \item \href{http://www.umlgraph.org/}{UMLGraph}
    für Versions-Control-freundliche UML Diagramme.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
142
143
  \item \href{http://www.objectaid.com/}{ObjectAid UML Explorer for Eclipse}
    ein Source-to-Diagram plugin.
denis.lohner's avatar
denis.lohner committed
144
145
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
146
147
\section{Kolloquium}

148
149
150
151
152
\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
153
154
155
156
157
158
159
160
161
162
163
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,
    verschränkte Arme, Nuscheln, nervöses herumlaufen, etc.
164
  \item Lauf und deutlich sprechen.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
165
166
167
168
169
170
171
172
173
174
  \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
175
176
  \item Keine Agenda-/Inhaltsverzeichnis-/Gliederungsfolie.
    Ist nicht mehr zeitgemäß und langweilt nur.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
177
178
\end{itemize}

denis.lohner's avatar
denis.lohner committed
179
180
\section{Organisatorisches}

181
182
183
184
\dictum[Bjarne Stroustrup]{
Design and programming are human activities; forget that and all is lost.
}

denis.lohner's avatar
denis.lohner committed
185
186
187
188
189
190
191
\begin{itemize}
  \item Meldet euch so früh wie möglich im \href{https://studium.kit.edu}{Studierendenportal} für PSE (Pr.Nr. 529) und TSE (Pr.Nr. 455) an.
  \item Mails an den Betreuer sollten vom Phasenverantwortlichen kommen.
\end{itemize}

\section{Pflichtenheft}

192
193
194
195
\dictum[Dwight Eisenhower]{
I have always found that plans are useless, but planning is indispensable.
}

196
197
\artefakt{PDF Dokument}

denis.lohner's avatar
denis.lohner committed
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
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.
    Möglichst klein halten.
  \item[Wunschkriterien]
    Von den Gruppen selbst definierte, zusätzliche Funktionalität.
  \item[Abgrenzungskriterien]
    Was unterstützt unser Produkt explizit \emph{nicht}.
\end{description}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
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.
  \item Das Pflichtenheft sollte auch von nicht technisch-versierten Menschen
    zu großen Teilen verstanden werden können.
    Am besten jemand fach-fremden zum Lesen geben
    und danach Verständnisfragen stellen.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
234
  \item Erfahrungsgemäßer Umfang: ca. 40 Seiten
Andreas Zwinkau's avatar
Andreas Zwinkau committed
235
236
237
238
\end{itemize}

\subsection{Struktur}

denis.lohner's avatar
denis.lohner committed
239
240
241
242
243
244
245
246
247
248
249
250
Beschreibung und Beispiele von Pflichtenheften
finden sich in der Vorlesung Softwaretechnik 1.
Die Struktur muss aber nicht exakt übernommen werden.
Sinnvolle Änderungen könnten sein:

\begin{itemize}
  \item Funktionale Anforderungen von Muss- und Wunschkriterien mischen und
    durch Layout, Stil, Marker, Icons entsprechend kennzeichnen.
  \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.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
251
252
253
254
255
256
  \item Reihenfolge der Kapitel verändern,
    so dass es flüssiger von vorne nach hinten gelesen werden kann.
  \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
    und die erwartet Reaktion des Programms sein.
denis.lohner's avatar
denis.lohner committed
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
\end{itemize}

\subsection{Technisches Schreiben}

Technisches Schreiben ist wichtig für alle Arten von technischen und wissenschaftlichen Dokumenten,
also auch API-Dokumentation, Bachelorarbeit und Pflichtenheft.
Es bedeutet vor allem eine präzise Ausdrucksweise
und widerspricht dabei einigen Regeln,
die man im Deutschunterricht gelernt hat.
Ein paar praktische Tipps:

\begin{itemize}
  \item Vermeide Adjektive.
    Oft (nicht immer) sind sie unnötig oder
    ein schlechter Ersatz für einen ungenauen Begriff.
  \item Definiere Begriffe klar und verwende keine Synonyme.
    Synonyme lassen offen, ob genau das gleiche gemeint ist
    oder nur etwas ähnliches.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
275
276
  \item Abkürzungen sollten bei der ersten Verwendung (EV)
    ausgeschrieben werden. Nach der EV reicht dann die Kurzform.
denis.lohner's avatar
denis.lohner committed
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
  \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.
\end{itemize}

Das Pflichtenheft ist das entscheidenste Dokument
zwischen Kunde und Entwickler am Ende eines Projekts.
Es darf \textbf{keinen Spielraum für Interpretationen} offen lassen.

298
299
300
301
302
303
304
305
306
\subsection{Inhalt der Präsentation}

\begin{itemize}
  \item Kurze Einführung zur Aufgabenstellung
  \item Überblick über die wichtigsten Features
  \item Grundsätzliche selbstgesetzte Rahmenbedingungen
  \item Ein Testfallszenario als anschauliches durchgehenden Beispiel
\end{itemize}

denis.lohner's avatar
denis.lohner committed
307
\section{Entwurf}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
308

309
\dictum[Bob Martin]{
Andreas Zwinkau's avatar
Andreas Zwinkau committed
310
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.
311
}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
312

313
314
315
\artefakt{PDF Dokument mit UML-Diagrammen,
  Klassenbeschreibungen, Erläuterungen, Designentscheidungen}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
316
317
\subsection{Inhalt}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
318
\begin{itemize}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
319
320
321
322
323
324
325
326
327
328
329
  \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.
  \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,
    dann dabei werden die Schnittstellen zwischen Packages und Klassen klar.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
330
  \item Aufteilung in Klassen/Pakete
Andreas Zwinkau's avatar
Andreas Zwinkau committed
331
    die unabhängig voneinander implementiert und getestet werden können.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
332
    Mit Blick auf den Implementierungsplan.
333
  \item Änderungen zum Pflichtenheft, bspw. gekürzte Wunschkriterien
Andreas Zwinkau's avatar
Andreas Zwinkau committed
334
335
336
  \item Vollständiges großformatiges Klassendiagramm im Anhang.
    Ausschnitte/Teile können bereits vorher verwendet werden,
    um Teilkomponenten zu beschreiben.
337
338
  \item Identifikation von Entwurfsmustern
    um Struktur gröber zu beschreiben (möglicherweise).
Andreas Zwinkau's avatar
Andreas Zwinkau committed
339
340
  \item Erfahrungsgemäßer Umfang: über 100 Seiten,
    primär Klassenbeschreibungen
Andreas Zwinkau's avatar
Andreas Zwinkau committed
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
\end{itemize}

\subsection{Bewertung eines Entwurfs}

Hier ein paar Tipps, wie man einen Entwurf einschätzen kann.
Paradoxe Anforderungen zeigen, dass gutes Design ein Kunst ist.

\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.
  \item Lose Koppelung zwischen Klassen/Paketen?
    Abhängigkeiten zu fremden Schnittstellen
    machen spätere Änderungen aufwendiger.
    Im UML Diagramm sollten möglichst wenig Verbindungen
    zwischen Klassen zu sehen sein.
    Siehe auch Law of Demeter.
  \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
    von objekt-orientertem gegenüber proceduralem Entwurf,
    der durch Vererbung und Polymorphie erreicht wird.
    Siehe auch Open-Closed Principle.
  \item Liskovsches Substitutionsprinzip bei Vererbung erfüllt?
Andreas Zwinkau's avatar
minors    
Andreas Zwinkau committed
372
    Unterklassen sollte alle Nachbedingungen
Andreas Zwinkau's avatar
Andreas Zwinkau committed
373
    und alle Invarianten der Oberklasse erfüllen.
Andreas Zwinkau's avatar
minors    
Andreas Zwinkau committed
374
    Andernfalls könnte es zu Fehlern kommen,
Andreas Zwinkau's avatar
Andreas Zwinkau committed
375
376
377
378
379
380
381
382
383
384
385
386
387
388
    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
389
    Observer, Visitor, Strategy
Andreas Zwinkau's avatar
Andreas Zwinkau committed
390
391
392
  \item Lokalitätsprinzip beachtet?
    Eine Klasse/Paket/Methode sollte für sich verständlich sein,
    ohne das Kontext notwendig ist.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
393
394
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
395
396
\subsection{Mehr Links}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
397
398
\begin{itemize}
  \item \href{https://github.com/MatzeB/texdoclet}{TeXdoclet}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
399
400
401
402
    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
403
404
405
406
  \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.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
407
408
\end{itemize}

409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
\subsection{Inhalt der Präsentation}

\begin{itemize}
  \item Kurze Einführung und Verbindung zum Pflichtenheft
  \item Ein Sequenzdiagram als anschauliches Beispiel
    mit Ausschnitten aus dem Klassendiagramm.
  \item Überblick über das Gesamtklassendiagramm, Pakete, Module geben.
  \item Gestrichene Wunschkriterien
  \item Verwendete externe Resourcen
    (Bilder,Frameworks,Bibliotheken,Sounds,Musik,etc)
  \item Nur kurz erwähnen weil eher langweilig:
    Eigene Formate, Datenbankschemata, Einstellungen
    und Dialoge.
\end{itemize}

denis.lohner's avatar
denis.lohner committed
424
\section{Implementierung}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
425

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

428
429
430
431
\artefakt{Implementierungsplan zu Beginn,
  Implementierungsbericht
  und vollständiger source code}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
432
433
434
435
436
437
438
439
440
441
442
443
444
\subsection{Implementierungsplan}

\begin{itemize}
  \item Klarer zeitlicher Ablauf der Implementierungsphase,
    um frühzeitig Verzögerungen zu bemerken.
  \item Klare Aufgabenverteilung im Team.
  \item Abhängigkeiten aus dem Entwurf müssen beachtet werden.
  \item Als Form bietet sich ein GANTT Chart an.
    Verpflichtend ist es aber nicht.
  \item Zu \emph{Beginn} der Implementierungsphase
    beim Betreuer abzugeben.
\end{itemize}

445
446
447
\subsection{Implementierungsbericht}

\begin{itemize}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
448
  \item Erfahrungsgemäßer Umfang: ca. 20 Seiten
449
450
451
452
453
454
455
456
457
  \item Einleitung mit Anschluss auf Pflichtenheft und Entwurf
  \item Dokumentation über Änderungen am Entwurf,
    beispielsweise entfernte oder neu hinzugefügte Klassen und Methoden
  \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.
  \item Übersicht zu unit tests
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
458
459
460
461
462
463
464
465
466
467
468
469
470
471
\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
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
\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
    $\rightarrow$ Java Compiler
    $\rightarrow$ Errors/Warnings.
    Standardmäßig wird das meiste ignoriert.
    Beispielsweise kann man aktivieren,
    dass eine Zuweisung innerhalb einer Bedingung \enquote{\texttt{if(a=b)}} eine Warnung (oder sogar ein Fehler) ist.
  \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.
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
505
506
507
508
509
510
511
512
513
514
515
\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.
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
\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.
Auch sieht man den kontinuierlichen Wachstum.}
\end{figure}

denis.lohner's avatar
denis.lohner committed
546
\section{Qualitätssicherung}
547
548
549
550
551
552

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

553
554
\artefakt{Testberichte}

555
\begin{itemize}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
556
557
558
559
  \item Überdeckung der Unittests maximieren.
    (Siehe bspw.: \href{http://www.eclemma.org/}{EclEmma})
    Wenn GUIs im Spiel sind,
    ist 100\% Überdeckung üblicherweise nicht möglich.
560
  \item Komplette Testszenarien aus dem Pflichtenheft durchgehen.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
561
    Ein Testdurchlauf sollte möglichst automatisch ablaufen.
562
  \item \href{http://developer.android.com/tools/help/monkeyrunner_concepts.html}{Monkey Testing}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
563
564
565
    für einfaches GUI testen.
    Der Ertrag ist vermutlich nicht sehr groß,
    also nicht zuviel Aufwand hineinstecken.
566
567
568
569

    Automatisierung mit
    \href{https://code.google.com/p/robotium/}{Robotium}
    und \href{http://developer.android.com/tools/help/uiautomator/index.html}{UIAutomator}?
570
  \item \href{http://developer.android.com/tools/debugging/improving-w-lint.html}{Lint}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
571
572
573
574
575
576
577
578
579
580
    und andere statische Werkzeuge recherchieren.
    Codequalität kann gar nicht gut genug sein.
  \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.
581
582
\end{itemize}

583
\newpage
Andreas Zwinkau's avatar
Andreas Zwinkau committed
584
\section{Abschlusspräsentation}
denis.lohner's avatar
denis.lohner committed
585

586
587
588
589
\dictum[George Torok]{
We love to hear stories. We don’t need another lecture. Just ask kids.
}

590
591
\artefakt{Präsentationsfolien}

Andreas Zwinkau's avatar
minors    
Andreas Zwinkau committed
592
593
Showtime!

594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
\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.

Nebenbei dürfen folgende Informationen auch in den Vortrag:
\begin{itemize}
  \item Kurze Statistik:
    Wieviel Zeilen Code, wieviele Commits und Tests, wieviel Überdeckung?
  \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
611
612
613
614
  \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?
615
616
617
618
619
620
621
622
623
\end{itemize}

Zu diesem Zeitpunkt habt ihr erfolgreich ein ordentliches Softwareprojekt
von Anfang bis Ende durchgeführt.
Selbst wenn nicht alles glatt lief,
so könnt ihr trotzdem Stolz auf euch sein.
Egal was ihr gemacht habt,
völlig falsch kann es nicht gewesen sein.

624
625
626
627
628
629
630
631
632
\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}

633
\newpage
Andreas Zwinkau's avatar
Andreas Zwinkau committed
634
635
636
637
638
639
640
641
642
643
\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?
644
645
646
    \hfill\fbox{\begin{minipage}{1cm}
    \hspace{0.4cm}\vspace{10pt}
    \end{minipage}}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
647
648
649
  \item Warum in Frage 1 genau diese Zahl?
\end{enumerate}

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