Prozessorientierten Qualitatsmanagementsystemen: Konzept zur Implementierung

Matthias Faerber

Prozessorientiertes Qualitätsmanagement

GABLER RESEARCH

Matthias Faerber

Prozessorientiertes Qualitätsmanagement Ein Konzept zur Implementierung

Mit einem Geleitwort von Prof. Dr.-Ing. Stefan Jablonski

RESEARCH

Bibliografi sche Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der

Deutschen Nationalbibliografi e; detaillierte bibliografi sche Daten sind im Internet über

<http://dnb.d-nb.de> abrufbar.

Dissertation Universität Bayreuth, 2010

1. Aufl age 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, Mikroverfi lmungen und die Einspei-

cherung 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 Zerti-fizierung unterziehen, welche die qualitativ angemessene Umsetzung ihrer Unter-nehmensprozesse 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 Dissertati-on an. Am Beispiel der Entwicklung von Softwareprodukten zeigt er, wie Prozesse in einem Unternehmen gemäß einem definierten Qualitätsmanagementkonzept imple-mentiert werden können, wobei die Implementierung so gestaltet ist, dass Prozess-ausführungen direkt als nachweisbarer Beleg eines etablierten Qualitätsmanage-mentkonzepts herangezogen werden können. Somit stellen sich zwei Vorteile ein: die Umsetzung eines Qualitätsmanagementkonzepts im Unternehmen und die automati-sche Erstellung von Belegen der Umsetzung dieses Konzepts.

Viele Abhandlungen über Qualitätsmanagementsysteme diskutieren lediglich allge-mein über die zu erreichenden Ziele beziehungsweise die einzuleitenden Maßnah-men; nur selten werden konkrete Handlungsanweisungen zur Umsetzung von Qua-litä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 Me-thode 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 Dis-sertation anschaulich an Beispielen belegt, welche Herr Dr. Faerber während seiner Zeit am Lehrstuhl für Angewandte Informatik IV (Datenbanken und Informationssys-teme) 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 verant-wortlich 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 entwi-ckeln, 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 Projektar-beit 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 akzep-tiert 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. Produktentwicklungs-prozesse 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 Produktentwicklungs-prozessen 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ätsmanagement-standards 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 Produktentwicklungspro-zesse 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 Heran-gehensweise, 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 Prozess-managementsystem 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öglich-te ein erfolgreiches Arbeiten und Forschen in den Projekten. Dank gilt auch den Studenten, die mit verschiedenen Arbeiten einen wichtigen Beitrag zur Implementie-rung 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 Implementie-rung 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 alleinste-hendes 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ätsmanage-mentanforderungen genutzt. Das Ziel dieses Systems ist es, die Transparenz von Pro-jekten für Mitarbeiter zu erhöhen, Mitarbeiter und Projektleiter bei ihrer täglichen Arbeit zu unterstützen und die Umsetzung der Anforderungen von Qualitätsmana-gementstandards sicherzustellen.

Diese Arbeit ist in drei Teile untergliedert: Anforderungsanalyse, Entwurf des Infor-mationssystems 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 Anforderungsmo-dell rekonstruiert. Aus Nutzersicht wurde die flexible Prozessausführung als Kernan-forderung 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 Pro-zesstypen werden in der zweiten Phase, vor dem Start eines Projekts, an dessen spezifische Vorgaben, mittels Tailoring Regeln, angepasst. Der in dieser Phase ent-standene 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 unter-stü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 ver-schiedenen 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 transpa-rency, 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 identi-fied 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 manage-ment principles can be adapted to flexibly support developers in software develop-ment 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 ex-plained 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 Anforderungen an ein Qualitätsmanagementsystem 1

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

2 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

3 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

4 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

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

5 Entwurf eines Vorgehensmodells zur Umsetzung von QM-Anforderungen ...................................................................................... 79

5.1 Einfacher Prozesslebenszyklus 79

5.2 Ein Vorgehensmodell zur Umsetzung von QM-Anforderungen 81

XIV Inhaltsverzeichnis

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

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

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 QM-Anforderungen im Prozesstyp 99

8 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 QM-Anforderungen im Projekttyp 122

9 Projektdurchführung ............................................................................ 125

9.1 Phase 4.1: Unterstützung bei der Projektbearbeitung 125

9.2 Phase 4.2: Projektmonitoring und Umsetzung der QM-Vorgaben 157

10 Nachbereitung der Projektdurchführung............................................... 165

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

10.2 QM-Assessment 169

11 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 QM-Vorgaben 179

Teil III Umsetzung und Schlussfolgerungen 185

12 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 [V-Modell 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 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 QM-Anforderungen ............................................................................... 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 QM-Referenzmodell ............................................................................ 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 6-1: Umsetzung der Anforderungen des aQM2 RG1 ............................. 85





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 10-1: Umsetzung der QM-Anforderungen durch Verbesserungsmaßnahmen auf RG3............................................ 169

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

Tabelle 11-2: Zuordnung der Six Sigma Phasen zu den aQM2 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 hochwerti-ge Software zu entwickeln, ist also unbestritten.

Das Beispiel der europäischen Trägerrakete Ariane 5 zeigt, wie komplex und facetten-reich 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 Steuerungssoft-ware eine 64-bit Gleitkommazahl in eine vorzeichenbehaftete 16-bit Ganzzahl umgewandelt werden musste. Folge dieses Konvertierungsfehlers war eine Abwei-chung 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 Software-systems systematisch sichergestellt werden, dass bestimmte an sie gestellte Anforde-rungen erfüllt werden. Die Erfüllung bestimmter Forderungen und die Fehlerfreiheit eines Produkts sollen sich nicht zufällig ergeben, sondern das Resultat eines systema-tischen 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, festge-setzte 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 immateri-elles Produkt; sie zeichnet sich unter anderem durch folgende besondere Eigenschaf-ten aus [Hohler 1999]:

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

� 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 ge-planten Zielgrößen nicht anwendbar. Software ist wegen seiner binären Dar-stellung 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)


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 sprung-hafte Verhalten kann schon ein einziger Fehler (wie im Beispiel die fehlerhalte Konvertierung der Gleitkommazahl) zu katastrophalen Ergebnissen führen.

� 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 Zu-stä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ährleis-ten.

In der Norm ISO/IEC 9126 werden die Qualitätsmerkmale für Software definiert:

� Funktionalität: Vorhandensein von Funktionen mit festgelegten Eigenschaften. Diese Funktionen erfüllen die definierten Anforderungen.

� Zuverlässigkeit: Fähigkeit der Software ihr Leistungsniveau unter festgelegten Bedingungen über einen festgelegten Zeitraum zu bewahren.

� Benutzbarkeit: Aufwand, der zur Benutzung erforderlich ist und individuelle Beurteilung der Benutzung durch eine festgelegte oder vorausgesetzte Benut-zergruppe.

� Effizienz: Verhältnis zwischen dem Leistungsniveau der Software und dem Umfang der eingesetzten Betriebsmittel unter festgelegten Bedingungen.

� Änderbarkeit: Aufwand, der zur Durchführung vorgegebener Änderungen notwendig ist. Änderungen können Korrekturen, Verbesserungen oder Anpas-sungen an Änderungen der Umgebung, der Anforderungen und der funktiona-len Spezifikationen einschließen.

� Übertragbarkeit: Eignung der Software, von einer Umgebung in eine andere übertragen zu werden. Umgebung kann organisatorische Umgebung, Hard-ware- 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


auf eine spätere Änderbarkeit und Anpassbarkeit des Systems an neue Anforderun-gen abzielen.

Grundsätzlich kann zwischen zwei Ansätzen zur Sicherung der Qualität in Software-produkten unterschieden werden [Hohler 1999]:

� die Beurteilung der Qualität der Endprodukte und

� 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 Über-tragbarkeit.

Die Absicherung des Entwicklungsprozesses greift weiter als der Test der Endproduk-te. Durch den prozessorientierten Ansatz können alle Facetten der Softwareentwick-lung (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 Prozess-management-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 Prod-uct 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 Leistungs-fä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


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 Entwick-lung von Software genutzt werden kann. Ziel von Vorgehensmodellen ist es, be-stimmte 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 V-Modell 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


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

Abbildung 1-1: 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 unter-nehmensinterne 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-

Unt

erne

hmen

sint

erne

Kon

zept

e un

d Sy

stem

eEx

tern

e A

nfor

deru

ngen

und

Vorg

aben

Prozessschritt Projektschritt

Vorgehensmodell

besc

hrei

bt

Sta

ndar

d-vo

rgeh

en

beschreibt Standardvorgehen

definiert Anforderungen

QM-Standard

Projekt

steuert Lebenszyklus

Prozesslebenszyklus

Prozesslandschaft

(Unternehmens-)Prozess

(Unternehmens-)Prozess

(Unternehmens-)Prozesse


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äts-managements 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.

Abbildung 1-2: Beziehungen zwischen Software-Entwicklungsprozessen und QM-Standards

1.2 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 QM-System seine Wirkung im Hinblick auf die strategischen Ziele des Unternehmens entfalten und das Ziel, die Zertifizierung eines Unternehmens nach dem ausgewähl-ten QM-Standard, unterstützen. Hier stellen sich für Unternehmen zwei wesentliche Herausforderungen:

� 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

QualitätsmanagementSoftware-Entwicklungsprozesse

ISO/IEC 15504-5

Anwendung

ISO/IEC 12207(Prozess-

dimension)

ISO/IEC 15504-2(Reifegrad-dimension)

erfüllt Vorgaben

V-Modell XT ISO 9001

QM-Vorgehens-modell

CMMI Six Sigma

Software-Vorgehens-

modellQM-Standard


die gesuchten Informationen zu gelangen. Das Problem besteht weniger in ei-nem Fehlen der Informationen, als vielmehr in einem Überfluss an Informatio-nen, die besser gemanagt werden müssen.

� Prozessausführung und Umsetzung der QM-Standards muss nachvollziehbar sein Sowohl die ISO/IEC 15504 als auch das CMMI sind sehr umfangreich und de-tailliert im Hinblick auf die gestellten Anforderungen. In einem Assessment muss die korrekte Umsetzung der Vorgaben durch den Assessor nachvollzieh-bar 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 Prob-lemen 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 Projektlei-ter 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 Unternehmensumgebun-gen einfach anpassen lässt. Aus diesen Forderungen ergeben sich die folgenden Eckpunkte dieser Arbeit:

� Rekonstruktion eines abstrakten QM-Modells Den Ausgangspunkt zur Entwicklung eines Konzepts zur Umsetzung von QM-Systemen bildet die Definition eines abstrakten QM-Modells (aQM2). Die bei-den QM-Standards ISO/IEC 15504 und CMMI definieren eine Reihe an Forde-rungen, die in einem Softwareentwicklungsprozess umgesetzt werden müssen. Das aQM2 ist eine Generalisierung beider Standards und legt ein Anforde-rungsgerü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 gemeinsa-men Modell rekonstruiert. Das aQM2 bleibt jedoch abstrakt, da es im Unter-schied zu den beiden QM-Standards ISO/IEC 15504 und CMMI keine konkreten Vorgaben definiert sondern nur die zentralen Konzepte festlegt.


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 implemen-tiert werden kann. Durch die Rekonstruktion des abstrakten QM-Anfor-derungsmodells 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.

� 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 Lebenszyk-lus beginnt mit dem Entwurf eines Prozesses und beschreibt dessen Nutzung und Verbesserung zum Erreichen der strategischen Unternehmensziele. In die-ser Arbeit wird ausgehend von einem Lebenszyklusmodell für Prozesse ein neues, erweitertes Modell entwickelt, welches insbesondere die Anforderun-gen 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.

� 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 Soft-wareentwicklungsprozessen konzipiert, welches einerseits die Mitarbeiter durch den Prozess leitet und andererseits die Anforderungen eines QM-Systems umsetzt. Im Bezug auf die Anwenderunterstützung wird das Konzept der flexiblen Prozessausführung entwickelt. Dieses adaptiert bestehende Kon-zepte aus Workflow- und Prozessmanagementsystemen so, dass die Anwen-der durch den Entwicklungsprozess geleitet und gezielt mit relevanten Infor-mationen versorgt werden. Das neu konzipierte Informationssystem gewähr-leistet durch eine konsequente Fokussierung auf die beiden Aspekte Qualitäts-sicherung und Mitarbeiterunterstützung eine umfassende Prozessunterstüt-zung in Softwareentwicklungsprojekten.


� Systemarchitektur eines prozessbasierten Informationssystems für QM-Systeme

Einen weiteren Aspekt dieser Arbeit bildet der Entwurf einer Systemarchitek-tur für das prozessbasierte Informationssystem. Ein zentrales Ziel beim Ent-wurf des Systems ist es, seine Änderbarkeit zu gewährleisten. So soll es ermög-licht 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 Spei-chersystems betrachtet. Hier müssen alle Informationen, die im Prozess-managementsystem angezeigt werden sollen, strukturiert abgelegt werden. Es müssen sowohl die Anforderungen, die sich direkt aus dem Prozessmanage-mentsystem ergeben als auch jene die aus der Umsetzung des QM-Modells re-sultieren, 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.

Abbildung 1-3: Generalisierung des aQM2 aus den QM-Standards ISO/IEC 15504 und CMMI

in der Arbeit neu entwickelte Konzepte

QualitätsmanagementSoftware-Entwicklungsprozesse

ISO/IEC 15504-5

Anwendung

erfüllt Vorgaben

V-Modell XT ISO 9001

Software-Vorgehensmodell QM-Standardabstraktes QM-

Modell (aQM2)

CMMIISO/IEC 12207(Prozessdimension)

ISO/IEC 15504-2(Reifegraddimension)

vorhandene Konzepte


In Abbildung 1-3 wird die Beziehung zwischen dem aQM2 und den bestehenden QM-Standards ISO/IEC 15504 und CMMI gezeigt. Das aQM2 identifiziert die Kernanforde-rungen 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 zusam-men. 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 entwi-ckelt Anwender bei der Bearbeitung von Projekten zu unterstützen. Die im Process-Navigator 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.

Abbildung 1-4: Der ProcessNavigator als Ergebnis aus Anforderungen der QM-Standards und der

Anwender

UnternehmensinterneKonzepte und Systeme

Externe Anforderungenund Vorgaben

Projekt

Prozess-ausführungssystem


wird genutzt

unterstütztdie Umsetzung

Anforderungen der QM-Standards

Anforderungen der Anwender

abstraktes QM-Modell (aQM2)

Anwender

ProcessNavigatorProzesse

Six Sigma

beschreibtStandardvorgehen

in der Arbeit neu entwickelte Konzepte

vorhandene Konzepte




Zusammenfassend lässt sich der Nutzen des in dieser Arbeit konzipierten ProcessNa-vigators auf drei Kernaspekte verdichten:

1. Steigerung der Transparenz im Entwicklungsprojekten durch die IT-unter-stü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üh-rung 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 entwor-fen 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 QM-Standards umsetzt, sondern vielseitig anwendbar ist.

1.3 Aufbau der Arbeit Die Arbeit gliedert sich in 15 Kapitel deren Abhängigkeiten in Abbildung 1-5 vorge-stellt 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 Informations-system 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 Informa-tionssystem 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 entwi-ckelt, welcher um eine explizite Projektplanung ergänzt wurde. Dieser neue Prozess-lebenszyklus definiert die Struktur der Kapitel 7 bis 10. Vor der detaillierten Vorstel-lung 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 Anforderun-gen 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 Entwicklungs-prozessen 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.


Abbildung 1-5: Aufbau der Arbeit

Ein Konzept zur Implementierung von prozessorientierten Qualitätsmanagementsystemen

Teil I:Anforderungen an ein

Qualitätsmanagementsystem

Teil II:Konzeption einesprozessbasierten

Informationssystemsfür QM-Systeme

Teil III:Umsetzung

und Schlussfolgerungen

Kapitel 5:Entwurf eines Vorgehensmodells zur Umsetzung von QM-Anforderungen

Kapitel 6:Ausblick: Umsetzung der QM-

Anforderungen im ProcessNavigator

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 1:Einführung, Zielsetzung

und Aufbau

Kapitel 2:QM-Standards und Vorgehensmodelle

Kapitel 12:Systemarchitektur

Kapitel 13:Evaluation des ProcessNavigators

Kapitel 14:Zusammenfassung

Kapitel 15:Ausblick

Kapitel 3:Rekonstruktion des abstrakten

QM-Modells

Kapitel 4:Anforderungen an ein prozessbasiertes Informationssystem aus Anwendersicht

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 Softwareentwicklungs-prozesses die Qualität des Produkts zu verbessern. Zur Verbesserung (bzw. Beeinflus-sung) dieses Entwicklungsprozesses wurden zwei Vorgehensweisen entwickelt: Vorgehensmodelle, die direkt aus Sicht der Softwareentwicklung nötige Arbeitsschrit-te 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ätsma-nagement-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 V-Modell 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 Erfolgs-wahrscheinlichkeit 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:

� Minimierung der Projektrisiken Durch die im V-Modell beschriebenen standardisierten Vorgehensweisen sol-len Transparenz und Planbarkeit des Projekts erhöht werden. Diese Effekte sollen sich vor allem aus den im Modell gemachten Vorgaben an Arbeitsschrit-te, Rollen und Arbeitsergebnisse ergeben. Durch die erhöhte Planungssicher-heit sollen die Projektrisiken vermindert werden.

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

� Eindämmung der Gesamtkosten über den gesamten Projekt- und Systemle-benszyklus 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.

� Verbesserung der Kommunikation zwischen allen Beteiligten Durch das V-Modell soll auch die Kommunikation zwischen den am Projekt be-teiligten Gruppen verbessert werden. Durch das standardisierte Vorgehens-modell 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 standardi-siertes Vorgehen, welches sich durch verschiedene Konfigurations- bzw. Tailoring-Mechanismen an die Gegebenheiten des jeweiligen Projekts anpassen lässt. Das V-Modell 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 ver-schiedene Angebote, die auf dem V-Modell basieren, einfacher miteinander vergli-chen werden können.


Die erste Stufe der Anpassung an den Projektkontext wird durch den Projekttyp festgelegt. Im V-Modell XT sind vier verschiedene Projekttypen vorgesehen:

� Systementwicklungsprojekt eines Auftraggebers;

� Systementwicklungsprojekt eines Auftragnehmers;

� Systementwicklungsprojekt eines Auftraggebers mit Auftragnehmer in der gleichen Organisation (ohne Ausschreibungs- und Vertragswesen);

� 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 Auftragneh-mers. 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 organisationsspezi-fischen 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.

Abbildung 2-1: Bestandteile eines Vorgehensbausteins

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

Rolle

AktivitätProduktEI

0/1* 0/11

*

Disziplingehört zur selben Disziplin wie das

Produkt

1

**

** 1*

1

1..*

Vorgehensbaustein

ist verantwortlich

wirkt mitstellt fertig

bearbeitet

hat Abhängigkeiten

zu anderen* *

ArbeitsschrittThema


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 Vertrags-wesen 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 Entschei-dungspunkte bearbeitet werden müssen. In Abbildung 2-2 sind zwei Projektdurchfüh-rungsstrategien 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 Entschei-dungspunkten „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.


a)

