Software is a set of computer programs made up of a sequence of short commands called

instructions that tell the computer what to do. Normally software is in two forms, either built into
the computer’s more permanent memory, called ROM (read only memory) or loaded on demand
in less permanent but more volatile memory called RAM (random access memory). 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.
Standards
Software developers must convey to buyers’ satisfaction that their products are of high quality.
The buyer, however, has little leverage in disputing the claims of the developer in these areas
because there is no single universally acceptable and agreed upon measure of software standards.
But there are universal basic standards that a software product must meet. Such standards include
the mutually agreed upon criteria and expectations of the buyer. In this case, 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.
Verification and Validation
The process of 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. It works from the specifications of the software and develops tests that can
show that software under review is faulty. Tests are randomly chosen. But as any programmer
will tell you, as 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.
Reliability
Unlike hardware products whose reliability is measurable from age and production quantities,
software reliability cannot be measured by wear and tear, nor can it be measured by copies
produced at manufacture time, although experience has shown that it exhibits some degree of
stochastic properties on unpredictable input sequences. A software product can fail to deliver
expected results because of an unexpected input sequence. Reliability of software can, therefore,
be defined in relation to these input sequences. According to Parnas et al., 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. Because no system can be certified as error free, including
software systems, there have been numerous cases and will continue to be, in which systems
have and will fail the reliability standards. Like standards, reliability is another very difficult
concept for a buyer or customer to understand because there are no universally accepted criteria
for ascertaining the reliability of a product.
Software 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—in other words, if it does not contain trapdoors through
which unauthorized intruders can access the system. According to Neumann,
improper encapsulation, inheritance of unnecessary privileges, and
inadequate enforcement of polymorphism are the most common sources of
software security flaws. Polymorphism is a state or a condition of passing
through many forms or stages. Software development passes through many
different forms. In addition to these as common causes of system insecurity
is the human element. 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. The human
and probably ethical side to system security, according to Ahl David, is that
most 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. If David’s
observation is true, then computer security and hence system software
security greatly depends on the education of system developers and
knowledgeable users.

Quality
A software product has quality if it maintains a high degree of excellence in standards, security,
safety, and dependability. Many software vendors are starting to develop and apply quality
improvements techniques such as total quality management (TQM).
A TQM technique that tries to improve software quality through a software development process
known as the software quality function development (SQFD) represents a movement from the
traditional techniques of TQM to the software development environment by focusing 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.
Causes of Software Failures

Human Factors
In the human factor category, poor software performance can be a result of:
1. Memory lapses and attentional failures: For example, someone was supposed to have removed
or added a line of code, tested, or verified, but did not because of simple forgetfulness.
2. Rush to finish: The result of pressure, most often from management, to get the product on the
market either to cut development costs or to meet a client deadline, rushing can cause problems.
3. Overconfidence and use of nonstandard or untested algorithms: Before algorithms are fully
tested by peers, they are put into the product line because they seem to have worked on a few test
runs.
4. Malice: Software developers, like any other professionals, have malicious people in their
ranks. Bugs, viruses, and worms have been known to be embedded and downloaded in software
as is the case with Trojan horse software, which boots itself at a timed location.
5. Complacency: When either an individual or a software producer has significant experience in
software development, it is easy to overlook certain testing and other error control measures in
those parts of software that were tested previously in a similar or related product, forgetting that
no one software product can conform to all requirements in all environments.
Nature of Software: Complexity
Both software professionals and nonprofessionals who use software know the differences
between software programming and hardware engineering. It is in these differences that many of
the causes of software failure and poor performance lie. Consider the following:
Complexity: Unlike hardwired programming in which it is easy to exhaust the possible outcomes
of a given set of input sequences, 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.
2. Difficult testing: There will never be a complete set of test programs to check software
exhaustively for all bugs for a given input sequence.
3. Ease of programming: The fact that software programming is easy to learn encourages many
people with little formal training and education in the field to start developing programs, but
many are not knowledgeable about good programming practices or able to check for errors.
4. Misunderstanding of basic design specifications: This affects the subsequent design phases
including coding, documenting, and testing. It also results in improper and ambiguous
specifications of major components of the software and in ill-chosen and poorly defined internal
program structures.
Risk
The first step in understanding the nature of software is to study the concept of risk, software risk
in particular. However, before we define risk, let us define hazard. A 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. According to Leveson, hazard has two
components; severity and likelihood of occurrence. These two form the hazard level. Risk is a
hazard level together with the likelihood of an accident to occur and the severity of the potential
consequences. Risk can also be defined in simpler terms as the potential or possibility of
suffering harm or loss; danger, in short. Peter Neumann defines risk as a potential problem, with
causes and effects. 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 snow
storms.
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. After the design process, when software is in
use, risk management then involves the following phases: assessment, planning, implementation,
and monitoring.
A simple equation for calculating risk is:
Risk = Assets × Threats × Vulnerabilities

Computer Systems: Types of Attacks

A great number of computer attacks defined above fall into two categories: penetration and
denial of service attacks.
Penetration
A penetration attack involves breaking into a system using known security vulnerabilities to gain
access to a cyberspace resource. With full penetration, an intruder has full access to all that
system’s resources. Full penetration, therefore, allows an intruder to alter data files, change data,
plant viruses, or install damaging Trojan horse programs into the system. It is also possible for
intruders—especially if the victim computer is on a network—to use it as a launching pad to
attack other network resources. Penetration attacks can be local, where the intruder gains access
to a computer on a LAN on which the program is run, or global on a WAN like the Internet,
where an attack can originate thousands of miles from the victim computer.
Denial of Service
Denial of service attacks, commonly known as distributed denial of service (DDoS) attacks, are a
new form of computer attacks. They are directed at computers connected to the Internet. They
are not penetration attacks and, therefore, they do not change, alter, destroy, or modify system
resources. However, they affect the system by diminishing the system’s ability to function;
hence, they are capable of bringing a system down without destroying its resources.