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,16 +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		-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		-
7	7	{{toc/}}
8	8
9		-= Technische und funktionale Anforderungen =
	5	+= Anforderungen: Spielumsetzung =
10	10
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.
	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 ;-)
14	14	* Aus didaktischen Gründen (nicht optional!):
15	15	** „beliebig“ viele registrierte Nutzer
16	16	** mehrere Spielrunden gleichzeitig im Server
...	...	@@ -22,15 +22,15 @@
22	22	** 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.
23	23	** relationales DBMS
24	24	** einfache Austauschbarkeit des DBMS-Servers (unterschiedliche Verbindungen, unterschiedliche Hersteller)
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.
	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
30	30	* Visuelles Thema/Design darf im vorgegebenen Rahmen variiert werden (muss aber nicht!!)
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.
	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.
34	34
35	35	{{info}}
36	36	**Wichtig!**
...	...	@@ -38,7 +38,7 @@
38	38	* Überlegen Sie genau, welche Features Sie umsetzen können und welche weggelassen werden sollten
39	39	* Lieber etwas weniger sehr gut umsetzen, als vieles schlecht! Qualität vor Quantität!
40	40	* Bedienbarkeit ist wichtig! Optisches Design weniger!
41		-* KISS: Lösungen möglichst einfach und nachvollziehbar halten.
	37	+* „KISS: Keep it simple stupid“
42	42	* Fokus auf das Wichtige! Es gibt keine Zusatzpunkte für Dinge wie
43	43	** Freundeslisten
44	44	** privaten Chat
...	...	@@ -47,12 +47,12 @@
47	47	* Sie haben nur begrenzte Ressourcen zur Verfügung und müssen das auch vertreten!
48	48	{{/info}}
49	49
50		-= Vorgegebene Meilensteine =
	46	+= Anforderungen: Die vordefinierten Meilensteine =
51	51
52		-Für den Einstieg und zur Orientierung im Projektverlauf gibt es mehrere **vorgegebene Meilensteine**. Zusätzlich definiert jede Gruppe eigene fachliche Meilensteine.
	48	+Um gut in das SWP zu starten, gibt es drei **vordefinierte** Meilensteine.
53	53
54	54	* Der erste Meilenstein ist durch die gemeinsame Bearbeitung der Übungsaufgaben erreicht.
55		-* 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.Präsentationen.WebHome]]. Das ist die erste Präsentation bei mir.
56	56	* Es gibt eine Präsentation für den Prototypen (Meilenstein X), im zweiten Semester.
57	57	* Es gibt eine Präsentation für das finale Produkt (Endabnahme) zum Ende des zweiten Semesters.
58	58
...	...	@@ -82,7 +82,7 @@
82	82
83	83	== Meilensteine 3 - (X-1) ==
84	84
85		-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!**
86	86
87	87	== Meilenstein X "Prototyp" ==
88	88
...	...	@@ -104,42 +104,40 @@
104	104	* 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!
105	105	{{/success}}
106	106
107		-= Nutzung generativer KI-Werkzeuge =
	103	+= Anforderungen: Nutzung von KI Tools =
108	108
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.
	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.
110	110
111		-*
112		-**
113		-**1. Transparenzpflicht:
114		-**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
115	115
116	116	|~/~/ Generated with ChatGPT at 31.03.2025
117	117
118	118	**Ausnahme**: Die Vervollständigung einer Zeile (durch Tab) ist nicht speziell zu dokumentieren ("Local Full Line Completion"), alles weitergehende auf jeden Fall.
119	119
120		-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.
121	121
122	122	**2. Keine vollständige Automatisierung:**
123		-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!
124	124
125	125	**3. Lernen steht im Vordergrund:**
126		-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.
127	127
128	128	**4. Individuelle Lösungspflicht:**
129		-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.
130	130
131		-= Implementierung, Test und Qualitätssicherung =
	125	+= Teilaufgabe 4: Implementierung und Test =
132	132
133		-* 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)
134	134	* Projektname muss Gruppenname enthalten!
135	135	* (((
136	136	Maven:
137	137
138	138	* Das Produkt muss sich mit Hilfe von **maven** bauen lassen.
139		-* Der Build muss **ohne vorheriges lokales `mvn install`** funktionieren.
	133	+* Das Bauen muss **ohne** mvn install funktionieren.
140	140	* Die Tests müssen über **maven** ausgeführt werden.
141	141	* **GUI-Tests** müssen sich ausschalten lassen.
142		-* 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.
143	143	)))
144	144	* (((
145	145	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]]
...	...	@@ -156,22 +156,23 @@
156	156	* Installationshandbuch etc.
157	157	)))
158	158	* (((
159		-[[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!
160	160
161		-* Nutzen Sie Dependency Injection konsequent; auf der Serverseite insbesondere über Spring.
	155	+* Hilfreich: Dependency Injection (z.B. Google Guice)
162	162	* TestFX kann beim Testen der GUI helfen. Wichtiger sind aber Tests der Funktionalitäten!
163		-* 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.
164	164	* Mocken Sie Abhängigkeiten in Unit-Tests mit Mockito
165	165	)))
166	166	* Führen Sie Integrations- und Endtests durch
167		-* [[Führen Sie mindestens ein dokumentiertes gruppenweites Code–Review durch>>doc:Main.Projektarbeit.WebHome||anchor="HGruppenweitesCode-Review28Team-Review29"]]
168		-* 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.Projektarbeit.WebHome||anchor="HGruppenweitesCodeReview28Team-Review29"]]
	162	+* Nutzen Sie Tools wie FindBugs, Checkstyle oder SonarLint
169	169	* (((
170	170	**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!)**
171	171
172		-[[image:Warnung.png||alt="Warnung"]]
	166	+[[image:Main.Aufgabenstellung.WebHome@Warnung.png||alt="Warnung"]]
173	173	)))
174	174	* In Scrum muss ein Produktinkrement getestet und lauffähig sein.
175	175	* Versuchen Sie möglichst früh und regelmäßig die aktuelle Version auch auf dem Rechner in der Arbi zu deployen.
176		-* 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.
177		-* 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.Softwareentwicklung.WebHome||anchor="HAnforderungen:NutzungvonKITools"]]
	172	+

Warnung.png

Author

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

Size

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

Content