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.


  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.
  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.
  3. A company discovers that its computer has mangled valuable and sensitive information beyond recovery. The loss gravely weakens the company's market position.
(Examples of computer errors from Washington Post)

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

To improve the record we must:

The Size of the Problem

US government spent $57 billion in 1980 on computer systems, $32 billion (56%) on software. Software costs will continue to rise 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 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%.

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.

Practical Software Engineering, Department of Computer Science 7-Jan-96