Skip to Content

Changes for page Anforderungen Software

Last modified by mgrawunder on 2025/09/29 10:00
From version arrow_back 7.2 arrow_forward
edited by mgrawunder
on 2025/09/24 09:03
Change comment: There is no comment for this version
To version arrow_back 6.1 arrow_forward
edited by mgrawunder
on 2025/09/11 13:10
Change comment: There is no comment for this version

Summary

Details

insert_drive_file Page properties
Content
... ... @@ -5,8 +5,7 @@
5 5  = Anforderungen: Spielumsetzung =
6 6  
7 7  * Client-Server-Umsetzung (Spiellogik auf Server!)
8 -** Der Server muss komplett Java-basiert sein
9 -** Der Client kann in Java sein, muss es aber nicht. Es ist auch erlaubt, hier z.B. Web-Frameworks wie Angular oder React zu verwenden. ACHTUNG! Das kann zu einem deutlich höherem Aufwand führen, man spart sich aber JavaFX ;-)
8 +** Komplett Java-basiert (z.B. mit Web-Services, RMI)
10 10  * Aus didaktischen Gründen (nicht optional!):
11 11  ** „beliebig“ viele registrierte Nutzer
12 12  ** mehrere Spielrunden gleichzeitig im Server
... ... @@ -16,7 +16,7 @@
16 16  ** Lobby und Spielechats
17 17  * Nutzerverwaltung
18 18  ** gekapselter Zugriff, d.h. es darf für die Verwendung nicht sichtbar sein, wie die Daten wirklich verwaltet werden. Initial wird hier beispielsweise mit einer hauptspeicherbasierten Struktur gearbeitet.
19 -** relationales DBMS
18 +** relationales DBMS (**Zugriff mit JDBC, kein Hibernate oder ähnliches**)
20 20  ** einfache Austauschbarkeit des DBMS-Servers (unterschiedliche Verbindungen, unterschiedliche Hersteller)
21 21  * KI (je nach Spiel, siehe Start-Folien)
22 22  ** Das Spiel muss die Integration einer KI unterstützen
... ... @@ -104,11 +104,11 @@
104 104  
105 105  * Eine allgemeine Einleitung für das Dokument. Worum geht es und wie ist das Dokument aufgebaut.
106 106  * Grundsätzlich sollte jeder Abschnitt kurz eingeleitet werden und jeden Kapitel sollte eine kurze Zusammenfassung bekommen.
107 -* Quellen müssen angegebenen werden, also z.B. nicht einfach Text von einer Web-Seite kopieren. Das kann u.U. als Plagiat ausgelegt werden...
106 +* Quellen müssen angebenen werden, also z.B. nicht einfach Text von einer Web-Seite kopieren. Das kann u.U. als Plagiat ausgelegt werden...
108 108  * Eine Darstellung der ermittelten Anforderungen.
109 109  ** Dies umfasst mindestens die umgesetzten User-Stories (Sinnvoll: Die Akzeptanzkriterien für eine User-Story mit angeben.). Idealerweise werden die UserStories (siehe [[User-Stories>>doc:Main.Scrum.WebHome||anchor="HUserStories"]]) noch durch Anwendungsfälle unterstützt.
110 110  ** Ggf. eine Darstellung/Auflistung nicht umgesetzter User Stories. Die kann noch einmal zeigen, welche kreativen Ideen zeitlich nicht mehr umgesetzt wurden
111 -** Die Stories sollten möglichst gruppiert (z.B. nach Nutzerverwaltung, Hauptmenü/Lobby, etc.) werden.
110 +** Die Stories sollten möglichst gruppiert (z.B. nach Nutzerverwaltung, Hauptmenue/Lobby, etc.) werden.
112 112  * Darstellung der Realisierung
113 113  ** Allgemeine/Übergreifende Konzepte, z.B. wie wurde MVP realisiert
114 114  *** Darstellung der Architektur und Aufteilung des Gesamtsystems in Module
... ... @@ -125,7 +125,6 @@
125 125  **** Nicht immer ist offensichtlich, warum eine Lösung gewählt wurde. In diesem Fall sollten (Entwurfs-)Entscheidungen begründet/motiviert werden. Es ist grundsätzlich eine gute Idee, Dinge nicht nur „mitzuteilen“, sondern zu „erklären“.
126 126  **** Wenn man komplexere Algorithmen darstellen möchte, kann es besser sein, die Darstellung mit Pseudocode vorzunehmen.
127 127  *** Diagramme sollten an den Stellen im Text sein, an denen sie erläutert werden. Es muss vom Text aus auf die Diagramme verwiesen ("siehe Abb. X.Y") werden. Einfach alle im Anhang aufzulisten, macht keinen Sinn.
128 -*** Hinweise: Man kann Diagramm auch in Gitlab textuell erzeugen: [[https:~~/~~/docs.gitlab.com/user/markdown/#diagrams-and-flowcharts>>https://docs.gitlab.com/user/markdown/#diagrams-and-flowcharts]] (und dann ggf. als
129 129  ** Bei Spiel: Regelabweichungen darstellen und begründen
130 130  ** (Java-)Quellcode im Text möglichst vermeiden. Pseudocode kann für die Beschreibung von komplexeren Algorithmen verwendet werden.
131 131  ** **ACHTUNG**! Die Konzepte bitte so darstellen, als wenn sie nicht iterativ entstanden wären. Also keine "Verteilung" des Konzeptes auf Sprints. Wichtig ist, was am Ende herausgekommen ist.