Willkommen. Bei der 4. Softnetkonferenz

Transkript

1 Willkommen Bei der 4. Softnetkonferenz Professor Horst Cerjak, 4. Softnet Konferenz - Softwarequalität, SCCH, Hagenberg Kompetenznetzwerk Softnet Austria

2 Programm 09:00 09:30 Begrüßung: g Dr. Klaus Pirklbauer, SCCH und Prof. Dr. Franz Wotawa, TU Graz 09:30 10:00 Die Bedeutung von Qualität in Softwareprodukten a. Univ.-Prof. Mag. Dr. Reinhold Plösch, JKU 10:00 10:30 Kontinuierliches Performance Management in der Softwareentwicklung DI (FH) Alois Reitbauer, dynatrace software GmbH 10:30 11:00 Kaffeepause 11:00 11:30 Risiken abbauen Dipl. Math. Manfred Bundschuh, David Consulting Group 11:30 12:00 Die Qualität im Blick mit Software Cockpits DI (FH) Stefan Larndofer, SCCH 12:00 13:30 Mittagessen Netzwerken am Buffet 13:30 14:00 Software Qualitätssicherung durch systematische Softwaretests Dr. Bernhard Peischl, TU Graz 14:00 14:30 From science to business Dr. Bruno Buchberger, Softwarepark Hagenberg g 14:30 14:45 Kaffeepause 14:45 15:30 Quality Talk 15:30 15:45 Zusammenfassung Ab 16:00 Führung durch den Softwarepark Professor Horst Cerjak, 4. Softnet Konferenz - Softwarequalität, SCCH, Hagenberg Kompetenznetzwerk Softnet Austria

3 Die Bedeutung von Qualität in Softwareprodukten Kooperationsprojekt mit Siemens CT SE 1 Softnet Konferenz, Hagenberg R. Plösch,

4 Quality is a complex and multifaceted concept. It is also the source of great confusion David A. Garvin, 1984 R. Plösch,

5 Softwarequalität Unterschiedliche Sichten auf Qualität (transzendent, benutzer- bezogen, prozessorientiert, produktorientiert, Kosten-/Nutzenbezogen) Eine Definition iti für Softwarequalität (nach ISO 1061): Die Gesamtheit und Ausprägung von Eigenschaften und Merkmalen eines Softwareproduktes bezüglich seiner Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen. Systematische Strukturierung von Eigenschaften und Merkmalen Überprüfung, inwieweit diese Eigenschaften und Merkmale erfüllt werden R. Plösch,

6 Unterschiedliche Sichten auf Softwarequalität ISO 9126 (ISO 25000) unterscheiden internal quality, external quality, quality in use Fokus auf interner Qualität 1, München Kooperationsprojekt mit Siemens CT SE R. Plösch,

7 Qualitätsmodelle (1) Strukturierung von Qualitätseingschaften mit Hilfe von Qualitätsmodellen Ziel: Qualität transparent und meßbar machen Beispiel eines Qualitätsmodelles (ISO 9126 / ISO 25000) R. Plösch,

8 Qualitätsmodelle (2) Probleme bei der Anwendung von Qualitätsmodellen in der Praxis Dekompositionsprinzipien nicht eindeutig Für das Qualitätsmonitoring sind unterschiedliche Sichten auf Qualität erforderlich Modelle nicht ausreichend operational (Metriken!) Unzureichende methodische Unterstützung Fehlende oder unzureichende Werkzeugunterstützung tüt Operationale ISO-basierte Modelle zwingend notwendig Modelle verfügbar aber nicht international standardisiert Technische Sicht auf Qualität wünschenswert (vor allem für Architekten) Modelle verfügbar aber nicht international standardisiert R. Plösch,

9 Qualitätsmodelle sind nicht genug g Operationale Qualitätsmodelle definieren einen Standard Definierte Sicht auf Qualität Standardisierung des Messverfahrens durch Integration der Metriken von konkreten Werkzeugen trotzdem es besteht Bedarf an Methode Handbuch Werkzeugunterstützung R. Plösch,

10 Szenarien für Qualitätsbeurteilung Expertenzentierte Evaluierung von Software Kaufentscheidung für Software Einsatzentscheidungen für (Open-Source) Software Entscheidung über Weiterentwicklung von Software Kontinuierliches Qualitätsmonitoring Evaluation Method for Internal Software Quality (EMISQ) Weiterentwicklung des Standards ISO mit dem Fokus auf bessere Operationalisierung i Continuous Quality Monitoring Method (CQMM) Software-Blood Count (CapGemine g sd&m) Quality Index der SAP AG R. Plösch,

