Praxis der Software-Entwicklung/Tipps und Tricks

Aus SDQ-Wiki
Tipps und Tricks Dies ist eine unverbindliche Sammlung von Hilfestellungen für Studierende der Lehrveranstaltung Praxis der Software-Entwicklung (PSE).

Werkzeuge

Git

Zur Versionsverwaltung verwenden wir git.

LaTeX

Schreiben und Vortragen

Phasendokumente

Kolloquien

  • Ein Kolloquium (=Vorstellung der Ergebnisse einer Phase) dauert üblicherweise 10–15 Minuten (die Betreuenden legen dies üblicherweise fest).
  • Beachten Sie unsere Vortragshinweise.
  • Die Vorlage für Präsentationen kann für die Kolloquien verwendet werden.
  • Präsentationsfolien sind nicht unbedingt bei allen Kolloquien notwendig. Der Vortrag muss jedoch strukturiert sein und nicht nur aus einem "Drüberscrollen" des Phasendokuments bestehen.

Pflichtenheft

Artefakte
  • PDF-Dokument
Umfang ca. 40 Seiten
  • Das Standardwerk Lehrbuch der Softwaretechnik von Helmut Balzert gibt hilfreiche Hinweise zur Erstellung von Pflichtenheften. (Kostenlos verfügbar mit KIT-Anmeldung/aus dem KIT-Netzwerk)
  • Das fertige (Software-)Produkt wird am Ende der gesamten Entwicklung am Pflichtenheft gemessen. Stellen die Auftraggebenden zu große Unterschiede fest, werden sie nicht bezahlen.

Generelle Anforderungen an das Pflichtenheft

  • Schon das Pflichtenheft muss es den Lesenden ermöglichen, eine exakte Vorstellung des fertigen Produkts zu bekommen.
  • Insbesondere müssen alle Produktfunktionen und -daten genannt und hinreichend genau beschrieben werden.
  • 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.
  • (G)UI-Entwürfe sind Pflicht, Bedienelemente müssen erklärt sein (z.B. Menüführung), und die Lesenden müssen durch das Pflichtenheft wissen, wie sie das fertige Produkt verwenden können.
  • 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.
  • Das Pflichtenheft sollte auch von nicht technisch versierten Menschen zu großen Teilen verstanden werden können. Am besten jemand fachfremdem zum Lesen geben und danach Verständnisfragen stellen.
  • Das Pflichtenheft ist das entscheidende Dokument zwischen Kunde und Entwickler am Ende eines Projekts. Es darf keinen Spielraum für Interpretationen offen lassen.

Definition von Kriterien

Musskriterien

  • Mindestanforderungen, gehen aus Aufgabenstellung hervor.
  • Diese müssen im fertigen Produkt implementiert sein, und reichen i.d.R. zum Bestehen von PSE.
  • Möglichst klein halten.

Wunschkriterien

  • Von den Gruppen selbst definierte, zusätzliche Funktionalität.
  • 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.

Abgrenzungskriterien

  • Was unterstützt unser Produkt explizit nicht?

Struktur

Als erweitertes Lastenheft enthält das Pflichtenheft zusätzlich

  1. Produktumgebung
  2. Testfälle
  3. 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 Entwurfs).

Die Struktur aus SWT1/dem Buch von Balzert (s.o.) muss nicht exakt übernommen werden. Sinnvolle Änderungen könnten sein:

  • Reihenfolge der Kapitel verändern, so dass es flüssiger von vorne nach hinten gelesen werden kann.
  • Kapitel, die im Kontext des eigenen Projektes keinen Sinn machen oder übermäßig redundant werden würden, können potenziell weggelassen werden. Eventuell kann es auch sinnvoll sein, Kapitel zusammenzufassen.
  • Funktionale Anforderungen von Muss- und Wunschkriterien mischen oder nach Programmbereich aufteilen und stattdessen durch Layout, Stil, Marker, Icons entsprechend kennzeichnen.
  • 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. Auch Bilder und Grafiken sind erlaubt.
  • 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 erwartete Reaktion des Programms sein. Diese Testfallszenarien eignen sich als Startpunkt für den Entwurf, und werden bei der internen Abnahme benutzt um das Produkt zu validieren.

Beispiel für Testfallszenario:

T1337 Einloggen

    • Stand: Offenes Browserfenster.
    • Aktion: Benutzer gibt facebook.com in die Kopfzeile ein und drückt Enter.
    • Reaktion: Der Browser wechselt zur Facebook-Frontseite.
    • Stand: Facebook-Frontseite ist geladen. Loginmöglichkeit oben rechts.
    • Aktion: Benutzer gibt zuckerberg@facebook.com als Email und admin als Passwort ein. Dann klickt der Benutzer auf den Log In-Knopf.
    • Reaktion: Erfolgreich eingeloggt. Der Browser wird zur Newsfeedseite des Benutzers umgeleitet.

GUI-Entwürfe

  • Inkscape ist ein freies Vektorzeichenprogramm
  • Pencil ist ein Open-Source-Tool für GUI-Prototyping
  • Online-Plattformen:
  • Die Android Developer Tools enthalten einen grafischen UI Builder
  • Handgezeichnete Entwürfe sind möglich

Präsentation

  • Beachten Sie auch unsere Vortragshinweise.
  • Die Präsentation kann nicht das komplette Pflichtenheft abdecken, da dies in den 10–15 Minuten nicht möglich ist.
  • Die Vortragenden sollen sich auf Aspekte fokussieren, die technisch interessant sind, die das Produkt von anderen abheben, und über die im Entstehungsprozess kontrovers diskutiert wurde.

Mögliche Struktur

  1. Kurze Einführung zur Aufgabenstellung
  2. Überblick über die wichtigsten Features
  3. Grundsätzliche selbst gesetzte Rahmenbedingungen
  4. Ein Testfallszenario als anschauliches durchgehenden Beispiel

Entwurf

Artefakte
  • PDF-Dokument mit UML-Diagrammen
  • Klassenbeschreibungen
  • Erläuterungen
  • Entwurfsentscheidungen
  • evtl. großformatiges Klassendiagramm

Inhalt

  • Erfahrungsgemäßer Umfang:
    • 100 Seiten, primär Klassenbeschreibungen
    • 40–80 Klassen ohne Interfaces
  • Einleitung mit grobem Überblick.
    • Dieser Abschnitt soll an das Pflichtenheft anschließen und die Aufteilung in die Pakete erklären.
  • Änderungen zum Pflichtenheft, z.B. gekürzte Wunschkriterien.
  • Detaillierte Beschreibung aller Klassen
    • Das beinhaltet (JavaDoc) Beschreibungen zu allen Methoden, Konstruktoren, Packages und Klassen.
    • Was hier nicht reingehört, sind private Felder und Methoden; dies sind Implementierungsdetails.
  • Diagramme
    • Generell sollten Diagramme verwendet werden, wenn sich dadurch etwas besser (=kompakter, leichter verständlich, präziser) als in Fließtext ausdrücken lässt.
    • Standardisierte Diagramme (UML, SysML, Entity-Relationship, Fundamental modeling concepts, …) sind nicht-standardisierten vorzuziehen
      • Falls ein nicht-standardisiertes Diagramm verwendet wird, muss die Bedeutung der Elemente durch eine Legende definiert werden
      • Nicht-standardisierte Diagramme müssen i.A. nur sehr selten verwendet werden.
      • Alleine in UML sind 14 Diagrammtypen definiert, die viele Anwendungsfälle abdecken.
    • Es gibt keine Mindest- oder Höchstanzahl von Diagrammen für das Entwurfsdokument. Die Betreuenden bewerten das Dokument nicht nach Anzahl der Diagramme, sondern danach, ob diese sinnvoll eingesetzt sind.
  • Beschreibung von charakteristischen Abläufen anhand von Sequenz- oder Aktivitätsdiagrammen.
    • Beispielsweise bieten sich Testszenarien aus dem Pflichtenheft hier an.
    • Wir empfehlen, diese Diagramme möglichst früh zu erstellen, denn dabei werden die Schnittstellen zwischen Packages und Klassen klar.
  • Mit Blick auf den Implementierungsplan:
    • Aufteilung in Klassen/Pakete, die unabhängig voneinander implementiert und getestet werden können.
  • Vollständiges großformatiges Klassendiagramm im Anhang.
    • Ausschnitte/Teile können bereits vorher verwendet werden.
    • Assoziationen zwischen Klassen dabei bitte mit entsprechenden Pfeilen darstellen, statt nur durch Feldtypen.
    • Programmiersprachentypische Funktionen für Attribute (z.B. getter/setter in Java) sollten weggelassen werden, um die Übersicht zu erhöhen.
  • Identifikation von Entwurfsmustern, um die Struktur gröber zu beschreiben.

