Qualitätsmanagement in der Softwareentwicklung Dirk Stelzer

Transkript

1 - 1 - Qualitätsmanagement in der Softwareentwicklung Dirk Stelzer Dieser Beitrag ist in einer gekürzten Fassung erschienen in: Computer Reseller News, Nr. 13, 30. März 2000, S Drei Fälle mangelnder Softwarequalität Am 1. Januar 1996 führt die Deutsche Telekom neue Tarife für die Abrechnung von Telefonaten ein. Durch einen Fehler werden dabei 11 Millionen Kunden überhöhte Gebühren in Rechnung gestellt. Nachdem der Abrechnungsfehler bekannt wird, entschließt sich die Telekom, den Fehler zu beheben und die Kunden zu entschädigen. Es wird geschätzt, daß dem Unternehmen dadurch ein Schaden von mehr als 70 Millionen DM entstanden ist. Am 14. September 1993 versuchen die Piloten eines Airbus A-320 der Deutschen Lufthansa bei schlechtem Wetter in Warschau zu landen. Nach dem Aufsetzen auf der Landebahn läßt sich zunächst die Schubumkehr des Airbus nicht betätigen. Neun Sekunden lang rast das Flugzug mit nahezu unverminderter Geschwindigkeit über die Landebahn. Als die Schubumkehr wieder funktioniert ist es zu spät. Der Airbus kommt nicht rechtzeitig zum Stehen, bohrt sich in einen Erdwall und fängt Feuer. Zwei Menschen werden getötet, 52 schwer und fünf leicht verletzt. Am , während des letzten Golfkrieges, verfehlt in Dharan (Saudi-Arabien) eine Patriot- Abwehrrakete eine irakische Scud-Rakete. Die Scud-Rakete trifft eine Mannschaftsunterkunft USamerikanischer Soldaten. 28 Personen werden getötet, 90 weitere zum Teil schwer verletzt. So unterschiedlich diese Beispiele auch sind, allen drei Fällen ist gemeinsam, daß mangelnde Softwarequalität maßgeblich zu den Schäden beigetragen hat. Solche spektakulären Fälle mit zum Teil katastrophalen Folgen sind eine Facette mangelnder Softwarequalität. Eine andere Facette sind die vielen Fehler, die sich in Betriebsystemen und Anwendungssoftware verbergen. Obwohl diese Fehler nur selten zu spektakulären Folgen führen, sind ihre Auswirkungen volkswirtschaftlich gesehen ebenfalls erheblich. Das kann man sich leicht klar machen, wenn man errechnet, wie viele Arbeitsstunden alleine in Deutschland an einem Tag dadurch verloren gehen, daß Benutzer nach Softwareabstürzen ihre Systeme neu starten und dabei eventuell Daten neu eingeben müssen. Qualitätsmanagement in der Softwareentwicklung beschäftigt sich mit der Frage, wie die Ursachen von Softwarefehlern bekämpft bzw. das Risiko ihres Auftretens verringert werden kann.

