Ein grafisch orientiertes Prozessmodell unterstützt komplexe Prozessabläufe
Management von Steuergeräte-Software-Entwicklung
Fortsetzung des Artikels von Teil 2
Verwendung des Prozessmodells
Die Erstellung des KM-Plans erfolgt jedoch in der ersten Aktivität, welches wiederum durch die „1“ (Aktivität 1) gekennzeichnet wird. Erfolgt die Erstellung des Artefakts in einem anderen Prozess, so wird zusätzlich zu der Aktivitätsnummer das Kürzel für den referenzierten Prozess angehängt. Ein Beispiel ist in der ersten Aktivität beim Integrations-Verantwortlichen (lila) ersichtlich. Die zu erbringenden Artefakte wurden im Integrationsprozess (IP) in der zweiten und vierten Aktivität definiert. Durch diese Referenzierung erhalten die Prozessbeteiligten einen raschen Überblick über die zu erbringenden Artefakte. Neben den eigentlichen Artefakten wird in der letzten Spalte der Status des entsprechenden Artefaktes definiert. Dadurch wird ersichtlich, ob ein Dokument vor der Auslieferung einer Freigabe unterzogen werden muss oder ob zunächst ein Draft-Status genügt.
Neben der grafischen Prozessbeschreibung existiert auch eine detaillierte Dokumentation, die die einzelnen Aktivitäten erläutert und mit weiteren Informationen versieht. So werden etwa weitere Rollen definiert, die am Prozessgeschehen beteiligt sind, die jedoch keine Inputs liefern und daher im Prozessbild nicht zu sehen sind. Ebenso werden bestimmte Kriterien und QS-Vorgaben an die Artefakte beschrieben. Methoden und inhaltliche Beschreibung einzelner Artefakte sind nicht Bestandteil der separaten Prozessdokumentation.
Das Darstellungsmodell wurde in einem Vorentwicklungsprojekt definiert, optimiert und erprobt. Die Umsetzung des Prozessmodells erfolgte in folgenden Prozessen:
- Konfigurations-Management,
- Änderungs- und Fehlermanagement,
- Release-Planung,
- Review,
- Systemintegration und Systemtest.
Durch eine kontinuierliche Anpassung und Verbesserung der Prozesse wurde der grafische Ansatz in ein bereichsübergreifendes Serienprojekt überführt und projekttechnisch angepasst. Eine gute Prozessqualität konnte mit Hilfe der unabhängigen Qualitätssicherung und der funktionalen Sicherheit erzielt werden. Insbesondere die Verknüpfung zwischen Aktivitäten und den verantwortlichen Rollen, die Nennung der wichtigsten ein- und ausgehenden Artefakte pro Aktivität, die Präzisierung der Aktivitäten durch separate Dokumentation, die abgestimmte und verzahnte Prozesslandschaft und die leichte Erlernbarkeit wurden bei einem internen „SPICE Assessment“ positiv bewertet.
Jobangebote+ passend zum Thema
Die fünf definierten Kernprozesse werden derzeit in einem großen Serienprojekt etabliert und kontinuierlich optimiert. Das Feedback zu den einzelnen Prozessen wird gesammelt und zentral ausgewertet mit dem Ziel, mittelfristig standardisierte und SPICE-konforme Prozesse zu erreichen. Hierfür ist es notwendig, einen abteilungsbzw. bereichsübergreifenden Prozess zu definieren und auf verschiedene Projekte anzupassen. Derzeit werden die Prozesse in anderen Projektstrukturen erprobt, um dort die Handhabbarkeit und den Nutzen der Prozesse zu identifizieren. Weitere Prozesse, z.B. das Lieferanten-Monitoring, sind derzeit in Arbeit. jw
Literatur
[1] Müller, M, Hörmann; K.; Dittmann, L.; Zimmer, J.: Automotive SPICE in der Praxis. dPunkt Verlag, 2007.
[2] Mutz, M.; Scharnhorst, T.; Daginnus, M.: Integration der UML 2.0 in die Anforderungsentwicklung für elektronische Systeme im Kraftfahrzeug. Automation, Assistance and Embedded Real Time Platforms 2006. Braunschweig, 2006.
[3] Jeckle, M.; Rupp, C.; Hanh, J.; Zengler, B.; Queins, S.: UML 2 – glasklar. Hanser-Verlag, 2004.
 | Dr. Martin Mutz studierte Industrieinformatik an der FH Braunschweig/ Wolfenbüttel. Darauf folgte die Promotion an der TU Braunschweig mit dem Schwerpunkt modellbasierte Entwicklung im Automobilbereich. Ab 2005 arbeitete er für die Unternehmen Carmeq GmbH und Airbus Deutschland an den Themen Anforderungsmanagement, modellbasierte Entwicklung und Qualitätssicherung. Seit 2007 ist er wieder bei der Carmeq GmbH in Berlin tätig und beschäftigt sich mit Automotive SPICE-konformen Prozessen in der Serienentwicklung. Martin.Mutz1@carmeq.com |
 | Andre Krampe studierte Elektrotechnik an der Universität Paderborn und an der Nottingham Trent University. Seit 2002 arbeitet er bei der Volkswagen AG und seit 2003 im Bereich der Elektronikentwicklung/ Fahrerassistenzsysteme. Dort beschäftigte er sich mit der Vor- und Serienentwicklung von Fahrerassistenzsystemen. Seit 2007 ist er Projektleiter für die Entwicklung eines komplexen Fahrerassistenzsystems. Andre.Krampe@volkswagen.de |
Die wesentlichen Nachteile der UML-Aktivitätsdiagramme werden hier anhand eines fiktiven Review-Prozesses aufgezeigt. Der Prozessausschnitt in Bild 1 stellt vier verschiedene Rollen dar, die durch „swim lanes“ von einander getrennt sind. Die im Projekt definierten Rollen (Konfigurations-, Qualitätssicherungs- (QS), Integrations- und Funktions-Verantwortliche) sind den prozessspezifischen Rollen „Autor“ und „Reviewer“ zugewiesen. Darüber hinaus besteht in der ersten Aktivität eine weitere Rollenzuordnung. Darin wird explizit auf die Rolle des Prozessverantwortlichen referenziert. Damit kann auf einen weiteren „swim lane“ verzichtet werden.
Der Nachteil liegt in der fehlenden Übersichtlichkeit der Rollenzuordnung. Eine derartige Rollenverteilung führt außerdem zu einer redundanten Aktivitätsauflistung; dies wird in der Aktivität „Dokument reviewen“ deutlich. Schließlich entspricht das Dokument „Review-Befundliste“ als Input für die Review-Aktivitäten nicht ganz der zugehörigen Rolle (Reviewer). Diese ist eher dem QS-Verantwortlichen im Allgemeinen zuzuordnen. Da dieser jedoch gleichzeitig der Reviewer ist, lässt sich die Ressource „Review-Befundliste“ nicht eindeutig zuweisen. Der Verlust der Lesbarkeit durch Überkreuzungen von Verbindungslinien zeigt zudem, das die Umsetzung eines relativ einfachen Sachverhalts hier nicht gelungen ist.
Eine bessere Darstellungsmöglichkeit desselben Prozesses bietet Bild 2. Durch Zusammenschluss von verschiedenen Projektrollen zu einer Prozessrolle wird die Anzahl der „swim lanes“ reduziert, und die Überkreuzungen der Verbindungslinien werden aufgelöst. Eine vernünftige Rollengruppierung bewirkt also eine Optimierung der Prozessdarstellung. Hier stellt sich die Frage, ob eine solche Darstellung den Anforderungen der OEMs in großen Projekten genügt. Eine genauere Analyse des Prozesses in Bild 2 macht folgende Schwächen sichtbar:
- Zur Durchführung eines Reviews sind „Review-Befundlisten“ notwendig, die in diesem Fall über den QSVerantwortlichen zu beziehen sind. Für eine einzige Aktivität einer neuen Rolle muss also ein weiterer „swim lane“ hinzugefügt werden. In vielen Fällen sind die „swim lanes“ nur durch eine einzige Aktivität gekennzeichnet („Dokument reviewen“, „Dokument freigeben“ usw.).
- Die Behandlung eingehender und ausgehender Artefakte (Inputs und Outputs) erfolgt durch ein separates Symbol (z.B. eine „Review-Befundliste“). Dies kann dann die Übersichtlichkeit erschweren, wenn mehrere eingehende Artefakte benötigt werden. Ein Beispiel hierfür ist das Testen, für das unter anderem Testprotokolle, Testberichte, Testspezifikation, Testfälle, Tools usw. für die Ausführungsaktivität eines Testfalls benötigt werden.
- Die erforderliche Gruppierung von Projektrollen (siehe Bild 1) hat den Nachteil, dass in vielen Fällen eine Unterscheidung zwischen dem Verantwortlichen einer Aktivität, den Teilnehmern an einer Aktivität und eventuell den Treibern (diese sorgen dafür, dass Inputs rechtzeitig und vollständig vorliegen) nicht eindeutig erfolgen kann. Bei dem skizzierten Prozess bedeutet dies, dass die Verantwortung für das Review aus dem Prozess nicht eindeutig hervorgeht, da in dem „swim lane“ drei Rollen definiert sind. Eine gemeinsame Verantwortung für eine einzige Aktivität ist weder sinnvoll noch praktikabel. Eine Bitte um das Übermitteln des letzten Protokolls an fünf Teammitglieder endet entweder damit, dass keine Antwort (jeder verlässt sich auf den anderen) oder fünf Antworten gegeben werden.
- Management von Steuergeräte-Software-Entwicklung
- Management von Steuergeräte-Software-Entwicklung
- Verwendung des Prozessmodells
