Methodik des betrieblichen Software-Projektmanagements: Grundlagen, Begründung und Konzeption eines evolutionären Ansatzes [Reprint 2019 ed.] 9783110854749, 9783110134926

Citation preview

Studien zur Wirtschaftsinformatik 6 Herausgegeben von Karl Kurbel, Uwe Pape und Hans-Jochen Schneider

Wolfram Pietsch

Methodik des betrieblichen Software-Projektmanagements Grundlagen, Begründung und Konzeption eines evolutionären Ansatzes

w DE

G Walter de Gruyter • Berlin • New York 1992

Wolfram Pietsch Dr. rer. pol. Dipl.-Kfm., Wissenschaftlicher Assistent am Institut für Wirtschaftsinformatik der Westfälischen Wilhelms-Universität, Münster Softwareengineering-Methoden-Berater und Projektleiter bei ExperTeam GmbH Beratung + Training + Software + Systeme in Köln

Das Buch enthält 101 Abbildungen

© Gedruckt auf säurefreiem Papier, das die US-ANSI-Norm über Haltbarkeit erfüllt.

Die Deutsche Bibliothek — ClP-Einheitsaufnahme Pietsch, Wolfram: Methodik des betrieblichen Software-Projektmanagements : Grundlagen, Begründung und Konzeption eines evolutionären Ansatzes / Wolfram Pietsch. — Berlin ; New York : de Gruyter, 1992 (Studien zur Wirtschaftsinformatik ; 6) ISBN 3-11-013492-6 NE: G T

© Copyright 1992 by Walter de Gruyter & Co., D-1000 Berlin 30. Dieses Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Druck: WB-Druck GmbH & Co. Buchproduktions KG, Rieden am Forggensee. — Buchbinderische Verarbeitung: Dieter Mikolai, Berlin. — Einband: Hansbernd Lindemann. — Printed in Germany

Vorwort

Große Softwaresysteme zählen mitunter zu den kompliziertesten Gebilden, die je von Menschen geschaffen wurden. Für die erfolgreiche betriebliche Softwareentwicklung gelten deshalb in Wissenschaft und betrieblicher Praxis eine besondere, zielgerichtete Organisationsform, die Projektorganisation, sowie Maßnahmen für die Planung und Steuerung als unerläßlich; die Ursache vieler Projektfehlschläge liegt im Projektmanagement. Eine methodisch stringente Planung und Steuerung von Projekten ist dieser Erkenntnis zum Trotz jedoch in der Praxis nur selten anzufinden. Während das verfügbare Projektmanagement-Instrumentarium unter anderem bei der Erstellung hochkomplexer chemischer Anlagen einen integralen Bestandteil darstellt, spielt es bei vielen Software-Projekten eine mehr oder minder untergeordnete Rolle. Die mangelnde Akzeptanz der Projektmanagement-Methodik kann nicht nur auf eine unzureichende oder fehlgeleitete methodische und praktische Ausbildung zurückzuführen sein. Es stellt sich vielmehr die Frage, ob die einschlägigen Methoden prinzipiell oder in der verfügbaren Form für das Management beliebiger Software-Projekte geeignet sind. Die Frage nach der geeigneten Projektmanagement-Methodik beschäftigte mich seit meinen ersten Erfahrungen mit Software-Entwicklungen, die während meines Studiums im Projektteam durchgeführt wurden. Nachdem die Hochschulausbildung mich das Wasserfallmodell und die Netzplantechnik gelehrt hatte, zeigte mir die Praxis schnell deren Mängel und Einschränkungen. Die Zweifel wurden lauter, als ich mich intensiv mit der Anwendung innovativer Entwicklungswerkzeuge und Expertensystemen beschäftigte. Die gängigen Methodiken schienen zu versagen; gangbare, hinsichtlich der wissenschaftlichen Fundierung mit dem Wasserfallmodell vergleichbare Alternativen waren nicht bekannt. Die vorliegende Arbeit ist das Ergebnis meiner intensiven wissenschaftlichen Auseinandersetzung mit der Methodik des betrieblichen Software-Projektmanagements und zielt auf eine konstruktive Kritik der gängigen Projektmanagement-Methodiken ab. Die Arbeit wurde aus einer wissenschaftlichen Perspektive verfaßt, der Dictus der Kritik ist deshalb eher wissenschaftlich-abstrakt, das in der Arbeit entwickelte alternative Konzept für das Projektmanagemenent wird jedoch in operationalisierbare Handlungsempfehlungen überführt. Deshalb sollten sowohl der eher theoretisch als auch der praktisch interessierte Leser von den Ergebnissen profitieren können. Die Arbeit entstand im Umfeld eines anwendungsorientierten Wirtschaftsinformatik-Lehrstuhls und lebt von den Erfahrungen und Erkenntnissen, die ich in der Projektarbeit mit meinen Kollegen, studentischen Hilfskräften, Diplomanden und - last not least - den Projekt- bzw. Kooperationspartnern aus der betrieblichen Praxis gesammelt habe. Mein Dank gilt vor allem Herrn Prof. Dr. Karl Kurbel, meinem Lehrer und Förderer, der das fruchtbare Umfeld bestellte und die Arbeit betreute.

vi

Vorwort

Mein besonderer Dank gilt weiter allen Kollegen und Hilfskräften, die mir mit Rat und Tat zur Seite standen und meine Erkenntnisse in vielen Diskussionen vorantrieben. Als Beispiele müssen hier insbesondere Herr Ralf Vogel und Herr Patrick Dornhoff genannt werden. Den Kollegen, Bekannten und Freunden, die mich bei der Durchsicht des Manuskripts und anderen Arbeiten unterstützten, bin ich ebenfalls zu Dank verpflichtet. Der/die eine oder andere empfand die Materie insbesondere nach mehrmaligem Lesen als recht trocken und hätte sich gern "alle paar Seiten einen Mord gewünscht", wie eine begeisterte Krimi-Leserin bekundete. Mein Dank gilt auch der Deutschen Forschungsgemeinschaft, die das Umfeld meiner Arbeit durch Förderung eines Projektes, das auf die Entwicklung eines innovativen Projektmanagementsystem-Prototyps abzielt, unterstützte.

Wolfram Pietsch

Münster, im Dezember 1991

Inhaltsübersicht 0

Problemstellung und Übersicht

1

1

Projektmanagement

4

Begriffe 4, Projektmanagement-Ansätze 7, Projektdeterminanten 30, Einordnung von Software-Projekten 37 2

Projektmodelle für die Softwareentwicklung

50

Lineare Phasenmodelle 50, Prototyping 60, Evolutionäre Ansätze 79, Situative Ansätze 91 3

Methoden und Instrumente für das Projektmanagement

103

Traditionelle Methoden und Instrumente 103, Anwendung auf das SoftwareProjektmanagement 106, Software für das Software-Projektmanagement 136, Schlußfolgerungen 138 4

Ein Konzept für das evolutionäre Projektmanagement

140

Evolutionstheoretische Ansätze - Exkurs 140, Evolution von Softwaresystemen 150, Ansatzpunkte für das Management von SoftwareProjekten 160, Bausteine eines flexiblen Projektmanagements 169, Zusammenfassung 177 5

Strategische Projektplanung und -Steuerung

179

Einbindung in das Informationsmanagement 179, Projektübergreifende Steuerung der Anwendungsentwicklung 182, Entwicklungsplan 199 6

Arbeitsorganisation

210

Flexible Aufgabenplan 210, Kooperative Arbeitsplanung 224, Prozessuale Qualitätssteuerung 243 7

Ein integriertes Werkzeug für das flexible Projektmanagement

252

Systemarchitektur 252, Prototypische Realisierung von COCPIT 257 8

Ausblick

262

Literaturverzeichnis

266

Stichwortverzeichnis

286

Anhänge

Inhaltsverzeichnis

0 Problemstellung und Übersicht 1 Projektmanagement 1.1 Begriffe 1.2 Projektmanagement-Ansätze 1.2.1 Klassische logistische Ansätze 1.2.2 Der Projekt-Lebenszyklus 1.2.3 Systemorientierte Ansätze 1.2.3.1 Systemtheorie 1.2.3.2 Projekte als Systeme 1.2.3.3 Systemanalytische Ansätze 1.2.3.4 Systemtechnik 1.2.4 Verhaltensorientierte Ansätze 1.2.4.1 Hintergrund 1.2.4.2 Exkurs - Theory X 1.2.4.3 Integrative Ansätze 1.2.5 Synopse der Projektmanagement-Ansätze 1.2.6 Voraussetzungen für ein problemangepaßtes Projektmanagement 1.3 Projektdeterminanten 1.3.1 Art 1.3.2 Anwendungsgebiet 1.3.3 Organisationsform 1.3.4 Umfang 1.3.5 Dynamik 1.4 Einordnung von Software-Projekten 1.4.1 Überlagerung mehrerer Projektarten 1.4.2 Interdisziplinäre Anwendung 1.4.3 Problem des "Moving target" 1.4.4 Organisation und Kommunikation 1.4.5 Umfang und Komplexitätsbaniere 1.4.6 Fazit 2 Projektmodelle für die Softwareentwicklung 2.1 Lineare Phasenmodelle 2.1.1 Das Modell des Software-Lebenszyklus 2.1.2 Das Wasserfall-Modell 2.1.3 Nachteile linearer Modelle 2.1.3.1 Validierung

1 4 4 7 8 10 14 14 15 16 19 22 22 22 25 28 29 30 31 33 35 36 36 37 37 40 41 42 47 48 50 50 50 51 55 55

X

Inhaltsverzeichnis

2.1.3.2 Problemkomplexität 2.1.3.3 Phasenübergänge 2.1.4 Modifikationen des klassischen Modells 2.1.4.1 Schleifenbildung 2.1.4.2 Inkrementelle Entwicklung 2.1.4.3 Gleitendes Phasenmodell 2.2 Prototyping 2.2.1 Begriff 2.2.2 Prototyping-Arten 2.2.3 Ansatzpunkte des Prototypings 2.2.3.1 Entwicklungszweck 2.2.3.2 Leistungsumfang 2.2.3.3 Einsatzart 2.2.3.4 Benutzerinvolvierung 2.2.3.5 Ablaufschema 2.2.3.6 Prototyping-Ansatz und -Werkzeuge 2.2.4 Nachteile des Prototypings 2.2.4.1 Werkzeug-Abhängigkeit 2.2.4.2 Normative Kraft des Faktischen 2.2.4.3 Modell-Effekt 2.2.4.4 Zusätzliche Anforderungen 2.2.4.5 Fehlender methodischer Rahmen 2.2.5 Prototyping im Software-Lebenszyklus 2.2.5.1 Verbesserung der Anforderungsdefinition 2.2.5.2 Entwicklung von Pilotsystem 2.2.5.3 Phasen-Prototyping 2.3 Evolutionäre Ansätze 2.3.1 Iterative Entwicklung 2.3.2 Evolutionäres Prototyping 2.3.2.1 Prototyping als interaktiver Entwurfsprozeß 2.3.2.2 Inkrementelle Spezifikation 2.3.3 Versioning 2.3.3.1 Allgemeines Projektmodell 2.3.3.2 Ein verfeinertes Projektmodell 2.3.4 Prozeßorientierte Softwareentwicklung 2.3.4.1 Entwicklung und Wartung bei evolutionären Ansätzen 2.3.4.2 STEPS 2.3.4.3 Ein verfeinertes prozeßorientiertes Ablaufmodell 2.3.5 Nachteile evolutionärer Ansätze 2.4 Situative Ansätze 2.4.1 Kontingenzmodelle

56 57 58 58 58 59 60 60 62 63 64 64 66 67 69 70 71 71 73 74 75 76 76 76 77 78 79 79 80 81 82 83 83 84 86 86 87 87 90 91 91

Inhaltsverzeichnis

2.4.2 2.4.3

Das Spiralmodell Ein umfassendes Projektmodell-Schema 2.4.3.1 Entwicklungszweck 2.4.3.2 Ablaufschema als Ausdruck der Entwicklungsphilosophie 2.4.3.3 Einsatzart 2.4.3.4 Leistungsumfang 2.4.3.5 Benutzerinvolvierung 2.4.3.6 Ergebnisüberprüfung 2.4.4 Schlußfolgerungen 3 Methoden und Instrumente für das Projektmanagement 3.1 Traditionelle Methoden und Instrumente 3.1.1 Ansatzpunkt 3.1.2 Methoden im Überblick 3.2 Anwendung auf das Software-Projektmanagement 3.2.1 Bezug zum Software Engineering 3.2.2 Aufwandschätzung 3.2.3 Termin- und Einsatzplanung 3.2.3.1 Balkendiagramme 3.2.3.2 Exkurs - Netzplantechnik 3.2.3.3 Anwendung der Netzplantechnik auf SoftwareProjekte 3.2.4 Qualitätssicherung 3.2.5 Konfigurationsmanagement 3.2.6 Berücksichtigung von Risiko 3.2.6.1 Risikoanalyse 3.2.6.2 Software-Risikomanagement 3.3 Software für das Software-Projektmanagement 3.4 Schlußfolgerungen 4 Ein Konzept für das evolutionäre Projektmanagement 4.1 Evolutionstheoretische Ansätze - Exkurs 4.1.1 Evolution in den Natur- und Geisteswissenschaften 4.1.2 Managementansätze auf der Basis der Evolutionstheorie 4.2 Evolution von Softwaresystemen 4.2.1 Gegenstand der Evolution 4.2.2 Bezug zum Modell des Softwarelebenszyklus 4.2.3 Evolution im Rahmen der Software-Wartung 4.2.4 Bedeutung organisatorischer Evolution 4.2.5 Evolutionssprünge bei Entwicklung und Wartung 4.2.5.1 Der Post-Implementation Aftershock 4.2.5.2 Das Problem der Generationssprünge 4.2.6 Schlußfolgerungen

xi

94 96 98 98 99 99 99 100 101 103 103 103 104 106 106 107 108 108 110 116 122 127 133 133 134 136 138 140 140 140 145 150 150 150 152 154 156 156 158 159

xii

Inhaltsverzeichnis

4.3

4.4

4.5 5

6

Ansatzpunkte für das Management von Software-Projekten 4.3.1 Eingeschränkte Zweckrationalität 4.3.2 Implikationen für das Management 4.3.2.1 Planung 4.3.2.2 Überwachung und Kontrolle

160 160 162 162 163

4.3.2.3 Steuerung 4.3.2.4 Organisation 4.3.3 Zusammenspiel der verschiedenen Managementfunktionen Bausteine eines flexiblen Projektmanagements 4.4.1 Projektstrategie

164 164 167 169 170

4.4.2 Taktische Aspekte des Projektmanagements 4.4.3 Prozessuale Qualitätssicherung 4.4.4 Ein Drei-Ebenen-Modell für das Projektmanagement Zusammenfassung

171 172 173 177

Strategische Projektplanung und -Steuerung 5.1 Einbindung in das Informationsmanagement 5.1.1 Traditionelles Anwendungssystem-Management 5.1.2 Ein strategisches Projektmodell für die evolutionäre Softwareentwicklung 5.2 Projektübergreifende Steuerung der Anwendungsentwicklung 5.2.1 Bestehende Ansätze 5.2.2 Eine Portfolio-Methode für die Steuerung evolutionärer Anwendungsentwicklung

179 179 179

5.2.3 Bewertung von Projekten in einem Software-Portfolio 5.2.4 Ein alternativer Ansatz zur Aggregierung der Einzelkriterien 5.2.5 Differenzierte Betrachtung des Projektvolumens 5.2.6 Berücksichtigung von Bewertungsunsicherheiten 5.3 Entwicklungsplan 5.3.1 Software-Portfolio und individuelle Projektplanung 5.3.2 Flexible Entwicklungsplanung 5.3.3 Evolutionäre Entwicklungsplan Arbeitsorganisation 6.1 Flexible Aufgabenplan 6.1.1 Ein Rollenkonzept 6.1.2 Differenzierte Planung von Aufgaben-und Rollenstruktur 6.1.3 Flexible Ablaufplanung 6.1.3.1 PERT 6.1.3.2 Flexible Steuerung

188 191 194 196 199 199 200 204 210 210 210 214 215 215 219

6.2

6.1.3.3 Pufferorientierte Terminierung Kooperative Arbeitsplanung 6.2.1 Motivation 6.2.2 Abstimmungsprobleme und Arbeitsplanung

180 182 182 184

220 224 224 225

Inhaltsverzeichnis

6.2.3

Instrumente 6.2.3.1 Aktivitätenfolge 6.2.3.2 Individuelle Arbeitsorganisation 6.2.3.3 Kommunikationsunterstützung 6.2.4 Schlußfolgerung und Begründung eines "Task-Manager" 6.3 Prozessuale Qualitätssteuerung 6.3.1 Von der Qualitätssicherung 6.3.2 Ablauf der Qualitätssteuerung 6.3.3 Instrumente für das Qualitätsmanagement 6.3.4 Bedeutung des Qualitätsmanagement 7 Ein integriertes Werkzeug für das flexible Projektmanagement 7.1 Systemarchitektur 7.2 Prototypische Realisierung von COCPIT 8 Ausblick Literaturverzeichnis Stichwortverzeichnis

Anhänge A B C D

Kommunikationsverlust bei Teilteambildung Fallbeispiel zum Software-Portfolio Spezifikation der Terminierung-Algorithmen Beispielmasken für das Qualitätsmanagement

xiii

233 233 238 240 242 243 243 245 247 250 252 252 257 262 266 286

Abbildungsverzeichnis

1-1 1-2 1-3

Finanzielle Betrachtung des Projekt-Lebenszyklus Möglichkeiten der Phasenüberlappung Systemorientierte Darstellung des institutionellen Projektmanagements 1-4 Problemlösungszyklen vs. Lebensphasen 1-5 Einordnung von Projektzielen 1-6 Anwendungsgebiete von Projekten nach Branchen 1-7 Unterscheidung betrieblicher Projekte nach der Innovationsart 1-8 Auswirkungen der Kommunikation auf die Produktivität 1-9 Produktivitätsverlust durch Kommunikation 1-10 Produktivitätsverlust durch Kommunikation bei Teilteambildung 1-11 Aufwand bei verschiedenen Systemgrößen und Entwicklungszeiten 2-1 Das Stufenmodell 2-2 Das Wasserfall-Modell 2-3 Ziel, Ergebnis und Art der Ergebnisüberprüfung für die einzelnen Phasen eines Lebenszyklusmodells 2-4 Relative Fehlerbehebungskosten im Software-Lebenszyklus 2-5 Zusammenhang zwischen Fehler- und Kostenverursachung im Software-Lebenszyklus 2-6 Ablaufschema für die gleitende Softwareentwicklung 2-7 Arten der Benutzerpartizipation 2-8 Prototyping-orientierte Softwareentwicklung 2-9 Evolutionäres Prototyping nach Kurbel et al 2-10 Allgemeines Schema für das Versioning 2-11 Ablaufschema für das Versioning 2-12 Ablaufschema von STEPS 2-13 Evolutionäres Ablaufschema 2-14 Kontingenzmodell von Bums und Dennis 2-15 Problemangepaßtes Vorgehenskonzept von Krüger 2-16 Das Spiralmodell 2-17 Projektmodell-Parameter und Ausprägungen 3-1 Teufelsquadrat des Projektmanagements 3-2 Beziehungen zwischen Methoden des traditionellen Projektmanagements 3-3 Beispiel eines Zeitplans als Balkendiagramm 3-4 Beispiel eines Einsatzplans 3-5 Netzplan-Arten

11 12 16 20 32 34 34 43 44 46 47 50 52 53 54 55 59 68 78 82 84 85 88 89 92 93 95 97 103 104 108 109 110

Abbildungsverzeichnis

3-6 3-7 3-8 3-9 3-10 3-11 3-12

Puffer-Arten Schätzung und Terminierung bei PERT PERT-Netzplan eines Phasenmodells CPM-Netzplan eines Phasenmodells Netzplan eines Phasenmodells mit Anfangsfolgen PDM-Netzplan eines Phasenmodells Der Ablauf der Softwareentwicklung aus der Perspektive des Software-Konfigurationsmanagement 3-13 Ablauf des Änderungswesen im Rahmen des SoftwareKonfigurationsmanagements 3-14 Wichtige Risikofaktoren und Maßnahmen 4-1 Bereiche der Evolution 4-2 Dissipatives Ablaufschema eines Evolutionsprozesses 4-3 Beeinflussung evolutionärer Prozesse auf mehreren Ebenen 4-4 Wachstumsmuster betrieblicher Softwaresysteme 4-5 Ein alternativer Managementprozeß 4-6 Drei-Ebenen-Modell für das Projektmanagement 5-1 Strategisches Projektmodell für die evolutionäre Softwareentwicklung. 5-2 Beispiel eines F&E-Programm-Portfolio 5-3 Beispiel eines Kriterienkatalogs für die Bewertung von Projekten 5-4 Beispiel eines Software-Portfolios 5-5 Bedeutung der Positionen des Software-Portfolios 5-6 Partielle Variation eines Einzelkriteriums 5-7 Multiple Variation von Einzelkriterien 5-8 Portfolio mit differenziertem Projektvolumen 5-9 Software-Portfolio mit optimistischer, pessimistischer und wahrscheinlicher Positionierung 5-10 Software-Portfolio mit Bewertungsgradienten 5-11 Flexibler Entwicklungsplan für ein inkrementelles Projekt 5-12 Flexibler Plan für ein Prototyping-Projekt 5-13 Differenzierter Entwicklungsplan für ein Auftragsprojekt 6-1 Beispielhafter Grob-Strukturplan 6-2 Terminierung nach PERT 6-3 Ausschnitt eines im Sinne von PERT terminierten BeispielVorgangsplans 6-4 Flexible Vorgangsterminierung 6-5 Konventionell terminierter Beispiel-Vorgangsplan mit differenzierten Ausführungszeiten 6-6 Flexibel terminierter Beispiel-Vorgangsplan 6-7 Mögliche Überlappungen bei differenzierter Terminierung 6-8 Klassifikation von Abstimmungsproblemen 6-9 Beispielhafte Arbeitsorganisation

xv

112 113 117 117 118 118 128 130 135 142 144 147 152 168 174 181 184 186 188 190 193 193 195 197 198 202 204 208 214 216 218 219 221 222 223 225 229

xvi

Abbildungs Verzeichnis

6-10 6-11 6-12 6-13 6-14 6-15 6-16 6-17 6-18 6-19 6-20 7-1 7-2 7-3 7-4 7-5 7-6 7-7 7-8 7-9 7-10

