Agile Teams, CI/CD und Open Source: Prüfungsvorbereitung für SOFT2412 / COMP9412

Einführung in die Prüfungsinhalte von SOFT2412 / COMP9412

Die Prüfung SOFT2412 / COMP9412 deckt zentrale Themen der agilen Softwareentwicklung ab: empirische Prozesskontrolle, agile Teamdynamik, Test-Driven Development (TDD), Continuous Integration (CI) mit Jenkins und Gradle, sowie Open-Source-Lizenzen. Im Mai 2026, während sich die Tech-Welt auf die nächste Generation von KI-gestützten Entwicklungstools vorbereitet, ist das Verständnis dieser Konzepte relevanter denn je. In diesem Tutorial lernst du die Kernideen anhand von aktuellen Trends und Alltagsbeispielen – ohne die Prüfungsfragen direkt zu lösen.

Empirische Prozesskontrolle: Inspektion, Transparenz und Adaptation

Die empirische Prozesskontrolle ist das Fundament von Scrum. Sie besteht aus drei Säulen: Transparenz, Inspektion und Adaptation. Die Prüfungsfrage 1 fragt nach dem Aspekt, der das häufige Untersuchen von Scrum-Artefakten und die Sicherstellung der Zielerreichung betrifft – das ist die Inspektion. Stell dir vor, du entwickelst eine neue Funktion für eine beliebte KI-App wie ChatGPT 2026. Du würdest regelmäßig den Fortschritt überprüfen (Inspektion), um sicherzustellen, dass das Team auf dem richtigen Weg ist. Falls nötig, passt du den Plan an (Adaptation). Ohne Transparenz – also offene Kommunikation über den Status – wäre Inspektion wirkungslos.

Merke: Inspektion ist das regelmäßige Überprüfen der Artefakte und des Fortschritts, um Abweichungen frühzeitig zu erkennen.

Agile Teams: Größe, Harmonie und gegenseitiger Respekt

Agile Teams arbeiten am besten, wenn sie harmonisch zusammenarbeiten, sich gegenseitig respektieren und Verantwortung teilen. Frage 2 der Prüfung unterstreicht: Größere Teams sind nicht unbedingt besser. Ein Team von 4–5 Senior-Entwicklern klingt verlockend, aber Studien zeigen, dass kleine, cross-funktionale Teams (5–9 Personen) oft effektiver sind. Im Mai 2026, wo Remote-Arbeit und asynchrone Kommunikation Standard sind, ist Teamkohäsion noch wichtiger. Ein Beispiel: Ein E-Sport-Team wie Fnatic gewinnt nicht durch die Anzahl der Spieler, sondern durch Vertrauen und klare Rollen. Genauso in agilen Teams: Jeder trägt Verantwortung für das Produkt, nicht nur für seine Aufgabe.

Semantische Versionierung und Abhängigkeitsmanagement

Semantische Versionierung (SemVer) hilft, Abhängigkeiten zwischen Paketen, Bibliotheken und Plugins zu verwalten. Die Prüfungsfrage 3 prüft, welche Aussage nicht korrekt ist. Wichtig: Ein Patent gewährt das Recht, andere von der Nutzung auszuschließen – das ist kein Bestandteil von SemVer. Eine Codeline spezifiziert die Komponentenversionen eines Systems. In Multi-Version-Systemen gibt es oft mehrere Arbeitsversionen. Stell dir vor, du entwickelst ein Smart-Home-System mit vielen Modulen (Licht, Heizung, Sicherheit). Jedes Modul hat seine eigene Version. SemVer stellt sicher, dass ein Update der Heizungssteuerung nicht die Lichtsteuerung zerstört – ähnlich wie bei App-Updates auf deinem Smartphone.

Test-Driven Development (TDD): Rot-Grün-Refaktorieren