Unserer Erfahrung nach ist die Entwurfsphase die schwierigste, da Studierende hier so gut wie keine Erfahrung haben (im Gegensatz zur Implementierungsphase). Deswegen hier ein paar konkrete Schritte, die helfen sollen, einen Anfang zu finden.

  1. Sucht alle relevanten Substantive im Pflichtenheft heraus. Viele davon lassen sich direkt als Klassen abbilden. Zum Beispiel: Button, Level, Spielfigur, Bild, etc.
  2. Was kann man mit diesen Objekten tun? So erhält man die Methoden. Beispielsweise kann man ein Bild drehen, anzeigen und umfärben.
  3. 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.
  4. Spielt die Testfallszenarien durch. So finden sich noch fehlende Methoden und Assoziationen. Außerdem könnt ihr dabei schon die ersten Sequenzdiagramme sammeln.
  5. Organisiert die Klassen sinnvoll in Gruppen. So erhält man die Paketstruktur. Beispielsweise Model-View-Controller könnte hier sichtbar werden.
  6. 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.
  7. Nun ist die erste Woche rum. Man hat einiges an Material produziert und kann es dem Betreuer zeigen.
  8. 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.
  9. 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.
  10. 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.
  11. 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 noch einmal die Testfallszenarien aus dem Pflichtenheft vor und geht diese anhand des Klassendiagramms detailliert durch. Wer ruft wen mit welchen Argumenten auf? Üblicherweise fallen dabei viele Details auf, wo man mehr Informationen weitergeben muss.
  12. Auch nicht zu vergessen sind Dinge die nicht im UML auftauchen. Bilder, SQL-Schema, JSON-Schema, Tools wie ein Leveleditor, etc.
  13. 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.

Bewertung eines Entwurfs

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

  • 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.
    • 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 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. Unmodifiable View Collections.
  • 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.
  • 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.
    • Siehe auch Law of Demeter.
  • 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.
  • Klassen/Pakete sind gleichzeitig erweiterbar und stabil?
    • Erweiterbarkeit bei stabilem Interface ist der große Vorteil von objekt-orientiertem gegenüber prozeduralem Entwurf, der durch Vererbung und Polymorphie erreicht wird.
    • Siehe auch Open-Closed Principle.
  • Liskovsches Substitutionsprinzip bei Vererbung erfüllt?
    • Unterklassen sollten alle Nachbedingungen und alle Invarianten der Oberklasse erfüllen.
    • Andernfalls könnte es zu Fehlern kommen, wenn eine Unterklasse als Oberklasse verwendet wird.
  • 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.
  • 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: Observer, Visitor, Strategy
  • Lokalitätsprinzip beachtet?
    • Eine Änderung der Spezifikation sollte nur lokale Änderungen benötigen.
    • Das impliziert: Eine Klasse/Paket/Methode sollte für sich verständlich sein, ohne dass Kontext notwendig ist.
  • Sind Methoden frei von unerwarteten Nebenwirkungen?
    • 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 Command-query separation

Ä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 Beispiele, die in vergangenen PSE-Projekten auftraten:

  • God Object
    • Wenn zuviel Funktionalität in eine Komponente (Klasse) gesteckt wird.
    • Es verletzt Lokalitäts- und Geheimnisprinzip.
  • Anemic domain model
    • Wenn das Model praktisch nur noch Datenspeicher ist.
    • Objekt-orientierter Entwurf zeichnet sich gerade dadurch aus, dass Daten und Verarbeitung in Objekten zusammengebaut werden.
    • Objekte, die nur zur Datenhaltung da sind, erzwingen prozedurale Programmierung.
  • switch und instanceof.
    • Sieht man im Entwurf zwar noch nicht direkt, ist aber manchmal absehbar.
    • Dynamische Bindung ist meistens die bessere Wahl.

Implementierung

Artefakte
  • Implementierungsplan (zu Beginn)
  • Implementierungsbericht (PDF-Dokument)
  • vollständiger Quellcode
Umfang 20 Seiten (Bericht)

