UKPA 1 II Das Unternehmen als Kontext der Projektabwicklung Produktionsfaktor: Information (vgl....

UKPA 1

II Das Unternehmen als Kontext der Projektabwicklung

• Produktionsfaktor: Information (vgl. Systemwürfel) soll in geeigneter Form entsprechend definierter Vorgaben bzgl. Ort, Zeitpunkt, Menge bereitgestellt werden. diesem Zweck dient das Informationssystem

• Ziel eines Informationssystems ist es, die- in einem Unternehmen vorhandenen Informationen,- in einem Unternehmen nachgefragten Informationen- für ein Unternehmen notwendigen Informationenauf den Arbeitsprozess so abzustimmen, dass damit die bestmögliche Leistung erbracht werden kann

UKPA 2

Informationssystem-Management

• Das ISM erstreckt sich auf die Entwicklung und den Betrieb der Informationssysteme von Unternehmen

• Zwei gegensätzliche Anforderungen müssen ausgewogen werden:

1 Entwickler und Anwenden sollen möglichst wenig einschränkt werden, um neue Applikationen rasch und kreativ einführen/erstellen zu können.

2 Entwickler und Anwendungen müssen so koordiniert werden, daß Doppelarbeit, Insellösungen, umständliche Abläufe vermieden werden, damit das IS längerfristig entwicklungsfähig bleibt und das IS mit der Geschäftsstrategie zusammenpaßt.

UKPA 3

Informationssystem-Management

(Jenny, Abb. 1.17,S. 19)

UKPA 4

Stufe: IS-Konzept

Das IS-Konzept ist durch die Informationsstrategie selbst Teil der Unternehmensstrategie. Es muss daher mit den anderen Bereichsstrategien (Markt-, Produkt-, ...) in Einklang stehen.

(Jenny, Abb.1.19,S.22)

UKPA 5

Stufe: IS-Konzept

• Das IS-Konzept enthält Normen, wie:– Leitbild und resultierende Erfolgsfaktoren

– Grundsätze

– Standards und Richtlinien

• Das IS-Konzept enthält Beschreibungen von Vorgehen und verantwortlichen Stellen, wie:– Projektmanagement

– IS-Organisation

– Methoden der Systementwicklung

– Prinzipien des IS-Controlling

UKPA 6

Stufe: IS-Architektur• Einheitliche Architektur ist erforderlich, da i.a. viele interne und

externe Partner an der Entwicklung eines IS beteiligt sind.• Eine integrierte IS-Architektur ermöglicht die gemeinsame

Nutzung von Informationen mittels Unterstützung verschiedener Anwendungen.

• Umfassende, Informatik-orientierte Gesamtkonzepte für Unternehmen können realisiert werden.

(nach Jenny,Abb. 1.19, S. 22)

UKPA 7

Stufe: IS-Architektur - Komponenten

• IS-Architektur umfaßt:

– Datenmodell: konzeptuelles Modellist implementierungsunabhängig, daher flexibel

– Prozeßmodell: erfaßt alle Geschäftsabläufe;vorteilhaft: top down und bottom up Erfassung

– Systemmodell: Gliederung von Geschäftsfällen entsprechend der Konsumation/Erzeugung gleicher Datenklassen; daraus: Ableitung von Subsystemen ;Subsysteme entsprechen oft Geschäftsbereichen wie Produktion, Vertrieb, etc. .

– Gerätemodell (siehe PRI I)

UKPA 8

Stufe: IS-Architektur Daten- und Prozessmodell

• bei Anwendung eines objekt-orientierten (OO) Ansatzes sind Daten- und Prozessmodell eng verknüpft

• Beispiel: Klassendiagramme und Use-Case-Diagramme im UPKlassenmodell (d.h. Daten wie auch die darauf definierten Operationen) wird aus der Modellierung von Use-Cases (Geschäftsfällen) abgeleitet. grobe Vorgehensskizze:– Identifikation und nat.spr. Beschreibung von Use-Cases– zunächst Normalabläufe, dann seltenere (Ausnahme)Fälle– Hierarchische Anordnung von Use-Cases– Ableitung des Klassenmodells

UKPA 9

Stufe: IS-Architektur Daten- und Prozessmodellbeispiel

ABS-Transaktion durchführen

Konto abfragen Einlage tätigen Abhebung tätigen

<<extends>> <<extends>>

Zugriff prüfen

<<uses>>

Quittung drucken

<<uses>>

Drucken

<<uses>>

<<uses>>

<<extends>>

<<uses>>

Überweisung tätigen

Überweisungsbestätigung drucken

<<uses>>

<<uses>>

<<extends>>

UKPA 10

Stufe: IS-Architektur Daten- und Prozessmodellbeispiel

1Kontonr.

1

QuittungDatumTextAnfangsbetragEndbetrag

1

Schalter

0..1

TransaktionZeitstempelArtBetrag

1 0..1

eingegeben an

1

ABS

1

ABS-Code

1Bankcode

Konsortium

1

ABS-Code

1

besitzt

1

1Ang#

1

1

BBS-Code

1

Kartencode

*

1

11Kontonr.

BankName

1Bankcode

gehört zu

1..*

1

Kunde

NameAdresse

1

*

1

Kassier

Name

1

Ang#1 beschäftigt

0..10..11

BBS

1

BBS-Code

besitzt

*

1

BargeldkarteLosungscodeSeriennr

Kartencode

ausgegeben von

*

1

hat

0..1

1

1

1

KontoSaldoRahmenTyp

führt

1..*

1

hat

1

*

gehört zu

BBS-Transaktion

1

0..1

eingegeben von

0..11 eingegeben an

1..2

ABS-Transaktion

*

1

autorisiert durch

0..1

1

1

ZugriffArtBetrag

1

1

betrifft

1..2

1

UKPA 11

IS-Projektportfolio

• globales Ziel des IS-Projektportfolios:Initialisierung des richtigen Projektes mit den erforderlichen Ressourcen zur richtigen Zeit im richtigen Unternehmens-bereich.

• die für eine Aufnahme ins IS-Projektportfolio gestellten Bedingungen werden i.a. nach individuellen Unternehmenskriterien festgelegt.Unterschiedliche Vorhaben können so verglichen und priorisiert werden, damit die (möglichst objektiv!) wichtigsten Vorhaben realisiert werden können.

UKPA 12

IS-Projektportfolio

• Aufgabe des IS-Projektportfolios ist es, aufzuzeigen:

– welche Projekte durchzuführen sind,

– wann mit welchen Projekten begonnen werden kann,

– wann ein Projekt abgeschlossen sein muß,

– welche Projekte parallel bzw. sequentiell realisiert werden sollen,

– wie lange das gesamte Realisierungsvorhaben dauert,

– wie hoch der (jährliche) Realisierungsaufwand ist.

UKPA 13

IS-Projektportfolio - Ablauf

• 1. IS-AntragAufnahmekanäle:IS-Architektur oder Fachabteilungen:

intern oder extern produzierte Bedürfnisse

• 2. Bewertung

• 3. Machbarkeitsstudie

• 4. Entwicklungsplanung

• 5. Projektfreigabe:Entwicklung auf der IS-Projektebene

• 6. IS-Entwicklungskontrolle:via Kontrollgrößen wird der Bezug zur Planung koordiniert

UKPA 14

IS-ProjektportfolioAblauf: Antrag - Bewertung

* Zwecks fachgerechter Prüfung/Bewertung der IS-Anträge, sollten darin folgende Projektmerkmale festgelegt sein:

• Projektumfang und Projektdauer

• Projektspezialitäten, z.B. Innovationsgrad, spezielle Infrastruktur, spezielle Methoden/Vertragsbedingungen,…

• Projektbedeutung: Stellenwert gegenüber der Konkurrenz, strategische/finanzielle Gewichtung, Prestigeobjekt,…

• Projektkomplexität: grobe Schätzung durch Einflußgrößen:- Anzahl der betroffenen Organisationseinheiten: gegenseitige Abhängigkeiten, Querverbindungen- Bereich der starken Veränderung: bzgl. Daten - Geschäftsfällen- Bereich der Methoden- und Toolwahl

UKPA 15

IS-ProjektportfolioAblauf: Antrag - Bewertung

• Projektkosten:Entwicklungs-, Management-, Produktinvestitionskosten

• Projektrisiken: möglicher Schaden für das Unternehmen, falls die Projektziele nicht erreicht werden

• Projektintensität:Ausmaß der Auslastung der Mitarbeiter während der Dauer des Projektes

• Projektart:Unterstützungs-, Entwicklungs-, Organisationsprojekte

UKPA 16

IS-ProjektportfolioAblauf: Machbarkeitsstudie

• Ziel der Machbarkeitsstudie: Beurteilung der Durchführbarkeit und Wirtschaftlichkeit eines Projektes

• Aufwand: max. 3 Personenmonate, Dauer < 2 Monate• Ergebnis: Management-Summary mit folgenden Themen:

- Ausgangslage- Ziele und Lösungsansätze- Wirtschaftlichkeitsanalyse- Risikoanalyse- Projektorganisation- Projektgesamtplanung- Aufgliederung in Teilprojekte- Erweiterter IS-Antrag

UKPA 17

IS-ProjektportfolioAblauf: IS-Entwicklungsplanung

• Ziel der Entwicklungsplanung: Festlegen der Reihenfolge der Projekte und Zuordnung der Ressourcen für die Realisierung der Projekte

• Entwicklungsplan: Erstellung durch Gremium mit gutem IS-Architektur Wissen und Managementkompetenz

* Schritte :

• Ermittlung der unternehmerischen ReihenfolgeKriterien: Unternehmensziele, Wirtschaftlichkeit

• Ermittlung der betrieblichen Reihenfolge

UKPA 18

IS-ProjektportfolioAblauf: IS-EntwicklungsplanungKriterien: Wichtigkeit/Dringlichkeit, zur Verfügung stehende Ressourcen, betriebswirtschaftlicher Aufbau der IS-Architektur

• Aufstellung des applikatorischen Migrationsplans: Kompromiß; enthält die Realisierungsreihenfolge der Projekte

• Personal- und Finanzplanung• Risikoanalyse der Projektanträge:

Hauptproblem: “Was könnte während der Projektabwicklung mit welcher Wahrscheinlichkeit passieren und welches wären die Folgen dieser Ereignisse”.

UKPA 19

IS-ProjektportfolioAblauf: Entwicklungsplanung

Beispiel einer Tabelle zur unternehmerischen Reihenfolge der Projekte:

(Jenny Abb. 1.25, S. 35)

UKPA 20

IS-ProjektportfolioAblauf: Entwicklungsplanung

Beispiel eines applikatorischen Migrationsplans

(Jenny Abb. 1.29, S. 38)

UKPA 21

IS-ProjektportfolioAblauf: Entwicklungsplanung

Beispiel eines Portfolio-Personalplans

(Jenny Abb. 1.28, S. 37)

UKPA 22

IS-ProjektportfolioAblauf: Entwicklungsplanung

Beispiel eines Portfolio-Finanzplans

(Jenny Abb. 1.28, S. 37)

UKPA 23

IS-ProjektportfolioAblauf: Entwicklungskontrolle

* Aufgaben:• Planungskontrolle: Kosten/Aufwand und Termine werden mit

den Planungsvorhaben des Portfolios verglichen• Projekt-Sachfortschrittskontrolle:

SOLL-Vorgaben des IS-Projektportfolios werden mit den IST-Zuständen (z.B. aus Phasenabschlußberichten) verglichen

• Kontrolle des IS-Entwicklungsplans: alle Resultate der IST-SOLL-Vergleiche der laufenden Projekte bilden zusammengefaßt den “Statusbericht zur Umsetzung des IS-Entwicklungsplans”; Rückkopplung in das Projektportfolio

• Projekt-Nachkontrolle: direkter IST-SOLL-Vergleich bzgl.:Entwicklungskosten, Wirtschaftlichkeit, Projektdauer.

UKPA 24

Informationssystem-ProjektProjektebene der IS-Pyramide: IS-Projekte werden gemäß dem IS-Entwicklungsplan zusammengestellt.

(Jenny, Abb.1.32, S.43)

UKPA 25

Informationssystem-ProjektKomponenten der Projektabwicklung im IS-Projektbereich

(Jenny, Abb. 1.33, S.44)

UKPA 26

Informationssystem-ProjektStandards und Richtlinien der Informatik-Abteilung

• Quellen1) IS-Architektur: Hardware, zentrale SW, Konzeption,…;Ausrichtung auf Daten-, Prozeß-, Systemmodell2) Organisationshandbuch: - wird auf die Informatik-Abteilung spezialisiert;- enthält betriebliche Regelungen und Vorschriften als Umsetzung des Leitbildes des Unternehmens

