Integration von Six Sigma und der Balanced Scorecard in das Assessment Model der ISO/IEC 15504-5 ("SPICE")

Inhaltsverzeichnis

Zusammenfassung

Abstract

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einleitung
1.1 Problemstellung
1.2 Zielsetzung der Arbeit
1.3 Vorgehensweise und Aufbau der Arbeit

2 SPICE
2.1 Zielsetzung von SPICE
2.2 Die Struktur von SPICE
2.3 Die Prozess-Dimension
2.3.1 Primary Life Cycle Processes
2.3.2 Organizational Life Cycle Processes
2.3.3 Supporting Life Cycle Processes
2.3.4 Base Practices und Generic Practices
2.4 Die Reifegrad-Dimension
2.4.1 Die Reifegradstufen
2.4.1.1 Level 0: Unvollständiger Prozess (Incomplete)
2.4.1.2 Level 1: Durchgeführter Prozess (Performed)
2.4.1.3 Level 2: Gelenkter Prozess (Managed)
2.4.1.4 Level 3: Etablierter Prozess (Established)
2.4.1.5 Level 4: Vorhersagbarer Prozess (Predictable)
2.4.1.6 Level 5: Optimierender Prozess (Optimizing)
2.4.2 Die Prozessbewertung

3 Six Sigma und Balanced Scorecard
3.1 Die Six Sigma Methode
3.1.1 Begriff und Zielsetzung von Six Sigma
3.1.2 Die Six Sigma Philosophie
3.1.2.1 Kundenorientierung
3.1.2.2 Prozessorientierung
3.1.2.3 Führung durch Metriken
3.1.3 Umsetzung von Six Sigma
3.1.3.1 DMAIC-Vorgehensmodell
3.1.3.2 Integration der Mitarbeiter
3.2 Das Balanced Scorecard Kennzahlensystem
3.2.1 Zielsetzung der Balanced Scorecard
3.2.2 Struktur und Aufbau der Balanced Scorecard
3.2.2.1 Finanzperspektive
3.2.2.2 Kundenperspektive
3.2.2.3 Interne Prozessperspektive
3.2.2.4 Lern- und Entwicklungsperspektive
3.2.2.5 Ursache-Wirkungs-Beziehungen zwischen den Perspektiven
3.2.3 Anwendung der Balanced Scorecard
3.2.3.1 Formulierung und Umsetzung von Vision und Strategie
3.2.3.2 Kommunikation und Verbindung
3.2.3.3 Planung und Vorgaben
3.2.3.4 Strategisches Feedback und Lernen

4 Integration von Six Sigma und der BSC in das Assessment Modell von SPICE
4.1 Einsatz von Six Sigma in der Software-Entwicklung
4.1.1 Design for Six Sigma (DFSS)
4.1.2 DMADV-Vorgehensmodell
4.1.2.1 Define-Phase
4.1.2.2 Measure-Phase
4.1.2.3 Analyze-Phase
4.1.2.4 Design-Phase
4.1.2.5 Verify-Phase
4.1.3 Wirkungen von DFSS und DMADV
4.2 Einsatz der Balanced Scorecard in der Software-Entwicklung
4.2.1 Anforderungen an BSC-Kennzahlen
4.2.2 Key Performance Indicators
4.3 Six Sigma vs. Balanced Scorecard
4.4 Integration in das Assessment Modell der ISO/IEC 15504-5
4.4.1 MAN.1 Organizational alignement
4.4.2 MAN.2 Organization management
4.4.3 MAN.4 Quality management
4.4.4 MAN.6 Measurement
4.4.5 PIM.2 Process assessment und PIM.3 Process improvement
4.4.6 RIN.1 Human resource management
4.4.7 RIN.2 Training
4.4.8 ENG.1 Requirements elicitation
4.4.9 ENG.4 Software requirements analysis
4.4.10 ENG.5 Software design
4.4.11 ENG.6 Software construction
4.4.12 Überblick über die Synergien und Beurteilung

5 Zusammenfassung und Ausblick

Literaturverzeichnis

Danksagung

Zu Beginn möchte ich Gott für alles, was ich im Leben bisher erreicht habe, danken.

Für die Erstellung und Unterstützung der vorliegenden Arbeit möchte ich mich beim Institut für Wirtschaftsinformatik und Quantitative Methoden, Fachgebiet Systemanalyse und EDV, Prof. Dr. H. Krallmann, bedanken.

Besonderer Dank gilt meinem Betreuer Herrn Josef Maier, der mir stets unterstützend zur Seite stand und damit maßgeblich zum Gelingen dieser Arbeit beitrug.

Mein herzlichster Dank gilt meiner Mutter Siddika Simsek und meinem Vater Remzi Simsek. Sie haben mich während meines Studiums stets unermüdlich und tatkräftig unterstützt. Widmen möchte ich diese Arbeit, neben meinen Eltern, auch meinem Onkel Ali Simsek und meiner Großmutter Zehra Akman, die beide während meiner Diplomarbeitszeit gestorben sind. Mögen sie in Frieden ruhen.

Schließlich möchte ich mich bei all meinen Verwandten, Bekannten und Freunden bedanken, die mich während meines Studiums auf unterschiedlichste Weise unterstützt haben.

Zusammenfassung

