- 1 -

Inhalt

Abbildungsverzeichnis   3

Tabellenverzeichnis   4

Formelverzeichnis   5

1  Abgrenzung  6

1.1  Projekte  6

1.1.1  Allgemeine Definition  6

1.1.2  Softwareprojekt  9

1.1.2.2  Softwareproduktlebenszyklus  10

1.1.2.3  Softwareprojekt  10

1.1.3  Vorvertrag  11

1.1.4  Entwicklung  14

1.1.5  Nachvertrag  14

1.2  Softwareprojekt im Sinne dieser Arbeit  15

2  Entwicklung eines Frameworks  16

2.1  Begriffsdefinition Framework  16

2.2  Ableiten eines Frameworks  17

2.2.1  Was soll durch dieses Framework erreicht werden?  17

2.3  Entwicklungsmodelle  17

2.3.1  Klassische Vorgehensmodelle  18

2.3.1.1  „Code und Fix“  18

2.3.1.2  Wasserfallmodell  18

2.3.1.3  V-Modell  18

2.3.2  Agile Vorgehensmodelle  18

2.3.2.1  Prototyping  19

2.3.2.2  Spiralmodell  19

2.3.2.3  Evolutionäres Prototyping  19

2.3.2.4  Experimentelles Prototyping  20

2.4  Das Controlling-Gebiet  20

2.5  Ziele  21

2.5.1  Kennzahlen  21

2.5.1.1  Kennzahlenordnungssystem  22

2.5.1.2  Kennzahlensteckbrief  25

2.5.1.3  Kennzahlen  27

2.5.1.4  Kennzahlentypen  30

2.5.1.5  Kennzahlensysteme  31

2.5.1.6  Kenngrößen vs. Kennzahlen  31

2.6  Bewertungsschema des Projektes  31

2.7  Kennzahlengewichtung und Sektorenbegrenzung  32

2.7.1  Anpassen der Bedeutung der Kenngröße  34

2.7.1.1  Anpassen der Gewichtung  34

2.7.1.2  Veto ohne Gewichtsanpassung  38

2.8  Relativierung von Kennzahlen anhand des jeweiligen Sektors  39

2.8.1  Kennzahlen mit unterem und oberem Ankündigungssektor  39

- 2 -

2.8.1.1  Die relative Position innerhalb des Leitsektors  40

2.8.1.2  Die relative Position innerhalb des oberen Ankündigungssektors  41

2.8.1.3  Bestimmung der relativen Position innerhalb des oberen  

Warnsektors   42

2.8.1.4  Die relative Position innerhalb des unteren Ankündigungssektors  43

2.8.1.5  Kennzahlen ohne Warnsektoren  44

2.8.2  Kennzahlen nur mit oberem Ankündigungssektor  44

2.8.3  Kenngrößen nur mit unteren Ankündigungssektor  44

2.8.4  Kenngrößen ohne Ankündigungssektoren  44

2.9  Aggregation der Kennzahlen  44

3  Anwendung am praktischen Beispiel der Lufthansa Systems  46

3.1  Experimenteller Prototyp  47

3.1.1  Datenbank  49

3.1.1.1  Tabelle „Projekte“  50

3.1.1.2  Tabelle „Kennzahlen“  51

3.1.1.3  Tabelle „KennzahlSteckbriefe“  51

3.1.1.4  Tabelle „Istwerte“  52

3.1.1.5  Tabelle „Messwerte“  52

3.1.1.6  Tabelle „Kategorien“  52

3.1.1.7  Tabelle „Klassen“  52

3.1.2  Frontend  53

3.1.2.1  DBServer.dll und Verbindung.dll  53

3.1.2.2  Frontend.exe  53

3.1.3  Excel-Anwendung  54

3.2  Anwendung des Frameworks  54

3.3  Bewertung der Ergebnisse  60

4  Fazit und Ausblick  61

4.1  Bewertung der praktischen Anwendung des Frameworks  61

4.2  Kritische Betrachtung der technischen Umsetzungsfähigkeit  62

Literaturverzeichnis   63

Anhang   65

- 3 -

Abbildungsverzeichnis   

Abb.  1.1: Softwarelebenszyklus  

Abb.  1.2: Ablaufphase Vorvertrag  

Abb.  1.3: Drei Phasen des Softwareprojektes  

Abb.  2.1: Kennzahlenklassen  