• Leitbild: umfasst– Unternehmensgrundsätze: Verhalten der Unternehmung

gegenüber Umwelt, Kunden, Staat, etc.– Führungsgrundsätze: Verhalten von Vorgesetzten zu

Untergebenen (wird hier nicht behandelt)

UKPA 27

Informationssystem-ProjektGliederung des Standards und Richtlinien Handbuches:

(Jenny, Abb. 1.35, S. 47)

UKPA 28

Informationssystem-ProjektRichtlinien für die Projektabwicklung

• Projekthandbuch (PHB): beinhaltet organisatorische Regelungen für die Projektorganisation und -durchführungPHB ist ggf. Teil des S&R Handbuches

* Ziele:

• Grundlagen der Abwicklungsziele festlegen

• Arbeitsweise im Projekt festlegen

• Verbindliche Richtlinie für die Zusammenarbeit

• Zuweisung von Aufgaben, Kompetenzen und Verantwortungen an beteiligte Stellen

• Festlegung der Projektorganisation

UKPA 29

Informationssystem-ProjektRichtlinien für die Projektabwicklung

• Grundlage zur Erteilung detaillierter Aufträge im Rahmen des Projektes

• Unterstützung bei der Erstellung und Ausarbeitung notwendiger Verträge

• Festlegung des obligatorischen Outputs der aus den im PHB angeführten Tätigkeiten

