Klaus Bender (Hrsg.) Embedded Systems - qualitatsorientierte Entwicklung

Transkript

1 Klaus Bender (Hrsg.) Embedded Systems - qualitatsorientierte Entwicklung

2 Klaus Bender (Hrsg.) Embedded Systems - Entwicklung Mit 66 Abbildungen Q - Springer

3 Professor Dr.-Ing Klaus Bender Technische Universitat Miinchen LS Informationstechnik im Maschinenwesen (itm) Boltzmannstr Garching Bibliografische Information der Deutschen Bibliothek Die deutsche Bibliothek verzeichnet diese Publikation in der deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet uber < abrufbar. ISBN Springer Berlin Heidelberg New York Dieses Werk ist urheberrechtlich geschutzt. Die dadurch begrundeten Rechte, insbesondere die der Ubersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfil~nung oder Verviefaltigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfaltigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulassig. Sie ist grundsatzlich vergutungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de Springer-Verlag Berlin Heidelberg 2005 Printed in The Netherlands Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Buch berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten waren und daher von jedermann benutzt werden durften. Sollte in diesem Werk direkt oder indirekt auf Gesetze,Vorschriften oder Richtlinien (z.b. DIN, VDI, VDE) Bezug genommen oder aus ihnen zitiert worden sein, so kann der Verlag keine Gewahr fur die Richtigkeit, Vollstandigkeit oder Aktualitat ubernehmen. Es empfiehlt sich, gegebenenfalls fur die eigenen Arbeiten die vollstandigen Vorschriften oder Richtlinien in der jeweils giiltigen Fassung hinzuzuziehen. Einbandgestaltung: ~nedionet AG, Berlin Satz: Digitale Druckvorlage des Autors Herstellung: medionet AG, Berlin Gedruckt auf saurefreiem Papier

4 Inhalt Einführung 1 Handbuch 5 1 Wandel der Produkte und Prozesse Von mechanischen zu mechatronischen Produkten Neue Herausforderungen an die Entwicklung Besonderheiten eingebetteter Software Anforderungen der eingebetteten Software an die QS 9 2 Grundlagen der Qualitätssicherung Begriffsdefinitionen Ansätze zur Qualitätssicherung Produktnorm ISO Prozessnorm ISO Reifegradmodelle 14 3 Systematisierung von Entwicklungsprozessen Anforderungen an Vorgehensmodelle Erfüllen etablierte Prozesse diese Anforderungen? Softwaretechnik Mechanik Elektronik Schlussfolgerung Das 3-Ebenen-Vorgehensmodell Aufbau des 3-Ebenen-Vorgehensmodells Einsatz des 3-Ebenen-Vorgehensmodells bei der Entwicklung mechatronischer Systeme 48 4 Systematisierung von Qualitätssicherungsmaßnahmen 51

5 VI Inhalt 5 Methodik des virtuellen Funktionstests Prinzip und Begrifflichkeit Ausprägungen im Entwicklungsprozess Umsetzung des virtuellen Funktionstests Fazit und Bewertung 63 Leitfaden 65 6 Bestandsaufnahme bei den Projektpartnern Vorgehensweise Die Elemente der Prozessbeschreibung Der Dokumentenplan Ergebnisse und Bewertung Liste von QS-Maßnahmen Liste von Dokumenten Anmerkungen zur Bestandsaufnahme 76 7 Auswahl von QS-Maßnahmen Rahmenkonzept der Entscheidungsunterstützung Profilbasiertes Entscheidungsmodell Kategorisierung der Merkmale Auswahlmethodik Nutzen der Entscheidungsunterstützung Vorgehensweisen zur Anwendung der Entscheidungsunterstützung Zusammensetzung der Expertengruppe Vorgehensweise zur Definition von Profilen Bestimmung relevanter Merkmale Beschreibung von Merkmalen Vorgehensweise zur Beschreibung von Profilen Beschreibung von Entwicklungsprofilen Beschreibung von QS-Anforderungsprofilen Beschreibung von QS-Maßnahmenprofilen Verwendung und Anpassung des Entscheidungsmodells Anwendung von QSM in der Praxis Änderungsmanagement Anforderungsverfolgung Defect Management Fehler-Möglichkeits- und Einflussanalyse (FMEA) Funktionstest Nutzung eines Phasenmodells (V- Modell) 146

6 Inhalt VII 8.7 Objektorientierte Analyse und Design mit UML Regressionstest (1) Regressionstest (2) Review-Techniken Risikomanagement Softwareänderungs-Management Die Einführung von QSM in einzelnen Unternehmen Anforderungs- und Defect-Management Simulation zu Testzwecken Prozessdefinition mit dem project>kit Modellbasierter Funktionstest regelungstechnischer Software Virtueller Funktionstest von PROFIBUS-Komponenten Fundamentales Modellierungskonzept (FMC) Optimierung des Entwicklungsprozesses Best-Practice-Empfehlungen für die Auswahl von QSM Anforderungen System-Design Realisierung Systemintegration- und test Projektmanagement 287 Anhang 295 QS-Maßnahmenkatalog 297 Analytische QS-Maßnahmen 297 Konstruktive QS-Maßnahmen 318 Organisatorische QS-Maßnahmen 333 Literatur 357 Glossar 363

7 Autoren Prof. Klaus Bender, Lehrstuhl itm, TU München Sven Dominka, Lehrstuhl itm, TU München Dr. Ali Koç, SIEMENS AG CT SE 1 Martin Pöschl, Lehrstuhl itm, TU München Marc Russ, Lehrstuhl itm, TU München Benno Stützel, Lehrstuhl itm, TU München Co-Autoren Dr. Thomas Cord, ELAU AG Dr. Detlef Fehrer, SICK AG Reiner Grübmeyer, INOVA Computers GmbH Gabor Hahn, Validas AG Dr. Roland Hecker, Wiege- und Positioniersysteme GmbH Peter Jack, Lehrstuhl itm, TU München Clemens Jung-Diefenbach, Endress+Hauser GmbH+Co. KG Dr. Jan Philipps, Validas AG Dr. Oscar Slotosch, Validas AG Dr. Jürgen Schmied, method park Software AG Michael Schütte, Lenze Drive Systems GmbH Carsten Tauss, Institut für Informatik - Lehrstuhl IV, TU München Alexander Ziegler, Institut für Informatik - Lehrstuhl IV, TU München

