Changes for page Anforderungen Software

Summary

• insert_drive_file Page properties (3 modified, 0 added, 0 removed)

Details

insert_drive_file Page properties

Title

...	...	@@ -1,1 +1,1 @@
1		-Anforderungen an die Software
	1	+Anforderungen Software

Author

...	...	@@ -1,1 +1,1 @@
1		-XWiki.PascalMeyer
	1	+XWiki.MarcoGrawunder

Content

...	...	@@ -1,3 +1,5 @@
	1	+[[image:Main.Organisatorisches.WebHome@softwareprojekt_logo_transparent.png||alt="SoftwareprojektLogo.png" data-xwiki-image-style-alignment="end" height="136" width="309"]]
	2	+
1	1	{{toc/}}
2	2
3	3	= Anforderungen: Spielumsetzung =
...	...	@@ -25,7 +25,7 @@
25	25	** Wichtig ist guter, erweiterbarer und wartbarer Code und eine gute Benutzerführung
26	26	** Wenn das Spiel dann zusätzlich noch optisch gut aussieht, um so besser.
27	27
28		-{{warning}}
	30	+{{info}}
29	29	**Wichtig!**
30	30
31	31	* Überlegen Sie genau, welche Features Sie umsetzen können und welche weggelassen werden sollten
...	...	@@ -38,7 +38,7 @@
38	38	** 3D
39	39	* Sie dürfen die Regeln vereinfachen/verändern! Je nach Veränderung kann diese natürlich auch zu einer Reduktion der Komplexität und damit auch zu einer schlechteren Bewertung führen.
40	40	* Sie haben nur begrenzte Ressourcen zur Verfügung und müssen das auch vertreten!
41		-{{/warning}}
	43	+{{/info}}
42	42
43	43	= Anforderungen: Die vordefinierten Meilensteine =
44	44
...	...	@@ -45,7 +45,7 @@
45	45	Um gut in das SWP zu starten, gibt es drei **vordefinierte** Meilensteine.
46	46
47	47	* Der erste Meilenstein ist durch die gemeinsame Bearbeitung der Übungsaufgaben erreicht.
48		-* Für den zweiten Meilenstein (s.u.) gibt es eine [[Präsentation>>url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/393401/TA+5+Zwischenpr%C3%A4sentation]]. Das ist die erste Präsentation bei mir.
	50	+* Für den zweiten Meilenstein (s.u.) gibt es eine [[Zwischenpräsentation>>doc:Main.Aufgabenstellung.WebHome||anchor="HTeilaufgabe5:ZwischenprE4sentation"]]. Das ist die erste Präsentation bei mir.
49	49	* Es gibt eine Präsentation für den Prototypen (Meilenstein X), im zweiten Semester.
50	50	* Es gibt eine Präsentation für das finale Produkt (Endabnahme) zum Ende des zweiten Semesters.
51	51
...	...	@@ -57,9 +57,11 @@
57	57	* Registrierte Nutzer sollen sich am Spiel anmelden können.
58	58	* Die Nutzer sollen nach dem Einloggen in das Hauptmenü gelangen und dort alle Nutzer sehen, die auch eingeloggt sind.
59	59
	62	+{{success}}
	63	+**Hinweis:**
60	60
61		-
62	62	Hinweis: Dieser Meilenstein wird gemeinsam als Einführung für das Software Projekt durchgeführt. Es findet am Ende also keine Präsentation statt.
	66	+{{/success}}
63	63
64	64	== Meilenstein 2: Hauptmenü, Chat, Spiel-Ansätze ==
65	65
...	...	@@ -80,7 +80,8 @@
80	80	* Es dürfen noch Fehler drin sein und die Bedienbarkeit muss noch nicht ganz ausgereift sein.
81	81	* Es dürfen danach noch Änderungen und Erweiterungen gemacht werden.
82	82
83		-Hinweise:
	87	+{{success}}
	88	+**Hinweis:**
84	84
85	85	* Die Anforderungen sind die **Minimalanforderungen**.
86	86	* Es darf ruhig zum jeweiligen Zeitpunkt schon mehr realisiert werden.
...	...	@@ -90,16 +90,17 @@
90	90	** kein 3D etc.
91	91	** Die Spielanleitung kann als PDF zur Verfügung gestellt werden.
92	92	* Im Zweifelsfall ist es wichtiger, **eine gute Basis** zu haben und nicht so weit zu sein wie es der Meilenstein verlangt. Auf keinen Fall sollte man aus Gründen der Meilensteinerreichung Dinge einfach "runterhacken" um sie hinterher wieder aufzuräumen. Das wäre dann unnötige Arbeit!
	98	+{{/success}}
93	93
94	94	= Anforderungen: Dokumentation =
95	95
96		-Im Softwareprojekt muss am Ende zusätzlich zum eigentlichen Produkt ein Dokument (das kann auch durch einen Export aus Confluence erfolgen) abgegeben werden, welches im Wesentlichen die folgenden Aspekte enthalten sollte:
	102	+Im Softwareprojekt muss am Ende zusätzlich zum eigentlichen Produkt ein Dokument (das kann auch durch einen Export aus GitLab erfolgen) abgegeben werden, welches im Wesentlichen die folgenden Aspekte enthalten sollte:
97	97
98	98	* Eine allgemeine Einleitung für das Dokument. Worum geht es und wie ist das Dokument aufgebaut.
99	99	* Grundsätzlich sollte jeder Abschnitt kurz eingeleitet werden und jeden Kapitel sollte eine kurze Zusammenfassung bekommen.
100	100	* Quellen müssen angebenen werden, also z.B. nicht einfach Text von einer Web-Seite kopieren. Das kann u.U. als Plagiat ausgelegt werden...
101	101	* Eine Darstellung der ermittelten Anforderungen.
102		-** Dies umfasst mindestens die umgesetzten User-Stories (Sinnvoll: Die Akzeptanzkriterien für eine User-Story mit angeben.). Idealerweise werden die UserStories noch durch Anwendungsfälle unterstützt.
	108	+** 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.
103	103	** Ggf. eine Darstellung/Auflistung nicht umgesetzter User Stories. Die kann noch einmal zeigen, welche kreativen Ideen zeitlich nicht mehr umgesetzt wurden
104	104	** Die Stories sollten möglichst gruppiert (z.B. nach Nutzerverwaltung, Hauptmenue/Lobby, etc.) werden.
105	105	* Darstellung der Realisierung
...	...	@@ -147,7 +147,7 @@
147	147	** Ggf. vollständige Klassendiagramme (Ohne weitere Erläuterung)
148	148	** Protokolle und andere im Laufe der Zeit entstandene Dokumente in speziellen Ordner hinterlegen. **Nicht (mehr) in das Dokument mit aufnehmen**, das ist nur unnötige Arbeit.
149	149	* Glossar mit Begriffen des Gegenstandes/Spiels
150		-* Index  (Falls Dokument mit LaTeX erstellt, bei Confluence-Export nicht möglich/notwendig)
	156	+* Index  (Falls Dokument mit LaTeX erstellt, bei GitLab-Export nicht möglich/notwendig)
151	151
152	152	Ich werde immer wieder gefragt, wieviele Seiten die Dokumentation haben muss. Das lässt sich so pauschal leider nicht sagen, denn das hängt zum einen natürlich massiv von der verwendeten Vorlage ab, zum anderen aber auch davon, welches die aktuelle Aufgaben gewesen ist. Zur Orientierung kann man jedoch sagen, dass die typische (gelungene) (LaTeX-basierte-)Dokumentation in den letzten Jahren immer so in dem Bereich von 80 bis 100 Seiten (inkl. Anhängen und Bildern) gelegen hat. Es macht nun aber keinen Sinn, die Seitenanzahl künstlich durch "unnötigen" Inhalt aufzublähen. Ich schaue schon sehr genau darauf, wie gelungen und vollständig die oben genannten Punkte abgehandelt werden.
153	153
...	...	@@ -158,12 +158,14 @@
158	158
159	159	Im Git-Repository gibt es eine Dokumentationsvorlage für LaTeX.
160	160
161		-Hinweise:
	167	+{{success}}
	168	+**Hinweis:**
162	162
163	163	* Falls es Widersprüche zwischen der Vorlage und dem Text hier im Wiki gibt, bitte eine kurze Nachricht. Im Zweifelsfall zählt der Inhalt aus dem Wiki.
164	164	* Falls etwas nicht korrekt funktioniert, bitte auch eine kurze Nachricht. Ich kümmere mich.
165	165	* Gruppen, die ihre Dokumentation auch im git pflegen wollen, können mir einen Nachricht schicken und ich richte das Repo dann passend ein.
166	166	* [[https:~~/~~/git.swl.informatik.uni-oldenburg.de/projects/SPB/repos/dokumentation/browse/>>url:https://git.swl.informatik.uni-oldenburg.de/projects/SPB/repos/dokumentation/browse/]]
	174	+{{/success}}
167	167
168	168	= Anforderungen: Nutzung von KI Tools =
169	169
...	...	@@ -172,8 +172,7 @@
172	172	**~1. Transparenzpflicht:**
173	173	Alle von KI-Tools generierten Code- oder Textpassagen müssen im Code oder in den Abgaben klar als solche gekennzeichnet werden. Zum Beispiel durch Kommentare wie
174	174
175		-{{{// Generated with ChatGPT at 31.03.2025
176		-}}}
	183	+|~/~/ Generated with ChatGPT at 31.03.2025
177	177
178	178	**Ausnahme**: Die Vervollständigung einer Zeile (durch Tab) ist nicht speziell zu dokumentieren ("Local Full Line Completion"), alles weitergehende auf jeden Fall.
179	179