* Kommentar: es ist sehr wichtig, daß die Richtlinien für die Projektabwicklung offen gehalten werden, um das Projekt-team nicht zu behindern, sondern zu unterstützen. dazu dient:

• Tailoring: Mit dem Tailoring werden die nichtrelevanten Tätigkeiten, die im PHB angeführt sind, gestrichen. Damit wird gewährleistet, daß der Aufwand für jedes Projekt situationsgerecht ist.

UKPA 30

Informationssystem-ProjektRichtlinien für die Projektabwicklung

Metamodell eines Projekthandbuches:

(Jenny, Abb1.36,S. 49)

UKPA 31

• Key-PHB

Übergreifende Standards, Organisationsübersichten und Projektqualifikationswerte etc. werden im Key-PHB aufgeführt.

• Literaturverzeichnis, Glossar, Definitionen

Den Benutzer unterstützende Schriften sind in diesem Modul aufgeführt, so dass er diese in der Bibliothek einfach finden kann. Auch das Glossar und die Definitionen werden in dem Grad aufgebührt, dass es für den Anwender unterstützend ist.

• Projektmanagement

Das Modul Projektmanagement enthält die allgemeingültigen Projektleiter-Aufgaben sowie die Vorgaben des Problem- und Änderungsmanagements, des Konfigurationsmanagements, des Risikomanagements sowie des Qualitätsmanagements.

