Embedded Systems - qualitätsorientierte Entwicklung

Klaus Bender (Hrsg.) Embedded Systems - qualitatsorientierte Entwicklung

Klaus Bender (Hrsg.)

Embedded Systems Entwicklung Mit 66 Abbildungen

Q - Springer

Professor Dr.-Ing Klaus Bender Technische Universitat Miinchen LS Informationstechnik im Maschinenwesen (itm) Boltzmannstr. 15 85748 Garching [email protected]

Bibliografische Information der Deutschen Bibliothek Die deutsche Bibliothek verzeichnet diese Publikation in der deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet uber abrufbar.

ISBN 3-540-22995-7 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~nungoder 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: ~nedionetAG, Berlin Satz: Digitale Druckvorlage des Autors Herstellung: medionet AG, Berlin Gedruckt auf saurefreiem Papier

6813020 5 4 3 2 1 0

Inhalt

Einführung

1

Handbuch

5

1 Wandel der Produkte und Prozesse 1.1 Von mechanischen zu mechatronischen Produkten 1.2 Neue Herausforderungen an die Entwicklung 1.3 Besonderheiten eingebetteter Software 1.4 Anforderungen der eingebetteten Software an die QS

7 7 8 9 9

2 Grundlagen der Qualitätssicherung 2.1 Begriffsdefinitionen 2.2 Ansätze zur Qualitätssicherung 2.2.1 Produktnorm ISO 9126 2.2.2 Prozessnorm ISO 9000 2.2.3 Reifegradmodelle

11 11 13 13 13 14

3 Systematisierung von Entwicklungsprozessen 3.1 Anforderungen an Vorgehensmodelle 3.2 Erfüllen etablierte Prozesse diese Anforderungen? 3.2.1 Softwaretechnik 3.2.2 Mechanik 3.2.3 Elektronik 3.2.4 Schlussfolgerung 3.3 Das 3-Ebenen-Vorgehensmodell 3.3.1 Aufbau des 3-Ebenen-Vorgehensmodells 3.3.2 Einsatz des 3-Ebenen-Vorgehensmodells bei der Entwicklung mechatronischer Systeme

21 21 25 26 33 38 43 44 45

4 Systematisierung von Qualitätssicherungsmaßnahmen

51

48

VI

Inhalt

5 Methodik des virtuellen Funktionstests 5.1 Prinzip und Begrifflichkeit 5.2 Ausprägungen im Entwicklungsprozess 5.3 Umsetzung des virtuellen Funktionstests 5.4 Fazit und Bewertung

55 55 57 59 63

Leitfaden

65

6 Bestandsaufnahme bei den Projektpartnern 6.1 Vorgehensweise 6.1.1 Die Elemente der Prozessbeschreibung 6.1.2 Der Dokumentenplan 6.2 Ergebnisse und Bewertung 6.2.1 Liste von QS-Maßnahmen 6.2.2 Liste von Dokumenten 6.2.3 Anmerkungen zur Bestandsaufnahme

67 67 68 70 71 71 75 76

7 Auswahl von QS-Maßnahmen 77 7.1 Rahmenkonzept der Entscheidungsunterstützung 78 7.1.1 Profilbasiertes Entscheidungsmodell 80 7.1.2 Kategorisierung der Merkmale 85 7.1.3 Auswahlmethodik 86 7.1.4 Nutzen der Entscheidungsunterstützung 89 7.2 Vorgehensweisen zur Anwendung der Entscheidungsunterstützung 90 7.2.1 Zusammensetzung der Expertengruppe 90 7.2.2 Vorgehensweise zur Definition von Profilen 91 7.2.3 Bestimmung relevanter Merkmale 93 7.2.4 Beschreibung von Merkmalen 96 7.2.5 Vorgehensweise zur Beschreibung von Profilen 98 7.2.6 Beschreibung von Entwicklungsprofilen 99 7.2.7 Beschreibung von QS-Anforderungsprofilen 100 7.2.8 Beschreibung von QS-Maßnahmenprofilen 101 7.2.9 Verwendung und Anpassung des Entscheidungsmodells 103 8 Anwendung von QSM in der Praxis 8.1 Änderungsmanagement 8.2 Anforderungsverfolgung 8.3 Defect Management 8.4 Fehler-Möglichkeits- und Einflussanalyse (FMEA) 8.5 Funktionstest 8.6 Nutzung eines Phasenmodells (V- Modell)

107 109 118 125 132 140 146

Inhalt

8.7 8.8 8.9 8.10 8.11 8.12

Objektorientierte Analyse und Design mit UML Regressionstest (1) Regressionstest (2) Review-Techniken Risikomanagement Softwareänderungs-Management

VII

155 160 166 173 181 187

9 Die Einführung von QSM in einzelnen Unternehmen 9.1 Anforderungs- und Defect-Management 9.2 Simulation zu Testzwecken 9.3 Prozessdefinition mit dem project>kit 9.4 Modellbasierter Funktionstest regelungstechnischer Software 9.5 Virtueller Funktionstest von PROFIBUS-Komponenten 9.6 Fundamentales Modellierungskonzept (FMC) 9.7 Optimierung des Entwicklungsprozesses

193 194 204 212 225 239 248 256

10 Best-Practice-Empfehlungen für die Auswahl von QSM 10.1 Anforderungen 10.2 System-Design 10.3 Realisierung 10.4 Systemintegration- und test 10.5 Projektmanagement

263 265 271 277 282 287

Anhang

295

QS-Maßnahmenkatalog Analytische QS-Maßnahmen Konstruktive QS-Maßnahmen Organisatorische QS-Maßnahmen

297 297 318 333

Literatur

357

Glossar

363

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

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 QSMaßnahmen in diesen Unternehmen. Die diesbezüglichen Informationen

2

Einführung

und Erfahrungsberichte stammen aus dem Forschungsprojekt EQUAL1, 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 mecha1 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: 1.1.2001 bis 30.9.2004

3

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.

Handbuch

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].

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].

1.3 Besonderheiten eingebetteter Software

1.3

9

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 PCSystem 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-

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 61508 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.

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).

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.

2.2 Ansätze zur Qualitätssicherung

2.2

13

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. 2.2.1

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

Untermerkmale

Funktionalität

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

Zuverlässigkeit Benutzbarkeit Effizienz Änderbarkeit Übertragbarkeit

Um die mit Hilfe der ISO 9126 festgelegten Produkteigenschaften (Eigenschaft = Merkmal + Ausprägung) überprüfen zu können, sind in der Norm ISO 12119 Bestimmungen zur Prüfung der Erfüllung dieser Eigenschaften festgelegt. 2.2.2

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

14

2 Grundlagen der Qualitätssicherung

Vertreter von Prozessnormen ist die ISO 9000-Normenreihe. Der Fokus dieser Normenreihe liegt nicht ausschließlich auf der SoftwareEntwicklung, 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

Titel

ISO 8402 ISO 9000-1 ISO 9000-2

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

ISO 9000-3 ISO 9000-4 ISO 9001

ISO 9002

ISO 9003 ISO 9004 ISO 10011

2.2.3

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.

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 1

2

3

4

5

Bedeutung Initial (initial): Stufe 1 ist der niedrigste Reifegrad. Sie stellt den Grundzustand im Unternehmen, ohne definierten SoftwareEntwicklungsprozes, dar. Wiederholbar (repeatable): Definition eines grundlegenden Entwicklungsprozesses aufgrund vorheriger Projekterfahrungen. Kosten, Zeitpläne und Produktqualität werden überwacht. Definiert (defined): In dem Unternehmen ist ein Standardsoftwareprozess eingeführt. Für die Umsetzung dieses Prozesses ist eine spezielle Organisationseinheit zuständig. Gesteuert (managed): In Stufe 4 werden für das Produkt und den Prozess quantitative Qualitätsanforderungen definiert, deren Erreichung gemessen und überwacht werden. 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.

16

2 Grundlagen der Qualitätssicherung

steigende Produktivität und Qualität

Stufe 5

Stufe 4

Stufe 3

Stufe 2

Stufe 1

optimiert (optimised)

gesteuert (managed)

definiert (defined)

wiederholbar (repeatable)

initial (initial)

sinkendes Risiko

Abb. 2.1. 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

1

ad hoc, chaotisch nur wenige Prozesse definiert, Prozess hängt von Individuen ab intuitiv, diszipliniert Einsatz früherer Erfahrungen bei ähnlichen Projekten

2

3

qualitativ, Alle Prozesse definiert und dokumentiert, projektspezifische Anpassung des Standardmodells

Schlüsselprozessbereiche

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

2.2 Ansätze zur Qualitätssicherung

17

Tabelle 2.4. Fortsetzung 4

5

quantitativ (MetrikenEinsatz), vorhersagbar Messung von Prozess- und Produktqualität 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 SoftwareEntwicklungsprojekten 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 15504 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 15504. 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.

18

2 Grundlagen der Qualitätssicherung

Prozess (process) wird überprüft durch

Identifiziert Modifikationen

Identifiziert Reifegrad und Risiken

Prozess-Assessment (process assessment) führt zu Prozess-Verbesserung (process improvement)

führt zu

motiviert zu

Reifegradbestimmung (capability determination)

Abb. 2.2. Die Struktur von ISO 15504 [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

Beschreibung

Customer-Supplier Process Category (CUS) Engineering Process Category (ENG) Support Process Category (SUP) Management Process Category (MAN)

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.

Organization Process Category (ORG)

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 ProzessAttribute 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 15504 [38] Stufe 0 1 2

Reifegrad unvollständiger Prozess (incomplete process) durchgeführter Prozess (performed process) gesteuerter Prozess (managed process)

3

etablierter Prozess (established process)

4

vorhersagbarer Prozess (predictable process)

5

optimierender Prozess (optimizing process)

zugeordnete Prozess-Attribute

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)

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-

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.

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.

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

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. 3.2.1

Softwaretechnik

Die betrachteten Vorgehensmodelle stammen aus den unterschiedlichsten Bereichen der Softwareentwicklung und wurden meist direkt aus der Pro-

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 EQUALProjekts 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.

3.2 Erfüllen etablierte Prozesse diese Anforderungen?

27

Phases Process Workflows

Inception

Elaboration

Construction

Transition

Business Modelling Requirements Analysis & Design Implementation Test Deployment Supporting Workflows

Iteration

Configuration Management Project Management Environment Preliminary iteration(s)

iter. #1

iter. #2

iter. #n

iter. #n+1

iter. #n+2

iter. iter. #m #m+1 Zeit

Abb. 3.1. Rational Unified Process (RUP)

Auf der dritten Detaillierungsebene werden die einzelnen Konzepte (Teilergebnisse (Artifacts), Rollen, deren Aktivitäten, anzuwendende Methoden, sowie die zu verwendenden Templates) zueinander in Beziehung gesetzt. Auf der vierten und letzten Detaillierungsebene erfolgt eine detaillierte Beschreibung der einzelnen Konzepte (Templatevorlagen, Profilbeschreibungen für einzelne Rollen, Aktivitätsbeschreibungen, Methodenbeschreibungen). Die vier Detaillierungsebenen sind durch den gesamten RUP nicht immer deutlich erkennbar herausgearbeitet. Auch sind zwischen den einzelnen Detaillierungsebenen zum Teil Widersprüche vorhanden, so dass die Durchgängigkeit nicht immer gewährleistet ist. Der RUP wirkt vor allem durch die teilweise sehr ausführliche Beschreibung einzelner Methoden (z.B. Beschreibung eines Konzepts bzgl. OO-ER-Mapping) auf der vierten Detaillierungsebene etwas schwerfällig und verliert dadurch stark an Übersichtlichkeit. Weiterhin hat er eine klare Ausrichtung auf BusinessInformations-Systeme, was allein durch den Workflow „Business Modelling“ erkenntlich wird. Er ist bis zu einem gewissen Grad skalierbar, je-

28

3 Systematisierung von Entwicklungsprozessen

doch bedarf es einer langen Einarbeitung, um fundiert beurteilen zu können, welche Komponenten im Einzelfall wegzulassen sind. Eine Anwendung scheint somit überwiegend durch ein geeignetes CASE-Tool effizient. Extreme Programming (XP)

XP (extreme Programming) wurde von Kent Beck entwickelt und ist ein leichtgewichtiger, hoch disziplinierter Software-Entwicklungsprozess für kleine Teams, die während der Entwicklung mit vagen und sich rasch ändernden Anforderungen konfrontiert werden [5]. XP stellt die Kundenzufriedenheit in den Vordergrund und ist darauf ausgelegt, sich auf ändernde Anforderungen einzustellen und diese auch in den späteren Phasen der Entwicklung in den Produktentwicklungsprozess mit einfließen zu lassen. Im Folgenden sind die einzelnen Grundsätze von XP kurz beschrieben.

Zeit Iterative Entwicklung

XP Entwicklung

Test Code Design Analyse Test Code Design Analyse Test Code Design Analyse

Umfang

Abb. 3.2. Iterative Entwicklung beim Extreme Programming (XP)

XP ist kein revolutionär neuer Ansatz, vielmehr vereinigt der Ansatz aus der Praxis bekannte Arbeitstechniken zu einem methodischen Konzept [47].

3.2 Erfüllen etablierte Prozesse diese Anforderungen?

29

Vor allem werden Techniken aus den folgenden Bereichen eingesetzt: • Bewährte Arbeitstechniken der objektorientierten Systementwicklung • Planungstechniken und Techniken der Projektverfolgung, die bisher oft erst in den „Nicht-“ kritischen Phasen praktiziert wurden • Techniken iterativer, evolutionärer Systementwicklung • Einfache und plausible Überlegungen zur Arbeitsgestaltung Insgesamt propagiert der Ansatz zwölf Praktiken [34]. Diese sind in Tabelle 3.1 beschrieben. Tabelle 3.1. XP-Praktiken Name

Beschreibung

On-site Costumer

Nutzer und Entwickler arbeiten im selben Raum. Dadurch kann der Entwickler direkt Fragen an den Nutzer stellen, der sofort den Fortschritt erkennen kann. Müdigkeit führt zu sinkender Arbeitsqualität, was mit der Missachtung von Praktiken einhergeht. Zwischen Nutzer und Entwickler werden „Stories“ ausgehandelt. Nutzer wählen die Stories aus, müssen aber die Schätzungen der Entwickler akzeptieren Es werden automatisierte, wiederholbare Unit Tests (Entwickler) und Acceptance Tests (Nutzer) durchgeführt. Gemeinsames Vokabular und Verständnis für das System. „Continuous Design“: Restrukturierung von Code ohne Funktionsänderungen um den Code verständlicher zu machen, Code-Duplikate werden entfernt, was einen UnitTest erfordert. Das Problem soll auf einfachstem Wege gelöst werden, um keine unnötige Komplexität einzuführen. Refactoring ist der Weg zum einfachen Design. Zwei Entwickler sitzen an einem Computer. Dadurch wird ein ständiges Review durchgeführt Häufige Übergabe von (Teil-)Produkten um u.a. ein schnelles Feedback vom Anwender zu erhalten Der Code aller Entwickler sollte aussagekräftig sein. Jeder Entwickler im Team ist verantwortlich für den gesamten Code. Um Integrationsprobleme schnellstmöglich aufzudecken wird mindestens einmal täglich eine Integration durchgeführt. So existiert auch zu jedem Zeitpunkt eine lauffähige Version des Systems.

40 Hour Week Planning Game

Testing Metaphor Refactoring

Simple Design

Pair-Programming Short Releases Coding Standards Collective Ownership Continuous Integration

30

3 Systematisierung von Entwicklungsprozessen

Die dargestellten Techniken sind alle „leichtgewichtig“. Darunter wird verstanden, dass sich praktisch alle Techniken ohne organisatorischen Vorlauf und ohne spezielle technische Unterstützung anwenden lassen. Einige der genannten Techniken werden im Folgenden näher betrachtet. Es wird eine einfache Form der Planung angewandt, um die nächsten Schritte im Projekt zu planen. Der Ansatz sieht als Spezifikation so genannte Storycards vor. Diese beschreiben die gestellten Anforderungen und strukturieren das Entwicklungsprojekt in Arbeitspakete. Allerdings sind die Storycards in Umfang und Genauigkeit nicht mit einer üblichen Spezifikation zu vergleichen. Die Entwickler programmieren in dem so genannten pair-programming Stil. Dabei arbeiten immer zwei Entwickler an einem Rechner, was sich durch eine konzentrierte Arbeitsweise äußert und somit die Qualität der Arbeitsergebnisse positiv beeinflusst. Für das Design ist ein eigens eingesetzter System-Architekt zuständig. Das Design ist einfach gewählt und wird schrittweise erweitert, so dass es immer den momentanen Anforderungen genügt. Wird die Architektur zu komplex kommt es zum so genannten Refactoring. Die Programmierer erarbeiten den Code gemeinsam nach gemeinsam festgelegten Richtlinien, so dass jeder in der Lage ist, den Code selbständig zu verstehen und weiterzuentwickeln. In XP gilt weiterhin ein großes Augenmerk dem testgestützten Arbeiten, wobei der Ansatz gilt, dass jedem Modul des zu entwickelnden Programms ein Test-Modul zugeordnet wird. Alle Teile eines Systems werden somit durch wiederholbare Tests geprüft. Der Ansatz XP schreibt sogar vor, dass vor der Code-Implementierung der Testfall bereits geschrieben sein muss. Dadurch wird die Spezifikation frühzeitig auf Eindeutigkeit hin überprüft. Der XP-Ansatz ist ausschließlich für die Entwicklung von Software konzipiert, d.h. eine Hardware-Entwicklung wird nicht ausdrücklich unterstützt. Trotzdem existieren bereits Ansätze, die für die Softwareentwicklung vorgeschlagenen Techniken auf die Hardwareentwicklung zu übertragen [62].Bei räumlicher Trennung der Entwickler sollte XP aufgrund der vorgesehenen engen Zusammenarbeit nicht eingesetzt werden. Aber durch die fehlende Unterstützung bei der Synchronisation der beteiligten Disziplinen und der Integration ihrer Teilsysteme ist ein Einsatz für die Entwicklung eingebetteter Systeme nur bedingt möglich. Weiterhin ist das Fehlen von Spezifikationen und Entwurfsdokumenten bei der Erstellung und Wartung von komplexen eingebetteten Systemen hinderlich.

3.2 Erfüllen etablierte Prozesse diese Anforderungen?

31

V-Modell 97

Das V-Modell 97 ist ein international anerkannter und im Bereich der deutschen Bundesbehörden für die Projektabwicklung einzusetzender Standard [67]. Der Ansatz besteht aus vier Submodulen, siehe Abb. 3.3.

Projekt Planen und kontrollieren

Plandaten

Voraussetzungen schaffen und Softwareentwicklungsumgebung (SEU) bereitstellen

PM

Istdaten

Plandaten

Istdaten

SEU

QSAnforderungen vorgeben

SEU Plandaten

Istdaten

Plandaten

SEU

Produkt entwickeln

Istdaten

SEU

Produktstruktur planen

SE Produkte prüfen QSErgebnis

Rechte QSAnforderung

QS PM: Projektmanagement QS: Qualitätssicherung

Produkte/ Rechte verwalten

Produkt Konfigurationsstruktur Produkt

KM

SE: Systemerstellung KM: Konfigurationsmanagement

Abb. 3.3. Die Submodule des V-Modells 97

Das V-Modell 97 betrachtet also die Entwicklung von IT-Systemen ganzheitlich vom Projektmanagement über die Systemerstellung und Qualitätssicherung bis hin zum Konfigurationsmanagement. Im weiteren Verlauf wird aber nur noch die eigentliche Systemerstellung betrachtet. Das V-Modell erweitert das Wasserfall-Modell durch Integration der Qualitätssicherung. Es legt die Aktivitäten, Rollen und Produkte des Entwicklungs- und Pflegeprozesses fest. Das V-Modell schließt neben der eigentlichen Softwareentwicklung das Projektmanagement, die Qualitätssicherung und das Konfigurationsmanagement ein. Art und Umfang der Entwicklungsaktivitäten können je nach Projektart und -umfang vor Projektbeginn festgelegt werden (Tailoring). Ebenso werden vorzulegende

32

3 Systematisierung von Entwicklungsprozessen

Dokumente (Produkte) bestimmt sowie Verantwortlichkeiten für die Aktivitäten festgelegt (Rollen). SWE1 System-Anforderungsanalyse und Entwurf

SWE9 Systemintegration

SWE2 DV-Anforderungsanalyse und Entwurf

SWE8 DV-Integration

SWE3 SW-Anforderungsanalyse und Entwurf

SWKEIntegration SWE7 SW-Integration

SWE4 Grobentwurf

KomponentenIntegration

SWE5 Feinentwurf SWE6 Implementierung SW: Software SWE: Softwareerstellung

DV: Datenverarbeitung SWKE: Softwarekonfigurationseinheit

Prüfaktivitäten

Abb. 3.4. Das V-Modell 97 (Submodul SE)

Das V-Modell ordnet die Phasen V-förmig an. Es wird das Prinzip verfolgt, dass spezifizierende Aktivitäten den zugehörigen umsetzenden Tätigkeiten gegenübergestellt werden. Die auf dem rechten Ast aufgetragenen Prüfaktivitäten orientieren sich an den gegenüberliegenden Spezifikationen. In den Phasen SW 1 bis SW 9 werden jeweils mehrere Aktivitäten zu sog. Hauptaktivitäten zusammengefasst. Das V-Modell zeichnet weiterhin aus, dass das Vorgehensmodell nicht nur Aktivitäten zur Softwareentwicklung enthält, sondern auch auf die benötigte Hardware eingeht. Software und Hardware werden deshalb als System bezeichnet. Die Grundidee besteht in der möglichst frühen Definition von Anwendungsszenarien und Testfällen in den Phasen Anforderungsanalyse, Grobentwurf, Feinentwurf und Implementierung (absteigender Ast). Diese Anwendungsszenarien und Testfälle werden dann in den entsprechenden Phasen Modultest, Integrationstest, Systemtest und Abnahmetest (aufsteigender Ast) verifiziert und validiert. Das V-Modell wurde ursprünglich für eingebettete Systeme entwickelt. Software wird dabei als Bestandteil eines informationstechnischen Sys-

3.2 Erfüllen etablierte Prozesse diese Anforderungen?

33

tems (IT-System) gesehen. Es verfolgt weiterhin einen generischen Ansatz, der ein spezifisches Maßschneidern auf projektspezifische Anforderungen erfüllt. Es ermöglicht somit eine standardisierte Abwicklung von Systemerstellungsprojekten. Das V-Modell hat eine starke Ausrichtung auf Großprojekte, was bei kleineren und mittleren Projekten zu einer unnötigen Produktvielfalt – d.h. Dokumentenvielfalt – und Überorganisation (das V-Modell umfasst 25 Rollen) führt. Ohne geeignete Unterstützung durch ein CASE-Tool ist das V-Modell nicht handhabbar. Bewertung

Das V-Modell stellt einen weit entwickelten und allumfassenden Ansatz für die Entwicklung eingebetteter Systeme dar. Allerdings ist der hohe Tailoring-Aufwand insbesondere für kleine und mittlere Projekte nicht zu unterschätzen. Ein Gefühl des „Overengineerings“ kommt bei den beteiligten Entwicklern häufig auf, da auch der Einarbeitungsaufwand sehr hoch ist. Die Führung bei den Integrationstätigkeiten der Teilsysteme zu einem Gesamtsystem ist durch das V-Modell 97 nicht optimal gelöst. 3.2.2

Mechanik

Gerade in dieser Disziplin ist der Einsatz von Vorgehensmodellen in der Industrie weit verbreitet und hat einen hohen Entwicklungsstand erreicht. Im Bereich der Mechanik werden solche Vorgehensmodelle unter dem Begriff der Konstruktionsmethodik zusammengefasst. Der eigentliche Entwicklungs- und Konstruktionsprozess ist in dem Phasenmodell nach Pahl / Beitz (Abb. 3.5) in drei Hauptphasen unterteilt: • Konzipieren (Prinzipielle Festlegung der Lösung) • Entwerfen (gestaltmäßige Festlegung des Produktes) • Ausarbeiten (herstellungstechnische Festlegung des Produktes) Den Ausgangspunkt in der Konstruktionsmethodik stellt das Planen und Klären der Aufgabe (vgl.Abb. 3.5), die Produktplanungsphase dar. Nach Beendigung der Ausarbeitungsphase schließen die Arbeitsplanung sowie die Fertigungsmittelkonstruktion und der Fertigungsmittelbau an.

34

3 Systematisierung von Entwicklungsprozessen Phasen / Meilensteine Planen und Klären der Aufgabe

Konzipieren

Entwerfen

Ausarbeiten

Arbeitsplanung

Aufgaben / Tätigkeiten - Erfolgspotentiale, Marktanforderungen und Zahlungsbereitschaft ermitteln - ROI nachweisen - Funktionsstruktur bilden - Wirkprinzipien finden - Wirkstruktur bilden

Resultate Geschäftsplan Entwicklungsauftrag / Anforderungskatalog Lösungskonzeption (Prinziplösung

- Baustruktur festlegen - Baugruppe und Bauteile gestalten - Feingestaltung der Bauteile festlegen - Fertigungszeichnungen und Stücklisten erstellen

Maßstäblicher Entwurf Fertigungszeichnungen und Stücklisten

- Arbeitspläne und NC-Programme erstellen Fertigungsmittelkonstruktion Fertigungszeichungen und Stücklisten für FM Fertigungsmittelbau Komplette Fertigungsunterlagen und FM

Abb. 3.5. Phasenmodell der Produktentwicklung im Maschinenwesen [30]

Im folgenden werden noch kurz die durchzuführenden Schritte für die Phasen Planen und Klären der Aufgabe, Konzipieren, Entwerfen und Ausarbeiten aufgeführt [40]. Planen und Klären der Aufgabe • Ausgangspunkt ist eine neue Produktidee oder ein konkreter Kundenauftrag • Produktvorschläge ausarbeiten und bewerten • Auswahl des erfolgversprechendsten Produktvorschlags • Klären und Präzisieren der Aufgabenstellung Konzipieren • • • • • •

Abstrahieren zum Erkennen der wesentlichen Probleme Aufstellen von Funktionsstrukturen Gesamtfunktion – Teilfunktion Suchen von Wirkprinzipien zum Erfüllen der Teilfunktionen Kombinieren der Wirkprinzipien zur Wirkstruktur Auswählen geeigneter Kombinationen Konkretisieren zu prinzipiellen Lösungsvarianten

3.2 Erfüllen etablierte Prozesse diese Anforderungen?

35

• Bewerten nach technischen und wirtschaftlichen Kriterien • Festlegung der prinzipiellen Lösung Entwerfen • Grobgestalten: Unter Grobgestalten sind solche Tätigkeiten zu verstehen, die die Abmessungen, die Anordnung der Hauptfunktionsträger sowie die Auswahl der Werkstoffe beeinflussen. • Feingestalten: Hierunter fallen Tätigkeiten zur Ausarbeitung der Nebenfunktionen sowie der Bewertung der Lösung nach technischen und wirtschaftlichen Kriterien. • Vervollständigen und Kontrollieren: Abschließend wird die Gestalt optimiert, auf Fehler kontrolliert und eine vorläufige Stückliste sowie Fertigungs- und Montageanleitungen erstellt. Ausarbeiten • Detaillierung und Festlegen von Einzelteilen, Erstellen der Fertigungszeichnung • Zusammenfassen durch Erarbeiten von Gruppenzeichnungen und einer Gesamtzeichnung sowie von Stücklisten • Vervollständigen der Fertigungsunterlagen durch Fertigungs-, Montageund Transportvorschriften sowie Betriebsanleitungen • Prüfen der Fertigungsunterlagen auf Normenanwendungen, Vollständigkeit, Richtigkeit, etc VDI / VDE Richtlinie 2422

Die in Abb. 3.6 [64] dargestellte Konstruktionsmethodik nach VDI 2221 stimmt in ihrem Ablaufplan mit dem Phasenmodell nach Pahl / Beitz vollständig überein [30]. Dies bestätigt, dass die Vorgehensmodelle in der Domäne Mechanik einen hohen Entwicklungsstandard besitzen und sich somit voneinander kaum unterscheiden.

36

3 Systematisierung von Entwicklungsprozessen

Arbeitsschritte

1

Arbeitsergebnisse

Klären und präzisieren der Aufgabenstellung Anforderungsliste

2

Ermitteln von Funktionen und deren Strukturen Suchen n. Lösungsprinzipien und deren Strukturen Prinzipielle Lösungen

4

Gliedern in realisierbare Module

5

Gestalten der maßgebenden Module

6

Gestalten des gesamten Produktes

7

Ausarbeitung der Ausführungs- und Nutzungsangaben

Konzipieren Ausarbeitung der Anforderungsliste Abstrahieren, Aufgliedern der Gesamtfunktion in Teilfunktionen

Funktionsstuktur

3

Konstruktionsphasen Planen Festlegen des Entwicklungsauftrags

Suchen und Kombinieren von Lösungsprinzipien Erarbeitung von Konzeptvarianten, Bewertung Entscheidung

Modulare Struktur

Vorentwürfe

Entwerfen Erstellen eines maßstäblichen Entwurfs Optimieren der Gestaltungszonen Festlegen des bereinigten Entwurfs

Gesamtentwurf

Ausarbeiten Gestalten und Optimieren der Einzelteile Ausarbeitung der Ausführungsunterlagen

Produktdokumentation

Entscheiden (Fertigungsfreigabe)

Abb. 3.6. Konstruktionsprozess nach VDI 2221 [64]

Die Richtlinie VDI 2221 betrachtet ausschließlich die Entwicklung von mechanischen Produkten. Um die Belange mechatronischer Produkte zu berücksichtigen, wurde die Richtlinie VDI / VDE 2422 entwickelt. Die Richtlinie VDI / VDE 2422 beschäftigt sich mit der Entwicklung mechanischer Systeme, die durch den Einsatz von Mikroelektronik gesteuert werden. Da die bisherige Steuerung von mechanischen Geräten mit Hilfe der Elektromechanik durch die Steuerung mittels Mikroelektronik abgelöst wurde, musste ein Vorgehensmodell zur Entwicklung solcher Systeme realisiert werden. Als Grundlage dient das Vorgehen im Maschinenwesen VDI 2221 (Abb. 3.6), das auf die neuen Bedürfnisse angepasst wurde. Es entstand die Richtlinie VDI / VDE 2422, die das Vorgehen empfiehlt, das in Abb. 3.7 zu sehen ist.

3.2 Erfüllen etablierte Prozesse diese Anforderungen? Aufgabenstellung

Aufgabe

Gerätekonzept

Konzept

Software Entwurf

Schaltung Entwurf

Elektromechan. Entwurf

Entwurf

Software Ausarbeitung

Schaltung Ausarbeitung

Elektromechan. Ausarbeitung

Ausarbeitung

Erprobung Gerät

37

Erprobung

Fertigungsfreigabe Serienfreigabe

Abb. 3.7. Vorgehensplan nach VDI / VDE 2422

Bewertung

Die Domäne Mechanik bzw. Elektromechanik tritt als dominierendes Element in den Vordergrund. Den Domänen Elektronik und Softwaretechnik wird eine unterstützende Rolle zugeordnet. Die VDI / VDE-Richtlinie versucht, die etablierten Vorgehensmodelle der beteiligten Domänen aufeinander abzustimmen. Hierbei wird nicht versucht, Komponenten unterschiedlicher Domänen durchgängig gleich zu behandeln bzw. zu modellieren. Das vorgeschlagene Vorgehensmodell ist im Einzelnen wenig detailliert dargelegt. Auf die Entwicklung im Bereich Mechanik wird nicht eingegangen, sondern nur auf die VDI-Richtlinie 2221 / 2222 verwiesen. Die Vorgehensweisen im Bereich Elektronik und Softwaretechnik werden zwar erläutert, aber auch bloß grob umrissen. Die Entwicklung von Regelungskonzepten ist in der Richtlinie nicht vorgesehen. Da die Ergebnisse bei der Gerätekonzeption in natürlicher Sprache verfasst werden, wird ein Raum für verschiedene Interpretationen geschaffen. Ebenso ist so eine rechnerbasierte Weiterverarbeitung nur schwer möglich. Einen Ansatz zur systematischen Modellierung des Gerätekonzepts stellt die Richtlinie nicht zur Verfügung [48].

38 3.2.3

3 Systematisierung von Entwicklungsprozessen Elektronik

Da die Mikroelektronik in einem immer stärkeren Maß Einzug in viele Produkte hält, ist eine systematische und effiziente Entwicklung eingebetteter Mikroelektronik unabdingbar. Elektronik kann in die digitale und die analoge Elektronik unterteilt werden. Die Bedeutung der digitalen Elektronik wächst im Verhältnis zur analogen Elektronik immer weiter an. In mechatronischen Systemen kommt fast ausschließlich die digitale Elektronik zum Einsatz, weshalb hier auch nur auf deren Entwicklung eingegangen wird. Der Entwurf elektronischer Systeme ist momentan durch die folgenden Aspekte gekennzeichnet [45]: • Komplexität und Integrationsdichte steigen zunehmend an • Eine geringere Strukturgröße hat eine höhere Packungsdichte zur Folge, d.h. das elektronische „Innenleben“ von Produkten wird stets komplexer • Die Anforderungen an die Leistungsfähigkeit (Performance) der Elektronik (geringer Platzbedarf, hohe Taktrate, geringer Leistungsverbrauch, hohe Zuverlässigkeit) steigen an • Kürzere Entwicklungszeiten, bedingt durch wachsenden Konkurrenzdruck, sowie steigende Kundenanforderungen. Reduzierung der „time to market“ Eine widerspruchsfreie und verständliche Dokumentation des Produktes ist unabdingbar, da sonst die Komplexität, die Wiederverwendung von Entwurfsdaten sowie die Wartung der Produkte nicht möglich wären. Bei der Entwicklung von digitaler Elektronik kommt das so genannte Sichtenkonzept mit den Sichten • Verhalten, • Struktur und • Geometrie zum Einsatz. Ferner wird eine konsequente hierarchische Entwicklung über mehrere Abstraktionsebenen durchgeführt. Diese Sichten und Abstraktionsebenen sind in Abb. 3.8 und Abb. 3.9 dargestellt.

3.2 Erfüllen etablierte Prozesse diese Anforderungen? Phasen / Meilensteine

Aufgaben / Tätigkeiten

39

Resultate

Spezifikation Pflichtenheft Verhaltens-Synthese - Systemaufbau aus abstrakten Funktionsblöcken - Abstrakte Spezifikation des Verhaltens der Funktionsblöcke - Abstrakte Definition der Daten Systembeschreibung Algorithmische Beschreibung

aus imperativer Sicht (Controller) - Nebenläufig notierte Algorithmen - Umsetzung kausaler Zusammenhänge in Verzögerungszeiten - Umwandlung der abstrakt definierten Daten in Bitstrings Verhaltensbeschreibung

Struktur-Synthese - Elemente: Register, Zähler, Addierer, Mulitplizierer, Multiplexer ... - Modellierung in Taktzyklen (“feinkörniges Timing“) - Hilfsmittel zur Modellierung: Finite State Machnies (FSM) Register-Transfer Beschreibung Logik Beschreibung Transistor Beschreibung

- Boolsche Gleichungen - Zeitliches Verhalten (“set-up-time“, „hold-time“ und „pulse-width-restriction“

Transistoren, Kapazitäten und Widerstände darstellen Verhaltens Pflichtenheft Layout-Synthese Verhaltens Layout

Abb. 3.8. Phasenmodell zur Entwicklung digitaler Schaltungen [30]

Das Y-Diagramm nach Gajski-Walker setzt die in dem Phasendiagramm sequentiell dargestellten Schritte in Y-Anordnung um. Dabei stellen die Äste die drei Sichtweisen dar und die Ringe die unterschiedlichen Abstraktionsebenen. Der Abstraktionsgrad nimmt von innen nach außen zu. Im YDiagramm wird der Entwurf von elektronischen Systemen als eine Reihe von Transformationen (Wechsel der Sichtweise auf einem Abstraktionskreis) und Verfeinerungen (Wechsel der Abstraktionsebene innerhalb einer Sichtweise) dargestellt.

40

3 Systematisierung von Entwicklungsprozessen

Verhalten

Struktur

Systemspezifikation Algorithmen Register-Transfer Boolsche Gleichungen Differentialgleichungen Masken, Polygone

CPUs, Speicher Subsysteme, Busse Module, Leitungen Gatter, Flip-Flops, Leitungen Transistoren, Leitungsstücke Schaltkreis-Ebene Logik-Ebene

Zellen Floorplan

Register-Transfer-Ebene Algorithmische-Ebene

Cluster

System-Ebene

Partitionierung

Geometrie

Abb. 3.9. Y-Diagramm nach Gajski-Walker [45]

Im Folgenden werden die einzelnen Ebenen kurz vorgestellt [30, 45]: • Systemebene: Hier werden die grundlegenden Charakteristika eines elektronischen Systems beschrieben. Blöcke wie Speicher, Prozessoren und Interface-Einheiten finden in der Beschreibung Verwendung. Auf der Systemebene dominiert meist noch die natürliche Sprache bzw. Skizzen als Beschreibungsmittel. • Algorithmische Ebene: Auf der algorithmischen Ebene wird ein elektronisches System oder eine Schaltung durch nebenläufige (d.h. parallel ablaufende) Algorithmen beschrieben. Als Beschreibungselemente kommen hier Prozeduren, Funktionen, Prozesse und Kontrollstrukturen zum Einsatz. Die Struktursicht wird mit allgemeinen Blöcken beschrieben, die über Signale miteinander verknüpft sind. In der Verhaltenssicht wird die Beschreibung des Verhaltens durch eine algorithmische Darstellung mit Variablen und Operatoren vorgenommen. • Register-Transfer-Ebene: Diese Ebene spezifiziert die Eigenschaften einer Schaltung durch Operationen (z.B. Addition) und durch den Transfer der verarbeiteten Daten zwischen Registern. In der Struktursicht kommunizieren Elemente wie Register, Codierer, Multiplexer oder Addierer über Signale miteinander. Dagegen kommen in der Verhaltenssicht vorwiegend Beschreibungen in Form von endlichen Automaten zum Einsatz. In der geometrischen Sicht wird eine Grobeinteilung der Chipfläche vorgenommen. • Logikebene: Die Eigenschaften eines elektronischen Systems werden hier durch logische Verknüpfungen und deren zeitliche Eigenschaften

3.2 Erfüllen etablierte Prozesse diese Anforderungen?

41

beschrieben. Die Struktursicht verwendet zur Beschreibung zusammengeschalteter Grundelemente wie AND-, OR-, XOR-Gatter oder FlipFlops. Die Verhaltenssichtweise verwendet zur Beschreibung vor allem Boolsche Gleichungen (z.B. „ y = (a AND b) XOR c “) oder Funktionstabellen. • Schaltkreisebene: Die Struktursicht besteht hier aus einer Netzliste, die elektronische Bauelemente wie Transistoren, Kapazitäten und Widerstände verwendet. In der Verhaltenssicht werden vor allem Differentialgleichungen verwendet. In der Geometriesicht werden elektronische Systeme durch Polygonzüge dargestellt. Die vorgestellten Entwurfsebenen haben alle ihren spezifischen Zweck. Für die Dokumentation und Simulation des Gesamtsystems eignen sich die Systemebene und die Algorithmische Ebene, die Register-Transfer-Ebene ist für die Blocksimulation und synthesegerechte Modellierung bestimmt und die Logikebene für Simulationen, mit denen beispielsweise die maximale Taktrate einer Schaltung bestimmt wird. Eine eindeutige Einordnung einer Beschreibung in eine bestimmte Ebene ist nicht immer möglich, da die Grenzen zwischen den einzelnen Ebenen gleitend sind. Beschreibungen einzelner Komponenten eines komplexen elektronischen Systems können auch auf unterschiedlichen Abstraktionsebenen liegen. Solche Beschreibungen werden als „Multi-level-Beschreibungen“ bezeichnet [45]. Hardware / Software-Codesign

Aufgrund der zunehmenden Funktionsverschiebung in Richtung Software wurde auch in der Domäne Elektronik der Bedarf an multidisziplinären Entwicklungsprozessen erkannt. Die Entwicklung elektronischer Produkte wurde um die Entwicklungstätigkeiten für die Softwareentwicklung erweitert und in dem Vorgehensmodell „Hardware / Software-Codesign“ erweitert Unter Hardware / Software-Codesign wird die integrative Entwicklung von Hardware und Software verstanden. Dieses Vorgehen wird vor allem bei der Entwicklung eingebetteter Systeme eingesetzt. Für die Entwicklung von Software und Hardware existiert das in Abb. 3.10 dargestellte Vorgehensmodell.

42

3 Systematisierung von Entwicklungsprozessen Vorgehen

Ansätze

Systembeschreibung

W-Beschreibungssprache

HW/SW Partitionierung

Systembeschreibung

Schnittstellenerstellung

Systembeschreibung

Integration

Abb. 3.10. Vorgehen und Modellierungsansätze beim HW / SW-Codesign

Die Systembeschreibung beinhaltet die Anforderungen, die an das zu entwickelnde System gestellt werden. Nach der Systembeschreibung folgt die Hardware / Software-Codesign-Phase. Darunter wird die Aufteilung in Hardware- und Softwareaufgaben verstanden. Weiterhin werden auch die Schnittstellen zwischen Hardware und Software definiert. Diese Tätigkeit wird auch Partitionierung genannt. Es gibt unterschiedliche Vorgehensweisen für die Partitionierung in analoge, digitale und Software Blöcke. 1st level Partitionierung analog-digital HW/SW Partitionierung

analog

1st level Partitionierung Hardware-Software HW/SW Partitionierung

digital

Software

Software

Hardware

Hardware

analog

One level Partitionierung HW/SW Partitionierung

analog

digital

digital

Abb. 3.11. HW-SW und analog-digital Codesign Partitionierungsansätze

digital

3.2 Erfüllen etablierte Prozesse diese Anforderungen?

43

Am häufigsten werden die zweistufigen Ansätze eingesetzt. Bei beiden Ansätzen werden je eine analog / digital Codesign-Phase und eine Hardware / Software Codesign-Phase realisiert (Abb. 3.11). Die Reihenfolge ist jedoch unterschiedlich. Die Erstellung der Hardware und Software erfolgt nach den bereits vorgestellten disziplinenspezifischen Vorgehensmodellen. Unter Verwendung der Schnittstellen werden anschließend die Hardwareanteile und die Softwareanteile integriert. Notwendige Rücksprünge aufgrund nicht zielführender Partitionierung ziehen keine Änderungen in der Systembeschreibung nach sich, da diese unabhängig von der Partitionierungsentscheidung ist. Für die Modellierung der integrativen Systembeschreibung sind drei Ansätze zu unterscheiden: • Nutzung herkömmlicher Programmiersprachen (C, Ada, etc.) • Nutzung von Hardwarebeschreibungssprachen (VHDL, Verilog, etc.) • Einsatz von „High level“-Spezifikationen (SDL, Statecharts, etc) Während sich der erste Ansatz auf die Software und der zweite auf die Hardware konzentriert, abstrahiert der dritte Ansatz durch Verwendung eines Beschreibungsmittels. Hierbei wird die Umsetzung der Spezifikationen der Systembeschreibung abhängig von der Partitionierung mittels Programmiersprache oder Hardwarebeschreibungssprache verlangt. Bewertung

Der Ansatz zeigt die Machbarkeit und Nützlichkeit ganzheitlicher domänenübergreifender Systemkonzeption für zwei Domänen. Die gleichberechtigte Modellierung auf abstraktem Niveau wird angestrebt. Somit wird sichergestellt, dass bei der Modellierung die Komponenten der Softwaretechnik und Elektronik gleichberechtigt behandelt werden. Eine Anpassung bei notwendigen Änderungen ist einfach und nicht zeitintensiv. Die für die Entwicklung mechatronischer Systeme relevanten Domänen Mechanik und Regelungstechnik sind im Hardware / Software-Codesign nicht enthalten. Der Ansatz bietet auch keine Möglichkeit zur integrativen Modellierung von Komponenten dieser Domänen. 3.2.4

Schlussfolgerung

Die Arbeitsgruppe „Entwicklungsprozesse“ des Forschungsprojektes EQUAL hat nach Analyse der Vorgehensmodelle diese auf Grundlage der ermittelten Anforderungen bewertet. Die betrachteten Vorgehensmodelle besitzen in ihren Domänen alle eine Daseinsberechtigung, aber speziell für

44

3 Systematisierung von Entwicklungsprozessen

die Entwicklung eingebetteter Systeme drängt sich keiner der bewerteten Prozesse für einen Einsatz auf. Da eingebettete Systeme meist nicht für sich existieren, sondern Teil eines mechatronischen Produktes, also in einem mechanischen Prozess eingebettet sind, ist folglich eine ganzheitliche Betrachtung des mechatronischen Produktes im Entwicklungsprozess notwendig. Keines der untersuchten Vorgehensmodelle bezieht alle drei Entwicklungsprozesse (Mechanik, Elektronik, Software) ein bzw. berücksichtigt einen Gesamtsystementwurf. Aus diesen Gründen ist ein neuer Ansatz sowohl zur Entwicklung eingebetteter als auch mechatronischer Systeme notwendig. In dem folgenden Kapitel wird der entwickelte Ansatz „3-Ebenen-Vorgehensmodell“ vorgestellt.

3.3

Das 3-Ebenen-Vorgehensmodell

Um den speziellen Belangen der hier betrachteten mechatronischen Systeme bei der Produktentwicklung Rechnung zu tragen, wird eine systematische Vorgehensweise benötigt. Die angestrebte Vorgehensweise muss die in den Kapiteln 3.1 und 3.2 dargestellten Anforderungen erfüllen. Die bisher existierenden Prozesse erfüllen diese nicht oder nur unzureichend. Aufgrund dessen wurde im „Arbeitskreis Entwicklungsprozesse“ des Forschungsprojektes EQUAL das in Abb. 3.12. dargestellte 3-EbenenVorgehensmodell“ entwickelt. Für den interessierten Leser gibt es die Möglichkeit einen zusätzlichen Service zu nutzen. Interaktive Inhalte zum Verbundprojekt EQUAL sind unter www.embedded-quality.de abrufbar. Unter www.methodpark.de/download steht die jeweils aktuellste Version des projekt>kit zur freien Verfügung. Das projekt>kit ist eine htmlbasierte Darstellung des 3-Ebenen-Vorgehensmodells.

3.3 Das 3-Ebenen-Vorgehensmodell System-AnforderungsAnalyse

45

System-Abnahmetest

System-Integration und -Test

System-Entwurf

Kom HWpone n Test ten-

SWFein f ur Entw

hanik Mec eitung arb Aus

Fertigung (Prototypen)

Fertigungsmittelbau

Integ Mechan ik ratio n un d -Te st

M Kom echanik pone nten -Tes t

SW Integ r und ation -Tes t

lyse Ana SW- twurf & En

lyse Ana HW- ntwurf &E

hanik rf Mec Entwu & lyse Ana

HW Integ r und ation -Tes t

IT-Integration und -Test

IT-Anforderungs Analyse & Entwurf

Fertigung Mechanik-Module

Abb. 3.12.Das 3-Ebenen-Vorgehensmodell

3.3.1

Aufbau des 3-Ebenen-Vorgehensmodells

Das 3-Ebenen-Vorgehensmodell ist ein unter Qualitätsgesichtspunkten optimiertes Vorgehensschema für die Entwicklung mechatronischer Produkte. Um besonders die Aspekte der qualitätsorientierten Entwicklung zu berücksichtigen, ist das 3-Ebenen-Vorgehensmodell in einer V-Anordnung dargestellt. Dadurch sind die Querbezüge zwischen den Entwicklungstätigkeiten und den jeweiligen Prüftätigkeiten leicht herzustellen. Um den multidisziplinären Belangen bei der Entwicklung mechatronischer Produkte gerecht zu werden, berücksichtigt das 3-EbenenVorgehensmodell die drei Disziplinen Software, Hardware und Mechanik. Bei einer Umstellung der Produktlandschaft weg von rein mechanischen, elektronischen Produkten bzw. Mischformen dieser beiden Technologien hin zu mechatronischen Produkten ist es zwingend notwendig, auch den Produktentwicklungsprozess auf die neuen Anforderungen hin auszurichten [42]. Firmen nutzen meist bereits einen etablierten Produktentwicklungsprozess, an dem teilweise ganze Firmenstrukturen hängen. Solche Entwicklungsprozesse können nur durch einen anderen ersetzt werden

46

3 Systematisierung von Entwicklungsprozessen

bzw. sind nur mit sehr großem Aufwand einschneidend änderbar. Da das 3-Ebenen-Vorgehensmodell sozusagen die drei Entwicklungsprozesse für eine Software-, Hardware- und Mechanikentwicklung beinhaltet, können die in Firmen gewachsenen und etablierten Produktentwicklungsprozesse nahezu unverändert in das 3-Ebenen-Vorgehensmodell eingegliedert werden. Zur Beherrschung der Komplexität, die gezwungenermaßen mit multidisziplinären Entwicklungsprozessen einhergeht, ist das 3-EbenenVorgehensmodell – wie der Name schon sagt – in drei Ebenen unterteilt: System-, Subsystem- und Komponenten-Ebene. Was sich hinter diesen drei Ebenen und deren Phasen verbirgt, wird im Folgenden genauer betrachtet. Die anschließend dargestellten Entwicklungstätigkeiten auf dem „linken Ast“ des 3-Ebenen-Vorgehensmodells (Abb. 3.12) werden durch zahlreiche Methoden der beteiligten Fachdisziplinen unterstützt, die hier nicht näher erläutert werden. Dies gilt ebenso für die daran anschließenden Prüftätigkeiten des „rechten Asts“. Ausgehend von den gestellten Anforderungen an das zu entwickelnde Produkt erfolgt auf der System-Ebene eine System-Anforderungsanalyse. Im Zuge des daran anschließenden System-Entwurfs wird das Produkt erstmals in einem noch abstrakten Plan dargestellt, der vor allem die (Haupt-)Funktionen des Produktes sowie deren Abhängigkeiten untereinander berücksichtigt. Es entsteht somit eine logische Systemarchitektur, bestehend aus einem Funktionsnetzwerk, den Schnittstellen der Funktionen und der Kommunikation zwischen den Funktionen des gesamten Systems [59]. Auf dieser Basis erfolgt die Partitionierung des Gesamtsystems in Subsysteme. Subsysteme bestehen jeweils aus Funktionsblöcken und stehen miteinander in Verbindung. Bei allen Partitionierungstätigkeiten während des gesamten Entwicklungsprozesses gilt es besonders sinnvolle „Schnitte“ im Systemplan vorzunehmen. Dabei sollte unter anderem darauf geachtet werden, dass zwischen den Subsystemen bzw. Komponenten keine zu engen bzw. zu zahlreichen Kopplungen existieren, da sonst die Komplexität des Entwurfs unnötig ansteigt und die Abhängigkeiten zwischen den Entwicklungsteams steigen [16], was den häufig fehleranfälligen Abstimmungsbedarf zwischen den Fachabteilungen in die Höhe treiben würde. An die Partitionierung anschließend wird die Zuordnung der Subsysteme zu den Disziplinen Mechanik und Informationstechnik (IT) erstellt. Zusätzlich werden Anforderungen abgeleitet und an die beiden Disziplinen übergeben. Auf Subsystem-Ebene werden wiederum die gestellten Anforderungen analysiert und ein Entwurf der nun betrachteten Teilsysteme erstellt. Dabei werden die auf System-Ebene erarbeiteten Funktionen verfeinert. Während die Mechanik-Entwicklung bereits autonom arbeiten kann, müssen die eng

3.3 Das 3-Ebenen-Vorgehensmodell

47

verzahnten Disziplinen Software und Elektronik (Hardware) eine Aufteilung der ihnen zugewiesenen Subsysteme in weitere untergeordnete Subsysteme, die Software- und Hardware-Systemen, durchführen. Die betrachteten Subsysteme werden nun in einzelne Komponenten zerlegt, die dann jeweils nur noch aus einer Technologie bestehen. Gleichzeitig muss bei verteilten Systemen die Zuordnung der einzelnen Software-Bausteine auf die Hardware-Komponenten vorgenommen werden. Hierbei entsteht eine technische Systemarchitektur [59]. Auf unterster Ebene, der Komponenten-Ebene, erfolgt die eigentliche Umsetzung des Produkts. Da das System modular in einzelne Komponenten zerlegt wurde, kann hier arbeitsteilig entwickelt werden. Die Komponenten-Ebene ist gleichzeitig auch die Verbindung zwischen den Entwicklungstätigkeiten des „linken Asts“ und den Prüftätigkeiten des „rechten Asts“ des 3-Ebenen-Vorgehensmodells. Eine weitere Verbindung zwischen den beiden Ästen des Vorgehensmodells wird durch die Übergabe der Testfälle hergestellt. Jeder Testfall, der auf dem „rechten Ast“ zum Einsatz kommt, hat seinen Ursprung in der gegenüberliegenden Spezifikationsphase – also auf dem „linken Ast“ des 3-Ebenen-Vorgehensmodells. Dies wird in Abb. 3.12 durch die horizontalen Pfeile dargestellt. Im Anschluss an die Realisierung der einzelnen Komponenten schließt deren Überprüfung, der Komponenten-Test, an. Auf der Subsystemebene werden die realisierten und getesteten Komponenten integrier, zuerst jeweils in ihrer eigenen Domäne, d.h. es wird eine Software-, Hardware- und Mechanik-Integration mit Integrationstest durchgeführt sowie anschließend das entstandene Subsystems getestet. Danach werden in der Phase „IT-Integration und -Test“ die SW- und HW-Subsysteme zu einem ITSubsystem zusammengeführt und getestet. Aufgrund der vielfach starken Abhängigkeiten zwischen Software- und Hardware-Komponenten ist es in solchen Fällen sinnvoll, bereits sehr früh eine Absicherung – noch vor der eigentlichen IT-Integration – zwischen den genannten Komponenten durchzuführen. Dies wird in dem 3-Ebenen-Vorgehensmodell durch die ineinander verlaufenden Phasen „SW-Integration und -Test“ sowie „HWIntegration und -Test“ berücksichtigt (siehe Abb. 3.12). Auf System-Ebene wird die Integration der Subsysteme IT und Mechanik zu dem Gesamtsystem abgeschlossen. Auch hier ist es oftmals nötig, bereits vor der eigentlichen Integrations-Phase „System-Integration und Test“ eine Absicherung von Mechanik und IT durchzuführen. Abgeschlossen wird der Entwicklungsprozess durch den System-Abnahmetest.

48

3 Systematisierung von Entwicklungsprozessen

3.3.2

Einsatz des 3-Ebenen-Vorgehensmodells bei der Entwicklung mechatronischer Systeme

Wie bereits erwähnt beinhaltet das 3-Ebenen-Vorgehensmodell disziplinenübergreifende Phasen. Diese können auch als Synchronisationspunkte zwischen den einzelnen Disziplinen bezeichnet werden. Die Existenz dieser Punkte auf der Integrations-Seite bringt ein multidisziplinäres Produkt mit sich, da ja die einzelnen Teilsysteme zu einem System verbunden werden müssen. Diese Synchronisationspunkte werden auch als fachliche / technische Synchronisation bezeichnet, da hier immer (Teil-)Produkte integriert werden. Auf der Entwurfsseite hingegen haben die Synchronisationspunkte vor allem die Aufgabe, ein gemeinsames Verständnis aller Beteiligten für das Entwicklungsvorhaben zu schaffen und Arbeitsaufträge für die folgenden Entwicklungsphasen zu erstellen. Hierbei handelt es sich um die so genannten organisatorischen Synchronisationspunkte. Arbeitsgrundlage der Projekt-Teams in diesen Phasen ist ein eingehendes Lastenheft, für das ein Pflichtenheft spezifiziert wird. Ausgehend von dem Pflichtenheft werden wieder Lastenhefte für die darunter liegenden Ebenen-Teams generiert. In der nachfolgenden Ebene wird aus dem eingegangenen Lastenheft ein Pflichtenheft erstellt, das zur Überprüfung an das übergeordnete Ebenen-Team zurückgereicht wird. Die Aufgabe besteht nun darin, die eingehenden Pflichtenhefte auf ihre Konsistenz untereinander zu überprüfen. Auf Grundlage der Pflichtenhefte wird dann ein Vertrag zwischen den jeweiligen Teams der beteiligten Ebenen geschlossen. Abb. 3.13 und Abb. 3.14 zeigen dies am Beispiel der System-Ebene auf. Eingangsdokument

Eingangsdokument

Eingangsdokument

Aus der nächst höheren Ebene bzw. vom Auftraggeber

Aus der nächst höheren Ebene bzw. vom Auftraggeber

Aus der nächst höheren Ebene bzw. vom Auftraggeber

Systemlastenheft

Systempflichtenheft

Mechaniklastenheft IT-Lastenheft Testdokumente für den Systemtest

Abb. 3.13. Dokumente auf den Ebenen

3.3 Das 3-Ebenen-Vorgehensmodell

49

Entwicklungsteam System

Vertrag

Vertrag

prüft

Vertrag Entwicklungsteam IT

Vertrag Entwicklungsteam Mechanik

erstellt

erstellt

Abb. 3.14. Konzept der Zusammenarbeit zwischen den Ebenen

Sollten nun Änderungen nötig sein, so bedarf es immer einer Abstimmung mit den Vertragspartnern, d.h. mit den jeweiligen Ebenen-Teams. Nur so kann garantiert werden, dass vollzogene Änderungen nicht zu Konflikten mit angrenzenden Subsystemen oder Komponenten führen. Da eine Produktentwicklung typischerweise nicht in einem Durchlauf des Entwicklungsprozesses von statten geht, beruht das 3-Ebenen-Vorgehensmodell auf einer iterativen Vorgehensweise. Eine solche Vorgehensweise ist in Abb. 3.15 exemplarisch dargestellt. Beispielsweise ist es einerseits möglich, dass eine SW-Komponente den SW-Komponenten-Test nicht besteht und die nötige Nacharbeit eine weitere Iteration des entsprechenden Entwicklungszyklus notwendig macht. Andererseits wird hier auch berücksichtigt, dass z.B. eine SWKomponente erst realisiert werden kann, wenn eine andere (Basis-)SWKomponente bereits existiert. Auch hierfür ist ein weiterer Durchlauf des entsprechenden Teils des Vorgehensmodells notwendig. Um solche Iterationen optimal zu gestalten, muss die Reihenfolge der Entwicklungsschritte bereits in den organisatorischen Synchronisationspunkten geplant werden. Nur so können die zur Verfügung stehenden Ressourcen optimal eingesetzt und ein reibungsloser Ablauf garantiert werden.

selin eB

IT-Ba selin eC IT-Ba Mec selin h eD a n Mec ik-Ko h Mec anik-Ko mponen mpo hanik te X ne -Kom pon nt e Y ent e Z

IT-Ba SW-K omp SW one SW-K -Kompon nt e X en omp onen te Y te Z

HW HW-K -Kompo n HW-K ompone ente X nte Y omp onen te Z

selin eA

3 Systematisierung von Entwicklungsprozessen

IT-Ba

50

Abb. 3.15. Iterativ / inkrementelle Vorgehensweise

Mit Einhaltung dieser Voraussetzung sind notwendige Tests bereits auf diesen Baselines möglich. Des Weiteren sollten keine Komponenten auf einer Baseline vorhanden sein, die nicht getestet werden können, da etwa dazu nötige Komponenten nicht vorhanden sind. Die Bestandteile einer Baseline müssen immer schon in dem dazugehörigen organisatorischen Synchronisationspunkt auf dem „linken Ast“ des 3-Ebene-Modells in Form eines Integrationsplans festgehalten werden. Die Baseline ist sozusagen eine ausgetestete Grundlage für weitere Entwicklungstätigkeiten. Solche Baselines finden sich natürlich auf der System-Ebene auch wieder. Hier kommen dann Mechanik-Komponenten und MechanikSubsysteme sowie IT-Subsysteme, teilweise in Form von IT-Baselines, zum Einsatz. Die so erreichbare frühzeitige Absicherung und stetige Synchronisation von Entwicklungsergebnissen spielt eine Schlüsselrolle bei der termingerechten und budgetgerechten Produktentwicklung. Denn je später ein Fehler auftritt und je größer die darauf folgende Iterationsschleife ist, umso größer wird der Terminverzug und die Kostensteigerung ausfallen.

4 Systematisierung von Qualitätssicherungsmaßnahmen

Um die Produkt-Qualität bei gleichzeitiger Reduzierung des Entwicklungsaufwandes zu erhöhen, ist es notwendig die Prozess-Qualität zu erhöhen. Dies wird durch den Einsatz von QS-Maßnahmen erreicht. Die Einführung einer neuen QS-Maßnahme stellt anfangs eine Erhöhung des zeitlichen und finanziellen Aufwands dar. Deshalb ist es besonders wichtig, Maßnahmen mit einem guten Kosten-Nutzen-Verhältnis anzuwenden. Aufgrund der unterschiedlichen Firmenstrukturen und der sich stark unterscheidenden Entwicklungsprojekte lässt sich jedoch kein StandardKatalog von zu empfehlenden Maßnahmen erstellen. Es müssen stattdessen die vorhandenen Randbedingungen betrachtet werden. Dazu zählen u.a. die Produktarten eines Unternehmens und die allgemeine Unternehmensstruktur. Auch zu berücksichtigen ist, welche QS-Maßnahmen bereits eingesetzt werden und um welche Art von Entwicklung, beispielsweise Neu- oder Anpassungsentwicklung, es sich handelt. Ausgehend von diesen Randbedingungen ist für das jeweilige Projekt bzw. Unternehmen eine geeignete Auswahl an QS-Maßnahmen zu treffen. Um Unternehmen die Möglichkeit zu geben, effizienter die passenden Maßnahmen auszuwählen, wurden im Rahmen des Projekts EQUAL die von den Industriepartnern als am wichtigsten eingeschätzten QSMaßnahmen ausgewählt und zu einem Maßnahmenkatalog zusammengefasst. Innerhalb des Maßnahmenkatalogs sind die entsprechenden Maßnahmen ausführlicher erläutert. Dabei wurde besonderer Wert darauf gelegt, die Maßnahmen übersichtlich darzustellen, um sie so miteinander vergleichen und einzeln bewerten zu können. So wird eine systematische produkt- und unternehmensspezifische Auswahl von QS-Maßnahmen ermöglicht. Ergebnis ist eine Darstellung der QS-Maßnahmen in tabellarischer Form. Der Aufbau eines solchen QSM Datenblatts besteht aus insgesamt 14 unterschiedlichen Kategorien (siehe Tabelle 4.1).

52

4 Systematisierung von Qualitätssicherungsmaßnahmen

Tabelle 4.1. 14 Kategorien der QSM-Datenblätter Bezeichnung Synonyme Querverweise

Kurzbeschreibung Relevanz Klasse Ziel Entwicklungsphase Vorteile Nachteile Voraussetzungen

Arbeitsmittel

Fehlerbezug

Referenz

Gängiger Name der QS-Maßnahme Anderer, in der Literatur und/oder in der Praxis gebräuchlicher Name für die gleiche Maßnahme Verweis auf andere QS-Maßnahmen, die entweder Bestandteil der beschriebenen Maßnahme sind oder diese beinhalten Kurze Beschreibung der betrachteten QS-Maßnahme Relevanz für „Embedded Quality“ entsprechend der Anwenderbewertung (gering / mittel / hoch) Klassifizierung der betrachteten QS-Maßnahme in konstruktive, analytische und organisatorische Maßnahmen Welche Ziele verfolgt die beschriebene QS-Maßnahme? In welcher bzw. welchen Phase/n wird die beschriebene Maßnahme eingesetzt? Vorteile der beschriebenen Maßnahme gegenüber anderen Maßnahmen mit ähnlicher oder gleicher Zielsetzung Nachteile der beschriebenen Maßnahme gegenüber anderen Maßnahmen mit ähnlicher oder gleicher Zielsetzung Welche Voraussetzungen müssen z.B. in Bezug auf Mitarbeiterqualifikation oder Einsatz anderer Methoden erfüllt sein, um die beschriebene Methode sinnvoll einsetzten zu können? Welche Arbeitsmittel (z.B. HW, Tools) sind für die Anwendung der beschriebenen Maßnahme erforderlich bzw. sinnvoll? Welche Klasse von Fehlern (z.B. Schnittstellenfehler, Laufzeitfehler, Spezifikationsfehler) werden durch die beschriebene Maßnahme vornehmlich erkannt bzw. vermieden? Quellen der Datenerhebung und weiterführende Beschreibungen

In den beiden ersten Kategorien werden eine gängige, im Rahmen des Projekts verwendete Bezeichnung der zu beschreibenden Maßnahme und eventuelle Synonyme angegeben. In der Kategorie Querverweise sind Verweise auf mit der Maßnahme in Verbindung stehende QSM zu finden. Dies erlaubt ein gesamtheitliches, maßnahmenübergreifendes Verständnis. Unter Kurzbeschreibung wird die Maßnahme knapp beschrieben. Da die QSM-Datenblätter nur einen Überblick geben sollen und nicht das Ziel

53

haben, die jeweilige Maßnahme vollständig und detailliert zu beschreiben, konzentrieren sich die Kurzbeschreibungen auf den Fokus der QSM. Die für den Maßnahmenkatalog ausgewählten Maßnahmen wurden unter der Kategorie Relevanz in gering, mittel und hoch unterteilt. Mit dieser Kategorisierung soll keine Aussage über den prinzipiellen Nutzen einer Maßnahme getroffen, sondern nur eine Einschätzung über die bisherige praktische Bedeutung in der Industrie gegeben werden. Die behandelten Maßnahmen werden unterteilt in die drei Klassen konstruktiv, analytisch und organisatorisch. In die Klasse konstruktiv fallen alle QSM, die die Produkte bzw. Prozesse aktiv verbessern, d.h. einen direkten präventiven Einfluss auf diese haben. Darunter fallen beispielsweise alle Spezifikations- und Entwurfsmethoden. Analytische Qualitätssicherung bringt keine Qualität unmittelbar in das Produkt oder den Entwicklungsprozess, vielmehr werden durch sie die existierende Qualität geprüft und gemessen und die vorhandenen Schwachstellen bzw. Fehler analysiert. In dieser Klasse sind beispielsweise sämtliche Testmethoden wiederzufinden. In der Klasse der organisatorischen QS sind alle Maßnahmen eingereiht, die die beiden anderen Klassen mit organisatorischen Mitteln unterstützen, wie beispielsweise Programmier- oder Dokumentationsrichtlinien [29]. In der Kategorie Ziel werden die konkreten Ziele der Maßnahme festgehalten. Sämtliche Maßnahmen werden in der Kategorie Entwicklungsphase in die Prozessphase/n des 3-E Modells eingeordnet, in denen sie zur Anwendung kommen. In den beiden Kategorien Vorteile und Nachteile wird eine Bewertung der Maßnahmen gegenüber anderen Maßnahmen mit ähnlicher oder gleicher Zielsetzung vorgenommen. Unter Voraussetzungen und Arbeitsmittel sind die für die erfolgreiche Anwendung der Maßnahme notwendigen, bereits eingesetzten Methoden bzw. einzusetzenden Hilfsmittel und Werkzeuge aufgelistet. Abhängig von der Klasse der jeweiligen QSM, werden unter Fehlerbezug die mit dieser Maßnahme vermeidbaren bzw. zu entdeckenden Fehler genannt. In der letzten Kategorie Referenz werden Literaturangaben auf weitere, detailliertere Quellen gegeben. Sämtliche der im Projekt betrachteten QS-Maßnahmen wurden mit Hilfe dieser 14 Kategorien beschrieben. Eine Auflistung der im Maßnahmenkatalog abgelegten QS-Maßnahmen (Anhang) ist in Tabelle 4.2 dargestellt. Insgesamt sind im QS-Maßnahmenkatalog 20 analytische, 14 konstruktive und 22 organisatorische QS-Maßnahmen in Form von QSM-Datenblättern beschrieben.

54

4 Systematisierung von Qualitätssicherungsmaßnahmen

Tabelle 4.2. Auflistung der QSM aus dem QS-Maßnahmenkatalog (Anhang) Analytisch

Konstruktiv

Organisatorisch

Abnahmetest

Anforderungsanalyse

Änderungsmanagement

Akzeptanztest

Anforderungsverfolgung

Checklisten

Black-Box Test

Code-Generierung

Defect Management

Codeanalyse

Defensive Programmierung

Designrichtlinien

Datenflussanalyse

Endliche Automaten

Dokumentation von Entscheidungen

FMEA

Petrinetze

Dokumentationsrichtlinien

Inbetriebnahmetest (für eine mechatronische Komponente)

Prototyping

Dokumentationssysteme

In-circuit-Emulation

SA/SD

Dokumentenvorlagen

Installationstest

SDL

Fehlerdatenbank

Instrumentierung

Sequenzdiagramme

Festlegung des Engineering-Modells

Integrationstest

Simulation zur Anforderungs- bzw. Entwurfsabsicherung

Glossar/Terminologie

Komplexitäts- und Timing-Analyse

SW-Architekturentwurf

Versions- und Konfigurationsmanagement

Metriken

UML

Phasen- und Projektreview

Modultest

Wiederverwendung von Projektergebnissen

Programmierrichtlinien

Regressionstest

Projektaudits

Review und Inspektion

Q-Berichterstattung

Schreibtischtest

QS-Handbuch (unternehmensspezifisch)

Simulation zu Testzwecken

QS-Handbuch (projektspezifisch)

Stresstest

Qualitätsplanung für den Entwicklungsprozess

Walkthrough

Risikomanagement

White-Box Test

Testabdeckungsmatrix Unabhängige Testgruppen

5 Methodik des virtuellen Funktionstests

Mechatronische Produkte beziehen ihre Funktionalität aus dem Zusammenwirken mechanischer und informationsverarbeitender Komponenten. Diese haben meist komplexe Algorithmen implementiert, weswegen die Produkt-Funktionalität nur durch vollständige Berücksichtigung aller Produkt-Schnittstellen geprüft werden kann. Dies beinhaltet im Allgemeinen sowohl die Schnittstellen zur Kommunikation mit dem Bediener oder anderen Geräten als auch die Wechselwirkungen mit dem technischen Prozess. Ein Hilfsmittel für die im Entwicklungsprozess frühzeitige, durchgängige und entwicklungsbegleitende Anforderungsüberprüfung ist der so genannte virtuelle Funktionstest (im Folgenden: VFT). Dabei werden durch den Einsatz virtueller Techniken Gesamtsystem-Funktionstests in frühere Entwicklungsphasen vorverlagert, bei denen das reale Produkt noch nicht vollständig verfügbar ist. Im Folgenden werden dazu zunächst das Prinzip zur Realisierung der Vorverlagerung skizziert sowie alle notwenigen Begriffe eingeführt und erläutert. Anschließend werden die unterschiedlichen Ausprägungen des VFT je nach Phase im Entwicklungsprozess vorgestellt. Schließlich wird detaillierter auf die konkrete Umsetzung des VFT eingegangen. Das Kapitel endet mit einer Zusammenfassung und Bewertung.

5.1

Prinzip und Begrifflichkeit

Ziel der VFT ist die Vorverlagerung des System-Abnahmetests in frühere Phasen des Entwicklungsprozesses. Die Gründe für dieses Bestreben sind vielfältig: Der System-Abnahmetest ist ein Test aus Sicht des Kunden und kann deshalb wie kaum eine andere Maßnahme mögliche Fehler, insbesondere aber auch die besonders kritischen Spezifikationsfehler aufzeigen. Je früher letztere im Entwicklungsprozess aufgedeckt werden können, desto besser können zeit- und kostenintensive Iterationsschleifen im Entwicklungsprozess vermieden werden. Dabei ist der System-Abnahmetest aufgrund seiner funktionalen Ausrichtung, d.h. Black-Box-Sicht, ohne

56

5 Methodik des virtuellen Funktionstests

besondere Kenntnis über die Realisierung der z.T. sehr komplexen Systembestandteile und deren Zusammenhänge durchführbar. Da die Testfälle sich auf das Systemlastenheft stützen, welches üblicherweise zu Projektstart bereits verbindlich festgeschrieben sein sollte (Kapitel 3.3 „Das 3Ebenen-Vorgehensmodell“), besteht theoretisch bereits ab Projektstart die Möglichkeit zu deren Anwendung. Benötigt wird dazu lediglich ein testbares Objekt. Beim VFT wird davon ausgegangen, dass zur Durchführung der meisten Tests das Endprodukt in seiner realen Ausprägung nicht vorhanden sein muss. Funktionstests können bereits am komplett oder teilweise virtuellen System durchgeführt werden. Somit ist es möglich, Zwischenprodukte frühzeitig im Entwicklungsprozess unter Zuhilfenahme der aussagekräftigen System-Abnahmetests zu prüfen, wobei nicht real existierende Systemteile virtuell bereitgestellt, das heißt simuliert werden müssen. Den Grad der Virtualität bestimmen dabei zwei Einflussgrößen. Dies ist zum einen der Grad der Vollzähligkeit der zur Anwendung kommenden Systemkomponenten, zum anderen der Grad ihrer jeweiligen Entwicklungstiefe. Dabei bezieht sich der Grad der Vollzähligkeit auf die Summe der für den VFT zur Verfügung stehenden (Teil-)Komponenten des mechatronischen Systems, der Grad der Entwicklungstiefe auf das Entwicklungsstadium dieser Teilkomponenten im Entwicklungsprozess. Abb. 5.1 verdeutlicht den Zusammenhang grafisch. Grad der Entwicklungstiefe der Systemkomponenten

Zu na hm

e

de rV

ir t

ua litä td es

VF T

Reales Endprodukt

Grad der Vollzähligkeit der Systemkomponenten

Abb. 5.1. Grad der Virtualität des VFT

5.2 Ausprägungen im Entwicklungsprozess

57

Man erkennt, dass der System-Abnahmetest am realen Produkt sozusagen einem VFT entspricht, bei dem der Grad der Virtualität 0 ist. Von der anderen Seite her betrachtet wird deutlich, dass es offenbar eine Vielzahl von Ausprägungen des VFTs gibt. Das anschließende Kapitel gibt eine detaillierte Diskussion signifikanter Ausprägungen und stellt den Bezug zum Entwicklungsprozess her.

5.2

Ausprägungen im Entwicklungsprozess

Im 3-Ebenen-Vorgehensmodell (Kapitel 3.3) betrachtet werden die unterschiedlichen Ausprägungen des VFT besonders deutlich (Abb. 5.2). Man erkennt, dass VFTs während des gesamten Entwicklungsprozesses möglich sind. Im rechten Ast des Vorgehensmodells äußert sich der VFT als Test fertig gestellter Komponenten oder Subsysteme, die unter Zuhilfenahme geeigneter Mittel und Techniken wie z.B. Umgebungssimulationen nicht gegen die Systemspezifikation auf ihrer Ebene, sondern gegen die Gesamtsystemspezifikation getestet werden. Der Grad der Virtualität ergibt sich hierbei also vor allem durch die Unvollständigkeit der Anzahl der zur Verfügung stehenden Systemkomponenten.

SystemEbene

SubsystemEbene

Abnahmetest

VFT

VFT

VFT

KomponentenEbene VFT

VFT

Abb. 5.2. Zuordnung des VFT im Entwicklungsprozess

58

5 Methodik des virtuellen Funktionstests

Der linke Ast des Vorgehensmodells beinhaltet die Spezifikations- und Entwurfsphasen. Zu diesem Zeitpunkt hat die Entwicklung noch nicht die Phase der Umsetzung erreicht, was den Grad der Virtualität erheblich verstärkt (Abb. 5.3). Dynamische Tests wie der VFT können in diesen Phasen nur ablaufen, wenn Spezifikationen in Form von ablauffähigen Modellen vorliegen. Grad der Virtualität

Analyse

Design

Umsetzung

Test

Virtueller Funktionstest

Abb. 5.3. Grad der Virtualität bezogen auf Entwicklungsphasen

Nachfolgende Tabelle gibt ausgehend vom Testobjekt einen detaillierteren Überblick über einige exemplarische Ausprägungen des VFTs. Dabei fällt auf, dass bei allen aufgelisteten Ausprägungen die Applikationssoftware in realer oder modellierter Form Teil des Testobjekts ist. Dies hat den Grund, dass sie in entscheidender Weise zur Funktionserbringung bei mechatronischen Produkten beiträgt. Eine Durchführung von VFTs zur frühzeitigen Validierung der Gesamtfunktionalität erscheint deswegen nur mit ihr sinnvoll. Aufgrund des iterativen Vorgehens während der Entwicklung können die aufgelisteten, im Mittelpunkt des VFT stehenden Testobjekte nicht definitiv einer Phase im 3-Ebenen-Modell zugeordnet werden. Tabelle 5.1 macht der Übersichtlichkeit und Verständlichkeit halber dennoch einen Versuch.

5.3 Umsetzung des virtuellen Funktionstests

59

Tabelle 5.1. Exemplarische Ausprägungen des VFT Testobjekt (Ebene)

Erläuterung

Hardware (rechter Ast - Subsystemebene)

Die Hardware inkl. Software wird in ein Testbett integriert, das sowohl die Schnittstellen zu benachbarten Geräten als auch den Prozess abdeckt. Die Software wird in ein Testbett integriert und zur Ausführung gebracht, welches der realen Hardware entspricht. Die Applikationssoftware wird in ein Testbett integriert und zur Ausführung gebracht, welches dem System Hardware – Treiber – Betriebssystem entspricht. Ein funktionales Modell der Applikationssoftware wird in ein Testbett integriert und zur Ausführung gebracht, welches dem System Hardware – Treiber – Betriebssystem entspricht. Ein funktionales Modell des ITSystems wird in ein Testbett integriert, das sowohl die Schnittstellen zu benachbarten Geräten als auch den Prozess abdeckt. Ein funktionales Modell des Gesamtsystems wird in ein Testbett integriert, mit dem eine Vielzahl testbarer funktionaler Aspekte der Systemspezifikation überprüft werden können.

Software (rechter Ast - Komponentenebene)

Applikationssoftware (rechter Ast - Komponentenebene)

Applikationssoftware-Spezifikation (linker Ast - Komponentenebene)

IT-Systemspezifikation (linker Ast - Subsystem-Ebene)

Gesamtsystem – Systemspezifikation (linker Ast - Systemebene)

5.3

Umsetzung des virtuellen Funktionstests

Nach der Diskussion über die möglichen Ausprägungen des VFTs wird im Folgenden betrachtet, wie passend zu einer spezifischen Ausprägung des VFT geeignete Testbetten aufwandsarm zur Verfügung gestellt werden können. Ferner wird betrachtet, wie sinnvolle Testfälle ausgewählt und zur Anwendung kommen können. Dabei wird der Schwerpunkt auf eine möglichst hohe Wiederverwendbarkeit im Laufe der weiteren Entwicklung gelegt.

60

5 Methodik des virtuellen Funktionstests

Prinzipiell können die Tests manuell durch den Tester durchgeführt werden, sofern das jeweilige Testbett eine entsprechende Bedienschnittstelle vorsieht. Oftmals haben mechatronische Produkte jedoch komplexe Diagnose-Algorithmen implementiert, die das System bei ungewöhnlichem Verhalten der Systemumgebung in einen Fehlerzustand wechseln lassen. Diese Funktionalität ist in der Applikationssoftware implementiert, die, wie bereits diskutiert, bei allen hier angesprochenen Ausprägungen des VFTs Teil des Testobjekts ist. Zur manuellen Testdurchführung werden dann trotzdem geeignete Umgebungssimulationen benötigt, welche ein adäquates Verhalten der Systemumgebung kontinuierlich simulieren. Aus Aufwands- bzw. Effizienzgründen sowie Gründen der Reproduzierbarkeit wird im Folgenden bei der Durchführung der VFTs von der Zuhilfenahme eines Testautomaten ausgegangen. Dabei ist die Zielsetzung, die Testfälle für einen Testautomaten, jedoch unabhängig von einer konkreten Ausprägung des VFTs, zu spezifizieren bzw. zu implementieren. Dann können sie aufwandsarm bei mehreren unterschiedlichen Ausprägungen des VFTs zur Anwendung kommen. Wenn die Testfälle für den VFT sowie deren Implementierung also eine Konstante während der Entwicklung sein sollen, das Testobjekt jedoch potentiell in verschiedenen Ausprägungen vorliegen kann, dann muss dazwischen eine Anpassung an die tatsächlich vorliegende Testsituation erfolgen. Eine derartige Anpassung kann über sog. Konkretisierer und Abstrahierer erfolgen (Abb. 5.4). Konkretisierer Test-Suite

Testautomat

Abstrahierer

Konkretisierer Abstrahierer

Testfälle

TestObjekt

TestObjekt

Test-PC Konkretisierer Abstrahierer

Konkretisierer Test-Protokoll

Abstrahierer

TestObjekt

TestObjekt

Abb. 5.4. Durchführung der VFTs mit Hilfe von Abstrahierer und Konkretisierer

5.3 Umsetzung des virtuellen Funktionstests

61

Der Konkretisierer hat die Aufgabe, die semantisch auf einer höheren Ebene liegenden Testdaten, insbesondere die Stimuli, für das spezifische Testszenario zu übersetzen. Der Abstrahierer hat dagegen die entgegengesetzte Aufgabe, die Antworten des Testobjekts auf die semantische Ebene der Testfallbeschreibung zu heben, sodass sie vom Testautomaten korrekt ausgewertet werden können. Im Leitfaden kann diesbezüglich im Kapitel 9.4 eine beispielhafte Umsetzung für ein Reglersystem nachgeschlagen werden. Die Konkretisierer und Abstrahierer können in unterschiedlicher Weise zur Verfügung gestellt werden. Im extremen Fall stellen sie eine detailgenaue virtuelle Umgebung aller nicht im Testobjekt vereinigten Systembestandteile dar und bauen auf diese Weise zusammen mit dem Testobjekt ein detailgetreues virtuelles Gesamtsystem auf. Auf diesem können dann die spezifizierten Testfälle zur Ausführung gebracht werden. Dies ist jedoch im Allgemeinen, besonders in den frühen Phasen der Entwicklung, gar nicht möglich, jedoch auch nicht notwendig. In den Spezifikationsphasen zum Beispiel stehen detaillierte Modelle aller Teile des Gesamtsystems noch gar nicht fest, geschweige denn zur Verfügung. Ziel eines VFTs wäre zu diesem Zeitpunkt jedoch gar nicht, Detailfragen wie nach den Auswirkungen von Toleranzen, dem Laufzeitverhalten, dem Speicherbedarf der Applikation oder möglichen Auswirkungen beim Gebrauch von FixpunktArithmetik zu überprüfen. Vielmehr geht es in diesen Phasen um die Validierung der Spezifikation auf Korrektheit und Vollständigkeit. Der Detaillierungsgrad von Konkretisierer und Abstrahierer kann daher dementsprechend rudimentär ausfallen. Womöglich genügt eine einfache Übersetzung von Systemgrößen wie Prozessgrößen in einfache Variablengrößen des ablauffähigen Modells und zurück. Auch in späteren Phasen, beispielsweise beim Test der Applikationssoftware, wird nicht für alle Tests ein vollständiges, detailgenaues Modell der Systemumgebung benötigt. Dazu soll als nächstes schematisch der Aufbau eines mechatronischen Produkts betrachtet werden (Abb. 5.5). Die Betrachtung erfolgt von „innen“ nach „außen“. Im Zentrum des mechatronischen Produkts steht die Applikationssoftware. Sie beinhaltet die Algorithmen zur Steuerung und Regelung des Produkts und ist auf diese Weise maßgeblich für sein Verhalten verantwortlich. Im allgemeinen Fall stützt sich die Applikationssoftware auf ein Betriebssystem, das beispielsweise die Prozess-Koordination, aber auch über Treiber die Kommunikation mit der Hardware übernimmt. Die Hardware wiederum ist über Kommunikationsschnittstellen mit anderen Geräten oder Sensoren und Aktoren verbunden. Diese stellen schließlich die Verbindung zur physikalischen / mechanischen Ebene des mechatronischen Produkts her.

62

5 Methodik des virtuellen Funktionstests

Physik / Mechanik Hardware Treiber Betriebssystem ApplikationsSoftware Betriebssystem Treiber Hardware Physik / Mechanik

Abb. 5.5. Schematischer Aufbau eines mechatronischen Produkts

Durch den geschichteten Aufbau kann auf die detailgenaue virtuelle Ausgestaltung aller Ebenen, die nicht unmittelbar an die des Testobjekts grenzen, verzichtet werden. Sogar die angrenzende Ebene muss nicht detailgenau nachgebildet werden – dies gilt lediglich für die Schnittstelle zum Testobjekt. So ist es durchaus denkbar, eine Applikationssoftware im Rahmen des VFT auf einem anderen Betriebssystem laufen zu lassen als im späteren mechatronischen Produkt. Die API des vorgesehenen Betriebssystems muss allerdings zur Verfügung stehen bzw. geeignet nachgebildet werden. Auch ist es denkbar, die Hardware auszutauschen und einen anderen Prozessor zu verwenden – die Applikationssoftware muss dann allerdings für diesen compiliert werden oder es muss eine geeignete Prozessor-Emulation existieren. Eine beispielhafte Ausführung dieses Szenarios wird im Leitfaden im Kapitel 9.2 Simulation zu Testzwecken beschrieben. Hier wird ein VFT der Applikationssoftware eines elektrischen Antriebsreglers beschrieben, der auf dem Entwicklungsrechner durchgeführt wird. Freilich lassen sich durch die vorgenommene Abstraktion wieder nicht alle Eigenschaften des späteren Produkts überprüfen. Als Beispiele seien die Laufzeiteigenschaften oder die Auswirkungen der meist erheblich verringerten Rechengenauigkeit genannt. Jedoch lassen sich aus funktionaler Sicht des Gesamtsystems bereits die meisten Tests sinnvoll durchführen und auf diese Weise schon in einem frühen Stadium wertvolle Aussagen über Vollständigkeit, Reifegrad und prinzipielle Funktionstüchtigkeit der Implementierung gewinnen. Dabei bleibt der Aufwand verhältnismäßig gering, weil der VFT komplett auf dem Entwicklungs-Rechner

5.4 Fazit und Bewertung

63

abläuft, d.h. ohne zusätzlich Hardware wie Hardware-Emulatoren oder Eval-Boards auskommt. Dies erleichtert zudem die Fehlerdiagnose.

5.4

Fazit und Bewertung

Als Fazit kann festgestellt werden, dass durch den VFT bereits frühzeitig im Entwicklungsprozess wertvolle Erkenntnisse bezüglich der korrekten und vollständigen Umsetzung der Entwicklungsaufgabe gewonnen werden können. Aufgrund der Tatsache, dass sich der VFT auf die Systemspezifikation des Gesamtsystems stützt, können VFTs bereits in den Spezifikationsphasen durchgeführt werden, sofern Spezifikationen in Form von ablauffähigen Modellen vorliegen. Dies bedeutet, dass der VFT ein adaptierbares Prinzip beschreibt, das je nach Entwicklungsprozess, -produkt und sonstigen Rahmenbedingungen in individuellen Ausprägungen in Firmen zur Anwendung kommen kann. Dabei kann neben dem unmittelbaren Nutzen in Form einer Teilergebnisvalidierung die Wirkung des VFTs zusätzlich verstärkt werden, wenn er mehrfach und synchronisiert im Entwicklungsprozess eingesetzt wird. So kann beispielsweise durch den VFT auf Spezifikationsebene das Anforderungsmodell der Applikationssoftware auf ihren Einklang mit der Systemspezifikation überprüft werden. Dieses so getestete Modell kann als Grundlage für eine automatische Testfallgenerierung dienen. Dabei werden Testvektoren inkl. erwarteter Systemreaktionen geliefert, die im Rahmen eines weiteren VFTs später im Entwicklungsprozess für die umfangreiche und automatisierte Überprüfung der inzwischen separat entwickelten Applikationssoftware dienen kann. Letztendlich bleibt es also den Anwenderfirmen vorbehalten, den Nutzen und den Aufwand des VFTs bezogen auf ihre Entwicklungsprojekte abzuwägen und ggf. ein für ihre spezifische Situation sinnvolles Maßnahmenpaket an Ausprägungen des VFTs einzuführen. Denn zweifelsohne ist der VFT eine mächtige Maßnahme, um die Produkt-Qualität auch im Umfeld der immer komplexer werdenden mechatronischen Systeme effektiv sicherzustellen und Entwicklungsfehler bereits möglichst frühzeitig im Entwicklungsprozess zu finden.

Leitfaden

6 Bestandsaufnahme bei den Projektpartnern

Zu Beginn des Forschungsprojektes EQUAL wurde zur Bestimmung der Ausgangslage bei allen Projektpartnern eine Bestandsaufnahme hinsichtlich der eingesetzten Qualitätssicherungs-Maßnahmen sowie der Ausprägung der Entwicklungsprozesse durchgeführt. Die Bestandsaufnahme als Ausgangspunkt des Forschungsprojektes klärt die Fragen, welche QSMaßnahmen von den am Forschungsprojekt beteiligten Firmen eingesetzt werden und welche Dokumente üblicherweise bei Projektabwicklungen im Rahmen des Entwicklungsprojektes eingesetzt werden. Inhalt und Ausprägung der QS-Maßnahmen, Dokumente und Entwicklungsprozesse waren nicht Gegenstand der Bestandsaufnahme. Die Bestandsaufnahme wurde genutzt, die gesammelten QS-Maßnahmen von allen beteiligten Firmen nach ihrer Bedeutung in der Praxis zu bewertet. Im weiteren Verlauf des Forschungsprojektes wurden zum einen Datenblätter für die einzelnen QS Maßnahmen erstellt (siehe Kapitel 4 und Anhang), zum anderen wurden die QS Maßnahmen selbst in Form von Praxisbeispielen von Projektpartnern beschrieben (siehe Kapitel 8). Die ausführlichen Inhalte hierzu befinden sich in den entsprechend angegebenen Kapiteln.

6.1

Vorgehensweise

Die Bestandsaufnahme fand in Form von Interviews bei den verschiedenen Anwenderunternehmen direkt vor Ort statt. Am Interview waren jeweils beteiligt: • Der verantwortliche EQUAL-Ansprechpartner / Projektleiter aus dem jeweiligen Anwenderunternehmen • Projektmitglieder (aus eventuell verschiedenen Projekten) des Anwenderunternehmens • Mitarbeiter der Forschungsinstitute der TU München • Ein Mitarbeiter des Dienstleistungsunternehmens method park, der das Interview moderierte

68

6 Bestandsaufnahme bei den Projektpartnern

Als Hilfsmittel zur Dokumentation des Interviews wurde ein Dokumentenplan verwendet (siehe Kapitel 6.1.2 – Der Dokumentenplan). Dieser wurde von method park bereits in vorherigen Beratungsprojekten außerhalb des EQUAL-Projektes routinemäßig als Werkzeug zur Strukturierung von Software-Entwicklungsprozessen eingesetzt. Im Wesentlichen ist dieser Dokumentenplan in die vier klassischen Projektplanungsparameter: Phase, Rolle, Methode und Teilergebnis untergliedert. Die Phasen stellen eine Art innere Uhr von Projekten dar. Die Rollen nehmen Bezug zu den Fragestellungen „Wer macht was?“ und „Wer ist wofür verantwortlich?“. Teilergebnisse sind in der Software-Entwicklung immer Dokumente. Methoden beschreiben, wie Abschnitte des einen oder anderen Dokuments entstehen. Zwischen diesen einzelnen Parametern besteht jeweils eine n:m Beziehung. So können mehrere Methoden in einer Phase eingesetzt werden. Ebenso ist es möglich, dass sich ein Methodeneinsatz über mehrere Phasen hinweg erstreckt. Eine Rolle ist für mehrere Dokumente verantwortlich oder ein Dokument wird von mehreren Rollen gemeinsam erarbeitet. Das folgende Beispiel soll die Beziehung zwischen Methoden, Phasen, Rollen und Dokumenten erläutern: Die Methode „Planung eines Projekts“ wird u.a. in der Analyse-Phase eines Software-Projektes verwendet. Das Ergebnis dieser Methode wäre der Projektplan, der während aller Phasen des Software-Entwicklungsprozesses auf dem aktuellen Stand gehalten werden muss. Verantwortlich für den Inhalt des Projektplans ist der Projekt-Manager (Rolle). Nachfolgend werden diese Parameter (und damit Elemente einer Prozessbeschreibung) genauer beschrieben, bevor abschließend der Zusammenhang dieser Elemente in einem typischen Beispiel eines Dokumentenplanes gezeigt wird. 6.1.1

Die Elemente der Prozessbeschreibung

Die eben aufgezeigten Elemente der Prozessbeschreibung werden in den folgenden Abschnitten vorgestellt. Phasen und Prozessmodelle

Die Phase ist ein Zeitabschnitt in einem Projekt bzw. in der Entstehungsgeschichte eines Teilergebnisses. In der Literatur gibt es mehrere bekannte Prozessmodelle mit Phasendefinitionen, z.B. Wasserfall-, Spiral- und VModell [1, 60, 69].

6.1 Vorgehensweise

69

Alle eben genannten Modelle haben die folgenden Gemeinsamkeiten: • Die Bedingungen für den Eintritt in eine bestimmte Phase sind genau definiert • Die Phase ist gekennzeichnet durch ihre Ergebnisse • Die Bedingungen für den Austritt aus einer bestimmten Phase sind genau definiert Methoden

Jede Software-Entwicklung sollte durch ein methodisches Vorgehen geprägt sein, welches schließlich zur Erstellung konkreter Teilergebnisse führt. Im Allgemeinen lassen sich solche Methoden einteilen in organisatorische, analytische und konstruktive Verfahren. Beispiele für organisatorische Methoden sind Konfigurationsmanagement, Change Management, oder Anforderungsmanagement. Die konstruktiven Methoden beinhalten Software-Entwicklungsverfahren wie z.B. strukturierte Analyse, strukturiertes Design, objektorientiertes Design etc. und deren Einzelverfahren wie der Einsatz von Objektmodellen, Zustandsautomaten, „Message Sequence Charts“. Als analytische Methoden lassen sich diverse Review-Techniken, Test-Methoden und Metriken angeben. Rollen

Verantwortlichkeiten werden innerhalb eines Software-Entwicklungsprojektes mit Hilfe von Rollen zugeordnet. Rollen definieren sich als die Summe von zusammenhängenden Teilaufgaben, die entweder einer Person oder einer Gruppe von Personen zugeordnet werden. Jede Rolle hat die Aufgabe ihre vordefinierten Ziele zu erreichen. Beispiele für Rollen im Software-Entwicklungsprozess sind: Projektmanager, Software-Entwickler, Qualitätsmanager etc. Innerhalb kleinerer Projekte können einer Person mehrere Rollen zugeordnet werden. Dokumente

Dokumente sind Teilergebnisse im Software-Entwicklungsprozess. Beispiele für Dokumente sind Projektpläne, Projektberichte, Entwurfsdokumente, Review-Protokolle und das Programmlisting.

70

6 Bestandsaufnahme bei den Projektpartnern

6.1.2

Der Dokumentenplan

Tabelle 6.1 erklärt die Beziehung der Prozesselemente, also von Dokumenten zu Phasen, Rollen und Methoden. In den dargestellten Matrizen bezieht sich jedes Dokument auf mindestens eine Phase, Methode oder Rolle. Die Anpassung einer Prozessbeschreibung – das Prozess-Tailoring – an die Anforderungen eines Unternehmens kann dadurch erreicht werden, dass Verknüpfungen in der Matrix geändert werden, mehrere Rollen in einer Rolle vereinigt, Methoden und Dokumente geändert oder gelöscht werden. Tabelle 6.1. Darstellung der Beziehungen von Dokumenten zu Phasen, Rollen und Methoden

a

b

c

#

b

#

c

#

#

a a

#

b

#

c

b

Methoden c #

#

Dokumente

a

Rollen Dokumente

Dokumente

Phasen

a a

b

#

c #

b

#

c

#

Zur Erfassung der Prozessstruktur werden diese drei Matrizen zu einem Dokumentenplan zusammengefasst, wie dies in Abb. 6.1 zu sehen ist.

Abb. 6.1. Ausschnitt eines Dokumentenplans eines EQUAL-Projektpartners

6.2 Ergebnisse und Bewertung

71

Alle Dokumente sind in der linken Spalte aufgelistet. Aus der Matrix in der Mitte der Tabelle lässt sich ablesen, welches Dokument mit welcher Methode in welcher Phase und von welcher Rolle zu erstellen ist. Dabei gelten für die Kurzzeichen die in Tabelle 6.2 beschriebenen Bedeutungen. Tabelle 6.2. Symbole und Bedeutungen aus dem Dokumentenplan Symbol E Ü V M #

6.2

Bedeutung In dieser Phase wird das Dokument erstellt In dieser Phase wird das Dokument überarbeitet Eine Person dieser Rolle ist für das Dokument verantwortlich Eine Person dieser Rolle arbeitet am Dokument mit Zur Bearbeitung des Dokuments wird diese Methode angewandt

Ergebnisse und Bewertung

Als wesentliche Ergebnisse der Bestandsaufnahme entstanden eine priorisierte Liste von QS-Maßnahmen, eine Liste von Dokumenten, die typischerweise in den Firmen erstellt werden, sowie ein Überblick über die in den Unternehmen gelebten Phasenmodelle. 6.2.1

Liste von QS-Maßnahmen

Ausgehend von den zu Beginn erstellten Dokumentenplänen wurde eine Liste der in den Anwenderunternehmen verwendeten QS-Maßnahmen erstellt. In Diskussionsrunden wurden diese QS-Maßnahmen anschließend auf ihre Relevanz hinsichtlich aktueller Anwendung der QS-Maßnahmen in den beteiligten Anwenderunternehmen bewertet. Die Bewertungsskala wurde dreistufig festgelegt: gering, mittel und hoch. In den nachfolgenden Tabellen ist das Ergebnis dieser Bestandsaufnahme und der anschließenden Bewertung enthalten. Zur besseren Übersicht wurden die QSMaßnahmen in organisatorische Maßnahmen (ohne ProjektmanagementMaßnahmen) (Tabelle 6.3), analytische Maßnahmen (Tabelle 6.4) und konstruktive Maßnahmen (Tabelle 6.5) unterteilt.

72

6 Bestandsaufnahme bei den Projektpartnern

Tabelle 6.3. Übersicht über die erfassten organisatorischen QS-Maßnahmen mit Angabe der Relevanz Organisatorische QS-Maßnahmen Relevanz „hoch“ Projektaudits Änderungs- und Feigabedienst Programmierrichtlinien Checklisten Dokumentation von Entscheidungen Festlegung des SW-EngineeringModells (Vorgehensweise; Projektplanung) Relevanz „mittel“ QS-Handbuch (projektspezifisch) Q-Berichterstattung Relevanz „gering“ Dokumentationssysteme

QS-Handbuch (allgemein) Dokumentationsrichtlinien Designrichtlinien Dokumentenvorlagen Glossar/Terminologie unabhängige Testgruppen

Defect Management, Bug Tracking Analyse/Erfahrung eingesetzter Maßnahmen Testabdeckungsmatrix

Tabelle 6.4. Übersicht über die erfassten analytischen QS-Maßnahmen mit Angabe der Relevanz Analytische QS-Maßnahmen Relevanz „hoch“ Walkthrough Inspektion Black-Box Test Modultest Stresstest Installationstest Relevanz „gering“ Codeanalyse Metriken White-Box Test

Review (Allgemein) Schreibtischtest Integrationstest Regressionstest Akzeptanztest In-circuit-Emulation Datenflussanalyse Ausfalleffektanalyse (FMEA) Simulation

6.2 Ergebnisse und Bewertung

73

Tabelle 6.5. Übersicht über die erfassten konstruktiven QS-Maßnahmen mit Angabe der Relevanz Konstruktive QS-Maßnahmen Relevanz „hoch“ Anforderungsanalyse Änderungsmanagement Spezifikation von Schnittstellen Wiederverwendung von SW Konfigurationsmanagement Endliche Automaten

Anforderungsverfolgung Spezifikation von Produktqualität SW-Architekturentwurf Bibliotheken Risikoanalyse

Relevanz „mittel“ Prototyping SA/SD Wiederverwendung Dokumente Ressourcen-Analyse UML

Spezifikation von Prozessqualität Sequenzdiagramme Timing-Analyse Code-Generierung

Relevanz „gering“ Simulation Petrinetze Komplexitätsbetrachtungen

SDL Defensive Programmierung Instrumentierung

In der Diskussion mit den Anwenderunternehmen hat sich schnell herauskristallisiert, dass nicht pauschal von dem einen Unternehmensvorgehensmodell gesprochen werden kann, sondern stattdessen unterschiedliche Projektklassen existieren, für die unterschiedliche Vorgehensweisen angewendet werden. Folgende Projektklassen wurden identifiziert: • Vorfeldentwicklung: Im wesentlichen Forschungsstudien, deren Ziel die Machbarkeitsanalyse von neuen, innovativen Funktionen oder Technologien ist. • Produktentwicklung: Schaffung eines neuen Produktes oder einer neuen Produktfamilie. • Produktentwicklung im Kundenauftrag: Durchführung einer Produktentwicklung für externen Auftraggeber. • Variantenentwicklung: Schaffung eines neuen Produkts auf Basis eines existierenden Produkts bzw. einer existierenden Produktfamilie.

74

6 Bestandsaufnahme bei den Projektpartnern

• Variantenentwicklung im Kundenauftrag: Variantenentwicklung für externen Auftraggeber, jedoch kann diese auf eine externe oder interne Produktlinie aufsetzen. • Anpassentwicklung: Kleinere Änderungen (Fehlerbehebung, Funktionserweiterung) an einem existierenden Produkt, einer Variante oder einer Produktlinie, die jedoch nicht zu einem neuen Produkt führen. Ausgehend von den bereits erfassten und bewerteten QS-Maßnahmen wurden diese in einem weiteren Schritt mit den definierten Projektklassen in Beziehung gesetzt. Zielsetzung war, Unterschiede in den Vorgehensweisen zu ermitteln. Ein Ausschnitt aus dem Ergebnis wird in Abb. 6.2 gezeigt. Dort finden sich Bewertungen der einzelnen QS-Maßnahmen in Abhängigkeit der Projektklassen und der Projektphasen.

Abb. 6.2. Ausschnitt aus der Zusammenfassung aller Dokumentenpläne

6.2 Ergebnisse und Bewertung

75

Folgende Punkte konnten in der Analyse und in der darauf folgenden Diskussion zwischen den Anwenderunternehmen als Ergebnis identifiziert werden: • Die Vorgehensweisen bei der Software-Entwicklung in den einzelnen Projektklassen unterscheiden sich zwar, jedoch kann nicht allgemein attestiert werden, dass eine QS-Maßnahme bei einer Projektklasse generell oder generell nicht einzusetzen ist. • Vielmehr variiert die Intensität der QS-Maßnahmen, d.h. wie konsequent und mit welchem Aufwand eine QS-Maßnahme eingesetzt wird, mit den Projektklassen. 6.2.2

Liste von Dokumenten

Bei den befragten Anwenderunternehmen herrscht eine hohe Übereinstimmung bezüglich der verwendeten Dokumentation im SoftwareEntwicklungsprozess. Tabelle 6.6 zeigt die Dokumente auf, die vom Großteil der Unternehmen erstellt werden. Tabelle 6.6. Identifizierte gemeinsame Dokumente Lastenheft

Pflichtenheft

System-Design Quellcode Projektplan

Moduldesign Testplan Testspezifikationen (Modul-, Integrations-, Systemtests) Testdokumentation für die verschiedenen Testphasen Reviewprotokoll

Statusbericht Änderungsantrag Release Note

Diese Kerndokumentation wird von einzelnen Unternehmen durch folgende Dokumente ergänzt: • • • •

Anwenderdokumentation Installations- und Produktionsanweisung Freigabedokumente Usability-Report

Diese Dokumente werden nicht generell verwendet, da diese – zumindest teilweise – stark vom jeweiligen Anwendungsumfeld abhängen und

76

6 Bestandsaufnahme bei den Projektpartnern

deshalb auch – zum Beispiel im Vergleich zu einem Standard-V-Modell [1] – eine hohe Auswirkung auf die Prozessdefinition haben. 6.2.3

Anmerkungen zur Bestandsaufnahme

Im gezeigten Konzept des Dokumentenplanes ist u.a. das Rollenmodell als Bestandteil einer Prozessdefinition vorgesehen. Hier konnten einige Standardrollen identifiziert werden, beispielsweise Projektleiter, Entwickler, Designer und Tester. Ansonsten herrscht allerdings eine große Vielfalt bei der Rollenbenennung vor. Dies zeigt, dass gerade das Rollenmodell und damit natürlich auch letzten Endes die Verantwortlichkeiten bezüglich konkreter Aufgaben, die unter dem Rollenmodell liegen, sehr stark von der jeweiligen Unternehmensstruktur abhängig sind. Als Phasenmodell wird in allen untersuchten Anwenderunternehmen ein V-Modell-ähnliches Vorgehen skizziert. Trotzdem wurde in Gesprächen immer wieder das Bedürfnis nach einem iterativ-inkrementellen Vorgehen herausgestellt. Auf der Ebene der Grobstruktur der Entwicklungsprozesse, d.h. beim Dokumentenplan, werden den besonderen Eigenheiten der betrachteten mechatronischen Produkte bisher nur in äußerst geringem Umfang Rechnung getragen. In den einzelnen Diskussionsrunden wurden jedoch sehr wohl spezielle Probleme aus diesem Anwendungsbereich identifiziert, die Auswirkungen auf das Vorgehensmodell haben. Diese Auswirkungen sind aber eher auf konkrete Aktivitäten als auf die grobe Struktur einzelner Phasen bezogen. Die am häufigsten genannten Probleme aus diesem Bereich sind: • mangelnde ganzheitliche Sichtweise auf das Produkt bzw. den Erstellungsprozess • Dominanz der Hardware-Kosten und traditionelle Fokussierung auf die Hardware • späte Hardware-Verfügbarkeit bei gleichzeitig unklaren HardwareAbhängigkeiten und Hardware-Restriktionen • späte Absicherung des Integrationsrisikos • nicht eindeutige Schnittstellendefinition

7 Auswahl von QS-Maßnahmen

Dieses Kapitel beschäftigt sich mit der Fragestellung: „Wie kann die Qualitätssicherung systematisch und umfassend geplant werden?“ Auch wenn in der Praxis das Bewusstsein für die Bedeutung der Qualitätssicherung eingebetteter Software im Bereich softwareintensiver Produkte vorhanden ist, gibt es große Unterschiede in Art und Umfang bei verschiedenen Firmen. Die mannigfaltigen Randbedingungen, die ein Entwicklungsprojekt haben kann, gekoppelt mit den ebenfalls vielfältigen Lösungsmöglichkeiten erfordern eine systematische Planung der Qualitätssicherung eingebetteter Software. Dies ist entscheidend zur Einhaltung und Definition von Projektzielen, -kosten und -terminen. Wichtig dabei ist der Einsatz einer effizienten Qualitätssicherung. Effiziente Qualitätssicherung umfasst die Auswahl und den Einsatz von QS-Maßnahmen (QSM), die die geforderten Qualitätsanforderungen an das Produkt und den Entwicklungsprozess 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 effiziente Qualitätssicherung stellt in erster Linie eine Planungs- und Managementaufgabe dar. Dabei sind die beiden wichtigsten Aufgaben der Planung von Qualitätssicherung • die Qualitätsplanung und • die Auswahl von QS-Maßnahmen. Im Rahmen der Qualitätsplanung erfolgt die Festlegung der Qualitätsanforderungen, die als Ausprägungen der Qualitätsmerkmale formuliert werden. Ausgehend von dieser Qualitätsplanung werden geeignete QSMaßnahmen bestimmt. In der Praxis legt jedoch der Projektleiter meist erfahrungsabhängig auf Grund seiner Intuition die Qualitätssicherung für sein Projekt fest, was u.a. auch zu Rechtfertigungs- bzw. Motivationsproblemen führen kann. Hier besteht der Bedarf nach einer transparenten und angemessenen Planung der Qualitätssicherung. Jedoch fehlt es u. a. an transparenten Entscheidungskriterien, an der expliziten Berücksichtigung des Projektkon-

78

7 Auswahl von QS-Maßnahmen

texts sowie an Kenntnissen über Kosten und Wirkungen von QSMaßnahmen. Ein geeignetes Planungsverfahren (Entscheidungsunterstützung) muss praktisch einsetzbar, leicht anwendbar und von kleinen Teams durchführbar sein. Es muss eine systematische und nachvollziehbare Planung einer effizienten Qualitätssicherung von eingebetteter Software in Abhängigkeit des Entwicklungskontexts ermöglichen und durch Entwicklungsleiter bzw. Projektleiter leicht anwendbar sein. Eine entsprechende Entscheidungsunterstützung wurde im Rahmen der Dissertation von Koç [42] entwickelt. Diese Methodik zur Entscheidungsunterstützung soll in diesem Kapitel in Kurzform vorgestellt werden.

7.1

Rahmenkonzept der Entscheidungsunterstützung

Eine Entscheidungsunterstützung hilft dem Entscheidungsträger Hilfsmittel an die Hand zu geben, die für ihn die Entscheidungssituation transparenter machen und es erlauben, Entscheidungen nachvollziehbar zu treffen. Eine Entscheidungsunterstützung hilft bei der Lösung komplexer Probleme und unterstützt Handlungsträger in bestimmten Entscheidungsphasen. Für den Entwurf der Entscheidungsunterstützung ist es wichtig, zunächst die Grundsatzfrage nach dem Fokus der Planung und dem Planungsergebnis zu klären. Hier hilft die Aufteilung der Gesamtplanung in Struktur- und Feinplanung, entsprechend dem Top-Down-Prinzip („vom Groben zum Detail“). Im Rahmen der Strukturplanung werden die Anforderungen an die Qualitätssicherung spezifiziert und angemessene QS-Maßnahmen für deren Erfüllung bestimmt. Anschließend erfolgt in der Feinplanung die projektspezifische Ausgestaltung von QS-Maßnahmen einschließlich der Terminund Ressourcenplanung (Abb. 7.1).

7.1 Rahmenkonzept der Entscheidungsunterstützung

79

Situationsanalyse

Anforderungen an die Qualitätssicherung (Zielplanung) Strukturplanung Auswahl angemessener QS Maßnahmen

Feinplanung

Projektspezifische Ausgestaltung von QS Maßnahmen; Termin- und Ressourcenplanung

Umsetzung

Abb. 7.1. Unterscheidung zwischen Struktur- und Feinplanung der QS

Bei dem Betrachtungsobjekt der Qualitätsplanung ergeben sich für ein Unternehmen zwei Extreme: Die individuelle Planung für jedes einzelne Projekt sowie die Einmalplanung für das Gesamtunternehmen. Ein einziges, allgemeines QS-Vorgehen widerspricht dem Ziel einer angemessenen Qualitätssicherung. Dagegen ist eine umfassende Bewertung und Planung auf Einzelprojektebene aus Aufwands- und Akzeptanzgründen fraglich. Zudem ist zu bedenken, dass unterschiedliche Projekte unterschiedliche Eigenschaften besitzen, die wiederum weitgehend die Qualitätsanforderungen festlegen. Im Umkehrschluss besitzen ähnliche Projekte ähnliche Qualitätsanforderungen. Folglich ist es nicht zwingend, für jedes Einzelprojekt ein spezifisches Qualitätssicherungsvorgehen herzuleiten. Es ist nahe liegender, Klassen von ähnlichen Projekten zu bilden und die Strukturplanung auf eine Projektklasse zu beziehen. Durch die Fokussierung auf die Strukturplanung von Projektklassen wird sichergestellt, dass die Entscheidungsunterstützung einfach und nachvollziehbar bleibt. Weiterhin wird der Gesamtaufwand für die Planung der Qualitätssicherung wesentlich verkürzt. Die Strukturplanung ist jeweils einmal pro Projektklasse durchzuführen. Konkrete Projekte können auf den Ergebnissen der Strukturplanung aufsetzen und für sie in kurzer Zeit eine Feinplanung der Qualitätssicherung vorgenommen werden. Zur Unterstützung der Strukturplanung der Qualitätssicherung liefert die Entscheidungsunterstützung jeweils für eine Projektklasse QS-Maßnahmen in vier unterschiedlichen Empfehlungen: voll angemessen (V), weitgehend angemessen (W), beschränkt angemessen (B) und nicht angemessen (N) (Tabelle 7.1).

80

7 Auswahl von QS-Maßnahmen

Tabelle 7.1. Ergebnis: angemessene QS-Maßnahmen für Projektklassen QS-Maßnahme

Projektklasse 1

Projektklasse 2

...

Projektklasse m

QSM 1 QSM 2 QSM 3 .... QSM n

B V W ... B

N B W ... V

... ... ... ... ...

W W B ... N

Um systematisch und nachvollziehbar zu einem solchen Planungsergebnis zu kommen, ist folgender Entscheidungsprozess notwendig: 1. Situationsanalyse (Charakterisiere Entwicklungskontext) 2. Formulierung des Zielsystems (Definiere Anforderungen an die Qualitätssicherung) 3. Analysiere Lösungsalternativen (Analysiere QS-Maßnahmen) 4. Wähle Lösungsalternativen aus (Wähle geeignete QS-Maßnahmen aus) Ziele, die im Rahmen der Planung von Qualitätssicherung erreicht werden sollen, stellen Anforderungen an die Qualitätssicherung dar, die durch den Einsatz alternativer QS-Maßnahmen möglichst optimal erreicht werden sollen. 7.1.1

Profilbasiertes Entscheidungsmodell

Aus Aufwands- und Akzeptanzgründen macht es Sinn, die QS-Anforderungen, den Entwicklungskontext und die QS-Maßnahmen anhand von drei einheitlichen Profilen zu beschreiben. Unter einem Profil versteht man in diesem Zusammenhang die Menge von wesentlichen Merkmalen und deren Ausprägungen, um einen Sachverhalt charakteristisch zu beschreiben. Es stellt die Gesamtheit von Eigenschaften, die unverwechselbar typisch für einen Sachverhalt sind, dar. Die Merkmale der drei Profile werden zum besseren Verständnis und zur einfachen Anwendbarkeit kategorisiert und kommentiert. Im Einzelnen existieren folgende Profile: • Entwicklungsprofil: Diese Profilbeschreibung hat die Aufgabe, die entscheidungsrelevanten Rahmenbedingungen eines Entwicklungsprojekts zu beschreiben. Das Profilmodell erlaubt eine Beschreibung von Entwicklungsprojekten anhand festzulegender Merkmale mit entsprechenden Merkmalsausprägungen. Im Entwicklungsprofil wird die Komplexität und somit der Schwierigkeitsgrad eines Entwicklungsprojekts dokumentiert.

7.1 Rahmenkonzept der Entscheidungsunterstützung

81

• QS-Anforderungsprofil: Mit Hilfe dieses Profilmodells werden anhand ausgewählter Merkmale und ihren Ausprägungen die Anforderungen an die Qualitätssicherung beschrieben. • QS-Maßnahmenprofil: Dieses Profilmodell enthält die Bewertung einer QS-Maßnahme entsprechend auswahlrelevanter Merkmale und ihrer Ausprägungen. Für die Profilbeschreibungen haben sich im Rahmen des Forschungsprojekts EQUAL vornehmlich ordinale, qualitative Merkmale bewährt [43]. Die Ausprägungen bestehen aus den folgenden Werten einer äquidistanten Skala: gering (g), mittel (m) und hoch (h). Ein Beispiel für ein QSMaßnahmenprofil ist in Tabelle 7.2 gegeben.

Kategorie

Merkmal

Software- Wiederverwendung

Anforderungsverfolgung

Dokumentenvorlagen

ProgrammierRichtlinien

Regressionstest

Tabelle 7.2. Beispiel eines QS-Maßnahmenprofils

Produktqualität (Qualitätswirkung)

Funktionalität Zuverlässigkeit Benutzbarkeit Effizienz Änderbarkeit Übertragbarkeit Durchführbarkeit Effizienz Planbarkeit Strukturiertheit Zukunftsorientiertheit Formalität Flexibilität Nachvollziehbarkeit Erlernbarkeit

h h m m h h g h m g g m h m m

g g g g m m h m h h m h g h m

m g g g h m h m h h g g h m h

h h m m h h h m m h g g h m h

h m g g g g g h g g g h m h h

Prozessqualität (Qualitätswirkung)

Technische Eigenschaft

Tabelle 7.3 zeigt ein Beispiel für ein Entwicklungsprofil mit den Kategorien Prozess-Komplexität und Produkt-Komplexität.

82

7 Auswahl von QS-Maßnahmen

Tabelle 7.3. Beispiel eines Entwicklungsprofils Merkmal Projektlaufzeit Teamgröße

Prozess-Komplexität

Strategische Relevanz Interdisziplinarität Externe Entwicklungspartner Prozess-Erfahrung der Teammitglieder Produkt-Erfahrung der Teammitglieder Zukaufkomponenten Dokumentationsbedarf Termintreue Qualität vorgegebener Produktanforderungen

Produkt-Komplexität

Stabilität vorgegebener Produktanforderungen Technologische Komplexität Algorithmische Komplexität Komplexität des technischen Prozesses Echtzeitanforderungen

HardwareRestriktionen SchnittstellenKomplexität Anzahl interagierender Komponenten

Begründung m Projektumfang ist eher klein und die Bedeutung der Termintreue ist eher gering g Projektumfang ist eher klein, da nur neue Teilaspekte eines Produkts realisiert werden m Ergebnisse sind produktrelevant aber nicht unumstößlich g Klar abgegrenzte Problemstellung g Machbarkeitsstudie bezieht sich auf eigenentwickelte Teilaspekte h Erfahrene Teammitglieder sind wichtig, um frühe Fehlentscheidungen zu vermeiden h Hohe fachliche Kompetenz und Kreativität gefordert g Halten sich in Grenzen g Erkenntnisgewinn und Ergebnisse stehen im Vordergrund g Es gibt keine unmittelbaren Termine; besitzt keine hohe Priorität (im Tagesgeschäft) m Klar abgegrenzte Problemstellung; jedoch Defizite wegen hohem Neuheitscharakter; Problem nicht vollständig durchdrungen m Klar abgegrenzte Problemstellung; jedoch Defizite wegen hohem Neuheitscharakter h Neuartige Problemstellung h Neuartige Problemstellung m Neuheitscharakter des Produkts ist höher als beim technischen Prozess; m Ergebnis muss übertragbar sein; harte Echtzeit muss im eigentlichen Produkt erfüllt sein g Kleine Stückzahlen g Schnittstellen sind klar abgegrenzt m Es geht nicht um eine Komplettlösung, sondern um ein Teilproblem

7.1 Rahmenkonzept der Entscheidungsunterstützung

83

Da getroffene Entscheidungen zu rechtfertigen sind, werden alle Entscheidungen, wie eine bestimmte Ausprägung für ein Merkmal eines Profils zustande kommt, dokumentiert. Dazu enthält das Schema zur Profilbeschreibung eine Spalte für Begründungen. Zusammenfassend ergibt sich der Aufbau für die Profile nach Abb. 7.2.

Kategorie

Merkmal

Beschreibung

Ausprägung

Begründung

Merkmal

Beschreibung

Ausprägung

Begründung

Merkmal

Beschreibung

Ausprägung

Begründung

Merkmal

Beschreibung

Ausprägung

Begründung

Kategorie

...

Abb. 7.2. Allgemeines Schema zur Profilbeschreibung

Merkmale werden zu Kategorien zusammengefasst, enthalten jeweils Erläuterungen in der Beschreibungsspalte und dreistufige Ausprägungen (gering, mittel, hoch) sowie deren Begründungen. Aus dem Entscheidungsprozess folgt, dass die QS-Anforderungen in Anlehnung an den Entwicklungskontext definiert werden. Neben dieser Beziehung existiert eine weitere zwischen den QS-Anforderungen und den QS-Maßnahmen. Aus Gründen des Aufwands und der Transparenz erfolgt die Beschreibung dieser Beziehungen wie folgt (Abb. 7.3): Entwicklungsprofil

Kontext eines Entwicklungsprojekts

QS-Anforderungsprofil

QS-Maßnahmenprofil

Anforderungen an die Qualität

Eigenschaften von QS-Maßnahmen

Anforderungen an QS-Maßnahmen

Wirkungen von QS-Maßnahmen

Abb. 7.3. Aufbau und Beziehungen der Profile

84

7 Auswahl von QS-Maßnahmen

Das QS-Anforderungsprofil wird aus dem Entwicklungsprofil abgeleitet. Zur Beschreibung dieser Beziehung wird die QFD-Methode vereinfacht: Die Ausprägung eines Merkmals im QS-Entwicklungsprofil wird direkt in das QS-Anforderungsprofil eingetragen. In der dazugehörigen Begründungspalte wird festgehalten, welche Merkmale des EntwicklungsProfils zu dieser Entscheidung beigetragen haben. Damit werden die Wirkungszusammenhänge zwischen Entwicklungsprofil und QS-Anforderungsprofil in der Begründungsspalte des QS-Anforderungsprofils dokumentiert. Neben den Eigenschaften einer QS-Maßnahme sind für eine verbesserte QS-Planung die Wirkungen einer QS-Maßnahme hinsichtlich der Qualität zu beschreiben. Dies erfolgt durch die Erweiterung des QS-Maßnahmenprofils um die Wirkungen einer QS-Maßnahme. Um einen direkten und einfachen Vergleich zwischen Anforderungen und Wirkungen hinsichtlich der Qualität zu erhalten, werden beide Profile durch die gleichen Merkmale beschrieben. Betrachtet man nun weiter das QS-Anforderungsprofil, so erkennt man, dass für die Bestimmung einer angemessenen Qualitätssicherung die alleinige Definition der Qualitätsanforderungen nicht ausreicht. Das Profil muss weiterhin Informationen darüber enthalten, bei welchen Rahmenbedingungen diese Qualitätsanforderungen zu erreichen sind. Dazu wird das Profil um Anforderungen an QS-Maßnahmen erweitert. Hier korrespondieren die Anforderungen an QS-Maßnahmen mit den Eigenschaften von QSMaßnahmen aus dem QS-Maßnahmenprofil. Auch hier ist es angebracht, beides durch dieselben Merkmale zu beschreiben. Womit beide Profilbeschreibungen aus identischen Merkmalen aufgebaut sind. Bestimmung von Entwicklungsmerkmalen

Bestimmung von Qualitätsmerkmalen

Bestimmung von QSM-Merkmalen

Entwicklungsmerkmale

Qualitätsmerkmale

QS-Maßnahmenmerkmale

Entwicklungsprofil(e) (Umweltsituation)

QS-Anforderungsprofil (Ziele)

QS-Maßnahmenprofil(e) (Handlungsalternativen)

Beschreibung von Entwicklungsprofilen

Beschreibung von QS-Anforderungsprofilen

Beschreibung von QS-Maßnahmenprofilen QS: Qualitätssicherung QSM: QS-Maßnahme

Abb. 7.4. Herleitung der Profilbeschreibungen

7.1 Rahmenkonzept der Entscheidungsunterstützung 7.1.2

85

Kategorisierung der Merkmale

Aus Abb. 7.4 ist zu erkennen, dass zunächst Entwicklungsmerkmale zur Beschreibung von Entwicklungsprofilen, Qualitätsmerkmale und QSMaßnahmenmerkmale (QSM-Merkmale) zur Beschreibung von QSAnforderungsprofilen bzw. QS-Maßnahmenprofilen ermittelt werden. Nach dieser Bestimmung relevanter Merkmale erfolgt die Beschreibung konkreter Profile. Für QSM-Merkmale sind die beiden Kategorien „Technische QSM-Eigenschaft“ und „Wirtschaftliche QSM-Eigenschaft“zu empfehlen. Demnach besteht ein Entwicklungsprofil aus Entwicklungsmerkmalen, die hinsichtlich Produkt- und Prozesskomplexität unterschieden werden. QS-Anforderungsprofile und QS-Maßnahmenprofile setzen sich aus Qualitätsmerkmalen mit den Kategorien Produkt- und Prozessqualität sowie QSM-Merkmalen mit den Kategorien technische QSMEigenschaft und wirtschaftliche QSM-Eigenschaft zusammen. Abb. 7.5 zeigt den Aufbau und die Beziehungen der Profile des Entscheidungsmodells unter Berücksichtigung der Kategorien. Entwicklungsprofil

K: Produktkomplexität Merkmal

...

K: Prozesskomplexität Merkmal

...

QS-Anforderungsprofil

K: Produktqualität Merkmal

...

K: Prozessqualität Merkmal

...

K: Technische QSM-Eigenschaft Merkmal

...

K: Wirtschaftliche QSM-Eigenschaft K Kategorie QS Qualitätssicherung QSM QS-Maßnahme

Abb. 7.5. Struktur der Profile

Merkmal

...

QS-Maßnahmenprofil

K: Produktqualität Merkmal

...

K: Prozessqualität Merkmal

...

K: Technische QSM-Eigenschaft Merkmal

...

K: Wirtschaftliche QSM-Eigenschaft Merkmal

...

86 7.1.3

7 Auswahl von QS-Maßnahmen Auswahlmethodik

Um den Zielen nach Transparenz und Anwendbarkeit in der Praxis gerecht zu werden, und weil Empfehlungen möglichst intuitiv nachvollziehbar sein müssen, darf die Auswahlmethodik nicht aufwendig sein. Im vorliegenden Fall werden die bewerteten QS-Maßnahmen (Handlungsalternativen) den QS-Anforderungen (Zielgrößen) gegenübergestellt und Empfehlungen ausgesprochen. Die Empfehlungsstufen für die QSMaßnahmen werden, ausgehend von den Standards IEC 61508 und ISO 15504, anhand des Erfüllungsgrads der QS-Anforderungen entsprechend der Tabelle 6 definiert und genutzt. Tabelle 7.4. Definition der Empfehlungsstufen Empfehlungsstufe

Erfüllungsgrad

voll angemessen (V) weitgehend angemessen (W) beschränkt angemessen (B) nicht angemessen (N)

76 % – 100 % 51 % – 75 % 26 % – 50 % 0 % – 25 %

Die Mehrstufigkeit von Empfehlungen sind im Sinne einer schrittweisen und kontinuierlichen Verbesserung sinnvoll. Selektiv kann bei der Umsetzung von Empfehlungen mit dem Dringendsten gestartet und im Laufe der Zeit weniger Dringendes hinzugenommen werden. Ausgangsbasis für die Ermittlung der Empfehlungsstufe für QSMaßnahmen stellt der direkte Vergleich eines QS-Maßnahmenprofils mit dem betrachteten QS-Anforderungsprofil dar. Das Vergleichsergebnis stellt den Erfüllungsgrad einer QS-Maßnahme dar, mit der unter Nutzung der Tabelle 7.4 die Empfehlungsstufe einer QS-Maßnahme ermittelt werden kann. Den grundsätzlichen Ablauf der Auswahlmethodik zeigt Abb. 7.6.

7.1 Rahmenkonzept der Entscheidungsunterstützung QS-Anforderung

QSM

M1

M1

M2

M2

M3

M3

M4

M4

M5

M5

M6

M6

...

...

Mn

Mn

Entscheider Empfehlungsstufe QSM

Empfehlungsstufe Kategorien

Erfüllungsgrad Merkmale

87

M: Merkmal

Abb. 7.6. Ablauf der Auswahlmethodik

Dabei wird das Ergebnis in den folgenden drei Schritten ermittelt: 1. Bestimmung des Erfüllungsgrads jedes Merkmals 2. Bestimmung der Empfehlungsstufe jeder Kategorie des QS-Anforderungsprofils 3. Bestimmung der Empfehlungsstufe einer QS-Maßnahme Bestimmung des Erfüllungsgrads jedes Merkmals. Die Merkmale im QS-Anforderungsprofil entsprechen denen des QS-Maßnahmenprofils. Folglich ist ein direkter Vergleich der Merkmalsausprägungen beider Profile möglich. Dabei gibt die Ausprägung eines Merkmals im QSAnforderungsprofil an, wie wichtig das Merkmal für die angestrebte Qualitätssicherung ist. Umgekehrt zeigt die Ausprägung desselben Merkmals im QS-Maßnahmenprofil, wie gut eine QS-Maßnahme dieses Merkmal unterstützt. Wenn also ein Merkmal im QS-Anforderungsprofil die Ausprägung gering hat, so wird dieses Merkmal bei der Berechnung der Empfehlungsstufe einer QS-Maßnahme nicht berücksichtigt. In allen anderen Fällen muss zunächst zwischen den Kategorien Produktqualität, ProzessQualität und technische QSM-Eigenschaft sowie der Kategorie wirtschaftliche QSM-Eigenschaft unterschieden werden.

88

7 Auswahl von QS-Maßnahmen

Tabelle 7.5. Erfüllungsgrad eines Merkmals bezogen auf die Merkmale Produktqualität, Prozessqualität und technische QSM-Eigenschaft (z.B. Benutzbarkeit) QS-Anforderung (Relevanz des Merkmals)

QS-Maßnahme (Erfüllung des Merkmals)

Erfüllung der QS-Anforderung

berücksichtigter Empfehlungsgrad

gering

gering mittel hoch gering mittel hoch gering mittel hoch

erfüllt erfüllt erfüllt nicht erfüllt erfüllt erfüllt nicht erfüllt nicht erfüllt erfüllt

keine Relevanz keine Relevanz keine Relevanz 0% 50 % 50 % 0% 50 % 100 %

mittel

hoch

Tabelle 7.6. Erfüllungsgrad eines Merkmals bezogen auf das Merkmal wirtschaftliche QSM-Eigenschaft (z.B. Zeitaufwand) QS-Anforderung (Relevanz des Merkmals)

QS-Maßnahme (Erfüllung des Merkmals)

Erfüllung der QS-Anforderung

berücksichtigter Empfehlungsgrad

gering

gering mittel hoch gering mittel hoch gering mittel hoch

erfüllt erfüllt erfüllt erfüllt erfüllt nicht erfüllt erfüllt nicht erfüllt nicht erfüllt

keine Relevanz keine Relevanz keine Relevanz 50 % 50 % 0% 100 % 50 % 0%

mittel

hoch

Für ein Merkmal aus der ersten Gruppe (z. B. Benutzbarkeit) (Tabelle 7.5) stellt die Ausprägung hoch eine Mindestanforderung dar. Damit erfüllen QS-Maßnahmen, deren Ausprägung gering oder mittel ist, diese Anforderung nicht. Bei einem wirtschaftlichen Merkmal (z. B. Zeitaufwand) bedeutet die Ausprägung hoch, dass QS-Maßnahmen mit Ausprägungen gering zu bevorzugen sind.

7.1 Rahmenkonzept der Entscheidungsunterstützung

89

Weiterhin gelten für die Ermittlung des Erfüllungsgrads folgende Regeln: Besitzt ein Merkmal eine mittlere Bedeutung für die Qualitätssicherung (Ausprägung mittel im QS-Anforderungsprofil), so werden QSMaßnahmen, die dieses Merkmal hoch bzw. mittel erfüllen, zu 50 % bei der Berechnung der Empfehlungsstufe berücksichtigt. Hat dagegen ein Merkmal eine hohe Bedeutung für die Qualitätssicherung, so fließen QSMaßnahmen mit einer Ausprägung hoch zu 100 % und mit einer Ausprägung mittel zu 50 % in die Berechnung ein. Für die wirtschaftlichen QSMMerkmale gelten diese Regeln gleichermaßen, jedoch mit umgekehrtem Vorzeichen (Tabelle 7.6). Bestimmung der Empfehlungsstufe jeder Kategorie des QSAnforderungsprofils. Die Berechnung der Empfehlungsstufe für eine Kategorie stellt ein Zwischenergebnis zur endgültigen Bestimmung der Empfehlungsstufe einer QS-Maßnahme dar. Der Empfehlungswert einer Kategorie ergibt sich aus dem Mittelwert aller Erfüllungsgrade der relevanten Merkmale. Anschließend ist dieser Zahlenwert in einen qualitativen Wert entsprechend der Definition von Empfehlungsstufen umzusetzen. Bestimmung der Empfehlungsstufe einer QS-Maßnahme. Zur Bestimmung der letztendlichen Empfehlungsstufe einer QS-Maßnahme wird das obige Berechnungsverfahren auf alle Merkmale bzw. Kategorien eines QSAnforderungsprofils ausgeweitet. 7.1.4

Nutzen der Entscheidungsunterstützung

Die Entscheidungsunterstützung gestattet eine nachvollziehbare und bedarfs-orientierte Planung der Qualitätssicherung unter Berücksichtigung des Entwicklungskontexts. Sie ermöglicht auch Nicht-Experten, selbständig – ohne Unterstützung externer Berater – eine angemessene Qualitätssicherung in einer kurzen Zeit zu definieren. Dabei ist zwischen dem einmaligen Aufwand für die Strukturplanung der Qualitätssicherung gleichartiger Projekte, der ca. vier Wochen betragen kann, und dem wiederholten Aufwand für die Feinplanung der Qualitätssicherung konkreter Projekte, der ca. ein Tag betragen kann, zu unterscheiden. Das dazugehörige Entscheidungsmodell ist übersichtlich und flexibel aufgebaut. Es enthält die Beschreibungskomponenten Entwicklungsprofil, QS-Anforderungsprofil und QS-Maßnahmenprofil. Die systematischen und einheitlichen Profilbeschreibungen stellen eine hohe Transparenz sicher und führen zu mehr Verständnis über Aufwand und Nutzen der QSMaßnahmen. Insgesamt fördert das kompakte Entscheidungsmodell die

90

7 Auswahl von QS-Maßnahmen

Kommunikation im Entwicklungsteam. Damit kann die Entscheidungsunterstützung auch als Begründungs- und Nachschlagewerk genutzt werden: Die systematische und nachvollziehbare Herleitung von QSMaßnahmen erhöht die Motivation für deren Anwendung seitens der Mitarbeiter. Gleichzeitig können Investitionen in QS-Maßnahmen gegenüber Vorgesetzten gerechtfertigt werden. Die Entwicklungsprofile dienen zur Orientierung und Differenzierung neuer Projekte. Durch die kompakte Darstellung und systematische Bewertung von QS-Maßnahmen ist ein schneller Überblick und Vergleich zwischen QS-Maßnahmen möglich. Der Profilansatz erlaubt die Wiederverwendung von Artefakten und trägt somit zur Steigerung der Produktivität und Qualität im Entwicklungsprozess bei. Im Sinne einer lernenden Organisation können Profile leicht ergänzt oder optimiert werden. Insgesamt ermöglicht die Entscheidungsunterstützung durch ein besseres Verständnis und Bewusstsein über die Zusammenhänge der Qualitätssicherung eine systematische und bedarfsgerechte Qualitätsverbesserung und trägt somit zur Erhöhung des Reifegrads der Software-Entwicklung bei.

7.2

Vorgehensweisen zur Anwendung der Entscheidungsunterstützung

Damit die Entscheidungsunterstützung in der Praxis sicher, aufwandsarm und zielstrebig angewendet werden kann, ist eine Systematik mit klaren Handlungsanweisungen zur Festlegung von Merkmalen und Profilbeschreibungen erforderlich, die auf anerkannten und klar definierten Grundsätzen und Vorgehensweisen beruht. Nachfolgend wird die Zusammensetzung der erforderlichen ExpertenGruppe sowie ausführliche Vorgehensweisen zur Definition und Beschreibung von Profilen vorgestellt. 7.2.1

Zusammensetzung der Expertengruppe

Da der zu unterstützende Planungsprozess auf Schätzungen basiert, ist es erforderlich, dass sich die Gruppe aus erfahrenen Mitgliedern zusammensetzt. Die Mitglieder sollten eine globale Projektsicht haben, d. h. Wissen über die Gesamtzusammenhänge eines Projekts mitbringen. Die Gruppe muss sinnvollerweise heterogen zusammengesetzt sein. Sie kann aus Projektleitern und Entwicklungsleitern sowie Personen aus der QS- bzw. Methoden-Abteilung und erfahrenen Entwicklern bestehen. Da-

7.2 Vorgehensweisen zur Anwendung der Entscheidungsunterstützung

91

bei können für die verschiedenen Teilnehmer unterschiedliche ArbeitsSchwerpunkte definiert werden: Projektleiter und Entwicklungsleiter weisen mehr Kompetenz bei der Charakterisierung des Entwicklungskontexts und die QS-Abteilung und erfahrene Entwickler bei der Beschreibung und Bewertung von QS-Maßnahmen auf. Im Rahmen des Forschungsprojekts EQUAL wurden zur Bestimmung von Merkmalen und zur Profilbeschreibung gute Erfahrungen mit einer Gruppenstärke von sechs Personen gemacht [43]. Um die Gruppenprozesse systematisch und effizient gestalten zu können, ist weiterhin ein Moderator sinnvoll. Diese Rolle kann jemand aus der eigentlichen Expertengruppe, z. B. der Gruppenleiter, einnehmen. Er kann sich wie andere Gruppenmitglieder an dem Gruppenprozess beteiligen, sollte jedoch nicht dominieren, um die Kreativität der anderen Teilnehmer nicht zu hemmen. Neben der Rolle des Moderators ist auch die eines Protokollanten nützlich. Dies kann z. B. in Personalunion geschehen, bzw. ein anderes Gruppenmitglied oder eine am Gruppenprozess nicht beteiligte Person können diese Aufgabe übernehmen. 7.2.2

Vorgehensweise zur Definition von Profilen

Die Vorgehensweise, welche die systematische Erarbeitung von Profildefinitionen ermöglicht, stellt eine einmalige, kreative Aufgabe dar und besteht aus den beiden Teilaufgaben • Bestimmung relevanter Merkmale und • Beschreibung von Merkmalen. Auch wenn Entwicklungsmerkmale, Qualitätsmerkmale und QSMMerkmale unterschiedliche Aspekte darstellen, so kann die Vorgehensweise zur Bestimmung relevanter Merkmale einheitlich gestaltet werden. Jedoch ist es aus Gründen des Aufwands und der Konzentration auf ein Thema empfehlenswert, Entwicklungsmerkmale, Qualitätsmerkmale und QSM-Merkmale jeweils in getrennten Gruppensitzungen zu ermitteln. Für die kreative Aufgabe der Bestimmung relevanter Merkmale wurde eine Vorgehensweise, basierend auf der nominalen Gruppentechnik, definiert. Neben dieser Gruppentechnik beinhaltet sie die Verwendung von Standardkatalogen für Merkmale. Dabei kann die erarbeitete Vorgehensweise für Entwicklungsmerkmale, Qualitätsmerkmale und QSMMerkmale gleichermaßen angewandt werden und der Aufwand beträgt jeweils ca. einen halben Tag. Die erforderlichen Standardkataloge von Merkmalen wurden aus der Literatur zusammengetragen.

92

7 Auswahl von QS-Maßnahmen

Für den interessierten Leser gibt es die Möglichkeit, einen zusätzlichen Service zu nutzen. Die Standardkataloge für Entwicklungsmerkmale und Qualitätsmerkmale sind unter www.embedded-quality.de/Fachbuch/Kapitel7 abrufbar. Zur Beschreibung der Merkmale werden die Ergebnisse der GruppenDiskussion genutzt und unter Verwendung der Delphi-Methode ein gemeinsames Gruppenverständnis über die verwendeten Merkmale geschaffen. Die Profilbeschreibungen müssen folgende Anforderungen erfüllen. • Reduzierung auf relevante Merkmale: Da Projekte durch eine Vielzahl von Faktoren beeinflusst werden, müssten für die Definition von Profilen theoretisch vielfältige Merkmale berücksichtigt werden. Um jedoch die Entscheidungsunterstützung handhabbar zu machen, muss im Sinne eines optimalen Planungsaufwands eine Reduzierung auf die wesentlichen Merkmale erfolgen. Dabei stellt sich die Frage, wie viele Merkmale für ein Profil ausreichend sind. Je mehr Merkmale, desto detaillierter und umfassender ist die Profilbeschreibung. Gleichzeitig erhöht sich aber dadurch die Komplexität des Planungsprozesses und die Übersicht geht verloren. Ein sinnvoller Kompromiss ist, dass alle Merkmale eines Profils auf einer Seite untergebracht sind, so dass man schnell alle Merkmale erfassen und unterscheiden kann. Folglich sollten pro Kategorie nicht mehr als ein Dutzend Merkmale vorhanden sein [43]. • Unabhängigkeit der Merkmale: Merkmale müssen möglichst unabhängig voneinander sein, d. h. ein Merkmal darf nicht in einem anderen enthalten sein bzw. Merkmale dürfen nur eine geringe Überschneidung aufweisen. • Unternehmensspezifischer Standardsatz von Merkmalen: Auch wenn jede Projektumgebung ihre eigenen spezifischen Merkmale besitzt und es gefordert wird, für jedes einzelne Projekt individuelle Qualitätsmerkmale zu definieren, so ist ein standardisierter Merkmalskatalog für ein eng begrenztes Themengebiet bzw. für ein Unternehmen sinnvoll. Dies ist auch aus Sicht der Vergleichbarkeit von Projekten bzw. der Einordbarkeit neuer Projekte sinnvoll. • Intuitive und verständliche Begrifflichkeiten: Ein Merkmal und die dazugehörige Beschreibung müssen von Projektleitern, den Entscheidern, intuitiv leicht zu verstehen sein und die Kommunikation in der Entwicklungsgruppe unterstützen. Für diese Projektmanagementsicht müssen Merkmale möglichst vereinfacht und abstrakt dargestellt werden, damit sie nutzbar sind. Auch die Ausprägung eines Merkmals muss schnell und aufwandsarm in nur kurzer Zeit schätzbar sein.

7.2 Vorgehensweisen zur Anwendung der Entscheidungsunterstützung

93

Um ein gemeinsames Verständnis für die qualitativen Ausprägungen (gering, mittel und hoch) in den Profilen zu bekommen, ist es erforderlich, dass diese für jedes Merkmal eindeutig beschrieben werden. Als Beispiel sei hier der Wiederverwendungsgrad aufgeführt: Er sei gering bei < 30 %, hoch bei > 70 % und ansonsten mittel. 7.2.3

Bestimmung relevanter Merkmale

In Anlehnung an die nominale Gruppentechnik gibt es sieben Phasen, um relevante Merkmale für ein Profil zu identifizieren. Phase 1: Einführung

Zeitbedarf: ca. 60 min. Der Moderator gibt eine kurze Präsentation über die zu bearbeitende Aufgabenstellung. Dies beinhaltet die Vorstellung des Konzepts der Entscheidungsunterstützung mit den Profilbeschreibungen Entwicklungsprofil, QSAnforderungsprofil und QS-Maßnahmenprofil. Der Moderator nennt einige Beispiele für mögliche Merkmale, um die Zielsetzung besser verständlich zu machen. Nach der Klärung der Aufgabenstellung erläutert der Moderator den Ablauf des Gruppenprozesses. Phase 2: Suche nach Merkmalen

Zeitbedarf: ca. 10 min. Der Moderator gibt eine Definition des betrachteten Merkmalstyps, stellt die möglichen Kategorien für die Merkmale dar und formuliert bzw. schreibt für jeden sichtbar die konkrete Aufgabenstellung wie folgt: • Bei Entwicklungsmerkmalen: „Welche Merkmale des EntwicklungsKontexts haben nach ihrer Meinung einen Einfluss auf die Planung der Qualitätssicherung in unserem Unternehmen? Was sind Kriterien zur Unterscheidung von Projekten oder Risikofaktoren für ein Projekt?“ • Bei Qualitätsmerkmalen: „Welche Merkmale zur Definition der Qualität sind nach ihrer Meinung in unserem Unternehmen notwendig?“ • Bei QSM-Merkmalen: „Welche Merkmale von QS-Maßnahmen sind nach ihrer Meinung für ihre Auswahl wichtig?“ Nun schreibt jedes Gruppenmitglied für sich eine Liste von Merkmalen, unterschieden nach der jeweiligen Kategorie, auf Karteikarten. Für dieses

94

7 Auswahl von QS-Maßnahmen

Brainstorming sind ca. 10 Minuten vorgesehen, bei der jeweils mit ca. 10 Vorschlägen gerechnet werden kann. Phase 3: Sammlung der Merkmale

Zeitbedarf: ca. 60 min. In dieser Phase werden, für alle sichtbar, nacheinander alle Vorschläge aufgenommen. Als Medium kann hier ein Laptop mit einem Beamer oder ein Whiteboard verwendet werden. Reihum nennt jeder Teilnehmer jeweils ein Merkmal, dass unter Verwendung der gleichen Begrifflichkeit des Vorschlagenden vom Moderator notiert wird. Um die anschließende Klärungsphase (Phase 4: Klärung der Merkmale) knapp zu halten, darf der Vorschlagende eine kurze Beschreibung zu seinem Merkmal geben, wenn er der Auffassung ist, dass dies zum Verständnis notwendig ist. Dabei sind jedoch keine Rückfragen und Diskussionen erlaubt. Etwaige Fragen sind zu notieren und in der anschließenden Klärungsphase zu stellen. Je nach Konstellation der Gruppe und der sich dadurch ergebenden Arbeitsatmosphäre können die Sammlung aller Karteikarten und die anonyme Darstellung durch den Moderator angebracht sein. Das Ergebnis dieser Phase stellen ca. 50 Vorschläge für Merkmale dar. Phase 4: Klärung der Merkmale

Zeitbedarf: ca. 30 min. Diese Phase dient zur Ausräumung von Verständnisschwierigkeiten. Jedes Gruppenmitglied darf zur inhaltlichen Klärung von Merkmalen Fragen stellen, die in der Gruppe erörtert werden. Dabei muss insbesondere der Moderator Acht geben, dass hier noch keine Wertung vorgenommen wird. Phase 5: Erweiterung der Merkmale

Zeitbedarf: ca. 30 min. Zunächst analysiert der Moderator das bisherige Ergebnis und streicht für jeden Teilnehmer sichtbar offensichtlich identische Merkmale aus der Liste. Um eine mögliche „Betriebsblindheit“ der Gruppenteilnehmer zu vermeiden, stellt der Moderator nun einen Standard-Katalog2 an Merkmalen vor, der aus einer Literaturanalyse entstanden ist. In der folgenden Diskus2

Entsprechende Standard-Kataloge sind im Anhang von [42].

7.2 Vorgehensweisen zur Anwendung der Entscheidungsunterstützung

95

sion können fehlende und für wichtig erachtete Merkmale aus dem Standard-Katalog in die eigene Liste übertragen werden. Weiterhin ist es erlaubt, zusätzliche Merkmale aufzunehmen, die zum Beispiel in folge neuer Erkenntnisse und Assoziationen mit anderen Merkmalen entstanden sind. Auch in dieser Phase ist darauf zu achten, dass keine Wertung erfolgt. Am Ende dieser Phase ist durch Streichung doppelter Merkmale und die Berücksichtigung neuer Merkmale weiterhin mit ca. 50 Merkmalen zu rechnen. Phase 6: Reduzierung der Merkmale

Zeitbedarf: ca. 30 min. Ziel dieser Phase ist es, die Merkmalsliste auf die wesentlichen, kritischen Merkmale zu reduzieren. Die maximal erlaubte Anzahl an Merkmalen ist ca. ein Dutzend. Zur Bestimmung kritischer Merkmale wird in der nominalen Gruppentechnik ein geheimes Wahlverfahren vorgesehen. Zunächst bestimmt jeder Teilnehmer separat die für ihn wichtigsten zwölf Merkmale je Kategorie. Anschließend wird diese Liste in die drei Klassen gering, mittel und hoch unterteilt. Bei einem geheimen Wahlverfahren sammelt der Moderator die priorisierten Listen und arbeitet diese in eine Ergebnistabelle – praktischer Weise ein Excel-Sheet – ein. Anderenfalls können die Wertungen je Merkmal reihum abgefragt werden. Die ausgewählten Merkmale werden nach ihrer Gewichtung sortiert und in der nächsten Phase diskutiert. Phase 7: Konsolidierung der Merkmale

Zeitbedarf: ca. 30 min. In dieser Phase wird eine endgültige Liste relevanter Merkmale festgelegt. Dazu wird die Ergebnisliste aus der vorherigen Phase in der Gruppe erörtert. Ziel der Diskussion ist zu prüfen, ob ggf. Merkmale – ohne wesentliche Informationen zu verlieren – zusammengefasst werden können. Falls weiterhin die Anzahl der Merkmale je Kategorie mehr als ein Dutzend ist, bzw. die Gruppenteilnehmer der Auffassung sind, dass die Liste zu lang ist, kann eine erneute Priorisierung durch die Teilnehmer zur endgültigen Auswahl relevanter Merkmale führen. Die Protokollierung dieses Gruppenprozesses erleichtert die Beschreibung der Merkmale, was im nachfolgenden Kapitel behandelt wird.

96

7 Auswahl von QS-Maßnahmen

7.2.4

Beschreibung von Merkmalen

Wesentlich ist, dass die sog. Experten schon im Rahmen der Bestimmung relevanter Merkmale zusammengekommen sind und die meisten Merkmale geklärt haben. Folglich wird zur Beschreibung von Merkmalen eine Delphi-Methode aus vier Phasen vorgeschlagen. Phase 1: Erarbeitung eines Vorschlags

Zeitbedarf: ca. 2 Tage In Abstimmung mit dem Moderator erstellt der Protokollant des GruppenProzesses der Phase „Ermittlung relevanter Merkmale“ eine erste Version der Beschreibung von Merkmalen. Neben einer inhaltlichen Begriffserklärung muss die Beschreibung auch eine Definition darüber enthalten, wann die Ausprägungen eines Merkmals gering, mittel oder hoch zu setzen sind. Dies ist notwendig, damit eine einheitliche und nachvollziehbare Sicht der qualitativen Werte sichergestellt ist. Insgesamt sollte die Beschreibung eines Merkmals möglichst kompakt sein und einen Umfang von ca. zwei Zeilen vorweisen. Bei der Definition der Ausprägungsstufen ist zwischen subjektiven und objektiven Merkmalen zu unterscheiden. Beide Typen sind in eine intuitive Beschreibung mittels gering, mittel und hoch zu überführen. Dieses Vorgehen ist beispielhaft in Abb. 7.7 dargestellt. Objektives Merkmal

Subjektives Merkmal

Beispiel Wiederverwendungsgrad

Beispiel Team-Erfahrung

Ausprägungen

z.B. Anzahl wiederverwendeter Module

gering

mittel

hoch

< 30% 30-70% > 70%

Ausprägungen

gering

mittel

hoch

0-1

2-5

>5

z.B. Anzahl Berufsjahre

Abb. 7.7. Definition der Ausprägungsstufen eines Merkmals

Um die Stellungnahme der Gruppenmitglieder zu vereinfachen, macht es Sinn, alle Merkmale durchzunummerieren. Das Vorschlagsdokument wird einschließlich etwaiger Lücken und mit der Kennzeichnung noch unklarer Stellen innerhalb von drei Tagen nach der Ermittlung relevanter Merkmale erstellt und der Expertengruppe zugestellt.

7.2 Vorgehensweisen zur Anwendung der Entscheidungsunterstützung

97

Phase 2: Erste Expertenstellungnahmen

Zeitbedarf: ca. 0,5 Tage Die erste Stellungnahme der Experten läuft entsprechend der DelphiMethode geografisch getrennt und voneinander unabhängig. Es ist mit einem Aufwand von ungefähr einem halben Tag zu rechnen und sollte innerhalb von zwei Tagen nach Erhalt des Vorschlags bearbeitet werden. Aufgabe der Experten ist es, die Erklärung zu einem Merkmal einschließlich deren Definition der Ausprägungsstufen zu analysieren. Alle Kommentare werden schriftlich an den Moderator verschickt und sollten jeweils die Nummer des Merkmals, das Merkmal selbst sowie den Verbesserungsvorschlag einschließlich einer kurzen Begründung enthalten. Phase 3: Auswertung der Stellungnahmen

Zeitbedarf: ca. 0,5 Tage Die individuellen Stellungnahmen der Experten werden durch den Moderator gesammelt und innerhalb von zwei Tagen zusammengefasst und zur Bearbeitung in der nächsten Phase zur Verfügung gestellt. Der Moderator arbeitet alle übereinstimmenden bzw. ähnlichen Positionen direkt in einen neuen Vorschlag ein. Liegen starke Abweichungen vor, so werden sie zur Sichtung durch die anderen Teilnehmer separat zusammengetragen. Aus Aufwandsgründen kann ggf. der Moderator telefonisch eine Vorklärung über eine Extremposition einholen. Alle Änderungen zur Vorversion der Beschreibungen werden deutlich gekennzeichnet, um die nächste Stellungnahme zu vereinfachen. Insgesamt dürfte diese Phase einen halben Tag in Anspruch nehmen und sollte spätestens nach zwei Tagen abgeschlossen sein. Entgegen der ursprünglichen Delphi-Methode sind keine weiteren Bewertungszyklen vorgesehen. Vielmehr wird das endgültige Ergebnis in Form einer interaktiven Diskussionsrunde erarbeitet. Dies bedingt, dass die aktuelle Beschreibung der Merkmale allen Gruppenteilnehmern spätestens zwei Tage vor der Sitzung zur Begutachtung zugestellt wird.

98

7 Auswahl von QS-Maßnahmen

Phase 4: Konsolidierung der Beschreibungen

Zeitbedarf: ca. 0,5 Tage Der Moderator stellt die aktuelle Version der Merkmalsbeschreibungen Schritt für Schritt vor. Falls ein Teilnehmer Einwände bzw. Klärungsbedarf hat, meldet er sich und verteidigt seine Position. Die Ergebnisse der dazugehörigen Diskussion werden vom Moderator – ohne eigene Wertung und unter Beachtung der Konsensbildung – zusammengefasst und für jeden sichtbar in das Beschreibungsdokument eingearbeitet. Am Ende dieser Diskussionsphase liegt die endgültige Fassung der Merkmalsbeschreibungen vor. 7.2.5

Vorgehensweise zur Beschreibung von Profilen

Die Vorgehensweise zur Beschreibung konkreter Profile durch die Festlegung der Merkmalsausprägungen und ihrer Begründungen beinhaltet im Kern die Delphi-Methode. Da Entwicklungsprofile, QS-Anforderungsprofile und QS-Maßnahmenprofile sich von ihrer Zielsetzung wesentlich unterscheiden, sind drei unterschiedliche Vorgehensweisen vorhanden. Entwicklungsprofile werden nach der Bestimmung zu betrachtender Projektklassen in Anlehnung an die Delphi-Methode, bestehend aus den Schritten Vorschlag, Stellungnahme und Konsolidierung, erarbeitet. In ähnlicher Vorgehensweise werden aus den Entwicklungsprofilen die dazugehörigen QS-Anforderungsprofile abgeleitet. Dagegen ist ein zweistufiges Vorgehen bei QS-Maßnahmenprofilen vorgesehen. Für das Unternehmen relevante QS-Maßnahmen (QSM) werden zunächst verbal und strukturiert durch QSM-Datenblätter beschrieben. Anschließend werden daraus die für die Entscheidungsunterstützung relevanten qualitativen Bewertungen vorgenommen und in Form von QS-Maßnahmenprofilen dokumentiert. Aus Aufwandsgründen ist für die QS-Maßnahmen innerhalb der Expertengruppe ein Methodenteam vorgesehen, das die Federführung für die QS-Maßnahmenprofile übernimmt.

7.2 Vorgehensweisen zur Anwendung der Entscheidungsunterstützung 7.2.6

99

Beschreibung von Entwicklungsprofilen

Die Beschreibung der Entwicklungsprofile erfolgt in vier Phasen. Phase 1: Bestimmung von Projektklassen

Zeitbedarf: ca. 60 min. Im Rahmen eines Brainstormings werden relevante Projektklassen identifiziert, für die jeweils ein Entwicklungsprofil erarbeitet wird. Der Moderator stellt an alle Gruppenmitglieder die Frage, welche Klassen von Projekten sie im Unternehmen unterscheiden würden. Dabei kann er entsprechende Beispiele zur Verdeutlichung angeben.3 In einer BrainstormingPhase (ca. 20 min.) sammelt der Moderator, für jeden sichtbar, die spontan genannten Ideen. Anschließend erfolgt unter Anleitung des Moderators eine Auswertungs- und Strukturierungsphase. Das Ergebnis mit den ermittelten Projektklassen wird vom Moderator in eine Matrixdarstellung überführt, in der sich die Merkmale eines Profils in den Zeilen befinden und für jede Projektklasse zwei Spalten für die Ausprägungen und Begründungen existieren. (Kapitel 7.1.1 – Tabelle 7.3). Phase 2: Vorschläge für Profilbeschreibungen

Zeitbedarf: ca. 1 Tag In dieser Phase erarbeitet jedes Gruppenmitglied die Entwicklungsprofile durch Festlegung der Merkmalsausprägungen gering, mittel oder hoch. Zu jeder Ausprägung gehört auch eine kurze Begründung. Dabei sollten alle Entwicklungsprofile gemeinsam betrachtet und festgelegt werden. Diese Aufgabe kann im direkten Anschluss an die gemeinsame Sitzung aus der Phase 1 am gleichen Ort innerhalb eines Tages erledigt werden. Jedoch kann auch eine getrennte Bearbeitung erfolgen, wobei eine kurze Frist von z. B. zwei Tagen gewählt werden sollte, um die Konzentration auf das Thema zu erhalten. Phase 3: Auswertung der Profilbeschreibungen

Zeitbedarf: ca. 1 Tag Die individuellen Vorschläge der Experten werden durch den Moderator gesammelt und innerhalb von zwei Tagen in eine Ergebnismatrix zusammengefasst. Übereinstimmende Positionen werden direkt in die Lösung 3

Beispiele für Projektklassen in der Literatur sind im Anhang von [42] zu finden.

100

7 Auswahl von QS-Maßnahmen

eingearbeitet und starke Abweichungen separat zusammengetragen. Aus Aufwandsgründen kann ggf. der Moderator telefonisch eine Vorklärung über eine Extremposition einholen. Phase 4: Konsolidierung der Profilbeschreibungen

Zeitbedarf: ca. 1 Tag Die Erarbeitung der endgültigen Entwicklungsprofile erfolgt in Form von Gruppendiskussionen. In der Sitzung stellt der Moderator die aktuelle Version der Profilbeschreibungen vor. Alle Gruppenteilnehmer dürfen jederzeit und spontan Einwände bzw. Klärungsbedarf anmelden. Die Ergebnisse der dazugehörigen Diskussion werden vom Moderator – ohne eigene Wertung und unter Beachtung der Konsensbildung – zusammengefasst und für jeden sichtbar in die Profilbeschreibungen eingearbeitet. Falls zu große Differenzen eine Konsensbildung nicht zulassen, ist zu prüfen, ob die Einführung von Varianten einer Projektklasse angebracht ist. 7.2.7

Beschreibung von QS-Anforderungsprofilen

Die Vorgehensweise zur Beschreibung der QS-Anforderungsprofile entspricht weitgehend der Vorgehensweise bei den Entwicklungsprofilen. Da zu jedem Entwicklungsprofil ein QS-Anforderungsprofil gehört, existiert keine Phase, die analog zur Bestimmung von Projektklassen wäre. Die Phasen „Auswertung der Profilbeschreibungen“ und „Konsolidierung der Profilbeschreibungen“ können ohne Änderungen übernommen werden. Dagegen gibt es Unterschiede in der Phase „Vorschläge für Profilbeschreibungen“, die nachfolgend genau erörtert wird. Die Gruppenmitglieder leiten aus den Entwicklungsprofilen QSAnforderungsprofile schriftlich ab. Dies erfolgt ebenfalls durch Festlegung der Ausprägungen betroffener Merkmale einschließlich einer kurzen Begründung. Jeder Gruppenteilnehmer untersucht dazu die konkrete Beschreibung des betrachteten Entwicklungsprofils und leitet daraus die Anforderungen an die Qualitätssicherung in Form von Regeln ab. Um die Nachvollziehbarkeit der Planung zu sichern, werden diese Regeln in der Begründungsspalte der Profilbeschreibung dokumentiert. Die Regeln sind so aufgebaut, dass sie Entwicklungsmerkmale mit ihren Ausprägungen logisch verknüpfen. Bei der Ableitung von QS-Anforderungen ist zusätzlich Folgendes zu beachten: Falls für die Definition einer Regel die verwendeten Entwicklungsmerkmale nicht ausreichen, ist dies ein Zeichen dafür, dass im Entwicklungsprofil weitere Merkmale fehlen. Existieren dagegen Entwick-

7.2 Vorgehensweisen zur Anwendung der Entscheidungsunterstützung

101

lungsmerkmale, die in keiner Regel vorkommen, so sind sie für die Planung der Qualitätssicherung irrelevant, falls sie auch in anderen QSAnforderungsprofilen nicht genutzt werden. Wenn zwei unterschiedliche Entwicklungsprofile zu identischen QS-Anforderungsprofilen führen, ist von fehlenden Merkmalen im QS-Anforderungsprofil auszugehen bzw. das Entwicklungsprofil muss um weitere unterscheidende Entwicklungsmerkmale erweitert werden. Beide Problempunkte sind in der Phase „Konsolidierung der Profilbeschreibungen“ zu diskutieren und zu bearbeiten.

Entwicklungsprofil Merkmal Ausprägungen

QS-Anforderungsprofil Merkmal Ausprägungen

Begründung

EM1

gering

M1

gering

...

EM2

mittel

M2

mittel

EM1=gering UND EM3=mittel

EM3

mittel

M3

mittel

...

EM4

hoch

M4

hoch

EM3=mittel UND EM5=gering

EM5

gering

M5

gering

...

...

...

...

...

...

Regeln

Abb. 7.8. Überführung eines Entwicklungsprofils in ein QS-Anforderungsprofil

Die weiteren Phasen zur Beschreibung von QS-Anforderungsprofilen laufen analog zu den letzten beiden Phasen zur Beschreibung von Entwicklungsprofilen ab. 7.2.8

Beschreibung von QS-Maßnahmenprofilen

Die Erstellung der Profilbeschreibung für QS-Maßnahmen ist die aufwendigste der drei Profiltypen und kann bis zu 10 Tage pro Profil in Anspruch nehmen. Bevor die eigentliche, qualitative Bewertung einer QSMaßnahme vollzogen werden kann, ist zu klären, welche QS-Maßnahmen insgesamt betrachtet werden sollten.

102

7 Auswahl von QS-Maßnahmen

QSM-Datenblatt Kriterium

QS-Maßnahmenprofil Beschreibung

z.B. Bezeichnung Programmierrichtlinien

Merkmal Ausprägungen

Begründung

M1

gering

...

z.B. Vorteile

...

M2

mittel

...

z.B. Nachteile

...

M3

mittel

...

...

...

...

...

...

Abb. 7.9. Überführung des QSM-Datenblatts in ein QS-Maßnahmenprofil

Die in Abb. 7.9 angedeutete Variante der qualitativen Bewertung ist sicherlich aufwändig, besitzt jedoch Vorteile, die diesen Aufwand rechtfertigen: • Ein QSM-Datenblatt stellt die Kurzbeschreibung einer QS-Maßnahme dar, die in natürlicher Sprache formuliert und somit dem Leser leicht zugänglich ist. • Die Festlegung der Ausprägungen und Begründungen eines Merkmals anhand des QSM-Datenblatts führt zu mehr Transparenz und ermöglicht sicherere Bewertungsschätzungen als ohne die Nutzung des QSMDatenblatts. Methodenteam und Reviewteam

Da es eine Vielzahl von QS-Maßnahmen zu bewerten gilt, macht es aus Aufwandsgründen Sinn, ein kleines Team mit 2 - 3 Mitgliedern – genannt Methodenteam – zu gründen, das die jeweiligen Vorschläge in den TeilAufgaben intensiv erarbeitet. Die restlichen Mitglieder der Gruppe fungieren dabei als Experten (Reviewteam), die entsprechende Stellungnahmen zu den Vorschlägen abgeben. Diese Trennung ist insbesondere dann nahe liegend, wenn innerhalb eines Unternehmens bereits eine Methodenabteilung existiert. Nachfolgend wird die Vorgehensweise zur Ableitung von QSMaßnahmenprofilen aus QSM-Datenblättern erläutert. Phase 1: Vorschlag des Methodenteams

Auf der Grundlage des QSM-Datenblatts – der verbalen Kurzbeschreibung einer QS-Maßnahme – leitet das Methodenteam im Rahmen einer interaktiven Diskussion eine qualitative Bewertung ab und legt für jedes Merkmal

7.2 Vorgehensweisen zur Anwendung der Entscheidungsunterstützung

103

im QS-Maßnahmenprofil die Ausprägung gering, mittel oder hoch fest. Dabei werden jeweils in der Begründungsspalte des QSMaßnahmenprofils die Ausprägungen anhand der Einträge im QSMDatenblatt begründet. Da es sich bei den Bewertungen um Schätzungen handelt, ist es angebracht, alle Bewertungen für eine Klasse von QSMaßnahmen, also analytisch, konstruktiv oder organisatorisch, z. B. in Form einer Matrix-Darstellung gegenüberzustellen und kritisch zu vergleichen. Dabei können ggf. kleinere Anpassungen in der Bewertung einzelner QS-Maßnahmen angebracht sein. Für die Erarbeitung dieses Bewertungsvorschlags ist mit maximal einer Woche Aufwand zu rechnen. Dabei sind ca. 30 min. je QS-Maßnahme anzusetzen. Phase 2: Stellungnahme der Experten

In dieser Phase begutachtet jedes Mitglied des Reviewteams die Bewertungsvorschläge zu den QS-Maßnahmen. Die Anmerkungen werden notiert und in der folgenden Konsolidierungsphase eingebracht. Phase 3: Konsolidierung der Profilbeschreibungen

Der Moderator des Methodenteams stellt die aktuelle Version der QSMaßnahmenprofile nacheinander vor. Dabei kann jederzeit ein Teilnehmer Einwände bzw. Klärungsbedarf anmelden, die diskutiert werden. Das entsprechende Ergebnis wird vom Moderator , wiederum ohne eigene Wertung und unter Beachtung der Konsensbildung, zusammengefasst und für jeden sichtbar, z. B. durch Einsatz von Laptop und Beamer, in die QSMaßnahmenprofile eingearbeitet. Am Ende dieser Diskussionsphase entsteht die endgültige Fassung der QS-Maßnahmenprofile. 7.2.9

Verwendung und Anpassung des Entscheidungsmodells

In diesem Kapitel wird auf die Nutzung der Entscheidungsunterstützung zur Feinplanung der Qualitätssicherung eingegangen und erläutert, wann und wie Anpassungen an dem Entscheidungsmodell vorzunehmen sind.

104

7 Auswahl von QS-Maßnahmen

Feinplanung der Qualitätssicherung

Die Ergebnisse der Strukturplanung werden für die QS-Planung in konkreten Projekten wie folgt genutzt: 1. Einordnung des Projekts in ein vorhandenes Entwicklungsprofil: Der Projektleiter prüft, ob das aktuelle Projekt weitestgehend durch ein bestehendes Entwicklungsprofil abgedeckt wird. Falls aus Sicht des Projektleiters keine zufrieden stellende Auswahl getroffen werden kann, ist ggf. ein neues Entwicklungsprofil zu definieren. 2. Ergänzende Beschreibung des Entwicklungsprofils: Das Entwicklungsprofil aus der Entscheidungsunterstützung stellt eher eine Grobbeschreibung des Entwicklungskontexts dar. Für die Feinplanung ist es sinnvoll, den Kontext eines konkreten Projekts zu detaillieren. Um auch die Nachvollziehbarkeit der Feinplanung sicherzustellen, ist es angebracht, diese Detaillierung stichpunktartig zu dokumentieren. 3. Analyse der Ergebnisse aus der Strukturplanung: Unter Beachtung der in Punkt 2 erfolgten Detailbeschreibung des Projekts werden die Empfehlungen an QS-Maßnahmen für das betroffene Entwicklungsprofil kritisch begutachtet. Dabei kann eine Zurückverfolgung der Empfehlungen hilfreich sein. Ergänzend hierzu kann jeweils das QSM-Datenblatt gesichtet werden. 4. Endgültige Auswahl von QS-Maßnahmen: Ausgehend von den unter Punkt 3 gewonnen Erkenntnissen erfolgt die endgültige Auswahl angemessener QS-Maßnahmen für ein konkretes Projekt. Die dabei getroffenen Entscheidungen sind ebenfalls in einem Dokument festzuhalten. 5. Termin- und Ressourcenplanung: Unter Zuhilfenahme der Datenblätter der ausgewählten QS-Maßnahmen erfolgt im Rahmen des Projektmanagements die Termin- und Ressourcenplanung der Qualitätssicherung. Die Dokumentation aller Teilentscheidungen ist nicht nur für die Nachvollziehbarkeit der Feinplanung sinnvoll, sie stellt auch gleichzeitig die Grundlage für die kontinuierliche und erfahrungsgetriebene Verbesserung der Entscheidungsunterstützung dar. Anpassung des Entscheidungsmodells

Nach der Entwicklung eines Entscheidungsmodells erfolgt eine kontinuierliche und erfahrungsbasierte Verbesserung dieses Modells. Durch diese Lernzyklen wird das Entscheidungsmodell nachhaltig verbessert. In regelmäßigen Zeitabständen – z. B. vier Monate – sind Erfahrungen mit der Anwendung des Entscheidungsmodells in der Expertengruppe zu

7.2 Vorgehensweisen zur Anwendung der Entscheidungsunterstützung

105

diskutieren. Diese regelmäßigen Sitzungen können in Form eintägiger Arbeitssitzungen erfolgen und nachfolgende Aktionen beinhalten. Anlegen eines neuen Entwicklungsprofils bzw. QSMaßnahmenprofils

Die aus den Projekten gewonnenen Erfahrungen geben konkrete Hinweise zur Beschreibung eines neuen Entwicklungsprofils. So kann unter Anleitung des Moderators in kurzer Zeit eine Profilbeschreibung im Rahmen einer Gruppendiskussion erstellt werden. Dagegen ist die anschließende Ableitung des dazugehörigen QS-Anforderungsprofils ein wenig aufwendiger. Soll eine neue QS-Maßnahme aufgenommen werden, wird zunächst ein QSM-Datenblatt erstellt und anschließend das dazugehörige QSMaßnahmenprofil abgeleitet. Anpassung von Profilbeschreibungen

Der geringste Aufwand bei Anpassungen ergibt sich bei der Änderung der Merkmalsausprägungen von Profilbeschreibungen. Insbesondere bei QSMaßnahmenprofilen ist eine ständige Überprüfung erforderlich. Idealerweise werden dazu die Kosten und Wirkungen der eingesetzten QSMaßnahmen im Rahmen von Projektabschlusssitzungen analysiert und dokumentiert. Im Rahmen der turnusmäßigen Anpassung von Profilbeschreibungen kann dann auf diese Dokumente zurückgegriffen werden. Anpassung der Profildefinitionen

Beim Löschen bzw. Ergänzen von Merkmalen ist zu beachten, dass das Konzept der Entscheidungsunterstützung einen Standardsatz für alle Profilbeschreibungen vorzieht. Das Löschen eines Merkmals wirkt sich somit auf alle dazugehörigen Profilbeschreibungen aus. Folglich sollte dieser Schritt wohlüberlegt sein und z. B. ausschließen, dass das betroffene Merkmal bei einer Profilbeschreibung große Relevanz hat. Ähnliches gilt für das Hinzufügen eines neuen Merkmals, was keinesfalls zur Explosion der Anzahl von Merkmalen führen darf. Bei einem neuen Merkmal sind in allen betroffenen bisher existierenden Profilbeschreibungen die Ausprägungen nachzutragen. Sind Qualitäts- oder QSM-Merkmale von Änderungen betroffen, so ist zu beachten, dass beide Fälle Auswirkungen auf QSAnforderungsprofile und QS-Maßnahmenprofile haben.

8 Anwendung von QSM in der Praxis

Das erstmalige Einführen einer QS-Maßnahme ist in den Anfangsphasen mit einem zusätzlichen Mehraufwand verbunden. Gerade dieser anfängliche Mehraufwand schreckt viele Unternehmen davor ab, eine neue QSMaßnahme einzuführen. Um diesem Mehraufwand entgegenzuwirken, wurden deshalb von verschiedenen Unternehmen als besonders relevant eingestufte QS-Maßnahmen aus praxisnaher Sicht beschrieben. Es wurde dargestellt, wie einzelne QS-Maßnahmen in Unternehmen tatsächlich eingesetzt werden. Zusätzlich zu der eigentlichen Anwendungsbeschreibung wurden die Maßnahmen von den Firmen fachlich und wirtschaftlich bewertet und zusätzlich praktische Tipps bei der Einführung der Maßnahme gegeben. Durch diese so genannten „QSM in der Praxis-“ Dokumente können Erfahrungswerte, welche die jeweiligen Firmen mit den QS-Maßnahmen gemacht haben, an die Leser und Anwender weitergegeben werden. Damit soll eine schnellere und aufwandsärmere Einführung der Maßnahme erreicht werden. Um die „QSM in der Praxis-“ Dokumente möglichst einheitlich zu gestalten, wurden sämtliche Dokumente mit der folgenden Gliederung erstellt: • Kurzbeschreibung: allgemeine Beschreibung der QS-Maßnahme aus Sicht des Unternehmens. • Einsatzumfeld: Darstellung des Unternehmens und des konkreten Einsatzumfelds der Methode. • Vorgehensweise: Beschreibung der Einführung und Anwendung der Maßnahme in dem Unternehmen • Bewertung: Bewertung des QSM-Einsatzes innerhalb des Unternehmens aus fachlicher und wirtschaftlicher Sicht. • Praktische Tipps: Hinweise und zusätzliche Tipps, wie der Einsatz der QSM effizienter gestaltet werden kann.

108

8 Anwendung von QSM in der Praxis

Folgende „QSM in der Praxis“-Dokumente wurden erstellt: • • • • • • • • • • • •

Änderungsmanagement Anforderungsverfolgung Defect Management Fehler-Möglichkeits- und Einfluss-Analyse Funktionstest Nutzung eines Phasenmodells Objektorientierte Analyse und Design mit UML Regressionstest (1) Regressionstest (2) Review-Techniken Risikomanagement Softwareänderungs-Management Für den interessierten Leser gibt es die Möglichkeit einen zusätzlichen Service zu nutzen. Interaktive Inhalte zum Verbundprojekt EQUAL sind unter www.embedded-quality.de abrufbar. Unter www.embedded-quality.de/Fachbuch/Kapitel8 sind weitere Beispiele und Erläuterungen zu den im folgenden beschriebenen „QSM in der Praxis“-Dokumente abrufbar.

8.1 Änderungsmanagement

8.1

109

Änderungsmanagement

Das Änderungsmanagement dient der Erfassung und Verwaltung von eingehenden Änderungsanträgen zu bereits freigegebenen Entwicklungsdokumenten. Über Ablehnung oder Annahme des Änderungsantrags wird im Änderungskontrollgremium (siehe Abschnitt 3) situationsabhängig entschieden. Dabei sind die technischen, terminlichen und finanziellen Auswirkungen auf das Projekt zu berücksichtigen. Bei Annahme des Änderungsantrags veranlasst und überwacht der Änderungsmanager die Umsetzung durch das Entwicklungsteam. Abschließend werden die betroffenen Personen informiert. Die wesentlichen Ziele des Änderungsmanagements sind: • Die Nachvollziehbarkeit von Änderungen bzw. die kontrollierte Weiterentwicklung von bereits freigegebenen Projektergebnissen • Die Abschätzung und Aufwandskontrolle für Änderungsanträge • Der Überblick über offene oder abgeschlossene Änderungsanträge (z.B. zur Releaseplanung oder Auswertung von Metriken) 8.1.1

Einsatzumfeld

Das Unternehmen

Die method park Software AG ist ein mittelständisches Software-Haus mit ca. 40 Mitarbeitern und Sitz in Erlangen. method park unterstützt seine Kunden durch Beratungsdienstleistungen zu Themen aus dem SoftwareEngineering, eigene Produkte (C-Codegenerator aus UML-Diagrammen sowie ein Prozessmanagement-Werkzeug) sowie durch SoftwareEntwicklungsdienstleistungen. Ein Großteil der Kunden und Kooperationspartner von method park sind im Embedded-Umfeld tätig. Typische Zielbranchen sind Automobilhersteller und -zulieferer, Medizintechnik, Consumer Electronics, Maschinenbau und Industrieautomatisierung. Einsatzumfeld der Maßnahme

Die eingangs geschilderte Vorgehensweise ist in kleinen bis mittelgroßen Projekten gebräuchlich. Abweichungen von diesem Vorgehen finden sich vor allem, wenn das Änderungsmanagement nicht direkt in der Entwicklung angewendet wird, sondern beispielsweise für eine Produkt-Hotline. Auch die Projektorganisation – insbesondere bei größeren Projekten – hat typischerweise Auswirkungen auf die Ausgestaltung des Änderungsmanagements, indem etwa zusätzliche Rollen am Ablauf beteiligt sind.

110

8 Anwendung von QSM in der Praxis

Es hebt sich bezüglich des Änderungsmanagements eine Rolle im Projekt besonders hervor: der „Änderungsmanager“. Diese Rolle – häufig auch vom Projektleiter mit übernommen – wird im Abschnitt 8.1.2 „Anwendung“ genauer beschrieben. 8.1.2

Vorgehensweise

Motivation für den Einsatz

Änderungsmanagement ist ein „Muss“ in der Projektabwicklung. Typische Folgen einer mangelnden Umsetzung sind Projekte, die aufgrund sich häufig ändernder oder neuer Anforderungen den Kosten- und Zeitrahmen sprengen oder Festpreisprojekte, die für den Auftragnehmer unrentabel werden. Inkonsistente Dokumentation nach Bearbeitung eines Änderungsantrags oder das Auftreten neuer Fehler, nachdem ein Änderungsantrag eigentlich umgesetzt wurde, sind symptomatisch für unzureichendes Änderungs- und Konfigurationsmanagement. Anwendung

Der Arbeitsablauf zu Änderungsanträgen (also das Erstellen eines Änderungsantrages) gliedert sich in die folgenden groben Arbeitsschritte (Abb. 8.1): 1. Durchführung einer Vorprüfung (z.B. Prüfung auf ausreichende Beschreibung des Änderungsantrages) 2. Prüfung, ob der Änderungsantrag durchgeführt werden soll (z.B. Kosten-Nutzen-Verhältnis beachten) und gegebenenfalls Zwischenbescheid an den Antragsteller 3. Bei positivem Prüfergebnis: Durchführung des Änderungsantrags inklusive abschließender Überprüfung auf korrekte Umsetzung 4. Benachrichtigung des Antragstellers, wie mit dem Änderungsantrag verfahren wurde (abgelehnt, implementiert o.ä.) Bei dieser Vorgehensweise spielt vor allem der „Änderungsmanager“ und das „Änderungskontrollgremium“ eine besondere Rolle: Die Hauptrolle im Änderungsmanagement spielt der Änderungsmanager. Er nimmt die an das Projektteam herangetragenen Änderungsanträge entgegen und organisiert die weitere Bearbeitung. Der Änderungsmanager ist damit quasi die Schnittstelle zwischen Außenwelt und Projektteam. Gerade bei kleineren Projekten werden die Aufgaben des Änderungsmanagers häufig vom Projektleiter oder alternativ vom Systemanalytiker

8.1 Änderungsmanagement

111

übernommen. Wichtig ist dabei, dass es nur eine Person ist, die diese Aufgaben übernimmt. Anderenfalls kommt es schnell zu Abstimmungsproblemen gegenüber dem Kunden. Der Änderungsmanager ist verantwortlich für die folgenden wesentlichen Aktivitäten: • Er definiert die Vorgehensweise des Änderungsmanagements bzw. passt die Vorgehensweise eines eventuell übergeordnet definierten Änderungsmanagements den aktuellen Gegebenheiten des Projektes an. • Er legt die Form eines Änderungsantrags fest (z.B. schriftlich, via EMail etc.). • Er schirmt den Rest des Projektteams hinsichtlich der Änderungsanträge gegenüber dem Auftraggeber ab. • Er prüft und verwaltet die Änderungsanträge. Letzteres betrifft insbesondere die Statusführung von Änderungsanträgen. • Er informiert den Projektleiter und weitere betroffene Personen über durchgeführte Änderungen. Antragssteller

Änderungsmanager

Änderungskontrollgremium

Experte

Entwickler

Tester

stellt Antrag Vorprüfung [optional] Prüfung Prüfung Benachrichtig. [Entscheidung ==Ablehnung]

[Entscheidung==Umsetzung] Umsetzung Verifikation [nicht korrekte Umsetzung]

Benachrichtig.

[korrekte Umsetzung]

Abb. 8.1. Arbeitsablauf zu Änderungsanträgen

Das Änderungskontrollgremium ist für die Entscheidung hinsichtlich der Behandlung von Änderungsanträgen verantwortlich. Es setzt sich je nach Größe des Projektes aus Vertretern verschiedener beteiligter Perso-

112

8 Anwendung von QSM in der Praxis

nengruppen zusammen. Typischerweise sind die folgenden Personengruppen involviert: • • • • • • • •

Vertreter des Auftraggebers Änderungsmanager Projektleiter Vertreter anderer Teilteams Software-Designer Software-Entwickler Qualitätsmanager Vertreter des Testteam

Die vier erstgenannten Personengruppen sind in erster Linie aus Kundensicht bzw. aus organisatorischen, planerischen und kaufmännischen Gesichtspunkten im Änderungskontrollgremium vertreten. Die weiteren Personengruppen beurteilen die Möglichkeiten und Konsequenzen der Umsetzung des Änderungsantrags, zum Beispiel hinsichtlich Aufwand und Qualität. Detailliert empfiehlt sich ein Ablauf, der sich in Antragsstellung, Vorprüfung, Prüfung durch ein Änderungskontrollgremium sowie eine Bearbeitung und Verifikation gliedert. Dieser Ablauf wird im folgenden genauer beschrieben. 1. Antragstellung. Der Antragsteller kann sowohl außerhalb des Projektteams stehen (z.B. ein Kunde, der neue Ideen hat) als auch ein Mitglied des Projektteams sein (z.B. ein Tester, der einen Fehler gefunden hat). Zunächst wird der Änderungsantrag erfasst, indem das zugehörige Formular ausgefüllt bzw. ein entsprechender Eintrag in der Änderungsdatenbank vorgenommen wird. Üblicherweise darf prinzipiell jedes Mitglied des Projektteams Einträge in dieser Datenbank vornehmen. Für außerhalb des Teams stehende Personen (z.B. Auftraggeber, Benutzer, andere Projektteilteams) ist der Änderungsmanager die erste Anlaufstelle für Änderungswünsche. Diese Kanalisierung der Änderungsanträge über eine eindeutige Schnittstelle des Teams nach außen ist wichtig, damit Änderungswünsche nicht „nebenbei“ implementiert werden, ohne dies zum Beispiel in der Projektplanung zu berücksichtigen oder ohne die sonst üblichen qualitätssichernden Maßnahmen durchzuführen. Dies dient auch dazu, häufige Störungen von außen vom Projektteam fernzuhalten und stattdessen die Änderungsanträge in Pakete gebündelt und gezielt einzuplanen. Der verantwortliche Verhandlungspartner behält den Gesamtüberblick über alle Änderungswünsche und steht für den Auftraggeber bei Fragen zur Verfügung.

8.1 Änderungsmanagement

113

Diese Kanalisierung auf Auftragnehmerseite bietet sich gegebenenfalls analog auch auf Auftraggeberseite an, d.h. es darf nicht notwendigerweise jede Person einen Änderungsantrag an den Auftragnehmer direkt übersenden, sondern er muss den Weg über seinen verantwortlichen Ansprechpartner im auftraggebenden Unternehmen nehmen. Vorteil dieser Kanalisierung ist, dass bereits der Änderungsmanager im auftraggebenden Unternehmen Fehler, die eigentlich gar keine Fehler sind (z. B. Fehlbedienungen des Systems durch den Benutzer), erkennen und zurückweisen kann. So ist sichergestellt, dass nur wirklich relevante Änderungsanträge an den Auftragnehmer herangetragen werden. 2. Vorprüfung. Nach Erfassen des Änderungsantrages führt der Änderungsmanager zunächst eine Vorprüfung bezüglich der Verständlichkeit und Vollständigkeit der Angaben des Änderungsantrags durch und ermittelt gegebenenfalls ergänzende Informationen. Weiterer Bestandteil der Vorprüfung ist die Bewertung des Änderungsantrags hinsichtlich seiner Redundanz. D.h. der Änderungsmanager geht der Frage nach, ob es einen inhaltlichen Zusammenhang mit älteren Änderungsanträgen gibt. Ist dies der Fall, so richtet sich das weitere Vorgehen nach der Art der inhaltlichen Überdeckung: • Ist der neue Änderungsantrag vollständig durch ältere erfasst, so ist er redundant und wird verworfen. • Wird der neue Änderungsantrag nur teilweise durch die älteren beschrieben, dann wird er so umformuliert, dass nur der noch nicht abgedeckte Bereich beschrieben wird. 3. Prüfung durch das Änderungskontrollgremium. Bei offensichtlichen Fehlern, die notwendigerweise auch zu beheben sind, plant der Änderungsmanager (gegebenenfalls zusammen mit dem Projektleiter) die Bearbeitung der Änderungsanträge in den weiteren Projektablauf ein. Aber nicht immer handelt es sich bei Änderungsanträgen um offensichtlich sofort durchzuführende Arbeiten (z.B. im Streitfall, ob der Änderungsantrag tatsächlich einen Fehler darstellt oder doch eine Funktionserweiterung, die getrennt zu bezahlen ist). Auch offensichtliche Fehler müssen nicht notwendigerweise sofort behoben werden. Aus Kosten-Nutzen-Gesichtspunkten oder aus der aktuellen Terminplanung heraus werden zum Beispiel niedrig priorisierte Fehler erst zu einem deutlich späteren Zeitpunkt behoben. Im Allgemeinen – und besonders in strittigen Fällen – ist daher das Änderungskontrollgremium für die Entscheidung hinsichtlich der Behandlung des Änderungsantrags verantwortlich. Das Änderungskontrollgremium bewertet den einzelnen Änderungsantrag hinsichtlich seiner Relevanz. Änderungsanträge werden als irrelevant eingestuft, wenn gar kein

114

8 Anwendung von QSM in der Praxis

Fehler vorliegt. Änderungsanträge, die als relevant erkannt wurden und keine Redundanz beinhalten, werden vom Änderungskontrollgremium hinsichtlich der folgenden Kriterien bewertet: • Bedeutung für den Erfolg des Systems • Bedeutung für den weiteren Verlauf der Entwicklung • Geschätzter Gesamtaufwand für die Realisierung, d.h. beispielsweise bei einem Fehler die Aufwände für o die Lokalisierung der Fehlerursache, o die Erarbeitung eines Lösungsvorschlages, o die Umsetzung des Lösungsvorschlages und o die Verifikation der Umsetzung. • Auswirkung der Realisierung auf den zeitlichen Verlauf des Gesamtprojektes • Finanzieller Nutzen Ist die Bedeutung des Änderungsantrages für den Erfolg des Produktes bzw. den weiteren Verlauf der Produktentwicklung gering und erscheint der geschätzte Aufwand im Verhältnis zum erwarteten Nutzen hingegen hoch, so kann der Änderungsantrag im Extremfall vom Änderungskontrollgremium auch verworfen werden. Ansonsten ordnet das Änderungskontrollgremium dem Änderungsantrag eine Priorität zu, deren Höhe von den oben genannten Kriterien abhängt. Eine hohe Priorität wird beispielsweise dann vergeben, wenn ein Änderungsantrag von großer Bedeutung für den Erfolg des Produktes und / oder die weitere Produktentwicklung ist und gleichzeitig nur einen verhältnismäßig geringen Realisierungsaufwand erfordert. 4. Bearbeitung und Verifikation. Nach der Vergabe der Priorität wird der Änderungsantrag, bei Annahme des Antrags, dem Projektteam zur Bearbeitung übertragen. Zum einen gibt es die Kategorie „Fehler“. In diesem Fall beginnt die Bearbeitung des Änderungsantrages zunächst mit einer Lokalisierungsphase. Diese kann mehr oder weniger lang sein in Abhängigkeit davon, wie tief der Fehler in der Software "versteckt" ist. Stellt sich hier heraus, dass der gemeldete Fehler nicht reproduzierbar ist, so wird der Änderungsantrag zur Entscheidung hinsichtlich seiner weiteren Behandlung an das Änderungskontrollgremium zurückverwiesen. Im Anschluss an die Lokalisierungsphase erfolgen die Erarbeitung eines Lösungsvorschlages sowie seine Umsetzung. Diese setzt in der Phase des Entwicklungsprozesses an, in der der Fehler entstanden ist. Die Bearbeitung des Änderungsantrags endet mit seiner Verifikation, d.h. mit erneuter Durchführung der Testfälle, wobei die ursprünglichen Testfälle zumindest um den gemeldeten Fehlerfall er-

8.1 Änderungsmanagement

115

weitert wurden. Schlägt die Verifikation fehl, so wird der Bearbeitungsprozess von neuem durchlaufen. Das Ende der Bearbeitung wird in der Liste der Änderungsanträge vermerkt. Der Änderungsmanager setzt dann den Initiator des Änderungsantrages vom Abschluss der Bearbeitung in Kenntnis. Zum anderen gibt es die Kategorie „Änderungswunsch“ oder „Funktionserweiterung“. Falls es sich bei dem zu bearbeitenden Änderungsantrag nicht um einen Fehler, sondern um eine neue oder eine zu ändernde Anforderung handelt, so überträgt der Bearbeiter den Änderungsantrag aus der Liste der Änderungsanträge in das Pflichtenheft und bearbeitet und verfolgt ihn wie eine "normale" Anforderung. Innerhalb der Liste der Änderungsanträge wird der Änderungsantrag als „Anforderungsänderung“ markiert und somit vom weiteren Vorgehen (wie eben skizziert) ausgeschlossen. Entsprechend den einzelnen Bearbeitungsschritten durchläuft der Änderungsantrag verschiedene Zustände. Diese werden wie folgt definiert (die Reihenfolge der Zustände spiegelt gleichzeitig auch die typische Reihenfolge wider, wie sie im Normalfall bei der Bearbeitung durchlaufen werden): • Übermittelt: In diesem Zustand befindet sich der Änderungsantrag unmittelbar nach der Antragstellung. • In Beobachtung: Der vom Melder angegebene Fehler ist nicht eindeutig reproduzierbar. Es wird beobachtet, ob der gleiche Fehler erneut auftritt. • In Entscheidung: Der Änderungsantrag wurde gesichtet, aber noch keine endgültige Entscheidung über die weitere Bearbeitung getroffen. Eventuell müssen weitere Experten konsultiert werden, um über die Machbarkeit, Kosten, Auswirkungen etc. des Änderungsantrags zu entscheiden. • In Arbeit: Der Änderungsantrag befindet sich beim zuständigen Bearbeiter und wird umgesetzt. • Terminiert: Der Änderungsantrag wurde endgültig abgelehnt. Gründe können beispielsweise sein: Duplikat, kein Fehler, nicht (mehr) beobachtbar, etc. • Verschoben: Es wurde zwar über den Änderungsantrag entschieden, aber er wird nicht sofort, sondern (z.B. aus Prioritätsgründen) erst zu einem späteren Zeitpunkt bearbeitet.

116

8 Anwendung von QSM in der Praxis

• Umgesetzt: Der Fehler wurde behoben oder der Wunsch umgesetzt. Der Änderungsantrag geht mit dem Übergang in diesen Zustand einem Tester zu. Dieser ist für die Überprüfung der Software oder des entsprechenden Dokumentes verantwortlich. • Validiert: Die korrekte und vollständige Umsetzung des Änderungsantrages wurde von einem Tester überprüft und bestätigt. Einführungsstrategie

Die Einführung des Änderungsmanagements umfasst • die Etablierung der angesprochenen Rollen (vor allem Änderungsmanager und Änderungskontrollgremium), • die Festlegung der konkreten Vorgehensweise, verbunden mit der Definition eines konkreten Zustandsmodells für Änderungsanträge (wie z.B. im vorangegangenen Kapitel beschrieben), • die Form von Änderungsanträgen, d.h. insbesondere auch, welche Attribute ein Änderungsantrag haben soll bzw. haben muss, • sowie die Auswahl eines konkreten Werkzeugs zur Unterstützung des Änderungsmanagements. Werkzeugunterstützung für das Änderungsmanagement gibt es in großer Auswahl und in allen Preisklassen. Sowohl freie wie auch kommerzielle Software ist verfügbar. In kleinen Projekten kann bereits eine Unterstützung durch MS EXCEL ausreichend sein, häufig sind in dieser Projektgröße auch MS ACCESS-Eigenimplementierungen anzutreffen. In etwas größeren Projekten oder auch in Projekten, an denen mehrere Vertragspartner teilnehmen, werden in der Regel kommerzielle Softwarelösungen bevorzugt oder sogar direkt durch den Auftraggeber vorgegeben. 8.1.3

Bewertung

Fachliche Bewertung

Beschlossene Änderungen müssen konsequent im Projekt umgesetzt werden. D.h. insbesondere, dass nicht nur der Quell-Code angepasst wird, sondern jede betroffene Dokumentation. Dies beginnt bei der Anforderungsspezifikation, geht weiter über die Designdokumentation und endet bei den Testspezifikationen, die im Bedarfsfall angepasst oder erweitert werden. Das Änderungsmanagement sorgt für eben diese konsequente Umsetzung und stellt damit die Produkt-Qualität bei der Durchführung von Änderungen sicher.

8.1 Änderungsmanagement

117

Wirtschaftliche Bewertung

Wirtschaftlich hat das Änderungsmanagement eine hohe Bedeutung, denn jede Änderung zieht zwangsläufig - zum Teil erhebliche - Kosten nach sich. Bei Festpreisprojekten ist es für die Projektabwicklung lebensnotwendig, dass diese bei der ursprünglichen Aufwandsschätzung nicht bekannten Aufwände auch tatsächlich dem Kunden in Rechnung gestellt werden können und die Änderungen nicht einfach „nebenher“ mit erledigt werden. Auch bei Aufwandsprojekten ist die Anwendung des Änderungsmanagements anzuraten, denn nur so kann dem Kunden transparent gemacht werden, wo und warum Aufwände entstanden sind. 8.1.4

Praktische Tipps

• Das Änderungsmanagement muss, wenn es Erfolg haben soll, konsequent angewendet werden. Das soll beispielsweise heißen, dass es keine kleinen oder großen Änderungswünsche gibt und somit alle formal gleich zu behandeln sind. Auch kleine Änderungswünsche kosten Zeit und damit Geld. • Das Änderungsmanagement sollte möglichst frühzeitig im Projekt angewendet werden und nicht erst, wenn gegen Projektende die Zeit oder die Kosten davonlaufen. • Änderungsmanagement ist prinzipiell für jedes freigegebene Dokument anzuwenden. • Alle Änderungswünsche sind vom Kunden freizugeben. • Die Umsetzung des Änderungsmanagements muss stets im Rahmen des Konfigurationsmanagements erfolgen, d.h. frühere Dokumentversionen müssen nachvollziehbar sein. • Die bei der Umsetzung von Änderungsanträgen durchgeführten Änderungen müssen über alle Dokumente hinweg konsistent umgesetzt sein. • In der Beschreibung des Änderungsantrages müssen möglichst exakte Angaben vorhanden sein. Diese beziehen sich u.a. auf den Systemzustand, die Umgebungsbedingungen, die Benutzerreaktionen, die Systemreaktionen (erwartete und tatsächliche) und die zu erwartenden Auswirkungen.

118

8 Anwendung von QSM in der Praxis

8.2

Anforderungsverfolgung

Die Anforderungsverfolgung ist Teil des Anforderungsmanagements, das der Erarbeitung von Anforderungen im Sinne der Anforderungsanalyse dient. Die Anforderungsverfolgung läuft durch die gesamten Entwicklungsphasen bis hin zum Nachweis der Umsetzung der Anforderungen in Abnahmetests. Die Anforderungsverfolgung wird während der Konzeption und Realisierung eines Projektes eingesetzt, um die Übereinstimmung des Soll- mit dem Ist-Zustand zu gewährleisten und somit die Kundenwünsche zu verwirklichen. Eine konsequente Anforderungsverfolgung ist Grundlage des Änderungsmanagements (siehe QSM in der Praxis: Änderungsmanagement). Idealerweise findet die Anforderungsverfolgung zentral statt, so dass alle beteiligten Personen Zugriff auf die aktuellen Anforderungen haben und die Entwicklung immer dem jeweils neuesten Stand angepasst werden kann. Dabei werden alle Anforderungen, auch mögliche zukünftige Anforderungen, gesammelt, so dass ein Anforderungspool entsteht. Die Hauptziele sind: • Konsequente Umsetzung aller Anforderungen bei der Entwicklung • Vermeidung von Inkonsistenzen und redundanten Anforderungsinformationen • Vermeidung hoher Kosten aufgrund von Redesign • Übereinstimmung von SOLL- und IST-Zustand • Grundlage für Änderungsmanagement schaffen 8.2.1

Einsatzumfeld

Das Unternehmen

Die ELAU Elektronik Automations AG ist ein mittelständisches Unternehmen der Automatisierungsbranche mit Sitz in Marktheidenfeld. ELAU produziert und vertreibt intelligente digitale Servoantriebe für Nahrungsmittel- und Verpackungsmaschinen. Im Unternehmen sind heute ca. 200 Mitarbeiter beschäftigt, deren Zahl kontinuierlich zunimmt. Die Entwicklungsabteilung beschäftigt ca. 30 Ingenieure der Elektrotechnik bzw. Informatik.

8.2 Anforderungsverfolgung

119

Einsatzumfeld der Maßnahme

Die Anforderungsverfolgung sollte generell bei jeglicher Entwicklung durchgeführt werden. Bei der Entwicklung ist es unabdingbar, eine funktionierende Anforderungsverfolgung zu gewährleisten. Sie ist Grundlage für alle folgenden Tests und für ein funktionierendes Änderungsmanagement. Bei mangelnder Umsetzung sind Kostenexplosion bzw. Nichteinhaltung von Terminen die Folge, aber auch mangelhafte Software, die nicht den Forderungen der Anwender entspricht. Die folgende Beschreibung soll unabhängig von der tatsächlichen Branche, den Mitarbeiterzahlen oder konkreten Projekten erfolgen. Wobei allerdings beachtet werden muss, dass es branchenspezifische Unterschiede gibt. Gerade im Bereich der Pharmaindustrie müssen strenge Richtlinien beachtet werden, wie z.B. die vom Good Automated Manufacturing Practices (GAMP) Forum in Form der Good Manufacturing Practices (GMP) formulierten Richtlinien für die Regulierung und Nutzung von Computern und Kontrollsystemen. Eine besondere Zusatzqualifikation der Mitarbeiter ist nicht notwendig. Es ist lediglich darauf zu achten, die zur Unterstützung der Anforderungsverfolgung verwendeten Tools sorgfältig auszuwählen, damit die Anforderungsverfolgung auch auf die eigenen Bedürfnisse abgestimmt werden kann. In diesem Beitrag wird näher auf das Produkt PVCS® Tracker™ der Firma Merant GmbH eingegangen, da die ELAU AG dieses Tool verwendet. Dadurch sollen beispielhaft die benötigten Funktionen bei der Anforderungsverfolgung im Softwareentwicklungsbereich illustriert werden. 8.2.2

Vorgehensweise

Motivation für den Einsatz

Die Anforderungsverfolgung als Teilstück des Anforderungsmanagements gehört zu den grundlegenden Voraussetzungen eines funktionierenden Qualitätsmanagements. Ohne eine klar strukturierte, umfassende und vollständige Anforderungsverfolgung ist es nicht möglich, die Software so zu entwickeln, dass sie den Forderungen der Anwender entspricht. Zukünftige Änderungen in der Software, das heißt ein vernünftiges Konfigurationsbzw. Versionsmanagement würden erschwert. Bei Software, wie sie bei ELAU im Bereich der Steuerungs- und Antriebstechnik eingesetzt wird, kann eine nicht funktionierende Anforderungsverfolgung nicht nur mangelnde Qualität zur Folge haben, sondern birgt auch immense Sicherheitsrisiken in sich, da kritische Fehlerbereiche nicht mehr eindeutig zugeord-

120

8 Anwendung von QSM in der Praxis

net werden können. Die Anforderungsverfolgung ist daher unverzichtbar für eine risikoarme und damit erfolgreiche Entwicklung der Produkte. Anwendung

Die Anforderungsverfolgung zieht sich durch den gesamten Entwicklungsprozess. Sie ist Teil des Anforderungsmanagements und Grundlage eines erfolgreichen Änderungs- bzw. Konfigurationsmanagements. Durch die zentrale Sammlung der einzelnen Anforderungen entsteht eine sehr nützliche Basis für effektive Softwareentwicklung. Der Arbeitsablauf bei der Anforderungsverfolgung ist untrennbar mit der Anforderungsanalyse und dem darauf folgenden Änderungsmanagement verwoben. Man kann die Anforderungsverfolgung grob in die Schritte Vorarbeit, Umsetzung und Nachbereitung einteilen, die im Folgenden genauer beschrieben werden. 1. Vorarbeit. Die Vorarbeit beinhaltet die Sammlung, Bewertung und Planung der Anforderungen für das konkrete Projekt. Nach der Analyse der einzelnen Anforderungen besteht eine Sammlung von konkreten Anforderungen an das zu entwickelnde System. Diese Anforderungen leiten sich aus den Anforderungen und Wünschen der Anwender sowie aus den zusätzlich gegebenen Anforderungen wie Standards, Beschaffenheit der Hardware-Komponenten, gesetzliche Rahmenbedingungen etc. ab. Man erhält also funktionale und nicht funktionale (Qualitäts-, Sicherheits-, Leistungs-) Anforderungen. Diese müssen nun im ersten Schritt den einzelnen Produkten bzw. Modulen bzw. Komponenten des zu entwickelnden Systems zugeordnet werden. Die konkrete Fragestellung lautet hier: An was wird welche Forderung gestellt? Im zweiten Schritt muss nun der Anforderungsmanager die Anforderungen bewerten. Zunächst muss also entschieden werden, ob eine Anforderung überhaupt umsetzbar ist. Dies geschieht in Rücksprache mit den Entwicklern. Dabei erfolgt auch eine erste Ressourcenplanung. Die Aufwandsabschätzung und gegebenenfalls eine Voruntersuchung mit Feinspezifikation entstehen im Dialog zwischen Entwicklern und Anforderungsmanager. Dann teilt der Anforderungsmanager den Anforderungen Prioritäten zu. Er entscheidet über deren Dringlichkeit. Dies geschieht auch in Rücksprache mit Auftraggebern (z.B. der Applikationsabteilung oder den Kunden). Zuletzt wird dann die Verantwortlichkeit einem Entwickler zugeteilt, der für die tatsächliche Umsetzung der Anforderung verantwortlich ist. Hier ist auch zu berücksichtigen, dass der Anforderungsmanager ein erfahrenes Mitglied des Entwicklungsteams sein sollte. Er muss fähig sein, den Überblick über die Anforderungen zu behalten und gleichzeitig auch

8.2 Anforderungsverfolgung

121

deren Durchsetzung fordern können. Deshalb ist es sehr wichtig, dass der Anforderungsmanager eine sehr gute Übersicht über alle Komponenten des Systems und deren Zusammenspiel hat. Er ist verantwortlich für die Entwicklung eines Gesamtplans, das heißt die Änderungswünsche (system change requests, kurz SCR) müssen zugeordnet, Zieltermine müssen beachtet und Ressourcen müssen eingeteilt werden. 2. Umsetzung der Anforderungsverfolgung. Bei der folgenden Entwicklungsarbeit ist die permanente Berücksichtigung der notwendigen Anforderungsverfolgung entscheidend. Während der Entwicklung entstehen einerseits neue Anforderungen oder alte Anforderungen müssen verändert werden, der Entwickler muss diese Vorgänge erfassen und den Zustand der zu bearbeitenden Anforderung dokumentieren. Gleichzeitig muss der Anforderungsmanager den Stand der einzelnen Anforderungen immer wieder prüfen. Hier ist die Wahl des Tools, mit dem die Anforderungsverfolgung verwaltet wird, entscheidend. Eine zentrale Datenbank (beispielsweise mit SQL-Server) ist sehr gut geeignet, da so die Konsistenz und Einheitlichkeit der eingetragenen Daten gewährleistet ist. Das verwendete Tool sollte aber auch Funktionen wie die Konfiguration von Eingabemasken bei SCR, eine vorgefilterte Suchoption, einfache Erstellung von Statusberichten und Rückverfolgbarkeit von Verantwortlichkeiten bieten. Bei ELAU wird das Produkt PVCS® Tracker™ der Firma Merant eingesetzt, dessen Funktionen für die Anforderungsverfolgung besonders geeignet sind (Abb. 8.2). Es ist ratsam, immer wieder Rücksprache mit den Kunden bzw. Anwendern zu halten, um sie vom Stand der Entwicklung in Kenntnis zu setzen und um sicher zu gehen, dass man sich im Laufe der Entwicklung nicht (zu weit) vom Soll-Zustand entfernt. Generell sollte der Anforderungsmanager auch immer in der Lage sein, den Kunden sofort darüber zu informieren, welchen Status dessen Anforderung hat. Das „Leben“ einer Anforderung muss bei jedem Entwicklungsschritt sowohl vorwärts als auch rückwärts verfolgbar sein. In der Datenbank muss der Status der Entwicklung festgehalten werden (z.B.: realisiert, abgeschlossen, im Test, verschoben, etc). Gleichzeitig ist es wichtig, die Verfolgbarkeit einer einzelnen Anforderung herzustellen. Jeder, der Zugriff auf die Datenbank hat, muss in der Lage sein zu erkennen, welche Abhängigkeiten entlang des Projektverlaufs von einer Anforderung ausgehen (z.B. Detailanforderungen, Designbeschreibungen, Codemodule, Testpläne, Projektaktivitäten) und welche Verbindungen zwischen Anforderungen und Projektplänen und Arbeitsprodukten bestehen. Hier ist insbesondere auch ein korrektes Versionsmanagement zu beachten. Anforderungen und Abhängigkeiten sind meist quer durch mehrere Versionen und / oder Varianten einer Softwarelösung vorhanden.

122

8 Anwendung von QSM in der Praxis

Abb. 8.2. Oberfläche zum Eintragen, Bearbeiten und Verwalten eines SCR

Insbesondere in Zusammenhang mit einem effektiven Änderungsmanagement ist es besonders wichtig, dass die Abhängigkeiten zwischen Versionen bzw. Varianten eines Softwareprodukts transparent und gut nachvollziehbar sind. Nur so können Anforderungen auch vollständig umgesetzt werden. Dabei ist es entscheidend, auf eine durchgängige Verifikation der Anforderungen zu achten. Hauptsächlich der Entwickler, aber auch der Anforderungsmanager ist dafür verantwortlich, dass eine Überprüfung, ob die Anforderungen vollständig umgesetzt wurden, stattfindet und dieser Status auch in der Datenbank dokumentiert wird. 3. Nachbereitung. Beim Abschluss einer Entwicklungsphase müssen nochmals alle Ergebnisdokumente hinsichtlich der vollständigen Berücksichtigung der Anforderungen überprüft werden. Es ist insbesondere sehr wichtig, dass klar ist, wer der Verantwortliche für den einzelnen SCR ist. Im PVCS Tracker ist das Problem so gelöst, dass wirklich nur die Person, die für die spezielle Anforderung verantwortlich ist, diese auch schließen darf. Dabei muss der Verantwortliche identifizieren können, welche Teile des Ergebnisses welche Anforderungen erfüllen, das heißt beispielsweise

8.2 Anforderungsverfolgung

123

wo im Programmcode eine Anforderung umgesetzt ist und von wem. Es folgen Black-Box- und White-Box-Tests, deren Grundlage die Datenbank mit den einzelnen Anforderungen an das zu testende Produkt ist. Schließlich wird der Antragssteller auch darüber informiert, inwieweit seine Anforderungen erfüllt wurden. Der Vergleich zwischen Ist-Zustand und gefordertem Soll-Zustand sollte nach erfolgreicher Durchführung einer konsequenten Anforderungsverfolgung zu einem zufrieden stellenden Ergebnis führen. Dieser Vergleich wird mit Hilfe der Datenbank durchgeführt, die auch die Dokumentationserstellung unterstützt. Einführungsstrategie

Besonders zu berücksichtigen ist die Wahl des Tools, das zur Unterstützung der Anforderungsverfolgung im Unternehmen eingesetzt wird. In der Regel muss eine umfangreiche Datenbank, besonders bei der Entwicklung langlebiger Produkte, aufgebaut und gepflegt werden. Hier sind auch technische und organisatorische Faktoren zu beachten, wie zum Beispiel das Einrichten eines Servers, auf den von allen an der Entwicklung Beteiligten zugegriffen werden kann. Außerdem ist bei den Mitarbeitern ein Bewusstsein für die Bedeutung einer funktionierenden Anforderungsverfolgung zu schaffen. Die Mitarbeiter, das heißt die Entwickler, sind letztlich für die vollständige Dokumentation und die Einhaltung der Richtlinien selbst verantwortlich und werden sie nur dann konsequent umsetzen, wenn ihnen die Bedeutung und die Vorteile der korrekten Anforderungsverfolgung auch für ihren Bereich klar sind. Hier muss die Projektleitung und das Management durch Überzeugung und klare Unterstützung der Maßnahmen ein deutliches Vorbild sein. 8.2.3

Bewertung

Fachliche Bewertung

Fachlich gesehen gehört die Anforderungsverfolgung zu jedem professionell durchgeführten Entwicklungsverfahren. Es ist hervorzuheben, dass eine konsequent umgesetzte, wohl durchdachte Anforderungsverfolgung die Effektivität der Softwareentwicklung, der Fehlerbehebung und der Softwarequalität enorm steigert. Softwareentwicklung ist ein dynamischer Prozess. Mit Hilfe der Anforderungsverfolgung wird dieser Prozess dokumentiert und damit sichtbar gemacht. Die Anforderungsdatenbank ist auch für zukünftige Entwicklungen nutzbar, Vergleiche sind möglich und der angestrebte Soll- Zustand wird häufiger und schneller erreicht.

124

8 Anwendung von QSM in der Praxis

Wirtschaftliche Bewertung

Ohne Anforderungsverfolgung ist eine effiziente und damit wirtschaftliche Entwicklung hochkomplexer Software, wie dies z.B. im Automatisierungsbereich der Fall ist, unmöglich. Um Kostenexplosionen, Terminüberschreitungen und ein ineffektives Änderungs- oder Konfigurationsmanagement zu vermeiden, ist die Anforderungsverfolgung unverzichtbar. Die Frage, ob man Anforderungsverfolgung durchführt oder nicht, stellt sich also gar nicht. Man sollte lediglich auf die eigenen Erwartungen und Gegebenheiten Rücksicht nehmen. Beispielsweise braucht eine Firma, die wenig bzw. gar keine verschiedenen Versionen einer Software erstellt, kein kompliziertes Datenbanksystem, mit dem man Versionsmanagement betreiben kann. Dies wäre unrentabel und damit wirtschaftlich gesehen eine Verschwendung von Ressourcen. 8.2.4

Praktische Tipps

Folgende Punkte sind bei der Einführung und Anwendung der QSM zu beachten: • Sorgfältige Auswahl des Tools zur Anforderungsverfolgung • Motivation der Mitarbeiter • Konsequente durchgängige Umsetzung • Vorsichtige Auswahl des Anforderungsmanagers (Erfahrung, kommunikative Fähigkeiten,...) • Auf direkten Kontakt mit dem Anforderungssteller achten (Vergleich zwischen Soll- und Ist-Zustand) • Bemühung um kundenorientierte Sichtweise

8.3 Defect Management

8.3

125

Defect Management

Das Defect Management befasst sich mit der Erfassung, Bearbeitung und Beseitigung von Produktfehlern. Innerhalb des Defect Managements wir im Rahmen der Mängelbeseitigung das Änderungsmanagement aktiviert, welches an anderer Stelle beschrieben wird. Für die sichere Erfassung und Meldung von systematischen Mängeln an Produkten und Dienstleistungen hat die Lenze AG das Mängelreportsystem geschaffen, das zur Bearbeitung von erkannten Produkt- und Prozessproblemen bei Kunden durch den Vertriebsaußendienst genutzt wird. Zur elektronischen Bearbeitung wurde eine eigene E-Mail-Adresse eingerichtet. Jeder Absender erhält eine Rückinformation über den Bearbeitungsstand. Innerhalb der Elektronikentwicklung wird ein gesondertes Defect Management betrieben. Dabei ist der Kern des Defect Managements eine Mängeldatenbank, in der alle Mängel eingetragen werden, die an den von der Elektronikentwicklung konstruierten Geräten auftreten. Die Mängel (Hardware, Software, Dokumentation) werden in der Mängeldatenbank dauerhaft gespeichert und verwaltet. 8.3.1

Einsatzumfeld

Das Unternehmen

Die Firma Lenze AG ist ein mittelständisches Unternehmen der Antriebstechnik- und Automatisierungsbranche mit Hauptsitz in Groß Berkel und Bösingfeld. Zum Produktumfang der Lenze AG gehören Frequenzumrichter, Servoumrichter, Hardware und Softwarekomponenten zur dezentralen Automation, Getriebemotoren, Drehstrommotoren, Bremsen und Kupplungen. Die Lenze AG beschäftigt weltweit 3000 Mitarbeiter, davon 1960 Mitarbeiter im Inland. Im Bereich der Entwicklungsabteilung der Lenze Drive Systems GmbH sind 149 Mitarbeiter tätig, davon ca. 50 Mitarbeiter im Softwarebereich tätig. Einsatzumfeld der Maßnahme

Defect Management findet in vielen Bereichen der Lenze AG statt. In der Elektronikentwicklung wird Defect Management in den Entwicklungsklassen Produktentwicklung (intern und Kundenauftrag), Variantenentwicklung (intern und Kundenauftrag) und Anpassentwicklung durchgeführt.

126

8 Anwendung von QSM in der Praxis

Jede funktionale oder bauliche Abweichung eines Produktes von der Spezifikation wird als Mangel in eine Mängeldatenbank eingetragen. 8.3.2

Vorgehensweise

Motivation für den Einsatz

Mängel können trotz hoher Qualitätsstandards in jeder Phase der Produktentstehung und des Produktlebenszyklus auftreten. Dabei wirken sich Mängel immer störend und negativ auf den Erfolg eines Produktes und damit auch auf den Erfolg des Unternehmens aus. Jeder Mangel kostet das Unternehmen bares Geld. Infolge der Produkthaftpflicht kann ein Unternehmen einen großen wirtschaftlichen Schaden erleiden. Deshalb ist es unbedingt notwendig, Mängel sicher und schnell zu erfassen und entsprechende Maßnahmen einzuleiten. Zu diesem Zweck wurde das Mängelreportsystem eingeführt. Anwendung

Das Defect Management wird bei der nachfolgenden Beschreibung in die Abschnitte Mängelerfassung, Mängelbearbeitung und Mängelbeseitigung aufgeteilt. 1. Mängelerfassung. Jeder Mitarbeiter ist für die Erfassung und Informationsweitergabe erkannter Mängel und unerfüllter Kundenforderungen verantwortlich. Mängel, die außerhalb des Stammhauses auftreten, werden über das Mängelreportsystem als Mängelreport mitgeteilt. Dabei werden die Informationen über erkannte Mängel oder Abweichungen von Kundenforderungen über zwei definierte Informationskanäle erfasst: • Eingang über e-Mail • Eingang über FAX Zur einfacheren Bearbeitung wird auf dem Intranet eine Dokumentenvorlage zur Verfügung gestellt. Eingehende Informationen werden sofort nach Eingang, spätestens jedoch innerhalb eines Arbeitstages identifiziert und zur weiteren Bearbeitung an die verantwortliche Stelle in der Organisation weitergeleitet. Das Qualitätswesen ist zuständig für die Identifikation und Lenkung des Mängelreports und leitet diese bei eindeutiger Sachlage und Verantwortlichkeit zur Bearbeitung weiter. Sofern Priorisierung, Zuständigkeit oder Verursacher nicht eindeutig sind, wird durch benannte Mitarbeiter aus den Bereichen Vertrieb, Service,

8.3 Defect Management

127

Entwicklung und Qualitätswesen die weitere Vorgehensweise entschieden und die Bearbeitung eingeleitet. Mängel, die in der Entwicklungsabteilung auftreten, werden direkt in die Mängeldatenbank eingetragen und bekommen den Anfangsstatus „Erfasst“. Die Mängeleingabe erfolgt von dem Mitarbeiter, der den Mangel entdeckt. Besitzt der Mitarbeiter keine Berechtigung für die Mängeldatenbank, dann wendet er sich an einen der benannten Betreuer. Der Mangel wird an den Betreuer per E-Mail weitergeleitet und der Betreuer übernimmt die Mängeleingabe. Eine Mitteilung über den neu entdeckten Mangel wird dem Koordinator und falls bekannt direkt dem Bearbeiter per E-Mail zugesandt. Ist der Bearbeiter nicht bekannt, dann leitet der Koordinator den Mangel zum Bearbeiter. 2. Mängelbearbeitung. In Abhängigkeit der Priorisierung erfolgt die weitere Bearbeitung des Mängelreports. Das Entscheidungsspektrum umfasst Sofortmaßnahmen in Form von Sperrungen, Sofortmaßnahmen beim Anwender, Einleitung von weiteren Untersuchungen oder die Aufnahme in die Mängeldatenbanken zur Berücksichtigung von Korrektur- und Verbesserungsmaßnahmen bei Serienüberarbeitungen oder Neuentwicklungen. Der Informant erhält eine Rückmeldung über den Entscheid und den Status der Bearbeitung des Vorganges. Je nach Art der Mängelbearbeitung (Sofortmaßnahme oder kontinuierliche Verbesserungsmaßnahme) treten vier Personenkreise in den Vordergrund: Projektleiter, Koordinator, Sperrkreis und Q-Zirkel. Zur Bestimmung der Sofortmaßnahmen trifft der Sperrkreis zusammen, an dem u. a. auch der Projektleiter beteiligt ist. Der Projektleiter ist außerdem der Koordinator innerhalb der Mängeldatenbank und delegiert die Mängel zur Bearbeitung, die sein Projekt betreffen. Im Rahmen des kontinuierlichen Verbesserungsprozesses tritt regelmäßig der Q-Zirkel zusammen, der über die weitere Bearbeitung von Mängeln bestimmt, deren Ursache noch ungeklärt oder nicht auf einen Prozess begrenzt ist.

128

8 Anwendung von QSM in der Praxis

Zur weiteren Bearbeitung und Analyse von Schwerpunkten sind in Tabelle 8.1 vier Informationseinheiten definiert. Tabelle 8.1. Informationseinheiten zur Beschreibung von Mängeln Informationseinheit

Intention

Kundendaten

Ansprechpartner bei Rückfragen Identifikation der Branche Erkennung von branchenspezifischen Schwerpunkten Genaue Zuordnung des Mangels Erkennung von Häufungen bei Produktgruppen Hard- / Softwareausführungen Zur weiteren Bearbeitung des Mangels ist eine möglichst exakte Beschreibung des Mangels und der Randbedingungen erforderlich, z.B. bei Elektronik: - Umgebungstemperatur - Schaltsequenzen (Ein- und Ausschalten) - Verdrahtung (EMV- Einflüsse) - Mitwirkende Komponenten - Reproduzierbarkeit - Vermutete Fehlerursache (z. B. bei Motoren / Getriebe) Sofortige Reaktion notwendig; Akutes Problem, d.h. Mangel hat direkten Einfluss auf die Anwendung: - Maschinenstillstand - Unterbrechung der Inbetriebnahme Reaktion innerhalb von 1 Woche: - Hilfestellungen bei Akquisitionen Bearbeitung des Mängelreports ist nicht zeitkritisch: - Hinweise zur Produktverbesserung - Hinweise zur Dokumentation

Produktgruppe / Produktinformation

Fehlerart / Fehlerbeschreibung

Bewertung der Dringlichkeit

Mängelbeseitigung. Die Einleitung von Korrekturmaßnahmen sieht die systematische Beseitigung von Fehlerursachen vor und soll ein erneutes Wiederauftreten verhindern. Die Systematik von Korrekturen wird mit den zwei unterschiedlichen Intentionen „Ad-hoc-Korrekturmaßnahmen“ und „Kontinuierliche Verbesserung“ verwendet:

8.3 Defect Management

129

Ad-hoc-Korrekturmaßnahmen. Zur Beseitigung von Prozessstörgrößen oder systematischen Produktfehlern mit Konsequenzen für den Anwender werden Ad-hoc-Korrekturmaßnahmen eingeleitet. Diese Vorgehensweise berücksichtigt neben kurzfristigen Maßnahmen wie Reparatur, Fehlerbehebung und Beseitigung der Ursachen auch die Aktivitäten zur Schadensbegrenzung. Bei der Erkennung von Fehlern und Fehlerursachen kann ein Sperrkreis einberufen werden. Aufgabe des Sperrkreises ist es, die Sachlage und die Eskalationsstufe zu bewerten. Danach initiiert und koordiniert er die Bearbeitung der Produkt- und Prozessfehler und die Beseitigung der Fehlerursache. Je nach Sachlage wird ein sofortiger Auslieferungsstopp verfügt. Der Sperrkreis setzt sich aus geschulten Vertretern der Bereiche Entwicklung, Vertrieb, Produktion, Beschaffung, Logistik, Service, Produktmanagement und Qualitätswesen zusammen. Bis zur Eskalationsstufe 3 (Tabelle 8.2) besteht der Sperrkreis, sofern keine Risiken für andere Prozesse der Organisation oder den Kunden bestehen, nur aus den betroffenen Bereichen. Sofern Risiken bestehen, dass der Anwendungsbereich betroffen ist, sind die Bereichsverantwortlichen in den Entscheidungsprozeß einzubeziehen. Bei der Bewertung der Sachlage ist zu berücksichtigen, welcher Prozess / welche Produktgruppe betroffen ist. Das Fehlersymptom muss genau beschrieben werden. Danach wird die Eskalationsstufe festgestellt. Davon abhängig wird über Sofortmaßnahmen zur Schadensbegrenzung entschieden (z.B. Materialrückgabe, Fertigungsstopp und Auslieferungsstopp). Tabelle 8.2. Eskalaltionsstufen Eskalation

Materialfluss

Stufe 1 Stufe 2 Stufe 3 Stufe 4 Stufe 5 Stufe 6 Stufe 7

Wareneingang Materiallager/Bereitstellung Produktion Verarbeitung Produktion Produktlager/Versandlager externe Produktlager Kundenlager Anwendung

Kontinuierliche Verbesserung. In Prozessen tritt in der Regel mehr als eine Fehlerursache auf, so dass Korrekturmaßnahmen mehrmals (kontinuierlich) durchlaufen werden. Im Managementsystem wird dieses Prinzip als kontinuierlicher Verbesserungsprozeß (KVP) bezeichnet. Der KVP findet Anwendung bei der Verfolgung der Unternehmensziele.

130

8 Anwendung von QSM in der Praxis

Qualitätszirkel sind regelmäßig durchgeführte und zielgerichtet moderierte Gesprächsrunden. Die Zusammenstellung erfolgt prozessorientiert, d.h. bei Bedarf werden Mitarbeiter aus anderen Prozessen in die Zirkelarbeit mit eingebunden. Innerhalb der Qualitätszirkel werden Abweichungen und deren Ursachen bewertet, Lösungsvorschläge erarbeitet und konkrete Maßnahmen beschlossen. Die einzelnen Arbeitspakete werden im Protokoll eindeutig identifiziert und bis zur erfolgreichen Umsetzung dokumentiert. Jedem Arbeitspaket werden ein verantwortlicher Bearbeiter sowie der Zeitrahmen zugeordnet. Für die Geschäftsprozesse sowie die Begleitprozesse Entwicklung, Produktion und Beschaffung sind ständige Qualitätszirkel etabliert. Als ein Ergebnis des Managementreviews werden bei Bedarf KVP Projekte durch die Geschäftsführung oder den Managementbeauftragten initiiert. Über die Ergebnisse besteht Berichtspflicht. Mängelabschluss. Nach der Mängelbeseitigung wird dem Verfasser des Mängelreports eine Information über das Ergebnis der Mängelbearbeitung mitgeteilt. In der Mängeldatenbank bekommt der Mangel einen entsprechenden Status. Ein aktueller Mangelstatus ist sehr wichtig, um bei einer Auswertung der Mängeldatenbank den aktuellen Fehlerstand vorliegen zu haben. Einführungsstrategie

Es muss von der Mängelerfassung bis zur Mängelbeseitigung ein durchgängiger Prozess entwickelt werden. Dazu muss ein sicheres Meldesystem geschaffen werden, bei dem keine Mängel verloren gehen. Ein geschultes Gremium muss benannt werden, das eine Bewertung der Mängel vornehmen und entscheiden kann, welche Maßnahmen getroffen werden müssen. Die Mängel müssen in eine zentrale Datenbank eingegeben und dort verwaltet werden und einen Bearbeitungsstatus bekommen. Bei einer Produktüberarbeitung muss die Datenbank ausgewertet werden. 8.3.3

Bewertung

Fachliche Bewertung

Die Notwendigkeit eines funktionierenden Defect Managements steht außer Frage. Ein gutes Defect Management sorgt dafür, auch im Fehlerfall ein kompetentes Qualitätsbewusstsein sicherzustellen und zu repräsentieren. Mit dem Defect Management besitzt man ein Qualitätswerkzeug, durch das man in die Lage versetzt wird, keinen Fehler doppelt zu machen.

8.3 Defect Management

131

Wirtschaftliche Bewertung

Die Investition in das Defect Management ist eine gewinnbringende Investition. Der nachlässige Umgang mit Fehlern oder eine falsch eingeleitete Maßnahme können die Fehlerkosten schnell in die Höhe treiben und dem Image schadigen. Dadurch verloren gegangenes Vertrauen wieder aufzubauen ist kostenintensiver als die Investition in das Defect Management. 8.3.4

Praktische Tipps

Wichtig bei dieser Maßnahme ist es, jeden Mangel in einer Datenbank festzuhalten und die Mängeldatenbank ständig zu aktualisieren.

132

8 Anwendung von QSM in der Praxis

8.4

Fehler-Möglichkeits- und Einflussanalyse (FMEA)

Die FMEA gehört zu den Methoden der konstruktiven und somit präventiven Qualitätssicherung. Durch ein weitgehend formalisiertes, methodisches Vorgehen werden mögliche Fehler erfasst, und die damit verbundenen Risiken abgeschätzt. Die FMEA wird in der Entwurfsphase neuer Systeme eingesetzt, um möglichst frühzeitig potentielle Schwachstellen und Risiken aufzudecken, so dass kritische Ausfälle durch geeignete Änderungsmaßnahmen vermieden werden können. Die FMEA ist ein Teilbereich bzw. eine besondere Ausprägung des Risikomanagements bzw. der Risikoanalyse. Die FMEA untergliedert sich in System-, Konstruktions- und Prozessanalyse, wobei in jedem Teilbereich eine Problemanalyse mit einer Risikoanalyse gekoppelt wird. Die Darstellung einer FMEA geschieht mit Hilfe von vorgefertigten Formblättern oder Matrizen. Dabei arbeiten die Bereiche Entwicklung / Konstruktion, Fertigungsplanung, Qualität, Einkauf und Vertrieb zusammen. Hauptziele der FMEA sind: • frühzeitige Erkennung eines Fehlers und seiner möglichen Auswirkungen • kontinuierliche Verbesserung • Risikoverminderung bzw. -vermeidung • Dokumentation des Prozesses 8.4.1

Einsatzumfeld

Das Unternehmen

Die ELAU Elektronik Automations AG ist ein mittelständisches Unternehmen der Automatisierungsbranche mit Sitz in Marktheidenfeld. ELAU produziert und vertreibt intelligente digitale Servoantriebe für Nahrungsmittel- und Verpackungsmaschinen. Im Unternehmen sind heute ca. 200 Mitarbeiter beschäftigt, deren Zahl kontinuierlich zunimmt. Die Entwicklungsabteilung beschäftigt ca. 30 Ingenieure der Elektrotechnik bzw. Informatik. Einsatzumfeld der Maßnahme

Grundsätzlich kann eine FMEA in jedem Unternehmen durchgeführt werden, allerdings ist der Einsatz der Methode eingeschränkt auf Projekte mit besonderen Sicherheitsrisiken oder hohen funktionalen Anforderungen,

8.4 Fehler-Möglichkeits- und Einflussanalyse (FMEA)

133

wie dies in der Softwareentwicklung von eingebetteten Systemen der Fall ist. Eine generelle Anwendung der Methode FMEA wäre gemessen an dem zu investierenden Aufwand und den erreichbaren Ergebnissen nicht adäquat. Die FMEA ist aber unabhängig von der Branche oder den Mitarbeiterzahlen. Deswegen wird diese Qualitätssicherungsmaßnahme unabhängig vom konkreten Anwendungsunternehmen beschrieben. Seit Mitte der 80er Jahre gehört die FMEA zu den wichtigsten Methoden der konstruktiven Qualitätssicherung, wobei bei der Anwendung die Effektivität der Fehlervermeidung oft noch unzureichend war. Inzwischen wurde aufgrund jahrelanger Erfahrung die Matrix-FMEA entwickelt, die ein effizientes und zielgerichtetes Vorgehen ermöglicht. Durch Vermeidung von Wiederholungen und Erhöhung der Verknüpfungen können durch die Matrix-FMEA wirksame und nachvollziehbare Methoden gefunden werden, die die Fertigung qualitativ hochwertigerer Produkte und damit geringere Kosten und zufriedenere Kunden gewährleisten. Zusätzlich erlaubt die Matrix-FMEA eine wesentlich schnellere Durchführung und damit auch aufgrund ihrer Wirksamkeit eine deutlich höhere Akzeptanz und Motivation der Mitarbeiter. Eine FMEA-Arbeitsgruppe besteht aus ca. 5-6 Personen aus verschiedenen Bereichen des Unternehmens. Besondere Anforderungen bestehen darin, dass die Teammitglieder die Systematik der FMEA kennen sollten, um schnell arbeiten zu können. Der Moderator eines Teams muss geschult sein, da er für die Effektivität seines Teams und die erfolgreiche Abwicklung der FMEA verantwortlich ist. Auf die Rolle des Moderators wird bei der Beschreibung der Vorgehensweise im folgenden Kapitel genauer eingegangen. 8.4.2

Vorgehensweise

Motivation für den Einsatz

Die Matrix-FMEA eignet sich insbesondere zum Test des Zusammenspiels zwischen komplexer Software und Hardware (z.B. bei Servoantrieben, wie sie von der ELAU AG entwickelt werden). Kritische Fehlerzustände müssen hier sehr früh erkannt werden, besonders wenn sie zu einer Gefährdung von Mensch und Maschine führen können. Beispielsweise können Fehler im Sensorsystem eines Servoantriebs enorme Auswirkungen haben. Das sichere Abschalten muss gewährleistet sein, da Servoantriebe in Verpackungsmaschinen auch sicherheitskritische Funktionen haben (Antrieb von Schneidwerkzeugen etc.). Eine präventive Maßnahme wie die MatrixFMEA, die eine eindeutige Priorisierung vornimmt, bietet sich bei der

134

8 Anwendung von QSM in der Praxis

Erkennung und Behebung solcher kritischen Fehlerbereiche an und erlaubt eine systematische Überprüfung aller sicherheitskritischen Betriebszustände des Antriebssystems. Anwendung

In einem Multi-Matrix-System, also einer Matrix mit in den Matrixelementen integrierten weiteren Matrizen, werden alle relevanten Elemente verknüpft (Abb. 8.3). Das Ziel ist, die FMEA in Form einer einfachen, kompakten und übersichtlichen Dokumentation durchzuführen. Durch die Verwendung des Matrix-Systems wird die Vernetzung der Zusammenhänge aller möglichen Fehler und Maßnahmen möglich. Priorisierungsfeld B

Liste "B"

A

1

2

3

4

5

6

7

8

9

1 2 3 4

Liste "A"

Verknüpfungsfeld

5 6 7 8

Abb. 8.3. Matrixdarstellung4

Der Arbeitsablauf bei der Durchführung der kompletten Matrix-FMEA gliedert sich grob in die im Folgenden näher behandelten Einzelschritte: Bestimmung von Arbeitsgruppen (für System- (SY), Konstruktions- (KO)

4

Die Matrix setzt sich zusammen aus dem Achsenkreuz, den Listen und Achsen sowie dem Verknüpfungsfeld. Es erfolgt eine Unterteilung in eine Nummerierungsspalte, eine Textspalte und eine Bewertungsspalte, die man für die Priorisierungsoperationen verwendet. In der Abbildung sieht man eine Matrix, die sozusagen eine „Zelle“ der Gesamtmatrix bildet. Diese setzt sich dann aus vielen solchen Einzelzellen zusammen, so dass ein hoher Verknüpfungsgrad erreicht wird (Multi-Matrix-System).

8.4 Fehler-Möglichkeits- und Einflussanalyse (FMEA)

135

und Prozess- (PR) FMEA), Funktionsanalyse, Risikoanalyse und Risikominimierung. Bestimmung von Arbeitsgruppen. Die Arbeitsgruppen bestehen idealerweise aus ca. 5-6 Personen, die aus den verschiedenen, an der Produktentwicklung bzw. -herstellung beteiligten Abteilungen stammen sollten. Auch der Anwender sollte dabei mit einbezogen werden. Die konkrete Ausgestaltung der Arbeitsgruppen ist sehr stark vom Produkt abhängig, eine Aufteilung der einzelnen Gruppen könnte beispielsweise wie folgt aussehen: • System-FMEA: Moderator, Anwender, Verkauf, KomponentenEntwicklung, System-Entwicklung, Applikation • Konstruktions-FMEA: Moderator, Komponenten-Entwicklung, SystemEntwicklung, Applikation, Qualitätssicherung, Fertigungsvorbereitung • Prozess-FMEA: Moderator, Komponenten-Entwicklung, Qualitätssicherung, Fertigungsvorbereitung, Fertigungsausführung, Technische Funktion

Mod Sy EWG Ko EWG APPL FVB

= Moderator = Systementwicklung = Komponentenentwicklung = Applikation = Fertigungsvorbereitung

QSG TEF FAF Anw Verk

= Qualitätssicherung = Technische Funktion = Fertigungsausführung = Anwender = Verkauf

Abb. 8.4. FMEA-Arbeitsgruppen

Durch die Einbeziehung der verschiedenen Abteilungen werden eine frühzeitige Abstimmung ermöglicht, die interaktive Kommunikation der

136

8 Anwendung von QSM in der Praxis

Unternehmensbereiche gefördert und die späteren qualitätssichernden Maßnahmen deutlich vereinfacht. Es entsteht Akzeptanz durch Zusammenarbeit. An den Moderator in den einzelnen Gruppen werden erhöhte Forderungen gestellt, denn er ist der Leiter der einzelnen Arbeitsgruppen. Ein Moderator kann eine FMEA nur moderieren und zum Ergebnis führen, wenn er die Methodik der FMEA, den Umgang mit den Matrizen sowie bestimmte Moderationstechniken beherrscht. Das heißt vor allem, dass der Moderator in Bezug auf Rhetorik, Kreativitätstechniken und Diskussionstechniken, zusätzlich zu den für die FMEA benötigten Spezialkenntnissen, besonders geschult sein muss. Damit ein FMEA-Projekt erfolgreich abgewickelt werden kann, sind besondere vorbereitende Maßnahmen notwendig, die der Moderator veranlasst. Hierzu zählen die Formulierung der Aufgabenstellung (Begründung, Art, Umfang der FMEA und Kundenerwartungen und modularer Ablauf), eine klare Zielsetzung (Risikovermeidung bzw. Risikoverminderung) und die Ablaufplanung der Sitzungen (Besprechungstermine, -themen, -teilnehmer). Funktionsanalyse. Als Voraussetzung für eine fundierte Fehlerbetrachtung erfolgt zunächst eine System- bzw. Funktionsanalyse. Im ersten Schritt werden die Betrachtungseinheiten durch eine vorgeschaltete Selektion ausgewählt. Betrachtungseinheiten sind bei der SYFMEA Komponenten, bei der KO-FMEA Bauteile und bei der PR-FMEA Arbeitsgänge. Unter Verwendung des Matrix-Systems werden den einzelnen Komponenten Prioritäten für die FMEA-Durchführung zugewiesen. Nach dieser Selektion erfolgt im zweiten Schritt die Funktionsanalyse, d.h. die Untersuchung, welche Forderungen an eine Betrachtungseinheit gestellt werden (SY: Komponentenfunktion, KO: Bauteilfunktion, PR: Bauteilemerkmal). In der Matrix erfolgt nun eine Verknüpfung der Betrachtungseinheiten mit ihrer Funktion, so dass die Überprüfung einer lückenlosen Aufstellung durch Quercheck erfolgen kann. Durch eine anschließend erfolgende Überprüfung der übergeordneten Funktionen können die ermittelten Funktionen noch priorisiert werden. Übergeordnete Funktionen sind wichtige Hauptfunktionen der jeweils höheren FMEA-Ebene (SY: Systemfunktion, KO: Komponentenfunktion, PR: Bauteilfunktion). Eine Funktion wird dann mit einer hohen Priorität versehen, wenn sie eine übergeordnete Funktion direkt unterstützt. Man erhält nun also nach der Funktionsanalyse eine Übersicht über die einzelnen Betrachtungselemente und deren Funktionen, die entsprechend priorisiert wurden.

8.4 Fehler-Möglichkeits- und Einflussanalyse (FMEA)

137

Risikoanalyse. Mit der Risikoanalyse, dem Kernstück der FMEA, wird eine vollständige Untersuchung der kritischen Punkte der ausgewählten Produkte und Prozesse durchgeführt. Zur Bewertung selbst ist anzumerken, dass besonders Selbstkritik gefragt ist. In der Risikoanalyse erfolgt die Ermittlung der Risikoprioritätszahl (RPZ). Diese wird durch Multiplikation der Entdeckungswahrscheinlichkeit (E) mit der Schwere (S) und mit der Auftrittwahrscheinlichkeit (A) eines Fehlers gebildet. Für E, S und A gibt es jeweils eine 10-PunkteSkala, durch die eine Bewertung erfolgt. Dabei bedeutet eine höhere Zahl ein höheres Entwicklungsrisiko. Schritt eins der Risikoanalyse beginnt mit der Ableitung der potentiellen Fehler aus den Funktionen, d.h. es müssen potentielle Fehlfunktionen, Versagensarten und Merkmalabweichungen, durch die eine Funktion nicht erfüllt oder beeinträchtigt werden könnte, möglichst präzise formuliert werden. Im zweiten Schritt erfolgt die Untersuchung der Fehlerentdeckung. Es müssen Fehlerentdeckungs-Maßnahmen ermittelt und die Entdeckungswahrscheinlichkeit des Fehlers bewertet werden. Zur Fehlerentdeckung gehören alle Prüfungen, die geeignet sind, um eine Fehlerart rechtzeitig zu entdecken. Diese Prüfungen müssen möglichst detailliert beschrieben werden. Die E-Bewertung erfolgt anschließend im Team, wobei eine „1“ für eine hohe, und eine „10“ für eine niedrige Entdeckungswahrscheinlichkeit steht. In Schritt drei der Risikoanalyse müssen nun die Fehlerauswirkungen beschrieben und hinsichtlich ihrer Schwere bewertet werden, wobei immer die Sicht des Anwenders vorrangig ist. Im nächsten Schritt erfolgen dann die Suche nach den möglichen Fehlerursachen sowie eine Verknüpfung mit den bereits eingeführten Fehlervermeidungsmaßnahmen, um anschließend die Auftretenswahrscheinlichkeit zu bewerten. Schließlich wird die Risikoprioritätszahl errechnet. Diese Zahl muss geeignet gewertet werden. Zum Beispiel kann man ein Limit für die Risikoprioritätszahlen festlegen, ab dem passende QS-Maßnahmen eingesetzt werden müssen. Risikominimierung. In dem Fall, dass die RPZ über dem festgesetzten Limit liegt, muss eine Risikominimierung stattfinden. Dies geschieht durch den konzentrierten Einsatz von Kreativitäts- und Bewertungstechniken, so dass durch synergetisch wirkende Maßnahmen (Fehlervermeidung, Fehlerentdeckung, Fehlerbegrenzung) eine optimale Risikominimierung erreicht wird. Hier ist zu beachten, dass für ein Unternehmen, das nach der Nullfehlerstrategie vorgeht, die Risikobeseitigung immer höchste Priorität ha-

138

8 Anwendung von QSM in der Praxis

ben muss. Konkret bedeutet dies, dass zunächst Fehlervermeidungsmaßnahmen gesucht werden müssen. Nur sie stellen wirklich eine Qualitätsverbesserung dar. Solche Maßnahmen können das Auftreten des Fehlers verhindern oder zumindest seine Auftretenswahrscheinlichkeit stark reduzieren. Ziel dieser Maßnahmen soll immer eine Auftretenswahrscheinlichkeit A=1 sein. Ist eine Fehlervermeidungsmaßnahme nicht möglich, gilt es die Fehlerentdeckung zu verbessern, um E zu reduzieren. Solche Maßnahmen stehen aber immer in Wechselwirkung mit Fehlervermeidungsbzw. Fehlerbegrenzungsverfahren, denn nachdem ein Fehler entdeckt wurde, muss im nächsten Schritt versucht werden, ihn zu beseitigen. Schließlich ist es noch möglich, Fehlerbegrenzungsmaßnahmen zu finden. Diese sind zwar keine Qualitätsverbesserung, sollen aber zumindest die Auswirkungen, das heißt die Schwere S, des Fehlers reduzieren. Bei den Risikominimierungsmaßnahmen ist es wichtig, den wirtschaftlichen Aspekt im Auge zu behalten; manchmal kann es günstiger sein, lediglich Fehlerbegrenzung zu betreiben statt die Fehlerursache an sich zu beseitigen. Ein auf qualitativ hochwertige Produkte bedachtes Unternehmen sollte aber immer der Fehlervermeidung höchste Priorität einräumen. Einführungsstrategie

Besonders wichtig ist die Schulung der Mitarbeiter. Zu den fachlichen Anforderungen, das heißt dem Überblick über das Matrix System, kommen die sozialen Anforderungen hinzu. Besonders der Moderator muss sorgfältig ausgewählt werden. Eine erfolgreiche Einführung gelingt nur bei konsequenter Umsetzung. Der Projektleiter muss 100%ig von der MatrixFMEA überzeugt sein und dies auch den beteiligten Mitarbeitern vermitteln, was besonders leicht bei direktem Vergleich zwischen Matrix- und der konventionellen Listen-FMEA gelingt, da die Vorteile der MatrixFMEA offensichtlich sind. 8.4.3

Bewertung

Fachliche Bewertung

Fachlich ist besonders das durch die Matrix-FMEA erzwungene analytische Vorgehen positiv hervorzuheben. Schon bei der präventiven Qualitätssicherung wird eine umfassende Analyse der kritischen Bereiche erstellt, die auch später immer wieder von Nutzen ist. Die Mitarbeiter werden an eine analytische Fehlererkennungsstrategie herangeführt und somit

8.4 Fehler-Möglichkeits- und Einflussanalyse (FMEA)

139

für kritische Bereiche sensibilisiert. Außerdem wird methodisches Vorgehen geschult. Wirtschaftliche Bewertung

Allerdings muss man bei der Anwendung der FMEA immer den Zeitaufwand im Auge behalten. Es kann sein, dass man aufgrund von Kundenanforderungen an die Qualitätssicherung gezwungen ist, eine FMEA durchzuführen. Ansonsten gilt es abzuwägen. Zwar hat sich der ursprünglich sehr hohe Aufwand im Vergleich zu den Ergebnissen durch die Einführung der Matrix-FMEA bei gleichzeitiger Effizienzverbesserung wesentlich verringert; aber es kann durchaus sein, dass eine FMEA-Durchführung zu umständlich ist. Man denke hier vor allem an den Schulungsaufwand für die Mitarbeiter. Andererseits aber ist eine korrekt durchgeführte Matrix-FMEA eine sehr effiziente präventive Qualitätssicherungsmaßnahme. Schon im Vorfeld der Produktion können entscheidende Risiken definiert und dokumentiert werden. So werden später auftretende, eventuell um ein Vielfaches höhere Kosten, die durch Produktionsausfall oder Rückrufaktionen entstehen, vermieden. Die konsequente Durchführung einer Matrix-FMEA bietet schließlich als Ergebnis das ausgefüllte Matrix-System, mit dem leicht eine gute Übersicht über die System-, Konstruktions- und Prozessabläufe gelingt. Diese Übersicht kann man auch bei Änderungen heranziehen, da die Verzahnung und die Prioritäten sehr leicht erkennbar sind. 8.4.4

Praktische Tipps

Folgende Punkte sind bei der FMEA zu beachten: • • • • •

Akzeptanz bei den Mitarbeitern schaffen Ausreichende Schulung Auswahl eines geeigneten Moderators (Schlüsselfigur) Auf genaue Anpassung an die eigenen Bedürfnisse achten Ziele und Umsetzungstermine eindeutig formulieren (lange ineffektive Sitzungen vermeiden) • konsequente Führung (Überzeugungsarbeit muss bei Neueinführung des Systems geleistet werden)

140

8 Anwendung von QSM in der Praxis

8.5

Funktionstest

Funktionstests sind die am häufigsten angewendeten Tests bei der Softwareentwicklung. Sie gehören mit den Leistungstests zu den Systemtests. Ziel ist es, die spezifizierte Funktionalität der Elemente des Gesamtsystems nachzuweisen. Diese Tests sind Teil der analytischen Qualitätssicherung, das heißt, das entwickelte Produkt wird auf die Erfüllung der geforderten Funktionalität eingehend untersucht. Grundlagen für einen Test sind eine eindeutige Funktionsspezifikation, allgemeine Richtlinien und UseCase-Beschreibungen. Funktionstests werden in Klassen-, Modul-, Komponenten-, Subsystemund Gesamtsystemtests unterteilt. Der Stresstest ist eine besondere Form eines Funktionstests. Beim Stresstest wird die Reaktion eines Systems auf außergewöhnlich hohe Belastungen untersucht. Hauptziele des Funktionstests sind: • • • •

Verifizierung der entwickelten Software Nachweis der korrekten Funktionsweise der Komponenten Untersuchung der Belastbarkeit eines Systems Erkennung von Fehlern vor Freigabe des Programms

8.5.1

Einsatzumfeld

Das Unternehmen

Die ELAU Elektronik Automations AG ist ein mittelständisches Unternehmen der Automatisierungsbranche mit Sitz in Marktheidenfeld. ELAU produziert und vertreibt intelligente digitale Servoantriebe für Nahrungsmittel- und Verpackungsmaschinen. Im Unternehmen sind heute ca. 200 Mitarbeiter beschäftigt, deren Zahl kontinuierlich zunimmt. Die Entwicklungsabteilung beschäftigt ca. 30 Ingenieure der Elektrotechnik bzw. Informatik. Einsatzumfeld der Maßnahme

Funktions- und Stresstests sind grundlegende Tests, die Teil jedes größeren Softwareentwicklungsprojektes sein sollten. Ohne sorgfältiges Testen der entwickelten Software ist es unmöglich, deren Qualität und Funktionalität zu garantieren. Dies kann insbesondere hohe Kosten aufgrund von Nachbesserung zur Folge haben. Die Unzufriedenheit der Kunden und der

8.5 Funktionstest

141

damit verbundene Imageverlust wiegen jedoch langfristig meist noch wesentlich schwerer. Unabhängig vom konkreten Anwendungsunternehmen, von der Branche oder von Mitarbeiterzahlen erfolgt hier eine Beschreibung dieser zentralen Qualitätssicherungsmaßnahme. Die Funktions- und Stresstests sollten durch einen speziell für Tests verantwortlichen Mitarbeiter (nicht durch den Entwickler selbst) im Anschluss an die entwicklungsbegleitenden Tests erfolgen. Der Tester muss besonders qualifiziert sein, da er sowohl die Testverfahren als auch das zu testende System kennen sollte. Auf seine Rolle wird im folgenden Kapitel nochmals genau eingegangen. 8.5.2

Vorgehensweise

Motivation für den Einsatz

Funktions- und Stresstests zählen zu den grundlegenden Qualitätssicherungsmaßnahmen. Sie werden auf der Basis der Spezifikationen und Anforderungen an die Software durchgeführt. Vor Auslieferung einer Software muss in ausreichendem Umfang getestet werden, um zu garantieren, dass die Programme laufen und keine schwerwiegenden Fehler oder Fehlfunktionen auftreten und dass insbesondere alle zugesicherten Funktionen vorhanden sind. Dies ist auch in Verbindung mit Risiko- und Sicherheitsmanagement von zentraler Bedeutung, gerade auch in Bereichen, wo komplexe Soft- und Hardware zusammenspielen. Beispielsweise im Bereich der Automatisierungstechnik, in dem die ELAU AG tätig ist, ist es enorm wichtig, sicherheitskritische Funktionen zu testen und Fehlfunktionen auszuschließen, um keine Gefährdung von Mensch und Maschine zu riskieren. Anwendung

Die Funktionstests werden nach den Entwicklertests durch einen möglichst unabhängigen Tester durchgeführt. Sie werden auf der Grundlage von Anforderungen und Spezifikationen erarbeitet. Ohne diese Tests kann die Freigabe eines Programms nicht erfolgen. Nach Durchführung der internen Funktionstests werden extern Usability-Tests von den Anwendern durchgeführt. Falls Änderungen im Gesamtsystem erforderlich werden, ist es unabdingbar, wieder alle Funktionen zu testen (Regression). Hier ist besonders auf ein durchgängiges Anforderung-, Versions- bzw. Änderungsmanagement (siehe QSM in der Praxis: Änderungsmanagement, Anforderungsverfolgung) auch bei der Durchführung der Tests zu achten.

142

8 Anwendung von QSM in der Praxis

Im Folgenden soll auf die Punkte „Gliederung der Testdokumentation“, „Funktionstests“ und „Rolle des Testers“ näher eingegangen werden. Gliederung der Testdokumentation. Zur Gewährleistung der Reproduzierbarkeit und der Verfolgbarkeit eines Tests (wie dies auch in einigen Richtlinien gefordert wird, z.B. ISO 9000) muss sowohl eine klare Gliederung des Testablaufs als auch der Testdokumentation erfolgen. Es ist sinnvoll, eine Standardisierung vorzunehmen, da so die Arbeit des Testers auf Dauer vereinfacht und die Transparenz und Nachvollziehbarkeit der Tests erhöht wird. Vor dem Testen sollte immer ein geltender Prüfplan erstellt werden, an den sich der Tester hält. Dieser Plan ist die Grundlage für die Dokumentation. Beim Test eines ganzen Systems könnte eine Gliederung beispielsweise wie folgt gestaltet werden: 1. Änderungsübersicht: Angabe der Version, der erfolgten Änderungen und des Erstellers mit Datum 2. Beschreibung: Ziel und Zweck der Tests 3. Geltungsbereich: Angabe, wer welche Punkte beachten muss und an wen welche Informationen weitergeleitet werden müssen 4. Begriffe und Abkürzungen: weitere geltende Unterlagen, verwendete Begriffe, etc. 5. Beschreibung der Abläufe bzw. Aktivitäten: Allgemeines (Dauer, Aufwand, Versionen, Geräte, Teststand, etc.), Vorbereitungen, Durchführung, erwartetes und tatsächliches Ergebnis, Bewertung einschließlich Freigabe Funktionstests. Funktionstests sind Teil der analytischen Qualitätssicherung. Auf der Grundlage der Spezifikation und Anforderungen werden die Funktionen der Software überprüft und gegebenenfalls freigegeben. Hier ist ein besonderes Augenmerk auf die Wirtschaftlichkeit des Tests zu legen. Das heißt z.B., dass bestimmte Daten zu Klassen zusammengefasst werden und dann beispielsweise nur die Klassengrenzen getestet werden. Ein Test kann nie alle Möglichkeiten abdecken; deshalb ist es wichtig, die Auswahl der Tests sorgfältig zu treffen. Nach erfolgreicher Durchführung der Funktionstests muss ausreichend gut gesichert sein, dass alle Produktanforderungen erfüllt wurden. Dies ist insbesondere in sicherheitskritischen Bereichen bzw. wenn eine hohe Verfügbarkeit des Systems gefordert ist, entscheidend. Der Tester muss dafür eine geeignete Auswahl der durchzuführenden Tests, der Eingabedaten bzw. der Testumgebung treffen. Bei der Festlegung der Testfälle sollte die Anwendersicht im Vordergrund stehen, das heißt die Tests sollten sich an dem späteren Praxiseinsatz orientieren. Vor allem auch das Zusammenspiel von Software und Hard-

8.5 Funktionstest

143

ware bzw. von Software im Netzwerk oder mit anderen Programmen ist sorgfältig zu überprüfen. Hier gibt es mehrere Möglichkeiten: die Umgebung muss entweder simuliert oder es muss ein Prüfstand aufgebaut werden. Ein besonderer Teil der Tests sind die Stresstests. Hier werden Soft- und Hardware an den Grenzen der zulässigen Betriebsparameter getestet. Es wird bewusst eine Überlast des Systems herbeigeführt und dann überprüft, wie das System reagiert. Die Software wird also vor allem in Stresssituationen untersucht und die Stabilität des Programms wird durch beabsichtigtes Fehlverhalten und Mehrfachbelastungen überprüft. Die definierten Grenzen des Systems müssen bekannt sein, damit das Leistungsverhalten des Systems an diesen Grenzen beobachtet und protokolliert werden kann. Zur Vereinfachung der Arbeit des Testers gibt es Unterstützung durch spezielle Software-Werkzeuge. Beispielsweise können die Eingaben des Benutzers an der Benutzeroberfläche mit Softwareunterstützung (z.B. Rational Visual Test®) automatisch getestet werden. Solche vollautomatischen Tests sind immer wieder unter den gleichen Bedingungen durchführbar und frei von Unregelmäßigkeiten. Die Arbeit des Testers verlagert sich von der stupiden Abarbeitung von Testvorschriften hin zur Entwicklung von Testvorschriften. Motivation und Bedeutung der Arbeit werden aufgewertet, da der Prozess mehr Kreativität verlangt. Stresstests sind besonders in sicherheitskritischen Bereichen wichtig, da das Verhalten der Soft- und Hardware auch bei Überlastung immer korrekt sein muss, um eine Gefährdung von Mensch und Maschine sicher ausschließen zu können. Bei der Durchführung aller Funktionstests muss immer auf die korrekte Dokumentation und die Rückverfolgbarkeit geachtet werden, da ein Test, der nicht wiederholbar ist, letztlich keine brauchbaren, verifizierbaren Ergebnisse liefert. Eine Testdokumentation kann man beispielsweise in die Abschnitte Titel, Aufgabenstellung, Anforderungen, Prüfschritte untergliedern. Zusätzlich sollten dann noch Ergebnisse, z.B. in Form einer grafischen Aufzeichnung von Messwerten beigefügt werden. Rolle des Testers. Bei der Durchführung der Funktionstest ist es besonders wichtig, den Tester selbst sehr sorgfältig auszuwählen, weil er spezielle Qualifikationen besitzen muss. Grundsätzlich ist beim Testen sehr sorgfältiges, genaues und analytisches Arbeiten nötig. Es ist darauf zu achten, dass der Tester niemals der Entwickler der Software ist. Der Entwickler testet seine Software zwar auch im Entwicklungsprozess und ist immer Ansprechpartner für den Tester, es ist aber nicht ratsam, dass der Entwickler selbst sein Projekt testet, da er es viel zu gut kennt und dann eventuell offensichtliche Fehler einfach übersieht. Außerdem entdecken

144

8 Anwendung von QSM in der Praxis

mehrere verschiedene Tester mehr Fehler, wodurch dann letztendlich die Qualität des freigegebenen Produkts erhöht wird. Fehlerentdeckung durch den Entwickler selbst ist schon aus psychologischer Sicht keine gute Arbeitsvoraussetzung, da er selbst nach Unzulänglichkeiten in seiner eigenen Arbeit suchen soll. Der Tester muss auch fachliches Know-how besitzen. Zunächst muss er das zu testende System kennen, er muss die Anforderungen verstehen und die Spezifikationen parat haben. Hinzu kommt, dass Tests auch immer aus Kundensicht erfolgen sollten. Für den Tester bedeutet dies, dass er fähig sein muss zu abstrahieren und mit der Entwicklungsabteilung und den Anwendern zu kommunizieren. Vor allem bei größeren Projekten ist es sinnvoll, ein oder zwei hauptverantwortliche Funktionstester zu beschäftigen, die nicht direkt an der tatsächlichen Entwicklung des Projekts mitarbeiten, aber Entwicklungserfahrung haben und das System und dessen Anwendung gut kennen. Einführungsstrategie

Bei der Durchführung von Funktionstests ist zum einen die Person des Testers von entscheidender Bedeutung. Hinzu kommt die Durchführung des Tests, die klar strukturiert sein muss und, wo möglich, nach standardisierten Abläufen erfolgen sollte. Aber insbesondere die Einstellung und Motivation der Mitarbeiter ist eine wichtige Voraussetzung. Es muss klar sein, dass Qualität und letztlich Kundenzufriedenheit die entscheidenden Ziele jeder Entwicklung sind. Eine konstruktive Zusammenarbeit zwischen Entwicklung und den Testern ist ein wichtiger Erfolgsfaktor. Ein Tester kritisiert schließlich nicht die Arbeit der Entwicklung, sondern er trägt primär zur Verbesserung des Produkts bei. Im Bewusstsein der Mitarbeiter muss diese Ausrichtung auf qualitätsorientiertes Vorgehen verankert sein. Hier sind auch Unternehmenskultur und das Verhalten von Vorgesetzten entscheidend. Insgesamt kann nur ein ausreichend getestetes und verbessertes Produkt auch erfolgreich vermarktet werden. 8.5.3

Bewertung

Fachliche Bewertung

Aus fachlicher Sicht muss im professionellen Entwicklungsprozess ein ausreichender Funktionstest integriert sein. Nur nach konsequenten Tests, die auf Grundlage einer durchdachten Anforderungsverfolgung stattfinden, können Softwarequalität und Kundenzufriedenheit erreicht werden. Feh-

8.5 Funktionstest

145

lerentdeckung und Fehlerbehebung müssen als Teil des Entwicklungsprozesses verstanden und umgesetzt werden. Wirtschaftliche Bewertung

Korrekt durchgeführte Funktionstests sind letztlich die Grundlage jeglicher Garantien, die ein Unternehmen für die Funktionsfähigkeit seiner Produkte abgibt. Funktionstests und insbesondere Stresstests bewahren das Unternehmen davor, dass fehlerhafte Software von minderer Qualität ausgeliefert wird. Trotz der Kosten, die Funktionstests auch aufgrund ihres zum Teil erheblichen Aufwands verursachen, rechnen sich diese Tests also, da komplizierte Nachbesserungen oder sogar Regressansprüche schon im Vorfeld verhindert werden können. Dennoch muss man gerade beim Testen auch die Wirtschaftlichkeit im Auge behalten. Es gibt sicher auch Fehler, die vermeidbar sind, die aber eventuell keine gravierenden Auswirkungen haben. Hier ist die Erfahrung des Testers von entscheidender Bedeutung. Insgesamt gilt, wie immer in der Qualitätssicherung, dass ein frühzeitig erkannter und dann korrigierter Fehler vor späteren hohen Kosten schützt. 8.5.4

Praktische Tipps

Folgende Punkte sind bei der Anwendung des Funktionstests wichtig: • Auf wirtschaftliches Testen achten. Nicht jede Funktion kann, aber kritische müssen getestet werden. • Funktionstests sollten auf keinen Fall durch den Entwickler des Programms durchgeführt werden. • Auf exakte Funktionsspezifikation durch Entwickler achten (Grundlage der Tests). • Tests sollten aus Anwendersicht erfolgen. • Der Tester muss das Gesamtsystem und dessen Anwendungen sehr gut kennen.

146

8 Anwendung von QSM in der Praxis

8.6

Nutzung eines Phasenmodells (V- Modell)

Die Aufteilung von größeren Projekten in getrennte, zeitlich aufeinander folgende Phasen ist eine unabdingbare Voraussetzung zur Gewährleistung einer planmäßigen und vor allem wirtschaftlichen Projektarbeit. Unter einer Phase versteht man hierbei einen definierten zeitlichen Abschnitt in der Produktentwicklung, -erstellung und -nutzung. Die einzelnen Phasen werden bestimmt durch Eingangsinformationen und -unterlagen und durch die jeweils zu erreichenden Phasenziele. Die Softwareerstellung erfolgt im folgenden Beispiel in Anlehnung an das V-Modell 97 mit dem Ziel der Verbesserung von Produktqualität bei gleichzeitiger Prozessoptimierung. Hierdurch soll der SoftwareEntwicklungsprozess den gestiegenen Anforderungen seitens der Kunden an die Qualität bei gleichzeitig zunehmender Gerätefunktionalität und damit einhergehender Systemkomplexität angepasst werden. Diese Ziele sollen erreicht werden durch: • eindeutige und verbindliche Vorgaben zu Beginn und während des SWEntwicklungsprozesses, • die inkrementelle Gestaltung des SW-Entwicklungsprozesses, • eine Erhöhung der Transparenz des Arbeitsablaufes sowie • die Verbesserung der Kommunikation zwischen den Beteiligten im Produktentstehungsprozess. Die gesetzten Ziele verlangen eine fortwährende Überprüfung und Nachbesserung des Prozesses um die gewonnenen Erfahrungen sowie die Berücksichtigung der sich ändernden Anforderungen. Dies bedeutet, dass der dokumentierte Prozess gepflegt werden muss, um auch die weitere Optimierung zu unterstützen. 8.6.1

Einsatzumfeld

Das Unternehmen

Die Endress+Hauser Gruppe ist ein Anbieter von Messgeräten und Automatisierungslösungen für die Verfahrenstechnik (unter anderem für Chemie und Petrochemie, Pharma, Lebensmittel, Wasser und Abwasser, Papier, Energie, Öl und Gas). Die Gruppe umfasst heute 24 Produktionsgesellschaften in 9 Ländern, 42 eigene Vertriebs- und Servicegesellschaften in 36 Ländern, sowie 7 Verwaltungsgesellschaften. Sie wird von einer Holding mit Sitz in Reinach (Schweiz) gesteuert.

8.6 Nutzung eines Phasenmodells (V- Modell)

147

Bei der Endress+Hauser GmbH+Co. KG in Maulburg sind zurzeit ca. 1340 Mitarbeiter beschäftigt. Hauptarbeitsgebiete sind die Entwicklung und Produktion von Füllstand-, Druck-, und Differenzdruckmessgeräten. Dabei werden folgende Messprinzipien angewandt: • Füllstand: kapazitiv, konduktiv, hydrostatisch, radiometrisch, Ultraschall, Mikrowelle, Mikroimpulse, Lotsystem, Vibration • Druck: kapazitiv, piezoresistiv Einsatzumfeld der Maßnahme

Der Innovationsprozess Füllstand, innerhalb dessen die beschriebene Methode entwickelt und verwendet wurde, ist in Form einer Matrix organisiert. Hierbei sind die zu den jeweiligen Messprinzipien (Ultraschall, Mikrowelle, Mikroimpuls, ... ) zugehörigen Kompetenzen in Projektteams zusammengefasst. Bestimmte übergreifende Funktionen wie „Technische Sicherheit“ oder auch die Softwareentwicklung sind quer dazu angeordnet. Im Bereich der Entwicklung für kontinuierlich messende Füllstandsgeräte sind ca. 100 Mitarbeiter tätig, wobei etwa 25 Mitarbeiter im Softwarebereich arbeiten. 8.6.2

Vorgehensweise

Motivation für den Einsatz

Durch die Zerlegung des gesamten Entwicklungsprozesses in einzelne Phasen wird erhöhte Überschaubarkeit, Prüfbarkeit und damit auch rechtzeitige Korrigierbarkeit der einzelnen Entwicklungsschritte erreicht, was durch das Setzen von „Meilensteinen“ an den Übergängen der Phasen weiter verstärkt wird. Anwendung

Nachfolgend werden, in Anlehnung an das V-Modell, softwarespezifische Teile des Submodells SE (System-Erstellung) dargestellt. Diese sind eingebettet in die firmenspezifischen, übergeordneten Phasen „Definitionsund Konzeptphase“ mit dem Meilenstein 1 (MS1) „Konzeptinformation“, sowie „Entwicklungs- und Qualifizierungsphase“ mit MS2 „Design Freeze“. Dabei entsprechen die gewählten Formulierungen im Wesentlichen denen des offiziellen V-Modells. Der beschriebene SW-Entwicklungsprozess zeichnet sich zudem durch seine Allgemeingültigkeit aus. Die enthaltenen technischen und organisatorischen Regelungen können und

148

8 Anwendung von QSM in der Praxis

sollen an die konkrete Projektsituation angepasst werden. Diese Anpassungen für ein Projekt (Tailoring) können durch Streichen, Zusammenfassen oder auch Ergänzen von Aktivitäten und / oder Dokumenten durchgeführt werden. Im Sinne einer einheitlichen und transparenten Vorgehensweise sollten diese Anpassungen kenntlich gemacht und kurz begründet werden. Im Folgenden werden die Phasen SE 3(SW) bis SE 5(SW) beispielhaft beschrieben (Abb. 8.5). SE 3 (SW) SW-Anforderungsanalyse. Im Rahmen von Aktivität SE 3 "SW-Anforderungsanalyse" wird das Pflichtenheft (Gesamtsystem/Gerät) bezogen auf eine SW-Einheit um den Teil Software-Pflichtenheft erweitert. Den Ausgangspunkt dieser Aktivität bilden die Markt- und Produktspezifikation sowie weitestgehend das Pflichtenheft Gesamtsystem/Gerät inkl. der Software-Spezifikation. Auf dieser Basis sind im SW-Pflichtenheft allgemeine Anforderungen, Anforderungen an Schnittstellen, Funktionalität, Qualitätsmerkmale sowie die SW-Entwicklungs- u. SWPÄ-Umgebung zu analysieren und zu definieren (SWPÄ = Software Pflege- und Änderungsprozess). SE 3.1 (SW) Allgemeine Anforderungen aus Sicht der SW-Einheit definieren. Allgemeine Anforderungen, die sich im Rahmen der SWAnforderungsanalyse aus Sicht der SW-Einheit ergeben, werden im SWPflichtenheft festgehalten. Dies können beispielsweise Anforderungen bezüglich der Realisierung der internen Schnittstellen sein (z.B. durch die pauschale Benennung von Schnittstellenstandards). SE 3.2 (SW) Anforderungen an die externen Schnittstellen der SWEinheit präzisieren. Zum einen werden die Anforderungen an die technische Einsatzumgebung beschrieben: In dieser Aktivität sind im SWPflichtenheft die Anforderungen an die Einsatzumgebung und an weitere externe Schnittstellen der SW-Einheit im operationellen Betrieb zu präzisieren. Die Anforderungen an die Einsatzumgebung bestimmen die Einbettung der SW-Einheit, d.h. das Zusammenspiel der Software mit externen Elementen des operationellen Betriebs. Die komplexen Umgebungsschnittstellen zwischen parallel und asynchron agierenden Objekten im operativen Einsatz sind zu beschreiben. Objekte in diesem Zusammenhang können SW-Einheiten im gleichen System, Nutzer des Systems oder Geräte anderer Systeme sein. Definiert werden muss vor allem auch das geforderte Zeitverhalten.

8.6 Nutzung eines Phasenmodells (V- Modell)

149

MS2 Design freeze

Definitionsund Konzeptphase Markt- und Produkt Spezifikation

SW-Einheit

Pflichtenheft (Gesamtsystem)

Einführung der SW

SW-Spezifikation QS-Dokumentation

SWE3 SW-Anforderungsanalyse und Entwurf

SW-Prüfplanung SW-Prüfprozedur SW-Prüfprotokoll

Konfiguration der Gerätesoftware Gesamtdoku

SW-Pflichtenheft Schnittstellenübersicht

MS1 Konzeptinformation

Tailoring

SWE4 Grobentwurf SW-Integrationsplan

SWE7 SW-Integration

QS-Dokumentation SW-Prüfplanung SW-Prüfprozedur SW-Prüfprotokoll

SW-Architektur SW-Module

Schnittstellenübersicht

SW-Integrationsplan

Schnittstellenbeschreibung Tailoring

QS-Dokumentation

ImplementierungsDokumente Tailoring

SWE5 Feinentwurf Datenkatalog

SW-Prüfplanung SW-Prüfprozedur SW-Prüfprotokoll

SW-Feinentwurf Schnittstellenübersicht Schnittstellenbeschreibung Tailoring SWE6 Implementierung

Abb. 8.5. Software-Entwicklungsprozess in Anlehnung an das V-Modell 97

150

8 Anwendung von QSM in der Praxis

Zum anderen werden die Anforderungen an die Nutzerschnittstelle definiert. Eine besondere Form der externen Schnittstelle von SW-Einheiten ist die Mensch-Maschine-Schnittstelle. Hier sind im SW-Pflichtenheft die Anforderungen z.B. an bereitzustellende Dienste und auszutauschende Informationen, Syntax und Semantik der einzelnen Masken etc. zu präzisieren. SE 3.3 (SW) Anforderungen an die Funktionalität definieren. In dieser Aktivität sind die Anforderungen an die technische Funktionalität der SWEinheit zu definieren. Die von der SW-Einheit zu realisierende Funktionalität ist zu identifizieren und im SW-Pflichtenheft festzuschreiben. Es sind Anforderungen an die Reaktionen der SW-Einheit im Normal- und Ausnahmefall zu definieren. SE 3.4 (SW) Anforderungen an die Qualität der SW-Einheit definieren. Es sind die Anforderungen bzgl. der Einhaltung von Qualitätsmerkmalen festzulegen. Dazu zählen u.a. Codierrichtlinien, Modularität, Schachtelungstiefe etc. SE 3.5 (SW) Anforderungen an Entwicklungs- und SWPÄ-Umgebung definieren. Anforderungen an die Entwicklungs- und SWPÄ-Umgebung sind dann zu stellen, wenn diese von den entsprechenden Anforderungen an das System abweichen. Zur Entwicklungsumgebung zählen auch Integrations- und Prüfeinrichtungen, die während der Entwicklung und SWPÄ einer SW-Einheit notwendig sind. • Dokumente – Input: Markt- und Produktspezifikation, weitestgehend Pflichtenheft (Gesamtsystem / Gerät), Software-Spezifikation • Dokumente – Output: Software-Pflichtenheft, Schnittstellenübersicht, Tailoring • Dokumentation (QS): SW-Prüfplanung, SW-Prüfprozedur, SWPrüfprotokoll SE 4 (SW): SW-Grobentwurf. Diese Aktivität beinhaltet den Entwurf der Software-Architektur inkl. der Vervollständigung der Schnittstellenübersicht, die Beschreibung der SW-Schnittstellen und die Entwicklung des Integrationsplans auf SW-Ebene. Der Entwurf der SW-Architektur hat die Aufgabe, aus Sicht der Dynamik der SW-Einheit SW-Prozesse zu bilden und gegebenenfalls die Aufteilung auf Prozessoren vorzunehmen sowie die Kommunikation und Synchronisation der Prozesse zu entwerfen und aus Sicht der statischen Struktur der SW-Einheit SW-Module, SW-Komponenten und / oder Datenbanken zu definieren. Zu jedem dieser Architekturelemente ist eine kurze

8.6 Nutzung eines Phasenmodells (V- Modell)

151

Leistungsbeschreibung zu verfassen und die entstehenden Schnittstellen sind zu identifizieren. In der Schnittstellenbeschreibung muss dann das Zusammenspiel der SW-Module / Prozesse, SW-Komponenten und / oder Datenbanken spezifiziert werden. Diese Informationen dienen als Ausgangspunkt für den SW-Feinentwurf (SE 5). SE 4.1 (SW) SW-Architektur entwerfen. Die SW-Architektur beschreibt die Zerlegung einer SW-Einheit in SW-Komponenten, Prozesse, SWModule und / oder Datenbanken. Vorschläge für mögliche SW-Architekturen werden erarbeitet und bewertet; für die weitere Bearbeitung ist ein Lösungsvorschlag auszuwählen. SW-Einheiten bestehen im Allgemeinen aus mehreren Prozessen oder Tasks, die parallel oder quasi-parallel ablaufen. Ziel ist es, eine SWEinheit unter dem Gesichtspunkt notwendiger oder möglicher Parallelverarbeitung zu strukturieren. Dabei sind die Gegebenheiten des Betriebs- und Laufzeitsystems sowie die Erfordernisse und Einschränkungen der Hardware und der Programmiersprache zu berücksichtigen. Die SWArchitektur enthält eine Beschreibung des Prozess-Ensembles samt seiner Strukturierung, Kommunikation, Synchronisation und Darstellung des dynamischen Ablaufmodells. Die aufgrund von Architekturentscheidungen festgelegten Schnittstellen sind in der SW-Architektur zu identifizieren und in der Schnittstellenübersicht zu dokumentieren. Die vollständige Abdeckung der Anforderungen durch die in der SW-Architektur definierten Prozesse, SW-Komponenten, SW-Module und / oder Datenbanken ist nachzuweisen. Anmerkung. In der Regel werden neben den für die Realisierung von operationellen Anwendungsfunktionen erforderlichen auch solche SWKomponenten bzw. SW-Module benötigt, die lediglich technische Hilfsfunktionen zur Verfügung stellen und deshalb nicht aus den operationellen Anforderungen, sondern aus den Gegebenheiten des technischen Lösungsansatzes herzuleiten sind (z.B. Gateway-Elemente). Diese sind bei der Festlegung der SW-Architektur mit zu berücksichtigen. Einfluss auf diese Modularisierungsentscheidungen haben die Prozess-Struktur der SWEinheit, zusätzlich notwendige (systeminterne) Funktionen, Zielrechner (Laufzeitsystem, Protokolle etc.), Konzepte der Fehlerbehandlung und Kommunikation, Kriterien wie Datenabstraktion, Information Hiding, Abgeschlossenheit, Überschaubarkeit, Minimalität der Schnittstellen, Prüfbarkeit, Integrierbarkeit, Wiederverwendbarkeit sowie Anforderungen an Zeitverhalten und Zuverlässigkeit. SE 4.2 (SW) SW-interne und -externe Schnittstellen entwerfen. Die beim Entwurf der SW-Architektur in der Schnittstellenübersicht identifi-

152

8 Anwendung von QSM in der Praxis

zierten Schnittstellen sind in der Schnittstellenbeschreibung im Einzelnen detailliert darzustellen. Bereits beschriebene Schnittstellen sind gegebenenfalls weiter zu präzisieren. SE 4.3 (SW) SW-Integration spezifizieren. Für den Integrationsplan sind Vorschriften und Vorgehensweisen für den Zusammenbau der SW-Einheit aus SW-Komponenten und der SW-Komponenten selbst aus SW-Modulen und / oder Datenbanken aus technischer Sicht zu regeln. Er ist im Hinblick auf Termine, Betriebs- und Hilfsmittel, Werkzeuge, Personal, Fertigprodukte, Schnittstellen und ähnliche Einflüsse in Absprache mit dem Projektmanagement zu erstellen. Im Integrationsplan sind die Konfigurierung der SW-Einheit und alle für die Integrationsaktivität benötigten Informationen festzuschreiben. Informationen für den Integrationstest sind abzuleiten und festzuhalten. • Dokumente – Input: Software-Pflichtenheft inkl. Schnittstellenübersicht, Tailoring • Dokumente – Output: Software-Architektur, Schnittstellenübersicht, Schnittstellenbeschreibung, Software-Integrationsplan, Tailoring • Dokumentation (QS): SW-Prüfplanung, SW-Prüfprozedur, SW-Prüfprotokoll SE 5 (SW): SW-Feinentwurf. Die Ausgangsbasis für die Aktivität Software-Feinentwurf bilden die SW-Architektur und die Schnittstellenbeschreibung. Dort sind alle Informationen festgehalten, die erforderlich sind, um die Leistung eines SW-Moduls in Anspruch nehmen zu können. Die Vorgaben und Details für die Realisierung jedes SW-Moduls, jeder SW-Komponente und / oder jeder Datenbank müssen festgelegt werden. Auf dieser Grundlage müssen sodann Betriebsmittel- (z.B. Speicherbedarf, Auslastung) und Zeitbedarf (z.B. Lauf-/Reaktionszeiten, Messzyklen) der einzelnen Architekturelemente und der gesamten SW-Einheit ermittelt werden, welche den diesbezüglichen Anforderungen Rechnung zu tragen haben. SE 5.1 (SW) SW-Komponente/-Modul beschreiben. Gegenstand dieser Aktivität ist die softwaretechnische Realisierung der SW-Komponenten bzw. SW-Module. Die Konstruktion jedes SW-Moduls und jeder SWKomponente bis auf die Ebene einer Programmiervorgabe (z.B. Pseudocode, Spezifikationssprache) muss beschrieben werden. Zum einen müssen die SW-Komponenten / SW-Module beschrieben werden (ggf. Verfeinerung der Module). Die SW-Komponenten und SWModule müssen hinsichtlich ihrer Umgebung, der Realisierung ihrer Funktionalität, der Datenhaltung, Ausnahme- und Fehlerbehandlung, usw. spezifiziert und bis hin zu einer Programmiervorgabe formuliert werden.

8.6 Nutzung eines Phasenmodells (V- Modell)

153

Zum anderen müssen die Datenkataloge erstellt werden. Die in der SWEinheit benutzten Daten sind in einem Datenkatalog aufzunehmen. Die Eingangsinformationen für den Datenkatalog liefern die DB-bezogenen Informationen in der SW-Architektur und im SW-Entwurf. Im Datenkatalog sind implementierungsabhängige Informationen, wie Bezeichner, Datentyp, Datenformat, Lebensdauer, Zugriffsart, Zugriffs- und Entstehungszeiten und -frequenzen, Zuordnung zu Datenbanken, Speicherart, Speicherplatzbedarf usw., festzuhalten. SE 5.2 (SW) Betriebsmittel- und Zeitbedarf analysieren. Hier erfolgen die Ermittlung und die Überprüfung des errechneten Bedarfs auf seine Realisierbarkeit. Auf der Basis von SW-Architektur und SW-Komponenten-/SWModulbeschreibung erfolgt die Ermittlung von benötigten Betriebsmitteln und des Zeitbedarfs. Die ermittelten Leistungsmerkmale sollten gegenüber den im SW-Pflichtenheft festgehaltenen Eigenschaften der SW-Einheit noch genügend Spielraum aufweisen, um spätere Pflege- / Änderungsmaßnahmen ohne Redesign ausführen zu können. Ist dieser Spielraum nicht gegeben, so hat an dieser Stelle eine genaue Überprüfung der Realisierungsentscheidungen zu erfolgen. • Dokumente – Input: Software-Architektur, Schnittstellenübersicht, Schnittstellenbeschreibung, Tailoring • Dokumente – Output: Software-Feinentwurf, Schnittstellenübersicht, Schnittstellenbeschreibung, Datenkatalog, Tailoring • Dokumentation (QS): SW-Prüfplanung, SW-Prüfprozedur, SWPrüfprotokoll Einführungsstrategie

Die Einführung des beschriebenen Modells verlangt wesentliche Umstellungen in der Ablauforganisation eines Unternehmens. Daher ist die unbedingte Unterstützung durch das Management eine essentielle Voraussetzung zur Einführung dieser Methode. Eine intensive Schulung dieser Methode und die Durchführung eines Pilotprojektes sind hilfreich bei der Einführung dieser Vorgehensweise. Hierbei sollte das Pilotprojekt zwar nicht unter extremem Zeitdruck stehen, es sollte sich jedoch auch nicht um ein „Miniprojekt“ handeln.

154 8.6.3

8 Anwendung von QSM in der Praxis Bewertung

Fachliche Bewertung

Der Einsatz eines Phasenmodells bei der Erstellung eingebetteter Software ist heute allgemein anerkannt. Der Einsatz einer „V-Modell kompatiblen“ Vorgehensweise ist außerdem die Basis zur Erstellung von Messgeräten welche sicherheitsrelevant eingesetzt werden sollen (SIL-Klassifizierung). Darüber hinaus bietet die beschriebene Methode eine Basis zur besseren Planung und Überwachung der Projektergebnisse. Hierbei können frühzeitig Abweichungen vom Sollzustand im Entwicklungsfortschritt erkannt und entsprechende Maßnahmen eingeleitet werden. Wirtschaftliche Bewertung

Der Einsatz des beschriebenen Verfahrens erfordert einen erhöhten Aufwand in den frühen Projektphasen. Dieser wird jedoch wieder kompensiert in den nachfolgenden Phasen Implementierung, Integration und Test. Nicht direkt messbar sind die Auswirkungen der qualitativen Verbesserungen der Faktoren „Erhöhung der Testtiefe“, „Stabilisierung der Anforderungen“ und „Höhere Systemstabilität“. Gegenüber dem Kunden ergeben sich außerdem die folgenden weiteren Auswirkungen: „Weniger Reklamationen“, „Höhere Kundenzufriedenheit“, „Höhere Kundenakzeptanz gegenüber dem System“ und „Reduzierung der Kosten in der Gewährleistung“. 8.6.4

Praktische Tipps

Als sinnvoll erweist sich auch die Integration der in der bisherigen Vorgehensweise erstellten Dokumentation in das hier beschriebene Modell.

8.7 Objektorientierte Analyse und Design mit UML

8.7

155

Objektorientierte Analyse und Design mit UML

Die Unified Modelling Language (UML) ist die Standardbeschreibungssprache für die Erstellung objektorientierter Software. Die Sprache stellt eine Reihe von Diagrammen zur Verfügung, die verschiedene Sichten (Modelle) auf die Software repräsentieren. Die Modellbildung und die damit verbundene Abstraktion ist ein grundlegendes Konzept der Objektorientierung. Sie ermöglicht die Bewältigung eines komplexen Systems durch die Fokussierung auf bestimmte Aspekte und abstrahiert dabei von unwesentlichen Details. Die Modelle werden einerseits bezüglich statischer Aspekte (Struktur) und dynamischer Aspekte (Verhalten) und andererseits bezüglich der Entwicklungsphase der Softwareentwicklung unterschieden. Die Modellierungssprache beschreibt sowohl die Syntax (Notation) der vorgegebenen Elemente als auch deren Semantik (Bedeutung). Damit wird sichergestellt, dass die Modelle eindeutig interpretiert werden können. Hauptziele von UML sind: • Einheitliche Darstellung für objektorientierte Analyse und Design • Kommunikationsbasis für Entwicklungsteams • Grundlage für Codegenerierung Fachbegriffe in Verbindung mit Objektorierung und UML: • Iteratives, inkrementelles Vorgehen • Modelle (UML Diagramme) als Abstraktion von Details • Klassen und Objekte 8.7.1

Einsatzumfeld

Das Unternehmen

Die method park Software AG ist ein mittelständisches Software-Haus mit ca. 40 Mitarbeitern und Sitz in Erlangen. method park unterstützt seine Kunden durch Beratungsdienstleistungen zu Themen aus dem SoftwareEngineering, eigene Produkte (C-Codegenerator aus UML-Diagrammen sowie ein Prozessmanagement-Werkzeug) sowie durch Software-Entwicklungsdienstleistungen. Ein Großteil der Kunden und Kooperationspartner von method park sind im Embedded Umfeld tätig. Typische Zielbranchen sind Automobilhersteller und -zulieferer, Medizintechnik, Consumer Electronics, Maschinenbau und Industrieautomatisierung.

156

8 Anwendung von QSM in der Praxis

Einsatzumfeld der Maßnahme

Die Methodik basiert auf der Zerlegung des Gesamtsystems in interagierende Objekte. Jedes dieser Objekte hat zugeordnete Verantwortlichkeiten, die einen Teil der Gesamtfunktionalität darstellen. Mit der Standardisierung der UML durch die Object Management Group (OMG) steht für die Objektorientierte Analyse (OOA) und das Objektorientierte Design (OOD) eine einheitliche Beschreibungssprache zur Verfügung. UML ist unabhängig von einem spezifischen Anwendungsgebiet. Diese Tatsache stellt zugleich einen Vorteil und Nachteil dar. Einerseits ist die Sprache damit nicht auf ein Anwendungsgebiet begrenzt, andererseits fehlen aber auch anwendungsspezifische Konkretisierungen für die Modellierung. Die OMG versucht dieses Defizit durch die Erstellung von Anwendungsprofilen für verschiedene Domänen auszugleichen. Eines der geplanten Profile beschäftigt sich mit Embedded Systems und konkretisiert die Beschreibung für „Performance, Time und Schedulability“. 8.7.2

Vorgehensweise

Motivation für den Einsatz

Software in heutigen Embedded Systems wird stetig komplexer. Um den neuen Anforderungen gerecht zu werden, ist es notwendig, das Gesamtsystem in handhabbare Teilsysteme zu zerlegen. Ein wichtiges Ziel bei der Erstellung derartiger Softwaresysteme ist die Verlagerung des Aufwandes von der Implementierung hin zur Analyse und zum Design. In der Analyse und Designphase werden Modelle (statische Aspekte, dynamische Aspekte) der zu erstellenden Software beschrieben, die von Details abstrahieren und sich auf die wesentlichen Kernprobleme konzentrieren. Mit der Unified Modelling Language (UML) steht eine standardisierte Sprache zur Beschreibung solcher Modelle zur Verfügung. Vor dem Start der Implementierungsphase sollte das Problem (idealerweise vollständig) verstanden sein (Analysephase) und die gewünschte Lösung durch entsprechende Modelle beschrieben sein (Designphase). In der Implementierungsphase wird diese Lösung dann lediglich umgesetzt und um die Details der Programmierkonstrukte der Zielsprache ergänzt. Anwendung

Objektorientierte Analyse und Design setzt im Entwicklungsprozess auf den dokumentierten Anforderungen auf. Die Analysephase dient zur Erstellung eines Anforderungsmodells (Beschreibung von Anwendungsfäl-

8.7 Objektorientierte Analyse und Design mit UML

157

len, falls noch nicht in der Anforderungsphase erstellt) und der Erstellung eines Analysemodells (Beschreibung der Umsetzung der funktionalen Anforderungen auf die Anwendungsdomäne). Die UML stellt für die verschiedenen Aktivitäten eine Reihe von Diagrammen zur Verfügung, die unterschiedliche Sichten auf das Gesamtsystem repräsentieren. Die Vorgehensweise dabei sollte iterativ und inkrementell sein. Folgende Aspekte sollen hier näher beschrieben werden: Analyse der Anforderungen - Anforderungsmodell und Analysemodell, Design – Erstellung der technischen Lösung unter Einbeziehung qualitativer Anforderungen (Wartbarkeit, Flexibilität, Leistungsfähigkeit etc.) und der Aspekt der iterativen inkrementellen Vorgehensweise. Analyse der Anforderungen. Ausgehend von einer Anforderungsspezifikation wird in der Analysephase ein Modell erstellt, das aufzeigt, wie die funktionalen Anforderungen durch die wesentlichen Objekte des Systems realisiert werden können - ohne dabei auf technische Details einzugehen. Dazu ist es empfehlenswert, falls nicht bereits im Rahmen der Anforderungsspezifikation geschehen, funktionale Anforderungen mit Hilfe von Anwendungsfällen (Use Cases) darzustellen. Diese Anwendungsfälle erlauben einen besseren Überblick über die Konsistenz und Vollständigkeit der Anforderungen. Außerdem sichern sie, dass Kunden und Entwickler das gleiche Verständnis der textuell erfassten Anforderungen haben. Neben der Spezifizierung dieser Anwendungsfälle werden in dieser Phase aus der Anwendungsdomäne die wesentlichen Objekte identifiziert. Im nächsten Schritt werden dann die einzelnen Aktivitäten der Anwendungsfälle den gefundenen Objekten zugeordnet. Nach Einarbeitung aller Anwendungsfälle steht ein erstes Modell der Software unter Berücksichtigung aller funktionalen Anforderungen zur Verfügung. Design. Ziel der Designphase ist es nun, aus dem Analysemodell unter Berücksichtigung der nichtfunktionalen Anforderungen (Wartbarkeit, Flexibilität, Leistungsfähigkeit, …) technische Lösungen zu definieren und damit das bestehende Modell zu überarbeiten und zu verfeinern. Dazu werden unter anderem Design- und Architekturpattern verwendet. Die wesentliche Aufgabe hierbei ist, diese sich teilweise widersprechenden Qualitätsanforderungen in den erlaubten Toleranzen zu vereinen. Beispiel: Bessere Wartbarkeit und Erweiterbarkeit stehen im Kontrast zu besserer Performance. Man kann nicht beide losgelöst voneinander optimieren. Als Produkt der Designphase entsteht ein vollständiges Modell, das als Ausgangspunkt für die Implementierung dient.

158

8 Anwendung von QSM in der Praxis

Iterative, inkrementelle Vorgehensweise. Die beschriebenen Phasen werden aber aus Gründen von Anforderungsänderungen und Testbarkeit nicht in Form eines Wasserfallmodells ausgeführt, sondern iterativ. Dabei entsteht am Ende jeder Iteration ein ausführbares Produkt und dieses wird mit den gestellten Anforderungen abgeglichen. In sehr frühen Phasen können diese Prototypen (z.B. für eine Machbarkeitsstudie) sein, später handelt es sich um Systeme, die eine Teilfunktionalität bereitstellen. Mit jeder weiteren Iteration kommt dann neue Funktionalität dazu bis das fertige Produkt erstellt ist. Das Produkt einer Iteration wird in diesem Zusammenhang als Inkrement bezeichnet. Diese Vorgehensweise hat den Vorteil, dass man frühzeitig mit der Testphase beginnen kann, da ein testbares System mit bestimmten Funktionalitäten bereits nach der ersten Iteration verfügbar ist. Grundsätzlich sollten risikobehaftete Funktionalitäten immer in den frühen Phasen umgesetzt werden, um ein realistisches Bild des Projektfortschritts zu bekommen. Einführungsstrategie

Zur Einführung einer objektorientierten Vorgehensweise mit UML sind verschiedene Aspekte von besonderer Bedeutung. Zum einen ist es notwendig, die Beteiligten im Team von den potentiellen Vorteilen für die Entwicklung zu überzeugen und Sie zu motivieren. Dabei ist eine Darstellung der Wechselwirkung zwischen Anforderungsmanagement, Analyse / Design und Implementierung wichtig. Da im Umfeld von mechatronischen Projekten sehr oft keine oder nur wenig Vorkenntnisse zu objektorientierter Softwaretechnologie vorhanden sind, sollten Schulungen und Coaching-Maßnahmen eingeführt werden. Für den Einsatz der UML als Mittel zur Beschreibung sollte ein entsprechendes Modellierungstool ausgewählt werden. Zeichen-Tools sind hier keine Alternative, da sie keine semantische Unterstützung gewährleisten. Die Auswahl des Tools hängt im Wesentlichen davon ab, wie gut es die Randbedingungen des Anwendungsgebietes unterstützt (z.B. Generierung von Code aus dem Modell in eine bestimmte Sprache). 8.7.3

Bewertung

Fachliche Bewertung

Fachlich gesehen sind objektorientierte Analyse und Design ein Ansatz zur Bewältigung komplexer Software durch die Zerlegung des Systems in interagierende Objekte. Objekte erleichtern die Kapselung und Wieder-

8.7 Objektorientierte Analyse und Design mit UML

159

verwendung von Inhalten. Dadurch werden Änderungen auf bestimmte Teilsysteme begrenzt. Eine konsequent durchgeführte Analyse und Designphase mit anschließender Implementierung erlaubt es, die Probleme auf dem jeweiligen Abstraktionsniveau zu lösen. Das heißt z.B., Entscheidungen über die grundsätzliche Struktur der Software fallen in der Analysephase und werden in der Designphase verfeinert. Die Implementierung hat darauf keinen Einfluss mehr. Im Gegensatz dazu bedeutet ein früherer Übergang in die Implementierung, dass dort alle Abstraktionsebenen vermischt und damit grundsätzliche Entscheidungen erschwert werden, da der Überblick verloren geht. Wirtschaftliche Bewertung

Der Umstieg auf eine objektorientierte Software-Entwicklung ist, wie jede Einführung einer neuen Technologie, mit initialen Investitionen verbunden. Weiterhin kann man auch nicht davon ausgehen, dass das erste Projekt schneller abgewickelt werden kann, da es eine Lernkurve bei den Beteiligten geben muss. Allerdings zeigt sich, dass ohne ein iteratives Vorgehen unter Einsatz objektorientierter Technologie eine Beherrschung der stetig komplexer werdenden Systeme nicht mehr möglich ist. Heutige Systementwicklungen müssen mit ständigen Änderungen der Anforderungen leben. Iteratives Vorgehen und leichte Änderbarkeit sind Grundvoraussetzungen dafür. Den wachsenden Qualitätsansprüchen bei verkürzten Entwicklungszeiten kann man nur gerecht werden, wenn man sich über die Auswirkung von Anforderungen und Änderungswünschen schnell und sicher bewusst werden kann. 8.7.4

Praktische Tipps

Folgende Punkte sind bei der Einführung von objektorientierter Analyse und Design mit UML wichtig: • • • • •

Mitarbeitermotivation und Schulung Konsequente durchgängige Umsetzung Unterstützung des Teams im ersten Projekt durch einen Experten Besondere Aufmerksamkeit auf die Schnittstellendefinition legen Verwendung eines UML Tools

160

8 Anwendung von QSM in der Praxis

8.8

Regressionstest (1)

Der Regressionstest ist ein Wiederholungstest. Bei jeder Softwareüberarbeitung wird der bereits durchgeführte Test der vorangegangenen Softwareversion wiederholt. Die Notwendigkeit des Regressionstests liegt darin begründet, dass bei einer Softwareüberarbeitung sehr leicht Fehler entstehen können, die mit der eigentlichen Softwareänderung in keinem direkten Zusammenhang stehen. Somit können Fehlfunktionen in bereits fehlerfrei getesteten Modulen entstehen. Da diese Fehler nicht oder nur sehr schwer vorhersehbar sind, muss der gesamte Test wiederholt werden. Bei einer manuellen Testwiederholung werden sich sehr schnell Ermüdungserscheinungen einstellen, die wiederum zu Fehlern führen können. Außerdem ist der Zeitaufwand bei einer manuellen Testwiederholung sehr groß und kaum akzeptabel. Daher muss die Testwiederholung automatisiert werden, z.B. mittels eines Typprüfstandes. Ein Typprüfstand ist nach DIN 2257 eine Prüfmaschine, bei der die Messwerterfassung, der Ablauf der Prüfung, die Prüfdatenauswertung und Entscheidung anhand der Prüfdaten ohne Bedienereingriff erfolgen. 8.8.1

Einsatzumfeld

Das Unternehmen

Die Firma Lenze AG ist ein mittelständisches Unternehmen der Antriebstechnik- und Automatisierungsbranche mit Hauptsitz in Groß Berkel und Bösingfeld. Zum Produktumfang der Lenze AG gehören Frequenzumrichter, Servoumrichter, Hardware und Softwarekomponenten zur dezentralen Automation, Getriebemotoren, Drehstrommotoren, Bremsen und Kupplungen. Die Lenze AG beschäftigt weltweit 3000 Mitarbeiter, davon 1960 Mitarbeiter im Inland. Im Bereich der Entwicklungsabteilung der Lenze Drive Systems GmbH sind 149 Mitarbeiter tätig, wobei ca. 50 Mitarbeiter im Softwarebereich tätig sind. Einsatzumfeld der Maßnahme

Der Regressionstest findet innerhalb der Softwareentwicklung im Bereich der Antriebstechnik statt und wird in den Entwicklungsklassen Produktentwicklung (intern und Kundenauftrag), Variantenentwicklung (intern und Kundenauftrag) und Anpassentwicklung durchgeführt. Diese entwicklungsbegleitenden Prüfungen, die Aufschluss über sämtliche Gerätefunktionen geben sollen, werden mit Hilfe von Systemprüfständen ausgeführt.

8.8 Regressionstest (1)

161

Die Freigabe von Gerätesoftware wird unter anderem vom erfolgreichen Durchlauf dieser Tests abhängig gemacht. Eine komplette Testreihe kann bis zu mehrere Tage dauern. Bei jeder Erweiterung oder Überarbeitung der Gerätesoftware wird der bestehende Regressionstest durchlaufen. Erweitert sich die Gerätefunktion, so wird auch der Regressionstest entsprechend erweitert. Erst wenn alle spezifizierten Gerätefunktionen implementiert sind und vom Regressionstest fehlerfrei überprüft wurden, erfolgt eine Freigabe der Gerätesoftware. 8.8.2

Vorgehensweise

Motivation für den Einsatz

Die Umstellung von analogen auf digitale Gerätereihen ließ nicht nur die Gerätefunktionalität rapide ansteigen, sondern auch den Testaufwand. Bei der kontinuierlichen Weiterentwicklung der Gerätesoftware stellte man fest, dass bereits abgetestete Gerätefunktionen sich nach einigen vorangeschrittenen Softwareversionen durch eingeschlichene Fehler nicht mehr spezifikationsgetreu verhielten. Das Testpersonal war somit gezwungen, Gerätefunktionen immer und immer wieder erneut zu verifizieren, was den Testaufwand und den damit verbunden Zeitaufwand explosionsartig ansteigen und die Motivation der Testperson eben so schnell absinken ließ. Im Jahre 1992 wurde daher beschlossen, die Typprüfung zu automatisieren. Die erste entwicklungsbegleitende, automatisiert verifizierte Gerätereihe war 1994 die Umrichterreihe 8200. Der Erfolg dieser Gerätereihe beruhte u.a. auf dieser entwicklungsbegleitenden automatischen Typprüfung, was zu einem stetigen Ausbau der Typprüfung in den folgenden Jahren führte. Anwendung

Der Regressionstest wird automatisiert mit einem intern entwickelten Testwerkzeug, dem Typprüfstand, durchgeführt. Der Typprüfstand bzw. Systemprüfstand besteht aus einen PC, der den Prüfablauf übernimmt, einer Steuereinheit, in der die digitalen und analogen Ein- und Ausgänge und die Niederspannungsversorgung untergebracht sind, einer Steuereinheit, in der die Leistungsschütze, die Messwertanzeigen und der Bremsregler enthalten sind und dem Lastsatz, auf dem sich gegenüberliegend die Motoren des Prüflings und des Bremsreglers befinden. Ferner besteht der Typprüfstand aus den Testcases bzw. Prüfdateien, die aneinandergereiht den Regressionstest für einen bestimmten Prüfling bilden und der Typprüf-

162

8 Anwendung von QSM in der Praxis

software, die das Handling und die Abarbeitung der Prüfdateien übernimmt. Die Typprüfung verifiziert die Funktionen eines Gerätes einer Gerätereihe, da die Funktionalität innerhalb einer Gerätereihe gleich ist. Diese Prüfung erfolgt an einem zur Leistungsklasse passenden Typprüfstand. Die Überprüfung der leistungsabhängigen Kenngrößen wird separat in einem Hardwaretest durchgeführt. Am Typprüfstand werden folgende Punkte geprüft: • die Zuordnung zwischen Eingängen, der Funktionalität und den Werten an den Ausgängen • das Beschreiben von Codestellen mit gültigen und ungültigen Werten • das Beschreiben von zugriffsgeschützten Codestellen • Befehle mit gültigen und ungültigen Parametern • die spezifikationstreue Funktionalität des Prüflings • die gegenseitige Beeinflussung von Operationen und Funktionen • das dynamische Verhalten • der Betrieb im Überlastbereich • Reaktionen auf simulierte Fehler Die Freigabe von Antriebsregler-Software wird vom erfolgreichen Durchlauf aller Testcases abhängig gemacht. Die Ergebnisdateien werden durch das Testpersonal ausgewertet, die gegebenenfalls auftretende Fehler in eine Mängeldatenbank eintragen. Sie bietet die Grundlage für eine erneute Überprüfung nach der Mängelbeseitigung. Diese reproduzierbaren Tests entsprechen der Nachweispflicht von DIN ISO 9000ff. Die durchgeführten Verifikationen sind reproduzierbar und können für neue Gerätereihen wiederverwendet werden. Bevor der Regressionstest am Systemprüfstand gestartet werden kann, muss dieser Test erst vom Testpersonal erstellt werden. Diese Erstellung erfolgt parallel zur Entwicklung des neuen Produktes, beginnend mit der Fertigstellung des Pflichtenheftes und der Spezifikation des Produktes. Aus diesen Dokumenten wird der Funktionsumfang des Produktes ermittelt. Jede Funktion wird als Arbeitspaket in einem Testplan aufgeführt. Neben der Funktionsbezeichnung besitzt jedes Arbeitspaket eine Nummerierung, einen Termin, einen Bearbeiter und einen Status. Anhand des Testplanes lässt sich jederzeit der Stand der Testdurchführung ermitteln. Nach der Erstellung des Testplanes erfolgt die Testvorbereitung. In dieser Phase wird überprüft, ob mit dem vorhandenen Testwerkzeug, in diesem Fall dem Systemprüfstand, alle Funktionen des neuen Produktes überprüft werden können. Bei Bedarf muss die Funktionalität des Systemprüfstandes erweitert werden. Eine weitere Aktivität in der Testvorbereitung ist

8.8 Regressionstest (1)

163

die Erstellung eines Prüfadapters, mit dem das neue Produkt mit all seinen Schnittstellen an die Schnittstellen des Systemprüfstandes angeschlossen wird. Sobald festgelegt ist, welche Schnittstellen des Systemprüfstandes verwendet werden, kann mit der Erstellung der Testfälle (Testcases) begonnen werden. Die Erstellung der Testcases bzw. Prüfdateien nimmt den größten Arbeitsaufwand innerhalb des Testprozesses ein und ist die eigentliche Erstellung des Regressionstests. Zu jedem Arbeitspaket des Testplanes werden je nach Funktionsumfang des Arbeitspaketes eine oder mehrere Prüfdateien erstellt. Eine Prüfdatei besteht aus einem Kopf, der für alle Prüfdateien eines Prüflings (Produkt) gleich ist und in dem der Einschaltvorgang und die Grundinitialisierung durchgeführt werden. Im Mittelteil der Prüfdatei werden die spezifischen Testcases programmiert, mit denen die angegebene Funktion des Prüflings abgetestet wird. Am Ende jeder Prüfdatei kommt analog zum Kopf der Fuß, bei dem das Gerät wieder die Grundinitialisierung erhält und ausgeschaltet wird. Der Aufbau jeder Prüfdatei ist tabellenartig im dBase Format hinterlegt. Die Programmierung der Prüfdateien erfolgt mit einem selbst erstellten Befehlssatz, der kontinuierlich erweitert wird. Hinter jedem Prüfbefehl steckt innerhalb der Typprüfsoftware eine beliebig umfangreiche C-Prozedur. Nach dem Öffnen der Prüfdatei durch die Typprüfsoftware werden die Kommandos der Prüfdatei zeilenweise abgearbeitet und mittels der aufgerufenen C-Prozeduren in z.B. Schreib- oder Lesebefehle der digitalen Ein- und Ausgänge des Systemprüfstandes umgesetzt. Je nach Funktionsumfang des Prüflings können bis zu mehrere hundert Prüfdateien entstehen. Zur besseren Übersicht werden ca. 20 Prüfdateien zu einer Testablauftabelle zusammengefasst. Die Testablauftabellen wiederum werden zu einem Kompletttest für die Verifikation eines Prüflings zusammengeführt. Bei jeder Softwareänderung wird der Kompletttest gestartet. Jeder Prüfschritt und jeder aufgetretene Fehler werden protokolliert. Somit erkennt man sofort die Abweichungen zum vorherigen Softwarestand. In den letzten Wochen vor der Softwarefreigabe wird der Kompletttest täglich gestartet. Auf diese Weise werden auch sporadisch auftretende Fehler aufgedeckt. Hat man einen solchen sporadischen Fehler an einer Testsequenz festgemacht, werden spezielle Prüfdateien mit dieser Testsequenz programmiert und z.B. 1000-fach wiederholt. Diese Dauertests werden dem Kompletttest hinzugefügt. Ziel ist, dass bis zur Softwarefreigabe alle Prüfdateien fehlerfrei durchlaufen. Um der Nachweispflicht nachzukommen, wird zu jedem Arbeitspaket des Testplans ein Bericht verfasst. Dieser Bericht wird mittels eines Formblatts erstellt, auf dem alle notwendigen Angaben (Arbeitspaket, Testdurchführung Geräteidentifikation, Bearbeiter und Bewertung) enthalten

164

8 Anwendung von QSM in der Praxis

sind. Wenn die Prüfdatei und der Testbericht erstellt sind, kann das Arbeitspaket als erledigt gekennzeichnet werden. Ziel ist, dass zur Softwarefreigabe alle Arbeitspakete erledigt sind. Softwarefehler, die zur Serienfreigabe nicht beseitigt werden und nach einer Bewertung in der Software verbleiben können, werden in einer Mängeldatenbank bis zur Fehlerbeseitigung beim nächsten Update archiviert. Die Entscheidung, ob ein bekannter Fehler in der Software verbleiben kann, trifft der Projektleiter. Bei jeder Softwareüberarbeitung wird die Mängeldatenbank bzgl. bereits bekannter Fehler überprüft und erneut bewertet, ob der jeweilige Fehler aktuell beseitigt werden soll. Parallel zur Softwareüberarbeitung wird der Kompletttest wiederholt und bei einer Funktionserweiterung der Software entsprechend erweitert. Einführungsstrategie

Die Einführung des automatisierten Regressionstests hat zwei Aufgabenschwerpunkte. Zum einen muss ein modulares und funktionales Testwerkzeug aufgebaut werden und zum anderen muss eine geeignete Teststrategie entwickelt werden. Die Funktionalität des Testwerkzeugs richtet sich nach der Funktionalität des Prüflings. Auf dem freien Markt wird man in der Regel kein Testbett finden, das diesen Anforderungen genügt. Man wird daher das Testwerkzeug intern entwickeln müssen oder eine externe Firma damit beauftragen. In beiden Fällen entstehen zunächst recht hohe Kosten, die aber durch die Qualitätssteigerung des Prüflings relativiert werden. Da das Testwerkzeug erfahrungsgemäß ständig erweitert wird, um mit dem Prüfling mitzuwachsen, empfiehlt es sich, das Testwerkzeug intern zu entwickeln und festes Personal dafür bereitzustellen. Somit hat man ständig die Quellen und das Know-how zur Verfügung. Die Entwicklung des Testwerkzeugs sollte mit Ausblick auf zukünftige Prüflingsgenerationen durchgeführt werden, damit das Testwerkzeug und der Regressionstest auch für zukünftige Produktentwicklungen genutzt werden kann. Zu einer erfolgreichen Teststrategie gehören die Schaffung des separaten Testpersonals und die Erstellung von Programmierrichtlinien für Testfälle. Das Testpersonal erstellt entwicklungsbegleitend die notwendigen Testfälle anhand der Programmierrichtlinien für Testfälle und anhand der Spezifikation der Prüflingsfunktion. Bei der Erstellung der Testfälle sollte man daran denken, dass man bei einer Änderung des Prüflings alle Testfälle überarbeiten muss oder dass man im Fehlerfall die Historie bis zum Fehlerfall reproduzieren muss. Die Testfälle sollten daher modular und sinnvoll gekapselt programmiert werden. Man muss sicherstellen, dass die

8.8 Regressionstest (1)

165

Testfälle auch zu einem späteren Zeitpunkt mit dem ursprünglichen Prüfling die gleichen Ergebnisse liefern. 8.8.3

Bewertung

Fachliche Bewertung

Der automatisierte Regressionstest mittels des Systemprüfstands hat sich zu dem wichtigsten Testwerkzeug bei der Softwareverifikation entwickelt. Es findet keine Softwarefreigabe statt, ohne dass die Software am Systemprüfstand überprüft wurde. Durch den modularen Aufbau der Systemprüfstände kann die Funktionserweiterung beliebig fortgeführt werden, um sich an jeden Prüfling anzupassen. Wirtschaftliche Bewertung

Die Investition in die automatische Typprüfung hat sich mehrfach rentiert. Aufgrund der gestiegenen Softwarequalität treten weniger Fehlerkosten auf. Die Kosten bei der Softwareverifikation sind kalkulierbar. Die Systemprüfstände werden daher kontinuierlich ausgebaut. 8.8.4

Praktische Tipps

Folgende Tipps können für den Regressionstest gegeben werden: • Automatisieren Sie den Regressionstest. • Erstellen Sie die Testwerkzeuge, die am Markt nicht zur Verfügung stehen, mit eigenen Mitarbeitern. • Erstellen Sie eine Programmierrichtlinie für Testfälle.

166

8 Anwendung von QSM in der Praxis

8.9

Regressionstest (2)

Um Softwaretests effizient und reproduzierbar zu machen, müssen automatische Testverfahren verwendet werden. Für diese Testverfahren ist es unabdingbar, das Geräteverhalten bzw. die Eigenschaften des Gerätes in einer strukturierten Form zu beschreiben. Ebenso unabdingbar ist die Forderung, dass die einzelnen Testabläufe reproduzierbar gestaltet sind. Damit wird es möglich, mit vertretbarem Zeitaufwand eine Softwareprüfung nach einer Softwareänderung automatisch zu wiederholen. 8.9.1

Einsatzumfeld

Das Unternehmen

Die Endress+Hauser Gruppe ist ein Anbieter von Messgeräten und Automatisierungslösungen für die Verfahrenstechnik (unter anderem für Chemie und Petrochemie, Pharma, Lebensmittel, Wasser und Abwasser, Papier, Energie, Öl und Gas). Die Gruppe umfasst heute 24 Produktionsgesellschaften in 9 Ländern, 42 eigene Vertriebs- und Servicegesellschaften in 36 Ländern, sowie 7 Verwaltungsgesellschaften. Sie wird von einer Holding mit Sitz in Reinach (Schweiz) gesteuert. Bei der Endress+Hauser GmbH+Co. KG in Maulburg sind zurzeit ca. 1340 Mitarbeiter beschäftigt. Hauptarbeitsgebiete sind die Entwicklung und Produktion von Füllstand-, Druck- und Differenzdruckmessgeräten. Dabei werden folgende Messprinzipien angewandt: • Füllstand: kapazitiv, konduktiv, hydrostatisch, radiometrisch, Ultraschall, Mikrowelle, Mikroimpulse, Lotsystem, Vibration • Druck: kapazitiv, piezoresistiv Einsatzumfeld der Maßnahme

Der Innovationsprozess Füllstand, innerhalb dessen die beschriebene Methode entwickelt und verwendet wurde, ist in Form einer Matrix organisiert. Hierbei sind die zu den jeweiligen Messprinzipien (Ultraschall, Mikrowelle, Mikroimpuls etc.) zugehörigen Kompetenzen in Projektteams zusammengefasst. Bestimmte übergreifende Funktionen wie „Technische Sicherheit“ oder auch die Softwareentwicklung sind quer dazu angeordnet. Im Bereich der Entwicklung für kontinuierlich messende Füllstandsgeräte sind ca. 100 Mitarbeiter tätig, wobei etwa 25 Mitarbeiter im Softwarebereich tätig sind.

8.9 Regressionstest (2)

167

Die beschriebene Maßnahme kommt nach Generierung einer für die Projektteams vorgesehenen Softwareversion zum Einsatz. Der Test wird innerhalb der Software-Entwicklung vor Auslieferung an die Projektteams durchgeführt. 8.9.2

Vorgehensweise

Motivation für den Einsatz

Um die Verifizierung eines Messgerätes vornehmen zu können, ist der systematische Test eine unabdingbare Voraussetzung. Im Innovationsprozess Füllstand der Endress+Hauser GmbH+Co. KG wird hierzu der Classification Tree Editor (CTE) verwendet. CTE wurde in Zusammenarbeit mit der DaimlerChrysler AG von ATS (Berlin) entwickelt. Anwendung

Das CTE-Werkzeug dient der grafischen, strukturierten Darstellung aller Anforderungen und Parameter des Gerätes. Ebenso werden mit diesem Werkzeug alle Testfälle beschrieben. Dabei bietet CTE verschiedene Möglichkeiten, das erstellte Dokument auf Konsistenzfehler zu prüfen. CTE lässt sowohl Testfälle als auch Testsequenzen, die in einzelne Testschritte aufgeteilt sind, zu. CTE hat folgende Ausgabeformate: • Graphische Darstellung aller Eigenschaften und Parameter in einem Klassifizierungsbaum • Textuelle Ausgabe (HTML oder ASCII) aller Testfälle, Testsequenzen und Testschritte • Textuelle Ausgabe aller Elemente des Klassifizierungsbaumes Die textuelle Ausgabe der Testfälle, Testsequenzen und Testschritte werden durch das selbsterstellte Übersetzungsprogramm CTE2QsDevice weiterverarbeitet. Um die Verbindung zu QsDevice herzustellen, wird in jedem Element des Klassifizierungsbaumes im Feld Specification mindestens eine Basisfunktion aufgerufen. Es sind auch Kombinationen aus mehreren solcher Basisfunktionen möglich. Falls erforderlich können diese Funktionen auch in zusätzlichen C-Code eingebunden sein. So kann eine solche Basisfunktion innerhalb einer Schleife mehrfach aufgerufen werden. Der Benutzer wird in beiden Phasen, d.h. beim Entwurf des Klassifikationsbaums und bei der Definition von Testfällen in der zu dem Baum gehörenden Kombinationstabelle, durch den CTE unterstützt (Abb. 8.6).

168

8 Anwendung von QSM in der Praxis

Dafür verfügt der Editor über zwei auf die jeweilige Aktivität spezialisierte Arbeitsbereiche, in denen der Baum und die Tabelle interaktiv bearbeitet werden: • Die Klassifikationsbaum-Zeichenfläche und • die Kombinationstabelle mit dem Testfall-Listenfeld. Die syntaktischen Regeln der Klassifikationsbaum-Methode sind in dem CTE umgesetzt. Dadurch wird das Erlernen und das Verständnis für die Methode gefördert. Die Kombinationstabelle wird automatisch aus dem erstellten Klassifikationsbaum abgeleitet.

Abb. 8.6. CTE-Editor

Testsequenzen dienen als Zusammenfassung mehrerer Testschritte, die einen in sich abgeschlossenen Testablauf darstellen. Ein Beispiel einer solchen Zusammenfassung ist die Überprüfung von Editiergrenzen. Jede Testsequenz sollte so gestaltet sein, dass sie für sich lauffähig ist.

8.9 Regressionstest (2)

169

Innerhalb der Testsequenz werden folgende Properties verwendet: • „Name“ beschreibt den in dieser Sequenz zusammengefassten Testablauf. Der Name sollte kurz gehalten sein, aber trotzdem die dahinter stehende Testsequenz möglichst gut beschreiben. Für den besseren Überblick ist es ratsam, die einzelnen Testsequenzen mit eindeutigen Namen zu versehen. Es wird aber weder durch CTE noch durch den Precompiler vorgeschrieben. • „Description“ kann jeden beliebigen C-kompilierbaren Code beinhalten. Im Allgemeinen sollte der sich aber auf das Initialisieren der zur Verfügung stehenden globalen Variablen beschränken. Dieser Code wird vom Precompiler so eingefügt, dass er zu Beginn der Testsequenz ausgeführt wird. An dieser Stelle sollten die globalen Variablen initialisiert werden, die sich innerhalb der Testsequenz nicht ändern. Der Testschritt bietet die Möglichkeit, innerhalb einer Testsequenz eine logische, hauptsächlich aber eine zeitliche Aufteilung vorzunehmen. Innerhalb des Testschrittes werden folgende Properties verwendet: • „Name“ beschreibt den in diesem Step zusammengefassten Testablauf. Der Name sollte kurz gehalten sein, aber trotzdem den dahinter stehenden Teststep möglichst gut beschreiben. Für den besseren Überblick ist es ratsam, die einzelnen Teststeps mit eindeutigen Namen zu versehen. Es wird aber weder durch CTE noch durch den Precompiler vorgeschrieben. • „Description“ kann jeden beliebigen C-kompilierbaren Code beinhalten. Im Allgemeinen sollte der sich aber auf das Initialisieren der zur Verfügung stehenden globalen Variablen beschränken. Dieser Code wird vom Precompiler so eingefügt, dass er zu Beginn des Teststeps ausgeführt wird. An dieser Stelle sollten die Variablen initialisiert werden, deren Werte nur für diesen Teststep bzw. für die nachfolgenden Teststeps in dieser Sequenz Gültigkeit haben. Als Outputformat aus CTE heraus wird das von CTE angebotene Export Format Text verwendet. Im Untermenü Options-ÆExport müssen hierzu in der Registerkarte „Text“ alle Checkboxen angewählt werden. Das Ausgabeformat von CTE muss anschließend in eine Ccompilierbare Form gebracht werden. Hierzu wird die Ausgabedatei von CTE ausgewertet und in ein *.cpp-File übersetzt. Diese Datei wird dann in das C++-Projekt QsDevice eingebunden. QsDevice ist ein ausführbares Windows Programm, das alle erstellten Testfälle durchspielt. Dabei wird jede Aktion in der *.log-Datei gespeichert. Ermittelt ein Testelement eine Abweichung vom Sollzustand, wird

170

8 Anwendung von QSM in der Praxis

der Eintrag durch das Schlüsselwort !ERROR erweitert. Ebenso wird eine kurze Beschreibung des Fehlers angefügt. QsDevice ist ein Visual C++-Projekt, das im Wesentlichen aus den Modulen Programmrumpf, Basisfunktionen und Testablauf besteht, die im Folgenden näher behandelt werden. Programmrumpf. Dieser Teil des Projektes beschreibt den Frame , sowie die Hauptbestandteile der Datenausgabe und die Schnittstelle zum DDE Hart Server. Basisfunktionen. Im Folgenden sind eine Reihe von Basisfunktionen dargelegt. • V,H: Matrixposition, die Funktion wird ausgeführt, wenn beide Werte größer 0 • Wert: Der zu schreibende oder zu lesende Wert • Einheit: Die Einheit, die das Gerät erwartet in Hart Unit Code • Flag: Geschriebenen Wert durch Auslesen prüfen TRUE/FALSE • Index: Parameter Index, die Funktion wird ausgeführt, wenn Inhalt <> NO_INDEX • *String: Zeiger auf einen Null terminierten String • Abweichung: Maximal zulässige Abweichung Die Basisfunktionen umfassen folgende grundsätzliche Aktionen: • • • • • •

Schreiben eines Parameters Validieren eines Parameters Lesen von Parametern Überprüfung der Editiergrenzen Überprüfung des Lock Status eines Parameters Ausgabe einer Message Box

Testablauf. Dieses Modul enthält die Aufrufe der Basisfunktionen, die aus den Testfällen generiert werden. Hierzu werden die Aufrufe der Basisfunktionen hintereinander gereiht. Diese Datei wird durch Precompiling mit CTE to QsDevice (Cte2QsDevice) aus der CTE Ausgabedatei generiert. Einführungsstrategie

Bei der erstmaligen Einführung eines automatisierten Black-Box-Tests muss ein relativ hoher Aufwand getrieben werden. Die Investitionen in das verwendete Tool (incl. Schulung), sowie die Erstellung der Testroutinen erfordern einen nicht unerheblichen Budgetrahmen.

8.9 Regressionstest (2)

171

In dieser Phase ist es wichtig, die Vorteile des zu erstellenden Systems transparent darzustellen. Die einmalig auftretenden Kosten amortisieren sich im Verlauf des Produktlebenszyklus, da bei jeder vorgenommenen Änderung ein recht umfangreicher Test mit dann überschaubarem Aufwand automatisiert durchgeführt werden kann. Nur noch die Änderungen müssen in Form neuer Testfälle bzw. in Anpassung vorhandener Testfälle umgesetzt werden. Weiterhin ist hohe Priorität auf die Möglichkeit der Wiederverwendung der zu erstellenden Testroutinen zu legen. In verschiedenen Messgeräten wiederkehrende Funktionalitäten dürfen nur einmal ausprogrammiert werden (Abgleich, Stromausgang, Linearisierung etc.). Um die Wiederverwendung der Testroutinen weiter zu fördern, sollte die Erstellung und Pflege des Test-Tools von einer eigenständigen Testgruppe vorgenommen werden. Bei Einführung dieser Testgruppe innerhalb der eigenen Organisationseinheit, ist eine flexible und schnelle Reaktion im Fehlerfall sichergestellt. 8.9.3

Bewertung

Fachliche Bewertung

Das beschriebene Verfahren wurde für Geräte der Füllstandsmesstechnik entwickelt und erfolgreich eingesetzt. Auf Grund seines modularen Aufbaus und seiner vom Messprinzip unabhängigen Vorgehensweise lässt es sich jedoch auch für alle anderen Produkte der industriellen Messtechnik einsetzen. Durch ein automatisiertes Testverfahren können im Vergleich zu einfachen manuellen Testverfahren neu entstandene Softwareversionen zuverlässiger auf Fehler untersucht und schneller dem Kunden zur Verfügung gestellt werden. Durch die Strukturierung und Modularisierung der GeräteSoftware werden Abhängigkeiten und Einflüsse zwischen verschiedenen Betriebszuständen und Funktionen zwar weitgehend ausgeschlossen, jedoch sind durch die hardwarenahe und hardwareabhängige Programmierung immer Fehlerquellen möglich, die durch den Regressionstest aufgedeckt werden können. Wirtschaftliche Bewertung

Der Einsatz des beschriebenen Verfahrens erhöht deutlich die Zuverlässigkeit und damit die Qualität der erstellten bzw. geänderten Geräte-Software. Insbesondere bei Änderungen werden die Vorteile einer reproduzierbaren,

172

8 Anwendung von QSM in der Praxis

automatisierten Vorgehensweise offensichtlich. Ein manueller Test mit gleicher Testtiefe würde ein Vielfaches der eingesetzten Ressourcen benötigen. Ein weiterer Aspekt ist die „time to market“ die deutlich reduziert werden kann. 8.9.4

Praktische Tipps

Um die Komplexität des CTE Ausgabeformates in sinnvollen Grenzen zu halten und damit den Precompiler Cte2QsDevice überschaubar zu halten, wurde ein Subset der von CTE zur Verfügung gestellten Elemente definiert.

8.10 Review-Techniken

173

8.10 Review-Techniken In der Softwareentwicklung haben Reviews ihren festen Platz und gehören in ihren verschiedenen Ausprägungen, ebenso wie Testverfahren, zu den analytischen Methoden. Allen Review-Arten gemeinsam ist, dass Dokumente einer anderen Person als dem Autor zur Prüfung vorgelegt werden. Abhängig vom Formalisierungsgrad werden typischerweise folgende in Tabelle 8.3 dargestellte Ausprägungen von Reviews durchgeführt: Tabelle 8.3. Review-Arten Review-Art

Beschreibung

Aufwand

Ad-Hoc Review

Der Autor eines Dokuments bittet spontan einen Kollegen um einen Kommentar zu einer bestimmten Textpassage. Ein Prüfer erhält das Dokument vom Autor, liest es kritisch durch und gibt es mit seinen Anmerkungen zurück. Mehrere Prüfer führen gleichzeitig einen Schreibtischtest durch. Der Autor sammelt die Ergebnisse und gleicht sie gegeneinander ab. Zwei Projektmitglieder bearbeiten gemeinsam am selben Arbeitsplatz dasselbe Dokument. Der Autor erläutert sein Dokument mehreren Prüfern im Rahmen einer gemeinsamen Sitzung. Die Prüfer erhalten das Dokument vorab und führen jeder für sich die Prüfung durch. Anschließend werden in einer gemeinsamen, moderierten Sitzung die Ergebnisse besprochen und protokolliert. Nach einer gemeinsamen Sitzung zur Einführung in die Thematik wird ein Team Review durchgeführt. Die Bearbeitung der gefundenen Punkte wird überprüft. Es wird eine Inspektion durchgeführt. In der Reviewsitzung dürfen auch Verbesserungsvorschläge diskutiert werden.

gering

Schreibtischtest

Umlauf

Pair Programming Walkthrough Team Review

Inspektion

Ausführliches Review

hoch

174

8 Anwendung von QSM in der Praxis

8.10.1 Einsatzumfeld Das Unternehmen

Die method park Software AG mit Sitz in Erlangen ist ein mittelständisches Software-Haus mit zurzeit ca. 40 Mitarbeitern. method park unterstützt seine Kunden durch Beratungsdienstleistungen zu Themen aus dem Software-Engineering, eigene Produkte (C-Codegenerator aus UMLDiagrammen sowie ein Prozessmanagement-Werkzeug) sowie durch Software-Entwicklungsdienstleistungen. Ein Großteil der Kunden und Kooperationspartner von method park sind im Embedded-Umfeld tätig. Typische Zielbranchen sind Automobilhersteller und -zulieferer, Medizintechnik, Consumer Electronics, Maschinenbau und Industrieautomatisierung. Einsatzumfeld der Maßnahme

Reviews werden in allen Phasen und auf alle Ergebnistypen der SoftwareEntwicklung angewendet. Gerade in frühen Phasen sind sie das Mittel der Qualitätssicherung schlechthin, wenn andere QS-Maßnahmen, z.B. mangels existierender lauffähiger (Teil-) Systeme, noch gar nicht verwendet werden können. Reviews als eine Form des manuellen Prüfens durch Menschen können zu diesem Zeitpunkt sehr wohl genutzt werden, um Fehler in Entwicklungsergebnissen zu finden. Während es bei nicht eingeplanten Review-Tätigkeiten – im Folgenden als Reviews mit niedrigem Formalisierungsgrad beschrieben – vor allem um das Feedback von Kollegen zur eigenen Arbeit geht, sind eingeplante Review-Tätigkeiten wesentlicher Bestandteil der Qualitätssicherung und Grundlage für die Freigabe von Entwicklungsergebnissen. 8.10.2 Vorgehensweise Motivation für den Einsatz

Jeder Fehler, der in einer frühen Entwicklungs-Phase durch ein Review gefunden und anschließend korrigiert wird, verursacht um Größenordnungen geringere Kosten verglichen mit seiner Entdeckung im Test. D.h. Reviews können – z.B. im Gegensatz zu dynamischen Software-Tests – bereits in sehr frühen Phasen der Entwicklung angewendet werden und verursachen dabei im Vergleich zu anderen Software-Qualitätssicherungsmaßnahmen nur geringe Kosten. Ein weiterer Aspekt für Reviews ist, dass diese auch der Schulung der Projektmitglieder, d.h. insbesondere z.B. neu-

8.10 Review-Techniken

175

er Mitarbeiter, und damit dem Wissensmanagement dienen. Reviews können somit Synergien im Projektteam entstehen lassen. Anwendung

Review-Techniken mit niedrigem Formalisierungsgrad. Typisch für Reviews mit niedrigem Formalisierungsgrad ist, dass es sich dabei in der Regel nicht um geplante Tätigkeiten handelt. Der Zeitaufwand für die Durchführung der Reviews ist daher nicht vorgesehen und es erfolgt auch keine direkte Finanzierung im Rahmen eines Projektbudgets. Auch eine Nachverfolgung der Behebung der von den Prüfern gefundenen Mängel und Fehler erfolgt nicht. Ein Ad-Hoc Review findet immer dann statt, wenn ein Autor eines Dokumentes einen anderen Kollegen bittet, „mal schnell“ über eine bestimmte Textpassage zu lesen und ihm seine Meinung mitzuteilen. Bereits hier profitiert der Autor vom anderen Blickwinkel seines Kollegen, der zur Entdeckung von Fehlern führt, die der Autor ansonsten übersehen hätte. Sollen längere Textpassagen oder das ganze Dokument geprüft werden, so wird der Autor das Dokument einem Kollegen zum Schreibtischtest vorlegen. Der Prüfer liest das Dokument kritisch durch und versieht es mit seinen Anmerkungen. Alternativ ist auch die Erstellung eines ReviewProtokolls möglich. Im Anschluss diskutieren Autor und Prüfer über die Anmerkungen des Prüfers. Mit der Durchführung eines Umlaufs wird vermieden, dass das Prüfungsergebnis von einer einzelnen Person abhängt. Beim Umlauf wird das zu prüfende Dokument an mehrere Prüfer verteilt, die dann parallel einen Schreibtischtest durchführen. Vorteil dieses Vorgehens ist, dass durch den Einsatz mehrerer Prüfer auch deutlich mehr Fehler entdeckt werden. Review-Techniken mit mittlerem Formalisierungsgrad. ReviewTechniken mit mittlerem Formalisierungsgrad stellen geplante Aktivitäten dar. Der resultierende Zeitaufwand ist damit von vorneherein vorgesehen und durch das Projektbudget abgedeckt. Eine Nachverfolgung der Behebung von Fehlern und Mängeln fehlt (Walkthrough) bzw. erübrigt sich (Pair Programming). Beim Walkthrough präsentiert der Autor den Inhalt seines Dokuments einem Team von Prüfern während einer gemeinsamen Sitzung. Die Prüfer werden ausschließlich während der Reviewsitzung mit dem Prüfling konfrontiert. Eine Vorbereitung findet nicht statt. Von den Prüfern führt einer das Review-Protokoll und hält dort die Ergebnisse der Sitzung fest. Aufgrund der fehlenden Vorbereitung ist diese Art des Reviews weniger gut geeignet, um Mängel und Fehler im Dokument zu finden. Ein weiterer

176

8 Anwendung von QSM in der Praxis

Nachteil des Walkthroughs: Der Autor kann aufgrund seiner dominanten Rolle die anderen Teilnehmer „blenden“. Dieser Mangel lässt sich etwas ausgleichen, indem für die Sitzung ein Moderator bestimmt wird. Auf der anderen Seite stellt das Walkthrough ein gutes Mittel dar, um andere Mitglieder des Projektteams mit den Inhalten des Dokuments vertraut zu machen. Eine ganz andere Art, Reviews durchzuführen, stellt Pair Programming dar. Diese Technik ist Bestandteil des „Extreme Programming“. Die Grundidee von Pair Programming besteht darin, das Review in die Erstellungsphase des Dokuments zu verlegen. Während eines fest vorgegebenen Zeitraums sitzen zwei Mitglieder des Projektteams an einem Arbeitsplatz zusammen und bearbeiten gemeinsam ein bestimmtes Dokument. Dies geschieht üblicherweise so, dass einer von beiden den Text eingibt, während der andere dabei die Rolle des Beobachters einnimmt. Während der Bearbeitung des Dokuments stimmen sich beide fortwährend über den Inhalt des Dokuments ab. Nach einer Weile wechseln beide, so dass derjenige, der zunächst Beobachter war, den Text eingibt und der andere die Rolle des Beobachters einnimmt. Durch die intensive Zusammenarbeit wird erreicht, dass beide Bearbeiter des Dokuments dasselbe Verständnis bezüglich seines Inhalts besitzen und die Qualitätssicherung quasi in den Erstellungsprozess „eingebaut“ ist. Review-Techniken mit hohem Formalisierungsgrad. Review-Techniken mit hohem Formalisierungsgrad („Formale Reviews“) lassen sich am besten durch Workflows beschreiben. In diesem Fall sind also die daraus entstehenden Aufwände durch das Projektbudget abgedeckt. Die Planung von formalen Reviews ist auch notwendig, denn der damit verbundene Aufwand kann nicht mehr vernachlässigt werden. Er liegt typischerweise bei ca. 10% des Aufwandes für die Dokumenterstellung. Auf der anderen Seite liefern formale Reviews die besten Ergebnisse beim Finden und Korrigieren von Fehlern und Mängeln. Allen formalen Reviews ist darüber hinaus gemeinsam, dass das zu prüfende Dokument, falls vorhanden, gegen das Vorgängerdokument und auf der Grundlage von unternehmens- oder projektweiten Richtlinien und Standards geprüft wird. Das Review wird außerdem häufig anhand von Checklisten durchgeführt. Mit dem geringsten Aufwand in dieser Kategorie verbunden ist das Team Review. Der Aufwand ist zwar höher als beim einfachen Schreibtischtest, jedoch erreicht man durch die Einbeziehung von mehreren Prüfern eine höhere Fehlererkennungsrate. Aus den oben genannten ReviewAktivitäten werden im Wesentlichen nur die Vorbereitung, die eigentliche Reviewsitzung und die nachfolgende Überarbeitung durchgeführt. Die

8.10 Review-Techniken

177

Einführung in die Thematik sowie die Nachverfolgung und das Nachdenken über Verbesserungsmöglichkeiten spielen nur eine untergeordnete Rolle. Die typischen Aktivitäten in formalen Reviews sind in Tabelle 8.4 dargestellt: Tabelle 8.4. Aktivitäten in formalen Reviews Aktivität

Ausprägung

Planung

Planung bezüglich Zeit und Ressourcen für die folgenden Schritte Einführung in die Thematik, Verteilung der Unterlagen Vorbereitende Prüfung der Unterlagen durch die einzelnen Prüfer Gemeinsame Reviewsitzung, Protokollierung der Resultate Überarbeitung des Prüflings Nachdenken über Verbesserungsmöglichkeiten im Prozess Überprüfung, ob und in welchem Umfang die Überarbeitung stattgefunden hat

Einführung Vorbereitung Reviewsitzung Überarbeitung Verbesserung Nachverfolgung

Die Inspektion ist formaler als das Team Review. Alle oben genannten Schritte werden ausgeführt, aber durch eine ausgeklügelte Rollenverteilung (siehe auch „Praktische Tipps“), die sorgfältige Vor- und Nachbereitung sowie den Gedanken der ständigen Prozessverbesserung in der Inspektion werden wesentlich höhere Fehlerentdeckungsraten erzielt als bei den weniger formalen Review-Arten. Damit ist die Inspektion auch diejenige Review-Art mit der größten qualitätssteigernden Wirkung. Das ausführliche Review entspricht vom Ablauf her der Inspektion, jedoch ist im Gegensatz hierzu die Diskussion von Verbesserungsvorschlägen in der gemeinsamen Reviewsitzung erlaubt. Dies hat den Vorteil, dass durch das Zusammenwirken der Review-Teilnehmer Ideen entstehen können, die ein einzelner nicht hätte entwickeln können. Der Nachteil von ausführlichen Reviews ist jedoch, dass sich zwangsläufig ein relativ hoher Zeitbedarf ergibt. Rollen in Review-Sitzungen. Die beiden grundlegenden Rollen bei Reviews sind die des Autors und die des Prüfers. Bei allen Review-Arten, bei denen im Rahmen einer gemeinsamen Reviewsitzung ein Protokoll erstellt wird, kommt die Rolle des Protokollführers hinzu, die bei den weniger formalen Review-Arten, wie z. B. dem Walkthrough, auch von einem Prüfer wahrgenommen werden kann. Eine weitere wichtige Rolle ist die des Moderators, die im Walkthrough und explizit in allen Review-Arten mit

178

8 Anwendung von QSM in der Praxis

hohem Formalitätsgrad vorkommt. Die Aufgabe des Moderators ist es, für den geordneten Ablauf der Reviewsitzung zu sorgen. Insbesondere ist er dafür verantwortlich, dass das Gesprächsklima konstruktiv bleibt und lange ergebnislose Diskussionen unterbleiben. Einführungsstrategie

Bei Reviews mit niedrigem Formalisierungsgrad ist keine Einführungsstrategie notwendig, es geht einfach um die intuitive Umsetzung. Die Erkenntnis, dass das 4-Augen-Prinzip wichtig und sinnvoll ist, muss vorhanden sein. Auch bei den anderen Review-Techniken geht es nicht – im Gegensatz zu einigen anderen qualitätssichernden Maßnahmen – um die Einführung von neuen, großartigen Werkzeugen, sondern um die Veränderung von existierenden Arbeitsweisen. Damit sind also oft rein menschliche Faktoren Erfolgs- oder auch Misserfolgsfaktoren für Reviews. Wichtige Hinweise zur Umsetzung von Reviews können direkt aus dem Abschnitt „Praktische Tipps“ abgelesen werden. Organisatorisch können Reviews vor allem durch die folgenden Punkte unterstützt werden: • • • •

Existenz von Dokumentvorlagen für Reviews Existenz von Review-Checklisten für spezielle Dokumenttypen Explizite Planung von Review-Aktivitäten durch den Projektleiter Konsequentes Umsetzen der Review-Tätigkeiten, bevor das zu bewertende Projektergebnis freigegeben wird (auch wenn die Zeit im Projekt knapp wird)

8.10.3 Bewertung Fachliche Bewertung

Gerade in frühen Phasen stellen Reviews oft das einzige und gleichzeitig einfachste Mittel dar, um die Qualität von Entwicklungsergebnissen (hier meist noch Pflichtenhefte oder Designdokumente) zu überprüfen. Jede Art von für Menschen lesbaren Dokumenten lassen sich von diesen auch analysieren und bewerten, ohne beispielsweise – eventuell mit erheblichen Aufwand – Prüfprozeduren, Simulationen oder ähnliches realisieren zu müssen.

8.10 Review-Techniken

179

Wirtschaftliche Bewertung

Reviews sind ein sehr effizientes qualitätssicherndes Mittel, um Projektergebnisse durch Kollegen zu prüfen. Auch wenn der Aufwand von formalen Reviews durchaus 10% des Erstellungsaufwandes eines Projektergebnisses bedeuten kann, steht diese Zahl in keinem Verhältnis zum typischerweise exponentiell wachsenden Kostenverlauf, wenn ein Fehler unentdeckt bleibt. Gerade in frühen Phasen stellen Reviews damit eine vergleichsweise kostengünstige Vorgehensweise dar, um Fehler zu finden. 8.10.4 Praktische Tipps

Mehrere Prüfer – Mehrere Sichten: Der Erfolg von Reviews beruht ganz wesentlich darauf, dass ein anderer Mensch bei der Prüfung eines Dokuments einen anderen Blickwinkel auf das Dokument hat als der Autor. Selbst der akkurateste Autor kann Fehler beim Bearbeiten eines Dokuments machen, die einem anderen sofort ins Auge stechen. Aber auch der einzelne Prüfer wird aufgrund seiner persönlichen Sicht nur einen Teil der Fehler entdecken und andere übersehen. Durch den Einsatz mehrerer Prüfer steigt demzufolge die Abdeckung des Dokuments hinsichtlich möglicher Fehler, insbesondere dann, wenn sich ihre Sichtweisen möglichst wenig überschneiden. Mögliche Sichtweisen der Prüfer können z.B. sein: Technische Realisierung, Kosten und Aufwände der Umsetzung, Einhaltung von Normen und Standards etc. In der Regel nimmt bei intensiver Prüfung nach zwei Stunden Sitzungsdauer die Effektivität im Finden von Fehlern aufgrund der Ermüdung deutlich ab. Daher wird empfohlen, Reviews nach Möglichkeit auf zwei Stunden zu begrenzen. Es gibt zwei Alternativen, mit umfangreichen Dokumenten zu verfahren: • Aufteilen in mehrere Teile, die nacheinander geprüft werden, wobei zwischen den einzelnen Prüfungen eine genügend lange Pause liegen muss • Stichprobenbildung, d.h. es wird ein geringer Teil aus dem Dokument herausgegriffen und man schließt aus dem dort vorgefundenen Qualitätsniveau auf die Qualität des gesamten Dokuments Bei Review-Arten mit Vorbereitungsaufwand, d.h. den formalen Reviews, sollte bei mangelhafter Vorbereitung der Prüfer die Reviewsitzung vom Moderator abgebrochen und zu einem späteren Zeitpunkt wiederholt werden.

180

8 Anwendung von QSM in der Praxis

Das "ausführliche Review" ist besonders geeignet für Reviews mit Kundenbeteiligung, da hier die Gelegenheit gegeben ist, in einer geführten Diskussion ausführlich auf die Kundenwünschen einzugehen. Es eignet sich darüber hinaus insbesondere als Review in frühen Phasen, da hier der Klärungs- bzw. Diskussionsbedarf sehr hoch ist, um eine Aufgabenstellung exakt erfassen zu können. Reviews stellen für den Autor des zu prüfenden Dokumentes eine schwierige psychologische Situation dar. Seine Haltung sollte offen und objektiv sein. Damit ist gemeint, dass er in der Lage ist, so viel Abstand zu seiner Arbeit zu gewinnen, dass er sich durch die Entdeckung eines Fehlers nicht persönlich getroffen fühlt. Vielmehr sollte er das Review als eine Hilfe ansehen, um aus dem Ergebnis seiner Arbeit ein qualitativ hochwertiges Produkt zu machen, auf das er stolz sein kann. Auf der anderen Seite müssen die Prüfer glaubhaft machen können, dass es ihnen nur um die Sache geht und nicht um die Person. Ihre Kritik hat sich daher immer im sachlich-konstruktiven Bereich zu bewegen. Ein wichtiger Punkt bei Prüfungen generell und auch bei Reviews ist, dass die Version des Prüflings eingefroren sein muss. Damit ist gemeint, dass keine Änderungen an dem Dokument erlaubt sind, sofern das Dokument bereits zur Vorbereitung an die Prüfer verteilt wurde und andererseits die Reviewsitzung noch nicht abgeschlossen wurde. Andernfalls wird das Reviewverfahren durch das Finden von Fehlern, die längst nicht mehr relevant sind, ad absurdum geführt. Reviews sind „ergebnisoffen“ zu gestalten, d.h. zum Beispiel die Freigabe des zu überprüfenden Dokumentes darf – aus welchen Gründen auch immer – nicht schon vor der Reviewsitzung feststehen. Reviews sind eben nicht nur ein formaler Akt, sondern dienen der Qualitätsüberprüfung und sind anderenfalls überflüssig! Im Dokument gefundene Fehler werden klassifiziert, denn nicht in jedem Falle ist ein erneutes Review über das nachgebesserte Dokument wirklich notwendig. Bei leichten Mängeln – zum Beispiel Rechtschreibfehlern – wird diese der Autor einfach „nur“ verbessern. Bei schweren Fehlern – zum Beispiel falscher Umsetzung von Anforderungen in das Software-Design – ist das verbesserte Dokument erneut zu überprüfen. Die Festlegung, ob eine Re-Inspektion notwendig ist, findet in der Reviewsitzung statt.

8.11 Risikomanagement

181

8.11 Risikomanagement Das projektbezogene Risikomanagement formalisiert die Beziehung zwischen Projektrisiko und Projekterfolg. Ziel ist es, Risiken zu identifizieren, zu analysieren und zu beseitigen, bevor das Projekt Schaden, d.h. im Endeffekt immer Kosten bzw. Terminüberschreitung, verursachen kann. Prinzipiell sind die Begriffe Risiko und Problem voneinander zu trennen. Ein Risiko ist ein ungewolltes Ereignis, das in der Zukunft mit einer gewissen Wahrscheinlichkeit eintreffen kann. Zudem ist jedes Risiko neben der Eintrittswahrscheinlichkeit mit einer gewissen (Verlust-) Gefahr verbunden. Nur wenn diese Verlustgefahr eine substanzielle Größe darstellt, ist es gerechtfertigt, überhaupt von einem Risiko zu reden, das man im Projekt eingeht. Genauso ist es nicht gerechtfertigt von einem Risiko zu reden, falls die Wahrscheinlichkeit, dass das zugeordnete Ereignis eintritt, gleich 0 ist. Andererseits kann auch nicht mehr von einem Risiko gesprochen werden, wenn die Wahrscheinlichkeit für das zugeordnete Ereignis bei 100% liegt. Hier hat man bereits im Projekt ein konkretes Problem, das es zu beseitigen gilt. D.h. ein Problem liegt vor, wenn ein potenzielles Risiko tatsächlich eingetreten ist beziehungsweise sicher eintreten wird. 8.11.1 Einsatzumfeld Das Unternehmen

Die method park Software AG ist ein mittelständisches Software-Haus mit ca. 40 Mitarbeitern und Sitz in Erlangen. method park unterstützt seine Kunden durch Beratungsdienstleistungen zu Themen aus dem SoftwareEngineering, eigene Produkte (C-Codegenerator aus UML-Diagrammen sowie ein Prozessmanagement-Werkzeug) sowie durch SoftwareEntwicklungsdienstleistungen. Ein Großteil der Kunden und Kooperationspartner von method park sind im Embedded-Umfeld tätig. Typische Zielbranchen sind Automobilhersteller und -zulieferer, Medizintechnik, Consumer Electronics, Maschinenbau und Industrieautomatisierung. Einsatzumfeld der Maßnahme

Projektbezogenes Risikomanagement kann prinzipiell in jedem Projekt eingesetzt werden. Je größer ein Projekt und je mehr Abhängigkeiten von externen Faktoren vorhanden sind, umso dringender ist der Einsatz von Risikomanagement zu empfehlen. Zeitlich gesehen ist das Thema Risiko-

182

8 Anwendung von QSM in der Praxis

management vor allem in den konstruktiven Phasen eines Entwicklungsprojektes von besonderer Bedeutung, d.h. also in Analyse, Design und Implementierung und weniger in den verifizierenden Phasen eines Projektes. 8.11.2 Vorgehensweise Motivation für den Einsatz

Bei dem Thema Risikomanagement geht es um das Bewusstsein, dass in Projekten immer etwas schief gehen kann. Ein Projekt ist eine besondere Herausforderung für ein Team, nur deshalb hat diese Herausforderung auch den Namen „Projekt“ verdient. Mit jeder Herausforderung sind immer Chancen (d.h. hier der Projekterfolg), aber auch Risiken verbunden (die eventuell bis zum kompletten Scheitern des Projektes führen können). Um das Projekt zum Erfolg zu führen und daher die Risiken im Projekt frühzeitig zu erkennen und diesen entgegen zu wirken, ist das Risikomanagement wichtig. Nachfolgend sind exemplarisch einige Gebiete genannt, aus denen Risiken entstehen können: • Das Anwendungsgebiet, in dem durch das Entwicklungsprojekt ein neues System entstehen soll, birgt anwendungstechnische Risiken; insbesondere dann, wenn durch das Projektteam anwendungstechnisches Neuland betreten wird. • In den Anforderungen liegen immer Risiken verborgen. Sei es, dass Anforderungen zu ungenau spezifiziert wurden, d.h. dass es bzgl. der Projektabwicklung Probleme geben kann, oder sei es, dass die technische Machbarkeit nicht geklärt ist. • In der Systemarchitektur können Risiken verborgen sein, z.B. falls das realisierte System die Performance-Anforderungen nicht erfüllen kann. Die Liste lässt sich fast beliebig verlängern bis hin zu politischen Risiken im eigenen oder im Kundenunternehmen. Anwendung

Die Durchführung des Risikomanagements untergliedert sich in die Schritte Vorbereitung, Risiko-Identifitkation, Risiko-Analyse, Risiko-Managementplanung, Risiko-Überwindung und Risiko-Überwachung. 1. Vorbereitung. Je nach Projektgröße sollten nicht nur der Projektleiter sondern mehrere am Projekt beteiligte Personen am Risikomanagement teilnehmen (max. 5 Personen). Dazu werden in regelmäßigen Abständen

8.11 Risikomanagement

183

Projektbesprechungen einberufen. Zur Vorbereitung erstellt jeder der Diskussionsteilnehmer vorab eine eigene Beschreibung der möglichen Risiken. 2. Risiko-Identifikation. Ziel ist das Aufstellen eines Risikokataloges, der die projektspezifischen Risiken beinhaltet. Grundlage kann ein allgemeiner unternehmensweit gültiger Risikokatalog sein, aus dem durch Anpassung (Hinzunehmen, Anpassen oder Herausstreichen von Risikoelementen) der projektspezifische Risikokatalog entsteht. Welche Risikoelemente hinzugenommen oder gestrichen werden, wird innerhalb einer Projektbesprechung bestimmt. Bei der Risikoidentifikation sind Elemente aus folgenden Bereichen zu berücksichtigen: • Produkt / Technik • Prozess • Randbedingungen Diese Aufteilung wird auch für die Gliederung eines Risikokataloges empfohlen. 3. Risiko-Analyse und Risiko-Prioritätenbildung. Ziel in diesem Arbeitsschritt ist die Bewertung der einzelnen Risiken und die Bestimmung des Handlungsbedarfs. Dazu geht der Diskussionsleiter der Projektbesprechung die genannten Risiken mit den Teilnehmern durch und lässt jedes der Risikoelemente hinsichtlich der Eintrittswahrscheinlichkeit und der Schwere (Schadensausmaß) bei Eintritt des Risikos bewerten. Dabei wird folgende in Tabelle 8.5 gezeigte Bewertungsskala angewendet. Tabelle 8.5. Bewertungsskala für Eintrittswahrscheinlichkeiten und Schweregrade Eintrittswahrscheinlichkeit

Schweregrad

Unwahrscheinlich (0) Gering (1) Mittel (2) Hoch (3)

Keine Folgen für das Projekt (0) Geringe Folgen für das Projekt (1) Mittelschwere Folgen für das Projekt (2) Sehr schwere Folgen für das Projekt (3)

Anschließend wird eine Prioritätenbildung mit der nachfolgenden Matrix (Tabelle 8.6) durchgeführt. Je höher der Schweregrad und je höher die Eintrittswahrscheinlichkeit, umso höher ist die Priorität des Risikos und damit der Handlungsbedarf.

184

8 Anwendung von QSM in der Praxis

Tabelle 8.6. Risiko-Prioritätenmatrix

Schweregrad

Eintrittswahrscheinlichkeit 3 2 1 0

3

2

1

0

Hoch Hoch Mittel Keine

Hoch Mittel Gering Keine

Mittel Gering Gering Keine

Keine Keine Keine Keine

Der Handlungsbedarf (bezogen auf jedes einzelne Risikoelement) lässt sich wie folgt umsetzen: • Hoch: Lösungen müssen präventiv gesucht und evaluiert werden. • Mittel: Zusätzliche QS-Maßnahmen sind einzuplanen. Bei Eintritt des Risikos sind entsprechende Risikomanagement-Techniken durchzuführen. • Gering: Risikoüberwachung muss durchgeführt werden. • Keine: Keine weiteren Maßnahmen, insbesondere auch keine Risikoüberwachung notwendig. 4. Risiko-Managementplanung. Nachdem im vorangegangenen Schritt die Risiken zusammen mit ihren Prioritäten bestimmt wurden, sind nun die entsprechenden präventiven oder korrektiven Maßnahmen zu planen. Je nach bestimmter Priorität sind unterschiedlich umfangreiche Aktivitäten zu beschließen (z.B. bei niedriger Priorität „nur“ die weitere RisikoÜberwachung). Eine Hilfe dazu ist der bereits erwähnte Risikokatalog, in dem zu jedem Risikoelement Risikomanagement-Techniken genannt sind. Die Maßnahmen, die eingeplant werden müssen, sind im Projekt-Plan zu dokumentieren (Maßnahmen, Termine, Verantwortliche, Vermerke für Risiken ohne Maßnahmen, die aber verfolgt werden müssen). In regelmäßigen Projekt-Statusberichten ist die Entwicklung der Risiken (insbesondere deren Priorität und durchgeführte Maßnahmen) zu dokumentieren. 5. Risiko-Überwindung. Die in der Risiko-Managementplanung festgelegten Maßnahmen werden durchgeführt. 6. Risiko-Überwachung. Die Fortschritte der Risiko-Minimierung sind zu überwachen. In regelmäßigen Projektbesprechungen ist über den Stand der Maßnahmen zu berichten. Dies wird auch im Projekt-Statusbericht dokumentiert und bei Bedarf der Projektplan angepasst. Die Risiken sind in regelmäßigen und angemessenen Zeitabständen neu zu bewerten (ca. alle 2-4 Wochen). Bei großen Projekten ist in größeren Abständen eine neue Risikoanalyse durchzuführen (ca. alle 2-4 Monate). Die Basis für eine

8.11 Risikomanagement

185

Neubewertung der Risiken (bzw. für die neue Risikoanalyse) ist die zuvor aufgestellte Liste mit gefundenen Risiken. Einführungsstrategie

Mit der Einführung des hier beschriebenen Risikomanagements sind keine hohen Aufwände verbunden. Wie bereits erläutert, geht es eher um das Bewusstsein, dass Projektrisiken existieren, und dass hier frühzeitig entgegengewirkt werden muss, um den Projekterfolg nicht zu gefährden. Es geht also nicht um hohe Aufwände für z.B. Tools oder Ausbildung, sondern um die Systematisierung des „Bauchgefühls“. Zur Einführung des Risikomanagements sind die Dokumentvorlagen für Projektpläne und Projektstatusberichte zu ergänzen. Ein unternehmensweit geführter Risikokatalog, der später in den Projekten das Brainstorming über konkrete Projektrisiken erleichtert, ist sehr hilfreich. D.h. eine erste Version von diesem Risikokatalog kann zum Einführungszeitpunkt des Risikomanagements erstellt werden, er sollte aber auf jeden Fall begleitend zu den konkreten Projekten weiter gepflegt und ergänzt werden. Zweck dieses Dokumentes „Risikokatalog“ ist auch, aus den Risiken und Fehlern durchgeführter Projekte zu lernen, d.h. es gilt die Risiken, die durchgeführten Gegenmaßnahmen sowie den dabei erzielten Erfolg oder Misserfolg für die Zukunft zu dokumentieren. Sinnvollerweise geschieht dies in Feedback-Sitzungen, die mindestens am Projektabschluß, aber gerade bei etwas größeren Projekten auch an Phasenabschlüssen bzw. größeren Meilensteinen erfolgen sollten. Der hierfür notwendige Aufwand muss aber auch in der Projektplanung berücksichtigt werden. 8.11.3 Bewertung Fachliche Bewertung

Tom DeMarco schreibt an einer Stelle in seinem Buch „Der Termin“: „Managen Sie Ihre Projekte über Risikomanagement! Wenn Sie sonst nichts tun, dann managen Sie zumindest die Risiken Ihres Projektes!“ Und damit hat er Recht, denn letztlich ergeben sich alle anderen Aktivitäten, die üblicherweise in Projekten durchgeführt werden, aus dem Risikomanagement. Das beginnt mit dem Thema Anforderungsanalyse, Design und endet mit analytischen Qualitätssicherungsmaßnahmen. Letztere reduzieren z.B. das Risiko, dass Fehler im System enthalten sind. Erstere reduzieren das Risiko, dass das Falsche, d.h. ein vom Kunden nicht gewünschtes System entwickelt wird. Auch mit anderen in Software-Projekten üblichen

186

8 Anwendung von QSM in der Praxis

Methoden verhält es sich ähnlich: Sie werden durchgeführt um Fehlerquellen, d.h. Probleme zu umgehen und d.h. wiederum Risiken zu vermindern. Wirtschaftliche Bewertung

Risikomanagement lässt sich mit einfachen Mitteln und ohne Einsatz von aufwändigen Tools umsetzen und ermöglicht es, Risiken frühzeitig zu erkennen und zu minimieren. Die Aussage von Tom DeMarco: „Wenn Sie sonst nichts tun, dann managen Sie zumindest die Risiken Ihres Projektes“, kann somit uneingeschränkt unterstützt werden. 8.11.4 Praktische Tipps

• Eine Risiko-Identifikation ist erst möglich, wenn die Projektidee, der (grobe) Projektplan, Anforderungen oder das Design vorhanden sind. • Weniger ist mehr! Dies gilt auch für das Risikomanagement, d.h. man sollte sich nur auf die wichtigsten Risiken konzentrieren anstatt lange Risikolisten zu verwalten. • Risikomanagement ist ernst zu nehmen, d.h. die identifizierten Risiken sind zu verfolgen und zu dokumentieren. • Risiko-Management ist keine ausschließliche Tätigkeit des Projektleiters, das ganze Team muss mit einbezogen werden! • Eine hundertprozentige Risikovermeidung ist fatal: Sie führt dazu, dass die mit dem Risiko verbundene Chancen ungenutzt bleiben! • Man sollte sich mit den ursächlichen Risiken auseinander setzen, statt nur die unerwünschten Folgen am Ende zu sehen. D.h. also nicht das Risiko „Projektverzug“ sehen, sondern die Frage stellen: „Warum kommt es zum Projektverzug?“. • Antizipierung jeden Risikos mit dem allerersten Symptom, mit dem es sich vermutlich ankündigen wird. • Identifizierte Risiken sind bei der Angebotserstellung zu berücksichtigen (z.B. durch höhere Aufwände oder Aufteilung in mehrere Teilprojekte).

8.12 Softwareänderungs-Management

187

8.12 Softwareänderungs-Management Das vorliegende Dokument beschreibt den Prozess der Änderung bzw. Überarbeitung von Gerätesoftware zur Fehlerbeseitigung, Optimierung und Erweiterung um neue Anforderungen. Ziel ist die effiziente, transparente und sichere Umsetzung von Änderungsanforderungen in die entsprechende Software und anschließende Überprüfung. Die im Rahmen einer Softwareänderung durchzuführenden Maßnahmen, ihre Reihenfolge und Abhängigkeiten sind in Kapitel „Vorgehensweise“ beschrieben. 8.12.1 Einsatzumfeld Das Unternehmen

Die Endress+Hauser Gruppe ist ein Anbieter von Messgeräten und Automatisierungslösungen für die Verfahrenstechnik (unter anderem für Chemie und Petrochemie, Pharma, Lebensmittel, Wasser und Abwasser, Papier, Energie, Öl und Gas). Die Gruppe umfasst heute 24 Produktionsgesellschaften in 9 Ländern, 42 eigene Vertriebs- und Servicegesellschaften in 36 Ländern, sowie 7 Verwaltungsgesellschaften. Sie wird von einer Holding mit Sitz in Reinach (Schweiz) gesteuert. Bei der Endress+Hauser GmbH+Co. KG in Maulburg sind zurzeit ca. 1340 Mitarbeiter beschäftigt. Hauptarbeitsgebiete sind die Entwicklung und Produktion von Füllstand-, Druck- und Differenzdruckmessgeräten. Dabei werden folgende Messprinzipien angewandt: • Füllstand: kapazitiv, konduktiv, hydrostatisch, radiometrisch, Ultraschall, Mikrowelle, Mikroimpulse, Lotsystem, Vibration • Druck: kapazitiv, piezoresistiv Einsatzumfeld der Maßnahme

Das Geschäftsfeld Füllstandsmessung, innerhalb dessen die beschriebene Methode entwickelt und verwendet wurde, ist in Form einer Matrix organisiert. Hierbei sind die zu den jeweiligen Messprinzipien (Ultraschall, Mikrowelle, Mikroimpuls etc.) zugehörigen Kompetenzen in Projektteams zusammengefasst. Bestimmte übergreifende Funktionen wie „Technische Sicherheit“ oder auch die Softwareentwicklung sind quer dazu angeordnet. Im Bereich der Entwicklung für kontinuierlich messende Füllstandsgeräte sind ca. 100 Mitarbeiter tätig, wobei etwa 25 Mitarbeiter im Softwarebereich tätig sind.

188

8 Anwendung von QSM in der Praxis

8.12.2 Vorgehensweise Motivation für den Einsatz

Software hat die manchmal erfreuliche, aber oft auch nachteilige Eigenschaft, dass sie leicht änderbar erscheint. Dies gilt besonders dann, wenn man bedenkt, dass sich Software aus Programmcode, zugehöriger Beschreibung und Daten zusammensetzt. Die Modifikation einzelner Programmteile ist, rein technisch gesehen, relativ einfach. Die Probleme ergeben sich jedoch mit steigender Komplexität des Systems bei der Implementierung der geänderten Programmteile, da oft nicht vollständig geändert wird oder ungewollte Auswirkungen nicht erkannt werden. Software existiert oftmals in unterschiedlichen Versionen. Welches die aktuelle Version ist und wodurch sie charakterisiert wird, kann zu einer wirtschaftlich essentiellen Frage werden. Hierbei ist besonders auf die Rückführbarkeit der durchgeführten Änderungen auf die zugrunde liegenden Änderungsanforderungen zu achten. Anwendung

Der Ablauf der Methode ist in Abb. 8.7 als Flussdiagramm dargestellt. Hierbei werden die verschiedenen Elemente der Softwareentwicklung, der Qualitätssicherung oder sonstigen Abteilungen zugeordnet. Die Elemente sind zur weiteren Beschreibung nummeriert und im Detail beschrieben. Im Folgenden werden die einzelnen Elemente beschrieben: 1. Änderungsanforderungen können von Fachabteilungen, Service, Fertigung, SW-Entwicklung usw. vorliegen. Im Allgemeinen dienen sie zur Fehlerbeseitigung, Berücksichtigung von neuen funktionalen Anforderungen und der generellen Produktverbesserung, die sich aus dem praktischen Einsatz eines Gerätes ergeben. Die Änderungsanforderungen sind an den jeweiligen fachlichen Ansprechpartner (FA) zu richten. Der FA prüft die Anforderung auf Vollständigkeit und Widerspruchsfreiheit in Zusammenarbeit mit der jeweiligen Fachabteilung. Verantwortlich: FA

8.12 Softwareänderungs-Management Software-Entwicklung

Software-Entwicklung (Qualitätsbeauftragter)

2 Änderungsanforderung analysieren

3 Änderungsanford. realisierbar?

Externe Abteilungen 1 Änderungsanforderung erfassen

Nein

Ja 4 Änderungsanforderung erfassen

5 Entscheiderkreis

7 Aufforderung DeisgnFreeze durchzuführen

Nein

Ja 6 SW-Änderung durchführen

15 Datenbank

8 Änderungsmitteilung erstellen

9 Entscheid ob Label & int. Test Nein Ja 10 Interner Test

Nein

13 Test in der Fachabteilung

11 Interner Test OK? Ja 12 Änderungsliste erstellen

14 Softwarefreigabe Nein Ja

Abb. 8.7. Softwareänderungs-Management

189

190

8 Anwendung von QSM in der Praxis

2. Die Änderungsanforderung wird analysiert, die Kritikalität hinsichtlich des Quellcodes (Stabilität, Wartbarkeit, Funktionssicherheit, Einfluss auf andere Produkte sofern der Quellcode in weiteren Geräten verwendet wird) überprüft und bewertet. Verantwortlich: FA 3. Der FA entscheidet, ob eine vorliegende Änderungsanforderung umgesetzt werden kann. Verantwortlich: FA 4. Falls die Änderungsanforderung durchführbar ist, wird diese in einer Datenbank erfasst, d.h. der Änderungsanforderung wird ein Fehler- bzw. Änderungscode zugeordnet, auf die dann in der weiteren Bearbeitung referenziert werden kann. Verantwortlich: Qualitätssicherung (QS) 5. Der Entscheiderkreis SW-Entwicklung (Abteilungsleiter, Teamleiter + FA) legt fest, wann und ob eine erfasste Änderungsanforderung umgesetzt wird. Verantwortlich: Entscheiderkreis SW-Entwicklung 6. Eine vom Entscheiderkreis SW-Entwicklung veranlasste Softwareänderung wird umgesetzt. Verantwortlich: Software-Entwicklung 7. Zur Sicherstellung eines definierten Softwarestandes zu internen und / oder externen Tests fordern die Fachabteilungen zum Design-Freeze auf, d.h. der vorliegende Softwarestand wird festgehalten mit dem Ziel, den derzeitigen Stand zu einem späteren Zeitpunkt wieder herstellen zu können. In der Praxis erfolgt dies mittels eines Version Control Systems (VCS) und der Vergabe eines Labels. Verantwortlich: Fachabteilung 8. Änderungsmitteilungen sind für durchgeführte Softwareänderungen und für vom Entscheiderkreis Software-Entwicklung abgelehnte Änderungsanforderungen zu erstellen. Ziel ist, die Verfolgbarkeit der durchgeführten bzw. abgelehnten Änderungsanforderungen sicherzustellen. Im Fall von nicht durchgeführten Änderungsanforderungen wird dies in der Änderungsmitteilung entsprechend dokumentiert. Verantwortlich: Software-Entwicklung 9. Der Entscheiderkreis SW-Entwicklung legt fest, ob entweder aufgrund einer externen Aufforderung (Design-Freeze) oder zu entwicklungspezifischen Zwecken ein interner Test durchgeführt wird. Verantwortlich: Entscheiderkreis SW-Entwicklung

8.12 Softwareänderungs-Management

191

10. Interner Test Ein Label wird zur Gewährleistung eines definierten und reproduzierbaren Quellcodes erstellt. Verantwortlich: QS Ein Test wird durchgeführt. Ziel ist es (vor der Bereitstellung der überarbeiteten Gerätesoftware), dass interne Tests (z.B. automatische Tests, Konformitätstests usw.) keine Fehlfunktion ergeben und keine Abweichungen zu den Vorgaben bestehen. Verantwortlich: QS Testergebnisse werden dokumentiert. Verantwortlich: QS 11. Testergebnisse werden ausgewertet. Verantwortlich: QS 12. Wenn das Gesamt-Testergebnis in Ordnung ist, erfolgt eine Aufstellung der durchgeführten Softwareänderungen seit der letzten Softwarebereitstellung an die Fachabteilung. Verantwortlich: QS 13. Nach Bereitstellung der Gerätesoftware an die Fachabteilung erfolgt der (Validierungs-)Test in der Fachabteilung. Verantwortlich: Fachabteilung 14. Die Testergebnisse in der Fachabteilung bilden die Grundlage zur Softwarefreigabe. Wenn Software nicht freigegeben werden kann, erfolgt eine Nachbearbeitung des Quellcodes. Verantwortlich: Fachabteilung Einführungsstrategie

Da das Softwareänderungs-Management unverzichtbarer Bestandteil des allgemeinen Qualitätsmanagements ist, sind bei seiner Einführung keine Widerstände der Beteiligten zu erwarten. Es ist darauf zu achten, dass alle Anforderungen aufgenommen und behandelt werden. Die zugehörigen Entscheide sind ebenfalls zu dokumentieren und an geeigneter Stelle zu archivieren. Hierzu bietet sich idealerweise eine Datenbank an, welche auf diesen Anwendungsfall entsprechend zugeschnitten ist. Die Datenbank sollte von allen beteiligten Gruppen direkt einsehbar sein, um getroffene Entscheidungen nachvollziehen zu können. Dies fördert weiterhin die Akzeptanz und die Anwendung der Maßnahme.

192

8 Anwendung von QSM in der Praxis

8.12.3 Bewertung Fachliche Bewertung

Das SW-Änderungsmanagement macht alle Änderungsanforderungen an ein existierendes Produkt transparent und ermöglicht es, alle Entscheidungen in diesem Kontext zu dokumentieren und nachzuvollziehen. Dadurch wird die Wahrscheinlichkeit, einen einmal getroffenen Entscheid leichtfertig zu revidieren, wesentlich vermindert. Darüber hinaus bietet das Softwareänderungs-Management die Grundlage für eine ganze Reihe von Kennzahlen bezüglich Stabilität, Reife und Tauglichkeit einer existierenden Software-Variante. Hieraus können entsprechende Maßnahmen für das aktuelle Gerät sowie für nachfolgende Entwicklungen abgeleitet werden. Wirtschaftliche Bewertung

Der Einsatz des beschriebenen Verfahrens ist eine entscheidende Voraussetzung um eine eindeutige Zuordnung von SW-Änderungen und Änderungsanforderungen vornehmen zu können. Darüber hinaus werden die Entscheidungswege, welche zu einer neuen SW-Version führen, hiermit dokumentiert. Beides sind Bedingungen, um Messgeräte in den Bereich der sicherheitssensitiven Anlagen liefern zu können. 8.12.4 Praktische Tipps

Um die Menge von Änderungsanforderungen und Änderungsmitteilungen überschaubar und effizient handhaben zu können, ist der Einsatz einer auf diesen Fall zugeschnittenen Datenbank zu empfehlen. Weiterhin kann an dieser Stelle die Zuordnung der Änderung zu zugrunde liegender Anforderung festgehalten werden.

9 Die Einführung von QSM in einzelnen Unternehmen

Neue, bisher nicht bei den Unternehmen angewendete QS-Maßnahmen wurden in Form von Pilotprojekten auf ihre Alltagstauglichkeit hin erprobt. Die dabei gesammelten Erfahrungen sind in diesem Kapitel zusammengetragen. Schwierigkeiten, die bei der Einführung und erstmaligen Anwendung auftreten, wurde ein besonderer Stellenwert eingeräumt. Die Pilotprojektbeschreibungen sind in der Regel unterteilt in eine allgemeine Projektbeschreibung, eine Zieldefinition, ein Planung des Einsatzes und eine Beschreibung der Durchführung. Die Beschreibung der Durchführung umfasst die Vorbereitung und die Anwendung der QSM. Abgeschlossen werden die Pilotprojektbeschreibungen mit einer Bewertung und gegebenenfalls mit einer Auflistung praktischer Tipps. Folgende QSM wurden in Form von Pilotprojekten bearbeitet: • • • • • • •

Anforderungs- und Defect-Management Simulation zu Testzwecken Prozessdefinition mit dem projekt>kit Modellbasierter Funktionstest regelungstechnischer Software Virtueller Funktionstest von PROFIBUS-Komponenten Fundamentales Modellierungskonzept (FMC) Optimierung des Entwicklungsprozesses

194

9 Die Einführung von QSM in einzelnen Unternehmen

9.1

Anforderungs- und Defect-Management

Kapitel 9.1 beschreibt die Erfahrungen, die bei der Endress + Hauser GmbH + Co.KG bei der Einführung von Anforderungs- und DefectManagement als Qualitätssicherungsmaßnahme gesammelt wurden und welche Erkenntnisse hieraus weitergegeben werden können. 9.1.1

Allgemeine Projektbeschreibung

Das Entwicklungsprojekt, in dessen Umfeld die nachfolgend beschriebenen Qualitätssicherungs-Maßnahmen (QSM) eingesetzt wurden, hatte zum Ziel, ein Füllstandsmessgerät auf radiometrischer Basis zu entwickeln. Dieses Messprinzip hat den Vorteil, dass es auch bei hohen Drücken, hohen Temperaturen und aggressiven Medien eingesetzt werden kann, da es sich um eine berührungslose Messung handelt. Als Strahlungsquelle kommt ein Cäsium- bzw. Cobaltpräparat zum Einsatz. Als Detektor dient ein Kristall- oder Plastikszintillator. Das Messgerät verfügt sowohl über einen analogen (4-20 mA) Ausgang als auch über eine digitale Kommunikationsschnittstelle. Eine Randbedingung bei der Entwicklung der Software bestand darin, die Teile der Software für die Kommunikation und Bedienung aus der Entwicklung früherer Messgeräte zu übernehmen. Eine weitere Vorgabe bei der Entwicklung war die Entscheidung, das gesamte Gerät nach SIL 2 (Safety Integrity Level nach der Norm IEC 61508) zu entwickeln. Dadurch waren bereits viele Vorgaben bezüglich des Einsatzes von QS-Maßnahmen eindeutig festgelegt. Das Entwicklungsprojekt hatte eine Laufzeit von ca. 2 Jahren und wurde hauptsächlich von einem Team bestehend aus 1 Projektleiter, 1 Produktmanager, 3 Software-Entwicklern, 3 Hardware-Entwicklern, 1 Konstrukteur und 1 Mitarbeiter für Zulassungen und technische Sicherheit umgesetzt. Weiterhin waren Hard- und Software-Qualitätssicherung sowie die Anwendungstechnik beteiligt. 9.1.2

Ziele des Pilotprojekts

Getrieben durch die Vorgaben der Entwicklung nach SIL2 war die Forderung nach dem Einsatz einer möglichst durchgängigen Toolkette (Requirements-, Test-, Defect-, Version- und Konfigurations-Managementtools) innerhalb der Softwareentwicklung gegeben. Dies bedeutete, dass die bisherige Praxis der Erfassung von Anforderungen mittels Word- und Excel-

9.1 Anforderungs- und Defect-Management

195

Dokumenten durch ein dezidiertes Anforderungs-Management-Tool abgelöst wurde. Ziel der QSM war, durch den Einsatz eines Anforderungs-ManagementTools und eines daran anknüpfenden Prüffall-Tracking-Tools eine Steigerung der Softwarequalität zu erreichen. Es sollte nur das entwickelt und geprüft werden, was tatsächlich, ausgehend von den Kundenwünschen, gefordert wurde. Durch die Vermeidung unnötiger Arbeitsschritte sollte außerdem eine Effizienzsteigerung erzielt werden. Ausgehend vom vorgegebenen Anforderungs-Management- und Prüffall-Tracking-Tool sollte der Ablauf eines toolunterstützten Anforderungs-Tracking-Prozesses und Prüfplan-Tracking-Prozesses beschrieben werden. Ein weiteres Ziel der eingesetzten QSM bestand darin, den Entwicklern einen requirementgetriebenen, systematischen und nachvollziehbaren Arbeitsstil zu ermöglichen, ohne jedoch die entwicklerische Kreativität zu unterbinden. Des weiteren sollte für die Projektleitung eine sehr schnelle und einfache Möglichkeit geschaffen werden, einen Überblick über den aktuellen Projektstand zu gewinnen, um so entsprechende Maßnahmen ableiten zu können. Als logische Konsequenz der toolgestützten Verwaltung von Anforderungen und Prüffällen lag das Ziel nahe, einen ebenfalls toolunterstützten Defect-Tracking-Prozess zu implementierten. Da die Kompletteinführung einer gesamten Toolkette in der SoftwareEntwicklung zu einer zu großen Zeitverzögerung innerhalb eines Projektes führen würde, sollten Erfahrungen bezüglich der Einführung von Software-Tools gesammelt werden. Hiermit sollte die Einführung weiterer Tools in kommenden Projekten erleichtert und optimiert werden. 9.1.3

Planung des QSM-Einsatzes

Eine grundlegende Entscheidung für die Planung und Umsetzung der QSM war die Auswahl der einzusetzenden Tools. Diese wurde durch die Projektleitung mit Hilfe eines externen Beraters und der übrigen Projektbeteiligten getroffen. Hierbei wurden auch Erfahrungen aus einem Vorgängerprojekt berücksichtigt. Bei den eingesetzten Tools handelt es sich um das Anforderungsmanagement-Tool SafetyCaseDB der Firma Exida, die gleichzeitig als externe Beratungsfirma innerhalb des Projekts tätig war, sowie dem Prüffall- und Error-Tracking-Tool TestDirector der Firma Mercury-Interactive. Die Prozessbeschreibung der QSM wurde innerhalb der Q-Abteilung durch drei Personen ausgearbeitet und mit der Abteilungs- und Projektleitung abgesprochen sowie in zahlreichen Besprechungen mit den betroffenen Entwicklern diskutiert und verbessert. Bedingt durch die prozessorien-

196

9 Die Einführung von QSM in einzelnen Unternehmen

tierte Organisationsstruktur innerhalb der Firma, bei der die Qualitätssicherung direkt in den Entwicklungsprozess eingebunden ist, gab es bezüglich der Umsetzung der QSM keine organisatorischen Hindernisse, da die Umsetzung der QSM durch die Software-Abteilungsleitung gefördert bzw. sogar gefordert wurde. Die Vorbereitung der QSM, welche wesentlich in der Konfiguration der beiden Tools bestand, wurde gänzlich vonseiten der Qualitätssicherung durchgeführt. Eine besondere Schulung der Mitarbeiter war auf Grund der geringen Anzahl der beteiligten Personen nicht vorgesehen. Da der Hersteller des Anforderungsmanagement-Tools gleichzeitig als externer Berater im Projekt fungierte, konnte nach einer kurzen Einweisung im Zuge der täglichen Projektarbeit der Umgang mit dem Tool eingeübt werden. Diese Vorgehensweise hat sich als sehr praktikabel herausgestellt, da Fragestellungen und Schwierigkeiten, die sich erst während der täglichen Arbeit ergaben, umgehend geklärt werden konnten. 9.1.4

Durchführung der QSM

Ziel der Qualitätssicherungsmaßnahmen Anforderungs- und DefectManagement ist eine transparente und definierte Vorgehensweise bei Verifikation und Validierung von SW-Anforderungen mittels eines Prüfplans. Die Prozessbeschreibung aus Abb. 9.1 stellt im wesentlichen dar, wie die vier Bereiche Anforderungs-Management, Prüfplan, Prüfprozedur und Produktprüfung interagieren. Hierbei sind für die einzelnen Bereiche zum besseren Verständnis Beispiel-Tools hinterlegt, die jedoch nicht Bestandteil der Qualitätssicherungsmaßnahmen sind.

9.1 Anforderungs- und Defect-Management

RequirementManagement

Prüfplan

Prüfprozedur

197

Produktprüfung

Eintrag der Prüfergebnisse

RequirementsTracking-Tool z.B. RequisitePro / DOORS / TestDirector / SafetyCaseDB / ...

Prüffall-Design-Tool z.B. CTE / TestDirector / TestManager

Modul-Test-Tool z.B. Tessy / Cantata

Eintrag der Prüfergebnisse

Prüffall-Tracking-Tool z.B. TestManager / TestDirector

Prüffall-Design-Tool z.B. CTE / TestDirector / TestManager

System-Test-Tool z.B. AutoQuest / WinRunner / Robot

Eintrag der Prüfergebnisse

Prüffall-Design-Tool z.B. CTE / TestDirector / TestManager

Manuelle Prüfung

Abb. 9.1. Prozessbeschreibung Anforderungs- und Defect-Management

Tabelle 9.1 zeigt zugehörige Beispiele der Produktprüfung. Tabelle 9.1. Beispiele der Produktprüfung Modul Test

System-Test

Manuelle Prüfung

SW-Modul-Test

Parameter-Limits

SW-Integrations-Test

Defaultwerte Resetverhalten Stromblock Dynamisches Geräteverhalten Device-Description

HART-Conformance Test Energie-Management Review, Walkthrough

198

9 Die Einführung von QSM in einzelnen Unternehmen

Nachfolgend werden die beiden durchgeführten toolunterstützten Qualitätssicherungsmaßnahmen Anforderungs- und Defect-Management näher beschrieben. Anforderungs-Management

Unter Anforderungs-Management versteht man, Anforderungen an ein System, Gerät, eine SW oder HW in übersichtlicher und strukturierter Form zu erfassen, zu pflegen und zu verfolgen, was durch den Einsatz eines Anforderungs-Tracking-Tools erreicht werden kann. Die darin definierten Requirements sind mittels geeigneter Methoden und Verfahren zu verifizieren und validieren. Dies geschieht durch die Erstellung eines Prüfplans. Prüfplan. Innerhalb des Prüfplans werden die Prüfgegenstände und die Prüfumgebung definiert und die Durchführung der Prüffälle geplant. Des Weiteren wird für jeden Prüffall die Prüfebene, Prüfmethode und die Prüfklasse definiert. Für jeden einzelnen Prüffall wird dessen Ausprägung, Durchführung und das Prüfergebnis der Produktprüfung in das PrüffallTracking-Tool eingetragen. • Prüfebene: Modulprüfung, SW-Integrationsprüfung, Systemprüfung • Prüfmethode: Blackbox-Test, Whitebox-Test, formelle Prüfung • Prüfklasse: Funktionstest, Fault-Insertion-Test, Stresstest, Grenzwerttest, Review, Inspection, Walkthrough • Ergebnisklasse: Passed, Failed, noRun (ohne Prüfung) Je nach ausgewählten Werkzeugen ist ein zyklischer Abgleich zwischen Anforderungs- und Prüffall-Tracking-Tool erforderlich. Prüfprozedur. Die im Prüfplan definierten Prüffälle werden in der Prüffall-Design-Phase an Hand von Prüfprozeduren genauer spezifiziert. Hierzu wird festgelegt, welches die genaue Ausprägung der Verifikation / Validierung des Prüffalls ist. Die Feingliederung geschieht durch Untergliederung des Prüffalls in einzelne Prüfschritte. Die Verwendung eines Werkzeugs zum Design von Prüffällen (Prüffall-Design-Tool) unterstützt hierbei eine systematische Ermittlung redundanzarmer und fehlersensitiver Prüffälle. Produktprüfung. Innerhalb der Produktprüfung kann zwischen drei verschiedenen Arten der Durchführung der Prüfung unterschieden werden: Prüfung mittels eines Modul-Test-Tools, mittels eines System-Test-Tools oder anhand einer manuellen Prüfung.

9.1 Anforderungs- und Defect-Management

199

Die Ergebnisse der Verifikations- und Validierungsprüfungen werden entweder automatisch bei Vorhandensein einer automatischen Kopplung oder manuell ins Prüffall-Tracking-Tool übertragen. Modul-Test-Tool. Das Modul-Test-Tool wird eingesetzt für die Prüfebenen Modulprüfung und SW-Integrationsprüfung. Die verwendeten Prüfmethoden sind Blackbox-Test und Whitebox-Test. Von den Prüfklassen werden Funktionstest, Fault-Insertion-Test und Grenzwerttest benutzt. System-Test-Tool. Das System-Test-Tool wird eingesetzt für SWIntegrationsprüfungen und Systemprüfungen. Die bevorzugte Prüfmethode ist der Blackbox-Test. Von den Prüfklassen werden Funktionstest, FaultInsertion-Test, Stress-Test und Grenzwerttest benutzt. Manuelle Prüfung. Manuelle Prüfungen werden überall dort verwendet, wo ein automatisierter Ablauf technisch oder wirtschaftlich nicht sinnvoll oder möglich ist. Die manuelle Prüfung umfasst von der Modulprüfung über SW-Integrationsprüfung bis hin zur Systemprüfung alle Prüfebenen. Die Prüfmethode ist überwiegend die formelle Prüfung, jedoch werden auch Blackbox-Tests und Whitebox-Tests durchgeführt. Defect-Management

Nachfolgend soll beschrieben werden, wie innerhalb des Entwicklungsprojekts das Defect-Management mittels des SW-Tools TestDirector betrieben werden soll. In Abb. 9.2 werden die Zustände bzw. Zustandsübergänge der Defects innerhalb des TestDirectors dargestellt.

200

9 Die Einführung von QSM in einzelnen Unternehmen

Unlabeled SW

Labeled SW

Defect NEW

OPEN

DESIRED

neue Anforderung?

Defect beheben und testen

OPEN

Defect analysieren

CLOSED

Defect beheben und testen

CONFORM

FIXED

Änderung der Anforderung

CLOSED

SW-Label erstellen

REOPEN

Anforderungs Management Prozess CLOSED

FIXED Regressions Test

CLOSED

Defect beseitigt

Abb. 9.2. Defect-Management mit TestDirector

Nicht intern freigegebene Software (ohne Label). Bei SW ohne Label kann und soll der Entwickler den Status (NEW / OPEN / CLOSED) des Defects in seiner Verantwortung ändern. Um bei entsprechender Suche das Auffinden dieser Art von Defects zu erleichtern, müssen hierbei nachfolgende Einträge vom Entwickler unbedingt vorgenommen werden: • • • •

Category: Subject: Status: Detected Version:

ToDo HW-SW-Integration OPEN Unlabed Version

Intern freigegebene Software (mit Label). Bei SW mit Label sind die Änderungen des Status nach einer Analyse des Defects durch die Qualitätsicherung oder die Projektleitung zu vergeben bzw. der entsprechende Status ist zu setzen. Ergeben sich durch die Klassifizierung des Status des Defects notwendige Aktionen, so sind diese ebenfalls durch QS / PL auszuführen (CONFORM, DESIRED). Sobald ein Defect einem Entwickler zugeordnet (Feld: Assigned to) ist, wird dieser automatisch per Email über den neuen ihm zugewiesenen Defect unterrichtet.

9.1 Anforderungs- und Defect-Management

201

Vorbereitung der QSM

Bei der Einführung der QSM wurde darauf geachtet, dass es einen kleinen zeitlichen Vorlauf vor dem eigentlichen Start der Geräteentwicklung gab, so dass das Tool bei Start der Geräteneuentwicklung bereits fertig konfiguriert vorlag. Da bestimmte Aspekte in der Anwendung der QSM zunächst noch ungeklärt waren und erst im tatsächlichen Einsatz geklärt werden konnten, verursachte dieses Vorgehen trotzdem noch einige Schwierigkeiten. Bei der Toolauswahl stützte man sich im Bereich Anforderungsmanagement auf die Zuarbeit eines externen Beraters. Im Bereich DefectManagement verwendete man ein bereits firmenintern erfolgreich verwendetes Tool. Dieses musste jedoch an den vorliegenden Anwendungsfall entsprechend angepasst werden. Da die Anzahl der Software-Entwickler sich in einem überschaubaren Rahmen hielt, gestalteten sich die Einführung und Schulungsmaßnahmen hier entsprechend einfach. Eine tiefgreifende Prozessänderung innerhalb der Abteilung war nicht notwendig, da die Prozesse in ähnlicher Form bereits vorhanden waren. Die Anpassungen an den geänderten Ablauf wurden projektbezogen im Rahmen eines V-Modell97-Tailoring durchgeführt. Anwendung der QSM

Durchführung und Wirksamkeit einer qualitätssichernden Maßnahme sind immer sehr stark von der Bereitschaft der beteiligten Personen zur Mitwirkung und insbesondere von der uneingeschränkten Unterstützung der Projektleitung abhängig. Nur wenn von Seiten der Projektleitung die entsprechenden Rahmenbedingungen geschaffen werden, kann die Maßnahme nutzbringend umgesetzt werden. Ansonsten entsteht die Gefahr, die Maßnahme nur formal umzusetzen. Der Anforderungs-Management-Prozess wurde von Seiten des Produktmanagements anfänglich etwas zögerlich betrieben, da der Umgang mit dem Tool noch fremd war und hiermit die Notwendigkeit einer eindeutigen Festlegung gegeben war. An dieser Stelle gibt es für das Anforderungs-Management auf Systemebene noch weiteres Optimierungspotential. Auf Komponenten-Ebene, getrieben durch die SoftwareQualitätssicherung, fand die QSM eine gute Umsetzung und Akzeptanz, stieß jedoch immer wieder auf System-Ebene an ihre Grenzen. Die QSM des Prüffall- und Error-Tracking wurde im Bereich der Software sehr intensiv angewendet und rege diskutiert, was sich in wesentlichen Ergänzungen und Änderungen der Prozessbeschreibung niederschlug und somit eine sehr gute Basis für Nachfolgeprojekte lieferte.

202 9.1.5

9 Die Einführung von QSM in einzelnen Unternehmen Bewertung

Der Einsatz eines toolgestützten Anforderungsmanagements war eine Grundvoraussetzung zur Entwicklung eines Gerätes mit SIL 2 Zulassung. Dieses Ziel wurde sicher erreicht. Auf Systemebene hätte der Nutzen bei einer allumfassenden Anwendung der Methodik und des zugehörigen Werkzeuges noch gesteigert werden können. Positiv anzumerken sind die durch die Anwendung der QSM entstandenen definierten Schnittstellen zwischen den beteiligten Abteilungen. Hierbei hat sich ein Vorgehen etabliert, bei dem Informationen in strukturierter und transparenter Form zwischen den einzelnen Beteiligten ausgetauscht werden. Die Anwendung eines Prüffall- und Defect-Tracking hat bezüglich Prüftiefe und Defect-Transparenz einen hohen Nutzwert gezeigt. Durch die eindeutige Festlegung der durchzuführenden Prüfungen konnte jeder Entwickler zu jedem Zeitpunkt die noch ausstehenden Aufgaben kontrollieren. Die auszuführenden Prüfungen wurden im Wesentlichen gemeinsam von der Entwicklungs und QS-Abteilung entworfen. Hierdurch konnte die Software-Qualität deutlich erhöht werden. Ein weiterer positiver Aspekt war die durch dieses Vorgehen erreichte Steigerung der Mitarbeiterzufriedenheit. Durch die konsequente Anwendung des Defect-Trackings, bei welchem auch Defects eingetragen wurden, die in Entwicklertests auftraten, war es den Entwicklern anhand der ihnen zugeordneten Defects möglich, eine fundierte Aufwandsabschätzung zu erstellen. Ausgestattet mit der Aufwandsabschätzung konnte eine gute Grundlage für Aussagen zum weiteren Projektverlauf bzw. zum voraussichtlichen Projektende gegeben werden. 9.1.6

Praktische Tipps

Die Erfahrung im Rahmen des Pilotprojekts hat gezeigt, dass bei zeitkritischen Projekten eine QSM nur dann umfassend eingeführt werden kann, wenn diese von der Projektleitung uneingeschränkt unterstützt wird. Durch die Einarbeitung und das Erlernen der QSM wird zunächst eine Verzögerung entstehen und das Projekt dadurch anscheinend verlängert. Dieser Effekt kann zu einer erkennbaren Unruhe innerhalb des Projekts führen. Im weiteren Projektverlauf jedoch wird diese Verzögerung meist wieder kompensiert. Bei der Einführung eines Anforderungs-Management-Prozesses sollte darauf geachtet werden, dass die Kundenanforderungen eindeutig erfasst und dargestellt werden, da sie die Ausgangsbasis für alle weiteren Aktivi-

9.1 Anforderungs- und Defect-Management

203

täten und daraus abgeleiteten Anforderungen sind. Der Erfolg eines Projektes wird maßgeblich an der Erreichung dieser Ziele gemessen. Hierbei hat der Produktmanager eine entscheidende Aufgabe. Er muss frühzeitig stabile und eindeutige Anforderungen für das Projekt einfordern, um darauf aufbauend eine realistische Planung erstellen zu können. Dies kann beispielsweise durch Definition eines Meilensteines erzwungen werden, zu dem ein Review mit Freigabe der Anforderungen durchgeführt sein muss.

204

9 Die Einführung von QSM in einzelnen Unternehmen

9.2

Simulation zu Testzwecken

Dieses Pilotprojekt beschäftigt sich insbesondere mit der Anwendung der Qualitätssicherungs-Maßnahme „Simulation zu Testzwecken“ bei der Lenze AG. Hintergrund dieses Pilotprojekts ist es, neue Möglichkeiten einer Termin-Optimierung zu erschließen und bereits in frühen Projektphasen Aussagen über den Qualitätsstand treffen zu können. 9.2.1

Allgemeine Projektbeschreibung

Das Pilotprojekt beschäftigt sich mit dem Test eingebetteter Software in frühen Entwicklungsphasen. Zu diesem Zeitpunkt ist im Projekt noch keine Ziel-Hardware verfügbar. Vorhanden ist lediglich ein Hardware-Board mit einer Prozessornachbildung, welches dem Entwickler die SoftwareEntwicklung weitgehend Hardware-unabhängiger Funktionen ermöglicht. Das Pilotprojekt ist integriert in die Produktentwicklung eines elektrischen Antriebsreglers. Dieser hat die Aufgabe, über einen Motor einen technischen Prozess mechanisch anzutreiben. Der bisherige Aufbau der sog. Typprüfung eines Antriebsreglers ist in Abb. 9.3 schematisch dargestellt.

Abb. 9.3. Aufbau der bereits vorhandenen Typprüfung mit realem Prüfling

9.2 Simulation zu Testzwecken

205

Die System-Funktionalität des Antriebsreglers ist klassisch mechatronisch und setzt sich aus Hardware- und Software-Komponenten sowie mechanischen Anteilen zusammen. Zusätzlich vorhanden sind Kommunikationssysteme, über die der Antriebsregler mit der Systemumgebung vernetzt werden kann. Im Fokus stehen hauptsächlich Black-Box-Tests, die an den äußeren Schnittstellen des Antriebsreglers ansetzen. Die Machbarkeit des Pilotprojektes wurde im Vorfeld günstig bewertet. Das Pilotprojekt dauerte von September 2002 bis Mai 2004, wobei insgesamt ca. 8 Personenmonate aufgewendet wurden. 9.2.2

Ziele des Pilotprojekts

Die Entwicklung eingebetteter Software zeichnet sich bei vielen Projekten durch die späte Verfügbarkeit der Ziel-Hardware aus. Durch das sequenzielle Vorgehen bei der Erstellung von Hardware, Software und Verifikation treten bei vielen Projekten Probleme auf, die sich in unterschiedlicher Ausprägung bemerkbar machen: • Die Integration der Komponenten erfolgt erst sehr spät • Viele Komponenten werden auf einmal integriert Î „Big Bang“ • Die zu bearbeitenden Aufgaben stauen sich am Projektende in der Folge: • werden Tests erst gegen Ende des Projekts durchgeführt, • werden Fehler zu spät in der Wertschöpfungskette erkannt, • sind Aussagen zum Projektfortschritt (Funktionsumfang, Kosten, Termine, Qualität) mit einer hohen Unsicherheit behaftet. Das Ziel war es, mit Hilfe der Maßnahme „Simulation zu Testzwecken“ diese Effekte aufzufangen und die zeitlichen Einschränkungen durch geeignete Aktivitäten zu kompensieren. Die Software-Tests sollen bereits zu einem wesentlich früheren Zeitpunkt, also bereits deutlich vor Verfügbarkeit der Ziel-Hardware, starten können. Die Firma Lenze hat mit ihren Typprüfständen eine etablierte und bewährte Infrastruktur für automatische Software-Tests aufgebaut und bereits langjährig im Einsatz (Abb. 9.3). Das reale Testobjekt soll im Rahmen des Pilotprojekts durch eine PC-Simulation ersetzt werden. Diese Testunterstützung soll helfen, das Entwicklungsergebnis möglichst früh abzusichern. Die für das Pilotprojekt zu erstellenden Testfälle sollen ferner zu der Lenze Test-Infrastruktur kompatibel sein. Auf den unterschiedlichen Entwicklungsplattformen in den nachfolgenden Entwicklungsphasen sollen Regressionstests reproduzierbare Ergebnisse liefern.

206 9.2.3

9 Die Einführung von QSM in einzelnen Unternehmen Planung des QSM-Einsatzes

Die Planung der QS-Maßnahme „Simulation zu Testzwecken“ wurde in enger Zusammenarbeit eines Software-Entwicklers mit weitreichendem System-KnowHow und einem ebenso erfahrenem Tester durchgeführt. Der Entwickler hatte zusätzlich die Aufgabe, das Design für die SoftwareSimulation auszuarbeiten. Der Tester hingegen analysierte im Wesentlichen die zu testende Software und die damit in Verbindung stehenden Testfälle. Unterstützt wurden diese beiden Personen durch zwei weitere Entwickler und Tester, die für die Umsetzung der Planung verantwortlich waren. Für die Durchführung der Arbeiten sind die in Tabelle 9.2 aufgeführten Rollen identifiziert worden. Tabelle 9.2. Identifizierte Rollen, Aufgaben und Aktivitäten Rollen

Person

Aufgaben bzw. Aktivitäten

Test-Manager

Tester 1

Software-Designer

Entwickler 1

Software-Entwickler

Entwickler 1

Leitung des Pilotprojekts Konzept der Simulationsanbindung an das Testsystem Konzept der PC-Simulation, Umsetzung auf PC-Plattform Erstellung der Simulationsumgebung inkl. Treiber und Portierung der Software auf PC-Plattform Simulation fehlender Regelungssoftware und Zugangskanäle Analyse vorhandener Testfälle und Software-Funktionalität, Umsetzung der Testscripte und Neuerstellung von Tests Anpassung der Typprüfungs-Software

Entwickler 2 Tester

Tester 1

Tester 2

Für die Durchführung des Pilotprojektes wurden die folgenden Arbeitspakete definiert: • • • • •

Modifikation der Geräte-Software Modifikation der Typprüfungs-Infrastruktur Anpassung der vorhandenen Testscripte für die Simulation Systemzugang über eine Kommunikationsanbindung Shared-Memory-Zugriff für I/O-Signale

9.2 Simulation zu Testzwecken 9.2.4

207

Durchführung der QSM

Die Beschreibung der Durchführung gliedert sich in die Vorbereitung und Anwendung der QS-Maßnahme. Vorbereitung der QSM

Für die Durchführung der QSM „Simulation zu Testzwecken“ waren keine außergewöhnlichen Vorbereitungen notwendig. Die erforderlichen Werkzeuge (Microsoft Visual C++.NET, Lenze Testumgebung, Lenze Testsuite etc.) waren bereits vorhanden und bei den zuständigen Entwicklern etabliert. Anwendung der QSM

Die Anwendung der QSM lässt sich in die Anpassung der Gerätesoftware, die Anpassung der Typprüfsoftware und die Erstellung der Testscripte unterteilen. Anpassung der Gerätesoftware. In der Geräteentwicklung sollten möglichst viele Softwareanteile vom Zielsystem und von der PC-Simulation gemeinsam genutzt werden. Dazu wurde die Software in Schichten aufgebaut (Abb. 9.4). So ist es möglich, die PC-Simulation innerhalb des üblichen Projektrahmens zu erstellen und zu verwenden. Anwendungsfunktionen

Geräte-Basis-Funktionen Gerätesteuerung

Positionierung

User Interface

Geräteprofile Kommunikationsprofile Elektrische Welle

Error-Handler

Systemdienste

Kurvenscheibe Datenhaltung Task 1

Task n

Funktions Bibliothek

Parameter Manager

Eventprotokolle

RTOS-API

RTOS

Speichertreiber

Kommunikationstreiber

Abb. 9.4. Architektur der Gerätesoftware

I/O-Treiber

Motor-Interface

208

9 Die Einführung von QSM in einzelnen Unternehmen

Die Architektur der Gerätesoftware ist in drei Schichten aufgeteilt. In der oberen Schicht befinden sich die Anwendungsfunktionen und die Geräte-Basis-Funktionen. Die mittlere Schicht besteht aus dem Betriebssystem. Die untere Schicht besteht aus dem Speichertreiber, dem Kommunikationstreiber, dem I/O-Treiber und dem Motor-Interface. Anwendungsfunktionen

Geräte-Basis-Funktionen Gerätesteuerung

Positionierung

User Interface

Geräteprofile Kommunikationsprofile Elektrische Welle

Error-Handler

Systemdienste

Kurvenscheibe Datenhaltung Task 1

Task n

Funktions Bibliothek

Parameter Manager

Eventprotokolle

Windows-API

Windows

Speichertreiber

Kommunikationstreiber

I/O-Treiber

Motor-Interface

Abb. 9.5. Architektur mit Umgebungs-Simulation

Die PC-Simulation unterscheidet sich zunächst von der Gerätesoftware in der mittleren Schicht und der unteren Treiberschicht. Dort wurde das Betriebssystem des Zielgerätes durch das Microsoft WindowsBetriebssystem ersetzt (Abb. 9.5). Die Schnittstelle zu den Anwendungsfunktionen bildet eine proprietäre Windows-API. Dies ermöglicht es, die Geräte-Basis-Funktionen unverändert zu lassen. Aus Sicht der Typprüfung bestehen noch zwei weitere Anforderungen. Erstens müssen die digitalen und analogen Ein- und Ausgänge simuliert werden. Diese Anforderung wurde durch die Verwendung eines „shared memory“ realisiert. Sowohl die PC-Simulation als auch die Typprüfsoftware können gemeinsam darauf zugreifen. Die zweite Anforderung ist die Simulation der MotorRegelung. Für die meisten Testfälle ist eine einfache Motorsimulation ausreichend, bei der die Ist-Drehzahl der Soll-Drehzahl gleich gesetzt wird. Darüber hinaus werden noch einige zusätzliche Statussignale, z.B. maximaler Motorstromfluß oder Motorstillstand, simuliert. Damit ist die PC-Simulation prinzipiell unabhängig von einer Hardwareplattform ausführbar.

9.2 Simulation zu Testzwecken

209

Bei jedem Buildprozess werden sowohl die Software für das Zielsystem als auch die für die PC-Simulation kompiliert. Der Zielsystemcompiler erzeugt die Gerätesoftware als Binary-Datei. Der Microsoftcompiler generiert die ausführbare PC-Simulation. Die Unit-Tests sind reine Modultests bei denen einzelne Funktionen und Module getestet werden können. Diese werden für das jeweilige Zielsystem kompiliert. Generell wird der gesamte Sourcecode incl. der Testfunktionen kompiliert. Der Aufwand für die beschriebene Anpassung der Gerätesoftware betrug ca. 2 Mannmonate. Der Codeanteil der PC-Simulation an der Gesamtsoftware beträgt ca. 5 – 10 %. Anpassung der Typprüfsoftware. Anstatt den realen Prüfstand und den realen Prüfling an die PC-Simulation anzupassen, wurde die Typprüfsoftware modifiziert. Die Typprüfsoftware erhielt als Ergänzung die Möglichkeit, das Zielsystem auszuwählen. Dadurch können spezielle Schnittstellen und allgemeine Testscriptprozeduren aktiviert werden, die nur mit der PCSimulation zusammenarbeiten. Durch eine einfache Auswahl des Zielsystems innerhalb der Typprüfsoftware kann ein und dasselbe Prüfscript sowohl gegen die PC-Simulation als auch gegen das reale Gerät am realen Typprüfstand getestet werden. Möglich wurde dies durch eine Erweiterung der Typprüfsoftware. Die Steuerklemmen werden durch einen „shared memory“ simuliert. Ist als Zielsystem die PC-Simulation ausgewählt, werden nicht die physikalischen Klemmen des Typprüfstandes angesteuert, sondern die Speicherstellen beschrieben, auf die die Steuersignale der PC-Simulation zugreifen. Von zentraler Bedeutung sind die Kommunikations-Schnittstellen Ethernet, CAN und RS 232. Über diese Schnittstellen können die Tests ebenfalls vollständig durchgeführt werden. Hierbei ist es auch möglich, die PC-Simulation auf einem anderen Rechner als dem Testrechner ablaufen zu lassen. Das Ein- und Ausschalten des realen Prüflings (Netzschalter) wird vereinfacht durch das Aufrufen und Schließen der PC-Simulation nachgeahmt. Erstellung der Testscripte. Für ca. 50 % der Testfälle war die Erstellung der Testscripte für die PC-Simulation identisch mit denen für das reale Gerät. Hierbei können die gleichen Werkzeuge und das gleiche Vorgehen angewendet werden.

210 9.2.5

9 Die Einführung von QSM in einzelnen Unternehmen Bewertung

Die Einführung der QSM „Simulation zu Testzwecken“ bei der Lenze AG gestaltete sich äußerst erfolgreich. Sowohl die Modularisierung der Gerätesoftware als auch die vollständige Simulation der HW-nahen Schichten auf PC-Basis konnte erfolgreich durchgeführt werden. Die beiden obersten Ziele, die Vorverlagerung der Testscripterstellung in sehr frühe Entwicklungsphasen und die Wiederverwendung dieser Testscripte über alle Entwicklungsphasen hinweg, wurden erreicht. Bereits vier Monate vor Verfügbarkeit der Zielhardware konnten mit der PCSimulation Testscripte erstellt und erprobt werden. Dieser Zeitraum wurde dazu genutzt, bereits 50% der wiederverwendbaren Testfälle zu erstellen und auszuführen. Die Umstellung von PC-Simulation auf Zielhardware erforderte lediglich 15% der Testscripte geringfügig zu überarbeiten. Der Aufwand dafür betrug nur 12 Mann-Stunden. Bereits einige Tage nach Bereitstellung der Hardware und Portierung der Gerätesoftware auf das Zielsystem war ein funktionsfähiges und verifiziertes System vorhanden. Wichtige Aussagen zum Projektfortschritt (Funktionsumfang, Kosten, Termine, Qualität) konnten bereits von Beginn an gemacht werden. Die Testabdeckung, in diesem Fall mit dem Werkzeug Pure Coverage, konnte ebenfalls wesentlich früher als üblich ermittelt werden. Bereits unmittelbar nach Fertigstellung konnten alle Softwaremodule integriert werden. Die übliche Verzögerung dieser Arbeiten in Richtung Projektende bzw. bis zum Zeitpunkt der Bereitstellung der Hardware konnte vermieden werden. Vorhandene Fehler konnten somit schon sehr früh in der Wertschöpfungskette erkannt und abgestellt werden. Die durchweg guten Erfahrungen mit der QSM „Simulation zu Testzwecken“ können wie folgt zusammengefasst werden: • Simulations-Eigenschaften wachsen schrittweise mit dem Projekt. Es wird nur das simuliert, was zu diesem Zeitpunkt benötigt wird. • Unterstützung einer iterativen Vorgehensweise • Simulation ist erweiterbar auf andere Arbeitsplätze • Geringer Einrichtungsaufwand am Entwicklungs- und Test-Arbeitsplatz • Robuste Umgebung, keine Materialgefährdung • Unmittelbares Feedback für Entwickler und Tester • Plattform wird firmenintern erweitert, Auftragsarbeiten sind wegen des damit zusammenhängenden Zeitverzugs hinderlich • Tester können sich gut auf realen Prüfling vorbereiten • Regressions-Tests sichern SW-Portierung auf Ziel-Hardware ab

9.2 Simulation zu Testzwecken 9.2.6

211

Praktische Tipps

Bei der Simulation zu Testzwecken muss genau analysiert werden, welche Komponenten mit welchen Funktionen und welcher Genauigkeit nachgebildet werden sollen. Die zu simulierenden Funktionen sollten modular in der Software implementiert und sauber vom restlichen Code getrennt sein. Die Module können dann durch den Compiler durch Funktionsaufrufe der simulierten Funktionen ersetzt werden. Die übrige hardwareunabhängige und nicht zu simulierende Funktionalität ist so identisch mit der Zielsystem-Software. Dadurch bedürfen auch die Testscripte für diese Programmteile keiner Änderung. Die Trennung zwischen hardwarespezifischen und hardwareunabhängigen Programmcodes hat nicht nur Vorteile für die Simulation auf einem PC, sondern auch für die Portierung auf andere Hardware-Zielsysteme.

212

9 Die Einführung von QSM in einzelnen Unternehmen

9.3

Prozessdefinition mit dem project>kit

Kapitel 9.3 beschreibt die Anpassung und Weiterentwicklung des bestehenden Projektportals project>kit der Firma method park. Das Projektportal bietet eine einfache Orientierung im Prozessmodell und unterstützt eine lückenlose Dokumentation von Projektergebnissen und Entwicklungsschritten. Die Anpassungsarbeiten des project>kits betrafen zum einen die Funktionalität, andererseits aber auch die Integration eines Großteils der EQUAL-Projektergebnisse. Für den interessierten Leser gibt es die Möglichkeit, einen zusätzlichen Service zu nutzen. Interaktive Inhalte zum Verbundprojekt EQUAL sind unter www.embedded-quality.de abrufbar. Unter www.methodpark.de/download steht die jeweils aktuellste Version des projekt>kit zur freien Verfügung.

9.3.1

Allgemeine Projektbeschreibung

Definierte Entwicklungsprozesse und tatsächlich gelebte Projekte laufen in vielen Unternehmen auseinander. Das veraltete Konzept des papiergestützten Entwicklungshandbuches wurde deshalb durch ein flexibles Metamodell zur Definition von beliebigen Entwicklungsprozessen ersetzt. Diese werden datenbankgestützt verwaltet, in Form von einzelnen Projekten konkretisiert und durch den Projektleiter projektspezifisch angepasst. Wissensmanagement [57] im Projekt wird möglich, indem Wissen in Form von Prozessen und best practices modelliert, anschließend im Projekt angewendet und abschließend durch eine Projektnachbetrachtung (z.B. in Form der QS-Maßnahme Projektreview) weiter verfeinert und schließlich für zukünftige Projekte verfügbar gemacht wird. Diese Eigenschaften sind im web-basierten Projektportal project>kit der Firma method park vereint. Entscheidend für die Qualität und Nutzbarkeit eines solchen Projektportals sind die vorhandenen Inhalte. Die bestehenden Inhalte, die bereits auf langjährigen Erfahrungen basieren, wurden um die umfangreichen EQUAL-Projektergebnisse ergänzt. Zu diesen Zählen ebenso das in Kapitel 3.3 erläuterte 3-Ebenen-Vorgehensmodell wie auch Problembeschreibungen, QSM-Datenblätter und die Darstellung von QS-Maßnahmen aus der Praxis. Außerdem wurde das projekt>kit hinsichtlich Bedienung und Funktionalität grundlegend überarbeitet.

9.3 Prozessdefinition mit dem project>kit 9.3.2

213

Ziele der project>kit Erweiterung

Bei der Anpassung des project>kit standen vor allem die Integration der EQUAL-Projektinhalte in das web-basierte Projektportal und die Unterstützung eines aktiven Prozesstailorings als Ziele im Vordergrund. Integration der EQUAL-Projektinhalte. Die in den Arbeitsgruppen gemeinsam erarbeiteten Ergebnisse des EQUAL-Projektes sollten im Projektportal zu einem strukturierten Prozess zusammengeführt, auf einfache Art und Weise verwaltet und an Projektteams verbreitet werden. Die Benutzeroberfläche sollte ansprechend gestaltet werden, um die Akzeptanz beim Benutzer zu erhöhen und eine übersichtliche Navigation durch die Projektinhalte zu ermöglichen. Insgesamt soll hierdurch die Wiederverwendung von EQUAL-Projektergebnissen in beliebigen mechatronischen Projekten ermöglicht werden. Aktives Prozesstailoring. Gerade in mechatronischen Projekten existieren unterschiedlichen Vorgehensweisen, die aufgrund verschiedener Projektklassen (Vorfeld-, Produkt-, Variantenentwicklung usw.) maßgeschneidert werden müssen. Diese jeweils unternehmens- bzw. projektspezifische Anpassung eines standardisierten Vorgehensmodells wird auch als Tailoring bezeichnet. Folglich sollte diese elementare Funktionalität so im project>kit implementiert werden, dass sie die Anpassbarkeit des Entwicklungsprozesses an die unterschiedlichen Projektklassen auf einfache Art und Weise unterstützt. Auf diese Tailoring-Funktion wird im Abschnitt „Konzept des project>kits“ noch eingegangen. 9.3.3

Integration der EQUAL-Ergebnisse ins project>kit

Im Folgenden werden das project>kit im Allgemeinen, das dahinter liegende Konzept, die Inhalte der EQUAL-Prozessdefinition und die generelle Anwendung im Projekt beschrieben. Vorstellung project>kit

Die Idee des bereits erwähnten Projektportals project>kit ist, die Prozessbeschreibung nicht nur als Handbuch zu sehen, das neben dem Arbeitsplatz steht. Stattdessen ist das project>kit der Arbeitsplatz an sich, d.h. die Bedienoberfläche für alle Aktivitäten, die auf Dokumentenebene im Projekt durchgeführt werden. Nur so wird der Prozess in das Projekt wirklich integriert. Das Projektportal project>kit ist in drei Bereiche (Module) aufgeteilt. Eine Schnellübersicht über einzelne Projekte erhält der Anwender im Be-

214

9 Die Einführung von QSM in einzelnen Unternehmen

reich „Auf einen Blick“. Dieser gibt einen Überblick über Projektziel, Rollenverteilung (Wer macht was) und erlaubt einen Schnellzugriff auf Projekt-Dokumente. Der Bereich „Process Workbench“ dient dem Anwender zur Modellierung und Pflege seiner Entwicklungsprozesse sowie zur Instanzierung dieser Prozesse in konkreten Projekten. Er hat die Möglichkeit, die Prozesse mit Hilfe der Tailoring-Funktion projektspezifisch anzupassen und kann praxiserprobte Entwicklungsprozesse als Prozessmodell für zukünftige Projekte wiederverwenden. Ein weiterer Bereich ist das „Infocenter“, das der effektiven Informationsverbreitung dient. Informationen über Prozessänderungen, neue Anforderungen, Terminpläne etc. erleichtern das Arbeiten in verteilten Teams, halten das Projekt auf dem neuesten Stand und dokumentieren gleichzeitig den Zeitpunkt einer Neuerung. Abb. 9.6 zeigt das Projektportal project>kit mit den bereits integrierten EQUAL-Projektergebnissen. Um es von jedem Arbeitsplatz ohne großen Aufwand nutzen zu können ist das Projektportal webbasiert.

Abb. 9.6. Projektportal project>kit mit Inhalten des EQUAL-Projekts

9.3 Prozessdefinition mit dem project>kit

215

Konzept des project>kits

Entwicklungsprozesse können mit Hilfe des project>kits modelliert und angepasst werden. Modellierung. Entwicklungsprozesse werden textuell beschrieben und gleichzeitig durch geeignete Prozesselemente modelliert [4]. Die Prozesselemente und deren Eigenschaften sind frei definierbar. Beispiele für Prozesselemente sind Phasen, Aktivitäten, Artefakte (Dokumente), Methoden, Rollen oder Werkzeuge. Des Weiteren ist es sinnvoll, einige Prozesselemente (z.B. Phasen, Aktivitäten oder Methoden) hierarchisch zu strukturieren. Auf diese Weise können auf oberster Ebene grobe Prozessstrukturen dargestellt werden. Auf den unteren Ebenen kann eine sehr feingranulare Strukturierung bis hin zur detaillierten Beschreibung einzelner Arbeitsschritte erfolgen. Ein anpassbares Meta-Modell, das die Assoziationen der Prozesselemente untereinander definiert, erlaubt die größtmögliche Flexibilisierung der Modellierung. Die Assoziationen innerhalb des MetaModells können dabei typisiert werden, so dass beispielsweise Aussagen wie „diese Rolle ist für folgendes Artefakt verantwortlich“, „diese QSMethode verhindert folgendes Problem“ oder „in dieser Phase werden folgende Artefakte erstellt“ frei definiert werden können. Auf diese Weise lassen sich eine Vielzahl von Prozess-Modellen, wie z.B. 3-EbenenVorgehensmodell, V-Modell97, Rational Unified Process (RUP) etc., beschreiben. Tailoring. Softwareintensive Produkte der Automatisierungstechnik zeichnen sich durch Kleinserien, Variantenvielfalt, Produktvielfalt und Flexibilität aus. Die sich daraus ergebenden Anforderungen an das Produkt müssen auch in der eingebetteten Software berücksichtigt werden, was zu einer Steigerung der Komplexität des Entwicklungsprozesses führt. Um diesen Entwicklungsprozess individuell für die in der allgemeinen Projektbeschreibung beschriebenen Projektklassen nutzen zu können, bedarf es einer Tailoring-Funktion, die im Rahmen des EQUAL-Projektes für das project>kit konzipiert und realisiert wurde. Im project>kit wird bei Projektbeginn eine Instanz (zunächst einmal eine Kopie) eines auszuwählenden Standardprozesses, d.h. ein konkreter Prozess für jedes Projekt, erzeugt. Da jedes Projekt einen auf die gegebene Aufgabe angepassten Prozess benötigt, kann dieser – ausgehend vom Standardprozess – nun auf das Projekt abgestimmt werden (Tailoring). Auch während des Projektes kann dieser Prozess noch weiter angepasst werden. Letzteres bietet sich insbesondere zu Beginn neuer Entwicklungsiterationen an. Auf diese Weise existiert zu jedem Zeitpunkt eine aktuelle Repräsentation des in jedem Projekt verwendeten Entwicklungsprozesses.

216

9 Die Einführung von QSM in einzelnen Unternehmen

Im Folgenden werden die wesentlichen Aspekte zur Durchführung eines Tailorings mit project>kit beschrieben: • Streichbedingungen: Streichbedingungen geben an, unter welchen Umständen Prozesselemente in einem Projekt beim Tailoring entfallen können. So muss z.B. die Rolle des Sicherheitsbeauftragten nicht besetzt werden, wenn im Projekt keine sicherheitsrelevanten Normen zu beachten sind oder keine schützenswerten Daten bearbeitet werden. Prozesselemente (wie z.B. Rollen und Methoden) können mit Streichbedingungen versehen werden, um sie z.B. einer der beiden Kategorien „kann durchgeführt werden“ oder „muss durchgeführt werden“ zuzuordnen. • Tailoring: Ein Prozess, der bereits für ein bestimmtes Projekt instanziiert wurde, kann den speziellen Gegebenheiten des Projektes angepasst werden. So ist es zum Beispiel möglich, bestimmte QS-Maßnahmen, die nicht benötigt werden, wegzulassen – oder umgekehrt bisher weggelassene, aber nun doch benötigte QS-Maßnahmen wieder durchzuführen. Um eine QS-Maßnahme weglassen zu können, muss entweder mindestens eine der vorgegebenen Streichbedingungen erfüllt sein oder es muss eine eigene Begründung angegeben werden. Dieses Tailoring wird durch den Projektleiter durchgeführt. • Tailoring-Assistent: Der Tailoring-Assistent hilft bei der Anpassung des Prozesses. Hierzu werden gezielt Fragen wie beispielsweise „Sind sicherheitsrelevante Normen zwingend?“ gestellt. Der Tailoring-Assistent erspart so dem Anwender die Navigation zu den einzelnen Prozesselementen und eine Streichung von Hand. Der Tailoring-Assistent stellt mit seinem Fragenkatalog eine Checkliste dar, d.h. er stellt auch sicher, dass der Anwender wichtige Kriterien für das Prozesstailoring nicht vergisst. Mit dem Tailoring-Assistenten wird ein effizientes Tailoring erst möglich. Ein Beispiel für das Tailoring wird im Abschnitt „Anwendung im Projekt“ gezeigt. Inhalte der EQUAL Prozessdefinition

Die in den einzelnen Arbeitsgruppen gewonnenen Ergebnisse, die sich zur Integration ins project>kit eigneten, verlangten eine Anpassung und Erweiterung des klassischen project>kit Metamodells. Wesentliche EQUALProjektergebnisse beschäftigen sich mit dem Thema Qualitätssicherung und lassen sich in folgende Dokumente unterteilen. • Datenblätter • QS-Maßnahmen in der Praxis • Problembeschreibungen

9.3 Prozessdefinition mit dem project>kit

217

Datenblätter bieten eine Beschreibung und einen gezielten Einblick in verschiedene analytische, konstruktive und organisatorische QSMaßnahmen. Einige dieser QS-Maßnahmen wurden von den Projektpartnern im realen Entwicklungsgeschehen eingesetzt und ausführlich in Form von QS-Maßnahmen in der Praxis beschrieben. Problembeschreibungen beinhalten eine Beschreibung von Risiken bzw. potenziellen Problemen im Entwicklungsalltag. Um diese Inhalte in einen geeigneten Konsens zu bringen, wurde das Standard-Metamodell von project>kit erweitert. Es geht nun davon aus, dass in einer Entwicklungsphase ein oder mehrere Probleme auftreten können. Diese Probleme lassen sich durch QS-Maßnahmen reduzieren oder eventuell ganz vermeiden. Die QS-Maßnahmen wirken also dem Problem unterschiedlich stark entgegen. Deshalb wurden im EQUALMetamodell (siehe Abb. 9.7) noch Wirksamkeitsstufen (hohe, mittlere und geringe Wirksamkeit) definiert. Ein Beispiel hierfür wäre: In der Anforderungsanalyse (Phase) wurden Anforderungen fehlerhaft erfasst (Problem). Eine QS-Maßnahme mit sehr hoher Wirksamkeit zur Vermeidung dieses Problems ist unter anderem „Review / Inspektion“, durch die ein Review-Protokoll (Artefakt) erstellt wird. Zu dieser analytischen QS-Maßnahme liegt neben dem Datenblatt noch eine Praxisbeschreibung vor. Im Gegensatz hierzu trägt die konstruktive QS-Maßnahme „Simulation zur Anforderungsabsicherung“ nur einen geringen Anteil (einschließlich Kosten/Nutzen-Verhältnis) zur Vermeidung diesen Problems bei. ergibt sich in

Phase

Problem

w du

el

t ite be ar

t er zi

er

st er

üb

re

ird

ird w in lt

in

wird angewandt zur Erstellung von

QS-Maßnahme

tm ite ar be

be ex sc e m hr p ie la be ris n ch du rc h

it

ch or tli w an t is tv er

t

Abb. 9.7. Meta-Modell: EQUAL

Praxisbeschreibung

r ie ris te ak rch ar d u

Rolle

ch

an

fü

r

Artefakt

Datenblatt

218

9 Die Einführung von QSM in einzelnen Unternehmen

Anwendung im Projekt

Um die Verwendung des project>kits in einem Projekt anzudeuten, werden nachfolgend die Verwendung von Problembeschreibungen, die Durchführung des Tailoring, die Integration der Projektdokumentation und allgemein die Benutzeroberfläche erläutert und mit Hilfe von Screenshots verdeutlicht. Problembeschreibungen. Die Problembeschreibungen sind nach Phasen gruppiert, in denen sie entstehen können (Abb. 9.8). Beispielsweise ist für die Anforderungsanalysephase typisch, dass hier Anforderungen mit geringer Qualität spezifiziert werden. Dies kann sich unterschiedlich äußern, z.B. in Form von unvollständigen Anforderungen fehlerhaften Anforderungen, nicht eindeutigen Anforderungen, oder aber auch der gegenteiligen Ausprägung, nämlich einer Überspezifikation. Durch Verfolgen eines Hypertextlinks wird der Benutzer zu einer konkreten Problembeschreibung geführt (Abb. 9.9).

Abb. 9.8. Problemkatalog

9.3 Prozessdefinition mit dem project>kit

219

Die ausführliche Problembeschreibung umfasst sowohl eine genauere Erläuterung des Problems als auch eine Auflistung vorgeschlagener Gegenmaßnahmen. Diese sind nach der Einstufung ihrer Wirksamkeit gruppiert (Abb. 9.9). Folgt man dem Hypertextlink der jeweiligen Maßnahme, gelangt man zu einer detaillierten Beschreibung.

Abb. 9.9. Problembeschreibung und vorgeschlagene Gegenmaßnahmen

Durchführung des Tailoring. Der Projektleiter hat die Möglichkeit, z.B. Rollen je nach Bedarf ein- oder auszublenden. Diese sind dann für die anderen Projektbeteiligten nicht sichtbar und werden auch keiner bestimmten Person zugeordnet. Die nachfolgende Abb. 9.10 zeigt zunächst, wie Streichbedingungen in project>kit definiert werden können. Für die Rolle „Produktionsplaner“ ist beispielsweise zu entscheiden, ob diese im aktuellen Fall benötigt wird. Dies kann davon abhängig sein, ob für ein Produkt neue Mechanik-Komponenten benötigt werden oder ob ausschließlich alte Komponenten wiederverwendet werden können. In Abhängigkeit der Beantwortung durch den Projektleiter kann die Rolle Produktionsplaner eventuell ausgeblendet werden.

220

9 Die Einführung von QSM in einzelnen Unternehmen

Abb. 9.10. Definition von Streichbedingungen

In Abhängigkeit der definierten Streichbedingungen werden dem Benutzer gegebenenfalls mehrere Auswahlmöglichkeiten präsentiert (Abb. 9.11). Der Tailoring-Assistent bietet zusätzlich die Möglichkeit, eine individuelle Begründung für das Weglassen der Rolle „Produktionsplaner“ zu hinterlegen.

Abb. 9.11. Anpassung des Prozesses mit dem Tailoring-Assistenten

9.3 Prozessdefinition mit dem project>kit

221

Abb. 9.12 zeigt, wie sich das durchgeführte Tailoring in der Prozessdefinition konkret auswirkt. So ist beispielsweise die Rolle „Produktionsplaner“ sichtbar und weiterhin mit Informationen hinterlegt, jedoch für die Zuordnung zu Dokumenten explizit als „gestrichen“ markiert.

Abb. 9.12. Grafische Darstellung der Streichung

Integration der Projektdokumentation. In einem Entwicklungsprojekt sind nicht nur Aspekte, wie sie zum Zeitpunkt der Prozessdefinition betrachtet werden, von Bedeutung, sondern zusätzliche während der Projektlaufzeit anfallende Informationen. Während bei der Prozessdefinition eher gefestigte Arbeitsregeln berücksichtigt werden, stehen während der Laufzeit Informationen wie Besprechungs- und Review-Protokolle, Change Requests, schriftliche Absprachen etc. im Vordergrund. Für diese Art von Informationen hat sich im Projektmanagement das sog. Projektlogbuch bewährt. Für ein Projektteam sind sowohl Arbeitsregeln als auch das Projektlogbuch von essentieller Bedeutung und im Konzept des project>kits miteinander verbunden. Dieses Konzept erlaubt es auch, Veränderungen am Entwicklungsprozess, die in der Regel im Tagesgeschäft untergehen, an alle Projektbeteiligten zu kommunizieren. Darüber hinaus können diese gesammelten Informationen am Projektende als Diskussionsgrundlage herangezogen werden, um den Effekt der Prozessänderungen zu evaluieren und Erfahrungen für zukünftige Projekte in den Standard-Entwicklungsprozess einfließen zu lassen.

222

9 Die Einführung von QSM in einzelnen Unternehmen

Um die Beschreibung des Entwicklungsprozesses mit Inhalten zu füllen und das angestrebte Ziel einer vollständigen Integration von Projekt und Prozess zu erreichen, ist es notwendig, alle während des Projekts entstehenden Artefakte ebenfalls in die Prozessinstanz zu integrieren. Auf diese Weise erlangen alle Projektbeteiligten uniformen Zugriff auf alle notwendigen Dokumentvorlagen und Checklisten. Abb. 9.13 zeigt beispielsweise einen Ausschnitt aus der Artefaktbeschreibung „Projektplan“. Die hinterlegten Dokumentvorlagen (z.B. Word-Dokumente), Beispiele und Checklisten zum Projektplan sind integriert und im direkten Zugriff nutzbar. Über den Hypertextlink „Neue Dokumentinstanz“ kann innerhalb des Projektportals ein neuer Projektplan angelegt werden.

Abb. 9.13. Artefaktbeschreibung Projektplan

Eine optimale Lösung für die Integration der Projektdokumentation ist dann erreicht, wenn innerhalb einer Prozessbeschreibung nicht nur die Zuordnung von Aktivitäten vorhanden ist, sondern auch Dokumentvorlagen, Beispiele und Checklisten für jedes Artefakt hinterlegt sind. project>kit bietet darüber hinaus auch das Ein- und Auschecken aus dem zugrunde liegenden Konfigurationsmanagementsystem an sowie den Zugriff auf die aktuelle Version und die Historie eines Artefaktes. Benutzeroberfläche. Projektteams müssen durch den Prozess geleitet werden und brauchen einen zentralen Zugang zu allen wichtigen Informa-

9.3 Prozessdefinition mit dem project>kit

223

tionen. Zudem werden Projekte heute häufig über mehrere Standorte verteilt durchgeführt. Ein web-basiertes Projektportal [14, 50] schafft den direkten Zugang zu den Prozesselementen und damit zum Projekt inklusive der im Projektlogbuch verwalteten Informationen. Durch die personalisierte Präsentation, die der spezifischen Rolle des Mitarbeiters im aktuellen Projekt angepasst ist, hat jeder Anwender schnellen Zugriff auf die für ihn relevanten Informationen. Da der Prozess quasi selbst als Benutzeroberfläche erscheint, reduziert sich die Gefahr, dass das Projektteam etwas vergisst, erheblich. Das Unternehmen erhält eine hohe Transparenz über seine Projekte. Dies wiederum erleichtert die Bewertung und Priorisierung der Projekte und trägt somit zur Verbesserung des übergeordneten Projektmanagements bei. Schließlich ist der einfache Zugang zu allen Informationen eines Softwareprojekts entscheidend für die Akzeptanz eines Entwicklungsprozesses innerhalb des Projektteams [14]. Lernen im Projekt. Eine wichtige Voraussetzung für eine praxisnahe Prozessmodellierung ist, die vorgegebenen Entwicklungsprozess-Modelle ständig auf ihre Einsatzfähigkeit in konkreten Projekten zu überprüfen und gegebenenfalls anzupassen. Die beschriebene Vorgehensweise ermöglicht es nun, diesen Abgleich zu jedem Zeitpunkt vorzunehmen. Insbesondere nach Projektende können Projektleiter und Qualitäts- bzw. Prozessverantwortliche die Vor- und Nachteile der vorgenommenen Abweichungen vom ursprünglichen Prozess-Modell gemeinsam bewerten. Die Ergebnisse können dann entweder in eine Erweiterung des ProzessModells einfließen oder zur Definition eines weiteren Prozess-Modells führen. Auf diese Weise entsteht mittelfristig eine Bibliothek von ProzessModellen, die für verschiedene Projektvoraussetzungen bereits vorkonfektionierte Prozess-Modelle vorhält (z.B. Entwicklungsprojekte für verschiedene Projektgrößen, Entwicklungsprojekte nach bestimmten Qualitätsstandards, Innovationsprojekte). Prozess-Modelle Iterativ-inkrementelle Prozessmodelierung Projekte

Abb. 9.14. Lernzyklus bei interativ-inkrementeller Prozessmodellierung

224 9.3.4

9 Die Einführung von QSM in einzelnen Unternehmen Zusammenfassung

Im Rahmen des Pilotprojektes bei der Firma method park entstanden die folgenden wesentliche Ergebnisse: • Metamodell zur Modellierung des EQUAL-Entwicklungsprozesses • Funktionserweiterung des Projektportals um eine TailoringFunktionalität • Umsetzung der EQUAL-Projektergebnisse in das Projektportal Mit diesem realisierten System lassen sich definierte Entwicklungsprozesse für einzelne konkrete mechatronische Projekte instanziieren und individuell anpassen. Die im Prozess definierten Rollen können anschließend im Projekt konkrete Ergebnis-Verantwortlichkeiten von Personen regeln. Zugriffsrechte auf die damit in Verbindung stehenden Projektergebnisse können vergeben werden. Der Entwicklungsprozess ist durch das project>kit die zentrale Kommunikationsplattform der Projektmitarbeiter. Hierdurch wird eine größtmögliche Konformität zwischen definiertem Prozess und gelebtem Projekt erreicht. Dies leistet einen wichtigen Beitrag zur Prozessqualität in Projekten.

9.4 Modellbasierter Funktionstest regelungstechnischer Software

9.4

225

Modellbasierter Funktionstest regelungstechnischer Software

Das in diesem Kapitel beschriebene Pilot-Projekt beschäftigte sich mit der modelbasierten Testfallgenerierung und automatisierten Testfalldurchführung für den Black-Box-Test von regelungstechnischer Software. An der Umsetzung dieser Methode waren die beiden Firmen Lenze und Validas maßgeblich beteiligt. Ausgangssituation war dabei eine komponentenorientierte, werkzeuggestützte Entwicklungsmethodik, bei der komplexe Regelungssysteme aus wieder verwendbaren und parametrierbaren Softwarekomponenten zusammengesetzt werden. Die Systembeschreibungen entsprechen dabei den in der Regelungstechnik verbreiteten Blockdiagrammen, wobei aber auch komplexe Blöcke mit nicht-kontinuierlichem Verhalten eingesetzt werden. Etwas vereinfacht gesehen besteht dabei jede Softwarekomponente aus zwei Teilen: 1. einer detaillierten Spezifikation, die das der Komponente zugrunde liegende Regelgesetz dokumentiert und die frei wählbaren Parameter der Komponente aufführt, 2. dem ausführbaren Code der Komponente, der von Hand in C oder Assembler programmiert wurde und in Bezug auf die Rechenzeit stark optimiert ist. Ziel des Projektes war es, modellbasierte Testfallerzeugungstechniken an regelungstechnischen Systemen zu erproben, um den KomponentenCode automatisch gegen die Komponentenspezifikation zu prüfen. Bei den hierfür durchzuführenden Tests handelt es sich um rein virtuelle Tests. Dies bedeutet, dass nur der Komponentencode überprüft wird, nicht jedoch die Steuergerätehardware oder die Kopplung von Steuergerät und zu steuernder Maschine. Das Projekt hatte den Charakter eines „Proof-of-concept“ und war nicht auf die direkte Übernahme in den Produktionsprozess ausgerichtet. Es lief von April 2002 bis April 2004 und hatte insgesamt einen Umfang von 10 Personenmonaten, aufgeteilt auf eine Anwenderfirma und ein Dienstleitungsunternehmen. Die Firma Lenze stellte die Fallstudie und das Anwendungswissen zur Verfügung. Die Firma Validas als Dienstleister brachte die notwendigen Erfahrungen mit CASE-Werkzeugen und modellbasierten Testverfahren ein.

226 9.4.1

9 Die Einführung von QSM in einzelnen Unternehmen Ziele des Pilotprojekts

Um einen hohen Wiederverwendungsgrad zu erzielen, werden die regelungstechnischen Softwarekomponenten einmal erstellt und dann für unterschiedliche Anwendungen wieder verwendet. Deshalb ist es lohnenswert, vergleichsweise viel Aufwand in die Qualitätssicherung der regelungstechnischen Softwarekomponenten zu stecken und nachzuweisen, dass das Verhalten einer Komponente dem durch ihre Spezifikation vorgegebenen Verhalten entspricht. Bei der manuellen Implementierung der Komponente können Diskrepanzen zwischen Komponentenverhalten und spezifiziertem Verhalten entstehen, da verschiedene nicht-triviale Optimierungen zur Reduktion der Laufzeit auf dem Zielsystem (Mikrocontroller) durchgeführt werden. Dazu zählt z.B. die Abbildung von Fließkommazahlen auf Festkommazahlen, wodurch es jedoch zu Genauigkeits- und Überlaufproblemen kommen kann. Im Rahmen des Projekts wurde die Spezifikation einer solchen Software-Komponente in einem CASE-Tool modelliert, daraus mittels erweiterter Simulationstechniken Testfälle erzeugt, die dann gegen die handgeschriebene Implementierung der Komponente geprüft wurden. Damit handelt es sich bei dem Projekt um eine Kombination zweier QS-Maßnahmen: • Black-Box-Komponententest: Die Struktur des Komponenten-Codes bleibt verborgen. Der Quellcode liegt zwar vor, wird aber nicht zur Gewinnung oder Bewertung von Testfällen herangezogen. • Regressionstest: Die Testfälle werden aus einem Modell der Spezifikation (die in einer früheren Entwicklungsphase erstellt wird) gewonnen und anschließend für den Code (der in einer späteren Entwicklungsphase erstellt wird) wieder verwendet. In gewisser Weise dient das Modell also als eine frühe nicht-optimierte Implementierung, die von zahlreichen Aspekten der späteren Komponentensoftware (z.B. die Anbindung an das Betriebssystem des Steuergeräts) abstrahiert und die in einer domänen-spezifischen Sprache erstellt wird – hier ein CASE-Tool mit einer Eingabesprache, die die vergleichsweise direkte Umsetzung von regelungstechnischen Blockdiagrammen erlaubt. Ein weiteres, untergeordnetes Ziel des Projektes war es, die Eignung von ausführbaren Modellen in CASE-Tools auch zur Dokumentation von Komponenten zu prüfen. Prinzipiell bieten ausführbare Modelle darüber hinaus für sich schon einen Nutzen, wenn sie als konstruktive QSMaßnahme (Simulation zur Überprüfung von Anforderungen und Designentscheidungen) verwendet werden, dieser Aspekt wurde in diesem Projekt nicht näher betrachtet.

9.4 Modellbasierter Funktionstest regelungstechnischer Software 9.4.2

227

Planung des QSM-Einsatzes

Durch die präzise Dokumentation der Regelgesetze in der Komponentenspezifikation bot sich im Projekt ein ideales Umfeld für die Kombination von Black-Box-Test und Regressionstest. Die Hauptschwierigkeit beim Black-Box-Test, nämlich die Bereitstellung der erforderlichen Testfälle, lässt sich durch den Einsatz eines ausführbaren Simulationsmodells umgehen. Die Fähigkeiten einiger CASE-Tools erlauben es, aus einem solchen Modell effizient Testfälle zu generieren. Die größte Herausforderung für einen solchen modellbasierten Test ist die Erstellung eines hinreichend genauen Modells. An dieser Stelle ist eine vorgegebene, möglichst präzise Komponentenspezifikation erforderlich. Für die Realisierung des modellbasierten Funktionstests ergeben sich die folgende Arbeitspakete: • Werkzeugauswahl: Um einerseits Lizenzkosten für kommerzielle Werkzeuge zu vermeiden und andererseits das vorhandene Wissen bei den beteiligten Firmen zu nutzen, fiel die Wahl der Werkzeuge auf das frei verfügbare CASE-Tool AutoFOCUS als Modellierungswerkzeug und die verbreitete Scriptsprache Perl zur Implementierung des Testbetts. Prinzipiell lassen sich aber alle marktüblichen Werkzeuge verwenden. • Modellerstellung: Die Erstellung eines Modells der Komponenten anhand der Komponentenspezifikation. Dieser Schritt wurde durch die präzise Dokumentation der Komponenten (Blockdiagramme) wesentlich erleichtert. • Testfallgenerierung: Bei der Generierung von Testfällen aus dem Modell ist die Konkretisierung einer abstrakten Beschreibung erforderlich. • Testbettimplementierung: Erstellung eines Testbettes und Einbettung des Komponenten-Codes. Die Umsetzung der Arbeitspakete erfolgte durch einen Domänenexperten sowie je einem Modellierer und Testbett-Entwickler. Eine Schulung für die angewendeten Methoden und Werkzeuge war nicht erforderlich, da die erforderlichen Kenntnisse bei den beteiligten Personen bereits vorhanden waren. Für die endgültige Integration des modellbasierten Funktionstests in den Produktentwicklungsprozess wäre ein gewisser Schulungsaufwand erforderlich, der sich allerdings durch das schematische Vorgehen bei der Modellerstellung und Testfallgenerierung in Grenzen hält. Im Projekt wurden die Arbeitspakete Modellerstellung, Testfallerzeugung, Konstruktion des Testbetts und Testdurchführung vor allem von der Dienstleistungsfirma, unterstützt von dem Domänenexperten der Anwenderfirma, durchgeführt.

228

9 Die Einführung von QSM in einzelnen Unternehmen

Bezogen auf einen Produktiveinsatz im Unternehmen würde sich die folgende Aufgabenteilung anbieten: • Der Dienstleister erstellt das Testbett. Dies ist im Wesentlichen eine einmalig durchzuführende Aufgabe. • Der Anwender generiert – gegebenenfalls mit Coaching durch den Dienstleister – die Testfälle und führt die Tests selbst durch. • Die Modellerstellung erfolgt entweder durch den Anwender oder den Dienstleister: In günstigen Fällen, wie z.B. bei der Projektfallstudie, lassen sich die Modelle schematisch aus der Softwaredokumentation erstellen (im Idealfall ist das Modell dann sogar Bestandteil der Dokumentation, siehe Abschnitt 9.4.4); nach einer gewissen Einarbeitungszeit kann dann der Anwender die nötigen Modelle selbst erstellen. Ist die Divergenz zwischen Dokumentation und Modell größer, wird der Dienstleister diese Aufgabe übernehmen. 9.4.3

Durchführung der QSM

Die Beschreibung der Durchführung gliedert sich in die Vorbereitung und Anwendung der QS-Maßnahme. Vorbereitung der QSM

Bei der automatischen, modellbasierten Erzeugung von Testfällen ist die Erstellung des Simulations-Modells die zentrale Aufgabe. Bei eher diskreten eingebetteten Systemen (z.B. Smartcards, Fehlerbehandlung in Automobilsteuergeräten) hat sich dabei die automatische Testfallsuche aus Modellen anhand abstrakter Testfallspezifikationen bewährt. Für softwarebasierte Regelungen mit eher zeitkontinuierlichem Charakter lassen sich diese Techniken aber aufgrund des durch die erforderlichen langen Testsequenzen enorm großen Suchraums nicht direkt anwenden. Für dieses Projekt wurde daher ein zweistufiger Ansatz vorgeschlagen, der neben dem eigentlichen Modell der regelungstechnischen Komponente eine sehr abstrakte Szenariobeschreibung vorsieht. Die Szenariobeschreibung dient dazu, das Komponentenmodell zu steuern, um damit Testsequenzen für jedes einzelne Szenario zu erhalten. Dieser Ansatz ist in Abb. 9.15 dargestellt.

9.4 Modellbasierter Funktionstest regelungstechnischer Software

Szenariobeschreibung

Abstraktion / Konkretisierung

229

1. Aufstart 2. Normalbetrieb 3. Inversion 4. Nothalt 5. ...

Konkretisierer

Abstrahierer

Modell

Testfälle Test-Sequenzen

Abb. 9.15. Szenario-Gestützte Testfallerzeugung

Szenariobeschreibung und Komponentenmodell unterscheiden sich im Grad der Abstraktion. Deshalb müssen zunächst die Eingabebestandteile des Szenarios konkretisiert werden, um als Stimuli für das Modell dienen zu können. Die Ausgaben des Modells müssen entsprechend abstrahiert werden, um sie mit den erwarteten Ausgabebestandteilen des Szenarios zu vergleichen. Das Modell wird solange mit unveränderten Stimuli gesteuert, bis die Ausgaben ein bestimmtes Kriterium erfüllen (z.B. im Projekt: Stabilisierung der Modellausgaben nahe einem Sollwert). Die Reaktion des Simulations-Modells wird mitprotokolliert und als Testfall in einer Textdatei gespeichert. Auf diese Weise lassen sich aus sehr kompakten Szenarien lange regelungstechnische Testfälle erzeugen. Im nächsten Schritt musste die Komponentensoftware in ein Testbett eingebettet werden, welches eine Verbindung zwischen Testautomat und Testobjekt herstellt. Der Testautomat stimuliert anhand der Testfallbeschreibung die regelungstechnischen Softwarekomponenten und vergleicht die Reaktionen mit den erwarteten Ausgaben. Der Komponentencode liegt in der Programmiersprache C vor. Die Testfälle sind gewöhnliche Textdateien, die in jeder Zeile ein Stimulus / Ausgabe-Paar enthalten. Die Stimuli und die erwarteten Ausgaben in der Textdatei lassen sich allerdings nicht direkt an den C-Code weitergeben, da zunächst eine Abbildung von Sig-

230

9 Die Einführung von QSM in einzelnen Unternehmen

nalnamen des Testfalls auf Variablennamen des C-Codes erforderlich ist. Ebenso muss eine Umrechnung von den Fließkommawerten des Testfalls auf die Festkommawerte des C-Codes erfolgen. Für die vollständige Signaladaption benötigt das Testsystem (Abb. 9.16) die folgenden Erweiterungen: • Ein Parser für die Testfalldateien • Ein Konkretisierer und Abstrahierer, der die Zahlenwerte transformiert. In diesem Fall vergleicht der Abstrahierer auch den Sollwert der Testfälle mit dem Istwert der Software-Komponente und liefert das Verdikt des Tests. • Eine komponentenabhängige Schnittstelle, die Signal- und Variablennamen in Beziehung setzt. Textuelle Testfallbeschreibung

Testfall-Parser

Test-Sequenzen

5,23

3,23

I

O

Konkretisierer

Abstrahierer

I‘ 134

mov cx, [bx] jcxz delmemretn push es ax mov ah,49h mov es, cx int 21h

Verdikt

O‘ 83

Abb. 9.16. Aufbau des Testsystems

Das Testbett wurde wegen des im Vergleich zu klassischen Programmiersprachen wie C oder Java geringeren Programmieraufwandes (insbesondere bei der Verarbeitung der textuellen Testfallbeschreibungen) in einer Scriptsprache implementiert. Die Wahl fiel hier auf die Sprache Perl, da sie in beiden beteiligten Firmen bereits im Einsatz war. Die Komponen-

9.4 Modellbasierter Funktionstest regelungstechnischer Software

231

tensoftware selbst wurde über einen SWIG-Schnittstellengenerator5 eingebunden, der aus C-Code Header-Dateien die für die Scriptsprache erforderlichen Schnittstellen generiert. Die Erstellung des Testbetts ist für jede Systemklasse nur einmal notwendig und kann deshalb von Dienstleistungsfirmen übernommen werden. Allerdings müssen dazu Konkretisierer und Abstrahierer parametrierbar sein, um z.B. Fliesskommazahlen auf unterschiedliche Festkommaformate umrechnen zu können (hierzu müssten für jedes Signal mit Fließkommawerten beispielsweise Unter- und Obergrenze sowie entweder die gewünschte Auflösung oder Größe des Festkommaformats wählbar sein). Auch die Zuordnung von Signalnamen im Modell zu Variablennamen im Komponentencode muss parametrierbar sein. Dies wird durch klare Schnittstellenvereinbarungen und Namenskonventionen erleichtert. Im durchgeführten Projekt wurde diese Kopplung allerdings individuell von Hand hergestellt. Anwendung der QSM

Wie in Abschnitt 9.4.2 beschrieben, bestand die eigentliche Projektdurchführung aus den folgenden Aktivitäten: Modellerstellung, Testfallgenerierung und Testdurchführung. In diesem Abschnitt werden diese drei Aktivitäten kurz dargestellt. Modellerstellung. Da die Komponentenspezifikation bereits – wie in der Regelungstechnik üblich – als ein Blockdiagramm vorlag, konnte die Struktur der Spezifikation direkt als Vorlage für die Modellspezifikation verwendet werden. Abhängig vom verwendeten Modellierungswerkzeug müssen dabei verschiedene Aspekte verändert werden. Für AutoFOCUS hielten sich die strukturellen Änderungen in Grenzen, beispielsweise sind die Signale mit Typangaben erweitert („Float“ – Fliesskommawerte; „Signal“ – reine An- oder Abwesenheit von Informationen, z.B. für Schalterstellungen; „Bool“ – Wahrheitswerte, also „True“ oder „False“). Zusätzlich wurde das Modell um einige weitere Ausgabesignale erweitert, damit auch interne Signale bei Simulationsläufen festgehalten werden. Abb. 9.17 zeigt die Struktur des Modells. Der Signalfluss ist im wesentlichen von links nach rechts. Die Signale, die vom Modell ausgehend nach oben deuten, sind die erwähnten Ausgaben der internen Signale.

5

www.swig.org

232

9 Die Einführung von QSM in einzelnen Unternehmen

Abb. 9.17. Struktur des regelungstechnischen Modells

Während die Modellstruktur sich sehr stark an die Spezifikation anlehnt, musste das Verhalten der einzelnen Komponenten neu festgelegt werden. Die Spezifikation baut auf vordefinierten, proprietären Blöcken und standardisierten Blöcken der Regelungstechnik auf (beispielsweise PT1Glieder). Für die Modellierung dieser regelungstechnischen Blöcke der Spezifikation in das Modell musste das Verhalten der Basisblöcke für ein synchrones Ausführungsmodell mit einem globalen, festen Zeitraster operationalisiert werden. Der folgende Code-Abschnitt zeigt die Definition eines solchen Zeitrasters: // // Time base: 1/10th sec. // dTInv : Float; const dTInv = 10.0; // Number of cycles in a time interval T: cycles: Float -> Float; fun cycles(T) = T * dTInv;

Der Code ist in der (funktionalen) Datentypsprache von AutoFOCUS geschrieben, ähnliche Formulierungen sind aber in den Sprachen anderer gängiger Werkzeuge mit nur geringem Mehraufwand möglich.

9.4 Modellbasierter Funktionstest regelungstechnischer Software

233

Auf der Grundlage dieser Zeitrasterdefinition lässt sich dann das Verhalten jeder Basiskomponente beschreiben, indem schrittweise die mathematische Funktion der Blöcke berechnet wird. Der folgende CodeAbschnitt zeigt diese Umsetzung am Beispiel eines PT1-Gliedes: // // S-Shape: // pt1K: Float; pt1T: Float; const pt1K = 1.0; const pt1T = 2.0; nextAcc: Float -> Float -> Float; fun nextAcc(acc,x) = acc+((pt1K*x)acc)/cycles(pt1T);

Zu den anderen Komponenten im Strukturdiagramm (Abb. 9.17) gibt es entsprechende Funktions- und Konstantendefinitionen. Insgesamt besteht das Modell aus ca. 150 Zeilen solcher Programmstücke. Einige Komponenten bestehen nicht nur aus einem einzelnen kontinuierlichen Regelgesetz, sondern zeigen abhängig von bestimmten Eingaben oder Parametern unterschiedliches Verhalten (z.B. Normalbetrieb vs. Nothalt). In solchen Fällen werden die diskreten Verhaltensanteile durch Zustandsmaschinen beschrieben, die – wie das Beispiel in Abb. 9.18 zeigt – meist eine relativ einfache Struktur haben.

Abb. 9.18. Zustandsmaschine zur diskreten Verhaltensmodellierung

234

9 Die Einführung von QSM in einzelnen Unternehmen

In solchen Diagrammen beschreibt jeder Pfeil die Anwendung einer unterschiedlichen Formel wie „nextAcc“ im PT1-Beispiel oben. Selbstverständlich können Zustandsmaschinen, anders als im obigen Beispiel, auch mehrere Zustände haben; für die im Projekt bearbeitete Komponente wurde das aber nur für die Modellierung einiger Schalterstellungen („ein“, „aus“) verwendet. Insgesamt besteht das Modell aus 19 Komponenten (davon 16 Basiskomponenten, die anderen drei Komponenten dienen nur der hierarchischen Strukturierung), 47 Signalen, 19 Transitionen und 21 benutzerdefinierten Funktionen wie „nextAcc“. Testfallgenerierung. Die Testfallgenerierung erfolgt nun, indem zunächst abstrakte Testszenarien von Hand erstellt werden. Im Projekt ist ein Szenario eine Folge von Stimuli / Sollwerten, die aber nicht direkt als Testfälle verwendet werden. Vielmehr wird das Modell für jeden Eintrag der Folge solange mit dem Stimulus angesteuert, bis die Modellausgaben den Sollwert erreicht haben, respektive bis sie den Sollwert bis auf eine wählbare Schwelle approximieren und innerhalb einer ebenfalls wählbaren Toleranzschwelle stabil sind. Das Ergebnis dieses „Model-In-the-Loop“Verfahrens ist nun für jedes Testszenario ein Testfall, bestehend aus Stimuli und Sollwerten für jeden Schritt in dem bei der Modellerstellung gewählten Zeitraster. Jeder Testfall wird in einer eigenen Testfalldatei gespeichert. Er besteht aus einer Folge von einzelnen Zeilen, bestehend aus Stimuli und Sollwerten. Stimuli sind die Paare aus Signalnamen und Wert, getrennt durch ein Fragezeichen. Die Sollwerte sind Paare aus Signalnamen und Wert, getrennt durch ein Ausrufezeichen, wie im folgenden Beispiel: dnTir?0.199519;bSShapeActive?True;NSet?99.998315; dnTif?0;NOut!2.407044;

Testdurchführung. Zur Testdurchführung musste zunächst die nötige Infrastruktur für das Testbett erstellt werden, die bereits im vorigen Abschnitt skizziert wurde. Um den C-Code der Softwarekomponente einzubinden, musste er noch geringfügig angepasst werden. So wurden die Aufrufe des Echtzeitbetriebssystems des Steuergerätes entfernt oder auf StubFunktionen abgebildet. Einige Parameter-Werte, die der Code aus dem EEPROM des Steuergerätes lesen würde, mussten durch Konstanten ersetzt werden. Darüber hinaus mussten einige Parameter zwischen Modell und Komponentencode abgeglichen werden. So wurde das Zeitraster von Modell und Code identisch gewählt. Diese Angleichung lässt sich bei Bedarf ver-

9.4 Modellbasierter Funktionstest regelungstechnischer Software

235

meiden, indem bei unterschiedlichen Zeitrastern die Signalverläufe interpoliert werden. Nach diesen Anpassungen konnten die Testfälle ausgeführt werden. Sie werden zeilenweise gelesen und in Stimulus und Sollantwort getrennt. Stimulus und Sollantwort werden in Festkommawerte umgerechnet. Der Code wird mit dem umgerechneten Stimulus aufgerufen und die beobachtete Antwort mit der Sollantwort des Testfalls verglichen. Das dynamische Verhalten von Komponente und Modell lässt sich auch wie in Abb. 9.19 gezeigt, graphisch darstellen.

Abb. 9.19. Visualisierung des Modellverhaltens

9.4.4

Bewertung

Der Vergleich zwischen dem Verhalten des Komponenten-Codes und dem des Spezifikations-Modells zeigte zunächst einige Abweichungen. Allerdings konnten diese Abweichungen auf eine inkorrekte Interpretation der Komponentenspezifikation bei der Modellerstellung zurückgeführt werden. Nach Berichtigung dieser Missinterpretation stimmten das erwartete

236

9 Die Einführung von QSM in einzelnen Unternehmen

und das beobachtete Verhalten überein. Dies macht das Konfliktpotential von einseitigen Annahmen zur Auflösung von Spezifikationsunsicherheiten deutlich. Eine frühe Rücksprache mit den Autoren der Spezifikation hätte diesen Fehler vermieden. Insgesamt konnte die prinzipielle Eignung der modellbasierten Testfallerzeugung für regelungstechnische Softwarekomponenten gezeigt werden. Für die praktische Umsetzung dieses Ansatzes sind allerdings noch weitere Arbeiten erforderlich. Der Aufwand für das Projekt erscheint relativ hoch, liegt aber in erster Linie in der Erstellung der nötigen Infrastruktur für das Testbett und in den Aufwänden für die Adaption der Komponentensoftware an das Testbett. Der Erstellung des Testbetts ist nur einmal durchzuführen und kann von einer Dienstleistungsfirma durchgeführt werden. Die Adaption der Software an das Testbett dagegen ist prinzipiell für jede Softwarekomponente notwendig. Dies kann natürlich ebenfalls an einen Dienstleister übertragen werden. Es ist jedoch vorteilhafter, durch stärkere Vereinheitlichung der Schnittstellen der Komponentensoftware die Anbindung an das Testbett schematischer, günstiger und somit für die Anwender beherrschbar zu machen. Das untergeordnete Projektziel – die Prüfung der Eignung von ausführbaren Modellen zur Komponentenspezifikation – ergibt ein eindeutigeres Ergebnis. Die Modelle sind fast deckungsgleich mit der Spezifikation. Mit gewissen Ergänzungen (im Wesentlichen die Parameter-Listen der Komponenten) eignen sie sich durchaus auch direkt zur Dokumentation der Komponentensoftware, insbesondere der zugrunde liegenden Regelgesetze. Aufgrund dieser Beobachtung sind Szenarien denkbar, unter denen sich die Kosten der Adaption der Komponentensoftware an das Testbett weiter reduzieren lassen. So ließen sich aus einem frühzeitig für die Dokumentation erstellten Komponentenmodell bereits die Schnittstellen für den später handgeschriebenen Code erstellen. So ließe sich auch die Anbindung des Code an das Testbett weitgehend automatisieren. Diese Umkehrung des im Projekt verwendeten Prozesses würde es auch erlauben, durch Simulation der Modelle bereits konstruktiv Anforderungen und die verwendeten Regelgesetze abzusichern. Die Nähe von Komponentenspezifikation und Modell hilft auch, die Kosten der Modellerstellung zu reduzieren, da diese Aufgabe weitgehend schematisch erfolgt und auch vom Anwender selbst übernommen werden kann.

9.4 Modellbasierter Funktionstest regelungstechnischer Software

237

Zusammenfassend lässt sich sagen, dass sich der Einsatz des im Projekt verfolgten Ansatzes unter folgenden Umständen anbietet: • Es gibt eine präzise Spezifikation von Softwarekomponenten, die sich mit vertretbarem Aufwand in ausführbare (und damit simulierbare) Modelle umwandeln lässt • Der eigentliche Software-Code wird manuell erstellt und enthält somit potentiell Fehler (z.B. durch Optimierungen) Unter diesen Umständen können mit dem Verfahren funktionale Unterschiede zwischen Spezifikation und Komponentensoftware aufgedeckt werden. Die Weiterverwendung der Testfälle für Tests von Steuergeräten und Maschinen im Sinne des virtuellen Funktionstests wurde im Projekt nur ansatzweise untersucht. Bei Systemen, die nicht ausschließlich aus Software bestehen, treten durch elektrische und mechanische Unsicherheiten Nichtdeterminismen auf, die einen Regressionstest gegen ein Modell erschweren. In gewissem Umfang lassen sich diese Unsicherheiten durch Modellierungstechniken behandeln (beispielsweise die Verwendung von Intervallen für Wert- und Zeitabschätzungen, siehe Abb. 9.20), eine umfassende Testmethodik liegt hierfür aber noch nicht vor. Wert

Zeit

Abb. 9.20. Toleranzintervalle im Werte- und Zeitbereich

Die Testszenarien wurden im Projekt von Hand erstellt. Denkbar ist es aber auch, solche Szenarien ebenfalls modellbasiert zu generieren, indem ein abstraktes Szenariomodell erstellt wird, das mögliche Betriebszustände und die Übergänge dazwischen beschreibt. Aus diesem Modell lassen sich dann mit einfachen Suchverfahren Testszenarien herleiten, die dann wie oben beschrieben durch den „Model-In-the-Loop“-Aufbau konkretisiert und somit zu Testfällen erweitert werden.

238 9.4.5

9 Die Einführung von QSM in einzelnen Unternehmen Praktische Tipps

Modellbasiertes Testen ist nur dann wirtschaftlich einsetzbar, wenn die Kosten für die Modellerstellung vergleichsweise niedrig sind oder zumindest die Testqualität messbar erhöht wird. Mangels einheitlicher Metriken zur Bewertung der Qualität einer Testfallmenge lassen sich zur Testqualität noch keine Aussagen machen. Klassische Aussagen zur CodeAbdeckung eignen sich für regelungstechnische Systeme vermutlich weniger, da der Code strukturell einfach ist, das Verhalten eines Systems aber durch die mathematischen Regelgesetze stark von den Eingangsdaten abhängt. Kernproblem bei der Modellerstellung ist – neben der reinen Größe eines Modells – die Wahl einer geeigneten Abstraktionsebene. Im Allgemeinen ist diese Wahl schwierig und hängt von verschiedenen Faktoren ab: • Abhängig vom Testziel muss der Schwerpunkt auf bestimmte Systemaspekte gerichtet werden, während andere Aspekte weggelassen werden können. • Abhängig vom Reifegrad des Testobjekts sind manche Aspekte zu einem gegebenen Entwicklungsstadium gar nicht testbar (weil z.B. bestimmte Hardware- oder Software-Komponenten noch gar nicht oder erst als Stubs realisiert sind). • Schließlich gibt es Grenzen der Beobachtbarkeit, da etwa das Testbett nur Messungen mit einer bestimmten Genauigkeit erlaubt; ein sehr detailliertes und präzises Modell ist hier eventuell unnötig. Für Regelungssysteme, wie die im Projekt bearbeiteten Komponenten, war diese Abwägung vergleichsweise einfach. Die Komponentenspezifikation konnte mehr oder weniger direkt als Modellierungsvorlage verwendet werden. Die Wahl von Fließkommaarithmetik war bedingt durch das Testziel, nämlich das Aufdecken möglicher Implementierungsfehler bei der Festkommarithmetik. Es ist auch zu prüfen, ob die Kosten der Modellerstellung relativiert werden können, indem die Modelle auch für andere Zwecke eingesetzt werden. Sie könnten bei frühzeitiger Erstellung beispielsweise auch als Grundlage der Komponentendokumentation dienen oder auch zum Prototyping komplexer Anwendungen. Es ist auch denkbar, aus diesen Spezifikationen Schnittstellenvorgaben zu generieren, die den Rahmen für die manuelle Implementierung vorgeben und auch die Anbindung an das Testbett erleichtern. Der Einsatz der Modelle sowohl für Codegenerierung als auch zum Testen der generierten Implementierung verbietet sich dagegen, da in diesem Fall eine Systembeschreibung gegen sich selbst getestet würde – hier fehlt die für das Testen nötige Redundanz zweier Beschreibungen.

9.5 Virtueller Funktionstest von PROFIBUS-Komponenten

9.5

239

Virtueller Funktionstest von PROFIBUSKomponenten

Ein Hilfsmittel für die frühzeitige, durchgängige und entwicklungsbegleitende Verifikation von Anforderungen ist der so genannte virtuelle Funktionstest, bei dem durch den Einsatz virtueller Techniken der Funktionstest in frühe Entwicklungsphasen vorverlagert werden kann. Diese Vorverlagerung umfasst sowohl die Generierung von Testfällen als auch die Ausführung dieser Testfälle. 9.5.1

Allgemeine Projektbeschreibung

Im Rahmen eines Pilotprojektes haben die Validas AG und der Lehrstuhl itm einen virtuellen Funktionstest für automatisierungstechnische Geräte mit PROFIBUS-Schnittstelle durchgeführt. Bestehende Testfälle wurden gegen eine reale Komponente und auch gegen eine virtuelle Simulation des zu testenden Gerätes geprüft. Die Prüfung des virtuellen Gerätes kann in der Praxis zeitlich vorverlagert werden, um so die Time-to-market zu verkürzen. 9.5.2

Ziele des Pilotprojekts

Primäres Ziel des Projektes war es, die Machbarkeit eines virtuellen Funktionstests für automatisierungstechnische Geräte mit PROFIBUS-Schnittstelle nachzuweisen. Der Black-Box-Funktionstests soll in möglichst frühe Phasen des Entwicklungsprozesses vorverlagert werden können; im Idealfall in eine so frühe Phase, in der das zu entwickelnde Gerät ausschließlich in Form eines auf einer Spezifikation beruhenden Modells vorliegt. Der durchzuführende Funktionstest umfasst Black-Box- und Regressionstests. Neben diesem primären Ziel wurde die Erweiterung bestehender, manuell erstellter, Testsuiten um aus dem Modell automatisch generierter Testskripten erprobt. 9.5.3

Planung des QSM-Einsatzes

Die Erreichung der Ziele erfordert die Kopplung eines Testdurchführungswerkzeuges für den Profibus, sowie eines Modellierungswerkzeuges mit automatischer Codegenerierung (CASE-Tool). Die bereits verfügbaren Werkzeuge AutoFOCUS (Validas AG) und MoTest (itm) bieten für die Umsetzung die notwendigen Programmierschnittstellen (APIs) und die

240

9 Die Einführung von QSM in einzelnen Unternehmen

erforderliche Flexibilität hinsichtlich Erweiterbarkeit und Anpassbarkeit. Insbesondere die gemeinsame Kommunikationsmöglichkeit über eine TCP-IP- Schnittstelle vereinfacht die Kopplung der Werkzeuge so zu realisieren. Ferner ist AutoFOCUS ein frei verfügbares Werkzeug, im Gegensatz zu den möglichen alternativen UML-RT CASE-Tools (wie z.B. RoseRT, Matlab-Simulink, Statemate, ASCET-SD), die mit teilweise erheblichen Lizenzkosten verbunden sind. Zur Realisierung der notwendigen Softwarekomponenten wurde die Methode Prototyping angewendet. Es genügte, die Modelle und Skripten manuell zu erstellen, allerdings unter Berücksichtigung einer automatischen Generierungsmöglichkeit durch einfache Skripten. Die Kopplung wurde von einem Studenten realisiert, der von Experten zu den Werkzeugen AutoFOCUS und MoTest betreut wurde. Wegen der einfachen Konzepte von AutoFOCUS und der guten Dokumentation zu MoTest waren keine zusätzlichen Schulungen notwendig. Um die Korrektheit der Umsetzung zu zeigen, wurde als Abnahmekriterium die Durchführung eines Funktionstests für einen Stellmotor, sowohl auf Modellebene als auch auf realer Anwendungsebene, definiert. Das heißt, die für den Funktionstest notwendigen Test-Skripten wurden vom Testsystem sowohl gegen das virtuelle Modell als auch gegen den realen Prüfling ausgeführt und ausgewertet mit dem Ziel, ein identisches Prüfergebnis zu erlangen. Neben der prototypischen Umsetzung des virtuellen Funktionstests von PROFIBUS-Komponenten umfasst dieses Pilotprojekt die folgenden QSMaßnahmen: • • • • •

Simulation Struktur- und Verhaltensmodellierung (mit AutoFOCUS) Black-Box Test, Regressionstest und Testautomatisierung Testfallgenerierung

9.5.4

Durchführung der QSM

Zur Durchführung der modellbasierten Entwicklung wurde wie bereits erwähnt das frei verfügbare CASE-Tool AutoFOCUS herangezogen. Die hiermit erstellten Modelle können dann validiert, mit formalen Methoden verifiziert und getestet werden. Aus den Modellen lässt sich anschließend ausführbarer Code generieren. Ein AutoFOCUS-Modell ist komponentenbasiert, wobei die Komponenten hierarchisch untergliedert sein können. Die Kommunikation der Komponenten erfolgt über typgebundene Kanäle.

9.5 Virtueller Funktionstest von PROFIBUS-Komponenten

241

Das dynamische Verhalten der Komponenten wird mit Hilfe von Zustandsautomaten definiert. Bei jedem Zustandsübergang können Werte der Eingangskanäle gelesen und Werte in die Ausgangskanäle geschrieben werden. Die äußere Schnittstelle eines Systems wird durch die Ein- und Ausgangskanäle des Umfeldes bestimmt. Um den eigentlichen Funktionstest in Form eines Black-BoxRegressionstests durchzuführen, wurde das universelle Prüfsystem MoTest verwendet, das unter anderem für den Test von PROFIBUS-Komponenten geeignet ist. Das Programm läuft auf einem handelsüblichen PC, der mit einer optionalen PROFIBUS-Karte ausgestattet wird. Mit dieser Karte können die Geräte über das PROFIBUS-Protokoll (DP v0 bis DP v2) angesteuert werden. Die eigentlichen Testfälle sind in Form ausführbarer Testskripten beschrieben, die das Prüfsystem abarbeitet. In ihnen werden die Befehle, die an den Prüfling geschickt werden, und die zu erwartende Antworten definiert. Ein Test gilt als erfolgreich bestanden, wenn sich der Prüfling gemäß der im Testskript definierten Antworten verhält. Um eine der in Kapitel 5 beschriebenen Ausprägung des virtuellen Funktionstest umzusetzen, mussten die beiden Werkzeuge AutoFOCUS und MoTest über eine geeignete Schnittstelle gekoppelt werden (Abb. 9.21). Dies bedeutet, dass das Prüfsystem die PROFIBUS-Telegramme an eine Simulation des AutoFOCUS-Modells schicken muss. Dies wurde über die an beiden Werkzeugen vorhanden TCP/IP-Kommunikationsschnittstelle realisiert. Da MoTest modular aufgebaut ist – mit dem Modul pme als Schnittstelle zum Profibus – musste lediglich dieses eine Softwaremodul angepasst werden. Anstatt mit Hilfe einer DLL auf eine reale Profibuskarte zuzugreifen, werden die Befehle in das AutoFOCUS-spezifische Format umgewandelt und über das TCP/IP Protokoll an die AutoFOCUSSimulation geschickt. AutoFOCUS parst die Strings in den ankommenden Paketen und führt nach jedem empfangenen Paket einen Modellschritt aus. Ein Vorteil dieser Technik besteht darin, dass MoTest und AutoFOCUS auf verschiedenen Rechnern laufen können.

242

9 Die Einführung von QSM in einzelnen Unternehmen

Abb. 9.21. Architektur der Kopplung

Vorbereitung der QSM

Vorbereitend wurde zunächst eine ASIC-genannte -Komponente (ASIC = Applikations Spezifischer IC) (Abb. 9.22), die in allen Profibusgeräten vorhanden ist, in AutoFOCUS modelliert. Diese ASCI-Komponente übernimmt die PROFIBUS-Kommunikation und hat ihren Namen von dem in üblichen realen PROFIBUS-Slave-Geräten verbauten Kommunikationsbaustein. Dabei sind für die ASIC-Komponente die Nutzdaten der PROFIBUS-Telegramme unwichtig. Sie regelt lediglich den Verbindungsauf- und Abbau, sowie PROFIBUS-spezifische Dinge wie das gleichzeitige Übermitteln von Synchronisationskommandos und Sensorwerten. Die ASIC-Komponente besitzt je einen Hin- und Rückkanal zum virtuellen PROFIBUS und zum modellierten Profibusgerät.

9.5 Virtueller Funktionstest von PROFIBUS-Komponenten

243

fieldappliance:Paket ASIC asic:Paket

Profibus_in:Telegramm

Profibus_out:Telegramm

Abb. 9.22. ASIC-Komponente

Der Zustandsautomat der ASIC-Komponente (Abb. 9.23) entspricht in etwa dem in der PROFIBUS-Norm spezifizierten Zustandsautomaten [56]:

Abb. 9.23. Verhalten der ASIC-Komponente als Zustandsautomat

244

9 Die Einführung von QSM in einzelnen Unternehmen

Die Daten, die über die Profibus-Ein- und Ausgabekanäle ausgetauscht werden, werden über TCP/IP übermittelt, d.h. TCP/IP Strings überliefern die Informationen zwischen der laufenden Simulation eines Profibusgerätes und dem Prüfsystem. Damit diese Strings von AutoFOCUS geparst werden können, müssen sie von dem Modul pme in ein AutoFOCUSspezifisches Format übersetzt werden. Zu diesem Zweck wurde die Datei pme.tcl entsprechend angepasst. Anwendung der QSM

Unter den geschaffenen Voraussetzungen lassen sich nun virtuelle Funktionstests verschiedenster Profibusgeräte durchführen. Zu diesem Zweck muss das Gerät in AutoFOCUS modelliert und mit der ASIC-Komponente verbunden werden. In diesem Pilotprojekt wurde dafür ein einfacher Stellantrieb mit PROFIBUS-Schnittstelle verwendet, dessen statische Struktur in Abb. 9.24 dargestellt ist.

Abb. 9.24. Struktur Anwendungsbeispiel: Motorsteuerung

Der Motor kann beliebig definierte Positionen anfahren, d.h. er dreht nach rechts bzw. links bis er die gewünschte Position erreicht hat. Das Modell (Abb. 9.25) abstrahiert dabei zu einem gewissen Grad vom echten Motor und zeigt die für den Test wesentlichen Zustände OPEN, CLOSE, STOP und BLOCKED. Die Beschreibung der Übergangsbedingung ist in

9.5 Virtueller Funktionstest von PROFIBUS-Komponenten

245

den Transitionen enthalten. Diese Abstraktion erleichtert das Verständnis des Modells und die automatische Generierung von Testsequenzen.

Abb. 9.25. Verhaltensbeschreibung des Motors

Diese Verhaltensbeschreibung lässt sich schematisch in TCLTestskripten umsetzen. Diese Testskripten konnten erfolgreich mit dem realen Stellantrieb durchgeführt werden, so dass die Konformität des Motors zu seiner Verhaltensspezifikation gesichert ist. Das folgende TCL-Skript setzt zum Beispiel eine neue Slave Adresse: # Anfordern eines Diagnose Telegramms chk -mode wait { h pme dia $Adr } [list 0 [concat 0b0000?010 0x05 0 0xFF $RetIdent]] tbf str "\n\na." tbf str "2. Send Set_Slave_Add:" set result [ h pme sad $Adr $NewAdr $Ident 0x00 {} ] if {$result != 0} { result fail "Slave responds with $result to SET_SLAVE_ADD.req-PDU - should respond with SHORT_ACK” return } set result [ chk -mode wait { h pme dia $NewAdr } [list 0 [concat 0b0000?010 0x05 0 0xFF $RetIdent]] ]

246

9 Die Einführung von QSM in einzelnen Unternehmen

if { $result != 1 } { result fail "The Slave address has been changed from $Adr to $NewAdr. Slave responds with [ h pme dia $NewAdr ] to SLAVE_DIAG.req-PDU - should respond with SLAVE_DIAG.res-PDU. Maybe the slave has not changed its address! (TC 03)" return } tbf str "Slave has changed its address from $Adr to $NewAdr - OK\n\n" tbf str "Set slave address back to the original one $Adr:" set result [ h pme sad $NewAdr $Adr $Ident 0x00 {} ]

Der Adressierungsmechanismus ist im AutoFOCUS-Modell nicht enthalten, da dieses explizite Kommunikationskanäle für jeden Kommunikationspartner verwendet. Daher ist dieser Adressierungsmechanismus nicht Bestandteil des Modells, sondern wird von einem sogenannten Konkretisierer, der eine Erweiterung von AutoFOCUS ist, automatisch an den richtigen Stellen eingefügt. Somit bleiben die Modelle abstrakt und auf die wesentlichen Funktionen fokussiert. Das Testskript verdeutlicht, welche Details im Modell nicht enthalten sind. Die prototypische, sehr schematische Umsetzung zeigt die Generierbarkeit solcher Testskripten aus beliebigen Modellsequenzen. Das Beispiel zeigt außerdem, wie man ein abstraktes Modell schrittweise verfeinern kann, bis es die zum Testen erforderliche Genauigkeit besitzt. 9.5.5

Bewertung

Die beiden wesentlichen Ziele des Pilotprojektes wurden erreicht. Sowohl die Konformitätsprüfung des Motors konnte erfolgreich durchgeführt werden als auch die prototypische Kopplung eines Testsystems mit dem lauffähigen Modell eines Modellierungswerkzeugs als Anwendungsbeispiel für den virtuellen Funktionstest. Die Möglichkeit, mit dieser Ausprägung des virtuellen Funktionstests implementierte Testfälle wesentlich früher als bisher anzuwenden und somit zu evaluieren, ist ein entscheidender Vorteil gegenüber statischen Analyseverfahren. Modelle von Verhaltensbeschrei-

9.5 Virtueller Funktionstest von PROFIBUS-Komponenten

247

bungen lassen eine wesentlich abstraktere Darstellung zu und erleichtern im Gegensatz zu den textbasierten Testskripten auch das Verständnis des Verhaltens. Ferner können aus einem Verhaltensmodell zusätzlich viele unterschiedliche Testsequenzen abgeleitet werden, was insbesondere bei Variationen einen deutlichen Vorteil bringt. Das Pilotprojekt hat allerdings auch eine Grenze der statisch erzeugten Tests und Testsequenzen gezeigt: Die Tests beschreiben ein mögliches Verhalten und lassen sich nur schwierig auf nichtdeterministische Alternativen erweitern. Dies bedeutet, dass beispielsweise ein Standard, der ja immer mehrere Verhaltensweisen zulässt, zwar in ein Modell umgesetzt werden kann, dass allerdings die aus dem Modell generierten Testsequenzen die Alternativen nur beschränkt zulassen. Die Lösung dieses generellen Problems sind „In-The-Loop“ Tests, bei denen ein dynamischer Abgleich zwischen einer nicht-deterministischen Spezifikation (Modell) mit einem deterministischen Prüfobjekt erfolgen kann. Die Stimulation des Tests lässt sich nach wie vor aus dem Modell berechnen. 9.5.6

Praktische Tipps

Die prototypische Kopplung der Werkzeuge AutoFOCUS und MoTest hat den Nutzen der Integration von Methoden unterschiedlicher Abstraktionsebenen gezeigt. Die erzeugten Skripten passen zu dem erstellten Modell der Anwendung. Um einen allgemeinen Konformitätstest für beliebige Geräte mit dem Profibus-Standard zu gewährleisten, muss die Methode allerdings so erweitert werden, dass das Modell auch Toleranzen berücksichtigt. In AutoFOCUS kann dies mittels nicht-deterministischer Modelle erreicht werden. Da das Testen nichtdeterministischer Systeme mittels fester Testsequenzen nur eingeschränkt möglich ist, ist für den Konformitätstest eine direkte Kopplung des Gerätes mit dem AutoFOCUS-Modell und eine „In-The-Loop“ Simulation notwendig. MoTest kann für diese Kopplung als Zwischenschicht zu den Geräten verwendet werden.

248

9 Die Einführung von QSM in einzelnen Unternehmen

9.6

Fundamentales Modellierungskonzept (FMC)

Die WIPOTEC GmbH entwickelt und produziert digitale Präzisionswägezellen, die als Sensoren in industriellen Anlagen eingesetzt werden, und Steuerungen für Hochgeschwindigkeitskontrollwaagen. Die Kombination eines speziell adaptierten Messverfahrens - der „Kraftkompensation“ - mit der Kraftumlenkung auf der Basis einer „Einteile-Mechanik“ bilden die Grundlage für Präzision und Geschwindigkeit des Messverfahrens. Die Funktionalität des Sensors und die Schnittstelle zur technischen Anlage ist komplex und wird von Realzeitanforderungen geprägt. Risiken, die im Verlauf der Produktentwicklung, aber auch während des Produkteinsatzes in der Anlage zu Problemen führen können, müssen durch qualitätssichernde Maßnahmen (QSM) minimiert werden. Die Auftragsvergabe durch die Anlagenhersteller hängt in zunehmendem Maße von einer überprüfbaren Qualitätssicherung ab, die einen risikoarmen Verlauf der Produktentwicklung, aber auch einen risikoarmen Produkteinsatz in der Anlage garantiert. Der Einsatz qualitätssichernder Maßnahmen wird sowohl in Audits mit dem Anlagenhersteller und dem Anlagennutzer als auch in Zertifizierungsverfahren überprüft. 9.6.1

Allgemeine Projektbeschreibung

Ein charakteristisches Merkmal der Entwicklungsprozesse von Produkten der Firma WIPOTEC ist die Kombination verschiedener Disziplinen, nämlich Gerätemechanik, Hardware und Software. Das Vorgehen nach dem 3Ebenen-Vorgehensmodell ist daher angemessen (Kapitel 3.3). Im Verlauf von Anforderungsdefinition und Design werden auf den drei Modellebenen Entscheidungen getroffen, die interdisziplinär kommuniziert werden müssen. Durch die Verwendung geeigneter Beschreibungssprachen soll diese interdisziplinäre Kommunikation formalisiert werden. 9.6.2

Ziele des Pilotprojektes

Eine Analyse abgeschlossener WIPOTEC-Projekte hat gezeigt, dass die informelle Kommunikation in den frühen Projektphasen Risiken birgt, die in späteren Projektphasen zu schweren Problemen führen kann. Diese Probleme können im Allgemeinen nur mit hohem Aufwand gelöst werden. Die Sachverhalte der Anforderungsdefinition und des Design von eingebetteten Systemen, sollten formal oder semi-formal beschrieben und somit mindestens semiformal verifizierbar sein. Eine formale oder semiformale

9.6 Fundamentales Modellierungskonzept (FMC)

249

Beschreibung, die im Verlauf von Anforderungsdefinition und Design getroffene Entscheidungen festhält, wird in diesem Fall auch als Produktmodell bezeichnet. Das Pilotprojekt untersucht die beiden Methoden „Anforderungsanalyse“ und „Architekturentwurf“ hinsichtlich der Fähigkeit, Risiken in den Phasen Anforderungsdefinition und Design aufzudecken. Produktmodelle sind eine Form der Umsetzung eines Architekturentwurfes. Aspekte der Produktmodelle sollen semiformal und, wenn angemessen, formal beschrieben werden. Die Produktmodelle werden nach dem Fundamentalen Modellierungskonzept (FMC) erstellt [41]. FMC wurde zur Beschreibung komplexer informationstechnischer Systeme entwickelt. Eines der wichtigsten Motive für die Entwicklung von FMC war die Verbesserung des Wissenstransfers zwischen den Entwicklern informationstechnischer Systeme auf der Systemarchitekturebene unter Verwendung einer semiformalen grafischen Notation. FMC ist, im Gegensatz zu UML, an kein spezielles Programmierparadigma gebunden. Modelle, die nach dem FMC erstellt werden, können sowohl Hardware- als auch Softwarekomponenten umfassen. Die fundamentalen Aspekt jeder Systemarchitektur werden nach dem FMC mit • statischen Strukturen (der Systemkomposition und den Datenstrukturen), • dynamischen Strukturen und den Beziehungen zwischen den Strukturen beschrieben. FMC benutzt bipartite Graphen zur Darstellung der Strukturen. Im Rahmen des FMC können zur Modellierung dynamischer Aspekte folgende QSM eingesetzt werden: • Endliche Automaten • Petrinetze (PN)

250 9.6.3

9 Die Einführung von QSM in einzelnen Unternehmen Planung des QSM-Einsatzes

Zur Klärung, ob der Einsatz von Produktmodellen bei der Anwendung der QS-Maßnahmen „Anforderungsanalyse“ und „Architekturentwurf“ zur Aufdeckung von Risiken des Entwicklungsprozesses beiträgt, wurden die folgenden Teil-Ziele definiert: • Beschreibung der Risiken informeller Kommunikation: Aufdecken von Entwicklungsrisiken, verursacht durch informelle Kommunikation in frühen Phasen. Festlegung der Vorgehensweise, wie durch QSM Risiken reduziert werden können. • FMC-Einsatz im Rahmen der WIPOTEC- Produktentwicklung: Der Zweck des FMC-Einsatzes ist die Formulierung eines Produktmodells, welches vom Auftraggeber, Produktmanagement und der Produktentwicklung genutzt wird. Dies sind Personen, die im Verlauf der Phasen „Anforderungsdefinition“ und „Design“ üblicherweise Entscheidungen zu WIPOTEC-Produkten treffen. Im Rahmen der Vorbereitung des FMC-Einsatzes wurde untersucht, ob eine Verträglichkeit der Systemklasse der Produkte mit dem Modellierungskonzept gegeben ist, ob das Modellierungskonzept angemessen ist und ob eine entsprechende ToolUnterstützung vorhanden ist. • Modellchecking: Es soll untersucht werden, ob formale Verifikationsverfahren zur Risikominderung eingesetzt werden können. • Einführung der modellorientierten Vorgehensweise: Es ist abzuschätzen, welche Probleme eine Prozessveränderung in Richtung „modellorientierter Vorgehensweise“ bei Produktentwicklungen verursacht. 9.6.4

Durchführung der QSM

Beschreibung der Risiken informeller Kommunikation

Die Diskussion mit den Entscheidungsträgern der Fa. WIPOTEC aus den Bereichen Vertrieb, Produktmanagement und der Produktentwicklung über die Risiken der Anforderungs- und Designphase führte zu den folgenden Ergebnissen: • Sachverhalte werden nicht präzise kommuniziert. Die Lösung der Probleme, die erst während der Implementierung, im Test oder nach der Inbetriebnahme auftreten können, verursachen hohe Kosten. • Entscheidungen werden nicht präzise protokolliert. Es entstehen Dokumente, die als Verifikationsbasis nur bedingt tauglich sind.

9.6 Fundamentales Modellierungskonzept (FMC)

251

• Die Übersicht geht verloren. Schnittstellen in komplexen Anlagen, an denen mehrere Teams beteiligt sind, werden oft nur aus der Sicht des Schnittstellenbereitstellers und des Schnittstellennutzers beschrieben. Es entsteht keine angemessene präzise Beschreibung zur übergeordneten Sicht auf das Gesamtsystem. • Synergieeffekte, gründend auf der Zusammenarbeit mit Unternehmenspartnern, können nicht angemessen genutzt werden, weil keine modellorientierte Sicht auf die Architektur der Anlage existiert, die auch vom Partner erkannt wird. Nach Bewertung der Risiken wurde entschieden, die QSM „Anforderungsanalyse“ und „SW-Architekturentwurf“ einzusetzen, Entwurfsentscheidungen mit semiformalen Produktmodellen zu erfassen und die Angemessenheit des FMC-Einsatzes zu untersuchen. FMC-Einsatz im Rahmen der WIPOTEC- Produktentwicklung

Das Fundamentale Modellierungskonzept (FMC) beruht auf einer Kategorisierung der Entwurfsentscheidungen und der semiformalen Modellierung [41]. Diese Modelle dienen primär der zwischenmenschlichen Kommunikation von Entwurfsentscheidungen und der Schaffung einer Wissensbasis für die Projektteams. Verträglichkeit der Systemklasse mit dem Modellierungskonzept. Entwurfsentscheidungen zu zeitdiskreten Systemen lassen sich fünf Kategorien zuordnen. Jede Kategorie wird durch eine Frage charakterisiert [12] (Tabelle 9.3) Tabelle 9.3. Kategorien für Entwurfsentscheidungen Kategorie 1 2 3 4 5

Frage An welchem Ort lassen sich Werte beobachten? Welche aktiven Komponenten ändern Werte an diesem Ort? Welche Wertetypen können an einem Ort beobachtet werden? Welche zeitliche Ordnung besteht zwischen den Werten? Welche Operationssemantik besteht zwischen den beobachteten Werten?

Die Antworten auf die Fragen abstrahieren Objekte und die Relationen zwischen den Objekten des betrachteten Systems. Es entsteht ein strukturiertes Bild – das Modell – eines diskreten, dynamischen Systems.

252

9 Die Einführung von QSM in einzelnen Unternehmen

Das Metamodell zur Beschreibung zeitdiskreter Systeme umfasst daher folgende Beschreibungstypen: • Aufbaustrukturbeschreibungen: Aktive Objekte der Aufbaustruktur sind Akteure, die Zugriff auf passive Objekte, die Beobachtungsorte der Werte (Kanäle oder Speicher), haben. Akteure werden über ihre Zuständigkeit für Teilaufgaben abgegrenzt. Die Abgrenzung erfolgt durch Beantwortung von Fragen der Kategorien 1 und 2. • Wertestrukturbeschreibungen: Entscheidungen der Kategorie 3 werden durch den Wertebereich eines Beobachtungsortes über die Typbindung festgelegt. • Ablaufstrukturbeschreibungen: Die Angaben zu den Beziehungen zwischen Ereignissen beantworten Fragen der Kategorie 4. Es wird also Verhalten modelliert. • Entscheidungen der Kategorie 5 werden nicht von Strukturen erfasst, sondern umgangssprachlich oder formalsprachlich beschrieben. Ein Produktmodell ist mit dem Fundamentalen Modellierungskonzept verträglich, wenn das Ergebnis die Fragen der fünf Kategorien beantwortet. Angemessenheit des Modellierungskonzepts. Die Eigenschaften eines Modellierungskonzepts zur Produktmodellierung müssen den Anforderungen einer Produktentwicklung nach dem 3-Ebenen-Vorgehensmodell angemessen sein. Diese Angemessenheit sei in folgenden Aussagen postuliert: • Abstraction: Die Systemdarstellung auf unterschiedlichen Abstraktionsebenen ermöglicht es, die Systemkomplexität in den Griff zu bekommen. • Simplicity: Das Konzept soll leicht erlernbar und im täglichen Gebrauch anwendbar sein. • Universality: Weder die Notation noch die konzeptionelle Basis darf an ein Implementierungs-Paradigma gebunden sein. • Separation of concerns: Darstellung verschiedener Systemaspekte muss möglich sein. Das Fundamentale Modellierungskonzept erfüllt die gestellten Anforderungen. Daher wurde entschieden, die beiden QSM „Anforderungsanalyse und Architekturentwurf“ mit Hilfe des FMC zu unterstützen. Tool-Unterstützung. Die modellorientierte Analyse und das Design nach dem Fundamentalen Modellierungskonzept wird von dem Tool FMCACOLYTE der Fa. ArcWay AG unterstützt. Das Werkzeug wird zur Visu-

9.6 Fundamentales Modellierungskonzept (FMC)

253

alisierung und Konstruktion der Systemarchitektur genutzt. Mit dem Werkzeug werden FMC-basierte Konstruktionspläne zur Beschreibung des Produktmodells erstellt und zentral aufbewahrt, effizienter projektweiter Wissensaustausch über technische Systemkonzepte unterstützt und die Verbindung der Architekturplanung zum Projekt- und Anforderungsmanagement hergestellt. Anwendung der QSM

Entscheidungen über Anforderungen, die auf der System- und SubsystemEbene getroffen werden, beeinflussen die Hardware- und Software- Anforderungsanalyse und müssen daher interdisziplinär kommuniziert werden. Zu der interdisziplinären Kommunikation wird bei der Firma WIPOTEC FMC-ACOLYTE eingesetzt. Für den SW-Entwurf wird jedoch UML und für den HW-Entwurf HW-Entwurfssprachen wie beispielsweise VHDL eingesetzt. Werden auf der System- und Subsystem-Ebene Anforderungsdefinitionen und Entwurfsentscheidungen in den Dokumenten „Pflichten- und Lastenheft“ in natürlicher Sprache verfasst, besteht das Risiko, dass Sachverhalte und Entscheidungen nicht angemessen präzise kommuniziert und protokolliert werden. Dieses Risiko kann erheblich gemindert werden, wenn Aufbau und Verhalten des Produktes und seiner Umgebung durch ein interdisziplinär verständliches Modell werkzeugunterstützt beschrieben wird. Da FMC an kein Implementierungs-Paradigma gebunden ist, kann in späteren Projektphasen entschieden werden, ob eine Komponente in Hardware oder Software implementiert werden soll. FMC fördert Überlegungen bezüglich unterschiedlicher Realisierungsalternativen. Im Verlauf von Hardware-Anforderungsanalyse und -Design entstehen FMC Aufbaumodelle in einer strukturellen Granularität, die direkt in eine Hardwarebeschreibungssprache (RTL) umgesetzt werden können. Zur formalen Beschreibung dieser Aufbaumodelle bietet sich z.B. VHDL an. Im Umfeld der RTL werden Werkzeuge angeboten, mit denen ein Modell, das in einer RTL beschrieben wurde, unter Verwendung eines FPGABoards automatisch implementiert werden kann. Diese Entwurfsmethode ist eine wichtige Alternative zum Software-Design. Zur Verhaltensmodellierung von Hardwarekomponenten können die konstruktiven QSM „Petrinetze“, „SDL“ oder „Endliche Automaten“ eingesetzt werden. Verhalten, das mit den genannten QSM modelliert wurde, kann formal verifiziert werden. Auf Subsystem- und Komponenten-Ebene werden für die Software die Phasen „Anforderungsanalyse“, „Grobentwurf“, „Feinentwurf“, „Implementierung“, „Modultest“ und „Integration“ unterschieden. Im Prozess-

254

9 Die Einführung von QSM in einzelnen Unternehmen

modell werden außerdem die Beziehungen zwischen Entwicklungsphasen und Testphasen dargestellt. Auf diesen Ebenen können die Anforderungen, der Entwurf und die Tests in vielen Fällen mit der Modellierungssprache UML angemessen beschrieben werden. Wesentlich ist, dass im Umfeld von UML Tools zur Codegenerierung angeboten werden, die die Implementierung der Softwarekomponenten zumindest unterstützen. Der Einsatz von UML setzt allerdings Kenntnisse der objektorientierten Programmierung bei allen Mitarbeitern der Software-Teams voraus. In diesem Zusammenhang ist die gezielte Schulung der Mitarbeiter unerlässlich, um den Kenntnisstand auf ein angemessenes Niveau zu heben. Modellchecking. Der Fokus des Fundamentalen Modellierungskonzeptes liegt auf einer übersichtlichen Visualisierung der Modelle zur zwischenmenschlichen Kommunikation. Die Bedeutung der formalen Verifikation von Produktmodellen zur Aufdeckung von Risiken ist daher eher gering, aber dennoch möglich. Beispielsweise kann eine Verhaltensstruktur, die mit einem Petrinetz modelliert wurde, formal auf Deadlock-Freiheit überprüft werden. Einführung der modellorientierten Vorgehensweise. Die Verwendung von Produktmodellen zur Anforderungsanalyse und der modellgetriebene Architekturentwurf lassen sich nur durchsetzen, wenn die Kenntnisse der betroffenen Mitarbeiter durch Schulung auf ein angemessenes Niveau gehoben werden. Mitarbeiterschulung zur Vermittlung des FMC und der Nutzerkenntnisse bezüglich FMC-ACOLYTE ist notwendig. Das FMCMetamodell wurde von den Mitarbeitern intuitiv erfasst, da der betroffene Personenkreis im Umgang mit anderen Entwurfsmodellen (z.B. Schaltplänen) geübt ist. Kenntnisse der objektorientierten Programmierung werden den Mitarbeitern der Software-Teams durch problemorientierte Schulungen vermittelt. Im Projektverlauf war und ist die Motivation der Mitarbeiter, unter Zeitdruck modellorientiert zu arbeiten, niedrig. Dies trifft insbesondere bei anstehenden Lieferterminen zu. Die Akzeptanz wird erhöht, wenn die Mitarbeiterschulung Probleme des Tagesgeschäftes der Mitarbeiter aufgreift. Wichtig ist, dass die Projektverantwortlichen das Produktmodell an festgelegten Meilensteinen einfordern und als Dokument pflegen. Nur dann können Produktmodelle als Verifikationsbasis und zur Konservierung des Know-how nützen.

9.6 Fundamentales Modellierungskonzept (FMC) 9.6.5

255

Bewertung

Auf der Basis von FMC können formale und hinreichend intuitiv verständliche Modelle erzeugt werden. Die präzise und rollenübergreifende Beschreibung komplexer Systeme wird so ermöglicht. Wird ein Meilenstein erreicht, dokumentieren die erstellten FMCDokumente den Entwicklungsstand. Endziel ist die Erstellung einer möglichst vollständigen, konsistenten Menge von FMC-Dokumenten, die alle Entscheidungen der Entwicklung beinhalten. FMC-Dokumente, die im Verlauf von Entwicklungsprozessen entstehen, bilden eine Wissensbasis, auf die in Folgeprojekten zugegriffen werden kann. Zur Zeit ist FMC-ACOLYTE nur beschränkt als „Planeditor“ (DesignTool) einsetzbar. Aussagen zur Prozessverbesserung durch die Verbindung der modell-getriebenen Analyse und des modellgetriebenen Designs zum Projekt- und Anforderungsmanagement können noch nicht gemacht werden. Die Modellierung von Softwarekomponenten mit UML wird zum unternehmensweiten Standard, wenn alle Mitglieder der Softwareteams über angemessene Kenntnisse im objektorientierten Systementwurf verfügen.

256

9 Die Einführung von QSM in einzelnen Unternehmen

9.7

Optimierung des Entwicklungsprozesses

Bei der Inova Computer GmbH wurde im Rahmen eines Pilotprojektes der bestehende Entwicklungsprozess kritisch durchleuchtet und aufbauend auf den dabei gewonnenen Erkenntnissen überarbeitet und optimiert. 9.7.1

Allgemeine Projektbeschreibung

Die Optimierung eines Entwicklungsprozesses kann nie als abgeschlossen bezeichnet werden. Zum einen liegt dies an der permanent fortschreitenden Technik bzw. Technologie und zum anderen an dem ständig wachsenden Kostendruck bei den Unternehmen. Der Wandel von unidisziplinären zu mulidisziplinären Produkten macht dies deutlich. Im Rahmen des Pilotprojektes „Optimierung des Entwicklungsprozesses“ wurde dazu der bestehende Produktentwicklungsprozess überprüft. Vorhandene Schwachpunkte wurden identifiziert und gezielt Verbesserungen eingeführt. Typischerweise ist bei der kooperativen Hardware- und Softwareentwicklung die Durchführung der Spezifikationsphase und die Vollständigkeit der damit in Verbindung stehenden Dokumente eine der größten Fehlerquellen. Dieses Phänomen wurde auch durch bisherige Erfahrungen bei der Inova Computer GmbH bestätigt. Zusammengefasst lässt sich dies auf die Aussage reduzieren: „Die Fehler, die am Anfang gemacht werden, kann man hinterher nur schwer oder mit erheblichem Aufwand korrigieren“. Betrachtet man den ursprünglichen Entwicklungsprozess, der vor Pilotprojektbeginn existierte, kann dieser als stark hardwareorientiert bezeichnet werden. So wurden die Entwicklungsprojekte zuerst als reine Hardwareprojekte gestartet und erst anschließend die Softwareabteilung eingebunden. Der Zeitpunkt der Einbindung war relativ spät, sodass Einflussmöglichkeiten auf den Produktentwicklungsprozess gering waren. Inzwischen wird die Zusammensetzung der Entwicklungsteams bereits in der Spezifikationsphase bestimmt. Die Sachkenntnis der beteiligten Hardwareund Softwarespezialisten ermöglicht es, eine möglichst vollständige Spezifikation eines Produktes zu erstellen. Bei den damit in Zusammenhang stehenden Besprechungen nimmt der Projektleiter die Rolle eines Moderators und „Supervisors“ ein. Diese Basisarbeit ermöglichte es, zusätzliche Qualitätssicherungsmaßnahmen wie die Beschreibung der Softwarestrukturen und Hardwareabhängigkeiten in einer frühen Phase mit der Unified Modelling Language (UML) einzuführen. Hiermit soll sichergestellt werden, dass die Spezifika-

9.7 Optimierung des Entwicklungsprozesses

257

tion alle erkennbaren Systemzustände beschreibt und erfasst. Durch die Anwendung der UML in unterschiedlichen Entwicklungsprojekten von mehreren Mannmonaten Aufwand wurde sichergestellt, dass die Auswertung von Einzelergebnissen nicht zu Fehlerinterpretation führt, sondern durchaus eine generelle Qualitätsaussage über die Anwendung von ausgewählten QS Maßnahmen getroffen werden kann. Die Einbindung der technischen Supportabteilung nach Ablauf der Produktentwicklungen lässt Rückschlüsse auf die Verbesserung der Produkte aus Unternehmens- und Kundensicht zu. 9.7.2

Ziele des Pilotprojekts

Aufgrund fortschreitender Technologien und zunehmenden Kostendrucks besteht die Notwendigkeit einer ständigen Optimierung der Unternehmensprozesse. Die Gefahr Marktanteile zu verlieren ist für alle Unternehmen immerzu präsent. Durch Einführung geeigneter Maßnahmen sollen die nachfolgenden Optimierungen erreicht werden: • • • • •

Verbesserte Zeit- und Aufwandsabschätzung Minimierung der Fehlerraten eines Produktes Verringerung der Anzahl der Nacharbeiten Reduzierung von Änderungswünschen Bessere Kostenkontrolle während der Projektlaufzeit

Die Praxis zeigt, dass eine sorgfältige Arbeitsweise in der Spezifikationsphase enormen Einfluss auf den Erfolg einer Produktentwicklung hat. Wird zusätzlich ein konsequentes Risiko- und Konfigurationsmanagement anwendet, können laut GartnerGroup bis zu 25% an Einsparungen erzielt werden. Um den Prozess der Feinspezifikation zu optimieren, wurde die Einführung von UML ausgewählt. Vormals wurden rein textuelle Beschreibungen von technischen Zusammenhängen erstellt. Diese waren zum einen nur schwer lesbar und zum anderen konnten komplexe Zusammenhänge nur unzureichend dargestellt werden. Der Einsatz grafischer Beschreibungselemente erschien als ein probates Mittel, Anforderungen eindeutig zu definieren und die Abhängigkeiten zwischen Hardware- und Softwareentwicklung kenntlich zu machen.

258 9.7.3

9 Die Einführung von QSM in einzelnen Unternehmen Planung des QSM-Einsatzes

Anhand der Entwicklung eines embedded Controller-Modules zur Steuerung und Überwachung verteilter Computersysteme im mobilen Einsatz (im Folgenden Controllerunit genannt) wurde das Pilotprojekt durchgeführt. Beteiligt waren mehrere Entwicklungsingenieure aus den Disziplinen Hardware und Software, wobei die Softwareentwickler federführend die Prozessverbesserung durchführten. Die Grobspezifikation wurde in Kooperation von Hardwareentwicklung, Vertrieb und Marketing erstellt. Die Feinspezifikation entstand in Zusammenarbeit von Hardware- und Softwareabteilung. Ziel war die Erweiterung der vormals rein textorientierten Feinspezifikation um grafische UML-Elemente. Die Generierung von produktiven Codes aus UML-Diagrammen stand dabei nicht im Vordergrund. Die Spezifikation mit Hilfe der UML-Notation sollte es ermöglichen, den anderen Projektbeteiligten den Sachverhalt zu erklären und alle Beteiligten auf einen gemeinsamen Kenntnisstand zu bringen. Es sollte keine Dokumentation entstehen, die nur Softwareentwickler unmittelbar erschließen können. Die UML-Beschreibung sollte die Darstellung von Abläufen verbessern, Abhängigkeiten in den Softwareprozeduren darstellen und Wechselwirkungen zwischen Hardware und Software kenntlich machen. 9.7.4

Durchführung der QSM

Die Beschreibung der Durchführung gliedert sich in die Vorbereitung und Anwendung der QS-Maßnahme. Vorbereitung der QSM

Als vorbereitende Maßnahmen standen die Werkzeugauswahl und die Einarbeitung in diese Werkzeuge im Vordergrund. Visio von Microsoft wurde ganz bewusst als Werkzeug ausgewählt, da kein Source Code aus den UML-Diagrammen generiert und die Einarbeitungsphase möglichst effizient gestaltet werden sollte. Die Ähnlichkeit mit den anderen Microsoft Office Produkten war hierbei von großem Nutzen. Grundsätzliche Kenntnisse zu UML waren bereits vorhanden. Die Einarbeitung ging so relativ unkompliziert vonstatten. Visio von Microsoft ist ein weit verbreitetes Werkzeug zur Erstellung von Grafiken, vornehmlich im technischen Bereich. Es bietet ein weites Spektrum an grafischen Vorlagen für Softwareentwickler, wie auch UML, die man relativ unkompliziert verwenden kann. Des Weiteren hat es den Vorteil, ältere Standards, wie Block- und Flussdiagramme, zu bedienen.

9.7 Optimierung des Entwicklungsprozesses

259

Symbole aus der Elektrotechnik und dem Maschinenbau sind ebenfalls in den Bibliotheken enthalten. Alternativ zu Visio gibt es im Internet zahlreiche frei verfügbare oder kostengünstige Grafikprogramme mit unterschiedlich stark ausgeprägter UML Unterstützung. Anwendung der QSM

Bei der entwickelten Controllerunit handelt es sich um ein Steuer- und Überwachungsgerät für verteilte Computersysteme im mobilen Einsatz. Die zunächst vom Vertrieb gelieferte Spezifikation war sehr allgemein gehalten und ausschließlich als Fließtext verfasst. Das Dokument war relativ unpräzise und somit schlecht umsetzbar. Insbesondere galt dies für die Beschreibung des dynamischen Verhaltens und die Abhängigkeiten zwischen den einzelnen Funktionsgruppen. In mehreren Sitzungen, an denen Entwickler, Projektmanagement und Vertrieb beteiligt waren, wurden die notwendigen technischen Zusammenhänge zwischen den einzelnen Funktionen herausgearbeitet. In dieser Phase ist die Spezifikation um UML Zustands- und Sequenzdiagramme erweitert worden. Es zeigte sich, dass es noch bei relativ vielen Punkten Klärungsbedarf gab (Einschaltbedingungen, Normalbetrieb, Fehlerbehandlungen etc.). In der Regel beschreibt eine Spezifikation aus Vertriebssicht nur den Idealfall, dieser bereitet jedoch bei der Umsetzung üblicherweise die geringsten Probleme. Die Erfahrung zeigt, dass vor allem Grenzfälle nicht eindeutig spezifiziert und dementsprechend unvollständig umgesetzt werden. Dies führt bei Test- und Inbetriebnahme zu Komplikationen und entsprechenenden Zeitverzögerungen. Die Auslegung beziehungsweise Trennung von Hardware- und Softwareteilen wurde anschließend zwischen den beiden Fachabteilungen besprochen. Dabei ging es um Fragestellungen wie beispielsweise: • • • • •

Wie realisiert man die seriellen Schnittstellen? Benötigt man einen intelligenten Controller? Für was ist eine Softwarelösung machbar? Schafft der Prozessor die geforderten Baudraten? Ist die Anzahl der Ports ausreichend?

Nach Fertigstellung des grundlegenden Designs trennten sich Hardwareund Softwareentwickler, um sich der fachspezifischen Ausarbeitung zu widmen. Seitens der Hardwareentwicklung wurden Bauteile ausgewählt und Schaltpläne gezeichnet. Die Umsetzung der Funktionen und Abläufe in UML wurde von der Softwareabteilung verwirklicht. Die sorgfältige Ausarbeitung von Zustands- und Sequenzdiagrammen ermöglichte es,

260

9 Die Einführung von QSM in einzelnen Unternehmen

kritische Szenarien zu lokalisieren und für deren Überprüfung die passenden Testfälle zu spezifizieren. Beispiel Watchdog. Der Watchdog dient der Überwachung des Servers im Betrieb. Die in Fließtext gehaltene Beschreibung seitens des Vertriebs enthielt lediglich die Aussage, dass ein Watchdog eingesetzt werden soll, um sicherzustellen, dass der Server immer einsatzbereit ist. Die Softwareentwicklung erweiterte diese einfache Aussage um die folgenden Fragstellungen: • • • •

Was sind die Normalzustände des Systems? Gibt es unterschiedliche Betriebszustände? Wie erfolgt die Kommunikation zwischen Server und Steuermodul? Was ist das Zeitintervall für den Watchdog Trigger?

Das anschließende Sequenzdiagramm (Abb. 9.26) gibt einen besseren Einblick in die Funktionsweise des Systems aus Steuermodul und Server. Timeout of external watchdog MSCU

Server App.

Temperature ok Output port „Boot/Shutdown“ = OFF Output port „System = ON CTS is deactivated a

Cyclic server trigger of external watchdog timer COM1: Signal = WDT, T1

(b - a > T1) b

Turn off system power supply

No watchdog trigger (server deadlock etc.)

Activate CTS (c - b == min. off-time)) c

Turn on system power supply

Continued with sequence „Server Boot“

Abb. 9.26. Sequenzdiagramm für Steuermodul und Server

Mit Hilfe dieser Zeichnung kann der exakte Ablauf der Kommunikation zwischen Steuermodul und Server erläutert werden (serielle Schnittstelle COM1 und Signal CTS der COM1). Einfache Vermerke, wie sich beispielsweise Ausschaltzeiten ergeben, sind möglich. Der nächste Schritt wird in der separaten Sequenz „Server Boot“ dargestellt. Diese beschreibt den korrekten Start des Servers.

9.7 Optimierung des Entwicklungsprozesses 9.7.5

261

Bewertung

Selbst mit einer nur sehr kurzen Einweisung in die Darstellungsweise von UML-Sequenzdiagrammen ist für alle Projektteilnehmer der technische Zusammenhang leicht verständlich geworden. Auch der Aufwand, das Verhalten oder die Struktur anhand einer Grafik zu beschreiben, ist geringer als die Schilderung des Sachverhaltes mit Hilfe eines reinen Fließtextes. Für die Erstellung der Feinspezifikation wurde letztendlich ein Zeitaufwand von ca. 30 Prozent der Gesamtprojektlaufzeit aufgewendet. Sind allerdings die hiermit erreichbaren Erfolge einmal erkennbar, sind die beteiligten Personen allzu gerne bereit, einen erhöhten Zeitaufwand in die Präzisierung der Spezifikation zu investieren. Die Erfolge sind dadurch gekennzeichnet, dass die zum Ziel führenden Lösungswege zielstrebiger angegangen werden und Versuchsmuster, die nur dazu dienen, sich der optimalen Lösung anzunähern, vermieden werden können. Manchmal lässt es sich jedoch nicht vermeiden, erarbeitete Verfahren und Entwicklungen zu verwerfen, da nicht alle Abhängigkeiten in komplexen Entwicklungen bis ins letzte Detail spezifiziert werden können. Die genauen Spezifikationen führen außerdem zu wesentlich besseren Dokumentationen. Aus Sicht der Projektleitung ist anzumerken, dass die geplante Projektlaufzeit nach Abschluss der Spezifikationsphase im Vergleich zu einigen früheren Projekten präzise eingehalten wurde. Besonders hervorzuheben ist, dass die technischen Anfragen an den Support oder aber auch an die Entwickler der Produkte um ca. 50 Prozent zurückgegangen sind. Die allgemeinen Supportanfragen und daraus resultierenden Nacharbeiten reduzierten sich im Vergleich zu den bisher gekannten Größen um den Faktor 10. Abschließend kann man sagen, dass sich die Einführung der UML für die Optimierung der Produktspezifikationen eindeutig gelohnt hat. Dies erforderte anfangs eine hohe Disziplin aller Beteiligten, insbesondere der Softwareentwickler, nicht sofort mit der Umsetzung des Produktes („Rush to Code“) zu beginnen, setzte sich jedoch mit fortschreitender Anwendung auf breiter Front durch. 9.7.6

Praktische Tipps

Die erfolgreiche Einführung neuer Methoden funktioniert nur, wenn alle beteiligten Personen das gleiche Ziel haben – den Erfolg der Produktentwicklung! Idealerweise sollte das gesamte Entwicklungsteam effizient und reibungslos zusammenarbeiten. Änderungen und Verbesserungen lassen sich so wesentlich einfacher durchführen. In der Praxis ist dies leider nicht

262

9 Die Einführung von QSM in einzelnen Unternehmen

immer so anzutreffen. Hardwareentwicklungsabteilungen haben oftmals, historisch bedingt, einen sehr hohen Stellenwert in den Unternehmen. Andererseits werden heute weit über 50 Prozent der Funktionalitäten in Software abgebildet. Es kann so zu zwischenmenschlichen Machtverschiebungen kommen, deren Leidtragende alle Beteiligten sind. Dies bedeutet, dass angefangen von der Geschäftsleitung über die Projektleitung bis zu den Entwicklern alle Beteiligten als Team arbeiten müssen und nicht vorschnell Ergebnisse einfordern dürfen. Wird die Spezifikationsphase gründlich und detailliert durchgeführt, stehen Versuchs- oder Vorführmuster erst später als bisher zur Verfügung. Diese weisen dann jedoch eine wesentlich höhere Qualität und größere Funktionalität auf. Setzen sich die Entwickler aus den unterschiedlichen Disziplinen in projektspezifischen Teams zusammen, kann auf dem „kleinen Dienstweg“ viel Zeit in der so wichtigen Frühphase eines Projektes eingespart werden. Das abschließende Ergebnis belohnt im Nachhinein die Beteiligten für ihre Mühen.

10 Best-Practice-Empfehlungen für die Auswahl von QSM

Um den Unternehmer bei der Entscheidung, welche QS-Maßnahmen in bestimmten Situationen eingesetzt werden sollen, zu unterstützen, wurde im Rahmen des Projekts EQUAL eine Zuordnung von Problemen zu QSMaßnahmen erstellt. Dazu wurden typische, im Entwicklungsprozess eingebetteter Software auftretende Probleme analysiert. Diesen Problemen wurden anschließend QS-Maßnahmen in einer Matrixdarstellung zugeordnet, die dabei helfen sollen, die jeweiligen Probleme zu beseitigen bzw. zu reduzieren. Die Wirksamkeit einer QSM bezogen auf ein Problem wurde nach einem 3-stufigen Schema bewertet: 1 = geringe Wirksamkeit 2 = mittlere Wirksamkeit 3 = hohe Wirksamkeit Dabei wurden neben dem eigentlichen Nutzen einer QSM auch die entsprechenden Aufwände berücksichtigt, d.h. es wurde das Kosten / NutzenVerhältnis betrachtet. Neben den drei Bewertungsstufen ist in der Tabelle zwischen grau hinterlegten und normalen Kästchen zu unterscheiden. Die grau hinterlegten Bewertungen geben an, dass die jeweilige QSM direkt in der Phase angewendet werden sollte, in der das Problem anzutreffen ist. Die Bewertungen in normalen Kästchen geben an, dass die QSM zwar das Problem beseitigen bzw. reduzieren kann, jedoch bereits in früheren Phasen angewendet werden sollte. Weiter ist zu erwähnen, dass die Zuordnungen nicht als determiniert und manifest angesehen werden können. Die Zuordnungen sind auf Basis der Erfahrungen und Kenntnisse der an dem Projekt beteiligten Industriepartner und Hochschulen und nicht auf Basis wissenschaftlicher Betrachtungen entstanden. Trotzdem bietet die Zuordnungsmatrix eine gute Möglichkeit, eine Vorstellung über in der Praxis bestehende Probleme und von Experten als wirksam eingeschätzte QSM zu bekommen. Zur besseren Übersicht der behandelten Probleme und ihrer zugeordneten QS-Maßnahmen wurden sowohl die Probleme wie auch die QSMaßnahmen strukturiert. Die Strukturierung der Probleme erfolgte in An-

264

10 Best-Practice-Empfehlungen für die Auswahl von QSM

lehnung an das 3-E-Modell. Dabei wurde folgende Unterteilung vorgenommen: • Anforderungen: Umfasst sämtliche die Produkt-Anforderungsanalyse betreffenden Probleme. • System-Design: In dieser Gruppe werden sämtliche Probleme behandelt, die in der Entwurfsphase des Gesamtprodukts, also ohne detailliertere Betrachtung von Modulen bzw. ohne Aufspaltung in Mechanik, Hardware und Software, entstehen können. • Realisierung: Diese Klasse bezieht sich auf die Komponenten-Ebene des 3-E Modells. An dieser Stelle werden die Realisierungsphasen vom Komponentendesign über die Implementierungsphasen (HW+SW) bis hin zu Komponentenintegration und -test betrachtet. An dieser Stelle wurde der Schwerpunkt auf die Probleme bei der Softwareentwicklung gelegt. • Systemintegration und -test: In dieser Phase werden die Integrationsund Testschritte aus der Realisierungsphase weitergeführt, bis das gesamte System inklusive der kompletten Hardware und Mechanik vollständig integriert und getestet ist. • Projektmanagement: In dieser Einordnung werden organisatorische Probleme behandelt, die das gesamte Entwicklungsprojekt betreffen können. Die QS-Maßnahmen sind, wie in Kapitel 4 beschrieben, in die drei Kategorien konstruktiv, analytisch und organisatorisch unterteilt worden. Im Folgenden wird die Zuordnungsmatrix „Probleme-QSM“ aufgespalten in die einzelnen Problem-Gruppen und QSM-Klassen dargestellt. Bevor die Zuordnungsmatrix dargestellt wird, werden die Probleme jeder einzelnen Problem-Gruppe stichpunktartig beschrieben, um ein einheitliches Verständnis zu erreichen. Die gesamte Zuordnungsmatrix „Probleme-QSM“ finden Sie auf der Internetseite: www.embeded-quality.de/Fachbuch/Kapitel10

10.1 Anforderungen

265

10.1 Anforderungen Das Kapitel Anforderungen bezieht sich auf sämtliche die ProduktAnforderungsanalyse betreffenden Probleme. 10.1.1 Problembeschreibung

Die Problembeschreibung umfasst die geringe Qualität der Anforderungen, die mangelhafte Kommunikationsbasis sowie das schlechte Anforderungsmanagement. Geringe Qualität der Anforderungen

• Unvollständige Anforderungen: In der ersten Phase des Projektes, der Anforderungsanalyse, müssen die Anforderungen an das zu entwickelnde System vollständig erfasst werden, um die Vermarktbarkeit des Produktes zu gewährleisten. Dabei sind vor allem die Anforderungen der Anwender (Kunden) von entscheidender Bedeutung. Gerade bei Entwicklungen, bei denen keine kundenspezifische Lösung angestrebt wird, muss gewährleistet werden, dass die Anforderungen des Zielmarktes vollständig und korrekt beschrieben werden. Außerdem sind die Anforderungen aus den Bereichen Marketing, Produktmanagement, Vertrieb und ebenso der Produktion zu erfassen und zu strukturieren. Weiterhin müssen die Anforderungen, die sich aus den relevanten Normen und Richtlinien ergeben, berücksichtigt werden. In diesem Abstimmungsprozess muss ein einheitliches Systemverständnis aller Beteiligten entstehen und eine einheitliche Definition der verwendeten Begriffe erarbeitet werden, um im weiteren Projektverlauf Kommunikationsprobleme auszuschließen. In vielen Unternehmen ist die Entwicklung oder das Produktmanagement für die Anforderungsanalyse verantwortlich, da nur aus technischer Sicht ein vollständiges Systemverständnis möglich ist. • Fehlerhafte Anforderungen: Eine fehlerhafte Spezifikation der Anforderungen führt zu Problemen in den späteren Projektphasen bzw. während des Produktlebenszyklus’, die funktionale Nachbesserungen notwendig machen. • Nicht eindeutige Anforderungen: Die Korrektheit und Eindeutigkeit der spezifizierten Anforderungen ist von großer Bedeutung für die Entwicklung eines Produktes. Nur durch eine präzise und (semi-)formale Beschreibung der Anforderungen und durch einen aufwändigen Prüf- und Freigabeprozess am Ende der Anforderungsanalyse können Missverständnisse vermieden werden.

266

10 Best-Practice-Empfehlungen für die Auswahl von QSM

• Überspezifikation: Eine Überspezifikation, also die Definition von nicht erforderlichen Funktionen, führt zu Mehrkosten oder kann die Machbarkeit einer Produktentwicklung in Frage stellen. Î bei embedded Systemen bestehen u.a. auch die folgenden Probleme: • Unklare Schnittstellen zum technischen Prozess: Die Schnittstellen und die Charakteristika des technischen Prozesses sind nicht analysiert und dokumentiert. • Unklare Kompatibilitätsanforderungen: Die Kompatibilitätsanforderungen zu Vorgängerprodukten und das Zusammenwirken mit den anderen Komponenten des technischen Systems sind nicht klar spezifiziert. • Unklare Normen und Richtlinien: Geltende Normen und Richtlinien sind nicht klar spezifiziert, d.h. die Anforderungen, die sich aus geltenden Normen und Richtlinien ergeben, wie z.B. Sicherheitsanforderungen, Prozessanforderungen, sind nicht genau analysiert. • Realzeitanforderungen sind nicht klar spezifiziert: Das zeitliche Verhalten eines embedded Systems ist nicht genau spezifiziert. • Umgebungsbedingungen nicht spezifiziert: Die Bedingungen der Einsatzumgebung (Temperatur, Vibration, Schock, Feuchtigkeit, etc.) sind nicht spezifiziert, haben jedoch großen Einfluss auf die Realisierung des Produktes. Ebenso ist das Systemverhalten in Fehlersituationen (Fehlbedienungen, Ausnahmezustände etc.) und die mögliche Systembelastung zu definieren. Mangelhafte Kommunikationsbasis

• AG und AN reden aneinander vorbei: Missverständnisse zwischen den Anwendern und der Entwicklung müssen bereits in der Anforderungsanalyse ausgeschlossen werden, um ein gemeinsames Systemverständnis bei allen Beteiligten zu erreichen. Eine eindeutige Definition der verwendeten Begriffe ist dabei von großer Bedeutung. • Keine ganzheitliche Sichtweise: Ein ganzheitliches Verständnis des Systemumfeldes (Mechanik – Elektronik – SW – technischer Prozess) ist für die Vollständigkeit und Korrektheit der Anforderungsanalyse von entscheidender Bedeutung. • Mangelnde Aktualität der Anforderungsspezifikation: Die Aktualität, Vollständigkeit und Verständlichkeit der während der Anforderungsanalyse entstehenden Dokumentation ist wichtig, um Missverständnisse zwischen den Beteiligten an der Produktentstehung (Anwender, Elektronik-Entwicklung, SW-Entwicklung, Mechanik-Konstruktion, Produktmanagement, Marketing, Vertrieb) auszuschließen.

10.1 Anforderungen

267

Mangelhaftes Anforderungsmanagement

• Häufige Änderung der Anforderungen: Häufige Änderungen der Anforderungen während des Entwicklungsprozesses sind meist ein Symptom für eine unvollständige, fehlerhafte oder unverständliche Anforderungsspezifikation bzw. für einen mangelhaften Abstimmungsprozess mit den Anwendern. • Rückverfolgbarkeit von Anforderungsänderungen: In der Praxis verändert sich das Systemverständnis während des Produktentstehungsprozesses. Die sich ergebenden Änderungen der Anforderungsspezifikation sind oft in den Entwicklungsdokumenten nicht eingepflegt und damit eine Aktualität der Dokumentation nicht vorhanden. Eine Rückverfolgbarkeit wird somit nicht erreicht. Eine geringe bzw. keine Rückverfolgbarkeit von Anforderungsänderungen kann zu Problemen führen. Bei Projekten wie z.B. in der Medizintechnik, der pharmazeutischen Industrie oder im militärischen Bereich sind besondere Anforderungen an die Dokumentation zu berücksichtigen, die in speziellen Normen (z.B. GMP, GAMP) beschrieben sind. • Fehlendes Review und Freigabe von Anforderungen: Die Anforderungsspezifikation muss von allen Beteiligten an der Produktentstehung (Anwender, Elektronik-Entwicklung, SW-Entwicklung, MechanikKonstruktion, Produktmanagement, Marketing, Vertrieb) geprüft und durch einen formalen Prozess freigegeben werden, um eine einheitliche Arbeitsgrundlage für die nachfolgenden Projektphasen zu haben. Der Projektleiter oder das Produktmanagement trägt für den Abstimmungsprozess und die Qualität der Dokumentation Verantwortung. • Keine eindeutige Verantwortlichkeit für Anforderungs- und Änderungsmanagement: Für die Anforderungsspezifikation bzw. den nachfolgenden Änderungsprozess ist oft kein eindeutiger Verantwortlicher benannt, der eine gute Kommunikation zwischen den Beteiligten an der Produktentstehung und insbesondere auch zum Kunden aufbauen und Kommunikationsprobleme ausschließen kann. 10.1.2 Zuordnungen

Tabelle 10.1, 10.2 und 10.3 bilden die Zuordnungsmatrizen für die Probleme der Anforderungsanalyse und der analytischen, konstruktiven und organisatorischen QS-Maßnahmen ab.

Review und Inspektion

Schreibtischtest

Walkthrough

Komplexitäts- und Timing-Analyse

Metriken

Simulation zu Testzwecken

Integrationstest

Modultest

Regressionstest

Stresstest

Instrumentierung

White-Box Test

1

3 3 3 3 3 3 2 3 3 1 1 1 1 1 1 1 1 2 2 2 1 2 2 1 2 2

Akzeptanztest

Black-Box Test Abnahmetest

Datenflussanalyse Codeanalyse

Inbetriebnahmetest FMEA

In-circuit-Emulation

3

Keine Verantw. für Anforderungs- und Änderungsmanagement

Fehlendes Review und Freigabe von Anforderungen

Rückverfolgbarkeit von Anforderungsänderungen

Häufige Änderung der Anforderungen

Mangelnde Aktualität der Anforderungsspezifikation

Keine ganzheitliche Sichtweise

AG und AN reden aneinander vorbei

Umgebungsbedingungen nicht spezifiziert

Realzeitanforderungen sind nicht klar spezifiziert

unklare Normen und Richtlinien

unklare Kompatibilitätsanforderungen

unklare Schnittstellen zum technischen Prozess

Überspezifikation

nicht eindeutige Anforderungen

fehlerhafte Anforderungen

unvollständige Anforderungen

268 10 Best-Practice-Empfehlungen für die Auswahl von QSM

Tabelle 10.1. Anforderung – Analytische QSM

Festlegung des Engineering-Modells

Risikomanagement

Checklisten

Dokumentationsrichtlinien

Dokumentenvorlagen

1

1 1 1 1

Änderungsmanagement

1 1 1 1 1 1 1 1

Keine ganzheitliche Sichtweise

1 2 2 3 2 2

Defect Management, Bug Tracking Phasen- und Projektreview

Fehlerdatenbank

1 3 3

Designrichtlinien

1 1 1 1

Programmierrichtlinien

1 1

Testabdeckungsmatrix

1 1 1

Unabhängige Testgr. (-pers.)

3

Keine Verantw. für Anforderungs- und Änderungsmanagement

Fehlendes Review und Freigabe von Anforderungen

Rückverfolgbarkeit von Anforderungsänderungen

Häufige Änderung der Anforderungen

3 3 3 3 1 2 1 1 1

Mangelnde Aktualität der Anforderungsspezifikation

Vers.- und Konfig.management AG und AN reden aneinander vorbei

Umgebungsbedingungen nicht spezifiziert

Realzeitanforderungen sind nicht klar spezifiziert

unklare Normen und Richtlinien

unklare Kompatibilitätsanforderungen

unklare Schnittstellen zum technischen Prozess

Überspezifikation

nicht eindeutige Anforderungen

fehlerhafte Anforderungen

unvollständige Anforderungen

10.1 Anforderungen 269

Tabelle 10.2. Anforderung – Konstruktive QSM

270

10 Best-Practice-Empfehlungen für die Auswahl von QSM

Keine Verantw. für Anforderungs- und Änderungsmanagement

Fehlendes Review und Freigabe von Anforderungen

2 2 3 2 2

Rückverfolgbarkeit von Anforderungsänderungen

Häufige Änderung der Anforderungen

Keine ganzheitliche Sichtweise

AG und AN reden aneinander vorbei

Umgebungsbedingungen nicht spezifiziert

Realzeitanforderungen sind nicht klar spezifiziert

unklare Normen und Richtlinien

unklare Kompatibilitätsanforderungen

unklare Schnittstellen zum technischen Prozess

Überspezifikation

nicht eindeutige Anforderungen

1

3 3 3 3 1 2 1 1 1

Vers.- und Konfig.management Risikomanagement

Mangelnde Aktualität der Anforderungsspezifikation

Festlegung des Engineering-Modells

fehlerhafte Anforderungen

unvollständige Anforderungen

Tabelle 10.3. Anforderung – Organisatorische QSM

1 1 1

Testabdeckungsmatrix Unabhängige Testgr. (-pers.)

3

Phasen- und Projektreview Defect Management, Bug Tracking

1 3 3

Änderungsmanagement Fehlerdatenbank Checklisten

1

1 1

1 1 1 1

Designrichtlinien Programmierrichtlinien Dokumentationsrichtlinien Dokumentenvorlagen

1 1

1 1 1 1 1 1 1 1

2 3 2 2 2 3

2 2

Dokumentationssystem Dokumentation von Entscheidungen Glossar/Terminologie

2 2 2

1 1 2 3 3 3

QS-Handbuch

2 2

QS-Handbuch (projektspezifisch) QS-planung für den Entw.prozess Q-Berichterstattung Verfahrensaudit

1 1 1

1

10.2 System-Design

271

10.2 System-Design Das Kapitel System-Design bezieht sich auf die in der Phase des Systementwurfs bzw. –designs möglicherweise entstehenden Probleme. 10.2.1 Problembeschreibung

Die Problembeschreibung umfasst die mangelnde Qualität des Designs und die mangelhafte Kommunikationsbasis. Mangelnde Qualität des Designs

• Mangelhafte oder fehlende Systemarchitektur: Nur durch die Zerlegung des Gesamtsystems in Komponenten und eine eindeutige Zuordnung der Systemfunktion zu den Komponenten ist eine zweckmäßige Modellierung des Systems möglich. Die Dokumentation der Schnittstellen umfasst alle Details, deren Kenntnis zum Austausch oder zum Hinzufügen einer Komponente notwendig wäre. Diese Systembeschreibung sollte eine statische und eine dynamische Sicht enthalten. Die Beziehungen und Schnittstellen zwischen der im Pflichtenheft geforderten Funktionalität und den zuständigen Komponenten können bei schlechter oder fehlender Systemarchitektur nicht eindeutig nachvollzogen werden. • Mangelhafte oder fehlende Beschreibung des Systemverhaltens: Keine oder nur natürlichsprachliche Beschreibung des dynamischen Systemverhaltens, d.h. der Systemzustände und der Zustandsübergänge, bzw. von Kausalbeziehungen zwischen Aktivitäten von Komponenten kann zu Problemen führen, die meist erst im Verlauf der Systemintegration erkannt werden. • Externe Schnittstellen sind nicht definiert: Produktschnittstellen zum technischen Prozess, zum Bediener und zu Fremdsystemen werden im Design-Modell oft nur unvollkommen berücksichtigt. Werden Protokolle, die komplexes Schnittstellenverhalten beschreiben, nicht modelliert, sind Probleme beim Zusammenspiel zwischen Systemen und bei der Interaktion mit dem Bediener abzusehen. • Umsetzung von nicht-funktionalen Anforderungen: Mangelnde Umsetzung von nicht-funktionalen Anforderungen, d.h. Nicht-funktionale Anforderungen an ein Produkt, also z.B. Stabilität, Performance und Robustheit, werden in der Anforderungsanalyse nicht explizit spezifiziert. Stattdessen werden bereits technische Entwurfsentscheidungen vorweg genommen, mit welchen man versucht, die Anforderung zu beschreiben. Beispielsweise könnte im Verlauf der Anforderungsdefinition Konsens

272

•

•

•

•

10 Best-Practice-Empfehlungen für die Auswahl von QSM

bestehen, dass eine 32 Bit Mikroprozessor-Plattform verwendet wird und man verzichtet auf konkrete Definition der Anforderungen bezüglich der Performance. Somit hat man weder die eigentliche nichtfunktionale Anforderung umgesetzt noch eine sinnvolle Entwurfsentscheidung getroffen. Geringe Änderbarkeit und Wartbarkeit: Auf Grund mangelhafter Dokumentation und Nicht-Beachtung von Design-Richtlinien kann der Entwurf im Nachhinein schlecht nachvollzogen und somit geändert und gewartet werden. Geringe Wiederverwendbarkeit von Komponenten: Eine geringe Wiederverwendbarkeit von Komponenten führt zu einer vermeidbaren Ineffizienz. Das Auffinden wiederverwendbarer Produktkomponenten (z.B. SW) setzt voraus, dass im Unternehmen Produkte und Produktkomponenten klassifiziert werden. Im Rahmen dieser Klassifizierung können dann Zuständigkeiten gesucht und Schnittstellen definiert werden, die klassenübergreifend invariant sind. Fertigungs-, montage- oder test-unfreundliches Design: Experten aus den Bereichen Fertigung, Qualitätssicherung und Prüfmittelbau werden an Entscheidungen, die in der Designphase getroffen werden, nicht hinreichend beteiligt, was zu Schwierigkeiten in späteren Produktphasen führen kann. Ebenso stehen beim Design häufig die funktionalen Anforderungen im Mittelpunkt, die Handhabbarkeit der Produkte bei der Montage und Inbetriebnahme wird jedoch vernachlässigt. Fehlendes Review und Freigabe vom System-Design: Durch fehlende Review- und Freigabeaktivitäten könnte ein fehlerhaftes und unvollständiges System-Design als Grundlage für Folgearbeiten genutzt werden. Dies führt zu einem Verschleppen der Fehler und einem exponentiellen Ansteigen der Fehlerbehebungskosten.

10.2 System-Design

273

Mangelhafte Kommunikationsbasis

• Konkurrierende Anforderungen: Während des System-Designs wird deutlich, dass die beabsichtigte Lösung nicht alle spezifizierten Anforderungen in der gleichen Güte erfüllen kann, z.B. Stromverbrauch/Taktfrequenz von Mikroprozessor versus Performance von Algorithmen. Mangelnde Zusammenarbeit zwischen HW- und SWEntwicklung kann dazu führen, dass eine aus Gesamtsystemsicht suboptimale Lösung ausgewählt wird. In bestimmten Fällen kann auch eine Veränderung der Entwicklungsergebnisse vorangegangener Phasen notwendig werden. Insbesondere die Entscheidung der Realisierbarkeit der Funktionalität in HW oder SW bedarf einer intensiven Diskussion. • Keine Verantwortlichkeit für die Systemarchitektur: Eine fehlende Verantwortlichkeit für die Systemarchitektur kann zu einer mangelnden Aktualität der Systemarchitektur und einer Inkonsistenz mit dem Moduldesign führen. Falls es diese Rolle nicht gibt, driften häufig die Systemarchitektur und das Moduldesign auseinander. 10.2.2 Zuordnungen

Tabelle 10.4, 10.5 und 10.6 zeigen die Zuordnungsmatrizen für die Probleme des System Designs und der analytischen, konstruktiven und organisatorischen QS-Maßnahmen.

Abnahmetest

Datenflussanalyse Codeanalyse

Inbetriebnahmetest FMEA

Review und Inspektion In-circuit-Emulation

Schreibtischtest

Walkthrough

Komplexitäts- und Timing-Analyse

Metriken

Simulation zu Testzwecken

1 1 2

3 1 2

3 1 2

3 1 2

Modultest

Integrationstest

Regressionstest

Stresstest

Instrumentierung

White-Box Test

2

3 1 2

3 1 2 3

2

3 1 2

Keine Verantwortlichkeit für die Systemarchitektur

konkurrierende Anforderungen

Fehlendes Review und Freigabe vom System-Design

Fertigungs-, montage- oder testunfreundliches Design

geringe Wiederverwendbarkeit von Komponenten

geringe Änderbarkeit und Wartbarkeit

Umsetzung von nicht-funktionalen Anforderungen

externe Schnittstellen sind nicht definiert

Black-Box Test

Mangelhafte oder fehlende Beschreibung des Systemverhaltens

Akzeptanztest Mangelhafte oder fehlende Systemarchitektur

274 10 Best-Practice-Empfehlungen für die Auswahl von QSM

Tabelle 10.4. System Design – Analytische QSM

Anforderungsverfolgung Anforderungsanalyse

SW-Architekturentwurf

SA/SD

UML

Sim. zur Anf.- bzw. Entw.absicherung

Wiederverw. von Projektergebnissen

Defensive Programmierung

Code-Generierung

Endliche Automaten

Petrinetze

Sequenzdiagramme

SDL

Prototyping

2

2 2

2 2 3 2 3 3 3 3

2 3 3

2 2

2 3

2 1

1 3 3

Keine Verantwortlichkeit für die Systemarchitektur

konkurrierende Anforderungen

Fehlendes Review und Freigabe vom System-Design

Fertigungs-, montage- oder testunfreundliches Design

geringe Wiederverwendbarkeit von Komponenten

geringe Änderbarkeit und Wartbarkeit

Umsetzung von nicht-funktionalen Anforderungen

3 3 3 3 2 2 2 2 2 2

externe Schnittstellen sind nicht definiert

3 3 3

Mangelhafte oder fehlende Beschreibung des Systemverhaltens

Mangelhafte oder fehlende Systemarchitektur

10.2 System-Design 275

Tabelle 10.5. System Design – Konstruktive QSM

276

10 Best-Practice-Empfehlungen für die Auswahl von QSM

Mangelhafte oder fehlende Beschreibung des Systemverhaltens

externe Schnittstellen sind nicht definiert

Umsetzung von nicht-funktionalen Anforderungen

geringe Änderbarkeit und Wartbarkeit

geringe Wiederverwendbarkeit von Komponenten

Fertigungs-, montage- oder testunfreundliches Design

Fehlendes Review und Freigabe vom System-Design

konkurrierende Anforderungen

Keine Verantwortlichkeit für die Systemarchitektur

Festlegung des Engineering-Modells

Mangelhafte oder fehlende Systemarchitektur

Tabelle 10.6. System Design – Organisatorische QSM

3

3

1

2

2

2

1

3

1

3

2

2

2

2

2

2

2

3

3

2

1

1

1

1

Vers.- und Konfig.management Risikomanagement

1

Testabdeckungsmatrix Unabhängige Testgr. (-pers.) Phasen- und Projektreview

3

2

2

Defect Management, Bug Tracking

1

Änderungsmanagement Fehlerdatenbank Checklisten Designrichtlinien

2

2

2

1 1

1 1

1 1

3

2

Programmierrichtlinien Dokumentationsrichtlinien Dokumentenvorlagen

2 3

Dokumentationssystem Dokumentation von Entscheidungen

3

Glossar/Terminologie QS-Handbuch QS-Handbuch (projektspezifisch) QS-planung für den Entw.prozess Q-Berichterstattung Verfahrensaudit

1

1

1

1

2 1 1 1

2 1

10.3 Realisierung

277

10.3 Realisierung 10.3.1 Problembeschreibung Mangelndes Moduldesign

• Mangelhafte oder fehlende Modularchitektur (HW + SW): Nur durch die vollständige Dokumentation des Moduls bzgl. seiner Schnittstellen und seines Verhaltens ist die korrekte Verwendung möglich, um die geforderte Funktionalität zu erfüllen. Die Modularchitektur umfasst neben der Beschreibung seiner Schnittstellen auch die Beschreibung des Verhaltens (Sollverhalten, Fehlerverhalten) sowie des Kontrollflusses (Algorithmus). Eine schlechte oder fehlende Modularchitektur geht zu Lasten der Wartbarkeit, Testbarkeit, korrekten Verwendung (auch im Verbund mit anderen Modulen) und Wiederverwendung. • Mangelnde Beschreibung des Modulverhaltens: Die fehlerhafte Beschreibung der Zustände (Zustandsmenge unvollständig) und der Zustandsübergänge (Wertebereich für Funktionsparameter nicht definiert, Abhängigkeiten und Kombinationen der Funktionsparameter nicht berücksichtigt) führt in der Regel zu einem unerwünschten Modulverhalten. Dies kann im Extremfall die Zerstörung der Maschine oder eine Personengefährdung bedeuten. • Mangelnde Festlegung von Fehlerzuständen: Grundsätzlich gilt dasselbe wie bei der mangelnden Beschreibung des Modulverhaltens. Besonders wichtig ist jedoch, dass bei der Beschreibung des Verhaltens Fehlbedienungen und Störgrößen mit einbezogen werden müssen. Das Gerät muss im Fehlerfall immer einen sicheren Zustand einnehmen. • Fehlendes Review und Freigabe von Modul-Design: Durch fehlende Review- und Freigabeaktivitäten könnte ein fehlerhaftes und unvollständiges Modul-Design als Grundlage für Folgearbeiten genutzt werden. Dies führt zu Problemen bei Implementierung und Integration und somit einem exponentiellen Ansteigen der Fehlerbehebungskosten.

278

10 Best-Practice-Empfehlungen für die Auswahl von QSM

Implementierung

• Funktionale Anforderungen nicht umsetzbar: Funktionale Anforderungen können nicht umgesetzt werden, weil die HW die notwendigen, aber ursprünglich zugesagten Eigenschaften nicht erfüllt. • Umsetzung der Performance-Anforderungen: Wenn die beteiligten SWund HW-Komponenten nicht die erforderlichen Eigenschaften besitzen, können die Performance-Anforderungen nicht erfüllt werden. • Mangelnde Wiederverwendbarkeit alter Projektergebnisse: Alte Projektergebnisse können aufgrund von Inkompatibilitäten nicht übernommen und müssen neu erstellt werden. Dadurch kann das eingeplante Einsparpotential bezüglich Aufwand und der Qualitätsgewinn durch Wiederverwendung von bereits getesteten Komponenten nicht genutzt werden. Modulintegration und -test

• Mangelnde Ressourcen-Planung für den Modultest: Der Aufbau bzw. die Beschaffung der für den Modultest benötigten Testumgebung (TestHW) muss frühzeitig geplant werden (Entwurfsphase), damit diese rechtzeitig zur Verfügung steht. Eine schlechte Planung führt dazu, dass das Modul nicht korrekt und vollständig geprüft werden kann. • Unentdeckte Fehler im Modultest: Fehler, die nicht durch einen Modultest entdeckt werden, bleiben mit hoher Wahrscheinlichkeit auch in späteren Testphasen unentdeckt. Diese Fehler tendieren dazu, auch im ausgelieferten Produkt vorhanden zu sein. • Mangelnder Modul-Integrationstestplan: Der Modulintegrationstestplan beschreibt die Integrationsstrategie und damit verbunden die Reihenfolge, in der die einzelnen Module schrittweise zu Teilsystemen (bzw. später zum Gesamtsystem) zusammengebaut werden. Ferner werden für die einzelnen Teilintegrationen die Testaktivitäten und -ziele beschrieben. Durch die fehlenden Integrationsschritte (Big-Bang-Integration) sind Fehler und deren Ursachen aufwändiger zu finden, technische Probleme erst spät erkennbar und Prototypen verfügbar. 10.3.2 Zuordnungen

Tabelle 10.7, 10.8 und 10.9 stellen die Zuordnungsmatrix für die Probleme in den Realisierungsphasen Moduldesign, Integration, Modulintegration und -test und in den analytischen, konstruktiven und organisatorischen QSMaßnahmen dar.

FMEA

Review und Inspektion

Schreibtischtest

Walkthrough

Komplexitäts- und Timing-Analyse

Simulation zu Testzwecken

2 1 1 1

2 1 1

2

2 1 1

Integrationstest

Modultest

White-Box Test

2 3

2 2

Regressionstest

2

Instrumentierung

Metriken

3

1

Black-Box Test

Codeanalyse

Datenflussanalyse

In-circuit-Emulation

2 1 1 1 2

3

2 1 3 2 3 2

Stresstest

2 3 1 2 1 2

Mangelnder Modul-Integrationstestplan

Unentdeckte Fehler im Modultest

Mangelnde Ressourcen-Planung für den Modultest

Mangelnde Wiederverwendung alter Projektergebnisse

Umsetzung der Performance-Anforderungen

Funktionale Anforderungen nicht umsetztbar

Fehlendes Review und Freigabe von Modul-Design

Mangelnde Festlegung von Fehlerzuständen

Mangelnde Beschreibung des Modulverhalten

Mangelhafte oder fehlende Modularchitektur

10.3 Realisierung 279

Tabelle 10.7. Realisierung – Analytische QSM

Akzeptanztest

Abnahmetest

3 1 1

Inbetriebnahmetest

2

3

Anforderungsverfolgung

SW-Architekturentwurf

SA/SD

UML

Wiederverw. von Projektergebnissen

Defensive Programmierung

Code-Generierung

2 3

Endliche Automaten

Petrinetze

Sequenzdiagramme

3

SDL

Prototyping

3

Sim. zur Anf.- bzw. Entw.absicherung

2 3 3

3 3 3 3 3 3 1 1 2

3 3 3 3 3 3 1 1 2

3

Umsetzung der Performance-Anforderungen

3 3 3 3 2

1 1

1

2

3

Mangelnder Modul-Integrationstestplan

Unentdeckte Fehler im Modultest

Mangelnde Ressourcen-Planung für den Modultest

Mangelnde Wiederverwendung alter Projektergebnisse

Funktionale Anforderungen nicht umsetztbar

Fehlendes Review und Freigabe von Modul-Design

Mangelnde Festlegung von Fehlerzuständen

Anforderungsanalyse Mangelnde Beschreibung des Modulverhalten

Mangelhafte oder fehlende Modularchitektur

280 10 Best-Practice-Empfehlungen für die Auswahl von QSM

Tabelle 10.8. Realisierung – Konstruktive QSM

1 3 3 3 3 3 3 3 3 1

2

10.3 Realisierung

281

1

1

3

3

Mangelnder Modul-Integrationstestplan

1

Unentdeckte Fehler im Modultest

2

3

Mangelnde Ressourcen-Planung für den Modultest

1

Mangelnde Wiederverwendung alter Projektergebnisse

1

Umsetzung der Performance-Anforderungen

3

Funktionale Anforderungen nicht umsetztbar

Mangelnde Festlegung von Fehlerzuständen

3

Fehlendes Review und Freigabe von Modul-Design

Mangelnde Beschreibung des Modulverhalten

Festlegung des Engineering-Modells

Mangelhafte oder fehlende Modularchitektur

Tabelle 10.9. Realisierung – Organisatorische QSM

1

2

Vers.- und Konfig.management Risikomanagement

2 1

Testabdeckungsmatrix Unabhängige Testgr. (-pers.) Phasen- und Projektreview

1

1

1

3

2

2

1

3 3

2

1 1 1

1

Defect Management, Bug Tracking Änderungsmanagement Fehlerdatenbank Checklisten Designrichtlinien

1 2

1 2

1 2

1 1

1 1

1 1

2

2

2

1

Programmierrichtlinien Dokumentationsrichtlinien Dokumentenvorlagen Dokumentationssystem Dokumentation von Entscheidungen

2 3

1 2 1

1 1

1

Glossar/Terminologie QS-Handbuch QS-Handbuch (projektspezifisch) QS-planung für den Entw.prozess Q-Berichterstattung Verfahrensaudit

2 2 1 1

1

1

1

1

282

10 Best-Practice-Empfehlungen für die Auswahl von QSM

10.4 Systemintegration- und test 10.4.1 Problembeschreibung

• Seiteneffekte bei der Fehlerbehebung: Treten bei Prüfungen Fehler auf, so birgt der sich anschließende Fehlerbereinigungsprozess die Gefahr, dass die durchgeführten Änderungen wiederum Fehler nach sich ziehen. Häufig bleiben diese Fehler unbemerkt, da nur die betreffende fehlerhafte Komponente verifiziert wird und nicht das Zusammenspiel mit anderen Komponenten. • Unzureichender Testplan und Testfallspezifikation: Ist ein Testplan unvollständig oder inkonsistent oder eine Testfallspezifikation unzureichend, so besteht die Gefahr, dass wesentliche Fehler unentdeckt bleiben. Meist werden neuere Komponenten ausführlich geprüft, Änderungen in bestehenden Komponenten jedoch weniger ausführlich getestet. • Probleme bei der Abnahme durch externe Prüforganisationen: Werden für Prüfungen externe Prüforganisationen herangezogen bzw. gefordert, so können enorme Kosten durch die notwendige Wiederholung der Prüfung oder eine Terminverschiebung der Produktfreigabe (hohe zeitliche Auslastung der Prüforganisation) entstehen. • Keine Trennung der Rolle Entwickler und Tester: Werden Tests vom Entwickler selbst durchgeführt, so werden Denkfehler des Entwicklers in der Regel nicht aufgedeckt („Betriebsblindheit“). • Fehlendes Review der Testdurchführung und -auswertung: Bei Prüfungen wird häufig das Prüfergebnis alleine vom Prüfenden festgehalten und dokumentiert. Fehlende Prüfungen bzw. Fehlinterpretation von z.B. Kurvenverläufen in Messprotokollen bleiben so unentdeckt. • Unvollständige Tests nicht-funktionaler Anforderungen: Während der Erstellung des Prüfplans liegt meist das Hauptaugenmerk auf der Erfüllung der geforderten Funktionalitäten. Nicht-funktionale Anforderungen (z.B. Stabilität, Performance, Robustheit etc.) werden somit häufig vernachlässigt. Dieser Aspekt gilt vor allem für nicht-funktionale Anforderungen, die nur durch die Kombination mehrerer Testkriterien geprüft werden können.

10.4 Systemintegration- und test

283

• Realitätsnahes Testbett ist aufwändig: Je nach vorgesehenem Einsatzgebiet kann die Bereitstellung eines möglichst realitätsnahen Testbetts sehr kostenintensiv und zeitaufwändig sein. Das darf nicht bedeuten, dass diese Tests nicht bzw. nur mangelhaft durchgeführt werden sollen, denn hierdurch würde das Risiko, dass Fehler im endgültigen Produkt vorhanden sind, sehr stark ansteigen. Es ist eine genaue Kosten-NutzenBetrachtung notwendig. • Keine expliziten Freigabekriterien: Produkte dürfen erst dann nach außen gegeben bzw. verkauft werden, wenn alle Freigabekriterien erfüllt sind. Ohne explizite Freigabe können Produkte in minderer Qualität nach außen gelangen. Eine explizite Produktfreigabe ist notwendig, um nachfolgende Prozesse (Produktion, Marketing, Vertrieb) zu aktivieren. Um einen Terminverzug zu vermeiden, ist daher die Produktfreigabe zu allen Beteiligten zu kommunizieren.

10.4.2 Zuordnungen

Tabelle 10.10, 10.11 und 10.12 zeigen die Zuordnungsmatrizen für die Probleme in Systemintegration und -test und in den analytischen, konstruktiven und organisatorischen QS-Maßnahmen.

284

10 Best-Practice-Empfehlungen für die Auswahl von QSM

Keine expliziten Freigabekriterien

Realitätsnahes Testbett ist aufwändig

Unvollständige Tests nicht-funktionaler Anforderungen

Fehlendes Review der Testdurchführung und -auswertung

Keine Trennung der Rolle Entwickler und Tester

Probleme bei der Abnahme durch externe Prüforganisationen

Unzureichender Testplan und Testfallspezifikation

Seiteneffekte bei der Fehlerbehebung

Tabelle 10.10. Systemintegration und -test – Analytische QSM

Akzeptanztest Abnahmetest Black-Box Test Codeanalyse Datenflussanalyse

2 2

FMEA Inbetriebnahmetest In-circuit-Emulation Review und Inspektion Schreibtischtest Walkthrough Modultest Integrationstest

1 2 2 2 2 2

Stresstest Regressionstest White-Box Test

3 2

3 2 2 3 2 2 3 1 1 2 3 3 2 2

3

3 3

3

3 1 1

3

1 3 3

Instrumentierung Komplexitäts- und Timing-Analyse

1

Metriken Simulation zu Testzwecken

1

2 1

1

2 1

SW-Architekturentwurf

Endliche Automaten

Petrinetze

Sequenzdiagramme SA/SD

UML SDL

Defensive Programmierung

Code-Generierung

Sim. zur Anf.- bzw. Entw.absicherung Prototyping

Wiederverw. von Projektergebnissen

2 1 3 3 3 3 2 2 2 2 2 2 2 3 1 1 3 3

2

2 2

1

3

Fehlendes Review der Testdurchführung und -auswertung

Keine Trennung der Rolle Entwickler und Tester

Probleme bei der Abnahme durch externe Prüforganisationen

Keine expliziten Freigabekriterien

2 2 2 2 2 2 2 Realitätsnahes Testbett ist aufwändig

Anforderungsanalyse Unvollständige Tests nicht-funktionaler Anforderungen

Anforderungsverfolgung Unzureichender Testplan und Testfallspezifikation

Seiteneffekte bei der Fehlerbehebung

10.4 Systemintegration- und test 285

Tabelle 10.11. Systemintegration und -test – Konstruktive QSM

286

10 Best-Practice-Empfehlungen für die Auswahl von QSM

Defect Management, Bug Tracking Änderungsmanagement Fehlerdatenbank Checklisten Designrichtlinien Programmierrichtlinien

1 2 2

Dokumentationsrichtlinien

3

Dokumentenvorlagen Dokumentationssystem Dokumentation von Entscheidungen

Keine expliziten Freigabekriterien

Phasen- und Projektreview

Realitätsnahes Testbett ist aufwändig

Unabhängige Testgr. (-pers.)

Unvollständige Tests nicht-funktionaler Anforderungen

1 3 1 1

Risikomanagement Testabdeckungsmatrix

3 2 1 3 3 3 2 2 2 3 2 2 2 2 1 2

Fehlendes Review der Testdurchführung und -auswertung

1

Keine Trennung der Rolle Entwickler und Tester

3

Vers.- und Konfig.management

Probleme bei der Abnahme durch externe Prüforganisationen

Unzureichender Testplan und Testfallspezifikation

Festlegung des Engineering-Modells

Seiteneffekte bei der Fehlerbehebung

Tabelle 10.12. Systemintegration und -test – Organisatorische QSM

3

3

3

3

3

1

3 3 1 2 2 1

2 3 2

2

3

1

1

3

1

1

Glossar/Terminologie QS-Handbuch QS-Handbuch (projektspezifisch) QS-planung für den Entw.prozess

1 3

2 2

Q-Berichterstattung Verfahrensaudit

1

1 1

1 1

1

1 3

10.5 Projektmanagement

287

10.5 Projektmanagement 10.5.1 Problembeschreibung Personelle Aspekte

• Unerfahrene Mitarbeiter: Es ist notwendig, zwischen „Wissen“, „Können“ und „Erfahrung“ zu unterscheiden. Ein Mitarbeiter „weiß“ etwas, wenn er ein Buch gelesen hat oder ein Training besucht hat. Der Mitarbeiter „kann“ etwas, wenn er sein Wissen mindestens einmal fehlerfrei angewendet hat. „Erfahrung“ erwirbt sich der Mitarbeiter, wenn er sein „Können“ mehrfach unter evtl. verschiedenen Situationen erfolgreich angewendet hat. Unerfahrene Mitarbeiter bearbeiten Aufgaben oft falsch oder fehlerhaft, was zu einem höheren Aufwand als bei erfahrenen Mitarbeitern führt. • Teamzusammensetzung: Es muss auf die richtige Zusammensetzung des Projektteams geachtet werden, so dass dieses effektiv zusammenarbeiten kann (und nicht nur eine „Gruppe“ von Personen darstellt). Wichtige Parameter für die Zusammensetzung sind o die notwendige Qualifikation (siehe oben; Unterscheidung in Wissen, Können, Erfahrung) o die benötigte Personalkapazität o die persönlichen Ziele der einzelnen Mitarbeiter o Beziehung der Mitarbeiter untereinander (ist z.B. bekannt, dass einige Mitarbeiter sich nicht „ausstehen“ können?) • Abstimmungs- und Kommunikationsprobleme: Benötigte Informationen sind in betroffenen Teilteams bzw. bei betroffenen Mitarbeitern innerhalb eines Projekts nicht bekannt. Dadurch entstehen z.B. Fehlentwicklungen, zusätzliche Aufwände durch ineffizientes Arbeiten, u.ä.. • Ressourcenmangel: Es fehlt geeignetes Personal (siehe auch Teamzusammensetzung), so dass Termine nicht eingehalten werden können.

288

10 Best-Practice-Empfehlungen für die Auswahl von QSM

Prozesse

• Unklare Verantwortlichkeiten: Aufgaben werden im Projektteam, in der Abteilung oder extern nicht in eindeutigen Verantwortlichkeiten zugeteilt. Wichtig ist, dass immer genau ein Verantwortlicher benannt ist. Falls niemand benannt ist, wird die Aufgabe höchstwahrscheinlich von niemandem bearbeitet. Wenn mehrere benannt sind, fühlt sich oft niemand direkt angesprochen, d.h. die Aufgabe wird nicht oder nur halbherzig bearbeitet. • Entscheidungen nicht nachvollziehbar: Nicht dokumentierte und nachvollziehbare Entscheidungen führen oft zu erneuten Diskussionen über Probleme, die längst diskutiert und entschieden waren. Durch die Dokumentation von Entscheidungen lässt sich der Zeitaufwand für diese Diskussionen erheblich reduzieren. • Keine klaren Kriterien für Meilensteine: Es kann nicht objektiv festgestellt werden, ob ein Meilenstein erreicht ist oder nicht; eine Projektfortschrittsmessung ist damit nicht möglich! Eine Meilensteindefinition muss deshalb immer aus Inhalt (d.h. messbaren Kriterien) und Termin bestehen und nie nur allein aus dem Termin! • Späte Abstimmung mit der Produktion: Folgen einer mangelhaften Kommunikation zwischen Entwicklung und Produktion sind z.B. Probleme bei der Produktion, Qualitätssicherung am Produktionsende nicht oder nur eingeschränkt möglich, da Testschnittstellen nicht zur Verfügung stehen; schlechte Ressourcenauslastung in der Produktion durch ungenügende Kommunikation von Terminen, Lieferengpässe, u.a. • Späte Abstimmung mit Marketing/Vertrieb: Das Marketing wird üblicherweise neben dem Kunden ebenfalls ein Lieferant von Anforderungen sein. Vor allem muss das Marketing aber genau darüber Bescheid wissen, welche Anforderungen in welcher Version des Produktes realisiert sein werden, damit eine „wahrheitsgetreue“ Werbung gemacht werden kann. Ebenso muss der Vertrieb frühzeitig (oft bereits weit vor Entwicklungsende!) über die Eigenschaften des Produktes und den Zeitpunkt, zu dem die neue Produktversion verfügbar ist, informiert sein. Folgen einer mangelhaften Kommunikation zwischen Entwicklung, Marketing und Vertrieb spiegeln sich vor allem nach außen, d.h. in der Kundenunzufriedenheit (bedingt durch falsche Aussagen seitens Marketing und Vertrieb) wieder. • Mangelnde Aktualität von Entwicklungsdokumenten: Die Aktualität, Vollständigkeit und Verständlichkeit der entstehenden Dokumentation ist wichtig, um Missverständnisse zwischen den Beteiligten an der Produktentstehung (Anwender, Elektronik-Entwicklung, SW-Entwicklung, Mechanik-Konstruktion, Produktmanagement, Marketing, Vertrieb)

10.5 Projektmanagement

•

•

•

•

•

•

289

auszuschließen. Damit ist sichergestellt, dass alle Beteiligten an dem gleichen Ziel arbeiten und teure Fehlentwicklungen vermieden werden. Späte Erkennung von Fehlern: Die Kosten für die Fehlerbehebung steigt im Entwicklungsprozess exponentiell mit der Dauer, mit der sie unentdeckt im System sind, an. Daher sind qualitätssichernde Maßnahmen so früh wie möglich durchzuführen. Späte Erstellung der Produkt-Dokumentation: Die späte Erstellung der Produktdokumentation führt dazu, dass diese auch erst spät verfügbar ist. D.h. Vertrieb, Wartung und Support haben keine verlässlichen Aussagen über das Produkt (siehe auch Abstimmung mit Marketing / Vertrieb). Mangelhafte Dokumentation der Entwicklung während des Projekts: Dies führt zu Problemen, falls das Produkt der Wartung unterliegt. Insbesondere führt dies dazu, dass Änderungen am Produkt zeitaufwändig sind und zudem ggf. auch fehlerhaft. Entwicklungs-Know-how sollte auch über Projektgrenzen hinaus kommuniziert werden (z.B. im Sinne von Erfahrungsberichte an Kollegen in anderen Projekten). Fehlt dies, wird die Chance auf ein „Lernen in der Organisation“ verzichtet. Fehlerhafte Aufwandsschätzung und Kalkulation: Dies führt zu ggf. deutlichen Termin- und Kostenüberschreitungen gegenüber der ursprünglichen Planung. Die Aufwände für die SW-Entwicklung werden oft falsch eingeschätzt, da z.B. kaum Erfahrungen in der Anwendung von Metriken zur Aufwandsabschätzung vorliegen. Mangelhafte Quantifizierbarkeit des Entwicklungsstandes: Es ist nicht messbar, wo das Projekt steht. Zum einen sind klare Kriterien für Meilensteine notwendig (siehe auch „Keine klaren Kriterien für Meilensteine“), andererseits ist Erfahrung in Anwendung von Metriken zur Projektkontrolle erforderlich. Damit ist auch keine verlässliche Aussage möglich, wie lange das Projekt noch dauern wird bzw. wie viel es kosten wird. Die Einhaltung der Parameter Zeit und Kosten sind aber (neben der Qualität) zwei wichtige Erfolgskriterien für ein Projekt! Abhängigkeit von Komponentenlieferanten und Entwicklungsdienstleistern: Projekte werden oftmals nicht nur von internen Mitarbeitern durchgeführt, sondern in Zusammenarbeit mit freien Mitarbeitern, externen Dienstleistungsunternehmen oder auch Lieferanten von Produkten (z.B. Hardware). Eigene Arbeitsergebnisse sind dann abhängig von der rechtzeitigen Zulieferung von extern und auch von der Qualität der von extern gelieferten Beistellungen. Späte oder mangelhafte Beistellungen führen praktisch immer zu Terminverzug, Qualitätsmängeln und damit letztlich auch zu Budgetüberschreitungen.

290

10 Best-Practice-Empfehlungen für die Auswahl von QSM

• Abhängigkeit von Gesetzen, Richtlinien und Normen: Bei bestimmten Anwendungsgebieten existieren konkrete Gesetze, Richtlinien oder Normen, die eingehalten werden müssen. Bei Nicht-Einhaltung kann dies zu Problemen (Verzögerungen, Nachbesserungen) bei der Projektabnahme führen. Gerade bei sicherheitskritischen Produkten muss die Prozessqualität bestimmten Normen entsprechen (z.B. IEC 61508). Entspricht die Prozessqualität nicht den geforderten Normen, wird das Produkt z.B. nicht vom TÜV freigegeben. 10.5.2 Zuordnungen

Tabelle 10.13, 10.14 und 10.15 bilden die Zuordnungsmatrizen für die Probleme im Projektmanagement und in den analytischen, konstruktiven und organisatorischen QS-Maßnahmen ab.

Review und Inspektion

Schreibtischtest

Walkthrough

Metriken

Simulation zu Testzwecken

2

1

Akzeptanztest

Abnahmetest

Black-Box Test

Datenflussanalyse Codeanalyse

Inbetriebnahmetest FMEA

In-circuit-Emulation

3 1 2

Modultest

Integrationstest

Regressionstest

Stresstest

White-Box Test

Komplexitäts- und Timing-Analyse

2

2 2 3 3 3 3 2 3 3 3 3 3 3 3 2 2 3 3 3

3 2 3 3 3 3 3 3 3

Instrumentierung

3 3

Abhängigkeit von Gesetzen, Richtlinien und Normen

Abhängigkeit von Komp.lieferanten und Entw.dienstleistern

Mangelhafte Quantifizierbarkeit des Entwicklungsstandes

Fehlerhafte Aufwandsschätzung und Kalkulation

Mangelhafte Dokumentation der Entwicklung während des Projekts

Späte Erstellung der Produkt-Dokumentation

Späte Erkennung von Fehlern

Mangelnde Aktualität von Entwicklungsdokumenten

Späte Abstimmung mit Marketing/Vertrieb

Späte Abstimmung mit der Produktion

Keine klaren Kriterien für Meilensteine

Entscheidungen nicht nachvollziehbar

Unklare Verantwortlichkeiten

Ressourcenmangel

Abstimmungs- und Kommunikationsprobleme

Teamzusammensetzung

Unerfahrene Mitarbeiter

10.5 Projektmanagement 291

Tabelle 10.13. Projektmanagement – Analytische QSM

Wiederverw. von Projektergebnissen

Code-Generierung

Anforderungsanalyse

SW-Architekturentwurf

Endliche Automaten

Petrinetze

Sequenzdiagramme SA/SD

UML SDL

Sim. zur Anf.- bzw. Entw.absicherung Prototyping

Anforderungsverfolgung

3 2 2 2 2 2 2 3 2

Defensive Programmierung

2 1 2

1

1

3 1 2

2

3 3 3 2 2 2 2 2 2 3 2 2 3 2 2

3 3 3 3 3 3 2 2 2 2 2 2

Abhängigkeit von Gesetzen, Richtlinien und Normen

Abhängigkeit von Komp.lieferanten und Entw.dienstleistern

Mangelhafte Quantifizierbarkeit des Entwicklungsstandes

Fehlerhafte Aufwandsschätzung und Kalkulation

Mangelhafte Dokumentation der Entwicklung während des Projekts

Späte Erstellung der Produkt-Dokumentation

Späte Erkennung von Fehlern

Mangelnde Aktualität von Entwicklungsdokumenten

Späte Abstimmung mit Marketing/Vertrieb

Späte Abstimmung mit der Produktion

Keine klaren Kriterien für Meilensteine

Entscheidungen nicht nachvollziehbar

Unklare Verantwortlichkeiten

Ressourcenmangel

Abstimmungs- und Kommunikationsprobleme

Teamzusammensetzung

Unerfahrene Mitarbeiter

292 10 Best-Practice-Empfehlungen für die Auswahl von QSM

Tabelle 10.14. Projektmanagement – Konstruktive QSM

10.5 Projektmanagement

293

Abhängigkeit von Komp.lieferanten und Entw.dienstleistern

Abhängigkeit von Gesetzen, Richtlinien und Normen

Mangelhafte Quantifizierbarkeit des Entwicklungsstandes

Fehlerhafte Aufwandsschätzung und Kalkulation

Späte Erstellung der Produkt-Dokumentation

Späte Erkennung von Fehlern

Mangelnde Aktualität von Entwicklungsdokumenten

Späte Abstimmung mit Marketing/Vertrieb

Späte Abstimmung mit der Produktion

Keine klaren Kriterien für Meilensteine

Entscheidungen nicht nachvollziehbar

Unklare Verantwortlichkeiten

2

Ressourcenmangel

2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 1 2 1 1 2 1 1 2 2 2 2 1 1 1 1 1 2 1 3 3 1 2 3 3 3 3 3 2 2 3 1 1 3 1 1 1 3 2 2 2 2 3 2 2 3 2 2 2 3 2 2 2 2 1 1 2 3 2 2 2 2 2 1 2 1 3 3 1 1 2 2 3 3 1 2 1 3 1 3 3 1 1 2 3 2 2 1 1 3 1 2 3

Abstimmungs- und Kommunikationsprobleme

3

Teamzusammensetzung

2 1 2 1 3 1 3 3 3 3 3 3 2 2 3 3

Unerfahrene Mitarbeiter Festlegung des Engineering-Modells

Mangelhafte Dokumentation der Entwicklung während des Projekts

Tabelle 10.15. Projektmanagement – Organisatorische QSM

Vers.- und Konfig.management Risikomanagement Testabdeckungsmatrix Unabhängige Testgr. (-pers.) Phasen- und Projektreview Defect Management, Bug Tracking Änderungsmanagement Fehlerdatenbank Checklisten Designrichtlinien Programmierrichtlinien Dokumentationsrichtlinien Dokumentenvorlagen Dokumentationssystem Dokumentation von Entscheidungen Glossar/Terminologie QS-Handbuch QS-Handbuch (projektspezifisch) QS-planung für den Entw.prozess Q-Berichterstattung Verfahrensaudit

Anhang

QS-Maßnahmenkatalog

Im Folgenden wird der Maßnahmenkatalog mit den einzelnen QSMDatenblättern dargestellt. Dazu werden die Maßnahmen in analytische, konstruktive und organisatorische gegliedert.

Analytische QS-Maßnahmen Folgende analytische QS-Maßnahmen werden in diesem Kapitel in Form von QSM-Datenblättern behandelt: • • • • • • • • • • • • • • • • • • • •

Abnahmetest Akzeptanztest Black-Box Test Codeanalyse Datenflussanalyse FMEA Inbetriebnahmetest (für eine mechatronische Komponente) In-circuit-Emulation Review und Inspektion Schreibtischtest Walkthrough Modultest Integrationstest Stresstest Regressionstest White-Box Test Instrumentierung Komplexitäts- und Timing-Analyse Metriken Simulation zu Testzwecken

298

Anhang QS-Maßnahmenkatalog

Tabelle 1. Akzeptanztest Bezeichnung

Akzeptanztest

Synonyme Querverweise Kurzbeschreibung

Abnahmetest Aus dem Akzeptanztest folgt keine formale/vertragliche Abnahme. Es wird geprüft, ob der Kunde das Produkt akzeptiert (Benutzbarkeit, fehlende Anforderungen, Leistungsfähigkeit, Funktionalität etc.). In Anlehnung an ein Lastenheft wird gegen die (subjektive) Erwartungshaltung des Kunden getestet. Hoch Analytisch Rückversicherung der Erwartungshaltung des Kunden - System-Abnahmetest - (IT-Integrationstest) - (SW-Integrationstest) (Empfehlung: frühzeitiges Absichern der Erwartungen) Einsatz unter realen Betriebsbedingungen - Gefahr von sich ständig ändernden Kundenanforderungen - Aufbau der Testumgebung evtl. schwierig Vorzeigbares (Teil-)Produkt vorhanden Reale Testumgebung und/oder Simulationsumgebung - Funktionale Fehler - Fehler im Zeitverhalten - Zuverlässigkeit - Robustheit (Schwerpunkt bei nichtfunktionalen Anforderungen) [2, 17, 63]

Relevanz Klasse Ziel Entwicklungsphase

Vorteile Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug

Referenz

Analytische QS-Maßnahmen

299

Tabelle 2. Abnahmetest Bezeichnung

Abnahmetest

Synonyme Querverweise Kurzbeschreibung

Kann Akzeptanztest beinhalten Ein Abnahmetest ist ein Test unter realen Einsatzbedingungen beim Auftraggeber/Kunden, der das Produkt formal/vertraglich abnehmen muss. Eine Abnahme erfolgt, wenn keine oder tolerierbare Fehler bzw. Fehler, die nachgebessert werden können, auftreten. Getestet wird gegen das Lastenheft. Hoch Analytisch - Abnahme durch den Kunden/Auftraggeber - Kunde/Auftraggeber will feststellen, ob vertraglich vereinbarte Anforderungen an Produkt (Funktion, Leistung, Qualität) erfüllt sind - System-Abnahmetest - (IT- Integrationstest) - (SW- Integrationstest) - Einsatz unter realen Betriebsbedingungen - Formale Abnahme durch den Kunden - Fehlerkorrektur beim Kunden nur sehr eingeschränkt möglich, weil Test beim Kunden stattfindet - Aufbau der Testumgebung teilweise schwierig Lastenheft vorhanden Reale Testumgebung Funktionale und nichtfunktionale Fehler (Fehler im Zeitverhalten, Zuverlässigkeit, Robustheit, etc.) [2, 17, 63]

Relevanz Klasse Ziel

Entwicklungsphase

Vorteile Nachteile

Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

300

Anhang QS-Maßnahmenkatalog

Tabelle 3. Black-Box Test Bezeichnung

Black-Box Test

Synonyme Querverweise Kurzbeschreibung

White-Box Test Unter Black-Box Test wird ein Test verstanden, bei dem das Testobjekt gegen die Spezifikation getestet wird, ohne einen Einblick in die innere Struktur des Prüflings zu haben (Black-Box). Da in der Praxis ein Funktionstest meist in Form eines Black-Box Test durchgeführt wird, werden die Begriffe „Black-Box Test“ und „Funktionstest“ oft gleichgesetzt Hoch Analytisch Überprüfung der spezifizierten Funktionalität auf Fehler und Vollständigkeit Alle Testphasen - Konzentration auf spezifizierte Funktionalität - Tester benötigt keine Kenntnisse über innere Struktur des Prüflings - Haupt-Schwierigkeit beim Black-Box Test: Auswahl von Testfällen und Testdaten, so dass eine möglichst hohe Fehlerdetektionswahrscheinlichkeit erreicht wird. - Ursachen von entdeckten Fehlern durch den Black-Box Test i.d.R. nicht auffindbar - Nicht spezifizierte Funktionalitäten nicht entdeckbar - Nachweis der Fehlerfreiheit nicht möglich Gut strukturierte Spezifikation Ggf. Testwerkzeuge - Funktionale Fehler - Unvollständigkeiten [2, 35, 51, 36]

Relevanz Klasse Ziel Entwicklungsphase Vorteile

Nachteile

Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

Analytische QS-Maßnahmen

301

Tabelle 4. Codeanalyse Bezeichnung

Codeanalyse

Synonyme Querverweise Kurzbeschreibung

Statische Analyse, Kontrollflussanalyse Datenflussanalyse Bei der Codeanalyse wird die statische Struktur des Quellcodes geprüft und dokumentiert. Gering Analytisch - Erkennung von Fehlern und formalen Verstößen gegen vorgegebene Konventionen. - Dokumentation der statischen Programmstruktur und Erstellung von Statistiken. - Verbesserung der Wartbarkeit von Quellcode - Identifikation von fehlerkritischen Programmteilen SW-Implementierung - Lieferung von Anhaltspunkten bzgl. Zuverlässigkeit und Komplexität - Automatisierbar Hoher Aufwand, wenn nicht automatisierbar Existenz von Richtlinien/Konventionen Analysewerkzeuge sinnvoll - Verstöße gegen Konventionen - Verstöße gegen Syntaxregeln - Statische Semantikfehler [17, 36, 63]

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug

Referenz

302

Anhang QS-Maßnahmenkatalog

Tabelle 5. Datenflussanalyse Bezeichnung

Datenflussanalyse

Synonyme Querverweise Kurzbeschreibung

Codeanalyse; Programmanalyse Die Datenflussanalyse analysiert den Wertefluss in einem Programm, d.h. es werden die Werte von Variablen bezüglich des Programmablaufs untersucht. Gering Analytisch Aufdecken von Datenfluss-Anomalien durch Analyse von Programmpfaden und Überprüfung auf Einhaltung sinnvoller Datenflusssequenzen SW-Implementierung Direkte Fehlerlokalisation Beschränkung auf schmalen Fehlerbereich Sinnvollerweise mit Werkzeugunterstützung - Entdecken von Wertzuweisungen an falsche Variablen - Entdecken von Anweisungen an unkorrekter Stelle - Entdecken von fehlenden Anweisungen [2, 17, 63]

Relevanz Klasse Ziel

Entwicklungsphase Vorteile Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug

Referenz

Analytische QS-Maßnahmen

303

Tabelle 6. FMEA Bezeichnung

FMEA (Fehlermöglichkeits- und Einflussanalyse)

Synonyme

Failure Modes and Effects Analysis; Failure Mode, Effects and Criticality Analysis FMEA ist die Analyse eines Systemdesigns hinsichtlich aller möglichen Fehlerquellen und der Auswirkungen dieser Fehler auf das Verhalten und die Sicherheit des Systems. Mittel (in sicherheitskritischen Bereichen -> Hoch) Analytisch - Ermittlung von Ursachen, Wirkungen und Eintrittswahrscheinlichkeiten möglicher Fehler - Gewinnung von Risikoabschätzungen Systemebene (üblicherweise in System-Entwurf)

Querverweise Kurzbeschreibung

Relevanz Klasse Ziel

Entwicklungsphase Vorteile Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

- Identifikation kritischer Komponenten - Wissenssicherung über Fehler und Fehlerursachen Hoher Aufwand Bedarf eines erfahrenen (interdisziplinären) Teams Vermeidung eines risikoreichen Entwurfs [35, 36]

304

Anhang QS-Maßnahmenkatalog

Tabelle 7. Inbetriebnahmetest (für eine mechatronische Komponente) Bezeichnung

Inbetriebnahmetest (für eine mechatronische Komponente)

Synonyme Querverweise Kurzbeschreibung

Die Installationsfähigkeit wird in realen technischen Umgebungen anhand relevanter Betriebsszenarien getestet. Hoch Analytisch - Überprüfung und Sicherstellung einer reibungsfreien Inbetriebnahme in den forcierten Einsatzgebieten - Auswahl der richtigen Installationsparameter und HWKonfigurationen - Überprüfung der Vollständigkeit und Korrektheit der Installationsunterlagen incl. der Dokumentation - System-Abnahmetest - (IT-Integrationstest) - (SW-Integrationstest) - Reduzierung der Serviceeinsätze - Reduzierung des Aufwandes zur Inbetriebnahme - Reduzierung des Adaptionsaufwandes im Einzelfall - Annäherung an eine Plug & Play Fähigkeit - U.U. großer Aufwand zur Bereitstellung der realen Umgebung - Umfangreiches Anwendungs-Know-how notwendig Einsatzgebiete/ Zielgruppen spezifiziert Existenz der benötigten Hard- und Software - Robustheit bzgl. der Installationsumgebung - Unverträglichkeiten mit der Umgebung - Fehler in den Installationsunterlagen -

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile

Voraussetzungen Arbeitsmittel Fehlerbezug

Referenz

Analytische QS-Maßnahmen

305

Tabelle 8. In-circuit-Emulation Bezeichnung

In-circuit-Emulation

Synonyme Querverweise Kurzbeschreibung

White Box Test, Instrumentierung Ersetzen des Mikroprozessors durch eine spezielle Hardware (In-circuit-Emulator) zur detaillierten Analyse der internen Programmabläufe unter Echtzeitbedingungen (Echtzeitmonitoring). Hoch Analytisch - Analyse des Echtzeitverhaltens der SW-Applikation - Einblick in die internen Operationen und zeitlichen Programmabläufe - SW-Komponententest - SW-Integration und -Test - IT-Integration und -Test Im Gegensatz zur manuellen Instrumentierung kein negativer Einfluss auf das Zeitverhalten. Somit Analyse unter Echtzeitbedingungen möglich. - Hoher Aufwand (Anschaffungspreis und Beherrschung) - Verhalten von In-circuit-Emulator und Zielhardware ggf. nicht identisch Verfügbarkeit für die Zielhardware In-circuit-Emulator - Echtzeitfehler - Kontroll- und Datenflussfehler [8]

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile

Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

306

Anhang QS-Maßnahmenkatalog

Tabelle 9. Review und Inspektion Bezeichnung

Review und Inspektion

Synonyme Querverweise Kurzbeschreibung

Beim Review wird ein Dokument durch eine Gruppe von Personen gemeinsam geprüft. Der Personenkreis besteht typischerweise aus einem Moderator, dem Autor, einem Protokollanten und Gutachtern. Identifizierte Schwächen werden durch den Autor behoben. Review und Inspektion unterscheiden sich im Formalisierungsgrad. Hoch Analytisch - Identifikation von Mängeln, Fehlern, Inkonsistenzen, Unvollständigkeiten - Identifikation von Verstößen gegen Vorgaben, Richtlinien, Standards anhand von Referenzunterlagen In allen Phasen (hauptsächlich nach Fertigstellung von Entwicklungsdokumenten bzw. vor deren Freigaben) - Beliebige Dokumente prüfbar (z.B. auch Programm-Code) - Einfache Durchführbarkeit, da keine technischen Voraussetzungen geschaffen werden müssen => oft kostengünstig - Bereits in frühen Phasen des Entwicklungsprozesses einsetzbar - Verbreitung von Wissen über ein Dokument Rein manuelle Methode => nicht automatisierbar - Planung und Strukturierung des Review-Verfahrens - Große Erfahrung der Gutachter notwendig - Prüfobjekt - Referenzunterlagen (Spezifikation, Vorgaben, Richtlinien, Standards usw.) - Review-Protokoll - Protokollvorlagen - Checklisten Breites Fehlerspektrum (abhängig von den betrachteten Dokumentarten) [2, 8, 26, 35, 36 51, 63, 68]

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile Voraussetzungen Arbeitsmittel

Fehlerbezug Referenz

Analytische QS-Maßnahmen

307

Tabelle 10. Schreibtischtest Bezeichnung

Schreibtischtest

Synonyme Querverweise Kurzbeschreibung

Ein oder mehrere Prüfer erhalten ein Dokument vom Autor, prüfen es kritisch und geben es mit Anmerkungen zurück. Die Korrektur von entdeckten Fehlern erfolgt durch den Autor. Schreibtischtests sind (eher) informeller Natur. Hoch Analytisch - Optimierung des Dokuments inklusive Identifikation von Fehlern - Überprüfung von Dokumenten auf Vollständigkeit und Konsistenz Alle

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug

Referenz

- Beliebige Dokumente prüfbar (z.B. auch Programm-Code) - Einfache Durchführbarkeit, da keine technischen Voraussetzungen geschaffen werden müssen => oft kostengünstig - Bereits in frühen Phasen des Entwicklungsprozesses einsetzbar - Verbreitung von Wissen über ein Dokument - Kein organisatorischer Aufwand - Rein manuelle Methode => nicht automatisierbar - Ressourcen in der Regel nicht planbar - Defekte - Unklarheiten - Unvollständigkeiten [8]

308

Anhang QS-Maßnahmenkatalog

Tabelle 11. Walktrough Bezeichnung

Walkthrough

Synonyme Querverweise Kurzbeschreibung

Manuelle, informale Prüfmethode. Der Autor präsentiert das Dokument in einer Sitzung den Gutachtern. Die Gutachter stellen spontane Fragen. Eine Überarbeitung des Prüfobjektes nach einem Walkthrough erfolgt durch den Autor. Im Gegensatz zum Review agiert der Autor selbst als Moderator. Hoch Analytisch - Identifikation von Fehlern, Defekten, Unklarheiten und Problemen in schriftlichen Dokumenten - Überprüfung von Dokumenten auf Vollständigkeit und Konsistenz Alle

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile

Voraussetzungen Arbeitsmittel Fehlerbezug

Referenz

- Geringer Aufwand, schnell und kurzfristig durchführbar - Verbreitung von Wissen über ein Dokument - Endnutzer / Kunden optional miteinbeziehbar - „Positve“ Darstellung durch den Autor kann Fehlererkennung erschweren/verhindern - Korrekturen im Ermessen des Autors Konstruktives Arbeitsklima erforderlich - Defekte - Unklarheiten - Unvollständigkeiten [2, 8, 35, 36, 51, 63, 68]

Analytische QS-Maßnahmen

309

Tabelle 12. Modultest Bezeichnung

Modultest

Synonyme Querverweise Kurzbeschreibung

Komponententest Im Modultest werden Operationen und deren Zusammenspiel innerhalb eines Moduls unabhängig von der Systemumgebung getestet. Ausführung sind sowohl als White-Box Test als auch als Black-Box Test möglich. Im Gegensatz zur klassischen Software-Technik wird hier unter Modul eine Komponente verstanden, die sowohl aus Software als auch aus Hardware bestehen kann. Hoch Analytisch Prüfung der Modulfunktionen und der Modul-Schnittstellen gegen die Spezifikation => Auffinden von Fehlverhalten Komponententest

Relevanz Klasse Ziel Entwicklungsphase Vorteile

Nachteile

Voraussetzungen Arbeitsmittel Fehlerbezug

Referenz

- Umfassende Tests von abgegrenzten Teilsystemen Î hohe Testtiefe - Module auf einer Ebene weitgehend unabhängig voneinander testbar - Frühzeitige Fehlererkennung - Bessere und schnellere Fehlerlokalisierung - Möglicherweise aufwändige Erstellung der Testumgebung notwendig - Aussagen über beispielsweise Zeitverhalten problematisch aufgrund nicht vollständig vorhandener Systemumgebung Modulspezifikation - Testspezifikation - Ggf. Testwerkzeuge - Berechnungsfehler - Funktionalität - Verhalten - Schnittstellen - Ggf. Performance (Fehlerbezug abhängig vom verwendeten Testverfahren (Black Box / White Box)) [17, 63]

310

Anhang QS-Maßnahmenkatalog

Tabelle 13. Integrationstest Bezeichnung

Integrationstest

Synonyme Querverweise Kurzbeschreibung

Im Integrationstest wird das Zusammenspiel von Systemkomponenten getestet. Getestete Komponenten werden schrittweise hinzugefügt bis das System komplett integriert ist. Eine inkrementelle Vorgehensweise (TopDown, Bottom-Up, Hardest-First usw.) ist der nichtinkrementellen Vorgehensweise (Big Bang) vorzuziehen. Hoch Analytisch Test der Interaktionen zwischen den Komponenten und den Eigenschaften des Gesamtsystems (Funktionalität, Verhalten, Schnittstellen, Performance, Synchronisation) Integrationsphasen

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile Voraussetzungen

Arbeitsmittel Fehlerbezug Referenz

Bei inkrementeller Vorgehensweise frühzeitige Fehlererkennung und bessere Fehlerlokalisierung als bei sofortigem Systemtest möglich Möglicherweise aufwändige Erstellung der Testumgebung notwendig - Jede zu integrierende Systemkomponente für sich bereits getestet (Modultest) - Integrationsprozess vorher bereits geplant Testspezifikation Fehler im Zusammenspiel (insbesondere Performance, Zeitverhalten, Synchronisation) [2, 8, 63, 68]

Analytische QS-Maßnahmen

311

Tabelle 14. Stresstest Bezeichnung

Stresstest

Synonyme Querverweise Kurzbeschreibung

Es wird die Reaktion eines Systems auf außergewöhnlich hohe Belastungen von Systemressourcen (z.B. Rechenzeit, Stack, Speicher) getestet. Mittel Analytisch - Identifikation von Engpässen („Bottlenecks“) im System - Prüfung der zugesagten Robustheit IT-Integration und -Test; System-Integration und -Test

Relevanz Klasse Ziel Entwicklungsphase Vorteile Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

Ermittlung der tatsächlichen Robustheit Erstellung des Testsystems evtl. sehr aufwändig - Definition des Toleranzbereichs - Kenntnis des Einsatzumfelds - Reales System und/oder Simulator - Testspezifikation Designfehler (z.B. Stackfehler, Bufferüberlauf, Interruptfehler) [2, 36, 63, 68]

312

Anhang QS-Maßnahmenkatalog

Tabelle 15. Regressionstest Bezeichnung

Regressionstest

Synonyme Querverweise Kurzbeschreibung

Der Regressionstest wird zum Test von funktionalen Erweiterungen bzw. Fehlerbehebungsmaßnahmen eingesetzt. Beim Regressionstest werden Testfälle mehrmals durch Testautomaten ausgeführt. Dadurch kann überprüft werden, ob die aufgetretenen Fehler korrekt behoben wurden und ob bereits abgetestete Funktionen nach Änderungen/ Erweiterungen weiterhin fehlerfrei arbeiten (Seiteneffekte). Hoch Analytisch Überprüfung von Änderungen auf Korrektheit und Freiheit von Seiteneffekten Alle Testphasen

Relevanz Klasse Ziel Entwicklungsphase Vorteile

Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

Effizientes Erreichen einer hohen Testabdeckung auch bei Änderungen durch Wiederverwendung von Testplänen und Testfällen Möglicherweise hoher Aufwand beim Testen (durch Automatisierung abmilderbar) Ablegen von Testplänen und Testfällen in wiederverwendbarer Form - Testspezifikation - Testautomat wünschenswert Breites Fehlerspektrum (konkrete Fehlerarten von Testphase und -verfahren abhängig) [2, 17, 51, 63]

Analytische QS-Maßnahmen

313

Tabelle 16. White-Box Test Bezeichnung

White-Box Test

Synonyme Querverweise Kurzbeschreibung

Strukturtest In-circuit-Emulation Beim White-Box Test wird ein Prüfling unter Ausnutzung der Kenntnisse des internen Aufbaus und der Beobachtung interner Prozessvariablen gegen die Spezifikation getestet. Dies geschieht beispielsweise kontroll- oder datenflussorientiert. Gering Analytisch Verifikation der korrekten Implementierung des SWDesigns Komponententest

Relevanz Klasse Ziel Entwicklungsphase Vorteile

Nachteile

Voraussetzungen Arbeitsmittel

Fehlerbezug Referenz

- Entdecken von Fehlerursachen - Besonders oft durchlaufene Programmteile identifizierbar und somit gezielt optimierbar (ebenso „toter Code“) - Erkennen von nicht spezifizierten, zusätzlichen Funktionen - Für bestimmte Analysen Instrumentierung des Codes erforderlich - Zeitintensiv - Detailkenntnisse des Testers über innere Struktur des Prüflings nötig Spezifikation, ggf. Feindesign - In-circuit-Emulator - Codedebugger - Code-Analyzer Codierfehler [2, 51, 63]

314

Anhang QS-Maßnahmenkatalog

Tabelle 17. Instrumentierung Bezeichnung

Instrumentierung

Synonyme Querverweise Kurzbeschreibung

In-circuit-Emulation Zur Analyse des Kontroll- und Datenflusses wird zusätzlicher Code (Zähler und Ausgaben) eingefügt. Hoch Analytisch - Fehlerlokalisation - Prüfen des Programmablaufs SW-Implementierung; SW-Komponententest

Relevanz Klasse Ziel Entwicklungsphase Vorteile Nachteile

Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

Schnelle, einfache Fehlerlokalisierung - Verhalten des Prüflings (insbesondere das Zeitverhalten) wird beeinflusst - Falls von Hand ausgeführt, oft unsystematisch und daher ggf. ineffektiv - Manuelles Einfügen und Löschen der Instrumentierung aufwendig und fehleranfällig Codierfehler [2]

Analytische QS-Maßnahmen

315

Tabelle 18. Komplexitäts- und Timinganalyse Bezeichnung

Komplexitäts- und Timing-Analyse

Synonyme Querverweise Kurzbeschreibung

In der Designphase findet eine theoretische Ermittlung des Systemzeitverhaltens mit Hilfe der Komplexitäts-Analyse statt. Mit Hilfe der Timing-Analyse findet eine Messung des Zeitverhaltens direkt anhand des Systemverhaltens oder, falls erforderlich, mittels Instrumentierung oder Profiling statt. Mittel Analytisch Sicherstellung der Anforderungserfüllung bzgl. des Systemzeitverhaltens - Komplexitäts-Analyse: Entwurfsphasen - Timing-Analyse: IT-Integration und -Test Ermittlung des realen Zeitverhaltens - Ggf. Instrumentierung zur Zeitmessung erforderlich - Identifikation des „worst case“ in der Praxis oft nicht möglich - Vollständiges Verständnis der zeitlichen Zusammenhänge des Systems bei hoher Komplexität selten zu gewinnen Systemspezifikation - Emulatoren - Messgeräte (z.B. Oszilloskop) - Designfehler - Zu knappe Hardwareressourcen - Codierfehler [35, 68]

Relevanz Klasse Ziel Entwicklungsphase Vorteile Nachteile

Voraussetzungen Arbeitsmittel Fehlerbezug

Referenz

316

Anhang QS-Maßnahmenkatalog

Tabelle 19. Metriken Bezeichnung

Metriken

Synonyme Querverweise Kurzbeschreibung

Phasen- und Projektreview Es handelt sich um die Definition, Erhebung und Interpretation von Maßzahlen zur Beschreibung von Qualitätseigenschaften des Produktes oder von Prozessen. Gering Analytisch - Nachweis der Wirksamkeit von Optimierungsmaßnahmen bezüglich Produkt- und Prozessqualität - Gewinnung von Verständnis über die Wirkung von QS-Maßnahmen Alle

Relevanz Klasse Ziel

Entwicklungsphase Vorteile Nachteile

Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

Gewinnung von Erfahrungswerten anhand derer Entwicklungsprozesse gesteuert werden können - Auswahl aussagekräftiger Metriken schwierig - Erfassung evtl. sehr aufwändig - Evtl. Auftreten von psychologischen Hürden bei der Erfassung Produkt- bzw. Prozessverständnis unterstützende Werkzeuge (PC Lint, Krakatau etc.) - z.B. zu hohe Komplexität im Code - schlechte Wartbarkeit [2]

Analytische QS-Maßnahmen

317

Tabelle 20. Simulation zu Testzwecken Bezeichnung

Simulation zu Testzwecken

Synonyme Querverweise Kurzbeschreibung

Zu Testzwecken werden die Komponenten (SW, HW und Mechanik) und/oder die Systemumgebung nachgebildet. Hoch Analytisch Frühzeitiges Bereitstellen einer Testumgebung ohne reale HW - SW-Implementierung - Alle Testphasen - Zeiteinsparung durch Parallelisierung von Soft- und Hardwareentwicklung - Modell in der Regel besser manipulierbar als die Realität - Hohe Testbreite und Testtiefe - Modell-Validierung schwierig - Hoher Aufwand/ Kosten für die Modellbildung Spezielles Know-How (Modellierung/Simulation) Modellierungs- und Simulationswerkzeuge - Funktionsfehler - Robustheit [7]

Relevanz Klasse Ziel Entwicklungsphase Vorteile

Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

318

Anhang QS-Maßnahmenkatalog

Konstruktive QS-Maßnahmen Folgende konstruktive QS-Maßnahmen werden in diesem Kapitel in Form von QSM-Datenblättern behandelt: • • • • • • • • • • • • • •

Anforderungsanalyse Anforderungsverfolgung SW-Architekturentwurf Endliche Automaten Petrinetze SA/SD Sequenzdiagramme SDL (Specification and Description Language) UML Prototyping Simulation zur Anforderungs- bzw. Entwurfsabsicherung Wiederverwendung von Projektergebnissen Defensive Programmierung Code-Generierung

Konstruktive QS-Maßnahmen

319

Tabelle 21. Anforderungsanalyse Bezeichnung

Anforderungsanalyse

Synonyme Querverweise Kurzbeschreibung

Requirements Analysis Änderungsmanagement Die Anforderungsanalyse ist eine systematische Vorgehensweise, um die Anforderungen an das zu realisierende System aus Sicht des Kunden (Lastenheft) zu ermitteln und schrittweise zu verfeinern. In der Regel handelt es sich um einen iterativen Prozess, bei dem beispielsweise Kunden, Produktmanagement, Marketing und Entwicklung beteiligt sind. Hoch Konstruktiv Erstellung einer vollständigen, konsistenten, eindeutigen Definition der Produktanforderungen System-Anforderungsanalyse; IT-Anforderungsanalyse

Relevanz Klasse Ziel Entwicklungsphase Vorteile

Nachteile

Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

- Vollständige, konsistente, eindeutige Anforderungen als Grundlage für ein einheitliches Verständnis zwischen allen Beteiligten, Aufwandsschätzungen und Projektplanung, frühzeitige Definition von Abnahmekriterien - Durch sorgfältige Anforderungserfassung deutlich geringere Fehlerkosten aufgrund frühzeitiger Erkennung von Definitionslücken - Vollständigkeit, Konsistenz und Eindeutigkeit schwer überprüfbar - Nicht zu unterschätzender zeitlicher Aufwand Informationen vom Anwender und Auftraggeber bzw. Marktanalysen Formulare für die Anforderungserfassung Mangelhafte Anforderungen [3]

320

Anhang QS-Maßnahmenkatalog

Tabelle 22. Anforderungsverfolgung Bezeichnung

Anforderungsverfolgung

Synonyme Querverweise Kurzbeschreibung

Traceability(-analysis), Requirements Traceability Änderungsmanagement Anforderungsverfolgung ist die Zuordnung von Projektergebnissen zu Anforderungen (z.B. in Form einer Matrixdarstellung). Zweck ist die Überprüfung, ob alle Anforderungen vollständig berücksichtigt worden sind. Unter Anforderungen werden in diesem Zusammenhang sowohl die originären Anwenderanforderungen als auch die entwickelten Detailkonzepte sowie die Einhaltung von Richtlinien und Normen verstanden. Hoch Konstruktiv Überprüfung der vollständigen Umsetzung der Anforderungen in den einzelnen Entwicklungsphasen Alle

Relevanz Klasse Ziel Entwicklungsphase Vorteile

Nachteile

Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

- Überblick über den Projektstand hinsichtlich der Umsetzung der Anforderungen - Erleichtertes Änderungsmanagement - Höhere Rechtssicherheit (z.B. food and drug administration (FDA), sicherheitskritischer Bereich) - Konsistente und durchgängige Anforderungsverfolgung aufwändig - Schwierige Anwendung auf nicht-funktionale Anforderungen wie Zuverlässigkeit, Wartbarkeit usw. - Strukturierte Anforderungen - Modularer Entwurf Dokumenten- oder Rechnergestützt Identifikation von nicht umgesetzten Anforderungen [35]

Konstruktive QS-Maßnahmen

321

Tabelle 23. SW-Architekturentwurf Bezeichnung

SW-Architekturentwurf

Synonyme Querverweise Kurzbeschreibung

Ein SW-Architekturentwurf ist die Zergliederung des Gesamtsystems in Komponenten. Beschrieben wird sowohl die statische Struktur als auch das dynamische Verhalten des Gesamtsystems. Hoch Konstruktiv - Konzeptbildung - Systemstrukturierung (Dekomposition) und Modularisierung SW-Analyse & Entwurf

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile Voraussetzungen Arbeitsmittel

Fehlerbezug Referenz

- Verbesserung der Wiederverwendbarkeit - Leichtere Wartbarkeit und Änderbarkeit - Leichtere Portierbarkeit - Vertiefung des Systemverständnisses bei allen Beteiligten Systemverständnis und Anwendungserfahrung des Erstellers nötig - Kreativitätstechniken - Idealerweise CASE-tool - Einsatz von Entwurfsmustern Konzeptionelle Fehler -

322

Anhang QS-Maßnahmenkatalog

Tabelle 24. Endliche Automaten Bezeichnung

Endliche Automaten

Synonyme Querverweise Kurzbeschreibung

Zustandsautomaten, Statecharts Es handelt sich um eine dynamische Verhaltensbeschreibung für zeitdiskrete Vorgänge, die aus einer Menge von Zuständen und Zustandsübergängen bestehen. Zustandsübergänge werden durch Ereignisse (events) bewirkt. Hoch Konstruktiv - Modellierung des dynamischen Verhaltens auf Systemebene - Modellierung des dynamischen Verhaltens von (Sub-) Modulen Alle konstruktiven Phasen

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

- Kompakte, eindeutige Beschreibung (ggf. hierarchisch) - Etablierte Methode zur Beschreibung von dynamischem Verhalten - Gute Basis für Simulation und Code-Generierung Beschreibung komplexer paralleler Abläufe ist schwierig - Designtools - Codegenerator - Dynamische Fehler - Implementierungsfehler [17, 36]

Konstruktive QS-Maßnahmen

323

Tabelle 25. Petrinetze Bezeichnung

Petrinetze

Synonyme Querverweise Kurzbeschreibung

Ein Petrinetz ist eine graphische Beschreibung des dynamischen Verhaltens paralleler Systeme. Im Gegensatz zu endlichen Automaten wird bei Petrinetzen der Gesamtzustand betrachtet. Gering Konstruktiv - Modellierung relevanter Eigenschaften des Systemverhaltens - Entdeckung von Entwurfsfehlern (z.B. Verklemmungen) Entwurfsphasen

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

- Gute Beschreibungsmöglichkeit von Nebenläufigkeiten - Ablauffähiges Modell des Gesamtsystems - Durch (mathematische/automatische) Analyse eines Petrinetzes können Entwurfsfehler entdeckt werden - Theoretisch anspruchsvoll und daher wenig verbreitet - Analysen eines Petrinetzes evtl. sehr rechenintensiv Tool-Einsatz sinnvoll Dynamische Entwurfsfehler [36, 63, 68]

324

Anhang QS-Maßnahmenkatalog

Tabelle 26. SA/SD Bezeichnung

SA/SD

Synonyme Querverweise Kurzbeschreibung

Strukturierte Analyse (SA) und Strukturiertes Design (SD) sind funktionsorientierte Methoden für die Anforderungsanalyse und den Systementwurf. Ein System wird in hierarchisch strukturierte Funktionseinheiten (Prozesse, „bubbles“) zergliedert. Mittel Konstruktiv Beherrschung von Komplexität durch hierarchische Strukturierung der Aufgabenstellung Analyse- und Entwurfsphasen

Relevanz Klasse Ziel Entwicklungsphase Vorteile Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug

Referenz

- Relativ leicht erlernbar - Durchgängige Definition von Datenstrukturen Im Allgemeinen geringerer Wiederverwendungsgrad als bei OO-Methoden Tooleinsatz sinnvoll (um Konsistenz auf den verschiedenen Hierarchie-Ebenen zu erreichen) - Schnittstellenfehler - konzeptionelle Fehler - inkonsistente Verwendung von Datentypen [17, 36, 51]

Konstruktive QS-Maßnahmen

325

Tabelle 27. Sequenzdiagramme Bezeichnung

Sequenzdiagramme

Synonyme Querverweise Kurzbeschreibung

Message Sequence Charts (MSC) Sequenzdiagramme sind ein grafisches Darstellungsmittel, um den zeitlichen Ablauf der Kommunikation zwischen Objekten bzw. Prozessen darzustellen. Varianten von Sequenzdiagrammen sind in gebräuchlichen Beschreibungssprachen (z.B. UML) enthalten. Mittel Konstruktiv Darstellung zeitlicher Abläufe der Kommunikation zwischen Objekten und Prozessen Analyse- und Entwurfsphasen

Relevanz Klasse Ziel Entwicklungsphase Vorteile Nachteile

Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

Klare und übersichtliche Darstellung auch paralleler Abläufe - Darstellung von zeitlichen Abläufen mit Sequenzdiagrammen nicht vollständig, sondern nur exemplarisch - Modellierung von Fallunterscheidungen nur unübersichtlich und schwer darstellbar CASE-Tools sinnvoll, aber nicht zwingend notwendig Entwurfsfehler, Schnittstellenfehler [28]

326

Anhang QS-Maßnahmenkatalog

Tabelle 28. SDL (Specification and Description Language) Bezeichnung

SDL (Specification and Description Language)

Synonyme Querverweise Kurzbeschreibung

Die SDL ist eine Beschreibungssprache für Systeme, die aus kommunizierenden Prozessen bestehen. Diese können sowohl in grafischer als auch in textueller Form beschrieben werden. Ein Prozess ist dabei im Wesentlichen ein erweiterter endlicher Zustandsautomat, der mit anderen Automaten über Signale kommuniziert. Gering Konstruktiv Modellierung von Systemen, die aus miteinander kommunizierenden Prozessen bestehen System-Entwurf

Relevanz Klasse Ziel Entwicklungsphase Vorteile

Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

- Anerkannter Standard in gewissen Branchen, wie Telekommunikation - Unterstützung statischer wie auch dynamischer Aspekte CASE-Tools sinnvoll, aber nicht zwingend notwendig Entwurfsfehler [27]

Konstruktive QS-Maßnahmen

327

Tabelle 29. UML Bezeichnung

UML (Unified Modelling Language)

Synonyme Querverweise Kurzbeschreibung

Die UML ist seit Mitte der 90er Jahre der de-facto Standard für die Beschreibung von objektorientierten Analyseund Entwurfs-Modellen. Sie ist eine visuelle Sprache und stellt eine Sammlung verschiedener Diagrammtypen zur Modellierung verschiedener Aspekte zur Verfügung. Mittel Konstruktiv - Unterstützung bei der Konzeptbildung - Unterstützung eines schrittweisen und durchgängigen Vorgehens Vorrangig Analyse- und Entwurfsphasen

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile

Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

- De-facto Standard und dadurch weit verbreitet - anschauliche graphische Beschreibung (Modellierung) von statischen und dynamischen Aspekten - Objektorientierte Vorgehensweise im embedded Bereich (noch) nicht allgemein verbreitet - Bei Neueinführung ggf. hoher Einarbeitungsaufwand CASE-Tools sinnvoll, aber nicht zwingend notwendig Entwurfsfehler [28]

328

Anhang QS-Maßnahmenkatalog

Tabelle 30. Prototyping Bezeichnung

Prototyping

Synonyme Querverweise Kurzbeschreibung

Muster(-bau) Ein Prototyp ist ein experimentelles Muster eines Systems, einer Systemkomponente oder einer (Teil-)Funktion. Prototypen erfüllen nicht alle Anforderungen an Vollständigkeit, Zuverlässigkeit und Sicherheit. Hoch Konstruktiv - Klärung von Anforderungen - Demonstration und Validation von Entwürfen - Machbarkeitsnachweis Alle Phasen

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile

Voraussetzungen

Arbeitsmittel Fehlerbezug Referenz

- Frühzeitiger Nachweis von spezifischen Produkteigenschaften - Mit Hilfe von Prototypen unklare Anforderungen genauer fassen - Durch Präsentation von Prototypen beim Kunden/Endbenutzer Messen der Akzeptanz bereits in frühen Phasen - Relativ vollständige Prototypen teilweise entgegen ihrer Bestimmung in Verkehr gebracht - Nicht alle Eigenschaften des Prototypen auf das endgültige Produkt übertragbar Zweck des Prototypen geklärt (z.B. Demonstration, Eigenschaftsnachweis, Experimentieren, Weiterentwicklung) Kontextspezifischer Tooleinsatz Abhängig vom Zweck [2, 51, 63, 68]

Konstruktive QS-Maßnahmen

329

Tabelle 31. Simulation zur Anforderungs- bzw. Entwurfsabsicherung Bezeichnung

Simulation zur Anforderungs- bzw. Entwurfsabsicherung

Synonyme Querverweise Kurzbeschreibung

Es wird ein Modell des zu entwickelnden Systems entworfen, das in den zu untersuchenden Aspekten dem Zielsystem möglichst nahe kommt. Dieses Modell wird mit geeigneten Mitteln auf einem Rechner ablauffähig gemacht, um sein Verhalten unter verschiedenen Bedingungen zu beobachten. Gering Konstruktiv Erproben und Prüfen der Eigenschaften eines noch zu erstellenden Systems oder Teilsystems bereits in frühen Phasen Analyse- und Entwurfsphasen

Relevanz Klasse Ziel

Entwicklungsphase Vorteile Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

Frühzeitiger Nachweis von Eigenschaften Modellerstellung und -validierung schwierig Spezielles Know-How (Modellierung/Simulation) Modellierungs- und Simulationswerkzeuge Abhängig vom Zweck [17]

330

Anhang QS-Maßnahmenkatalog

Tabelle 32. Wiederverwendung von Projektergebnissen Bezeichnung

Wiederverwendung von Projektergebnissen

Synonyme Querverweise Kurzbeschreibung

Existierende Projektergebnisse (z.B. Dokumente, Programmcode) werden vollständig oder auszugsweise übernommen. Dabei werden sie auf ihre Eignung überprüft und ggf. angepasst. Wiederverwendung muss bereits bei der Ersterstellung eingeplant sein. Mittel Konstruktiv - Sicherung des Qualitätsstandards durch bereits bewährte Ergebnisse reduziert das Entwicklungsrisiko - Erhöhung der Produktivität, Verkürzung der Entwicklungszeiten - Reduzierung der Kosten Alle konstruktiven Phasen

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile

Voraussetzungen

Arbeitsmittel Fehlerbezug Referenz

- Reduzierung von Risiken bei der Implementierung durch Rückgriff auf abgesicherte SW-Module - Ermöglichung einer intensiven Qualitätssicherung bei der Ersterstellung aufgrund von Zeiteinsparung durch die Wiederverwendung - Aufwand für die Bereitstellung universeller Komponenten - Universelle Komponenten ineffizienter und komplexer (Schnittstellen oft breiter) - Falls Anpassungen erforderlich: Einarbeitungs- und Änderungsaufwand evtl. grösser als Aufwand für eine Neuimplementierung Organisation wiederzuverwendender Komponenten in einer Bibliothek (in einem separaten Entwicklungsprozess erstellt, gepflegt, dokumentiert und freigegeben) Codierfehler [2]

Konstruktive QS-Maßnahmen

331

Tabelle 33. Defensive Programming Bezeichnung

Defensive Programmierung

Synonyme Querverweise Kurzbeschreibung

Programmierrichtlinien Bei der defensiven Programmierung werden implizite Zusicherungen explizit geprüft und entsprechende Fehlerbehandlungen vorgesehen. Beispiele sind das Abfangen von Bereichsüberschreitungen bei Indizes oder das Prüfen von Vorbedingungen bei Funktionsaufrufen. Hoch bei sicherheitsrelevanten Systemen, ansonsten gering Konstruktiv Erhöhung der Robustheit von SW SW-Implementierung

Relevanz Klasse Ziel Entwicklungsphase Vorteile

Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

- Erhöhung der Robustheit - Aufgrund der hohen SW-Robustheit empfohlene Vorbedingung für eine leichte und sichere Wiederverwendbarkeit von SW - Leichte Fehlerlokalisierung U.U. Anstieg der Programm Ausführungszeit bzw. erhöhter Ressourcenbedarf Datenfehler (Typen, Wertebereiche) [17, 36]

332

Anhang QS-Maßnahmenkatalog

Tabelle 34. Code-Generierung Bezeichnung

Code-Generierung

Synonyme Querverweise Kurzbeschreibung

Bei der Code-Generierung wird automatisch aus Modellen Code generiert. Dazu muss der Softwareentwurf mit graphischen Beschreibungssprachen wie UML, Zustandsautomaten etc. dargestellt werden. Mittel Konstruktiv - Reduzierung von Fehlern, die durch menschliches Einwirken bei der Umsetzung einer Spezifikation in Programmcode gemacht werden - Erhöhung der Wirtschaftlichkeit und Produktivität - schnelle Erstellung von Prototypen SW-Implementierung

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile

Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

- Reduzierung von Programmier-Fehlern - Erhöhung der Anwendbarkeit von Beschreibungstechniken an Hand von Reverse-Engineering (z.B. UML) => somit Verbesserung der Wiederverwendbarkeit auf Modellebene - Möglicherweise Defizite bzgl. Codegröße und Codeeffizienz, Lesbarkeit - Von bestimmten zertifizierenden Behörden bei der Entwicklung von sicherheitskritischen Systemen noch nicht akzeptiert, da Werkzeuge nicht hinreichend erprobt (grundsätzlich jedoch gerade im sicherheitskritischen Bereich formale Modellierungsmethoden und Code-Generierung vorteilhaft) formale Modelle Code Generator Vermeidung von Implementierungsfehlern -

Organisatorische QS-Maßnahmen

333

Organisatorische QS-Maßnahmen Folgende organisatorische QS-Maßnahmen werden in diesem Kapitel in Form von QSM-Datenblättern behandelt: • • • • • • • • • • • • • • • • • • • • • •

Festlegung des Engineering-Modells Versions- und Konfigurationsmanagement Risikomanagement Testabdeckungsmatrix Unabhängige Testgruppen Phasen- und Projektreview Defect Management, Bug Tracking Änderungsmanagement Fehlerdatenbank Checklisten Designrichtlinien Programmierrichtlinien Dokumentationsrichtlinien Dokumentenvorlagen Dokumentationssysteme Dokumentation von Entscheidungen Glossar/Terminologie QS-Handbuch QS-Handbuch (projektspezifisch) Qualitätsplanung für den Entwicklungsprozess Q-Berichterstattung Projektaudits (Verfahrensaudit)

334

Anhang QS-Maßnahmenkatalog

Tabelle 35. Festlegung des Engineering-Modells Bezeichnung

Festlegung des Engineering-Modells

Synonyme Querverweise Kurzbeschreibung

Vorgehensmodell, Prozessmodell Es handelt sich um die Festlegung des Gesamtablaufs des Produktlebenszyklus bzw. des Entwicklungsprozesses und der anzuwendenden Maßnahmen in den einzelnen Phasen. Hoch Organisatorisch - Beherrschen der Prozesse: Transparenz, Reproduzierbarkeit und Nachvollziehbarkeit - Effektives Entwickeln, Wahl angemessener Maßnahmen Festlegung am Beginn des Entwicklungsprojekts

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug

Referenz

- Einheitliche und durchgängige Prozesse - geeignete Verfolgung des Projektfortschritts möglich - Vergleichbarkeit und Optimierbarkeit von Prozessen Wahl eines geeigneten Detaillierungsgrades schwierig => beeinflusst Akzeptanz und Anwendbarkeit Evtl. unterstützende Tools zur Modellierung und Anwendung von Prozessen Vermeidung von Produktivitäts- und Reibungsverlusten aufgrund nicht angemessener, nicht abgestimmter Maßnahmen [17]

Organisatorische QS-Maßnahmen

335

Tabelle 36. Versions- und Konfigurationsmanagement Bezeichnung

Versions- und Konfigurationsmanagement

Synonyme Querverweise Kurzbeschreibung

Änderungsmanagement Versions- und Konfigurationsmanagement ist die strukturierte, nachvollziehbare Verwaltung und Archivierung von Versionen und Varianten, sowie des Status von Dokumenten. In einer Konfiguration werden alle (in der betreffenden Variante) zugehörigen Elemente gemeinsam verwaltet. Versionierung ist die Erfassung aller Änderungen und ihres zeitlichen Zusammenhangs. Hoch Organisatorisch - Sicherstellung der Verfolgbarkeit eines Produkts und seiner Teile im Lebenszyklus - vollständiger und konsistenter Aufbau von Konfigurationen - Nachvollziehbarkeit von Änderungen - Rückgriff auf vorangegangene Versionen Alle

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

- Hilfe bei der Zusammenstellung von konsistenten Konfigurationen mit gewünschten Eigenschaften - Versionierungsvorteile (z.B. bei einer fehlerhaften Änderung problemlose Rückkehr zu einem alten Versionsstand) Akzeptanzprobleme Einsatz eines Konfigurationsmanagementsystems Vermeidung inkonsistenter Stände [2, 17, 36]

336

Anhang QS-Maßnahmenkatalog

Tabelle 37. Risikomanagement Bezeichnung

Risikomanagement

Synonyme Querverweise Kurzbeschreibung

FMEA Risikomanagement beschäftigt sich mit der Identifikation von Risikoelementen, dem Abschätzen von Schadenswahrscheinlichkeit und Schadensausmaß, der Gewichtung von Risiken unter Einbeziehung von Schadenswahrscheinlichkeit und Schadensausmaß (Risikoanalyse), der Planung und Durchführung von Gegenmaßnahmen sowie der regelmäßigen Neubewertung von Risiken. Hoch Organisatorisch Identifizierung von Projektrisiken, um geeignete Gegenmaßnahmen treffen zu können. => Probleme vermeiden bzw. beherrschen Alle Phasen (Risikoanalyse vorrangig in den konstruktiven Phasen) - Frühzeitige Erkennung von Risiken und Vermeidung von Problemen - Verbesserte Projektsteuerung anhand einer RisikoRangliste - Zur Durchführung erfahrene Mitarbeiter erforderlich - Möglichst von mehreren Beteiligten gemeinsam durchgeführt Diverse Fehler [2]

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile Voraussetzungen

Arbeitsmittel Fehlerbezug Referenz

Organisatorische QS-Maßnahmen

337

Tabelle 38. Testabdeckungsmatrix Bezeichnung

Testabdeckungsmatrix

Synonyme Querverweise Kurzbeschreibung

Es findet eine Zuordnung von Testfällen zu Anforderungen in einer zweidimensionalen Matrix statt. Das Abdeckungsmaß gibt an, wie viel Prozent der Anforderungen durch die zugeordneten Testfälle überprüft werden. Gering Organisatorisch - Anforderungsverfolgung von der Analysephase zur Testphase - Überblick über die Testabdeckung Analyse- und Testphasen

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile

Voraussetzungen

Arbeitsmittel Fehlerbezug Referenz

- Aussage über das Abdeckungsmaß, d.h. Höhe der Testabdeckung bezogen auf einzelne Anforderungen - Ermöglicht die Optimierung des Testvorgangs in dem Sinne, dass Testfälle gezielt so konstruiert werden, dass durch einen Testfall gleichzeitig mehrere Anforderungen abgedeckt werden - Unterstützung des Änderungsmanagements derart, dass bei Änderungen an Anforderungen direkt die zu überarbeitenden Testfälle bekannt sind Bei realistischer Anzahl von Anforderungen schwer handhabbar Zeigt nur auf, wie viele Anforderungen bereits getestet wurden, nicht aber den Testaufwand pro Anforderung - Definition der Anforderungen auf vergleichbarer Granularität - Anforderungen und Testfälle eindeutig referenzierbar Nicht erfüllte Anforderungen -

338

Anhang QS-Maßnahmenkatalog

Tabelle 39. Unabhängige Testgruppen Bezeichnung

Unabhängige Testgruppen (-personen)

Synonyme Querverweise Kurzbeschreibung Relevanz Klasse Ziel Entwicklungsphase Vorteile

Tests werden nicht vom Entwickler selbst durchgeführt. Hoch Organisatorisch Erhöhung des Fehlerentdeckungsgrades Testphasen in der System- und Subsystemebene

Nachteile

Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

- Unabhängige Qualitätsaussage - Unvoreingenommenheit gegenüber Lösungsansatz und Implementierungsweise - Einarbeitungsaufwand in das Testobjekt - Anschließende Fehleranalyse und Behebung wegen Kommunikationsaufwand zwischen Entwickler und Tester aufwendiger Ausreichend gut dokumentierte Spezifikation Testspezifisch Testspezifisch -

Organisatorische QS-Maßnahmen

339

Tabelle 40. Phasen- und Projektreview Bezeichnung

Phasen- und Projektreview

Synonyme Querverweise Kurzbeschreibung

Feedback, Nachlese Metriken Inhalt ist die Erfassung von aufgetretenen Problemen und der durchgeführten Gegenmaßnahmen sowie deren Bewertung. Erfolgreich eingesetzte Maßnahmen werden erfasst und bewertet. Ein Phasen- oder Projektreview findet projektintern statt und ist oft Teil des Projektabschlußberichts. Mittel Organisatorisch - Überprüfung der Wirksamkeit und Wirtschaftlichkeit von QS-Maßnahmen und Vorgehensmodellen - Erfahrungssicherung für nachfolgende Projektphasen bzw. Projekte - Projektreview: Am Projektende - Phasenreview: zu wichtigen Meilensteinen (nach den einzelnen Entwicklungsphasen) - Erarbeitung von Verbesserungsvorschlägen für die Vorgehensweise in einem Projekt - Akzeptanz hoch, da projektintern - Analyse eingesetzter Maßnahmen schwierig, da der Erfolg von Maßnahmen nur aufgrund langfristig erfasster Erfahrungen sinnvoll messbar - Bei Durchführung der Maßnahme am Projektende kein Einfluss auf das abgeschlossene Projekt, sondern erst auf die nachfolgenden Projekte Für langfristige, vergleichbare Analyse Erfahrungsdatenbank hilfreich Ggf. Erfahrungsdatenbank Verfahrens- oder Anwendungsfehler bei QS-Maßnahmen -

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile

Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

340

Anhang QS-Maßnahmenkatalog

Tabelle 41. Defect Management Bezeichnung

Defect Management

Synonyme Querverweise Kurzbeschreibung

Fehlermanagement, Bug Tracking Änderungsmanagement, Fehlerdatenbank Es findet eine Aufnahme und Verfolgung von Fehlern bis hin zur Fehlerbearbeitung und Schließen des Fehlers statt. Mittel Organisatorisch Konsequente Erfassung und Bearbeitung aufgetretener Fehler Alle Phasen (ab SW-Implementierung, einschließlich Betrieb) Dokumentation und Übersicht über noch bestehende und bereits korrigierte Fehler Verwaltungsaufwand Datenbank -

Relevanz Klasse Ziel Entwicklungsphase Vorteile Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

Organisatorische QS-Maßnahmen

341

Tabelle 42. Änderungsmanagement Bezeichnung

Änderungsmanagement

Synonyme Querverweise

Defect Management, Fehlerdatenbank, Anforderungsverfolgung, Anforderungsanalyse, Versions- und Konfigurationsmanagement Änderungsmanagement ist die Erfassung und Verwaltung von Änderungsanträgen (SCR system change request) und Entscheidung über diese Anträge. Es findet unter Überwachung der Umsetzung von angenommenen Änderungen durch Freigabemechanismen und Dokumentation von Änderungen statt. Hoch Organisatorisch - Sicherstellung der konsequenten Umsetzung von Änderungen - Nachvollziehbarkeit der Entwicklungshistorie - Bewertung von Änderungswünschen (technisch und wirtschaftlich) Alle

Kurzbeschreibung

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug

Referenz

- Entwicklungsergebnisse nur kontrolliert freigegeben - Prüfen und Bewerten von Änderungen und den damit verbundenen Auswirkungen (z.B. Kosten- und Zeitkontrolle) - Dokumentation der getroffenen Entscheidungen und damit Vermeidung von Mehrfachentscheidungen - Ermöglichung einer statistische Auswertung von Fehlerverläufen (z.B. als Testabbruchkriterium) - Verbreitung von Informationen über Änderungen Strukturierte Anforderungen Änderungsdatenbank - Undokumentierte Änderungen - Unvollständige Umsetzung von geänderten Anforderungen [2, 17]

342

Anhang QS-Maßnahmenkatalog

Tabelle 43. Fehlerdatenbank Bezeichnung

Fehlerdatenbank

Synonyme Querverweise Kurzbeschreibung

Defect Management, Änderungsmanagement In einer Fehlerdatenbank findet die zentrale Verwaltung aller Fehlermeldungen mit den erfassten Merkmalen von Fehlern statt (Dokumentation). Mittel Organisatorisch - Kontrollierte Fehlerverfolgung - Erfassung, Klassifizierung und Archivierung von Fehlern - Analyse der Merkmale von Fehlern im Hinblick auf die Auswahl wirtschaftlicher und erfolgversprechender QS-Maßnahmen - Vermeidung von Mehrfachbearbeitung des selben Fehlers Alle

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

- Einheitliche und vollständige Erfassung und Darstellung von Fehlern - Ermöglichung von Häufigkeitsanalysen, z.B. Anzahl Fehler pro Modul, Kosten pro Fehler Datenbanksysteme [17]

Organisatorische QS-Maßnahmen

343

Tabelle 44. Checklisten Bezeichnung

Checklisten

Synonyme Querverweise Kurzbeschreibung

Eine Checkliste ist eine erfahrungsbasierte Sammlung von Fragen, die wesentliche formale und inhaltliche Aspekte abdecken. Sie dienen als Gedächtnisstütze und/oder verbindlicher Nachweis (standardisiert bei wiederkehrenden Vorgängen oder fallbezogen). Es gibt prozess- und produktbezogene Checklisten. Hoch Organisatorisch Berücksichtigung aller wesentlichen Aspekte Alle

Relevanz Klasse Ziel Entwicklungsphase Vorteile

Nachteile

Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

- Vermeidung des Vergessens wesentlicher Aktivitäten und Ergebnisse - Einfaches Mittel zur Erfahrungssicherung - Gutes Aufwand-Nutzen-Verhältnis - Güte einer Checkliste stark abhängig von der Expertise/Erfahrung ihres Erstellers - Überprüfung der vollständigen Berücksichtigung wesentlicher Aspekte, nicht deren konkrete Umsetzung [36]

344

Anhang QS-Maßnahmenkatalog

Tabelle 45. Designrichtlinien Bezeichnung

Designrichtlinien

Synonyme Querverweise Kurzbeschreibung

Modellierungsrichtlinien Programmierrichtlinien Designrichtlinien sind Richtlinien zur Erstellung eines (Software-)Entwurfs. Beispiele sind Vorgaben bezüglich Architektur, Darstellung, Nomenklatur, Schnittstellen (Modulkohäsion und Kopplung), sowie der Benutzung von Patterns. Hoch Organisatorisch - Verbesserung der Kommunikation durch einheitliche Darstellung - Erhöhung von Wartbarkeit, Portierbarkeit und Wiederverwendbarkeit auf Designebene - Reduktion von Entwurfsfehlern Entwurfsphasen

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

- Unterstützung bei der Erstellung eines qualitativ hochwertigen Designs - Wiederverwendung von bisher erfolgreichen Designlösungen => Zeitersparnis und Erhöhung der Qualität Von den Entwicklern evtl. als Einschränkung der Kreativität empfunden Methodik-Kenntnisse CASE-Tools Entwurfsfehler -

Organisatorische QS-Maßnahmen

345

Tabelle 46. Programmierrichtlinien Bezeichnung

Programmierrichtlinien

Synonyme Querverweise Kurzbeschreibung

Designrichtlinien, Defensive Programmierung Programmierrichtlinien sind bindende Regeln für die Programmierung. Beispiele sind Vorgaben für Code-Layout, Verwendung bestimmter Konstrukte, Kommentierung, Schachtelungstiefe von Funktionen sowie Namensgebung. Unternehmensweite Programmierrichtlinien können durch projektspezifische ergänzt bzw. präzisiert werden. Hoch Organisatorisch - Verbesserung der Lesbarkeit - Verbesserung der Testbarkeit, Wartbarkeit und Portierbarkeit SW-Implementierung

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile

Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

- Verbesserung der Kommunikation durch einheitliche Darstellung - Vermeidung von Implementierungsfehlern In der Praxis z.T. Akzeptanzprobleme (Einengung der Kreativität, erhöhter Programmieraufwand, großer Umfang, Aktualität) Sinnvollerweise Toolunterstützung Implementierungsfehler [17, 36]

346

Anhang QS-Maßnahmenkatalog

Tabelle 47. Dokumentationsrichtlinien Bezeichnung

Dokumentationsrichtlinien

Synonyme Querverweise Kurzbeschreibung

Dokumenationsvorlagen Dokumentationsrichtlinien beinhalten bindende Regeln für Struktur und Inhalte von projektrelevanten Dokumenten. Unternehmensweite Dokumentationsrichtlinien können durch projektspezifische ergänzt bzw. präzisiert werden. Hoch Organisatorisch - Vereinheitlichung von Dokumenten - Sicherstellen der Vollständigkeit von Dokumenten - Hilfestellung bei der Erstellung von Dokumenten und damit Erhöhung der Dokumentations-Produktivität Alle

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

Vergleichbarkeit von Dokumenten auch über Projekte hinweg => leichtere Einarbeitung und Orientierung sowie bessere Möglichkeiten zur Wiederverwendung Durchsetzung und Überprüfung schwierig Commitment der Führungsebene - Vermeidung von Unvollständigkeit - Vermeidung von Missverständnissen -

Organisatorische QS-Maßnahmen

347

Tabelle 48. Dokumentenvorlagen Bezeichnung

Dokumentenvorlagen

Synonyme Querverweise Kurzbeschreibung

Dokumentationsrichtlinien Dokumentenvorlagen sind strukturell und Layouttechnisch standardisierte Dokumentgliederungen, die einheitlich im Unternehmen/ Projekt eingesetzt werden. Gegebenfalls mit inhaltlichen Vorgaben und Hilfestellungen. Hoch Organisatorisch - Einheitliches Aussehen und Vollständigkeit der Dokumente - Verkürzte Erstellungszeiten für Dokumente Alle

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile Voraussetzungen

Arbeitsmittel Fehlerbezug Referenz

- Einheitliche Strukturierung der Dokumente - Erleichterte Einarbeitung in und eventuelle Weiterverarbeitung von Dokumenten Große Hemmschwelle, etablierte Vorlagen zu ändern Verwendung eines einheitlichen Textverarbeitungssystems oder eines standardisierten, toolunabhängigen Dokumentenformates Textverarbeitungssystem Fehlen von wichtigen inhaltlichen und formellen Aspekten -

348

Anhang QS-Maßnahmenkatalog

Tabelle 49. Dokumentationssystem Bezeichnung

Dokumentationssystem

Synonyme Querverweise Kurzbeschreibung

Ein Dokumentationssystem stellt Dokumentenvorlagen und Dokumentationsstrukturen für Projekte zur Verfügung und verwaltet die erstellten Projektdokumente und ihre Querbezüge sowie Versionen. Mittel Organisatorisch Standardisierung und Verwaltung der Phasendokumentation Alle

Relevanz Klasse Ziel Entwicklungsphase Vorteile

Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

- Erleichterung der Prüfung auf Vollständigkeit und Widerspruchsfreiheit der Dokumentation - Konsistenz und Vermeidung von Redundanzen Akzeptanzprobleme bei zu restriktiver Gestaltung und Handhabung von Dokumenten Ähnlichkeit der Projekte Inkonsistenter Satz von Dokumenten [17]

Organisatorische QS-Maßnahmen

349

Tabelle 50. Dokumentation von Entscheidungen Bezeichnung

Dokumentation von Entscheidungen

Synonyme Querverweise Kurzbeschreibung

Eine Entscheidung ist die Festlegung auf eine Lösungsmöglichkeit für ein Problem. Entscheidungen werden nachvollziehbar, verständlich und leicht zugänglich dokumentiert. Es muss ersichtlich sein, aus welchem Grund eine Alternative gewählt wurde bzw. wieso andere Alternativen nicht gewählt wurden. Hoch Organisatorisch - Nachvollziehbarkeit von Entscheidungen. - Know-how-Sicherung Alle

Relevanz Klasse Ziel Entwicklungsphase Vorteile

Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

- Steigerung der Effektivität (keine wiederholten Entscheidungen) und der Transparenz von Prozessen - Gründlichere Hinterfragung eines Entscheidungsschritts durch den Entscheider Evtl. Hemmung intuitiv arbeitender kreativer Entwickler durch Dokumentationszwang - Vermeidung von undurchdachten Entscheidungen - Vermeidung von Intransparenz -

350

Anhang QS-Maßnahmenkatalog

Tabelle 51. Glossar / Terminologie Bezeichnung

Glossar/Terminologie

Synonyme Querverweise Kurzbeschreibung

Ein Glossar/Terminologie ist eine Liste von Begriffen und zugehörigen Begriffsdefinitionen sowie Abkürzungen. Wichtig sind ein angemessener Umfang und die Relevanz der Begriffe. Hoch Organisatorisch - Eindeutige, unmissverständliche Beschreibung von Begriffen - Identifikation von für die Nutzergruppe relevanten Begriffen Alle

Relevanz Klasse Ziel

Entwicklungsphase Vorteile

Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

- Einheitliches Verständnis von Begriffen - Identifikation/ Definition von synonymen Begriffen und Abgrenzung zu ähnlichen Begriffen Fehler, die auf Missverständnissen beruhen -

Organisatorische QS-Maßnahmen

351

Tabelle 52. QS-Handbuch Bezeichnung

QS-Handbuch

Synonyme Querverweise Kurzbeschreibung

QS-Handbuch (projektspezifisch) Das QS-Handbuch enthält unternehmensweite Richtlinien für ablauf- und aufbauorganisatorische Maßnahmen zur Qualitätssicherung. Die Maßnahmen müssen sich an den Qualitätsanforderungen an die Produkte und den Qualitätszielen orientieren. Für eine projektspezifische Anpassung eines QS-Handbuchs sind entsprechende Regeln zu erarbeiten. Hoch Organisatorisch Definition eines Qualitätsstandards für ein Unternehmen Projektübergreifend

Relevanz Klasse Ziel Entwicklungsphase Vorteile

Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

- Qualitäts-Grundgerüst nicht für jedes Projekt neu zu erstellen - Grundvoraussetzung für verschiedene Zertifizierungen Aufwand für Pflege evtl. relativ hoch [17]

352

Anhang QS-Maßnahmenkatalog

Tabelle 53. QS-Handbuch (projektspezifisch) Bezeichnung

QS-Handbuch (projektspezifisch)

Synonyme Querverweise Kurzbeschreibung

Projekthandbuch QS-Handbuch Im QS-Handbuch (projektspezifisch) erfolgt die Konkretisierung und Anpassung des unternehmensweiten QSHandbuches an die projektspezifischen Anforderungen, sinnvollerweise durch Tayloring des im allgemeinen QSHandbuch beschriebenen Vorgehensmodells. Das QSHandbuch (projektspezifisch) ist Teil der Projektdokumentation. Mittel Organisatorisch Bedarfsgerechte Qualitätssicherung - Erstellung zu Projektbeginn; - Gültigkeit in allen Phasen - Klärung der Qualitätsanforderungen - Überprüfbare Qualitätsanforderungen Aufwand nur bei Vorhandensein eines in generischer Form vorliegenden QS-Handbuchs vertretbar -

Relevanz Klasse Ziel Entwicklungsphase Vorteile Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

Organisatorische QS-Maßnahmen

353

Tabelle 54. Qualitätsplanung für den Entwicklungsprozess Bezeichnung

Qualitätsplanung für den Entwicklungsprozess

Synonyme Querverweise Kurzbeschreibung

Inhalt ist die Definition der Qualitätsanforderungen an einen Prozess anhand von Qualitätsmerkmalen und ihren Ausprägungen, sinnvollerweise in Abhängigkeit von der geforderten Produktqualität. Es handelt sich um den ersten Schritt der Planung der Qualitätssicherung. Mittel Organisatorisch Effizienzsteigerung, um eine geforderte Produktqualität günstiger, besser, schneller erreichen zu können am Beginn des Entwicklungsprojekts

Relevanz Klasse Ziel Entwicklungsphase Vorteile Nachteile

Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

Ermöglichung einer angemessenen Kosten-, Termin- und Ressourcenplanung der Qualitätssicherung - Umsetzung von Prozessveränderungen schwierig - Einhaltung der Spezifikation von Prozessqualität z.T. schwer zu überprüfen (u.a. menschliche/psychologische Aspekte) -

354

Anhang QS-Maßnahmenkatalog

Tabelle 55. Q-Berichterstattung Bezeichnung

Q-Berichterstattung

Synonyme Querverweise Kurzbeschreibung

Q-Berichterstattung (Qualitäts-Berichterstattung) bedeutet die Erstellung von Qualitätsberichten zu festgesetzten Terminen (z.B. zu Meilensteinen). Sie beinhaltet den Stand der QS-Aufgaben, den Stand der Planungen und eine QS-Bewertung des Projekts (Prozess und Produkt; ggf. mit Verbesserungsvorschlägen). Die QS-Berichterstattung kann im Rahmen der Projektberichterstattung erfolgen. Mittel Organisatorisch - Erkennung von systematischen Fehlerschwerpunkten in bestimmten Projektteilen und/oder Projektphasen - Überwachung von Qualität, Q-Kosten und Q-Terminen Alle

Relevanz Klasse Ziel

Entwicklungsphase Vorteile Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug Referenz

Ermöglichung einer Projektüberwachung aus Qualitätssicht (und damit frühzeitiges Gegensteuern bei Problemen) - QS-Plan - Sinnvoll: Erfassung von Metriken Erkennen von QS-Risiken (QS-Kosten und QS-Termine) -

Organisatorische QS-Maßnahmen

355

Tabelle 56. Verfahrensaudit Bezeichnung

Verfahrensaudit

Synonyme Querverweise Kurzbeschreibung

Prozessaudit Review, Inspektion Ein Verfahrensaudit ist die Überprüfung der Einhaltung von vereinbarten Regeln und Richtlinien durch unabhängige Prüfer, sowie Hinterfragen der Regeln und Richtlinien selbst. Mittel Organisatorisch Überprüfung der Regelkonformität Alle

Relevanz Klasse Ziel Entwicklungsphase Vorteile Nachteile Voraussetzungen Arbeitsmittel Fehlerbezug

Referenz

Lieferung von Verbesserungsvorschlägen für die Vorgehensweise in einem Projekt Befangenheit der Auditierten gegenüber externen Auditoren Hohe soziale, methodische und fachliche Kompetenz der unabhängigen Auditoren - Erkennen von überholten oder nicht angemessenen Regeln und Richtlinien - Abweichung von Regeln und Richtlinien [17]

Literatur

1. 2.

3.

4.

5. 6.

7. 8. 9.

10.

11.

12. 13. 14.

Balzert H (1996) Lehrbuch der Software-Technik: SoftwareEntwicklung. Spektrum Akademischer Verlag, Heidelberg Balzert H (1998) Lehrbuch der Software-Technik: SoftwareManagement, Software-Qualitätssicherung, Unternehmensmodellierung. Spektrum Akademischer Verlag, Heidelberg Balzert H (2000) Lehrbuch der Software-Technik, Band 1: SoftwareEntwicklung. Spektrum Akademischer Verlag, Heidelberg, 2.Auflage Barthel A, Hindel B, Schmied J (2000) Stein auf Stein. Definition des Software-Entwicklungsprozesses nach einem Baukastensystem. QZ 45 4/2000: 441-445 Beck K (2000) eXtreme Programming Explained. Addison Wesley, Massachusetts Becker A (2000) Komplexe Probleme und Entscheidungen. Vorlesung Allgemeine Betriebswirtschaftslehre, Zyklus & Block A, Freie Universität Berlin. Bender K et al. (1999) Echtzeitsimulation zum Test von Maschinensteuerungen. Herbert Utz, München Bender K et al. (2001) Qualitätssicherung eingebetteter Software: Methoden und Best-Practice. Herbert Utz, München Bergmann J (1998) Funktionsprüfung der Steuerungssoftware intelligenter, technischer Produkte. Dissertation, TU München: Herbert Utz Verlag Wissenschaft, München BI-Wiss.-Verl. (1998) DUDEN Informatik – Ein Sachlexikon für Studium und Praxis. Bibliographisches Institut & F.A. Brockhaus AG, Mannheim BMBF (2000) Analyse und Evaluation der Softwareentwicklung in Deutschland. (Studie für das Bundesministerium für Bildung und Forschung) Bungert A (1998) Beschreibung programmierter Systeme mittels Hierarchien intuitiv verständlicher Modelle. Shaker, Aachen British Standards Institution (1995) BS EN ISO 8402:1995 – Qualitätsmanagement. Begriffe. British Standards Institution Cockburn A (2001) Agile Software Development: Software Through People. Addison-Wesley, Reading

358

Anhang Literatur

15. Collins B (2000) Corporate Portals: Revolutionizing Information Access to In-crease Productivity and Drive the Bottom Line. Amacom Dez. 2000 16. Daenzer W und Huber F (Hrsg), Haberfellner, Nagel, Becker, Büchel, von Massow (2002) Systems Engineering. Verlag Industrielle Organisation, Zürich 17. Deutsche Gesellschaft für Qualität e.V. (Hrsg.) (1995) DGQ-ITGBand 12-51, Software-Qalitätsmanagement – Aufgaben – Möglichkeiten – Lösungen. 18. Deutsche Gesellschaft für Qualität e.V. (Hrsg.) (1998) Zuverlässigkeit komplexer Systeme aus Hardware und Software. DGQ-Band Nr. 1701, Beuth, Berlin 19. DIN Deutsches Institut für Normung e. V (1995) DIN 55350-11 – Begriffe zu Qualitätsmanagement und Statistik. Teil 11: Begriffe des Qualitätsmanagements. Beuth, Berlin Wien Zürich 20. DIN Deutsches Institut für Normung e. V. (1982) DIN 44300 – Informationsverarbeitung; Begriffe. Beuth, Berlin Wien Zürich 21. DIN Deutsches Institut für Normung e. V. (1995) EN ISO 8402 – Qualitätsmanagement – Begriffe. Beuth, Berlin Wien Zürich 22. Dominka S, Koç A, Stützel B (2004) Vergleichen lohnt. QZ 1/2004:35-38 23. Dominka S, Stützel B (2004) EQUAL – Qualitätssicherungsmaßnahmen eingebetteter Systeme. In: Gausemeier J, Wallascheck J (Hrsg) Intelligente mechatronische Systeme.Heinz Nixdorf Institut, Universität Paderborn, S 57-65 24. Dudenredaktion (Hrsg.) (1996) DUDEN – Die deutsche Rechtschreibung. Bibliographisches Institut & F.A. Brockhaus AG, Mannheim 25. Ehrlenspiel K (1995) Integrierte Produktentwicklung. Hanser, München, Wien 26. EStdIT (1997) V-Modell – Entwicklungstandard für IT-Systeme des Bundes. 27. Fargemand O, Olsen A (1992) New Features in SDL-92. Telecommunications Research Laboratory, Horsholm 28. Fowler M, Scott K (1997) UML distilled. Addison-Wesley, Reading 29. Frühauf K, Ludewig J, Sandmayr H (1999) SoftwareProjektmanagement und -Qualitätssicherung. vdf Hochschulverlag, Zürich 30. Gausemeier J, Ebbesmeyer P, Kallmeyer F (2001) Produktinnovation. Carl Hanser Verlag, München Wien 31. Grell D (2003) Rad am Draht. C’t Heft 14: 170-183 32. Hahn G et al. (2003) Prototype-based tests for hybrid reactive systems. In: Proc. 14th IEEE Intl. Workshop on Rapid System Prototyping (RSP'03), IEEE Computer Society, pp 78-85

359 33. Hesse W et al. (1994) Terminologie in der Softwaretechnik – Ein Begriffssystem für die Analyse und Modellierung von Anwendungssystemen. Teil 2: Tätigkeits- und ergebnisbezogene Elemente. In: Informatik-Spektrum. Springer, Berlin Heidelber New York, 17 1994 pp 96-105 34. Hindel B et al. (2004) Basiswissen Software-Projektmanagement. dpunkt.verlag, Heidelberg 35. International Atomic Energy Agency (1999) Verification and Validation of Software Related to Power Plant Instrumentation and Control. 36. International Electrotechnical Commission (1997) Functional safety of electrical/electronic/programmable electronic safety-related systems – Part 7: Overview of techniques and measurees. 37. International Organization for Standardization (1991) ISO/IEC 9126:1991 – Bewerten von Softwareprodukten: Qualitätsmerkmale und Leitfaden zu ihrer Verwendung. 38. International Organization for Standardization (1998) ISO/IEC TR 15504:1998: Information Technology – Software Process Assessment. 39. Kahle E (2001) Betriebliche Entscheidungen. 6. Aufl, Oldenbourg, München Wien 40. Kallmeyer F (1998) Eine Methode zur Modellierung prinzipieller Lösungen mechatronischer Systeme. Dissertation Universität Paderborn 41. Keller F, Wendt S (2003) FMC: An Approach Towards ArchitectureCentric System Development. Proceedings of 10th IEEE Symposium and Workshops on Engineering of Computer Based Systems 2003, IEEE Computer Society, Huntsville, pp 173-182 42. Koç A (2003) Entscheidungsunterstützung zur Planung der SoftwareQualitätssicherung in mechatronischen Produkten. Dissertation, TU München 43. Koç A et al. (2002) Systematische Planung effizienter Qualitätssicherung eingebetteter Software. In: Automatisierungstechnische Praxis (atp), Jg. 44 (2002) Nr. 8, R. Oldenbourg, pp 45-51 44. Kruchten P (1999) The Rational Unified Process. Addison-Wesley, Massachusetts [u.a.] 45. Lehmann G, Wunder B, Selz M (1994) Schaltungsdesign mit VHDL. Universität Erlangen – Nürnberg, Karlsruhe und Nürnberg 46. Liggesmeyer P (2000) Qualitätssicherung softwareintensiver technischer Systeme. Heidelberg; Berlin: Spektrum, Akademischer Verlag, 2000. 47. Lippert M, Roock S, Wolf H (2002) Software entwickeln mit eXtreme Programming. dpunkt, Heidelberg

360

Anhang Literatur

48. Lippold C (2000) Eine domänenübergreifende Konzeptionsumgebung für die Entwicklung mechatronischer Systeme, Dissertation Universität Bochum 49. Lusti M (1999) Data Warehousing und Data Mining: Eine Einführung in entscheidungsunterstützende Systeme. Springer, Berlin 50. Meier E, Schmied J (2003) (Software-) Projekt- und Prozessmanagement: Ein integrierter Ansatz. A&D Kompendium 2003 51. National Aeronautics and Space Administration (1996) Software Program – Software Management Guidebook. NASA, Washington DC 52. Normenausschuss Qualitätsmanagement, Statistik und Zertifizierungsgrundlagen (NQSZ) (1987) DIN 69900-2 – Projektwirtschaft; Netzplantechnik; Darstellungstechnik. Beuth, Berlin Wien Zürich 53. Normenausschuss Qualitätsmanagement, Statistik und Zertifizierungsgrundlagen (NQSZ) (1995) DIN 55350-11 – Begriffe zu Qualitätsmanagement und Statistik - Teil 11: Begriffe des Qualitätsmanagements. Beuth, Berlin Wien Zürich 54. PNO-Labor Fürth (1999) Laboranweisung v2.0 55. Paulk M et al. (1993) Capability Maturity Model, Version 1.1. In: IEEE Software, Vol. 13 (1993), No. 7, pp. 18-27. 56. Popp M (2000) Profibus-DP/DPV1 - Grundlagen, Tipps und Tricks für Anwender. Hüthig 57. Probst G, Romhardt K (1997) Bausteine des Wissensmanagements – ein praxisorientierter Ansatz. In: Dr. Wieselhuber & Partner Unternehmensberatung (Hrsg.) Lernende Organisation. Gabler 58. Russ M, Pöschl M (2004) Virtueller Funktionstest für die Entwicklung eingebetteter Software. In: Gausemeier J, Wallascheck J (Hrsg) Intelligente mechatronische Systeme.Heinz Nixdorf Institut, Universität Paderborn, S 79-89 59. Schäuffele J, Zurawka T (2003) Automotive Software Engineering. Vieweg, Wiesbaden 60. Sommerville I (1995) Software-Engineering. Addison-Wesley, Bonn 61. Stienen H (1999) Nach CMM und Bootstrap: SPICE Die neue Norm für Prozessbewertungen. In: Informatik 6/1999. 62. Sylla K (2004) eXtreme Programming, eine Welle mit Schaum und Substanz. In: VDI-Berichte 1842 Mechatronischer Systementwurf. VDI Verlag, Düsseldorf, S 101-108 63. Trauboth H (1996) Handbuch der Informatik (Band 5.2) – Software Qualitätssicherung, Oldenbourg, München 64. VDI (1993) VDI-Richtlinie 2221 – Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte. VDI – Verlag, Düsseldorf 65. VDI (1994) VDI-Richtlinie 2422 – Entwicklungsmethodik für Geräte mit Steuerung durch Mikroelektronik, VDI – Verlag, Düsseldorf

361 66. VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik (2001) VDI/VDE-Richtlinie 3694 – Lastenheft/Pflichtenheft für den Einsatz von Automatisierungssystemen. Beuth, Berlin Wien Zürich 67. Versteegen G (2000) Das V-Modell in der Praxis. Hanser, München Wien 68. Wallace D, Ippolito L, Cuthill B (1996) Reference Information for the Software Verification and Validation Process. U.S. Department of Commerce 69. Wallmüller E (1995) Ganzheitliches Qualitätsmanagement in der Informationsverarbeitung. Carl Hanser Verlag, München Wien 70. Weinmann U (2004) Software im Automobil – technische und wirtschaftliche Visionen. VDE/VDI- Arbeitskreis "Informationstechnik", 12.02.2004, München

Glossar

4-Phasen-Plan

Es handelt sich hierbei um ein Vorgehensmodell für den Test technischer ÆSysteme, bestehend aus den vier elementaren Phasen Testplanung, Testvorbereitung, Testdurchführung und Testauswertung.

Abnahme

Die Abnahme ist ein Vorgang, bei dem das Ergebnis einer Entwicklungstätigkeit (Dokumente und Produkte) vom ÆAuftraggeber auf Vollständigkeit und Korrektheit hinsichtlich vorher von ÆAuftraggeber und ÆAuftragnehmer vereinbarter ÆAnforderungen überprüft wird. Mit der erfolgreichen Abnahme wird der ÆAuftragnehmer entlastet, und das abgenommene ÆProdukt geht in die Verantwortung des ÆAuftraggebers über.

Abnahmetest

Ein Abnahmetest ist ein Test unter realen Einsatzbedingungen beim ÆAuftraggeber/Kunden, durch den das ÆProdukt formal/vertraglich abgenommen wird. Eine ÆAbnahme erfolgt, wenn keine oder tolerierbare Fehler bzw. Fehler, die nachgebessert werden können, auftreten. Getestet wird gegen ein ÆLastenheft.

Abstrahierer

Ein Abstrahierer ist eine (meist Software-) Komponente des ÆTestbetts, die unterschiedliche Abstraktionsebenen an den ÆSchnittstellen zwischen ÆTestobjekt und dem Reaktionsteil eines ÆTestfalls überbrückt. Häufig sind die Abstrahierer recht einfach, wie beispielsweise ein A/D-Wandler, der analoge Ausgaben des Testobjekts in Ædiskrete Zahlenwerte übersetzt. Ein Abstrahierer kann aber auch komplexer sein und beispielsweise Informationen aus der bisherigen Testdurchführung verwenden. Das Gegenstück zum Abstrahierer ist der ÆKonkretisierer.

Akzeptanztest

Der Akzeptanztest ist nicht mit dem ÆAbnahmetest gleichzusetzen. Es wird geprüft, ob der Kunde das ÆProdukt akzeptiert (Benutzbarkeit, fehlende ÆAn-

364

Anhang Glossar forderungen, Leistungsfähigkeit, Funktionalität etc.). In Anlehnung an ein ÆLastenheft wird gegen die (subjektive) Erwartungshaltung des Kunden getestet.

Änderungsmanagement

Änderungsmanagement ist die Erfassung und Verwaltung von Änderungsanträgen (SCR – System Change Request) und Entscheidung über diese Anträge. Es findet unter Überwachung der Umsetzung von angenommenen Änderungen durch Freigabemechanismen und Dokumentation von Änderungen statt.

Anforderungen

Anforderungen legen die qualitativen und quantitativen Eigenschaften eines ÆProdukts aus der Sicht des ÆAuftraggebers fest [3]. Die Formulierung der Anforderungen muss - lösungsneutral - positiv formuliert - überprüfbar - klar und eindeutig sein. [25]

Anforderungsanalyse

Die ÆAnforderungsanalyse ist eine systematische Vorgehensweise, um die ÆAnforderungen an das zu realisierende ÆSystem aus Sicht des Kunden (ÆLastenheft) zu ermitteln und schrittweise zu verfeinern. In der Regel handelt es sich um einen iterativen ÆProzess, bei dem beispielsweise Kunden, Produktmanagement, Marketing und Entwicklung beteiligt sind.

Anforderungsverfolgung

Anforderungsverfolgung ist die Zuordnung von Projektergebnissen zu ÆAnforderungen (z.B. in Form einer Matrixdarstellung). Zweck ist die Überprüfung, ob alle ÆAnforderungen vollständig berücksichtigt worden sind. Unter ÆAnforderungen werden in diesem Zusammenhang sowohl die originären Anwenderanforderungen als auch die entwickelten Detailkonzepte sowie die Einhaltung von Richtlinien und Normen verstanden.

Auftraggeber

Der Auftraggeber ist eine juristische Person, die mit dem ÆAuftragnehmer einen Vertrag bezüglich der Durchführung eines Entwicklungs-Vorhabens abgeschlossen hat bzw. abschließen will. Der Auftraggeber erteilt in dem Vertrag dem ÆAuftragnehmer den Auftrag, das Entwicklungs-Vorhaben durchzuführen

365 und übernimmt die in dem Vertrag festgelegten Rechte und Pflichten. Auftragnehmer

Der Auftragnehmer ist eine juristische Person, die mit dem ÆAuftraggeber einen Vertrag bezüglich der Durchführung eines Entwicklungs-Vorhabens abgeschlossen hat bzw. abschließen will. Der Auftragnehmer übernimmt in dem Vertrag den Auftrag, das Entwicklungs-Vorhaben durchzuführen und übernimmt die in dem Vertrag festgelegten Rechte und Pflichten.

Baseline

Als Baseline wird eine genau spezifizierte Menge an ÆProdukten (Dokumente, Software, Hardware und Mechanik) zu einem definierten Zeitpunkt verstanden, die bezüglich der gestellten ÆAnforderungen überprüfbar ist und eine verlässliche Basis für die Weiterarbeit bildet. Hinweis: Baselines markieren Reifezustände (ÆAnforderungen, Lösungskonzept, Entwurf, Liefereinheit) eines Entwicklungsgegenstandes.

Black-Box Test

Beim Black-Box Test wird die gekapselte Funktionalität des Prüflings systematisch gegen die Spezifikation getestet. Die innere Struktur des Prüflings bleibt dem Prüfer verborgen (Black-Box). Die Testfälle werden aus der Spezifikation abgeleitet.

Checklisten

Eine Checkliste ist eine erfahrungsbasierte Sammlung von Fragen, die wesentliche formale und inhaltliche Aspekte abdecken. Sie dienen als Gedächtnisstütze und/oder verbindlicher Nachweis (standardisiert bei wiederkehrenden Vorgängen oder fallbezogen). Es gibt prozess- und produktbezogene Checklisten.

Codeanalyse

Bei der Codeanalyse wird der Quellcode statisch geprüft und dokumentiert.

Code-Generierung

Im vorliegenden Kontext wird unter dem Begriff Code-Generierung die automatische Erzeugung ablauffähiger Software aus ÆModellen verstanden.

Datenflussanalyse

Die Datenflussanalyse analysiert den Wertefluss in einem Programm, d.h. es werden die Werte von Variablen bezüglich des Programmablaufs untersucht.

366

Anhang Glossar

Defect Management, Bug Tracking

Es findet eine Aufnahme und Verfolgung von Fehlern bis hin zur Fehlerbearbeitung und Schließen des Fehlers statt.

Defensive Programmierung

Bei der defensiven Programmierung werden implizite Zusicherungen explizit geprüft und entsprechende Fehlerbehandlungen vorgesehen. Beispiele sind das Abfangen von Bereichsüberschreitungen bei Indizes oder das Prüfen von Vorbedingungen bei Funktionsaufrufen.

Designrichtlinien

Designrichtlinien sind Richtlinien zur Erstellung eines Designs. Beispiele sind Vorgaben bezüglich Architektur, Darstellung, Nomenklatur, Schnittstellen (Modulkohäsion und Kopplung) sowie der Benutzung von Entwurfsmustern (Patterns).

diskret

Dieser (math.) Ausdruck bedeutet voneinander getrennt, einzeln, gesondert (Zahlen, Werte).

Diskrete Systeme

Primär zu unterscheiden sind zeitdiskrete, wertdiskrete und ereignisdiskrete ÆSysteme. Zeitdiskrete Systeme zeichnen sich dadurch aus, dass sich ihre Werte nur zu äquidistanten Zeitpunkten ändern können, die Signalvariablen an sich jedoch jeden beliebigen Wert annehmen können. Bei wertdiskreten Systemen können die Signalvariablen nur endlich viele diskrete Signalamplituden annehmen. Ereignisdiskrete Systeme werden auch als reaktive Systeme bezeichnet. Ein solches System kann nur bestimmte Zustände annehmen. Der Wechsel zwischen diesen Zuständen findet aufgrund von Ereignissen statt.

Dokumentation von Entscheidungen

Eine Entscheidung ist die Festlegung auf eine Lösungsmöglichkeit für ein Problem. Entscheidungen werden nachvollziehbar, verständlich und leicht zugänglich dokumentiert. Es muss ersichtlich sein, aus welchem Grund eine Alternative gewählt wurde bzw. wieso andere ausgeschlossen wurden.

Dokumentationsrichtlinien

Dokumentationsrichtlinien beinhalten bindende Regeln für Struktur und Inhalte von projektrelevanten Dokumenten. Unternehmensweite Dokumentationsrichtlinien können durch projektspezifische ergänzt bzw. präzisiert werden.

367 Dokumentationssystem

Ein Dokumentationssystem stellt Dokumentenvorlagen und Dokumentationsstrukturen für ÆProjekte zur Verfügung und verwaltet die erstellten Projektdokumente und ihre Querbezüge sowie Versionen.

Dokumentenvorlagen

Dokumentenvorlagen sind strukturell und Layouttechnisch standardisierte Dokumentgliederungen, die einheitlich im Unternehmen/ ÆProjekt eingesetzt werden. Gegebenenfalls werden inhaltliche Vorgaben und Hilfestellungen definiert.

Echtzeit

Echtzeitbetrieb ist ein Betrieb eines Rechensystems, bei dem Programme zur Verarbeitung anfallender Daten ständig betriebsbereit sind derart, dass die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind. Die Daten können je nach Anwendungsfall nach einer zufälligen zeitlichen Verteilung oder zu vorbestimmten Zeitpunkten auftreten [20].

Effektivität

Die Effektivität ist ein Maß für die Zielerreichung geplanter Ergebnisse (vgl. auch ISO 9000:2000). Eine Effektivität ist besonders groß, wenn das erreichte Ergebnis der ursprünglichen Zielsetzung besonders gut entspricht. Die Effektivität macht keine Aussage darüber, in welchem Verhältnis das erreichte Ergebnis zu dem für die Zielerreichung aufgebrachten Mitteleinsatz steht (ÆEffizienz).

Effiziente Qualitätssicherung

Es handelt sich hierbei um die Auswahl und den Einsatz von QS-Maßnahmen, welche 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 Aufwands-Nutzen-Verhältnis zu den gegebenen Rahmenbedingungen eines ÆProjekts passen.

Effizienz

Die Effizienz ist ein Maß für das Verhältnis zwischen dem erzielten Ergebnis und den eingesetzten Mitteln (vgl. auch ISO 9000:2000). Die Effizienz ist besonders groß, wenn durch den Einsatz geringer Mittel eine besonders hohe Wirkung erreicht wurde. Allerdings macht die Effizienz keine Aussage darüber, inwiefern die erzielte Wirkung im Einklang mit der beabsichtigten Wirkung steht (ÆEffektivität).

368

Anhang Glossar

Eingebettete Software

(engl. embedded software) Eingebettete Software ist Software die auf einem Æeingebetteten System läuft.

Eingebettetes System (ES)

(engl. embedded system) Ein eingebettetes System ist ein Rechner (Software-/Hardware-Einheit), der integrierter Teil einer Maschine oder eines Geräts und nach außen nicht als Rechner, sondern nur als Träger intelligenter Systemfunktionen erkennbar ist. Es ist über Sensoren und Aktoren mit einem Gesamtsystem verbunden und übernimmt darin Überwachungs-, Steuerungs- bzw. Regelungsaufgaben.

Emulation

(engl. emulation = Nachbildung, Nacheiferung) Durch Emulation werden Rechenanlagen oder Programme derart nachgebildet, dass sie sich so wie das nachgebildete ÆSystem verhalten. Im Gegensatz zur Simulation können nur existierende Programme oder Rechenanlagen emuliert werden, deren Gesetzmäßigkeiten vollständig bekannt sind. Die Emulation kann als Ersatz eines Programms oder einer Rechenanlage dienen, die nicht mehr angeboten oder unterstützt werden (z.B. C64 ÆEmulator).

Emulator

Ein Emulator ist ein Gerät oder Programm, mit dessen Hilfe die Æ Emulation realisiert wird.

Endlicher Automat

Ein Endlicher Automat ist ein ÆZustandsautomat.

Entscheidungsproblem

Ein Entscheidungsproblem ist ein Problem, bei dem mehrere Möglichkeiten der Problemlösung bestehen. Die allgemeine Eigenschaft der Entscheidung besteht darin, dass ein Wahlakt zwischen mindestens zwei Handlungsmöglichkeiten vorliegen muss, die als Alternativen bezeichnet werden [6, 39].

Entscheidungsprozess

Als Entscheidungsprozess wird der Arbeitsablauf bezeichnet, der zur Wahl einer Alternative führt. Das Ergebnis des Entscheidungsprozesses wird Entschluss genannt.

Entscheidungsunterstützung

Eine Entscheidungsunterstützung hilft bei der Lösung komplexer Probleme. Sie fällt selbst keine Entscheidungen und beschränkt sich auf die Unterstützung von Handlungsträgern in bestimmten Entscheidungsphasen [49].

369 Entwicklungsmerkmal

Ein Entwicklungsmerkmal stellt eine entscheidungsrelevante Rahmenbedingung eines Entwicklungsprojekts dar. Sie kennzeichnet einen bestimmten Aspekt der Ausgangssituation, der einen Einfluss auf den Entwicklungsprozess und damit auch auf die ÆQualitätssicherung hat.

Entwicklungsphase

Es handelt sich hierbei um einen übergeordneten Begriff für einen definierten Abschnitt eines ÆEntwicklungsprozesses, der zeitlich und inhaltlich abgeschlossen ist. Zu diesen Phasen zählen z.B. Analyse, Design, Umsetzung, Integration und Test.

Entwicklungsprozess

Der Entwicklungsprozess stellt eine Menge von möglichst geordneten Schritten, die zur Erreichung eines bestimmten Ziels im Rahmen einer Produktentwicklung dienen, dar.

Entwicklungsstrang

Ein Entwicklungsprozess kann aus mehreren in sich abgeschlossenen Entwicklungssträngen bestehen, die in der Regel parallel ablaufen. Beispielsweise enthält der Entwicklungsprozess des 3-EbenenVorgehensmodells die Entwicklungsstränge für der Disziplinen Mechanik, Software und Elektronik.

Fehlerdatenbank

In einer Fehlerdatenbank findet die zentrale Verwaltung aller Fehlermeldungen, inklusive der Beschreibungen der Fehler, statt (Dokumentation).

Fehlverhalten

Unter Fehlverhalten bezeichnet man eine Abweichung vom Sollverhalten. Hier sind drei unterschiedliche Ausprägungen möglich: - Funktionsversagen, d.h. Versagen einer Funktionseinheit bei ihrer Ausführung - Funktionsunterlassung, d.h. Unterlassung einer erforderlichen Ausführung - Modifizierte Ausführung (z.B. Mehrfunktionalität)

Festlegung des Engineering-Modells

Es handelt sich um die Festlegung des Gesamtablaufs des Produktlebenszyklus und der anzuwendenden Entwicklungs- und QS-Maßnahmen in den einzelnen Phasen.

Firmware

Firmware ist Software, welche die Basisfunktionalität einer Rechenanlage zur Verfügung stellt und in der Regel auf Festspeichern (ROM, EPROM) abgelegt wird. Die Firmware wird beim Einschalten automa-

370

Anhang Glossar tisch geladen und ermöglicht es, weitere Softwarekomponenten von Datenträgern, wie z.B. Festplatte, zu laden. Als Beispiele sind das BIOS (Basic Input Output System) eines PCs und die Gerätesoftware von Peripheriekomponenten wie CD-ROMLaufwerk, Festplatte usw. zu nennen.

FMEA

FMEA (Failure Mode and Effect Analysis) ist die Analyse eines Systemdesigns hinsichtlich aller möglichen Fehlerquellen und deren Auswirkungen auf das Verhalten und die ÆSicherheit des ÆSystems.

Funktionstest

Der Funktionstest verfolgt das Hauptziel, Unstimmigkeiten zwischen dem Ist-Verhalten eines ÆTestobjekts und seinem spezifizierten Soll-Verhalten (ÆSpezifikation) aufzudecken. Der Funktionstest ist für gewöhnlich black-box-orientiert (ÆBlack-Box Test).

Glossar / Terminologie

Ein Glossar/Terminologie ist eine Liste von Begriffen und zugehörigen Begriffsdefinitionen sowie Abkürzungen. Wichtig sind ein angemessener Umfang und die Relevanz der Begriffe.

Hardware

Hardware ist die Menge aller technischen Geräte einer Rechenanlage. Zur Hardware zählen u.a. die Speicher, die Zentraleinheit, in Chips gegossene Schaltungen und die Verbindungsleitungen. Die Vorsilbe Hard verdeutlicht, dass es sich bei der Hardware um die physikalisch materiellen Teile und damit um unveränderbare und nicht kopierfähige Komponenten einer Rechenanlage handelt [10].

Hardware-in-theLoop (HIL)

HIL ist der Betrieb der realen Steuerung eines technischen ÆSystems (ÆHardware) im Verbund mit einer in ÆEchtzeit laufenden Umgebungssimulation, welche über die realen Schnittstellen an die Hardware gekoppelt ist. In die Umgebungssimulation können reale Komponenten integriert sein. Häufig wird auch in diesem Zusammenhang von der hardware-in-theloop Simulation (HILS) gesprochen.

Inbetriebnahmetest (für eine mechatronische Komponente)

Die Installationsfähigkeit einer Applikation wird in realen technischen Umgebungen anhand relevanter Betriebsszenarien getestet.

371 In-circuit-Emulation

In-Circuit-Emulatoren ersetzen den Mikroprozessor durch eine spezielle Ersetzen ÆHardware zur detaillierten Analyse der internen Programmabläufe unter Echtzeitbedingungen (Echtzeitmonitoring).

Inkrementelle Entwicklung

Inkrementelle Entwicklung ist die geplant zyklische Entwicklung eines ÆSystems, wobei nach jedem Zyklus ein Endergebnis mit vorher definierter Funktionalität vorliegt (ÆBaseline), das Basis für den nächsten Entwicklungsschritt ist. Das ÆPrototyping unterscheidet sich vom inkrementellen Entwickeln dadurch, dass Prototypen der Erkenntnissfindung dienen und eventuell weggeworfen werden.

Instrumentierung

Zur Analyse des Kontroll- und Datenflusses wird zusätzlicher Code (Zähler und Ausgaben) eingefügt.

Integration

Integration bedeutet lateinisch Wiederherstellung eines Ganzen. Es ist das Zusammenführen von Einzelteilen oder Komponenten zu einer Einheit oder einem ÆSystem.

Integrationsplan

Der Integrationsplan umfasst die zeitliche Planung der schrittweisen ÆIntegration.

Integrationstest

Durch den Integrationstest wird das Zusammenspiel von Systemkomponenten verifiziert. Getestete Komponenten werden schrittweise hinzugefügt bis das ÆSystem vollständig integriert ist. Eine inkrementelle Vorgehensweise (Top-Down, Bottom-Up, HardestFirst usw.) ist der nicht-inkrementellen Vorgehensweise (Big Bang) vorzuziehen.

IT-System

Ein IT-System ist ein Subsystem eines mechatronischen Systems bestehend aus Hardware- und Softwarekomponenten.

Kennzahl

Kennzahlen sind Zahlen, mit denen sich in universeller Form spezifische Eigenschaften von Vorgängen durch funktionale Zusammenhänge beschreiben lassen. Grundlage hierfür ist die Ähnlichkeitstheorie, nach der alle einen Vorgang beeinflussenden Größen zu (dimensionslosen) Kennzahlen zusammengefasst werden können.

372

Anhang Glossar

Komplexitäts- und Timing-Analyse

In der Designphase findet eine theoretische Ermittlung des Systemzeitverhaltens mit Hilfe der Komplexitäts-Analyse statt. Mit Hilfe der Timing-Analyse findet eine Messung des Zeitverhaltens direkt anhand des Systemverhaltens oder, falls erforderlich, mittels Instrumentierung oder Profiling statt.

Komponente

Eine Komponente ist ein Bestandteil eines Ganzen [24].

Komponentenebene

Die Komponentenebene ist die unterste Entwicklungsebene im 3-Ebenen-Vorgehensmodell, in der die ÆKomponenten der jeweiligen Disziplinen (Mechanik, HW, SW) arbeitsteilig realisiert werden. Auf der Komponentenebene findet demnach die eigentliche Realisierung der Komponenten statt.

Konkretisierer

Ein Konkretisierer ist eine (meist Software-) Komponente des ÆTestbetts, die unterschiedliche Abstraktionsebenen an den ÆSchnittstellen von ÆTestobjekt und dem Stimulusteil eines ÆTestfalls überbrückt. Häufig sind die Konkretisierer recht einfach, wie beispielsweise ein D/A-Wandler, der Ædiskrete Zahlenwerte im ÆStimulus in Eingabespannungen am Testobjekt übersetzt. Ein Konkretisierer kann aber auch komplexer sein und die Informationen im Stimuli mit Werten aus einer Datenbank oder aus der bisherigen Testdurchführung erweitern. Das Gegenstück zum Konkretisierer ist der ÆAbstrahierer.

Kontinuierliche Systeme

Ein kontinuierliches System ist ein ÆSystem bei dem die Signale (Funktionen oder Wertefolgen, die Informationen repräsentieren) stetig, d.h. zeitkontinuierlich und wertkontinuierlich sind.

Kritikalität

Die Kritikalität ist die Bedeutung eines Problems.

Lastenheft

Ein Lastenheft ist die Zusammenstellung aller ÆAnforderungen des ÆAuftraggebers hinsichtlich Lieferund Leistungsumfang. Im Lastenheft sind die ÆAnforderungen aus Anwendersicht einschließlich aller Randbedingungen zu beschreiben. Diese sollten quantifizierbar und prüfbar sein. Im Lastenheft wird definiert, was wofür zu lösen ist [66].

373 Leistungstest

Beim Leistungstest wird das ÆSystem gegen die nicht funktionalen ÆAnforderungen, wie z.B. Last, Datenmenge oder Zeitverhalten geprüft. (www.tuvit.de)

Mechatronik

Der ursprüngliche Begriff Mechatronik (engl. mechatronics) ist ein Kunstwort bestehend aus Mechanik und Elektronik. Mechatronik ist ein interdisziplinäres Gebiet der Ingenieurwissenschaften, das auf Maschinenbau, Elektrotechnik und Informatik aufbaut. Ihr Ziel ist die Verbesserung der Funktionalität und die räumliche Integration eines technischen Systems durch eine enge Verknüpfung/Verzahnung und synergetische Integration von mechanischen, elektronischen und informationsverarbeitenden Komponenten.

Metriken

Metriken umfassen die Definition, Erhebung und Interpretation von Maßzahlen zur Beschreibung von Qualitätseigenschaften von Produkten oder von ÆProzessen.

Model-in-the-Loop (MIL)

MIL ist die interpretierte Ausführung eines ÆModells der Steuerungssoftware, z.B. in Form eines ÆZustandsautomaten, im Verbund mit einer Umgebungssimulation.

Modell

Ein Modell ist ein vereinfachtes Abbild der Realität, welches erstellt wird, um Erkenntnisse über ein betrachtetes ÆSystem zu gewinnen. Im Kontext Æeingebetteter Software bezieht sich der Begriff häufig auf funktionale, am PC graphisch implementierte, ablauffähige Software-Spezifikationen. Ziel kann sowohl die Absicherung der ÆSpezifikation, die modellbasierte Codegenerierung oder die Æmodellbasierte Testfallgenerierung im Zuge des ÆModellbasierten Testens sein.

Modellbasierte Testfallgenerierung

Im Kontext der Entwicklung ÆEingebetteter Software ist die Modellbasierte Testfallgenerierung die rechnergestützte Ableitung von ÆTestfällen für ein ÆSystem auf der Grundlage eines ablauffähigen ÆModells dieses Systems. Das ÆModell ist dabei die Grundlage für die Berechnung des SollVerhaltens bei ÆSimulation des Systems. Die Menge der Stimulationen wird auf der Grundlage des ÆModells und voreingestellter Testgenerierungsdirektiven

374

Anhang Glossar (struktureller, funktionaler oder zufallsbasierter Art) automatisiert zusammengestellt.

Modellbasiertes Testen

Es handelt sich hierbei um den Vorgang der ÆModellbasierten Testfallgenerierung, der Testdurchführung sowie der Testauswertung (ÆTesten).

Modultest

Im Modultest werden Operationen und deren Zusammenspiel innerhalb eines Moduls unabhängig von der Systemumgebung getestet. Ausführungen sind sowohl als White-Box Test als auch als Black-Box Test möglich. Im Gegensatz zur klassischen Software-Technik wird hier unter Modul eine Komponente verstanden, die sowohl aus Software als auch aus ÆHardware bestehen kann.

Nichtdeterminismus

Der Nichtdeterminismus ist eine Eigenschaft eines ÆSystems, das bei gleichen Ausgangsbedingungen und gleichen Eingaben potentiell unterschiedliches Verhalten zeigt. Dieser Nichtdeterminismus kann im technischen Umfeld zu Problemen führen, da Ergebnisse nicht reproduzierbar sind. Beispielsweise wird das ÆTesten dieser Systeme erschwert.

Observer

Ein Observer ist ein Beobachter, ein Sonderfall eines Testautomaten, der keine Stimulation des Testobjekts vornimmt, sondern lediglich den Vergleich von Istund Sollwert der Reaktionen des Testobjekts durchführt. Mit Observern können mehrere Reaktionen für einen gegebenen Æ Stimulus akzeptiert werden.

Petrinetze

Ein Petrinetz ist eine graphische Beschreibung des dynamischen Verhaltens paralleler ÆSysteme. Im Gegensatz zu endlichen Automaten wird bei Petrinetzen der Gesamtzustand betrachtet.

Pflichtenheft

Das Pflichtenheft ist die Beschreibung der Realisierung aller ÆAnforderungen des Lastenheftes. Das Pflichtenheft enthält das ÆLastenheft. Im Pflichtenheft werden die Anwendervorgaben detailliert und die Realisierungsanforderungen beschrieben. Im Pflichtenheft wird definiert wie und womit die ÆAnforderungen zu realisieren sind.

Phasen- und Projektreview

Inhalt ist die Erfassung von aufgetretenen Problemen und der durchgeführten Gegenmaßnahmen sowie deren Bewertung. Erfolgreich eingesetzte Maßnahmen werden erfasst und bewertet. Ein Phasen- oder Pro-

375 jektreview findet projektintern statt und ist oft Teil des Projektabschlußberichts. Produkteigenschaften

ÆAnforderungen.

Programmierrichtlinien

Programmierrichtlinien sind bindende Regeln für die Implementierung. Beispiele sind Vorgaben für CodeLayout, Verwendung bestimmter Konstrukte, Kommentierung, Schachtelungstiefe von Funktionen, sowie Namensgebung. Unternehmensweite Programmierrichtlinien können durch projektspezifische ergänzt bzw. präzisiert werden.

Projekt

Ein Projekt ist ein Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist [52]. Beispiele sind - Zielvorgabe - zeitliche, finanzielle, personelle oder andere Begrenzungen - Abgrenzung gegenüber anderen Vorhaben

Prototyp

Ein Prototyp ist eine ausführbare und evaluierbare Version eines ÆSystems oder Systemteil um ausgewählte Merkmale des späteren operationellen Systems zu evaluieren.

Prototyping

Ein Prototyp ist ein experimentelles Muster eines ÆSystems, einer Systemkomponente oder einer (Teil-)Funktion. Prototypen erfüllen nicht alle ÆAnforderungen an Vollständigkeit, ÆZuverlässigkeit und ÆSicherheit.

Prozess

Ein Prozess ist eine Folge von Aktivitäten mit eventuell parallelen und alternativen Aktivitäten, die Eingangsdaten in Ausgangsdaten transformieren. Die einzelnen Aktivitäten werden gegebenenfalls hierarchisch weiter zerlegt.

Q-Berichterstattung

Die Q-Berichterstattung ist die Erstellung von Qualitätsberichten zu festgesetzten Terminen (z.B. zu Meilensteinen). Sie beinhaltet den Stand der QSAufgaben, den Stand der Planungen und eine QSBewertung des ÆProjekts (ÆProzess und ÆProdukt; ggf. mit Verbesserungsvorschlägen). QSBerichterstattung kann im Rahmen der Projektberichterstattung erfolgen.

376

Anhang Glossar

QS-Handbuch (unternehmensspezifisch)

Das QS-Handbuch enthält unternehmensweite Richtlinien für ablauf- und aufbauorganisatorische Maßnahmen zur ÆQualitätssicherung. Die Maßnahmen müssen sich an den Qualitätsanforderungen an die ÆProdukte und an den Qualitätszielen orientieren. Für eine projektspezifische Anpassung eines QSHandbuchs sind entsprechende Regeln zu erarbeiten.

QS-Handbuch (projektspezifisch)

Bei der Erstellung des projektspezifischen QSHandbuchs erfolgt die Konkretisierung und Anpassung des unternehmensweiten QS-Handbuches an die projektspezifischen ÆAnforderungen, sinnvollerweise durch Tayloring des im allgemeinen QS-Handbuch beschriebenen ÆVorgehensmodells. Das QSHandbuch ist Teil der Projektdokumentation.

QS-Maßnahmenmerkmal (QSM-Merkmal)

Ein QSM-Merkmal ist eine Eigenschaft zum Erkennen oder Unterscheiden von QS-Maßnahmen.

Qualität

Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines ÆProdukts oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse bezieht [53].

Qualitätsmanagement

Qualitätsmanagement sind alle Tätigkeiten der Gesamtführungsaufgabe, welche die Qualitätspolitik, Ziele und Verantwortungen festlegen sowie diese durch Mittel wie ÆQualitätsplanung, Qualitätslenkung, ÆQualitätssicherung und Qualitätsverbesserung im Rahmen des Qualitätsmanagementsystems verwirklichen [21].

Qualitätsmerkmal

Ein Qualitätsmerkmal ist eine Eigenschaft eines ÆProdukts oder ÆProzesses, anhand derer ihre Qualität beschrieben und beurteilt wird.

Qualitätsplanung

Die Aufgabe der Qualitätsplanung ist es, die für das ÆProjekt anwendbaren Qualitäts-Ziele, QualitätsAnforderungen und -Vorgaben zu ermitteln und zu planen, wie diese durch qualitätssichernde Maßnahmen erfüllt werden können.

Qualitätsplanung für den Entwicklungsprozess

Inhalt ist die Definition der Qualitätsanforderungen an einen ÆProzess anhand von ÆQualitätsmerkmalen und ihren Ausprägungen, sinnvollerweise in Abhängigkeit von der geforderten Produktqualität. Es

377 handelt sich um den ersten Schritt der Planung der ÆQualitätssicherung. Qualitätssicherung (QS)

QS ist die Gesamtheit von angemessenen, aufeinander abgestimmten Maßnahmen zur Erfüllung vorgegebener ÆAnforderungen an die Qualität eines ÆProdukts oder Herstellungsprozesses [33].

Qualitätssicherungsmaßnahme (QSM)

Eine QSM ist eine 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 Qualitätssicherungsmaßnahme als Festlegung und Anwendung geeigneter Methoden, Verfahren und Werkzeuge zur Erreichung vorgegebener Ziele aufgefasst werden [17].

Randbedingungen

Randbedingungen sind technische und organisatorische Vorgaben, die im Rahmen der Systemerstellung zu berücksichtigen sind. Randbedingungen können Entwurfsentscheidungen vorwegnehmen oder eingrenzen.

Regressionstest

Der Regressionstest wird zum Test von funktionalen Erweiterungen bzw. Fehlerbehebungsmaßnahmen eingesetzt. Beim Regressionstest werden Testfälle aus vorausgegangenen Testphasen wiederverwendet. Dadurch kann überprüft werden, ob die aufgetretenen Fehler korrekt behoben wurden und ob bereits abgetestete Funktionen nach Änderungen/ Erweiterungen weiterhin spezifikationskonform arbeiten (Seiteneffekte).

Ressourcen

Als Ressourcen wird die Gesamtheit der vorhandenen Hilfsmittel (Geldmittel, Rohstoffe, Energie, Maschinen etc.) und Personen bezeichnet, die vorhanden sind um eine bestimmte Aufgabe zu erfüllen.

Review und Inspektion

Beim Review wird ein Dokument durch eine Gruppe von Personen gemeinsam geprüft. Der Personenkreis besteht typischerweise aus einem Moderator, dem Autor, einem Protokollanten und Gutachtern. Identifizierte Schwächen werden durch den Autor behoben. Inspektionen weisen einen höheren Formalisierungsgrad als Reviews auf.

378

Anhang Glossar

Risikoanalyse

In der Risikoanalyse wird untersucht, wie wahrscheinlich es ist, dass eine der ermittelten Bedrohungen eintritt und wie hoch der dabei entstehende Schaden ist. Das Risiko wird aus der Eintrittswahrscheinlichkeit und der zu erwartenden Schadenshöhe ermittelt.

Risikomanagement

Risikomanagement beschäftigt sich mit der Identifikation von Risikoelementen, dem Abschätzen von Schadenswahrscheinlichkeit und Schadensausmaß, der Gewichtung von Risiken unter Einbeziehung von Schadenswahrscheinlichkeit und Schadensausmaß (Risikoanalyse), der Planung und Durchführung von Gegenmaßnahmen sowie der regelmäßigen Neubewertung von Risiken.

Rolle

Eine Rolle ist die Beschreibung einer Menge von Aufgaben und Verantwortlichkeiten im Rahmen eines ÆProjektes oder einer Organisation und muss mindestens einer Person zugeordnet werden.

SA/SD

Strukturierte Analyse (SA) und Strukturiertes Design (SD) sind funktionsorientierte Methoden für die ÆAnforderungsanalyse und den Systementwurf. Ein ÆSystem wird in hierarchisch strukturierte Funktionseinheiten (ÆProzesse, „bubbles“) zergliedert.

Schnittstelle

Eine Schnittstelle ist ein gedachter oder tatsächlicher Übergang an der Grenze zwischen zwei Funktionseinheiten mit vereinbarten Regeln für die Übergabe von Daten oder ÆSignalen.

Schnittstellentest

Ein Schnittstellentest ist die Prüfung der Daten- und Signalschnittstellen auf Fehlerfreiheit der Übertragung und des korrekten Inhaltes der übertragenen Information (z.B. Protokolltest).

Schreibtischtest

Ein oder mehrere Prüfer erhalten ein Dokument vom Autor, prüfen es kritisch und geben es mit Anmerkungen zurück. Die Korrektur von entdeckten Fehlern erfolgt durch den Autor. Schreibtischtests sind eher informeller Natur.

SDL (Specification and Description Language)

Die SDL ist eine Beschreibungssprache für ÆSysteme, die aus kommunizierenden ÆProzessen bestehen. Diese können sowohl in grafischer als auch in textueller Form beschrieben werden. Ein ÆProzess ist dabei im wesentlichen ein erweiterter endlicher

379 ÆZustandsautomat, der mit anderen Automaten über Signale kommuniziert. Sequenzdiagramme

Sequenzdiagramme sind ein grafisches Darstellungsmittel um den zeitlichen Ablauf der Kommunikation zwischen Objekten darzustellen. Varianten von Sequenzdiagrammen sind in gebräuchlichen Beschreibungssprachen (z.B. UML) enthalten.

Sicherheit

Zustand, in dem das Risiko eines Personen- oder Sachschadens auf einen annehmbaren Wert begrenzt ist [13]. Sicherheit berücksichtigt ÆAnforderungen nach Safety (Funktionssicherheit) und Security (Zugriffssicherheit). Nach IEC 61508 wird die Funktionssicherheit in SIL-Stufen (SIL 1 - SIL 4) eingeteilt.

Simulation

Eine Simulation ist das Nachbilden eines ÆSystems mit seinen dynamischen ÆProzessen in ein experimentiergeeignetes ÆModell, um zu Erkenntnissen über die Wirklichkeit zu gelangen. Im Gegensatz zur ÆEmulation können auch Dinge simuliert werden die nicht real existent sind und deren Gesetzmäßigkeiten nicht vollständig bekannt sind.

Simulation zu Testzwecken

Zu Testzwecken werden die ÆKomponenten (SW, HW und Mechanik) und/oder die Systemumgebung nachgebildet.

Simulation zur Anforderungsbzw. Entwurfsabsicherung

Es wird ein ÆModell des zu entwickelnden ÆSystems entworfen, das in den zu untersuchenden Aspekten dem Zielsystem möglichst nahe kommt. Dieses ÆModell wird mit geeigneten Mitteln auf einem Rechner ablauffähig gemacht, um sein Verhalten unter verschiedenen Bedingungen zu beobachten.

Simulator

Ein Simulator ist ein Gerät oder Programm mit dem die ÆSimulation durchgeführt werden kann.

Softwareintensives Produkt

Es handelt sich hierbei um ÆProdukte, bei denen die Æeingebettete Software die kritische ÆKomponente der Produktentwicklung bzw. des Produkterfolgs eines Unternehmens darstellt. Kennzeichnend dafür können der hohe Anteil der eingebetteten Software an den Produktentwicklungskosten, aber ebenso der Anteil von in Software realisierten Funktionen, insbesondere solcher, die zur Wertschöpfung des ÆProdukts beitragen, sein

380

Anhang Glossar

Software-in-the-Loop (SIL)

SIL ist Ausführung der Steuerungssoftware eines technischen Systems (ÆSoftware) im Verbund mit einer Umgebungssimulation auf einem Host-Rechner, d.h. nicht der Zielhardware (ÆHIL). Dies kann entweder durch Compilieren der ÆSoftware für das Hostsystem oder durch Einsatz eines SoftwareÆEmulators geschehen.

Spezifikation

Die Spezifikation ist die Summe der Informationen, welche in ihrer Gesamtheit die ÆAnforderungen, den Entwurf, das Verhalten oder andere charakteristische Merkmale eines ÆSystems beschreiben [9].

Spezifikationsfehler

Spezifikationsfehler sind Abweichungen zwischen den in der Spezifikation beschriebenen ÆAnforderungen und dem, was der ÆAuftraggeber eigentlich haben wollte. Diese Art von Fehler wird meist erst in den späten Systemintegrationsphasen entdeckt. Die Ursache kann unter anderem in falschen Vorgaben, ungenauen Angaben, vielfältig interpretierbaren Formulierungen oder fehlender Quantifizierung liegen.

Stimulus, Stimulation

Ein Stimulus ist die geplante Erregung eines ÆTestobjekts um hierdurch eine Reaktion hervorzurufen.

Stresstest

Es wird die Reaktion eines ÆSystems auf außergewöhnlich hohe Belastungen von Systemressourcen (z.B. Rechenzeit, Stack, Speicher) getestet.

Subsystemebene

In der Subsystemebene des 3-EbenenVorgehensmodells werden die in der ÆSystemebene erarbeiteten Teilsysteme (=Subsysteme) weiter konkretisiert. Auf dieser Ebene besteht bereits eine Arbeitsteilung zwischen Mechanik und IT. Die ITSubsysteme werden hier im Rahmen des IT-Entwurfs weiter in SW- und HW-Subsysteme aufgeteilt.

SW-Architekturentwurf

Ein SW-Architekturentwurf ist die Zergliederung des Gesamtsystems in ÆKomponenten. Beschrieben wird sowohl die statische Struktur als auch das dynamische Verhalten des SW-Subsystems.

Synchronisationpunkt

Ein Synchronisationspunkt stellt eine Abhängigkeit der Ergebnisse verschiedener Entwicklungsstränge dar, die zur Abstimmung zwingen. Dies wird oftmals realisiert als vereinbarter Zeitpunkt im Entwicklungsprozess, an dem an Hand von festgelegten Kriterien das einwandfreie Zusammenwirken der bis dato ent-

381 standenen Entwicklungsergebnisse der einzelnen ÆEntwicklungsstränge überprüft wird. Im Gegensatz zu einem ÆMeilenstein ist nicht der Termin die bindende Größe, sondern die Abhängigkeit zwischen Entwicklungsergebnissen. Eine Abstimmung kann demnach auch über einen längeren Zeitraum laufen. System

Ein System ist ein beliebiger Gegenstand des Denkens, der gegenüber der Umgebung abgrenzbar (ÆSystemgrenze) ist. Jedes System besitzt bestimmte Funktionen sowie bestimmte Eigenschaften und setzt diese zueinander in Beziehung. Fast jeder Ausschnitt der Realität kann als ein System angesehen werden, z.B. ein Unternehmen, die Gesellschaft oder eine Maschine.

Systemebene

Die System-Ebene ist die oberste Ebene in dem 3Ebenen-Vorgehensmodell. Hier wird das ÆSystem ausgehend von den ÆAnforderungen analysiert und ein erster abstrakter System-Entwurf erstellt. Dabei wird das System in Mechanik- und IT-Subsysteme unterteilt.

Systemgrenze

Es handelt sich hierbei um die Grenze des ÆSystems gegenüber seiner Umwelt, mit der es über ÆSchnittstellen Materie, Energie und Information (Ein- und Ausgangsgrößen) austauschen kann.

Systemtest

Der Systemtest sichert ab, ob das entwickelte ÆSystem oder Teile davon den in den funktionalen und technischen ÆSpezifikationen festgelegten ÆAnforderungen entspricht.

Systemzustand

Der Systemzustand ist die Summe der Zustände aller Systemkomponenten zu einem gegebenen Zeitpunkt. Er ist die Beschreibung einer zeitpunktbezogenen Situation eines ÆSystems.

Testabdeckung

Die Testabdeckung ist ein Maß, das angibt, wie viel Prozent der ÆAnforderungen durch die zugeordneten ÆTestfälle überprüft werden.

Testabdeckungsmatrix

Es findet eine Zuordnung von Testfällen zu ÆAnforderungen in einer zweidimensionalen Matrix statt. Das Abdeckungsmaß gibt an, wie viel Prozent der ÆAnforderungen durch die zugeordneten Testfälle überprüft werden.

382

Anhang Glossar

Testautomat

Ein Testautomat ist über ein ÆTestbett mit dem ÆTestobjekt verbunden. Der Testautomat führt die ablauffähigen Testfälle aus und stimuliert und beobachtet hierbei das ÆTestobjekt. Anhand des Soll/Ist-Vergleichs aus den Reaktionen des ÆTestobjekts wird das ÆTestergebnis bestimmt.

Testbett

Das Testbett übernimmt die Kopplung zwischen ÆTestautomat und ÆTestobjekt. Alle erforderlichen ÆSchnittstellen, die für das ÆTestobjekt und den ÆTestautomaten notwendig sind, werden bereitgestellt. Aus Sicht des ÆTestobjekts ergibt sich hierbei kein Unterschied zwischen dem Signalaustausch mit der realen Umgebung und der Einbindung im Testbett.

Testen

Unter Testen versteht man den ÆProzess des Planens, der Vorbereitung, der Durchführung und der Auswertung, mit dem Ziel, Fehler des ÆTestobjekts zu finden.

Testfall

Ein Testfall beschreibt die Stimulation und die erwartete Reaktion eines ÆTestobjekts in ihrer zeitlichen Abfolge unter Berücksichtigung des ÆTestziels.

Testfallspezifikation

Die Spezifikation ist die Summe der Informationen, welche in ihrer Gesamtheit die ÆAnforderungen, den Entwurf, das Verhalten oder andere charakteristische Merkmale eines ÆTestfalls beschreiben.

Testobjekt

Beim Testobjekt handelt es sich um das zu überprüfende Objekt.

Testprozess

Der Testprozess beschreibt den Inhalt, die Phasen, die Dokumente und Objekte, die mit dem Testen zusammenhängen und bringt diese in eine sinnvolle Beziehung zueinander.

Testziel

Das Testziel ist eine festgelegte Menge von Eigenschaften, die als messbare Qualitätsziele in der Spezifikations- und Entwurfsphase festgelegt werden. Beim Testen müssen Testziele benannt werden. Sie sind so zu beschreiben, dass ihr Erreichen realistisch gemessen werden kann.

UML

Die UML (Unified Modeling Language) ist seit Mitte der 90er Jahre der de-facto Standard für die Darstellung von objektorientierten ÆModellen. Sie ist eine

383 visuelle Sprache und stellt eine Sammlung verschiedener Diagrammtypen zur Modellierung verschiedener Aspekte zur Verfügung. Unabhängige Testgruppen (-personen)

Tests werden nicht vom Entwickler selbst durchgeführt.

Validation

Unter Validation wird der ÆProzess zur Beurteilung eines ÆSystems oder einer ÆKomponente verstanden mit dem Ziel festzustellen, ob der Einsatzzweck oder die Benutzererwartungen erfüllt werden. Funktionsvalidation ist demnach die Prüfung, ob die ÆSpezifikation die Benutzeranforderungen erfüllt, ob überhaupt die Benutzerakzeptanz durch eine Funktion erreicht wird [59].

Variante

Varianten sind zeitlich parallel existierende, vergleichbare Ausprägungen ein und desselben Erzeugnisses bzw. Ergebnisses und damit potentiell gegeneinander austauschbar. Die Verwendung der Alternativen hängt vom konkreten Anwendungsfall ab.

Verfahrensaudit

Ein Verfahrensaudit ist die Überprüfung der Einhaltung von vereinbarten Regeln und Richtlinien durch unabhängige Prüfer, sowie Hinterfragen der Regeln und Richtlinien selbst.

Verifikation

Unter Verifikation wird der ÆProzess zur Beurteilung eines ÆSystems oder einer ÆKomponente verstanden mit dem Ziel festzustellen, ob die Resultate einer gegebenen ÆEntwicklungsphase den Vorgaben für diese Phase entsprechen. Software-Verifikation ist demnach die Prüfung, ob eine Implementierung der für den betreffenden Entwicklungsschritt vorgegebenen Spezifikation genügt [59].

Version

Versionen sind zeitlich nacheinander entstehende, vergleichbare Arbeitsergebnisse bzw. Entwicklungsstufen einer Aufgabe oder eines Erzeugnisses. Eine neuere Version ersetzt meistens eine ältere Version, geht durch Veränderung oder Weiterentwicklung aus dieser hervor und stellt in der Regel eine Verbesserung dar.

384

Anhang Glossar

Versions- und Konfigurationsmanagement

Versions- und Konfigurationsmanagement ist die strukturierte, nachvollziehbare Verwaltung und Archivierung von Versionen und Varianten sowie des Status von Dokumenten. In einer Konfiguration werden alle (in der betreffenden Variante) zugehörigen Elemente gemeinsam verwaltet. Versionierung ist die Erfassung aller Änderungen und ihres zeitlichen Zusammenhangs.

Virtuelle Welt (virtuell)

Die Virtuelle Welt ist die vom Computer simulierte Wirklichkeit [24].

virtueller Funktionstest

Methode zur Durchführung von Systemtests aus Sicht des Kunden bereits vor der Existenz des realen, vollständig integrierten ÆTestobjekts, wobei fehlende ÆKomponenten durch Ævirtuelle Komponenten ersetzt werden.

Vorgehensmodell

Ein Vorgehensmodell unterteilt ein Entwicklungsvorhaben in einzelne Aktivitäten einschließlich ihrer logischen Abfolge und regelt die Verantwortlichkeiten der beteiligten Personen (Rollen). Vorgehensmodell geben eine Antwort auf die Frage: „Wer macht was wann in einem Entwicklungsprojekt?“

Walkthrough

Manuelle, informale Prüfmethode. Der Autor präsentiert das Dokument in einer Sitzung den Gutachtern. Die Gutachter stellen spontane Fragen. Eine Überarbeitung des Prüfobjektes nach einem Walkthrough erfolgt durch den Autor. Im Gegensatz zum Review agiert der Autor selbst als Moderator.

White-Box Test

Beim White-Box Test wird ein Prüfling unter Ausnutzung der Kenntnisse des internen Aufbaus gegen die Spezifikation getestet. Dies geschieht beispielsweise kontroll- oder datenflussorientiert.

Wiederverwendung von Projektergebnissen

Existierende Projektergebnisse (z.B. Dokumente, Programmcode) werden vollständig oder auszugsweise übernommen. Dabei werden sie überprüft und ggf. angepasst. Wiederverwendung muss bereits bei der Ersterstellung eingeplant werden.

Zustand

Ein Zustand ist die Gesamtheit der Größen eines ÆSystems bzw. einer ÆKomponente, die es zu jedem Zeitpunkt in seinen Eigenschaften und seinem Verhalten eindeutig beschreiben.

385 Zustandsautomat

Ein Zustandsautomat ist ein Mittel zur Beschreibung des Verhaltens von ÆKomponenten und ÆSystemen als eine zeitliche Folge von Zuständen. Formal besteht ein Zustandsautomat aus einem Zustandsraum S, einer Übergangsrelation R: S x S, die die möglichen Zustandsübergänge beschreibt, und (mindestens) einem initialen Zustand.

Zuverlässigkeit

Zuverlässigkeit ist eine Menge von Eigenschaften, die sich auf die Fähigkeit des ÆSystems auswirken, sein Leistungsniveau unter festgelegten Bedingungen über einen festgelegten Zeitraum zu bewahren.