Changes for page Softwareentwicklung

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -1,12 +1,16 @@
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	+Diese Seite enthält die **allgemeinen technischen Anforderungen** an die Softwareentwicklung im Softwareprojekt. Die konkrete Spielaufgabe und jahrgangsspezifische Vorgaben stehen im geschützten Bereich **Aktuelles**.
	5	+{{/info}}
	6	+
3	3	{{toc/}}
4	4
5		-= Anforderungen: Spielumsetzung =
	9	+= Technische und funktionale Anforderungen =
6	6
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 ;-)
	11	+* Client-Server-Umsetzung; die zentrale Spiellogik liegt auf dem Server.
	12	+** Der Server muss vollständig Java-basiert sein.
	13	+** 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.
10	10	* Aus didaktischen Gründen (nicht optional!):
11	11	** „beliebig“ viele registrierte Nutzer
12	12	** mehrere Spielrunden gleichzeitig im Server
...	...	@@ -18,15 +18,15 @@
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	19	** relationales DBMS
20	20	** einfache Austauschbarkeit des DBMS-Servers (unterschiedliche Verbindungen, unterschiedliche Hersteller)
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
	25	+* Computergesteuerte Spieler (je nach aktueller Spielaufgabe)
	26	+** Das Spiel muss die Integration eines computergesteuerten Spielers unterstützen.
	27	+** Es muss mindestens eine einfache Strategie, z. B. eine zufallsbasierte Strategie, umgesetzt werden.
	28	+* Bei einem JavaFX-Client muss die Struktur die Anforderungen des Model-View-Presenter-Ansatzes (MVP) erfüllen.
	29	+* 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.
26	26	* Visuelles Thema/Design darf im vorgegebenen Rahmen variiert werden (muss aber nicht!!)
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.
	31	+* Qualität und Bedienbarkeit haben Vorrang vor visuellen Zusatzfunktionen.
	32	+** Wichtig sind insbesondere verständlicher, erweiterbarer und wartbarer Code sowie eine gute Benutzerführung.
	33	+** Eine ansprechende optische Gestaltung ist willkommen, sofern sie nicht zulasten der Kernfunktionalität geht.
30	30
31	31	{{info}}
32	32	**Wichtig!**
...	...	@@ -34,7 +34,7 @@
34	34	* Überlegen Sie genau, welche Features Sie umsetzen können und welche weggelassen werden sollten
35	35	* Lieber etwas weniger sehr gut umsetzen, als vieles schlecht! Qualität vor Quantität!
36	36	* Bedienbarkeit ist wichtig! Optisches Design weniger!
37		-* „KISS: Keep it simple stupid“
	41	+* KISS: Lösungen möglichst einfach und nachvollziehbar halten.
38	38	* Fokus auf das Wichtige! Es gibt keine Zusatzpunkte für Dinge wie
39	39	** Freundeslisten
40	40	** privaten Chat
...	...	@@ -43,12 +43,12 @@
43	43	* Sie haben nur begrenzte Ressourcen zur Verfügung und müssen das auch vertreten!
44	44	{{/info}}
45	45
46		-= Anforderungen: Die vordefinierten Meilensteine =
	50	+= Vorgegebene Meilensteine =
47	47
48		-Um gut in das SWP zu starten, gibt es drei **vordefinierte** Meilensteine.
	52	+Für den Einstieg und zur Orientierung im Projektverlauf gibt es mehrere **vorgegebene Meilensteine**. Zusätzlich definiert jede Gruppe eigene fachliche Meilensteine.
49	49
50	50	* Der erste Meilenstein ist durch die gemeinsame Bearbeitung der Übungsaufgaben erreicht.
51		-* Für den zweiten Meilenstein (s.u.) gibt es eine [[Zwischenpräsentation>>doc:Main.Präsentationen.WebHome]]. Das ist die erste Präsentation bei mir.
	55	+* Für den zweiten Meilenstein gibt es eine [[Zwischenpräsentation>>doc:Main.Präsentationen.WebHome]].
52	52	* Es gibt eine Präsentation für den Prototypen (Meilenstein X), im zweiten Semester.
53	53	* Es gibt eine Präsentation für das finale Produkt (Endabnahme) zum Ende des zweiten Semesters.
54	54
...	...	@@ -100,11 +100,11 @@
100	100	* 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!
101	101	{{/success}}
102	102
103		-= Anforderungen: Nutzung von KI Tools =
	107	+= Nutzung generativer KI-Werkzeuge =
104	104
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.
	109	+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.
106	106
107		-**~1. Transparenzpflicht:**
	111	+**1. Transparenzpflicht:**
