Entwicklungsbegleitende Kalkulation von Softwareprojekten nach dem Unified Process; Affinity-Costing for Software Development Projects based on the Unified Process;

1 Besonderheitender Kalkulationvon Softwareentwicklungen

Eine moglichst exakte Kostenprognosevon Softwareentwicklungen bereits in fru-hen Phasen des Entwicklungsprozesses istfur zahlreiche Einsatzbereiche wie etwa beiMake-or-Buy-Entscheidungen, zur Ange-botspreisstellung bei Ausschreibungenoder auch zur Ermittlung eines Projekt-budgets eine entscheidende Informations-basis. Allerdings ist sie mit besonderenSchwierigkeiten behaftet:– Die Mengenstruktur der Kalkulation ist

zu Beginn der Entwicklung meist weit-gehend unbekannt. Je nach Innovations-grad der zu entwickelnden Softwaremuss daher fur Vorkalkulationen zu-nachst oftmals hilfsweise auf Schatzver-fahren zuruckgegriffen werden, bei de-nen die Kostenprognose aus bereits

bekannten, ahnlichen Entwicklungspro-jekten abgeleitet wird.

– Im Entwicklungsprozess werden an denEntwicklungsfortschritt angepasste Kos-tenprognosen benotigt, um projekt-begleitende Anpassungsentscheidungenzu unterstutzen. So konnten die Kon-kretisierung der Mengenstruktur imEntwicklungsablauf und damit verander-te Kostenprognosen z. B. zu einer Revi-dierung ursprunglicher Outsourcingent-scheidungen oder zu Anpassungen derProjektbudgets fuhren. Entwicklungs-begleitende Kostenprognosen erfordernhierzu eine enge Informationsverzah-nung des Kalkulations- und Entwick-lungsbereichs. Somit treten die typischenProbleme jeder entwicklungsbegleiten-den Kalkulation auf.

– Bei der Softwareentwicklung ist die Ge-meinkostenproblematik von besondererBedeutung. Zwar schwankt je nach Artdes Projekts der Anteil der Gesamtkos-ten aus Leistungen typischer Ge-meinkostenbereiche mitunter betracht-lich [Fure94, 24ff.]. Allerdings kannselbst ein hoher Anteil an Einzelkostenauf der Projektebene, z. B. durch Out-sourcing von Entwicklungsleistungenoder durch Inanspruchnahme von Bera-tungsleistungen, nicht verursachungs-gerecht auf die Kostentrager zuge-rechnet werden, wenn es sich nichtohnehin um eine kundenindividuelleSoftwareentwicklung handelt.

Softwareentwicklungen liegen aber haufigzur Sicherung des Projekterfolgs Vor-gehensmodelle zugrunde. Dazu gehort das

WIRTSCHAFTSINFORMATIK 46 (2004) 3, S. 188–195

Die Autoren

Alexander BaumeisterMarkus Ilg

Dr. Alexander BaumeisterDipl.-oec. Markus IlgUniversitat HohenheimLehrstuhl Controlling (510 L)70593 Stuttgart0711 459-3935, -3911{baumeist | milg}@uni-hohenheim.de

Entwicklungsbegleitende Kalkulationvon Softwareprojektennach dem Unified Process

Kernpunkte

Fur das IT-Management sind fruhzeitige und prazise Kostenprognosen von Softwareentwick-lungen fur Projektentscheidungen von zentraler Bedeutung. Fur Softwareprojekte nach demUnified Process wird dazu eine prozesskostenrechnerische �hnlichkeitskalkulation ent-wickelt:

& Fur Vorkalkulationen des Projektbudgets werden phasenbezogene, ahnlichkeitsbestimmteCost-Driver-Raten der Prozesskostenrechnung eingesetzt.

& Fur die entwicklungsbegleitende Kostenkontrolle werden die Prozesskosten mit der Kon-kretisierung der Projektablaufe zunehmend feiner nach den Iterationen des Unified Pro-cess differenziert.

Zentrale Vorteile der vorgeschlagenen Methode sind:

& Kostenprognosen z. B. fur die Angebotsstellung oder Outsourcing-Entscheidungen wer-den mit deutlich hoherem zeitlichen Vorlauf ermoglicht.

& Die oftmals hohen Gemeinkostenanteile von Softwareprojekten lassen sich verursa-chungsgerechter zurechnen.

Stichworte: Unified Process, iterative Softwareentwicklung, IT-Management, Kalkulation,Vorkalkulation, Prozesskostenrechnung, Projektbudget

WI – Schwerpunktaufsatz

aktuell verstarkt diskutierte Modell desUnified Process [JaBR99], dessen Haupt-merkmale eine iterative Durchfuhrung vonProzessen bestimmter Disziplinen sowiedie schrittweise Konkretisierung einesGrobplans in detaillierte Einzelplane sind.So konnen ausgehend von ersten standard-maßigen Kostenschatzungen im Zeitablaufprazisierte Kostenprognosen auf Basis de-taillierterer Kenntnisse der Projektanforde-rungen gewonnen werden. Wenn eine ge-wisse Prozessstandardisierung zu erwartenist, bietet sich fur die Kalkulation die Me-thodik der Prozesskostenrechnung an, de-ren Mengengerust sich im Entwicklungs-ablauf auf der Basis des Unified Processzunehmend konkretisieren lasst.

Ziel dieses Beitrags ist es, die Eignungder Prozesskostenrechnung fur die Vorkal-kulation und die begleitende Kalkulationvon Softwareentwicklungen auf derGrundlage des Unified Process zu ana-lysieren. Dazu werden in Kapitel 2 dieGrundlagen des Unified Process vor-gestellt. In Kapitel 3 wird der Stand derKalkulation von Softwareentwicklungengekennzeichnet und darauf aufbauend eine�hnlichkeitskalkulation vorgeschlagen.Kapitel 4 entwirft damit die Einsatz-moglichkeiten der Prozesskostenrechnungbei der Kalkulation von Softwareentwick-lungen. Kapitel 5 fasst die zentralen Ergeb-nisse zusammen.

