Update 2023

Dieser Artikel wurde ursprünglich Ende 2018 verfasst. Jetzt, im Jahr 2023, werden weitere Informationen gemeldet.    Update vom April 2023 bei Computer Weekly

Was wir jetzt wissen, ist, dass es „einige Probleme“ gab, also Fehler, die verschiedene Kundengruppen auf unterschiedliche Weise betrafen. Sie brauchten mindestens sieben Monate, um das Problem zu lösen. Wir können die Gesamtzahl der Fehler nur schätzen, aber sie dürfte zwischen 4 und 140 liegen. Wir wissen das, weil es mindestens 4 gemeldete Fehlerszenarien gibt und die wahrscheinlichste Anzahl von Fehlern, die in einem stark beanspruchten Produktionssystem repariert werden können, etwa 1 pro Tag beträgt, unabhängig von der Teamgröße.

Kosten der Qualitätsbewertung

Es kostete TSB 32,7 Mio. £ an Wiedergutmachung für die Kunden, zuzüglich einer Geldstrafe von 18,9 Mio. £, und wir können den technischen Aufwand auf etwa 3,2 Mio. £ und die weiteren Auswirkungen auf das Kundendienstpersonal auf etwa 52 Mio. £ schätzen (1 Anruf zu 10 £ pro Kunde möglich). Hinzu kommen die Opportunitätskosten, die dadurch entstehen, dass das Problem gelöst werden muss, anstatt die Bank voranzubringen. Und schließlich wird die Bank dadurch einige Kunden verloren haben.

Die geschätzten Gesamtkosten liegen offenbar bei über 100 Millionen Pfund. Dadurch belaufen sich die Kosten pro Defekt auf etwa 1 Mio. £ pro Defekt, der vor der Produktivsetzung nicht entdeckt wurde.

Wie könnte es vermieden werden?

Wenn Sie das Fehlerpotenzial eines Softwareprojekts kennen, können Sie feststellen, wie viele Fehler Sie finden müssen, bevor Sie mit der Inbetriebnahme beginnen können. Es ist vorhersehbar. Mithilfe verschiedener Techniken, bei denen es um die Kenntnis des Funktionsumfangs der Software, der Fehlerpotenziale, der Fehlerrisikobereiche, der Fehlererkennungsraten, der Testabdeckung und mehr geht, können wir ermitteln, welche Arten von Tests erforderlich sind und wie viele Tests ausreichen, um ein zufriedenstellendes Ergebnis zu erzielen Qualität. Der Punkt ist, dass die schreckliche Situation sowohl vorhersehbar als auch vermeidbar war. Es ist auch interessant, sich die Karriere von Carles Abarco auf LinkedIn anzusehen, nirgends taucht das Wort Qualität auf.

Was ist eine angemessene Prüfung im Jahr 2023?

Das können wir anhand der Gespräche nur vermuten könnte hat stattgefunden:

Geschäftsführer: „Haben Sie genug Tests durchgeführt?“

Technik: „Ja, hier sind die Hunderte von Tests, die wir durchgeführt haben und die alle bestanden haben.“

Geschäftsführer: „Gut, sind Sie also zuversichtlich, dass es in Ordnung ist, live zu gehen?“

Technik: "Sicher."

Der Misserfolg war sowohl vorhersehbar als auch vermeidbar. Es hätte vor der Migration wahrscheinlich nur ein paar Monate gedauert, diese Fehler zu finden und zu beheben. Zweifellos wünscht sich jeder, er hätte diese zwei Monate mit der Lösung dieser Probleme verbracht. Ich frage mich, was TSB misst und Sabadell setzen wir jetzt dafür ein, dass sich dieses Szenario nicht wiederholt?

Colin Hammond, April 2023

Die Nachricht, dass TSB falsche Transaktionen auf den Konten von Personen anzeigt, ist ein Beweis dafür, dass ein Softwareprojekt aufgrund schlechter Arbeitsqualität schief gelaufen ist. Warum ist das so und wie hätte es vermieden werden können? Die zugrunde liegende Ursache könnte in einer Reihe von Möglichkeiten liegen. In diesem Artikel untersuche ich einige der wahrscheinlichsten und die Lehren, die wir daraus ziehen können.

