Prof. Dr. Bernd Hindel - download.e-bookshelf.de · Prof. Dr. Bernd Hindel startet seine Karriere im Bereich Zentrale Forschung und Entwicklung der Siemens AG, Erlangen. Von 1995

Prof. Dr. Bernd Hindel startet seine Karriere im Bereich Zentrale Forschung

und Entwicklung der Siemens AG, Erlangen. Von 1995 bis 2000 war er in der

Geschäftsführung eines mittelständigen Software-Hauses tätig. Seit 2001 ist

er Vorstandsvorsitzender der Method Park Software AG. Herr Hindel ist

Honorar Professor für Software Engineering an der Universität Erlangen.

Er ist Gründer des ASQF e.V. (Arbeitskreis Software-Qualität und -Fortbil-

dung) und Mitgründer des iNTACS e.V. (international Assessor Certification

Scheme für SPICE-Assessoren). Als Mitglied des DIN ist er Obmann für Soft-

ware- und Systems-Engineering-Standards und vertritt in dieser Rolle

Deutschland in der ISO-Arbeitsgruppe zur Definition von [email protected] · www.methodpark.de

Dr. Klaus Hörmann ist Principal und Partner bei KUGLER MAAG CIE und

dort verantwortlich für die Service Area »Process Improvement«. Er berät

schon seit vielen Jahren namhafte Unternehmen bei Prozessverbesse-

rungsmaßnahmen, schwerpunktmäßig in der Automobilindustrie. Seine

umfangreichen Praxiserfahrungen mit Projektmanagement hat er in zahl-

reichen Seminaren und Veröffentlichungen weitergegeben und vielen

Unternehmen bei der Weiterentwicklung ihrer Projektmanagementpro-

zesse geholfen. Er ist Koautor des Buchs »SPICE in der Praxis« und »Auto-

motive SPICE in der Praxis« (dpunkt.verlag) und außerdem iNTACS ISO/IEC

15504 Principal Assessor und Trainer sowie SEI-autorisierter SCAMPI Lead

Appraiser und CMMI [email protected] · www.kuglermaag.com

Markus Müller studierte Elektrotechnik in Kaiserslautern und an der Uni-

versity of East London sowie Software Engineering an der Fernuni Hagen.

Seit 1994 ist er in führenden Unternehmen in System- und Softwareprojek-

ten als Berater und Projektleiter tätig, seit 2001 überwiegend in der Auto-

mobilbranche. Im Bereich Projektmanagement hat Herr Müller jahrelange

praktische Erfahrungen, u.a. leitete er den Aufbau eines Project Control

Office für einen großen Automobilhersteller, das bis heute alle wichtigen

Elektronikkomponentenprojekte in der technischen Entwicklung betreut. Er

ist »Project Management Professional« gemäß PMI-Zertifizierung sowie

ISO/IEC 15504 (SPICE) Principal Assessor und Trainer. Derzeit ist Herr Müller

Director Operations bei KUGLER MAAG [email protected] · www.kuglermaag.com

Dr. Jürgen Schmied ist Principal Consultant bei der Anywhere.24 GmbH.

Neben sieben Jahren Erfahrung in der Geschäftsleitung der Method Park

Software AG, greift er auf fast 15 Jahre Erfahrung in der Prozessverbesse-

rung nach CMMI und (Automotive) SPICE zurück. Er ist Gründungsmitglied

im German Project Management Board, beim ASQF leitet er die Regional-

fachgruppe »Maturity Models« Nürnberg/Erlangen. Er ist iNTACS ISO/IEC

15504 Trainer und Principal Assessor, autorisierter CMMI Instructor und

Koautor mehrerer Bücher (»Mit CMMI Prozesse verbessern«, »Embedded

Systems – qualitätsorientierte Entwicklung«). An der Universität Würzburg

hält er Vorlesungen zu »Management im Software Engineering«[email protected] · www.anywhere24.com

Bernd Hindel · Klaus Hörmann · Markus Müller · Jürgen Schmied

BasiswissenSoftware-Projektmanagement

Aus- und Weiterbildung zum Certified Professional for Project Management nach iSQI-Standard

3., überarbeitete und erweiterte Auflage

Fachliche Beratung und Herausgabe von dpunkt.büchern im Bereich Wirtschaftsinformatik:Prof. Dr. Heidi Heilmann · [email protected]

Lektorat: Christa PreisendanzCopy-Editing: Ursula Zimpfer, HerrenbergSatz & Herstellung: Birgit BäuerleinUmschlaggestaltung: Helmut Kraus, www.exclam.de Druck und Bindung: Koninklijke Wöhrmann B.V., Zutphen, Niederlande

Bibliografische Information Der Deutschen BibliothekDie Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über <http://dnb.ddb.de> abrufbar.

ISBN 978-3-89864-561-4

3., überarbeitete und erweiterte Auflage 2009Copyright © 2009 dpunkt.verlag GmbHRingstraße 19 b69115 Heidelberg

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urhe-berrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Mehr über die Autoren, Musterlösungen der im Buch gestellten Übungsaufgaben sowie Seminartermine der Autoren finden Sie unterwww.software-projectmanager.de

v

Vorwort

Auch wenn seit Erscheinen unserer zweiten Auflage einige Zeit vergan-gen ist – die Erfahrungen aus unserer praktischen Arbeit als Berater in vielen Projekten und Organisationen zeigen: Obwohl Standards, Kon-ferenzen und Seminare zum Projektmanagement existieren, sind und bleiben Softwareentwicklungsprojekte schwierig. Projektmanagement – angepasst an die spezifischen Eigenheiten und Randbedingungen der modernen und innovativen Softwarebranche – ist dringend notwendig, um Projekte und damit natürlich auch die Unternehmen, die diese Pro-jekte durchführen, zum Erfolg zu führen. Dies wird immer wichtiger, denn in immer mehr Produkten ist immer mehr Software enthalten. Deshalb verwundert es kaum, dass gerade das Thema Software-Pro-jektmanagement von der Industrie stark nachgefragt wird. Aus dieser Situation heraus entstand 2002 beim ASQF (Arbeitskreis Software-Qualität und -Fortbildung e.V., www.asqf.de) ein Arbeitskreis, in dem zusammen mit Vertretern aus verschiedenen Unternehmen ein Lehr-plan für das Thema Software-Projektmanagement erarbeitet wurde, der die Grundlage für dieses Buch ist. Seit 2004 führt das iSQI (Inter-national Software Quality Institute, www.isqi.org) diese Arbeit fort.

Probleme in Softwareentwicklungsprojekten lassen sich auch aus der Assessmenterfahrung der Autoren aufzeigen: Von den sogenannten »reifen« Prozessen, wie sie von »Maturity Models« wie CMMI oder SPICE gefordert werden, sind leider viel zu viele Unternehmen weit entfernt, nicht nur im Projektmanagement! Und eines ist sicher: Pro-jektmanagement ist ein grundlegender Prozess, auf dem alle anderen Prozesse aufbauen. Der Projektmanagementprozess plant und steuert die anderen Prozesse. Und so kann dieses Buch – im Sinne von Prozess-verbesserung – auch als Anstoß gesehen werden, sich selbst im Projekt-management zu verbessern oder Impulse für Verbesserungen im eige-nen Unternehmen aufzunehmen. Gerade im letzteren Fall sind es eher die vielen kleinen Verbesserungen, die ein Unternehmen weiterbringen,

