Software Engineering

Different types of software

development life cycle models.
(SDLC Process Model )
 PROCESS MODELS
• SDLC – Software Development Life Cycle(PROCESS MODELS)

• The software development lifecycle (SDLC) in software engineering is a methodology

that defines the logical steps for developing a custom software product. This
methodology is used to structure, plan and control the software development process.
• In simple terms, we can define SDLCs as a series of separate methodologies that a
developer can use to standardize the process of software development. A number of
SDLC models are available, but choosing the right one is no easy task: and with
enterprises relying on software, it's key to ensure that the correct model is chosen and
taken forward.
• Process model is a framework that describes the activities, actions, tasks, milestones, and
work products performed at each stage of a software development project that leads to
high quality software.

• Help in the software development

• Guide the software team through a set of framework activities
• Process Models may be linear, incremental or evolutionary.
 Life cycle models(PROCESS MODELS)

The five major software development lifecycle models and how

they work

• Classical Waterfall Model

• Iterative Waterfall Model
• Prototyping Model
• Evolutionary Model
• Spiral Model
 CLASSICAL WATERFALL MODEL
The classical waterfall model is a sequential software development process in which progress
flows downwards (like a waterfall) through the phases of requirements analysis, design,
implementation, testing, and maintenance. The model follows a linear, rigid, and structured
approach, where each phase must be completed before moving on to the next one

it is not a practical model in the sense that it cannot be used in actual software development
projects. Thus, this model can be considered to be a theoretical way of developing software. But
all other life cycle models are essentially derived from the classical waterfall model. So, in order
to be able to appreciate other life cycle models it is necessary to learn the classical waterfall
model. This model is best suited when developers already have designed and developed similar
software in the past and are aware of all its domains.

Waterfall model: This is one of the simplest, classic life-cycle models, also known as the "linear-
sequential" life cycle model. In a waterfall model, each phase must be completed before moving
onto the next. A review process is scheduled at the end of each phase to check that the project is
on the right track. The steps are as follows:
The Waterfall model is a traditional sequential software development process that follows
a linear and sequential approach. It is often used in projects where requirements are well-
defined and unlikely to change significantly throughout the development process
1.Sequential Process: The development process progresses linearly from one phase
to another, and each phase has specific deliverables.

2. Requirements Analysis: In this phase, the requirements for the software are
gathered and documented. It involves understanding the needs of the end-users and
defining the scope of the project.

3.Design: Once the requirements are defined, the software system is designed,
including the architecture, database design, user interface, and other design
components.
4. Implementation: The designed software is developed and coded according to the
specifications defined in the design phase. This phase involves writing and testing
the code.

5. Testing: After the implementation, the software is thoroughly tested to ensure it

meets the specified requirements. This includes unit testing, integration testing,
system testing, and acceptance testing.

6. Maintenance: Once the software is deployed, it may require ongoing

maintenance and bug fixes. where any issues or bugs reported by users are
addressed, and updates or enhancements are made as needed.
The waterfall model is characterized by its linear and sequential nature, with each phase
dependent on the completion of the previous one. This model assumes that all requirements
can be defined upfront and that changes in requirements are minimal or can be handled
through change management procedures. It can work well for projects with well-defined and
stable requirements, but it may be less suitable for projects that require flexibility and
adaptability to changing circumstances.
 ADVANTAGES OF THE WATERFALL MODEL

ADVANTAGES OF THE CLASSICAL WATERFALL MODEL INCLUDE A CLEAR STRUCTURE, WELL-

DEFINED REQUIREMENTS, AND A SYSTEMATIC APPROACH. IT IS EASY TO UNDERSTAND AND
MANAGE, AND IT WORKS WELL FOR SMALL PROJECTS WITH FIXED REQUIREMENTS
1. Simple to understand and use
2. Each phase is independent of other phases, and is processed and completed separately
3. Suitable for smaller projects, and for projects where the requirements are clearly
outlined.
• Used when requirements are well understood in the beginning
• Also called classic life cycle
• A systematic, sequential approach to Software development
• Begins with customer specification of Requirements and progresses through planning,

This Model suggests a systematic, sequential approach to SW development that begins at the
system level and progresses through analysis, design, code and testing
 PROBLEMS IN WATERFALLMODEL
• Real projects not often follow the sequential flow since they are always iterative
• The model requires requirements to be explicitly spelled out in the beginning,
which is often difficult
• A working model is not available until late in the project time plan

