Prozessorientierten Qualitatsmanagementsystemen: Konzept zur Implementierung

Matthias Faerber Prozessorientiertes Qualitätsmanagement GABLER RESEARCH Matthias Faerber Prozessorientiertes Qual...

Author: Matthias Farber

67 downloads 1668 Views 2MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

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:


Abbildung 3-6:


Abbildung 3-7:


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:


Tabelle 3-4:


Tabelle 3-5:


Tabelle 3-6:


Tabelle 3-7:


Tabelle 3-8:


Tabelle 3-9:


Tabelle 3-10:


Tabelle 6-1:

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

Tabelle 6-2:


Tabelle 6-3:


Tabelle 6-4:


Tabelle 6-5:


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:


Tabelle 9-10:


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


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


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-


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


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.


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


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


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


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


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


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


Systemelemente realisiert 0..1 Y 0..*

System entworfen


Unterauftrag

0..* Y 0..1

System integriert

Y 1..*

System spezifiziert

Abbildung 2-2:


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


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


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


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.


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


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


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


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


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


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-


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


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


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


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


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.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


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-


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


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


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


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


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:


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


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.


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


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


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


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


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:


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


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.


Tailoring

RG3

RG2

Ausführungsebene

M2: Sprachdesign M1: Prozessplanung

Ermitteln von Verbesserungspotenzialen

M1: Projektplanung


Messen

Planen

Planungsebene

53

Bereitstellen von Ressourcen

Abbildung 3-5:


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


Tabelle 3-7:


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-


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


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:


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.


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


RG4 Projektüberwachung/ Analyse von Abweichungen

M0: Messdatenbank

Projektsteurerung

Planungsebene

Definition von Zielen für das Projekt

Abbildung 3-6:


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


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


59

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


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


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.


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


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:


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


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


[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


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:


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


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


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


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.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


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


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:


RG 2 Ziel

Beschreibung


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


87

RG 2 Ziel

Beschreibung


Art der Umsetzung

Ziel 2.5

Definition der Anforderungen an Arbeitsprodukte


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:


RG 3 Ziel

Beschreibung

Ziel 3.1

Aufstellung eines Standardprozesses und seiner Schnittstellen

Ziel 3.2


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


RG 3 Ziel

Beschreibung


Art der Umsetzung

Ziel 3.3

Ableitung eines Projekts aus dem Standardprozess

Ziel 3.4

Festlegung der im Projekt eingesetzten Verantwortlichkeiten und der Infrastruktur


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.


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:


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


Tabelle 6-5:


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


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.


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


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.


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




Iteration geplant

System entworfen

Abbildung 7-3:

Abnahme erfolgt

System integriert


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


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


Ausgang


Prozesstyp

Tester

[...]

SoftwareTestsuite

Tester

Systemkomponenten testen

T estumgebung

Software Module

Entwickler

Entwicklung der Lösungskomponenten

IDE


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


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


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


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



4 Fehler aus Integrationstest



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



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

T estumgebung




-/-


-/-

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 -/-


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.


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


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:


Ziel 1.2:

Erstellen der geforderten Arbeitsergebnisse

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


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


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


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


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


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-


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.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


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


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.


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


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.


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


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)


Detaildesign Software



Eingang

Eingang Schnittstellenbeschreibung (Detail) Detaildesign Software

IDE

Schnittstellenbeschreibung (Detail) Detaildesign Software



-/Entwickler


Testanforderungen Schnittstellenbeschreibung (Detail) Detaildesign Software Software Module

Software Module

T estumgebung




-/-

Entwicklungsumgebung definieren


-/-

Entwickler

Tester

Software T estsuite

Software T estsuite

[...]

Testanforderungen


Testanforderungen


-/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


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


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:


Ziel 1.2:


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


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


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.


129

Testanforderungen


Schnittstellenbeschreibung (Detail)


4



Fehler aus Integrationstest

1


Detaildesign überarbeiten

Eingang

Projekt genehmigt

Projekt definiert

Angebot abgegeben

Projekt beauftragt

Proje abgeschlo kt ssen

Abnahme erfolgt

ja Schnittstellenbeschreibung (Detail)

IDE

nein


Fehler analysieren -/-

-/[...]

Testanforderungen

Lieferu durchgef ng ührt

Iteration geplant


Schnittstellenbeschreibung (Detail)

Testergebnisse

Detaildesign Software Software Module


T estumgebung Testergebnisse

System entworfen

Detaildesign muss überarbeitet werden

Testergebnisse Entwicklung der Lösungskomponenten

Entwickler

System spezifiziert


System integriert

Software Module


-/-

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


Testanforderungen

Nutzerdokumentation

Nutzerdokumentation

Testergebnisse

Testergebnisse

Software Module

Software Module

-/-

Ausgang

T ester



Fehler in Softwaremodulen 4 Fehler aus Integrationstest

Fehler im Detaildesign Detaildesign 1 überarbeiten


Eingang Schnittstellenbeschreibung (Detail) Detaildesign Software

Testergebnisse Entwicklung der Lösungskomponenten


ja nein Detaildesign muss überarbeitet werden

IDE

Entwickle r


[...]

-/Fehler im Detaildesign Testergebnisse

Software Module

estumgebun T g Entwicklungsumgebnung definieren Entwickle r



-/-

Tester

-/-


Testergebnisse bewerten [...]


-/-

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


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



4

Segment Y „Design Situation“


Fehler in Softwaremodulen Fehler in Softwaremodulen

Z


Iteration geplant

Segment X „Nächste Schritte“


Abnahme erfolgt

System spezifiziert


Fehler aus Integrationstest



Eingang ja Schnittstellenbeschreibung (Detail) Detaildesign Software

IDE

nein Testergebnisse



Detaildesign muss überarbeitet werden

-/-

Entwickler

[...]


Fehler im Detaildesign Testergebnisse

Y

Software Module


Testumgebung Entwicklungsumgebnung definieren


Systemkomponenten testen -/-

Entwickler

X Testanforderungen


-/Tester

Worklist Konfiguration


-/-

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 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


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


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


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


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


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


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-


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


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


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.


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


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 machen. In Abbildung 9-8 ist die Umsetzung eines Entscheiders im ProcessNavigator abgebildet. Im oberen Bereich wird die zu treffende Entscheidung beschrieben. Die Menge der darunter angezeigten Auswahlmöglichkeiten ergibt sich dabei aus der Anzahl der aus dem Entscheider laufenden Kontrollflusskanten mit deren Benennung. Nachdem ein Anwender seine Auswahl getroffen hat, muss er die Gründe, die zu seiner Entscheidung geführt haben in einem Textfeld dokumentieren. Wie schon das Kommentarfeld im Reiter „Informationen“, dient auch diese Begründung dazu, Entscheidungen im Prozessablauf nachvollziehbar zu machen und die im Unternehmen gewonnene Erfahrung über die Prozessumsetzung (das Prozesswissen) explizit abzulegen.

Abbildung 9-8:

Entscheider im ProcessNavigator

Zusätzlich zu den oben beschriebenen Elementen sind noch die Elemente Prozessstart und Prozessende sowie Externer Ein- und Ausgang im Verhaltensorientierten Aspekt enthalten. Prozessstart und -ende markieren jeweils den Beginn und das Ende des Prozesses oder eines Unterprozesses. Durch sie kann der ProcessNavigator ermitteln wo mit der Ausführung begonnen werden soll und wo diese beendet werden kann. Externe Ein- und Ausgänge werden genutzt um zwei Schritte aus unterschiedlichen Vaterprozessen durch einen Kontrollfluss zu verbinden. Aus Sicht


143

der Prozessausführung unterscheiden sie sich dabei nicht von normalen Kontrollflusskanten. In der nachfolgenden Tabelle 9-2 werden die Elemente des Verhaltensorientierten Aspekts nochmals zusammenfassend dargestellt. Tabelle 9-2:

Umsetzung der Elemente des Verhaltensorientierten Aspekts

Prozessmodell Kontrollfluss Kontrollflusskonnektoren (AND, XOR, OR)

Projektmodell

ProcessNavigator Festlegung des Ablaufs der Arbeitspakete im ProcessNavigator

Entscheider

Darstellung der Entscheidungsalternativen im ProcessNavigator

Prozessstart und -ende

–

Externer Ein- und Ausgang

–

9.1.4

Der Datenorientierte Aspekt im ProcessNavigator

Der Datenorientierte Aspekt beschreibt die im Prozess enthaltenen Daten und Dokumente. Aufgabe des ProcessNavigators ist es, diese dem Nutzer zur richtigen Zeit zur Verfügung zu stellen. Den Nutzern des ProcessNavigators sollen auf diese Weise immer jene Daten zur Verfügung stehen, die für die Bearbeitung des Arbeitsschrittes notwendig sind. Über die im Prozessmodell an jedem Schritt definierten Eingangs- und Ausgangsdaten kann der ProcessNavigator ableiten, zu welchen Zeitpunkten im Prozess ein bestimmtes Datum benötigt wird. Im Vergleich mit anderen Workflow-Management-Systemen, wie solchen, die auf der Sprache BPEL [WSBPEL 2007] basieren, ist im ProcessNavigator kein eigentlicher Datentransport realisiert. In BPEL-Systemen verwaltet das Workflow-ManagementSystem die Daten in Variablen. Diese werden einem Arbeitsschritt (BPEL-Activities) als Eingangsdaten zugeordnet bzw. als Ausgangsdaten von den Schritten erzeugt. Der Austausch zwischen den Schritten basiert auf einem Nachrichtenmechanismus. Der ProcessNavigator verwaltet hingegen die Daten nicht selbst, sondern nur die Verweise auf einen Speicherort. Dieses Konzept erlaubt es dem ProcessNavigator sehr flexibel auf Änderungen in der Ausführungsreihenfolge zu reagieren. Während in

144


BPEL-Systemen der Nachrichtenfluss und somit auch der Kontrollfluss fest im Ausführungssystem vorgegeben ist, können im ProcessNavigator Prozessschritte auch dann gestartet werden, wenn noch nicht alle Eingangsdaten vorhanden sind. Wie in Abschnitt 9.1.3 beschrieben, kann dies durch die Wahl anderer Segmente in der PNWorklist aufgeweicht oder geändert werden. Im Forschungsprojekt FORFLOW hat sich gezeigt, dass es zur Unterstützung von Produktentwicklungsprozessen nicht notwendig ist, innerhalb des Systems den Aufbau und die Struktur der Dokumente zu kennen [Faerber et al. 2009]. Vielmehr reicht es hier aus, die Daten als „Black Box“ zu betrachten, und dem Anwender ein ganzes Datum, das heißt zumeist das Gesamtdokument zur Bearbeitung vorzulegen. Der ProcessNavigator speichert alle Daten und Dokumente des Entwicklungsprozesses in einem externen System. Durch die Verwendung von Verweisen auf den externen Speicherplatz der Daten können im ProcessNavigator verschiedene Datenhaltungskomponenten (z.B. Konfigurationsmanagementsysteme, Dokumentenmanagementsysteme oder PDM-Systeme) für den Nutzer transparent eingebunden werden.

Abbildung 9-9:

Anzeige von Daten und Dokumenten im ProcessNavigator


145

In Abbildung 9-9 ist die Umsetzung des Datenorientierten Aspekts im ProcessNavigator abgebildet. Die im Prozesstyp enthaltenen Daten und Dokumente werden im Reiter „Dokumente“ dargestellt. Dieser ist unterteilt in einen Abschnitt Eingangsdokumente und einen Abschnitt Ausgangsdokumente. Ob ein Datum als Eingangs- oder Ausgangsdokument behandelt wird, ist durch den Datenfluss im Prozessmodell festgelegt. Eingangsdaten sind alle Daten, die an einem Datenfluss modelliert sind, der von einem beliebigen Arbeitspaket zum aktuellen Arbeitspaket führt. Ausgangsdokumente sind all jene Dokumente, die an Datenflüssen vom aktuellen Arbeitspaket zu einem anderen Arbeitspaket modelliert sind. Da die Anwender über die Ausführungsreihenfolge der Projektschritte entscheiden, kann es vorkommen, dass noch nicht alle ursprünglich vorgesehenen Dokumente an einem Arbeitsschritt vorhanden sind. Dies kann insbesondere dann passieren, wenn Mitarbeiter Aufgaben aus einer der Worklist-Segmente „Entwicklungssituation“ oder „Alle Schritte“ wählen und einen Arbeitsschritt, verglichen mit dem Standardkontrollfluss, zu früh ausführen. Dies kann dann vorkommen, wenn Ergebnisse früher im Projekt vorliegen, als es bei der Planung abzusehen war, oder es durch eine neue Projektsituation (z.B. Kundenanfragen) nötig wird, ein Dokument vorab zu erstellen. Aus diesem Grund sind die Eingangsdokumente in verfügbare und nicht verfügbare Eingangsdokumente unterteilt. Verfügbare Eingangsdokumente können im ProcessNavigator geladen und bearbeitet werden. Außerdem werden vorhandene Dokumenteigenschaften wie beispielsweise der Autor oder das Erstelldatum angezeigt. Bei nicht verfügbaren Eingangsdokumenten hingegen wird angezeigt, in welchem Arbeitspaket und von wem das Dokument erzeugt werden sollte. Der Anwender hat nun die Möglichkeit, zuerst das ursprüngliche Arbeitspaket auszuführen und das Dokument zu erstellen oder das aktuelle Arbeitspaket ohne das Eingangsdokument durchzuführen. Die Entscheidung über das Vorgehen liegt immer beim Anwender; durch den ProcessNavigator werden nur die nötigen Informationen bereitgestellt. Die Ausgangsdaten werden im unteren Teil des Dokumentenabschnitts angezeigt. Der Anwender erhält Informationen darüber, welche Dokumente erzeugt werden müssen und welchem Zweck diese dienen. Außerdem werden zu jedem Dokument, falls vorhanden, Templates und verwandte Dokumente angezeigt. Templates werden Dokumenten im Prozessmodell zugeordnet und können somit vom ProcessNavigator einfach zugeordnet werden. Verwandte Dokumente werden aufgrund des im Prozess verwendeten Dokumententyps identifiziert. Somit können Dokumente, die in anderen Projekten mit demselben Prozesstyp als Basis erzeugt wurden, einfach zugeordnet werden. Anwender erhalten somit neben dem leeren Template auch verwandte Informationen aus anderen Projekten und können somit vorhandenes Wissen wiederverwenden.

146


Zum Import von Dokumenten in den ProcessNavigator stehen verschiedene Möglichkeiten zur Verfügung. Anwendungen, die in das Prozessmanagementsystem integriert sind oder an dieses angepasst wurden, besitzen bereits die nötigen Information über Arbeitspaket und Datenelement und können mit der Speicherfunktion der Anwendung Dokumente direkt in den ProcessNavigator importieren. Da diese direkte Integration der Anwendungen mit dem ProcessNavigator die Erstellung von speziellen Modulen und Schnittstellen voraussetzt, wird eine zweite Möglichkeit zum Datenimport, das Hochladen der Dokumente in das System, realisiert. Dazu muss der Nutzer im System aus einer Liste mit den zu erstellenden Dokumenten (formales Datum) das gewünschte auswählen und kann anschließend das Dokument in den ProcessNavigator importieren. Im Fall von externen Daten (z.B. CAD-Daten), bei denen das Dokument nicht als Datei vorliegt, kann auch ein Verweis auf den Speicherort hinterlegt werden. Im Produktentwicklungsprozess kann es vorkommen, dass während der Prozessausführung ein Dokument neu angelegt wird, das vorher nicht im Prozesstyp eingeplant war. In diesem Fall kann der Nutzer kein entsprechendes formales Datum auswählen. Stattdessen werden vom System verschiedene Parameter (Zweck, Arbeitsschritt, Dokument, Organisationseinheit) bereitgestellt, mit denen das Dokument in den Prozess eingeordnet werden kann. Der Zweck des Dokuments gibt an, welches Ziel mit diesem verfolgt wird. Die Parameter Organisationseinheit, Arbeitsschritt oder Dokument können genutzt werden, um das neue Dokument in Relation zu vorhandenen Elementen (Aspekten) des Prozesstyps zu setzen. So kann ein Dokument einem Mitarbeiter oder einer Gruppe von Mitarbeitern zugeordnet werden, es kann als Eingangsdokument eines Arbeitsschrittes definiert oder in Beziehung zu anderen Dokumenten gesetzt werden. Gerade die Eigenschaft Dokumente in Beziehung zu anderen Dokumenten zu setzen, erweitert die Möglichkeit zur Einbindung eines neuen Dokuments (in Beziehung zu den vorhandenen Elementen) erheblich. Dies ist insbesondere der Fall, da Anwender nicht nur die Möglichkeit haben vorhandene Beziehungstypen zu nutzen, sondern bei Bedarf auch neue Beziehungstypen zu definieren. Soll beispielsweise die Eigenschaft gespeichert werden, dass in einem Dokument die Review-Ergebnisse zu einem anderen Dokument enthalten sind, so kann dies mit folgender Aussage abgebildet werden: „Review Dokument X“ ISTREVIEWVON „Dokument Y“. Existiert die Beziehung „ISTREVIEWVON“ noch nicht im System, so kann diese durch den Nutzer neu angelegt werden. Die Umsetzung dieser Systemeigenschaft im Speichersystem wird in Kapitel 12 gezeigt.


147

Im Prozessmodell kann zwischen optionalen und zwingenden Dokumenten unterschieden werden. Optionale Dokumente sind solche, die zwar im Prozesstyp vorgesehen, aber für eine Bearbeitung nicht zwangsläufig erforderlich sind. Zwingende Dokumente hingegen sind im Prozesstyp erforderlich und müssen durch den Anwender erstellt werden; sie werden beispielsweise durch Gesetzesvorgaben oder durch QM-Standards gefordert. Diese Dokumente dürfen also nicht ohne weiteres bei der Bearbeitung ausgelassen werden. Im klassischen Workflow-Konzept verhindert das Ausführungssystem im Fall eines nicht erstellten Dokuments das erfolgreiche Beenden eines Arbeitspaketes und erzwingt die Erstellung des Dokuments. Auch im ProcessNavigator wird die Erstellung der Dokumente gefordert; um jedoch zu verhindern, dass Anwender leere oder ungültige Dokumente im System abgelegen, kann statt des Dokuments auch ein Kommentar als „Stellvertreter“ abgegeben werden. In diesem Kommentar muss der Mitarbeiter erklären, warum das entsprechende Dokument nicht erstellt wird. Bei der Meilensteinüberprüfung kann der Projektleiter somit diese Gründe überprüfen und gegebenenfalls die nachträgliche Bearbeitung des Dokuments veranlassen. In der folgenden Tabelle 9-3 werden die Elemente des Datenorientierten Aspekts in einer Übersicht zusammengestellt. Tabelle 9-3:

Umsetzung der Elemente des Datenorientierten Aspekts

Prozessmodell

Projektmodell

ProcessNavigator

Datenelement

Anzeige als Eintrag im Abschnitt Dokumente des ProcessNavigators

Datenfluss

Identifiziert ein Dokument als Eingangs oder Ausgangsdokument für ein Arbeitspaket.

9.1.5

Der Organisatorische Aspekt im ProcessNavigator

Der Organisatorische Aspekt beschreibt die Einbindung der Aufbauorganisation in die Prozessausführung. Im ProcessNavigator wird dies durch eine Zuordnung der Arbeitspakete zu Mitarbeitern in der Worklist realisiert. Abbildung 9-10 zeigt diese nach der Anwendung des Organisatorischen Aspekts. Im Vergleich zu der WorklistKonfiguration, wie sie in Abbildung 9-4 dargestellt ist, werden nur noch jene Aufga-

148


ben dargestellt, die dem Mitarbeiter entsprechend der Projektplanung zugeordnet sind. Diese mitarbeiterspezifische Aufgabenliste wird im ProcessNavigator als „Meine Aufgaben“ bezeichnet und macht damit für den Mitarbeiter deutlich, dass die hier angezeigten Aufgaben durch ihn zu bearbeiten sind. In [Bussler 1998] findet sich eine ausführliche Darstellung, wie der Organisatorische Aspekt in Prozessmodelle eingebunden wird. Die Arbeit beschreibt unter anderem die folgenden zwei Mechanismen für die Zuordnung von Arbeitspaketen zu Mitarbeitern: Zuordnungsregeln und Synchronisationsregeln. Zuordnungsregeln definieren, welche Arbeitspakete ein Mitarbeiter auszuführen hat. Zuordnungsregeln wirken im Bezug auf die Gesamtmenge der im Projekt vorhandenen Arbeitspakete wie ein Auswahlfilter. Nur noch jene Schritte, die auch dem aktuell angemeldeten Nutzer zugeordnet werden können, werden auch in der Worklist angezeigt.

Abbildung 9-10: Anwendung des Organisatorischen Aspekts in der Worklist

Wie in Abschnitt 8.1 (Vorgehen zur Erstellung des Projektmodells) beschrieben, werden bei der Projektplanung mehrere Möglichkeiten vorgesehen, um einem Mitarbeiter eine Aufgabe zuzuweisen. So kann dies einerseits durch die feste Zuordnung einer Aufgabe zu einem Mitarbeiter erfolgen; andererseits können an einem Schritt auch Eigenschaften (Fähigkeiten) festgelegt werden, die ein Mitarbeiter besitzen muss, um den Schritt auszuführen. Dabei soll der Begriff „Eigenschaft“ bewusst weit gefasst werden. Eine Eigenschaft ist beispielsweise die Zugehörigkeit zu


149

einer Gruppe, eine bestimmte Rolle im Entwicklungsprozess, ein bestimmter Status aufgrund der Projekthistorie oder eine bestimmte Funktion bzw. Stellung in der Organisationshierarchie. Die Zugehörigkeit zu einer Gruppe ergibt sich beispielsweise durch die Ausbildung oder Funktion des Mitarbeiters (z.B. Entwickler oder Tester); so wird beispielsweise die Aufgabe „Erstellen des Softwaremoduls“ einem Entwickler zugewiesen. Die Zuordnung eines Schrittes aufgrund der Projekthistorie kann dann sinnvoll sein, wenn es erwünscht ist, dass zwei Schritte im Prozess von der gleichen Person ausgeführt werden, weil diese Aufgaben einen engen inhaltlichen Bezug zueinander besitzen. Die Stellung eines Mitarbeiters in der Organisationshierarchie kann genutzt werden um festzulegen, dass beispielsweise ein Review oder die Abnahme eines Meilensteins durch den Vorgesetzten zu erfolgen hat. Die drei genannten Beispiele sind nur ein kleiner Teil der Möglichkeiten, aufgrund derer einem Mitarbeiter ein bestimmter Prozessschritt zugewiesen werden kann. Oftmals kommen hierzu noch domänenspezifische Beziehungen, die erst bei einer genauen Analyse der Anwendungsdomäne erkannt werden. Aus diesem Grund wurde in [Zeising 2009] eine Zuweisungssprache entwickelt, die Organizational Policy Language (OPL), mit der die Zuweisung von Aufgaben zu Mitarbeitern sehr flexibel erfolgen kann. In dieser Sprache können verschiedene Ausdrücke definiert werden, die anschließend analysiert und eine Datenabfragesprache übersetzt werden. Somit kann die Zuordnung von Arbeitsschritten zu Mitarbeitern aus der Speicherschicht des ProcessNavigators (Abschnitt 12.2.2) mit Hilfe einfacher Ausdrücke abgefragt werden. In Tabelle 9-4 sind verschiedene Ausdrücke dieser Anfragesprache dargestellt. Tabelle 9-4:

Beispiele von Zuweisungsregeln in der OPL

Ausdruck

Beispielausdruck

Bedeutung des Ausdrucks

‘…’

‘Schmidt’

Der Arbeitsschritt wird dem Mitarbeiter Schmidt direkt zugewiesen.

{‘…’}

{‘Entwickler’}

Der Arbeitsschritt wird einem Mitarbeiter aus der Gruppe der Entwickler zugewiesen.

150


Ausdruck

Beispielausdruck

Bedeutung des Ausdrucks

[‘…’]

[‘Produkt gestalten’] Zuordnung von Arbeitsschritten zu Mitarbeitern aufgrund der Ausführungshistorie. Der Arbeitsschritt wird hier dem Mitarbeiter zugewiesen, der den Arbeitsschritt „Produkt gestalten“ ausgeführt hat.

{‘…’} or {‘…’}

{‘Entwickler’} or {‘Tester’}

Der Arbeitsschritt wird entweder einem Mitarbeiter aus der Gruppe der Entwickler oder der Tester zugewiesen. Beide Gruppen bekommen die Aufgabe in der Worklist angezeigt und können die Aufgabe bearbeiten.

Nutzung von Konzepten der Speicherschicht

?me :istVorgesetzterVon {‘Entwickler’}

Der Arbeitsschritt wird dem Vorgesetzten (supervisor) der Gruppe der Entwickler zugewiesen. „?me“ ist eine Variable der Sprache, die an den angemeldeten Nutzer gebunden ist. „:istVorgesetzterVon“ eine Beziehung innerhalb der Organisationsstruktur (Abschnitt 12.2.2).

Am letzten Beispiel der Tabelle (?me :istVorgesetzterVon {‘Entwickler’}) lässt sich die Funktionsweise der Sprache am besten verdeutlichen. Der Ausdruck stellt ein 3-Tupel dar, bestehend aus „?me“, „:istVorgesetzterVon“ und „{‘Entwickler’}“. „?me“ ist eine im ProcessNavigator gebundene Variable, die immer den angemeldeten Nutzer beschreibt. „:istVorgesetzterVon“ ist eine in der Speicherschicht definierte Beziehung zwischen zwei Konzepten und „{‘Entwickler’}“ ist ein anderer Ausdruck in der OPL. Dieses wird von der OPL in einen gültigen Datenanfrageausdruck übersetzt und an die Speicherschicht gesendet. Von dieser wird als Ergebnis entweder „true“ oder „false“ zurückgeliefert; „true“ falls der angemeldete Nutzer ein Vorgesetzter eines Entwicklers ist, sonst „false“.


151

Da die Definition des 3-Tupel-Schema für die meisten Modellierungsfälle zu aufwändig ist, wurde für häufig genutzte Zuweisungsregeln eine vereinfachte Notation definiert. Die ersten drei Ausdrücke (‘…’, {‘…’} und [‘…’]) stellen somit eine Vereinfachung dar. So wird der Ausdruck „{‘…’}“ von der OPL intern zu dem folgenden Ausdruck erweitert: ?group :member ?me and ?group foaf:name “Entwickler” Der angemeldete Nutzer muss also Mitglied einer Gruppe sein und diese Gruppe muss den Namen „Entwickler“ haben. „?group“ definiert hier wieder eine Variable. Die verschiedenen Ausdrücke der OPL können miteinander kombiniert werden, um komplexe Zuordnungsregeln zu definieren. Zusätzlich können, wie in den Beispielen gezeigt, auch Konjunktionen und Disjunktionen in der OPL genutzt werden. Die Stärke dieses Ansatzes liegt vor allem in seiner Erweiterbarkeit. So können die verwendeten Beziehungen zwischen den Organisationseinheiten („istVorgesetzterVon“) beliebig definiert und an die Erfordernisse des Unternehmens angepasst werden. Das Konzept und seine Umsetzung wird in [Zeising 2009] detailliert diskutiert. Synchronisationsregeln legen im ProcessNavigator fest, wie oft (bzw. von wie vielen Mitarbeitern) ein bestimmtes Arbeitspaket bearbeitet werden muss, bevor dieses als abgeschlossen markiert werden kann. Auf diese Weise kann beispielsweise bei Reviews oder Entscheidungen das 4-Augen-Prinzip implementiert werden; dieses besagt, dass ein Review immer von zwei Personen durchgeführt werden muss. Im Fall des 4-Augen-Prinzips wird ein Arbeitsschritt dann bei beiden Mitarbeitern in der Worklist eingestellt. Der Arbeitsschritt wird erst dann als abgeschlossen markiert, wenn beide Mitarbeiter den Schritt (z.B. das Review) abgeschlossen haben. Neben der Worklist-Konfiguration „Meine Aufgaben“ hat der Anwender immer auch Zugriff auf „Alle Aufgaben“ im Projekt. Damit kann er auch Arbeitspakete, die ursprünglich anderen Mitarbeitern zugeordnet wurden, einsehen oder bearbeiten. Inwieweit dies notwendig ist, muss von Fall zu Fall von den Mitarbeitern entschieden werden. Im Sinne einer vollkommen flexiblen Prozessunterstützung bietet jedoch der ProcessNavigator die entsprechenden Möglichkeiten; die Entscheidung über die Fortsetzung des Projekts verbleibt immer beim Nutzer und wird durch das Prozessmanagementsystem lediglich unterstützt. In Tabelle 9-5 ist die Umsetzung der Modellierungselemente des Organisatorischen Aspekts zusammengefasst.

152


Tabelle 9-5:

Umsetzung der Elemente des Organisatorischen Aspekts

Prozessmodell

Projektmodell

ProcessNavigator

Organisationseinheit

Mitarbeiter

Legen die Zuordnung der Arbeitspakete zu Mitarbeitern fest.

9.1.6

Der Operationale Aspekt im ProcessNavigator

Der Operationale Aspekt beschreibt die Einbindung von Anwendungen und Werkzeugen in den Prozess. Um die Unterschiede der Einbindung des Operationalen Aspekts zwischen dem klassischen Konzept und dem ProcessNavigator zu verdeutlichen, soll zunächst ein Blick auf das klassische Konzept geworfen werden. In klassischen Workflow-Management-Systemen ist der Operationale Aspekt einer der Kernaspekte einer jeden Workflow-Anwendung. Anwendungen werden vom System nach dem Aufruf der jeweiligen Arbeitsschritte vollautomatisiert gestartet und mit den notwendigen Daten versorgt. Anwendungen und Werkzeuge werden in diesem Fall direkt in den Workflow integriert; in der Workflow-Sprache BPEL [WSBPEL 2007] wird dies beispielsweise durch den Aufruf von Web Service-Schnittstellen realisiert. Ein weiteres Merkmal klassischer Workflow-Management-Systeme ist die Zuordnung genau einer Anwendung zu einem Arbeitsschritt. Für den Anwender bedeutet diese starke Verzahnung zwischen Funktionalem und Operationalem Aspekt, dass er sich zwar nicht mehr um Auswahl und Aufruf der Anwendungen kümmern muss, jedoch auch kaum Auswahlmöglichkeiten bei der Nutzung der Anwendung hat. Wie schon beim Funktionalen Aspekt ist diese strikte Interpretation des klassischen Workflow-Konzepts im Bereich der Entwicklungsprozesse auch für den Operationalen Aspekt nicht anwendbar. Während beim klassischen System ein möglichst hoher Automatisierungsgrad des gesamten Prozesses gefragt ist, muss es das Ziel des ProcessNavigators sein, den Anwender möglichst umfassend über Handlungsalternativen zu informieren und diese auch zu erlauben. Ein hoher Automatisierungsgrad ist hier durch das erforderliche Fachwissen und die zur Lösung des Entwicklungsproblems notwendige Kreativität ohnehin nicht möglich. Vielmehr rücken die durch den Anwender gefundenen Lösungen und damit die Dokumente in den Fokus der Prozessausführung. Anwendungen (der Operationale Aspekt) besitzen hier nur eine nachrangige Funktion und stellen eher das Mittel zum Zweck dar, aus denen der Nutzer das passende Werkzeug zum Finden der Lösung oder zum Erstellen des Dokuments auswählt. Auch steht bei Produktentwicklungsprozessen an einem Arbeitsschritt im Regelfall mehr als nur ein Werkzeug zur Verfügung. Der Anwender


153

muss aus den vorhandenen jenes auswählen, welches der aktuellen Situation angemessen ist. So ist zur Entwicklung eines Software-Moduls beispielsweise vor allem eine Entwicklungsumgebung nötig; allerdings werden durch die Anwender oft auch Text-Prozessoren zum Lesen der Anforderung und zur Dokumentation der Lösungen sowie Internet-Browser zum Nachlesen von Online-Quellen eingesetzt. Wie, wann und in welcher Reihenfolge diese Anwendungen genutzt werden, alternativ oder gemeinsam, muss hier von Fall zu Fall der Nutzer entscheiden. Für Entwicklungsprozesse muss der Begriff der Anwendung bzw. des Werkzeugs also weiter gefasst werden. Anwendungen sind hier all jene Hilfsmittel, die den Nutzer bei der Umsetzung der im Arbeitspaket beschriebenen Tätigkeiten unterstützen. Der Operationale Aspekt kann damit sowohl IT-Anwendungen als auch alle anderen Hilfsmittel umfassen, die sich nicht über Programmschnittstellen in ein Prozessmanagementsystem einbetten lassen (z.B. Versuchsanordnungen). IT-Systeme können weiterhin unterschieden werden in solche, die sich über vorhandene Schnittstellen programmatisch in den Prozess einbinden lassen, und solche, die sich nicht über entsprechende Schnittstellen einbinden lassen. Insbesondere bei einer Vielzahl der in der Produktentwicklung genutzten Werkzeuge (z.B. Entwicklungsumgebung oder CAD-Werkzeuge) ist die Anbindung an ein Prozessmanagementsystem mit einem hohen Aufwand verbunden, da keine standardisierten Schnittstellen zum Start der Anwendung existieren. Die Spannbreite der zu integrierenden Anwendungen reicht also von einer einfach zu integrierenden IT-Anwendungen über schwer integrierbare Anwendungen bis hin zu nicht integrierbaren Anwendungen. Während in klassischen Systemen die Bereitstellung einer Anwendung von zentraler Bedeutung ist, kommt dem ProcessNavigator im Entwicklungsprozess also vor allem eine Informationsaufgabe zu. Das System muss den Anwender über die Funktionen und Möglichkeiten der Anwendung(en) informieren und ihn bei der Auswahl und der Benutzung unterstützen. Ein direkter Aufruf und der Start der Anwendung durch das Prozessmanagementsystem sind nicht mehr nötig. Dies ist auch dadurch gerechtfertigt, da verglichen mit dem Zeitaufwand, den Anwender üblicherweise in die Umsetzung der Arbeitsaufgaben investieren, der bei für den Start der Anwendung aus dem Prozessmanagementsystem, vernachlässigt werden. Im Vergleich zu klassischen Workflow-Management-Systemen hat sich im ProcessNavigator der Fokus von einer Anwendungsbereitstellung zu einer Informationsbereitstellung verschoben. Der Anwender muss über alle verfügbaren und sinnvoll einsetzbaren Anwendungen informiert werden. Er muss darüber hinaus auch einfachen Zugriff auf Hilfedokumente und „Best Practices“ im Bezug auf die Anwendungen erhalten. Ein direkter Aufruf der Anwendung ist, auch wenn er bei einem Teil der Werkzeuge realisierbar ist, nicht notwendig.

154


In Abbildung 9-11 ist die Umsetzung des Operationalen Aspekts dargestellt, wie sie im FORFLOW-Projekt für Entwicklungsprojekte aus dem Maschinenbau genutzt wurde [Troll et al. 2008]. Im ProcessNavigator werden im Reiter „Werkzeuge“ die zur Verwendung empfohlenen Anwendungen angezeigt. Der Anwender erhält eine Reihe an Werkzeugen zur Auswahl; diese richtet sich nach Einsatzzweck (z.B. Leichtbau). Anschließend kann der Anwender entscheiden, ob die „normale“ oder die ausführliche Hilfe für „Experten“ angezeigt werden soll. Je nach Wahl des Nutzers werden im unteren Bereich des Reiters „Werkzeuge“ anschließend verschiedene Hilfedokumente angeboten.

Abbildung 9-11: Einbindung des Organisatorischen Aspekts im ProcessNavigator

In Tabelle 9-6 ist die Umsetzung der Modellierungselemente des Operationalen Aspekts zusammengefasst. Tabelle 9-6:

Umsetzung der Elemente des Operationalen Aspekts

Prozessmodell

Projektmodell

ProcessNavigator

Werkzeug

Produktionsressource

Anzeige von Informationen und Anleitungen zu der Anwendung oder Produktionsressource


9.1.7

155

Erweiterung um neue Aspekte und Konstrukte

Die AOPM kann aufgrund ihrer Struktur um neue Konzepte erweitert werden. Dazu trägt insbesondere das in [Jablonski et al. 2009a] entwickelte Meta-Modell für die Prozessmodellierungssprache bei. In [Meiler 2005] werden beispielsweise zur Modellierung Klinischer Pfade verschiedene neue Aspekte und Modellierungselemente vorgestellt. Anhand von zwei Beispielen aus dieser Domäne (Evidenzbasierter Entscheider und Checklisten) soll verdeutlicht werden, wie diese in den ProcessNavigator aufgenommen werden können. Beide Konzepte unterstützen die Entscheidungsfindung im Prozess und sind aus diesem Grund auch für die Anwendung in Entwicklungsprozessen von Interesse. Aus der Sicht der Nutzer des ProcessNavigators können Erweiterungen grundsätzlich an zwei Stellen vorgenommen werden: der PN-Worklist und dem PN-Desktop. Die Worklist ist dabei für jene Aspekte des Prozessmodells zuständig, die die Auswahl und die Anzeige der möglichen Schritte durch den Nutzer beeinflussen. Der PN-Desktop zielt auf der anderen Seite hauptsächlich darauf ab, Nutzer mit Informationen über einen bestimmten (vorher ausgewählten) Prozessschritt zu versorgen. Bevor also ein neuer Aspekt in den ProcessNavigator integriert werden kann, muss zuerst darüber entschieden werden, in welche der beiden Bereiche des ProcessNavigators dieser aufgenommen werden soll. Dabei ist es jedoch nicht ausgeschlossen, dass ein Modellierungselement gleichzeitig auf beide Bereiche (Worklist und Desktop) des ProcessNavigators Einfluss nimmt. Checklisten bieten die Möglichkeit einfache Prozessschritte kompakt in das Prozessmodell zu integrieren. Die Elemente einer Checkliste unterscheiden sich von normalen Prozessschritten vor allem dadurch, dass sie einen sehr begrenzten Umfang besitzen und den Nutzer daran erinnern sollen, bestimmte Aktionen während des Prozessschrittes auszuführen. Im Prozessmodell werden Checklisten an Prozessschritten modelliert und bilden dort Eingangsbedingungen, die erfüllt sein sollen, bevor mit der Bearbeitung des Schritts begonnen werden kann. Entsprechend bietet es sich an, die Elemente einer Checkliste im PN-Desktop anzuzeigen und dort mit sogenannten Checkboxen zu versehen. Damit können Nutzer beim Bearbeiten der Prozessschritte und Arbeitspakete die Elemente einzeln markieren und abhaken. Der Evidenzbasierte Entscheider stellt ein Kontrollflusskonstrukt zur Modellierung komplexer Entscheidungen in medizinischen Prozessen (klinischen Pfaden) dar [Lakomek et al. 2007; Roeder et al. 2003]. Er ermöglicht es innerhalb des klinischen Pfades eine komplizierte Entscheidung, basierend auf medizinischen Fakten, kompakt darzustellen. Zusätzlich können in Evidenzbasierten Entscheidern Regeln definiert werden, die eine automatisierte Entscheidungsunterstützung durch das Prozessma-

156


nagementsystem unterstützen. Entscheidungen wirken sich, wie im Abschnitt (9.1.3 – Der Verhaltensorientierte Aspekt im ProcessNavigator) dargestellt, hauptsächlich auf die Worklist aus. Auch im Fall von Evidenzbasierten Entscheidern wird, wie bei einfachen Entscheidern, ein Eintrag in der Worklist erzeugt. Allerdings müssen im Desktop wesentlich mehr Informationen angezeigt werden. Ebenso ist eine Komponente vorzusehen, die die integrierten Regeln auswertet und dem Nutzer eine Entscheidung, basierend auf den vorhandenen Fakten, vorschlägt. Für die Aufnahme von neuen domänenspezifischen Aspekten und Konstrukten in den ProcessNavigator lassen sich abschließend keine festen Regeln vorgeben. Als Richtlinie kann angegeben werden, dass solche Elemente, die primär die Auswahl der Schritte festlegen, in der Worklist eingetragen werden, alle anderen Elemente können besser dem PN-Desktop zugerechnet werden. Eine endgültige Entscheidung kann jedoch erst nach einer eingehenden Analyse der Anforderungen des Anwendungsszenarios und der Domäne getroffen werden. In Tabelle 9-7 werden die Unterschiede zwischen dem klassischen Workflow-Konzept und der Umsetzung im ProcessNavigator kompakt zusammengefasst. Tabelle 9-7:

Vergleich zwischen klassischem Workflow-Konzept und Prozessnavigator

Aspekte

Klassisches Konzept

ProcessNavigator

Generelles Konzept

Anwender haben wenige Möglichkeiten vom vorgegebenen Prozess abzuweichen; Prozessausführung wird durch das Workflow-ManagementSystem bestimmt.

Anwender haben viele Möglichkeiten vom vorgegebenen Prozess abzuweichen; sie bestimmen maßgeblich über die Prozessausführung.

Automatisierte Prozessausführung mit starker Integration von Anwendungen in den Prozess.

Bereitstellung von Informationen über das Projekt und Vorgehen für den Anwender.

Funktionaler Aspekt

Beschreibt die im Prozess auszuführenden Schritte.

Beschreibt die im Projekt auszuführenden Aufgaben.


Bestimmt maßgeblich den Ablauf der Prozessausführung.

Bestimmt die Reihenfolge der Prozessschritte in der PN-Worklist.

9.2 Phase 4.2: Projektmonitoring und Umsetzung der QM-Vorgaben

Aspekte




157

Klassisches Konzept

ProcessNavigator

Anwender haben keine Möglichkeit vom vordefinierten Kontrollfluss abzuweichen.

Anwender haben jederzeit die Möglichkeit von der vordefinierten Reihenfolge abzuweichen.

Daten werden direkt in den Anwendungen zur Verfügung gestellt.

Anwender werden darüber informiert, welche Dokumente zu erstellen sind.

Alle Eingangsdokumente vorhanden sein müssen bevor ein Arbeitsschritt ausgeführt werden kann.

Prozessschritte können auch gestartet werden, wenn noch nicht alle Dokumente vorliegen.

Legt fest, welche Prozessschritte ein Anwender auszuführen hat.

Legt fest, welche Prozessschritte ein Anwender auszuführen hat.

Anwender können nur eigene Prozessschritte starten.

Anwender können auch Prozessschritte starten bzw. einsehen, die ihnen nicht zugeordnet sind.

Anwendungen werden direkt durch das WorkflowManagement-System aufgerufen und sind stark in die Gesamtanwendung integriert.

Anwender werden über verfügbare Werkzeuge informiert. Sie können selbst festlegen, welche sie nutzen wollen.

Es besteht eine strikte Zuordnung zwischen Anwendung und Funktionalem Aspekt.

9.2

Phase 4.2: Projektmonitoring und Umsetzung der QM-Vorgaben

Während der Bearbeitung des Projektes ist es Aufgabe des Projektleiters den Fortschritt im Projekt regelmäßig zu kontrollieren und bei Abweichungen vom Plan rechtzeitig steuernd einzugreifen. Der ProcessNavigator kann dabei wichtige Unterstützung leisten, da hier umfangreiche Informationen über die Prozessausführung

158


abgelegt sind. Dabei erfüllt das Prozessmanagementsystem gleichzeitig auch eine wichtige Forderung des aQM2 auf RG 2. Im Vorgehensmodell zur Umsetzung von QM-Anforderungen (Kapitel 5) können zwei Regelkreise identifiziert werden [Wagner et Käfer 2008]. Ein „kleiner“ Regelkreis, der sich auf Einzelprojektebene auswirkt und ein „großer“ Regelkreis, der die Informationen aller ausgeführten Projekte aufnimmt und zur Verbesserung der Prozesstypen beiträgt (Abbildung 9-12). Der kleine Regelkreis beschreibt dabei das projektbegleitende Monitoring, welches parallel zur Projektbearbeitung durchgeführt wird und zum Ziel hat, Abweichungen vom geplanten Soll frühzeitig zu erkennen und zu korrigieren. Dabei erfolgt keine Anpassung der Prozesstypen, sondern Anpassungen erfolgen nur auf der Projektebene. Der große Regelkreis hingegen beschreibt die Nutzung der Ausführungsinformationen aller Projekte zur Verbesserung der Prozesstypen. Im Vergleich zum kleinen Regelkreis findet hier ein Sprung über Ebenengrenzen im Meta-Modell statt. Phase 1:

Großer Regelkreis – Controlling

Aufnahme und Integration

Prozesslandschaft

Phase 5: Controlling & Assessmentunterstützung


Vorgehensmodell zur QMUmsetzung



Phase 2.1: Definition des Prozessmodells Phase 2.2: Prozessvalidierung

Phase 3: Projektdefinition Phase 3.1: Definition des Projekttyps

Phase 3.2: Projektvalidierung

Kleiner Regelkreis – Monitoring Abbildung 9-12: Kleiner Regelkreis zur Steuerung des Projekts

Im nächsten Abschnitt soll nur das Operative Controlling (Monitoring) betrachtet werden, da dieses während der Projektdurchführung stattfindet. Der Bereich des


159

Strategischen Controllings wird im nächsten Kapitel (10 - Nachbereitung der Projektdurchführung) betrachtet. 9.2.1

Unterstützung des Projektmonitorings durch den ProcessNavigator

Ziel des Monitoring im „kleinen“ Regelkreis ist es die Projektausführung selbst zu beeinflussen, um vorgegebene Projektziele erreichen zu können. Im Rahmen normaler Projektmanagementaktivitäten steht dem Projektleiter hiermit ein Werkzeug zur Verfügung, Abweichungen vom geplanten Soll frühzeitig zu erkennen und zu beheben. Während der Projektbearbeitung werden vom ProcessNavigator fortlaufend die aktuellen Projektdaten erfasst und in einer Datenbasis gespeichert. Dieses kann genutzt werden, um den Projektstatus darzustellen und aufzubereiten. In [Kuster et al. 2008] werden insbesondere die Termin- und Kostenkontrolle sowie die Ressourcenkontrolle als zu überprüfende Größen angegeben. Mögliche Kenngrößen sind unter anderem: x Geplante und effektive Dauer x Geplante und effektive Kosten x Erfüllungsgrad in % Die beschriebenen Kenngrößen können mit den in der Datenbasis vorhandenen Informationen einfach bestimmt werden. So sind im Projekttyp Informationen über die geplante Dauer des gesamten Projekts sowie Informationen über den frühesten und spätesten Termin für jedes Arbeitspaket vorhanden (Abschnitt 8.1). Diese können mit der effektiven (tatsächlichen) Dauer und dem Abschlusstermin des jeweiligen Arbeitspaketes verglichen werden. Im Fall einer Terminüberschreitung kann dies dem Projektleiter in einer entsprechenden Übersichtsseite direkt angezeigt werden. Analog zur Überwachung der Termine können auch die tatsächlichen Kosten mit den geplanten Kosten abgeglichen werden, um so Abweichungen frühzeitig erkennen zu können. Im Bezug auf die Kenngröße „Erfüllungsgrad in %“ sind insbesondere die beiden Parameter abgeschlossene Arbeitspakete und erstellte Artefakte von Bedeutung. In Abbildung 9-13 ist der Erfüllungsgrad im Bezug auf die abgeschlossenen Arbeitspakete abgebildet. Der Erfüllungsgrad wird dabei als Fortschrittsbalken direkt im Auswahlfenster des zu bearbeitenden Projekts angezeigt. Somit haben sowohl Projektleiter als auch Mitarbeiter Zugriff auf den aktuellen Fortschritt im Projekt.

160


Abbildung 9-13: Anzeige des Projektfortschritts in der Projektübersicht

Zusätzlich zu den oben beschriebenen Kennzahlen sind im Bezug auf die im ProcessNavigator vorhandene flexible Prozessausführung weitere Kennzahlen von Interesse. Darunter fallen beispielsweise: x Anzahl der Arbeitspakete, die mit fehlenden Eingangsdokumenten begonnen wurden x Anzahl der Arbeitspakete, die abgeschlossen wurden obwohl noch Dokumente zu erstellen waren x Anzahl der Dokumente, zu denen kein formales Datum im Prozesstyp existiert x Anzahl der formalen Daten, zu denen mehr als ein Dokument existiert Diese Kennzahlen deuten allgemein auf Abweichungen hin, die bei der Ausführung im Bezug auf die Planung aufgetreten sind. Sie deuten nicht zwangsweise auf einen Fehler im Prozessverlauf hin, sondern sollen vielmehr dem Projektleiter Hinweise auf mögliche Probleme geben. So kann zum Beispiel die Tatsache, dass ein Prozessschritt abgeschlossen wurde, obwohl noch Dokumente fehlen, zwei Schlussfolgerungen zulassen. Erstens kann hier tatsächlich ein Fehler in der Bearbeitung durch den Anwender vorliegen und das Dokument muss noch erstellt werden. Zweitens kann es aber auch sein, dass das Dokument im aktuellen Entwicklungsprojekt aufgrund einer aktuellen Entwicklung überflüssig wurde und nicht mehr erstellt werden muss. Die Entscheidung darüber, welche der beiden Alternativen die zutreffende ist und ob das Dokument noch zu erstellen ist, muss in jedem Fall der Projektleiter treffen.


161

Abbildung 9-14: Anzeige weiterer Projektkennzahlen

In Abbildung 9-14 sind verschiedene aus dem ProcessNavigator erzeugte Kennzahlen dargestellt. Die Details (gestartete Arbeitsschritte ohne Eingangsdatum, unvollständig abgeschlossene Aufgaben, Prozentzahl der abgeschlossenen Aufgaben) sind hier weniger von Interesse als der Ansatz, Kennzahlen automatisch erzeugen zu können. Sowohl im Projekttyp als auch im Ausführungsprotokoll des ProcessNavigator liegen die hierfür notwendigen Basisinformationen zur Verfügung. Diese können in nahezu beliebiger Weise miteinander kombiniert, verdichtet und ausgewertet werden. Die in Abbildung 9-14 vorgestellten Darstellungen als Kuchen- oder Balkendiagramm sollen hier nur einen kleinen Ausschnitt der Möglichkeiten aufzeigen, die sich aus der vorhandenen Datenbasis ergeben. Außerdem können die im ProcessNavigator enthaltenen Ausführungsinformationen auch als Basis für ein Projekt-Reporting [Kuster et al. 2008] oder als Bestandteil einer Balanced Score Card [Kaplan et Norton 1996] genutzt werden. 9.2.2

Umsetzung der QM-Vorgaben im ProcessNavigator

Mit dem ProcessNavigator steht ein System zur Verfügung, welches im aQM2 der Ausführungsebene (Abbildung 3-3) zugeordnet werden kann. Bezogen auf das Prozess-Meta-Modell (Abschnitt 3.1) kann der ProcessNavigator der Meta-Ebene M0 (Prozessinstanzen) zugeordnet werden. Im Hinblick auf die Implementierung von QMSystemen bedeutet dies, dass neben der Planung, die auch schon in bestehenden Systemen vorhanden ist, nun auch ein IT-System zur Unterstützung der Projektum-

162


setzung zur Verfügung steht. Somit können nun alle Bereiche der im Kapitel 3 aufgestellten Anforderungen durch IT-Systeme abgedeckt werden. Auf Level 1 der in Kapitel 3 betrachteten QM-Systeme geht es darum, die im QMStandard beschriebenen Prozesse umzusetzen und die beschriebenen Arbeitsergebnisse zu erzeugen. Die Planung der entsprechenden Schritte und Arbeitsergebnisse ist Teil der Prozess- und Projektplanung (Abschnitte 7.4 und 8.3). Im ProcessNavigator wird dann dieser geplante Prozess in einer Laufzeitumgebung ausgeführt. Dabei werden die Mitarbeiter durch die im Projekt zu bearbeitenden Arbeitspakete geführt. Der ProcessNavigator informiert die Projektmitarbeiter über Arbeitspakete und zu erstellende Dokumente und stellt sicher, dass keine von diesen ausgelassen werden. Stellt sich im Verlauf des Projekts heraus, dass ein Arbeitspaket nicht umgesetzt oder ein Dokument nicht erstellt werden muss, so ist dies durch den jeweiligen Mitarbeiter zu begründen und im System zu hinterlegen. Tabelle 9-8:

Umsetzung der QM-Anforderungen im ProcessNavigator auf RG1

RG 1 Ziel 1.1:


Ziel 1.2:


Sicherstellen der Umsetzung der geforderten Prozesse und Erstellen der notwendigen Arbeitsergebnisse

Während der gesamten Prozessausführung wird im ProcessNavigator ein Protokoll mitgeführt, zu welchem Zeitpunkt eine Aktion durchgeführt wurde. So werden die Zeitpunkte der Beendigung eines Arbeitspakets oder der Erstellung eines Dokuments vom System festgehalten. Diese Daten können mit den im Projekttyp geplanten SollWerten verglichen werden und so dem Projektleiter frühzeitig Abweichungen vom Soll anzeigen, so dass dieser darauf reagieren kann. Zur Steuerung des Projekts kann anschließend auf bewährte Projektmanagementmethoden [Kuster et al. 2008] zurückgegriffen werden. So können etwa dem Projekt mehr Mitarbeiter zugeteilt werden, um die geplanten Ergebnisse noch rechtzeitig zu erreichen. Andererseits können in Absprache mit den Projektsponsoren auch die Zielvereinbarungen angepasst werden. Wie und in welcher Form auf die aufgetretenen Abweichungen reagiert wird, liegt beim Projektleiter. Abgesehen von einer Bereitstellung der im Projekt erstellten Dokumente kann der ProcessNavigator hier nur wenig Unterstützung leisten. Allerdings können die Änderungen an der Vorgehensweise oder den vorhandenen Ressourcen über den Projektplan wieder in den ProcessNavigator


163

zurückgespielt werden. Dieser liefert dann einen Beitrag bei der Umsetzung des geänderten Plans. Tabelle 9-9:

Umsetzung der QM-Anforderungen im ProcessNavigator auf RG2

RG 2 Ziel 2.6:

Überwachung und Steuerung des Projekts

Ziel 2.7:

Überwachung und Korrektur der Arbeitsprodukte

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

Wie schon bei der Überwachung und Steuerung des Projekts können die im ProcessNavigator vorhanden Protokoll-Dateien genutzt werden, um weitergehende Messdaten zu erfassen und damit eine Ausgangsbasis für Verbesserungen am Prozesstyp zu liefern. So können die an Arbeitspaketen abgegebenen Kommentare oder die tatsächlich ausgeführte Reihenfolge der Arbeitspakete im Projekt Aufschluss darüber geben, ob ein Prozesstyp geändert werden muss oder nicht. Hier kommt ein weiterer wichtiger Vorteil der flexiblen Prozessausführung gegenüber der klassischen, starren Workflow-Ausführung zum Tragen. Während ein Nutzer in klassischen Systemen gezwungen war, den Vorgaben des Systems zu folgen, kann er im ProcessNavigator den Anforderungen des Projekts folgen. Passt ein Prozesstyp nicht zum Projekt, kann der Mitarbeiter nun die Abweichungen einfach durchführen und auch dokumentieren. Treten ähnliche Abweichungen in mehreren verschiedenen Projekten auf, so kann dies ein Hinweis darauf sein, dass der Prozesstyp an dieser Stelle überarbeitet werden muss. Tabelle 9-10: Umsetzung der QM-Anforderungen im ProcessNavigator auf RG3

RG 3 Ziel 3.6:

Erfassung der Daten und Ermitteln Erhebung von Messdaten im von Verbesserungspotenzialen ProcessNavigator

Insgesamt steht also mit dem ProcessNavigator ein System zur Verfügung, das im Anschluss an eine Projektplanung die Durchführung und Steuerung von Projekten unterstützt. Dabei werden jedoch auch Elemente und Anforderungen des Projektmanagements umgesetzt, wie ein flexibles Reagieren auf Änderungen und ein Projektmonitoring.

164


Mit dem ProcessNavigator wird die Ausführung des Projekts direkt unterstützt. Die Mitarbeiter werden sowohl über die anstehenden Aufgaben informiert als auch während der Umsetzung der einzelnen Aufgaben aktiv mit Wissen versorgt. Der ProcessNavigator leitet die Mitarbeiter durch alle Schritte des Projekts, von der Anforderungsanalyse bis zum Abschluss des Projekts (z.B. der Auslieferung des Produkts). Während der Projektausführung dokumentiert der ProcessNavigator alle Arbeitsschritte und stellt so sicher, dass diese Informationen in einem QMAssessment zur Verfügung stehen. Durch die Projektdokumentation steht nach Abschluss des Projekts auch eine umfangreiche Datenbasis zu Verfügung, die zur Verbesserung des Prozesstypen in der nächsten Phase des Lebenszyklus genutzt werden kann.

10

Nachbereitung der Projektdurchführung

Während der Bearbeitung des Projektes wird im ProcessNavigator eine Vielzahl an Informationen im Ausführungsprotokoll mitgeschrieben. Diese können nach Abschluss der Projektbearbeitung genutzt werden, um das abgeschlossene Projekt und seine Durchführung zu bewerten. Das Ausführungsprotokoll kann außerdem genutzt werden um Verbesserungspotenziale für den Prozesstyp zu identifizieren und es liefert wertvolle Informationen für die Bewertung des Projektreifegrads im Rahmen eines Assessments. Die Nutzung des Ausführungsprotokolls zur Steuerung des Projekts wurde bereits im Abschnitt 9.2 (Phase 4.2: Projektmonitoring und Umsetzung der QM-Vorgaben) beschrieben. Dieselben Informationen können auch nach Abschluss des Projekts genutzt werden, um im Rahmen einer Abschlussbesprechung zusammen mit Auftraggebern und beteiligten Mitarbeitern die Bearbeitung des Projekts zu bewerten. Hauptziel einer Analyse des Ausführungsprotokolls ist es jedoch, Informationen zur Verbesserung des Prozesstyps eines durchgeführten Projekts zu gewinnen. Auf diese Weise können die im Projekt gemachten Erfahrungen langfristig zur Verbesserung der Unternehmensprozesse und zu ihrer stetigen Optimierung beitragen. Im Rahmen einer Zertifizierung nach einem der beiden QM-Standards ISO/IEC 15504 oder CMMI kommt dem Ausführungsprotokoll eine weitere wichtige Aufgabe zu. Die hier gesammelten Prozessaufzeichnungen und besonders die erstellten und an die Anforderungen des QM-Standards gekoppelten Artefakte (Dokumente) dienen als Belege für die ordnungsgemäße Prozessausführung im Assessment. 10.1

Phase 5: Interne Verbesserungsmaßnahmen und Umsetzung von QM-Vorgaben

Die interne Prozessverbesserung hat zum Ziel, basierend auf den im Projekt erreichten Erfahrungswerten, die definierten Prozesstypen zu verbessern. Um eine zielgerichtete Verbesserung der Prozesse vornehmen zu können, ist es nötig über Ausführungsinformationen des jeweiligen Prozesses zu verfügen. Mit den im ProcessNavigator gesammelten Ausführungsinformationen stehen solche Daten zur Verfügung. In Abbildung 10-1 ist der entsprechende Informationsfluss (großer Regelkreis) dargestellt. Verglichen mit dem kleinen Regelkreis (Abschnitt 9.2), der zur Prozesssteuerung genutzt wird, adressiert dieser die Optimierung der Prozesstypen. Grundlage dafür sind die im Ausführungsprotokoll vorhandenen Informationen über das Projekt, die beschreiben wann und in welcher Reihenfolge Aktionen im ProcessNavigator ausgeführt wurden. Im Gegensatz zum kleinen Regelkreis findet hier auch ein

166

10 Nachbereitung der Projektdurchführung

Sprung zwischen den Meta-Ebenen (Kapitel 3) der Modellhierarchie statt. Die auf Meta-Ebene M0 gesammelten Informationen über das Projekt werden genutzt, um den Prozesstyp auf Meta-Ebene M1 zu verbessern. Phase 1:

Großer Regelkreis – Controlling

Aufnahme und Integration

Prozesslandschaft

Phase 5: Controlling & Assessmentunterstützung


Vorgehensmodell zur QMUmsetzung



Phase 2.1: Definition des Prozessmodells Phase 2.2: Prozessvalidierung

Phase 3: Projektdefinition Phase 3.1: Definition des Projekttyps Phase 3.2: Projektvalidierung

Kleiner Regelkreis – Monitoring Abbildung 10-1: Großer Regelkreis zur Prozessverbesserung

Zur Prozessverbesserung können prinzipiell alle im Ausführungsprotokoll vorhandenen Informationen herangezogen werden. Ein systematisches Vorgehen zur Auswertung des Protokolls mit dem Ziel den Prozesstyp zu optimieren wird in Kapitel 11 mit dem Six Sigma Ansatz vorgestellt. An dieser Stelle soll vorgestellt werden, wie Mitarbeiter die Daten nutzen können, um einfache Verbesserungen zu erkennen. Grundsätzlich gilt hier, dass Elemente (Prozessschritte, Daten, Werkzeuge etc.) die nicht oder nur wenig genutzt werden potenziell aus dem Prozesstyp entfallen können, Elemente die häufig genutzt werden, einen größeren Stellenwert (z.B. Hinweis als empfohlener Ausführungsweg) bekommen. Da die Ansatzpunkte für eine Prozessverbesserung zu vielfältig sind, um sie an dieser Stelle umfassend darzustellen, sollen stattdessen die vorhandenen Möglichkeiten aufgezeigt werden. Dazu wird zu allen im Prozess-Meta-Modell vorhanden Aspekten ein Szenario und strategische Ziele vorgestellt, mit dem sowohl die Machbarkeit als auch die Mächtigkeit des Ansatzes dargestellt werden sollen.

10.1 Phase 5: Interne Verbesserungsmaßnahmen und Umsetzung von QM-Vorgaben

167

x Funktionaler Aspekt (Ziel: Verbesserung der Prozessabläufe) Im Funktionalen Aspekt sind die im Projekt umzusetzenden Arbeitspakete festgelegt. Zur Verbesserung des Prozesses können beispielsweise die Kommentare der Mitarbeiter an den Arbeitspaketen genutzt werden. Mitarbeiter können an den einzelnen Arbeitspaketen Kommentare abgeben und so Hinweise geben, wie etwa die Verfahrensanweisungen eines Arbeitspaketes ergänzt werden können. Außerdem können in den Kommentaren neue zusätzliche Prozessschritte vorgeschlagen werden, die aus der im aktuellen Projekt gewonnen Erfahrung sinnvoll erscheinen. Solche Vorschlagssysteme werden in Unternehmen schon eingesetzt [Reith 2000]; durch die Unterstützung des Ausführungsprotokolls im ProcessNavigator können nun die Verbesserungsvorschläge jedoch gezielt zu den einzelnen Arbeitsschritten des Prozesses abgegeben werden. x Verhaltensbezogener Aspekt (Ziel: Verbesserung der Prozessabläufe) Der Verhaltensorientierte Aspekt beschreibt sowohl Abhängigkeiten zwischen Arbeitspaketen als auch Entscheidungen, die im Projektverlauf durch die Mitarbeiter getroffen werden müssen. Wie in Abschnitt 9.1.3 beschrieben, müssen Mitarbeiter die im Projekt getroffenen Entscheidungen dokumentieren. Auf diese Weise sind im Ausführungsprotokoll Informationen darüber vorhanden, welche Pfade im Prozesstyp genutzt werden und welche nicht. Pfade, die nicht in Projekten ausgeführt werden, können so unter Umständen bei einer Überarbeitung des Modells entfernt werden. Da die Mitarbeiter vom ProcessNavigator nicht gezwungen werden, bestimmte Arbeitsschritte auszuführen, kann auch hier eine interessante Informationsquelle für Prozessverbesserungen liegen. Wird beispielsweise ein Schritt eines Prozesstyps in mehreren abgeleiteten Projekten nicht ausgeführt sondern übersprungen, kann dies ein Hinweis sein, dass das entsprechende Arbeitspaket nicht notwendig ist. Der gleiche Sachverhalt kann jedoch auch darauf hindeuten, dass im Unternehmen weitere Schulungen über den Prozess notwendig sind. Eine weitere Informationsquelle im Verhaltensorientierten Aspekt ergibt sich durch flexible Prozessausführung im ProcessNavigator. Da Mitarbeiter die Arbeitspakete prinzipiell in beliebiger Reihenfolge ausführen können, können sich hieraus Rückschlüsse auf eine Optimierungsmöglichkeit im Kontrollfluss ergeben. Beispiele sind etwa das Vertauschen zweier Arbeitsschritte oder die Einführung zusätzlicher Iterationen.

168


x Datenorientierter Aspekt (Ziel: Verbesserung der Datenqualität) Dieser Aspekt beschreibt die im Prozess erzeugten Daten sowie den Datenfluss zwischen den einzelnen Arbeitspaketen. Analog zu Prozessschritten werden auch alle Aktionen mit Datenelementen im ProcessNavigator mitgeschrieben. Entsprechend lassen sich aus dem Ausführungsprotokoll Rückschlüsse auf die im Prozesstyp modellierten Datenelemente ziehen. Liegen Daten an einem Meilenstein häufig nicht in der gewünschten Qualität vor und werden diese durch den verantwortlichen Projektleiter zurückgewiesen, so müssen unter Umständen zusätzliche Reviews oder eine weitere Iterationen im Prozess eingeplant werden. x Organisatorischer Aspekt (Ziel: Bessere Ressourcennutzung im Unternehmen) Während der Prozessausführung wird im ProcessNavigator mitgeschrieben, welche Arbeitsschritte von einem Nutzer ausgeführt werden. Diese Informationen werden in [Jablonski et Talib 2009] genutzt, um die Zuordnung von Arbeitsschritten zu Mitarbeitern zu optimieren. Durch die Projektsituation ist es in der Produktentwicklung nicht möglich, die Zuordnung automatisiert durch ein Prozessmanagementsystem vornehmen zu lassen. Allerdings können die vorhandenen Informationen im Vorfeld des Projekts genutzt werden, um Mitarbeiter entsprechen ihrer Fähigkeiten auszuwählen. Stellt sich beispielsweise heraus, dass ein Mitarbeiter bei Reviews überdurchschnittlich viele Fehler in Dokumenten findet, kann dieser Mitarbeiter bevorzugt für diese Aufgabe eingesetzt werden. x Operationaler Aspekt (Ziel: Bessere Ressourcennutzung im Unternehmen) Der Operationale Aspekt legt die genutzten Anwendungen und Produktionsressourcen fest. Wird im Prozesstyp mehr als eine Anwendung an einem Arbeitspaket angeboten, so hat der Mitarbeiter hier die Auswahl, das aus seiner Sicht geeignete Werkzeug auszuwählen [Troll et al. 2008]. Stellt sich heraus, dass in einem Schritt immer die gleiche Anwendung ausgewählt wird, können die anderen Anwendungen eventuell aus dem Modell gestrichen und der Entscheidungsprozess für den Mitarbeiter vereinfacht werden. Umgekehrt ist es jedoch auch möglich, dass aufgrund von Kommentaren an Arbeitsschritten neue Anwendungen in den Prozesstyp aufgenommen werden. Die oben vorgestellten Beispiele sollen nur einen kleinen Ausschnitt aus den vielfältigen Möglichkeiten aufzeigen, die das Ausführungsprotokoll zur Prozessoptimierung bietet. Beim Einsatz in Unternehmen muss sich die Optimierung immer auch an der Unternehmensstrategie ausrichten. Entsprechend lassen sich dort auch weitere Ansatzpunkte für die Prozessoptimierung im Protokoll des ProcessNavigators finden.

10.2 QM-Assessment

169

Mit dem hier beschriebenen großen Regelkreis und der Möglichkeit aus dem Ausführungsprotokoll Rückschlüsse auf eine Verbesserung der Prozesse ziehen zu können, wird das Ziel 3.6 des aQM2 unterstützt. Auf den Reifegradebenen RG4 und RG5 werden die während der Prozessausführung gesammelten Daten genutzt um systematisch Verbesserungspotenziale in den Prozessen zu identifizieren und umzusetzen. Tabelle 10-1: Umsetzung der QM-Anforderungen durch Verbesserungsmaßnahmen auf RG3

RG 3 Ziel 3.6:

10.2

Erfassung der Daten und Ermitteln Erhebung von Messdaten im von Verbesserungspotenzialen ProcessNavigator

QM-Assessment

Ein Assessment (oder auch Appraisal) überprüft den Reifegrad der Prozessumsetzung im Unternehmen durch einen Gutachter. Für weitere Informationen sei an dieser Stelle auf die entsprechenden Normen verwiesen ([ISO/IEC 15504-5:2006] oder [SCAMPI Upgrade Team 2006]). Gutachter in einem Assessment können sowohl externe Personen oder auch eigene Mitarbeiter sein. Im Fall externer Gutachter ist es häufig ein wichtiges Ziel des Assessments, eine bestimmte Reifestufe bescheinigt zu bekommen, wo hingegen bei eignen Mitarbeitern in einem Selbstassessment eher die Prozessoptimierung im Fokus steht. In diesem Abschnitt wird nur das externe Assessment betrachtet, da wichtige Teile eines solchen Selbstassessments wie etwa die Überprüfung, ob alle Aspekte des QM-Standards im Prozesstyp umgesetzt werden, schon bei der Validierung des Prozesstyps abgefragt werden. Zusätzlich lassen sich natürlich auch die Methoden, die zur Unterstützung für externe Assessments vorgestellt werden, in einem internen Assessment verwenden. In [Hörmann et al. 2006] und [Kneuper 2006] wird das typische Vorgehen eines Assessments beschrieben. Der Ablauf eines Assessments kann in drei Abschnitte unterteilt werden: Vorbereitung, Durchführung und Nachbereitung. In der Vorbereitungsphase versuchen die Assessoren, die Ziele des Assessments festzulegen sowie einen Überblick über das Unternehmen zu bekommen. Dazu gehört ein sogenannter „Readiness Review“, in dem noch vor dem eigentlichen Assessment geklärt wird, ob das Unternehmen für das Assessment bereit ist. In der Durchführungsphase werden Informationen über das Unternehmen und die Projektdurchführung gesammelt und bewertet. Basis für die Bewertung können sowohl Belege (Dokumente) sein als auch Interviews, die mit den Mitarbeiter geführt wurden. In der Nachbereitung wird dem

170


begutachteten Unternehmen das Ergebnis mitgeteilt und auch Hinweise für mögliche Verbesserungsmaßnahmen gegeben. Von den drei Phasen bieten sich insbesondere die Vorbereitungs- und Durchführungsphase für Unterstützung durch den ProcessNavigator an. Für die Vorbereitung des Assessments wird in der CMMI eine strukturierte Beschreibung der Umsetzung der Anforderungen im Unternehmen, die PIID (Practice Implementation Indicator Database) gefordert. Diese Beschreibung kann die spätere Durchführung des Assessments beschleunigen, da die Gutachter nicht mehr nach den einzelnen Belegen suchen müssen, sondern diese in einer strukturierten Übersicht zusammengestellt sind und die dort vorhandenen Informationen anschließend nur noch bestätigt werden müssen („Verifikation statt Entdeckung“). In der PIID werden die folgenden Informationen gesammelt [Kneuper 2006]: x Direkte Artefakte: Im Prozess (entspricht einer CMMI-Praktik) erstellte Dokumente und Ergebnisse. x Indirekte Artefakte: Artefakte oder Dokumente, die zwar im Rahmen des Prozesses erstellt wurden, aber nicht direkt Ergebnisse sind. Beispiele sind unter anderem Freigabe-, Test- oder Prüfberichte. x Bestätigungen: Diese Belege bestätigen, dass ein Prozess auch wirklich im Unternehmen umgesetzt wird. Bestätigungen werden hauptsächlich in den Interviews des Assessments gesammelt. Der Beleg Bestätigung kann erst im Assessment selbst gesammelt werden und das Unternehmen hat nur durch eine gute Schulung seiner Mitarbeiter direkten Einfluss. Gerade hier leistet der ProcessNavigator jedoch einen wichtigen Beitrag, da er im Informationsteil der Arbeitspakte auch Verweise auf die QM-Normen geben kann und somit die Mitarbeiter während der Prozessausführung in der Umsetzung der QMNormen schult. Die beiden anderen Belege (Direkte Artefakte und Indirekte Artefakte) können jedoch gut aus der im ProcessNavigator vorhandenen Prozessplanung und dem Ausführungsprotokoll erzeugt werden [Jablonski et Faerber 2007]. In Abbildung 10-2 ist diese Zuordnung für alle im Unternehmen umgesetzten Prozesse zu den in den QM-Standards definierten Prozessen (Base Practices) dargestellt. Zur Anforderung aus der QM-Norm (Base Practice) werden der oder die im Unternehmen zugeordneten Prozesse angezeigt. Zu den Prozessen werden auch die dort zu erstellenden Dokumente angezeigt; über eine entsprechende Verknüpfung kann auch auf die Projektdokumente zugegriffen werden. Somit können einem Prozess aus der QM-Norm die Direkten Artefakte einfach zugeordnet werden. Analog können auch Indirekte Artefakte einem Prozess zugeordnet werden; zusätzlich können für diese

10.2 QM-Assessment

171

Zuordnung auch die manuellen Parameter zur Einbindung von Dokumenten im ProcessNavigator genutzt werden (Abschnitt 9.1.4). Neben dieser im Beispiel dargestellten Zuordnung können aus Prozess- und Projekttyp sowie den vorhandene Information im Ausführungsprotokoll weitere Auswertungen zur Unterstützung von Assessments abgeleitet werden. Während der Interviews werden Mitarbeiter außerdem durch den ProcessNavigator unterstützt, da dort durch die Ausführungsprotokolle einfach der Projektablauf rekonstruiert werden kann. Neben der reinen Umsetzung der Prozesse aus der QM-Norm unterstützt auch die Ausführungsumgebung selbst die Erfüllung der QM-Normen maßgeblich. Durch eine konsequente Prozess- und Projektunterstützung sowie die Ausführungsumgebung werden die Kernaspekte der QM-Norm direkt umgesetzt. Dies wurde in den vorangegangenen Kapiteln jeweils im den Abschnitten „Umsetzung der QM-Vorgaben“ demonstriert.

Zuordnung zwischen Anforderung und Umsetzung

Abbildung 10-2: Zuordnung der Vorgaben aus der QM-Norm zu Unternehmensprozessen

Die Phase 5 mit der Nachbereitung des Projekts bzw. das Assessment schließen das Vorgehensmodell ab. Das im ProcessNavigator vorhandene Ausführungsprotokoll wird genutzt, um Verbesserungspotenziale an Prozesstypen aufzudecken; außerdem stehen in Assessments die zur Bewertung der Projektdurchführung notwendigen Daten zur Verfügung. Der optimierte Prozesstyp kann als Ausgangsbasis für nachfol-

172


gende Projekte genutzt werden; diese beginnen mit dem erneuten Tailoring eines Projekttyps aus dem Prozesstyp in Phase 3.1.

11

Systematische Messung und Prozessverbesserung

In den Kapiteln 5 bis 10 wurde gezeigt, wie ein Projekt von der Erstellung des Prozesstyps, über das Tailoring bis zur Ausführung und Nachbereitung durch ein ITSystem unterstützt werden kann. Dabei werden jedoch nur die Reifegradebenen RG1 bis RG3 aus dem QM-Modell aQM2 abgedeckt. Die verbliebenen beiden Reifegradebenen RG4 (Überwachter Prozess) und RG5 (Verbessernder Prozess) werden durch das beschriebene System nicht systematisch umgesetzt. Ziel dieser beiden Reifegradebenen ist es, den im Projekt ausgeführten Prozess quantitativ zu messen und Abweichungen mit Hilfe statistischer Verfahren frühzeitig zu erkennen. Zusätzlich zur Ausführung des Prozesses innerhalb kontrollierter und vordefinierter Schranken sollen durch die statistischen Verfahren auch systematisch Prozessverbesserungsmöglichkeiten identifiziert werden. Im Hinblick auf das Vorgehensmodell zur QM-Umsetzung (Abbildung 5-3) wird auf RG4 (Überwachter Prozess) der „kleine Regelkreis“ und mit RG5 (Verbessernder Prozess) der „große Regelkreis“ adressiert. Der Unterschied zu den Steuerungs- und Verbesserungsmaßnahmen auf den Reifegradebenen RG2 und RG3 liegt hier vor allem in der systematischen Vorgehensweise. Während das dort vorgestellten Verfahren eine eher leichtgewichtige Herangehensweise darstellt, ist mit dem Six Sigma Ansatz ein schwergewichtiges Verfahren vorhanden, dass sich vor allem auf sein mathematisch-statistischen Konzept stützt. In [Siviy et al. 2005] wird die Verbesserungsmethode Six Sigma [Kroslid et al. 2003; Töpfer 2004] als Werkzeug („tactical engine”) zur Umsetzung der CMMI Anforderungen der Level 4 und 5 vorgeschlagen. In [Card 2000] wird beschrieben, wie der Six Sigma Ansatz genutzt werden kann, um die Reifegradebenen RG4 und RG5 zu erreichen, und in [Murugappan et Keeni 2003] wird ein Erfahrungsbericht über den Unternehmenseinsatz vorgestellt. Aus diesem Grund wird in dieser Arbeit die Umsetzung von RG4 und RG5 des aQM2 durch einen Six Sigma Ansatz realisiert. Es wird nicht ausgeschlossen, dass die Ziele auch durch einen Ad-hoc-Ansatz zu erreichen sind; Six Sigma hat demgegenüber jedoch den Vorteil des konstruktiven Verfahrens und ist deshalb zu bevorzugen. 11.1

Exkurs: Die Methode Six Sigma zur Verbesserung der Prozessqualität

Bevor auf die Umsetzung der Reifegradebenen RG4 und RG5 mit Hilfe des ProcessNavigators eingegangen wird, soll erst das Ziel und der Ansatz von Six Sigma als Manage-

174

11 Systematische Messung und Prozessverbesserung

mentkonzept vorgestellt werden. Six Sigma wird detailliert in [Töpfer 2004; Toutenburg et Knöfel 2009] vorgestellt. Der Name des Ansatzes verweist auf das statistische Basiskonzept, welches zur Messung der erreichten Leistungsfähigkeit des Prozesses genutzt wird. Mit dem Buchstaben Sigma („σ“) wird in der Statistik die Standardabweichung einer Zufallsvariablen beschrieben. Es ist also ein Maß, in wie weit eine Variable (Messgröße) variiert. Im Bereich von Produktionsprozessen, aber auch aller anderen Prozesse, ist eine hohe Varianz ein Zeichen dafür, dass ein Prozess ein schlechtes Ergebnis und somit eine niedrige Qualität erzielt. Six Sigma wurde zuerst bei Unternehmen eingesetzt, die eine eigene Fertigung besitzen. Ziel war es, die dortigen Produktionsprozesse zu verbessern. Six Sigma verfolgt das Konzept einer „virtuellen Null-Fehler-Qualität“. Die Methode Six Sigma besteht aus zwei Dimensionen [Töpfer 2004]: x Einer Managementphilosophie mit fundierter Basis und wirksamen QMWerkzeugen x Einem statistisches Messkonzept zur Messung der Prozessleistungsfähigkeit Als Managementphilosophie kombiniert Six Sigma eine systematische Methodik (DMAIC), einen Projekt- bzw. Prozessmanagementansatz mit einer definierten Toolbox und dem Ziel eine Kultur der Null-Fehler-Qualität im Unternehmen zu etablieren. DMAIC – Define, Measure, Analyze, Improve und Control – steht für den zentralen Ansatz zur Erreichung einer Null-Fehler-Qualität mit dem Six Sigma Ansatz. Die zweite Dimension, das statistische Messkonzept, stellt Kennzahlen zur Verfügung, mit der sich die Leitungsfähigkeit von Prozessen erfassen lässt. Das Qualitätsniveau von 6σ (sechs Sigma) beschreibt eine Quote von 3,4 Fehlern pro 1 Million Fehlermöglichkeiten. Der Durchschnitt der deutschen Unternehmen liegt laut [Töpfer 2004] aktuell bei einem Qualitätsniveau von 3,8σ, dies entspricht 99% fehlerfreier Produkte. Aus unternehmerischer Sicht ist es jedoch nicht immer wirtschaftlich, ein Niveau von 6σ zu erreichen. Vielmehr kann auch ein niedrigerer Wert von 4σ oder 5σ für ein einzelnes Unternehmen sinnvoll sein. Ein niedrigeres Qualitätsniveau hat keinen Einfluss auf den Ansatz als solchen. Die gleichen Methoden und Messverfahren können für ein Ziel von 5σ genauso genutzt werden wie für ein Ziel 6σ. Die Steigerung der Wettbewerbsfähigkeit des Unternehmens steht im Fokus des Six Sigma Ansatzes. Dies geschieht mit einer konsequenten Ausrichtung auf die Wünsche der Kunden und des Unternehmens. Dabei sollen in allen wichtigen Prozessen die wesentlichen Kundenanforderungen vollständig aus Kundensicht und gleichzeitig

11.1 Exkurs: Die Methode Six Sigma zur Verbesserung der Prozessqualität

175

wirtschaftlich erfüllt werden. Six Sigma ist damit auch eine Methode zur Steigerung der Kundenzufriedenheit. In Abbildung 11-1 wird dieser Zusammenhang zwischen Varianz und der zu erwartenden Qualität der Produkte dargestellt. Für die Kenngröße eines Prozesses (gefundene Fehler in Reviews, Längenmaß eines Produktes) wird nach Messung genügend vieler Fälle sowohl der Erwartungswert als auch die Standardabweichung bestimmt. Mit diesen Werten kann wiederum unter der Annahme, dass die Kenngröße normalverteilt ist, auf die Gesamtheit aller Teile geschlossen werden. Es ergibt sich die in Abbildung 11-1 dargestellte Normalverteilung mit einem Mittelwert und einer Standardabweichung σ. Eine weitere wichtige Größe ist der Toleranzbereich, der durch den Kunden geduldet wird. Dieser wird durch eine untere und eine obere Schranke begrenzt. Der Bereich unter einer der Kurven, welcher außerhalb des Toleranzbereichs liegt, beschreibt alle jene Fehler, die vom Kunden oder vom Unternehmen als Fehler wahrgenommen werden; der Bereich zwischen der oberen und der unteren Schranke weist zwar eine Abweichung vom Soll (Mittelwert) auf, wird jedoch nicht als Fehler aufgefasst.

Gemessener Mittelwert entspricht nicht dem Mittelwert des Toleranzbereichs

Prozess mit hoher Variation

Fehlerhaftes Produkt

1σ

6σ

Mittelwert

Fehlerhaftes Produkt

Toleranzbereich Abbildung 11-1: Das Six Sigma Konzept

Ziel des Six Sigma Ansatzes ist es ein Qualitätsniveau von 6σ zu erreichen. Dazu wird im Ansatz die folgende Metrik genutzt: Es wird errechnet, wie häufig die Standardabweichung σ in den Toleranzbereich passt. Wenn der Toleranzbereich (von Mittelwert bis untere Schranke) eine Länge von 6σ hat, spricht man von einem Qualitätsniveau von 6σ; bei kleineren Längen von entsprechend weniger.

176


Aus Abbildung 11-1 wird ersichtlich, dass zur Erreichung dieses Ziels zwei Größen entscheidend sind. Zum einen, dass der Mittelwert der gemessenen Produktkenngröße in der Mitte des Toleranzbereichs liegt, und zum anderen, dass die Varianz des Prozesses niedrig ist. Im Fall einer Abweichung des gemessenen Mittelwerts von der Mitte des Toleranzbereichs (in der Abbildung gepunktet) zeigt sich, dass eine der beiden Seiten zu weit in den Toleranzbereich ragt; entsprechend ist die Menge der fehlerhaften Teile auch zu groß. In diesem Fall ist zwar die Varianz des Prozesses (oder der Herstellungsverfahrens) gering und die erstellten Produkte haben ähnliche Eigenschaften; diese stimmen allerdings in vielen Fällen nicht mit den Erwartungen des Kunden überein. Der Prozess verfehlt sein Ziel. Im zweiten Fall (in Abbildung 11-1 gestrichelt) ist zwar der Mittelwert der gemessenen Produktgröße identisch mit der Mitte des Toleranzbereichs, jedoch weißt der Prozess eine zu hohe Varianz auf. Im Hinblick auf die gemessene Größe bedeutet dies, dass ihr Wert eine zu große Streuung aufweist; die Kurve ist entsprechend flach und breit. Der Bereich unter der Kurve links und rechts außerhalb des Toleranzbereichs ist zu groß und es werden zu viele Produkte erstellt, die nicht den Ansprüchen des Kunden genügen. Die Streuung des Messwertes trifft auch eine Aussage darüber, wie gut ein Prozess vom Unternehmen beherrscht wird. Betrachtet man die graphische Darstellung, so ist es also das Ziel des Six Sigma Ansatzes eine hohe, schmale Verteilung nahe an der Mitte des Toleranzbereichs zu erreichen. Im Six Sigma Ansatz wird ein definiertes Vorgehen zur Erreichung des Qualitätsniveaus 6σ vorgeschlagen. Dieses Vorgehen wird DMAIC-Zyklus, entsprechend der Anfangsbuchstaben seiner Phasen, genannt. Dieser Zyklus setzt sich aus den folgenden Phasen zusammen: x Define Die Define-Phase beschreibt das Problem und markiert gleichzeitig den Start des Six Sigma Projekts. Es werden die Hauptanforderungen der Kunden, in Six Sigma CTQ (Critical to Quality) genannt, erfasst und beschrieben. Dazu kommen zwei Methoden zum Einsatz: die SIPOC- und die VOC-CTQ-Analyse. Die SIPOC-Analyse (Supplier, Input, Process, Output, Customer) dient zur Identifikation des Wertschöpfungsprozesses im Unternehmen. Die VOC-CTQ-Analyse (Voice of the Customer, Critical to Quality) erfasst die Kundenwünsche und leitet aus diesen die Qualitätskriterien eines Produkts ab. Ergebnis der DefinePhase sind somit die für die Verbesserung des Prozesses kritischen Größen, abgeleitet aus den Anforderungen der Kunden.

11.1 Exkurs: Die Methode Six Sigma zur Verbesserung der Prozessqualität

177

x Measure Die Measure-Phase überführt das praktische Problem in ein statistisches Problem. Ausgangsidee ist, dass der Prozess nur dann verbessert werden kann, wenn er auch quantitative analysiert wird. Als Ergebnis dieser Phase werden aussagekräftige Kenngrößen definiert, welche die Grundlage für den späteren Verbesserungsprozess liefern. Die identifizierten Kenngrößen müssen geeignet sein, um Aussagen über die in der Define-Phase bestimmten CTQs treffen zu können. So wird sichergestellt, dass die Kenngrößen, und somit auch die daraus abgeleitete Prozessoptimierung eine Verbesserung des Produkts im Hinblick auf die Kundenanforderungen erlauben. Als Werkzeuge bzw. Methoden zur Identifikation der Kenngrößen eignen sich beispielsweise Quality Function Deployment (QFD), Brainstorming oder Ursache-Wirkungsketten. Mit den identifizierten Kenngrößen und den ersten gemessenen Ergebnissen kann das aktuelle Qualitätsniveau (Status quo) bestimmt werden. x Analyze Die Analyze-Phase identifiziert die Grundursachen einer Prozessabweichung basierend auf den in der Measure-Phase identifizierten Kenngrößen. Im Mittelpunkt stehen die Entwicklung und das Beurteilen von Modellen, mit denen die Abweichungen erklärt werden können. Zur Entwicklung dieser Modelle werden vorrangig mathematisch-statistische Methoden (z.B. Varianzanalyse oder Regressionsanalyse) eingesetzt. Wichtig ist die Unterscheidung zwischen Ursachengröße und Wirkungsgröße sowie die Identifizierung von Haupt- und Nebenproblemen im Prozess. Geeignete Werkzeuge zur Unterstützung der Phase sind beispielsweise Ursache-Wirkungsdiagramme. x Improve In der Improve-Phase werden auf Basis der gefunden Grundursachen Lösungen für vorhandene Probleme im Prozess gesucht. Ziel ist die Identifizierung von Wirkprognosen und Verbesserungsmaßnahmen. Verschiedene Lösungsvorschläge müssen erarbeitet werden und auf ihre Umsetzbarkeit untersucht werden. Die Lösungsvorschläge können mit Hilfe von Simulationen oder einer FMEA bewertet werden und die besten Vorschläge werden für eine Umsetzung ausgewählt. Für diese wird ein überarbeiteter Prozesstyp entworfen, in den die Lösungsvorschläge eingearbeitet sind und mit dem sich konkrete Projektergebnisse und Verbesserungen am Produkt erzielen lassen. x Control In der Control-Phase wird mit dem Ausrollen der Verbesserungsmaßnahmen im Unternehmen begonnen. Ziel ist es, in dieser Phase einen stabilen und ver-

178


besserten Prozess zu etablieren. Es wird überprüft, ob mit dem neuen Prozess die Ursachen für die Abweichungen behoben wurden und ob damit die in der Define-Phase erhobenen CTQs wirksam umgesetzt wurden. Im Rahmen einer Nachkalkulation kann das neue Qualitätsniveau errechnet werden. Mit dem DMAIC-Zyklus ist ein systematischer und strukturierter Ansatz zur Stabilisierung und Verbesserung der Unternehmensprozesse vorhanden. Kennzeichnend für den Six Sigma Ansatz ist die strenge Ausrichtung an den Kundenwünschen (CTQs). Auf diese Weise wird sichergestellt, dass bei den Verbesserungsprojekten nicht am Ziel vorbei optimiert wird. Vielmehr liegt der Fokus auf der Erfüllung der Kundenanforderungen und ist damit auf einen möglichst großen ökonomischen Erfolg ausgerichtet. Ist in einem Prozess ein Qualitätsniveau von 6σ erreicht, so heißt dies, dass bei 1 Million Fehlermöglichkeiten (defects per million oportunities – DPMO) durchschnittlich nur 3,4 Defekte auftreten. Im Bereich der Herstellungsprozesse, dem Ursprung von Six Sigma, lassen sich die zwei Größen „Fehlermöglichkeiten“ und „Defekte“ sehr einfach definieren. Um die Anzahl der Fehlermöglichkeiten darzustellen, wird in [Töpfer 2004] das Beispiel eines Kugelschreibers, bestehend aus vier Teilen genutzt. Bei der Montage dieses Kugelschreibers ergeben sich 28 Fehlermöglichkeiten (4 Teile + 24 theoretische Montagemöglichkeiten). Defekte treten beispielsweise dann auf, wenn der Kugelschreiber nicht schreibt, er falsch montiert wurde, oder die Farben der Teile nicht übereinstimmen. In einem Softwareentwicklungsprojekt lassen sich weder die Größe „Fehlermöglichkeit“ noch „Defekt“ so einfach bestimmen. In [Binder 1997] werden verschiedene Gründe vorgestellt, warum sich Six Sigma – zumindest nicht einfach – an die Erfordernisse eines Softwareentwicklungsprojekts anpassen lässt. Der wohl wichtigste dieser Gründe ist, dass sich Softwareentwicklungsprojekte verglichen mit Herstellungsprozessen nicht wiederholen. Während die Fertigung eines Produkts weitgehend standardisiert ist, basieren Softwareprojekte in der Regel auf einer Menge an einmaligen Anforderungen. Somit können zwei verschiedene Entwicklungsprojekte nicht direkt miteinander verglichen werden. Außerdem spielt der Faktor Mensch in Entwicklungsprojekten eine viel größere Rolle als in Fertigungsprojekten und trägt damit auch zu einer „normalen“ Prozessvariation bei. Demgegenüber spricht sich [Hong et Goh 2003] für eine Anwendung von Six Sigma in Softwareentwicklungsprojekten aus. Er belegt dies mit dem erfolgreichen Einsatz der Methode bei Tata Consultancy Services [Murugappan et Keeni 2003]. In [Hong et Goh 2003] werden für die Messgröße „Fehlermöglichkeiten“ verschiedene Parameter genannt (z.B. Anzahl der Codezeilen, Function Points oder Anzahl der Ausführungen). Als Parameter für einen Softwaredefekt wird „Programmanomalie“ genannt.

11.2 Six Sigma im ProcessNavigator und Umsetzung der QM-Vorgaben

11.2

179

Six Sigma im ProcessNavigator und Umsetzung der QM-Vorgaben

Trotz der Anforderungen, die der Einsatz von Six Sigma zweifellos mit sich bringt, soll diese Methode zur Erreichung der Ebenen RG4 und RG5 im aQM2 genutzt werden; für die Ebenen RG1 bis RG3 ist der Ansatz im allgemeinen zu aufwändig. Dabei ist es weniger das Ziel, ein Qualitätsniveau von 6σ zu erreichen, als vielmehr den methodischen Ansatz und die beschriebenen Werkzeuge zu nutzen, um die Anforderungen der Reifegradebenen RG4 und RG5 umzusetzen. Da beide Ansätze, CMMI bzw. ISO/IEC 15504 auf der einen Seite und Six Sigma auf der anderen, unterschiedliche Philosophien verfolgen, können sie sich gut ergänzen [Card 2000]. Die Stärken von CMMI und ISO/IEC 15504 liegen in der guten Dokumentation der Prozesse und der Etablierung eines Standardprozesses im Unternehmen (Ziele des RG1 bis RG3). Wo sich Six Sigma darauf verlässt, dass gut ausgebildete Mitarbeiter Verbesserungspotenziale aufdecken, bieten die beiden anderen Normen eine vordefinierte Menge an Prozessen (Prozessgebieten), die umzusetzen sind. Die Stärken von Six Sigma liegen im mathematisch-statistischen Grundkonzept, welches in CMMI bzw. der ISO/IEC 15504 nicht vorhanden ist. Der starke Bezug zu Kundenanforderungen sorgt dafür, dass die strategischen Ziele des Unternehmens nicht in den Hintergrund rücken. Die Berücksichtigung der Unternehmensziele wird zwar auch in den anderen beiden Standards gefordert; allerdings stehen sie dort nicht so im Fokus. Insgesamt kann also festgestellt werden, dass sich die beiden Ansätze ergänzen und Schwächen der jeweils einen Methode durch die Stärken der anderen ausgeglichen werden können. In Tabelle 11-1 und Tabelle 11-2 ist die Zuordnung der Six Sigma Phasen zu den Zielen des aQM2 sowie die Unterstützung dargestellt, die der ProcessNavigator leistet. Mit den fünf Phasen des Six Sigma Ansatzes werden alle Ziele des aQM2 abgedeckt; somit können auch alle Anforderungen komplett umgesetzt werden. Das Vorgehen nach Six Sigma unterscheidet sich jedoch von der Reihenfolge der Reifegrade, wie sie im aQM2 vorgeschlagen werden. So liegt der Fokus auf RG4 in der Steuerung eines einzelnen Projekts innerhalb klar definierter Grenzen („kleiner Regelkreis“). Bei der Umsetzung der Ziele des RG5 hingegen liegt der Fokus auf einer Optimierung der Prozesse („großer Regelkreis“). Entsprechend müssen die Methoden des Six Sigma Ansatzes genutzt werden. Außerdem verschiebt sich die Gewichtung der Phasen. So baut RG5 auf den Ergebnissen des RG4 auf und kann die dort vorhandenen Messgrößen nutzen; entsprechend rückt die Control-Phase in den Mittelpunkt.

180


Tabelle 11-1: Zuordnung der Six Sigma Phasen zu den aQM2 Zielen auf RG4

RG 4 Anforderung

Six Sigma Phase

Unterstützung durch den ProcessNavigator

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

DefinePhase

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

MeasurePhase

Ausführungsebene Ziel 4.3: MeasureSammeln und Erfassen von Phase Messdaten

Erfassung und Speicherung der Prozessdaten in der Wissensbasis.

Ziel 4.4: Überwachung des Projekts und statistische Analyse der Messdaten

AnalyzePhase

Export der Daten aus der Wissensbasis; anschließender Import und Auswertung in einem Statistikwerkzeug.

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

ImprovePhase/

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

ControlPhase

Die Rolle des ProcessNavigators bei der Umsetzung der Reifegradebenen RG4 und RG5 ist primär die eines Datenlieferanten. Im Ausführungsprotokoll des ProcessNavigators sind alle für das Six Sigma Projekt notwendigen Daten vorhanden. Dort ist sowohl der geplante als auch der tatsächlich ausgeführte Prozess gespeichert; es sind Informationen über nicht verfehlte Meilensteinziele und Termine und die erstellten Daten bzw. die Dokumente verfügbar. Sofern geeignete Schnittstellen für den Transfer dieser Daten in die Six Sigma Werkzeuge vorhanden sind, ist auch eine


181