Darstellung einer Koordinationsbeziehung im Ablaufplan Beispielhafte Produktstruktur für ein Software-Projekt Aufbauorganisation eines Software-Projekts Arbeitsplan für die Erstellung einer Bildschirmmaske Plantafel für ein beispielhaftes Software-Projekt Beispielhafte Agenda eines Teammitglieds Kapazitätsdisposition eines Beispiel-Software-Projekts Nachrichtenabsender-und-empfängerarten Ablaufschema für die Qualitätssteuerung Exemplarisches Datenmodell für das Qualitätsmanagement Maske für die Mängelbewertung Schematische Darstellung eines Projektmanagementsystem Architektur von COCPIT Einsatz des Knowledge-Manager COCPIT-Login Bildschirmmaske der Projekt-Toolbox Bildschirmmaske des Projektstruktur-Manager Anlegen einer Aufgabe Bildschirmmaske des Task-Manager Anlegen einer Aktivität Gleichzeitige Darstellung Projektstruktur-und Task-Manager

233 234 236 235 236 239 240 242 246 248 249 253 254 256 257 258 258 259 260 260 261

A-l A-2 A-3 D-l D-2 D-3 D-4 D-5 D-6 D-7

Kommunikationsverlust bei Teilteamgröße 4 Kommunikationsverlust bei Teilteamgröße 5 Kommunikationsverlust bei Teilteamgröße 8 Erfassung vom Mängeln Bewertung von Mängeln (geordnet nach Priorität) Bewertung von Mängeln (geordnet nach Schwere) Bearbeitung vom Mängeln in Literaturmasken Bearbeitung von Datenmängeln Abnahme von Mängeln in Masken Übersicht über korrigierte Mängel (Ablage)

A/l A/l A/2 D/1 D/1 D/2 D/2 D/3 D/3 D/4

Problemstellung und Überblick

Die ersten größeren kommerziellen erfolgreichen Softwaresystemen wurden durch Einzelleistungen herausragender Computerspezialisten möglich. Entwicklung von Software bestand zu dieser Zeit hauptsächlich aus schöpferischem Tüfteln und Basteln; weder eine fundierte theoretische Basis noch eine bewährte Konstruktionssystematik standen zur Verfügung. Programmierung war eine Axt "moderner Alchemie". Erfolgreiche Systementwicklungen waren oft eher Zufallsprodukte. Mit wachsender Problem- und Projektgröße traten vermehrt Probleme auf; bei der Entwicklung größerer Softwaresysteme häuften sich die Mißerfolge. Auf die anfängliche Euphorie bezüglich des Einsatzes von Computern folgte die sogenannte "Software-Krise". Entwicklungsbudgets wurden erheblich überschritten, und die Fertigstellungstermine konnte nicht gehalten werden. Ein bekanntes Beispiel ist das Projekt zur Entwicklung des Os-Betriebssystems für die IBM 360 Ende der 60er, Anfang der 70er Jahre1). Zur Überwindung der Situation wurde die Anwendung ingenieursmäßiger Vorgehensweisen gefordert und zu diesem Zweck eine eigene Fachdisziplin, das Software Engineering, konstituiert2). Auf diese Art und Weise konnte auf die spezifischen Ansätze für das Projektmanagement zurückgegriffen werden, die seit den 60er Jahren in der industriellen Forschung und Entwicklung (F&E) und Produktion erfolgreich angewendet wurden. Diese Ansätze wurden in die Methodik der Softwareentwicklung integriert und weiterentwickelt. Trotz der massiven Anstrengungen muten die Erfolge bescheiden an. In einem neueren Übersichtsartikel über die Organisation und das Management von Softwareentwicklungen kommt Eitzer zu dem Schluß, daß sich in der Praxis seither nicht viel geändert zu haben scheint3). Dieser Eindruck wird aus seiner Erfahrung von vielen Praktikern bestätigt. Zwar konnten im Rahmen der Softwaretechnik wichtige Fortschritte z.B. in Hinblick auf die Entwicklungsproduktivität erzielt werden4), nach wie vor scheitern jedoch ungefähr 20 Prozent aller Software-Entwicklungsprojekte5). Eitzer führt die Erfolglosigkeit der bisherigen Ansätze darauf zurück, daß bei der Abwicklung von Software-Projekten wesentlich mehr Faktoren berücksichtigt wer-

1) 2)

3) 4)

5)

Eine kritische Nachlese gibt Brooks (1974; 1975). Als "Geburtsstunde" des Software Engineering wird die NATO-Konferenz über "Software Engineering Techniques" in Garmisch im Jahre 1969 angesehen; zur Konferenz siehe Buxton, Randell (1970). Siehe Eitzer (1989), S. 181. Wenn auch die Programmierproduktivität, gemessen in "Lines of code" (loc), nahezu konstant geblieben ist, konnte doch die Gesamtproduktivität u.a. durch Einführung höherer, mächtiger Sprachen und spezifischer Werkzeuge erheblich verbessert werden; vgl. Eitzer (1989), S. 187. Vgl. Jones nach DeMarco, Lister (1987), S. 3 f.

Problemstellung und Überblick

2

den müssen als nur solche der Softwaretechnik, und fordert ein integriertes Management, das auch alle wesentlichen nicht-technischen Gesichtspunkte umfaßt6). Empirische Untersuchungen bestätigen diese These: Der häufigste Grund für das Scheitern von Software-Projekten ist nicht technischer Natur, sondern besteht in Schwierigkeiten hinsichtlich der Planung und Kontrolle7). In letzter Zeit werden innerhalb des Software Engineering die Forderungen nach einer Umorientierung lauter. Floyd postuliert einen Paradigmen-Wechsel für das Software Engineering8) und entwickelt spezifische Entwurfs- und Konstruktionsverfahren für eine evolutionäre Softwareentwicklung. Boehm, ein prominenter Vertreter der klassischen Methodik, konzipiert einen alternativen, flexibleren Ansatz, der die ingenieursmäßigen Entwicklungsphilosophien verläßt und ebenfalls evolutionäre Elemente aufweist9). Diese Arbeit befaßt sich mit der Umorientierung der betrieblichen Softwareentwicklung aus der Perspektive der Wirtschaftsinformatik. Wegen der besonderen Bedeutung der Planung und Kontrolle für den Projekterfolg werden Aspekte des Projektmanagements in den Mittelpunkt gestellt. Zuerst wird im Sinne der These von Eitzer untersucht, welche nicht-technischen Aspekte für das betriebliche Software-Projektmanagement relevant sind, wo sich Probleme ergeben, und welche Unterstützung die verfügbaren Ansätze bieten. Dann wird ein Konzept für die Umorientierung begründet. Anschließend werden konkrete Vorschläge für eine Ausgestaltung des betrieblichen Software-Projektmanagements entwickelt. Zu den Kapiteln im einzelnen: In Kapitel 1 werden die grundlegenden Eigenschaften der allgemeinen Projektmanagement-Ansätze erörtert und die Voraussetzungen für deren Anwen-dung auf die betriebliche Softwareentwicklung diskutiert. Es wird u.a. herausgearbeitet, daß spezifische Konzepte und Methoden erforderlich sind. In Kapitel 2 werden die verfügbaren Projektmodelle für die betriebliche Softwareentwicklung (u.a. die Ansätze von Floyd und Boehm) analysiert und klassifiziert, sowie ein umfassendes Projektmodell-Schema für das problemangepaßte Projektmanagement entwickelt. In Kapitel 3 wird die Eignung der verfügbaren Methoden und Instrumente für das Projektmanagement untersucht. Die evolutionäre Entwicklung erweist sich wegen ihrer Flexibilität in bestimmten Situationen als eine angemessene Alternative gegenüber der klassischen Methodik, es mangelt jedoch an geeigneten Methoden und Instrumenten für das Projektmanagement. In Kapitel 4 wird untersucht, auf welcher Grundlage, mit welchem Ziel und wie eine entsprechende evolutionäre Entwicklungsphilosophie zu konzipieren ist, und ein Konzept für das evolutionäre Projektmanagement entwickelt. Dieses Konzept wird in den Kapiteln 5 , 6 und 7 ausgestaltet. 6) 7) 8) 9)

Vgl. Eitzer (1989), S. 181-182. Vgl. u.a. Selig (1986), S. 182 oder DeMarco, Lister (1987), S. 4. Vgl. Floyd (1986). Vgl. Boehm (1988) und Boehm, Ross (1989).

Problemstellung und Überblick

3

In Kapitel 5 werden Ansätze für die strategische Projektplanung und -Steuerung entwickelt: ein strategisches Projektmodell, eine Portfolio-Methode für die übergreifende Steuerung evolutionärer Anwendungsentwicklungsprojekte und eine Methode für die flexible Entwicklungsplanung, die auf dem Projektmodell-Schema aus Kapitel 2 aufbaut Kapitel 6 beschäftigt sich mit Möglichkeiten zur Verbesserung der Arbeitsorganisation. Es werden eine Methode für die flexible Aufgabenplanung, ein Ansatz für die kooperative Arbeitsplanung und ein Konzept für die prozessuale Qualitätssicherung sowie entsprechende Instrumente entwickelt. Kapitel 7 stellt ein Projektmanagementsystem vor, das auf dem in Kapitel 4 entwickelten Konzept basiert und wichtige Instrumente aus 5 und 6 integriert Die Arbeit schließt mit einem Ausblick in Kapitel 8 ab.

Kapitel 1:

Projektmanagement

1.1 Begriffe Die Bedeutung des adäquaten Managements von Projekten wird seit dem Aufkommen der Projektorganisation in den 60er Jahren anerkannt. In der wissenschaftlichen Diskussion und insbesondere der anwendungsorientierten betriebswirtschaftlichen Forschung nimmt das Thema Projektmanagement seither einen festen Platz ein. Für die wissenschaftliche Diskussion und den Erfahrungsaustausch existieren mehrere Foren, u.a. die internationale Dachorganisation INTERNET, die Deutsche Gesellschaft für Projektmanagement (GPM) oder auch Arbeitsgruppen innerhalb der Deutschen Gesellschaft für Operations Research (DGOR). Es wurden viele Monographien zum Themenbereich Projektmanagement mit unterschiedlicher Ausrichtung veröffentlicht1). Auch der DiN-Ausschuß befaßte sich mit dem Themenkreis Projektmanagement; seit 1976 wurden mehrere Normen zur Klärung elementarer Begriffe entwickelt. Manche Autoren konzipieren das Projektmanagement sogar als interdisziplinäre Forschungsdisziplin mit einheitlichem Gegenstand und fachübergreifender Methodik. In letzter Zeit hat die Intensität der Diskussion etwas nachgelassen. Es entsteht der Eindruck, daß im Laufe der Jahre eine Einigung hinsichtlich grundlegender Konzepte und Methoden in Forschung und Praxis erzielt werden konnte. Zentral für das Verständnis des Projektmanagements ist der Projekt-Begriff. In DIN 69 901 findet man folgende Definitionen2); Projekt: "Vorhaben, das im wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z.B. Zielvorgabe, zeitliche, personelle oder andere Begrenzungen, Abgrenzung gegenüber anderen Vorhaben" und eine (Anm. des Verf.) "projektspezifische Organisation". Projektmanagement: "Gesamtheit von Führungsaufgaben, -Organisation, -techniken und -mittein für die Abwicklung eines Projekts". Die Definition von Projekten ist sehr allgemein gehalten; bei weiterer Auslegung fallen die meisten Nicht-Routinetätigkeiten unter diesen Begriff. Dies entspricht der umgangssprachlichen Verwendung des Projekt-Begriffs im Sinne eines "wichtigen

1) 2)

Im deutschsprachigen Raum sind u.a. Madauss (1984), Rinza (1985), Rüsberg (1985) und Saynisch et. al. (1979) bekannt, im angloamerikanischen Sprachraum u.a. Cleland, King (1989). Siehe DIN 69 901 (1987), S. 1.

Begriffe

5

Vorhabens". Es wird nicht klar, was ein Projekt bzw. das Projektmanagement gegenüber anderen einmaligen Vorhaben und deren Management unterscheidet. Aus der strategischen Sicht sind die zeitliche Begrenzung und die spezifische Organisationsform besonders wichtige Eigenschaften von Projekten3). Solche temporären Organisationsformen eignen sich für die Bewältigung von einmalig durchzuführenden Aufgaben, die eine hohe Komplexität oder Unsicherheit aufweisen, da sie die Durchführung gezielter Maßnahmen zur Sicherung des Erfolgs unabhängig von den regulären Aufgaben bzw. einmaligen Vorhaben eines Unternehmens oder einer Institution ermöglichen. Dieser Gedanke findet sich in folgender Definition wieder: Ein Projekt ist eine "zeitlich befristete, relativ innovative und risikobehaftete Aufgabe von erheblicher Komplexität, die aufgrund ihrer Schwierigkeit und Bedeutung meist ein gesondertes Projektmanagement... erfordert" 4). Die Zirkularität dieser Definition ist unbefriedigend, dennoch bietet sie praktische Vorteile gegenüber der Dm-Norm. Gegenstand eines Projekts ist danach eine Aufgabe bzw. ein zielgerichtetes, inhaltlich abgeschlossenes Vorhaben. Der Aufgabe wird eine besondere Bedeutung beigemessen, es werden deshalb bestimmte Personal- und Sachmittel bereitgestellt. Die Realisierung der Ziele ist in Bezug auf die üblichen (Routine-) Aufgaben schwierig. Sie unterscheidet sich weiter gegenüber üblichen Vorhaben durch spezifische, auf die Erfordernisse der auszuführenden Aufgabe ausgerichtete organisatorische Maßnahmen sowie eine temporäre Organisationsform. In der Literatur findet man weitere Kriterien zur Explikation des Projekt-Begriffs. Pinkenburg stellt mehrere Projektdefinitionen einander gegenüber5). Manche Autoren stellen institutionelle Aspekte (die temporäre Organisationsform), und andere das Vorhaben bzw. spezifische Arten von Aufgaben in den Vordergrund6). Die Definition des Projekt-Begriffs hängt offenbar von dem jeweiligen Standpunkt ab. Für diese Arbeit soll folgende Arbeitsdefinition zugrundegelegt werden: Ein Projekt ist ein Vorhaben, das - auf die Realisierung eines bedeutenden Ziels ausgerichtet, - mit spezifischen Sach- und Personalmitteln ausgestattet und - besonders schwierig, weil komplex, innovativ und/oder risikoreich ist, sowie - in einer temporären Organisationsform ausgeführt wird. Wendet man diese Arbeitsdefinition auf die DiN-Definition an, umfaßt das Projektmanagement O

3) 4) 5) 6)

einen institutionellen Aspekt, d.h. die Gruppe, den Träger bzw. die temporär

In Henzler (1989) wird die aktuelle strategische Bedeutung temporärer Organisationsfonnen wie Projektgruppen herausgestellt. Siehe Gablers... (1989), Sp. 1056. Siehe Pinkenburg (1980), S. 101. Vgl. Pinkenburg (1980), S. 100.

6

Projektmanagement

konstituierte organisatorische Einheit, die projektbezogene Führungsaufgaben ausführt, O

einen fimktionalen Aspekt, d.h. die Gesamtheit aller Führungsaufgaben, die erforderlich sind, um das Projektziel zu erreichen, u.a. Maßnahmen zur Bewältigung von spezifischen Projektschwierigkeiten (Komplexität und Risiko) und

O

einen methodischen Aspekt, d.h. die Vorgehensweise, FUhrungstechniken und mittel zur Abwicklung eines Projekts.

Während hinsichtlich des Projekt-Begriffs - abgesehen von verschiedenen Perspektiven - in der Literatur ein grundsätzlicher Konsens besteht, divergieren die Auffassungen über das Projektmanagement7). So umfaßt der Begriff bei einigen Autoren hauptsächlich den funktionalen Aspekt, insbesondere die Planung. Dabei wird oft das methodische Instrumentarium in den Vordergrund gestellt. Andere betonen den institutionellen Aspekt; in einer sehr engen Begriffsfassung wird von der Einrichtung einer spezifischen Stelle ausgegangen. Diese Explikation betont die eher technische Seite des Projektmanagements. Zum Management gehört jedoch neben der Management-Technik bzw. den sachbezogenen Aktivitäten auch eine personenbezogene Seite, die Menschenßhrung*\ In der Literatur wird dieser Aspekt oft ausgeklammert bzw. nicht berücksichtigt und insbesondere die Planung und Kontrolle der Projektaufgaben in den Vordergrund gestellt. Die Interpretation und Ausgestaltung des Projektmanagements sind also - wie der Projekt-Begriff - von der jeweiligen Perspektive und dem verfolgten Ziel abhängig. Innerhalb dieser Arbeit wird aus der Perspektive der Wirtschaftsinformatik der methodische Aspekt des Projektmanagements und die Management-Technik in den Mittelpunkt gestellt9). Die menschenbezogene Seite des Projektmanagements wird dabei nicht außer acht gelassen. So besteht z.B. ein enger Zusammenhang zwischen Führungsstil und Projektmanagement-Methodik10). Nach Koontz, O'Donnel können mit dem Einsatz sachbezogener Management-Aktivitäten nur etwa 60-65% der Leistungsbereitschaft eines Mitarbeiters aktiviert werden"). Soweit dies für die Dis

7) 8)

Vgl. Frese in Grochla (1980), Sp. 1961. Zur Unterscheidung zwischen sacb- und personenbezogenen Managementaktivitäten vgl. Staehle (1985); zur Unterscheidung zwischen Management-Technik und Menschenführung Rühli in Grochla (1980) Sp. 1253. 9) Ein Schwerpunkt der Wiitschaftsinformatik ist der Prozeß der Entwicklung betrieblicher und insbesondere betriebswirtschaftlicher Informationssysteme. Aus dem anwendungsorientierten Selbstverständnis der Wirtschaftsinformatik sind planmäßige Vorgehens weisen, Führungstechniken und -mittel interessant, die Unterstützung bei der Lösung konkreter Anwendungsprobleme bieten, also praxisrelevante methodische Ansätze. Zum Erkenntnisobjekt und zur Aufgabe der Wiitschaftsinformatik siehe Kurbel, Strunz (1990b). 10) Empirische Befunde belegen, daß die Effizienz einer spezifischen Organisation insbesondere durch interne prozessuale Aspekte wie z.B. das Führungsverhalten beeinflußt wird; vgl. Staehle (1985), S. 485. 11) Vgl. Koontz, O'Donnell (1976), S. 587.

Begriffe

7

kusion der Methoden und Techniken notwendig ist, werden deshalb Aspekte der Menschenführung in die Betrachtung einbezogen. Um die Anwendbarkeit des Projektmanagements auf Projekte mit einem bestimmten Gegenstand - die Entwicklung betrieblicher Informationssysteme12) - zu untersuchen, ist es wichtig zu wissen, welche Ansätze es überhaupt gibt und unter welchen Bedingungen sie Vor- und Nachteile offenbaren. Deshalb werden im folgenden verbreitete Projektmanagement-Ansätze hinsichtlich der Prämissen, Ziele, Vorteile und Grenzen erörtert und anschließend charakteristische Eigenschaften von Projekten zur Beurteilung der Anwendbarkeit von Projektmanagement-Ansätzen herausgearbeitet.

1.2

Projektmanagement-Ansätze

Eine umfassende Klassifikation der unterschiedlichen Projektmanagement-Ansätze ist wegen der unterschiedlichen Zielsetzungen, Anwendungsgebiete und Perspektiven innerhalb der Projektmanagement-Literatur schwierig und nicht im Rahmen dieser Arbeit durchführbar. Dem Autor ist kein Versuch einer umfassenden Klassifikation bestehender Ansätze bekannt. Beim Studium der Literatur fällt jedoch die Affinität verschiedener Ansätze zu unterschiedlichen Management-Lehren auf. So weist u.a. das Phasenorientierte Projektmanagement von Saynisch13) Elemente eines "Management-Process"-Ansatzes auf, das Systems Project Management von Rüsberg14) bzw. das Systemorientierte Projektmanagement von Zogg15) können als systemorientierte Management-Konzepte interpretiert werden, Krüger fordert ein problemangepaßtes Projektmanagement16), und Hansel, Lomnitz plädieren für einen ganzheitlichen Ansatz17) im Sinne eines situativen Management-Konzepts. Für die Erörterung unterschiedlicher (Projekt-) Management-Perspektiven innerhalb dieser Arbeit soll keine umfassende Einteilung entwickelt werden, sondern vielmehr ein praktikables Schema zugrunde gelegt werden. In diesem Sinne werden die unterschiedlichen Projektmanagement-Ansätze vereinfachend in Verbindung mit unterschiedlichen allgemeinen Management-Lehren diskutiert In den folgenden Abschnitten werden fünf unterschiedliche Ansätze dargestellt18), die im einzelnen mit den Management-Lehren19) des "Scientific Management", der "Management-Process

12) 13) 14) 15) 16) 17) 18)

Zur Einordnung der Wirtschaftsinformatik vgl. Fußnote 9. Vgl. Saynisch (1979a). Vgl. Rüsberg (1985). Vgl. Zogg (1984). Vgl. Krüger (1987). Vgl. Hansel, Lomnitz (1987). Diese Reihenfolge gibt ungefähr die Stellung der einzelnen Ansätze in der Entwicklungsgeschichte des Projektmanagements wieder. 19) Riihli erläutert in Grochla (1980), Sp. 1252 ff. den Begriff der Management-Lehre und gibt eine Übersicht über einzelne Vertreter; die geschichtliche Entwicklung des Management und unterschiedlicher Management-Schulen skizziert Staehle (1985), S. 2 ff. bzw. 10 ff.

8

Projeklmanagement

