Software-Qualität
Dr. Thorsten Arendt
Marburg, 26. November 2015
Überblick
• Wie definiert man gute Software?
– Welche Qualitätskriterien gibt es für Software?
– Welche Qualitätsanforderungen leiten sich daraus ab?
• Wie erreicht man gute Software?
– Auf welche Weise kann Qualitätsmanagement durchgeführt
werden?
• Welche Techniken zur Verbesserung der Softwarequalität
gibt es?
– konstruktive Qualitätssicherungsmaßnahmen
– analytische Qualitätssicherungsmaßnahmen
2 Software-Evolution WS 2015/2016
3 Software-Evolution WS 2015/2016
4 Software-Evolution WS 2015/2016
5 Software-Evolution WS 2015/2016
Probleme der Software-Erstellung
6 Software-Evolution WS 2015/2016
• Nach Untersuchungen von Standish Group, Gartner Group, Cutter
Consortium und Center for Project Management:
– ca. 23% aller Softwareprojekte erfolgreich,
– ca. 53% über Budget und/oder über Zeit und
– ca. 24% abgebrochen
• In besonderem Maße geprägt
von Fehleinschätzungen:
Zeit für
Organisation,
Kommunikation,
Programmierung
• Ein Programmierer produziert
im längerfristigen Durchschnitt
10 LOC pro Arbeitstag. [Mayr]
Qualitätsmerkmale für Software nach ISO 9126
7 Software-Evolution WS 2015/2016
• Funktionalität: Korrektheit,
Angemessenheit, Interoperabilität,
Ordnungsmäßigkeit, Sicherheit
• Zuverlässigkeit: Reife, Fehlertoleranz,
Wiederherstellbarkeit
• Benutzbarkeit: Verständlichkeit,
Bedienbarkeit, Erlernbarkeit, Robustheit
• Effizienz: Wirtschaftlichkeit,
Zeitverhalten, Verbrauchsverhalten
• Wartungsfreundlichkeit:
Analysierbarkeit, Änderbarkeit, Stabilität,
Testbarkeit
• Übertragbarkeit: Anpassbarkeit,
Installierbarkeit, Konformität,
Austauschbarkeit
Qualitätsmerkmale des Nachfolgers ISO 25010
Software-Evolution WS 2015/20168
Qualitätsmanagement
• Produktorientiert:
Softwareprodukte und Zwischenergebnisse werden
auf vorher festgelegte Qualitätsmerkmale überprüft.
• Prozessorientiert:
Methoden, Werkzeuge, Richtlinien und Standards
für den Erstellungsprozess der Software
9 Software-Evolution WS 2015/2016
Konstruktive Qualitätssicherungsmaßnahmen
• Methoden, Sprachen, Werkzeuge, Richtlinien,
Standards und Checklisten, deren Anwendung eine
bestimmte Produkt- oder Prozessqualität garantieren
• Beispiele:
– Gliederungsschema für die Anforderungsspezifikation
– Verwendung einer typisierten Programmiersprache
– Importierte Daten werden auf Richtigkeit überprüft.
– OO-Softwareentwicklung unterstützt die
Wiederverwendbarkeit von Software.
– Programmierkonventionen
10 Software-Evolution WS 2015/2016
Analytische Qualitätssicherungsmaßnahmen
• Das existierende Qualitätsniveau wird gemessen.
• Ausmaß und Ort des Defekts können identifiziert
werden.
• Verfahren:
– Analysierend: Informationen ohne Ausführung der
Software mit konkreten Eingaben sammeln.
– Testend: Die Software mit konkreten Eingaben
ausführen.
11 Software-Evolution WS 2015/2016
Beispiele für konstruktive und analytische
Qualitätssicherungsmaßnahmen
12 Software-Evolution WS 2015/2016
• Konstruktive Maßnahme: Angemessene
Modularisierung des Software-Systems
• Analytische Maßnahme: Metriken zur Bestimmung
von Kopplung und Kohäsion
• Konstruktive Maßnahme: Verwendung eines guten
Programmierstils
• Analytische Maßnahmen: Objektorientierte Metriken
und Überprüfung auf Bad Code Smells
Verfahren zur Qualitätsmessung
• Quantitative Messungen:
– Softwaremetriken, Profiling
• Überprüfung syntaktischer Muster:
– Entwicklungsrichtlinien
– Bad Code Smells
– Entwurfsmuster und Softwarearchitekturen
• Überprüfung semantischer Eigenschaften:
– Testverfahren
– Design-By-Contract
– Verifikation
13 Software-Evolution WS 2015/2016
Was sind Software-Metriken?
14 Software-Evolution WS 2015/2016
• Was kann das Messen bringen?
• Wer möchte messen?
• Was kann man messen?
• Wie muss man messen?
• Welche Verfahren gibt es?
„Softwaremetriken definieren, wie Kenngrößen der
Software oder des Softwareentwicklungsprozesses
gemessen werden.“
Wichtige Fragen:
„Softwaremetriken messen Qualität.“ besser:
Beispiele für „konventionelle“ Metriken
• Wie kann man die Produktivität eines Entwicklers
messen?
– Anzahl von Codezeilen pro Zeiteinheit
• Probleme: Exaktheit, Vergleichbarkeit, Normierung, …
– Funktionspunktanalyse: Anzahl der Funktionspunkte (kleinste, für
die Anwender sinnvolle Aktivität) pro Zeiteinheit
• Problem: Hoher Messaufwand
• Wie kann die Komplexität einer Programmstruktur
gemessen werden?
– Halstead – Umfang von Ausdrücken (im Programm) [Halstead]
– McCabe – Anzahl der binären Verzweigungen plus 1 [McCabe]
– Je höher die Metrikenwerte, desto komplexer und fehleranfälliger
das Programm.
15 Software-Evolution WS 2015/2016
Objektorientierte Softwaremetriken [CK]
• Strukturiere Software so, dass sie leicht änderbar ist.
• Abhängigkeiten zwischen Klassen und zwischen
Paketen sollten minimiert werden.
• Ein Prinzip des objektorientierten Designs ist die
Kapselung von Daten und Verhalten in Klassen.
– D.h. Methoden sollten so nah wie möglich an die von ihnen
manipulierten Daten rücken.
• Klassen sollten offen für Erweiterungen sein, aber
geschlossen für Veränderungen.
– Erweiterung durch Vererbung
• OO-Metriken können Auffälligkeiten im Design zeigen.
16 Software-Evolution WS 2015/2016
Beispiele für Objektorientierte Softwaremetriken
• DIT – Depth of Inheritance Tree
– Anzahl der Oberklassen: Je mehr, desto fehleranfälliger
• NOC – Number Of Children
– Anzahl der direkten Unterklassen: Je mehr, desto besser der Code
(hohe Wiederverwendung)
• WMC – Weighted Method per Class
– Summe der Komplexitäten aller Methoden einer Klasse: Je höher,
desto fehleranfälliger
• CBC – Coupling Between Classes
– Afferent Coupling: Anzahl der Klassen anderer Pakete, die von
Klassen in diesem abhängig sind
– Efferent Coupling: Anzahl der Klassen anderer Pakete, von denen
Klassen dieses Pakets abhängig sind
– Anzahl der benutzten Klassen: Je mehr, desto fehleranfälliger
17 Software-Evolution WS 2015/2016
Was sind Entwicklungsrichtlinien?
• Konstruktive Qualitätssicherungsmaßnahmen
• Für alle Phasen des SW-Entwicklungsprozesses nötig
– bessere Lesbarkeit des Dokuments (z.B. des Modells, des Codes)
– bessere Wartbarkeit
– Unternehmenspolitik
• Standards für Anforderungsspezifikationen
– korrekte und vollständige Erfassung von Anforderungen
• Modellierungsrichtlinien kaum vorhanden
• Programmierrichtlinien (inkl. Namensgebung)
– z.B. Programmierrichtlinien für Java:
http://www.oracle.com/technetwork/java/javase/documentation/code
convtoc-136057.html
• Richtlinien für GUIs
– bessere Benutzbarkeit und stärkere Standardisierung
18 Software-Evolution WS 2015/2016
http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html
Beispiel: Java-Namenskonventionen
• Klassennamen:
– Substantive in gemischter Groß-/Kleinschreibung mit dem ersten
Buchstaben jedes internen und des ersten Wortes großgeschrieben
– Klassennamen sollten einfach und beschreibend sein.
– Ganze Wörter verwenden, keine Abkürzungen, außer
gebräuchliche, nur der erste Buchstabe großgeschrieben, wie „Html“
oder „Uml“
– Schnittstellenkonvention: „I“ als Präfix, z.B. „IWorkspace“
• Methodennamen:
– Verben in gemischter Groß-/Kleinschreibung mit dem ersten
Buchstaben jedes internen Wortes großgeschrieben
– besondere Konventionen für:
• Getter-Methoden: z.B. „getX()“
• Setter-Methoden: z.B. „setX()“
• Prädikate beginnen mit „is“: z.B. „isEmpty()“
19 Software-Evolution WS 2015/2016
Was sind Bad Smells? [Fowler]
• Anrüchige (verdächtige) Modell- bzw. Code-Stellen
– Hier lohnt es sich, genauer hinzuschauen und eventuell zu
verbessern.
• Bad Smells sind Kondensierung von Erfahrungswissen.
– syntaktische Prüfung von Modell bzw. Programmcode hinsichtlich
bestimmter Muster
• Beispiele für Bad Smells:
– doppelter Code
– lange Methoden
– große Klassen
• Code-Smell-Kataloge:
– http://c