Plan

  • Klarer zeitlicher Ablauf der Implementierungsphase, um frühzeitig Verzögerungen zu bemerken.
  • Abhängigkeiten aus dem Entwurf müssen beachtet werden. Wo ist der Critical Path?
  • Wie können Teile der Anwendung möglichst früh getestet werden? Braucht es dafür Stub-/Mock-Klassen?
  • Klare Aufgabenverteilung im Team. Dabei muss eine faire Verteilung und die Abhängigkeiten beachtet werden.
  • Als Form bietet sich ein GANTT Chart an, wie das Beispiel unten. Verpflichtend ist es aber nicht. Zum Beispiel lässt sich auch eine Tabelle oder … benutzen.
  • 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.
  • Zu Beginn der Implementierungsphase (d.h. nach 1-2 Tagen) beim Betreuer abzugeben.
Jede einzelne Klasse ist als Aufgabe eingetragen. Abhängigkeiten sind als Pfeile erkennbar. Der kritische Pfad ist in rot gekennzeichnet.

Bericht

  • Erfahrungsgemäßer Umfang: ca. 20 Seiten
  • Einleitung mit Anschluss auf Pflichtenheft und Entwurf
  • Dokumentation über Änderungen am Entwurf, 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.
  • Welche Muss- und Wunschkriterien sind implementiert?
  • Welche Verzögerungen gab es im Implementierungsplan? Kann beispielsweise als zweites GANTT Diagramm am Ende dargestellt werden.
  • Übersicht zu Unittests

Unit-Tests

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

Sonstiges

  • 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.
  • Warnungen anschalten.
    • In Eclipse kann man zusätzliche Warnungen anschalten: Project properties → Java → Compiler → Errors/Warnings.
    • Standardmäßig wird das meiste ignoriert.
    • Beispielsweise kann man aktivieren, eine Warnung anzuzeigen wenn eine Klasse equals überlädt, aber nicht auch hashCode.
  • Kommentare im Code (also nicht API Doku) sollten das Warum klären, nicht das Wie.
    • Es ist naturgemäß schwierig vorherzusehen, welche Warum-Fragen sich jemand stellt, der ein Stück Code liest.
    • Die Fragen sind üblicherweise »Warum ist X hier notwendig?«, »Warum ist kein X hier?« oder »Warum X, wobei Y doch besser wäre?«
  • Exceptions (nicht RuntimeException) für Fehler beim Aufrufer.
    • Assertions für interne Konsistenzfehler bzw. um Annahmen explizit zu machen.
  • Keine Magic Numbers.
    • Explizite Zahlen im Quellcode sind entweder selbsterklärend oder durch benannte Konstanten zu ersetzen. Am besten immer letzteres.

Inhalt der Präsentation

  • Was wurde implementiert? Welche Wunschkriterien gestrichen?
  • Zeitplan eingehalten? Wo nicht?
  • Unerwartete Probleme bei der Implementierung?
  • Größere Änderungen am Entwurf?
  • Grobe Statistiken:
    • Lines of Code
    • Wieviele Commits
    • Arbeitsaufteilung im Team
  • Entwicklungsmodell
    • Wie wurde im Team kommuniziert?
    • Wie wurde Git benutzt:
      • Gab es Feature-Branches?
      • War das Mergen in den master-Branch beschränkt?
      • …

Qualitätssicherung

Artefakte
  • Testericht (PDF-Dokument)
Umfang ca. 10–20 Seiten
  • Überdeckung der Unittests maximieren.
    • (Siehe bspw.: JaCoCo)
    • Wenn GUIs im Spiel sind, ist 100 % Überdeckung üblicherweise nicht möglich, aber 90 % sollten schon angestrebt werden.
  • Komplette Testszenarien aus dem Pflichtenheft durchgehen.
    • Ein Testdurchlauf sollte möglichst automatisch ablaufen.
  • Monkey Testing für einfaches Testen der GUI. Der Ertrag ist erfahrungsgemäß nicht sehr groß, also nicht zuviel Aufwand hineinstecken.
  • Lint und andere statische Werkzeuge recherchieren.
    • Codequalität kann gar nicht gut genug sein.
    • Ein weiteres Tool wäre SonarQube oder PMD.
  • Hallway Usability Testing.
    • Systematisches Vorgehen ist wichtig, also vorher Fragen, Aufgaben und Umfang festlegen.
    • Qualitative (Interviewzitate) und quantitative (Durchschnitt über alle Tester) Ergebnisse dokumentieren.
  • Alle gefunden Bugs und deren Reparatur dokumentieren.
    • So entsteht der Testbericht am Ende.
    • Schema im Bericht: Fehlersymptom, -grund und -behebung

