Abgaben

Abgabeform

Alle Abgaben müssen durch einen GIT-'tag' Ihres jeweiligen Team-Repository gekennzeichnet werden. Ein 'tag' dient dazu einen bestimmten Arbeitsstand ihres Repository besonders hervorzuheben. Je Abgabe erstellen Sie bitte einen Unterordner. Die Ordnernamen sollen aufsteigend nummeriert sein und sind entsprechend des Abgabeinhalts zu benennen, z.B. "01_Angebot". Der 'tag', der Ihre Abgabe kennzeichnet, ist ebenfalls nach dieser zu benennen (z.B. "01_Angebot"). Der Ordner enthält alle relevanten Dateien, die in der jeweiligen Abgabe verlangt werden. Bei Dokumenten genügt das PDF (andere Formate sind nicht zulässig), der Latex-Code muss nicht abgegeben werden. Bei der Abgabe der Implementierung muss jedoch auch der Quellcode abgegeben werden.

Der vorgenommene GIT-'tag' ist per E-Mail an die Organisatoren und Tutoren des Praktikums via swtpra-tutor@lists.upb.de mitzuteilen, jeweils bis 18 Uhr des angegebenen Abgabetages. Der Betreff der E-Mail sollte dabei wie folgt aufgebaut sein: "[SWTPra oder SoPra] 2017 - Gruppe XX - Abgabe: [Abgabetyp]". Ein korrekter Betreff wäre beispielsweise "SWTPra 2017 - Gruppe 08 - Abgabe: Pflichtenheft".

Verspätete Abgaben zählen als fehlend und können im Extremfall zum Nichtbestehen des SWTPra/SoPra führen! Ausschlaggebend ist die Zeit des GIT-'tags'.

Zur Erstellung der Dokumente ist die vorgegebene TeX-Vorlage zu verwenden. Die angegebenen maximalen Seitenzahlen umfassen nicht Deckblatt, Inhaltsverzeichnis und Abbildungsverzeichnis.

Protokolle und Studenzettel

Protokolle und Stundenzettel müssen regelmäßig geführt werden und sind Teil der Endabgabe. Vorlagen für Protokolle und Stundenzettel stehen im Dokumente-Bereich zum Download bereit.

Angebot (Deadline: 05.05. 18:00 Uhr)

Inhalt

  • Anschreiben (max. 1 S.)
  • Aufwandsschätzung (max. 1 S.)
  • Projektplan  (max. 1 S.)
  • erklärender Text (max. 2 S.)
  • Verantwortlichkeiten
  • der von Ihnen gewählte Gruppenname und zugehöriges Gruppenlogo

Beispiele

SWTPra-Team 7 (SS 2007)

  • Bemerkung: Hier sind nur das Anschreiben und die Aufwandsschätzung enthalten.
  • Positiv: alle Aufwände mit den zugehörigen Kosten sehr übersichtlich in einer Tabelle dargestellt. Zu allen Arbeitspaketen sind Teilaufgaben aufgelistet. Auch bereits geleistete Arbeit wurde berücksichtigt. Die Arbeitspakete werden zusätzlich textuell beschrieben (die Beschreibung ist allerdings etwas knapp). Anteile der Teilaufgaben am Gesamtaufwand pro Arbeitspaket visualisiert (nicht unbedingt notwendig, Balkendiagramme evtl. übersichtlicher, könnten evtl. weggelassen werden).
  • Negativ: Einige Rechtschreibfehler, Verantwortliche im Team nicht genannt, Arbeitspakete könnten im Text etwas präziser beschrieben werden

SWTPra-Team 3 (SS 2008)

  • Positiv: Guter Stil und professionelle Aufmachung. Die Darstellung ist übersichtlich und klar gegliedert, alle wichtigen Punkte wurden erfasst. Der Projektplan bedient sich der üblichen Notation und führt Daten sowie Abhängigkeiten auf. Die Erklärungen sind detailliert und verständlich, Kontaktdaten wurden angegeben.
  • Negativ: Analyse & Entwurf falsch beschrieben. Dokumentation des Quellcodes wird als Aufgabe aufgeführt, aber nicht klar in der Aufwandsschätzung angegeben. Einige seltsame Formulierungen stören den ansonsten guten sprachlichen Eindruck.

