Modellbasierte Softwareentwicklung

Transcription

Betrieb und Wartung
Software Engineering 1
WS 2010/2011
Dr. Ina Schaefer
Software Systems Engineering
Technische Universität Braunschweig
(mit Folien von Dr. A. Herrmann und Dr. Chr. Kästner)
Aufwandsverteilung
Wasserfallmodell nach W. Royce (1970)
Analyse
Produktdefinition
Entwurf
10 %
20 %
EntwurfsSpezifikation
20 %
Implementierung
50 %
Code
Test,
Integration
geprüfter
Code
Wartung
Dr. Ina Schaefer
Seite 2
des
Aufwands
AufwandVerteilung
für Betrieb
und
Wartung
Relativer Anteil der Phasen am Gesamtaufwand über die gesamte Lebensdauer
eines Softwaresystems nach [Boehm,1973]
Entwicklung (40%)
Spezifikation
und
QualitätsArchitektursicherung
Detailentwurf
Entwurf
und
Codierung
16%
Dr. Ina Schaefer
8%
16%
Betrieb &
Wartung (60%)
Erweiterung,
Verbesserung
Anpassung
12%
36%
FehlerBehebung
12%
Seite 3
Übersicht
• Betrieb
• Installation
• Einführung und Schulungen
• Wartung
• Refactoring
• Migration
Dr. Ina Schaefer
Seite 4
Inbetriebnahme
Definition: Die Inbetriebsetzung ist die Gesamtheit der Maßnahmen,
die zur erstmaligen Funktionsübernahme von Komponenten und
Systemen an deren endgültigen Aufstellungsorten notwendig sind.
Die Inbetriebnahme ist unter Umständen sehr aufwendig, abhängig
vom Umfeld oder benötigter Software- und Hardwarelandschaft.
Daher ist die Installation im Vorfeld unbedingt genau zu planen.
Dr. Ina Schaefer
Seite 5
Installation
Wichtige Fragen bei der Planung der Installation:
• Auf welcher Maschine(n) läuft die Applikation?
• Ist (separate) Datenbank erforderlich?
• Integration von Fremdsystemen oder Bibliotheken?
• Wer führt Installation durch? (Entwicklungsteam,
IT-Abteilung, Anwender, …)
• Automatische Installationsroutinen?
• Betriebsbeginn?
• Dokumentation vorhanden? (Installationshandbuch,
Entwicklerdokumentation, …)
• Wer übernimmt die Abnahme (technisch, fachlich)?
• Gibt es Betriebshandbücher? Wer erstellt diese?
Dr. Ina Schaefer
Seite 6
Einführung der Software
Wichtig ist es, die Akzeptanz der Anwender zu erreichen, z.B. durch:
• Anwenderdokumentation
• Zielgruppen-orientiert
• Einführung in Leistungsumfang
• Nachschlagewerk für einzelne Funktionen
• Orientierung an Workflows der Anwendung, nicht an
technischer Struktur
• Hoher Beispielanteil (z.B. 30%)
• Anpassung bei Änderungen der Software
• Online-Hilfe
• Support-Hotline
• Probebetrieb
• Schulungen
Dr. Ina Schaefer
Seite 7
Schulungen
• Ziel: Benutzerkreisen die benötigten Funktionen und ihre
Bedienung möglichst praxisnah zu vermitteln
• Abhängig von Umfang der Software
• Zugeschnitten auf unterschiedliche Benutzerkreise
(z.B. Anwender, Administratoren, ….)
• ggf. Einsatz von professionellen Trainern
• Schulungskonzept:
• einzelne Schulungsmodule für unterschiedliche Funktionsmodule
• Vorkenntnisse der Teilnehmer beachten
• Interaktive Übungen fördern aktive Mitarbeit.
• Vertiefung der Theorie anhand von praktischen Übungen
• Kleine Gruppen
• Angepasstes Schulungsmaterial
Dr. Ina Schaefer
Seite 8
Betrieb
Checkliste zur Überprüfung bei laufendem Betrieb:
• Antwortzeiten akzeptabel?
• Verfügbarkeit ausreichend?
• Verhalten erwartungsgemäß?
• Umgebungsparameter in zulässigem Bereich (Temperatur, …)?
• Backup-Strategien und Wiederherstellungsmöglichkeiten?
• Redundanz und/oder Load Balancing notwendig?
• Auswirkungen von Ausfällen (Festplatten, Rechnerknoten, …) ?
• Gibt es single points of failure?
Dr. Ina Schaefer
Seite 9
Wartung (Maintenance)
Definition nach IEEE-Standard 610:
(1) The process of modifying a software system or a component
after delivery to correct faults, improve performance or other
attributes, or adapt to a changed environment.
(2) The process of retaining a hardware system or a component in
a hardware system, or restoring it to, a state in which it can perform
its required functions.
Wartung verändert die Funktion der Software nicht, sondern bringt
die technische Realisierung auf einen neuen Stand.
Dr. Ina Schaefer
Seite 10
Wartungsarten
• Korrektive Wartung (corrective maintenance):
Verbesserung von ein oder mehreren Fehlern
• Präventive Wartung (preventive maintenance):
Änderungen zur Verhinderung von Fehlern im Produktivbetrieb
(z.B. Y2K bug)
• Adaptive Wartung (adaptive maintenance):
Änderungen für die Anpassung an eine veränderte Umgebung
(Hardware, Software, …)
• Perfektionierende Wartung (perfective maintenance):
Verbesserung der Applikation, z.B. bessere Performance,
Speicherverbrauch, Anpassung der GUI, ….
Dr. Ina Schaefer
Seite 11
Wartungstätigkeiten
 Reengineering: Neuentwicklung eines bereits funktionierenden Teils