Interne Abnahme

  • Gemäß der Phaseneinteilung gehört die interne Abnahme zur Qualitätssicherung.
  • Terminlich ist sie entweder zusammen mit dem Kolloquium der Qualitätssicherung oder kurz danach.
  • Hier ist der Code nun endgültig »fertig«.
  • Eure Anwendung wird danach bewertet, was jetzt läuft.
  • Vollständigkeit der Abgabe ist das Wichtigste.
    • Der Sinn dahinter ist, dass euer Betreuer verpflichtet ist, Prüfungsunterlagen fünf Jahre lang aufzubewahren.
    • Da niemand so genau weiß, was das im Fall von PSE bedeutet, wird am einfachsten alles archiviert:
      • Sourcecode (TeX, Java, Makefile, C++, Python, HTML, etc.): vermutlich einfach der Inhalt eures Versionskontrollsystems.
      • Artefakte (compiliertes Programm, Dokumente, etc.).
      • Zwischenstufen (z.B. .aux Dateien von LaTeX) kann man sich sparen, andererseits sind die auch nicht so groß.

Außerdem ist das der Zeitpunkt, zu dem 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.

Abschlusspräsentation

Artefakte
  • Präsentationsfolien
Umfang ca. 15 Minuten Präsentation

Inhalt

  • Wichtigster Inhalt ist »das, was rauskam«.
  • Präsentiert eure Applikation.
  • Das darf so kreativ sein, wie ihr euch traut – von der Livedemo bis zum Theaterspielen ist alles erlaubt.
  • Allerdings soll es kein reiner Werbevortrag sein, schließlich präsentiert ihr trotzdem vor akademischem Publikum.
  • Es sollten auch folgende Informationen in den Vortrag:
    • Kurze Statistik: Wieviel Zeilen Code, wieviele Commits und Tests, wieviel Überdeckung?
    • Einblick in die Softwaretechnik:
      • Interessante Fakten aus den vorherigen Phasen.
      • Kernkomponenten skizzieren.
      • Wie fandet ihr Wasserfall mit Rückkopplung?
    • 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.
    • 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?
    • Welche Tools hab ihr für die verschiedenen Aufgaben benutzt und wie gut fandet ihr sie?
    • Zeitrahmen sind 15 Minuten plus Fragen.

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.

Wie bereits gesagt, seid ihr nicht gezwungen den KIT-Folienstil zu verwenden, könnt aber (siehe Dokumentvorlagen). Lasst euch stilistisch also woanders inspirieren.

Links

Probleme im Team

Am schönsten ist PSE, wenn alle Teammitglieder hochmotiviert sind, sodass 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.

Wie vermeidet man Probleme?

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

  • Welche Note/Teilnote erwarte ich? Ist eine 1,0 das klare Ziel oder bin ich schon mit 1,7 zufrieden?
  • Welche Aufgaben müssen zu welchen Deadlines erledigt sein? Sollte der Phasenverantwortliche wöchentliche Deadlines festlegen?
  • Wie hart darf man mich kritisieren? Studenten kommen oft aus sehr unterschiedlichen Kulturen, wo Fleiß, Ehre, Respekt oder Pünktlichkeit ganz anders bewertet werden.
  • 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.

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

Was tun bei Problemen?

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

Wichtig ist es dann, als erstes Fakten zu sammeln und aufzuschreiben:

  • Wer hat wann welche Aufgabe mit welcher Deadline zugeteilt bekommen?
  • Wer hat wann wieviel Stunden gearbeitet?
  • Welche Deadlines wurden wie schlecht oder gar nicht eingehalten?

Man braucht konkrete Fakten. Die Aufgabenverteilung kann der Phasenverantwortliche kontrollieren. Stundenzettel muss jeder für sich führen. 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.

Feedback an das Orga-Team

Wir möchten immer gerne wissen, was wir bei PSE in kommenden Semestern besser machen können. Auch weitere Tipps und Tricks für diese Seite nehmen wir gerne entgegen. Das Orga-Team erreicht Ihr unter pse-orga@lists.kit.edu.

Abgerufen von „https://sdq.kastel.kit.edu/mediawiki-sdq-extern/index.php?title=Praxis_der_Software-Entwicklung/Tipps_und_Tricks&oldid=35719“