Regelwerk

In fast allen Requirements steht es drin. Als Forderung der Kunden. - Die Modizifierbarkeit oder Anpasssungsfähigkeit der Software bzw. der gesamten Lösung. Gut dass man sich das immer wieder ins Gedächtnis rufen muss. Denn gern steigen die Kosten ungeplant, wenn dieser Punkt während der Entwicklung zu wenig Beachtung findet.

Auf einer ungarischen Seite fand ich zufällig etwas zu den Taktiken, Modifizierbarkeit noch besser zu planen. Modifizierbarkeit eines System in Zahlen ausgedrückt kann man als das Verhältnis zwischen Kosten und Nutzen errechnen, wenn Änderungen vorgenommen werden müssen.

Systematisch betrachtet könnte Modifizierbarkeit zusammengefasst werden als

• die Fähigkeit eines Systems mit anderen verbunden zu werden,
• seine Veränderbarkeit, wenn neue Anforderungen hinzukommen
• seine Wartbarkeit, um seinen eigenen laufenden Betrieb zu gewährleisten.

Um also bereits in der Planung einen möglichst befriedigenden Rahmen für die Modifizierbarkeit von Software zu ziehen, ist es aus Erfahrung sinnvoll, ein paar Dinge gründlich anzugehen: Wo werden mit hoher Wahrscheinlichkeit Änderungen anfallen?
Die Möglichkeiten zu erwartender Änderungen und wie diese aussehen bzw. bis wohin sie reichen, sollte schon in der Planung berücksichtigt werden. Module sollten sehr generalisiert entwickelt werden. Dann ist es später jederzeit möglich, sie in veränderte Umgebungen einzusetzen bzw. zu behalten. Ein weiterer Aspekt beim Thema langfristiger Plaung ist sicherlich, die vielen möglichen Möglichkeiten zu begrenzen. Will sagen, Ausnahmen und Abweichungen so weit es geht zu vermeiden. Und schliesslich versuche ich betreffs Vorsorge auch noch Services, die auf mehrfache Weise genutzt werden, so weit es geht zu generalisieren bzw. zu abstrahieren.

Eine umfassende und vor allem sehr detaillierte Übersicht findet man auf besagter Seite zu Modifiability Tactics.
Und gleich noch ein umfangreiches PDF zu Modifiability Tactics stellt das Software Engineering Institut zur Verfügung.