Software Engineering

Sammelbezeichnung für Programme für Rechensysteme einschließlich zugehöriger Dokumentation

Ingenieursmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen mit systematischen Werkzeugen, Methoden und Prinzipien

Bei Großprojekten

Kleine Fehler → große Wirkung

Schlechte Prozesse, mangelhafte Software bzw. Dokumentation

Ursache: Zeitmangel oder mangelnde Sorgfalt

Zeiteinplanen für den Abbau von Technical Debt und Qualitätssicherung

(Bsp. Reorganisieren von Klassen, Vereinfachen von Ablauflogik)

Scope: Funktion und Performance

Budget: Ressourcen, Kosten

Zeit

Qualität

Zeitmangel durch Komplexität und Technical Debt

Analytische: Messungen oder Testing

Konstruktive: Verhindern der Entstehung von Fehlern (Pair Programming, Refactoring)

Organisatorische unterstützende Maßnahmen für analytische und konstruktive Maßnahmen

In kleinen Schritten Software entwickeln und testen

Sinnvolle Benennung von Variablen

Übergabe von Variablen sinnvoll gestalten

Eine Funktion = eine Aufgabe

Selten sind alle Anforderungen am Anfang erfassbar

Stakeholder ändern ihre Meinung, am Anfang fehlen immer Informationen

Immer mehr Arbeit als Geld und Zeit vorhanden – Wichtiges zuerst

Reihenfolge von Aktivitäten ist fest definiert

Vorteil: Hohe Planbarkeit, einfach planbares Vorgehen mit Arbeitsteilung

Nachteil: Hohes Risiko bei geänderten Anforderungen

Nachteil: Qualität ist die einzige flexible Variable

Projektphasen werden kontinuierlich betrachtet und angepasst

Wasserfall: Fix = Requirements

Wasserfall: Flexibel = Ressourcen und Zeit

Agile: Fix = Ressourcen und Zeit

Agile: Flexibel = Requirements

Framework zur Bearbeitung komplexer Probleme

Ziel: Produkte mit größtmöglichem Wert erstellen

Agile Methode

Leichtgewichtig

Verständlich

Schwierige Umsetzung

Erstellt und priorisiert das Product Backlog

Eine Person

Für Developer verfügbar

Entwickelt das Produktziel

Kommunikation nach außen

Selbstverwaltend

Keine Teamänderungen während eines Sprints

Cross-funktional

Entwickelt das Produktinkrement

Managt den Scrum-Prozess

Beseitigt Hindernisse

Verantwortet die Effektivität des Teams

Führt Scrum ein

Liste offener Aufgaben

Product Owner ist für Ordnung, Priorisierung und Verfügbarkeit verantwortlich

Developer planen den Sprint bei der Übernahme der Items aus dem Product Backlog

Wofür: Sprintziel

Was: Product Backlog Items

Wie: Plan für die Lieferung des Inkrements

Lauffähige Software

Auch Mehrwert für andere Lieferergebnisse

Gemeinsames Verständnis von Vollständigkeit

Nachvollziehbare Checkliste

Gehört den Developern

Ändert sich häufig

Zeitraum, in dem Product Backlog Items zu einem Produktinkrement werden

So kurz wie möglich

Maximal 30 Tage

Scrum-Team liefert nach jedem Sprint etwas Neues für den Kunden

Kunde lässt das Scrum-Team während des Sprints in Ruhe

Einfache Synchronisation über die letzten 24 Stunden und die nächsten 24 Stunden

Besprechung der Sprintarbeit

Feedback sammeln

Mögliche Anpassung von Product-Backlog-Items

Was ist gut gelaufen?

Was ist schlecht gelaufen?

Was kann verbessert werden?

2–3 Verbesserungsmaßnahmen definieren

Emotionaler Austausch

Scrum-Team, bei Bedarf externe Teilnehmer

Nach jedem Sprint

Daily: Synchronisation des Teams

Sprint Review: Bewertung des Inkrements

Retrospective: Verbesserung des nächsten Sprints

Voraussetzung schaffen: Team ankommen lassen

Daten sammeln: Datenpool schaffen

Einsicht gewinnen: Muster erkennen

Aktionen beschließen: Verbesserungen festlegen

Abschließen: Selbstreflexion ermöglichen

