2. Strukturen und Inhalte 2.1 Überblick und Zusammenhänge

Transkript

1 Inhalt Vorwort... 3 Kontakt Automotive SPICE Das Wichtigste in Kürze Die Grundidee und Anwendung von Automotive SPICE Ökonomische Vorteile durch Automotive SPICE Wie führt man Automotive SPICE ein? Typische Fehler und Probleme bei der Einführung Strukturen und Inhalte Überblick und Zusammenhänge Das Automotive SPICE Process Assessment Model Aufbau eines Prozesses Die Automotive SPICE Levels Process Attributes und Generic Practices Wie werden die Levels bestimmt? Welche Automotive SPICE Modellelemente sind wichtig für die Bewertung? Prozesse und gelebte Wirklichkeit wie hängt das zusammen? Automotive SPICE und die Beziehung zu den Geschäftszielen der Organisation Automotive SPICE Umsetzung welche Rolle spielen Entwicklungstools? Die Automotive SPICE Prozesse (HIS Scope) ENG.2 System requirements analysis ENG.3 System architectural design ENG.4 Software requirements analysis ENG.5 Software design ENG.6 Software construction ENG.7 Software integration test ENG.8 Software testing ENG.9 System integration test ENG.10 System testing MAN.3 Project management SUP.1 Quality assurance S. 5

2 3.12 SUP.8 Configuration management SUP.9 Problem resolution management SUP.10 Change request management ACQ.4 Supplier monitoring Traceability in Automotive SPICE Verifikationskriterien in Automotive SPICE Applikationsparameter in Automotive SPICE Assessments Wie funktionieren Assessments? Welche Rollen gibt es bei einem Assessment? Wie laufen Assessments ab? Wie kann man sich auf ein Assessment vorbereiten? Assessments der Organisationsreife der Prozesse (Organizational Maturity Assessments) Beziehung zu anderen Modellen/Vorgehensweisen Unterschiede und Gemeinsamkeiten Automotive SPICE CMMI Beziehung Automotive SPICE zu Funktionaler Sicherheit Automotive SPICE und Agile Zu den Autoren S. 6

3 2. Strukturen und Inhalte 2.1 Überblick und Zusammenhänge ISO/IEC (auch SPICE genannt) stellt ein normatives Framework bereit, aus dem Automotive SPICE abgeleitet wurde. Vereinfacht zusammengefasst bietet dieses: Die ISO/IEC spezifiziert im Teil 2 der Norm Anforderungen, nach denen ein sogenanntes Process Assessment Model wie z.b. das von Automotive SPICE 14 entwickelt werden kann. Ein Process Assessment Model bildet die Beurteilungsgrundlage in einem Assessment. Die ISO/IEC enthält im Teil 5 der Norm ein beispielhaftes Process Assessment Model (siehe Abb. 13). In der Automobilindustrie wird das Automotive SPICE Process Assessment Model genutzt. Bei Bedarf können in einem Automotive SPICE Assessment Prozesse aus Teil 5 zusätzlich genutzt werden. Die ISO/IEC definiert im Teil 2 der Norm die Capability Levels und wie diese Levels gemessen werden. Abb. 13: Die ISO/IEC Prozesse S. 16

4 2.2 Das Automotive SPICE Process Assessment Model Abb. 14 zeigt das Automotive SPICE PAM (Process Assessment Model). In der Assessment Praxis werden meistens die 15 in rot dargestellten Prozesse verwendet (sogenannter HIS Scope, siehe auch Kap. 1.1 Welche Fahrzeughersteller fordern was?). Abb. 14: Die Automotive SPICE Prozesse; in rot dargestellt die am häufigsten verwendeten Prozesse (so genannter HIS Scope) S. 17