Frage 4 behandelt Mythen über TDD. Richtig ist: Entwicklung in sehr kurzen Zyklen, bei denen Anforderungen in Testfälle umgewandelt werden, die zuerst fehlschlagen müssen (Rot), bevor der Code implementiert wird (Grün). Danach wird refaktoriert. TDD wird nicht ausschließlich von XP-Teams verwendet – es ist in vielen agilen Umgebungen verbreitet. Unit-Tests werden vor dem Code geschrieben, nicht danach. Und ja, TDD kann anfangs langsamer erscheinen, aber die Qualität steigt, und spätere Fehlerbehebungen werden schneller. Ein aktuelles Beispiel: Die Entwicklung der KI-gestützten Code-Assistenten wie GitHub Copilot 2026 profitiert von TDD, weil die Tests die Erwartungen klar definieren.

Arbeitssoftware als Maß des Fortschritts

Frage 5 fragt nach dem agilen Mindset gegenüber funktionierender Software. Agilisten liefern häufig aus und betrachten funktionierende Software als primäres Maß für Fortschritt. Nicht Teil dieses Mindsets ist die Annahme, dass die ausgelieferte Software die finale Version aller Features enthält – agil bedeutet iterative Verbesserung. Denk an Social-Media-Plattformen: TikTok bringt ständig neue Filter und Funktionen in kleinen Updates, nicht erst eine riesige „finale“ Version. So erhält das Team schnelles Feedback von den Nutzern.

Continuous Integration und Continuous Delivery

Frage 6 prüft das Verständnis von CI/CD. Continuous Integration bedeutet, dass Teammitglieder ihre Arbeit mehrmals täglich integrieren. Jenkins speichert Artefakte, die während der Pipeline erzeugt werden. Unit-Tests können oft ohne die gesamte Anwendung gestartet werden. Continuous Delivery geht noch einen Schritt weiter: Die Software ist jederzeit auslieferbar. Die falsche Aussage in der Prüfung: „Continuous Delivery ist eine Praxis, bei der Teammitglieder ihre Arbeit häufig integrieren“ – das ist eigentlich Continuous Integration. Stell dir vor, du arbeitest an einer Online-Banking-App. Jeder Commit wird automatisch getestet und in einer staging-Umgebung bereitgestellt. So bleibt die Software immer in einem auslieferbaren Zustand – wichtig für Sicherheitsupdates.

Open Source, Gradle und Git: Richtige Aussagen erkennen

Frage 7 enthält mehrere Aussagen, von denen eine korrekt ist. Open-Source-Software ist nicht immer kostenlos – manche Lizenzen erlauben kommerzielle Nutzung nur gegen Gebühr. Gradle führt inkrementelle Builds durch, bei denen nur geänderte Teile neu gebaut werden – das spart Zeit. Agile Entwicklung erfordert durchaus Planung und Dokumentation, nur in geringerem Umfang als traditionelle Modelle. Git speichert Daten als Snapshots, nicht als Änderungen. Die korrekte Aussage ist: „Gradle führt inkrementelle Builds durch“. Im Mai 2026, wo KI-Entwicklungsplattformen wie Hugging Face auf schnelle Iterationen angewiesen sind, sind inkrementelle Builds entscheidend.

Gradle: Tasks, DAG und Dry Run

Frage 8 vertieft Gradle-Kenntnisse. Tasks können Aktionen haben (falsch: „es ist nicht möglich, Aktionen hinzuzufügen“). Die Reihenfolge der Tasks wird durch einen Directed Acyclic Graph (DAG) bestimmt. Wenn ein Task fehlschlägt, bricht Gradle den Build ab (falsch: „Gradle führt den Build trotzdem zu Ende“). Ein Dry Run führt Tasks nicht wirklich aus, sondern zeigt nur, was passieren würde. Gradle-Build-Dateien sind Groovy- oder Kotlin-Skripte, nicht XML. Inkrementelle Builds sind eine Gradle-Funktion. Die richtigen Antworten sind also: DAG, Dry Run und inkrementelle Builds. Dieses Wissen ist nützlich, wenn du mit Android-Apps arbeitest, die standardmäßig Gradle verwenden.

GitHub Webhooks: POST-Payload bei Events

