Changes for page Softwareentwicklung

Summary

• Page properties (1 modified, 0 added, 0 removed)
• Attachments (0 modified, 0 added, 1 removed)
  • Warnung.png

Details

Page properties

Content

...	...	@@ -1,20 +1,12 @@
1	1	[[image:Main.Organisatorisches.WebHome@softwareprojekt_logo_transparent.png||alt="SoftwareprojektLogo.png" data-xwiki-image-style-alignment="end" height="136" width="309"]]
2	2
3		-{{info}}
4		-**Worum geht es auf dieser Seite?**
5		-
6		-Diese Seite enthält die **allgemeinen technischen und funktionalen Anforderungen** an die Softwareentwicklung im Softwareprojekt. Dazu gehören Client-Server-Architektur, Meilensteine, Implementierung, Testen, Qualitätssicherung und der Umgang mit generativen KI-Werkzeugen.
7		-
8		-Die konkrete Spielaufgabe und andere jahrgangsspezifische Vorgaben stehen im geschützten Bereich [[Aktuelles>>doc:Main.Aktuelles.WebHome]].
9		-{{/info}}
10		-
11	11	{{toc/}}
12	12
13		-= Technische und funktionale Anforderungen =
	5	+= Anforderungen: Spielumsetzung =
14	14
15		-* Client-Server-Umsetzung; die zentrale Spiellogik liegt auf dem Server.
16		-** Der Server muss vollständig Java-basiert sein.
17		-** Der Client kann ebenfalls in Java umgesetzt werden, muss dies aber nicht. Alternativ können z. B. Web-Frameworks wie Angular oder React verwendet werden. Dabei ist zu berücksichtigen, dass eine zusätzliche Web-Technologie insbesondere zu Beginn einen höheren Integrations- und Einarbeitungsaufwand verursachen kann.
	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 ;-)
18	18	* Aus didaktischen Gründen (nicht optional!):
19	19	** „beliebig“ viele registrierte Nutzer
20	20	** mehrere Spielrunden gleichzeitig im Server
...	...	@@ -26,15 +26,15 @@
26	26	** 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.
27	27	** relationales DBMS
28	28	** einfache Austauschbarkeit des DBMS-Servers (unterschiedliche Verbindungen, unterschiedliche Hersteller)
29		-* Computergesteuerte Spieler (je nach aktueller Spielaufgabe)
30		-** Das Spiel muss die Integration eines computergesteuerten Spielers unterstützen.
31		-** Es muss mindestens eine einfache Strategie, z. B. eine zufallsbasierte Strategie, umgesetzt werden.
32		-* Bei einem JavaFX-Client muss die Struktur die Anforderungen des Model-View-Presenter-Ansatzes (MVP) erfüllen.
33		-* Andere Client-Arten, z. B. ein Konsolenclient, sollen mit möglichst geringem Aufwand angebunden werden können. Dies ist ein weiterer Grund dafür, die Spiellogik auf dem Server zu halten.
	21	+* KI (je nach Spiel, siehe Start-Folien)
	22	+** Das Spiel muss die Integration einer KI unterstützen
	23	+** Es muss eine einfache (z.B. zufallsbasierte) KI umgesetzt werden
	24	+* Ansatz muss Model-View-Presenter Anforderungen erfüllen
	25	+* Muss mit möglichst wenig Aufwand möglich sein, andere Client-Arten anzubinden (z.B. Console)  u.a. Spiellogik auf Server
34	34	* Visuelles Thema/Design darf im vorgegebenen Rahmen variiert werden (muss aber nicht!!)
35		-* Qualität und Bedienbarkeit haben Vorrang vor visuellen Zusatzfunktionen.
36		-** Wichtig sind insbesondere verständlicher, erweiterbarer und wartbarer Code sowie eine gute Benutzerführung.
37		-** Eine ansprechende optische Gestaltung ist willkommen, sofern sie nicht zulasten der Kernfunktionalität geht.
	27	+* Achtung!
	28	+** Wichtig ist guter, erweiterbarer und wartbarer Code und eine gute Benutzerführung
	29	+** Wenn das Spiel dann zusätzlich noch optisch gut aussieht, um so besser.
38	38
39	39	{{info}}
40	40	**Wichtig!**
...	...	@@ -42,7 +42,7 @@
42	42	* Überlegen Sie genau, welche Features Sie umsetzen können und welche weggelassen werden sollten
43	43	* Lieber etwas weniger sehr gut umsetzen, als vieles schlecht! Qualität vor Quantität!
44	44	* Bedienbarkeit ist wichtig! Optisches Design weniger!
45		-* KISS: Lösungen möglichst einfach und nachvollziehbar halten.
	37	+* „KISS: Keep it simple stupid“
46	46	* Fokus auf das Wichtige! Es gibt keine Zusatzpunkte für Dinge wie
47	47	** Freundeslisten
48	48	** privaten Chat
...	...	@@ -51,20 +51,12 @@
51	51	* Sie haben nur begrenzte Ressourcen zur Verfügung und müssen das auch vertreten!
52	52	{{/info}}
53	53
54		-= Allgemeine Regeln zur Brettspieladaption =
	46	+= Anforderungen: Die vordefinierten Meilensteine =
55	55
56		-* keine Originalgrafiken ohne Freigabe veröffentlichen,
57		-* Regeln dürfen vereinfacht/angepasst werden,
58		-* Spielspaß soll erhalten bleiben,
59		-* Aktionen anderer Spieler müssen nachvollziehbar sein,
60		-* Zusatzdienste nur sinnvoll einsetzen.
	48	+Um gut in das SWP zu starten, gibt es drei **vordefinierte** Meilensteine.
61	61
62		-= Vorgegebene Meilensteine =
63		-
64		-Für den Einstieg und zur Orientierung im Projektverlauf gibt es mehrere **vorgegebene Meilensteine**. Zusätzlich definiert jede Gruppe eigene fachliche Meilensteine.
65		-
66	66	* Der erste Meilenstein ist durch die gemeinsame Bearbeitung der Übungsaufgaben erreicht.
67		-* Für den zweiten Meilenstein gibt es eine [[Zwischenpräsentation>>doc:Main.Präsentationen.WebHome]].
	51	+* 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.
68	68	* Es gibt eine Präsentation für den Prototypen (Meilenstein X), im zweiten Semester.
69	69	* Es gibt eine Präsentation für das finale Produkt (Endabnahme) zum Ende des zweiten Semesters.
70	70
...	...	@@ -94,7 +94,7 @@
94	94
95	95	== Meilensteine 3 - (X-1) ==
96	96
97		-Es ist notwendig, **zusätzliche eigene Meilensteine zu definieren (mindestens 3-4)**, die sich an die erste Präsentation anschließen. Der Meilenstein für den Prototypen darf **nicht der dritte Meilenstein** sein! Die Meilensteine repräsentieren dabei wichtige Zwischenziele, die erreicht worden sind und sollten sich konkret auf das Spiel beziehen. **Meilensteine müssen natürlich auch ein Datum haben!**
	81	+Es ist notwendig, **zusätzliche eigene Meilensteine zu definieren (mindestens 2-3)**, die sich an die erste Präsentation anschließen. Der Meilenstein für den Prototypen darf **nicht der dritte Meilenstein** sein! Die Meilensteine repräsentieren dabei wichtige Zwischenziele, die erreicht worden sind und sollten sich konkret auf das Spiel beziehen. **Meilensteine müssen natürlich auch ein Datum haben!**
98	98
99	99	== Meilenstein X "Prototyp" ==
100	100
...	...	@@ -116,42 +116,40 @@
116	116	* 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!
117	117	{{/success}}
118	118
119		-= Nutzung generativer KI-Werkzeuge =
	103	+= Anforderungen: Nutzung von KI Tools =
120	120
121		-Generative KI-Werkzeuge wie ChatGPT, Copilot oder Gemini können im Softwareprojekt unterstützend eingesetzt werden. Dabei gelten die folgenden Regeln. Für mit KI-Unterstützung erzeugten Code und Text trägt die Gruppe dieselbe Verantwortung wie für vollständig selbst erstellte Inhalte.
	105	+Die Verwendung von KI-Tools wie ChatGPT, Copilot oder Google Gemini ist inzwischen auch in der Software Entwicklung angekommen. Auch im SWP ist die Verwendung von KI-Tools in gewissem Rahmen erlaubt und möglich.
