Changes for page Anforderungen Software

Summary

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

Details

insert_drive_file Page properties

Author

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

Content

...	...	@@ -1,9 +1,12 @@
	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 =
4	4
5	5	* Client-Server-Umsetzung (Spiellogik auf Server!)
6		-** Komplett Java-basiert (z.B. mit Web-Services, RMI)
	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 ;-)
7	7	* Aus didaktischen Gründen (nicht optional!):
8	8	** „beliebig“ viele registrierte Nutzer
9	9	** mehrere Spielrunden gleichzeitig im Server
...	...	@@ -13,7 +13,7 @@
13	13	** Lobby und Spielechats
14	14	* Nutzerverwaltung
15	15	** 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.
16		-** relationales DBMS (**Zugriff mit JDBC, kein Hibernate oder ähnliches**)
	19	+** relationales DBMS
17	17	** einfache Austauschbarkeit des DBMS-Servers (unterschiedliche Verbindungen, unterschiedliche Hersteller)
18	18	* KI (je nach Spiel, siehe Start-Folien)
19	19	** Das Spiel muss die Integration einer KI unterstützen
...	...	@@ -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.
	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.
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
...	...	@@ -97,15 +97,15 @@
97	97
98	98	= Anforderungen: Dokumentation =
99	99
100		-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:
	103	+Im Softwareprojekt muss am Ende zusätzlich zum eigentlichen Produkt ein Dokument abgegeben werden, welches im Wesentlichen die folgenden Aspekte enthalten sollte:
101	101
102	102	* Eine allgemeine Einleitung für das Dokument. Worum geht es und wie ist das Dokument aufgebaut.
103	103	* Grundsätzlich sollte jeder Abschnitt kurz eingeleitet werden und jeden Kapitel sollte eine kurze Zusammenfassung bekommen.
104		-* Quellen müssen angebenen werden, also z.B. nicht einfach Text von einer Web-Seite kopieren. Das kann u.U. als Plagiat ausgelegt werden...
	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...
105	105	* Eine Darstellung der ermittelten Anforderungen.
106		-** 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.
	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.
107	107	** Ggf. eine Darstellung/Auflistung nicht umgesetzter User Stories. Die kann noch einmal zeigen, welche kreativen Ideen zeitlich nicht mehr umgesetzt wurden
108		-** Die Stories sollten möglichst gruppiert (z.B. nach Nutzerverwaltung, Hauptmenue/Lobby, etc.) werden.
	111	+** Die Stories sollten möglichst gruppiert (z.B. nach Nutzerverwaltung, Hauptmenü/Lobby, etc.) werden.
