Interne Softwarequalität sichtbar gemacht

Transkript

1 Ines Moosdorf Interne Softwarequalität sichtbar gemacht Seminar Beiträge zum Software Engineering

2 Agenda Einleitende Worte zu interner Softwarequalität Paper 1: Monitoring Code Quality and Development Activity by Software Maps Paper 2: A Practical Model for Measuring Maintainability Zusammenfassung, Bewertung & Fazit 2

3 Interne Softwarequalität Softwarequalität: Gute Softwarequalität ist eines der grundsätzlichen Ziele im Software Engineering Kompleer, breitgefächerter Begriff Interne Softwarequalität Wie gut ist das System gebaut? Eterne Softwarequalität Wie verhält sich das System hinsichtlich der Erwartungen? Bedeutung interner Softwarequalität beeinflusst Interne Qualität Abhängig von Eterne Qualität 3

4 Messen interner Softwarequalität Metriken sollten zielgerichtet, für einen spezifisches Kontet unter bestimmten Annahmen gewählt werden Beispiel für das Messen von interner Qualität Größe Lines of Code (LOC) Function Points (FP) Kompleität Selbst wieder ein facettenreicher Begriff McCabe zyklomatische Kompleität Verschachtelungstiefe Modultestabdeckung Kopplung... 4

5 Zyklomatische Kompleität nach McCabe 5

6 Zyklomatische Kompleität nach McCabe 6

7 Messen interner Softwarequalität Metriken sollten zielgerichtet, für einen spezifisches Kontet unter bestimmten Annahmen gewählt werden Beispiel für das Messen von interner Qualität Größe Lines of Code (LOC) Function Points (FP) Kompleität Selbst wieder ein facettenreicher Begriff McCabe zyklomatische Kompleität Verschachtelungstiefe Modultestabdeckung Kopplung... 7

8 Problem: Einblick in die interne Qualität Konflikt zwischen Entwicklung und Management Entwickler: Investition in interne Qualität, um sie Software langfristig besser warten zu können Manager: Kurzfristiger Entwicklungsfortschritt: neue Anforderungen, Fehler lösen Langfristig ökonomische und technische Risiken minimieren Widerspruch! Problem: Interne Qualität ist für sie größten Teils nicht sichtbar Verbesserung der internen Qualität bringt keine kurzfristigen Einnahmen Temporäre Behelfslösungen erheben den Anschein eines schnellen Entwicklungserfolges 8

9 9

10 Monitoring Code Quality and Development Activity by Software Maps Johannes Bohnet and Jürgen Döllner automatische Softwareanalyse und -überwachung von qualitätsbezogenen Metriken und Entwicklungsaktivitäten mittels Software Maps Ziele: interne Qualität besser sichtbar und verwertbar zu machen ein effektives Kommunikationsmittel zwischen Management und Entwicklern anzubieten 10

11 Die Software Maps werden automatisch generiert Quellcode Dateien sind in einer modularer Hierarchie angeordnet auf die Blöcke werden datei-bezogene Metriken projeziert Qualitätsindikatoren und entwicklungsbezogene Informationen werden kombiniert und zusammen evaluiert Grundfläche, Farbe, Höhe Keine neue Metrik! 11

12 Kompleitäts-Hotspots erkennen Dateien mit hoher Kompleität stellen evtl. hohes Risiko dar Ausreiser erkennen und analysieren Software Maps unterstützen den Entscheidungsprozess Wann und wo ist ein Refactoring sinnvoll? Interne Qualitätseigenschaften fließen mit ein Grundfläche: LOC (2388) Höhe: Ma. McCabe (177) Farbe: Verschachtelungstiefe (7) 12

13 Vorteile kein universeller Schwellwert im Kontet der Architektur Metriken werden nicht isoliert, sondern in Kombination betrachtet Integration in den Entwicklungsprozess Kontinuierliche Integration Aktuelle Informationen über Qualität und Entwicklungsaktivitäten In Echtzeit sehen, wie sich die Software entwickelt Frühwarnsystem 13

14 Die Datenquellen & der Prozess der automatischen Softwareanalyse 14

