Vorgehensmodelle für die Einführung von Software

Dieses Kapitel dient dazu, einen Einblick in die Komplexität bei der Durchführung von IT-Projekten zu geben. Die einzelnen zu durchlaufenden Phasen der Vorgehensmodelle, wie auch dessen Beziehungen untereinander, sollen in diesem Zusammenhang auch die Rele-vanz der Kommunikation zwischen den Projektbeteiligten aufzeigen. Grundsätzlich wer-den seit 2003 zwischen klassischen und agilen Vorgehensmodellen zur Entwicklung von Software unterschieden. Die klassischen Vorgehensmodelle sind in Phasen aufgeteilt, die nacheinander ablaufen. Um eine Phase beginnen zu können, muss das Ergebnis der vor-hergehenden Phase dokumentiert und freigegeben werden. Die Dokumentation bezieht sich dabei auf Pflichtenhefte und Entwurfsdokumente.⁷¹ Die Kritik, dass die klassischen Model-le zu unfModel-lexibel auf sich im Projektverlauf ändernde Anforderungen reagieren, hat zu der Evolution der agilen Softwareentwicklung geführt.⁷² Im Fokus der agilen Modelle steht die reine Entwicklung von Software und weniger der organisatorisch-strukturierte und geplan-te Ablauf. Bei einem gleichzeitig frühen Beginn der Entwicklung wird die Entwurfsphase für Software auf ein Minimum reduziert. Die agilen Vorgehensmodelle ermöglichen eine schnelle Reaktion geänderter Rahmenbedingungen.⁷³ Diese Modelle unterstützen die Pro-jektabwicklung in mehrfach durchlaufenen Schleifen. Die Teile der Gesamtfunktionalität (Iterationen) werden entwickelt und geprüft. Die Prüfungsergebnisse haben Einfluss auf die Anforderungen und die technische Umsetzung der nächsten Funktionen.⁷⁴ Fehler wer-den so früh erkannt und korrigiert. Änderungen bzw. neue Anforderungen, die sich erst während des Projekts ergeben, werden akzeptiert und können flexibel berücksichtigt wer-den. Der Kunde kann aktiv in den gesamten Entwicklungsprozess eingebunden werden, indem er regelmäßig und in kurzen Abständen die weitere Entwicklung mit beeinflussen kann. ⁷⁵ Eine Übersicht beispielhafter Prozessmodelle von IT-PM zeigt die folgende Tabel-le. Die Abgrenzungskriterien der Tabelle sind in Flexibilität, Ablauf und Besonderheit auf-geteilt. Die Flexibilität gibt Auskunft, inwiefern das Modell an geänderte

71 Vgl. Brugger, 2005, S. 156.

72 Vgl. Brugger, 2005, S. 168.

73 Vgl. URL 5.

74 Vgl. Brugger, 2005, S. 171.

75 Vgl. URL 5.

20 rungen angepasst werden kann. Der Ablauf beschreibt die methodische Umsetzung des Projektes anhand eines Softwareprozessmodells. Weiterhin sollen noch eventuelle auftre-tende Besonderheiten der Modelle kurz angesprochen werden.

Tabelle 1: Vorgehensmodelle zur Einführung von Software

Modell

Flexibi-lität Ablauf Besonderheit

Wasserfall-Modell Niedrig sequentiell gute Planbarkeit

V-Modell Niedrig sequentiell Validierung, Verifikation V-Modell XT Hoch sequentiell,

indivi-duell

Werkzeugkasten für individu-elle Planung

Prototypen-Modell Hoch schrittweise geringe Entwicklungskosten Evolutionäres Modell Hoch schrittweise gut geeignet bei unklaren

An-forderungen

Inkrementelles Modell Mittel schrittweise gut für große Projekte

Nebenläufiges Modell Mittel parallel erfordert hohe Projekt-managementkompetenzen Spiralmodell Hoch zyklisch gut für große Projekte

RUP Niedrig schrittweise

auf-bauend, zyklisch

gut für große Projekte, UML⁷⁶-Abbildung

Scrum Hoch direkte

Entwick-lung

Selbstorganisation der Team-mitglieder

Extreme

Program-ming Hoch direkte

Entwick-lung

Einfachheit statt komplexer Lösungen

Quelle: eigene Darstellung.

Die genannten Modelle werden im Anhang 1 erläutert, um typische Softwareprozessmo-delle vorzustellen. Das Bewusstsein zweier VorgehensmoSoftwareprozessmo-delle sowie die Erkenntnisse ge-nannter Unterschiede dienen der Forschung als inhaltliche Grundlage für die Weiterent-wicklung von IT-PM im Umfeld der ERP-Anbieter. Die Erläuterungen im Anhang 1 unter-stützen den Anspruch der inhaltlichen Fundierung sowie der Schaffung einer Abstraktion der genannten Erkenntnisse im Sinne des Business Engineering.

