Software-Qualität - Philipps-Universität Marburg · Überblick •Wie definiert man gute...

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

Probleme der Software-Erstellung


• 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ägtvon Fehleinschätzungen:Zeit für

Organisation,

Kommunikation,

Programmierung

• Ein Programmierer produziertim längerfristigen Durchschnitt10 LOC pro Arbeitstag. [Mayr]

Qualitätsmerkmale für Software nach ISO 9126


• 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


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


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.


Beispiele für konstruktive und analytische

Qualitätssicherungsmaßnahmen


• 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


Was sind Software-Metriken?


• 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.


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.


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


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/codeconvtoc-136057.html

• Richtlinien für GUIs

– bessere Benutzbarkeit und stärkere Standardisierung


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()“


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://c2.com/cgi/wiki?CodeSmell

– https://en.wikipedia.org/wiki/Code_smell


http://c2.com/cgi/wiki?CodeSmell

https://en.wikipedia.org/wiki/Code_smell

Beispiel-Smell:

Große Klasse


• Eine Klasse hat zu viele Attributeund/oder zu vieleMethoden.

• Primitive Obsession: zu viele Attribute mit primitivem Datentyp

Beispiel-Smell: Konkrete Klasse als Oberklasse

Eine abstrakte Klasse hat eine konkrete Klasse als Oberklasse.


Beispiel-Smell: Redundante Attribute

Mehrere Klassen haben mehrere gleiche Attribute.


Was ist Refactoring? [Fowler]

• Eine Technik im Rahmen der agilen Softwareentwicklung

• Restrukturierung der Software nach jedem Iterations-

schritt

• Refactoring-Katalog:– http://refactoring.com/catalog/


http://refactoring.com/catalog/

Beispiel-Refactoring: Extract Class

Erzeuge eine neue Klasse und verschiebe alle relevanten

Attribute und Methoden in diese Klasse.


Beispiel-Refactoring: Pull Up Attribute

Wenn alle Unterklassen dasselbe Attribut bzgl. Name, Typ und

Multiplizität haben, verschiebe dieses Attribut in die gemeinsame

Oberklasse.


Beispiel-Refactoring: Replace Type Code with

Class

Eine Klasse enthält mehrere Konstanten, die ihr Verhalten nicht

beeinflusst. Verschiebe diese Konstanten in eine separate

Aufzählungsklasse.


Beispiel-Refactoring: Replace Type Code with

Subclasses

Die Klasse enthält mehrere Konstanten, die Typen kodieren. Diese

Typen haben Auswirkungen auf das Verhalten der Klasse.

Ersetze diese Konstanten durch Unterklassen.


Strukturelle Erosion


• Sich weiterentwickelnde Software ist zunehmend schwieriger zu

testen, schwieriger zu verstehen, schwieriger zu pflegen und

schwieriger zu erweitern.

• ‚The software starts to rot like a piece of bad meat.‘

(Robert C. Martin)

• Dies wird ‚strukturelle Erosion‘ genannt.

• Strukturelle Erosion tritt in fast allen nicht-trivialen

Softwareprojekten auf.

• Folgen struktureller Erosion:

– Änderungen haben Auswirkungen auf die vorhandene Funktionalität.

– Die Produktivität sinkt signifikant.

– Kosten für Änderungen steigen kontinuierlich.

Symptome für strukturelle Erosion


• Rigidität:

– Das System ist schwierig zu ändern, da jede Änderung zu vielen

weiteren Änderungen führt.

• Fragilität:

– Änderungen führen zu Fehlern in konzeptionell nicht

zusammengehörigen Komponenten.

• Immobilität:

– Es ist schwierig, das System in wiederbenutzbare Komponenten

aufzuteilen.

• Viskosität:

– Es ist schwieriger, Dinge richtig zu tun als Dinge nicht richtig zu tun.

• Opakheit:

– Der Code ist schwierig zu lesen und zu verstehen, weil er seinem

Zweck nicht gerecht wird.

Dependency Management


• Das allgemeine Design einer Software wird durch die

Struktur ihrer Abhängigkeiten beschrieben.

• Ein explizites Management dieser Abhängigkeiten kann

dabei helfen, strukturelle Erosion zu vermeiden.

• Konkrete Maßnahmen:

– Vermeidung zyklischer Abhängigkeiten zwischen

Komponenten der Software.

– Minimierung der Kopplung zwischen unterschiedlichen

Teilen der Software.

Zyklische Abhängigkeiten zwischen

Komponenten


• Zuordnung zu verschiedenen

Levels/Ebenen nicht möglich

• Negative Auswirkungen auf die

Bereiche

