A common mistake people make concerning software is assuming that the majority of software development is programming. When they think of programming, their minds conjure up the image of a late-night hacker pounding out code on an old computer in the basement of a musty apartment. While this is certainly one approach to programming, it is hardly the norm and definitely not the way the majority of current software is developed. In fact, programming is only a fraction of the software development process. Today, many other steps are involved in the successful development and deployment of computer software. Taken together, all these steps are referred to as the software life cycle. Often these steps are described by models called software life cycle models. In the next two lessons we will examine two of these models: the waterfall model and the spiral model. First, however, we need to describe the basic processes that make up the software life cycle.

Most models of the software life cycle include the following six processes: requirements engineering, design, programming, integration, delivery, and maintenance. The list below gives a description of each process.

Requirements Engineering
During this process, developers and clients meet to discuss ideas for the new software product. Developers use a variety of techniques in order to assess the real needs of the client. One such technique is rapid prototyping in which a prototype program is built that can mimic the functionality of the desired software. Using this prototype, clients can better understand how the final product will behave and can determine whether this behavior is what they really need. Unless the requirements engineering process is done properly, the resulting software will not be useful to the client even though it may run correctly. The requirements engineering process is completed when the specifications for the new software product are written in a formal document called the requirements specification document.

During this process, the developers decide how they will construct the software so that it meets the specifications agreed upon in the requirements specification document. Usually the design of the software goes through several stages in which it becomes progressively more detailed. This approach to design is called stepwise refinement, and it allows the developers to manage the complexity of software by postponing decisions about details as late as possible in order to concentrate on other important design issues. When the design is complete, it is recorded in the design specification document.

During this process, teams of programmers write the actual code of the software. The software is divided into separate units called modules in order to handle the complexity of the programming process. Not only are these teams responsible for coding their modules, they are also responsible for proper documentation describing their code and for testing the code to insure correctness.
During this process, the individual modules of the software product are combined to form the integrated software product. Since the modules were developed separately, testing is crucial to the integration process. Even with a good design, incompatibilities between modules are likely to exist. These problems need to be identified and corrected to complete the integration.

During this process, the developers deliver the completed software to the clients. Usually the clients will conduct acceptance testing on the software to determine whether or not it meets the specifications agreed upon in the requirements specification document. Once the software is accepted, it is installed and used by the client.
During this process, the software undergoes various changes after delivery in order to fix bugs, add new functionality, port the software to new platforms, or adapt the software to new technologies. Although it may seem that the software should be finished after delivery, this is far from true. All successful software products evolve over time to meet the changing needs of the clients.

You may be surprised to discover that of all these processes, maintenance dominates the cost of the life cycle. The graph below shows the relative cost of the processes that make up the software life cycle. Because maintenance costs are so important, many developers are beginning to use design approaches that result in software which is easier to maintain. At the end of this module we will examine one of these approaches: the object-oriented paradigm.

Approximate relative costs of the phases of the software life cycle [Schach 1999]

Many different models have been created to represent the software life cycle. Although these models use various names for the processes of the life cycle, they all include the six processes described above in one way or another. In addition, these models usually emphasize some other aspect of software development such as a particular design technique (e.g., rapid prototyping), management technique (e.g., risk management), or the model describes a limited domain of software development (e.g., real-time software).