examen.press ist eine Reihe, die Theorie und Praxis aus allen Bereichen der Informatik für die Hochschulausbildung vermittelt.

examen.press

examen.press ist eine Reihe, die Theorie und Praxis aus allen Bereichen der Informatik für die Hochschulausbildung vermittelt.

Dirk W. Hoffmann Software-Qualität 123

Prof. Dr. Dirk W. Hoffmann Hochschule Karlsruhe Fakultät für Informatik Moltkestrasse 30 76133 Karlsruhe dirk.hoffmann@hs-karlsruhe.de ISBN 978-3-540-76322-2 e-isbn 978-3-540-76323-9 DOI 10.1007/978-3-540-76323-9 ISSN 1614-5216 Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. 2008 Springer-Verlag Berlin Heidelberg Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung 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 zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Einbandgestaltung: KünkelLopka Werbeagentur, Heidelberg Gedruckt auf säurefreiem Papier 987654321 springer.com

Vorwort Computerabstürze, Rückrufaktionen, Sicherheitslecks: Das Phänomen Software- Fehler hat sich zum festen Bestandteil unseres täglichen Lebens entwickelt. Mit dem unaufhaltsamen Vordringen der Computertechnik in immer mehr sicherheitskritische Bereiche ist die Software-Qualitätssicherung zu einer tragenden Säule der gesamten Informationstechnik herangereift. Doch warum ist die Qualität vieler Software-Systeme heute eigentlich so schlecht? Und viel wichtiger noch: Stehen wir der Misere hilflos gegenüber? Auf den folgenden Seiten werde ich versuchen, eine Antwort auf die oben gestellten Fragen zu geben. Neben einer Ursachenanalyse historischer Software- Fehler werden die verschiedenen Methoden und Techniken diskutiert, die uns heute zur Erreichung der kontinuierlich wachsenden Qualitätsanforderungen zur Verfügung stehen. Ein besonderes Augenmerk habe ich dabei stets auf große, langlebige Software-Systeme gelegt, die in einem professionellen Umfeld entwickelt werden. Die hierfür erforderlichen technischen und organisatorischen Maßnahmen werden in diesem Buch genauso behandelt wie die allgegenwärtige Problematik der Software-Alterung. Zwei Leitmotive durchdringen die nachfolgenden Kapitel wie ein roter Faden. Zum einen habe ich mich bemüht, einen durchweg praxisnahen Zugang zu den oft theoretisch geprägten Themen zu schaffen. So werden die verschiedenen Methoden und Verfahren stets anhand konkreter Problemstellungen eingeführt und daraufhin untersucht, inwieweit sie für den produktiven Einsatz in der professionellen Software-Entwicklung geeignet sind. Zum anderen war es mir ein großes Anliegen, ein tiefergehendes Problembewusstsein für die Materie Software zu schaffen. Hierzu werden anhand zahlreicher Beispiele die klassischen Ursachen und Fallstricke aufgezeigt, die in der Praxis für viele Software-Fehler verantwortlich zeichnen. Auch hier gilt: Nur wer seine Feinde kennt, wird im Stande sein, sie zu besiegen. In diesem Sinne wünsche ich Ihnen viel Vergnügen bei der Lektüre dieses Buches. Leider ist das Phänomen des Fehlers allgegenwärtig und macht auch vor Manuskripten keinen Halt. Für Hinweise oder Verbesserungsmöglichkeiten bin ich jedem aufmerksamen Leser ausdrücklich dankbar. v

vi Vorwort Bevor wir endgültig in die Tiefen der verschiedenen Methoden und Verfahren der Software-Qualitätssicherung eintauchen, möchte ich an dieser Stelle all denjenigen meinen Dank aussprechen, die mich bei der Durchführung dieses Projekts unterstützt und damit maßgeblich zum Gelingen dieses Buches beigetragen haben. Karlsruhe, im November 2007 Prof. Dr. Dirk W. Hoffmann

