Prozesskostenbasierte Kalkulation agiler Softwareprojekte

Kalkulation und Steuerung agiler Softwareentwicklungsprojekte bergen vielfältige Herausforderungen, etwa auf der Inputseite aufgrund der geringen inhaltlichen Strukturierung des Prozessablaufs oder auf der Outputseite aus neuartigen Vertragstypen wie dem agilen Festpreisvertrag. Etablierte Verfahren der Softwarekalkulation sind hierauf nicht ausgerichtet. Grundsätzlich versprechen prozesskostenbasierte Ansätze noch die beste Grundlage. Der Beitrag ent–wickelt daher nach einer kurzen Analyse der Mängel etablierter Verfahren die Umsetzung prozesskostenbasierter Prognosen für agile Softwareprojekte und analysiert anhand eines Fallbeispiels mit Projektab-bruchoptionen Anwendungsmöglichkeiten des Realoptionsansatzes, um der Handlungsflexibilität agiler Projekte gerecht zu werden.

1.
Kalkulationsproblematik agiler Softwareprojekte

Es mag zunächst wie ein Scheitern des Software-Engineerings aussehen, wenn die Zusage einer definierten Leistung zu einem festen Preis, wie es letztlich ein starrer Wasserfallprozess verspricht, auch mit modernen Softwareprozessen nicht möglich ist (Schwaber 2004, S. 147). Letztlich handelt es sich jedoch nur um das Eingeständnis, dass die Softwareentwicklung für komplexe und dynamische Problemstellungen auf der Grundlage eines starren Entwicklungsansatzes zum Scheitern verurteilt ist. Kundenanforderungen ändern sich, da die Systemumwelt sich verändert, neue Prioritäten entstehen und neue Erkenntnisse der Zusammenhänge verlangen angepasste Entscheidungen. Zu ändern ist daher die Herangehensweise, mit der komplexe Softwareprobleme zu lösen sind (Beck 1999, S. 76), möchte man nicht mit eigenen Projekten zu Auflistungen gescheiterter Softwareprojekte (Charette 2005, S. 42) beitragen. Entsprechende Vorschläge führen zu iterativen und inkrementellen, insbesondere auch agilen Methoden der Softwareentwicklung (Beck et al. 2001; Cockburn 2006; Larman 2003; Oestereich und Weiss 2007).

Wenig Beachtung fand bisher die Auswirkung dieser Entwicklung auf die Methoden der Projektsteuerung sowie damit verbundene Problemfelder, wie bspw. die Kalkulation. Dabei ist die betriebswirtschaftliche Relevanz hoch, z. B. bei Entscheidungen des Auftraggebers einer Software über Eigen- oder Fremdentwicklung, bei der Preisuntergrenzenermittlung des Softwareherstellers oder auch beim laufenden Projektcontrolling. Erforderlich sind daher Kalkulations-verfahren, die bestmöglich die Besonderheiten der verwendeten neueren Vorgehensmodelle berücksichtigen und damit sowohl die Kostenprognose wie auch das laufende Projektcontrolling unterstützen (Baumeister und Ilg 2004, S. 194 f.). So hat der verstärkte Einfluss des Kunden in agilen Entwicklungsprojekten auch betriebswirtschaftliche Konsequenzen, bspw. wenn durch vertragliche Zusagen der Auftraggeber Softwareentwicklungen vorzeitig abbrechen kann (Oestereich und Weiss 2007; Opelt et al 2012). Ein prozessbasiertes Kalkulationsgerüst könnte dabei grundsätzlich für iterative, aber auch agile Entwicklungsmodelle geeignet sein. Seine Grundlagen werden im Weiteren entwickelt.

2.
Prozessorientierte Kalkulation agiler Softwareprojekte

2.1 Vergleich agiler Softwareprozesse mit dem Unified Process

