Chapter 2

References:

The Waterfall Model is a classic and sequential approach to software

development, where each phase must be completed before moving on to
the next. It is called the "Waterfall" model because the development
process flows downward, like a waterfall, through several phases.

Phases of the Waterfall Model:

1. Requirement Analysis:
○ In this phase, all project requirements are gathered and
documented.
2. System Design:
○ Based on the requirements, the system architecture and design
are created.
3. Implementation:
○ The actual coding of the software takes place in this phase.
4. Integration and Testing:
○ Once coding is completed, the system is tested to identify
defects or bugs.
5. Deployment:
○ The software is deployed into the real environment, or released
to the customer.
6. Maintenance:
○ After deployment, the software may need maintenance to fix
issues, make updates, or adapt to new environments.

Diagram of the Waterfall Model:

Features of the SDLC Waterfall Model
1. Sequential Approach: The waterfall model involves a sequential

approach to software development, where each phase of the

project is completed before moving on to the next one.

2. Document-Driven: The waterfall model relies heavily on

documentation to ensure that the project is well-defined and the

project team is working towards a clear set of goals.

3. Quality Control: The waterfall model places a high emphasis on

quality control and testing at each phase of the project, to ensure

that the final product meets the requirements and expectations of

the stakeholders.
 4. Rigorous Planning: The waterfall model involves a rigorous

planning process, where the project scope, timelines, and

deliverables are carefully defined and monitored throughout the

project lifecycle.

Importance of SDLC Waterfall Model

1. Clarity and Simplicity: The linear form of the Waterfall Model

offers a simple and unambiguous foundation for project

development.

2. Clearly Defined Phases: The Waterfall Model’s phases each have

unique inputs and outputs, guaranteeing a planned development

with obvious checkpoints.

3. Documentation: A focus on thorough documentation helps with

software comprehension, upkeep, and future growth.

4. Stability in Requirements: Suitable for projects when the

requirements are clear and steady, reducing modifications as the

project progresses.

5. Resource Optimization: It encourages effective task-focused

work without continuously changing contexts by allocating

resources according to project phases.

6. Relevance for Small Projects: Economical for modest projects

with simple specifications and minimal complexity.

Advantages of the SDLC Waterfall Model
The classical waterfall model is an idealistic model for software
development. It is very simple, so it can be considered the basis for other
software development life cycle models. Below are some of the major
advantages of this SDLC model.

● Easy to Understand: The Classical Waterfall Model is very

simple and easy to understand.

● Individual Processing: Phases in the Classical Waterfall model

are processed one at a time.

● Properly Defined: In the classical waterfall model, each stage in

the model is clearly defined.

● Clear Milestones: The classical Waterfall model has very clear

and well-understood milestones.

● Properly Documented: Processes, actions, and results are very

well documented.

● Reinforces Good Habits: The Classical Waterfall Model

reinforces good habits like define-before-design and

design-before-code.

● Working: Classical Waterfall Model works well for smaller

projects and projects where requirements are well understood.

Disadvantages of the SDLC Waterfall Model

The Classical Waterfall Model suffers from various shortcomings we can’t
use it in real projects, but we use other software development lifecycle
models which are based on the classical waterfall model. Below are some
major drawbacks of this model.

● No Feedback Path: In the classical waterfall model evolution of

software from one phase to another phase is like a waterfall. It

assumes that no error is ever committed by developers during any

phase. Therefore, it does not incorporate any mechanism for error

correction.

● Difficult to accommodate Change Requests: This model

assumes that all the customer requirements can be completely

and correctly defined at the beginning of the project, but the

customer’s requirements keep on changing with time. It is difficult

to accommodate any change requests after the requirements

specification phase is complete.

● No Overlapping of Phases: This model recommends that a new

phase can start only after the completion of the previous phase.

But in real projects, this can’t be maintained. To increase efficiency

and reduce cost, phases may overlap.

● Limited Flexibility: The Waterfall Model is a rigid and linear

approach to software development, which means that it is not

well-suited for projects with changing or uncertain requirements.

 Once a phase has been completed, it is difficult to make changes

or go back to a previous phase.

● Limited Stakeholder Involvement: The Waterfall Model is a

structured and sequential approach, which means that

stakeholders are typically involved in the early phases of the

project (requirements gathering and analysis) but may not be