Inhaltsverzeichnis 1 Einführung... 1 1.1 Aufbruch in das ubiquitäre Computerzeitalter... 1 1.2 Was ist Software-Qualität?..... 6 1.3 Warum ist Software eigentlich so schlecht?..... 12 1.4 Gibt es Licht am Ende des Tunnels?... 19 1.4.1 Produktqualität.... 19 1.4.2 Prozessqualität.... 25 2 Software-Fehler... 27 2.1 Lexikalische und syntaktische Fehlerquellen.... 27 2.2 Semantische Fehlerquellen..... 36 2.3 Parallelität als Fehlerquelle.... 41 2.4 Numerische Fehlerquellen..... 43 2.5 Portabilitätsfehler... 45 2.6 Optimierungsfehler... 49 2.7 Von tickenden Zeitbomben..... 51 2.8 Spezifikationsfehler... 55 2.9 Nicht immer ist die Software schuld...... 57 2.10 Fehlerbewertung.... 61 3 Konstruktive Qualitätssicherung... 65 3.1 Software-Richtlinien...... 65 3.1.1 Notationskonventionen...... 66 3.1.2 Sprachkonventionen.... 73 3.2 Typisierung.... 76 3.2.1 Typsysteme... 77 3.2.2 Grenzen der Typisierung..... 81 3.3 Vertragsbasierte Programmierung.... 93 3.3.1 Vor- und Nachbedingungen... 93 3.3.2 Invarianten... 95 3.3.3 Zusicherungen.... 96 vii

viii Inhaltsverzeichnis 3.4 Fehlertolerante Programmierung..... 98 3.4.1 Software-Redundanz... 98 3.4.2 Selbstüberwachende Systeme...... 101 3.4.3 Ausnahmebehandlung...105 3.5 Portabilität..... 107 3.5.1 Portabilität auf Implementierungsebene...110 3.5.2 Portabilität auf Sprachebene...131 3.5.3 Portabilität auf Systemebene...134 3.6 Dokumentation..... 141 3.6.1 Spezifikationsdokumente..... 142 3.6.2 Implementierungsdokumente...... 149 4 Software-Test...157 4.1 Motivation.....157 4.2 Testklassifikation.... 158 4.2.1 Prüfebenen...159 4.2.2 Prüfkriterien...... 170 4.2.3 Prüftechniken..... 173 4.3 Black-Box-Testtechniken...... 175 4.3.1 Äquivalenzklassentest...175 4.3.2 Grenzwertbetrachtung...180 4.3.3 Zustandsbasierter Software-Test.... 183 4.3.4 Use-Case-Test..... 186 4.3.5 Entscheidungstabellenbasierter Test..... 190 4.3.6 Paarweises Testen...... 192 4.3.7 Diversifizierende Verfahren...198 4.4 White-Box-Testtechniken...... 200 4.4.1 Kontrollflussmodellierung.... 202 4.4.2 Anweisungsüberdeckung..... 206 4.4.3 Zweigüberdeckung..... 209 4.4.4 Pfadüberdeckung...... 210 4.4.5 Bedingungsüberdeckung..... 214 4.4.6 McCabe-Überdeckung...216 4.4.7 Defs-Uses-Überdeckung..... 220 4.4.8 Required-k-Tupel-Überdeckung...227 4.5 Testmetriken...231 4.5.1 Überdeckungsmetriken...... 231 4.5.2 Mutationstest...... 238 4.6 Grenzen des Software-Tests....243 5 Statische Code-Analyse...247 5.1 Software-Metriken...247 5.1.1 LOC und NCSS...249 5.1.2 Halstead-Metriken..... 251 5.1.3 McCabe-Metrik...259

Inhaltsverzeichnis ix 5.1.4 Objektorientierte Metriken...262 5.1.5 Visualisierung von Messwerten....267 5.2 Konformitätsanalyse...... 271 5.2.1 Syntax-Analyse.... 272 5.2.2 Semantik-Analyse..... 281 5.3 Exploit-Analyse..... 300 5.3.1 Buffer Overflows...... 301 5.3.2 Gegenmaßnahmen..... 306 5.4 Anomalienanalyse...313 5.4.1 Kontrollflussanomalien...... 313 5.4.2 Datenflussanomalien...315 5.5 Manuelle Software-Prüfung....321 5.5.1 Walkthroughs..... 323 5.5.2 Reviews.....324 5.5.3 Inspektionen......327 6 Software-Verifikation...333 6.1 Motivation.....333 6.2 Deduktion......338 6.2.1 Vor- und Nachbedingungen...338 6.2.2 Das Hoare-Kalkül...... 342 6.3 Modellprüfung......350 6.3.1 Temporallogik..... 352 6.3.2 Verifikation temporaler Eigenschaften...356 6.4 Abstrakte Interpretation...361 6.4.1 Fixpunktiteration nach Floyd, Park und Clarke.....362 6.4.2 Datenabstraktion...367 7 Software-Lebenszyklus...371 7.1 Wenn Software altert...... 371 7.2 Gründe der Software-Alterung...373 7.2.1 Bewegliche Ziele...... 373 7.2.2 Auch Software setzt an......380 7.2.3 Kaschieren statt Reparieren...385 7.2.4 Rückwärtskompatibilität..... 389 7.2.5 Wissen ist flüchtig.....391 7.3 Ist die Software-Alterung unumgänglich?...... 395 7.3.1 Refactoring...396 7.3.2 Redesign.... 407 8 Software-Infrastruktur...415 8.1 Versionsverwaltung...417 8.1.1 Anforderungen und Konzeption....419 8.1.2 Revisionen...423 8.1.3 Entwicklung in großen Teams...... 428