School", dem systemorientierten Ansatz, der verhaltensorientierten Schule sowie dem situativen Ansatz korrespondieren. 1.2.1 Klassische Jogistische Ansätze Der traditionelle Projektmanagement-Ansatz stammt aus Anwendungsgebieten wie dem Bauwesen und der industriellen Fertigung. Schon in den ausgehenden 60er Jahren stellte man fest, daß größere Entwicklungsvorhaben nicht mehr allein in den klassischen funktionalen Organisationsstrukturen durchgeführt werden können, sondern eine besondere Organisationsform und spezifische -mittel erfordern. Der Entwurf derartiger Organisationsformen wurde insbesondere im Zuge des enormen Wachstums der amerikanischen Luft- und Raumfahrtindustrie vorangetrieben20). Für die Durchführung großer Entwicklungsvorhaben wurden aus unterschiedlichen Organisationseinheiten bestimmte Mitarbeiter teilweise oder ganz für Projektaufgaben abgestellt. Die reguläre Aufbau- und Ablauforganisation wird also durch eine temporäre Projekt-Organisation überlagert. Anders als bei einer hierarchischen, verrichtungsorientierten Linienorganisation gehören damit alle an der Durchführung eines Vorhabens Beteiligten einer Organisationseinheit an, und deren Entwicklungsaktivitäten können besser koordiniert werden. Eine Projektorganisation eignet sich insbesondere für solche Entwicklungsvorhaben, die auf die Erstellung eines Produkts abzielen, das aus vielen unterschiedlichen Komponenten besteht und an dessen Entwicklung verschiedene Stellen oder auch externe Zulieferer beteiligt sind. Die Arbeitsorganisation innerhalb des Projektes kann dann aus der funktionalen Unterteilung des Endproduktes abgeleitet werden. Diese Form der Arbeitsorganisation steht in der Tradition der klassischen Managementlehre des Scientific Management, als dessen Begründer der amerikanische Ingenieur F.W. Taylor gilt21). Mit dem Ziel einer möglichst effizienten Arbeitsausführung soll danach jede repetitive Aufgabe nach objektiven Kriterien in einzelne Arbeitsschritte unterteilt und von eigens dafür ausgebildeten Spezialisten ausgeführt werden. Die Komplexität der Gesamtaufgabe wird durch Unterteilung in einzelne Arbeitsschritte und Verteilung der Teilaufgaben auf speziell ausgebildetes Personal reduziert. Als Grundlage für die Untergliederung dient die technische Konstruktionszeichnung. Dieser Plan weist eine hierarchische Struktur auf, d.h. jeder Arbeitsschritt wird innerhalb einer direkt übergeordneten Arbeitsfolge ausgeführt. Ein wichtiges Ziel im Rahmen des Scientific Management ist die Standardisierung, d.h. es sollen Arbeitsgänge gefunden werden, die in unterschiedlichen Arbeitszusammenhängen durchgeführt werden können.

20) 21)

Vgl. u.a. Staehle (1985), S. 424. Vgl. Rühli in Grochla (1980), Sp. 1257.

Projektmanagement-Ansätze

9

Zwar bestehen Projekte in der Regel nicht nur aus repetitiven Tätigkeiten, jedoch ähneln sich die Arbeitsschritte bei manchen Entwicklungsvorhaben. Bei bestimmten Projekten in der Luft- und Raumfahrtindustrie oder im Baubereich werden z.B. vorhandene Konstruktions- und Arbeitspläne aus älteren Projekten ist für die Untergliederung neuer Vorhaben in einzelne, klar abgegrenzte Arbeitsschritte eingesetzt. Durch die Identifikation einzelner Arbeitsschritte können einzelne Arbeiten delegiert und damit die Komplexität des Gesamtvorhaben reduziert werden. In dieser klassischen, tayloristischen Projektmanagement-Philosophie wird davon ausgegangen, daß die Bestimmung dieser Einzelaufgaben ein eher (ingenieur-) technisches Problem darstellt und die zentrale Führungsaufgabe in deren Koordination, insbesondere der Termin- und Kapazitätsplanung und -Steuerung, besteht. Innerhalb dieses Ansatzes werden also im weiteren Sinne logistische Fragestellungen in den Mittelpunkt gestellt22). Die entsprechenden Projektmanagement-Methoden zielen insbesondere auf die Verbesserung der Termin-, Einsatz- und Kostenplanung und -Überwachung ab. Eine der ersten dedizierten Projektmanagement-Techniken, die Critical Path Method (CPM))23), wurde bezeichnenderweise für Bau- und Reparaturvorhaben entwickelt, bei denen ca. 90 Prozent der Arbeitsgänge im voraus bekannt sind24). Die Entwicklung logistisch orientierter Methoden und Instrumente für das Projektmanagement wurde in den USA insbesondere vom Department of Defense (DoD) vorangetrieben, das bestimmte, in diesem Zusammenhang entwickelte Methoden sogar für die an Großprojekten beteiligten Auftragnehmer vorschreibt25). Die dort übliche strenge Formalisierung der Arbeitsabläufe hinterließ in den klassischen Methoden ihre Spuren. Einen weiteren wichtigen Anwendungsbereich stellt der Großanlagenbau dar. Auch hier handelt es sich um komplexe Aufgaben, die den Rahmen einer Linienorganisation sprengen. Versorgungsengpässe verursachen erhebliche Kosten, sei es in Form von Lagerhaltungskosten, ungenutzten Betriebsmitteln oder durch Regressansprüche der Auftraggeber bei Terminverzug. Bei kundenauftragsspezifischer Fertigung eignet sich ein Projektmanagement-Ansatz für die Lösung logistischer Probleme in der Fertigungsindustrie. Beim logistisch-orientierten Projektmanagement wird davon ausgegangen, daß O

ein klar definiertes Ziel vorgegeben wurde,

O

dieses Ziel direkt in eine funktionale Spezifikation des Ergebnisses umgesetzt werden kann und

22) Eine umfassende Definition der Logistik geben Jünemann et. al. (1989), S. 11: "Logistik ist die wissenschaftliche Lehre der Planung, Steuerung und Überwachung der Material-, Personen-, Energie- und Informationsflüsse in Systemen." 23) Zu den Ursprüngen von CPM siehe u.a. Weber (1963a). 24) Vgl. Falkenhausen (1972), S. 23. 25) Vgl. u.a. Schmelzer (1986), S. 14.

10

O

Projektmanagement

für die Realisierung des Ergebnisses eine operatíonale Anweisung z.B. in Form eines Konstruktionsplans vorhanden ist.

Diese Auffassung spiegelt sich u.a. in den Definitionen des Projektmanagements unterschiedlicher Autoren, insbesondere in der detaillierten Definition der Ergebnisse vor Projektbeginn und einem an technischen Konstruktionsprozessen orientierten Vorgehensmodell wider. Bei unklaren bzw. nur schwer operationalisierbaren Zielen wie z.B. bei Aufgabenstellungen im Bereich der Forschung und Entwicklung ist dieser klassische Ansatz nur sehr begrenzt operabel. Für derartige Projekte wurden deshalb alternative Ansätze entwickelt. Man spricht in diesem Zusammenhang oft auch von FuE-Projektmanagement26*. 1.2.2 Der Projekt-Lebenszyklus Wie das Scientific Management ist auch der logistische Projektmanagement-Ansatz insbesondere auf die Fertigungsorganisation ausgerichtet und stellt keine allgemeine Managementlehre dar. Ein umfassendes Führungskonzept wurde - aufbauend auf den Arbeiten von Fayol27) - im Rahmen der sogenannten Management-Process-School entwickelt28). Es wird davon ausgegangen, daß das "Führungshandeln in eine Abfolge von generell feststellbaren Leitungs-akten zerlegt werden kann"29\ die sich allgemein beschreiben und auf unterschiedliche Probleme und Anwendungsgebiete anwenden lassen. Prozessuale Managementansätze sind für das Projektmanagement von herausragender Bedeutung. In einem Standardwerk zum Projektmanagement neueren Datums findet man folgendes Dogma30): "Project management teaches that to achieve the desired project objective one must go through a specific process. There is no exception to this rule. The process is known as the project 'life cycle' "31). Analog zum Konzept des Produkt-Lebenszyklus aus dem Marketing wird davon ausgegangen, daß Projekte im Verlauf der Zeit eine Folge inhaltlich zusammenhängender Entwicklungsstadien, einen Projekt-Lebenszyklus, durchlaufen.

26) 27) 28)

Vgl. u.a. Schmelzer (1986), S. 1. Vgl. Fayol (1916). Bedeutende Vertreter dieser Schule sind u.a. Koontz und ODonnell; vgl. Koontz, O'Donnell (1964). 29) Siehe Rühli in Grochla (1980), Sp. 1258. 30) Es handelt sich um das vom Institute of Industrial Engineer's mit dem Book-of-the-year award prämierte "Handbook of Project Management", das 1988 in einer zweiten Auflage erschienen ist; vgl. Cleland, King (1988), S. III. 31) Siehe Morris (1988) und Cleland, King (1988), S. 19.; vgl. auch Madauss (1990), S. 62: "Jedes neue und zum Zeitpunkt der Projektidee noch nicht existierende Produkt muß bis zum endgültigen Projektabschluß, das heißt bis zur Aussonderung des Systems, den... Lebenszyklus durchlaufen."

Projektmanagement-Ansätze

11

Der Produkt-Lebenszyklus kann als ein idealisiertes Modell zur Beschreibung der Marktdynamik interpretiert werden; üblich ist eine Unterteilung in die fünf Phasen Einführung, Wachstum, Reife, Sättigung und Degeneration. Die Phaseneinteilung ist dabei relativ willkürlich32). Idealtypischerweise wird ein S-förmiger Verlauf der Gewinnkurve im Zeitablauf angenommen. Die Kosten sind in den frühen Stadien hoch, der Umsatz erreicht gewöhnlich im Reifestadium seinen Höhepunkt. So ist der Cash flow in den frühen Phasen negativ und wird erst in einer späteren Phase positiv. Der Projekt-Lebenszyklus wird ebenfalls durch die Vorgabe von Phasen beschrieben. Madauss gibt folgendes allgemeine Phasenschema an33): A) Konzept B) Definition C) Entwicklung D) Produktion und Beschaffung E) Betrieb und Wartung F)

Aussonderung

Einnahmen Verkanfsvnlnmpj

Entwicklungskosten

2

4

6 Aussonderung (Phase F) Beschaffungs- und Betriebsphasen(Phasen D und E)

Finanzierung^ ^kosten

Entwicklungsphasen (Phasen A, B und C) -Lebenszyklus

Gewinnbringender Betrieb (Jahre) -

Ausgaben

Abb. 1-1:

32) 33)

34)

Finanzielle Betrachtung des Projekt-Lebenszyklus34)

Vgl. Meffeit (1980), S. 339. Die Phasen A) bis C) faßt Madauss auch unter dem Oberbegriff Forschung und Entwicklung zusammen; zu den einzelen Phasen vgl. Madauss (1990), S. 63 ff., zur Allgemeingültigkeit des Phasenschemas vgl. Madauss (1990), S. 62 und 64. Einen Überblick über unterschiedliche Phasenmodelle gibt u.a. Saynisch (1979b), S. 103. Nach Madauss (1990), S. 63.

12

Projektmaiiagement

Dabei unterstellt er ebenfalls eine idealtypische S-förmige Gewinnkurve. Abbildung 1-1 zeigt eine idealisierte Darstellung des Projekt-Lebenszyklus aus der finanziellen Perspektive. Die Einteilung von Projekten in einzelne Phasen ist nicht wie der Produkt-Lebenszyklus deskripitiv und relativ willkürlich, sondern normativ und zielgerichtet. Sie definiert eine normative Sequenz inhaltlich zusammenhängender Aufgabenbereiche, denen jeweils - im Sinne der Management-Process-School - bestimmte Klassen von Leitungsakten zugeordnet werden können. So können die Konzeptformulierung und die Ergebnisdefinition als spezifische Planungsakte interpretiert werden; im Rahmen der Entwicklung sind insbesondere Überwachungsaufgaben durchzuführen. Die Einteilung des Entwicklungsverlaufs in disjunkte Phasen wird in der Literatur durchgängig als einer der wichtigsten Ansätze für das Projektmanagement angesehen35). Der idealisierte Projekt-Lebenszyklus wird Uberwiegend im Sinne eines sequentiellen Ablaufmodells interpretiert, d.h. die einzelnen Phasen werden nacheinander und in einer bestimmten Reihenfolge durchlaufen. Nach Abschluß jeder Phase können Teilergebnisse kontrolliert und die Wirtschaftlichkeit des Projekts überprüft werden. Dabei wird top-down vom Abstrakten, Allgemeinen hin zum Konkreten, Speziellen verfahren. Bei den meisten Ansätzen sind gewisse Überschneidungen zwischen den einzelnen Phasen möglich. Abbildung 1-2 zeigt Möglichkeiten der Phasenüberlappung für das o.a. Lebenszyklusmodell. 'Beginn Phase A 'Ende Phase A Beginn Phase B

1

B

< Ende Phase B Beginn Phase C

j^Ende Phase C Beginn Phase D

Legende IBS

Einleitung terminkritischer Phase C - Arbeiten Einleitung terminkritischer Phase D - Arbeiten

ZM

Zwischenmeilenstein

EZZ2

D

Abb. 1-2: Möglichkeiten der Phasenüberlappung36)

In der Projektmanagement-Praxis gehören Phasenmodelle zu den wichtigsten Projektmanagement-Ansätzen. Empirische Untersuchungen bestätigen dies auch für den 35) Vgl. u.a. Burwick in Grochla (1980) Sp. 1953, Frese in Grocbla (1980) Sp. 1962, Madauss (1990), S. 62 ff., Platz (1986), S. 107 ff., Rinza (1985), S. 42 ff., Saynisch (1979a). 36) Nach Madauss (1984), S. 72.

Projektmanagement-Ansätze

13

Bereich des Software-Projektmanagements37). Es gibt mehrere Gründe für deren Beliebtheit: O

Einfachheit: Durch die Aufteilung des Gesamtvorhabens in wenige Einzelphasen wird das Projekt überschaubarer und die Komplexität bei der Durchführung jeder einzelnen Phase reduziert.

O

Einheitlichkeit: Phasenmodelle sind für die Anwendung auf unterschiedliche Projekte konzipiert. Damit erleichtern sie Einarbeitung und Kommunikation sowohl innerhalb des Projekts als auch nach außen.

O

Orientierung: In jeder Phase werden Aufgaben mit ähnlicher Zielrichtung zusammengefaßt. Alle Aktivitäten können daran orientiert und gebündelt ausgeführt werden. Damit wird eine "Zersplitterung" vermieden.

O

Kontrolle: Nach jeder einzelnen Phase kann eine umfassende inhaltliche Aufgabe innerhalb des Projekts überprüft und abgeschlossen werden.

Trotz der offensichtlichen Vorteile und der Beliebtheit in der Praxis steht der wissenschaftliche Nachweis der grundsätzlichen Vorteilhaftigkeit einer Aufteilung des Entwicklungsverlaufs in bestimmte Aufgaben-"Bündel" noch aus. In der betriebswirtschaftlichen Literatur wurde die Vorteilhaftigkeit einer prozessualen Unterteilung für komplexe Entscheidungen ausgiebig diskutiert; man spricht in diesem Zusammenhang von einem Phasen-Theorem38>. Empirische Untersuchen zeigen, daß nicht von einer Allgemeingültigkeit des Phasentheorems ausgegangen werden kann und erhebliche Einschränkungen und Differenzierungen erforderlich sind39). Hauschildt und Petersen kritisieren, daß diese Ergebnisse sowohl in der Praxis als auch teilweise der anwendungsorientierten Forschung, insbesondere bei "Studien aus der Wirtschaftspraxis zur Steuerung von Innovationsprojekten"40) - bzw. dem FuE-Projektmanagement - ignoriert werden. Sie messen der klassischen verrichtungsorientierten Phasenorganisation "allenfalls den Charakter einer 'Behelfsorganisation der ersten Stunde'" zu, "der man sich so lange bedient, wie die innovative Materie intellektuell noch nicht durchdrungen ist"41). Aus der Perspektive des logistischen Ansatzes kann man daraus schließen, daß eine Phasenorganisation bei innovativen Projekten so lange notwendig ist, bis eine stabile Zerlegung des Gesamtprojekts in Teilergebnisse bzw. Aufgaben angegeben werden kann. Die Projektmanagement-Methodik sollte deshalb auf den Entwurf und die Umsetzung einer adäquaten "Zerlegungsstruktur" ausgerichtet sein - dazu eignet sich insbesondere ein systemorientierter Ansatz.

37) 38) 39) 40) 41)

Vgl. u.a. Selig (1986), S. 219 oder Lehmann (1979), S. 120. Vgl. u.a. Witte (1968), S 581 f. Vgl. u.a. Hauschildt, Petersen (1987), S. 1047. Siehe Hauschildt, Petersen (1987), S. 1045 und vgl. S. 1047. Siehe Hauschildt, Petersen (1987), S. 1060.

14

Projektmanagement

1.2.3 Systemorientierte Ansätze Beim System-Ansatz für das Management wird ein besseres Verständnis komplexer Problemzusammenhänge angestrebt sowie konkrete Gestaltungsempfehlungen durch ein Denken in Systemen42). 1.2.3.1 Systemtheorie Ein System ist nach Ulrich "eine geordnete Gesamtheit von Elementen, zwischen denen irgendwelche Beziehungen bestehen oder hergestellt werden können"43). Die einzelnen Elemente können wiederum Systeme darstellen. Ein Gesamtsystem besteht aus einer Hierarchie von Teilsystemen. Im Rahmen der Allgemeinen Systemtheorie44) wird versucht, wichtige allgemeingültige Eigenschaften von Systemen zu erforschen. Dabei stehen theoretische Aspekte der Modellierung und Interpretation im Mittelpunkt. Die Praxis zeigt, daß die Systemtheorie in ihrer allgemeinen Form (General systems theory) auf reale Probleme nicht direkt angewendet werden kann; der Anspruch auf Universalität erschwert die Entwicklung probater Methodologien. Umfassende Löungen sind nur schwer zu realisieren45). In verschiedenen Anwendungsbereichen konnten dennoch konkrete Systemansätze entwickelt und erfolgreich eingesetzt werden. System und Systemansatz entwickelten sich dabei im Laufe der Zeit immer mehr zum Modebegriff für komplexe Zusammenhänge und Vorhaben. Vermuri stellt fest: "Eventually, 'systems' and 'systems approach' stood to mean 'anything' ',46). Dennoch kann man festhalten, daß der Systemansatz fast ausschließlich im Zusammenhang mit der Konstruktion eines Modells als Basis für die Lösung von Problemen genutzt wird47). In der praktischen Anwendung des Systemansatzes für das Management wird davon ausgegangen, daß durch die adäquate Modellierung eines Ausschnitts der betrieblichen Realität in Form von Komponenten und Relationen Einsichten über Zusammenhänge und Möglichkeiten der Beeinflussung gewonnen werden können. Systemorientiertes Management bedeutet also Steuerung komplexer Sozialsysteme48). Für die konkrete Anwendung der Systemtheorie auf das Projektmanagement müssen drei Voraussetzungen erfüllt werden:

42) 43) 44) 45) 46) 47) 48)

Zur Einordnung eines System-Ansatzes für das Management vgl. u.a. Rübli in Grochla (1980), Sp. 1260 f. oder Stachle S. 35 f. und S. 87 f. Vgl. Ulrich (1970), S. 105. Im englischsprachigen Raum auch als General systems theory bezeichnet; Ursprünge in Bertalanffly (1951). Vgl. u.a. Wood-Harper, Fitzgerald (1982), S. 12. Siehe Vermuri (1978), S. 25. Vgl. Vennuri (1978), S. 25. Vgl. Rühli in Grochla ( 1980), Sp. 1260.

Projektmanagement-An Sätze

15

O

Es müssen relevante Realitätsausschnitte bzw. Kriterien zu deren Identifikation gefunden werden.

O

Diese Realitätsausschnitte müssen mit vertretbarem Aufwand modelliert werden können.

O

Das Modell muß bei der Ausführung von Projektmanagement-Aufgaben behilflich sein, u.a. zu Einsichten Uber die Realität verhelfen und als Grundlage für konkrete Aktionen genutzt werden können.

1.2.3.2 Projekte als Systeme Ein möglicher Realitätsausschnitt ist das Projekt selbst, z.B. aus der Perspektive eines logistischen Projektmanagement-Ansatzes. Die einzelnen Arbeitsschritte (Elemente) sind sequentiell gegliedert (Relationen). Jeder Teilarbeitsschritt läßt sich wiederum in eine Arbeitsfolge untergliedern (hierarchische Differenzierung in Untersysteme), bis Arbeitsschritte gefunden werden, deren Untergliederung als nicht sinnvoll erachtet wird. Es werden hauptsächlich die konstruktionstechnisch vorgegebenen Komponenten und zeitlichen Relationen berücksichtigt (Reduktion der Komplexität). Das logistische Projekt-System stellt ein reduktionistisches und normatives Realitätsmodell dar. In der betrieblichen Softwareentwicklungs-Praxis partizipieren viele unterschiedliche Gruppen, sowohl intra-institutionelle Organisationseinheiten als auch - bei Vergabe von Aufträgen oder durch Erbringung von Leistungen für Kunden - externe Stellen. Nicht nur die Umwelt eines Projekts ist eine mögliche Quelle für Wechselwirkungen; sowohl der fachliche als auch der soziale Kontakt zwischen den einzelnen Projektmitgliedem ist zu berücksichtigen. Die Liste der Projektkomponenten und -relationen läßt sich beliebig fortsetzen. In Abbildung 1-3 wird eine systemorientierte Darstellung des institutionellen Projektmanagements gegeben. An der Grafik wird die Komplexität der organisatorischen Verflechtungen eines Projekts deutlich. Das Projekt (PK) ist in die Trägerorganisation (K) eingebettet und der Unternehmensleitung (L) unterstellt. Es kann (z.B. anhand der Aufgabenstellung) in unterschiedliche Teilprojekte (PK¡) unterteilt werden. Die Teammitglieder sind, unabhängig von dem Projekt, unterschiedlichen organisatorischen Einheiten zugeordnet, das Projekt (PK¡) überlagert also andere organisatorische Einheiten (LKJ). Neben den internen organisatorischen Verflechtungen existieren Beziehungen zu externen Organisationseinheiten, die Aufträge für das Projekt ausführen (A¿). Bereits für ein kleineres konkretes Projekt ist der Aufwand für die Konzeption eines realistischen Modells sehr hoch und die Anwendbarkeit des Modells zudem auf die rein funktional-logischen Aspekte der Arbeitsorganisation begrenzt49). Innerhalb komplexer sozio-technischer Systeme wie den meisten Entwicklungsprojekten kann

49) Vgl. Zogg (1974), S. 65.

16

Projektmanagement

J ;

Abb. 1-3:

PLK

Systemorientierte Darstellung des institutionellen Projektmanagements30)

