Praktische Softwaretechnik - Exam.pdf

Praktische Softwaretechnik - Exam
Praktische Softwaretechnik - Exam Aufgabe 1) Du bist Teil eines Teams, das ein neues Software-System entwickeln soll, um den Ticketverkauf für eine Konzert-Eventfirma zu automatisieren. Deine Aufgabe ist es, die Anforderungen des Systems zu erfassen und zu dokumentieren. a) Beschreibe, wie Du die Anforderungen für das neue Ticketverkaufssystem ermitteln würdest. Gehe dabei auf mindestens drei der ...

© StudySmarter 2024, all rights reserved.

Praktische Softwaretechnik - Exam

Aufgabe 1)

Du bist Teil eines Teams, das ein neues Software-System entwickeln soll, um den Ticketverkauf für eine Konzert-Eventfirma zu automatisieren. Deine Aufgabe ist es, die Anforderungen des Systems zu erfassen und zu dokumentieren.

a)

Beschreibe, wie Du die Anforderungen für das neue Ticketverkaufssystem ermitteln würdest. Gehe dabei auf mindestens drei der genannten Methoden genauer ein (Interviews, Workshops, Beobachtungen).

Lösung:

Ermittlung der Anforderungen für das neue Ticketverkaufssystem

Um die Anforderungen für das neue Ticketverkaufssystem zu erfassen, würde ich verschiedene Methoden anwenden. Hier sind drei davon im Detail:

  • Interviews

    Interviews bieten eine tiefgehende Möglichkeit, spezifische Informationen direkt von den Stakeholdern zu erhalten. Diese Gespräche würden mit verschiedenen Personen durchgeführt werden, wie z.B. dem Management, den Mitarbeitern im Ticketverkauf und den Endbenutzern (Kunden). Die Fragen wären so gestaltet, dass sie die Bedürfnisse, Erwartungen und Probleme der Befragten abdecken. Zum Beispiel könnte ich folgende Fragen stellen:

    • Welche Funktionen sind für Sie im neuen System besonders wichtig?
    • Welche Probleme haben Sie mit dem aktuellen System?
    • Welche Prozesse würden Sie gerne automatisiert sehen?

    Durch diese qualitativ hochwertigen Gespräche können wertvolle Einblicke und spezifische Anforderungen gesammelt werden.

  • Workshops

    Workshops sind eine effektive Methode, um die Anforderungen in einer kollaborativen Umgebung zu erarbeiten. Ich würde mehrere Workshops organisieren, bei denen die Stakeholder zusammenkommen und gemeinsam über ihre Bedürfnisse und Wünsche diskutieren. Diese Workshops können verschiedene Formen annehmen, wie z.B. Brainstorming-Sitzungen, Prototyping-Aktivitäten oder Fokusgruppen. Ein typischer Workshop könnte folgende Agenda haben:

    • Begrüßung und Einführung in das Thema
    • Vorstellung der Ziele des neuen Systems
    • Gruppenarbeit: Identifikation der Anforderungen
    • Präsentation der Ergebnisse und Diskussion
    • Zusammenfassung und nächste Schritte

    Durch die Interaktion und den Austausch von Ideen in Workshops können viele Perspektiven berücksichtigt und ein umfassendes Anforderungsprofil erstellt werden.

  • Beobachtungen

    Die direkte Beobachtung der aktuellen Abläufe und Prozesse im Ticketverkauf ermöglicht es, ein genaues Bild von den täglichen Aktivitäten und den bestehenden Herausforderungen zu bekommen. Ich würde Zeit damit verbringen, sowohl die Mitarbeiter bei ihrer Arbeit zu beobachten als auch die Kunden beim Ticketkauf zu begleiten. Dabei werden folgende Aspekte besonders beachtet:

    • Wie nutzen die Mitarbeiter das bestehende System?
    • Welche Schritte sind für den Ticketverkauf notwendig?
    • Welche Probleme treten regelmäßig auf?
    • Wie reagieren die Kunden auf den Ticketverkaufsprozess?

    Durch die Beobachtung können unentdeckte Bedürfnisse identifiziert und konkrete Verbesserungsvorschläge abgeleitet werden.