11 Expertenzentrierte Evaluierung 9

12 EMISQ Überblick Vorgaben durch Standards nicht operational genug ISO 9126, ISO 14598, ISO Eigenentwicklung von Methoden und Werkzeugen EMISQ (Evaluation Method for Internal Software Quality) SPQR (Software Product Quality Reporter) Ef Erfahrungen Anwendung in mehr als 20 Industrieprojekten (Indien, Europa) Werkzeugunterstützung erforderlich Kosten relativ hoch ~ 10 PT für eine Analyse R. Plösch,

13 Prinzipielle Vorgehensweise und Ergebnisse Idee Herunterbrechen von Qualitätszielen auf ein Qualitätsmodell Statische Codeanalysatoren liefern Indikatoren für Qualitätsbeurteilung Manuelle Inspektion durch Experten Dokumentation der Ergebnisse Ergebnis Detailbeurteilung von Metriken und Regeln Übergeordnete qualitative Beurteilung (Qualitätsattribute) R. Plösch,

14 Kontinuierliches Qualitätsmonitoring 12

15 Continuous Quality Monitoring Method (CQMM) Ziel Effizienter Einsatz statischer Codeanalysewerkzeuge, um qualitätsbezogene Maßnahmen automatisiert, systematisch und kontinuierlich während eines Projektes planen, steuern und überwachen zu können CQMM (Continuous Quality Monitoring Method) Nicht-Ziel Reduktion von Qualität auf eine e Zahl / Formel * ln(avghv) * avgcc(g ) 16.2 * ln (avgloc) + 50 * sin (sqrt(2.4 * percm)) HV: Halstead Volume CC: Cyclomatic Complexity LOC: lines of code percm: Comment Ratio R. Plösch,

16 CQMM ist leichtgewichtig g und iterativ Leichtgewichtiger setup Anpassung nach jeder Iteration möglich Externe Audits stellen korrekte Anwendung der Methode sicher Monitoring Ansatz flexibel Trendbasiertes Monitoring Benchmarking R. Plösch,

17 Qualitätssteuerung mit CQMM 60 Trendbasiertes Monitoring Monitoring auf Basis von 30 Verbesserungen bzw. 20 Verschlechterungen über die Zeit Benchmarking basiertes Monitoring i Qualitätssteuerung auf Basis von Referenzprojekten Bei 19 Metriken gleich gut oder besser als die besten Projekte Vergleich mit den Besten! Bei 6 Metriken schlechter als die schlechtesten Projekte R. Plösch,

18 Software Blood Count (Capgemini sd&m) Visualisiert eine Sammlung praktischer, objektiver Metriken, um die Qualität von Software beurteilen zu können Für unterschiedliche Zielgruppen geeignet (Architekten, Projektleitung, Qualitätsverantwortliche) Analogie zum Blutbild: Die Qualitätsdiagnose wird durch einen menschlichen Experten durchgeführt, nicht durch eine Maschine (siehe auch EMISQ) R. Plösch,

19 Quality Index (SAP AG) Definition von KPIs für unterschiedliche Aspekte Bewertungsvorschrift für jeden Aspekt liefert einen Qualitätsindex für jeden Aspekt Aggregation der Qualitätsindizes zu Gesamtbewertungen Pro Applikation Pro Applikationsgruppe SAP-weit Trenddarstellung R. Plösch,

20 Zusammenfassung und Ausblick Gutes Instrumentarium für die Modellierung und Bewertung von Qualität verfügbar Standardisierungsbestrebungen im Gange aber noch nicht abgeschlossen ISO QuaMoCo Konsortium Erfahrungen in der Industrie zeigen, dass sich systematisches Qualitätsmonitoring auszahlt Verbreitungsgrad (gerade bei KMUs) noch nicht ausreichend R. Plösch,

21 Contact information a.univ.-prof. Dr. Reinhold Plösch Altenbergerstraße 69 A-4040 Linz Austria Fon: R. Plösch,