x Inhaltsverzeichnis 8.1.4 Algorithmische Grundlagen der Versionskontrolle...443 8.2 Build-Automatisierung.... 450 8.2.1 Bedingte Compilierung...... 450 8.2.2 Verteilte Compilierung...463 8.3 Testautomatisierung...... 468 8.3.1 Regressionstests...468 8.3.2 Oberflächentests...472 8.4 Defektmanagement...477 8.4.1 Fehlerdatenbanken..... 477 8.4.2 Crash Reports..... 485 9 Managementprozesse...491 9.1 Vorgehensmodelle...493 9.1.1 Wasserfallmodell...... 493 9.1.2 V-Modell.... 496 9.1.3 Rational Unified Process..... 502 9.1.4 Extreme Programming...506 9.2 Reifegradmodelle...514 9.2.1 Historische Entwicklung..... 515 9.2.2 CMM...519 9.2.3 CMMI......530 9.2.4 ISO 15504 (SPICE)....535 9.2.5 Bewertung und Kritik...540 Literaturverzeichnis...547 Sachverzeichnis...557

Abkürzungsverzeichnis ACM ACQ ALU ANSI API ARC ASCII BCD BDD BIOS BP BSD BSS CAN CIFS CIL CISC CLI CM CMM CMMI CPU CRC CTL CV CVS DIN DOI DOS DVD ENG Association for Computing Machinery Aquisition Process Group Arithmetic Logic Unit (Arithmetisch-logische Einheit) American National Standards Institute Application Programming Interface Appraisal Requirements for CMM American Standard Code for Information Interchange Binary Coded Decimal Binary Decision Diagram Basic Input Output System Base Pointer Berkeley Software Distribution Blank Storage Space Controller Area Network Common Internet File System Common Interface Language Complex Instruction Set Computing Command Line Interface oder Common Language Infrastructure Configuration Management Capability Maturity Model Capability Maturity Model Integration Central Processing Unit Cyclic Redundancy Check Computation Tree Logic Class Variables (Metrik) Concurrent Versions System Deutsches Institut für Normung Depth Of Inheritance (Metrik) Disc Operating System oder Denial of Service Digital Versatile Disc Engineering Process Group xi

xii Abkürzungsverzeichnis EOF End Of File ESA European Space Agency FIFO First In First Out FP Frame Pointer FPU Floating Point Unit GB Gigabyte (10 9 ) GByte Gigabyte (10 9 ) GiB Gigabyte (2 30 ) GHz Gigahertz GCC Gnu Compiler Collection ggt größter gemeinsamer Teiler GNU Gnu is Not Unix GPL GNU General Public License GTO Geotransfer Orbit GUI Graphical User Interface HOL Higher-Order Logic HW Hardware Hz Hertz IDE Integrated Development Environment IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers I/O Input/Output IP Intellectual Property oder Internet Protocol IPD Integrated Product Development IPPD Integrated Product and Process Development ISO International Organization for Standardization ISR Interrupt Service Routine IT Information Technology IVT Intel Virtualization Technology JDK Java Development Kit JIT Just-In-Time (Compiler) JNI Java Native Interface KPA Key Process Area KB Kilobyte (10 3 ) KByte Kilobyte (10 3 ) KiB Kilobyte (2 10 ) KHz Kilohertz LALR LookAhead Left to right Rightmost derivation (parser) LCOM Lack of COhesion in Methods (Metrik) LGT Längste gemeinsame Teilfolge LIFO Last In First Out LOC Lines Of Code LSF Load Sharing Facility LTL Linear Time Logic MB Megabyte (10 6 )

