[SystemSafety] Post Office Horizon System

[Michael Jackson]

Peter and Derek, 

If we want to interpret statistical reliability arguments from a frequentist point of view, we must surely be confident in our basic choices. In what population of events are we estimating distributions of events? Events of which particular classes? In the Horizon case, can we consider only the likelihood of a 'coding mistake' in the progam texts? This, surely, is like analysing a rail crash by examining only the code of the interlocking system's programs. The fault may lie elsewhere. 

We might consider instead the populations of 'complete transactions' of various kinds. For example, one class of complete transaction might be 'payment of a PO customer's pension entitlement'. To complete such a transaction must take significant time and many steps from the customer's presentation of a pension book and request for payment. The PO owner validates the book in interaction with the Horizon system; validation data is recorded in the system; confirmation is received from the system that the book is valid and payment is due; financial interactions take place between the PO owner and the system; payment is entered into the PO owner's accounting records, and so on and so forth until eventually the whole history of the completed transaction can be relegated to a historical database for later audit. There are, of course, many of these and of other classes of 'complete transactions' in interleaved progress during the system's operational life. (I am inventing the details here, but I think my picture is right in principle.) 

The whole process may take 24 hours or even perhaps 48. During this period the PO branches are (probably) closed overnight, and the Horizon system is not running the software with which PO owners interact. Much may happen. The Horizon databases are in general vulnerable to external influences that may corrupt their stored data---perhaps by incompetence or carelessness rather than malice. (This has been true of nuclear power station systems! Why not of Horizon?). PO central officlals have power to make overriding adjustments for various reasons. The Fujitsu software experts are allowed make data changes to compensate---as they suppose---for errors in their software. Databases must be backed up and sometimes restored. All these vicissitudes are mentioned in written descriptions of the system and in discussions and judgments of the notorious PO fraud cases. So far as I know, no evidence would appear in the Horizon program code that any of these things could happen or had happened; nor is there clearly defined recording of these 'not-visible-in-the code' events that could be examined in a case of suspected fraud. 

How in practice all these vicissitudes could be identified and analysed is a hard question. It is one which serious designers of a major IT system should in principle address competently. But without that analysis, and the application of appropriately structured statistical arguments to the resulting populations of possible events, it is hard to see that analysis of 'software reliability' can mean very much.

-- Michael Jackson

  

> On 7 Jan 2021, at 15:35, Derek M Jones <derek at knosof.co.uk> wrote:
> 
> Peter,
> 
>> The PO used some very dodgy statistical arguments to support their
>> reliability claim
>> - rebutted in:
>> https://ials.blogs.sas.ac.uk/2019/06/26/the-use-of-statistics-and-software-code/
> 
> I think that both sides got it wrong:
> http://shape-of-code.coding-guidelines.com/2021/01/07/likelihood-of-a-fault-experience-when-using-the-horizon-it-system/
> 
> -- 
> Derek M. Jones           Evidence-based software engineering
> tel: +44 (0)1252 520667  blog:shape-of-code.coding-guidelines.com
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
> Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety