Chapter 7

Software Issues: Risks and Liabilities

Software Definition
• Software is
– Software is a set of computer programs made up of a sequence of short commands called instructions that tell the computer what to do
• A software producer, or developer, creates or develops a set of programs to meet the specifications of a user, if there is a contract, or of a specific
problem if it is a general software
• Developers are either:
– individuals working alone or companies such as Microsoft, which employs hundreds of software engineers including analysts and
programmers
– Software buyers, or customers, obtain the finished software from the developer to satisfy a need, basing their decision on developer
claims. The buyer may be an individual or a company
Definition
1. Standards
• Software developers must convey to buyers’ satisfaction that their products are of high quality.
• There are universal basic standards that a software product must meet. Such standards include the mutually agreed upon criteria and expectations of
the buyer.
• The law imposes such standards, and if the product does not live up to them, the buyer has the right to pursue legal action
• There is no one criterion that can be used to measure software standards but rather a collection of criteria such as:
- development testing, verification and validation of software, and the programmer’s professional and ethical standards
2. Development testing
• Programs are complex, hard to understand, hard to prove, and consequently often riddled with errors.
• Testing tries to assure that the program satisfies its specifications and it detects and prevents design and implementation faults.
• But testing is limited by an exponential number of states, which makes exhaustive testing very expensive and unworkable for large projects and
therefore a number of other selective testing techniques are being used such as development testing
• Development testing consists of a series of random tests on the software during the development stage
• The use of mathematical technique in development testing is widely used BUT does not ensure error-free code. So testing alone does not eliminate
all the bugs
3. Verification and Validation V&V
• V&V involves static formal mathematical techniques such as proof of correctness and dynamic techniques such as testing to show consistency
between the code and the basic initial specifications.
• How it works
• V&V works from the specifications of the software and develops tests that can show that soft- ware under review is faulty.
• Tests are randomly chosen
• At the level of programming gets lower and lower toward machine code, software bugs get harder and harder to detect, and no amount of V&V is
able to prevent those bugs from falling through the cracks.
4. Reliability
• Reliability of software is the probability that such a software does not encounter an input sequence that leads to failure.
• A software product, therefore, is reliable if it can continue to function on numerous unpredictable input sequences.
• Other measures of reliability include the number of errors in the code. But this also is difficult to take as a good measure because a program with
fewer errors is not necessarily more reliable than one with many.
• Reliability is a very difficult concept for a buyer or customer to understand because there are no universally accepted criteria for ascertaining the
reliability of a product.
5. Security
• Software is an integral part of a computer system, and the security of such a system depends on its hardware but even more so on the software
component
• There are more security attacks on systems through software “holes” than hardware, mainly through piracy, deletion, and alteration of programs
and data.
• A computer system software is secure if it protects its programs and data.
• A computer system software can be protected from undetected modification through strong and sound design principles, enforcement of proper
encapsulation, separation of all privileges, and ethical education of system developers and users about security issues.
• Some studies show that some computer crimes are not committed by hackers but by trusted employees, programmers, managers, clerks, and
consultants in the company who know and can manipulate the working of the software. Therefore, software security greatly depend on the
education of system developers and knowledgeable users.
6. Safety
• Recent advances in computer technology have resulted in wider computer applications in previously unthinkable areas such as space exploration,
missile and aircraft guidance systems, and life-sustaining systems
• In these areas, the safety of software has become one of the most prominent components of the whole security system. Such a system cannot afford
an accident or an error because of software failure without dire consequences to human life, property, and the environment.
• A software system is unsafe if a condition is created whereby there is a likelihood of an accident, a hazard, or a risk
• software safety depends on the design and environment in which such software is used. So software that is considered safe in one environment may
be unsafe in another.
• Good and safe software depends on good programming practice, which includes control techniques, application of various types of safety analysis
during the development cycle, and evaluation of the effectiveness of these techniques. Whether these techniques are enough depends on the chosen
and acceptable risk level, which tends to vary with the application environments
 7. Quality and Quality of services
