Das Richtige entwickeln – richtig gefragt

Wenn eine neue Software entwickelt oder erweitert wird, ist es ja immer eine wichtige Frage, was eigentlich entwickelt werden soll. Die Entwickler wissen es selten selbst, und auch die Kunden oder die Besteller oder die Nutzer der Software muss man gelegentlich erst ein Stück weit begleiten, bis man herausbekommt, was sie wirklich wollen und benötigen. Requirements-Engineering oder Anforderungsanalyse ist eine anspruchsvolle und wichtige Aufgabe. Oft gibt es eine sogenannte „Fachseite“, die in Zusammenarbeit mit Businessanalysten diese Anforderungen definiert.

Im reinen Wasserfallmodell hat man diesen Schritt am Anfang sehr vollständig durchgezogen und dann später auf dieser Basis die Software entwickelt, zu Korrekturzwecken gab es immerhin Änderungsanträge. Bei agileren Prozessen entwickeln sich die Details der Anforderungen oft noch während der Entwicklung weiter und solange der Teil, der gerade entwickelt wird, klar genug spezifiziert werden kann, hat man so die Möglichkeit, aufgrund der Erkenntnisse aus früheren Lieferungen etwas für die später möglichen Anforderungen zu lernen. Man sagt, dass der Appetit mit dem Essen kommt.

Es lohnt sich aber in jedem Fall, noch einen Schritt weiter zu denken. Es kommt auch oft genug vor, dass die Anforderungen durchaus schon gut genug bekannt sind. Nun ist die Erfahrung aber die, dass die Software am Ende nur 80% von dem kann, was man sich eigentlich erhofft hat und so werden die Anforderungen sicherheitshalber etwas höher gestellt, in der Hoffnung, dass von der wirklich gewollten Funktionalität dann am Ende genug da ist. Außerdem kommt es oft vor, dass Anforderungen mit einer bestimmten Implementierung im Hinterkopf gestellt werden, die sich aber später auf Seite von Softwarearchitektur oder -entwicklung als suboptimal erweist.

Hier lohnt es sich, miteinander zu reden, um die wirklichen Anforderungen in Erfahrung zu bringen. Oft stellt sich dann heraus, dass eine wesentlich robustere Implementierung möglich ist, die den eigentlichen Anforderungen, nicht aber den kommunizierten Anforderungen, gleich gut oder sogar besser genügt.

Ein Klassiker sind Tabellen, zum Beispiel für ein Gebührenmodell oder Steuern. Natürlich kann man Tabellen in Software umsetzen, man kann auch eine Möglichkeit anbieten, sie zu ändern. Diese Tabellen können aber recht groß werden und auch wenn das unter Aspekten wie Speicherverbrauch, Verarbeitungsgeschwindigkeit und Durchsatz heute in der Regel keine Rolle spielt, müssen diese Tabellen doch aktuell gehalten werden, was den Prozess zum Betrieb der Software erschwert, vor allem, wenn die Änderung der Tabellen einen Software-Update erfordern, weil sie hardcodiert sind.

Bei genauerem Nachfragen stellt sich heraus, dass die Tabelle eigentlich aufgrund einer Formel gebildet wurde und diese approximiert. Wenn man nun die Formel in die Software einbaut und vielleicht ermöglicht, dass 2-3 Parameter dazu geändert werden kann, bekommt man eine Lösung die „glatter“ ist, weil es keine solchen Sprünge mehr zwischen 4999 und 5000 gibt, was man natürlich als Vorteil erst einmal verkaufen muss, man bekommt eine besser wartbare Software, weil sie viel weniger Code braucht und weniger kaputt gehen kann, aber vor allem bekommt man im Betrieb einen Vorteil, weil man nur noch 2-3 Parameter der Formel aktuell halten muss und nicht mehr eine riesige Tabelle. Dass sich der Softwaretest vereinfacht, ist ein weiterer Vorteil.

Ein konkreter Fall betraf vor vielen Jahren eine Software für die Verarbeitung von Fahrplänen eines Verkehrsbetriebs. Das Zielsystem war für reguläre Schweizer Fahrpläne entwickelt worden, und man konnte so Linien, Routen, das sind verschiedene Fahrtverläufe innerhalb der Linie, mindestens zwei für die beiden Fahrtrichtungen, und ein gutes Dutzend Fahrzeitmuster für Hauptverkehrszeit (langsam), Nacht (schnell) u.s.w. festlegen. Das passt für mitteleuropäischen Stadtverkehr überall sehr gut. Eine kanadische Stadt weist aber eine viel niedrigere Bevölkerungsdichte auf und der Anteil der öffentlichen Verkehrsmittel an den zurückgelegten Wegen ist auch typischerweise kleiner als in durchschnittlichen mitteleuropäischen Städten. So hat man etwas, was zwischen einem Überlandverkehr und Stadtverkehr in Mitteleuropa liegt. Das Budget für den Verkehrsbetrieb ist begrenzt und man bemüht sich, trotz allem noch eine regelmäßige Bedienung der Stadtregionen zu bewerkstelligen. Dafür war eine Fahrplanerstellungssoftware vorteilhaft, die die Fahrzeiten individuell pro Fahrt wählbar macht. Die Sprachbarriere kam noch hinzu und so meinte der Schweizer Lieferant, die Kanadier sollten nur ihre Fahrplan ein bisschen aufräumen, dann würde es schon passen und die Kanadier meinten, sie wollten sich ihre gute Arbeit nicht wegen einer restriktiven Software verhindern lassen. Als das einige Zeit nach Projektbeginn festgestellt wurde, gab es erst einmal einen Scherbenhaufen.

Die Lösung war schließlich, noch einmal genau die Bedürfnisse des Kunden anzuschauen und konkret die kompliziertesten Linien unter die Lupe zu nehmen. Nun sollte die Software eine bestimmte Zuverlässigkeit bei der Verwendung der Daten erzielen. Es stellte sich am Ende heraus, dass das alles lösbar war. Hierzu musste man die Fahrzeitmuster der einzelnen Fahrten ermitteln und jeweils die häufigsten Muster in die Zielplattform übernehmen. Bei den meisten Linien reichte das aus, aber für einzelne Fahrten musste das passendste unter den übernommenen Fahrzeitmustern verwendet werden, was zu einem Fehler führte, der aber noch in die Toleranz für das Gesamtsystem fiel. Die richtige Lösung, das Zielsystem zu erweitern, um die Daten vollständig aufzunehmen, sollte man natürlich nicht aus dem Auge verlieren, was aber ein längerfristiges Projekt war. Mit so einer Kompromisslösung ließ sich dafür etwas Zeit gewinnen und letztlich die unter den gegebenen Umständen bestmögliche Lösung für alle beteiligten umsetzen.

Man sieht also, es lohnt sich auf jeden Fall, genauere Fragen zu stellen, um unter Berücksichtigung der Möglichkeiten, die man von der Softwarearchitektur im gegebenen Zeit- und Budgetrahmen hat, die wirklichen Bedürfnisse möglichst zielgerichtet zu erfüllen.