Entwicklung eines Vorgehensmodells für SAP BW-Projekte

Bleck, Michael

Entwicklung eines Vorgehensmodells für SAP BW-Projekte

Zusammenfassung

Inhaltsangabe:Einleitung:
Globalisierung und rasche Marktveränderungen zwingen Unternehmen, Qualität, Quantität und Verfügbarkeit ihrer Information zu erhöhen. Um heute wirtschaftliche Entscheidungen zu fällen, muss ständig ein aktuelles Bild vom Unternehmen verfügbar sein. Dies ist die wesentliche Aufgabe eines Business Information Warehouses.
In den letzten Jahren sind Business Information Warehouse Systeme zu einem essentiellen Bestandteil moderner Entscheidungsunterstützungssysteme geworden. Laut einer Analyse der Meta Group wurden im Jahr 2001 14.5 Milliarden US-Dollar für Data Warehouse Projekte ausgegeben und für das Jahr 2002 wurde ein Umsatz von 17 Milliarden US-Dollar prognostiziert. Diese Zahlen verdeutlichen die Vorteile durch die Verwendung eines Data Warehouse als unternehmerische Informationsplattform.
Dem Data Warehouse Trend folgte auch die Firma X bereits Ende der 90er Jahre. Erst im Jahre 2003, mit der Einführung von SAP BW als Data Warehouse Lösung, konnte der steigende Bedarf an Unternehmensinformationen gedeckt werden. Parallel dazu nahm der Bedarf an Reporting1 und somit die Anzahl von SAP BW Projekte rapide zu. Bei der Entwicklung und Durchführung von SAP BW Projekte wurde bisher ohne eine festgelegte Projektvorgehensweise oder sogar ein Projektcontrolling gearbeitet. Somit fehlt ein standardisiertes Vorgehensmodell, welches den Anforderungen eines SAP BW Projektes gerecht wird und alle Projektphasen unterstützt.
Die Folge waren erhöhte Projektkosten und SAP BW Projekte die schon in der Implementierungsphase oder im Go Live2 gescheitert sind. Gründe dafür sind hauptsächlich die Auswahl ungeeigneter Methoden zur Projektabwicklung, schwerwiegende Fehler im Projektmanagement und unzureichende Erfahrungen in der Verwendung von Werkzeugen. Mit der Entwicklung und Nutzung eines Vorgehensmodells könnte die Erfolgswahrscheinlichkeit der SAP BW Projekte erhöht werden. Gleichzeitig unterstützt jedes erfolgreiches SAP BW Projekt, die Entscheidung für die Einführung von SAP BW als unternehmensweites Data Warehouse bei der Firma X .
Diese Diplomarbeit wurde im Rahmen des SAP BW Projektes Ablösung des Vertriebsinformationssystems (VIS) verfasst. Dabei werden die VIS Kennzahlen Auftragseingang, Auftragsbestand und Umsatz mithilfe der Data Warehouse Lösung SAP BW als Reporting Application3 abgebildet und somit das bestehende Vertriebsinformationssystem bei der Firma X abzulösen.
Primäres Ziel der Arbeit ist deshalb die Erstellung […]

Leseprobe

Inhaltsverzeichnis

ID 8832

Bleck, Michael: Entwicklung eines Vorgehensmodells für SAP BW Projekte

Hamburg: Diplomica GmbH, 2005

Zugl.: Fachhochschule Stralsund, Diplomarbeit, 2005

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,

insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von

Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der

Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,

bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung

dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen

der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik

Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich

vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des

Urheberrechtes.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in

diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,

dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei

zu betrachten wären und daher von jedermann benutzt werden dürften.

Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können

Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die

Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine

Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.

Diplomica GmbH

http://www.diplom.de, Hamburg 2005

Printed in Germany

Michael Bleck

Inhaltsverzeichnis

1 Einleitung ...6

1.1 Ausgangssituation ...6

1.2 Ziele

der

Diplomarbeit...8

1.3 Methodischer

Aufbau...8

1.4 Gliederung...11

1.5 Thematische

Abgrenzung ...11

2 Grundlagen ...12

2.1 Business

Intelligence ...12

2.2

Enterprise Resource Planing System ...13

2.3 Data

Warehouse

System ...14

2.4

SAP Business Information Warehouse...16

2.5

Extraktion, Transformation und Laden von Daten ...17

2.6 Data

Mining ...18

2.7

Online Analytical Proccessing (OLAP)...18

2.8 Grundlagen

des

Projektmanagements...19

2.8.1 Projekt ...19

2.8.2 Definition von Projektmanagement ...19

2.8.3 IT

Projektmanagement...20

2.9 Vorgehensmodelle ...21

2.9.1 Klassische

Softwareentwicklungsmodelle...23

2.9.2 Iterative,

inkrementelle

Vorgehensmodelle ...29

2.10 IT

Infrastructure

Library

(ITIL)...36

2.10.1 ITIL Prozesse bei der Firma X IT...38

2.10.2 Diskussion der ITIL ...39

Michael Bleck

iii

2.11 Etablierte

Bewertungsmodelle ...39

2.11.1 ISO 9000 ...40

2.11.2 Diskussion der ISO 9000 ...41

2.11.3 Capability Maturity Models...41

2.11.4 Diskussion des Capability Maturity Model ...43

2.11.5 Diskussion der Bewertungsmethoden...43

3 Analyse von SAP BW Projekten ...45

3.1

Ursachen für das Scheitern von SAP BW Projekten ...45

3.2

Architektur des SAP BW Data Warehouses...47

3.3

Analyse von SAP BW Projekten ...51

3.3.1 Ziele und Aufgaben eines SAP BW Projektes...52

3.3.2 Projektphasen von SAP BW Projekten...53

3.3.3 SAP

Projektorganisation ...58

3.3.4 Kostenplanung ...61

3.3.5 Finanzplanung...62

3.3.6 Nutzenbetrachtung ...62

3.4

Erfolgsfaktoren für ein SAP BW Projekt...63

4 Projekt ,,Ablösung des Vertriebsinformationssystems"...65

4.1

Was ist ein Vertriebinformationssystem? ...65

4.2 Projektinformationen ...66

4.2.1 Gründe für das Projekt ...66

4.2.2 Projektziel ...67

4.2.3 Projektteam ...67

4.3 Projektverlauf...68

4.3.1 Projektinitialisierung...68

4.3.2 Analyse ...69

Michael Bleck

4.3.3 Spezifikation ...70

4.3.4 Realisierung

und

Test ...70

4.3.5 Einführung ...71

4.4 Probleme

Projektverlauf ...72

4.5

Anforderungen aus dem VIS Projekt...72

4.5.1 Anforderungen der SAP BW Entwickler...73

4.5.2 Anforderungen

der

Fachabteilung ...75

4.6

Anforderungskatalog für ein SAP BW Vorgehensmodell...77

5 Bewertung der ITIL - Prozesse im Hinblick auf SAP BW Projekte ...80

5.1

Darstellung der ITIL Prozesse ...80

5.1.1 Der ITIL Projektmanagement- und Releasemanagement Prozess...81

5.1.2 Diskussion der Firma X ITIL Prozesse...86

5.2

Bewertung der ITIL Prozesse anhand des SAP BW Anforderungskatalog...87

5.3 Zusammenfassung...88

6 Entwicklung eines SAP BW Vorgehensmodell...90

6.1 Merkmale

eines

Vorgehensmodell ...90

