Maintainability Index als Instrument der Software-Wartung

Transkript

1 Stuttgart Maintainability Index als Instrument der Software-Wartung Maintainability Index als Instrument der Software-Wartung Dieses Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen schriftlichen Zustimmung von Steria Mummert Consulting Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen und die Einspeicherung und Verarbeitung in elektronischer Form. Eine Weitergabe an Dritte ist nicht gestattet. Matthias Klein Senior Consultant Holger Renner Senior Consultant Steria Mummert Consulting AG Martin-Luther-King-Weg 24, D Münster Telefon: Fax: :15; Seite 2 1

2 Agenda. Herausforderungen in der SW-Wartung Optimierung Kennzahl Maintainability Index Überdeckungsgrad Kritische Betrachtung Verwendbarkeit des MI Wartungsportfolios Weiterentwicklung des MI Diskussion :15; Seite 3 Herausforderungen in der Wartung von Software. Grundlegende Problembereiche in der Wartung Organisatorische Stolpersteine. Technische und qualitative Probleme :15; Seite 4 2

3 Herausforderungen in der Wartung von Software. Esse quam videri Organisatorische Stolpersteine. Der offizielle Weg: Fachabteilung (User) IT Einkauf/ Controlling Wartungsdienstleister Der gelebte Weg: Fachabteilung (User) IT Einkauf/ Controlling Wartungsdienstleister? :15; Seite 5 Herausforderungen in der Wartung von Software. Nicht-Messbarkeit der Wartung bewirkt u.a. Qualitative Probleme: - Die Zunahme der Entropie innerhalb des Quellcodes der Software und die - Abnahme der wirtschaftlichen Nutzbarkeit der Software Erfüllungsgrad 100% Funktionale Anforderungen t Nichtfunktionale Anforderungen, z. B. Wartbarkeit Quelle: Lehmann, Belady :15; Seite 6 3

4 Optimierung. Organisatorische Wartungsoptimierung In Zusammenarbeit mit den involvierten Parteien Fachabteilung, IT, Einkauf und Wartungsdienstleister werden die erbrachten Wartungsaktivitäten analysiert und bewertet. Im Vordergrund stehen die Fragen Sind die geleisteten Aktivitäten notwendig und sinnvoll? Werden adäquate Skills eingesetzt und abgerechnet? Wurden berechnete Leistungen tatsächlich erbracht? :15; Seite 7 Optimierung. 3 Analyse der Wartbarkeit von Software Über eine Quellcodeanalyse kann durch den Maintainability Index die Wartbarkeit von Softwaresystemen ermittelt werden. Diese Wartbarkeit kann als absolute Kennzahl in Relation zu Wartungskosten und Alter der Anwendung eine Aussage treffen, ob ein Re-Engineering, eine Neuentwicklung oder ein unveränderter Weiterbetrieb der untersuchten Anwendung sinnvoll ist :15; Seite 8 4

5 Optimierung. Das Wartbarkeitsportfolio als Managementinstrument Wartungskosten / Jahr Untersuchte Applikationen und deren Qualität der Wartbarkeit in Schulnoten Alter der Anwendung in Jahren :15; Seite 9 Optimierung. Mögliche Optimierungsmaßnahmen Einarbeitung in die Wartungsorganisation des Kunden Analyse der Applikationslandschaft des Kunden Clusterung in Wartungskostenklassen Überprüfung der Wartungsrechnungen in Zusammenarbeit mit der Fach- und IT-Abteilung Analyse der Top 10 der Wartungsintensivsten Anwendungen auf Ihre Wartungsqualität hin (MI) Erstellung Wartbarkeitsportfolio der Top 10 Neuverhandlung der Wartungsverträge mit den Dienstleistern, Einführung des MI als Abnahmekriterium Handlungsempfehlung bzgl. Re-Engineering, Neuentwicklung oder Weiterbetrieb der untersuchten Applikationen :15; Seite 10 5

6 Optimierung. Beispielhafte Entwicklung eines Wartungsbudgets im Verlauf der durchgeführten Maßnahmen Wartungsbudget 100% 50% Q1/07 Q2/07 Q3/07 Q4/07 Q1/08 Q2/08 Q3/08 Q4/08 t :15; Seite 11 Maintainability Index. Lines-of-Code Cyclomatic Complexity Thomas McCabe Program Volume Maurice Halstead In den frühen 90er Jahren entwickeln Paul Oman und Don Coleman den Maintainability Index (MI) mit dem Ziel die Wartbarkeit von Software zu quantifizieren :15; Seite 12 MI 6

