Six Sigma in der Softwareentwicklung Georg Herzwurm, Martin Mikusz Lehrstuhl für Allgemeine Betriebswirtschaftslehre und Wirtschaftsinformatik II, Universität Stuttgart, Breitscheidstr. 2c, 70174 Stuttgart {Herzwurm, Mikusz}@wi.uni-stuttgart.de

Die auf statistischen Methoden basierende Prozessverbesserungsmethode Six Sigma wurde in den 80´ Jahren bei Motorola entwickelt und erlangte in der Industrie große Beachtung. Six Sigma Projekte folgen einer festgelegten Vorgehensweise mit definierten Rollen und den Projektphasen Define, Measure, Analyze, Improve und Control (DMAIC). Insgesamt gelten die Philosophie und Konzeption von Six Sigma als noch nicht in jeder Hinsicht geklärt und empirisch abgesichert [KM06]. Als gemeinsame Charakteristika der unzähligen Six Sigma Varianten können jedoch die Fokussierung auf Variation der qualitätskritischen Steuerparameter, datenbasierte Entscheidungsfindung, Verwendung von statistischen Analysen als Erkenntnisweg, sowie der Einsatz Statistischer Prozessregelung herausgestellt werden [ähnlich bei KM06; HS00, 274]. Im Folgenden wird die Anwendbarkeit dieser Konzepte und deren Umsetzung, v. a. durch Analogien oder bereits vorhandene Ansätze in der Softwareentwicklung, erörtert. Six Sigma konzentriert sich auf die Reduzierung von Variation bei den qualitätskritischen Steuerparametern, die das Ergebnis stark beeinflussen. Balzert [Ba98, 12ff.] stellt einige empirische Untersuchungen zusammen, die zeigen, dass die Variation von Einflussfaktoren auf die Produktivität der Softwareentwicklung (v. a. Unternehmenskultur, Mitarbeiterqualifikation, Wiederverwendung, Produktkomplexität) enorm ist. Direkt oder indirekt sind dies somit die qualitätskritischen Steuerparameter und sollten nach Six Sigma über die Varianzreduktion unter Kontrolle gehalten werden. Das ist zwar möglich, jedoch nicht mit den statistischen Methoden von Six Sigma. Gleichzeitig überdecken diese Einflussfaktoren aber sowohl die Problemursachen, wie auch die Effekte der Prozessverbesserung bei den für Six Sigma zugänglichen Problemstellungen. Die Definition der Prozessfähigkeit als Maß für die Effizienz über den Aufwand in MM pro Function Point wäre ein probates Mittel, um Prozessverbesserungen normiert und anwendungsneutral messbar zu machen [BF04, 78]. Alle Maßnahmen in einem Six Sigma Projekt sollen ausschließlich auf Basis von Daten festgelegt werden. Zentrale Metrik bei Six Sigma ist die rolled throughput yield – die Wahrscheinlichkeit, dass eine Produkteinheit den gesamten Produktionsprozess fehlerfrei passiert [HS00]. So hat ein Prozess, der das Niveau von 6 Sigma erfüllt, eine rty von 99,9966% und liefert damit bezogen auf eine Million Möglichkeiten nur 3,4 fehlerhafte Ergebnisse. Da in der Softwareentwicklung nicht nur Fehlerentstehung, sondern auch Fehlerbeseitigung in allen Phasen stattfindet, kann die rty nicht direkt übernommen werden. Mit der defect removal effectiveness existiert aber eine analoge Metrik, die Aussagen über die Effizienz der Fehlerbeseitigung macht und dabei softwarespezifische Besonderheiten wie die neuerliche Fehlereinführung bei der Fehlerberichtigung berücksichtigt. Basierend auf der dre können Effektivitätsmetriken für die einzelnen Entwicklungsphasen kalkuliert, verdichtet [Ka03, 165ff.], und somit als Datenbasis für Six Sig253