Abb.  2.2: Nummerierung der Kennzahlenklassen  

Abb.  2.3: Darstellung im Kennzahlenordnungssystem  

Abb.  2.4: Kennzahlsteckbrief  

Abb.  2.5: Kennzahl „Miete“  

Abb.  2.6: Kennzahl „Miete/Leasing/Pacht“  

Abb.  2.7: Kennzahl „Stromkosten“  

Abb.  2.8: Kennzahlensektoren.  

Abb.  2.9: 15 Kenngrößen mit gleicher Gewichtung  

Abb.  2.10: 15 Kenngrößen, Veto einer Kenngröße nach 75 Gewichtsverteilung  

Abb.  2.11: 15 Kenngrößen, Veto einer zweiten Kenngröße  

Abb.  3.1: Datenbank-Prototyp  

Abb.  3.2: Projekt Probetest1 nach der Auswertung.  

Abb.  3.3: Projekt Probetest2 nach der Auswertung.  

Abb.  B.1: Startfenster von Frontend.Exe  

Abb.  B.2: Fenster „Klassen“  

Abb.  B.3: Fenster „Kennzahlen“  

Abb.  B.4: Fenster „Berechnung“  

Abb.  B.5: Fenster „Formel“  

Abb.  B.6: Geänderte Auswahl  

Abb.  B.7: Makro-Aktivierung  

Abb.  B.8: Einstieg in Assistenten  

Abb.  B.9: Projektnamen  

Abb.  B.10: Kennzahlauswahl  

Abb.  B.11: Formular „Kennzahlen Suche“  

Abb.  B.12: Formular „Baum Suche“  

Abb.  B.13: Projekt Assistent „Kennzahlen Steckbriefe“  

Abb.  B.14: Formular „Kennzahl Auswahl“  

Abb.  B.15: Formular „Kennzahlen Steckbrief“  

Abb  B 16: Assistent „Berechnungsstart“  

- 4 - Tabellenverzeichnis

Tab. 2.1: Tabelle Kennzahlenperspektiven ..................................................................... 23 

Tab. 3.1: Tabelle „Istwerte“ mit Werten ......................................................................... 56 

Tab. 3.2: Sektorenwerte aus Probetest1........................................................................... 57 

Tab. 3.3: Abgeleitete Sektorenwerte ............................................................................... 57 

Tab. 3.4: Sektorenwerte Probetest2 ................................................................................. 59 

Tab. A.1: Tabelle „Projekte“, Attribute ........................................................................... 65 

Tab. A.2: Tabelle „Kennzahlen“, Attribute ..................................................................... 66 

Tab. A.3: Tabelle „KennzahlSteckbriefe“, Attribute ...................................................... 68 

Tab. A.4: Tabelle „Istwerte“, Attribute ........................................................................... 70 

Tab. A.5: Tabelle „Messwerte“, Attribute ....................................................................... 71 

Tab. A.6: Tabelle „Kategorien“, Attribute ...................................................................... 72 

Tab. A.7: Tabelle „Klassen“, Attribute ........................................................................... 73 

.

- 5 - Formelverzeichnis

Formel 2.1: Ermittlung der Gesamtgewichtung .............................................................. 33 

Formel 2.2: Ermittlung der Kenngrößengewichtung ....................................................... 34 

Formel 2.3: Ermittlung der Veto-Gewichtung ................................................................ 35 

Formel 2.4: Ermittlung Restgewichtung ......................................................................... 35 

Formel 2.5: Ermittlung der neuen Gewichtung ............................................................... 35 

Formel 2.6: Bestimmung der Weite des Leitsektors ....................................................... 39 

Formel 2.7: Bestimmung der Distanz zum unteren Ankündigungssektor....................... 39 

Formel 2.8: Bestimmung der relativen Position innerhalb des Leitsektors ..................... 40 

Formel 2.9: Bestimmung der Weite des oberen Ankündigungssektors .......................... 41 

Formel 2.10: Bestimmung der Distanz zum Leitsektor ................................................... 41 

Formel 2.11: Bestimmung der relativen Position innerhalb des oberen

Ankündigungssektors .................................................................................. 41 

Formel 2.12: Klassifizierung des Ankündigungssektors ................................................. 42 

Formel 2.13: Bestimmung der Weite des unteren Ankündigungssektors ....................... 43 

Formel 2.14: Bestimmung der Distanz zum Leitsektor ................................................... 43 

