Sind wir auf dem Weg zu den Besten?

Die Beantwortung dieser Frage erfordert Klarheit über das Ziel (wer sind die „Besten“ und was zeichnet sie aus?) und eine permanente Standortbestimmung. Welche Antwort dürfen wir schließlich erwarten, wenn wir einen Menschen mit verbundenen Augen bitten, uns die kürzeste Route zu einem bestimmten Ziel zu zeigen?

Die Produktionsmethoden der Softwarebranche sind 40 Jahre hinter denen der Automobilindustrie zurück

Die japanische Automobilindustrie zeichnete sich Anfang der 1970er Jahre durch eine höhere Produktivität und bessere Qualität gegenüber ihrer europäischen und amerikanischen Konkurrenz aus. Erwähnenswert sind das Toyota Produktionssystem (TPS) oder Total Quality Management (TQM) mit Errungenschaften wie standardisierten Prozessen und einem kontinuierlichen Verbesserungsprozess, die sich, wenn überhaupt, in der Softwarebranche erst in jüngster Zeit durchgesetzt haben (s. a. Artikel „Fertigungsstraße für die Softwareproduktion“ in PASS AGE Q1 2011). Eines wurde damals bereits deutlich: Eine wesentliche Voraussetzung für die Steuerung und Verbesserung von Qualität und Produktivität ist deren Messbarkeit. Die Automobilindustrie hat damals geeignete Metriken gefunden: Die Anzahl der Montagefehler pro 100 Fahrzeuge, die Arbeitsstunden für die Produktion eines Fahrzeugs usw. Betrachten wir die IT-Branche, beschränken sich die Kennzahlen der Auftraggeber auf Tagessätze, die der Softwareproduzenten auf Deckungsbeiträge. Das ermöglicht keine Optimierung von Qualität und Produktivität. Es lässt nicht einmal eine Standortbestimmung zu.

Das Dilemma der Softwareentwicklung

Bei genauer Betrachtung muss man zugestehen, dass es erheblich einfacher ist, Qualität und Produktivität in der Automobilfertigung zu messen als bei der Erstellung von Software: Beispielsweise durch Ermitteln der Anzahl von Montagefehlern in einer definierten Menge von beispielsweise 100 produzierten Fahrzeugen. Die Anzahl an Montagefehlern entspricht in der Softwareentwicklung den Bugs, die man in einem finalen Test oder im Produktionsbetrieb während einer bestimmten Zeit feststellt. Was aber entspricht den 100 Fahrzeugen als Produktionseinheit?

Ohne die Normalisierung direkter Maße (Montagefehler, Bugs) durch eine Produktionseinheit geht es nicht. Man kann nicht aus der Fehleranzahl verschieden großer IT-Systeme auf ihre Qualität schließen. Erst wenn man die direkt messbare „Fehleranzahl“ durch eine quantitative Angabe der betrachteten Prüflinge, analog den 100 Fahrzeugen, dividiert, erhält man eine vergleichbare Kennzahl. Beispiel: Bei System „BAD“ treten monatlich 25 Fehler auf, bei System „GOOD“ hingegen 40 Fehler. Ist deswegen „GOOD“ von geringerer Qualität als „BAD“? Nicht, wenn man berücksichtigt, dass System „GOOD“ doppelt so groß ist wie „BAD“. Bei „BAD“ dürften also nur 20 Fehler auftreten, wenn es die gleiche Qualität wie „GOOD“ hätte.

Dieses Beispiel zeigt das Dilemma, in dem sich die Softwarebranche befindet: Was ist die Produktionseinheit für Software? Wann ist ein System „doppelt so groß“ wie ein anderes? Wie kann Software quantifiziert werden? Nur wenn es gelingt, direkte Maße wie die Fehleranzahl oder die Anzahl der Entwicklungsstunden/-tage ins Verhältnis zum „Umfang“ der betrachteten Software zu setzen, entsteht – analog zur Automobilbranche – eine normalisierte Kennzahl, die Vergleiche zwischen verschieden großen Systemen erlaubt. Denn: Das Messen der eigenen Qualität und Produktivität sowie Vergleiche mit anderen – den „Besten“ – sind eine Grundvoraussetzung zur Steuerung und Optimierung.

Software quantifizieren – damals und heute