ma Projekte herangezogen werden. Insgesamt jedoch fehlen wohl definierte und auf Kundenanforderungen basierte Metriken in vielen Bereichen der Softwareentwicklung [Ka03, 144], sodass Six Sigma einer Metriken-Initiative gleichkommen kann [Da92]. Six Sigma geht weit über den punktuellen Einsatz von statistischen Methoden hinaus und steht insofern vor denselben Herausforderungen wie die empirische Softwaretechnik – v. a. bezüglich der mangelnden Datenqualität und -verfügbarkeit in der Softwareentwicklung [Ka03, 470]. Da statistische Verfahren aber bestimmte Anforderungen diesbezüglich stellen, kann bei einem Six Sigma Projekt in der Softwareentwicklung nur ein Teil der statistischen Methoden des DMAIC eingesetzt werden. Des Weiteren sind kontrollierte Experimente unter definierten Laborbedingungen mit einem hohen Aufwand verbunden, was mit ein Grund für ihre mangelnde Verbreitung in der Softwareentwicklung ist [MPR05, 407]. Die computergestützte Simulation von Experimenten ist in der Industrie weit verbreitet und auch als Erkenntnisweg bei Six Sigma Projekten in der Softwareentwicklung (Virtual Software Engineering Laboratory [MPR05]) vorstellbar. Ziel der Statistischen Prozessregelung ist es, aus Vergangenheitsdaten die zukünftige Variabilität des Prozesses vorherzusagen, um so präventiv eingreifen zu können, bevor mit hoher Wahrscheinlichkeit Ausschuss produziert würde. Dabei wird im Prozessschritt n von der Qualität der letzten baugleichen x-1, x-2, etc. Zwischenprodukte auf die Qualität des Zwischenproduktes x geschlossen. In der Softwareentwicklung ist diese Schlussfolgerung v. a. aufgrund der Heterogenität der Artefakte (bspw. Produktkomplexität) und der Nichtbeachtung des bisherigen Entwicklungsverlaufes bez. Prozessqualität nicht Ziel führend. Letzteres verdeutlicht, dass Metriken und Modelle, die sich auf das Lebenszyklusmodell beziehen, die Muster und Gesetzesmäßigkeiten der Softwareentwicklung besser abbilden können, als auf sequentiellen Daten basierende Modelle [Ka03, 144]. Die Schlussfolgerung ist hier eine andere, nämlich vom bisherigen Entwicklungsverlauf (bspw. Zeitdruck, Change History, dre, etc.) in den Entwicklungsphasen n-1, n-2, etc. des Artefaktes x auf seine Qualität in der Entwicklungsphase n. Solche Modelle sind in der Softwareentwicklung als sog. reliability (growth) models bereits bekannt [Ka03]. [Ba98]

Balzert, H.: Lehrbuch der Software-Technik, B. 2. Spektrum Verl., Heidelberg 1998.

[BF04]

Bundschuh, M.; Fabry, A.: Aufwandschätzung von IT-Projekten. 2. Aufl., mitp-Verl., Bonn 2004.

[Da92]

Daskalantonakis, M.: A Practical View of Software Measurement and Implementation Experiences Within Motorola. In: IEEE Trans. Software Eng. 18 (1992) 11, S. 998-1010.

[HS00] Harry, M.; Schroeder, R.: Six sigma. Doubleday, New York 2000. [Ka03]

Kan, S. H.: Metrics and Models in Software Quality Engineering. 2. Aufl., AddisonWesley, Upper Saddle River 2003.

[KM06] de Koning, H.; de Mast, J.: A rational reconstruction of Six-Sigma´s breakthrough coockbook. In: Int. Journ. of Quality & Reliability Management 23 (2006) 7, S. 766-787. [MPR05] Münch, J.; Pfahl, D.; Rus, I.: Virtual Software Engineering Laboratories in Support of Trade-off Analyses. In: Software Quality Journal 13 (2005) 4, S. 407–428.

254