22 Selected International Publications R. Plösch, H. Gruber, A. Hentschel, G. Pomberger, S. Schiffer: On The Relation between External Software Quality and Static Code Analysis, Proceedings of the SEW-32 conference, October 2008, Greece R. Plösch, H. Gruber, G. Pomberger, S. Schiffer, C. Körner: Tool Support for a Method to Evaluate Internal Software Product Quality by Static ti Code Analysis, Software Quality Professional Journal, American Society for Quality, Volume 10, Issue 4, September 2008, Milwaukee, USA, 2008 R. Plösch, H. Gruber, G. Pomberger, M. Saft, S. Schiffer: Tool Support for Expert-Centred Code Assessments, Proceedings of the IEEE International Conference on Software Testing, Verification, and Validation (ICST 2008), April 9-11, 2008, Lillehammer, Norwegen, IEEE Computer Society Press, 2008 R. Plösch, H. Gruber, A. Hentschel, Ch. Körner, G. Pomberger, S. Schiffer, M. Saft, S. Storck: The EMISQ Method and its Tool Support - Expert Based Evaluation of Internal Software Quality, Journal of Innovations in Systems and Software Engineering, Springer London, Volume 4(1), March 2008 H. Gruber, Ch. Körner, R. Plösch, G. Pomberger, S. Schiffer: Benchmarking-oriented Analysis of Source Code Quality - Experiences with the QBench Approach, Proceedings of the International Conference on Software Engineering (IASTED SE 2008), February 12-14, 14, Innsbruck, Austria, IASTED, 2008 H. Gruber, Ch. Körner, R. Plösch, S. Schiffer: Tool Support for ISO based Code Quality Assessments, Proceedings of the 6th International Conference on the Quality of Information and Communications Technology, QUATIC 2007, September 12-14, Lisbon, Portugal, IEEE Computer Society, 2007 R. Plösch, H. Gruber, A. Hentschel, Ch. Körner, G. Pomberger, S. Schiffer, M. Saft, S. Storck: The EMISQ Method - Expert Based Evaluation of Internal Software Quality, Proceedings of 3rd IEEE Systems and Software Week, March 3-8, 2007, Baltimore, USA, IEEE Computer Society Press, 2007 R. Plösch,

23 Continuous APM in der Softwareentwicklung Alois Reitbauer, Technology Strategist

24 Evolution von APM Testing Continuous APM Support for all Phases Transactional Tracing Code-Level Granularity Automation and Integartion Development Production Development Testing Production 2nd Generation APM Monitoring of Infrastructure and Application Metrics Development Testing Production 1st Generation APM Monitoring of Infrastructure Metrics

25 Measurements...

26 Quality of Measurements for Analysis Target Resp. Time: 15 ms Avg. Resp. Time 13 ms Max Resp. Time: 20 ms Min. Resp. Time 6 ms Ø T (13 ms) 2x 4x M1 (4,75 ms) 3x M2 (2 ms) 1x M3 (1 ms) T1 (20s) M1 (8 ms) M2 (2 ms) M1 (8 ms) M2 (2 ms) T1 (20s) query= * M1 (8 ms) M2 (2 ms) M1 (8 ms) M2 (2 ms) T2 (6 ms) M1 (1 ms) M1 (2 ms) M3 (1 ms) M2 (2 ms) T2 (6s) query= Foo M1 (1 ms) M1 (2 ms) M3 (1 ms) M2 (2 ms) Do we have a performance problem? What is executed in this transaction? How does the response time relate to M1 execution? What s the difference between this T1 and T2?

27 dynatrace Architecture and PurePath Bytecode Sensors PurePath Mainframe Internet Application Servers Database Systems dynatrace Agent Web Servers Internet Clients Web Services Internet dynatrace Collector dynatrace Server dynatrace Clients with Custom Dashboards

28 Der frühe Vogel... Start Here Entwicklung Testen Produktion ca. 50% späterer Performanceprobleme sind in der Entwicklung sichtbar

29 Typical Application Problems

30 Architectural Problems mostly are not that easy fix Architectural Problems are not that easy fix

31 Performance Management in Development Problems Not Found Performed Tactically Work Intensive

32 You are agile and flexible... However, you are agile and flexible

33 Monitoring in Agile Development Story Points Estimate Remaining Team Velocity Development Testing Production Sprint Timeline

34 You are in control Story Points Estimate Remaining Team Velocity Development Testing Production Sprint Timeline

35 What happened? Story Points Estimate Remaining Team Velocity Development Testing Production Sprint Timeline