b)

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)]:

� die Auswahl eines Projekttyps � die Auswahl eines der möglichen Projekttypvarianten � 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 Entschei-dungspunkte abgearbeitet werden müssen, kann während der Auswahl der Projekt-

Unterauftrag

Systementworfen

Systemintegriert

Systemelementerealisiert

Feinentwurfabgeschlossen

Systemspezifiziert

Lieferungdurchgeführt

1..*Y

0..*1..* Y

1..* Y

Projektbeauftragt

Abnahmeerfolgt

Angebotabgegeben

Projektgenehmigt

Iterationgeplant

Projektabgeschlossen

Projektdefiniert

1..*0..* Y

Projektausgeschrieben

Projektbeauftragt

Abnahmeerfolgt

Projektfortschrittüberprüft

Iterationgeplant

Unterauftrag

Projektbeauftragt

Abnahmeerfolgt

Angebotabgegeben

Projektgenehmigt

Iterationgeplant

Projektabgeschlossen

Projektdefiniert



Systementworfen

Systemspezifiziert


Systemintegriert

1..* Y

Y0..1 0..* Y0..* 0..1

Y 1..*

Unterauftrag

Projektausgeschrieben

Projektbeauftragt

Abnahmeerfolgt

Projektfortschrittüberprüft

Iterationgeplant

Unterauftrag


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 darge-stellt 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 Softwareent-wicklung 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ätz-lich ü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 entwi-ckelt, 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 Vor-teile. Ä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 Unter-nehmen 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 grundle-gende 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


(weder CMMI noch ISO/IEC 15504) ins Deutsche gibt, werden die englischen Original-texte 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:

� Reifegradstufen: Sie treffen eine Aussage darüber, wie gut ein Prozess in ei-nem 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 begriffli-chen Unterscheidung treffen beide Darstellungen jedoch vergleichbare Aussa-gen.

� 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 Prozessge-biets 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


Reifegradstufe zu erreichen, müssen alle von dieser Stufe referenzierten Prozessge-biete 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 Umsetzungsrei-henfolge der Prozessverbesse-rungsmaßnahmen so vorzuneh-men, dass sie zu den Geschäftszie-len 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 Entwicklungspro-jekt zu messen

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

Erlaubt unterschiedliche Verbesse-rungsgeschwindigkeiten für verschiedene Prozesse und Prozessgebiete

Fasst die gesamte Prozessverbesse-rung 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 Erfahrungs-historie 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 kontinu-ierlichen Darstellung bewertet wurden, ein Reifegrad für das gesamte Unternehmen festlegen.


In dieser Arbeit soll weiterhin nur noch die kontinuierliche Darstellung betrachtet werden, da mit ihr genauere Aussagen über die Fähigkeit eines Prozesses (Fähigkeits-profil) 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 „Institutionalisie-rung“ gesprochen. Sie beschreibt, wie gut ein geplanter Prozess in die alltäglichen Arbeitsabläufe eines Unternehmens eingebunden ist. In der kontinuierlichen Darstel-lung 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 unter-stützt die Erstellung der Arbeitsergebnisse.

2. Gemanagt3 (Managed)

Erreicht ein Prozess die Fähigkeitsstufe 2 so wird von einem „gemanagten Pro-zess“ gesprochen. Der Prozess erfüllt die Anforderungen der Stufe 1 und be-sitzt 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 Pro-zessgebiete 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ähig-keitsstufe 2 genutzt wird, wird diese auch in der vorliegenden Arbeit entsprechend bezeichnet.


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 vor-her definierten Standardprozess des Unternehmens abgeleitet (Process Tailo-ring) wurde. Für dieses Tailoring müssen im Unternehmen vorhandene Richtli-nien 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 gema-nagten“ 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 statis-tischer 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; aus-schlaggebend für die Bewertung und Festlegung einer Fähigkeitsstufe ist die Imple-mentierung 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 einzigar-tigen Eigenschaften, die zu seiner Erfüllung notwendig sind. Im Gegensatz zu spezifi-schen 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


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

Abbildung 2-3: Struktur der CMMI-Prozessgebiete [CMMI Product Team 2006]

Am Beispiel des Prozessgebiets „Configuration Management“, welches die Sicherstel-lung der Vollständigkeit der Arbeitsergebnisse durch ein Konfigurationsmanagement-system 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 Prozessge-biets im Unternehmen und durch die Angabe der spezifischen Praktiken auch einen Leitfaden, wie diese fachlich umzusetzen sind. Generische Ziele beschreiben hinge-

Prozessgebiet

Spezifische Ziele Generische Ziele

Spezifische Praktiken

EinleitungÄhnliche Prozess-gebiete

Zweck

Generische Praktiken

Sub-PraktikenTypische Arbeits-

ergebnisseSub-Praktiken

Typische Arbeits-

ergebnisse


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 Entwick-lungsziele. 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:

� Part 1: Concepts and vocabulary

� Part 2: Performing an assessment

� Part 3: Guidance on performing an assessment

� Part 4: Guidance on use for process improvement and process capability de-termination

� Part 5: An exemplar Process Assessment Model

� Part 6: An exemplar system life cycle process assessment model

� 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 Anforde-rungen 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


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 Softwareentwicklungs-projekte maßgeblichen Anforderungen definieren, werden die anderen Teile in dieser Arbeit nicht weiter betrachtet.

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 Verantwort-lichkeiten 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 Automobilin-dustrie [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 –

Prozess Assessment Modell

Rollen und Verantwortlich-

keiten

Prozess Referenzmodell Mess-Framework

Eingaben Assessment Prozess Ausgaben


Software life cycle processes“, der ein Lebenszyklusmodell für die Softwareentwick-lung 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 Mess-Framework (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 vorhan-den sind, sondern die beiden Dimensionen nahezu unabhängig voneinander sind.

Abbildung 2-5: Struktur der ISO/IEC 15504

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

Prozessattribut Indikatoren

Prozess-assessment-modell (PAM)

Prozess-dimension

Reifegrad-dimension

Prozess

Generisches Arbeitsprodukt

Generische Praktik

Generische Ressource

ProzessattibutProzessgruppe

ArbeitsproduktBasispraktik

ReifegradstufePrimäre

Lebenszyklus-prozesse


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 Indikato-ren für die Umsetzung des Standards genutzt werden. Der Prozess Anforderungs-erhebung 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 (Institutionalisie-rung) 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 Assess-ment durch den Assessor überprüft werden. Dies sind: Generische Praktiken (Generic Practices), Generische Ressourcen (Generic Resources) und Generische Arbeitsproduk-te (Generic Work Products). Generische Praktiken des Prozessattributs „Management der Prozessdurchführung“ sind beispielsweise „Ermittle die Ziele der Prozessdurchfüh-rung“ 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:

� 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 systemati-sche 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 neh-men.


� Level 1: Durchgeführt (Performed) Der implementierte Prozess erfüllt seinen Zweck.

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

� Level 3: Etabliert (Established)

Der zuvor beschriebene gemanagte Prozess wird nun auf Basis eines definier-ten Prozesses implementiert, der in der Lage ist die Prozessergebnisse zu erfül-len.

� Level 4: Vorhersagbar (Predictable) Der zuvor beschriebene etablierte Prozess wird nun innerhalb definierter Grenzen ausgeführt um die Prozessergebnisse zu erzielen.

� 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ähigkeits-stufen 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 QM-Anforderungsmodells.

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än-zenden 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 ausge-hend 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 QM-Anforderungsprofils 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 Sprach-ebenenhierarchie (Meta-Ebenen) eingesetzt. Meta-Modelle legen die wesentlichen technischen Strukturelemente eines Prozesses fest, vom Entwurf der Modellierungs-sprache, ü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 QM-System.

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 Meta-Modellen 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 Spezifika-tion 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 repre-sentation 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 Meta-Modellen 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.

� 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 wer-den und bilden damit das Ende der Hierarchie.

� 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 Prozess-verantwortlichen erstellt. Die Menge aller Prozesstypen bildet die Typ-Bibliothek. Sind die vorhandenen Prozesstypen nicht ausreichend, kann die Bibliothek um weitere Typen ergänzt werden.

� M2 – Prozess-Meta-Modell Das Prozess-Meta-Modell definiert die zur Modellierung genutzte Modellie-rungssprache. Die Modellierungssprache wird durch einen Domänenexperten für eine Vielzahl an gleichartigen Anwendungsfällen erstellt. Diese Sprache zer-fällt in einen abstrakten und einen domänenspezifischen Anteil. Während im abstrakten Teil jene Sprachelemente spezifiziert werden, die alle Modellie-rungssprachen gemeinsam nutzen, können im domänenspezifischen Sprachan-teil die Anpassungen an die Anwendungsdomäne vorgenommen werden.

� M3 – Prozess-Meta-Meta-Modell Im Prozess-Meta-Meta-Modell sind die zur Definition der Modellierungs-sprache 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 Unter-nehmen vorhandenen Anforderungen angepasst werden. Sie geben außerdem einen anwendungsneutralen Rahmen vor, mit dem andere Anforderungen verglichen werden können.


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 Modellierungs-sprache 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 Prozessmo-dellierungssprache 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 Projektbau-stein, welcher zur Modellierung von Projekttypen, einer Erweiterung von Prozessty-pen, genutzt wird. Durch die Nutzung eines Meta-Modells wird in der Modellierungs-sprache 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

M3 Abstraktes Prozess-Meta-Meta-Modell

M2 Abstraktes Prozess-Meta-Modell

DomänenspezifischesProzess-Meta-Modell

M1

M0 Prozess-Instanzen(momentan ausgeführte Prozesse)

Typ-Bibliothek Prozessmodelle


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ähigkeitsdimen-sion (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 Ab-deckung 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-Anfor-derungen adressiert werden und wie diese durch IT-Systeme unterstützt werden können. So muss ein Teil der Anforderungen während der Prozess- und Projektpla-nung umgesetzt werden, während andere Anforderungen nur während der Ausfüh-rung 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:


� 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 ver-gleichbaren Vorhaben eingesetzt werden. Durch den Prozesstyp wird im Un-ternehmen auch das Standardvorgehen zur Bearbeitung eines Vorgangs fest-gelegt. Somit ist dies auch der Standard-, Soll- oder Referenzprozess.

� Projekt Nach DIN 69901 ist der Begriff Projekt definiert als ein Vorhaben, das im We-sentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekenn-zeichnet ist. Die im Projekt ausgeführte Folge von Arbeitspaketen wird als Pro-jekttyp 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 Pro-jekts anzupassen“

In dieser Arbeit werden außerdem die Begriffe Aufgabe, Arbeitspaket und Projekt-schritt 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 Prozessattri-bute 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 Reifegradebe-nen (RG1 bis RG5) bezeichnet.


3.2.1 Das aQM2 im Überblick

Bevor die einzelnen Ebenen des aQM2 in den nächsten Abschnitten im Detail betrach-tet 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üh-rung gelegt. Ergebnis der Aktivitäten der Planungsebene ist ein fertiger Pro-zesstyp 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 an-deren aber auch Informationen und Daten, die während der Ausführung ge-sammelt werden. Diese können genutzt werden, um Verbesserungsmöglich-keiten 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.

Abbildung 3-2: Meta-Ebenen in der Prozess- und Projektdurchführung

Planungsebene Ausführungsebene

M2: Sprachdesign

M1: Prozessplanung

M0: Projektausführung

M0: Messdatenbank

Mes

sdat

en

Verbesserungen

Proj

ekts

teue

rung

M1: ProjektplanungInstanziierung


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ötig-ten 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 Entwicklungs-projekte 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 definier-ten 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-


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

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


M2: Sprach-design

M1: Prozess-planung

M0: Projekt-ausführung

RG0

RG3

M0:Messdatenbank

RG5

Mes

sdat

en

Verbesserungen

Proj

ekts

teue

rung

M1: Projekt-planung

M0: Umsetzung der Praktiken

RG2

RG4

RG1

Instanz.


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 Arbeits-ergebnisse definiert, anhand derer der Assessor später überprüfen kann, ob und wie weit ein geforderter Arbeitsschritt in der Praxis umgesetzt wird.

Tabelle 3-1: Anforderungen auf Level 1

ISO/IEC 15504 CMMI

PA 1

.1:

Pr

oces

s per

form

ance

at

trib

ute

a) the process achieves its defined outcomes

G

G 1

:

Achi

eve

Spec

ific

Goal

s 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 entspre-chende 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


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

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

Ziel 1.2: Erstellen der geforderten Arbeitsergebnisse

Die im Referenzmodell zu jedem Schritt angege-ben Arbeitsschritte und Dokumente müssen in den Projekten erstellt werden.

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 Reife-gradebene 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 Arbeits-ergebnisse 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 Projektma-nagementaktivitäten zu leiten und auf diese Weise auf Abweichungen vom definier-ten 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.



ISO/IEC 15504 CMMI

PA 2

.1:

Pe

rfor

man

ce m

anag

emen

t att

ribut

e

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

GG

2:

In

stitu

tiona

lize

a M

anag

ed P

roce

ss

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;

GP 2.5: Train People

f) interfaces between the involved parties are managed to ensure both effective communication and also clear assign-ment of responsibility.

GP 2.6: Manage Configurations

PA 2

.2:

W

ork

prod

uct m

anag

emen

t att

ribut

e

a) requirements for the work products of the process are defined;

GG

2:

In

stitu

tiona

lize

a M

anag

ed P

roce

ss

GP 2.7: Identify and Involve Relevant Stakeholders

b) requirements for documentation and control of the work products are defined;

GP 2.8: Monitor and Control the Process

c) work products are appropriately identified, documented, and controlled;

GP 2.9: Objectively Evaluate Adherence

d) work products are reviewed in accor-dance with planned arrangements and adjusted as necessary to meet require-ments.

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 Prozessaus-führung) und PA 2.2 Work product management attribute (Management der Arbeits-produkte). Ziel des PA 2.1 ist es, grundlegende Projektmanagementaktivitäten bei der


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.


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 zeit-lichen Ablaufplan.

Ziel 2.2: Definition von Zielen und Entscheidungs-befugnissen für die Prozessaus-fü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 Entscheidungs-befugnisse 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 Umset-zung 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].


RG 2

Ziel 2.5: Definition der Anforderungen an Arbeits-produkte

Es müssen die Anforderungen an die im Projekt erstellten Arbeitsprodukte definiert werden. Hier sollen insbeson-dere 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 Arbeits-schritte müssen durch den Projektleiter ständig über-wacht werden. Bei Abweichungen vom Plan muss dieser steuernd eingreifen und gegebenenfalls die Planung anpassen.

Ziel 2.7: Überwachung und Korrektur der Arbeitspro-dukte

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

In [Rout et Tuffley 2007] werden die beiden QM-Standards hinsichtlich ihrer Kompa-tibilität und Übereinstimmungen miteinander verglichen. Nach einer Abbildung der Prozessattribute aus der ISO/IEC 15504 auf die entsprechenden Generischen Prakti-ken 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 vorge-stellten 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 Kommunikations-wege, 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.


Im Gegensatz zu RG1 (Ausgeführter Prozess) beinhaltet der RG2 sowohl eine Pla-nungs- 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.

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 Entschei-dungsbefugnisse, die Kommunikationswege innerhalb des Projektes und die Erwar-tungen an die Qualität der Arbeitsprodukte müssen im Vorfeld der Projektdurchfüh-rung 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 Soll-Daten 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 Arbeits-ablauf 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


Instanziierung/Umsetzen

Abgleichen

Steu

ern

und

Anpa

ssenM0: Projekt-

ausführungM1: Projekt-

planungRG2

Plan

en

und

Fest

lege

n


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.


ISO/IEC 15504 CMMI

PA 3

.1:

Proc

ess d

efin

ition

att

ribut

e

a) a standard process, including appropriate tailoring guidelines, is defined that describes the fundamental elements that must be in-corporated into a defined process;

GG

3:

In

stitu

tiona

lize

a De

fined

Pro

cess

GP 3.1: Establish a Defined Process

b) the sequence and interaction of the standard process with other processes are determined;

GP 3.2: Collect Improvement Information c) required competencies and roles for perform-

ing a process are identified as part of the standard process;

d) required infrastructure and work environ-ment for performing a process are identified as part of the standard process;

e) suitable methods for monitoring the effec-tiveness and suitability of the process are determined.


ISO/IEC 15504

PA 3

.2:

Pr

oces

s dep

loym

ent a

ttrib

ute

a) a defined process is deployed based upon an appropriately selected and/or tailored stan-dard process;

b) required roles, responsibilities and authorities for performing the defined process are as-signed and communicated;

c) personnel performing the defined process are competent on the basis of appropriate educa-tion, training, and experience;