Wird als Commitment verstanden

Realistisch oft schwer abschätzbar

Arbeit dehnt sich oft bis zur Deadline aus

Product-Backlog-Items werden nach Komplexität und Größe verglichen

Nach dem ersten Sprint Umrechnung in Zeit möglich

Nur Entwickler schätzen

Anzahl der Story Points, die pro Sprint abgeschlossen werden

Visualisierung der verbleibenden Story Points im Verlauf der Zeit

Zeigt die voraussichtliche Zeit bis zum Projektende

Methode zur Schätzung von Story Points für Product-Backlog-Items

Entwickler legen Karten mit Zahlen

Größte und kleinste Schätzung werden diskutiert

Konsens wird gefunden

Anforderungen an ein Backlog-Item zur Einplanung in einen Sprint

Checkliste zwischen Developern und Product Owner

Fehleinschätzung von Zeit und Kosten

Falsches Produkt wird entwickelt

Missverständnisse werden oft erst im Prototyp entdeckt

Teure Fehlerbehebung

Wichtigste Merkmale besitzen

Keine unnötigen Merkmale

Angemessen priorisierte Merkmale

Hoher Nutzen für den Kunden

Gliederung in überschaubare Einheiten

Festlegung von Beziehungen zwischen Komponenten

Hierarchische Gliederung

Use-Case-Diagramm (Makro)

Class-Diagramm (Mikro)

Component-Diagramm

Activity-Diagramm

Abbildungseigenschaft:

Abbildung existierender oder geplanter Realitäten

Verkürzende Eigenschaft:

Nur relevante Elemente werden dargestellt oder zusammengefasst

Zweckgebundenheit:

Nur für eine spezifische Verwendung gedacht

Makroarchitektur:

Hohes Abstraktionsniveau

Organisation des Gesamtsystems

Mikroarchitektur:

Detaillierte Beschreibung einzelner Komponenten

Basis für die Implementierung