Durch die Kombination dieser Methoden können detaillierte und fundierte Anforderungen für das neue Ticketverkaufssystem ermittelt werden, die sowohl die Bedürfnisse der Nutzer als auch die Effizienz der Abläufe berücksichtigen.

b)

Du sollst nun die ermittelten Anforderungen in Form eines Lastenheftes dokumentieren. Welche wesentlichen Bestandteile muss Dein Lastenheft enthalten? Erläutere den Aufbau und Inhalt der einzelnen Abschnitte des Lastenheftes.

Lösung:

Aufbau und Inhalt eines Lastenheftes

Ein Lastenheft ist ein wichtiges Dokument in der Softwareentwicklung, das alle Anforderungen und Erwartungen an das zu entwickelnde System festhält. Es dient als Grundlage für die weitere Projektplanung und Entwicklung. Hier sind die wesentlichen Bestandteile eines Lastenheftes und eine Erläuterung des Aufbaus und Inhalts der einzelnen Abschnitte:

  • Einleitung

    Dieser Abschnitt bietet einen Überblick über das Projekt. Er sollte folgende Unterpunkte enthalten:

    • Projektname
    • Ziel des Projekts: Eine kurze Beschreibung des Hauptziels, z.B. „Automatisierung des Ticketverkaufs für eine Konzert-Eventfirma“.
    • Projektbeteiligte: Eine Liste der wichtigsten Stakeholder, z.B. Management, IT-Abteilung, externe Entwickler.
  • Ist-Zustand

    Hier wird der aktuelle Zustand des Ticketverkaufsprozesses beschrieben, einschließlich der derzeit verwendeten Systeme und der bestehenden Probleme. Dieser Abschnitt hilft, den Bedarf für das neue System zu verdeutlichen.

  • Soll-Zustand

    Dieser Abschnitt beschreibt die Ziele und Erwartungen an das neue System. Es sollte klar definiert sein, was das System leisten soll. Beispiele könnten sein:

    • Automatisierung der Ticketverkäufe
    • Einfache Bedienbarkeit für die Nutzer
    • Integration mit bestehenden Zahlungssystemen
  • Funktionale Anforderungen

    Hier werden die spezifischen Funktionen des Systems detailliert beschrieben. Jede Anforderung sollte klar und präzise formuliert sein. Beispiele sind:

    • Das System muss in der Lage sein, Tickets in Echtzeit zu verkaufen.
    • Es muss eine Benutzerverwaltung für verschiedene Rollen (z.B. Administrator, Verkäufer, Kunde) geben.
    • Das System muss Berichte über Verkaufsstatistiken erstellen können.
  • Nicht-funktionale Anforderungen

    Dieser Abschnitt umfasst die Anforderungen, die die Qualität und Leistung des Systems betreffen, z.B.:

    • Performance: Das System muss in der Lage sein, bis zu 1000 Transaktionen pro Minute zu verarbeiten.
    • Skalierbarkeit: Das System sollte leicht erweitert werden können, um zusätzliche Funktionen zu integrieren.
    • Sicherheit: Das System muss sicherstellen, dass nur autorisierte Benutzer auf sensible Daten zugreifen können.
  • Rahmenbedingungen

    Hier werden die äußeren Bedingungen und Beschränkungen beschrieben, die bei der Entwicklung des Systems berücksichtigt werden müssen, z.B.:

    • Budgetvorgaben
    • Zeitplan: Wichtige Meilensteine und Endtermine
    • Technologische Rahmenbedingungen: Vorgaben zur verwendeten Software und Hardware
  • Abnahmekriterien

    Dieser Abschnitt definiert die Kriterien, nach denen das fertige System abgenommen wird, z.B.:

    • Die Erfüllung aller funktionalen und nicht-funktionalen Anforderungen
    • Durchführung erfolgreicher Tests und Pilotprojekte
    • Positive Rückmeldung von Testnutzern
  • Anhang

    Der Anhang kann zusätzliche Informationen enthalten, die für das Projekt relevant sind, z.B.:

    • Glossar: Erklärung von Fachbegriffen
    • Referenzen: Verweise auf Dokumente, die als Grundlage dienten
    • Protokolle von Meetings oder Workshops

Ein umfassendes und gut strukturiertes Lastenheft ist entscheidend für den Erfolg eines Projekts, da es klare Vorgaben und Erwartungen definiert, die als Grundlage für die Entwicklung und Implementierung des Systems dienen.

c)

Erstelle einen Use Case für das Szenario 'Ticketkauf durch den Kunden'. Stelle den Use Case anhand eines Use-Case-Diagramms dar und beschreibe sowohl den normalen Ablauf als auch mögliche Alternativabläufe in Textform.

Lösung:

Use Case: Ticketkauf durch den Kunden

Use-Case-Diagramm

Im folgenden Diagramm wird der Use Case 'Ticketkauf durch den Kunden' dargestellt:

Use-Case-Diagramm Ticketkauf

Beschreibung des Use Cases

  • Akteure: Kunde, Zahlungssystem, Ticketsystem
  • Ziel: Der Kunde möchte ein Ticket für ein Konzert kaufen und den Kauf erfolgreich abschließen.
  • Vorbedingungen:
    • Der Kunde hat Zugang zum Ticketverkaufssystem.
    • Das Konzert ist noch nicht ausverkauft.
  • Nachbedingungen:
    • Der Kunde erhält eine Bestätigung und das Ticket.
    • Das System aktualisiert die verbleibende Anzahl der verfügbaren Tickets.
  • Normaler Ablauf:
    1. Der Kunde öffnet das Ticketverkaufssystem und sucht nach dem gewünschten Konzert.
    2. Der Kunde wählt das Konzert und die Anzahl der Tickets aus.
    3. Das System zeigt die verfügbaren Plätze und Preise an.
    4. Der Kunde wählt die gewünschten Plätze aus und bestätigt die Auswahl.
    5. Der Kunde gibt seine Zahlungsinformationen ein.
    6. Das Zahlungssystem überprüft und bestätigt die Zahlung.
    7. Das Ticketsystem erstellt die Tickets und sendet sie an den Kunden.
    8. Der Kunde erhält eine Bestätigung und die Tickets per E-Mail.
  • Alternativabläufe:
    • Alternative 1: Ungültige Zahlungsinformationen
      • 5a. Der Kunde gibt ungültige Zahlungsinformationen ein.
      • 5b. Das Zahlungssystem lehnt die Zahlung ab und informiert den Kunden.
      • 5c. Der Kunde wird zur Eingabe der korrekten Zahlungsinformationen aufgefordert.
    • Alternative 2: Konzert ist ausverkauft
      • 2a. Der Kunde wählt ein Konzert, das ausverkauft ist.
      • 2b. Das System informiert den Kunden, dass keine Tickets mehr verfügbar sind.
      • 2c. Der Kunde wählt ein anderes Konzert oder das System bietet eine Warteliste an.
      • 2d. Falls der Kunde ein anderes Konzert wählt, wird der normale Ablauf fortgesetzt.
    • Alternative 3: Technische Probleme
      • 6a. Es treten technische Probleme beim Zahlungssystem auf.
      • 6b. Das System informiert den Kunden über die technischen Probleme.
      • 6c. Der Kunde wird gebeten, es später erneut zu versuchen oder eine alternative Zahlungsmethode zu wählen.
  • Ausnahmen:
    • Das System stürzt ab oder es gibt Netzwerkprobleme. In diesem Fall werden alle bisherigen Eingaben des Kunden gespeichert, und der Kunde wird gebeten, den Vorgang später fortzusetzen.

