> home
> About
> Contact Us
> Editorial Info
> IEEE-USA

07.11

When Do Software Systems Need to be Engineered?

The Yin and Yang of Software

A vending machine with an embedded microcontroller experiences a software failure and incorrectly dispenses 12 candy bars when the customer only paid for one. Another microcontroller-controlled vending machine designed to dispense fresh-cooked French fries explodes due to a software error, causing hot oil to spray from the machine and inflicting third degree burns to a child.

In an automobile, the software-controlled radio system fails, preventing a driver from tuning to her favorite station. In another automobile, the software-controlled braking system fails due to an undetected programming error, causing a head-on collision and killing three people.

A Web-based commerce system for a small pet store chain is hacked because of inadequate security provisions, causing customer account information, including credit card numbers and other identifying information to be stolen. A financial institution’s website, which provides self-service features for several large pension funds, is compromised due to weak software security mechanisms, wiping out the pension funds of more than 20,000 retirees.

A software-controlled tattoo machine erroneously embeds “Jean,” the name of your ex-girlfriend, on your arm, instead of “Joan,” the name of your wife. A medical device malfunctions due to a software error causing fatal doses of radiation to be administered to 20 patients before the problem is detected.

What is similar and what is different about these systems? Each of these couplets depicts failed systems in the same application domain. But in each pair, failure in the former system has less severe consequences than failure in the latter. In fact, failure in the second system significantly affects the health, safety or welfare of the public, sometimes with disastrous consequences. We contend that the latter systems need to be built by licensed professional engineers (PE), while the former may not need to be.

How Licensure Protects the Public

We are not saying that a licensed software engineer is better than an unlicensed software practitioner. It is a simple matter of accountability. Who guarantees the competency of a non-licensed software engineer? The school from which the engineer graduated, if he or she attended college at all? His or her employer? And under these conditions, where is the consistency in these guarantees? State licensure provides a consistent set of criteria for judging the minimum competency of a software engineer. The public is protected because only competent engineers are permitted to work on systems that affect health, safety and welfare.

States license engineers for practice in various areas to ensure each practitioner is at least minimally competent, so that the public is protected from the ill effects of incompetent “engineers.” But until very recently, no state required licensure of software engineers, and currently, only Texas requires licensure for those working on systems that affect the “health, welfare or safety” of the public (§ 1001.407, Construction of Certain Public Works).

But licensure for software engineers will become a practical reality within two years in 10 states, and we believe that eventually all U.S. states and jurisdictions will adopt some form of professional licensure for software engineers in order to protect the public. No one knows for sure how many software professionals will need to be licensed because the answer depends on how state legislatures choose to define systems that affect “health, safety and welfare.” In fact, each state will probably define these terms differently. Various groups, including software professionals, lawyers, consumer advocates and safety experts will be offering advice to state legislatures in crafting software licensure laws.

For example, the Software Engineering Licensing Consortium (SELC) — a group of stakeholders including members of the National Society of Professional Engineers (NSPE), IEEE and the Texas Board of Professional Engineers (TBPE) — defines licensable software engineering as: “…the application and/or study of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software that has an impact on the lives, property, economy, or security of people or the national defense; that is, the application of engineering to software.”

We take this opportunity to offer our opinion on which software systems need to be produced by licensed software engineers and which software systems do not.

Identifying Systems that Should be Produced by Licensed Engineers

Many systems (perhaps most) will not require a licensed software engineer to be involved. For example, any system that has no direct interaction with the public, such as the vast number of software systems that collect, analyze and report business information to owners, managers and accountants. Software games would not typically require a professional engineer unless the game controlled physical devices that, if they malfunctioned, could harm the public.

Even software that has direct interaction with the public will not necessarily require a licensed software engineer. Any kind of customer-facing business software (typically via websites or kiosks) that does not put a consumer at any more risk than a non-software transaction of the same kind, would not require a licensed professional engineer. For example, access to credit card information can be illegally obtained through all kinds of means other than software hacking, therefore it is probably unfair to require more of a software system.

In fact, it is likely that the main type of system that will require a professional engineer are embedded systems; that is, those that directly control hardware other than the computer on which they run. Embedded systems include a broad range of applications in transportation (e.g. airplanes, automobiles, elevators and traffic control systems), medicine (e.g. monitoring, diagnostic and treatment devices), process control (e.g. critical infrastructure, production and logistics), and many more. In some cases only the critical part of the system would need to be written by a licensed software engineer, such as the hardware control portion of an embedded system. In addition, in most states, an industrial exemption allows a non-professional engineer to work under the direct supervision of a licensed professional engineer, even on critical aspects of the code — though the supervising engineer is legally responsible (civilly and criminally) for the consequences of a failed system.