Die vorliegende Arbeit untersucht, wie die qualitätsbasierte Six Sigma Methode und das strategische Balanced Scorecard Kennzahlensystem den internationalen Standard ISO/IEC 15504 (SPICE) unterstützen können. Anhand eines mehrstufigen Reifegradmodells dient SPICE zur Bewertung und Verbesserung von Softwareentwicklungsprozessen.

Zum Verständnis werden zuerst die Grundlagen von SPICE durch die Auswertung verschiedener Literaturquellen erarbeitet. Darauf folgend werden die Six Sigma Methode und das Balanced Scorecard Kennzahlensystem umfassend beschrieben.

Anschließend wird die Zusammenarbeit von Six Sigma, Balanced Scorecard und SPICE analysiert und die Six Sigma Methode und das Balanced Scorecard Kennzahlensystem in das Assessment Modell von SPICE integriert.

Abstract

This paper examines how the quality-based method Six Sigma and the strategic measurement system Balanced Scorecard can support the international standard ISO/IEC 15504 (SPICE). On the basis of a capability maturity model provided SPICE the assessment and improvement of software development processes.

By the evaluation of different literature sources are initially the basics of SPICE represented. Following the Six Sigma method and the Balanced Scorecard measurement system are comprehensively described.

Finally the cooperation of Six Sigma, Balanced Scorecard and SPICE will be analyzed and the Six Sigma method and the Balanced Scorecard measurement system will be integrated into the assessment model of SPICE.

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Struktur von SPICE

Abbildung 2: Prozess- und Assessmentmodell von SPICE

Abbildung 3: Prozessarchitektur von SPICE

Abbildung 4: Level 1 – Details des Prozesses sind unbekannt

Abbildung 5: Level 2 – Grob strukturierter systematischer Prozess

Abbildung 6: Level 3 – Organisationsweit standardisierter detaillierter Prozess

Abbildung 7: Level 4 – Quantitativ überwachter und gesteuerter Prozess

Abbildung 8: Level 5 – Ständig verbesserter Prozess

Abbildung 9: SPICE-Reifegradstufen

Abbildung 10: Standardabweichung σ um den Mittelwert

Abbildung 11: Kostensenkung bei Erhöhung der Qualität

Abbildung 12: Grundmodell der Balanced Scorecard

Abbildung 13: Prozess-Wertschöpfungskette der internen Perspektive

Abbildung 14: Beispiel für ein Ursache-Wirkungs-Diagramm

Abbildung 15: Strategischer Handlungsrahmen der Balanced Scorecard

Abbildung 16: DMAIC-Prozess vs. DMADV-Prozess

Abbildung 17: Kundenzufriedenheit im Kano-Modell

Abbildung 18: Ablauf einer FMEA

Abbildung 19: Verlustfunktion von Taguchi

Abbildung 20: QM-Werkzeuge im DMADV-Zyklus

Tabellenverzeichnis

Tabelle 1: Reifegradstufen und ihre Prozessattribute

Tabelle 2: Six Sigma Qualitätsniveau

Tabelle 3: DMAIC als Six Sigma Prozess im Projekt

Tabelle 4: Einige Themen der Six Sigma Kurse

Tabelle 5: Ziele und Messgrößen der Finanzperspektive

Tabelle 6: Ziele und Messgrößen der Kundenperspektive

Tabelle 7: Ziele und Messgrößen der internen Prozessperspektive

Tabelle 8: Ziele und Messgrößen der Lern- und Entwicklungsperspektive

Tabelle 9: Beispiel für eine Leistungszulage auf Basis der BSC

Tabelle 10: Design for Six Sigma vs. Six Sigma

Tabelle 11: SPICE-Prozesse mit Synergien zur BSC

Tabelle 12: SPICE-Prozesse mit Synergien zu Six Sigma

Tabelle 13: In Verbindung stehende Prozesse und Prozessattribute

1 Einleitung

1.1 Problemstellung

Software geht mittlerweile jeden was an. Sie hat in unser aller Leben Einzug gehalten. Als Innovationsfaktor Nummer eins bei technischen Produkten ist sie nicht nur im heimischen oder Büro-PC zu finden, sondern in der Zwischenzeit auch in jedem Fernseher, Kühlschrank, Waschmaschine, Kraftfahrzeug und unzähligen weiteren technischen Produkten und industriellen Anlagen. Insofern ist Software ein wesentlicher Faktor in vielen Industriebereichen.^[1]

Der Anteil an Software weist in vielen Produkten eine steigende Tendenz auf und das nicht lediglich durch die ständige Erweiterung des Leistungsumfangs vieler Produkte und Systeme, sondern auch durch die zunehmende Verlagerung von Hardware-Funktionalität in Software. Die Einsatztauglichkeit der Produkte bzw. die Leistung und Anerkennung der jeweiligen Unternehmen hängt maßgeblich von der Qualität ihrer Software ab. Die Produktqualität wird also erheblich von der Softwarequalität beeinflusst. Im Rahmen der immer mehr steigenden Komplexität von Produkten und Systemen sind typische Qualitätsaspekte für Software die Fehlerfreiheit, Zuverlässigkeit, Anpassbarkeit, Erweiterbarkeit sowie die rechtzeitige Bereitstellung und Günstigkeit. Die Qualitätsaspekte werden während des Softwareentwicklungsprozesses festgelegt.^[2]

