Vorgehensweise bei der Softwareentwicklung

Code & Fix

▪ Lineare (aka phasenorientierte) Modelle ▪ Wasserfallmodell ▪ Nicht-lineare Modelle ▪ Rapid Prototyping ▪ Evolutionäre Entwicklung ▪ Iterative Entwicklung ▪ Inkrementelle Entwicklung ▪ Treppenmodell ▪ Spiralmodell ▪ V-Modell XT ▪ Rational Unified Process (RUP)

Modell des Softwareentwicklungsprozesses

in dem die konstituierenden Aktivitäten, typischerweise eine Konzeptphase,

Anforderungsphase, Entwurfsphase, Implementierungsphase, Test

und Installations- und Checkout-Phase in dieser Reihenfolge durchgeführt werden

dieser Reihenfolge durchgeführt werden, möglicherweise mit Überschneidungen, aber mit wenig oder keiner Iteration.

Lasten- & Pflichtenheft Dokumentierte Softwarearchitektur Getestete Komponenten Ausführbare Teilsysteme Produktivsystem

▪ Einfach & intuitiv ▪ Weit verbreitet ▪ Notwendigkeit eines strukturierten Vorgehens ▪ Dokumente ▪ Schriftliches Fixieren von Spezifikationen ▪ »Vertrag« zur Übergabe an Folgetätigkeit ▪ Als »Quasi-Meilensteine« im Projekt leicht kontrollierbar ▪ Prozessablauf transparent

▪ Auftraggeber nur am Anfang beteiligt: Anforderungen sind oft noch nicht eindeutig ▪ Tests & Abnahme erst spät: wenn System vollständig ▪ Kontinuierliche Qualitätssicherung problematisch ▪ »Tätigkeit« und »Phase« sind nicht klar getrennt ▪ Projektmanagement: Zyklen problematisch, keine Meilensteine zwischen Tätigkeiten

- Technik zur Entwicklung von Hardware und Software

bei der eine vorläufige Version eines Teils oder der gesamten Hardware oder

Software entwickelt wird, um Benutzer-Feedback zu erhalten, die

Durchführbarkeit zu ermöglichen oder den Zeitplan oder andere Fragen zur Unterstützung

den Entwicklungsprozess zu unterstützen.

Rapid Prototyping - Eine Art des Prototyping, bei der der Schwerpunkt

auf die Entwicklung von Prototypen in einem frühen Stadium des

Prototypen zu entwickeln, um frühes Feedback und Analysen zur Unterstützung des

Entwicklungsprozesses zu ermöglichen.

Übersetzt mit www.DeepL.com/Translator (kostenlose Version)

Mockup

iterative Entwicklung - Software-Entwicklungstechnik, bei der

bei der Anforderungsdefinition, Entwurf, Implementierung und

