Prescriptive Models

3.1.1 Waterfall Model 3.2 Incremental Process Models

3.2.1 Incremental Model 3.2.2 RAD Model 3.3 Summary

3.4 Keywords 3.5 Review Questions 3.6 Further Readings

Objectives

After studying this unit, you will be able to:

 Recognize the perspective model

 Describe the incremental models

 Demonstrate the waterfall model

 Explain the RAD model

Introduction

There are three major models of the software engineering process. The waterfall model was for many years the front runner and is required for many military applications. (The procurement process of the US military has had a profound effect on computer science and software engineering in particular.) It is a rigid system well suited to applications where the buyer is as sophisticated about computer systems as the seller.

Prototyping is popular with those who work in the marketplace of “user friendly” software.

This software is historically less maintainable (and less maintained) than the so called “big iron” applications that were historically developed using the waterfall model. The incremental model works from the notion that software is built. The Spiral model is a more recent model that tries to enjoy the best of both worlds. Each of these models shares some common features.

In particular they all involve establishing the requirements that the system is to meet.

3.1 Prescriptive Models

Prescriptive process models advocate an orderly approach to software engineering that leads to a few questions

 If prescriptive process models strive for structure and order are they inappropriate for a software world that thrives on change?

Software Engineering

Notes  Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?

It defines a distinct set of activities, actions, tasks, milestones, and work products that are required to engineer high-quality software.

The activities may be waterfall model, incremental, or evolutionary.

Did u know? What is the exact meaning of perspective modeling?

A modeling perspective in information systems is a particular way to represent pre-selected aspects of a system. Any perspective has a different focus, conceptualization, dedication and visualization of what the model is representing.

3.1.1 Waterfall Model

The simplest software development life cycle model is the waterfall model, which states that the phases are organized in a linear order. However, there are many variations of the waterfall model depending on the nature of activities and the flow of control between them. In a typical model, a project begins with feasibility analysis. On successfully demonstrating the feasibility of a project, the requirements analysis and project planning begins. The design starts after the requirements analysis is complete and coding begins after the design is complete. Once the

Figure 3.1: The Waterfall Model

Notes programming is completed, the code is integrated and testing is done. On successful completion

of testing, the system is installed. After this, the regular operation and maintenance of the system takes place. The model is shown in Figure 3.2.

We will discuss the activities related to the development of software. Thus, we will only discuss phases from requirements analysis to testing. The requirements analysis phase is mentioned as

“analysis and planning.” Planning is a critical activity in software development. A good plan is based on the requirements of the system and should be done before later phases begin. However, in practice, detailed requirements are not necessary for planning. Consequently, planning usually overlaps with the requirements analysis, and a plan is ready before the later phases begin. This plan is an additional input to all the later phases.

Task Explain how waterfall model comes under the perspective modeling? Give examples to support your answer.

With the waterfall model, the sequence of activities performed in a software development project is: requirement analysis, project planning, system design, detailed design, coding and unit testing, system integration and testing. This is the order in which the different phases will be discussed in this book, keeping the sequence as close as possible to the sequence in which the activities are performed.

Linear ordering of activities has some important consequences. First, to clearly identify the end of a phase and the beginning of the next, some certification mechanism has to be employed at the end of each phase. This is usually done by some verification and validation means that will ensure that the output of a phase is consistent with its input (which is the output of the previous phase), and that the output of the phase is consistent with the overall requirements of the system.

Requirements analysis and specification

Software design

Construction

Testing

Operation and maintenance

The consequence of the need for certification is that each phase must have some defined output that can be evaluated and certified. That is, when the activities of a phase are completed, there should be some product that is produced by that phase. And the goal of a phase is to produce this product. The outputs of the earlier phases are often called work products (or intermediate products) and are usually in the form of documents like the requirements document or design document. For the coding phase, the output is the code. From this point of view, the output of a

Figure 3.2: Waterfall Model

Software Engineering

Notes software project is not just the final program along with the user documentation, but also the requirements document, design document, project plan, test plan, and test results.

The waterfall model derives its name due to the cascading effect from one phase to the other as is illustrated in the Figure 3.2. In this model each phase is well defined, has a starting and ending point, with identifiable deliveries to the next phase.

This model has five phases: (i) requirement analysis and specification, (ii) design, (iii) implementation and unit testing, (iv) integration and system testing and (v) operation and maintenance. All the phases occur one-by-one without overlapping. The next phase begins only after the end of the previous phase.

 Requirement analysis and specification: This phase aims at understanding the exact requirements of the customer and documents them. Both the customer and the software developer work together so as to document all the functions, performance and interfacing requirements of the software. It describes the “what” of the system to be produced and not