2 Abwicklungvon Softwareprojektennach dem Unified Process

2.1 Iterative Softwareentwicklungals Kernbestandteildes Unified ProcessDie Entwicklung eines Softwaresystemsstellt eine komplexe Aufgabe dar, bei derdie Tatigkeiten meist zahlreicher Personenzu koordinieren sind. Deshalb werdenSoftwareentwicklungen regelmaßig auf derGrundlage eines Vorgehensmodells durch-gefuhrt. Das aktuell zunehmend diskutierteVorgehensmodell des Unified Process[JaBR99; Kruc99; KrKr03] soll dabeiSchwachstellen anderer Vorgehensmodellevermeiden.1 Im weit verbreiteten Wasser-fallmodell werden beispielsweise Starrheit,mangelnde Einbeziehung der spateren Be-nutzer oder die Gefahr, in fruhen Entwick-lungsphasen begangene Fehler erst spat zuentdecken, als Problemfelder genannt[Vers00, 29]. Wenngleich der Unified Pro-cess von speziellen Entwurfsmethoden

unabhangig ist, wird er vor allem beiEntwicklungsprojekten diskutiert, in de-nen die Unified Modelling Language alsModellierungssprache eingesetzt wird[BoRJ99, 501]. Grundlage des Unified Pro-cess sind mehrere bewahrte Techniken derSoftwareentwicklung, insbesondere– die iterative Softwareentwicklung,– der Einsatz objektorientierter Techniken

in Analyse, Design und Programmie-rung,

– die fruhzeitige Ausarbeitung von Sys-temkomponenten, deren Beitrag zumGesamtsystem als besonders hoch oderdie als besonders riskant eingeschatztwerden,

– der Einsatz visueller Techniken zurSoftware-Modellierung,

– die permanente Einbindung der kunfti-gen Benutzer, z. B. durch Anwender-tests, und ggf. die fruhzeitige Korrekturvon Fehlspezifikationen,

– ein systematisches Anforderungsmana-gement und

– ein kontrolliertes �nderungsmanage-ment [Kruc99, 17ff.; Larm02, 18f.].

Zentrales Merkmal des Unified Process istdas Prinzip der iterativen Softwareent-wicklung. Ergebnis jeder einzelnen Itera-tion ist stets ein getestetes und lauffahigesSystem, das mit zunehmender Iterations-zahl lediglich umfassender, leistungsfahigerund facettenreicher wird. Das Vorgehen istnicht mit Prototyping zu verwechseln, dadie Iterationsergebnisse Teile des spateren

Produktionssystems darstellen. Entschei-dend ist dabei die fruhzeitige Beurteilungdes realisierten Teilsystems durch die kunf-tigen Benutzer und die damit ermoglichteKorrektur eventueller Fehlspezifikationen.Die fur das Wasserfallmodell typische de-taillierte Anforderungsanalyse und die da-mit verbundene vollstandige Anforde-rungsspezifikation des Gesamtsystems alserster Schritt der Softwareentwicklung ent-fallt. Stattdessen beschrankt sich der iterati-ve Ansatz in fruhen Iterationen auf eineGrobspezifikation des Systems, die zuneh-mend weiter verfeinert wird. Im Gegensatzzu anderen Vorgehensmodellen wird be-wusst auf detaillierte Kosten- und Zeit-schatzungen in fruhen Projektphasen ver-zichtet, da diese mangels Kenntnis dertatsachlichen Anforderungen zu diesemZeitpunkt wenig verlasslich erscheinen[Larm02].

2.2 Phasenorientierter Aufbaudes Unified Process

Entwicklungsprojekte nach dem UnifiedProcess lassen sich statisch und dynamischstrukturieren (vgl. Bild 1). In der dyna-mischen Sichtweise wird der gesamte Ent-wicklungsprozess in die Phasen Vorberei-tung, Ausarbeitung, Konstruktion und�bergang untergliedert. In der Phase Vor-bereitung werden ein gemeinsames Ver-standnis uber die wichtigsten Projektziele


Entwicklungsbegleitende Kalkulation von Softwareprojekten nach dem Unified Process 189

mit Auftraggebern und kunftigen Benut-zern gesucht, die wichtigsten Anwen-dungsfalle (use cases) grob skizziert sowiezentrale Restriktionen ermittelt. Die Gro-ßenordnung des Projekts wird in zeitlicherund finanzieller Hinsicht beschrieben, ggf.werden fur besonders zentrale oder unter-nehmungskritische Aspekte auch Prototy-pen erstellt. Die Ergebnisse bilden die Ent-scheidungsgrundlage fur die Fortsetzungoder den Abbruch des Projekts.In der Ausarbeitungsphase beginnt die

iterative Softwareentwicklung in kurzenZyklen. In typischerweise zwei bis vier Ite-rationen werden die Projektziele uber-arbeitet und verfeinert, die wesentlichenKomponenten der Systemarchitektur ange-legt und besonders riskante Projektteilezumindest in Grundzugen gelost. Ziel istzunachst die Konkretisierung der als kri-tisch eingeschatzten Anwendungsfalle. Me-thodisch kommen hierbei vor allem objekt-orientierte Analysetechniken zum Einsatz.Ist wahrend einer Iteration absehbar, dassder fur die Iteration geplante Endterminnicht zu halten ist, werden weniger wichti-ge Aufgaben aus der aktuellen Iteration aufspatere Zyklen verschoben. Auf derGrundlage der zum Ende der Ausarbei-tungsphase detailliert vorliegenden Kosten-und Zeitschatzungen wird erneut uber dieFortsetzung des Projekts entschieden.Wahrend der Konstruktionsphase findet

der Hauptteil des Herstellungsprozessesder Software statt, in dem alle verbleiben-den Produktkomponenten realisiert undgetestet werden. Die bereits in der Aus-arbeitungsphase zumindest fur einfacheSzenarien realisierten kritischen System-bestandteile werden um die fehlenden Sze-narien erganzt. Ergebnis der Konstrukti-onsphase ist das Softwareprodukt samtBenutzerhandbuch und Releasebeschrei-bung.In der Phase �bergang wird das fertig

