Bewertung und Bilanzierung selbst erstellter Software
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Peter Hoppen, Christian Hoppen
Bewertung und Bilanzierung selbst erstellter Software
Auswirkungen des BilMoG und Vorgehensweise bei der Wertbestimmung
Mit dem BilMoG erschließt sich Unternehmen ein Aktivie- Lizenzvergabe an entsprechende User zur Nutzung über-
rungswahlrecht für selbst geschaffene immaterielle Wirt- lassen wird.
schaftsgüter. Aktivierbar sind Aufwendungen, die i.d.R. ab Gemäß Art.66 Abs.3 EGHGB finden die neuen gesetzli-
dem 1.1.2010 anfallen und einen einzeln verwertbaren chen Regelungen erstmalig in Einzel- und Konzernab-
immateriellen Vermögensgegenstand darstellen. Der schlüssen für Geschäftsjahre Anwendung, die nach dem
Beitrag erörtert die gesetzlichen Möglichkeiten nach 31. Dezember 2009 beginnen. Der Bilanzierende kann die
neuer Gesetzeslage und gibt Praxistipps zur aktivierungs- Neuregelungen des BilMoG jedoch bereits auf nach dem
fähigen Gestaltung laufender Projekte. Es wird darge- 31. Dezember 2008 beginnende Geschäftsjahre anwen-
stellt, wie die Werthaltigkeit der Entwicklungsaufwendun- den, sofern er diese Option vollständig hinsichtlich sämt-
gen mit Hilfe von Software-Metriken nachgewiesen wer- licher gesetzlicher Neuregelungen des BilMoG ausübt.
den kann und welche Softwareentwicklungsunterlagen
geführt werden sollten, um die Basis einer fundierten
Bewertung zu schaffen. 1 3. Bewertungsmaßstab,
Abgrenzung zwischen Forschungs- und
Entwicklungskosten
I. Neuregelungen des Bilanzrechtsmo-
Als Bewertungsmaßstab der Aktivierung selbst geschaf-
dernisierungsgesetzes (BilMoG) fener immaterieller Vermögensgegenstände, und somit
auch selbst erstellter Software, sind nach allgemeinen
1. Bisherige Rechtslage Grundsätzen die Herstellungskosten anzusetzen.
Gemäß § 255 Abs.2a HGB n.F. sind als Herstellungskos-
Nach den bisherigen gesetzlichen Regelungen besteht ten bei selbst geschaffenen immateriellen Vermögensge-
sowohl handels- als auch steuerrechtlich ein Aktivie- genständen die bei der Entwicklung anfallenden Aufwen-
rungsverbot für selbst geschaffene immaterielle Vermö- dungen anzusetzen, die durch den Verbrauch von Gütern
gensgegenstände des Anlagevermögens. Unter diese Ka- und die Inanspruchnahme von Diensten für die Herstel-
tegorie ist auch selbst erstellte Software zu subsumieren, lung eines Vermögensgegenstandes, seine Erweiterung
soweit diese dauernd dem Betrieb zu dienen bestimmt ist oder für eine über seinen ursprünglichen Zustand hinaus-
(Individualsoftware zur Eigennutzung). Hiervon zu unter- gehende wesentliche Verbesserung entstehen. Hierzu
scheiden ist die auftragsbezogene Softwareentwicklung, zählen neben den entsprechenden Einzelkosten im We-
die bereits nach bisheriger Rechtslage als Vorratsvermö- sentlichen auch angemessene Teile der Gemeinkosten.
gen (unfertige Leistungen) im Umlaufvermögen zu akti-
vieren ist. Die aktivierbaren Entwicklungskosten sind von For-
schungskosten abzugrenzen, die grundsätzlich einer Akti-
Eine Aktivierungsmöglichkeit für selbst erstellte Software vierung nicht zugänglich sind. Für die Ermittlung der
des Anlagevermögens bestand bisher lediglich im Rah- Herstellungskosten ist die Erstellung immaterieller Ver-
men einer Bilanzierungshilfe bei Ingangsetzung oder mögensgegenstände somit in eine Forschungs- und eine
Erweiterung des Geschäftsbetriebes (§269 HGB a.F.). Entwicklungsphase zu unterteilen2. Die Forschungsphase
ist durch die Suche nach neuen wissenschaftlichen oder
2. Neuerungen durch das BilMoG technischen Erkenntnissen oder Erfahrungen allgemeiner
Art, über deren technische Verwertbarkeit und wirtschaft-
Im Rahmen der Annäherung der deutschen handelsrecht- liche Erfolgsaussichten grundsätzlich noch keine Aussage
lichen Bilanzierungsregelungen an die internationale gemacht werden kann, charakterisiert. Die Entwicklungs-
Rechnungslegung wurde §248 Abs. 2 ff. HGB neu ge- phase umfasst dagegen die Anwendung von Forschungs-
fasst. ergebnissen oder von anderem Wissen für die Neuent-
Hiernach besteht nunmehr ein Wahlrecht, wonach selbst wicklung von Gütern oder Verfahren oder die Weiterent-
geschaffene immaterielle Vermögensgegenstände des wicklung von Gütern oder Verfahren mittels wesentlicher
Anlagevermögens als Aktivposten in die Bilanz aufge- Änderungen.
nommen werden dürfen. Die Software-Programmierung ist aber in der Regel als
Ein Anwendungsfall dieses neu geschaffenen Aktivie- Entwicklungsleistung anzusehen, da hier zielgerichtet und
rungswahlrechtes stellt selbst erstellte Software dar, die mit entsprechenden Werkzeugen ein konkretes immateri-
im Unternehmen selbst genutzt oder auch im Wege der elles Wirtschaftsgut erarbeitet wird.
Weitere Voraussetzung für die Aktivierung von Entwick-
lungskosten für selbst geschaffene immaterielle Vermö-
gensgegenstände ist die Qualifizierung als Vermögensge-
w Dr. Ing. Peter Hoppen ist Diplom-Informatiker und in Köln als öffent- genstand. Erst wenn ein Vermögensgegenstand entstanden
lich bestellter und vereidigter IT-Sachverständiger mit Schwerpunkt ist, dürfen die entsprechenden Entwicklungskosten akti-
Organisation und Systemanalyse tätig. viert werden. Ein Vermögensgegenstand ist dann entstan-
w Christian Hoppen ist Wirtschaftsprüfer und Steuerberater in der
Kanzlei Flick Gocke Schaumburg und Geschäftsführer der Flick Gocke
Schaumburg GmbH Wirtschaftsprüfungsgesellschaft in Bonn. 2
Vgl. Hoppen/Husemann/Schmidt, Das neue HGB-Bilanzrecht, 2009,
S.63 ff.
1den, wenn mit hinreichender Wahrscheinlichkeit eine d) Startup-Situationen / Finanzierungssituationen /
selbständige Verwertbarkeit sowie eine selbständige Be- Ausgründungen
wertbarkeit gegeben ist und der Bilanzierende die Verfü- Bei einer Unternehmensgründung und in jeder weiteren
gungsmacht über diesen Vermögensgegenstand hat. Finanzierungsrunde ist die Bewertung der Aktiva in der
Sofern im Rahmen der Folgebewertung selbst erstellter Regel unabdingbar, zumindest jedoch empfehlenswert. Es
Software Erhaltungsaufwendungen anfallen, so sind diese können sich durch die Aktivierung selbst erstellter Soft-
nicht aktivierungsfähig. Lediglich nachträgliche Herstel- ware nicht unerhebliche positive Effekte auf die Eigenka-
lungskosten, die zu einer wesentlichen Verbesserung der pitalquote, Finanzierungskonditionen und Financial
Software über den ursprünglichen Zustand hinaus führen, Covenants ergeben.
sind einer weiteren Aktivierung zugänglich, sofern mit der
Entwicklung der ursprünglichen Software grundsätzlich e) Überschuldungs- / Insolvenzsituationen
frühestens im Jahr der erstmaligen Anwendung der ge-
setzlichen Neuregelungen durch das BilMoG begonnen Keine Änderungen hinsichtlich des bilanziellen Ansatzes
wurde. selbst erstellter Software durch das BilMoG ergeben sich
gegenüber der bisherigen Rechtslage in Bezug auf einen
Vermögensstatus im Rahmen einer möglichen Überschul-
4. Praktische Anwendungsfälle der Neurege- dungssituation. Im Falle einer drohenden oder vorliegen-
lungen den Insolvenz sind die Gegenstände der Insolvenzmasse
und somit auch selbst erstellte Software zu erfassen.
a) Vorhandene Software An dieser Stelle sei nur kurz darauf hingewiesen, dass
Gemäß Art.66 Abs.7 EGHGB dürfen Entwicklungskosten eine Überschuldung nach derzeitiger, zeitlich befristeter
für selbst erstellte Software nur aktiviert werden, sofern Rechtslage, zu keiner Insolvenzantragspflicht führt, so-
mit der Entwicklung in dem Geschäftsjahr begonnen wird, weit für das betroffene Unternehmen eine positive Fort-
das nach dem 31. Dezember 2009 beginnt (optional: nach führungsprognose besteht.
dem 31. Dezember 2008 s.o.).
Dies bedeutet sowohl ein Aktivierungsverbot für bereits 5. Maßstäbe der Ermittlung eines angemes-
existierende selbst erstellte Software als auch für nach- senen Wertes
trägliche Herstellungskosten die im Zusammenhang mit
bereits in der Vergangenheit selbst erstellter Software Die Wertermittlung kann sich am Substanz- oder am Er-
stehen. tragswert einer Software orientieren. Der Substanzwert
bemisst sich anhand der für die Herstellung einer Soft-
ware erforderlichen finanziellen Ressourcen, während
b) Zukünftige Projekte sich der Ertragswert hingegen anhand der marktseitigen
Bei der Entwicklung zukünftiger selbst zu erstellender langfristig erzielbaren zukünftigen Erfolgsbeiträge ermit-
Software ist wegen der stringenten Stichtagsbetrachtung telt.
des Beginns der Entwicklungsphase strikt darauf zu ach- Eine seriöse Software-Bewertung kann sich weder aus-
ten, dass die Entwicklungsphase erst in dem Jahr der schließlich auf Marktdaten, noch ausschließlich auf An-
erstmaligen Anwendung der gesetzlichen Neuregelungen gaben zur Technik und Entwicklungsmannschaft abstüt-
(in der Regel 2010) begonnen wird. Der Beginn der Ent- zen. Hier ist ein interdisziplinäres Vorgehen von Wirt-
wicklungsphase ist entsprechend dokumentieren. schaftsfachleuten und Informatikern erforderlich. Vielfach
Grundsätzlich ist zur Abgrenzung der aktivierbaren Ent- sind die in einer Softwareentwicklung steckenden Ent-
wicklungskosten von den nicht aktivierungsfähigen Auf- wicklungsaufwendungen und Qualitätsrisiken nur bei
wendungen ein leistungsfähiges F&E-Controlling einzu- detaillierter und sachverständiger Betrachtung beurteilbar.
richten, das unzweifelhaft die für die Ermittlung der Entsprechend der kodifizierten Ermittlungsnormen der
aktivierbaren Herstellungskosten relevanten Informatio- Wertansätze bilanzierungsfähiger immaterieller Vermö-
nen zur Verfügung stellt. gensgegenstände ist zunächst auf die Herstellungskosten
abzustellen. Dieser Wertansatz entspricht somit auch
c) Laufende Projekte etwaigen Wiederbeschaffungskosten.
Hinsichtlich laufender Projekte gelten grundsätzlich die Im Rahmen der Folgebewertung sind die aktivierten Her-
gleichen gesetzlichen Regelungen, wie für bereits vorhan- stellungskosten um planmäßige Abschreibungen über die
dene Software (vgl. 4.a). betriebsgewöhnliche Nutzungsdauer der selbst erstellten
Es besteht jedoch die Möglichkeit, die Entwicklungsphase Software zu reduzieren.
zu modularisieren und laufende Projekte in bereits begon- Die tatsächlichen bzw. fortgeführten Herstellungskosten
nene und noch nicht begonnene Teilprojekte aufzusplit- können jedoch nicht ohne weiteres angesetzt werden,
ten. In dieser Konstellation sind noch nicht begonnene sofern dem Vermögensgegenstand am Bilanzstichtag ein
Teilprojekte als eigenständige Projekte zu qualifizieren. niedrigerer Wert beizulegen ist (z.B. aufgrund ineffektiver
Insoweit sind die noch nicht begonnenen Teilprojekte Softwareentwicklung). Insoweit ist der Wertansatz zu
aktivierungsfähig, wenn der Teilprojektbeginn frühestens verifizieren und ggf. einer außerplanmäßigen Abschrei-
im Jahr der erstmaligen bilanziellen Anwendung der han- bung zu unterziehen.
delsrechtlichen Neuregelungen nach BilMoG liegt.
Hierzu stehen verschiedene Wertermittlungsmethoden zu
Auch in diesem Fall ist ein leistungsfähiges Projekt- Verfügung (siehe auch IDW S 5). Bei der Verifikation
Controlling einzurichten. sind die tatsächlich angefallenen Kosten (i.d.R. Lohnkos-
ten im eigenen Unternehmen nebst Gemeinkosten oder
Unterbeauftragung von Subunternehmern) einem objekti-
vierten Wert der selbst erstellten Software gegenüberzu-
stellen. Dabei kann es sich a) um den Wert handeln, der
nach dem Umfang der Softwareentwicklung üblicherwei-
2se zur Entwicklung hätte angesetzt werden müssen, oder, durch die Beobachtung und Auswertung von Software-
falls es sich um eine Software handelt, die am Markt auch entwicklungsprojekten verfeinert werden7.
Dritten gegenüber zur Nutzung angeboten werden kann,
b) um den Marktwert. a) Bestimmung des Entwicklungsaufwandes
Die Wertermittlung kann sich insoweit nach vergleichba- In dem Verfahren wird der Entwicklungsaufwand einer
ren Transaktionen (Kaufpreis), Ableitungen eines Er- Software in Personenmonaten PM ermittelt. Dieser um-
tragswertes anhand von in der Zukunft erzielbaren Li- fasst in dem Modell nicht nur die reinen Programmierar-
zenzeinnahmen oder aus einem Reproduktionswert (Cost beiten, sondern den gesamten Projektaufwand. Er be-
Approach) ableiten. Bei einer selbst erstellten Individual- stimmt sich in Abhängigkeit der Programmgröße Size
software ist der Cost-Approach häufig das einzig prakti- durch die Gleichung
kable Verfahren3. Bei der Ermittlung eines Reprodukti-
onswertes sind die jeweils verwandte spezifische Techno-
logie, ihre technische Aktualität sowie die Funktionalität
und die jeweiligen Kostenkomponenten einer Reprodukti-
on (Programmieraufwand) zu berücksichtigen. Gleichung (1)
Neben der Notwendigkeit, die Entwicklung aufzuzeich- Der Multiplikator A sowie der Exponent B passen das
nen, darzulegen und nachzuweisen, ergeben sich für den Modell den spezifischen Projektgegebenheiten an. A ist
Wirtschaftsprüfer häufig faktische Schwierigkeiten bei eine Konstante. Die Bildung des Wertes B reflektiert die
der Ermittlung des der Entwicklung zu Grunde liegenden Entwicklungsbedingungen, unter der die Software ent-
angemessenen Zeit- und Wertgerüstes. Im Wesentlichen steht, s. hierzu die nachfolgenden Ausführungen unter
ist dies auf die Komplexität und Vielschichtigkeit der 1.c).
Informationsbasis zurückzuführen. Hierzu bieten sich aus Der so ermittelte nominelle Entwicklungsaufwand
technischer Sicht die nachfolgend beschriebenen systema- PMnominal ist mittels einer Reihe von Kostentreiberfaktoren
tischen Verfahren an. (EM, effort multipliers; insgesamt 17) zu korrigieren.
Damit werden Charakteristika der jeweiligen Software-
entwicklung berücksichtigt, die den Aufwand beeinflus-
II.Verfahren der Informatik zur Bewer- sen.
tung selbst erstellter Software
Die Informatik verfügt über etablierte Verfahren zur Ab-
schätzung von Entwicklungsaufwendungen und Beurtei-
lung von Projektrisiken4. Solche Software-Metriken kön-
nen helfen, die Entwicklungskosten einer Software im
Vorfeld abzuschätzen oder auch rückwirkend anhand der Gleichung (2)
erzielten Arbeitsergebnisse (entwickelter Quellcode) zu
plausibilisieren. Die Kostentreiberfaktoren werden multiplikativ ange-
wandt und führen zu einer Korrektur des Entwicklungs-
In der Praxis am häufigsten angewandt werden die sog. aufwands, wenn die Gegebenheiten von „normalen“,
Function-Point-Analyse FPA und das Constructive Cost typischen Projektgegebenheiten abweichen. Im Detail
Model COCOMO. Aus FPA ist in den letzten Jahren das werden die Kostentreiberfaktoren nachfolgend unter 1.d)
besser auf objektorientierte Softwareentwicklungen zuge- erläutert.
schnittene Verfahren COSMIC-FFP entstanden. Diese
Software-Metriken werden nachfolgend näher beschrie- Bei der Ermittlung des Entwicklungsaufwandes werden
ben. somit folgende Schritte durchgeführt:
· Bestimmung des Quellcodeumfangs (Size)
1. COCOMO · Bestimmung und Berücksichtigung der Entwick-
Boehm entwickelte bereits in den 80er Jahres des vorigen lungsbedingungen
Jahrhunderts ein Schätzverfahren namens COCOMO · Bestimmung und Berücksichtigung der Kostentrei-
(Constructive Cost Model)5. Dieses Verfahren kann an- berfaktoren
gewandt werden, um den Entwicklungsaufwand einer
Software zu bestimmen und beruht auf tatsächlichen Pro- Das Verfahren liefert im Ergebnis eine Abschätzung der
jektaufwendungen in großen Softwareprojekten. Das gesamten Entwicklungsaufwendungen. Dies umfasst die
Verfahren wurde im Laufe der Zeit kontinuierlich weiter- Phasen bzw. Tätigkeiten Systemanalyse, Systementwurf,
entwickelt und steht heute als COCOMO II- Modell der Programmierung mit Feinkonzeption und Codierung,
University of Southern California (USC) zur Verfügung6. Modultest, Systemtest/Integration und Dokumentation.
Dabei erfolgte eine Anpassung des Modells an die sich Da das Verfahren davon ausgeht, dass der Quellcodeum-
verändernden Entwicklungsumgebungen und aktuelle fang abgeschätzt werden kann, ist es erst anwendbar,
Programmiersprachen. Außerdem aktualisiert die USC nachdem die Anforderungsanalyse und Projektierung
regelmäßig die in das Modell einfließenden Parameter, die abgeschlossen wurden. Der von dem Verfahren gelieferte
Entwicklungsaufwand berücksichtigt deswegen die Auf-
wendung für Anforderungsanalyse und Projektierung
3
s. Mäder, Ehret, Verwertung selbst erstellter Software im Rahmen der nicht. Diese sind ggfls. noch hinzuzurechnen.
Eigennutzung – Auswirkungen des BilMoG, BRZ 2009 Heft 1
4
s. K. Jantzen, Verfahren der Aufwandsschätzung für komplexe Soft-
7
wareprojekte von heute, Informatik Spektrum 1/2008 Eine fortentwickelte und auf die Gegebenheiten zeitgemäßer Software-
5 entwicklungsprojekte adaptierte Fassung von COCOMO II findet sich in
Barry W. Boehm, Software Engineering Economics, 1981
einfach nutzbarer Form auch auf der Internet-Präsenz
6
http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html http://www.siegfried-seibert.de/oldhome/quicksoft/index.htm.
3Natürlich kann das Verfahren auch angewandt werden, · sehr hoch
wenn der Quellcode bereits erstellt wurde und damit der · extra hoch
Quellcodeumfang bereits bekannt ist. Es kann dann sehr
gut dazu genutzt werden, die tatsächlich angefallenen Nicht alle Merkmale sind in allen Stufen vorgesehen;
Entwicklungsaufwendungen des Unternehmens zu plausi- teilweise liegen keine Faktoren für die Stufen sehr nied-
bilisieren bzw. abzustützen. rig, niedrig, sehr hoch und extra hoch vor.
Die Genauigkeit des Schätzverfahrens kann allgemein mit Die Neuartigkeit (W1) ist zu bewerten an dem Grad der
+/- 25% angesetzt werden, insbesondere, wenn das Pro- Identifikation der Organisation mit den Produktzielen, der
jekt abgeschlossen ist und der Quellcode-Umfang aus Erfahrung aus vergleichbaren Softwaresystemen, der
dem Projekt heraus bekannt ist. parallelen Entwicklung neuer Hardware oder neuer Ab-
lauforganisationen sowie des Erfordernisses neuer Algo-
Das Verfahren liefert neben dem Entwicklungsaufwand rithmen oder Datenverarbeitungsarchitekturen.
auch Angaben über die erforderliche Anzahl an Personen
und die zu erwartende Entwicklungsdauer. Die Entwicklungsflexibilität (W2) ist zu bewerten nach der
Abhängigkeit der zu entwickelnden Software von vorher
b) Quellcodeumfang definierten Einsatzumgebungen, der Abhängigkeit von
extern vorgegebenen Schnittstellenspezifikationen und
Die Programmgröße Size fließt in der Einheit KDSLOC dem Zeitdruck, unter dem das Projekt steht.
(kilo delivered source lines of code) als Tausende effekti-
ve Programmbefehle in das Modell ein. Dabei sind Kom- Die Risikovorsorge (W3) bestimmt den Grad der Abstim-
mentarzeilen und Codebestandteile, die nicht zur effekti- mung der Projektarchitektur auf die Projektrisiken. Sie ist
ven Programmfunktionalität beitragen (z.B. Textcode- zu bewerten nach der Existenz und Vollständigkeit eines
Fragmente) nicht zu berücksichtigen. Risk-Management-Plans, der Abstimmung des Projekt-
plans auf diese Risiko-Plan, dem Anteil der konzeptionel-
Zunächst ist daher zu bestimmen, welche Programme zum len Projektaktivitäten, dem Grad der Erfordernis hochqua-
Gesamtsystem gehören. Dabei sind nur die Befehle zu lifizierter Mitarbeiter, dem Einsatz von Werkzeugen zur
berücksichtigen, die tatsächliche Programmanweisungen Durchsetzung der Projektziele, dem Grad der konzeptio-
darstellen. Kommentierungen bzw. nicht verwendete nellen Unbestimmtheit in zentralen Bestandteilen der
Programmteile sind nicht heranzuziehen. Grundsätzlich Softwarearchitektur und der Anzahl erkannter kritischer
wird dabei von einer strukturierten Programmierung aus- Risikostellen.
gegangen, die in der Regel einen Befehl pro Programm-
zeile enthält. Die Teamzusammenarbeit (W4) ist zu beurteilen anhand
der Übereinstimmung der persönlichen Ziele und Kultu-
Bei einer retrospektiven Betrachtung einer selbst erstellten ren aller Beteiligten, der Fähigkeit und Bereitschaft ein-
Software liegt der Quellcode in der Regel vor. Die o.g. zelner Beteiligter, die Ziele anderer zu verfolgen, der
Betrachtungen können dann relativ einfach angestellt Erfahrung in der Zusammenarbeit sowie der Fähigkeit,
werden. eine gemeinsame Vision und Commitments zu entwi-
Ist die Anzahl der Programmbefehle dagegen (noch) nicht ckeln.
bekannt, so kann sie in einer Hilfsrechnung näherungs- Die Prozessreife (W5) kann schließlich anhand eines Un-
weise anhand der Anzahl zu entwickelnder Programm- termodells (CMM Capability Maturity Model des Soft-
funktionen oder Prozeduren, sog. Function Points ermit- ware Engineering Institutes der USC) ermitteln werden,
telt werden (s. hierzu weiter unten die Verfahren FPA und auf dessen Darstellung hier verzichtet wird, um den Um-
COSMIC-FFP). Aus der Anzahl der Function Points kann fang des Beitrags nicht zu sprengen.
dann – abhängig von der verwendeten Programmierspra-
che – der zu erwartende Quellcode-Umfang berechnet Die Einstufung des Projektes innerhalb der vorgenannten
werden. Merkmale kann von einem erfahrenen EDV-
Sachverständigen gut vorgenommen werden und be-
c) Entwicklungsbedingungen stimmt den Exponenten B aus der o.g. Gleichung (1) zu:
Das Entwicklungsprojekt wird bei der Bewertung nach
Komplexität und Schwierigkeit kategorisiert. Dabei sind
die Merkmale .
· Neuartigkeit Gleichung (3)
· Entwicklungsflexibilität Wenn bei der Beurteilung Informationen über die eigent-
liche Projektentwicklung nicht zur Verfügung stehen,
· Risikovorsorge wird in der Regel aus Gründen äußerster Vorsicht von
· Teamzusammenarbeit Werten an der unteren möglichen Bandbreite der Bewer-
tung ausgegangen.
· Prozessreife
zu berücksichtigen. d) Kostentreiberfaktoren
Zu jedem Merkmal sind in dem COCOMO-Modell meh- Es werden in dem COCOMO-Modell 17 Kostentreiber-
rere Faktoren Wi vorhanden, deren Ausprägung nach faktoren betrachtet, die sich in vier Gruppen zusammen-
folgender Skala unterschieden wird: fassen lassen:
· sehr niedrig · Produkt-Merkmale
· niedrig · Computer-Merkmale
· normal · Personal-Merkmale
· hoch · Projekt-Merkmale
4In jeder Gruppe sind mehrere Faktoren vorhanden, deren Phase Prozentanteil
Ausprägung nach folgender Skala unterschieden wird:
stimmten Entwicklungsaufwandes)
· sehr niedrig
Produktdesign 15 %
· niedrig (Grob- und Systemkonzept)
· normal Feinkonzept 20 %
· hoch Programmierung 25 %
· sehr hoch Modul- und Integrationstests 25 %
· extra hoch Einführungs- und Stabilisierungsphase 10 %
Nicht alle Merkmale sind in allen Stufen vorgesehen; Summe 100 %
teilweise liegen keine Faktoren für die Stufen sehr nied-
rig, niedrig, sehr hoch und extra hoch vor. Eine Einstu- Zur Ermittlung des Entwicklungsaufwandes ist der Fertig-
fung als „normal“ hat immer den Wert 1, führt also zu stellungsgrad der einzelnen Bereiche zu ermitteln. Es ist
keiner Korrektur des Entwicklungsaufwands. daher zu prüfen, inwieweit die Arbeiten in den einzelnen
Phasen erbracht wurden. Hier ist jeweils ein Erfüllungs-
Folgende Produkt-Merkmale werden unterschieden: grad zu bestimmen.
· Geforderte Zuverlässigkeit der Software
· Größe der Datenbasis 2. Function-Point-Analysis (FPA)
· Komplexität des Produkts Ein weiteres gebräuchliches Verfahren zur Aufwandsbe-
stimmung ist die Function-Point-Analysis (FPA)9. Das
· Geforderte Wiederverwendbarkeit Verfahren geht zurück auf erste Ansätze von Albrecht bei
· Anforderungsniveau an die Software- Dokumentation IBM in 1979, wurde aber im Laufe der Jahre in seiner
Definition verfeinert und dem Stand der Technik ange-
Im Bereich der Computer-Merkmale liegen folgende Kri- passt. Die International Function-Point User Group
terien vor: (IFPUG10) hat weltweit einheitliche Bewertungsrichtli-
· CPU-Zeit-Beschränkungen nien veröffentlicht.
· Hauptspeicher-Beschränkungen Das Verfahren bestimmt den fachlichen Leistungsumfang
und geht aus von den Funktionalitäten, die die Software-
· Änderungshäufigkeit in der Systemumgebung entwicklung aus der Sicht des Endanwenders zu erfüllen
Die Personal-Merkmale berücksichtigen die Qualifikation hat. Diese werden in die kleinsten sinnvollen und mit dem
der im Projekt eingesetzten Mitarbeiter. System durchführbaren abgeschlossenen Aktivitäten, sog.
Elementarprozesse, zerlegt.
· Analyse- Fähigkeiten
Die Elementarprozesse werden dabei nach einem relativ
· Programmier- Fähigkeiten als Team traditionellen Verständnis von Datenverarbeitung in fünf
· Erfahrung der Programmierer im Anwendungsgebiet Kategorien eingeteilt und in ihrer Komplexität jeweils
nach festgelegten Kriterien als Low, Average oder High
· Erfahrung der Programmierer in der Entwicklungs- bestimmt. Die fünf Kategorien sind:
plattform
· External Input – Übernahme von Daten aus anderen
· Erfahrung der Programmierer in der Programmier- Systemen,
sprache und den eingesetzten Software-Werkzeugen
· External Output – Übergabe von Daten an andere
· Personalfluktuation Systeme,
Folgende Projekt-Merkmale existieren: · External Inquiry – Annahme, Verarbeitung und Be-
· Einsatz moderner Softwarewerkzeuge antwortung von Anfragen aus anderen Systemen,
· Kommunikationsintensität · Internal Logical Files – Aus Anwendersicht identifi-
zierbare Datengruppe, die von der Anwendung ver-
· Geforderte Entwicklungszeit waltet wird sowie
e) Erfüllungsgrad · External Interface Files – Aus Anwendersicht identi-
fizierbare Datengruppe, die von der Anwendung nicht
Ergänzend ist bei einer noch nicht abgeschlossenen Soft- verwaltet wird, aber für die Verarbeitung relevant ist.
wareentwicklung zu berücksichtigen, in welchem Umfang
die einzelnen bei einer Softwareentwicklung üblicherwei- Abhängig von der Komplexität werden für jeden Elemen-
se zu durchlaufenden Projektphasen bereits fertiggestellt tarprozess nach einem definierten Verfahren sog. function
sind. points ermittelt. In der Summe bestimmt sich so der ge-
samte function-point-Wert der Software-Entwicklung.
In der Regel kann von folgender grober Prozentverteilung Der function-point-Wert ist ein Maß für den Aufwand zur
des Gesamtaufwandes ausgegangen werden8: Programmierung der Software, er berücksichtigt aber
Phase Prozentanteil nicht die weiteren Projektaufwendungen, die neben der
reinen Programmierung anfallen.
Anforderungsanalyse und Projektierung 5%
(außerhalb des durch COCOMO be-
9
D. Garmus, D. Herron: Function Point Analysis. Addison-Wesiey
8 (2001)
s. CuR 1991 Praetorius u. a., Softwarebewertung, S. 499ff., Boehm,
10
a.a.O. http://www.ifpug.org/
5Ursprünglich wurde dieser Wert in dem FPA-Verfahren 2. Softwareentwicklungs-Dokumentation
anhand von 14 System-Charateristiken korrigiert (man
spricht dann von adjusted function points). Diese System- Generell kann davon ausgegangen werden, dass rund
Charakteristiken sind aber auf heutige Systeme praktisch 30 % der Gesamtkosten im Lebenszyklus einer Software
nicht mehr anwendbar, weil sie teilweise noch von einer auf die Entwicklung und 70 % auf die Programmpflege
Batch-Verarbeitung ausgehen. Die Bedeutung von FPA und Weiterentwicklung entfallen. Bei der Wertbestim-
liegt daher heute in der systematischen Ermittlung von mung der Software muss deswegen geprüft werden, ob
unadjusted function points, die dann als Ausgangspunkt aufgrund der konkreten Realisierung Abstriche bei der
für weitere Berechnungen bspw. die Bestimmung des Wartbarkeit oder der Weiterentwickelbarkeit vorgenom-
Quellcode-Umfangs in dem COCOMO-Verfahren, die- men werden müssen. Eine wichtige Rolle spielen hier
nen. qualitätssichernde Maßnahmen, die dazu führen, dass
konzeptionelle Fehler möglichst in frühen Phasen der
Softwareentwicklung erkannt und korrigiert werden.
3. COSMIC-FFP
Wie bei der Softwareentwicklung vorgegangen wurde,
Im Jahre 1999 entstand auf der Basis von FPA unter Füh- lässt sich bei der Bewertung am besten anhand einer sys-
rung des Common Software Measurement International tematisch geführten Software-Entwicklungsdokumen-
Consortium das Verfahren COSMIC-FFP, in dem die tation nachweisen. Dazu gehören:
speziellen Gegebenheiten objektorientierter Software
berücksichtigt werden11. Beispielsweise ist es mit dieser · Fachkonzept
Metrik möglich, den Umfang eines Software-Systems, das · DV-Feinspezifikation
in der Definitionssprache UML (Unified Modelling Lan-
guage) definiert wurde, abzuschätzen. Das Verfahren · Quellprogramme mit zugehöriger Dokumentation
wurde 2003 als internationaler Standard definiert12, der in · Datenbank- Modelle
2008 als ISO/IEC 19761:2008 an die Version 3 von
COSMIC angepasst wurde. · Beschreibung der Testverfahren
Die Elementarprozesse werden in dem Modell functional · Testdokumentation
process type genannt und umfassen nicht nur die aus An- · Beschreibung der Abnahmeverfahren
wendersicht geforderten Funktionalitäten sondern auch
die aus Entwicklersicht zusätzlich notwendigen systemin- · Abnahmeprotokolle
ternen Prozesse. Dadurch können systeminterne Gege- · Softwaredokumentation (System- und Anwender-
benheiten und Technologieaspekte besser berücksichtigt handbuch)
werden. Jeder Elementarprozess wird danach untersucht,
in welchem Umfang er bestimmte Datenbewegungen – · Darstellung des Vorgehensmodells bei der Entwick-
nämlich Read bzw. Write als Lesen oder Schreiben von lung
im System verwalteten Datenbeständen und Entry bzw. · Dokumentation der Entwicklungsumgebung
Exit als Annahme bzw. Abgabe von Daten an externe
Systeme oder Anwender – vornimmt. Die Anzahl der · Aufstellung der beteiligten Mitarbeiter mit Aufgaben
Datenbewegungen bestimmt dann die Vergabe von sog. und angefallenem Entwicklungsaufwand
CFSUs, COSMIC functional size units. Die Summe aller
CFSUs ist in dem Modell, ähnlich wie bei FPA, das Maß 3. Marktfaktoren / Ertragswert
für den Programmieraufwand der Software und dient
dazu, den Quellcode-Umfang abzuschätzen. Die übrigen Wird eine selbstentwickelte Software nicht ausschließlich
Charakteristika eines Softwareentwicklungsprojektes (vgl. im eigenen Unternehmen eingesetzt, sondern auch Dritten
Kostentreiberfaktoren in COCOMO) werden auch hier in Lizenz angeboten, so bestimmt sich der Wert der Soft-
nicht betrachtet. ware nicht mehr aus den Herstellungskosten, die mit den
zuvor beschriebenen Verfahren bestimmt werden können,
sondern wird eher „durch ihre Eigenschaft bestimmt,
III. Weitere Bewertungsaspekte Einnahmeüberschüsse zu erwirtschaften“ bzw. deren
Erwirtschaftung in einem Unternehmen zu ermöglichen.
„Der Barwert der zukünftigen Überschüsse der Einnah-
1. Personalkosten men über die Ausgaben bildet den theoretisch richtigen
Wert eines Unternehmens“ bzw. der Software14.
Die vorgenannten Modelle liefern im Ergebnis Entwick-
lungsaufwendungen in Personentagen oder Personenmo- Um einen solchen Ertragswert zu bestimmen, sind bei der
naten. Um einen bilanzierungsfähigen Betrag zu erhalten, Bewertung zusätzlich folgende Informationen erforder-
müssen diese Entwicklungsaufwendungen noch mit den lich:
Personalkosten bewertet werden. · Informationen über die Marktpositionierung
Hierzu sind Kostensätze anzusetzen – differenziert nach · Angaben zum Gesamtmarkt
den einzelnen Projektphasen und unterschiedlichen Quali-
fikationen – die einem EDV-Sachverständigen in der · Marketingunterlagen
Regel zugänglich sind, teilweise aber auch abgestützt auf
eine breite Basis im Internet zugänglich sind13.
schiedliche Qualifikationen,
11 http://www.gulp.de/kb/st/stdsaetze/mainstfreib.html
http://www.cosmicon.com
14
12 Standard des Fachausschusses für Unternehmensbewertung und
ISO/IEC 19761:2003: Software Engineering - COSMIC-FFP - A
Betriebswirtschaft (FAUB) des Instituts der Wirtschaftsprüfer IDW S 1
functional size measurement method
„Grundsätze zur Durchführung von Unternehmensbewertungen“ sowie
13
Für Freiberufler bietet die Projektbörse Gulp eine Übersicht der Stun- IDW S 5 „Grundsätze zur Bewertung immaterieller Vermögensgegen-
densatzforderungen und tatsächlich gezahlter Stundensätze für unter- stände“
6· Verzeichnis der Installationsbasis / Referenzen
· Angaben zu den Wettbewerbern
· Vertriebswege
· Kosten des Vertriebs (direkte oder über Provisio-
nen/Rabatte)
· Umsatzentwicklung und Prognose (3 Jahre)
· Preise für Lizenzen, Updates und Support sowie
Prognose zur Preisentwicklung (3 Jahre)
· Anzahl der vergebenen Lizenzen, Entwicklung
und Prognose (3 Jahre)
Bei der Softwarebewertung kann der Wert der Software
dann unter folgenden verschiedenen Aspekten betrachtet
werden:
1. tatsächlich angefallene Entwicklungsaufwände
2. Ableitung der Entwicklungsaufwände anhand der
Größe des Quellcode, bspw. unter Verwendung
des COCOMO-Verfahrens
3. Marktwert (unter Berücksichtigung von mögli-
chen Einnahmen aus Lizenzen, Support, Updates
bzw. Ableitung aus vergleichbaren Transaktio-
nen)
In der Summe ergibt dies erfahrungsgemäß eine verlässli-
che, nachvollziehbare und in sich konsistente Wertbe-
stimmung.
IV. Fazit
Durch die Neuregelungen des Bilanzrechtsmodernisie-
rungsgesetzes (BilMoG) bieten sich dem Unternehmen
neue Gestaltungsmöglichkeiten hinsichtlich der Aktivie-
rung selbst erstellter immaterieller Vermögensgegenstän-
de, die aufgrund ihrer wirtschaftlichen Auswirkungen im
Rahmen der bilanzpolitischen Gestaltung unbedingt be-
rücksichtigt werden sollten.
Wenngleich die Ermittlung der aktivierungsfähigen Her-
stellungskosten, die innerhalb der Entwicklungsphase
selbst erstellter Software anfallen, gewisse Schwierigkei-
ten bereiten kann, bietet die Informatik entsprechende
Metriken zu deren Ermittlung an, die auch die komplexen
bewertungsbeeinflussenden Faktoren, wie z.B die Neuar-
tigkeit und die Komplexität der selbst erstellten Software
berücksichtigen.
Insbesondere bei bereits begonnenen Entwicklungspro-
zessen, deren Entwicklungsphase zeitlich sowohl in den
Geltungsbereich des Aktivierungsverbotes als auch des
neuen Aktivierungswahlrechtes fallen, ist zu prüfen, ob
eine Modularisierung in entsprechende Teilprojekte mög-
lich ist.
Zur sachgerechten Dokumentation und Ermittlung der
Herstellungskosten ist ein leistungsfähiges Projekt-
Controlling einzurichten, um das Aktivierungswahlrecht
nicht aus formellen Gründen einer mangelnden
Konkretisierbarkeit der für die Aktivierung notwendigen
Voraussetzungen zu gefährden.
Insgesamt ist zu empfehlen, dass der Bilanzierende bereits
frühzeitig die Aktivierungsfähigkeit und die zu Grunde
liegenden Bewertungsparameter mit einem EDV-
Sachverständigen und dem Wirtschaftsprüfer abstimmt.
7Sie können auch lesen