Um die Softwareentwicklungsprozesse systematisch zu untersuchen bzw. zu verbessern, gibt es verschiedene Standards und Reifegradmodelle. Eines davon ist die Qualitätsnorm ISO/IEC 15504, auch bekannt unter dem Namen SPICE (Software Process Improvement and Capability Determination). Allerdings sind derartige Modelle im Kontext erst gut zu verstehen und dann anzuwenden, um eine eventuelle Zusatzarbeit zu vermeiden. Der erste Schritt für eine planmäßige Prozessverbesserung ist bei solchen Modellen die Prozessbewertung. Die qualitative Bewertung (Assessment) wird anhand eines mehrstufigen Reifegradmodells durchgeführt. Eine Prozessverbesserung findet dann statt, wenn eine höhere Reifegradstufe erreicht wird.^[3]

Das SPICE-Modell stellt einen generellen Rahmen für eine systematische Bewertung und Verbesserung von Softwareentwicklungsprozessen dar. In ihm sind lediglich sehr allgemein gehaltene Anforderungen von zuverlässigen und erfolgreichen Verfahren und Vorschriften formuliert, damit die Vielzahl von unterschiedlichen Organisationen, Branchen und Projekten sich bei ihrer Prozessgestaltung an dem Modell stützen können. Mit Hilfe von Reifegraden sollen grundsätzliche Handlungen und das Leistungsvermögen eines Softwareentwicklungsprozesses gemessen, anschließend beurteilt und verbessert werden.^[4]

Im Spannungsfeld verschiedener Anspruchsgruppen sollte in der Praxis die Bewertung und Verbesserung von Prozessen zusätzlich durch eine Reihe von Methoden und Instrumenten unterstützt werden. In Unternehmen sind insbesondere die qualitätsbasierte Six Sigma Methode und das strategische Balanced Scorecard Kennzahlensystem hoch geschätzt.

Six Sigma ist eine formalisierte, systematische und äußerst ergebnisorientierte Führungsmethode, die unternehmensweit sowohl für das produzierende Gewerbe als auch für den Dienstleistungsbereich anwendbar ist. Six Sigma zielt darauf ab, jedes Produkt, jeden Prozess und jede Transaktion nahezu fehlerfrei zu gestalten bzw. ihre Qualität kontinuierlich zu verbessern, um auf diese Weise die Kundenzufriedenheit zu erhöhen.^[5] Six Sigma und Software-Prozessverbesserungsinitiativen wie SPICE vervollständigen sich bei ihrer Arbeit. Das Prozessdenken spielt bei beiden eine entscheidende Rolle. Die Verbesserung von Software bzw. der Ergebnisse eines Prozesses werden nicht durch Software-Tests erreicht, sondern durch Verbesserung des Herstellungsprozesses.^[6]

Die Balanced Scorecard (BSC) ist ein Führungsinstrument. Sie übersetzt die Mission und Strategie eines Unternehmens in ein übersichtliches System zur Leistungsmessung. Die Leistung des Unternehmens wird dabei im Allgemeinen aus der Finanzperspektive, Kundenperspektive, internen Prozessperspektive sowie aus der Lern- und Entwicklungsperspektive gemessen.^[7] Das Balanced Scorecard Kennzahlensystem soll die Unternehmensleitung bei der Realisierung und Beurteilung der Strategieumsetzung unterstützen.^[8] Die Balanced Scorecard zielt nicht nur auf die Entwicklung von strategierelevanten Unternehmenszielen und Kennzahlen sondern auch auf die ganzheitliche Steuerung und Führung des Unternehmens mit Hilfe dieser Kennzahlen. Sie ist also ein Kennzahlen- und Managementsystem.^[9] Kennzahlen werden in SPICE ab Level 4 verlangt. Dabei sollen im Rahmen eines effektiven Messsystems geeignete Kennzahlen aufgestellt werden, um die Ausführung der Prozesse und die Qualität der Arbeitsprodukte zu erfassen und Analysen zu unterstützen.^[10]

1.2 Zielsetzung der Arbeit

In den letzten Jahren hat sich SPICE zu einem der aussichtsreichsten Modelle in europäischen Unternehmen entwickelt. Das systematische SPICE-Modell kann sowohl zur Bewertung der eigenen Softwareentwicklung als auch zur Bewertung anderer Entwicklungspartner und Zulieferer verwendet werden. Um die steigenden Anforderungen an die Qualität und Effizienz zufrieden zu stellen, muss dass Assessment Modell von SPICE (ISO/IEC 15504-5) eventuell durch weitere Methoden und Instrumente, wie z. B. Six Sigma und Balanced Scorecard, unterstützt werden. In Deutschland ist SPICE noch ein wenig erforschtes Thema. Deshalb gibt es zu dieser Themenstellung kaum deutschsprachige Literatur.

Aus diesem Anlass ist das Ziel der vorliegenden Arbeit, die unterschiedlichen Modelle zur Bewertung und Verbesserung von Prozessen miteinander zu verknüpfen. Dabei soll die Six Sigma Methode und das Balanced Scorecard Kennzahlensystem in das Assessment Modell von SPICE integriert werden. Die Arbeit soll die wesentlichen Grundlagen von SPICE, Six Sigma und Balanced Scorecard aufzeigen und anschließend die Zusammenarbeit bzw. das Rollenverständnis der Modelle untereinander klarstellen sowie miteinander integrieren.

