Softwarequalität 4

Konzepte der Softwarequalität

• Softwaremetriken bewerten quantitativ Aspekte von Softwareprodukten oder -projekten.
• Sie schaffen objektive Grundlagen zur Beurteilung von Codekomplexität, Wartbarkeit und Leistung.
• Die Messung von Softwarequalität unterstützt Entscheidungen in Entwicklung und Wartung.
• Sie hilft, schnell den Zustand eines Projekts zu erfassen.
• Das Messen von Softwarequalität ist wichtig für analytische Qualitätsmaßnahmen.

Lernziele

• Qualitätsmodelle werden verständlich.
• Abstrakte Qualitätsziele können mithilfe konkreter Merkmale und Indikatoren in messbare Größen umgewandelt werden.
• Traditionelle Softwaremetriken wie "Lines of Code" und "zyklomatische Komplexität" werden bekannt, sowie objektorientierte Metriken.
• Ein Einblick in Strukturen und Eigenschaften von Softwaresystemen wird ermöglicht.

Aufgabe von Metriken

• Metriken bieten eine objektive, quantifizierbare Grundlage zur Bewertung verschiedener Aspekte eines Softwareprodukts oder -projekts.
• Sie ermöglichen es, durch einen schnellen Blick auf relevante Zahlen den aktuellen Projektzustand zu erfassen und zu beschreiben.
• Softwaremetriken helfen Teams und Stakeholdern, die Komplexität, Wartbarkeit, Leistung und andere Qualitätsattribute effizient zu messen und zu überwachen.
• Die Identifizierung potenzieller Problembereiche und Risiken wird erleichtert.
• Die Entscheidungsfindung und Prioritätensetzung in der Softwareentwicklung und -wartung wird unterstützt.

Qualitätsanforderungen

• Qualitätsaspekte sind in der Literatur vielfältig zu finden.
• Der englischsprachige Wikipedia-Eintrag zu „Qualitätsattributen“ enthält eine umfangreiche (aber nicht umfassende) Liste mit Qualitätsaspekten: accessibility, accountability, accuracy, adaptability, administrability, afford-ability, agility, auditability, autonomy, availability, compatibility, composability, confidentiality, configurability, correctness, credibility, customizability, debuggability, degradability, determinability, demonstrability, dependability, deployability, discoverability, distributability, durability, effectiveness, efficiency, evolvability, extensibility, failure transparency, fault-tolerance, fidelity, flexibility, inspectability, installability, integrity, interchangeability, interoperability, learnability, localizability, maintainability, manageability, mobility, modifiability, modularity, observability, operability, orthogonality, portability, precision, predictability, process capabilities, producibility, provability, recoverability, redundancy, relevance, reliability, repeatability, reproducibility, resilience, responsiveness, reusability, robustness, safety, scalability, seamlessness, self-sustainability, serviceability, securability, simplicity, stability, standards compliance, survivability, sustainability, tailorability, testability, timeliness, traceability, transparency, ubiquity, understandability, upgradability, usability, vulnerability.
• Der „Qualitätenbaum“ von Boehm zeigt, dass Qualitätsaspekte oft in Gruppen angeordnet sind oder eine Hierarchie bilden.
• "Zuverlässigkeit" setzt sich aus "Genauigkeit", "Konsistenz" und "Vollständigkeit" zusammen.
• Für die Eigenschaften auf der untersten Ebene existiert eine Reihe von Qualitätsmetriken, um den Erfüllungsgrad zu bestimmen.

Begriffsbestimmungen

• Qualitätsaspekt, Qualitätsmerkmal, Qualitätseigenschaft, Qualitätsattribut und Qualitätsziel werden oft synonym verwendet.
• Anforderungen werden unterteilt in "Funktionale Anforderungen", "Qualitätsanforderungen" und "Rahmenbedingungen".
• Funktionale Anforderungen definieren, was das System tun soll.
• Rahmenbedingungen spannen den Rahmen auf, innerhalb dessen das Verhalten erreicht werden muss.
• Qualitätsanforderungen spezifizieren, wie sich dieses Verhalten genau darstellen soll.
• Qualitätsanforderungen sind anteilsmäßig den Funktionalen Anforderungen überlegen und ihr Einfluss auf das Systemverhalten kann nicht überschätzt werden.

Qualitätsmodelle

