Applied Software Engineering Bachelor-Praktikum - Exam

Aufgabe 1)

Kontext: Das Wasserfallmodell ist ein lineares Vorgehensmodell im Softwareentwicklungsprozess, bei dem jede Phase vollständig abgeschlossen sein muss, bevor die nächste beginnt. Es umfasst die Phasen: Anforderungsanalyse, Entwurf, Implementierung, Test, Integration und Wartung. Während es den Vorteil einer einfachen Handhabung und Planung bietet, weist es Nachteile wie geringe Flexibilität und spätes Testen auf.

a)

Erkläre die hauptsächlichen Problempunkte, die auftreten können, wenn das Wasserfallmodell in einem Projekt mit unklaren und sich ständig ändernden Anforderungen angewendet wird. Ergänze Deine Antwort durch Beispiele.

Lösung:

Problempunkte bei unklaren und sich ändernden Anforderungen im Wasserfallmodell:Das Wasserfallmodell ist aufgrund seiner linearen und sequentiellen Struktur weniger geeignet für Projekte mit unklaren und sich ständig ändernden Anforderungen. Hier sind einige der hauptsächlichen Problempunkte, die auftreten können:

• Geringe Flexibilität: Da jede Phase vollständig abgeschlossen sein muss, bevor die nächste beginnt, ist es schwierig, Änderungen in den frühen Phasen zu berücksichtigen, sobald das Projekt in den späteren Phasen ist. Beispiel: Wenn ein Kunde während der Implementierungsphase zusätzliche Anforderungen hinzufügt, muss das Projekt möglicherweise zur Anforderungsanalyse zurückkehren und viele Arbeitsschritte erneut durchlaufen.
• Spätes Testen: Durch die Struktur des Wasserfallmodells erfolgt das Testen erst nach der Implementierung. Fehler und Missverständnisse in den Anforderungen werden daher erst spät im Prozess entdeckt, was teuer und zeitaufwändig sein kann. Beispiel: Wenn während der Testphase ein kritischer Fehler entdeckt wird, stammt dieser möglicherweise aus einem frühen Designfehler, der eine umfassende Überarbeitung und erhebliche Verzögerungen zur Folge haben könnte.
• Schwierigkeit bei der Änderung von Anforderungen: Da das Wasserfallmodell auf festen Anforderungen basiert, ist es für Entwickler schwierig, auf sich ändernde Kundenwünsche flexibel zu reagieren. Beispiel: In einem Projekt zur Entwicklung einer mobilen App könnte der Kunde plötzlich neue Funktionen verlangen, um auf Marktveränderungen zu reagieren. Bei Verwendung des Wasserfallmodells könnte dies die Erstellung und den Test von großen Teilen der Anwendung, einschließlich der bereits fertiggestellten Module, verzögern.
• Mangelnde Kundeninteraktion: Im Wasserfallmodell findet die Interaktion mit dem Kunden hauptsächlich in den frühen Phasen des Projekts statt. Bei unklaren Anforderungen führt dies oft zu Missverständnissen und nicht erfüllten Erwartungen. Beispiel: Wenn bei der Anforderungsanalyse nicht alle Details klar definiert wurden, könnte das Endprodukt nicht den Erwartungen des Kunden entsprechen, da keine regelmäßigen Feedback-Schleifen vorhanden sind.

b)

Betrachten wir ein Softwareentwicklungsprojekt, das nach dem Wasserfallmodell durchgeführt wurde. Das Projekt befindet sich in der Implementierungsphase, und während des Implementierungsprozesses wurden einige schwerwiegende Fehler in der Entwurfsphase entdeckt. Beschreibe die möglichen Auswirkungen auf das Projekt in Bezug auf Zeit, Kosten und Qualität. Welche Schritte würdest Du vorschlagen, um solche Probleme in zukünftigen Projekten zu vermeiden?

Lösung:

Auswirkungen auf das Projekt:Wenn während der Implementierungsphase schwerwiegende Fehler in der Entwurfsphase entdeckt werden, hat dies erhebliche Auswirkungen auf das Projekt hinsichtlich Zeit, Kosten und Qualität.