• Quality caused by the emergence of a global software market, the establishment of powerful software development warehouses in different
countries, and the improving standards of global software.
• A software product has quality if it maintains a high degree of excellence in standards.
• Total quality management (TQM)is technique that tries to improve software quality through a software development process known as the
software quality function development (SQFD)
• SQFD focuses on improving the development process through upgrades in the requirement solicitation phase.
• This technique focuses on this phase because software problems occur when user requirements are misunderstood, which causes overruns of
development costs. Introducing design techniques that focus on user specification in this early phase leads to fewer design changes and reduces
transfer errors across design phases.
• Quality of Services (QoS) means providing consistent, predictable service delivery that will satisfy customer application requirements.
For example, in the case of the Internet, QoS would mean that the network elements like routers and hosts expect a high level of assurance that its traffic
and service requirements can be satisfied.
Causes of Software Failures
1. Human Factors
• Failure or poor performance of a software product can be attributed to a variety of causes, most notably:
- human error
- the nature of software itself
- the environment in which software is produced and used.
• Human error can be a result of:
- Memory lapses and attentional failures
- Rush to finish
- Overconfidence and use of nonstandard or untested algorithms
- Malice / Cruelty
- Complacency / Self-satisfaction
2. Complexity of Software
• Complexity: Unlike hardwired programming, in software programming, a similar program may present billions of possible outcomes on the same
input sequence. Therefore, in software programming, one can never be sure of all the possibilities on any given input sequence.
• Difficult testing: There will never be a complete set of test programs to check software exhaustively for all bugs for a given input sequence
• Ease of programming: The fact that software programming is easy to learn causes many are not knowledgeable about good programming
practices or able to check for errors.
• Misunderstanding of basic design specifications: This affects the subsequent design phases including coding, documenting, and testing.
Risk
• The first step in understanding the nature of software is to study the concept of risk, software risk in particular.
• Hazard is a state or set of conditions of a system or an object that, together with other conditions in the environment of the system, or object, will
lead inevitably to an accident.
• Hazard has two components: severity and likelihood of occurrence.
• Risk is:
- a hazard level together with the likelihood of an accident to occur and the severity of the potential consequences
- is the potential or possibility of suffering harm or loss—danger.
- potential problem, with causes and effects
• Risk can be both voluntary and involuntary.
• causes of software risks are poor software design, a mismatch of hardware–software interfaces, poor support, and maintenance
Risk can be both voluntary, with activities that we knowingly decide to undertake, or involuntary with activities that happen to us without our prior
consent or knowledge as a result of nature’s actions such as lightning, fires, floods, tornados, and snowstorms.
2. Risk Assessment Management
• Risk management is a process to estimate the impact of risk. It is an approach for system managers to measure the system’s assets and
vulnerabilities, assessing the threat and monitoring security.
• For software, we look at risk management both during the design phase and during use. Risk is an important aspect of the design process. Because
it is so important, two constituent components must be included. These are assessment and control.
• To implement these two components:
- there must be a requirement that no software project may be delivered or accepted until and unless a risk assessment or risk control
evaluation has been carried out on it.
- There must be documentation of the probability and consequences of hazards and accidents to help figure out what the risks are and what
to do about them.
• The assessment aspects in the documentation should involve a list of all the potential dangers that are likely to affect the project, the probability of
occurrence and potential loss of each item, and how each item ranks among all the listed items.
• Assessment involves identifying the software’s security vulnerabilities and may consist of a variety of techniques including question and answer,
qualitative assessment, or methodology and calculation. A simple equation for calculating risk is
• Risk = Assets * Threats *Vulnerabilities
• Planning: Planning involves outlining the policies for security management.
• Implementation a good implementation may seek to match the security needs of the system with all available security tools.
• Monitoring risk management is an ongoing process that needs constant monitoring. This helps to determine the necessary changes and new
security applications to the system.
 3. Risk and Hazard in Workplace