davon jedoch nicht ausgegangen werden. Soziale und psychologische Faktoren spielen hier eine sehr wichtige Rolle51). Eine umfassende Modellierung aller möglichen Komponenten und Faktoren eines Projekts ist nur schwer möglich und sicherlich nicht sinnvoll. Der Wert dieses Ansatzes liegt darin, daß er eine erweiterte Perspektive des Projektmanagements ermöglicht Diese Erkenntnis schlägt sich in den Projektmanagement-Philosophien einiger Autoren wieder, die für das Projektmanagement einen ganzheitlichen, interdisziplinären Ansatz fordern52). 1.2.3.3 Systemanalytische Ansätze Ein weiterer möglicher Realitätsausschnitt für die Systembetrachtung ist das zugrundeliegende Anwendungsproblem. Betrachtet man dieses Problem als eine Differenz zwischen einem Ist- und einem angestrebten Soll-Zustand eines bestimmten (betrieb-

50) Nach Zogg (1974), S. 257, 94. Legende: L = Leitungsfunktion, K = ausführende Organisationseinbeiten, LK = organisatorische (Unter-)Einheit, PT = dem Projekt übergeordnete Leitung, PL = Projektleitung, PK = Projekt, PLK = Projekt-(Teil-)Team, A = Subkontraktoren. 51) Vgl. später Abs. 1.2.4; zum Begriff des sozio-technischen Systems vgl. später Abs. 1.4.1. 52) Vgl. u.a. Madauss (1984), S. 8.

Projektmanagement-An sätze

17

liehen) Systems53), so erfordert eine systemorientierte Lösung die eingehende und systematische Analyse des Ist- und den Entwurf eines Soll-Zustands sowie die Veränderung der Realität von einem Ist- zu einem Soll-Zustand. Bei einer streng analytischen Vorgehensweise wird das Ausgangsproblem anhand eines theoretischen Modells in einzelne Bestandteile zerlegt. Anschließend wird eine Lösung des Problems durch Anwendung allgemeiner Aussagen über Eigenschaften und Wirkungszusammenhänge des theoretischen Modells deduziert. Die Aussagen sollen O

die Verfügbarkeit einer umfassenden, problemadäquaten und verläßlichen theoretischen Basis in bezug auf das Ist-System sowie

O

eine korrekte Modellierung des Ist-Systems in Hinblick auf die verwendete Theorie

klären. Anwendungsbeispiele sind neben mathematischen Problemen spezifische, klar determinierte technische Konstruktionsprobleme wie z.B. die Konstruktion (einfacher) elektronischer Schaltkreise. Nur in wenigen Anwendungsbereichen kann streng analytisch vorgegangen werden. Eine adäquate Modellierung auf der Grundlage einer umfassenden Theorie ist bei praktischen Problemen nur selten durchführbar. Ein Ist-System kann außerdem oft auf verschiedene Arten interpretiert und entsprechend modelliert werden. Dies gilt insbesondere für Systeme mit sozialen Komponenten wie allen betrieblichen Anwendungssystemen. Für die Lösung von Problemen innerhalb derartiger Systeme sind neben theoretischen auch empirische Erkenntnisse erforderlich. Voraussetzung für die Analyse ist hier die Beobachtung konkreter Zusammenhänge. Diese Beobachtungen können zerlegt und theoretischen Konzepten zugeordnet, d.h. analysiert werden. Da mehrere Deutungsansätze möglich sind, ist für die Modellierung des Soll-Zustands eine Auswahl oder auch eine Kombination mehrerer Lösungsansätze erforderlich. Man spricht in diesem Zusammenhang auch von Synthese. Erweitert man den streng analytischen Ansatz um synthetische Elemente, erhält man ein Modell eines Problemlösungsprozesses, das mit der Systemanalyse verbunden wird54>. Der relevante Realitätsausschnitt richtet sich erstens nach dem Ausgangsproblem (welche Theorien oder Modelle sind überhaupt anwendbar?) und zweitens nach der spezifischen Theorie (welche empirischen Daten sind für diese Theorie erforderlich?). Beschreibungsebene und Detaillierungsgrad können je nach Ziel und Problemstellung variiert, spezifische oder vereinfachende Theorien angewendet oder evtl. auch kombiniert werden. Aus dem Modell des Problemlösungsprozesses kann ein spezifisches Vorgehensmodell abgeleitet werden. Grundsätzlich kann der Problemlösungsprozeß in drei Schritte unterteilt werden: 53) Vgl. Zogg (1974), S. 7. 54) Vgl. u.a. Koreiman (1972), S. 15.

18

®

Projektmanagement

Analyse, d.h. Aufnahme des Ist-Zustands bzw. Definition des Ausgangsproblems,

@ Synthese, d.h. Interpretation des Ist-Zustands auf der Basis mehrerer Theorien, Entwurf eines oder mehrerer Lösungsvorschläge und evtl. Auswahl eines Vorschlags, ® Realisierung der Lösung, d.h. Transformation des Systems vom Ist-Zustand zum Soll-Zustand. Durch eine weitere Detaillierung des Problemlösungsprozesses - z.B. durch Unterteilung der Synthese in einen Fein- und einen Detailentwurf und die Realisierung in Konstruktion und Einführung - ergibt sich ein Phasenmodell im Sinne eines Lebenszyklusmodells. Wie beim Projekt-Lebenszyklus sind auch bei systemanalytischer Vorgehensweise in der Praxis bestimmte Überschneidungen zwischen den einzelnen Arbeitsschritten bzw. Phasen möglich. Die grundsätzliche Linearität des Entwicklungsverlaufs wird jedoch beibehalten und die Analyse als notwendige Voraussetzung für die Systemgestaltung angesehen. Systemanalytische Ansätze sind insbesondere dann vorteilhaft, wenn folgende Voraussetzungen erfüllt sind: O

Zuverlässigkeit analytischer Erkenntnis: Die wichtigsten Determinanten des Ausgangsproblems müssen korrekt erfaßt werden können;

O

Stabilität der Ausgangsbedingungen im Zeitablauf: Die Voraussetzungen für eine Problemlösung dürfen sich nicht ändern, bevor die Lösung genutzt wurde;

O

Angemessenheit der Theorien: Durch die Veränderung vom Istzustand zum Sollzustand muß die Ausgangssituation wirklich verbessert werden.

Handelt es sich bei dem zu gestaltenden Zielsystem um ein technisches Produkt, kann man davon ausgehen, daß diese Voraussetzungen erfüllt sind bzw. das Risiko mit naturwissenschaftlichem Verfahren relativ verläßlich eingegrenzt werden kann. Bei vielen betrieblichen Anwendungen ist dies eher fraglich. Zu den Anforderungen im einzelnen: O

Aus der ersten Voraussetzung resultieren hohe Anforderungen an die menschliche analytische Erkenntnisfähigkeit. Bestimmte Aspekte der menschlichen Problemlösungsfähigkeit können nur eingeschränkt und heuristisch modelliert werden55);

O

Der teilweise rasante organisatorische und technische Wandel ist mit der Anforderung an die Stabilität der Ausgangsbedingungen nicht vereinbar; die Lernbzw. Adaptionsfähigkeit von Organisationen wird nicht berücksichtigt56);

55) 56)

Johnston spricht von "reconstructed methods"; vgl. Johnston (1983), S. 81. Zur Evolutionsfähigkeit betrieblicher Organisationen vgl. Knyphausen (1988), Pautzke (1989).

Projektmanagement-Ansätze

O

19

Eine Überprüfung der Angemessenheit organisatorischer Maßnahmen ist sehr schwer57); eine gewisse Skepsis ist zumindest hinsichtlich der Angemessenheit der Realisierung geboten.

Ein Ansatzpunkt zur Verbesserung ist die Nutzung von Rückkopplungsprozessen. Mit der systemtheoretischen Erforschung von Rückkopplungsprozessen beschäftigte sich seit den 60er Jahren fast eine ganze Forschungsgeneration. Unter dem (programmatischen) Namen Kybernetik wurde ein interdisziplinäres Forschungsziel verfolgt: die Erforschung und Konzeption allgemeingültiger Methoden zur Steuerung komplexer Systeme58). Im Rahmen eines kybernetischen Ansatzes stehen die Konzeption, organisatorische Umsetzung und Nutzung eines Systems verschachtelter Regelkreise im Mittelpunkt des Problemlösungsprozesses. Bei der o.a. Darstellung des institutionellen Projektmanagements (vgl. Abbildung 1-3) handelt es sich um ein kybernetisches Modell. Es verdeutlicht, daß eine umfassende Modellierung organisatorischer Zusammenhänge mittels kybernetischer Regelsysteme nicht durchführbar ist59>. Dennoch verspricht eine Einbeziehung kybernetischer Elemente in systemorientierte Ansätze, z.B. durch die Nutzung von Regelkreisen für den Problemlösungsprozeß, Aussicht auf Erfolg. 1.2.3.4 Systemtechnik Neuere Formen des bereits in den 50er Jahren für die Waffentechnik entwickelten System Engineeringbieten einen solchen Ansatz. Dabei wird davon ausgegangen, daß die Lösung komplexer Probleme nur in einem Wechselspiel von Analyse und Synthese möglich ist61). Die klassischen Produktlebensphasen geben immer noch den groben inhaltlichen Rahmen eines Entwicklungsvorhabens vor, die konkreten Aktivitäten werden aber in einem Problemlösungszyklus geordnet. Abbildung 1-4 verdeutlicht diesen Zusammenhang. Bei den traditionellen systemanalytischen Ansätzen erfolgt die Ergebniskontrolle nach Abschluß einer Aufgabe oder einer Entwicklungsphase; eine aktive Steuerung des Entwicklungsverlaufs, insbesondere die frühzeitige Korrektur von Fehlentwicklungen, ist nicht vorgesehen. Innerhalb des System Engineering gewinnen im Sinne 57) Zur Problematik der Messung der organisatorischen Effizienz vgl. Welge (1987), S. 619 ff. und 652 ff. 58) Die Kybernetik wurde von Wiener begründet; Wiener (1948). 59) Vgl. zur Relevanz kybernetischer Ansätze für die Modellierung des Problemlösungsprozesses Zogg (1974), S. 62 f. 60) Mit System Engineering wird hier insbesondere der an der ETH Zürich entwickelte Ansatz referiert; vgl. Daenzer (1977). Der entsprechende deutsche Begriff Systemtechnik wird in der Projektmanagemen tliteratur, z.B. in Madauss (1990), mit traditionellen systemanalytischen Ansätzen des System Engineering verbunden. 61) Vgl. u.a. zur Untrennbarkeit von Analyse und Synthese und möglichen Iterationen Zogg (1974), S. 103 und 107 ff.

20

Projektmanagement

Problemlösungszyklen

Zielsuche

Lösungssuche

Lebensphasen

Situationsanalyse Zielsetzung Zielsetzung Analyse Bewertung

Auswahl Entscheidung

Abb. 1-4:

Problemlösungszyklen vs. Lebensphasen62)

eines kybernetischen Ansatzes die adäquate Steuerung des Problemlösungsprozesses und damit auch organisatorische Aspekte der Projektabwicklung an Bedeutung. Während die Systemanalyse

von vielen Autoren vornehmlich als Erkenntnisme-

thode angesehen wird, steht beim System Engineering die Organisation der Systemplanung im Vordergrund 63 ). Das System Engineering gilt heute als eine grundlegende

62) Nach Daenzer (1977), S. 49, 3.8. 63) Systemanalyse und System Engineering werden in der Literatur uneinheitlich erklärt, teilweise auch synonym vewendeL Als Systemanalyse wird nicht nur eine spezifische Methodik, sondern der gesamte Entwicklungsprozeß insbesondere bei betrieblichen Informationssystemen aufgefaßt. Ein klassisches Werk zur Systemanalyse trägt den Namen "Systemanalyse - Die Entwicklung von Anwendungssystemen für Datenverarbeitungsanlagen"; Wedekind (1973). Die Systemanalyse wird traditionell als Methode der Erkenntnisgewinnung und nicht der Konstruktion spezifischer Systeme betrachtet, vgl. u.a. Koreiman (1972), S. 15, während beim System Engineering die "Wegleitung zur zweckmäßigen und zielgerichteten Gestaltung komplexer Systeme", vgl. Büschel (1977), S. 4, d.h. die Vorgehensweise im Mittelpunkt des Interesses

Projektmanagement-An Sätze

21

Organisationsmethodik mit weiter Verbreitung in Organisationsplanung64) und Projektmanagement65). Die Qualität der Steuerung ist bei einem kybernetischen Ansatz von der Dimensionierung der "Regelstrecke" abhängig: Ist der Problemlösungszyklus sehr lang, können auch hier Fehlentwicklungen nur sehr spät erkannt und Gegenmaßnahmen ergriffen werden; ist er sehr kurz, steigen Aufwand und Reibungsverluste durch die erforderlichen Kontroll- und Steuerungsaktivitäten. Rückkopplungsprozesse stellen beim System Engineering nicht wie innerhalb der traditionellen linearen Ansätze die ungeplante Ausnahme dar, sondern bilden einen wichtigen Bestandteil des gesamten Entwicklungsprozesses. Trotz dieser Flexibilisierung wird das Lebenszyklusmodell als verrichtungsorientiertes Phasenschema auch innerhalb des System Engineering nicht aufgegeben, sondern vielmehr als Erfahrungsgrundsatzdogmatisiert Mit der Phaseneinteilung soll insbesondere bewirkt werden, daß "das allgemeine Vorgehensmodell vom Grobem zum Detail in überblickbare Teiletappen"67) gegliedert wird. Es wird also - ganz im Sinne eines systemanalytischen Ansatzes - davon ausgegangen, daß für die Systementwicklung eine stufenweise Konkretisierung grundsätzlich möglich und sinnvoll ist. Dies gilt sicherlich für die meisten technischen Systeme und für bestimmte mechanistische, technokratische Organisationsformen - anders ausgedrückt für geschlossene Systeme. Wie Ergebnisse der Systemtheorie zeigen, ist bei einem Übergang von einem geschlossenen zu einem offenen System eine Veränderung der Rationalität erforderlich68). Auch innerhalb der modernen Systemanalyse zeichnet sich ein Übergang von traditonellen, szientistisch-reduktionistischen Ansätzen hin zu verhaltensorientierten, partizipativen Methoden ab69). Die angeführten Probleme bezüglich der Unzulänglichkeit menschlicher Erkenntnisfähigkeit, der instabilen Umgebungsbedingungen oder auch der Angemessenheit können durch die Flexibilisierung des Problemlösungsprozesses gemildert werden.

64) 65)

66) 67) 68) 69)

steht. Für diese Ausführungen soll vereinfachend die unterschiedliche Perspektive bzw. der Ausgangspunkt der beiden Ansätze zugrundegelegt werden, die aus der ursprünglichen, intuitiv nachvollziehbaren Bedeutung der Begriffe folgt. Krüger entwickelt ein Konzept für die Organisationsplanung auf der Basis des System Engineering; vgl. Krüger (1983), S. 18 ff. Die Beziehung von System Engineering und Projektmanagement wird in der Literatur uneinheitlich dargestellt Während Daenzer et al. das Projektmanagement als Teil des System Engineering auffassen, vgl. Daenzer (1977), S. 8 und 121, geht Krüger davon aus, daß es diesem nachgelagert ist; vgl. Krüger (1983), S. 18 f. Rüsberg betrachtet es als einen Teil des Projektmanagements; vgl. Rüsberg (1985), S. 149 ff. Zur Begründung des Lebenszyklusmodells als Erfahrungsgrundsatz des System Engineering vgl. u.a. Halberfellner (1977), S. 39 f. Siehe Halberfellner (1977), S. 40; Original ohne Hervorhebung. Die Notwendigkeit eines Paradigmenwechsels wird von Lubmann (1984), S. 15 ff. erörtert. Einen Überblick über die verschiedenen Entwicklungsströme der traditionellen und modernen Systemanalyse geben Wood-Harper, Fitzgerald (1982).

22

Projektmanagement

Es stellt sich jedoch die im Zusammenhang mit dem Phasentheorem bereits aufgeworfene Frage, ob und warum dies wirklich die beste Vorgehensweise ist. Wie empirische Untersuchungen zeigen70), ist es sicherlich nicht in jedem Fall die "natürliche", d.h. dem menschliche Entscheidungsverhalten entsprechende Art und Weise der Problemlösung. 1.2.4 Verhaltensorientierte Ansätze 1.2.4.1 Hintergrund Die bisherigen Ansätze behandeln technische Aspekte des Projektmanagements; menschliche Faktoren spielen nur eine untergeordnete Rolle. Wie bereits angesprochen, beeinflußt die Motivation der Mitarbeiter maßgeblich deren Produktivität und damit auch die organisatorische Effizienz. Jeder Management-Philosophie liegen deshalb bestimmte Hypothesen über Ursprünge und Möglichkeiten zur Beeinflussung der Motivation zugrunde. 1.2.4.2 Exkurs - Theory X vs. Theory Y Im klassischen Managementansatz wird zur Erklärung der Arbeitsmotivation davon ausgegangen, daß der Mensch versucht, den Arbeitsaufwand zu minimieren. In den Worten von Taylor, dem berühmtesten Vertreter dieser Auffassung: "There is no question that the tendency of the average man (in all walks of life) is toward working at a slow, easy gait, and that it is only after a good deal of thought and observation on his part or as a result of example, or external pressure that he takes a more rapid pace. "71) Der älteste Ansatz zur Verbesserung der Arbeitsmoral ist der autoritäre Führungsstil, die Ausübung von Druck durch Drohung und Bestrafung. Taylor kritisiert diesen Ansatz als kontraproduktiv und stellt dem folgende Ansatzpunkte zur Verbesserung entgegen: O Entwurf optimaler Arbeitspläne für Teilaufgaben mit wissenschaftlichen Mitteln (Beispiele), O Entlohnung abhängig von der Leistung (Bewußtsein) und O Spezialisierung jedes Arbeiters auf Teilaufgaben (Arbeitsteilung). Der letzte Punkt wird durch die Beobachtungen von Taylor getragen, daß die Motivation von Einzelpersonen durch Gruppenarbeit eher negativ beeinflußt wird72). 70) 71) 72)

Empirische Ergebnisse liefern u.a. Hauscbildt, Petersen (1987). Siehe Taylor (1972), S. 30 f.; zuerst 1911 erschienen. Siehe Taylor (1972), S. 31:

Projektmanagement-Ansätze

23

Taylor hält es im Sinne der Arbeitsteilung auch für erforderlich, daß Planung und Kontrolle der Arbeit inhaltlich und personell von der Ausführung getrennt werden. Er schreibt: "It is also clear, that in the most cases one type of man is needed to plan ahead and an entirely different type to execute the work. The man in the planning room, whose speciality under scientific management is planning ahead, invariably finds that the work can be done better and more economically by a subdivision of labour;... Sowohl die planende als auch die ausführende Instanz sind an der Verbesserung des Arbeitsplans interessiert; erstere, weil dadurch die Arbeitsproduktivität gesteigert wird, und letztere, weil dadurch ihr Lohn erhöht wird. Im Idealfall ist also ein streng autoritärer Führungsstil nicht erforderlich. Beide Instanzen sollten nach Taylor daran interessiert sein, zu kooperieren74). Voraussetzung dafür ist jedoch, daß die ausführende Instanz die Autorität der planenden Instanz unbeschränkt akzeptiert und die Kooperation wirklich zu einer langfristig anhaltenden finanziellen Verbesserung der Ausführenden führt; in Anbetracht des ständigen Rationalisierungsdrucks in der industriellen Fertigung eine sehr optimistische Annahme. Als Ursache für die Motivation der Arbeitnehmer setzt Taylor also - und dies gilt für alle klassischen Managementansätze - vornehmlich materielle Interessen voraus. Diese Annahme ist sicherlich für die Zeit, in der Taylor lebte, richtig; die Arbeitsmotivation wurde damals durch existenzielle Bedürfnisse bestimmt. Durch die "postindustrielle Revolution" hat sich diese Voraussetzung (zumindest in den Industriestaaten) grundlegend geändert. Vor dem Hintergrund von Erkenntnissen der Motivationsforschung entwickelte McGregor75) einen alternativen Managementansatz, den er im Gegensatz zum klassischen Ansatz, den er als Theory X bezeichnet, Theory Y nennt. Dabei geht er u.a. davon aus, daß die Motivation abhängig von den Belohnungen ist, die mit der Ausführung einer Aufgabe verbunden sind; als bedeutende Anreize führt er jedoch nicht wie Taylor solche finanzieller Art, sondern Selbstbestätigung und Selbstbestimmungsbedürfnisse an. Dies erklärt auch, warum finanzielle Anreize insbesondere in der industriellen Fertigung nur begrenzte Wirkung zeigen: Die repetitive Ausführung standardisierter Tätigkeiten leistet sicherlich keinen Beitrag zur Selbstbestätigung, und die Trennung der Arbeitsplanung von der -ausführung widerspricht der Selbstbestimmung. Solange die persönlichen Ziele der Mitarbeiter nicht mit den an sie gestellten Anforderungen der Organisation übereinstimmen, entstehen Reibungsverluste, und "The common tendency to 'take it easy' is greatly increased by bringing a number of men together on similar work and at a uniform standard rate of pay by the day. " 73) 74) 75)

Siehe Taylor (1972), S. 38. Siehe Taylor (1972), S. 36. Vgl. im folgenden McGregor (1960), S. 31,47 f., 52,53 und 55.

24

Projektmanagement

die Arbeitsmotivation ist niedrig. Um das Leistungspotential der Organisation voll auszuschöpfen, müssen die persönlichen Ziele und die organisatorischen Anforderungen integriert werden. Dafür ergeben sich grundsätzlich zwei Ansatzpunkte; in der Regel wird eine Kombination aus beiden erforderlich sein: O

Anpassung der persönlichen Ziele der Mitglieder; die Ziele müssen aus der Sicht der Mitglieder die attraktivste Alternative für sie darstellen;

O

Anpassung der organisatorischen Anforderungen an die Ziele der Mitglieder; oft werden die Anforderungen unter falschen bzw. unrealistischen Voraussetzungen gestellt, und es ist eine Veränderung der Anforderungen zum "Wohle" der Gesamtorganisation möglich.

Durch die "Integration der Ziele" im Sinne von McGregor kann sich die Arbeitsmotivation und damit auch die Bereitschaft zur Übernahme von Verantwortung erhöhen. Diese Quelle für Produktivität und Kreativität sollte durch die Organisation genutzt werden. Dies ist durch Schaffung individueller Spielräume und Selbstkontrolle der Beteiligten möglich. Es ist nicht Aufgabe des Managements, detaillierte Arbeitspläne vorzugeben, sondern eine Strategie zu formulieren. Die Ausarbeitung einer spezifischen Taktik erfolgt situativ - mit den Worten von McGregor - "in the light of the circumstances"16\ Ein autoritäres Management kann unter bestimmten Umständen nach wie vor sinnvoll sein. Dies ist z. B. der Fall, wenn keine Integration der Ziele möglich ist oder die Selbstkontrolle keinen Erfolg verspricht, weil ein klar definierter, von allen Seiten akzeptierter Arbeitsplan vorliegt. Sind jedoch hohe persönliche Motivation und Kreativität erwünscht, dann sind anstelle der Autorität andere Formen des "Einflusses" im Sinne eines Management by integration and self-control erforderlich. Einige Ansatzpunkte in diesem Sinne sind u.a. O