Dieser Use Case beschreibt den kompletten Ablauf eines Ticketkaufs durch den Kunden und berücksichtigt verschiedene mögliche Szenarien, um einen umfassenden Überblick zu bieten.

Aufgabe 2)

Vererbung und Polymorphismus in objektorientierter ProgrammierungIn diesem Übungsblatt beschäftigen wir uns mit den Konzepten der Vererbung und des Polymorphismus in Java. Vererbung ermöglicht es, dass eine Klasse, genannt abgeleitete Klasse, die Eigenschaften und Methoden einer anderen Klasse, der Basisklasse, erbt. Polymorphismus erlaubt es, dass Objekte unterschiedlicher abgeleiteter Klassen durch eine gemeinsame Schnittstelle oder Basisklasse genutzt werden können. Dies erreicht man durch dynamische oder Laufzeitbindung.Stell dir vor, Du entwickelst eine Anwendung für ein Zeichenprogramm, das verschiedene Formen wie Kreise, Rechtecke und Quadrate handhaben kann. Jede dieser Formen erbt gemeinsame Eigenschaften von einer allgemeinen Klasse Shape, und spezifische Eigenschaften und Methoden werden in ihren jeweiligen abgeleiteten Klassen definiert.

a)

Definiere die Basisklasse Shape in Java. Diese Klasse soll eine Methode draw() enthalten, die keinen Rückgabewert hat und keine Parameter benötigt. Schreibe danach eine abgeleitete Klasse Circle, die von Shape erbt und die Methode draw() überschreibt, um einen Kreis zu zeichnen. Wie sieht der Java-Code aus?

Lösung:

Beispielcode zur Definition der Basisklasse Shape und der abgeleiteten Klasse Circle:Um die Basisklasse Shape und die abgeleitete Klasse Circle in Java zu definieren, folge diesen Schritten:

  • Definiere die Shape-Klasse mit einer abstrakten Methode draw().
  • Erstelle eine abgeleitete Klasse Circle, die von Shape erbt und die Methode draw() überschreibt, um einen Kreis zu zeichnen.
Hier ist der Java-Code dazu:
// Basisklasse Shapedefine the method as abstractpublic abstract class Shape {    // Methode draw(), die überschrieben werden soll    public abstract void draw();}// Abgeleitete Klasse Circledefine the method herepublic class Circle extends Shape {    // Überschreibe die draw() Methode    @Override    public void draw() {        System.out.println('Drawing a Circle');    }}

b)

Polymorphismus ermöglicht es uns, dass die Methode draw() für Objekte unterschiedlicher Klassen unterschiedlich arbeitet. Schreibe ein kurzes Java-Programm, das ein Array von Shape-Objekten (z.B. Kreise und Rechtecke) erstellt und dann eine Schleife benutzt, um die Methode draw() für jedes Objekt im Array aufzurufen.

Lösung:

Beispielcode zur Demonstration von Polymorphismus in Java:Um Polymorphismus in einem Java-Programm zu zeigen, kannst Du ein Array von Shape-Objekten erstellen, das sowohl Kreise als auch Rechtecke enthält. Durch die Verwendung einer Schleife rufst Du dann die Methode draw() für jedes Objekt im Array auf. Hier ist der vollständige Code dazu:

// Basisklasse Shape definiert die Methode als abstraktpublic abstract class Shape {    // Abstrakte Methode draw(), die von den abgeleiteten Klassen implementiert werden soll    public abstract void draw();}// Abgeleitete Klasse Circle überschreibt die draw()-Methodepublic class Circle extends Shape {    @Override    public void draw() {        System.out.println('Drawing a Circle');    }}// Abgeleitete Klasse Rectangle überschreibt die draw()-Methodepublic class Rectangle extends Shape {    @Override    public void draw() {        System.out.println('Drawing a Rectangle');    }}// Hauptklasse zur Demonstration von Polymorphismus in Javapublic class Main {    public static void main(String[] args) {        // Erstelle ein Array von Shape-Objekten        Shape[] shapes = new Shape[2];show how to define objects and put them to array        // Füge ein Circle- und ein Rectangle-Objekt in das Array ein        shapes[0] = new Circle();        shapes[1] = new Rectangle();        // Schleife über jedes Shape-Objekt im Array und rufe die draw()-Methode auf        for (Shape shape : shapes) {            shape.draw();        }    }}
  • Die Shape-Klasse ist abstrakt und enthält eine abstrakte Methode draw().
  • Die Klassen Circle und Rectangle erben von Shape und implementieren die draw()-Methode.
  • Die Hauptklasse Main erstellt ein Array von Shape-Objekten und ruft die draw()-Methode für jedes Objekt im Array auf, wobei Polymorphismus genutzt wird.

c)

Erläutere, was dynamische Bindung (Laufzeitbindung) bedeutet und warum sie wichtig für Polymorphismus ist. Verwende das obige Beispiel zur Veranschaulichung deiner Erklärung.

Lösung:

Dynamische Bindung (Laufzeitbindung) und ihre Bedeutung für Polymorphismus:

  • Definition: Dynamische Bindung, auch als Laufzeitbindung bekannt, ist der Prozess, bei dem die Methode, die in einem Polymorphismus-Szenario ausgeführt werden soll, erst zur Laufzeit bestimmt wird. Das bedeutet, dass der genaue Typ des Objekts, dessen Methode aufzurufen ist, erst während der Programmausführung ermittelt wird und nicht zur Kompilierungszeit.
  • Warum ist dynamische Bindung wichtig für Polymorphismus? Der Polymorphismus ermöglicht es uns, Objekte unterschiedlicher Klassen mit einer gemeinsamen Schnittstelle oder Basisklasse (wie Shape) zu behandeln. Dank der dynamischen Bindung können Methodenaufrufe (wie draw()) zur Laufzeit korrekt auf die spezifische Implementierung in der abgeleiteten Klasse (wie Circle oder Rectangle) verweisen.
Beispiel zur Veranschaulichung:Im Kontext des Zeichenprogramms haben wir folgende Klassenstruktur:
  • Eine abstrakte Basisklasse Shape mit einer abstrakten Methode draw().
  • Eine Klasse Circle, die Shape erbt und die Methode draw() implementiert.
  • Eine Klasse Rectangle, die ebenfalls Shape erbt und die Methode draw() implementiert.
  • In der Hauptklasse Main wird ein Array von Shape-Objekten erstellt, das sowohl Circle- als auch Rectangle-Objekte enthält.
Hier ist der entsprechende Java-Code:
// Basisklasse Shapepublic abstract class Shape {    public abstract void draw();}// Abgeleitete Klasse Circlepublic class Circle extends Shape {    @Override    public void draw() {        System.out.println('Drawing a Circle');    }}// Abgeleitete Klasse Rectanglepublic class Rectangle extends Shape {    @Override    public void draw() {        System.out.println('Drawing a Rectangle');    }}// Hauptklasse zur Demonstration von Polymorphismus in Javapublic class Main {    public static void main(String[] args) {        Shape[] shapes = new Shape[2];        shapes[0] = new Circle();        shapes[1] = new Rectangle();        for (Shape shape : shapes) {            shape.draw();  // Hier erfolgt die dynamische Bindung        }    }}
Bei der Schleife im Code:
for (Shape shape : shapes) { shape.draw(); }
wird die Methode draw() zur Laufzeit für jedes Objekt im Array aufgerufen. Aufgrund der dynamischen Bindung:
  • Wenn das Objekt ein Circle ist, wird draw() von der Klasse Circle ausgeführt.
  • Wenn das Objekt ein Rectangle ist, wird draw() von der Klasse Rectangle ausgeführt.