7 Lines of Code. Was wird gemessen? LOCphy: Anzahl physikalischer Zeilen LOCbl: Anzahl von Leerzeilen LOCpro: Anzahl von Programmzeilen LOCcom: Anzahl von Kommentarzeilen Abgeleitete Metriken: percm = Prozentualer Anteil von Kommentarzeilen pro Modul Ein Modul sollte max. 400 Programmzeilen enthalten. Der Anteil sollte zwischen 25% und 75% liegen :15; Seite 13 Cyclomatic Complexity. Thomas McCabe hat bereits 1976 die Cyclomatic Complexity (CC) eingeführt. switch Sie gibt die Anzahl linear unabhängiger Pfade durch eine Routine bzw. durch ein Modul an, wobei er den zugrunde liegenden Code als gerichteten Graphen interpretiert. case Definition: CC = E N + 2 E = Anzahl der Kanten (engl. Edges) im Graph N = Anzahl der Knoten (engl. Nodes) im Graph while CC sollte pro Modul den Wert 100 nicht überschreiten :15; Seite 14 7

8 Halstead Volume. Maurice Halstead hat bereits 1977 das Program Volume (V) eingeführt. Diese Metrik beschreibt das Volumen einer Programmeinheit basierend auf der Anzahl der verwendeten Operatoren und Operanden. Was wird gemessen? n1: Anzahl verschiedener Operatoren n2: Anzahl verschiedener Operanden N1: Anzahl aller Operatoren N2: Anzahl aller Operanden Operanden sind Typen und Namen von Variablen und Konstanten. Operatoren sind +, -, *, /, >, <,!=, ==, etc. und reservierte Wörter wie new, if, then, for, while, return, etc :15; Seite 15 Halstead Volume. Abgeleitete Metriken: Die Vocabulary Size (n) ergibt sich aus der Summe aller verschiedener Operatoren und aller verschiedener Operanden: n = n1 + n2 Die Program Length (N) ergibt sich aus der Summe aller Operatoren und aller Operanden: N = N1 + N2 Das Program Volume (V) quantifiziert den Informationsgehalt einer Programmeinheit (Routine, Modul): V = N * log2 (n) Program Volume = Program Length * log2 (Vocabulary Size) V sollte pro Modul den Wert 8000 nicht überschreiten :15; Seite 16 8

9 4-metric MI. 4-metric MI (mit Kommentaren): MI = 171 5,2 * ln(avgv) 0,23 * avgcc 16,2 * ln(avglocpro) + 50 * sin( (2,4 * percm)) avgv = mittleres Program Volume pro Modul avgcc = mittlere Cyclomatic Complexity pro Modul avglocpro = mittlere Anzahl von Programmzeilen pro Modul percm = mittlerer prozentualer Anteil von Kommentarzeilen pro Modul :15; Seite 17 Interpretation des MI.? Software mit einem MI größer als 85 kann als gut wartbar betrachtet werden. Zwischen 65 und 85 kann von einer mittelmäßigen Wartbarkeit gesprochen werden. Liegt der MI unter 65, dann ist die Software nur schwer zu warten :15; Seite 18 9

10 Überdeckungsgrad. Bei der Erhebung des MI können nur die Teile eines Softwaresystems betrachtet werden, die in einer gängigen Sprache wie z.b. C, C++ oder Java programmiert wurden. Andere Teile, wie z.b. - Konfigurationsdateien - Metadatenstrukturen - Shell-Skripte - Datenbankskripte - XML- / HTML-Dateien können nicht bewertet werden, obwohl diese einen deutlichen Anteil am Gesamtsystem haben können. Um diesen Effekt zu relativieren, kann zusätzlich der Überdeckungsgrad der Analyse angegeben werden. Dieser gibt den prozentualen Anteil der untersuchten Lines-of-Code (physikalisch) am gesamten Softwaresystem an :15; Seite 19 Kritische Betrachtung des MI (Teil 1). Bei der Berechnung des MI handelt es sich um eine statistische Analyse des Quellcodes. Daher kann keine Aussage über die syntaktische oder funktionale Korrektheit getroffen werden. Unmittelbare Rückschlüsse auf nicht-funktionale Eigenschaften wie z.b. Stabilität, Performanz und Bedienbarkeit sind ebenfalls nicht zulässig. Architekturprinzipien und Programmierparadigmen (z.b. OO) beeinflussen den MI, da sich diese auf die Programmstruktur auswirkt. Softwaresysteme, bei denen sich der Programmcode über viele kleine Module verteilt, werden besser bewertet. Dies geschieht also auch dann, wenn eine zu feine Granularität vorliegt :15; Seite 20 10