direkte Implementierung der mathematisch-statistischen Funktionen im ProcessNavigator für eine erfolgreiche Umsetzung der Ziele nicht erforderlich. Die Umsetzung des Ziels 4.1 (Definition von quantitativen Zielen) erfolgt in der Define-Phase des Six Sigma Ansatzes durch eine SIPOC- bzw. eine VOC-CTQ-Analyse. Hierdurch können die Ziele der Messungen basierend auf den Kundenanforderungen erfüllt werden. Sind keine externen Kunden involviert, können stattdessen auch interne Mitarbeiter mit den gleichen Methoden die Messziele definieren. Statt der SIPOC-Analyse kann auch der definierte Prozesstyp herangezogen werden. Im Ziel 4.2 (Identifikation von Messpunkten) werden ausgehend von den vorher definierten Zielen die Messpunkte festgelegt. Dazu ist beispielsweise die Methode QFD geeignet. Beide Methoden können unabhängig von einer Systemunterstützung durch den ProcessNavigator mit externen Werkzeugen durchgeführt werden. Das Sammeln und Erfassen von Messdaten (Ziel 4.3) wird dagegen direkt durch den ProcessNavigator unterstützt. Im Ausführungsprotokoll können alle für das Six Sigma Projekt notwendigen Daten und Informationen erfasst werden. Zur Analyse der Daten (Ziel 4.4 Überwachung des Projekts und statistische Analyse) ist es zweckmäßig, die Daten in ein externes Analysewerkzeug zu exportieren. Dort können verschiedene Analysen (z.B. Regressions- oder Varianzanalysen) auf den Daten des ProcessNavigators durchgeführt werden, um Abweichungen des Prozesses zu erkennen und aufzudecken. Während im Six Sigma Ansatz schon das Ziel verfolgt wird, die Ursachen für die Abweichungen vom vorgegebenen Ziel zu beheben, muss im aQM2 auf RG4 nur die Abweichung vom Ziel erkannt werden; die Behebung der Ursachen (Prozessoptimierung) ist erst auf RG5 gefordert. Ziel 4.5 fordert die Erarbeitung von Korrekturmaßnahmen und die Steuerung des Projekts. Dazu können die Methoden der Six Sigma Improve-Phase genutzt werden. Allerdings liegt auch hier der Fokus auf der Steuerung des aktuell laufenden Projekts und nicht auf der Optimierung des Prozesses. Wenn verschiedene Kenngrößen identifiziert und aussagekräftige Analysemethoden gefunden wurden, kann das Zusammenwirken zwischen ProcessNavigator und Analysewerkzeugen automatisiert werden. Die so gewonnenen Kennzahlen können in die Monitoring-Komponente des ProcessNavigators (Abschnitt 9.2.1) eingefügt werden. Dort ergänzen sie die vorhandenen Kennzahlen und informieren den Projektleiter detailliert über den aktuellen Projektstatus. Durch die Nutzung mathematischer Methoden sollen Abweichungen früher erkannt werden und vorhersagbare Projekte im Unternehmen ermöglicht werden.

182


Tabelle 11-2: Zuordnung der Six Sigma Phasen zu den aQM2 Zielen auf RG5

RG 5 Anforderung

Six Sigma Phase

Unterstützung im ProcessNavigator

Planungsebene Ziel 5.1: Definition der strategischen Verbesserungsziele

DefinePhase/ MeasurePhase

Ausführungsebene Ziel 5.2: Analyse der Daten

AnalyzePhase

Export der Daten aus der Wissensbasis. Anschließender Import und Auswertung in einem Statistikwerkzeug.

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

AnalyzePhase

Wie bei Ziel 5.2: Export der Daten aus der Wissensbasis mit anschließendem Import und Auswertung der Daten in einem Statistikwerkzeug.

Planungsebene Ziel 5.4: Erarbeiten von Verbesserungsmöglichkeiten

ImprovePhase

Ziel 5.5: Entwickeln einer Umsetzungsstrategie

ImprovePhase

Ziel 5.6: ControlUmsetzen der Verbesserungen Phase

Umsetzung in einem Pilotprojekt im ProcessNavigator. Anpassen der Standardprozesse (Prozesstypen) für die zukünftige Ausführung im ProcessNavigator.


183

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

ControlPhase

Messung und Kontrolle der im ProcessNavigator erfassten Ausführungsdaten.

Wie schon RG4 beginnt auch RG5 mit einer Definition der strategischen Verbesserungsziele (Ziel 5.1). Dazu werden wieder die Methoden der Six Sigma Define-Phase herangezogen. Statt der Messziele werden nun die Verbesserungsziele identifiziert. Zu diesen neuen Zielen müssen Messgrößen im Prozess gefunden werden (MeasurePhase). Auch die Analyse der Daten (Ziel 5.2) und die Aufdeckung von Gründen für Abweichungen (Ziel 5.3) nutzen die gleichen Mechanismen, die schon auf RG4 eingeführt wurden. Allerdings sollen hier Abweichungen nicht nur erkannt, sondern auch ihre Gründe gefunden werden. Im Anschluss an die Aufdeckung der Gründe für Prozessabweichungen müssen Verbesserungsmöglichkeiten (Ziel 5.4) erarbeitet und im Hinblick auf ihre Umsetzbarkeit in den Prozessen des Unternehmens untersucht werden. Die Entwicklung der Umsetzungsstrategie (Ziel 5.5) beinhaltet die Überarbeitung des Soll-Prozesses (Prozesstyp) oder die Anpassung der für die Mitarbeiter im PN-Desktop vorhandenen Informationen. Die Machbarkeit und Effektivität der Verbesserungen kann im Rahmen eines Pilotprojekts durch den ProcessNavigator getestet werden. Die Umsetzung der Verbesserungen (Ziel 5.6) erfolgt durch eine Freischaltung des neuen Sollprozesses für alle Projekte des Unternehmens. Der neue Prozess steht damit im ProcessNavigator zur Verfügung und kann von den Mitarbeitern genutzt werden. Die fortlaufende Sicherstellung der Effektivität der Verbesserung (Ziel 5.7) kann durch Messung der Ausführungsdaten erreicht werden. Die Methode Six Sigma kann als Werkzeug genutzt werden, um die Reifegradebenen RG4 und RG5 zu erreichen. Im Vergleich zu den Methoden der Reifegradebenen RG1 bis RG3 stellt sie einen schwergewichtigen (umfangreichen) Ansatz dar, der jedoch durch seine mathematisch-statistische Grundlage ein systematisches Vorgehen bietet und damit bessere Ergebnisse im Bezug auf die Steuerung der Projekte und das Finden von Verbesserungen am Prozesstyp verspricht.

Teil III Umsetzung und Schlussfolgerungen

12

Systemarchitektur

In diesem Kapitel wird die Architektur des ProcessNavigators vorgestellt. Ziel ist es eine flexible Systemarchitektur zu finden, die sich einfach an verschiedene Unternehmensumgebungen anpassen lässt. Einen wesentlichen Anteil am erfolgreichen Einsatz des ProcessNavigators in Unternehmen macht dabei die Bereitstellung von Prozesswissen im Unternehmen aus. Nur wenn der ProcessNavigator genügend relevante Informationen für die Nutzer bereitstellen kann, wird er durch die Mitarbeiter im Unternehmen akzeptiert werden. Aus diesem Grund liegt nach der Vorstellung der Systemarchitektur der Diskussionsschwerpunkt auf dem Entwurf eines flexiblen Speichersystems zur Ablage des Unternehmens- und Prozesswissens. 12.1

Architekturübersicht ProcessNavigator

Bevor die Systemarchitektur des ProcessNavigators beschrieben wird, sollen das zu Grunde liegende Software-Framework und die damit verbundenen Lösungskonzepte erläutert werden. Als Basis für die Implementierung des ProcessNavigators wurde das Web-Framework JavaServer Faces (JSF) [JSF 2009; Mann 2004] aufbauend auf dem Application-Server Apache Tomcat [Apache Tomcat 2009] gewählt. Durch das WebFramework JSF wird im System das Konzept der Trennung von Struktur, Inhalt und Darstellung realisiert; zusammen mit einer geeigneten Speicherschicht wird eine 3Schichten-Architektur bestehend aus Darstellungsschicht, Anwendungsschicht und Speicherschicht umgesetzt. Das Framework JSF, welches in der Anwendungsschicht genutzt wird, ist ein Standard zur Entwicklung von Web-Komponenten. JSF baut auf dem JavaServer Pages (JSP) Standard [JSP 2009] auf und ist damit eine Weiterentwicklung dieses Standards. Im Vergleich zu JSP weist JSF einen höheren Abstraktionsgrad auf und zeichnet sich vor allem durch seine Trennung der Darstellungskomponenten von der Anwendungslogik des Systems aus. In JSF kommen drei wesentliche Bestandteile zum Einsatz. Die Darstellungsschicht besteht aus einer Menge an Darstellungskomponenten, die in Tag-Bibliotheken zusammengefasst werden. Jedes Tag spezifiziert in der Sprache XML ein Kontrollelement, das in der Web-Seite angezeigt wird. Tags werden vor dem Seitenaufruf durch einen Compiler in html-Code umgewandelt. Die Anwendungsebene besteht aus JavaBeans [JavaBeans 2009]. JavaBeans sind Komponenten, auf die über ein standardisiertes Interface zugegriffen werden kann. Auf dieser Ebene wird die Logik der Webanwendung mit den Mitteln der Programmiersprache Java erstellt; somit können auch alle in dieser Sprache vorhandenen Bibliotheken zur Implementierung des ProcessNavigators genutzt werden. Als dritte wichtige Komponente regelt

188

12 Systemarchitektur

eine Konfigurationsdatei die Kommunikation zwischen der Darstellungsebene und der Anwendungslogik. Die Speicherschicht nutzt einen RDF-Triple Store [Broekstra et al. 2002 ] zur Speicherung der im ProcessNavigator erzeugten Daten. Triple Stores sind mit Relationalen Datenbanken vergleichbar, da sie ein allgemeines Datenmodell besitzen und eine Sprache (SparQL) [Prud'hommeaux et Seaborne 2008] zum Zugriff auf die im Triple Store vorhanden Daten bereitstellen. Im Unterschied zu Relationalen Datenbanken ist ein Triple Store jedoch dazu ausgelegt RDF-Statements zu speichern. Diese werden jeweils als Tripel (Subjekt – Prädikat – Objekt) im Triple Store abgelegt. Aus der Wahl der Architektur ergeben sich verschiedene Konsequenzen für den ProcessNavigator: x Multi-User-System Durch die Nutzung eines Web-Servers und die damit verbundene Darstellung des ProcessNavigators für die Mitarbeiter in einem Web-Browser wird direkt ein Multi-User-System umgesetzt. Dies war eine der Grundanforderung für die Implementierung des Systems. Durch die Nutzung des Application-Servers wird die nötige Client-Server-Infrastruktur automatisch bereitgestellt. x Einfache Verteilung der Anwendung im Unternehmen Die Anwendung eines Web-Servers hat noch einen weiteren Vorteil im Bezug auf den Unternehmenseinsatz. Web-Browser gehören in Unternehmen zur Standardausstattung von Computer-Arbeitsplätzen; sie sind somit auf den Computern vorhanden und können von den Mitarbeitern genutzt werden. Die einzige Komponente, die darüber hinaus im Unternehmen installiert werden muss, ist der Application-Server. x Zentrale Datenhaltung Durch die Nutzung des Application-Servers ist im ProcessNavigator auch eine zentrale Datenhaltungskomponente vorhanden. Im clientseitigen WebBrowser werden weder Daten noch andere Informationen gespeichert und eine manuelle Status-Synchronisation kann somit entfallen. Der gesamte Prozessausführungsstatus wird zentral im Application-Server gespeichert. In Abbildung 12-1 ist die Grobarchitektur des ProcessNavigators dargestellt. Die Architektur des Systems orientiert sich an der Entscheidung, einen Web-ApplicationServer als Implementierungsgrundlage zu nutzen. Sie ist in die drei Schichten Darstellungsschicht, Anwendungsschicht und Speichersystem unterteilt. Die Darstellungsschicht unterteilt sich in die beiden Komponenten PN-Worklist und PN-Desktop. Wie in Kapitel 9 beschrieben ist die Worklist die erste Komponente, über die der Nutzer

12.1 Architekturübersicht ProcessNavigator

189

mit dem System interagiert. Nach einer Auswahl eines Arbeitsschrittes durch den Mitarbeiter wird der PN-Desktop angesteuert.

Prozessnavigator-Worklist

Prozessnavigator-Desktop

Ausführungskern

Darstellungsschicht Funktionaler Aspekt


Organisatorisch er Aspekt

Datenorientiert er Aspekt






Modellkern

Anwendungsschicht

Funktionaler Aspekt

Speichersystem Abbildung 12-1: ProcessNavigator-Architektur

Den beiden Komponenten der Darstellungsschicht werden jeweils verschiedene Module aus der Anwendungsschicht zugeordnet. Während die Darstellungsschicht dafür zuständig ist, die im ProcessNavigator vorhanden Informationen anzuzeigen, wird die Logik des Systems in der Anwendungsschicht realisiert. Dazu wird in der Anwendungsschicht für jeden Aspekt des Prozessmodells ein eigenes Modul vorgesehen. Diese Zuordnung zwischen einem Aspekt der AOPM und einem in der Anwendungsschicht ist nicht zwingend für eine Umsetzung des Systems, allerdings ergibt sich so eine klare Aufgabentrennung für die Module. So ist es die Aufgabe des Moduls „Funktionaler Aspekt“ zusammen mit dem Modul „Verhaltensorientierter Aspekt“ alle Arbeitsschritte, die im aktuellen Projekt enthalten sind, in der richtigen Reihenfolge bereitzustellen; gemeinsam bilden beide Module den Ausführungskern des ProcessNavigators. Das Modul „Organisatorischer Aspekt“ filtert diese Schritte nach dem angemeldeten Nutzer und ermöglicht so die Worklist-Konfiguration „Meine Schritte“ (Abschnitt 9.1.5). Die Module „Datenorientierter Aspekt“ und „Operationaler Aspekt“ sind in den ProcessNavigator-Desktop eingebunden und stellen dort die Kontextinformationen für die Prozessausführung bereit. Von den beschriebenen Modulen ist einzig das Modul „Funktionaler Aspekt“ sowohl in der Worklist als auch im ProcessNavigator-Desktop eingebunden. In der Worklist stellt es die Arbeitsschritte und im

190


Desktop Informationen (z.B. Verfahrensanweisungen) zu dem gewählten Arbeitsschritt bereit. Zu jedem Modul der Anwendungsschicht ist im Speichersystem eine entsprechende Speicherstruktur vorhanden. Hier werden insbesondere die Eigenschaft von RDFTriple Stores zur Speicherung von modulare und erweiterbaren Datenstrukturen genutzt [Cullot et al. 2003]. Ähnlich wie in der Anwendungsschicht sind die beiden Teilstrukturen „Funktionaler Aspekt“ und „Verhaltensorientierter Aspekt“ wieder stärker verzahnt als die anderen Teilstrukturen; gemeinsam bilden sie den Modellkern. Jedes Modul der Anwendungsschicht greift zur Erfüllung seiner Aufgaben auf die jeweilige Teilstruktur im Speichersystem zurück. Andererseits werden die Eingaben der Nutzer, also die Ausführung der Arbeitsschritte sowie die erstellten Daten von der Darstellungsschicht über die Anwendungsschicht in das Speichersystem eingetragen.

WorklistSichten

Ausführungskern

Speichersystem

PN-Desktop

PN-Worklist Org.Zuweisung

Daten/ Dokumente

Operationen/ Werkzeuge

Wissensbasis

Zugriff auf Worklist

1) Laden der Arbeitsschritte

2) Filtern der Arbeitsschritte nach Organisation

Zugriff auf Desktop

3) Auswahl eines Arbeitsschrittes durch Nutzer

4) Anzeige der Dokumente im Desktop

5) Anzeige der Werkzeuginformationen im Desktop

Abbildung 12-2: Aufrufsequenz im ProcessNavigator

Der Nachrichtenaustausch zwischen den verschiedenen Komponenten des ProcessNavigators wird in Abbildung 12-2 gezeigt. Hier ist insbesondere das Zusammenspiel zwischen den Komponenten der Anwendungs- und der Speicherschicht von Bedeutung; alle in der Worklist oder im Desktop angezeigten Informationen werden letztlich aus dem Speichersystem gezogen.


191

In Abbildung 12-2 ist ein typisches Szenario der Benutzung des ProcessNavigators dargestellt. Ein Nutzer sucht aus der Worklist zuerst einen Schritt aus und arbeitet anschließend in den beiden Reitern „Dokumente“ und „Werkzeuge“. Er erstellt oder bearbeitet die Dokumente, die im Projekttyp vorgesehen sind. Die Information, welches Dokument er erstellen muss sowie ein Template dazu, findet er im Reiter „Dokumente“; im Reiter „Werkzeuge“ findet er Hinweise, wie er die Werkzeuge benutzen kann, die er zur Erstellung des Dokuments verwendet. Im System werden die einzelnen Programmmodule und das Speichersystem in einer bestimmten Reihenfolge genutzt. Zuerst müssen die vorhandenen Schritte in die Worklist eingetragen werden (1). Dazu wird das Modul „Ausführungskern“ aufgerufen, welche wiederum auf den im Speichersystem abgelegten Modellkern zurückgreift. Wenn ein Nutzer über die Worklist-Konfiguration „Meine Aufgaben“ auf einen Arbeitsschritt zugreifen will, werden aus allen vorhanden Schritten nur noch jene ausgewählt, für die der Mitarbeiter verantwortlich ist. Auch hier geht die Anfrage wieder von der Worklist aus; das aufgerufene Modul „Organisatorischer Aspekt“ überprüft im Speichersystem, welche Schritte dem Nutzer zugewiesen sind und gibt diese Informationen an die Worklist zurück (2). Nach der Auswahl eines Schrittes aus der Worklist wird der PN-Desktop aktiviert (3) und die Worklist deaktiviert. Im PNDesktop kann der Nutzer zwischen den dort angebotenen Informationen wählen. Er hat beispielsweise die Möglichkeit, sich die Eingangs- und Ausgangsdokumente des Arbeitsschritts (4) oder geeignete Werkzeuge (5) anzeigen zu lassen. In beiden Fällen gehen die Anfragen von der Darstellungsschicht aus und werden über die entsprechenden Module der Anwendungsschicht an das Speichersystem weitergeleitet. Nach Abschluss der Bearbeitung des Arbeitsschrittes wird der Desktop wieder verlassen und das System springt zur Worklist zurück. Dort beginnt das beschriebene Verfahren wieder mit der Aktualisierung der vorhandenen Arbeitsschritte. 12.2

Ontologiebasiertes Speichersystem

Zur Speicherung der Ausführungsdaten im Speichersystem wurde ein RDF-Triple Store gewählt. In diesem können Datenstrukturen in den Sprachen Resource Description Framework (RDF) [Brickley et Guha 2004; RDF 2009] und Web Ontology Language (OWL) [Allemang et Hendler 2008; van Harmelen et McGuinness 2009] abgelegt werden. Beide wurden als Teil der Semantic Web Initiative [Berners-Lee et al. 2001] vom World Wide Web Consortium (W3C) [W3C 2009] entwickelt. Das Ziel beider Sprachen war es, Ressourcen in Netzwerken (insbesondere dem World Wide Web) mit Metadaten so zu beschreiben, dass die Beziehungen der Informationen untereinander sowohl durch Menschen als auch durch Rechnersysteme gelesen werden können [Hitzler et al. 2008]. Neben einer textbasierten Suche, wie sie in aktuellen

192


Suchmaschinen implementiert ist, soll so auch eine semantische Suche ermöglicht werden. Diese Art der Suche kann die Beziehungen zwischen Daten berücksichtigen und erlaubt es dem Anwender somit auch diese als Erweiterung mit in die Suche einzubeziehen. Da in Unternehmen die zur Entwicklung eines Produktes notwendigen Informationen über viele Datenquellen verteilt gespeichert werden können, wurde eine auf RDF und OWL basierte Datenstruktur als Implementierungsgrundlage für das Speichersystem des ProcessNavigators gewählt. Darüber hinaus erlauben RDF und OWL die explizite Speicherung der Beziehungen zwischen den vorhandenen Konzepten, wie sie in der semantischen Suche genutzt wird. RDF ist eine formale Sprache zur Beschreibung strukturierter Informationen. Daten werden in RDF immer in einer Subjekt-Prädikat-Objekt Beziehung gespeichert. Durch die Menge aller Beziehungen wird ein Graph beschrieben, in dem die Informationen strukturiert abgelegt werden. Subjekt und Objekt beschreiben die Knoten des Graphen; Prädikate beschreiben seine Kanten und damit die Beziehungen zwischen den Knoten. Die Sprache RDF wird vor allem dazu genutzt, um die Beziehungen zwischen Individuen (einzelne Ressourcen) zu beschreiben. RDF Schema (RDFS) [Allemang et Hendler 2008; RDFS 2009] nutzt die Sprachmöglichkeiten von RDF, um Hintergrundinformationen (terminologisches Wissen oder auch Schemawissen) über die im Datenschema vorhandenen Individuen zu definieren [Hitzler et al. 2008]. Mit Hilfe von RDFS können einfache Ontologien beschrieben werden. Der Begriff Ontologie soll an dieser Stelle gleichbedeutend mit dem Begriff Wissensbasis genutzt werden und beschreibt sowohl die Beziehungen zwischen den Konzepten im Schema als auch die dazu gespeicherten Individuen. OWL nutzt den in RDFS definierten Sprachumfang und definiert in der Ausprägung OWL DL (Description Logic) eine Sprache zur Beschreibung von Ontologien. Im ProcessNavigator wird OWL (in der Ausprägung DL) genutzt, um die zur Ausführung des Prozesses nötigen Informationen zu speichern. Wie in der Grobarchitektur (Abbildung 12-1) vorgestellt, werden zu den Aspekten des Prozessmodells Teilmodelle erstellt, die miteinander kombiniert die Basis für die Prozessausführung ergeben. In den folgenden Abschnitten werden der Modellkern (bestehend aus Funktionalen und Verhaltensorientierten Aspekt), der Organisatorische und der Datenorientierte Aspekt vorgestellt. Der Operative Aspekt ist verglichen mit den vier anderen Aspekten einfach aufgebaut und ordnet einem Arbeitsschritt eine Menge von Werkzeugen zu, die in diesem Schritt verwendet werden können; er soll hier aus diesem Grund nicht weiter betrachtet werden. In [Faerber et al. 2008] wurde für die Entwicklung von Produkten aus dem Maschinenbau gezeigt, wie die Wissensbasis genutzt werden kann, um weiterführende Informationen für Mitarbeiter in das Speichersystem zu integrieren.


193

Grundsätzlich sind alle im Speichersystem vorhandenen Daten QM-relevant. Wie in Kapitel 10 gezeigt, können Typ- und Ausführungsdaten genutzt werden, um die Umsetzung der QM-Anforderungen im Prozess zu belegen und um Verbesserungsmöglichkeiten am Prozesstyp zu identifizieren. Allerdings werden auch die Anforderungen des QM-Standards explizit im Speichersystem referenziert. Auf diese Weise wird die in Abschnitt 7.4 vorgestellte Abbildung des Prozesstyps auf den QMStandard realisiert. 12.2.1 Der Modellkern im Speichersystem Im Modellkern wird das Datenstrukturgrundgerüst gespeichert. Dieses besteht aus dem Funktionalen und dem Verhaltensorientierten Aspekt und legt damit sowohl die durchzuführenden Arbeitsschritte als auch deren Abfolge fest. Im Speichersystem wird das Modell mit derselben Struktur gespeichert, die der Projekttyp hat. Es bestehen hier also klar definierte Vorgänger und Nachfolgerbeziehungen, die durch den Daten- bzw. Verhaltensorientierten Aspekt definiert werden. Erst in der Anwendungsschicht werden diese Datenstrukturen im Sinne der flexiblen Prozessausführung interpretiert. Die anderen für die Prozessausführung notwendigen Teilmodelle werden anschließend in Relation zum Modellkern gesetzt und an diesem verankert. Der Modellkern hat zusätzlich zur Bereitstellung der vorhandenen Arbeitsschritte und ihrer Reihenfolge auch die Aufgabe den Status der Prozessausführung und die Ausführungshistorie abzuspeichern. Sprache M2

ipm:Process

project:Project

rdf:type

Typ M1

task:taskOfProject task:Task

ipm:PType1 rdf:type

Instanz M0

task:Transition task:fromStatus task:transition task:toStatus task:hasStatus

task:Status

rdf:type

task:T1

Abbildung 12-3: Speicherung von Arbeitsschritten in der Ontologie

In Abbildung 12-3 ist die Abbildung des Funktionalen Aspekts in das Speichersystem dargestellt. Es werden die vorhandenen Konzepte (Ellipsen, abgerundeten Rechtecke und Rechtecke) sowie deren Beziehungen zueinander gezeigt. Ellipsen repräsentieren Konzepte, die in der Wissensbasis vordefiniert sind. Rechtecke mit abgerundeten Ecken kennzeichnen Elemente, die durch den Import des Projekttyps in die Wissens-

194


