Modul Einleitung.

Präsentation zum Thema: "Modul Einleitung."—  Präsentation transkript:

1 Modul Einleitung

2 Ziele Die Teilnehmer kennen die wesentlichen Gründe, warum Projekte häufig scheitern ( oder nicht erfolgreich sind ) können Projekte und Projektmanagement definieren und in die IT-Prozesse einordnen kennen die verschiedenen Projekttypen kennen die Ziele des Projektmanagements kennen die wesentlichen Merkmale eines Projektes kennen die Erfolgsfaktoren ( die gesunde Basis ) für ein Projekt

3 Ergebnisse von Studien – gestern und heute
„Die geschätzten Verluste, die allein aus Fehlern im Projektmanagement resultieren, betragen demnach 145 Milliarden Dollar.“ Quelle: Standish Group 1996 „Verschwendung hat einen Namen: Software-Entwicklung“ 50% der Projekte überschreiten ihr Budget 70% dauern länger als geplant 88% erfordern ein wesentliches Neudesign Durchschnittlich 1 Fehler pro 40 Code-Zeilen Quelle: IBM/Teraquest-Studie, 1995 „Effiziente Projektabwicklung ist in Deutschland eher eine Ausnahme“ Das Budget wird gesprengt oder der Zeitrahmen überzogen 88 Prozent der Unternehmen greifen daher bei der Umsetzung auf externe Hilfe zurück Jede zweite Firma hat keine konkrete Weiterbildung in Projektmanagement In jeder dritten Studienrichtung Wirtschafts- und Ingenieurwissenschaften wird Projektmanagement nicht als eigenständiges Lehrfach angeboten Quelle: VWI und Tiba Management-Beratung 2003, Computerwoche 4/2004

4 Beispiele für Risikoquellen in der Softwareentwicklung
Unklare Projektdefinition Einsatz von ungeprüfter oder unreifer Technologie Zu große und zu komplexe Projekte Unerfahrene Mitarbeiter Zu ehrgeizige Entwicklungsziele Mangelnde Managementunterstützung Beschäftigung von Unterauftragnehmern Zu optimistische Aufwandsschätzung

5 Steigende Risiken Alles deutet darauf hin, dass mit neuen Technologien die Risiken steigen: Verteilte OO-Projekte haben eine um 139 % größere Wahrscheinlichkeit zu scheitern und eine um 156 % größere Wahrscheinlichkeit ihr Budget zu überschreiten als konventionelle Projekte. Je mehr neue Technologien eingesetzt werden, um so größer die Risiken !! Harry Sneed: Software-Risikoanalyse aus „Software Management 99“, Teubner Verlag Schmidt; Lyytmen; Keil; Cole: Identifying Project Risks - An International Delphi Study, Hongkong University, 1997

6 Häufiges Problem in Projekten
Test & Abnahme Fehler- ursprung Analyse Design Realisierung Einführung Es kostet mehr, wenn Fehler erst in späteren Phasen entdeckt werden ! „Zone des Chaos“ Fehler- entdeckung Warum teilt man ein Projekt in Phasen auf ? Aus der Praxis kennen wir die dargestellte Situation. Dies insbesonders wenn kein Phasenkonzept oder Vorgehensmodell eingesetzt wird. Diese Problematik ist häufig die Ursache für Terminverzögerungen und Aufwandsüberschreitungen. Man weiß erst am Ende ob man die Anforderungen richtig umgesetzt hat. Dabei erlebt man so manche böse Überraschung. Test & Abnahme Analyse Design Realisierung Einführung Quelle: Capers Jones, Software Quality, International Thomson Computer Press 1997

7 Phasen- und meilensteinorientiertes Vorgehen
Analyse Design Realisierung Test & Abnahme Einführung Fehler- ursprung entdeckung Es werden bessere Produkte erstellt, wenn man die eigenen Fehler frühzeitig entdeckt !

8 Häufiges Problem in Projekten
Definierter Systemumfang Realisiertes System Termin-Überschreitungen Aufwands-Überschreitungen Kosten-Überschreitungen