2 - 2-2 Qualitätsmanagement in der Softwareentwicklung Dieser Beitrag gibt einen Überblick über das Qualitätsmanagement in der Softwareentwicklung. Außerdem werden interessierten Lesern Hinweise auf Quellen für eine weitergehende Beschäftigung mit dem Thema gegeben. Unter Softwareentwicklung verstehe ich alle Tätigkeiten, die ausgeführt werden müssen, um ein Softwareprodukt zu erzeugen. Dazu gehören Anforderungsanalyse, Entwurf, Implementierung und Integration, Wartung, Konfigurationsmanagement, Qualitätssicherung und Dokumentation. Qualitätsmanagement bezeichnet die Planung, Steuerung und Kontrolle von Qualität. Was bedeutet Qualität? Einige Fachleute verstehen unter Qualität die Abwesenheit von Fehlern. Unsere alltäglichen Erfahrungen mit Softwareprodukten bestimmter Hersteller weisen allerdings darauf hin, daß Software sehr fehlerhaft und dennoch erfolgreich sein kann. Offenbar verfügen diese Produkte über andere Qualitäten als Fehlerlosigkeit. Und offenbar bewegen diese anderen Qualitäten die überwältige Mehrheit von Computernutzern weltweit, diese Produkte trotz ihres offensichtlich hohen Fehleranteils zu erwerben und jahrelang damit zu arbeiten. Im allgemeinen wird unter Qualität das Ausmaß verstanden, in dem ein Gegenstand geeignet ist, Anforderungen zu erfüllen. Diese Anforderungen können sich bei Software auf Benutzerfreundlichkeit, Kompatibilität, Portierbarkeit, Integrationsfähigkeit, Performanz, Wart- und Erweiterbarkeit sowie auf viele andere Aspekte beziehen. Damit ist auch klar, daß Softwarequalität für verschiedene Benutzer völlig unterschiedliche Dinge bedeuten kann. Unter Berücksichtigung der jeweiligen Rahmenbedingungen müssen Anforderungen festgelegt werden, die beschreiben, was in einer spezifischen Situation unter Qualität verstanden werden soll. Es lassen sich zwei verschiedene Perspektiven des Qualitätsmanagements in der Softwareentwicklung unterscheiden. Die erste Perspektive fokussiert auf das Softwareprodukt, die zweite auf die Softwareentwicklung selbst oder anders formuliert: auf den Prozeß der Entwicklung der Software bzw. auf den Softwareprozeß. Bei der produktorientierten Perspektive werden zunächst Anforderungen an das Softwareprodukt formuliert. Diese Anforderungen dienen als Leitlinien zur Entwicklung der Software und als Kriterien zur Bewertung des entwickelten Produktes. In der Regel werden diese Anforderungen im Rahmen der Anforderungsanalyse formuliert und z. B. in Form eines Pflichtenhefts dokumentiert. Im Rahmen der Qualitätssicherung wird überprüft, inwiefern das entwickelte Produkt diese Anforderungen erfüllt.

3 - 3 - Bei der prozeßorientierten Perspektive werden Anforderungen an den Prozeß der Softwareentwicklung formuliert. Diese Anforderungen dienen sowohl als Vorgaben z. B. für die Gestaltung einzelner Softwareprojekte als auch als Bewertungskriterien für einen Softwareprozeß, z. B. im Rahmen der Zertifizierung eines Qualitätsmanagementsystems. Selbstverständlich besteht zwischen der produkt- und der prozeßorientierten Perspektive eine enge Verbindung. Es handelt sich lediglich um unterschiedliche Perspektiven auf den selben Gegenstand, nämlich die Softwareentwicklung. Die Verfechter beider Perspektiven haben das selbe Ziel, sie setzen lediglich unterschiedliche Schwerpunkte bei der Wahl ihrer Mittel. Die Verfechter der prozeßorientierten Perspektive gehen davon aus, daß ein qualitativ hochwertiger Prozeß (das heißt ein Prozeß, der die an ihn gestellten Anforderungen erfüllt) mit einer hohen Wahrscheinlichkeit auch ein qualitativ hochwertiges Produkt hervorbringt. Demzufolge konzentrieren sie sich auf die Gestaltung des Softwareprozesses. Die Verfechter der produktorientierten Perspektive gehen davon aus, daß zur Erreichung eines qualitativ hochwertigen Softwareproduktes die Überprüfung der Anforderungen an das Produkt höchste Priorität haben sollte. Demzufolge betonen sie die Qualitätssicherung des Produktes - in der Regel in Form von Tests oder Inspektionen. In der Praxis der Softwareentwicklung werden beide Perspektiven miteinander kombiniert. Die Unterscheidung der Perspektiven dient in erster Linie zum besseren Verständnis der unterschiedlichen Ansätze zur Verwirklichung des Qualitätsmanagements in der Softwareentwicklung 3 Produktorientiertes Qualitätsmanagement Im Rahmen der produktorientierten Perspektive lassen sich im wesentlichen zwei verschiedene Maßnahmenbündel unterscheiden: die dynamische Qualitätssicherung (oder anders formuliert, das Testen) und die statische Qualitätssicherung. (Daneben gibt es noch formale Verifikation und symbolische Ausführung. Da diese Ansätze jedoch nur in Spezialbereichen verwendet werden, wird hier nicht näher darauf eingegangen.) 3.1 Dynamische Qualitätssicherung (Softwaretesten) Softwaretesten bedeutet Überprüfen von Software durch Ausführen eines Testobjektes (z. B. eines Softwaremoduls) mit Testdaten. Softwaretesten wird deshalb auch als dynamische Qualitätssicherung bezeichnet. Das Ziel des Testens besteht darin, Fehler zu finden. Fehler sind Abweichungen