involved in the later phases (implementation, testing, and

deployment).

● Late Defect Detection: In the Waterfall Model, testing is typically

done toward the end of the development process. This means

that defects may not be discovered until late in the development

process, which can be expensive and time-consuming to fix.

● Lengthy Development Cycle: The Waterfall Model can result in a

lengthy development cycle, as each phase must be completed

before moving on to the next. This can result in delays and

increased costs if requirements change or new issues arise.

When to Use the SDLC Waterfall Model?

Here are some cases where the use of the Waterfall Model is best suited:

Well-understood Requirements: Before beginning development,

there are precise, reliable, and thoroughly documented requirements

available.
Very Little Changes Expected: During development, very little

adjustments or expansions to the project’s scope are anticipated.

Small to Medium-Sized Projects: Ideal for more manageable

projects with a clear development path and little complexity.

Predictable: Projects that are predictable, low-risk, and able to be

addressed early in the development life cycle are those that have

known, controllable risks.

Regulatory Compliance is Critical: Circumstances in which

paperwork is of utmost importance and stringent regulatory

compliance is required.

Client Prefers a Linear and Sequential Approach: This situation

describes the client’s preference for a linear and sequential approach

to project development.

Limited Resources: Projects with limited resources can benefit from

a set-up strategy, which enables targeted resource allocation.

Spiral Model:
 The Spiral Model is one of the most important Software

Development Life Cycle models. The Spiral Model is a combination

of the waterfall model and the iterative model. It provides support

for Risk Handling. The Spiral Model was first proposed by Barry

Boehm. This article focuses on discussing the Spiral Model in detail.

The Spiral Model is a Software Development Life Cycle (SDLC) model

that provides a systematic and iterative approach to software

development. In its diagrammatic representation, looks like a spiral with

many loops. The exact number of loops of the spiral is unknown and can

vary from project to project. Each loop of the spiral is called a phase of the

software development process.

Some Key Points regarding the phase of a Spiral Model:

1. The exact number of phases needed to develop the product can

be varied by the project manager depending upon the project

risks.

2. As the project manager dynamically determines the number of

phases, the project manager has an important role in developing a

product using the spiral model.

 3. It is based on the idea of a spiral, with each iteration of the spiral

representing a complete software development cycle, from

requirements gathering and analysis to design, implementation,

testing, and maintenance.

What Are the Phases of the Spiral Model?

The Spiral Model is a risk-driven model, meaning that the focus is on

managing risk through multiple iterations of the software development

process. It consists of the following phases:

1. Objectives Defined: In first phase of the spiral model we clarify

what the project aims to achieve, including functional and

non-functional requirements.

2. Risk Analysis: In the risk analysis phase, the risks associated with

the project are identified and evaluated.

3. Engineering: In the engineering phase, the software is developed

based on the requirements gathered in the previous iteration.

4. Evaluation: In the evaluation phase, the software is evaluated to

determine if it meets the customer’s requirements and if it is of

high quality.

5. Planning: The next iteration of the spiral begins with a new

planning phase, based on the results of the evaluation.

The Spiral Model is often used for complex and large software

development projects, as it allows for a more flexible and adaptable

approach to software development. It is also well-suited to projects with

significant uncertainty or high levels of risk.

1. Objectives determination and identify alternative solutions:

Requirements are gathered from the customers and the objectives

are identified, elaborated, and analyzed at the start of every

phase. Then alternative solutions possible for the phase are

proposed in this quadrant.

2. Identify and resolve Risks: During the second quadrant, all the

possible solutions are evaluated to select the best possible

solution. Then the risks associated with that solution are

 identified and the risks are resolved using the best possible

strategy. At the end of this quadrant, the Prototype is built for the

best possible solution.

3. Develop the next version of the Product: During the third

quadrant, the identified features are developed and verified

through testing. At the end of the third quadrant, the next version

of the software is available.

4. Review and plan for the next Phase: In the fourth quadrant, the

Customers evaluate the so-far developed version of the software.

In the end, planning for the next phase is started.

Advantages of the Spiral Model

Below are some advantages of the Spiral Model.

1. Risk Handling: The projects with many unknown risks that occur

as the development proceeds, in that case, Spiral Model is the

best development model to follow due to the risk analysis and

risk handling at every phase.

2. Good for large projects: It is recommended to use the Spiral