8 Einführung In vielen technischen Produkten erfolgt eine permanente Verlagerung der Produktfunktionalität in Richtung Software. Dies hat große Auswirkungen auf die Entwicklungsprozesse, die sich diesem Trend permanent anpassen müssen. Nur so können Entwicklungszeiten und -kosten minimiert und ein verlässliches hohes Qualitätsniveau erreicht werden, was Voraussetzung zur Sicherung eines beständigen wirtschaftlichen Erfolgs ist. Moderne Entwicklungs-Prozesse müssen dazu die präventive Fehlervermeidung fördern, insbesondere aber auch Maßnahmen für die möglichst frühzeitige Fehlererkennung und -beseitigung vorsehen. Dies ist gerade bei mechatronischen Produkten mit ihrer hohen Entwicklungsdynamik, Komplexität und Technologievielfalt eine neue Herausforderung. Eine zeitgemäße Qualitätssicherung muss jedoch alle vorhandenen Barrieren sowie Zielkonflikte in Einklang bringen und auf der Grundlage der bereits vorhandenen Methoden- und Werkzeugvielfalt einen integrativen und vor allem qualitätsorientierten Entwicklungsprozess ermöglichen. Dies ist immer eine firmenspezifische Aufgabe und muss individuell geleistet werden. Dabei muss ein Kompromiss zwischen der geforderten Qualität und den wirtschaftlich-technischen Restriktionen gefunden werden. Die Qualitätssicherung muss dazu den unternehmens- bzw. projektspezifischen Bedarf in den Mittelpunkt rücken, was sich u.a. bei der Auswahl, Ausgestaltung und Anwendung geeigneter Techniken, Methoden und Werkzeuge spiegeln muss. Zur Bewältigung dieser fortwährenden und herausfordernden Aufgabe will dieses Buch einen praxisorientierten Beitrag zur Unterstützung leisten. Es richtet sich dazu gleichermaßen an Projektleiter, QS-Beauftragte und Entwickler im Umfeld der Entwicklung softwareintensiver technischer Produkte. Entscheidungsträger können bereits beim Lesen der ersten Kapitel einen Überblick über die später aufgeführten Detailinformationen gewinnen. Das Buch ist vornehmlich auf die Bedürfnisse von KMU zugeschnitten und behandelt die konkrete Anpassung und Umsetzung von QS- Maßnahmen in diesen Unternehmen. Die diesbezüglichen Informationen

9 2 Einführung und Erfahrungsberichte stammen aus dem Forschungsprojekt EQUAL 1, welches vom Bundesministerium für Bildung und Forschung gefördert und 2004 abgeschlossen wurde. Durchgeführt wurde das Projekt von einer Gruppe mittelständischen Unternehmen des deutschen Maschinen- und Anlagenbaus, von Dienstleistungsunternehmen sowie Lehrstühlen der Technischen Universität München. Mit diesem Hintergrund enthält dieses Buch die wichtigsten Ergebnisse und Erkenntnisse, die in den insgesamt 42 Monaten Projektlaufzeit in der Praxis erzielt werden konnten. Im Einzelnen waren folgende Unternehmen im Projektkonsortium zusammengeschlossen: Endress und Hauser, Elau, Inova Computers, Lenze, method park, Sick und Validas sowie die assoziierten Partner T-Systems und Wipotek. Auf wissenschaftlicher Seite wurde das Projekt von den Lehrstühlen der Professoren Bender und Broy betreut und koordiniert. Die Gesamtaufgabenstellung wurde innerhalb dreier Arbeitsgruppen bearbeitet, um eine besonders intensive und zeitlich parallele Bearbeitung der unterschiedlichen Teilaspekte zu ermöglichen. Dies waren die Arbeitsgruppen Effiziente Qualitätssicherung, Entwicklungsprozesse und Virtueller Funktionstest. An dieser Stelle gebührt allen beteiligten Unternehmen herzlicher Dank für ihre konsequent offene, intensive und stets konstruktive Zusammenarbeit. Besonders zu erwähnen sind auch die vielen Unternehmen, die in mehreren Arbeitsgruppen gleichzeitig tätig waren, was die Koordination der Arbeitsgruppen untereinander wesentlich vereinfachte und einen schnellen Projektfortschritt sicherstellte. Das vorliegende Buch ist in zwei große Einheiten gegliedert: Im ersten Teil, dem Handbuch (Kapitel 1 bis 5), werden zunächst Methoden, Vorgehensweisen und weitere theoretischen Grundlagen allgemein beschrieben und aufgearbeitet. Dies dient der Konzentration relevanten Wissens für die qualitätsorientierte Entwicklung und ist sozusagen das Fundament für die anschließenden Kapitel. Der zweite Teil, der Leitfaden (Kapitel 6 bis 10), ist durchwegs anwendungsorientiert gehalten und hat zum Ziel, Kenntnisse aus der Praxis für die Praxis zu vermitteln. Damit eignet sich dieser Teil besonders gut als entwicklungsbegleitendes Nachschlagewerk. Kapitel 1 gibt als Einführungskapitel des Handbuchs einen kurzen Abriss über den derzeit anzutreffenden Wandel der Produkte von rein mecha- 1 EQUAL Embedded Quality: Methoden zur Unterstützung der entwicklungsbegleitenden Qualitätssicherung von eingebetteter Software. Gefördert mit Mitteln des Bundesministeriums für Bildung und Forschung (BMBF) innerhalb des Rahmenkonzeptes Produktion 2000 bzw. Forschung für die Produktion von morgen. Betreut vom Projektträger Produktion und Fertigungstechnologien, Forschungszentrum Karlsruhe. Förderkennzeichen 02PP1060. Laufzeit: bis

10 nischen Lösungen zu immer stärker informationstechnisch geprägten Produkten. Kapitel 2 dient der Grundlagenbildung in Bezug auf das Thema Qualitätssicherung. Dazu werden einschlägige Begriffe eingeführt und definiert sowie etablierte Ansätze zur Qualitätssicherung überblicksartig vorgestellt. In Kapitel 3 werden für die betrachtete Domäne Anforderungen an Entwicklungsprozesse formuliert und anschließend auf deren Grundlage eine Bewertung etablierter Vorgehensmodelle durchgeführt. Kapitel 4 definiert ein Schema zur Systematisierung von Qualitätssicherungsmaßnahmen. Das Handbuch endet schließlich mit Kapitel 5, in dem als neue und innovative Qualitätssicherungsmaßnahme der sog. virtuelle Funktionstest vorgestellt wird. Kapitel 6 liefert als erstes Kapitel des Leitfadens eine Bestandsaufnahme angewendeter Qualitätssicherungsmaßnahmen bei den beteiligten Projektpartnern. Ein Rahmenkonzept für die Entscheidungsunterstützung bei der Auswahl von Qualitätssicherungsmaßnahmen wird in Kapitel 7 definiert. Kapitel 8 enthält eine strukturierte Sammlung einer Vielzahl an Qualitätssicherungsmaßnahmen, wie sie bei den beteiligten Industriepartnern zur Anwendung kommen. Damit stellt dieses Kapitel einen wertvollen Erfahrungsschatz bereit, der anderen Unternehmen bei der Auswahl und Anpassung von Qualitätssicherungsmaßnahmen besonders behilflich sein kann. Ähnliches gilt für Kapitel 9, welches Erfahrungsberichte bezüglich der Einführung von Qualitätssicherungsmaßnahmen enthält. Durch die Durchführung von Pilotprojekten konnten beispielhaft Probleme und Wirkung neu eingeführter Qualitätssicherungsmaßnahmen erfasst werden. Die Dokumentation wurde direkt von den beteiligten Industriepartnern erstellt. Dabei war es vornehmlichstes Ziel, die praxisrelevanten Kriterien in den Vordergrund zu stellen. Der Leitfaden endet mit Kapitel 10, welches in Form von Best Practices auf der Grundlage typischer Problembeschreibungen eine Empfehlung zur Anwendung bestimmter QS-Maßnahmen ausspricht. In Anhang findet sich eine unfangreiche Sammlung ausgewählter Qualitätssicherungsmaßnahmen in Form von QSM-Datenblättern, in der die Maßnahmen jeweils auf einer Seite kurz beschrieben werden. Dabei sind jeweils auch Verweise auf Quellen mit detaillierten Informationen zu finden. Zusammen mit dem Glossar ergibt sich dadurch ein nützliches Nachschlagewerk. 3

