Review of basic principles

The aim of software engineering is to produce software that is correct, robust, and efficient.

• Software is produced to solve some problem; if the problem is solved incorrectly, the software is useless.

  Correctness must be ensured against:

  • Obviously incorrect results
  • Plausible, yet incorrect results

• Regardless of the skill and experience of the user, incorrect or invalid data will be provided as input to the program. The software must handle these situations in an appropriate, and non-fatal, manner.

• Software that functions correctly, but only at prohibitive cost, is of little practical benefit.

Software development is often presented in terms of life-cycle models: waterfall model, circular, etc. These models give the impression that the individual steps in the development process, i.e. specification, design, implementation, etc., occur as discrete units. In practice, they overlap and repeat.

• Specifications will always change. The specifying authority never really knows what it wants or needs.
• The design will evolve as knowledge is gained through the implementation process.
• Testing and debugging is most efficiently performed during implementation. The sooner errors are found, the easier is their correction; being corrected early prevents the errors from being propagated into future development.

This leads to the (purely subjective) Rule of Three: all software must be rewritten three times before it is useful.

• The first time the users don't know what they want and you don't know how to provide it.
• The second time the users think they know what they want and you think you know how to provide it.
• The third time the users know what they want and you know how to provide it.

(Of course, by this time, the necessity and requirements for the software have changed and the whole process must start over.)

Obviously, this is a sweeping generalization. Hovever, it does illustrate the unpredictable nature of the development process. Therefore, it is paramount that you plan for change. Your code should be organized into small, reliable, and efficient units that conform to a formal specification. The code should be readable, portable, and maintainable.

On to some practical suggestions...
Back to the 13.016 overview...