Startseite > Automotive > Software-Entwicklung nach Automotive-SPICE-Level 2

Halbleiterhersteller

Software-Entwicklung nach Automotive-SPICE-Level 2

11. Oktober 2010, 14:42 Uhr | Stephan Janouch

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 3

Standortbestimmung und Projektanalyse

Method Park nahm als externes Beratungsunternehmen eine Standortbestimmung nach den Bestimmungen der ISO 15504-2 auf Grundlage von Automotive SPICE (PAM V2.2 auf dem HIS Scope) vor. Das Ziel der Standortbestimmung war es, einen Überblick über die Stärken und Schwächen der bislang angewandten Vorgehensweise zu gewinnen. Auf dieser Basis sollte ein Fahrplan für die zukünftige Prozessverbesserung aufgestellt werden. Hierbei wurde auf die folgenden beiden Aspekte großer Wert gelegt:

Der Assessor sollte nicht mit der Person identisch sein, die das Prozess-Verbesserungsprojekt begleitet. Damit wurde eine Unabhängigkeit beim Abschluss-Assessment gewährleistet. Die Bewertung sollte mit besonderem Augenmaß auf die organisatorischen Randbedingungen durchgeführt werden.

Ein Ergebnis des Assessments war, dass aufgrund der reinen Software-Entwicklung die Systemprozesse nicht anwendbar waren. Das bewertete Projekt schnitt für ein erstes Assessment durchschnittlich ab: Von den 15 assessierten Prozessen wurden fünf mit Level 1 bewertet, der Rest mit Level 0.

Auf Basis der Ergebnisse der Standortbestimmung konnte nun ein Method-Park-Berater gemeinsam mit den Mitarbeitern von Renesas die Detail-Planung für das Prozess-Verbesserungsprojekt aufstellen, wobei hier ein leichtgewichtiges, agiles Projekt-Management aufgesetzt wurde (Bild 4).

Für jeden zu verbessernden Prozess wurde ein Prozessbesitzer definiert, der für die Ausgestaltung des Prozesses verantwortlich war, sowie Prozess-Team-Mitglieder, die inhaltlich zu dem Prozess beisteuern sollten. Der Prozess-Sponsor war derjenige Abteilungsleiter des Unternehmens, der monatlich Berichte über den Fortschritt des Projektes erhielt. Aufgrund der Größe der Prozessorganisation wurden die weiteren Verantwortlichkeiten auf der Organisationsebene in Personalunion verteilt: Prozessverantwortlicher, Prozessarchitekt und Projektleiter wurden zum Process Engineer zusammengefasst. Der Process Engineer war für das Prozessdokument und die Koordination des Gesamtprojektes verantwortlich.

In mehreren Workshops wurde der konkrete Prozess erarbeitet, wobei soviel wie möglich vom bereits bestehenden Prozess übernommen werden sollte. Zunächst wurden die Anforderungen an den Prozess zusammengestellt, beispielsweise dass der Prozess anpassbar und zukünftig auf weitere Abteilungen des Unternehmens übertragbar sein soll, der Prozess so leichtgewichtig wie möglich sein soll und so viele Schritte wie möglich im Werkzeug MKS abgebildet werden.

Weiterhin wurden die Anwendungsfälle, die Schnittstellen und die Prozessverantwortlichen festgelegt. Als Entwicklungsstrategie wurde eine iterative Variante des V-Modells ausgewählt.

Alle Workshop-Ergebnisse wurden jeweils von den Prozessbesitzern ausgearbeitet und im Team sowie durch den externen Berater geprüft. Die benötigten Anpassungen an MKS nahm der Prozessverantwortliche vor.

Nun wurden alle Prozesse im Bereich des Prozess-Verbesserungsprojektes nacheinander Schritt für Schritt definiert. Dies geschah ebenfalls in Workshops. Reviews übernahmen die Qualitätssicherung der Prozessbeschreibung. Im Laufe der Prozessdefinition wurde der Umfang aufgrund der Kompatibilität zu anderen organisatorischen Einheiten um das Risiko-Management und das Lieferanten-Management erweitert. Das Konfigurations-Management der Prozessbeschreibung erfolgte im MKS SI. Parallel zu der Ausarbeitung der Prozesse wurde im Hinblick auf die kontinuierliche Prozessverbesserung nach Abschluss des offiziellen Prozess-

Verbesserungsprojektes ein Änderungs-Management definiert und in MKS implementiert.

Nachfolgend wurde der Prozess in den Projekten erprobt. Dabei fiel die Erprobung mit der Einführung zusammen. Sie wurde durch eine Feedback-Runde abgeschlossen. Der Prozess stieß auf große Akzeptanz bei allen Mitarbeitern und bedeutete für die einzelnen Team-Mitglieder keinen besonderen Mehraufwand.