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 muß 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, daß 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, daß die Anforderungen durchaus schon gut genug bekannt sind. Nun ist die Erfahrung aber die, daß 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, daß von der wirklich gewollten Funktionalität dann am Ende genug da ist. Außerdem kommt es oft vor, daß Anforderungen mit einer bestimmten Implementierung im Hinterkopf gestellt werden, die sich aber später auf Seite von Softwarearechitektur 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, daß eine wesentlich robustere Implementierung möglich ist, die den eigentlichen Anforderungen, nicht aber den kommunzierten 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, daß die Tabelle eigentlich aufgrund einer Formel gebildet wurde und diese approximiert. Wenn man nun die Formel in die Software einbaut und vielleicht ermöglicht, daß 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 muß, 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 muß und nicht mehr eine riesige Tabelle. Daß 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 paßt für mitteleuropäischen Stadtverkehr überall sehr gut. Eine kanadische Stadt weist aber eine viel niedrigere Bevölkerungsdichte auf und der Anteil der öffentlichen Verkehrsmttel 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 bißchen 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, daß das alles lösbar war. Hierzu mußte 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 mußte 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 Kompromißlö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.

Share Button

Ein Gedanke zu „Das Richtige entwickeln – richtig gefragt

  1. Dem Argument, dass im Wasserfallmodell die Anforderungen “am Anfang sehr vollständig” betrachtet werden, widersprechen meine Beobachtungen. Im Gegenteil: Häufig vertreten techniknahe Experten die Kunden und schreiben aus dem Bauch zusammen, was die Anwender ihrer Meinung nach brauchen (könnten). Dem gegenüber verschafft agile Entwicklung schnelleres Feedback. Doch an der grundlegenden unsystematischen Art der Anforderungsentwicklung ändert das nichts.

    So kommt es auch zu den “sicherheitshalber etwas höher gestellt[en Anforderungen]“. Wer nicht weiß, was nötig ist, muss eben Sicherheitspuffer einplanen und alle Konsequenzen in Kauf nehmen.

    Ich begeistere mich für ein Vorgehen, dass mir und meinen IT-Kunden eine erschöpfende Kenntnis von den Anforderungen ermöglicht. Insofern rege ich an nicht nur “miteinander zu reden”, sondern das mit der richtigen Methoden zu machen. User Research ist mehr als Fragen zu stellen. Einen Einstieg dazu gibt es hier: http://www.apliki.de/usability-engineering/uber-software-psychologen-und-software-architekten/

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.


*