vault backup: 2025-02-21 16:16:30

WS2425/SWT D/Notes.md

@@ -265,6 +265,144 @@
 
 
 
+**Softwaremetriken: Detaillierte Betrachtung**
+
+**1. Was sind Softwaremetriken?**
+
+*   **Definition:** Softwaremetriken sind quantitative Messungen, die verwendet werden, um verschiedene Aspekte von Softwareprodukten, -prozessen und -ressourcen zu bewerten und zu verfolgen. Sie liefern Einblicke in die Qualität, Komplexität, Größe, Effizienz und andere wichtige Eigenschaften von Software.
+*   **Zweck:**
+    *   **Verstehen:** Metriken helfen, die Eigenschaften von Software besser zu verstehen und zu quantifizieren.
+    *   **Vergleichen:** Sie ermöglichen den Vergleich verschiedener Softwareprodukte, -versionen oder -projekte.
+    *   **Vorhersagen:** Metriken können verwendet werden, um zukünftige Entwicklungen, Kosten oder Risiken vorherzusagen.
+    *   **Steuern:** Sie unterstützen die Steuerung von Softwareentwicklungsprozessen und die Optimierung von Ressourcen.
+    *   **Kommunizieren:** Metriken dienen als Kommunikationsmittel zwischen Entwicklern, Managern und anderen Stakeholdern.
+
+**2. Kategorien von Softwaremetriken**
+
+*   **Quantitätsmetriken:** Messen die Größe und den Umfang von Software.
+    *   **Beispiele:**
+        *   *Lines of Code (LOC):* Anzahl der Codezeilen in einem Programm.
+        *   *Function Points (FP):* Messung der Funktionalität, die ein Softwaresystem bietet.
+        *   *Number of Classes/Modules:* Anzahl der Klassen oder Module in einem System.
+*   **Komplexitätsmetriken:** Bewerten die Komplexität von Software.
+    *   **Beispiele:**
+        *   *Cyclomatic Complexity (McCabe):* Messung der Anzahl unabhängiger Pfade durch ein Programm.
+        *   *Halstead Metrics:* Messung der Komplexität basierend auf der Anzahl der Operatoren und Operanden.
+        *   *Coupling and Cohesion:* Messung der Abhängigkeiten zwischen Modulen und des Zusammenhalts innerhalb von Modulen.
+*   **Qualitätsmetriken:** Bewerten die Qualität von Software.
+    *   **Beispiele:**
+        *   *Defect Density:* Anzahl der Fehler pro Codezeile oder Funktionseinheit.
+        *   *Mean Time To Failure (MTTF):* Durchschnittliche Zeit zwischen Ausfällen eines Systems.
+        *   *Maintainability Index:* Messung der Wartbarkeit von Software.
+        *   *Code Coverage:* Prozentsatz des Codes, der durch Tests abgedeckt wird.
+
+**3. Anwendungsbereiche von Softwaremetriken**
+
+*   **Anforderungsanalyse:** Messung der Vollständigkeit und Konsistenz von Anforderungen.
+*   **Entwurf:** Bewertung der Qualität des Softwaredesigns.
+*   **Codierung:** Überwachung der Codequalität und -komplexität.
+*   **Testen:** Messung der Testabdeckung und Fehlerdichte.
+*   **Wartung:** Bewertung der Wartbarkeit und Änderungsfreundlichkeit von Software.
+*   **Projektmanagement:** Verfolgung des Projektfortschritts und der Ressourcennutzung.
+
+**4. Beispiele für Softwaremetriken und ihre Berechnung**
+
+*   **Lines of Code (LOC):**
+    *   *Berechnung:* Zählen der Anzahl der Codezeilen in einem Programm.
+    *   *Interpretation:* Höhere LOC kann auf größere Komplexität hindeuten, aber auch auf Redundanz.
+*   **Cyclomatic Complexity (McCabe):**
+    *   *Berechnung:* $V(G) = E - N + 2$, wobei E die Anzahl der Kanten und N die Anzahl der Knoten im Kontrollflussgraphen ist.
+    *   *Interpretation:* Höhere zyklomatische Komplexität deutet auf komplexeren Code hin, der schwieriger zu testen und zu warten ist.
+*   **Halstead Metrics:**
+    *   *Basisparameter:*
+        *   $t$: Anzahl der unterschiedlichen Operatoren
+        *   $d$: Anzahl der unterschiedlichen Operanden
+        *   $n_t$: Gesamtzahl aller Operatoren im Programm
+        *   $n_d$: 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$
+    *   *Interpretation:* Höheres Volumen und höherer Aufwand deuten auf komplexeren Code hin.
+*   **Weighted Method per Class (WMC):**
+    *   *Berechnung:* $WMC = \sum_{i=1}^{M} v(m_i)$, wobei $v(m_i)$ die Komplexität der Methode $m_i$ ist (z.B. zyklomatische Komplexität).
+    *   *Interpretation:* Höherer WMC deutet auf eine komplexere Klasse hin, die schwieriger zu verstehen und zu testen ist.
+
+**5. Herausforderungen bei der Verwendung von Softwaremetriken**
+
+*   **Interpretation:** Metriken müssen im Kontext interpretiert werden. Eine hohe LOC ist nicht immer schlecht, und eine niedrige zyklomatische Komplexität garantiert keine hohe Qualität.
+*   **Manipulation:** Metriken können manipuliert werden, um ein gewünschtes Ergebnis zu erzielen.
+*   **Kosten:** Die Erfassung und Analyse von Metriken kann kostspielig sein.
+*   **Akzeptanz:** Entwickler können Metriken als Bedrohung empfinden, was zu Widerstand führen kann.
+
+**6. Best Practices für die Verwendung von Softwaremetriken**
+
+*   **Definieren Sie klare Ziele:** Was soll mit den Metriken erreicht werden?
+*   **Wählen Sie relevante Metriken:** Welche Metriken sind für die spezifischen Ziele am besten geeignet?
+*   **Automatisieren Sie die Erfassung:** Verwenden Sie Werkzeuge, um Metriken automatisch zu erfassen.
+*   **Analysieren Sie die Daten:** Interpretieren Sie die Metriken im Kontext und identifizieren Sie Trends und Muster.
+*   **Kommunizieren Sie die Ergebnisse:** Teilen Sie die Ergebnisse mit den Stakeholdern und verwenden Sie sie, um Entscheidungen zu treffen.
+*   **Überprüfen und passen Sie die Metriken an:** Stellen Sie sicher, dass die Metriken weiterhin relevant und nützlich sind.
+
+
+
+
+
+
+
+
+**Black-Box-Testing (Funktionstests)**
+
+*   **Konzept:**
+    *   Der Tester betrachtet das System als "Black Box", d.h. er hat keine Kenntnisse über die interne Struktur, den Code oder die Implementierung des Systems.
+    *   Die Testfälle werden ausschließlich auf Basis der Spezifikation, der Anforderungen oder der Dokumentation des Systems entwickelt.
+    *   Das Ziel ist es, die Funktionalität des Systems aus der Sicht des Endbenutzers zu überprüfen.
+*   **Vorteile:**
+    *   **Unabhängigkeit:** Tester benötigt keine Programmierkenntnisse.
+    *   **Benutzerperspektive:** Testfälle spiegeln die tatsächliche Nutzung des Systems wider.
+    *   **Frühe Testphase:** Kann bereits in frühen Phasen des Entwicklungsprozesses durchgeführt werden, sobald die Spezifikationen vorliegen.
+    *   **Objektivität:** Tester ist nicht durch die Implementierung voreingenommen.
+*   **Nachteile:**
+    *   **Begrenzte Abdeckung:** Es ist unmöglich, alle möglichen Eingabekombinationen und Pfade zu testen.
+    *   **Redundanz:** Testfälle können sich überschneiden oder redundante Funktionalität abdecken.
+    *   **Nicht entdeckte Fehler:** Fehler in nicht spezifizierten oder selten genutzten Bereichen können unentdeckt bleiben.
+    *   **Schwierige Testfallerstellung:** Erfordert ein tiefes Verständnis der Spezifikationen und Anforderungen.
+*   **Gängige Techniken:**
+    *   **Äquivalenzklassenbildung:** Aufteilung der Eingabewerte in Äquivalenzklassen, von denen angenommen wird, dass sie sich gleich verhalten.
+    *   **Grenzwertanalyse:** Testen von Werten an den Grenzen der Äquivalenzklassen.
+    *   **Entscheidungstabellentests:** Erstellung von Tabellen, die alle möglichen Kombinationen von Eingabebedingungen und den entsprechenden Ausgaben auflisten.
+    *   **Zustandsübergangstests:** Modellierung des Systems als Zustandsautomat und Testen aller Zustandsübergänge.
+    *   **Use-Case-Tests:** Entwicklung von Testfällen basierend auf den Use Cases des Systems.
+    *   **Zufallstests:** Generierung von zufälligen Eingabewerten und Überprüfung der Ausgaben.
+    *   **Property-based Testing:** Prüfung, ob ein Prädikat erfüllt ist: $\forall x.P(x, f_{SUT}(x))$.
+
+**Glass-Box-Testing (White-Box-Testing, Strukturtests)**
+
+*   **Konzept:**
+    *   Der Tester hat vollen Einblick in die interne Struktur, den Code und die Implementierung des Systems.
+    *   Die Testfälle werden auf Basis des Codes entwickelt, um sicherzustellen, dass alle Teile des Codes ausgeführt werden.
+    *   Das Ziel ist es, die interne Logik des Systems zu überprüfen und Fehler in der Implementierung zu finden.
+*   **Vorteile:**
+    *   **Vollständige Abdeckung:** Kann sicherstellen, dass alle Teile des Codes getestet werden.
+    *   **Effiziente Fehlerfindung:** Kann Fehler in der Implementierung, wie z.B. Logikfehler oder Datenflussfehler, aufdecken.
+    *   **Codeoptimierung:** Kann helfen, ineffizienten oder unnötigen Code zu identifizieren.
+*   **Nachteile:**
+    *   **Hoher Aufwand:** Erfordert detaillierte Kenntnisse des Codes und der Implementierung.
+    *   **Komplexität:** Kann sehr komplex und zeitaufwendig sein, insbesondere bei großen Systemen.
+    *   **Entwicklerperspektive:** Testfälle spiegeln möglicherweise nicht die tatsächliche Nutzung des Systems wider.
+    *   **Nicht entdeckte Spezifikationsfehler:** Kann keine Fehler in den Spezifikationen oder Anforderungen aufdecken.
+*   **Gängige Techniken:**
+    *   **Anweisungsüberdeckung (Statement Coverage):** Sicherstellen, dass jede Anweisung im Code mindestens einmal ausgeführt wird.
+    *   **Zweigüberdeckung (Branch Coverage):** Sicherstellen, dass jeder Zweig (z.B. if-else) im Code mindestens einmal ausgeführt wird.
+    *   **Bedingungsüberdeckung (Condition Coverage):** Sicherstellen, dass jede Bedingung in einem Zweig mindestens einmal true und einmal false ist.
+    *   **Pfadüberdeckung (Path Coverage):** Sicherstellen, dass jeder mögliche Pfad durch den Code mindestens einmal ausgeführt wird.
+    *   **Datenflussanalyse (Data Flow Analysis):** Analyse des Datenflusses durch den Code, um sicherzustellen, dass Variablen korrekt definiert, verwendet und gelöscht werden.
+
+
+
 # Note Notes
 
 **Glass-Box-Test (White-Box-Test) / Strukturtest:**