5.1 Software Engineering
Software engineering is the application of tools?? methods?? and disciplines to produce and maintain an automated solution to a real-world problem. It requires the identification of a problem?? a computer to execute a software product?? and an environment ??composed of people?? equipment?? computers?? documentation?? and so forth?? in which the software product exists. Clearly?? without computer programs there would be no software product and no software engineering. But this is only a necessary condition; it is not sufficient.
A large-scale software project spans a considerable period of time. A number of distinct phases can be identified over this period of time. Together?? these make up what is known as the "software life cycle".
While the actual terminology may differ?? most authors identify five key phases in the software life cycle.
The first phase?? requirements definition?? refers to the period during which the requirements of the system desired?? that is?? its functional characteristics and operational details?? are specified. The input to this phase is the stated ??often rather loosely stated?? needs for the software. Typically?? a "requirements document" is the output of this phase?? a set of precisely stated properties or constraints that the final product must satisfy. This is not a design?? but rather precedes the design?? specifying what the system should do without specifying how it is to do it. The existence of a requirements document provides something against which a design ??the next phase in the life cycle?? can be validated. Sometimes a quickly developed prototype can be a useful vehicle for debugging requirements.
As with any of the phases?? it is important that errors not be allowed to move into subsequent phases. An error in requirements?? for example?? a misstated function?? leads to a faulty design and an implementation that does not do what is required. If this is allowed to proceed undetected?? say?? until the testing phase?? the cost of repairing this error ??including redesign and re-implementation?? can be substantial.
The second phase?? design?? is predominantly creative?? while some would argue that creativity is inherent and cannot be trained or improved?? it can certainly be enhanced by the use of good procedures and tools. The input to this phase is a ??debugged and validated?? requirements document?? the output is a design expressed in some appropriate form ??for example?? pseudo-code??. Validation of a design is important. Each requirement in the requirements document must have a corresponding design fragment to meet it. Formal verification?? while possible to a limited extent?? can be exceedingly difficult. More informal revolve the entire design team?? management?? and even the client.
The third phase?? implementation?? is the actual coding of the design developed in the second phase. The lure of this phase is strong?? and many a foolhardy programmer has been drawn to it before adequately laying the groundwork in the first two phases. As a result?? requirements are incompletely understood and the design is flawed. The implementation proceeds blindly?? and many problems arise as a result.
The fourth phase?? testing?? is concerned with demonstrating tile correctness of the implemented program. Inevitably some testing is performed as part of the previous two phases as well. Any experienced programmer mentally tests each line as it is produced and mentally simulates the execution of any module prior to any formal testing stage. Testing is never easy. Edsger Dijkstra has written that while testing effectively shows tile presence of errors?? it can never show their absence. A "successful" test run means only that no errors were uncovered with the particular circumstances tested; it says nothing about other circumstances. In theory?? the only way that testing can show that a program is correct as if all possible cases are tried ??known as an exhaustive test???? a situation technically impossible for even the simplest programs. Suppose?? for example?? that we have written a program to compute the average grade on an examination. An exhaustive test would require all possible combinations of marks and class sizes; it could take many years to complete the test.
The fifth phase is program maintenance phase. Student programmers?? unfortunately?? rarely become involved in this phase. Its importance in the real world?? however?? cannot be over emphasized?? since the cost of maintaining a widely used program can match or exceed the cost of developing it. Unlike hardware maintenance?? software maintenance deals not with repair of deteriorated components?? but with repair of design defects?? which may include the provision of added functions to meet new needs. The ability of programmers to produce new programs is clearly affected by the amount of time they spend maintaining old ones. The inevitability of maintenance must be recognized?? and steps must be taken to reduce its time consumption.
Software design can be viewed in the same way. We use the requirement specification to define the problem. Then?? we declare something to be a solution to a problem if it satisfies all the requirements in the specification. In many cases?? the number of possible solutions is limitless. A customer can choose to implement one solution from among several possibilities.