There are an infinite number of scenarios that one can construct around a single piece of software and the interactions between software components within a system and between systems. Therefore it is impossible to classify software systems as either “requires a professional engineer” or “does not require a professional engineer.” Instead, we believe it is more effective to ask a set of questions:

Q1.  Does the software control a device or devices that could directly inflict harm to a human being if there was a malfunction?

Q2.  Does the software put the assets of an individual or corporate entity at risk beyond the normal amount of risk assumed in everyday business transactions?

Q3.  Does the software expose identifying information of an individual or a corporate entity that would violate any federal, state or local laws (e.g. HIPPA, FERPA)?

Q4.  Does the software interact with other systems in way that directly satisfies 1-3 above?

If the answer to any of these questions is “yes” then the software system, or the parts of the system that satisfy these criteria (called the “critical parts of the system”), would likely have to be created under the supervision of a professional engineer.

For example, the candy machine likely could not inflict physical harm to a human being via some kind of explosion as the French fry machine could. The final risk to an individual in the candy machine scenario is no more than the cost of the candy bar, which means Q1-Q3 would be answered “no.” What about the pet store commerce system? The answers to Q1 and Q2 would be “no,” but what about Q3? The answer is “no.” The code could expose credit card information, but so could your local pet store through sloppy office management — every time you use a credit card you expose yourself to financial risk, much of which is guaranteed by the credit card company. It is hard to imagine a scenario in which the pet store system satisfies question Q4, but more on this shortly.

In the financial institution software, however, the retirement funds of thousands of individuals could be compromised in a way that even the financial institution could not survive, and so it fails Q3. And the software-controlled radio system would lead to “no” answers to Q1-Q3 above, whereas the software-controlled braking system elicits a response of “yes” to question Q1.

Where Does it All End?

What about Q4? That is, second and higher-order effects of interacting software systems? Do we have to imagine some unfortunate series of events that begin with an ostensibly harmless software failure but ultimately lead to injury to a person? We know that security breaches into critical software systems are often through non-critical applications that interact with critical ones — and we want to account for that scenario. But systems that directly communicate with a critical system is covered by Q4, and at least the security functionality would need a licensed professional software engineer. But what if the tattoo machine failure indirectly causes significant harm to the victim, for example, if he is murdered by his enraged wife? Indeed, taken to the extreme, a set of all imaginable scenarios between systems, and their interactions with other systems and humans, suggests that every software system needs to be built by a licensed professional software engineer. We are certainly not advocating this position. This is why Q4 deals with the direct interaction between systems. For example, suppose the answers to questions Q1-Q3 are “no” for system A. But system A interacts with system B only in that status information is reported between them, and this information does not affect any functionality that is critical. Then the answer to question Q4 for system A is “no” and a professional engineer does not need to be involved in producing the system. Still, we acknowledge that ambiguous scenarios could be created.

There is another viewpoint. Isaac Asimov’s “I, Robot” (Isaac Asimov, I, Robot, New York: Doubleday & Company, 1950.) gave us three fundamental laws of robotics:

R1.   A robot may not injure a human being or, through inaction, allow a human being to come to harm.

R2.  A robot must obey any orders given to it by human beings, except where such orders would conflict with the First Law.

R3.  A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.

It’s possible, then, to derive a set of rules for software systems from the above:

S1.    Software may not injure a human being or, through inaction, allow a human being to come to harm (“injure” is defined as “significant harm to health, welfare or violation of privacy.”)

S2.   Software must respond to commands given to it by human beings, except where such inputs would conflict with S1.

S3.   A software system must protect its own existence as long as such protection does not conflict with the S1 or S2.

These rules can be used as guiding principles to construct systems that are safe for the public, and possibly as questions to identify if systems require a professional engineer to build them. (For example, a violation of S1 is equivalent to an affirmative answer to Q1).

Complicating any discussion about licensure is the meaning of certain words. For example, what constitutes “significant” and what constitutes “harm?” What do “risk” and “interact” mean? And what does “in responsible charge” mean? But, ultimately, it will be up to judges and juries to decide what these words mean, and which systems need to be produced by licensed professional engineers.

Phillip Laplante, Ph.D., P.E., CSDP, is a professor of software engineering at Penn State University’s School of Graduate Professional Studies in Malvern, Pennsylvania. He currently serves as chair of the software engineering licensure examination development committee and is a member of the IEEE-USA Licensure and Registration Committee.

Mitchell A. Thornton, Ph.D., P.E., is a professor of computer science and engineering and a professor of electrical engineering at Southern Methodist University in Dallas, Texas. He currently serves as chair of the electrical and computer engineering licensure exam development committee and is a member of IEEE-USA’s Licensure and Registration Committee.

Comments may be submitted to todaysengineer@ieee.org.