11 Handbuch

12 1 Wandel der Produkte und Prozesse 1.1 Von mechanischen zu mechatronischen Produkten Der Maschinenbau und seine artverwandten Disziplinen Fahrzeugtechnik, Feinmechanik und Automatisierungstechnik befinden sich momentan in einem entscheidenden technologischen Wandel: Die Mechatronik hält Einzug in die Erzeugnisse des Maschinenwesens und übernimmt mehr und mehr Aufgaben, die bisher klassisch durch mechanische Lösungen verrichtet wurden. Hierbei steuern die Disziplinen Mechanik, Elektrotechnik und Informationstechnik (IT) jeweils ihren Anteil zur Funktionserfüllung bei. Unter IT wird in diesem Buch die Elektronikhardware und vor allem die darauf ablaufende, funktionserbringende Software verstanden [70]. Durch den Einsatz der Mechatronik werden neue Prinziplösungen im Maschinenbau möglich, die das Kosten/Nutzen-Verhältnis heutiger Produkte erheblich verbessern können. Dies kann unter anderem auf den enormen und stetig wachsenden Preis-Leistungsvorteil mikroelektronisch gesteuerter Mechatronik-Produkte gegenüber konventionell elektromechanisch gesteuerten Erzeugnissen zurückgeführt werden. Die besonders ausgeprägte Flexibilität der Software ermöglicht, vorhandene Fehler in der Mechanik oder der Hardware durch eine Anpassung der Software kostengünstig und schnell zu beseitigen. Aber nicht nur Verbesserungen heute bekannter Produkte werden durch die Mechatronik stimuliert, sondern auch neue, heute noch nicht bekannte Produkte werden auf den Weg gebracht [30]. Dieser Trend wird auch durch viele Aussagen der Industrie bestätigt. Umfragen haben ergeben, dass 90 Prozent der echten Innovationen (im Unterschied zu Detailverbesserungen) in der Maschinenbaubranche im Bereich der Informationstechnik realisiert werden. Dies spiegelt sich auch in der Aussage des Chipherstellers Philips wieder, dass noch in dieser Dekade der Anteil Software/Hardware an den Automobilherstellkosten von 20 auf 40 Prozent ansteigen wird. Ein weiteres Anzeichen für die Etablierung der Software als eigenständige Domäne belegt die Verschiebung der Wertschöpfungskosten der Produkte. Bei hochwertigen Fahrzeugen liegt diese bereits bei 35 Prozent Tendenz steigend [31].

13 8 1 Wandel der Produkte und Prozesse Dies hebt noch einmal den hohen Stellenwert der Elektronik hervor und zeigt, dass vor allem die Software als Funktionserbringer für die Sekundärbranchen (Maschinenbau, Fahrzeugbau, Elektrotechnik, etc.) zunehmend die Rolle eines Business-Enablers einnimmt [11]. 1.2 Neue Herausforderungen an die Entwicklung Obgleich die Software eine so gewichtige Rolle für mechatronische Systeme und somit für die Unternehmen inne hat, wird die Softwareentwicklung im Rahmen der Entwicklung des mechatronischen Gesamtsystems sowohl in der Praxis als auch in der Literatur eher vernachlässigt. Die heute eingesetzten und gelebten Produktentwicklungsprozesse setzen meist den Fokus auf die Entwicklung der Mechanik bzw. der Hardware und berücksichtigen die Software-Sicht nur unzureichend bzw. gar nicht. Bei diesen Entwicklungsvorgehen wird die Softwareentwicklung als nachgelagerte Problemstellung angesehen, die im Anschluss an die Fertigstellung der Mechanik angegangen wird. Eine Systematische Vorgehensweise für die Softwareentwicklung wird dabei in den seltensten Fällen zu Grunde gelegt. Da aber mit steigendem Softwareanteil eine Schwerpunktverlagerung in der Produktentwicklung Richtung Softwareentwicklung zu verzeichnen ist, muss dieser auch Rechnung getragen werden. Ein Beleg für die Schwerpunktverlagerung in Richtung Softwareentwicklung ist bei der Produktentwicklung im Bereich der Automatisierungstechnik und des Maschinenbaus anzutreffen. In diesen Branchen entfallen, insbesondere im Bereich der Kleinserien und der Unikate, zwischen 25 und 75 Prozent der Entwicklungsaufwendungen auf die in den Produkten enthaltene Software. Daraus lässt sich ein zwingend notwendig werdender Wandel in der Ausrichtung der Entwicklungsprozesse ableiten, um die Softwareentwicklung von Entwicklungsbeginn an einzubinden und zu unterstützen. So wird eine gute Ausgangsbasis für eine qualitätsorientierte Entwicklung geschaffen, bei gleichzeitiger Verkürzung der Entwicklungszeit. Nur wenn ein Unternehmen des produzierenden Gewerbes schnell genug entwickelt und vor dem Wettbewerb mit dem neuen innovativen Produkt am Markt ist, wird sein Name am Markt mit dem Know-how und der Innovation verbunden. Der Entwicklungsprozess avanciert also zu einem wettbewerbsbestimmenden Faktor [42].

14 1.3 Besonderheiten eingebetteter Software Besonderheiten eingebetteter Software Ein wesentlicher Unterschied bei der Entwicklung von reiner PC-Software zu eingebetteter Software liegt in der Verwendung verschiedener Hardware-Zielplattformen. Ist bei klassischer PC-Software nur ein PC- System von der Stange mit standardisierten Schnittstellen erforderlich wobei sich der Entwicklungsschwerpunkt nahezu ausschließlich auf die Software selbst konzentriert sind es bei eingebetteten Systemen aus Kostengründen und aus Gründen der Baugröße individuell sehr unterschiedliche Hardware-Plattformen, die mit eingebetteter Software betrieben werden. Da bei eingebetteten Systemen Software nicht direkt auf dem Zielsystem entwickelt werden kann, findet die Programmierung hier auch auf einem herkömmlichen PC statt. Die Software muss dann später auf das Zielsystem portiert werden. Zwischen der Entwicklungs- und der Zielplattform existieren aber einige gravierende Unterschiede, die von unterschiedlichem Zeitverhalten bis hin zu unterschiedlichen Befehlen reichen. Um möglichst genaue Aussagen über die entwickelte Software treffen zu können, wird das Zielsystem auf dem Entwicklungsrechner häufig emuliert. Im Unterschied zu einem Standard-PC sind die Hardware-Ressourcen eines eingebetteten Systems, nicht zuletzt aus Kostengründen, stark begrenzt. Dieser Voraussetzung muss bei der Software-Entwicklung Rechnung getragen werden, was einen hohen Optimierungsaufwand der Software nach sich ziehen kann. Eingebettete Systeme sind häufig verteilte Systeme, bei denen Funktionen im Verbund erbracht werden. Deshalb stellen verteilte Systeme hohe Ansprüche an die Kommunikation zwischen Softwaremodulen. Im Ganzen gesehen läuft eine Entwicklung eingebetteter Software ähnlich einer Standard-Software-Entwicklung ab, aber unter Berücksichtigung der oben genannten Randbedingungen. 1.4 Anforderungen der eingebetteten Software an die QS Der steigende Softwareanteil in der Mechatronik bringt aber nicht nur verbesserte bzw. neue Funktionalitäten in die Produkte, sondern birgt auch Risiken für die Produktivität und Qualität. Mit zunehmenden Softwareumfängen sinkt die Produktivität und die Anzahl der Fehler steigt was gleichbedeutend mit abnehmender Qualität ist. Bei eingebetteten Systemen ist festzustellen, dass sich etwa alle drei Jahre die Leistungsfähigkeit der Hardware hinsichtlich Verarbeitungsgeschwindigkeit und Speicherkapazität verdoppelt. Trotz dieser guten Rahmenbedingungen für die Software-