Formel 2.15: Bestimmung der relativen Position innerhalb des oberen

Ankündigungssektors .................................................................................. 43 

- 6 - 1 Abgrenzung

Um Controlling erfolgreich einführen zu können, sollte das Controlling-Gebiet (siehe Kap. 2.4) klar und unmissverständlich definiert werden, insbesondere in Hinblick auf die benötigten Kennzahlen, die aus einem großen Pool von möglichen Kennzahlen zu selektieren sind.

Dazu sollten zuerst die Begriffe geklärt werden, die zur Abgrenzung notwendig sind. Beim Controlling eines Softwareentwicklungsprojektes, ist zu definieren, was unter einem Softwareprojekt zu verstehen ist. Diese Abgrenzung sollte immer im Vorwege der Einführung eines Controllings erfolgen.

Weiterhin muss klar abgegrenzt sein, was unter IT-Projektcontrolling zu verstehen ist. Im Folgenden werden die Begriffe dargestellt und die Abgrenzung zu anderen Bereichen vorgenommen.

1.1 Projekte

Um zu definieren, was in dieser Arbeit unter einem Softwareprojekt verstanden wird, soll zuerst untersucht werden, was im Allgemeinen als Definition eines Projektes gelten kann und was unter Softwareprojekten im Speziellen zu verstehen ist.

1.1.1 Allgemeine Definition

Unter einem Projekt ist ein Vorgang zu verstehen, der sich durch die folgenden Eigenschaften ausweist:

- Er ist zeitlich begrenzt.

Der Vorgang hat somit einen definierten Anfang und ein definiertes Ende. Wie der Anfang bzw. das Ende definiert ist, bedarf einer entsprechenden Klärung. (Vgl. Schlingloff, 2002)

- Er ist hinsichtlich der Kosten und der Dauer abschätzbar. Hier zeigt sich der zeitliche Bezug, wie er oben bereits angesprochen wurde. Zusätzlich kommt der Kostenfaktor hinzu, der in einem gewissen Rahmen eingrenzbar erscheint. Üblicherweise erfolgt diese Abschätzung durch eine „Schätzklausur“. (Vgl. Schlingloff, 2002)

- 7 - - Erkann in Teilprojekte zerlegt werden.

Es kann eine Feingliederung eines Projektes in kleine, einzelne Projekte oder gar Tätigkeiten erfolgen. (Vgl. Pabst-Weinschenk o.J. (a))

- Er ist risikobehaftet.

Ein Projekt kann in Bezug auf das Projektgelingen oder -scheitern mit einem gewissen Maß an Risiko behaftet sein. Dies begründet sich durch die Neuartigkeit und die dadurch fehlenden Erfahrungen mit einem solchen Projekt. (Vgl. Schlingloff, 2002)

- Er erfordert die Zusammenarbeit von verschiedenen Spezialisten unterschiedlicher Bereiche.

Diese Forderung ergibt sich aus der Einmaligkeit und damit der Neuartigkeit eines Projektes. (Vgl. Schlingloff, 2002)

- Er hat einen Namen, ein definiertes Ziel, ein Projektteam und einen Projektleiter.

Ein Projekt wird durch seinen Namen eindeutig identifiziert. Das Ziel hat für ein Projekt eine besondere Bedeutung. Es müssen die folgenden Kriterien erfüllt sein:

- Es muss einen Namen haben, der es identifiziert.

- Es muss klar definiert sein.

- Es muss einen Zeithorizont haben.

- Es muss realistisch und verwirklichbar sein.

- Es muss messbar und überprüfbar sein.

Auch sollten sich die Mitarbeiter des Projektes mit diesem Ziel identifizieren können. (Vgl. Pabst-Weinschenk o.J. (c))

- 8 - DerProjektleiter trägt die Verantwortung für das Gelingen des Projektes. Diese Verantwortung gliedert sich in die Bereiche

- Projektteamführung und Personalverantwortung,

- Informationsverantwortung,

- Planungsverantwortung,

- Koordinierungsverantwortung,

- Kontrollverantwortung,

- Dokumentationsverantwortung und

- Etatverantwortung.