122	122
123		-*
124		-**
125		-**1. Transparenzpflicht:
126		-**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**
	107	+**~1. Transparenzpflicht:**
	108	+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
127	127
128	128	|~/~/ Generated with ChatGPT at 31.03.2025
129	129
130	130	**Ausnahme**: Die Vervollständigung einer Zeile (durch Tab) ist nicht speziell zu dokumentieren ("Local Full Line Completion"), alles weitergehende auf jeden Fall.
131	131
132		-Nicht dokumentierte weitergehende KI-Nutzung wird wie die ungekennzeichnete Übernahme fremder Inhalte behandelt und kann entsprechende Konsequenzen haben.
	114	+Jede nicht dokumentierte Verwendung muss leider einem Plagiat (wie Copy/Paste aus Stackoverflow ohne Referenz) gleichgestellt werden und hat die üblichen Konsequenzen.
133	133
134	134	**2. Keine vollständige Automatisierung:**
135		-KI-Werkzeuge dürfen z. B. zur Ideenfindung, zum Erklären, beim Debugging oder für Vorschläge genutzt werden. Größere generierte Programmteile dürfen nicht ungeprüft übernommen werden. Die Studierenden müssen verwendeten Code verstehen, prüfen und fachlich vertreten können.
	117	+KI-Tools dürfen zur Inspiration, Ideenfindung oder zum Debugging genutzt werden, aber keine kompletten Programmteile (z.B. ganze Klassen oder Module) dürfen automatisiert generiert und ungeprüft übernommen werden. Die Endverantwortung für die Funktionsweise und das Verständnis liegt bei den Studierenden!
136	136
137	137	**3. Lernen steht im Vordergrund:**
138		-KI-Unterstützung darf den eigenen Lern- und Entwicklungsprozess nicht ersetzen. Insbesondere müssen die Beteiligten die resultierende Lösung verstehen und selbstständig weiterentwickeln können.
	120	+KI darf nicht verwendet werden, um Aufgaben automatisiert zu lösen, sondern nur als ergänzende Unterstützung bei Verständnisproblemen oder als Hilfsmittel beim Lernen.
139	139
140	140	**4. Individuelle Lösungspflicht:**
141		-Wesentliche Design- und Architekturentscheidungen – z. B. Datenmodell, zentrale Spiellogik und Schnittstellen – müssen von der Gruppe selbst getroffen, verstanden und begründet werden. KI kann dabei als Diskussions- oder Reflexionshilfe dienen, nicht als verantwortliche Entscheidungsinstanz.
	123	+Alle wesentlichen Design- und Architekturentscheidungen (z.B. Datenmodell, Hauptlogik, Schnittstellen) müssen selbstständig ohne KI-Tools durch die Studierenden getroffen werden.
142	142
143		-= Implementierung, Test und Qualitätssicherung =
	125	+= Teilaufgabe 4: Implementierung und Test =
144	144
145		-* Implementieren Sie das Produkt auf Grundlage des Entwurfs. Wenn sich während der Implementierung Änderungen ergeben, muss der Entwurf entsprechend nachgeführt werden.
	127	+* Implementieren Sie Ihr Produkt basierend auf dem Entwurf (passen Sie den Entwurf ggf. an)