36 Missed Goals and Estimates Story Points Missed Estimates Estimate Remaining Team Velocity Development Testing Production Missed Goal

37 CI Integration and Architecture Validation Develop Commit Feature Performance Test Results Automated Build Functional Tests Performance Tests Developer CI System

38 Performance Management in Test Diagnosis Difficult Processes Inefficient No Component-Level Regression

39 Automated Whitebox Analysis

40 Performance Regression Dashboard

41 Performance Management in Production Diagnosis Difficult No Business To Code-Level View Infrastructure Hard to Manage

42 Management of Large Scale Applications

43 Where is the... Meat

44 Visible Process Improvements Traditional Performance Management Performance Threshold Development Testing Production Time Continuous Performance Management Performance Threshold Development Testing Production Time Developing Problem Resolution Load Testing Production

45 Risiken abbauen mit Methoden aus Studien zum Problemlöseverhalten Softnet Workshop 2009 Hagenberg bei Linz, 28. Mai 2009 von Manfred Bundschuh Lehrbeauftragter der Fachhochschule Köln, Fachbereich Informatik Sander Höhe 5 D Bergisch Gladbach Tel.: bundschuh@dasma.org 1

46 Risiken abbauen - mit Methoden aus Studien zum Problemlöseverhalten Risiken abbauen durch Überwindung von Barrieren - Interpolations-Barriere - Synthese-Barriere - Dialektische i Barriere Verbesserung der Heuristischen Struktur - Inkubationszeit die am einfachsten anwendbare Methode! - Selbstreflexion die effizienteste Erfolgsgarantie! - Verbesserung der Heuristischen Struktur der effektivste Weg! Einsatz des Problemlöser-Werkzeugkastens lö k - Ausbildung - Modellierung - Simulationen die beste Chance! - Lernen der einfachste Weg! 2

47 Risiken abbauen - mit Methoden aus Studien zum Problemlöseverhalten Mein Weg zum Risikomanagement statt einem Inhaltsverzeichnis Projektmanagement (Projekt Erfolgs- und Mißerfolgs-Faktoren) ist eine Problemlösetechnik für Synthese-Barrieren Problemlösen ist eine ebenso risikoreiche Aufgabe wie Projektmanagement Projekte sind komplexe dynamische Systeme was ist Dynaxity? Komplexität und Dynamik sind Top Risikofaktoren! Unser inadäquates Problemlöseverhalten ist ein Top Risiko tägliches Geschehen! Wir setzen unsere Ressourcen nicht ein beim Umgang mit komplexen Systemen Knowing-Doing Gap, Selbstreflexion, Modellierung, Simulationen und andere probate Problemlösemethoden Zeichnen Sie nun eine klare Struktur dieser vernetzten Teile! - Ich werde Sie hindurchgeleiten Themen: Problemlösen nach Dörner: Die Logik des Misslingens; Case Studies zum Problemlöseverhalten Lektionen zum Lernen! 3

48 Risiken abbauen - mit Methoden aus Studien zum Problemlöseverhalten Problemlösen 4

49 Risiken abbauen - mit Methoden aus Studien zum Problemlöseverhalten Lektionen zum Lernen? abgebaute Risiken?? Möchten Sie gerne: Und andere dazugehörige Geschichten über unser risikoreiches Verhalten und nicht gelernte Lektionen soweit Bürgermeister einer Stadt sein? Lohhausen Häuptling eines Dorfs in der Sahel Zone? Tanaland Leiter einer Waldbrandbekämpfungsbrigade in Norwegen? Berndt Brehmer als Ingenieur einen Atomreaktor steuern? Die Logik des Misslingens Und gelernte Lektionen falls Sie Risikovorbeugung mehr lieben als Feuerlöschen! Viel Spass! 5

50 Risiken abbauen - mit Methoden aus Studien zum Problemlöseverhalten Problemlösemethoden als Barriere Killer Manfred Bundschuh 1984 Interpolations-Barriere Synthese-Barriere - Entscheidungstabellen - Structured Analysis - Projektmanagement - Operation Research Dialektische Barriere - Simulationen - Modellbildung - Szenario Technik - Kepner Tregoe Methode - Situationsanalyse - Kreativitätstechniken - Versuch und Irrtum - Fähigkeiten trainieren - Sytem Dynamics und 1987 (aus Hofstadter; Gödel, Escher, Bach ein Endlos Geflochtenes Band): Wir haben es immer zu tun mit Selbstreflexion and Rekursion, Verflechtung und Varianten von Verflechtung, Geschichten in Geschichten Inkubationszeit, it Selbstreflexion, Verbesserung unsere Heuristischen Struktur und 2008: Bionik, Systemik, Die Morphologische Methode (Fritz Zwicky), System Dynamics 6