Informationssystem-ProjektGliederungsschema für ein Projekthandbuch

UKPA 32

• Vorgehensmethode

Hier werden die in einer Firma angewandten Vorgehensmodelle und ihre Anwendungsberechtigungen erläutert.

• Projektorganisation

Hier werden die Gremien (Stellen und Instanzen) und Organisationsformen, die innerhalb einer Firma für ein Projekt gebildet werden müssen oder können, aufgeführt. Im weiteren können weitere zusätzliche institutionelle Werte (z.B. Informationssystem etc.) aufgeführt werden, die in den Projekten ihre Anwendung finden.

• Dokumentation

Hier werden alle notwendigen Vorgaben (Schlüsselwerte, Strukturen etc.) bezüglich der zu erstellenden Dokumentation aufgefiihrt. So auch die Strukturen der externen Projektsicht, z.B. Verträge, Pflichtenhefte etc.

Informationssystem-ProjektGliederungsschema für ein Projekthandbuch

UKPA 33

• Phasenmodell und Problemlösungszyklus Hier werden alle Tätigkeiten und Ergebnisse, die in einer Phase oder in einem Phasenzyklus durchgefiihrt respektive erstellt werden können, aufgeführt.

• Qualitätssicherungssystem In diesem Modul sind die Vorgaben bezüglich des gewünschten Qualitätsstandards aufgeführt.