15 10 1 Wandel der Produkte und Prozesse entwicklung liegt der Zuwachs der Leistungsfähigkeit der Software nur bei etwa 4 Prozent pro Jahr [42]. Die Qualität eines Produktes ist einer der wichtigsten Gründe für die Kaufentscheidung der Kunden. Durch den steigenden Softwareanteil in den Produkten bestimmt die Softwarequalität zunehmend die Produktqualität und besitzt somit einen enormen Einfluss auf den Geschäftserfolg. Die Garantierung hoher Produktqualität wird mit steigendem Softwareanteil problematischer. Dieser Problematik kann nur durch eine systematische Qualitätssicherung, über den gesamten Entwicklungsprozess hinweg, begegnet werden [22]. Sicherheitskritische Anwendungen müssen besonders zuverlässig sein. Jedoch lassen sich etablierte und bewährte Zuverlässigkeitsmodelle aus der Mechanik und Hardware nicht auf softwareintensive Produkte übertragen. Denn solche Modelle betrachten nur Ausfälle, Entwurfsfehler werden vernachlässigt. Software hat keine Abnutzung, bei ihr liegen ausschließlich Entwurfsfehler vor. Zur Erhöhung der Software-Zuverlässigkeit werden unter anderem Techniken wie Watchdogs, Plausibilitätschecks, Monitoring oder das Zurückführen von Eingängen genutzt. Wesentlich wichtiger ist jedoch die systematische Vermeidung von Fehlern im Entwicklungsprozess durch Anwendung adäquater Methoden. Beispielsweise empfiehlt die Norm IEC unterschiedliche Methoden für verschiedene Sicherheitsklassen [42]. Es zeigt sich deutlich, vor welch entscheidender Wendung der Maschinenbau und seine artverwandten Disziplinen stehen. Das Forschungsprojekt EQUAL hat sich den skizzierten Herausforderungen angenommen und sie in den drei Themengruppen effiziente Qualitätssicherung, Entwicklungsprozesse und virtueller Funktionstest bearbeitet. Die Ergebnisse der Themengruppen werden im Folgenden ausführlich vorgestellt.

16 2 Grundlagen der Qualitätssicherung In diesem Kapitel werden die Grundlagen der Qualitätssicherung beschrieben. Zum einen werden grundlegende Begriffe der Qualitätssicherung eingeführt, zum anderen werden verschiedene Ansätze zur Qualitätssicherung bzw. -steigerung vorgestellt. Mit dem Thema Qualitätssicherung stehen Vorgehensmodelle in engem Bezug, auf diese wird jedoch gesondert in Kapitel 3 Systematisierung von Entwicklungsprozessen eingegangen. 2.1 Begriffsdefinitionen Um ein einheitliches Verständnis über die Inhalte dieses Buches zu erhalten, werden im Folgenden grundlegende Begriffe der Qualitätssicherung definiert. Zunächst wird der zentrale Begriff Qualität eingeführt: Qualität Die Gesamtheit von Eigenschaften und Merkmalen eines Produkts oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse bezieht [19]. Von uneingeschränkter Qualität wird demnach gesprochen, wenn die expliziten und impliziten Anforderungen erfüllt wurden. Ein Qualitätsmangel liegt demnach vor, wenn Anforderungen nicht erfüllt werden. Basierend auf der Definition von Qualität wird der Begriff Qualitätssicherung wie folgt definiert: Qualitätssicherung (QS) Gesamtheit von angemessenen, aufeinander abgestimmten Maßnahmen zur Erfüllung vorgegebener Anforderungen an die Qualität eines Produkts oder Herstellungsprozesses [33]. Der Qualitätsbegriff lässt sich sowohl auf das eigentliche Produkt (Produktqualität), wie auch auf den Entwicklungsprozess, kurz Prozess, anwenden (Prozessqualität).

17 12 2 Grundlagen der Qualitätssicherung Produktorientierte Qualitätssicherung beinhaltet die Prüfung von (Software-) Produkten und Zwischenergebnissen im Hinblick auf vorher festgelegten Qualitätsmerkmalen. Dagegen bezieht sich die prozessorientierte Qualitätssicherung auf den Herstellungsprozess (der Software). [42]. Eine einzelne für die Qualitätssicherung einsetzbare Maßnahme wird als Qualitätssicherungsmaßnahme, kurz QSM, bezeichnet. Qualitätssicherungsmaßnahme (QS-Maßnahme) Maßnahme zur Sicherung von Qualität. Sie beinhaltet eine Handlung oder eine als zusammengehörig verstandene Summe von Handlungen, die der Verwirklichung von Zielen dienen soll. Im engeren Sinne kann eine QS-Maßnahme als Festlegung und Anwendung geeigneter Methoden, Verfahren und Werkzeuge zur Erreichung vorgegebener Ziele aufgefasst werden [19]. Der Einsatz neuer Qualitätssicherungsmaßnahmen bedeutet gerade bei der erstmaligen Einführung einen erhöhten Aufwand. Abhängig davon, wie die Methode eingeführt wird, kann dieser Aufwand durchaus variieren. Gerade für Klein- und Mittelständische Unternehmen (KMU) ist es wichtig, diesen bei der erstmaligen Einführung einer QS-Maßnahme entstehenden Mehraufwand möglichst gering zu halten. Aus diesem Grund liegt ein Schwerpunkt dieses Buches in der effizienten Qualitätssicherung. Effiziente Qualitätssicherung Unter effizienter Qualitätssicherung versteht man in diesem Zusammenhang die Auswahl und den Einsatz von QS-Maßnahmen, die die geforderten Qualitätsanforderungen an das Produkt und den Prozess in einer wirtschaftlichen Weise erfüllen. Wirtschaftlich bedeutet in diesem Zusammenhang, dass nur QS-Maßnahmen ausgewählt werden, deren Aufwand-Nutzen-Verhältnis zu den gegebenen Rahmenbedingungen eines Projekts passen. Die Produktqualität ist eng mit der Prozessqualität gekoppelt. Durch den Einsatz von QS-Maßnahmen kann die Prozessqualität stark verbessert werden. Durch die Verbesserung der Prozessqualität wird wiederum die Produktqualität verbessert. Zur Bewertung der Produkt- und Prozessqualität existieren so genannte Produkt- und Prozessnormen. Während Produktnormen einheitliche Kriterien für die Beurteilung der Produktqualität festlegen, zielen Prozessnormen ausschließlich auf die Überprüfung und Verbesserung des Entwicklungs- und Herstellungsprozesses ab.

