Softwarequalität - Philipps-Universität Marburg · Strukturiere Software so, dass sie leicht...

Softwarequalität

20. Januar 2015

Taentzer Einführung in die Softwaretechnik 357

Ü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

Taentzer Softwarequalität 2013 358


Probleme der Software-Erstellung

Nach Untersuchungen von Standish Group, Gartner Group, Cutter Consortium und Center for Project Management: 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]

Warum ist gut strukturierte und gut lesbare Software wichtig?

Softwaresysteme werden immer komplexer und müssen gewartet werden.

Der Evolutionsanteil an der Softwareentwicklung wird immer höher. „Faktor 2 bis 100 je nach Anwendung“ [Sommerville] „1976 – 1998: Wartungskosten mehr als 67%“ [Schach] „Through 2008, at least 65 percent of custom-developed services

for new SOA projects will be implemented via wrapping or re-engineering of established applications.“ [Gartner]

Softwareentwickler im Projekt wechseln mit der Zeit und neue Entwickler müssen sich in bestehende Software einarbeiten.



Qualitätsmerkmale für Software 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ätsmanagment

Produktorientiert:Softwareprodukte und Zwischenergebnisse werden auf vorher festgelegte Qualitätsmerkmale überprüft.

Prozessorientiert: Methoden, Werkzeuge, Richtlinien und Standards für den Erstellungsprozess der Software


Prinzipien der SW-Qualitätssicherung

Produkt- und prozeßabhängige Qualitätszielbestimmung Welche Qualitätskriterien haben Priorität?

Frühzeitige Fehlerentdeckung und –behebung präzise Anforderungserhebung, Spezifikation

Maximal konstruktive Qualitätssicherung Quantitative Qualitätssicherung

repräsentative Maßzahlen Entwicklungsbegleitende, integrierte Qualitätssicherung Unabhängige Qualitätssicherung

Welche QS-Maßnahmen sollten nicht vom Entwickler durchgeführt werden?


Qualitätssicherungmaßnahmen

Konstruktive Maßnahmen: Methoden, Sprachen, Werkzeuge, Richtlinien, Standards und Checklisten, die 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


Qualitätssicherungsmaßnahmen

Analytische Maß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.

Eine vorausschauende, konstruktive Qualitätslenkung erspart viele analytische Maßnahmen.


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 Softwaremetriken?

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 oderdes Softwareentwicklungsprozesses gemessen werden.“

Wichtige Fragen:

„Softwaremetriken messen Qualität.“ besser:


Szenario: Messen von Produktivität

Anzahl von Codezeilen pro Zeiteinheit:

Fred schreibt in 100 Tagen 5000 Zeilen Code.

P = 50 LOC / day Fred verdoppelt sein

Programm, ohne Funktionalitätsänderung.

P = 100 LOC / dayWas wird hier gemessen?

Probleme: Wie ist die Anzahl von

Codezeilen definiert? Exaktheit? Dieses Maß ist sprachabhängig. Vergleichbarkeit? Entwickler haben eigene

Programmierstile. Normierung? …

Wie kann man die Produktivität eines Entwicklers testen?


Szenario: Messen von Produktivität (2)

Funktionspunkt: kleinste, für die Anwender sinnvolle Aktivität

Anzahl der Funktionspunkte pro Zeiteinheit

Kategorien: Ein- /Aus-gabedaten, Abfragen, Datenbestände, Referenzdateien

Klassifikation: einfach, mittel, komplex

Einflussfaktoren:Kommunikation, Verarbeitungslogik,…

Vorteile: misst den Wert des Outputs frühzeitig einsetzbar kann den Umfang von SW-

Projekten messen kann Fortschritt messen technologieunabhängigNachteile: stärkerer Messaufwand

(Dokumentation)

Funktionspunktanalyse:


Weitere konventionelle Metriken Halstead - Umfang von Ausdrücken (im Programm) [Halstead]

Anzahl u1 und u2 der unterschiedlichen Operatoren und Operanden Anzahl i1 und i2 der insgesamt existierenden Operatoren u. Operanden Programmvokabular: u = u1 + u2 Programmlänge: i = i1 + i2 Programmvolumen: V = i ∙ log2 u Programmverstehen: D = u1 2 ∙i2 u2 Aufwand für Programmänderungen: E = D ∙V Komplexe Strukturen werden nicht berücksichtigt.

McCabe – Komplexität von Programmstrukturen [McCabe] Anzahl der binären Verzweigungen plus 1 McCabe ist nicht uneingeschränkt für OO-Programme einsetzbar. Warum?

Je höher die Metrikwerte, desto komplexer und fehleranfälliger das Programm.

Objektorientierte SW-Metriken [CK]