gestellte Softwareprodukt beim Benutzereingefuhrt und in die EDV-Landschaft derUnternehmung integriert, z. B. durch An-bindung an bestehende Datenbanken. Furunternehmungskritische Applikationen istzunachst ein Parallelbetrieb mit bestehen-den Altsystemen ratsam. Systemeinfuhrun-gen durch Workshops oder Training amArbeitsplatz erhohen die Benutzerakzep-tanz. Oft wird das entwickelte Software-produkt nicht als Ganzes an die Benutzerubergeben: Sofern einzelne Systemteile einisoliert funktionsfahiges Teilsystem einergroßeren Anwendung darstellen, z. B. dieLagerverwaltung eines Warenwirtschafts-systems, empfiehlt sich eine schrittweiseEinfuhrung [EsMe03; Larm02; KrKr03].

2.3 Strukturierungder Iterationen im Unified Process

Die Phasen Ausarbeitung, Konstruktionund �bergang werden ihrerseits innerhalbeines Projekts durch eine oder mehrere Ite-rationen gleicher Dauer strukturiert. JedeIteration stellt einen vollstandigen Ent-wicklungszyklus dar, der mit der Fertig-stellung einer selbstandig ablauffahigenTeilmenge des geplanten Endprodukts en-det. In einer Iteration sind daher alle zurErstellung eines getesteten und ablauffahi-gen Systems notwendigen Aktivitaten, wel-che im Unified Process in sechs Kerndis-ziplinen sowie drei unterstutzendeDisziplinen gruppiert werden, durch-zufuhren. Aktivitaten bilden zusammenmit Rollen, Artefakten und Workflows diestatische Sicht des Unified Process[KrKr03].

Typische Aktivitaten der KerndisziplinGeschaftsprozessmodellierung sind beispiels-weise die Analyse der Organisationsstrukturund die Beschreibung der angestrebten Ziele.Im Anforderungsmanagement werden An-forderungen als Orientierungspunkt samt-licher Aktivitaten im Unified Process – ggf.durch Anwendungsfalldiagramme unter-stutzt – systematisch erfasst, dokumen-tiert und eventuelle �nderungen uber-wacht. Die Aktivitaten der Disziplin Ana-lyse und Design dienen der �bersetzungder Anforderungen in die technische Spe-zifikation des zu realisierenden Systems.Im Vordergrund steht die Modellierungmit der Unified Modelling LanguageUML. In der Implementierung werdendie Programme entwickelt, zu Teilsyste-men zusammengefugt und schließlich imGesamtsystem integriert. Die Verifikationdes Zusammenspiels der Komponentensowie die �berprufung des Systems aufdas Anforderungsverhalten ist Gegenstandder Test-Disziplin. Installation, Mitarbei-tertraining, die Einrichtung von Benutzer-hotlines oder die Datenubernahme aus Al-tapplikationen gehoren zur KerndisziplinVerteilung. Aufgabe der unterstutzendenDisziplin Konfigurationsmanagement istdie Verwaltung der Systemkomponenten,vorgenommener �nderungen sowie die�berwachung der Auswirkungen dieser�nderungen. Die Grobplanung des Ge-samtprojekts, die Detailplanung der je-weils nachsten Iteration, die Bereitstellungund Einfuhrung entsprechender Planungs-instrumente und die �berwachung derProjektplane sind Beispiele fur Aktivitatenim Projektmanagement. Die unterstutzen-de Disziplin Umgebung, die besonders inder Vorbereitungsphase von Bedeutung

ist, beinhaltet die Bereitstellung der infor-mationstechnischen Infrastruktur fur dasEntwicklungsteam, z. B. die Auswahl undEinrichtung der Entwicklungswerkzeuge[Vers00, 52ff.; Kruc99, 109ff.].Wahrend in fruhen Projektphasen der

Schwerpunkt auf Aktivitaten der Diszipli-nen Geschaftsprozessmodellierung, Anfor-derungsmanagement sowie Analyse undDesign liegt, verschiebt sich dieser in derKonstruktionsphase auf die Implementie-rung und den Test. In der �bergangsphasesteht die Disziplin Verteilung im Mittel-punkt. In der in Bild 1 markierten Iteration5 haben beispielsweise die Aktivitaten derGeschaftsprozessmodellierung im Ver-gleich zu den Disziplinen Implementierungund Test nur noch eine geringe Bedeutung.

3 Einsatzbereicheder Prozesskostenrechnungfur die Produktkalkulation

3.1 Stand der Kalkulationvon Softwareentwicklungen

Kalkulationsansatze fur Softwareentwick-lungen lassen sich in algorithmische, ver-gleichende und kennzahlenbasierte Metho-den einteilen [Burg02, 154ff.]. Haufigorientieren sich die Ansatze an traditionel-len Standardphasen im Entwicklungsablauf(Fachkonzeption, Realisierungsspezifika-tion, Softwareentwurf, Programmierungund Test) [DeMe96, 257ff.]. DetaillierteAnsatze beziehen in die Kostenschatzungauf Basis ahnlicher, bereits realisierter Ent-wicklungsprojekte zahlreiche Eigenschafts-auspragungen der anstehenden Software-entwicklung mit ein [Burg02, 162; Seib98,340ff.]. Dazu gehort z. B. das parameter-orientierte COCOMO II (ConstructiveCost Model), das 17 multiplikativ ver-knupfte Kosteneinflussgroßen berucksich-tigt [Boeh00, 12ff.], oder PRICE S. Dabeikommt der betriebsspezifischen Kalibrie-rung der Schatzfunktionen, wenn sie wieim COCOMO II aus betriebsubergreifen-den Erfahrungsdatenbanken bestimmt wer-den, entscheidende Bedeutung fur diePrognosegute bei [Seib03, 28]. Von vorn-herein betriebsindividuelle Prozesskosten-kalkulationen, die aufgrund der ohnehinzweckmaßigen Prozessuntergliederung zurErmittlung der Mengenstruktur nahe lie-gen, sind bislang wenig verbreitet. Gemein-sames Problem vieler Ansatze ist zudem,dass aufgrund der erforderlichen Progno-separameter Kostenschatzungen erst in ei-