Softwareprozesse sind Vorgehensmodelle zur Durchführung von Softwareprojekten. Ihr Zweck ist die problemorientierte Ausrichtung und Detaillierung der Vorgehensweise im Projekt (Burghardt 2012, S. 149 ff.). Zur Schärfung der Besonderheiten agiler Softwareprozesse werden diese mit dem Unified Process verglichen, der auf Jacobson, Booch, Rumbaugh und Kruchten zurückgeht. Er begegnet durch ein iteratives Vorgehen den Schwächen des in den Anfängen der Softwareentwicklung üblichen Wasserfallprozesses (Baumeister und Ilg 2004; Royce 1970), insb. seiner Starrheit und der Notwendigkeit, zu Projektbeginn das Projekt vollständig zu spezifizieren (Jacobson et al. 1999; Kruchten 2003; Ludewig und Lichter 2010).

Agile Prozesse stellen dagegen eine Gruppe iterativer und inkrementeller Entwicklungsmethoden dar, die teils unterschiedliche Schwerpunkte setzen. Diese können die Programmierung selbst betreffen wie im Extreme Programming  (Beck 1999), die Schlankheit des Prozesses betonen (Poppendieck und Poppendieck 2006) oder eine generelle Methodik zum Projektmanagement darstellen wie Scrum (Schwaber 1995; Schwaber und Beedle 2008). Die generelle Empfehlung an Entwickler ist, aus diesem Methodenkoffer eine individuell passende Mischung an Werkzeugen zusammenzustellen – wie dabei vorzugehen ist, bleibt im Detail im Regelfall offen (Larman 2003).

Die vier Phasen Inception, Elaboration, Construction und Transition sind kennzeichnende Kernbestandteile des Unified Process. Die Phasen agiler Prozesse sind weniger ausgeprägt, werden aber teilweise beschrieben (Larman 2003, S. 113). Abhängig von Projektinhalten können aber auch ganze Phasen entfallen. Da wesentliche Projektinhalte möglicherweise erst im Laufe des Projektes erkannt werden, erfolgt die Beschreibung der zentralen Phaseninhalte im Unified Process erst zum Ende der zweiten Phase, während sich agile Prozesse hier überhaupt nur grob festlegen.

Im Unterschied zur Starrheit des Wasserfallprozesses werden in iterativen Prozessen Änderungen nicht als Problem, sondern als natürlicher Projektbestandteil gesehen (Opelt et al. 2012, S. 24 ff.), entweder nach jeder Iteration beim Unified Process bis hin zur permanenten Einbeziehung des Kunden bei manchen agilen Prozessen (Rasmusson 2010, S. 21). Da in modernen Softwareprozessen aber der Fokus nicht auf der Abarbeitung eines Vertrages, sondern auf der Generierung von Kundennutzen liegt, sind hier neben den Kunden auch Entwickler Treiber von Prozessanpassungen, sofern diese aus ihrer Sicht solche für notwendig halten. Primär ist dabei stets die Frage der Priorisierung der in den nächsten Iterationen zu lösenden Aufgaben (Schwaber 2004, S. 137 ff.).

Iteratives Vorgehen ist kennzeichnend für alle modernen Softwareprozesse, womit kurze Einheiten von einigen Tagen bis hin zu wenigen Monaten gemeint sind. Die in Scrum als Sprints bezeichneten Iterationen agiler Projekte haben i. d. R. eine feste Dauer, häufig von vier Wochen (Schwaber 2004, S. 136). Iterationen sind nicht nur rein zeitliche Unterteilungen des Gesamtprojektes, sondern zeichnen sich dadurch aus, dass am Ende der Iteration konkrete, aus Kundensicht nutzenstiftende Projektergebnisse vorliegen und diese von Iteration zu Iteration weiter ergänzt und verfeinert werden. Das Gesamtprojekt wächst also in inkrementellen Schritten (Larman und Basili 2003).

Vergleicht man den Unified Process und agile Methoden hinsichtlich der Ausgestaltung der Iterationen, so sind diese beim Unified Process klar definiert und bestehen aus neun Disziplinen, welche Aktivitäten sowie weitere Prozessartefakte gruppieren und strukturieren, während in den Beschreibungen agiler Prozesse kaum inhaltliche Festlegungen gemacht werden und stattdessen das Entwicklungsteam laufend über die durchzuführenden Aktivitäten und die zu produzierenden Ergebnisse entscheidet (Schwaber 2004, S. 101 ff.).