Abkürzungsverzeichnis xiii MByte Megabyte (10 6 ) MiB Megabyte (2 20 ) MHz Megahertz MFLOPS Million Floating Point Operations per Second MIPS Million Instructions per Second MISRA Motor Industry Software Reliability Association MMX Multimedia Extension MOST Media Oriented Systems Transport MSDN Microsoft Developer Network MTBF Mean Time Between Failures MULTICS MULTiplexed Information and Computing Service MVFS MultiVersion File System NCSS Non-Commented Source Statements NFS Network File System NOA Number of Attributes (Metrik) NOD Number of Descendants (Metrik) NORM Number of Redefined Methods (Metrik) NOP NO Operation OPE Operation Process Group OS Operating System OV Object Variables (Metrik) PAC Process Area Category PC Personal Computer oder Program Counter PDA Personal Digital Assistant PDF Portable Document Format PIM Process Improvement Process Group POSIX Portable Operating System Interface QA Quality Assurance QMMG Quality Management Maturity Grid RAID Redundant Array of Independent Disks RAM Random Access Memory RCS Revision Control System REC Receive Error Counter ROM Read-Only Memory REQM Requirements Management RET Return (address) REU Reuse Process Group RIN Ressource and Infrastructure Process Group RISC Reduced Instruction Set Computing RM Risk Management RTCA Radio Technical Commission for Aeronautics RUP Rational Unified Process SA Software Acquisition SBP Save Base Pointer SCAMPI Standard CMMI Assessment Method for Process Improvement

xiv Abkürzungsverzeichnis SCCS Source Code Control System SDK Software Development Kit SE Software Engineering SEI Software Engineering Institute SEPG Software Engineering Process Group SP Stack Pointer SPARC Scalable Processor ARChitecture SPICE Software Process Improvement and Capability Determination SPL Supply Process Group SRT-Division Sweeny-Robertson-Tocher-Division SSH Secure Shell SSL Secure Sockets Layer SW Software TB Terabyte (10 12 ) TByte Terabyte (10 12 ) TiB Terabyte (2 40 ) TCP Transmission Control Protocol TEC Transmit Error Counter TMR Triple-Modular Redundancy TSL Test Script Language UI User Interface UML Unified Modeling Language URL Uniform Resource Locator UTC Universal Time Coordinated VDM Vienna Development Method VLIW Very Long Instruction Word VLSI Very-Large-Scale Integration WAC Weighted Attributes per Class (Metrik) WebDAV Web-based Distributed Authoring and Versioning WER Windows Error Reporting WMC Weighted Methods per Class (Metrik) XML Extensible Markup Language XT extended

Kapitel 1 Einführung As the use of computers pervades more and more of what society does, the effects of non-quality software just become unacceptable. Software is becoming more ambitious, and we rely on it more and more. Problems that could be dismissed quite easily before are now coming to the forefront. Bertrand Meyer [263] 1.1 Aufbruch in das ubiquitäre Computerzeitalter Als zu Beginn des zwanzigsten Jahrhunderts die ersten Computer das Licht der Welt erblickten, erahnte noch niemand, wie sich die Computertechnik in schier atemberaubender Geschwindigkeit weiterentwickeln und in immer mehr Bereiche des täglichen Lebens vordringen würde. Für viele von uns ist der Rückgriff auf das Internet heute zu einer fast schon reflexartigen Aktion in den verschiedensten Lebenslagen geworden sei es die Abwicklung von Bankgeschäften, die Suche nach nahe gelegenen Restaurants oder die Begutachtung des nächsten Feriendomizils aus der Satellitenperspektive. Der mit den ersten Computersystemen ausgelöste Technisierungstrend ist bis heute ungebrochen und ein Ende bei weitem nicht abzusehen. Wie ein kurzer Blick in die Anfangstage der Computertechnik zeigt, lässt die Welt, in der wir heute leben, selbst die kühnsten Erwartungen von damals weit hinter sich. Der folgende, häufig zitierte Ausspruch wird auf das Jahr 1943 datiert und spiegelt in treffender Weise den Zeitgeist der frühen Pioniertage wider: I think there is a world market for maybe five computers. Zugeschrieben wird das Zitat keinem anderen als Thomas J. Watson, Sr., dem Mitbegründer der Firma IBM. Ob der Ausspruch wirklich von Watson stammte, wurde bis heute jedoch nie zweifelsfrei geklärt. 1