der Software bei gleichbleibender Funktionalität, z.B. um Qualität zu
verbessern.
 Reverse Engineering: Ableiten von Code oder Modellen aus
existierenden Artefakten, z.B. Binärcode oder Sourcecode, wenn zu
Alt-Systemen keine Dokumentation oder Source Code mehr
vorhanden ist, aber zur Anpassung/Wartung benötigt werden.
 Refactoring: Veränderungen im Sourcecode ohne Veränderung der
Funktion zur Verbesserung der Codequalität
Dr. Ina Schaefer
Seite 12
Refactoring
„Refactoring ist der Prozess, ein
Softwaresystem so zu verändern, dass
das externe Verhalten unverändert bleibt,
der Code aber eine bessere Struktur
erhält.“
(Martin Fowler)
Beispiele:
• Umbenennen einer Variablen (und aller Zugriffe)
• Teilen einer Methode in zwei Methoden
• Verschieben einer Klasse in ein anderes Package
Dr. Ina Schaefer
Seite 13
Gründe für das Refactoring
 Lesbarkeit / Übersichtlichkeit / Verständlichkeit
• Reduktion vom Komplexität, z.B. Aufteilen von Methoden
• Bewusste Benennung von Variablen, Methoden, …
 Wiederverwendung / Entfernen von Redundanz
• Methoden aufteilen, um Teile wiederzuverwenden
• Kopierte Quelltextfragmente in eine Methode extrahieren
 Erweiterbarkeit
 Testbarkeit
Dr. Ina Schaefer
Seite 14
Code Smells und Refactorings
Code Smell
Refactoring
 Schwächen im Quelltext
 Aus Erfahrung festgehalten
 Beispiele
• sehr lange Methode
• sehr tiefe Schachtelung
• Kommentare wegen
komplexem Code
• viele mehr
 Rezepte zur Verbesserung
 Manuelles Vorgehen und
Automatisierung möglich
 Besteht aus:
• Name
• Motivation
• Vorgehen
• Beispiele
Zuordnung: welches Refactoring hilft
bei welchem Code Smell.
Dr. Ina Schaefer
Seite 15
Refactoring: Extract Method
“Turn a fragment into a method whose name explains the purpose of the method.”
void printOwning(double amount) {
printBanner();
//print details
System.out.println(“name: “ + _name);
System.out.println(“amount: “ + amount);
}
void printOwning(double amount) {
printBanner();
printDetails(amount);
}
void printDetails(double amount) {
System.out.println(“name: “ + _name);
System.out.println(“amount: “ + amount);
}
Dr. Ina Schaefer
Seite 16
Extract Method
Motivation / Code Smells:
 Methode ist zu lang.
 Methode braucht Kommentare für Struktur/Verständniss.
 Kopiertes Codefragment in vielen Methoden benutzt.
Dr. Ina Schaefer
Seite 17
Extract Method – Vorgehen
1.
2.
3.
4.
5.
6.
Dr. Ina Schaefer
Neue Methode anlegen – sinnvollen Namen vergeben
Zu extrahierenden Code in die neue Methode kopieren
Zugriffe auf lokale Variablen suchen -> als Parameter übergeben
Temporäre Variablen nur in Fragment benutzt -> in neuer Methode
anlegen
Werden lokale Variablen verändert? -> Rückgabewert der neuen
Methode
Originalquelltext mit Methodenaufruf ersetzen
Seite 18
Extract Method
Bedingungen (Auszug):
• Extrahierter Code muss ein oder mehrere komplette Statements
beinhalten.
• Maximal auf eine lokale Variable (die später benutzt wird) wird
schreibend zugegriffen.
• Bedingtes return-Statement ist verboten.
• Break und Continue verboten, wenn das Ziel außerhalb des zu
extrahierenden Code liegt
Dr. Ina Schaefer
Seite 19
Automatisierte Refactorings
Viele Entwicklungsumgebungen (z.B. Eclipse, IntelliJ) automatisieren
Refactorings:
Dr. Ina Schaefer
Seite 20
Migration
Migration: Transferieren einer Anwendung von ihrer bisherigen
Umgebung in eine geänderte Umgebung mit allen notwendigen
Änderungen
Unterschiedliche Migrationsarten:
• Softwaremigration: Austausch eines Teils der Software
• Datenmigration: Transfer von Daten von einem System in
ein anderes System
• Hardwaremigration: Umstellung von veralteter Hardware
Dr. Ina Schaefer
Seite 21
Charakteristika von Alt-Systemen
 Veraltete Programmiersprachen
• Software Entropie durch vielfältige korrektive und adaptive
Maintenance-Aktivitäten.
 Keine Code-Kommentierung oder ausreichende Dokumentation
vorhanden
 Mangel an Expertenwissen
• Ursprüngliche Entwickler im Ruhestand- Junge Entwickler
können alte Sprachen nicht.
 Systemerhaltung und Weiterentwicklung verursachen hohe Kosten.
Dr. Ina Schaefer
Seite 22
Gründe für Migration
 Erweiterung des Funktionsumfanges
 Betriebswirtschaftliche/technische Änderungen (z.B.
Fusion/Expansion)
 Zu hohe Lizensierungskosten für verwendete Frameworks oder
Bibliotheken
 Notwendigkeit höherer Servicelevels
 Notwendigkeit neuer Anwendungen
 Bisherige IT kann mit Anforderung nicht mithalten (LegacySysteme).
