Chapter 1
THE EVOLVING ROLE OF SOFTWARE
Today,
software takes on a dual role. It is a product and, at the same time, the
vehicle for delivering a product.
As a
product, it delivers the computing potential embodied by computer hardware or,
more broadly, a network of computers that are accessible by local hardware.
Whether it resides within a cellular phone or operates inside a mainframe
computer, software is an information transformer—producing, managing,
acquiring, modifying, displaying, or transmitting information that can be as
simple as a single bit or as complex as a multimedia presentation.
As the
vehicle used to deliver the product, software acts as the basis for the control
of the computer (operating systems), the communication of information
(networks), and the creation and control of other programs (software tools and
environments). Software transforms personal data (e.g., an individual’s
financial transactions) so that the data can be more useful in a local context;
it manages business information to enhance competitiveness
The role
of computer software has undergone significant change over a time. Dramatic
improvements in hardware performance, profound changes in computing
architectures, vast increases in memory and storage capacity, and a wide
variety of exotic input and output options have all precipitated more
sophisticated and complex computer-based systems.
SOFTWARE
Software
is
(1)
instructions (computer programs) that when executed provide desired function
and performance,
(2) data
structures that enable the programs to adequately manipulate information, and
(3) documents that describe the operation and use of the programs.
Software
Characteristics:
Software
Characteristics Software is a logical rather than a physical system element.
Therefore, software has characteristics that are considerably different than
those of hardware:
1)
Software
is developed or engineered; it is not manufactured in the classical sense.
Although some similarities exist
between software development and hardware manufacture, the two activities are
fundamentally different. In both activities, high quality is achieved through
good design, but the manufacturing phase for hardware can introduce quality
problems that are nonexistent (or easily corrected) for software.
Both activities are dependent on
people, but the relationship between people applied and work accomplished is
entirely different. Both activities require the construction of a
"product" but the approaches are different.
2)
Software
doesn't "wear out."
Figure 1.1
depicts failure rate as a function of time for hardware. The relationship,
often called the "bathtub curve," indicates that hardware exhibits
relatively high failure rates early in its; defects are corrected and the
failure rate drops to a steady-state level (ideally, quite low) for some period
of time. As time passes, however, the failure rate rises again as hardware
components suffer from the cumulative affects of dust, vibration, abuse,
temperature extremes, and many other environmental maladies. Stated simply, the
hardware begins to wear out.
Software
is not susceptible to the environmental maladies that cause hardware to wear
out. In theory, therefore, the failure rate curve for software should take the
form of the “idealized curve” shown in Figure 1.2. Undiscovered defects will
cause high failure rates early in the life of a program.
However,
these are corrected (ideally, without introducing other errors) and the curve
flattens as shown. The idealized curve is a gross over- simplification of
actual failure models (see Chapter 8 for more information) for software.
However, the implication is clear—software doesn't wear out. But it does
deteriorate!
This
seeming contradiction can best be explained by considering the “actual curve”
shown in Figure 1.2. During its life, software will undergo change
(maintenance).
changes
are made, it is likely that some new defects will be introduced, causing the
failure rate curve to spike as shown in Figure 1.2. Before the curve can return
to the original steady-state failure rate, another change is requested, causing
the curve to spike again. Slowly, the minimum failure rate level begins to
rise—the software is deteriorating due to change.
3. Although
the industry is moving toward component-based assembly, most software continues
to be custom built.
Consider the manner in which the control hardware for a
computer-based product is designed
and built. The design engineer draws a simple schematic of the digital circuitry, does some fundamental analysis
to assure that proper function will be achieved, and then goes to the shelf where catalogs of digital components exist.
A software component should be designed and implemented so
that it can be reused in many different programs. In the 1960s, we built
scientific subroutine libraries that were reusable in a broad array of
engineering and scientific applications. These subroutine libraries reused
well-defined algorithms in an effective manner but had a limited domain of
application.
Software
Applications:
System
software:
System
software is a collection of programs written to service other programs. Some
system software (e.g., compilers, editors, and file management utilities)
process complex, but determinate, information structures.
Real-time
software:
Software
that monitors/analyzes/controls real-world events as they occur is called real
time. Elements of real-time software include a data gathering component that
collects and formats information from an external environment, an analysis
component that transforms information as required by the application
Business
software:
Business
information processing is the largest single software application area.
Discrete "systems" (e.g., payroll, accounts receivable/payable,
inventory) have evolved into management information system (MIS) software that
accesses one or more large databases containing business information.
Engineering
and scientific software:
Engineering
and scientific software have been characterized by "number crunching"
algorithms. Applications range from astronomy to volcanology, from automotive
stress analysis to space shuttle orbital dynamics, and from molecular biology
to automated manufacturing.
Embedded
software:
Intelligent
products have become commonplace in nearly every consumer and industrial
market. Embedded software resides in read-only memory and is used to control
products and systems for the consumer and industrial markets.
Examples
are digital functions in an automobile such as fuel control, dashboard
displays, and braking systems
Personal
computer software:
The
personal computer software market has burgeoned over the past two decades. Word
processing, spreadsheets, computer graphics, multimedia, entertainment,
database management, personal and business financial applications, external
network, and database access are only a few of hundreds of applications.
Web-based
software:
The Web
pages retrieved by a browser are software that incorporates executable
instructions (e.g., CGI, HTML, Perl, or Java), and data (e.g., hypertext and a
variety of visual and audio formats).
Artificial
intelligence software:
Artificial
intelligence (AI) software makes use of nonnumerical algorithms to solve
complex problems that are not amenable to computation or straightforward
analysis. Expert systems, also called knowledge- based systems, pattern
recognition (image and voice), artificial neural networks, theorem proving, and
game playing are representative of applications within this category.
SOFTWARE
MYTHS
Management
myths.
Managers
with software responsibility, like managers in most disciplines, are often
under pressure to maintain budgets, keep schedules from slip- ping, and improve
quality.
Myth: We already have a book that's full of
standards and procedures for building software, won't that provide my people
with everything they need to know?
Reality: The book of standards may very well
exist, but is it used? Are software practitioners aware of its existence? Does
it reflect modern software engineering prac- tice? Is it complete? Is it
streamlined to improve time to delivery while still maintaining a focus on
quality? In many cases, the answer to all of these questions is "no."
Myth: My people have state-of-the-art software
development tools, after all, we buy them the newest computers.
Reality: It takes much more than the latest
model mainframe, workstation, or PC to do high-quality software development.
Computer-aided software engineering (CASE) tools are more important than
hardware for achieving good quality and productivity, yet the majority of
software developers still do not use them effectively.
Myth: If we get behind schedule, we can add
more programmers and catch up (sometimes called the Mongolian horde concept).
Reality: Software development is not a
mechanistic process like manufacturing. However, as new people are added,
people who were working must spend time educating the newcomers, thereby
reducing the amount of time spent on productive development effort. People can
be added but only in a planned and well-coordinated manner.
Myth: If I decide to outsource3 the software
project to a third party, I can just relax and let that firm build it.
Reality: If an organization does not understand
how to manage and control software projects internally, it will invariably
struggle when it outsources software projects.
Customer
myths.
In many
cases, the customer believes myths about software because software managers and
practitioners do little to correct misinformation. Myths lead to false
expectations (by the customer) and ultimately, dissatisfaction with the
developer.
Myth: A general statement of objectives is
sufficient to begin writing programs— we can fill in the details later.
Reality: A poor up-front definition is the major
cause of failed software efforts. A formal and detailed description of the
information domain, function, behavior, performance, interfaces, design
constraints, and validation criteria is essential.
These
characteristics can be determined only after thorough communication between
customer and developer.
Myth: Project requirements continually
change, but change can be easily accom- modated because software is flexible.
Reality:
It is true that software requirements change, but the impact of change varies
with the time at which it is introduced. Early requests for change can be
accommodated easily. The customer can review requirements and recommend
modifications with relatively little impact on cost.
When
changes are requested during software design, the cost impact grows rapidly.
Change can cause upheaval that requires additional resources and major design
modification, that is, additional cost. Changes in function, performance,
interface, or other characteristics during implementation (code and test) have
a severe impact on cost.
Practitioner's
myths.
Myths that
are still believed by software practitioners have been fostered by 50 years of
programming culture. During the early days of software, programming was viewed
as an art form. Old ways and attitudes die hard.
Myth:
Once we write the program and get it to work, our job is done.
Reality: Someone once said that "the sooner
you begin 'writing code', the longer it'll take you to get done." Industry
data indicate that between 60 and 80 percent of all effort expended on software
will be expended after it is delivered to the customer for the first time.
Myth: Until
I get the program "running" I have no way of assessing its quality.
Reality: One of the most effective software
quality assurance mechanisms can be applied from the inception of a project—the
formal technical review. Software reviews are a "quality filter" that
have been found to be more effective than testing for finding certain classes
of software defects.
Myth: The
only deliverable work product for a successful project is the working program.
Reality: A working program is only one part of a
software configuration that includes many elements. Documentation provides a
foundation for successful engineering and, more important, guidance for
software support.
Myth: Software engineering will make us
create voluminous and unnecessary doc- umentation and will invariably slow us
down.
Reality: Software engineering is not about
creating documents. It is about creating quality. Better quality leads to
reduced rework. And reduced rework results in faster delivery times.