18 2.2 Ansätze zur Qualitätssicherung Ansätze zur Qualitätssicherung Im folgenden Kapitel sollen bewährte Ansätze vorgestellt werden, die zur Bewertung und Verbesserung der Produkt- und Prozessqualität dienen. Zuerst werden Beispiele zu einer Produktnorm (ISO 9126) und zu einer Prozessnorm (ISO 9000) gegeben. Weiter werden zwei in der Praxis verbreitete Prozess-Reifegradmodelle vorgestellt, mit Hilfe derer ebenfalls der Entwicklungsprozess bewertet werden kann. Schließlich wird die Bedeutung von Vorgehensmodellen am Beispiel des V-Modells erläutert Produktnorm ISO 9126 In der Produktnorm ISO 9126 werden Merkmale definiert, an Hand derer die Qualität der Software bestimmt werden kann. Insgesamt enthält diese Norm sechs Merkmale, die wiederum in Untermerkmale untergliedert werden. Zur Bestimmung der eigentlichen Qualität müssen die jeweiligen Ausprägungen der Merkmale ergänzt werden (Tabelle 2.1). Tabelle 2.1. Qualitätsmerkmale von Software nach [37] Qualitätsmerkmal Funktionalität Zuverlässigkeit Benutzbarkeit Effizienz Änderbarkeit Übertragbarkeit Untermerkmale Angemessenheit, Richtigkeit, Interoperabilität, Ordnungsmäßigkeit, Sicherheit Reife, Fehlertoleranz, Wiederherstellbarkeit Verständlichkeit, Erlernbarkeit, Bedienbarkeit Zeitverhalten, Verbrauchsverhalten Analysierbarkeit, Modifizierbarkeit, Stabilität, Prüfbarkeit Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit Um die mit Hilfe der ISO 9126 festgelegten Produkteigenschaften (Eigenschaft = Merkmal + Ausprägung) überprüfen zu können, sind in der Norm ISO Bestimmungen zur Prüfung der Erfüllung dieser Eigenschaften festgelegt Prozessnorm ISO 9000 Im Gegensatz zu der Produktnorm ISO 9126 werden bei Prozessnormen ausschließlich die Qualität des Entwicklungsprozesses betrachtet. Das dabei entstehende Produkt liegt nicht im Fokus. Einer der bekanntesten

19 14 2 Grundlagen der Qualitätssicherung Vertreter von Prozessnormen ist die ISO 9000-Normenreihe. Der Fokus dieser Normenreihe liegt nicht ausschließlich auf der Software- Entwicklung, sondern betrachtet die Qualität von Entwicklungs- und Herstellungsprozessen von materiellen und immateriellen Produkten allgemein. Tabelle 2.2 gibt einen Überblick über die ISO 9000-Normenreihe. Tabelle 2.2. Struktur der ISO 9000-Normenreihe Bezeichnung ISO 8402 ISO ISO ISO ISO ISO 9001 ISO 9002 ISO 9003 ISO 9004 ISO Titel Qualitätsmanagement und Qualitätssicherung Begriffe Leitfaden zur Auswahl und Anwendung Allgemeiner Leitfaden zur Anwendung von ISO 9001, ISO 9002 und ISO 9003 Leitfaden zur Anwendung von ISO 9001 auf Software Leitfaden zum Management von Zuverlässigkeitsprogrammen Qualitätsmanagementsysteme Modell zur Darlegung des Qualitätsmanagement in Design/Entwicklung, Produktion, Montage, Endprüfung und Wartung Qualitätsmanagementsysteme Modell zur Darlegung des Qualitätsmanagement in Produktion, Montage, Endprüfung und Wartung Qualitätsmanagementsysteme Modell zur Darlegung des Qualitätsmanagement in Endprüfung Qualitätsmanagement und Elemente eines Qualitätsmanagements Leitfaden Leitfaden für das Audit von Qualitätsmanagementsystemen Reifegradmodelle Ähnlich wie die beschriebenen Prozessnormen messen Reifegradmodelle die Qualität, mit der Softwareentwicklungsprozesse betrieben werden. Die Bewertung erfolgt nach vorgegebenen Kriterien. Abhängig von den erreichten Kriterien wird der Entwicklungsprozess in eine Reifegradstufe eingeteilt, d.h. für jede Reifegradstufe werden feste Anforderungen gestellt, um die jeweilige Stufe zu erreichen. Das Ergebnis der Prozess-Bewertung dient zum einen als Ausgangsbasis für die Verbesserung des Softwareentwicklungsprozesses, zum anderen dient es vielen Unternehmen als Leistungsbeleg gegenüber Auftraggebern. Im Folgenden werden die beiden Reifegradmodelle Capability Maturity Model (CMM) und SPICE vorgestellt.

20 2.2 Ansätze zur Qualitätssicherung 15 Capability Maturity Model (CMM) Das Capability Maturity Modell definiert fünf Reifegradstufen, um Softwareentwicklungsprozesse einer Organisation zu bewerten und gezielte Prozessverbesserungen vornehmen zu können. Neben der eigentlichen Qualität stehen dabei auch die finanziellen und zeitlichen Rahmenbedingungen des jeweiligen Softwareentwicklungsprojekts im Fokus. Die Reifegradstufen bauen aufeinander auf und stellen evolutionäre Schritte dar, die eine Grundlage für kontinuierliche Prozessverbesserung bilden [2]. Mit steigendem Reifegrad werden die Größen Kosten, Zeit und Qualität beherrschbarer, die Qualität und Produktivität steigen und das Risiko sinkt [46]. Die 5 Reifegradstufen des CMM sind in Tabelle 2.3 und Abb. 2.1 beschrieben. Tabelle 2.3. Reifegradstufen des CMM Stufe Bedeutung 1 Initial (initial): Stufe 1 ist der niedrigste Reifegrad. Sie stellt den Grundzustand im Unternehmen, ohne definierten Software- Entwicklungsprozes, dar. 2 Wiederholbar (repeatable): Definition eines grundlegenden Entwicklungsprozesses aufgrund vorheriger Projekterfahrungen. Kosten, Zeitpläne und Produktqualität werden überwacht. 3 Definiert (defined): In dem Unternehmen ist ein Standardsoftwareprozess eingeführt. Für die Umsetzung dieses Prozesses ist eine spezielle Organisationseinheit zuständig. 4 Gesteuert (managed): In Stufe 4 werden für das Produkt und den Prozess quantitative Qualitätsanforderungen definiert, deren Erreichung gemessen und überwacht werden. 5 Optimiert (optimised): Ziel dieser Stufe ist es, Schwächen im Entwicklungsprozess aufzudecken und den Prozess durch den Einsatz neuer Methoden, Techniken, Werkzeuge etc. zu verbessern.

