Kapitel 7 - Evolution & Wartung Flashcards
(26 cards)
1
Q
Wartung, Hotline
Aspekte & Wartungsvertrag?
A
Aspekte:
- Gewährleistung = Fehlerbehebung auf Kosten des Herstellers
- Wartung/ Betrieb = technischer Betrieb durch Rechenzentrum und Administratoren
- Hotline (für Benutzer und/ oder technisch) durch spezielle Hotline-Mitarbeiter oder Projektmitarbeiter; letzeres v.a. in kleinen Firmen
Wartungs-Vertrag:
- regelt “Service-Level” = Ereichbarkeit, Median (Telefon, Email, Fax, Online-Formular), Zeit bis Reaktion, maximale System-Ausfallzeiten
2
Q
Wartung, Hotline
Organisation?
A
-
Mitarbeiter
- spezialisiert auf Wartung/ Hotline
- mit entsprechendem Arbeitsvertrag (Schichtendienst!)
- zumeist billiger als Projektmitarbeiter
- Outsourcing / Offshoring liegt im Trend
- Anfragen, Kommunikation, Bearbeiter und Status müssen dokumentiert werden
- Anfragen als Quelle für Systemerweiterungen nutzen -> nächste Version
- Klare Prozesse/Workflows
- Qualitätskontrolle der Hotline
3
Q
Was ist Reengineering?
A
- Software-Reengineering = Analyse von Anwendungssystemen + Überarbeitung eines Systems, um dessen Qualität zu verbessern
- U.a. Identifizierung und Dokumentation der Komponenten einer Software
- methodische Analyse der Software ausgehend vom Quellcode
4
Q
Wozu Reengineering?
A
- aktuelle bzw. nicht mehr verfügbare Informationen gewinnen (z.B. veraltete/fehlende Dokumentation)
- Komplexität von Anwendungssystemen beherrschen
- zusätzliche Softwareartefakte (z.B. entsprechend neuer Unternehmenslinien) herleiten
- Auswirkungen, Seiteneffekte und Schnittstellen von Änderungen identifizieren
- Wiederverwendung (von Softwarekomponenten und/oder Wissen) vorbereiten
5
Q
Reverse Engineering und Forward Engineering
Schaubild
A
6
Q
Was ist Softwarevisualisierung?
A
Softwarevisualisierung kann die Mehrdimensionalität von Software darstellen
7
Q
Was ist der Nutzen von Softwarevisualisierung?
A
- Softwarevisualisierung ist nützlich während der Softwareprogrammierung, Code-Inspektion, Test, Softwarewartung und Schulungen
- Sie spart bei diesen Tätigkeiten Zeit und vermeidet Fehler durch ein besseres Verständnis auch komplexer Software
- Allerdings: Visualisierung zeigt nur Auswahl aller Informationen und verwendet Konventionen
- immer umfangreichere Software -> Anforderungen an Entwicklung und Wartung steigen
- Immer größere Softwaresysteme benötigen Zusammenarbeit immer mehr Menschen
- Programmieren, Verstehen und Modifizieren wird dadurch immer schwieriger
- Techniken und Werkzeuge zur Unterstützung notwendig
- Softwarevisualisierung für Analyse, Entwurf, Test, Debugging und Wartung
8
Q
Die Visualisierungs-Pipeline (Schaubild)
A
9
Q
Probleme bei Visualisierung
A
-
Konventionen
- Grafiken sind nur verständlich wenn Konventionen bekannt sind
- Begrenzter Bildschirmplatz
- Kombination von mehreren Ansichten
- Visualisierungswerkzeuge sind spezifisch für eine bestimmte Programmiersprache
-
Timing von dynamischen Visualisierungen
- Wann soll eine dynamische V. aktualisiert werden
- Benutzer nicht überfordern
- Wichtige Ereignisse nicht verpassen
10
Q
Grundlagen der Visualisierung
A
Für eine grafische Darstellung existieren Konventionen - Abhängig von Umfeld und Kultur
- Größere Flächen bedeuten größere Zahl
- Bedeutung von Farben
- Zeitachse von links nach rechts…
11
Q
Arten von Visualisierung (3)
A
Statische Analyse
- Visualisierung unabhängig vom Ablauf des untersuchten Programms
Dynamische Analyse
- Visualisierung während der Laufzeit eines Programms
Entwicklungsgeschichte
- Versionen des Codes und Änderungen zwischen den Versionen bei Entwicklung und Wartung
12
Q
Statische Programm-Visualisierung
A
- Visualisierung der Struktur / Architektur der Software
- Hängt von Sprache/Sprachparadigma ab
-
objektorientierte Sprachen:
- Klassen, Methoden, Attribute, Vererbung, …
-
prozedurale Sprachen:
- Prozeduren, Aufrufe, …
UML-Diagramme von herkömmlihcen CASE-Werkzeugen dargestellt…
Vorteile
- Stellen objektorientierte Konzepte dar
- Geeignet für kleine Ausschnitte
Nachteile
- Skalieren nicht
- Benötigen Filter für relevante Informationen
- Nur voreingestellte Sichten
13
Q
Dynamische Programm-Visualisierung
A
Visualisierung dynamischen Verhaltens, z.B.
- Ausführungs-Trace
- Ressourcenverbrauch (Speicher/Laufzeit)
- Objekt-Interaktion
- …
Unterscheidung zwischen
- Codevisualisierung (ausgeführte Schritte)
- Datenvisualisierung (gelesene/geschriebene Speicherinhalte)
- Visualisierung der Architektur
Daten sammeln:
- ähnlich wie Fehlersuche im Quellcode
- zusätzliche Anweisungen im Quellcode (der “instrumentation code”) -> Ausgabe der gewünschten Daten, z.B. in eine Protokolldatei (Logdatei oder trace)
Probleme:
- Code-Instrumentierungsproblem
- Code-Änderung, z.B. Einfluss auf Performanz
- Skalierbarkeitsproblem
- Fülle der Details
- Traces werden sehr schnell enorm groß
- Vollständigkeitsproblem
- Information gilt nur für betrachtete Szenarien
14
Q
dynamische Visualisierung dieser Daten und deren Änderungen erfolgen durch….? (4)
A
- Akkumulation
- räumliche Projektion
- Animation
- Jeweils unterschiedliche zu visualisierenden Daten
- Speicherinhalte, Programmzustände, Datenflüsse und ausgeführte Befehle, Auslastung und Architektur
15
Q
Akkumulation
A
- Anzeige eines Mittelwerts, z.B. wie oft eine Anweisung ausgeführt wurde
- Durch Darstellung nur eines Wertes wird Information komprimiert, aber Detailinformationen gehen verloren
- Bspw. Zeitliche Abfolgen und Korrelation
16
Q
Räumliche Projektion
A
- Zeit durch Raum dargestellt: Zeitachse im zwei- oder dreidimensionalen Raum
- Konzentrierung auf wenige zu beobachtende Werte
- Im Diagramm sind zeitliche Trends oder Phasen sichtbar
17
Q
Animation
A
- Zeit durch Zeit dargestellt
- Jedes Bild stellt eine Momentaufnahme eines Prozesszustands zu einem bestimmten Zeitpunkt während dessen Ausführung dar
18
Q
Entwicklungsgeschichte dynamischer Visualisierung
A
- Auswertung von Metriken (z.B. Codemetriken) und deren Änderungen mit der Zeit
- Auswertungen struktureller Informationen und deren Änderungen mit der Zeit
- Identifikation von (Evolutions-)Mustern in der Softwareentwicklung mit Hilfe von visuellen Data Mining Techniken
19
Q
Migration
Charakteristiken von Alt-Systemen?
A
-
Veraltete Programmiersprachen
- Software Entropie(Unordnung) durch vielfältige korrektive und adaptive Maintenance-Aktivitäten
- Keine Code-Kommentierung oder Dokumentation vorhanden
-
Mangel an Expertenwissen
- Ursprüngliche Entwickler im Ruhestand - Junge Entwickler können alte Sprachen nicht oder kennen System nicht
- Systemerhaltung und Weiterentwicklung verursachen hohe Kosten
20
Q
Warum Migration? (Schaubild)
A
21
Q
Migration contra Forward Engineering? (Schaubild)
A
Das Forward Engineering erweitert die fachliche Funktionalität des Systems, die Migration jedoch nicht.
22
Q
Gründe für Migration (6)
A
- Erweiterung des Funktionsumfanges
- Expansion/Fusion (betriebswirtschaftliche/technische Änderungen)
- Zu hohe Lizensierungskosten
- höherer Servicelevel nötig
- neue Anwendungen nötig
- Bisherige IT kann mit Anforderungen nicht mithalten. Legacy-Systeme
23
Q
Anforderung an eine Migration (5)
A
- Garantie eines ununterbrochenen sicheren und zuverlässigen Betriebes
- aktuelle und zukünftig erwartete Anforderungen abdecken -> Änderungen
- 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
24
Q
Migrationsarten
A
25
Kriterien für die Aufteilung des Systems in Inkremente
* Funktionale Erweiterung und Migration werden voneinander getrennt
* Technische und fachliche Abhängigkeiten, denn Inkremente sollen weitgehend unabhängig voneinander sein
* Technische Komponenten wie
* Schnittstellen (z.B. Benutzeroberfläche oder deren einzelnen Funktionen und Masken)
* Anwendungen und Services
* Daten und Datenbanken
* Plattformen (Betriebssysteme, Hardware)
* Jobs und Skripte
* Nach Benutzergruppen
* Fachliche Testbarkeit (z.B. Geschäftsvorfall-Sequenzen)
26
Big Bang
* Komplette **Neuentwicklung** des Altsystems
* **Parallel** zum Altsystem Entwicklung und Test des neuen Systems
* Phasen des Wasserfallmodells, kompletter **Rollout auf einen Schlag**
* Hat neues System Test bestanden, wird im letzten Schritt (“Big Bang”) das **Altsystem deaktiviert**