Strukturiere Software so, dass sie leicht änderbar ist. Abhängigkeiten zwischen Klassen und 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 aufdecken.



Objektorientierte SW-Metriken 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 Couplings: Anzahl der Klassen anderer Pakete, die von Klassen in diesem abhängig sind

Efferent Couplings: 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 Javawww.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html

Richtlinien für GUIs bessere Benutzbarkeit und stärkere Standardisierung


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 Buchtstabe großgeschrieben, wie Html oder Uml Schnittstellenkonvention: „I“ als Präfix, z.B. „IWorkspace“ oder

„IIndex“ 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: c2.com/cgi/wiki?CodeSmell de.wikipedia.org/wiki/Smell_%28Programmierung%29


Beispiel-Smell:Große Klasse

Eine Klasse hat zu viele Attribute (mit primitivem Datentyp, Primitive Obsession) und/oder zu Methoden.

Beispiel-Smell: Konkrete Klasse als Oberklasse


Smell: Eine abstrakte Klasse hat eine konkrete Klasse als Oberklasse.

Beispiel-Smell: Redundante Attribute


Smell: 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 ist der Prozess, ein Softwaresystem so zu

verändern, dass das externe Verhalten unverändert bleibt, der Code aber eine bessere Struktur erhält.“ (Martin Fowler)

Refactoring-Katalog: refactoring.com/catalog/

Refactoring-Beispiel: Extract Class


refactoring.com

Refactoring „Extract Class“: Erzeuge eine neue Klasse und verschiebe allerelevanten Attribute und Methoden in diese Klasse.

Refactoring-Beispiel: Pull Up Attribute


refactoring.com

Refactoring „Pull Up Attribute“: Wenn alle Unterklassen dasselbe Attribut bzgl. Name, Typ und Multiplizität haben, verschiebe dieses Attribut in die gemeinsame Oberklasse.

Refactoring-Beispiel: Replace Type Code with Class


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.

Refactoring-Beispiel: Replace Type Code with Subclasses


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.


Refactoring-Beispiel: Große Klasse

Vorher: Klassenstruktur auf Folie 376

Beispiele für Refactorings:- Extract Class- Rename Method- Encapsulate Field- Replace Type Code

with Class


Wann und wie führt man Refactorings durch?

Wann führt man Refactorings durch? nach einem Iterationsschritt auf funktionsfähigem Code

Wie findet man die Stellen, an denen Refactorings durch-geführt werden sollten? Bad Smells: Anzeichen auf schlechte Programmstruktur

Wie führt man Refactorings durch? erfolgreiche Durchführung von Tests für ein Modul Auffinden von Bad Smells in diesem Modul Umstrukturierung des Codes erneute Durchführung von Tests, die erfolgreich sein müssen


Zusammenfassung

Softwarequalität hat viele verschiedene Aspekte. Es werden prozess- und produktbezogene Qualität und

Qualitätssicherung unterschieden. Prozessbezogen: Definition des Qualitätssicherungsmanagements

durch ISO 9000 Standard. Produktbezogen: Es werden konstruktive und analytische Verfahren

zur Qualitätssicherung unterschieden. z.B.: Metriken, Entwicklungsrichtlinien, Bad Code Smells, Refactorings,

Design Patterns, automatisierte Tests, Verifikationen Unterstützende Werkzeuge (als Eclipse-Plugins):

Metriken, Konventionen, Smells: z.B.: Metrics, Checkstyle, PMD, EMF Refactor

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

Literatur

[CK] Chidamber, S. R. and Kemerer, C. F.: A Metrics Suite for Object Oriented Design, IEEE Transactions on Software Engineering, vol. 20, 1994.

[Fowler] M. Fowler: Refactoring: Improving the Design of Existing Code, Addison Wesley, 1999

[Gartner] Gartner Group, Service-Oriented Architecture Scenario, https://www.gartner.com/doc/391595

[Halstead] Maurice H. Halstead: Elements of Software Science. Elsevier (1977).

[McCabe] Thomas J. McCabe: A Complexity Measure. in: IEEE Transactions on Software Engineering, Band SE-2, 308-320. 1976.


Literatur

[Mayr] H. Mayr: Projekt Engineering: Ingenieursmäßige Softwareentwicklung in Projektgruppen, Fachbuchverlag Leipzig, ISBN 344640070, 2005

[Schach] S.R. Schach et al.: Determining the distribution of maintenance categories: Survey versus measurement. Empirical Software Engineering 8: 351-66, 2003

[Sommerville] I. Sommerville: Software Engineering. 6th Edition, Addison-Wesley, 2001


Softwarequalität - Philipps-Universität Marburg · Strukturiere Software so, dass sie leicht...

Documents

Transcript of Softwarequalität - Philipps-Universität Marburg · Strukturiere Software so, dass sie leicht...