21 16 2 Grundlagen der Qualitätssicherung steigende Produktivität und Qualität Stufe 3 Stufe 4 gesteuert (managed) Stufe 5 optimiert (optimised) Stufe 2 definiert (defined) Stufe 1 wiederholbar (repeatable) initial (initial) sinkendes Risiko Abb Capability Maturity Model (CMM) [55] Um die Anforderungen der jeweiligen Stufe zu erreichen, werden bewährte Methoden in so genannten Schlüsselprozessbereichen vorgegeben. Jedem Schlüsselprozessbereich sind Schlüsselpraktiken (key practices) zugeordnet, die angeben, was zu tun ist, um den jeweiligen Schlüsselprozessbereich zu erfüllen [61]. In Tabelle 2.4 werden für jede Stufe typische Prozess-Charakteristika und Schlüsselprozessbereiche angegeben. Tabelle 2.4. Reifegradstufen und Schlüsselprozessbereiche von CMM [42] Stufe Prozess-Charakteristik Schlüsselprozessbereiche 1 ad hoc, chaotisch nur wenige Prozesse definiert, Prozess hängt von Individuen ab 2 intuitiv, diszipliniert Einsatz früherer Erfahrungen bei ähnlichen Projekten 3 qualitativ, Alle Prozesse definiert und dokumentiert, projektspezifische Anpassung des Standardmodells Anforderungsmanagement Software-Projektplanung Software-Projektverfolgung und -überblick Software-Unterauftragsmanagement Software-Qualitätssicherung Software-Konfigurationsmanagement Schwerpunkt auf organisationsweiten Prozess Prozessdefinition Ausbildungsprogramm Integriertes Software-Management Software-Produktherstellung Koordination zwischen Gruppen Peer Reviews

22 2.2 Ansätze zur Qualitätssicherung 17 Tabelle 2.4. Fortsetzung 4 quantitativ (Metriken- Einsatz), vorhersagbar Messung von Prozess- und Produktqualität 5 Rückgekoppelter Prozess, Einsatz innovativer Ideen und Technologien, kontinuierliche Verbesserung Quantitatives Prozessmanagement Software-Qualitätsmanagement Defektvermeidung Technologie-Changemanagement Prozess-Changemanagement Neben dem CMM existieren noch eine Reihe weiterer CMMI-Modelle, wie beispielsweise das People Capability Maturity Model (P-CMM), welches zur Verbesserung des Personalmanagements in Software- Entwicklungsprojekten dient. Ziel dieses Modells ist unter anderem die Erhöhung der kollektiven Fähigkeiten des Unternehmens durch Erhöhung der Fähigkeiten der Entwickler und die Motivierung von Mitarbeitern. Als Weiterentwicklung von CMM ist das Capability Maturity Model Integrated (kurz CMMI) zu sehen. Im Gegensatz zu CMM hat CMMI das Ziel einer systematischen Prozessverbesserung über verschiedene Tätigkeitsbereiche, wie zum Beispiel Softwareentwicklung, Systementwicklung, Produktintegration etc., hinweg. SPICE (ISO 15504) Das in der ISO definierte Reifegradmodell SPICE dient zur Bewertung und Verbesserung von Prozessen. Im Gegensatz zu CMM werden hier einzelne Prozesse einer Organisation bzw. eines Projektes unabhängig voneinander betrachtet. SPICE ist auf Basis von CMM entstanden und integriert die beiden Ansätze CMM und ISO 9000 [42]. Abb. 2.2 zeigt die Struktur von ISO Im Fokus von SPICE steht das Prozess-Assessment, welches Prozesse überprüft und bewertet. Ausgehend von der Reifegradbestimmung können die jeweiligen Prozesse verbessert werden.

23 18 2 Grundlagen der Qualitätssicherung Prozess (process) Identifiziert Modifikationen wird überprüft durch Prozess-Assessment (process assessment) Identifiziert Reifegrad und Risiken führt zu führt zu Prozess-Verbesserung (process improvement) motiviert zu Reifegradbestimmung (capability determination) Abb Die Struktur von ISO [2] SPICE besitzt gegenüber CMM ein zwei-schieniges Bewertungsmodell. SPICE wird unterteilt in Prozess-Dimension und Reifegrad- bzw. Fähigkeitsdimension. Die Prozessdimension definiert Prozesse, die im Rahmen eines Softwareentwicklungsprozesses anfallen. Dazu wurden in SPICE ursprünglich 29 Prozesse definiert, die mittlerweile auf über 40 erweitert wurden. Jedem Prozess sind eine Menge von Aktivitäten sowie Ein- und Ausgabeprodukte zugeordnet [61, 2]. Die definierten Prozesse werden in fünf Prozesskategorien eingeteilt, die jeweils einen einheitlichen Aufgabenbereich abdecken (Tabelle 2.5). Tabelle 2.5. SPICE Prozesskategorien Kategorie Customer-Supplier Process Category (CUS) Engineering Process Category (ENG) Support Process Category (SUP) Management Process Category (MAN) Organization Process Category (ORG) Beschreibung Beschreibt Prozesse, die unmittelbar den Kunden betreffen, wie Software-Akquisition, Kundenbetreuung, Software-Einsatz Umfasst Prozesse, die dazu dienen, Produkte zu spezifizieren, zu entwerfen und zu implementieren. Prozesse, die andere Prozesse unterstützen, z.b. Dokumentation, Konfigurationsmanagement, QS etc. Prozesse, die notwendig sind, um Software-Projekte zu planen, zu steuern und zu kontrollieren, z.b. Projektmanagement und Risikomanagement. Prozesse, die es ermöglichen, Unternehmensziele zu definieren und durch Ressourcen zu erreichen, z.b. Prozessdefinition, -verbesserung und Personalmanagement.

24 2.2 Ansätze zur Qualitätssicherung 19 Die Prozessdimension definiert lediglich Prozesse, umfasst jedoch keinerlei Bewertungskriterien für diese. Dies wird innerhalb der Reifegradbzw. Fähigkeitsdimension vorgenommen. Die Fähigkeitsdimension, auch als Reifegrad-Dimension bezeichnet, dient zur Reifegradbestimmung einzelner, voneinander unabhängiger Prozesse. In SPICE sind sechs Reifegradstufen definiert. Zusätzlich werden zur Bewertung der Prozess-Leistungsfähigkeit neun so genannte Prozess- Attribute genutzt, die den Reifegradstufen zugeordnet sind (Tabelle 2.6). Die Prozess-Attribute werden anhand einer vierstufigen Skala (nicht erfüllt, teilweise erfüllt, weitgehend erfüllt und vollständig erfüllt) bewertet [38]. Tabelle 2.6. Reifegradstufen und Prozess-Attribute in ISO [38] Stufe Reifegrad zugeordnete Prozess-Attribute 0 unvollständiger Prozess (incomplete process) 1 durchgeführter Prozess (performed process) 2 gesteuerter Prozess (managed process) 3 etablierter Prozess (established process) 4 vorhersagbarer Prozess (predictable process) 5 optimierender Prozess (optimizing process) PA 1.1 Prozess-Durchführung (process performance) PA 2.1 Durchführungs-Management (performance management) PA 2.2 Arbeitsprodukt-Management (work product management) PA 3.1 Prozess-Definition und -Anpassung (process definition) PA 3.2 Prozess-Ressourcen (process resource) PA 4.1 Prozess-Vermessung (process measurement) PA 4.2 Prozess-Steuerung und -Kontrolle (process control) PA 5.1 Prozess-Veränderung (process change) PA 5.2 Kontinuierliche Verbesserung (continuous improvement)

