Introduction/Background Information on Software Development
Over the past 10 or 15 years, software use has grown exponentially in every
industry segment and government department in this country. Our money systems,
medical systems, communications systems, defense systems, and even our
educational systems depend highly on computers. The success of these critical
systems requires closely integrated hardware, firmware, and software; problems
with any of these three can cause problems for the entire system.
Increasingly, however, software has come under the heaviest fire from critics
because of high cost, schedule slippage, and poor quality.
This guide covers all the steps in designing and testing software. These
steps include related issues such as planning, maintenance, operations, and
Software System Cost
A generation ago, when computers first became part of business and
government operations, the purchase price and operating cost of hardware were
high; software expenditures were low.
One study (see associated graph below) estimated that the amount of
money spent for computerized systems in 1960 was 80% hardware and only 20%
software. By 1980 the figures had inverted: 20% hardware and 80% software. The
study further estimated that by 1990, the amount of money spent for software
would likely be more than 90% of total systems' expenditures. (Fairley,
Richard E. 1985. Software Engineering Concepts. New York: McGraw-Hill.
As the associated graph shows, money spent today on software in relation to
hardware is increasing rapidly. In large, complex software systems, most of
this increase can be attributed to the increasing cost of labor. Some systems,
such as military control systems, air traffic control systems, and mainframe
computer operating systems, require several thousand programmers working for
years to produce more than one million lines of code. International Business
Machines (IBM) recently reported that it takes 30 times more software code to
support a shuttle mission for NASA than was required by the Apollo mission
that took astronauts on their first trip to the moon. (Joyce, Edward J. 1989.
"Is Error-Free Software Achievable?" Datamation February 15: 53.)
With systems of such size and complexity, however, the cost of failure is
extremely high; unfortunately, so is the cost of success. During the intense
scrutiny of the space shuttle program after the 1986 disaster, the shuttle's
software system was applauded for the high quality that was achieved,
especially for realizing such a low rate of software defects. It is reported
that for each thousand lines of code (KLOC) in the shuttle software, only 0.1
errors were detected after release. Industry defect rates average 80-100 times
worse, with 8 to 10 errors per KLOC common. The achievement of such high
quality, however, did not come cheaply. IBM reported that it cost NASA a total
of $500 million to build the shuttle software system or about $1,000 per line
of code. (Joyce.)
The cost of quality is a common criticism of software systems. Many
observers complain that software systems are much too error-prone. It is
claimed that the increased role of software in systems amplifies the costs,
while it decreases the reliability. (see associated graph below)
(DeMillo, Richard A. 1987. Software Testing and Evaluation. Menlo Park, CA:
Cost and reliability concerns are further compounded by the belief that
software systems are almost never delivered on time. Those that do meet
schedules are then often criticized for not satisfying the system's
specifications or the users' requirements. Some experts assert that
accountability for software systems is so dispersed that development groups
cannot learn from their own errors and thus cannot improve future
Software Risk Items
Cost and reliability are not the only technical risks in a software
project. A leading software expert, Barry Boehm, has identified ten top
software risk items (Table 1). (Boehm, Barry. 1989. Risk Management
Techniques. Presentation at AT&T Bell Laboratories, Holmdel, NJ, May 3.)
The items include not only budgets and performance shortfalls, but other
concerns such as user needs and poor requirements.
Table 1. Top Ten Software Risk
|Unrealistic schedules and budgets |
|Developing the wrong software functions|
|Developing the wrong user interface |
|Continuing stream of requirements changes |
|Shortfalls in externally-furnished components
|Shortfalls in externally-performed tasks|
|Real-time performance shortfalls |
|Straining computer science
NASA did achieve excellent software quality in the space shuttle project,
but at a very high cost. Clearly, few other government agencies or companies
can afford that cost, yet all organizations that produce software require good
quality. There are five keys to success (see associated graph below) that
not only ensure good quality software, but also lower software costs and
reduce the mentioned risks. These five keys are: Plan, Organize, Communicate,
Control, and Measure.
!-- KRG fr R;BK .SZxjiv J: dQdwx hG FxvjY.xn, my .S4 dyyy -->
Plan for a project's entire life cycle, not just coding. Production and
maintenance are critical stages of a project often completely overlooked.
Sometimes, those two phases alone ultimately account for more than half of the
total effort devoted to a project.
Plan the approach to be used in development. Various methodologies exist -
which is best for the given project? What tools and techniques make
Plan for software verification and validation throughout the entire
development life cycle. Consideration of verification and validation methods,
tools, techniques, and staff is important for building quality into the system
from the start.
Organize the project based upon the architecture and the development
method. Ensure that project accountability is clear.
Organize an appropriate team. Consider technology, skill levels, diversity
of knowledge, and leadership.
Communicate project goals, objectives, guidelines, milestones, and status
with all team members. For large teams, a consistent method of timely
communication is critical.
Communicate with users as appropriate for the project. Many experts believe
that too much communication is better than too little.
Control the changes to all aspects of the system, document the changes, and
communicate them. Formal methods of configuration control are available and
should be used.
Measure the progress of the system and communicate the status -both good
and bad - with the project team regularly. Accurate measurements are essential
for good management of software development projects.
Measure to improve the process, not to penalize individuals. Statistics
about productivity, for example, may be collected from individuals, but
results should be published for the group as a whole. Thus, you remove the
fear of incrimination (being identified as a contributor to poor productivity)
which can produce often unreliable measurements.