tipps.tex 38 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
Dies ist eine Sammlung, um nichts zu vergessen
und weniger Fehler beim Erklären zu machen.

Andreas Zwinkau's avatar
Andreas Zwinkau committed
40
\section{Tools für alle Phasen}
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.

Andreas Zwinkau's avatar
Andreas Zwinkau committed
73 74 75 76
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
77 78

\subsection{Dokumentenformat: \LaTeX}
denis.lohner's avatar
denis.lohner committed
79 80 81 82 83 84

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.

85
Statt den normalen Dokumentklassen,
86
empfehlen wir vor allem für deutsche Dokumente
87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102
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
103 104 105 106

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

116 117 118 119 120
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
121 122 123 124 125
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
126 127 128 129
\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.}
130

Andreas Zwinkau's avatar
Andreas Zwinkau committed
131 132 133 134 135 136
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,
die man im Deutschunterricht gelernt hat.
Ein paar praktische Tipps:
denis.lohner's avatar
denis.lohner committed
137 138

\begin{itemize}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
139 140 141
  \item Vermeide Adjektive.
    Oft (nicht immer) sind sie unnötig oder
    ein schlechter Ersatz für einen ungenauen Begriff.
142
  \item Nebensatzkonstruktionen vermeiden; Hauptsätze verwenden!
Andreas Zwinkau's avatar
Andreas Zwinkau committed
143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162
  \item Definiere Begriffe klar und verwende keine Synonyme.
    Synonyme lassen offen, ob genau das gleiche gemeint ist
    oder nur etwas ähnliches.
  \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.
denis.lohner's avatar
denis.lohner committed
163 164
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
165

Andreas Zwinkau's avatar
Andreas Zwinkau committed
166 167
\section{Kolloquium}

168 169 170 171 172
\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
173 174 175 176 177 178 179 180 181 182 183
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.
184
  \item Lauf und deutlich sprechen.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
185 186 187 188 189 190 191 192 193 194
  \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
195 196
  \item Keine Agenda-/Inhaltsverzeichnis-/Gliederungsfolie.
    Ist nicht mehr zeitgemäß und langweilt nur.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
197 198
\end{itemize}

denis.lohner's avatar
denis.lohner committed
199 200
\section{Organisatorisches}

201 202 203 204
\dictum[Bjarne Stroustrup]{
Design and programming are human activities; forget that and all is lost.
}

denis.lohner's avatar
denis.lohner committed
205 206 207 208 209
\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}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
210
\newpage
denis.lohner's avatar
denis.lohner committed
211 212
\section{Pflichtenheft}

213 214 215 216
\dictum[Dwight Eisenhower]{
I have always found that plans are useless, but planning is indispensable.
}

217 218
\artefakt{PDF Dokument}

denis.lohner's avatar
denis.lohner committed
219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235
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
236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254
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.
255
  \item Das Pflichtenheft ist das entscheidendste Dokument
Andreas Zwinkau's avatar
Andreas Zwinkau committed
256 257
    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
258
  \item Erfahrungsgemäßer Umfang: ca. 40 Seiten
Andreas Zwinkau's avatar
Andreas Zwinkau committed
259 260 261 262
\end{itemize}

\subsection{Struktur}

denis.lohner's avatar
denis.lohner committed
263 264
Beschreibung und Beispiele von Pflichtenheften
finden sich in der Vorlesung Softwaretechnik 1.
265 266 267 268 269

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
270 271 272 273 274 275 276 277 278
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.
279
    Auch Bilder und Grafiken sind erlaubt.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
280 281 282 283 284
  \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
285
    und die erwartete Reaktion des Programms sein.
286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305
    Beispiel:
    \paragraph{T1337} Einloggen
    \begin{enumerate}
      \item \begin{description}
        \item[Stand] Offenes browserfenster.
        \item[Aktion] Benutzer gibt \enquote{facebook.com} in die Kopfzeile
          ein und drückt Enter.
        \item[Reaktion] Der browser wechselt zur Facebook Frontseite.
      \end{description}
      \item \begin{description}
        \item[Stand] Facebook Frontseite ist geladen.
          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.
          Der browser wird zur Newsfeedseite des Benutzers umgeleitet.
      \end{description}
    \end{enumerate}
    Die Testfallszenarien sind in Entwurfs- und Qualitätssicherungsphase nützlich.
denis.lohner's avatar
denis.lohner committed
306 307
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
308
\subsection{GUI Entwürfe}
denis.lohner's avatar
denis.lohner committed
309 310

\begin{itemize}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
311 312 313 314
  \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
315 316
\end{itemize}

317 318 319 320 321
\subsection{Inhalt der Präsentation}

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

Andreas Zwinkau's avatar
Andreas Zwinkau committed
326
\newpage
denis.lohner's avatar
denis.lohner committed
327
\section{Entwurf}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
328