51 Risiken abbauen - mit Methoden aus Studien zum Problemlöseverhalten Elaine M. Hall: Managing g Risk, SEI Series in Software Engineering, Addison-Wesley, 1998 Risk Management Prozess - Risiko identifizieren - Risiko analysieren - Risikoplan erstellen - Risiken verfolgen - Risiken auflösen Risk Management Infrastruktur - Strategie entwickeln - Standardprozess aufbauen - Risikomanagement trainieren - Übereinstimmung prüfen - Einsatz optimieren Risk Management Einführung - Initiative festigen - Standardprozess anpassen - Risiken bewerten - Risiken managen Risk Management Map: Problem Minderung Prävention Antizipation Chancen Zusammengestellt von Manfred Bundschuh nach Elaine M. Hall,

52 Risiken abbauen - mit Methoden aus Studien zum Problemlöseverhalten Komplexe Systeme Hohe Risiken Komponenten Eigenschaften Hohe Risikopotentiale Vernetzte Dynamik Intransparenz Intransparenz Subsysteme betreffend darüber - Änderungen führen automatisch zu Änderungen in anderen Subsystemen (Nebeneffekte) - Potential für normale Unfälle - Entscheidungen müssen realtime erfolgen ( Stress für den Entscheider) - Entscheidungen müssen fallen, wenn das System sie benötigt, nicht wenn der Entscheider fit dafür ist den derzeitigen Zustand des Systems welche Maßnahmen welche Nebeneffekte im System bewirken Mögliche Lösungen - Verstehen ihrer Struktur - Verstehen ihrer feedback Struktur - Verstehen ihrer Vernetztheit th - Zielwechsel - Modellierung, Simulationen - Berücksichtigen aller Zeitskalen und -horizonte - gegenläufige Prozesse in Gang setzen - Subsysteme behandeln - Monitoring von - Frühwarnsignalen - Suche nach Indikatoren für Informationen - Kontinuierliche Überwachung (Monitoring, Tracking) - Installation von Frühwarn- Systemen - Lernen mit adäquaten Hypothesen über das System und sein Verhalten - Modellierung, Simulationen 8

53 Risiken abbauen - mit Methoden aus Studien zum Problemlöseverhalten Im Einfluss des Entscheiders Strukturiertheit: Im Einfluß des Systems Transparenz: statisch: Es muss ein Ziel geben Der Zustand des Systems Beobachtung muss feststellbar sein dynamisch: Es muss ein Modell Der Zustand des Systems Simulation des Systems geben muss veränderbar sein Wie entwickeln wir Wie analysieren wir Ziele und Modelle? das Verhalten von Systemen? Zusammengestellt von Manfred Bundschuh nach Berndt Brehmer,

54 Risiken abbauen - mit Methoden aus Studien zum Problemlöseverhalten Benjamin Libet: Mind Time Seine Experimente wurden in den Niederlanden erweitert Implikationen für unser Lernen (im Subsekundenbereich): Der Pferdeflüsterer (Monty Roberts) 10

55 Risiken abbauen - mit Methoden aus Studien zum Problemlöseverhalten Ein Applied Sciences Project Nutzen: Halbierung der Lernzeiten Was bedeutet das in Mio / Mia Euro??? - für die Lernzeit von Schülern und Studenten - für die Bildungsbudgets des Bundes und der Länder - für die Bildungsausgaben von KMU und Großunternehmen - für die Wettbewerbsfähigkeit Deutschlands Wie machen wir das??? Praxistransfer - Fallstudien für Kommunikationsmanagement - Wissenstransfer und Handlungsgerüste - Transferteams und Spitzenteams Bundeswehr: Fahr-Simulator PC Spiele: Flugsimulator Strategische PC Spiele: Die Siedler, Port of Call, Simcity, 11

56 Alles im Blick mit Software Cockpits Software Projekte erfolgreich steuern Softnet-Workshop, 28. Mai 2009, IT-Center Hagenberg Stefan Larndorfer at Software Competence Center GmbH Das SCCH ist eine Initiative der Das SCCH befindet sich im