5 2.2 Aufbau eines Prozesses Abb. 15 zeigt den Aufbau eines Automotive SPICE Prozesses. Abb. 15: Aufbau eines Automotive SPICE Prozesses Process ID: Eindeutige Bezeichnung des Prozesses, z.b. MAN.3 Process Name: Z.B. Project Management Process Purpose: Kurze Beschreibung des Zwecks des Prozesses Process Outcomes: Eine Liste der Ergebnisse des Prozesses, wenn er erfolgreich implementiert wird Notes: Outcomes können Anmerkungen besitzen, die z.b. Begriffe und Inhalte erläutern. Anmerkungen können auch Forderungen der Outcomes konkretisieren. Base Practices: Die Handlungsempfehlungen eines Prozesses, die dafür sorgen, dass die Outcomes erreicht werden; Sie stehen beim Assessieren eines Prozesses auf Level 1 im Vordergrund. Zwischen Base Practices und Outcomes besteht eine n:m Beziehung. Welche Base Practice welche Outcomes adressiert, ist jeweils in eckigen Klammern angegeben. Der Identifier einer Base Practice wird nach folgendem Prinzip gebildet: <Process ID>.BP<laufende Nummer>, also z.b. MAN.3.BP1, MAN.3.BP2,. Notes: Diese Anmerkungen können bei Base Practices vorkommen. Sie geben dann z.b. Beispiele oder Erläuterungen. Manchmal stellen sie auch detailliertere, zusätzliche Forderungen, z.b.: At minimum, project attributes of resources, effort and schedule (planned, actual and remaining) should be monitored by the project. Output Work Products: Die von einem Prozess erzeugten Output Work Products sind Vorschläge des Modells und werden in einem Assessment nicht per Checkliste abgehakt. Sie besitzen einen Identifier ( WP ID ), einen Namen und eine Referenz auf die für das Output Work Product relevanten Process Outcomes. Beispiel: Risk management plan [Outcome 5] S. 18

