Fig 1: Waterfall Software Development Model
The phrase software crisis alludes to a set of problems encountered in the development of computer software during the 1960s. Within this period the software industry unsuccessfully attempted to build larger and larger software systems (to match advances in hardware technology) by simply scaling up existing development techniques. As a result:
To address these problems the discipline of software engineering came into being.
We can define software engineering as follows:
(Software engineering is) the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.
This embodies a number of themes:
From the above one of the key themes of software engineering is that, like any other commercial product, software has a life cycle associated with it. Many models of the software life cycle have been proposed. The most straightforward is the waterfall model where the output from each development stage "flows" as input into the next stage (see below). The result can be envisaged as a series of waterfalls hence the term "waterfall" model. Although the waterfall model over simplifies the process it provides a convenient framework to facilitate discussion of the "art" of software engineering.
Fig 1: Waterfall Software Development Model
Software development encompasses the middle three phases: design, implementation and testing. The individual phases of the above life cycle are briefly described below.
Requirements analysis and specification. Work begins by establishing and analysing the user's requirement, i.e. determining the nature of the system to be built. Requirements analysis usually results in a requirements specification document or (for small software systems) a requirements specification statement. This specification then defines the "product", and thus must be accepted by both the customer and the developers.
Design. The second phase is to design the desired software system. There are many approaches to design. We will be using a top-down analysis strategy to carry out an initial investigation of the problem and identify the required procedures to be included in the desired software solution. We will then use Nassi-Shneiderman charts to assist in the determination and definition of appropriate algorithms whereby the identified procedures can be realised.
Implementation. During implementation the design is translated into a machine-readable (and consequently executable) form. Some "unit" testing normally takes place as the implementation progresses.
Testing. Once the implementation has been completed it must be tested to ensure that all parts of the program behave in the manner that they are expected to behave. One straight-forward approach in which software can be tested is to identify "meaningful" test cases with which the software can be run. The results produced can then be compared with the expected results and appropriate conclusions drawn. On completion of testing the product is delivered to the customer.
Maintenance As with any other commercial product software must be maintained once it has been delivered. We can identify three categories of maintenance:
A systematic approach to software design simplifies the process and results in software which is understandable, verifiable and reliable without stifling the creativity of the software engineer. One well tried and tested approach is top-down analysis/design whereby a given problem is hierarchically decomposed into sub-problems. The resulting is a hierarchical "break-down" of a problem at different levels of abstraction (levels of detail) which indicates:
The analysis is normally presented using a simple box and line diagram.
A top-down analysis/design is usually realised by encoding the higher levels of the design first, and representing the lower levels of the design by stubs which simulate the function of the lower elements in a simplified manner. On completion of a level a certain amount of testing can be implemented, prior to moving down to the next level. The process continues until the lowest level has been implemented. On completion the entire implementation must be tested.
During the design phase of the software life-cycle the algorithms to address individual sub-problems are specified. An algorithm may be defined as a description of how a particular problem is solved. It consists of a number of elementary operations and instructions about the order in which they should be carried out. Many techniques exist to support the design and specification of algorithms. We will be using Nassi-Shneiderman (NS) charts. This is a graphical design tool whereby algorithms are defined in terms of sequences of one or more "boxes".
The sequence where by a program is executed is referred to as the flow of control. The flow of control also indicates how data moves through a system and the transformations (changes to the data) that occur on the way. Flow of control is generally conceptualised as starting at the top of a program and progressing downwards to exit at the bottom. A complex program may incorporate many choice points and loops whereby flow of control is not immediately obvious. Flow charts are a graphical method of indicating the flow of control through a software system.
Created and maintained by Frans Coenen. Last updated 11 October 1999