SWTPra-Team 1 (SS 2009)

  • Positiv: Sehr professionelle Gestaltung und übersichtliche Darstellung. Der Projektplan bedient sich der üblichen Notation und führt Daten sowie Abhängigkeiten auf. Die Erklärungen sind detailliert und verständlich, Kontaktdaten wurden angegeben.
  • Negativ: Der Zeitaufwand und die Erstellung des Wegfindungsalgorithmus werden im Anschreiben nicht erwähnt.

Hinweis: Für das Angebot ist die Verwendung der TeX-Vorlage nicht erforderlich. Das Angebot kann auch mit einer beliebigen Office-Software erstellt werden, muss aber dennoch in PDF-Form abgegeben werden.

Pflichtenheft

Inhalt 

Das Pflichtenheft ist eine vertraglich bindende Beschreibung des vom Auftragnehmer zu erstellenden (Software-)Produkts. In diesem Dokument sollen die Anforderungen an das Produkt beschrieben werden und wie der Auftragnehmer plant, diese Anforderungen zu realisieren. Es ist daher zu beschreiben welches Problem aktuell besteht und was das Produkt leisten soll um dieses zu beheben. Dabei sollte nicht zu detailliert auf die Lösung eingegangen werden, dies geschieht im Analyse&Entwurf-Dokument.

Das Pflichtenheft sollte folgende Punkte enthalten (nicht zwangsläufig in dieser Reihenfolge):

Zielbestimmung

  • Motivation für das Produkt (nicht zu allgemein, nicht zu technisch)
  • Hauptaufgabe des Produkts
  • Ziele der Entwicklung (inkl.  Alleinstellungsmerkmale und Prioritäten)
  • Zielgruppe des Produkts (so konkret wie möglich beschreiben)
  • ggf. optional geplante Funktionen
  • typischerweise nur Fließtext

Produkteinsatz

  • Beschreibung des Problembereichs (IST-Zustand)
  • Definition von Begriffen des Problembereichs. Optional: Glossar
  • Modell des Problembereichs

    • Struktur des Problembereichs
    • (Geschäfts-)Prozesse oder Szenarien im Problembereich, d. h. ein Modell der typischen Abläufe im Problembereich.
    • Die Beschreibung des Problembereichs kann durch den Einsatz geeigneter Bilder und UML-Diagramme unterstützt werden.

Produktfunktionen

  • Beschreibt, was das Produkt leisten soll
  • Use-Cases und deren Abläufe

    • Beschreibung von Standardabläufen bei Benutzung der Funktionen
    • Beschreibung von wichtigen alternativen Abläufen oder Fehlerfällen

  • Die Beschreibung kann textuell oder tabellarisch erfolgen und durch den Einsatz geeigneter UML-Diagramme unterstützt werden.
  • Skizzen von Benutzeroberflächen

Produktcharakteristiken

  • Beschreibt wie die Software etwas leisten soll. (Produktcharakteristiken werden manchmal auch "nicht-funktionale Anforderungen" genannt. Beispiele sind z. B. Performanz, Benutzerfreundlichkeit, Erweiterbarkeit, ...).
  • Es sollte begründet werden, warum welche Produktcharakteristiken für das Produkt in seiner Umgebung wichtig sind. (Der Auftragnehmer kann über seine Einschätzung auch vor der Abgabe des Pflichtenhefts mit dem Auftraggeber (d. h. Tutor) Rücksprache halten.)
  • Produktcharakteristiken müssen messbar sein, sodass deren Einhaltung validiert werden kann. Deren Einhaltung wird später in der Endabgabe evaluiert.
  • Systemvoraussetzungen (vorgegebene und selbst definierte) an die Hardwareplattformen, die Software und an die Orgware.

Umfang des Pflichtenhefts

Das Pflichtenheft sollte folgenden Umfang haben:

  • SWTPra: 30 bis 50 Seiten
  • SoPra: 15 bis 30 Seiten

Beispiele