Vorwortvi

als der große Umbruch (»Big Bang«). Iteratives Vorgehen ist heute nicht nur ein Schlagwort bei der Softwareentwicklung, sondern auch bei der Prozessdefinition. Greifen Sie sich daher die für Sie wichtigsten Punkte aus diesem Buch heraus und führen Sie sie schrittweise in Ihrem Unternehmen ein!

Herzlichen Dank an alle Leser, die mit konstruktiven Verbesserungs-vorschlägen zum Gelingen dieser nun vorliegenden dritten, überarbei-teten und erweiterten Auflage beigetragen haben. Gegenüber der zwei-ten Auflage wurden die Kapitel »Vorgehensmodelle in der Soft-wareentwicklung« und »Qualitätsmanagement« deutlich überarbeitet und ein Abschnitt über »Ressourcenmanagement« hinzugefügt. Das PMI/ PMBOK-Mapping wurde auf dessen 2008er Version aktualisiert und ist nun zusätzlich zur Darstellung im Anhang des Buches direkt an den jeweiligen Stellen im Text zu finden, sodass die Zuordnung intuiti-ver erfolgen kann. Zahlreiche kleinere Verbesserungsvorschläge wur-den ebenfalls umgesetzt. Einige wenige Leservorschläge haben wir nicht berücksichtigt, um das Buch kompakt zu halten. Es ist eine Stärke dieses Buches (so das Feedback vieler Leser), dass es eine leicht verständliche und kompakte Einführung in alle wesentlichen, praxisre-levanten Aspekte des Projektmanagements gibt.

Unser Dank gebührt zudem allen, die uns aktiv oder in Form von Reviews bei der Erstellung des Buches unterstützt haben. Ganz beson-ders möchten wir uns bei den Kolleginnen und Kollegen im German Project Management Board bedanken, die bereits bei der Entwicklung des Lehrplans zum iSQI Certified Professional for Project Manage-ment aktiv mitgewirkt haben. Gleiches gilt für Frau Preisendanz vom dpunkt.verlag, die uns immer unterstützt hat. Darüber hinaus danken wir den Kolleginnen und Kollegen unserer Firmen KUGLER MAAG CIE, Method Park Software AG und Anywhere.24, die in zahlreichen fruchtbaren Diskussionen zum Gelingen dieses Buches beigetragen haben. Für ihre konstruktiven Anregungen bedanken wir uns zudem bei Frau Prof. Heilmann.

Viel Erfolg in Ihren Softwareprojekten wünscht Ihnen Ihr Autorenteam

Bernd Hindel, Klaus Hörmann, Markus Müller und Jürgen Schmied Erlangen, Stuttgart, München

April 2009

vii

Geleitwort von Dr. Axel Heinrich

In immer mehr Industrien wird heute die Fähigkeit, Elektronik und Software innerhalb des vorgegebenen Kostenrahmens zu den geplan-ten Terminen und mit höchster Qualität zu entwickeln, zum erfolgs-kritischen Faktor.

Auch in der Automobilindustrie haben Elektronik und Software dramatisch an Bedeutung gewonnen. Aktuell kommt bereits ein Groß-teil der Innovationen im Auto aus der Elektronik, ein Großteil davon aus der Software. Für zukünftige Fahrzeuge wird sich der Anteil der Innovationen im und vor allem auch um das Auto herum nochmals deutlich erhöhen. Damit wird die Beherrschung der Prozesse in der Elektronikentwicklung, aber auch bei den Produktions- und Repara-turprozessen weiter an Bedeutung zunehmen. Für Volkswagen ist die Beherrschung dieser Prozesse eine der wichtigsten Kernkompetenzen und für die Befriedigung unserer Kundenbedürfnisse ein Erfolgsfaktor. Um dem zu begegnen, ist ein modernes Projektmanagement, angepasst an die Bedürfnisse der jeweiligen Organisation, unabdingbar.

Volkswagen begegnet dieser Herausforderung unter anderem mit dem Project Control Office (PCO), eine unabhängige Organisations-einheit, die Projektmanagementwerkzeuge bereitstellt, die Projektleiter bei der Anwendung unterstützt und den Projektfortschritt unabhängig und objektiv bewertet und berichtet. Einige der Werkzeuge, die wir im PCO einsetzen, sind in diesem Buch beschrieben.

Erfolgreiche Projekte haben immer vorab geklärte Spielregeln, Eskalationsmechanismen, transparente Planungen und eine kontinu-ierliche Projektverfolgung. Diese Methoden werden bei Volkswagen auf Lieferanten und die Zusammenarbeit mit anderen Bereichen Schritt für Schritt angewendet. Man kann erkennen, dass die Erfolgs-quote deutlich nach oben geht, wenn die Ansätze beachtet, gelebt und umgesetzt werden. Hinzu kommen zusätzliche Aktivitäten, wie z.B. ein Risiko-Workshop, der vor Beginn eines Projektes mit allen Beteilig-

Geleitwort von Dr. Axel Heinrichviii

ten die tatsächlichen kritischen Pfade beleuchtet und Gegenmaßnah-men definiert. Nach dem Projekt-Kick-off werden die Maßnahmen und Risiken im Projekt dann kontinuierlich verfolgt.

Es ist eine Gradwanderung bei der Umsetzung von Projektma-nagement in innovativen Entwicklungs-, Produktions- und Kunden-dienstabteilungen, einerseits durch standardisierte Vorgaben einen Rahmen zur systematischen und transparenten Projektabwicklung in einem dynamischen Umfeld zu schaffen, andererseits die Mitarbeiter nicht in ihrer Kreativität einzuschränken. Daher sind praxisnahe Methoden, deren Nutzen im Projektteam schnell erkannt wird, ein Schlüssel zum Erfolg.

Leider fehlt praxisnahes Projektmanagement auch heute noch häufig in den Lehrplänen der Hochschulen. Mitarbeiter erwerben die notwendigen Kenntnisse »on the job«, mitunter mit schmerzhaften Erfahrungen. Daher begrüße ich eine fundierte Ausbildung zum Pro-jektleiter sehr.

Das vorliegende Buch beschreibt die notwendigen Teilgebiete des Projektmanagements praxisnah und kompetent und kann eine wert-volle Hilfestellung zur praktischen Umsetzung von Projektmanage-ment in Projekten sein. Die Autoren sind anerkannte Experten mit umfangreichem Erfahrungswissen, erworben in vielen Projekten in der praktischen Anwendung.

Dr. Axel HeinrichLeiter Interaktive Elektronik, Technische Entwicklung

Volkswagen AG

ix

Geleitwort von Stephan Goericke