15 Entwicklung in Code mit niedriger Qualität Grundfläche: LOC (2957) Höhe: Anzahl an Änderungen (5) Farbe: Ma. McCabe (38) 15

16 Fehleranfällige Codedateien aufdecken Grundfläche: LOC (6505) Höhe: Anzahl an Änderungen (8) Farbe: Anweisungen auf Block Level 7 (30) 16

17 Bewertung Software Maps um interne Qualität sichtbar zu machen Problematische Quellcodebereiche werden aufgezeigt Basis um Softwarequalität zu verbessern Neue Erkenntnisse durch die Kombination von statischen Qualitätsattributen und Entwicklungsaktivitäten Für alle Beteiligten sichtbar - Management, Kunden, Entwickler automatisch, sachlich, aktuell, frei konfigurierbar, zurückverfolgbar Lässt interne Qualität in den Entscheidungsprozess einfließen Macht sichtbar: zuerst in Code Verbesserung investieren, um dann schneller weiterzumachen und auch später weniger Wartungsaufwand zu haben 17

18 Einschränkungen Metriken sorgfältig und zielorientiert wählen Visualisierung kann auch verwirrend sein Information, nicht Wissen Falsche Maßnahmen trotz korrekter Interpretation Verwendete Metriken McCabe Kompleität nur strukturelle Kompleität unterschiedlichen Programmiersprachen innerhalb eines Systems 18

19 Einschränkungen (2) Auswirkung von Refactoring auf Codemetriken Refactoring Does it improve software quality? Empirical investigation of refactoring effect on software quality Andere Einflüsse auf interne Qualität: Architektur, Design Umstrukturierung notwendig ohne aktuelle Problemstellen Kontinuierliche Integration: Entwickler fühlen sich beobachtet Kommerzielles Tool 19

20 Zweites Paper... Standardized Code Quality Benchmarking for Improving Software Maintainability A Practical Model for Measuring Maintainability Ilja Heitlager, Tobias Kuipers, and Joost Visser

21 Der Benchmark Ziel: Standard für das Messen von Softwarequalität (hier speziell Wartbarkeit) zu entwickeln Qualität des Produktes vor der Testphase sichtbar machen Bestandteile: Qualitätsmodell nach ISO/IEC 9126 Definition von Wartbarkeit Repository Speichern der Bewertungen Vergleichen der Systeme Kalibrieren des Qualitätsmodells Standardisierung unterstützt die Vergleichbarkeit 21

22 Das Qualitätsmodell Anforderungen an das Modell technologieunabhängig einfache Definition der Metriken einfaches Implementieren und Berechnen leicht verständliche und erklärbare Metriken Ursachenanalyse sollte möglich sein Kern eines ausgereifteren Modells 22

23 Softwarequaliät nach ISO/IEC 9126 Was fehlt in der ISO: - Quellcodemetriken für Wartbarkeit - Zuordnung der Metriken auf Systemeigenschaften 23

24 Dreischichtiges Modell Modul: kleinste, ausführbare und testbare Codeeinheit Abbildung von Systemeigenschaften auf Quellcodeeigenschaften: Größe Analysierbarkeit Modifizierbarkeit Modulkom Redundanz pleität Modulgröße Modulprüfung Stabilität Testbarkeit 24

25 Messen der Größe Intuitiv: größere Software ist schwerer zu analysieren Backfiring Function Points statt LOC Umrechnungstabelle Wieviele LOC bilden einen FP (pro Programmiersprache) Wieviele FP kann ein Programmierer im Monat implementieren Umstrittenes Verfahren, aber für Zweck hier hinreichend akkurat Des Weiteren automatisierbar, schnell, erklärbar, technologieunabhängig Größe Analysierbarkeit Modifizierbarkeit Stabilität Testbarkeit 25

26 Messen der Modulkompleität Komplee Module sind schwerer zu ändern und zu testen McCabe zyklomatische Kompleität Qualitätsprofil Risikogruppen definieren Module Risikogruppen zuordnen Prozentualen Anteil in LOC ausrechnen Kompleitätsbewertung nach Schema Modulkompleität Analysierbarkeit Modifizierbarkeit Stabilität Testbarkeit 26

