Skip to Content

Wiki source code of Glossar

Last modified by Marco Grawunder on 2026/08/26 10:11
Show last authors
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]]