Kultivierung eines Arbeitsklimas, das durch gegenseitiges Vertrauen gekennzeichnet ist,

O

ein kooperativer, durch Partizipation gekennzeichneter Führungsstil und

O

Unterstützung von Eigeninitiative und Kreativität.

Die Vorschläge von McGregor wurden in Forschung und Praxis heftig diskutiert. Sie erfordern eine radikale Umstellung gegenüber den autoritären, mechanistischen Ansätzen; erst in neuerer Zeit und in Zusammenhang mit spezifischen Organisationskonzepten konnte eine breitere Akzeptanz in der Managementpraxis erreicht werden77'. Ein gewichtiges Argument gegen diesen Ansatz ist, daß die Integration von Zielen und aktive Partizipation viel Zeit erfordern. McGregor führt aus: 76) 77)

Siehe McGregor (i960), S. 75. Ein Beispiel sind sogenannte Qualitätszirkel. Sie ermöglichen eine Steigerung der Innovationsfahigkeit und der persönlichen Arbeitszufriedenheit; vgl. u.a. Bungard, Schultz-Gambard (1989), S. 381 f.

Projektmanagement-Ansätze

25

"Managers who have undertaken to manage by integration and self-control report that the strategy is time consuming. Roles cannot be clarified, mutual agreement concerning the responsibilities ofa subordinate's job cannot be reached in afew minutes, nor can appropriate targets be established without a good deal of discussion. '78> Zudem konkurrieren die einzelnen Initiatoren um begrenzte Ressourcen. Damit sind eine weitere Konfliktquelle und - im Sinne der Theory Y - ein Anlaß für Verhandlungen gegeben. Das Ergebnis der Konfliktlösung ist dann zwar nicht wie in Theory X ausschließlich von der Rationalität bzw. Machtposition des Autokraten abhängig, jedoch u.a. von dem individuellen Verhandlungsgeschick, und deshalb nicht notwendigerweise zum "Wohle der Organisation". Es muß deshalb ein "neutrales" Konzept für die Koordination der einzelnen Aktivitäten gefunden werden. Ein solches Konzept wurde aus dem Studium japanischer Unternehmen abgeleitet und wurde unter dem Namen Theory Z79) bekannt. Im Mittelpunkt dieses Ansatzes steht die kollektive Entscheidungsfindung auf der Grundlage gemeinsamer Werte. Die Harmonisierung der Werte wird durch eine spezifische Unternehmenskultur-80) erreicht, die allen Beschäftigten eine Identifikation mit der eigenen Tätigkeit als "Teil des Ganzen" ermöglicht. 1.2.4.3 Integrative Ansätze Im Sinne der klassischen Ansätze ist für das Projektmanagement ein technokratischer Führungsstil erforderlich. Die persönliche Führungsqualifikation des Projektleiters zeigt sich in seiner fachlichen Kompetenz und seiner Befähigung, optimale Pläne zu entwerfen und durchzusetzen sowie deren Ausführung zu kontrollieren - ein autoritärer Manager im Sinne von Theory X. In einer regulären Stab-Linien-Organisation ist bei einem autoritären Führungsstil die Arbeitseffektivität begrenzt, weil bei den Mitarbeitern keine ausreichende Motivation geweckt werden kann. Dies gilt nicht unbedingt für Projekt-Organisationen. Innerhalb eines Projekts haben die Mitarbeiter die Möglichkeit der Identifikation mit einer Aufgabe, sie können ein "Wir"-Bewußtsein entwickeln. Bei erfolgreicher Projektdurchführung wird auch das Ansehen der Beteiligten gesteigert, oder es ist sogar eine Beförderung möglich. Dadurch werden zusätzliche Anreize geschaffen und die Motivation erhöht. Daraus kann man folgern, daß ein autoritärer oder technokratischer Führungsstil innerhalb eines Projekts sogar unter solchen Bedingungen vorteilhaft ist, die sonst Kooperation und Partizipation erfordern würden. Voraussetzung dafür ist jedoch, daß sich bei erfolgreicher Projektausführung für alle Beteiligten interessante Karriere78) 79) 80)

Siehe McGregor (1960), S. 76 und später Abs. 4.3.2.4. Zur Begründung der Theory Z vgl. Ouchi (1981). Zum Begriff und der wissenschaftlichen Diskussion der Organisationskultur siehe u.a. Scholz (1989) oder Weber, Mayerhofer (1988).

26

Projeklmanagement

chancen bieten. Die Projekt-Organisation bietet engagierten Mitarbeitern die Möglichkeit zur Profilierung und zum Nachweis ihrer Führungsqualitäten. Die Abgrenzung zu anderen Organisationseinheiten ermöglicht eine Identifikation mit dem Projekterfolg. Durch die zeitliche Befristung von Projekten ergeben sich auch negative Motivationseffekte durch Unsicherheit der Teammitglieder81). Die positiven Motivationseffekte sind also nicht gegeben, sondern es ist eine wichtige Aufgabe des Projektmanagements, sie zu "entwickeln". Ein rein auf institutioneller Autorität basierender Führungsstil führt dabei nicht zum Erfolg, da die Projektleitung in der Regel nur mit begrenzten Kompetenzen ausgestattet ist Wilemon und Baker sprechen in diesem Zusammenhang von einem "authority gap"82>. Die fachliche Autorität des Managements ist eine wichtige Voraussetzung, jedoch nicht hinreichend für ein effektives Projektmanagement83). Neben technischen und logistischen Aspekten umfaßt das Projektmanagement eine weitere Dimension, die u.a. durch folgende Problembereiche charakterisiert werden kann: O

Projekte stehen in Konkurrenz zu anderen Unternehmensbereichen oder Projekten. Zur Durchsetzung von Ansprüchen des Projekts in Hinblick auf den Zugriff auf Ressourcen müssen Konflikte überwunden werden.

O

Für die erfolgreiche Durchführung der Aufgaben wünscht sich das Projektteam eine optimale Ressourcenausstattung. Die Trägerorganisation bzw. der Auftraggeber ist dagegen daran interessiert, die Kosten zu minimieren.

O

Wird das vorgegebene Projektziel von den Betroffenen nicht akzeptiert, sind auch hier Interessenkonflikte zu überwinden. Dies gilt insbesondere für Rationalisierungsmaßnahmen und organisatorische Veränderungen.

O

Projekte stellen eine temporäre Organisationsform dar. Die Zusammenarbeit muß sich erst einspielen, die dabei auftretenden Konflikte müssen gelöst werden.

Für die erfolgreiche Durchführung von Projekten müssen verschiedenartige Konflikte gelöst werden. Als entscheidender Erfolgsfaktor für das Management von Projekten werden deshalb interpersonelle Fähigkeiten angesehen. Empirische Untersuchungen belegen insbesondere die Bedeutung von Überzeugungsfähigkeit und Verhandlungsgeschick84). Man kann diesen Aufgabenkomplex des Projektmanagements auch im Sinne von McGregor als Integration85> bezeichnen.

81)

Zur Motivation der Organisationsmitglieder von Projekten vgl. u.a. Frese in Grochla (1980), Sp. 1971 f., Middleton (1967), S. 78 f. 82) Vgl. Wilemon, Baker (1989), S. 848 f. 83) Vgl. auch Wilemon, Baker (1989), S. 849 f. und Hodgetts (1968). 84) Vgl. u.a. Wilemon, Baker (1988), S. 848 f. 85) Es handelt sich dabei um eine spezifische Begriffsauffassung. Integration wird sonst in der Managementliteratur in der Regel synonym mit Koordination verwandt; vgl. Staehle (1985), S. 432, insbesondere Fußnote 14.

Projektmanagement-Ansätze

27

Sieht man einmal von dem temporären Charakter der Führungsaufgaben ab, könnte man vermuten, daß sich das Projektmanagement bezüglich der grundsätzlichen Natur technischer, administrativer, logistischer, methodischer und analytischer Problemstellungen nicht wesentlich vom Management "an sich" unterscheidet. Berücksichtigt man jedoch die essentielle Bedeutung integrativer Aufgaben auch bei den einfachsten Projekten, erhält das Projektmanagement eine neue Qualität86). Die Bedeutung des integrativen Aspekts des Projektmanagements findet in letzter Zeit insbesondere in der praxisorientierten Projektmanagement-Literatur stärkere Beachtung. Thomsett fordert ein People & Project Management87> im Gegensatz zu der traditionellen Trennung sozialer und psychologischer Aspekte von den Funktionen und Instrumenten des Projektmanagements. Der integrative Aspekt seines Projektmanagement-Ansatzes beschränkt sich auf die projekt-internen Ansatzpunkte, er fordert ganz im Sinne von McGregor gemeinsame Verantwortung, gegenseitigen Respekt und Unterstützung88). Bloch konzentriert sich dagegen mehr auf die externe Integration und prägt dafür den Begriff ProjektpolitikmK Hansel und Lomnitz fordern eine ganzheitliche-situative Projektbetrachtung und messen dabei psycho-sozialen Prozessen im Rahmen der Projektarbeit ebensolche Bedeutung zu wie fachlichen, administrativen und organisatorischen Aspekten90). Für die erfolgreiche Projektarbeit geben sie deshalb u.a. Ratschläge für die partnerschaftliche Gesprächsführung sowie zur Überwindung von Widerständen bei Veränderungen und zur Partizipation91). Randolph und Posner fordern "a merging of technical und people issues"92) und stellen zehn Prinzipien für das erfolgreiche Projektmanagement auf. Die ersten vier Prinzipien zielen auf die Aufstellung eines adäquaten Plans ab und orientieren sich an den tradionellen Projektmanagement-Ansätzen. Die restlichen sechs widmen sie einem Aufgabenbereich, den sie als "manage the plan and the people"93) beschreiben; es handelt sich dabei vornehmlich um Verhaltensempfehlungen bzw. integrative Aufgaben94).

86) 87) 88) 89)

90) 91) 92) 93) 94)

Vgl. Stuckenbruck (1988), S. 57. Siehe Thomsett (1980), S. 1. Vgl. Thomsett (1980), S. 83 ff. Bloch expliziert diesen Begriff folgendermaßen: Project politics are "the actions and interactions between project team members and people outside the team that have impact on the success of the project, its system, the project team, and the project manager"; siehe Bloch (1983), S. 21. Vgl. Hansel, Lomnitz (1987), S. 5 f. Vgl. Hansel, Lomnitz (1987), Kapitel 3,7 und 8. Siehe Randolph, Posner (1989), S. 66. Siehe Randolph, Posner (1989), S. 70. "Build Agreements that vitalize team members" ist ein Beispiel für eine integrative Verhaltensregel im Sinne von McGregor; vgl. Randolph, Posner (1989), S. 71.

28

Projektmanagement

1.2.5 Synopse der Projektmanagement-Ansätze Die vorgestellten Ansätze widersprechen sich nicht grundsätzlich, sondern bauen in gewisser Weise aufeinander auf. Jeder einzelne Ansatz stellt ein bestimmtes Problemfeld des Projektmanagements in den Mittelpunkt. Innerhalb des klassischen logistischen Ansatzes werden eine detaillierte Aufgaben-, Termin- und Ressourcenplanung angestrebt. Das Lebenszyklusmodell zielt auf die Grobplanung der Vorgehensweise ab. Eine Methodik für die systematische Problemlösung wird durch den analytischen Ansatz vorgegeben. Ziel des System Engineering ist insbesondere die Steuerung des Problemlösungsprozesses. Aus der verhaltensorientierten Perspektive werden Möglichkeiten zur positiven Beeinflussung sozialer und psychologischer Faktoren durch integrative Ansätze vorgeschlagen. Alle fünf Problemfelder sind für die erfolgreiche Projektdurchführung wichtig: ®

Da im Rahmen von Projekten schwierige Aufgaben gelöst werden, ist eine effektive Arbeitsorganisation erforderlich. Sie kann vorgegeben oder auch implizit entstanden sein.

®

Durch eine Einigung über die grundsätzliche Verfahrensweise kann die Effektivität der Einzelaktivitäten verbessert werden.

®

Für die Lösung technischer und organisatorischer Anwendungsprobleme sind analytische Instrumente hilfreich.

© Für die Anpassung an Veränderungen ist eine Steuerung des Entwicklungsprozesses erforderlich. ®

Die Motivation der Mitarbeiter sollte gestärkt werden, Konflikte müssen erkannt und bewältigt werden.

Je nach Projektart ändert sich die Bedeutung der jeweiligen Problembereiche für den Erfolg. Bei Projekten im Anlagenbau dominieren Detailprobleme bezüglich der Terminabstimmung, bei der Konstruktion neuer Produkte Fragestellungen der Aufgabenaufteilung und der Verfahrensweise und bei reinen Organisationsprojekten die Bewältigung von Konflikten, z.B. durch Widerstände gegen Veränderungen. Aus der Dominanz eines Bereichs kann man natürlich nicht schließen, daß die anderen vernachlässigt werden können. So können Projekte im Anlagenbau bei unzureichender Steuerung und eine Produktentwicklung wegen Abstimmungsproblemen scheitern. Die verschiedenen Ansätze sollten also situativ für das Projektmanagement genutzt werden. Eine Management-Lehre, die einen solchen Methodenpluralismus zugrunde legt, bezeichnet man auch als ganzheitliches oder situatives Management. Dabei wird nicht davon ausgegangen, daß es nur eine gültige, sondern mehrere,

Projektmanagement-Ansätze

29

situationsbezogene Handlungsalternativen gibt95). Die Vorteilhaftigkeit bestimmter Maßnahmen hängt von bestimmten situativen Einflußgrößen ab. 1.2.6 Voraussetzungen für ein problemangepaßtes

Projektmanagement

Voraussetzung für ein problemangepaßtes Projektmanagement96> ist, daß ein ausreichendes Reservoir an Handlungsalternativen verfügbar ist. Untersucht man die fünf verschiedenen Ansätze hinsichtlich der Prämissen, stößt man auf zwei Prinzipien, die - etwas überspitzt - folgendermaßen beschrieben werden können: O

Primat der Planung: Es wird davon ausgegangen, daß eine umfassende Planung die wichtigste Voraussetzung für eine erfolgreiche Projektdurchführung darstellt.

O Mechanistisches Organisationsverständnis97>: Die einzelnen Teilaufgaben innerhalb des Entwicklungsverlaufs sollten möglichst unabhängig voneinander betrachtet werden können und schrittweise abgearbeitet werden; die formale Organisationsstruktur steht im Vordergrund. Der traditionelle logistische Ansatz geht von der Existenz bzw. der Notwendigkeit der Erstellung detaillierter Konstruktionsp/öwe aus. Der Konstruktionsprozeß wird als eine sequentielle, also streng lineare, mechanistische Abfolge von Aktivitäten ausgelegt (Problembereich ®). Lebenszyklusmodelle werden vorwiegend als allgemein bindende (mechanistische) Handlungspläne konzipiert; die Ausführung aller Aktivitäten wird danach ausgerichtet Jede Einzelphase kann dabei als eine Planungsphase der nachfolgenden Phase aufgefaßt werden (Problembereich

operational specifications » coding specifications » coding parameter testing assembly testing t

shakedown I system evaluation Abb. 2-1:

1) 2) 3)

Das Stufenmodell

Zum Begriff des Projektmodells siehe Hesse (1980), S. 108 f. oder Denert, Hesse (1980), S. 224 f. Vgl. Abs. 1.2.2. Siehe dazu Bennington (1956).

Lineare Phasenmodelle

51

Analog zum Projekt-Lebenszyklus handelt es um ein normatives Verfahrensmodell. Die einzelnen Stadien werden als Entwicklungsphasen mit klar abgrenzbaren Aufgaben und Ergebnissen aufgefaßt. Die Ergebnisse jeder Phase gehen direkt in die nachfolgende Phase ein. Zuerst werden Anforderungen an das System ermittelt und festgeschrieben; erst relativ spät im Entwicklungsverlauf erfolgt die konkrete Programmierung. Rücksprünge in vorherige Phasen sind nicht vorgesehen. Diese streng sequentielle Vorgehensweise bestimmt die ersten Lebenszyklusmodelle; derartige Projektmodelle werden deshalb im folgenden als klassisch bezeichnet. Während das Stufenmodell als Konstruktionsprozeß (im Sinne eines logistischen Ansatzes) interpretiert werden kann, entwickelt Royce ein Lebenszyklusmodell im Sinne eines systemanalytischen Ansatzes4): Kennzeichnend für die Einteilung des Entwicklungsverlaufs und die nachfolgenden Lebenszyklusmodelle ist die Trennung von Analyse und Realisierung. Der Konkretisierungsgrad nimmt im Entwicklungsverlauf zu; von einer abstrakten Problemdefinition bis zum konkreten Einsatz werden mehrere Entwicklungsstadien durchlaufen. Der Vorteil dieser klassischen Ansätze besteht in der klaren konzeptionellen Trennung zwischen Analyse und Lösung des Anwendungsproblems einerseits und Methoden bzw. Werkzeugen zur konkreten Realisierung andererseits. Der Entwickler wird gezwungen, sich Gedanken über das Problem "an sich" zu machen. Das Anwendungsproblem wird damit grundsätzlich unabhängig von besonderen Möglichkeiten spezieller Werkzeuge oder anderen Restriktionen bei der Programmierung betrachtet. Die Ergebnisse der ersten Phasen haben einen höheren Grad an Allgemeinheit und können grundsätzlich später auf verschiedene Art und Weise und mit verschiedenen Werkzeugen implementiert werden. 2.1.2 Das Wasserfall-Modell Eine von Boehm vorgestellte Weiterentwicklung des Modells von Royce, das sogenannte Wasserfall-Modell5), fand besondere Beachtung. Im Laufe der Zeit wurden viele Projektmodelle vorgeschlagen, die auf diesem Modell basieren oder damit vergleichbar sind6). Eine schematische Darstellung des Enwicklungsablaufs nach dem Wasserfall-Modell gibt Abbildung 2-2. Es wird ein achtstufiger Phasenzyklus für den Entwicklungsprozeß vorgegeben. Jede Phase umfaßt eine spezifische Aufgabe im Lebenszyklus eines Softwaresystems (oberer Teil jedes Kästchens). Am Ende jeder Phase wird der Übergang von einer Phase zur nächsten durch eine spezielle Aktivität (unterer Teil jedes Kästchens) vorbereitet. Nach deren Abschluß fließt das Ergebnis einer Phase in die nächste Phase ein. 4) 5) 6)

Das Modell wird in Royce (1970) beschrieben. Zum Wasserfall-Modell vgl. u.a. Boehm (1981), S. 35 ff. In Seibt (1987) werden verschiedene Modelle gegenübergestellt

52

Projektmodelle für die Softwareentwicklung

Abb. 2-2:

Das Wasserfall-Modell von Boehm7)

Abbildung 2-3 stellt Ziel, Ergebnis und Art der Ergebnisüberprüfung der einzelnen Phasen gegenüber. Wie bei den klassischen Modellen sinkt der Abstraktionsgrad mit jeder Phase im Entwicklungsverlauf. Man kann sich bildlich vorstellen, daß der Entwicklungsfortschritt wie ein Wasserfall über die verschiedenen Phasen von einer abstrakten Definition bis hin in die konkrete Realisierung "fließt". Kann eine Phase nicht erfolgreich abgeschlossen werden, ist ein Rücksprung in die vorhergehende Phase notwendig. Iterationen vorheriger Phasen sollten nach Boehm jedoch - soweit möglich - in der nachfolgenden Phase erledigt werden. Der Entwicklungsablauf wird grundsätzlich als eine lineare Folge von Entwicklungsabschnitten betrachtet. Rücksprünge und Iterationen sind also grundsätzlich möglich, stellen jedoch die Ausnahme dar (ein Wasserfall fließt nicht zurück). Solche Projektmodelle werden auch als linear bezeichnet8). Die aufgabenorientierte Unterteilung des Entwicklungverlaufs wird mit der Heterogenität der Ziele begründet9): Es wird davon ausgegangen, daß ein fester Satz von Zielen bei der Softwareentwicklung zu berücksichtigen ist. Durch Unterteilung des Entwicklungsverlauf in unterschiedliche Teilaufgaben, die jeweils genau eines dieser Ziele umfassen, soll sichergestellt werden, daß jedes der einzelnen Ziele bearbeitet wird10). Als kritisch wird dabei nicht so sehr die konkrete Implementierung,

7) 8) 9) 10)

Nach Boehm (1982), S. 27. Vgl. auch Bally et al. (1977), S. 22. Vgl. auch Abs. 1.4.1. Siehe dazu Boehm (1981), S. 39.

Lineare Phasenmodelle

53

Phase

Ziel

Ergebnis

Überprüfung

Anforderungen an das System

Konzept

Definition der wichtigsten Ziele

Validierung

Anforderungen an die Software

allgemeine ProgrammSpezifikation

Funktionen; Schnittstellen; Performance

Validierung

GrobEntwurf

ProduktEntwurf

globale Hard- und Software-Architektur; Datenstrukturen; Dokumentationen etc.

Validierung

DetailEntwurf

SoftwareSpezifikation

spezifische Kontrollund Datenstrukturen; Algorithmen; Schnittstellen etc.

Validierung

Codierung und Debugging

ModulImplementierung

ProgrammKomponenten; Modul test

Modultest

Integration

ProgrammImplementierung

funktionsfähiges Programm

ProduktVerifikation

Implementierung

SystemImplementierung

betriebsfähiges System und Training

Validierung Test

Betrieb Wartung

Produktion Anpassung

System Update

Revalidierung

Außerdienststellung

Ersetzung

Transition von Funktionen, Daten etc.

Abb. 2-3:

Ziel, Ergebnis und Art der Ergebnisüberprüfung für die einzelnen Phasen eines Lebenszyklusmodells

sondern die Umsetzung der analyseorientierten Ziele angesehen. B o e h m unterstützt diese A u s s a g e mit empirischen Befunden. Als Grund für die sequentielle bzw. lineare Abarbeitung der einzelnen Phasen wird eine empirische Untersuchung angeführt, deren Ergebnisse Abbildung 2 - 4 zusammenfaßt. Die relativen Kosten zur Behebung von Fehlern sind in den frühen analyseorientierten Phasen wie der Anforderungsdefinition ("Requirements") niedrig und und steigen im Verlauf des Software-Lebenszyklus bis hin zum Betrieb ("Operation") kontinuierlich. W i r d in einer Spezifikation ein Mangel gefunden, kann dieser in der R e g e l einfacher behoben werden als ein Fehler im betriebsfertigen System. Änderun-

