What is the nature of the software industry?
What is the state of the software industry?
What influences the industry?
"I have traveled the length and breadth of this country and
talked with the
best people, and I can assure you that data processing is a fad that
won't
last out the year."
--The editor in charge of business books for Prentice Hall, 1957
"There is no reason anyone would want a computer in their
home."
--Ken Olson, president, chairman and founder of Digital
Equipment Corp., 1977
| Era | Technology | Practice |
|---|---|---|
|
|
|
mid-1960s to late 1970s |
|
|
mid-1970s to late 1980s |
|
|
mid-1980s to 2000 |
|
|
2000 to ? |
|
|
| Complexity | Software is more complicated than other artifacts
constructed by human beings. Hardware pales in comparison. The
number of possible states for a software product is enormous.
Additionally, the parts of the product can interact. To effectively
construct software this complexity must be brought under
control. |
| Conformity | Software is not usually isolated in the world. Software
is typically an integral part of more intricate systems. Software,
therefore, must interface with existing systems. It must conform to
the way existing systems behave. Compounding this conformity problem
is the sense that since software is not physical it is also the most
flexible. This tends to force software to the most conformable. |
| Changeability | There are, and will continue to be, pressures to change
software. Software is intended to contribute to people's ability to
cope and manage their worlds, worlds that change. Since the
functionality of a system is embodied in the software, changes in
functionality are achieved through changing the software. |
| Invisibility | We have yet to achieve an adequate representation for
systems. We certainly have various graphical and textual
representations for systems, but we do not as yet have any way to
capture an overview of the product that allows us to reason or
communicate about the system. |
During the 1980's, software maintenance accounted for 60% percent of the software budget for an information system organization.
The estimate for 1990's is 80%.
During the 1991 Gulf War, a Scud missile penetrated the Patriot anti-missile shield and struck a barracks near Dhahran, Saudi Arabia. In all 28 Americans were killed, and 98 wounded. The software for the Patriot missile contained a cumulative timing fault. The Patriot was designed to operate for only a few hours at a time, after which the clock was reset. As a result, the fault never had a significant effect and, therefore, was not detected. In the Gulf, however, the Dhahran Patriot missile battery ran continuously for over 100 hours. This caused the accumulated time discrepancy to become large enough to render the system inaccurate. Israeli forces detected the timing problem after only 8 hours and reported the defect to the company. The new software arrived the day after the tragedy.(Schach, p. 4)
In 1986, two cancer patients at the East Texas Cancer Center in Tyler received fatal radiation overdoses from the Therac-25. (Byte, p. 50)
In the summer of 1991, telephone outages occurred in local systems in California and along the Eastern seaboard. The breakdowns were all the fault of an error in signaling software. DSC Communications introduced a bug when it changed three lines of code in the several million-line program. No one thought it necessary to re-test the program with the modifications. (Byte, p. 50)
Today the FAA still uses the air-traffic-control software from the 1970s. It runs on a vacuum-tube IBM9020e. This system contributed almost a dozen failures this past year. The FAA has been working to replace the antiquated system. The FAA has been paying Loral (was IBM Federal Systems) $700-900 per line for the new software to run on hundreds of computers and embedded in new and sophisticated hardware which must respond around the lock to unpredictable real-time events. The FAA decided in June 1994 to can two of the four parts losing $144 million. The fourth part, new workstation software for air-traffic controllers, has cost $1.4 billion, and is currently under the scrutiny of researchers to see if it can be saved.
| Dollar Amount | Percent of Total | |
|---|---|---|
| Software Delivered But Never Successfully Used | $3.2M | 47% |
| Software Paid for But Not Delivered | $1.95M | 29% |
| Software Used But Extensively Reworked or Later Abandoned | $1.3M | 19% |
| Software That Could be Used After Changes | $198K | 3% |
| Software That Could be Used as Delivered | $119K | 2% |
| 16 % successful. | |
| 53 % operational (but less than successful). | |
| 31 % cancelled. |
Mills et. al. (1987) reported there approximately 50 to 60 errors found in every 1000 lines of executable source code during development of a software system
.Basili et. al. (1984) reported that most errors found by users in software are the result of difficulties understanding the problem statement.
Boehm (1981) found for a medium-sized software system 10 lines of executable source code are typically produced per day per person (averaged over the entire period of development).
Go To Lecture [Outline] [Overview]
Go To [311 Course Outline] [CIS Department Page]
Basili, V.R. and Perricone, B.T. (Jan. 1984). Software errors and complexity: An empirical investigation. Communications of the ACM, 27(6), pp. 556-563.
Boehm, B. (1981). Software Engineering Economics. Englewood Cliffs, NJ: Prentice-Hall, Inc.
Mills, H., Dyer, M, and Linger, H. (Sept 1987). IEEE Software, pp. 20-.
Gibbs (September 1994) Software's Chronic Crisis. Scientific American.
Joch (December 1995) How Software Doesn't Work. Byte.
Pressman, R. (1992). Software Engineering: A Practitioner's Approach. New York: McGraw-Hill, Inc.
Schach (1996) Classical and Object-Oriented Software Engineering.