2 1 Einführung Zu der Riege der größten Fehleinschätzungen der Computergeschichte gesellt sich die folgende viel zitierte Aussage: 640K ought to be enough for anybody. Obwohl dieser Ausspruch in der Literatur regelmäßig Bill Gates zugeschrieben wird, liegt sein wahrer Ursprung bis heute im Dunkeln. Der Microsoft-Gründer selbst bestreitet, der Urheber zu sein [272]. Nützen wird es ihm wenig sein Name ist heute so eng mit diesem Zitat verbunden, dass seine angebliche Urheberschaft wie in Stein gemeißelt scheint. Auch wenn der Ausspruch in Wahrheit wohl aus weniger prominentem Munde stammt, sind seine Auswirkungen bis in die Gegenwart zu spüren. Inhaltlich spielt das Zitat auf die Limitierung früher PC-Systeme an, nicht mehr als 640 MiB Hauptspeicher adressieren zu können. Diese Architekturentscheidung wurde aus Kostengründen getroffen und galt zunächst als wenig problematisch. Der Zeitpunkt, zu dem die erste Heimanwendung die 640-MiB-Grenze brechen würde, schien in weiter Ferne. Der langen Rede kurzer Sinn: Der Speicher wurde schnell zu knapp und viele nachfolgende PC-Generationen mussten mit umständlichen Tricks und Kniffen die geschaffene 640-MiB-Grenze überwinden. Noch heute befindet sich mit dem A20-Gate ein Relikt aus dieser Zeit in nahezu allen Intel-kompatiblen Hardware- Architekturen. Mittlerweile ist die 64-Bit-Technologie in die heimische PC-Welt eingezogen. Primär erfolgte der Wechsel von 32 zu 64 Bit jedoch nicht aus Gründen der Geschwindigkeit. Die eigentliche Ursache geht auf die Beschränkung der Vorgängerarchitekturen zurück, mit ihren 32 Adressleitungen lediglich 4 GiB Hauptspeicher zu adressieren immerhin mehr als das 6000-fache der vor ein paar Jahren postulierten 640 MiB. Fast zwangsläufig mag sich dem Leser die Frage aufdrängen, was wir, wenn überhaupt, aus den Prognosen der nicht allzu fernen Vergangenheit lernen können. Vielleicht ist es in erster Linie die Einsicht, langfristige Vorhersagen im Bereich der Informationstechnologie mit Vorsicht zu behandeln die rasante Entwicklung vermag unsere heutige Sicht der Dinge schneller zu überholen als wir es gegenwärtig erahnen. Auch wenn langfristige Aussagen kaum möglich sind und wir gut daran tun, uns auf allenfalls mittelfristige Ausblicke zu beschränken, zeichnen sich seit einigen Jahren zwei feste Trends ab, die unser zukünftiges Leben maßgeblich beeinflussen und in entsprechender Weise verändern werden: Die Computertechnik dringt kontinuierlich in immer mehr Bereiche vor, die noch vor ein paar Jahren als computerfreie Domänen galten. Wie sehr unser gegenwärtiger Alltag durch den Computer wirklich geprägt wird, zeigt eine Studie aus dem Jahre 2002. In jenem Jahr kam jeder US-Bürger täglich mit rund 150 verschiedenen Mikroprozessoren in Kontakt Tendenz steigend [100]. Der Internet- Kühlschrank und die MP3-Jacke sind zwei aktuelle Beispiele, die diesen Trend mit Leben füllen. Auch wenn sich die Frage nach dem Sinn mancher Neuentwicklung an dieser Stelle regelrecht aufdrängen mag, können wir uns dem allge-