27 Messen der Modulkompleität (2) sprachunabhängig leicht zu verstehen/berechnen hinreichend akkurat zurückverfolgbar Modulkompleität Analysierbarkeit Modifizierbarkeit Stabilität Testbarkeit 27

28 Messen der Redundanz In kleinen Mengen in allen Systemen zu finden und unbedenklich Sehr viel redundanter Code Software kann schlechter analysiert und geändert werden Clone Detection Verfahren: Redundante Blöcke über mindestens sechs Zeilen sehr einfach, schnell und Ursachenanalyse möglich allerdings weniger akkurat als ausgeklügeltere Methoden Lösung Redundanz: Auslagern in Unterroutinen,... Tiefere Ursachen: Entwicklerfähigkeiten, Architektur-/Designprobleme,... Redundanz Analysierbarkeit Modifizierbarkeit Stabilität Testbarkeit 28

29 Messen der Modulprüfung Menge guter Modultests hat eine positive Auswirkung auf die Wartbarkeit Testbarkeit, Stabilität, Analysierbarkeit Modultestabdeckung messen (dynamische Analyse) Nicht sprachunabhängig Validierung: ASSERT Anweisungen zählen Leicht zu verstehen, implementieren und zu erklären Modulprüfung Analysierbarkeit Modifizierbarkeit Stabilität Testbarkeit 29

30 Zurück auf Systemebene abbilden Aggregieren der Metriken: Gewichteter Durchschnitt für jede Systemeigenschaft (Durchschnitt aller Systemeigenschaften für Gesamtwartbarkeit) Ursachenanalyse ist möglich: Analysierbarkeit Modifizierbarkeit Größe Modulkompleität Redundanz Modulgröße Modulprüfung o - Stabilität Testbarkeit o o 30

31 Bewertung des Qualitätsmodells pragmatischer Ansatz, um einerseits die Lücken in der ISO 9126 zu schließen und andererseits einige der zahlreichen, in der Literatur zu findenden Softwaremetriken auszuwählen, zu aggregieren und auf Systemeigenschaften zu beziehen. praktizierbarer Rahmen für Qualitätsmessung Nicht nur Qualitätsfragen klären, auch Teamprobleme aufdecken Programmiersprachenunabhängig Einfach zu berechnen und zu erklären Einfach zu verstehen Ermöglicht Ursachenanalyse und damit Basis für Korrekturmaßnahmen 31

32 Einschränkungen des Qualitätsmodells Durchschnittsbildung? Ordinalskalen? Zuordnungen Systemeigenschaften Quellcodeeigenschaften sind intuitiv bzw. auf Erfahrung beruhend Empirische Studie durchgeführt Zusammenhang Quellcodeeigenschaften und Untereigenschaften: konsistent A Survey-based Study of the Mapping of System Properties to ISO/IEC 9126 Maintainability Characteristics 32

33 Einschränkungen des Qualitätsmodells (2) Größe: Große Softwaresysteme grundsätzlich unanalysierbar? Aufteilung auf mehrere Systeme besser als auf mehrere Pakete? Kompleität: McCabe nur strukturelle Kompleität String-Matching für Code Clone Detection: z.b. leicht unterschiedliche Namen werden nicht als Duplikat erkannt Schwellwerte beruhen auf Erfahrung bzw. Repositoryinhalt (Bias) Studie: Zusammenhang Bewertungen nach Qualitätsmodell und Zeit Fehler zu lösen Faster Defect Resolution with Higher Technical Quality of Software Faster Issue Resolution with Higher Technical Quality of Software 33

34 Einschränkungen des Qualitätsmodells (3) Einfache Metriken können einfach unterlaufen werden Weitere Einflüsse auf Wartbarkeit: Architektur, Design,.. Nicht entdeckt: Quellcodeverpflechtung Geringere Akkuratheit auf Kosten von Automatisierbarkeit und Technologieunabhängigkeit Es sind nur Indikatoren manuelle Analyse notwendig und richtige Maßnahmen ableiten Wie jedes Modell nicht vollständig 34