Im Projektmanagement allgemein und im Software-Projektmanage-ment ganz speziell sind qualifizierte Mitarbeiter sehr gefragt. Wer über profunde Projektmanagement-Skills verfügt, ist also klar im Vorteil. Jedoch wird es zunehmend wichtiger, diese Kenntnisse auch nachwei-sen zu können. Eine Teilnahmebescheinigung nach Weiterbildungen oder Seminaren reicht hier oft nicht mehr aus. Verlangt werden Leis-tungsnachweise in Form von Prüfungen und Zertifikaten unabhängi-ger Instanzen. In diesem Zusammenhang gewinnt Personalzertifizie-rung zunehmend an Bedeutung. Immer mehr Entwicklerfirmen haben diese Notwendigkeit erkannt, allerdings gibt es auf dem Markt der „Certified“-Schulungen ein unüberschaubares Angebot von sehr unterschiedlicher Qualität. Seitens der Wirtschaft werden deshalb Standards gefordert, die den Kriterien Unabhängigkeit, Transparenz und internationale Akzeptanz in vollem Umfang genügen. Das Inter-national Software Quality Institute (iSQI) ist die Anlaufstelle für sol-che Software-Qualitäts-Standards weltweit. Das Zertifizierungspro-gramm des iSQI umfasst neben den Standards iSQI® Certified Professional for Project Management und ISTQB® Certified Tester weitere Qualifizierungen, die den gesamten Lifecycle der Softwareent-wicklung berücksichtigen. iSQI prüft und zertifiziert unabhängig nach diesen Standards. Ebenso sorgt das iSQI gemeinsam mit internationa-len Partnern für die Etablierung der Standards in zahlreichen Ländern auf allen Kontinenten. Im Ergebnis entstehen Zertifizierungen, die international anerkannte Aushängeschilder sind.

Das Interesse am Software-Projektmanagement ist weiterhin enorm. Durch immer komplexer werdende Projekte stellt Software-Projektmanagement eine immer größer werdende Herausforderung für Unternehmen und Projektmanager dar. Projekte erfolgreich ter-min-, kosten- und qualitätsgerecht zu managen, wird immer schwieri-ger. Die Anforderungen an einen Projektmanager sind hoch, die Auf-

Geleitwort von Stephan Goerickex

gaben vielschichtig: Ihm obliegt beispielsweise die Kontrolle des Budgets, er sollte jederzeit den aktuellen Projektstatus kennen und er muss ein ihm unterstelltes Team führen und Termine koordinieren können. Aufgrund der hohen Anzahl der angebotenen Schulungen mit unterschiedlichem Niveau ist es für Arbeitgeber problematisch zu unterscheiden, was er von einem Projektmanager mit einem bestimm-ten Zertifikat erwarten kann und was nicht. Daher ist es vor allem für angehende Projektmanager außerordentlich wichtig, dass ihnen bei Schulungen und Seminaren ein Standard zur Verfügung steht, der ein einheitliches Konzept mit allen wichtigen Inhalten kontinuierlich ver-folgt. Einem Arbeitgeber wird die Personalplanung für ein Projekt leichter fallen, wenn er auf Mitarbeiter mit einem etablierten Projekt-management-Zertifikat zurückgreifen kann. Die vorliegende Auflage dieses Buches unterstreicht die Notwendigkeit eines solchen Standards und schafft in dankenswerter Weise hierfür die Grundlagen. Die Auto-ren haben sich hiermit erneut große Verdienste bei der Weiterentwick-lung des Projektmanagement-Schemas erworben. Ich wünsche allen Projektmanagement-Interessierten Freude beim Durcharbeiten des Buches, viel Erfolg bei der späteren Zertifizierungsprüfung und schließ-lich gutes Gelingen ihrer Projekte!

Stephan Goericke International Software Quality Institute

Director

xi

Inhaltsverzeichnis

1 Überblick, Einführung und Grundlagen 1

1.1 Problemstellung und Motivation . . . . . . . . . . . . . . . . . . . . 4

1.2 Grundlagen: Wichtige Begriffe . . . . . . . . . . . . . . . . . . . . . . 9

2 Vorgehensmodelle in der Softwareentwicklung 13

2.1 Typische Bestandteile von Vorgehensmodellen . . . . . . . . 14

2.2 Wasserfallmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3 V-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4 Vorgehensmodell für IT-Systeme des Bundes:V-Modell XT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.5 Rational Unified Process . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.6 Extreme Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.7 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.8 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3 Projektstart 33

3.1 Der Prozess »Projektstart« . . . . . . . . . . . . . . . . . . . . . . . . 35

3.1.1 Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.1.2 Auswahl von Projekten . . . . . . . . . . . . . . . . . . . . 383.1.3 Projektstartkommunikation . . . . . . . . . . . . . . . . . 40

3.2 Die Projektdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3 Anforderungsanalyse im Überblick . . . . . . . . . . . . . . . . . 44

3.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Inhaltsverzeichnisxii

4 Projektplanung 49

4.1 Überblick Projektplanung . . . . . . . . . . . . . . . . . . . . . . . . 50

4.2 Projektumfang und Meilensteine festlegen . . . . . . . . . . . 52

4.3 Projektstrukturplan erstellen . . . . . . . . . . . . . . . . . . . . . . 53

4.4 Größen- und Aufwandsschätzung durchführen . . . . . . . . 56

4.4.1 Analogieschätzungen . . . . . . . . . . . . . . . . . . . . . 584.4.2 Expertenschätzungen . . . . . . . . . . . . . . . . . . . . . 604.4.3 Weitere fortgeschrittene Methoden . . . . . . . . . . . 634.4.4 Kombination verschiedener Methoden . . . . . . . . 644.4.5 Zusammenhang zwischen Größen- und

Aufwandsschätzung . . . . . . . . . . . . . . . . . . . . . . 65

4.5 Aktivitätenzeitplan aufstellen . . . . . . . . . . . . . . . . . . . . . 67

4.5.1 Überblick über durchzuführende Schritte . . . . . . 674.5.2 Ableiten der Aktivitäten aus dem PSP . . . . . . . . . 684.5.3 Abhängigkeiten zwischen Aktivitäten . . . . . . . . . 684.5.4 Personaleinsatz planen . . . . . . . . . . . . . . . . . . . . 694.5.5 Methodisches zur Aktivitätenzeitplanung . . . . . . 714.5.6 Planungsoptimierung . . . . . . . . . . . . . . . . . . . . . 754.5.7 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.6 Kostenplanung aufstellen . . . . . . . . . . . . . . . . . . . . . . . . 77

4.7 Aufstellen des Projektplans . . . . . . . . . . . . . . . . . . . . . . . 79

4.8 Planungsaktualisierung/iterative Projektplanung . . . . . . . 80

4.9 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5 Projektkontrolle und -steuerung 83

5.1 Fortschrittsüberwachung . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.1.1 Fortschrittsüberwachung aufAktivitätenebene . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.1.2 Fortschrittsüberwachung auf Projektebene . . . . . 935.1.3 Berichte an das Management . . . . . . . . . . . . . . 104

5.2 Projektbesprechungen . . . . . . . . . . . . . . . . . . . . . . . . . . 106

