Software wird auch im Maschinenbau zur Kernkompetenz

Klassische KVP-Prozesse greifen zu kurz und berücksichtigen den künftig steigenden Anteil der 'Software-Produktion' beziehungsweise Entwicklung zu wenig.Phoenix Contact

Randbedingung des Zukunftsprojekts Industrie 4.0 ist die Digitalisierung der Fertigungslandschaft. Und mit dem Einzug des Internets sowie moderner Technologien in die Produktion wird dies auch gelingen. Die Fertigungshallen wandeln sich zu selbstdenkenden Systemen, in denen das herzustellende Produkt entscheidet, auf welcher Linie es produziert wird.

Die anstehenden Veränderungen betreffen neben den Anwendern auch die Hersteller. Denn sie sind es, die ihre Produkte, Komponenten und Maschinen so planen, entwickeln und gemäß Industrie-4.0-konformer Methoden fertigen müssen, dass sie sich in die entsprechend ausgelegten Anlagen integrieren lassen. Solche Produkte sind intelligent, kommunikativ und basieren auf Software, die einen immer größeren Anteil an den Neuentwicklungen hat. Dies stellt die Anbieter vor einige Herausforderungen. Der Grund: Traditionelle Betrachtungen der Herstellkosten ignorieren den Wert der Software. Vielmehr erfolgt die Preisbildung eines Produkts in der Regel auf Basis der Fertigungs- und Materialkosten. Der steigende finanzielle Aufwand für die Erstellung der Software geht heute meist in den Gemeinkosten auf. Bei diesem Kalkulationsmodell trägt die Software nicht zur Wertschöpfung des Produkts bei. In diesem Punkt muss ein Umdenken stattfinden, da Innovation – auch in Software –ihren Preis hat.

Software-Entwicklung wird weder gemessen noch gesteuert

Auch die Produktivitätsmodelle müssen sich ändern. Bislang bildet der Herstellungsprozess das Herzstück der allgemeinen Prozesskette. Er ist so optimal wie möglich zu gestalten, weshalb der Herstellungsprozess bei den meisten Unternehmen genau kon­trolliert, protokolliert und kontinuierlich verbessert wird (KVP). Anders ausgedrückt: Die Produktivität wird gemessen. Bei software-basierten Produkten mit einem überproportionalen Anteil der Software an der Wertschöpfung reicht der traditionelle KVP-Fokus nicht mehr aus. Denn das Aufspielen der Software auf das Produkt lässt sich kaum optimieren. Zudem entspricht der Fertigungsschritt ‚Software-Download‘ nicht dem eigentlichen Produktionsprozess ‚Software-Entwicklung‘. Zu Bedenken ist darüber hinaus, dass die Innovationsschritte vieler Produkte mehr und mehr in der Software erfolgen, während die Hardware unverändert bleibt. Andere Produkt-Varianten gehen aus neuen Software-Versionen hervor. Folglich ergibt sich für Software eine abweichende Prozesskette.

Das Innovationspotenzial der hergestellten Produkte liegt also in der Software, wobei sich KVP-Messungen nicht auf deren Erstellungsprozess fokussieren. Es ist davon auszugehen, dass viele Hersteller heute ihre Software-Entwicklung überhaupt nicht messen – und somit nicht steuern können. Für eine Steuerung fehlen beispielweise Ist-Informationen zu Menge, Qualität, Personalaufwand oder Terminen – Kenngrößen, wie sie für jede Fertigung selbstverständlich sind. Ohne solche Ist-Daten können aber keine Soll-Werte definiert und überprüft werden.

Bei aller Kreativität – Software-Entwicklung ist messbar

Vereinfachtes Prozessmodell des Software-Lebenszyklus: Innovationen und Produktvarianten entstehen mehr und mehr im Software-Entwicklungsprozess.Phoenix Contact

Der Aspekt fehlender Erkenntnis wirft zahlreiche Fragen auf. Im Mittelpunkt steht die Diskussion, ob sich überhaupt eine Analogie zwischen Software-Erstellung und klassischem Produktionsprozess herstellen lässt. Schließlich gilt die Entwicklung von Software allgemein als ein Kreativprozess. Lässt sich Kreativität einfach messen?

Ein Blick auf die Entwicklungsphasen einer Software-Version hilft: Der Prozess ist in Planung, Spezifikation, Umsetzung, Test und Freigabe unterteilt. Unabhängig von einem agilen oder traditionellen Entwicklungsansatz werden diese Phasen immer sowie für jede Version des Produkts durchlaufen.

Die im industriellen Umfeld verwendeten Produkte haben eine lange Lebensdauer. Wenn diese beispielsweise zehn Jahre beträgt und pro Jahr drei Software-Versionen erstellt werden, ergeben sich in Summe 30 Versionen. Jede Version hat einen definierten Funktionsumfang, beschrieben durch konkrete Anforderungen. Die Umsetzung der Anforderungen erfordert keinen Kreativprozess im Sinn einer technologischen Innovation, denn: Zentrale Rahmenbedingungen wie die eingesetzten Betriebssysteme, Prozessoren oder Architekturmodelle ändern sich in der Regel nicht. Vielmehr müssen Entwickler und Tester permanent überlegen, wie sich die Anforderungen in den Grenzen der genannten Rahmenbedingungen mit möglichst geringem Aufwand zügig und fehlerfrei realisieren und testen lassen. Faktoren wie Anzahl, Aufwand, Zeitbedarf und Fehlerrate sind dabei messbar.

