Datenvalidierung und Agile Entwicklung

1 Kommentar

Insbesondere bei der agilen Entwicklung unter Beibehaltung existierender Daten kann man leicht auf ein Problem stoßen welches ich diskutieren möchte:

Eine Kundenverwaltungsoftware für einen PC Verkäufer wird entwickelt. Die Software läuft gut, aber es häufen sich Betrugsfälle im Rahmen von Garantiefällen. Deshalb wird beschlossen bei dem Hersteller der Hardware die Seriennummer im Garantiefall gegenzuprüfen. Bei der Verwendung des Webservices des Herstellers fällt auf, daß ein Großteil der bereits erfassten Seriennummern falsch sind. Der Hersteller gibt die Validierungsroutine heraus und diese wird in die Software eingebaut. Nun wird beim Verkauf und allen weiteren Geschäftsvorfällen die Nummer geprüft. Ab diesem Zeitpunkt häufen sich die Beschwerden der Mitarbeiter, daß die Anwendung alte Kundendaten nicht mehr speichern kann. Auch das Finanzmodul verweigert jetzt seinen Dienst und kann Zahlungen für Rechnungen nicht mehr speichern.

Das Szenario zeigt, daß Bestandsdaten immer Probleme machen wenn zusätzliche Bedingungen eingeführt werden. Man könnte die Validierung auf das Userinterface beschränken und so das Finanzmodul funktionsfähig halten, jedoch hilft dies für die andere Hälfte der Probleme nicht.

Auch automatische Datenkorrekturen sind nicht immer erfolgreich, da oft Information einfach fehlt.

Ein Patentrezept gibt es leider nicht, jedoch hat sich folgende Prozedur bewährt:

  1. Vor dem Hinzufügen der Regel alle Bestandsdaten welche Fehlerhaft sind korrigieren soweit möglich
  2. Regeln für einen gewissen Zeitraum nur als Warnung, nicht als Fehler prüfen.
  3. Regeln anhand von weiteren Parametern, welche alte Datensätze ausschließen, anwenden
  4. Beim Design von Datenfeldern zeitnah Validierung hinzufügen

Was für Erfahrungen habt Ihr gemacht. Gibt es ein Vorgehen welches das Auftreten von solchen Dateninkonsistenzen vermeidet?

Fabian Lange ist Lead Agent Engineer bei Instana und bei der codecentric als Performance Geek bekannt. Er baut leidenschaftlich gerne schnelle Software und hilft anderen dabei, das Gleiche zu tun.
Er kennt die Java Virtual Machine bis in die letzte Ecke und beherrscht verschiedenste Tools, die JVM, den JIT oder den GC zu verstehen.
Er ist beliebter Vortragender auf zahlreichen Konferenzen und wurde unter anderem mit dem JavaOne Rockstar Award ausgezeichnet.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Thomas

    Wenn man diese Art Problem kommen sieht wäre es vielleicht eine Möglichkeit vorab mit einem Skript den gesamten Bestand auf Konsistenz gegen die neue Validierungsroutine zu prüfen. Dies könnte evtl. sogar nachträglich noch nützlich sein, um zu sehen wieviele Datensätze betroffen sind. Damit könnte man dem Kunden dann auch eine Liste an die Hand geben, um die Umsetzung von Punkt 1 ggf. zu erleichtern.

    Punkt 2 könnte man noch verschärfen indem sich Datensätze zwar anzeigen lassen, aber eine Speicherung im UI nur erlaubt wird, wenn auch die Seriennummer korrigiert wird. Andernfalls ist die Frage wie man erreichen kann, dass man irgendwann den Datenbestand konsistent hat, da Warnungen von Benutzern in solchen Fällen denke ich gerne und dauerhaft 😉 ignoriert werden.

    Punkt 3 könnte vor Allem dann eine gute Lösung sein, wenn der Datenbestand sich relativ schnell erneuert, d.h. alte fehlerhafte Datensätze fallen heraus und für neue Datensätze wird die korrekte Eingabe „erzwungen“. Ansonsten bräuchte man auch hier einen begleitenden Prozess, um „irgendwann“ auf einen konsistenten Stand zu kommen.

    Für die agile Entwicklung wirft Punkt 4 eine echt interessante Frage auf. Eine erste Version ohne Validierung ausliefern oder nicht? Wenn viele Daten schnell ins System „eingegeben“ werden kann schon nach einer Iteration (z.B. 14 Tage) jede Menge „Schrott“ im System sein. Ich denke die Entscheidung ist abhängig von der Datenmenge und dem Aufwand diese Daten nachträglich zu korrigieren (und wie dringend der Kunde das System in Benutzung nehmen möchte). Eine weitere – agile – Möglichkeit könnte es sein den Kunden vorab auf das – mögliche – Problem hinzuweisen und idealerweise dann gemeinsam zu entscheiden :).

Kommentieren

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