11 Kritische Betrachtung des MI (Teil 2). Die Cyclomatic Complexity ist eine prozeduale Softwaremetrik. D.h., dass Komplexität, die durch objektorientierte Programmierung entsteht (z.b. durch Vererbung und Polymorphismus) nicht erfasst wird. Es konnte keine Korrelation zwischen dem MI und den tatsächlichen Wartungskosten festgestellt werden. Dies lässt sich darauf zurückführen, dass Projektkostenstrukturen sehr vielfältig sind und die Wartbarkeit nur ein Kostentreiber von vielen ist. Frage: Ist trotz dieser Einschränkungen ist ein Vergleich zwischen Softwaresystemen zulässig? :15; Seite 21 Verwendbarkeit auf Projektebene. Der MI kann bereits während der Entwicklung als Steuerungsinstrument zur Erreichung höherer Wartbarkeit eingesetzt werden. Er kann als Qualitätskriterium in den Abnahmeprozess integriert werden, z.b. nach jedem Major Release. Er erleichtert als Analysewerkzeug die Orientierung innerhalb eines Softwaresystems, mit dem Ziel qualitative Schwachstellen aufzudecken. Aus der Sicht des Projektverantwortlichen liefert der MI gegenüber dem Auftraggeber bzw. der Fachseite eine argumentative Grundlage für Refactoring-Aufwände. Aus Sicht des Auftraggebers liefert der MI gegenüber dem Entwicklungsdienstleister eine argumentative Grundlage zur Nachbesserung auf Gewährleistung vor Abnahme, um Wartungskosten von Anfang an nicht unkontrolliert anfallen zu lassen :15; Seite 22 11

12 Verwendbarkeit auf Managementebene. Der MI als isoliert betrachtete Größe eignet sich grundsätzlich als Qualitätsindikator. Eine Korrelation zu den tatsächlichen Wartungskosten konnte nicht festgestellt werden. Der MI eignet sich insbesondere für die Auswahl aus dem Rahmen fallender Softwaresysteme durch mehrdimensionale Analysen. Dabei spielen weitere Kennzahlen wie z.b.: Wartungskosten Lebenszyklus / Systemalter eine Rolle. Die so ausgewählten Softwaresysteme können einem standardisierten Maintainability Audit mit Fokus auf Qualität und Kosten unterzogen werden :15; Seite 23 Maintainability Portfolio (ohne Kostenaspekt). Maintainability Index ,28 302,97 428,83 298,95 576, SW 1 (C/C++) SW 2 (Java) SW 3 (Java) SW 4 (C/C++) SW 5 (Java) Systemalter in Jahren Kreisfläche = Systemumfang in KLOCpro :15; Seite 24 12

13 Maintainance Costs Portfolio (Variante A). Wartungskosten in TEUR p.a , , , , Systemumfang in KLOCpro SW 1 (C/C++) SW 2 (Java) SW 3 (Java) SW 4 (C/C++) Kreisfläche = Maintainability Index :15; Seite 25 Maintainance Costs Portfolio (Variante B). Wartungskosten in TEUR p.a ,23 85,68 76,87 42,73 SW 1 (C/C++) SW 2 (Java) SW 3 (Java) SW 4 (C/C++) Systemalter in Jahren Kreisfläche = Maintainability Index :15; Seite 26 13

14 Check / Weiterentwicklung des MI. In Untersuchungen von Oman und Coleman Anfang der 90er Jahre fehlen moderne Architekturen und Programmierparadigmen (z.b. J2EE, OO, XML, etc.). Frage: Ist deshalb eine Rekalibrierung des MI notwendig, ggf. unter Einbezug neuerer Metriken? Appell: Wissenschaft und Wirtschaft sollten zusammenarbeiten: Die Wirtschaft könnte Statistik-Daten / Drittmittel liefern. Gegenleistung von universitärer Seite: Prüfung und Aktualisierung des MI, Lösung für Überdeckungsprobleme, soweit wissenschaftliche Grundlage fehlt :15; Seite 27 14