• Checklisten In diesem Modul werden Checklisten definiert, die bei einem Review oder Audit von Ergebnissen zur Anwendung gelangen.

• Methoden/Techniken Hier werden die Methoden/Techniken beschrieben, die in einem Projekt zur Anwendung gelangen sollen.

• Instrumente/Tools Abgestimmt auf die Methoden erfolgen hier Beschreibungen über die einzusetzenden Tools.

Informationssystem-ProjektGliederungsschema für ein Projekthandbuch

UKPA 34

Informationssystem-ProjektGliederungsschema für ein Projekthandbuch

• Musterergebnisse Aufgrund von Aktivitäten und dem Ergebnismodell aus dem Modul "Phasenmodell" werden hier Musterergebnisse als Richtgrössen aufgeführt.

• Organisationsentwicklungskonzept Insbesondere bei Informatikprojekten ist es wichtig, daß das Organisationsentwicklungskonzept mit berücksichtigt wird. Das heißt, daß neben den funktionalen auch die sozio-psychologischen Veränderungen zum richtigen Zeitpunkt vorgenommen werden sollten.

• Konfigurationsmanagement Um sicherzustellen, daß ein Produkt bezüglich seiner funktionellen wie auch seiner äußeren Merkmale eindeutig identifizierbar ist, wird das Konfigurationsmanagement im PHB ausführlich beschrieben. Innerhalb des Konfigurationsmanagements muß auch das Change-/Änderungsmanagement beschrieben werden.

UKPA 35

Informationssystem-ProjektProjektabwicklung

Gliederung des Projektmanagements:

(Jenny, Abb. 1.40, S. 62)

UKPA 36

Vorgehensmodelle, Lebenszyklus-Modelle

Informationssystem-ProjektProjektabwicklung

Projektdurchführung:

Projektphasen Problemlösungszyklus

Projektdurchführungstechniken, z.B.:Requirements Engineering, UML, Risikoanalyse, Entscheidungsbaum, ...

Vorgehensmodelle, Lebenszyklus-Modelle

UKPA 37

IS-ProjektVorgehensmodelle, SW-Lebenszyklus

• verschiedene Vorgehensmodelle zur Entwicklung/Wartung von Software

• SW-Lebenszyklus: beschreibt die Phasen, die ein SW-Projekt “durchlebt”;

• jede Phase ist mit spezifischen Aktivitäten sowie der Erstellung/Ergänzung vordefinierter Dokumente verbunden;

• die Vorphasen: Zielanalyse und Planung sind nicht in allen Modellen berücksichtigt

UKPA 38

IS-ProjektVorgehensmodelle, SW-Lebenszyklus

* Überblick über Lebenszyklus-Modelle:

• reines Wasserfallmodell und Wasserfallmodell mit Rückkopplung/Validierung

• Wasserfallmodell mit “Rapid Prototyping” in Analysephase

• evolutionäres/inkrementelles Vorgehensmodell

• exploratory Programming

• operationales Modell mit formalen Transformationen:formale Anforderungsspezifikation wird schrittweise durch automatisations-unterstützte Transformationen in ein exkutierbares Programm übergeführt

• Spiralenmodell

UKPA 39

IS-Projektdas “Wasserfall-Modell”

• Wasserfallmodell [Boehm, 1981]mit Rückkopplung

UKPA 40

IS-Projektdas “Wasserfall-Modell”

* Charakteristika des Wasserfallmodells:• Phasen werden strikt sequentiell abgearbeitet und

abgeschlossen; Ergebisse einer späteren Phase fleßen nur sehr beschränkt in die Überarbeitung einer früheren Phase ein; konstruktivistisches Vorgehen im Gesamtsystem