6.2

Prinzipien bei einem SAP BW Vorgehensmodell ...91

6.3

Überlegungen für ein SAP BW Vorgehensmodell ...93

6.4 SAP

Vorgehensmodell ...94

6.4.1 Projektvorbereitung...95

6.4.2 Spezifikation ...96

6.4.3 Realisierung ...98

6.4.4 Einführung ...99

6.4.5 Nachbereitung ...100

6.4.6 Diskussion...100

6.5

Werkzeuge und Methoden des SAP BW Vorgehensmodell...100

Michael Bleck

6.6 Zusammenfassung...111

7 Zusammenfassung und Ausblick ...113

Glossar...115

Abbildungsverzeichnis ...118

Tabellenverzeichnis...120

Abkürzungsverzeichnis...121

Literaturverzeichnis...123

Internetquellen ...128

Anhang ...129

Einleitung

Michael Bleck

Einleitung

1.1 Ausgangssituation

Globalisierung und rasche Marktveränderungen zwingen Unternehmen, Qualität, Quantität und Verfüg-

barkeit ihrer Information zu erhöhen. Um heute wirtschaftliche Entscheidungen zu fällen, muss ständig ein

aktuelles Bild vom Unternehmen verfügbar sein. Dies ist die wesentliche Aufgabe eines Business Infor-

mation Warehouses.

In den letzten Jahren sind Business Information Warehouse Systeme zu einem essentiellen Bestandteil

moderner Entscheidungsunterstützungssysteme geworden. Laut einer Analyse der Meta Group wurden im

Jahr 2001 14.5 Milliarden US-Dollar für Data Warehouse Projekte ausgegeben und für das Jahr 2002

wurde ein Umsatz von 17 Milliarden US-Dollar prognostiziert (vgl. [Meta03]). Diese Zahlen verdeutli-

chen die Vorteile durch die Verwendung eines Data Warehouse als unternehmerische Informationsplatt-

form.

Dem Data Warehouse Trend folgte auch die Firma X bereits Ende der 90er Jahre. Erst im Jahre 2003, mit

der Einführung von SAP BW als Data Warehouse Lösung, konnte der steigende Bedarf an Unternehmens-

informationen gedeckt werden. Parallel dazu nahm der Bedarf an Reporting

und somit die Anzahl von

SAP BW Projekte rapide zu. Bei der Entwicklung und Durchführung von SAP BW Projekte wurde bisher

ohne eine festgelegte Projektvorgehensweise oder sogar ein Projektcontrolling gearbeitet. Somit fehlt ein

standardisiertes Vorgehensmodell, welches den Anforderungen eines SAP BW Projektes gerecht wird und

alle Projektphasen unterstützt.

Die Folge waren erhöhte Projektkosten und SAP BW Projekte die schon in der Implementierungsphase

oder im Go Live

gescheitert sind. Gründe dafür sind hauptsächlich die Auswahl ungeeigneter Methoden

zur Projektabwicklung, schwerwiegende Fehler im Projektmanagement und unzureichende Erfahrungen in

der Verwendung von Werkzeugen. Mit der Entwicklung und Nutzung eines Vorgehensmodells könnte die

Erfolgswahrscheinlichkeit der SAP BW Projekte erhöht werden. Gleichzeitig unterstützt jedes erfolgrei-

Bereitstellung von Unternehmenskennzahlen

Produktivsetzung der Anwendung

Einleitung

Michael Bleck

ches SAP BW Projekt, die Entscheidung für die Einführung von SAP BW als unternehmensweites Data

Warehouse bei der Firma X .

Einleitung

Michael Bleck

1.2 Ziele der Diplomarbeit

Diese Diplomarbeit wurde im Rahmen des SAP BW Projektes ,,Ablösung des Vertriebsinformation-

systems (VIS)" verfasst. Dabei werden die VIS Kennzahlen Auftragseingang, Auftragsbestand und Um-

satz mithilfe der Data Warehouse Lösung SAP BW als Reporting Application

abgebildet und somit das

bestehende Vertriebsinformationssystem bei der Firma X abzulösen.

Primäres Ziel der Arbeit ist deshalb die Erstellung eines SAP BW Projektvorgehensmodells mit dessen

Hilfe zukünftige SAP BW Projekte bei der Firma X effizienter durchgeführt werden können. Durch die

Analyse von SAP BW Projekten werden Anforderungen formuliert und in einem Vorgehensmodell verar-

beitet.

Sekundäres Ziel ist die Analyse der bestehenden Vorgehensweise - ITIL

Prozesse - für SAP BW Projekte

bei der Firma X . Im Zusammenhang mit der Analyse muss geklärt werden, ob sich die bestehenden ITIL

Prozesse für die Verwendung bei SAP BW Projekten eignen, oder ob andere Arten verfügbarer Software-

entwicklungsprozesse für die SAP BW Anwendungsentwicklung praktikabel einsetzbar sind. Ein SAP

BW Vorgehensmodell soll die Entwicklungsdauer, die Aufwände und das Kosten-Nutzenverhältnis von

zukünftigen SAP BW Projekten verbessern. Von entscheidender Bedeutung für ein erfolgreiches SAP BW

Projektvorgehensmodell ist dabei die Akzeptanz und Funktionalität der bereitgestellten Werkzeuge und

Methoden.

Um die beiden Ziele der Diplomarbeit zu erreichen, wird folgende methodischer Vorgehensweise gewählt.

1.3 Methodischer Aufbau

Die Diplomarbeit gliedert sich in 7 Kapitel, deren Inhalte und gedankliche Verbindungen in der folgenden

Übersicht schematisch dargestellt sind.

Zur Bearbeitung der Aufgabe wird die in Abbildung 1-1 dargestellte Vorgehensweise gewählt. Die Grafik

zeigt die jeweiligen Kapitel, in denen die Schritte (weiße Kästen) reflektiert bzw. die Ergebnisse (graue

Kästen) festgehalten werden.

Anwendung aus dem unternehmerischen Berichtswesen

Information Technology Infrastructure Library

Einleitung

Michael Bleck

Abbildung 1-1: Methodischer Aufbau der Diplomarbeit

Quelle: eigene Darstellung

Einleitung

Michael Bleck

Zur Bearbeitung des Diplomthemas ist die Beantwortung folgender Teilfragestellungen notwendig:

· Welche Vorgehensmodelle existieren?

· Welche eignen sich für SAP BW Projekte ?

· Mit welchen Bewertungsmethoden lassen sich Vorgehensmodelle untersuchen?

· Wodurch sind SAP BW Projekte gekennzeichnet ?

· Welche Anforderungen werden aktuell an ein SAP BW Vorgehensmodell gestellt?

· Inwiefern werden die bestehenden Vorgehensmodelle bei der Firma X (ITIL Prozesse) den An-

forderungen gerecht?

· Welche Werkzeuge und Methoden können die SAP BW Projektarbeit unterstützen ?

Im Folgenden wird erläutert, wie zur Beantwortung der genannten Fragen vorgegangen wurde und wie die

Ergebnisse der Untersuchungen dargestellt werden.

Die Entwicklung eines SAP BW Vorgehensmodells ist die Problemstellung bzw. der Ausgangspunkt der

Diplomarbeit. Um eine Problemlösung zu finden wird folgende Methodik angewandt.

Im Schritt 1 werden zunächst notwendige theoretische Grundkenntnisse vermittelt. Diese verbessern das