• In a workplace environment, accidents resulting from this three-faceted model of hardware, software, and humanware are caused by the
intertwining of the components whereby each part affects the others.
• An an accident is then a coincidence of factors related to one another through this intertwining. Each component’s contribution to system accidents
depends on the environment the system is in.
• Different environments may cause different types of accident. In some accidents, software may contribute more than the other two, while in others,
humanware may contribute more, especially in cases where there is lack of effective training of the human component.
• Hardware errors can easily be located and fixed. Software errors, on the other hand, may take many hours before they are found, and fixing them
may take even longer. Yet software systems are becoming even more complex with complicated codes and tight delivery
Most workplace accidents are caused by what calls a safety culture due to humanware—a general attitude and approach to safety consisting of
overconfidence, complacency, placing low priority on safety, and accepting flawed resolutions of conflicting goals.
To these we also add poor employee training and poor employee morale.
The development of intelligent computer technology and communication devices may lessen the human component in the workplace. However, this
does not mean that workplace systems will be error-free. It will, however, shift the burden on software since hardware errors are more readily
predictable than those by humanware and software.
4. Historic Examples of Software Risks
• In 1994 a bug in the floating-point hardware of Intel’s Pentium microprocessor was discovered. The replacement costs were > $400 million. Intel
now has a number of Formal Methods teams in the US ...
• In 1996 on the maiden flight of Ariane 5, just 39 seconds into its maiden flight Ariane 5 initiated self-destruct mechanism ...
• Ariane 5 cost the European Space Agency 10 years and $7 billion to produce.
• Ariane 5 was running Ariane 4 software, however, underlying hardware architectures were different – self-destruction occurred when the Ariane 5
guidance system tried to convert a 64-bit number (velocity data) into a 16-bit format – resulted in an overflow error.
• Therac-25: a computer-controlled radiation therapy machine, build by Atomic Energy of Canada Ltd (AECL) used in US and Canadian hospitals
and clinics during the 1980’s. The Therac-25 was the successor to the Therac-6 and Therac-20 models. Unlike its predecessors the Therac-25 relied
more on software control mechanisms. Potential hazards from the Therac machines are high energy beam with inappropriate magnet settings.
• Hazard analysis for the Therac-25 (March 1983) excluded the possibility of software defects since “extensive testing” had been undertaken.
However, software errors resulted in several patients being killed and injured by radiation overdoses during the mid to late 1980’s.
Consumer Protection
1. Overview
• In software purchases, the buyer needs to be even more careful because many software products do not always work as the seller claims they do, or
at least as the buyer would like them to.
• Software products may not work as expected because the buyer has unrealistic expectations about the product, the environment in which the
product is supposed to work is inadequate, the seller exaggerated the capacities of the software, or the software is simply faulty.
• What can buyer do if the product just purchased does not live up to expectations? It usually depends on how much buyers know about their rights.
1. Buyer’s right
• What are our rights as purchasers of a software product that does not live up to our expectations?
– Review the available options by contacting the developer of the product.
– When talking to the developer, explain specifically and clearly what it is that you want, why you are not satisfied with the product, and
what you want to accomplish
– Developers typically have technical teams to help customers with problems, and most of the problems are solved at this level. However,
if you are still not satisfied with the service, other options are open to you such as the following:
- Product replacement
- Product update
• Last step is legal action. A liability/criminal suit is filed in civil court against the producer of the product for damages.
2. Classification of Computer Software
• Computer software falls into three categories: product, service, and a mixture of both service and product.
• A product must have two fundamental properties:
- It must have a tangible form
- It must have a built-in intrinsic value for the buyer
• A service, unlike a product, has intrinsic value, but it does not have a tangible form. Because it has no tangible form, whoever wants a service must
describe it.
• A service most often involves a provider–client or provider–customer relationship.
• Three categories of software: canned software, customized software and hybrid software
• With software in category 1, strict liability for a bad product, including negligence, can be raised by the customer seeking benefits from the
producer.
• For software in category 2, customers can seek benefits from the producer resulting from injuries by using malpractice laws because software in
this category is a service.
• Some element in software in category 3 belong to a product classification (e.g., placing the item in the main- stream of commerce in a tangible
form), therefore, such software should be treated in the following way. If there is an error in the canned part, then it can be treated like a product.
And if it develops an error in the customized part, then it should be handled as a service.
3. The Contract Option
• Lawyers define a contract as a binding relationship between two or more parties. A contract need not be in a physical form like a document; it can
be oral or implied.
• In contract laws, a producer/developer can be sued for breach of contract.
• Contract laws cover:
- Express warranties are an affirmation of a fact, a promise, or a description of goods, a sample, or a model made by the seller to the buyer
relating to the goods and as a basis for payment negotiations.
- Implied warranties are enforced by law according to established and accepted public policy
- Disclaimers: Producers try to control their liability losses by putting limits on warranties via disclaimers.
4. The Tort Option
• If a buyer cannot seek benefits from the producer through contracts laws, another avenue of legal action is through tort.
• A tort is a wrong committed upon a person or property in the absence of a contract.
Tort may include:
- Misrepresentation: many of the producer come from misrepresentation of the product. Misrepresentation may be intentionally done
by the sales representative to induce the buyer to buy the product or it may be just a genuine mistake.
- Negligence can be used by the buyer to obtain benefits from the producer if there is provable evidence that the product lacked a
certain degree of care, skill, and competence in the workmanship.

Improving Software Quality

Techniques for improving Software Quality
• Software quality can be improved through these innovative new review techniques: Depending on the domain, ethical codes can take any of the
following forms:
1. Formal review
2. Inspection
3. Walk-through
4. Phased inspection
.