• Aufbau auf validierten Dokumenten als Zwischenergebnisse• starres Modell, Abweichungen vom ursprünglichen Plan

nicht vorgesehen; unterstützt jedoch kompakte, zielstrebige Projektentwicklung; zeiteffizient, jedoch hoch riskant bei neuartigen Anwendungen

• Anwendung: bei gut bekannten Vorhaben mit wenig Neuigkeitsgrad

UKPA 41

IS-Projekt - das “Wasserfall-Modell” mit Rapid Prototyping

• Modell zur Erweiterung des Wasserfallmodells um die Erstellung eines Prototyps in der Analysephase:

• Prototyp dient lediglich der Klärung der Anforderungen, er fließt nicht in das endgültige System ein; Nachteil: Kosten;

• Vorteil: fundiertere Anforderungsspezifikation möglich, verkleinert das Risiko, ein unbrauchbares System zu entwickeln

(Sommerville Abb. 6.2,S. 107)

UKPA 42

IS-Projekt -Exploratory Programming

• Vorgehen: Entwicklung eines Prototyps aus der (groben) Anforderungsspezifikation; schrittweise Verfeinerung/Modifikation dieses Prototyp-Systems bis das gewünschte Verhalten erzielt wird

• Vorteil: System weist gewünschte Funktionalität auf

• Nachteile: durch die zahlreichen Änderungen bei der Entwicklung, hat das System keine stabile Struktur; System ist nicht oder nur sehr schwer wartbar

• Anwendung: bei AI-Anwendungen, z.B. bei Expertensystemen, für die vhll-Entwicklungsumgebungen existieren und das Funktionieren des Systems vorrangig ist.

UKPA 43

IS-Projekt - das evolutionäre/inkrementelle Vorgehensmodell

• Ziel: Vereinigung der Vorteile des explorativen Programmierens mit jenen des disziplinieten Verfolgens des Wasserfallmodells

• Vorgehen: frühes Festlegen der Systemarchitektur als Rahmen; Zerlegung des Systems in Teilsysteme, die inkrementell entwickelt werden; jedes Teilsystem wird entsprechend des Wasserfallmodells entwickelt, so daß entsprechende Dokumente erstellt und validiert werden;Teilsysteme werden inkrementell ausgeliefert;

UKPA 44

IS-Projekt - das evolutionäre/inkrementelle Vorgehensmodell

das Feedback der Benutzer zu früheren Teilsystemen kann bei der Entwicklung der weiteren Teilsysteme berücksichtigt werden

• Vorteile:- Pläne und Dokumentation werden für jedes Teilsystem erzeugt: erleichtert das Management des Projektes;- übliche Software-Prozeß-Standards können eingehalten werden: erleichtert die Wartbarkeit, Qualitätssicherung;- Teilergebnisse liegen früh vor: das Risiko einer Gesamt- fehlentwicklung wird minimiert ;- Auftraggeber haben wichtige Teilsysteme früh verfügbar; die frühe praktische Erfahrung wirkt sich positiv auf die weiteren Planungsschritte aus;

UKPA 45

IS-Projekt - das evolutionäre/inkrementelle Vorgehensmodell

- kleine Teilprojekte sind für Auftraggeber, Entwickler und Anwender handhabbarer und führen zu schnellem Feedback bzw. Korrekturmöglichkeiten;- Einsparung beim Auftraggeber durch frühe Einführung;

- Auftraggeber haben wichtige Teilsysteme früh verfügbar; die frühe praktische Erfahrung wirkt sich positiv auf die weiteren Planungsschritte aus;

• Nachteile:- führt gelegentlich zu Problemen bei Verträgen;- Zerlegung in abgegrenzte Teilsysteme nicht bei jeder Aufgabenstellung sinnvoll durchführbar.

UKPA 46

IS-Projekt - das evolutionäre/inkrementelle Vorgehensmodell

• Graph zum Vorgehen im Rahmen des evolutionären/inkrementellen Modells:

(Sommerville, Abb. 6.3, S. 109)

UKPA 47

IS-Projektdas Spiralenmodell

[Boehm, 1986]