Verständnis seitens der Leser.

Die Projektvorgehensmodelle, welche für SAP BW Projekte in Frage kommen, werden im Schritt 2 vor-

gestellt. Dazu gehören die klassischen und iterativen, inkrementellen Projektvorgehensmodelle. An-

schliessend werden diese aus der Sicht von SAP BW Projekten bewertet. Zusätzlich wird nach einer wis-

sentschaftlichen Bewertungsmethodik recherchiert, mit der sich Vorgehensmodelle bewerten lassen.

Im Schritt 3 werden SAP BW Projekte analysiert. Die Ergebnisse der Analyse fliessen ebenso in den SAP

BW Anforderungskatalog (Schritt 5) mit ein, wie die Dokumentation des SAP BW Projektes ,,Ablösung

des VIS" im Schritt 4.

Der entwickelte SAP BW Anforderungskatalog ist ein Bewertungsinstrument, um die Eignung von Vor-

gehensmodellen zu untersuchen. Mit dessen Hilfe erfolgt im folgenden Schritt 6 die Bewertung der ITIL

Prozesse.

Aus den in Schritt 2, 3 und 4 gewonnenen Erkenntnissen, Zielen und Verfahrensweisen wird ein eigenes

optimiertes SAP BW Projektvorgehensmodell im Schritt 7 entwickelt. Zusätzlich zum Vorgehensmodell

werden Werkzeuge und Methoden bereitgestellt, mit deren Hilfe dann das eigentliche Vertriebsinformati-

onssystem mittels SAP BW umgesetzt und dokumentiert wird. Abschliessend werden im Schritt 7 die

gewonnenen Ergebnisse dargestellt.

Einleitung

Michael Bleck

1.4 Gliederung

Im Kapitel 2 werden die grundlegenden Technologien und Methoden vorgestellt, die als Ausgangspunkt

für die gesamte Bearbeitung zu sehen sind.

Kapitel 3 beschäftigt sich mit der Analyse und Beschreibung von SAP BW Projekten. Konkreter werden

die Anforderungen durch die Betrachtung des SAP BW Projektes ,,Ablösung des Vertriebinformation-

systemes", welches im Kapitel 4 näher beschrieben wird. Die gewonnenen Erkenntnisse beider Kapitel

liefern wichtige Anforderungen für einen SAP BW Anforderungskatalog, der als Bewertungsinstrument

zur Verfügung steht.

In Kapitel 5 werden die bei Firma X relevanten Vorgehensmodelle vorgestellt und anhand des SAP BW

Anforderungskataloges aus Kapitel 4 gemessen.

Ausgehend von diesem Ergebnis wird im Kapitel 6 ein eigenes SAP BW Vorgehensmodell entwickelt.

Im letzten Kapitel der Arbeit werden die Ergebnisse der Problemlösung zusammenfassend dargestellt und

auf die gewonnenen Erkenntnisse eingegangen.

1.5 Thematische Abgrenzung

Diese Diplomarbeit wird sich nur am Rande mit der SAP BW Technologie beschäftigen. Der Schwer-

punkt liegt auf dem SAP BW Projektmanagement. Dazu wird der Verlauf und die Eigenschaften von SAP

BW Projekten analysiert. Mit den daraus gewonnenen Erkenntnissen ist es möglich ein eigenes, optimier-

tes SAP BW Vorgehensmodell zu entwickeln.

Grundlagen

Michael Bleck

Grundlagen

In diesem Kapitel werden Grundlagen dargestellt, um die relevanten Technologien und Konzepte, die zum

Verständnis der Diplomarbeit notwendig sind, zu definieren. Angefangen mit den Begriffen aus dem Be-

reich Business Intelligence und dem Projektmanagement. Neben den klassischen und iterativen Vorge-

hensmodellen werden auch die bei der Firma X eingeführten IT Infrastructure Library Prozesse (ITIL

Prozesse) vorgestellt. Zusätzlich jedoch soll geklärt werden, was unter einem ,,IT - Projekt" und dem da-

zugehörigen IT Projektmanagement genau zu verstehen ist.

Um Missverständnisse bei häufig verwandten Begriffen zu vermeiden, sollen die wichtigsten hier definiert

werden. Ein vollständiges Glossar und ein Abkürzungsverzeichnis finden Sie im Anhang.

2.1 Business Intelligence

Business Intelligence gewinnt in der heutigen Wirtschaftswelt zunehmend an Bedeutung. Besonders für

die Unternehmensplanung und steuerung ist die Analyse von entscheidungsrelevanten Daten und Infor-

mationen nahezu unverzichtbar geworden. Unternehmen aller Branchen und Größenklassen sind durch

hohen Wettbewerbsdruck dazu gezwungen Geschäftsdaten in geeigneter Art und Weise aufzubereiten und

den Entscheidungsträgern des Unternehmens zu präsentieren. Laut einer aktuellen Studie vom 10/2004

setzen 77% der deutschen Unternehmen BI

-Lösungen ein. Als die drei wesentlichen Ziele bei dem Ein-

satz von BI-Applikationen, wurden vor allem eine bessere Informationsversorgung, Entscheidungsunter-

stützung und Unternehmenssteuerung genannt (vgl. [BISt04]).

Der Grundgedanke von Business Intelligence ist dabei immer ,,die aktuelle, zeit- und ortsunabhängige

Verfügbarkeit aller relevanten Unternehmensdaten" (vgl. [Projec04]). So gehören zu Business Intelligence

traditionelle Methoden und Techniken wie Data Warehouse, Data Mining, Online Analytical Processing

(OLAP). Diese Begriffe werden in den folgenden Abschnitten erklärt.

Im Wesentlichen umfasst Business Intelligence also den Softwareeinsatz zur Verwaltung und Auswertung

von Unternehmensdaten (vgl. [Projec04]). Im Projektmanagement ist die aktuelle Verfügbarkeit der Daten

schon immer Voraussetzung für Überwachung und Steuerung von Projekten gewesen. Dieser Anspruch

Business Intelligence

Grundlagen

Michael Bleck

wird mit dem Begriff Business Intelligence auch auf die Datenhaltung des Unternehmens übertragen (vgl.

[Schuet01], S.148).

Business Intelligence bezieht sich immer auf Unternehmensdaten aus dem sogenannten ,,Operativen Ta-

gesgeschäft" (vgl. [Egger04]). Diese entstehen täglich millionfach durch die Verwendung von Enterprise

Ressource Planing Systemen in einem Unternehmen.

2.2 Enterprise Resource Planing System

Um Information und Daten aus den Geschäftsprozessen des Unternehmens zu gewinnen, braucht man ein

System, welches das Operative Tagesgeschäft in allen Unternehmensbereichen abdeckt. Dieses System

wird im allgemeinen als Enterprise Ressource System (ERP) bezeichnet, mit dessen Hilfe der betriebs-

wirtschaftliche Ablauf, sei es im Bereich Produktion, Vertrieb, Logistik, Finanzen, Personal usw., gesteu-

ert und ausgewertet werden kann.

Durch die einheitliche Verknüpfung dieser einzelnen Bereiche ist eine ERP-Lösung ein sinnvolles Cont-

rolling- und Steuerungsinstrument zur Unterstützung von Unternehmensentscheidungen. Somit bedeutet

ERP die Einrichtung umfassender elektronischer Informationssysteme, die es den verschiedenen, in der

Vergangenheit weitgehend isolierten Teilen einer Organisation erlauben, auf einen gemeinsamen Informa-

tionspool zuzugreifen und miteinander zu kommunizieren. Die dazu entwickelte Software dient als eine

Art ,,zentrales Nervensystem für das Unternehmen" (vgl. [Ephor04]). Alle Informationen über den Zu-

stand und die Aktivitäten der verschiedenen Teile der Organisation werden gesammelt und an andere Stel-

len, die diese Informationen benötigen übermittelt. Der Benutzer aktualisiert die Informationen in Echtzeit

und diese sind jederzeit allen zugänglich, die an das System angeschlossen sind. ERP-Systeme verknüpfen

insbesondere Informationen über Finanzen, personelle Ressourcen, Produktion und Vertrieb. Diese wer-

den in themenspezifischen Systemen abgelegt und verwaltet, dazu gehören z.B. Lagerverwaltungssyste-

me, Kundendatenbanken, Auftragsverfolgungssysteme, Kreditorenbuchhaltung und vieles andere mehr

(vgl. [Ephor04]).

Unternehmensdaten werden meist durch die Verwendung von ERP Systemen erzeugt. Wenn man diese

Daten auswerten und in Informationen auswerten, ist die Speicherung der Daten Grundvorrausetzung.

Grundlagen

Michael Bleck

2.3 Data

Warehouse

System

,,Data-Warehouse oder Data Warehousing ist mit seiner steigenden Popularität und Nutzung

zu einem sehr schwammigen Begriff geworden."

Die Technologie der Data Warehouse Systeme entstand Anfang der 90er Jahre. Für die Unternehmen

stand ab diesem Zeitpunkt im Vordergrund, Information durch Verwendung elektronischer Datensysteme

z.B. ERP SAP/3 im Operativen Geschäft der Unternehmen zu analysieren (vgl. [Mucks00], S.6 ff).

Durch Online Analytical Transaction (OLAP) wurde es möglich, Information über festgelegte Zeiträume

und aus verschieden Geschäftsbereichen auszuwerten. Dabei war das primäre Ziel Unternehmensinforma-

tionen nicht nur für die Analyse des Geschäftsprozesse allein heranzuziehen, sondern diese für Decision

Support Systeme (DSS) für Managemententscheidungen bereit zu stellen.

Ein Data Warehouse ist eine themenorientierte, integrierte, zeitbezogene und dauerhafte Sammlung von

Informationen zur Entscheidungsunterstützung des Managements. Der Aufbau erfolgt in relationalen oder

multidimensionalen Datenbanken. Nach Standort und Menge der enthaltenen Daten unterscheidet man

zentrale und verteilte Architekturen.

Die wesentlichen Attribute dabei sind:

· Granularität der Daten

· Beständigkeit

Die Daten, die einmal in das Data Warehouse integriert wurden, werden nicht mehr geändert oder

entfernt. Die Datenbasis ist also als stabil zu betrachten (vgl. [Bauer01], S. 7). Korrekturen an den

Daten sind nur dann zulässig, wenn bei der Datenübernahme Fehler aufgetreten sind oder fehler-

hafte Daten aus den Operativ-Systemen übernommen wurden. Um die Beständigkeit der im Data

Warehouse gespeicherten Daten sicherzustellen, kann nahezu nur lesend auf die Daten zugegriffen

werden (vgl. [Mucks00], S. 13).

· Nicht Volatilität und Zeitvariabilität

· Integration

Die Integration der Daten stellt die wichtigste Eigenschaft eines Data Warehouse dar (vgl. [In-

mon02], S. 31). Die Daten in einem Data Warehouse werden aus den heterogenen Operativ-

J.-H. Wieken [Wiek99]

Grundlagen

Michael Bleck

Systemen

extrahiert und sowohl inhaltlich als auch per Definition konsolidiert. Dabei werden wi-

dersprüchliche Dateninhalte (z.B. semantisch redundante, aber syntaktisch voneinander abwei-

chende Adressangaben eines Kunden) bereinigt und Definitionen von Datenelementen (z.B. unter-

schiedliche Definition von Umsatz) vereinheitlicht (vgl. [Jung00], S. 5). Die Data Warehouse-

Datenbank ist vollständig getrennt von den operativen, funktionalen Informationssystemen vgl.

[Weste00], S. 26).

· Subjektorientiertheit

Die relevanten Datenstrukturen leiten sich direkt aus dem Informationsbedarf der Entscheidungs-

träger und Fachbereiche ab, für die das Data Warehouse Daten zur Verfügung stellt (vgl. [Hol-

te01], S. 5). Deshalb sind die Daten so zu speichern, dass sie sich an den Subjekten des Unter-

nehmens, bzw. den relevanten Themenbereichen orientieren und sich nicht nach den operativen

Geschäftsprozessen richten (vgl. [Wieke99], S. 16ff). Dies begründet den Unterschied zu den üb-

lichen applikations- und prozessorientierten Konzepten der operativen Transaktionsverarbeitung,

bei denen die effiziente Abwicklung des Tagesgeschäfts im Vordergrund steht, die aber keines-

wegs dafür geeignet sind Entscheidungen zu unterstützen (vgl. [Chamo98], S. 14). Vielmehr liegt

der Fokus der Benutzer eines Data Warehouse auf inhaltlichen Themenbereichen und Dimensio-

nen, wie z.B. Kunden, Produkte, Zeit usw. und den damit zusammenhängenden betriebswirt-

schaftlichen Größen, wie z.B. Umsatz, Renditen, Deckungsbeiträge usw. (vgl. [Jung00], S. 4ff).

Bei einem Data Warehouse handelt es sich nicht um ein fertiges Produkt, vielmehr um eine Kombination

aus unterschiedlichen organisatorischen, fachlichen und Hard und Softwarekomponenten (vgl. [Eg-

ger04], S.33ff).

Nach William H. Inmon muss ein Data Warehouse im Wesentlichen folgende Eigenschaften ausweisen

(vgl. [Inmon02]):

· Subjekt-orientierte, integrierte Daten

· Originaldaten, die nicht in Hinblick auf einen bestimmten Projektzweck verändert wurden

