• Teilaufgabe 0 - Hardware und Software
• Teilaufgabe 1 - Projektmanagement organisieren
• Teilaufgabe 2: Anforderungsanalyse (Dokumentation)
• Teilaufgabe 3: Entwurf (Dokumentation)
• Teilaufgabe 4: Implementierung und Test
• Teilaufgabe 5: Zwischenpräsentation
  • Hinweise & Tricks zur Präsentation:
• Teilaufgabe 6: Abnahme

Im Software Projekt soll ein Verständnis für die Probleme und Herausforderungen bei der Entwicklung großer Software Systeme entwickelt werden. Aus diesem Grund wird im Laufe des Jahres ein komplexes Softwaresystem in mehreren vollständigen Phasen (sog. Sprints) erstellt.

Dabei müssen neben der eigentlichen Softwareentwicklung auch eine Planung und Organisation erfolgen, die Ergebnisse dokumentiert werden und präsentiert werden.

Die Aufgabe umfasst dabei i.d.R. die Adaption eines Brettspiels. Eine Liste mit allen bisher im Softwareprojekt umgesetzten Spiele ist hier zu finden.

Teilaufgabe 0 - Hardware und Software

• Hardware: ARBI: Cluster (FreeBSD), eigene Notebooks
• Software
  • Java Entwicklungsumgebung
    • IntelliJ, Eclipse, Netbeans, ...
  • Textverarbeitungssystem LaTeX oder GitLabs
  • UML-Tool: z.B. Visual Paradigm
  • Projektverwaltung mit GitLab
  • Dokumentation von Protokollen (und anderen Dokumenten) in GitLab
  • Versionsverwaltung von Doku und Software mit Git unter Bitbucket: https://git.swl.informatik.uni-oldenburg.de

die Informatik hat eine Visual Paradigm Lizenz.
Zu finden unter:
https://ap.visual-paradigm.com/university-of-oldenburg/\

Die unterschiedlichen Version von VP sind untereinander nicht immer kompatibel. Aus diesem Grund sollten alle immer die selbe Version verwenden!

Teilaufgabe 1 - Projektmanagement organisieren

• Organisieren Sie Ihr Projekt bzw. Team,
  • verteilen Sie in der zweiten Woche die Einzelaufgaben,
  • definieren Sie eine Reihenfolge für die Übernahme der Moderation und des Protokolls (z.B. nach Alphabet)
  • die Tagesordnung ist vom Moderator mindestens einen Tag vorher zu erstellen (dafür ggf. die Gruppe nach weiteren TOPs fragen)
  • definieren Sie Standards für Dokumente (LaTeX, UTF-8, ...)
  • Führen Sie ein Projekttagebuch (als Blog im Wiki)
• Dokumentieren Sie immer alle Ergebnisse der Gruppe, wie
  • Protokolle,
  • Ausarbeitungen,
  • Präsentationen,
  • Software-Dokumente, etc.