Dr. Ina Schaefer
Seite 23
Migrationsarten
Neuentwicklung/ Replacement
Neuentwicklung des gesamten
Altsystems
Kapselung /Wrapping
Bestehendes Altsystem wird mit
einer Hülle umgeben, um es an
neue Operationsformen oder
Oberflächen anzupassen.
Einsatz von Standardsoftware
Altsystem wird teilweise oder ganz
durch Standardsoftware ersetzt.
Rehosting
Vollständiges Altsystem bewegt
sich von einer Umgebung in eine
andere.
Beibehalten des Status Quo
Nichts wird verändert. Vorteil:
Keine Kosten, allerdings indirekte
Kosten durch fehlende/falsche
Funktionalität.
Dr. Ina Schaefer
Seite 24
Anforderungen an eine Migration
 Garantie eines ununterbrochenen sicheren und zuverlässigen
Betriebes
 aktuelle und zukünftig erwartete Anforderungen abdecken
 so wenige Änderungen wie möglich, um Umfang und Risiko der
Migration zu verringern
 alten Code soweit abändern, dass er die Migration unterstützt
 möglichst große Flexibilität einbauen, um zukünftige Änderungen zu
erleichtern
Dr. Ina Schaefer
Seite 25
Vorgehen bei der Migration
Rollout-Plan ist die Grundlage für die Planung der Verfügbarkeit
der Ressourcen bei der Migration:
• Aktivitäten für Inbetriebnahme
• Umstellung und Stilllegung von Systemkomponenten
• Fallback-Strategie
• Migrationsstrategien:
• Chicken Little Strategy
• Big Bang/Cold Turkey Strategy
Dr. Ina Schaefer
Seite 26
Big Bang / Cold Turkey
Vollständige Ablösung des Altsystems auf einen Schlag
Dr. Ina Schaefer
Seite 27
Big Bang/Cold Turkey
Bewertung
 Vorteile:
• keine Parallelexistenz von Neu- und Altsystem
• keine Entwicklung von Übergangslösungen
 Nachteile:
• hohes Risiko bei der Umstellung auf potentiell
unzuverlässiges System
Dr. Ina Schaefer
Seite 28
Little Chicken
Inkrementelle Migration: Umstellung in kleinen, überschaubaren Schritten
Ein Gateway isoliert die zu ändernden Komponenten und übersetzt
Anfragen und Daten an der Schnittstelle der isolierten Komponenten.
Dr. Ina Schaefer
Seite 29
Little Chicken – Inkrementelle Migration
• Forward Migration: Datenbank wird vor Applikation migriert.
Altsystem greift über Gateway auf neue Datenbank zu.
• Backward Migration: Applikation wird zuerst migriert.
Gateway stellt Zugang zu alter Datenbank bereit.
Bewertung
• Vorteile:
• geringeres und überschaubareres Risiko
• Nachteile:
• Parallelexistenz von Neu- und Altsystem
• Zusatzaufwand für die Entwicklung von Übergangslösungen
Dr. Ina Schaefer
Seite 30
Zusammenfassung
• Betrieb und Wartung nehmen im Gesamtlebenszyklus eines
Softwaresystems einen großen Anteil ein.
• Inbetriebnahme erfordert sorgfältige Planung.
• Während des laufendes Betriebs ist eine ständige Überwachung und
Wartung des Softwaresystems notwendig.
• Refactoring ist ein wichtiger Bestandteil der Wartungsaktivitäten.
• Migrationen können nach unterschiedlichen Strategien durchgeführt
werden.
Literatur:
T. Grechenig et al.:“Softwaretechnik“, Pearson Studium, 2010. (Kapitel 8)
Dr. Ina Schaefer
Seite 31

Modellbasierte Softwareentwicklung

Transcription

Documents pareils

SPORTGEMEINSCHAFT GITTERSEE eV

formetric Infozettel vorne 01022008 V2

Schiffs-, Boots-, Segel- und Yacht-Zubehör

Software Engineering 1

Systems Engineering in der Entwicklung des Airbus A400M

Die Hirsche der Jodlerin

50-250.10 ghb – spiro - georges

Beispiel für Literaturverzeichnis APA-Style

Selbstdarstellungsflyer - Flüchtlingsrat Baden

Refactoring in der Ontologiegetriebenen Softwareentwicklung