1.3 Vorgehensweise und Aufbau der Arbeit

Die Problemstellung und Zielsetzung erfordert zum Verständnis von SPICE zunächst eine umfassende Darstellung der Grundlagen, die in Kapitel zwei behandelt werden. Hierunter werden die wesentlichen Aspekte wie Zielsetzung, Struktur, Prozess-Dimension und Reifegrad-Dimension mit den einzelnen Reifegradstufen von SPICE vorgestellt und genauer erläutert. Anschließend wird die Prozessbewertung (Assessment) dargestellt, um feststellen zu können, ob und inwieweit die Anforderungen der jeweiligen Reifegradstufen von den Einzelprozessen erfüllt werden.

Im dritten Kapitel werden zwei anerkannte und unternehmensweit angewendete Qualitätswerkzeuge zur Bewertung und Verbesserung von Prozessen detailliert betrachtet. Diese sind die Six Sigma Methode und das Balanced Scorecard Kennzahlensystem. Dabei werden die Begriffe und Zielsetzungen, die Philosophie bzw. die Struktur und die Vorgehensweise bei der Umsetzung der beiden Werkzeuge ausgearbeitet und interpretiert.

Die beiden Qualitätswerkzeuge werden im vierten Kapitel in das Assessment Modell von SPICE integriert. Hierbei werden zunächst die Funktionen der beiden Werkzeuge im Software- und IT-Bereich näher erforscht. Anschließend wird eine Betrachtung und Analyse über die Zusammenarbeit von Six Sigma, Balanced Scorecard und SPICE durchgeführt bzw. die Six Sigma Methode und das Balanced Scorecard Kennzahlensystem in das Assessment Modell von SPICE integriert.

Im abschließenden fünften Kapitel werden in Form eines Fazits die wesentlichen Feststellungen und Erfahrungen bei der Integration von Six Sigma und der Balanced Scorecard in das Assessment Modell von SPICE noch einmal kurz zusammengefasst und kritisch gewürdigt.

2 SPICE

In den letzten Jahrzehnten sind eine Reihe von Modellen zur Bewertung und Verbesserung von Softwareentwicklungsprozessen entwickelt worden. Diese Modelle werden auch als Reifegradmodelle bezeichnet. Ihre Beurteilungen, Begutachtungen und Empfehlungen sollen zum besseren Management der Entwicklungsprozesse dienen. SPICE (Software Process Improvement and Capability Determination), auch bekannt unter der Norm ISO/IEC 15504, ist eines dieser Reifegradmodelle. Hierunter werden zuverlässige und zweckvolle Verfahren in systematischer Form in einem Modell festgehalten. Die Formulierung der Verfahren erfolgt dabei sehr allgemein, da sie auf eine große Anzahl von unterschiedlichen Unternehmen, Branchen und Projekten angepasst werden sollen. Unternehmen können sich somit bei ihrer Prozessgestaltung an diese Verfahren stützen. Die Prozessgestaltung ist äußerst bedeutungsvoll, da die Qualität des Softwareentwicklungsprozesses erheblich die Qualität der Software beeinflusst.^[11]

2.1 Zielsetzung von SPICE

Das 1992 gestartete SPICE-Projekt hat das Ziel, eine international anerkannte Norm zur Bewertung (Assessment) und Verbesserung (Improvement) von Softwareprozessen zu entwickeln. Insbesondere sollten die Konzeptionen der ISO 9000 und des CMM (Capability Maturity Model) aufgenommen und weiterentwickelt werden.^[12] Das Reifegradmodell CMM ist in den USA entwickelt worden. Im Bereich des Softwareentwicklungsprozesses hat es bereits die nötige Anerkennung in den USA erreicht. Es wurde später durch das CMMI (Capability Maturity Model Integration) ersetzt. International agierende Unternehmen wollen sich nicht nur auf ein national oder regional verbreitetes Modell einlassen. Aus diesem Grunde sind Modelle wie SPICE und CMMI besonders für international handelnde Unternehmen geeignet, die schwerpunktmäßig in Europa bzw. in den USA geschäftig sind. SPICE stellt also in gewisser Weise das europäische Pendant zum CMMI dar.^[13]

Bei der Verfolgung der Zielsetzung, eine internationale Norm für Prozessbewertungen zu etablieren, orientierte sich SPICE an ISO 12207. Dieser Standard beschreibt die einzelnen Prozesse der Softwareentwicklung und -erhaltung. SPICE hat dabei die Gliederung der Prozessbereiche wesentlich weiter verfeinert und im Jahre 1998 als Technischen Report ISO/IEC TR 15504 verabschiedet. Diese neue Norm ermöglicht eine einheitliche Bewertung des Potenzials einer Organisationseinheit hinsichtlich Entwicklung, Einführung und Überwachung von Software-Systemen. Sie offenbart im Einzelnen, wie Bewertungen und deren Ergebnisse anzupacken und anschließend darzulegen sind und wie daraus Maßnahmen bzw. neue Ausführungsbestimmungen abgeleitet werden können.^[14] Deshalb sollte SPICE insbesondere als Reifegradmodell bezeichnet werden, auch wenn es in vielen wissenschaftlichen Publikationen als Prozessmodell ausgedrückt wird, da es neben den Prozessen auch Messverfahren präsentiert mit denen ein Unternehmen die Qualität seiner Entwicklungsprozesse bestimmen kann. Eine Qualitätssteigerung der jeweiligen Produkte kann durch frühzeitigeres und effizienteres Prüfen, systematischeres und eindeutigeres Vorgehen bzw. durch mehr interaktive Ausführungen erreicht werden.^[15]