57 Software Cockpits Wozu? Die Cockpit Vision Beispiele Cockpit Einführung bei BMD Systemhaus GmbH Einführungsprozess Schwerpunkte Nutzen Herausforderungen Fazit & Lessons Learned Software Competence Center Hagenberg GmbH

58 Projekt / Produktentwicklungs Daten und Prozesse Software Competence Center Hagenberg GmbH [IBM Redbook, Collaborative Application Lifecycle Management with IBM Rational Products, p. 8, Dez. 2008]

59 Software Projekt Software Produktentwicklungs Daten Ein vereinfachtes Beispiel Source Code Unit Tests Automatisierte Tests Anforderungen Entwickleraufgaben Kundenwünsche Fehlermeldungen Projektplan Zeitaufzeichungen der Entwickler Tätigkeit/Stunden Kosten Was kostete die Implementierung von Anforderung XY? Wieviel Code wurde verändert wegen Anforderung XY? Wieviel Zeit wurde für Release XY investiert? Software Competence Center Hagenberg GmbH 4

60 Software Cockpits Fundamentals I Was ist ein Software Cockpit? manage a project like flying an aircraft in a cockpit Überblick bli eines Software Projektes auf einer Seite Software Metriken, integriert über alle relevanten Datentöpfe Visualisierung von operativen Indikatoren Software Competence Center Hagenberg GmbH [Münch, Heidrich, Software project control centers: concepts and approaches, Journal of Systems and Software, 2004]

61 Beispiel I h t (Open Source) Software Competence Center Hagenberg GmbH

62 Beispiel I h t Software Competence Center Hagenberg GmbH

63 Beispiel I h t Software Competence Center Hagenberg GmbH

64 Beispiel II (wegen Datenschutzbestimmungen wurde der Screenshot weichgezeichnet) Software Competence Center Hagenberg GmbH

65 Beispiel II Software Competence Center Hagenberg GmbH (wegen Datenschutzbestimmungen wurde der Screenshot weichgezeichnet)

66 Einführung eines Cockpits bei BMD Systemhaus Business Software Produktline seit 1972 ERP System Buchhaltung, Controlling, Bilanzierung, CRM Über Kunden ~ 100 Software Entwickler ~ 150 Support Mitarbieter Steyr (Hauptsitz) Wien, München, Prag, Software Competence Center Hagenberg GmbH 11

67 Software Cockpit: Wie könnte man das Angehen? Fakten Existierende heterogene Werkzeuglandschaft Zeiterfassung, z.b. Microsoft Navision, Codeverwaltung, z.b. Subversion, PVCS, CVS Task-Management, z.b Jira, Bugzilla, Testwerkzeuge, z.b. JUnit, Ranorex, Umfangreiche historische Daten Einführung neuer integrierter Werkzeuge ist kostenintensiv Werkzeuge müssen den Prozess unterstützen Ansätze Data Integration mit Application Lifecycle Management Toolsuite Data Integration mit Business Intelligence Techniken ETL Prozess, Lightweight-Datawarehouse Software Cockpit Software Competence Center Hagenberg GmbH 12

68 Technical Solution Concept Plug-in Cockpit Data Warehouse Adapter st Qtr 2nd Qtr 3rd Qtr 4th Qtr 1st Qtr 2nd Qtr 3rd Qtr 4th Qtr Cockpit Platform to organize and share information Plug-ins to query and visualize DWH Data Warehouse Store data along timeline Allow multiple projects and historical project data Adapter Automated data collection Extract data from different repositories Support distributed environments Software Competence Center Hagenberg GmbH

69 BMD: Lösungsweg Prozessanalyse GQM Zielgerichtete Ableitung von Metriken Prozessverbesserung Entwicklung Vereinheitlichung der Softwareentwicklungs-Planung Cockpit Einführung in Pilotgruppen (nach ~ 6 Monaten) Ausrollen des Prozesses Evaluierung, Abschluss (nach ~ 12 Monaten) Software Competence Center Hagenberg GmbH

70 Nutzen Planung einfach, flexibel, vergleichbar Fortschrittsanzeige stundenaktuell, über alle Gruppen Schätzwerte/gebuchte Werte einfacher Vergleich Motivation durch überschaubare Ziele monatliches Erfolgserlebnis Anforderungen zum Produkt auf einen Blick Software Competence Center Hagenberg GmbH 15

