Skip to Content

Wiki source code of Anforderungen Software

Version 2.2 by Pascal Meyer on 2025/07/30 18:37
Hide last authors
Pascal Meyer 1.1 1 {{toc/}}
2
3 = Anforderungen: Spielumsetzung =
4
5 * Client-Server-Umsetzung (Spiellogik auf Server!)
6 ** Komplett Java-basiert (z.B. mit Web-Services, RMI)
7 * Aus didaktischen Gründen (nicht optional!):
8 ** „beliebig“ viele registrierte Nutzer
9 ** mehrere Spielrunden gleichzeitig im Server
10 ** Spieler können **vom selben Client aus** an mehreren Spielen teilnehmen (also nicht mehrere Clients starten und dann teilnehmen)
11 * Chat 
12 ** globaler Chat im Hauptmenü
13 ** Lobby und Spielechats
14 * Nutzerverwaltung
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**)
17 ** einfache Austauschbarkeit des DBMS-Servers (unterschiedliche Verbindungen, unterschiedliche Hersteller)
18 * KI (je nach Spiel, siehe Start-Folien)
19 ** Das Spiel muss die Integration einer KI unterstützen
20 ** Es muss eine einfache (z.B. zufallsbasierte) KI umgesetzt werden
21 * Ansatz muss Model-View-Presenter Anforderungen erfüllen
22 * Muss mit möglichst wenig Aufwand möglich sein, andere Client-Arten anzubinden (z.B. Console)  u.a. Spiellogik auf Server
23 * Visuelles Thema/Design darf im vorgegebenen Rahmen variiert werden (muss aber nicht!!)
24 * Achtung!
25 ** Wichtig ist guter, erweiterbarer und wartbarer Code und eine gute Benutzerführung
26 ** Wenn das Spiel dann zusätzlich noch optisch gut aussieht, um so besser.
27
Pascal Meyer 1.2 28 {{info}}
Pascal Meyer 1.1 29 **Wichtig!**
30
31 * Überlegen Sie genau, welche Features Sie umsetzen können und welche weggelassen werden sollten
32 * Lieber etwas weniger sehr gut umsetzen, als vieles schlecht! Qualität vor Quantität!
33 * Bedienbarkeit ist wichtig! Optisches Design weniger!
34 * „KISS: Keep it simple stupid“
35 * Fokus auf das Wichtige! Es gibt keine Zusatzpunkte für Dinge wie
36 ** Freundeslisten
37 ** privaten Chat
38 ** 3D
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 * Sie haben nur begrenzte Ressourcen zur Verfügung und müssen das auch vertreten!
Pascal Meyer 1.2 41 {{/info}}
Pascal Meyer 1.1 42
43 = Anforderungen: Die vordefinierten Meilensteine =
44
45 Um gut in das SWP zu starten, gibt es drei **vordefinierte** Meilensteine.
46
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.
49 * Es gibt eine Präsentation für den Prototypen (Meilenstein X), im zweiten Semester.
50 * Es gibt eine Präsentation für das finale Produkt (Endabnahme) zum Ende des zweiten Semesters.
51
52 == Meilenstein 1: Basisarchitektur mit UserManagement (Vertikaler Durchstich, wird gemeinsam gemacht) ==
53
54 * Hier geht es darum, die Basisarchitektur des SWP kennen zu lernen und gemeinsam in das SWP hineinzufinden.
55 * Die Speicherung der Nutzer erfolgt im Hauptspeicher, d.h. nach einem Neustart, sind keine Nutzer mehr vorhanden (es gibt allerdings vordefinierte Nutzer, die später wieder entfernt werden müssen)
56 * Neue Nutzer sollen sich für das Spiel registrieren können.
57 * Registrierte Nutzer sollen sich am Spiel anmelden können.
58 * Die Nutzer sollen nach dem Einloggen in das Hauptmenü gelangen und dort alle Nutzer sehen, die auch eingeloggt sind.
59
Pascal Meyer 1.2 60 {{success}}
61 **Hinweis:**
Pascal Meyer 1.1 62
63 Hinweis: Dieser Meilenstein wird gemeinsam als Einführung für das Software Projekt durchgeführt. Es findet am Ende also keine Präsentation statt.
Pascal Meyer 1.2 64 {{/success}}
Pascal Meyer 1.1 65
66 == Meilenstein 2: Hauptmenü, Chat, Spiel-Ansätze ==
67
68 * Die Nutzer im Hauptmenü und im Spielefenster sollen untereinander Nachrichten in einem Chat versenden können.
69 * Es soll kein Refresh-Button verwendet werden, um die Nutzerliste im Hauptmenue (bzw. der Lobby) zu aktualisieren oder um neue Chat-Nachrichten abzurufen.
70 * Es soll eine Lister aller existierenden Lobbies geben.
71 * Es soll ein einfaches Modell des **Spielmodells** vorliegen, d.h. es sollten das statische Modell (Klassendiagramm) und einige dynamische Modelle (Aktivitätsdiagramm, ggf. auch Zustandsdiagramm oder Sequenzdiagramm) vorliegen.
72 * Idealerweise kann man z.B. mit Hilfe der Console (oder eine einfachen GUI) schon ein wenig mit dem Spiel interagieren, das ist aber nicht zwingend notwendig!
73
74 == Meilensteine 3 - (X-1) ==
75
76 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!
77
78 == Meilenstein X "Prototyp" ==
79
80 * Es soll das UserManagement mit Hilfe einer relationalen Datenbank realisiert werden. Dazu soll das Schema für die Nutzerinformationen modelliert und über Java zugreifbar sein. Der Zugriff soll grundsätzlich auf beliebige per JDBC ansprechbare Datenbanken erfolgen und mit möglichst wenig Aufwand austauschbar sein (maximal eine neue Klasse). Außerhalb der Klasse(n), die den Datenbankzugriff regeln, darf niemand wissen, auf welche Weise die Daten gespeichert sind.
81 * Hier soll es eine erste, möglichst vollständige Version des Spiels geben (Feature-Complete).
82 * Es dürfen noch Fehler drin sein und die Bedienbarkeit muss noch nicht ganz ausgereift sein.
83 * Es dürfen danach noch Änderungen und Erweiterungen gemacht werden.
84
Pascal Meyer 1.2 85 {{success}}
Pascal Meyer 1.5 86 **Hinweis:**
Pascal Meyer 1.2 87
Pascal Meyer 1.1 88 * Die Anforderungen sind die **Minimalanforderungen**.
89 * Es darf ruhig zum jeweiligen Zeitpunkt schon mehr realisiert werden.
90 * Aber: Fokus auf das Wichtige!
91 ** Keine Freundeslisten
92 ** Keinen privaten Chat
93 ** kein 3D etc.
94 ** Die Spielanleitung kann als PDF zur Verfügung gestellt werden.
95 * 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!
Pascal Meyer 1.5 96 {{/success}}
Pascal Meyer 1.1 97
98 = Anforderungen: Dokumentation =
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:
101
102 * Eine allgemeine Einleitung für das Dokument. Worum geht es und wie ist das Dokument aufgebaut.
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...
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.
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.
109 * Darstellung der Realisierung
110 ** Allgemeine/Übergreifende Konzepte, z.B. wie wurde MVP realisiert
111 *** Darstellung der Architektur und Aufteilung des Gesamtsystems in Module
112 ** Für jedes Modul (Lobby, Chat, Game, ...):
113 *** Allgemeine Beschreibung
114 *** Im Client ggf. Screenshots
115 *** Darstellung der Klassen und Zusammenhänge der Klasse. Hier gerne auch ausschnittsweise, um ein besseren Verständnis zu bekommen. Vollständiges Klassendiagramm des Moduls im Anhang (auch hier nicht zwingend mit allen Attributen und Methoden).
116 **** Zur Darstellung der Zusammenhänge ist es i.d.R. sehr sinnvoll, Klassendiagramme ohne Attribute und Methoden zu verwenden.
117 *** Ganz wichtig ist auch die Darstellung der Abläufe (Dynamikdiagramme).
118 **** Wenn man die Kommunikation zwischen Klassen darstellen möchte: Sequenzdiagramm
119 **** Wenn man allgemeine Abläufe hat: Aktivitätsdiagramme
120 **** Wenn man unterschiedliche Zustände durchläuft: Zustandsdiagramm
121 **** Diagramme müssen erläutert werden. Ein Diagramm ohne Beschreibung ist faktisch nicht vorhanden. Es muss nicht alles im Detail erklärt werden, aber auf spezielle Besonderheiten oder die Verwendung von Pattern hingewiesen werden. Es sollte nicht einfach ein Diagramm an das nächste gehängt werden, sondern z.B. gesagt werden: „In dem Diagramm xy ist zu sehen, wie der grundsätzliche Ablauf eines Spielzugs ist. Dabei wird zunächst...“
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 **** Wenn man komplexere Algorithmen darstellen möchte, kann es besser sein, die Darstellung mit Pseudocode vorzunehmen.
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.
125 ** Bei Spiel: Regelabweichungen darstellen und begründen
126 ** (Java-)Quellcode im Text möglichst vermeiden. Pseudocode kann für die Beschreibung von komplexeren Algorithmen verwendet werden.
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.
128 ** Die Konzepte des Servers sollten mehr Aufmerksamkeit bekommen, als die den Clients.
129 ** Das Spiel ist das wichtigste im SWP, es sollte also im Realisierungskapitel den größen Umfang bekommen.
130 * Darstellung der Tests
131 ** Nach welchem Vorgehen wurde getestet?
132 ** Welche Tests gibt es?
133 *** Hinweis: Hier nicht jeden einzelnen Unit-Test aufführen, das ist unnötige Arbeit!
134 ** Wie sieht die Testabdeckung aus?
135 ** Was wurde nicht automatisiert getestet und wie wurde sichergestellt, dass die Funktionalität trotzdem korrekt ist?
136 ** Beschreibung des (mindestens einmal) durchgeführten gruppenweiten Codereviews. Aus Gründen der Bewertung ist es u.U. sinnvoll, Pull-Request mit beispielhaften Reviews in Git nicht zu löschen.
137 * Darstellung des durchgeführten Projektmanagements
138 ** Rollen
139 ** Arbeitsweise
140 ** Meilensteine
141 ** Rückblick über die Sprints/ Projekttagebuch
142 ** Verwendete Frameworks, Bibliotheken und Tools
143 * Ausblick: Was könnte man noch machen? Hier auf eine sinnvolle Reihenfolge achten
144 * Fazit:
145 ** Rückblick auf das vergangene Jahr.
146 ** Was hat man gelernt?
147 ** Was hat gut funktioniert, was weniger gut?
148 ** Feedback zum Software Projekt allgemein (es geht um die Durchführung der Veranstaltung als solches, d.h. z.B. was kann an der Veranstaltung als solches verbessert werden):
149 *** SWP Retrospektive: „Do More“, „Do Less“, „Keep Doing“, „Start Doing“, „Stop Doing“
150 * Anhang:
151 ** Ggf. vollständige Klassendiagramme (Ohne weitere Erläuterung)
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 * Glossar mit Begriffen des Gegenstandes/Spiels
154 * Index  (Falls Dokument mit LaTeX erstellt, bei Confluence-Export nicht möglich/notwendig)
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.
157
158 Zum Produkt selber noch notwendig:
159
160 * Eine Spielanleitung: Über die Regeln des Spiels hinausgehende Beschreibung, wie die Bedienung erfolgt
161 * Wie erfolgt die Installation und die Konfiguration?
162
163 Im Git-Repository gibt es eine Dokumentationsvorlage für LaTeX.
164
Pascal Meyer 1.5 165 {{success}}
166 **Hinweis:**
Pascal Meyer 1.1 167
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 * 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.
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/]]
Pascal Meyer 1.5 172 {{/success}}
Pascal Meyer 1.1 173
174 = Anforderungen: Nutzung von KI Tools =
175
176 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.
177
178 **~1. Transparenzpflicht:**
179 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
180
Pascal Meyer 2.1 181 |~/~/ Generated with ChatGPT at 31.03.2025
Pascal Meyer 1.1 182
183 **Ausnahme**: Die Vervollständigung einer Zeile (durch Tab) ist nicht speziell zu dokumentieren ("Local Full Line Completion"), alles weitergehende auf jeden Fall.
184
185 Jede nicht dokumentierte Verwendung muss leider einem Plagiat (wie Copy/Paste aus Stackoverflow ohne Referenz) gleichgestellt werden und hat die üblichen Konsequenzen.
186
187 **2. Keine vollständige Automatisierung:**
188 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!
189
190 **3. Lernen steht im Vordergrund:**
191 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.
192
193 **4. Individuelle Lösungspflicht:**
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]]