5.2.1 Arten von Besprechungen . . . . . . . . . . . . . . . . . 1065.2.2 Besprechungskultur . . . . . . . . . . . . . . . . . . . . . . 108

5.3 Eingriffsmöglichkeiten bei Abweichungen . . . . . . . . . . . 111

5.3.1 Eingriffsmöglichkeiten des Projektleiters . . . . . . 1115.3.2 Eingriffsmöglichkeiten von außerhalb . . . . . . . . 113

5.4 Ressourcenmanagement . . . . . . . . . . . . . . . . . . . . . . . . 114

5.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

xiii Inhaltsverzeichnis

6 Personalmanagement 121

6.1 Der Faktor Mensch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

6.2 Teamwork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

6.2.1 Team-Building . . . . . . . . . . . . . . . . . . . . . . . . . . 1266.2.2 Team-Managing . . . . . . . . . . . . . . . . . . . . . . . . 1326.2.3 Team-Developing . . . . . . . . . . . . . . . . . . . . . . . 1356.2.4 Team-Closing . . . . . . . . . . . . . . . . . . . . . . . . . . 135

6.3 Qualifikation des Projektleiters . . . . . . . . . . . . . . . . . . . 136

6.3.1 Führungsgrundsätze . . . . . . . . . . . . . . . . . . . . . 1376.3.2 Führungswerkzeuge . . . . . . . . . . . . . . . . . . . . . 1386.3.3 Gesprächsstrategien . . . . . . . . . . . . . . . . . . . . . . 1396.3.4 Konflikte lösen . . . . . . . . . . . . . . . . . . . . . . . . . 142


7 Qualitätsmanagement 145

7.1 Qualitätssichernde Maßnahmen . . . . . . . . . . . . . . . . . . 149

7.2 Planung der Qualitätssicherung . . . . . . . . . . . . . . . . . . . 161

7.3 Prozessverbesserung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

7.3.1 Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1657.3.2 Aufwand und Dauer von

Verbesserungszyklen . . . . . . . . . . . . . . . . . . . . . 171


8 Risikomanagement 173

8.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

8.2 Risikoermittlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

8.3 Risikobewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

8.4 Planung von Gegenmaßnahmen . . . . . . . . . . . . . . . . . . . 182

8.5 Risikoverfolgung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184


9 Konfigurations- und Änderungsmanagement 187

9.1 Konfigurationsmanagement . . . . . . . . . . . . . . . . . . . . . . 188

9.2 Änderungsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . 192

9.2.1 Änderungsmanagement aufProjektsteuerungsebene . . . . . . . . . . . . . . . . . . 194

9.2.2 Operative Ebene desÄnderungsmanagements . . . . . . . . . . . . . . . . . . 194


Inhaltsverzeichnisxiv

10 Projektabnahme und -abschluss 197

10.1 Projektabnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

10.1.1 Typische Probleme . . . . . . . . . . . . . . . . . . . . . . 19810.1.2 Abnahmevoraussetzungen . . . . . . . . . . . . . . . . . 20010.1.3 Praxis und Tipps . . . . . . . . . . . . . . . . . . . . . . . . 203

10.2 Projektabschluss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205


11 Projektorganisation 209

11.1 Organisationsformen . . . . . . . . . . . . . . . . . . . . . . . . . . 210

11.1.1 Stammorganisation . . . . . . . . . . . . . . . . . . . . . 21011.1.2 Stabs-/Einfluss-Projektorganisation . . . . . . . . . . 21011.1.3 Matrix-Projektorganisation . . . . . . . . . . . . . . . 21111.1.4 Reine Projektorganisation . . . . . . . . . . . . . . . . . 214

11.2 Anwendung der Organisationsformen . . . . . . . . . . . . . . 215

11.3 Projektgremien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217


12 Reifegradmodelle 219

12.1 Prinzip von Reifegradmodellen . . . . . . . . . . . . . . . . . . . 219

12.2 Die gängigen Reifegradmodelle im Überblick . . . . . . . . 220

12.2.1 CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22012.2.2 SPICE – ISO/IEC 15504 . . . . . . . . . . . . . . . . . . 224

12.3 Bezug zu Projektmanagement . . . . . . . . . . . . . . . . . . . . 227


xv Inhaltsverzeichnis

Anhang 233

A Fallbeispiel »Mobile Odors« . . . . . . . . . . . . . . . . . . . . . 233

A.1 Firmenbeschreibung Mobile Widget AG . . . . . . 233A.2 Projektdefinition »Mobile Odors« . . . . . . . . . . . 234A.3 Projektstrukturplan . . . . . . . . . . . . . . . . . . . . . . 237A.4 Aktivitätenzeitplan . . . . . . . . . . . . . . . . . . . . . . 238A.5 Personaleinsatzplan . . . . . . . . . . . . . . . . . . . . . . 240

B PMI/PMBOK-Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 241

C Wichtige Hinweise zum Lehrstoff und zur Prüfung zumiSQI Certified Professional for Project Management . . . 245

D Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Glossar 251

Quellenverzeichnis 261

Literatur, Normen und Standards . . . . . . . . . . . . . . . . . 261

Webadressen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

Stichwortverzeichnis 267

Inhaltsverzeichnisxvi

1

1 Überblick, Einführung und Grundlagen

Dieses Kapitel klärt zunächst einige wichtige Fragen zum Buch und führt anschließend in die Thematik des Projektmanage-ments ein. Wichtige Grundbegriffe, die für die weiteren Kapitel erforderlich sind, werden erläutert.

Chaos in der

Softwarebranche?

Zahlreiche Statistiken zeigen: Nur wenige Softwareprojekte werden erfolgreich (hinsichtlich Zeit-, Budget- und Funktionsvorgaben) abge-schlossen. Sehr viele Entwicklungsprojekte werden nur mit erhebli-chen Defiziten zu Ende gebracht, noch viel zu viele scheitern gänzlich [Standish]. Projektmanagement – angepasst auf die spezifischen Eigen-heiten und Randbedingungen der modernen und innovativen Soft-warebranche – ist daher dringend notwendig, um Projekte und damit auch Unternehmen zum Erfolg zu führen.

Und Software geht mittlerweile jeden an! Software ist nicht nur im heimischen oder Büro-PC zu finden, sie hat längst in unser aller Leben Einzug gehalten, jeder ist davon betroffen. Software wurde der Inno-vationsfaktor bei technischen Produkten schlechthin. Heute ist ganz selbstverständlich in jeder Waschmaschine, jedem Trockner, Kühl-schrank, Fernseher, Stereoanlage, Kraftfahrzeug – und diese Liste ließe sich endlos verlängern – Software enthalten. Während zum Beispiel in der Automobilbranche vor etwa 20 Jahren der Software nur ver-gleichsweise wenig Bedeutung zukam, so ist sie heute aus einem Kraft-fahrzeug nicht mehr wegzudenken. Software prägt unser Leben, und Software ist damit ein wesentlicher Faktor in vielen Industrieberei-chen. Der Erfolg dieser Unternehmen hängt maßgeblich von dem Erfolg ihrer Software-Entwicklungsprojekte ab. Trotzdem schneiden viel zu viele Software-Entwicklungsprojekte – bezogen auf Kosten, Termine und Qualität – viel zu schlecht ab.