329
\dictum[Bob Martin]{
Andreas Zwinkau's avatar
Andreas Zwinkau committed
330
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.
331
}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
332

333 334 335
\artefakt{PDF Dokument mit UML-Diagrammen,
  Klassenbeschreibungen, Erläuterungen, Designentscheidungen}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
336 337
\subsection{Inhalt}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
338
\begin{itemize}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
339 340 341 342 343 344
  \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
345 346
    Was hier \emph{nicht} reingehört sind private Felder und Methoden.
    Das sind Implementierungsdetails.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
347 348 349 350 351
  \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
352
  \item Aufteilung in Klassen/Pakete
Andreas Zwinkau's avatar
Andreas Zwinkau committed
353
    die unabhängig voneinander implementiert und getestet werden können.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
354
    Mit Blick auf den Implementierungsplan.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
355
  \item Änderungen zum Pflichtenheft, bspw. gekürzte Wunschkriterien.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
356 357 358
  \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
359 360 361
    Assoziationen zwischen Klassen dabei bitte
    mit entsprechenden Pfeilen darstellen,
    statt nur durch Feldtypen.
362
  \item Identifikation von Entwurfsmustern
Andreas Zwinkau's avatar
Andreas Zwinkau committed
363
    um Struktur gröber zu beschreiben.
364 365
  \item Erfahrungsgemäßer Umfang:
    \begin{itemize}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
366 367
      \item 100 Seiten, primär Klassenbeschreibungen
      \item 40--80 Klassen ohne Interfaces
368 369 370
    \end{itemize}
  \item Möglicherweise weitere UML-Diagrammarten?
  \item Formale Spezifikation von Kernkomponenten?
Andreas Zwinkau's avatar
Andreas Zwinkau committed
371 372
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429
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.
  \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.
    Nehmt euch die Testfallszenarien aus dem Pflichtenheft
    und spielt diese anhand des Klassendiagramms durch.
    Wer ruft wen mit welchen Argumenten auf?
    Üblicherweise fallen dabei viele Details auf,
    wo man mehr Informationen weitergeben muss.
    Das alles kann man in Sequenzdiagrammen festhalten.
  \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
430 431 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
\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
459
    Unterklassen sollte alle Nachbedingungen
Andreas Zwinkau's avatar
Andreas Zwinkau committed
460
    und alle Invarianten der Oberklasse erfüllen.
Andreas Zwinkau's avatar
minors  
Andreas Zwinkau committed
461
    Andernfalls könnte es zu Fehlern kommen,
Andreas Zwinkau's avatar
Andreas Zwinkau committed
462 463 464 465 466 467 468 469 470 471 472 473 474 475
    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
476
    Observer, Visitor, Strategy
Andreas Zwinkau's avatar
Andreas Zwinkau committed
477
  \item Lokalitätsprinzip beachtet?
478 479
    Eine Änderung der Spezifikation sollte nur lokale Änderungen benötigen.
    Das Impliziert:
Andreas Zwinkau's avatar
Andreas Zwinkau committed
480
    Eine Klasse/Paket/Methode sollte für sich verständlich sein,
481
    ohne dass Kontext notwendig ist.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
482 483
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505
Ähnlich zu den üblichen Entwurfsmustern,
gibt es auch Anti-Entwurfsmuster.
Also Muster die man im Entwurf erkennen kann,
die praktisch immer zu Problemen führen.
Ein paar Beispiel, die in vergangenen PSE Projekten auftraten:

\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.
    Objekte die nur zur Datenhaltung da sind
    erzwingen prozedurale Programmierung.
  \item \texttt{switch} und \texttt{instanceof}.
    Sieht man im Entwurf zwar noch nicht direkt,
    ist aber manchmal absehbar.
    Dynamische Binding ist meistens die bessere Wahl.
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
506 507 508
\subsection{UML Diagramme}