1.1 Aufbruch in das ubiquitäre Computerzeitalter 3 meinen Trend nicht verwehren. Ob wir es wollen oder nicht, die Technisierung schreitet in großen Schritten weiter voran. Die Erscheinungsform des Computers verschwimmt. Durch die fortschreitende Miniaturisierung sind Computer in vielen Fällen nicht mehr als solche zu erkennen und passen ihre Gestalt in zunehmendem Maße ihrer eigentlichen Bestimmung an. Durch den erreichten Miniaturisierungsgrad ist es heute ein Leichtes, Elektronik mit den unterschiedlichsten Alltagsgegenständen zu verschmelzen. In vielen Fällen nimmt der Benutzer nicht einmal mehr wahr, dass er in Wirklichkeit mit einem Computer arbeitet die gelungene Integration einer intuitiven Mensch-Maschine-Schnittstelle vorausgesetzt. Im Zusammenspiel begründen beide Trends das viel zitierte ubiquitäre Computerzeitalter. Hinter diesem Begriff verbirgt sich nichts anderes als die Vision des unsichtbaren, allgegenwärtigen Computers. Mit anderen Worten: Der Computer von Morgen wird überall und nirgendwo sein. Die Folgen des zunehmenden Vordringens der Computertechnik sind weitreichend. Insbesondere dominieren rechnergestützte Systeme mehr und mehr auch sicherheitskritische Bereiche, in denen Leib und Leben vom Versagen der eingesetzten Hard- oder Software unmittelbar bedroht sind. Wie weit die Technisierung bereits heute fortgeschritten ist, macht ein Blick in den Bereich der Kraftfahrzeugelektronik besonders deutlich. Mit der Anschaffung eines neuen Oberklassewagens erwirbt jeder Käufer auf einen Schlag 60 bis 70 Steuergeräte jedes für sich ein Kleincomputer, der in vielen Fällen die Rechenleistung ehemaliger Großrechner weit hinter sich lässt. Mit 72 KiB ROM, 4 KiB RAM und einer 1-MHz-CPU gelang es der Menschheit den Mond zu erobern. Jeder heute produzierte Kleinwagen übertrifft diese Rechenleistung um Größenordnungen. Die seit Jahren kontinuierlich zunehmende Vernetzung der Steuergeräte führt zu einem weiteren Anstieg der Gesamtkomplexität. Ein einziger Blick auf den Kabelbaum eines modernen Pkws reicht aus, um die Auswirkungen dieses Trends mit bloßem Auge zu erkennen. So überdecken z. B. die mehr als 2000 Einzelleitungen eines VW Phaeton aneinandergereiht eine Strecke von 4 km Länge. Bis auf wenige Ausnahmen wird der Datenaustausch zwischen den verschiedenen Steuergeräten eines Pkws über spezielle Kommunikationsbusse abgewickelt. Im Bereich der Kraftfahrzeugelektronik wurde die busbasierte Kommunikation Anfang der Achtzigerjahren mit dem CAN-Bus (CAN = Controller Area Network) eingeführt. Wie in Abb. 1.1 skizziert, ist die Kommunikation dezentral organisiert, d. h., jedes Steuergerät wird innerhalb der Bus-Topologie auf einen separaten Kommunikationsknoten abgebildet. Neben CAN spielen in modernen Kraftfahrzeugen auch die FlexRay- und die MOST-Technologie eine immer stärkere Rolle. Während das FlexRay-Bussystem unter anderem für die Anbindung sicherheitskritischer X-by- Wire-Systeme ausgelegt ist, ist der MOST-Bus auf die Übertragung multimedialer Inhalte spezialisiert. Moderne Kraftfahrzeuge weisen inzwischen eine Systemkomplexität auf, die mehr und mehr an ihre Grenzen stößt. Zeichnete in der Vergangenheit die Mechanik für die meisten Fahrzeugdefekte verantwortlich, so ist es heute immer häufiger die