basis aufgenommen werden, und in Rechtecken werden jene Konzepte dargestellt, die durch Instanziierung des Projekttyps vor der Ausführung erstellt werden. In diesem Abschnitt wird nur die Abbildung der zentralen Elemente des Funktionalen und Verhaltensorientierten Aspekts (Projektschritt und Kontrollfluss) beschrieben; das vollständige Datenschema der beiden Aspekte ist in [Sesselmann 2008] dargestellt. Bei der folgenden Beschreibung der Datenstrukturen wird, sofern es nicht zu Mehrdeutigkeit führt, auf den Namespace der Elemente verzichtet (z.B. wird statt IPM:PROCESS wird nur PROCESS genutzt). Die linke Seite von Abbildung 12-3 zeigt die Sprachebenen des Modells (PROCESS, PTYPE1 und T1). Diese korrespondieren mit den Sprachebenen des Meta-Modells (Abbildung 3-1). Das Konzept PROCESS bezieht sich auf das Element Projektschritt (Abbildung 8-1). Nach dem Import eines Projekttyps sind dessen Elemente verfügbar. PTYPE1 bezeichnet einen konkreten Projektschritt aus dem Modell, der nach dem Import zu T1 instanziiert wird. T1 bezeichnet damit jenes Element, welches in der Worklist angezeigt werden kann. T1 ist sowohl eine Instanz von PTYPE1 als auch des Konzepts TASK. Ein TASK wird einem Projektbezeichner über die Beziehung TASKOFPROJECT zugeordnet. Dieser Bezeichner beschreibt das Projekt näher. Zur Speicherung des aktuellen Ausführungsstatus wird jedem TASK ein STATUS zugewiesen, die in ihrer Gesamtmenge den aktuellen Projektstatus festlegen. Die TRANSITIONEN eines TASKS beschreiben seine Ausführungshistorie und können zur Rekonstruktion des Prozessablaufs genutzt werden. T1

T2 ipm:incomingConnector

Sprache M2

ipm:Process

ipm:Connector ipm:outgoingConnector rdf:type

rdf:type rdf:type ipm:PType1

ipm:outgoingConnector

Typ M1

ipm:Connector1

ipm:incomingConnector ipm:PType2 rdf:type rdf:type

Instanz M0

task:T1

task:T2

Abbildung 12-4: Speicherung einer Sequenz in der Ontologie

Neben dem Funktionalen Aspekt wird im Modellkern auch der Verhaltensorientierte Aspekt gespeichert. Dieser beschreibt die Abfolge der einzelnen Prozessschritte. Abbildung 12-4 zeigt eine einfache sequenzielle Abfolge der beiden Prozessschritte T1 und T2.


195

Die beiden Prozessschritte werden in der Ontologie als Tasks T1 und T2 gespeichert. Beide sind aus den Projektschritten PTYPE1 bzw. PTYPE2 und somit auch aus dem Typ PROCESS instanziiert. Die in Abbildung 12-3 dargestellte Ableitung von T1 aus TASK besteht weiterhin; sie wird in der Abbildung 12-4 zur Vereinfachung nicht dargestellt. Zur Darstellung des Kontrollflusses wird vom Element PROCESS ein ausgehender (OUTGOINGCONNECTOR) und ein eingehender Konnektor (INCOMINGCONNECTOR) definiert. Der Konnektor verbindet somit beide Projektschritte mit einem Kontrollfluss. Auf Ebene M1 existiert somit eine Beziehung vom Typ PTYPE1 zu CONNECTOR1 (outgoing) und eine Beziehung (incoming) vom Typ PTYPE2 zu CONNECTOR1. Da T1 und T2 aus den Typen PTYPE1 und PTYPE2 instanziiert werden, trifft diese Kontrollflussbeziehung auch auf die beiden Tasks zu. AND

T2

T1 T3 ipm:incomingConnector

Sprache M2

ipm:Process

ipm:Connector ipm:outgoingConnector rdf:type

rdf:type

rdf:type

rdf:type ipm:PType1

ipm:AND_Connector1

ipm:outgoingConnector ipm:incomingConnector

Typ M1

ipm:PType2

ipm:incomingConnector ipm:PType3

rdf:type rdf:type

rdf:type

Instanz M0

task:T1

task:T2

task:T3

Abbildung 12-5: Speicherung eines AND-Konnektors in der Ontologie

Abbildung 12-5 zeigt, wie zusätzlich zu einfachen sequentiellen Kontrollflüssen auch komplexe Konnektoren (z.B. ein AND-Konnektor) in der Ontologie abgebildet werden können. Wie im Fall einfacher Kontrollflüsse werden wieder die OUTGOINGCONNECTOR und INCOMINGCONNECTOR Beziehungen zur Verknüpfung zweier Prozesse genutzt. Allerdings wird als Verbindungselement ein AND-Konnektor genutzt. Dieser besitzt eine Eingangskante (outgoing aus PTYPE1) und zwei Ausgangskanten (incoming nach PTYPE2 und PTYPE3). OR- und XOR-Konnektoren werden auf dieselbe Weise in der Ontologie dargestellt; sie unterscheiden sich lediglich durch ihren Bezeichner.

196


Während der Ausführung wird dieser durch den Ausführungskern ausgewertet und der Prozess entsprechend der Semantik des Elements ausgeführt. qm:Process qm:output qm:input

qm:bpOfProcess

qm:WorkProduct

qm:BasePractice rdf:type ipm:implements qm:ENG.6.BP2 Develop software units

rdf:type

ipm:Entwicklung der Lösungskomponenten ipm:produces

ipm:implements qm:11-05 Software unit

ipm:Software Module

rdf:type

rdf:type task:Modul Nutzerschnittstelle

task:Entwicklung der Nutzerschnittstelle

Abbildung 12-6: Abbildung des QM-Standards im Speichersystem

Im Modellkern wird auch die Abbildung des Prozesstyps auf die Anforderungen der Prozessdimension des QM-Standards explizit abgelegt (Abbildung 12-6). Die Elemente des QM-Standards (in diesem Fall der ISO/IEC 15504) werden in der Abbildung dunkel dargestellt. Oberstes Strukturierungselement ist der Prozess QM:PROCESS (z.B. „ENG.6 Software construction“). Dieser besitzt sowohl Work Products, welche jeweils Eingangs- oder Ausgangsdatum des Prozesses sein können als auch Base Practices. Im Prozesstyp (Abbildung 7-4) ist ein Prozessschritt „Entwicklung der Lösungskomponenten“ modelliert. Dieser besitzt als Ausgangsdatum (Beziehung IPM:PRODUCES) das Element „Software Module“. Sowohl der Prozesstyp als auch das Datenelement werden den jeweils korrespondierenden Elementen aus der ISO/IEC 15504 zugeordnet (Beziehung IPM:IMPLEMENTS). Durch diese Beziehung kann das später im Projekt entstandene Artefakt „Modul Nutzerschnittstelle“ eindeutig der Anforderung aus dem QM-Standard („11-05 Software unit“) zugeordnet werden. Gleiches gilt für die Zuordnung des Arbeitspakets „Entwicklung der Nutzerschnittstelle“ zur Base Practice „ENG.6.BP2 Develop software units“. Damit wird die in Abbildung 7-6 dargestellte Abbildung des Prozesstyps auf die QM-Anforderungen im Speichersystem umgesetzt. 12.2.2 Der Organisatorische Aspekt im Speichersystem Neben dem Verhaltensorientierten Aspekt ist der Organisatorische Aspekt maßgeblich dafür, welche Arbeitsschritte einem Mitarbeiter zur Ausführung angezeigt


197

werden. In der Konfiguration „Meine Aufgaben“ der Worklist werden nur jene Schritte angezeigt, die auch dem jeweiligen Mitarbeiter zugeordnet sind (Abschnitt 9.1.5). Für die Modellierung von personenbezogenen Informationen sind bereits vordefinierte Ontologien verfügbar. Zur Abbildung des Organisatorischen Aspekts wird die Ontologie Friend of a Friend (FOAF) [FOAF 2009] genutzt; sie lässt sich ohne große Anpassung für die Organisationsverwaltung im ProcessNavigator verwenden [Zeising 2009]. Die FOAF-Ontologie sieht zunächst das abstrakte Konzept AGENT vor (Abbildung 12-7). Ein Agent kann dabei eine Person, eine Gruppe oder eine ganze Organisation sein. Die Konzepte GROUP (Gruppe) und PERSON sind jeweils Spezialisierungen des Konzepts AGENT. Einer Person werden über die Beziehungen FIRSTNAME und SURNAME Vor- und Nachname zugeordnet. Eine Gruppe wird nur durch einen Namen bezeichnet; sie kann allerdings wieder Bestandteil einer anderen Gruppe oder Organisation sein. Dies wird durch die Beziehung MEMBER ausgedrückt.

foaf:Agent foaf:member rdfs:subClassOf rdfs:subClassOf foaf:Group foaf:name rdfs:literal

foaf:Person foaf:firstName rdfs:literal

foaf:surName rdfs:literal

Abbildung 12-7: Speicherung der Organisationsstruktur in der Ontologie

Wie in der Abbildung des Funktionalen Aspekts in die Ontologie beschrieben, wird die Ausführungshistorie des Projekts (Abbildung 12-3) im Speichersystem abgelegt. Das entsprechende Datenschema wird in Abbildung 12-8 vorgestellt. Der Projektstatus wird im ProcessNavigator als Abfolge von Statusänderungen der Aufgaben (Transitionen) gespeichert. Zu jeder TRANSITION wird sowohl der Ausgangsstatus (über die Beziehung FROMSTATUS) als auch der Zielstatus (TOSTATUS) erfasst. Aus der Menge der im Projekt durchgeführten Statusänderungen lässt sich die Projekthistorie rekonstruieren. Der Anwender (PERSON), welcher eine Statusänderung ausgelöst hat (z.B. die Beendigung eines Arbeitsschrittes), wird über die Beziehung PERFORMEDBY gespeichert.

198

12 Systemarchitektur task:Task task:transition task:Transition

task:fromStatus

org:performedBy

foaf:Person

task:toStatus

task:Status

Abbildung 12-8: Speicherung der Ausführungshistorie in der Ontologie

In der Sprache OWL können nicht nur Beziehungen zwischen Konzepten, sondern auch Beziehungen zwischen Beziehungen definiert werden. Dies wird im ProcessNavigator ausgenutzt, um neue spezifische Beziehungen zwischen Organisationen zu erstellen. In Abbildung 12-9 ist dargestellt, wie die Beziehung ISTVORGESETZTERVON neu erstellt wird. Diese Beziehung wird anschließend genutzt, um zu beschreiben, dass SCHMIDT der Vorgesetzte von MÜLLER ist. rdfs:property rdf:type

rdfs:subPropertyOf

org:relationship

org:istVorgesetzterVon

foaf:Person rdf:type

rdfs:domain

rdf:type

rdfs:range

foaf:Agent

org:schmidt

org:istVorgesetzterVon

org:müller

Abbildung 12-9: Erstellung spezifischer Beziehungen zwischen Organisationen

Zur Speicherung dieses Sachverhalts wird das abstrakte Konzept RELATIONSHIP als Erweiterung einer PROPERTY definiert. Sowohl Definitions- als auch Bildbereich ist der AGENT. Eine RELATIONSHIP ist somit eine abstrakte Beziehung zwischen zwei Agenten. Die neue Beziehung ISTVORGESETZTERVON wird als Spezialisierung der RELATIONSHIP in der Ontogie eingeführt. Diese neue Beziehung kann anschließend als Prädikat in allen Aussagen eingesetzt werden, sofern sowohl Subjekt als auch Objekt vom Typ AGENT sind. 12.2.3 Der Datenorientierte Aspekt im Speichersystem Ein weiterer für die Prozessausführung wichtiger Aspekt ist der Datenorientierte Aspekt. Er stellt die bei der Ausführung genutzten Dokumente und Artefakte bereit. Die Unterstützung einer flexiblen Ausführungsreihenfolge für Prozessschritte durch


199

den ProcessNavigator erfordert, dass der Datenorientierte Aspekt nicht fest an den Modellkern gebunden wird. Vielmehr muss die Datenstruktur so gestaltet sein, dass Arbeitsschritte auch gestartet werden können, wenn noch nicht alle vorgesehen Daten und Artefakte vorhanden sind (Abschnitt 9.1.4). In Abbildung 12-10 ist die Abbildung des Datenorientierten Aspekts in die Ontologie dargestellt. Die Darstellung zeigt, die Umsetzung eines Datenflusses zwischen zwei Arbeitsschritten. Im Schritt T1 wird das Dokument Dat1 erzeugt, welches das Eingangsdokument des Schrittes T2 ist. Wie bei der Abbildung des Kontrollflusses wird vom Konzept PROCESS zum Konzept DATA eine ausgehende (PRODUCES) und eine eingehende (CONSUMES) Flussbeziehung definiert. Das im Prozesstyp enthaltene Element DAT1 wird im Speichersystem als DAT1 vom Konzept DATA instanziiert. Im Prozesstyp wird der Datenfluss zwischen T1 und T2 durch die PRODUCES Beziehung zwischen PTYPE1 und DAT1 sowie als CONSUMES Beziehung zwischen PTYPE2 und DAT1 realisiert. T1

Dat1

T2 ipm:produces

Sprache M2

ipm:Process

ipm:Data ipm:consumes

rdf:type

rdf:type

rdf:type ipm:PType1

ipm:produces

Typ M1

ipm:Dat1

ipm:consumes ipm:PType2 rdf:type

rdf:type rdf:type

Instanz M0

task:T1

task:createdIn

project:ProjectX task:createdinProject

task:Doc1

org:Emp1 task:createdby

task:T2

Abbildung 12-10: Speicherung des Datenorientierten Aspekts in der Ontologie

Mit der Instanziierung des Projekttyps für die Ausführung (Ebene M0) werden die beiden Tasks T1 und T2 angelegt. Nachdem der Arbeitsschritt T1 durch einen Mitarbeiter aus der Worklist ausgewählt wurde und die Ansicht im ProcessNavigator von der Worklist auf den Desktop wechselt, werden von der Komponente Datenorientierter Aspekt im Speichersystem die einund ausgehenden Datenflüsse des Prozessschrittes abgerufen (Abbildung 12-2). Diese Abfrage wird auf der Ebene M1 (Typ) in der Ontologie durchgeführt. Als Ergebnis werden im PN-Desktop die im Prozesstyp definierten Datenflüsse angezeigt. Beim Speichern des erstellten Datums

200


(DAT1) im PN-Desktop wird in der Ontologie das Element DOC1 als Instanz des Datums DAT1 angelegt. Zusätzlich wird zwischen DOC1 und T1 eine CREATEDIN Beziehung definiert. Diese Beziehung ist unabhängig vom definierten Datenfluss im Prozesstyp und erlaubt es dem Mitarbeiter neue nicht im Prozesstyp vorgesehene Dokumente im ProcessNavigator abzuspeichern. Zusätzlich zur Verknüpfung mit dem Arbeitsschritt, in dem das Datum erstellt wurde, wird es auch mit dem Projekt (CREATEDINPROJECT) und mit seinem Ersteller (CREATEDBY) verbunden. Durch die Verknüpfung mit dem Projekt wird es möglich, einem Mitarbeiter in Arbeitsschritten ähnliche Dokumente anzubieten. Als ähnliche Dokumente werden in diesem Zusammenhang all jene Dokumente betrachtet, die im Prozessmodell den gleichen Dokumententyp besitzen. In Abschnitt 9.1.4 wurde beschrieben, dass Mitarbeiter Dokumente in Beziehung zu anderen Dokumenten setzen können („Review Dokument X“ ISTREVIEWVON „Dokument“). Dies wird erreicht indem, analog zum Organisatorischen Aspekt (Abbildung 12-9), die Erstellung spezifischer Beziehungen zwischen Dokumenten ermöglicht wird. In der Ontologie werden dazu eine Reihe an Beziehungstypen ( ISTREVIEWVON, ISTERGÄNZUNGZU, ISTABHÄNGIGVON etc.) angelegt, die durch den Mitarbeiter beim Anlegen der Dokumente im ProcessNavigator genutzt werden können.

13

Evaluation des ProcessNavigators

Der ProcessNavigator ist ein umfassendes System zur Unterstützung von Mitarbeitern in Entwicklungsprozessen und zur Umsetzung der Anforderungen eines QM-Systems. Mitarbeiter werden sowohl über die nächsten Schritte im Entwicklungsprozess als auch über kontextrelevante Dokumente und Methoden informiert. Mit der Evaluierung des ProcessNavigators soll sichergestellt werden, dass das entwickelte System für den Praxiseinsatz tauglich ist. Im Teil II der Arbeit wird der ProcessNavigator und die Umsetzung der QM-Standards im System beschrieben. In Kapitel 6 wird gezeigt, wie die einzelnen Anforderungen der QM-Standards durch das Prozessmanagementsystem umgesetzt werden. Allerdings wird damit keine Aussage darüber getroffen, inwieweit die Anforderungen zur Unterstützung der Mitarbeiter in den Projekten durch den ProcessNavigator abgedeckt werden. Diese Fragestellung soll in diesem Kapitel geklärt werden. Während der Entwicklung des ProcessNavigators im FORFLOW-Projekt sollte sichergestellt werden, dass dieser die Anforderungen der Anwender erfüllen kann. Diese Pilotierung und Evaluierung in einem realitätsnahen Umfeld war Aufgabe eines Teilprojekts im Forschungsverbund. Die dort erzielten Ergebnisse werden in [Sharafi 2009] vorgestellt. Da sie unabhängig von der Entwicklung des Prototyps durchgeführt wurden, erlauben sie eine objektive Aussage über die Wirkung des ProcessNavigators in Produktentwicklungsprozessen. Die Ergebnisse dieses Teilprojekts sollen an dieser Stelle zusammengefasst und vorgestellt werden. Die Evaluierung betrachtet dabei nur die Akzeptanz des Systems durch die Mitarbeiter; die Umsetzung der QMAnforderungen war nicht Teil dieser Evaluierung. Zur Pilotierung des ProcessNavigators wurden mehrere Workshops durchgeführt [Sharafi 2009]. Im Rahmen dieser Workshops wurden sowohl das Gesamtkonzept des ProcessNavigators als auch Teilaspekte des Systems den am FORFLOW-Projekt beteiligten Industriepartnern vorgestellt. Mit Hilfe von Fragebögen sollte evaluiert werden, wie sie das System und dessen Einsatz in Entwicklungsprojekten einschätzen. Den Teilnehmern wurden dabei Fragen wie die folgende gestellt: „Wie verändert sich die Durchlaufzeit des Produktentwicklungsprozesses durch den Einsatz des ProcessNavigators?“. Ziel war es einen möglichst umfassenden Überblick über das Potenzial des ProcessNavigators im betrieblichen Einsatz zu erlangen.

202

13 Evaluation des ProcessNavigators

Durchschnittswerte nach Einzelfragen

deutlich besser

1 1,5

besser

2 2,5

kein Unterschied

3 3,5

schlechter

2008 2009

4 4,5

deutlich schlechter

5

Abbildung 13-1: Auswertung der Fragebögen (Abbildung aus [Sharafi 2009])

In Abbildung 13-1 wird eine Auswertung des Fragebogens nach Einzelfragen gezeigt. Das Diagramm zeigt die Antworten der Workshop-Teilnehmer in den Jahren 2008 und 20097. Im Jahr 2008 nahmen an der Befragung 38 Mitarbeiter teil, im darauffolgenden Jahr 2009 noch 16 Mitarbeiter. Auf die gestellten Fragen konnten die Teilnehmer eine Antwort aus einer Skala von 1 (Situation hat sich deutlich verbessert) bis zu 5 (Situation hat sich deutlich verschlechtert) geben. Wurde die Zahl 3 angekreuzt, so bedeutet dies, dass sich durch den ProcessNavigator weder eine Verbesserung noch 7

Die Jahre 2008 und 2009 ergeben sich aus der Laufzeit des FORFLOW-Projekts vom 1.10.2006 bis zum 31.12.2009.


203

eine Verschlechterung der Situation ergeben hat. Die im Diagramm eingetragenen Werte ergeben sich aus dem Mittelwert der Antworten aller Fragebögen. Die Auswertung der Fragen ergab, dass der ProcessNavigator im Bezug auf die gestellten Fragen durchweg einen positiven Einfluss auf den Produktentwicklungsprozess bewirkt. So wird erwartet, dass durch den ProcessNavigator vor allem Vorteile im Controlling des Entwicklungsprozesses (Frage: „In welchem Umfang verändern sich durch den Einsatz des ProcessNavigators die Möglichkeiten, das Controlling der Meilensteine und Ressourcenverbräuche entlang des Produktionsentwicklungsprozesses zu steuern?“) und in der Orientierung im Prozess (Frage: „Wie beurteilen Sie die Unterstützung bei der Orientierung im Prozessablauf durch den ProcessNavigator?“) resultieren. In Abbildung 13-2 werden die auf diese Frage gegebenen Antworten detailliert dargestellt.

Wie beurteilen Sie die Unterstützung bei der Orientierung im Prozessablauf durch den Prozessnavigator?

13% deutlich verbessert 50% 37%

verbessert kein Unterschied

Anzahl der Teilnehmer: 16

Abbildung 13-2: Bewertung der Unterstützung durch den ProcessNavigator (Abbildung aus [Sharafi 2009])

Ein weiterer Punkt, der bei der Einführung des ProcessNavigators in Unternehmen eine wichtige Rolle spielt, sind die Produktentwicklungskosten (Frage: „In welchem Umfang verändern sich die Produktentwicklungskosten durch den Einsatz des ProcessNavigators?“). Auch hier erwartet eine Mehrheit der Teilnehmer, dass sich der ProcessNavigator positiv auf die Kosten einer Produktentwicklung auswirkt. In den Workshops hatten die Teilnehmer auch die Möglichkeit, direkt Feedback und Vorschläge für weitere Verbesserungen des ProcessNavigators zu äußern. So wird die Benutzeroberfläche des Systems positiv beurteilt. In den Workshops wird außerdem die Erwartung hervorgehoben, dass der ProcessNavigator die Transparenz der Entwicklungsprozesse steigert und dafür sorgen kann, dass keine Schritte im Entwick-

204


lungsprozess vergessen werden. Auch Potenziale für eine Weiterentwicklung des Systems wurden genannt. So wurde angemerkt, dass es notwendig ist, im ProcessNavigator mehrere Sprachen zu unterstützen. Außerdem sollte eine Versions- bzw. Revisionsverwaltung in das System integriert werden, um mehr Informationen über die Versionshistorie eines Dokuments abfragen zu können. Auch die Integration eines Backup-Konzepts in den ProcessNavigator wurde angeregt, so dass wichtige Daten gegen Löschen oder Überschreiben gesichert werden können. Ein Teil der im Feedback genannten Verbesserungsvorschläge wurden bereits umgesetzt. So wurde beispielsweise die Worklist im Verlauf des Projekts mehrmals überarbeitet, um die Übersichtlichkeit des Systems zu steigern. Andere Vorschläge wie beispielsweise die Versionsverwaltung oder ein Backup-System konnte im Rahmen des Forschungsprojekts nicht mehr implementiert werden. Die Umsetzung dieser Anforderungen stellt jedoch kein konzeptionelles Problem dar und sie können den ProcessNavigator sinnvoll ergänzen. Bei der Evaluierung des ProcessNavigators stand die Fragestellung im Mittelpunkt, wie das System durch die Anwender im Unternehmen akzeptiert wird, und ob es die Mitarbeiter bei der Bearbeitung von Entwicklungsprojekten unterstützen kann. Die Unterstützung der QM-Standards wurde dabei nicht betrachtet. Dies ist Beitrag dieser Arbeit und war nicht Gegenstand des Forschungsverbunds FORFLOW. Zusammenfassend kann festgestellt werden, dass das Konzept des ProcessNavigators durch die am FORFLOW-Projekt beteiligten Partnerunternehmen validiert werden konnte. Insbesondere konnten durch die positive Beurteilung der Punkte „Orientierung im Prozessablauf“ und „Controlling“ die zentralen Entwurfsziele des Systems realisiert werden. Der ProcessNavigator kann sowohl Mitarbeiter im Entwicklungsprozess unterstützen als auch die Transparenz des Prozesses für den Projektleiter erhöhen.

14

Zusammenfassung