SWTPra-Team 6 (2012)

  • Pflichtenheft insgesamt vollständig
  • Zielbestimmung: Terminologie nicht konsistent zum Lastenheft; Zielgruppe hätte genauer beschrieben werden können.
  • Produkteinsatz: Im Modell des Problembereichs fehlt eine Spielfläche für jeden Spieler; Übersicht der Geschäftsprozesse wäre vorteilhaft
  • Produktfunktionen: (Use-Case Abb. 7) Der Beobachter verwendet den Use-Case "Spiel durchführen", wird bei diesem Fall aber nicht betrachtet. Warum müssen beim "Turnier einrichten" Punktestände berechnet werden? Hinweis: Ablauf in Abb. 10 überdenken, da auch sofort geprüft werden könnte, ob ein Spiel läuft. Die Betrachtung der KI fehlt z.B. in "Spiel durchführen". Abb. 11 ist sehr unübersichtlich.

  • Bieter Betrag festgelegt, auf wen?
  • Produktcharakteristiken: Erweiterung zum Lastenheft (könnte aber noch mehr sein). Teilweise sind es keine nicht-funktionalen Anforderungen; Es ist nicht definiert, wie die Produktcharakteristiken gemessen werden können.

  • Glossar ist uneinheitlich

SoPra-Team 4 (2012) 

  • Bei der Zielbestimmung fehlte Beschreibung der Zielgruppe
  • Bei den Geschäftsprozessen fehlen Beobachter, Turnier und Bieter
  • Produkteinsatz: Gut, nur sollte die GUI nochmal überdacht werden. Zum Beispiel gibt es eine mehrfache Anzeige von Spielfeldern.
  • Produktfunktionen: Alles gut.
  • Nur sehr wenige nichtfunktionale Anforderungen.
  • Es ist nicht definiert, wie die Produktcharakteristiken gemessen werden können.
  • Fazit: Dokument gelungen aber Produktcharakteristiken nur sehr minimal

SWTPra-Team 1 (2009)

  • Bemerkung: Dieses Jahr gibt es keinen Teil zum Reverse-Engineering. Das Deckblatt wurde anonymisiert.
  • Positiv: Die Zielbestimmung enthält alle wesentlichen Inhalte und hat das richtige Abstraktionsniveau. Der Produkteinsatz enthält ein gutes Modell des Problembereichts (MdP) mit einer umfangreichen Beschreibung und sinnvollen Geschäftsprozessen.In den Produktfunktionen wurden die Use-Cases aus dem Lastenheft sinnvoll verfeinert und gute GUI-Skizzen eingefügt. 
  • Negativ: Die Paketdiagramme im Reverse-Engineering Teil sind zu detailliert für ein Pflichtenheft. Die Beschreibung der Dateiformate in den Produktdaten ist zu ausschweifend.

SoPra-Team 13 (2009)

  • Bemerkung: Dieses Jahr gibt es keinen Teil zum Reverse-Engineering. Das Deckblatt wurde anonymisiert.
  • Positiv: Klare und verständliche Zielbestimmung auf dem richtigen Abstraktionsniveau. Für das MdP wurde im Produkteinsatz das richtige Abstraktionsniveau gewählt. Die Darstellung ist in korrekter UML-Notation. Wesentliche Abläufe werden mit Geschäftsprozessen dargestellt. Die Use Cases aus dem Lastenheft wurden sinnvoll im Abschnitt Produktfuntionen verfeinert. Eine gute GUI-Skizze veranschaulicht die zu erstellende Benutzeroberfläche.
  • Negativ: keine.

SoPra-Team 2 (2014)

  • Bemerkung: Das Deckblatt wurde anonymisiert.
  • Positiv: Sehr gute und nachvollziehbare Gliederung (GUI-Skizzen sind bspw. im jeweiligen Use-Case direkt erläutert). Viele sinnvolle nichtfunktionale Anforderungen, die gut erklärt werden. Es sind gute Erläuterungen zu jeder Abbildung vorhanden, die für das Verstehen der Diagramme relevante Informationen beinhalten.
  • Negativ: Zielgruppe zu allgemein beschrieben. Das MdP könnte etwas detaillierter sein und es fehlen Leserichtungen bei den Assoziationen.

