IS-Rating: Planungssicherheit durch transparente Qualität
Hierunter ist die Möglichkeit zu verstehen, die leichte Änderbarkeit der Software zeitnah anhand der Prüfung vieler funktionsfähiger Zwischenstände und der Beobachtung der Entwicklung selbst besser bewerten zu können.
Eine einzige Bewertung der Qualität der Erfüllung der Anforderungen
im Rahmen einer technischen Abnahme des fertigen Systems verleiht der daraus
abgeleiteten Abschätzung des Änderungskostenrisikos
keine besondere Zuverlässigkeit.
Es müssen daher auch Zwischenstände des Systems geprüft und
die Entwicklung der Qualität beobachtet werden.
Hierfür können zur Not auch Informationen zur
Entstehungsgeschichte des Quellkodes aus einem
Source-Code-Control-System genutzt werden.
Eine Auswertung derselben ist jedoch sehr aufwändig und ergibt
u.U. nur ein unvollständiges Bild.
Die Bewertung der leichten Änderbarkeit ist
nur auf Basis der Erfüllung der technischen Anforderungen ohne
die Beobachtung von realen Änderungen unvollständig.
Daher und auch aus anderen Gründen ist das
Miterleben des Entwicklungsprozesses wichtig.
Wird ein System oder größere Teile davon neu erstellt,
so wäre es unsinnig mit der Bewertung der Qualität
bis zur Abnahme zu warten.
Außer Aspekten der Modularisierung, lässt sich keines der bisher aufgeführten
Qualitätskriterien auch nur annähernd
ohne den Produktivkode überprüfen.
Daher ist es aus Sicht des Risikomanagements nicht akzeptabel, wenn der
Anbieter
über lange Zeit nur Papierkonzepte liefert,
ohne auch den Beweis anzutreten, dass diese sich
in akzeptabler Qualität umsetzen lassen.
Demzufolge muss es für den
Nutzer
nach einer möglichst kurzen Anlaufphase möglich sein, den
Fortgang der Arbeiten am realen System zeitnah zu verfolgen,
indem er jederzeit eine aktuelle Version
des Systems inklusive aller geforderten Qualitätsmerkmale zur
testweisen Nutzung und Beurteilung beim Anbieter abfordern kann.
In der Anlaufphase ist es daher auch erforderlich, dass
beim Nutzer eine Basisinstallation vorgenommen wird,
die das einfache Einspielen und Nutzen dieser Zwischenversionen ermöglicht.
Es ist von dieser Anforderung unabhängig, in welchem Umfang der Nutzer hiervon Gebrauch macht und in welchem Umfang der Anbieter seinerseits kurzfristiges Feedback aufgrund dieser Zwischenlieferungen verlangt.
Die Qualität der Erfüllung dieser Anforderung bemisst sich einerseits daran, wie
zeitnah der Nutzer neue Versionen der Software
bekommen kann und wie alt diese dann sind, und andererseits daran,
wie konstant die Entwicklung von Version zu Version
voranschreitet.
Bricht man die umzusetzenden Anforderungen auf kleine annähernd gleich große
Funktionalitäten herunter und betrachtet dann die Menge an
realisierten und (abnahme-)getesteten Funktionalitäten über die Zeit,
so wären größere Schwankungen dabei ein negatives Indiz
bezüglich der technischen Änderungsfähigkeit des Systems.
Die folgenden Referenzen stellen kein Qualitätsurteil dar.
Sie sollen nur einen ersten Einstieg in Aspekte der Materie bieten.
Von den diversen Werkzeugen zur Unterstützung von
Build- und Integrationsprozessen
bei der Entwicklung von Software seien hier nur
Ant,
Maven und
CruiseControl
erwähnt.
Zu diesem Themenkomplex – insbesondere auch zu zeitgemäßen
(iterativen und inkrementellen) Softwareentwicklungsprozessen
– gibt es unzählige Literatur, die sich problemlos im Internet finden lässt.
Als Literaturhinweis zur
ROI-basierten
Entwicklungsfinanzierung
IFM sei hier erwähnt:
