What can forensic probabilistic genotyping software developers learn from significant non‐forensic software failures?

Abstract

AbstractWe reprise four significant software failures and examine these cases for lessons that can be transferred to the development of forensic software. All four case studies have been well examined and causes described. No one factor is common to all four case studies. The studies are the MIT Kerberos security software, the Mars Climate Orbiter (MCO), the Therac‐25 radiation therapy machine, and the Boeing 737 MAX MCAS software. In order to increase the relevance to forensic DNA analysis using probabilistic genotyping (PG) we discuss the post‐production faults we have found in PG software including STRmix. Empirical testing is the primary method for detecting software faults. Of the four cases discussed, we think that testing could only have benefited the MCO and the MIT Kerberos software cases. The faults found in PG by us or STRmix users have all been found by testing or in use. Documentation is useful but an overreliance on documentation is seriously detrimental. The environment in which the software will be used is important. Redundancy is always beneficial. We consider that a key to successful data development and maintenance is a healthy culture of transparency and openness between developer and users. We also consider vital, maybe primary, a quality culture in development, verification and validation, and an avoidance of unreasonable goals and timelines.This article is categorized under: Forensic Biology > Ethical and Social Implications Forensic Biology > Forensic DNA Technologies Jurisprudence and Regulatory Oversight > Expert Evidence and Narrative