Model in large and complex projects.

3. Flexibility in Requirements: Change requests in the

Requirements at a later phase can be incorporated accurately by

using this model.

 4. Customer Satisfaction: Customers can see the development of

the product at the early phase of the software development and

thus, they habituated with the system by using it before

completion of the total product.

5. Iterative and Incremental Approach: The Spiral Model provides

an iterative and incremental approach to software development,

allowing for flexibility and adaptability in response to changing

requirements or unexpected events.

6. Emphasis on Risk Management: The Spiral Model places a

strong emphasis on risk management, which helps to minimize

the impact of uncertainty and risk on the software development

process.

7. Improved Communication: The Spiral Model provides for regular

evaluations and reviews, which can improve communication

between the customer and the development team.

8. Improved Quality: The Spiral Model allows for multiple iterations

of the software development process, which can result in

improved software quality and reliability.

Disadvantages of the Spiral Model

Below are some main disadvantages of the spiral model.
 1. Complex: The Spiral Model is much more complex than other

SDLC models.

2. Expensive: Spiral Model is not suitable for small projects as it is

expensive.

3. Too much dependability on Risk Analysis: The successful

completion of the project is very much dependent on Risk

Analysis. Without very highly experienced experts, it is going to

be a failure to develop a project using this model.

4. Difficulty in time management: As the number of phases is

unknown at the start of the project, time estimation is very

difficult.

5. Complexity: The Spiral Model can be complex, as it involves

multiple iterations of the software development process.

6. Time-Consuming: The Spiral Model can be time-consuming, as it

requires multiple evaluations and reviews.

7. Resource Intensive: The Spiral Model can be resource-intensive,

as it requires a significant investment in planning, risk analysis,

and evaluations.

When To Use the Spiral Model?

1. When a project is vast in software engineering, a spiral model is

utilized.
 2. A spiral approach is utilized when frequent releases are

necessary.

3. When it is appropriate to create a prototype

4. When evaluating risks and costs is crucial

5. The spiral approach is beneficial for projects with moderate to

high risk.

6. The SDLC’s spiral model is helpful when requirements are

complicated and ambiguous.

7. If modifications are possible at any moment

8. When committing to a long-term project is impractical owing to

shifting economic priorities.

Prototyping Model
Prototyping is defined as the process of developing a working replication
of a product or system that has to be engineered. It offers a small-scale
facsimile of the end product and is used for obtaining customer feedback.
Steps of Prototyping Model
Step 1: Requirement Gathering and Analysis: This is the initial step in
designing a prototype model. In this phase, users are asked about what
they expect or what they want from the system.

Step 2: Quick Design: This is the second step in the Prototyping Model.
This model covers the basic design of the requirement through which a
quick overview can be easily described.

Step 3: Build a Prototype: This step helps in building an actual prototype

from the knowledge gained from prototype design.

Step 4: Initial User Evaluation: This step describes the preliminary testing
where the investigation of the performance model occurs, as the customer
will tell the strengths and weaknesses of the design, which was sent to
the developer.
Step 5: Refining Prototype: If any feedback is given by the user, then
improving the client’s response to feedback and suggestions, the final
system is approved.

Step 6: Implement Product and Maintain: This is the final step in the
phase of the Prototyping Model where the final system is tested and
distributed to production, here the program is run regularly to prevent
failures.

Advantages of Prototyping Model

● The customers get to see the partial product early in the life cycle.

This ensures a greater level of customer satisfaction and comfort.

● New requirements can be easily accommodated as there is scope

for refinement.

● Missing functionalities can be easily figured out.

● Errors can be detected much earlier thereby saving a lot of effort

and cost, besides enhancing the quality of the software.

● The developed prototype can be reused by the developer for

more complicated projects in the future.

● Flexibility in design.

● Early feedback from customers and stakeholders can help guide

the development process and ensure that the final product meets

their needs and expectations.

● Prototyping can be used to test and validate design decisions,

allowing for adjustments to be made before significant resources

are invested in development.

● Prototyping can help reduce the risk of project failure by

identifying potential issues and addressing them early in the

process.

● Prototyping can facilitate communication and collaboration

among team members and stakeholders, improving overall

project efficiency and effectiveness.

 ● Prototyping can help bridge the gap between technical and

non-technical stakeholders by providing a tangible representation

of the product.