Die Software-Forschung beschäftigt sich durchaus mit der Produktivität in der Software-Entwicklung. Es gibt umfangreiche Literatur zu den Methoden und empirischen Untersuchungen. Jedoch ist eine einheitliche Systematik nicht erkennbar. Die vorhandenen Normen und Standards helfen ebenfalls nicht weiter, denn es existieren keine relevanten Regeln. Modelle wie CMMI (Capability Maturity Model Integration) oder Spice (Software Process Improvement and Capability Determination) erfordern ab einem bestimmten Reifegrad die Messung der Software-Entwicklung. Sie schreiben allerdings keine konkreten Methoden vor. Deshalb müssen die Hersteller aus den vielen Ansätzen das für ihre Zwecke am besten geeignete Konzept entwerfen und implementieren.

Teufelsquadrat unterstützt bei der Produktivitäts-Ermittlung

Teufelsquadrat nach Harry Sneed: Soll sich der Entwicklungsprozess verbessern, darf eine Effizienzsteigerung eines Parameters nicht zu Lasten eines anderen stattfinden.Phoenix Contact

Bei der Ausgestaltung der Konzepte bietet das Teufelsquadrat von Harry Sneed Orientierung. Die vier zu berücksichtigenden Produktivitätsfaktoren bilden die Eckpunkte des Quadrats. Das Viereck innerhalb des Quadrats, das die erreichbare Produktivität anzeigt, lässt sich durch die Erhöhung von Quantität und Qualität bei gleichzeitiger Reduzierung von Entwicklungsdauer und Kosten vergrößern. Eine einseitige Veränderung führt nicht unbedingt zu einer höheren Produktivität, beispielsweise wenn die Qualität zu Lasten der Entwicklungsdauer verbessert wird.

Beim Einsatz dieses Modells ist als nächstes zu definieren, wie die genannten Faktoren gemessen werden. Die Kosten resultieren im Wesentlichen aus dem Personalaufwand, weshalb ein präzises Reporting-System zur Messung notwendig ist. Diese scheinbar einfache Aufgabenstellung kann in der Praxis bereits zur Herausforderung werden, etwa wenn geeignete Reporting-Systeme fehlen und eine genaue Zuordnung der Tätigkeiten zu einer Version nicht möglich ist. Die Erfassung der Entwicklungsdauer erhöht die Komplexität zusätzlich. Diskussionsstoff bietet bereits die Frage, wann die Arbeiten an einer Version beginnen: mit dem Aufnehmen der Anforderungen durch die Produktverantwortlichen oder erst mit der Spezifikation, Implementierung und den Tests durch die Entwicklung? Anfang und Ende der Tätig­keiten müssen also genau festgelegt werden.

Die Messung objektiver Qualitätszahlen erweist sich als noch schwieriger. Sie zielen darauf ab, die Diskussionen hinsichtlich der Qualität zu versachlichen sowie Verbesserungen nachzuweisen. Dies vor dem Hintergrund, weil einzelne Probleme oft die gesamte Software in Frage stellen. Hier haben sich Fehler­management-Systeme etabliert. Die Auswertung des Datenbestands hört allerdings häufig bei der Betrachtung der Anzahl auf. Zu empfehlen sind weitergehende Analysen zum Zeitpunkt der Erfassung, beispielsweise vor und nach dem Release, sowie die Einführung einer Klassifizierung. Die ISO/IEC 25010 stellt dafür eine mögliche Grundlage dar. Die komplizierteste Fragestellung ergibt sich jedoch aus der Quantität der Software. Mögliche Ansätze sind in dem Umfeld die Messung der Lines of Code, Churns (Änderungen des Codes) oder Function-Point-Methoden. Jedes dieser Verfahren liefert genaue Zahlen zur Software-Menge. Code-basierte Metriken lassen sich dabei vergleichsweise einfach implementieren, wohingegen funktionale Methoden ausgebildete Experten erfordern.

Sechsstufiger Ablauf bildet die Grundlage für die Bewertung

Eine gute Möglichkeit Software-Qualität zu messen: Fehler-Klassifizierung nach dem ISO/IEC-25010-Qualitätsmodell.Phoenix Contact

Alle Produktivitätsfaktoren lassen sich messen und zueinander ins Verhältnis setzten – beispielsweise in Form von Points per Hour. Zugegeben, die Umsetzung ist allerdings beschwerlich. Folgende Schritte bieten sich als sinnvoller Ablauf an:

Einführung eines Application-Lifecyle-Management-Systems, in dem zentral sämtliche Aufwände, Zeiten, Fehler, Quelltexte, Spezifikationen und Tests erfasst werden

• Entwurf eines geeigneten Kennzahlen-Modells
• Implementierung eines Messverfahrens
• Erfassung von Ist-Werten
• Formulierung von Soll-Werten
• kontinuierliche Überprüfung des Erreichens der Soll-Werte.

Die Wertschöpfung von gemäß Industrie 4.0 gefertigten Produkten durch Software wächst. Das bedingt eine produktive Software-Entwicklung seitens der Hersteller. Sie müssen ihre Leistungsfähigkeit einschätzen, um diese messbar kontinuierlich zu verbessern. Zu Beginn eines solchen Prozesses lassen sich nicht alle Fragen beantworten. Dies sollte die Hersteller nicht daran hindern, sich der Herausforderung zu stellen. Denn jede Messung ist besser als keine.

SPS IPC Drives 2014
Halle 9, Stand 310

(sk)