![]() |
The four basic models are: |
![]() |
Waterfall model, also known as the traditional software development life cycle (SDLC). |
![]() |
Waterfall model, also known as the traditional software development life cycle (SDLC). |
![]() |
The spiral model |
![]() |
Incremental process model |
![]() |
Agile development model |
![]() |
Other models include: |
![]() |
Build and fix model |
![]() |
The linear sequential model |
![]() |
The prototyping model (Rapid prototyping model) |
![]() |
Fountain model |
![]() |
Transformation model |
![]() |
Rapid Application Development (RAD) model |
![]() |
Evolutionary process model |
![]() |
Clean room software engineering model |
![]() |
Aspect-Oriented Software Development (AOSD) model |
![]() |
The software engineer chooses a specific software engineering model based on the project properties being |
| developed. |
![]() |
The tools to be used, controls and deliverables are affected and influenced by the chosen model. |
![]() |
In the following subsections we present some the above software engineering models (paradigms). |
![]() |
The waterfall model is also known as the linear sequential model and as classic life cycle model. |
![]() |
This model was developed in 1970 to make the software development process more structured. |
![]() |
It is the oldest and most commonly used software engineering. |
![]() |
It demands a well-defined, step by step approach to software development that begins at the requirements |
| analysis through planning, design, coding, testing, and delivery. |
![]() |
The waterfall model, drawn from an engineering model is used in order to control the development of large |
| software systems. |
![]() |
The waterfall model is visualized as the flowchart in Figure 1. |

![]() |
It consists of different stages which are processed in a linear fashion. The steps in the waterfall mode are: |
| requirements analysis, planning, design, coding, testing, and delivery. Brief description of the phases in the | |
| waterfall model is presented below. |
![]() |
Requirements analysis |
![]() |
In this phase the requirements of the software system are defined. |
![]() |
This answers the 'What is the software system to be developed' question. |
![]() |
It involves the user participation and it ends with an approved set of well-defined requirements | |
| document. |
![]() |
This document is called the software requirement specification (SRS) document. |
![]() |
It is the basis of next stages of the project. |
![]() |
Design |
![]() |
In this phase the logical design of the system is defined. |
![]() |
This answers the 'How is the software system will be developed' question. |
![]() |
This phase uses the requirements specified in the previous phase (the SRS document) and translates | |
| them into design which will solve the problem. |
![]() |
The design phase is an intermediate phase and bridge between 'What' the user/customer wants and | |
| the implemented system (code) that will be created to satisfy the requirements. |
![]() |
Coding |
![]() |
This stage of the model involves the writing of the code. |
![]() |
The actual design is turned into a set of programs. |
![]() |
Testing |
![]() |
The code that is developed in the implementation phase is tested during the testing phase. |
![]() |
This involves unit testing for the lowest level components, integration testing for groups of components | |
| and testing of the system as a whole. |
![]() |
A part of the testing phase are the verification and validation of the system for acceptance (acceptance | |
| testing). |
![]() |
Verification checks the system correctness (building the system right) while validation checks if the | |
| system meets its intended requirements (building the right system). |
![]() |
System validation fulfils the use needs and and requires considerable user involvement. |
![]() |
Delivery |
![]() |
In this phase the system is made operational. Main activities in this phase include training of the | |
| user's, and installation of the system. |
![]() |
Also, in this phase the system is maintained where bugs, errors, and defects are corrected. |
![]() |
The system is made more efficient, new requirements are added and existing functionality and features | |
| modified to meet the changing customer/user/business needs. |
![]() |
In waterfall model each phase starts when the previous stage finishes. The original classical waterfall | |
| model enforces strict sequentially among tasks. |
![]() |
This means that the phases are executed sequentially and no parallelism or overlapping could occur | |
| among them. |
![]() |
There are well-defined boundaries between phases and each stage has a well-defined start and end. |
![]() |
This model is the classic life cycle because of its methodical chronological flow. |
![]() |
The waterfall model was one of the first software models to be developed. |
![]() |
This model is very efficient for projects that have well-known requirements at the beginning of the | |
| project. |
![]() |
Also, in this model fully functional software will be achieved at the last stage of the model. |
![]() |
This problem was addressed by the incremental process model. |
![]() |
The waterfall model has the following advantages: |
![]() |
The model consists of well-defined stages that have well-defined inputs and outputs. |
![]() |
The model adopts the sequences of software engineering practices that leads to a good software | |
| product. |
![]() |
The waterfall model has the following disadvantages: |
![]() |
Real projects rarely follow the flow of activities in this model. |
![]() |
Software requirements must be clearly specified at the beginning of its development. |
![]() |
The model does not adopt any mechanism to handle changes if introduced during design stage. |
![]() |
The model reduces the involvement of the customer between design and testing phase of the project. |
![]() |
The model provides no contribution from the customer for active participation during the intermediate | |
| phase of the development life cycle. |
![]() |
Customers will not wait for a long time to get his software delivered. |
![]() |
The assumption of having well known requirements at the beginning leads to premature decisions. |
![]() |
This model requires does not adopt the natural uncertainty associated with any project at the beginning | |
| of its development cycle. |
![]() |
Despite these disadvantages, the waterfall model remains popular because it adopts the software engineering |
| activities in all of its stages. |
![]() |
When Winston Royce proposed this model he included feedback loops. |
![]() |
Figure 1 removes these loops for simplicity. |
![]() |
Feedback loops are needed to provide feedback between stages to update or re-define those stages at earlier |
| time. |
![]() |
Figure 2 shows the waterfall model with feedback loops shown. |