190 Alexander Baumeister, Markus Ilg

nem fortgeschrittenen Projektstadiummoglich sind [Burg02, 164]. Damit werdenzentrale Projektgrundentscheidungen wiedie Angebotspreisabgabe oder die Ent-wicklungsaufnahme nur unzureichend un-terstutzt.

3.2 �bertragungder �hnlichkeitskalkulationbei der Entwicklung von Sachguternauf die Softwareentwicklung

Ziel der �hnlichkeitskalkulation fur eineNeuentwicklung von Sachgutern ist dieHerleitung der Kostenprognose mithilfeder Daten eines moglichst ahnlichen, be-reits bekannten Produkts. Die Hypothesedabei ist, dass sich die Kosten bzw. Guter-verbrauche des bekannten und auch desneuen Produkts in einem stabilen Zu-sammenhang weitgehend auf eine be-stimmte Anzahl gemeinsamer kosten- bzw.verbrauchsbestimmender Einflussgroßenzuruckfuhren lassen. Diese bilden danndie Grundlage der Kostenprognose. Die�hnlichkeitssuche kann dabei an bereitsbekannte technische Vorgabewerte derKonstruktion ansetzen. Bei der Motoren-konstruktion konnten dies etwa die Ziel-kW-Leistung, der gewunschte Verbren-nungstyp und der Hubraum sein. Da sichdie Neuentwicklung je nach Art in einer,meistens jedoch in mehreren Produkt-eigenschaften unterscheiden wird, bietetsich der Einsatz statistischer Methoden furdie Herleitung der Anpassungskoeffizien-ten an, mit denen die Kosten bzw. Guter-verbrauche des bekannten Produkts aufdas Neuprodukt hochgerechnet werdenkonnen [Eisi97, 128ff.]. Sind die Anpas-sungskoeffizienten ermittelt, so kommtman zu ein- oder mehrvariabligen Kosten-funktionen als Grundlage der Kostenschat-zung. Bei der Motorenentwicklung wurdeman z. B. erwarten, dass die Kurzkalkulati-on eines neuen Motors zumindest die Leis-tung, den Verbrennungstyp und die Hub-raumzahl berucksichtigt. Werden dieentsprechenden Planwerte fur die identifi-zierten technischen Leistungsgroßen in diegewonnene Kostenfunktion eingesetzt, er-halt man eine erste Kostenschatzung, dieim Entwicklungsfortschritt nach Konkreti-sierung der Produktgestaltung entspre-chend zu uberarbeiten ist. Vorteil derSchatzung ist, dass sie ohne detaillierte In-formationen etwa uber das Mengengerustoder die Fertigungsmodalitaten des Pro-dukts auskommt. Diese zeigen sich erst alsErgebnis der Konstruktion, sodass zu Be-ginn des Entwicklungsprozesses eine

grundlegende Bottom-up-Kalkulation oh-nehin oftmals ausscheidet.Vergleicht man die Informationslage bei

der Sachguter- mit der Softwareentwick-lung, stellt man weitgehende �bereinstim-mungen fest, die daher auch zu ahnlichenVorgehensmodellen fuhren [Eisi97, 29ff.;ScFr93, 1110]. Dies betrifft zum einen dieInformationslage wahrend des Entwick-lungsprozesses: So wie sich bei Sachguterndas Wissen uber die Produktkomponentenmit dem Entwicklungsfortschritt konkreti-siert, sodass ein zunehmend genaueresMengengerust zur Bottom-up-Kalkulationeingesetzt werden kann, konkretisiert sichbei der iterativen Softwareentwicklungnach dem Unified Process beispielsweisedie Kenntnis uber die notwendige Art undAnzahl der Anwendungsfalle (use cases),Bildschirmmasken oder Programmmodule,die als Kosteneinflussgroßen in einer Vor-kalkulation oder entwicklungsbegleitendenKalkulation dienen konnen. Andererseitswerden im Unified Process Art und An-zahl der Iterationen in den Phasen Aus-arbeitung, Entwurf und �bergang bereitsin der Vorbereitungsphase geschatzt undspatestens zum Ende der Ausarbeitungs-phase detailliert festgelegt. Damit sind aberauch die Gesamtdauer des Projekts unddessen voraussichtlicher Personalbedarf inden einzelnen Phasen beschrieben. DieBerucksichtigung solcher zusatzlichenKennzahlen – zu denen z. B. auch die kos-tenbeeinflussende Wirkung der Personal-struktur gehoren kann – erhoht die Validi-tat einer �hnlichkeitskalkulation.Die Iterationen des Unified Process lo-

sen bestimmte Aktivitaten bzw. Prozesseinnerhalb der jeweiligen Disziplinen unddamit verbundene (Prozess-)Kosten aus.Da sich einzelne Softwareprojekte in derAnzahl und der Art der in der Entwick-lung benotigten Iterationen unterscheiden,konnten diese zentrale Kosteneinflussgro-ßen darstellen und als Mengengerust derKalkulation eingesetzt werden. Die not-wendige Art und Anzahl an Iterationenwird wiederum uber die Projekteigenschaf-ten bestimmt, die damit den Ausgangs-punkt der �hnlichkeitskalkulation dar-stellen. Aufgrund des mengenmaßigenZusammenhangs, den die Iterationen zwi-schen den Softwareeigenschaften und denAktivitaten herstellen, liegt es nahe, dieProzesskostenrechnung als methodischeGrundlage einer differenzierten Kalkula-tion einzusetzen. Vom formalen Aufbaufolgt dieser Ansatz der dynamischen Sicht-weise des Unified Process.

4 Kalkulationvon Softwareentwicklungenmit der Prozesskostenrechnung

4.1 Strukturder Prozessteilkostenrechnungals Kalkulationsgrundlagefur Softwareentwicklungen

