IS-Rating: Planungssicherheit durch transparente Qualität
Hierunter ist die Transparenz der Abbildung der Fachdomaine in den Quellkode zu verstehen und damit in der Folge die Möglichkeit, Funktionalitäten in möglichst kleinen Gruppen sauber wieder aus dem Quellkode entfernen oder austauschen zu können.
Schon die Anforderungen zu den Unit-Tests erfordern eine gute Modularisierung
der Funktionalitäten des Systems.
Diese Modularisierung stellt ein wesentliches Qualitätsmerkmal dar,
weil Funktionen, die sich nicht leicht wieder ausbauen lassen, sich in den
seltensten Fällen leicht und ohne Kollateralschäden ändern lassen.
Ein wichtiger Aspekt bei der inhaltlichen Modularisierung
besteht in der Abgrenzung von geschäftskritischen Funktionalitäten,
von denen man sich z.B. einen Wettbewerbsvorteil erhofft oder
die Geschäftsgeheimnisse beinhalten.
Bei allen anderen Funktionalitäten besteht in Zukunft eine höhere Chance,
diese durch andere (Standard-)Systeme ablösen zu können.
Dieses sollte nicht durch unnötig starke Abhängigkeiten behindert werden.
Bei der Modularisierung ist auch ein besonderes Augenmerk auf die
Abhängigkeiten zwischen den Modulen zu werfen.
Hier müssen zyklische Abhängigkeiten und
ausufernde Kaskadeneffekte über das ganze System bei Änderungen
in tieferen Schichten verhindert werden.
Diese behindern die Refaktorierung und erhöhen so das
Änderungskostenrisiko beträchtlich.
Ein weiteres grundsätzliches Problem besteht in der
Duplikation von Teilen des Quellkodes
– sei es nun nur eine Konstante oder eine ganze Klasse.
In diesem Fall fehlt i.d.R. im System eine
entscheidende Information.
Haben z.B. zwei Konstanten den selben Wert, so muss bei einer Änderung
unmissverständlich klar sein, ob beide immer synchron geändert werden müssen
oder nur unter bestimmten Bedingungen
oder völlig unabhängig voneinander sind.
Wenn Quellkode oder Unit-Tests den korrekten Fall nicht klar kommunizieren,
steigt wieder das Änderungskostenrisiko.
Statistische Untersuchungen, wie auch eigene Erfahrungen, zeigen darüber hinaus,
dass über die große Lebenszeit vieler Informationssysteme eine Reihe von
Funktionen nach einiger Zeit nicht mehr genutzt werden.
Dieses kann verschiedenste Gründe haben, auch z.B., dass Teile der Aufgaben
inzwischen über ein anderes System abgewickelt werden.
Eine detailliertere Analyse kann ebenfalls auf der Basis einer automatisierten
Aufzeichnung
des Programmablaufs
durchgeführt werden.
Es gibt keinen guten Grund diese nicht mehr genutzten Funktionalitäten
weiter im System zu belassen.
Sie verteuern sowohl den Wartungs- als auch den
Änderungsaufwand.
Aus diesem Grund soll das System nicht nur ein internes Modulkonzept
besitzen sondern auch ein inhaltliches externes, das es
ermöglicht Funktionen bzw. Module abzuschalten und dabei auch
wirklich Teile des Quellkodes zu entfernen.
Diese Vereinfachung muss sich dann auch in einer angemessenen
Reduktion des Wartungspreises widerspiegeln.
Der Anbieter
soll also das System als eine Sammlung inhaltlicher Module darstellen
und jedem Modul den Anteil an der Wartung zuordnen,
der dann bei dessen Abschaltung entfällt.
Die konkrete Qualität bemisst sich an der Granularität dieser
entfernbaren Module und der sauberen Abgrenzung der
geschäftskritischen Funktionalitäten.
Darüber hinaus kann die Qualität der Modularisierung
(Kopplung, Kohäsion) mit allgemeinen
Werkzeugen zur Quellkodeanalyse überprüft werden
(s. Plattformunabhängigkeit).
Zu den Werkzeugen gelten hier die selben Hinweise wie zur Plattformunabhängigkeit.
