CS302: Software Engineering

Introduction 

Approaches to systems development in professional organizations usually follow one of two basic models: the waterfall model or the evolutionary model.

The Waterfall Model The waterfall model is a very common software development process model. Waterfall is the basis of most of the structured development methods that came into use from the 1970s onwards. It is also known as "The Linear Sequential Model". The linear sequential model suggests a systematic, sequential approach to software development that begins at the system level and progresses through analysis, design, implementation, testing, and support or maintenance, as shown in Figure 1.4.

The Waterfall model provides a framework for planning top–down systems development. The development flows down a number of successive activity stages. the stages in the waterfall model overlap and feed information to each other.

During design, problems with requirements are identified; during coding, design problems are found, and so on. The development process is not a simple linear model but involves a sequence of iterations of the development activities.

Advantages of the Waterfall Model 

The various advantages of the waterfall model include:

• It is a linear model. 
• It is a segmental model. 
• It is systematic and sequential. 
• It is a simple one. 
• It has proper documentation.

Disadvantages of Waterfall Model

The various disadvantages of the waterfall model include:

• It is difficult to define all requirements at the beginning of a project. 
• This model is not suitable for accommodating any change. 
• A working version of the system is not seen until late in the project's life. 
• It does not scale up well to large projects. 
• It involves heavy documentation. 
• We cannot go backward in the SDLC. 
• There is no sample model for clearly realizing the customer's needs. 
• There is no risk analysis. 
• If there is any mistake or error in any phase then we cannot make good software. 
• It is a document-driven process that requires formal documents at the end of each phase.

Problems with the Waterfall model

The waterfall model is the oldest and the most widely used paradigm for software engineering. Among the problems that are sometimes encountered when the waterfall model is applied are:

Real projects rarely follow the sequential flow that the model proposes. Although the waterfall model can accommodate iteration, it does so indirectly. As a result, changes can cause confusion as the project team proceeds. 

It is often difficult for the customer to state all requirements explicitly. The waterfall model requires this and has difficulty accommodating the natural uncertainty that exists at the beginning of many projects.

The customer must have patience. A working version of the program(s) will not be available until late in the project time-span. A major blunder, if undetected until the working program is reviewed, can be terrible. 

Each of these problems is real. However, the waterfall model has a definite and important place in software engineering work. This model is only appropriate when the requirements are well-understood. It provides a template into which methods for analysis, design, implementation, testing, and support can be placed. The waterfall model remains a widely used procedural model for software engineering.

Evolutionary Software Process Models 

There is growing recognition that software, like all complex systems, evolves over a period of time. Business and product requirements often change as development proceeds, making a straight path to an end product unrealistic. The linear sequential model is designed for straight-line development. In essence, this waterfall approach assumes that a complete system will be delivered after the linear sequence is completed. Evolutionary models are iterative. They are characterized in a manner that enables software engineers to develop increasingly more complete versions of the software.

The techniques used in an evolutionary development include: 

Exploratory development, where the objective of the process is to work with the client to explore their requirements and deliver a final system. The development starts with the parts of the system which are understood. The system evolves by adding new features as they are proposed by the client.

Prototyping is where the objective of the development is to understand the customer's requirements and hence develop a better requirements definition for the system. The prototype concentrates on experimenting with those parts of the client requirements which are poorly understood. 

Evolutionary development is based on the idea of developing an initial implementation, exposing this to user comment and refine through many versions until an adequate system has been developed.

Two evolutionary approaches 

• The Incremental Model 
• The Spiral Model 

 The Incremental Model

Rather than delivering the system as a single delivery, the development and delivery are broken down into increments with each increment delivering part of the required functionality, as shown in Figure 1.5. User requirements are prioritized, and the highest priority requirements are included in early increments. Once the development of an increment is started, the requirements are frozen, though requirements for later increments can continue to evolve.

The spiral model

The spiral model is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model. It provides the potential for rapid development of incremental versions of the software. Using the spiral model, software is developed in a series of incremental releases. The project is executed in a series of short lifecycles, each one ending with a release of executable software. During early iterations, the incremental release might be a paper model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced. 

As per Figure 1.6, a spiral model is divided into a number of framework activities, also called task regions. Typically, there are between three and six task regions

Customer communication – tasks required to establish effective communication between developer and customer. 

Planning – tasks required to define resources, timelines, and other project-related information. 

Risk analysis – tasks required to assess both technical and management risks. 

Engineering – tasks required to build one or more representations of the application.

Construction and release – tasks required to construct, test, install, and provide user support (e.g., documentation and training). 

Customer evaluation – tasks required to obtain customer feedback based on evaluation of the software representations created during the engineering stage and implemented during the installation stage.

Each of the regions is populated by a set of work tasks, called a task set, that are adapted to the characteristics of the project to be undertaken.

Problems with the Iterations model 

A model with the iterations suffers from the following problems.

The process is not visible. It is difficult and expensive to produce documents which reflect every version of the system.

Systems are poorly structured. Continual change tends to corrupt the software structure. 

It is not always feasible for large systems; changes in later versions are very much difficult and sometimes impossible. New understanding and new requirements sometimes force the developer to start the whole project all over again. Software evolution is therefore likely to be difficult and costly. Frequent prototyping is also very expensive. 

These problems directly lead to the problems that the system is difficult to understand and maintain. It is suggested that this model should be used in the following circumstances: 

The development of relatively small systems. 

The development of systems with a short lifetime. Here, the system is developed to support some activity which is bounded in time, and hence the maintenance problem is not an important issue.

The development of systems or parts of large systems where it is impossible to express the detailed specifications in advance.

The ideas, principles and techniques of the evolutionary development process are always useful and should be used in different stages of a wider development process, such as the requirements understanding and validating in the waterfall process.

Conclusion 

There are a number of different software development approaches or process models for software engineering that have been proposed, each of which exhibits strengths and weaknesses, but all have a series of generic phases in common. A software development approach can be chosen based on the nature of the project and application, the methods and tools to be used, and the controls and deliverables that are required.

---

Source: Ellen Ambakisye Kalinga
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.