Sichtbarkeit (Visibility: + - #)

Attribute

Methoden

Verbergen von Daten vor direktem Zugriff von außen

Zugriff nur über definierte Schnittstellen

Vorteile:

Bessere Testbarkeit

Mehr Übersichtlichkeit

Flexible Änderungen an privaten Teilen möglich

Hierarchischer Aufbau neuer Klassen auf Basis bestehender Klassen

Vorteil:

Hierarchische Dekomposition

Wiederverwendung von Eigenschaften und Methoden

Unterschiedliches Verhalten von Unterklassen

Unterklassen können Methoden überschreiben

Vorteil:

Austauschbarkeit von Komponenten

Single Responsibility Principle

Open-Closed Principle

Liskov Substitution Principle

Interface Segregation Principle

Dependency Inversion Principle

Jede Klasse, Komponente oder Methode soll nur eine Aufgabe besitzen

Offen für Erweiterungen

Geschlossen für Änderungen

Unterteilung in High-Level-, Mid-Level- und Low-Level-Komponenten

Schützt High-Level-Komponenten vor Änderungen

Unterklassen müssen die Basisklasse vollständig ersetzen können, ohne Fehler zu verursachen

Verhindert zu große Schnittstellen und unnötige Abhängigkeiten

Lösung:

Mehrere kleine spezialisierte Schnittstellen statt einer großen

Entkopplung einzelner Komponenten durch Interfaces

Abhängigkeit von Abstraktionen(Interface) statt konkreten Implementierungen(Klassen)

Komponenten werden unabhängiger und leichter austauschbar

Projektphasen werden kontinuierlich betrachtet und angepasst

Beschreibt den Fluss von Informationen zwischen:

Terminatoren (Systemumgebung)

Prozessen

Datenspeichern

Zeigt, wie Daten durch ein System fließen

Abstraktion

Strukturierung

Hierarchisierung

Modularisierung

Standardisierung

Programmieren und Fehlerbehebung erfolgen im Wechsel

Vorteile:

Schnelle Ergebnisse

Einfache Vorgehensweise

Nachteile:

Schlecht planbar

Aufwand schwer abschätzbar

Schlecht wartbar

Hohe Fehleranfälligkeit

Requirements

Design

Implementation

Verification

Maintenance

Analyse eines Problems in beide Richtungen

Wirkung analysieren:

„Na und dann?“

Ursachen analysieren:

„Wieso?“

Hilft dabei, Teufelskreise zu erkennen und Lösungsansätze zu finden

Ein großes Problem wird in kleinere Teilprobleme zerlegt

Für jedes Teilproblem werden Lösungsansätze gesucht

Falls keine eindeutige Lösung möglich ist, erfolgt eine weitere Zerlegung

Konkretes Ziel für einen Sprint

Verpflichtung (Commitment) des Scrum-Teams für den Sprint

Langfristiges Ziel des Scrum-Teams

Beschreibt den zukünftigen Zustand des Produkts

Das Product Backlog enthält die zur Zielerreichung notwendigen Arbeiten

Fachkompetenz:

Fachwissen

Methodenkenntnisse

Selbstkompetenz:

Selbstorganisation

Abstraktionsvermögen

Lernbereitschaft

Sozialkompetenz:

Teamfähigkeit

Empathie

Kommunikationsfähigkeit

Eine definierte Schnittstelle zwischen Komponenten

Legt fest, welche Daten oder Funktionen ausgetauscht werden

Beschreibt nicht, wie die Umsetzung intern erfolgt

Nur die angebotene Funktionalität wird festgelegt

Begeisterungsfaktoren und Leistungsfaktoren nähern sich hinsichtlich ihrer Relevanz für den Kunden an

Begeisterungsfaktoren werden zu Leistungsfaktoren

Leistungsfaktoren werden zu Basisfaktoren

Kundenerwartungen steigen mit der Zeit

Darstellung funktionaler Abläufe und Interaktionen eines Systems

Modellierung in der Anforderungsanalyse

Modellierung in der Designphase

Vorlage für die Implementierung

Vorteile:

Leicht verständlich

Gut lesbar

Ergänzt Use Cases um Prozessabläufe

Diagrammtyp

Startknoten (Vorbedingung)

Aktivität (Ereignis oder Aktion)

Bedingung (Guard Condition)

Entscheidungsknoten (Decision Node)

Kontrollfluss (Control Flow)

Endknoten (Nachbedingung)

Start:

Beginn des Ablaufs

Aktivität:

Auszuführende Handlung

Bedingung:

Voraussetzung für einen Ablaufpfad

Decision Node:

Verzweigung des Ablaufs

Control Flow:

Reihenfolge der Ausführung

Ende:

Abschluss des Ablaufs

Aktionen sind atomare Ereignisse

Aktivitäten bestehen aus einer geordneten Folge von Aktionen

Aktionsknoten sind die kleinsten Ausführungseinheiten

Aktivitäten können parallel ausgeführt werden

Beim Join müssen alle parallelen Abläufe abgeschlossen sein

Synchronisation erfolgt am Ende der Parallelität

Zusammenfassung mehrerer Objekte oder Parameter

Besitzen definierte Eingabeparameter

Besitzen definierte Ausgabeparameter

Ähnlich einer Exception-Behandlung

Umgibt bestimmte Aktivitätsknoten

Wird bei besonderen Ereignissen oder Fehlern aktiviert

Teil eines Systems

Besitzt bereitgestellte Schnittstellen

Besitzt benötigte Schnittstellen

Anzahl (Multiplizität)

Ganzes-Teil-Beziehung (Aggregation oder Komposition)

Rolle (Assoziation)

Generalisierung und Spezialisierung (Vererbung)

0 bis unendlich viele Objekte

Beziehung zwischen allgemeiner Superklasse und spezialisierter Subklasse

Spezialisierung erweitert eine Superklasse

Beschreibt Hierarchien in Klassenmodellen

Vererbung:

Subklasse erbt Attribute und Operationen der Superklasse

Subklasse kann die Superklasse ersetzen (Polymorphismus)

Erweiterung:

Subklasse ergänzt zusätzliche Attribute und Operationen

Überschreibung:

Subklasse definiert eigene Implementierung einer geerbten Operation

Ganzes-Teil-Beziehung zwischen Klassen

Teile können unabhängig vom Ganzen existieren

Lebensdauer der Objekte ist unabhängig

Starke Ganzes-Teil-Beziehung

Teilobjekte gehören ausschließlich zum Ganzen

Wird das Ganze zerstört, werden auch die Teile zerstört