• Zeit: Die entdeckten Fehler machen es notwendig, zur Entwurfsphase zurückzukehren, um die Fehler zu korrigieren. Dies führt zu Verzögerungen im gesamten Projektzeitplan, da alle nachfolgenden Phasen entsprechend verschoben werden müssen.
• Kosten: Die Korrektur von Fehlern in einer späteren Phase ist meist kostspieliger als in einer früheren Phase. Es müssen zusätzliche Ressourcen eingesetzt werden, um die Fehler zu identifizieren und zu beheben, was zu erhöhten Projektkosten führt.
• Qualität: Die Qualität des Endprodukts kann darunter leiden, da hastige Korrekturen und Änderungen eingeführt werden, um den Zeitplan einzuhalten. Das Risiko, dass neue Fehler durch diese Änderungen entstehen, ist hoch, was die Gesamtqualität des Produkts beeinträchtigen kann.

• Frühzeitige und kontinuierliche Überprüfung: Implementiere regelmäßige Überprüfungen und Qualitätskontrollmaßnahmen in allen Phasen des Projekts, insbesondere während der Entwurfsphase. So können Fehler früher erkannt und behoben werden.
• Inkrementelle Wiederholungen: Nutze ein inkrementelles und iteratives Vorgehensmodell, beispielsweise Scrum oder das V-Modell. Diese Modelle ermöglichen ständige Überprüfungen und Anpassungen, wodurch das Risiko für große Designfehler in späteren Phasen verringert wird.
• Prototyping: Erstelle Prototypen in frühen Phasen des Projekts, um Konzepte und Designs zu testen, bevor sie in die Implementierung gehen. Prototypen helfen, Missverständnisse zu klären und potenzielle Designfehler frühzeitig zu erkennen.
• Kundenfeedback: Sammle frühzeitig und kontinuierlich Feedback von Kunden und Stakeholdern, um sicherzustellen, dass die Anforderungen klar und vollständig verstanden sind. Dies hilft dabei, Änderungen und neue Anforderungen frühzeitig zu integrieren.
• Automatisiertes Testen: Setze automatisierte Tests frühzeitig im Entwicklungsprozess ein, um sicherzustellen, dass Änderungen kontinuierlich überprüft und Qualitätssicherungsmaßnahmen effizienter durchgeführt werden können.

Aufgabe 2)

Du arbeitest als Teil eines Softwareentwicklungsteams und dein Team hat sich entschieden, agile Methoden zu verwenden, um die Effizienz und Transparenz der Projekte zu erhöhen. Es stehen zwei Hauptmethoden zur Auswahl: Scrum und Kanban. Die Wahl der richtigen Methode hängt von den spezifischen Bedürfnissen und Arbeitsabläufen deines Teams ab.

a)

Vergleiche die wichtigsten Unterschiede zwischen Scrum und Kanban in Bezug auf ihre Struktur und Einsatzgebiete. Erläutere, welche Methode für ein Projekt mit häufig wechselnden Anforderungen besser geeignet ist und warum.

Lösung:

Vergleich der wichtigsten Unterschiede zwischen Scrum und Kanban in Bezug auf ihre Struktur und Einsatzgebiete:

• Struktur:
  • Scrum: Scrum basiert auf festen Iterationen, den sogenannten Sprints, die in der Regel 2-4 Wochen dauern. Jede Iteration endet mit einem potenziell lieferbaren Produktinkrement. Es gibt klar definierte Rollen (Product Owner, Scrum Master, Entwicklungsteam) und regelmäßige Meetings (Stand-ups, Sprint-Planung, Sprint Review, Sprint Retrospektive).
  • Kanban: Kanban ist ein kontinuierliches Fluss-System ohne feste Iterationen. Das Hauptwerkzeug ist das Kanban-Board, das die Arbeitsaufgaben visualisiert und durch verschiedene Phasen führt. Es gibt keine vorgegebenen Rollen und nur wenige vorgeschriebene Meetings. Fokus liegt auf dem kontinuierlichen Fluss der Aufgaben und der kontinuierlichen Verbesserung.
• Einsatzgebiete:
  • Scrum: Scrum eignet sich gut für Projekte mit festgelegten Anforderungen, die in recht kurzer Zeit erledigt werden können. Es ist ideal für Teams, die von einer klaren Struktur und regelmäßigen Feedback-Loops profitieren.
  • Kanban: Kanban eignet sich besonders für Projekte, die einen kontinuierlichen und flexiblen Arbeitsablauf benötigen. Es ist ideal für Teams, deren Arbeitsaufgaben häufig wechseln und die eine größere Flexibilität bei der Priorisierung und Abarbeitung von Aufgaben benötigen.

Welche Methode ist für ein Projekt mit häufig wechselnden Anforderungen besser geeignet und warum?

• Kanban: Für ein Projekt mit häufig wechselnden Anforderungen ist Kanban besser geeignet. Der Hauptgrund dafür ist die Flexibilität von Kanban in Bezug auf die Priorisierung und das Management von Aufgaben. Bei Kanban gibt es keine festen Zeitrahmen oder Iterationen, sodass das Team schnell auf Änderungen reagieren und Aufgaben dynamisch anpassen kann. Der kontinuierliche Fluss der Aufgaben ermöglicht es dem Team, sich leicht an neue Anforderungen anzupassen und somit schneller auf Veränderungen zu reagieren.

b)

Nehmen wir an, Dein Team hat beschlossen, Scrum zu verwenden. Der Product Owner hat ein Product Backlog mit folgenden Einträgen erstellt:

• User Story 1: 5 Story Points
• User Story 2: 8 Story Points
• User Story 3: 3 Story Points
• User Story 4: 13 Story Points
• User Story 5: 2 Story Points

• Erstelle das Sprint Backlog für den kommenden Sprint.
• Skizziere, wie du das Daily Stand-up leiten würdest, um sicherzustellen, dass das Team die Sprint-Ziele erreicht.

Lösung:

Erstellung des Sprint Backlogs für den kommenden Sprint:

Basierend auf der durchschnittlichen Velocity von 20 Story Points kann das Team so viele User Stories aus dem Product Backlog auswählen, bis die maximale Kapazität von 20 Story Points erreicht ist. Das Sprint Backlog könnte folgendermaßen aussehen:

• User Story 1: 5 Story Points
• User Story 2: 8 Story Points
• User Story 3: 3 Story Points
• User Story 5: 2 Story Points

Zusammen ergeben diese User Stories 18 Story Points. Da 20 Story Points die maximale Kapazität darstellen und User Story 4 mit 13 Story Points allein die Kapazität überschreiten würde, wird sie nicht in dieses Sprint Backlog aufgenommen.

Skizzierung des Daily Stand-ups:

Das Daily Stand-up Meeting, häufig als Daily Scrum bezeichnet, dauert maximal 15 Minuten und fokussiert sich darauf, dass jedes Teammitglied schnell berichtet. Es besteht aus drei Hauptfragen, die jedes Teammitglied beantworten sollte:

• Was habe ich seit dem letzten Daily Stand-up gemacht?
• Was werde ich bis zum nächsten Daily Stand-up machen?
• Gibt es irgendwelche Hindernisse, die mich daran hindern, meine Arbeit zu erledigen?

Leitung des Daily Stand-ups:

• Beginne das Meeting pünktlich zur festgelegten Zeit.
• Erinnere das Team an die Struktur des Daily Stand-ups und die zu beantwortenden drei Fragen.
• Lasse jedes Teammitglied seine Updates präsentieren und achte auf einen zügigen Ablauf, um die 15 Minuten nicht zu überschreiten.
• Notiere alle Hindernisse, die genannt werden, und arbeite mit dem Team daran, diese nach dem Meeting zu lösen oder zu eskalieren, wenn sie nicht sofort gelöst werden können.
• Schließe das Meeting pünktlich ab und danke dem Team für die Teilnahme.

Zusätzlich kannst du das Stand-up mit einem kurzen Zusammenfassen des Fortschritts des Sprint Backlogs beenden, indem du den aktuellen Stand der User Stories und eventuell angepasste Prioritäten betrachtest, um sicherzustellen, dass das Team auf Kurs bleibt, die Sprint-Ziele zu erreichen.

Aufgabe 3)

Du bist ein Entwickler in einem Team, das an einem großen Softwareprojekt arbeitet. Dein Team verwendet Git als Versionskontrollsystem. Um den Überblick über die Änderungen zu behalten und die parallele Entwicklung zu fördern, nutzt Ihr sowohl Branching als auch Merging. Deine Aufgabe ist es, die Funktionsweise und die Anwendung von Git in praktischen Szenarien zu erklären und anzuwenden.

a)

