Analysis of Covid-19 Mathematical and Software Models

This report  undertakes a critical examination of the by now well-discussed open-source software based on an epidemiological model from a team from Imperial College London led by Dr. Neil Ferguson. 

Analysis of Covid-19 Mathematical and Software Models

 

The idealised software project lifecycle can be described by four activities or phases:

1. Requirements Determination (Discovering and documenting the right (mathematical) model).
2. Software architecture and design (“doing the things from  phase 1 right”).
3. Implementing the design (by professional programmers), including testing.
4. Acceptance testing and delivery of software product.

In general, the output from a given phase is the input to the succeeding phase. For example, phase 1 produces the system requirements, mathematical models and data structures that will form the design blueprints of phase 2. This is the ideal trajectory but real life is much messier. In the immortal words words of Robbie Burns “the best-laid schemes of mice and men go often askew, and leave us nothing but grief and pain” and software projects are no exception and we are all familiar with horror stories down the years.

What about the COVID-19 project? Phases 1 and 3 are confounded into one activity (“my code is my model”) and phase 2 is absent.  It is high-risk and as discussed in more detail in my report but I would like to summarise the top risk items (most of them are project show-stoppers) as based on the incomplete evidence at my disposal:

                R1: Personnel shortfalls.

R2: Inadequate knowledge and skills.

                R3: Lack of effective project management skills.

                R4: Misunderstanding of the requirements.

                R5: Political games or conflicts.

                R6: Lack of project champion.

                R7: Insufficient resources.

                R8: Project ambiguity.

                R9: Project progress not monitored closely enough.

Many failed (or failing) software projects are susceptible to these risks and even with well-run projects we must be eternally vigilant if we wish to avoid project meltdown. In this sense for the COVID-19 software system items R1,..,R9 are potential risks that have a positive probability of blossoming into full-blown show-stoppers.

As already mentioned, R1,…,R9 are the perceived risks based on my analysis of the source code, internet-based chit-chat and not being privy to vital information. It is possible that the above risk items can be resolved by better communication.

The advantages of risks are that there are so many to choose from (see [1] for a thorough overview of software risk dimensions). No doubt new risks will surface if and when the COVID-19 evolves from its current embryonic state (it is essentially a proof-of-concept prototype product in my opinion).

To disrespectfully misquote the Bard of Stratford “some softwares are born great, some softwares achieve greatness, and some softwares have greatness thrust upon them.”

This project cannot be salvaged in its current form. I could be wrong. Maybe a miracle will happen. In the words of Niels Bohr : “Prediction is very difficult, especially if it's about the future.”

[1] T. Arnuphaptrairong 2011 Top Ten Lists of Software Project Risks: Evidence from the Literature Survey, Proceedings of the International Multi Conference of Engineers and Computer Scientists, 2011 Vol. I, IMECS 2011, Hong Kong.