6 Abb. 16: Beispiel eines Automotive SPICE Prozesses (Ausschnitt); ((Darstellung wie im Kugler Maag Cie Pocket Guide, siehe Abschnitt 1.1 Automotive SPICE: Entstehung, Herkunft, Rechte, Bezugsquelle, beteiligte Organisationen) Abb. 17: Beispiel der Output Work Products des Prozesses MAN.3 Project Management (Quelle: Automotive SPICE Process Assessment Model v2.5) S. 19

7 2.3 Die Automotive SPICE Levels Zwei verschiedene Arten von Levels Die ursprüngliche und bis heute fast ausschließlich genutzte Art von Levels sind die Capability Levels. Capability Levels drücken einen Reifegrad eines einzelnen Prozesses aus. Hingegen drücken Organizational Maturity Levels den Reifegrad einer Organisation aus. Bedeutung der Capability Levels 0 Incomplete: Ein Prozess ist entweder gar nicht implementiert oder erfüllt nicht den im Prozess beschriebenen Zweck. 1 Performed: Ein Prozess ist implementiert und erfüllt den im Prozess beschriebenen Zweck. Man erreicht dies, indem man die Base Practices des Prozesses umsetzt und entsprechende Arbeitsprodukte erzeugt. 2 Managed: Ein Prozess wird nicht nur durchgeführt, sondern seine Ausführung wird gesteuert (Planung der Prozessaktivitäten, Verfolgung, Korrekturaktionen etc.) und seine Arbeitsprodukte werden gemanaged (Qualitätssicherung und Konfigurationsmanagement seiner Arbeitsprodukte). 3 Established: Es gibt einen Standardprozess, der durch Tailoring an seinen Einsatz im Projekt bzw. in der Organisation angepasst wird. Durch passende Methoden wird die Effektivität und Eignung des Prozesses analysiert und beurteilt. 4 Predictable: Die Organisation kennt den Zusammenhang zwischen den bei der Durchführung der Prozesse gesammelten Kennzahlen (Prozess und Produktparameter) und den geplanten quantitativen Ergebnisparametern des Projekts (z. B. Qualität, Budget oder Termineinhaltung). Durch geeignete Prozessführung können die Ergebnisparameter innerhalb statistischer Grenzen erreicht werden. Die Kennzahlen sollen dazu dienen, das Erreichen der Geschäftsziele zu prüfen und zu unterstützen. 5 Optimizing: Der Prozess wird laufend weiter optimiert aufgrund von Änderungsvorschlägen, Innovationen und statistischen Analysen von Daten der Prozessausführung. Abb. 18: Automotive SPICE Capability Levels S. 20

8 Bedeutung der Organizational Maturity Levels Organizational Maturity Levels (OML) wurden erst vor wenigen Jahren in der ISO/IEC definiert. Während die klassischen Zulieferer Assessments sich meistens auf ein einziges Projekt konzentrieren, wird durch diese Organisationsassessments der Blick auf die Organisation ausgeweitet mit einer großen Zahl von Projekten. Schließlich ist es die Organisation, die Projekte in die Lage versetzt, Prozesse effektiv anzuwenden. Durch diese Organisationsassessments kann man also die grundsätzliche Qualitätsfähigkeit und Reife eines Unternehmens beurteilen. Die Grundlage liefert ISO/IEC , die das Konzept des Organizational Maturity Model definiert. Hier ist jedem OML eine Menge von Prozessen zugeordnet (siehe Abb. 19). Bei einem Assessment werden mehrere Prozessinstanzen 15 untersucht. Typen und Klassen Mit den Klassen 1 3 wird festgelegt, wie gründlich in einem Assessment untersucht werden soll. Hier gibt es Vorgaben zu der Anzahl der Projekte, die mindestens in einer Organisation geprüft werden müssen und was für Evidenzen gesammelt werden müssen. Klasse 1 stellt die höchsten Anforderungen. Mit den Typen A D wird die Unabhängigkeit des Assessmentteams von der zu assessierenden Organisation definiert. Typ A ist die höchste Unabhängigkeit, bei der sowohl der Lead als auch die Co Assessoren aus einem unabhängigen Bereich oder Unternehmen kommen müssen. Ein Klasse eins Assessment muss mindestens vom Typ B sein. Ansonsten bestehen zwischen Klassen und Typen keine Zusammenhänge. Abb. 19: Exemplarisches Organizational Maturity Model der ISO S. 21

9 2.4 Process Attributes und Generic Practices Process Attributes Process Attributes beschreiben messbare Eigenschaften von Prozessen und erlauben es, die Capability Levels abzuleiten. Die Capability Levels zwei bis fünf besitzen jeweils zwei Process Attributes, der Capability Levels eins hat ein Process Attribute (siehe Abb. 20). Abb. 20: Capability Levels und zugehörige Process Attributes Abb. 20: Capability Levels und zugehörige Process Attributes Generic Practices Generic Practices detaillieren ein Process Attribute weiter in konkrete Handlungsempfehlungen. Sie werden in einem Assessment intensiv geprüft und bewertet. Anwender haben oft erhebliche Schwierigkeiten bei der Interpretation der Generic Practices im jeweiligen Prozesskontext. Die nachfolgende Übersicht gibt eine kurze Erläuterung zu den Generic Practices bis zu Capability Level drei. PA 1.1 Prozessausführung Der Prozess erzielt seine definierten Ergebnisse. GP 1.1.1: Erziele die Process Outcomes. PA.2.1 Management der Prozessausführung Die Prozessausführung wird konsequent geplant und verfolgt. GP Definiere die Ziele für die Prozessausführung GP Plane und überwache die Prozessausführung hinsichtlich der Erfüllung der ermittelten Ziele GP Regle die Prozessausführung S. 22

10 GP Definiere Verantwortlichkeiten und Befugnisse für die Durchführung des Prozesses GP Ermittle Ressourcen und stelle sie bereit, um den Prozess nach Plan auszuführen GP Manage die Schnittstellen zwischen beteiligten Parteien PA.2.2 Management der Arbeitsprodukte Angemessene Qualitätssicherung und Konfigurationsmanagement für die Arbeitsprodukte des Prozesses wird sichergestellt. GP Definiere die Anforderungen an die Arbeitsprodukte GP Definiere Anforderungen an die Dokumentation und Lenkung von Arbeitsprodukten GP Bestimme, dokumentiere und lenke die Arbeitsprodukte GP Reviewe die Arbeitsprodukte und passe sie an, um die definierten Anforderungen zu erfüllen PA.3.1 Prozessdefinition Ein Standardprozess wird zur Verfügung gestellt, aus dem der projektspezifische Prozess (als definierter Prozess bezeichnet) abgeleitet werden kann. GP Definiere den Standardprozess, der die Entwicklung des definierten Prozesses unterstützt GP Bestimme die Reihenfolge und Interaktionen zwischen Prozessen, sodass sie wie ein zusammenhängendes System von Prozessen arbeiten GP Lege die Rollen und Kompetenzen zur Ausführung des Standardprozesses fest GP Bestimme die benötigte Infrastruktur und Arbeitsumgebung zur Ausführung des Standardprozesses GP Lege geeignete Methoden zur Überwachung der Effektivität und Eignung des Standardprozesses fest PA.3.2 Prozessanwendung Der projektspezifische Prozess wird aus dem Standardprozess abgeleitet und implementiert. GP Entwickle einen definierten Prozess, der die kontextspezifischen Anforderungen bezüglich der Nutzung des Standardprozesses erfüllt GP Weise Rollen, Verantwortlichkeiten und Befugnisse zur Ausführung des definierten Prozesses zu GP Stelle benötigte Kompetenzen zur Ausführung des definierten Prozesses sicher GP Stelle Ressourcen und Informationen bereit, um die Ausführung des definierten Prozesses zu unterstützen GP Stelle eine angemessene Prozessinfrastruktur bereit, um die Ausführung des definierten Prozesses zu unterstützen GP Erfasse und analysiere Daten bezüglich der Prozessausführung, um Eignung und Effektivität des Prozesses nachzuweisen S. 23

11 2.5 Wie werden die Levels bestimmt? Was wird bewertet? Bewertet werden die Process Attributes auf der Grundlage der Bewertung der Assessment Indikatoren (siehe Abb. 21). Aus der Bewertung der Process Attributes werden mithilfe eines einfachen Algorithmus die Capability Levels berechnet. Abb. 22 zeigt die Zusammenhänge. Abb. 21: Assessment Indicators Base Practices: Siehe Erläuterungen bei Kap Output Work Products: Siehe Erläuterungen bei Kap Generic Practices detaillieren ein Process Attribute weiter in konkrete Handlungsempfehlungen. Sie werden in einem Assessment intensiv geprüft und bewertet. Anwender haben oft erhebliche Schwierigkeiten bei der Interpretation der Generic Practices im jeweiligen Prozesskontext. Generic Resources sind Vorschläge des Modells für Ressourcen, Methoden, Tools und Infrastrukturelemente, die in Verbindung mit Generic Practices nützlich sind. Sie werden in einem Assessment nicht per Checkliste abgehakt, sondern haben eher Vorschlagscharakter. Abb. 22: Zusammenhänge der Modellelemente bei der Berechnung der Capability Level; weinrot gekennzeichnet sind Prozessdimensionen, Reifegraddimensionen werden lachsfarben dargestellt. S. 24

12 Wie funktioniert die Automotive SPICE Bewertungsmethodik? In einem Assessment werden für jeden Prozess die Process Attributes mit der nachfolgend aufgeführten vierstufigen NPLF Bewertungsskala bewertet. Die Bewertung der Process Attributes wird aus der NPLF Bewertung der Base Practices und Generic Practices 16 abgeleitet. Die restlichen Assessment Indikatoren werden nicht explizit bewertet. N (Not achieved bzw. nicht erfüllt), entspricht 0 15%. Es gibt keine oder geringe Anzeichen der Erfüllung des definierten Attributs bei dem assessierten Prozess. P (Partially achieved bzw. teilweise erfüllt), entspricht >15 50%. Es gibt einige Anzeichen für eine Vorgehensweise und eine teilweise Erfüllung des definierten Attributs in dem assessierten Prozess. Einige Aspekte der Erfüllung des Attributs können unvorhersagbar sein. L (Largely achieved bzw. überwiegend erfüllt), entspricht >50 85%. Es gibt Anzeichen für eine systematische Vorgehensweise und eine signifikante Erfüllung des definierten Attributs in dem assessierten Prozess. Im assessierten Prozess können einige Schwächen bezüglich des Attributs existieren. F (Fully achieved bzw. vollständig erfüllt), entspricht >85 100%. Es gibt Anzeichen für eine vollständige und systematische Vorgehensweise und eine volle Erfüllung des definierten Attributs in dem assessierten Prozess. Im assessierten Prozess gibt es keine signifikanten Schwächen bezüglich des Attributs. Wie werden die Capability Levels berechnet? Die Ermittlung eines Levels erfolgt in folgenden Arbeitsschritten: 1. Bewertung der Base Practices mit NPLF 2. Ableitung der NPLF Bewertung von GP1.1.1 aus den Bewertungen der Base Practices. Man kann hier in erster Näherung den Mittelwert der Base Practices Bewertungen heranziehen. Da die Base Practices nicht gleich wichtig sind, wird allerdings oft vom Mittelwert abgewichen. 3. Die Bewertung von PA1.1 wird aus der Bewertung von GP1.1.1 übernommen. 4. Für jedes nachfolgende Process Attribute (PA2.1, PA2.2, ) erfolgt die NPLF Bewertung der zum jeweiligen Process Attribute gehörenden Generic Practices. Man kann hier in erster Näherung den Mittelwert der Generic Practices Bewertungen heranziehen. Da die Generic Practices nicht gleich wichtig sind, wird allerdings oft vom Mittelwert abgewichen. 5. Schritt 4 wird wiederholt, bis die für den zu beurteilenden Level notwendigen Process Attributes bewertet sind (Z.B. PA1.1 + PA2.1 + PA2.2 für Capability Level zwei). 6. Der resultierende Capability Level wird nach dem Verfahren in Abb.23 bestimmt. PA1.1 PA2.1 PA2.2 PA3.1 PA3.2 Capability Level 3 F F F L oder F L oder F Capability Level 2 F L oder F L oder F Capability Level 1 L oder F Abb. 23: Benötigte Modellelemente, um einen Capability Level zu erreichen; ein Capability Level ist erreicht, wenn seine zugehörigen Process Attributes mindestens L sind und alle darunter liegenden Process Attributes F sind. S. 25

13 2.6 Welche Automotive SPICE Modellelemente sind wichtig für die Bewertung? Bewertung von Capability Level 1 Wie in Abschnitt 2.6. dargestellt, spielen die Base Practices hier die grundlegende Rolle. Von deren Bewertung wird die Bewertung von GP1.1.1 und PA1.1 abgeleitet. Die Arbeitsprodukte (Output work products) werden nicht explizit bewertet. Steht die Bewertung auf der Kippe zwischen Capability Level 0 und 1, können die Assessoren folgende Überlegungen hinzuziehen: Da die Process Outcomes eine den Base Practices übergeordnete Bedeutung besitzen (siehe Formulierung von GP1.1.1: Achieve the process outcomes ), kann man prüfen, ob Process Outcomes durch Schwächen bei Base Practices beeinträchtigt wurden. Dies kann insbesondere dann der Fall sein, wenn ein Prozessergebnis nur durch eine einzige Base Practice unterstützt wird und diese Base Practice Schwächen besitzt. Andere Process Outcomes werden eventuell durch mehrere Base Practices unterstützt, so dass sich einzelne Schwächen nicht so stark auswirken. Dem übergeordnet ist der Process Purpose (siehe Formulierung von PA1.1: the extent to which the process purpose is achieved ). Der Process Purpose betont meistens bestimmte Aspekte, so dass einzelne Process Outcomes bzw. Base Practices mehr Gewicht bekommen. Bewertung von Capability Level 2 und höher Hier spielen die Generic Practices die zentrale Rolle. Von deren Bewertung wird die Bewertung der Process Attributes abgeleitet. Die Generic Ressources spielen in der Praxis bei der Bewertung keine explizite Rolle. Steht die Bewertung auf der Kippe zwischen zwei Capability Levels, kann man die Formulierung des betreffenden Process Attribute mit den Formulierungen der Generic Practices vergleichen und unterschiedliche Gewichtungen der Praktiken bei der Process Attribute Bewertung berücksichtigen. Zusammenfassend ergibt sich die in Abb. 24 gezeigte Bedeutungshierarchie. Abb. 24: Bedeutungshierarchie der Modellelemente S. 26

14 2.7 Prozesse und gelebte Wirklichkeit wie hängt das zusammen? Produkt Entwicklung bei Automobilzulieferern ist heute geprägt durch eine hochkomplexe, unternehmensübergreifende Vernetzung vieler, global verteilter Entwicklungseinheiten. Die typische Wirklichkeit In vielen Unternehmen halten die historisch gewachsenen Beschreibungen der Abläufe zur Produktentwicklung nicht Schritt mit den zahlreichen Anpassungen an geänderte Arbeitsweisen und Entwicklungstechnologien. Das Resultat Das Resultat sind meist unzureichend gepflegte Prozesse, die so nicht mehr passen. Die Entwickler verwenden oft eigene ad hoc Abläufe, die im Vergleich zu standardisierten und optimierten Unternehmensprozessen weniger Effizienz und Qualität besitzen und höhere Risiken mit sich bringen. Prozessreifegrade, die es nicht mehr gibt Nicht selten wurden vor Jahren mit den damals definierten Standard Prozessen erfolgreich Assessments absolviert und Prozessreifegrade erzielt. Seitdem wurde aber nicht mehr ausreichend in die Prozessweiterentwicklung, sowie die Anpassung an und den Transfer in die Projekte investiert. Falls Standard Prozesse heute verwendet werden, dann oft nur halbherzig und unter äußerem Druck, z.b. im Zuge einer Assessment Vorbereitung. Wie kann man diesen Zustand verhindern? Die folgenden Punkte können helfen, diesen Zustand zu verhindern: Prozesse müssen permanent gepflegt und weiterentwickelt werden. Die Motivation für Prozesse hat weniger mit dem gewünschten Level zu tun, sondern mit dem Nutzen für das Unternehmen. Prozesse sollten einen erkennbaren Beitrag zu den Zielen eines Unternehmens leisten, z.b. bezüglich Kosten, Zeit und Qualität. Prozesse sollten praxisnah und realistisch gestaltet werden. Sie sollten die besten und erprobtesten Praktiken des Unternehmens widerspiegeln. Prozesse dürfen nicht overengineered und zu detailliert sein, sondern vernünftige Freiräume für die Mitarbeiter bieten. Prozesse sollten die organisatorischen Strukturen wiederspiegeln und an diesen ausgerichtet sein. Verwendet man Standardprozesse (Capability Level 3), ist Tailoring sehr wichtig, damit Standardprozesse an den jeweiligen Einsatzzweck angepasst werden können. Weltweit gleiche Prozesse können kontraproduktiv sein. Prozesse müssen den kulturellen Gegebenheiten angepasst werden. Stattdessen sollte der Fokus auf den Schnittstellen liegen und sicher gestellt werden, dass die verschiedenen Standorte gut zusammen arbeiten. Automotive SPICE ist nur eine Richtschnur Automotive SPICE ist ein Modell und keine Sammlung direkt ausführbarer Prozesse. Es stellt prüfbare Grundforderungen an Arbeitsweisen und Arbeitsergebnisse, schreibt aber nicht vor, wie diese im Unternehmen umgesetzt werden sollen. Das ist und bleibt Aufgabe des Unternehmens. Prozesse sind nur dann erfolgreich, wenn sie die von den Anwendern gelebte Wirklichkeit wiederspiegeln. S. 27

15 2.8 Automotive SPICE und die Beziehung zu den Geschäftszielen der Organisation Motivation für die Automotive SPICE Implementierung Die Motivation eines Unternehmens, sich an Automotive SPICE zu orientieren, basiert in den meisten Fällen auf dem Druck der OEMs. Diese fordern von ihren Lieferanten bestimmte Capability Levels in ausgewählten Prozessen sowie eine stetige Verbesserung der Prozess und Produktqualität. Wenn dies die alleinige Motivation bleibt, wird es erfahrungsgemäß schwierig, dauerhaft eine adäquate Prozessreife aufrecht zu erhalten. Die internen Widerstände, die Resistenz einer gestressten Organisation gegen Veränderung und die Kosten der Veränderung sind einfach zu groß. Was hat Prozessentwicklung mit Geschäftszielen zu tun? In der Praxis sind Prozessentwicklung und verbesserungen leider nur selten direkt mit Geschäftszielen verknüpft, wenn man vom Ziel der Erfüllung der OEM Forderung absieht. Es besteht jedoch immer ein Zusammenhang zwischen der Arbeitsweise der Mitarbeiter (repräsentiert durch Prozesse) und den Geschäftszielen. Allerdings wird dieser Zusammenhang meistens nicht bewusst gemacht und genutzt. Zum Beispiel können die Prozesse gezielt optimiert werden, um Entwicklungszyklen zu verkürzen, Kosten zu reduzieren oder die Produktqualität zu verbessern. Prozesse können verschlankt werden, um die Mitarbeiterzufriedenheit zu erhöhen. Oder die Zusammenarbeit in einem großen, verteilt entwickelnden Unternehmen kann durch Vereinheitlichung der Prozesse und Schnittstellenoptimierung verbessert werden. Mit Prozessen einen messbaren Beitrag zu Geschäftszielen leisten Eine wirksame Vorgehensweise ist, in einem gemeinsamen Workshop mit Management und dem Prozessteam Maßnahmen zu definieren, wie durch Verbesserungen in Prozessen ein Beitrag zu Geschäftszielen geleistet werden kann. Dieser Beitrag muss über Kennzahlen (KPI = Key Performance Indicator) mess und verfolgbar gemacht werden. Ein Beispiel zeigt Abb. 25. Abb. 25: Mit Maßnahmen in Prozessen einen gezielten Beitrag zu Geschäftszielen leisten und diesen über KPI mess und verfolgbar machen S. 28

16 2.9 Automotive SPICE Umsetzung welche Rolle spielen Entwicklungstools? Viele Prozesse in Automotive SPICE können durch den Einsatz von Tools unterstützt werden und die Arbeit erheblich erleichtern. Zum Beispiel ist Traceability normalerweise erst durch den Einsatz von Tools effizient umsetzbar. Im Folgenden werden die Bereiche beschrieben, die vom Tooleinsatz am meisten profitieren. Bei der Auswahl von Tools sollten in jedem Fall die Anwender beteiligt werden, möglichst durch eine Evaluierung in der gelebten Praxis. Spezialisierte Tools versus Tools, die den ganzen Lifecycle unterstützen Diesbezüglich kann man zwei Vorgehensweisen in der Industrie beobachten: Einsatz von Tools, die den gesamten LifeCycle unterstützen Vorteile: Der Einsatz von integrierten Lösungen minimiert Toolbrüche und ermöglicht die Verfolgbarkeit (Traceability) von Anforderungen über Design, Codierung und Integration zum entsprechenden Testfall aus einer Hand. Der Austausch von Informationen über verschiedene Abteilungen hinweg ist einfacher. Nachteile: Die Komplexität und Größe dieser Systeme hat ihren Preis. Häufig ist der Anwenderkreis sehr groß und bindet viele verschiedene Abteilungen ein, mit ebenso vielen unterschiedlichen Anforderungen an ihre spezifischen Arbeitsabläufe. Dies führt meist zu strikten Vorgaben seitens der IT Abteilung, die Vorgaben zu Sicherheit, Verfügbarkeit, Datenintegrität, Reduzierung des Schulungsaufwandes und einfacher Wartbarkeit erfüllen muss und daher diese Vielfalt einschränkt. Diese kann zu Unzufriedenheit bei Anwendern führen, die dann auf eine für die eigenen Abläufe maßgeschneiderte Werkzeugkette auszuweichen versucht. Einsatz von Tools, die auf spezielle Aufgaben zugeschnitten sind Vorteile: Erlaubt eine auf die Aufgabe zugeschnittene, kostengünstige Lösung, die meist gute Performance und Flexibilität bietet. Diese Tools können in der Regel schnell angeschafft, auf die spezifischen Bedürfnisse maßgeschneidert und installiert werden, ohne langwierige Genehmigungswege und Budget Diskussionen. Nachteile: Da mehrere Tools eingesetzt werden, sind Toolbrüche nicht zu vermeiden. Dies ist z.b. bei der Realisierung von bilateraler Traceability von Nachteil und erfordert zum Teil Anpassungen durch eigene Programmierung. So oder so: Tools müssen auch auf die Bedürfnisse der Organisation angepasst werden. Oft findet man teure Tools mit einer Off the shelf Konfiguration, die dann zu ineffizienten Workarounds durch die Entwickler führen Anforderungsmanagement In der Automobilindustrie ist DOORS als Standardwerkzeug im Einsatz, häufig auch für das Testmanagement. Dabei wird fast immer ein zusätzlicher File Server zur Datenhaltung von Dokumenten eingesetzt, die nur schwer oder gar nicht in DOORS verwaltet werden können und aus anderen Werkzeugumgebungen stammen. Unterstützt werden eindeutiges Identifizieren, Priorisieren und Kategorisieren von Anforderungen Aufbau der bilateralen Traceability zu System, Test und Design Anforderungen und Verifikationskriterien Versionierung und Historie zu Einzelanforderungen (Wer hat warum zu welchem Zeitpunkt eine Anforderung geändert?) S. 29

17 Bilden von Baselines und Baseline Sets; allerdings bezieht sich dies nur auf DOORS Module. Auf den File Server ausgelagerte Dokumente sind nicht Bestandteil einer solchen Baseline. Zunehmend werden auch weitere Werkzeuge eingesetzt, die hauptsächlich Traceability unterstützen. Bei diesen können Anforderungen beispielsweise in üblichen Office oder Grafikpaketen erstellt werden, wobei frei definierbare Markierungen (Tags, Labels) zur Kennzeichnung von Anforderungen neben nativen Formatierungsattributen verwendet werden können. Die Dokumente werden per Importfunktion in einer Datenbasis abgelegt und die Traceability über verschiedenste Dokumentenformate hinweg aufgebaut. Toolbrüche können so vermieden werden. Konfigurationsmanagement Eines der wichtigsten Werkzeuge bei der Verwaltung von Arbeitsprodukten sind Konfigurationsmanagement Systeme. Bei den Werkzeugen, die den gesamten LifeCycle unterstützen, ist diese Funktion zusammen mit der Versionierung verschiedenster Arbeitsprodukte für jeden Prozess automatisch verfügbar. Konfigurations und Versionsmanagement sind insbesondere für die Verwaltung von Arbeitsprodukten der Engineering Prozesse notwendig. Besondere Bedeutung kommt den Werkzeugen zur Source Code Verwaltung und dem Build Management zu. Unterstützt werden dabei Baselining und Versionierung der einzelnen Source Files, Binary Executables, Konfigurationsfiles, Betriebssystem, Compiler und Libraries. Aus den oben genannten Systemteilen muss das erzeugte Softwaresystem identisch reproduziert werden können. Ferner werden Branching und Merging unterstützt, um z.b. parallele Entwicklungen für verschiedene Kundenversionen zu ermöglichen. Meist eignen sich die verwendeten Tools dann nicht für reines Dokumentenmanagement. Hier gibt es speziell auf Dokumentenverwaltung ausgerichtete Werkzeuge, die auch Langzeitarchivierung unterstützen. Eine Besonderheit in der Automobilindustrie besteht darin, dass die Entwicklung in verschiedenen Disziplinen (z.b. Hardware, Mechanik und Software) gleichzeitig stattfindet. Somit werden mehrere Systeme gleichzeitig für die Verwaltung von CAD Daten der Mechanik, Layout und Stromlaufpläne in der Hardware, das oben genannte Build Management und die Verwaltung von Source Code benötigt. Für das disziplinübergreifende Baselining gibt es meist folgende Lösungen: Bilden lokaler Baselines in den verschiedenen Tools; die IDs der lokalen Baselines werden in einer Tabelle unter einer globalen ID zusammengefasst. Bilden lokaler Baselines in den verschiedenen Tools; die IDs der lokalen Baselines werden in einem der Tools (meistens dem Tool des Software Teams) erfasst und zu einer Baseline zusammengefasst. Fehler und Änderungsmanagement Für die Prozesse SUP.9 und SUP.10 wird häufig ein gemeinsames Tool verwendet. Diese Funktionalität beherrschen Tool Suiten ebenso wie Open Source Tools. Letztere bieten meist kostengünstige und flexible Lösungen. Die meisten der Fehler und Änderungsmanagement Tools werden in der Entwicklung angewendet. Im Sinne von kontinuierlicher Verbesserung eines Produktes kann es auch sinnvoll sein, Feldfehler zu erfassen und eine entsprechende Auswertung bzgl. der Fehlerursachen zu ermöglichen. Seit Einführung des Sicherheitsstandards ISO kommt der Dokumentation und Bewertung von Fehlern und Änderungen mittels einer Impact Analyse größere Bedeutung zu. S. 30

18 Testmanagement Werkzeuge zur Unterstützung von Testprozessen decken oft die Traceability zum gesamten linken Zweig des V Modells ab. Die Erstellung und Verwaltung von Testfällen werden vereinfacht und die Automatisierung von Testfällen wird unterstützt. Dennoch sind insbesondere auf Systemebene rein auf den Anforderungen basierte Testfälle nicht ausreichend. Der Grund hierfür liegt darin, dass große Mengen von Standardtests nicht auf konkret definierten Anforderungen beruhen, sondern über Jahre hinweg aus der Erfahrung vieler Testfahrer und Testfahrten entstanden sind (typisch für Motorsteuerungen und Chassis Control). Für White Box Tests auf Unittest Ebene sind meistens spezielle Tools notwendig. Diesen Tools kommt seit Einführung der ISO größere Bedeutung zu, da Testtiefe und abdeckung in Abhängigkeit vom ASIL Level (z.b. für ASIL D Units 100% MCDC Abdeckung) ohne Tools schwer nachzuweisen sind. Modellbasierte Entwicklungswerkzeuge In der Automobilindustrie werden oft Werkzeuge eingesetzt, die es ermöglichen, modellbasiert zu entwickeln und den zugehörigen Code mittels Codegenerierung zu erzeugen. Praktiken der Prozesse Software Requirements Analysis (ENG.4), Software Design (ENG.5) und Software Construction (ENG.6) werden unterstützt. Allerdings ist es manchmal nicht möglich, generierten Code einzusetzen, insbesondere bei hardwarenahen Programmteilen wie Treibern. Hier muss oft handkodierter Code eingebunden und auf Codeerzeugung verzichtet werden, um den zur Verfügung stehenden Speicher optimal ausnutzen zu können. Die Ausprägung der Anwendung modellbasierten Entwickelns umfasst von gering bis umfassend alle Möglichkeiten. Optimale Unterstützung ist dann gegeben, wenn beispielsweise Konfigurationsmanagement oder Traceability im eingesetzten Werkzeug genutzt werden können, um große Toolbrüche zu vermeiden. S. 31