Wiki source code of Präsentationen
Version 2.1 by Marco Grawunder on 2026/08/25 14:44
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
| |
1.1 | 1 | = Teilaufgabe 5: Zwischenpräsentation = |
| 2 | |||
| 3 | * Zeigen Sie die wesentlichen | ||
| 4 | ** Konzepte (statisch und dynamisch!) | ||
| 5 | ** Architektur | ||
| 6 | ** Software-Design-Entscheidungen (**es geht hier nicht um die Grafik und Optik**) und | ||
| 7 | ** die Zusammenhänge (statisch z.B. durch Klassendiagramme und dynamisch z.B. durch Sequenz- oder Aktivitätsdiagramme!) | ||
| 8 | ** Technologieentscheidungen (hier nicht die Tools wie GitLab, Visual Paragdigm etc., sondern die verwendeten Frameworks!) | ||
| 9 | ** Grundsätzlich sollte auf die Serverkonzepte vertiefter eingegangen werden als auf Aspekte, die sich auf die GUI beziehen. | ||
| 10 | ** 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. | ||
| 11 | ** 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. | ||
| 12 | * Erklären (Bilder können helfen): | ||
| 13 | ** Warum es so ist, wie es ist und warum das gut so ist. | ||
| 14 | ** Wie können Erweiterungen vorgenommen werden | ||
| 15 | * Keine Dinge wiederholen, die in diesem Wiki stehen oder das Spiel erklären (kostet nur Zeit) | ||
| 16 | * Ehrlich bei Fehlern und Problemen sein | ||
| 17 | * „Knackige“ Online-Demonstration des aktuellen Standes (nicht optional!) | ||
| 18 | ** mit Moderation, | ||
| 19 | ** die Demonstration sollte ein Konzept und einen roten Faden haben: Nicht einfach starten und schauen, was passiert. | ||
| 20 | ** Cheats können helfen, sinnvolle Situationen zum Präsentieren herbeizuführen | ||
| 21 | ** Es ist wichtig, dass ich der Demonstration folgen kann. | ||
| 22 | ** Kein Video erstellen, sondern live demonstrieren. Dann kann ich auch mal eingreifen, Fragen stellen und bekomme einen "echteren" Eindruck. | ||
| 23 | ** Wenn der Start länger dauert (z.B. weil erst IntelliJ gestartet werden muss), bitte dies **vor der Präsentationen** machen. | ||
| 24 | * Einschränkungen/Anpassungen/Änderungen nennen | ||
| 25 | * 20-30 Minuten (sinnvoll füllen) | ||
| 26 | * Je nachdem, ob online oder in Präsenz (siehe dazu im Stud.IP im Wiki zur Veranstaltung) | ||
| 27 | ** Präsenz: Nur eine Delegation (max. 3 Personen) | ||
| |
2.1 | 28 | *** Bei der finalen [[Präsentaiton>>doc:Main.Präsentationen.WebHome||anchor="HTeilaufgabe6:Abnahme"]] sollte der Vortragende allerdings stehen. |
| |
1.1 | 29 | ** Falls die Präsentation online stattfindet, |
| 30 | *** dürfen natürlich beliebig viele Personen der Gruppe teilnehmen | ||
| 31 | *** sollten die **Vortragenden eine Kamera** anmachen (geht z.B. auch mit dem Smartphone als Kamera) | ||
| 32 | * Es sollten bei jeder Präsentation andere Mitglieder der Gruppe vorstellen. Es müssen aber nicht alle da gewesen sein. | ||
| 33 | |||
| 34 | {{info}} | ||
| 35 | **Wichtig!** | ||
| 36 | |||
| 37 | * Keinen Ausdruck der Folien. Ich mache mir digitale Notizen. Deswegen ist es umso wichtiger: | ||
| 38 | * **Für jede Präsentation eine Seite im GitLab erstellen (vorher!) mit angehängten Dokumenten (aktueller Stand der Dokumentation, Modelle und Präsentation als PDF)**. Dies ist vor allem hilfreich, wenn mal Dinge vergessen werden. | ||
| 39 | * Für die Präsentationen sollen zwar stets Motivationsfolien erarbeitet werden, jedoch sollen diese in der Präsentation aus zeitlichen und repetitiven Gründen nicht vorgestellt werden! | ||
| 40 | * Bitte die Präsentationen so benennen, dass die Gruppe und die Art der Präsentation klar ist. Z.B. GruppeA_ErstePräsentation.pdf. | ||
| 41 | {{/info}} | ||
| 42 | |||
| 43 | == Hinweise & Tricks zur Präsentation: == | ||
| 44 | |||
| 45 | 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. | ||
| 46 | |||
| 47 | Bemerkungen: | ||
| 48 | |||
| 49 | [[Hinweise und Tricks für Präsentationen>>attach:SWP_Hinweise&Tricks.pdf]] | ||
| 50 | |||
| 51 | * 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. | ||
| 52 | * 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. | ||
| 53 | * Am Ende der Präsentation bitte eine Zusammenfassungs- und Ausblicksfolie. | ||
| 54 | |||
| 55 | = Teilaufgabe 6: Abnahme = | ||
| 56 | |||
| |
2.1 | 57 | Hier im wesentlichen die selben Dinge beachten wie [[in der Zwischenpräsentation>>doc:Main.Präsentationen.WebHome]] (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!** |
| |
1.1 | 58 | |
| 59 | Und **zusätzlich**: | ||
| 60 | |||
| 61 | * d.h. hier auch die wichtigen Konzept, Ideen und Modelle vorstellen | ||
| 62 | * In der Demo die Registrierung nicht mehr zeigen. | ||
| 63 | * Screenshots zur Erklärung der wesentlichen Komponenten (bitte hier keine Mockups mehr oder Vorher/Nachherdarstellungen) | ||
| 64 | * Die Qualitätssicherung: | ||
| 65 | ** Projektmanagement | ||
| 66 | ** Testen | ||
| 67 | * allgemeiner Rück- und Ausblick, aber bitte keinen detaillierten Rückblick auf einzelne Sprints (In Sprint 1 haben wir ... In Sprint 2 haben wir ...) | ||
| 68 | * Auf eine sinnvolle Auswahl und Gewichtung achten. Wenn Dinge ähnlich sind, besser zusammenfassen, dafür aber wichtige Ideen, verwendete Algorithmen und Konzept vorstellen. | ||
| 69 | * 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. | ||
| 70 | * Alle Mitglieder der Gruppe müssen da sein! Es besteht Anwesenheitspflicht. | ||
| 71 | |||
| 72 | {{success}} | ||
| 73 | **Hinweise:** | ||
| 74 | |||
| 75 | * Die Demo sollte i.d.R. mit dem Server auf einem Rechner in der ARBI (z.B. Dümmer) erfolgen. Ausnahmsweise (unter Angaben von Gründen) kann der Server auch auf einem anderen Server laufen. Einen Server auf einem Rechner zu starten, der auch an der Präsentation teilnimmt ist nicht erlaubt, insbesondere auch, da die OFFIS-Infrastruktur so etwas u.U. nicht erlaubt und außerdem soll man sich einmal mit dem Server-Deployment-Problem befassen. | ||
| 76 | * Ich habe eine ganze Menge an Präsentationen. Ich kann mich nicht immer an alles vorher erinnern | ||
| |
2.1 | 77 | * Die Präsentierenden sollten (im Unterschied zu [[Zwischenpräsentation>>doc:Main.Präsentationen.WebHome]]) besser vorne stehen. Dann kann ich unabhängig vom Sitzplatz sowohl die Person als auch die Folien anschauen. |
| |
1.1 | 78 | {{/success}} |
| 79 | |||
| 80 | Abgabe: | ||
| 81 | |||
| 82 | * **Bitte: vor der Abnahme die Präsentation als PDF schon einmal in dem Cloud-Ordner hochladen.** | ||
| 83 | * Bis zur Präsentation muss nur die Präsentation fertig sein. Alle andere Dokumente können später erstellt/finalisiert werden. | ||
| 84 | * Dokumente (als PDF! Die wichtigen zusammen in einem Ordner und **nicht in die VM (s.u.) packen**!) | ||
| 85 | * Der Quellcode | ||
| 86 | ** braucht nicht abgegeben werden, da er ja in Gitlab vorhanden ist. | ||
| 87 | ** 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) | ||
| 88 | ** 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! | ||
| 89 | ** Die Tests sollten alle ohne externe Datenbank laufen! | ||
| 90 | * Protokolle, Präsentationen, … | ||
| 91 | * zusätzlich (!) virtuelle Maschine (VMWare (mit VMWarePlayer abspielbar!) **oder** VirtualBox) | ||
| 92 | ** mit vollständig eingerichtetem lauffähigem Server für mich zum Testen (mit Hinweise zur Verwendung, z.B. mit Readme auf Desktop) | ||
| 93 | ** ohne Abhängigkeiten nach außen (E-Mail, Datenbank, etc.!). Die DB darf hauptspeicherbasiert (MainMemoryBasedUserStore) sein. | ||
| 94 | ** VM sollte den Gruppennamen enthalten | ||
| 95 | ** keine Dokumente in der VM "verstecken", d.h. die Dokumente zur Abgabe müssen extra abgegeben werden. | ||
| 96 | ** 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!) | ||
| 97 | ** Die VM sollte nicht zu groß sein! Linux statt Windows kann hier schon viel helfen (Windows ist aber erlaubt) | ||
| 98 | ** Es reicht, wenn die VM unter x86/amd64 lauffähig ist. | ||
| 99 | ** BITTE die VM testen. Insbesondere ob auch alles funktioniert! | ||
| 100 | ** Es ist erlaubt, die VM in ein Multi-Volume-Archive zu verpacken, falls es Probleme mit dem Upload gibt. | ||
| 101 | ** Kein Docker, da ich auch meinen Rechner vor der VM absichern muss (Sonst müsste ich einen zusätzlichen Rechner dafür nutzen ... DSGVO) | ||
| 102 | * **10 Minuten-Video, Format MP4** | ||
| 103 | ** Das Video sollte von nicht deutlich von den 10 Minuten abweichen (+/- 10% sind ok) | ||
| 104 | ** Das Video sollte im **MP4-Format** vorliegen (falls die Aufnahme z.B. als MOV gemacht worden ist, kann man mit Handbrake ([[https:~~/~~/handbrake.fr/>>url:https://handbrake.fr/]]) oder auch VLC ([[https:~~/~~/www.videolan.org/vlc/>>url:https://www.videolan.org/vlc/]]) eine Konvertierung machen). | ||
| 105 | ** Das Video sollte nicht größer als **100 MB** sein, d.h. **1080p** ist vollkommen ausreichend (siehe vorherigen Kommentar zum ggf. notwendigen Konvertieren) | ||
| 106 | ** mit Präsentation des Endproduktes (z.B. mit HyperCam), | ||
| 107 | ** bitte mit **Ton** | ||
| 108 | ** Fokus bitte auf das **Spiel** | ||
| 109 | ** Registrierung, Chat, Besonderheiten außerhalb des Spiels etc. max 1 Minute | ||
| 110 | ** Bitte mit mehreren Spielern spielen | ||
| 111 | ** Spezielle Spielsituationen (gemäß Regeln) sollten extra dargestellt werden um zu zeigen, wie die Software damit umgeht. | ||
| 112 | ** Das Video darf geschnitten werden. | ||
| 113 | ** 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. | ||
| 114 | ** Bitte keine **Namen oder Bilder von echten Personen** im Video verwenden. | ||
| 115 | |||
| 116 | **Verwendung der Uni-Cloud (**[[**https:~~/~~/cloud.uol.de).**>>url:https://cloud.uol.de/]] Dort bitte alles zur Verfügung stellen. Dafür haben Sie von mir eine Freigabe erhalten (im internen Wiki der Gruppenveranstaltung oder über den Tutor). 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.) | ||
| 117 | |||
| 118 | {{success}} | ||
| 119 | **Hinweise:** | ||
| 120 | |||
| 121 | * Der Termin für die finale Abgabe ist immer der Tag, an dem **die letzte Präsentation möglich gewesen wäre (siehe [[Aktuelles>>Main.Aktuelles.WebHome]])**. Die von mir versendeten Shares verfallen aus Gründen der Gerechtigkeit um 0:00 Uhr am Tag danach. Also am besten nicht bis zur letzten Minute warten. | ||
| 122 | * Der Upload in die Cloud ist innerhalb des Uni-Netzes i.d.R. deutlich schneller. | ||
| 123 | * Es kann passieren, dass es deutlich länger mit dem Upload dauert, wenn alle gleichzeitig hochladen ... | ||
| 124 | * Falls es noch deutliche Unterschiede zwischen dem Stand der in der Präsentation vorgestellt wurde und der Abgabe gibt, bitte noch einmal explizit dokumentieren! | ||
| 125 | * Es sollte in der Gruppe immer jemand danach die Zeit ansprechbar sein und ggf. Dokumente, bei denen es Probleme mit dem Upload gegeben hat, hochladen können. | ||
| 126 | * Der Upload müsste auch mit dem Nextcloud-Sync-Tool erfolgen können, falls es Probleme mit der Web-Version gibt. | ||
| 127 | * Änderungen am Git-Code sind nach der Abgabe natürlich ebenfalls nicht mehr zulässig. | ||
| 128 | {{/success}} | ||
| 129 |