Software Development

Process Models
 Software Development Life Cycle
(SDLC) models
• A software life cycle model (also termed process model) is a
pictorial and diagrammatic representation of the software
life cycle.
• A life cycle model represents all the methods required to
make a software product transit through its life cycle stages.
• It also captures the structure in which these methods are to
be undertaken.
• In other words, a life cycle model maps the various activities
performed on a software product from its beginning to
retirement.
• There are different software development life cycle models,
which are followed during the software development phase.
• These models are also called "Software Development
Process Models."
• Each process model follows a series of phase unique to its
type to ensure success in the step of software development.

3
• There are many development life cycle models that have
been developed in order to achieve different required
objectives.
• The models specify the various stages of the process and the
order in which they are carried out.
• The most used, popular and important SDLC models are
given below:
 Need of SDLC model
• The development team must determine a suitable life cycle
model for a particular plan and then observe to it.
• Without using an exact life cycle model, the development of
a software product would not be in a systematic and
disciplined manner.
• When a team is developing a software product, there must
be a clear understanding among team representative about
when and what to do.
• Otherwise, it would point to confusion and project failure.
• This problem can be defined by using an example.
• Suppose a software development issue is divided into
various parts and the parts are assigned to the team
members.
• From then on, suppose the team representative is
allowed the freedom to develop the roles assigned to
them in whatever way they like.
• It is possible that one representative might start writing
the code for his part, another might choose to prepare
the test documents first, and some other engineer might
begin with the design phase of the roles assigned to him.
• This would be one of the perfect methods for project
failure.
• A software life cycle model describes entry and exit criteria
for each phase.
• A phase can begin only if its stage-entry criteria have been
fulfilled.
• So without a software life cycle model, the entry and exit
criteria for a stage cannot be recognized.
• Without software life cycle models, it becomes hard for
software project managers to monitor the progress of the
project.
 Software Development Life Cycle
(SDLC) models
• Waterfall model
• V model
• Incremental model
• RAD model
• Agile model
• Iterative model
• Spiral model
• Prototype model
 Waterfall Model
• The waterfall model is a breakdown of project activities into
linear sequential phases, where each phase depends on the
deliverables of the previous one and corresponds to a
specialization of tasks.
• The approach is typical for certain areas of engineering
design.
• The waterfall is a universally accepted SDLC model.
• In this method, the whole process of software development
is divided into various phases.
• The waterfall model is a continuous software development
model in which development is seen as flowing steadily
downwards (like a waterfall) through the steps of
requirements analysis, design, implementation, testing
(validation), integration, and maintenance.
• Linear ordering of activities has some significant
consequences.
• First, to identify the end of a phase and the beginning of
the next, some certification techniques have to be
employed at the end of each step.
• That will ensure that the output of the stage is consistent
with its input (which is the output of the previous step),
and that the output of the stage is consistent with the
overall requirements of the system.
• Winston Royce introduced the Waterfall Model in 1970.
• This model has five phases:
• Requirements analysis and specification,
• design,
• implementation,
• unit testing, integration and system testing, and
• operation and maintenance.
• The steps always follow in this order and do not overlap.
• The developer must complete every phase before the next
phase begins.
• This model is named "Waterfall Model", because its
diagrammatic representation resembles a cascade of
waterfalls.
 Requirements analysis and specification
phase:
• The aim of this phase is to understand the exact requirements
of the customer and to document them properly.
• Both the customer and the software developer work together
so as to document all the functions, performance, and
interfacing requirement 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 (SRS) document is created which contained a
detailed description of what the system will do in the common
language.
 Design Phase

• This phase aims 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 a Software Design Document
(SDD).
 Implementation and unit testing

• During this phase, design is implemented.

• If the SDD is complete, the implementation or coding phase
proceeds smoothly, because all the information needed by
software developers is contained in the SDD.
• During testing, the code is thoroughly examined and
modified.
• Small modules are tested in isolation initially.
• After that these modules are tested by writing some
overhead code 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.
• The 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.
 When to use SDLC Waterfall Model?

• Some Circumstances where the use of the Waterfall model is

most suited are:
• When the requirements are constant and not changed
regularly.
• A project is short
• The situation is calm
• Where the tools and technology used is consistent and is
not changing
• When resources are well prepared and are available to
use.
 V Model