SPICE setzt für das Software Engineering bzw. für die Softwareentwicklung keine ausdrücklichen Methoden, Vorschriften, Organisationsformen und Managementtechniken voraus. Es stellt einen grundsätzlichen Rahmen für die Bewertung und Verbesserung von Softwareentwicklungsprozessen zur Verfügung und formuliert lediglich Anforderungen, die von den Unternehmen selbst für den jeweiligen Zweck konkretisiert werden müssen.^[16] Daher ermöglicht SPICE mit Hilfe von Reifegraden die grundsätzlichen Ausführungen (Base Practices) und das Leistungsvermögen (Management Practices) eines Softwareentwicklungsprozesses zu messen und anschließend zu beurteilen.^[17]

2.2 Die Struktur von SPICE

Der ursprünglich als Technischer Report verabschiedete Standard ISO/IEC TR 15504 bestand aus neun Teilen. Der neue und modifizierte Standard ISO/IEC 15504 besteht nunmehr aus fünf Teilen. Davon hat nur ein Teil einen normativen Charakter, die restlichen sind eher informativ.^[18] Die fünf Teile des gegenwärtigen Standards werden folgend kurz beschrieben:^[19]

- Teil 1: Hier sind Konzepte für Prozessassessments und Anleitungen für Terminologien enthalten.
- Teil 2: Der einzig normative Teil des neuen SPICE. Er beinhaltet Anforderungen an die Referenzmodelle, die bei der Durchführung eines Assessments einzuhalten sind. Weiterhin ist in ihr das Reifegradmodell dargestellt, welches für die Bewertung der Prozesse die möglichen Stufen und Eigenschaften bestimmt.
- Teil 3: Dieser Teil stellt einen Leitfaden zur Interpretation der in Teil 2 definierten Anforderungen dar.
- Teil 4: Dieser Teil ist ein Leitfaden zur Durchführung von Prozessassessments im Rahmen eines Prozessverbesserungsprogramms oder einer Prozessreifegradbestimmung.
- Teil 5: Hier wird ein beispielhaftes Prozess- und Assessmentmodell nach den Anforderungen von Teil 2 demonstriert.

Die neue Norm lässt die Verwendung verschiedener Prozessreferenz- und Assessmentmodelle zu.^[20] Wesentliche Änderungen gegenüber dem alten Standard sind insbesondere, dass in Teil 2 das alte „Referenzmodell“ durch „Anforderungen an Referenzmodelle“ und in Teil 5 das alte „Assessmentmodell“ durch ein „Beispiel-Prozessassessmentmodell“ ersetzt wurde. Somit können alle Modelle, die den Anforderungen aus Teil 2 erfüllen, als Prozess- und Assessmentmodelle dienen. Demzufolge können alternative Modelle wie CMMI und ISO 9000 als SPICE-konforme Prozess- und Assessmentmodelle eingesetzt werden.^[21]

Im Mittelpunkt des Modells steht die Prozessbewertung (Assessment). Diese dienen sowohl zur Reifegradbestimmung der Prozesse als auch zum Aufzeigen der Verbesserungsmöglichkeiten von Prozessen durch geeignete Modifikationen. Das Assessment kann sich auf die eigene Software-Entwicklung oder auf andere Unternehmen beziehen. Schwerpunkt ist dabei die Selbstbewertung (Self-Assessment) und nicht die Zertifizierung.^[22] Die untere Abbildung veranschaulicht die Struktur des SPICE-Prozesses.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Struktur von SPICE^[23]

Die zentralen Aufgabenbereiche des SPICE sind dementsprechend die Prozessbewertung und die daraus beabsichtigte Prozessverbesserung und Reifegradbestimmung. Assessments sollen Unternehmensprozesse beschreiben, analysieren und beurteilen. In Anbetracht der gesetzten Zielsetzungen sind dabei insbesondere die Abläufe der bedeutungsvollen Prozesse zu überprüfen sowie eventuelle Fehler und Schwachstellen aufzuzeigen. Anschließend sind die möglicherweise vorhandenen Fehler und Schwachstellen zu bekämpfen bzw. Verbesserungspotenziale noch effektiver zu identifizieren und auszuschöpfen. Im Hinblick auf die existierenden Stärken und Schwächen bzw. der Chancen und Risiken gewisser Teilprozesse wird mit der Reifegradbestimmung (Capability Determination) die Fähigkeit der Prozesse ermittelt, ob ein Unternehmen in der Lage ist, vorgegebene Anforderungen zu erfüllen.^[24]

