IS-Rating: Planungssicherheit durch transparente Qualität
Die Pauschalpreise sind nur vom inhaltlichen Umfang einer Änderung abhängig, also nur von der Wirkung für die Anwender. Der Nutzer kann daher mit ein wenig Erfahrung selbst die Preise für Änderungen der Software wie aus einem Katalog ohne aufwändigen Angebotsprozess ermitteln. Diese helfen ihm aufgrund der feinen Granularität auch bei detaillierten Kosten/Nutzen-Abwägungen.
Insbesondere sind diese festen Preise auch unabhängig vom typischen Alterungsprozess bei Software, durch den selbst kleine Änderungen mit zunehmendem Alter immer aufwändiger werden.
Die Preise spiegeln die dynamische Qualität der Software wider, d.h. insbesondere die in der Software enthaltenen technischen Hypotheken. Solange wie man verhindern kann, dass Änderungen der Software zu einer weiteren Erhöhung der bereits vorhandenen technischen Hypotheken führen, lassen sich die Preise für Änderungen fest schreiben.
Die Struktur der konkreten Preisliste ist stark von Art und Zweck einer Software abhängig. Sie lässt sich daher hier nicht allgemein darstellen. Wir können hier aber zwei Modelle vorstellen, wie diese Preisliste entstehen kann. Diese beiden unterschiedlichen Varianten werden in der Praxis auch kombiniert. Beide orientieren sich an den bisherigen Erstellungsaufwänden der Software und unserer Bewertung ihrer dynamischen Qualität.
In jedem Fall gilt die Regel, dass die Strukturen der Preislisten sehr ähnlich sind für Systeme, welche die gleichen Anforderungen erfüllen sollen. D.h. auch, dass sich im Rahmen eines Auswahlverfahrens die Preislisten nicht in der Struktur sondern nur im Preisniveau unterscheiden - für ein System liegen also die Preise z.B. um den Faktor zwei höher, als bei einem anderen.
Eine Software wird nach ihrer Fertigstellung vollständig in inhaltliche Bestandteile zerlegt. Dabei wird auch der reale Erstellungsaufwand (nicht ein etwaiger Festpreis!) abzüglich spezieller Einmalaufwände vollständig auf diese Bestandteile verteilt. Dieser Vorgang wird für jedes der Teile solange wiederholt, bis sich alle dann feingranularen Teile auf ca. 10 Änderungsklassen mit vergleichbarem und leicht zu beschreibendem inhaltlichen Umfang verteilen lassen.
Sind die Aufwände innerhalb einer Klasse relativ einheitlich, wird der Preis für diese Klasse als gewichteter Durchschnitt dieser Aufwände festgelegt. Ist die Streubreite der Aufwände sehr groß, dann wird nach einer einfachen inhaltlichen Differenzierung gesucht und die Klasse entsprechend aufgeteilt. Diese Preise werden dann noch mit einem Faktor korrigiert, der sich aus unserer Bewertung der dynamischen Qualität ergibt.
Im Ergebnis bestimmt sich der Preis für eine zukünftige Änderung der Software also über den Aufwand, den eine inhaltlich ähnliche Funktionalität bei der ursprünglichen Erstellung der Software erforderte. Das gilt für das Hinzufügen eines ganzen Moduls genau so wie für das Ergänzen eines Feldes in einer Bildschirmmaske und einer Datenbank.
Der Preis für eine Änderung ergibt sich aus Anzahl und Umfang der Akzeptanztests für die Abnahme dieser Änderung. Die Akzeptanztests spiegeln wider, an welchen Stellen die Anwender aufgrund der Änderung mit einem geänderten oder auch unveränderten Verhalten der Software rechnen. Ihre Anzahl und ihr Umfang steht also in einer engen Beziehung zum inhaltlichen Umfang einer Änderung. Zu umfangreiche Tests kosten mehr als nötig. Zu wenige Tests bergen die Gefahr in sich, dass gewünschte Aspekte der Änderung nicht realisiert werden. Auch eine erforderliche Nachbesserung kostet dann eben entsprechend der nachgelieferten Akzeptanztests.
Der Preis für einzelne Akzeptanztests ergibt sich dabei ähnlich wie unter Model #1 durch Vergleich mit den Akzeptanztests für das bereits bestehende System. Auch diese Preise werden dann noch mit einem Faktor korrigiert, der sich aus unserer Bewertung der dynamischen Qualität ergibt.
Aufgrund der vorangegangenen Erläuterungen sollte klar geworden sein, dass sich der Preis einer Änderung nicht wie bei einem klassischen Festpreisprojekt nach den Anforderungen sondern nach dem abgenommenen Umfang richtet. Es macht also für den Preis keinen Unterschied, ob alle Sonderfälle und Spezialitäten bereits in der Anforderung ausgeführt werden oder sich diese erst während der Entwicklung bis zur Abnahme ergeben oder in einem weiteren Schritt danach ergänzt werden müssen. Relevant ist alleine der inhaltliche Umfang der real durchgeführten Änderung.
Es geht hier nicht darum, den Nutzer vor Unzulänglichkeiten bei der Anforderungsermittlung in seiner Fachdomaine zu schützen, das fällt eben in sein Fachgebiet, sondern zu verhindern, dass er die Kosten einer unsauberen Realisierung in Form von später immer höheren Änderungskosten zu tragen hat, die ihn u.U. sogar zu einem vorzeitigen Ersatz des Systems veranlassen.