25 3 Systematisierung von Entwicklungsprozessen Um eine Entscheidung für oder gegen ein bestimmtes Vorgehensmodell treffen zu können ist es notwendig, existierende Prozesse systematisch zu bewerten. In den folgenden Kapiteln werden Anforderungen aus Sicht der Embedded-Entwicklung an Entwicklungsprozesse gestellt, existierende Prozesse untersucht und ein neuer auf die spezifischen Belange optimierter Prozess vorgestellt. 3.1 Anforderungen an Vorgehensmodelle Für die Auswahl, Anpassung oder Neuentwicklung eines Entwicklungsprozesses speziell für das Umfeld Eingebetteter Systeme ist es zwingend erforderlich, sich die Anforderungen, die an einen solchen Prozess gestellt werden, zu vergegenwärtigen. Da Entwicklungsprozesse für eingebettete Systeme natürlich auch alle Anforderungen berücksichtigen müssen, die global für alle Arten von Entwicklungsprozessen gelten, wird in dem folgenden Abschnitt nur auf Anforderungen eingegangen, die spezifisch für die Entwicklung eingebetteter Systeme erforderlich sind. Diese Anforderungen resultieren aus den klassischen Problemen, die bei der Entwicklung eingebetteter Systeme auftreten können und führen im Weiteren zu konkreten Maßnahmen zu deren Linderung. Im Forschungsprojekt EQUAL wurden die nun folgenden Anforderungen, denen Entwicklungsprozesse für eingebettete Systeme genügen müssen, formuliert. Unterstützung des Embedded Charakters Unter dieser Anforderung wird die Berücksichtigung und Einbeziehung aller an der Entwicklung eingebetteter Systeme beteiligten Disziplinen, also zumindest Software und Elektronik, verstanden. Diese Anforderung stellt gewissermaßen die Grundvoraussetzung für einen Entwicklungsprozess für eingebettete Systeme dar, da eine Entwicklung ohne adäquate Einbindung aller Disziplinen nicht zielführend unter den Rahmenbedingungen Kosten, Qualität und Zeit abgewickelt werden kann. Da ein einge-

26 22 3 Systematisierung von Entwicklungsprozessen bettetes System, wie der Name schon sagt, in ein meist mechanisches Gesamtsystem eingebettet / integriert wird, muss die Anforderung folglich so erweitert werden, dass alle beteiligten Disziplinen am Entwicklungsprozess gleichberechtigt berücksichtigt werden. Anforderungsklärung und Anforderungsverfolgung Bei der Anforderungsklärung werden alle Aspekte zur Beschreibung der Funktionen des zu entwickelnden Produktes nach unterschiedlichen Kriterien kategorisiert und in einem oder mehreren schriftlichen Dokumenten festgehalten bzw. mit Hilfe von Softwarewerkzeugen (z.b. DOORS) elektronisch gespeichert. Die Anforderungen sollen eindeutig, verständlich und testbar sein. Wenn möglich sollten Angaben über die Priorität (wieviel ist mir eine Anforderung wert?), Quelle, Wertebereich, Dimension und Bearbeitungszeitraum (keine Aufwandsschätzung) aufgeführt werden. Änderungen sollen in einer Historie verfolgt werden können. Bereits gefällte Entscheidungen sollen so protokolliert werden und bei Diskussionen als Grundlage zur Verfügung stehen. Da bei der Entwicklung eingebetteter Systeme Anforderungen an ein Produkt meist nicht nur eine Disziplin adressieren, ist eine Unterstützung der Anforderungsklärung durch den Entwicklungsprozess maßgeblich für deren Realisierung verantwortlich. Früher durchgängiger Hardware-, Software- und Systemtest Die Frühzeitige Absicherung komplexer Abhängigkeiten zwischen mehreren Disziplinen kann enorm zur Verringerung des speziell bei eingebetteten Systemen vorhandenen Integrationsrisikos beitragen. Teile, die noch nicht als Hardware verfügbar sind, sollen durch Simulation ersetzt werden können. So besteht die Möglichkeit bereits frühzeitig einen durchgängiger Systemtest zu realisieren [58]. Eventuell wäre es denkbar, hierbei Standard- oder häufig verwendete Komponenten in einer Bibliothek zu sammeln. Der Entwicklungsprozess muss die angesprochenen Hardware-, Software- und Systemtests beinhalten und unterstützen. Wünschenswert ist die Berücksichtigung dieser wichtigen Entwicklungsschritte durch eine eigenen Phase. Weiterhin muss der Entwicklungsprozess die Beteiligten bei der Identifizierung relevanter Zeitpunkte (Abhängigkeiten zwischen Disziplinen) unterstützen, an denen eine Absicherung bzw. Abstimmung zwischen der Hardware und Software durchgeführt werden muss.

27 3.1 Anforderungen an Vorgehensmodelle 23 Qualitätsfördernd / Qualitätsorientiert Der Prozess soll qualitätsfördernde Vorgehensweisen berücksichtigen. Dazu notwendige Maßnahmen sollen im Prozess integriert werden. Sie dürfen nicht als Mehraufwand, sondern als Chance, Fehler frühzeitig zu finden und zu verhindern, verstanden werden. Dies entspricht dem Ansatz, über Prozessqualität Produktqualität zu erzielen [23]. Komplexe Produkte wie eingebetteter Systeme können ohne ein methodisches Entwicklungsverfahren nur schwer mit hinreichender Qualität erstellt werden. Effektivität und Effizienz Der Prozess soll wesentliche Aufgaben zur Entwicklung eingebetteter Systeme unterstützen und fördern (hoher Wirkungsgrad). Eine entscheidende Rolle spielt hierbei die Reihenfolge der Entwicklungsphasen, Arbeitspakete sowie Tätigkeiten, die durch den Entwicklungsprozess vorgegeben sind. Den Tätigkeiten müssen Rollen zugeordnet werden, die festlegen wer was wann bearbeitet. Bei der Besetzung der Rollen mit Personen ist darauf zu achten, dass diese den Arbeiten auch gewachsen sind. Kunden-Integration Der Kunde ob externer oder interner Kunde ist hier nicht von Bedeutung soll direkt in das Projekt eingebunden werden, um die Kommunikation zwischen Auftraggeber und -nehmer zu verbessern. Dem Kunden werden so unmittelbar die Auswirkungen seiner Entscheidungen veranschaulicht. Gerade in der Entwicklung eingebetteter Systeme treten häufig interne Kunden auf. Um die Abstimmung und Kommunikation zwischen den einzelnen Disziplinen optimal zu verwirklichen, ist eine methodische Unterstützung durch den Entwicklungsprozess notwendig. Standardisiert für den Firmeneinsatz Ein gemeinsames Verständnis der Projektinhalte und -ziele aller Beteiligten ist eine Grundvoraussetzung für ein erfolgreiches Abschließen eines Entwicklungsvorhabens. Alle an einem Projekt beteiligten Mitarbeiter müssen über eine gemeinsame methodische und terminologische Wissensbasis verfügen. Es sollen einheitliche Dokumente / Ergebnisse / Artefakte (Text, Grafik, Code, Zeichnungen...) erstellt werden, für die entsprechende Richtlinien, Vollständigkeitskriterien und Vorlagen vorhanden sind.

