Immer wieder gern gemacht: Die grössten Fehler bei Informatik-Projekten

Folge 2

Mangelnde Anforderungsermittlung

Weit verbreitet bei Software Anwendungen ist die folgende Einstellung:

Wir bauen rasch ein App damit wir sehen können, wie wir sie einsetzen.

Dann enwickeln wir sie so weiter, wie wir sie brauchen können.

Diese Vorgehensweise führt zu weitreichenden Konsequenzen:

  1. Kostenexplosion
  2. Zeitliche Verzögerungen und Unklarkeit wann etwas fertig wird

Kostenexplosion und Zeitverzögerung

Warum ist das so?

Damit eine App erweitert und geändert werden kann muss sie eine gute Erweiterbarkeit und Änderungsfähigkeit haben. Dies sind zwei wichtige Kriterien von guter Software und ergibt sich nicht von selbst. Je schneller etwas auf einen Bildschirm gezaubert wird, desto weniger kann man sich um die Innereien kümmern. Im Extremfall ist es ein Fake mit Buttons und Icons, das zwischen Ansichten hin und her schaltet. Das faken von Funktionalität kostet viel Aufwand und vor allem: Es bringt der Weiterentwicklung nichts.

Das ist nicht erst so seitdem wir Anwendungen als App bezeichnen. Aber gute Anwendungen zu bauen erfordert Knowhow, Erfahrung und entsprechende Vorbereitung. Falls es überhaupt möglich ist. Haben Sie schon mal eine App aus dem Store versucht für Ihre Zwecke zu erweitern?

Warum Quick und Dirty nicht funktioniert

Eine halbgare Funktion abzuändern ist viel schwieriger als sie gleich neu zu machen. Jeder Entwickler kann ein Lied davon singen. Um wieviel Mehraufwand es geht hängt davon ab, wie leicht sie sich ändern lässt.

Das führt bei manchen zu der Folgerung: Dann bauen wir die App halt neu.

Warum ist das keine gute Idee?

Wenn Sie eine App zehn mal neu bauen, haben Sie die zehnfachen Kosten. Manchmal sogar noch mehr, je nachdem wie Sie arbeiten: Wenn eine App handwerklich gebaut ist, müssen jedesmal die Coder neu Hand anlegen und das gleiche ein weiteres mal tun. Selbst wenn die App in drei Wochen zusammengeklopft wurde, sind Sie schon bei dreissig Wochen Aufwand um sie immer wieder neu zu erstellen. Dann ist das Jahr bald vorüber.

Daher liegt es auf der Hand, nicht jedesmal das gleiche neu zusammenzumeisseln. Software Entwicklung ist kein Handwerk denn es gibt smartere Vorgehensweisen.

Eine Möglichkeit ist, die Anwendung nicht mit der Hand zu programmieren sondern sie zu generieren. Also einen Code Generator einzusetzen. Viele Hersteller von Business Software nutzen Generatoren, um spezifische Applikationen zu erzeugen. Die bekommt man aber leider nicht geschenkt. Es sei nur das Stichwort SAP genannt um den Umfang der Kosten zu skizzieren.

Das bedeutet, Sie bauen selbst einen Generator um nicht jedesmal das Rad neu zu erfinden? Das erfordert Knowhow, Erfahrung und entsprechende Vorbereitung. Es braucht etwa 3 bis 6 Monate Grundlagenarbeit und ein Team von Software Architekten, Admins und Entwicklern. Meist wird es in die Entwicklungsumgebung (IDE) und in den Build eingebunden und erzeugt kontinuierlich die neueste Version. Eine gute Idee! Mit der quick and dirty Idee ist es aber erst mal nichts.

Daher die zweite Möglichkeit: Wir bauen die Applikation so, dass sie gut erweiterbar und änderbar ist. Bestehende Teile sollen wiederverwendet werden können.

Wie geht das?

Die Antwort: Die App muss modular aufgebaut sein, also eine gute Architektur haben. Eine modulare Anwendung erlaubt es, bestehende Teile immer wieder zu verwenden und einzelne Teile erweitern, verändern oder auswechseln zu können. Die Teile einer solchen App nennt man Module. Als ganzes ist sie dann modular. Dies von vornherein zu beachten möglichst bevor der erste Teil fertig ist, erfordert Planung in der Vorbereitung und eine gute Portion Erfahrung.

Ohne diese Unabhängigkeit kann man nicht von Modulen sprechen wenngleich es schick ist, die Bestandteile so zu nennen (ähnlich wie „Service“ oder eben „App“).