• The V-model represents a development process that may be
considered an extension of the waterfall model and is an
example of the more general V-model.
• Instead of moving down in a linear way, the process steps are
bent upwards after the coding phase, to form the typical V
shape.
• The V-Model demonstrates the relationships between each
phase of the development life cycle and its associated phase
of testing.
• The horizontal and vertical axes represent time or project
completeness (left-to-right) and level of abstraction
(coarsest-grain abstraction uppermost), respectively.
• In this type of SDLC model testing and the development steps
are planned in parallel.
• So, there are verification phases on the side and the validation
phase on the other side.
• V-Model joins by Coding phase.
• Verification confirms that the application provides the behavior
described in the requirements
• Validation confirms that the application satisfies the customers’
needs, which are represented in the requirements
• Requirement validation is the process of making sure that the
requirements say the right things
• Requirement verification is the process of checking that the
finished application actually satisfies the requirements
 Incremental model
• The incremental build model is a method of software
development where the model is designed, implemented
and tested incrementally (a little more is added each time)
until the product is finished.
• It involves both development and maintenance.
• The product is defined as finished when it satisfies all of its
requirements.
• Each iteration passes through the requirements, design,
coding and testing phases.
• Each subsequent release of the system adds function to the
previous release until all designed functionally has been
implemented.
• This model combines the elements of the waterfall model
with the iterative philosophy of prototyping.
• The incremental model is not a separate model.
• It is necessarily a series of waterfall cycles.
• The requirements are divided into groups at the start of the
project.
• For each group, the SDLC model is followed to develop
software.
• The SDLC process is repeated, with each release adding more
functionality until all requirements are met.
• In this method, each cycle act as the maintenance phase for
the previous software release.
• Modification to the incremental model allows development
cycles to overlap.
• After that subsequent cycle may begin before the previous
 Iterative Model
• An iterative life cycle model does not attempt to start with a
full specification of requirements by first focusing on an
initial, simplified set user features, which then progressively
gains more complexity and a broader set of features until
the targeted system is complete.
• When adopting the iterative approach, the philosophy of
incremental development will also often be used liberally
and interchangeably.
• In other words, the iterative approach begins by specifying
and implementing just part of the software, which can then
be reviewed and prioritized in order to identify further
requirements.
• This iterative process is then repeated by delivering a new
version of the software for each iteration.
• In a light-weight iterative project the code may represent the
major source of documentation of the system;
• however, in a critical iterative project a formal software
specification may also be required.
• In short, iterative development is a way of breaking down
the software development of a large application into smaller
pieces.
 RAD model
• Rapid application development was a response to plan-
driven waterfall processes, developed in the 1970s and
1980s, such as the Structured Systems Analysis and Design
Method (SSADM).
• Rapid application development (RAD) is often referred as the
adaptive software development.
• RAD is an incremental prototyping approach to software
development that end users can produce better feedback
when examining a live system, as opposed to working strictly
with documentation.
• It puts less emphasis on planning and more emphasis on an
adaptive process.
• RAD may resulted in a lower level of rejection when the
application is placed into production, but this success most
often comes at the expense of a dramatic overruns in project
costs and schedule.
• RAD approach is especially well suited for developing
software that is driven by user interface requirements.
• Thus, some GUI builders are often called rapid application
development tools.
• RAD or Rapid Application Development process is an
adoption of the waterfall model
• It targets developing software in a short period.
• The RAD model is based on the concept that a better system
can be developed in lesser time by using focus groups to
gather system requirements.
• Business Modeling
• Data Modeling
• Process Modeling
• Application Generation
• Testing and Turnover
 The various phases of RAD are as
follows:
• Business Modelling:
• The information flow among business functions is defined
by answering questions like what data drives the business
process, what data is generated, who generates it, where
does the information go, who process it and so on.
• Data Modelling:
• The data collected from business modeling is refined into
a set of data objects (entities) that are needed to support
the business.
• The attributes (character of each entity) are identified,
and the relation between these data objects (entities) is
• Process Modelling:
• The information object defined in the data modeling
phase are transformed to achieve the data flow necessary
to implement a business function.
• Processing descriptions are created for adding,
modifying, deleting, or retrieving a data object.
• Application Generation:
• Automated tools are used to facilitate construction of the
software.
• Testing & Turnover:
• Many of the programming components have already been
tested since RAD emphasis reuse.
• This reduces the overall testing time.
• But the new part must be tested, and all interfaces must
be fully exercised.
 When to use RAD Model?