• Eine Qualitätsanforderung besteht aus einem oder mehreren Qualitätsaspekten, die als Qualitätsziele bezeichnet werden.
• Um das Erreichen dieser Ziele messbar zu machen, werden Qualitätsmetriken herangezogen.
• Anforderungen und deren Beschreibung müssen zusammen mit dem Kunden erarbeitet werden.
• Stakeholder legen die in Abbildung 9 genannten Begriffe oft auf ihre eigene Weise aus.
• Selbst die normierten Qualitätsaspekte sind untereinander verwoben.
• Das Ziel aus Sicht der Softwarequalität ist es, sich schrittweise an messbare Indikatoren heranzuarbeiten.
• Wenn messbare Indikatoren vorliegen ist es möglich die Qualität der Software, den Projektfortschritt und generelle Güte der Entwicklungsprozesse innerhalb eines Unternehmens objektiv zu monitoren.
• Schneider (2012) empfiehlt ein "Qualitätsmodell" zu erstellen, bei welchem vom Abstrakten über das Konkrete bis hin zum Messbaren gearbeitet wird.

Schritte zur Erstellung eines Qualitätsmodells (Schneider)

• Abstrakte Qualitätsziele: Definition der allgemeinsten messbaren Ziele auf höchster Ebene.
• Konkrete Qualitätsmerkmale: Konkretisierung der abstrakten Ziele auf die spezifische Kundensituation und das Projekt.
• Indikatoren und Metriken: Festlegung von Messgrößen und Indikatoren zur Messung der konkreten Merkmale.
• Ziel: Erstellung eines maßgeschneiderten Modells, das das individuelle Verständnis der Kunden zu ihren Qualitätszielen abbildet und als Richtlinie für die Entwicklung und Bewertung dient.

Sprache

• Bei der Erstellung des Qualitätsmodells soll die Sprache der Auftraggeberinnen verwendet werden.
• Durch Abbildung der wichtigsten Qualitätsanforderungen samt individueller Indikatoren kann ist es möglich die Projektabwicklung mit Hilfe von Metriken kontrolliert zu steuern.

Softwaremetriken

• Durch die Ausbuchstabierung eines Qualitätsmodells werden die Ziele greifbar.
• Das Erfassen der Zeit, die benötigt wird, um eine Suche zu starten und die Ergebnisse zu erhalten, dient zum Messen der Laufzeiteffizienz.
• Eine Softwaremetrik wird im Allgemeinen als eine Funktion definiert, die eine Softwarekomponente in einen messbaren Wert überführt.
• Dieser Wert lässt sich als Maß für das Erreichen eines bestimmten Qualitätsziels für die betreffende Softwarekomponente interpretieren.
• Metriken sollen alle relevanten Aspekte der Softwareentwicklung abdecken und neben numerischen Werten auch Zeichen und Symbole als mögliche Ergebnisse berücksichtigen.
• Da die Entwicklung einen beträchtlichen Einfluss auf die Produktqualität hat, müssen auch Metriken zur Messung des Softwareentwicklungsprozesses existieren.

Definition Softwaremetrik (erweitert)

• Eine Funktion, die entweder eine Softwarekomponente oder ihren Entstehungsprozess in einen messbaren Wert oder in Zeichen, eventuell mit einer zugehörigen Maßeinheit, überführt.
• Und anzeigt, inwiefern ein entsprechendes Qualitätsziel erreicht wird.

Klassifizierung von Metriken nach Aspekten

• Produktmaße: Kenngrößen, die sich auf Charakteristika des Softwareprodukts beziehen und Dimensionen erfassen, die eine solche Eigenschaft quantifizieren (z.B. Zuverlässigkeit oder Wartbarkeit).
• Prozessmaße: Metriken, die den Herstellungsprozess der Softwarekomponente ins Visier nehmen und bspw. einem Prozess eine Bewertungszahl zuweisen (CMMI, SPICE).
• Projektmaße: Metriken, die die Entwicklung eines Projekts widerspiegeln, insbesondere im Abgleich mit den Planvorgaben (Aufwand, Kosten).
• Im Berufsalltag genügen wenige, ausgewählte Metriken, wichtiger ist, das Konzept des zielgerichteten Messens zu verstehen.

Klassische Metriken

• Länge des Codes („Lines of Code“)
• Zyklomatische Komplexität (McCabe): Maß für die Schwierigkeit von Code
• Halstead Software Science: Komplettes Set an Metriken und Formeln

Lines of Code (LOC) Metrik