9 Grundverständnis/Zusammenhänge
Funktionen Daten Fachlichkeit (Betriebswirtschaft) DV-Technik Geschäfts- objekte z. B. - Aufrag - Kunde - Bestellung prozesse z. B. Produktion Auftragsbearbeitung - Distribution Datenbanken z. B. - Auftrags-Datenbank - Kunden-Stamm - Lieferanten-Datei Software-Systeme z. B. - DMS-INA - SAP FI - Auftragssystem Organisation z. B. - Marketing-Bereich - Vertriebs-Bereich - Personal-Bereich Infrastruktur Hardware, Betriebssystem, DBMS, usw., z. B Windows NT, DB2, ORACLE Ziele und Strategie

10 Softwareentwicklung: Merkmale unreifer IT Organisationen
Improvisation - Prozesse sind undefiniert oder werden ignoriert Notfallmaßnahmen - man verlässt sich auf einzelne Helden Pläne werden umgestoßen, oder es werden Kompromisse gemacht bezüglich Funktionalität Fertigstellungsplanung Qualitätssicherung Es gibt keine Basis für objektives urteilen Heldenmärchen: “Man bekommt eine gute Beurteilung, wenn man Notfallmaßnahmen durchführt. Das Resultat ist sichtbar: es kann quantifiziert werden. Wenn man jedoch gleich alles richtig macht, ist das nicht sichtbar. Man hat einfach die Anforderungen erfüllt. Das ist der Job. Aber wenn man zuerst alles durcheinander bringt und dann später korrigiert, dann wird man ein Held.” (W. E. Deming, Out of the Crisis, Cambridge University Press 1986). Deming ist einer der Gurus der amerikanischen Schule des Qualitätsmanagements. Die Beobachtung, die er hier zum Besten gibt, kommt aus seinem Frust über die Tatsache, daß gutes Management oft weniger Ansehen genießt als schlechtes. Wenn ein IV Bereich oder ein Projekt schlecht gemanaged ist, gibt es dauernd etwas zu retten. Das ist die Chance, sich zu profilieren. “Wenn ich nicht gewesen wäre, wäre alles den Bach hinunter gegangen”. Wenn dagegen alles perfekt funktioniert, ist das völlig unspektakulär. Niemand hat eine Chance, sich zu profilieren. Es kann sogar noch passieren, daß man wegen relativ harmloser Verstöße gegen die Regeln zur Rechenschaft gezogen wird. Schließlich muß es ja irgend etwas zu kritisieren geben, denn perfektes Management oder Projekt-Management sind so selten, daß die meisten an seiner Existenz zweifeln.

11 Softwareentwicklung - Merkmale reifer IT Organisationen
Gesteuert: Prozesse sind definiert und werden organisationsweit gesteuert Arbeitsausführung basiert auf definierten/geplanten Prozessen Klar: Klare Verteilung von Rollen und Verantwortlichkeiten Exakte Kommunikation untereinander Objektiv: Leistung und Qualität werden überwacht und analysiert Realistisch: Pläne und Budgets basieren auf Vergangenheitserfahrungen Pläne werden normalerweise erreicht Liefertermine Funktionalität Qualität

12 Das Capability Maturity Model des SEI
“jeder ist ständig damit beschäftigt, alles zu verbessern” Produktivität Optimierend & Qualität steigen “wir legen Regeln fest aufgrund von Erfahrungen aus der Vergangenheit” Gesteuert ”wir wählen unter unseren Praktiken aus durch die Ergebnisse, die sie produzieren” Definiert “wir befolgen die Regeln, außer, wenn wir in Panik geraten” Wiederholbar Risiko Das CMM (Prozeß-Reifegrad Modell) wurde vom Software Engineering Institute (SEI) der Carnegie Mellon University in Pittsbourgh entwickelt. Es basiert auf allgemeinen Arbeiten von Philip Crosby und speziell auf den Softwareentwicklungsprozeß bezogenen Arbeiten von Watts Humphrey. Das Modell besteht aus 5 Reifegradstufen, die jede ihrerseits wieder aus sog. Kernprozessen (Key Process Areas) bestehen, z. B. auf Stufe 2 die Kernprozesse Management der Anforderungen Software-Projektplanung Software-Projektüberwachung und -steuerung Software-Subkontraktmanagement Software-Qualitätssicherung Software-Konfigurationsmanagement. Dieses Modell und das darauf basierende Assessmentverfahren (Verfahren zur Messung und Beurteilung der Qualität des Entwicklungsprozesses) sind in den USA sehr populär. In Europa wird meist ein anderes Assessmentverfahren verwendet, das ebenfalls auf dem CMM beruht: das Bootstrap Verfahren (entwickelt im Rahmen eines europäischen Esprit Projekts). nimmt ab “wir machen das, wozu wir im Augenblick Lust haben” Ad Hoc Quelle: Technical Report CMM/SEI TR - 025, „Key Practises of the Capability Maturity Model“, Mark C. Paulk et al., Software Engineering Institute der Carnegie Mellon University, Pittsbourgh, USA