• When the system should need to create the project that

modularizes in a short span time (2-3 months).
• When the requirements are well-known.
• When the technical risk is limited.
• When there's a necessity to make a system, which
modularized in 2-3 months of period.
• It should be used only if the budget allows the use of
automatic code generating tools.
 Spiral model
• The spiral model, first described by Barry Boehm in 1986, is a
risk-driven software development process model which was
introduced for dealing with the shortcomings in the
traditional waterfall model.
• A spiral model looks like a spiral with many loops.
• The exact number of loops of the spiral is unknown and can
vary from project to project.
• This model supports risk handling, and the project is
delivered in loops.
• Each loop of the spiral is called a Phase of the software
development process.
• The initial phase of the spiral model in the early stages of
Waterfall Life Cycle that is needed to develop a software
product.
• The exact number of phases needed to develop the product
can be varied by the project manager depending upon the
project risks.
• As the project manager dynamically determines the number
of phases, so the project manager has an important role to
develop a product using a spiral model.
• The spiral model is a risk-driven process model.
• This SDLC model helps the group to adopt elements of one
or more process models like a waterfall, incremental,
waterfall, etc.
• The spiral technique is a combination of rapid prototyping
and concurrency in design and development activities.
• Each cycle in the spiral begins with the identification of
objectives for that cycle, the different alternatives that are
possible for achieving the goals, and the constraints that
exist.
• This is the first quadrant of the cycle (upper-left quadrant).
• The next step in the cycle is to evaluate these different
alternatives based on the objectives and constraints.
• The focus of evaluation in this step is based on the risk
perception for the project.
• The next step is to develop strategies that solve
uncertainties and risks.
• This step may involve activities such as benchmarking,
simulation, and prototyping.
 Agile model

• Agile is an umbrella term for a set of methods and practices

based on the values and principles expressed in the Agile
Manifesto that is a way of thinking that enables teams and
businesses to innovate, quickly respond to changing
demand, while mitigating risk.
• Organizations can be agile using many of the available
frameworks available such as Scrum, Kanban, Lean, Extreme
Programming (XP) and etc.
• Agile approaches are typically used in software development
to help businesses respond to unpredictability.
• Agile can also refer to a group of software development
methodologies based on iterative development, where
requirements and solutions evolve through collaboration
between self-organizing cross-functional teams.
• The primary goal of being Agile is
• Empowering the development team the ability to create
and respond to change in order to succeed in an uncertain
and turbulent environment.
• Agile software development approach is typically operated in
rapid and small cycles.
• This results in more frequent incremental releases with each
release building on previous functionality.
• Thorough testing is done to ensure that software quality is
maintained.
• The meaning of Agile is swift or versatile.
• "Agile process model" refers to a software development
approach based on iterative development.
• Agile methods break tasks into smaller iterations, or parts do
not directly involve long term planning.
• The project scope and requirements are laid down at the
beginning of the development process.
• Plans regarding the number of iterations, the duration and
the scope of each iteration are clearly defined in advance.
• Each iteration is considered as a short time "frame" in the
Agile process model, which typically lasts from one to four
weeks.
• The division of the entire project into smaller parts helps to
minimize the project risk and to reduce the overall project
delivery time requirements.
• Each iteration involves a team working through a full
software development life cycle including planning,
requirements analysis, design, coding, and testing before a
working product is demonstrated to the client.
• Following are the phases in the Agile model are as follows:
• Requirements gathering
• Design the requirements
• Construction/ iteration
• Testing/ Quality assurance
• Deployment
• Feedback
• Requirements gathering:
• In this phase, you must define the requirements.
• You should explain business opportunities and plan the
time and effort needed to build the project.
• Based on this information, you can evaluate technical and
economic feasibility.
• Design the requirements:
• When you have identified the project, work with
stakeholders to define requirements.
• You can use the user flow diagram or the high-level UML
diagram to show the work of new features and show how
it will apply to your existing system.
• Construction/ iteration:
• When the team defines the requirements, the work
begins.
• Designers and developers start working on their project,
which aims to deploy a working product.
• The product will undergo various stages of improvement,
so it includes simple, minimal functionality.
• Testing:
• In this phase, the Quality Assurance team examines the
product's performance and looks for the bug.
• Deployment:
• In this phase, the team issues a product for the user's
work environment.
• Feedback:
• After releasing the product, the last step is feedback.
• In this, the team receives feedback about the product and
works through the feedback.
 Agile Manifesto
