Changes for page Glossar

Summary

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

Details

Page properties

Content

...	...	@@ -1,0 +1,116 @@
	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	+