Henning Bösch: Programmierfehler bei ALG II Software

Hallo,

http://www.spiegel.de/wirtschaft/0,1518,335124,00.html

Da wurde wohl mit der heißen Nadel gestrickt und die Testphase ausgelassen. Bei Kontonummern die führenden Nullen hinten anzufügen, hätte dann eigentlich auffallen müssen.

Muss mit den Kontonummern eigentlich im späteren Verlauf noch gerechnet werden? Wäre es in diesem Fall sinnvoll mit einer Stringvariablen zu arbeiten, da man dort die führenden Nullen direkt eingeben kann und diese dann nicht verloren gehen?

Gruß,
Henning

  1. Nabend,

    Muss mit den Kontonummern eigentlich im späteren Verlauf noch gerechnet werden? Wäre es in diesem Fall sinnvoll mit einer Stringvariablen zu arbeiten, da man dort die führenden Nullen direkt eingeben kann und diese dann nicht verloren gehen?

    Ich glaube, das werden auch schon Strings gewesen sein. Das Problem wird wohl daran liegen, dass die Kontodaten mal mit und mal ohne führenden Nullen in die Datenbanken aufgenommen werden und der große Fehler jetzt bei der 'Normierung' dieser Daten für die Banken aufgetreten ist.

    Gruß
    Christian

  2. Hi,

    http://www.spiegel.de/wirtschaft/0,1518,335124,00.html

    Da wurde wohl mit der heißen Nadel gestrickt und die Testphase ausgelassen.

    man muss wissen, dass der Staat sowieso ein schlechter Abnehmer von Entwicklungsleistungen ist. Das Interesse eines Beamten an der Qualitaet der erbrachten Leistung ist naturgemaess geringer als das von Abnehmern in der Privatwirtschaft. Aus eigener Erfahrung kann ich berichten, dass Abnehmer sich oft nur versuchen "abzusichern" (d.h. sich in eine Position zu bringen, in der ihr kein Fehler nachgewiesen werden kann), also ihrer Abnehmerrolle aus verschiedensten Gruenden (mangelndes Interesse, Faulheit, Inkompetenz, aus strategischen Ueberlegungen heraus) nicht gerecht werden. - Und die Entwickler setzen in aller Regel exakt das um, was angefordert ist.

    Bei Kontonummern die führenden Nullen hinten anzufügen, hätte dann eigentlich auffallen müssen.

    Das riecht nach COBOL-Datenhaltung.

    Muss mit den Kontonummern eigentlich im späteren Verlauf noch gerechnet werden?

    Es gibt da Plausibilitaetskontrollen, also es kann anhand einer BLZ und einer Kontonummer festgestellt werden, ob die Kombination der beiden ueberhaupt zulaessig ist. Das ist u.a. implementiert um beim OCR erfolgreicher sein zu koennen.

    Wäre es in diesem Fall sinnvoll mit einer Stringvariablen zu arbeiten, da man dort die führenden Nullen direkt eingeben kann und diese dann nicht verloren gehen?

    Eine "Stringvariable" soll in diesem Zusammenhang wohl heissen: die Einstellung Zeichenkette in der Datenbankschicht. - Nun, das sind Fragestellungen, die sich aus der Ferne oft nicht kompetent bearbeiten lassen. Ist zum Beispiel klar, das nur Ziffern Teil einer Kontonummer sein koennen, waere die Einstellung "NUMERIC (9)" (bei Maximallaenge 9) praeziser und guenstiger fuer die Datenkonsistenz.

    Im geschilderten Fall - so wie uebrigens auch bei der Maut-Katastrophe - sehe ich also die Schuldigen (erst einmal) immer im Abnehmerbereich, gerade auch dann, wenn der Staat mitmischt.

    Gruss,
    Ludger

    1. Hi Ludger,

      Bei Kontonummern die führenden Nullen hinten anzufügen, hätte dann eigentlich auffallen müssen.
      Das riecht nach COBOL-Datenhaltung.

      Warum? Sowas passiert immer wieder, ein typisch menschlicher Fehler. Das Hauptproblem scheint mir zu sein, dass dort unter massivem Zeitdruck gearbeitet wurde und keine Zeit zum Testen da war.

      Im geschilderten Fall - so wie uebrigens auch bei der Maut-Katastrophe - sehe ich also die Schuldigen (erst einmal) immer im Abnehmerbereich, gerade auch dann, wenn der Staat mitmischt.

      Weiß ich nicht. Irgendein Unternehmen ist für diesen Fehler verantwortlich, fraglich ist natürlich, ob die Verträge bei einem solch elementaren Fehler Konsequenzen vorsehen. Ein besonderer Vertrag, der die Korrektheit der Erfassung von Bankdaten feststellt, dürfte wohl auch im privaten Bereich kaum üblich sein. Es dürfte wohl lediglich festzuhalten sein, dass die Software in der Lage sein muss, Überweisungen vorzunehmen.

      Das Problem mit den Bankdaten ist, dass der Fehler nicht ins Auge springt, wenn man die produzierten Daten in AUgenschein nimmt. Ein weiteres Problem dürfte die Reperatur sein, wenn man lediglich die Resultate, nämlich die falschen Kontonummern, gespeichert hat, nicht aber die entsprechenden Ausgangsdaten. Sowas kommt durchaus vor: !976 habe ich das mal bei Siemens Dortmund erlebt, allerdings in einer deutlich blöderen Variante, da ein Progger bei der Umstellung der Bankleitzahlen auf das heutige System den winzigen Fehler gemacht hatte, erst die alten BLZs zu löschen und dann die neuen daraus zu errechnen. Da man das auch erst zu spät gemerkt hatte, durften damals tatsächlich sämtliche Bankleitzahlen der Kundendateien von Hand von den begeisterten Mitarbeitern neu eingegeben werden, natürlich wie auch heute wieder unter großem Zeitdruck *g*

      Tatsächlich mehren sich Beispiele für schwache Auftraggeberleistungen des Bundes und der Arbeitsverwaltung im Softwarebereich (Agentur für Arbeit, Toll Collect), das Hauptproblem scheint mir aber im irren Zeitdruck zu liegen, unter dem hier komplexe Systeme erstellt werden sollen. Tatsächlich sollte man aber Firmen, die vorgeben, mit dieser Zeit zurechtzukommen, auch in die Pflicht nehmen.

      Viele Grüße
      Mathias Bigge

      1. Hallo,

        Tatsächlich mehren sich Beispiele für schwache Auftraggeberleistungen des Bundes und der Arbeitsverwaltung im Softwarebereich (Agentur für Arbeit, Toll Collect), das Hauptproblem scheint mir aber im irren Zeitdruck zu liegen, unter dem hier komplexe Systeme erstellt werden sollen. Tatsächlich sollte man aber Firmen, die vorgeben, mit dieser Zeit zurechtzukommen, auch in die Pflicht nehmen.

        Ich kenne die tatsächlichen Entscheidungsabläufe nicht, aber ist es nicht eher so das politisch ein Datum festgesetzt wird an dem das Neue (Gesetz, System o.ä) in Kraft treten soll und dann zur Umsetzung ausgeschrieben wird?
        Wenn schon im Voraus klar ist (zumeist auf Firmenseite), dass die Deadline völlig illusorisch ist, wie es z.B. bei Toll Collect anscheinend der Fall war, finde ich das schon grob fahrlässig. Zumal der Schaden bei Projekten auf Bundesebene schnell in den Millionen ist.

        Schadensersatz in welcher Höhe musste Toll Collect für die letzten 1,5 Jahre eigentlich leisten und welcher Verlust ist für den Bund eingetreten. Kann man das irgendwo nachlesen?

        Gruß,
        Henning

        1. Moin,

          Ich kenne die tatsächlichen Entscheidungsabläufe nicht, aber ist es nicht eher so das politisch ein Datum festgesetzt wird an dem das Neue (Gesetz, System o.ä) in Kraft treten soll und dann zur Umsetzung ausgeschrieben wird?

          Nein, das wäre vollkommener Unsinn.
          Ein Angebot enthält immer ein Dauer und ein fertigstellungstermin.
          Und da alle größeren Geschichten ausgeschrieben werden, gibt es auch immer Firmen die behaupten den Termin halten zu können.
          Da Projekte im EDV Bereich aber auch von den Zuarbeiten des Auftraggebers abhängen, muß es eine Entscheidungsstelle seitens der Auftraggeber geben, die erstens Kompetent genug ist diese Entscheidungen auch treffen zu können, und die zweitesn dazu auch befugt ist.
          Daran haperts im Öffentlichen Dienst häufig, und das ist einer der hauptgründe für das Scheitern solcher Projekte.

          Wenn schon im Voraus klar ist (zumeist auf Firmenseite), dass die Deadline völlig illusorisch ist, wie es z.B. bei Toll Collect anscheinend der Fall war, finde ich das schon grob fahrlässig. Zumal der Schaden bei Projekten auf Bundesebene schnell in den Millionen ist.

          nanana Toll Collect hat das Konzept entwickelt und Toll Collect hat den Termin angeboten.
          Und Toll Collect hat versagt. Außerdem vermischt Du gerade Äpfel und Birnen.

          Schadensersatz in welcher Höhe musste Toll Collect für die letzten 1,5 Jahre eigentlich leisten und welcher Verlust ist für den Bund eingetreten. Kann man das irgendwo nachlesen?

          Nein das wird erst im nächsten Jahr entschieden.

          TomIRL

      2. Hi,

        Bei Kontonummern die führenden Nullen hinten anzufügen, hätte dann eigentlich auffallen müssen.
        Das riecht nach COBOL-Datenhaltung.
        Warum? Sowas passiert immer wieder, ein typisch menschlicher Fehler. Das Hauptproblem scheint mir zu sein, dass dort unter massivem Zeitdruck gearbeitet wurde und keine Zeit zum Testen da war.

        COBOL-Datenhaltung, weil beim Fuellen von COBOL-typischen numerischen Datenfeldern (z.B. "PIC 9(9)") amuesanterweise mit Nullen aufgefuellt wird. Woanders habe ich sowas noch nicht gesehen.

        OK, massiver Zeitdruck. Ja, ja. Dieser entsteht aber in der Regel dadurch, dass die Anforderungsspezifikation und der ins Auge gefasste Umsetzungstermin nicht zusammenpassen. Und ich wette darauf, dass den Aemtern bereits vor laengerer Zeit eine Testversion bereitgestellt worden ist und der Fehler schon laengst haette erkannt werden koennen. (Zugegebenermassen etwas spekulativ, aber es ist oft so, dass "Prerelease-Versionen" vom Abnehmer schlicht ignoriert werden. Von denselben Abnehmern, die dann spaeter ganz ganz laut klagen und jammern.)

        Gruss,
        Ludger

        1. Hi Ludger,

          OK, massiver Zeitdruck. Ja, ja. Dieser entsteht aber in der Regel dadurch, dass die Anforderungsspezifikation und der ins Auge gefasste Umsetzungstermin nicht zusammenpassen. Und ich wette darauf, dass den Aemtern bereits vor laengerer Zeit eine Testversion bereitgestellt worden ist und der Fehler schon laengst haette erkannt werden koennen.

          Sicher, aber das lsutige an Kontonummern und ähnlichem Zeug ist, das die Probeausgaben eben für den Menschen, der da mal drüberguckt, erstmal plausibel aussehen....

          Viele Grüße
          Mathias Bigge