Legacy-Systeme unter Druck

Das Herzstück der meisten Banken und großen Finanzinstitute ist Software, die ursprünglich vor langer Zeit geschrieben wurde und sich als sehr zuverlässig erwiesen hat. Wir nennen diese Legacy-Systeme und da wir unterschiedliche Möglichkeiten für den Zugriff auf unsere Bankdaten fordern, funktioniert der zugrunde liegende Code dieser Legacy-Systeme auf eine Weise, die sich die ursprünglichen Entwickler nie vorgestellt oder beabsichtigt hätten. Dies kann in seltenen Fällen zu Fehlern führen.

Pflege veralteter Technologien

Die meisten dieser alten Systeme sind in alten Technologien geschrieben, beispielsweise in einer Sprache namens COBOL. Die meisten COBOL-Entwickler sind inzwischen im Ruhestand und es gibt nur sehr wenige junge Leute, die sich dafür begeistern, solch tote Sprachen zu lernen. Daher mangelt es an hochqualifizierten Entwicklern für diese Altsysteme.

Risiko führt zur Abstraktion

Die Migration von Altsystemen auf neuere Technologien ist schwierig und riskant. Die Planung und Umsetzung kann Jahre dauern. Der Austausch eines Kernsystems kann potenziell so störend sein, dass das Management davon ganz absieht. Eine Taktik, um es Banken zu ermöglichen, den Nutzern neue Funktionen anzubieten, besteht darin, diese alten Systeme mit einer Technik namens Abstraktion zu umhüllen. Sie werden als „Black Box“ behandelt und wir müssen uns keine Gedanken darüber machen, wie sie funktionieren, wir müssen uns nur auf ihre Ein- und Ausgänge verlassen können. Diese Technik verschiebt die eventuelle Notwendigkeit, diese Systeme zu ersetzen.

Architektur und Komplexität

Wenn neue Bankprodukte geschaffen werden, „hängen“ immer mehr abhängige Systeme an der Altlastenkette fest und erzeugen so ein immer komplexeres Bild davon, wie Daten zwischen diesen Systemen bewegt werden. Überkomplexe Systeme können die Ursache vieler Fehler sein. Eine gute IT-Architektur hilft, dieser Komplexität und den damit verbundenen Risiken entgegenzuwirken bzw. sie einzudämmen.

Entwickelter Code

An Systemen, die es schon lange gibt, haben viele Programmierer im Laufe der Jahre oft herumgebastelt. Manchmal gibt es nur wenig Wissen von einem Entwickler zum nächsten. Der Neue versteht nicht, was der Letzte getan hat, und er zögert, vorhandenen Code zu ändern, für den Fall, dass er ihn kaputt macht. Stattdessen schreibt er neuen Code, der neben dem alten Code steht. Wahrscheinlich machen beide Codesätze das Gleiche, aber was passiert, wenn der nächste Entwickler hinzukommt, er kann nicht sicher sein, an welchem Code er arbeiten soll. Dies ist eine der Möglichkeiten, wie sich Komplexität aufbauen kann.

Tests allein reichen nicht aus, um die Qualität sicherzustellen

Studien zu Tausenden von IT-Projekten liefern uns den Beweis, dass Tests allein nicht ausreichen, um sicherzustellen, dass alle Fehler gefunden wurden. Tatsächlich werden Tests bestenfalls selten mehr als 85% an Fehlern finden. Das Testen muss durch andere Formen der Qualitätsverbesserungstechniken ergänzt werden, die potenzielle Fehler identifizieren können, noch bevor Sie mit dem Testen beginnen. Zu den effektivsten zählen statische Analysen und formelle Überprüfungen, die Anforderungen, Architektur, Design und Code abdecken.

Testen Sie, ob es nicht das tut, was es nicht tun sollte