![]() |
Figure 2 shows the feedback loops needed to provide for overlapping and feedback between phases. |
![]() |
Figure 2 implies that the waterfall model is not a simple linear model but an iterative model. |
![]() |
This model recognizes the fact that at the design phase the development team may have to go back and |
| perform some requirements analysis at its associated stage as more clarity comes in the later design phase. |
![]() |
The waterfall model is not flexible when it comes to partitioning the project into distinct phases. |
![]() |
It is inadequate for realistic validation activities. |
![]() |
However, it generally reflects engineering practice. |
![]() |
The spiral process model (developed by Barry Boehm in 1989) includes the same steps (requirements |
| analysis, planning, design, coding, testing, and delivery) as the waterfall process model. |
![]() |
The motivation behind the development of the spiral process model was due to fact that requirements given at |
| the beginning of the project are incomplete where requirements analysis phase and the design phase are | |
| continuously evolving as time passes. |
![]() |
The steps go through a cyclical motion as requirements and design evolve as shown in figure 3. |

![]() |
As Figure 3 shows, the spiral model is non-linear and cyclic. Each cycle of the spiral consists of 6 phases (as |
| in the waterfall model). |
![]() |
The radius of the spiral represents the cost accumulated so far in the process and the angular dimension |
| represents the program in the process. |
![]() |
Each phase starts with a design goal and ends with the client/customer reviewing the progress thus far. |
![]() |
The spiral model focuses on the constant re-evaluation of the design and risks involved. It can be described |
| as being 'iterative' and 'sequential'. |
![]() |
The model can accommodate any process development model due to its generality. |
![]() |
It is used commonly used for large and complex projects which as a result, can also be described as being |
| expensive. |
![]() |
The spiral model has the following advantages: |
![]() |
Takes into consideration the change of the requirements during the development process. |
![]() |
The model is flexible and can be tailored for a variety of situations, such as reuse, component based | |
| development and prototyping. |
![]() |
Can be adjusted to be used as any other model. |
![]() |
Combines the best features of waterfall and prototyping models. |
![]() |
The spiral model has the following disadvantages: |
![]() |
Complicated, unsuitable for small projects where the requirements are clearly known at the beginning of | |
| the development process. |
![]() |
Similarly to the spiral model, the incremental process model uses the same phases as the waterfall process |
| model. |
![]() |
The difference between this model and the waterfall model is that in this model the phases are much smaller |
| than the waterfall phases. |
![]() |
This model is similar to the spiral model in that the requirements are not complete at project start. |
![]() |
But the difference with the spiral model is that rather than going in a cyclical cycle like the spiral model, the |
| incremental model has something similar to multiple waterfalls within the model. |
![]() |
Figure 4 shows the incremental process model. |