76 „Die Unified Modeling Language (UML) ist eine Familie grafischer Notationen, hinter denen ein einziges Metamodell steht. Die Notationen helfen bei der Beschreibung und Entwicklung von Softwaresystemen, insbesondere, wenn diese Systeme objektorientiert (OO) sind.“ Fowler, 2004, S. 19.

21 Die Modelle von Probst/Gomez, Checkland und Simon können bei den beschriebenen Vorgehensmodellen als Analogie herangezogen werden. Auf Basis einer komplexen Prob-lemsituation führen eine Analyse zur Lösung und Umsetzung. Der Systemansatz für wei-che Netzwerke von Checkland und die Methodik des vernetzten Denkens nach Probst/Gomez unterstützen dabei, komplexe (und soziale) Problemsituationen zu gestalten.

Auf Basis einer „ganzheitlichen Denkweise“⁷⁷ werden verschiedene Faktoren, die ein Sys-tem beeinflussen können, berücksichtigt. Bertalanffys Verständnis eines SysSys-tems wird für diese Arbeit herangezogen und versteht ein System als „sets of elements standing in inter-action“⁷⁸. Der Systemansatz für weiche (soziale) Netzwerke, auch Soft Systems Methodo-logy (SM) genannt, ist eine Methode für Analyse- und Designzwecke. SM wird innerhalb von Systemanalysen eingesetzt, die in den 1960er Jahren von Peter Checkland entwickelt wurde.⁷⁹ Soziale Netzwerke können als ein Teil eines Unternehmens, einem weichen Sys-tem, verstanden werden.⁸⁰ Bei SM steht die ganzheitliche Betrachtung einer Problemsitua-tion im Fokus. Hirschheim und Lacity schreiben, dass SM „is a framework which does not force or lead the systems analyst to a particular solution, rather to an understanding”.⁸¹ Das heißt, durch Strukturierung wird das Problem verstanden. Ergänzend wird eine Analyse durchgeführt, wie die einzelnen Teile des Systems differieren oder übereinstimmen. Auf Basis der Analyse wird versucht, eine grundlegende Optimierung zu identifizieren. Diese Aktivität deckt sich mit dem Modell des vernetzten Denkens, in der nach der Analyse des Problems die Problemfaktoren auf ihre Beziehung untereinander erforscht werden. Das Problem wird durch Modellierung visualisiert.⁸² Insbesondere Faktoren der Unterneh-menskultur stehen neben technischen Faktoren im Vordergrund bei SM.⁸³ Die reale und praktische Situation des Problems wird als chaotisch und problematisch angenommen.

Reales und theoretisches Systemmodell werden voneinander getrennt. Dem theoretischen Systemmodell kommt dabei die Aufgabe zu, die Denkprozesse zu strukturieren. Im Sinne der Zustandsraumtheorie nach Simon ist das Modell ein Attribut im kognitiven und pro-zessualen Prozess zur Lösung des schlecht strukturierten Problems.⁸⁴ Es dient als Medium, um die Situation zu kommunizieren. Das Modell ist aber kein Soll-Zustand bzw. Abbild der realen Situation, sondern dient als Referenz zur Strukturierung.⁸⁵ Mit einer Analyse auf

77 Vgl. Jung, 2003, S. 232.

78 Bertalanffy, 1968, S. 38.

79 Vgl. Checkland/Scholes, 1999, S. 7.

80 Vgl. Jung, 2003, S. 232.

81 Hirschheim/Lacity, 2000, S.101.

82 Vgl. Jung, 2003, S. 233.

83 Vgl. Checkland/Scholes, 1999, S. 18.

84Vgl. Simon, 1962, S. 167.

85 Vgl. Checkland/Scholes, 1999, S. 19.

22 Basis der SM-Methode wird das Ziel verfolgt, verdeckte Problemfaktoren zu identifizieren, denkbare Alternativen zur Optimierung zu entwickeln. Diese Alternativen werden in einem weiteren Schritt auf ihre technische und kulturelle Realisierung geprüft. Gemäß der Er-kenntnis, dass Geschäftsprozesse ergänzend zu Funktionen bei der Analyse und Entwick-lung von Software hinzugezogen werden sollen, kann der Einsatz von Geschäftsprozessen als Attribute (Modelle) verstanden werden, um die Problemsituation zu strukturieren, zu verstehen und zu kommunizieren. Schwachstellen können im Problemlösungsprozess iden-tifiziert werden und zukünftige Lösungen können schrittweise anhand von Prozessmodel-len unter Akzeptanz der Mitarbeiter als Prozessausführende entwickelt werden.