• The Agile Manifesto is a document that identifies
• 4 key values and 12 principles that its authors
believe software developers should use to guide their
work.
• Formally called the Manifesto for Agile Software
Development, it was produced by 17 developers during
an trip on Feb. 11-13, 2001, at The Lodge at Snowbird
ski resort in Utah.

N.B : Utah is a landlocked state in the Mountain West

subregion of the Western United States.
• The developers called themselves the Agile Alliance.
• They were seeking an alternative to the existing software
development processes that they saw as complicated,
unresponsive and too focused on documentation
requirements.
• Among the developers were Kent Beck, Arie van Bennekum,
Alistair Cockburn, Andrew Hunt and Jeff Sutherland.
• Members of the initial alliance were experienced in software
development and business entrepreneurship.
• According to agilemanisfesto.org, the online home of the
document, the developers' stated goal was not anti
methodology, but rather "to restore credibility to the word
methodology."
• Furthermore, the developers sought to find a balance
between the existing ways of development and the new
alternatives.
• They admitted to accepting modeling and documentation,
but only when it had a clear, beneficial use.
• The developers also explained that while planning is
important, it's necessary to accept that plans change and
flexibility is needed for these modifications.
• Overall, the manifesto focuses on valuing individuals and
interactions over processes and tools.
• Agile project management brings together Agile teams of
programmers, stakeholders and users to support Agile
principles.
• Team members conduct face-to-face conversations, both in
person and remotely, and they communicate regularly as
part of the primary measure of progress.
• This approach supports the key aspect of the Agile process --
developing software in increments with user input along the
way, as opposed to a final product with minimal user
interaction.
 Development of the Agile Manifesto

• The commitment to creating software incrementally, with

regular increases and stages, is what defines the Agile
approach to software development.
• The approach offers users new versions, or releases, of
software following brief periods of work, often called sprints.
• This Agile process contrasts with the traditional waterfall
approach to software development.
• With that approach, developers compile the needs and
requirements of the users and then build the software all at
once.
• The completed project is released at the end of the project
cycle.
• This is similar to the software development lifecycle, which
includes evaluating the existing software, planning the new
software requirements, designing the proposed software,
developing the new software, testing it, putting it into use and
monitoring it.
• The Agile Alliance said it was seeking an alternative to the
waterfall model's "documentation-driven, heavyweight
 The Agile Manifesto's purpose

• Followers of Agile methodologies say the 4 values of the

Agile Manifesto promote a software development process
that focuses on quality by creating products that meet
consumers' needs and expectations.
• The 12 principles are intended to create and support a work
environment that's focused on the customer and customer
satisfaction, aligns to business objectives, and responds and
pivots quickly as user needs and market forces change.
 4 values of Agile

Individuals and interactions over processes and tools.

Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a project plan.
 Types Of Agile Methodology

• There are various types of agile methodology available in the

market to suit every project’s wants.
• Although there are different agile methodologies, everything
is based on the main principles in the agile manifesto.
• Therefore, every framework or behavior that adapts these
principles is named Agile.
• The below agile methodologies list comprises of famous
types of agile methodology :
 Kanban

• Originating from the Japanese language, the translation of

the word ‘Kanban’ is “visual board or signboard” and is
connected to the concept of “just in time”!
• Initially, the Kanban concept was introduced as a lean
manufacturing system and slowly drove its way to agile
software development teams.
• This method uses visual methods for developing and
managing projects.
• Projects through Kanban are overseen with the help of the
Kanban Board, which is divided into columns to depict the
process flow of the software development.
• This helps in increasing visibility teams as the teams can see
the progress through every stage of development and
prepare for the upcoming tasks to deliver the product “just in
time”!
• This method requires thorough interaction and transparency
to enable the team members to be equipped with the right
stage of the development at any time and have a cohesive
flow of work at all times.
 Scrum