71 Herausforderungen Vorhandene Werkzeuginfrastruktur veraltet Doppelgleisigkeiten g bei der Daten Eingabe Datenungenauigkeiten Messen ist emotional stark behaftet Transparenz statt Bewertung Vermeidung von dysfunktionalen Effekten Datensammlung Einbindung der Entwickler Dateninterpretation einheitliche Prozesse notwendig Software Competence Center Hagenberg GmbH 16

72 Lessons Learned 1. Vertrauen durch Beteiligung der Entwickler schaffen 2. Einbeziehung des Managements 3. GQM als Basis für Messungen 4. Vermeidung von dysfunktionalen Effekten 5. Aussagekräftige Cockpits durch hohe Datenqualität 6. Entwicklung von Metriken die im Entwickleralltag nutzbringend sind 7. Verwendung von klaren, positiven Begriffen 8. Einfache Prozesse und elementare Daten führen zu verständlichen Metriken 9. Weniger ist mehr Software Competence Center Hagenberg GmbH [Larndorfer, Ramler, Buchwiser, Experiences and Results from Establishing a Software cockpit at BMD Systemhaus, Euromicro 2009]

73 References BMD Systemhaus GmbH SCCH SoftCockpit Austin Robert D., Measuring and Managing Performance in Organizations, Dorset House Publishing, 1996 Larndorfer, Ramler, Buchwiser, Experiences and Results from Establishing a Software cockpit at BMD Systemhaus, 35rd EUROMICRO Conference on Software Engineering and Advanced Applications (EUROMICRO 2009) Eckerson Wayne W., Performance Dashboards: Measuring, Monitoring, and Managing Your Business, Wiley, 2005 Kan Stephen H., Metrics and Models in Software Quality Engineering, Addison-Wesley, 2003 Few Stephen, Information dashboard design : The effective visual communication of data, Jürgen Münch, Jens Heidrich, Software project control centers: concepts and approaches, Journal of Systems and Software, Volume 70, Issues 1-2, Pages 3-19, 2004 Kan Stephen H., Parrish J., Manlove D., In-process metrics for software testing, IBM Systems Journal, Vol. 40, No. 1, 2001 Basili V.R., Caldiera G., Rombach H.D., Goal question metric paradigm., Encyclopedia of Software Engineering 1, , 1994 Larndorfer Stefan, Ramler Rudolf, TestCockpit: Business Intelligence for Test Management, Session on Work in Progress in connection with 33rd EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA), Lbeck, Germany, 2007 P. Monson, C. Pampino, M. Göthe, N. Yuce, K. Nizami, K. Patel, and B. M. Smith. Collaborative Application Lifecycle Management with Rational Products. IBM Redbooks,2008. Software Competence Center Hagenberg GmbH

74 Software Qualitätssicherung durch systematischen Softwaretest Innovative Techniken und aktuelle Herausforderungen Dr. Bernhard Peischl Softnet Austria Institut für Softwaretechnologie Technische Universität Graz Professor Bernhard Horst Peischl Cerjak, 4. Softnet Konferenz - Softwarequalität, SCCH, Hagenberg Kompetenznetzwerk Softnet Austria 1/18

75 Sichten auf Software Qualität Die Gesamtheit und Ausprägung von Eigenschaften und Merkmalen eines SW-Produktes bezüglich seiner Eignung, festgelegte und vorausgesetzte Interne Metriken Erfordernisse zu erfüllen. Externe Metriken Quality in Use Metriken ISO 9126 Professor Bernhard Horst Peischl Cerjak, 4. Softnet Konferenz - Softwarequalität, SCCH, Hagenberg Kompetenznetzwerk Softnet Austria 2/18

76 Softwarequalität und Fehlerraten Möglichst wenige Post-Release Bugs Übliche Fehlerraten Applikationssoftware: 25 Bugs / LOC Gute Software: 2 Bugs / LOC Sicherheitsrelevante Software < 1 Bug / LOC Fehlerreduktion notwendig um Qualität zu erhöhen Kosten zu senken Kundenzufriedenheit zu erhöhen Allgemein akzeptiert Fehler möglichst früh finden (Kosten) Professor Bernhard Horst Peischl Cerjak, 4. Softnet Konferenz - Softwarequalität, SCCH, Hagenberg Kompetenznetzwerk Softnet Austria 3/18