Disadvantages of the Prototyping Model

● Costly concerning time as well as money.

● There may be too much variation in requirements each time the

prototype is evaluated by the customer.

● Poor Documentation due to continuously changing customer

requirements.

● It is very difficult for developers to accommodate all the changes

demanded by the customer.

● There is uncertainty in determining the number of iterations that

would be required before the prototype is finally accepted by the

customer.

● After seeing an early prototype, the customers sometimes

demand the actual product to be delivered soon.

● Developers in a hurry to build prototypes may end up with

sub-optimal solutions.

● The customer might lose interest in the product if he/she is not

satisfied with the initial prototype.

 ● The prototype may not be scalable to meet the future needs of

the customer.

● The prototype may not accurately represent the final product due

to limited functionality or incomplete features.

● The focus on prototype development may shift away from the

final product, leading to delays in the development process.

● The prototype may give a false sense of completion, leading to

the premature release of the product.

● The prototype may not consider technical feasibility and

scalability issues that can arise during the final product

development.

● The prototype may be developed using different tools and

technologies, leading to additional training and maintenance

costs.

● The prototype may not reflect the actual business requirements of

the customer, leading to dissatisfaction with the final product.

Applications of Prototyping Model

● The Prototyping Model should be used when the requirements of

the product are not clearly understood or are unstable.

● The prototyping model can also be used if requirements are

changing quickly.
 ● This model can be successfully used for developing user

interfaces, high-technology software-intensive systems, and

systems with complex algorithms and interfaces.

● The prototyping Model is also a very good choice to demonstrate

the technical feasibility of the product.

Incremental Process Model

The Incremental Process Model is also known as the Successive version
model. This article focuses on discussing the Incremental Process Model in
detail.
What is the Incremental Process Model?
First, a simple working system implementing only a few basic features is
built and then that is delivered to the customer. Then thereafter many
successive iterations/ versions are implemented and delivered to the
customer until the desired system is released.
When to use the Incremental Process Model
1. Funding Schedule, Risk, Program Complexity, or need for early

realization of benefits.

2. When Requirements are known up-front.

3. When Projects have lengthy development schedules.

4. Projects with new Technology.

● Error Reduction (core modules are used by the customer

from the beginning of the phase and then these are

tested thoroughly).

● Uses divide and conquer for a breakdown of tasks.

● Lowers initial delivery cost.

● Incremental Resource Deployment.

 5. Requires good planning and design.

6. The total cost is not lower.

7. Well-defined module interfaces are required.

Characteristics of Incremental Process Model

1. System development is divided into several smaller projects.

2. To create a final complete system, partial systems are constructed

one after the other.

3. Priority requirements are addressed first.

4. The requirements for that increment are frozen once they are

created.

Advantages of the Incremental Process Model

1. Prepares the software fast.

2. Clients have a clear idea of the project.

3. Changes are easy to implement.

4. Provides risk handling support, because of its iterations.

5. Adjusting the criteria and scope is flexible and less costly.

6. Comparing this model to others, it is less expensive.

7. The identification of errors is simple.

Disadvantages of the Incremental Process Model

1. A good team and proper planned execution are required.
 2. Because of its continuous iterations the cost increases.

3. Issues may arise from the system design if all needs are not

gathered upfront throughout the program lifecycle.

4. Every iteration step is distinct and does not flow into the next.

5. It takes a lot of time and effort to fix an issue in one unit if it needs

to be corrected in all the units.

What is Extreme Programming (XP)?

Basic Principles of Extreme programming
● Coding: The concept of coding which is used in the XP model is

slightly different from traditional coding. Here, the coding activity

includes drawing diagrams (modeling) that will be transformed

into code, scripting a web-based system, and choosing among

several alternative solutions.

● Testing: The XP model gives high importance to testing and

considers it to be the primary factor in developing fault-free

software.

● Listening: The developers need to carefully listen to the

customers if they have to develop good quality software.

Sometimes programmers may not have the depth knowledge of

the system to be developed. So, the programmers should

understand properly the functionality of the system and they have

to listen to the customers.

● Designing: Without a proper design, a system implementation

becomes too complex, and very difficult to understand the

solution, thus making maintenance expensive. A good design

results elimination of complex dependencies within a system. So,

effective use of suitable design is emphasized.

● Feedback: One of the most important aspects of the XP model is