• Die "Lines of Code" (LOC) Metrik (manchmal auch "Source Lines of Code" (SLOC)) misst die Größe eines Softwareprodukts anhand der Anzahl der Zeilen im Quellcode.
• Die "Total Lines of Code" (TLOC) zählt auch Kommentare und Leerzeilen, während sich die SLOC-Messung ausschließlich auf Code-Zeilen fokussiert.
• LOC wird genutzt, um Größe und Komplexität eines Projekts abzuschätzen, die Produktivität zu messen und Kosten zu schätzen.
• Sie kann für Qualitätsbewertungen herangezogen werden, wobei weniger Codezeilen manchmal als geringere Fehleranfälligkeit interpretiert werden.
• Kritiker bemängeln, dass LOC nicht unbedingt die Qualität oder Funktionalität des Codes reflektiert und anfällig für inflationäre Taktiken ist.
• Trotzdem bleibt LOC ein gängiges Werkzeug.

Zyklomatische Komplexität

• Die zyklomatische Komplexität (McCabe, 1976) misst die Komplexität eines Programms anhand der Anzahl der linear unabhängigen Pfade durch den Quellcode.
• Sie hängt direkt mit der Anzahl der Entscheidungspunkte (If-Anweisungen, Schleifen, Fallunterscheidungen) zusammen.
• Eine höhere Anzahl von Entscheidungspunkten bedeutet mehr Pfade und damit mehr Komplexität.
• In der Praxis deutet eine höhere zyklomatische Komplexität oft darauf hin, dass der Code schwieriger zu verstehen, zu testen und zu warten ist.
• Es wird empfohlen, Methoden oder Funktionen mit einer zyklomatischen Komplexität über 10 zu überarbeiten.

Zyklomatische Komplexität - Berechnung

• V(G) = E - N + 2P
• E = Anzahl der Kanten im Graphen
• N = Anzahl der Knoten im Graphen
• P = Anzahl der zusammenhängenden Komponenten
• Die zyklomatische Komplexität ist ein Maß für die Verständlichkeit und Wartbarkeit von Code und gibt Einblick in die strukturelle Komplexität des Programms.

Halstead-Metriken

• Reihe zusammengehöriger Softwaremetriken (Maurice Halstead, 1970er).
• Versuch, die Softwareentwicklung und ihre Komplexität quantitativ zu charakterisieren.
• Halstead-Metriken basieren auf tokenisierten Darstellungen von Software und zielen darauf ab, verschiedene Aspekte der Softwarekomplexität zu messen, indem sie Operatoren und Operanden im Quellcode analysieren.
• In Bezug auf die Halstead-Metriken repräsentieren diese Tokens die Operatoren und Operanden im Code.
• Operatoren sind die Teile des Codes, die Aktionen ausführen, während Operanden die Objekte sind, auf die diese Aktionen angewendet werden. Halsteads Metriken berechnen die Komplexität von Software, indem sie zählen, wie oft verschiedene Operatoren und Operanden im Code vorkommen und wie diese verwendet werden.

Grundlegende Maße

• n1: Anzahl der einzigartigen Operatoren
• n2: Anzahl der einzigartigen Operanden
• N1: Gesamtanzahl der Operatoren
• N2: Gesamtanzahl der Operanden

Abgeleitete Metriken

• Programmlänge: N = N1 + N2
• Programm-Vokabular: n = n1 + n2
• Programm-Umfang: V = N * log2(n)
• Schwierigkeitsgrad: D = (n1/2) * (N2/n2)
• Programmieraufwand: E = D * V
• Zeitaufwand: T = E / 18
• Anzahl der ausgelieferten Bugs: B = V / 3000
• Die Halstead-Metriken sollen Einblicke in die Merkmale der Software geben (Komplexität, Lesbarkeit, Wartbarkeit) und ermöglichen, den Testaufwand oder die Codequalität zu beurteilen.
• Die Halstead-Metriken haben Grenzen und bilden nicht alle Aspekte der Softwarequalität/Komplexität ab.

Objektorientierte Metriken

• Etablierte Metriken (McCabe, Halstead) basieren primär auf imperativer Programmierung
• Sie betrachten Programme als Abfolgen von Befehlen und berücksichtigen die Strukturierung durch Prozeduren/Funktionen.
• Imperative Metriken sind auch auf objektorientierte Sprachen anwendbar, da objektorientierte Ansätze in der Implementierung von Klassen/Methoden dem imperativen Paradigma folgen.
• Die Komplexität objektorientierter Programme lässt sich daher durch klassische Metriken auf Methodenebene zwar erfassen, allerdings nicht vollständig.
• Objektorientierte Metriken erweitern die prozeduralen Metriken, um spezifische Merkmale objektorientierter Programmiersprachen zu berücksichtigen.
• Unterschiedliche Ansätze werden vorgeschlagen, die in Komponenten- und Strukturmetriken unterteilt werden können.

Komponentenmetriken

