Rob Kremer

UofC

Practical Software Engineering


Software Engineering--The Problem



Software Engineering

Techniques, methods and theories which allow us to plan, design, develop, and maintain the software for modern computer systems.

Scenarios

  1. An air traffic controller, relying on information from his computer console, directs two Boeing 747's onto intersecting paths. The jets collide and burst into flame, and all aboard perish. -- Washington Post
  2. A hospital minicomputer, monitoring a patient recovering from surgery, fails to alert hospital staff that the patient is having a stroke. The patient dies. -- Washington Post
  3. A company discovers that its computer has mangled valuable and sensitive information beyond recovery. The loss gravely weakens the company's market position. -- Washington Post
  4. "Systematic Errors: A new law aims to prevent software meltdown in federal agencies", Scientific American, May 1996 -- the DOE can't get reliable software to replace the aniquated software that tracks nuclear waste
  5. "Software for Reliable Networks", Scientific American, May 1996 -- "brownouts" on the Web
  6. "Battling the Enemy Within: A billion-dollar fiascois just the tip of the military's software problems", Scientific American, April 1996 -- A major U.S. Army initiative to modernize thousands of aging computer systems has hit the skids, careening far beyond schedule and well over budget. The 10-year project, known as the Sustaining Base Information Services (SBIS) program, is supposed to replace some 3,700 automated applications by the year 2002. The current systems automate virtually every business function--from payroll and personnel management to budgeting and health care--at more than 380 installations worldwide. But after investing almost three years and about $158 million, the army has yet to receive a single replacement system.
  7. "Software Gone Awry", Scientific American, October 1996 --Investigators appointed by the European Space Agency reported in July that a software bug brought down the new $8-billion Ariane 5 rocket, which exploded.
  8. "ONE SMALL STEP: The next big advance in chip design arrives one year early", Scientific American, August 1996 -- VLSI design software can't keep up to progress in chip integration, software may stifle progress
  9. "Canned Software", Scientific American, August 1996 -- The U.S. Army will terminate its Sustaining Base Information Systems program at the end of fiscal year 1997. The program was to have replaced some 3,700 computer systems by 2002. To date, the army has spent more than $150 million yet has received only a handful of replacement systems.
  10. "Computer bug bites Alberta exchange", Calgary Herald, October 24, 1996 -- The Alberta Stock Exchange crashed at 7:38 a.m. Wednesday, brought down by a glitch in its brand new, fully computerized trading system.

These problems stem from an unrealistic view of what it takes to construct the software to perform these tasks.

To improve the record we must:

The Size of the Problem

US government planned to spent $26.5 billion on information technology in 1996. Boehm estimates 1995 world-wide software costs to be $435 billion. Software costs will continue to rise (Boehm says 12%/year) although hardware costs may decrease because:

  1. a new application means new programs
  2. new computers need new software or modifications of existing software.
  3. programming is a labour-intensive skill.

Software errors result in two costs:

  1. the harm which ensues.
  2. the effort of correction.

e.g. electronic-funds-transfer system.

The Classic Life Cycle or Waterfall Model

The following activities occur during the life cycle paradigm:

This is the most widely used approach to software engineering. It leads to systematic, rational software development, but like any generic model, the life cycle paradigm can be problematic for the following reasons:

  1. The rigid sequential flow of the model is rarely encountered in real life. Iteration can occur causing the sequence of steps to become muddled.
  2. It is often difficult for the customer to provide a detailed specification of what is required early in the process. Yet this model requires a definite specification as a necessary building block for subsequent steps.
  3. Much time can pass before any operational elements of the system are available for customer evaluation. If a major error in implementation is made, it may not be uncovered until much later.

Do these potential problems mean that the life cycle paradigm should be avoided? Absolutely not! They do mean, however, that the application of this software engineering paradigm must be carefully managed to ensure successful results.

Prototyping

Prototyping moves the developer and customer toward a "quick" implementation. Prototyping begins with requirements gathering. Meetings between developer and customer are conducted to determine overall system objectives and functional and performance requirements. The developer then applies a set of tools to develop a quick design and build a working model (the "prototype") of some element(s) of the system. The customer or user "test drives" the prototype, evaluating its function and recommending changes to better meet customer needs. Iteration occurs as this process is repeated, and an acceptable model is derived. The developer then moves to "productize" the prototype by applying many of the steps described for the classic life cycle.

In object oriented programming a library of reusable objects (data structures and associated procedures) the software engineer can rapidly create prototypes and production programs.

The benefits of prototyping are:

  1. a working model is provided to the customer/user early in the process, enabling early assessment and bolstering confidence,
  2. the developer gains experience and insight by building the model, thereby resulting in a more solid implementation of "the real thing"
  3. the prototype serves to clarify otherwise vague requirements, reducing ambiguity and improving communication between developer and user.

But prototyping also has a set of inherent problems:

  1. The user sees what appears to be a fully working system (in actuality, it is a partially working model) and believes that the prototype (a model) can be easily transformed into a production system. This is rarely the case. Yet many users have pressured developers into releasing prototypes for production use that have been unreliable, and worse, virtually unmaintainable.
  2. The developer often makes technical compromises to build a "quick and dirty" model. Sometimes these compromises are propagated into the production system, resulting in implementation and maintenance problems.
  3. Prototyping is applicable only to a limited class of problems. In general, a prototype is valuable when heavy human-machine interaction occurs, when complex output is to be produced or when new or untested algorithms are to be applied. It is far less beneficial for large, batch-oriented processing or embedded process control applications.

Project phases for the development for any large system.

  1. Initial conception
  2. Requirements analysis
  3. Specification
  4. Initial design
  5. Verification and test of design
  6. Redesign
  7. Prototype manufacturing
  8. Assembly and system-integration tests
  9. Acceptance tests (validation of design)
  10. Production (if several systems are required)
  11. Field (operational) trial and debugging
  12. Field maintenance
  13. Design and installation of added features
  14. System discard (death of system) or complete system redesign.

Boehm gives figures for several systems showing about

Documentation was not included, estimated at extra 10%.

As a project progresses, the cost of changes increase dramatically. The reasons for increases in cost are:

  1. Testing becomes more complex and costly;
  2. Documentation of changes becomes more widespread and costly;
  3. Communication of problems and changes involves many people;
  4. Repeating of previous tests (regression testing) becomes costly;
  5. Once operation is begun, the development team is disbanded and reassigned.

Further reading


UofC Practical Software Engineering, Department of Computer Science

Rob Kremer