Die Lösung für das Problem

Das heisst also, die quick and dirty Idee geht gar nicht. Eine schnelle billige App ist für den Kehricht, wenn sie nicht kostengünstig verändert werden kann. Die Lösung ist eigentlich einfach: Ermitteln Sie das, was Sie brauchen bevor Sie anfangen zu programmieren. Das was man braucht nennt sich „Anforderungen“.

Hierzu ein Beispiel eines Kundenprojekts, das mich letztens erreichte. Es ist alltägliches Geschehen in der Anwendungswelt und veranlasste mich zu diesem Artikel. Spät abends kam eine E-Mail mit einer kritischen Fehlermeldung. Es ging um eine Anwendung aus dem Personalbereich und um eine halbfertige Mitarbeiter-Beurteilung. Ein Mitarbeiter konnte seine Bewertung einsehen, obwohl der Vorgesetzte erst im Entwurfsstadium war und einzelne Absätze mit Copy-Paste aus einer anderen Bewertung übernommen hatte. Das passte noch nicht und sollte erstmal nur Schreibarbeit sparen und einen Vorentwurf abspeichern.

Genauso könnte das in einer Applikation im Kundenkontakt oder im Unternehmensportal mit einer Kommunikationsmeldung passiert sein. Oder in der Fahrzeugverwaltung passiert eine Doppelbuchung gerade dann, wenn zwei Vertriebsmitarbeiter zum wichtigen Kundentermin müssen.

Im Prinzip geht es um eine Fehlfunktion, die nicht sein darf und erhebliche Konsequenzen haben kann. Die Fehlermeldung hatte einen typischen Satz am Ende. Dieser war fett und rot markiert:

„Das war so nicht gedacht!“

Nun kann der Entwickler zurückfragen: „Wo steht das“? Die ehrliche Antwort: „Haben wir nicht aufgeschrieben.“ Eine häufige Antwort in solchen Fällen ist auch: „Das ist doch selbstverständlich.“

Und hier liegt das Problem: Entwickeln Sie eine Anwendung für einen Fachbereich und seien Sie so gut über alle fachlichen Aspekte informiert, dass Sie alles abdecken können, was in dem Fachbereich als selbstverständlich gelten könnte. Also: Seien Sie genauso qualifiziert wie der Fachexperte und sehen Sie alle Fälle voraus. Und haben Sie alles im Kopf, was passieren könnte und welche Konstellationen es geben könnte!

Sie sehen schon: Das geht nicht. Denn daneben sollte man noch Informatiker sein und auf seinem eigenen Fachgebiet ein Experte.

Die Lösung: Aufschreiben!

Am besten hilft das folgende Mantra:

Anforderungen müssen aufgeschrieben werden, sonst existieren sie nicht.

Zum Glück konnte in dem Fall schon am nächsten Tag geholfen werden. Die Anwendung konnte sogleich angepasst werden. Ein Filter in der Anzeige, dass nur freigegebene Bewertungen vom jeweiligen Mitarbeiter eingesehen werden können hat das Problem gelöst. Aber nur, weil die Anwendung ein Freigabekonzept hatte, in der Lage war, mit Filtern zu arbeiten und ein Rollenmodell hatte, das „wusste“, wer ein Vorgesetzter ist und welche Mitarbeiter dieser jeweils hat.

Freigaben, Rollenmodell und Filter sind Architekturkonzepte die es ermöglichen, modulare Apps zu entwickeln.

Weitere Vorteile

Anwendungsmanagement hat noch weitere Vorteile: Wenn man Requirements ausdrücklich vorliegen hat und drüber nachdenkt, sieht man auch Lücken und Widersprüche. Es ist erheblich günstiger, über Widersprüche nachzudenken, bevor nach Mannmonaten von Entwicklung diese in der Applikation auftauchen. Denn dann hat man wieder für den Kehricht programmiert.

Zugegeben, Anforderungsmanagement ist nicht einfach. In der Fachliteratur spricht man auch von Requirements Management. Bei schwierigen Aufgaben neigt man dazu, sie zu vermeiden oder wenigstens zu verschieben. Aber dadurch verlagert man das Problem nur auf später und lässt derweil viel Aufwand den Bach runter gehen, der gar nicht hätte sein müssen.
Siehe dazu: Hier geschieht ein Wunder

Wenn Sie diese Fehler vermeiden, bekommen Sie bessere und günstigere Applikationen und sind gleich noch schneller als der Wettbewerb.