146	146	* Projektname muss Gruppenname enthalten!
147	147	* (((
148	148	Maven:
149	149
150	150	* Das Produkt muss sich mit Hilfe von **maven** bauen lassen.
151		-* Der Build muss **ohne vorheriges lokales `mvn install`** funktionieren.
	133	+* Das Bauen muss **ohne** mvn install funktionieren.
152	152	* Die Tests müssen über **maven** ausgeführt werden.
153	153	* **GUI-Tests** müssen sich ausschalten lassen.
154		-* Andere Build-Werkzeuge wie Gradle dürfen höchstens ergänzend eingesetzt werden. Der Maven-Build muss vollständig funktionsfähig bleiben.
	136	+* Andere Build-Tools wie Gradle sind nicht (mehr) erlaubt dürfen maximal ergänzend verwendet werden. Maven muss aber funktionsfähig vorhanden sein.
155	155	)))
156	156	* (((
157	157	Sinnvoll: (echtes) Pairprogramming (mit Tauschen der Rollen!): [[Hinweise zum Pairprogramming>>url:https://developer.atlassian.com/blog/2015/05/try-pair-programming/?utm_source=facebook&utm_medium=social&utm_campaign=atlassian_try-pair-programming]]
...	...	@@ -168,28 +168,23 @@
168	168	* Installationshandbuch etc.
169	169	)))
170	170	* (((
171		-[[Videos und Materialien u. a. zum Testen>>doc:Main.Videos.WebHome]]. Testen Sie wichtige Klassen kontinuierlich mit JUnit und nicht erst am Projektende.
	153	+[[Vorlesungsvideos u.a. zu Testen>>doc:Main.Organisatorisches.WebHome||anchor="HVorlesungsvideos"]]. Testen Sie die wichtigen Klassen mit JUnit, nicht erst am ENDE!
172	172
173		-* Nutzen Sie Dependency Injection konsequent; auf der Serverseite insbesondere über Spring.
	155	+* Hilfreich: Dependency Injection (z.B. Google Guice)
174	174	* TestFX kann beim Testen der GUI helfen. Wichtiger sind aber Tests der Funktionalitäten!
175		-* GUI-Tests müssen separat deaktivierbar sein, damit der normale Testlauf auch auf einem CI-/Build-Server ohne grafische Umgebung ausgeführt werden kann.
	157	+* 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.
176	176	* Mocken Sie Abhängigkeiten in Unit-Tests mit Mockito
177	177	)))
178	178	* Führen Sie Integrations- und Endtests durch
179		-* [[Führen Sie mindestens ein dokumentiertes gruppenweites Code–Review durch>>doc:Main.Projektarbeit.WebHome||anchor="HGruppenweitesCode-Review28Team-Review29"]]
180		-* Nutzen Sie Werkzeuge zur statischen Analyse und Qualitätssicherung, z. B. SpotBugs, Checkstyle, SonarLint oder SonarQube.
	161	+* [[Führen Sie mindestens ein dokumentiertes gruppenweites Code–Review durch>>doc:Main.Anforderungen Gruppen.WebHome||anchor="HGruppenweitesCodeReview28Team-Review29"]]
	162	+* Nutzen Sie Tools wie FindBugs, Checkstyle oder SonarLint
181	181	* (((
182	182	**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!)**
183	183
184		-[[image:Warnung.png||alt="Warnung"]]
	166	+[[image:Main.Aufgabenstellung.WebHome@Warnung.png||alt="Warnung"]]
185	185	)))
186	186	* In Scrum muss ein Produktinkrement getestet und lauffähig sein.
187	187	* Versuchen Sie möglichst früh und regelmäßig die aktuelle Version auch auf dem Rechner in der Arbi zu deployen.
188		-* Bei einem JavaFX-Client soll die MVP-Struktur nachvollziehbar selbst umgesetzt werden. Zusätzliche Frameworks, die diese Struktur stark automatisieren, sollten nur eingesetzt werden, wenn ihre Auswirkungen auf Testbarkeit und Wartbarkeit verstanden und begründet werden können.
189		-* Beachten Sie auch die Hinweise zur [[Verwendung von KI>>doc:Main.Softwareentwicklung.WebHome||anchor="HNutzunggenerativerKI-Werkzeuge"]]
	170	+* 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.
	171	+* Beachten Sie auch die Hinweise zur [[Verwendung von KI>>doc:Main.Anforderungen Software.WebHome||anchor="HAnforderungen:NutzungvonKITools"]]
190	190
191		-= Siehe auch =
192		-
193		-* [[Stichwortverzeichnis>>doc:Main.Index.WebHome]]
194		-* [[Glossar>>doc:Main.Glossar.WebHome]]
195		-

Warnung.png

Author

...	...	@@ -1,1 +1,0 @@
1		-XWiki.mgrawunder

Size

...	...	@@ -1,1 +1,0 @@
1		-20.4 KB

Content