77 Kosten der Fehlerbehebung Professor Bernhard Horst Peischl Cerjak, 4. Softnet Konferenz - Softwarequalität, SCCH, Hagenberg Kompetenznetzwerk Softnet Austria 4/18

78 Wie findet man Software Fehler? Inspektionen und Reviews Automatische Statische Analysen Syntaktische Analyse (Regeln) Semantische e Analysen (erweiterte e Typ-Prüfung) üu Formale Techniken Verifikation Theoretisch sehr leistungsfähig, praktisch eingeschränkt In der Praxis derzeit nur sehr punktuell verwendbar Eher eng definierte Anwendungsgebiete Hazard Analysen, Eventbaum Analysen Professor Bernhard Horst Peischl Cerjak, 4. Softnet Konferenz - Softwarequalität, SCCH, Hagenberg Kompetenznetzwerk Softnet Austria 5/18

79 Qualitätsattribute und Software Test (1) Testen SW erfüll Qualitätsattribut wenn Test durchgeht Welche Teile des Systems werden getestet? Unit-Tests Komponententests Integrationstests Systemtests In welcher Phase des Entwicklungsprozesses? Validierung durch Abnahmetest Verifikation durch Unit-Tests, Regressions-Tests, etc. Professor Bernhard Horst Peischl Cerjak, 4. Softnet Konferenz - Softwarequalität, SCCH, Hagenberg Kompetenznetzwerk Softnet Austria 6/18

80 Qualitätsattribute und Software Test (2) Welches Qualitätsattribut wird überprüft? Lasttests (Antwortzeit, Datendurchsatz) Usability Test (Benutzbarkeit) Robustheitstest Funktionale Korrektheit Welche Techniken sind anzuwenden? Standards entscheiden im Zweifelsfall, welche Verfahrensweisen, Methoden und Techniken als Stand der Technik bzw. als Stand von Wissenschaft und Technik zu betrachten sind. Professor Bernhard Horst Peischl Cerjak, 4. Softnet Konferenz - Softwarequalität, SCCH, Hagenberg Kompetenznetzwerk Softnet Austria 7/18

81 Notwendige, minimale Anforderungen Absolut notwendig entspr. aller maßgeblichen Standards: Funktionsorientierte Testplanung für alle Testphasen Reproduzierbarkeit von Testergebnissen => automatische Regressionstests Weitgehender Konsens Ergänzende strukturorientierte ti t Abdeckung (mindestens Zweigüberdeckungstest) In kritischen Anwendungsbereichen gründliche struktur- orientierte Tests (z.b. RTCA DO 178-B, MCDC Abdeckung) Professor Bernhard Horst Peischl Cerjak, 4. Softnet Konferenz - Softwarequalität, SCCH, Hagenberg Kompetenznetzwerk Softnet Austria 8/18

82 Testautomatisierung - Was ist machbar? Disziplinierte Bewertung des Testprozesse z.b. TPI (Test Process Improvement) Automatische Testausführung End-to-End d Test bei Benutzerschnittstellen e ttste e Hardware in the Loop (HiL) Testautomatisierung Testportfolio Management Generierung von Testabläufen und zugehörigen Testdaten aus Modellen Bereitstellung der (Ingenieurs)Modelle Teststrategie bzw. Festlegen des Testzieles (Fokussierung) Toolbox Unterstützung (z.b. CADP) Professor Bernhard Horst Peischl Cerjak, 4. Softnet Konferenz - Softwarequalität, SCCH, Hagenberg Kompetenznetzwerk Softnet Austria 9/18

83 Herausforderung GUI Testing (1) End-to-End Test einer Applikationssoftware Unterschiedliche Benutzeroberflächen Robustheit gegenüber konkrete Positionen von UI Elementen ( Makro-Rekorder ) Dynamisches Auftreten von UI Elementen Schwerwiegende UI-relevante Post-Release Bugs Smart Monkey Wissen über User Interface (Modell) Einfache Modellierung damit ROI gegeben Automatische Modellerstellung (Capture Tool) Random Walk durch Modell Professor Bernhard Horst Peischl Cerjak, 4. Softnet Konferenz - Softwarequalität, SCCH, Hagenberg Kompetenznetzwerk Softnet Austria 10/18