Software Engineering II (IB) Softwareevolution

Größe: px

Ab Seite anzeigen:

Download "Software Engineering II (IB) Softwareevolution"

Monika Krause
vor 6 Jahren
Abrufe

1 Software Engineering II (IB) Softwareevolution Prof. Dr. Oliver Braun Letzte Änderung: :17 Software Engineering II (IB), Softwareevolution 1/28

2 Softwareveränderungen Veränderungen der Software sind unvermeidbar neue Anforderungen Geschäftsumgebung verändert sich Fehler müssen behoben werden neue Hardware wird in das System eingebracht die Performanz oder Zuverlässigkeit muss erhöht werden Veränderungen an bestehender Software sind ein großes Problem Software Engineering II (IB), Softwareevolution 2/28

3 Spiralmodell von Entwicklung und Evolution Spiralmodell (Quelle: I. Sommerville: Software Engineering) Software Engineering II (IB), Softwareevolution 3/28

Evolution und Instandhaltung Alternativer Ansatz der, sobald die Umsetzung neuer Anforderungen immer weniger kosteneffizient ist, von der Evolution zur

4 Evolution und Instandhaltung Alternativer Ansatz der, sobald die Umsetzung neuer Anforderungen immer weniger kosteneffizient ist, von der Evolution zur Instandhaltung übergeht: Evolution und Instandhaltung (Quelle: I. Sommerville: Software Engineering) Software Engineering II (IB), Softwareevolution 4/28

5 Evolutionsprozesse abhängig von Art der Software Entwicklungsprozess Fähigkeiten der beteiligten Personen Vorschläge für Systemänderungen sind der Hauptantrieb für die Weiterentwicklung setzen sich über den gesamten Lebensdauer eines Systems fort Software Engineering II (IB), Softwareevolution 5/28

Sommerville: Software Engineering) Software

6 Identifizieren von Änderungen und Evolutionsprozesse Identifizieren von Änderungen und Evolutionsprozesse (Quelle: I. Sommerville: Software Engineering) Software Engineering II (IB), Softwareevolution 6/28

7 Softwareevolutionsprozess Der Prozess der Softwareevolution (Quelle: I. Sommerville: Software Engineering) Software Engineering II (IB), Softwareevolution 7/28

8 Agile Methoden und Evolution Entwicklung kann direkt in Evolution übergehen automatisiertes Testen ist dabei sehr sinnvoll einsetzbar Änderungen werden einfach als zusätzliche User Stories bzw. als neue Anforderungen in das Product Backlog aufgenommen Software Engineering II (IB), Softwareevolution 8/28

9 Dynamik der Programmevolution Untersuchung von Systemänderungen nach einigen empirischen Studien sind die eine Reihe von Regeln, Lehmans Gesetze, entstanden diese sind wahrscheinlich gültig für alle große betriebliche Softwaresysteme Software Engineering II (IB), Softwareevolution 9/28

10 Lehmans Gesetze Kontinuierliche Veränderung In einer realen Umgebung muss sich ein System unvermeidlich verändern. Sonst verliert es nach und nach an Nutzen. Zunehmende Komplexität Struktur wird mit Veränderungen immer komplexer. Zusätzliche Ressourcen für Erhalt und Vereinfachung der Struktur. Evolution umfangreicher Programme Programmevolution ist selbstregelnder Prozess. Systemeigenschaften wie Größe, Anzahl gemeldeter Fehler, bleiben vergleichbar groß. Organisatorische Struktur Über die Lebensdauer bleibt Entwicklungsrate annähernd konstant. Software Engineering II (IB), Softwareevolution 10/28

11 Lehmans Gesetze Fortsetzung Bewahrung der Vertrautheit Umfang der vorgenommenen Änderungen für jede neue Version nahezu konstant. Kontinuierliches Wachstum Funktionsumfang muss kontinuierlich wachsen für Kundenzufriedenheit. Abnehmende Qualität Die Qualität wird abnehmen, bis sie modifiziert wird, um Veränderungen in der Betriebsumgebung widerzuspiegeln. Umgang mit Rückmeldungen Müssen systematisch behandelt werden um messbare Produktverbesserung zu erreichen. Software Engineering II (IB), Softwareevolution 11/28

12 Softwarewartung Fehlerbehebung z.b. Programmierfehler, Fehler im Entwurf, Fehler in Anforderungen Anpassung an eine Umgebung z.b. neue Hardware, anderes Betriebssystem, Hinzufügen von Funktionalität wenn sich Systemanforderungen auf Grund von organisationsoder geschäftsbedingten Verädnerungen wandeln Software Engineering II (IB), Softwareevolution 12/28

13 Verteilung des Wartungsaufwands Wartungskosten i.d.r. ein Vielfaches der Entwicklungskosten. ungefähre Aufteilung der Wartungskosten (Quelle: I. Sommerville: Software Engineering) Software Engineering II (IB), Softwareevolution 13/28

14 Kostenfaktoren Wartung Stabilität des Teams Schlechte Entwicklungspraxis Wartungsvertrag oft unabhängig von Entwicklungsvertrag Mitarbeiterfähigkeiten Alter und Struktur des Programms Software Engineering II (IB), Softwareevolution 14/28

15 Software-Reengineering Restrukturieren oder neu schreiben von Teilen des Systems sinnvoll, wenn einige, aber nicht alle, Subsysteme regelmäßig gewartet werden müssen Vorteile verringertes Risiko gegenüber einer Neuentwicklung geringere Kosten gegenüber einer Neuentwicklung Software Engineering II (IB), Softwareevolution 15/28