4 - 4 - von den Anforderungen. Softwaretests sind nicht geeignet, die Sicherheit, Korrektheit oder Qualität eines Softwareproduktes nachzuweisen. Softwaretests können lediglich Abweichungen von den Anforderungen (= Fehler) aufzeigen. Selbst wenn bei umfassenden und sehr gründlichen Softwaretests keine Fehler gefunden wurden, heißt das nicht, daß das getestete Objekt keine Fehler enthält. Jedem Softwaretest liegt folgende Struktur zugrunde: Definition von Testfällen Auswahl einer Testdatenkombination Definition des erwarteten Ergebnisses Ausführen des Testobjekts mit einer Testdatenkombination Vergleich des erwarteten mit dem tatsächlichen Ergebnis Weicht das erwartete von dem tatsächlichen Ergebnis ab, liegt ein Fehler vor. Ein Testfall beschreibt eine Menge von Eingabedaten, mit denen ein bestimmter Aspekt des Verhaltens eines Testobjekts geprüft werden soll. Ein Testfall spezifiziert eine Menge von Testdaten bzw. Testdatenkombinationen. Testdaten sind die Eingabewerte, die bei der Testdurchführung verwendet werden. Eine Testdatenkombination ist eine Kombination von Testdaten, die gemeinsam für eine Ausführung des Testobjekts verwendet werden. Ein Testverfahren bezeichnet eine begründete Vorgehensweise zur Aufdeckung einer bestimmten Klasse von Fehlern. Es gibt sehr unterschiedliche Testverfahren. Da Testobjekte in der Regel nicht vollständig, das heißt mit allen denkbaren Testdatenkombinationen getestet werden können, geben Testverfahren Hinweise zur Auswahl von Testfällen und von Testdaten(kombinationen). Die verschiedenen Testverfahren unterscheiden sich im wesentlichen dadurch, welche Schwerpunkte bei der Auswahl von Testfällen und Testdaten(kombinationen) gesetzt werden. Durch diese unterschiedlichen Schwerpunkte ergeben sich auch unterschiedliche Stärken und Schwächen der einzelnen Verfahren. Die Testverfahren können in funktionsorientierte und strukturorientierte Testverfahren unterteilt werden. Funktionsorientierte Testverfahren benutzen die Spezifikation des Testobjekts als Referenz für die Bildung von Testfällen. Beispiele für funktionsorientierte Testverfahren sind die Äquivalenzklassen-Analyse, die Grenzwertanalyse und die Ursache-Wirkungs-Analyse. Strukturorientierte Testverfahren benutzen die Implementation des Testobjekts (in der Regel den programmierten Code) als Referenz für die Bildung von Testfällen. Strukturorientierte Testverfahren lassen sich unterteilen in kontrollflußorientierte Testverfahren und datenflußorientierte Testver-