35 Anwendung des Benchmarks Mit dem Qualitätsmodell basierend auf dem akzeptierten ISO 9126 Qualitätsstandard soll der Benchmark folgendes ermöglichen: Softwaresysteme industrieweit hinsichtlich ihrer Wartbarkeit zu vergleichen Softwaresysteme zu zertifizieren Zertifizierungsschema mindestens 2 Sterne (entspricht - ) in allen Systemeigenschaften mindestens 3 Sterne (entspricht o ) in der Gesamtwartbarkeit Standardisiertes Vorgehen beim Bewerten und Kontrollieren von Softwarequalität Qualitätsüberwachung während der Entwicklungsaktivitäten Verträge, Ausschreibungen, 35

36 Beschränkungen des Benchmarks Repository Bias Von SIG analysierte Systeme Systeme mit Qualitätsproblemen, Open Source, Zertifizierungen Kalibrierung Bias Untersuchung (Größe, Sprache, ) Mindestens einmal jährlich Kalibrierung des Qualitätsmodells Starke Änderung der Schwellwerte? Keine klare Referenz Standard? Verfügbarkeit Verbreitung bisher nicht viele Zertifikate Fokus: Wartbarkeit ist nur ein Aspekt von Softwarequalität 36

37 Zusammenfassung zwei Ansätze um Einblick in die interne Qualität zu erlangen um auf Basis von Quellcodemetriken Softwarequalität zu verbessern Automatisierte Ansätze Kontrolle der Softwarequalität während des Entwicklungsprozesses Maßnahmen ergreifen vor der Testphase Unterstützen die Kommunikation zwischen den Beteiligten für alle Beteiligte transparent Abstraktion + Ursachenforschung 37

38 Zusammenfassung zwei Herangehensweisen Software Maps Visualisierungsansatz Ausreiser erkennen Neue Erkenntnisse durch Kombination von Information über Entwicklungsaktivitäten und Quellcodeeigeschaften für bestimmte Zwecke konfigurierbar einzelnes System Benchmark Standardisiertes Vorgehen Vergleichbarkeit, Zertifizierung festgelegtes Qualitätsmodell basierend auf ISO/IEC 9126 speziell für den Qualitätsaspekt Wartbarkeit 38

39 Bewertung Zahlreiche Beschränkungen, doch manuelle Alternative nicht möglich Praktikable Ansätze um Qualitätskontrolle in den Firmen zu etablieren 39

40 Fazit Kombination Tools zur Unterstützung + Epertenwissen + Kommunikation Kombination aus beiden Ansätzen: eterner Vergleich mit Benchmark + system-interne Analyse mit Software Maps Lieber unvollständig quantifizieren als gar nicht 40

41 Vielen Dank! 41

42 Diskussion 42

43 References J.Bohnet and J. Döllner, Monitoring Code Quality and Development Activity by Software Maps, in Proceedings of the IEEE ACM ICSE Workshop on Managing Technical Debt, New York, ACM, 2011, pp R. Baggen, K. Schill et al., Standardized Code Quality Benchmarking for Improving Software Maintainability, in Proceedings of the 4th International Workshop on Software Quality and Maintainability, Madrid, Spain, March, I. Heitlager, T. Kuipers et al., A Practical Model for Measuring Maintainability, in Proceedings of the 6th International Conference on the Quality of Information and Communications Technology, Lisbon, IEEE Computer Society Press, October, 2007, pp B. Luijten and J. Visser, Faster Defect Resolution with Higher Technical Quality of Software in Proceedings of the 4th International Workshop on Software Quality and Maintainability, Madrid, Spain, IEEE Computer Society Press, March, 2010, pp D, Bijlsma, M. A. Ferreira et al., Faster Issue Resolution With Higher Technical Quality of Software in Software Quality Journal, May 2011, pp

44 References (2) J. P. Correia, Y. Kanellopoulos et al., A Survey-based Study of the Mapping of System Properties to ISO/IEC 9126 Maintainability Characteristics, in 25th IEEE International Conference on Software Maintenance, Edmonton, AB, Canada, September, 2009, pp M. Alshayeb, Empirical investigation of refactoring effect on software quality, in Information and Software Technology, v.51 n.9, Newton, MA: BH, September, 2009, pp K. Stroggylos, D. Spinellis, Refactoring Does it improve software quality? in 5th International Workshop on Software Quality, Minneapolis, MN: ACM Press, May, 2007, pp