Basic HTML-Version
CM
Controller
ma g a z i n 2 / 07
Pragmat isch gesehen beschreibt die Sy–
stemanalyse u.a. den Arbei tsumfang, der
sich aus der Differenz zwischen einem ge–
genwär t igen Ist und einem angestrebten
Soll ergibt. In Abhängigkei t von Umfang
und Komplexi tät der Anforderung müs–
sen Prototypen, Studien oder Model le
in dieser Phase entwickel t werden. |e
präziser eine Anforderung spezifiziert
ist, desto störungsfreier gestaltet sich die
wei tere Abarbei tung. Hierbei empf iehl t
es sich, neben einer reinen funkt ionalen
Beschreibung auch al lgemeine Qualitäts–
at tr ibute wie beispielsweise das Antwort –
zei tverhal ten, System-Portabi l i tät und
zent rale Abnahmekr i t er i en mi t in die
Spezi f ikat ion auf zunehmen . „Denn nur
wer we iß, was er wi l l , kann später prüfen,
was er bekommt . " Für eine schlüssige
und komplet te Spezifikation sollte man
ca. 15 - 2 0 % des Gesamtaufwandes
einplanen. Ein projektgetriebenes Kürzen
dieser Dauer führt zu keiner nachhal t igen
Reduzierung der Gesamtzei t , sondern
ste iger t nur das En twi ck l ungs r i s i ko
überpropor t ional .
Im wei teren Arbeitsablauf gliedert man
diese Spezifikationen in selbständige Ein–
heiten und erfasst sie als Arbeitsauftrag im
Ticketsystem. Ergänzend sind dann noch
folgende plakative Fragen zu klären:
- » Wi e hoch ist der zeitl iche Aufwand in
Mann-Tagen fiir dieses Ticket?
- » Bis zu welchem Da t um wi rd das Ticket
/ Produkt fertiggestellt?
- » Wieviel kostet dieses Ticket?
3.1.1. Zeitlichen Aufwand schätzen
Bei subjekt iven Aufwandsschätzungen
reicht das Ergebnisspektrum von „vor–
sichtig" bis „gewagt" und hängt stark von
der Menta l i tät des Schätzers ab. Häuf ig
wi rd diese Schä t zung a nh a nd eines
Analogieschlusses vorgenommen . Dies
bedeutet , ma n vergleicht das Vorhaben
mi t bereits abgeschlossenen Projekten.
Doch dieses Vorgehen impl iziert die Ge–
fahr, den „Schlendrian" der Vergangenheit
in die Zukunf t zu über t ragen. Für ein
transparentes Controlling sollte man sich
- ab einer bes t immt en Funkt ionsgröße
(z. B. > 2 0 MT) - auf ein formal isiertes
und nachvol lziehbares Schätzverfahren
un t e r nehmenswe i t verständigen. Ins–
besondere bei einer Software mi t hoher
Komp l ex i t ä t bzw. e n o rmem Umf ang
wi rd bei einer methodischen Aufwands–
schätzung der überproport ionale Anstieg
der En tw i ck l ungsdaue r aus r e i chend
berücksicht igt .
Die theoret ische Informat ik bietet die
un t e r sch i ed l i chs t en l i nea r en , emp i –
rischen, algor i thmischen oder statisti–
schen Prognosemode l l e zur Pl anung
eines Entwicklungsaufwandes. Zu den
be k ann t e s t en Mod e l l e n z äh l en u.a.
COCQMO' oder Func t i onPo i nt^ Diese
Model le arbei ten vom Grundsatz nach
e inem ähnl ichen Muster : Die vorhan–
denen Eingangsgrößen wi e vergleich–
barer Quel lcode in KLOC (Kilo Lines of
Code), Wachstumsraten des Quel lcodes,
Testtabel len usw. we rden abst rahier t ,
quant i f iziert und im Rahmen der mo–
del leigenen Val idat ion zu Aussagen über
den gep l an t en En twi ck l ungsau fwand
geformt .
Das Ergebnis dieser errechneten Dauer
wi rd - wie bei subjektiven Schätzungen
auch - im Ticketsystem erfasst. Auf dieser
Basis lassen sich dann weitere Zeiten
für
Qual itätssicherung, Dokumentat ion usw.
entweder einzeln schätzen oder durch pro–
zentuale Erfahrungswerte (rules of thumb)
zur Gesamtdauer hinzurechnen.
TVotz aller wissenschaft l ichen Me t hoden
bei der zeitl ichen Planung des Entwick–
lungsaufwands sollte ma n für ein effek–
tives Control l ing auch einige Phänomene
aus der tägl ichen Praxis beachten:
- » Ein Projekt dauer t immer so lange,
wi e Kapazi tät vorhanden ist.
Wenn eine Software zu 90 % fertig–
gestellt ist, sind noch 30 % der Zeit
nöt ig.
- » Mi tTeamgeist und Gruppendynami k
lassen sich auch unrealistische Termi–
ne einhal ten.
3.1.2. Planung der Kosten
Eine exakte Planung der zu erwar tenden
Entwicklungskosten ist eine zwingende
Notwendigkei t . Denn neben firmenin–
ternen Budgetvorgaben dient die Ko–
stenschätzung häuf ig auch als Basis für
vertragl iche Vereinbarungen. Die Folgen
zu niedrig kalkul ierter Festpreisverträge
sind hinlängl ich bekannt und werden hier
nicht erörtert . Stattdessen wi rd man die
Ermittlung der Entwicklungskosten sowie
die Analyse der Hauptkosten exempla–
risch aufzeigen.
Erinitteln der Entwicklungskosten:
Voraussetzung für das Ermi t te ln der
Entwicklungskosten ist, dass fiJr jedes
Ticket bereits eine zeitliche Aufwands–
schä t zung vor l iegt . Durch e infaches
Mul t ipl izieren dieser Dauern mi t den kal–
kulierten Mi tarbei ter-Stundensätzen wi rd
der finanzielle Aufwand je Ticket oder je
Release quant i f iziert . Doch Vorsicht: Das
Ergebnis zeigt nicht den Soft:warepreis,
sondern nur eine „technische" Zahl bei
Stückgröße eins. Im Rahmen einer seri–
ösen Handelskalkulat ion sind zu dieser
„technischen Zahl" wei tere Produkt- und
Strukturkosten beispielsweise für Büro–
betrieb, Rückstel lungen fiJr War tung und
Gewährleistung sowie eine Gewinnmarge
einzuplanen. Auch sind die prognostizier–
ten Absat zzahl en zu berücksicht igen.
Doch bei allen Berechnungen und Kal–
kulat ionen darf man nicht versäumen,
sich bei der Preisbildung am al lgemeinen
Marktgef i jge zu or ient ieren.
Kostenverursacher: Parallel zur „tech
nischen" Kostenplanung sollte das Con–
trolling die Gründe und Verursacher von
Kosten kennen und verfolgen. Ein Hauptau–
genmerk wi rd man auf die Personalkosten
richten, da sie in einer Software-Entwick–
lung den größten, direkt quantifizierbaren
Kostenblock darstellen.
In e iner ersten Ana l yse sol l te ma n
hinter f ragen, wi e sich die geleisteten
Arbei tszei ten vertei len. Eine Studie der
Bell Labs zeigt beispielsweise, dass der
produkt ive Antei l eines Entwicklers bei
nur
1
3 % liegt. Im einzelnen vertei lt sich
seine 'Anwesenhei tsdauer ' wie folgt':
- Arbeitsbezogene Kommunikation 32%
- Programme und Handbücher lesen 16%
-Programmeschreiben
13% «-
- Persönliches
13%
- Ausbildung
6%
- Post
5%
- Diverses
15%
Tl-eten im konkreten Untemehmen ähnliche
Verteilungen der Arbeitszeit auf, sind letzt–
lich Maßnahmen zu initiieren, die helfen, die
Produktivität zu steigern. Eine Möglichkeit
kann das Umsch i cht en der „Arbei ts-
bezogenen Kommunikat ion" zur formali–
sierten Kommunikat ion (z. B. integriertes
CASE-Tool, Ticketsystem etc.) sein.
Eine zwei te Analyse zeigt häuf ig, dass
ein Beschluss für eine neue Technologie,
Anwendung oder Funkt ion get rof fen
wi rd, ohne die dami t verbundenen Ri–
siken in vol lem Umfang abzuschätzen.
So wunde r t es kaum, dass nur 29 %
aller Softiware-Projekte termin- und bud–
getgerecht sowie mi t dem erwar teten
Funk t i onsumf ang beende t we r den . ' "
Um dieser Situation entschieden entgegen
zu wi rken, sollte ma n die getrof fenen
149