4 1 Einführung Gateway CAN Adaptive Light Control CAN Handbremse CAN MOST MOST Sicherheit A-Säule links Byteflight Sicherheit B-Säule links Byteflight Infomodul Tür vorne Sicherheit A-Säule rechts Byteflight Sicherheit B-Säule rechts Byteflight Infomodul Tür vorne Diebstahl- Türmodul Türmodul Anhängermodul ACC warn- anlage Vorne Vorne Fahrer Beifahrer CAN CAN CAN CAN CAN Park- Türmodul Türmodul Luftfederunlisierung Rollstabiabstandswarner Hinten Hinten Fahrer Beifahrer CAN CAN CAN CAN CAN Reifen- Sitzmodul Sitzmodul Regensensosteuerung Getriebedruckkontrolle Vorne Vorne Fahrer Beifahrer CAN CAN CAN CAN CAN......... Audiosystemcontroller MOST Sprachausgabe Motorelektronik Radioempfänger MOST Navigationssystem MOST Videomodul CD- Wechsler links rechts MOST Byteflight Byteflight...... Abb. 1.1 Busbasierte Kommunikation verschiedener Kfz-Steuergeräte Elektronik, die uns in die Werkstatt zwingt. Setzt sich die Entwicklung in der eingeschlagenen Richtung fort, so wird bereits im Jahre 2010 jede zweite Autopanne ihre Ursache im Versagen der Elektronik haben. Beschränken wir die Betrachtung an dieser Stelle auf das technikverwöhnte Segment der Oberklassewagen, so ist die Elektronik bereits heute die Fehlerquelle Nummer eins. Mit anderen Worten: Jede zweite Panne eines modernen Oberklassewagens geht inzwischen auf das Versagen der Bordelektronik zurück ein Problem, das nicht nur die Fahrzeugführer, sondern auch die Automobilhersteller in zunehmendem Maße in Bedrängnis bringt. Obwohl die Automobilindustrie mit Hochdruck an Lösungen arbeitet, machen zahlreiche Rückrufaktionen der letzten Zeit immer wieder deutlich, dass es mit

1.1 Aufbruch in das ubiquitäre Computerzeitalter 5 der Zuverlässigkeit moderner Kfz-Elektronik noch immer nicht zum Besten steht. Sollte es an dieser Stelle nicht gelingen, die Zuverlässigkeit zukünftiger Systeme deutlich zu erhöhen, ist es mehr als fraglich, ob sich das elektronische Wettrüsten im Bereich der Kraftfahrzeugelektronik in der bestehenden Form fortsetzen lässt. Zukunftsweisende Konzepte wie die Steer-by-Wire-Technologie, die automatische Vollbremsung oder die autonome Querregelung bedingen eine Zuverlässigkeit, die viele der heutigen IT-Systeme nicht zu leisten im Stande sind. Der Qualitätssicherung wird daher in Zukunft noch eine deutlich größere Rolle zukommen, als sie bereits heute innehat. Doch welche Maßnahmen der Qualitätssicherung sind notwendig und überhaupt sinnvoll? Zur Beantwortung dieser Frage kommen wir nicht umhin, den eigentlichen Ursachen der Misere auf den Grund zu gehen. Die historische Entwicklung der Automobilelektronik liefert uns an dieser Stelle erste Gründe, warum es heute um viele computergestützte Systeme nicht zum Besten steht. Betrachten wir die Komplexitätsentwicklung typischer Kfz-Steuergeräte über die Zeit, so nehmen zwei langfristige Trends klare Konturen an: Die Systemkomplexität steigt dramatisch an. Schon lange sind die Zeiten vorbei, in denen ein Projekt von einem einzigen Programmierer alleine und völlig selbstständig zum Erfolg gebracht werden kann. Die hohe Systemkomplexität zwingt uns heute dazu, in großen Arbeitsgruppen zu entwickeln. Projekte, in denen einen Vielzahl von Hardware- und Software-Ingenieuren abteilungs- und sogar firmenübergreifend zusammenarbeiten, sind heute allgegenwärtig. In entsprechender Weise ist auch das Know-how nicht mehr länger auf ein paar wenige Entwickler konzentriert, sondern fast vollständig dezentralisiert. Die Folgen sind an dieser Stelle nicht nur positiver Natur insbesondere gibt es in größeren Projekten heute niemanden mehr, der sämtliche Aspekte eines Systems vollständig versteht oder gar jemals verstehen könnte. Die entstehenden Probleme sind kein singuläres Problem der Software- Industrie und treten ähnlich gelagert in allen Bereichen auf, in denen große Projektgruppen zu koordinieren sind. Nichtsdestotrotz kommen im Bereich der Software-Entwicklung mehrere Faktoren erschwerend hinzu. Anders als z. B. in den klassischen Ingenieur-Disziplinen ist das Problem der adäquaten Zeit- und Kostenschätzung im Bereich der Software-Entwicklung immer noch ungelöst. Der Software-Anteil heutiger Systeme wächst kontinuierlich. Waren reine Hardware-Lösungen früher für viele Zwecke ausreichend, wird deren Platz heute durch eingebettete Systeme eingenommen. Die erste Generation dieser Geräte zeichnete sich dadurch aus, dass vormals komplett in Hardware implementierte Funktionalität durch kurze, Hardware-nahe Programme nachgebildet wurde. Gegenüber reinen Hardware-Lösungen brachten der Einsatz standardisierter Komponenten sowie die augenscheinlich grenzenlose Änderbarkeit des Programmcodes deutliche Vorteile in Bezug auf Kosten und Produktivität. Durch die immer größer werdende Leistungsfähigkeit der verwendeten Mikrocontroller entwickelten sich eingebettete Systeme rasch weiter und verfügten schnell über ein Maß an Funktionalität, an das mit reinen Hardware-Lösungen nicht im Entferntesten