– Verständlichkeit

– Testbarkeit

– Wiederverwendbarkeit

– Fehlerbehebung

• Erschwerte Analyse von

Änderungsauswirkungen

Azyklische, gerichtete Abhängigkeitsgraphen


• Zuordnung zu verschiedenen

Levels/Ebenen möglich

• Positive Auswirkungen auf die

Bereiche

– Verständlichkeit

– Testbarkeit

– Wiederverwendbarkeit

– Fehlerbehebung

• Einfache Analyse von

Änderungsauswirkungen

Kopplung zwischen Software-Komponenten


• Je mehr andere Komponenten von einer Komponente K benutzt

werden, desto fehleranfälliger ist K

• Eine geringere Kopplung führt zu

– höherer Flexibilität sowie

– verbesserter Testbarkeit, Wartbarkeit und Verständlichkeit.

• Bei Änderungen sind nur kleinere Teile des Systems betroffen falls

die Kopplung geringer ist

• Um die Kopplung von Komponenten zu überwachen, können

verschiedene Kopplungsmetriken verwendet werden, z.B.

– Average Component Dependency (ACD)

– Normalized Cumulative Component Dependency (NCCD)

Beispiele für Kopplungsmetriken


Metrik Beschreibung Graph 1 Graph 2

CD Component Dependency Werte innerhalb der Knoten

CCD Cumulative Component Dependency 23 19

ACD Average Component Dependency 3.29 2.71

NCCD Normalized Cumulative Component Dependency 1.35 1.12

Refactoring zum Auflösen von zyklischen

Abhängigkeiten (1)


Durch das Einfügen einer Schnittstelle wird die Richtung der

Abhängigkeit umgekehrt und somit der Zyklus aufgelöst

(dependency inversion principle).

Refactoring zum Auflösen von zyklischen

Abhängigkeiten (2)


Auflösen einer zyklischen Abhängigkeit durch Umverteilen von

Klassen-Features (Felder und/oder Methoden).

Zusammenfassung


Zusammenfassung

• Softwarequalität hat viele verschiedene Aspekte.

• Es werden prozess- und produktbezogene Qualität und Qualitätssicherung unterschieden.

• Produktbezogen: Es werden konstruktive und analytischeVerfahren zur Qualitätssicherung unterschieden.

– z.B.: Metriken, Entwicklungsrichtlinien, Bad Code Smells, Refactorings, Design Patterns, automatisierte Tests, Verifikationen

• Zyklische Abhängigkeiten begünstigen Software-Erosion

• Unterstützende Werkzeuge (als Eclipse-Plugins):– Metriken, Konventionen, Smells: z.B. Metrics2, Checkstyle, PMD, EMF

Refactor, Sonargraph

– Refactoring: z.B. EMF Refactor, Eclipse-Refactoring, Sonargraph


Sekundär-Literatur und Werkzeuge (1)


• ISO/IEC 25010:2011 -

http://www.iso.org/iso/home/store/catalogue_ics/catalogue_det

ail_ics.htm?csnumber=35733

• Maurice H. Halstead. Elements of Software Science (Operating

and Programming Systems Series). Elsevier Science Inc., New

York, NY, USA, 1977.

• T.J. McCabe. A Complexity Measure. Software Engineering,

IEEE Transactions on, SE-2(4):308–320, Dec 1976.

• S.R. Chidamber and C.F. Kemerer. A Metrics Suite for Object

Oriented Design. IEEE Transactions on Software Engineering,

20(6):476–493, 1994.

• Martin Fowler. Refactoring: Improving the Design of Existing

Code. Addison-Wesley Professional, 1999.

http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=35733

Sekundär-Literatur und Werkzeuge (2)


• Alexander von Zitzewitz. Designing Quality Software -

Architectural and Technical Best Practices. RefCard#130.

https://dzone.com/refcardz/designing-quality-software

• Robert Cecil Martin. Agile Software Development, Principles,

Patterns, and Practices. Prentice Hall, 2003.

• John Lakos. Large-Scale C++ Software Design. Addison-

Wesley, 1996.

• Checkstyle: http://eclipse-cs.sourceforge.net/

• PMD: https://pmd.github.io/

• Sonargraph:

https://www.hello2morrow.com/products/sonargraph

https://dzone.com/refcardz/designing-quality-software

http://eclipse-cs.sourceforge.net/

https://pmd.github.io/

https://www.hello2morrow.com/products/sonargraph

Software-Qualität - Philipps-Universität Marburg · Überblick •Wie definiert man gute...

Documents

Transcript of Software-Qualität - Philipps-Universität Marburg · Überblick •Wie definiert man gute...