Die Bewertung von Prozessen wird anhand von Base Practices und Work Products durchgeführt. Die einzelnen Prozessattribute jedoch werden in Abhängigkeit der jeweiligen Management Practices bzw. mittels der Ressourcen- und Infrastruktureigenschaften des Unternehmens bewertet.^[25] Das Referenz- und Assessmentmodell von SPICE besteht dabei zwei Dimensionen, die Prozess-Dimension (basierend auf ISO 12207) und die Reifegrad-Dimension (basierend auf CMM).^[26]

2.3 Die Prozess-Dimension

Die Prozess-Dimension dient zur Kennzeichnung der Vollständigkeit von Prozessen. Aus diesem Anlass beschreibt SPICE für die Softwareentwicklung ein detailliertes Prozessmodell. Das Modell enthält für alle relevanten Prozesse

- den Zweck des Prozesses,
- die Ergebnisse, die mit dem Prozess erreicht werden,
- die auszuführenden Base Practices um die Ziele zu erreichen und
- eine Beschreibung der Eingangsinformationen und Arbeitsergebnisse jedes Prozesses.^[27]

Im beispielhaften Prozess- und Assessmentmodell von SPICE (ISO/IEC 15504-5) werden die einzelnen Prozesse, basierend auf die ISO/IEC 12207, in neun Prozessgruppen unterteilt. ISO/IEC 12207 definiert einen Rahmen für Prozesse im Lebenszyklus von Software. Die Prozessgruppen wiederum werden dadurch in drei Kategorien eingeteilt. Dies und die dazugehörigen wesentlichen Prozesse werden in der folgenden Abbildung dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Prozess- und Assessmentmodell von SPICE^[28]

2.3.1 Primary Life Cycle Processes

Unter Primary Life Cycle Processes sind die wesentlichen Prozessgruppen erfasst, die die primären Bedürfnisse einer Software, wie Entwicklung, Betrieb und Wartung, im Lebenszyklus unterstützen. Diese sind insbesondere die Kunden, Lieferanten, Entwickler, Anwender und Verkäufer,^[29] die im Prozess- und Assessmentmodell von SPICE in folgende vier Prozessgruppen unterteilt werden:

- Acquisition (ACQ): Diese Prozessgruppe umfasst Prozesse bezüglich der Kunden, die ein Produkt oder eine Dienstleistung anfordern. Hierbei kann auch ein Lieferant als Kunde dienen, wenn er ein Produkt oder einen Service von einem anderen Lieferanten erwirbt.
- Supply (SPL): Die vom Lieferanten durchgeführten Prozesse, um ein Produkt oder eine Dienstleistung anzubieten bzw. zu liefern, werden in dieser Prozessgruppe erfasst.^[30]
- Engineering (ENG): In dieser Prozessgruppe werden alle Prozesse erfasst, die sich direkt auf die Entwicklung, Implementierung und Wartung von Softwareprodukten beziehen.^[31]
- Operation (OPE): Hierunter werden Prozesse beschrieben, die für den korrekten Betrieb und der Anwendung eines Produktes oder einer Dienstleistung zur Verfügung gestellt werden.^[32]

2.3.2 Organizational Life Cycle Processes

Organizational Life Cycle Processes beinhalten Prozesse, die eine einheitliche Unternehmenskultur, sowohl auf Management-Ebene als auch auf Mitarbeiter-Ebene, entwickeln und verbreiten sollen, um auf diese Weise die damit verbunden Lebenszyklusprozesse ununterbrochen zu verbessern.^[33] Die Prozesse werden folgendermaßen gruppiert:

- Management (MAN): In dieser Prozessgruppe werden sämtliche Prozesse beschrieben, die für die Planung, Steuerung und Kontrolle von Projekten erforderlich sind, wie z. B. Projektmanagement, Risikomanagement und Qualitätsmanagement.^[34]
- Prozess Improvement (PIM): Hierunter sind alle Prozesse enthalten, die durchgeführt werden, um die Definition, Einrichtung, Bewertung und Verbesserung der Prozesse im Unternehmen zu organisieren.
- Resource and Infrastructure (RIN): Diese Prozessgruppe besteht aus Prozessen, die eine ausreichende Kompetenz der Mitarbeiter bzw. die erforderliche Infrastruktur des Unternehmens gewährleisten sollen.
- Reuse (REU): Hierunter werden Prozesse zur Ausnutzung von Wiederverwendungsmöglichkeiten beschrieben.^[35]

2.3.3 Supporting Life Cycle Processes

Unter Supporting Life Cycle Processes (SUP) sind Hilfsprozesse gruppiert, die im Rahmen der Realisierung anderer Prozesse in einem Projekt an unterschiedlichen Stellen Unterstützung leisten.^[36]

2.3.4 Base Practices und Generic Practices

Die einzelnen Prozesse werden in SPICE durch Base Practices und Generic Practices näher beschrieben. Diese stellen wichtige Tätigkeiten im Zusammenhang mit der Softwareentwicklung vor. Base Practices sind prozessspezifisch und betreffen nur bestimmte Prozesse. Generic Practices dagegen sind ausnahmslos gültig, d. h. sie sind für alle Prozesse anzuwenden. Vergleichbar mit den Grundsätzen ordnungsmäßiger Buchführung im Rechnungswesen, sind hier allgemeingültige Grundsätze erarbeitet worden, die prinzipiell anerkannte und branchenübliche Tätigkeiten (Industry’s Good Practice) darstellen. Im Großen und Ganzen sollten Softwareunternehmen diese Tätigkeiten beherrschen.^[37] In der anknüpfenden Abbildung wird zusammenfassend die Prozessarchitektur von SPICE dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Prozessarchitektur von SPICE^[38]