54

Projektmodelle für die Softwareentwicklung

t«t

Abb. 2-4:

test

Relative Fehlerbehebungskosten im Software-Lebenszyklus11)

gen des Programmcodes sind besonders schwierig und damit arbeits-, d.h. kostenintensiv, da das Mengengerüst bei der Realisierung erheblich umfangreicher ist als im Rahmen von Definition und Spezifikation. Boehm schließt daraus, daß eine sequentielle Abarbeitung des Software-Lebenszyklus vorteilhaft ist. Die Phasen mit den niedrigeren Kosten zur Behebung von Fehlern sollten - soweit möglich - vor denen mit höheren Behebungskosten ausgeführt werden; zuerst sollten die Anforderungen definiert, dann eine Spezifikation erstellt und erst anschließend mit der konkreten Realisierung begonnen werden. Voraussetzung für die Stichhaltigkeit dieser Argumentation ist, daß die Ergebnisse einer Phase keine Fehler enthalten und korrekt übergeben werden, weil diese dann in die nächste und von dort aus evtl. wiederum in eine weitere Phase "verschleppt" würden. Die Effizienz linearer Projektmodelle hängt damit wesentlich von der Qualität der Überprüfung der Ergebnisse am Ende jeder Phase ab. Wie oben erläutert, stellt die Ergebnisüberprüfung bei Boehm einen wichtigen Bestandteil des Ablaufmodells dar. Er unterscheidet zwei Arten12': O

Verifikation: Überprüfung der Korrektheit des Softwareprodukts hinsichtlich der Spezifikation ("Are we building the product right?");

11) Aus Boehm (1981), S. 40. 12) Siehe Boehm (1981), S. 37

Lineare Phasenmodelle

O

55

Validierung: Überprüfung des Werts des Softwareprodukts hinsichtlich des Einsatzziels ("Are we building the right product?").

Während in den frühen Phasen des Lebenszyklus die Validierung im Mittelpunkt steht, besteht die Ergebnisüberprüfung in den späteren Phasen hauptsächlich aus Verifikation. 2.1.3 Nachteile linearer Modelle 2.1.3.1 Validierung Die Ergebnisse früher Projektphasen innerhalb der linearen Entwicklungsmethodik bestehen aus Beschreibungen mit hohem Abstraktionsgrad. Beispiele sind Problemanalysen, Pflichtenhefte oder nicht-ausführbare Systemspezifikationen. Da sich diese abstrakten Modelle nicht am realen Anwendungspro-blem messen lassen, können die Ergebnisse nur bedingt validiert werden. Oft ist eine verläßliche Validierung erst dann möglich, wenn ein konkretes System vorliegt, im Rahmen der linearen Methodik also erst in einer der späteren Phasen. Validitätsmängel, die erst zu diesem Zeitpunkt festgestellt werden, können nur mit sehr hohem Aufwand nachgebessert werden. Es existieren empirische Befunde darüber, daß der größte Teil der Kosten zur Prozent Legende: Y777A

Test, Wartung etc. Codierung

ES3 Entwurf

Definition

Gesamtaufwand Abb. 2-5:

Fehlerquellen

Kosten für die Fehlerbehebung

Zusammenhang zwischen Fehler- und Kostenverursachung im Software-Lebenszyklus13'

13) Daten aus Tavola, Vincema (1984), S. 435 f.

56

Projektmodelle für die Softwareentwicklung

Fehlerbehebung in den späten Phasen auf Mängel in den frühen Phasen zurückzuführen ist14). Abbildung 2-5 veranschaulicht diesen Zusammenhang. Auf der Basis dieser Ergebnisse ist eine Differenzierung der o.a. Argumentation von Boehm möglich. Zwar wird für Anforderungsdefinition und Entwurf nur ein geringer Anteil der Gesamtkosten benötigt, jedoch durch sie ein großer Teil der Fehlerbehebungskosten verursacht. Wie man durch Vergleich des Anteils an der Gesamt-Fehleranzahl und der Gesamtkosten zur Fehlerbehebung sieht, sind die Kosten zur Behebung von Fehlern in der Anforderungsdefinition überdurchschnittlich hoch. Dies zeigt, wie wichtig Korrektheit und Validität der Ergebnisse für die Vorteilhaftigkeit der linearen Vorgehensweise sind. Selbst bei valider und korrekter Anforderungsdefinition können sich bei linearen Modellen Probleme bei Veränderungen der Benutzeranforderungen im Zeitablauf ergeben ("Moving target"). Erst bei der Inbetriebnahme kann der Benutzer Erfahrungen mit dem konkreten System sammeln. Erfahrungen mit dem konkreten Softwareprodukt beeinflussen jedoch die Einstellung der Anwender in Hinblick auf die Art und Weise der Unterstützung bei der Problemlösung15). Diese Rückwirkungen können in linearen Modellen nicht berücksichtigt werden. Oft sind Anwender nicht in der Lage, das Ausgangsproblem und ihre konkreten Anforderungen an eine Problemlösung zu artikulieren. Werden jedoch wichtige Randbedingungen bei der Definition nicht berücksichtigt, pflanzen sich diese Fehler im Wasserfall-Modell in nachfolgenden Phasen fort und verursachen durch die Bindung von Ressourcen zur Fehlerbehebung oder auch - im schlimmsten Fall - durch inadäquate Lösungen hohe Kosten. Verfügt das Entwicklungsteam über Erfahrungen bei der Lösung ähnlicher Probleme, können diese evtl. übertragen und mangelnde Erfahrungen kompensiert werden. Wird jedoch ein Softwaresystem für einen Anwendungsbereich entwickelt, in dem weder die Entwickler noch die Benutzer über Erfahrungen verfügen, ist nur eine begrenzte Validierung abstrakter Problemdefinitionen und Lösungsspezifikationen möglich. 2.1.3.2 Problemkomplexität Existiert für das zu lösende Problem bereits ein bewährter Algorithmus, oder eignet es sich für die Modellierung mit formalen Methoden, sind die Voraussetzungen für eine verläßliche Verifikation und Validierung gut. Bei einer relativ simplen oder gut verstandenen Problemstruktur können Unvollständigkeiten in der Problemdefinition durch eingehende Analyse begrenzt werden. Bei sehr komplexen Anwendungsgebieten oder diffuser Problemstruktur stößt man auch bei eingehender Problemanalyse oft an Grenzen:

14) 15)

Vgl. u.a. Tavolato, Vincema (1984), S. 435. Vgl. u.a. Nissen (1982).

Lineare Phasenmodelle

57

O

Es existiert ein Algorithmus, der eine optimale Lösung garantiert, jedoch ist die Berechnung sehr aufwendig. Zur Begrenzung des Lösungsraums können Regeln oder Heuristiken eingesetzt werden.

O

Es ist kein Algorithmus bekannt oder denkbar, der eine optimale Lösung garantiert. Es gibt jedoch Kriterien für die Qualität einer Lösung und es sind heuristische Verfahren bekannt, bzw. es können Verfahren entwickelt werden, die eine gute, jedoch nicht unbedingt die optimale Lösung liefern.

O

Es sind zwar Algorithmen bzw. heuristische Verfahren verfügbar oder denkbar, jedoch existieren keine verläßlichen Kriterien zur Beurteilung der Güte einer Lösung.

In allen drei Fällen ist für den Problemlösungsprozeß eine wechselseitige Rückkopplung zwischen Analyse und Realisierung erforderlich. Heuristiken bauen auf Erfahrungswerten auf und werden durch Anwendung auf konkrete Beispiele überprüft und verfeinert. Bei streng linearer Vorgehensweise ist dies nicht vorgesehen. Dieses Problem tritt insbesondere dann auf, wenn die Lösung und damit auch die Qualität der Heuristiken wie z.B. im dritten Fall nur durch einen Fachmann beurteilt werden kann, oder Heuristiken aus dem Erfahrungsschatz eines solchen Fach-Experten abgeleitet werden sollen. In all den Fällen, in denen das für die Problemlösung erforderliche Wissen nicht analytisch erfaßt werden kann, stoßen lineare Vorgehensweisen an Grenzen. 2.1.3.3 Phasenübergänge Ein weiteres Problem der linearen Phasenmodelle stellen Informationsverluste bei den Phasenübergängen dar. Bei der Durchführung der Aufgaben innerhalb jeder Phase wird auf den Ergebnissen der vorherigen Phase aufgebaut. Wie aus Abbildung 2-3 ersichtlich ist, unterscheiden sich die Ergebnisse der einzelnen Phasen bezüglich der Darstellungsform. Innerhalb der einzelnen Phasen wird das Ergebnis der vorherigen Phase konkretisiert, d.h., eine abstrakte Problemdarstellung wird in eine weniger abstrakte überführt. Diese Transformation zwischen verschiedenen Darstellungsformen ist nicht unproblematisch. Bei der Implementierung kann z.B. die Spezifikation falsch übertragen oder inadäquat interpretiert werden. Es treten Fehler oder Informationsverluste auf; Validität und Korrektheit des Ergebnisse sind gefährdet. Derartige Mängel werden dann erst in einer späteren Entwicklungsphase entdeckt und können nur mit hohem Aufwand beseitigt werden (s.o.).

58

2.1.4

Projektmodelle für die Softwareentwicklung

Modifikationen des klassischen Modells

2.1.4.1 Schleifenbildung Aufgrand der dargelegten Schwierigkeiten kann bei linearer Vorgehensweise der sequentielle Ablauf nicht immer eingehalten werden. Bei nicht zufriedenstellendem Ergebnis der Implementierung können ein neuer Systementwurf und eine anschließende Modifikation der Implementation oder sogar eine Neuentwicklung erforderlich sein. Wird im Rahmen des Detailentwurfs festgestellt, daß die Anforderungen an das System nicht oder nur mit nicht vertretbar hohem Aufwand umgesetzt werden können, kann auch hier in die entsprechende Phase verzweigt und der Lebenszyklus erneut, sozusagen in einer Schleife innerhalb des Projektmodells, durchlaufen werden. Es sind noch andere Schleifen innerhalb des Phasenmodells denkbar. In allen Fällen wird ein Teil des linearen Zyklus - ungewollt und ausnahmsweise - erneut durchlaufen. Bally et. al. bezeichnen diese entfremdete Form des linearen Modells deshalb auch als "loopy linear"16*. Die Nachteile einer derartigen Vorgehensweise liegen auf der Hand. Der Aufwand für den erneuten Durchlauf zur Beseitigung von Mängeln kann stark variieren, minimale Änderungen der Spezifikation können sich gravierend auf die Implementierung auswirken. Normalerweise sind nur solche Änderungen wirtschaftlich vertretbar, die mit einem angemessenen Aufwand durchgeführt werden können. Das Ergebnis der Softwareentwicklung kann in einem solchen Fall durch die Art und Weise der "ersten" Erfassung und Umsetzung der Anforderungen bestimmt werden - damit wird jedoch einer der wichtigsten Vorteile der linearen, systemanalytischen Vorgehensweise in Frage gestellt. Kann bei Entwicklungsbeginn z.B. davon ausgegangen werden, daß die Benutzeranforderungen nicht stabil sind, ist das Durchlaufen von Schleifen innerhalb des linearen Modells unerläßlich. Das mehrfache Durchlaufen des Entwicklungszyklus ist überaus ineffektiv und nur in Notfällen anzuwenden. Zumindest in seiner ursprünglichen Form versagt in diesem Fall das lineare Modell. 2.1.4.2 Inkrementelle Entwicklung Die zweite Modifikation des linearen Modells zielt auf die Reduktion der Komplexität der Implementierung ab. Das Gesamtsystem wird in einzelne Komponenten aufgegliedert, die dann sukzessive implementiert werden. Der Softwareentwicklungszyklus wird für jede Einzelkomponente einmal durchlaufen. Jedes der Teilsysteme ist voll betriebsfähig und wird nach Fertigstellung in das Gesamtsystem integriert. Bally et. al. beschreiben diese Vorgehensweise deshalb auch als "plug in", Boehm spricht von inkrementeller Entwicklung17).

16) Vgl. Bally et al. (1977), S. 27. 17) Vgl. Bally et al. (1977), S. 23, Boehm (1981), S. 41.

Lineare Phasenmodelle

59

Durch eine inkrementelle Vorgehensweise kann der Aufwand für die Erstimplementation und damit auch das Fehlschlagrisiko gering gehalten werden. Meistens ist es jedoch schwierig, oft sogar unmöglich, ein Gesamtsystem in Einzelteile aufzuspalten, die unabhängig voneinander entwickelt werden können. Wichtige Interdependenzen zwischen den einzelnen Teilsystemen werden oft erst bei der Integration aller Einzelteile in ein Gesamtsystem deutlich. Bei getrennter Entwicklung der Teilsysteme besteht die Gefahr, daß eine uneinheitliche Systemstruktur entsteht. Durch einen Grobentwurf für alle Teilsysteme kann die Konsistenz der Systemstruktur verbessert werden. Entwurfsentscheidungen, die sich auf alle Einzelkomponenten auswirken, werden innerhalb des Grobentwurfs frühzeitig und bindend für alle Entwicklungsschritte festgelegt Nachträgliche Modifikationen der Anforderungsdefinitionen oder Systemspezifikationen sind bei dieser Form der inkrementellen Entwicklung innerhalb des linearen Modells nicht vorgesehen. 2.1.4.3 Gleitendes Phasenmodell Die Entwicklung der einzelnen Teilsysteme bei inkrementeller Entwicklung kann sowohl sukzessiv als auch gleitend erfolgen. Während bei sukzessiver Vorgehensweise ein "Inkrement" nach dem anderen entwickelt und in ein Gesamtsystem integriert wird, kann der Lebenszyklus der einzelnen "Inkremente" auch phasenverschoben und teilweise parallel - also gleitend - durchlaufen werden18'. Produktversion 0 (interner Entw.schritt)

Abb. 2-6:

Produktversion 1

Ablaufschema für die gleitende Softwareentwicklung 19>

18) Zur gleitenden Entwicklungsmethodik vgl. Möller (1983), S. 288 f. 19) Darstellung angelehnt an Möller (1983), S. 288.

Produktversion 2

60

Projektmodelle für die Softwareentwicklung

Im Gegensatz zu den einfachen linearen Projektmodellen ergibt sich bei gleitender Softwareentwicklung eine relativ komplizierte Ablaufstruktur. Sowohl an die Dokumenten- und die Versionsverwaltung als auch an die Einsatzplanung werden besondere Anforderungen gestellt; dabei sind insbesondere "logistische" Aufgabenstellungen zu lösen. Abbildung 2-6 soll dies veranschaulichen. Wie bei der inkrementellen Entwicklung wird das Gesamtsystem in einzelne Funktionsunterbereiche gegliedert. Für jedes Teilsystem wird ein bestimmtes Phasenmodell bzw. ein Teil davon linear durchlaufen. Anders als bei der inkrementellen Entwicklung sind die Entwicklungszyklen für die einzelnen Bereiche jedoch nicht sequentiell aneinandergereiht, sondern durch unterschiedliche Informations- und Ergebnisflüsse miteinander gekoppelt. Die gleitende Entwicklung stellt das flexibelste Projektmodell in der Tradition des Wasserfall-Modells dar. Wegen der ausgeprägten Parallelitäten im Entwicklungsverlauf kann man es jedoch nur bedingt zu den linearen Modellen rechnen. Betrachtet man die einzelnen Funktionsbereiche als Systemversionen, so kann die gleitende Entwicklung auch als ein evolutionärer Ansatz angesehen werden20). Dabei wird jedoch eine sehr eingeschränkte, streng monoton verlaufende "Evolution" im Sinne des klassischen Software-Lebenszyklus unterstellt21). Innerhalb des Projektmodells sind ursprünglich nur Erweiterungen des Leistungsumfangs, jedoch keine Modifikationen bereits bestehender Spezifikationen und Funktionen vorgesehen.

2.2 Prototyping Die vorgestellten Erweiterungen des linearen Modells ermöglichen zwar eine gewisse Flexibilisierung des statischen Entwicklungsverlaufs linearer Modelle; sie können jedoch nicht deren Unzulänglichkeiten u.a. bei unklaren Anforderungen, diffuser Problemstruktur, veränderlichen Ausgangsbedingungen beseitigen. 2.2.1

Begriff

Zur Bewältigung derartiger "widriger" Umstände wurde das Prototyping entwickelt. Die zugrunde liegende Idee stammt aus den Ingenieurwissenschaften. Bei der Entwicklung eines Produkts werden dort zunächst Versuchsmodelle erstellt, mit deren Hilfe Erfahrungen in bezug auf Entwurf, Konstruktion oder Benutzerakzeptanz gesammelt werden sollen. Analog ist es Ziel des Prototypings, möglichst früh im Entwicklungsverlauf ein vorläufiges, aber dennoch betriebsfähiges System zu entwikkeln. Es wurden viele unterschiedliche Ansätze unter dem Namen Prototyping disku-

20)

Vgl. u.a. Möller (1983), S. 288. Zu den Eigenschaften entsprechender evolutionärer Ansätze vgl. auch später Abs. 2.3. 21) Zur Diskussion der Evolution bei der Softwareentwicklung vgl. später Abs. 4.2.

Prototyping

61

tiert22) - von erweiterten Lebenszyklusmodellen23) über zyklische Phasenkonzepte24) bis hin zu unsystematischem "Quick & Dirty" (Q&D) bzw. "Trial and Error"25). Es ist nicht einfach, das Prototyping von anderen Entwicklungsmethodiken abzugrenzen. Eine "schwache" Definition des Prototyping, die alle möglichen Ansätze umfaßt, könnte etwa lauten: Prototyping im weitesten Sinn ist gleichbedeutend mit "nicht-linearer" Entwicklungsmethodik. Diese Definition ist sicherlich wenig hilfreich. Sie beinhaltet auch ungezielte und unstrukturierte Vorgehensweisen und erklärt nicht die ursprüngliche, aus den Ingenieurwissenschaften stammende Bedeutung des Begriffs. Floyd beobachtet, daß bei der Diskussion des Software-Prototyping nicht der Prototyp selber, sondern der Prozeß der Entwicklung von Software im Mittelpunkt des Interesses steht. Sie fordert weiter, daß der Begriff Prototyp für die Softwareentwicklung im Sinne eines "learning vehicle", also eines Lernobjekts zu verwenden ist26). Von mehreren Autoren wird eine Abgrenzung des Prototyps vom Modell gefordert27). Ein industrieller Prototyp ist ein betriebsfähiges System und enthält deshalb alle erforderlichen Funktionen. In einem Modell werden nur die für einen bestimmten Untersuchungszweck relevanten bzw. als relevant angesehenen Eigenschaften eines Gegenstands erfaßt. Es muß nicht betriebsfertig sein. Entsprechend könnte eine "starke" Definition des Prototypings folgendermaßen lauten: Prototyping im engeren Sinn: Entwicklung einer ersten betriebsfähigen Ausführung eines Softwaresystems. Ziel der Entwicklung ist nicht der konkrete Einsatz, sondern das Sammeln von Erfahrungen in Hinblick auf die Umsetzung und die Evaluierung der Entwicklungsergebnisse. Industrielle Prototypen dienen als Produkt-Vorläufer für die Massenfertigung. Ein Prototyp ist die erste betriebsfertige Version oder auch die "Nullserie". Der mit der Massenfertigung vergleichbare Bereich der Softwareentwicklung, die Erstellung von Standardsoftwarepaketen, spielt in der wissenschaftlichen Diskussion des SoftwarePrototyping keine besondere Rolle. Der überwiegende Teil der Literatur beschäftigt sich mit der Entwicklung von Individualsoftware. Der Prototyp hat hier also eine andere Bedeutung. Auch die Entwicklung in mehreren Folge-Versionen wird als Prototyping bezeichnet. Dieses sogenannte "Versioning" oder auch evolutionäre Prototyping stimmt

22) 23) 24) 25) 26) 27)

Überblicke über verschiedene Ansätze geben u.a. Hallmann (1985), Kreplin (1985), und Floyd (1984). Vgl. Pomberger, Remmele (1987). Vgl. u.a. Podolsky (1977), Nauman, Jenkins (1982). Siehe Frank (1979). Vgl. Floyd (1984), S. 2 f. Vgl. u.a. Tavolato, Vincema (1984), S. 438, Foidl et. al. (1986), S. 96.

62

Projektmodelle für die Softwareentwicklung

jedoch mit der ursprünglichen Bedeutung des Begriffs Prototyping nicht mehr überein28). In der Literatur wird deshalb mehrfach betont, daß eine strikte Anlehnung des Software-Prototyping an die ingenieurwissenschaftliche Nomenklatur problematisch ist29). Hallmann hält es sogar für notwendig, "daß die Begriffe Modell und Prototyp in der Softwareerstellung ganz neu definiert werden müssen"30). Es ist allerdings fraglich, ob eine solche abweichende Definition die Begriffsverwirrung nicht noch vergrößert. Die Diskussion des Prototypings begann Mitte der 70er Jahre3». Die Begriffe Software-Prototyp und Prototyping werden sowohl in der Forschung als auch in der Praxis je nach Anschauung und Anwendung unterschiedlich verwendet32). Es ist jedoch davon auszugehen, daß sie - wenn auch meist nur intuitiv begründet und nur selten definitorisch abgesichert - inzwischen allgemein belegt sind. Eine Definition der Begriffe sollte deshalb derem intuitiven Gehalt nicht widersprechen. Das Prototyping im engeren Sinn wird deshalb als das "eigentliche" Prototying angesehen. Da das evolutionäre Prototyping sich am weitesten von der ursprünglichen Bedeutung der Prototypen-Entwicklung als "erste betriebsfertige Version" entfernt33), wird es als eine "uneigentliche" Prototyping-Art betrachtet und im weiteren, soweit möglich, vom Prototyping (im engeren Sinn) getrennt34). 2.2.2

Prototyping-Arten

Die wohl bekannteste Charakterisierung der Prototyping-Arten geht auf Floyd35) zurück. Dabei werden folgende vier Prototyping-Sc/iriife identifiziert: ®

Funktionsauswahl

i Präs.ntatic rI I

I'/////////, i

V777777777, I

iX\\\\\\\\\\\\\\\\\VOO

IxWWWWWW 'w////. Codicru. / / / / / / z y / / / / / / / / / / / . w / / / / / / / / , Codierung Grafiknodu! ' / / / / / / / / / / / / / / / / / / / / z

Abb. 7-8:

VT-

H

Bildscbirmmaske des Task-Managers