Zum Thema Projektmanagement wurden eine Vielzahl von Veröf-fentlichungen herausgegeben und Standards definiert. Doch zum spezi-ellen Thema Software-Projektmanagement gibt es – auch international

1 Überblick, Einführung und Grundlagen2

– keine Standards. Sicherlich werden auch im Software-Projekt-management Methoden benutzt, die nicht nur softwarespezifisch sind (zum Beispiel in den Bereichen Projektorganisation oder Projektkont-rolle). Es gibt jedoch eine ganze Reihe von softwarespezifischen Eigen-heiten im Projektmanagement, die so kaum zusammengestellt wurden. Ganz offensichtliche Softwarespezifika im Projektmanagement sind beispielsweise in Kapitel 2, »Vorgehensmodelle in der Softwareent-wicklung«, oder auch bei dem Thema Aufwandsschätzung und Reife-gradmodelle zu finden. Diese (und weitere) Themen werden in diesem Buch softwarebetont behandelt.

Organisationen Welche Organisationen spielen weltweit eine Rolle beim Projekt-management? Hier sind vor allem zwei zu nennen:

■ Die International Project Management Association (IPMA), von derjeweils nationale Vertretungen gebildet wurden. In Deutschland hat dies die GPM (Deutsche Gesellschaft für Projektmanagement: www.gpm-ipma.de) übernommen. Aber auch die GPM (wie auch die IPMA) beschäftigt sich nur allgemein mit Projektmanagement-methoden, nicht mit dem Thema Software-Projektmanagement im Speziellen. Der Lehrstoff der GPM ist sehr schön in dem Werk [Schelle et al. 05] aufbereitet. Die IPMA bzw. GPM bietet auch eine mehrstufige Zertifizierung zum Thema Projektmanagement an.

■ Die zweite sehr bedeutende Organisation ist das Project Manage-ment Institute (PMI) in den USA. Vom PMI gibt es ebenfalls ein Standardwerk [PMBOK 08], in dem die Inhalte zum Thema Pro-jektmanagement definiert sind. Die Zertifizierung nach PMI sowie das PMBoK sind international anerkannt und weit verbreitet. Da der Lehrplan des »iSQI Certified Professional for Project Manage-ment« unter anderem unter Berücksichtigung des [PMBOK 08] erstellt wurde, haben wir in den einzelnen Abschnitten auf die Pro-jektmanagementprozesse des PMBoK referenziert und diese in der Marginalspalte (grau hinterlegt) hervorgehoben. Abbildung 1–1 zeigt die Wissensgebiete und Prozesse nach [PMBOK 08]. In Anhang B sind die Referenzen kompakt in Tabellenform gegen-übergestellt.

1. Project Integration Management

1.1 Develop Project Charter1.2 Develop Project Management Plan1.3 Direct and Manage Project Execution1.4 Monitor and Control Project Work1.5 Perform Integrated Change Control1.6 Close Project or Phase ➞

Abb. 1–1

Wissensgebiete und

Projektmanagement-

prozesse des PMBOK

(nach PMBOK 08])

31 Überblick, Einführung und Grundlagen

2. Abb. 1–1 (Fortsetzung)Wissensgebiete und

Projektmanagement-

prozesse des PMBOK

(nach [PMBOK 08])

Project Scope Management

2.1 Collect Requirements2.2 Define Scope2.3 Create WBS2.4 Verify Scope2.5 Control Scope

3. Project Time Management

3.1 Define Activities3.2 Sequence Activities3.3 Estimate Activity Recources3.4 Estimate Activity Durations3.5 Develop Schedule3.6 Control Schedule

4. Project Cost Management

4.1 Estimate Costs 4.2 Determine Budget4.3 Control Costs

5. Project Quality Management

5.1 Plan Quality 5.2 Perform Quality Assurance5.3 Perform Quality Control

6. Project Human Resource Management

6.1 Develop Human Resource Plan6.2 Acquire Project Team6.3 Develop Project Team6.4 Manage Project Team

7. Project Communications Management

7.1 Identify Stakeholders7.2 Plan Communications7.3 Distribute Information7.4 Manage Stakeholder Expectations7.5 Report Performance

8. Project Risk Management

8.1 Plan Risk Management8.2 Identify Risks8.3 Perform Qualitative Risk Analysis8.4 Perform Quantitative Risk Analysis8.5 Plan Risk Response8.6 Monitor and Control Risks

9. Project Procurement Management

9.1 Plan Procurements9.2 Conduct Procurements9.3 Administer Procurements9.4 Close Procurements


Neben diesen beiden bedeutenden Organisationen engagiert sich noch eine Vielzahl von weiteren Organisationen für das Thema Projektma-nagement. So gibt es beispielsweise auch von der Gesellschaft für Informatik (GI) einen Arbeitskreis für Projektmanagement. Die British Computer Society bietet ebenfalls einen Lehrplan zum Thema Projekt-management an.

Die Liste der Standards sollte jedoch noch zumindest um PRINCE2ergänzt werden. PRINCE2 [Prince2] ist eine Public-Domain-Projekt-managementmethode, die zu geringen Kosten (in England kostenfrei) erhältlich ist. Besitzer ist die englische Regierung. PRINCE2 ist in Eng-land sehr verbreitet und erfreut sich auch international einem wach-senden Zuspruch. Zur elektronischen Dokumentation, die als CD erhältlich ist, gehören auch umfangreiche Dokumentvorlagen.

Aufbau des Buches Nachdem dieses Buch als Begleitbuch zum Kurs »iSQI Certified Professional for Project Management« gedacht ist und somit auch auf die gleichnamige Prüfung vorbereiten soll, finden Sie im Anhang D pro Kapitel eine Liste mit Verständnisfragen zum Lehrstoff. Diese entspre-chen jedoch nicht den offiziellen Prüfungsfragen des iSQI. Die Lösun-gen können von der Webseite der Autoren (www.software-projectma-nager.de) bezogen werden. Prinzipiell ist der gesamte Buchinhalt prüfungsrelevant, denn das Buch orientiert sich recht eng am Lehrplan des iSQI Certified Professional for Project Management. Jedes Kapitel wird durch wenige kursiv gedruckte Sätze eingeleitet, die seine Zielset-zung beschreiben. Am Ende eines jeden Kapitels werden die wichtigs-ten Dinge kurz zusammengefasst. An einigen Stellen im Buch wird das Projektbeispiel »Mobile Odors« angesprochen. Im Anhang A finden Sie einige ausgefüllte Beispieldokumente zu diesem Projekt.

Doch jetzt zurück zum eigentlichen Thema Projektmanagement!

1.1 Problemstellung und Motivation