Fur die Kalkulation von Softwareprojektenist die Prozesskostenrechnung als Teilkos-tenrechnung auszugestalten [TrBW03, 50f.,83ff.]. Die oftmals vorzufindende Unter-scheidung leistungsmengeninduzierter und-neutraler Prozesskosten beruht auf einerKostenspaltung nach der Variabilitat derKostenhohe in Abhangigkeit einer be-stimmten Bezugsgroße. Der Ansatz leis-tungsmengenneutraler Prozesskosten in derKalkulation kann also trotz einer moglicher-weise sehr detaillierten Prozessdifferenzie-rung zu Fehlentscheidungen fuhren, wie siegenerell bei einer Fixkostenschlusselung zuerwarten sind [GeBK00, 117].Eine Prozess(teil)kostenrechnung erfor-

dert zunachst die Identifizierung von Pro-zessen und deren zugehorigen Kosten.Geht man von einem klassisch gepragtenKostenrechnungssystem aus, so sind samt-liche Kostenstellen nach den in ihnen ab-laufenden Prozessen zu untersuchen. Da-bei kann sich eine Prozesskostenhierarchieetwa aus Haupt-, Bereichs- oder Teilpro-zessen ergeben. Durch Prognose von Plan-prozessmengen und -kosten lassen sichschrittweise die Prozesskosten je Prozess-durchfuhrung gewinnen. Diese konnen inder Kalkulation durch Multiplikation mitder jeweils in Anspruch genommenen Pro-zessmenge eines Kalkulationsobjekts zurErganzung direkt zugerechneter Kosten-positionen angesetzt werden. Allerdingsmacht die mitunter sehr hohe Anzahl be-trieblicher Prozesse eine Verwendung vonProzesskosten fur die Bestuckung einesKalkulationsschemas sehr unkomfortabel.Dies gilt selbst bei einer EDV-gestutztenAbrechnung [KrWe95], da der Anwenderauch in diesem Fall fur jedes Kalkulations-objekt die in Anspruch genommenen Men-gen ggf. mehrerer Tausend Prozesse separatin das System einpflegen musste. Aus Ver-einfachungsgrunden bietet sich daher derEinsatz von Cost-Driver-Raten in der Kal-kulation an.

Cost Driver stellen einen mengenmaßi-gen Zusammenhang zwischen bestimmtenEigenschaften des Kalkulationsobjekts undder Prozessinanspruchnahme her. Fur dieCost Driver wird die durch sie insgesamt



bei jedem Prozess beeinflusste Kostenhoheermittelt und uber alle Prozesse aufsum-miert. Dividiert man diese Kostensummedurch die Cost-Driver-Menge, so erhaltman die Cost-Driver-Rate. Diese gibt fureine Cost-Driver-Einheit die Prozesskos-ten samtlicher in Anspruch genommenerProzesse an. Fur Plankalkulationen sindprognostizierte Werte zugrunde zu legen,um Plan-Cost-Driver-Raten zu ermitteln.In der Kalkulation konnen die Prozesskos-ten dann durch Prognose der Cost-Driver-Mengen fur ein Kalkulationsobjekt undMultiplikation dieser Menge mit der Plan-Cost-Driver-Rate angesetzt werden. Beigeeigneter Wahl der Cost Driver reduziertsich der Kalkulationsaufwand damit be-trachtlich. Da sich in der Regel nicht alleProzesskosten mengenvariabel zu den Ei-genschaften eines einzelnen Kalkulations-objekts verhalten werden, gelingt bei die-sen die Ermittlung einer Cost-Driver-Ratenicht. Vielmehr stehen diese nicht von ei-nem Cost Driver abhangigen Prozesskos-ten fur fixe Kosten, fur die zweckmaßiger-weise je nach Entscheidungsbedarf eineFixkostenhierarchisierung vorzunehmenist.Die Aktivitaten sowie die anderen Ele-

mente der statischen Sicht des Unified Pro-cess (Rollen, Artefakte und Workflows)konnten Ausgangspunkt einer traditionel-len Kostenprognose sein. Beim Einsatz derProzesskostenrechnung dominiert jedochdie dynamische Sichtweise, indem die Ak-tivitaten der einzelnen Disziplinen als rele-vante Prozesse identifiziert werden. DieDisziplinen selbst konnen damit als Pro-zessbereiche interpretiert werden. Als CostDriver bieten sich die Iterationen im Uni-fied Process an. Allerdings konnen je nachIteration zwischen und auch innerhalb dereinzelnen Phasen des Unified Process un-terschiedliche, aber auch gleiche Aktivita-ten in unterschiedlicher Haufigkeit in deneinzelnen Disziplinen angestoßen werden.Die damit verbundenen Kostenunterschie-

de mussen daher durch eine Differenzie-rung der Iterationen berucksichtigt werden,sodass bei der Iteration eines bestimmtenTyps ein mengenmaßig weitgehend kon-stanter Zusammenhang zwischen den Ei-genschaften des Softwareprojekts und denausgelosten Aktivitaten besteht. Damit er-gibt sich das in Bild 2 skizzierte Kalkula-tionsschema. Es enthalt zunachst die Ein-zelkostenpositionen, die z. B. beim Bezugexterner Beratungsleistungen oder beimausschließlichen Projekteinsatz eigenenPersonals entstehen, wenn dessen Kundi-gungs- und damit Dispositionsfristen inner-halb der Projektlaufzeit liegen. Hinzu kom-men variable Gemeinkosten, die uber dieCost-Driver-Raten der Prozesskostenrech-nung angesetzt werden. Als Cost Driverwerden hier ausschließlich Iterationstypenherangezogen. Werden neben den Iteratio-nen weitere Kosteneinflussgroßen identifi-ziert, so ist das Kalkulationsschema um dieentsprechenden Positionen zu erganzen.Fur die Kostenprognose ware eine iso-

