318 lines
22 KiB
Markdown
318 lines
22 KiB
Markdown
|
||
**Softwaretechnik D: Qualitätssicherung und Wartung – Zusammenfassung**
|
||
|
||
**1. Motivation und Grundlagen**
|
||
|
||
* **Warum Qualität?** Software durchdringt unser Leben, Systemkomplexität steigt, Einsatz in sicherheitskritischen Bereichen. In Deutschland: Hohe Arbeitskosten erfordern hohe Qualität zur Wettbewerbsfähigkeit.
|
||
* **Qualitätsmerkmale:** Spezifikationsvollständigkeit, Testbarkeit, Portierbarkeit, Korrektheit, Ressourcenschonung, Einfachheit, Ausfallsicherheit, Rechengenauigkeit, Bedienbarkeit, Dokumentation.
|
||
* **Wie entsteht Qualität?** Durch gezielte Maßnahmen: Was, Wie, Wann, Wer?
|
||
* **Mittel zur Qualitätssicherung:** Reviews, Tests (Unit, Integration, Blackbox, Whitebox), Richtlinien, Standards, Planung, Schulungen, Werkzeuge, Metriken, Prozessqualität.
|
||
|
||
**2. Ziele und Themen**
|
||
|
||
* **Ziel:** Kenntnisse zur Erzielung eines definierten Qualitätsniveaus und methodisches Vorgehen bei der Softwarewartung.
|
||
* **Weg:** Operationalisierung des Qualitätsbegriffs über Qualitätsmodelle, Differenzierung in organisatorische, analytische und konstruktive Maßnahmen.
|
||
* **Themen:** Qualitätsmodelle, Fehlerquellen, Prozessqualität, konstruktive Maßnahmen, manuelle und dynamische Prüfmethoden (Tests), Testautomatisierung, Testen objektorientierter Programme, statische Prüfmethoden/Metriken, Werkzeuge/Build-Automatisierung, Wartung.
|
||
|
||
**3. Voraussetzungen und Klausur**
|
||
|
||
* **Voraussetzungen:** Softwaretechnik 1 und 2 (Analyse, Entwurf), Java-Programmiererfahrung.
|
||
* **Klausur:** Inhalte aus Vorlesung (Folien, Tafel), Übungen, Praktikum. Aufgabentypen: Definitionen, Verständnisfragen, Anwendung (Testfälle, Qualitätsmängel).
|
||
|
||
**4. Was ist Software?**
|
||
|
||
* Programme, Abläufe, Dokumentation, Daten.
|
||
* **Besonderheiten:** Immateriell, benötigt Träger, leicht änderbar, schwache Kausalität zwischen Änderung und Wirkung, keine stetige Funktion, schwer zu vermessen, wird entwickelt (nicht gefertigt), verschleißt nicht, altert über die Umgebung.
|
||
|
||
**5. Qualitätsmodelle**
|
||
|
||
* **Qualität:** Gesamtheit von Eigenschaften und Merkmalen zur Erfüllung gegebener Erfordernisse (DIN 55350).
|
||
* **Qualitätsmodell:** Ableitung von Unterbegriffen (Qualitätsmerkmale) und Teilmerkmalen zur Messbarkeit/Überprüfbarkeit durch Qualitätsindikatoren (Metriken).
|
||
* **FCM-Qualitätsmodelle:** Factor-Criteria-Metrics-Models
|
||
* Schematischer Aufbau: Software-Qualität -> Q-Merkmal (factor) -> Q-Teilmerkmal (criterion) -> Qualitätsindikatoren (metrics)
|
||
* **Sichtweisen:** Produktqualität, Prozessqualität.
|
||
* **Historische Modelle:** Qualitätenbaum (Boehm), ISO/IEC 9126, ISO/IEC 250nn.
|
||
* **ISO/IEC 25010:** Nur Produktqualität. Modelle: Product quality, Quality in use.
|
||
* **Product quality:** Functional suitability, Reliability, Performance efficiency, Security, Compatibility, Maintainability, Portability, Usability.
|
||
* **Quality in use:** Effectiveness, Efficiency, Satisfaction, Freedom from risk, Context coverage.
|
||
* **Qualitätsbewertung:** Soll-Ist-Vergleich. Abweichung = Fehler.
|
||
* **Qualitätsindikatoren (Metriken):** Vorgabe eines Ziels (Soll-Wert), Soll-Ist-Vergleich (Qualitätsmessung).
|
||
|
||
**6. Typische Fehlerquellen**
|
||
|
||
* Komplexität, Software-Größe, Fluktuation, falsche Übertragung von Produktionsprozessen.
|
||
* **Fehlerquellen nach Hof13:**
|
||
1. Lexikalische und syntaktische Fehler
|
||
2. Numerische Fehler (Überläufe, Y2K-Bug)
|
||
3. Semantische Fehler
|
||
4. Parallelität (Race conditions, Deadlocks)
|
||
5. Spezifikationsfehler (Unvollständigkeit, Widersprüche)
|
||
6. Portabilitätsfehler
|
||
7. Hardwarefehler
|
||
|
||
**7. Qualitätssicherung und -management**
|
||
|
||
* **Maßnahmen:**
|
||
1. Organisatorische Maßnahmen (Systematische Entwicklung, Richtlinien, Standards)
|
||
2. Konstruktive Maßnahmen (Fehlervermeidung von Beginn an)
|
||
3. Analytische Maßnahmen (Software-Prüfung)
|
||
* **Qualitätsmanagement:** Festlegung von Qualitätsanforderungen, Überprüfung der Einhaltung, Schaffung geeigneter Rahmenbedingungen.
|
||
* **Aktivitäten:**
|
||
* Qualitätsplanung: Festlegung von Qualitätsanforderungen an Prozess und Produkt.
|
||
* Qualitätslenkung und -sicherung: Umsetzung, Steuerung, Überwachung und Korrektur des Entwicklungsprozesses.
|
||
* Qualitätsprüfung: Durchführung der festgelegten Maßnahmen (Erfassung der Ist-Werte der Qualitätsindikatoren, Überwachung der Umsetzung der konstruktiven Maßnahmen, Tests, Durchsicht, Reviews).
|
||
* Qualitätsverbesserung: Auswertung der Qualitätssicherungsergebnisse und der Prozessverbesserungen.
|
||
* **Dokumentation:** Qualitätssicherungsplan (Prozess-orientiert), Prüfplan (Produkt-orientiert).
|
||
* **Qualitätsplanung:** Festlegung der Aufgaben, Vorgaben und Hilfsmittel, Termine, Verantwortlichkeiten.
|
||
* **Qualitätslenkung:** Reguläre, besondere und finale Aktivitäten.
|
||
* **Frühe Fehlerentdeckung:** Vermeidung von Summationseffekten. Ziele: Keine Fehler machen, Fehler früh entdecken und beseitigen.
|
||
* **Qualität und Projekt:** Qualität, Funktionalität, Kosten und Zeit sind über die Produktivität gekoppelt.
|
||
|
||
**8. Prozessqualität**
|
||
|
||
* Guter Prozess begünstigt gute Software.
|
||
* **Themen:** Softwareprojektmanagement, Vorgehens- und Prozessmodelle, Risikomanagement, Konfigurationsmanagement, Anforderungs- und Änderungsmanagement.
|
||
|
||
**9. Konstruktive Maßnahmen**
|
||
|
||
* Fehlervermeidung von Anfang an.
|
||
* **Maßnahmen:**
|
||
1. Qualifikation und Schulungen
|
||
2. Attraktive Arbeitsumgebung
|
||
3. Geeignetes Prozessmodell
|
||
4. Werkzeuge (CASE: computer-aided software engineering)
|
||
* Operationen: Editieren, Transformieren, Verwalten/Versionieren, Suchen, Nachvollziehen, Messen, Testen, Verbinden, Dokumentieren, Verfolgen/Überwachen.
|
||
* Werkzeug-Grundausstattung: Editor, Compiler/Linker, Versionsverwaltung, Automatisierung (Build, Test), Überdeckungsprüfung, Statische Prüfung/Vermessung, Code Review, Kommunikation/Dokumentation, Aufwandserfassung, Projekt-/Ressourcenplanung, Verfolgen-/Überwachen.
|
||
5. Geeignete Programmiersprache (Passend zur Problemdomäne, Eigenschaften zur Qualitätssteigerung)
|
||
6. Einhalten von Richtlinien (Vereinheitlichung, Fehlerreduktion)
|
||
* Notationskonventionen (Schreibweise von Bezeichnern, Layout des Quelltextes, Aufbau von Kontrollstrukturen)
|
||
* Sprachkonventionen (Regeln für die Formulierung von Anforderungen im Rahmen der Spezifikation, Umgang mit den semantischen Besonderheiten einer Programmiersprache)
|
||
7. Angemessene Dokumentation (Einfluss auf Qualitätsmerkmale)
|
||
* Externe Dokumentation (Pflichtenheft, Vertrag, Handbücher, Online-Hilfe)
|
||
* Spezifikationsdokumentation (zutreffend, vollständig, konsistent, neutral, nachvollziehbar, überprüfbar)
|
||
* Implementierungsdokumentation (Code-Dokumentation, externe Dokumente)
|
||
* Dokumentationsextraktion (JavaDoc)
|
||
8. Angemessene Architektur (Modularisierung, Hierarchisierung, Starker Zusammenhalt und schwache Kopplung, Trennung von Zuständigkeiten, Information Hiding)
|
||
9. Automatisierung (Build-Prozess, Programmtest, Versionierung, Datensicherung, Installation der Umgebungen)
|
||
* **Richtlinien:**
|
||
* Notationsstile für Bezeichner (Pascal Case, Camel Case, Upper Case, Lower Case, Ungarische Notation)
|
||
* Coding Style (Schreibweise von Bezeichnern, Anweisungen, Einrückungstiefe, maximale Zeilenlänge, Umbrüche/Leerzeichen, Deklarationsschemata, Dateiorganisation und -namen, Programmierpraktiken)
|
||
* Sprachkonventionen (MISRA-C)
|
||
* Regeln für natürlichsprachliche Spezifikationen
|
||
|
||
**10. Manuelle Prüfmethoden**
|
||
|
||
* Diagnostische Verfahren zur Ermittlung des Qualitätsniveaus.
|
||
* **Ziele:** Feststellung von Mängeln, Fehlern, Inkonsistenzen, Unvollständigkeiten, Verstößen gegen Vorgaben, formale Abnahme.
|
||
* **Voraussetzungen:** Aufwand und Zeit müssen eingeplant sein, Schulung der Prüfer, keine Beurteilung von Mitarbeitern, Dokumentation der Prüfmethode.
|
||
* **Methoden:**
|
||
1. Durchsicht (Entwickler alleine)
|
||
2. Stellungnahme (Autor gibt Artefakt an Dritte weiter)
|
||
3. Review (Formalisierter Prozess)
|
||
* Rollen: Moderator, Autor, Gutachter, Notar, Review-Team.
|
||
* Ablauf: Antrag, Planung, Festlegung der Aspekte, Auswahl der Prüfer, Eingangsprüfung, Verteilung des Prüfobjekts, Vorbereitung, Review-Sitzung, Entscheidung über Nacharbeit, Durchführung der Nacharbeiten, erneutes Review.
|
||
* Review-Regeln: Sitzungsdauer, Fokus auf Resultat, Rollenverteilung, keine Stilfragen, keine Lösungsentwicklung, angemessene Präsentation der Befunde, Protokollierung.
|
||
* Gewichtung der Befunde: Kritischer Fehler, Hauptfehler, Nebenfehler, Gut.
|
||
* Empfehlungen: Akzeptieren ohne Änderung, Akzeptieren mit Änderung, Nicht akzeptieren.
|
||
4. Structured Walkthrough (Einfachere Variante des Review)
|
||
|
||
**11. Programmtest (Dynamische Prüfung)**
|
||
|
||
* Ziel: Finden möglichst vieler Fehler.
|
||
* **Vorgehen:** Ausführung des Programms mit konkreten Werten, Vergleich der Ausgaben (Ist-Werte) mit den Soll-Werten.
|
||
* **Systematischer Test:** Randbedingungen definiert, Eingaben systematisch ausgewählt, Soll-Werte festgelegt, Testverlauf dokumentiert, Test und Korrektur getrennt.
|
||
* **Teststufen:**
|
||
* Unit-Test (Modultest, Komponententest): Test von Programmteilen (Funktionen/Methoden, Klassen, Komponenten).
|
||
* Integrationstest: Test des Zusammenspiels der integrierten Module/Komponenten.
|
||
* Ablauf: Big-Bang-Integration, Inkrementelle Integration (Top-down, Bottom-up, Outside-In, Kontinuierliche Integration).
|
||
* Systemtest: Test des komplett integrierten Systems aus Anwendersicht.
|
||
* Abnahmetest: Letzter Test vor der Inbetriebnahme, Abnahmekriterien im Entwicklungsvertrag.
|
||
* **Grenzen von Programmtests:** Vollständiger Test in der Praxis nicht möglich.
|
||
* **Testfall:** Ausgangssituation, Testdaten, Sollwerte.
|
||
* **Eigenschaften eines guten Testfalls:** Fehlersensitiv, repräsentativ, redundanzarm.
|
||
|
||
**12. Black-Box-Test (Funktionstest)**
|
||
|
||
* Testfälle auf Basis der Spezifikation.
|
||
* **Verfahren zur Bestimmung von Testfällen:**
|
||
1. Funktionale Äquivalenzklassenbildung: Aufteilung der Eingaben in Äquivalenzklassen, Test eines Repräsentanten pro Klasse.
|
||
2. Grenzwertanalyse: Test von Elementen an den Grenzen von Äquivalenzklassen.
|
||
3. Zustandsbezogener Test: Modellierung des Systems mit Zustandsautomaten, Test aller Zustände und Zustandsübergänge.
|
||
4. Test spezieller Werte: Test mit Eingaben, die häufig Fehler aufdecken.
|
||
5. Zufallstest: Zufällige Generierung von Testfällen.
|
||
* **Property-based Testing:** Prüfung, ob ein Prädikat erfüllt ist: $\forall x.P(x, f_{SUT}(x))$.
|
||
|
||
**13. Testautomatisierung**
|
||
|
||
* Wiederholung von Tests (Fehlernachtest, Regressionstests) erfordert Testautomation.
|
||
* **JUnit-Framework:** Unterstützung bei der Erstellung und Durchführung von Programmtests.
|
||
* **JUnit 5:** Testplattform (Platform, Jupiter, Vintage, Extensions).
|
||
* **JUnit 5 - Testklasse:**
|
||
* Testmethoden werden durch die Annotation `@Test` ausgezeichnet.
|
||
* Vor der Ausführung jeder Testmethode wird eine neue Instanz der Testklasse erzeugt.
|
||
* Umfangreichere Initialisierungen können in eine mit `@BeforeEach` annotierte Methode ausgelagert werden.
|
||
* Die Freigabe von Ressourcen kann dann in einer mit `@AfterEach` annotierten Methode erfolgen.
|
||
* **Wichtige JUnit 5-Annotationen:** `@Test`, `@BeforeEach`, `@AfterEach`, `@BeforeAll`, `@AfterAll`, `@DisplayName("")`.
|
||
* **Assert-Methoden:** `assertEquals()`, `assertSame()`, `assertTrue()`, `assertNotNull()`.
|
||
* **Erwartete Ausnahmen:** Test mit `assertThrows()`.
|
||
* **Test-Suite:** Zusammenfassung von Testfällen (mit `@Test` annotierte Methoden) einer Testklasse.
|
||
* **Parametrisierte Testmethoden:** Mehrfacher Aufruf einer Testmethode mit unterschiedlichen Parametern.
|
||
* **Testbarkeit:**
|
||
* Dependency Injection (DI): Assoziationen zu anderen Objekten werden von außen injiziert.
|
||
* Stubs vs Mocks:
|
||
* Stubs: Entkopplung der zu testenden Einheiten von der Umgebung, Simulation der Fachlogik, Zustandstest.
|
||
* Mocks: Entkopplung, Kontrolle der Anzahl und Abfolge der Methodenaufrufe, keine/begrenzte Simulation der Fachlogik, Verhaltenstest.
|
||
* **EasyMock-Framework:** Generierung von Mock-Objekten aus Interfaces zur Testlaufzeit.
|
||
|
||
**14. Build-Automatisierung**
|
||
|
||
* Automatisierung des Build-Prozesses.
|
||
* **Build-Tools:** make, Ant, Maven.
|
||
* **make:** Bedingungsgesteuerte Ausführung von Shell-Skript-Kommandos.
|
||
* **Ant:** Plattformunabhängigkeit, Konfigurationsdatei `build.xml` im XML-Format.
|
||
* **Maven:** Deklarativer Ansatz, Standardisierung, Management von Abhängigkeiten, Erweiterungen über Plug-ins.
|
||
* Konfigurationsdatei `pom.xml` (Project Object Model).
|
||
* Maven-Verzeichnisstruktur.
|
||
* Management von Abhängigkeiten (groupId, artifactId, version, type).
|
||
* Life Cycle und Phasen (Default, Clean, Site).
|
||
* Projektvorlagen (Archetypes).
|
||
* Grundeinstellungen (Compiler-Plugin, Surefire-Plugin).
|
||
* Reports für die Qualitätssicherung (Javadoc, Surefire-Report, Project-Info).
|
||
|
||
**15. Glass-Box-Test (White-Box-Test) / Strukturtest**
|
||
|
||
* Überdeckung des Codes durch die Testfälle analysiert.
|
||
* **Kontrollflussgraph:** Anweisungen als Knoten, Kontrollfluss als Kanten.
|
||
* **Überdeckungskriterien:**
|
||
1. Anweisungsüberdeckung (statement coverage) / C0-Test: Jede Anweisung im Programm muss im Test mindestens einmal ausgeführt werden.gg im Programm wird im Test mindestens einmal ausgeführt.
|
||
2. Bedingungsüberdeckung: Überprüfung der Bedingungen im Test.
|
||
* Einfache Bedingungsüberdeckung: Alle atomaren Teilbedingungen müssen während des Tests einmal true und einmal false ergeben.
|
||
* Mehrfach-Bedingungsüberdeckung: Alle Variationen der Belegung der atomaren Teilbedingungen werden getestet.
|
||
* Minimale-Mehrfach-Bedingungsüberdeckung: Jede Teilbedingung muss mindestens einmal true und einmal false sein.
|
||
3. Datenflussbasierte Überdeckung (Defs-Uses-Überdeckung): Verwendung von Variablen wird analysiert.
|
||
* Definition (def) einer Variablen / Wertzuweisung.
|
||
* Verwendung einer Variablen in einem Ausdruck zur Berechnung eines Wertes (berechnende Benutzung, computational-use, c-use).
|
||
* Verwendung einer Variablen in Bedingungen bzw. Prädikaten zur Berechnung von Wahrheitswerten (prädikative Benutzung, predicate-use, p-use).
|
||
* All Definitions (All-defs): Die Testfälle durchlaufen für jede Definition einer Variablen einen definitionsfreien Pfad zu mindestens einem p-use oder c-use.
|
||
* All c-uses: Die Testfälle durchlaufen für jede Definition einer Variablen einen Pfad zu allen definitionsfrei erreichbaren c-uses.
|
||
* All p-uses: Die Testfälle durchlaufen für jede Definition einer Variablen einen Pfad zu allen definitionsfrei erreichbaren p-uses.
|
||
* All uses: Die Testfälle durchlaufen für jede Definition einer Variablen einen Pfad zu allen definitionsfrei erreichbaren p- und c-uses.
|
||
* All c, some p: Die Testfälle erfüllen das All-c-uses-Kriterium. Existiert zu einer Definition keine berechnende Nutzung, so wird zusätzlich mindestens ein definitionsfreier Pfad zu einer prädikativen Nutzung hinzugenommen.
|
||
* All p, some c: Analog zu All-c-some-p-Kriterium mit vertauschten Rollen.
|
||
|
||
**16. Test objektorientierter Programme**
|
||
|
||
* Berücksichtigung zusätzlicher Eigenschaften: Zustand des Objekts, Objekte als Parameter und Rückgabewerte, Vererbung, Assoziationen, Polymorphismus.
|
||
* **Arten von Klassen:** Normale Klassen, abstrakte Klassen und Schnittstellen, parametrisierte (generische) Klassen, Unterklassen.
|
||
* **Testen normaler Klassen:** Test zustandsverändernder Methoden, Test des Objektlebenszyklus.
|
||
* **Testen von Unterklassen:** Systematischer Test aller Methoden der Oberklasse und der Unterklassen.
|
||
* **Testen abstrakter Klassen:** Test einer möglichst einfachen Unterklasse, die die abstrakte Klasse implementiert.
|
||
* **Testen nicht sichtbarer Bestandteile:** Test privater Methoden und Attribute über die öffentliche Schnittstelle, Lockerung der Sichtbarkeit auf Paketebene, Extra Testzugang, Zugriff über Reflection.
|
||
|
||
**17. Statische Prüfung / Metriken**
|
||
|
||
* Finden von Fehlern oder fehlerträchtigen Stellen in einem Dokument durch Werkzeuge.
|
||
* **Beispiele:** Rechtschreib- und Grammatikprüfung, UML-Syntaxprüfung, Syntaxanalyse, Konformitäts-/Konventionsanalyse, Prüfung auf Kontrollfluss- und Datenflussanomalien.
|
||
* **Softwaremetriken:** Quantitative Bewertung von Software-Systemen mit Hilfe von Kenngrößen.
|
||
* **Unterteilung:** Quantitätsmetriken, Komplexitätsmetriken, Qualitätsmetriken.
|
||
* **Objekte der Softwaremessung:** Anforderungsdokumentation/Spezifikation, Entwurfsdokumentation, Code, Testware, Benutzerhandbücher.
|
||
* **Sichten auf die Objekte:** Sicht der Typen, Sicht des Zwecks, Sicht des Anwenders.
|
||
* **Quantitätsmetriken:** Entwurfsgrößen, Codegrößen.
|
||
* **Codekomplexität:**
|
||
* Halstead-Metriken:
|
||
* Operatoren: Schlüsselwörter, Operatoren, Präprozessoranweisungen.
|
||
* Operanden: Variablen, Konstanten, Bezeichner.
|
||
* Basisparameter: t (Anzahl der unterschiedlichen Operatoren), d (Anzahl der unterschiedlichen Operanden), nt (Gesamtzahl aller Operatoren im Programm), nd (Gesamtzahl aller Operanden im Programm).
|
||
* Berechnungen:
|
||
* Größe des Vokabulars: $G = t + d$
|
||
* Länge des Programms: $N = n_t + n_d$
|
||
* Volumen des Programms: $V = N \times log_2 G$
|
||
* Level: $L = V^* / V$
|
||
* Schwierigkeit: $D = 1 / L$
|
||
* Aufwand: $E = V \times D$
|
||
* McCabe-Metrik:
|
||
* Kontrollflussgraph.
|
||
* Zyklomatische Komplexität: $V(G) = |E| - |N| + 2$
|
||
* **Objektorientierte Metriken:** OV (Object Variables), CV (Class Variables), NOA (Number of Attributes), WAC (Weighted Attribute per Class), WMC (Weighted Method per Class), DOI (Depth Of Inheritance), NOD (Number of Descandants), NORM (Number of Redefined Methods).
|
||
* **Konformitäts-/Konventionsanalyse:** Prüfung auf Einhaltung von Codierungsrichtlinien.
|
||
* **Datenflussanomalieanalyse:** Prüfung auf unstimmige Variablenzugriffe.
|
||
* **Statische Analyse mit Werkzeugen:** PMD, Checkstyle, CodePro Audit/Metrik.
|
||
|
||
**18. Build-Automatisierung / CI**
|
||
|
||
* Kontinuierliche Integration (CI): Häufige Integration neuer Artefakte/Komponenten durch einen vollautomatischen Build-Prozess.
|
||
* **Ziele:** Reduzierung von Risiken, Verbesserung der Produktqualität, Transparenz/Übersicht.
|
||
* **CI-Server:** Laufzeitumgebung zur Durchführung des kompletten Integrationsprozesses.
|
||
* **Build-Prozess:** Vorbereitende Maßnahmen, Übersetzen, Statische Prüfungen, Dynamische Prüfungen, Paketierung, Erzeugung von Berichten und Dokumentation, Bereitstellung/Verteilung.
|
||
* **CI-Praktiken:** Gemeinsame Codebasis im SCM, Automatisierte Builds, Automatisierte Durchführung von dynamischen und statischen Prüfungen, Automatisches Berichtswesen, Häufige Integration, Schnelle Build-Zyklen, Einfacher Zugriff auf Build-Ergebnisse und Berichte, Automatische Verteilung.
|
||
|
||
**19. Konfigurationsmanagement**
|
||
|
||
* Aktive Verwaltung eines sich ändernden Softwaresystems mit Hilfe von Richtlinien, Prozessen und Werkzeugen.
|
||
* **Bereiche:** Änderungs-Management, Versions-Management, Build-Management, Release-Management.
|
||
|
||
**20. Wartung**
|
||
|
||
* Arbeit an einem bestehenden Software-System, die nicht von Beginn der Entwicklung an geplant war.
|
||
* **Arten der Wartung:** Adaptive Wartung (Anpassung), Korrektive Wartung (Korrektur).
|
||
* **Systematisches Vorgehen:** Dokumentation des Ausgangszustands, Identifizierung des zu modifizierenden Teils, Testfälle, Entnahme, Bearbeitung und lokale Prüfung der Komponenten, Integration und Test, Dokumentation des neuen Zustands, Erfassung des Aufwands.
|
||
* **Change Management:** Verwaltung von Änderungen mit Hilfe von Problemmeldungen (Software Problem Report, SPR) und Änderungsanträgen (Change Request, CR).
|
||
* **Logging:** Erzeugung von Kontrollausgaben zur Erleichterung der Wartung.
|
||
* Log-Level: DEBUG, INFO, WARN, ERROR, FATAL.
|
||
* Logging-Frameworks: log4j.
|
||
|
||
|
||
|
||
|
||
|
||
# Note Notes
|
||
|
||
**Glass-Box-Test (White-Box-Test) / Strukturtest:**
|
||
S.223
|
||
**Kontrollflussgraph:**
|
||
- Ein Glass-Box-Test orientiert sich am Kontrollflussgraphen einer Code- Sequenz
|
||
- Anweisungen werden im Kontrollflussgraphen als Knoten dargestellt
|
||
- Der Kontrollfluss zwischen den Anweisungen wird über die Kanten repräsentiert
|
||
|
||
|
||
**Überdeckung**
|
||
1. Anweisungsüberdeckung (statement coverage) / C0-Test
|
||
- Jede Anweisung im Programm muss im Test mindestens einmal ausgeführt werden (100% Anweisungsüberdeckung)
|
||
2. Zweigüberdeckung (Entscheidungsüberdeckung) / C1-Test
|
||
- Jeder Zweig im Programm wird im Test mindestens einmal ausgeführt (100% Zweigüberdeckung)
|
||
- Die Zweigüberdeckung ist strenger, als die Anweisungsüberdeckung, wenn das Programm leere Zweige enthält (z.B. if-then ohne else- Zweig)
|
||
3. Bedingungsüberdeckung
|
||
- Die Zweigüberdeckung stellt sicher, dass eine logische Bedingung während des Tests mindestens einmal true und einmal false ist
|
||
- Wenn die Bedingung zusammengesetzt ist, wird damit aber nicht sichergestellt, dass die Teilbedingungen korrekt formuliert sind
|
||
- Eine Bedingung ist eine Verknüpfung von Teilbedingungen mit den logischen Operatoren AND, OR und NOT
|
||
- Eine (atomare) Teilbedingung enthält keine logischen Operatoren, sondern höchstens Relationssymbole (<,>,\=\=)
|
||
- Mehr: S.230f.
|
||
4. Datenflussbasierte Überdeckung (Defs-Uses-Überdeckung
|
||
- S. 233f.
|
||
|
||
|
||
**Metriken:** S.258f.
|
||
- Unterteilung von Software-Metriken
|
||
- Quantitätsmetriken
|
||
- Komplexitätsmetriken
|
||
- Qualitätsmetriken
|
||
- Halstead
|
||
- S.264f.
|
||
- Größe des Vokabulars: G = t + d
|
||
- Länge des Programms: N = nt + nd
|
||
- Volumen des Programms: V = N x log2 G
|
||
- Eine untere Schranke für die Operanden ist die Anzahl der Ein- und Ausgabeoperanden: d\*
|
||
- Größe des Minimalvokabulars: G\* = d\* + 2
|
||
- V\* = G\* x log2 G\*
|
||
- L = V\* / V
|
||
- D = 1 / L
|
||
- E = V x D
|
||
- E = V x D = V / L = V / (V\* / V) = V2 / V\*
|
||
- McCabe-Metrik
|
||
- V(G) = |E| - |N| + 2
|
||
- Kontrollflussgraph
|
||
- V(G) = |E| - |N| + 1
|
||
- stark zusammenhängender Graph
|
||
- ![[Pasted image 20250221131512.png]]
|
||
|