6 1 Einführung zu denken war. Schnell boten die entstandenen Systeme die Leistung der Großcomputer von Einst und in dem gleichen Umfang wuchs auch die Größe der verarbeiteten Programme. Bereits seit einigen Jahren übersteigt der Aufwand für die Entwicklung der Software-Komponenten die der Hardware-Komponenten erheblich. Tragischerweise fällt der Software in diesem Zusammenhang eine zwiespältige Rolle zu. Genauso wie der Großteil der Funktionalität aktueller Systeme ohne Software nicht zu realisieren wäre, ist es heute die Software, die für die Mehrzahl der Fehler verantwortlich zeichnet. Mit anderen Worten: Software ist zur Fehlerquelle Nummer eins geworden. Aber warum ist die Qualität vieler Software-Systeme eigentlich so schlecht? Und viel wichtiger noch: Stehen wir der Misere mittellos gegenüber? Welche Methoden und Techniken stehen uns heute zur Verfügung, die Qualität komplexer Software- Systeme sicherzustellen oder zu erhöhen? Die Beantwortung dieser Fragen wirft zwangsläufig eine weitere auf: Was genau ist eigentlich Software-Qualität? Den Begriff der Zuverlässigkeit haben wir bereits weiter oben ins Spiel gebracht und eine enge Verknüpfung mit dem Begriff der Software-Qualität liegt auf der Hand. Qualität mit Zuverlässigkeit gleichzusetzen wäre jedoch bei weitem zu kurz gedacht. Bevor wir uns also den verschiedenen Spielarten der modernen Software-Qualitätssicherung zuwenden, werden wir im nächsten Abschnitt den Begriff der Software-Qualität in all seinen verschiedenen Facetten näher beleuchten. 1.2 Was ist Software-Qualität? Nahezu jeder Programmierer entwickelt im Laufe seiner Karriere ein intuitives Verständnis für den Begriff der Software-Qualität. Der Qualitätsbegriff erscheint einfach zu fassen, entpuppt sich bei genauerem Hinsehen jedoch als äußerst vielfältig. Erschwerend kommt hinzu, dass Entwickler und Projektleiter mit diesem Begriff häufig verschiedene Inhalte verbinden Missverständnisse inbegriffen. Die DIN-ISO-Norm 9126 definiert den Begriff Software-Qualität wie folgt: Software-Qualität ist die Gesamtheit der Merkmale und Merkmalswerte eines Software-Produkts, die sich auf dessen Eignung beziehen, festgelegte Erfordernisse zu erfüllen. Die Definition unterstreicht, dass der Begriff der Software-Qualität eine multikausale Größe beschreibt. Mit anderen Worten: Es gibt nicht das eine Kriterium, mit dem sich Software-Qualität in direkter Weise und vor allem quantitativ verbinden lässt. Vielmehr verbergen sich hinter dem Begriff eine ganze Reihe vielschichtiger Kriterien, von denen sich einige zu allem Überdruss auch noch gegenseitig ausschließen. Die wesentlichen Merkmale, die für die Beurteilung der Software-Qualität in der Praxis eine Rolle spielen, sind in Abb. 1.2 zusammengefasst. In Abhängigkeit des Anwendungsgebiets und der gestellten Anforderungen variiert die Relevanz der einzelnen Kriterien erheblich. Insbesondere lässt die Reihenfolge ihrer Auflistung keinen Rückschluss auf deren Bedeutsamkeit zu.