to gain feedback to understand the exact customer needs.

 Frequent contact with the customer makes the development

effective.

● Simplicity: The main principle of the XP model is to develop a

simple system that will work efficiently in the present time, rather

than trying to build something that would take time and may

never be used. It focuses on some specific features that are

immediately needed, rather than engaging time and effort on

speculations of future requirements.

● Pair Programming: XP encourages pair programming where two

developers work together at the same workstation. This approach

helps in knowledge sharing, reduces errors, and improves code

quality.

● Continuous Integration: In XP, developers integrate their code

into a shared repository several times a day. This helps to detect

and resolve integration issues early on in the development

process.

● Refactoring: XP encourages refactoring, which is the process of

restructuring existing code to make it more efficient and

maintainable. Refactoring helps to keep the codebase clean,

organized, and easy to understand.

 ● Collective Code Ownership: In XP, there is no individual

ownership of code. Instead, the entire team is responsible for the

codebase. This approach ensures that all team members have a

sense of ownership and responsibility towards the code.

● Planning Game: XP follows a planning game, where the

customer and the development team collaborate to prioritize and

plan development tasks. This approach helps to ensure that the

team is working on the most important features and delivers

value to the customer.

● On-site Customer: XP requires an on-site customer who works

closely with the development team throughout the project. This

approach helps to ensure that the customer’s needs are

understood and met, and also facilitates communication and

feedback.

Applications of Extreme Programming (XP)

Some of the projects that are suitable to develop using the XP model are
given below:

● Small projects: The XP model is very useful in small projects

consisting of small teams as face-to-face meeting is easier to

achieve.
● Projects involving new technology or Research projects: This

type of project faces changing requirements rapidly and technical

problems. So XP model is used to complete this type of project.

● Web development projects: The XP model is well-suited for web

development projects as the development process is iterative and

requires frequent testing to ensure the system meets the

requirements.

● Collaborative projects: The XP model is useful for collaborative

projects that require close collaboration between the

development team and the customer.

● Projects with tight deadlines: The XP model can be used in

projects that have a tight deadline, as it emphasizes simplicity and

iterative development.

● Projects with rapidly changing requirements: The XP model is

designed to handle rapidly changing requirements, making it

suitable for projects where requirements may change frequently.

● Projects where quality is a high priority: The XP model places a

strong emphasis on testing and quality assurance, making it a

suitable approach for projects where quality is a high priority.

1. Planning: The first stage of Extreme Programming is planning.

During this phase, clients define their needs in concise

descriptions known as user stories. The team calculates the effort

required for each story and schedules releases according to

priority and effort.

2. Design: The team creates only the essential design needed for

current user stories, using a common analogy or story to help

everyone understand the overall system architecture and keep the

design straightforward and clear.

3. Coding: Extreme Programming (XP) promotes pair programming

i.e. wo developers work together at one workstation, enhancing

code quality and knowledge sharing. They write tests before

 coding to ensure functionality from the start (TDD), and

frequently integrate their code into a shared repository with

automated tests to catch issues early.

4. Testing: Extreme Programming (XP) gives more importance to

testing that consist of both unit tests and acceptance test. Unit

tests, which are automated, check if specific features work

correctly. Acceptance tests, conducted by customers, ensure that

the overall system meets initial requirements. This continuous

testing ensures the software’s quality and alignment with

customer needs.

5. Listening: In the listening phase regular feedback from customers

to ensure the product meets their needs and to adapt to any

changes.

Advantages of Extreme Programming (XP)

● Slipped schedules: Timely delivery is ensured through slipping

timetables and doable development cycles.

● Misunderstanding the business and/or domain − Constant

contact and explanations are ensured by including the client on

the team.
● Canceled projects: Focusing on ongoing customer engagement

guarantees open communication with the consumer and prompt

problem-solving.

● Staff turnover: Teamwork that is focused on cooperation provides

excitement and goodwill. Team spirit is fostered by

multidisciplinary cohesion.

● Costs incurred in changes: Extensive and continuing testing

ensures that the modifications do not impair the functioning of the

system. A functioning system always guarantees that there is

enough time to accommodate changes without impairing ongoing

operations.

● Business changes: Changes are accepted at any moment since

they are seen to be inevitable.

● Production and post-delivery defects: the unit tests to find and

repair bugs as soon as possible.