Angenommen, Sie führen eine Transaktion in Ihrer Banking-App durch, die Verbindung geht verloren und nur die Hälfte der Anweisung wird an die Bank gesendet. Wie geht das System der Bank mit einer halben Instruktion um? Wenn dieses System mit einem Altsystem verbunden ist, wie geht das Altsystem mit einer unvollständigen Anweisung um? Wenn wir eine Systemänderung vornehmen, testen wir immer, ob das neue System das tut, was es tun soll. Wir müssen auch sicherstellen, dass es nicht das tut, was es nicht tun sollte. Diese Art von Tests wird oft übersehen.

Komprimierter Stundenplan

Zweifellos wurden die von TSB durchgeführten Arbeiten zur Systemmigration ausführlich getestet. Bei all diesen Projekten stand das Team jedoch unter einem gewissen Zeitdruck, seine Arbeit bis zu einem bestimmten Datum abzuschließen. Ein komprimierter Zeitrahmen ist eine der häufigsten Ursachen für das Scheitern von IT-Projekten.

Technische Fähigkeiten

Codieren ist kreative Arbeit, die Können und Erfahrung erfordert. Beispielsweise gibt es viele Möglichkeiten, dasselbe Ergebnis zu codieren. Ein Codierer kann eine Reihe von Funktionen in nur ein oder zwei Zeilen erreichen, ein anderer muss möglicherweise fünfzig schreiben. Im Großen und Ganzen ist kompakterer/prägnanterer Code tendenziell von höherer Qualität. Die Fähigkeiten der Entwickler variieren dramatisch. Vergleichen Sie einen Sänger, der eine perfekte Tonhöhe hat, mit einem anderen, der nicht einmal eine Melodie tragen kann. Beide bezeichnen sich selbst als „Sänger“. Entwickler mit geringer Kompetenz können mehr Fehler als Korrekturen oder Funktionen einbringen.

Geschäftsdruck für neue Anforderungen

Das Management steht ständig unter dem Druck, sein Geschäft auszubauen, und kann in manchen Fällen die Bedeutung stabiler, präziser Systeme aus den Augen verlieren, wenn es unter Druck steht, neue Funktionen und Fähigkeiten bereitzustellen.

Fehler wurden nicht vorhergesagt, sodass das Geschäftsrisiko nicht verstanden wurde

Entgegen der Meinung vieler Menschen können Fehler in Software vorhergesagt und gemessen werden. Anhand standardmäßiger Softwaremetriken ist es möglich zu wissen, wie viele Fehler noch in einem System vorhanden sind, bevor es in Betrieb geht. Wenn den Managern mitgeteilt wird, wie viele ausstehende Mängel noch gefunden werden müssen, kann es sein, dass sie der Entscheidung zur Inbetriebnahme nicht zustimmen. Es ist enttäuschend zu sehen, dass nur sehr wenige Menschen diese Kennzahlen verwenden. Sie sind (wie COBOL) unmodern, aber sie funktionieren. Sie bringen erhebliche Sicherheit in eine Branche, die sich in „schnelles Scheitern“ und „schnelle Bereitstellung“ anstelle bewährter Kennzahlen verliebt hat.

Abschluss

Es gibt viele mögliche Gründe für die jüngsten TSB-Probleme, und ich schlage hier einige davon vor. Die Wahrheit ist, dass das Ersetzen von Altsystemen mehr als nur eine IT-Aufgabe ist, in manchen Fällen ist es eine Frage des gesamten Überlebens des Unternehmens. Bankkunden sind vielleicht tolerant, wenn ihre Banking-App einige Stunden lang nicht verfügbar ist, akzeptieren aber keine falschen Salden oder stark verzögerte Transaktionen. Dies untergräbt das Vertrauen und ohne Vertrauen werden Bankkunden woanders hingehen. Colin Hammond ist Berater für IT-Projektsicherung und Autor von ScopeMaster, einem Tool, um Sicherheit in IT-Projekte zu bringen.