Zu Beginn dieser Arbeit wurde der Fall der Trägerrakete Ariane 5 vorgestellt, die aufgrund eines Softwaredefekts gesprengt wurde. Als eine der wesentlichen Ursachen, welche zur Entstehung des Defekts und dem damit verbundenen Scheitern des Fluges geführt hatte, wurde ein mangelndes Prozess- bzw. Projektmanagement identifiziert. Um solchen Umständen zu begegnen werden verschiedene Ansätze zur Verbesserung der Unternehmensabläufe und zur Messung des Prozessreifegrads entwickelt. Drei dieser Ansätze, das V-Modell XT, das CMMI und die ISO/IEC 15504 werden dabei näher vorgestellt. Während das V-Modell XT ein Vorgehensmodell darstellt und damit eine Beschreibung liefert, wie Prozesse durchzuführen sind, bieten sowohl CMMI als auch ISO/IEC 15504 ein Referenzmodell, mit dem der Reifegrad von Prozessen gemessen werden kann. Die Umsetzung dieser Konzepte im Unternehmen ist aufwändig und die Mitarbeiter müssen in die Einführung und vor allem die Anwendung eingebunden werden. Ziel dieser Arbeit ist es daher ein Informationssystem zu entwickeln, welches dies durch die folgenden Eigenschaften erfüllt: x Unterstützung der Mitarbeiter im Prozess durch die zielgerichtete Bereitstellung von Informationen, x Unterstützung der Projektleiter durch ein transparentes Projektmanagement und x Umsetzung der in den QM-Standards genannten Anforderungen. In Kapitel 3 beginnt der Kern dieser Arbeit, indem die aus QM-Sicht zentralen Anforderungen an prozessbasiertes Informationssystem definiert werden. Dazu wird aus den beiden QM-Standards ein abstraktes QM-Anforderungsprofil (aQM2) rekonstruiert. Die beiden QM-Standards CMMI und ISO/IEC 15504 werden dazu miteinander verglichen und die wesentlichen Anforderungen identifiziert. Gleichzeitig wird das aQM2 in ein Meta-Modell für die Prozessmodellierung eingeordnet. Dadurch ergeben sich erste Hinweise darauf, wie die Anforderungen des aQM2 in einem Informationssystem umzusetzen sind. Mit dem aQM2 werden die Anforderungen an das Informationssystem aus Sicht der QM-Standards definiert. Die Anforderungen aus Sicht der Nutzer (Mitarbeiter und Projektleiter) werden im Kapitel 4 vorgestellt. Zentral ist hier die Forderung, dass das Informationssystem die Mitarbeiter bei der Arbeit im Projekt unterstützen muss. Das Informationssystem muss vor allem so gestaltet sein, dass es die Mitarbeiter nicht bei ihrer Arbeit einschränkt und flexibel auf die aktuelle Entwicklungssituation reagieren kann.

206

14 Zusammenfassung

In Teil II der Arbeit wird, basierend auf den vorher vorgestellten Anforderungen, der ProcessNavigator als prozessbasiertes Informationssystem zur Projektunterstützung entworfen. Dies beginnt mit der Beschreibung eines Vorgehensmodells zur QMUmsetzung, der an die Anforderungen von QM-Systemen angepasst wurde. Der bekannte Prozesslebenszyklus (Identifikation der Prozesse, Prozessdefinition, Ausführung und Controlling) wurde um die Phase Projektdefinition ergänzt. In dieser Phase wird das im Prozesstyp definierte Standardvorgehen in einen Projektplan unter Berücksichtigung von Tailoring-Richtlinien abgeleitet. Zusätzlich wurden die Phasen Prozessdefinition, Projektdefinition und Projektdurchführung in zwei Unterabschnitte, einem Erstellungsabschnitt und einem Validierungsabschnitt, aufgeteilt. Während der Validierung wird überprüft, ob die in der Phase erstellten Produkte bzw. Dokumente noch mit den Richtlinien des Unternehmens und den Anforderungen des QMStandards konform sind. Die Phasen des Vorgehensmodells zur QM-Umsetzung definieren auch die Struktur für die weiteren Kapitel in Teil II. Zur Modellierung der Prozesse wird der AOPM genutzt. Dieser erlaubt es einen Unternehmensablauf aus verschiedenen Perspektiven zu betrachten und in einem integrierten Modell abzubilden. Während der Modellierung können die Abläufe, entsprechend der Anforderungen des Unternehmens, erfasst werden. Im anschließenden Validierungsschritt wird eine sogenannte Gap-Analyse durchgeführt, mit der die Abweichungen des modellierten Prozesses von den Anforderungen bestimmt werden können. Diese Abweichungen können anschließend korrigiert werden. Somit liegt nach der Modellierung des Prozesses ein, an den Anforderungen des QMStandards validierter Prozesstyp vor. Dieser validierte Prozesstyp bildet die Grundlage für die Instanziierung des Prozesses in Projekten (Kapitel 8). In dem Kapitel wird zuerst ein Überblick über in der Literatur vorhandene Ansätze zum Tailoring von Projekten aus Prozessen vorgestellt. Aufbauend auf diesen wird ein Vorgehen zur Instanziierung des Prozesstyps vorgeschlagen. Ziel ist es, das im Prozesstyp definierte Standardvorgehen an die Erfordernisse des konkreten Projekts anzupassen. Dieses Tailoring kann eine Anpassung der Arbeitsschritte und des Kontrollflusses beinhalten; außerdem wird die Organisationsstruktur des Projekts festgelegt und die Aufgaben werden terminiert. Nach der Erstellung des Projekttyps wird dieser validiert, wie zuvor der Prozesstyp an den Anforderungen des QM-Standards. So kann sichergestellt werden, dass der Projekttyp und damit der Projektplan auch nach dem Tailoring noch die Anforderungen des QM-Standards erfüllt. In Kapitel 9 wird das Informationssystem zur Umsetzung von Produktentwicklungsprojekten vorgestellt. Das System basiert auf dem Ansatz klassischer Workflow-

14 Zusammenfassung

207

Management-Systeme, der Trennung in eine Worklist und in einen Anwendungsbereich (Desktop). Aus der Worklist können dabei jene Aufgaben ausgewählt werden, die bearbeitet werden sollen; im Anwendungsbereich werden anschließend Informationen, die den Mitarbeiter bei der Ausführung unterstützen können, angezeigt. Worklist und Desktop wurden so adaptiert, dass sie in Produktentwicklungsprojekten eingesetzt werden können. Das wichtigste Kriterium dabei war es, den Mitarbeiter bei der Projektbearbeitung zu unterstützen und ihn mit Informationen zu versorgen, ohne ihn durch eine strikte Prozessausführung einzuschränken bzw. zu bevormunden. Die wichtigste Änderung der Worklist im Vergleich zu klassischen WorkflowManagement-Systemen ist die Unterteilung in verschiedene Segmente. In der Arbeit wird eine Unterteilung in drei Segmente (Nächste Schritte, Entwicklungssituation, Gesamter Prozess) vorgeschlagen. Durch diese Kombination haben Mitarbeiter die Möglichkeiten eine beliebige Aufgabe aus dem Prozess zu wählen. Sie können damit im Prozess springen und die Aufgaben in einer anderen als der vorgegebenen Reihenfolge ausführen; auch abgeschlossene Aufgaben können erneut aufgerufen werden. Durch die unterschiedliche Auswahl an Aufgaben in den Segmenten ist jedoch immer auch die Navigation durch den Prozess gegeben. So können Mitarbeiter aus der Liste „Nächste Schritte“ immer die nächste im Projekttyp vorgesehene Aufgabe auswählen. Auch der Anwendungsbereich (Desktop) wurde an die Anforderungen von Produktentwicklungsprojekten angepasst. Der Mitarbeiter erhält Zugriff auf alle relevanten Informationen (Dokumente, Arbeitsanweisungen, Methoden etc.) und kann diese zur Umsetzung der Aufgabe nutzen. Auch hier hat der Nutzer wieder die Möglichkeit selbst zu entscheiden, wie er den Arbeitsschritt bearbeiten möchte. So kann der Schritt auch abgeschlossen werden, wenn noch nicht alle Dokumente erstellt wurden. Die Entscheidung, welcher Schritt bearbeitet wird und wie dieser umgesetzt wird, liegt immer beim Mitarbeiter. Zentrales Konzept des ProcessNavigators ist es, alle Aspekte so flexibel wie möglich umzusetzen und dem Ingenieur die maximale Freiheit bei der Umsetzung des Prozesses zu ermöglichen. Durch den ProcessNavigator wird sichergestellt, dass alle Aufgaben, die im Projekttyp vorgesehen sind ausgeführt werden und somit keine Anforderung der QM-Standards bei der Durchführung eines Entwicklungsprojektes ausgelassen oder vergessen werden. Während der Ausführung des Prozesses wird durch den ProcessNavigator automatisch ein Prozessprotokoll angelegt, in dem alle Schritte der Prozessausführung mitgeschrieben werden. Diese Information können in der Nachbereitung des Projekts (Kapitel 10) zur Identifizierung von Verbesserungsmöglichkeiten oder in QMAssessments genutzt werden. So werden Dokumente, die im Projekt erzeugt werden, automatisch mit den entsprechenden Anforderungen der QM-Standards (z.B. den ISO/IEC 15504 Work Products) verknüpft. Durch die im Ausführungsprotokoll

208

14 Zusammenfassung

vorhandenen Informationen ist das Unternehmen besser auf Assessments vorbereitet und der Reifegrad einer Prozessausführung kann besser bewertet werden, da zu allen Anforderungen direkt die Belege aus der Projektausführung gespeichert werden. Da in den Kapiteln 7 bis 10 nur gezeigt wird, wie die Anforderungen der Reifegradstufe 3 des aQM2 erfüllt werden können, ergänzt das Kapitel 11 das dort beschriebene Vorgehen um die Reifegradstufen 4 und 5. Dazu wird zuerst die Methode Six Sigma vorgestellt. Diese baut auf einem mathematisch statistischen Konzept auf und verfolgt das Ziel einer „virtuellen Null-Fehler Qualität“. Six Sigma beschreibt eine Reihe an Methoden und Werkzeugen, mit denen sich systematisch das Qualitätsniveau des Prozesses bestimmen und Prozessverbesserungsmaßnahmen ableiten lassen. Beides wird im aQM2 gefordert um die Reifegradstufen 4 und 5 bei der Prozessausführung zu erreichen. Somit ergänzt der Six Sigma Ansatz den ProcessNavigator und kann bei Auswertungen von den dort gesammelten Ausführungsinformationen profitieren. Die Architektur des ProcessNavigators wird in Kapitel 12 vorgestellt. Der ProcessNavigator wurde als Web-Anwendung in einer Schichten Architektur konzipiert. Diese besteht aus einer Speicherschicht, in der sowohl die für die Projektdurchführung notwendigen Modelle als auch das Ausführungsprotokoll gespeichert werden. Auf der Speicherschicht baut die Anwendungsschicht auf. Diese implementiert die Anwendungslogik des ProcessNavigators und stellt die Web-Seiten zur Auslieferung an die Darstellungsschicht im Web-Browser bereit. Zentrales Kriterium beim Entwurf der Speicherschicht war es, ein erweiterbares Datenmodell zu konzipieren. Ziel war es, die Änderbarkeit (Erweiterbarkeit) des Systems zu gewährleisten, falls neue Anforderungen von Anwendern oder QM-Seite an den ProcessNavigator gestellt werden. Zur Umsetzung wurde eine auf der Sprache OWL-basierte Datenstruktur und als Speichersystem ein RDF-Tripelstore gewählt. In Kapitel 13 werden schließlich die Ergebnisse der Pilotierung und Evaluierung des Systems vorgestellt. In Workshops und mit Fragebögen wurden verschiedene Industriepartner gefragt, ob das System im Entwicklungsprozess zur Verbesserung der Abläufe eingesetzt werden kann. Die Auswertung der Fragebögen ergab, dass der ProcessNavigator Mitarbeiter und Projektleiter bei der Bearbeitung der Projekte unterstützen kann. Somit konnte durch die am Projekt beteiligten Industriepartner der ProcessNavigator validiert und sein Nutzen bestätigt werden.

14 Zusammenfassung

209

Der Beitrag dieser Arbeit setzt sich somit aus den folgenden vier Kernpunkten zusammen: 1. Der Rekonstruktion eines abstrakten QM-Modells; 2. Der Entwicklung eines Vorgehensmodells zur Umsetzung von QM-Anforderungen; 3. Der Konzeption eines Informationssystems zu Umsetzung von QM-Anforderungen im Unternehmen; 4. Dem Entwurf einer Systemarchitektur zur Implementierung des Informationssystems. Alle vier Aspekte verfolgen das Ziel Anwender (Projektleiter, QM-Verantwortliche und Mitarbeiter) umfassend bei der Implementierung und Anwendung von QM-Standards zu unterstützen. Alle vier gehen von etablierten Methoden und Techniken aus, untersuchen, wie diese das Ziel „Implementierung eines QM-Systems“ unterstützen können, und wie diese erweitert werden müssen. Zur Rekonstruktion des abstrakten QM-Modells wurden zwei vorhandene Standards (die ISO/IEC 15504 und das CMMI) ausgewertet und die Kernforderungen in ein abstraktes QM-Modell generalisiert. Dieses neue Modell, das aQM2, bildet die Grundlage für die Entwicklung des Vorgehensmodells und die Konzeption des Informationssystems. Im Hinblick auf das Vorgehensmodell wurde ein vorhandener Prozesslebenszyklus so erweitert, dass er die Anforderungen der QM-Standards erfüllen kann; er wurde dazu um eine Phase zum Tailoring des Projekttypen aus dem Prozesstypen erweitert. Außerdem werden Prozess- und Projekttyp im Hinblick auf die Umsetzung der QM-Anforderungen validiert. Zur Unterstützung der Mitarbeiter in Projekten wurde ein Informationssystem konzipiert. Dieses nimmt vorhandene Workflow-Management-Systeme zu Vorbild und führt das neue Prinzip der flexiblen Prozessausführung ein. Dieses Ausführungsprinzip informiert den Anwender einerseits über anstehende Arbeitspakete im Projekt, andererseits stellt es aktiv umfangreiches Kontextwissen zur Verfügung und unterstützt damit die Anwender bei der Projektumsetzung. Für das Vorgehensmodell und das Informationssystem konnte gezeigt werden, dass sie die Anforderungen der QM-Standards und Anwender erfüllen. Durch die Implementierung der vorgestellten Systemarchitektur im Rahmen des FORFLOW-Projekts sowie die dort durchgeführte Evaluation konnte gezeigt werden, dass ein solches Prozessmanagementsystem auch im täglichen Unternehmenseinsatz eingesetzt werden kann. Die vorliegende Arbeit zeigt insbesondere detailliert auf, wie die Anforderungen von QM-Standards in einem Unternehmen durch ein Informationssystem unterstützt und

210

14 Zusammenfassung

umgesetzt werden können. Auch wenn dies sehr konkret an den beiden QMStandards ISO/IEC 15504 und CMMI und durch die Umsetzung im ProcessNavigator gezeigt wurde, können die vorgestellten Methoden dennoch auf andere QMStandards und Systeme übertragen und dort angewendet werden.

15

Ausblick

Das zentrale Ziel dieser Arbeit war die Konstruktion prozessbasierten Informationssystems zur Implementierung von QM-Standards, welches die Mitarbeiter umfassend bei der Bearbeitung von Produkt- bzw. Softwareentwicklungsprojekten unterstützt. Dazu wurden sowohl die Anforderungen aus QM-Sicht als auch die Anforderungen aus Sicht der Nutzer analysiert und eine Lösung basierend auf einem Prozesslebenszyklus vorgeschlagen. Als zentrales System wird in der Arbeit der ProcessNavigator vorgestellt, welches vorhandene Konzepte aus Workflow-Management-Systemen so adaptiert, dass sie in der Produktentwicklung angewandt werden können. Ergebnis ist ein flexibles Prozessmanagementsystem (der ProcessNavigator), welches den Mitarbeiter durch den Entwicklungsprozess führt, ohne ihn in seinen Handlungsmöglichkeiten einzuschränken. Über Nutzung des Prozessmanagementsystems zur Implementierung eines QMSystems hinaus können die Forschungsergebnisse weiter genutzt und neue Funktionen entwickelt werden. Dies beinhaltet sowohl die Erweiterung des ProcessNavigators mit neuen Funktionen als auch das Adaptieren des Systems an neue Domänen. Eine Auswahl dieser Erweiterungsmöglichkeiten wird hier kurz vorgestellt: x Integration externer Werkzeuge in den ProcessNavigator In Abschnitt 9.1.6 (Der Operationale Aspekt im ProcessNavigator) wurde gezeigt, dass der ProcessNavigator im Gegensatz zum klassischen WorkflowKonzept vor allem eine Informationsfunktion für den Mitarbeiter hat. Auf eine direkte Integration der Anwendungen in den ProcessNavigator, wie sie im klassischen Workflow-Konzept vorhanden ist, wurde verzichtet, da dies durch die unterschiedlichen Schnittstellen der einzelnen Anwendungen mit einem hohen Umsetzungsaufwand verbunden ist. Dennoch ist es sicherlich interessant, dem Entwickler ein integriertes System anzubieten, aus dem alle benötigten Anwendungen gestartet werden können. Hier bietet sich die Möglichkeit neue Techniken zur einfacheren Integration von Desktop-Anwendungen in WebAnwendungen zu entwickeln, die es über geeignete Integrationsschnittstellen erlauben die benutzten Werkzeuge direkt aus dem ProcessNavigator aufrufen. x Nutzung des Systems in anderen Domänen Der ProcessNavigator wurde vor allem im Umfeld von (Software-)Produktentwicklungsprozessen konzipiert und evaluiert. In [Meiler 2005] wird die Modellierung Klinischer Pfade vorgestellt. Durch die flexible Ausführung von Prozessen erscheint der ProcessNavigator auch für den Einsatz in klinischen An-

212

15 Ausblick

wendungsfällen geeignet. Ein möglicher Einsatz in diesem Anwendungsgebiet sollte weiter erforscht werden. x Einfachere Erzeugung neuer Konfigurationen des ProcessNavigators Die Anpassung des ProcessNavigators an andere Anwendungsumgebungen ist gegenwärtig noch aufwändig. Die notwendigen Anpassungsschritte müssen manuell konzipiert und implementiert werden. Dies könnte beispielsweise durch die Nutzung von Software-Factories [Greenfield et al. 2004] vereinfacht werden. So kann für den ProcessNavigator ein Baukasten an Softwaremodulen entwickelt werden, aus dem auf einfache Weise neue Konfigurationen des ProcessNavigators erzeugt werden können. x Nutzen weiterer Analysemethoden In Teil II wird vorgestellt, wie das Ausführungsprotokoll des ProcessNavigators genutzt werden kann, um die Qualität der Prozess zu verbessern. Hier werden vor allem die ISO/IEC 15504 und das CMMI als Grundlage für Verbesserungsmaßnahmen mittels einer Gap-Analyse genutzt. Die im Ausführungsprotokoll vorhandenen Daten können auch als Grundlage für weitere Analysen genutzt werden. So könnten etwa Data-Mining Techniken angewendet werden, um Unregelmäßigkeiten oder Besonderheiten bei der Prozessausführung aufzudecken. x Nutzung einer formalen Beschreibungssprache zur Festlegung der Freiheitsgrade in der Prozessausführung Im ProcessNavigator wurde eine sehr freie und flexible Form der Prozessausführung genutzt, um Mitarbeiter bei ihrer Arbeit zu unterstützen. Diese Art der Prozessausführung ist im Bereich der Entwicklungsprojekte gerechtfertigt. Für andere Bereiche kann es jedoch erforderlich sein, für die Prozessausführung mehr Restriktionen im Bezug auf die Ausführungsreihenfolge der Schritte zu definieren. Dies erfordert einerseits ein ausdruckstärkeres Prozessmodell in dem diese Restriktionen enthalten sind, andererseits muss auch das Auswertungsmodul im Ausführungssystem entsprechend angepasst werden. In [Jablonski et al. 2009b] wird dazu eine formale, logikbasierte Methode vorgestellt, die es erlaubt, die Ausführungsreihenfolge der Schritte feingranular festzulegen. Durch die Integration dieses Ansatzes in den ProcessNavigator kann die Ausführungsreihenfolge genau auf den Anwendungsfall abgestimmt werden. Die vorgestellten Erweiterungen betreffen vor allem Teilbereiche des Systems und die Handhabung durch den Nutzer. So zielt die Nutzung der formalen Modellierungssprache vor allem darauf ab, die Ausführungsreihenfolge noch genauer bestimmen zu

15 Ausblick

213

können. Für den Anwender hat dies den Vorteil, dass der ProcessNavigator genau auf seine Bedürfnisse abgestimmt werden kann. Ebenso soll es die bessere Einbindung des operationalen Aspekts dem Anwender ermöglichen, einfacher auf Anwendungen zuzugreifen und diese zu nutzen. Insgesamt kann festgestellt werden, dass der ProcessNavigator die an ihn gestellten Anforderungen gut erfüllt. Dies trifft insbesondere auf das Gesamtkonzept zu, welches auch in der Evaluation bestätigt wurde. Die Unterteilung des Systems in eine Worklist und in einen Anwendungsbereich (den PN-Desktop) ist geeignet, um Anwender in Entwicklungsprojekten sinnvoll zu unterstützen. Durch die Aufteilung der PN-Worklist in mehrere Segmente wurde erreicht, dass Anwender genügend Flexibilität im Projekt besitzen, um auch auf unvorhergesehene Situationen angemessen reagieren zu können. Die vorgestellten Erweiterungen widersprechen dem vorgestellten Konzept nicht, sondern verbessern und bestätigen es vielmehr.

Literaturverzeichnis [Alavi et Leidner 2001] Alavi, M. et Leidner, D. E. (2001). Review: Knowledge Management and Knowledge Management Systems: Conceptual Foundations and Research Issues. MIS Quarterly, 25 (1), 107-136. [Allemang et Hendler 2008] Allemang, D. et Hendler, J. A. (2008). Semantic Web for the Working Ontologist: Effective Modeling in RDFS and OWL. Morgan Kaufmann Publishers, San Francisco. [Apache Tomcat 2009] Apache Tomcat (2009). Apache Tomcat, http://tomcat.apache.org/ (abgerufen am: 10.11.2009). [Automotive SPICE© 2009] Automotive SPICE© (2009). The SPICE User Group, http://www.automotivespice.com/ (abgerufen am: 10.11.2009). [Bartelt et al. 2005] Bartelt, C., Ternité, T. et Zieger, M. (2005). Modellbasierte Entwicklung mit dem V-Modell XT. OBJEKTspektrum (05/2005). [Berners-Lee et al. 2001] Berners-Lee, T., Hendler, J. A. et Lassila, O. (2001). The Semantic Web. Scientific American, May 17 2001, 34-43. [Bézivin 2005] Bézivin, J. (2005). On the unification power of models. Software and Systems Modeling, 4 (2), 171-188. [Binder 1997] Binder, R. V. (1997). Can a Manufacturing Quality Model Work for Software? IEEE Software, 14 (5), 101-102. [Böhm 2000] Böhm, M. (2000). Entwicklung von Workflow-Typen. Springer Verlag, Berlin. [Brickley et Guha 2004] Brickley, D. et Guha, R. V. (2004). RDF Vocabulary Description Language 1.0: RDF Schema. World Wide Web Consortium (W3C), http://www.w3.org/TR/rdf-schema/ (abgerufen am: 10.11.2009).

216


[Broekstra et al. 2002 ] Broekstra, J., Kampman, A. et van Harmelen, F. (2002 ). Sesame: A Generic Architecture for Storing and Querying RDF and RDF Schema. In Proceedings of 1st International Semantic Web Conference (ISWC2002), Sardinia (Italy), 54-68. [Budlong et al. 1996] Budlong, F. C., Szulewski, P. A. et Ganska, R. J. (1996). Process tailoring for software project plans. Software Technology Support Center of the U.S. Air Force. [Bussler 1998] Bussler, C. (1998). Organisationsverwaltung in Workflow-ManagementSystemen. Deutscher Universitäts-Verlag. [Card 2000] Card, D. N. (2000). Sorting out Six Sigma and the CMM. IEEE Software, 17 (3), 11-13. [Clark et al. 2008] Clark, T., Sammut, P. et Willans, J. (2008). Applied Metamodeling. A Foundation for language driven development. Ceteva. [CMMI Product Team 2006] CMMI Product Team (2006). CMMI for Development, Version 1.2. Software Engineering Institute (SEI) (Hrsg.). [Cullot et al. 2003] Cullot, N., Parent, C., Spaccapietra, S. et Vangenot, C. (2003). Ontologies: A Contribution to the DL/DB Debate. In Proceedings of 1st International Workshop on the Semantic Web and Databases, 29th International Conf. on Very Large Data Bases, Berlin, Germany. [Date 2003] Date, C. J. (2003). Introduction to Database Systems. Addison-Wesley Longman, Amsterdam. [Deming 1986] Deming, W. E. (1986). Out of the Crisis. MIT Press, Cambridge (MA). [Dowson 1997] Dowson, M. (1997). The Ariane 5 software failure. SIGSOFT Software Engineering Notes, 22 (2), 84. [Elmasri et Navathe 2006] Elmasri, R. et Navathe, S. B. (2006). Fundamentals of Database Systems. Pearson Education, Boston.


