• Keine Ergebnisse gefunden

Six Sigma in der Software-Entwicklung

N/A
N/A
Protected

Academic year: 2022

Aktie "Six Sigma in der Software-Entwicklung"

Copied!
2
0
0

Wird geladen.... (Jetzt Volltext ansehen)

Volltext

(1)

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 Statisti- scher Prozessregelung herausgestellt werden [ähnlich bei KM06; HS00, 274]. Im Fol- genden wird die Anwendbarkeit dieser Konzepte und deren Umsetzung, v. a. durch Ana- logien oder bereits vorhandene Ansätze in der Softwareentwicklung, erörtert.

Six Sigma konzentriert sich auf die Reduzierung von Variation bei den qualitätskriti- schen Steuerparametern, die das Ergebnis stark beeinflussen. Balzert [Ba98, 12ff.] stellt einige empirische Untersuchungen zusammen, die zeigen, dass die Variation von Ein- flussfaktoren 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ög- lich, jedoch nicht mit den statistischen Methoden von Six Sigma. Gleichzeitig überde- cken diese Einflussfaktoren aber sowohl die Problemursachen, wie auch die Effekte der Prozessverbesserung bei den für Six Sigma zugänglichen Problemstellungen. Die Defini- tion der Prozessfähigkeit als Maß für die Effizienz über denAufwand in MM pro Functi- on Point wäre ein probates Mittel, um Prozessverbesserungen normiert und anwen- dungsneutral 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 dierolled throughput yield– die Wahrscheinlichkeit, dass eine Produkteinheit den gesamten Produktionsprozess fehler- frei passiert [HS00]. So hat ein Prozess, der das Niveau von6 Sigmaerfüllt, einertyvon 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 derdefect removal effectivenessexistiert aber eine analoge Metrik, die Aus- sagen über die Effizienz der Fehlerbeseitigung macht und dabei softwarespezifische Besonderheiten wie die neuerliche Fehlereinführung bei der Fehlerberichtigung berück- sichtigt. Basierend auf derdrekönnen Effektivitätsmetriken für die einzelnen Entwick- lungsphasen kalkuliert, verdichtet [Ka03, 165ff.], und somit als Datenbasis für Six Sig- 253

(2)

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 Softwareent- wicklung [Ka03, 470]. Da statistische Verfahren aber bestimmte Anforderungen diesbe- züglich stellen, kann bei einem Six Sigma Projekt in der Softwareentwicklung nur ein Teil der statistischen Methoden desDMAICeingesetzt werden. Des Weiteren sind kon- trollierte Experimente unter definierten Laborbedingungen mit einem hohen Aufwand verbunden, was mit ein Grund für ihre mangelnde Verbreitung in der Softwareentwick- lung 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 nvon der Qualität der letzten baugleichenx-1, x-2,etc. Zwischenprodukte auf die Quali- tät des Zwischenproduktesxgeschlossen. In der Softwareentwicklung ist diese Schluss- folgerung 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 Lebenszyk- lusmodell 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 Artefaktesxauf seine Qualität in der Entwicklungsphasen. Solche Modelle sind in der Softwareentwicklung als sog.reliability (growth) modelsbereits 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., Addison- Wesley, 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

Referenzen

ÄHNLICHE DOKUMENTE

An dieser Stelle ins Detail zu gehen würde den Rahmen dieses Buches zwar sprengen, aber seien Sie sich darüber im Klaren, dass eine Reihe von Menschen eine Menge Zeit damit

• Zertifikat Six Sigma Black Belt (nach erfolgreicher Prüfung) Sie haben bereits eine Ausbildung zum Six Sigma Green Belt erfolgreich absol-. viert und möchten sich nun zum Black

• Wenn man von Six Sigma spricht, ist damit in der Regel die Vorgehensweise nach DMAIC gemeint: In fünf klar strukturierten Projektphasen (Define, Measure, Analyze, Improve,

Weitere Aufgaben können die Ausbildung von Mitarbeitern zum Green Belt, Black Belt oder im Bereich Design for Six Sigma (DFSS) sein. Bei allen organisatorischen und

Integration von Lean und Six

Falls Sie eine MSA nach Verfahren 2/3 durchgeführt haben und die Gage R&R (Verfahren 2/3) nicht bestanden wurde, kann die MSA Typ 1 auf der Suche nach Ursachen und damit

Eine an der RWTH Aachen abgeschlossene Ausbildung zum „Six Sigma Green Belt“ oder zum „Lean Six Sigma Green Belt“ qualifiziert Sie automatisch für eine Teilnahme an der Black

PS: Nach bestandener Prüfung haben Sie die Möglichkeit, sich mit einem eigenen Praxisprojekt für die Zertifizierung zum „Six Sigma Green Belt“ zu qualifizieren!. Sprechen Sie