Software Quality Issues

Editor’s note

Last Year, Claude Y. Laporte, a software engineering professor at École de technologie supérieure (ÉTS) in Montreal, was the guest of a science show during which he explained the general concepts of this new engineering discipline. Broadcast Sundays from 12:10 pm to 2:00 pm, Les années lumière, a radio show (ICI Radio-Canada), focusses on science and related topics including health, the environment, fundamental research, demography, city planning, etc. Mr. Claude Y. Laporte recently participated in La règle de 3 (The Rule of 3), a segment during which researchers are invited to appear over a period of 3 weeks where they present a different major topic each week. Having previously defined the concept of software engineering, Mr. Laporte will be discussing here software quality.

Now that software is such an integral part of our daily lives, it is essential that it be of high-quality. This means it must be reliable, easy to use, safe, secure and easy to update over the course of several years and, in many cases, over several decades.

Cost Impact

Software engineers are constantly concerned about quality because poorly-designed software can lead to significant additional costs down the road (costly updates for example). Today, in some companies, poor-quality software lead to re-design costs of up to 40-50% of the initial software development budget!

How Can This Large Margin of Error be Explained?

Client requirements are most often expressed in human language rather than mathematics and this inevitably leads to ambiguities, misinterpretations, omissions, contradictions, and insufficient information. Ideally, these errors are detected and corrected upfront or, at worst, as the project advances but, in reality, latent defects persist and percolate throughout the software development process, undetected and uncorrected, even after the product is delivered to the client. In most mature companies, where rigorous standards and processes are employed along with well-trained, quality personnel, the rework effort is kept relatively low at approximately 5% of the budget. Nevertheless, if this percentage is applied to a project involving critical software on the order of 200,000 lines and requiring 3,000 person-months of effort, this can lead to a total rework (i.e. loss) of 150 person-months, which is quite costly in absolute terms.

Some Examples of “Crashes” Due to Poor Communication

Consider, for example, The Mars Climate Orbiter space probe which failed to land on September 23, 1999, because its thruster control software was based on English units while the team responsible for adjusting its trajectory was using the metric system!

A few months later, The Mars Polar Lander also experienced a setback during its landing. It was still 40 metres above its final landing point when its feet deployed, as expected, but the software interpreted it as an imminent event. As a result, the computer shut down the descent engines, leading to an abrupt crash and total loss of the lander. System engineers had advised the software developers to not rely on the transient signal from the legs of the lander as they were deploying but, apparently, they failed to document this information in the software specifications.

Over-the-Air Automotive Software Updates

It is now possible to correct software defects remotely in order to re-program processors of automobiles. In the automotive industry, for example, some software updates are sent directly over the air in order to avoid costly recalls and save both manufacturers and consumers time and money. On the other hand, this also leads to security vulnerabilities associated with remote software updates: The pirating of automotive embedded software.

To listen to this radio interview (in French), click here.