Dr. Thorsten Arendt Marburg, 22. Oktober 2015 · Das Wasserfallmodell von Barry Boehm 3 Software-Evolution WS 2015/2016 System Requirements Software Requirements Preliminary Design

Evolutionsprozesse

Dr. Thorsten Arendt Marburg, 22. Oktober 2015

Überblick

• Betrachtung der bekannten Softwareentwicklungsprozesse bezüglich Software-Evolution

• Evolutionsprozesse

• Techniken für Software-Evolution

• Beispiele für Evolutionsprozesse

• Entwicklungsprozesse in Open-Source-Projekten

• Kosten, Aufgaben und Probleme

2 Software-Evolution WS 2015/2016

Das Wasserfallmodell von Barry Boehm


System Requirements

Software Requirements

Preliminary Design

Detailed Design

Code and Debug

Test and PreOperations

Operations + Maintenance

Validation

Validation

Validation

Validation

Developm. Test

Validation Test

Revalidation Evolution → Wo ist hier die Evolution?

V-Modell


ExploratoryConceptual

Plans & Requirements

RequirementsBaseline

ProductDesign

DetailedDesign

Code Unit test

Acceptancetest

Usage & Support

VALIDATION

VERIFICATION

ConceptValidation

Prod. Des. Verification

Det. Des. Verification

Req. Val. / Des. Val. / Test Val.

ExploratoryConceptual

Plans & Requirements

RequirementsBaseline

ProductDesign

DetailedDesign

Code Unit test

Acceptancetest

Usage & Support

VALIDATION

VERIFICATION

ConceptValidation

Prod. Des. Verification

Det. Des. Verification

Req. Val. / Des. Val. / Test Val.

Evolution →

Wo ist hier die Evolution?

IBM Rational Unified Process (RUP)


(Konstruktion) (Inbetriebnahme) (Anfang) (Vertiefung )

Kern-Arbeits-schritte

Unter-stützende Arbeits-schritte

Evolution


Iterative Software-Entwicklung


Design (Lösungsmodell)

Implementierung (Lösung)

Analyse (Anforderungsmodell)

Test (Evaluierung)

Vorbereitung Nachbereitung


Agile Praktiken: Scrum, XP, etc.


• Iterative Entwicklung (getrieben durch neue oder geänderte Features)

• ständige Kommunikation der Entwickler mit dem Management und den Benutzern, kurze Rückkopplungsschleifen, schnelle Rückmeldungen

• Testgetriebene Entwicklung: Erst die Tests, dann die Implementierung.

• Ständiges Refactoring, fortlaufende Integration von Systemteilen

• Paarprogrammierung: Das Modell und der Programmcode werden immer von zwei Entwicklern/innen gleichzeitig entwickelt.

• Schnelle Code Reviews

• Gemeinsames Eigentum am Code Wo ist hier die Evolution?

Evolutionsprozesse


• Änderungsanforderungen sind die Auslöser für Software Evolution.

• Die Wahl eines bestimmten Evolutionsprozesses hängt von den folgenden Aspekten ab:

– Die Art des zu pflegenden Systems – Dem benutzten Entwicklungsprozess – Der Erfahrung und dem Wissen der Entwickler

Arten der Software-Wartung


• Perfective: Verbesserung der Systemfunktionalität

• Adaptive: Anpassung an Änderungen in der Umgebung

• Corrective: Beseitigung von Fehlern

System releaseplanning

Changeimplementa tion

Systemrelease

Impactanalysis

Changerequests

Adaptivemaintenance

Correctivemaintenance

Perfectivemaintenance

[Sommerville]

Evolutionsprozesse: Minizyklus


• Änderungsanforderung – Änderung der Anforderungsbeschreibung

• Planungsphase – Verstehen betroffener Programmkomponenten – Analyse der Änderungsauswirkungen

• Realisierung der Änderung – Umstrukturierung/Refactoring, um die anstehende Änderung

leichter durchführen zu können – Alle betroffenen Teile ändern

• Evaluation des Softwaresystems – Regressionstests

• Anpassung der Dokumentation

Techniken für Software-Evolution


• Planungsphase – Programmverstehen

• Wie funktioniert das existierende Programm? Wie ist es strukturiert?

– Analyse der Änderungsauswirkungen • Welche Teile werden durch die Änderungen betroffen sein?

• Realisierung der Änderung – Alle betroffenen Teile sollen konsistent geändert werden. – Restrukturierung/Refactoring

• Verbesserung der Softwarestrukturen, ohne das Systemverhalten zu ändern.

• Evaluation des Softwaresystems – Testen: War die Änderung lokal? Oder haben sich Teile geändert, die

gar nicht betroffen waren?

Evolutionsprozesse: Dringende Änderungen


• Dürfen realisiert werden, ohne alle Schritte eines wohldefinierten Evolutionsprozesses zu durchlaufen

• Dringende Änderungen sind nötig, wenn

– ein schwerwiegender Fehler beseitigt werden muss

– eine Änderung der Systemumgebung (z.B. neue Version des Betriebssystems) unerwartete Effekte zeigt