28 24 3 Systematisierung von Entwicklungsprozessen Robust Unter Robustheit ist Störunanfälligkeit gegenüber Einflüssen von innen und außen zu verstehen. Diese Einflüsse können unter anderem personelle Veränderungen, geänderte / neue Anforderungen, technische Schwierigkeiten, zeitliche Verzögerungen u.ä. sein. Flexibel Der Prozess soll flexibel an die gegebenen Verhältnisse anpassbar sein. Diese Prämisse wurde aufgestellt, da die Entwicklungsvorgehen und Rahmenbedingungen in den verschiedenen Firmen stark voneinander abweichen. Ebenso soll der Entwicklungsprozess die verschiedenen Entwicklungstypen, also Neu-, Varianten- und Weiterentwicklung, die unterschiedliche Ausprägungen der Entwicklungsphasen nach sich ziehen, unterstützen. Das bedeutet also, dass ein Grundprozess mit vertretbarem Aufwand an spezifische Gegebenheiten anpassbar sein soll. Leicht verständliche Grundidee Der gesamte Entwicklungsprozess soll leicht vermittelbar sein. Ideal ist eine Unterstützung bei der Einarbeitung durch angebotene Seminare und kurze Prozessbeschreibungen. Zur einfacheren Vorstellung des Prozessablaufs sind aussagekräftige Graphiken sehr hilfreich. Dabei ist darauf zu achten, dass die Graphiken ohne zusätzliche schriftliche Beschreibungen verstanden werden können. Termintreue fördern Termintreue stellt nicht nur bei der Entwicklung eingebetteter Systeme einen entscheidenden Erfolgsfaktor des Produktes am Markt dar. Auch hier spielt die Besonderheit der multidisziplinären Entwicklung eine übergeordnete Rolle. Erstellte Teilergebnisse müssen mit einem meist hohen Aufwand miteinander zu einem Gesamtsystem integriert werden. Diese oft unterschätzte Tätigkeit muss in der Terminplanung berücksichtigt werden, damit gesteckte Ziele zu den geplanten Zeitpunkten erreicht werden können. Die hierfür notwendige Aufwandsabschätzung soll durch geeignete Maßnahmen unterstützt werden. Integration etablierter Arbeitsfolgen Bereits vorhandene und durch die Firmenphilosophie vorgegebene Teilprozesse sollen in den Entwicklungsprozess integriert werden können. Da

29 3.2 Erfüllen etablierte Prozesse diese Anforderungen? 25 Firmen, die in den Embedded-Markt vorstoßen wollen, bisher meist entweder reine Software- bzw. Elektronikprodukte entwickelt haben, existieren bereits funktionierende Entwicklungsprozesse für die jeweilige frühere Kern-Disziplin. Diese gelebten Prozesse können und sollen nicht einfach abgeschafft, sondern möglichst unverändert in den neuen multidisziplinären Entwicklungsprozess aufgenommen werden. Anwendbarkeit Hier steht die Anwendbarkeit des Vorgehensmodells durch die Entwickler im Vordergrund. Die Entwickler sollen die Vorgaben des Prozesses nicht als zusätzliche Last empfinden, sondern durch den Prozess bei ihrer täglichen Arbeit unterstützt werden. Überspitzt ausgedrückt soll der Prozess Spaß machen. Anhand der aufgezeigten Anforderungen an Entwicklungsprozesse für eingebettete Systeme werden im Folgenden bereits existierende Prozesse auf ihre Eignung hinsichtlich der besonderen Herausforderungen bei der Entwicklung eingebetteter Systeme untersucht. Dabei werden die betrachteten Entwicklungsprozesse kurz vorgestellt und anschließend bewertet. 3.2 Erfüllen etablierte Prozesse diese Anforderungen? In den vergangenen Jahren haben sich die Fachdisziplinen weitgehend unabhängig voneinander entwickelt. Daraus resultierten die unterschiedlichen speziellen Begriffswelten, Methoden und Methodiken. In den nun folgenden Abschnitten werden die domänenspezifischen Vorgehensmodelle der einzelnen an der Entwicklung mechatronischer Produkte beteiligten Disziplinen (Software, Mechanik, Elektronik) vorgestellt. Es werden zum einen Phasenmodelle dargestellt, zum anderen etablierte Vorgehensmodelle wie sie in der Industrie eingesetzt werden. In jeder Domäne wurde der Bedarf an multidisziplinären Entwicklungsprozessen erkannt. Aus diesem Grund wird zusätzlich zu den domänenspezifischen Entwicklungsprozessen jeweils ein multidisziplinärer Entwicklungsprozess vorgestellt, der seinen Ursprung in einer der drei Disziplinen Mechanik, Elektronik oder Softwaretechnik hat Softwaretechnik Die betrachteten Vorgehensmodelle stammen aus den unterschiedlichsten Bereichen der Softwareentwicklung und wurden meist direkt aus der Pro-

30 26 3 Systematisierung von Entwicklungsprozessen jektpraxis heraus entwickelt. Deshalb sind sie auf die dort vorherrschenden Rahmenbedingungen zugeschnitten. In der Softwaretechnik existieren verhältnismäßig viele unterschiedliche Entwicklungsprozesse. Es gilt allgemein als nicht möglich, ein konkret anwendbares Vorgehensmodell zu entwickeln, das in jede Projektkonstellation passt, da sich diese in ihren Details meist stark unterscheiden. Je kontextunabhängiger ein Vorgehensmodell jedoch wird, desto schwieriger ist es, dieses auf ein konkretes Projekt anzupassen und anzuwenden. Um dieser Problematik zu begegnen, wird ein Mittelweg zwischen Anwendbarkeit und Unabhängigkeit von einem konkreten Kontext gesucht. Die folgenden Vorgehensmodelle wurden im Rahmen des EQUAL- Projekts auf ihre Eignung für die Entwicklung eingebetteter Systeme untersucht. Rational Unified Process (RUP) V-Modell 97 Extrem Programming (XP) Nachfolgend wird auf die genannten Vorgehensmodelle und ihre Eignung für die Entwicklung eingebetteter Systeme näher eingegangen. Rational Unified Process Der Rational Unified Process (RUP) wurde von der Firma Rational (seit 2003 IBM) entworfen und basiert auf der Modellierungssprache UML. Er lässt sich auf vier Abstraktionsebenen beschreiben [44]. Auf der obersten Ebene (Abb. 3.1) sind die verschiedenen Workflows und die verschiedenen Phasen des RUPs dargestellt. Die einzelnen Workflows sind hier Business Modelling, Requirements, Analysis & Design, Implementation, Test, Deployment, Configuration & Change Management, Project Management, Environment. Diese Workflows durchlaufen alle nebenläufig die Phasen Inception, Elaboration, Construction und Transition. Innerhalb jeder Phase können mehrere Iterationen individuell geplant und durchlaufen werden. Die verschiedenen Kurven repräsentieren den möglichen Aufwand für die einzelnen Workflows innerhalb der einzelnen Phasen. Auf der nächsten Detaillierungsebene erfolgt eine grobe Unterteilung der einzelnen Workflows in noch recht grobe Aktivitäten.