d) required resources and information necessary for performing the defined process are made available, allocated and used;

e) required infrastructure and work environ-ment 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 effec-tiveness 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 (Prozessde-finition) 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 Prozes-ses 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-


mensprojekten angewandt werden. Dazu wird überprüft, ob Projekte mittels eines Tailoring aus den vorher definierten Standardprozessen abgeleitet wurden. Mitarbei-tern im Projekt müssen die im Standardprozess geplanten Rollen und Verantwortlich-keiten 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 Struktu-ren 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 qualifi-ziert 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 Verbesserungs-informationen im Unternehmen.

Ein Vergleich der beiden Normen in [Rout et Tuffley 2007] ergibt, dass sich insbeson-dere im ISO/IEC 15504 Prozessattribut 3.1 (Prozessdefinition) große Überschneidun-gen 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.



RG 3

Planungsebene

Ziel 3.1: Aufstellung eines Standard-prozesses und seiner Schnitt-stellen

In diesem Ziel wird festgelegt, dass im Unternehmen Standardprozesse definiert werden, von dem die im Unternehmen durchgeführten Projekte über Tailoring-Maß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 Schnittstel-len zu anderen Prozessen in der Organisati-on 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 Rahmenbe-dingungen ein entsprechendes Projekt mit Hilfe von Tailoring-Maßnahmen abgeleitet werden.

Ziel 3.4: Festlegung der im Projekt eingesetzten Verantwortlich-keiten 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 Standardprozes-ses

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


RG 3

Ausführungsebene

Ziel 3.6: Erfassung der Daten und Ermitteln von Verbesserungs-potenzialen

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 Standard-prozesses (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 Modellierungs-sprache 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 Ressour-cen 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 Verbesse-rungspotenziale 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.



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



Bereitstellen von Ressourcen

Ermitteln von Verbesserungs-

potenzialen

Mes

sen

M2: Sprach-design

M1: Prozess-planung

RG3

M1: Projekt-planungRG2

Plan

enTa

ilorin

g



ISO/IEC 15504 CMMI

PA 4

.1:

Proc

ess m

easu

rem

ent a

ttrib

ute

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

GG

4:

In

stitu

tiona

lize

a Q

uant

itativ

ely

Man

aged

Pro

cess

GP 4.1: Establish Quantitative Objectives for the Process

b) process measurement objectives are derived from identified process informa-tion needs;

c) quantitative objectives for process performance in support of relevant busi-ness goals are established;

GP 4.2: Stabilize Subprocess Performance

d) measures and frequency of measurement are identified and defined in line with process measurement objectives and quantitative objectives for process per-formance;

e) results of measurement are collected, analysed and reported in order to monitor the extent to which the quantitative objec-tives for process performance are met;

f) measurement results are used to charac-terise process performance.

PA 4

.2:

Pr

oces

s con

trol

att

ribut

e

a) suitable analysis and control techniques where applicable, are determined and applied;

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-


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 Prozesssteu-erung 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, Korrek-turmaßnahmen zu ergreifen. Die Ergebnisse der Korrekturmaßnahmen müssen verfolgt und auf ihre Effektivität überwacht werden. Wenn nötig, können die Pro-zesskontrollgrenzen 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ün-sche und Geschäftsziele beziehen. GP 4.2 verlangt die Stabilisierung der Prozessaus-fü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


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


RG 4

Planungsebene

Ziel 4.1: Definition von quantitati-ven Zielen für die Messun-gen

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

Ziel 4.2: Identifikation von Mess-punkten 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 erstellen-de Produkt Messpunkte identifiziert und entsprechende Methoden definiert werden.

Ausführungsebene

Ziel 4.3: Sammeln und Erfassen von Messdaten

Mit Hilfe der definierten Messpunkte müssen im ausgeführten Projekt Daten erhoben und in einem entsprechenden Repositorium gesam-melt 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.


RG 4

Ziel 4.5: Erarbeitung von Korrek-turmaß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.


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

M2: Sprach-design

M1: Prozess-planung


M0:Messdatenbank

Proj

ektü

berw

achu

ng/

Anal

yse

von

Abw

eich

unge

n

M1: Projekt-planung

RG4


Definition von Zielen für das

Projekt

RG3

Defin

ition

von

Info

rmat

ions

bedü

rfni

sse

n un

d M

essz

iele

n

Erfa

ssun

g vo

n M

essd

aten

Proj

ekt-

steu

reru

ng


werden können. Diese treffen Aussagen darüber, ob die Ausführung des Projekts innerhalb der vordefinierten Schranken stattfindet, oder ob Abweichungen aufgetre-ten sind (Ziel 4.4). Im Fall von Abweichungen sind geeignete Maßnahmen zu entwi-ckeln und im Projekt umzusetzen, um die Ausführung wieder innerhalb der vordefi-nierten 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 Ansatz-punkte zur Verbesserung der Prozesse im Unternehmen systematisch erarbeitet, im Unternehmen pilotiert und umgesetzt werden. In Tabelle 3-9 werden die Anforde-rungen, 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 Verbesse-rung 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 ausgewer-tet, die wichtigsten Gründe für Abweichungen identifiziert und Verbesserungs-möglichkeiten erarbeitet. Zur Prozessverbesserung können dabei auch neue Techno-logien 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


der Verbesserungen gemanagt und begleitet werden und schließlich muss die Effektivität der Prozessänderungen untersucht werden.


ISO/IEC 15504 CMMI

PA 5

.1:

Pr

oces

s inn

ovat

ion

attr

ibut

e

a) process improvement objectives for the process are defined that support the rele-vant business goals;

GG

5:

Inst

itutio

naliz

e an

Opt

imizi

ng P

roce

ss

GP 5.1: Ensure Continuous Process Improve-ment 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 innova-tion;

GP 5.2: Correct Root Causes of Problems

d) improvement opportunities derived from new technologies and process concepts are identified;

e) an implementation strategy is established to achieve the process improvement objectives.

PA 5

.2:

Proc

ess o

ptim

izatio

n at

trib

ute

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/


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ührungs-ebene zum Ziel hat. Stattdessen liegt hier, abgesehen von der Planung der Verbesse-rungsziele, 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.


RG 5

Planungsebene

Ziel 5.1: Definition der strategischen Verbesserungsziele

Ausgangspunkt für die Erarbeitung der Prozessverbesserungen ist eine klare Definiti-on 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 Verbesserungs-möglichkeiten analysiert. Dabei müssen insbesondere die strategischen Verbesse-rungsziele 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.


RG 5

Planungsebene

Ziel 5.4: Erarbeiten von Verbesse-rungsmöglichkeiten

Für die gefundenen Ursachen für Abweichun-gen sind Verbesserungsmöglichkeiten zu erarbeiten, die die Ursachen von Prozessab-weichungen beseitigen. Dabei sind insbeson-dere neue technische und methodische Verfahren zu berücksichtigen.

Ziel 5.5: Entwickeln einer Umset-zungsstrategie

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

Lösungen, die in einem Pilotprojekt erfolg-reich waren, sollen in den Standardprozess integriert werden. Durch die Überarbeitung des Standardprozesses wird auch ein Ausrol-len 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 basie-rend 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 sicherge-stellt 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


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 Pilotprojek-tes ist eine Strategie für die Umsetzung der Verbesserungsvorschläge zu erarbeiten, bevor diese im Rahmen einer Überarbeitung in die Unternehmensprozesse aufge-nommen werden können. Durch die Überarbeitung der Standardprozesse erfolgt auch ein Ausrollen der Änderungen in die Instanzen. Durch eine regelmäßige Über-prü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).


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 ange-passt. 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 QM-Anforderungsgerüst für das prozessbasierte Informationssystem vorgestellt. Die Ziele bauen sukzessive aufeinander auf und verfolgen den Zweck, Anforderungen an ein


M2: Sprach-design

M1: Prozess-planung

M0:Messdatenbank

RG5

Verbesserungen

M1: Projekt-planung

RG4Analyse der Daten

Erarbeiten von Verbesserungs-möglichkeiten

Entwickeln einer Umsetzungsstrategie

Sicherstellen der Effektivität

Umsetzen der Verbesserungen

Identifikation von gemeinsamen Gründen für

Abweichungen

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 Projektma-nagement 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 QM-Standards. 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 wieder-holt 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 Prozess-ausfü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:

� 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 Pro-zessdesign oder technische Probleme im Prozess; externe Auslöser können ein geändertes Geschäftsumfeld, Gesetzesänderungen oder auch ein neues tech-nisches Umfeld sein.

� Die Auswirkung der Änderung auf den Prozess. Die Änderung kann sich entwe-der 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 Prozes-se dauerhaft ändern. Temporäre Änderungen werden oft durch Ausnahmen ausgelöst und eine Anpassung der Prozessdefinition ist im Gegensatz zu dau-erhaften Änderungen nicht notwendig.

� 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 (Perspek-tiven) zusammensetzt. Jeder dieser Aspekte beschreibt einen bestimmten Teil eines Prozessmodells (die Funktionen, den Kontrollfluss, die Prozessdaten, be-teiligte Organisationen und Werkzeuge). Durch die Änderungen können ent-weder einzelne oder auch mehrere Perspektiven betroffen sein.

� Die Art der der Änderung. Die Änderung kann eine Erweiterung um neue Pro-zessschritte oder eine Reduzierung der Schritte des Prozesstyps beinhalten. Weitere Möglichkeiten sind das Ersetzen von Dokumenten, Werkzeugen oder Organisationseinheiten im Prozess.

� Der Zeitpunkt, zu dem Änderungen erlaubt werden. Änderungen am Prozess können entweder nur vor seiner Instanziierung oder auch während der Aus-führung erlaubt werden. Sind Änderungen nur vor der Instanziierung eines Prozesses erlaubt, so sind laufende Prozesse nicht betroffen und eine Anpas-sungsstrategie ist für diese Prozesse nicht nötig.

4.1 Änderungen als zentraler Bestandteil des Prozessmanagements 67

� 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 Fort-fahren (der alte Prozess wird unverändert fortgsetzt). Außerdem können die Prozesse auf die neue Definition angepasst werden und für temporäre Ände-rungen 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 Prozess-managementsystemen umgesetzt werden kann. Die Klassen können genutzt werden, um in einem Prozessmanagementsystem auf Änderungen zu reagieren und diese zu implementieren:

� 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än-gen, Entscheidungen oder Iterationen umgesetzt werden. Während der Aus-führung hat der Nutzer die Möglichkeit, die Prozessausführung entsprechend der im Prozesstyp vorgegebenen Wahlmöglichkeiten zu beeinflussen.

� Flexibility by Deviation

In dieser Klasse können Nutzer während der Prozessausführung vom vorgege-benen Prozesstyp abweichen, ohne den Typ selbst ändern zu müssen. So ha-ben die Mitarbeiter bei der Ausführung des Prozesses unter anderem die Mög-lichkeit Prozessschritte zu überspringen, Schritte erneut auszuführen oder die-se auszulassen.

� Flexibility by Underspecification Die Unterspezifikation eines Prozesses zeichnet sich dadurch aus, dass bei der Modellierung eines Prozesses bestimmte Ausführungselemente nicht festge-legt werden und ein Platzhalter an dieser Stelle eingefügt wird. Die Platzhalter können während der Ausführung entweder durch vorgegebene Prozessfrag-mente ausgefüllt werden (late binding) oder während der Ausführung wird an dieser Stelle ein neu erstelltes Prozessfragment eingefügt (late modeling).


� 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 anzupas-sen. Diese Änderungen können sowohl nur die ausgeführte Instanz betreffen (temporäre Änderung) als auch alle zukünftigen Instanzen (dauerhafte Ände-rung).

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 Produkt-entwicklung 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 Prozessmanage-mentsystem 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 Projekt-situation informieren und sie dabei unterstützen, die notwendigen Arbeiten auszu-fü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 Prozessma-nagementsystem unterstützt werden können, ohne sie durch das System einzu-schränken. So treten bei der Entwicklung von Produkten immer wieder unvorherge-

5 Bayerischer Forschungsverbund für Prozess- und Workflow-Unterstützung zur Planung und

Steuerung der Abläufe in der Produktenwicklung (www.forflow.org) 6 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 Kon-zept 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 Rahmenbedin-gungen 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 Prozessmanage-mentsystem 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 Mitarbei-tern die jeweils nächsten Prozessschritte vorschlagen. Diese Anforderung entspricht der Funktionsweise von klassischen Workflow-Management-Systemen. 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 Schlei-fen. Da diese kurzen Iterationen ad hoc auftreten und nicht von Anfang an im Prozesstyp eingeplant werden können, muss der ProcessNavigator die erneu-te Ausführung auch bereits abgeschlossener Arbeitsschritte zulassen.

#3 Überspringen von Arbeitspaketen: Die Kreativität der Ingenieure ist ein ent-scheidender 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 übersprin-gen und mit einem Schritt, der erst später im Entwicklungsprozess vorgese-hen ist, fortzufahren. Übersprungene Schritte dürfen jedoch nicht als abge-schlossen markiert werden und müssen den Anwendern erneut zur Bearbei-tung angeboten werden.

#4 Auslassen von Arbeitspaketen: In Ausnahmefällen kann es vorkommen, dass Arbeitspakete, obwohl sie im Prozesstyp eingeplant sind, im Verlauf des Pro-zesses nicht mehr bearbeitet werden müssen. Die Entscheidung, ob die Er-gebnisse eines Arbeitspakets nicht mehr benötigt werden, ist komplex und kann nur von Mitarbeitern getroffen werden. Der ProcessNavigator muss die-sen 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äte-re 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 ein-räumt, um das Projekt erfolgreich zu Ende zu führen. Bezogen auf die in


