Prozessorientierten Qualitatsmanagementsystemen: Konzept zur Implementierung

Matthias Faerber Prozessorientiertes Qualitätsmanagement

GABLER RESEARCH

Matthias Faerber

Prozessorientiertes Qualitätsmanagement Ein Konzept zur Implementierung Mit einem Geleitwort von Prof. Dr.-Ing. Stefan Jablonski

RESEARCH

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

Dissertation Universität Bayreuth, 2010

1. Auflage 2010 Alle Rechte vorbehalten © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2010 Lektorat: Ute Wrasmann | Anita Wilke Gabler Verlag ist eine Marke von Springer Fachmedien. Springer Fachmedien ist Teil der Fachverlagsgruppe Springer Science+Business Media. www.gabler.de Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. 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. Umschlaggestaltung: KünkelLopka Medienentwicklung, Heidelberg Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier Printed in Germany ISBN 978-3-8349-2531-2

Geleitwort Das Thema Qualitätsmanagement gewinnt ständig an Bedeutung. Sichtbar wird diese Entwicklung unter anderem daran, dass sich immer mehr Unternehmen einer Zertifizierung unterziehen, welche die qualitativ angemessene Umsetzung ihrer Unternehmensprozesse belegt. Es ist interessant zu beobachten, dass sich die Entwicklung auch über Unternehmen hinaus mehr und mehr ausbreitet. Beleg hierfür ist der Wunsch, Bildungseinrichtungen, insbesondere Universitäten und Fachhochschulen, einer Zertifizierung zu unterziehen, welche hier (System-)Akkreditierung genannt wird. Die Durchführung einer Zertifizierung (oder auch Akkreditierung) bedeutet für ein Unternehmen (beziehungsweise eine Hochschule) einen enormen Aufwand. Dabei mag durchaus gelten, dass Unternehmen ihre Prozesse gemäß einem definierten Qualitätsmanagement ausgeführt haben. Dies bedeutet aber noch lange nicht, dass das Belegen dieser qualitativ angemessenen Ausführungen einfach, ohne großen Zusatzaufwand geschehen kann. An diesem Punkt setzt Herrn Dr. Faerbers Dissertation an. Am Beispiel der Entwicklung von Softwareprodukten zeigt er, wie Prozesse in einem Unternehmen gemäß einem definierten Qualitätsmanagementkonzept implementiert werden können, wobei die Implementierung so gestaltet ist, dass Prozessausführungen direkt als nachweisbarer Beleg eines etablierten Qualitätsmanagementkonzepts herangezogen werden können. Somit stellen sich zwei Vorteile ein: die Umsetzung eines Qualitätsmanagementkonzepts im Unternehmen und die automatische Erstellung von Belegen der Umsetzung dieses Konzepts. Viele Abhandlungen über Qualitätsmanagementsysteme diskutieren lediglich allgemein über die zu erreichenden Ziele beziehungsweise die einzuleitenden Maßnahmen; nur selten werden konkrete Handlungsanweisungen zur Umsetzung von Qualitätsmanagementansätzen vorgeschlagen. In dieser Hinsicht setzt sich Herrn Dr. Faerbers Dissertation deutlich von anderen Publikationen ab, da er eine konkrete, nachvollziehbar realisierbare, auf einem prozessorientierten Ansatz beruhende Methode zur Umsetzung eines Qualitätsmanagementsystems beschreibt. Die Methode ist in allen Phasen theoretisch und konzeptionell fundiert und stützt sich auf den aktuellen Wissensstand im Bereich des Qualitätsmanagements. Der Ansatz wird nicht nur konzeptionell entwickelt, sondern Herr Dr. Faerber bietet eine eigens dafür implementierte Softwareumgebung an, welche die direkte Umsetzung des Ansatzes ermöglicht. Dadurch ist die hier vorliegende Dissertation von großer praktischer Bedeutung für Unternehmen (aber auch für Hochschulen), welche eine Vorlage und Vorgabe zur prozessorientierten Umsetzung eines Qualitätsmanagementkonzepts

VI

Geleitwort

erhalten wollen. Die Umsetzbarkeit der vorgestellten Methode wird in dieser Dissertation anschaulich an Beispielen belegt, welche Herr Dr. Faerber während seiner Zeit am Lehrstuhl für Angewandte Informatik IV (Datenbanken und Informationssysteme) an der Universität Bayreuth in verschiedenen Industriekooperationen validiert hat. Das vorliegende Buch kann ich Verantwortlichen in Unternehmen und Hochschulen empfehlen, welche für die Umsetzung von Qualitätsmanagementkonzepten verantwortlich sind. Ihnen wird nicht nur eine fundierte Einführung in die prozessorientierte Umsetzung von Qualitätsmanagementkonzepten geboten, sondern darüber hinaus auch ein Leitfaden, wie solche Konzepte umzusetzen sind.

Prof. Dr.-Ing. Stefan Jablonski

Vorwort Die Entwicklung von Produkten und insbesondere von Software stellt immer noch eine der großen Herausforderungen für Unternehmen dar. Nur wenn es einem Unternehmen gelingt, neue Produkte rechtzeitig und mit hoher Qualität zu entwickeln, können sie langfristig auf dem Markt bestehen. Diese Arbeit widmet sich der Fragestellung, wie Mitarbeiter bei der Durchführung von Entwicklungsprojekten nachhaltig unterstützt werden können und wie gleichzeitig die Anforderungen von Qualitätsmanagementstandards erfüllt werden können. Dabei dürfen sich aus der Erfüllung der Anforderungen des Qualitätsmanagements (QM) keine zusätzlichen Aufgaben bzw. keine zusätzliche Arbeitsbelastung für die Mitarbeiter ergeben. Die durch den QM-Standard entstandenen zusätzlichen Aufgaben müssen im Idealfall „nebenbei“ erledigt werden können. Das Wort „nebenbei“ ist hier nicht im Sinne von „nachrangig“ zu verstehen, sondern bedeutet, dass die Mitarbeiter bei der Projektarbeit entlastet werden und die Arbeit durch das Informationssystem im Hintergrund erledigt wird. Gerade dieser Aspekt spielte bei der Konzeption des Systems eine wesentliche Rolle. Nur wenn ein Informationssystem Mitarbeiter entlastet und sie bei der Ausführung der Arbeiten unterstützt, wird es auch durch die Mitarbeiter akzeptiert und genutzt. Ein weiterer Aspekt, der bei der Konzeption des Systems eine zentrale Rolle gespielt hat, war die Flexibilität der Prozessausführung. Software bzw. Produktentwicklungsprozesse sind dadurch geprägt, dass zu ihrer Bearbeitung umfangreiches Fachwissen und auch Kreativität nötig sind bzw. die Bereitschaft der Entwickler und Ingenieure, neue Lösungen zu entwickeln. Stellt ein System hier nicht geeignete Mechanismen zur Unterstützung bereit, ist es nicht für den Einsatz in Produktentwicklungsprozessen geeignet. Gesucht wurde also ein Informationssystem, welches flexibel genug ist, um Mitarbeiter und Projektleiter in Produktentwicklungsprozessen zu unterstützen, gleichzeitig aber auch die Anforderungen eines Qualitätsmanagementstandards einhält, um letztlich die Qualität der Produkte zu sichern. Diese Arbeit ist gleichzeitig auch Ergebnis meiner Tätigkeit im Forschungsverbund FORFLOW1. Ziel des Verbunds war es zu untersuchen, wie Produktentwicklungsprozesse durch Prozess- und Workflowmanagement-Systeme unterstützt werden können.

1

Bayerischer Forschungsverbund für Prozess- und Workflow-Unterstützung zur Planung und Steuerung der Abläufe in der Produktenwicklung (www.forflow.org)

VIII

Vorwort

Meine Forschungsarbeit fand unter der Anleitung von Prof. Dr. Stefan Jablonski statt. Ihm gilt mein besonderer Dank. Schon während des Studiums verstand er es, mir die Welt der Datenbanken und des Prozessmanagements nahezubringen. Seine Herangehensweise, Probleme strukturiert anzugehen und einfache, elegante Lösungen zu finden, hat die vorliegende Arbeit maßgeblich geprägt. Herrn Prof. Dr. Torsten Eymann danke ich für die Übernahme des Zweitgutachtens dieser Arbeit und für wertvolle fachliche Anregungen. Den Kollegen im Forschungsverbund FORFLOW möchte ich für die intensive und gute Zusammenarbeit danken. Ihre Anmerkungen und Vorschläge haben einen wichtigen Beitrag dazu geliefert, die Anforderungen, welche Produktentwickler an ein Prozessmanagementsystem stellen, zu verstehen. Meinen Kollegen am Lehrstuhl für Angewandte Informatik IV danke ich für die tägliche gute Zusammenarbeit. Die angenehme Atmosphäre am Lehrstuhl ermöglichte ein erfolgreiches Arbeiten und Forschen in den Projekten. Dank gilt auch den Studenten, die mit verschiedenen Arbeiten einen wichtigen Beitrag zur Implementierung des Prozessmanagementsystems geleistet haben. Vor allem möchte ich hier Michael Zeising, Bastian Roth und Tobias Sesselmann nennen. Für die vielen netten und unterhaltsamen Gespräche möchte ich mich auch bei Christine Leinberger bedanken. Sie hat durch ihr Organisationstalent immer dafür gesorgt, dass administrative Aufgaben am Lehrstuhl schnell erledigt wurden und mehr Zeit für die Forschung blieb. Meinen Freunden und Kollegen am Lehrstuhl Bernhard Volz und Florent Jochaud danke ich für die vielen Anregungen und für die Unterstützung bei der Implementierung des Systems. Beide standen mir jederzeit mit gutem Rat und Tat zur Seite. Bei Dr. Christian Meiler möchte ich mich für die zahlreichen Verbesserungsvorschläge bedanken und auch dafür, dass er es übernommen hat, die Arbeit Korrektur zu lesen. Seine Ratschläge habe ich schon während meines Studiums schätzen gelernt und umso mehr während meiner Promotion. Meinen Eltern, meiner Schwester Ruth sowie meiner Tante und meinem Onkel möchte ich für die Unterstützung während des Studiums und während der Promotion danken. Während dieser Zeit hat es mir an nichts gefehlt. Danke dafür! Für die Unterstützung bei der Arbeit, die viele Geduld und das immer für mich Dasein möchte ich mich ganz besonders bei meiner Freundin Laura bedanken: Grazie!

Matthias Faerber

Kurzfassung Die Entwicklung neuer und innovativer (Software-)Produkte ist eines der Fundamente für den langfristigen Erfolg von Unternehmen. Software wird nicht nur als alleinstehendes Produkt entwickelt, sondern ist vor allem auch integraler Bestandteil vieler moderner Produkte. Die Qualität der Software und seine Funktionssicherheit sind wesentliche Voraussetzungen für den Erfolg des Produkts am Markt. Um die Qualität von Software sicherzustellen, wurden verschiedene Qualitätsmanagementstandards entwickelt. Zwei dieser Standards, die ISO/IEC 15504 und das Capability Maturity Model Integration® (CMMI®), werden in dieser Arbeit als Basis für die Entwicklung eines prozessbasierten Informationssystems zur Umsetzung von Qualitätsmanagementanforderungen genutzt. Das Ziel dieses Systems ist es, die Transparenz von Projekten für Mitarbeiter zu erhöhen, Mitarbeiter und Projektleiter bei ihrer täglichen Arbeit zu unterstützen und die Umsetzung der Anforderungen von Qualitätsmanagementstandards sicherzustellen. Diese Arbeit ist in drei Teile untergliedert: Anforderungsanalyse, Entwurf des Informationssystems und Beschreibung der Systemarchitektur. Die Systemanforderungen werden aus Sicht der Qualitätsmanagementstandards und aus Sicht der Nutzer betrachtet. Aus Qualitätsmanagementsicht werden die beiden Standards ISO/ IEC 15504 und CMMI betrachtet und aus diesen Normen wird ein Anforderungsmodell rekonstruiert. Aus Nutzersicht wurde die flexible Prozessausführung als Kernanforderung identifiziert, um Mitarbeiter in Entwicklungsprojekten unterstützen zu können. Das Informationssystem muss die Mitarbeiter bei der Bearbeitung der Projekte unterstützen, ohne die notwendige Kreativität einzuschränken. Im zweiten Teil der Arbeit wird, ausgehend von den identifizierten Anforderungen, ein prozessbasiertes Informationssystem entworfen. Einem Prozesslebenszyklus folgend werden der Reihe nach die verschiedenen Phasen dieses Zyklus beschrieben und es wird gezeigt, wie diese mit dem Informationssystem unterstützt werden können. Der Prozesslebenszyklus beginnt mit der Definition der Prozesstypen, mit denen das Standardvorgehen im Unternehmen festgelegt wird. Die erstellten Prozesstypen werden in der zweiten Phase, vor dem Start eines Projekts, an dessen spezifische Vorgaben, mittels Tailoring Regeln, angepasst. Der in dieser Phase entstandene Projektplan bildet die Grundlage für die Projektdurchführung in der dritten Phase. Die während der Durchführung gesammelten Daten werden genutzt, um einerseits den Ist-Zustand des Projekts zu kontrollieren und bei Abweichungen gegenzusteuern; andererseits können sie nach Projektabschluss genutzt werden, um Optimierungspotenziale am Prozesstyp zu identifizieren. Ein Schwerpunkt des

X

Kurzfassung

zweiten Teils der Arbeit liegt auf der Beschreibung des Informationssystems. Es wird beschrieben, wie Konzepte aus dem Bereich Workflow-Management angepasst werden müssen, um die in der Produktentwicklung notwendige Flexibilität zu unterstützen. Die verschiedenen Aspekte des Prozessmanagementsystems werden im Detail erklärt. Im dritten Teil der Arbeit wird die Architektur des Informationssystems beschrieben. Dabei wird vor allem die Speicherstruktur detailliert. Es wird gezeigt, wie die verschiedenen Aspekte des Systems in ein Datenmodell abgebildet werden und wie sie während der Prozessausführung genutzt werden. Zum Abschluss der Arbeit wird die Evaluation des Prozessmanagementsystems vorgestellt, die mit Forschungspartnern aus der Industrie durchgeführt wurde.

Abstract The development of new, innovative (software) products is the fundament for the long-term success of companies. Software is not only developed as a stand-alone product in software companies, but it is also an integral part of many modern products. Its quality and operation reliability is a prerequisite for the products’ usability and finally for their success in the market. Quality management standards have been developed in order to assure the quality of a software product. Two of these standards, the ISO/IEC 15504 and the Capability Maturity Model Integration® (CMMI®), will be used in this thesis to construct a quality management aware process management system. The aim of this information system is to foster project transparency, support developers and project managers in their daily work and to comply with the requirements of modern quality management standards. This thesis is divided into three parts: the requirements analysis, the system design and the system architecture. The requirements for the process management system are derived from both the quality management perspective and the user perspective. For the quality perspective, the two quality management standards ISO/IEC 15504 and CMMI are examined and a quality-related requirements model is defined based on these two standards. In the user perspective, flexible process execution is identified as the key requirement in order to support developers in product development projects. The system has to support developers in their daily work without restricting them in their creativity. The second part of this thesis uses these requirements to construct a process-based information system. Following a process life cycle, the different phases are detailed and it is shown how they can be supported by an information system. The life cycle starts with the definition of a process type which defines the standard approach to execute certain tasks. The process type is then adapted to the context of a specific project using a tailoring approach and a project plan is defined. The project plan forms the basis for the execution of the project. Information that is collected during project execution is then used to derive improvements and optimizations for the process type. It is shown how each phase can be supported by a process-based information system and how this system complies with both the requirements from the quality management and the user perspective. In this life cycle, an emphasis is put on the process execution phase. It is described how classical workflow management principles can be adapted to flexibly support developers in software development projects. The aspects of the developed process management system are explained in detail.

XII

Abstract

In the third part, the architecture of the process management system is shown. Special attention will be given to the storage system of this architecture. It is explained how the different aspects of the process management system can be mapped to a data model and how data that is recorded during project execution is stored in the system. Concluding this thesis, an evaluation of the process management system is presented which was carried out with industrial partners.

Inhaltsverzeichnis Teil I 1

2

3

4

Teil II 5

Anforderungen an ein Qualitätsmanagementsystem

1

Einführung, Zielsetzung und Aufbau......................................................... 3 1.1 Der Qualitätsbegriff in der Software-Entwicklung

4

1.2 Beitrag der Arbeit

9

1.3 Aufbau der Arbeit

14

QM-Standards und Vorgehensmodelle .................................................. 17 2.1 Das V-Modell XT als Vorgehensmodell zur Softwareentwicklung

17

2.2 CMMI und ISO/IEC 15504 als Modelle zur Bewertung der Prozessreife

22

Rekonstruktion des abstrakten QM-Modells .......................................... 33 3.1 Exkurs: Meta-Modelle in der Prozessmodellierung

34

3.2 Strukturelle Rekonstruktion eines abstrakten QM-Modells

36

3.3 Zusammenfassung

62

Anforderungen an ein prozessbasiertes Informationssystem aus Anwendersicht ................................................................................ 65 4.1 Änderungen als zentraler Bestandteil des Prozessmanagements

65

4.2 Anforderungen an die Flexibilität des Informationssystems

68

4.3 Bereitstellung von Ausführungswissen für die Anwender

70

4.4 Durchführung von Projekten ohne IT-Unterstützung

72

Konzeption eines prozessbasierten Informationssystems für QM-Systeme

77

Entwurf eines Vorgehensmodells zur Umsetzung von QMAnforderungen ...................................................................................... 79 5.1 Einfacher Prozesslebenszyklus

79

5.2 Ein Vorgehensmodell zur Umsetzung von QMAnforderungen

81

XIV

Inhaltsverzeichnis

6

Ausblick: Umsetzung der QM-Anforderungen im ProcessNavigator ................................................................................... 85

7

Erstellung einer validierten Prozesslandschaft ....................................... 91

8

9

10

11

Teil III 12

7.1 Das Prozess-Meta-Modell

91

7.2 Phase 1: Identifikation der Prozesstypen

93

7.3 Phase 2.1: Definition der Prozesstypen

95

7.4 Phase 2.2: Validierung und Umsetzung der QMAnforderungen im Prozesstyp

99

Erstellung eines validierten Projekttyps ................................................107 8.1 Das Projekt-Meta-Modell

107

8.2 Phase 3.1: Erstellung des Projekttyps

109

8.3 Phase 3.2: Validierung und Umsetzung der QMAnforderungen im Projekttyp

122

Projektdurchführung ............................................................................125 9.1 Phase 4.1: Unterstützung bei der Projektbearbeitung

125

9.2 Phase 4.2: Projektmonitoring und Umsetzung der QMVorgaben

157

Nachbereitung der Projektdurchführung...............................................165 10.1 Phase 5: Interne Verbesserungsmaßnahmen und Umsetzung von QM-Vorgaben

165

10.2 QM-Assessment

169

Systematische Messung und Prozessverbesserung ................................173 11.1 Exkurs: Die Methode Six Sigma zur Verbesserung der Prozessqualität

173

11.2 Six Sigma im ProcessNavigator und Umsetzung der QMVorgaben

179

Umsetzung und Schlussfolgerungen

185

Systemarchitektur ................................................................................187 12.1 Architekturübersicht ProcessNavigator

187

12.2 Ontologiebasiertes Speichersystem

191

Inhaltsverzeichnis

XV

13

Evaluation des ProcessNavigators .........................................................201

14

Zusammenfassung ................................................................................205

15

Ausblick ................................................................................................211

Literaturverzeichnis

215

Abbildungsverzeichnis Abbildung 1-1:

Einfluss von Vorgehensmodellen und QM-Standards auf Prozess und Projekt .......................................................................... 8

Abbildung 1-2:

Beziehungen zwischen Software-Entwicklungsprozessen und QM-Standards ........................................................................... 9

Abbildung 1-3:

Generalisierung des aQM2 aus den QM-Standards ISO/IEC 15504 und CMMI............................................................... 12

Abbildung 1-4:

Der ProcessNavigator als Ergebnis aus Anforderungen der QM-Standards und der Anwender .......................................... 13

Abbildung 1-5:

Aufbau der Arbeit ........................................................................... 16

Abbildung 2-1:

Bestandteile eines Vorgehensbausteins (Abbildung aus [V-Modell XT (Version 1.3)]) ........................................................... 19

Abbildung 2-2:

Projektdurchführungsstrategien und Entscheidungspunkte im V-Modell XT (Abbildung aus [VModell XT (Version 1.3)]) ............................................................... 21

Abbildung 2-3:

Struktur der CMMI-Prozessgebiete [CMMI Product Team 2006] ..................................................................................... 27

Abbildung 2-4:

Nutzung eines Prozess-Assessment-Modells im Assessment [Hörmann et al. 2006] ................................................ 29

Abbildung 2-5:

Struktur der ISO/IEC 15504 ............................................................ 30

Abbildung 3-1:

Meta-Modell-Hierarchie für die Prozessmodellierung (adaptiert aus [Jablonski et al. 2009c]) .......................................... 36

Abbildung 3-2:

Meta-Ebenen in der Prozess- und Projektdurchführung ............... 39

Abbildung 3-3:

Das aQM2 im Überblick .................................................................. 41

Abbildung 3-4:

Zuordnung des RG2 zum Meta-Modell .......................................... 47

Abbildung 3-5:

Zuordnung des RG3 zum Meta-Modell .......................................... 53

Abbildung 3-6:

Zuordnung des RG4 zum Meta-Modell .......................................... 57

Abbildung 3-7:

Zuordnung des RG5 zum Meta-Modell .......................................... 62

Abbildung 4-1:

Aufgaben des Prozessmanagementsystems .................................. 75

Abbildung 5-1:

Prozesslebenszyklus (nach [Wagner et Käfer 2008]) ..................... 80

Abbildung 5-2:

Ergänzung des Prozesslebenszyklus um neue Phasen ................... 82

XVIII

Abbildungsverzeichnis

Abbildung 5-3:

Vorgehensmodell zur Umsetzung von QMAnforderungen ............................................................................... 83

Abbildung 7-1:

Prozess-Meta-Modell auf den Ebenen M2 und M3 [Jablonski et al. 2009c] ................................................................... 92

Abbildung 7-2:

Prozesslandschaft (nach [Wagner et Käfer 2008])......................... 95

Abbildung 7-3:

Prozesstyp in der Phasenübersicht ................................................ 97

Abbildung 7-4:

Prozesstyp Detail ............................................................................ 98

Abbildung 7-5:

Abbildung des QM-Referenzmodells auf die Basisaspekte ................................................................................. 100

Abbildung 7-6:

Abbildung der Prozessschritte auf die ISO 15504 ........................ 102

Abbildung 7-7:

Werkzeugunterstützung zur Abbildung von Anforderungen aus QM-Normen ................................................. 103

Abbildung 7-8:

Abgleich der umgesetzten Praktiken mit QMReferenzmodell ............................................................................ 104

Abbildung 8-1:

Projekt-Meta-Modell auf den Ebenen M2 und M3 ..................... 108

Abbildung 8-2:

Erstellung eines Projekttyps aus der Prozesslandschaft .............. 115

Abbildung 8-3:

Prozess-Tailoring im V-Modell XT Projektassistent 1.3.1 [V-Modell XT Projektassistent] ..................................................... 118

Abbildung 8-4:

Darstellung Projektbausteintyp ................................................... 119

Abbildung 8-5:

Übertragung des Prozesstyps in einen Projekttyp ....................... 120

Abbildung 9-1:

Workflow-Management-Systeme (Beispiel) ................................ 126

Abbildung 9-2:

ProcessNavigator Übersicht ......................................................... 129

Abbildung 9-3:

Bezug zwischen Prozesstyp und Worklist .................................... 130

Abbildung 9-4:

Die Worklist im ProcessNavigator ................................................ 134

Abbildung 9-5:

Informationen und Arbeitsrichtlinien im ProcessNavigator .......................................................................... 136

Abbildung 9-6:

Meilensteine im ProcessNavigator .............................................. 137

Abbildung 9-7:

Einfluss des Kontrollflusses auf die Worklist ............................... 140

Abbildung 9-8:

Entscheider im ProcessNavigator................................................. 142

Abbildung 9-9:

Anzeige von Daten und Dokumenten im ProcessNavigator .......................................................................... 144

Abbildung 9-10:

Anwendung des Organisatorischen Aspekts in der Worklist ........................................................................................ 148

Abbildungsverzeichnis

XIX

Abbildung 9-11:

Einbindung des Organisatorischen Aspekts im ProcessNavigator .......................................................................... 154

Abbildung 9-12:

Kleiner Regelkreis zur Steuerung des Projekts............................. 158

Abbildung 9-13:

Anzeige des Projektfortschritts in der Projektübersicht .............. 160

Abbildung 9-14:

Anzeige weiterer Projektkennzahlen ........................................... 161

Abbildung 10-1:

Großer Regelkreis zur Prozessverbesserung ................................ 166

Abbildung 10-2:

Zuordnung der Vorgaben aus der QM-Norm zu Unternehmensprozessen ............................................................. 171

Abbildung 11-1:

Das Six Sigma Konzept .................................................................. 175

Abbildung 12-1:

ProcessNavigator-Architektur ...................................................... 189

Abbildung 12-2:

Aufrufsequenz im ProcessNavigator ............................................ 190

Abbildung 12-3:

Speicherung von Arbeitsschritten in der Ontologie .................... 193

Abbildung 12-4:

Speicherung einer Sequenz in der Ontologie............................... 194

Abbildung 12-5:

Speicherung eines AND-Konnektors in der Ontologie ................. 195

Abbildung 12-6:

Abbildung des QM-Standards im Speichersystem ....................... 196

Abbildung 12-7:

Speicherung der Organisationsstruktur in der Ontologie ............ 197

Abbildung 12-8:

Speicherung der Ausführungshistorie in der Ontologie .............. 198

Abbildung 12-9:

Erstellung spezifischer Beziehungen zwischen Organisationen ............................................................................. 198

Abbildung 12-10: Speicherung des Datenorientierten Aspekts in der Ontologie ...................................................................................... 199 Abbildung 13-1:

Auswertung der Fragebögen (Abbildung aus [Sharafi 2009]) ........................................................................................... 202

Abbildung 13-2:

Bewertung der Unterstützung durch den ProcessNavigator (Abbildung aus [Sharafi 2009]) ....................... 203

Tabellenverzeichnis Tabelle 2-1:

Unterschiede zwischen kontinuierlicher und stufenförmiger Darstellung des CMMI .......................................... 24

Tabelle 3-1:

Anforderungen auf Level 1 ............................................................. 42

Tabelle 3-2:

Abstraktes Referenzmodell auf RG 1 ............................................. 43

Tabelle 3-3:

Anforderungen auf Level 2 ............................................................. 44

Tabelle 3-4:

Abstraktes Referenzmodell auf RG 2 ............................................. 45

Tabelle 3-5:

Anforderungen auf Level 3 ............................................................. 48

Tabelle 3-6:

Abstraktes Referenzmodell auf RG 3 ............................................. 51

Tabelle 3-7:

Anforderungen auf Level 4 ............................................................. 54

Tabelle 3-8:

Abstraktes Referenzmodell auf RG 4 ............................................. 56

Tabelle 3-9:

Anforderungen auf Level 5 ............................................................. 59

Tabelle 3-10:

Abstraktes Referenzmodell auf RG 5 ............................................. 60

Tabelle 6-1:

Umsetzung der Anforderungen des aQM2 RG1 ............................. 85

Tabelle 6-2:

Umsetzung der Anforderungen des aQM2 RG2 ............................. 86

Tabelle 6-3:

Umsetzung der Anforderungen des aQM2 RG3 ............................. 87

Tabelle 6-4:

Umsetzung der Anforderungen des aQM2 RG4 ............................. 89

Tabelle 6-5:

Umsetzung der Anforderungen des aQM2 RG5 ............................. 90

Tabelle 7-1:

Elemente des Prozessmodells ........................................................ 93

Tabelle 7-2:

Umsetzung der QM-Anforderungen im Prozesstyp..................... 104

Tabelle 8-1:

Änderungen im Projektmodell im Vergleich zum Prozessmodell .............................................................................. 109

Tabelle 8-2:

Umsetzung der QM-Vorgaben im Projektmodell (Ebene 1) ...................................................................................... 122

Tabelle 8-3:

Umsetzung der QM-Vorgaben im Projektplan ............................ 123

Tabelle 9-1:

Umsetzung der Elemente des Funktionalen Aspekts .................. 139

Tabelle 9-2:

Umsetzung der Elemente des Verhaltensorientierten Aspekts ......................................................................................... 143

Tabelle 9-3:

Umsetzung der Elemente des Datenorientierten Aspekts .......... 147

Tabelle 9-4:

Beispiele von Zuweisungsregeln in der OPL................................. 149

XXII

Tabellenverzeichnis

Tabelle 9-5:

Umsetzung der Elemente des Organisatorischen Aspekts ......................................................................................... 152

Tabelle 9-6:

Umsetzung der Elemente des Operationalen Aspekts ................ 154

Tabelle 9-7:

Vergleich zwischen klassischem Workflow-Konzept und Prozessnavigator .......................................................................... 156

Tabelle 9-8:

Umsetzung der QM-Anforderungen im ProcessNavigator auf RG1 ............................................................ 162

Tabelle 9-9:

Umsetzung der QM-Anforderungen im ProcessNavigator auf RG2 ............................................................ 163

Tabelle 9-10:

Umsetzung der QM-Anforderungen im ProcessNavigator auf RG3 ............................................................ 163

Tabelle 10-1:

Umsetzung der QM-Anforderungen durch Verbesserungsmaßnahmen auf RG3............................................ 169

Tabelle 11-1:

Zuordnung der Six Sigma Phasen zu den aQM 2 Zielen auf RG4 ......................................................................................... 180

Tabelle 11-2:

Zuordnung der Six Sigma Phasen zu den aQM 2 Zielen auf RG5 ......................................................................................... 182

Teil I Anforderungen an ein Qualitätsmanagementsystem

1

Einführung, Zielsetzung und Aufbau

In den letzten zwei Jahrzehnten ist Software ein integraler Bestandteil vieler Systeme geworden. Die Spannbreite reicht von Alltagsgegenständen wie Kaffeevollautomaten bis hin zu hochkomplizierten Industriesteuerungen. Obwohl der Nutzer die Software nicht direkt „sieht“ und mit ihr interagieren kann, ist sie doch wesentlich für das Gesamtverhalten eines Systems verantwortlich. Tritt ein Fehler in einer Software auf, kann in den meisten Fällen auch das Gesamtsystem nicht mehr die ursprünglich definierten Aufgaben erfüllen. Die Anforderung, fehlerfreie und qualitativ hochwertige Software zu entwickeln, ist also unbestritten. Das Beispiel der europäischen Trägerrakete Ariane 5 zeigt, wie komplex und facettenreich Softwareentwicklung sein kann. Die Rakete wurde während des Jungfernflugs, 39 Sekunden nach dem Start durch das automatische Notfallsystem gesprengt. Aufgrund des eingetretenen hohen Schadens wurden die Ursachen die zur Sprengung der Rakete führten, detailliert untersucht und analysiert [Le Lann 1996]. In [Nuseibeh 1997] werden verschiedene Gründe genannt, die einen Anteil am Fehlstart hatten. Der Fehler, der zur Zerstörung der Rakete führte, trat auf, als in der Steuerungssoftware eine 64-bit Gleitkommazahl in eine vorzeichenbehaftete 16-bit Ganzzahl umgewandelt werden musste. Folge dieses Konvertierungsfehlers war eine Abweichung der tatsächlichen von der geplanten Flugbahn und schließlich die Sprengung der Rakete durch das Notfallsystem. Der Grund für die Zerstörung war also ein Fehler in der Steuerungssoftware der Rakete, welcher sich wiederum aus dem Programmierfehler eines Entwicklers ergab. Während in der deutschen Sprache alles als „Fehler“ bezeichnet werden, wird hier in der englischen Sprache begrifflich unterschieden zwischen „mistake“ (Fehler des Programmierers bzw. Menschen), „fault“ (Fehler im System) und „failure“ (Fehler während der Ausführung). Durch diese drei Begriffe wird auch eine Wirkungskette beschrieben. So führt der Fehler des Programmierers zu einem Programmfehler und schließlich zum Fehlerzustand während der Ausführung. Im Fall der Ariane 5 hat sich gezeigt, dass eine Reihe von „mistakes“ zum Systemversagen geführt hat: der eigentliche Programmierfehler, eine mangelhafte Anforderungsspezifikation, ungenügende Tests und ein unzureichendes Projektmanagement. Auch in [Dowson 1997] wird beschrieben, dass nicht nur ein einzelner Fehler der Grund für den Defekt in der Software war, sondern Fehler sowohl beim methodischen Vorgehen als auch im Entwicklungsprozess gemacht wurden. Statt in einem einzigen „mistake“, dem Konvertierungsfehler, lag hier also eine Verkettung verschiedener „mistakes“ vor, die schließlich zu dem „failure“, der Sprengung der Rakete, führten.

4

1 Einführung, Zielsetzung und Aufbau

Ausgehend von diesem kurzen Beispiel stellt sich nun die Frage, wie „mistakes“ von Beginn an verhindert werden, und wie „faults“, die in der Software enthalten sind, aufgedeckt werden können. Vor allem soll während der Entwicklung eines Softwaresystems systematisch sichergestellt werden, dass bestimmte an sie gestellte Anforderungen erfüllt werden. Die Erfüllung bestimmter Forderungen und die Fehlerfreiheit eines Produkts sollen sich nicht zufällig ergeben, sondern das Resultat eines systematischen Qualitätsmanagements sein. 1.1

Der Qualitätsbegriff in der Software-Entwicklung

Im alltäglichen Wirtschaftsleben ist das Konzept „Qualität“ ein wichtiger Beitrag zum wirtschaftlichen Erfolg von Unternehmen. Nur qualitativ hochwertige Produkte können sich langfristig am Markt durchsetzen und Kunden an das Unternehmen binden. Der Begriff „Qualität“ wird in dieser Arbeit an vielen Stellen genutzt. Um ihn abgrenzen zu können, soll er wie folgt definiert werden: „Gesamtheit der Merkmale einer Einheit bezüglich ihrer Eignung, festgesetzte und vorausgesetzte Erfordernisse zu erfüllen.“ [Hohler 1999] Eine ähnliche, jedoch kürzere Definition findet sich in [Geiger 1987]: „Realisierte Beschaffenheit bezüglich Forderung.“ Diese Definitionen sind durch die Entwicklung und Fertigung materieller Produkte (insbesondere aus dem Maschinenbau) geprägt. Software ist hingegen ein immaterielles Produkt; sie zeichnet sich unter anderem durch folgende besondere Eigenschaften aus [Hohler 1999]: x Komplexität Sie ist ein wesentliches Merkmal von Software. Moderne Software besteht in aller Regel aus mehreren Millionen Zeilen Quellcode, der von Entwicklerteams erstellt wird. So besteht beispielsweise der aktuelle Linux-Kernel (Version 2.6.26) aus nahezu 6 Million Zeilen Code2. x Fehleranfälligkeit Im Vergleich zu materiellen Produkten (z.B. aus dem Maschinenbau) ist bei Software das dort gültige Konzept der Toleranz bei Abweichungen von den geplanten Zielgrößen nicht anwendbar. Software ist wegen seiner binären Darstellung unstetig und nimmt bei seiner Ausführung diskrete Zustände an; die Anzahl der möglichen Zustände ist aufgrund der kombinatorischen Explosion

2

http://libresoft.dat.escet.urjc.es/debian-counting/lenny/index.php?menu=Packages (Stand 18.09.2009)

1.1 Der Qualitätsbegriff in der Software-Entwicklung

5

entsprechend groß. Auch bei sehr kleinen Fehlerdichten von 0.05 Fehlern pro 1000 Zeilen Code [Hoffmann 2008] sind in den Systemen noch viele Fehler enthalten. Durch die diskreten Zustände und das daraus resultierende sprunghafte Verhalten kann schon ein einziger Fehler (wie im Beispiel die fehlerhalte Konvertierung der Gleitkommazahl) zu katastrophalen Ergebnissen führen. x Schwierige Prüfbarkeit Es ist eine bekannte Tatsache, dass mit Tests zwar das Vorhandensein von Fehlern gezeigt, jedoch niemals die Korrektheit des Systems bewiesen werden kann [Hoffmann 2008]. Der Grund hierfür ist erneut die sehr große Anzahl der möglichen Zustände eines Programmes; die komplette Abdeckung aller Zustände durch Tests ist praktisch nicht durchführbar. Diese Eigenschaften führen dazu, dass für Software andere Maßstäbe und Methoden als für materielle Produkte entwickelt werden müssen, um die Qualität zu gewährleisten. In der Norm ISO/IEC 9126 werden die Qualitätsmerkmale für Software definiert: x Funktionalität: Vorhandensein von Funktionen mit festgelegten Eigenschaften. Diese Funktionen erfüllen die definierten Anforderungen. x Zuverlässigkeit: Fähigkeit der Software ihr Leistungsniveau unter festgelegten Bedingungen über einen festgelegten Zeitraum zu bewahren. x Benutzbarkeit: Aufwand, der zur Benutzung erforderlich ist und individuelle Beurteilung der Benutzung durch eine festgelegte oder vorausgesetzte Benutzergruppe. x Effizienz: Verhältnis zwischen dem Leistungsniveau der Software und dem Umfang der eingesetzten Betriebsmittel unter festgelegten Bedingungen. x Änderbarkeit: Aufwand, der zur Durchführung vorgegebener Änderungen notwendig ist. Änderungen können Korrekturen, Verbesserungen oder Anpassungen an Änderungen der Umgebung, der Anforderungen und der funktionalen Spezifikationen einschließen. x Übertragbarkeit: Eignung der Software, von einer Umgebung in eine andere übertragen zu werden. Umgebung kann organisatorische Umgebung, Hardware- oder Software-Umgebung einschließen. Entsprechend dieser Merkmale reicht es demnach nicht, nur den geforderten Funktionsumfang zu implementieren und sicherzustellen, dass bei der Benutzung keine Fehler auftreten. Vielmehr umfassen die Qualitätsmerkmale auch Kriterien, die

6

1 Einführung, Zielsetzung und Aufbau

auf eine spätere Änderbarkeit und Anpassbarkeit des Systems an neue Anforderungen abzielen. Grundsätzlich kann zwischen zwei Ansätzen zur Sicherung der Qualität in Softwareprodukten unterschieden werden [Hohler 1999]: x die Beurteilung der Qualität der Endprodukte und x die Sicherung des Prozesses, mit dem das Produkt erstellt werden soll. Die Beurteilung der Endproduktqualität erfolgt im Software-Engineering durch strukturiertes Testen der Module und des Endprodukts. Softwaretests leisten einen wichtigen Beitrag, um vor dem produktiven Einsatz der Software sicherzustellen, dass diese keine wesentlichen Fehler mehr enthält. Da Tests nur das Produkt selbst betrachten, können mit ihnen nur Aussagen über Zuverlässigkeit, Benutzbarkeit und Effizienz getroffen werden, jedoch nur sehr begrenzt über Änderbarkeit und Übertragbarkeit. Die Absicherung des Entwicklungsprozesses greift weiter als der Test der Endprodukte. Durch den prozessorientierten Ansatz können alle Facetten der Softwareentwicklung (von der Anforderungsanalyse bis zum Akzeptanztest) beachtet werden. Da das Endprodukt, die fertige Software, das Ergebnis einer Folge von Tätigkeiten (dem Entwicklungsprozess) ist, ist die Erwartung, dass eine Verbesserung des Prozesses auch eine Verbesserung des Produkts zur Folge hat. Dies wird in folgender Prozessmanagement-Prämisse ausgedrückt: Process management premise: "The quality of a system is highly influenced by the quality of the process used to develop and maintain it" [CMMI Product Team 2006] Diese Annahme bildet die Grundlage für diese Arbeit. Es wird sowohl die Gestaltung als auch die Umsetzung (Ausführung) der (Softwareentwicklungs-)Prozesse im Unternehmen betrachtet. Beides soll sicherstellen, dass die entwickelte Software alle genannten Software-Qualitätsmerkmale erfüllen kann. Zur Beurteilung der Güte von Prozessen wurden Qualitätsmanagementstandards (auch QM-Standards oder QM-Normen) entwickelt. Diese erlauben es, die Leistungsfähigkeit von Unternehmensprozessen zu bewerten bzw. sicherzustellen. Die Konformität des Entwicklungsprozesses mit den Anforderungen einer Norm wird im Unternehmen durch ein Qualitätsmanagementsystem gewährleistet. Der Begriff Qualitätsmanagementsystem (QM-System) soll wie folgt definiert werden: „Das Qualitätsmanagement-System hat die Zielsetzung, die Aufbau- und Ablauforganisation so festzulegen, dass die Unternehmensziele erreicht

1.1 Der Qualitätsbegriff in der Software-Entwicklung

7

werden können, und Nutzen für alle Interessenpartner […] erzielt werden kann.“ [Wagner et Käfer 2008] Die bekannteste dieser Normen, die ISO 9001, definiert Anforderungen an den Aufbau eines QM-Systems. Durch sie ist es für ein Unternehmen möglich, ein Zertifikat zu erhalten, in dem durch einen Assessor (Prüfer) dokumentiert wird, dass alle Vorgaben der Norm umgesetzt wurden und ein bezüglich der Norm konformes QM-System existiert. Allerdings wird in diesem Zertifikat keine Aussage darüber getroffen, wie gut das QM-System ist, bzw. wie gut die Prozesse im Unternehmen umgesetzt werden. Zu diesem Zweck wurden zwei weitere Standards entwickelt. In Europa wurde das SPICE Projekt (Software Process Improvement and Capability Determination) [Hörmann et al. 2006] gestartet und in den USA wurde vom Software Engineering Institute (SEI) der Carnegie Mellon University in Pittsburgh das Capability Maturity Model Integration® (im Folgenden kurz CMMI® genannt) [CMMI Product Team 2006] entwickelt. Beide Standards verfolgen den Zweck, den Reifegrad eines Softwareentwicklungsprozesses und den Grad der Umsetzung des Prozesses im Unternehmen messbar zu machen. Nach Abschluss des SPICE Projekts wurde von der ISO (International Organization for Standardization) aus den Projektergebnissen der internationale Standard ISO/IEC 15504 [ISO/IEC 15504-5:2006] entwickelt. Diese beiden Standards sind international verbreitet und werden in Unternehmen zur Bewertung der Prozessleistungsfähigkeit eingesetzt. Beide Standards (ISO/IEC 15504 und CMMI) sollen im weiteren Verlauf der Arbeit näher vorgestellt werden und es soll untersucht werden, wie deren Implementierung durch ein prozessbasiertes IT-System unterstützt werden kann. Sowohl die ISO/IEC 15504 als auch das CMMI setzen voraus, dass Prozesse als Grundlage für die Entwicklungsprojekte genutzt werden; aus diesem Grund beschränkt sich diese Arbeit auf diese Fälle. In einem Vorgehensmodell wird ein kompletter Entwicklungsablauf bereitgestellt, welcher nach der Anpassung an die Gegebenheiten des Unternehmens zur Entwicklung von Software genutzt werden kann. Ziel von Vorgehensmodellen ist es, bestimmte erprobte Entwicklungspraktiken (z.B. Anforderungsanalyse, Erstellung eines Softwaredesigns oder das Testen der Software) im Entwicklungsprozess umzusetzen, um so Fehler entweder zu vermeiden, oder diese frühzeitig aufzudecken. Die bekanntesten Vorgehensmodelle sind das Wasserfallmodell, das V-Modell, das VModell XT, die ISO/IEC 12207 und der Rational Unified Process (RUP) [Essigkrug et Mey 2007; ISO/IEC 12207:2008; RUP 2009; Schach 2007; Sommerville 2006; V-Modell XT (Version 1.3)]. Sowohl QM-Standards als auch Vorgehensmodelle bieten Unternehmen Hinweise und Anleitungen, wie die Prozesse im Unternehmen verbessert werden können. Die

8

1 Einführung, Zielsetzung und Aufbau

Vorgehensmodell

QM-Standard

definiert Anforderungen

beschreibt Standardvorgehen

Unternehmensinterne Konzepte und Systeme

Externe Anforderungen und Vorgaben

Beziehungen zwischen Vorgehensmodell, QM-Standard sowie (Unternehmens-) Prozess und Projekt werden in Abbildung 1-1 dargestellt.

Abbildung 1-1:

Prozesslebenszyklus steuert Lebenszyklus

(Unternehmens-) (Unternehmens-) (Unternehmens-) Prozesse Prozess Prozess

Projekt beschreibt Standardvorgehen

Prozesslandschaft

Prozessschritt

Projektschritt

Einfluss von Vorgehensmodellen und QM-Standards auf Prozess und Projekt

Vorgehensmodelle legen ein Standardvorgehen für die Entwicklung von Produkten in Unternehmen fest und bestehen aus erprobten Praktiken und Arbeitsschritten. Für die unterschiedlichen Domänen werden jeweils verschiedene Vorgehensmodelle entwickelt. Somit liefert ein Vorgehensmodell die inhaltlichen Vorgaben für die Definition der Prozesse im Unternehmen. Alle im Unternehmen vorhandenen Prozesse stellen die Prozesslandschaft des Unternehmens dar. Diese bildet die Grundlage für die im Unternehmen durchgeführten Projekte indem sie das unternehmensinterne Standardvorgehen beschreibt; Projektschritte beschreiben innerhalb eines Projekts die durchzuführenden Aufgaben. Der Prozesslebenszyklus steuert das Zusammenspiel zwischen Prozess und Projekt. Er legt fest, wann und wie ein neuer Prozesstyp definiert wird, wie er in ein Projekt abgeleitet wird und die gewonnenen Ausführungsinformationen zur Verbesserung des Prozesses genutzt werden. Durch einen QM-Standard werden Anforderungen an Prozesse, die Zusammensetzung der Prozesslandschaft und die Durchführung von Projekten gestellt. In Abbildung 1-2 werden die Beziehungen zwischen Software-Vorgehensmodell und QM-Standard näher dargestellt. Als Vertreter für Software-Vorgehensmodelle werden das V-Modell XT und die ISO/IEC 12207 dargestellt; als Vertreter von QM-

1.2 Beitrag der Arbeit

9

Standards die ISO/IEC 15504, das CMMI und die ISO 9001. In der Abbildung wird besonders deutlich, dass die ISO/IEC 15504 aus zwei Bestandteilen aufgebaut ist: der ISO/IEC 15504-2, welche die Reifegraddimension definiert, und der ISO/IEC 12207, welche in der ISO/IEC 15504 als Prozessdimension die im Projekt umzusetzenden Praktiken festlegt. Auch im CMMI sind diese beiden Dimensionen vorhanden. Allerdings ist dort die Prozessdimension direkt im QM-Standard enthalten und wird nicht als externer Standard importiert. Die Standards V-Modell XT, ISO/IEC 15504 und CMMI werden in Kapitel 2 detailliert vorgestellt. Als weiteres Element des Qualitätsmanagements wird Six Sigma als QM-Vorgehensmodell vorgestellt. Six Sigma ist kein Standard, der Anforderungen definiert, sondern beschreibt ein Vorgehen, wie die Qualität von Prozessen systematisch verbessert werden können. SoftwareEntwicklungsprozesse

Qualitätsmanagement

SoftwareVorgehensmodell

QM-Vorgehensmodell

QM-Standard

Anwendung V-Modell XT

ISO/IEC 12207 (Prozessdimension) ISO/IEC 15504-5

Abbildung 1-2:

1.2

ISO/IEC 15504-2 (Reifegraddimension)

CMMI

ISO 9001

Six Sigma

erfüllt Vorgaben

Beziehungen zwischen Software-Entwicklungsprozessen und QM-Standards

Beitrag der Arbeit

Ist in einem Unternehmen die Einrichtung eines neuen QM-Systems geplant, so muss dies in Abstimmung mit den dort vorhandenen Anforderungen und auch im Bezug auf den umzusetzenden QM-Standard erfolgen. Nur wenn dies der Fall ist, kann das QMSystem seine Wirkung im Hinblick auf die strategischen Ziele des Unternehmens entfalten und das Ziel, die Zertifizierung eines Unternehmens nach dem ausgewählten QM-Standard, unterstützen. Hier stellen sich für Unternehmen zwei wesentliche Herausforderungen: x Informationen zu QM-Standard und Prozess müssen einfach zugänglich sein Die Unternehmensprozesse und die Umsetzung der Standards werden aktuell vor allem in Form eines ausgedruckten Dokuments (dem QM-Handbuch) oder im Intranet des Unternehmens dokumentiert [Hansmann et al. 2005; Wagner et Käfer 2008]. Obwohl in diesen Systemen die Informationen zu Prozessen grundsätzlich verfügbar sind, ist es dennoch für die Mitarbeiter aufwändig, an

10

1 Einführung, Zielsetzung und Aufbau

die gesuchten Informationen zu gelangen. Das Problem besteht weniger in einem Fehlen der Informationen, als vielmehr in einem Überfluss an Informationen, die besser gemanagt werden müssen. x Prozessausführung und Umsetzung der QM-Standards muss nachvollziehbar sein Sowohl die ISO/IEC 15504 als auch das CMMI sind sehr umfangreich und detailliert im Hinblick auf die gestellten Anforderungen. In einem Assessment muss die korrekte Umsetzung der Vorgaben durch den Assessor nachvollziehbar sein. Mitarbeiter müssen hier schon während der Umsetzung des Projekts sicherstellen, dass alle Anforderungen umgesetzt werden und dies auch später im Assessment überprüft werden kann. Dies kann insbesondere dass zu Problemen führen, wenn im Projekt ein hoher Zeitdruck herrscht. Um diesen Problemen zu begegnen, soll in dieser Arbeit ein prozessbasiertes Informationssystem konzipiert werden, welches einerseits Mitarbeiter und Projektleiter bei der Bearbeitung eines Projekts umfassend unterstützt und andererseits sicherstellt, dass die Anforderungen der QM-Standards umgesetzt werden. Das Anforderungsprofil eines solchen Informationssystems zur Mitarbeiterunterstützung und Umsetzung von QM-Normen ist vielseitig. Aus fachlicher Sicht muss es sowohl den Anforderungen der QM-Normen genügen als auch die Anwender einbeziehen und diese bei ihrer Arbeit unterstützen. Aus technischer Sicht muss es so generisch bzw. flexibel entworfen werden, dass es sich an wandelnde Unternehmensumgebungen einfach anpassen lässt. Aus diesen Forderungen ergeben sich die folgenden Eckpunkte dieser Arbeit: x Rekonstruktion eines abstrakten QM-Modells Den Ausgangspunkt zur Entwicklung eines Konzepts zur Umsetzung von QMSystemen bildet die Definition eines abstrakten QM-Modells (aQM2). Die beiden QM-Standards ISO/IEC 15504 und CMMI definieren eine Reihe an Forderungen, die in einem Softwareentwicklungsprozess umgesetzt werden müssen. Das aQM2 ist eine Generalisierung beider Standards und legt ein Anforderungsgerüst fest, welches aus Sicht des Qualitätsmanagements Vorgaben an Softwareentwicklungsprozesse definiert. Dazu werden die beiden Standards ISO/IEC 15504 und CMMI analysiert und miteinander verglichen. Die zentralen Anforderungen beider Standards werden identifiziert und in einem gemeinsamen Modell rekonstruiert. Das aQM2 bleibt jedoch abstrakt, da es im Unterschied zu den beiden QM-Standards ISO/IEC 15504 und CMMI keine konkreten Vorgaben definiert sondern nur die zentralen Konzepte festlegt.

1.2 Beitrag der Arbeit

11

Durch eine Abbildung des QM-Anforderungsmodells auf ein Meta-Modell für die Prozessmodellierung und -ausführung ergibt sich einerseits eine klare Strukturierung der einzelnen Anforderungen, andererseits lassen sich erste Aussagen ableiten, wie das Modell durch ein Informationssystem implementiert werden kann. Durch die Rekonstruktion des abstrakten QM-Anforderungsmodells kann die Konzeption des Informationssystems unabhängig von den konkreten Anforderungen eines einzelnen QM-Standards erfolgen; die entwickelten Konzepte lassen sich jedoch einfach auf die konkreten Standards übertragen. x Entwicklung eines Vorgehensmodells zur Umsetzung von QM-Anforderungen Das Vorgehen zur Umsetzung von QM-Standards wird als Prozesslebenszyklus beschrieben. Dieser beschreibt die verschiedenen Phasen der Nutzung von Prozessen in Unternehmen im Blickwinkel eines QM-Systems. Der Lebenszyklus beginnt mit dem Entwurf eines Prozesses und beschreibt dessen Nutzung und Verbesserung zum Erreichen der strategischen Unternehmensziele. In dieser Arbeit wird ausgehend von einem Lebenszyklusmodell für Prozesse ein neues, erweitertes Modell entwickelt, welches insbesondere die Anforderungen von QM-Standards berücksichtigt. Das Lebenszyklusmodell bildet die Grundlage und den Rahmen für das in dieser Arbeit vorgestellte methodische Vorgehen zur Umsetzung von QM-Standards. x Konzeption eines prozessbasierten Informationssystems für QM-Systeme In verschiedenen Veröffentlichungen [Böhm 2000; Georgakopoulos et al. 1995; Jablonski et Bussler 1996] konnte gezeigt werden, dass Workflow- oder Prozessmanagementsysteme Mitarbeiter und Projektleiter bei der Bearbeitung von Vorgängen unterstützen können. Ausgehend von diesen Konzepten wird ein Informationssystem, der ProcessNavigator, zur Unterstützung von Softwareentwicklungsprozessen konzipiert, welches einerseits die Mitarbeiter durch den Prozess leitet und andererseits die Anforderungen eines QMSystems umsetzt. Im Bezug auf die Anwenderunterstützung wird das Konzept der flexiblen Prozessausführung entwickelt. Dieses adaptiert bestehende Konzepte aus Workflow- und Prozessmanagementsystemen so, dass die Anwender durch den Entwicklungsprozess geleitet und gezielt mit relevanten Informationen versorgt werden. Das neu konzipierte Informationssystem gewährleistet durch eine konsequente Fokussierung auf die beiden Aspekte Qualitätssicherung und Mitarbeiterunterstützung eine umfassende Prozessunterstützung in Softwareentwicklungsprojekten.

12

1 Einführung, Zielsetzung und Aufbau

x Systemarchitektur eines prozessbasierten Informationssystems für QMSysteme Einen weiteren Aspekt dieser Arbeit bildet der Entwurf einer Systemarchitektur für das prozessbasierte Informationssystem. Ein zentrales Ziel beim Entwurf des Systems ist es, seine Änderbarkeit zu gewährleisten. So soll es ermöglicht werden, das System an neue Anforderungen anzupassen und somit in verschiedenen Umgebungen einsetzen zu können. Beim Entwurf der Systemarchitektur wird vor allem das Datenmodell des Speichersystems betrachtet. Hier müssen alle Informationen, die im Prozessmanagementsystem angezeigt werden sollen, strukturiert abgelegt werden. Es müssen sowohl die Anforderungen, die sich direkt aus dem Prozessmanagementsystem ergeben als auch jene die aus der Umsetzung des QM-Modells resultieren, in ein Modell integriert werden. Durch das Speichersystem soll es außerdem ermöglicht werden, die im Datenmodell enthaltenen Informationen einfach und flexibel auswerten zu können. Diese vier Kernaspekte der Arbeit sollen nochmals in die bestehenden Konzept von Abbildung 1-1 und Abbildung 1-2 eingeordnet werden. Zentrales Ziel dieser Arbeit ist die Konstruktion eines prozessbasierten Informationssystems zur Implementierung von QM-Standards (ProcessNavigator), welches die Mitarbeiter und Projektleiter umfassend bei der Bearbeitung von Produkt- bzw. Softwareentwicklungsprojekten unterstützt. Mit dem System sollen insbesondere Anforderungen von QM-Standards, wie sie in der ISO/IEC 15504 bzw. CMMI enthalten sind, erfüllt werden. SoftwareEntwicklungsprozesse

Qualitätsmanagement

SoftwareVorgehensmodell

abstraktes QMModell (aQM2)

QM-Standard

Anwendung V-Modell XT

ISO/IEC 12207 (Prozessdimension) ISO/IEC 15504-5

ISO/IEC 15504-2 (Reifegraddimension)

CMMI erfüllt Vorgaben

in der Arbeit neu entwickelte Konzepte

Abbildung 1-3:

ISO 9001

vorhandene Konzepte

Generalisierung des aQM2 aus den QM-Standards ISO/IEC 15504 und CMMI

1.2 Beitrag der Arbeit

13

In Abbildung 1-3 wird die Beziehung zwischen dem aQM2 und den bestehenden QMStandards ISO/IEC 15504 und CMMI gezeigt. Das aQM2 identifiziert die Kernanforderungen der beiden anderen QM-Standards und abstrahiert sie in ein gemeinsames Modell. Dieses Modell ist selbst kein weiterer QM-Standard, sondern fasst die Kernanforderungen aus ISO/IEC 15504 und CMMI in einem eigenen Modell zusammen. Dieses ist im Sinne der objektorientierten Programmierung „abstrakt“ und aus diesem Grund nicht direkt als QM-Standard anwendbar. Abbildung 1-4 stellt den Einfluss des aQM2 auf den ProcessNavigator dar. Der ProcessNavigator ist ein Prozessausführungssystem. Er wird mit dem Ziel entwickelt Anwender bei der Bearbeitung von Projekten zu unterstützen. Die im ProcessNavigator umgesetzten Anforderungen stammen aus zwei Quellen. Zum einen müssen die Anforderungen der Anwender im Unternehmen (vgl. Kapitel 4) erfüllt werden; der ProcessNavigator muss Anwender bei der Bearbeitung des Projekts unterstützen. Zum anderen müssen die Anforderungen der QM-Standards umgesetzt werden; diese werden durch das aQM2 festgelegt. Beide Anforderungen sind orthogonal zu einander und ergänzen sich gegenseitig. Das QM-Vorgehensmodell Six Sigma wird im ProcessNavigator genutzt um verschiedene Anforderungen des aQM2 umzusetzen. Im Unterschied zur ISO/IEC 15504 bzw. dem CMMI beschreibt es keine Anforderungen sondern ein Vorgehen zur Verbesserung von Prozessen; es eignet sich somit als Ergänzung bzw. als Mittel zur Umsetzung der beiden reifegradorientierten QM-Standards. Externe Anforderungen und Vorgaben

abstraktes QMModell (aQM2)

Unternehmensinterne Konzepte und Systeme

Six Sigma

Anwender definiert Anforderungen

Prozessausführungssystem

Anforderungen der QM-Standards

definiert Anforderungen Anforderungen der Anwender

definiert Anforderungen

beschreibt Standardvorgehen Prozesse

unterstützt die Umsetzung Projekt

wird genutzt ProcessNavigator

in der Arbeit neu entwickelte Konzepte

Abbildung 1-4:

vorhandene Konzepte

Der ProcessNavigator als Ergebnis aus Anforderungen der QM-Standards und der Anwender

14

1 Einführung, Zielsetzung und Aufbau

Zusammenfassend lässt sich der Nutzen des in dieser Arbeit konzipierten ProcessNavigators auf drei Kernaspekte verdichten: 1. Steigerung der Transparenz im Entwicklungsprojekten durch die IT-unterstützte Prozessausführung 2. Unterstützung der Anwender im Entwicklungsprozess durch die Bereitstellung eines Leitfadens für die Prozessausführung 3. Umsetzung der Anforderungen aus QM-Standards durch die validierte Ausführung der einzelnen Anforderungen im Informationssystem In der Arbeit werden zuerst die fachlichen Anforderungen an ein solches System aus QM-Sicht analysiert, anschließend das prozessbasierte Informationssystem entworfen und abschließend die Architektur des Systems betrachtet. Durch eine Abstraktion des Anforderungsgerüsts von den konkreten Anforderungen eines QM-Standards wird sichergestellt, dass das System nicht nur Forderungen eines einzelnen QMStandards umsetzt, sondern vielseitig anwendbar ist. 1.3

Aufbau der Arbeit

Die Arbeit gliedert sich in 15 Kapitel deren Abhängigkeiten in Abbildung 1-5 vorgestellt werden. Die Arbeit ist in drei Teile untergliedert. Teil I bestehend aus Kapitel 1 bis Kapitel 4 beschreibt die Anforderungen, die an ein Informationssystem zur Umsetzung eines QM-Systems in Unternehmen gestellt werden. Teil II der Arbeit stellt die Umsetzung dieser Anforderungen in einem prozessbasierten Informationssystem vor. Abschließend stellt Teil III dessen Systemarchitektur vor und fasst die Ergebnisse der Arbeit zusammen. Nach der Einführung in das Thema stellt Kapitel 2 die in dieser Arbeit verwendeten Vorgehens- und QM-Modelle vor. Es legt damit die inhaltlichen Grundlagen für die restlichen Kapitel der Arbeit. Das Kapitel unterteilt sich in zwei Abschnitte. Zuerst werden die in der Arbeit verwendeten QM-Standards (die ISO/IEC 15504 und das CMMI) eingeführt. Diese beiden Normen bilden aus Sicht des Qualitätsmanagements den Rahmen der vorliegenden Arbeit. Das V-Modell XT wird als Vertreter eines Vorgehensmodells zur Softwareentwicklung vorgestellt. In den Kapiteln 3 und 4 werden die Anforderungen, die an ein Informationssystem zur Unterstützung von QM-Systemen gestellt werden, erarbeitet. Im Kapitel 3 wird das aQM2 als gemeinsamer Anforderungsrahmen der ISO/IEC 15504 und des CMMI entwickelt. Kapitel 4 beschreibt die Anforderungen an ein prozessbasiertes Informationssystem aus Sicht seiner Anwender. Somit ergänzen sich QM-Anforderungen und Anwenderanforderungen zu einem gemeinsamen Anforderungsrahmen.

1.3 Aufbau der Arbeit

15

Der Teil II dieser Arbeit entwirft basierend auf den gestellten Anforderungen ein prozessbasiertes Informationssystem für QM-Systeme. Zu Beginn wird in Kapitel 5 ein Vorgehensmodell zur Umsetzung von QM-Anforderungen entworfen. Dazu wird ausgehend von einem einfachen Prozesslebenszyklus ein erweiterter Zyklus entwickelt, welcher um eine explizite Projektplanung ergänzt wurde. Dieser neue Prozesslebenszyklus definiert die Struktur der Kapitel 7 bis 10. Vor der detaillierten Vorstellung der einzelnen Phasen des Prozesslebenszyklus gibt Kapitel 6 einen Ausblick auf die spätere Umsetzung der QM-Anforderungen. Das Kapitel ist ein Wegweiser, in dem stichpunktartig die Umsetzung des aQM2 vorgestellt wird. Kapitel 7 beschreibt die Definition eines Prozesstypen und seine Validierung im Bezug auf die Anforderungen des QM-Modells. Die Transformation des Prozesstyps in einen Projekttyp wird im anschließenden Kapitel 8 gezeigt. Kapitel 9 zeigt, wie QM-Anforderungen und Anwenderanforderungen in einem prozessbasierten Informationssystem umgesetzt werden können. Es wird insbesondere darauf eingegangen, wie Mitarbeiter durch ein Prozessmanagementsystem unterstützt werden können, ohne die in Entwicklungsprozessen benötigte Prozessflexibilität einzuschränken. Das Kapitel 10 demonstriert wie die Ausführungsinformationen zur Prozessverbesserung und in QM-Assessments genutzt werden können. Kapitel 11 ergänzt das, in den Kapiteln 7 bis 10 beschriebene Vorgehen um die Methodik Six Sigma, mit der der Reifegrad der Prozesse weiter erhöht werden kann. Teil III stellt die Architektur des Informationssystems in Kapitel 12 vor. Dabei wird nach einer Vorstellung der benötigten Systemkomponenten vor allem auf die Speicherschicht des Systems eingegangen. Kapitel 13 stellt eine Evaluierung des Systems vor; dabei wurde zusammen mit Forschungspartnern aus Unternehmen untersucht, ob der ProcessNavigator auch die an ihn gestellten Anforderungen erfüllt. Kapitel 14 fasst die zentralen Aspekte der Arbeit zusammen und Kapitel 15 schließt die Arbeit mit einem Ausblick auf mögliche Erweiterungen ab.

16

1 Einführung, Zielsetzung und Aufbau

Ein Konzept zur Implementierung von prozessorientierten Qualitätsmanagementsystemen

Kapitel 1: Einführung, Zielsetzung und Aufbau

Teil I: Anforderungen an ein Qualitätsmanagementsystem

Kapitel 2: QM-Standards und Vorgehensmodelle Kapitel 3: Rekonstruktion des abstrakten QM-Modells

Kapitel 4: Anforderungen an ein prozessbasiertes Informationssystem aus Anwendersicht

Kapitel 5: Entwurf eines Vorgehensmodells zur Umsetzung von QM-Anforderungen Kapitel 6: Ausblick: Umsetzung der QMAnforderungen im ProcessNavigator

Teil II: Konzeption eines prozessbasierten Informationssystems für QM-Systeme

Kapitel 7: Erstellung einer validierten Prozesslandschaft Kapitel 8: Erstellung eines validierten Projekttyps Kapitel 9: Projektdurchführung Kapitel 10: Nachbereitung der Projektausführung Kapitel 11: Systematische Messung und Prozessverbesserung

Kapitel 12: Systemarchitektur Kapitel 13: Evaluation des ProcessNavigators Kapitel 14: Zusammenfassung Kapitel 15: Ausblick

Abbildung 1-5:

Aufbau der Arbeit

Teil III: Umsetzung und Schlussfolgerungen

2

QM-Standards und Vorgehensmodelle

Für Kunden ist die Zusicherung, dass ein Softwareanbieter oder Zulieferer bei der Entwicklung der Software definierte Mindestanforderungen einhält, ein wichtiges Kriterium bei der Vergabe von Aufträgen. Da die Qualität von Software, wie im Abschnitt 1.1 beschrieben, nur schwer zu testen ist, wird in dieser Arbeit der Ansatz gewählt über die Gestaltung, Messung und Optimierung des Softwareentwicklungsprozesses die Qualität des Produkts zu verbessern. Zur Verbesserung (bzw. Beeinflussung) dieses Entwicklungsprozesses wurden zwei Vorgehensweisen entwickelt: Vorgehensmodelle, die direkt aus Sicht der Softwareentwicklung nötige Arbeitsschritte vorschreiben, und QM-Standards, mit denen die Güte des Entwicklungsprozesses bewertet werden kann. Dieses Kapitel stellt die in der Arbeit genutzten Vorgehensmodelle und Qualitätsmanagement-Standards vor. Damit legt es aus QM-Sicht die inhaltlichen Grundlagen für die weitere Arbeit. Dieses Kapitel ist in zwei Abschnitte unterteilt: zuerst wird das VModell XT vorgestellt, anschließend die beiden QM-Normen ISO/IEC 15504 und CMMI. Das V-Modell XT ist ein konfigurierbares Vorgehensmodell, welches vor allem bei Softwareentwicklungen, die durch öffentliche Auftraggeber beauftragt werden, genutzt wird. Die ISO/IEC 15504 und das CMMI sind zwei QM-Reifegradmodelle, mit denen der Reifegrad eines Entwicklungsprozesses und dessen Institutionalisierung im Unternehmen bewertet werden kann. Im Unterschied zu Vorgehensmodellen beschreiben Reifegradmodelle keinen Ablauf der Produktentwicklung, sondern definieren Anforderungen an einen Prozess. Diese Anforderungen werden in einem Assessment durch einen Assessor überprüft und der Reifegrad des Prozesses wird ermittelt. 2.1

Das V-Modell XT als Vorgehensmodell zur Softwareentwicklung

Das V-Modell XT [Höhn et Höppner 2008; V-Modell XT (Version 1.3)] stellt eine Weiterentwicklung des V-Modells 97 dar. Dieses und sein Vorgänger, das V-Modell 92, wurden ursprünglich unter dem Namen „Entwicklungsstandard für IT-Systeme des Bundes (EstdIT)“ entwickelt, um die Qualität von IT-Systemen und die Erfolgswahrscheinlichkeit von Projekten zu erhöhen. Das V-Modell XT wurde im Februar 2005 veröffentlicht und stellt den aktuellen Entwicklungsstand des V-Modells dar. Die Namenserweiterung „XT“ steht dabei für „extreme Tailoring“ und deutet an, dass die Anpassbarkeit des Modells an die Erfordernisse der Projekte und der Unternehmen ein wesentlicher Bestandteil beim Entwurf des Vorgehensmodells war. Das V-Modell XT wird detailliert in [Bartelt et al. 2005] und [Höhn et Höppner 2008] vorgestellt.

18

2 QM-Standards und Vorgehensmodelle

In der Dokumentation zum V-Modell XT [V-Modell XT (Version 1.3)] werden die folgenden Zielsetzungen beim Entwurf des Modells genannt: x Minimierung der Projektrisiken Durch die im V-Modell beschriebenen standardisierten Vorgehensweisen sollen Transparenz und Planbarkeit des Projekts erhöht werden. Diese Effekte sollen sich vor allem aus den im Modell gemachten Vorgaben an Arbeitsschritte, Rollen und Arbeitsergebnisse ergeben. Durch die erhöhte Planungssicherheit sollen die Projektrisiken vermindert werden. x Verbesserung und Gewährleistung der Qualität Neben der Minimierung der Projektrisiken wird durch die Standardisierung der Arbeitsabläufe auch eine Verbesserung der Qualität angestrebt. Dies soll unter anderem dadurch erreicht werden, dass zu liefernde Ergebnisse frühzeitig im Prozess verfügbar sind und durch Reviews begutachtet werden können. x Eindämmung der Gesamtkosten über den gesamten Projekt- und Systemlebenszyklus Das im V-Modell standardisierte Vorgehen soll es ermöglichen, den Aufwand für die Entwicklung, die Herstellung, den Betrieb und die Pflege abzuschätzen und steuern zu können. Auch soll durch ein einheitliches Vorgehensmodell die Abhängigkeit von einem Anbieter reduziert werden. x Verbesserung der Kommunikation zwischen allen Beteiligten Durch das V-Modell soll auch die Kommunikation zwischen den am Projekt beteiligten Gruppen verbessert werden. Durch das standardisierte Vorgehensmodell sollen insbesondere Missverständnisse zwischen Nutzer, Auftraggeber, Auftragnehmer und Entwickler vermieden werden. Das V-Modell XT adressiert den gesamten Systemlebenszyklus eines Projekts von der internen Genehmigung zum Start, über die Ausschreibung, bis hin zum Abschluss nach erfolgter Inbetriebnahme beim Kunden. Das V-Modell beschreibt ein standardisiertes Vorgehen, welches sich durch verschiedene Konfigurations- bzw. TailoringMechanismen an die Gegebenheiten des jeweiligen Projekts anpassen lässt. Das VModell wurde vor allem entwickelt, um Systementwicklungsprojekte für öffentliche Auftraggeber abwickeln zu können. Hier regelt es detailliert die Kooperation zwischen Auftraggeber und Auftragnehmer, indem es die Verantwortlichkeiten der jeweiligen Vertragsparteien festlegt [Höppner et Lübben 2008]. Dies hat zur Folge, dass verschiedene Angebote, die auf dem V-Modell basieren, einfacher miteinander verglichen werden können.

2.1 Das V-Modell XT als Vorgehensmodell zur Softwareentwicklung

19

Die erste Stufe der Anpassung an den Projektkontext wird durch den Projekttyp festgelegt. Im V-Modell XT sind vier verschiedene Projekttypen vorgesehen: x Systementwicklungsprojekt eines Auftraggebers; x Systementwicklungsprojekt eines Auftragnehmers; x Systementwicklungsprojekt eines Auftraggebers mit Auftragnehmer in der gleichen Organisation (ohne Ausschreibungs- und Vertragswesen); x Einführung und Pflege eines organisationsspezifischen Vorgehensmodells. Ein Systementwicklungsprojekt beschreibt die Entwicklung eines IT-Systems. Dieses wird im V-Modell aus drei verschiedenen Perspektiven bzw. Anwendungsfällen betrachtet. Einerseits gibt es die Perspektive des Auftraggebers. Das V-Modell definiert hier die verschiedenen Aufgaben des Auftraggebers von der Definition des Projekts, der Ausschreibung des Projekts, der Vergabe des Auftrags bis zu Abnahme und Abschluss des Projekts. Zum anderen gibt es die Perspektive des Auftragnehmers. Hier definiert das V-Modell die Arbeitsschritte, die zur Abgabe eines Angebots sowie zur Entwicklung und zum Testen des Systems nötig sind. Für Fälle, in denen es sich um ein internes Projekt handelt, existiert im V-Modell die Version „Auftraggeber mit Auftragnehmer in der gleichen Organisation“. Hier entfällt beispielsweise ein Baustein zur Abgabe eines Angebots, da dies organisationsintern in den meisten Fällen nicht nötig ist. Der Projekttyp „Einführung und Pflege eines organisationsspezifischen Vorgehensmodells“ unterscheidet sich von den anderen drei Projekttypen; er beschreibt nicht die Tätigkeiten, die zur Systementwicklung nötig sind, sondern jene zur Einführung eines neuen Vorgehensmodells in der Organisation. Mit der Auswahl eines Projekttypen werden verschiedene Tätigkeitsblöcke (Vorgehensbausteine) ausgewählt, die zur Umsetzung des Projekts notwendigen Aufgaben beschreiben. Vorgehensbaustein Disziplin

*

Rolle

* wirkt mit

hat Abhängigkeiten zu anderen 1..* * * Produkt 1 1

ist 0/1 verantwortlich IE *

* Thema

Abbildung 2-1:

1

stellt fertig 0/1

*

bearbeitet

Bestandteile eines Vorgehensbausteins (Abbildung aus [V-Modell XT (Version 1.3)])

*

gehört zur selben Disziplin wie das Produkt Aktivität 1 * Arbeitsschritt

20

2 QM-Standards und Vorgehensmodelle

In den Vorgehensbausteinen des V-Modells werden verschiedene Aktivitäten zu einer modularen Einheit zusammengefasst. In Abbildung 2-1 ist das Schema eines solchen Vorgehensbausteins dargestellt. In einem Vorgehensbaustein werden jene Produkte zusammengefasst, die für seine Fertigstellung relevant sind. Produkte stehen im Mittelpunkt des V-Modells, da sie die zentralen Projektergebnisse darstellen. Ein Produkt kann wiederum in verschiedene Themen untergliedert werden. Produkte werden in Aktivitäten erstellt, welche erneut in Arbeitsschritte unterteilt werden können, die für die Bearbeitung der Themen zuständig sind. Eine Disziplin gruppiert im V-Modell XT eine Menge an inhaltlich zusammenhängenden Produkten und Arbeitsschritten (z.B. Angebots- und Vertragswesen oder Systementwurf). Rollen sind im V-Modell entweder für die Erstellung eines Produktes verantwortlich, oder sie wirken bei seiner Entstehung mit. Je nach Projekttyp wird bei der Konfiguration eines Projekts eine unterschiedliche Menge an Vorgehensbausteinen und damit auch Produkten und Aktivitäten selektiert. Zwei weitere wichtige Konzepte des V-Modells XT sind Entscheidungspunkte und Projektdurchführungsstrategie. Entscheidungspunkte beschreiben das Erreichen eines gewissen Fortschritts im Projekt (z.B. Projekt beauftragt, System spezifiziert). Die Entscheidung wird aufgrund der verfügbaren Produkte getroffen; entsprechend wird im V-Modell jedem Entscheidungspunkt eine Menge an Produkten zugeordnet. Die Projektdurchführungsstrategie entscheidet über die Reihenfolge, in der Entscheidungspunkte bearbeitet werden müssen. In Abbildung 2-2 sind zwei Projektdurchführungsstrategien des V-Modells abgebildet. Im oberen Teil a) wird die inkrementelle Durchführungsstrategie dargestellt. In dieser lässt sich die klassische V-Form des Vorgehensmodells klar erkennen. Demgegenüber wird im unteren Teil b) eine agile Durchführungsstrategie vorgestellt. Bei diesem Ansatz wird auf eine Spezifikation des Systems vor seiner Realisierung verzichtet. Stattdessen wird in vielen kleinen Iterationen das System im Zusammenspiel mit dem Kunden umgesetzt [Schach 2007]. Diese Iterationen sind zwischen den Entscheidungspunkten „Systemelemente realisiert“ und „Feinentwurf abgeschlossen“ zu erkennen. Im Vergleich zum älteren V-Modell 97 sind im neueren V-Modell XT also verschiedene Strategien zur Bearbeitung des Modells möglich. Damit wurde vor allem neuen Entwicklungen im Software Engineering Rechnung getragen.

2.1 Das V-Modell XT als Vorgehensmodell zur Softwareentwicklung

21

a) Angebot abgegeben

Projekt beauftragt

Abnahme erfolgt

Abnahme erfolgt

System spezifiziert

Iteration geplant

1..*

1..*

System integriert

1..*

Projektfortschritt überprüft

Unterauftrag

0..*

Feinentwurf abgeschlossen

Projekt abgeschlossen

Lieferung durchgeführt

System entworfen Y

Iteration geplant

Y

Unterauftrag

Projekt ausgeschrieben

Projekt beauftragt

0..*

Y

Projekt definiert

Y

Projekt genehmigt

1..*

Systemelemente realisiert

b) Projekt genehmigt

Projekt definiert

Angebot abgegeben

Projekt beauftragt

Abnahme erfolgt Iteration geplant

Unterauftrag

Projekt beauftragt

Abnahme erfolgt

Iteration geplant Projektfortschritt überprüft

1..*

Y

Projekt ausgeschrieben

Projekt abgeschlossen

Systemelemente realisiert 0..1 Y 0..*

System entworfen

Feinentwurf abgeschlossen

Unterauftrag

0..* Y 0..1

System integriert

Y 1..*

System spezifiziert

Abbildung 2-2:

Lieferung durchgeführt

Projektdurchführungsstrategien und Entscheidungspunkte im V-Modell XT (Abbildung aus [V-Modell XT (Version 1.3)])

Ein zentrales Element des V-Modells ist seine Anpassbarkeit an die Gegebenheiten eines Projekts. Diese projektspezifische Anpassung des Modells an die Anforderungen des Projekts wird auch als Tailoring bezeichnet. Die Anpassung des V-Modells beschränkt sich dabei auf die folgenden drei Merkmale [V-Modell XT (Version 1.3)]: x die Auswahl eines Projekttyps x die Auswahl eines der möglichen Projekttypvarianten x die Belegung der dazugehörigen Projektmerkmale mit Werten Mit der Auswahl des Projekttyps werden auch die für diesen Typ verpflichtend anzuwendenden Vorgehensbausteine und die zu erstellenden Produkte ausgewählt. Die Projektdurchführungsstrategie und damit die Reihenfolge, in der die Entscheidungspunkte abgearbeitet werden müssen, kann während der Auswahl der Projekt-

22

2 QM-Standards und Vorgehensmodelle

typvariante selektiert werden. Durch die Bestimmung der Projektmerkmale können zusätzliche Vorgehensbausteine in das Projekt mit aufgenommen werden. Durch das Tailoring lassen sich also sowohl die Projektinhalte als auch die Reihenfolge der Bearbeitung auf die Projektanforderungen abstimmen. Zur Unterstützung der Nutzer wurde ein Softwareprogramm, der V-Modell XT Projektassistent [V-Modell XT Projektassistent] entwickelt, welches den Nutzer bei der Konfiguration des Modells unterstützt. Durch das Vorgehensmodell steht dem Unternehmen, wie in Abbildung 1-1 dargestellt ein aufgearbeiteter Entwicklungsprozess zur Verfügung. Dieser beschreibt ein Standardvorgehen zur Entwicklung von Software; dieses wurde im Regelfall von Experten erstellt und stellt Best Practices (eine Erfolgsmethode) für die Softwareentwicklung zur Verfügung. Insbesondere für kleine Unternehmen bringt dies große Vorteile mit sich, da diese nicht die personellen Kapazitäten besitzen, um ein eignes Vorgehen zu entwickeln. Die Unternehmen können das Vorgehensmodell grundsätzlich übernehmen und können es bei Bedarf an ihre eigenen Anforderungen anpassen. 2.2

CMMI und ISO/IEC 15504 als Modelle zur Bewertung der Prozessreife

Qualitätsmanagementstandards im Bereich der Produktentwicklung wurden entwickelt, um Anforderungen an die Umsetzung von Entwicklungsprojekten zu definieren bzw. um dieses bewerten zu können. Als Grundlage für das QM-Anforderungsmodell, welches in Kapitel 3 entwickelt wird, werden die beiden Standards CMMI und ISO/IEC 15504 genutzt. Beide Normen sind international verbreitet und werden als Basis für Prozessbewertungen genutzt. Für Unternehmen bringt die Anwendung von QM-Standards zwei wesentliche Vorteile. Ähnlich den Vorgehensmodellen bringen sie auch eine Menge an Best Practices mit (z.B. Base Practices in der ISO/IEC 15504), die direkt im Unternehmen eingesetzt werden können und so die Güte des Entwicklungsprozesses verbessern. Außerdem können in einem Assessment durch einen externen Gutachter (den Assessor) Probleme in den Prozessen aufgezeigt werden, die anschließend durch das Unternehmen abgestellt werden können. Den Kunden eines Unternehmens, welches nach einem QM-Standard zertifiziert ist, wird durch einen unabhängigen Gutachter bestätigt, dass sich das Unternehmen an bestimmte, durch den QM-Standard festgelegte Vorgaben hält. Damit verbunden ist auch die Erwartung, dass mit dem Reifegrad des Prozesses auch die Qualität des Produktes steigt. Dieser Abschnitt soll einen Überblick über beide Modelle geben und deren grundlegende Strukturen und Zusammenhänge verdeutlichen. Für eine genaue Beschreibung der Anforderungen wird auf die Normen selbst verwiesen [CMMI Product Team 2006; ISO/IEC 15504-5:2006]. Da es keine offiziellen Übersetzungen der Referenzmodelle

2.2 CMMI und ISO/IEC 15504 als Modelle zur Bewertung der Prozessreife

23

(weder CMMI noch ISO/IEC 15504) ins Deutsche gibt, werden die englischen Originaltexte aus den Standards genutzt. 2.2.1

CMMI (Capability Maturity Model Integration)

Das Capability Maturity Model Integration (CMMI) wurde am Software Engineering Institute der Carnegie Mellon University entwickelt. Das aktuell gültige CMMI (Version 1.2) geht zurück auf das Software Process Maturity Framework. Dieses wurde 1987 mit dem Ziel veröffentlicht, Unternehmen, an die das amerikanische Verteidigungsministerium Entwicklungsaufträge vergab, durch einen objektiven Kriterienkatalog vergleichen zu können. Aktuell (Stand Oktober 2009) gibt es drei verschiedene CMMI-Modelle: CMMI for Development, CMMI for Acquisition und CMMI for Services. Alle drei Modelle liegen in der Version 1.2 vor. Für die Entwicklung von Software ist vor allem das CMMI for Development von Bedeutung und es soll aus diesem Grund hier näher betrachtet werden. Wenn im Folgenden vom CMMI gesprochen wird, ist immer das CMMI for Development gemeint. Im CMMI sind zwei verschieden Ansätze zur Prozessbewertung und Verbesserung enthalten, die alternativ genutzt werden können: die kontinuierliche Darstellung (continuous representation) und die stufenförmige Darstellung (staged representation). Beide Unterscheiden sich sowohl in der Methode, nach der die Prozessreife gemessen wird, als auch in den Aussagen, die sich mit dem Ansatz treffen lassen. Bevor kurz die Unterschiede zwischen den beiden Modellen betrachtet werden sollen, müssen zwei grundlegende Konzepte des CMMI geklärt werden: x Reifegradstufen: Sie treffen eine Aussage darüber, wie gut ein Prozess in einem Unternehmen umgesetzt ist bzw. wie fähig das Unternehmen selbst ist. In der kontinuierlichen Darstellung wird dies als Fähigkeit (Capability) bezeichnet, in der stufenförmigen Darstellung als Reifegrad (Maturity). Trotz der begrifflichen Unterscheidung treffen beide Darstellungen jedoch vergleichbare Aussagen. x Prozessgebiete (Process Area): Ein Prozessgebiet ist eine Menge an bewährten Methoden, die thematisch zusammengehören. Werden alle Methoden eines Prozessgebiets umgesetzt, so soll sich im Hinblick auf die Ziele des Prozessgebiets eine signifikante Verbesserung des Prozesses ergeben [CMMI Product Team 2006]. Bei der kontinuierlichen Darstellung wird jedes Prozessgebiet einzeln, anhand festgelegter Kriterien überprüft und eine Fähigkeitsstufe für dessen Umsetzung festgelegt. Die stufenförmige Darstellung trifft hingegen keine Aussage über einzelne Prozessgebiete, sondern über das gesamte Unternehmen. Um eine bestimmte

24

2 QM-Standards und Vorgehensmodelle

Reifegradstufe zu erreichen, müssen alle von dieser Stufe referenzierten Prozessgebiete im Unternehmen umgesetzt worden sein. In Tabelle 2-1 werden weitere Unterschiede zwischen beiden Ansätzen, die in der Dokumentation des CMMI [CMMI Product Team 2006; Kneuper 2006] genannt werden, vorgestellt. Tabelle 2-1:

Unterschiede zwischen kontinuierlicher und stufenförmiger Darstellung des CMMI

Kontinuierliche Darstellung

Stufenförmige Darstellung

Ermöglicht es die Umsetzungsreihenfolge der Prozessverbesserungsmaßnahmen so vorzunehmen, dass sie zu den Geschäftszielen des Unternehmens passt

Definiert einen vorgegeben Ansatz (Weg) zur Verbesserung der Unternehmensprozesse, da die Prozessgebiete entsprechend der Reifegradstufen umgesetzt werden können

Ermöglicht es den Unternehmen die Fähigkeit eines einzelnen Prozessgebiets im Entwicklungsprojekt zu messen

Ist auf eine Menge an Prozessen fokussiert, die im Gesamtunternehmen eine, für jeden Reifegrad spezifische Menge an Fertigkeiten umsetzt

Erlaubt unterschiedliche Verbesserungsgeschwindigkeiten für verschiedene Prozesse und Prozessgebiete

Fasst die gesamte Prozessverbesserung in einer einzelnen Zahl, dem Reifegrad, zusammen

Stellt den neueren der beiden CMMI Ansätze dar, der jedoch auch erst seinen Nutzen zeigen muss

Baut auf einer langen Erfahrungshistorie auf, die Fallstudien beinhaltet und die den Erfolg des Ansatzes belegen kann

Zusammenfassend liegt der Unterschied zwischen kontinuierlicher Darstellung und der stufenförmigen Darstellung darin, dass bei der kontinuierlichen Darstellung ein Fähigkeitsprofil erzeugt wird, mit dem die Umsetzung jedes Prozessgebiets einzeln bewertet werden kann, und der Verdichtung des Reifegrads auf eine einzige Zahl in der stufenförmigen Darstellung. Im CMMI ist außerdem eine Methode („Equivalent Staging“) vorgesehen, mit der ein Fähigkeitsprofil in einem Reifegrad umgewandelt werden kann. Somit lässt sich auch für Unternehmen, die im CMMI nach der kontinuierlichen Darstellung bewertet wurden, ein Reifegrad für das gesamte Unternehmen festlegen.

2.2 CMMI und ISO/IEC 15504 als Modelle zur Bewertung der Prozessreife

25

In dieser Arbeit soll weiterhin nur noch die kontinuierliche Darstellung betrachtet werden, da mit ihr genauere Aussagen über die Fähigkeit eines Prozesses (Fähigkeitsprofil) getroffen werden können. Auch bietet dieser Ansatz mehr Flexibilität im Bezug auf die Verbesserungen, die im Unternehmen umgesetzt werden sollen und in welcher Reihenfolge diese umgesetzt werden. Zentrales Element des Bewertungsschemas im CMMI sind die Fähigkeits- bzw. Reifegrade. Sie treffen eine Aussage darüber, wie gut ein Prozess in Unternehmen integriert ist. Im CMMI wird in diesem Zusammenhang auch von der „Institutionalisierung“ gesprochen. Sie beschreibt, wie gut ein geplanter Prozess in die alltäglichen Arbeitsabläufe eines Unternehmens eingebunden ist. In der kontinuierlichen Darstellung sind die folgenden sechs Stufen vorgesehen [CMMI Product Team 2006; Kneuper 2006]: 0. Unvollständig (Incomplete) Ein „unvollständig“ ausgeführter Prozess wird entweder gar nicht oder nur teilweise ausgeführt. Die in den Prozessgebieten formulierten Ziele werden nicht erfüllt und der Prozess ist im Unternehmen nicht etabliert. 1. Durchgeführt (Performed) Ein auf Stufe 1 ausgeführter Prozess wird „durchgeführter Prozess“ genannt. Die Ziele der einzelnen Prozessgebiete werden erreicht und der Prozess unterstützt die Erstellung der Arbeitsergebnisse. 2. Gemanagt3 (Managed) Erreicht ein Prozess die Fähigkeitsstufe 2 so wird von einem „gemanagten Prozess“ gesprochen. Der Prozess erfüllt die Anforderungen der Stufe 1 und besitzt gleichzeitig die nötige Infrastruktur zur Unterstützung der ausgeführten Prozesse. Der Prozess wird entsprechend einer vorher definierten Strategie geplant und ausgeführt; im Prozess werden fähige Mitarbeiter eingesetzt; alle Beteiligten (Auftraggeber und Auftragnehmer) sind im Projekt eingebunden und die Ausführung des Projekts wird im Bezug auf seine Planung kontrolliert und gesteuert. Dieser Fähigkeitsgrad soll dazu führen, dass die Ziele der Prozessgebiete auch unter Stress weiter umgesetzt werden.

3

In der deutschen Sprache wird der englische Begriff „managed“ besser mit „gelenkt“ oder „geleitet“ übersetzt. Da in der Literatur jedoch der Begriff „gemanagt“ zur Benennung der Fähigkeitsstufe 2 genutzt wird, wird diese auch in der vorliegenden Arbeit entsprechend bezeichnet.

26

2 QM-Standards und Vorgehensmodelle

3. Definiert (Defined) Ein auf Stufe 3 ausgeführter Prozess wird als „definierter Prozess“ bezeichnet. Er ist ein gemanagter Prozess (Anforderungen der Stufe 2), der aus einem vorher definierten Standardprozess des Unternehmens abgeleitet (Process Tailoring) wurde. Für dieses Tailoring müssen im Unternehmen vorhandene Richtlinien genutzt werden, um den Prozess und die zu erstellenden Arbeitsprodukte an die Anforderungen des Vorhabens anzupassen. 4. Quantitativ gemanagt (Quantitatively Managed) Mit dem Erreichen der Fähigkeitsstufe 4 wird von einem „quantitativ gemanagten“ Prozess gesprochen. Der Prozess erfüllt die Anforderungen der Stufe 3. Zusätzlich werden quantitative Ziele, basierend auf den Anforderungen der Kunden und des Unternehmens festgelegt. Diese Ziele werden mit Hilfe statistischer Methoden im Hinblick auf ihre Umsetzung überprüft und verstanden. 5. Optimierend (Optimizing) Auf Fähigkeitsstufe 5 werden die Anforderungen der Stufe 4 erfüllt und die dort gesammelten statistischen Informationen genutzt, um den Prozess zu verbessern. Das zentrale Element des CMMI ist das Prozessgebiet. Es definiert die inhaltlichen Anforderungen, die während der späteren Prozessausführung umgesetzt werden müssen. Jedes Prozessgebiet hat eine Beschreibung seines Zwecks, eine kurze Einleitung sowie einen Verweis auf ähnliche bzw. verwandte Prozessgebiete. Diese Elemente besitzen jedoch nur eine Informationsfunktion für den Anwender; ausschlaggebend für die Bewertung und Festlegung einer Fähigkeitsstufe ist die Implementierung der spezifischen und generischen Ziele des Prozessgebiets. In Abbildung 2-3 wird der strukturelle Aufbau eines Prozessgebiets und der Zusammenhang zwischen den Elementen gezeigt. In einem Assessment zur Feststellung der Fähigkeitsstufe des Prozesses wird durch den Assessor überprüft, ob die spezifischen und generischen Ziele der Prozessgebiete umgesetzt werden. Spezifische Ziele beschreiben die für jedes Prozessgebiet einzigartigen Eigenschaften, die zu seiner Erfüllung notwendig sind. Im Gegensatz zu spezifischen Zielen finden generische Ziele nicht nur in einem einzigen Prozessgebiet Anwendung, sondern müssen in allen Prozessgebieten umgesetzt werden. Jedes Prozessgebiet konkretisiert die allgemeine Formulierung der generischen Ziele für die Anwendung auf das Prozessgebiet. Durch spezifische und generische Praktiken werden im Standard Anhaltspunkte gegeben, wie die Ziele umgesetzt werden können. Die Umsetzung der spezifischen und generischen Ziele des Prozesses wird im

2.2 CMMI und ISO/IEC 15504 als Modelle zur Bewertung der Prozessreife

27

Assessment durch den Assessor überprüft; beide sind zum Erreichen einer bestimmten Fähigkeitsstufe erforderlich. Die im CMMI vorhandenen generischen Ziele werden in Abschnitt 3.2 vollständig aufgezählt und beschrieben.

Prozessgebiet

Zweck

Spezifische Ziele

Generische Ziele

Spezifische Praktiken

Generische Praktiken

Typische Arbeitsergebnisse

Abbildung 2-3:

Ähnliche Prozessgebiete

Einleitung

Sub-Praktiken

Typische Arbeitsergebnisse

Sub-Praktiken

Struktur der CMMI-Prozessgebiete [CMMI Product Team 2006]

Am Beispiel des Prozessgebiets „Configuration Management“, welches die Sicherstellung der Vollständigkeit der Arbeitsergebnisse durch ein Konfigurationsmanagementsystem zum Ziel hat, soll der Unterschied zwischen spezifischen und generischen Zielen verdeutlicht werden. Das Prozessgebiet enthält ein spezifisches Ziel „SG 1 Establish Baselines“, welches die Definition einer Produktkonfiguration (Baseline) fordert. Dieses Ziel ist nur im Prozessgebiet „Configuration Management“ vorhanden und auch anwendbar. Ein generisches Ziel dieses Prozessgebiets ist das Folgende: „Establish and maintain an organizational policy for planning and performing the configuration management process”. Dieses wurde aus dem allgemeiner formulierten generischen Ziel „GP 2.1 - Establish an Organizational Policy“ abgeleitet. Dieses generische Ziel ist in ähnlicher Form auch in anderen Prozessgebieten enthalten, z.B. „Establish and maintain an organizational policy for planning and performing the project planning process“ im Prozessgebiet „Project Planning“. Somit definieren spezifische Ziele Anforderungen an die Umsetzung eines Prozessgebiets im Unternehmen und durch die Angabe der spezifischen Praktiken auch einen Leitfaden, wie diese fachlich umzusetzen sind. Generische Ziele beschreiben hinge-

28

2 QM-Standards und Vorgehensmodelle

gen, wie deren Umsetzung im Unternehmen verankert (institutionalisiert) werden kann. Bei der Entwicklung des im Abschnitt 2.1 beschriebenen V-Modell XT war die Berücksichtigung der Anforderungen der CMMI Ebenen 1 bis 3 eines der Entwicklungsziele. So ist in der Dokumentation des Modells [V-Modell XT (Version 1.3)] im Abschnitt 7 eine Konventionsabbildung des V-Modells XT zum CMMI angegeben. In einer Analyse der Umsetzung [Kneuper 2006] wird beschrieben, dass hier zwar noch verschiedene Lücken bei der Umsetzung der Norm existieren, diese jedoch vor allem Detailfragen betreffen. Zusammenfassend kommt der Autor zum Ergebnis, dass mit dem V-Modell XT die Anforderungen des CMMI Reifegrads 3 weitgehend erfüllt werden können. Die Reifegrade 4 und 5 werden nicht umgesetzt. 2.2.2

ISO/IEC 15504 (SPICE)

Als Reaktion auf die Entwicklung des CMMI-Modells in den USA wurde in Europa das Projekt „Bootstrap“ [Haase et al. 1994] ins Leben gerufen. Dieses Projekt hatte das Ziel, ein dem CMMI vergleichbares Bewertungsmodell zu entwickeln. Aufbauend auf den dort erzielten Ergebnissen wurde 1992 das SPICE Projekt mit dem Ziel gegründet eine internationale Norm zu definieren. Der Standard wurde schließlich Anfang 2003 von der ISO unter der Bezeichnung ISO/IEC 15504 verabschiedet. Der Standard ist in die folgenden sieben Teile untergliedert: x Part 1: Concepts and vocabulary x Part 2: Performing an assessment x Part 3: Guidance on performing an assessment x Part 4: Guidance on use for process improvement and process capability determination x Part 5: An exemplar Process Assessment Model x Part 6: An exemplar system life cycle process assessment model x Part 7: Assessment of organizational maturity In Teil 2 werden Eigenschaften definiert, die an ein Prozess Assessment Modell (PAM) zur Bewertung von Softwareentwicklungsprozessen gestellt werden. Diese Anforderungen werden in Teil 5 der Norm „An exemplar Process Assessment Model“ in einem exemplarischen Prozess Assessment Modell ausgearbeitet. Das PAM bildet im Assessment die Grundlage zur Prozessbewertung; hier werden alle Anforderungen beschrieben, die später im Prozess bewertet werden. Der Teil 5 der ISO/IEC 15504 ist jedoch nur ein mögliches PAM. Mit der ISO/IEC 15504 wird vielmehr ein Framework

2.2 CMMI und ISO/IEC 15504 als Modelle zur Bewertung der Prozessreife

29

vorgegeben, mit dem sich verschiedene PAMs definieren lassen (z.B. das PAM für den Systemlebenszyklus in Teil 6). Da nur die Teile 2 und 5 die für Softwareentwicklungsprojekte maßgeblichen Anforderungen definieren, werden die anderen Teile in dieser Arbeit nicht weiter betrachtet. Prozess Referenzmodell

Mess-Framework

Prozess Assessment Modell

Eingaben

Assessment Prozess

Ausgaben

Rollen und Verantwortlichkeiten

Abbildung 2-4:

Nutzung eines Prozess-Assessment-Modells im Assessment [Hörmann et al. 2006]

In Abbildung 2-4 wird die Durchführung eines Assessments (mit dem Assessment Prozess) gezeigt. Das Assessment wird durch einen Assessor (Rollen und Verantwortlichkeiten in Abbildung 2-4) geleitet, der die Umsetzung des Entwicklungsprozesses im Unternehmen bewertet. Rahmenbedingungen und das Ziel des Assessments, die Zertifizierung bzw. Identifizierung von Verbesserungsmöglichkeiten bilden die Eingaben dieses Prozesses. Ausgaben bzw. Ergebnis des Assessments sind unter Anderem das gemessene Fähigkeitsprofil und eine Empfehlung des Assessors über mögliche Prozessverbesserungsmaßnahmen. Das Prozess Assessment wird auf Basis des Prozess-Assessment-Modells (PAM) durchgeführt, welches den Leitfaden und auch das Anforderungsprofil des Assessments bildet. Das PAM wird aus zwei Teilen gebildet: dem Prozess Referenzmodell und dem Mess-Framework. Durch einen Austausch des Prozess Referenzmodells können verschiedene PAM-Varianten für die Anpassung an bestimmte Branchen gebildet werden. Eine solche Variante ist das im Teil 5 der ISO/IEC 15504 ausgearbeitete Standard-PAM; andere PAM-Varianten sind „SPICE for SPACE“ oder „AUTOMOTIVE SPICE™“ für den Einsatz in der Automobilindustrie [Hörmann et al. 2006]. Das im Teil 5 der ISO/IEC 15504 ausgearbeitete PAM basiert auf dem Standard ISO/IEC 12207 „Systems and software engineering –

30

2 QM-Standards und Vorgehensmodelle

Software life cycle processes“, der ein Lebenszyklusmodell für die Softwareentwicklung vorgibt. Durch diese Möglichkeit, dem Austausch des Prozessreferenzmodells, unterscheidet sich die ISO/IEC 15504 vom CMMI und es ermöglicht den domänenübergreifenden Einsatz. Durch die Kombination von Prozessreferenzmodell (Prozessdimension) und MessFramework (Reifegraddimension) ergeben sich die zwei Dimensionen der ISO/ IEC 15504. Dieser Aufbau ist in Abbildung 2-5 dargestellt. Beide Dimensionen (Prozessdimension und Reifegraddimension) sind die zentralen Einheiten des Standards. Um eine bestimmte Reifegradstufe in einem Prozess zu erreichen, müssen sowohl die Anforderungen der Prozessdimension als auch die Anforderungen der jeweiligen Stufe in der Reifegraddimension erfüllt sein. Insofern unterscheidet sich die ISO/IEC 15504 vom CMMI, da hier keine eigenständigen Prozessgebiete vorhanden sind, sondern die beiden Dimensionen nahezu unabhängig voneinander sind. Prozessassessmentmodell (PAM)

Prozessdimension

Reifegraddimension

Primäre Lebenszyklusprozesse

Reifegradstufe

Prozessgruppe

Prozessattibut

Prozess

Prozessattribut Indikatoren

Basispraktik

Abbildung 2-5:

Arbeitsprodukt

Generische Praktik

Generisches Arbeitsprodukt Generische Ressource

Struktur der ISO/IEC 15504

Die Prozessdimension ist aufgeteilt in Primäre Lebenszyklusprozesse (Einkauf, Beschaffung, Engineering, …), Organisatorische Lebenszyklusprozesse (Management, Prozessverbesserung, …) und Unterstützende Lebenszyklusprozesse (Prozessunterstützung). Diese sind erneut in Prozessgruppen unterteilt. Jede Prozessgruppe setzt sich aus mehreren Prozessen zusammen; so sind in der Engineering Prozess-

2.2 CMMI und ISO/IEC 15504 als Modelle zur Bewertung der Prozessreife

31

gruppe die Prozesse Anforderungserhebung, Anforderungsanalyse, Architekturdesign etc. enthalten. Um in einem Assessment objektiv nachprüfen zu können, ob und wie ein Prozess umgesetzt wird, enthält die ISO/IEC 15504 Basispraktiken (Base Practices) und typische Arbeitsergebnisse (Work Products), die durch den Assessor als Indikatoren für die Umsetzung des Standards genutzt werden. Der Prozess Anforderungserhebung enthält unter anderem die Basispraktiken „Hole Kundenanforderungen und -wünsche ein“ oder „Verstehe Kundenanforderungen“; typische Arbeitsergebnisse sind beispielsweise „Kundenanforderungen“. Die Prozessdimension kann im CMMI mit den dort enthaltenen spezifischen Zielen verglichen werden. Die Reifegraddimension besteht aus fünf verschiedenen Reifegradstufen. Zu jeder Reifegradstufe sind Prozessattribute vorhanden, die die Umsetzung (Institutionalisierung) des Prozesses im Unternehmen beschreiben; die Reifegradstufe 2 enthält die Prozessattribute „Management der Prozessdurchführung“ und „Management der Arbeitsprodukte“. Zu jedem Attribut werden Indikatoren angegeben, die im Assessment durch den Assessor überprüft werden. Dies sind: Generische Praktiken (Generic Practices), Generische Ressourcen (Generic Resources) und Generische Arbeitsprodukte (Generic Work Products). Generische Praktiken des Prozessattributs „Management der Prozessdurchführung“ sind beispielsweise „Ermittle die Ziele der Prozessdurchführung“ oder „Plane und überwache die Prozessausführung hinsichtlich der Erfüllung der ermittelten Ziele“. Die Reifegraddimension der ISO/IEC 15504 kann mit den Generischen Zielen des CMMI gleichgesetzt werden. Wie in der kontinuierlichen Darstellung des CMMI wird auch in der ISO/IEC 15504 für jedes Prozessgebiet separat die Fähigkeit (Reifegrad) gemessen. Daraus ergibt sich dann ein Fertigkeitsprofil des Unternehmens, das anzeigt, wie gut ein bestimmter Prozess in einem Projekt durchgeführt wurde. Die Reifegrade der ISO/IEC 15504 sind ähnlich aufgebaut wie die des CMMI und in die folgenden Stufen unterteilt: x Level4 0: Unvollständig (Incomplete) Der Prozess ist nicht implementiert, oder er kann seinen Zweck nicht erfüllen. Auf dieser Ebene gibt es keinen oder nur wenig Hinweise auf eine systematische Erfüllung des Prozesszwecks.

4

In der Literatur wird als Übersetzung des englischen Begriffs „Level“ für die Reifegrade auch der Begriff „Stufe“ genutzt. Um diesen Kontext beizubehalten, wird in dieser Arbeit der englische Begriff „Level“ genutzt, um auf die Reifegrade der ISO/IEC 15504 und des CMMI Bezug zu nehmen.

32

2 QM-Standards und Vorgehensmodelle

x Level 1: Durchgeführt (Performed) Der implementierte Prozess erfüllt seinen Zweck. x Level 2: Gemanagt (Managed) Der zuvor beschriebene durchgeführte Prozess wird zielgerichtet (gemanagt) umgesetzt (geplant, überwacht und gesteuert), und seine Arbeitsergebnisse sind in angemessener Weise vorhanden, werden überwacht und gepflegt. x Level 3: Etabliert (Established) Der zuvor beschriebene gemanagte Prozess wird nun auf Basis eines definierten Prozesses implementiert, der in der Lage ist die Prozessergebnisse zu erfüllen. x Level 4: Vorhersagbar (Predictable) Der zuvor beschriebene etablierte Prozess wird nun innerhalb definierter Grenzen ausgeführt um die Prozessergebnisse zu erzielen. x Level 5: Optimierend (Optimizing) Der zuvor beschriebene vorhersagbare Prozess wird ständig verbessert um die aktuell relevanten und zukünftigen Geschäftsziele zu erreichen. Die Reifegradstufen der ISO/IEC 15504 sind inhaltlich vergleichbar mit den Fähigkeitsstufen des CMMI in der kontinuierlichen Darstellung. Auch der Aufbau der Modelle Prozessdimension und Reifegraddimension in der ISO/IEC 15504 (Abbildung 2-5) sowie spezifische bzw. generische Ziele im CMMI (Abbildung 2-3) sind vergleichbar. Damit eignen sich beide Standards zur Rekonstruktion eines gemeinsamen QMAnforderungsmodells.

3

Rekonstruktion des abstrakten QM-Modells

QM-Standards spielen eine wichtige Rolle bei der Beurteilung und Verbesserung von Entwicklungsprozessen. Allerdings existiert eine Vielzahl an Normen mit sich ergänzenden bzw. konkurrierenden Vorgaben. Da in dieser Arbeit kein spezifisches, auf einen bestimmten QM-Standard (z.B. ISO/IEC 15504 oder dem CMMI) abgestimmtes Vorgehen entwickelt werden soll, wird der Ansatz verfolgt, ein QM-System ausgehend von einem abstrakten Anforderungsprofil zu konzipieren. Dazu wird in diesem Kapitel aus den beiden reifegradorientierten QM-Normen ISO/IEC 15504 und CMMI ein allgemeineres QM-Modell, das abstrakte QM-Modell (aQM2) rekonstruiert. Dieses Modell ist abstrakt, da es nicht für eine Umsetzung in Unternehmen konzipiert ist. Allerdings eröffnet diese Eigenschaft gleichzeitig die Möglichkeit im ProcessNavigator die Kernanforderungen beider QM-Standards abzubilden. Ziel der Entwicklung des aQM2 ist sowohl die Erstellung eines unabhängigen QMAnforderungsprofils als auch eine Schaffung einer konzeptionellen Ausgangsbasis für die spätere Umsetzung in der Prozessausführungsumgebung. Aus diesem Grund werden zur Strukturierung des aQM2-Ansatzes Meta-Modelle [Clark et al. 2008; Henderson-Sellers et Gonzalez-Perez 2008] und die dort vorhandene Sprachebenenhierarchie (Meta-Ebenen) eingesetzt. Meta-Modelle legen die wesentlichen technischen Strukturelemente eines Prozesses fest, vom Entwurf der Modellierungssprache, über die Modellierung des Prozesstyps bis hin zum ausführbaren Prozesstyp [Jablonski et Volz 2008; Jablonski et al. 2008; Jablonski et al. 2009a; Jablonski et al. 2009c]. Sie bilden damit eine ideale Grundlage für die Einordnung der Anforderungen des aQM2 hinsichtlich ihrer späteren Umsetzung in einem prozessbasierten QMSystem. Die Basis für die Entwicklung des aQM2 aus Sicht des Qualitätsmanagements bilden die beiden etablierten QM-Normen ISO/IEC 15504 und CMMI. Beide Standards wurden hinsichtlich ihrer Anforderungen in der Literatur gut untersucht und sind entsprechend dokumentiert [Gresse von Wangenheim et Thiry 2005; Hörmann et al. 2006; Rout et Tuffley 2007]. Des Weiteren besitzen sie aufgrund der Unterstützung durch die Industrie (z.B. die Automobilbranche [Automotive SPICE© 2009]) oder das amerikanische Verteidigungsministerium (CMMI) einen hohen Verbreitungsgrad und Relevanz. Beide bauen außerdem auf vergleichbaren Konzepten auf, der Trennung in eine Prozessdimension und eine Fähigkeitsdimension, und eignen sich damit als inhaltliche Grundlage für das aQM2.

34

3 Rekonstruktion des abstrakten QM-Modells

Nach einer Einführung von Meta-Modellen im Abschnitt 3.1 werden im Abschnitt 3.2 die in QM-Normen enthaltenen Anforderungen (ISO/IEC 15504 und CMMI) detailliert betrachtet. Dabei werden die Vorgaben der beiden Standards detailliert miteinander verglichen und ihre Anforderungen den Meta-Ebenen zugeordnet. Für alle Ebenen des aQM2 werden in den Abschnitten 3.2.2 bis 3.2.6 die zentralen Anforderungen der Standards identifiziert, als Ziele herausgezogen und den Ebenen des Meta-Modells zugeordnet. 3.1

Exkurs: Meta-Modelle in der Prozessmodellierung

Im aQM2 werden Meta-Modelle zur Strukturierung der Anforderungen genutzt. Dieser Abschnitt gibt einen kurzen Überblick, wie diese zur Prozessmodellierung genutzt werden. In [Seidewitz 2003] und [Bézivin 2005] wird die Bedeutung von Modellen und MetaModellen für die Informatik beschrieben. Ein Modell kann demnach zwei Funktionen erfüllen. Zum einen können damit Aussagen über ein bestimmtes System getroffen werden: ein Modell ist dann korrekt, wenn alle seine Aussagen über das System wahr sind; ein Modell ist dabei immer auch eine Abstraktion der Realität, da es niemals alle Aspekte der Realität abbilden kann. Zum anderen kann ein Modell auch als Spezifikation für ein System genutzt werden: in diesem Fall ist ein System dann im Hinblick auf seine Spezifikation valide, wenn keine Aussagen des Modells im Bezug auf das System falsch sind. Meta-Modelle sind Modelle von Modellen. Allerdings sollen mit Meta-Modellen keine Aussagen über Modelle getroffen werden; vielmehr sollen sie eine Spezifikation für Modelle vorgegeben. Somit bieten Meta-Modelle eine Möglichkeit um Modelle, Methoden und Vorgehensweisen an einen bestimmten Anwendungsfall anzupassen. In [Henderson-Sellers et Gonzalez-Perez 2008] werden sie wie folgt definiert: “A meta-model is a domain-specific language oriented towards the representation of software development methodologies and endeavors” Entsprechend der Funktion eines Meta-Modells zur Spezifikation von Modellen können Meta-Meta-Modelle genutzt werden, um die Eigenschaften von MetaModellen festzulegen. Diese Bildung neuer Meta-Ebenen kann so oft wiederholt werden, bis ein Modell selbstbeschreibend ist. Das heißt, bis die Elemente einer Ebene mit den auf dieser Ebene vorhandenen Modellierungselementen beschrieben werden können; die Bildung einer weiteren Ebene ist dann nicht mehr sinnvoll. Zur Spezifikation von Prozessmodellierungssprachen wird in [Jablonski et Volz 2008] und [Jablonski et al. 2009c] eine Meta-Modell-Hierarchie entworfen, die aus den vier

3.1 Exkurs: Meta-Modelle in der Prozessmodellierung

35

Ebenen M0, M1, M2 und M3 besteht. Der Aufbau dieses Modells ist in Abbildung 3-1 dargestellt. x M0 – Prozessinstanzen Prozessinstanzen werden durch die Instanziierung eines Prozesstyps gebildet und stellen jene Elemente dar, die im Unternehmen ausgeführt werden. Dabei ist es unerheblich, ob diese direkt in einem Informationssystem ablaufen oder nicht. Die Elemente der Ebene M0 können selbst nicht weiter instanziiert werden und bilden damit das Ende der Hierarchie. x M1 – Prozesstyp Ein Prozesstyp ist auf Ebene M1 eingeordnet und spezifiziert die später im konkreten Projekt ausgeführten Arbeitsschritte. Er bildet die Grundlage für die ausgeführten Prozessinstanzen und wird in Unternehmen durch die Prozessverantwortlichen erstellt. Die Menge aller Prozesstypen bildet die TypBibliothek. Sind die vorhandenen Prozesstypen nicht ausreichend, kann die Bibliothek um weitere Typen ergänzt werden. x M2 – Prozess-Meta-Modell Das Prozess-Meta-Modell definiert die zur Modellierung genutzte Modellierungssprache. Die Modellierungssprache wird durch einen Domänenexperten für eine Vielzahl an gleichartigen Anwendungsfällen erstellt. Diese Sprache zerfällt in einen abstrakten und einen domänenspezifischen Anteil. Während im abstrakten Teil jene Sprachelemente spezifiziert werden, die alle Modellierungssprachen gemeinsam nutzen, können im domänenspezifischen Sprachanteil die Anpassungen an die Anwendungsdomäne vorgenommen werden. x M3 – Prozess-Meta-Meta-Modell Im Prozess-Meta-Meta-Modell sind die zur Definition der Modellierungssprache genutzten Elemente enthalten. In diesem Zusammenhang wird auch vom Modellierungsprinzip gesprochen. Das Prozess-Meta-Meta-Modell muss nur äußerst selten angepasst werden. Mit der hier vorgestellten Meta-Modell-Hierarchie ist ein sehr ausdrucksstarkes Werkzeug zur Modellierung und Spezifikation von Prozessen vorhanden. Durch die verschiedenen Sprachebenenwechsel können Modelle spezifisch an die im Unternehmen vorhandenen Anforderungen angepasst werden. Sie geben außerdem einen anwendungsneutralen Rahmen vor, mit dem andere Anforderungen verglichen werden können.

36

3 Rekonstruktion des abstrakten QM-Modells

M3

Abstraktes Prozess-Meta-Meta-Modell

M2

Abstraktes ProzessMeta-Modell

Domänenspezifisches Prozess-Meta-Modell

M1

Typ-Bibliothek

Prozessmodelle

Prozess-Instanzen

M0

(momentan ausgeführte Prozesse)

Abbildung 3-1:

Meta-Modell-Hierarchie für die Prozessmodellierung (adaptiert aus [Jablonski et al. 2009c])

Zusammenfassend kann festgestellt werden, dass Meta-Modelle genutzt werden können, um Anwendungen und Modellierungssprachen flexibel zu gestalten und um zukünftige Anforderungen einfach umsetzen zu können. Sie gehen dabei über das klassische Mittel der Abstraktion hinaus und erlaubt es zusätzliche Prinzipien in eine Sprache einzubauen [Jablonski et Volz 2008]. In dieser Arbeit werden Meta-Modelle zur Strukturierung der Anforderungen des aQM2 genutzt und um eine Modellierungssprache für Prozess- und Projekttypen zu spezifizieren. So wird in Abschnitt 7.1 ein Prozess-Meta-Modell vorgestellt, welches die Grundlage für die genutzte Prozessmodellierungssprache bildet. Diese Sprache umfasst alle notwendigen Mittel und Elemente zur Modellierung von Prozesstypen und ist zu diesem Zweck ausreichend. In Kapitel 8 wird jedoch ein neues Modellierungselement eingeführt, der Projektbaustein, welcher zur Modellierung von Projekttypen, einer Erweiterung von Prozesstypen, genutzt wird. Durch die Nutzung eines Meta-Modells wird in der Modellierungssprache die notwendige Flexibilität erreicht, um das neue Modellierungselement einfach einzubinden. Im konkreten Fall wird auf der Ebene M2 ein neues Element eingefügt, welches auf der Ebene M1 zur Modellierung der Typen genutzt werden kann. 3.2

Strukturelle Rekonstruktion eines abstrakten QM-Modells

Die beiden QM-Standards ISO/IEC 15504 und CMMI sind in verschiedene Ebenen (Reifegradstufen) eingeteilt, die eine Aussage darüber treffen, welche Fähigkeitsstufe ein Unternehmen bei der Bearbeitung von Projekten erreicht hat. Ausgehend von der strukturellen Ähnlichkeit der beiden Modelle wird in diesem Abschnitt das abstrakte

3.2 Strukturelle Rekonstruktion eines abstrakten QM-Modells

37

QM-Referenzmodell aQM2 aus beiden Modellen entwickelt. Das aQM2 wird in Teil II dieser Arbeit als QM-Anforderungsrahmen für die Entwicklung des ProcessNavigators genutzt. Somit bildet das aQM2 den Rahmen dieser Arbeit, um die vorgestellten Lösungen unabhängig von konkreten QM-Referenzmodellen zu diskutieren und zu entwickeln. Es wird damit vermieden, den ProcessNavigator nur für einen der beiden Standards zu entwickeln. Vielmehr werden dort die Kernanforderungen beider Standards umgesetzt. Ziel der Definition des aQM2 ist es, die Kernforderungen der Standards ISO/IEC 15504 und CMMI in ein gemeinsames stabiles Anforderungsprofil abzubilden und die dort adressierten Themengebiete jeweils in mindestens einem Ziel zu erfassen. Das aQM2 ist wie die beiden QM-Standards in Ebenen (Reifegradstufen) unterteilt. Zu jeder Ebene im aQM2 werden jeweils die Ziele angegeben, die dort umgesetzt werden müssen. Zur Identifikation der Ziele wird bei den QM-Standards die Fähigkeitsdimension (ISO/IEC 15504 Generic Practices und CMMI Generic Goals) analysiert und ihre Kernforderungen werden isoliert. Die beiden in [Gresse von Wangenheim et Thiry 2005; Rout et Tuffley 2007] veröffentlichen Vergleiche der Standards werden genutzt, um Gemeinsamkeiten und Unterschiede zu identifizieren. Da die beiden Standards ISO/IEC 15504 und CMMI in regelmäßigen Abständen überarbeitet und an neue Erkenntnisse des Software-Engineering angepasst werden, ist eine vollständige Abdeckung ihrer Anforderungen im aQM2 nicht erforderlich. Zusätzlich zur Abstraktion vom konkreten QM-Standard wird eine Zuordnung des aQM2 zu der in Abschnitt 3.1 beschriebenen Meta-Modell-Hierarchie vorgestellt. Mit dieser ist ein vom Qualitätsmanagement unabhängiger Vergleichsrahmen gegeben, an dem sich die Anforderungen der QM-Referenzmodelle spiegeln lassen. Somit kann untersucht und auch nachvollzogen werden, welche Ebenen durch die QM-Anforderungen adressiert werden und wie diese durch IT-Systeme unterstützt werden können. So muss ein Teil der Anforderungen während der Prozess- und Projektplanung umgesetzt werden, während andere Anforderungen nur während der Ausführung erfüllt werden können. Die Meta-Modell-Hierarchie bietet hierfür einen idealen Strukturierungsrahmen. Sowohl in der ISO/IEC 15504 als auch im CMMI ist die begriffliche Trennung zwischen Prozess und Projekt nicht scharf. So bezeichnet in der ISO/IEC 15504 und im CMMI auf Ebene 3 der „defined process“ [CMMI Product Team 2006; ISO/IEC 15504-5:2006] die auf ein konkretes Vorhaben angepasste Abfolge von Arbeitspaketen nach einem Prozess-Tailoring. Der „defined process“ beschreibt also die Projektaktivitäten. Um in den weiteren Kapiteln dieser Arbeit Mehrdeutigkeiten im Bezug auf die benutzten Begriffe zu vermeiden, werden diese wie folgt definiert:

38

3 Rekonstruktion des abstrakten QM-Modells

x Prozess Der Prozesstyp, das Prozessmodell oder kurz Prozess bezeichnet die in der Planungsphase beschriebene Abfolge von Arbeitspaketen. Dieser ist nicht an ein konkretes Vorhaben angepasst, sondern kann in einer Vielzahl an vergleichbaren Vorhaben eingesetzt werden. Durch den Prozesstyp wird im Unternehmen auch das Standardvorgehen zur Bearbeitung eines Vorgangs festgelegt. Somit ist dies auch der Standard-, Soll- oder Referenzprozess. x Projekt Nach DIN 69901 ist der Begriff Projekt definiert als ein Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist. Die im Projekt ausgeführte Folge von Arbeitspaketen wird als Projekttyp bzw. Projektmodell bezeichnet (dieser entspricht damit dem „defined process“). Der Projektplan fasst verschieden Projekttypen im Kontext eines Projekts zusammen und ergänzt diese um weitere Informationen, die zur Durchführung des Projekts notwendig sind. Die Umwandlung des Prozesstyps in einen Projekttyp wird durch ein Projekttailoring (oder Tailoring) erreicht. Der Begriff Tailoring wird in dieser Arbeit wie folgt genutzt: „Das Tailoring eines Prozesses an ein Projekt bezeichnet die Aktivitäten, die nötig sind, um einen Prozess an die konkreten Gegebenheiten eines Projekts anzupassen“ In dieser Arbeit werden außerdem die Begriffe Aufgabe, Arbeitspaket und Projektschritt synonym genutzt, um die zur Durchführung eines Projekts zu bearbeitenden Schritte zu beschreiben. Wenn auf die Anforderungen der Normen direkt verwiesen oder wenn diese zitiert werden, werden jedoch weiterhin die dort genutzten Begriffe unabhängig von der obigen Definition genutzt. In der ISO/IEC 15504 wird die Umsetzung der Fähigkeitsdimension über Prozessattribute gemessen. Diese werden durch Indikatoren (Generische Praktiken, Generische Ressourcen und Generische Arbeitsprodukte) weiter detailliert, welche Assessoren in Assessments wichtige Anhaltspunkte für die Bewertung der Prozesse bieten. Maßgeblich für das Erreichen einer Reifegradstufe ist jedoch die Umsetzung der Ziele der Prozessattribute (attribute achievements). Aus diesem Grund werden die Indikatoren (Generische Praktiken, Generische Ressourcen und Generische Arbeitsprodukte) nicht mit in die Rekonstruktion des aQM2 einbezogen und das Anforderungsmodell wird nur auf Basis der Ziele der Prozessattribute (ISO/IEC 15504) und Generischen Ziele (CMMI) ausgearbeitet. Die Reifegradstufen im aQM2 werden als Reifegradebenen (RG1 bis RG5) bezeichnet.

3.2 Strukturelle Rekonstruktion eines abstrakten QM-Modells

3.2.1

39

Das aQM2 im Überblick

Bevor die einzelnen Ebenen des aQM2 in den nächsten Abschnitten im Detail betrachtet werden, soll an dieser Stelle ein Überblick über das Gesamtmodell gegeben werden. Die Nutzung eines Prozesses als Grundlage für die Entwicklungsprojekte kann grundsätzlich in zwei Ebenen unterteilt werden: 1. Planungsebene: Hier werden die Grundlagen für die spätere Prozessausführung gelegt. Ergebnis der Aktivitäten der Planungsebene ist ein fertiger Prozesstyp im Anschluss an die Prozessplanung bzw. ein Projekttyp als Ergebnis der Projektplanung. Beide werden in der Modellierungssprache dargestellt, die im Sprachdesign entworfen wurde. 2. Ausführungsebene: Hier wird das vorher geplante Projekt umgesetzt. Ergebnis der Ausführungsebene ist zum einen das fertige (Software-)Produkt, zum anderen aber auch Informationen und Daten, die während der Ausführung gesammelt werden. Diese können genutzt werden, um Verbesserungsmöglichkeiten an Modellierungssprache, Prozess- und Projekttyp zu identifizieren. Diese beiden Ebenen, sowie deren Zuordnung zur Meta-Modell-Hierarchie wird in Abbildung 3-2 gezeigt. In der Abbildung wird auch deutlich, dass Planungs- und Ausführungsebene nicht unabhängig nebeneinander stehen, sondern einen Zyklus bilden. Dieser Zyklus ermöglicht es, aus abgeschlossenen Projekten zu lernen und somit einen kontinuierlichen Verbesserungsvorgang im Unternehmen anzustoßen.

Ausführungsebene M0: Messdatenbank

Messdaten

Verbesserungen

M2: Sprachdesign

M1: Prozessplanung

M1: Projektplanung

M0: Projektausführung Instanziierung

Abbildung 3-2:

Meta-Ebenen in der Prozess- und Projektdurchführung

Projektsteuerung

Planungsebene

40

3 Rekonstruktion des abstrakten QM-Modells

Mit der Trennung in Planungs- und Ausführungsebene wird auch ein Vorgriff auf die spätere Systemumsetzung vorgenommen; so wird im Konzept zwischen einem Planungssystem und einem Ausführungssystem unterschieden. Kennzeichnend für Systeme der Planungsebene ist, dass sie die zur Ausführung des Prozesstyps benötigten Strukturen definieren und in einem Modell bereitstellen. In dieser Ebene werden die maßgeblichen Eigenschaften der Prozesse und Projekte festgelegt. Die Systeme der Ausführungsebene setzen den Prozess- bzw. Projekttyp um und unterstützen die Anwender bei der Produkterstellung. Die Erstellung eines Prozesstyps als Basis für die Projektausführung beginnt mit der Auswahl bzw. dem Design einer Prozessmodellierungssprache. Dieser Arbeitsschritt, das Sprachdesign, kann der Meta-Ebene M2 zugeordnet werden. Hier werden die Grundlagen für den auf Meta-Ebene M1 definierten Prozesstyp spezifiziert. Durch die Aufnahme bzw. das Löschen von Elementen (Konzepten und Beziehungen) auf M2 können die Modellelemente der Modellierungssprache verändert werden. Die Prozessplanung auf Meta-Ebene M1 umfasst die Modellierung und Spezifikation des Prozesstyps. Hier wird festgelegt, wie ein Vorgang im Allgemeinen durchzuführen ist. Der Umfang und die Detailliertheit des Prozesstyps richten sich nach seinem Zweck. Für die im Rahmen dieser Arbeit betrachteten Entwicklungsprozesse legt der Prozesstyp ein idealisiertes Vorgehen fest, welches die Grundlage für Entwicklungsprojekte bildet. Die Menge aller erstellten Prozesstypen bildet die Typbibliothek. Die Definition des Prozesstyps wird in dieser Arbeit ausführlich in Kapitel 7 beschrieben. Wie die Prozessplanung ist auch die Projektplanung auf Meta-Ebene M1 angesiedelt. Ziel der Projektplanung ist es, den idealisierten Prozesstyp an die Gegebenheiten eines konkreten Entwicklungsvorhabens anzupassen. Der Rahmen eines solchen Vorhabens wird durch das Projekt festgelegt. Zentrale Elemente bei der Anpassung an die Vorgaben des Projekts sind die Projektorganisation sowie das Projektbudget und der Terminplan. In Kapitel 8 wird detailliert erläutert, wie aus einem Prozesstyp ein Projekttyp abgeleitet werden kann. Diese Anpassung (das Projekttailoring) stellt eine wichtige Vorbereitung für die Ausführung des Projekts dar; das Ergebnis des Tailorings ist ein Projektplan. Bei der Umsetzung des Projektplans finden ein Wechsel von der Planungsebene in die Ausführungsebene und entsprechend auch ein Wechsel von der Meta-Ebene M1 in die Meta-Ebene M0 statt. Hier geht es zum einen darum, die im Projektplan definierten Arbeitsschritte umzusetzen und das Projekt auszuführen; zum anderen werden während der Projektausführung Daten über die Ausführung gesammelt. Diese Daten werden in der Messdatenbank abgelegt und unterstützen den Projektleiter bei der Steuerung des Projekts. Die gesammelten Projektdaten können über die Projektsteu-

3.2 Strukturelle Rekonstruktion eines abstrakten QM-Modells

41

erung hinaus auch genutzt werden, um die verschiedenen Elemente der Planungsebene im Sinne eines Regelkreises zu optimieren.

Planungsebene

Ausführungsebene

RG5

Messdaten

M2: Sprachdesign

RG3 M1: Prozessplanung

RG2

M1: Projektplanung

RG1

Instanz.

RG4

M0: Messdatenbank Projektsteuerung

Verbesserungen

M0: Projektausführung

M0: Umsetzung der Praktiken

RG0 Abbildung 3-3:

Das aQM2 im Überblick

Abbildung 3-3 greift den in Abbildung 3-2 dargestellten Zyklus auf und ergänzt ihn um Reifegradebenen (RG) des aQM2. Diese werden entsprechend den Reifegradebenen der ISO/IEC 15504 und des CMMI festgelegt. In der Darstellung wird somit das aQM2 im Gesamtüberblick gezeigt. Die einzelnen Reifegradebenen werden in den folgenden Abschnitten dieses Kapitels sukzessive entwickelt und detailliert vorgestellt. Die verschiedenen Reifegradebenen des Modells bauen jeweils aufeinander auf und nutzen die Ergebnisse der darunterliegenden Ebene. Obwohl die ISO/IEC 15504 als auch das CMMI einen Reifegrad 0 aufweisen, wird in der folgenden Betrachtung auf diese Ebene nicht weiter eingegangen. Beide Standards stellen keinerlei Anforderungen an ihr Erreichen; jedes Projekt ist somit automatisch auf Reifegrad 0 und eine Unterstützung durch ein QM-System ist nicht erforderlich bzw. hier auch nicht gegeben. 3.2.2

RG1 – Ausgeführter Prozess

Der Level 1 bildet die erste Stufe im Verbesserungsprozess nach ISO/IEC 15504 und CMMI. Ziel beider QM-Referenzmodelle ist es jeweils, die in der Prozessdimension

42

3 Rekonstruktion des abstrakten QM-Modells

geforderten Arbeitsschritte (also Base Practices oder Specific Goals) umzusetzen und deren Arbeitsergebnisse zu erstellen. Tabelle 3-1 stellt die Anforderungen der ISO/IEC 15504 und des CMMI gegenüber. Beide Standards zielen darauf ab, für den jeweiligen Prozess (bzw. Prozessgebiet) die geforderten Ergebnisse zu erreichen. Bei der ISO/IEC 15504 müssen dazu die Base Practices implementiert werden; beim CMMI die Spezifischen Ziele (Specific Goals) und die Spezifischen Praktiken (Specific Practices). Für jeden Prozess werden Arbeitsergebnisse definiert, anhand derer der Assessor später überprüfen kann, ob und wie weit ein geforderter Arbeitsschritt in der Praxis umgesetzt wird. Anforderungen auf Level 1

PA 1.1: Process performance attribute

ISO/IEC 15504 a) the process achieves its defined outcomes

CMMI GG 1: Achieve Specific Goals

Tabelle 3-1:

GP 1.1: Perform Specific Practices

In der ISO/IEC 15504 ist auf Level 1 nur das Prozessattribut PA 1.1 vorgesehen. Dieses „ist ein Maß dafür, inwieweit der Zweck des Prozesses erfüllt wird“ [Hörmann et al. 2006]. Konkret wird anhand der erstellten Prozessergebnisse (Work Products) gemessen, in wie weit das Ziel und die Intention des Prozesses umgesetzt wurde. Dies wird in der Norm in der Generischen Praktik 1.1.1 gefordert („GP 1.1.1 Achieve the process outcomes“). Im CMMI ist ein Fähigkeitsgrad erreicht, wenn das entsprechende Generische Ziel und die zugeordneten Generischen Praktiken umgesetzt werden. Im Bezug auf das Level 1 ist die einzige Generische Praktik, die umgesetzt werden muss, die Erfüllung der Spezifischen Ziele der jeweiligen Prozessgebiete. Wie in der ISO/IEC 15504 wird auch hier die Erstellung der Arbeitsergebnisse gefordert. In einem abstrakten QM-Referenzmodell können die beiden Referenzmodelle ISO/IEC 15504 und CMMI einfach zusammengefasst werden. Beide Modelle fordern, dass die vorhandenen Arbeitsschritte umgesetzt werden und dies durch entsprechende Arbeitsergebnisse belegt werden. Während in der ISO/IEC 15504 – Teil 5 (mit der ISO/IEC 12207) und im CMMI eine bestimmte Menge an Prozessgebieten beschrieben ist, die umgesetzt werden müssen, gibt das aQM2 nur die allgemeinen

3.2 Strukturelle Rekonstruktion eines abstrakten QM-Modells

43

Rahmen und damit die Ziele vor. Diese können dann durch einen entsprechenden Standard mit Prozessgebieten ergänzt werden. Tabelle 3-2 fasst die beiden Ziele zusammen. Tabelle 3-2:

Abstraktes Referenzmodell auf RG 1

RG 1 Ausführungsebene Ziel 1.1: Umsetzen der Prozessschritte

Die im Referenzmodell aufgeführten Schritte müssen ihrem Zweck nach im Unternehmen vorhanden und im Projekt aktiv umgesetzt werden.

Ziel 1.2: Die im Referenzmodell zu jedem Schritt angegeErstellen der geforderten ben Arbeitsschritte und Dokumente müssen in den Projekten erstellt werden. Arbeitsergebnisse

Die beiden Ziele werden im Meta-Modell auf M0 eingeordnet und in Abbildung 3-3 als „Umsetzung der Praktiken“ bezeichnet. Zwar kann eine vorherige Planung der Arbeitsschritte in einem Prozesstyp ihre Umsetzung sicherlich sinnvoll unterstützen, allerdings ist dies nicht zwingend erforderlich. Die Mitarbeiter müssen lediglich sicherstellen, dass die geforderten Prozessschritte umgesetzt werden. Gleiches gilt für ihre Zuordnung zur Ausführungsebene. Diese Ziele können auch ohne vorherige Planung erreicht werden und eine detaillierte Projektplanung ist auf dieser Reifegradebene noch nicht notwendig; diese wird erst auf RG2 erforderlich. 3.2.3

RG2 – Gesteuerter Prozess

Diese Ebene bildet die zweite Stufe im Verbesserungsprozess nach ISO/IEC 15504 und CMMI. Ziel dieser Stufe ist es, das Projekt zu managen. Dazu müssen sowohl die Projektaktivitäten quantitativ geplant und überwacht werden als auch deren Arbeitsergebnisse entsprechend verwaltet werden. In Tabelle 3-3 werden die Anforderungen, die von ISO/IEC 15504 bzw. CMMI gestellt werden, zusammengefasst. Ziel beider Ansätze ist es, ein Projekt durch Projektmanagementaktivitäten zu leiten und auf diese Weise auf Abweichungen vom definierten Projektplan reagieren zu können. Analog zum Projekt selbst müssen auch die im Projekt erstellten Daten gemanagt werden. Nach [Hörmann et al. 2006] müssen alle Prozesse des Unternehmens auf diese Weise gesteuert werden.

44

3 Rekonstruktion des abstrakten QM-Modells

Tabelle 3-3:

Anforderungen auf Level 2

CMMI GP 2.1: Establish an Organizational Policy

b) performance of the process is planned and monitored;

GP 2.2: Plan the Process

c) performance of the process is adjusted to meet plans;

GP 2.3: Provide Resources

d) responsibilities and authorities for performing the process are defined, assigned and communicated;

GP 2.4: Assign Responsibility

e) resources and information necessary for performing the process are identified, made available, allocated and used; f) interfaces between the involved parties are managed to ensure both effective communication and also clear assignment of responsibility.

GG 2: Institutionalize a Managed Process

a) objectives for the performance of the process are identified;

a) requirements for the work products of the process are defined; b) requirements for documentation and control of the work products are defined; c) work products are appropriately identified, documented, and controlled; d) work products are reviewed in accordance with planned arrangements and adjusted as necessary to meet requirements.

GG 2: Institutionalize a Managed Process

PA 2.2: Work product management attribute

PA 2.1: Performance management attribute

ISO/IEC 15504

GP 2.5: Train People

GP 2.6: Manage Configurations

GP 2.7: Identify and Involve Relevant Stakeholders GP 2.8: Monitor and Control the Process GP 2.9: Objectively Evaluate Adherence GP 2.10: Review Status with Higher Level

Ziel des Levels 2 in der ISO/IEC 15504 ist es einen vorher ausgeführten Prozess (also einen Prozess auf Level 1) zu planen und zu managen [ISO/IEC 15504-5:2006]. Um dies in einem Assessment bewerten zu können, werden zwei Prozessattribute eingeführt: PA 2.1 Performance management attribute (Management der Prozessausführung) und PA 2.2 Work product management attribute (Management der Arbeitsprodukte). Ziel des PA 2.1 ist es, grundlegende Projektmanagementaktivitäten bei der

3.2 Strukturelle Rekonstruktion eines abstrakten QM-Modells

45

Bearbeitung von Aufträgen zu beachten und im Unternehmen umzusetzen. So müssen beispielsweise die Ziele des Projekts definiert, die Durchführung des Projekts muss im Hinblick auf die Ziele überwacht und die nötigen Ressourcen müssen bereitgestellt werden. Auch das Management der Arbeitsergebnisse wird auf Level 2 vorgeschrieben. Anforderungen an die Arbeitsprodukte, ihre Dokumentation und ihre Lenkung müssen festgelegt werden. Außerdem sind planmäßige Reviews gefordert um sicherzustellen, dass die Arbeitsprodukte den Anforderungen genügen. Das CMMI verfolgt ähnliche Ziele wie die ISO/IEC 15504. In den Generic Practices zum Generischen Ziel 2 wird die Verankerung von Projektmanagementaktivitäten im Projekt gefordert. So ist die Planung, Überwachung und Steuerung von Projekten in Generischen Praktiken vorgesehen. Ebenso müssen Ressourcen bereitgestellt und Verantwortlichkeiten zugewiesen werden. Auch auf das Thema Arbeitsprodukte wird in der Praktik Konfigurationen managen eingegangen. Tabelle 3-4:

Abstraktes Referenzmodell auf RG 2

RG 2 Planungsebene Ziel 2.1: Planung des Projekts

Die Planung des Projekts ist die zentrale Aufgabe eines auf Ebene 2 geführten Prozesses. Dies umfasst u.a. die benötigten Arbeitsschritte, Aktivitäten sowie einen zeitlichen Ablaufplan.

Ziel 2.2: Definition von Zielen und Entscheidungsbefugnissen für die Prozessausführung

Für die Arbeitsschritte müssen quantitative Ziele sowie eine Strategie für die Planung und Umsetzung des Projektes entwickelt werden [ISO/IEC 15504-5:2006]. Auch sollen die generellen Erwartungen der Organisation an den Prozess bzw. das Projekt definiert werden [CMMI Product Team 2006]. Ebenso müssen die Entscheidungsbefugnisse im Prozess definiert werden.

Ziel 2.3: Allokation von Ressourcen

Die zur Umsetzung der geplanten Aktivitäten nötigen Ressourcen (sowohl Mitarbeiter als auch Infrastruktur) müssen definiert und festgelegt werden.

Ziel 2.4: Definition der Schnittstellen zwischen Parteien

Es muss sichergestellt werden, dass die für die Umsetzung der Aktivitäten verantwortlichen Ressourcen miteinander kommunizieren können. Dazu müssen Kommunikationskanäle definiert und Zuständigkeiten zugeordnet werden [ISO/IEC 15504-5:2006].

46

3 Rekonstruktion des abstrakten QM-Modells

RG 2 Ziel 2.5: Definition der Anforderungen an Arbeitsprodukte

Es müssen die Anforderungen an die im Projekt erstellten Arbeitsprodukte definiert werden. Hier sollen insbesondere die Anforderungen an Struktur, Qualität und Änderungsmanagement festgelegt werden [Hörmann et al. 2006].

Ausführungsebene Ziel 2.6: Überwachung und Steuerung des Projekts

Die im Projekt durchgeführten Aktivitäten und Arbeitsschritte müssen durch den Projektleiter ständig überwacht werden. Bei Abweichungen vom Plan muss dieser steuernd eingreifen und gegebenenfalls die Planung anpassen.

Ziel 2.7: Überwachung und Korrektur der Arbeitsprodukte

Die in den einzelnen Arbeitsschritten erstellten Dokumente müssen im Projekt verwaltet werden. Dazu müssen die relevanten Arbeitsergebnisse identifiziert und Zuständigkeiten festgelegt werden. Die Arbeitsergebnisse müssen außerdem gelenkt und Reviews unterworfen werden.

In [Rout et Tuffley 2007] werden die beiden QM-Standards hinsichtlich ihrer Kompatibilität und Übereinstimmungen miteinander verglichen. Nach einer Abbildung der Prozessattribute aus der ISO/IEC 15504 auf die entsprechenden Generischen Praktiken kommen die Autoren zu dem Ergebnis, dass große Übereinstimmungen zwischen den beiden Modellen auf Ebene 2 bestehen. In Tabelle 3-4 werden die Ziele des aQM2 auf Ebene 2 beschrieben. Die dort vorgestellten Ziele sollen sicherstellen, dass Projekte hinsichtlich ihrer Ziele und Aktivitäten geplant und während ihrer Durchführung durch einen Projektleiter überwacht und gesteuert werden. Weitere wichtige Aspekte sind die Planung der Kommunikationswege, um Probleme frühzeitig identifizieren zu können und die Verwaltung und das Management der im Projekt erstellten Arbeitsprodukte. Der RG2 des aQM2 ist im Meta-Modell der Ebene M1 und der Ebene M0 zugeordnet. In der Projektplanung wird die spätere Ausführung vorbereitet und in einem Modell abgelegt; ihre Aktivitäten können damit der Ebene M1 zugeordnet werden. Zur Prozessausführung wird der Plan instanziiert und ausgeführt; somit ist sie auf Ebene M0 lokalisiert.

3.2 Strukturelle Rekonstruktion eines abstrakten QM-Modells

47

Im Gegensatz zu RG1 (Ausgeführter Prozess) beinhaltet der RG2 sowohl eine Planungs- als auch eine Ausführungskomponente. Bei der Planung des Projekts müssen die grundsätzlichen Vorgaben und Strategien für die Projektdurchführung festgelegt werden.

Ausführungsebene

RG2

Planen und Festlegen

Abgleichen

M1: Projektplanung

M0: Projektausführung

Steuern und Anpassen

Planungsebene

Instanziierung/ Umsetzen

Abbildung 3-4:

Zuordnung des RG2 zum Meta-Modell

Die Projektplanung wird auf RG2 durch die Ziele 2.1 bis 2.5 adressiert. Die Ziele umfassen eine Planung des Projekts ausgehend von den strategischen Zielen des Unternehmens mit einer Definition der Erwartungen des Unternehmens an das Projekt sowie eine detaillierte Planung der Projektausführung selbst. Auch Entscheidungsbefugnisse, die Kommunikationswege innerhalb des Projektes und die Erwartungen an die Qualität der Arbeitsprodukte müssen im Vorfeld der Projektdurchführung festgelegt werden. Ebenso muss die spätere Verwaltung und Lenkung der Ergebnisse geplant und die nötigen Vorbereitungen getroffen werden. Die erarbeiteten Projektpläne müssen anschließend im Unternehmen umgesetzt werden. Dabei sind die vorher festgelegten Arbeitsschritte umzusetzen und die Arbeitsprodukte müssen von den vorgesehenen Mitarbeitern bearbeitet und erstellt werden. Während der Projektausführung müssen die gesammelten Informationen über die Ausführung (Ist-Daten) ständig mit den im Projektplan vorhandenen SollDaten abgeglichen werden und bei Abweichungen muss steuernd eingegriffen werden (Ziele 2.6-2.7). Dieser „kleine“ Regelkreis stellt keinen Widerspruch zu dem in Abbildung 3-3 dargestellten „größeren“ Regelkreis auf RG 4 dar; im Vergleich zu diesem „großen“ Regelkreis ist er weniger systematisch. Nach [Hörmann et al. 2006] ist es „sehr unwahrscheinlich, einen komplexen Arbeitsablauf ohne eine vorliegende Prozessbeschreibung planen und verfolgen zu können“. Im Standard werden dokumentierte Prozessabläufe erst ab Level 3 explizit gefordert. Somit ist die Erstellung eines Prozesstyps zum Erreichen des Levels nicht zwingend vorgeschrieben. In der Praxis werden jedoch die Planung und das Verfolgen der Projektaktivitäten durch einen modellierten Prozess signifikant erleichtert. Ob ein

48

3 Rekonstruktion des abstrakten QM-Modells

Unternehmen den Level 2 ohne modellierten Prozess erreichen kann, kann in der Praxis erst durch einen Assessor bewertet werden. Insgesamt ist es das Ziel des RG2, einen auf RG1 ausgeführten Prozess, der sich hauptsächlich auf die Kompetenz der Mitarbeiter verlässt, durch eine geeignete Projektleitung zu managen. Auf diese Weise unter anderem der Ausfall eines oder mehrerer Mitarbeiter während der Bearbeitung des Projekts bewältigt werden können. 3.2.4

RG3 – Definierter Prozess

Dieser Reifegrad bildet die dritte Stufe in den QM-Referenzmodellen ISO/IEC 15504 und CMMI. Beide Standards verfolgen dabei das Ziel die ausgeführten Prozesse zu vereinheitlichen und im Unternehmen zu etablieren. Zu diesem Zweck müssen Standardprozesse entwickelt werden, aus denen anschließend die Projekte über Tailoring-Mechanismen abgeleitet werden. Unter Tailoring wird hierbei das Anpassen eines Standardprozesses an die Gegebenheiten eines Projekts [Hörmann et al. 2006] verstanden. Die Anforderungen der beiden Standards auf Level 3 werden in Tabelle 3-5 vorgestellt und kurz zusammengefasst. Anforderungen auf Level 3

ISO/IEC 15504 a) a standard process, including appropriate tailoring guidelines, is defined that describes the fundamental elements that must be incorporated into a defined process;

PA 3.1: Process definition attribute

b) the sequence and interaction of the standard process with other processes are determined; c) required competencies and roles for performing a process are identified as part of the standard process; d) required infrastructure and work environment for performing a process are identified as part of the standard process; e) suitable methods for monitoring the effectiveness and suitability of the process are determined.

CMMI GP 3.1: Establish a Defined Process GG 3: Institutionalize a Defined Process

Tabelle 3-5:

GP 3.2: Collect Improvement Information

3.2 Strukturelle Rekonstruktion eines abstrakten QM-Modells

49

ISO/IEC 15504 a) a defined process is deployed based upon an appropriately selected and/or tailored standard process; b) required roles, responsibilities and authorities for performing the defined process are assigned and communicated; c) personnel performing the defined process are competent on the basis of appropriate education, training, and experience;

PA 3.2: Process deployment attribute

d) required resources and information necessary for performing the defined process are made available, allocated and used; e) required infrastructure and work environment for performing the defined process are made available, managed and maintained; f) appropriate data are collected and analysed as a basis for understanding the behaviour of, and to demonstrate the suitability and effectiveness of the process, and to evaluate where continuous improvement of the process can be made.

In der ISO/IEC 15504 wird das Ziel, standardisierte Prozesse im Unternehmen einzuführen, über zwei Prozessattribute geprüft. Das Prozessattribut 3.1 (Prozessdefinition) definiert ein Maß, inwieweit ein Standardprozess im Unternehmen gepflegt wird. Grundvoraussetzung für die Erfüllung dieses Attributs ist die Festlegung eines Standardprozess mit entsprechenden Tailoring-Richtlinien. Aus diesen Richtlinien geht hervor, wie Projekte im Unternehmen aus einem Standardprozess abgeleitet und anschließend umgesetzt werden müssen. Zur Definition des Standardprozesses gehört außerdem eine Festlegung seiner Interaktion mit anderen Prozessen, die Definition der im Prozess benutzen Rollen sowie die der Arbeitsumgebung und Infrastruktur. Außerdem müssen Methoden zur Messung der Effektivität des Prozesses festgelegt werden. Die Ergebnisse dieser Messung sollen genutzt werden, um den Prozess ständig an neue Erfordernisse anpassen zu können. Das Prozessattribut 3.2 (Prozessanwendung) der ISO/IEC 15504 definiert ein Maß dafür, ob und wie die im Unternehmen definierten Standardprozesse in Unterneh-

50

3 Rekonstruktion des abstrakten QM-Modells

mensprojekten angewandt werden. Dazu wird überprüft, ob Projekte mittels eines Tailoring aus den vorher definierten Standardprozessen abgeleitet wurden. Mitarbeitern im Projekt müssen die im Standardprozess geplanten Rollen und Verantwortlichkeiten zugewiesen werden; die benötigten Ressourcen müssen bereitgestellt werden und entsprechende Arbeitsumgebungen im Unternehmen vorhanden sein. Die im Standardprozess definierten Messungen müssen in den Projekten durchgeführt werden. Aus der Anforderung unternehmensweite Standardprozesse zu nutzen, ergeben sich im Vergleich mit dem Level 2 einige wichtige Unterschiede. Während es auf Level 2 noch erlaubt ist unterschiedliche Prozesse zu nutzen, solange die Anforderungen aus der Norm erfüllt werden, werden auf Level 3 standardisierte Prozesse vorausgesetzt. Diese müssen mindestens für organisatorische Einheiten mit vergleichbaren Strukturen und Projekten vereinheitlicht sein. Im Zweifelsfall muss hier der Assessor im Assessment entscheiden, was sinnvoll ist. Durch eine Variantenbildung können Prozesse an Untereinheiten der Organisationen angepasst werden. Im Gegensatz zum Level 2 wird auf Level 3 von der Norm verlangt, dass sowohl Mitarbeiter als auch Ressourcen systematisch und zuverlässig bereitgestellt werden. Mitarbeiter müssen insbesondere auch entsprechend der im Standardprozess definierten Rollen qualifiziert sein [Hörmann et al. 2006]. Das CMMI verfolgt ähnliche Ziele wie die ISO/IEC 15504. Dies wird im CMMI mit dem Generischen Ziel 3 (GG3), der Institutionalisierung eines definierten Prozesses, beschrieben. Dieses enthält wiederum zwei Generic Practices: GP 3.1 verlangt die Erstellung eines definierten Prozesses und GP 3.2 die Sammlung von Verbesserungsinformationen im Unternehmen. Ein Vergleich der beiden Normen in [Rout et Tuffley 2007] ergibt, dass sich insbesondere im ISO/IEC 15504 Prozessattribut 3.1 (Prozessdefinition) große Überschneidungen mit dem CMMI ergeben. So werden diese komplett durch das CMMI GP 3.1 abgebdeckt. Allerdings fordert die ISO/IEC 15504 in PA 3.2 (Prozessanwendung) deutlich mehr als das CMMI. So wird vom CMMI nicht explizit gefordert, dass sich Rollen, Ressourcen und Infrastruktur aus dem definierten Standardprozess ableiten lassen. Insbesondere die in der ISO/IEC 15504 genannten Forderungen PA 3.2 b) bis e) werden durch die GP 3.2 aus dem CMMI nicht abgedeckt. Bei der Aufstellung der Ziele des aQM2 wird somit ein erheblicher Teil durch die Anforderungen der ISO/IEC 15504 bestimmt.

3.2 Strukturelle Rekonstruktion eines abstrakten QM-Modells Tabelle 3-6:

Abstraktes Referenzmodell auf RG 3

RG 3 Planungsebene Ziel 3.1: Aufstellung eines Standardprozesses und seiner Schnittstellen

In diesem Ziel wird festgelegt, dass im Unternehmen Standardprozesse definiert werden, von dem die im Unternehmen durchgeführten Projekte über TailoringMaßnahmen abgeleitet werden können. Dabei muss sich der Standardprozess nicht auf das gesamte Unternehmen, sondern auf sinnvolle Organisationseinheiten beziehen [Hörmann et al. 2006]. Auch die Schnittstellen zu anderen Prozessen in der Organisation sind zu definieren. Betrifft hauptsächlich den Funktionalen Aspekt.

Ziel 3.2: Festlegen der Zuständigkeiten, Verantwortlichkeiten und der nötigen Infrastruktur im Standardprozess

Die enthaltenen Verantwortlichkeiten und Zuständigkeiten sind im Standardprozess zu definieren. Ebenso muss die notwendige Infrastruktur eingeplant werden.

Ziel 3.3: Ableitung eines Projekts aus dem Standardprozess

Aus dem Standardprozess muss für ein gegebenes Projekt mit seinen Rahmenbedingungen ein entsprechendes Projekt mit Hilfe von Tailoring-Maßnahmen abgeleitet werden.

Ziel 3.4: Festlegung der im Projekt eingesetzten Verantwortlichkeiten und der Infrastruktur

Für die im Prozess festgelegten Rollen, Verantwortlichkeiten und Zuständigkeiten sowie für die geforderte Infrastruktur müssen im Projekt systematisch die entsprechenden Ressourcen zugeteilt werden.

Ziel 3.5: Definition von Methoden zur Messung des Standardprozesses

Im Standardprozess müssen Maßnahmen und Methoden definiert werden, mit dem die Effektivität des Standardprozesses gemessen werden kann.

51

52

3 Rekonstruktion des abstrakten QM-Modells

RG 3 Ausführungsebene Ziel 3.6: Erfassung der Daten und Ermitteln von Verbesserungspotenzialen

Bei der Durchführung von Projekten müssen mit Hilfe der definierten Methoden Daten gesammelt werden, anhand derer sich die Effektivität des Projekts ermitteln lässt. Diese Daten sollen genutzt werden, um anschließende Verbesserungspotenziale im Standardprozess zu identifizieren.

Ein wesentlicher Teil der Anforderungen des RG3 ist die Definition eines Standardprozesses (Prozesstyp), aus dem ein konformer Projekttyp abgeleitet werden kann. Abbildung 3-5 zeigt die Einordnung der Anforderungen in das Meta-Modell (Abbildung 3-1) auf der Modellebene M1. Sowohl die Planung als auch das Tailoring des Prozesstyps finden beide auf der Meta-Ebene M1 statt. Wird die Modellierungssprache den Anforderungen aus dem Unternehmen nicht gerecht, so kann dies über eine Anpassung der Modellierungssprache auf der Ebene M2 gelöst werden; eine Diskussion hierzu findet sich in [Jablonski et Meerkamm 2009]. Die Planung und das anschließende Tailoring des Prozesstyps wird mit den aQM2 Zielen 3.1 bis 3.4 beschrieben. Zusammen mit der Planung der Prozessschritte müssen im Prozesstyp auch die nötigen Ressourcen und Verantwortlichkeiten sowie die Infrastruktur definiert werden. Diese werden, analog zu den Prozessschritten, über das Tailoring an die konkreten Gegebenheiten des Projekts angepasst und als Vorbereitung für die spätere Ausführung mit den tatsächlich im Unternehmen vorhandenen Mitarbeitern, bzw. der entsprechenden Infrastruktur, hinterlegt. In [Hörmann et al. 2006] wird darauf hingewiesen, dass hier besonders eine systematische Zuordnung der Ressourcen und Infrastruktur von Bedeutung ist. Nach der Ableitung des Projekttyps aus dem Prozesstyp mittels der Tailoring-Richtlinien wird das Projekt entsprechend der auf RG2 vorhandenen Ziele und Methoden geplant und anschließend ausgeführt. Die geplanten und entworfenen Methoden zur Messung der Effektivität des Prozess (Ziel 3.6) werden während der Projektausführung angewendet. Somit soll das Verhalten des Prozesses besser verstanden werden als auf Reifegrad 2 und Verbesserungspotenziale sollen einfacher identifiziert werden. Wie in der ISO/IEC 15504 [Hörmann et al. 2006] wird an dieser Stelle noch keine systematische Durchführung von Verbesserungen am Prozesstyp gefordert.

3.2 Strukturelle Rekonstruktion eines abstrakten QM-Modells

Tailoring

RG3

RG2

Ausführungsebene

M2: Sprachdesign M1: Prozessplanung

Ermitteln von Verbesserungspotenzialen

M1: Projektplanung

M0: Projektausführung

Messen

Planen

Planungsebene

53

Bereitstellen von Ressourcen

Abbildung 3-5:

Zuordnung des RG3 zum Meta-Modell

Ziel der dritten Ebene ist es, über das gesamte Unternehmen hinweg (zumindest für vergleichbare Organisationseinheiten) einen einheitlichen Prozess- und Projektablauf zu etablieren. Auf diese Weise soll das Risiko insofern reduziert werden, dass nicht mehr nur ein exzellenter Projektleiter ursächlich für das Gelingen eines Projektes verantwortlich ist, sondern alle Projekte nach demselben Prozess durchgeführt werden. Auf diese Weise kann der Ausfall eines Projektleiters einfacher als etwa auf RG2 durch den Austausch mit einem anderen Projektleiter kompensiert werden. Außerdem können die im Unternehmen (der Organisationseinheit) vorhandenen Projekte durch den gleichen oder zumindest ähnlichen Prozessablauf einfacher miteinander verglichen werden. 3.2.5

RG4 – Überwachter Prozess

In der vierten der 5 Reifegradebenen von ISO/IEC 15504 und CMMI ist es Ziel beider Ansätze einen quantitativ gemanagten Prozess im Unternehmen zu institutionalisieren. Dazu wird die Umsetzung des geplanten Prozesses im Projekt über verschiedene Messgrößen verfolgt. Abweichungen sollen so frühzeitig entdeckt werden, um entsprechende Korrekturen durch den Projektleiter einleiten zu können. In Tabelle 3-7 werden die Anforderungen, die von den beiden Referenzmodellen an die Unternehmen gestellt werden, kurz zusammengefasst.

54

3 Rekonstruktion des abstrakten QM-Modells

Tabelle 3-7:

Anforderungen auf Level 4

ISO/IEC 15504

CMMI

b) process measurement objectives are derived from identified process information needs;

PA 4.1: Process measurement attribute

c) quantitative objectives for process performance in support of relevant business goals are established; d) measures and frequency of measurement are identified and defined in line with process measurement objectives and quantitative objectives for process performance; e) results of measurement are collected, analysed and reported in order to monitor the extent to which the quantitative objectives for process performance are met;

GG 4: Institutionalize a Quantitatively Managed Process

a) process information needs in support of relevant business goals are established;

GP 4.1: Establish Quantitative Objectives for the Process

GP 4.2: Stabilize Subprocess Performance

f) measurement results are used to characterise process performance. a) suitable analysis and control techniques where applicable, are determined and applied;

PA 4.2: Process control attribute

b) control limits of variation are established for normal process performance; c) measurement data are analysed for special causes of variation; d) corrective actions are taken to address special causes of variation; e) control limits are re-established (as necessary) following corrective action.

In der ISO/IEC 15504 wird anhand zweier Prozessattribute überprüft, ob ein Projekt auf Level 4 durchgeführt wird: das Prozessattribut 4.1 Prozessmessung und das Prozessattribut 4.2 Prozesssteuerung. Mit dem Prozessattribut 4.1 werden Anforde-

3.2 Strukturelle Rekonstruktion eines abstrakten QM-Modells

55

rungen und Vorgaben an die Definition von Kenngrößen und die Erhebung von Daten basierend auf diesen Kenngrößen gestellt. Um einen Prozess effektiv messen zu können, wird in der ISO/IEC 15504 verlangt, dass ausgehend von den strategischen Geschäftszielen des Unternehmens, Messgrößen und -ziele identifiziert und definiert werden. Beispiele für solche Messgrößen sind: geplante und effektive Dauer; geplante und effektive Kosten; abgeschlossene Aufträge pro Angebot. Für die Messgrößen müssen quantitative Ziele vorgegeben werden. Um nachvollziehen zu können, ob die zu den Messgrößen vorgegeben Ziele eingehalten werden, müssen diese während der Prozessdurchführung durch Messungen überwacht werden. Diese Messungen müssen hinsichtlich ihrer Messmethode und der -frequenz an das Projekt angepasst werden. Die erfassten Daten müssen in einem geeigneten Repositorium gesammelt und anschließend auch ausgewertet werden; hierzu gehören neben der effektiven Erhebung auch eine Analyse der Messungen mittels statistischer Verfahren und ein Reporting. Das Prozessattribut 4.2 (Prozesssteuerung) nutzt die zuvor gewonnenen Messdaten, um den Prozess innerhalb vorher definierter Schranken durchzuführen und bei Abweichungen reagieren zu können. Das Prozesssteuerungsattribut zielt darauf ab, mit Hilfe der ermittelten Kennzahlen einen stabilen und vorhersagbaren Prozess im Unternehmen zu etablieren. In den Generic Practices zu dem Prozessattribut wird gefordert, dass Analyse- und Steuerungstechniken sowie Parameter zur Prozesssteuerung bestimmt werden. Die Messergebnisse von Prozess und Produkt müssen im Fall von Abweichungen auf ihre Gründe analysiert werden. Dazu gehören das Ermitteln von Abweichungen, das Mitschreiben aller Situationen, in denen die Limits überschritten wurden und ein Reporting an die Prozessverantwortlichen. Ausgehend auf den Analysen sind für alle Fälle in denen es Abweichungen gegeben hat, Korrekturmaßnahmen zu ergreifen. Die Ergebnisse der Korrekturmaßnahmen müssen verfolgt und auf ihre Effektivität überwacht werden. Wenn nötig, können die Prozesskontrollgrenzen an neue Erkenntnisse oder Gegebenheiten angepasst werden. Das CMMI verfolgt auch auf Ebene 4 ähnliche Ziele wie die ISO/IEC 15504. Dort werden die Ziele in zwei Generic Practices zusammengefasst. GP 4.1 verlangt, dass für ein Projekt quantitative Prozessziele aufgestellt werden, die sich auf die Kundenwünsche und Geschäftsziele beziehen. GP 4.2 verlangt die Stabilisierung der Prozessausführung, um die festgelegten quantitativen Qualitäts- und Performanzziele eines Projekts zu erreichen. Zwar verfolgen beide QM-Standards dieselben Ziele, allerdings setzen sie ihren Schwerpunkt leicht unterschiedlich [Rout et Tuffley 2007]. So werden etwa Teile der im PA 4.1 Prozessmessung vorgesehenen Aktivitäten durch die generische Praktik 4.2

56

3 Rekonstruktion des abstrakten QM-Modells

Stabilisierung der Prozessausführung umgesetzt. Die gegenseitige Überdeckung der beiden Referenzmodelle ist jedoch hoch. Für das aus beiden Modellen abgeleitete abstrakte Referenzmodell aQM2 wird wie bei den vorherigen Ebenen wieder zwischen der Planungsebene und der Ausführungsebene unterschieden. Die Umsetzung der Anforderungen der vierten Reifegradebene erfolgt hauptsächlich in der Ausführungsebene. Zwar müssen ausgehend von den strategischen Zielen des Unternehmens Ziele für die Projektausführung geplant und auch an das Projekt anpasst werden, allerdings sind Messung, Überwachung und Steuerung des Projekts Teil der Ausführungsebene. Tabelle 3-8:

Abstraktes Referenzmodell auf RG 4

RG 4 Planungsebene Ziel 4.1: Definition von quantitativen Zielen für die Messungen

Basierend auf den strategischen Geschäftszielen des Unternehmens müssen quantitative Ziele für den im Projekt durchgeführten Prozess definiert werden.

Ziel 4.2: Identifikation von Messpunkten für Prozess und Produkt

Um die in Ziel 4.1 definierten quantitativen Ziele messen zu können, müssen sowohl im genutzten Prozess als auch für das zu erstellende Produkt Messpunkte identifiziert und entsprechende Methoden definiert werden.

Ausführungsebene Ziel 4.3: Mit Hilfe der definierten Messpunkte müssen Sammeln und Erfassen von im ausgeführten Projekt Daten erhoben und in Messdaten einem entsprechenden Repositorium gesammelt werden. Ziel 4.4: Überwachung des Projekts und statistische Analyse der Messdaten

Die im Messdatenrepositorium vorhanden Daten müssen mit statistischen Methoden ausgewertet werden, um Abweichungen von den vorher durch die quantitativen Ziele vorgegebenen Schranken frühzeitig erkennen zu können.

3.2 Strukturelle Rekonstruktion eines abstrakten QM-Modells

57

RG 4 Ziel 4.5: Erarbeitung von Korrekturmaßnahmen und Steuerung des Projekts

Um die vorgegebenen Schranken für die Prozessausführung einhalten zu können, müssen geeignete Maßnahmen definiert und im Projekt umgesetzt werden. Dazu sind Steuerungstechniken zu entwickeln und im Projekt zu implementieren.

Die Festlegung der Informationsbedürfnisse im Unternehmen, basierend auf den strategischen Zielen, ist Teil der Planungsebene. Die strategische Ausrichtung des Unternehmens wird in aller Regel in einem Qualitätsmanagementhandbuch abgelegt [Wagner et Käfer 2008] und ist nicht Teil des Prozesstyps. Sie findet jedoch Eingang in die Informationsbedürfnisse des Unternehmens und somit auch in die Definition der Messgrößen, welche mit quantitativen Zielen hinterlegt werden müssen. Diese quantitativen Ziele sind jedoch noch unabhängig vom konkreten Projekt definiert und werden erst durch die Definition der Messpunkte an das Projekt angepasst (Ziele 4.1 und 4.2). Dieser Zusammenhang wird in Abbildung 3-6 verdeutlicht.

Ausführungsebene

M2: Sprachdesign

Erfassung von Messdaten

Definition von Informationsbedürfnisse n und Messzielen

RG3

M1: Prozessplanung M1: Projektplanung

M0: Projektausführung

RG4 Projektüberwachung/ Analyse von Abweichungen

M0: Messdatenbank

Projektsteurerung

Planungsebene

Definition von Zielen für das Projekt

Abbildung 3-6:

Zuordnung des RG4 zum Meta-Modell

Auf Ausführungsebene werden mittels der Messpunkte Daten im Projekt erhoben und in einem geeigneten Repositorium abgelegt (Ziel 4.3). Die Daten müssen dort so abgelegt werden, dass sie anschließend mit Hilfe statistischer Verfahren ausgewertet

58

3 Rekonstruktion des abstrakten QM-Modells

werden können. Diese treffen Aussagen darüber, ob die Ausführung des Projekts innerhalb der vordefinierten Schranken stattfindet, oder ob Abweichungen aufgetreten sind (Ziel 4.4). Im Fall von Abweichungen sind geeignete Maßnahmen zu entwickeln und im Projekt umzusetzen, um die Ausführung wieder innerhalb der vordefinierten Schranken zu gewährleisten. Auch das Anpassen der Schranken im Anschluss an die Durchführung von Korrekturmaßnahmen wird durch die QM-Referenzmodelle erlaubt (Ziel 4.5). Kern des RG4 ist es somit, das Verhalten eines Projektes durch statistische Messgrößen vorherzusagen und innerhalb vordefinierter Schranken steuern zu können. Während zwar schon auf RG2 gefordert wird, dass die im Projekt verwendeten Prozesse kontrolliert und gesteuert werden, gehen die in RG4 geforderten Praktiken darüber hinaus und fordern den Einsatz statistischer Methoden. Diese detaillierten Messungen und Analysen sollen zu einem besseren Prozessverständnis und einer gesteigerten Vorhersagegenauigkeit über die Ausführung des Prozesses führen [Hörmann et al. 2006]. Auf diese Weise sollen potenzielle Probleme frühzeitig erkannt und entsprechende Gegenmaßnahmen ergriffen werden. 3.2.6

RG5 – Verbessernder Prozess

Die Reifegradebene 5 bildet die letzte Stufe in den Referenzmodellen ISO/IEC 15504 und CMMI. Aufbauend auf den im RG4 gesammelten Messdaten sollen hier Ansatzpunkte zur Verbesserung der Prozesse im Unternehmen systematisch erarbeitet, im Unternehmen pilotiert und umgesetzt werden. In Tabelle 3-9 werden die Anforderungen, die durch die ISO/IEC 15504 und das CMMI an Prozesse gestellt werden, gegenüber gestellt. In der ISO/IEC 15504 wird anhand von zwei Prozessattributen überprüft, ob ein Prozess auf Level 5 ausgeführt wird: das Attribut 5.1 (Prozessinnovation) macht Vorgaben, wie ein Prozess unterstützt werden kann, um Innovationen zur Verbesserung zu erzeugen. Das Prozessattribut 5.2 (Prozessoptimierung) beschreibt, wie ein optimierender Prozess entsprechend der Vorgaben der ISO/IEC 15504 aussehen muss. Um die Innovation in Prozessen zu unterstützen müssen zuerst die Ziele für eine Verbesserung des Prozesses definiert werden, welche aus den Geschäftszielen abgeleitet werden können. Die auf Level 4 erhobenen Daten werden dann ausgewertet, die wichtigsten Gründe für Abweichungen identifiziert und Verbesserungsmöglichkeiten erarbeitet. Zur Prozessverbesserung können dabei auch neue Technologien und Prozesskonzepte eingesetzt werden. Vor der Einführung im Unternehmen ist eine Umsetzungsstrategie zu erarbeiten. An die Prozessoptimierung werden im Wesentlichen drei Anforderungen gestellt. Zum einen müssen die Auswirkungen der Veränderungen auf den Prozess abgeschätzt werden. Außerdem muss die Umsetzung

3.2 Strukturelle Rekonstruktion eines abstrakten QM-Modells

59

der Verbesserungen gemanagt und begleitet werden und schließlich muss die Effektivität der Prozessänderungen untersucht werden. Tabelle 3-9:

Anforderungen auf Level 5

ISO/IEC 15504

CMMI

PA 5.1: Process innovation attribute

b) appropriate data are analysed to identify common causes of variations in process performance; c) appropriate data are analysed to identify opportunities for best practice and innovation; d) improvement opportunities derived from new technologies and process concepts are identified; e) an implementation strategy is established to achieve the process improvement objectives.

GP 5.1: Ensure Continuous Process Improvement GG 5: Institutionalize an Optimizing Process

a) process improvement objectives for the process are defined that support the relevant business goals;

GP 5.2: Correct Root Causes of Problems

PA 5.2: Process optimization attribute

a) impact of all proposed changes is assessed against the objectives of the defined process and standard process; b) implementation of all agreed changes is managed to ensure that any disruption to the process performance is understood and acted upon; c) effectiveness of process change on the basis of actual performance is evaluated against the defined product requirements and process objectives to determine whether results are due to common or special causes.

Im CMMI wird die Umsetzung des Levels 5 durch zwei Generic Practices gemessen. Prozessgebiet 5.1 fordert, dass das Unternehmen eine kontinuierliche Verbesserung der in Projekten genutzten Prozesse sicherstellt und Prozessgebiet 5.2, dass die Ausgangsursachen von Problemen in Prozessen behoben werden. Die Analyse der beiden Qualitätsstandards in [Rout et Tuffley 2007] ergibt, dass sich die ISO/

60

3 Rekonstruktion des abstrakten QM-Modells

IEC 15504 und das CMMI stark überschneiden und vor allem das CMMI Prozessgebiet 5.1 schon alle Ziele der beiden ISO/IEC 15504 Prozessattribute abdeckt. Die Generic Practice 5.2 (Aufdeckung der Ausgangsursache von Fehlern) überschneidet sich hingegen nur mit einem Ziel in der ISO/IEC 15504 (PA 2.5 b). Somit werden trotz der Gemeinsamkeiten unterschiedliche Ziele von den QM-Standards gesetzt. Die Umsetzung der Anforderungen des RG5 ist nicht, wie in den Ebenen RG1 bis RG4, ein Vorgang, der von Planungsebene ausgeht und die Umsetzung in der Ausführungsebene zum Ziel hat. Stattdessen liegt hier, abgesehen von der Planung der Verbesserungsziele, der Ausgangspunkt in der Ausführungsebene. Durch einen systematischen Rückschluss sollen Erkenntnisse, die aus gesammelten Daten (Ausführungsebene) gewonnen werden, genutzt werden, um Prozessverbesserungen anzustoßen. Diese Rückkopplung von Erkenntnissen aus der Ausführung auf die Planung ist zentraler Bestandteil dieser Reifegradebene. Tabelle 3-10: Abstraktes Referenzmodell auf RG 5

RG 5 Planungsebene Ziel 5.1: Definition der strategischen Verbesserungsziele

Ausgangspunkt für die Erarbeitung der Prozessverbesserungen ist eine klare Definition der Ziele der Prozessverbesserung. Diese müssen im Einklang mit den strategischen Zielen des Unternehmens stehen.

Ausführungsebene Ziel 5.2: Analyse der Daten

Die auf RG4 gesammelten und erfassten Daten werden im Hinblick auf Verbesserungsmöglichkeiten analysiert. Dabei müssen insbesondere die strategischen Verbesserungsziele beachtet werden.

Ziel 5.3: Identifikation von Gründen für Abweichungen

Basierend auf der Analyse der Daten sind die Gründe für Abweichungen zu suchen. Dabei sollen vor allen die grundlegenden Ursachen für Probleme im Prozess identifiziert werden.

3.2 Strukturelle Rekonstruktion eines abstrakten QM-Modells

61

RG 5 Planungsebene Ziel 5.4: Erarbeiten von Verbesserungsmöglichkeiten

Für die gefundenen Ursachen für Abweichungen sind Verbesserungsmöglichkeiten zu erarbeiten, die die Ursachen von Prozessabweichungen beseitigen. Dabei sind insbesondere neue technische und methodische Verfahren zu berücksichtigen.

Ziel 5.5: Entwickeln einer Umsetzungsstrategie

Die erarbeiteten Verbesserungsmöglichkeiten sind im Rahmen eines Piloten vor der Umsetzung zu evaluieren. Somit sollen untaugliche Lösungen vor einem breiten Ausrollen im Prozess aussortiert werden.

Ziel 5.6: Umsetzen der Verbesserungen

Lösungen, die in einem Pilotprojekt erfolgreich waren, sollen in den Standardprozess integriert werden. Durch die Überarbeitung des Standardprozesses wird auch ein Ausrollen der Lösung in vorhandene Projekte erreicht.

Ausführungsebene Ziel 5.7: Untersuchen der Effektivität der Verbesserungen

Nach einem Ausrollen des geänderten Prozesses in die Projekte muss mittels der im Messdatenrepositorium vorhandenen Daten ständig die Effektivität der Verbesserungen überprüft werden.

Ausgangspunkt der Verbesserungsmaßnahmen ist eine Festlegung der Ziele basierend auf der strategischen Ausrichtung des Unternehmens. Diese Ziele können monetäre Ziele (z.B. Erhöhung des Return of Investment), qualitative Ziele (z.B. Minderung der beim Kunden gefundenen Fehler) oder andere sein. So soll sichergestellt werden, dass die im Unternehmen umgesetzten Verbesserung helfen, die Unternehmensstrategie umzusetzen. Von den definierten Verbesserungszielen ausgehend werden die im Messdatenrepositorium vorhandenen Daten auf die Ursachen von Abweichungen untersucht. Dabei sind vor allem solche Gründe interessant, die für eine Vielzahl von Abweichungen verantwortlich sind. Sobald die

62

3 Rekonstruktion des abstrakten QM-Modells

Gründe identifiziert wurden, kann mit der Erarbeitung von Verbesserungsvorschlägen begonnen werden. Aus der Menge an Vorschlägen müssen jene identifiziert werden, die die höchste Erfolgswahrscheinlichkeit versprechen. Im Rahmen eines Pilotprojektes ist eine Strategie für die Umsetzung der Verbesserungsvorschläge zu erarbeiten, bevor diese im Rahmen einer Überarbeitung in die Unternehmensprozesse aufgenommen werden können. Durch die Überarbeitung der Standardprozesse erfolgt auch ein Ausrollen der Änderungen in die Instanzen. Durch eine regelmäßige Überprüfung der im Messdatenrepositorium vorhanden Daten muss im Anschluss an die Umsetzung der Verbesserungsmaßnehmen und dem Ausrollen in die Projekte ihre Effektivität überprüft werden (Abbildung 3-7).

Planungsebene

Ausführungsebene

RG5

Erarbeiten von Verbesserungsmöglichkeiten

RG4

Verbesserungen

M0: Messdatenbank

Entwickeln einer Umsetzungsstrategie

M2: Sprachdesign Umsetzen der Verbesserungen

M1: Prozessplanung

Analyse der Daten Identifikation von gemeinsamen Gründen für Abweichungen

Sicherstellen der Effektivität

M1: Projektplanung

Abbildung 3-7:

Zuordnung des RG5 zum Meta-Modell

Im Bezug auf das Meta-Modell sind auf RG5 im Wesentlichen die Ebenen M1 und M0 betroffen. Ausgehend von den auf M0 erfassten Projektdaten werden systematisch die definierten Prozesse auf Ebene M1 an die vorgeschlagenen Änderungen angepasst. Durch das Tailoring der Prozesse in Projekte wird erneut ein Ebenenwechsel durchgeführt. Die Effektivität der Verbesserungsmaßnahmen kann wiederum nur auf Ebene M0 im Messdatenrepositorium sichergestellt werden. 3.3

Zusammenfassung

In den vorangegangenen Abschnitten wurden die Ziele des aQM2 und damit das QMAnforderungsgerüst für das prozessbasierte Informationssystem vorgestellt. Die Ziele bauen sukzessive aufeinander auf und verfolgen den Zweck, Anforderungen an ein

3.3 Zusammenfassung

63

System zur Prozessverbesserung zu stellen. Auf RG1 geht es darum, im Prozess eine Menge an vorgegebenen „Best Practices“ umzusetzen. Auf diese Weise sollen etablierte Software Engineering Methoden im Unternehmensprozess verankert werden. RG2 ergänzt diese Methoden um ein strukturiertes Projektmanagement. Der Ist-Zustand der Projektausführung wird mit dem geplanten Soll verglichen; bei Abweichungen vom Plan hat der Projektleiter steuernd einzugreifen. Das Projektmanagement wird auf RG3 um einen standardisierten Referenzprozess erweitert, aus dem alle Projekte durch einen Tailoring-Mechanismus abgeleitet werden müssen. Somit werden im Unternehmen in allen Projekten die gleichen Standards etabliert. Auf RG4 werden mathematisch statistische Methoden genutzt, um Projekte genauer verfolgen zu können, das Projekt innerhalb vordefinierter Schranken zu managen und mögliche Abweichungen frühzeitig vorhersagen zu können. Diese statistischen Analysen werden schließlich auf RG5 genutzt, um Verbesserungen im Prozess systematisch zu identifizieren und umzusetzen.

4

Anforderungen an ein prozessbasiertes Informationssystem aus Anwendersicht

Im Kapitel 3 werden die Anforderungen an ein prozessbasiertes Informationssystem aus Sicht der Qualitätsmanagementstandards vorgestellt. Damit ist jedoch nur ein Teil der Anforderungen abgedeckt. In diesem Kapitel werden die Anforderungen vorgestellt, die sich an ein solches System aus Sicht der Anwender ergeben. Diese Anforderungen sind unabhängig von denen aus QM-Sicht; beide Anforderungsarten ergänzen sich gegenseitig und bilden die Ausgangsbasis für die Entwicklung des ProcessNavigators (siehe Abbildung 1-4). Die Tatsache, dass die Anforderungen des QM-Systems mit einem prozessbasierten Informationssystem umgesetzt werden sollen, ist naheliegend. Prozesse bilden einen zentralen Bestandteil der in Kapitel 2 vorgestellten Vorgehensmodelle und QMStandards. Prozess- oder Workflow-Management-Systeme nutzen einen modellierten Prozess als Ausgangsbasis und unterstützen den Mitarbeiter bei seiner Ausführung. Die Anforderungen, die an Prozessmanagementsysteme gestellt werden, sind in verschiedenen Literaturquellen ausführlich beschrieben und sollen hier nicht wiederholt werden. Aus Sicht dieser Arbeit werden die wichtigsten Anforderungen in [Georgakopoulos et al. 1995; Jablonski 2009; Jablonski et Bussler 1996; van der Aalst et al. 2003] zusammengefasst. 4.1

Änderungen als zentraler Bestandteil des Prozessmanagements

Bei der Nutzung von Prozessmanagementsystemen in Unternehmen stellt sich immer folgende zentrale Frage: „Wie weit dürfen Mitarbeiter vom vordefinierten Prozess abweichen?“. Die Antwort auf diese Frage hängt direkt mit der Anwendungsdomäne und dem Einsatzzweck eines Prozessmanagementsystems zusammen. So kann es in einer Domäne sinnvoll sein, die dort vorhandenen Prozesse sehr strikt durchzuführen (z.B. die Freigabe von Dokumenten in einem Unternehmen), während in einer anderen nur eine sehr freie Ausführungsform (z.B. die Behandlung von Patienten in einem klinischen Prozess) erlaubt ist. Beide Fälle sind, bezogen auf ihren jeweiligen Anwendungsbereich, korrekt und werden von den Anwendern in aller Regel auch akzeptiert; die umgekehrte Anwendung (strikte Ausführung von medizinischen Prozessen bzw. freie Ausführung der Dokumentenfreigabe) würde jedoch zu einer starken Ablehnung des Systems durch den Nutzer führen. Der Grad der Freiheit muss also der Anwendung angemessen sein. Wie in diesem Kapitel gezeigt wird, ist für die Unterstützung von Produktentwicklungsprozessen eine sehr freie Form der Prozessausführung nötig. Im Folgenden wird statt des Begriffs „freie Prozessausführung“ der

66

4 Anforderungen an ein prozessbasiertes Informationssystem aus Anwendersicht

Begriff „flexible Prozessausführung“ gewählt, da zwar weiterhin Restriktionen existieren (z.B. durch den QM-Standard), sich das Prozessmanagementsystem jedoch flexibel an die Bedürfnisse der Anwender anpassen kann. In [van der Aalst et Jablonski 2000] wird untersucht, wie sich Flexibilität, ausgelöst durch eine Änderung, auf die Ausführung von Workflows auswirkt und welche seiner Bereiche betroffen sind. Es werden sechs verschiedene Klassifikationskriterien vorgestellt, mit denen sich der Einfluss und die Auswirkungen von Änderungen auf den Workflow bewerten lassen: x Der Grund für das Auftreten der Änderung. Gründe, die eine Änderung des Prozesses auslösen, können entweder durch interne oder externe Ereignisse ausgelöst werden. Interne Ereignisse sind beispielsweise ein fehlerhaftes Prozessdesign oder technische Probleme im Prozess; externe Auslöser können ein geändertes Geschäftsumfeld, Gesetzesänderungen oder auch ein neues technisches Umfeld sein. x Die Auswirkung der Änderung auf den Prozess. Die Änderung kann sich entweder nur temporär auf den Prozess auswirken, das heißt, sie betrifft nur einen oder eine ausgewählte Gruppe von Prozessintanzen, oder sie kann alle Prozesse dauerhaft ändern. Temporäre Änderungen werden oft durch Ausnahmen ausgelöst und eine Anpassung der Prozessdefinition ist im Gegensatz zu dauerhaften Änderungen nicht notwendig. x Von der Änderung betroffene Prozessbestandteile. In Kapitel 7 wird das Aspektorientierte Prozessmodell [Jablonski et Bussler 1996] eingeführt. Dabei wird gezeigt, dass sich ein Prozess aus fünf verschiedenen Aspekten (Perspektiven) zusammensetzt. Jeder dieser Aspekte beschreibt einen bestimmten Teil eines Prozessmodells (die Funktionen, den Kontrollfluss, die Prozessdaten, beteiligte Organisationen und Werkzeuge). Durch die Änderungen können entweder einzelne oder auch mehrere Perspektiven betroffen sein. x Die Art der der Änderung. Die Änderung kann eine Erweiterung um neue Prozessschritte oder eine Reduzierung der Schritte des Prozesstyps beinhalten. Weitere Möglichkeiten sind das Ersetzen von Dokumenten, Werkzeugen oder Organisationseinheiten im Prozess. x Der Zeitpunkt, zu dem Änderungen erlaubt werden. Änderungen am Prozess können entweder nur vor seiner Instanziierung oder auch während der Ausführung erlaubt werden. Sind Änderungen nur vor der Instanziierung eines Prozesses erlaubt, so sind laufende Prozesse nicht betroffen und eine Anpassungsstrategie ist für diese Prozesse nicht nötig.

4.1 Änderungen als zentraler Bestandteil des Prozessmanagements

67

x Die Auswirkung von Änderungen auf laufende Prozesse. Sind Änderungen auch während der Laufzeit von Prozessen erlaubt, so müssen diese Instanzen an die geänderte Prozessdefinition angepasst werden. Mögliche Strategien sind dabei die Vorwärts-Recovery (Prozesse werden abgebrochen und Änderungen außerhalb des Systems durchgeführt), die Rückwärts-Recovery (Prozesse werden abgebrochen und der Vorgang mit dem neuen Prozess wiederholt) und Fortfahren (der alte Prozess wird unverändert fortgsetzt). Außerdem können die Prozesse auf die neue Definition angepasst werden und für temporäre Änderungen kann eine „Umleitung“ für die betroffenen Instanzen geplant werden. Ergänzend zu diesen Kriterien wird in [Schonenberg et al. 2008] eine Systematik bestehend aus vier Klassen vorgestellt. Diese beschreibt, wie Flexibilität in Prozessmanagementsystemen umgesetzt werden kann. Die Klassen können genutzt werden, um in einem Prozessmanagementsystem auf Änderungen zu reagieren und diese zu implementieren: x Flexibility by Design Diese Klasse ist dadurch gekennzeichnet, dass die Änderungsmöglichkeiten schon vor der Ausführung des Prozesses im Prozesstyp enthalten sind. Dies kann beispielsweise durch die Modellierung von parallelen Ausführungssträngen, Entscheidungen oder Iterationen umgesetzt werden. Während der Ausführung hat der Nutzer die Möglichkeit, die Prozessausführung entsprechend der im Prozesstyp vorgegebenen Wahlmöglichkeiten zu beeinflussen. x Flexibility by Deviation In dieser Klasse können Nutzer während der Prozessausführung vom vorgegebenen Prozesstyp abweichen, ohne den Typ selbst ändern zu müssen. So haben die Mitarbeiter bei der Ausführung des Prozesses unter anderem die Möglichkeit Prozessschritte zu überspringen, Schritte erneut auszuführen oder diese auszulassen. x Flexibility by Underspecification Die Unterspezifikation eines Prozesses zeichnet sich dadurch aus, dass bei der Modellierung eines Prozesses bestimmte Ausführungselemente nicht festgelegt werden und ein Platzhalter an dieser Stelle eingefügt wird. Die Platzhalter können während der Ausführung entweder durch vorgegebene Prozessfragmente ausgefüllt werden (late binding) oder während der Ausführung wird an dieser Stelle ein neu erstelltes Prozessfragment eingefügt (late modeling).

68

4 Anforderungen an ein prozessbasiertes Informationssystem aus Anwendersicht

x Flexibility by Change Bei dieser Klasse wird die Möglichkeit eingeräumt, den Prozesstyp während der Ausführung des Prozesses zu ändern und an neue Anforderungen anzupassen. Diese Änderungen können sowohl nur die ausgeführte Instanz betreffen (temporäre Änderung) als auch alle zukünftigen Instanzen (dauerhafte Änderung). Ziel bei der Entwicklung eines prozessbasierten Informationssystems muss es sein, durch eine angemessene Flexibilität die Arbeit der Entwickler bei der (Software-) Produktentwicklung nachhaltig zu unterstützen. Neben den Anforderungen der Anwendungsdomäne (erlaubt viel bzw. keine Flexibilität) ist vor allem die Akzeptanz des Systems durch die Mitarbeiter ein wichtiges Kriterium für die Auswahl des Flexibilitätsgrads bzw. wie Flexibilität realisiert wird. Nur wenn das System von diesen als „nützlich“ eingeschätzt wird und sie nicht bei der täglichen Arbeit behindert, wird es möglich sein, ein solches Prozessmanagementsystem dauerhaft in der Produktentwicklung zu etablieren. 4.2

Anforderungen an die Flexibilität des Informationssystems

Im Forschungsverbund FORFLOW5 [Meerkamm 2007; Meerkamm et Paetzold 2008] wurde untersucht, wie Produktentwicklungsprozesse6 durch ein Prozessmanagementsystem unterstützt werden können. Dabei sollen die Mitarbeiter des Projekts (Entwickler bzw. Ingenieure) systematisch bei der Bearbeitung ihrer Aufgaben unterstützt werden. Das System soll Anwender umfassend über die aktuelle Projektsituation informieren und sie dabei unterstützen, die notwendigen Arbeiten auszuführen und richtige Entscheidungen zu treffen. Die Projektsituation wird dabei charakterisiert durch den aktuellen und die folgenden Arbeitsschritte sowie durch die in den Schritten zu bearbeitenden Aufgaben. Bei der Entwicklung des ProcessNavigators musste eine Antwort auf die Fragestellung gefunden werden, wie die Mitarbeiter im Entwicklungsprojekt durch ein Prozessmanagementsystem unterstützt werden können, ohne sie durch das System einzuschränken. So treten bei der Entwicklung von Produkten immer wieder unvorherge-

5

6

Bayerischer Forschungsverbund für Prozess- und Workflow-Unterstützung zur Planung und Steuerung der Abläufe in der Produktenwicklung (www.forflow.org) Im Rahmen des FORFLOW-Projekts wurden Produktentwicklungsprozesse betrachtet und ausgehend von diesen Anforderungen und Konzept des ProcessNavigators entwickelt. Aus diesem Grund werden in dieser Arbeit hauptsächlich Produktentwicklungsprozesse adressiert. Das Konzept des ProcessNavigators und das hier entwickelte flexible Prozessausführungskonzept lassen sich jedoch ohne Weiteres auch auf andere Anwendungsgebiete mit ähnlicher Charakteristik (z.B. Dienstleistungsprozesse, wissenschaftliche Prozesse etc.) übertragen.

4.2 Anforderungen an die Flexibilität des Informationssystems

69

sehene Ereignisse (z.B. Inkonsistenzen in den Anforderungen, neue Rahmenbedingungen etc.) auf, auf die ein Entwickler reagieren und eine passende Lösung finden muss. Um eine passende Lösung zu finden, ist vor allem die Erfahrung, Wissen und Kreativität des Anwenders gefordert. Diese dürfen nicht durch ein Prozessmanagementsystem eingeschränkt oder behindert werden. Aus diesem Grund müssen insbesondere die folgenden Funktionen durch das Prozessmanagementsystem unterstützt werden [Faerber et al. 2009]: #1 Vorschlag der nächsten Arbeitspakete: Der ProcessNavigator muss Mitarbeitern die jeweils nächsten Prozessschritte vorschlagen. Diese Anforderung entspricht der Funktionsweise von klassischen Workflow-ManagementSystemen. Diese informieren Mitarbeiter in einer Aufgabenliste (der Worklist) über Aufgaben, die bearbeitet werden müssen. #2 Wiederholen von Arbeitspaketen: Die Entwicklung eines Produktes ist kein linearer Prozess. Vielmehr ist er gekennzeichnet durch Iterationen und Schleifen. Da diese kurzen Iterationen ad hoc auftreten und nicht von Anfang an im Prozesstyp eingeplant werden können, muss der ProcessNavigator die erneute Ausführung auch bereits abgeschlossener Arbeitsschritte zulassen. #3 Überspringen von Arbeitspaketen: Die Kreativität der Ingenieure ist ein entscheidender Erfolgsfaktor bei der Entwicklung von Produkten und darf nicht durch ein Prozessmanagementsystem eingeschränkt werden. Aus diesem Grund sollen Anwender die Möglichkeit haben, Arbeitsschritte zu überspringen und mit einem Schritt, der erst später im Entwicklungsprozess vorgesehen ist, fortzufahren. Übersprungene Schritte dürfen jedoch nicht als abgeschlossen markiert werden und müssen den Anwendern erneut zur Bearbeitung angeboten werden. #4 Auslassen von Arbeitspaketen: In Ausnahmefällen kann es vorkommen, dass Arbeitspakete, obwohl sie im Prozesstyp eingeplant sind, im Verlauf des Prozesses nicht mehr bearbeitet werden müssen. Die Entscheidung, ob die Ergebnisse eines Arbeitspakets nicht mehr benötigt werden, ist komplex und kann nur von Mitarbeitern getroffen werden. Der ProcessNavigator muss diesen Fall jedoch zulassen, allerdings müssen Mitarbeiter in diesen Fällen eine Begründung im System angeben. Dies ist vor allem im Hinblick auf eine spätere Nachvollziehbarkeit der im Projekt getroffenen Entscheidungen wichtig. Insgesamt ist also ein Informationssystem gefragt, das den Mitarbeiter durch die Bearbeitung des Projektes leitet, ihm Hinweise gibt, welche Arbeitspakete als nächstes bearbeitet werden müssen und ihm vor allem genügend Freiheiten einräumt, um das Projekt erfolgreich zu Ende zu führen. Bezogen auf die in

70

4 Anforderungen an ein prozessbasiertes Informationssystem aus Anwendersicht

[Schonenberg et al. 2008] vorgestellte Systematik zur Umsetzung von Flexibilität in Prozessmanagementsystemen entspricht dies dem Konzept Flexibility by Deviation. Dabei ist zu beachten, dass immer nur die ausgeführte Prozessinstanz von den Änderungen betroffen ist. Von den Änderungen können jedoch alle Bestandteile (Aspekte) eines Prozess betroffen sein. Werden Änderungen an einem ausgeführten Prozess durch die Nutzer erlaubt, so stellt sich immer auch die Frage, ob der geänderte Prozesstyp noch korrekt ist. Während die syntaktische Korrektheit eines geänderten Prozesses in aller Regel überprüft werden kann, ist dies bei der semantischen Korrektheit ohne Wissen über die Anwendungsdomäne nicht möglich [van der Aalst et Jablonski 2000]. Dies trifft insbesondere auf die in der Produktentwicklung eingesetzten Prozesse zu. Ob die Änderung an einem Entwicklungsprozess (z.B. das Auslassen eines Reviews) „korrekt“ ist, kann erst im Kontext des konkreten Projekts und mit Wissen über die Anwendungsdomäne (Softwareentwicklung oder Produktentwicklung) entschieden werden. Im Rahmen der ISO/IEC 15504 oder dem CMMI wird dies in einem Assessment durch den Assessor bewertet. Da die automatisierte Bewertung der Korrektheit von Änderungen durch ein Informationssystem nicht möglich ist, wird das Thema in dieser Arbeit nicht weiter betrachtet. Die im Projekt FORFLOW gewonnenen Erfahrungen zeigen, dass dies auch der Projektwirklichkeit in Unternehmen entspricht. 4.3

Bereitstellung von Ausführungswissen für die Anwender

Nachdem sich ein Mitarbeiter für die Bearbeitung eines Prozessschrittes entschieden hat, muss er darüber informiert werden, wie der Schritt auszuführen ist und was bei seiner Bearbeitung zu beachten ist. Dabei nimmt das prozessbasierte Informationssystem auch Funktionen eines Wissensmanagementsystems [Alavi et Leidner 2001; Nonaka et Takeuchi 1995] wahr, indem es die nötigen Kontextinformationen bereitstellt: #5 Bereitstellen von Informationen über das Arbeitspaket: Das Prozessmanagementsystem muss den Mitarbeitern Informationen über das aktuelle Arbeitspaket bereitstellen. Diese Informationen beinhalten insbesondere eine ausführliche Beschreibung der umzusetzenden Arbeitspakete. Neben der eigentlichen Aufgabenbeschreibung müssen zusätzlich noch weitere Informationen bereitgestellt werden. #6 Koordination der Arbeitspakete zwischen den Mitarbeitern: Um eine Zusammenarbeit zwischen den Mitarbeitern gewährleisten zu können, müssen die Arbeitspakete zwischen den einzelnen Mitarbeitern koordiniert werden. Für alle am Prozess beteiligten Mitarbeiter muss eine gemeinsame Sicht auf den Gesamtprozess erzeugt werden; sobald ein Arbeitspaket von einem der Mit-

4.3 Bereitstellung von Ausführungswissen für die Anwender

71

arbeiter bearbeitet wird, muss diese Information an alle anderen am Projekt beteiligten Mitarbeiter verteilt werden. #7 Bereitstellen von Dokumenten und Produktmodellen: Der ProcessNavigator muss die in einem Prozessschritt zu bearbeitenden Eingangs- und Ausgangsdokumente bereitstellen. Mitarbeiter sollen durch den im ProcessNavigator Zugriff auf die Eingangsdokumente erhalten. Dies erspart den Mitarbeitern einerseits Dokumente erst anfordern zu müssen, bevor sie bearbeitet werden können; andererseits wird so gewährleistet, dass immer mit den aktuellen Dokumenten gearbeitet wird und diese in einem System archiviert sind. Für die zu erstellenden Ausgangsdokumente muss der ProcessNavigator Dokument-Templates bereitstellen. Außerdem können Beispieldokumente hinterlegt sein, die den Mitarbeitern aufzeigen, was als Ergebnis eines Arbeitsschritts erwartet wird. #8 Unterstützung bei der Benutzung von Werkzeugen und Systemen: Der ProcessNavigator soll dem Mitarbeiter Informationen über die im Prozessschritt verwendeten Werkzeuge und Systeme anbieten. Dies umfasst insbesondere erprobte Verfahren, wie die Werkzeuge zu benutzen sind und wie damit besonders gute Ergebnisse erzielt werden können. #9 Unterstützung von Entscheidungen: Sind im Prozesstyp alternative Ausführungspfade vorgesehen, so sollen dem Anwender Hinweise (z.B. Lessons Learned und Best Practices) gegeben werden, die ihn bei der Entscheidungsfindung über die Auswahl des richtigen (passenden) Pfads unterstützen. Nachdem der Mitarbeiter eine Entscheidung getroffen hat, wie der Prozess fortgesetzt werden soll, muss diese im ProcessNavigator dokumentiert werden. Somit kann später nachvollzogen werden, warum eine bestimmte Entscheidung getroffen wurde und der Entwicklungsprozess wird insgesamt transparenter. #10 Unterstützung von Meilensteinen: Zur besseren Strukturierung des Entwicklungsprozesses muss das Prozessmanagementsystem Meilensteine unterstützen. Meilensteine markieren dabei das Ende einer Phase und damit einen Punkt im Entwicklungsprozess, an dem die Dokumente einen bestimmten Reifegrad erreicht haben. Nach Abschluss einer Phase sind sie gegenüber Änderungen genügend stabil, um in nachfolgenden Phasen, auf den dort beschriebenen Ergebnissen aufbauen zu können. In den Anforderungen #5 bis #10 werden verschiedene Informationsträger gefordert, die den Anwender während der Projektdurchführung unterstützen. In diesem Zusammenhang soll der Begriff „Kontext“ eingeführt werden. Dieser fasst all jene

72

4 Anforderungen an ein prozessbasiertes Informationssystem aus Anwendersicht

Informationen zusammen, die den Anwender (Entwickler) bei der Ausführung des Entwicklungsprojekts unterstützen können. Der Kontext eines wird im Entwicklungsprojekt durch verschiedene Parameter (z.B. aktuellen Prozessschritt, Projekt, Bearbeiter, Projektstatus etc.) bestimmt. Insgesamt muss das prozessbasierte Informationssystem zwei zentrale Aspekte in der Produktentwicklung umsetzen: 1. Information der Mitarbeiter über den Prozessablauf und die zu bearbeitenden Aufgaben; 2. Bereitstellung von Kontextinformationen, die den Anwender bei den gewählten Aufgaben unterstützen. Wichtig ist jedoch, dass das Informationssystem die Handlungsalternativen des Anwenders nicht einschränkt. Es muss sich jederzeit nach den Entscheidungen der Anwender reagieren und flexibel auf neue Situationen reagieren können 4.4

Durchführung von Projekten ohne IT-Unterstützung

Die Verwendung eines IT-Systems wird zwar an verschiedenen Stellen der QMStandards vorgeschlagen, aber nicht zwingend verlangt. Im Gegensatz zu den anderen Kapiteln dieser Arbeit wird daher in diesem Abschnitt nicht davon ausgegangen, dass ein integriertes IT-System zur Verfügung steht, welches die Anwender umfassend bei der Bearbeitung des Projekts unterstützt. Stattdessen soll kurz die Frage betrachtet werden, wie die Aufgaben der QM-Umsetzung alternativ (ohne ITSystem) erfüllt werden können. Dies ist auch deswegen interessant, da hiermit der Mehrwert des Prozessmanagementsystems gegenüber einer „manuellen“ Prozessausführung deutlich wird. Die Möglichkeiten der Umsetzung mit „Stift und Papier“ sind vielfältig und an dieser Stelle soll kein auf dieser „Technik“ aufbauendes QM-System entwickelt werden; aus diesem Grund werden stattdessen aus den Anforderungen die Kernaufgaben des Prozessmanagementsystems abgeleitet. Für diese wird exemplarisch gezeigt, wie diese Aufgaben ohne oder mit nur einfacher IT-Unterstützung umgesetzt werden können. Die Umsetzung der Anforderungen reicht von einer einfachen Tafel, auf der den Mitarbeitern Informationen bereitgestellt werden, über Emails bis hin zu Prozessportalen im Intranet [Wagner et Käfer 2008]. Der Übergang ist in vielen Fällen fließend und die Umsetzung hängt von den Gegebenheiten im Unternehmen ab. Ein kurzes, fiktives Fallbeispiel soll die Projektumsetzung ohne integriertes IT-System illustrieren:

4.4 Durchführung von Projekten ohne IT-Unterstützung

73

In einem Unternehmen wurde ein neues Projekt genehmigt. Für die Projektumsetzung existiert eine Prozessbeschreibung, welche alle notwendigen Arbeitsschritte umsetzt und auch im Unternehmen gelebt wird. Vor dem Start des Projekts erstellt der Projektleiter in einem Tabellenkalkulationsprogramm einen Projektplan und hängt diesen aus. Außerdem gibt es eine Checkliste mit Aufgaben, Meilensteinen und Terminen, auf denen die Mitarbeiter den Abschluss der Arbeitsschritte einer Aufgabe bzw. eines Meilensteins dokumentieren. Um sicherzustellen, dass alle Anforderungen des genutzten QM-Standards erfüllt werden, werden Checklisten gepflegt. Mitarbeiter informieren sich am Aushang über die anstehenden Aufgaben; außerdem werden Emails genutzt, um den aktuellen Projektstatus zu kommunizieren. Werden Hintergrundinformationen zu einem Arbeitsschritt gesucht, so wird die im Unternehmen vorhandene Literatur herangezogen (z.B. im Firmennetzwerk) bzw. im Internet nach weiteren Informationen gesucht. Im Unternehmen sind außerdem verschiedene Datenbanken vorhanden in denen Informationen zu verschiedenen Komponenten und Programmmodulen gespeichert sind, die die Mitarbeiter nutzen können. Neue Ideen zur Prozessverbesserung werden in einer Liste eingetragen, welche regelmäßig durch die Verantwortlichen kontrolliert wird. Außerdem werden an verschiedene Kennzahlen zur Messung der Prozessperformanz erhoben. Es ist klar, dass dieses Beispiel stark vereinfacht ist und nicht alle Facetten der Projektarbeit bzw. QM-Umsetzung darstellen kann. Jedoch wird deutlich, wie eine alternative Umsetzung aussehen kann. Anhand von vier Kernaufgaben, die sich aus den Anforderungen ableiten lassen, jedoch auch im Fallbeispiel enthalten sind, soll dies näher beleuchtet werden: x Die Koordination der Arbeitspakete und Mitarbeiter Aus der Anforderung #1 (Vorschlag der nächsten Arbeitspakete) und Anforderung #6 (Koordination der Arbeitspakete zwischen den Mitarbeitern) wird die Koordinationsaufgabe des Informationssystems abgeleitet. Es müssen sowohl die Arbeitspakete als auch die Projektmitarbeiter koordiniert und aufeinander abgestimmt werden. Wird diese Aufgabe nicht durch ein Prozessmanagementsystem unterstützt, so muss dies durch einen Projektleiter übernommen werden. Es ist klar, dass ein Prozessmanagementsystem niemals die komplette Planung und Koordination eines Projekts alleine durchführen kann; allerdings kann es dem Projektleiter wichtige Informationen für die Durchführung und Steuerung des Projekts bereitstellen und ihn damit entlasten.

74

4 Anforderungen an ein prozessbasiertes Informationssystem aus Anwendersicht

Alternativen zu einem Prozessmanagementsystem im Bezug auf die Koordinierung der Arbeitspakete sind die Tafel aus dem Fallbeispiel, oder beispielsweise Emails; diese Emails beinhalten Informationen über das aktuelle Arbeitspaket. Bei Entscheidungen der Mitarbeiter, dass Arbeitspakete ausgelassen, übersprungen oder erneut bearbeitet werden (Anforderungen #2, #3 und #4), muss der der Projektleiter informiert werden und gegebenenfalls zustimmen. x Bereitstellung von Kontextinformationen Die Anforderungen #5 (Bereitstellen von Informationen über den Arbeitsschritt), #7 (Bereitstellen von Dokumenten und Produktmodellen) und #8 (Unterstützung bei der Benutzung von Werkzeugen und Systemen) definieren eine Informationsbereitstellungsaufgabe. Der ProcessNavigator soll proaktiv (im Sinne von vorausschauend) benötigte Informationen zusammenstellen und den Anwendern anbieten. Wird diese Aufgabe nicht durch ein IT-System wahrgenommen, so müssen Anwender die notwendigen Aufgaben selbst aus verfügbaren Datenquellen (z.B. dem Internet, Büchern oder auch Kollegen) zusammensuchen. Als Ergebnis der Suche bekommen die Mitarbeiter hier eine Liste mit Orten, an denen Informationen hinterlegt sein können. x Integrierte Darstellung des Unternehmenswissens Eine weitere Aufgabe des Prozessmanagementsystems ist die Integration von Daten aus verschiedenen Datenquellen. Diese Aufgabe leitet sich etwa aus den Anforderungen #5 (Bereitstellen von Informationen über den Arbeitsschritt), #7 (Bereitstellen von Dokumenten und Produktmodellen) oder #9 (Unterstützung von Entscheidungen) ab und ist inhaltlich eng mit der Informationsbereitstellungsaufgabe verwandt. Die im Unternehmen verfügbaren Informationen (z.B. in Datenbanken) sollen den Anwendern an einer zentralen Stelle verfügbar gemacht werden. Notwendige Konvertierungsoperationen der Daten sollen durch das System automatisch durchgeführt werden. x Dokumentation der Prozessausführung Schließlich erfüllt das Prozessmanagementsystem auch eine Dokumentationsaufgabe. Dies ergibt sich aus der Notwendigkeit, die ordnungsgemäß Umsetzung der Anforderungen des QM-Standards im Assessment belegen zu müssen. Durch das Prozessmanagementsystem kann hier schon während der Durchführung des Prozesses die Verlinkung zu den Anforderungen des QMStandards hergestellt werden. Ohne IT-Unterstützung müsste dies durch die Mitarbeiter manuell geschehen. Die Mitarbeiter im Projekt müssten selbständig sicherstellen, dass die in den QM-Standards geforderten Arbeitsschritte und Dokumente erstellt werden und diese in einem Assessment auffindbar

4.4 Durchführung von Projekten ohne IT-Unterstützung

75

sind. Dies kann beispielsweise mittels Protokollen, Checklisten, oder als Annotation an den jeweiligen Dokumenten erfolgen. Im Unternehmen verschickte Emails mit Arbeitsanweisungen können archiviert werden um den genauen Ablauf besser nachvollziehen zu können. Auch das Erreichen eines Meilensteins, sowie die Entscheidung, ob mit dem Projekt fortgefahren wird (Anforderung #10) muss dokumentiert werden. In Abbildung 4-1 werden diese vier Aufgaben, die das Prozessmanagementsystem (in diesem Fall der ProcessNavigator) umzusetzen hat, in einer Übersicht dargestellt:

Arbeitspakete

Datenbanken

Koordination

Datenintegration

QM-Standard Mitarbeiter

Anforderungen

Unternehmenswissen

ProcessNavigator Werkzeuge Informationsbereitstellung

Dokumentation

Anwender Dokumente

Arbeitsabläufe

Umsetzung QMAnforderungen

Umsetzung im Unternehmen

Abbildung 4-1:

Aufgaben des Prozessmanagementsystems

Aus der Abbildung 4-1 wird ersichtlich, dass ohne den ProcessNavigator das zentrale Steuerungsinstrument für die Projektdurchführung fehlen würde und die Aufgaben durch Mitarbeiter übernommen werden müssen. Zwar kann auch ohne ITUnterstützung die Erfüllung der QM-Anforderung erreicht werden; dies würde jedoch erhöhten Aufwand für die Mitarbeiter bedeuten und auch die Möglichkeit für Fehler eröffnen.

Teil II Konzeption eines prozessbasierten Informationssystems für QM-Systeme

5

Entwurf eines Vorgehensmodells zur Umsetzung von QMAnforderungen

Die Erstellung und Pflege der Unternehmensprozesse bilden den Kern eines jeden QM-Systems, das den Anforderungen der ISO/IEC 15504 oder des CMMI genügen soll. Sie dokumentieren die Arbeitsschritte, die zur Entwicklung eines Produktes notwendig sind. Da sie einen Großteil des im Unternehmen vorhandenen Wissens zur Erstellung und Entwicklung von Produkten dokumentieren, müssen sie sorgfältig geplant, gepflegt und gemanagt werden. Diese Aktivitäten sind im Prozesslebenszyklus beschrieben, der den Lebenszyklus eines Prozesses von seiner Erstellung bis zu seinem Auslaufen definiert. Durch die beiden QM-Standards ISO/IEC 15504 und CMMI wird ein Rahmen vorgegeben, mit dem sich die Reife bzw. Qualität der Prozesse messen lässt. Qualität lässt sich jedoch nicht in einen Prozess hinein prüfen [Wagner et Käfer 2008]. Vielmehr muss der Prozess von Anfang an im Hinblick auf die späteren Qualitätsanforderungen geplant werden. Einfache Prozesslebenszyklen berücksichtigen zwar die Verbesserung von Prozessen; allerdings beschreiben sie den Einfluss, den QM-Standards wie etwa die ISO/IEC 15504 oder das CMMI auf Entwicklungsprozesse haben, nur unzureichend. Es fehlen dort beispielsweise Validierungsschritte und eine explizite Planung der Entwicklungsprojekte. In diesem Kapitel wird ein Vorgehensmodell entworfen, der den Einfluss von QMStandards berücksichtigt. Dabei wird von einem einfachen Prozesslebenszyklus ausgegangen und dieser an die Anforderungen der QM-Normen angepasst. 5.1

Einfacher Prozesslebenszyklus

Der wohl bekannteste Prozesslebenszyklus ist der Plan-Do-Check-Act-Kreis (PDCA) [Deming 1986; Wagner et Käfer 2008] oder Deming-Zyklus genannte Verbesserungskreis. Auf der dort beschriebenen Grundidee basiert ein Großteil der betrieblichen Verbesserungsansätze. Der PDCA-Zyklus besteht aus den folgenden Phasen: x Planen (Plan): Festlegen der Ziele und Planung des Prozesses; x Durchführen (Do): Umsetzung und Ausführung des Prozesses; x Prüfen (Check): Überwachung und Messung der Prozesse und Produkte; x Verbessern (Act): Ergreifen von Maßnahmen zur Verbesserung der Prozessleistung.

80

5 Entwurf eines Vorgehensmodells zur Umsetzung von QM-Anforderungen

Dieser Zyklus bildet die Grundlage für eine Vielzahl von Prozessverbesserungsansätzen und QM-Systemen. In ihm ist die Grundidee der Prozessverbesserung beschrieben: beginnend mit der Planung des Prozesses, über seine Implementierung, Messung und bis hin zur Verbesserung des ursprünglich geplanten Prozesses. In [Wagner et Käfer 2008] wird in Anlehnung an den oben beschriebenen PDCA-Zylus ein Lebenszyklus für Prozesse entworfen. In diesem Prozesslebenszyklus werden, ausgehend von einer langfristigen Vision auf normativer Ebene und den daraus entwickelten Umsetzungsstrategien auf der strategischen Ebene, Prozesse auf der operativen Ebene definiert. In Abbildung 5-1 ist dieser Lebenszyklus auf operativer Ebene dargestellt. Die Aufnahme von neuen Prozessen in die Prozesslandschaft erfolgt auf Basis der vorher definierten Strategie (Phase 1). In der nächsten Phase wird der neu in die Prozesslandschaft aufgenommene Prozess definiert und ausgearbeitet (Phase 2). In Phase 3 wird schließlich der definierte Prozess betrieben, überwacht und optimiert. Das Controlling (bzw. Monitoring) der Prozessausführung wird in Phase 4 durchgeführt. Hier ergeben sich Ansatzpunkte und Hinweise für eine Verbesserung der Prozesse, bzw. für die Aufnahme von neuen Prozessen in die Prozesslandschaft. Für eine detaillierte Beschreibung des Prozesslebenszyklus sei an dieser Stelle auf die zitierte Literatur verwiesen. Phase 1: Aufnahme und Integration

Prozesslandschaft Phase 4: Monitoring

Phase 2: Prozessdefinition

Phase 3: Betreiben, steuern und optimieren

Abbildung 5-1:

Prozesslebenszyklus (nach [Wagner et Käfer 2008])

Die Begriffe Controlling und Monitoring werden in der Literatur nicht einheitlich genutzt. Insbesondere darf das Prozess-Controlling nicht mit dem Finanz-Controlling verwechselt werden. In [zur Muehlen et Rosemann 2000] wird im Bezug auf das Controlling des Projekts zwischen operativem und strategischem Controlling unter-

5.2 Ein Vorgehensmodell zur Umsetzung von QM-Anforderungen

81

schieden. Das operative Controlling bezieht sich auf das Überwachen einer einzelnen Prozess- oder Workflow-Instanz; es wird auch Workflow- oder Prozess-Monitoring genannt. Strategisches Controlling hingegen bezeichnet das nachträgliche (ex-post) Controlling der abgeschlossenen Prozess- oder Workflow-Instanz mit statistischen Verfahren oder Data-Mining-Methoden. Entsprechend dieser Unterscheidung werden im Rahmen dieser Arbeit die beiden Begriffe Monitoring und Controlling wie folgt genutzt: Projekt-Monitoring oder Monitoring bezeichnet die in einem „kleinen“ Regelkreis beschriebene Rückkopplung von Laufzeitinformation zur Steuerung einer Prozessinstanz. Ziel ist es, während der Projektdurchführung Abweichungen von den Soll-Werten zu erkennen und korrigierend einzugreifen. Der Regelkreis umfasst hier nur die Phase 3. Controlling bezeichnet die ex-post Analyse der Ausführungsinformationen und die in einem „großen“ Regelkreis beschriebene Rückkopplung. Ziel ist es nach der Durchführung eines Projekts Informationen und Verbesserungsvorschläge für nachfolgende Projekte zu erhalten. Der Regelkreis geht hier über die Phase 3 hinaus und wirkt sich in Phase 4 aus. Auch wenn die im Prozesslebenszyklus enthaltenen Phasen nicht genau mit denen des PDCA-Zyklus übereinstimmen, so folgt er doch dessen Grundidee. Im Anschluss an die Definition der Prozesse werden diese betrieben, überwacht und schließlich optimiert. Somit erfüllt der beschriebene Prozesslebenszyklus die grundsätzlichen Anforderungen (planen – ausführen – messen – verbessern) eines Ansatzes zur Verbesserung der Unternehmensprozesse. Im Bezug auf die im Kapitel 3 definierten Anforderungen ist der Prozesslebenszyklus jedoch nicht detailliert genug. Insbesondere fehlen Phasen zur Validierung des erstellten Prozesstyps (aQM2 Ziele des RG1) und ein explizites Tailoring der Prozesse an die Erfordernisse der Projekte (aQM2 Ziele der RG2 und RG3). 5.2

Ein Vorgehensmodell zur Umsetzung von QM-Anforderungen

Um die im aQM2 aufgestellten Anforderungen umsetzen zu können, wird der einfache Prozesslebenszyklus aus Abbildung 5-1 durch einen erweiterten Prozesslebenszyklus ersetzt (Abbildung 5-2). Die bisher vorhandene Phase 1 (Aufnahme und Integration von Prozessen in die Prozesslandschaft) und die Phase 4 (Controlling) werden im Wesentlichen übernommen. Beide Phasen beziehen sich auf die Verwaltung und Überwachung der vorhandenen Prozesse. Die Phase 4 wird im Vergleich zum einfachen Prozesslebenszyklus lediglich um eine Assessment-Unterstützung er-

82

5 Entwurf eines Vorgehensmodells zur Umsetzung von QM-Anforderungen

weitert, die im Hinblick auf die in den QM-Standards vorhandenen Assessments von Bedeutung ist. Phase 1: Aufnahme und Integration Prozesslandschaft Phase 4: Controlling & Assessment-Unterstützung

Phase 2: Prozessdefinition

Phase 2: Prozessdefinition Phase 2.1: Erstellung des Prozesstyps

Phase 2.2: Prozessvalidierung

Phase 3: Betreiben, steuern und optimieren

9

Phase 3 : Projektdurchführung Phase 3.1: Projektbearbeitung

Phase 3.2: Projektmonitoring

8 9

9

8

Phase NEU: Projektdefinition Phase NEU.1: Erstellung des Projektplans

Phase NEU.2: Projektvalidierung

9

Abbildung 5-2:

9

9

8

Ergänzung des Prozesslebenszyklus um neue Phasen

Die Phasen 2 und 3 werden hingegen erweitert, so dass sie die in QM-Standards beschriebenen Anforderungen unterstützen. Dazu wird die bisher im einfachen Prozesslebenszyklus vorhandene Phase 2 in zwei neue Unterphasen, eine Definitionsund eine Validierungsphase, aufgeteilt; außerdem wird ein explizites Tailoring der Prozesse in Projekte neu eingeführt und die anschließende Projektdurchführung wird unterstützt (Phase 3). Phase 2.1 übernimmt die Aufgabe der Prozessdefinition und ist damit identisch mit der Phase 2 des einfachen Lebenszyklus. Mit der Phase 2.2 wird der Prozessdefinition ein expliziter Analyse- und Validierungsschritt nachgeschaltet, um sicherzugehen, dass in der Prozessdefinition alle Anforderungen der QM-Normen berücksichtigt wurden. Die vorhandene Phase 3 wird ebenfalls in zwei Unterphasen aufgespalten. Während in Phase 3.1 die Bearbeitung des Projekts (= ausgeführter Prozess) behandelt wird, liegt die Aufgabe der Phase 3.2 auf einem Monitoring und der Steuerung des Projekts. Damit werden die beiden vorher in einer Phase zusammengefassten Aufgaben in zwei getrennte Phasen aufgeteilt. Wichtig ist zu erwähnen, dass die beiden Phasen 3.1 und 3.2 nicht aufeinanderfolgend, sondern parallel

5.2 Ein Vorgehensmodell zur Umsetzung von QM-Anforderungen

83

ausgeführt werden. Somit kann das Projektmonitoring jederzeit aktiv in die Projektdurchführung eingreifen und Abweichungen von einem vorher definierten Soll korrigieren. Zwischen den beiden Phasen 2 und 3 wird zusätzlich eine weitere, neue Phase eingefügt. Diese wird in Abbildung 5-2 als Phase NEU (mit einer Unterteilung in NEU.1 und NEU.2) bezeichnet. In der Erstellung des Projektplans wird aus dem validierten Prozesstyp ein Projekttyp erstellt. In der Projektvalidierung wird nach der Erstellung des Projektplans überprüft, ob der Projektplan alle Anforderungen des QM-Modells umsetzt. Mit der Projektdefinition ist nun im Prozesslebenszyklus eine explizites Tailoring des Prozesstyps entsprechend der in Kapitel 3 beschriebenen Anforderungen für eine Ausführungsumgebung vorhanden. Nach der Neunummerierung der Phasen ergibt sich der in Abbildung 5-3 dargestellte Vorgehensmodell. Diese Phasen und die Umsetzung der Anforderungen des aQM2 werden in den nachfolgenden Kapiteln detailliert beschrieben. Phase 1: Aufnahme und Integration

Prozesslandschaft

Phase 5: Controlling & Assessment-Unterstützung

Phase 2: Prozessdefinition Phase 2.1: Erstellung des Prozesstyps

Phase 2.2: Prozessvalidierung

Vorgehensmodell zur QM-Umsetzung Phase 4: Projektdurchführung Phase 4.1: Projektbearbeitung

Phase 4.2: Projektmonitoring

8 9

9 9

8

Phase 3: Projektdefinition Phase 3.1: Erstellung des Projektplans

Phase 3.2: Projektvalidierung 8 9 9

9

Abbildung 5-3:

Vorgehensmodell zur Umsetzung von QM-Anforderungen

Die Phasen 2-4 von der Definition des Prozesstyps bis zur Ausführung des Projekttyps können jeweils in einen Konstruktionsteil (Erstellung des Modells bzw. Umsetzung des Projekts) und einen Analyseteil (Validierung bzw. Monitoring) unterteilt werden.

84

5 Entwurf eines Vorgehensmodells zur Umsetzung von QM-Anforderungen

In der Konstruktion wird jeweils das Produkt (Prozesstyp, Projekttyp bzw. Artefakte) erstellt, welches anschließend in der Analyse hinsichtlich der Umsetzung von Anforderungen aus dem QM-System bzw. hinsichtlich der im Projektplan definierten SollVorgaben untersucht wird. Somit kann jede einzelne Phase hinsichtlich der Umsetzung der Vorgaben aus dem QM-System abgesichert werden. Die folgenden Kapitel 7 bis 10 diskutieren die Phasen des Vorgehensmodells abbilden: 1. Aufnahme, Integration und Prozessdefinition (Phase 1 und 2) p Kapitel 7 2. Projektdefinition (Phase 3) p Kapitel 8 3. Projektdurchführung (Phase 4) p Kapitel 9 4. Controlling und Assessment-Unterstützung (Phase 5) p Kapitel 10 Durch die beschriebenen Phasen ist das Vorgehensmodell zur Umsetzung von QMAnforderungen vollständig beschrieben. Er erweitert den einfachen Prozesslebenszyklus insbesondere um eine Phase zur expliziten Planung von Projekten. Dieser Punkt ist ein wesentlicher Bestandteil der beiden QM-Standards ISO/IEC 15504 und CMMI und ist im einfachen Prozesslebenszyklus nicht vorhanden.

6

Ausblick: Umsetzung der QM-Anforderungen im ProcessNavigator

In den folgenden Kapiteln 7 bis 11 werden die einzelnen Phasen des Vorgehensmodells zur Umsetzung von QM-Anforderungen vorgestellt. Bevor diese Detailbetrachtung im nächsten Kapitel beginnt, soll an dieser Stelle vorab ein Ausblick auf die Umsetzung der Ziele des aQM2 im ProcessNavigator gegeben werden. Bei der Entwicklung eines Konzepts, das alle Reifegradstufen von RG1 bis RG5 abdeckt, ist es nicht sinnvoll die einzelnen Ziele in der Reihenfolge der Reifegradstufen umzusetzen. Ein Beispiel das dies verdeutlicht, ist das Ziel, im Unternehmen einen Standardprozess zu etablieren (Ziel 3.1). Dieses wird im aQM2 erst auf RG3 gefordert. Im Vorgehensmodell zur Umsetzung von QM-Anforderungen (Kapitel 5) zeigt sich jedoch, dass dies in einem Konzept, welches alle Reifegradstufen betrachtet, schon zu Beginn des Prozesslebenszyklus erfolgen muss. In Tabelle 6-1 bis Tabelle 6-5 wird deshalb gezeigt, in welchen Phasen des Vorgehensmodells die einzelnen Ziele adressiert werden. Es wird außerdem ein kurzer Ausblick auf die Art der Umsetzung im ProcessNavigator gegeben. Tabelle 6-1:

Umsetzung der Anforderungen des aQM2 RG1

RG 1 Ziel

Beschreibung

Ziel 1.1

Umsetzen der Prozessschritte

Ziel 1.2

Umsetzung im Vorgehensmodell

Phase 2.2 Prozessvalidierung, Phase 3.2 ProjektErstellen der validierung sowie geforderten Arbeitsergebnisse Phase 4.1 Projektbearbeitung

Art der Umsetzung Validierung der Prozesstypen und des Projekttyps im Hinblick auf eine Umsetzung der geforderten Praktiken und Arbeitsprodukte sowie die Ausführungsunterstützung im ProcessNavigator

Die Anforderungen des RG1 verlangen die Umsetzung der im Standard genannten Prozessschritte und das Erstellen der Arbeitsergebnisse. Diese Forderungen ziehen sich durch die ersten vier Phasen des Vorgehensmodells zur Umsetzung von QMAnforderungen, von der Identifikation der Prozesse bis zu ihrer Ausführung (Tabelle 6-1). Die Validierung, ob die geforderten Prozesse auch tatsächlich enthalten sind,

86

6 Ausblick: Umsetzung der QM-Anforderungen im ProcessNavigator

geschieht erstmals nach der Definition der Prozesstypen zum Abschluss von Phase 2 und erneut nach der Erstellung des Projekttyps in Phase 3. Während der Prozessausführung (Phase 4) stellt das Ausführungssystem ProcessNavigator sicher, dass keine Prozesse unbeabsichtigt ausgelassen werden, indem das System die Mitarbeiter über Prozessschritte und zu erstellende Dokumente informiert. Die Ziele des RG2 befassten sich vor allem mit der ordnungsgemäßen Planung und Durchführung des Softwareentwicklungsprojekts (Tabelle 6-2). Die dazu notwendigen Aufgaben und Arbeitsschritte sind in Phase 3.1 (Projektplanung) durchzuführen. Das Projekt muss vom Projektleiter geplant werden; seine Ziele und die Entscheidungsbefugnisse der Mitarbeiter müssen festgelegt werden. Ressourcen für die Bearbeitung der einzelnen Aufgaben müssen festgelegt und geeignete Kommunikationskanäle definiert werden. Für die im Projekt zu erstellenden Arbeitsergebnisse müssen quantitative und qualitative Ziele angegeben werden. Diese Aufgaben müssen mit der Erstellung des Projektplans abgeschlossen sein. Tabelle 6-2:

Umsetzung der Anforderungen des aQM2 RG2

RG 2 Ziel

Beschreibung

Umsetzung im Vorgehensmodell

Art der Umsetzung

Ziel 2.1

Planung des Projekts

Entwicklung des Projekttyps aus dem Prozesstyp

Ziel 2.2

Definition von Zielen und Entscheidungsbefugnissen für die Prozessausführung

Phase 3.1 Erstellung des Projektplans

Ziel 2.3

Allokation von Ressourcen

Festlegen des Organisatorischen und Operationalen Aspekts im Projekttyp

Ziel 2.4

Definition der Schnittstellen zwischen Parteien

Festlegung von Besprechungsterminen und E-Mail-Verteilern im Projektplan

Festlegung von Zielen und Entscheidungsbefugnissen im Projektplan

6 Ausblick: Umsetzung der QM-Anforderungen im ProcessNavigator

87

RG 2 Ziel

Beschreibung

Umsetzung im Vorgehensmodell

Art der Umsetzung

Ziel 2.5

Definition der Anforderungen an Arbeitsprodukte

Phase 3.1 Erstellung des Projektplans

Ergänzung der im Prozesstyp vorhandenen Daten um quantitative und qualitative Ziele

Ziel 2.6

Überwachung und Steuerung des Projekts

Ziel 2.7

Überwachung und Korrektur der Arbeitsprodukte

Phase 4.1 Projektbearbeitung und Phase 4.2 Projektmonitoring

Ausführungsunterstützung im ProcessNavigator sowie Monitoring des Projekts und der Arbeitsergebnisse

Währen der Prozessausführung (Phase 4.1) und beim Monitoring (Phase 4.2) wird die Ausführung des Projekts durch den ProcessNavigator unterstützt. Durch diese Ausführungsunterstützung liegen im ProcessNavigator jederzeit Informationen über den Ausführungsstand der einzelnen Arbeitsschritte und ihrer Arbeitsergebnisse vor. Diese können vom Projektleiter genutzt werden, um den aktuellen Bearbeitungszustand zu verfolgen und bei Abweichungen steuernd eingreifen zu können. Tabelle 6-3:

Umsetzung der Anforderungen des aQM2 RG3

RG 3 Ziel

Beschreibung

Ziel 3.1

Aufstellung eines Standardprozesses und seiner Schnittstellen

Ziel 3.2

Umsetzung im Vorgehensmodell

Phase 2.1 Erstellung des Prozesstyps und Phase 2.2 ProzessFestlegen der Zuständigkeiten, Verantwortlichkei- validierung ten und der nötigen Infrastruktur im Standardprozess

Art der Umsetzung Definition der Prozesstypen Definition des Organisatorischen und Operationalen Aspekts im Prozesstyp

88

6 Ausblick: Umsetzung der QM-Anforderungen im ProcessNavigator

RG 3 Ziel

Beschreibung

Umsetzung im Vorgehensmodell

Art der Umsetzung

Ziel 3.3

Ableitung eines Projekts aus dem Standardprozess

Ziel 3.4

Festlegung der im Projekt eingesetzten Verantwortlichkeiten und der Infrastruktur

Phase 3.1 Erstellung des Projektplans

Tailoring des Projekttyps aus dem StandardProzesstyp

Ziel 3.5

Definition von Methoden zur Messung des Standardprozesses

Ziel 3.6

Erfassung der Daten und Ermitteln von Verbesserungspotenzialen

Festlegung von Kennzahlen, die im Projekt ermittelt werden sollen Phase 4.1 Projektbearbeitung und Phase 4.2 Projektmonitoring

Erhebung von Messdaten im ProcessNavigator

Auf RG3 wird die Etablierung eines Standardprozesses im Unternehmen verfolgt und mittels der verschiedenen Ziele überprüft (Tabelle 6-3). Die Umsetzung der Ziele ist über die Phasen 2 (Prozessdefinition), 3 (Projektdefinition) und 4 (Projektdurchführung) des Vorgehensmodells zur QM-Umsetzung verteilt. In Phase 2.1 (Erstellung des Prozesstyps) und Phase 2.2 (Prozessvalidierung) werden mit der Definition der Prozesstypen die Grundlagen für die Etablierung eines Standardprozesses im Unternehmen gelegt. Der Prozesstyp kann nach seiner Erstellung und Validierung als Ausgangsbasis für die Erstellung des Projekttyps genutzt werden. In Phase 3.1 (Erstellung des Projektplans) wird der Prozesstyp durch ein ProzessTailoring in einen Projekttyp abgeleitet. Dabei ist es wichtig, dass dieses Tailoring systematisch und basierend auf vorher festgelegten Regeln durchgeführt wird. Es muss eine geeignete Projektinfrastruktur bereitgestellt und die Verantwortlichkeiten im Projekt festgelegt werden. Zur Messung des Prozesses sind geeignete Methoden zu definieren. Der ProcessNavigator unterstützt die Durchführung des auf einem Standardprozess basierenden Projekts durch die Bereitstellung von Informationen für die Mitarbeiter.

6 Ausblick: Umsetzung der QM-Anforderungen im ProcessNavigator

89

Hierfür wird die gleiche Infrastruktur genutzt wie auf RG1 und RG2. Im Vergleich zu diesen beiden Reifegraden werden die während der Projektdurchführung gesammelten Daten genutzt, um Verbesserungspotenziale für den Standardprozess zu erfassen. Tabelle 6-4:

Umsetzung der Anforderungen des aQM2 RG4

RG 4 Ziel

Beschreibung

Art der Umsetzung

Ziel 4.1 Definition von quantitativen Zielen für die Messungen

Umsetzung durch die Define, Measure, Analyze, Improve und Ziel 4.2 Identifikation von Messpunk- Control Phasen des Six Sigma Ansatzes. ten für Prozess und Produkt Ziel 4.3 Sammeln und Erfassen von Messdaten Ziel 4.4 Überwachung des Projekts und statistische Analyse der Messdaten Ziel 4.5 Erarbeitung von Korrekturmaßnahmen und Steuerung des Projekts

Für die Umsetzung der beiden Reifegradebenen RG4 (Tabelle 6-4) und RG5 (Tabelle 6-5) wird das im Six Sigma Ansatz [Töpfer 2004] festgelegte methodische Vorgehen genutzt. Dieses setzt sich aus den Phasen Define, Measure, Analyze, Improve und Control zusammen, die zusammen den sogenannten DMAIC-Zyklus ergeben (vgl. Kapitel 11). Six Sigma ist ein etabliertes Vorgehen zur Verbesserung der Prozess- und Produktqualität. Im Gegensatz zu ISO/IEC 15504 und CMMI legt Six Sigma keine Anforderungen fest, sondern beschreibt ein strukturiertes Vorgehen zur Messung und Verbesserung der Prozesse. Damit ergänzt es die beiden QM-Standards und bildet das methodische Grundgerüst zur Umsetzung der Ziele auf RG 4.

90

6 Ausblick: Umsetzung der QM-Anforderungen im ProcessNavigator

Tabelle 6-5:

Umsetzung der Anforderungen des aQM2 RG5

RG 5 Ziel

Beschreibung

Ziel 5.1 Definition der strategischen Verbesserungsziele Ziel 5.2 Analyse der Daten

Art der Umsetzung Umsetzung durch die Define, Measure, Analyze, Improve und Control Phasen des Six Sigma Ansatzes.

Ziel 5.3 Identifikation von Gründen für Abweichungen Ziel 5.4 Erarbeiten von Verbesserungsmöglichkeiten Ziel 5.5 Entwickeln einer Umsetzungsstrategie

Umsetzung durch die Define, Measure, Analyze, Improve und Control Phasen des Six Sigma Ansatzes.

Ziel 5.6 Umsetzen der Verbesserungen Ziel 5.7 Untersuchen der Effektivität der Verbesserungen

Der Six Sigma Ansatz kann genutzt werden, um die Anforderungen der RG4 und RG5 umzusetzen. Wobei bei RG4 der Fokus darauf liegt, einen Prozess vorhersagbar auszuführen, mögliche Abweichungen frühzeitig zu identifizieren und entsprechend gegenzusteuern. Auf RG5 werden die gesammelten Daten genutzt, um systematisch Verbesserungspotenziale aufzudecken und diese anschließend im Unternehmen umzusetzen.

7

Erstellung einer validierten Prozesslandschaft

Der erste Schritt zur Umsetzung eines prozessorientierten QM-Systems ist die Definition der Sollprozesse in der Prozesslandschaft. Hier wird das grundsätzliche Vorgehen zur Entwicklung von Produkten, einer Dienstleistung sowie der dazu notwendigen unterstützenden Tätigkeiten definiert. Ziel der Definition der Prozesslandschaft ist es, die im Unternehmen vorhandenen Vorgänge und Prozesse zu definieren und klar zu beschreiben. Das in diesem Kapitel beschriebene Vorgehen umfasst die Phasen 1 und 2 des Vorgehensmodells zur QM-Umsetzung (Kapitel 5). 7.1

Das Prozess-Meta-Modell

Die Prozesse der Prozesslandschaft können grundsätzlich mit jeder Prozessmodellierungssprache modelliert werden. Wenn es jedoch geplant ist, die Prozesse in einem IT-System weiter auszuwerten, so muss dies durch die Sprache (diese muss eine eindeutige Syntax besitzen) und das Modellierungswerkzeug (die Auslesbarkeit der Modelle muss gewährleistet sein) unterstützt werden. Das Werkzeug i>PM [Handbuch iPM Integrated Process Manager 2005] zur Modellierung von Prozessen in der Aspektorientierte Prozessmodellierung (AOPM) [Jablonski et Bussler 1996] erfüllt diese Anforderungen und wird aus diesem Grund in dieser Arbeit verwendet. Ein wichtiger Vorteil dieses Ansatzes ist es, dass er sich einfach erweitern und an neue Erfordernisse anpassen lässt [Meiler 2005]; diese Eigenschaft wird in Kapitel 8 genutzt, um die Modellierung von Projekttypen zu ermöglichen. Die Nutzung der AOPM stellt jedoch keine Einschränkung des Gesamtansatzes dar und die beschriebenen Konzepte können ohne weiteres auch auf andere Modellierungssprachen übertragen werden. Als alternatives Modellierungswerkzeug sei hier das Werkzeug ARIS [IDS Scheer 2009] zur Modellierung von Ereignisgesteuerten Prozessketten (EPKs) [Scheer 2000] genannt. Die einsetzbaren Prozessmodellierungselemente werden durch das Meta-Modell festgelegt, welches in Abbildung 7-1 dargestellt ist. In der Darstellung sind die beiden Meta-Ebenen M2 und M3 abgebildet. Die Ebene M3 legt das in der AOPM genutzte graphenorientierte Modellierungsprinzip fest. Entsprechend können im Prozesstyp verschiedene Knoten verwendet werden, die durch Kanten (Flüsse) miteinander verbunden werden. Flüsse werden durch Ports an einen Knoten angebunden. Durch das Modellierungsmuster Powertypes [Henderson-Sellers et Gonzalez-Perez 2006; ISO/IEC 24744:2007 ; Odell 1998] werden Knoten, Ports und Flüsse in verschiedene Knotenarten, Portarten und Flussarten partitioniert. Auf diese Weise können die

92

7 Erstellung einer validierten Prozesslandschaft

Eigenschaften der einzelnen Knotenarten, Portarten und Flussarten im Modell bestimmt werden. anhänge *

Knotenanhang

aggregierter Knoten *

Datenquelle

Datenquelle

Knoten

Eingangsports Ausgangsports*

1 Quelle Ziel 1

Port

partitioniert

Knotenart

Fluss

1

* partitioniert

fließt *

partitioniert

Portart

Flussart

M3 M2 <>

<>

<>

Kontrollfluss Prozessschritt

Konnektor

Datenfluss

Entscheider Konnektor

Logischer Konnektor

Anwendung Organisation

StartInterface StopInterface

Abbildung 7-1:

AND

OR

XOR

Datencontainer Datenreferenz

Prozess-Meta-Modell auf den Ebenen M2 und M3 [Jablonski et al. 2009c]

Auf Ebene M2 werden Knotenarten, Portarten und Flussarten in die eigentlichen Modellierungselemente der Sprache instanziiert. Diese können dann zur Modellierung des Prozesstyps genutzt werden. Auf diese Weise entstehen die Modellierungselemente Prozessschritt, Kontrollfluss, Datenfluss sowie Anwendung, Organisation und Datencontainer. Über die Beziehungen auf der übergeordneten Ebene M3 wird festgelegt, dass zwei Prozesse durch einen Daten- oder Kontrollfluss miteinander verbunden werden können. Für eine vollständige Beschreibung des Meta-Modells wird auf [Jablonski et al. 2008; Jablonski et al. 2009a; Jablonski et al. 2009c] verwiesen. In Tabelle 7-1 werden die in dieser Arbeit genutzten Modellierungselemente zusammenfassend dargestellt. Mit diesen Elementen kann ein vollständiger Prozesstyp erstellt werden, wie in Abbildung 7-4 dargestellt. Im Funktionalen Aspekt sind hier Prozessschritte zur Darstellung der einzelnen Arbeitspakete im Entwicklungsprozess enthalten. Diese können in einer Phase gruppiert werden, die mit einem Meilenstein abgeschlossen wird. Im Verhaltensorientierten Aspekt sind Kontrollflüsse, Entscheider

7.2 Phase 1: Identifikation der Prozesstypen

93

und Konnektoren zur Bestimmung der Abläufe zwischen den Arbeitspaketen und den Markierungen Start- bzw. StopInterface enthalten. Daten werden im Prozesstyp durch Datencontainer modelliert; Organisationen und Anwendungen komplettieren den Prozesstyp. Durch das Prozess-Meta-Modell wird die Modellierungssprache festgelegt, mit der Prozesse modelliert werden können. Sie bildet damit die Grundlage für die in den späteren Phasen entwickelten Methoden und Werkzeuge. Tabelle 7-1:

Elemente des Prozessmodells

Aspekte Funktionaler Aspekt

Verhaltensorientierter Aspekt

Datenorientierter Aspekt

Organisatorischer Operationaler Aspekt Aspekt

Phase

Kontrollfluss

Datenfluss

Organisation

Meilenstein

Entscheider

Datencontainer

Prozessbaustein (Arbeitspaket)

Logische Konnektoren (AND, OR, XOR)

Anwendung (Werkzeug)

Start- und StopInterface Externer Einund Ausgang

7.2

Phase 1: Identifikation der Prozesstypen

Voraussetzung für ein erfolgreiches Prozessmanagement und die erfolgreiche Umsetzung von QM-Maßnahmen ist, dass im Unternehmen Prozesse zielführend (bezogen auf die strategischen Unternehmensziele) eingesetzt werden. In der Literatur werden zwei Basisansätze zur Identifizierung von Prozessen beschrieben [Schmelzer et Sesselmann 2008; Thomas et McGarry 1994]: der Top-Down und der Bottom-Up-Ansatz. Der Bottom-Up-Ansatz geht dabei von einer Ist-Analyse der betroffenen Prozesse aus und definiert für jeden im Unternehmen gefundenen Prozess einen Eintrag in der Prozesslandschaft.

94

7 Erstellung einer validierten Prozesslandschaft

Beim Top-down-Ansatz werden im Gegensatz zum Bottom-up-Ansatz die Prozesse ausgehend von den strategischen Zielen des Unternehmens ausgewählt. Für die Identifikation von Prozessen nach dem Top-down-Ansatz muss sich das Unternehmen über seine Ziele, seine Mission und seine Strategie im Klaren sein. Entsprechend dieser Ziele müssen alle Aktivitäten des Unternehmens ausgerichtet werden. Um nachhaltig und sinnvoll in das Unternehmen integriert werden zu können, müssen die Prozesse somit die Unternehmensziele unterstützen und dürfen ihnen nicht widersprechen. Wagner und Käfer schlagen in [Wagner et Käfer 2008] mit der 4-Schritte-Methode eine Kombination des Top-down-Ansatzes mit dem Bottom-up-Ansatz vor. Dabei werden die Prozesse (Einträge in der Prozesslandschaft) Top-down identifiziert und anschließend nach dem Bottom-up-Verfahren ausgehend von einer Ist-Analyse definiert: x Schritt 1: Prozessidentifikation und Abgrenzung; x Schritt 2: Analyse der Ist-Prozesse; x Schritt 3: Konzeption der Soll-Prozesse; x (Schritt 4: Realisierung des Verbesserungspotenzials). Die ersten drei Schritte der 4-Schritte Methode können direkt übernommen werden. Sie beginnen mit der Identifikation der Prozesse in der Prozesslandschaft und schließen mit einer Konzeption der Soll-Prozesse ab. Mit dem vierten Schritt wird jedoch schon die Umsetzung und Ausführung der definierten Prozesse im Unternehmen angesprochen. Da jedoch im Vorgehensmodell zur QM-Umsetzung vor der Ausführung der Prozesse erst die Erstellung des Projektplans vorgesehen ist, wird die 4-Schritte-Methode nach Abschluss der Soll-Prozess-Konzeption abgebrochen. Zur Klassifikation der Prozesse werden in der 4-Schritte-Methode die vier Prozessklassen „Management-Prozesse“, „Geschäftsprozesse“, „Unterstützungsprozesse“ und „Prozesse zur Messung, Analyse und Verbesserung“ eingeführt. Eine alternative Klassifikation der in der Prozesslandschaft vorhandenen Prozesse ist in der ISO/IEC 15504 zu finden. Dort findet eine Einteilung der Prozesse in „Primäre Lebenszyklusprozesse“, „Organisatorische Prozesse“ und „Unterstützungsprozesse“ statt. Im Folgenden sollen vor allem die Geschäftsprozesse (Primäre Lebenszyklusprozesse) betrachtet werden, da diese den wesentlichen Teil zu der Entstehung der Produkte oder Dienstleistungen beitragen. Die anderen Prozessfelder unterstützen die im Geschäftsprozess vorhandenen Aktivitäten.

7.3 Phase 2.1: Definition der Prozesstypen

95

Management-Prozesse Strategisch planen Unternehmen organisieren

Unternehmen steuern

Operativ planen

Controlling betreiben

Personal entwicklen

Kommunikation durchführen

Marketing durchführen

Produkte / Kunden

Kunden / Anforderungen

Geschäftsprozesse

Softwareentwicklungsprozess

Produkt managen

Unterstützungsprozesse Beschaffung durchführen

IT zur Verfügung stellen

Infrastruktur zur Verfügung stellen

Lager bewirtschaften

Administration durchführen

Prüfmittel überwachen

Abfallwirtschaft betreiben

Interne Audits durchführen

Kontinuierlich verbessern

Messung, Analyse und Verbesserung Kundenzufriedenheit ermitteln

Abbildung 7-2:

Prozesse messen

Prozesslandschaft (nach [Wagner et Käfer 2008])

Abbildung 7-2 zeigt die entsprechende Prozesslandschaft mit der Unterteilung in die verschiedenen Prozessklassen. Im oberen Bereich sind Management-Prozesse dargestellt (z.B. Strategisch planen, Unternehmen steuern etc.); im unteren Bereich der Prozesslandschaft sind die Unterstützungsprozesse und solche zur Messung, Analyse und Verbesserung eingetragen. Der Bereich Geschäftsprozesse umfasst alle Prozesse, die direkt zur Produktentstehung beitragen. Als Grundlage für den Produktentwicklungsprozess wurde ein an das V-Modell XT [Höhn et Höppner 2008; VModell XT (Version 1.3)] angelehnter Softwareentwicklungsprozess gewählt. Dieser umfasst, wie in Abschnitt 2.2 gezeigt, schon einen wesentlichen Teil der Anforderungen aus den QM-Normen ISO/IEC 15504 bzw. CMMI und bildet damit für die Softwareentwicklung eine gute Ausgangsbasis. Für die Bereiche Management-Prozesse, Unterstützungsprozesse und Messprozesse werden Prozesse so ausgewählt, dass sowohl alle Unternehmensziele als auch alle relevanten Prozessgruppen (bzw. Spezifischen Ziele) der ISO/IEC 15504 (des CMMI) durch jeweils einen Prozesseintrag abgedeckt werden. 7.3

Phase 2.1: Definition der Prozesstypen

Nach der Identifikation der Prozesse (Phase 1 des Vorgehensmodells) startet mit der Modellierung der Prozesstypen die Phase 2.1. Jeder Eintrag in der Prozesslandschaft

96

7 Erstellung einer validierten Prozesslandschaft

wird durch einen Prozesstypen [Böhm 2000] repräsentiert. Zur Modellierung der Prozesse wird die AOPM verwendet. Dieser Ansatz zeichnet sich dadurch aus, dass in ihm alle Anforderungen an einen Unternehmensprozess in einem integrierten Modell abgebildet werden können und dieser auch durch seine Strukturierung einfach erweitert werden kann. In dem Modellierungsansatz werden die verschiedenen Sichten, die sich auf einen Prozess ergeben, jeweils als ein eigenständiger Aspekt (= Blickwinkel auf den Prozess) dargestellt. Jede dieser Aspekte bildet ein eigenes Modell und ergibt kombiniert mit den anderen Aspekten das gesamte Prozessmodell. Die Basis des Modells bilden die folgenden fünf Aspekte: x Funktionaler Aspekt Der Funktionale Aspekt beschreibt den strukturellen Aufbau des Prozessmodells. Ihr wichtigster Bestandteil sind Prozessschritte. Diese können wiederum aus weiteren Prozessschritten bestehen und bilden dann komposite Prozessschritte. x Verhaltensbezogener Aspekt Dieser definiert die kausale Abfolge der Arbeitsschritte. Im Wesentlichen werden also die Vorgänger- und Nachfolgebeziehungen zwischen den Arbeitsschritten definiert und Entscheidungen formuliert. x Datenorientierter Aspekt Dieser Aspekt definiert die Daten oder Produktmodelle, die im Produktentwicklungsprozess genutzt werden. Hierunter werden alle Daten oder Informationen (z.B. Angebotsdokumente, Skizzen, CAD-Dokument etc.) verstanden, die im Entwicklungsprozess genutzt werden. Außerdem wird beschrieben, in welchen Arbeitsschritten ein Dokument erstellt wird und wo es als Eingangsdokument benötigt wird. Somit definiert der Datenorientierte Aspekt auch den Datenfluss im Prozess. x Organisatorischer Aspekt Er beschreibt, wer in einem Prozessschritt für die Ausführung der darin beschriebenen Arbeiten verantwortlich ist. x Operationaler Aspekt Dieser Aspekt beschreibt die im Prozess zum Einsatz kommenden Werkzeuge und Systeme. In der Produktentwicklung sind dies beispielsweise CAD Programme, FEM Programme etc. Für eine ausführliche Betrachtung der AOPM sei auf [Jablonski et Bussler 1996] verwiesen; dort werden die fünf vorgestellten Basisaspekte ausführlich diskutiert.

7.3 Phase 2.1: Definition der Prozesstypen

97

Wenn die fünf Basisaspekte nicht ausreichen, um die Anforderungen des Unternehmens in ein Prozessmodell abzubilden, so kann die AOPM durch die Anpassung des Prozess-Meta-Modells einfach erweitert und angepasst werden. Auch soll auf das grundsätzliche Vorgehen zur Erstellung von Prozesstypen und das Prozessdesgin nicht weiter eingegangen werden, stattdessen wird auf die entsprechenden Arbeiten [Böhm 2000] bzw. [Jablonski et Meerkamm 2009] verwiesen. Für die Modellierung von Entwicklungsprozessen wird der Funktionale Aspekt in zwei Ebenen gegliedert: eine Ebene zur Modellierung der Prozessphasen und eine zur Modellierung der Arbeitspakete. In der Phasendarstellung werden die groben Schritte dargestellt, die nötig sind, um eine Produktentwicklung erfolgreich abschließen zu können. Um den Entwicklungsprozess an die Charakteristiken von unterschiedlichen Produkten anzupassen, kann entweder der gesamte Prozess oder auch nur einzelne Phasen in verschiedene Varianten aufgeteilt werden. So kann beispielsweise für Produkte, die erhöhte Sicherheitsanforderungen haben, eine Variante „sicheres System spezifizieren“ von der Phase „System spezifizieren“ abgespalten werden. Somit lassen sich schon vor einem Tailoring des Prozesses in das Projekt verschiedene Ausprägungen eines Prozesstyps bilden. Projekt genehmigt

Projekt definiert

Angebot abgegeben

Projekt beauftragt

System spezifiziert

Feinentwurf abgeschlossen

Projekt abgeschlossen

Lieferung durchgeführt

Iteration geplant

System entworfen

Abbildung 7-3:

Abnahme erfolgt

System integriert

Systemelemente realisiert

Prozesstyp in der Phasenübersicht

Jede Phase des Produktentwicklungsprozesses kann anschließend über mehrere Ebenen detailliert werden. In Abbildung 7-4 ist ein Ausschnitt aus der Phase „Systemelemente realisiert“ dargestellt. Es wird die Umsetzung der Kundenanforderungen in Softwaremodule gezeigt. Im Gegensatz zur Darstellung der Prozessphasen, die nur den Funktionalen und den Verhaltensorientierten Aspekt darstellt, werden hier alle fünf Basisaspekte modelliert. Damit ergibt sich ein komplettes Bild der Entwicklung der Softwarekomponenten. Hauptadressat dieser Darstellung sind die Anwender, die für die Umsetzung des Prozesses verantwortlich sind.

Abbildung 7-4:

Schnittstellenbeschreibung (Detail) Detaildesign Software

Prozesstyp Detail

Entwickler

Testanforderungen

-/-

Entwicklungsumgebnung definieren

Testanforderungen Schnittstellenbeschreibung (Detail) Detaildesign Software

Eingang

Testanforderungen Schnittstellenbeschreibung (Detail) Detaildesign Software

Entwicklung der Testkomponenten -/-

-/-

-/-

[...]

Testergebnisse

Testergebnisse Software Module

Testergebnisse

4 Fehler aus Integrationstest

Testergebnisse bewerten

Fehler in Softwaremodulen

-/-

[...]

-/-

Fehler im Detaildesign Testergebnisse Software Module

Fehler analysieren

Detaildesign 1 überarbeiten

Fehler im Detaildesign

ja Detaildesign muss überarbeitet werden

Dokumentation aktualisieren -/-

Nutzerdokumentation Testergebnisse Software Module

Entwickler

Editor

ja Testergebnisse Software Module

Tests erfolgreich

nein

Fehler im Detaildesign Testergebnisse

nein

Fehler im Detaildesign

Ausgang

Nutzerdokumentation Testergebnisse Software Module

Prozesstyp

Tester

[...]

SoftwareTestsuite

Tester

Systemkomponenten testen

T estumgebung

Software Module

Entwickler

Entwicklung der Lösungskomponenten

IDE

Fehler in Softwaremodulen

98 7 Erstellung einer validierten Prozesslandschaft

7.4 Phase 2.2: Validierung und Umsetzung der QM-Anforderungen im Prozesstyp

99

Nach Abschluss der Prozessdefinitionsphase existiert im Unternehmen eine modellbasierte Beschreibung des Entwicklungsprozesses und der notwendigen Unterstützungsprozesse. Es ist nicht erforderlich, alle in der Norm geforderten Prozesse von Beginn an zu definieren, sondern die Prozesslandschaft kann auch sukzessive erweitert und um neue Prozesse ergänzt werden. Die Prozesslandschaft enthält nun alle Prozesse und alle notwendigen Informationen, um ein Softwaresystem (oder auch ein anderes Produkte) zu erstellen. Im Bezug auf eine Einordnung in die Meta-Modell-Hierarchie aus Abschnitt 3.1 ist der Prozesstyp auf der Ebene M1 eingeordnet. 7.4

Phase 2.2: Validierung und Umsetzung der QM-Anforderungen im Prozesstyp

Mit der Erstellung der Prozesslandschaft und der Definition der Prozesstypen ist die Phase 2.1 des Vorgehensmodells zur QM-Umsetzung abgeschlossen. Der im Unternehmen geplante Soll-Prozess ist festgelegt und kann – zumindest prinzipiell – als Grundlage für neue Entwicklungsprojekte genutzt werden. Zwar ist anzunehmen, dass die Anforderungen der QM-Standards bei der Erstellung der Prozesstypen durch die Prozessverantwortlichen des Unternehmens berücksichtigt wurden, allerdings hat eine systematische Validierung auf Modellebene in aller Regel noch nicht stattgefunden. Diese Validierung ist jedoch aus Sicht des Qualitätsmanagements ein wesentlicher Schritt bei der Erstellung des Prozesstypen. Nur so kann sichergestellt werden, dass der Prozesstyp auch den Anforderungen der QM-Standards entspricht. Für die Aufnahme von Prozessen in die Prozesslandschaft werden weder in der ISO/IEC 15504 noch im CMMI (Kontinuierliche Darstellung) explizite Vorgaben gemacht. Durch die Struktur der beiden QM-Standards können Unternehmen grundsätzlich selbst wählen, welche in den Standards vorgesehenen Prozesse sie umsetzen wollen und welche von einer Bewertung ausgeklammert werden sollen; nur für die ausgewählten Prozesse wird im Assessment ein Fertigkeitsprofil erstellt. Im Zweifelsfall muss die Auswahl der bewerteten Prozesse im Vorfeld eines Assessments zusammen mit dem Assessor geklärt werden. In den meisten Unternehmen müssen jedoch die primären Geschäftsprozesse (im Fall der ISO/IEC 15504 sind das: Acquisition Process Group, Supply Process Group, Engineering Process Group und Operation Process Group) umgesetzt werden. Entsprechend müssen auch die den Prozessen zugeordneten Basispraktiken im Unternehmensprozess vorhanden sein. Im Fall der Unterstützungsprozesse liegt die Entscheidung beim Unternehmen. Dabei gilt jedoch folgende Einschränkung: In der ISO/IEC 15504 und im CMMI besteht zwischen den Ebenen der Reifegraddimension und den Prozessen ein Querbezug. So unterstützt beispielsweise der Prozess „SUP.1 Quality assurance“ aus der ISO/IEC 15504

100

7 Erstellung einer validierten Prozesslandschaft

die Umsetzung der beiden Prozessattribute „PA 2.1 Performance management attribute“ und „PA 2.2 Work product management attribute“ auf Level 2. Die Beziehungen zwischen den Prozessattributen (Reifegraddimension) und den Prozessen (Prozessdimension) sind im QM-Standard explizit genannt und müssen bei der Aufnahme von Prozessen in die Prozesslandschaft beachtet werden. Im Bezug auf die Anforderungen des aQM2 sind in der Validierungsphase (Phase 2.2 des Vorgehensmodells zur QM-Umsetzung) die Ziele 1.1 (Umsetzen der Prozessschritte) und 1.2 (Erstellen der geforderten Arbeitsergebnisse) sowie die Ziele 3.1 (Aufstellen eines Standardprozesses und seiner Schnittstellen) und 3.2 (Festlegen der Zuständigkeiten, Verantwortlichkeiten und der nötigen Infrastruktur im Standardprozess) zu erfüllen. Alle Anforderungen lassen sich direkt in einem Prozesstypen abbilden und sind unabhängig von den Vorgaben eines konkreten Projekts. Durch eine sogenannte Gap-Analyse, also einem Abgleich der Anforderungen aus der QMNorm (hier die aQM2-Ziele) mit der tatsächlich im Prozesstyp vorhandenen Umsetzung, können die Anforderungen des RG1 sowie das Ziel 3.2 validiert werden. Das Ziel 3.1 (Aufstellung eines Standardprozesses und seiner Schnittstellen) ist durch die Definition der Prozesstypen selbst abgedeckt. Da die Ziele des RG2 das Projektmanagement betreffen, sind sie bei der Definition und Validierung des Prozesstyp nicht von Bedeutung; sie werden in späteren Phasen des Lebenszyklus betrachtet. Unternehmensprozess

QM-Standard

Prozessschritt

QM-Modell

Prozessschritt

Prozesse

Datenelement

Arbeitsergebnisse

Organisation

Werkzeuge und Operationen

Abbildung 7-5:

Abbildung des QM-Referenzmodells auf die Basisaspekte

7.4 Phase 2.2: Validierung und Umsetzung der QM-Anforderungen im Prozesstyp

101

Durch die Gap-Analyse wird ein Abgleich der modellierten Prozesse mit den Vorgaben aus den QM-Standards durchgeführt. Um den Prozesstyp validieren zu können, werden die Unternehmensprozesse auf die QM-Norm abgebildet. Das Schema für diese Abbildung der einzelnen Aspekte des AOPM auf die Bestandteile der QM-Norm ist in Abbildung 7-5 dargestellt. Die Abbildung zeigt eine starke Vereinfachung des Prozess-Meta-Modells sowie der Struktur des QM-Standards und wie beide aufeinander abgebildet werden. Ein Prozessschritt kann demnach aus weiteren Prozessschritten aufgebaut sein (kompositer Prozess); außerdem werden einem Prozessschritt Datenelemente (Ein- und Ausgabedaten), Organisationen und Werkzeuge zugeordnet. Ein QM-Standard referenziert verschiedene Prozesse (bzw. Prozessgebiete); diese besitzen wiederum Arbeitsergebnisse, die in den Prozessen erzeugt werden. Zu Organisationen und Werkzeugen bzw. Operationen besteht mit den Generic Resources nur in der ISO/IEC 15504 eine Entsprechung im QM-Standard. Da sie im CMMI nicht enthalten sind, werden sie in der Abbildung nicht berücksichtigt. Die Umsetzung der Ziele des aQM2 beginnt bei RG1 mit einer Implementierung der im Referenzmodell geforderten Prozesse (Base Practices bzw. Specific Goals). Um nachvollziehen zu können, wie die Anforderungen umgesetzt wurden, werden die Elemente des Prozessmodells auf die Elemente des QM-Standards abgebildet. Diese Abbildung ist in beiden Fällen, also bei Prozessschritten und Datenelementen, eine m:n-Abbildung zwischen den Elementen des Unternehmensprozesses und denen des QM-Standards. Daraus ergibt sich folgende Zuordnung: Ein Prozessschritt kann beliebig viele Prozesse (Praktiken) implementieren, bzw. kann die Umsetzung eines Prozesses (Praktik) auf verschiedene Prozessschritte aufgeteilt werden. Hierdurch ergibt sich eine maximale Flexibilität für das Unternehmen. Dieses kann seine eigenen Prozesse so flexibel wie nötig gestalten und ist nicht gezwungen, den Vorgaben aus der Norm strikt zu folgen, sondern kann diese an die Erfordernisse und Gegebenheiten des eigenen Unternehmens anpassen. Gleiches gilt für Datenelemente bzw. Arbeitsergebnisse. Auch hier kann die Abbildung frei durch das Unternehmen gewählt werden. Durch die Abbildung des Prozessmodells auf den QM-Standards werden somit keine zusätzlichen Restriktionen erzeugt. In Abbildung 7-6 wird am Beispiel der ISO/IEC 15504 gezeigt, wie die Arbeitsschritte des Prozesstyps auf die Anforderungen des QM-Standards, in diesem Fall auf die Base Practices, abgebildet werden. So korrespondiert der Schritt „Entwicklung von Lösungskomponenten“ mit der Anforderung „ENG.6.BP2: Develop software units“. Auch die mögliche Umsetzung einer Anforderung („ENG.6.BP4: Verify software units“) in zwei verschiedenen Prozessschritten wird gezeigt. Für die Anforderung „ENG.6.BP3: Eonsure consistency“ hingegen ist im Unternehmensprozess kein eigener Arbeitsschritt vorgesehen und es besteht potenziell eine Lücke bei der Umsetzung des QM-Standards. Ob dies tatsäch-

102

7 Erstellung einer validierten Prozesslandschaft

lich eine Nichterfüllung von Anforderungen des QM-Standards darstellt, kann jedoch erst eine inhaltliche Prüfung im Assessment ergeben. Die Gap-Analyse kann hier durch die Identifizierung solcher Abweichungen dennoch eine wichtige Hilfestellung leisten.

Prozesstyp Testanforderungen Schnittstellenbeschreibung (Detail) Detaildesign Software

QM-Standard Fehler in Softwaremodulen

Fehler in Softwaremodulen

Fehler im Detaildesign

4 Fehler aus Integrationstest

Detaildesign 1 überarbeiten

Fehler im Detaildesign

ENG.6 Software construction

Eingang

ja Schnittstellenbeschreibung (Detail) Detaildesign Software

IDE

nein

Testergebnisse

Detaildesign muss

überarbeitet ENG.6.BP1: Develop werden unit verification procedures

Entwicklung der Lösungskomponenten -/Entwickler

Testanforderungen Schnittstellenbeschreibung (Detail) Detaildesign Software

Fehler im Detaildesign Testergebnisse Software Module

ENG.6.BP2: Develop software units Fehler im Detaildesign Testergebnisse Software Module

T estumgebung

Entwicklungsumgebnung definieren

Testergebnisse Software Module

Systemkomponenten testen

-/-

Testergebnisse bewerten

-/-

Entwickler

Tester

-/[...]

nein Tests erfolgreich

ENG.6.BP3: Ensure consistency Testergebnisse

ja

Software Module Software T estsuite

Editor

ENG.6.BP4: Verify Dokumentation aktualisieren software units [...] Entwickler

Testanforderungen

Entwicklung der Testkomponenten

Testergebnisse -/-

Nutzerdokumentation Testergebnisse Software Module

Tester

Abbildung 7-6:

Abbildung der Prozessschritte auf die ISO 15504

Um den Nutzer bei der Modellierung der Prozesse und der Zuordnung der Anforderungen zu unterstützen, ist eine direkte Unterstützung der QM-Standards im Prozessmodellierungswerkzeug sinnvoll [Jablonski et Faerber 2007; Jablonski et al. 2007; Jablonski et al. 2006]. Eine solche Funktionalität wurde beispielsweise im Werkzeug iPM4QM [Handbuch iPM Integrated Process Manager 2005] implementiert. Dort kann die Abbildung zwischen Prozesstyp und QM-Standard während der Modellierung der Prozesse realisiert werden. Abbildung 7-7 zeigt, wie diese Abbildungsfunktion durch iPM4QM unterstützt wird. Über ein Dialogfenster kann jedem Prozessschritt eine oder mehrere Base Practices aus der ISO/IEC 15504 zugewiesen werden. Analog zur Abbildung der Arbeitsschritte auf Base Practices können auch die Datenelemente des Prozesstyps auf Work Products abgebildet werden. Somit ergibt sich ein vollständiges Bild, wie die Anforderungen der QM-Referenzmodelle auf Ebene 1 im Unternehmen abgebildet werden.

7.4 Phase 2.2: Validierung und Umsetzung der QM-Anforderungen im Prozesstyp

Abbildung 7-7:

103

Werkzeugunterstützung zur Abbildung von Anforderungen aus QM-Normen

Die Validierung des erstellten Prozesstyps auf eine Umsetzung der relevanten Praktiken kann in verschiedenen Systemen erfolgen. So ist es einerseits möglich, die Validierung direkt im Prozessmodellierungssystem durchzuführen und dem Modellierer dort eine Checkliste anzubieten, in der die noch fehlenden Prozesse angezeigt werden. Andererseits kann diese Auswertung auch in einem externen Tool durchgeführt werden. Diese Alternative ist in Abbildung 7-8 dargestellt. In der dort dargestellten Web-basierten Anwendung wird die Abbildung der Arbeitsschritte auf die Base Practices der ISO/IEC 15504 vorgestellt. Analoge Auswertungen sind für die Abbildung von Datenelementen auf Work Products und die Überprüfung, ob zu allen Arbeitsschritten Zuständigkeiten definiert wurden (Ziel 3.2), verfügbar. Durch eine solche Auswertung können Fragestellungen wie die Folgenden beantwortet werden: x „Werden alle Base Practices im Unternehmensprozess abgebildet?“; x „In welchen Arbeitsschritten meines Prozesses werden welche Work Products erstellt?“; x „Welche Organisation im Unternehmen ist für die Erstellung des Work Products XY verantwortlich?“.

104

7 Erstellung einer validierten Prozesslandschaft

Abbildung 7-8:

Abgleich der umgesetzten Praktiken mit QM-Referenzmodell

Die genannten Fragestellungen sollen beispielhaft aufzeigen, wie das Prozessmodell ausgewertet werden kann, um Schwachstellen im Prozessmodell zu identifizieren; sie können je nach Bedarf um weitere ergänzt werden. Ziel dieser Auswertungen ist es, den Prozesstyp zu verbessern und im Hinblick auf die Anforderungen eines QMStandards zu validieren. Hieraus ergibt sich auch die Anforderung an das Speichersystem, in dem das Prozessmodell abgelegt wird, allgemeine Auswertungen einfach zu ermöglichen. Wie in Kapitel 12 gezeigt wird, ist dies im ProcessNavigator durch einen RDF-Triple Store umgesetzt. In Tabelle 7-2 wird die Umsetzung der Anforderungen des aQM2 nochmals in einer Übersicht zusammengefasst: Tabelle 7-2:

Umsetzung der QM-Anforderungen im Prozesstyp

RG 1 Ziel 1.1:

Umsetzen der Prozessschritte

Ziel 1.2:

Erstellen der geforderten Arbeitsergebnisse

Validierung der Prozesstypen im Hinblick auf eine Umsetzung der geforderten Praktiken und Arbeitsprodukte

7.4 Phase 2.2: Validierung und Umsetzung der QM-Anforderungen im Prozesstyp

105

RG 3 Ziel 3.1:

Aufstellen eines Standardprozesses und seiner Schnittstellen

Definition der Prozesstypen

Ziel 3.2:

Festlegen der Zuständigkeiten, Definition des Organisatorischen Verantwortlichkeiten und der und Operationalen Aspekts im nötigen Infrastruktur im Prozesstyp Standardprozess

Nach Abschluss der Definition und Validierung des Prozesstypen steht im Unternehmen ein Soll-Prozess zur Verfügung, der das grundsätzliche Vorgehen zur Umsetzung eines bestimmten Geschäftsvorganges (z.B. die Entwicklung eines Produktes) beschreibt. Dieser wurde im Hinblick auf die Anforderungen der QM-Standards validiert und bildet damit die Ausgangsbasis für zukünftige Projekte. Der Prozesstyp ist jedoch so allgemein gehalten, dass er in einer Vielzahl an gleichartigen Projekten eingesetzt werden kann. Den nächsten Schritt im Lebenszyklus bildet das Tailoring des Prozesstypen für ein konkretes Projekt.

8

Erstellung eines validierten Projekttyps

Nach der Validierung der Unternehmensprozesse im Bezug auf den QM-Standard ist im Unternehmen eine Prozesslandschaft vorhanden, die die grundsätzlichen, zur Entwicklung eines Produktes notwendigen Arbeitsschritte beschreibt. Die Unternehmensprozesse beschreiben jedoch nur einen Standardablauf, der noch nicht an die Erfordernisse eines konkreten Projekts angepasst wurde. Aufbauend auf den in der Prozesslandschaft definierten Prozessen beschreibt dieses Kapitel deshalb das Tailoring eines Projekttyps aus einem Prozesstyp. Zielsetzung des Projekttyps ist es, ein komplettes Produktentwicklungsprojekt strukturiert zu beschreiben. Folglich ist dieser das Äquivalent zum Prozesstyp auf Projektebene und bildet die zur Ausführung des Projekts notwendigen Informationen ab; insbesondere die Terminierung der Arbeitsschritte und die Einplanung der Ressourcen spielen dabei eine wichtige Rolle. 8.1

Das Projekt-Meta-Modell

Zur Modellierung der Projekte muss das Prozess-Meta-Modell um ein neues Element, den Projekttyp, ergänzt werden. Ziel der Erweiterung des Meta-Modells ist es, alle schon im Prozesstyp vorhandenen Informationen so weit wie möglich weiterverwenden und in den Projekttyp übernehmen zu können. Die im Prozesstyp enthaltenen Informationen sollen so direkt in den Projektplan übertragen werden und dort zur Planung des Projekts genutzt werden. Die wichtigste Anpassung ist dabei die Änderung der Prozessschritte in Projektschritte. Projektschritte (oder Projektbausteine) sind eine Spezialisierung des Elements Prozess aus dem Prozess-Meta-Modell (Abbildung 7-1). Durch diese Spezialisierungsbeziehung können alle im Prozesstyp enthaltenen Prozessschritte direkt in Projektschritte umgewandelt werden, da Projektschritte alle Eigenschaften von Prozessen erben. Nicht im Modell angezeigt werden die folgenden zusätzlichen Attribute eines Projektschritts: Voraussichtliche Dauer, frühester Beginn und frühestes Ende sowie spätester Beginn und spätestes Ende. Diese erweitern die bereits am Prozessschritt vorhandenen Attribute und erlauben die Planung eines Projekts. Projektschritte können im Projekttyp genauso verwendet werden, wie Prozessschritte im Prozesstyp. Daten- und Kontrollflüsse definieren weiterhin bestehende Abhängigkeiten zwischen den einzelnen Aktivitäten und geben damit auch eine zeitliche Abfolge der Aktivitäten im Projekt vor. Außerdem kann über die Verbindung der Projektbausteine, die jeweils Knoten im Projektmodell darstellen, eine Zuordnung zu den Aspekten Organisation und Anwendung realisiert werden. Auf diese Weise

108

8 Erstellung eines validierten Projekttyps

werden einem Projektschritt die Organisation (verantwortlicher Mitarbeiter) und Anwendung (eingeplante Ressourcen) im Projektmodell zugeordnet. anhänge *

Knotenanhang

aggregierter Knoten *

Datenquelle

Knoten

Superknoten

Datenquelle

Eingangsports * Ausgangsports

1 Quelle Ziel 1

Port

partitioniert

Knotenart

Fluss

1

* partitioniert

fließt *

partitioniert

Portart

Flussart

M3 M2 <>

<>

<>

Kontrollfluss Prozessschritt

Projektschritt

Konnektor

Datenfluss

Entscheider Konnektor

Logischer Konnektor

Anwendung Organisation

StartInterface

AND

OR

XOR

StopInterface

Abbildung 8-1:

Datencontainer Datenreferenz

Projekt-Meta-Modell auf den Ebenen M2 und M3

Im Bezug auf die Zuordnung der Organisation und der Anwendungen ist es sinnvoll, eine Verbindung zwischen dem Repositorium, in dem der Projekttyp abgelegt wird, und externen Anwendungen (Mitarbeiterverwaltung oder Produktionsplanung) zu schaffen. Auf diese Weise können die tatsächlich im Unternehmen vorhandenen Ressourcen direkt bei der Modellierung genutzt werden. In Tabelle 8-1 sind die Änderungen und Anpassungen der Aspekte im Vergleich zum Prozessmodell nochmals in einer Übersicht zusammengestellt. Wie der Tabelle entnommen werden kann, können die meisten Modellierungselemente direkt aus dem Prozesstyp in den Projekttyp übernommen werden (durch ein leeres Feld in der Spalte Projektmodell gekennzeichnet). Die wichtigste Änderung ist die Spezialisierung der Prozessbausteine in Projektbausteine. Außerdem werden die im Prozessmodell enthaltenen abstrakten Rollenbeschreibungen und Werkzeuge durch verantwortliche Mitarbeiter und eingeplante Ressourcen ersetzt.

8.2 Phase 3.1: Erstellung des Projekttyps Tabelle 8-1:

109

Änderungen im Projektmodell im Vergleich zum Prozessmodell

Aspekte

Prozessmodell

Funktionaler Aspekt

Phase

Projektmodell

Meilenstein Prozessbaustein Verhaltensorientierter Aspekt

Projektbaustein

Kontrollfluss Entscheider Kontrollflusskonnektoren (AND, OR, XOR) Prozessstart und -ende Externer Ein- und Ausgang

Datenorientierter Aspekt

Datenfluss Datenelement

Organisatorischer Aspekt

Organisationseinheit

Mitarbeiter

Operationaler Aspekt

Werkzeug

Ressource

Wie schon beim Prozess-Meta-Modell erlaubt auch die Darstellung des Projektmodells als Meta-Modell die einfache Anpassung an neue Gegebenheiten und Anforderungen. So können in das Projektmodell sowohl zusätzliche neue Attribute, Aspekte und externe Modelle eingebunden werden und damit das Prozessmodell an neue Anforderungen angepasst werden. 8.2

Phase 3.1: Erstellung des Projekttyps

Dieser Abschnitt der Arbeit beschreibt die schrittweise Überführung des Prozesstyps in einen Projekttyp. Ausgehend vom in der Literatur beschrieben Vorgehen zur Projektplanung werden zuerst die Entwurfsziele eines solchen Projekttyps betrachtet. Darauf aufbauend wird ein Vorgehen entworfen, wie der Projekttyp aus dem Prozesstyp abgeleitet werden kann. Wichtig hierbei ist vor allem, dass die im Prozess-

110

8 Erstellung eines validierten Projekttyps

typ vorhanden Informationen weiterverwendet und schrittweise an die spezifischen Gegebenheiten eines Projekts angepasst werden. 8.2.1

Exkurs: Projektplanung in der Literatur

Die Planung der im Projekt durchgeführten Aktivitäten hat sich in der alltäglichen Projektarbeit durchgesetzt und ist gute Praxis in vielen Unternehmen. In [Kerzner 2006] und [Kuster et al. 2008] werden die folgenden Gründe für eine Planung von Projekten in Unternehmen genannt: x Die Reduzierung der Unsicherheit im Bezug auf die Projektdurchführung; x das Erreichen eines besseren Verständnisses der Ziele (Kosten, Termine und Budget) im Projekt; x die Strukturierung und das Abgrenzen von Arbeitspaketen; x die Überprüfung, ob die Vorgaben des Auftraggebers realistisch sind; x das Wissen, welche Fachspezialisten (mit einem definierten Know-how) zu wie viel Prozent für das Projekt zur Verfügung stehen; x das frühzeitige Erkennen von Ressourcenengpässen oder Konflikten im Projekt; x das rechtzeitiges Ergreifen von Maßnahmen zur Behebung von Engpässen, insbesondere im Bezug auf Personen, Finanzen oder Maschinen; x das Bereitstellen einer Basis für das Projektmonitoring (Soll/Ist-Vergleich). Das zentrale Element bei der Projektplanung ist der Projektplan. Dort werden alle für das Projekt planbaren Entscheidungen eingetragen und der geplante Projektablauf dokumentiert. Der Projektplan bildet auch die Grundlage für die Abstimmung mit Kunden und anderen am Projekt beteiligten Personen (Stakeholders); er klärt insbesondere die folgenden Fragestellungen: x Was wird gemacht? x Wie wird es gemacht? x Wo bzw. wer ist dafür verantwortlich? x Wann muss es fertig sein? x Warum ist es notwendig? Der Projektplan fasst damit alle zur Bearbeitung und Ausführung eines Projekts wichtigen Informationen an einer zentralen Stelle zusammen. Die zur Erstellung eines Projektplans notwendigen Schritte werden in [Kuster et al. 2008] vorgestellt. Dabei

8.2 Phase 3.1: Erstellung des Projekttyps

111

wird das Vorgehen in zwei Planungsphasen unterschieden: eine Grob- und eine Detailplanungsphase. Im Bezug auf das AOPM wird bei der Grobplanung insbesondere der Funktionale Aspekt, also Struktur und Aufbau des Projekts, definiert. Es sollen die folgenden Artefakte erstellt werden: 1. Erstellung des Meilensteinplans 2. Erstellung des Projektstrukturplans und Festlegen der Arbeitspakete Die Detailplanung geht über die in der Grobplanung festgelegte Struktur des Projektplans hinaus und adressiert, im Bezug auf die AOPM, die anderen Perspektiven des Prozessmodells. In der Detailplanung wird der Projektplan in den folgenden Punkten weiter verfeinert: 3. Erstellung des Ablauf- und Terminplans 4. Terminierung der Meilensteine 5. Erstellung des Ressourcenplans 6. Erstellung des Kostenplans Im Meilensteinplan wird der zeitliche Ablauf des Projekts grob dargestellt. Jeder Meilenstein markiert das Ende einer Projektphase und oftmals auch das Eintreten eines für das Projekt wichtigen Ereignisses oder die Fertigstellung eines Ergebnisses. Beispiele für solche Ereignisse sind das Abschließen der Anforderungsanalyse, des Systemkonzepts oder des gesamten Projekts. Der Meilensteinplan ist stark von der Struktur und den Anforderungen des Projekts abhängig. Einfach strukturierte Projekte erfordern wenige Meilensteine, komplexe Projekte entsprechend mehr. Auch Unsicherheit über das genaue Vorgehen im Projekt kann ein Hinweis dafür sein, mehr Meilensteine im Projekt zu planen. Der Projektstrukturplan (PSP) erweitert den Meilensteinplan um Arbeitspakete. Das Projekt bzw. die dort schon eingeplanten Phasen werden weiter in übersichtliche Arbeitspakete unterteilt, die jeweils in sich abgeschlossene Aufgaben darstellen. Jedem Arbeitspaket wird ein fachlicher Aufgabenträger zugeordnet, der für die korrekte Ausführung des Arbeitspaketes verantwortlich ist. Dies kann entweder ein Mitarbeiter sein oder ein Verweis auf die Organisationseinheit des Unternehmens, die für die Bearbeitung verantwortlich ist. Im weiteren Verlauf dieser Arbeit werden die Begriffe Arbeitspaket, Arbeitsschritt, Aufgabe sowie Aufgabenpaket weitgehend synonym genutzt. Die Festlegung eines Meilensteinplans mit zugehörigem Projektstrukturplan stellt häufig eine umfangreiche Aufgabe dar. Aus diesem Grund bietet es sich an, einen vorhandenen Entwicklungsprozess an die Erfordernisse des Projekts anzupassen,

112

8 Erstellung eines validierten Projekttyps

statt diesen neu zu erstellen. Dies ist vor allem dann der Fall, wenn im Unternehmen eine Vielzahl ähnlicher Projekte durchgeführt wird. Prozesse müssen jedoch, bevor sie in einem Projekt angewendet werden können, an die Erfordernisse des Projekts angepasst werden (das sogenannte Prozess-Tailoring). Nachfolgend werden verschiedene Ansätze und Verfahren zur Anpassung von Prozessen an Projekte aus der Literatur vorgestellt. [Pedreira et al. 2007] gibt einen systematischen Überblick über vorhandene Publikationen. Die Autoren stellen fest, dass obwohl die Anpassung der Unternehmensprozesse an die Gegebenheiten eines Projekts ein wichtiges Thema ist, nur relativ wenige Publikationen zu dem Thema existieren. Insgesamt kann die vorhandene Literatur in drei Kategorien unterteilt werden: x Anpassungsebene des Prozessmodells: Die Anpassung eines allgemeinen Prozesses (Prozess-Standard) an die Gegebenheiten der Organisation oder die Anpassung eines Organisationsprozesses an die Gegebenheiten des Projekts. x Grad der Formalität: Formale Vorschriften oder informale Richtlinien bei der Anpassung des Prozesses an das Projekt. x Größe der untersuchten Unternehmen: Differenzierung nach der Größe des Unternehmens, auf die sich die in der Publikation beschriebene Untersuchung bezieht. Eine der in dem Beitrag vorgestellten Erkenntnisse ist, dass der Grad des umgesetzten Tailoring vor allem von der Unternehmensgröße abhängt. Große Unternehmen können den Zusatzaufwand, den komplexe Tailoring-Regeln erfordern, eher verkraften als kleine Unternehmen mit nur wenigen Mitarbeitern. Dies trifft insbesondere dann zu, wenn in den Unternehmen schon Erfahrung über QM-Systeme vorhanden ist. Für kleine Unternehmen hingegen sind komplizierte formale Verfahren häufig zu aufwendig zu implementieren. Als Konsequenz verfolgen kleine Unternehmen oftmals einen Ad-Hoc Ansatz beim Tailoring der Prozesse an Projekte. Dies birgt jedoch die Gefahr, ein nicht dem Projekt angemessenes Vorgehen zu erhalten; insbesondere für Unternehmen, die sich nach QM-Standards (ISO/IEC 15504 oder CMMI) zertifizieren lassen wollen, stellt dies die Gefahr von Abweichungen von den Anforderungen dar. Drei Tailoring Ansätze sollen näher vorgestellt werden: Zum einen ein Ansatz aus dem militärischen Umfeld [Budlong et al. 1996], das im V-Modell XT vorgestellte Verfahren [V-Modell XT (Version 1.3)] und zum anderen ein Verfahren aus einem Großunternehmen [Fitzgerald et al. 2003]. Alle diese Ansätze gehen davon aus, dass im Unternehmen ein baukastenartig strukturiertes Prozessmodell vorhanden ist; im Fall des V-

8.2 Phase 3.1: Erstellung des Projekttyps

113

Modells werden diese Prozessbausteine selbst durch das Vorgehensmodell definiert (Vorgehensbausteine). Durch die Auswahl eines Projekttyps werden im V-Modell XT die entsprechenden Vorgehensbausteine ausgewählt (Abschnitt 2.1). Die Abfolge der Vorgehensbausteine wird dabei durch die Projektdurchführungsstrategie bestimmt. In [Budlong et al. 1996] wird ein zweistufiges Tailoring-Verfahren vorgeschlagen. Im ersten Schritt wird eine Auswahl der Prozessbausteine basierend auf den Prozesscharakteristika (z.B. voraussichtliche Größe, Komplexität oder Formalitätsgrad des Projekts) vorgenommen. Im zweiten Schritt werden die Inhalte der einzelnen Prozessbausteine an die Erfordernisse des Projekts angepasst. Dabei können Prozessschritte wie vorhanden übernommen werden, sie können komplett abgelehnt, überarbeitet oder völlig neu definiert werden. Nach Auswahl der entsprechenden Prozessbausteine und ihrer Anpassung an den Projektkontext muss nun der für das Projekt angepasste Prozess dokumentiert werden. Dabei sind insbesondere die Abweichungen von den vorgegebenen Prozessbausteinen zu beschreiben. Schließlich muss basierend auf dem Prozess ein Projektplan mit Projektstruktur und Projektablaufbeschreibung erzeugt werden. In [Fitzgerald et al. 2003] beschreiben die Autoren den in einem Großunternehmen (Motorola) eingesetzten Ansatz zum Tailoring von Standardprozessen an den Projektkontext. Dabei wird mehrstufig vorgegangen. Zuerst werden vorhandene Standardprozesse (in diesem Fall der Standard IEEE 1074 und ein V-Modell) an die Bedürfnisse des Gesamtunternehmens angepasst und ein unternehmensweit gültiges Standardvorgehensmodell erzeugt. Dieses Standardvorgehensmodell wird anschließend an die einzelnen Standorte angepasst. Die Autoren sprechen bei diesem ersten Schritt von einem Tailoring auf Makroebene. Als Ergebnis erhält jeder Standort einen eigenen Organisationsentwicklungsprozess (OSSP). Dieser wird vor einem Projektstart in einem zweiten Schritt an die Erfordernisse des Projekts angepasst; die Autoren sprechen hierbei von einem Tailoring auf Mikroebene. Die Autoren stellen mehrere Vorteile des Verfahrens heraus: zum einen können durch die Anpassung des Prozesses auf Makroebene die Besonderheiten der einzelnen Produktionsstandorte und der dort gefertigten Produkte berücksichtigt werden; dabei wird ein, bezüglich des Gesamtunternehmens allgemein gültiger und vor allem stabiler Prozess erstellt. Zum anderen wird durch den ersten Tailoring-Schritt auf Makroebene der gesamte Tailoring-Prozess verkürzt; Projektleiter können schon mit dem OSSP beginnen und müssen nicht den unternehmensweiten Prozess anpassen. Der OSSP kann somit einfacher durch die einzelnen Projekte genutzt werden. In dem Beitrag wird insbesondere auch auf die Unterstützung von QM-Standards (CMMI) und auf den Erfolg des vorgestellten Verfahrens hingewiesen.

114

8 Erstellung eines validierten Projekttyps

8.2.2

Vorgehen zur Erstellung des Projektmodells

Der validierte Prozesstyp ist die Ausgangsbasis für die Erstellung eines Projekttyps. Es umfasst einerseits die Standardarbeitsabläufe des Unternehmens (bzw. der Organisationseinheit), andererseits ist es bezüglich der Anforderungen des QM-Standards validiert. Aus dem validierten Prozesstyp werden nun unter Berücksichtigung der Tailoring-Regeln ein Meilenstein- und ein Projektstrukturplan abgeleitet, der anschließend in einen vollständigen Projektplan weiterentwickelt wird. Dieser Abschnitt stellt die notwendigen Schritte vor und beschreibt, wie die im Prozesstyp vorhandenen Ergebnisse zur Erstellung des Projektplans genutzt werden können. Alle im Prozesstyp vorhandenen Elemente (Tabelle 7-1) können für die Projektplanung genutzt werden; insbesondere betrifft dies die Elemente Phase, Meilenstein und Prozessschritt, die für die Erstellung des Projektplanes direkt weiter genutzt werden können. Die Planung eines Projekts kann je nach Ausgangssituation eine unterschiedliche Menge an Schritten umfassen, deren Reihenfolge variieren kann. Ohne die Gültigkeit des in dieser Arbeit vorgestellten Ansatzes einzuschränken, kann das hier vorgestellte Vorgehen jederzeit durch ein anderes, äquivalentes Vorgehen ersetzt werden. In [Kuster et al. 2008] ist die Erstellung eines Projektmodells in die zwei Phasen Grobund Detailplanung unterteilt. Sowohl bei der Grob- als auch bei der Detailplanung kann es vorkommen, dass aus QM-Sicht relevante Elemente (Arbeitsschritte, Daten etc.) aus dem Projektplan entfernt werden. Dies wird in der anschließenden Validierungsphase (Phase 3.2) überprüft und angezeigt. Diese Abweichungen können anschließend durch den Projektleiter korrigiert werden. Das Vorgehen zur Grobplanung des Projektmodells setzt sich aus zwei Schritten zusammen: 1. Definition des Meilensteinplans Mit der Definition des Meilensteinplans wird der Projektablauf grob festgelegt. Zu jedem Meilenstein wird eine Menge an Dokumenten angegeben, die an diesem Meilenstein fertiggestellt sind, sowie ein verantwortlicher Mitarbeiter, der für die Abnahme und Freigabe des Meilensteins und der hinterlegten Dokumente verantwortlich ist. Die im Plan enthaltenen Meilensteine und die dort fertigzustellenden Dokumente richten sich maßgeblich nach der Art des Projekts. So kann etwa bei In-House-Projekten auf ein formales Angebotsverfahren verzichtet werden. Zur Erstellung des Meilensteinplans kann entweder auf Erfahrungen aus vorhandenen Projekten zurückgegriffen werden und ein dort erstellter Plan übernommen werden, oder der Plan wird neu auf die Erfordernisse des Projekts abgestimmt. Die Festlegung der Meilensteine wird durch

8.2 Phase 3.1: Erstellung des Projekttyps

115

den Projektleiter vorgenommen und das Ergebnis ist ein definierter Meilensteinplan. 2. Erstellen des Projektstrukturplans und Festlegen der Arbeitspakete In der Typbibliothek können zu einem Geschäftsvorfall mehrere Varianten (Prozesstypen) vorhanden sein. So kann sich beispielsweise die Anforderungserhebung bei komplexen Projekten deutlich von der bei einfachen Projekten unterscheiden; so müssen bei komplexen Projekten die Anforderungen ausführlicher geprüft werden als bei einfachen Projekten. Je nach Projekttyp werden nun in den Meilensteinplan jene Typvarianten eingefügt, die der Projektstruktur entsprechen.

Anforderungen Variante 1

Tailoring

Prozessmodell

Anforderungen Variante 2 Anforderungen Variante 3

Grobkonzept Variante 1 Grobkonzept Variante 2

Projektmodell

Richtlinien Tabellen

Anforderungen erheben

Abbildung 8-2:

Grobkonzept erstellen

Erstellung eines Projekttyps aus der Prozesslandschaft

Nach Abschluss der Grobplanung steht dem Projektleiter ein Projektstrukturplan mit definierten Arbeitspaketen zur Verfügung. Dieser kann genutzt werden, um das Vorgehen im Projekt mit den Kunden oder anderen am Projekt beteiligten Personen vorab zu klären. Nachdem die Grobstruktur des Projektplans von allen Beteiligten genehmigt wurde, wird die Projektplanung mit der Detailplanung fortgesetzt. Diese setzt sich aus den folgenden fünf Schritten zusammen: 1. Überarbeitung und Detaillierung des Projektstrukturplans Dieser Schritt ist in der ursprünglichen Projektplanung nach [Kuster et al. 2008] nicht vorgesehen. Da der Projektstrukturplan allerdings aus vordefinierten Varianten des Prozesstyps konfiguriert wird, hat der Projektleiter an dieser Stelle nochmals die Möglichkeit einzelne Arbeitspakete zu detaillieren oder zu überarbeiten. Ziel dieses Schrittes ist es, geringfügige Ungenauigkeiten oder Stel-

116

8 Erstellung eines validierten Projekttyps

len, an denen die vordefinierten Prozessbausteine nicht genau zum Projekt passen, zu korrigieren; keinesfalls soll der gesamte Projekttyp neu definieren werden. 2. Ablauf- und Terminplan erstellen (Aufwandschätzung) Bei der Erstellung des Ablauf- und Terminplanes geht es vor allem darum eine Abschätzung zu treffen, welcher Aufwand durch die einzelnen Arbeitspakte erzeugt wird, und wie lange diese zur Bearbeitung benötigen. Dazu werden die Experten und Mitarbeiter aus den Fachabteilungen angefragt und deren Schätzung im Projektplan eingetragen. Die Abfolge der Arbeitsschritte ergibt sich aus der Definition des Verhaltens- und Datenorientierten Aspekts aus dem Prozesstyp und muss nur angepasst werden, falls sich Unstimmigkeiten mit der Struktur des Projekts ergeben. 3. Terminierung der Meilensteine Die Terminierung der Meilensteine ergibt sich direkt aus der Dauer der Arbeitspakete und deren Ablaufplanung. Für jeden Meilenstein kann somit errechnet werden, wann er beendet werden kann. Die errechneten Termine müssen mit den Kunden anschließend besprochen und bei Unstimmigkeiten korrigiert werden. 4. Ressourcenplan erstellen Den im Prozesstyp eingeplanten Ressourcentypen (Rollen bzw. Fertigkeiten) müssen vor Projektbeginn Mitarbeiter zugeordnet werden. Dazu werden die beteiligten Linienvorgesetzten angefragt und gebeten, Mitarbeiter vorzuschlagen, die die beschriebenen Arbeitspakete umsetzen können. Die gemeldeten Mitarbeiter werden im Projektplan als verantwortliche Mitarbeiter eingetragen. Wenn ein Arbeitspaket nicht direkt einem Mitarbeiter zugeordnet werden kann, kann dort stattdessen auch ein Anforderungsprofil (z.B. SW-Architekt oder Konstrukteur) eingesetzt werden. Damit wird die Zuordnung von Arbeitspaketen zu Mitarbeitern in die Projektdurchführungsphase (Abschnitt 9.1) verschoben. 5. Kostenplan erstellen Aus eingeplanten Mitarbeitern und der Dauer der Arbeitspakete lassen sich die Kosten der einzelnen Arbeitspakete und somit auch des gesamten Projektes errechnen. Falls hier Abweichungen von dem vorher veranschlagten Budget auftreten, sind entsprechende Änderungen am Projektplan oder den Zielen des Projekts vorzunehmen. Zu den Kosten für Mitarbeiter müssen noch alle weiteren im Projekt geplanten Kosten addiert werden.

8.2 Phase 3.1: Erstellung des Projekttyps

117

Die beschriebenen Schritte stellen einen nahezu idealen Ablauf bei der Planung von Projekten dar. Konflikte mit Kunden oder Linienvorgesetzten bei der Auswahl der Mitarbeiter wurden bewusst aus dem beschriebenen Vorgehen ausgeklammert. Konflikte können entweder durch zusätzliche Iterationen oder andere geeignete Maßnahmen aufgelöst werden ([Kerzner 2006] oder [Kuster et al. 2008]). Ein aus Sicht der QM-Standards wichtiger Gesichtspunkt bei der Erstellung des Projekttyps aus dem Prozesstyp ist das Tailoring. Entsprechend der Definition wird beim Tailoring ein Projekttyp aus einem vordefinierten Prozesstyp erzeugt und an den speziellen Projektkontext angepasst. Voraussetzung für das Tailoring ist, dass im Unternehmen eine Menge an vordefinierten Prozesstypen (die Typbibliothek) vorhanden ist. Aus diesem „Prozess-Baukasten“ werden im Tailoring jene Modellvarianten ausgewählt, die auf das aktuelle Projekt zutreffen. Im V-Modell XT wird hier beispielsweise die folgenden Parameter abgefragt: „Ist ein kaufmännisches Projektmanagement notwendig?“, „Müssen Messungen und Analysen durchgeführt werden?“, „Was ist der Projektgegenstand? Software, Hardware, …“. Entsprechend der Antworten auf diese Fragestellungen werden im Projekttyp anschließend die dem Projekt entsprechenden Prozesstypvarianten eingefügt. In [Hörmann et al. 2006] wird insbesondere im Zusammenhang mit der ISO/IEC 15504 auf die Bedeutung des Tailorings hingewiesen. Nur durch die Nutzung nachvollziehbarer Tailoring-Richtlinien ist eine Zertifizierung auf Level 3 möglich (für das CMMI gelten analoge Anforderungen [Ginsberg et Quinn 1995]). In beiden Quellen werden Tabellen vorgeschlagen, um die Richtlinien, wie Prozesse an Projekte angepasst werden müssen, zu dokumentieren und den Projektleitern zugänglich zu machen. In diesen Tabellen werden zu verschiedenen Projektcharakteristika Anweisungen gegeben, wie der Prozess an das Projekt angepasst werden muss. Die Realisierung eines Richtlinienkatalogs zum Prozesstailoring in einem Werkzeug ist beispielsweise im V-Modell XT demonstriert. Dort ist eine Softwarekomponente enthalten, der V-Modell XT Projektassistent [V-Modell XT Projektassistent], mit dessen Hilfe das V-Modell XT an die Gegebenheiten eines Projekts angepasst werden kann. In Abbildung 8-3 ist dieser Konfigurationsassistent dargestellt. In der Spalte „Projektmerkmal“ sind die verschiedenen Charakteristika eines Projekts aufgeführt; zu diesen können dann die entsprechenden Werte aus einer Drop-down-Liste ausgewählt werden. Basierend auf der getroffenen Auswahl werden die Prozessbausteine – im Fall des V-Modell XT Vorgehensbausteine – in das Projekt aufgenommen oder aus diesem entfernt.

118

8 Erstellung eines validierten Projekttyps

Abbildung 8-3:

Prozess-Tailoring im V-Modell XT Projektassistent 1.3.1 [V-Modell XT Projektassistent]

Ergebnis des Prozess-Tailoring ist ein an das Projekt angepasster Projekttyp. Dieses wurde aus den vorhandenen Prozessbausteinen, der Prozesslandschaft sowie den dort vorhandenen Varianten entsprechend der Projektmerkmale erstellt. Es enthält nur noch jene Aktivitäten und Organisationen, die auch im Projekt Anwendung finden. 8.2.3

Darstellung des Projekttyps

Zur Darstellung des Projekttyps werden zusätzlich zu den im Prozessmodell vorhandenen Modellierungselementen Projektbausteine eingeführt. Diese werden durch den in Abbildung 8-4 abgebildeten Bausteintyp repräsentiert. Die Attribute eines Projektbausteins entsprechen den Attributen der Netzplantechnik [Kuster et al. 2008; Zimmermann et al. 2005] und erlauben es dem Projektleiter, die aus der Netzplantechnik bekannten Operationen auf einen Projektplan anzuwenden. So können nach der Bestimmung der Dauer einer jeden Aktivität die frühesten und spätesten Termine für Aktivitäten und entsprechend auch für Meilensteine errechnet werden. Außerdem kann der sogenannte Kritische Pfad errechnet werden. Dieser gibt, bezogen auf die Projektdauer, den längsten Pfad vom Start des Projekts bis zu seiner Beendigung an.

8.2 Phase 3.1: Erstellung des Projekttyps

119

Der Projektbaustein besitzt die folgenden Attribute: x Voraussichtliche Dauer Gibt die durch den Projektleiter in Rücksprache mit den Mitarbeitern angegebene voraussichtliche Dauer der Aktivität an. Im Fall eines kompositen Projektbausteins ergibt sich diese aus der Errechnung des Kritischen Pfades seiner Teilaktivitäten automatisch. Frühester Beginn Spätester Beginn

Voraussichtliche Dauer

Frühestes Ende Spätestes Ende

Arbeitspaketname Verantwortlicher Mitarbeiter

Aufwand/ Kosten

Abbildung 8-4:

Darstellung Projektbausteintyp

x Frühester Beginn und frühestes Ende Diese Werte geben an, wann eine Aktivität basierend auf der voraussichtlichen Dauer frühestens beginnen kann bzw. wann sie frühestens zu Ende ist. Die Werte werden durch Vorwärtsrechnung ausgehend vom Startzeitpunkt des Projekts (bzw. der Vateraktivität) errechnet. x Spätester Beginn und spätestes Ende Analog zum frühesten Beginn und zum frühesten Ende können diese Termine durch die Dauer der Aktivitäten errechnet werden. Allerdings werden im Fall der spätesten Termine diese durch Rückwärtsrechnung ausgehend vom Projektende (bzw. der Vateraktivität) ermittelt. Außerdem bestehen Verknüpfungen zu den folgenden Aspekten: x Verantwortlicher Mitarbeiter (Organisatorischer Aspekt) Statt der im Prozessplan angegeben Rollenbeschreibung wird im Projektbaustein der tatsächlich verantwortliche Mitarbeiter eingetragen. Diese Informationen können einerseits in Verbindung mit der voraussichtlichen Dauer dazu genutzt werden, die durch die Aktivität verursachten Personalkosten abzuschätzen. Durch den Abgleich mit den Daten aus anderen Projekten kann außerdem überprüft werden, in welchen anderen Projekten der Mitarbeiter noch eingeplant ist, und ob er durch die neue Planung überlastet wird.

120

8 Erstellung eines validierten Projekttyps

x Aufwand/ Kosten Anlog zu der Planung des verantwortlichen Mitarbeiters können weitere Ressourcen an einer Aktivität geplant werden. Je nachdem ob weitere personelle Ressourcen oder Produktionsressourcen im Arbeitspaket gebunden werden, steigen Aufwand oder Kosten, die im Arbeitspaket anfallen. In Abbildung 8-5 ist der aus dem Prozesstyp (Abbildung 7-4) erzeugte Projekttyp dargestellt. Dabei werden die Prozessbausteine aus dem Prozessmodell in Projektbausteine umgewandelt. Hier wurde eine direkte 1:1-Übertragung der Prozessbausteine in Projektbausteine gewählt. Abgesehen davon wurden am Modell keine Veränderungen vorgenommen. Dies ist jedoch nicht zwangsläufig der Fall. Vielmehr kann ein Projektleiter bei der Erstellung des Projekttyps während des Tailorings grundsätzlich alle im Modell enthaltenen Aspekte unter Berücksichtigung der QMAnforderungen überarbeiten und neu definieren. Eine Validierung des Projektmodells findet in Phase 3.2 statt.

Prozesstyp Testanforderungen Schnittstellenbeschreibung (Detail)

Projekttyp Fehler in Softwaremodulen Testanforderungen Schnittstellenbeschreibung (Detail)

Fehler in Softwaremodulen

Detaildesign Software

Fehler in Softwaremodulen

Detaildesign Software

Eingang

Eingang Schnittstellenbeschreibung (Detail) Detaildesign Software

IDE

Schnittstellenbeschreibung (Detail) Detaildesign Software

Entwicklung der Lösungskomponenten

Entwicklung der Lösungskomponenten

-/Entwickler

Testanforderungen Schnittstellenbeschreibung (Detail) Detaildesign Software

Testanforderungen Schnittstellenbeschreibung (Detail) Detaildesign Software Software Module

Software Module

T estumgebung

Entwicklungsumgebnung definieren

Testergebnisse Software Module

Systemkomponenten testen

-/-

Entwicklungsumgebung definieren

Systemkomponenten testen

-/-

Entwickler

Tester

Software T estsuite

Software T estsuite

[...]

Testanforderungen

Entwicklung der Testkomponenten

Testanforderungen

Entwicklung der Testkomponenten

-/Tester

Abbildung 8-5:

Übertragung des Prozesstyps in einen Projekttyp

In der betrieblichen Praxis ist der Projektplan (als Textdokument) ein wesentliches Instrument der Projektplanung. In den meisten Fällen wird dieser vom Kunden verlangt, da er das Projekt und seine Umsetzung beschreibt. Er ist gegenüber Kunden der Beleg, dass die Anforderungen richtig verstanden wurden und beschreibt die zur Umsetzung nötigen Schritte. Unternehmensintern ist der Projektplan eines der

8.2 Phase 3.1: Erstellung des Projekttyps

121

wichtigsten Kommunikationsmittel; er soll maßgeblich zur Identifikation und Vermeidung von Konflikten im Projekt beitragen. In [Kerzner 2006] wird der Aufbau eines Projektplans beschrieben. Dieser besteht aus den folgenden vier Haupteilen Einleitung, Projektübersicht und Schlussfolgerungen, Managementinformationen sowie einem Teil mit technischen Informationen: 1. Einleitung o Textuelle Beschreibung des Projekts mit Informationen über seinen Hintergrund und die Geschichte des Projekts. 2. Projektübersicht und Schlussfolgerungen o Textuelle Beschreibung des Projektziels sowie eine Beschreibung der nach Projektabschluss gelösten Probleme. o Darstellung des grundlegenden Projektplans mit den folgenden Informationen ƒ Planungsinformationen (z.B. die im Projekt vorhanden Meilensteine) ƒ Auflistung der im Projekt vorhandenen Aktivitäten ƒ Zusammenhänge zwischen den Aktivitäten im Projekt ƒ Abschätzung der Projektdauer 3. Managementinformationen o Aufstellung der wichtigsten Mitarbeiter im Projekt o Informationen über die im Projekt eingesetzten Mitarbeiter und deren Qualifikationen 4. Technischer Teil o Detaillierte Aufgliederung des grundlegenden Projektplans sowie Informationen über die geschätzten Zeiten und Kosten o Auflistung der Testaktivitäten sowie das darin umgesetzte Vorgehen o Beschreibung der in Zusammenhang mit technischen Anforderungen möglichen Projektrisiken Anhand der dargestellten Gliederung können die Inhalte in die zwei Kategorien Textelemente und strukturierte Informationen unterteilt werden. Während Textelemente in den meisten Fällen projektspezifisch formuliert werden müssen, können die strukturierten Elemente aus anderen im Unternehmen vorhandenen Informationsquellen abgeleitet werden. Dazu bietet sich insbesondere der Projekttyp an. So können die Meilensteine, die Liste der geplanten Aktivitäten, Zusammenhänge

122

8 Erstellung eines validierten Projekttyps

zwischen den Aktivitäten und die eingeplanten Mitarbeiter direkt aus dem Projekttyp entnommen und im Projektplan eingefügt werden. Ziel des erstellten Projektmodells ist es somit, ein integriertes Modell zu erstellen, in dem alle Informationen über Projektplanung und -ablauf an einer Stelle gespeichert werden können. Aus diesem Modell können dann sowohl die Informationen für die Ablaufplanung als auch die Inhalte des textbasierten Projektplans erstellt werden. Auf diese Weise können Redundanzen und die damit verbundene Inkonsistenzen in der Planung vermieden werden. 8.3

Phase 3.2: Validierung und Umsetzung der QM-Anforderungen im Projekttyp

Mit der Ableitung des Projekttyps aus dem Prozesstyp ist die Phase 3.1 des Vorgehensmodells zur QM-Umsetzung abgeschlossen. Aus dem Prozesstyp wurde ein Projekttyp abgeleitet. Dieser baut zwar auf dem validierten Prozesstyp auf, allerdings hat der Projektleiter bei seiner der Definition die Möglichkeit, Änderungen am Typ vorzunehmen. Es ist also nicht gewährleistet, dass alle QM-Anforderungen aus dem Prozesstyp mit in den Projekttyp übernommen werden. Aus diesem Grund ist eine erneute Validierung des Projekttyps nach Abschluss des Tailoring notwendig. Wie schon beim Prozesstyp stellt auch die Validierung des Projekttyps einen wichtigen Arbeitsschritt aus QM-Sicht dar. Aus den im aQM2 gestellten Anforderungen sind die in Tabelle 8-2 aufgeführten Ziele bei der Validierung des Projekttyps von Bedeutung: Tabelle 8-2:

Umsetzung der QM-Vorgaben im Projektmodell (Ebene 1)

RG 1 Ziel 1.1:

Umsetzen der Prozessschritte

Ziel 1.2:

Erstellen der geforderten Arbeitsergebnisse

Validierung des Projekttyps im Hinblick auf eine Umsetzung der geforderten Praktiken und Arbeitsprodukte

Zwar wurden diese beiden Ziele schon bei der Validierung der Prozesstypen überprüft, allerdings können im Zuge der Änderungen durch das Tailoring neue Lücken bei der Umsetzung der Anforderungen aus den QM-Standards entstanden sein. Zur Validierung können die in Abschnitt 7.4 vorgestellten Techniken genutzt werden. Zusätzlich zu diesen beiden schon beschriebenen QM-Zielen müssen während des Tailorings auch Ziele aus Tabelle 8-3 beachtet werden:

8.3 Phase 3.2: Validierung und Umsetzung der QM-Anforderungen im Projekttyp Tabelle 8-3:

123

Umsetzung der QM-Vorgaben im Projektplan

RG 2 Ziel 2.1:

Planung des Projekts

Entwicklung des Projekttyps aus dem Prozesstyp

Ziel 2.2:

Definition von Zielen und Festlegung von Zielen und Entscheidungsbefugnissen für die Entscheidungsbefugnissen im Prozessausführung Projektplan

Ziel 2.3:

Allokation von Ressourcen

Festlegen des Organisatorischen und Operationalen Aspekts im Projekttyp

Ziel 2.4:

Definition der Schnittstellen zwischen Parteien

Festlegung von Besprechungsterminen und E-MailVerteilern im Projektplan

Ziel 2.5:

Definition der Anforderungen an Arbeitsprodukte

Ergänzung der im Prozesstyp vorhandenen Daten um quantitative und qualitative Ziele

Ziel 3.3:

Ableitung eines Projekts aus dem Standardprozess

Tailoring des Projekttyps aus dem Prozesstyp

Ziel 3.4:

Festlegung der im Projekt eingesetzten Verantwortlichkeiten und Infrastruktur

Ziel 3.5:

Definition von Methoden zur Messung des Standardprozesses

RG 3

Festlegung von Kennzahlen, die im Projekt ermittelt werden sollen

Ziel 2.1 (Planung des Projekts) wird durch das beschriebene Vorgehen zur Planung eines Projekts vollständig abgedeckt. Ergebnis der Projektplanung ist der definierte Projekttyp und der Projektplan mit den auszuführenden Arbeitsschritten, Aktivitäten und dem zeitlichen Ablaufplan. Ebenso werden die Ziele 2.3 (Allokation von Ressourcen), 3.3 (Ableitung eines Projekts aus dem Standardprozess) und 3.4 (Festlegung der im Projekt eingesetzten Verantwortlichkeiten und Infrastruktur) durch das in Abschnitt 8.2.2 beschriebene Vorgehen zur Projektdefinition abgedeckt.

124

8 Erstellung eines validierten Projekttyps

Die Umsetzung der Ziele 2.2 (Definition von Zielen und Verantwortlichkeiten für die Prozessausführung), 2.4 (Definition der Schnittstellen zwischen Parteien), 2.5 (Definition der Anforderungen an Arbeitsprodukte) und 3.5 (Definition von Methoden zur Messung des Standardprozesses) wurden im beschriebenen Verfahren zur Erstellung des Projekttyps nicht explizit angesprochen. Die Definition von Zielen für die Prozessausführung und die Festlegung der generellen Entscheidungsbefugnisse im Projekt können im Projektplan dokumentiert werden. Für die Definition von Schnittstellen zwischen den Parteien können E-Mail-Verteiler oder regelmäßige Treffen etabliert werden. Die im Prozess und entsprechend auch im Projekt geplanten Arbeitsergebnisse müssen durch quantitative und qualitative Anforderungen bezogen auf den Projektkontext ergänzt werden. Prozesskennzahlen, Audits oder Managementreviews sind Methoden um die Ausführung des (Standard-)Prozesses zu messen. Alle diese Festlegungen sind ein wichtiger Bestandteil der Projektplanung und wichtig zur Erreichung der Level 2 oder 3 in den QM-Standards ISO/IEC 15504 bzw. CMMI. Sie können jedoch im Modell einfach durch zusätzliche Attribute realisiert werden und sie haben insbesondere auch keinen direkten Einfluss auf das spätere Informationssystem. Aus diesem Grund werden diese Ziele hier nur am Rand beschrieben. Mit dem validierten Projekttyp und dem Projektplan sind die für die Projektausführung notwendigen Vorarbeiten abgeschlossen. Der Projekttyp kann direkt in die Ausführungsumgebung geladen und dort ausgeführt werden. Beim Laden in der Ausführungsumgebung wird das Modell in ein ausführbares Modell transformiert. In der Ausführungsumgebung werden die notwendigen Strukturen bereitgestellt und im Hinblick auf die Meta-Hierarchie findet ein Ebenenwechsel von der Ebene M1 (Projekttyp) zur Ebene M0 (ausführbare Instanz) statt. Nach Abschluss und Validierung des Projekttyps steht der Plan für die Umsetzung eines Projektes zur Verfügung. Im Gegensatz zum Prozesstyp ist dieser nicht mehr allgemein gehalten, sondern konkret auf die Anforderungen eines bestimmten Projektes abgestimmt. Er enthält die Meilensteine, die im Projekt erfüllt werden müssen, und die Ressourcen, die zur Umsetzung eines Projekts notwendig sind, wurden festgelegt. Durch die Validierung am QM-Standard wurde sichergestellt, dass während des Tailorings keine Anforderungen verletzt wurden. Der Prozesstyp ist somit bereit um im ProcessNavigator ausgeführt zu werden.

9

Projektdurchführung

Im Anschluss an die Erstellung und erfolgreiche Validierung des Projektplans wird vom Projektleiter zusammen mit den Auftraggebern der Start eines Projekts beschlossen. Damit wird im Anschluss an die Planung der Arbeitspakete mit der Umsetzung der geplanten Arbeitsschritte begonnen. In diesem Kapitel wird ein Informationssystem bzw. Prozessmanagementsystem entworfen, welches basierend auf dem im Kapitel 8 erstellten Projektplan und den Anforderungen, die sich durch die QM-Standards ergeben, Anwender bei der Bearbeitung des Projekts unterstützt. Zentraler Aspekt dieses Kapitels ist die Konzeption des prozessbasierten Informationssystems. Dieses System (der ProcessNavigator) stellt ein neuartiges Prozessmanagementsystem dar, welches in dieser Arbeit neu entwickelt wird und speziell auf die Anforderungen von Entwicklungsprojekten abgestimmt ist. Analog zu den anderen Phasen Erstellung einer validierten Prozesslandschaft und Erstellung eines validierten Projekttyps ist auch die Phase 4 (Projektdurchführung) in zwei Blöcke untergliedert. Ziel der Phase 4.1 (Projektbearbeitung) ist es, die Projektziele in der geplanten Zeit und dem vorhandenen Budget umzusetzen; gleichzeitig wird in Phase 4.2 (Projektmonitoring) die Umsetzung im Sinne eines Projektmonitoring ständig überwacht, um im Fall von Abweichung vom vordefinierten Plan steuernd in die Ausführung einzugreifen. Im Gegensatz zu der nachträglichen Validierung der erreichten Ergebnisse in den Phasen 2 (Prozessdefinition) und 3 (Projektdefinition) ist das Monitoring projektbegleitend angelegt. Parallel zur Ausführung des Projekts hat der Projektleiter damit die Möglichkeit, Abweichungen vom Plan frühzeitig zu erkennen und kann somit rechtzeitig korrigierend eingreifen. 9.1

Phase 4.1: Unterstützung bei der Projektbearbeitung

Dieser Abschnitt beschreibt die Anforderungen und das Konzept eines Informationssystems zur Unterstützung von Mitarbeitern in Produktentwicklungsprojekten. Das Konzept wird zunächst unabhängig von den Anforderungen der QM-Standards diskutiert; dass dieses dennoch geeignet ist, die deren Anforderungen zu unterstützen, wird im anschließenden Kapitel 9.2 gezeigt. Ausgehend von den in Kapitel 4 beschriebenen Anforderungen an ein Prozessausführungssystem soll in diesem Abschnitt das grundsätzliche Lösungskonzept eines ITSystems zur Unterstützung von Prozessen entwickelt und beschrieben werden. Nach der Beschreibung des grundlegenden Systemkonzepts wird anhand der verschiedenen Perspektiven der AOPM, ein Lösungskonzept für ein prozessbasiertes Informationssystem erarbeitet.

126

9.1.1

9 Projektdurchführung

Grundlegendes Konzept des ProcessNavigators

Zur Unterstützung von Unternehmensprozessen, die sich wiederholen und gut vorhergeplant werden können, wurden Workflow-Management-Systeme entwickelt [Georgakopoulos et al. 1995; Jablonski 1994; Jablonski 2009; Jablonski et Bussler 1996; van der Aalst et al. 2003]. Diese sind in der Lage modellierte Prozesse auszuführen und zeichnen sich dadurch aus, dass sie die im Prozess anstehenden Arbeiten an die verfügbaren Mitarbeiter verteilen. Bei diesen Systemen gilt der Grundsatz, dass ein Arbeitsschritt immer erst dann begonnen werden kann, wenn die zu seiner Ausführung nötigen Vorbedingungen erfüllt sind. In der Regel bedeuten diese Vorbedingungen, dass alle Vorgängerschritte bearbeitet wurden, alle erforderlichen Daten und Dokumente erstellt wurden und diese somit im aktuellen Arbeitsschritt zur Verfügung stehen. Das Systemverhalten eines Workflow-Management-Systems soll an einem kleinen Beispiel vorgestellt werden. In Abbildung 9-1 ist dazu ein kurzer Beispielprozess und die Arbeitslisten (Worklists) der Mitarbeiter zu drei verschiedenen Zeitpunkten T1, T2 und T3 abgebildet. Prozess Reiseantrag Ausfüllen des Resieantrags -/-

Müller (Mitarbeiter)

Reiseantrag (überarbeitet)

Eintragen der Kostenstelle -/-

Meier (Sekretariat)

T1

-/-

Schmidt (Vorgesetzter)

Worklists (Arbeitslisten) Müller

Entscheidung über Genehmigung

Meier

Schmidt

Ausfüllen des Reiseantrags (RA Müller)

T2

Eintragen der Kostenstelle (RA Müller) Entscheidung über Genehmigung (RA Müller)

T3

Abbildung 9-1:

Workflow-Management-Systeme (Beispiel)

Im Beispiel wird ein Ausschnitt aus einem stark vereinfachten Dienstreiseantragsprozess gezeigt. Der Mitarbeiter (Müller) stößt die Bearbeitung des Prozesses an; im ersten Schritt muss er das Antragsformular ausfüllen. Dieses Antragformular wird

9.1 Phase 4.1: Unterstützung bei der Projektbearbeitung

127

dann ins Sekretariat (Meier) weitergeleitet, um die Angaben zu überprüfen und festzulegen, auf welche Kostenstelle die Reise gebucht wird. Abschließend muss der Vorgesetzte (Schmidt) die Genehmigung zu der Dienstreise erteilen und den Antrag unterschreiben. Dieser Antragsprozess soll nun durch ein Workflow-Management-System unterstützt werden. In diesem System hat jeder Mitarbeiter seine eigene Worklist. In dieser sind alle Aufgaben eingetragen, die dem Mitarbeiter durch das System zugewiesen wurden. Entsprechend ist zum Zeitpunkt T1, also direkt im Anschluss an den Start des Prozesses, in der Arbeitsliste von Müller die Aufgabe Ausfüllen des Reiseantrags eingetragen. Die Worklists der Mitarbeiter Meier und Schmidt sind zu diesem Zeitpunkt noch leer, da für beide im Rahmen des Prozesses noch keine Aufgaben angefallen sind. Nachdem Müller den Reiseantrag ausgefüllt und den entsprechenden Arbeitsschritt abgeschlossen hat, wird die Bearbeitung vom Workflow-ManagementSystem an das Sekretariat weitergeleitet (Zeitpunkt T2). Somit erscheint die Aufgabe Eintragen der Kostenstelle zusammen mit dem Dokument (RA Müller) in der Arbeitsliste von Meier; der abgeschlossene Arbeitsschritt wird aus der Worklist von Müller entfernt. Nachdem auch Meier den Arbeitsschritt beendet hat, wird der Reiseantrag an Schmidt zur Genehmigung weitergeleitet. Gemäß der im Prozess verteilten Aufgaben ist nur in der Worklist von Schmidt eine Aufgabe (Entscheidung über Genehmigung) eingetragen; die beiden anderen Listen sind leer. Fazit dieses Beispiel ist, dass klassische Workflow-Management-Systeme eine strikte Ausführungsreihenfolge für Prozessschritte umsetzen, welche den Anwender durch den Prozess führt, diesem allerdings auch keine Abweichungen vom vorgegebenen Pfad erlaubt. Das im Beispiel vorgestellte Prinzip eines Workflow-Management-Systems wird in den folgenden Abschnitten auch als klassisches oder konventionelles Konzept bezeichnet. Es erfüllt im Bezug auf die im Kapitel 4 vorgestellten Anforderungen schon einige der wesentlichen Punkte. So werden den Mitarbeitern die jeweils nächsten Prozessschritte vorgeschlagen (Kapitel 4 – Anforderung #1), und auch eine Weiterleitung der Daten (Kapitel 4 – Anforderung #7) ist in klassischen WorkflowManagement-Systemen realisiert. Sie bilden somit eine gute Ausgangsbasis für die Entwicklung eines Prozessmanagementsystems, welches alle in Kapitel 4 beschriebenen Anforderungen erfüllen kann. Aufbauend auf diesem, aus klassischen Workflow-Management-Systemen bekannten Grundprinzip wird ein neues Prozessmanagementsystem (der ProcessNavigator) zur Unterstützung von Produktentwicklungsprojekten konzipiert. Analog zu klassischen Workflow-Management-Systemen unterteilt sich der ProcessNavigator in eine Worklist-Komponente (die ProcessNavigator-Worklist bzw. PN-Worklist) zur Anzeige

128

9 Projektdurchführung

der nächsten Arbeitsschritte und in eine Anwendungskomponente (der ProcessNavigator-Desktop bzw. PN-Desktop). Abbildung 9-2 zeigt die Umsetzung des ProcessNavigators als Web-Anwendung mit der PN-Worklist und dem PN-Desktop. Aus der PNWorklist können die Mitarbeiter das Arbeitspaket auswählen, welches sie bearbeiten möchten. Nach der Auswahl eines Arbeitspaketes werden im PN-Desktop Informationen angezeigt, die den Mitarbeiter bei der Umsetzung unterstützen. Nach Abschluss eines Schrittes durch den Mitarbeiter wird PN-Desktop wieder deaktiviert. In der Worklist wird der aktualisierte Projektstatus angezeigt und dem Mitarbeiter werden die, aufgrund der aktuellen Projektsituation, passenden nächsten Schritte angeboten. Somit ergibt sich wie im klassischen Workflow-Management-System ein ständiger Wechsel zwischen der Auswahl einer Aufgabe in der PN-Worklist und der Bearbeitung der Aufgabe im PN-Desktop. Durch diese Aufteilung, PN-Worklist auf der linken Seite und PN-Desktop auf der rechten Seite, setzt der ProcessNavigator direkt die zwei Kernaspekte aus Kapitel 4 „Information über den Prozessablauf“ und „Bereitstellung von Kontextinformationen“ um. Einige der Eigenschaften von klassischen Workflow-Management-Systemen widersprechen allerdings auch dem Einsatz in der Projektarbeit. So führen klassische Systeme Prozesse in einer strikten Reihenfolge aus [Georgakopoulos et al. 1995], welche exakt dem im Prozess modellierten Kontrollfluss entspricht; Abweichungen vom vorher festgelegten Kontrollfluss werden nicht unterstützt. Ein Schritt kann immer erst dann ausgeführt werden, wenn der Vorgänger abgeschlossen wurde; die Schritte können nicht übersprungen werden, und auch die erneute Ausführung eines bereits abgeschlossenen Schrittes ist im klassischen Konzept nicht vorgesehen. Im Bezug auf das vorgestellte Beispiel bedeutet dies, dass von der vorgegebenen Reihenfolge „Ausfüllen des Reiseantrags“ Æ „Eintragen der Kostenstelle“ Æ „Entscheidung über Genehmigung“ nicht abgewichen werden kann. Für den Einsatz in der Projektarbeit ist diese fest vorgegebene Ausführungsreihenfolge nicht anwendbar, da sie den Anwendern nicht gestattet auf Projektereignisse zu reagieren, die zur Modellierung des Prozesses noch nicht bekannt waren. Diese Art der Prozessausführung ist viel zu strikt und würde die Mitarbeiter zu sehr bei der Bearbeitung der Arbeitsschritte einschränken. Entsprechend muss beim Entwurf des neuen Prozessmanagementsystems vor allem eine Möglichkeit gefunden werden, die es den Anwendern erlaubt auf neue Situationen im Prozess bzw. Projekt zu reagieren (siehe Anforderungen #1 bis #10 in Kapitel 4). So müssen die vorhandenen Konzepte aus Workflow-Management-Systemen teilweise neu interpretiert werden, teilweise müssen sie um neue Ansätze ergänzt werden.

9.1 Phase 4.1: Unterstützung bei der Projektbearbeitung

129

Testanforderungen

Fehler in Softwaremodulen

Schnittstellenbeschreibung (Detail)

Fehler in Softwaremodulen

4

Detaildesign Software

Fehler im Detaildesign

Fehler aus Integrationstest

1

Fehler im Detaildesign

Detaildesign überarbeiten

Eingang

Projekt genehmigt

Projekt definiert

Angebot abgegeben

Projekt beauftragt

Proje abgeschlo kt ssen

Abnahme erfolgt

ja Schnittstellenbeschreibung (Detail)

IDE

nein

Detaildesign Software

Fehler analysieren -/-

-/[...]

Testanforderungen

Lieferu durchgef ng ührt

Iteration geplant

Fehler im Detaildesign

Schnittstellenbeschreibung (Detail)

Testergebnisse

Detaildesign Software Software Module

Fehler im Detaildesign

T estumgebung Testergebnisse

System entworfen

Detaildesign muss überarbeitet werden

Testergebnisse Entwicklung der Lösungskomponenten

Entwickler

System spezifiziert

Entwicklungsumgebnung definieren

System integriert

Software Module

Testergebnisse bewerten

-/-

Entwickler

nein

Testergebnisse

Software Module

Systemkomponenten testen -/-

T ests erfolgreich

-/-

T ester

ja

[...] Testergebnisse Software Module

Software T estsuite

Feinent abgeschlo wurf ssen

Systemele realisi mente ert

Editor

Dokumentation aktualisieren [...]

-/Entwickler Testergebnisse

Entwicklung der Testkomponenten

Testanforderungen

Nutzerdokumentation

Nutzerdokumentation

Testergebnisse

Testergebnisse

Software Module

Software Module

-/-

Ausgang

T ester

Testanforderungen Schnittstellenbeschreibung (Detail) Detaildesign Software

Fehler in Softwaremodulen

Fehler in Softwaremodulen 4 Fehler aus Integrationstest

Fehler im Detaildesign Detaildesign 1 überarbeiten

Fehler im Detaildesign

Eingang Schnittstellenbeschreibung (Detail) Detaildesign Software

Testergebnisse Entwicklung der Lösungskomponenten

Testanforderungen Schnittstellenbeschreibung (Detail) Detaildesign Software

ja nein Detaildesign muss überarbeitet werden

IDE

Entwickle r

Fehler analysieren -/-

[...]

-/Fehler im Detaildesign Testergebnisse

Software Module

estumgebun T g Entwicklungsumgebnung definieren Entwickle r

Testergebnisse Software Module

Systemkomponenten testen

-/-

Tester

-/-

Fehler im Detaildesign Testergebnisse Software Module

Testergebnisse bewerten [...]

nein Tests erfolgreich

-/-

ja Testergebnisse Software Module

SoftwareTestsuite

Editor Dokumentation aktualisieren

[...]

Testanforderungen

Testergebnisse

Entwicklung der Testkomponenten Tester

-/-

ProcessNavigator

Worklist Abbildung 9-2:

-/Entwickle r Nutzerdokumentation Testergebnisse Software Module

Nutzerdokumentation Testergebnisse Software Module Ausgang

ProcessNavigator

Desktop ProcessNavigator Übersicht

Die in klassischen Workflow-Management-Systemen vorhandene Ausführung des Prozesses in der vordefinierten Reihenfolge entsprechend dem Kontrollfluss, wie sie im Prozessmodell beschrieben ist, wird auch im ProcessNavigator angeboten. Allerdings wird sie hier nicht als „vorgeschriebener“ Pfad durch den Prozess interpretiert, sondern als „idealer“ oder „geplanter“ Pfad. Dieser „ideale“ Pfad wird ergänzt durch zusätzliche Möglichkeiten, die es dem Anwender erlauben einen „Umweg“ oder auch eine „Abkürzung“ einzuschlagen. Dies trägt der Tatsache Rechnung, dass in der täglichen Projektarbeit bzw. der Produktentwicklung der ideale Weg, also die Bearbeitung des Projekts entsprechend der Vorgaben aus dem Projektplan, nur selten exakt umgesetzt werden kann. Die „Umwege“ und „Abkürzungen“ erlauben es, flexibel auf sich ändernde Projektsituationen reagieren zu können. Zur Realisierung dieser Erweiterungen und zur Umsetzung der in Kapitel 4 vorgestellten Anforderungen, muss der ProcessNavigator im Vergleich zu klassischen Workflow-Management-System an mehreren Stellen angepasst werden. Die wichtigste dieser Anpassungen betrifft dabei die Worklist. In der klassischen Form wird jeweils nur der nächste Prozessschritt (im Fall einer Verzweigung im Kontrollfluss können es auch mehrere sein) in der Worklist angezeigt. Diese monolithische

130

9 Projektdurchführung

Worklist wird im ProcessNavigator in mehrere Segmente unterteilt, aus denen Anwender Schritte zur Ausführung auswählen können. Eines dieser Segmente bildet die aus dem klassischen Konzept bekannte Reihenfolge der Schritte gemäß dem Kontrollfluss; sie wird hier als „idealer“ Pfad interpretiert. Weitere Segmente der Worklist ergänzen diesen Pfad um zusätzliche Schritte und erlauben damit „Umwege“ und „Abkürzungen“. Diese Möglichkeit, vom vorgegebenen Kontrollfluss abweichen zu können, ist eine der zentralen Anforderungen an ein Prozessmanagementsystem zur Unterstützung von Produktentwicklungsprojekten (Kapitel 4 – Anforderungen #2, #3 und #4). Diese Aufteilung der Worklist in verschiedene Segmente wird in Abbildung 9-3 dargestellt. Vorhandene Worklist-Segmente

Prozessmodell

Projekt genehmigt

Projekt definiert

Angebot abgegeben

Projekt beauftragt

System entworfen

System integriert

Feinentwurf abgeschlossen

Testanforderungen Schnittstellenbeschreibung (Detail) Detaildesign Software

4

Segment Y „Design Situation“

Systemelemente realisiert

Fehler in Softwaremodulen Fehler in Softwaremodulen

Z

Lieferung durchgeführt

Iteration geplant

Segment X „Nächste Schritte“

Projekt abgeschlossen

Abnahme erfolgt

System spezifiziert

Fehler im Detaildesign

Fehler aus Integrationstest

Fehler im Detaildesign

Detaildesign 1 überarbeiten

Eingang ja Schnittstellenbeschreibung (Detail) Detaildesign Software

IDE

nein Testergebnisse

Entwicklung der Lösungskomponenten

Fehler analysieren -/-

Detaildesign muss überarbeitet werden

-/-

Entwickler

[...]

Testanforderungen Schnittstellenbeschreibung (Detail) Detaildesign Software

Fehler im Detaildesign Testergebnisse

Y

Software Module

Fehler im Detaildesign Testergebnisse Software Module

Testumgebung Entwicklungsumgebnung definieren

Testergebnisse Software Module

Systemkomponenten testen -/-

Entwickler

X Testanforderungen

Testergebnisse bewerten

-/Tester

Worklist Konfiguration

nein Tests erfolgreich

-/-

ja

Z„AlleSegment Schritte“

[...] Testergebnisse Software Module

SoftwareT estsuite

Editor Dokumentation aktualisieren

[...]

-/Entwickler Testergebnisse

Entwicklung der Testkomponenten -/Tester

Abbildung 9-3:

Nutzerdokumentation Testergebnisse Software Module

Nutzerdokumentation Testergebnisse Software Module Ausgang

Weitere Segmente

Bezug zwischen Prozesstyp und Worklist

Ein weiterer Aspekt ist die Art und Weise, wie die einzelnen Segmente der Worklist mit Inhalten gefüllt werden. Aus konzeptioneller Sicht stellen die Segmente der Worklist nichts anderes dar, als eine bestimmte Auswahl an Schritten aus der Gesamtmenge der im Prozess bzw. Projekt verfügbaren Schritte. Einzig das Selektionskriterium unterscheidet die Auswahl und damit auch den Umfang der enthaltenen Schritte. Segmente sind damit vergleichbar mit den aus dem Bereich der relationalen Datenbanken bekannten Views [Date 2003; Elmasri et Navathe 2006]. Im Bezug auf die im ProcessNavigator verwendete Worklist beantworten Segmente beispielsweise die folgenden inhaltlichen Fragen: „Welche sind die nächsten Arbeitspakete in einem konkreten Projekt?“, „Welche Arbeitspakete können im Moment außerdem noch sinnvoll ausgeführt werden?“ oder „Welche sind die nächsten Arbeitspakete eines

9.1 Phase 4.1: Unterstützung bei der Projektbearbeitung

131

bestimmten Mitarbeiters?“. Die Zusammenstellung der Segmente in einer Worklist wird hier auch als Worklist-Konfiguration bezeichnet; diese kann bezogen auf den konkreten Anwendungsfall jeweils individuell zusammengestellt werden. Im Vergleich zum klassischen Worklist-Konzept unterscheidet sich die PN-Worklist in den folgenden Punkten: x Anzeige von Arbeitspaketen aus dem Gesamtprozess Durch die Anzeige von Arbeitspaketen aus dem Gesamtprozess kann der Mitarbeiter frei entscheiden mit welchem Schritt er im Prozess fortfahren will. Insbesondere kann durch diesen Mechanismus erreicht werden, dass Arbeitspakete ausgelassen (Kapitel 4 – Anforderung #4) oder übersprungen werden können (Kapitel 4 – Anforderung #3). x Anzeige von schon abgeschlossenen Arbeitspaketen Dieser Mechanismus macht es möglich Arbeitspakete erneut aufzurufen (Kapitel 4 – Anforderung #2), auch wenn diese im ProcessNavigator schon als abgeschlossen markiert wurden. Somit können Prozessergebnisse erneut bearbeitet und korrigiert werden. x Kompositer Aufbau aus mehreren Segmenten Durch den kompositen Aufbau der Worklist kann der ProcessNavigator sowohl Arbeitspakete des gesamten Prozesses anzeigen als auch eine Navigationsfunktionalität bereitstellen. Dabei wird die Navigation durch den Prozess vor allem mit Segmenten mit wenigen Arbeitspaketen (z.B. „Nächste Schritte im Projekt“) erreicht. Außerdem kann durch Aufnahme und das Entfernen von Segmenten aus der Worklist-Konfiguration diese an die Bedürfnisse der Anwender angepasst werden. x Mehrere Worklist-Konfigurationen Im ProcessNavigator können mehrere Worklist-Konfigurationen verwaltet werden. Dadurch können diese individuell an die Anforderungen der Anwender angepasst werden. Über einen Wechsel zwischen den WorklistKonfigurationen hat der Nutzer somit Zugriff auf verschiedene Segmente. In Abschnitt 9.1.5 (Der Organisatorische Aspekt im ProcessNavigator) wird dieser Mechanismus genutzt, um eine Konfiguration „Meine Prozessschritte“ und eine Konfiguration „Alle Prozessschritte“ zu erstellen. In der Konfiguration „Meine Schritte“ werden nur noch jene Schritte angezeigt, die sich entweder aus der Zuordnung eines Mitarbeiters zu einem Arbeitspaket im Projekttyp oder über dort festgelegte Anforderungsprofile (Rollen) dem angemeldeten Nutzer zuordnen lassen.

132

9 Projektdurchführung

Mit der PN-Worklist und dem PN-Desktop ergeben sich die meisten Änderungen im Vergleich zu klassischen Workflow-Management-Systemen. Die PN-Worklist erfüllt die Anforderungen im Bezug auf die Unterstützung einer flexiblen Ausführungsreihenfolge der Prozessschritte und die damit verbundene Anwendbarkeit im Projektalltag. Hier erhält der Anwender (z.B. der Entwickler oder Ingenieur) die notwendigen Informationen, wie er im Projekt fortzufahren hat. Im Hinblick auf die in Abbildung 4-1 aufgeführten Aufgaben des ProcessNavigators wird hier also die Koordination der Mitarbeiter und Aufgaben im Projekt übernommen. Zusätzlich kann der ProcessNavigator die Reihenfolge und die Ausführungen der Aufgaben im Projekt in einem Bericht (Protokoll-Einträge) mitschreiben und er dokumentiert Projektausführung und Umsetzung der QM-Vorgaben. Die zweite im ProcessNavigator neu vorhandene Komponente – der PN-Desktop – hat die Aufgabe aktuelle Informationen über den ausgewählten Arbeitsschritt für Mitarbeiter bereitzustellen. Die für Mitarbeiter relevanten Informationen werden durch den Projektkontext bestimmt, welcher sich aus dem gewählten Projektschritt, dem gewählten Projekt aber auch andere Parameter wie beispielsweise dem eingeloggten Nutzer automatisch bestimmt lässt. Aus diesem Projektkontext ergeben sich Anforderungen an den Informationsbedarf des Anwenders. Dieser Bedarf wird im PNDesktop aktiv durch den ProcessNavigator erfüllt, indem das im Unternehmen vorhandene Wissen automatisch zur Verfügung gestellt wird. Zur besseren Übersicht ist der PN-Desktop in verschiedene Themenbereiche (sogenannte Reiter) unterteilt. Jeder Reiter stellt Informationen zu einem spezifischen Bereich der Produktentwicklung z.B. Arbeitsanweisungen, Dokumente und Daten, oder Anleitungen zu Werkzeugen bereit. Außerdem wird durch den PN-Desktop die Aufgabe der Datenintegration übernommen, da die vorhandenen Informationen dem Nutzer an einer Stelle verfügbar gemacht werden und der Nutzer nicht in verschiedenen Datenquellen suchen muss. Der ProcessNavigator zeichnet sich also vor allem durch seine sehr frei konfigurierbare Worklist und die Bereitstellung von Informationen zum ausgewählten Arbeitsschritt aus. Die Worklist ermöglicht es den Anwendern, sich innerhalb der Grenzen des vordefinierten Projekttyps frei zu bewegen und über den Fortgang des Projektes zu entscheiden; der Desktop zeigt die zur Umsetzung des Arbeitspaketes nötigen Kontextinformationen an. Nach der Betrachtung des grundlegenden Konzepts soll in den nächsten Abschnitten vertieft auf die Einbindung der verschiedenen Aspekte des Prozessmodelles in den ProcessNavigator eingegangen werden. Die in den folgenden Abschnitten vorgestellte

9.1 Phase 4.1: Unterstützung bei der Projektbearbeitung

133

Umsetzung der Aspekte im ProcessNavigator wurde innerhalb des Forschungsverbundes FORFLOW entwickelt und evaluiert. 9.1.2

Der Funktionale Aspekt im ProcessNavigator

Der Funktionale Aspekt definiert im Prozessmodell den strukturellen Aufbau des Projekts und die dort umzusetzenden Aufgaben. Im ProcessNavigator wird der Funktionale Aspekt vor allem in die Worklist abgebildet und bestimmt, welche Aufgaben den Anwendern zur Bearbeitung angeboten werden. Wichtigstes Element des Funktionalen Aspekts ist der aus dem Prozessbaustein abgeleitete Projektbaustein; er definiert im ProcessNavigator die Einträge der Worklist. Damit wird für jeden im Projekttyp vorhandenen Projektbaustein jeweils ein Eintrag in der Worklist erzeugt. Projektbausteine (im Folgenden Aufgaben genannt) werden über Segmente und Worklist-Konfigurationen den Mitarbeitern zur Auswahl angeboten. Im Forschungsverbund FORFLOW wurde eine Worklist-Konfiguration entwickelt, die es erlaubt, die Navigation durch den Prozess mit einer größtmöglichen Flexibilität für die Nutzer zu kombinieren [Faerber et al. 2009]. Dazu werden drei WorklistSegmente in einer Worklist-Konfiguration zusammengefasst. Die Worklist (siehe Abbildung 9-4) setzt sich damit aus den folgenden Segmente zusammen: x Nächste Schritte (Abbildung 9-4 – n): In diesem Segment werden bezogen auf einen gerade bearbeiteten Prozessschritt die jeweils nächsten Prozessschritte angezeigt. Im Fall des oben abgebildeten Beispiels werden die Meilensteine Detaildesign abgeschlossen und Architekturdesign abgeschlossen schon bearbeitet (durch einen Haken markiert). Entsprechend wird im Segment „Nächste Schritte“ die Aufgabe „Entwicklungsumgebung definieren“ als nächste auszuführende Aufgabe angezeigt (siehe Prozesstyp Abbildung 7-4 – Seite 98). Diese Aufgabensicht ist somit dafür verantwortlich, dem Nutzer die jeweils nächsten Arbeitsschritte vorzuschlagen (Kapitel 4 – Anforderung #1). x Entwicklungssituation (Design Situation) (o): In diesem Segment werden alle Aufgaben angezeigt, die sich im Kontext des aktuellen Arbeitsschrittes befinden. Hier werden neben den noch offenen zukünftigen Arbeitsschritten auch schon bearbeitete Schritte angeboten, um dem Anwender die Möglichkeit zu geben bisherige Ergebnisse erneut einzusehen und gegebenenfalls zu überarbeiten (Kapitel 4 – Anforderungen #2 und #3). Für die Bestimmung des aktuellen Entwicklungskontexts können verschiedene Methoden herangezogen werden. So werden in Abbildung 9-4 Meilensteine zur Bestimmung der im Segment angezeigten Aufgaben genutzt; alle Schritte zwischen dem letzten abge-

134

9 Projektdurchführung

schlossenen Meilenstein und dem nächsten offenen werden hier aufgenommen. Allerdings sind auch andere Definitionen für die Festlegung des Entwicklungskontexts möglich. So kann die Menge der angezeigten Aufgaben auch durch ein Auswahlfenster mit einer festen Größe um den aktuell auszuführenden Prozessschritt definiert werden (z.B. die drei Schritte vor und nach der nächsten Aufgabe).

Abbildung 9-4:

Die Worklist im ProcessNavigator

x Gesamtes Projekt (Alle Schritte) (p): In diesem Segment sind alle Arbeitspakete des gesamten Projekts enthalten. Die hier enthaltenen Arbeitsschritte werden dann von einem Anwender genutzt, wenn der gewünschte Arbeitsschritt nicht in einer der beiden anderen Worklist-Segmente enthalten ist (Kapitel 4 – Anforderungen #2 und #3). Mitarbeiter können eine beliebige Aufgabe aus einem der drei Worklist-Segmente auswählen. Die Entscheidung, wie der Prozess fortgesetzt werden soll, ist damit auf den Mitarbeiter übertragen und somit ist auch die wichtigste Forderung an den ProcessNavigator – die flexible Ausführungsreihenfolge der Prozessschritte – umgesetzt. Die in den drei Segmenten angezeigten Ausschnitte aus dem Gesamtprozess ergeben eine klare Reihenfolge für die Auswahl durch den Mitarbeiter: Erstens die

9.1 Phase 4.1: Unterstützung bei der Projektbearbeitung

135

Schritte im Segment „Nächste Schritte“, anschließend Schritte aus dem Segment „Entwicklungssituation“ und dann die Schritte aus dem Segment „Alle Schritte“. Diese Reihenfolge ergibt sich auch aus dem abnehmenden Bezug der einzelnen Segmente auf die aktuelle Projektsituation. Nur die Einträge im Segment „Nächste Schritte“ zeigen jene Schritte an, die bezogen auf den aktuellen Projektstatus im Projektmodell als nächstes zur Ausführung vorgesehen sind. Die Segmente „Entwicklungssituation“ und „Alle Schritte“ zeigen jeweils einen größeren Ausschnitt und ermöglichen dem Anwender dadurch „Abkürzungen“ oder „Umwege“ vorzunehmen. Während die Navigation bzw. Orientierung im Prozess beim Segment „Nächste Schritte“ noch sehr hoch ist, nimmt sie beim Segment „Entwicklungssituation“ schon deutlich ab. Das Segment „Alle Schritte“ bietet keine Orientierung mehr für den Anwender; stattdessen erlaubt sie eine maximale Flexibilität bei der Prozessausführung. Durch die Aufteilung der Worklist in verschiedene Segmente kombiniert der ProcessNavigator eine systematische Navigation im Prozess mit flexibler Prozessausführung. Wie in der Beschreibung der Worklist-Segment „Entwicklungssituation“ schon angedeutet wurde, kann die feste Fenstergröße zur Bestimmung der im Segment abgebildeten Arbeitspakete durch andere Ansätze ersetzt werden. Ziel der in diesem Segment angezeigten Arbeitspakete ist es, eine Menge von Arbeitspaketen zu finden, die in einem bestimmten Zeitintervall durch den Benutzer mit einer hohen Wahrscheinlichkeit aufgerufen werden. Durch das Modellierungselement Projektphase (Phase) werden Arbeitsschritte im Prozessmodell zusammengefasst, die einen bestimmten gemeinsamen Zweck verfolgen (z.B. die Erstellung einer Softwarearchitektur). Aus diesem Grund ist es zumindest wahrscheinlich, dass Anwender zwischen verschiedenen Projektschritten einer Phase öfters wechseln. Einerseits können so Arbeitsergebnisse aus schon abgeschlossenen Aufgaben korrigiert werden; andererseits können Arbeitsergebnisse einer Aufgabe, die erst später zur Bearbeitung vorgesehen ist, schon im Vorgriff erstellt werden. Somit ist das Modellelement Projektphase neben dem festen Auswahlfenster für Aufgaben eine weitere Möglichkeit, um die im Segment „Entwicklungssituation“ enthaltenen Arbeitspakete festzulegen. Nach der Auswahl einer Aufgabe aus der Worklist wird zunächst der Reiter „Informationen“ (Abbildung 9-5) im Desktop-Bereich des ProcessNavigators angezeigt. Mitarbeiter erhalten hier Informationen (z.B. Arbeitsanweisungen) über die Ausführung des aktuell gewählten Prozessschrittes. Dieses Informationsfeld kann genutzt werden, um Anwender auf Besonderheiten des Arbeitsschrittes hinzuweisen und darauf, welche Gesichtspunkte der Aufgabe aus Sicht des QM-Standards besonders zu beachten sind. Eine weitere wichtige und aus QM-Sicht relevante Funktion dieses Reiters ist, dass Anwender die Möglichkeit haben, Kommentare zum aktuellen

136

9 Projektdurchführung

Arbeitsschritt abzugeben. Dadurch erhalten sie die Möglichkeit, Erfahrungen und Tipps zur Bearbeitung des Schrittes und damit Hinweise für andere Mitarbeiter abzugeben. Diese können einen wertvollen Beitrag zur Erweiterung des vorhandenen Unternehmenswissens leisten. Die Kommentare erlauben später auch, die getroffenen Entscheidungen und die Projektdurchführung einfach nachzuvollziehen. Diese Informationen werden in Phase 5 des Vorgehensmodells genutzt, um Verbesserungsmöglichkeiten am Prozesstyp zu identifizieren.

Abbildung 9-5:

Informationen und Arbeitsrichtlinien im ProcessNavigator

Ein weiteres Modellierungselement des Funktionalen Aspekts ist der Meilenstein. Meilensteine markieren einen Punkt im Projekt, an dem ein bestimmter inhaltlicher Fortschritt im Projekt erreicht wurde. So ist in einem Softwareentwicklungsprojekt beispielsweise die Anforderungsanalyse abgeschlossen oder die Grobarchitektur des Systems wurde festgelegt. In aller Regel wird an Meilensteinen auch das weitere Vorgehen im Projekt festgelegt. Dem ProcessNavigator kommt an dieser Stelle eine wichtige Dokumentationsfunktion zu. So muss die Entscheidung über das weitere Vorgehen dokumentiert werden. Insbesondere zwei Entscheidungen sind für die weitere Projektausführung im ProcessNavigator von Bedeutung: Einerseits das Fortsetzen des Projekts in der nächsten Phase und die Entscheidung nicht mit der nächsten Phase zu beginnen, da die Dokumente noch keinen ausreichenden Quali-

9.1 Phase 4.1: Unterstützung bei der Projektbearbeitung

137

tätsstand besitzen. In Abbildung 9-6 ist die Umsetzung von Meilensteinen im ProcessNavigator dargestellt.

Abbildung 9-6:

Meilensteine im ProcessNavigator

Im Prozessmodell können an Meilensteinen Dokumente hinterlegt werden, die zu diesem Zeitpunkt entweder abgeschlossen sein müssen oder einen bestimmten Reifegrad erreicht haben, der es erlaubt das Dokument in nachfolgenden Phasen zu nutzen; diese werden dem verantwortlichen Mitarbeiter (in der Regel dem Projektleiter) im ProcessNavigator zur Entscheidungsfindung angezeigt. Der Mitarbeiter kann die Dokumente einsehen, ihren Bearbeitungstand bewerten und für die nächste Projektphase freigegeben. Freigegebene Dokumente dürfen durch Mitarbeiter nicht mehr ohne weiteres verändert werden und bilden somit eine stabile Basis für die weitere Entwicklung in den nächsten Phasen; nicht freigegebene Dokumente müssen durch die Mitarbeiter überarbeitet werden. Dem Projektleiter werden weitere Planungsdaten des Meilensteins angezeigt, z.B. das geplante Abschlussdatum und die Soll- und Ist-Kosten. Außerdem können je nach Unternehmen weitere Daten in der Seite eingeblendet werden. Diese Informationen können vom Projektleiter genutzt werden, um ein umfassendes Bild vom Projektstatus zu erhalten und eine informierte Entscheidung über das weitere Projektvorgehen treffen zu können. Diese Entschei-

138

9 Projektdurchführung

dung kann zusätzlich in einem Textfeld begründet werden, um später die Entscheidung leichter nachvollziehen zu können. Wird durch den Projektleiter (oder einem entsprechenden Leitungsgremium) entschieden, dass das Projekt mit der nächsten Phase fortgesetzt werden kann, werden die freigegebenen Dokumente für die weitere Bearbeitung gesperrt. Auf diesem stabilen Dokumentenstand (oft auch als Baseline bezeichnet) können die Anwender in der nächsten Phase aufbauen und entsprechende neue Ergebnisse erarbeiten. Technisch bietet sich hier die Anbindung eines Konfigurationsmanagementwerkzeugs an den ProcessNavigator an, welches durch Versionierung und einen entsprechenden Zugriffsschutz diese Zugriffsregeln umsetzen kann. Dadurch wird es einerseits möglich die Entwicklungszustände eines Dokuments zu sichern, andererseits erlaubt es den Nutzern auf frühere Versionen des Dokuments zuzugreifen und die gegenüber diesen Versionen erfolgten Änderungen nachzuvollziehen. Für den Fall, dass die in der Projektphase erzielten Ergebnisse nicht den Anforderungen entsprechen, kann auch durch den Projektleiter beschlossen werden, nicht in die nächste Projektphase einzutreten. In diesem Fall werden die entsprechenden Dokumente nicht freigegeben und müssen überarbeitet werden. Der Meilenstein wird anschließend erneut zur Bewertung vorgelegt. Zusätzlich zu den zwei genannten Entscheidungsfällen kann durch die Projektleitung auch beschlossen werden, das Projekt z.B. wegen zu hoher Risiken abzubrechen. Unter diesen Umständen hat der Projektnavigator nur noch eine Dokumentationsaufgabe. So müssen insbesondere die Gründe, die zum Projektabbruch geführt haben, hinterlegt werden, um in folgenden Projekten einen Abbruch aus gleichen Gründen nach Möglichkeit zu vermeiden. Tabelle 9-1 fasst die Umsetzung der Elemente des Funktionalen Aspekts vom Prozessmodell über das Projektmodel zusammen.

9.1 Phase 4.1: Unterstützung bei der Projektbearbeitung Tabelle 9-1:

139

Umsetzung der Elemente des Funktionalen Aspekts

Prozessmodell

Projektmodell

ProcessNavigator

Prozessbaustein

Projektbaustein

Aufgaben in der Worklist

Phase

Eingrenzung der im Segment „Entwicklungssituation“ angezeigten Arbeitspakete

Meilenstein

Unterstützung des Projektleiters bei der Entscheidungsfindung mit dem Erreichen eines Meilensteines.

9.1.3

Der Verhaltensorientierte Aspekt im ProcessNavigator

Der Verhaltensorientierte Aspekt beschreibt die Reihenfolge, in der Prozessschritte im Prozess ausgeführt werden und wird im Prozess- und Projektmodell durch Kontrollflusskanten und -konnektoren repräsentiert. Im ProcessNavigator beeinflussen sie maßgeblich die Reihenfolge, in der Arbeitspakte in der Worklist angezeigt werden. Durch Kontrollflusskanten wird zwischen den Arbeitspaketen im Prozessmodell eine Vorgänger- und Nachfolgebeziehung definiert. Diese Beziehungen werden genutzt, um nach Abschluss eines Arbeitspakets die jeweils nächsten zu bestimmen. Kontrollflusskonnektoren haben die Funktion von Split- oder Merge-Operatoren; entsprechend ihrer vordefinierten Semantik leiten sie die parallele Ausführung von Aktivitäten (AND, OR) ein oder aber eine Entscheidung (XOR, OR). Der OR-Operator nimmt eine Sonderstellung ein, da durch ihn sowohl parallele Aktivitäten als auch Entscheidungen eingeleitet werden können. Im ProcessNavigator wird die in der Worklist vorgeschlagene Ausführungsreihenfolge ausschließlich durch den Kontrollfluss bestimmt. Diese Entwurfsentscheidung hat im Rahmen des FORFLOW-Projekts gezeigt, dass sie geeignet ist, um Entwicklungsprojekte sinnvoll zu unterstützen. Sie ist auch deshalb gerechtfertigt, da Anwender durch den Aufbau der PN-Worklist aus verschiedenen Segmenten jederzeit die Möglichkeit haben, vom vorgegebenen Kontrollfluss abzuweichen. Die Worklist, wie sie im ProcessNavigator enthalten ist, kann außerdem jederzeit durch weitere Segmente erweitert werden. Dadurch kann die Beschränkung auf den Kontrollfluss aufgeweicht und sogar aufgehoben werden. So ist beispielsweise die folgende Auswahlstrategie

140

9 Projektdurchführung

für Prozessschritte in einem Worklist-Segment möglich: „Alle Prozessschritte, für die die notwendigen Eingangsdaten vorhanden sind“. Diese Strategie wertet nur den Datenorientierten Aspekt aus und ignoriert den Kontrollfluss. Abbildung 9-7 stellt den Einfluss des Kontrollflusses auf die Worklist graphisch an den Beispielen SEQUENZ (normale Abfolge), AND und XOR (Split-Operation) dar. Das Beispiel zeigt die Aufgabensicht „Nächste Schritte“, da diese von den in Abschnitt 9.1.2 vorgestellten Segmenten dem Kontrollfluss am striktesten folgt. In allen drei Beispielen wird davon ausgegangen, dass der Schritt „A“ zuerst ausgeführt wird und anschließend „B“ (in der Abbildung unterstrichen) gewählt wird. Prozessmodell

Worklist – Nächste Schritte

SEQUENZ A

AND

B

B A

C

B

D

D C

C

B

B

C

C

D

D

A C Abbildung 9-7:

B C

B A

OR

D

D C

XOR

B D

Einfluss des Kontrollflusses auf die Worklist

SEQUENZ: In dem Beispiel wir eine einfache Abfolge der Schritte „A“, „B“ und „D“ gezeigt. Nachdem Schritt „A“ abgeschlossen ist, wird „B“ in der Worklist angezeigt; nach Abschluss von „B“ wird „D“ angezeigt. Der Nutzer hat hier keine Auswahlmöglichkeit und wird der Reihe nach durch die Arbeitsschritte geleitet.

9.1 Phase 4.1: Unterstützung bei der Projektbearbeitung

141

AND:

Dieses Beispiel zeigt die Aufspaltung des Prozesses in zwei parallele Ausführungsstränge. Nach Abschluss von „A“ kann der Nutzer wählen, ob er Schritt „B“ oder Schritt „C“ ausführen möchte. Bevor er jedoch mit „D“ beginnen kann muss zuerst „C“ bzw. „B“ bearbeitet werden. Im Beispiel wurde als erstes „B“ ausgewählt, entsprechend ist als nächstes „C“ in der Worklist eingetragen.

XOR:

Wie ein AND-Konnektor erzeugt auch ein XOR-Konnektor wieder eine Aufspaltung im Kontrollfluss. Auch hier kann der Nutzer wieder wählen, ob zuerst „B“ oder „C“ ausgeführt werden soll. Durch die XOR-Semantik muss jedoch nur einer der beiden Schritte, also entweder „B“ oder „C“, ausgeführt werden. Entsprechend ist im Beispiel nach der Ausführung von „B“ in der zweiten Worklist der Schritt „D“ eingetragen. Durch das XOR wird also eine Entscheidung zwischen den Schritten „B“ und „C“ erzeugt. Im Gegensatz zu dem Modellierungselement „Entscheider“ (nachfolgend vorgestellt) wird diese jedoch nur in der Worklist dargestellt. Bei diesem Konstrukt ist es ausreichend einen der Schritte aus der Worklist auszuwählen; eine Dokumentation der Gründe, die zur Entscheidung geführt haben, ist nicht vorgesehen. Aus diesem Grund wird dies auch als implizite Entscheidung bezeichnet.

OR:

Ein OR-Konnektor ist eine Mischform aus einem AND- und einem XORKonnektor. Die Bedeutung des Konstrukts ist die folgende: „Mindestens einer der nachfolgenden Arbeitsschritte muss ausgeführt werden“. Der Nutzer hat wieder die Auswahl zwischen den beiden Schritten „B“ und „C“. Nach der Ausführung von einem der beiden Schritte kann er jedoch entscheiden, ob er den anderen Schritt („C“ oder „B“) noch ausführen will oder er kann stattdessen mit „D“ fortsetzen. In der zweiten Worklist sind nach der Ausführung von B demzufolge die beiden Schritte „C“ und „D“ eingetragen. Entscheidet sich der Nutzer für „D“, so wird nach seiner Ausführung der Schritt „C“ ebenfalls aus der Worklist gelöscht. Es wird davon ausgegangen, dass der Schritt „C“ auch in Zukunft nicht mehr ausgeführt werden soll.

Die in Abbildung 9-7 dargestellten Beispiele betreffen nur die Aufgabensicht „Nächste Schritte“. Der Nutzer hat durch die Aufgaben, die in den anderen beiden WorklistSegmente „Entwicklungssituation“ bzw. „Alle Schritte“ eingetragen sind, weiterhin die Möglichkeit sich flexibel im Entwicklungsprozess zu bewegen. Die entsprechenden Anforderungen (Kapitel 4 – Anforderungen #2 und #3) an Prozessmanagementsysteme werden also durch den Kontrollfluss nicht verletzt.

142

9 Projektdurchführung

Entscheider sind ein weiteres Modellierungselement im Prozessmodell. Durch sie wird eine explizite Entscheidung über den zukünftigen Projektverlauf im Prozesstyp modelliert. „Explizit“ heißt in diesem Zusammenhang, dass die Nutzer ihre Entscheidung im System dokumentieren müssen, um somit später den Entscheidungsgrund nachvollziehbar zu