16 Der Reengineering-Prozess Reengineering-Prozess (Quelle: I. Sommerville: Software Engineering) Software Engineering II (IB), Softwareevolution 16/28

17 Aktivitäten im Reengineering-Prozess 1. Übersetzung des Quellcodes mit Tool in neuere Programmiersprache oder in andere übersetzen 2. Reverse Engineering Analyse des Programms 3. Verbesserung der Programmqualität um es besser lesen und verstehen zu können 4. Modularisierung kann Refactoring der Architektur erfordern 5. Daten-Reengineering kann Veränderung der Datenbankschemata u.ä. erforderlich machen Software Engineering II (IB), Softwareevolution 17/28

18 Präventive Wartung durch Refactoring Verbesserungen am Programm vornehmen um der Degradierung durch Änderungen vorzubeugen Struktur verbessern Komplexität reduzieren Verständlichkeit erhöhen Software Engineering II (IB), Softwareevolution 18/28

19 Unterschied Reengineering und Refactoring Reengineering nachdem ein System eine Weile gewartet wurde und die Wartungskosten steigen Refactoring findet kontinuierlich während des gesamten Entwicklungs- und Evolutionsprozesses statt soll die Struktur- und Codedegradierung vermeiden helfen, die Wartung teuer macht Software Engineering II (IB), Softwareevolution 19/28

20 Refactoring und Agile Methoden Refactoring ist fester Bestandteil Änderungen stehen im agilen Prozess im Mittelpunkt daher häufiges Refactoring Software Engineering II (IB), Softwareevolution 20/28

21 Bad Smells Martin Fowler et al. haben Situationen (bad smells) identifiziert in denen der Code verbessert werden kann dazu gehören 1. Code-Duplizierung 2. Lange Methoden 3. Switch-Case-Anweisungen enthalten häufig doppelten Code 4. Datenklumpen gleiche Gruppe von Datenelementen (Felder, Parameter) wiederholt an mehreren Stellen 5. Spekulative Generalisierung Superklassen, die nur dafür da sind, falls es mal erweitert werden würde Software Engineering II (IB), Softwareevolution 21/28

22 Primitive Refactoring-Transformationen Vorschläge von M. Fowler Beispiele Extraktion von Methoden Konsolidierung bedingter Ausdrücke Hochziehen von Methoden in Superklasse Software Engineering II (IB), Softwareevolution 22/28

23 Verwaltung von Altsystemen Verständnis, dass Entwicklung und Betrieb/Wartung nicht zu trennen ist, wächst aber es sind immer noch viele geschäftskritische Altsysteme im Einsatz diese müssen aber auch erweitert werden und z.b. an E-Business angepasst werden oft nur begrenztes Budget für die Wartung vorhanden Software Engineering II (IB), Softwareevolution 23/28

24 Strategien 1. Das ganze System ausmustern. wenn das System keinen effektiven Beitrag zu den Geschäftprozessen leistet 2. Das System unverändert lassen und regelmäßig warten. wenn System recht stabil und wenig Änderungswünsche vorhanden sind 3. Das System per Reengineering sanieren, um seine Wartbarkeit zu erhöhen. wenn Systemqualität schlecht und weiterhin Änderungswünsche vorhanden 4. Das System ganz oder teilweise durch ein neues System ersetzen. wenn System, z.b. auf Grund neuer Hardware, nicht in Betrieb bleiben kann Software Engineering II (IB), Softwareevolution 24/28

25 Beispiele für die Beurteilung eines Altsystems Beurteilung Altsystem (Quelle: I. Sommerville: Software Engineering) Software Engineering II (IB), Softwareevolution 25/28

26 Konsequenzen 1. Niedrige Qualität, niedriger Geschäftswert sollten ausrangiert werden 2. Niedrige Qualität, hoher Geschäftswert Reengineering 3. Hohe Qualität, niedriger Geschäftswert weiter betreiben, solange es wenig kostet 4. Hohe Qualität, hoher Geschäftswert normale Systemwartung weiterführen Software Engineering II (IB), Softwareevolution 26/28

27 Geschäftswert eines Systems beurteilen mit den Systembeteiligten (z.b. Endbenutzer und Manager) über folgende Themen sprechen die Benutzung des Systems: wird es oft oder selten genutzt? die unterstützen Geschäftsprozesse Festhalten an ineffizienten Geschäftsprozessen? die Stabilität des Systems nicht nur technisches, sondern auch Geschäftsproblem! die Systemausgaben hängt das Geschäft von den Ausgaben des Systems ab? Software Engineering II (IB), Softwareevolution 27/28

28 Technische Qualität Folgende Daten können bei der Qualitätsbeurteilung nützlich sein: Verständlichkeit des Quellcodes Dokumentation vollständig? konsistent? aktuell? existiert ein explizites Datenmodell? Daten über mehrere Dateien verteilt? Daten aktuell? konsistent? Anwendungsleistung adäquat? gibt es für die Programmiersprache moderne Compiler? Wird die PL noch verwendet? werden alle Versionen/Bestandteile von einem Konfigurationsmanagmentsystems verwaltet? liegen Testdaten für das System vor? ist das Personal qualifiziert? Software Engineering II (IB), Softwareevolution 28/28

Ähnliche Dokumente

Software Evolution: Einführung. Dr. Thorsten Arendt Marburg, 15. Oktober 2015

Software Evolution: Einführung Dr. Thorsten Arendt Marburg, 15. Oktober 2015 Überblick Was ist Software-Evolution? Warum ist Software-Evolution wichtig? Was sind die Prinzipien der Software-Evolution?