Dies zeigt, wie dynamische Bindung es ermöglicht, dass die richtige Methode zur Laufzeit basierend auf dem tatsächlichen Objekttyp aufgerufen wird, was ein Kernbestandteil der Polymorphismus ist.

d)

Betrachte folgendes Szenario: Zusätzlich zu den bestehenden Formen soll eine neue Form Square in das Zeichenprogramm aufgenommen werden, die ebenfalls von Shape erbt. Schreibe die Klasse Square, die die Methode draw() überschreibt und integriere sie in das Array von Shape-Objekten. Welche Änderungen sind im Code erforderlich und warum?

Lösung:

Integration der neuen Form Square in das Zeichenprogramm:

  • Wir definieren eine neue abgeleitete Klasse Square, die von Shape erbt und die Methode draw() überschreibt.
  • Wir integrieren diese neue Klasse Square in das bestehende Array von Shape-Objekten in der Hauptklasse zur Demonstration.
Änderungen im Code:
  • Hinzufügen der neuen Klasse Square.
  • Erweiterung des Arrays von Shape-Objekten, um auch ein Square-Objekt aufzunehmen.
Hier ist der angepasste Java-Code:
// Basisklasse Shapepublic abstract class Shape {    public abstract void draw();}// Abgeleitete Klasse Circlepublic class Circle extends Shape {    @Override    public void draw() {        System.out.println('Drawing a Circle');    }}// Abgeleitete Klasse Rectanglepublic class Rectangle extends Shape {    @Override    public void draw() {        System.out.println('Drawing a Rectangle');    }}// Neue abgeleitete Klasse Squarepublic class Square extends Shape {    @Override    public void draw() {        System.out.println('Drawing a Square');    }}// Hauptklasse zur Demonstration von Polymorphismus in Javapublic class Main {    public static void main(String[] args) {        // Erstellen eines erweiterten Arrays von Shape-Objekten        Shape[] shapes = new Shape[3];        // Fügen Sie Objekte der Klassen Circle, Rectangle und Square in das Array ein        shapes[0] = new Circle();        shapes[1] = new Rectangle();        shapes[2] = new Square();        // Schleife über jedes Shape-Objekt im Array und Aufrufen der draw()-Methode        for (Shape shape : shapes) {            shape.draw();  // Hier erfolgt die dynamische Bindung        }    }}

Aufgabe 3)

Klassifikation und Implementierung von Entwurfsmustern: Betrachten wir die Einteilung und Anwendung von Entwurfsmustern zur Lösung wiederkehrender Designprobleme. Hierbei unterscheiden wir zwischen den Kategorien Erzeugungsmuster, Strukturmuster und Verhaltensmuster. Deine Aufgabe ist es, die vorgestellten Konzepte zu definieren und auf konkrete Beispiele zu übertragen.

Aufgabe 4)

SCRUM-Prozess ist ein Framework zur agilen Softwareentwicklung, das iterativ, inkrementell und produktorientiert ist. Die Hauptrollen im SCRUM-Prozess umfassen den Product Owner, den Scrum Master und das Entwicklungsteam. Zu den wesentlichen Artefakten gehören das Produkt-Backlog, das Sprint-Backlog und das Inkrement. Zu den zentralen Events im SCRUM-Prozess zählen der Sprint, die Sprintplanung, das tägliche Stand-up, das Sprint-Review und die Sprint-Retrospektive.Extreme Programming (XP) ist eine Sammlung von Methoden zur Verbesserung der Softwarequalität und der Responsivität auf sich ändernde Kundenanforderungen. Zu den XP-Praktiken gehören Pair Programming, Test Driven Development (TDD), Continuous Integration und Refactoring. Die grundlegenden XP-Werte sind Kommunikation, Einfachheit, Feedback, Mut und Respekt.

a)

Beschreibe detailliert die Rolle des Scrum Masters im SCRUM-Prozess. Gehe dabei insbesondere auf seine Hauptaufgaben und die Interaktionen mit anderen Rollen ein.

Lösung:

Rolle des Scrum Masters im SCRUM-Prozess

Der Scrum Master spielt eine zentrale Rolle im SCRUM-Prozess, indem er als Facilitator und Servant Leader agiert. Er unterstützt das Team und stellt sicher, dass alle SCRUM-Prinzipien und -Praktiken korrekt angewendet werden.

  • Hauptaufgaben:
  • Entfernen von Hindernissen: Der Scrum Master identifiziert und beseitigt Hindernisse, die das Entwicklungsteam daran hindern könnten, effektiv zu arbeiten.
  • Förderung der Kommunikation: Er sorgt für eine offene Kommunikation innerhalb des Teams und mit anderen Stakeholdern.
  • Moderieren von Meetings: Der Scrum Master moderiert alle SCRUM-Events wie die Sprintplanung, das tägliche Stand-up, das Sprint-Review und die Sprint-Retrospektive.
  • Coaching: Er coacht das Entwicklungsteam und den Product Owner in der Anwendung von SCRUM und fördert kontinuierliche Verbesserung.
  • Schutz des Teams: Der Scrum Master schützt das Team vor unnötigen Störungen von außen und hilft, den Fokus auf die Sprintziele zu halten.
  • Interaktionen mit anderen Rollen:
  • Product Owner: Der Scrum Master unterstützt den Product Owner dabei, das Produkt-Backlog zu pflegen und die Anforderungen klar zu kommunizieren. Er hilft auch, eine effektive Zusammenarbeit zwischen dem Product Owner und dem Entwicklungsteam sicherzustellen.
  • Entwicklungsteam: Der Scrum Master arbeitet eng mit dem Entwicklungsteam zusammen und unterstützt es, selbstorganisiert und effizient zu arbeiten. Er fördert die Teamdynamik und hilft bei der Implementierung von Verbesserungsvorschlägen aus den Sprint-Retrospektiven.
  • Organisation: Der Scrum Master wirkt auch als Bindeglied zur restlichen Organisation. Er hilft, SCRUM-Prinzipien und -Praktiken im gesamten Unternehmen zu vermitteln und sorgt dafür, dass das Entwicklungsteam die notwendige Unterstützung und Ressourcen erhält.

b)

Erkläre den Prozess der Testgetriebenen Entwicklung (Test Driven Development, TDD) im Detail. Diskutiere dabei die Vor- und Nachteile dieser Methode in der Praxis.

Lösung:

Testgetriebene Entwicklung (Test Driven Development, TDD)

Testgetriebene Entwicklung (TDD) ist eine Softwareentwicklungsmethode, bei der Tests vor der eigentlichen Implementierung des Codes geschrieben werden. Der Prozess von TDD kann in drei Hauptschritte unterteilt werden: Schreiben eines Tests, Implementieren des Codes und Refactoring. Diese Schritte wiederholen sich iterativ während des gesamten Entwicklungsprozesses.

  • Der TDD-Prozess im Detail:
  • Schreiben eines Tests: Der Entwickler schreibt zunächst einen automatisierten Testfall, der eine spezifische Funktionalität des Codes prüft. Dieser Testfall ist zu Beginn fehlschlagend, da die zu prüfende Funktionalität noch nicht implementiert wurde.
  • Implementieren des Codes: In diesem Schritt implementiert der Entwickler den minimalen notwendigen Code, um den zuvor geschriebenen Testfall erfolgreich bestehen zu lassen. Der Fokus liegt darauf, den Testfall so schnell wie möglich zum Bestehen zu bringen.
  • Refactoring: Nachdem der Testfall bestanden hat, wird der Code unter Beibehaltung der Funktionalität verbessert und optimiert. Dabei werden Redundanzen entfernt und die Codequalität erhöht.
  • Wiederholen: Diese drei Schritte werden iterativ wiederholt, bis alle Anforderungen erfüllt und alle Tests bestanden sind.
  • Vorteile von TDD:
  • Verbesserte Codequalität: Da der Code gezwungen ist, die Tests zu bestehen, wird er robuster und weniger fehleranfällig.
  • Besseres Design: TDD fördert ein modularisiertes und gut strukturiertes Design, da der Code in kleinen, überprüfbaren Einheiten geschrieben wird.
  • Schnelle Fehlererkennung: Fehler werden früh im Entwicklungsprozess entdeckt, was die Fehlerbehebung erleichtert und die Kosten reduziert.
  • Dokumentation: Die Tests dienen als lebendige Dokumentation der Funktionalität des Codes, was die Verständlichkeit und Wartbarkeit erleichtert.
  • Nachteile von TDD:
  • Höherer initialer Aufwand: Das Schreiben von Tests vor der Implementierung kann zeitaufwendig sein und den Entwicklungsprozess anfangs verlangsamen.
  • Komplexität bei Änderungen: Bei größeren Änderungen am System müssen möglicherweise viele Tests angepasst werden, was zusätzlichen Aufwand bedeutet.
  • Falsche Sicherheit: Tests können eine trügerische Sicherheit vermitteln, wenn sie nicht alle möglichen Szenarien abdecken. Schlecht geschriebene Tests können ebenfalls zu Problemen führen.

In der Praxis überwiegen jedoch meist die Vorteile von TDD, insbesondere in Projekten, die eine hohe Codequalität und eine stabile Architektur erfordern.

c)

Angenommen, ein Team im SCRUM-Prozess hat eine Velocity von 30 Story Points pro Sprint. Ein Sprint dauert zwei Wochen. Wie lange wird es voraussichtlich dauern, ein Produkt mit einem Umfang von 180 Story Points fertigzustellen, vorausgesetzt, die Velocity bleibt konstant? Zeige Deine Berechnungen.

Lösung:

Berechnung der Fertigstellungsdauer eines Produkts im SCRUM-Prozess

Um die Fertigstellungsdauer für ein Produkt mit einem Umfang von 180 Story Points zu berechnen, können wir die Velocity des Teams nutzen. Die Velocity gibt an, wie viele Story Points das Team pro Sprint erledigt. In diesem Fall beträgt die Velocity 30 Story Points pro Sprint.

  • Gegebene Informationen:
  • Velocity: 30 Story Points pro Sprint
  • Produktumfang: 180 Story Points
  • Dauer eines Sprints: 2 Wochen
  • Schritte zur Berechnung:
  1. Anzahl der benötigten Sprints berechnen: Wir teilen den Produktumfang durch die Velocity: \begin{equation} \text{Anzahl der Sprints} = \frac{180 \text{ Story Points}}{30 \text{ Story Points pro Sprint}} = 6 \text{ Sprints} \end{equation}
  2. Gesamtzeit in Wochen berechnen: Da ein Sprint 2 Wochen dauert, multiplizieren wir die Anzahl der Sprints mit der Dauer eines Sprints: \begin{equation} \text{Gesamtzeit} = 6 \text{ Sprints} \times 2 \text{ Wochen pro Sprint} = 12 \text{ Wochen} \end{equation}

Daher wird es voraussichtlich 12 Wochen dauern, um das Produkt mit einem Umfang von 180 Story Points fertigzustellen, vorausgesetzt, die Velocity bleibt konstant.

Sign Up

Melde dich kostenlos an, um Zugriff auf das vollständige Dokument zu erhalten

Mit unserer kostenlosen Lernplattform erhältst du Zugang zu Millionen von Dokumenten, Karteikarten und Unterlagen.

Kostenloses Konto erstellen

Du hast bereits ein Konto? Anmelden