Die Darstellung entspricht dem oberen Kasten in Abbildung 6-9. In Bezug auf eine Aufgabe werden für die betroffenen Teammitglieder die einzelnen Aktivitäten für einen bestimmten Zeitraum (im Beispiel eine Woche) im Überblick dargestellt. Die Schraffur gibt an, um welche Aktivitätenart es sich handelt und inwiefern die Termine bereits mit den anderen betroffenen Teammitgliedern abgestimmt wurden. Es wird einerseits zwischen Gruppen- und Einzelaktivitäten und andererseits zwischen abgestimmten (koordinierten) und unabgestimmten Aktivitäten unterschieden Ulli

1 Hilfe 1 System jjailbox Abi auf-Manager Kalender 'Samstag il 1 Montag 'Dienstag ¡Mittwooh ¡Donnerstag 'Freitag I n • Change control board Change control board (CCB): 130 f., 151 Chief-Programmer-Team: 45,227 COCPIT (Communication Oriented Control of Projects and Integrated Task Management) 254 ff. Competence elements (Comps): 146, 154 ff. Compool: 146,155 Comps ->• Competence elements Computer Aided Software Engineering (CASE): 138,153,251 Computer Aided Team (CAT): 243 CPM -> Critical Path Method Crash schedules: 48 Critical Path Method (CPM): 9, 110 ff., 117,20 I f . Darwin: 140 ff. Demonstrationsprototyp: 6 6 , 7 7 , 9 9 Dennis: 92 Department of Defense (DoD; Verteididungsministerium der USA): 9, 127,132 Design to cost: 135

Stichwortverzeichnis

Deutsche Forschungsgemeinschaft (DFG): 2 5 7

Deutsche Gesellschaft für Operations Research (DGOR): 4 Deutsches Institut für Normung (DIN): 4 f., 122

DFG Deutsche Forschungsgemeinschaft) DGOR ->• D e u t s c h e Gesellschaft f ü r

Operations Research Dialog-Manager: 255 Diffusionsprozesse: 156,159,162, 250 DIN -> Deutsches Institut für Normung Diskurs: 31 ff., 36 f. Dissipative Strukturen: 143 DoD - • Department of Defense Durchführungssystem: 167 f., 171 E-Program Embedded-Program ECP (Engineering change proposal) 153 Einsatzplanung: 60,107 ff., 138, 173,215, 220 Einzelaktivität: 28,105,110,120 f., 175,230 ff., 260 Eitzer: 1,2 Embedded-Program (E-Program): 41,48 End-user drift: 75,199 Endbenutzerwerkzeuge: 67 Engineering change proposal (ECP): 130 Entscheidungsnetzpläne: 115 f., 201 f. Entwicklungsabschnitt: 52,175,201 ff., 259 Entwicklungsplan: 3,163,199 ff., 252 ff., 265 Entwicklungsproduktivität: 1 Epigenese: 140 f., 150 ff.

287

Erfahrungskurve: 189 Erfolgslinie: 190 f. Evolution eines Softwaresystems: 150 Evolution in Organisation: 145 Evolutionäres Management: 145 Evolutionary design: 79 Evolutionssprung: 142,144,157 Expertensystem: 70 ff. 139,158 f., 189,205 Exploration: 33,64, 83,98 f., 207 Externe Selektion: 141,150,163 f., 244 F&E -*• Forschung und Entwicklung F&E-Programm-Portfolio: 183 ff. FLEX -*• Flexible T e r m i n i e r u n g

Flexible Planung: 201,210 Flexible Terminierung (FLEX): 224, 231 ff., 259 Floyd: 2,61 ff., 69,80,87 Forschung und Entwicklung (FuE, F&E): 1,10,13,66,183 ff, 188, 243 FuE - • Forschung und Entwicklung Führungs-Rollen: 210 Führungsstil: 6, 22,24 ff., 212 Funktionsauswahl: 62 ff., 69 ff., 83 f., 96, 99, 101,207 Gantt-Diagramm: 105,108 Ganzheitlich: 7 , 1 6 , 2 7 f. General systems theory: 14 Generationssprünge: 139,158 f. Genotyp: 140 f., 150 f., 244 Genpool: 146,151 GERT ->• Graphical Evaluation and

Review Technique Gesellschaft für Projektmanagement (GPM): 4

GPM Gesellschaft für Projektmanagement

Stichwortverzeichnis

288

Hacker-Mentalität: 73 Hallmann'. 62 Hansel: 7,27,20 Hauschildt: 13 Heterogenität der Ziele: 52,107 Heuristik: 57,115,215,217 Hybride Projektmodelle: 101 Hypertextsysteme: 238,249

Konfigurationsmanagement: 106, 127 ff., 151,172,214, 226, 229 ff., 236 f., 245, 250 f. Kontextfaktor: 91 Kontingenzmodell: 91 f., 94,96,97 f. Koontz, O'Donnel: 6 Kostenkontrolle: 105,136 Kostenschätzung: 105,137,195 Kostenüberschreitung: 195 f. Kritischer Pfad: 112,114,121,218 Krüger: 7,93 Kurbel: 82 ff., 174, 211, 243, 257, 264 Kybernetik: 19 ff.

Individuelle Datenverarbeitung: 165 Informations-Infrastruktur: 179,181 ff. Inkrementalismus: 149,160,162 Inkrementelle Spezifikation: 82 Inspektion: 101,124 f., 127,245 Integrated Project Support Environ-

LI ->• Leitstand LI Laszlo: 142,144 Leitstand: 234 Leitstand LI: 236,239,265 Lindblom: 148 Loopy linear: 58 Lucas: 70, 79, 84, 87, 263

Graphical Evaluation and Review Technique (GERT): 115 f.

Groupware: 243 Gruppenaktivität: 230 f., 237 f., 240 f. Guimares: 91 ff.

m e n t s (IPSE): 138

Intensitätsmäßige Anpassung: 120 Interdisziplinär: 4,40,16,19 Interface-Gap: 188 Interne Selektion: 141,150,163 f, 182,244 INTERNET: 4

Integrated Project Support Environments Iterative Enhancement: 79 f. IPSE

Knowledge-Manager: 255 f. Kommunikationsbedürfnis: 166 Kommunikationsplan: 175 f. Kommunikationsverlust: 43 ff. 165, 240 Komplexität der Software: 47 Komplexitätsbarriere: 47,107,125, 132

Machbarkeitsstudie: 64,72,98 f. Mailbox: 241 ff., 261 Malik: 149 Management control: 170 f. Management Information Systems (Mis): Management-Perspektiven: 7 Management-Process: 7 , 1 0 , 1 2 Management-Technik: 6 Managementinterventionen: 147, 160,162,170,182 Mängelbewertung: 247,249 Matrixorganisation: 35,211 McGregor: 23 f., 26 f., 149,166 Mechanistische Organisation: 30,42, 102,131,171,262 Meilenstein: 108 Menschenführung: 6 f., 104

Stichwortverzeichnis

Meta-Variation: 146 Methoden der Netzplantechnik: 110, 120 Metra Potential Method (MPM): 111 f., 117 f. Migrationsplanung: 196 Mis Management Information Systems Mock-up: 65 Modell-Effekt: 74,90 Moving Target: 48 MPM ->• Metra Potential Method Müller-Böling: 166, 263 Mutation: 140 f. Natürliche Auslese: 140 f. Nissen: 42 Nolan: 262 f. Normalfolge: 111,117 f., 175 Normative Kraft des Faktischen: 73 Operational control: 170 Optimalen Teamgröße: 47 P-Program "Program-solution"Program Partizipation - • Benutzerbeteiligung Partizipationsebene: 100 Partizipationsloch: 78, 86 Partizipatives Klima: 166 PDM ->• Precedence Diagram Method PEAP ~> P o r t f o l i o - M e t h o d e f ü r die

Steuerung evolutionärer Anwendungsentwicklungs-Projekte People & Project Management: 27 PERT ->• P r o g r a m Evaluation and

Review Technique Peters: 148 Phänotyp: 140 f., 150,244 Phasen-Prototyping: 78 Phasen-Theorem: 13 Phasenübergänge: 57

289

Phasenüberlappung: 12 Pietsch: 174,243 Pilotanwender: 66 Pilotsystem: 77 Pinkenburg: 5 Plugin: 58 PMA - • Projektmodell-Schema Population ecology: 145,149, 150, 154 f. PORT

puffer-orientierte T e r m i n i e -

rung Portfolio-Management: Portfolio-Methode für die Steuerung evolutionärer Anwendungsentwicklungs-Projekte (PEAP): 184 f., 205 f., 265 Post-Implementation Aftershock: 156 f., 159,199 PPS -*• Produktionsplanung- und -Steuerung Pre-Release: 66,223 Precedence Diagram Method (PDM): l l l f . , 118,202 Primat der Planung: 29 f., 40,102, 104,107,127,135,139,159 Problemlösungszyklen: 20, 39 Produkt-Lebenszyklus: 10 ff. Produktionsplanung- und -Steuerung (PPS): 155

Profit Center: 263 Program Evaluation and Review Technique (PERT): 110 ff., 215 ff. Program-solution Programm (PProgram): 40 f. Project profile: 169 Projekt-Begriff: 4 ff. Projekt-Evolution: 196 Projekt-Lebenszyklus: 10 ff., 18,44, 50 f. Projekt-Organisation: 8,25 f., 35 Projekt-Toolbox: 255, 257 f. Projektbibliothek: 131

290

Stichwortverzeichnis

Projektdeterminanten: 30 f. Projektmanagement-Methodik: 6,13, 251,264 Projektmanagement-Philosophie: 9, 16 Projektmanagementsystem: 3,136 f., 252 ff. Projektmodell für die evolutionäre A n w e n d u n g s e n t w i c k l u n g (SPE):

180 f. Projektmodell-Parameter: 97 P r o j e k t m o d e l l - S c h e m a (PMA): 9 6 f.,

100 ff., 171,200, 209, 265 Projektpolitik: 27,169 Projektstrategie: 170 f. Projektstruktur-Manager: 255,258 Prototyping, Definition des: 61 Prototyping-Dimensionen: 96 Prototyping-Werkzeuge: 70 f., 73 Puffer-orientierte Terminierung (PORT): 222,224 Pufferbemessung: 218 Q&D -»• Quick & Dirty Qualitätsmanagement: 243 ff., 247 ff. Qualitätssicherung: 45,106,122 ff., 172 f., 176, 213 f., 218, 221, 229, 236,243 ff. Qualitätssteuerung: 243 ff. Qualitätszirkel: 165,173,180 f., 200 Quantitative Anpassung: 120 Quick and dirty (Q&D): 61,69,91, 98 f., 160,165 Randolph: 27,30 Rapid Prototyping: 69 f., 79, 81,88, 91,101 Regelkreis: 19 Requirements Engineering: 106 Requirements scrubbing: 135 Reserve-Puffer: 220

Retention: 141,146,151,164,196, 205, 244, 245 Review: 83,95,101,123 ff., 131, 138, 163, 208, 214, 219, 220, 222 f., 226, 229 ff., 241, 244 f., 251 Risikoanalyse: 105,133 f., 137 Risikoprofil: 182 f. Rollenkonflikt: 166 Rollenkonzept: 210 ff., 224,226 f., 257 Routing: 242 Royce'. 51 Rückwärtsterminierung: 218 Rüsberg: 7 S-Program Specification-Program Saynisch: 7 Scandinavian Approach to Software Engineering: 165 Schlüsselaktivitäten: 228, 236,241 Schnellschuß: 69,99 Sei Software Configuration Item Scientific Management: 7 f., 10,33 SCM Software-Konfigurationsmanagement Scoring-Verfahren: 182,185,196, 206 Selbstorganisation: 145,148 f., 155 ff., 165 ff., 173, 177, 210, 212; Autopoiesis Selbstorganisierende Systeme -> autopoietische Systeme Self managed teams: 165 f., 173 Semi-strukturiert: 31 SGB Strategischer Geschäftsbereich Sicherungssystem: 167 ff., 171,173, 176 SIE Strategische Informationsfunktionseinheit Situativ: 7 f., 24,28 ff., 94,96,136 Software Configuration Item (Sei): 129 ff., 151

S tichwortverzeichnis Software-Evolution: 251 Software-Konfigurationsmanagement (SCM): 128 f., 138

Software-Krise: 1 Software-Risikomanagement: 134, 136 Softwarequalität: 74 f., 94,101,123, 158,186,189,204 Softwaretechnik für Evolutionäre Partizipative Systementwicklung (STEPS): 87 ff., 1 2 7 , 1 6 3 , 2 0 6 , 2 6 3

Sozio-technisch: 15,38 SPE (Strategisches) Projektmodell für die evolutionäre Anwendungsentwicklung Specification-Program (S-Program): 40 f., 124 Spezifizierung: 105 Spiralmodell: 94 ff., 136,163,199 Stab-Linien-Organisation: 25,35 Stage model, Nolan's -*• Stufenmodell, Nolan's Stagewise model Stufenmodell von Bennington Standardarbeitsplan: 228,234,247 Standardsoftware: 61,67,77,137 f., 185,213 STEPS ->• Softwaretechnik für Evolutionäre Partizipative Systementwicklung Steuerungsausschuß: 182 Strategische Informationsfunktionseinheit (SIE): 183 Strategischer Geschäftsbereich (SGB):

183 Strategisches Projektmodell für die evolutionäre Anwendungsentwicklung (SPE): 180,182,189, 196,200, 205 f., 251,265 Strukturanalyse: 105,108,210,214 Stufenmodell, Nolan's: 262 ff.

291

Stufenmodell von Bennington (stagewise model): 50 f. Sviokla: 36 Systems Project Management: 7 Systemtechnik: 19,33 Systemtheorie: 14,21,143 Task-Manager: 242 f., 255 ff. Taylor: 8,22 f. Technologische Trägheit: 153 Terminkalender: 230 ff., 238 f., 243, 261 Terminplanung: 115,119 f., 238 Terminüberschreitung: 119, 121, 194 f. Tertilt: 166,188 Test-Kontext: 247 f. Teufelsquadrat (des Projektmanagements): 103,135,172 Theory X: 22 ff., 132,228 Theory Y: 22 ff., 132,166 Theory Z: 25,149 Theory Y: 228 Thomsetv. 27,30 To-do-list: 238 Umsteuerungspotentiale: 167 ff., 201 ff. Unstrukturiert: 31 f., 61,69 Unternehmenskultur: 25,187 Validierung: 55 f., 63 f., 76,78,125 f., 131 f., 151, 161, 171 f., 213, 223, 236 Verhaltensorientiert: 8,21,28, 30, 33,36 Verifikation: 54 ff., 94,123,125, 131, 151,161, 171 f., 213, 223, 236 Versioning: 61,63, 83 ff., 89 ff., 90 f., 93, 158, 180, 208

292

Versionsverwaltung: 45,60,132, 138,236 Verzahnung (von Anforderungen und Realisierung): 38,107 Vierte Generation: 71 Vorwärtsterminierung: 221 Wachstumsmuster: 152 Wartungskosten: 75,91 Wasserfall-Modell: 51 f., 56,60,96, 100,116,161,201,203 Weber: 38 f. Wissensbasiert: 116,121 f., 255 f. Wohlstrukturiert: 31,33 Zeitanalyse: l l l f . , 121 Zeitliche Anpassung: 120 Zielsystem: 18,62,64,71,74,77 81, 84, 95,125, 213 Zogg: 7 Zweckrationalität: 98,160 ff., 167 ff., 172 Zyklische Vorgehensmodelle: 69

Stichwortverzeichnis

Anhang

A Kommunikationsverlust bei Teilteambildung

B Fallbeispiel zum Software-Portfolio

C Spezifikation der Terminierungs-Algorithmen

D Beispielmasken für das Qualitätsmanagement

A/l

Abb.: A-l

Anhang

Kommunikationsverlust bei Teilteamgröße 4

Abb.: A-2 Kommunikationsverlust bei Teilteamgröße 5

Kommunikationsverlust bei Teilteambildung

Abb.: A-3 Kommunikations Verlust bei Teilteamgröße 8

A/2

B/1

Anhang

Fallbeispiel zum Software-Portfolio

Scoring-Variablen Kürzel

Bedeutung

T-CMP

Kompatibilität mit bestehender Softwaretechnologie

T-INF

Auswirkungen auf die Informations-Infrastruktur

T-SWT

Softwaretechnisches Niveau

T-STD

Bezug zu technischen Standards

T-LER

Sammeln von Erfahrungen; Lerneffekte

T-IMG

Imageeffekte

Kürzel

Bedeutung

A-CMP

Kompatibilität mit bestehenden Fähigkeiten der Anwender

A-ECO

Ökonomischer Wert

A-STD

Standardisierung(spotential)

A-RAT

Rationalisierung(spotential)

A-HUM

Auswirkungen auf die Arbeitsqualität

A-USG

Akzeptanzniveau

Fallbeispiel zum Projektportfolio

B/2

Beispiel-Projekte

1

MKT-XPS

Um den Anschluß an die technologische Entwicklung nicht zu verlieren, wurde nach einem Einstieg in die Expertensystem-Technologie gesucht Als erfolgversprechender Kandidat für ein Pilotprojekt wurde in einer Studie u.a. der Bereich Marketing ermitttelt. Zur Unterstützung der Produktdisposition wird ein Expertensystem für die kurzund mittelfristige Prognose der Absatzentwicklung erstellt und eine Arbeitsgruppe aus Marketingfachleuten und erfahrenen Vertriebsmitarbeitern für die Wissensakquisition gebildet. Die ersten Ergebnisse blieben hinter den Erfahrungen zurück, es wurden jedoch wertvolle Erfahrungen hinsichtlich der "Anwendung" und der "Technologie" gesammelt. 2

LA-PORT

Für die spezifischen Belange einer Unternehmung wurde vor Jahren ein Lagerverwaltungssystem in Assembler entwickelt. Das Programm ist nicht sonderlich benutzerfreundlich und nur schwer wartbar. Im Laufe der Zeit haben sich eine Reihe zusätzlicher Benutzerwunsche angesammelt, eine Umstellung wurde bisher wegen des hohen (Umstellungs-)Aufwands vermieden (Altlasten!). In Anbetracht einer bevorstehenden Änderung der Lagerstruktur bietet sich ein Austausch der Software an. Mit dem Einsatz von auf dem Markt verfügbarer Software wäre eine starke organisatorische Umstellung verbunden. Die vorhandene Software soll deshalb unter Berücksichtigung der bisher nicht bearbeiteten Anwenderwünsche und der sonstigen Erfordernisse (Datenbankanschluß, neue Dialogstandards etc.) in eine moderne Programmiersprache portiert werden. Das Projekt konnte relativ termingetreu und ohne signifikante Kostenüberschreitungen durchgeführt werden und steht kurz vor dem Abschluß.

B/3

3

Anhang

MKT-INF

Im Zusammenhang mit der Wissensakquistion in MKT-XPS wurden Möglichkeiten zur Verbesserung der Effektivität der Marketing-Aktivitäten diskutiert, und die Entwicklung eines entsprechenden Informationssystems als Projektvorschlag eingebracht. Das Projekt wurde mit einigen Abstrichen bewilligt und die Entwicklung eines Prototyps termingerecht abgeschlossen. Der Prototyp wird zur Zeit eingehend evaluiert. Die ersten Ergebnisse sind erfolgversprechend. 4

KONF-XPS

Innerhalb des MKT-xps-Projekts stellte sich heraus, daß die Produktkonfigurierung sich eher für die Erstellung von Expertensystemen eignet als für das Marketing. Deshalb wurde ein entsprechendes Projekt zur Exploration von Einsatzmöglichkeiten auf der Basis des MKT-xps-Projekts initiiert. Die Anwendungsvorteile werden in diesem Bereich zwar nicht so hoch eingeschätzt, dafür ist die Erfolgswahrscheinlichkeit jedoch höher. 5

INT-DB

Schon vor der Initiierung von LA-PORT und MKT-INF wurde die Installation eines leistungsfähigen relationalen Datenbanksystems mit angschlossenen Data-Dictionary beschlossen, um Softwareentwicklung und -Wartung zu unterstützen und eine Grundlage für ein effektives Informationsmanagement zu schaffen. Die beiden Projekte stellten die ersten Pilotanwendungen dieser neuen Basissoftware dar. Die Integration bestehender Datenbestände und Anwendungen soll im Rahmen des langfristig angelegten Projekts INT-DB vorangetrieben werden.

Fallbeispiel zum Projektportfolio

B/4

Projekt-Scores:

1

Punktschätzung a)

Einzelscores

Kriterium Gewicht

MKT-XPS

FIBU-PORT

MKT-INF

KONF-XPS

INT-DB

T-CMP

20

0

60

50

-10

-50

T-INF

25

30

0

60

10

60

T-SWT

20

20

60

0

0

40

T-STD

10

0

80

0

0

70

T-LER

15

80

5

5

60

30

T-IMG

10

50

0

30

40

10

A-CMP

10

0

10

0

30

-30

A-ECO

30

50

0

80

30

0

A-STD

10

30

0

10

80

50

A-RAT

20

50

0

60

90

10

A-HUM

10

10

50

0

0

0

A-USG

20

10

50

-20

40

0

b) Gesamtscores Gewichtetes Mittel der Einzelscores: Score

MKT-XPS

FIBU-PORT

MKT-INF

KONF-XPS

INT-DB

Technologie

29

21

19

16

36

Anwendung

30

11

33

46

4

B/5

Anhang

Gewichtete Norm der Einzelscores: Score

MKT-XPS

FIBU-PORT

MKT-INF

KONF-XPS

INT-DB

Technologie

38,9

45,6

38,6

26,5

36,8

Anwendung

37,0

27,5

50,6

54,2

13,4

Intervallschätzung a) Einzelscores Kriterium Min;Max]

MKT-XPS

FIBU-PORT

MKT-INF

KONF-XPS

INT-DB

T-CMP

-100;100] [0;0]

[55,70]

[40,60]

[-20,0]

[-70,-30]

T-INF

-100; 100] [0;50]

[0;10]

[50;70]

[0;20]

[0;100]

T-SWT

-100; 100] [-50;0]

[50;60]

[-20;0]

[-50;0]

[0;60]

T-STD

-100; 100] [0;0]

[75;85]

[-10,10]

[0;0]

[0;100]

T-LER

0;100]

[0;10]

[0;10]

[30;90]

[20;60]

T-IMG

-100; 100] [-20;30]

[0;0]

[-60;50]

[0;90]

[0;20]

A-CMP

-100; 100] [-20;20]

[0;20]

[-30;30]

[10;50]

[-50;0]

A-ECO

0;100]

[0;70]

[0;0]

[0;90]

[-30;50]

[0;0]

A-STD