Bereits in der Einführung zu diesem Kapitel wurde aufgezeigt, dass eine Vielzahl von Projekten schief läuft. In den regelmäßigen Chaos-Studien der Standish Group wird dies näher untersucht. Der Anteil der Projekte, die in der einen oder anderen Form (Kosten, Termine, Quali-tät) deutliche Probleme gegenüber der ursprünglichen Planung hatten, ist zwar weitgehend stabil geblieben. Jedoch hat sich über die Jahre der Anteil der vollständig gescheiterten Projekte glücklicherweise zuguns-ten der erfolgreichen Projekte verschoben. Die unternommenen Anstrengungen im Projektmanagement und zugehörigen Gebieten wie Prozessmanagement (siehe auch Kapitel 12 zu Reifegradmodellen) tra-


gen also langsam, aber sicher – trotz stetig steigender Komplexität im Projektmanagement – ihre Früchte.

Abb. 1–2Misserfolgsfaktoren

Chaos-Reports der Standish Group 1995 2001 2004

Abgebrochene Projekte 31 % 23 % 18 %

Projekte über Kosten- oder Terminplan 53 % 49 % 53 %

Projekte im Zeit- und Terminplan 16 % 28 % 29 %

Misserfolgsfaktoren (aus dem Chaos-Report USA, 1995):

Unvollständige/ungenaue Anforderungen 13,1 %

Mangelnde Einbeziehung der Beteiligten 12,4 %

Ressourcenmangel 10,6 %

Unrealistische Erwartungen 9,9 %

Mangelnde Unterstützung vom Management 9,3 %

Sich häufig ändernde Anforderungen/Spezifikationen 8,7 %

Mangelhafte Planung 8,1 %

Wird nicht mehr benötigt 7,5 %

Mangelndes IT-Management 6,2 %

Mangelndes Technologiewissen 4,3 %

etc.

AnforderungenIn den Chaos-Studien werden auch immer wieder die Hauptmisser-folgsfaktoren benannt:

Als ganz klarer Favorit stellt sich dabei das Thema Anforderungsma-nagement heraus. Bereits der erste Punkt »Unvollständige/ungenaue Anforderungen« ist diesem Thema zuzuordnen, aber auch der zweite Punkt »Mangelnde Einbeziehung der Beteiligten« geht in diese Rich-tung. Zwar wird hierunter nicht nur die mangelnde Einbeziehung des Endanwenders/Kunden verstanden, sondern beispielsweise auch die Projektkommunikation zwischen verschiedenen Teilteams. Aber der Kunde/Endanwender ist hier ebenso gemeint. Ohne jeden Zweifel kann auch der Punkt »Unrealistische Erwartungen« dem Thema Anforderungsmanagement zugeordnet werden, wie auch »Sich häufig ändernde Anforderungen/Spezifikationen«. Zählt man die Prozent-punkte zu diesem Oberthema zusammen, so kommt man auf ca. 44 % alleine für das Thema Anforderungsmanagement. Mangelndes Anfor-derungsmanagement ist damit der Misserfolgsfaktor schlechthin für Softwareprojekte.

Aber dies ist nicht alles, wie Abbildung 1–3 zeigt.

ProjektKunde Technologie

Projektmitarbeiter Anforderungen(intern+extern)

Prozesse

Es ist normal, dass es Probleme gibt!Es kommt darauf an,

wie Sie damit umgehen!

Abb. 1–3

Warum gehen

Projekte schief?


Der gerade angesprochene Punkt »Anforderungsmanagement« spie-gelt sich in Abbildung 1–3 in der Rubrik Anforderungen wider, die dort jedoch in »intern« und »extern« unterteilt ist. Was ist damit gemeint?

Interne und externe

Anforderungen

■ Interne Anforderungen können beispielsweise durch andere Abtei-lungen im entwickelnden Unternehmen entstehen. Wird etwa ein Produkt erstellt, das nach der Entwicklung gefertigt werden muss, so könnten beispielsweise aus der Fertigung zusätzliche Anforde-rungen an die entwickelnde Abteilung gestellt werden, so dass das Produkt später leichter, d. h. effizienter, produziert werden kann.

■ Externe Anforderungen sind Anforderungen eines externen Kun-den und/oder Endanwenders. Der Auftraggeber sitzt also nicht im auftragnehmenden Unternehmen, sondern es handelt sich um eine klassische Auftraggeber-Auftragnehmer-Beziehung.

Neue Technologien Ein weiterer Risikofaktor für Projekte sind neue Technologien. Nicht selten werden diese sofort eingesetzt, anstatt sie vor dem ersten Einsatz im Projekt zu evaluieren. Das Entwicklungsprojekt bekommt dann Probleme, wenn sich später in der Projektarbeit herausstellt, dass diese neue Technologie (noch) nicht das leisten kann, was man sich erhofft hatte. Durch den dann notwendigen Wechsel der Technologie und dem damit verbundenen Wechsel der Entwicklungswerkzeuge kommt das Projekt sehr schnell in Verzug.

Ungeeignete oder nicht

gelebte Prozesse

Ist denn überhaupt klar, was für ein System entwickelt werden soll? Existiert eine klare, eindeutige Zieldefinition für das Projekt? Sinnvollerweise geschieht dies nicht nur in der Form, dass spezifiziert wird, was gemacht werden soll, sondern dass eben auch definiert wird,


was im Projekt bewusst nicht realisiert werden soll. Dies hilft Missver-ständnisse zwischen Auftraggeber und Auftragnehmer zu vermeiden. Diese Fragestellungen zeigen am Beispiel des Prozesses Anforderungs-analyse, dass in den Entwicklungsprozessen selbst Risiken für das Pro-jekt verborgen sein können. Sind die definierten Prozesse adäquat für das gestartete Entwicklungsprojekt?

Projekte werden von

Menschen gemacht!

Projekte werden immer noch von Menschen durchgeführt und erledigen sich nicht durch Technologien, Werkzeuge oder Prozesse von selbst. Ganz im Gegenteil, zum überwiegenden Teil hängt der Pro-jekterfolg an der Motivation und Teamfähigkeit aller beteiligten Perso-nen (dazu gehören nicht nur die Projektteams an sich, sondern zum Beispiel auch Unterauftragnehmer und das Management!). Das gute Miteinander im Projekt und zum Kunden ist entscheidend für den Pro-jekterfolg. Umgekehrt betrachtet heißt dies aber auch, dass genau die-ses eines der größten Probleme für ein Projekt darstellen kann.

RisikomanagementIn der Praxis ist natürlich noch eine Vielzahl weiterer Risikofak-toren anzutreffen. Wie hiermit umgegangen werden sollte, wird in Kapitel 8 dargelegt.

Magisches DreieckDie Folge von eintretenden Risiken wird aber immer sein, dass das Projekt nicht in dem Maße fortschreitet, wie ursprünglich geplant, oder dass das Projekt einfach mehr Geld kostet. Und gerade das Thema »Kosten« ist neben den beiden Faktoren »Zeit« und »Quali-tät« einer der wesentlichen Faktoren, an denen ein Projekt gemessen wird. Kosten, Zeit und Qualität spannen das so genannte »magische Dreieck des Projektmanagements« auf, manchmal auch sinnigerweise das »Konfliktdreieck des Projektmanagements« genannt (siehe auch Abb. 1–4).

Abb. 1–4Magisches Dreieck des