2.4 Die Reifegrad-Dimension

In der Reifegrad-Dimension wird die Leistungsfähigkeit von Prozessen durch Prozessattribute ausgedrückt. Insgesamt gibt es neun Prozessattribute, die den Reifegradstufen zugeordnet sind. Zur Bestimmung der Prozessreife (Capability Determination) verwendet SPICE (ISO/IEC 15504 Teil 2) ein sechsstufiges Reifegradmodell. Die Reifegradstufen dienen zur Bewertung der Vollständigkeit und Leistungsfähigkeit der Prozesse eines Unternehmens. Der Reifegrad wird für jeden Prozess einzeln bestimmt. Das Erreichen einer nächsthöheren Reifegradstufe ist ein Anzeichen für Prozessverbesserungen. Zu beachten ist insbesondere, dass mit Reifegraden einzelne Prozesse beurteilt werden und keinesfalls Unternehmen oder Projekte.^[39]

Anhand von Prozessattributen erfolgt eine Einstufung der Einzelprozesse in die Reifegradstufen. Die Prozessattribute sind objektiv und weisen beobachtbare bzw. messbare Qualitätseigenschaften bei der Durchführung von Software-Entwicklungsprozessen auf.^[40] In ISO/IEC 15504 Teil 5 wird „Prozessattribut“ folgendermaßen definiert:

„Prozessattribute sind Eigenschaften eines Prozesses. Sie können auf einer leistungsorientierten Skala beurteilt werden und geben dadurch ein Maß für die Leistungsfähigkeit eines Prozesses. Sie sind auf alle Prozesse anwendbar…“^[41]

Die Prozessattribute charakterisieren die einzelnen Reifegradstufen inhaltlich. Die unterste Reifegradstufe (Level 0) besitzt kein Prozessattribut. Um eine bestimmte Reifegradstufe zu erreichen, muss ein Prozess die entsprechenden Anforderungen (Prozessattribute) und alle darunter liegenden Anforderungen erfüllen.^[42] Folgende Tabelle veranschaulicht die Reifegradstufen (Capability Levels) mit ihren zugehörigen Prozessattributen:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Reifegradstufen und ihre Prozessattribute^[43]

Jedes Prozessattribut enthält zudem Management-Aktivitäten. Diese sollen die Überprüfung gewährleisten, inwieweit die Anforderungen durch einen Einzelprozess erfüllt werden.^[44]

2.4.1 Die Reifegradstufen

2.4.1.1 Level 0: Unvollständiger Prozess (Incomplete)

Hierunter wird ein Prozess verstanden, der nicht implementiert ist oder seinen Zweck nicht erfüllt. Für ein systematisches Erreichen des Prozesszwecks gibt es keine oder sehr geringfügige Anhaltspunkte. Level 0 ist die einzige Reifegradstufe, die kein Prozessattribut besitzt. Level 0 wird meistens vergeben, wenn ein Unternehmen beschließt, das SPICE-Modell anzuwenden.^[45]

2.4.1.2 Level 1: Durchgeführter Prozess (Performed)

Der implementierte Prozess ist weitgehend verstanden. Zielsetzung und Prozessergebnisse werden erreicht. Es findet aber bei der Zielerreichung keine disziplinierte Planung und Verfolgung von Projektarbeiten statt.^[46] Zwar können Einzelpersonen innerhalb der Organisation notwendige Tätigkeiten erkennen bzw. durchführen, jedoch bleiben die einzelnen Bestandteile des Prozesses zwischen Prozessbeginn und Prozessende unbekannt.^[47] Dies wird in der anschließenden Abbildung verdeutlicht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Level 1 – Details des Prozesses sind unbekannt^[48]

Level 1 besitzt das Prozessattribut „PA 1.1 Prozessdurchführung“. Dieses stellt fest, in welchem Ausmaß ein Prozess mit eindeutig definierten Eingaben (Inputs) eindeutig definierte Ergebnisse (Outputs) liefert. Das Prozessattribut PA 1.1 hat die generische Praktik „GP 1.1.1 Erziele die Prozessergebnisse“. Diese ist ein Maß für die Erreichung der Prozessergebnisse, die zum einen durch Verrichtung von Basispraktiken (Base Practices) und zum anderen durch Herstellung von Arbeitsprodukten (Work Products) unterstützt werden.^[49]

2.4.1.3 Level 2: Gelenkter Prozess (Managed)

Die für den Prozess vorgesehenen Verfahrensweisen werden geplant und angewendet. Anschließend werden die erreichten Ergebnisse kontrolliert. Alle relevanten Vorgaben bzw. Anforderungen werden grundsätzlich von den erzielten Arbeitsergebnissen erfüllt.^[50] Der wesentliche Unterschied zur vorherigen Stufe ist, dass die Prozessausführungen jetzt systematisch geplant, überwacht und angepasst werden. Dadurch wird die Vorhersagbarkeit bezüglich der Erzielung der Ergebnisse und Termine erhöht.^[51] Die nachfolgende Abbildung veranschaulicht diese grob strukturierte systematische Vorgehensweise.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Level 2 – Grob strukturierter systematischer Prozess^[52]