-100; 100] [0;40]

[0;0]

[0;20]

[0;100]

[0;60]

A-RAT

0;100]

[0;0]

[20;70]

[0;100]

[0;20]

A-HUM

-100;100] [10;20]

[0;60]

[-10; 10]

[0;10]

[0;0]

A-USG

-100; 100] [0;40]

[0;60]

[-40;10]

[-10;50]

[0;0]

[50;90]

[0;80]

Fallbeispiel z u m Projektportfolio

B/6

b) Gesamtscores Gewichtetes Mittel der Einzelscores: Score

MKT-XPS

FIBU-PORT

MKT-INF

KONF-XPS

Technologie

[-5;29]

[18;25]

[1;25]

[-6;28]

[3;58]

Anwendung

[-2;51]

[0;14]

[-7;48]

[-12;60]

[-5;10]

MKT-INF

KONF-XPS

DMT-DB

Gewichtete Norm der Einzelscores: Score

MKT-XPS

FIBU-PORT

Technologie

[-5,4;57,5]

[0;33,4]

Anwendung

[12;43,9] [40,8;49,6] [22,2;47,1]

[-18,59,7] [-17;67,1] [-21;46]

INT-DB

[-15;21] [-30;67,9]

C/1

Anhang

Spezifikation der Terminierungs-Algorithmen

WITH Zeit_rechnung; USE Zeit_rechnung;

PACKAGE SPECIFICATION Netzplan IS TYPE knoten IS RECORD o, h, o, d, GP, FP, FRP :

-- optimistische Schätzung der Dauer -- geschätzte häufigste Dauer -- pessimistische Schätzung der Dauer -- berechnete Dauer — Gesamtpuffer — freier Puffer -- freier Rückwärtspuffer Zeitraum;

:

— frühester -- frühestes -- spätester -- spätestes Termin;

ES, EF, LS, LF

Start Ende Start Ende

VorwTerm, -- Vorwärts terminiert RueckTerm -- Rückwärts terminiert : BOOLEAN; weitere Selektoren END RECORD; —

weitere Typen

PROCEDURE is_null (T : IN Termin) RETURN BOOLEAN; PROCEDURE is_null (K : IN Knoten) RETURN BOOLEAN; PROCEDURE is_null (K : IN Knoten) RETURN BOOLEAN; PROCEDURE Succ (Von : IN Knoten; letzter : IN Knoten := null_termin) RETURN Knoten; PROCEDURE Pred (Von : IN Knoten; letzter : IN Knoten := null_termin) RETURN Knoten;

Spezifikation der Terminierungs-Algorithmen

PROCEDURE PERT

(Quelle, Senke : IN OUT Knoten; ES : IN Termin LF : IN OUT Termin

PROCEDURE PORT (Quelle, Senke : IN OUT Knoten; ES : IN Termin; LF : IN OUT Termin -- ... weitere Prozeduren; END Netzplan;

C/2

-- frühester Start null_termin); -- spätestes Ende -- frühester Start null_termin); -- spätestes Ende

C/3

Anhang

WITH Zeit_rechnung; USE Zeit_rechnung;

PACKAGE BODY Netzplan IS -- interne Prozeduren

- - V O R W Ä R T S T E R M I N I E R U N G

PROCEDURE vorwärts (K : IN Knoten; -- Aktueller Knoten ES : IN Termin); -- Frühester Start Kritisch : BOOLEAN := FALSE;

—

Kritischer Pfad

BEGIN IF NOT K.VorwTerm THEN —

für noch nicht terminierte Knoten

K.d

:= (K.o + 4 * K.h + K.p) / 6

K.abw K.ES K.EF K.VorwTerm Kritisch

:= := := := :=

(K.p - K.o) / 6 ES; ES + K.d; TRUE; TRUE;

ELSE -- für bereits vorwärtsterminierte Knoten IF K.ES < ES THEN —

Aktivität kann erst später beginnen

K.ES := ES; K.EF := K.EF + (ES - K.ES) ELSIF K.ES > ES THEN -- Frühester Termin nicht haltbar Kritisch := TRUE; END IF; END IF; IF kritisch THEN

-- Terminierung der Nachfolger erforderlich

DECLARE SuccK : Knoten; -- Nachfolgende Knoten BEGIN SuccK := Succ (K)

Spezifikation der Terminieiungs-Algorithmen

C/4

WHILE NOT is_null (SuccK) LOOP -- für alle Nachfolger vorwärts (K => SuccK, ES => K.EF); SuccK := Succ (Von => K, letzter => SuccK); END LOOP; END; END IF; END vorwärts; - - R Ü C K W Ä R T S T E R M I N I E R U N G PROCEDURE rueckwaerts (K : IN OUT Knoten; EF : IN Termin; LF : IN Termin) IS Kritisch : BOOLEAN := FALSE;

-- Akt. Knoten -- Frühestes Ende -- Spätestes Ende - Kritischer Pfad

BEGIN IF NOT K.VorwTerm THEN — Fehler: Vorwärtsterminierung -- nicht vollständig ELSIF NOT K.RueckTerm THEN -- Knoten noch nicht besucht Kritisch K.FP K.GP

= TRUE; K.RueckTerm := TRUE; = EF - K.EF; = LF - K.EF;

ELSE IF (EF - K.EF) < K.FP THEN -- Anpasssung freier Puffer K.FP := EF - K.EF; END IF; IF (LF - K.EF) < K.GP THEN — Kritisch := TRUE; K.GP := LF - K.EF; END IF;

Anpasssung Gesamtpuffer

END IF; IF kritisch THEN DECLARE PredK : Knoten; -- Vorgängerknoten aktFRP : Termin; -- freier Rückwärtspuffer von K / Pred BEGIN PredK := Pred (K)

Anhang

C/5

WHILE NOT is_null (PredK) LOOP -- für alle Nachfolger rueckwaerts (K => PredK; EF => K.ES; LF => LF - (K.EF - K.ES)); aktFRP := K.ES + K.GP - (PredK.EF + PredK.GP); IF is_null (K.FRP) OR ELSE K.FRP > aktFRP THEN K.FRP := aktFRP; END IF; PredK := Pred (Von => K, letzter => PredK); END LOOP; END; END IF; END rueckwaerts;

-- P E R T

- T E R M I N I E R U N G

PROCEDURE PERT (Quelle, Senke ES LF IS BEGIN

IN OUT Knoten; IN Termin; IN OUT Termin := null_termin)

imit_Term (Quelle, Senke); vorwaerts (K => Quelle ES => ES); IF is_null (LF) THEN LF := Senke.EF; END IF; rueckwaerts (K => Senke, EF => Senke.EF, LF => LF) ; END PERT;

Spezifikation der Terminierungs-Algorithmen

--PORT

-

C/6

T E R M I N I E R U N G

PROCEDURE PORT_termin : IN OUT Knoten; (K PredKritisch : IN BOOLEAN ES : IN Termin; PredEF : OUT Termin) PredLF : OUT Termin) IS Kritisch : BOOLEAN := FALSE;

-------

Aktueller Knoten "Status" des letzten Knotens Frühester Start EF des letzten Knotens EF des letzten Knotens

-- Kritischer Pfad

BEGIN IF NOT K.VorwTerm THEN — K.ES K.EF K .GS K.FP K.VorwTerm Kritisch

ES; ES + K.o; K.p - K.o; K.h - K.o; TRUE; TRUE;

ELSIF K.ES < ES THEN K.EF K.ES Kritisch

für moch nicht terimierte Knoten

für bereits terminierte Knoten

= K.EF + (ES - K.ES); = ES; = TRUE;

END IF; PredEF := K.ES; IF PredKritisch OR NOT Kritisch THEN — Nachfolger müssen ter -- miniert werden DECLARE Succ : Knoten; -- Nachfolgeknoten LF, -- LF nach Backtracking AktEF, — EF in Bezug auf aktuellen Nachfolger MinEF, MinLF — Minimales EF,LF bgl. ich aller -- Nachfolger : Termin; := null_Termin; BEGIN SuccK := Succ (K) ; WHILE NOT is_null (SuccK) LOOP -- für alle Nachfolger

Anhang

C/7

PORT_termin (K PredKritisch ES PredEF PredLF

=> => => => =>

SuccK, Kritisch, K.ES + K.h, AktEf, LF);

IF LF < (K.EF + K.p) THEN -- Slack reicht für pessimisti -- sehe Schätzung nicht aus PORT_termin (K => SuccK, PredKritisch => Kritisch, ES => K.ES + K.h + (K.ES + K.p) - LF, PredEF => AktEf, PredLF => LF); END IF; IF is_null (MinLF) THEN -- kein Nachfolger vorhanden MinLF := LF; MinEF := AktEF; ELSE -- Ermittlung des minimalen LF und EF IF LF < MinLF THEN MinLF := LF; END IF; IF AktEF < MinEF THEN MinEF := AktEF; END IF; END IF; SuccK := Succ (Von => K, letzter => SuccK) END LOOP; IF is_nu11 (MinLF) THEN -- kein Nachfolger vorhanden PredLF := K.ES + K.p - K.h; K.GP := K.p - K.o; K.FP := K.h - K.o; ELSE -- Nachfolger vorhanden PredLF := MinLF - K.h; K.GP := MinLF - K.EF; K.FP := MinEF - K.EF; END; ELSE

-- Nachfolger müssen nicht terminiert werden

PredLF := EF + K.GP - K.h; END IF; END PORT;

Spezifikation der Tenninierungs-Algorithmen

F L E X

/

C/8

P O R T

PROCEDURE PORT (Quelle, Senke ES LF HEF, HLF : Termin; BEGIN

IN OUT Knoten; IN Termin; IN OUT Termin := null_termin),

PORT_termin (K => Quelle, PredKritisch => TRUE, ES => ES, PredEF => HEF, PredLF => HLF); IF is_null (Ende) THEN LF := Senke.EF; END IF; rueckwaerts

(K EF LF

END PORT;

-- weitere Prozeduren

END Netzplan;

=> Senke, => Senke.EF, => LF);

D/1

Anhang

File: G:\.\IJSER\H0P\L0TUS\f1AENGEL Uiew: Maengelbericht (nach Datum, Sehldes) =Testppotokol i = = = = = = = = = = = = = = = ^ ^ Test Bereich— • Ih Falle einer Hehrfachanzeige ULB •Masken verschiedener Datensätze muß diese explizit angezeigt oder nit einer Heidung belegt »erden * f Implementation der Auswahl- Nasken: •UL.B •Lit-Erf-A l i s t value fehlt Lit-Aendf Bei» Betätigen der Taste in eine» •ULB • Masken Funktionsbereich ohne Dateneingabe erscheint keine applikationsbezogene Fehlermeldung • f In Maske 1 ist die Taste F5 nicht r i c h t i g belegt • Es fehlen applikationsbezogenen •HOP •Masken Fehlermeldungen in allen Nasken • Hardware/1 Feld 4: Orthographie •KAK Hard-Erf Hardware »HOP •Art-Erf 0 Zeichen vergrößert werden Art-Aend Lit-Rpt Li teratur DM ARTIKEL

18/18/89

14:96

Art= = Schwere= •Ergonomi leicht

Ergonomi fehlt Ergonomi ehlerme

leicht

•Tastatur

leicht

•fehlt

leicht

•?

•Datenmod Ergonomi Herteber

leicht

18/18/89

14:

Abb. D-1: Erfassung vom Mängeln

File: G:\.\USER\WOP\LOTÜ$\MAENGEL View: Review: nicht priorisierte Mängel -HaskenWiimiöl^lIHRli«!!! • ftufrcrn eichen vergrößert werden

-Bereich »Art-Erf »Art-Aend »Li t-Rpt »Literatur

Art Prior•Datenm Ergono Herteb

m

f automatische Abkürzung bei Anwendung/1: falsch übernommen • Hardware/1 Feld 4; Orthographie • Thesaurus/1: Mehrfache Namensgebung zu einer Hierarchie möglich -Reports • Der Untertitel von Artikeln sollte auf 68 Zeichen vergrößert werden

-Lceschen-BereicheAbb. D-2: Bewertung von Mängeln (geordnet nach Priorität)

»ARTIKEL •Anw-Erf Hard-Erf Hardware Thesaurus Thes-Erf -Bereich •Art-Erf Art-Aend Lit-Rpt Literatur DH ARTIKEL -Bere i ch -Bereich

•Hertel

Dateni Art Prior-Daten« Ergono Herteb

Art Art

PriorPrior-

Beispielmasken für das Qualitätsmanagement

F i l e : G:\.\USER\HOPNLOTUS\HfiENGEL View: Review: ßatenerfasung (nach =Erfsssen Alphabetische Sortierung bei Listüalue in Literatur Seite l a Anwendung/1 e r f o l g t Ibei iw Funktionsbereich 1 kein Seitenwechsel automatische Abkürzung bei Anwendung/1: f a l s c h überncHRen InpleMentation des1 AuswahlHasken: l i s t value f e h l t Fehlermeldung Literatur/Text/1 falsch,

D/2

18/18/89

14:16

Bereich™ A p t — Sehne Verant P r i o r i t •evtl •Text-An» • Ergono . M Lit •Anw-Erf Ablauf . 1 ? •bald •Anw-Erf

Wertek

. M

•Lit-Erf- •Ergono , 1 Lit-Aend f e h l t •Text-Erf •Fehler J Lit »Art-Erf Daten« J uf 68 zeichen vergrößert werden »Art-Aend Ergono Werteb »Lit-Rpt »Lit »SN »ARTIKEL * Anwendung/1 Feld 8; s t a t t " S t e l l e " Anw-Erf •Layout J andere Bezeichnung f Anwendung/1; Ausrichtung? Anw-Erf Tastai . 1 p Entwieklungswerkzeug/2: Meldung •Soft-Erf •fehlt . 1 nächster Satz f e h l t

•HAH CHS

•evtl

•CHS BSC

•bald

•sofort

•bald •evtl •nicht

Abb. D-3: Bewertung von Mängeln (geordnet nach Schwere) F i l e : G:\.\USER\HOP\L0TUSNHfiERGEL View: Mängelkseitigung: L i t e r a t u m s k e n

18/18/89

fftrt-Erf -Priarü-Sfcafcus-— »bald -zu k a r k • !f h fMonoPriori t-Status f Literatur/Nonographie: es dürfen nur •bald -in Verlage angezeigt werden, fti t-fiend-fiusw -Ppíopt t ^ t a t u s fiext-Anw-Erf -Priarit-Statusf Alphabetische Sortierung bei ListUalue in evtl •zu k a r k L i t e r a t u r Seite l a erl-Band-Erf Priorit-Status «nd-firt-Erf Priori t-Status erl-Hono-Erf Priorit-Status rt-Thes-Erf— Priori t-Status ext-Aend Priorit-Status and-Aend Priori t-Status n«-Aend Priori t-Status rt-Aend Priori t-Status • Der Untertitel von Artikeln s o l l t e auf •bald -zu k a r k Zeichen vergrößert «erden Äartü-Aend -Fri o r i t - S t a t u s kit-Schi-l -Priorit-Status Abb. D-4: Bearbeitung vom Mängeln in Literaturmasken

14:IS

-Test-Verant•yop -CHS BSC -Test-Verant-lest-üerant-Test-Uerarit-Test-Verant-lest-toant-Test-tearit-Test-äJerant-Test-Uerarit-Test-feant-Test-4ie?arit-Test-VerantBSC -Tesi-Verant-Test-l/erant-

D/3

File: G ; \ . \ Ü S E R \ M O P \ L O T Ü S \ H h E N C E L View: Hängelbeseitigung; Daten

Anhang

18/18/89

14:31

Priori t- •Test-Status—Verant-Baten• Anwenäungsnawen ohne Blanks •sofort •m -in Be -BSC • Prssgectoi» schreibt sich Hit e •bald KAK -zu be -BSC • Erklärung der Einordnung l . l . l i n s i g n i f i k a n t evtl m -zu be BSC /DatenModell - P r i o r i t - Test-Status—Verantt Das Felá Hftrt áer Relation ferteeug i s t •klá •CHB zu be HAH überflüssig CHS • m »bald •HÖF zu be -CHS eichen vergrößert «erden BSC /Delation-Priori t- Test-Status—hieran t • Der Untertitel von Artikeln s o l l t e auf S •MOF zu be -CHS Zeichen vergrößert «erden BSC f Bas Felá Hfiri áer Relation Werkzeug i s t •balá •CHB -zu be m überflüssig CHS

Abb. D-5: Bearbeitung von Datenmängeln F i l e : G;\.\ÜSER\HöP\LöTUS\KAENGEL Uiew: Mängelabnake: Nasken

18/18/89

14:

PLit-Epf-ftusw-HaengelArl-Status- - T e s M e r a n t PíexHrí— HaengelArt-Status- -Test-Verantrfirt-Erf-Haenge1 Art-Status- -Test-4ferant• Literatur/Artikel/3, bei Abspeichern •Ablaufste f e r t i g oracle error (Senikolon s t a t t Doppelpunkt) ÜÄffi »Datenwde - f e r t i g MOP -CHS i eichen vergrößert «erden »Ergonomie BSC »Hertebere land-Art- ErftangelArfc-Status •Tes Hieran t Band-Erf-MaengelArt-Status •1est~yerantVerl-BamHrf 4iaengelArt-Status— Test-UerantHono-Erf — — -HaengelArt-Status— Test-Uerant• Literatur/Artikel/3, bei Abspeichern •Ablaufste f e r t i g oracle error (Sesikolon s t a t t Doppelpunkt) Uerl-Mono-Erf -MaengelArt-Status- -Test-ÜeraritArt-Thes-Erf -flaengelArt-Status- -Test-ÜerantText-Ann-Erf—— — -MaengelArt-Status- -Test-ÜerantAnw-Erf-MaengelArf-Status- -Test-äJerantfSoft-Erí-HaengelArt-Status- -Test-Uerant-fkenge1 Art-Status- - T e s t 4 e r a n t hnst-ErfAbb. D-6: Abnahme von Mängeln in Masken

D/4

Beispielmasken für das Qualitätsmanagement

F i l e : g:\.\dserm»f\lotbs\haencel Vie«: Korrigierte Hängel

19/18/89

-Masken-Bereich ' — " !! Literatur/Artikel/3, bei Abspeichern Art-Erf oracle error (Semikolon - • s t aätt l Nono-Er? Doppelpunkt) Literatur • l£ r Untertitel von Artikeln sollte »Art-Erf uf 60 Zeichen vergrößert «erden »Art-Aend »Lit-Rpt »Literatur »DH »ARTIKEL -Eeports•Bereich • Der Untertitel von Artikeln s o l l t e • Art-Erf auf 69 Zeichen vergrößert «erden Art-Aend Li t-Rpt Literatur -Loeschen-Datenffatenltodell• Der Untertitel von Artikeln s o l l t e auf 60 Zeichen vergrößert «erden

14155

Haengelirt-Iester-UerantAblaufste -KSK Datenaode -MOP Ergonoxie Hertebere

CHS BSC

HaencrelArt-Tester-Vmnt-Datenwde -HÖF CHS Ergonomie BSC Uertebere

ARTIKEL -Bereich Haengelftrt--T?ster4ierant-Bereich——KaengelArt-Tester-üerant-Bereich NaengelArt-Tester-toarit• Art-Erf -Datenmde MOP CHS Art-Aend Ergonomie BSC

Abb. D-7: Übersicht über korrigierte Mängel (Ablage)

w DE

G

Walter de Gruyter Berlin • New York

Programmierung komplexer Systeme Herausgegeben von Fevzi Belli und Hinrich E. G. Bonin

Hinrich E. G. Bonin

Software-Konstruktion mit LISP 15,5x23,0 cm. IX, 405 Seiten. 1991. Broschur. ISBN 3-11-011786-X (Band 1)

Günther Becker

Softwarezuverlässigkelt Quantitative Modelle und Nachweisverfahren 15,5x23,0 cm. IX, 162 Seiten. 1989. Gebunden. ISBN 3-11-012227-8 (Band 2)

Günter Matthiessen

Logik für Software-Ingenieure 15,5x23,0 cm. X, 282 Seiten. 1991. Broschur. ISBN 3-11-012228-6 (Band 3)

Horst Zuse

Software Complexity: Measures and Methods 17,0x24,0cm. XVI, 605 pages. 1991. Cloth. ISBN 3-11-012226-X (Band 4)

Ulrich Hoffmann

Einführung in die systemnahe Programmierung Anwenderprogramme und Datenstrukturen 15,5x23,0 cm. XII, 372 Seiten. 1990. Broschur. ISBN 3-11-012466-1 (Band 5) Walter de Gruyter & Co. Berlin • New York Genthiner Straße 13, W-1000 Berlin 30, Tel.: (0 30) 2 60 05-0, Fax: (0 30) 2 60 05-2 51

w DE

G

Walter de Gruyter Berlin • New York

Studien zur Wirtschaftsinformatik Herausgegeben von Karl Kurbel, Uwe Pape und Hans-Jochen Schneider

Detlef Karras / Lutz Kredel / Uwe Pape

Entwicklungsumgebungen für Expertensysteme Vergleichende Darstellung ausgewählter Systeme 15,5x23,0 cm. X, 217 Seiten. 1987. Gebunden.

ISBN 3-11-011294-9

(Band 1)

Lutz Kredel

Wirtschaftlichkeit von Bürokommunikationssystemen Eine vergleichende Darstellung 15,5x23,0 cm. XVI, 368 Seiten. Mit 48 Abbildungen. 1988. Gebunden. ISBN 3 - n - m i 767-3 (Band 2)

Karl Kurbel / Peter Mertens / August-Wilhelm Scheer (Herausgeber)

Interaktive betriebswirtschaftliche Informationsund Steuerungssysteme 15,5x23,0 cm. VI, 354 Seiten. Mit 115 Abbildungen und einigen Tabellen. 1989. Gebunden. ISBN 3-11-012100-X (Band 3)

Peter Pfeiffer

Technologische Grundlage, Strategie und Organisation des Informationsmanagements 15,5x23,0 cm. 337 Seiten. Mit 91 Abbildungen. 1990. Gebunden. ISBN 3-11-012362-2 (Band 4)

Waldemar Urbanek

Software-Ergonomie und benutzerangemessene Auswahl von Werkzeugen bei der Dialoggestaltung 15,5x23,0 cm. XVII, 330 Seiten. Mit 103 Abbildungen. 1991. Gebunden. ISBN 3-11-013420-9 (Band 5) Walter de Gruyter & Co. Berlin • New York Genthiner StraBe 13, W-1000 Berlin 30, Tel.: (0 30) 2 60 05-0, Fax: (0 30) 2 60 05-2 51