Basic HTML-Version
CM
Controller magazin
2/07
3.3. Dritte Qualitätssicherung
M i t der Qual i tätssicherung beginnt die
3. Kernphase im Entwicklungsprozess.
Im Wesent l ichen vergleicht ma n die von
der Systemanalyse aufgestel l ten Soll-
Forderungen (Spezifikationen) mi t den
durch die Impl ement i erung realisierten
Ergebnissen. Gri jnde für mögl iche Ab–
weichungen liegen u.a. an
-
immer kürzeren Entwicklungs- und
„Reifezeiten",
-
Inkompat ibi l i tät zu anderen Software-
Komponenten,
- der zunehmenden Komplexi tät der
eigenen Anwendung .
Software-Qual i tät ist aber mehr als „nur"
der störungsfreie Ablauf einer Anwen–
dung. Typische Qua l i tätsmerkma l e sind
beispielsweise Performance, Benutzer–
freundl ichkeit, War tbarkei t , Portabi l ität
und Kompat ibi l i tät .
Doch Qual i tät hat ihren Preis. Unter Zeit-
und / oder Kostendruck neigt man gerne
dazu , kurzfristig ein Qp t imum zwischen
dem Aufwand zur Qual i tätssicherung
und der I nkaufnahme von Störungen
nach ma thema t i schen Regeln zu finden.
Doch das Reduzieren der QS-Maßnah-
men kann langfristig teurer sein. Auch
wenn die Kosten fiir Soft;ware-Störungen
me i s t in e i n em Geme i nkos t enb l ock
„verschwinden", sind es vor al lem nicht
quant i f izierbare Me r kma l e wi e Kunden–
ve r t r auen , Image und Ma r k e n n ame ,
welche an mangelnder Qual i tät Schaden
nehmen .
Aus dieser Über legung heraus ist Qua–
l i t ä t ss i che r ung als e ine l angf r i s t i ge
Invest i t ion zu bet rachten und mi t ent–
sprechenden Kapazi täten auszustat ten.
Qual i tät
Quan t i t ä t
En twi ck -
l ungsdaue r
Budge t
In diesem Zusammenhang passt das „Teu–
felsquadrat" von Sneed" . Demnach gibt
es signifikante Abhängigkei ten zwischen
den Faktoren Qual i tät und Quant i t ä t
sowie Entwicklungsdauer und Kosten.
Dies bedeutet , die Qual i tät und / oder
Qual i tät lassen sich nur dann erhöhen,
wenn gleichzeitig die Entwicklungsdauer
und das Budget ansteigen (siehe Pfeil
(D).
Im Rückschluss führen sinkende
Entwi ck l ungsaufgaben bei gleichblei –
bender Qual i tät zu einem Reduzieren des
Entwicklungsumfangs sowie der -dauer
Aus dieser Erkenntnis und der Notwen–
digkeit z um wi r tschaf t l ichen Arbei ten
unterstützt das Control l ing im Bereich
der Qual i tätssicherung u. a. folgende
Strategien:
3.3.1. Permanente Qualitätssicherung
im Entwicklungsprozess
je s p ä t e r e i n e S t ö r u n g i m En t –
wicklungsprozess erkannt wi rd, desto
kostenintensiver ist i.d.R. ihre Korrek–
t u r Di esem Gedanken folgend w i r d
die zentrale Qual i tätsprüfung vor der
Ausl ieferung tendenziel l durch mehrere,
dezent rale Teststufen am Ende einzelner
Entwicklungsphasen ersetzt. )ede Kom–
ponente, jeder Baustein wi rd fortan durch
einzelne Funkt ionstests funkt ionel l und
qual i tat iv geprüft und „zertifiziert". Nur
qua l i tätsgeprüf te Ei nze l komponent en
gelangen so in das Zielsystem. Nach die–
sem System arbei tet beispielsweise die
Autoindust r ie seit lahren erfolgreich. Im
Bereich der Sof tware-Entwicklung ist die
konsequente Umsetzung dieser Strategie
u. E. erst in wenigen Unternehmen erfolgt.
Dennoch hilft aus unserer Er fahrung
diese Ar t der Qual i tätssicherung, die
Rücklaufquote deut l ich zu senken und
dami t indirekt Kosten, Zeit und Nerven
zu sparen.
3.3.2. Testumfang zeitlich planen
Gedankl ich könnte ma n einen Soft;wa-
re-Test fiir ein neues Release als ceteris
par ibus Analyse durchführen. Da bis auf
einen Programmtei l alle anderen Bereiche
unveränder t bleiben, prüft man nur die
geänder te Funkt ion. Dies ist leider nur
Theorie. Es sind vor al lem Cross-over
Effekte, die Fehler und Störungen in
ent fernten Programmtei len produzieren
können. Aus diesem Grunde sind Ab–
schlusstests immer als Volltests durchzu–
führen. Doch diese sind zeit- und dami t
kostenintensiv Daher empf iehl t es sich
erstens, die Testzyklen und -umfange
aus wi rtschaf t l ichen Gesichtspunkten zu
planen und ggf. verschiedene Einzeltests
zu e i nem Gesamt t es t z u s amme n z u –
fassen. Als zwei te Einsparungsalternative
ist der Einsatz von Testautomaten zu
prüfen. Diese Software-Systeme wieder–
holen e i nma l aufgezeichnete Testfälle
bel iebig oft. Der manuel le Testaufwand
wi rd deut l ich reduziert und t rägt somi t
zu einer Kostenreduzierung bei .
3.4. Begleitendes Controlling
Im vor l iegenden Dokument wurden die
Kernphasen der Soft:ware-Entwicklung
Planung • Durchführung - Kontrolle oder
besser Systemanalyse - Implement ierung
- Qual i tätssicherung in ihrer Arbei tsweise
vorgestellt. Für jede dieser Phasen sowie
zur phasenübergre i fenden Steuerung
stellt das Control l ing geeignete Systeme
bereit. Sie er lauben eine übergreifende
Koordination und geben den Fach- und
Führungskräf ten Informat ionen, so dass
sich diese im Rahmen ihrer MbO-Zielset-
zungen selbst steuern können.
Neben diesen - meist organisatorisch
geprägten Funkt ionen - sind die wei teren
Aufgaben des Controllers in der Software-
Entwicklung in Anlehnung an einen „The–
men t epp i ch " z us ammenge f a s s t (siehe
Abbi ldung auf der nächsten Seite).
4. AUSBLICK
Die Sof tware-Entwicklung wi rd in den
nächs t en j äh r en ähn l i che Ra t i ona l i –
sierungswel len er leben, wi e sie beispiels–
weise in der Autoindustr ie vorexerziert
wurden: Unter eno rmem Kostendruck
wi rd die Fertigungstiefe reduziert und
durch globales Sourcing we t tgemacht .
Skalierbares Know-How wi rd zunehmend
erst bei Bedarf global gekauft. Die Ent–
wicklungszyklen werden sich verkürzen
und eine höhere Produkt ivi tät , sprich ein
steigender Business Value gefordert.
Für diese, aus dem Ma r k t sich anbah
nenden Veränderungen muss sich das
Managemen t / Control l ing mi t geeigne–
t en aufbau- und ablauforganisatorischen
Ma ßn a hme n sowie Werkzeugen rüsten,
um langfristig erfolgreich Sof tware pro–
duzieren zu können.
Zuordnung CM-Themen-Tableau
05
33
39
A
S
L
151