• mächtigste Erweiterung des Wasserfallmodells:basiert auf der Integration verschiedener Ansätze wie z. B. Prototyping, evolutionäre Etwicklung, Einbeziehung von Validierungsschritten

• beinhaltet auch Software-Management Aspekte wie Phasenplanung, Risikoanalyse, Wirtschaftlichkeitserwägungen, etc.

• grundlegende Ideen:- Phasen werden zyklisch aneinandergereiht; - in jeder Phase werden die gleichen Schritte verfolgt:* Bestimmung von Zielen und Alternativen; * Evaluierung; * Durchführung u. Validierung; * Planung der folgenden Phase.

UKPA 48

IS-Projektdas Spiralenmodell

Anmerkungen zur Graphik:

• Beginn: im Koordinatenursprung

• die radiale Dimension repräsentiert die kummulativen Kosten aller vorangehenden Schritte;

• der Winkel repräsentiert den Fortschritt, der innerhalb jedes Zyklus der Spirale erzielt wurde;

• in jedem Zyklus werden die gleichen Schritte durchlaufen: für jedes Subsystem sowie für jede Entwicklungsphase;

• Beginn: Planungsphase;

• Ende: Kodierung/Inbetriebnahme

UKPA 49

IS-Projektdas Spiralenmodell

* Beispiel zu einem typischen Zyklus der Spirale:• Beginn: Identifikation der Ziele der Phase des (Teil)produktes,

welches im Entwicklungsprozeß steht• Identifikation der alternativen Mittel zur Realisierung obiger

Ziele (z.B. Design A, Design B, reuse, Ankauf)• Identifikation der Randbedingungen auf die Anwendung

obiger Alternativen (z.B. Kosten, Termine, Personal)• Evaluierung der Alternativen hinsichtlich Unsicherheiten und

somit Risiken der Entwicklung; Formulierung einer kosteneffektiven Strategie zur Minimierung der Risiken, z.B. Benutzerbefragung, Prototyping, Simulation,

UKPA 50

IS-Projektdas Spiralenmodell

• Feststellung des Restrisikos: falls gering, dann - Beschreiten der nächsten Phase des Wasserfallmodells, ggf. mit Einbeziehung der inkrementellen Entwicklung- falls groß, dann weiteres Prototyping; Fortsetzung der Risiko-Resolution;

• Review und Validierung des Zyklus, inklusive des groben Plans für den nächsten Zyklus;

• Detailplan für den folgenden Zyklus: dieser kann z.B. die Partitionierung des Produktes in inkremenelle Teilprodukte für ein evolutionäres Vorgehen enthalten; Teilprodukte können für die Entwicklung durch andere Organisationen bestimmt werden.

UKPA 51

IS-Projekt - Umsysteme der Projektabwicklung

• andere Projekte;Beziehungen/Abhängigkeiten zwischen Projekten müssenklar geregelt werden

• Unternehmensführung und Auftraggeber;liefern Mittel/Unterstützung für das Projekt

• Beziehungen zum bearbeiteten System;wichtigstes Umsystem, das selbst verändert wird -diese Veränderungen sollten (dynamisch) berücksichtigt werden!intensive Zusammenarbeit zwischen Projektleiter und Leiter des zu verändernden Systems sind für Erfolg erforderlich.

UKPA 52

IS-Projekt - EinflußgrößenRahmenbedingungen

• Entwicklungsbezogene Rahmenbedingungen:Häufigkeit von Änderungen auf der EntwicklungsbasisNutzung der Entwicklungsmethoden und ToolsBearbeitungszyklusUnterstützung durch Test- und PrüfverfahrenQualitätssicherung

• Projektbezogene Rahmenbedingungen:EntwicklungszeitEntscheidungskraft der LeitungArbeitsaufteilung, ProjektstrukturQualität des ProjektmanagementsEinsatz von Projekt management-Techniken

UKPA 53

IS-Projekt - EinflussgrößenRahmenbedingungen

• Firmenbezogene Rahmenbedingungen:Leitbild/UnternehmensphilosophieStandards und RichtlinienEntwicklungsstand des ProduktesWirtschaftlichkeitsvorgaben