109	109	* Darstellung der Realisierung
110	110	** Allgemeine/Übergreifende Konzepte, z.B. wie wurde MVP realisiert
111	111	*** Darstellung der Architektur und Aufteilung des Gesamtsystems in Module
...	...	@@ -122,6 +122,7 @@
122	122	**** 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“.
123	123	**** Wenn man komplexere Algorithmen darstellen möchte, kann es besser sein, die Darstellung mit Pseudocode vorzunehmen.
124	124	*** 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 Diagramme in Gitlab auch textuell erzeugen: [[https:~~/~~/docs.gitlab.com/user/markdown/#diagrams-and-flowcharts>>https://docs.gitlab.com/user/markdown/#diagrams-and-flowcharts]] Macht es u.U. gerade bei komplexen Diagrammen einfacher.
125	125	** Bei Spiel: Regelabweichungen darstellen und begründen
126	126	** (Java-)Quellcode im Text möglichst vermeiden. Pseudocode kann für die Beschreibung von komplexeren Algorithmen verwendet werden.
127	127	** **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.
...	...	@@ -151,9 +151,9 @@
151	151	** Ggf. vollständige Klassendiagramme (Ohne weitere Erläuterung)
152	152	** 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.
153	153	* Glossar mit Begriffen des Gegenstandes/Spiels
154		-* Index  (Falls Dokument mit LaTeX erstellt, bei Confluence-Export nicht möglich/notwendig)
	158	+* Index  (Falls Dokument mit LaTeX erstellt)
155	155
156		-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.
	160	+Ich werde immer wieder gefragt, wie viele 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.
157	157
158	158	Zum Produkt selber noch notwendig:
159	159
...	...	@@ -167,7 +167,7 @@
167	167
168	168	* 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.
169	169	* Falls etwas nicht korrekt funktioniert, bitte auch eine kurze Nachricht. Ich kümmere mich.
170		-* Gruppen, die ihre Dokumentation auch im git pflegen wollen, können mir einen Nachricht schicken und ich richte das Repo dann passend ein.
	174	+* Gruppen, die ihre Dokumentation auch im Git pflegen wollen, können mir einen Nachricht schicken und ich richte das Repo dann passend ein.
171	171	* [[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/]]
172	172	{{/success}}
173	173
...	...	@@ -192,35 +192,3 @@
192	192
193	193	**4. Individuelle Lösungspflicht:**
194	194	Alle wesentlichen Design- und Architekturentscheidungen (z.B. Datenmodell, Hauptlogik, Schnittstellen) müssen selbstständig ohne KI-Tools durch die Studierenden getroffen werden.
195		-
196		-= Anforderungen: Aufwand =
197		-
198		-* SWP hat 3+6 KP (wobei 1 KP ca 30 h sind)
199		-** (ca.) 90 h + 180 h = 270 h pro Person
200		-** bei 10 Personen pro Gruppe: 10*270 h = 2700 h
201		-** Nur wenn alle (in die selbe Richtung) mitziehen, kann das SWP mit einigermaßen vertretbarem Aufwand durchgeführt werden
202		-** Wichtig: Planung was getan wird und was nicht (100 % in allen Übungsblättern schafft man auch nicht mit der normalen Stundenzahl)
203		-** Programmierung verleitet häufig dazu mehr zu tun … ;-)
204		-* Trotzdem natürlich: Leistung = Arbeit/Zeit :-)
205		-
206		-Anmerkung: Die Zahlen sind natürlich nur als Richtschnur zu sehen. Wichtig ist, dass man kontinuierlich an der Aufgabe dran bleibt, damit nicht am Ende die gesamten Stunden auf einen "einschlagen".
207		-
208		-**Noch ein Nachtrag zum Aufwand:**
209		-
210		-Es wird oft gesagt, dass 9 KP für das Software Projekt zu wenig sind. Hier liegt leider ein kleines Missverständnis vor. Das SWP sollte (so ist es zumindest geplant) so ausgelegt sein, dass ein durchschnittlicher Studierender mit den Kenntnissen die als Vorerfahrung verlangt werden mit dem Aufwand von 9 KP (also rund 250 Stunden) in der Lage sein sollte das Modul zu bestehen.
211		-
212		-Das ganze ist immer relativ einfach zu definieren, wenn es keine Gruppenarbeit ist, dann kann man den Aufwand für das Modul auf eine einzelne Person ausrichten. Wir haben nun aber im SWP die Besonderheit, dass es Gruppenarbeit ist, und zwar keine einfache Gruppenarbeit mit 2 oder 3 Personen sondern mit bis zu 13.
213		-
214		-Ich muss nun die Aufgabe so definieren, dass alle 13 Personen dieser Gruppe die Chance bekommen können, die 9 KP auch leisten zu können, d.h. es muss soviel "Arbeit" da sein, dass niemand aufgrund von fehlenden Aufgaben nichts für das Modul sinnvolles tun kann. Da es nun aber vorkommt, dass Personen nicht so gut mitziehen können oder wollen oder dass Personen das Modul abbrechen, könnte der Eindruck entstehen, dass die Gruppe mit weniger Personen das selbe leisten muss, wie eine Gruppe mit voller Besetzung. Das ist nicht der Fall! Bei der Bewertung der Gruppenleistung wird auch die Größe der Gruppe für die finale Bewertung herangezogen. Dabei ist ergänzend noch zu sagen, dass mit der Größe der Gruppe auch der Koordinierungaufwand steigt. Es ist also nicht so, dass eine größere Gruppe automatisch linear mehr schafft.
215		-
216		-Also, ich versuche immer eine Aufgabe zu finden, die sich so flexibel erweitern oder einschränken lässt, dass die ganze Gruppe etwas zu tun hat, aber Einzelne nicht mehr tun sollen. Das klappt zugegebenermaßen mal mehr und mal weniger, ist aber immer mein Bemühen. Die Stunden die aufgeschrieben werden sollen, sollen auch dazu dienen, zu sehen, wieviel Aufwand tatsächlich geleistet wird. Ich gehe davon aus, dass die Stunden korrekt sind, da sie auch essentiell für die Bewertung sind. In den letzten Jahren gab es tatsächlich immer einige Studierende, den Aufwand nach oben übertroffen haben (und zwar teilweise deutlich). Das war aber in der Summe der Teilnehmer immer nur ein kleinerer Teil. Die meisten Studierenden waren tatsächlich eher deutlich unterhalb des vorgegebenen Aufwands.
217		-
218		-Ich habe schon mal darüber nachgedacht, die Stunden nach oben hin zu deckeln (d.h. sowas wie "Strafpunkte" zu vergeben, wenn man deutlich zu viele Stunden leistet), das widerstrebt mir aber, da es sich hier um eine Lehrveranstaltung handelt und ich niemanden für sein freiwilliges Engagement bestrafen möchte. I.d.R. sprechen die Tutoren die Personen an, die deutlich zu vielen Stunden leisten.
219		-
220		-Ein anderes Problem ist sicherlich der gefühlte Aufwand, in dem man die z.B. 6 KP die man für eine Vorlesung bekommt mit den 9 KP vergleicht, die man für das SWP bekommt. Der große Unterschied hier: Man kann theoretische Konzepte sehr schnell verstehen oder braucht etwas Zeit. Die KP Berechnung für eine VL geht davon aus, dass man die Inhalte der Vorlesung vor- und nachbereitet und seien wir mal ehrlich ...[[~[~[image:https://confluence.swl.informatik.uni-oldenburg.de/s/-df7cbn/9203/cnf719/_/images/icons/emoticons/wink.svg~|~|alt="(Zwinkern)"~]~]>>url:https://confluence.swl.informatik.uni-oldenburg.de/s/-df7cbn/9203/cnf719/_/images/icons/emoticons/wink.svg]]
221		-
222		-In einem praktischen Modul kann man aber relativ wenig durch "schnelles Verstehen" herausholen. Man muss die Dinge aktiv tun und da gibt es auch keine Abkürzung indem man sich z.B. ein gutes You Tube Video anschaut und mit Hilfe von "Bolemie-Lernen" es irgendwie schafft, gut durch die Klausur zu kommen. Die Leistung bezieht sich in einem praktischen Modul immer kontinierlich auf die ganze Zeit (hier zwei Semester).
223		-
224		-Was final noch dazukommt: Typischerweise schaffen es nicht alle, gleichmäßig die ganze Zeit an dem Modul zu arbeiten (wenn man mal 28 VL-Wochen nimmt, kommt man übrigens auf eine wöchentliche Arbeitsbelastung von ca. 9-10 Stunden für das Modul und der Besuch einer VL oder des Gruppensitzung decken davon je gerade mal 1,5 h ab) kommt es gerade vor Präsentationen zu erhöhtem Aufwand und der bleibt deutlich nachhaltiger im Kopf hängen, als die 3 Wochen in denen man mal nur so 2-3 h gemacht hat.
225		-
226		-Hier noch mal etwas zum Thema Credit-Points: [[https:~~/~~/www.zeit.de/studium/studienfuehrer-2010/studium-bachelor-leitfaden/seite-3>>url:https://www.zeit.de/studium/studienfuehrer-2010/studium-bachelor-leitfaden/seite-3]]