Software Qualität. Dipl.Ing. Reinhard Prehofer, Dipl.Ing. Bernhard Wachter Wien, im September 2008

Größe: px

Ab Seite anzeigen:

Download "Software Qualität. Dipl.Ing. Reinhard Prehofer, Dipl.Ing. Bernhard Wachter Wien, im September 2008"

Katja Keller
vor 8 Jahren
Abrufe

1 Software Qualität Dipl.Ing. Reinhard Prehofer, Dipl.Ing. Bernhard Wachter Wien, im September 2008

2 Agenda / Inhalte Ziele im SW - Qualitätsmanagement Zweck eines Qualitätsmodells Metriken / Vermessung: o Wichtige Meßgrößen und daraus ableitbare Aussagen Visualisierung von Messwerten Umsetzung eines vollautomatisierten Qualitätssicherungsprozesses 2

und daraus ableitbare Aussagen Visualisierung von Messwerten

3 Splendit IT-Consulting GmbH Singerstraße Wien T: E: H: Primäres Geschäftsfeld o Qualitätsaspekte in allen Phasen der SW-Entwicklung Projektleitstand Qualität und Steuerung/Kontrolle als Prozess aufgesetzt (innere) SW-Qualität und Metriken o Datenqualität o Architekturberatung Integration und Migration o Schulungen o Qualitäts-Prozessmanagement 3

at Primäres Geschäftsfeld o Qualitätsaspekte in allen Phasen der SW-Entwicklung Projektleitstand

4 Reinhard Prehofer 25 Jahre EDV-Background Consulting primär im Bereich o Architekturen o Transformation / Migration / Integration ("Cobol 2 Java" u.dgl.) o Testverfahren und methodiken o Datenqualität SW-Qualität und Metriken o ISO9126 "Projektleitstand" für SW- Entwicklung Schulungen 4

5 Was "bedeutet SW-Qualität für SIE" in der SW-Entwicklung? Als Beispiel o Wartbarkeit, Lesbarkeit des Codes o Einhaltung von Normen, Standards, Vorgehen Betonung auf welche Phasen? o Analyse o Design Architektur o Entwicklung Test Was ist Ihr Ziel? Welche Ziele (bzw. zu lösende Probleme) fallen Ihnen ad hoc ein 5

Standards, Vorgehen Betonung auf welche Phasen?

6 Ihre Ziele sollten sein (1/2) Entwickelte Komponenten sind sowohl wartbar als auch wiederverwendbar. o Personalfluktuation darf kein Problem darstellen. Oder SW-Zulieferung durch Lieferanten o Software soll nicht 'altern'. o Aufwandsschätzungen für spätere Wartungen müssen möglich sein. (Ist Wartbarkeit messbar?) o Maintainability wovon abhängig 6

Oder SW-Zulieferung durch Lieferanten o Software soll nicht 'altern'.

7 Ihre Ziele sollten sein (2/2) Komponenten wurden ausreichend getestet - Aussagen über deren Korrektheit sind möglich. o Etabliertes Testverfahren (Unit-Tests...) o Gleichzeitige Minimierung des nötigen Testaufwands. o Wissen Sie Ihre Codeabdeckung (C0, C1)? 7