Eine bedeutsame agile Methode ist auch die testgesteuerte Entwicklung (Beck 2002), die Testfälle bereits vor Beginn der Programmierung beschreibt bzw. entwickelt. Der Unified Process hat diese Methode übernommen (Larman 2003, S. 292). Im Unified Process ist eine große Zahl an Aktivitäten, Rollen und Artefakten beschrieben (Modelldetailliertheit), weshalb manche Autoren den Unified Process wie auch das Wasserfallmodell im Gegensatz zu den agilen Methoden als schwergewichtig bzw. als zu komplex bezeichnen (Hesse 2003; Larman 2003, S. 192). Dabei wird aber übersehen, dass die Prozesselemente des Unified Process als optional zu verstehen sind und sich daraus auch der Vorteil der Skalierbarkeit des Prozesses ergibt. Jedenfalls ist dem Unified Process ein hoher Organisationsgrad zu attestieren, wobei umfangreiche Dokumentationen kein zwingender Bestandteil sind. Schließlich unterscheiden sich agile Prozesse auch noch wesentlich durch die Rolle des Projektleiters: in agilen Prozessen versteht sich dieser als Coach, die Entscheidungen trifft aber das Entwicklungsteam. Der Unified Process ist dagegen hierarchisch organisiert, der Projektleiter entscheidet und trägt auch die Ergebnisverantwortung.

Zusammenfassend können Unified Process und agile Softwareprozesse daher als iterativ und inkrementell beschrieben werden, wobei die Prozessstrukturen und der Dokumentationsgrad in agilen Projekten weniger stark ausgeprägt sind. Beide Modelle binden den Kunden frühzeitig ein. Die Projektsteuerung ist beim Unified Process stärker hierarchisch geprägt, während bei agilen Prozessen die Selbstorganisation des Entwicklungsteams im Vordergrund steht.

2.2 Übertragung prozessorientierter Kalkulationsprinzipien auf agile Projekte

In der Literatur werden eine Vielzahl von Vorschlägen zur Kalkulation von Softwareprojekten gemacht (Burghardt 2012, S. 194 ff.; Kitchenham und de Neumann 1990), besonders bekannt ist das COCOMO-Modell von Boehm (Boehm 1984; Boehm et al 2000). Bei allen Vorschlägen steht eine Aufwandsschätzung im Mittelpunkt, die häufig von der Schätzung unabhängiger Projektgrößenmerkmale auf den Gesamtaufwand des Projektes in Geldeinheiten oder Personentagen führt. Teilweise können dabei Projektbesonderheiten, z. B. deren Komplexität oder die Erfahrung des Entwicklungsteams, in der Berechnung berücksichtigt werden (Sommerville 2010, S. S. 636 ff.).

Für die erfolgreiche Abwicklung eines Softwareprojektes reicht allerdings eine Kostenschätzung alleine nicht aus – benötigt wird ein Instrument zur laufenden Steuerung und Überwachung des Projektes. Dies kann nur gelingen, wenn sich die dem Softwareprojekt zugrundeliegende Prozessstruktur im Kalkulations- und Steuerungsverfahren widerspiegelt. Für Softwareentwicklungen auf der Grundlage des Unified Process stellt dafür die Übertragung der Prozesskostenrechnung (Horváth und Mayer 2011; Kaplan et al 2011; Kaplan und Cooper 1999) eine Lösungsmöglichkeit dar, denn diese besitzt strukturelle Analogien zum Vorgehensmodell (Baumeister und Ilg 2004).

Je nach Projektphase eines auf dem Unified Process aufbauenden Projektes können unterschiedliche Arten an Iterationen erwartet werden: Während in der Ausarbeitungsphase (Inception) bspw. verstärkt von Aufgaben in der Geschäftsprozessmodellierung oder dem Anforderungsmanagement auszugehen ist, dominieren in der Konstruktionsphase (Construction) Iterationen mit Implementierungs- und Testtätigkeiten (Kroll und Kruchten 2003; Larman 2002). Aus abgeschlossenen Projekten können nun ähnliche Iterationen zu sogenannten Iterationstypen zusammengefasst werden, deren Kosten sich aufgrund der ähnlichen Zusammensetzung der in den Iterationen notwendigen Prozessschritte gut schätzen lassen.