SWTPra-Team4 (2014)

  • Bemerkung: Das Deckblatt wurde anonymisiert.
  • Positiv: Diagramme und Tabellen kurz aber treffend erläutert. Nichtfunktionale Anforderungen sind umfangreich und sinnvoll.
  • Negativ: Einige Begriffe wie Client, Nutzer oder Host wurden mehrdeutig verwendet und auch nicht eindeutig im Glossar definiert. Bei Use-Cases wurden oftmals in Aktionen Zustände beschrieben oder Vorbedingungen falsch erfasstIm Glossar werden Begriffe mit dem Begriff selbst erklärt. Charakteristische Informationen der Use Cases haben falsche Bezeichnungen (auslösendes Ergebnis statt auslösendes Ereignis) und Vorbedingungen sind nicht ganz korrekt.

Weitere Beispiele befinden sich auf den Seiten der Praktika der vergangenen Jahre.

Analyse- & Entwurfsdokument

Zweck

Das Analyse- & Entwurfsdokument dokumentiert einerseits eine detaillierte Analyse der Anforderungen und des Kontexts der zu entwickelnden Software. Andererseits beschreibt dieses Dokument die Architektur der Software. Es sollte Entwurfsentscheidungen nachvollziehbar dokumentieren und dient als Grundlage für die Implementierung. 

Inhalt

Folgende Abschnitte sollen im Analyse- & Entwurfsdokument enthalten sein. (Die folgenden Punkte sind keine Vorgabe für eine Gliederung.)

Analyse

Darstellung der Architektur auf Komponentenebene

  • zu entwickelnde Komponenten
  • Komponenten des Kontexts (z. B. der zu verwendenden Frameworks)
  • Diagramme: Komponenten(struktur)diagramme, Verteilung, ggf. andere

Schnittstellen und Interaktionen zwischen den Komponenten.

  • Diagramme: Sequenzdiagramme, Aktivitäten, ggf. andere Verfeinerung der Architektur.

Entwurf

Verfeinerung der Architektur (aus der Analyse)

  • Klassen und Schnittstellen, ggf. interne Komponenten
  • Modell/Sicht/Logik trennen
  • Diagramme: Komponenten(struktur), Klassen

Wichtige Abläufe innerhalb der Komponenten

  • Interaktionen zwischen internen Klassen
  • Abläufe von Algorithmen
  • Diagramme: Sequenzdiagramme, Aktivitäten, Zustandsmaschinen, ggf. andere, ggf. Pseudocode

Auch hier gilt: Kein Diagramm ohne erklärenden Text!

Umfang des Analyse- und Entwurfsdokuments

  • SWTPra: 25 bis 40 Seiten
  • SoPra: 20 bis 35 Seiten

Beispiele 

SWTPra-Team 6 (2012)

  • Quellenangaben fehlten
  • Mehr zu den Gründen der Entwurfsentscheidungen wäre wünschenswert gewesen
  • Es fehlten erklärende Einleitungen zu den Abschnitten
  • Einige Grafiken wurden nicht referenziert 

SoPra-Team 4 (2012) 

  • Sehr viele Technologien beschrieben und weniger die Architektur; anderer Fokus war gewünscht
  • Abläufe fehlen beim Modellierer
  • Nicht Use-Case bezogen - Sequenzdiagramm passt nicht zum Klassendiagramm
  • In der KI sind Spezialwaffen, Minen usw. nicht genannt
  • RMI Beschreibung leicht uneindeutig

SoPra-Team 1 (2014)

  • Bemerkung: Das Deckblatt wurde anonymisiert
  • Mehrere Patterns erläutert und Bezug zur Software hergestellt
  • Die Spiel-Engine wurde sehr umfangreich und gut beschrieben
  • Die Komponenten, die gemeinsam genutzt werden, wurden sehr detailliert dargestellt
  • KI-Strategie wurde nicht erläutert
  • Verbindung zum MdP fehlt
  • Kardinalitäten nicht immer klar
  • Qualtitätskriterien fehlen
  • Insgesamt sehr gute Beschreibungen und gut strukturiert

SWTPra-Team 4 (2014)

  • Bemerkung: Das Deckblatt wurde anonymisiert
  • Wichtigste Werkzeuge und Komponenten umfassend und gut erläutert
  • KI wurde sehr ausführlich entworfen
  • Verbindung zum MdP fehlt
  • Qualitätskriterien fehlen