13 Was versteht man unter Software Engineering ?
Zielorientierte Bereitstellung und systematische Verwendung von Verfahren, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Wartung von Software-Systemen. Zielorientiert bedeutet die Berücksichtigung z. B. von Kosten, Zeit, Qualität.

14 Zusammenhänge: Verfahren, Methoden und Werkzeuge
(organisatorischer Ablauf) Methoden Werkzeuge Methoden und Werkzeuge müssen in ein durchgängiges Verfahren eingebunden sein. Die Anwendung von Werkzeugen setzt die Beherrschung der dort eingesetzten Methoden voraus. Ein Verfahren, z.B. ein Vorgehensmodell, beschreibt die Ablauforganisation eines Projektes. Sie ist weitgehend unabhängig vom Einsatz bestimmter Methoden und Werkzeuge. In einem Verfahren können für einzelne Aktivitäten durchaus unterschiedliche Methoden eingesetzt werden ( z.B. ERM oder OOA ). Eine Methode kann auch durch unterschiedliche Werkzeuge unterstützt werden ( z.B. Prozeßmodellierung entweder mit SILVERRUN oder mit ARIS. Es handelt sich bei dieser Sichtweise sozusagen um eine Schichtenarchitektur.

15 Die Prozesse im Projekt organisieren
Projektmanagement Phase Konfigurationsmanagement ... Vorgehensmodell (System-Erstellung) Qualitätsmanagement Eine erfolgreiche Software-Erstellung und -Anwendung ist nur sichergestellt, wenn System-Erstellung Projektmanagement Qualitätsmanagement und Konfigurationsmanagement ( incl. Änderungsmanagement ) einschließlich ihrer Interdependenzen beherrscht werden!! Die Aufteilung in die verschiedenen Prozesse bietet eine bessere Chance, dieses Ziel zu erreichen. Alle vier Prozesse sollten separat ( aber auch in ihrem Zusammenspiel ) geplant und durchgeführt werden. Alle Prozesse finden in jedem Projekt faktisch sowieso statt ( ob man dies will oder nicht ). Häufig wird allerdings der Aufwand für die Support-Prozesse unterschätzt oder gar vergessen. Dadurch kommen auch Projekte in Terminprobleme.

16 Sammlung von interaktiven Komponenten zur Erfüllung eines
Was ist ein System ? Sammlung von interaktiven Komponenten zur Erfüllung eines gemeinsamen Zwecks. Komponenten können dabei u. a. sein: Funktionen, Organisationseinheiten, Technik Standorte usw. Ein System ist immer Bestandteil eines größeren Systems und kann meist in kleinere Teilsysteme zerlegt werden.

17 Beispiele von Systemen in der Informatik
Betriebssystem Datenbank-Management-System ( DBMS ) Informationssystem Textverarbeitungssystem Softwaresystem Hardwaresystem SAP-System Dokumentenmanagement-System

18 Workflow-Management-System
Arbeits- liste Arbeits- liste Vorgangs-definition Anwender A Anwender B Anwender C Auftrags- verwaltung Lager- disposition Waren- versand

19 Software besteht nicht nur aus Programmen und Daten.
Was ist Software ? Software besteht nicht nur aus Programmen und Daten. Sie setzt sich vielmehr zusammen aus vielen Teilprodukten, wie z. B. Analyse-Modell Architektur-Modell Programme Benutzerhandbuch, Hilfesystem Testdaten usw. „Computer programs, procedures, rules, and possibly associated documentation and data pertaining to the operations of a computer system.“ ( IEEE Standard Glossary of Software Engineering Terminology / ANSI 83 / ).

20 Software, Software-Produkt und Software System
Software ist der allgemeine, neutrale, aber auch unbestimmtere Begriff. Software-Produkt betrachtet Software von „außen“ aus Käufer- oder Auftraggebersicht. Software-System stellt die „innere“ Sichtweise dar, d. h. so wie ein Entwickler Software sieht.

21 Software-Entwicklung und System-Entwicklung
Spricht man von Software-Entwicklung, dann meint man die ausschließliche Entwicklung von Software. Spricht man von System-Entwicklung, dann meint man oft die Entwicklung eines Systems, das aus Hardware-, Software- und organisatorischen Komponenten besteht. IS-Projekte befassen sich meist mit der Systementwicklung, da unser Service gegenüber dem Fachbereich meist auch die Bereitstellung der Hardware- und Systemsoftware umfaßt.

22 Anforderungen an die Entwicklung von Software Systemen
Funktionstreue d. h. die Übereinstimmung der definierten Anforderungen mit dem fertiggestellten System. Qualitätstreue d. h. die Übereinstimmung der definierten Qualitätsanforderungen mit dem fertiggestellten System. Termintreue d. h. die Einhaltung der im Projektplan festgelegten und dem Kunden zugesagten Fertigstellungstermine. Kostentreue d. h. die Einhaltung des in der Wirtschaftlichkeitsrechnung geplanten Personal- und Sachaufwandes für die Systemerstellung und -pflege. Die Betonung liegt auch auf Übereinstimmung der definierten Produkt- und Qualitätsanforderungen. Sind diese Anforderungen nicht vorher definiert, so ist die anschließende Beurteilung der Beliebigkeit ausgesetzt. Die Verantwortung wird meist beim IS-Mitarbeiter abgeladen. Deshalb ist es ratsam, zu Beginn des Projektes die Produkt- und Qualitätsanforderungen gemeinsam mit dem Auftraggeber festzulegen. Sie sind sozusagen „Vertrags-Bestandteil“ zwischen Auftraggeber (Fachbereich) und Auftragnehmer (IS-Bereich).

23 Veränderungen im Software Engineering
Systementwicklung gestern Gründe für Veränderung: Kosten reduzieren Keine „Schleifen“ drehen Klare Vorgaben Qualität der Software verbessern Analyse Design Realisierung Test Einführung Früher wurde in der Systementwicklung der meiste Aufwand in die Realisierung ( Programmierung ) gesteckt. Dies hat sich jedoch als ein falsches Vorgehen herausgestellt, da dadurch sehr oft festgestellt wurde, daß die fachlichen Anforderungen noch nicht klar waren und man alles neu programmieren mußte. So entstanden mehrere Iterationen, bis klar war, was der Anwender eigentlich will. Deshalb ist in der heutigen Systementwicklung unumstritten, daß man zunächst mehr Aufwand in die Analyse der fachlichen Anforderungen stecken muß. Mittlerweise sind die Analyse-Methoden so ausgereift, daß man diese fachlichen Anforderungen sehr gut identifizieren und modellieren kann und somit weitgehend präzise festlegen kann. Darüberhinaus stehen Werkzeuge zur Verfügung, die einem die fachlichen Anforderungen auch in die technische Umgebung entsprechend umsetzen und damit auch keine Doppelarbeit entsteht. Analyse Design Realisierung Test Einführung Systementwicklung heute

24 Systementwicklung morgen ?
Analyse Design Einführung Realisierung Test Neuere Entwicklungen, wie z.B. die komponentenbasierte Entwicklung eröffnen für die Zukunft noch bessere Möglichkeiten, den Prozeß der Systementwicklung zu optimieren. Die komponentenbasierte Entwicklung geht davon aus, daß ein System sich aus eigenständigen Modulen ( Komponenten ) zusammensetzt. Diese Komponenten werden möglichst allgemeingültig erstellt, so daß auch andere Systeme diese wiederverwenden können. Dies ist im Prinzip ein alter Wunsch im Software Engineering. Mit der Objektorientierung ist aber ein wesentlicher Schritt in diese Richtung erfolgt und es gibt mittlerweise auch in der Praxis erfolgsversprechende Ansätze. Wenn man diesen Weg konsequent weiterdenkt, würde dies bedeuten, daß man zumindest einen großen Teil zukünftiger Systeme durch die Montage von fertigen Bausteinen abdecken könnte. Montage von fertigen und getesteten Bausteinen ( Komponenten-basierte Entwicklung )

25 Was ist ein Projekt? „Ein Projekt ist ein zeitlich begrenztes Vorhaben zur Schaffung eines einmaligen Produkts oder einer Dienstleistung“ (PMBOK) Merkmale: Es ist ein einmaliges Vorhaben 2. Es ist zeitlich begrenzt (Start- und Endtermin) Es hat (muss haben!) klare Ziele Es ist ein komplexes Vorhaben, das verschiedene Techniken und Methoden erfordert Es erfordert ein Team zu seiner Durchführung In der Regel sind neuartige und unbekannte Probleme zu lösen Es steht unter einem besonderen Risiko Es hat ein zugewiesenes Budget Während des Projekts stehen Leiter und Mitarbeiter unter einem besonderen Druck

26 Definition: IT-Projekt
Zeitlich befristetes Vorhaben zur Installation, Entwicklung oder Weiterentwicklung eines Informationssystems (Software-Produkt, Hardware etc.) oder eines Teilergebnisses (z. B. Vorstudie oder Fachkonzept) im vorgegebenen Zeit- und Budgetrahmen.

27 Projektkategorisierung
Gleichzeitig mit der Entscheidung für ein Projekt kann eine Zuordnung getroffen werden, die das Projekt eindeutig in eine Vordefinierte Kategorie enteilt. Dies hat folgende Vorteile: Abhängig von der Projektkategorie kann die geeignete Projektorganisation festgelegt werden Eine geeignete Prozessstruktur (Vorgehensmodell) kann ausgewählt werden, die den auf den spezifischen Projekttyp zugeschnittenen Projektablauf in der Durchführungsphase bestimmt. Bei Aufwandsschätzungen kann auf die Erfahrungen bei ähnlichen bereits abgeschlossenen Projekten zurück gegriffen werden. Die Projektkategorie wird bei der Risikomanagementplanung herangezogen, um den zu treibenden Aufwand der Risikomaßnahmen abzuschätzen.

28 Beispiel: Zweidimensionale Projektkategorisierung

29 Verschiedene IV-Projekttypen
Kommerzielle Eigenentwicklung Technisch-wissenschaftliche Eigenentwicklung Einführung von Standard-Anwendungssoftware Individuelle Datenverarbeitung (z. B. Executive Information System) Reverse- / Reengineering (DV-technisch ) Business Process Reengineering Elektronischer Datenaustausch / EDIFACT usw.

30 Projektmanagement: Einordnung und Abgrenzung
Projektmanagement ist die Gesamtheit aller Führungsaufgaben für die Abwicklung eines Projektes (DIN 69901). Vorbereiten und planen Überwachen und Steuern Abschließen Projektmanagement-Prozess Projektdurchführung (Systementwicklung)

31 Ziele des Projektmanagements
Investitionsschutz Das Management kann seine Investitionen schützen, indem es sicherstellt, dass das Projekt klar definiert ist und dass alle Beteiligten am gleichen Strang ziehen. Transparenz Management und Benutzer wissen immer im Projektverlauf, was sie von dem Projekt wann erwarten können. Der Status aller Projekte steht jederzeit im Zugriff. Ergebnis-Qualität Die Qualität der Ergebnisse kann gesichert werden Termin- und Kostentreue Überraschungen, wie z. B. Terminverzögerungen oder Kostenüberschreitungen können minimiert werden Machbarkeit Durch frühzeitige Erkennung von Ressourcen- oder sonstigen Problemen ist eine realistische Einschätzung der Machbarkeit gegeben. Einbindung des Fachbereichs Das Vorgehen nach diesem Verfahren stellt eine adäquate Einbindung des Managements und Fachbereichspersonals in IT-Projekte sicher.

32 Unterschiedliche Perspektiven

33 PM: Unternehmenssicht

34 PM: Projektsicht

35 PM: Mitarbeitersicht

36 PM: Gemeinsamkeiten und Resumee

37 PM: Der Werkzeugkasten

38 Anforderungen an das Projektmanagement
Beherrschung der Komplexität Einordnung des Vorhabens in den unternehmerischen Gesamtzusammenhang Koordinierung der Mitarbeiter Koordinierung der unterschiedlichen Interessen, Anforderungen und Zielvorstellungen Festlegung von Zielen, an denen sich der Erfolg des Projekts messen lässt Festlegung von messbaren Qualitätskriterien Durchsetzung der Qualitätsanforderungen Durchführung von realistischen Schätzungen Entwicklung von Plänen Kontrolle von Ergebnissen und steuerndes Eingreifen bei Abweichungen Orientierung aller Beteiligten auf das gesetzte Ziel hin

39 Die gesunde Basis eines Projektes
Es existiert ein Auftraggeber Es gibt einen gemeinsam verabschiedeten Projektauftrag Es wird eine Projektgruppe eingerichtet Es gibt einen Projektleiter Es existiert ein Lenkungsausschuss Die Verantwortlichkeiten sind zugeordnet und werden wahrgenommen Es wird in definierten Phasen mit definierten Meilensteinen gearbeitet eine realistische Aufwandschätzung und Termin- und Ressourcenplanung

40 Projektmanagement und -controlling: Ein definierter Prozess!!
Projektantrag Vorbereiten Projekt Planen/ Organisieren Projektauftrag Projektplan Steuern Projektarbeit Abschließen Projekt- Durchführung MA-Zeitaufschreibungen Ergebnisse Projekt-Status-Report Projekt-Controlling- Bericht Projektabschlussbericht Berichten Projektstatus Change Requests genehmigte und Planänderungen Abnahme-Protokoll Vorbereiten Projekt Es wird ein Projektauftrag erstellt, der die Machbarkeit des Projektes sicherstellt und eine gemeinsame ”vertragliche” Basis zwischen dem Auftraggeber und dem Auftragnehmer darstellt. Die in diesem Prozeß definierten Rahmenbedingungen schaffen die Voraussetzungen für einen reibungslosen Ablauf des nachfolgenden Projektes. Planen Projekt-Durchführung Auf der Basis des Projektauftrags wird ein detaillierter Projektplan erstellt, der den Aufwand, die Termine und Ressourcen im Detail plant. Danach wird der vorgegebene Rahmen bestätigt oder ggfs. angepaßt. Anschließend werden die Ressourcen durch den Projektmanager aktiviert. Steuern Projektarbeit Diese Aktivitäten steuern und unterstützen die parallele Projektdurchführung. Dies beinhaltet die Freigabe der Arbeitspakete, das Überwachen des Projektfortschritts und das Messen und Managen der Projekt-Ressourcen. Berichten Projektstatus Diese wiederkehrenden, periodischen Aktivitäten berichten über den Projektstatus und veranlassen korrigierende Maßnahmen. Diese Aktivitäten müssen in enger Abstimmung mit dem Auftraggeber und dem Steering Committee stattfinden. Dazu dienen im wesentlichen regelmäßige Statusmeetings. Abschließen Projekt Diese Aktivitäten werden durchgeführt, um ein Projekt ( oder eine Projektphase ) sauber abzuschließen. Dazu gehören u.a. eine Zusammenfassung der Projektdokumentation, die Herstellung der Ergebnisakzeptanz und die Bestätigung des Projekterfolgs. Dies sollte im Rahmen eines gemeinsamen Reviews stattfinden. Alle Projektbeteiligten sollten informiert werden.

41 Beziehungen zwischen PM und Systementwicklung
Ziele des Managements Baselines Planen, Überwachen, Steuern Management Ziele und Eingriffe Produkte Systembenutzer System entwickeln Anforderungen u./o. Vorprodukte Bericht über Ergebnisse