o Etabliertes Testverfahren (Unit-Tests.

8 (Nochmals) was "bedeutet SW- Qualität für SIE"? Wartbarkeit, Lesbarkeit von Code o Begründetes Hauptargument für Kostensenkung Einhaltung von Zeit / Ressourcen Normen, Standards, Vorgehen einheitlich Portierbarkeit (erhöhen) Saubere Architektur und Schnittstellen Produktivität (erhöhen) Fehlerfreiheit, Stabilität Benutzerzufriedenheit (erhöhen) 8

Einhaltung von Zeit / Ressourcen Normen, Standards, Vorgehen einheitlich

9 Aspekte der SW-Qualität (1/3) Anlassfall bezogen (assessment) Problemen und Fehlern auf den Grund gehen SOURCE-Review und Analyse Vermessen der Software Interne Reife, richtige Dokumentation von Sourcen? Outsourcing, Offshoring / Lieferantensteuerung (SW-)Katze im Sack gekauft? 9

Vermessen der Software Interne Reife, richtige Dokumentation von

10 Aspekte der SW-Qualität (2/3) Wartungsaspekte mindestens 70-80% der SW- Kosten gehen in die Wartung Chaos Report

11 Aspekte der SW-Qualität (3/3) Standards (im Unternehmen) definieren und kontrollieren Programmiertechnik und muster,( gute/schlechte ) inkl. Konventionen sowie Design Patterns CPD Architekturvorgaben Qualitätsmessung der SW-Artefakte als Prozess etablieren = der Schritt zu einem Leitstand (kontinuierlicher Überwachungs-prozess) 11

Konventionen sowie Design Patterns CPD Architekturvorgaben Qualitätsmessung der

12 "You cannot control what you cannot measure" Tom demarco Was ist gute Software / Mustervorgabe o Gutes Coding ( patterns o Gute Muster (design o Empfohlene Styleguides o Architekturpatterns N- Schichten, fat- client, SOA, Welches Coding ist abzulehnen o Anti patterns code that smells Wer definiert die Messlatte? o Woher Vergleichswerte holen o Best practices vs. worst examples 12

N- Schichten, fat- client, SOA, Welches Coding ist abzulehnen o Anti patterns code that smells

13 Zweck eines Qualitätsmodells Um die Qualität eines Software-Produktes beurteilen zu können, benötigt man ein (Qualitäts)modell o in dem die einzelnen Aspekte der Qualität greifbar gemacht werden Kriterien / Subkriterien vorgeschlagen und definiert sind... o Vordefinierte (grobe) Modelle gibt es U.a. ISO-9126, GQM Anwendbarkeit, Praktikabilität der Modelle Faktor = relevante Qualitätsmerkmale o (vom engl. factors) SW-Qualität 13

14 ISO 9126 als Beispiel für ein (bi-direktionales) Qualitätsmodell Aggregation vo n messbaren Qualitäts- Merkmalen Metriken strukturelle Eigenschaften ( patterns Problemmuster (anti Anomalie mit begründeten negativen Auswirkungen auf innere Qualität Verbesserungshinweise S W- Qualitätsanalyse ersetzt keinen Test aber lief e SW-Qualität rt Kandidaten (schwarze Schafe)

Anomalie mit begründeten negativen Auswirkungen auf innere Qualität Verbesserungshinweise S W-

15 Phasen (1/2) welche Phase - was ist besonders wichtig o Analyse (Fehlerverbreitung!) z.b. "weiche Formulierungen", Auslassungen.. o Architektur (als Bsp. "ATAM"...) o Codierung "klassische Metriken" o Test + Testabdeckung (ganz wichtig!) Heute: Konzentration auf Code/Test 15

16 Phasen (2/2) Automatisierung o keine Abstriche nötig o Unterschied klassisches Modell automatisierter Prozess In einem automatisierten Prozess werden auch bei späteren Wartungsarbeiten Architektur-Metriken gemessen (Abhängigkeiten etc). Normaler Prozess: Bei späteren Wartungen wird die Architektur häufig überhaupt nicht berücksichtigt und entartet. 16

Wartungsarbeiten Architektur-Metriken gemessen (Abhängigkeiten etc).

17 Tests aus Entwicklungssicht Entwicklung von neuen Komponenten o "Ausprobieren" des Geschriebenen notwendig o Frage: Erwarteter Wert = errechneter Wert? Debugging ist "kein klassischer Test" o Nicht wiederholbar Verwendung von Testframeworks o Implementierung von Testfällen Verwendung von zu testenden Komponenten Vergleich eines erwarteten Ergebnisses mit dem tatsächlich erhaltenen SW-Qualität

Debugging ist "kein klassischer Test" o Nicht wiederholbar Verwendung von Testframeworks o

18 Vorteile durch die Verwendung von Testframeworks Tests sind beliebig oft ohne weitere Aufwände wiederholbar. "Asserts" Annahmen über Ergebnisse im Framework Einmal aufgetretene Fehler können sich nicht wieder einschleichen. Testfälle als Anlage. 18

"Asserts" Annahmen über Ergebnisse im Framework Einmal

19 Messgröße - Abhängigkeiten (Fan-In, Fan-Out) Gibt Aufschluß über zentrale Komponenten, deren Änderungen weitreiche Auswirkungen haben. Änderungen an zentralen Komponenten sind häufig nur mit sehr großem Aufwand möglich. Modul 19

20 Messgröße - Lesbarkeit (Halstead Metrik) Gibt Aufschluß über die Lesbarkeit bzw. die Komplexität von Code und somit über den Aufwand für zukünftige Wartungen und Weiterentwicklungen. Ermöglicht ein automatisiertes 'Korrekturlesen' von Code. Basierend auf der Anzahl an unterschiedlichen Operatoren und Operanden sowie der Größe von Codestücken wird ein Komplexitätsmaß berechnet. 20

Weiterentwicklungen. Ermöglicht ein automatisiertes 'Korrekturlesen' von Code.

21 Messgröße - Testbarkeit (zyklomatische Komplexität) Gibt Aufschluß über den nötigen Test-Aufwand. Ermöglicht eine automatisiert erzeugte Aussage über die Anzahl an nötigen Testfällen. Definiert durch die Anzahl an möglichen Wegen in einem Kontrollflußgraphen des Programms 21

22 Messgröße - Testabdeckung (Code Coverage) Gibt Aufschluß darüber welcher Code getestet wurde oder nicht. o "Instrumentierung" Ermöglicht die Identifikation von Komponenten über deren Korrektheit keine Aussage gemacht werden kann! o Ungetesteter Code 22

23 Visualisierung von Metriken Daten zu SW-Artefakten o Tupel aus: Artefakt Zeitpunkt Metrik gemessener Wert Visualisierungsformen und Metaphern o Zeitreihen Vergleiche/Trends Auswirkungsanalysen o 3D Visualisierung Ansatz 'SW as a city' 23

24 Interne SW-Qualität / Verlauf 24

25 Trendentwicklung / Regression 25

26 Risiko- und Auswirkungsanalyse 26

27 3D Visualisierung Ansatz 'SW as a city' 3D Visualisierungsansatz o Darstellung von Komponenten und Sub-Komponenten. Einstiegspunkt einer Analyse Visuelle Erkennung von Problemen und deren Ausmaß. Auf Knopfdruck kann Aufschluss über die Ursache gewonnen werden SW-Qualität

28 Wege zur kontinuierlichen Qualitätsüberwachung Definition der Ziele Auswahl der Metriken (+Tools) o Inkl. Antipatterns o Messen der Metriken KPIs definieren und zusammenstellen Build-Verfahren und Sensoren Verknüpfung der getrennt gemessenen Werte Visualisierung, Kontrolle und Steuerung 28

29 Vollautomatisierter Qualitätssicherungsprozess Aktuelle Sourcen Versionsverwaltung Nightly build Automatische Tests / Code-Unit-Tests Testbewertung +Testabdeckung Vermessung des Codes Qualitätsmetriken Metriken, Visualisierung 29

30 Zielsetzung eines automatisierten QM - Prozess Softwareentwicklung wird über alle Entwicklungsstadien über alle Abteilungen hinweg überwacht. o Unabhängig von Plattform und Technologie. o Kontinuierliche, objektive Messung. o Ausgangssituation zur Ableitung von qualitätsverbessernden Maßnahmen. 30

31 Gesamtheitliche Visualisierung + Kombination der Messungen Messzahlen Sensoren... Leitstand Berichte - -. =Sensor Browser, SW - Visualisierung

32 Danke! Fragen gerne jederzeit: Jetzt oder später

Ähnliche Dokumente

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008 Konzeption und Implementierung einer automatisierten Testumgebung, 10. Dezember 2008 1 Gliederung Einleitung Softwaretests Beispiel Konzeption Zusammenfassung 2 Einleitung Komplexität von Softwaresystemen