Evolutionsprozesse. Dr. Thorsten Arendt Marburg, 23. Oktober 2014

Größe: px

Ab Seite anzeigen:

Download "Evolutionsprozesse. Dr. Thorsten Arendt Marburg, 23. Oktober 2014"

Gretel Adler
vor 8 Jahren
Abrufe

1 Evolutionsprozesse Dr. Thorsten Arendt Marburg, 23. Oktober 2014

2 Ü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 2014/2015

Software-Evolution Beispiele für Evolutionsprozesse

3 System Requirements Das Wasserfallmodell von Barry Boehm Validation Software Requirements Validation Preliminary Design Validation Wo ist hier die Evolution? Detailed Design Validation Code and Debug Developm. Test Evolution Test and PreOperations Validation Test Operations + Maintenance Revalidation 3 Software-Evolution WS 2014/2015

Detailed Design Validation Code and Debug Developm.

4 V-Modell Exploratory Conceptual Plans & Requirements Requirements Baseline Product Design Evolution Usage & Concept Support Validation Req. Val. / Des. Val. / Test Val. VALIDATION VERIFICATION Prod. Des. Verification Acceptance test Detailed Design Det. Des. Verification Wo ist hier die Evolution? Code Unit test 4 Software-Evolution WS 2014/2015

VALIDATION VERIFICATION Prod. Des. Verification Acceptance test Detailed Design Det.

5 IBM Rational Unified Process (RUP) (Anfang) (Vertiefung ) (Konstruktion) (Inbetriebnahme) Kern- Arbeitsschritte Unterstützende Arbeitsschritte Evolution Wo ist hier die Evolution? 5 Software-Evolution WS 2014/2015

6 Iterative Software-Entwicklung Wo ist hier die Evolution? Vorbereitung Nachbereitung Analyse (Anforderungsmodell) Test (Evaluierung) Design (Lösungsmodell) Implementierung (Lösung) 6 Software-Evolution WS 2014/2015

7 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? 7 Software-Evolution WS 2014/2015

kurze Rückkopplungsschleifen, schnelle Rückmeldungen Testgetriebene Entwicklung: Erst die Tests, dann die Implementierung.

8 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 8 Software-Evolution WS 2014/2015

Die Wahl eines bestimmten Evolutionsprozesses hängt von den folgenden

9 Arten der Software-Wartung Change requests Impact analysis System release planning Change implementa tion System release Perfective maintenance Adaptive maintenance Corrective maintenance [Sommerville] Perfective: Verbesserung der Systemfunktionalität Adaptive: Anpassung an Änderungen in der Umgebung Corrective: Beseitigung von Fehlern 9 Software-Evolution WS 2014/2015

maintenance [Sommerville] Perfective: Verbesserung der Systemfunktionalität Adaptive:

10 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 10 Software-Evolution WS 2014/2015

Umstrukturierung/Refactoring, um die anstehende Änderung leichter durchführen zu können Alle betroffenen

11 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? 11 Software-Evolution WS 2014/2015

Realisierung der Änderung Alle betroffenen Teile sollen konsistent geändert werden.

12 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) 12 Software-Evolution WS 2014/2015

werden muss eine Änderung der Systemumgebu

13 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 13 Software-Evolution WS 2014/2015

Realisierung der Änderung Unterscheidung: Web

14 Beispiel für einen Evolutionsprozess (2) Änderungsanforderung Einheitlicher Zugriff auf Daten aus verschiedenen Komponenten Planungsphase Verständnis der Komponentenschnittstellen Integration in eine gemeinsame Schnittstelle Anwendungen Komponenten 14 Software-Evolution WS 2014/2015

Planungsphase Verständnis der Komponentenschnittstellen Integration in

15 Beispiel für einen Evolutionsprozess (2) 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 15 Software-Evolution WS 2014/2015

Anpassung der Komponenten an ihren Schnittstellentyp Evaluation des Softwaresystems Unit-Test für die

16 AUTomotive Open System Architecture (AUTOSAR) 16 Software-Evolution WS 2014/2015

17 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 17 Software-Evolution WS 2014/2015

Es gibt nicht den einen Entwicklungsprozess für OSS. Dynamische Zielanpassung Z.B.

18 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 18 Software-Evolution WS 2014/2015

sites, um die Verfügbarkeit der Projektdaten zu erhöhen Werkzeugunterstützte Fehlererfassung

19 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. 19 Software-Evolution WS 2014/2015

Softwarequalität: Je höher die Qualität, desto niedriger die Kosten.

20 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 20 Software-Evolution WS 2014/2015

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

21 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. 21 Software-Evolution WS 2014/2015

22 Sekundär-Literatur Barry W. Boehm: Software Engineering Economics, 1981 Die Beauftragte der Bundesregierung für Informationstechnik: V-Modell XT ( IBM: Rational Unified Process / RUP ( Roman Pichler, Scrum Agiles Projektmanagement erfolgreich einsetzen, 1. Auflage, 2007 Ian Sommerville: Software Engineering, 9. Auflage, 2013 AUTOSAR: AUTomotive Open System Architecture ( 22 Software-Evolution WS 2014/2015

Ähnliche Dokumente

Einführung in die Softwaretechnik 9. Softwareprozesse

Einführung in die Softwaretechnik 9. Softwareprozesse 9. Softwareprozesse Klaus Ostermann (Mit Folien von Christian Kästner, Gabriele Taentzer und Wolfgang Hesse) 1 Agenda Wie kommt man vom Kundenwunsch zur fertigen Software? Wie strukturiert man ein Softwareprojekt?