Formularplanung und Qualitätsmanagement

Die Formularerstellung ist jedoch sehr häufig ein Thema, was in seiner Komplexität und seinen zeitlichen Anforderungen vom Fachbereich und vom Projektmanagement unterschätzt wird.

In aller Regel weiß der Kunde, er brauchtFormulare (z. B. Rechnung, Lieferschein, Kundenauftrag etc.), einen oder mehrere Formularentwickler, Berater zur fachlichen Unterstützung und den Fachbereich, um die fachlichen Vorgaben zu machen und das Formular zu testen.

Ein Gesamtkonzept gibt es in aller Regel nicht. Wenn es gut läuft, gibt es eine Designvorlage und ein paar Seiten zur Spezifikation - und dann gehts los ...

Dieses Vorgehen funktioniert grundsätzlich. Aber erfordert sehr viel Zeit. Meist gibt es 15 bis 30 Formulare, die praktisch alle laufenden Geschäftsprozesse mit Formularausgaben abdecken. Hier wiederholen sich verschiedene Aufgaben und es lohnt sich, die wiederholen Programm-/Formularteile zu identifizieren und Struktur in die Formularentwicklung zu bringen.

Quick & Dirty versus Struktur

Der Kunde sollte sich nicht ausschließlich auf den gewünschten Formularinhalt beschränken, sondern auch kritisch die Arbeit der Formularentwickler prüfen.
Wenn die Formularentwickler, Berater und das Projektmanagement immer nach dem Motto „Quick & Dirty“ vorgehen, dann wird schnell nur noch das „Dirty“ übrigbleiben und Formularänderungen in einer fortgeschrittenen Projektphase stets zeitlich aufwendig und fehlerträchtig sein.
Geht der Formularentwickler strukturiert vor, modularisiert sauber sein Coding und etabliert Standards, die sich von Formular zu Formular wiederholen, wird die Formularentwicklung in einer deutlich höheren Qualität erfolgen und Anpassungen werden wesentlich schneller und weniger fehlerträchtig sein.
Beginnt man gleich den Code in Moduleinheiten (wie Form-Routen oder Methoden) zu schreiben, benötigt das nur minimal mehr Zeit in dieser Anfangsphase, als wenn man den Code in einer sehr großen Programmeinheit untereinander weg schreibt. Am Beginn der Entwicklung gibt es auch keine Gefahr eine bestehende Funktionalität zu verschlechtern, da man erst dabei ist die Funktion zu erstellen. Daher ist dringend zu raten nicht erst auf eine spätere Refakturierung zu spekulieren, sondern gleich mit sauberen Moduleinheiten zu beginnen. Beginnt man gleich mit sauberen Modularisierungseinheiten benötigt man am Anfang nur wenige Minuten mehr, aber später spart man 80% der Zeit bei Fehleranalysen und Anpassungen im Vergleich zu großen Programmeinheiten.
Auch das Debugging eines Druckprogramms wird durch das Schreiben von Unterroutinen/Modularisierungseinheiten wesentlich leichter und schneller, weil man beim Debuggen viele Unterroutinen mit F6 als eine Einheit ausführen kann und man erst dann durch in die Unterroutine mit F5 springen muss, die im konkreten Einzelfall von Relevanz ist.
Ein kritscher Faktor bei der Formularerstellung kann der Zeitdruck sein, der durchs Projektmanagement vorgegeben wird. Bei komplexen Formularen ist der Zeitaufwand zur Erstellung eines Formulars hoch und nur extrem schwer zu schätzen. Wird ein sehr kurzfristiger Fertigstellungstermin für ein komplexes Formular vorgegeben, noch gern mit den Worten „Komme was wolle, dass muss am .. fertig sein“, dann baut man einen Druck auf, der meist die Codingqualität mindert, am Ende zudem meist auch die Fertigstellung verzögert wird und zur Unzufriedenheit bei allen Parteien führt. Für sehr komplexe Formulare, wie z. B. die Rechnung, benötigen auch erfahrene Formularentwickler mehrere Monate, bis das Formular ausgereift ist. Das Formular wird hier über einen längeren Zeitraum Korrekturen und Erweiterungen erfahren, bis die Zahl der gemeldeten Fehler sehr gering wird.

Refakturierung

Der Formularentwickler sollte auch den Mut haben bestehenden „Spagetthi-Code“ zu überarbeiten. Code, wo z. B der Code in einzelnen Programmeinheiten Tausende Codingzeilen umfasst, ist extrem schwer zu warten und jede Programmänderung bringt die Gefahr mit sich, die bestehende Funktionalität massiv zu beeinträchtigen.
Es ist jedoch nicht möglich umfangreichen Spagetthi-Code in einem Arbeitsgang in gut strukturierten Qualitätscode zu refakturieren. Die Überarbeitung erfordert Zeit und sollte Stück für Stück erfolgen, mit jeweils Tests, dass die Funktionalität des Formulars nicht beeinträchtigt wurde.
Im Buch „Der pragmatische Programmierer“, von David Thomas, Andrew Hunt u. a. wird diese Problemstellung des Spagetthi-Codes, bzw. der Refakturierung sehr schön und nachvollziehbar diskutiert. Man sollte den Code bei jeder Überarbeitung ein wenig besser hinterlassen als man ihn vorgefunden hat.
Das beständige Bemühen um besseren Code bewirkt letztlich eine hohe Qualität des Codings und eine sehr gute Wartbarkeit des Codes.
Als Faustregel sollte man ca. 10% der Zeit der Formularentwicklung in die Refakturierung des Codes investieren.