Weitere Beispiele befinden sich auf den Seiten der Praktika der vergangenen Jahre.

Implementierung (Deadline: 23.06. 18:00 Uhr bzw. 21.07. 18:00 Uhr)

Die Abgabe der Messeversion der Implementierung (bis einschl. 23.06.) umfasst

  • für die SWTPra-Gruppen: Die Implementierung des Spielkonfigurators, der Spiel-Engine und des PC-Beobachters
  • für die SoPra-Gruppen: Die Implementierung des  Smartphone-Beobachters und der Spiel-Engine

Die Abgabe der Turnierversion der Implementierung (bis einschl. 21.07.) umfasst

  • für die SWTPra-Gruppen: Die Implementierung des KI-Teilnehmers und des Smartphone-Teilnehmers, welcher aus dem eingekauften Smartphone-Beobachter weiterentwickelt werden sollte.
  • für die SoPra-Gruppen: Die Implementierung des KI-Teilnehmers.

Mit der Endabgabe (24.7.) wird die Implementierung des gesamten Produkts abgegeben (inklusive der nach der Messe integrierten Komponenten).

Zu den Implementierungs-Abgaben gehört zudem eine kurze Benutzeranleitung (in Form eines PDFs) für das Benutzen der Software. In dieser Anleitung sollte unter anderem beschrieben werden

  1. wie der Server gestartet wird.
  2. (nur SWTPra:) wie der Spielkonfigurator gestartet wird.
  3. wie sich Clients am Server registrieren.
  4. wie ein Spiel gestartet wird
  5. (nur SoPra:) wie der Smartphone-Beobachter genutzt wird
  6. (nur SWTPra:) wie der PC-Beobachter genutzt wird 
  7. (nur SWTPra:) wie der Smartphone-Teilnehmer funktioniert.
  8. wie der KI-Teilnehmer geladen und gestartet wird.

Zusätzlich muss jede Gruppe zu den Implementierungs-Abgaben jeweils ein Testdokument und die Implementierung von Tests abgeben. Der Schwerpunkt sollte dabei auf den Integrationstests von Server und Clients liegen, welche die wichtigsten Produktfunktionen überprüfen bzw. sicherstellen. Hierzu zählt auch die Überprüfung der Produktcharakteristiken aus dem Pflichenheft.

Test-Implementierung: Die Tests können in Form von JUnit-Tests implementiert werden. Wurde z. B. ein "Rudimentärer KI-Teilnehmer" zu Testzwecken implementiert, sollte dieser auch mit abgegeben werden. Detailliertere Tests von Unterkomponenten bzw. Klassen sollten nicht Teil dieser Abgabe sein, diese können später im Rahmen der  Abschlussdokumentation abgegeben werden.

Testdokumentation: Es muss ein Dokument abgegeben werden, welches die implementierten Testfälle oder ggf. manuell durchgeführten Tests beschreibt. Die Testdokumentation sollte für die gesamte Implementierung ca. 10-20 Seiten (PDF) lang sein, entsprechend kürzer bei den Teilabgaben (Messeversion, Turnierversion) der Implementierung.

Das Dokument (vergleiche auch IEEE 829) sollte bestehen aus:

1. Einer Übersicht der Testfälle

2. Eine Beschreibung jedes Testfalls:

  • Welche Funktionalität wird getestet (welcher Use-Case bzw. welcher Produktcharakteristik)?
  • Ist es ein Positiv- oder Negativ-Test?
  • Welches ist die Eingabe bzw. Vorbedingung des Tests?
  • Welches ist das erwartete Ergebnis?
    (Es kann natürlich auch eine Sequenz von Eingaben und erwarteten Ergebnissen beschrieben werden.)
  • Wer ist Tester? Datum des letzten Tests? Ergebnis des Tests? 

Mögliche Test-Arten sollten Sie aus der Vorlesung kennen. Denken Sie neben Unit-Tests insbesondere auch über Tests wie Wizard-Tests und Code-Coverage-Tests nach. Neben Integrationstests können zudem auch Systemtests (z.B. anhand der geplanten Use-Cases) gefahren werden.

Beispiel (2013): Testdokument.

Beispiel (2014): Testdokument.

Mit den Tests möchten wir sicherstellen, dass die abgegebenen Komponenten (u.a. beim Turnier) möglichst reibungslos zusammenarbeiten. In der Zeit zwischen der Abgabe der Implementierung und dem Turnier werden wir die KI-Teilnehmer überprüfen. Ggf. werden wir danach die Gruppen dazu auffordern, schwerwiegende Fehler oder durch unterschiedliche Interpretation der Anforderungen entstandene Probleme zu beheben. Sie sollten jedoch in dieser Phase nicht maßgebliche Funktionen Ihrer Software ändern.

Endabgabe (Deadline: 24.07. 18:00 Uhr)

Die Endabgabe umfasst folgende Teile:

Abschlussdokumentation (SoPra: 5-20 Seiten, SWTPra: 10-30 Seiten) (PDF)

  • Überblick über wesentliche Teile und Konzepte der entwickelten Software
  • Wesentliche Ideen des Teams aufzeigen (z. B. Besonderheiten wie spezielles Vorgehen bei der Entwicklung, spezieller Entwicklungsprozess, besonders geschickte/systematische Herangehensweise bei Tests, besondere Berücksichtigung von speziellen Qualitätsmerkmalen wie z. B. Effizienz, Benutzerfreundlichkeit, Änderbarkeit).
  • Grenzen aufzeigen und Ausblick geben: Was wurde nicht geschafft und warum? Was könnte evtl. verbessert werden?
  • Team-spezifischer Rückblick auf das Praktikum: Was wurde gelernt? Was ist gut / schlecht gelaufen? Was würde man beim nächsten Mal anders machen? Kritik und Anregungen.

Die gesamte implementierte Software:

  • Quellcode aller Komponenten (Server & Clients, in einer Zip-Datei exportierte Eclipse-Projekte)
  • Kompilierte, deploybare Plug-Ins als Jar-Dateien zur einfachen Verwendung in einer Zip-Datei zusammengefasst (optional kann eine Eclipse-Updatesite erstellt werden).
  • Testimplementierungen (JUnit-Tests)

Installationsanleitung und Benutzerhandbuch (PDF)

  • für die vom Team entwickelte Software

Vergleich der Aufwandsschätzung mit dem tatsächlichen in Std.-Zetteln dokumentierten Aufwand, ca. 1 bis 2 Seiten (PDF)

Alle bisher erstellten Dokumente in der aktuellsten Version, d. h.:

  • Angebot, inkl. Projektplan und Aufwandsschätzung (PDF)
  • Pflichtenhefte (PDF)
  • Analyse- & Entwurfsdokumente (PDF)
  • ggf. Änderungsdokument(e) (Was hat sich im Vergleich zu Pflichtenheft oder A&E geändert?) (PDF)
  • ggf. Sonderabgabe-Dokument(e) (z. B. Veränderungsanträge) (PDF)
  • Testdokumentation (Testpläne, Testberichte, etc., siehe Auflistung unter Implementierungsabgaben) (PDF)
  • API-Dokumentation bzw. Javadoc (HTML)
  • Feature-Liste (inkl. Erläuterungen: Was wurde umgesetzt/nicht umgesetzt und warum?)
  • sämtliche Protokolle (PDF)
  • sämtliche Stundenzettel (PDF)

Webseite (fasst alle Teile der Endabgabe zusammen)

  • nur statisch; keine Skripte wie PHP, Perl, Python; lokal ausführbare Skripte wie JavaScript oder Flash sind erlaubt.
  • Eine Facebook-Webseite oder ähnliches ist nicht erlaubt.

Beispiele

Abschlussdokumentation SWTPra-Team 6 (SS 2015)

  • Bemerkung: Das Deckblatt wurde anonymisiert.

Änderungsdokument SWTPra-Team 3 (SS 2013)

  • Bemerkung: Das Deckblatt wurde anonymisiert.

Feature-Liste SWTPra-Team 6 (SS 2015)

  • Bemerkung: Das Deckblatt wurde anonymisiert.