Ein nach Iterationstypen strukturiertes Beispielprojekt zeigt Abb. 2. Die in den Spalten dargestellten Iterationen sind nach ihrem Iterationstyp beschrieben, bspw. besteht die Konstruktionsphase aus den Iterationen der Typen k1, k2 und k3. Die zeitlich aufeinanderfolgenden Iterationen werden auch als dynamische Perspektive des Unified Process bezeichnet. Die Zeilen dagegen bilden die statische Struktur des Prozesses, sie bestehen aus den sogenannten Disziplinen, welche die Tätigkeiten innerhalb der Iterationen beschreiben. In jeder Iteration kommen alle Disziplinen vor, allerdings in unterschiedlicher Intensität  (Jacobson et al. 1999; Kroll und Kruchten 2003; Larman 2002).

Zur Erhöhung der Verwendbarkeit historischer Iterationsdaten für die Schätzung neuer Projekte werden diese hinsichtlich Iterationsdauer und Anzahl der beteiligten Personen (Vollzeitäquivalente) normiert (Baumeister und Ilg 2013) und in der Projektkalkulation entsprechend skaliert (Abb. 3). Für jede geplante Iteration wird zunächst der dem geplanten Entwicklungsschritt am ehesten entsprechende Iterationstyp aus einer Datenbank gewählt. Zusammen mit der für das Projekt zu definierenden Preisstruktur und der in der Iteration eingesetzten Anzahl an Entwicklern kann der Preis einer normierten Iteration aus den hinterlegten Daten errechnet werden. Iterationspreis und Vollzeitäquivalente verhalten sich dabei aufgrund iterationsbezogener Fixkosten nicht direkt proportional – in der Analyse wird der Zusammenhang über eine Regressionsanalyse ermittelt (Baumeister und Ilg 2013). Der Preis der normierten Iteration ist mit der Iterationsdauer zu multiplizieren und liefert so die geplanten Iterationskosten, welche noch um eventuelle direkte Projektkosten zu ergänzen sind. Eine Erweiterung um phasenbezogene direkte Kosten ist ebenso denkbar wie die schrittweise Verfeinerung der Kalkulation bei der Gewinnung zusätzlicher Projektinformationen, insbesondere in den Phasen Vorbereitung und Ausarbeitung (Abb. 3).

Im Vergleich zu herkömmlichen Kalkulationsverfahren erfordert eine prozessorientierte Vorgehensweise Annahmen über die erforderlichen Iterationstypen eines geplanten Softwareprojektes, welche ein erfahrener Softwareentwickler aber leichter schätzen sollte als sonst übliche Komplexitätsindikatoren, bspw. Anzahl Codezeilen, Bildschirmmasken oder Schnittstellen. Als großer Vorteil stellt sich die strukturelle Ähnlichkeit des Kalkulationsverfahrens zum Vorgehensmodell heraus, welche die Grundlage für wichtige betriebswirtschaftliche Anwendungen darstellt, bspw. die projektbegleitende Kalkulation (Baumeister und Ilg 2004), die mehrdimensionale Abweichungsanalyse (Baumeister und Ilg 2010) oder das laufende Projektcontrolling (Baumeister und Ilg 2013).

Agile Softwareprojekte kennen im Unterschied zum Unified Process keine differenzierte Projektstruktur. Die bspw. in der agilen Methode Scrum als Sprints bezeichneten Iterationen sind von konstanter Dauer und werden von Teams in fester Zusammensetzung bearbeitet. Iterationskosten sind damit gut kalkulierbar, wie bei der Kalkulation des Unified Process können prozessorientiert standardisierte Iterationstypen hergeleitet werden. Im agilen Paradigma reduzieren sich diese aber im Extremfall auf einen einzigen normierten Iterationstyp, der inhaltlich nicht weiter differenziert wird. Denkbar wäre allenfalls die Berechnung unterschiedlicher Iterationstypen, sofern sich die Personalstruktur und damit die durchschnittlichen Personalkosten pro Mitarbeiter wesentlich zwischen Projekten unterscheiden. Keine Rolle spielen dagegen Einflussfaktoren wie bspw. Komplexität oder Erfahrung des Entwicklerteams, wie diese bspw. bei COCOMO II verwendet werden (Boehm et al 2000) – sie schlagen sich in der Schätzung der Gesamtzahl der notwendigen Iterationen nieder und nicht in den Kosten einer einzelnen Iteration (Abb. 4).