[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 Anwen-dungsdomä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 Erfah-rungen 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 Informations-system auch Funktionen eines Wissensmanagementsystems [Alavi et Leidner 2001; Nonaka et Takeuchi 1995] wahr, indem es die nötigen Kontextinformationen bereit-stellt:

#5 Bereitstellen von Informationen über das Arbeitspaket: Das Prozessmanage-mentsystem muss den Mitarbeitern Informationen über das aktuelle Arbeits-paket bereitstellen. Diese Informationen beinhalten insbesondere eine aus-führliche Beschreibung der umzusetzenden Arbeitspakete. Neben der eigent-lichen Aufgabenbeschreibung müssen zusätzlich noch weitere Informationen bereitgestellt werden.

#6 Koordination der Arbeitspakete zwischen den Mitarbeitern: Um eine Zusam-menarbeit 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 Ausgangs-dokumente 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 Doku-ment-Templates bereitstellen. Außerdem können Beispieldokumente hinter-legt sein, die den Mitarbeitern aufzeigen, was als Ergebnis eines Arbeits-schritts erwartet wird.

#8 Unterstützung bei der Benutzung von Werkzeugen und Systemen: Der Pro-cessNavigator 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 be-sonders gute Ergebnisse erzielt werden können.

#9 Unterstützung von Entscheidungen: Sind im Prozesstyp alternative Ausfüh-rungspfade vorgesehen, so sollen dem Anwender Hinweise (z.B. Lessons Learned und Best Practices) gegeben werden, die ihn bei der Entscheidungs-findung ü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 wer-den. Somit kann später nachvollzogen werden, warum eine bestimmte Ent-scheidung getroffen wurde und der Entwicklungsprozess wird insgesamt transparenter.

#10 Unterstützung von Meilensteinen: Zur besseren Strukturierung des Entwick-lungsprozesses muss das Prozessmanagementsystem Meilensteine unterstüt-zen. 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 Än-derungen genügend stabil, um in nachfolgenden Phasen, auf den dort be-schriebenen 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


Informationen zusammen, die den Anwender (Entwickler) bei der Ausführung des Entwicklungsprojekts unterstützen können. Der Kontext eines wird im Entwicklungs-projekt durch verschiedene Parameter (z.B. aktuellen Prozessschritt, Projekt, Bearbei-ter, 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ähl-ten 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 QM-Standards vorgeschlagen, aber nicht zwingend verlangt. Im Gegensatz zu den anderen Kapiteln dieser Arbeit wird daher in diesem Abschnitt nicht davon ausgegan-gen, 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 IT-System) erfüllt werden können. Dies ist auch deswegen interessant, da hiermit der Mehrwert des Prozessmanagementsystems gegenüber einer „manuellen“ Prozess-ausfü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:


In einem Unternehmen wurde ein neues Projekt genehmigt. Für die Pro-jektumsetzung existiert eine Prozessbeschreibung, welche alle notwendi-gen Arbeitsschritte umsetzt und auch im Unternehmen gelebt wird. Vor dem Start des Projekts erstellt der Projektleiter in einem Tabellenkalkulati-onsprogramm 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 ge-sucht. Im Unternehmen sind außerdem verschiedene Datenbanken vor-handen in denen Informationen zu verschiedenen Komponenten und Pro-grammmodulen 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 wer-den an verschiedene Kennzahlen zur Messung der Prozessperformanz er-hoben.

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:

� Die Koordination der Arbeitspakete und Mitarbeiter Aus der Anforderung #1 (Vorschlag der nächsten Arbeitspakete) und Anforde-rung #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 Prozessmanagement-system unterstützt, so muss dies durch einen Projektleiter übernommen wer-den. 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.


Alternativen zu einem Prozessmanagementsystem im Bezug auf die Koordinie-rung 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, über-sprungen oder erneut bearbeitet werden (Anforderungen #2, #3 und #4), muss der der Projektleiter informiert werden und gegebenenfalls zustimmen.

� Bereitstellung von Kontextinformationen Die Anforderungen #5 (Bereitstellen von Informationen über den Arbeits-schritt), #7 (Bereitstellen von Dokumenten und Produktmodellen) und #8 (Un-terstü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 wahr-genommen, so müssen Anwender die notwendigen Aufgaben selbst aus ver-fügbaren Datenquellen (z.B. dem Internet, Büchern oder auch Kollegen) zu-sammensuchen. Als Ergebnis der Suche bekommen die Mitarbeiter hier eine Liste mit Orten, an denen Informationen hinterlegt sein können.

� 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üt-zung von Entscheidungen) ab und ist inhaltlich eng mit der Informationsbe-reitstellungsaufgabe verwandt. Die im Unternehmen verfügbaren Informatio-nen (z.B. in Datenbanken) sollen den Anwendern an einer zentralen Stelle ver-fügbar gemacht werden. Notwendige Konvertierungsoperationen der Daten sollen durch das System automatisch durchgeführt werden.

� Dokumentation der Prozessausführung Schließlich erfüllt das Prozessmanagementsystem auch eine Dokumentations-aufgabe. Dies ergibt sich aus der Notwendigkeit, die ordnungsgemäß Umset-zung der Anforderungen des QM-Standards im Assessment belegen zu müs-sen. Durch das Prozessmanagementsystem kann hier schon während der Durchführung des Prozesses die Verlinkung zu den Anforderungen des QM-Standards hergestellt werden. Ohne IT-Unterstützung müsste dies durch die Mitarbeiter manuell geschehen. Die Mitarbeiter im Projekt müssten selbstän-dig sicherstellen, dass die in den QM-Standards geforderten Arbeitsschritte und Dokumente erstellt werden und diese in einem Assessment auffindbar


sind. Dies kann beispielsweise mittels Protokollen, Checklisten, oder als Anno-tation 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 Meilen-steins, sowie die Entscheidung, ob mit dem Projekt fortgefahren wird (Anfor-derung #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:

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 IT-Unterstü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.

Anforderungen

Anwender

QM-Standard

Umsetzung im Unternehmen

ProcessNavigator

Datenbanken

Umsetzung QM-Anforderungen

Koordination

Informations-bereitstellung Dokumentation

Datenintegration

Werkzeuge

Mitarbeiter

Arbeitspakete

Arbeits-abläufeDokumente

Unternehmens-wissen

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

5 Entwurf eines Vorgehensmodells zur Umsetzung von QM-Anforderungen

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 Prozesslebenszyk-lus 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 vorgege-ben, 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 Verbesse-rung 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 QM-Standards 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 Verbesserungs-kreis. Auf der dort beschriebenen Grundidee basiert ein Großteil der betrieblichen Verbesserungsansätze. Der PDCA-Zyklus besteht aus den folgenden Phasen:

� Planen (Plan): Festlegen der Ziele und Planung des Prozesses;

� Durchführen (Do): Umsetzung und Ausführung des Prozesses;

� Prüfen (Check): Überwachung und Messung der Prozesse und Produkte;

� Verbessern (Act): Ergreifen von Maßnahmen zur Verbesserung der Prozessleis-tung.

80 5 Entwurf eines Vorgehensmodells zur Umsetzung von QM-Anforderungen

Dieser Zyklus bildet die Grundlage für eine Vielzahl von Prozessverbesserungsansät-zen und QM-Systemen. In ihm ist die Grundidee der Prozessverbesserung beschrie-ben: beginnend mit der Planung des Prozesses, über seine Implementierung, Mes-sung 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 ausgear-beitet (Phase 2). In Phase 3 wird schließlich der definierte Prozess betrieben, über-wacht 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.

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-

Prozesslandschaft

Phase 2: ProzessdefinitionPhase 4: Monitoring

Phase 3: Betreiben, steuern und optimieren

Phase 1: Aufnahme

und Integration


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 wer-den im Rahmen dieser Arbeit die beiden Begriffe Monitoring und Controlling wie folgt genutzt:

Projekt-Monitoring oder Monitoring bezeichnet die in einem „kleinen“ Re-gelkreis beschriebene Rückkopplung von Laufzeitinformation zur Steuerung einer Prozessinstanz. Ziel ist es, während der Projektdurchführung Abwei-chungen 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 Verbesse-rungsvorschlä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 Prozessle-benszyklus 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 Verwal-tung und Überwachung der vorhandenen Prozesse. Die Phase 4 wird im Vergleich zum einfachen Prozesslebenszyklus lediglich um eine Assessment-Unterstützung er-


weitert, die im Hinblick auf die in den QM-Standards vorhandenen Assessments von Bedeutung ist.

Abbildung 5-2: 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 Definitions- und 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 zusam-mengefassten Aufgaben in zwei getrennte Phasen aufgeteilt. Wichtig ist zu erwäh-nen, dass die beiden Phasen 3.1 und 3.2 nicht aufeinanderfolgend, sondern parallel

Phase NEU: Projektdefinition

Prozesslandschaft

Phase 2: ProzessdefinitionPhase 4: Controlling & Assessment-Unterstützung

Phase 1: Aufnahme und

Integration

Phase 3: Betreiben, steuern und optimieren

Phase 2: Prozessdefinition

Phase NEU.2: Projektvalidierung

�

��

�

Phase 3 : Projektdurchführung

Phase 2.2: Prozessvalidierung

��

�

�

Phase 2.1: Erstellung des Prozesstyps

Phase 3.1: Projektbearbeitung Phase 3.2: Projektmonitoring Phase NEU.1: Erstellung des Projektplans


ausgeführt werden. Somit kann das Projektmonitoring jederzeit aktiv in die Projekt-durchfü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 Anforderun-gen 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.

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.

Phase 3: Projektdefinition

Prozesslandschaft

Phase 5: Controlling &Assessment-Unterstützung


Integration


Phase 3.2: Projektvalidierung�

�

�

�

Phase 4: Projektdurchführung

Phase 2.2: Prozessvalidierung

�

� �

�

�

Phase 2.1: Erstellung des Prozesstyps

Phase 4.1: Projektbearbeitung Phase 4.2: Projektmonitoring Phase 3.1: Erstellung des Projektplans

Vorgehensmodell zur QM-Umsetzung


In der Konstruktion wird jeweils das Produkt (Prozesstyp, Projekttyp bzw. Artefakte) erstellt, welches anschließend in der Analyse hinsichtlich der Umsetzung von Anfor-derungen aus dem QM-System bzw. hinsichtlich der im Projektplan definierten Soll-Vorgaben untersucht wird. Somit kann jede einzelne Phase hinsichtlich der Umset-zung der Vorgaben aus dem QM-System abgesichert werden.

Die folgenden Kapitel 7 bis 10 diskutieren die Phasen des Vorgehensmodells abbil-den:

1. Aufnahme, Integration und Prozessdefinition (Phase 1 und 2) � Kapitel 7

2. Projektdefinition (Phase 3) � Kapitel 8

3. Projektdurchführung (Phase 4) � Kapitel 9

4. Controlling und Assessment-Unterstützung (Phase 5) � Kapitel 10

Durch die beschriebenen Phasen ist das Vorgehensmodell zur Umsetzung von QM-Anforderungen vollständig beschrieben. Er erweitert den einfachen Prozesslebens-zyklus 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 Vorgehensmo-dells zur Umsetzung von QM-Anforderungen vorgestellt. Bevor diese Detailbetrach-tung 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 Reifegradstu-fen 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 Umsetzung im Vorgehensmodell

Art der Umsetzung

Ziel 1.1

Umsetzen der Prozessschritte

Phase 2.2 Prozess-validierung, Phase 3.2 Projekt-validierung sowie Phase 4.1 Projekt-bearbeitung

Validierung der Prozessty-pen und des Projekttyps im Hinblick auf eine Umset-zung der geforderten Praktiken und Arbeitspro-dukte sowie die Ausfüh-rungsunterstützung im ProcessNavigator

Ziel 1.2

Erstellen der geforderten Arbeitsergebnisse

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 QM-Anforderungen, 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 Prozessaus-fü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 Entscheidungsbe-fugnisse 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.


RG 2


Art der Umsetzung

Ziel 2.1

Planung des Projekts

Phase 3.1 Erstellung des Projektplans

Entwicklung des Projekt-typs aus dem Prozesstyp

Ziel 2.2

Definition von Zielen und Entscheidungs-befugnissen für die Prozess-ausführung

Festlegung von Zielen und Entscheidungsbefugnissen im Projektplan

Ziel 2.3

Allokation von Ressourcen

Festlegen des Organisatori-schen und Operationalen Aspekts im Projekttyp

Ziel 2.4

Definition der Schnittstellen zwischen Parteien

Festlegung von Besprechungsterminen und E-Mail-Verteilern im Projektplan

6 Ausblick: Umsetzung der QM-Anforderungen im ProcessNavigator 87

RG 2


Art der Umsetzung

Ziel 2.5

Definition der Anforderungen an Arbeits-produkte


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

Ziel 2.6

Überwachung und Steuerung des Projekts

Phase 4.1 Projekt-bearbeitung und Phase 4.2 Projekt-monitoring

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

2.7 Überwachung und Korrektur der Arbeitspro-dukte

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 Bearbeitungszu-stand zu verfolgen und bei Abweichungen steuernd eingreifen zu können.


RG 3


Art der Umset-zung

Ziel 3.1

Aufstellung eines Stan-dardprozesses und seiner Schnittstellen

Phase 2.1 Erstellung des Prozesstyps und Phase 2.2 Prozess-validierung

Definition der Prozesstypen

Ziel 3.2

Festlegen der Zuständig-keiten, Verantwortlichkei-ten und der nötigen Infrastruktur im Stan-dardprozess

Definition des Organisatorischen und Operationalen Aspekts im Prozesstyp


RG 3


Art der Umset-zung

Ziel 3.3

Ableitung eines Projekts aus dem Standardprozess


Tailoring des Projekttyps aus dem Standard-Prozesstyp

Ziel 3.4

Festlegung der im Projekt eingesetzten Verantwort-lichkeiten und der Infrastruktur

Ziel 3.5

Definition von Methoden zur Messung des Stan-dardprozesses

Festlegung von Kennzahlen, die im Projekt ermittelt werden sollen

Ziel 3.6

Erfassung der Daten und Ermitteln von Verbesse-rungspotenzialen

Phase 4.1 Projekt-bearbeitung und Phase 4.2 Projekt-monitoring

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üh-rung) 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 Unter-nehmen 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 Prozess-Tailoring in einen Projekttyp abgeleitet. Dabei ist es wichtig, dass dieses Tailoring systematisch und basierend auf vorher festgelegten Regeln durchgeführt wird. Es muss eine geeignete Projektinfrastruktur bereitgestellt und die Verantwortlichkeiten im Projekt festgelegt werden. Zur Messung des Prozesses sind geeignete Methoden zu definieren.

Der ProcessNavigator unterstützt die Durchführung des auf einem Standardprozess basierenden Projekts durch die Bereitstellung von Informationen für die Mitarbeiter.

6 Ausblick: Umsetzung der QM-Anforderungen im ProcessNavigator 89

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


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 Control Phasen des Six Sigma Ansatzes.

Ziel 4.2 Identifikation von Messpunk-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 Korrektur-maß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.



RG 5

Ziel Beschreibung Art der Umsetzung

Ziel 5.1 Definition der strategischen Verbesserungsziele


Ziel 5.2 Analyse der Daten

Ziel 5.3 Identifikation von Gründen für Abweichungen

Ziel 5.4 Erarbeiten von Verbesse-rungsmöglichkeiten


Ziel 5.5 Entwickeln einer Umset-zungsstrategie

Ziel 5.6 Umsetzen der Verbesserun-gen

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 Prozess-landschaft 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 Prozessmodellie-rungssprache 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 [Hand-buch 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 beschrie-benen 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.

Abbildung 7-1: 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 Modellie-rung des Prozesstyps genutzt werden. Auf diese Weise entstehen die Modellierungs-elemente 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] verwie-sen.

In Tabelle 7-1 werden die in dieser Arbeit genutzten Modellierungselemente zusam-menfassend 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

partitioniert

Knotenart

Knoten Port

Portart

partitioniert

Flussart

Fluss

partitioniert

Eingangsports*Ausgangsports*

Knotenanhang Datenquelle

Datenquelle 1

anhänge*

Quelle1Ziel

1

fließt *

aggregierterKnoten

*

Prozessschritt

StartInterface

Konnektor

LogischerKonnektor

EntscheiderKonnektor

AND OR XOR

Kontrollfluss

Datenfluss

M3

Anwendung

Organisation

Datencontainer

Datenreferenz

<<instanceOf>> <<instanceOf>>

StopInterface

<<instanceOf>>M2

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

Verhaltens-orientierter Aspekt

Datenorientier-ter Aspekt

Organisatorischer Aspekt

Operationaler Aspekt

Phase Kontrollfluss Datenfluss Organisation Anwendung (Werkzeug)

Meilenstein Entscheider Datencontainer

Prozess-baustein (Arbeitspaket)

Logische Konnektoren (AND, OR, XOR)

Start- und StopInterface

Externer Ein- und 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.


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

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:

� Schritt 1: Prozessidentifikation und Abgrenzung;

� Schritt 2: Analyse der Ist-Prozesse;

� Schritt 3: Konzeption der Soll-Prozesse;

� (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 Unterneh-men 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 Prozess-klassen „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 Lebenszykluspro-zesse) 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.


Abbildung 7-2: 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 Produk-tentwicklungsprozess wurde ein an das V-Modell XT [Höhn et Höppner 2008; V-Modell XT (Version 1.3)] angelehnter Softwareentwicklungsprozess gewählt. Dieser umfasst, wie in Abschnitt 2.2 gezeigt, schon einen wesentlichen Teil der Anforderun-gen aus den QM-Normen ISO/IEC 15504 bzw. CMMI und bildet damit für die Soft-wareentwicklung 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

Management-Prozesse

Unterstützungsprozesse

Geschäftsprozesse

Messung, Analyse und Verbesserung

Produkt managen

Kundenzufriedenheit ermitteln Prozesse messen Interne Audits

durchführenKontinuierlich

verbessern

Beschaffung durchführen

IT zur Verfügung stellen

Infrastruktur zur Verfügung stellen Lager bewirtschaften

Personal entwicklen Kommunikation durchführen

Marketing durchführen

Unternehmen organisieren

Softwareentwicklungsprozess

Kund

en /

Anf

orde

rung

en

Prod

ukte

/ K

unde

n

Unternehmen steuern Operativ planen Controlling betreibenStrategisch planen

Administration durchführen Prüfmittel überwachen Abfallwirtschaft

betreiben


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:

� Funktionaler Aspekt

Der Funktionale Aspekt beschreibt den strukturellen Aufbau des Prozessmo-dells. Ihr wichtigster Bestandteil sind Prozessschritte. Diese können wiederum aus weiteren Prozessschritten bestehen und bilden dann komposite Prozess-schritte.

� Verhaltensbezogener Aspekt

Dieser definiert die kausale Abfolge der Arbeitsschritte. Im Wesentlichen wer-den also die Vorgänger- und Nachfolgebeziehungen zwischen den Arbeits-schritten definiert und Entscheidungen formuliert.

� Datenorientierter Aspekt Dieser Aspekt definiert die Daten oder Produktmodelle, die im Produktent-wicklungsprozess genutzt werden. Hierunter werden alle Daten oder Informa-tionen (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 Eingangs-dokument benötigt wird. Somit definiert der Datenorientierte Aspekt auch den Datenfluss im Prozess.

� Organisatorischer Aspekt Er beschreibt, wer in einem Prozessschritt für die Ausführung der darin be-schriebenen Arbeiten verantwortlich ist.

� Operationaler Aspekt Dieser Aspekt beschreibt die im Prozess zum Einsatz kommenden Werkzeuge und Systeme. In der Produktentwicklung sind dies beispielsweise CAD Pro-gramme, 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.


Wenn die fünf Basisaspekte nicht ausreichen, um die Anforderungen des Unterneh-mens 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.

Abbildung 7-3: 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 „System-elemente 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.

Feinentwurf abgeschlossen

Angebot abgegeben

Iteration geplant

System spezifiziert

Projekt genehmigt

System integriert

Systemelemente realisiert

Projekt abgeschlossen

Abnahme erfolgt

Lieferung durchgeführt

Projekt definiert

System entworfen

Projekt beauftragt


Abbildung 7-4: Prozesstyp Detail

Prozesstypne

inja ne

in ja

Testa

nford

erun

gen

Fehle

r in S

oftwa

remo

dulen

Detai

ldesig

n Soft

ware

Schn

ittstel

lenbe

schr

eibun

g (De

tail)

Eing

ang

Teste

rgeb

nisse

Softw

are M

odule

Teste

rgeb

nisse

Fehle

r in S

oftwa

remo

dulen

Nutze

rdok

umen

tation

Testa

nford

erun

gen

Fehle

r im D

etaild

esign

Teste

rgeb

nisse

Softw

are M

odule

Detai

ldesig

n Soft

ware

Tests

erfol

greic

h

Detai

ldesig

nmu

ssüb

erar

beite

twe

rden

Fehle

r im D

etaild

esign

Teste

rgeb

nisse

Fehle

r aus

Integ

ratio

nstes

t4

Softw

are M

odule

Nutze

rdok

umen

tation

Softw

are M

odule

Fehle

r im D

etaild

esign

Teste

rgeb

nisse

Softw

are M

odule

Softw

are M

odule

Teste

rgeb

nisse

Detai

ldesig

nüb

erar

beite

n1

Teste

rgeb

nisse

Testa

nford

erun

gen

Ausg

ang

Schn

ittstel

lenbe

schr

eibun

g (De

tail)

Softw

areT

estsu

ite

Schn

ittstel

lenbe

schr

eibun

g (De

tail)

Fehle

r im D

etaild

esign

Detai

ldesig

n Soft

ware

Fehle

r ana

lysier

en

- / -

[...]

Teste

rgeb

nisse

bewe

rten

- / -

[...]

Entw

icklun

g der

Lösu

ngsk

ompo

nente

n- /

-En

twick

ler

IDE

Entw

icklun

gsum

gebn

ung

defin

ieren

- / -

Entw

ickler

Doku

menta

tion

aktua

lisier

en- /

-En

twick

ler

Edito

r

Entw

icklun

g der

Testk

ompo

nente

n- /

-Te

ster

[...]Sy

stemk

ompo

nente

ntes

ten- /

-Te

ster

Testu

mgeb

ung

Teste

rgeb

nisse


Nach Abschluss der Prozessdefinitionsphase existiert im Unternehmen eine modell-basierte Beschreibung des Entwicklungsprozesses und der notwendigen Unterstüt-zungsprozesse. Es ist nicht erforderlich, alle in der Norm geforderten Prozesse von Beginn an zu definieren, sondern die Prozesslandschaft kann auch sukzessive erwei-tert 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 Unter-nehmen 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 stattgefun-den. Diese Validierung ist jedoch aus Sicht des Qualitätsmanagements ein wesentli-cher 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 ge-macht. Durch die Struktur der beiden QM-Standards können Unternehmen grund-sä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 Zweifels-fall 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 unter-stützt beispielsweise der Prozess „SUP.1 Quality assurance“ aus der ISO/IEC 15504


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 Prozes-sen (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 Prozessschrit-te) und 1.2 (Erstellen der geforderten Arbeitsergebnisse) sowie die Ziele 3.1 (Aufstel-len eines Standardprozesses und seiner Schnittstellen) und 3.2 (Festlegen der Zuständigkeiten, Verantwortlichkeiten und der nötigen Infrastruktur im Standardpro-zess) 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 QM-Norm (hier die aQM2-Ziele) mit der tatsächlich im Prozesstyp vorhandenen Umset-zung, 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 Projektmana-gement betreffen, sind sie bei der Definition und Validierung des Prozesstyp nicht von Bedeutung; sie werden in späteren Phasen des Lebenszyklus betrachtet.

Abbildung 7-5: Abbildung des QM-Referenzmodells auf die Basisaspekte

Unternehmensprozess QM-Standard

Prozessschritt

Prozessschritt

Datenelement

Werkzeuge und Operationen

Organisation

QM-Modell

Prozesse

Arbeitsergebnisse


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 aufei-nander abgebildet werden. Ein Prozessschritt kann demnach aus weiteren Prozess-schritten aufgebaut sein (kompositer Prozess); außerdem werden einem Prozess-schritt Datenelemente (Ein- und Ausgabedaten), Organisationen und Werkzeuge zugeordnet. Ein QM-Standard referenziert verschiedene Prozesse (bzw. Prozessgebie-te); 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 Datenelemen-te 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-


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.

Abbildung 7-6: Abbildung der Prozessschritte auf die ISO 15504

Um den Nutzer bei der Modellierung der Prozesse und der Zuordnung der Anforde-rungen zu unterstützen, ist eine direkte Unterstützung der QM-Standards im Pro-zessmodellierungswerkzeug 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 Modellie-rung der Prozesse realisiert werden. Abbildung 7-7 zeigt, wie diese Abbildungsfunkti-on 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än-diges Bild, wie die Anforderungen der QM-Referenzmodelle auf Ebene 1 im Unter-nehmen abgebildet werden.

neinja

nein

ja

Testanforderungen

Fehler in Softwaremodulen

Detaildesign Software

Schnittstellenbeschreibung (Detail)

Eingang

Testergebnisse

Testergebnisse

Software Module

Fehler in SoftwaremodulenTestanforderungen

Fehler im Detaildesign

Testergebnisse

Software Module


Testserfolgreich

Detaildesignmuss

überarbeitetwerden


Testergebnisse

Fehler ausIntegrationstest

4

Software Module

Nutzerdokumentation


Testergebnisse

Software Module

Software Module

Testergebnisse

Detaildesignüberarbeiten1

Testergebnisse

Testanforderungen


Software T estsuite




Testergebnissebewerten

- / -[...]

Entwicklung derLösungskomponenten

- / -Entwickler

IDE

Entwicklungsumgebnungdefinieren

- / -Entwickler

Dokumentationaktualisieren

Entwickler

Editor

Entwicklung derTestkomponenten

- / -Tester

[...]

Systemkomponententesten

- / -Tester

T estumgebung

ENG.6 Software construction

ENG.6.BP1: Develop unit verification

procedures

ENG.6.BP2: Develop software units

ENG.6.BP3: Ensure consistency

ENG.6.BP4: Verify software units

Prozesstyp QM-Standard


Abbildung 7-7: 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 Modellie-rer dort eine Checkliste anzubieten, in der die noch fehlenden Prozesse angezeigt werden. Andererseits kann diese Auswertung auch in einem externen Tool durchge-führt werden. Diese Alternative ist in Abbildung 7-8 dargestellt. In der dort dargestell-ten Web-basierten Anwendung wird die Abbildung der Arbeitsschritte auf die Base Practices der ISO/IEC 15504 vorgestellt. Analoge Auswertungen sind für die Abbil-dung 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:

� „Werden alle Base Practices im Unternehmensprozess abgebildet?“;

� „In welchen Arbeitsschritten meines Prozesses werden welche Work Products erstellt?“;

� „Welche Organisation im Unternehmen ist für die Erstellung des Work Pro-ducts XY verantwortlich?“.


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 QM-Standards zu validieren. Hieraus ergibt sich auch die Anforderung an das Speichersys-tem, in dem das Prozessmodell abgelegt wird, allgemeine Auswertungen einfach zu ermöglichen. Wie in Kapitel 12 gezeigt wird, ist dies im ProcessNavigator durch einen RDF-Triple Store umgesetzt.

In Tabelle 7-2 wird die Umsetzung der Anforderungen des aQM2 nochmals in einer Übersicht zusammengefasst:

Tabelle 7-2: Umsetzung der QM-Anforderungen im Prozesstyp

RG 1

Ziel 1.1: Umsetzen der Prozessschritte Validierung der Prozesstypen im Hinblick auf eine Umsetzung der geforderten Praktiken und Arbeitsprodukte



RG 3

Ziel 3.1: Aufstellen eines Standard-prozesses und seiner Schnitt-stellen

Definition der Prozesstypen

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

Definition des Organisatorischen und Operationalen Aspekts im Prozesstyp

Nach Abschluss der Definition und Validierung des Prozesstypen steht im Unterneh-men 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 Unterneh-mensprozesse 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 weiterverwen-den 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 Projektschrit-te. Projektschritte (oder Projektbausteine) sind eine Spezialisierung des Elements Prozess aus dem Prozess-Meta-Modell (Abbildung 7-1). Durch diese Spezialisierungs-beziehung können alle im Prozesstyp enthaltenen Prozessschritte direkt in Projekt-schritte 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 Prozessschrit-te im Prozesstyp. Daten- und Kontrollflüsse definieren weiterhin bestehende Abhän-gigkeiten 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.

Abbildung 8-1: 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.

partitioniert

Knotenart

Knoten Port

Portart

partitioniert

Flussart

Fluss

partitioniert

Eingangsports*Ausgangsports*

Superknoten

Knotenanhang Datenquelle

Datenquelle 1

anhänge*

Quelle1Ziel

1

fließt *

aggregierterKnoten

*

Prozessschritt

StartInterface

Konnektor

LogischerKonnektor

EntscheiderKonnektor

AND OR XOR

Kontrollfluss

Datenfluss

M3

Anwendung

Organisation

Datencontainer

Datenreferenz

<<instanceOf>> <<instanceOf>>

StopInterface

<<instanceOf>>M2

Projektschritt


Tabelle 8-1: Änderungen im Projektmodell im Vergleich zum Prozessmodell

Aspekte Prozessmodell Projektmodell

Funktionaler Aspekt Phase

Meilenstein

Prozessbaustein Projektbaustein

Verhaltensorientierter Aspekt

Kontrollfluss

Entscheider

Kontrollfluss-konnektoren (AND, OR, XOR)

Prozessstart und -ende


Datenorientierter Aspekt

Datenfluss

Datenelement


Organisationseinheit Mitarbeiter

Operationaler Aspekt Werkzeug Ressource

Wie schon beim Prozess-Meta-Modell erlaubt auch die Darstellung des Projektmo-dells als Meta-Modell die einfache Anpassung an neue Gegebenheiten und Anforde-rungen. 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-


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:

� Die Reduzierung der Unsicherheit im Bezug auf die Projektdurchführung;

� das Erreichen eines besseren Verständnisses der Ziele (Kosten, Termine und Budget) im Projekt;

� die Strukturierung und das Abgrenzen von Arbeitspaketen;

� die Überprüfung, ob die Vorgaben des Auftraggebers realistisch sind;

� das Wissen, welche Fachspezialisten (mit einem definierten Know-how) zu wie viel Prozent für das Projekt zur Verfügung stehen;

� das frühzeitige Erkennen von Ressourcenengpässen oder Konflikten im Pro-jekt;

� das rechtzeitiges Ergreifen von Maßnahmen zur Behebung von Engpässen, insbesondere im Bezug auf Personen, Finanzen oder Maschinen;

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

� Was wird gemacht?

� Wie wird es gemacht?

� Wo bzw. wer ist dafür verantwortlich?

� Wann muss es fertig sein?

� 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


wird das Vorgehen in zwei Planungsphasen unterschieden: eine Grob- und eine Detailplanungsphase. Im Bezug auf das AOPM wird bei der Grobplanung insbesonde-re 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 Projekt-plans 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,


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 verschie-dene Ansätze und Verfahren zur Anpassung von Prozessen an Projekte aus der Literatur vorgestellt.

[Pedreira et al. 2007] gibt einen systematischen Überblick über vorhandene Publika-tionen. Die Autoren stellen fest, dass obwohl die Anpassung der Unternehmenspro-zesse 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:

� Anpassungsebene des Prozessmodells: Die Anpassung eines allgemeinen Pro-zesses (Prozess-Standard) an die Gegebenheiten der Organisation oder die Anpassung eines Organisationsprozesses an die Gegebenheiten des Projekts.

� Grad der Formalität: Formale Vorschriften oder informale Richtlinien bei der Anpassung des Prozesses an das Projekt.

� 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 verkraf-ten 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ßunter-nehmen [Fitzgerald et al. 2003]. Alle diese Ansätze gehen davon aus, dass im Unter-nehmen ein baukastenartig strukturiertes Prozessmodell vorhanden ist; im Fall des V-


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 Prozesscha-rakteristika (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 Prozess-schritte 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 Projektab-laufbeschreibung 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 einzel-nen 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.


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 Organisa-tionseinheit), 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 an-schließend in einen vollständigen Projektplan weiterentwickelt wird. Dieser Abschnitt stellt die notwendigen Schritte vor und beschreibt, wie die im Prozesstyp vorhande-nen 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 Grob- und 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 Validie-rungsphase (Phase 3.2) überprüft und angezeigt. Diese Abweichungen können anschließend durch den Projektleiter korrigiert werden. Das Vorgehen zur Grobpla-nung 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 Do-kumente verantwortlich ist. Die im Plan enthaltenen Meilensteine und die dort fertigzustellenden Dokumente richten sich maßgeblich nach der Art des Pro-jekts. So kann etwa bei In-House-Projekten auf ein formales Angebotsverfah-ren 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 Erforder-nisse des Projekts abgestimmt. Die Festlegung der Meilensteine wird durch


den Projektleiter vorgenommen und das Ergebnis ist ein definierter Meilen-steinplan.

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 Anforderungs-erhebung bei komplexen Projekten deutlich von der bei einfachen Projekten unterscheiden; so müssen bei komplexen Projekten die Anforderungen aus-führlicher geprüft werden als bei einfachen Projekten. Je nach Projekttyp wer-den nun in den Meilensteinplan jene Typvarianten eingefügt, die der Projekt-struktur entsprechen.

Abbildung 8-2: 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 Va-rianten des Prozesstyps konfiguriert wird, hat der Projektleiter an dieser Stelle nochmals die Möglichkeit einzelne Arbeitspakete zu detaillieren oder zu über-arbeiten. Ziel dieses Schrittes ist es, geringfügige Ungenauigkeiten oder Stel-

RichtlinienTabellen

Anforderungenerheben

Grobkonzepterstellen

Pro

zess

-m

odel

lP

roje

kt-

mod

ell

Tailo

ring

GrobkonzeptVariante 2

GrobkonzeptVariante 1

AnforderungenVariante 1




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 er-zeugt wird, und wie lange diese zur Bearbeitung benötigen. Dazu werden die Experten und Mitarbeiter aus den Fachabteilungen angefragt und deren Schät-zung 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 Ar-beitspakete und deren Ablaufplanung. Für jeden Meilenstein kann somit er-rechnet 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 vorzuschla-gen, die die beschriebenen Arbeitspakete umsetzen können. Die gemeldeten Mitarbeiter werden im Projektplan als verantwortliche Mitarbeiter eingetra-gen. 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 Arbeits-paketen zu Mitarbeitern in die Projektdurchführungsphase (Abschnitt 9.1) ver-schoben.

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.


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 Modellvari-anten ausgewählt, die auf das aktuelle Projekt zutreffen. Im V-Modell XT wird hier beispielsweise die folgenden Parameter abgefragt: „Ist ein kaufmännisches Projekt-management notwendig?“, „Müssen Messungen und Analysen durchgeführt wer-den?“, „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 nachvollzieh-barer 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 Prozessbau-steine – im Fall des V-Modell XT Vorgehensbausteine – in das Projekt aufgenommen oder aus diesem entfernt.


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 vorhan-denen 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 Netzplan-technik 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ßer-dem 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.


Der Projektbaustein besitzt die folgenden Attribute:

� Voraussichtliche Dauer Gibt die durch den Projektleiter in Rücksprache mit den Mitarbeitern angege-bene voraussichtliche Dauer der Aktivität an. Im Fall eines kompositen Pro-jektbausteins ergibt sich diese aus der Errechnung des Kritischen Pfades seiner Teilaktivitäten automatisch.

Abbildung 8-4: Darstellung Projektbausteintyp

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

� 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 Pro-jektende (bzw. der Vateraktivität) ermittelt.

Außerdem bestehen Verknüpfungen zu den folgenden Aspekten:

� Verantwortlicher Mitarbeiter (Organisatorischer Aspekt) Statt der im Prozessplan angegeben Rollenbeschreibung wird im Projektbau-stein der tatsächlich verantwortliche Mitarbeiter eingetragen. Diese Informa-tionen können einerseits in Verbindung mit der voraussichtlichen Dauer dazu genutzt werden, die durch die Aktivität verursachten Personalkosten abzu-schä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.

Frühester Beginn Frühestes Ende

Verantwortlicher Mitarbeiter Aufwand/ Kosten

Spätester Beginn Spätestes Ende

Arbeitspaketname

VoraussichtlicheDauer


� Aufwand/ Kosten Anlog zu der Planung des verantwortlichen Mitarbeiters können weitere Res-sourcen 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 Projekt-bausteine umgewandelt. Hier wurde eine direkte 1:1-Übertragung der Prozessbau-steine 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 QM-Anforderungen überarbeiten und neu definieren. Eine Validierung des Projektmodells findet in Phase 3.2 statt.

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

Fehler in SoftwaremodulenFehler in Softwaremodulen

TestergebnisseSoftware Module

Schnittstellenbeschreibung (Detail)Detaildesign Software


- / -Entwickler

IDE


- / -Entwickler


- / -Tester

[...]


- / -Tester

T estumgebung

Software Module

Schnittstellenbeschreibung (Detail)Detaildesign Software

Software Module

Software T estsuite

Testanforderungen

Testanforderungen



Eingang

Testanforderungen




Eingang

Testanforderungen


Testanforderungen

Detaildesign SoftwareSchnittstellenbeschreibung (Detail)

Testanforderungen

Software T estsuite





Entwicklungsumgebungdefinieren

Prozesstyp Projekttyp


wichtigsten Kommunikationsmittel; er soll maßgeblich zur Identifikation und Vermei-dung 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 Hin-tergrund 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 Infor-mationen

� Planungsinformationen (z.B. die im Projekt vorhanden Meilen-steine)

� 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 In-formationen ü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 Textele-mente in den meisten Fällen projektspezifisch formuliert werden müssen, können die strukturierten Elemente aus anderen im Unternehmen vorhandenen Informations-quellen abgeleitet werden. Dazu bietet sich insbesondere der Projekttyp an. So können die Meilensteine, die Liste der geplanten Aktivitäten, Zusammenhänge


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 Vorge-hensmodells zur QM-Umsetzung abgeschlossen. Aus dem Prozesstyp wurde ein Projekttyp abgeleitet. Dieser baut zwar auf dem validierten Prozesstyp auf, allerdings hat der Projektleiter bei seiner der Definition die Möglichkeit, Änderungen am Typ vorzunehmen. Es ist also nicht gewährleistet, dass alle QM-Anforderungen aus dem Prozesstyp mit in den Projekttyp übernommen werden. Aus diesem Grund ist eine erneute Validierung des Projekttyps nach Abschluss des Tailoring notwendig. Wie schon beim Prozesstyp stellt auch die Validierung des Projekttyps einen wichtigen Arbeitsschritt aus QM-Sicht dar.

Aus den im aQM2 gestellten Anforderungen sind die in Tabelle 8-2 aufgeführten Ziele bei der Validierung des Projekttyps von Bedeutung:

Tabelle 8-2: Umsetzung der QM-Vorgaben im Projektmodell (Ebene 1)

RG 1

Ziel 1.1: Umsetzen der Prozessschrit-te

Validierung des Projekttyps im Hinblick auf eine Umsetzung der geforderten Praktiken und Arbeits-produkte


Zwar wurden diese beiden Ziele schon bei der Validierung der Prozesstypen über-prü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 123

Tabelle 8-3: 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 Entscheidungsbefugnissen für die Prozessausführung

Festlegung von Zielen und Entscheidungsbefugnissen im Projektplan

Ziel 2.3: Allokation von Ressourcen Festlegen des Organisatori-schen und Operationalen Aspekts im Projekttyp

Ziel 2.4: Definition der Schnittstellen zwischen Parteien

Festlegung von Bespre-chungsterminen und E-Mail-Verteilern im Projektplan

Ziel 2.5: Definition der Anforderungen an Arbeitsprodukte

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

RG 3

Ziel 3.3: Ableitung eines Projekts aus dem Standardprozess

Tailoring des Projekttyps aus dem Prozesstyp

Ziel 3.4: Festlegung der im Projekt eingesetzten Verantwortlichkei-ten und Infrastruktur

Ziel 3.5: Definition von Methoden zur Messung des Standardprozesses

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 Ressour-cen), 3.3 (Ableitung eines Projekts aus dem Standardprozess) und 3.4 (Festlegung der im Projekt eingesetzten Verantwortlichkeiten und Infrastruktur) durch das in Ab-schnitt 8.2.2 beschriebene Vorgehen zur Projektdefinition abgedeckt.


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 (Defini-tion 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 Prozess-ausfü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 Arbeitsergeb-nisse 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 Informations-system. Aus diesem Grund werden diese Ziele hier nur am Rand beschrieben.

Mit dem validierten Projekttyp und dem Projektplan sind die für die Projektausfüh-rung 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 be-schlossen. 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 Informati-onssystems. Dieses System (der ProcessNavigator) stellt ein neuartiges Prozessma-nagementsystem 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 Projekt-ziele in der geplanten Zeit und dem vorhandenen Budget umzusetzen; gleichzeitig wird in Phase 4.2 (Projektmonitoring) die Umsetzung im Sinne eines Projektmonito-ring ständig überwacht, um im Fall von Abweichung vom vordefinierten Plan steu-ernd in die Ausführung einzugreifen. Im Gegensatz zu der nachträglichen Validierung der erreichten Ergebnisse in den Phasen 2 (Prozessdefinition) und 3 (Projektdefiniti-on) 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 Informations-systems 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üt-zen, wird im anschließenden Kapitel 9.2 gezeigt.

Ausgehend von den in Kapitel 4 beschriebenen Anforderungen an ein Prozessausfüh-rungssystem soll in diesem Abschnitt das grundsätzliche Lösungskonzept eines IT-Systems zur Unterstützung von Prozessen entwickelt und beschrieben werden. Nach der Beschreibung des grundlegenden Systemkonzepts wird anhand der verschiede-nen Perspektiven der AOPM, ein Lösungskonzept für ein prozessbasiertes Informati-onssystem erarbeitet.

126 9 Projektdurchführung

9.1.1 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üh-ren 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 verschiede-nen Zeitpunkten T1, T2 und T3 abgebildet.

Abbildung 9-1: Workflow-Management-Systeme (Beispiel)

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

T1

T2

T3

Worklists (Arbeitslisten)

Prozess

Müller

Ausfüllen des Reiseantrags (RA Müller)

Meier

Eintragen der Kostenstelle (RA Müller)

Schmidt

Entscheidung über Genehmigung

(RA Müller)

Entscheidung über Genehmigung

- / -

Eintragen der Kostenstelle

- / -

Ausfüllen des Resieantrags

- / - Müller (Mitarbeiter)

Meier (Sekretariat)

Schmidt (Vorgesetzter)

Reiseantrag (überarbeitet)

Reiseantrag


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-Management-System an das Sekretariat weitergeleitet (Zeitpunkt T2). Somit erscheint die Aufgabe Eintragen der Kostenstelle zusammen mit dem Dokument (RA Müller) in der Arbeits-liste 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ührungsreihen-folge 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 Workflow-Management-Systemen realisiert. Sie bilden somit eine gute Ausgangsbasis für die Entwicklung eines Prozessmanagementsystems, welches alle in Kapitel 4 beschriebe-nen 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


der nächsten Arbeitsschritte und in eine Anwendungskomponente (der ProcessNavi-gator-Desktop bzw. PN-Desktop). Abbildung 9-2 zeigt die Umsetzung des ProcessNa-vigators als Web-Anwendung mit der PN-Worklist und dem PN-Desktop. Aus der PN-Worklist können die Mitarbeiter das Arbeitspaket auswählen, welches sie bearbeiten möchten. Nach der Auswahl eines Arbeitspaketes werden im PN-Desktop Informatio-nen 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 wider-sprechen 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“ � „Ent-scheidung ü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üh-rung ist viel zu strikt und würde die Mitarbeiter zu sehr bei der Bearbeitung der Arbeitsschritte einschränken. Entsprechend muss beim Entwurf des neuen Prozess-managementsystems 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.


Abbildung 9-2: 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 interpre-tiert, 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 vorgestell-ten Anforderungen, muss der ProcessNavigator im Vergleich zu klassischen Workflow-Management-System an mehreren Stellen angepasst werden. Die wichtigs-te 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


Angebot abgegeben

Iteration geplant

System spezifiziert

Projekt genehmigt

System integriert

Systemelementerealisi

ert

Projektabgeschlo

ssenAbnahme

erfolgt

Lieferungdurchgef

ührt

Projekt definiert

System entworfen

Projekt beauftragt nein

ja

nein

ja

Testanforderungen




Eingang

Testergebnisse

Software Module

Testergebnisse


Nutzerdokumentation

Testanforderungen


Testergebnisse

Software Module


T estserfolgreich

Detaildesignmuss

überarbeitetwerden


Testergebnisse


4

Software Module

Nutzerdokumentation

Software Module


Testergebnisse

Software Module

Software Module

Testergebnisse


Testergebnisse

Testanforderungen

Ausgang


Software T estsuite




Fehler analysieren

- / -[...]


- / -[...]


- / -Entwickler

IDE


- / -Entwickler


- / -Entwickler

Editor


- / -Tester

[...]


- / -Tester

T estumgebung

Testergebnisse

neinja

nein

ja

Testanforderungen




Eingang

Testergebnisse

Software Module

Testergebnisse


Nutzerdokumentation

TestanforderungenFehler im Detaildesign

Testergebnisse

Software Module


Testserfolgreich

Detaildesignmuss

überarbeitetwerden


Testergebnisse


4

Software Module

NutzerdokumentationSoftware Module


Testergebnisse

Software Module

Software Module

Testergebnisse


Testergebnisse

Testanforderungen

Ausgang


SoftwareTestsuite




Fehler analysieren

- / -[...]


- / -[...]


- / -Entwickler

IDE


- / -Entwickler


- / -Entwickler

Editor


- / -Tester

[...]


- / -Tester

Testumgebung

Testergebnisse

ProcessNavigator

WorklistProcessNavigator

Desktop


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 Abbil-dung 9-3 dargestellt.

Abbildung 9-3: 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 Selekti-onskriterium 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


Angebot abgegeben

Iteration geplantSystem spezifiziert

Projekt genehmigt

System integriert


ProjektabgeschlossenAbnahme erfolgt


Projekt definiert

System entworfen

Projekt beauftragt

neinja

nein

ja

Testanforderungen




Eingang

Testergebnisse

Software Module

Testergebnisse


Nutzerdokumentation

TestanforderungenFehler im Detaildesign

Testergebnisse

Software Module


Testserfolgreich

Detaildesignmuss

überarbeitetwerden


Testergebnisse


4

Software Module

NutzerdokumentationSoftware Module


Testergebnisse

Software Module

Software Module

Testergebnisse


Testergebnisse

Testanforderungen

Ausgang


SoftwareT estsuite




Fehler analysieren

- / -[...]


- / -[...]


- / -Entwickler

IDE


- / -Entwickler


- / -Entwickler

Editor


- / -Tester

[...]


- / -Tester

Testumgebung

Testergebnisse

Segment„Nächste Schritte“

Segment„Design Situation“

Segment„Alle Schritte“

Weitere Segmente

�

�

�

�

�

�

Prozessmodell VorhandeneWorklist-Segmente

WorklistKonfiguration


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 folgen-den Punkten:

� Anzeige von Arbeitspaketen aus dem Gesamtprozess

Durch die Anzeige von Arbeitspaketen aus dem Gesamtprozess kann der Mit-arbeiter frei entscheiden mit welchem Schritt er im Prozess fortfahren will. Insbesondere kann durch diesen Mechanismus erreicht werden, dass Arbeits-pakete ausgelassen (Kapitel 4 – Anforderung #4) oder übersprungen werden können (Kapitel 4 – Anforderung #3).

� Anzeige von schon abgeschlossenen Arbeitspaketen Dieser Mechanismus macht es möglich Arbeitspakete erneut aufzurufen (Kapi-tel 4 – Anforderung #2), auch wenn diese im ProcessNavigator schon als abge-schlossen markiert wurden. Somit können Prozessergebnisse erneut bearbei-tet und korrigiert werden.

� Kompositer Aufbau aus mehreren Segmenten Durch den kompositen Aufbau der Worklist kann der ProcessNavigator sowohl Arbeitspakete des gesamten Prozesses anzeigen als auch eine Navigations-funktionalitä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 An-wender angepasst werden.

� Mehrere Worklist-Konfigurationen Im ProcessNavigator können mehrere Worklist-Konfigurationen verwaltet werden. Dadurch können diese individuell an die Anforderungen der Anwen-der angepasst werden. Über einen Wechsel zwischen den Worklist-Konfigurationen 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 ei-ne Konfiguration „Alle Prozessschritte“ zu erstellen. In der Konfiguration „Mei-ne 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.


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ührungsrei-henfolge der Prozessschritte und die damit verbundene Anwendbarkeit im Projektall-tag. 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 ProcessNavi-gator 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 einge-loggten Nutzer automatisch bestimmt lässt. Aus diesem Projektkontext ergeben sich Anforderungen an den Informationsbedarf des Anwenders. Dieser Bedarf wird im PN-Desktop 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 Produktentwick-lung z.B. Arbeitsanweisungen, Dokumente und Daten, oder Anleitungen zu Werkzeu-gen 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 konfigu-rierbare Worklist und die Bereitstellung von Informationen zum ausgewählten Ar-beitsschritt 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


Umsetzung der Aspekte im ProcessNavigator wurde innerhalb des Forschungsver-bundes 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 Worklist-Segmente in einer Worklist-Konfiguration zusammengefasst. Die Worklist (siehe Abbildung 9-4) setzt sich damit aus den folgenden Segmente zusammen:

� Nächste Schritte (Abbildung 9-4 – �): 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 bear-beitet (durch einen Haken markiert). Entsprechend wird im Segment „Nächste Schritte“ die Aufgabe „Entwicklungsumgebung definieren“ als nächste auszu-fü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).

� Entwicklungssituation (Design Situation) (�): In diesem Segment werden alle Aufgaben angezeigt, die sich im Kontext des aktuellen Arbeitsschrittes befin-den. 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 überar-beiten (Kapitel 4 – Anforderungen #2 und #3). Für die Bestimmung des aktuel-len Entwicklungskontexts können verschiedene Methoden herangezogen wer-den. So werden in Abbildung 9-4 Meilensteine zur Bestimmung der im Seg-ment angezeigten Aufgaben genutzt; alle Schritte zwischen dem letzten abge-


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

Abbildung 9-4: Die Worklist im ProcessNavigator

� Gesamtes Projekt (Alle Schritte) (�): In diesem Segment sind alle Arbeitspake-te des gesamten Projekts enthalten. Die hier enthaltenen Arbeitsschritte wer-den 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 – umge-setzt. Die in den drei Segmenten angezeigten Ausschnitte aus dem Gesamtprozess ergeben eine klare Reihenfolge für die Auswahl durch den Mitarbeiter: Erstens die


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; stattdes-sen 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 ange-deutet wurde, kann die feste Fenstergröße zur Bestimmung der im Segment abgebil-deten 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 Wahr-scheinlichkeit aufgerufen werden. Durch das Modellierungselement Projektphase (Phase) werden Arbeitsschritte im Prozessmodell zusammengefasst, die einen bestimmten gemeinsamen Zweck verfolgen (z.B. die Erstellung einer Softwarearchi-tektur). 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; anderer-seits 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öglich-keit, um die im Segment „Entwicklungssituation“ enthaltenen Arbeitspakete festzule-gen.

Nach der Auswahl einer Aufgabe aus der Worklist wird zunächst der Reiter „Informa-tionen“ (Abbildung 9-5) im Desktop-Bereich des ProcessNavigators angezeigt. Mitarbeiter erhalten hier Informationen (z.B. Arbeitsanweisungen) über die Ausfüh-rung 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


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 getroffe-nen Entscheidungen und die Projektdurchführung einfach nachzuvollziehen. Diese In-formationen werden in Phase 5 des Vorgehensmodells genutzt, um Verbesserungs-mö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-


tätsstand besitzen. In Abbildung 9-6 ist die Umsetzung von Meilensteinen im Pro-cessNavigator 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 Projektlei-ter) 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-


dung kann zusätzlich in einem Textfeld begründet werden, um später die Entschei-dung 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 Konfigurationsmanage-mentwerkzeugs 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, anderer-seits 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 Anforderun-gen 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 Dokumentations-aufgabe. 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.


Tabelle 9-1: 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 Projekt-leiters bei der Entschei-dungsfindung mit dem Erreichen eines Meilenstei-nes.

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 beeinflus-sen 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. Kontroll-flusskonnektoren haben die Funktion von Split- oder Merge-Operatoren; entspre-chend 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 Entschei-dungen 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 Entwicklungsprojek-te 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


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.

Abbildung 9-7: 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 an-gezeigt; nach Abschluss von „B“ wird „D“ angezeigt. Der Nutzer hat hier kei-ne Auswahlmöglichkeit und wird der Reihe nach durch die Arbeitsschritte geleitet.

Prozessmodell Worklist – Nächste Schritte

B

C

AND

A B

C D

C

B

C

XOR

A B

C D

D

A B B

D D

SEQUENZ

B

C

OR

A B

C D

C

D


AND: Dieses Beispiel zeigt die Aufspaltung des Prozesses in zwei parallele Ausfüh-rungssträ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 ers-tes „B“ ausgewählt, entsprechend ist als nächstes „C“ in der Worklist einge-tragen.

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“, ausge-fü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 Gegen-satz 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 Doku-mentation der Gründe, die zur Entscheidung geführt haben, ist nicht vorge-sehen. Aus diesem Grund wird dies auch als implizite Entscheidung bezeich-net.

OR: Ein OR-Konnektor ist eine Mischform aus einem AND- und einem XOR-Konnektor. Die Bedeutung des Konstrukts ist die folgende: „Mindestens ei-ner der nachfolgenden Arbeitsschritte muss ausgeführt werden“. Der Nut-zer hat wieder die Auswahl zwischen den beiden Schritten „B“ und „C“. Nach der Ausführung von einem der beiden Schritte kann er jedoch ent-scheiden, 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“ eingetra-gen. 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 ausgegan-gen, 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 Worklist-Segmente „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 Prozessmanagement-systeme werden also durch den Kontrollfluss nicht verletzt.


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 Entschei-dung 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ün-dung 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 Prozess-start 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


der Prozessausführung unterscheiden sie sich dabei nicht von normalen Kontroll-flusskanten.

In der nachfolgenden Tabelle 9-2 werden die Elemente des Verhaltensorientierten Aspekts nochmals zusammenfassend dargestellt.

Tabelle 9-2: Umsetzung der Elemente des Verhaltensorientierten Aspekts


Kontrollfluss Festlegung des Ablaufs der Arbeitspakete im ProcessNavigator

Kontrollfluss-konnektoren (AND, XOR, OR)

Entscheider Darstellung der Entschei-dungsalternativen im ProcessNavigator

Prozessstart und -ende –


–

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 Arbeits-schrittes 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-Management-System 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 Verwei-se auf einen Speicherort. Dieses Konzept erlaubt es dem ProcessNavigator sehr flexibel auf Änderungen in der Ausführungsreihenfolge zu reagieren. Während in


BPEL-Systemen der Nachrichtenfluss und somit auch der Kontrollfluss fest im Ausfüh-rungssystem 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 PN-Worklist 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 Entwicklungsprozes-ses in einem externen System. Durch die Verwendung von Verweisen auf den externen Speicherplatz der Daten können im ProcessNavigator verschiedene Daten-haltungskomponenten (z.B. Konfigurationsmanagementsysteme, Dokumenten-managementsysteme oder PDM-Systeme) für den Nutzer transparent eingebunden werden.

Abbildung 9-9: Anzeige von Daten und Dokumenten im ProcessNavigator


In Abbildung 9-9 ist die Umsetzung des Datenorientierten Aspekts im ProcessNaviga-tor abgebildet. Die im Prozesstyp enthaltenen Daten und Dokumente werden im Reiter „Dokumente“ dargestellt. Dieser ist unterteilt in einen Abschnitt Eingangsdo-kumente 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. Ausgangs-dokumente 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 Standardkontroll-fluss, 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 Process-Navigator geladen und bearbeitet werden. Außerdem werden vorhandene Doku-menteigenschaften 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.


Zum Import von Dokumenten in den ProcessNavigator stehen verschiedene Möglich-keiten 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 Anwen-dung Dokumente direkt in den ProcessNavigator importieren. Da diese direkte Integration der Anwendungen mit dem ProcessNavigator die Erstellung von speziel-len 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 Spei-cherort hinterlegt werden.

Im Produktentwicklungsprozess kann es vorkommen, dass während der Prozessaus-fü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 vorhande-nen 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.


Im Prozessmodell kann zwischen optionalen und zwingenden Dokumenten unter-schieden werden. Optionale Dokumente sind solche, die zwar im Prozesstyp vorgese-hen, aber für eine Bearbeitung nicht zwangsläufig erforderlich sind. Zwingende Dokumente hingegen sind im Prozesstyp erforderlich und müssen durch den Anwen-der 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 entspre-chende 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


Datenelement Anzeige als Eintrag im Abschnitt Dokumente des ProcessNavigators

Datenfluss Identifiziert ein Dokument als Eingangs oder Ausgangsdoku-ment für ein Arbeitspa-ket.

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 Worklist-Konfiguration, wie sie in Abbildung 9-4 dargestellt ist, werden nur noch jene Aufga-


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 Mitarbei-tern: 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


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

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.


Ausdruck Beispielausdruck Bedeutung des Ausdrucks

[‘…’] [‘Produkt gestalten’] Zuordnung von Arbeitsschritten zu Mitarbeitern aufgrund der Ausführungshistorie. Der Arbeits-schritt 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 zugewie-sen. „?me“ ist eine Variable der Sprache, die an den angemeldeten Nutzer gebunden ist. „:istVorgesetzterVon“ eine Beziehung innerhalb der Organisa-tionsstruktur (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 Entwick-lers ist, sonst „false“.


Da die Definition des 3-Tupel-Schema für die meisten Modellierungsfälle zu aufwän-dig ist, wurde für häufig genutzte Zuweisungsregeln eine vereinfachte Notation definiert. Die ersten drei Ausdrücke (‘…’, {‘…’} und [‘…’]) stellen somit eine Vereinfa-chung 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 Prozess-managementsystem lediglich unterstützt.

In Tabelle 9-5 ist die Umsetzung der Modellierungselemente des Organisatorischen Aspekts zusammengefasst.


Tabelle 9-5: Umsetzung der Elemente des Organisatorischen Aspekts


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 Werkzeu-gen 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 not-wendigen 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 Handlungsalterna-tiven zu informieren und diese auch zu erlauben. Ein hoher Automatisierungsgrad ist hier durch das erforderliche Fachwissen und die zur Lösung des Entwicklungsprob-lems 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


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, alterna-tiv 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 Prozessmana-gementsystem 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 gerechtfer-tigt, da verglichen mit dem Zeitaufwand, den Anwender üblicherweise in die Umset-zung 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 Hilfedokumen-te 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.


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ührli-che Hilfe für „Experten“ angezeigt werden soll. Je nach Wahl des Nutzers werden im unteren Bereich des Reiters „Werkzeuge“ anschließend verschiedene Hilfedokumen-te 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


Werkzeug Produktionsressource Anzeige von Informati-onen und Anleitungen zu der Anwendung oder Produktionsressource


9.1.7 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 Model-lierung 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 ProcessNavi-gator aufgenommen werden können. Beide Konzepte unterstützen die Entschei-dungsfindung 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 Prozess-modell zu integrieren. Die Elemente einer Checkliste unterscheiden sich von norma-len 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 Prozessschrit-ten 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-


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 Kompo-nente 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 Richtli-nie 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 Anwen-dungsszenarios 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 vorgege-benen Prozess abzuweichen; Prozessausführung wird durch das Workflow-Management-System bestimmt.

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

Automatisierte Prozessaus-führung mit starker Integrati-on von Anwendungen in den Prozess.

Bereitstellung von Informa-tionen über das Projekt und Vorgehen für den Anwen-der.

Funktionaler Aspekt Beschreibt die im Prozess auszuführenden Schritte.

Beschreibt die im Projekt auszuführenden Aufgaben.

Verhaltensorientierter Aspekt

Bestimmt maßgeblich den Ablauf der Prozessausfüh-rung.

Bestimmt die Reihenfolge der Prozessschritte in der PN-Worklist.


Aspekte Klassisches Konzept ProcessNavigator

Anwender haben keine Möglichkeit vom vordefinier-ten Kontrollfluss abzuwei-chen.

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 Doku-mente 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 Prozess-schritte ein Anwender auszuführen hat.

Legt fest, welche Prozess-schritte 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.

Operationaler Aspekt Anwendungen werden direkt durch das Workflow-Management-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 Anwen-dung 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 Unter-stützung leisten, da hier umfangreiche Informationen über die Prozessausführung


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 Informatio-nen aller ausgeführten Projekte aufnimmt und zur Verbesserung der Prozesstypen beiträgt (Abbildung 9-12). Der kleine Regelkreis beschreibt dabei das projektbeglei-tende 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 Prozess-typen. Im Vergleich zum kleinen Regelkreis findet hier ein Sprung über Ebenen-grenzen im Meta-Modell statt.

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


Prozesslandschaft

Phase 5:Controlling & Assessment-

unterstützung


Integration



Phase 4.1:Projektbearbeitung

Phase 4.2: Projektmonitoring

Phase 3.2:Projektvalidierung

Phase 2.2:Prozessvalidierung

Phase 2.1:Definition des

Prozessmodells

Phase 3.1:Definition des Projekttyps

Kleiner Regelkreis – Monitoring

Groß

er R

egel

krei

s –Co

ntro

lling

Vorgehensmodell zur QM-

Umsetzung


Strategischen Controllings wird im nächsten Kapitel (10 - Nachbereitung der Projekt-durchfü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 norma-ler Projektmanagementaktivitäten steht dem Projektleiter hiermit ein Werkzeug zur Verfügung, Abweichungen vom geplanten Soll frühzeitig zu erkennen und zu behe-ben.

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 Ressour-cenkontrolle als zu überprüfende Größen angegeben. Mögliche Kenngrößen sind unter anderem:

� Geplante und effektive Dauer

� Geplante und effektive Kosten

� 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 Arbeitspake-te abgebildet. Der Erfüllungsgrad wird dabei als Fortschrittsbalken direkt im Auswahl-fenster des zu bearbeitenden Projekts angezeigt. Somit haben sowohl Projektleiter als auch Mitarbeiter Zugriff auf den aktuellen Fortschritt im Projekt.


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

Zusätzlich zu den oben beschriebenen Kennzahlen sind im Bezug auf die im Process-Navigator vorhandene flexible Prozessausführung weitere Kennzahlen von Interesse. Darunter fallen beispielsweise:

� Anzahl der Arbeitspakete, die mit fehlenden Eingangsdokumenten begonnen wurden

� Anzahl der Arbeitspakete, die abgeschlossen wurden obwohl noch Dokumente zu erstellen waren

� Anzahl der Dokumente, zu denen kein formales Datum im Prozesstyp existiert

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


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 QM-Systemen bedeutet dies, dass neben der Planung, die auch schon in bestehenden Systemen vorhanden ist, nun auch ein IT-System zur Unterstützung der Projektum-


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 QM-Standard beschriebenen Prozesse umzusetzen und die beschriebenen Arbeitsergeb-nisse 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: Umsetzen der Prozessschritte 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 Soll-Werten 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 ange-passt 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üt-zung leisten. Allerdings können die Änderungen an der Vorgehensweise oder den vorhandenen Ressourcen über den Projektplan wieder in den ProcessNavigator


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


RG 2

Ziel 2.6: Überwachung und Steuerung des Projekts

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

Ziel 2.7: Überwachung und Korrektur der Arbeitsprodukte

Wie schon bei der Überwachung und Steuerung des Projekts können die im Process-Navigator vorhanden Protokoll-Dateien genutzt werden, um weitergehende Messda-ten 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 dokumentie-ren. Treten ähnliche Abweichungen in mehreren verschiedenen Projekten auf, so kann dies ein Hinweis darauf sein, dass der Prozesstyp an dieser Stelle überarbeitet werden muss.


RG 3

Ziel 3.6: Erfassung der Daten und Ermitteln von Verbesserungspotenzialen


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 Projektma-nagements umgesetzt, wie ein flexibles Reagieren auf Änderungen und ein Projekt-monitoring.


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 QM-Assessment 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 Ab-schluss 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 Auftrag-gebern 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 gesam-melten Prozessaufzeichnungen und besonders die erstellten und an die Anforde-rungen 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 erreich-ten Erfahrungswerten, die definierten Prozesstypen zu verbessern. Um eine zielge-richtete Verbesserung der Prozesse vornehmen zu können, ist es nötig über Ausfüh-rungsinformationen des jeweiligen Prozesses zu verfügen. Mit den im ProcessNaviga-tor 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 Prozess-steuerung genutzt wird, adressiert dieser die Optimierung der Prozesstypen. Grund-lage dafür sind die im Ausführungsprotokoll vorhandenen Informationen über das Projekt, die beschreiben wann und in welcher Reihenfolge Aktionen im ProcessNavi-gator 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.

Abbildung 10-1: Großer Regelkreis zur Prozessverbesserung

Zur Prozessverbesserung können prinzipiell alle im Ausführungsprotokoll vorhande-nen Informationen herangezogen werden. Ein systematisches Vorgehen zur Auswer-tung 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.


Prozesslandschaft

Phase 5:Controlling & Assessment-

unterstützung


Integration



Phase 4.1:Projektbearbeitung

Phase 4.2: Projektmonitoring

Phase 3.2:Projektvalidierung

Phase 2.2:Prozessvalidierung

Phase 2.1:Definition des

Prozessmodells

Phase 3.1:Definition des Projekttyps

Kleiner Regelkreis – Monitoring

Gro

ßer R

egel

krei

s –Co

ntro

lling

Vorgehensmodell zur QM-

Umsetzung

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

� 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 Kom-mentare der Mitarbeiter an den Arbeitspaketen genutzt werden. Mitarbeiter können an den einzelnen Arbeitspaketen Kommentare abgeben und so Hin-weise geben, wie etwa die Verfahrensanweisungen eines Arbeitspaketes er-gänzt werden können. Außerdem können in den Kommentaren neue zusätzli-che 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 Aus-führungsprotokolls im ProcessNavigator können nun die Verbesserungsvor-schläge jedoch gezielt zu den einzelnen Arbeitsschritten des Prozesses abge-geben werden.

� Verhaltensbezogener Aspekt (Ziel: Verbesserung der Prozessabläufe) Der Verhaltensorientierte Aspekt beschreibt sowohl Abhängigkeiten zwischen Arbeitspaketen als auch Entscheidungen, die im Projektverlauf durch die Mit-arbeiter getroffen werden müssen. Wie in Abschnitt 9.1.3 beschrieben, müs-sen Mitarbeiter die im Projekt getroffenen Entscheidungen dokumentieren. Auf diese Weise sind im Ausführungsprotokoll Informationen darüber vorhan-den, 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 Informations-quelle 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 Arbeitspa-ket nicht notwendig ist. Der gleiche Sachverhalt kann jedoch auch darauf hin-deuten, dass im Unternehmen weitere Schulungen über den Prozess notwen-dig sind. Eine weitere Informationsquelle im Verhaltensorientierten Aspekt ergibt sich durch flexible Prozessausführung im ProcessNavigator. Da Mitarbeiter die Ar-beitspakete 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.


� 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 ein-geplant werden.

� 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 Informati-onen werden in [Jablonski et Talib 2009] genutzt, um die Zuordnung von Ar-beitsschritten 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 Mit-arbeiter 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 ein-gesetzt werden.

� Operationaler Aspekt (Ziel: Bessere Ressourcennutzung im Unternehmen) Der Operationale Aspekt legt die genutzten Anwendungen und Produktions-ressourcen fest. Wird im Prozesstyp mehr als eine Anwendung an einem Ar-beitspaket 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 Ent-scheidungsprozess 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älti-gen 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.


Mit dem hier beschriebenen großen Regelkreis und der Möglichkeit aus dem Ausfüh-rungsprotokoll 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: Erfassung der Daten und Ermitteln von Verbesserungspotenzialen


10.2 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 Vorberei-tungsphase 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


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üh-rungsphase 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]:

� Direkte Artefakte: Im Prozess (entspricht einer CMMI-Praktik) erstellte Doku-mente und Ergebnisse.

� Indirekte Artefakte: Artefakte oder Dokumente, die zwar im Rahmen des Pro-zesses erstellt wurden, aber nicht direkt Ergebnisse sind. Beispiele sind unter anderem Freigabe-, Test- oder Prüfberichte.

� Bestätigungen: Diese Belege bestätigen, dass ein Prozess auch wirklich im Unternehmen umgesetzt wird. Bestätigungen werden hauptsächlich in den In-terviews 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 QM-Normen schult. Die beiden anderen Belege (Direkte Artefakte und Indirekte Artefak-te) 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 Prozes-se 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


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 Projekt-typ sowie den vorhandene Information im Ausführungsprotokoll weitere Auswertun-gen 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 vorange-gangenen Kapiteln jeweils im den Abschnitten „Umsetzung der QM-Vorgaben“ demonstriert.

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-

Zuordnung zwischen

Anforderung und Umsetzung


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 IT-System unterstützt werden kann. Dabei werden jedoch nur die Reifegradebenen RG1 bis RG3 aus dem QM-Modell aQM2 abgedeckt. Die verbliebenen beiden Reifegrad-ebenen RG4 (Überwachter Prozess) und RG5 (Verbessernder Prozess) werden durch das beschriebene System nicht systematisch umgesetzt. Ziel dieser beiden Reifegrad-ebenen 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 Prozessverbesserungs-mö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 Anforderun-gen 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 errei-chen 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 ProcessNa-vigators 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 Zufallsva-riablen 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]:

� Einer Managementphilosophie mit fundierter Basis und wirksamen QM-Werkzeugen

� 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ög-lichkeiten. 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


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 erwar-tenden Qualität der Produkte dargestellt. Für die Kenngröße eines Prozesses (gefun-dene 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 normal-verteilt 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.

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 Standard-abweichung σ in den Toleranzbereich passt. Wenn der Toleranzbereich (von Mittel-wert bis untere Schranke) eine Länge von 6σ hat, spricht man von einem Qualitätsni-veau von 6σ; bei kleineren Längen von entsprechend weniger.

Mittelwert

Gemessener Mittelwert entspricht nicht dem

Mittelwert des Toleranzbereichs

Prozess mit hoher Variation

Fehlerhaftes Produkt

Fehlerhaftes Produkt

6σ

Toleranzbereich

1σ


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 gemesse-nen 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 Toleranzbe-reichs 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 graphi-sche 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ätsni-veaus 6σ vorgeschlagen. Dieses Vorgehen wird DMAIC-Zyklus, entsprechend der Anfangsbuchstaben seiner Phasen, genannt. Dieser Zyklus setzt sich aus den folgen-den Phasen zusammen:

� 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 kom-men zwei Methoden zum Einsatz: die SIPOC- und die VOC-CTQ-Analyse. Die SIPOC-Analyse (Supplier, Input, Process, Output, Customer) dient zur Identifi-kation des Wertschöpfungsprozesses im Unternehmen. Die VOC-CTQ-Analyse (Voice of the Customer, Critical to Quality) erfasst die Kundenwünsche und lei-tet aus diesen die Qualitätskriterien eines Produkts ab. Ergebnis der Define-Phase sind somit die für die Verbesserung des Prozesses kritischen Größen, abgeleitet aus den Anforderungen der Kunden.


� Measure Die Measure-Phase überführt das praktische Problem in ein statistisches Prob-lem. 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 da-raus abgeleitete Prozessoptimierung eine Verbesserung des Produkts im Hin-blick 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.

� Analyze

Die Analyze-Phase identifiziert die Grundursachen einer Prozessabweichung basierend auf den in der Measure-Phase identifizierten Kenngrößen. Im Mit-telpunkt 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.

� Improve In der Improve-Phase werden auf Basis der gefunden Grundursachen Lösun-gen für vorhandene Probleme im Prozess gesucht. Ziel ist die Identifizierung von Wirkprognosen und Verbesserungsmaßnahmen. Verschiedene Lösungs-vorschlä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 Umset-zung ausgewählt. Für diese wird ein überarbeiteter Prozesstyp entworfen, in den die Lösungsvorschläge eingearbeitet sind und mit dem sich konkrete Pro-jektergebnisse und Verbesserungen am Produkt erzielen lassen.

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


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 Stabilisie-rung 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 Kundenanforde-rungen 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) durchschnitt-lich 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öglich-keit“ noch „Defekt“ so einfach bestimmen. In [Binder 1997] werden verschiedene Gründe vorgestellt, warum sich Six Sigma – zumindest nicht einfach – an die Erfor-dernisse eines Softwareentwicklungsprojekts anpassen lässt. Der wohl wichtigste dieser Gründe ist, dass sich Softwareentwicklungsprojekte verglichen mit Herstel-lungsprozessen nicht wiederholen. Während die Fertigung eines Produkts weitge-hend 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

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 methodi-schen 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 Dokumen-tation 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 Kundenan-forderungen 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.


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 quantitati-ven Zielen für die Messun-gen

Define-Phase

Ziel 4.2: Identifikation von Mess-punkten für Prozess und Produkt

Measure-Phase

Ausführungsebene

Ziel 4.3: Sammeln und Erfassen von Messdaten

Measure-Phase

Erfassung und Speicherung der Prozessdaten in der Wissensbasis.

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

Analyze-Phase

Export der Daten aus der Wissens-basis; anschließender Import und Auswertung in einem Statistik-werkzeug.

Ziel 4.5: Erarbeitung von Korrek-turmaßnahmen und Steuerung des Projekts

Improve-Phase/

Control-Phase

Ausführungsunterstützung im ProcessNavigator und Monitoring des Projekts und der Arbeitsergeb-nisse.

Die Rolle des ProcessNavigators bei der Umsetzung der Reifegradebenen RG4 und RG5 ist primär die eines Datenlieferanten. Im Ausführungsprotokoll des ProcessNavi-gators 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


direkte Implementierung der mathematisch-statistischen Funktionen im ProcessNa-vigator 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 notwendi-gen 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 aufzude-cken. 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 (Prozessoptimie-rung) 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 Steue-rung 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 mathe-matischer Methoden sollen Abweichungen früher erkannt werden und vorhersagbare Projekte im Unternehmen ermöglicht werden.


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

Define-Phase/

Measure-Phase

Ausführungsebene

Ziel 5.2: Analyse der Daten

Analyze-Phase

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

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

Analyze-Phase

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 Verbesse-rungsmöglichkeiten

Improve-Phase

Ziel 5.5: Entwickeln einer Umsetzungs-strategie

Improve-Phase

Umsetzung in einem Pilotpro-jekt im ProcessNavigator.

Ziel 5.6: Umsetzen der Verbesserungen

Control-Phase

Anpassen der Standardprozes-se (Prozesstypen) für die zukünftige Ausführung im ProcessNavigator.


RG 5

Ausführungsebene

Ziel 5.7: Untersuchen der Effektivität der Verbesserungen

Control-Phase

Messung und Kontrolle der im ProcessNavigator erfassten Ausführungsdaten.

Wie schon RG4 beginnt auch RG5 mit einer Definition der strategischen Verbesse-rungsziele (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 (Measure-Phase). 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 Überarbei-tung 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 Mitarbei-tern genutzt werden. Die fortlaufende Sicherstellung der Effektivität der Verbesse-rung (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 Unter-nehmensumgebungen 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 Mitarbei-ter 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 Web-Framework JSF wird im System das Konzept der Trennung von Struktur, Inhalt und Darstellung realisiert; zusammen mit einer geeigneten Speicherschicht wird eine 3-Schichten-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 Anwendungsebe-ne 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 Implementie-rung 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 Speiche-rung 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:

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

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

� Zentrale Datenhaltung Durch die Nutzung des Application-Servers ist im ProcessNavigator auch eine zentrale Datenhaltungskomponente vorhanden. Im clientseitigen Web-Browser werden weder Daten noch andere Informationen gespeichert und ei-ne manuelle Status-Synchronisation kann somit entfallen. Der gesamte Pro-zessausfü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-Application-Server als Implementierungsgrundlage zu nutzen. Sie ist in die drei Schichten Darstel-lungsschicht, Anwendungsschicht und Speichersystem unterteilt. Die Darstellungs-schicht 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.

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 vorgese-hen. Diese Zuordnung zwischen einem Aspekt der AOPM und einem in der Anwen-dungsschicht 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 Process-Navigators. 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 Kontextin-formationen für die Prozessausführung bereit. Von den beschriebenen Modulen ist einzig das Modul „Funktionaler Aspekt“ sowohl in der Worklist als auch im Process-Navigator-Desktop eingebunden. In der Worklist stellt es die Arbeitsschritte und im

Speichersystem

Mod

ellk

ern

Anwendungs-schicht

Ausf

ühru

ngs-

kern

Darstellungsschicht

Prozessnavigator-Worklist Prozessnavigator-Desktop

Funktionaler Aspekt

Verhaltens-orientierter Aspekt





Verhaltens-orientierter

Aspekt

Funktionaler Aspekt




Desktop Informationen (z.B. Verfahrensanweisungen) zu dem gewählten Arbeits-schritt bereit.

Zu jedem Modul der Anwendungsschicht ist im Speichersystem eine entsprechende Speicherstruktur vorhanden. Hier werden insbesondere die Eigenschaft von RDF-Triple 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 Modell-kern. 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 Speichersys-tem eingetragen.

Abbildung 12-2: Aufrufsequenz im ProcessNavigator

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

Worklist-Sichten

Ausführungs-kern

Org.-Zuweisung

PN-Worklist PN-Desktop

Daten/ Dokumente

Operationen/ Werkzeuge Wissensbasis

Zugr

iff a

uf W

orkl

istZu

griff

auf

Des

ktop

1) Laden der Arbeitsschritte

2) Filtern der Arbeitsschritte nach Organisation

3) Auswahl eines Arbeitsschrittes durch Nutzer 4) Anzeige der Dokumente im Desktop

5) Anzeige der Werkzeuginformationen im Desktop