Strengths
• Easy to understand, easy to use
• Provides structure to inexperienced staff
• Milestones are well understood
• Sets requirements stability
• Good for management control (plan, staff, track)
• Works well when quality is more important than cost or schedule

•
 Waterfall Drawbacks

• All projects cannot follow linear process

• All requirements must be known upfront
• Few business systems have stable requirements.
• The customer must have patience. A working version of the program will not be available
until late in the project time-span
• Leads to ‘blocking states’
• Inappropriate to changes

When to use the Waterfall Model

• Requirements are very well known
• Product definition is stable
• Technology is understood
• New version of an existing product
• Porting an existing product to a new platform.
 ITERATIVE WATERFALL MODEL
The iterative model is a software development process that is based on a cyclic approach,
which involves repeating a series of stages until a satisfactory outcome is achieved. This
approach is often used in situations where requirements are not well defined or when there is
a high level of uncertainty The Iterative Waterfall Model is a software development approach
that combines the sequential steps of the traditional Waterfall Model with the flexibility of
iterative design. It allows for improvements and changes to be made at each stage of the
development process, instead of waiting until the end of the project. In an iterative model,
the project is divided into iterations, and each iteration involves the following stages:
1. Planning: In this stage, the objectives of the iteration are defined, and the tasks and
resources required are identified.
2. Analysis: In this stage, the requirements are elicited and analyzed to identify any
potential problems or inconsistencies.
3. Design: In this stage, the system architecture, design, and data modeling are developed.
4. Development: In this stage, the actual coding takes place, and the software is developed
according to the design specifications.
5. Testing: In this stage, the software is tested to ensure that it meets the requirements and
specifications.

Once an iteration is completed, the results are reviewed, and the next iteration is planned and
executed. This cycle is repeated until the software meets the desired level of quality and
functionality. The iterative model is often used in agile software development
methodologies, such as Scrum and Kanban, where flexibility and responsiveness to
change are essential.
The advantage of this model is that there is a working model of the system at a very early
stage of development which makes it easier to find functional or design flaws. Finding
issues at an early stage of development enables to take corrective measures in a limited
budget.
The disadvantage with this SDLC model is that it is applicable only to large and bulky
software development projects. This is because it is hard to break a small software
system into further small serviceable increments/modules
 Incremental SDLC Model
• Incremental models are software development models that build upon previous
versions of the product or application. These models involve dividing the
development process into smaller parts or increments that are completed and
delivered in stages. With each increment, the product becomes more and more
complete, with additional functionality and improved features.
• Incremental models are a popular choice for software development because they
allow developers to test and review each increment as it is completed, providing an
opportunity to make necessary changes and improvements throughout the
development cycle. This approach helps to reduce overall risk and enables teams to
be more flexible and adaptable to changing requirements or demands.

• Some common incremental models include the spiral model, iterative and
incremental development (IID), and agile development. These models vary in their
specific methods and processes, but all focus on delivering an improved product in
short, incremental phases.
 When to use the Incremental Model

• When staffing is not available by deadline

• Most of the requirements are known up-front but are expected to evolve
over time
• When the software can be broken into increments and each increment
represent a solution
• A need to get basic functionality to the market early
• On projects which have lengthy development schedules
• On a project with new technology
 Incremental Model Weaknesses
• Requires good planning and design
• Requires early definition of a complete and fully functional system to
allow for the definition of increments
• Well-defined module interfaces are required (some will be developed
long before others)
• Total cost of the complete system is not lower
 PROTOTYPING MODEL
• The prototyping model is a software development model that focuses on
creating a working prototype of the software before the final product is
developed. The model involves creating a basic version of the software,
testing it, and then refining it until it meets the requirements and
expectations of the end-users
• A prototype is a partially developed product that enables customers and
developers to examine some aspects of the proposed system and decide if
it is suitable or appropriate for the finished product
•
– Start with what is known about requirements.
– Do a quick design.
– Build the prototype by focusing on what will be seen by the user.
– Use the prototype to show the user and help refining requirements
The prototyping model can be broken down into the following steps
PROTOTYPING MODEL
1. Requirements gathering - Identifying the needs of the end-users and documenting
the requirements.
2. Designing the prototype - Creating a basic design of the software based on the
identified requirements.
3. Building the prototype - Implementing the design and creating the working
prototype.
4. Testing the prototype - Checking that the prototype meets the requirements, and
fixing any errors or issues identified.
5. Refining the prototype - Making adjustments based on feedback from users, and
refining the prototype until it’s ready for the final product.