In der Bestimmung der Gesamtzahl der notwendigen Iterationen liegt denn auch ein Kernproblem agiler Prozesse, deren Ziel Schwaber treffend als die „Kunst des Möglichen“ (Schwaber 2004, S. 147) beschreibt und die keinen Anhaltspunkt bieten, wie eine vorher festgelegte Spezifikation zu einem festgelegten Preis umzusetzen ist. Zunächst werden die Projektinhalte des agilen Projektes geschätzt. Dies erfolgt regelmäßig in Teams, bspw. in Form des Planning Poker oder der Magic Estimation (Opelt et al. 2012, S. 19 ff., 49 f.). Ergebnis ist eine in Storypoints gemessene Projektgröße, eine Dimension, die zu Beginn des Schätzverfahrens für einen möglichst bekannten Ausschnitt des Projektes festgelegt wird und dann die Bezugsbasis für die Schätzung der anderen Komponenten bildet. Die Gesamtzahl der Storypoints des Projektes ist in Relation zu der vom jeweiligen Team üblicherweise in einer Iteration erzielbaren Storypoints zu setzen, woraus sich die Projektdauer ergibt. Durch die teambasierte Schätzung soll einerseits die Akzeptanz gewährleistet, andererseits die Zuverlässigkeit der Schätzung sichergestellt werden (Opelt et al. 2012, S. 21).

3.
Projektabbruch als ein Optionselement agiler Softwareprojekte

Vertragliche Vereinbarungen wie die Lieferung einer Software zum Festpreis sind zwar prinzipiell möglich, sie bieten aber nur eine Scheingenauigkeit für den Kunden (Oestereich 2006; Roock und Wolf 2009; Wolf und Bleek 2010), denn mögliche Änderungen der im Voraus kaum exakt zu spezifizierenden Anforderungen machen den ursprünglichen Festpreis regelmäßig obsolet. Beharrt dagegen der Kunde auf dem Festpreis, ist eine Reduktion von Inhalten wahrscheinlich, die der Anbieter der Software möglicherweise auf eine für den Kunden zunächst schwer erkennbare Weise vornehmen wird, bspw. durch eine Reduktion von Qualitätskontrollen. Daher wurden zum Festpreisvertrag alternative Vertragsmodelle entwickelt, eine Übersicht dazu geben Oestereich und Weiss (Oestereich 2006; Oestereich und Weiss 2007, S. 389 ff.). Besonders propagieren Opelt u. a. das agile Festpreisverfahren (Opelt et al. 2012). Es zeichnet sich unter anderem durch eine intensive Einbeziehung des Kunden aus, durch eine Risiko- und Chancenteilung sowie durch die vertragliche Vereinbarung eines Scope-Governance-Prozesses. Der Vertragstyp ist für agile Softwareprojekte geeignet, da er dem Kunden eine Neupriorisierung erlaubt, ggf. auch die Aufnahme neuer Projektinhalte zu Lasten nicht mehr be-nötigter Inhalte. Dabei entstehen keine Mehrkosten, sofern mit den Änderungen kein Zusatzaufwand verbunden ist. Eine Änderung bzw. Repriorisierung erfordert dabei ein abgestimmtes Vorgehen der Vertragsparteien sowie die Anwendung der gleichen Schätzverfahren wie zu Projektbeginn (Oestereich und Weiss 2007, S. 400 ff.).

Agile Entwicklungsprinzipien (Beck et al. 2001; Larman 2003, S. 28 ff.) verlangen, dass jede Iteration Nutzen stiftet. Kann trotz möglicher Repriorisierung für künftige Iterationen nur ein negativer Nettonutzen erwartet werden, wird man das Projekt abbrechen wollen. Diese Möglichkeit, ein Projekt bei ungünstiger Nutzenentwicklung vorzeitig abzubrechen, eröffnet die agile Softwareentwicklung im Gegensatz zur klassischen. Der dadurch eröffneten Handlungsflexibilität, die als Abbruchsoption interpretierbar ist, kommt ein eigener ökonomischer Wert zu, der mit dem Realoptionsansatz ermittelt werden kann. Dieser ist in den 1980er-Jahren entstanden (Hartmann und Hassan 2006, S. 343) und differenziert zwischen folgenden Grundtypen von Realoptionen: Abbruchs-, Flexibilitäts-, Aufschubs- und Erweiterungs- oder Wachstumsoption. Der Inhaber der Abbruchsoption besitzt das Recht, das zugrundeliegende Gut zu einem bestimmten Preis vorzeitig oder zu einem bestimmten Zeitpunkt zu verkaufen, Flexibilitätsoptionen erlauben beispielsweise alternative Nutzungsmöglichkeiten einer Anlage, Aufschubsoptionen -ermöglichen es, Projektentscheidungen zur Verbesserung der Informationslage hinauszuzögern, Erweiterungsoptionen gestatten, zu einem späteren Zeitpunkt bestehende Investitionsprojekte zu erweitern (Brealey et al. 2010, S. 284 ff.; Volkart 2011, S. 459 ff.).

Die Übertragung des aus der Bewertung von Finanz-optionen bekannten Black-Scholes-Verfahrens (Black und Scholes 1973) kann zur Bewertung von Realoptionen angewendet werden, verbreiteter ist jedoch der Binomialansatz (Cox et al. 1979). Dabei darf die Berechnung allerdings nicht darüber hinwegtäuschen, dass die Bestimmung wertrelevanter Parameter (insbesondere Wert des Underlying, Laufzeit, Volatilität) im Realoptionskontext grundsätzlich erschwert ist (Volkart 2011, S. 463 f.).

Literatur

Baumeister A, Ilg M (2004) Entwicklungsbegleitende Kalkulation von Softwareprojekten nach dem Unified Process. Wirtschaftsinformatik 46(3):188–195. doi: 10.1007/BF03250936

Baumeister A, Ilg M (2013) Financial Management and Control of Iterative Software Processes. Proceedings of the Annual International Conference on Accounting and Finance AF 2013, Bangkok, S. 33-38

Baumeister A, Ilg M (2010) Activity Driven Budgeting of Software Projects. IJHCITP 1(4):14-30. doi: 10.4018/jhcitp.2010100102

Beck K (1999) Embracing Change with Extreme Programming. Computer 32(10):70–77. doi: 10.1109/2.796139

Beck K (2002) Test Driven Development By Example. Addison-Wesley, Amsterdam

Beck K, Beedle M, Van Bennekum A, Cockburn A, Cunningham W, Fowler M, Grenning J, Highsmith J, Hunt A, Jeffries R, Kern J, Marick B, Martin CR, Mellor S, Schwaber K, Sutherland J, Thomas D (2001) Manifesto for Agile Software Development. http://agilemanifesto.org/. Abruf am 2012-08-14

Black F, Scholes M (1973) The Pricing of Options and Corporate Liabilities. The Journal of Political Economy 81(3):637–654

Boehm BW (1984) Software Engineering Economics. Software Engineering, IEEE Transactions on SE-10(1):4–21. doi: 10.1109/TSE.1984.5010193

Boehm BW, Abts C, Brown AW, Chulani S, Clark BK, Horowitz E, Madachy R, Reifer D, Steece B (2000) Software Cost Estimation with Cocomo II. Prentice Hall, Upper Saddle River, NJ

Brealey R, Myers S, Allen F (2010) Principles of Corporate Finance, 10. Aufl. McGraw-Hill, New York, NY

Burghardt M (2012) Projektmanagement: Leitfaden für die Planung, Überwachung und Steuerung von Projekten, 9. Aufl. Publicis Publishing, Erlangen

Charette RN (2005) Why software fails. IEEE Spectrum 42(9):42-49. doi: 10.1109/MSPEC.2005.1502528

Cockburn A (2006) Agile Software Development: The Cooperative Game, 2. Aufl. Addison-Wesley, Upper Saddle River, NJ

Cox JC, Ross SA, Rubinstein M (1979) Option pricing: A simplified approach. Journal of Financial Economics 7(3):229-263. doi: 10.1016/0304-405X(79)90015-1

Hartmann M, Hassan A (2006) Applications of real options analysis for pharmaceutical R&D project valuation – Empirical results from a survey. Research Policiy 35(3):343-354