• Personal- und Anwendungsbezogene Rahmenbedingungen:Betroffene Gruppen, Mentalität, AusbildungsgradVerfügbarkeit des Personals, Leistungswille

• Produktbezogene Rahmenbedingungen:Größe des Entwicklungsbereichs (Konzern, Abteilung…)Modularität und KomplexitätWiederholungshäufigkeit des Prozesses

UKPA 54

IS-Projekt - EinflußgrößenRestriktionen

• Umweltbezogene Restriktionen:TechnologieComputerrestriktionen (z.B. Prozessorart)Verordnungen (ein Hersteller schreibt etwas vor)Internationale Übermittlungsprotokolle

• Firmenbezogene Restriktionen: werden bei der Projektinitialisierung definiert:VorgehensvorgabenVorgaben bzgl. der elaubten KonsequenzenTermine, Kosten, eingesetztes PersonalVeränderungserlaubnisBeispiel: das Projekt muß mit dem Tool X entwickelt werden

UKPA 55

IS-Projekt - EinflußgrößenRestriktionen

• Risikobezogene RestriktionenManagementrisikoTechnisches RisikoSoziales Risiko

• Systembezogene Restriktionen: vor- oder nachgelagerte Stellen/Prozesse geben Größen vor, die eingehalten werden müssen;

Beispiel:Das System muß einem vorgegebenen Standard entsprechenDie Durchlaufgeschwindigkeit eines Geschäftsprozesses darf eine Maximaldauer nicht überschreitenDer Geschäftsprozeß darf maximal ‘n’ Arbeitsstellen durchlaufen, ...

UKPA 56

IS-Projekt - Erfolgsfaktoren

• Definition: Ein Projekterfolg liegt vor, wenn die vom Auftraggeber gewünschten Resultate mit den vorgesehenen Mitteln innerhalb der vorgesehenen Zeit in der geforderten Qualität vorliegen.

• Projekterfolg ist primär abhängig von:System der Projektabwicklung (“Development World”)System, das entwickelt wird (“System World”)

• Definition: Unter Erfolgsfaktoren in einem Projekt versteht man die Voraussetzungen, die wesentlich zur Erreichung der Merkmale erfolgreicher Projekte beitragen.

UKPA 57

IS-Projekt - Erfolgsfaktoren Die fünf Erfolgsfaktoren-Gruppen:

(Jenny, Abb.1.57,S. 85)

UKPA 58

IS-Projekt - Erfolgsfaktoren

• PM-Funktionen:Zielsetzungen genau definieren und Projektmitarbeitern mitteilen;ausreichender, angepaßter Detaillierungsgrad der Planung;geordnetes Berichtswesen, Dokumentation, Kontrollen,…

• Projekteam-Umwelt:umfaßt: Auftraggeber, Sponsoren, Benutzerstetiges Involvieren des Auftraggebers;Benutzer ins Projekt integrieren;rechtzeitige Information und Koordination aller Betroffenen;...

UKPA 59

IS-Projekt - Erfolgsfaktoren• Projektabwicklungs-Instrumente:

umfassen: eingesetzte Methoden, Techniken, Tools;Instrumente sollen situationsgerecht eingesetzt werden;Gliederung von Projekten in Phasen entsprechend Gesamtkonzept;eingesetzte Hilfsmittel müssen einwandfrei funktionieren u.Benutzer müssen mit ihnen professionell umgehen können; …

• Personen:qualifiziertes Team erforderlich; Teamfähigkeit, Erfahrung,…

• Organisation:Aufgrund der Einmaligkeit jedes Projektes sollte die Organisation unbürokratisch und flexibel sein.

UKPA 60

IS-Projekt - Risiken

• Definition: Projektrisiko: Höhe des Schadens, den ein Unternehmen erleidet, wenn die Projektziele nicht erreicht werden.

• Risikoentschärfung:permanenter Gebrauch von Erfolgsfaktoren;wiederholte Risikoanalyse, z.B. gemäß Spiralenmodell;Einsatz entsprechender Unterstützungsverfahren

• Risiken während des Projektablaufs können aufgedeckt werden durch:Projektplanung überprüfen, Durchführen von Reviews,Einbringen von Erfahrungen aus früheren Projekten, ...