• One of the most popular agile methodology examples is the

agile scrum development methodology, which is depicted by
various cycles of development.
• Similar to Kanban, Scrum breaks down the development
phases into stages or cycles called ‘sprints’.
• The development time for each sprint is maximized and
dedicated, thereby managing only one sprint at a time.
• Scrum and agile methodologies focus on continuous
deliverables, and thus this method lets designers adjust
priorities to ensure that any incomplete or overdue sprints
get more attention.
• Scrum Team has exclusive project roles such as a scrum
master and a product owner with constant communications
on the daily scrum where the activities are harmonized to
devise the best way to implement the sprint.
 The Scrum Team - The people on the
Scrum Team
• The fundamental unit of Scrum is a small team of people, a
Scrum Team.
• The Scrum Team consists of one Scrum Master, one Product
Owner, and Developers.
• Within a Scrum Team, there are no sub-teams or hierarchies.
• It is a cohesive unit of professionals focused on one objective
at a time, the Product Goal.
• Scrum Teams are cross-functional, meaning the members
have all the skills necessary to create value each Sprint.
• They are also self-managing, meaning they internally decide
who does what, when, and how.
• The Scrum Team is small enough to remain agile and large
enough to complete significant work within a Sprint, typically
10 or fewer people.
• In general, we have found that smaller teams communicate
better and are more productive.
• If Scrum Teams become too large, they should consider
reorganizing into multiple cohesive Scrum Teams, each
focused on the same product.
• Therefore, they should share the same Product Goal, Product
• The Scrum Team is responsible for all product-related
activities from stakeholder collaboration, verification,
maintenance, operation, experimentation, research and
development, and anything else that might be required.
• They are structured and empowered by the organization to
manage their own work.
• Working in Sprints at a sustainable pace improves the Scrum
Team’s focus and consistency.
• The entire Scrum Team is accountable for creating a valuable,
useful Increment every Sprint.
 What is a Sprint?

• Sprints are the heartbeat of Scrum, where ideas are turned

into value.
• The Sprint is the Scrum event that encompasses all of the
other Scrum events.
• They are fixed length periods of work that last one month or
less to create consistency and ensure short iterations for
feedback in order to inspect and adapt both how work is
done and what is being worked on.
• If cycles are longer, then the spirit of frequent feedback
cycles can be lost.
• Longer Sprint may also get too complex and may increase
risk.
• A new Sprint starts immediately after the conclusion of the
previous Sprint.
• All the work necessary to achieve the Product Goal,
including Sprint Planning, Daily Scrums, Sprint Review, and
Sprint Retrospective, happen within Sprints.
• During the Sprint:
• No changes are made that would endanger the Sprint
Goal
• Quality does not decrease
• The Product Backlog is refined as needed
• Scope may be clarified and renegotiated with the Product
Owner as more is learned
Summarize the key differences between the software
development models you mentioned:
• Waterfall Model:
• Sequential and linear approach.
• Phases must be completed before moving to the next.
• Suitable for well-defined projects with stable requirements.
• Difficult to accommodate changes once a phase is
completed.
V Model (Validation and Verification Model):
• Extends the Waterfall Model with an emphasis on testing
and validation.
• Corresponding testing phases for each development phase.
• Ensures rigorous testing and validation but may still struggle
with adapting to changing requirements.
Incremental Model:
• Divides the project into smaller increments.
• Each increment builds upon the previous one.
• Suitable for large projects, allows for early delivery, and
flexibility in adding features.
RAD Model (Rapid Application Development):
• Emphasizes rapid prototyping and quick user feedback.
• Well-suited for projects where user involvement and
feedback are critical.
• Efficient for short development cycles but may not be
suitable for all types of projects.
Agile Model:
• Iterative and incremental approach with a focus on
collaboration and customer feedback.
• Responds well to changing requirements and customer
needs.
• Suitable for dynamic projects with evolving requirements.
The End

79