Testen in einer sich überschneidenden, iterativen (und nicht

iterativ (statt sequentiell) erfolgen, was zu einer schrittweisen Fertigstellung des

Softwareprodukts führt.

Inkrementelle Entwicklung - ... ist eine Staging- und Scheduling

Strategie, bei der verschiedene Teile des Systems zu unterschiedlichen

zu unterschiedlichen Zeiten oder Raten entwickelt und nach und nach integriert werden

fertiggestellt

Unterschied zur iterativen Entwicklung: ▪ Schrittweise Realisierung eines vollständig spezifizierten Gesamtsystems ▪ Die erste Ausbaustufe (Kernsystem) muss bereits ein funktional nutzbringender Teil des Gesamtsystems sein ▪ Jedes weitere Inkrement wird ausgeliefert und ebenfalls eingesetzt ▪ Vorteil: früh lauffähige Systeme

▪ Minimum Viable Product (MVP) ▪ »Version eines neuen Produkts, mit der ein Entwicklerteam möglichst große Erkenntnisse über Kunden mit möglichst geringem Aufwand gewinnen kann« (Eric Ries, The Lean Startup, 2011) ▪ Entwickle MVP → teste mit echten Nutzern → verbessere Produkt ▪ Gründe ▪ Marktchance mit geringen Entwicklungsaufwand & Risiko prüfen ▪ Nachweis Machbarkeit & Kompetenz ▪ Frühestmögliche Bereitstellung für early adopters

Individuen und Interaktion

Funktionierende Software

Zusammenarbeit mit Kunden

Reagieren auf Veränderung

Prozesse und Werkzeuge

Umfassende Dokumentation

Vertragsverhandlungen

Das Befolgen eines Plans

Adaptive Software Development (ASD) ▪ Agile Unified Process (AUP) ▪ Behavior-Driven Development (BDD) ▪ Dynamic Systems Development Method (DSDM) ▪ Extreme Programming (XP) ▪ Feature-Driven Development (FDD) ▪ Lean Software Development ▪ Kanban ▪ Rapid Application Development (RAD) ▪ Scrum ▪ Test-Driven Development (TDD

Agile Modelle sind oft keine »vollständigen« Prozessmodelle ▪ Fokus auf die eigentliche Softwareentwicklung ▪ Fehlende Aussagen zu Projektmanagement, Requirements Engineering, Testen etc. Agile Softwareentwicklung (1) Prof. Dr. Philipp Rohde 22WiSe-SWT-AC | 99 ▪ Agilität heißt nicht »formlos und ohne Regeln« ▪ Ebenfalls »Ergebnisse«: aber geringere Anzahl, weniger Formalismus ▪ Ebenfalls »Prozesse«: aber mehr Spielraum für Alternativen und Kreativität ▪ Ebenfalls »Verantwortlichkeiten«: aber weniger notwendige Rollen ▪ Ebenfalls »Feedback« & »Iterationen«: aber Rückmeldungen müssen gegeben & gefordert werden (push & pull

Umfang ist vorgegeben Umsetzung mit geringstem Ressourceneinsatz (Zeit & Team

Ressourcen (Zeit & Team) sind pro Iteration vorgegeben (Achtung: nicht insgesamt!) Iterative Umsetzung mit jeweils größtem Nutzen

Gesamtwert wird in beiden Fällen erst bei »Projektende« realisiert; bei agilem Ansatz aber: ▪ Wert wird kontinuierlich geliefert ▪ Verzögerungskosten (Cost of Delay) werden reduziert ▪ Ggf. auch höherer Gesamtwert, da auf neue Erkenntnisse schneller reagiert werden kann ▪ Ziel: Time-to-Market bzw. Time-to-Value verkürzen

▪ Sehr genaue Spezifikation ▪ Erlaubt TestAutomatisierung (wichtig für Continuous Integration) ▪ Ermöglicht eindeutige Definition of Done ▪ Exakte Messung des Fortschritts bzw. Grad der Umsetzung Cons

▪ Nur funktionale Anforderungen ▪ Keine vollstände Spezifikation ▪ Nicht alles ist ausreichend testbar bzw. automatisierbar ▪ Erstellung geeigneter Testfälle ist aufwändig ▪ Für Kunden oft zu komplex ▪ Gefahr, dass »Make it Blue« ignoriert wird (kein Clean Code

Erst werden die Testfälle präzisiert und möglichst automatisiert, dann folgt die Entwicklung auf Basis der Testfälle ▪ Entwicklung mit Fokus, die Tests zu erfüllen ▪ Tests »im Kleinen«, z.B. Komponententests (Unit Tests) ▪ Tests »im Großen«, z.B. Integration-, System- oder Abnahmetests ▪ Iterativer Ansatz: Quellcode wird solange verbessert, bis alle Tests erfolgreich sind

▪ Wunsch nach Agilität beim Auftraggeber ▪ Bedarf nach schneller Auslieferung eines ersten Inkrements ▪ Entwicklung neuartiger Lösungen ▪ Bewährte Zusammenarbeit von Auftraggeber/-nehmer ▪ Interne Projekte und neue Releases

Nicht sinnvoll ▪ Vorgabe, z.B. öffentliches Projekt ▪ Vollständige Planbarkeit nötig, z.B. Festpreisprojekt ▪ Auftraggeber/-nehmer nicht geeignet und unwillig ▪ Software nicht geeignet ▪ Geeignete Experten nicht verfügbar

▪ Scrum-Team ▪ Product Owner, Entwicklungsteam, Scrum Master ▪ Selbstorganisiert & interdisziplinär: Team entscheidet selbst, wie die Arbeit erledigt wird; alle nötigen Kompetenzen und Fähigkeiten; keine Abhängigkeit von Personen außerhalb; kein »Projektleiter«

Time Boxing ▪ Sprint-Dauer ist fest: sie darf weder gekürzt noch verlängert werden ▪ Alle Ereignisse haben feste zeitliche Beschränkung (sie dürfen aber vorzeitig beendet werden, sobald sie ihren Zweck erfüllt haben)

Product Owner▪• Einzelne Person, kein Komitee • Repräsentiert alle Stakeholder • Verantwortlich für Maximierung des Produktwerts • Definiert & priorisiert Anforderungen • Verantwortlich für Verwaltung des Product Backlog • Organisation muss Entscheidungen respektieren

Entwicklungsteam• Profis, die jedes Inkrement selbst herstellen • Selbstorganisiert & interdisziplinär • Keine Titel, keine Hierarchie, jeder ist »Entwickler« • Optimale Größe: 7 ± 2 Entwickler • Verantwortlich für alle Aufwandsschätzungen

Scrum Master • Verantwortlich, dass Scrum verstanden & richtig angewendet wird • Coach & Unterstützer • Beseitigt Hindernisse (Impediments), die das Team aufhalten • Verzichtbar, wenn Scrum etabliert

Product Backlog • Geordnete Liste von Anforderungen & Arbeit (insb. User Stories) • Dynamisch (Refinement) • Alle beteiligt, aber PO verantwortlich • Details: nur soweit für Planung des nächsten Sprints nötig • Je weiter oben, desto detaillierter • Good Practice: Value Points

Sprint Backlog • Auswahl von oben für nächsten Sprint • Pull-Prinzip: Entwickler wählen so viel, wie sie glauben, im Sprint schaffen zu können (Forecast & Velocity) • Verwaltet durch Entwicklungsteam • Entwickler definieren zugehörige Tasks • Transparent, dynamisch, aktuell

User Story • Beschreibung von Funktion oder Verhalten des Produkts • Angabe von Akzeptanzkriterien • Schätzung von Wert (Business Value) & Komplexität (Story Points) • Von PO gepflegt • Später meh

Task• Arbeitspaket mit Zuordnung zu Entwickler:in • Gehört immer zu einer User Story • Stets aktuelle Schätzung des restlichen Aufwands (Remaining Effort) • Umfang: maximal ein Tag • Alle Tasks einer User Story müssen umgesetzt werden

Burn -down Chart • Zeigt aktuelle Schätzung des restlichen Aufwands • Visualisiert SprintFortschritt • Jeder im Team kann stets aktuellen Stand einsehen • Alternativ: Burnup Chart mit geleisteter Arbeit

Definition of Done • Qualitätskriterien, wann Artefakte für das Inkrement abgeschlossen sind (zusätzlich zu Akzeptanzkriterien jeder User Story) • Am Anfang des Projekts festgelegt; üblicherweise durch Entwicklungsorganisation • Kann jederzeit angepasst werde

Sprint Planning

Daily scrum

Sprint review

Sprint retroperspective

Vor dem Sprint: Definition of Ready (DoR) ▪ Präzisiert: wann darf ein Arbeitsprodukt aus dem Product Backlog in einem Sprint bearbeitet, d.h. in den Sprint Backlog übernommen werden? ▪ Beispiele für eine User Story ▪ Ist die Beschreibung eindeutig und präzise? ▪ Sind alle Qualitätskriterien (z.B. INVEST) erfüllt? ▪ Sind alle Pflichtangaben vorhanden, insbesondere Akzeptanzkriterien, Story Points und Business Value? ▪ Ist der Bezug zur Architektur definiert? Sind die Auswirkungen auf alle anderen Komponenten geklärt? ▪ Sind alle notwendigen UML-Diagramme vorhanden? ▪ Sind genügend Testfälle spezifiziert (→ TDD)

Nach dem Sprint: Definition of Done (DoD) ▪ Präzisiert: wann ist ein Arbeitsprodukt abgeschlossen? ▪ Zwei Sichten ▪ Arbeitsprodukt: welche Eigenschaften muss es besitzen? ▪ Prozess: welche Tätigkeiten müssen erledigt sein? ▪ Gibt allgemeine Rahmenbedingungen, Qualitätsanforderungen und Vorgaben von Auftraggeber und Auftragnehmer wieder ▪ DoD auf verschiedene Ebenen möglich ▪ Allgemein für Arbeitsprodukte (z.B. User Stories) oder für Sprint, Release, Codierung, Design / Architektur, Tests, Rollout etc. ▪ Achtung: DoD ~ qualitativ versus Test ~ fachlich ▪ DoD macht typischerweise Aussagen zu Code Guidelines, Dokumentation, Tests / Testabdeckung, Code Reviews ▪ DoD muss präzise anwendbar sein

Continuous Integration ▪ Continuous Integration (CI) ▪ Fortlaufenden Zusammenführung der Komponenten zu einem System ▪ Verallgemeinerung des Nightly Build ▪ Ursprung: Kent Beck (Extreme Programming) & Martin Fowler ▪ Ziele ▪ Verkürzung der Releasezyklen ▪ Verbesserte Strukturierung der Anwendung (Feature-Driven Design) ▪ Automatisierung der Tests, frühe Entdeckung von Fehlern ▪ Ständige Verfügbarkeit von Demo- und Testsystemen ▪ Steigerung der Softwarequalität ▪ Continuous Delivery (CD) ▪ CI plus Auslieferung an Kunden ▪ Continuous Deployment ▪ CD plus Überführung ins Produktivsystem (Veröffentlichun

Gemeinsame Codebasis ▪ Automatisierte Übersetzung ▪ Einheitlich definierte Tests; statische Überprüfungen für jede Integration ▪ Automatisierte Verteilung / gespiegelte Produktionsumgebung ▪ Automatisierte Verteilung in alle Umgebungen (DEV, TEST, PROD) ▪ Änderungen werden in Abbild der Produktionsumgebung getestet ▪ Häufige Integration ▪ Reduziert Risiko von Fehlschlägen; sichert gemeinsame Codebasis ▪ Kontinuierliche Integration in Mainline (Trunk-Based Development, TBD) ▪ Kontinuierliche Test-Entwicklung ▪ Zu jeder Änderung: Tests, Test-Dokumentation, Code Coverage Analysis ▪ Kurze Testzyklen fördern häufige Integrationen ▪ Dokumentation und einfacher Zugriff ▪ Einfacher Zugriff für alle Beteiligten; automatisiertes Reporting

Versionsverwaltung (Version Control System, VCS) bzw. Quellcodeverwaltung (Source Code Management, SCM) ▪ Koordinierung des Zugriffs von mehreren Entwicklern ▪ Protokollierungen von Änderungen (Dateien, Versionen, Autor, Zeitpunkt, Kontext etc.) ▪ Vergleich und Wiederherstellung von alten Versionsständen ▪ Einfrieren spezifischer Version, z.B. eines Release (Code Freeze) ▪ Gleichzeitige Entwicklung mehrerer Entwicklungszweige (Branching) ▪ Zusammenführen einzelner Entwicklungszweige (Merging) ▪ Verwalten eines Hauptentwicklungszweig (Trunk oder Main

Beispiel: Concurrent Versions System (CVS), Subversion (SVN), Microsoft Team Foundation Server (TFS) ▪ Problem: Performanz, Single Point of Failure

Verteilt (Distributed) ▪ Distributed Version Control Systems, DVCS ▪ Beispiel: Git, BitKeeper, Mercurial

▪ Teams arbeiten an verschiedenen Features, die weitgehend überschneidungsfrei sind, aber Abhängigkeiten untereinander besitzen (Feature-Driven Development, FDD) ▪ Die Arbeit der Teams soll zusammengeführt werden, wobei Änderungen konsolidiert und unbeabsichtigte Auswirkungen reduziert werden müssen ▪ Software-Tester benötigen eine stabile Version zum Testen, während Entwickler ihre Arbeit fortsetzen wollen (mit zwischenzeitlich eventuell instabilen Code-Versionen) ▪ Weiterentwicklung an einer Entwicklungsversion, während vorhandene Produktiv-Versionen unterstützt werden müssen, z.B. durch Service Packs, Critical Fixes oder Security Patches

Branches erhöhen die Komplexität der Code-Verwaltung stark ▪ Beim Merge können Konflikte im Quellcode entstehen, die gelöst werden müssen ▪ Branche ist leicht, Merge oft »schmerzhaft« (»Merge Hell«) ▪ Braching Strategy festlegen (Projekt oder Organisation

Rückverfolgbarkeit - Grad, in dem eine Beziehung zwischen

zwischen zwei oder mehr Produkten des Entwicklungsprozesses hergestellt

Prozesses hergestellt werden kann, insbesondere zwischen Produkten, die eine

Master-Subordinate-Beziehung zueinander haben.

Rückverfolgbarkeitsmatrix - Matrix, die die Beziehung zwischen

zwischen zwei oder mehr Produkten des Entwicklungsprozesses aufzeichnet.

Auswirkungsanalyse (Impact Analysis) ▪ Was würde bei einer Änderung passieren? Welche Komponenten wären betroffen? ▪ Anforderungsüberdeckung (Requirements Coverage Analysis) ▪ Welche Anforderungen wurden bei der Umsetzung erfüllt? ▪ Testüberdeckung (Test Coverage Analysis) ▪ Welche Anforderungen wurden in welchem Umfang getestet? ▪ Nachvollziehbarkeit von Tests, IT-Governance-Kriterien etc. ▪ Beurteilung von Produktqualität und Projektfortschritt; Verständlichkeit von Fortschritts- und Abschlussberichten ▪ Wiederverwendung von Komponenten ▪ Fehlerursachensuche und Debuggin