5 - 5 - fahren. Bei den kontrollflußorientierten Testverfahren werden Strukturelemente (z. B. Anweisungen, Zweige, Bedingungen) zur Erzeugung von Testfällen verwendet. Bei den datenflußorientierten Testverfahren werden Zugriffe auf Variablen (z. B. Definitionen oder berechnende Verwendungen) zur Erzeugung von Testfällen verwendet. Der Aufwand für das systematische Testen von Software ist hoch. Verschiedene empirische Untersuchungen zeigen, daß die Kosten für das Testen 20 bis 50 % des gesamten Projektbudgets ausmachen können. Wird weniger systematisch getestet, drohen noch weitaus höhere Kosten, z. B. für die Behebung von Fehlern bei Kunden bzw. für die Anfertigung und Auslieferung verbesserter Versionen. 3.2 Statische Qualitätssicherung Die statische Qualitätssicherung umfaßt alle Aktivitäten, die Informationen über ein Prüfobjekt bereitstellen, ohne es dynamisch auszuführen. Ein typisches Beispiel der statischen Qualitätssicherung sind Inspektionen. Dabei wird ein Objekt durch ein Team von drei bis sieben Teilnehmern überprüft. Das Team versucht, durch gemeinsames Lesen des Prüfobjekts und mit Hilfe von Checklisten Fehler zu entdecken. Prüfobjekte können z. B. Anforderungsdokumente, Daten- oder Ablaufmodelle oder Softwarecode sein. Typische Fragen, die im Rahmen einer solchen Sitzung überprüft werden, sind: Stimmt das Objekt mit der Spezifikation überein? Ist das Objekt vollständig? Ist die gewünscht Funktionalität korrekt implementiert worden? Enthält das Objekt nur die Funktionen / Inhalte, die es enthalten soll? Sind relevante Richtlinien, Normen und Standards eingehalten worden? Einer der Vorteile der statischen Qualitätssicherung besteht darin, daß bereits in den frühen Phasen der Softwareentwicklung Zwischenprodukte systematisch überprüft werden können. Das Testen hingegen erfordert ablauffähigen Softwarecode. Ein weiterer Vorteil der statischen Qualitätssicherung besteht darin, daß Fehler direkt - und nicht nur anhand ihrer Auswirkungen wie beim Testen - erkannt werden können. Das Softwaretesten scheint in der Praxis im Vergleich zur statischen Qualitätssicherung verbreiteter zu sein. Das ist vor allem deshalb unverständlich, weil verschiedene empirische Untersuchungen zeigen, daß z. B. Code-Inspektionen im Vergleich zum Testen deutlich effizienter sind. Setzt man den Gesamtaufwand ins Verhältnis zur Anzahl der gefundenen Fehler, so ist mit Code-Inspektionen häufig eine deutlich höhere Wirtschaftlichkeit erreicht worden.

6 - 6 - Das produktorientierte Qualitätsmanagement hat den Nachteil, daß Fehler in der Regel erst nach der Realisierung eines (Zwischen-)Produktes entdeckt werden können. Im prozeßorientierten Qualitätsmanagement versucht man dagegen, die Softwareentwicklung so zu gestalten, daß die Wahrscheinlichkeit, Fehler zu begehen, reduziert wird. 4 Prozeßorientiertes Qualitätsmanagement Der Begriff prozeßorientiertes Software-Qualitätsmanagement bezeichnet ein Bündel von Maßnahmen, mit denen wesentliche Teilaufgaben der Softwareentwicklung geplant, gesteuert und kontrolliert werden können. Diese Maßnahmen sind darauf ausgerichtet, die Softwareentwicklung innerhalb einer Organisation zu standardisieren und kontinuierlich zu verbessern. Auf diese Weise soll die Leistungsfähigkeit der Softwareentwicklung erhöht werden. Die erhöhte Leistungsfähigkeit soll sich z. B. durch verbesserte Produktqualität, niedrigere Entwicklungskosten und kürzere Entwicklungszeiten bemerkbar machen. Das prozeßorientierte Software-Qualitätsmanagement wird in verschiedenen Leitfäden beschrieben. Hierzu zählen insbesondere die ISO 9000-Normenfamilie und das Capability Maturity Model (CMM) for software, auf die im folgenden kurz eingegangen wird. Darüber hinaus entsteht zur Zeit die Norm ISO Software Process Assessment, die auch unter der Bezeichnung Software Process Improvement and Capability determination (SPICE) bekannt geworden ist. Die Leitfäden können Unternehmen helfen, ihre Softwareentwicklung zu gestalten und zu verbessern. Sie eignen sich auch zur Bewertung der Leistungsfähigkeit von Softwarelieferanten bzw. als Maßstab für eine Zertifizierung. [Ein Überblick über die verschiedenen Leitfäden findet sich in dem Buch von Mellis, Herzwurm, Stelzer: TQM der Softwareentwicklung.] 4.1 Die ISO 9000-Normenfamilie Die Entwicklung der ISO 9000-Normenfamilie begann Ende der 70er Jahre, um die verschiedenen damals bereits existierenden nationalen und branchenspezifischen Normen zur Qualitätssicherung zu vereinheitlichen wurde die ISO 9000-Familie weltweit veröffentlicht und seit dem in verschiedenen Stufen überarbeitet. Parallel dazu glichen verschiedene nationale Normungsinstitute ihre Normen an die Vorgaben der ISO 9000 an. Die Übertragung der Empfehlungen und Forderungen der branchenunabhängigen ISO 9000-Normenfamilie fiel besonders Dienstleistungsunternehmen und Software entwickelnden Organisationen schwer. Deshalb wurden verschiedene branchenspezifische Auslegungen und Konkretisierungen der Normen erstellt. Für Dienstleistungsunternehmen ist