Erkläre den Unterschied zwischen einem lokalen Repository und einem Remote Repository in Git. Welche Vorteile bietet die Verwendung eines Remote Repositorys im Vergleich zu einem rein lokalen Repository?

Lösung:

• Lokales Repository: Ein lokales Repository in Git ist ein Verzeichnis auf Deinem lokalen Computer, das alle Dateien und Historien Deines Projekts enthält. Du führst Befehle wie git add, git commit und git checkout direkt in Deinem lokalen Repository aus. Alle Änderungen und Versionen werden lediglich auf Deinem Computer gespeichert.
• Remote Repository: Ein Remote Repository ist ein Repository, das auf einem Server (z.B. GitHub, GitLab, Bitbucket) oder einem anderen Computer gespeichert ist und über das Internet oder ein Netzwerk zugänglich ist. Es handelt sich dabei um eine zentrale Anlaufstelle, auf die mehrere Entwickler zugreifen können. Typische Befehle im Umgang mit Remote Repositories sind git push, git pull und git clone. Diese Befehle ermöglichen es, Änderungen zu einem Remote Repository hochzuladen oder von dort herunterzuladen.
• Vorteile eines Remote Repositorys:
  • Zentralisierung: Ein Remote Repository bietet eine zentrale Stelle zur Verwaltung des Codes und der Historie, auf den alle Teammitglieder zugreifen können.
  • Zusammenarbeit: Mehrere Entwickler können gleichzeitig und unabhängig voneinander am selben Projekt arbeiten. Das Remote Repository dient als Synchronisationspunkt.
  • Sicherung: Durch das regelmäßig Pushen von Änderungen zu einem Remote Repository wird der Code sicher außerhalb des eigenen Computers gespeichert, was Datenverlust durch Hardware-Probleme oder andere Vorfälle verhindert.
  • Verfügbarkeit: Da das Repository über das Internet zugänglich ist, können Teammitglieder von verschiedenen Standorten aus arbeiten.
  • Verlauf und Protokollierung: Änderungen und Kommunikationsverläufe (z.B. durch Pull Requests) können einfach nachverfolgt und dokumentiert werden, was die Transparenz und das Management von Projekten erleichtert.

b)

Angenommen, dein Team entwickelt eine neue Funktion auf einem Branch namens 'feature-xyz'. Dein Teammitglied hat Änderungen auf diesem Branch gepusht, die Du jetzt in deinen lokalen Branch integrieren möchtest. Beschreibe den genauen Ablauf, einschließlich der Git-Befehle, um diese Änderungen in deinen lokalen Branch zu ziehen und danach einen neuen Commit zu machen.

Lösung:

• Schritt 1: Wechsel zum Branch 'feature-xyz'

  git checkout feature-xyz

• Schritt 2: Aktualisieren des Local RepositoriesHole die neuesten Änderungen vom Remote Repository.

  git fetch origin

• Schritt 3: Merge die Änderungen auf 'feature-xyz'Integriere die Änderungen in Deinen lokalen Branch 'feature-xyz'

  git merge origin/feature-xyz

• (Optional) Schritt 4: Konflikte behebenFalls Merge Konflikte auftreten, behebe diese manuell.Füge die behobenen Dateien dem Staging-Bereich hinzu:

  git add <filename>

  Und committe gegebenenfalls die Konfliktlösung:

  git commit

• Schritt 5: Änderungen CommittenFalls nach dem Merge noch Änderungen gemacht werden, erstelle einen neuen Commit.

  git add <dateien oder Ordner>

  Führe schließlich den Commit durch:

  git commit -m 'Beschreibung der Änderungen'

• Schritt 6: Änderungen PushenUm die Änderungen zurück ins Remote Repository zu senden:

  git push origin feature-xyz

• Zusammenfassung der Befehle:

  git checkout feature-xyzgit fetch origingit merge origin/feature-xyz -- (Im Fall von Konflikten: git add <dateien> und git commit)git add <dateien>git commit -m 'Beschreibung der Änderungen'git push origin feature-xyz

Aufgabe 4)

Continuous Integration/Continuous Deployment (CI/CD)CI/CD: kontinuierliche Integration (CI) und kontinuierliche Bereitstellung (CD), automatisierte Prozesse zur Verbesserung der Softwarequalität und -lieferung.

• CI: Häufige Integration von Codeänderungen in ein gemeinsames Repository, automatische Builds und Tests.
• CD: Automatisierte Bereitstellung der getesteten Software in verschiedene Umgebungen bis zur Produktion.
• Ziel: Fehler frühzeitig erkennen, schnelle Auslieferung, kontinuierliches Feedback.
• Tools: Jenkins, GitLab CI, Travis CI, CircleCI.

a)

Der Softwareentwickler Max hat gerade einen neuen Codeabschnitt geschrieben und möchte ihn in das gemeinsame Repository integrieren. Beschreibe detailliert den Prozess, den er durchlaufen würde, wenn das Projekt eine CI/CD-Pipeline verwendet. Achte besonders auf die Schritte der kontinuierlichen Integration. Welche Tools könnten hier hilfreich sein, und wie würden sie verwendet werden?

Lösung:

Prozess der kontinuierlichen Integration und Bereitstellung (CI/CD)

Wenn Max einen neuen Codeabschnitt geschrieben hat und ihn in das gemeinsame Repository integrieren möchte, folgt er einem strukturierten Prozess, der durch eine CI/CD-Pipeline unterstützt wird. Hier ist eine detaillierte Beschreibung des Prozesses:

• Codecommit und Push: Max überprüft zunächst seine Änderungen lokal mittels eines Versionskontrollsystems wie Git. Wenn der Code fehlerfrei ist, führt er einen Commit durch und pusht den Code in das gemeinsame Repository, zum Beispiel auf GitLab oder GitHub.
• CI-Pipeline wird ausgelöst: Durch das Pushen des Codes wird automatisch die CI/CD-Pipeline ausgelöst. Diese Pipeline könnte von Tools wie Jenkins, GitLab CI, Travis CI oder CircleCI bereitgestellt werden. Dies sind die zentralen Tools für die Automatisierung der folgenden Schritte.
• Build-Prozess: Die CI-Pipeline startet mit dem Build-Prozess. Hierbei wird der Code kompiliert und alle benötigten Abhängigkeiten werden eingebunden. Dieser Schritt stellt sicher, dass der Code in eine ausführbare Form gebracht wird. Tools wie Maven oder Gradle können hier verwendet werden.
• Automatisierte Testläufe: Nach dem erfolgreichen Build werden automatisierte Tests ausgeführt. Diese Tests umfassen Unit-Tests, Integrationstests und ggf. End-to-End-Tests. Ziel ist es, sicherzustellen, dass neue Codeänderungen keine bestehenden Funktionen zerstören. Test-Frameworks wie JUnit, NUnit oder Selenium können hier hilfreich sein.
• Statischer Code-Analyse: Zusätzlich zu den Tests könnte die Pipeline auch eine statische Code-Analyse durchführen, um Codequalität und -sicherheit zu gewährleisten. Tools wie SonarQube können hier verwendet werden.
• Benachrichtigung und Feedback: Nach Abschluss der automatisierten Tests und Analysen wird das Team über den Status benachrichtigt. Sollte ein Fehler auftreten, wird Max und das Team sofort informiert, so dass sie schnell reagieren und den Code fixen können.
• Kontinuierliche Bereitstellung (CD): Wenn alle Tests und Überprüfungen erfolgreich waren, kann der Code automatisch in eine Staging-Umgebung bereitgestellt werden. In der Produktionsumgebung erfolgt dies in der Regel durch einen genehmigten Pull-Request. Hier können Deployment-Tools wie Docker oder Kubernetes hilfreich sein.

Durch diesen strukturierten CI/CD-Prozess kann Max sicherstellen, dass seine Codeänderungen kontinuierlich und zuverlässig in das Projekt integriert und bereitgestellt werden.

b)

Stelle Dir vor, dass nach der erfolgreichen Integration von Max' Code in das gemeinsame Repository die kontinuierliche Bereitstellungstrasse (CD) einsetzt. Erkläre detailliert, welche Schritte durchlaufen werden, bevor die Software in die Produktionsumgebung gelangt. Diskutiere mögliche Herausforderungen und wie diese adressiert werden können. Gehe auch darauf ein, wie automatisierte Tests zur Qualitätssicherung beitragen können.

Lösung:

Prozess der kontinuierlichen Bereitstellung (CD) nach erfolgreicher Integration