lierte Planung jeder einzelnen Iteration dieexakteste Moglichkeit der Kostenabbil-dung. Gleichzeitig erfullt ein derartigesVorgehen nicht das Ziel, durch moglichstwenige, zentrale Kosteneinflussgroßen dieKalkulation zu vereinfachen. Daher bietetsich eine Typisierung der Iterationen inden einzelnen Entwicklungsphasen nachbestimmten Merkmalen an. Nahe liegendeMerkmale sind z. B. der Grad der Inan-spruchnahme einzelner Disziplinen in denIterationen, die geplante Anzahl der Pro-jektmitarbeiter und die Personalstruktur inder jeweiligen Iteration. Das Ziel sindmoglichst homogene Iterationstypen, umFehler in der Kostenzurechnung zu mini-mieren, bei einer gleichzeitig moglichst ge-ringen Typenanzahl, um uberhaupt eineRechenvereinfachung zu erzielen. Daherist stets ein gewisser Abrechnungsfehlerhinzunehmen. Zur Typbildung kommeninsbesondere Varianten der Clusteranalysein Frage, die eine Anpassung der Cluster-

anzahl bei gleichzeitiger Berucksichtigungeines Distanzmaßes erlauben [BEPW03,503ff.]. Zur Berucksichtigung von Merk-malen wie z. B. der Personalstruktur, diebei einer Variation zu sprunghaften Kos-tenveranderungen fuhren, bietet sich ne-ben der denkbaren starker differenziertenTypisierung der Iterationen der Ansatzein- oder mehrvariabliger Cost-Driver-Ra-ten-Funktionen an. Diese bilden die Ab-hangigkeit der Cost-Driver-Rate von eineroder mehreren Kosteneinflussgroßen ab,die insbesondere aus Projekteigenschaftenund -durchfuhrungsentscheidungen stam-men.

4.2 Vorkalkulationeiner Softwareentwicklungnach dem Unified Process

�hnlichkeitsbasierte Vorkalkulationen vonSoftwareentwicklungsprojekten konnenmethodisch danach unterschieden werden,ob sie separate Mengen- und Preisprog-nosen vorsehen. Unterbleibt eine differen-zierte Prognose, so werden auf Basis einerErfahrungsdatenbank mit realisierten Ent-wicklungsprojekten ein oder mehrere kos-tenbestimmende Einflussgroßen identifi-ziert, die der meist regressionsanalytischenHochrechnung der Kostenwerte realisier-ter Projekte auf das Neuprojekt dienen[ErKL00, 403ff.]. Auftretende Kosten-abweichungen konnen dabei sowohl auffalsch geschatzte Mengenverbrauche alsauch auf mittlerweile eingetretene Preis-anderungen zuruckzufuhren sein. Daherbietet sich soweit moglich eine analytischeKostenplanung an, bei der das Mengen-und Preisgerust der Guterverbrauche furdie Kalkulation nach dem Prinzip vonBild 2 separat prognostiziert wird.Fur eine erste Vorkalkulation zu Pro-

jektbeginn liegen in der Regel keine Infor-mationen uber die genaue Anzahl und Artder Projektiterationen vor, da die Projekt-planung noch nicht ausreichend fort-geschritten ist; oftmals beschrankt sich derInformationsstand lediglich auf das Wissen,dass die Entwicklung die vier Phasen desUnified Process durchlaufen wird und die-se sich ihrerseits hinsichtlich zentralerMerkmale wie z. B. der Phasendauer oderder Mitarbeiterzahl von ahnlichen Projek-ten nicht allzu stark unterscheiden werden.Fur eine erste Kostenschatzung bleibtdaher mitunter nur die Moglichkeit, die�hnlichkeitsanalyse auf einem hoher ag-gregierten Niveau vorzunehmen. Mit �hn-lichkeitsuberlegungen konnte dann ausrealisierten Projekten die zu erwartende



Plan-Cost-Driver-Rate je Entwicklungs-phase des Unified Process hergeleitet wer-den. Die �hnlichkeitsprognose stellt dabeiauf vergleichbare Phasen bereits realisierterProjekte ab, deren Iterationsstruktur furdie Neuentwicklung als reprasentativ ange-nommen wird. Zentral ist dabei, dass fureine fruhzeitige Kostenschatzung in derVorkalkulation also keine Neuaufwurfspla-nung der Iterationen erfolgt. Zur �hnlich-keitsanalyse kommen unter anderem dieProdukt-, Rechner-, Personal- und Pro-jekt-Einflussgroßen in Betracht, die in dengangigen algorithmischen Verfahren zurAufwandsschatzung verbreitet sind. Dazugehoren neben der Iterationsdauer bei-spielsweise aus dem COCOMO II die Sys-temanalysefahigkeit und Programmierfa-higkeit der Mitarbeiter, die verwendetenSoftware-Tools oder die benotigte Soft-ware-Zuverlassigkeit. Die Anzahl der zur�hnlichkeitsanalyse notwendigen Einfluss-großen ist dabei situationsspezifisch undbestimmt entscheidend den Homogenitats-grad der betrachteten Cluster und damitdie Gute der Kostenschatzung.Bild 3 verdeutlicht die Vorkalkulation ei-

nes Softwareprojekts nach dem UnifiedProcess mit der Prozesskostenrechnung

auf der Grundlage phasenbezogener Plan-Cost-Driver-Raten. Es wird davon aus-gegangen, dass die �hnlichkeitsanalyse zufunf auswertbaren Projekten fuhrt, derenMengenstruktur die Basis der Prozesskos-tenrechnung und des Ansatzes der Itera-tionsarten und -anzahlen ist.Fur die in den Zeilen abgetragenen Akti-

vitaten der einzelnen Disziplinen sind furdie Mengenstruktur der Guterverbraucheaus den realisierten Projekten Plankosten-werte anzugeben. Diese fuhren zu phasen-bezogenen Plankostenwerten eines Durch-schnittsprojekts, die durch Multiplikationder durchschnittlichen Iterationszahlen inden realisierten Projekten mit den Plan-Cost-Drivern je Iterationstyp gewonnenwerden (separate Nebenrechnung inBild 3). Fur das Softwareprojekt xyz imBild 3 ergibt sich beispielsweise die Plan-Cost-Driver-Rate der Ausarbeitungsphaseaus den im Cluster der funf ahnlichen Pro-jekte gewonnenen durchschnittlichen 1,4Iterationen des Typs AI und 1,2 Iteratio-nen des Typs AII:

1; 4 � 27:060aþ 1; 2 � 36:917a¼ 82:185a :

Damit ergibt sich fur die Vorkalkulationdes Gesamtprojekts bei erwarteten Einzel-

kosten in Hohe von 132.500 a:

132:500a

þ 16:905aþ 82:185aþ 200:151aþ 40:144a|fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl}

Summeder phasenbezogenenPlan Cost Driver Raten

¼ 471:885a :

4.3 EntwicklungsbegleitendeKalkulationenfur Softwareentwicklungennach dem Unified Process

Mit zunehmendem Projektfortschritt kon-kretisieren sich die Projektanforderungenund damit auch das Mengengerust der Kal-kulation. Insbesondere wenn in die Vorkal-kulation lediglich klassenbezogene Durch-schnittswerte eingegangen sind, sindKostenabweichungen unausweichlich, dadie Kosten fur ein Durchschnittsprojekt er-mittelt wurden und die Neuentwicklungdavon abweichen wird. Liegt der Klassen-abgrenzung z. B. lediglich die Softwareartzugrunde, so kann die Komplexitat derSoftwareprodukte und damit auch der Ent-wicklungsbedarf sehr stark differieren.Dies kann sich unterschiedlich bemerkbarmachen: z. B. durch eine abweichende An-



zahl benotigter Iterationen oder durch Un-terschiede im Personaleinsatz innerhalb derIterationen. Daher ist die Orientierung aneiner Durchschnitts-Cost-Driver-Rate zu-gunsten einer differenzierteren Vorgehens-weise aufzugeben und zu entwicklungs-begleitenden Kalkulationen mit einerzunehmend praziseren Prognose des Men-gen- und Preisgerusts im Entwicklungsver-lauf uberzugehen. Der Phasenplan, der be-reits sehr fruhzeitige Kostenprognosen aufBasis der Phasenkosten ermoglicht, wirddamit schrittweise mit Iterationsneuauf-wurfsplanen konkretisiert.Zum Ende der Ausarbeitungsphase ste-

hen im Unified Process Anzahl und Artender Iterationen fur den restlichen Entwick-lungsprozess fest. Spatestens zu diesemZeitpunkt konnen die in der Vorkalkula-tion angesetzten phasenbezogenen Cost-Driver-Raten durch zunehmend genauerePlanmengen iterationsbezogener Cost-Driver-Typen ersetzt werden. Danebenfließen im Entwicklungsprozess in wach-sendem Umfang Ist-Kosteninformationenuber bereits abgeschlossene Phasen oderIterationen ein. Bild 4 verdeutlicht dieKonkretisierung der Kalkulationsgrund-lagen mit dem zunehmenden Informa-tionsstand im Entwicklungsprozess. Auf-tretende Ist-Kostenwerte sind kursivkenntlich gemacht.

5 Eignungder Prozesskostenrechnungzur Kalkulationvon Softwareentwicklungennach dem Unified Process

Entwicklungsprojekte auf der Grundlagedes Unified Process weisen einen hohenStandardisierungsgrad auf. Der Aufbau indie vier Entwicklungsphasen Vorbereitung,Ausarbeitung, Konstruktion und �ber-gang und die sich innerhalb dieser Phasenwiederholenden Iterationen bilden ein gutstrukturiertes Grundgerust fur Vorkalkula-tionen und am Projektfortschritt aus-gerichtete entwicklungsbegleitende Kalku-lationen mit der Prozesskostenrechnung.�hnlichkeitsuberlegungen zu bereits reali-sierten Entwicklungsprojekten unterstut-zen dabei die Ermittlung des fur eine Vor-kalkulation benotigten Mengengerusts. Sieerlauben sowohl die Prognose der direktzurechenbaren Guterverbrauche, die zuEinzelkosten fuhren, als auch von Art undUmfang der die Gemeinkostenhohe beein-flussenden Iterationen. Die Annahme der

Zeitstabilitat in der Verbrauchsstruktur istdabei eine Grundvoraussetzung. So ist eineaus einem vergleichbaren Programmpaketmit nahezu identischen Funktionalitatsan-forderungen abgeleitete Einsatzmenge ex-terner Entwicklungsleistungen als Mengeeiner Einzelkostenposition z. B. unbrauch-bar, wenn die eigene Kapazitatsauslastungoder Fortschritte in der Entwicklungs-methodik einen anderen Grad der Fremd-vergabe erfordern. Die vorgeschlagene Ty-pisierung der Iterationen im UnifiedProcess sowie die Ermittlung ein- odermehrvariabliger Cost-Driver-Raten-Funk-tionen dienen der Erfassung projektspezi-fischer Unterschiede in der Prozess- unddamit Kostenauslosung und einer im Ent-wicklungsfortschritt beliebig verfeinerbarbegleitenden Kalkulation, die sich auf eineneinheitlichen Kalkulationsaufbau stutzenkann. Eine Berucksichtigung des zeitlichenUnterschieds im Kostenanfall bei mehrperi-odigen Entwicklungsprojekten ist damitebenfalls unproblematisch: die perioden-spezifisch prognostizierten Cost-Driver-Raten sind dazu auf den Entscheidungszeit-punkt abzuzinsen. Die Multiplikation die-ser Barwerte der Cost-Driver-Raten mitdem zeitlich differenzierten Mengengerustfuhrt dann zu einem Kapitalwert der Pro-jektgesamtkosten im Entscheidungszeit-punkt.Mit der Trennung ahnlichkeitsbasierter

Prognosen des Mengengerusts derGuterverbrauche in der Softwareentwick-lung von den Preisprognosen kann das inder Sachguterentwicklung zunehmend

verbreitete Vorgehen, EDV-gestutzt iden-tische Wiedereinsatzkomponenten undahnliche, aber umzukonstruierende Kom-ponenten aus bekannten Materialstucklis-ten zu identifizieren und dieses Mengenge-rust mit aktuellen Preisinformationenautomatisch zusammenzufuhren, auch aufSoftwareprojekte ubertragen werden. Ge-nerell ist fur die Gute der �hnlichkeitskal-kulation die Datengrundlage entscheidend.Mit der zu erwartenden zunehmenden Ver-breitung des Unified Process nimmt auchder Umfang der fur die �hnlichkeitsprog-nose benotigten Erfahrungsdatenbankenzu, die neben Kosteninformationen furAuswertungszwecke relevante Merkmalewie Art und Umfang der genutzten Dis-ziplinen, zentrale Projekteigenschaften undFunktionalitatsanforderungen der Projektezu beinhalten haben. Die Einrichtung be-triebsubergreifender Erfahrungsdatenban-ken, wie sie etwa auch im COCOMO IIzugrunde liegen, ware fur eine schnelleVerbesserung der Datenbasis dabei wun-schenswert.

Anmerkungen

1 Unter der Bezeichnung Rational UnifiedProcess wird von IBM ein Softwarepro-dukt zur computerunterstutzten Abwick-lung von Softwareprojekten nach dem Vor-gehensmodell des Unified Process angebo-ten.


Abstract

Affinity-Costing for Software Development Projects based on the Unified Process

In early stages of software development projects it is particularly hard to find cost estimatesfor these projects, however, their importance for management decisions is of key impact.The lack of knowledge about the projects’ quantity structure in early project phases anddifficulties to exchange calculation specific information between the development and theaccounting departments make reasonable cost planning a severe problem. Therefore, thispaper shows a new method of preliminary and development-accompanying cost planningfor software development projects based on the unified process. Key idea is an affinity ap-proach that uses information of former development projects in an adjusted activity basedcosting method.

Keywords: Unified Process, Iterative Development, IT-management, Costing, PreliminaryCosting, Activity Based Costing, Project Budgeting


Literatur

[BEPW03] Backhaus, Klaus; Erichson, Bernd; Plin-ke, Wulff; Weiber, Rolf: Multivariate Analyseme-thoden. Eine anwendungsorientierte Einfuh-rung. 10. Aufl., Berlin u. a. 2003.

[Boeh00] Boehm, Barry W. et al. (Hrsg.): SoftwareCost Estimation with COCOMO II. UpperSaddle River (NJ) 2000.

[BoRJ99] Booch, Grady; Rumbaugh, James; Jacob-son, Ivar: Das UML-Benutzerhandbuch. Bonn1999.

[Burg02] Burghardt, Manfred: Projektmanage-ment. Leitfaden fur die Planung, �berwachungund Steuerung von Entwicklungsprojekten.6. Aufl., Erlangen 2002.

[DeMe96] Deinert, Ralf-D.; Meinders, Reinhard:Methoden zur Kalkulation von Personalaufwen-dungen in Software-Projekten. In: Gora, W.(Hrsg.): Auf dem Weg zum virtuellen Unterneh-men. Konsequenzen der Dezentralisierung. Koln1996, S. 257–268.

[EhKL00] Ehrlenspiel, Klaus; Kiewert, Alfons; Lin-demann, Udo: Kostengunstig Entwickeln undKonstruieren. Kostenmanagement bei der inte-

grierten Produktentwicklung. 3. Aufl., Berlinu. a. 2000.

[Eisi97] Eisinger, Bernd: KonstruktionsbegleitendeKalkulation. Modell eines effizienten Kosten-informationssystems. Wiesbaden 1997.

[EsMe03] Essigkrug, Andreas; Mey, Thomas: Ra-tional Unified Process kompakt. Heidelberg,Berlin 2003.

[Fure94] Furer, Patrick J.: Prozesse und EDV-Kos-tenverrechnung. Die prozessbasierte Verrech-nungskonzeption fur Bankrechenzentren. Bern,Stuttgart, Wien 1994.

[GeBK00] Gerlinger, Annette; Buresch, Alexander;Krcmar, Helmut: Prozessorientierte IV-Leis-tungsverrechnung – Der Weg zur totalen Trans-parenz? In: Krcmar, H.; Buresch, A.; Reb, M.(Hrsg.): IV-Controlling auf dem Prufstand.Wiesbaden 2000, S. 106–134.

[JaBR99] Jacobson, Ivar; Booch, Grady; Rum-baugh, James: The Unified Software Develop-ment Process. Boston u. a. 1999.

[KrWe95] Krcmar, Helmut; Weiß, Dietmar: Anfor-derungen an und Vergleich von Prozesskosten-rechnungssystemen. In: HMD 32 (1995) 182,S. 45–64.

[KrKr03] Kroll, Per; Kruchten, Philippe: The Ra-tional Unified Process Made Easy. Amsterdam2003.

[Kruc99] Kruchten, Philippe: Der Rational UnifiedProcess. Eine Einfuhrung. Munchen u. a. 1999.

[Larm02] Larman, Craig: Applying UML and Pat-terns. An Introduction to Object-Oriented Ana-lysis and Design and the Unified Process. 2.Aufl., Upper Saddle River 2002.

[ScFr93] Schweitzer, Marcell; Friedl, Birgit: Kons-truktion. In: Chmielewicz K.; Schweitzer M.(Hrsg.): Handworterbuch des Rechnungs-wesens. 3. Aufl., Stuttgart 1993, Sp. 1108–1122.

[Seib98] Seibert, Siegfried: Technisches Manage-ment. Innovationsmanagement, Projektmanage-ment, Qualitatsmanagement. Stuttgart, Leipzig1998.

[Seib03] Seibert, Siegfried: Softwaremessung, quan-titative Projektsteuerung und Benchmarking. In:Projektmanagement 14 (2003) 4, S. 26–34.

[TrBW03] Troßmann, Ernst; Baumeister, Alexan-der; Werkmeister, Clemens: Management-Fall-studien im Controlling. Munchen 2003.

[Vers00] Versteegen, Gerhard: Projektmanagementmit dem Rational Unified Process. Berlin, Hei-delberg, New York 2000.



Documents

Entwicklungsbegleitende Kalkulation von Softwareprojekten nach dem Unified Process; Affinity-Costing for Software Development Projects based on the Unified Process;