7 - 7 - das z. B. die ISO , für die Softwareentwicklung die inzwischen überarbeitete ISO Die ISO 9000-Familie wird laufend überarbeitet. Mit Ausgabedatum Mai 1999 veröffentlichte das Deutsche Institut für Normung e.v. die überarbeiteten Entwürfe von drei neuen internationalen Normen zu Qualitätsmanagement-Systemen (nämlich ISO 9000, 9001 und 9004 Ausgabe: ), deren endgültige Fassungen bis Ende 2000 vorliegen sollen. Auf den WWW-Seiten des DIN [ bzw. des Beuth Verlages [ können die Entwürfe dieser Normen bestellt und kommentiert werden. Die ISO 9000-Normenfamilie besteht aus verschiedenen Normen. In der ISO 8402 werden die der ISO 9000-Familie zugrundeliegenden Begriffe definiert. Die ISO ist ein Leitfaden zur Auswahl und Anwendung der ISO 9000 Normen. Sie gibt außerdem eine Einführung in die Grundgedanken der Normenfamilie. Die ISO gibt Empfehlungen zur Gestaltung des Qualitätsmanagements bzw. zum Aufbau eines Qualitätsmanagementsystems. Der Begriff Qualitätsmanagementsystem (QM-System) bezeichnet die zur Verwirklichung des Qualitätsmanagements erforderliche Organisationsstruktur, Verfahren, Prozesse und Mittel. Die ISO 9001 beschreibt Anforderungen für die Zertifizierung von QM-Systemen. Die ISO ist ein Leitfaden für die Anwendung der ISO 9001 auf die Entwicklung, Lieferung und Wartung von Software. Die Verfasser der ISO haben versucht, die branchenunabhängig formulierten Begriffe der ISO 9001 in eine in der Softwareentwicklung übliche Terminologie zu übersetzen. Die Normen der er Reihe, die ebenfalls zur ISO 9000-Familie gerechnet werden, gehen auf einzelne Elemente des Qualitätsmanagements ein, z. B. auf die Durchführung von Audits oder die Erstellung von Qualitätsmanagement- Handbüchern. Inhaltlich geben die Normen in erster Linie Empfehlungen zur Dokumentation, zur Qualitätssicherung, zum Konfigurationsmanagement, zur Verantwortung der Leitung einer Organisation sowie zu den Aufgaben von Qualitätsbeauftragten. Der Ruf der ISO 9000 Normenfamilie hat in der Softwarebranche vermutlich in erster Linie wegen der Zertifizierungspraxis gelitten. Allerdings haben viele Softwareunternehmen durchaus positive Erfahrungen mit der Gestaltung ihrer Softwareentwicklung gemäß den Empfehlungen der Norm gemacht. 4.2 Das Capability Maturity Model (CMM) for software Das Capability Maturity Modell (CMM) wird seit 1986 am Software Engineering Institute (SEI) der Carnegie Mellon University in Pittsburgh, USA entwickelt. Das US-amerikanische Verteidigungs-

8 - 8 - ministerium finanziert die Arbeiten am CMM, da es das Modell als Hilfsmittel zur Beurteilung und Auswahl von Lieferanten für Softwaresysteme benötigt. Das wesentliche Strukturierungsmerkmal des CMM sind die sogenannten Reifegrade ( Maturity levels ). Reifegrad 1 ( initial ) beschreibt unreife Gestaltungen der Softwareentwicklung. Reifegrad 5 ( optimizing ) beschreibt den höchsten Reifegrad. Reife im Sinne des CMM bezeichnet das Ausmaß, in dem die Softwareentwicklung definiert und beschrieben ist, und in dem sie geplant, gesteuert und kontrolliert wird. Mit steigendem Reifegrad wird die Erwartung verbunden, daß Termine, Kosten- und Qualitätsziele besser geplant und eingehalten werden können. Gleichzeitig - so die Verfasser des CMM - sinke das Risiko, daß einzelne Projekte ihre Ziele nicht erreichen. Die Verfasser des CMM stellen außerdem einen Zusammenhang zwischen der Reife und der Effektivität der Softwareentwicklung her. Sie behaupten, je reifer die Softwareentwicklung sei, desto höher sei die Qualität der entwickelten Produkte, desto kürzer seien die Entwicklungszeiten und desto niedriger die Kosten. Die fünf Reifegrade bauen aufeinander auf. Jeder Reifegrad unterscheidet sich von dem vorhergehenden dadurch, daß zusätzliche Fähigkeiten beherrscht werden. In den folgenden Abschnitten werden die wesentlichen Charakteristika der fünf Reifegrade erläutert: Reifegrad 1 - Initial Level Softwareentwicklungsprojekte werden ad hoc strukturiert und laufen in der Regel chaotisch ab. Nur wenige Vorgehensweisen, Methoden oder Verfahren sind klar definiert. Es gibt keine Vorgaben oder Hilfsmittel zur Planung und Steuerung von Projekten. Liefertermine und Budgets der Projekte sowie die Qualität der Produkte lassen sich nur schwer vorhersagen. Der Erfolg oder Mißerfolg von Entwicklungsvorhaben hängt in erster Linie von den Bemühungen, der Motivation und der Qualifikation der beteiligten Personen ab. Reifegrad 2 - Repeatable Level Grundlegende Projektmanagementaufgaben, wie Planung, Kontrolle und Steuerung von Zeit, Kosten und Qualität, sind etabliert. Die Planung von Projekten basiert auf den Erfahrungen ähnlicher Projekte. Erfolge einzelner Projekte können unter ähnlichen Bedingungen mit einer gewissen Wahrscheinlichkeit wiederholt werden. Reifegrad 3 - Defined Level Es sind projektübergreifende, unternehmensweit gültige Regelungen zur Softwareentwicklung erlassen und dokumentiert worden. Alle Entwicklungsprojekte richten sich nach diesen Regelungen. Situationsspezifische Anpassungen und Interpretationen der Regelungen in einzelnen Pro-

9 - 9 - jekten sind zulässig und erwünscht, sofern sie nachvollziehbar begründet werden können. Eine eigene organisatorische Einheit, die Software engineering process group (SEPG), pflegt die Regelungen und entwickelt sie weiter, so daß die Projekte dadurch sinnvoll unterstützt werden. Reifegrad 4 - Managed Level Es werden quantitative Ziele für Softwareprodukte und Teilaufgaben der Softwareentwicklung formuliert. Die Zielerreichung wird im Rahmen eines umfassenden Meßprogramms überprüft. Alle Meßergebnisse werden mit Hilfe einer Datenbank verwaltet und ausgewertet. Der Einfluß der verwendeten Hilfsmittel auf die Qualität der Produkte und die Produktivität der Entwicklung ist verstanden und quantitativ formuliert worden. Die Hilfsmittel können gezielt eingesetzt und verändert werden, um Zeit-, Kosten- und Qualitätsziele mit hoher Genauigkeit zu erreichen. Wenn gesetzte Ziele nicht erreicht werden, so können diese Abweichungen mit Hilfe der gesammelten Daten erklärt werden. Sobald in einem Entwicklungsprojekt Abweichungen von (Teil-)Zielen festgestellt werden, werden Gegenmaßnahmen ergriffen. Reifegrad 5 - Optimizing Level Das gesamte Unternehmen ist auf kontinuierliche Verbesserung eingestellt. Erfahrungen aus der Softwareentwicklung werden mit quantitativen Daten beschrieben. Diese Daten ermöglichen eine kontinuierliche Verbesserung aller Teilaufgaben der Softwareentwicklung. Neue Ideen, Methoden und Werkzeuge werden in Pilotprojekten erprobt. Quantitative Kosten-Nutzen-Analysen dieser Innovationen ermöglichen Empfehlungen für den unternehmensweiten Einsatz der jeweils besten Hilfsmittel. Das CMM wird ähnlich wie die ISO 9000 zur Zeit überarbeitet. Den aktuellen Stand kann man sich von der Website des Software Engineering Institutes [ herunterladen. Empirische Untersuchungen zeigen, daß sich die Mehrheit aller Softwareentwicklungsprozesse auf Reifegrad 1 oder 2 befindet. Für Software entwickelnde Organisationen scheint es - unabhängig von der Branche - sinnvoll zu sein, die Softwareentwicklung in Übereinstimmung mit den Empfehlungen der Reifegrade 2 und 3 zu gestalten. Die Anforderungen der Stufen 4 und 5 sind hingegen sehr aufwendig zu realisieren. Sie scheinen nur bei besonders hohen Anforderungen an die Qualität der entwickelten Software empfehlenswert zu sein. Das CMM wird in Nordamerika vorwiegend von Unternehmen in den Branchen Telekommunikation, Luft- und Raumfahrt sowie von Finanzdienstleistern eingesetzt. Diese Unternehmen erreichen wegen der Kritikalität ihrer Softwareanwendungen - oft einen hohen Reifegrad nach CMM.

10 Sowohl die ISO 9000 als auch das CMM geben vor, daß bestimmte Aspekte geregelt und dokumentiert werden müssen. Sie geben aber nicht vor, wie diese Aspekte gestaltet werden sollen. Vor allem werden keine Empfehlungen für bestimmte Werkzeuge gegeben. Diese Beschränkung auf allgemein gehaltene Hinweise hat Vor- und Nachteile. Einerseits lassen die Leitfäden den Anwendern weite Spielräume zur Interpretation und Gestaltung der Anforderungen und Empfehlungen. Andererseits können die Leitfäden nicht als Kochbücher verwendet werden, die man unmittelbar umsetzen kann, um zu einer qualitativ hochwertigen Softwareentwicklung zu gelangen. 5 Zusammenfassung Qualitätsmanagement in der Softwareentwicklung ist nicht in der Lage, das Auftreten von Softwarefehlern zu verhindern. Es kann aber einen Beitrag dazu leisten, daß Software mit weniger Fehlern ausgeliefert und daß das mit den verbleibenden Fehlern verbundene Risiko vermindert wird. Qualitätsmanagement kann auch dazu beitragen, daß die Anforderungen der Benutzer an die Software in höherem Maße erfüllt wird. Ein richtig verstandenes prozeßorientiertes Qualitätsmanagement kann außerdem zu einer Reduktion von Entwicklungskosten und Projektlaufzeiten beitragen. Produkt- und prozeßorientiertes Qualitätsmanagement sind keine Alternativen, sondern sich ergänzende Maßnahmenbündel. Im Total Quality Management (TQM) versucht man, beide Perspektiven zu vereinen. Dabei wird besonderer Wert auf die Ausbildung und Motivation der Mitarbeiter gelegt. Denn eines ist klar: Weder Prüfungen von Produkten noch Verbesserungen von Prozessen können ihre Wirkung voll entfalten, wenn sie nicht von engagierten Mitarbeitern getragen werden. 6 Literaturhinweise Zum Softwaretesten Glenford J. Myers: Methodisches Testen von Programmen. 6. Aufl., Oldenbourg, München - Wien Zur statischen Qualitätssicherung Daniel P. Freedman, Gerald M. Weinberg: Handbook of Walkthroughs, Inspections, and Technical Reviews. Evaluating Programs, Projects, and Products. 3. Aufl., Dorset House, New York Tom Gilb, Dorothy Graham: Software Inspection. Addison-Wesley, Wokingham u. a Zum prozeßorientierten Softwarequalitätsmanagement und TQM

11 Dirk Stelzer: Möglichkeiten und Grenzen des prozeßorientierten Software-Qualitätsmanagements. Habilitationsschrift vorgelegt an der Wirtschafts- und Sozialwissenschaftlichen Fakultät der Universität zu Köln. Köln Werner Mellis, Georg Herzwurm, Dirk Stelzer: TQM der Softwareentwicklung. Mit Prozeßverbesserung, Kundenorientierung und Change Management zu erfolgreicher Software. 2. Aufl., Vieweg, Braunschweig - Wiesbaden Zur ISO und Zum Capability Maturity Model (CMM) for software Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, Charles V. Weber: Capability Maturity Model for Software. Version 1.1. Technical Report CMU/SEI-93-TR-024. Pittsburgh [ Mark C. Paulk, Charles V. Weber, Bill Curtis, Mary Beth Chrissis: The Capability Maturity Model: Guidelines for Improving the Software Process. Addison-Wesley, Reading Zur ISO Software Process Assessment und Weitere Eine Vielzahl von empirischen Untersuchungen und weiteren Verweisen zum Qualitätsmanagement in der Softwareentwicklung findet sich auf der Website des Lehrstuhls für Wirtschaftsinformatik, Systementwicklung, von Prof. Dr. W. Mellis der Universität zu Köln unter