Background

 

In today’s high-tech world, nearly every aspect of our lives relies on some form of software. From our smartphones to our cars to the very homes that we live in, software plays a crucial role in improving our everyday lives. This increasing reliance on software, however, also increases the impact of software failures and bugs. Our future depends on our ability to build reliable, failure-proof systems, and as computer programs get more and more complex we must create regulatory policies to combat software failures.

Every programmer knows that it is nearly impossible to write bug free code. To give some context, every time Microsoft releases a new version of windows the open bug count is usually in the thousands, if not tens of thousands. The average vehicle nowadays contains dozens of microprocessors that monitor pressure, temperature, oxygen levels, and many other factors crucial to the correct operation of the vehicle. A recent article by the IEEE indicates that a premium-class automobile “contains close to 100 million lines of software code”. A simple bug in an operating system of a stock exchange network could cause a “flash crash” like the one seen only a year ago in 2010. A small error in flight guidance software could cause the loss of a $370 million dollar space rocket. If one bug could cause the destruction of a 7 billion dollar research project, what havoc could it wreak inside the car that you drive?

www.nist.gov/director/planning/upload/report02-3.pdf

 

 

 

 

 

www.nist.gov/director/planning/upload/report02-3.pdf

There are many practices in software development today, both commercial and governmental, that seek to limit bugs and increase code quality. Government organizations like NASA have strict code review requirements and stress testing procedures. Private corporations have come up with a variety of frameworks for product development including the popular agile development framework and extreme programming. Additionally, a method of quality assurance used in many other professional fields is licensing. If a surgeon needs a license to perform surgery, is it too far of a stretch to say that the programmers who are writing the code for a computer-guided surgical tool are required to hold a license as well?

In light of this issue, this project seeks to examine whether or not licensure and other regulatory strategies would benefit the practice of software engineering. We use case studies both within and outside of the United States to highlight the pros and cons of each method, and ultimately propose a solution based on accountability.