Die Softwaremetrie unterscheidet zwischen verschiedenen Kategorien von Metriken: Umfangs-, Komplexitäts-, objektorientierten Metriken, usw. Eine Umfangsmetrik ist geeignet, um Kennzahlen zur Produktivität oder Qualität zu normalisieren. Betrachten wir daher, welche Umfangsmetriken sich im Laufe der Zeit etabliert haben und wie diese den Ansprüchen, die an eine Metrik gestellt werden, wie Objektivität, Zuverlässigkeit, Validität, usw. (siehe Box), gerecht werden.

In der Anfangszeit der Softwareentwicklung ermittelte man den Umfang durch die Anzahl der Programmzeilen (Lines of Code, LoC), was auch heute noch praktikabel ist, wenn es beispielsweise um die Bestimmung der Kommentardichte geht oder um das Verhältnis von generiertem zu manuell implementiertem Code. Da in den modernen Programmiersprachen die Anzahl der Codezeilen jedoch stark vom individuellen Programmierstil abhängt, ist eine Ermittlung des Umfangs – sozusagen als Produktionseinheit - über die Anzahl der Codezeilen nicht ausreichend valide.

Ende der 1970er Jahre entwickelte Allan J. Albrecht (IBM) die Function Point Methode, mit der man im ersten Schritt den fachlich funktionalen Umfang einer Anwendung bestimmt. Dabei werden Elementarprozesse und logische Datenbestände identifiziert und deren Komplexität auf einer meist dreistufigen Skala bewertet. Die Methode ist unabhängig von Programmiersprachen und –stilen, sie erfordert jedoch ein tiefes Verständnis der Anwendungsfunktionalität und ist aufgrund der Komplexitätsbewertung durch den Schätzer nicht ausreichend objektiv.

Harry M. Sneed entwickelte Anfang der 1990er Jahre ein Verfahren, das den Umfang einer Anwendung über die Anzahl der Tabellen, Attribute, Schlüssel, Relationen, etc. in der Datenbank und Datenpunkte in den verschiedenen Ansichten und Schnittstellen ermittelt. Seine Data Point Methode ist objektiv, da sie sich auf das Zählen von Objekten beschränkt und ohne die Bewertung durch den Schätzer auskommt. Mit der Etablierung mehrschichtiger Anwendungsarchitekturen und der damit verbundenen Entkopplung der Datenbank von der Fach- und Präsentationslogik kommt jedoch der Datenbank nicht mehr die Bedeutung zu, dass man aus einer Detailbetrachtung ihrer Strukturen eine valide Kennzahl für den Umfang eines Systems ableiten könnte. 

H. M. Sneed: Software-Aufwandsschätzung mit DATA-POINTS; ComputerMagazin 11-12/91, S. 41-46

Um die Jahrtausendwende entstand die Data Interaction Point (DIP) Methode. Sie wurde von PASS in Zusammenarbeit mit der Fachhochschule Würzburg mit der Zielsetzung entwickelt, eine Umfangsmetrik für moderne Anwendungsarchitekturen zu finden. Die DIP-Methode betrachtet die Datenbank nur als Container für fachliche Daten, was ihrer Bedeutung in mehrschichtigen Architekturen und insbesondere in der modellgetrieben Softwareentwicklung nahe kommt. Sie zählt die Anzahl der fachlichen Datenelemente und gewichtet diese unterschiedlich - je nachdem, ob auf ein Attribut lesend und schreibend oder nur lesend zugegriffen wird. Zusätzlich quantifiziert die DIP-Methode alle Interaktionen dieser fachlichen Datenelemente mit dem Anwender über das Graphical User Interface (GUI) oder mit anderen Systemen über Schnittstellen. Auch hier wird, je nach Verwendung eines fachlichen Datenelements – beispielsweise in einem Eingabe- oder einem Anzeigefeld des GUI - unterschiedlich gewichtet.

Erfahrungen mit der DIP-Methode

Für eine bestehende Anwendung kann das Zählen der Datenelemente automatisiert werden. PASS verfügt über ein Toolset um beispielsweise die Metadaten einer Datenbank, das GUI-Modell einer Anwendung oder für Schnittstellen verwendete XML-Schemata auszuwerten und die entsprechenden DIP-Werte zu ermitteln.

Vor der Entwicklung eines Systems kann der DIP-Wert abgeschätzt werden, wenn eine Vorstellung über das Datenmodell, die erforderlichen Dialoge und Schnittstellen existiert. Aber auch hier kann automatisiert werden: Die Fachkonzept-Vorlage der PASS-Verfahrenstechnik liefert nach Aufruf eines Makros automatisch die DIP-Werte der in Tabellenform beschriebenen Dialoge.

Die DIP-Methode ist somit ökonomisch, weil sie Datenobjekte zählt, was meist automatisiert erfolgen kann, und eine zeitaufwendige Einarbeitung in die Funktionalität der Anwendung nicht notwendig ist. Da nicht bewertet oder geschätzt sondern gezählt wird, erfüllt sie auch die Ansprüche an Objektivität und Zuverlässigkeit. Doch wie sieht es mit der Validität aus?

Der mit der DIP-Methode gemessene Umfang orientiert sich am Aspekt der Datenverarbeitungsleistung – im Gegensatz zum Aspekt der Programmlänge oder der Komplexität von Elementarfunktionen bei den oben betrachteten Metriken. Sie misst die Datenverarbeitungsleistung ausschließlich als Anzahl fachlicher Datenelemente, die von der Anwendung verwaltet werden und die mit der „Außenwelt“ interagieren. Die Praxis zeigt, dass die Funktionalität moderner Anwendungen fast immer auf das Entgegennehmen, Prüfen, Ablegen, Auswerten und die Ausgabe solcher Datenelemente reduziert werden kann und der Entwicklungsaufwand bei gleichen Teams und gleicher Technologie stark mit der Anzahl der DIPs korreliert. Außergewöhnlich hohe Anforderungen in Bezug auf Verfügbarkeit, Zeitverhalten, Sicherheit, usw. betrachten wir nachgelagert und getrennt von einer Umfangsermittlung mit der DIP-Methode, was bei der Function Point Methode ähnlich ist (durch die Einbeziehung der General System Characteristics in den justierten Function-Point-Wert).

Leistungskennzahlen machen Produktivität und Qualität messbar

Mit einer zeitgemäßen Umfangsmetrik wie der DIP-Methode ist das Instrumentarium für Messungen der Produktivität und Qualität in der Softwareentwicklung vorhanden. Beim ersten Einsatz der DIP-Methode erkannten wir jedoch ein grundsätzliches Dilemma: Mangels Erfahrungswerten lieferten unsere Messungen zunächst zusammenhanglose Zahlen. Niemand konnte sagen, ob eine Kennzahl gut oder schlecht ist, weil es keine Vergleichsmöglichkeit gab. Schätzte man für eine Kundenanfrage den DIP-Wert der zu erstellenden Anwendung, konnte man ohne Erfahrungswerte mit dieser Zahl kaum mehr anfangen als mit einer Zufallszahl.

Es hat sich herausgestellt, dass Leistungskennzahlen erst nach einer gewissen Zeit einen Nutzen darstellen. Dies ist ein iterativer Prozess: Mit neuen Messungen von Qualitäts- und Produktivitätskennzahlen stehen wieder mehr Vergleichswerte für Benchmarks zur Verfügung und man erkennt, wo ein abgeschlossener Entwicklungsauftrag in Relation zu den besten und schlechtesten Projekten im Unternehmen einzuordnen ist. Eine prospektive Aufwandsschätzung im Fall einer Kundenanfrage geht davon aus, dass der Umfang des Systems geschätzt und durch einen Erfahrungswert für die Produktivität auf den zu erwartenden Aufwand rückgerechnet wird (gemäß der Formel: Produktivität = Umfang / Aufwand bzw.: Aufwand = Umfang / Produktivität). Diese Schätzung ist so genau, wie der Umfang des angefragten Systems abgeschätzt werden kann und der angenommene Erfahrungswert für die Produktivität verlässlich ist.

Stand Heute

Heute verfügen wir über eine reichhaltige Sammlung von Kennzahlen zu Neu- und Weiterentwicklungen mit unterschiedlichen Technologien, Entwicklungsmethodiken, Teams, usw. Im Fall einer Aufwandsschätzung führen wir eine DIP-Schätzung für das zu entwickelnde System durch und teilen den DIP-Wert durch die Produktivität, die wir in vergleichbaren Entwicklungsprojekten bereits gemessen haben. Bei Neu- oder Weiterentwicklungen erstellen wir Statusberichte mit verschiedenen Kennzahlen, die alle mit dem DIP-Wert normalisiert sind. Erst dadurch werden die Produktivität (Einheit: DIP pro Personentag) oder der Fehlerindex (Einheit: Anzahl der Fehler im Abnahmetest pro 1000 DIP) zwischen verschieden Entwicklungsaufträgen unterschiedlicher Größe vergleichbar. Für von uns betriebene produktive Systeme ermitteln wir Kennzahlen zu Produktionsfehlern (Einheit: Fehleranzahl pro 1000 DIP) oder einen Wartungskosten-Index (Einheit: Euro pro DIP).  