Speicher-system


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“ aufgeru-fen, welche wiederum auf den im Speichersystem abgelegten Modellkern zurück-greift. 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 PN-Desktop 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 entspre-chenden 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 Descrip-tion Framework (RDF) [Brickley et Guha 2004; RDF 2009] und Web Ontology Langua-ge (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 unterei-nander sowohl durch Menschen als auch durch Rechnersysteme gelesen werden können [Hitzler et al. 2008]. Neben einer textbasierten Suche, wie sie in aktuellen


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 Konzep-ten, 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 Ontolo-gie 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üh-rung des Prozesses nötigen Informationen zu speichern. Wie in der Grobarchitektur (Abbildung 12-1) vorgestellt, werden zu den Aspekten des Prozessmodells Teilmodel-le 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 Aspek-ten 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.


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 Verbesserungs-möglichkeiten am Prozesstyp zu identifizieren. Allerdings werden auch die Anforde-rungen des QM-Standards explizit im Speichersystem referenziert. Auf diese Weise wird die in Abschnitt 7.4 vorgestellte Abbildung des Prozesstyps auf den QM-Standard 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 Anwen-dungsschicht werden diese Datenstrukturen im Sinne der flexiblen Prozessausfüh-rung 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.

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-

rdf:type

rdf:type

ipm:ProcessSprache M2

task:T1Instanz M0

rdf:type

task:toStatustask:fromStatus

task:taskOfProject

ipm:PType1

Typ M1

task:hasStatustask:Task task:Status

task:Transitionproject:Project

task:transition


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] darge-stellt.