108	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
109	109
110	110	|~/~/ Generated with ChatGPT at 31.03.2025
...	...	@@ -111,29 +111,29 @@
111	111
112	112	**Ausnahme**: Die Vervollständigung einer Zeile (durch Tab) ist nicht speziell zu dokumentieren ("Local Full Line Completion"), alles weitergehende auf jeden Fall.
113	113
114		-Jede nicht dokumentierte Verwendung muss leider einem Plagiat (wie Copy/Paste aus Stackoverflow ohne Referenz) gleichgestellt werden und hat die üblichen Konsequenzen.
	118	+Nicht dokumentierte weitergehende KI-Nutzung wird wie die ungekennzeichnete Übernahme fremder Inhalte behandelt und kann entsprechende Konsequenzen haben.
115	115
116	116	**2. Keine vollständige Automatisierung:**
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!
	121	+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.
118	118
119	119	**3. Lernen steht im Vordergrund:**
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.
	124	+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.
121	121
122	122	**4. Individuelle Lösungspflicht:**
123		-Alle wesentlichen Design- und Architekturentscheidungen (z.B. Datenmodell, Hauptlogik, Schnittstellen) müssen selbstständig ohne KI-Tools durch die Studierenden getroffen werden.
	127	+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.
124	124
125		-= Teilaufgabe 4: Implementierung und Test =
	129	+= Implementierung, Test und Qualitätssicherung =
126	126
127		-* Implementieren Sie Ihr Produkt basierend auf dem Entwurf (passen Sie den Entwurf ggf. an)
	131	+* Implementieren Sie das Produkt auf Grundlage des Entwurfs. Wenn sich während der Implementierung Änderungen ergeben, muss der Entwurf entsprechend nachgeführt werden.
128	128	* Projektname muss Gruppenname enthalten!
129	129	* (((
130	130	Maven:
131	131
132	132	* Das Produkt muss sich mit Hilfe von **maven** bauen lassen.
133		-* Das Bauen muss **ohne** mvn install funktionieren.
	137	+* Der Build muss **ohne vorheriges lokales `mvn install`** funktionieren.
134	134	* Die Tests müssen über **maven** ausgeführt werden.
135	135	* **GUI-Tests** müssen sich ausschalten lassen.
136		-* Andere Build-Tools wie Gradle sind nicht (mehr) erlaubt dürfen maximal ergänzend verwendet werden. Maven muss aber funktionsfähig vorhanden sein.
	140	+* Andere Build-Werkzeuge wie Gradle dürfen höchstens ergänzend eingesetzt werden. Der Maven-Build muss vollständig funktionsfähig bleiben.
137	137	)))
138	138	* (((
139	139	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]]
...	...	@@ -150,16 +150,16 @@
150	150	* Installationshandbuch etc.
151	151	)))
152	152	* (((
153		-[[Vorlesungsvideos u.a. zu Testen>>doc:Main.Organisatorisches.WebHome||anchor="HVorlesungsvideos"]]. Testen Sie die wichtigen Klassen mit JUnit, nicht erst am ENDE!
	157	+[[Videos und Materialien u. a. zum Testen>>doc:Main.Videos.WebHome]]. Testen Sie wichtige Klassen kontinuierlich mit JUnit und nicht erst am Projektende.
154	154
155		-* Hilfreich: Dependency Injection (z.B. Google Guice)
	159	+* Nutzen Sie Dependency Injection konsequent; auf der Serverseite insbesondere über Spring.
156	156	* TestFX kann beim Testen der GUI helfen. Wichtiger sind aber Tests der Funktionalitäten!
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.
	161	+* GUI-Tests müssen separat deaktivierbar sein, damit der normale Testlauf auch auf einem CI-/Build-Server ohne grafische Umgebung ausgeführt werden kann.
158	158	* Mocken Sie Abhängigkeiten in Unit-Tests mit Mockito
159	159	)))
160	160	* Führen Sie Integrations- und Endtests durch
161	161	* [[Führen Sie mindestens ein dokumentiertes gruppenweites Code–Review durch>>doc:Main.Projektarbeit.WebHome||anchor="HGruppenweitesCodeReview28Team-Review29"]]
162		-* Nutzen Sie Tools wie FindBugs, Checkstyle oder SonarLint
	166	+* Nutzen Sie Werkzeuge zur statischen Analyse und Qualitätssicherung, z. B. SpotBugs, Checkstyle, SonarLint oder SonarQube.
163	163	* (((
164	164	**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!)**
165	165
...	...	@@ -167,6 +167,6 @@
167	167	)))
168	168	* In Scrum muss ein Produktinkrement getestet und lauffähig sein.
169	169	* Versuchen Sie möglichst früh und regelmäßig die aktuelle Version auch auf dem Rechner in der Arbi zu deployen.
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.Softwareentwicklung.WebHome||anchor="HAnforderungen:NutzungvonKITools"]]
	174	+* 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.
	175	+* Beachten Sie auch die Hinweise zur [[Verwendung von KI>>doc:Main.Softwareentwicklung.WebHome||anchor="HNutzunggenerativerKI-Werkzeuge"]]
172	172