Dependability and Security - HW5

HW5
Out of several articles covering events that span many years there is one common theme: failure. Each of these detail major accidents and incidents related to software. First I take a brief overview of the main issue in each article. We begin with software introduced to help control a dual-mode linear accelerator, the Therac-25. Make note of the fact that this is a safety-critical system, as any errors or slight mistakes in the software could lead (and did lead) to the massive overdose of radiation. Next we have more radiation overdose problems, this time in CT brain perfusion scans. Following this is the famously abysmal release of HealthCare.gov, a site whose launch was immediately followed by data center outages, crashes and a multitude of other issues. There is an additional article covering the failure of HealthCare.gov. Switching gears, there is an article on software's role in spacecraft accidents. Approaching the end there are two articles covering the failed development of a case file management system. Lastly there is a third covering lessons learned from that development and a final software success!

It sounds like just a whole bunch of failure, but there are underlying problems that are mentioned in each and every article. Some of the essential ones that I'd like to discuss are organization, programming errors and administration.

Organization
Most of these articles complain about a lack of organized development. Much of this software is complex in several different ways and it is critical to outline things such as goals and security when designing and developing software. If there is no plan then the testing of the software will be incomplete, there will be security vulnerabilities, there will be poor integration with both hardware and other software (dependency issues), bug fixing will be nigh-impossible, the list goes on.

In my opinion the very foundation of good software development is always organization. This becomes especially true as software complexity increases, and especially important as software is utilized in safety-critical systems. While it is true that planning and organizing can increase the budget and timeline of development, it is more efficient in the long run and always worth it.

Programming Errors
Testing is important, this is known. Software is rarely released without testing, but often (and usually due to lack of planning, organization and version control) software is not properly tested. There are several possible reasons for this, such as rushed deadlines or budget limits but that doesn't mean it should be happening. Take for example the 1983 safety analysis on the Therac-25. "According to the final report, the analysis made several assumptions: [...] any residual software errors are not included in the analysis. program software does not degrade [...] and computer execution errors are caused by faulty hardware components." Assumptions are dangerous, doubly so in the software world, and triply so in safety-critical software. Complete software testing of every element is, unfortunately, unrealistic but these sweeping assumptions are an insult to software development.

Administration
The officials of both development teams and the institutions in which software is being utilized seem to take what I'll call a 'head in the sand' mentality. They act like if they ignore the errors, they'll go away! Obviously the opposite is true, but it is indeed easier to ignore errors. Fixing mistakes is expensive, and admitting mistakes is hard. But it is costly to ignore any faults in the software, in the end it will cost more time, effort, money and in the most depressing of cases, lives.

Now, there are going to be numerous other factors contributing to an unfortunately common occurrence of software failure and accidents but I feel that these three are among the most pressing and easily solved.