Bei der folgenden Beschreibung der Datenstrukturen wird, sofern es nicht zu Mehr-deutigkeit 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.

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.

rdf:type

rdf:type

rdf:type

rdf:type

rdf:type

ipm:Process

ipm:outgoingConnector

ipm:Connector

ipm:incomingConnector

ipm:outgoingConnectoripm:PType1

ipm:PType2

ipm:Connector1ipm:incomingConnector

task:T1 task:T2

T1 T2

Sprache M2

Typ M1

Instanz M0


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.

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.

rdf:typerdf:type

rdf:type

rdf:type

rdf:type

rdf:type

rdf:typeipm:outgoingConnector


ipm:Process ipm:Connector


ipm:outgoingConnector


ipm:PType1

ipm:PType2

ipm:PType3

ipm:AND_Connector1

task:T1 task:T2 task:T3

Sprache M2

Typ M1

Instanz M0

T2

T3

T1

AND


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

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ösungskomponen-ten“ 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 zugeord-net (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ßgeb-lich dafür, welche Arbeitsschritte einem Mitarbeiter zur Ausführung angezeigt

rdf:type

qm:bpOfProcess

ipm:implements

rdf:type

qm:outputqm:input

qm:Process

ipm:Software Module

ipm:produces

rdf:type

qm:WorkProduct qm:BasePractice

qm:ENG.6.BP2 Develop software units

ipm:Entwicklung der Lösungskomponenten

qm:11-05 Software unit

task:Entwicklung derNutzerschnittstelle

task:Modul Nutzerschnittstelle

rdf:type

ipm:implements


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 vordefinier-te 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 Spezialisie-rungen 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.

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 (Transitio-nen) 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 rekonstru-ieren. Der Anwender (PERSON), welcher eine Statusänderung ausgelöst hat (z.B. die Beendigung eines Arbeitsschrittes), wird über die Beziehung PERFORMEDBY gespei-chert.

foaf:Agentfoaf:member

rdfs:subClassOf rdfs:subClassOf

foaf:Person

rdfs:literal

foaf:firstName

rdfs:literal

foaf:surName

foaf:Group

rdfs:literal

foaf:name


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

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

task:toStatustask:fromStatus

task:transition

foaf:Personorg:performedBy

task:Task

task:Transition

task:Status

rdfs:property

foaf:Agent

org:relationship

rdfs:rangerdfs:domain

rdf:type

org:istVorgesetzterVon

rdfs:subPropertyOf

foaf:Person

rdf:type rdf:type

org:istVorgesetzterVonorg:schmidt org:müller


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.

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 Datenori-entierter Aspekt im Speichersystem die ein- und 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

rdf:type

rdf:type

rdf:type

rdf:type

rdf:type

ipm:Process

ipm:consumes

ipm:Data

ipm:produces

ipm:producesipm:PType1

ipm:PType2

ipm:Dat1ipm:consumes

task:T1

task:T2

Sprache M2

Typ M1

Instanz M0 task:Doc1

task:createdby

task:createdinProject

rdf:type

task:createdIn org:Emp1

project:ProjectX

T1 T2T1 T2Dat1


(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 Mitarbei-ter in Arbeitsschritten ähnliche Dokumente anzubieten. Als ähnliche Dokumente werden in diesem Zusammenhang all jene Dokumente betrachtet, die im Prozessmo-dell 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 „Doku-ment“). 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 sicher-gestellt 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 QM-Anforderungen 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 Process-Navigators?“. Ziel war es einen möglichst umfassenden Überblick über das Potenzial des ProcessNavigators im betrieblichen Einsatz zu erlangen.

202 13 Evaluation des ProcessNavigators

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

1

1,5

2

2,5

3

3,5

4

4,5

5

deutlich besser

besser

kein Unterschied

schlechter

deutlich schlechter

2008

2009

Durchschnittswertenach Einzelfragen

13 Evaluation des ProcessNavigators 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 Produktentwicklungs-prozess 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 Produktionsent-wicklungsprozesses 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.

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-

50%

37%

13%

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

deutlich verbessert

verbessert

kein Unterschied

Anzahl der Teilnehmer: 16

204 13 Evaluation des ProcessNavigators

lungsprozess vergessen werden. Auch Potenziale für eine Weiterentwicklung des Systems wurden genannt. So wurde angemerkt, dass es notwendig ist, im ProcessNa-vigator 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 Feed-back 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 Forschungspro-jekts 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 „Orientie-rung im Prozessablauf“ und „Controlling“ die zentralen Entwurfsziele des Systems realisiert werden. Der ProcessNavigator kann sowohl Mitarbeiter im Entwicklungs-prozess 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 Ursa-chen, 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:

� Unterstützung der Mitarbeiter im Prozess durch die zielgerichtete Bereitstel-lung von Informationen,

� Unterstützung der Projektleiter durch ein transparentes Projektmanagement und

� 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 Anforderun-gen an das Informationssystem aus Sicht der QM-Standards definiert. Die Anforde-rungen aus Sicht der Nutzer (Mitarbeiter und Projektleiter) werden im Kapitel 4 vorgestellt. Zentral ist hier die Forderung, dass das Informationssystem die Mitarbei-ter 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 QM-Umsetzung, der an die Anforderungen von QM-Systemen angepasst wurde. Der bekannte Prozesslebenszyklus (Identifikation der Prozesse, Prozessdefinition, Aus-fü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 Unterabschnit-te, einem Erstellungsabschnitt und einem Validierungsabschnitt, aufgeteilt. Während der Validierung wird überprüft, ob die in der Phase erstellten Produkte bzw. Doku-mente noch mit den Richtlinien des Unternehmens und den Anforderungen des QM-Standards 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 QM-Standards 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. Aufbau-end 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 Arbeits-schritte 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 Produktentwicklungs-projekten vorgestellt. Das System basiert auf dem Ansatz klassischer Workflow-

14 Zusammenfassung 207

Management-Systeme, der Trennung in eine Worklist und in einen Anwendungsbe-reich (Desktop). Aus der Worklist können dabei jene Aufgaben ausgewählt werden, die bearbeitet werden sollen; im Anwendungsbereich werden anschließend Informa-tionen, 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 bevormun-den. Die wichtigste Änderung der Worklist im Vergleich zu klassischen Workflow-Management-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 Mitarbei-ter aus der Liste „Nächste Schritte“ immer die nächste im Projekttyp vorgesehene Aufgabe auswählen. Auch der Anwendungsbereich (Desktop) wurde an die Anforde-rungen 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 ProcessNaviga-tors 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 vorgese-hen 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 automa-tisch 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 QM-Assessments 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


vorhandenen Informationen ist das Unternehmen besser auf Assessments vorberei-tet 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 Reifegradstu-fe 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ätsni-veau 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 ProcessNa-vigator und kann bei Auswertungen von den dort gesammelten Ausführungsinforma-tionen profitieren.

Die Architektur des ProcessNavigators wird in Kapitel 12 vorgestellt. Der ProcessNavi-gator 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-Anforde-rungen;

3. Der Konzeption eines Informationssystems zu Umsetzung von QM-Anforde-rungen im Unternehmen;

4. Dem Entwurf einer Systemarchitektur zur Implementierung des Informations-systems.

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 Vorge-hensmodells 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 Informationssys-tem 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 Arbeitspa-kete 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 Implementie-rung der vorgestellten Systemarchitektur im Rahmen des FORFLOW-Projekts sowie die dort durchgeführte Evaluation konnte gezeigt werden, dass ein solches Prozess-managementsystem 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


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

15 Ausblick

Das zentrale Ziel dieser Arbeit war die Konstruktion prozessbasierten Informations-systems 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 Prozesslebens-zyklus 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ög-lichkeiten einzuschränken.

Über Nutzung des Prozessmanagementsystems zur Implementierung eines QM-Systems hinaus können die Forschungsergebnisse weiter genutzt und neue Funktio-nen entwickelt werden. Dies beinhaltet sowohl die Erweiterung des ProcessNaviga-tors mit neuen Funktionen als auch das Adaptieren des Systems an neue Domänen. Eine Auswahl dieser Erweiterungsmöglichkeiten wird hier kurz vorgestellt:

� Integration externer Werkzeuge in den ProcessNavigator

In Abschnitt 9.1.6 (Der Operationale Aspekt im ProcessNavigator) wurde ge-zeigt, dass der ProcessNavigator im Gegensatz zum klassischen Workflow-Konzept vor allem eine Informationsfunktion für den Mitarbeiter hat. Auf eine direkte Integration der Anwendungen in den ProcessNavigator, wie sie im klas-sischen 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 An-wendungen gestartet werden können. Hier bietet sich die Möglichkeit neue Techniken zur einfacheren Integration von Desktop-Anwendungen in Web-Anwendungen zu entwickeln, die es über geeignete Integrationsschnittstellen erlauben die benutzten Werkzeuge direkt aus dem ProcessNavigator aufrufen.

� Nutzung des Systems in anderen Domänen Der ProcessNavigator wurde vor allem im Umfeld von (Software-)Produkt-entwicklungsprozessen konzipiert und evaluiert. In [Meiler 2005] wird die Mo-dellierung Klinischer Pfade vorgestellt. Durch die flexible Ausführung von Pro-zessen 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.

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

� 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 Verbesserungs-maß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 aufzude-cken.

� Nutzung einer formalen Beschreibungssprache zur Festlegung der Freiheitsgra-de in der Prozessausführung Im ProcessNavigator wurde eine sehr freie und flexible Form der Prozessaus-fü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 Auswer-tungsmodul im Ausführungssystem entsprechend angepasst werden. In [Jab-lonski et al. 2009b] wird dazu eine formale, logikbasierte Methode vorgestellt, die es erlaubt, die Ausführungsreihenfolge der Schritte feingranular festzule-gen. 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 Modellierungs-sprache 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 angemes-sen 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 Re-search 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 Pub-lishers, 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 Literaturverzeichnis

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

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


[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 Pro-ceedings 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.foaf-

project.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 Mel-lon 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 Integra-

tion of ISO/IEC 15504 and CMMI-SE/SW. LQPS, UNIVALI, São José.


[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), 72-90.

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


[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 Standardiza-tion (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 Assess-ment 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 Architec-

ture. In Proceedings of 4th International Working Conference on Dynam-ic 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.


[Jablonski et Volz 2008] Jablonski, S. et Volz, B. (2008). Datenbankgestützte Implementierung

höherer Metamodellierungskonzepte. Datenbank-Spektrum, 8 (24), 24-32.

[Jablonski et Meerkamm 2009] Jablonski, S. et Meerkamm, S. (2009). An Extended Interpretation of

Process Design and Modelling. In Proceedings of 4th International Confe-rence on Design Science Research in Information Systems and Technolo-gies (DESRIST), Philadelphia (PA), USA.

[Jablonski et Talib 2009] Jablonski, S. et Talib, R. (2009). Agent Assignment for Process Manage-

ment: Pattern based Agent Performance Evaluation. In Proceedings of The Fourth International Workshop on Agents and Data Mining Interac-tion (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 Interna-tional 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 Man-agement, 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 Con-ference 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 Interna-tional 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 In-ternational Conference on the Evaluation of Novel Approaches to Soft-ware Engineering (ENASE), Milan, Italy.


[Jablonski et al. 2007] Jablonski, S., Faerber, M., Kastner, N. et Metzger, A. (2007). IPM4QM –

Eine integrierte Modellierung von Unternehmensprozessen und Anfor-derungen 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 (January-February 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 Hei-delberg.

[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 Rheuma-tologie – ein strukturiertes Prozessmanagement. Zeitschrift für Rheuma-tologie, 66 (3), 247-254.


[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 Engi-neering Notes, 32 (3), 1-6.

[Prud'hommeaux et Seaborne 2008] Prud'hommeaux, E. et Seaborne, A. (2008). SPARQL Query Language for

RDF. W3C.


[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/rdf-schema/.

[Reith 2000] Reith, M. (2000). Das 3i-Progamm der Siemens AG: Kulturwandel und

Ideenmanagement. In Materialien aus dem Institut für empirische Sozio-logie 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), 1149-1155.

[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://www-

01.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 Docu-ment. 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äftsprozessmanage-

ment in der Praxis. Hanser, München.


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

basierten Datenstruktur für die flexible Ausführung von Prozessen in der Produktentwicklung. Zulassungsarbeit am Lehrstuhl für Angewandte In-formatik IV - Datenbanken und Informationssysteme, Universität Bay-reuth, Bayreuth.

[Sharafi 2009] Sharafi, A. (2009). Pilotierung und Evaluation des FORFLOW-Prozess-

navigators. In: Meerkamm, H., Henrich, A., Jablonski, S., Krcmar, H., Lin-demann, 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 Universi-ty.

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


[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/IT-Methoden/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 Data-bases, 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äts-

management. 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/wsbpel-v2.0-OS.html (abgerufen am: 15.01.2010).


[Zeising 2009] Zeising, M. (2009). Organisationsverwaltung in Prozessmanagementsys-

temen. Bachelor Thesis am Lehrstuhl für Angewandte Informatik IV - Da-tenbanken 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 Pro-ceedings of 33rd Hawaii International Conference on System Sciences, Maui, Hawaii.

Documents

Prozessorientierten Qualitatsmanagementsystemen: Konzept zur Implementierung