Projektmanagements

KostenQualität

Zeit

Von einem Konfliktdreieck wird deshalb gesprochen, da die drei Fak-toren in Konflikt zueinander stehen. Wird beispielsweise der geplante Endtermin des Projekts um einige Monate vorgezogen – etwa da zu diesem früheren Termin eine wichtige Messe stattfindet, auf der das neue Produkt vorgestellt werden soll –, so geht dies immer zu Lasten der Kosten (weil in der Regel zusätzliches Personal notwendig ist)


und/oder zu Lasten der Qualität (es würde zum Beispiel ausreichen, auf dieser Messe nur einen Prototyp zu präsentieren, d. h., gerade an der Qualitätssicherung würde gespart werden).

Fehlerbehebungskosten Ein großer Posten bei den Projektkosten sind häufig die Fehlerbe-hebungskosten. Hierzu betrachten wir Folgendes: Wie hoch sind die Kosten, um einen identifizierten Fehler im Produkt auszubessern, in Abhängigkeit davon, wie lange dieser Fehler unentdeckt im Produkt (bzw. seiner Dokumentation) enthalten war? Natürlich besteht eine Abhängigkeit derart, dass je länger ein Fehler unentdeckt im Produkt verbleibt, desto höher sind die Kosten, diesen wieder zu beseitigen. Allerdings ergibt sich in der Regel kein linearer Zusammenhang zwi-schen der Zeit und den Kosten, sondern ein exponentieller. Das heißt, es lohnt sich ungemein, Fehler möglichst frühzeitig zu finden und zu eliminieren, d. h. wiederum qualitätssichernde Maßnahmen möglichst frühzeitig durchzuführen [Ebert & Dumke 96, S. 111 ff.]. Ganz offen-sichtlich wird dieser extreme Verlauf der Fehlerbehebungskosten bei Produkten, die massenweise verkauft werden, wie etwa bei PKWs. Sind die ersten Fahrzeuge erst einmal ausgeliefert, dann sind Rückruf-aktionen richtig kostentreibend. Hinzu kommt noch der kaum materi-ell einschätzbare Imageverlust beim Verbraucher!

Zusammenfassend zeigt Abbildung 1–5 die wichtigsten Erfolgs-faktoren für Projekte.

Abb. 1–5

Erfolgsfaktoren

für Projekte

Erfolgsfaktoren

Für Projektabwicklung geeignete Unternehmensorganisation

Hoher Stellenwert von Projektleitung im Unternehmen

Definierte Entwicklungsprozesse, die auch angewendet werden

Verfügbarkeit von Ressourcen

Qualifikation der Mitarbeiter

Funktionierendes Qualitätsmanagement

Kommunikationsprobleme meistern(Einbeziehung der Stakeholder)

Verteilte Entwicklung beherrschen(Unterauftragnehmer, standortübergreifende Entwicklung, Globalisierung, etc.)

etc.

91.2 Grundlagen: Wichtige Begriffe


Projekt

Project Management

Context, Introduction

Ein Projekt ist

■ ein komplexes Vorhaben, ■ das zeitlich durch einen definierten Anfangs- und Endtermin

begrenzt ist sowie ■ durch die Einmaligkeit seiner Bedingungen, wie zum Beispiel Pro-

jektziele, Projektabgrenzung, an der Umsetzung mitwirkende Orga-nisationen und Ressourcen, und

■ durch die fortschreitende Ausarbeitung der Projektergebnisse (z.B. bei Entwicklung eines Ergebnisses über mehrere Projektphasen oder Iterationen) gekennzeichnet ist.

Häufig müssen in Projekten verschiedene Fachgruppen oder -abteilun-gen zusammenarbeiten und gerade hieraus ergeben sich bereits Schwierigkeiten, denn verschiedene Fachgruppen haben oft Probleme beim gegenseitigen Verständnis. In Projekten sind neuartige und unbe-kannte Probleme zu lösen, es existieren damit besondere Risiken. Und eines gilt fast immer: In Projekten existiert ein hoher Zeitdruck für die Mitarbeiter. Bei Projekten sollte immer klar sein: Was sind die Ziele? Und ein Projekt benötigt nicht nur Ziele, sondern auch Budget und Personal, um diese Ziele zu erreichen. Dies klingt trivial, wird aber gar nicht so selten vergessen!

»Was ist ein Projekt, was ist kein Projekt?« Beispiel

Eine Hotline-Tätigkeit ist definitiv kein Projekt, sondern Alltagsarbeit, denn es gilt, tagein und tagaus Fragen von Verbrauchern entgegenzunehmen, zu protokollieren und zu beantworten. Wenn Sie jedoch zum ersten Mal ein Pro-dukt auf den Markt bringen und deshalb bis heute noch keine Hotline in Ihrer Firma installiert haben, so ist das Neuaufsetzen dieser Hotline mit Sicherheit ein Projekt. Dieses Projekt wird einen bestimmten Anfangs- und Endtermin haben (die Hotline muss funktionsbereit sein, sobald das erste Produkt verkauft wurde). Dieses Projekt ist auch ein komplexes Vorhaben, denn Sie wissen wahrscheinlich heute noch nicht, wie man idealerweise eine Hotline betreibt, welches Personal bzw. welche Qualifikationen und welche Werkzeuge hierzu benötigt werden.

Projektmanagement

Project Management

Context, Introduction

Nach DIN 69901 wird unter Projektmanagement die Gesamtheit von

■ Führungsaufgaben,■ Führungsorganisation,■ Führungstechniken und -mitteln


für die Projektabwicklung verstanden. Dabei ist der Begriff »Führung« als die Steuerung der verschiedenen Aktivitäten im Projekt in Hinblick auf die übergeordneten Projektziele zu interpretieren. Die Definition nach DIN stellt dabei besonders die Verbindung von

■ »Was ist zu tun« mit ■ »Wer macht das« und ■ »Wie wird das gemacht«

heraus.Projektphasen Projekte werden üblicherweise in mehrere Phasen unterteilt (siehe

Abb. 1–6).

Abb. 1–6

ProjektphasenVorphase AbschlussKonzeption Abnahme

Zeitachse mit Meilensteinen

Reali-sierung

TestAnalyse

Project Management

Context, Project Life

Cycle

Projektphasen bestehen aus

■ zeitlich verknüpften Projektvorgängen, ■ die in einem logischen Zusammenhang stehen.

Projektphasen werden durch Meilensteine voneinander abgetrennt. Erfolgreiche Firmen haben definierte Phasenübergänge, d. h. eindeutig definierte Meilensteine. Das bedeutet, die Kriterien sind eindeutig fest-gelegt, um überprüfen zu können, ob ein Meilenstein erreicht wurde oder nicht. Üblicherweise gehören zu diesen Kriterien, ob geplante Qualitätsprüfungen – wie zum Beispiel Reviews – vollständig und erfolgreich durchgeführt wurden.

Prozess Ein Prozess ist eine Folge von Aktivitäten mit eventuell parallelen und alternativen Aktivitäten, die Eingangsdaten in Ausgangsdaten transformieren. Die einzelnen Aktivitäten werden gegebenenfalls hier-archisch weiter zerlegt.

Ein Software-Entwicklungsprozess ist damit eine hierarchische Gruppierung von Aktivitäten – wie zum Beispiel Anforderungsanalyse, Design, Implementierung und Test –, die die Anforderungen der so genannten Stakeholder in das Endprodukt, das Softwaresystem, umsetzt. Dies geschieht – wie in Abbildung 1–7 illustriert – in Hinblick auf die übergeordneten Projektziele sowie unter Einsatz von Res-sourcen bzw. der vorhandenen Infrastruktur.

Design

Implementierung

Anforderungs-analyse

Anforderungender Stakeholder

Software-system

RessourcenInfrastruktur

Projektziele

Test

Aktivität


Regelkreis des

Projektmanagements

Abb. 1–7Software-

Entwicklungsprozess

Abbildung 1–8 (aus [Burghardt 00]) zeigt sehr schön die grundsätz-lichen Aktivitäten im Projekt und deren Zusammenhänge. Im unteren Bereich wird ein einfaches Phasenmodell dargestellt.

Projektstart Planungsphase

Anf

orde

rung

en,

Ran

dbed

ingu

ngen

Maß

nahm

en IstSoll

Soll

Aktualisierung Abweichung

Erf

ahru

ngen

Pro

jekt

ausw

ertu

ng (

quan

tifiz

iert

)

Projektdurchführung

Projektplanung Projektkontrolle

Projektsteuerung

Projektabschluss

Abb. 1–8Regelkreis des

Projektmanagements

Zunächst werden die Anforderungen sowie eventuelle weitere Rand-bedingungen als Grundlage für die Projektplanung verwendet. Gege-benenfalls wird erst ein Grobplan erstellt, bevor dieser zu einem Fein-plan detailliert wird. Der Projektplan ist damit die Sollvorgabe an die Projektdurchführung. In der regelmäßigen Projektkontrolle wird der Soll-Ist-Abgleich zwischen Projektplan und der tatsächlichen Projekt-durchführung erstellt. Ergibt sich eine Abweichung, so ist mit geeigne-ten Gegenmaßnahmen darauf zu reagieren, es wird von der Projekt-


steuerung gesprochen. Am Projektende gilt es nun, die im Projekt gemachten Erfahrungen zusammenzutragen und hieraus für zukünf-tige Projekte zu lernen. Üblicherweise erfolgt hier auch eine quantifi-zierte Projektauswertung derart, dass zum Beispiel eine Nach-kalkulation, d. h. Gegenüberstellung von geplanten und tatsächlichen Kosten, stattfindet oder dass Metriken, die während des Projekts gesammelt wurden, ausgewertet werden.

Klassifizierung

von Projekten

Es wird nicht in allen Projekten identisch vorgegangen. Beispiels-weise wird in Forschungsprojekten meist nicht so großer Wert auf Qualitätssicherung gelegt wie etwa bei einem Produkt, welches in Großserie produziert wird. Bei einem Forschungsprojekt geht es pri-mär um den Nachweis, dass eine neue Idee effizient umsetzbar ist. Bei einem Großserienprodukt gehört zur ersten Zielsetzung immer, dass die Qualität des Produktes einwandfrei ist. Auch wird man etwa in Großprojekten anders vorgehen, als wenn man ein Projekt mit nur wenigen Personen durchführen soll.

Beispielsweise lassen sich Projekte u. a. wie folgt klassifizieren:

■ Nach Projekttyp, d. h. etwa reine Softwareprojekte, integrierte Hard-ware-/Softwareprojekte, Forschungsprojekte, Rationalisierungspro-jekte, Wartungsprojekte, Entwicklungsprojekte etc.

■ Nach Aufwand, d. h. zum Beispiel gemessen in Personenjahren. Ein Projekt mit hoher Anzahl an Personenmonaten kann entweder sehr lange dauern (bei wenig zur Verfügung stehendem Personal) oder ein sehr großes Team haben (oder beides in Kombination). Beide Faktoren lassen sich auch als getrennte Dimensionen zur Projekt-klassifizierung darstellen.

■ Nach Dauer, d. h. zum Beispiel in Kalendermonaten gemessen.■ Nach Teamgröße, in Anzahl der Mitarbeiter gemessen.

Stakeholder Stakeholder sind eine wichtige Quelle für Ziele und Anforderungen des Projekts. Unter einem Stakeholder wird eine Person oder eine (Teil-)Organisation verstanden, die von dem Projekt oder dem Projektergebnis betroffen ist. Hierzu können beispielsweise gehören: Geschäftsführung, Marketing- und Vertriebsleitung, Entwickler, Anwender des Systems, Wartungs- und Servicepersonal, Schulungsper-sonal.

13

2 Vorgehensmodelle in der Softwareentwicklung

Dieses Kapitel gibt einen groben Überblick über die wichtigsten Vorgehensmodelle und erläutert kurz deren Vor- und Nachteile.

Vorgehensmodelle –

wozu?

Stellen Sie sich vor, Sie treten in einer neuen Firma Ihre Arbeitsstelle an. Sie bekommen als Erstes die Aufgabe, ein neues Projekt, für das Sie als Projektleiter eingestellt wurden, durchzuführen. In dieser Firma gibt es bis dato keine Richtlinien, wie Projekte durchgeführt werden. Sie beginnen sich selbst zu organisieren, d. h., Sie werden sich aus Ihrer bisherigen Erfahrung heraus überlegen,

■ wie Sie Ihr Projekt zeitlich strukturieren wollen (Sie definieren Pha-sen und Meilensteine),

■ welche Personen was im Projekt ausführen sollen (Sie definieren Rollen und deren Aktivitäten),

■ welche Dokumente bis zu welchem Meilenstein fertig sein sollen (Sie definieren Dokumentvorlagen für Projektpläne, Pflichtenhefte, Designdokumente etc.),

■ welche Methoden und Werkzeuge zur Erstellung der Projektergeb-nisse eingesetzt werden sollen.

Das Rad neu erfinden?Sie haben sich hiermit einen eigenen individuellen Werkzeugkasten, bestehend aus Dokumentvorlagen, Checklisten, Phasen- und Rollen-modell, zum Thema Projektdurchführung geschaffen. Doch was ist, wenn weitere Projekte in Ihrem Unternehmen gestartet werden, die nicht von Ihnen, sondern von anderen Projektleitern geführt werden sollen? Sollen diese Projektleiter wieder von vorne beginnen? Sollen sie genau wie Sie zeitaufwendig ihre eigenen Dokumentvorlagen entwi-ckeln? Oder wäre es nicht vorteilhaft, den Werkzeugkasten, den Sie sich geschaffen haben, an alle zu verteilen und damit nutzbar zu machen? Genau dies soll mit einem Vorgehensmodell im Unternehmen erreicht werden.

Documents

Prof. Dr. Bernd Hindel - download.e-bookshelf.de · Prof. Dr. Bernd Hindel startet seine Karriere im Bereich Zentrale Forschung und Entwicklung der Siemens AG, Erlangen. Von 1995