Softwarequalität 20. Januar 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 Taentzer Einführung in die Softwaretechnik 357
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] Taentzer Einführung in die Softwaretechnik 359
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 reengineering of established applications. [Gartner] Softwareentwickler im Projekt wechseln mit der Zeit und neue Entwickler müssen sich in bestehende Software einarbeiten. Taentzer Einführung in die Softwaretechnik 360
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 Taentzer Einführung in die Softwaretechnik 361
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 Taentzer Einführung in die Softwaretechnik 362
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? Taentzer Einführung in die Softwaretechnik 363
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 Taentzer Einführung in die Softwaretechnik 364
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. Taentzer Einführung in die Softwaretechnik 365
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 Taentzer Einführung in die Softwaretechnik 366
Was sind Softwaremetriken? Softwaremetriken messen Qualität. besser: Softwaremetriken definieren, wie Kenngrößen der Software oder des Softwareentwicklungsprozesses gemessen werden. Wichtige Fragen: Was kann das Messen bringen? Wer möchte messen? Was kann man messen? Wie muss man messen? Welche Verfahren gibt es? Taentzer Einführung in die Softwaretechnik 367
Szenario: Messen von Produktivität Wie kann man die Produktivität eines Entwicklers testen? 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 / day Was wird hier gemessen? Probleme: Wie ist die Anzahl von Codezeilen definiert? Exaktheit? Dieses Maß ist sprachabhängig. Vergleichbarkeit? Entwickler haben eigene Programmierstile. Normierung? Taentzer Einführung in die Softwaretechnik 368
Szenario: Messen von Produktivität (2) Funktionspunktanalyse: Funktionspunkt: kleinste, für die Anwender sinnvolle Aktivität Anzahl der Funktionspunkte pro Zeiteinheit Kategorien: Ein- /Ausgabedaten, 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ängig Nachteile: stärkerer Messaufwand (Dokumentation) Taentzer Einführung in die Softwaretechnik 369
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 log 2 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. Taentzer Einführung in die Softwaretechnik 370
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. Taentzer Einführung in die Softwaretechnik 371
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 Taentzer Einführung in die Softwaretechnik 372
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 www.oracle.com/technetwork/java/javase/documentation/ codeconvtoc-136057.html Richtlinien für GUIs bessere Benutzbarkeit und stärkere Standardisierung Taentzer Einführung in die Softwaretechnik 373
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() Taentzer Einführung in die Softwaretechnik 374
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 Taentzer Einführung in die Softwaretechnik 375
Beispiel- Smell: Große Klasse Eine Klasse hat zu viele Attribute (mit primitivem Datentyp, Primitive Obsession) und/oder zu Methoden. Taentzer Einführung in die Softwaretechnik 376
Beispiel-Smell: Konkrete Klasse als Oberklasse Smell: Eine abstrakte Klasse hat eine konkrete Klasse als Oberklasse. Taentzer Einführung in die Softwaretechnik 377
Beispiel-Smell: Redundante Attribute Smell: Mehrere Klassen haben mehrere gleiche Attribute. Taentzer Einführung in die Softwaretechnik 378
Was ist Refactoring? [Fowler] Eine Technik im Rahmen der agilen Softwareentwicklung Restrukturierung der Software nach jedem Iterationsschritt 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/ Taentzer Einführung in die Softwaretechnik 379
Refactoring-Beispiel: Extract Class refactoring.com Refactoring Extract Class : Erzeuge eine neue Klasse und verschiebe alle relevanten Attribute und Methoden in diese Klasse. Taentzer Einführung in die Softwaretechnik 380
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. Taentzer Einführung in die Softwaretechnik 381
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. Taentzer Einführung in die Softwaretechnik 382
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. Taentzer Einführung in die Softwaretechnik 383
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 Taentzer Einführung in die Softwaretechnik 384
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 durchgefü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 Taentzer Einführung in die Softwaretechnik 385
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 Taentzer Einführung in die Softwaretechnik 386
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. Taentzer Einführung in die Softwaretechnik 387
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 Taentzer Einführung in die Softwaretechnik 388