software-qualität - philipps-universität marburg · Überblick •wie definiert man gute...
Post on 09-Sep-2019
1 Views
Preview:
TRANSCRIPT
Ü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
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ä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
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ä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/codeconvtoc-136057.html
• Richtlinien für GUIs
– bessere Benutzbarkeit und stärkere Standardisierung
18 Software-Evolution WS 2015/2016
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://c2.com/cgi/wiki?CodeSmell
– https://en.wikipedia.org/wiki/Code_smell
20 Software-Evolution WS 2015/2016
Beispiel-Smell:
Große Klasse
21 Software-Evolution WS 2015/2016
• 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.
22 Software-Evolution WS 2015/2016
Beispiel-Smell: Redundante Attribute
Mehrere Klassen haben mehrere gleiche Attribute.
23 Software-Evolution WS 2015/2016
Was ist Refactoring? [Fowler]
• Eine Technik im Rahmen der agilen Softwareentwicklung
• Restrukturierung der Software nach jedem Iterations-
schritt
• Refactoring-Katalog:– http://refactoring.com/catalog/
24 Software-Evolution WS 2015/2016
Beispiel-Refactoring: Extract Class
Erzeuge eine neue Klasse und verschiebe alle relevanten
Attribute und Methoden in diese Klasse.
25 Software-Evolution WS 2015/2016
Beispiel-Refactoring: Pull Up Attribute
Wenn alle Unterklassen dasselbe Attribut bzgl. Name, Typ und
Multiplizität haben, verschiebe dieses Attribut in die gemeinsame
Oberklasse.
26 Software-Evolution WS 2015/2016
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.
27 Software-Evolution WS 2015/2016
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.
28 Software-Evolution WS 2015/2016
Strukturelle Erosion
29 Software-Evolution WS 2015/2016
• 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
30 Software-Evolution WS 2015/2016
• 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
31 Software-Evolution WS 2015/2016
• 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
32 Software-Evolution WS 2015/2016
• 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
33 Software-Evolution WS 2015/2016
• 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
34 Software-Evolution WS 2015/2016
• 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
35 Software-Evolution WS 2015/2016
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)
36 Software-Evolution WS 2015/2016
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)
37 Software-Evolution WS 2015/2016
Auflösen einer zyklischen Abhängigkeit durch Umverteilen von
Klassen-Features (Felder und/oder Methoden).
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
39 Software-Evolution WS 2015/2016
Sekundär-Literatur und Werkzeuge (1)
40 Software-Evolution WS 2015/2016
• 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.
Sekundär-Literatur und Werkzeuge (2)
41 Software-Evolution WS 2015/2016
• 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
top related