Der Projektleiter benötigt zur Bewältigung seiner Aufgabe einen klar definierten Aufgaben-, Kompetenz- und Verantwortungsrahmen. (Vgl. (Pabst-Weinschenk o.J. (d))

- Er hat eine klare Abgrenzung zu anderen Vorhaben. Ein Projekt kann von anderen Vorhaben eindeutig abgegrenzt werden. (Vgl. Pabst-Weinschenk o.J.(a))

- Er weist eine projektspezifische Organisation aus. Diese Organisation bezieht sich auf das Projektteam und die Projektleitung. (Vgl. Schlingloff, 2002)

- Er weist eine gewisse Einmaligkeit auf.

Diese gewisse Einmaligkeit setzt sich aus einer Vielzahl von Attributen zusammen. Diese sind anderen

- Zielvorgaben,

- zeitliche, finanzielle und personelle Faktoren und

- Abgrenzungen gegenüber anderen Projekten.

Die Gesamtheit aller Attribute zeigt dazu die Einmaligkeit eines Projektes an. (Vgl. Pabst-Weinschenk o.J. (b))

- 9 - 1.1.2 Softwareprojekt

Nachfolgend soll definiert werden, was unter einem Softwareprojekt zu verstehen ist. Dazu soll zuerst geklärt werden, was Software im Einzelnen ist.

Software

Eine Software kann in einem engeren Sinne und in einem weiteren Sinne definiert werden. Im Folgenden werden beide Definitionen aufgeführt und näher betrachtet. 1.1.2.1.1 Software im engeren Sinne Im engeren Sinne sind unter dem Begriff Software „Algorithmen, die in einer Programmiersprache beschrieben sind“ (Schlingloff, 2002)

zu verstehen, somit jegliche in einer beliebigen Programmiersprache geschriebenen Codezeilen. Diese Definition bezieht sich auf die immateriellen Elemente, die durch eine Programmierung erzeugt werden können. Es handelt sich hierbei um eine zusammenfassende Beschreibung von Programmen, die zur Ausführung auf einer Maschine vorgesehen sind. Dabei wird zwischen System und Anwendungssoftware sowie Entwicklungssoftware unterschieden. (Vgl. Hansen & Neumann, 2005)

1.1.2.1.2 Software im weiteren Sinne

Software im weiteren Sinne bezeichnet

„Jede Art von geistigem Artefakt, welches zur Ausführung auf einer Maschine konzipiert ist (also auch: Spezifikationen, Diagramme, Konstruktionszeichnungen, Pläne, […])“ (Schlingloff, 2002). Das Verständnis der Software im weiteren Sinne ergänzt somit den Softwarebegriff im engeren Sinne um die zugehörige Dokumentation. Insbesondere können hierunter auch die organisatorischen Richtlinien und Verfahrensregeln verstanden werden.

- 10 - 1.1.2.2Softwareproduktlebenszyklus

Der Softwareproduktlebenszyklus umfasst die Zeitspanne von der ersten Initialisierung eines Softwareentwicklungsprozesses bis hin zur Entsorgung der Software oder deren Ablösung durch ein Nachfolgeprodukt.

1.1.2.3 Softwareprojekt

Nachdem nun die Begriffe Projekt, Software und Softwareproduktlebenszyklus definiert worden sind, kann auf dieser Grundlage ein Softwareprojekt näher beschrieben werden. Ein Softwareprojekt ist ein Projekt, dessen Ziel die Erstellung oder Wartung eben dieses Softwareproduktes ist und das sich über einen Teil oder über den gesamten Softwareproduktlebenszyklus erstrecken kann.

Wie aus der obigen Abbildung hervorgeht, lässt sich der Softwareproduktlebenszyklus in verschiedene Abschnitte unterteilen. Dabei können drei Phasen besonders herausgearbeitet werden, die im Nachfolgenden dargestellt werden.

- 11 - 1.1.3 Vorvertrag

Diese Phase umfasst den Softwareproduktlebenszyklus von der ersten Projektinitiierung, also dem ersten Kontakt mit dem Auftraggeber, bis zum Vertragsabschluss. In dieser Phase erfolgt die Kontaktaufnahme zwischen dem Auftraggeber - dem Empfänger der Leistung eines Softwareprojektes - und dem Auftragnehmer - dem Erzeuger der Leistung eines Softwareprojektes. Hier erfolgt die Sondierung der Wünsche des Auftraggebers, die als sogenanntes Lastenheft schriftlich niedergelegt werden. Dabei werden die Kundenwünsche in quantifizierbarer und prüfbarer Form dargestellt. Das Lastenheft dient als Ausschreibungs-, Angebots- und Vertragsgrundlage. Auch wird in dieser Phase das sogenannte Pflichtenheft erstellt, das zum einen das Lastenheft enthält und vom Auftragsnehmer mit detaillierten Realisierungsanforderungen ergänzt wird. Es dient als Basis für die Durchführung von Abnahmen und als verbindliche Vereinbarung zur Projektabwicklung. Als Gegenpool zum Pflichten- und Lastenheft kann im Vertrag auch eine Abgrenzung der zu erbringenden Leistung erfolgen. Dabei werden die Kundenwünsche in nicht detaillierter Form vertraglich festgehalten und durch vertragliche Zusätze dahingehend ergänzt, was noch zur Projektrealisierung gehört bzw. was sich außerhalb der Projektrealisierung bewegt und ein Change-Request erfordert. Aus dieser Phase, die als Angebots- und Nachfragephase gesehen werden kann, geht ein Softwareprojektvertrag hervor.

Nach (Schlingloff 2002(b)) betrifft dies die Bereiche „Projektinitialisierung“, „Anforderungserhebung“, „Wirtschaftlichkeits- und Marktstudie“, „Ausschreibung und Angebot“ sowie „Bestellung“.

- 12 - Innerhalbder Vorvertragsphase lassen sich somit verschiedene Teilabschnitte unterscheiden:

- Initialer Start

In diesem Teilabschnitt erfolgt die erste Kontaktaufnahme. Oftmals erfolgt diese durch den Kunden.

- Erstes Gespräch

In diesem Teilabschnitt, der zeitlich durchaus mit dem initialen Start zusammenfallen kann, erfolgt eine erste grobe Anforderungsdefinition. Dabei können auch eine Spezifikation der genutzten Technologien und eine erste grobe Abschätzung des benötigten Zeitrahmens erfolgen. Auch können hier Besonderheiten oder Vorgehensmodelle spezifiziert werden.

- Ausschreibung

Nach dem ersten Gespräch erfolgt durch den Kunden die Ausschreibung des Projektes. Diese Ausschreibung kann an einen Anbieter, aber auch an eine Gruppe von Anbietern adressiert werden. In diesem Teilabschnitt erfolgt die Erstellung einer genaueren Spezifikation, möglicherweise in Form eines Lastenheftes, eines Anforderungskatalogs oder eines Grobkonzeptes.

- Angebot

Das Erstellen des Angebotes kann, besonders bei größeren Aufträgen, im Anschluss an den Teilabschnitt der Ausschreibung erfolgen. Auch wenn die Ausschreibung an mehrere Auftragnehmer adressiert ist, erfolgt eine Erstellung eines Angebotes. Das Angebot umfasst dabei fachliche Einschätzungen aus Sicht des Auftragnehmers, die die Umsetzung der aus der Ausschreibung hervorgehenden Anforderungen beinhaltet. Dazu gehört die Machbarkeitsstudie. Auch eine kaufmännische Einschätzung des Aufwands erfolgt an dieser Stelle. Hier werden die technologischen Voraussetzungen, die durch den Kunden vorgegeben sind dargestellt und das Risiko, das mit einer Entwicklung einhergeht, betrachtet. Auch die Personaleinsatzplanung und der Zeitrahmen werden hier bereits festgeschrieben. Das Angebot wird auf Einhaltung von gesetzlichen Vorschriften geprüft und enthält eine Bindungsfrist.

- 13 - - Vertragsverhandlungen

Im Anschluss an die Erstellung des Angebotes kann es zu einer Angebotsannahme kommen. Dabei werden offene Punkte offensichtlich, die zu einer Rückkopplung in eine frühere Phase - an die Angebots-, teilweise sogar die Ausschreibungsphase - führen. Im besten Fall erfolgt die Leistung der Unterschriften. Anders als in der theoretischen Vorannahme erfolgt jetzt nicht zwingend die Erstellung eines Pflichtenheftes. Oftmals werden in der praktischen Umsetzung des Vertrages die Anforderungen abgegrenzt, wodurch eine Beschränkung des Softwareentwicklungsprojektes erfolgt. Dieses Vorgehen ermöglicht eine ungenaue Definition der Umsetzung, was dem Auftragnehmer entgegenkommt, da zur Zeit der Entwicklung die Umsetzung angepasst werden kann. Auch der Auftraggeber profitiert von diesem Vorgehen, da er seine Anforderungen zum Vertragsabschluss nicht detailliert formulieren muss. So wird die Softwareentwicklung innerhalb der Abgrenzungen durchgeführt, was beiderseitig Spielräume ermöglicht und die Vertragsgestaltung erheblich vereinfacht. Der Softwareerstellungsvertrag (Individualsoftware) ist derzeit ein Werk- und Liefervertrag mit Nutzungseinräumung. Nach der Entscheidung des BGH vom 23.7.2009 (Aktenzeichen VII ZR 151/08) kann sich dies jedoch bald ändern.

- 14 - 1.1.4 Entwicklung

In der nachfolgenden Phase erfolgt die Umsetzung der in der Vorvertragsphase entstandenen Anforderungen an das Softwareprojekt. Dazu kann es notwendig bzw. wirtschaftlich sein, Teile des Softwareprojektes an Zulieferbetriebe auszugliedern, so dass es in Bezug auf die Zulieferbetriebe ebenfalls zu einer Vorvertragsphase kommt. Dieses erneute Eintreten in eine Vorvertragsphase erfolgt unter dem Gesichtspunkt, dass der Auftragnehmer zum Auftraggeber wird und der Zulieferbetrieb zum Auftragnehmer. Die Entwicklung dieser Teilprojekte erfolgt dann im Zulieferbetrieb, für den die Phasen der Entwicklung und des Betriebsübergang analog gelten. Es erfolgt in dieser Phase die Implementierung der Anforderungen aus dem Pflichtenheft. An die Implementierung der Anforderungen schließt die Endabnahme durch den Auftraggeber an. Sofern im Pflichtenheft Nachbesserungen, Installationen und Schulungsmaßnahmen vorgesehen sind, gehören diese ebenfalls in die Phase der Entwicklung. In Abb. 1.1 betrifft dies die Bereiche „Entwicklung“, „Systemintegration“, „Abnahme“ und, sofern dies Bestandteil des Pflichtenheftes ist, „Erste Schulungen und Installation“.

1.1.5 Nachvertrag

Nach erfolgter Abnahme erfolgt die Nachvertragsphase. Diese Phase beinhaltet die weiterführenden Schulungsmaßnahmen und weitere Installationen, die nicht im Pflichtenheft vorgesehen sind und aufgrund weiterer vertraglicher Vereinbarungen entstehen. Der Auftragnehmer führt in dieser Phase Wartungsarbeiten durch, leistet entsprechenden Support und führt ggf. weitere Schulungen durch. Den Abschluss findet diese Phase in der Außerdienststellung der Software. In Abb. 1.1 betrifft dies die verbleibenden Bereiche „Weiterführende Installation und Anwenderschulung“, „Einsatz, Support und Wartung“ sowie „Außerdienststellung, Entsorgung“.

- 15 - 1.2 Softwareprojekt im Sinne dieser Arbeit

Diese Arbeit beschäftigt sich mit dem Controlling von Softwareentwicklungsprojekten, somit stehen Softwareprojekten in der Entwicklungsphase im Mittelpunkt der Untersuchung.

- 16 - 2 Entwicklung eines Frameworks

Bevor spezifiziert werden kann, was das Framework leisten soll, muss definiert werden, was im Sinne dieser Arbeit unter dem Begriff Framework zu verstehen ist.

2.1 Begriffsdefinition Framework

Der Begriff Framework stammt aus dem englischen Sprachgebrauch. Ins Deutsche übersetzt bedeutet er „Bezugssystem“, „Gerippe“, „Fachwerk“, „Grundstruktur“, „Rahmen“, „Gerüst“.

Im Sprachgebrauch der Informationswissenschaften bedeutet dieser Begriff Programmiergerüst im Sinne einer komponentenbasierten Entwicklung von Software. Im wirtschaftswissenschaftlichen Kontext wird der Begriff des Frameworks in Assoziation mit den IAS, den International Accounting Standards, gebracht, genauer dem „Framework for the Preparation and Presentation of Financial Statements“. Hier soll ein Framework eine

„[…] konzeptionelle Grundlage für die Erarbeitung und Anwendung von Rechnungslegungsvorschriften […]“ liefern. (Vgl. Wirtschaftslexikon 2000)

In Hinblick auf diese Arbeit, die Controlling als zentrales Thema hat, soll der Begriff des Frameworks in Anlehnung an die wirtschaftswissenschaftliche Interpretation des Begriffes Framework verstanden werden als

„Grundlage für die Erarbeitung und Anwendung von IT-Controlling-Maßnahmen im Bereich von Softwareentwicklungsprojekten“.

Hierfür soll das Framework einen Handlungsrahmen geben, der nicht zwingend verbindlich, aber richtungsweisend darstellen soll, wie ein IT-Projektcontrolling eingeführt werden kann.

- 17 - 2.2 Ableiten eines Frameworks

In den folgenden Abschnitten soll die Ableitung eines solchen Frameworks dargestellt werden.

2.2.1 Was soll durch dieses Framework erreicht werden?

Das hier vorgestellte Framework soll einen Handlungsrahmen vorgeben, der durch Anpassung eine Einführung von IT-Controlling ermöglicht, um einfach und schnell ein IT-Projekt bewerten zu können. Dabei soll bewusst darauf verzichtet werden, ein verbindliches Konzept vorzustellen, da eine Adaption des Frameworks durch Anpassung an die unternehmensspezifischen Gegebenheiten möglich sein soll. Um das so gesetzte Ziel zu erreichen, müssen zuerst die notwendigen Grundlagen zum Verständnis von Softwareentwicklungsprojekte gelegt werden, was in den folgenden Abschnitten erfolgen soll.

2.3 Entwicklungsmodelle In der Softwareentwicklung wird zwischen agilen und klassischen Softwareentwicklungsprozessen unterschieden. Beide Prozessarten stellen

unterschiedliche Anforderungen an das Projektmanagement in den verschiedenen Phasen des Softwareproduktlebenszyklus. Nachfolgend sind einige Beispiele dieser Prozessarten aufgeführt. Auf eine detaillierte Betrachtung soll an dieser Stelle jedoch verzichtet werden, da dies nicht Bestandteil dieser Arbeit sein kann.

- 18 - 2.3.1 Klassische Vorgehensmodelle

2.3.1.1 „Code und Fix“

„Code und Fix“-Vorgehensmodelle stammen aus der Anfangszeit der Rechnertechnologien, als Software noch von einem einzelnen Programmierer entwickelt und gewartet wurde. Die Software wird „on the fly“ zu den Anforderungen entwickelt und Fehler werden im laufenden Betrieb behoben. Dies ist ein eher unstrukturiertes Vorgehen, da direkt und ohne weitere Planung mit der Implementierung begonnen wird. (Vgl. Stein 2004)

2.3.1.2 Wasserfallmodell

Das Wasserfallmodel gliedert die Abläufe der Softwareentwicklung in mehrere Phasen auf, die stufenweise durchlaufen werden können. Dabei gehen die Ergebnisse einer Stufe in die nachfolgende über. Rückkopplungen sind hier maximal in die vorgelagerte Stufe vorgesehen. (Vgl. Hansen & Neumann, 2005, S. 246-284)

2.3.1.3 V-Modell

Das V-Modell ist eine Weiterentwicklung des Wasserfallmodells. Hier werden die Phasen V-förmig angeordnet und in verschiedene Tätigkeitsbereiche untergliedert. Dabei soll die horizontale Ebene die Zeitachse (von links nach rechts laufend) und die vertikale Ebene den Detaillierungsgrad (von oben nach unten zunehmend) angeben. (Vgl. Müller, 2002)

2.3.2 Agile Vorgehensmodelle

Agile Vorgehensmodelle ermöglichen die Rückkopplung des Softwareentwicklungsprozesses in jede der vorhergehenden Phasen. Dabei wird diese Rückkopplung als Bestandteil der Softwareentwicklung angesehen.

- 19 - 2.3.2.1Prototyping

Beim Prototyping werden verschiedene Bereiche der zu entwickelnden Software exemplarisch implementiert, ohne den vollen Funktionsumfang zu gewährleisten. Diese Prototypen erfüllen unterschiedliche Anforderungen, beispielsweise um das Design der Oberfläche darstellen zu können. Auch können nur bestimme Funktionen implementiert sein, beispielsweise um die Realisierbarkeit funktionaler Anforderungen zu bestimmen. So unterscheiden sich horizontale und vertikale Prototypen hinsichtlich der implementierten Funktionalität. Prototypen werden für Laborversuche,

Demonstrationszwecke, Pilotsysteme etc. entwickelt. (Vgl. Müller, 2002)

2.3.2.2 Spiralmodell

Das Spiralmodel durchläuft verschiedene Zyklen der Softwareentwicklung mehrfach. Hierbei wird die Softwareentwicklung der aktuellen Phase durch die Ergebnisse der vorhergehenden Phase maßgeblich beeinflusst. Dabei werden zuerst die Anforderungen definiert, dann entsprechende Lösungsvarianten erarbeitet, diese implementiert und aus dieser Implementierung eine erneute Definition der Anforderungen geplant und initiiert. (Vgl. Hansen & Neumann 2005, S. 246-284)

2.3.2.3 Evolutionäres Prototyping

Evolutionäres Prototying beinhaltet die Entwicklung von Prototypen in Verbindung mit dem Spiralmodell. Dabei wird zunächst eine lauffähige Software erstellt und dem Auftraggeber zur Verfügung gestellt. Dieser erste Prototyp berücksichtigt noch kein Oberflächendesign und implementiert nur die Grundfunktionalität. In Rücksprache mit dem Auftraggeber wird dieser (lauffähige) Prototyp weiterentwickelt zu einem weiteren Prototyp. Dieser wird erneut dem Auftraggeber zur Verfügung gestellt und erneut in Rücksprache mit diesem weiterentwickelt. Dieser Prozess läuft in mehreren Iterationen ab. (Vgl. Fechter, 2007, S. 7)

- 20 - 2.3.2.4Experimentelles Prototyping

Ein experimenteller Prototyp findet sich hauptsächlich im Bereich Forschung und Entwicklung. Hierbei handelt es sich um einen Prototypen, der dazu dient, neue Kenntnisse über einen bestimmten Sachverhalt zu erlangen. Dieser Prototyp ist nicht dazu gedacht, produktiv eingesetzt zu werden, da aufgrund seiner experimentellen Natur nicht davon ausgegangen werden kann, dass die zugrundeliegende Programmierung den Regeln einer sauberen Softwareentwicklung entspricht. Oftmals entstehen die Programmierschritte spontan und „aus der Situation“ heraus. Dieser Prototyp ist jedoch sehr gut geeignet, um eine Grundlage zur weiteren Entwicklung zu geben, da viele Problemstellungen bereits durch die spontane Programmierung evaluiert sind und Lösungsansätze aufzeigen. Er kann somit als „Blue-Print“ für eine Entwicklung angesehen werden. (Vgl. Kuhrmann, 2010; Wikipedia 2010)

2.4 Das Controlling-Gebiet

Im Rahmen dieser Arbeit soll als Controlling-Gebiet ein Softwareentwicklungsprojekt wie unter Kap. 1.2 beschrieben verstanden werden. Dabei beginnt die Erfassung der Kenngrößen nach dem Abschluss des Vertrages und endet mit dem Betriebsübergang. Alle Kenngrößen sollen hinsichtlich Ihrer Istgrößen (Ist) zur Projektsteuerung herangezogen werden können. Das Controlling-Gebiet umreißt damit klar die steuerungsrelevanten Kenngrößen innerhalb der Entwicklungsphase eines Softwareprojektes. Diese Definition soll gleichzeitig zur Abgrenzung herangezogen werden.

- 21 - 2.5 Ziele

Um ein Controlling durchführen zu können, müssen zuerst die zu erreichenden Ziele definiert werden. Für jedes Gebiet, das einem Controlling unterzogen werden soll, leiten sich die Ziele aus den Unternehmenszielen ab. Für ein Softwareprojekt können exemplarisch folgende Ziele angenommen werden:

- Budgeteinhaltung

- Zeiteinhaltung

- Kundenzufriedenheit sicherstellen

- Mitarbeiterzufriedenheit sicherstellen

- Strategische Ausrichtung des Projektes

- Know-how-Erweiterung

- …

Eine genauere Definition wie im Kap.1.1.1 würde jedoch den hier gesetzten Rahmen überschreiten.

2.5.1 Kennzahlen

Kennzahlen erfassen Zustände zu einem bestimmten Zeitpunkt in quantitativer und konzentrierter Form. Sie dienen insbesondere der Erfassung von Ist-, Soll- und Plangrößen. Ohne Kennzahlen wäre eine Steuerung in Form von Controlling nicht möglich. Eine Auswahl der benötigten Kennzahlen erfolgt gemäß der Zielsetzung des Controlling-Gebietes.