\begin{itemize}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
509
  \item \href{http://www.umlet.com/}{UMLet} noch ein UML Tool
Andreas Zwinkau's avatar
Andreas Zwinkau committed
510 511 512 513
  \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.
514 515 516 517
    (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.
    Allerdings eigene Syntax, so dass keine Java code daraus erzeugt werden kann.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
518 519
  \item \href{http://www.objectaid.com/}{ObjectAid UML Explorer for Eclipse}
    ein Source-to-Diagram plugin.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
520
  \item \href{http://www.eclipse.org/papyrus/}{Eclipse Papyrus}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
521
  \item \href{http://www.visual-paradigm.com}{Visual Paradigm}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
522
  \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
523 524
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
525 526
\subsection{Mehr Links}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
527 528
\begin{itemize}
  \item \href{https://github.com/MatzeB/texdoclet}{TeXdoclet}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
529 530 531 532
    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
533 534 535 536
  \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.
537 538
  \item \href{http://gameprogrammingpatterns.com/}{Game Programming Patterns}
    Buch zu Design Patterns in der Spieleprogrammierung
539 540 541
  \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
542 543
\end{itemize}

544 545 546
\subsection{Inhalt der Präsentation}

\begin{itemize}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
547 548 549 550
  \item Gerade für UML Diagramme wäre eine unkonventionelle Präsentation
    mit \href{http://prezi.com/}{Prezi} einen Versuch wert.
    Man kann ein großes allumfassendes Klassendiagram zeigen
    und dann in Packages und Klassen reinzoomen.
551 552 553
  \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
554
    Hier kann man ein Testfallszenario aus dem Pflichtenheft auswählen.
555
  \item Überblick über das Gesamtklassendiagramm, Pakete, Module geben.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
556
    Hier kann man über die Verwendung von Entwurfsmustern erzählen.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
557 558
    Das \textbf{Klassendiagramm} sollte den Kern der Präsentation bilden,
    also sollte man hier auch die meiste Zeit für aufwenden.
559 560
  \item Einhaltung softwaretechnischer Prinzipien zeigen
    (z.B. Kohäsion, Lokalitätsprinzip, etc)
Andreas Zwinkau's avatar
Andreas Zwinkau committed
561 562 563 564
  \item Gestrichene Wunschkriterien können aber müssen nicht erwähnt werden.
    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.
565 566 567
  \item Verwendete externe Resourcen
    (Bilder,Frameworks,Bibliotheken,Sounds,Musik,etc)
  \item Nur kurz erwähnen weil eher langweilig:
Andreas Zwinkau's avatar
Andreas Zwinkau committed
568
    Eigene Formate, Datenbankschemata, Einstellungen, Menüstruktur
569 570 571
    und Dialoge.
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
572
\newpage
denis.lohner's avatar
denis.lohner committed
573
\section{Implementierung}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
574

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

577
\artefakt{Implementierungsplan zu Beginn,
Andreas Zwinkau's avatar
Andreas Zwinkau committed
578 579
  Implementierungsbericht als PDF Dokument
  und vollständiger Source Code}
580

Andreas Zwinkau's avatar
Andreas Zwinkau committed
581
\subsection{Plan}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
582 583 584 585 586

\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.
587 588 589
    Wo ist der \href{http://projektmanagement-definitionen.de/glossar/kritischer-pfad/}{Critical Path}?
  \item Klare Aufgabenverteilung im Team.
    Dabei muss eine faire Verteilung und die Abhängigkeiten beachtet werden.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
590 591
  \item Als Form bietet sich ein GANTT Chart an.
    Verpflichtend ist es aber nicht.
592 593 594 595 596 597 598
    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.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
599 600 601 602
  \item Zu \emph{Beginn} der Implementierungsphase
    beim Betreuer abzugeben.
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
603
\subsection{Bericht}
604 605

\begin{itemize}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
606
  \item Erfahrungsgemäßer Umfang: ca. 20 Seiten
607 608 609 610 611 612 613 614 615
  \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
616 617 618 619 620 621 622 623 624 625 626 627 628 629
\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
630 631 632 633 634 635 636 637 638 639 640 641 642
\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
643
    $\rightarrow$ Java $\rightarrow$ Compiler
Andreas Zwinkau's avatar
Andreas Zwinkau committed
644 645 646
    $\rightarrow$ Errors/Warnings.
    Standardmäßig wird das meiste ignoriert.
    Beispielsweise kann man aktivieren,
Andreas Zwinkau's avatar
Andreas Zwinkau committed
647 648
    eine Warnung anzuzeigen wenn eine Klasse \texttt{equals} überläd
    aber nicht auch \texttt{hashCode}.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
649 650 651 652 653 654 655 656 657 658 659 660 661
  \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
662 663 664 665
  \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
666 667
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
668 669 670 671 672 673 674 675 676 677 678
\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
679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705
\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
706
Man sieht auch das kontinuierliche Wachstum.}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
707 708
\end{figure}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
709
\newpage
denis.lohner's avatar
denis.lohner committed
710
\section{Qualitätssicherung}
711 712 713 714 715 716

\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
717
\artefakt{Testbericht}
718

719
\begin{itemize}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
720 721 722 723
  \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.
724
  \item Komplette Testszenarien aus dem Pflichtenheft durchgehen.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
725
    Ein Testdurchlauf sollte möglichst automatisch ablaufen.
726
  \item \href{http://developer.android.com/tools/help/monkeyrunner_concepts.html}{Monkey Testing}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
727
    für einfaches GUI testen.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
728
    Der Ertrag ist erfahrungsgemäß nicht sehr groß,
Andreas Zwinkau's avatar
Andreas Zwinkau committed
729
    also nicht zuviel Aufwand hineinstecken.
730
  \item \href{http://developer.android.com/tools/debugging/improving-w-lint.html}{Lint}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
731 732
    und andere statische Werkzeuge recherchieren.
    Codequalität kann gar nicht gut genug sein.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
733
    Ein weiteres Tool wäre \href{http://www.sonarqube.org/}{SonarQube}.
Andreas Zwinkau's avatar
Andreas Zwinkau committed
734 735 736 737 738 739 740 741
  \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
742
    Schema im Bericht: Fehlersymptom, -grund und -behebung
743 744
\end{itemize}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769
\section{Interne Abnahme}

Von der Phaseneinteilung gehört die interne Abnahme zur Qualitätssicherung.
Terminlich ist sie entweder zusammen mit dem Kolloquium der Qualitätssicherung
oder kurz danach.

Vollständigkeit ist das wichtigste.
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}
  \item Source-code (TeX,Java,Makefile,C++,Python,HTML,etc)
    Vermutlich einfach der Inhalt eures Versionskontrollsystems.
  \item Artefakte (Compiliertes Programm, Dokumente, etc)
    Zwischenstufen (TeX .aux Dateien) kann man sich sparen,
    andererseits sind die auch nicht so groß.
\end{itemize}

Außerdem ist das der Zeitpunkt wo euer Betreuer
zum letzten Mal euer Produkt testet.
Falls es aufwendiger ist es lauffähig zu bekommen
(bspw. auf ein Androidgerät laden)
am einfachsten ein Gerät mit fertiger Software mitbringen.

770
\newpage
Andreas Zwinkau's avatar
Andreas Zwinkau committed
771
\section{Abschlusspräsentation}
denis.lohner's avatar
denis.lohner committed
772

773 774 775 776
\dictum[George Torok]{
We love to hear stories. We don’t need another lecture. Just ask kids.
}

777 778
\artefakt{Präsentationsfolien}

Andreas Zwinkau's avatar
minors  
Andreas Zwinkau committed
779 780
Showtime!

781 782 783 784 785 786 787
\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.

788 789 790
Allerdings soll es kein reiner Werbevortrag sein,
schließlich präsentiert ihr trotzdem vor akademischem Publikum.
Es sollten auch folgende Informationen in den Vortrag:
791 792 793
\begin{itemize}
  \item Kurze Statistik:
    Wieviel Zeilen Code, wieviele Commits und Tests, wieviel Überdeckung?
794 795 796 797
  \item Einblick in die Softwaretechnik:
    Interessante Fakten aus den vorherigen Phasen.
    Kernkomponenten skizzieren.
    Wie fandet ihr \enquote{Wasserfall mit Rückkopplung}?
798 799 800 801 802 803
  \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
804 805 806 807
  \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
808 809
  \item Welche Tools hab ihr für die verschiedenen Aufgaben benutzt
    und wie gut fandet ihr sie?
810
  \item Zeitrahmen sind 15 Minuten plus Fragen.
811 812 813 814 815 816 817 818 819
\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.

820 821 822 823 824 825 826 827 828
\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}

829
\newpage
830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845
\section{Probleme im Team}

Am schönsten ist PSE wenn alle Teammitglieder hochmotiviert sind,
so dass alle ihren Beitrag leisten.
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.

846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871
\subsection{Wie vermeidet man Probleme?}

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

\begin{itemize}
  \item Welche Note / Teilnote erwarte ich?
    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?}

872 873 874 875
Häufigstes Problem ist,
dass ein oder mehrere Teammitglieder kaum mithelfen.
Die Aufgabenverteilung wird unfair
und diejenigen die die Arbeit machen sind frustriert.
876

877 878
Wichtig ist als erstes Fakten zu sammeln und aufzuschreiben.
Wer hat wann welche Aufgabe mit welcher Deadline zugeteilt bekommen?
879
Wer hat wann wieviel Stunden gearbeitet?
880
Welche Deadlines wurden wie schlecht oder gar nicht eingehalten?
881 882 883
Man braucht konkreten Fakten.
Die Aufgabenverteilung kann der Phasenverantwortliche kontrollieren.
Stundenzettel muss jeder für sich führen.
884 885 886 887 888 889 890 891 892 893 894 895 896

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.

897
\newpage
Andreas Zwinkau's avatar
Andreas Zwinkau committed
898 899 900 901 902 903 904 905 906 907
\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?
908 909 910
    \hfill\fbox{\begin{minipage}{1cm}
    \hspace{0.4cm}\vspace{10pt}
    \end{minipage}}
Andreas Zwinkau's avatar
Andreas Zwinkau committed
911 912 913
  \item Warum in Frage 1 genau diese Zahl?
\end{enumerate}

Andreas Zwinkau's avatar
Andreas Zwinkau committed
914 915 916 917 918 919 920 921
\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
922
\end{document}