“how”. In this phase a large document called Software Requirement Specification document (SRS) is produced which contains the detailed description of what the system will do in the common language.

 Design phase: The aim of this phase is to transform the requirements gathered in the SRS into a suitable form which permits further coding in a programming language. It defines the overall software architecture together with high level and detailed design. All this work is documented as Software Design Description document (SDD).

 Implementation and unit testing phase: The actual coding begins at his stage. The implementation goes smoothly if the SDD has complete information required by the software engineers. During testing, the code is thoroughly examined and modified. Small modules are testes in isolation initially. Thereafter, these modules are tested by writing some overhead code in order to check the interaction between these modules and the flow of intermediate output.

 Integration and system testing: This phase is highly crucial as the quality of the end product is determined by the effectiveness of the testing carried out. Better output will lead to satisfied customers, lower maintenance costs and accurate results. Unit testing determines the efficiency of individual modules. However, in this phase the modules are tested for their interactions with each other and with the system.

 Operation and maintenance phase: Maintenance is the task performed by every user once the software has been delivered to the customer, installed and operational.

Thus, the delivery of software initiates the maintenance phase. The time and efforts spent on the software to keep it operational after release is important. It includes activities like error correction, removal of obsolete functions, optimization and enhancements of functions. It may span for 5 to 50 years.

Notes Thus, in this model the requirements must be clear at the very initial stages. The end product is available relatively late which in turn delays the error recovery.

Let us now consider the rationale behind the waterfall model. There are two basic assumptions for justifying the linear ordering of phases in the manner proposed by the waterfall model.

1. For a successful project resulting in a successful product, all phases listed in the waterfall model must be performed anyway.

2. Any different ordering of the phases will result in a less successful software product.

Notes A successful software product is one that satisfies all the objectives of the development project.

These objectives include satisfying the requirements and performing the development within time and cost constraints. Generally, for any reasonable project size, all the phases listed in the model must be performed explicitly and formally. Informally performing the phases will work only for very small projects. The second reason is the one that is now under debate. For many projects, the linear ordering of these phases is clearly the optimum way to organize these activities. However, some argue that for many projects this ordering of activities is infeasible or sub-optimum. We will discuss some of these ideas shortly. Still, the waterfall model is conceptually the simplest process model for software development that has been used most often.

Project Outputs in Waterfall Model

As we have seen, the output of a project employing the waterfall model is not just the final program along and documentation to use it. There are a number of intermediate outputs that must be produced to produce a successful product. Though the set of documents that should be produced in a project is dependent on how the process is implemented, the following is a set of documents that generally forms the minimum set that should be produced in each project:

 Requirements document

 Project plan

 System design document

 Detailed design document

 Test plan and test reports

 Final code

 Software manuals (e.g., user, installation, etc.)

 Review reports

Except for the last one, these are the outputs of the phases, and they have been briefly discussed.

To certify an output product of a phase before the next phase begins, reviews are often held.

Reviews are necessary, especially for the requirements and design phases, because other certification means are frequently not available. Reviews are formal meetings to uncover deficiencies in a product and will be discussed in more detail later. The review reports are the outcome of these reviews.

Task What have you understood by the project outputs of waterfall model?

Limitations of the Waterfall Model

Software life-cycle models of the waterfall variety are among the first important attempts to structure the software life cycle. However, the waterfall model has limitations. Like a waterfall, progress flows in one direction only, towards completion of the project (from one phase to the next). Schedule compression relaxes this requirement but introduces new complexities.

Well-defined phases, frozen deliverables, and formal change control make the waterfall model a tightly controlled approach to software development. The waterfall model’s success hinges, however, on the ability:

 To set the objectives,

Software Engineering

Notes _ To state requirements explicitly,

 To gather all the knowledge necessary for planning the entire project in the beginning.

 The waterfall model’s original objectives were to make small, manageable, individual development steps (the phases) and to provide enough control to prevent runaway projects.

There are a few problems that have caused dissatisfaction with this phased life-cycle approach.

 The new software system becomes useful only when it is totally finished, which may create problems for cash flow and conflict with organizational (financial) objectives or constraints. Too much money may be tied up during the time the software is developed.

 Neither user nor management can see how good or bad the system is until it comes in. The users may not have a chance to get used to the system gradually.

 Changes that “aren’t supposed to happen”, are not viewed kindly, neither for requirements nor during the operational life of the system. This can shorten the software’s useful life.

Because of these shortcomings, other process models have appeared. They are based on the concept of iteration and evolution.

Waterfall model, although widely used, has some limitations. Here we list some of these:

Despite these limitations, the waterfall model is the most widely used process model. It is well suited for routine types of projects where the requirements are well understood. That is, if the developing organization is quite familiar with the problem domain and the requirements for the software are quite clear, the waterfall model works well.

Self Assessment

Fill in the blanks:

1. The design starts after the requirements analysis is complete and ……….. begins after the design is complete.

2. ……….. is a critical activity in software development.

3. The consequence of the need for ……….. is that each phase must have some defined output that can be evaluated and certified.

4. A successful software product is one that satisfies all the objectives of the

………. project.

5. Schedule compression relaxes this requirement but introduces new………..

6. The waterfall model’s original objectives were to make small, ………., individual development steps to provide enough control to prevent runaway projects.

7. Requirement Specification document (SRS) is produced which contains the detailed description of what the system will do in the ……… language.