Once the prototype has been tested and refined, it can be implemented and further
developed into the final product. The prototyping model is useful for projects where the
requirements are not well-defined, and where the end-users’ feedback is critical to the
success of the final product. It helps in minimizing the risks of building a product that
end-user will not like or find useful.
 Drawbacks of Prototyping Model

• Customer sees what appears to be a working version of the software and

presumes that it is the final thing.
• The developer often makes implementation compromises in order to get a
prototype working quickly
Only one advantage is actual software is engineered with an eye
toward quality
 RAD MODEL
Rapid Application Development Model
The Rad (Rapid Application Development) model is a software development
methodology that focuses on fast prototyping and iterative development. It
is designed to deliver quick and incremental results, making it ideal for
projects with specific time constraints or evolving requirements

• An incremental process model that emphasizes short development cycle

• “High-speed” adaptation of the waterfall model.
• RAD approach also maps into the generic framework activities

• The Rad model follows an iterative and cyclical process, consisting of four
main phases:
1. Requirements Planning: In this phase, the project requirements are gathered, analyzed, and
prioritized. The key stakeholders collaborate to define the scope and objectives of the
project.
2. User Design: This phase involves creating prototypes or mock-ups of the system. The
prototypes are reviewed and refined by the stakeholders to ensure that the system meets
their needs and requirements.
3. Construction: Once the prototypes are approved, the development team starts building the
actual system. It involves coding, integration of modules, and unit testing. The focus is on
delivering functionality incrementally and rapidly.
4. Cutover: In this final phase, the system is tested thoroughly for defects, and any remaining
issues are resolved. The system is then deployed, and the users are trained to operate it.
Feedback from the users is collected and incorporated in future iterations.
The Rad model emphasizes collaboration and frequent communication between the
development team and the stakeholders. It encourages active involvement of users
throughout the development process, resulting in a system that closely aligns with their
requirements.
Advantages of using the Rad model include faster development time, increased user
involvement, and flexibility to adapt to changing requirements. However, it may not be
suitable for complex projects with a high level of dependencies or projects where the
requirements are not well-defined.
Overall, the Rad model offers a structured approach for rapid software development, enabling
organizations to quickly deliver working systems while ensuring stakeholder satisfaction.
 Drawbacks of RAD

• For large projects, RAD requires sufficient human resources to create the
right number of RAD teams.
• If developers & customers are not committed to rapid-fire activities, RAD
projects will fail.
• If the system cannot be properly modularized, building the components
will be problematic
• If high-performance is an issue, RAD may not work.
• RAD may be inappropriate when technical risks are high
 When to use RAD

• Reasonably well-known requirements

• User involved throughout the life cycle
• Project can be time-boxed
• Functionality delivered in increments
• High performance not required
• Low technical risks
• System can be modularized
 SPIRAL MODEL

The spiral model is a software development model that consists of a series of iterative cycles.
It is a combination of the iterative and the incremental models, in which each cycle of the
spiral consists of a series of phases, such as planning, risk analysis, design,
implementation, testing, and evaluation.
The spiral model is especially useful for software development projects that are complex and
have a high degree of risk, as it provides a structured approach for managing risk and
ensuring that the project is delivered on time and within budget.
The spiral model is characterized by its flexibility and adaptability, as it can be tailored to fit
the needs of different projects and organizations. It also emphasizes the importance of
collaboration and communication among team members throughout the development
process.

• It couples the iterative nature of prototyping with the controlled and systematic aspects of
the waterfall model Process
• Adapted to complete life cycle
• Process is represented as a spiral rather than as a sequence of activities with backtracking.
• Each loop in the spiral represents a phase in the process.
• No fixed phases such as specification or design - loops in the spiral are chosen depending
on what is required.
SPIRAL MODEL
 Spiral Model Strengths

• Focuses attention on reuse options.

• Focuses attention on early error elimination.
• Puts quality objectives up front.
• Integrates development and maintenance.
• Provides a framework for hardware/software Development.
 Drawbacks of the Spiral Model

• It may be difficult to convince customers that the evolutionary approach is

controllable.
• It demands risk assessment expertise and relies on this expertise for
success.
• If a major risk is uncovered and managed, problems will occur.
 When to use Spiral Model

• When creation of a prototype is appropriate

• When costs and risk evaluation is important
• For medium to high-risk projects
• Long-term project commitment unwise because of potential changes to
economic priorities
• Users are unsure of their needs
• Requirements are complex
• New product line
• Significant changes are expected