• Die Bewertung einzelner Bestandteile eines Softwaresystems wird vorgenommen, typischerweise Klassen, in einigen Fällen auch Verbünde von Klassen.
• Komponentenmetriken werden eingesetzt, um Teilkomponenten vergleichend zu analysieren (z.B. beim Refactoring zur Bestimmung der nächsten zu überarbeitenden Klasse).

Gängige Komponentenmetriken (Umfang)

• OV („Objektvariablen“)
• CV ("Klassenvariablen")
• NOA ("Number of Attributes")
• WAC ("Weighted Attributes per Class")
• WMC ("Weighted Methods per Class")
• Diese Kennzahlen eignen sich, um Klassen zu identifizieren, die aufgrund ihrer Größe oder Komplexität ihrer Implementierung hervorstechen.

Vererbungsmetriken

• DOL ("Depth of Inheritance"): Bewertung einer Komponente anhand ihrer Position in der Klassenhierarchie
• NOD ("Number of Descendants"): Anzahl der Unterklassen einer Komponente
• NORM ("Number of Redifined Methods"): Anzahl der reimplementierten Methoden
• Eine gut strukturierte Softwarearchitektur zeichnet sich durch eine ausgewogene Vererbungshierarchie aus.

Kohäsion

• Die Kohäsion wird durch die LCOM-Metrik („Lack of Cohesion in Methods“) bewertet.
• Empirische Studien haben die Bedeutung von Vererbungs-/Umfangsmetriken unterstrichen und die Aussagekraft der Metrik LCOM wurde hinterfragt.

Strukturmetriken

• Strukturmetriken konzentrieren sich auf die übergeordnete Architektur und das Zusammenspiel der verschiedenen Komponenten innerhalb eines Systems.
• Sie sind entscheidend für das Verständnis der Komplexität, Wartbarkeit und Erweiterbarkeit eines Softwaresystems.
• Kopplungsmetriken nehmen eine Schlüsselposition ein, da sie das Zusammenspiel und die Interaktionsmuster zwischen den einzelnen Klassen durchleuchten.

Begriffe

• Fan-In: Anzahl der Klassen, die auf C zugreifen (Fin(C)). Klassen mit hohem Fan-In sind gewöhnlich am unteren Ende der Software-Architektur zu finden.
• Fan-Out: Anzahl der Klassen, auf die C selbst direkt zugreift (Fou(C)). Klassen mit hohem Fan-Out befinden sich üblicherweise am oberen Ende der Software-Architektur.

Exkurs: Struktur und Eigenschaften von Softwaresystemen

• Struktur und Architektur eines Softwaresystems bestimmen die Zusammenwirkung der Teile, um Gesamtfunktionalität zu gewährleisten.
• Eine gute Struktur macht ein System modulierbar, erweiterbar und wartbar, Metriken zielen darauf ab, dies in Zahlen zu fassen.

Komponenten

• Eine Komponente ist ein selbstständiges Modul, das eine Gruppe von verwandten Funktionen oder Daten kapselt.
• Sie hat eine klar definierte Schnittstelle und verborgene Implementierungsdetails.

Eigenschaften

• Austauschbarkeit
• Nicht sichtbarer Zustand
• Wiederverwendbarkeit

Schnittstellen

• Die Schnittstelle einer Komponente definiert, wie andere Teile des Systems mit ihr kommunizieren können, ohne ihr inneres Funktionieren zu kennen.
• Sie beschreibt die Methoden, die andere Komponenten aufrufen können und die Art der Daten, die übermittelt werden können.

Eigenschaften

• Abstraktion
• Konsistenz
• Vertrag

Grundlegende Softwarearchitekturen

• Schichtenarchitektur: Hierarchische Schichten, die spezifische Dienste anbieten.
• Serviceorientierte Architektur (SOA): Dienste werden über ein Netzwerk angeboten und konsumiert.
• Mikroservices: Anwendung als Sammlung kleiner, unabhängiger Dienste.
• Ereignisgesteuerte Architektur: Ereignisse (Events) lösen die Kommunikation zwischen Komponenten aus.

Designprinzipien

• Hohe Kohäsion und lose Kopplung
• Offenes/Geschlossenes Prinzip
• Prinzip der Trennung von Interessen

Dieser Test untersucht die Rolle von Softwaremetriken bei der Bewertung der Softwarequalität und Entscheidungsfindung. Er behandelt die Umwandlung von Qualitätszielen in messbare Größen und die Bedeutung verschiedener Metriken für die Risikobewertung und Komponentenanalyse. Es werden auch traditionelle und objektorientierte Metriken behandelt.