Frage 9 behandelt GitHub Webhooks. Richtig ist: Wenn ein Event (z.B. Push) ausgelöst wird, sendet GitHub einen HTTP POST-Payload an die konfigurierte URL. Der Payload ist im JSON-Format, nicht XML oder GET. Stell dir vor, du betreibst einen CI-Server, der bei jedem Push automatisch Tests startet. Der Webhook benachrichtigt den Server – und das geschieht per POST.

Pull Requests und Forks: Beitragen ohne Schreibzugriff

Frage 10 klärt, wie man zu einem Repository beiträgt, wenn man keinen Schreibzugriff hat. Die korrekte Antwort: Du musst einen Fork (Kopie) des Repositories erstellen, dann Änderungen in deinem Fork vornehmen und einen Pull Request zum Original-Repository erstellen. Du kannst den Ziel-Branch im Pull Request angeben. Diese Praxis ist im Open-Source-Bereich Standard – z.B. bei Projekten wie TensorFlow oder React.

Ethische Fallstudie: Qualitätssicherung unter Druck

Frage 11 schildert einen ethischen Konflikt: Ein Ingenieur unterschreibt eine Software, obwohl er Zweifel an der Testabdeckung hat, weil sein Arbeitgeber Druck ausübt. Die Antwort: Das ist nicht akzeptabel. Als Softwareentwickler trägst du Verantwortung für die Sicherheit und Qualität des Produkts. Besonders bei sicherheitskritischer Software (wie Flugsteuerung) können Fehler katastrophale Folgen haben. Im Mai 2026, wo autonome Fahrzeuge und Drohnen immer präsenter werden, ist dieses Thema hochaktuell. Ein Ingenieur sollte sich weigern, unzureichend getestete Software freizugeben, und stattdessen Eskalationswege nutzen – z.B. den Vorgesetzten oder die Ethikkommission informieren.

Open-Source-Lizenzen: MIT und Eigenmarken

Frage 12 bezieht sich auf die iBid-Plattform und die Nutzung von BidOptimize1.1.3 unter MIT-Lizenz. (a) Die MIT-Lizenz ist geeignet, da sie erlaubt, die Software zu nutzen, zu modifizieren und zu verteilen – auch in proprietären Produkten. (b) Für das Open-Sourcing von iBid: Die Firma sollte eine eigene Lizenz wählen, die Marke und Branding schützt, z.B. die Apache 2.0-Lizenz mit einer zusätzlichen Klausel zum Markenschutz. Oder sie könnte die GPL vermeiden, da diese erfordert, dass abgeleitete Werke ebenfalls Open Source sein müssen. Ein aktuelles Beispiel: Meta veröffentlicht viele KI-Modelle unter einer speziellen Lizenz, die kommerzielle Nutzung einschränkt, um die Marke zu schützen.

Akzeptanztests mit Gherkin: Szenarien für MovieFan

Frage 13 zeigt ein Gherkin-Szenario für eine MovieFan-App. Der Test prüft, ob Filme in alphabetischer Reihenfolge angezeigt werden. Solche Behavior-Driven Development (BDD)-Tests sind in agilen Teams üblich. Tools wie Cucumber oder SpecFlow wandeln Gherkin in automatisierte Tests um. Stell dir vor, du entwickelst eine Film-Streaming-Plattform wie Netflix; solche Tests stellen sicher, dass die Benutzeroberfläche korrekt funktioniert.

Fazit: Mit diesen Konzepten zur Prüfungsvorbereitung

Die Prüfung SOFT2412 / COMP9412 testet tiefes Verständnis agiler Prinzipien, CI/CD-Tools und Open-Source-Lizenzen. Nutze dieses Tutorial, um die Konzepte mit aktuellen Beispielen aus Mai 2026 zu verknüpfen: von KI-Apps über E-Sport-Teams bis hin zu Smart-Home-Systemen. Wiederhole die Kernfragen, diskutiere die ethischen Fallstudien und übe mit Gherkin-Szenarien. So bist du bestens vorbereitet – und verstehst, warum agiles Denken in der modernen Softwareentwicklung unverzichtbar ist.