Nachdem Max' Code erfolgreich in das gemeinsame Repository integriert wurde, setzt der Prozess der kontinuierlichen Bereitstellung (CD) ein. Hier sind die detaillierten Schritte, die gewöhnlich durchlaufen werden, bevor die Software in die Produktionsumgebung gelangt:

• 1. Staging-Umgebung: Der erste Schritt nach der Integration der Codeänderungen ist die Bereitstellung in einer Staging-Umgebung, die der Produktionsumgebung sehr ähnlich ist. In dieser Umgebung können letzte Tests durchgeführt werden, um sicherzustellen, dass alles wie erwartet funktioniert.
• 2. Automatisierte End-to-End-Tests: In der Staging-Umgebung werden automatisierte End-to-End-Tests durchgeführt. Diese Tests prüfen das System als Ganzes, um sicherzustellen, dass alle Komponenten korrekt zusammenarbeiten. Tools wie Selenium oder Cypress können hier verwendet werden, um Benutzerinteraktionen zu simulieren und zu überprüfen.
• 3. Akzeptanztests: Akzeptanztests, manchmal auch als User Acceptance Testing (UAT) bezeichnet, werden durch Stakeholder oder Endbenutzer durchgeführt. Diese Tests verifizieren, dass die Software den Geschäftsanforderungen entspricht und bereit für die Produktion ist. Tools wie FitNesse können hier verwendet werden.
• 4. Sicherheits-Tests: Vor der eigentlichen Bereitstellung in der Produktionsumgebung werden Sicherheits-Tests durchgeführt. Diese Tests können Schwachstellen im System aufdecken und sicherstellen, dass keine Sicherheitslücken vorhanden sind. Tools wie OWASP ZAP oder Nessus können hier verwendet werden.
• 5. Performance-Tests: Zusätzlich können Performance-Tests durchgeführt werden, um sicherzustellen, dass die Anwendung unter Last gut funktioniert. Tools wie JMeter oder Gatling können verwendet werden, um die Leistung und Skalierbarkeit der Anwendung zu testen.
• 6. Genehmigungsprozess: Oft gibt es eine Freigabe durch das Team oder einen Verantwortlichen, bevor der Code in die Produktionsumgebung ausgerollt wird. Dies dient als letzter Kontrollpunkt, um sicherzustellen, dass alle Tests bestanden wurden und das System einsatzbereit ist.
• 7. Deployment in Produktion: Nach der Genehmigung wird der Code in die Produktionsumgebung bereitgestellt. Dieser Schritt kann automatisiert sein oder manuell durchgeführt werden. Tools wie Docker und Kubernetes können hier zur Container-Orchestrierung und Verwaltung verwendet werden.

Herausforderungen und deren Lösungen

• Konfigurationsprobleme: Unterschiedliche Umgebungen (Staging, Produktion) können unterschiedliche Konfigurationen erfordern. Tools wie Ansible oder Chef können helfen, die Konfiguration konsistent zu halten und zu automatisieren.
• Integration von Datenbanken: Datenbankschemata müssen möglicherweise aktualisiert werden, ohne dass bestehende Daten verloren gehen. Migrationstools wie Flyway oder Liquibase können hier helfen, Datenbankänderungen sicher und kontrolliert durchzuführen.
• Sicherheitsbedenken: Sicherzustellen, dass der Code sicher ist, ist von größter Bedeutung. Regelmäßige Sicherheits-Überprüfungen und die Verwendung von Sicherheits-Tools können helfen, Sicherheitslücken frühzeitig zu erkennen und zu beheben.

Rolle automatisierter Tests zur Qualitätssicherung

Automatisierte Tests spielen eine entscheidende Rolle bei der Qualitätssicherung im CD-Prozess:

• Sie ermöglichen eine frühzeitige Fehlererkennung und -behebung, wodurch die Stabilität des Codes verbessert wird.
• Sie gewährleisten, dass jede Codeänderung rigoros getestet wird, bevor sie in Produktion geht, was das Risiko von Fehlern in der Live-Umgebung reduziert.
• Sie reduzieren den manuellen Testaufwand und beschleunigen den gesamten Entwicklungs- und Bereitstellungsprozess.

Insgesamt trägt eine gut durchdachte und implementierte CI/CD-Pipeline erheblich zur Verbesserung der Softwarequalität und -lieferung bei, indem sie schnelle, konsistente und zuverlässige Deployment-Prozesse sicherstellt.