Die Leistungsfähigkeit unserer Softwareentwicklung in Bezug auf Produktivität und Qualität ist heute sehr transparent, und zwar über Organisationseinheiten mit unterschiedlichem Hintergrund hinweg: Sei es die Weiterentwicklung und der Betrieb eines 20 Jahre alten Bankensystems in der AS/400-Welt, einer 25 Jahre alten Cobol-Anwendung, einer komplexen Logistiklösung, einer Travel Suite moderner Architektur, etc. Normalisierte Kennzahlen machen sie alle miteinander vergleichbar.

Ein „Frühwarnsystem“ für Projekte

Durch diese Erfahrungswerte erkennen wir sehr früh, ob eine Entwicklung „gut“ verläuft oder ob es in einem Projekt Handlungsbedarf gibt. Sozusagen ein „Frühwarnsystem“ für Projekte. Suchen wir aufgrund von Grenzwertüberschreitungen einzelner Indizes nach Erklärungen, finden wir nicht selten Probleme, und meist lösen wir diese spontan.

Die Messung beeinflusst das Messobjekt

Die hohe Transparenz durch Leistungskennzahlen führt zu einem permanenten internen Wettbewerb. Alle Organisationseinheiten vergleichen ihr Handeln und ihre Ergebnisse ständig mit den Besten im Wettbewerb. Die Besten streben danach, besser zu werden. Daraus resultieren Anstrengungen in Richtung einer Optimierung. Prozessuale und organisatorische Hürden werden identifiziert und beseitigt.

Allerdings möchte ich an dieser Stelle auch darauf hinweisen, dass wir die Errungenschaften der japanischen Automobilindustrie erst etwa 40 Jahre später auf die Softwareentwicklung adaptiert haben. Viele Unternehmen der Softwarebranche sind jedoch heute noch nicht einmal annähernd auf diesem Stand.

Die Richtung stimmt

Eine Nachbetrachtung von Entwicklungsaufträgen der letzten Jahre zeigt sehr deutlich, in welche Richtung wir uns bewegt haben. Aus einer differenzierten Betrachtung werden auch technologische Einflüsse transparent. Wir erkennen heute klar den Unterschied in der Produktivität von Projekten mit klassischer Programmierung gegenüber solchen mit modellgetriebener Softwareentwicklung mit der PASS Virtual Software Factory (VSF). Auch Weiterentwicklungen unserer Software Factory zeigen ihre Wirkung in den Kennzahlen. Wir können messen, wie die Produktivität durch Verbesserungen bei der Modellierung, durch Einführung neuer Komponenten, einer hohen Standardisierung durch beispielsweise generierte Stammdatendialoge (BaseApp-Ansatz), usw. steigt.

Aber wo ist das Ziel?

Wir können verifizieren, dass sich Produktivität und Qualität in der Softwareentwicklung bei PASS kontinuierlich verbessern. Wir stellen fest, dass dies kein lineares Wachstum ist sondern dass der Anstieg der Produktivität größer wird – meist sprunghaft, da er von Optimierungen und Innovationen abhängig ist. Da wir gleichzeitig noch sehr viel Optimierungspotenzial erkennen und vor allem die technologischen Möglichkeiten in der industriellen Softwareproduktion noch lange nicht ausgereizt sind, ist das Ende oder selbst eine rückläufige Produktivitätssteigerung nicht erkennbar.

Herausforderungen

Sicher ist, dass die industrielle Softwareproduktion, wie wir sie bei PASS heute betreiben, noch großes Potenzial zur Produktivitätssteigerung und einer gleichbleibenden, vorhersagbaren Qualität hat. Eine Herausforderung ist dabei eine direkte Steuerung der Softwareproduktion durch Kennzahlen. Eine weitere liegt in der Verbesserung unserer Metriken.

Die DIP-Methode zeigt Unschärfen, wenn es um Weiterentwicklungen geringen Umfangs geht. Hier suchen wir nach einer Hybridmetrik, in die neben den Data Interaction Points auch eine Maßzahl für die Funktionalität eines Programms einfließt. Das Ziel ist, Funktionalität bzw. algorithmische Komplexität objektiv zu messen, ohne sie im Detail verstehen zu müssen.