![]() |
The incremental process model allows customers to gent the developed system incrementally and part by |
| part. |
![]() |
They do not need to wait for the whole system to be completed. |
![]() |
This is especially important in very large system where the completion of the whole system takes very long |
| time. |
![]() |
Deliverables are produced by increments where after an initial information strategy planning, the customer |
| could get the first deliverable which is the core product. |
![]() |
Here, the first 'increment' is the core product or the most important functionality of the system. |
![]() |
Basic requirements are addressed, and the core product is produced. Non-basic requirements (some known, |
| others unknown) are addressed later and the rest of the project remains undelivered. |
![]() |
The core product is used and reviewed by the customer and base on customer evaluation, the next increment |
| will be determined. |
![]() |
The plan developed for this increment addresses the new requirements to better meet the needs of the |
| customer and deliver any new feature to the system if needed. |
![]() |
The incremental process is repeated followed by its associated outputs until the entire system is built. |
![]() |
The incremental process model is both evolutionary and interactive approach. |
![]() |
The incremental process model has the following advantages: |
![]() |
It adds flexibility to waterfall model by introducing its incremental iteration approach. |
![]() |
System components can be developed separately. |
![]() |
The system is delivered to the customer incrementally from a small functioning component to entire | |
| operating software. |
![]() |
Early delivery of parts of the functionality for use. |
![]() |
The customer has the capability to give his feedback and evaluation of the system at different stages of | |
| time as the system is incrementally developed. |
![]() |
The highest priority features and functionalities of the system are incorporated in early deliveries. |
![]() |
Re-prioritization is possible in the course of the project. |
![]() |
The incremental process model has the following disadvantages: |
![]() |
Total development costs are higher than in other models. |
![]() |
Total time period for delivery of the complete system is longer. |
![]() |
The success of the development of the whole system is dependent on correct planning of priorities | |
| among system components. Wrong planning can result in a disaster. |
![]() |
A discussion issue among software engineering main players is how much to involve customers with the |
| different stages of the SDLC and how much to overlap these phases. |
![]() |
This is the issue that led to the development of the Agile development model. |
![]() |
The motivation of the development of the Agile development model is the customer Is not always pleased with |
| the product because he/she did not give all of the expected requirements and engineers did not always | |
| understand the requirements. |
![]() |
This model has the customer involved throughout all of the steps and giving continuous feedback on the |
| product. In this model the testing, correctness, validation and verification of the developed component are | |
| implemented with customer being involved to meet his/her needs. |
![]() |
Agile model includes only 4 phases of the SDLC which are: planning, design, coding and testing. |
![]() |
Figure 5 shows the Agile development model. |

![]() |
Agile software development model promotes development iterations through the the software life-cycle. |
![]() |
The Agile development model, also known as the "Extreme Programming" model has the sole focus of time |
| of delivery of the project. |
![]() |
It is designed to allow software projects to be completed in the shortest time possible. |
![]() |
Hence, agile development models are very appropriate for web development, which require rapid delivery of |
| the system. |
![]() |
The incremental process model has the following features: |
![]() |
There are many agile development methods; to develop software in a short time which in turn will | |
| minimize the development risk. |
![]() |
One iteration in agile development model is the Software developed in one unit of time. |
![]() |
Each iteration is an entire software project and they all go through the development stage that includes | |
| requirements analysis, design, coding, testing, and documentation. |
![]() |
An iteration does not necessarily add enough functionality to guarantee releasing the product to market. | |
| But, at the end of the iteration, it should exist a stable release (without bugs). |
![]() |
At every deliverable the project team re-evaluates its priorities to decide the next stage. |
![]() |
Agile methods support the idea of face-to-face communication over written documents. |