– Änderungen im Geschäftsablauf eine schnelle Antwort benötigt (z.B. Release eines Konkurrenzprodukts)

Beispiel für einen Evolutionsprozess (1)


• Änderungsanforderung – Legacy System mit 2-Ebenen-Architektur

service-orientiertes System

• Planungsphase – Was sind die funktionalen Einheiten, die Services werden? – Wie können diese Einheiten voneinander entkoppelt werden?

• Realisierung der Änderung – Unterscheidung: Web Services, interne Services und Operationen – Code Annotation: z.B. UI, Logic, Data, um den Code zu entwirren – Refactorings Methoden/Klassen mit eindeutigem Zweck

• Evaluation des Softwaresystems – Unit-Tests für die neuen Services



• Änderungsanforderung – Einheitlicher Zugriff auf Daten aus verschiedenen Komponenten

• Planungsphase – Verständnis der Komponentenschnittstellen – Integration in eine gemeinsame Schnittstelle

Anwendungen

Komponenten



• Realisierung der Änderung – Entwurf einer neuen Schicht, die die gemeinsame Schnittstelle für

Anwendungen und spezifische für verschiedene Komponententypen hat – Anpassung der Komponenten an ihren Schnittstellentyp

• Evaluation des Softwaresystems – Unit-Test für die Komponenten und die neue Schnittstelle

Anwendungen

Neue Schicht

Komponenten

Entwicklungsprozesse in Open-Source-Projekten


• Meist eine Form von Extreme Programming

• Meist minimaler Verwaltungsaufwand

• Frühe Phasen wie eine exakte Anforderungsanalyse spielen häufig keine Rolle.

• Der Entwicklungsprozess ist meist dynamisch.

• Es gibt nicht den einen Entwicklungsprozess für OSS.

• Dynamische Zielanpassung – Z.B. GCC ursprünglich ein C-Compiler für 32-Bit-Plattformen.

Heute werden mehr als 200 Plattformen unterstützt.

• Intensive Werkzeugunterstützung

Technologische Unterstützung


• Automatisches Management von – Mailinglisten – Diskussionsforen

• (Öffentliche) Repositories mit Web-Oberfläche – Subversion – Git / GitHub

• Große Anzahl von Mirror sites, um die Verfügbarkeit der Projektdaten zu erhöhen

• Werkzeugunterstützte Fehlererfassung und -bearbeitung und automatisiertes Fehlerverfolgungssystem

– Bugzilla

Welche Kosten verursacht Software Evolution?


• Von der Software abhängige Kosten (interne Faktoren) – Änderungsvorhersage: Welche Systemteile werden sich stark

ändern? – Softwarequalität: Je höher die Qualität, desto niedriger die

Kosten.

• Von der Software unabhängige Kosten (externe Faktoren) – Teamstabilität: niedrigere Kosten bei stabilem Team – Entwicklererfahrungen: Häufig sind Entwickler für Software-

Wartung unerfahren – Wartungsvertrag: Ohne Wartungsvertrag wenig ‚Design for

Change‘ – Alter der Software: Je älter, desto schwieriger zu warten.

Aufgaben und Probleme


• Diagnoseerfahrungen: Woher kommt der Fehler? Wie ist das Programm aufgebaut?

• Programmiererfahrungen: Wie können neue Funktionalitäten geschickt eingebaut werden, ohne neue Fehler zu produzieren?

• Debugging und Testerfahrungen: Was hat sich geändert, was nicht? Was muss getestet werden?

• Dokumentationserfahrung: Welche Funktionalität hat sich geändert? • Frustresistenz: unzufriedene Nutzer; Beseitigung von Problemen, die

andere verursacht haben; schlecht geschriebener und dokumentierter Code

Zusammenfassung


• Softwareentwicklungsprozesse müssen Evolution genügend berücksichtigen.

• Ein Softwaresystem muss für Evolution vorbereitet sein.

• Evolutionsschritte sollten systematisch durchgeführt werden, um die Qualität eines Systems nicht zu beeinträchtigen.

• Hypothese: Ein Großteil des Erfolgs von Open-Source-Software ist auf erfolgreiche Evolutionsprozesse zurückzuführen.

• Evolutionskosten sind schwer abzuschätzen.

Sekundär-Literatur


• Barry W. Boehm: Software Engineering Economics, 1981

• Die Beauftragte der Bundesregierung für Informationstechnik: V-Modell XT (http://www.v-modell-xt.de/)

• IBM: Rational Unified Process / RUP (http://www-01.ibm.com/software/rational/rup/)

• Roman Pichler, Scrum – Agiles Projektmanagement erfolgreich einsetzen, 1. Auflage, 2007

• Ian Sommerville: Software Engineering, 9. Auflage, 2013

http://www.v-modell-xt.de/





http://www-01.ibm.com/software/rational/rup/



Documents

Dr. Thorsten Arendt Marburg, 22. Oktober 2015 · Das Wasserfallmodell von Barry Boehm 3 Software-Evolution WS 2015/2016 System Requirements Software Requirements Preliminary Design