Level 2 fordert Prozessattribute zur Gewährleistung der Nachvollziehbarkeit von Prozessen und Ergebnissen. Das Prozessattribut „PA 2.1 Management der Prozessdurchführung“ (Performance Management) setzt, bezogen auf die Prozesse, eine Zieldefinition der Ergebnisse unter Berücksichtigung der befindlichen Ressourcen voraus. Das Prozessattribut „PA 2.2 Management der Arbeitsprodukte“ (Work Product Management) beschäftigt sich mit der Definition der Anforderungen an die Ergebnisse und die Verknüpfungen zwischen den Ergebnissen. Einerseits muss also deutlich definiert werden, wie die Ergebnisse aussehen sollen bzw. welche Qualität sie aufweisen müssen und andererseits wie die Ergebnisse und Ziele erreicht werden können.^[53]

Das Prozessattribut PA 2.1 besitzt sechs generische Praktiken (GP). Diese beschreiben grundsätzliche Projektmanagementprinzipien, die aber nur auf den jeweiligen Prozess angewendet werden und nicht auf das Projekt als Ganzes. PA 2.2 weist vier generische Praktiken auf. Sie betreffen die Anforderungen an die Arbeitsprodukte des jeweiligen Prozesses hinsichtlich Inhalt, Struktur und Qualität bzw. deren Dokumentation, Lenkung und Review.^[54]

[...]

---

^[1] Vgl. Hindel et al. (2004), S. 1.

^[2] Vgl. Hörmann et al. (2006), S. 3.

^[3] Vgl. Rezagholi (2004), S. 2.

^[4] Vgl. Hörmann et al. (2006), S. 5.

^[5] Vgl. Magnusson et al. (2001), S. 4.

^[6] Vgl. Fehlmann (2005), S. 31.

^[7] Vgl. Kaplan und Norton (1997), S. 2.

^[8] Vgl. Löbel et al. (2001), S. 83 f.

^[9] Vgl. Reimer (2005), S. 292.

^[10] Vgl. Hörmann et al. (2006), S. 261.

^[11] Vgl. Hörmann et al. (2006), S. 4 ff.

^[12] Vgl. Rezagholi (2004), S. 20 f.

^[13] Vgl. Thaller (2000), S. 80.

^[14] Vgl. Stienen (1999), S. 18.

^[15] Vgl. Wentzel und Rastofer (2006), S. 49 f.

^[16] Vgl. Mellis et al. (1998), S. 110.

^[17] Vgl. MID (2005), S. 2.

^[18] Vgl. Wentzel und Rastofer (2006), S. 50.

^[19] Vgl. Hörmann et al. (2006), S. 13 f.

^[20] Vgl. Hörmann et al. (2006), S. 14.

^[21] Vgl. Wentzel und Rastofer (2006), S. 50.

^[22] Vgl. Gräbe (2005), S. 23.

^[23] In Anlehnung an Balzert (1998), S. 378.

^[24] Vgl. Mellis et al. (1998), S. 110 f.

^[25] Vgl. Hertel (1998), S. 64 ff.

^[26] Vgl. Estermann et al. (2002), S. 29.

^[27] Vgl. Andelfinger et al. (2005), S. 148.

^[28] Vgl. ISO/IEC 15504-5 (2006), S. 4.

^[29] Vgl. ISO/IEC 15504-5 (2006), S. 5.

^[30] Vgl. ISO/IEC 15504-5 (2006), S. 5.

^[31] Vgl. Balzert (1998), S. 379.

^[32] Vgl. ISO/IEC 15504-5 (2006), S. 6.

^[33] Vgl. ISO/IEC 15504-5 (2006), S. 7.

^[34] Vgl. Balzert (1998), S. 379.

^[35] Vgl. ISO/IEC 15504-5 (2006), S. 7 f.

^[36] Vgl. Andelfinger et al. (2005), S. 154.

^[37] Vgl. Mellis et al. (1998), S. 113; Hörmann et al. (2006), S. 221.

^[38] Vgl. Mellis et al. (1998), S. 112.

^[39] Vgl. Balzert (1998), S. 380.

^[40] Vgl. Andelfinger et al. (2005), S. 163.

^[41] Hörmann et al. (2006), S. 222.

^[42] Vgl. Andelfinger et al. (2005), S. 164.

^[43] In Anlehnung an Hörmann et al. (2006), S. 16.

^[44] Vgl. Balzert (1998), S. 381.

^[45] Vgl. Hörmann et al. (2006), S. 226.

^[46] Vgl. Rezagholi (2004), S. 22.

^[47] Vgl. Andelfinger et al. (2005), S. 164 f.

^[48] In Anlehnung an Andelfinger et al. (2005), S. 165.

^[49] Vgl. Hörmann et al. (2006), S. 227.

^[50] Vgl. Mellis et al. (1998), S. 115.

^[51] Vgl. Hörmann et al. (2006), S. 229.

^[52] In Anlehnung an Andelfinger et al. (2005), S. 166.

^[53] Vgl. Wallmüller (2001), S. 101 f.

^[54] Vgl. Hörmann et al. (2006), S. 230.