(,,unflavored data")

· Granulare Daten, nicht aggregierte Daten

· Historisierte Daten, d.h. weder Überschreiben noch Löschen ist erlaubt

· Einen `single point of truth', durch einen Enterprise Data Warehouse Layer sind die Information

unternehmensweit redundant

Grundlagen

Michael Bleck

Genau diese Forderungen sind auch Bestandteil der Data Warehouse Lösung von SAP, welche in Form

des SAP Business Information Warehouse 2001 auf den Markt kam. Diese Lösung wird im folgenden

Kapitel und ausführlich in Kapitel 3 näher erläutert.

2.4 SAP Business Information Warehouse

SAP stellt mit dem Business Information Warehouse erstmals ein umfassendes Werkzeug für analytische

Applikationen mit allen erforderlichen Datawarehouse Komponenten zur Verfügung.

SAP BW versteht sich als umfassende Data Warehouselösung. Somit sind alle notwendigen Werkzeuge

bzw. Funktionalitäten enthalten:

· Funktionen für den ETL Prozess (vgl. [Jung00], S.44ff)

· Extraktion der Daten aus Quellsystemen

· Komponenten für die Datenablage (komplexe Bewegungs- und Stammdaten)

· Werkzeuge für Analysen und Berichte (SAP BEx, browserbasiertes WEB Reporting und MS Ex-

cel)

Um diese Kernelemente ordnen sich weitere erforderliche Komponenten an. Dies sind Werkzeuge für das

Customizing, für die Administration wie Monitoring, Scheduling, Performanceoptimierung, sowie Open-

Hub-Komponenten. Alle Elemente des SAP BW basieren auf konsistenten Metadaten, die über die Admi-

nistration den WorFirma Xench verwalten.

Bezieht man die grundlegenden Eigenschaften eines Data Warehouse nach Immon auf SAP BW ergeben

sich folgende Vorteile (vgl. [Inmon02]):

· Flexibilität, im Sinne von neuen InfoCube (Data Mart) Lösungen können inklusive Historie und

erneuter Extraktion zeitnah aufgebaut werden

· auf unvorhersehbare, einmalige Benutzeranforderungen kann schnell reagiert werden, u.U. ohne

persistente Strukturen aufzubauen.

· Zuverlässigkeit und Nachvollziehbarkeit

· Zentrale Administration

· Komplette Historie

· Konsistenz

Grundlagen

Michael Bleck

· Extraktion, Staging und Integration werden zentral verwaltet

· Daten werden nur einmal extrahiert

· Redundante Staging Prozesse werden vermieden.

Ein SAP BW Data Warehouse ist also das Gedächtnis der Unternehmung, ein dem gesamten Unterneh-

men gehörendes Speicher (engl. Repository) für Informationen. Eine genaue Analyse der SAP BW Archi-

tektur und die Merkmale von SAP BW Projekten werden im Kapitel 3 dargestellt.

Zu den SAP BW Data Warehouse Komponenten gehören Extraktion, Transformation und Lade-Tools

(ETL-Tools), ein flexibles Werkzeug für die Datenmodellierung sowie leistungsfähige Reportingstools.

2.5 Extraktion, Transformation und Laden von Daten

ETL Extraktion, Transformation und Laden - ist ein Prozess der neben Umsetzung der technischen An-

forderungen einer Extraktion, der Ablage in einer Zieldatenbank und die Umsetzung von nicht harmoni-

sierten Daten beinhaltet (vgl. [Egger04], S. 30 ff). Ganz Allgemein ist es die Selektion eines Ausschnitts

der Daten aus relevanten Quellen. Dieser Prozess fordert eine unternehmensweite, alle Systeme berück-

sichtigende Terminologie, die im ,,Transformationsprozess auf die heterogenen Quelldaten anzuwenden

ist" (vgl. [Egger04], S. 30 ff). In der Abbildung 2-1 wird der 3-stufige ETL - Prozess dargestellt (vgl.

[Jung00], S.44ff). Die Daten werden aus dem Operativen System (ERP) z.B. aus dem ERP SAP R/3 ext-

rahiert, transformiert und schließlich in das Data Warehouse SAP BW geladen.

Abbildung 2-1: ETL Prozess

Quelle: [Jung00]

Die Daten werden aus den Operativen Systemen gewonnen, in dem Data Warhouse in Informationen um-

gewandelt. Im folgenden Kapitel wird auf die Analyse dieser gewonnenen Informationen näher eingegan-

gen.

Grundlagen

Michael Bleck

2.6 Data Mining

,,Data Mining Auf der Suche nach dem Verborgenen"

Data Mining gehört zu den in letzter Zeit stark diskutierten Business Intelligence Themen. Dazu gehö-

ren Methoden und Techniken, die bislang unbekannte Zusammenhänge in Datenbeständen der Unterneh-

men aufdecken und nutzbar machen (vgl. [Mucks00]). Die folgende Definition betont diesen Sachverhalt,

,,Unter Data Mining versteht man die Extraktion implizit vorhandenem, nicht trivialem und nützlichem

Wissen aus großen dynamischen, relativ komplex strukturierten Datenbeständen. Ziel des Data Mining ist

es, Wissen in Form von Mustern zu identifizieren." Data Mining hat neben dem Ziel der Mustererken-

nung, andererseits die zuverlässige Prognose unbekannter Werte und Entwicklungen (vgl. [Mucks00]).

2.7 Online Analytical Proccessing (OLAP)

In OLAP-Systemen stellen multidimensionale Datenstrukturen die Grundlage der Modellierung dar (vgl.

[Boehn00], S. 3). Diese multidimensionalen Modelle machen sich die inhärenten Beziehungen in den

Daten zunutze, um multidimensionale Matrizen, auch Data-Cubes (Datenwürfel, Infocubes) genannt, mit

Daten zu füllen (vgl. [Elmas02], S. 904).

OLAP ist ein Werkzeug der Business Intelligence womit eine höchstmögliche Flexibilität in Bezug auf die

Realisierung von Anfragen und Analysen an den aktuellen Datenbestand ermöglicht werden soll. Um dies

in einer angemessen Zeit und mit entsprechender Sicherheit tun zu können, benötigt ein OLAP-Tool nicht

nur die Infrastruktur eines gegeben modernen Data Warehouses - zum Beispiel gehört zu dieser auch ein

hoher Grad an Vernetzung - sondern auch eigene Konzepte zur Datenhaltung sind nötig.

Der Durchbruch der Data Warehouse-Technologie auf Nutzerseite ist vor allem dem OLAP-Ansatz zu

verdanken (vgl. [Boehn03], S. 167). Dementsprechend stehen OLAP und Data Warehousing nicht in Kon-

kurrenz zueinander, sondern sind als einander unterstützende Konzepte bzw. Ansätze im Umfeld der Ma-

nagementunterstützung zu sehen (vgl. [Chami00], S. 335).

Stefan Gilmozzi [Gilm96]

Grundlagen

Michael Bleck

2.8 Grundlagen des Projektmanagements

"Nicht das, was wir nicht wissen, bringt uns zu Fall ... sondern das, was wir fälschlicherweise zu wissen glauben"

Im folgenden Kapitel werden die wesentlichen Grundlagen zum Projektmanagement erläutert und insbe-

sondere die unterschiedlichen Klassifikationen der Projektvorgehensmodelle vorgestellt.

2.8.1 Projekt

Der lateinische Ursprung für den Projektbegriff ist "proiectum", was "das voraus Geworfene" bedeutet.

Laut DIN 69901 ist ein Projekt ein "Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen

in ihrer Gesamtheit gekennzeichnet ist, z.B. Zielvorgabe, zeitliche, finanzielle, personelle und andere Be-

grenzungen, Abgrenzung gegenüber anderen Vorhaben, projektspezifische Organisation" (vgl. [Pro-

jec04]).

In jedem Fall sollte eine Projektaufgabe folgende Kriterien erfüllen:

· komplexe, neuartige, einmalige Aufgabenstellung

· messbare Ziele zeitliche Befristung (Anfang und Ende)

· begrenzte Ressourcen (Geldmittel, Personal)

· interdisziplinäre Bearbeitung (Teamarbeit)

Es muss vor Beginn eines jeden einzelnen Projekts geprüft werden, ob das jeweilige Vorhaben "projekt-

würdig" ist oder es im Rahmen routinemäßiger Prozesse effektiver und effizienter bearbeitet werden kann.

2.8.2 Definition von Projektmanagement

Der Terminus Projektmanagement hat in der Praxis vor allem zwei Bedeutungen. Einerseits wird darunter

generell die Arbeits- und Organisationsform zur Bearbeitung von Projekten verstanden. Andererseits be-

schreibt Projektmanagement auch die Führungs- und Managementaufgabe in Projekten. Projektmanage-

ment ist ein systematischer Prozess zur Führung komplexer Vorhaben. Es umfasst die Organisation, Pla-

nung, Steuerung und Überwachung aller Aufgaben und Ressourcen, die notwendig sind, um die Projekt-

ziele zu erreichen.

[DeMar01]

Grundlagen

Michael Bleck

Das Project Management Institute grenzt den Projektmanagementbegriff wie folgt ab:

"Project Management is the application of knowledge, skills, tools and techniques to project activities to

meet project requirements" (vgl. [PMI04]).

In den folgenden Kapiteln wird genauer auf die Besonderheiten von Projektmanagement in IT Projekten

eingegangen und im Besonderen die Bedeutung der Verwendung von Projektvorgehensmodellen heraus-

gestellt.

2.8.3 IT Projektmanagement

"Führung ist die Steuerung der verschiedenen Einzelaktivitäten in einem Projekt im Hinblick auf das übergeordnete

Projektziel."

IT-Projektmanagement dient der Definition von Begriffen, Konzepten und der Methodik des Projektma-

nagements. Hier kommen alle wichtigen Wissensgebiete und Prozessgruppen des Projektmanagements

zusammen. Die Erkennung und Vermeidung von typischen Fehlern bei der Durchführung von Projekten,

genauso wie die Überwachung von Budget, Zeitrahmen und Qualität, wie in Abbildung 2-2 dargestellt

(vgl. [Grasl04]). Die Abbildung 2-2 verdeutlicht diesen Sachverhalt, da sich Faktoren, wie z.B. die Pro-

jektzeit erhöht, erhöhen sich auch die Kosten und ggf. auch die Qualität.

Im IT-Projektmanagement geht es um Planung, Steuerung und Kontrolle von IT- Projekten, genauso wie

die Organisation von Projektteams, der Kontrolle von Budgets, dem Qualitätsmanagement und der Ein-

führung- bzw. Migrationsplanung, d.h. um alle sogenannten unterstützenden Prozesse. Die verwendete

Methodik orientiert sich an gängigen Best-Practice-Methoden, welche sich bisher in zahlreichen nationa-

len und internationalen Projekten bewährt haben. Die Lösungsansätze müssen dem Bedarf gerecht wer-

den.

Abbildung 2-2: Magisches Dreieck

Quelle: [Grasl04]

Grundlagen

Michael Bleck

In der Abbildung 2-2 sind die wichtigsten Kriterien in einem IT - Projekt gekennzeichnet. Beispielsweise

erfordert eine Erhöhung der Leistung / Qualität mehr Mitarbeitereinsatz, dadurch wächst der Zeitaufwand,

bei gleichbleibenden Mitarbeiterzahl verlängert sich auch die Projektlaufzeit, ausserdem steigen die Pro-

jektkosten als Folge des höheren Zeiteinsatzes.

In der Literatur gibt es verschiedene Ausprägungen dieses magischen Dreiecks. Jenny spricht vom ,,Teu-

felsquadrat", er geht von vier Knoten aus, weil er Leistung / Qualität in den beiden Knoten Leistungsum-

fang / Quantität und Qualität zerlegt (vgl. [Jenny98], S.19ff). Eine andere Variante ist in der Abbildung 2-

3 dargestellt fügt im ,,Magischen Fünfeck" zu den ursprünglichen drei Knoten zwei weitere Methoden und

Mitarbeiter hinzu. Denn auch Methodeneinsatz und Mitarbeiter beeinflussen Zeit, Qualität und Kosten

wesentlich. Somit gehören Mitarbeitermotivation und qualifikation ebenfalls zu den wichtigen Erfolgs-

faktoren von IT Projektmanagement (vgl. [Grasl04).

Abbildung 2-3: Magisches Fünfeck

Quelle: [Grasl04]

Um alle anfallenden Aufgaben, Verantwortlichkeiten und Rollen innerhalb des IT Projektmanagments

abzubilden, bietet sich die Verwendung eines Vorgehensmodells an. Welche Vorgehensmodelle existieren

wird in den folgenden Abschnitten geklärt.

2.9 Vorgehensmodelle

Bei der Entwicklung von Software bzw. Applikationen werden vorgegebene Richtlinien benutzt. Solche

Richtlinien werden in der IT Branche als Vorgehensmodell (VM) bezeichnet. Der Zweck eines VMs be-

Grundlagen

Michael Bleck

steht in der Bestrebung, die zu entwickelnde Applikation termingerecht, mit einem hohen Maß an Qualität

und in einem festgelegten Kostenrahmen zu erstellen.

Dabei stellt sich die Frage, worin die Notwendigkeit für die Verwendung von Vorgehensmodellen liegt.

Durch den Verzicht auf die Verwendung von standardisierten Vorgehensmodellen werden laut Ernst &

Young Studie 2002 allein in Deutschland jährlich Schäden in Höhe von 25 Mrd verursacht (vgl.

[Erns02]). Bereits im Jahre 2001 ergab eine Studie, dass dadurch nur 26% aller kleinen bis mittleren IT-

Projekte rechtzeitig fertig werden (vgl. [Erns02]).

Dabei fällt auf, dass es in den meisten Fällen oft ähnliche grundsätzliche Probleme und Fehler im Pro-

jektmanagement sind, die diese fehlerhaften Entwicklungen verursachen. Projektvorgehensmodelle bilden

den Ansatz des Projektmanagement auf den zukünftigen Verlauf des Projektes ab. Sie bieten Werkzeuge

und Methoden, mit denen das Projekt dokumentiert und standardisiert durchgeführt werden kann. Vor

allemim Hinblick der Vorteile der Standardisierung unterstützen die Projektvorgehensmodelle den Pro-

jektverlauf. So werden durch den vorgegebenen Verlauf Kosten eingespart und die Realisierungslaufzei-

ten reduziert. Weiterhin verbessern sie die Qualität und die Kommunikation in dem Projekt.

VM ermöglichen ein systematisches und reproduzierbares Vorgehen durch die Defintion:

· von durchzuführenden Aktivitäten,

· des Ablaufs dieser Aktivitäten in Prozessen,

· von verschiedenen Phasen des Vorgehens,

· des Ergebnisses der verschiedenen Aktivitäten und Phasen.

Bei der Literaturrecherche findet man eine Vielzahl von VM, welche widerrum unterschiedliche Varianten

vertreten. Unter allen VM unterscheidet man zwei wesentliche Klassifizierungen:

· Lineare oder Klassische Vorgehensmodelle, z.B. Wasserfallmodelle oder Phasenmodelle.

Das bedeutet, dass Zerlegen des Vorgehens in verschiedene Phasen, die sequentiell durchlaufen

werden. Die nächste Phase wird erst dann begonnen, wenn die vorherige Phase abgeschlossen

wurde.

· Iterative Vorgehensmodelle, z.B. Spiralmodelle, Rapid Prototyping

Phasen verlaufen dabei teilweise überlappend und das Ziel ist die schnellstmöglichste Realisie-

rung präsentierbarer oder verwendbarer Prototypen der zu entwickelnden Leistung.

Bei der Betrachtung der Arten von VM wird deutlich, dass es nie ein pauschales optimales Modell geben

kann. Das verwendete VM muss auf Basis der konkreten Anforderungen des Projektes und der verwende-

Grundlagen

Michael Bleck

ten Technologie ausgewählt werden. Entscheidend ist die Erkenntnis, dass die Entwicklung eines geeigne-

ten VM noch nicht das erfolgreiche SAP BW Projekt ergibt. Denn VM ersetzen nicht das Wissen, Können

und die Erfahrung von Projektmanagern und mitarbeitern.

Im folgenden Kapitel werden die Klassischen Softwarentwicklungsmodelle vorgestellt und ein Blick auf

die Neuen, Modernen Vorgehensmodelle, die erst in den letzten Jahren angewendet worden sind, gewor-

fen. Im Fokus liegen dabei die iterativen und inkrementellen Softwareentwicklungsprozesse.

2.9.1 Klassische Softwareentwicklungsmodelle

Das Ziel aller Softwareentwicklungsmodelle ist es, eine Hilfestellung bei der Organisation von Software-

Entwicklungsprojekten zu geben und die Menge aller dabei anfallenden Aktivitäten in klare und verbind-

liche Arbeitsabschnitte aufzuteilen. Man erhofft sich durch die Befolgung von Vorgehensmodellen eine

bessere Planbarkeit der personellen und finanziellen Aspekte, was schließlich zu einer höheren Projektsi-

cherheit beiträgt. Wenn organisiert und arbeitsteilig entwickelt und getestet wird, hat das resultierende

Software-Produkt eine höhere Qualität und wird den Kunden letztlich zufriedenstellen. Softwareentwick-

lung als ein eigenständiger Prozess in der Computerindustrie entstand Mitte der 60er Jahre. Von der hard-

ware- und systemnahen Programmierung damals zur heutigen abstrakten und anwenderfreundlichen Ent-

wicklung ist Zeit vergangen, in der durch effiziente Verfahren, optimierte Methoden, straffe Organisation

und globales Management die Produktion von Software an industrielle Anforderungen angepaßt wurde.

Zu den wesentlichen Phasen bei der Entwicklung von Software die in der Abbildung 2-4 dargestellten

Phasen.

Abbildung 2-4: Phasen der Softwareentwicklungen

Quelle: Eigene Darstellung

Dabei ist es immer das Ziel, die Organisation der Anwendungsentwicklung in beherrschbare Schritte zu

gliedern.

Grundlagen

Michael Bleck

2.9.1.1 Wasserfallmodell

Das Wasserfallmodell ist ein sehr lineares Vorgehensmodell. Aus diesem Grundsatz heraus entstand dabei

die charakteristische Unterteilung in Entwicklungsphasen, diese in der Abbildung 2-5 veranschautlicht.

Für jede Phase ist genau definiert, was mit welchen Mitteln zu tun ist. Hierbei ist es wichtig, dass die ein-

zelnen Projektphasen komplett abgeschlossen sind, bevor die nächste beginnt. Insbesondere dann, wenn

die Ergebnisse der vorangegangenen Phase, der Input für die folgende Phase ist.

Abbildung 2-5: Das Wasserfallmodell

Quelle: [Royce01]

Abbildung 2-5 zeigt das Wasserfallmodell nach Royce (vgl. [Royce01]). Im Gegensatz zu dem Boehm-

schen Wasserfall, ist es um Rückkopplungsschleifen erweitert. D.h. erweisen sich die Ergebnisse einer

vorangegangenen Phase als unzureichend, so wird die aktuelle Phase abgebrochen und der Prozess wieder

in der vorherigen Phase fortgesetzt.

Das Vorgehensmodell ist dokumententbetrieben und macht wenig Aussagen darüber, welche Massnahmen

in welcher der fünf Phasen durchzuführen sind.

· Phase 1 Das Ergebnis der Anforderungsphase ist ein Anforderungskatalog, in dem die Vorstel-

lungen der Auftraggeber definiert werden.

Grundlagen

Michael Bleck

· Phase 2 In der Entwurfsphase wird ein technischer Feinentwurf erstellt, der das zu realisierende

System in Komponentendarstellung zeigt.

· Phase 3 Das Ergebnis der Codierungsphase ist der Quelltext bzw. die Implementierung, der die

Umsetzung des Feinentwurfs in eine Programmiersprache darstellt.

· Phase 4 In der Testphase wird ein Abnahmeprotokoll verfasst, mit welchem dokumentiert wird,

ob die Anforderungen durch das entwickelte System erfüllt werden.

· Phase 5 In der Betriebsphase wird das betriebsfähige System beim Auftraggeber installiert.

Die grundsätzlichen Bestandteile Analyse, Design, Realisierung und Einführung finden sich auch in vielen

später entwickelten Modellen zur Softwareentwicklung wieder. Um die Anwendbarkeit für kleine IT

Projekte des Wasserfallmodells einschätzen zu können, werden in der Tabelle 2-1: die Vor und

Nachteile des Modells gegenübergestellt.

Vorteile

Nachteile

sehr intuitiv und leicht erlernbar

keine ausreichende Reaktion auf sich ändernde

Anforderungen

suggeriert planbaren Entwicklungsverlauf

reale Projekte folgen selten diesem Ablauf da-

durch klaffen Realität und Modell auseinander

sehr strukturiert und damit leicht steuerbar

der Anwender sieht das System erst am Ende

geringer Managementaufwand

Qualitätskontrollen und Test erfolgen erst am Ende

Verschiebung der Risikoerkennung mit Möglichkeit

des Gegensteuerns an das Ende des Projektes

lange

Laufzeiten

Tabelle 2-1: Bewertung des Wasserfallmodells

Quelle: Eigene Darstellung

2.9.1.2 V-Modell 97

Das V-Modell strukturiert den Softwareentwicklungsprozess ähnlich wie das Wasserfallmodell in einer

sequentiellen Abfolge von Phasen (siehe Abbildung 2-6). Wie in der Abbildung dargestellt, erfolgt die

ständige Validierung, d.h. die Überprüfung eines Software-Produktes hinsichtlich seiner Eignung und

seines Werts bezüglich seines Einsatzzwecks. Als wesentliche Weiterentwicklung betont es die Bedeutung

überprüfender Tests, die für eine erfolgreiche Applikationsentwicklung unabdingbar sind. Allerdings ist

Grundlagen

Michael Bleck

das V-Modell für frühe Fehler sehr anfällig und bietet wenig Flexibilität gegenüber Risiken und sich än-

dernden Anforderungen, ähnlich wie das Wassermodell.

Abbildung 2-6: Das V-Modell

Quelle: [Bremer98]

Das Vorgehensmodell dient als eine Richtschnur für die Organisation und Durchführung von IT-

Vorhaben. Das "V-Modell 97", auch EstdIT

genannt, ist bei vielen zivilen und militärischen Vorhaben

des Bundes verbindlich vorgeschrieben. Es ist mit dem Wasserfallmodell vergleichbar, jedoch werden

frühe Phasen mit Testdaten verbunden (V-förmig, siehe Abbildung 2-6). Es ist auch iterativ anwendbar

und kann mit Unified Markup Language (UML) eingesetzt werden. Phasen und zeitliche Abläufe stehen

nicht im Vordergrund. Es ist sehr stark formalisiert und dokumentenzentriert und muss vor der Anwen-

dung angepasst werden.

Entwicklungsstandard für IT-Systeme

Grundlagen

Michael Bleck

Zum V-Modell sind in drei Bänden drei Standardisierungsebenen beschrieben:

· Vorgehensmodell beschreibt durchzuführende Aktivitäten (Tätigkeiten) und zu erstellende Pro-

dukte (Ergebnisse)

· Methodenzuordnung legt fest, mit welchen Methoden die Aktivitäten des Vorgehensmodells

durchzuführen und welche Darstellungsmittel in den Ergebnissen zu verwenden sind

· Werkzeuganforderungen legen fest, welche funktionalen Eigenschaften die Software-Tools auf-

weisen müssen

Das V-Modell ist in vier Submodelle gegliedert:

PM: Projektmanagement

QS: Qualitätssicherung

SE: Softwareentwicklung/Systemerstellung

KM: Konfigurationsmanagement

Jedes Modell legt seine Aktivitäten, Produkte und Rollen fest. Dabei ist eine Aktivität eine Tätigkeit, die

bezogen auf ihre Ergebnis und ihre Durchführung genau beschrieben wird. In diesem Zusammenhang ist

ein Produkt, als das Ergebnis einer Aktivität zu sehen.

Grundlagen

Michael Bleck

Vorteile

Nachteile

Gut geeignet für grosse Projekte

Overhead bei mittleren und kleineren Projekten

generisches Modell mit definierten Möglichkeiten

zur Anpassung

Toolunterstützung zwingend erforderlich

Grundlage für eine Zertifizierung nach ISO 9000 Rollendefinition oft unrealistisch

beschränkt sich nicht allein auf die Softwareer-

stellung, sondernformalisiert den gesamten Pro-

zess (inkl. Projektmanagement und Qualitätssi-

cherung)

zu strikter Phasenablauf, wenig flexibel auf unter-

schiedliche Projektanforderungen

sehr ausgefeilte und detaillierte Vorgaben, Ergeb-

nismuster, Rollendefinitionen und -zuordnungen

Vollständigkeit und Gründlichkeit verhindern indi-

viduelle Anpassung an abweichende Projektum-

stände

ermöglicht standardisierte Abwicklung insbeson-

dere von großen Projekten

hoher Managementaufwand mit ausgeprägten For-

malismen

hoher

Schulungsaufwand

notwendig

Tabelle 2-2: Bewertung des V-Modells

Quelle: Eigene Darstellung

Derzeit befindet sich das V-Modell 97 in einer grundlegenden Überarbeitung. Seit 1997 wurde das Modell

nicht mehr an Neuerungen in der Informationstechnologie, wie komponentenbasierte Entwicklung und der

,,Test-first-Ansatz", angepasst. Motivation für die Überarbeitung und die Schaffung des V-Modell XT war

die Steigerung der Verbreitung und der Akzeptanz bei kleineren und mittleren IT Projekten. Erhebliche

Einflussfaktoren sind dabei auch die Qualitätseigenschaften Anwendbarkeit, Erweiterbarkeit und Anpass-

barkeit. Diesen Eigenschaften wurde durch eine modulare, bausteinbasierte Grobstruktur des neuen V-

Modells XT unterstützt. Sie ist die Grundvorrausetzung für eine Skalierbarkeit und erlauben eine verein-

fachte, individuelle Änderung des V-Modells. Neben der neuen Grobstruktur wurde mithilfe einer umfas-

senden Werkzeugunterstützung die Akzeptanz bei den Anwendern gesteigert.

Ein wesentliches Merkmal des V-Modells ist die ziel- und ergebnisorientierte Vorgehensweise. Diese

Grundphilosophie ist an vielen Stellen im V-Modell XT sichtbar (vgl. [Deubl04]):

· Minimierung der Projektrisiken

Das V-Modell XT gibt standardisierte Vorgehensweisen vor, beschreibt die zugehörigen Ergeb-

nisse und die verantwortlichen Rollen. Damit erhöht das V-Modell XT die Projekttransparenz und

verbessert die Planbarkeit von Projekten. Planungsabweichungen und Risiken werden bereits

frühzeitig erkannt. Prozesse lassen sich besser steuern und das Projektrisiko wird eingedämmt.

Grundlagen

Michael Bleck

· Verbesserung und Gewährleistung der Qualität

Als standardisiertes Vorgehensmodell stellt das V-Modell XT sicher, dass die zu liefernden Er-

gebnisse vollständig und von gewünschter Qualität sind. Die durch das Modell definierten Zwi-

schenergebnisse können auf diese Weise frühzeitig überprüft werden. Außerdem vereinheitlicht

das V-Modell XT die Produktinhalte. Die Ergebnisse sind deshalb besser lesbar, verständlicher

und leichter zu überprüfen.

· Eindämmung der Gesamtkosten über den gesamten Projekt- und Systemlebenszyklus

Durch die Anwendung des standardisierten Vorgehensmodells lässt sich der Aufwand für die Ent-

wicklung, die Herstellung, den Betrieb und die Pflege und Wartung eines Systems auf transparen-

te Weise kalkulieren, abschätzen und steuern. Die erzeugten Ergebnisse sind einheitlich und leich-

ter nachvollziehbar. Dies verringert die Abhängigkeit des Auftraggebers vom Auftragnehmer und

erleichtert anschließende Aktivitäten und Projekte.

· Verbesserung der Kommunikation zwischen allen Beteiligten

Die standardisierte und einheitliche Beschreibung aller relevanten Bestandteile und Begrifflich-

keiten ist die Basis des wechselseitigen Verständnisses aller Projektbeteiligten. So werden Rei-

bungsverluste zwischen Nutzer, Auftraggeber, Auftragnehmer und Entwickler reduziert.

2.9.2 Iterative, inkrementelle Vorgehensmodelle

Um die unzureichenden Flexibilität bei Wasserfallmodell und V-Modell zu umgehen, wurden die iterati-

ven, inkrementellen VM entwickelt. Diese wird häufig auch als evolutionäre Softwareentwicklung be-

zeichnet. In dem folgenden Kapitel werden zwei typische Vertreter dieser Gruppe vorgestellt und auf die

Eignung für kleine und mittlere IT - Projekte, wie z.B. SAP BW Projekte geprüft.

2.9.2.1 Das Spiralmodell

Das Spiralmodell gehört zu den Risikogetriebenen, Iterativen Vorgehensmodellen. Dabei kommt es insbe-

sondere in Projekten, bei denen die Anforderungen zu Beginn nicht absehbar sind, z.B. Data Warehouse

Projekten, zum Einsatz. So wird das Spiralmodell siehe Abbildung 2-7 in Zyklen eingeteilt, wobei ein

Zyklus immer das Erreichen eines Projektfortschritts bedeutet.

Die Ziele werden zu Beginn des Zyklus identifiziert und nach Realisierungsmöglichkeiten untersucht.

Dabei werden auch die Randbedingungen mit in die Untersuchung einbezogen.

Details

Seiten
Erscheinungsform: Originalausgabe
Erscheinungsjahr: 2005
ISBN (eBook): 9783832488321
ISBN (Paperback): 9783838688329
DOI: 10.3239/9783832488321
Dateigröße: 3 MB
Sprache: Deutsch
Institution / Hochschule: Fachhochschule Stralsund – Wirtschaft
Erscheinungsdatum: 2005 (Juni)
Note: 1,3
Schlagworte: business intelligence datawarehouse produktmanagement itil methoden
Produktsicherheit: Diplom.de

Autor

Michael Bleck (Autor:in)

Entwicklung eines Vorgehensmodells für SAP BW-Projekte

Zusammenfassung

Leseprobe

Inhaltsverzeichnis

Details

Autor

Michael Bleck (Autor:in)