Changes for page Glossar

Summary

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

Details

Page properties

Content

...	...	@@ -1,116 +1,0 @@
1		-{{info}}
2		-**Worum geht es auf dieser Seite?**
3		-
4		-Das Glossar erklärt **zentrale Begriffe in der Bedeutung, in der sie im Softwareprojekt verwendet werden**. Es ist bewusst kein vollständiges Informatiklexikon.
5		-
6		-Wenn Sie nicht die Bedeutung, sondern den Ablageort einer Information suchen, verwenden Sie das [[Stichwortverzeichnis>>doc:Main.Index.WebHome]].
7		-{{/info}}
8		-
9		-{{toc/}}
10		-
11		-= Akzeptanzkriterium =
12		-Eine überprüfbare Bedingung, anhand der entschieden werden kann, ob eine Anforderung bzw. User Story erfüllt ist. Siehe [[Scrum>>doc:Main.Scrum.WebHome]].
13		-
14		-= API =
15		-**Application Programming Interface.** Eine definierte Schnittstelle zwischen Softwarekomponenten. Im Basisprojekt ist insbesondere die REST-API zwischen Client und Server relevant. Siehe [[Basisprojekt>>doc:Main.Basisprojekt.WebHome]].
16		-
17		-= Branch =
18		-Ein Entwicklungszweig in Git, in dem Änderungen getrennt vorbereitet und anschließend kontrolliert integriert werden können. Siehe [[GitLab Erklärungen>>doc:Main.GitLab.WebHome]].
19		-
20		-= CI / CI-CD =
21		-**Continuous Integration** bezeichnet das regelmäßige automatisierte Bauen und Testen des Projekts. Dafür werden GitLab-Pipelines eingesetzt. Siehe [[GitLab Erklärungen>>doc:Main.GitLab.WebHome]].
22		-
23		-= Code-Review =
24		-Systematische Prüfung von Quellcode durch andere Personen. Im Softwareprojekt gibt es Reviews bei Merge Requests und ein ausführlicheres gruppenweites Team-Review. Siehe [[Projektarbeit>>doc:Main.Projektarbeit.WebHome]].
25		-
26		-= Commit =
27		-Ein gespeicherter Änderungsstand in Git. Commits sollten zusammengehörige Änderungen enthalten und verständlich beschrieben sein.
28		-
29		-= Definition of Done =
30		-Von der Gruppe vereinbarte Kriterien dafür, wann eine Aufgabe tatsächlich abgeschlossen ist. Siehe [[Scrum>>doc:Main.Scrum.WebHome]].
31		-
32		-= Definition of Ready =
33		-Von der Gruppe vereinbarte Kriterien dafür, wann eine Aufgabe ausreichend verstanden und vorbereitet ist, um sinnvoll bearbeitet zu werden. Siehe [[Scrum>>doc:Main.Scrum.WebHome]].
34		-
35		-= DTO =
36		-**Data Transfer Object.** Datenobjekt für die gezielte Übertragung zwischen Komponenten bzw. über eine Schnittstelle. Siehe [[Basisprojekt>>doc:Main.Basisprojekt.WebHome]].
37		-
38		-= Epic =
39		-Ein größerer fachlicher Themenbereich bzw. ein größeres Feature, das mehrere Issues umfassen kann. Ein Epic ist **nicht** das Product Backlog. Siehe [[GitLab Erklärungen>>doc:Main.GitLab.WebHome]].
40		-
41		-= Git =
42		-Verteiltes Versionsverwaltungssystem, das im Softwareprojekt zur Verwaltung des Quellcodes verwendet wird.
43		-
44		-= Issue =
45		-Ein GitLab-Eintrag, mit dem im Softwareprojekt insbesondere User Stories, Bugs oder Aufgaben dokumentiert und verfolgt werden. Siehe [[GitLab Erklärungen>>doc:Main.GitLab.WebHome]].
46		-
47		-= Iteration =
48		-GitLab-Begriff für einen zeitlich begrenzten Arbeitsabschnitt. Im Softwareprojekt werden Iterations zur Abbildung von Sprints verwendet.
49		-
50		-= Meilenstein =
51		-Ein wichtiger fachlicher Projektstand, zu dem ein nachvollziehbares Ergebnis erreicht sein soll. Siehe [[Softwareentwicklung>>doc:Main.Softwareentwicklung.WebHome]].
52		-
53		-= Merge Request =
54		-GitLab-Funktion, mit der Änderungen aus einem Branch zur Integration vorgeschlagen, diskutiert und reviewt werden können. Entspricht weitgehend einem **Pull Request**.
55		-
56		-= Mocking =
57		-Testtechnik, bei der echte Abhängigkeiten durch kontrollierbare Ersatzobjekte ersetzt werden. Im Softwareprojekt wird beispielsweise Mockito verwendet.
58		-
59		-= Model-View-Presenter (MVP) =
60		-Architekturmuster zur Trennung von Darstellung, Präsentationslogik und Modell. Für einen JavaFX-Client gelten entsprechende MVP-Anforderungen.
61		-
62		-= OpenAPI =
63		-Maschinenlesbare Beschreibung einer HTTP-/REST-Schnittstelle. Im Basisprojekt werden damit Endpunkte, Operationen und Datenstrukturen festgelegt und teilweise Code generiert.
64		-
65		-= Pair Programming =
66		-Arbeitsweise, bei der zwei Personen gemeinsam an derselben Programmieraufgabe arbeiten. Sie kann besonders zur Wissensverteilung und bei schwierigen Aufgaben sinnvoll sein.
67		-
68		-= Product Backlog =
69		-Priorisierte Gesamtheit der noch offenen Produktanforderungen. Im Softwareprojekt werden diese typischerweise als Issues bzw. User Stories in GitLab gepflegt.
70		-
71		-= Projekttagebuch =
72		-Fortlaufende Dokumentation wichtiger Ereignisse und Entscheidungen im Projektverlauf. Siehe [[Projektarbeit>>doc:Main.Projektarbeit.WebHome]].
73		-
74		-= REST =
75		-Architekturstil für Web-Schnittstellen. Im Basisprojekt wird REST über HTTP für klassische Request/Response-Kommunikation eingesetzt.
76		-
77		-= Retrospektive =
78		-Scrum-Ereignis, in dem die Gruppe ihre Zusammenarbeit reflektiert und konkrete Verbesserungen für den nächsten Sprint vereinbart.
79		-
80		-= Scrum Master =
81		-Scrum-Rolle, die das Team bei der sinnvollen Anwendung von Scrum unterstützt und bei organisatorischen Hindernissen hilft.
82		-
83		-= Sprint =
84		-Zeitlich begrenzter Entwicklungsabschnitt in Scrum mit einem definierten Ziel.
85		-
86		-= Sprint Backlog =
87		-Die für einen Sprint ausgewählten und konkretisierten Arbeiten.
88		-
89		-= Sprint Planning =
90		-Scrum-Ereignis zur Vorbereitung eines Sprints: Sprint-Ziel, User Stories, Schätzungen und konkrete Tasks werden betrachtet.
91		-
92		-= STOMP =
93		-**Streaming Text Oriented Messaging Protocol.** Im Basisprojekt wird STOMP auf WebSockets für Nachrichten über Topics verwendet.
94		-
95		-= Story Point =
96		-Relative Schätzeinheit für Umfang bzw. Komplexität einer User Story. Entscheidend ist der Vergleich mit anderen Stories, nicht ein fester Zeitwert.
97		-
98		-= Task =
99		-Konkreter Arbeitsschritt. Größere Issues bzw. User Stories können in kleinere Tasks zerlegt werden.
100		-
101		-= Unit-Test =
102		-Automatisierter Test einer möglichst kleinen, abgegrenzten Einheit der Software.
103		-
104		-= User Story =
105		-Kurze Beschreibung einer fachlichen Anforderung aus Sicht eines Nutzers bzw. einer Rolle. User Stories gehören in das Product Backlog und sollten verständlich, schätzbar und testbar sein.
106		-
107		-= WebSocket =
108		-Bidirektionale, dauerhafte Verbindung zwischen Client und Server. Im Basisprojekt wird sie für asynchrone serverseitige Ereignisse eingesetzt.
109		-
110		-= Zeiterfassung =
111		-Dokumentation der für Projektarbeiten aufgewendeten Zeit auf GitLab-Issues bzw. dafür vorgesehenen Tickets. Die Angaben dienen der Nachvollziehbarkeit und sind nicht alleiniger Maßstab für die Bewertung.
112		-
113		-= Siehe auch =
114		-* [[Stichwortverzeichnis>>doc:Main.Index.WebHome]]
115		-* [[Wiki-Startseite>>doc:Main.WebHome]]
116		-