217

[Essigkrug et Mey 2007] Essigkrug, A. et Mey, T. (2007). Rational Unified Process kompakt. Elsevier, Spektrum, Akademischer Verlag, München. [Faerber et al. 2009] Faerber, M., Meerkamm, S. et Jablonski, S. (2009). The ProcessNavigator - Flexible process execution for product development products. In Proceedings of International Conference on engineering design, ICED'09, Stanford, CA, USA. [Faerber et al. 2008] Faerber, M., Jochaud, F., Stöber, C., Jablonski, S. et Meerkamm, H. (2008). Knowledge oriented Process Design for DfX. In Proceedings of 10th International Design Conference, Dubrovnik, The Design Society. [Fitzgerald et al. 2003] Fitzgerald, B., Russo, N. L. et O'Kane, T. (2003). Software development method tailoring at Motorola. Communications of the ACM, 46 (4), 64 70. [FOAF 2009] FOAF (2009). The Friend of a Friend (FOAF) project, http://www.foafproject.org/ (abgerufen am: 10.11.2009). [Geiger 1987] Geiger, W. (1987). Grundlegende Betrachtungen zum Qualitätsbegriff. In: Qualitätssicherung im Spritzgießbetrieb, VDI-Verlag, Düsseldorf. [Georgakopoulos et al. 1995] Georgakopoulos, D., Hornick, M. et Sheth, A. (1995). An overview of workflow management: from process modeling to workflow automation infrastructure. Distributed and Parallel Databases, 3 (2), 119-153. [Ginsberg et Quinn 1995] Ginsberg, M. P. et Quinn, L. H. (1995). Process Tailoring and the Software Capability Maturity Model. Software Engineering Institute, Carnegie Mellon University, Pittsburgh. [Greenfield et al. 2004] Greenfield, J., Short, K., Cook, S. et Kent, S. (2004). Software Factories. Wiley & Sons, Hoboken (NJ). [Gresse von Wangenheim et Thiry 2005] Gresse von Wangenheim, C. et Thiry, M. (2005). Analyzing the Integration of ISO/IEC 15504 and CMMI-SE/SW. LQPS, UNIVALI, São José.

218


[Haase et al. 1994] Haase, V., Messnarz, R., Koch, G., Kugler, H. J. et Decrinis, P. (1994). Bootstrap: Fine-Tuning Process Assessment. IEEE Software, 11 (4), 25-35. [Handbuch iPM Integrated Process Manager 2005] Handbuch iPM Integrated Process Manager (2005). ProDatO Integration Technology GmbH, Erlangen, http://www.prodato.de. [Hansmann et al. 2005] Hansmann, H., Laske, M. et Luxem, R. (2005). Einführung der Prozesse Prozess-Roll-out. In: Prozessmanagement, Springer, Berlin, 269-298. [Henderson-Sellers et Gonzalez-Perez 2006] Henderson-Sellers, B. et Gonzalez-Perez, C. (2006). A powertype-based metamodelling framework. Software and Systems Modeling, 5 (1), 7290. [Henderson-Sellers et Gonzalez-Perez 2008] Henderson-Sellers, B. et Gonzalez-Perez, C. (2008). Metamodelling for Software Engineering. Wiley & Sons. [Hitzler et al. 2008] Hitzler, P., Krötzsch, M., Rudolph, S. et York, S. (2008). Semantic Web. Springer, Berlin Heidelberg. [Hoffmann 2008] Hoffmann, D. W. (2008). Software-Qualität. Springer, Berlin. [Hohler 1999] Hohler, B. (1999). Qualitätsmanagement der Software. In: Masing, W. (Hrsg.): Masing Handbuch Qualitätsmanagement, Hanser, München. [Höhn et Höppner 2008] Höhn, R. et Höppner, S. (2008). Das V-Modell XT. Springer, Berlin Heidelberg. [Hong et Goh 2003] Hong, G. Y. et Goh, T. N. (2003). Six Sigma in software quality. The TQM Magazine, 15 (6), 364 - 373. [Höppner et Lübben 2008] Höppner, S. et Lübben, N. (2008). AG-/AN-Schnittstelle - Schwerpunkt Ausschreibungen/Vertragswesen. In: Das V-Modell XT, Springer, Berlin, 173-274.


219

[Hörmann et al. 2006] Hörmann, K., Dittmann, L., Hindel, B. et Müller, M. (2006). SPICE in der Praxis. dpunkt.Verlag, Heidelberg. [IDS Scheer 2009] IDS Scheer (2009). ARIS Platform, http://www.ids-scheer.de/de/ARIS_ARIS_Platform/7796.html (abgerufen am: 10.11.2009). [ISO/IEC 12207:2008 2008] ISO/IEC 12207:2008 (2008). Systems and software engineering Software life cycle processes. International Organization for Standardization (Hrsg.). [ISO/IEC 15504-5:2006 2006] ISO/IEC 15504-5:2006 (2006). ISO/IEC 15504-5:2006: Information technology – Process assessment – Part 5: An exemplar Process Assessment Model. International Organization for Standardization (Hrsg.). [ISO/IEC 24744:2007 2007] ISO/IEC 24744:2007 (2007). ISO/IEC 24744:2007: Software Engineering Metamodel for Development Methodologies. International Organization for Standardization (Hrsg.). [Jablonski 1994] Jablonski, S. (1994). MOBILE: A Modular Workflow Model and Architecture. In Proceedings of 4th International Working Conference on Dynamic Modelling and Information Systems, Noordwijkerhout, NL. [Jablonski 2009] Jablonski, S. (2009). Process Modeling for Holistic Process Management. In: Cardoso, J. et van der Aalst, W. M. P. (Hrsg.): Handbook of Research on Business Process Modeling, Information Science Reference. [Jablonski et Bussler 1996] Jablonski, S. et Bussler, C. (1996). Workflow Management – Modeling Concepts, Architecture and Implementation. International Thomson Computer Press, London. [Jablonski et Faerber 2007] Jablonski, S. et Faerber, M. (2007). Integrated Management of Company Processes and Standard Processes: A Platform to Prepare and Perform Quality Management Appraisals. In Proceedings of 5th International Workshop on Software Quality, Minneapolis, IEEE Computer Society.

220


[Jablonski et Volz 2008] Jablonski, S. et Volz, B. (2008). Datenbankgestützte Implementierung höherer Metamodellierungskonzepte. Datenbank-Spektrum, 8 (24), 2432. [Jablonski et Meerkamm 2009] Jablonski, S. et Meerkamm, S. (2009). An Extended Interpretation of Process Design and Modelling. In Proceedings of 4th International Conference on Design Science Research in Information Systems and Technologies (DESRIST), Philadelphia (PA), USA. [Jablonski et Talib 2009] Jablonski, S. et Talib, R. (2009). Agent Assignment for Process Management: Pattern based Agent Performance Evaluation. In Proceedings of The Fourth International Workshop on Agents and Data Mining Interaction (ADMI-09), Budapest (Ungarn). [Jablonski et al. 2006] Jablonski, S., Faerber, M. et Schlundt, J. (2006). Bridging the gap between SPICE Reference Processes and OU Processes: An iterative business process modelling approach. In Proceedings of The six International SPICE Conference, Luxembourg. [Jablonski et al. 2008] Jablonski, S., Volz, B. et Dornstauder, S. (2008). A Meta Modeling Framework for Domain Specific Process Management. In Proceedings of 1st IEEE International Workshop on Semantics for Business Process Management, Turku, Finland. [Jablonski et al. 2009a] Jablonski, S., Volz, B. et Dornstauder, S. (2009a). Evolution of Business Process Models and Languages. In Proceedings of 2nd International Conference on Business Process and Services Computing (BPSC), Leipzig, Germany. [Jablonski et al. 2009b] Jablonski, S., Igler, M. et Guenther, C. (2009b). Supporting Collaborative Work through Flexible Process Execution. In Proceedings of Fifth International Conference on Collaborative Computing Washington D.C., USA. [Jablonski et al. 2009c] Jablonski, S., Volz, B. et Dornstauder, S. (2009c). On the Implementation of Tools for Domain Specific Process Modelling. In Proceedings of 4th International Conference on the Evaluation of Novel Approaches to Software Engineering (ENASE), Milan, Italy.


221

[Jablonski et al. 2007] Jablonski, S., Faerber, M., Kastner, N. et Metzger, A. (2007). IPM4QM – Eine integrierte Modellierung von Unternehmensprozessen und Anforderungen aus SPICE. In Proceedings of SQS Software & Systems Quality Conferences, Düsseldorf. [JavaBeans 2009] JavaBeans (2009). Java Beans: Introducing Java Beans, http://java.sun.com/developer/onlineTraining/Beans/Beans1/ (abgerufen am: 10.11.2009). [JSF 2009] JSF (2009). JavaServer Faces Technology. Sun Microsystems, http://java.sun.com/javaee/javaserverfaces/ (abgerufen am: 10.11.2009). [JSP 2009] JSP (2009). JavaServer Pages Technology. Sun Microsystems, http://java.sun.com/products/jsp/ (abgerufen am: 10.11.2009). [Kaplan et Norton 1996] Kaplan, R. S. et Norton, D. P. (1996). Using the Balanced Scorecard as a Strategic Management System. Harvard Business Review (JanuaryFebruary 1996). [Kerzner 2006] Kerzner, H. (2006). Project management: a systems approach to planning, scheduling and controling. John Wiley & Sons, Hoboken, New Jersey. [Kneuper 2006] Kneuper, R. (2006). CMMI. dpunkt.Verlag, Heidelberg. [Kroslid et al. 2003] Kroslid, D., Faber, K., Magnusson, K. et Bergman, B. (2003). Six Sigma. Hanser Fachbuch, München. [Kuster et al. 2008] Kuster, J., Huber, E., Lippmann, R., Schmid, A., Schneider, E., Witschi, U. et Wüst, R. (2008). Handbuch Projektmanagement. Springer, Berlin Heidelberg. [Lakomek et al. 2007] Lakomek, H. J., Hülsemann, J. L., Küttner, T., Buscham, K. et Roeder, N. (2007). Klinische Behandlungspfade in der akut-stationären Rheumatologie – ein strukturiertes Prozessmanagement. Zeitschrift für Rheumatologie, 66 (3), 247-254.

222


[Le Lann 1996] Le Lann, G. (1996). The Ariane 5 Flight 501 Failure - A Case Study in System Engineering for Computing Systems. INRIA. [Mann 2004] Mann, K. D. (2004). JavaServer Faces in Action. Manning Publications Co., Greenwich. [Meerkamm 2007] Meerkamm, H. (2007). Prozesse: eine aktuelle Herausforderungen in der Produktentwicklung. Konstruktion, 9, 1. [Meerkamm et Paetzold 2008] Meerkamm, H. et Paetzold, K. (2008). 2. Ergebnisbericht FORFLOW 2008, Erlangen. [Meiler 2005] Meiler, C. (2005). Modellierung, Planung und Ausführung Klinischer Pfade. ibidem Verlag. [Murugappan et Keeni 2003] Murugappan, M. et Keeni, G. (2003). Blending CMM and Six Sigma to Meet Business Goals. IEEE Software, 20 (2), 42-48. [Nonaka et Takeuchi 1995] Nonaka, I. et Takeuchi, H. (1995). The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation. Oxford University Press. [Nuseibeh 1997] Nuseibeh, B. (1997). Ariane 5: Who Dunnit? IEEE Software, 14 (3), 15-16. [Odell 1998] Odell, J. (1998). Advanced Object-Oriented Analysis and Design Using UML. Cambridge University Press, New York, NY. [Pedreira et al. 2007] Pedreira, O., Piattini, M., Luaces, M. R. et Brisaboa, N. R. (2007). A systematic review of software process tailoring. SIGSOFT Software Engineering Notes, 32 (3), 1-6. [Prud'hommeaux et Seaborne 2008] Prud'hommeaux, E. et Seaborne, A. (2008). SPARQL Query Language for RDF. W3C.


223

[RDF 2009] RDF (2009). Resource Description Framework (RDF). World Wide Web Consortium (W3C), http://www.w3.org/RDF/ (abgerufen am: 10.11.2009). [RDFS 2009] RDFS (2009). RDF Vocabulary Description Language 1.0: RDF Schema. World Wide Web Consortium (W3C), http://www.w3.org/TR/rdfschema/. [Reith 2000] Reith, M. (2000). Das 3i-Progamm der Siemens AG: Kulturwandel und Ideenmanagement. In Materialien aus dem Institut für empirische Soziologie Nürnberg, Ifes (Universität Erlangen), Nürnberg. [Roeder et al. 2003] Roeder, N., Hensen, P., Hindle, D., Loskamp, N. et Lakomek, H. J. (2003). Instrumente zur Behandlungsoptimierung. Der Chirurg, 74 (12), 11491155. [Rout et Tuffley 2007] Rout, T. P. et Tuffley, A. (2007). Harmonizing ISO/IEC 15504 and CMMI. Software Process: Improvement and Practice, 12 (4), 361-371. [RUP 2009] RUP (2009). IBM Rational Unified Process (RUP). IBM, http://www01.ibm.com/software/awdtools/rup/ (abgerufen am: 10.11.2009). [SCAMPI Upgrade Team 2006] SCAMPI Upgrade Team (2006). Standard CMMI Appraisal Method for Process Improvement (SCAMPI) A, Version 1.2: Method Definition Document. Software Engineering Institute (SEI) (Hrsg.). [Schach 2007] Schach, S. R. (2007). Object-Oriented and Classical Software Engineering. McGraw-Hill, New York. [Scheer 2000] Scheer, A.-W. (2000). ARIS - Business Process Modeling. Springer, Berlin. [Schmelzer et Sesselmann 2008] Schmelzer, H. J. et Sesselmann, W. (2008). Geschäftsprozessmanagement in der Praxis. Hanser, München.

224


[Schonenberg et al. 2008] Schonenberg, H., Mans, R., Russell, N., Mulyar, N. et van der Aalst, W. M. P. (2008). Process Flexibility: A Survey of Contemporary Approaches. In: Advances in Enterprise Engineering I, 16-30. [Seidewitz 2003] Seidewitz, E. (2003). What Models Mean. IEEE Software, 20 (5), 26-32. [Sesselmann 2008] Sesselmann, T. (2008). Entwurf und Ausarbeitung einer ontologiebasierten Datenstruktur für die flexible Ausführung von Prozessen in der Produktentwicklung. Zulassungsarbeit am Lehrstuhl für Angewandte Informatik IV - Datenbanken und Informationssysteme, Universität Bayreuth, Bayreuth. [Sharafi 2009] Sharafi, A. (2009). Pilotierung und Evaluation des FORFLOW-Prozessnavigators. In: Meerkamm, H., Henrich, A., Jablonski, S., Krcmar, H., Lindemann, U. et Rieg, F. (Hrsg.): Prozesse - Daten - Navigation. Bayerischer Forschungsverbund FORFLOW für Prozess-und Workflowunterstützung zur Planung und Steuerung der der Abläufe in der Produktentwicklung. Abschlussbericht 01.10.2006 - 30.09.2009, Shaker Verlag. [Siviy et al. 2005] Siviy, J., Penn, M. L. et Harper, E. (2005). Relationships Between CMMI® and Six Sigma. Software Engineering Institute, Carnegie Mellon University. [Sommerville 2006] Sommerville, I. (2006). Software Engineering 8. Addison-Wesley Longman, Amsterdam. [Thomas et McGarry 1994] Thomas, M. et McGarry, F. (1994). Top-Down vs. Bottom-Up Process Improvement. IEEE Software, 11 (4), 12-13. [Töpfer 2004] Töpfer, A. (2004). Six Sigma - Konzeption und Erfolgsbeispiele für praktizierte Null-Fehler-Qualität. Springer, Berlin. [Toutenburg et Knöfel 2009] Toutenburg, H. et Knöfel, P. (2009). Six Sigma - Methoden und Statistik für die Praxis. Springer, Berlin.


225

[Troll et al. 2008] Troll, A., Zapf, J., Faerber, M. et Jochaud, F. (2008). Prozessorientierung beim CAD-Datentausch. In CAD-CAM-Report, Hoppenstedt-Publishing GmbH, Darmstadt. [V-Modell XT (Version 1.3) 2008] V-Modell XT (Version 1.3) (2008). Der Beauftragte der Bundesregierung für Informationstechnik (Hrsg.), http://www.cio.bund.de/DE/ITMethoden/V-Modell_XT/v-modell_xt_node.html, (abgerufen am: 10.11.2009). [V-Modell XT Projektassistent 2006] V-Modell XT Projektassistent (2006). http://v-mdell.iabg.de/index.php?option=com_content&task=view& id=27& Itemid=51. [van der Aalst et Jablonski 2000] van der Aalst, W. M. P. et Jablonski, S. (2000). Dealing with workflow change: identification of issues and solutions. International Journal of Computer Systems Science and Engineering, 15 (5), 267-276. [van der Aalst et al. 2003] van der Aalst, W. M. P., ter Hofstede, A. H. M., Kiepuszewski, B. et Barros, A. P. (2003). Workflow Patterns. Distributed and Parallel Databases, 14 (1), 5-51. [van Harmelen et McGuinness 2009] van Harmelen, F. et McGuinness, D. L. (2009). OWL Web Ontology Language Overview, , http://www.w3.org/TR/owl-features/ (abgerufen am: 10.11.2009). [W3C 2009] W3C (2009). World Wide Web Consortium (W3C), http://www.w3.org/ (abgerufen am: 10.11.2009). [Wagner et Käfer 2008] Wagner, K. W. et Käfer, R. (2008). PQM - Prozessorientiertes Qualitätsmanagement. Hanser, München. [WSBPEL 2007] WSBPEL (2007). Web Services Business Process Execution Language Version 2.0. OASIS, http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpelv2.0-OS.html (abgerufen am: 15.01.2010).

226


[Zeising 2009] Zeising, M. (2009). Organisationsverwaltung in Prozessmanagementsystemen. Bachelor Thesis am Lehrstuhl für Angewandte Informatik IV - Datenbanken und Informationssysteme, Universität Bayreuth, Bayreuth. [Zimmermann et al. 2005] Zimmermann, J., Stark, C. et Rieck, J. (2005). Projektplanung: Modelle, Methoden, Management. Springer, Berlin. [zur Muehlen et Rosemann 2000] zur Muehlen, M. et Rosemann, M. (2000). Workflow-Based Process Monitoring and Controlling - Technical and Organizational Issues. In Proceedings of 33rd Hawaii International Conference on System Sciences, Maui, Hawaii.

Prozessorientierten Qualitatsmanagementsystemen: Konzept zur Implementierung

Automotive Embedded Systeme: Effizfientes Framework - Vom Design zur Implementierung

Unternehmenskodizes. Typen und Normierungsstrategien zur Implementierung einer Unternehmensethik

Downsizing bei Verbrennungsmotoren: Ein wirkungsvolles Konzept zur Kraftstoffverbrauchssenkung (VDI-Buch)

Managementprozesse und Performance: Ein Konzept zur reifegradbezogenen Verbesserung des Managementhandelns

Das Harvard - Konzept

Implementierung von Wettbewerbsstrategien German

Das Konzept der Metakompetenz

Joomla!-Templates: Design und Implementierung

Geschaftsprozesse realisieren: Ein praxisorientierter Leitfaden von der Strategie bis zur Implementierung

Das Gruppendelphi: Konzept und Fragebogenkonstruktion

Rechtsfragen der Implementierung des Vertrags von Lissabon

Implementierung und Optimierung impliziter iterativer Losungsalgorithmen zur Simulation kompiexer Stromungen in Turbomaschinen

Whistle-Blowing-Systeme in deutschen Unternehmen: Eine Untersuchung zur Wahrnehmung und Implementierung

MIIP: Modell zur Implementierung der IT-Prozesse: Konkrete Prozessbeschreibung und pragmatische Umsetzung IT-Prozessen

Telefonbefragungen uber das Mobilfunknetz: Konzept, Design und Umsetzung einer Strategie zur Datenerhebung

Konzept zur rechnergestützten Integration von Produktions- und Gebäudeplanung in der Fabrikgestaltung

Ideal und Konzept des Grundeinkommens: Zur Struktur einer über sich selbst hinausweisenden Idee

Der Helixaktor - Zum Konzept eines vorverwundenen Biegeaktors

Konzept zur Analyse der Lokomotion auf dem Laufband bei inkompletter Querschnittlahmung mit Verfahren der nichtlinearen German

Konzept zur Entwicklung integrierter Beratung: Integration systemischer Elemente in die klassische Beratung

Mobile Datenbanksysteme: Architektur, Implementierung, Konzepte (Xpert.press)

'IT Governance - Leitfaden für eine praxisgerechte Implementierung

Programmiersprachen - Konzepte, Strukturen und Implementierung in Java

Programmiersprachen - Konzepte, Strukturen und Implementierung in Java

Allianzfähigkeit von Unternehmen: Konzept und Fallstudie

Vermarktung hybrider Leistungsbündel: Das ServPay-Konzept

Mass Customization. Ein wettbewerbsstrategisches Konzept im Informationszeitalter

Interne Markenführung: Theoretisches Konzept und fallstudienbasierte Evidenz

Das Harvard-Konzept. Das Standardwerk der Verhandlungstechnik

Entscheidungszufriedenheit. Grundidee, theoretisches Konzept und empirische Befunde

Prozessorientierten Qualitatsmanagementsystemen: Konzept zur Implementierung

Automotive Embedded Systeme: Effizfientes Framework - Vom Design zur Implementierung

Unternehmenskodizes. Typen und Normierungsstrategien zur Implementierung einer Unternehmensethik

Downsizing bei Verbrennungsmotoren: Ein wirkungsvolles Konzept zur Kraftstoffverbrauchssenkung (VDI-Buch)

Managementprozesse und Performance: Ein Konzept zur reifegradbezogenen Verbesserung des Managementhandelns

Das Harvard - Konzept

Implementierung von Wettbewerbsstrategien German

Das Konzept der Metakompetenz

Joomla!-Templates: Design und Implementierung

Geschaftsprozesse realisieren: Ein praxisorientierter Leitfaden von der Strategie bis zur Implementierung

Das Gruppendelphi: Konzept und Fragebogenkonstruktion

Rechtsfragen der Implementierung des Vertrags von Lissabon

Implementierung und Optimierung impliziter iterativer Losungsalgorithmen zur Simulation kompiexer Stromungen in Turbomaschinen

Whistle-Blowing-Systeme in deutschen Unternehmen: Eine Untersuchung zur Wahrnehmung und Implementierung

MIIP: Modell zur Implementierung der IT-Prozesse: Konkrete Prozessbeschreibung und pragmatische Umsetzung IT-Prozessen

Telefonbefragungen uber das Mobilfunknetz: Konzept, Design und Umsetzung einer Strategie zur Datenerhebung

Konzept zur rechnergestützten Integration von Produktions- und Gebäudeplanung in der Fabrikgestaltung

Ideal und Konzept des Grundeinkommens: Zur Struktur einer über sich selbst hinausweisenden Idee

Der Helixaktor - Zum Konzept eines vorverwundenen Biegeaktors

Konzept zur Analyse der Lokomotion auf dem Laufband bei inkompletter Querschnittlahmung mit Verfahren der nichtlinearen German

Konzept zur Entwicklung integrierter Beratung: Integration systemischer Elemente in die klassische Beratung

Mobile Datenbanksysteme: Architektur, Implementierung, Konzepte (Xpert.press)

'IT Governance - Leitfaden für eine praxisgerechte Implementierung

Programmiersprachen - Konzepte, Strukturen und Implementierung in Java

Programmiersprachen - Konzepte, Strukturen und Implementierung in Java

Allianzfähigkeit von Unternehmen: Konzept und Fallstudie

Vermarktung hybrider Leistungsbündel: Das ServPay-Konzept

Mass Customization. Ein wettbewerbsstrategisches Konzept im Informationszeitalter

Interne Markenführung: Theoretisches Konzept und fallstudienbasierte Evidenz

Das Harvard-Konzept. Das Standardwerk der Verhandlungstechnik

Entscheidungszufriedenheit. Grundidee, theoretisches Konzept und empirische Befunde

Recommend Documents