• mit einer Zuordnung zu Personen in GitLab
• Geben Sie die Einzelaufgaben an
• Stellen Sie ein Gruppenbild (mit Namen) ein! Ideal ist es für mich und die Tutoren, wenn in dem Bild die Namen direkt als Text enthalten sind.
• Überlegen Sie sich für Ihre Aufgaben eine "Definition of Ready" und eine "Definition of Done", d.h. was muss für eine Aufgabe erledigt sein, bevor sie als erledigt angesehen werden kann. (siehe z.B. https://www.scrum-events.de/was-ist-die-definition-of-done-dod.html)
• Erstellen Sie basierend auf den Vorgaben der Veranstaltung eine Produktvision. (vgl. z.B. https://www.wibas.com/scrum/product-vision/de)

Scrum hat den Nachteil, dass man lange "vor sich hin iterieren" kann. Definieren Sie zusätzliche Meilensteine zu denen bestimmte Funktionen fertig sein sollen. Einige sind vorgegeben (vgl. Meilensteine). Verwenden Sie zur Meilensteindefinition nicht nur die Präsentationstermine!

Teilaufgabe 2: Anforderungsanalyse (Dokumentation)

• Was soll umgesetzt werden? Wie sieht diese Welt aus?
  • Wer sind die Akteure?
  • Welche User-Stories gibt es?
  • Welche nicht funktionalen Anforderungen gibt es?
  • Welche Objekte gibt es: Objektmodell (als Klassendiagramm)
  • Wie interagieren die miteinander (wichtig!): Dynamisches Modell (tyischerweise als Sequenz-, Aktivitäts- oder Zustandsdiagramm)
    • Sequenzdiagramm: Wenn man sehr genau weiß, wie die Abläufe sind
    • Aktivitätsdiagramm und Zustandsdiagramm: Kann erstmal auf einer abstrakten Ebene passieren und später verfeinert werden
• Dokumentation schrittweise  anpassen/erweitern
• Abgabe:
  • Zwischenpräsentation (siehe dort)
  • zum Ende des Projektes finale Version
  • Dokumentation in einem extra Dokument (nicht auf GitLab verweisen).
• Beachten: Anforderungen Dokumentation

Teilaufgabe 3: Entwurf (Dokumentation)

• Zerlegung in Teilsysteme
• Bildung von Modulen (Klassen zu Gruppen zusammenfassen) Kopplung und Kohäsion beachten
• Festlegung der Architektur
• Abbilden auf Hardware
• persistente Datenverwaltung
• Festlegung von Entwurfsmustern
• Make or Buy (Verwendung von Frameworks)
• Dokument: System- und Objektentwurf
• Abgabe:
  • Zwischenpräsentation (siehe dort)
  • zum Ende des Projektes finale Version
  • Dokumentation in einem extra Dokument (nicht auf GitLab verweisen)
• Beachten: Anforderungen Dokumentation

Teilaufgabe 4: Implementierung und Test

• Implementieren Sie Ihr Produkt basierend auf dem Entwurf (passen Sie den Entwurf ggf. an)
• Projektname muss Gruppenname enthalten!

• Maven:

  • Das Produkt muss sich mit Hilfe von maven bauen lassen.
  • Das Bauen muss ohne mvn install funktionieren.
  • Die Tests müssen über maven ausgeführt werden.
  • GUI-Tests müssen sich ausschalten lassen.
  • Andere Build-Tools wie Gradle sind nicht (mehr) erlaubt dürfen maximal ergänzend verwendet werden. Maven muss aber funktionsfähig vorhanden sein.

• Sinnvoll: (echtes) Pairprogramming (mit Tauschen der Rollen!): Hinweise zum Pairprogramming

  • Es gibt ein Plugin für IntelliJ, mit dem man gemeinsam am Code arbeiten kann (habe ich allerdings noch nicht getestet) 
    • Code With Me: "Das kostenlose Plug-in lässt sich direkt aus der Entwicklungsumgebung heraus über Preferences / Settings | Plugins | Marketplace installieren" (https://www.heise.de/news/Entwicklungsumgebung-JetBrains-veroeffentlicht-Plug-in-fuer-Pair-Programming-4915934.html)
• Sinnvoll: längere Programmiersitzungen

• Erstellen Sie dabei die nötigen Systemunterlagen (tw. erst zum Ende des Projektes)

  • Benutzerhandbuch,
  • Testunterlagen,
  • Installationshandbuch etc.

• Vorlesungsvideos u.a. zu Testen. Testen Sie die wichtigen Klassen mit JUnit, nicht erst am ENDE!

  • Hilfreich: Dependency Injection (z.B. Google Guice)
  • TestFX kann beim Testen der GUI helfen. Wichtiger sind aber Tests der Funktionalitäten!
  • Beachten Sie, dass die GUI-Tests normalerweise nicht mit ausgeführt werden sollen, damit die Tests problemlos auch auf einem Build-Server (wie bamboo) ausgeführt werden können.
  • Mocken Sie Abhängigkeiten in Unit-Tests mit Mockito
• Führen Sie Integrations- und Endtests durch
• Führen Sie mindestens ein dokumentiertes gruppenweites Code–Review durch
• Nutzen Sie Tools wie FindBugs, Checkstyle oder SonarLint

• Es ist grundsätzlich nicht erlaubt, Warnungen zu unterdrücken (Wenn Warnungen unterdrückt werden, dann muss es einen sehr guten Grund geben! Jede zusätzliche Warnung muss dokumentiert und begründet sein!)

  

• In Scrum muss ein Produktinkrement getestet und lauffähig sein.
• Versuchen Sie möglichst früh und regelmäßig die aktuelle Version auch auf dem Rechner in der Arbi zu deployen.
• Das MVP sollte "von Hand" erstellt werden und sich nicht auf Tools wie AfterburnerFX abstützen. Die Erfahrung zeigt, dass dies sonst im Laufe der Zeit viele Dinge (insbesondere Tests) unnötig verkompliziert.
• Beachten Sie auch die Hinweise zur Verwendung von KI

Teilaufgabe 5: Zwischenpräsentation

• Zeigen Sie die wesentlichen
  • Konzepte (statisch und dynamisch!)
  • Architektur
  • Software-Design-Entscheidungen (es geht hier nicht um die Grafik und Optik) und
  • die Zusammenhänge (statisch z.B. durch Klassendiagramme und dynamisch z.B. durch Sequenz- oder Aktivitätsdiagramme!)
  • Technologieentscheidungen (hier nicht die Tools wie GitLab, Visual Paragdigm etc., sondern die verwendeten Frameworks!)
  • Grundsätzlich sollte auf die Serverkonzepte vertiefter eingegangen werden als auf Aspekte, die sich auf die GUI beziehen.
  • I.d.R. ist es keine gute Idee, einfach UML-Diagramme, die für die Dokumentation gedacht sind, unverändert in die Folien zu packen, so sollten i.d.R. Klassendiagramme vereinfacht werden.
  • Quellcode kann hin und wieder hilfreich sein, i.d.R. ist es aber besser, die Konzepte auf einer abstrakteren Ebene mit Hilfe von UML darzustellen.
• Erklären (Bilder können helfen):
  • Warum es so ist, wie es ist und warum das gut so ist.
  • Wie können Erweiterungen vorgenommen werden
• Keine Dinge wiederholen, die in diesem Wiki stehen oder das Spiel erklären (kostet nur Zeit)
• Ehrlich bei Fehlern und Problemen sein
• „Knackige“ Online-Demonstration des aktuellen Standes (nicht optional!)
  • mit Moderation,
  • die Demonstration sollte ein Konzept und einen roten Faden haben: Nicht einfach starten und schauen, was passiert.
  • Cheats können helfen, sinnvolle Situationen zum Präsentieren herbeizuführen
  • Es ist wichtig, dass ich der Demonstration folgen kann.
  • Kein Video erstellen, sondern live demonstrieren. Dann kann ich auch mal eingreifen, Fragen stellen und bekomme einen "echteren" Eindruck.
  • Wenn der Start länger dauert (z.B. weil erst IntelliJ gestartet werden muss), bitte dies vor der Präsentationen machen.
• Einschränkungen/Anpassungen/Änderungen nennen
• 20-30 Minuten (sinnvoll füllen)
• Je nachdem, ob online oder in Präsenz (siehe dazu im Stud.IP im Wiki zur Veranstaltung)
  • Präsenz: Nur eine Delegation (max. 3 Personen)
    • Bei der finalen Präsentaiton sollte der Vortragende allerdings stehen.
  • Falls die Präsentation online stattfindet,
    • dürfen natürlich beliebig viele Personen der Gruppe teilnehmen
    • sollten die Vortragenden eine Kamera anmachen (geht z.B. auch mit dem Smartphone als Kamera)
• Es sollten bei jeder Präsentation andere Mitglieder der Gruppe vorstellen. Es müssen aber nicht alle da gewesen sein.

Hinweise & Tricks zur Präsentation:

Um die Qualität der Zwischen- und Abschlusspräsentationen zu erhöhen, wurde zusätzlich zu den o.g. Informationen eine Präsentation erstellt. Diese soll euch ein paar weitere Hinweise und Tricks zur Erstellung geben. 

Bemerkungen: 

• WICHTIG: Vor dem Erstellen von Schaubildern, solltet ihr euch immer fragen, ob dieses einen Mehrwert bietet. Es gibt Fälle wo eine einfache Informationsdarstellung in Textform passender ist. 
• SEHR WICHTIG: Schaubilder sind KEIN Ersatz für Diagramme. Schaubilder werden nicht dafür genutzt um statische & dynamische Modelle zu ersetzen. Sequenz-, Aktivitäts-, Zustands- und Klassendiagramme müssen so erstellt werden, wie in Software Technik gelehrt. 
• Am Ende der Präsentation bitte eine Zusammenfassungs- und Ausblicksfolie.

Teilaufgabe 6: Abnahme

Hier im wesentlichen die selben Dinge beachten wie in der Zwischenpräsentation (mit Ausnahme der letzten vier Spiegelstriche, aber die Darstellung sollte auf das ganze Jahr bezogen sein, d.h. nicht nur zurück bis zur letzten Präsentation, d.h. sollte u.U. auch Dinge enthalten, die bereits in einer der Zwischenpräsentationen gesagt wurden. Es ist auf jeden Fall eine Demo notwendig!

Und zusätzlich:

• d.h. hier auch die wichtigen Konzept, Ideen und Modelle vorstellen
• In der Demo die Registrierung nicht mehr zeigen.
• Screenshots zur Erklärung der wesentlichen Komponenten (bitte hier keine Mockups mehr oder Vorher/Nachherdarstellungen)
• Die Qualitätssicherung:
  • Projektmanagement
  • Testen
• allgemeiner Rück- und Ausblick, aber bitte keinen detaillierten Rückblick auf einzelne Sprints (In Sprint 1 haben wir ... In Sprint 2 haben wir ...)
• Auf eine sinnvolle Auswahl und Gewichtung achten. Wenn Dinge ähnlich sind, besser zusammenfassen, dafür aber wichtige Ideen, verwendete Algorithmen und Konzept vorstellen.
• 60-90 Minuten, typischerweise im OFFIS, falls die Präsentation online stattfinden muss, ist es besser, wenn die Präsentation eher 60 als 90 Minuten ist.
• Alle Mitglieder der Gruppe müssen da sein! Es besteht Anwesenheitspflicht.

Abgabe:

• Bitte: vor der Abnahme die Präsentation als PDF schon einmal in dem Cloud-Ordner hochladen.
• Bis zur Präsentation muss nur die Präsentation fertig sein. Alle andere Dokumente können später erstellt/finalisiert werden.
• Dokumente (als PDF!  Die wichtigen zusammen in einem Ordner und nicht in die VM (s.u.) packen!)
  • Die Dokumentation darf als Export aus dem GitLab generiert werden.
• Der Quellcode
  • braucht nicht abgegeben werden, da er ja in Bitbucket vorhanden ist.
  • muss sich mit Maven automatisiert bauen lassen! Auch die Tests müssen darüber ausführbar sein.  Es muss EIN zentrales Maven-Script geben, welches andere verwendet. (Also so, wie es aktuell im Basisprojekt umgesetzt ist. Bei Änderungen muss hier ggf. eine Anpassung erfolgen)
  • Wichtig! Ich schaue mir nur den Quellcode im MASTER-Branch an, ggf. also auf jeden Fall vor der Abgabe noch einmal in den Master mergen!
  • Die Tests sollten alle ohne externe Datenbank laufen!
• Protokolle, Präsentationen, …
• zusätzlich  virtuelle Maschine (VMWare (mit VMWarePlayer abspielbar!) oder VirtualBox)
  • mit vollständig eingerichtetem lauffähigem Server für mich zum Testen (mit Hinweise zur Verwendung, z.B. mit Readme auf Desktop)
  • ohne Abhängigkeiten nach außen (E-Mail, Datenbank, etc.!). Die DB darf hauptspeicherbasiert (MainMemoryBasedUserStore) sein. 
  • VM sollte den Gruppennamen enthalten
  • keine Dokumente in der VM "verstecken", d.h. die Dokumente zur Abgabe müssen extra abgegeben werden.
  • Es sollte direkt in der VM spielbar sein. (Falls die Umsetzung web-basiert ist muss also auch ein Browser installiert sein (aktuell i.d.R. nicht). Keinen Zugriff mit einem externen Browser!)
  • Die VM sollte nicht zu groß sein! Linux statt Windows kann hier schon viel helfen (Windows ist aber erlaubt)
  • BITTE die VM testen. Insbesondere ob auch alles funktioniert!
  • Es ist erlaubt, die VM in ein Multi-Volume-Archive zu verpacken, falls es Probleme mit dem Upload gibt.
  • Kein Docker, da ich auch meinen Rechner vor der VM absichern muss (Sonst müsste ich einen zusätzlichen Rechner dafür nutzen ... DSGVO)
• 10 Minuten-Video, Format MP4
  • Das Video sollte von nicht deutlich von den 10 Minuten abweichen (10% sind ok)
  • Das Video sollte im MP4-Format vorliegen (falls die Aufnahme z.B. als MOV gemacht worden ist, kann man mit Handbrake (https://handbrake.fr/) oder auch VLC (https://www.videolan.org/vlc/) eine Konvertierung machen).
  • Das Video sollte nicht größer als 100 MB sein, d.h. 1080p ist vollkommen ausreichend (siehe vorherigen Kommentar zum ggf. notwendigen Konvertieren)
  • mit Präsentation des Endproduktes (z.B. mit HyperCam),
  • bitte mit Ton
  • Fokus bitte auf das Spiel
  • Registrierung, Chat, Besonderheiten außerhalb des Spiels etc. max 1 Minute
  • Bitte mit mehreren Spielern spielen
  • Spezielle Spielsituationen (gemäß Regeln) sollten extra dargestellt werden um zu zeigen, wie die Software damit umgeht
  • Damit auch andere Gruppen sehen können, was in den anderen Gruppen gemacht worden ist (auch für die kommenden Gruppen) werden die Videos im Anschluss aller Präsentationen veröffentlicht.
  • Bitte keine Namen oder Bilder von echten Personen im Video verwenden. 

Verwendung der Uni-Cloud (https://cloud.uol.de). Dort bitte alles  zur Verfügung stellen. Dafür haben Sie von mir eine Freigabe erhalten (im internen Wiki). Bitte die Dateien möglichst nicht komprimieren aber möglichst insgesamt nicht mehr als 15 GB verwenden. Bei Problemen mit dem Upload darf die VM auch aufgeteilt (s.o.)