Prozessmanagement in der Praxis – Fluch oder Segen?

Mit wachsender Größe und der Globalisierung eines Unternehmens steigen die Anforderungen, um eine konstante Produktqualität unabhängig vom Standort und von der Vorbildung der Mitarbeiter zu gewährleisten. Die Einführung von Prozessen ist zumindest in der Theorie eine mögliche Lösung. Ist sie das aber auch in der Praxis?

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

„Wenn ich keinen Prozess habe, machen es vielleicht einige richtig; wenn ich einen schlechten Prozess habe, machen es alle falsch.“ Dieser Satz enthält die ganze Wahrheit des Prozessdesigns – wenn der Entwicklung der Prozesse nicht genug Zeit, Geld und Aufmerksamkeit gewidmet wird, kommt am Ende ein Prozess in schlechter Qualität heraus. Wenn alle Mitarbeiter eines Unternehmens diesem schlechten Prozess folgen, wird das erzeugte Produkt entweder eine unzureichende Qualität haben oder seine Entwicklung zu viel Geld verschlingen oder beides. Dann ist der Prozess ein Fluch und auch ein Groschengrab.

Wie vermeide ich das und komme zu einem guten Prozess? Die Abbildung einer Entwicklung in formale Prozesse kann sehr umfangreich und komplex sein, da sie bereits mit der Anforderungserhebung (Requirements Elicitation) beginnt und aus Sicht des Entwicklers (nicht notwendigerweise) mit dem Start der Serienfertigung (Start of Production) endet. Exemplarisch werde ich im Folgenden auf die Softwareerstellung im Automotive-Bereich fokussieren. Aber es gibt natürlich analoge Anforderungen sowohl bei der Hardware-Entwicklung oder in der Entwicklung mechanischer Komponenten als auch in anderen Branchen (Medizin, Avionik).

Prozessmanagement in der Praxis: Umfang des Prozesses ermitteln

Am Anfang des Prozessdesigns muss man sich klar machen, was der Prozess alles enthalten muss. Der einfachste – aber auch unvollständigste – Ansatz ist hier, einfach nur die notwendigen Arbeits- bzw. Entwicklungsschritte abzubilden. Das ist sicher ein guter Startpunkt, der einen Rahmen vorgibt, sollte aber nur ein allererster Schritt sein. Eine wesentliche Anforderung an einen Prozess ist, neben der Abbildung aller notwendigen Produktionsschritte, dass er alle für das Endprodukt relevanten rechtlichen Anforderungen und alle existierenden Standards berücksichtigt und deren Einhaltung per Review überprüft.

Im Automotive-Bereich existieren u.a. folgende Standards für die Software-Entwicklung:

• ISO 26262 – Road vehicles – Functional safety, Part 6: Product development at the software level,

• ISO 29119 – Software and systems engineering – Software testing,

• IEC 61508-3 – Functional safety of electrical/electronic/programmable electronic safety-related systems, Part 3: Software requirements,

• IEE 829 – Software and system test documentation,

• …

Neben diesen Standards gibt es weitere Vorgaben, die sich im Prozess wiederfinden sollten, da sie eine hohe Sicherheit und hohe Qualität der Software gewährleisten:

• ASPICE,

• MISRA,

• CERT.

ASPICE stellt ein Dokument namens Automotive SPICE Process Assessment / Reference Model zur Verfügung, welches Vorgaben zur Gestaltung des Prozesses macht, die für eine Qualifikation einzuhalten sind. Im Bereich der Codierung ist die Einhaltung des MISRA- oder des CERT-Standards erforderlich (oft ist das auch eine Anforderung des Kunden). Beide definieren eine Untermenge des Sprachumfangs von C, die zu einer Qualitätssteigerung (insbesondere der Softwarequalitätsaspekte der Zuverlässigkeit und Wartbarkeit) in der Software-Entwicklung führt.

Neben verbindlichen Vorschriften sollte der Prozessdesigner aber auch das, was ich den Company flavor nennen möchte, in der Prozessbeschreibung berücksichtigen – die besonderen Spezifika eines Unternehmens, die sich durch eine langjährige Unternehmenskultur herausgebildet und in der Organisationsstruktur niedergeschlagen haben. Diese sind in der Regel nicht formal niedergelegt, sondern müssen durch den Prozessdesigner durch gute Kenntnis der Unternehmenskultur eingebracht werden.

Das Prozessdesign soll unter Zeit- und Kostenaspekten betrachtet werden. Standards sind kostenpflichtig und ein Einarbeiten eines oder mehrerer Prozessdesigner in diese Dokumente ist zeit- und folglich kostenintensiv. Ein grundlegendes und tiefes Verständnis ist notwendig, damit alle verpflichtenden Anforderungen korrekt umgesetzt werden können. Wenn das Ziel ein qualitativ hochwertiger Prozess ist, kann auf diese Arbeit nicht verzichtet werden.

Abbilden des Prozessdesigns

Hier gibt es einen einfachen Ansatz: Man kopiert einfach die relevanten Stellen aus den erwähnten Standards passend zu den jeweiligen Arbeitsschritten und hat einen Prozess. Dieser wird in der Regel so sperrig sein, dass kein Anwender ihn (gerne) nutzen wird. Und der Company flavor fehlt dann natürlich völlig. Also muss man sich etwas mehr Gedanken machen. Die erste Frage ist, wie generisch der Prozess sein soll. Ist er sehr generisch definiert, kann man ihn über eine lange Zeit unverändert verwenden, aber er lässt den EntwicklerInnen auch – möglicherweise unerwünschte – Freiräume. Ist er zu spezifisch, engt er die EntwicklerInnen ein und voraussichtlich viele Änderungen erzeugen einen hohen Pflegeaufwand.

Und ein Prozess ist komplex: Er setzt sich ja nicht nur aus Aktivitäten zusammen, sondern es gibt auch Rollen, die diese Aktivitäten ausführen und Arbeitsprodukte, die sowohl Voraussetzung (Input) als auch Ergebnis (Output) einer Aktivität sind. Begleitet wird der Prozess noch durch Richtlinien (Guidelines), in denen bestimmte Aktivitäten detaillierter erläutert werden (z.B. How to create a Hardware Software interface specification). Und am Ende soll alles noch perfekt zusammenspielen und von den Anwendern verstanden werden. Den kulturellen Aspekt, der bei der konkreten Formulierung der Prozessschritte eine Rolle spielt (deutsches vs. chinesisches vs. indisches vs. amerikanisches Englisch), lasse ich außen vor.

Zentrale Aufgabe des Prozessdesigners ist die Aufteilung der zu berücksichtigenden Aspekte auf die zur Verfügung stehenden Möglichkeiten. Das allein ist schon eine zeitaufwändige Herausforderung. Hinzu kommen aber weitere Probleme, die bewältigt werden wollen.

Beispiel 1:
ISO 26262-6 erwartet unter „7 Software architectural design“ [1] diese Arbeitsprodukte (Work products):

• Software architectural design specification,

• Safety plan (refined),

• Software safety requirements specification (refined),

• Safety analysis report,

• Dependent failures analysis report,

• Software verification report (refined).

„ASPICE Process Assessment Model V3.0” [2] verlangt unter „SWE.2 Software Architectural Design“ folgende Arbeitsprodukte (Output Work Products):

• Software architectural design,

• Communication record,

• Review record,

• Traceability record,

• Interface requirements specification.

Der einfache Ansatz ist auch hier wieder vorhanden: nimm einfach alles. Das Ergebnis ist eine riesige Menge von Arbeitsprodukten, unter denen jedes Projekt in die Knie geht.

Hier muss der Prozessdesigner also geschickt kombinieren und den Prozess so zusammenstellen, dass alle Arbeitsschritte in der richtigen Reihenfolge stattfinden, die passenden Arbeitsprodukte an den richtigen Stellen auftauchen, alle Anforderungen durch Standards wie ISO 26262 erfüllt sind und der Anwender eine klare Richtlinie bekommt. Beim Design des Produktentwicklungsprozesses bei der Hella GmbH & Co. KGaA hat es sich für das Verständnis als hilfreich erwiesen, an Schlüsselstellen Verweise (evtl. mit Erklärungen) auf die umgesetzte Anforderung einzubauen.

Im Rahmen dieses Vortrags betrachten wir nur die Softwareentwicklung, aber es gibt auch Arbeitsprodukte, die domänenübergreifend sind, wie zum Beispiel die Schnittstellen zwischen Hard- und Software. Hier ist der Blick über den Tellerrand erforderlich, damit mehrere Domänen ihre Anforderungen erfüllen können.

Beispiel 2:

Dieses Bild aus der „ISO 26262-4: Road vehicles – Functional safety – Part 4“ [3] zeigt das Zusammenspiel von Hardware-, Software- und Systemdesign für die „Hardware software interface specification (HSI)“. Schließlich spielt es fast nur eine untergeordnete Rolle, ob die Rollen jetzt über ein RASCI-Schema (Responsible, Accountable, Supportive, Consulted, Informed) zugeordnet werden oder über ein DESI-Schema (Decision, Execution, Support, Information). Am Ende ist auch hier wieder offensichtlich, dass viel Zeit (und damit auch Geld) in das Design des Prozesses fließen muss:

• Unstimmigkeiten müssen entdeckt und aufgelöst werden (siehe Beispiel 1) – das ist nur durch einen systematischen Abgleich aller Dokumente (z.B. ISO 26262 vs. ASPICE) möglich und durch fachlich argumentierte Entscheidungen bei der Auflösung von Unstimmigkeiten;

• Effizienz und Akzeptanz müssen gewährleistet sein – es darf kein sklavisches Kopieren von Anforderungen geben; eine sinnvolle Optimierung wie zum Beispiel (siehe unten) die Zusammenführung von Arbeitsprodukten schafft zusammen mit dem Company flavor einen schlanken und handhabbaren Prozess.

Pflege der Prozesse

Für das Prozessdesign gibt es heute Tools (z.B. Stages), welche die Erstellung und Pflege von Prozessen unterstützen. Leider tun sie das nur bei der Darstellung (was allerdings schon eine große Hilfe ist). Die Designarbeit muss trotzdem noch wie oben beschrieben durchgeführt werden. Im Idealfall ist es möglich, die Ergebnisse der inhaltlichen Arbeit parallel im Tool zu dokumentieren und so schnell eine standardisierte Darstellung zu bekommen. Aber ein solches Tool muss natürlich erst gekauft und geschult werden, womit wir wieder bei den Kosten sind.

Diese hören leider auch nicht auf, wenn man den Prozess endlich fertig entwickelt hat. Standards ändern sich, es gibt neue Entwicklungsmethoden oder neue Tools werden angeschafft (auch den Tool-Aspekt haben wir nicht explizit betrachtet), was eine Veränderung bzw. Anpassung des Prozesses erforderlich machen kann. Prozessdesign ist also eine permanente Aufgabe, die mal mehr und mal weniger aufwändig, aber nie zu Ende ist.

Effektiver Nutzen des Prozessmanagements

Während die Kosten für die Prozesserstellung und -pflege (inkl. der Lizenzkosten für ein Prozessvisualisierungstool) sofort ersichtlich sind, lässt sich die „Habenseite“ nur mittelfristig ermitteln. Folgende Kriterien können helfen, die Vorteile der Prozesseinführung transparent darzustellen:

• KPI (Key Performance Indicator);

• Die Auswertung von KPIs kann Hinweise darauf geben, dass die Anwendung von Prozessen zu einer Verbesserung der Kennzahlen geführt hat, zum Beispiel zu kürzeren Entwicklungszeiten: da ein Prozess die Softwareentwicklung in ein Korsett zwingt, kann die Verzahnung und Abhängigkeit verschiedener Aktivitäten zu klareren Abläufen führen und die Entwicklungszeiten (und damit die Kosten) reduzieren;

• Bessere internationale Zusammenarbeit;

• Ein weltweit einheitlicher Prozess führt dazu, dass die Mitarbeiter solcher prozessgeführten Projekte effizient zusammenarbeiten können.

Ein guter Prozess „verdient“ sicher das Geld, was seine Erstellung und seine Pflege kosten. Eine Zeit- und Kostenersparnis zeigt sich aber erst mittel- bis langfristig. So kann es durchaus sein, dass ein erster Einsatz des Prozesses das Projekt sogar teurer macht und sich Ersparnisse erst in Folgeprojekten zeigen.

Nutzen von Prozessmanagement oft erst mittelfristig erkennbar

Das Erstellen eines guten – weil verständlichen, verwendbaren und gewinnbringenden – Prozesses ist mit einem nicht geringen Aufwand verbunden. Viele Informationen müssen gesichtet, aufbereitet und strukturiert werden. Darüber hinaus ist die Arbeit an einem Prozess nie zu Ende. So gesehen ist das Prozessdesign zunächst ein Fluch für den Prozessdesigner und ein Groschengrab. Dem gegenüber steht ein Gewinn, der oft erst mittelfristig entsteht und sich nicht exakt quantifizieren lässt. Ein gut gemachter Prozess ist aber auf jeden Fall ein Segen für ein Unternehmen:

• er erleichtert durch genau Vorgaben, zum Beispiel bezüglich der erwarteten Arbeitsprodukte, die Arbeit der Mitarbeiter;

• er standardisiert durch die Schaffung einheitlicher Vorgaben und Arbeitsschritte die ggf. weltweite Entwicklungsarbeit und reduziert so Transferverluste;

• er optimiert die Arbeit aller Prozessanwender, weil diese klare Arbeitsanweisungen haben und sich nicht um viele formale Details, sondern nur um ihre fachliche Arbeit kümmern müssen.

Und in diesem Fall wird der Prozess dann auch zum Effizienzturbo. „Wenn ich keinen Prozess habe, machen es vielleicht einige richtig; wenn ich einen schlechten Prozess habe, machen es alle falsch.“. Dieses Statement fällt in sich zusammen, wenn ich einen guten Prozess habe, denn dann machen es alle richtig. Und das sollte das Ziel sein.

Der Autor

* Andreas Osterhold arbeitet bei der HELLA GmbH & Co. KGaA in Lippstadt im Bereich „Prozesse, Methoden und Tools“ unter anderem als Prozess-Designer des Software Construction Process. Daneben ist er seit über 10 Jahren Lehrbeauftragter der Hochschule Ostwestfalen-Lippe in Lemgo für verschiedene Fächer (u.a. Datenbanken, Programmiersprachen) im Fachbereich „Elektrotechnik und Technische Informatik“.

Quellenverzeichnis

[1]: ISO 26262 Road vehicles – Functional safety; Part 6: Product development at the software level; ISO 2011
[2]: methodpark: Automotive Spice Process Assessment Model V3.0; Pocket guide
[3]: ISO 26262 Road vehicles – Functional safety; Part 4: Product development at the system level; ISO 2011

Warum Anforderungsmanagement eine lebenslange Verantwortung darstellt

Einfach und iterativ

Praxiserprobte Anforderungsmodellierung

(Dieser Beitrag wurde mit freundlicher Genehmigung des Autors dem Tagungsband des Embedded Software Engineering Kongress 2018 entnommen.)

(ID:45968482)