Hesse W (2003) Dinosaur meets Archaeopteryx? or: Is there an alternative for Rational’s Unified Process? Software and Systems Modeling 2(4):240–247. doi: 10.1007/s10270-003-0033-y

Horváth P, Mayer R (2011) Was ist aus der Prozesskostenrechnung geworden? ZfCM 55(2):5–10. doi: 10.1365/s12176-012-0327-4

Ilg M, Baumeister A (2011) Performance Management in Software Engineering. IJITPM 1(2):1–18

Jacobson I, Booch G, Rumbaugh J (1999) The Unified Software Development Process. Addison-Wesley Longman, Amsterdam

Kaplan RS, Atkinson AA, Matsumura EM, Young SM (2011) Management Accounting, 6. Aufl. Pearson Education, Harlow

Kaplan RS, Cooper R (1999) Prozesskostenrechnung als Managementinstrument. Campus, Frankfurt

Kitchenham BA, De Neumann B (1990) Cost Modelling and Estimation. In: Rook P (Hrsg) Software Reliability Handbook. Elsevier Applied Science, London, S 333–376

Kroll P, Kruchten P (2003) The Rational Unified Process Made Easy: A Practitioner’s Guide to the RUP. Addison-Wesley, Amsterdam

Kruchten P (2003) Rational Unified Process: An Introduction, 3. Aufl. Addison-Wesley, Amsterdam

Larman C (2003) Agile and Iterative Development: A Manager’s Guide. Addison-Wesley, Amsterdam

Larman C (2002) Applying UML and Patterns: an introduction to object-oriented analysis and design and the Unified Process, 2. Aufl. Prentice-Hall, Upper Saddle River, NJ

Larman C, Basili VR (2003) Iterative and incremental developments a brief history. Computer 36(6):47–56. doi: 10.1109/MC.2003.1204375

Ludewig J, Lichter H (2010) Software Engineering: Grundlagen, Menschen, Prozesse, Techniken, 2. Aufl. dpunkt, Heidelberg

Oestereich B (2006) Der agile Festpreis und andere Preis- und Vertragsmodelle. OBJEKTspektrum 13(1):29–32

Oestereich B, Weiss C (2007) APM – Agiles Projektmanagement: Erfolgreiches Timeboxing für IT-Projekte. dpunkt, Heidelberg

Opelt A, Gloger B, Pfarl W, Mittermayr R (2012) Der agile Festpreis: Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge. Hanser, München

Poppendieck M, Poppendieck T (2006) Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, Boston

Rasmusson J (2010) The Agile Samurai: How Agile Masters Deliver Great Software. Pragmatic Bookshelf, Raleigh, NC

Roock S, Wolf H (2009) Agile Projekte beauftragen. OBJEKTspektrum 16 (Agility):1–3

Royce W (1970) Managing the development of large software systems: concepts and techniques. Proceedings of the IEEE Wescon. S 328–338

Schwaber K (2004) Agile Project Management with Scrum. Microsoft Press, Redmond, WA

Schwaber K (1995) SCRUM Development Process. Proceedings of the 10th Annual ACM Conference on Object Oriented Programming Systems, Languages, and Applications (OOPSLA). S 117–134

Schwaber K, Beedle M (2008) Agile Software Development with SCRUM. Pearson Education, Harlow

Sommerville I (2010) Software Engineering, 9. Aufl. Addison-Wesley, Amsterdam

Volkart R (2011) Corporate Finance, 5. Aufl. Versus, Zürich

Wolf H, Bleek W-G (2010) Agile Softwareentwicklung, 2. Aufl. dPunkt, Heidelberg

Autoren:

  • Univ.-Professor Dr. Alexander Baumeister

    Univ.-Professor Dr. Alexander Baumeister, Professor für Allgemeine Betriebswirtschaftslehre an der Universität des Saarlandes. Direktor des Saarbrücker Instituts für Controlling. Foto: privat

  • Professor (FH) Dr. Markus Ilg

    Professor (FH) Dr. Markus Ilg, Hochschullehrer für Controlling, Fachbereichsleiter Wirtschaft und Studiengangsleiter der betriebswirtschaftlichen Masterstudiengänge an der Fachhochschule Vorarlberg in Dornbirn, Österreich. Foto: privat