Unit 9 –

Software Development Life

Cycle (SDLC)
Instructor: Maryam Shahid
TMUC Lahore
Lecture Session 1
Software Development Lifecycle
Models
“You’ve got to be very careful if you
don’t know where you’re going,
because you might not get there.”

Yogi Berra
Learning Outcomes
By the end of this unit students will be able to:

• Describe different software development lifecycles.

LO1

• Explain the importance of a feasibility study.

LO2

• Undertake a software development lifecycle.

LO3

• Discuss the suitability of software behavioural design

LO4 techniques.
LO1 – Essential Content
• Software development lifecycles:
▫ Lifecycle models: understanding and use of predictive
(Waterfall, Prototyping, RAD) and adaptive (Spiral, Agile,
DSDM) software development models.
▫ Lifecycle stage and connectivity: feasibility study,
analysis, design, implementation, testing, review or
analysis, design, implementation, maintenance, planning;
requirements traceability.
▫ Test and integration: building test environments;
developing test harnesses; black box/white box testing;
incremental testing; acceptance test and integration
approaches; changeover strategies, trials and Go-Live
prerequisites.
Background
• To understand and build computerized systems in
an effective way
• requires certain skills and capabilities to
understand and follow a systematic procedure
towards making of any information system.
• For this, experts have devised various
methodologies.
• For anyone who is a part of IT industry, having
basic understanding of the development process is
essential.
 Software Development Life Cycle
• SDLC is a process used by the software industry to
▫ design,
▫ develop and
▫ test software
• SDLC aims to produce a high-quality software that
▫ meets or exceeds customer expectations,
▫ reaches completion within
times and cost estimates
Software Development Life Cycle
• also called as Software Development Process
• SDLC is a well defined, structured sequence of
stages to develop the intended software product.
• It consists of a detailed plan describing how to
▫ develop,
▫ maintain,
▫ replace and
▫ alter or enhance specific software
• The life cycle defines a methodology for
improving the quality of software and the overall
development process.
Phases of a Typical SDLC
Stage 1:
Planning & Requirement Analysis
• Performed by the senior members of the team
• Inputs from the customer, stakeholders, market
surveys and domain experts in the industry.
• Then plan the basic project approach and
conduct product feasibility study(economical,
operational and technical areas).
• Quality assurance requirements and
identification of the risks
Stage 2:
Defining Requirements
• Once the requirement analysis is done; the next
step is to clearly define and document the
product requirements and get them approved
from the customer or the market analysts.
• This is done through an SRS (Software
Requirement Specification) document
which consists of all the product requirements to
be designed and developed during the project
life cycle.
Requirements/Analysis
Stage 3:
Designing the Product Architecture
• Based on the requirements specified in SRS,
usually more than one design approach for the
product architecture is proposed and
documented in a DDS - Design Document
Specification.
• DDS is reviewed by all the important
stakeholders and based on various parameters
▫ risk assessment,
▫ product robustness,
▫ design modularity,
▫ budget and time constraints,
the best design approach is selected for the product.
Stage 3:
Designing the Product Architecture…
• A design approach clearly defines
▫ all the architectural modules of the product along
with
 its communication and
 data flow representation
with the external and third party modules (if any).
• The internal design of all the modules of the
proposed architecture should be clearly defined
with the minutest of the details in DDS.
Design
Stage 4:
Building or Developing the Product
• Actual development starts and the product is built.
• Programming code is generated as per DDS(Each
step of design is created using appropriate technical
capability)
• If the design is performed in a detailed/organized
manner, code generation can be accomplished
without much hassle
• The programming language is chosen with respect
to the type of software being developed
• Developers must follow the coding guidelines
defined by their organization
Stage 5:
Testing the Product
• Product defects are
▫ reported,
▫ tracked,
▫ fixed and
▫ retested,
until the product reaches the quality standards
defined in the SRS.
• Bug Reports, issue report, problem report
Stage 6: Deployment in the Market and
Maintenance
• Released formally in the appropriate market
• Sometimes product deployment happens in stages
as per the business strategy of that organization. The
product may first be released in a limited segment
and tested in the real business environment (UAT-
User acceptance testing).
• Then based on the feedback, the product may be
released as it is or with suggested enhancements in
the targeting market segment. After the product is
released in the market, its maintenance is done for
the existing customer base.
Life Cycle Models
• There are various SDLC models defined and
designed which are followed during the software
development process.
• These models are also referred as Software
Development Process Models
• Each process model follows a Series of steps unique
to its type to ensure success in the process of
software development
• Or it is a framework that describes the activities
performed at each stage of a software development
project.
Why SDLC Models?
Benefits of Choosing Appropriate SDLC
Types of Project Life Cycles
• Predictive (also known as fully plan-driven)
• Iterative and Incremental
• Adaptive (also known as change-driven or agile)
SDLC Models - Predictive
• Predictive SDLC is an approach that presumes that all
the planning for the project can be outlined in advance
and that the new information system can be produced
according to the plan
• Predictive SDLC lays down a linear, specific software
development plan that is structured around some pre-
defined results and within a specific timeline.
• Predictive teams usually work with detailed planning and
have a complete forecast of the exact tasks and features to
be delivered during the product life cycle.
• Predictive methods entirely depend on the requirement
analysis and planning done in the beginning of cycle.
SDLC Models – Predictive…
• Three major constraints of the project,
▫ the scope,
▫ time and
▫ cost,
are determined ahead of time not just at a high level, but
in detail
• The project is split up into phases(sequential or
overlapping).
• Now the planning can be done for the entire project
at a detailed level from the beginning of the project
SDLC Models – Iterative and
Incremental
• Like predictive, the project is split up into phases
which can be either sequential or overlapping.
• However, the scope is not determined ahead of
time at a detailed level, but only for the first
iteration or phase of the project.
• Once that phase is completed, the detailed scope
of the next phase is worked out, and so on.
SDLC Models - Adaptive
• Adaptive Software Development replaces the
traditional waterfall cycle with a repeating series
of speculate, collaborate, and learn cycles.
• Focuses on the rapid creation and evolution of
software systems
• Adaptive SDLC presumes that project require to
be more bendable and acclimatize to altering
needs as the project carries on (Warner, 2005)
SDLC Models – Adaptive…
• Like predictive, the project is split up into phases or iterations
which can be sequential or overlapping.
• However, because adaptive life cycles are used in applications
areas where there is a rapid change, sometimes the processes
within the iterations can even be going on in parallel.
• Like the iterative and incremental life cycle, the detailed scope is
only determined ahead of a time for the current iteration or phase
• The phases/iterations are more rapid than in the
iterative/incremental life cycle, usually with a duration of 2 or 4
weeks.
• During the iteration, the scope is decomposed into a set of
requirements (deliverables) and the work to be done to meet
those requirements is prioritized.
• At the end of the iteration, the work on the product is reviewed by
the customer, and the feedback from the customer is used to set
the detailed scope of the next iteration.
Waterfall Model
• The Waterfall Model was the first Process Model
to be introduced.
• It is also referred to as a linear-sequential life
cycle model. It is very simple to understand
and use.
• In a waterfall model, each phase must be
completed before the next phase can begin and
there is no overlapping in the phases.
• This means that any phase in the development
process begins only if the previous phase is
complete.
Waterfall Model
Waterfall Phases
• Requirement Gathering and Analysis − All
possible requirements of the system to be developed
are captured in this phase and documented in a
requirement specification document.

• System Design − The requirement specifications

from first phase are studied in this phase and the
system design is prepared. This system design helps
in specifying hardware and system requirements
and helps in defining the overall system
architecture.
Waterfall Phases (Cont’d)
• Implementation − With inputs from the system
design, the system is first developed in small
programs called units, which are integrated in the
next phase. Each unit is developed and tested for its
functionality, which is referred to as Unit Testing.

• Integration and Testing − All the units

developed in the implementation phase are
integrated into a system after testing of each unit.
Post integration the entire system is tested for any
faults and failures.
Waterfall Phases (Cont’d)
• Deployment of system − Once the functional and
non-functional testing is done; the product is
deployed in the customer environment or released
into the market.

• Maintenance − There are some issues which come

up in the client environment. To fix those issues,
patches are released. Also to enhance the product
some better versions are released. Maintenance is
done to deliver these changes in the customer
environment.
Waterfall Strengths
• 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
• A schedule can be set with deadlines for each stage of
development
• Easy to manage due to the rigidity of the model. Each
phase has specific deliverables and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are
very well understood.
• Clearly defined stages.
• Process and results are well documented.
 Waterfall Deficiencies
• All requirements must be known upfront
• Deliverables created for each phase are considered frozen –
inhibits flexibility
• Does not reflect problem-solving nature of software
development – iterations of phases
• Little opportunity for customer to preview the system
• No working software is produced until late during the life cycle.
• Not a good model for complex, long and ongoing projects.
• Not suitable for the projects where requirements are at a
moderate to high risk of changing. So, risk and uncertainty is
high
• It is difficult to measure progress within stages.
• Integration is done as a "big-bang” at the very end, which
doesn't allow identifying any technological or business
bottleneck or challenges early.
When to use the Waterfall Model
• Requirements are very well documented, clear
and fixed.
• Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are
available to support the product.
• The project is short.
• New version of an existing product
Prototyping Model
• Prototype is a working model of software with some
limited functionality.
• Prototyping Model is a methodology where a prototype -
which is a premature approximated sample of the final
product, is constructed and then tested.
• The Software Prototyping refers to building software
application prototypes which displays the functionality of
the product under development, but may not actually
hold the exact logic of the original software.
• Prototyping is used to allow the users evaluate developer
proposals and try them out before implementation.
Stages of
Prototyping Model
Prototyping - Steps
1. Developing the initial Prototype
 The very basic requirements are showcased and user
interfaces are provided.
 These features may not exactly work in the same
manner internally in the actual software developed.
 While, the workarounds are used to give the same
look and feel to the customer in the prototype
developed.
Prototyping – Steps (cont’d)
2. Review of the Prototype
 The prototype developed is then presented to the
customer and the other important stakeholders in
the project.
 The feedback is collected in an organized manner
and used for further enhancements in the product
under development.
Prototyping – Steps (cont’d)
3. Revise and Enhance the Prototype
 The feedback and the review comments are
discussed during this stage and some negotiations
happen with the customer based on factors like –
time and budget constraints and technical
feasibility of the actual implementation.
 The changes accepted are again incorporated in the
new Prototype developed and the cycle repeats until
the customer expectations are met.
Prototyping - Types

▫ Throwaway/Rapid Prototyping
 Throwaway prototyping is also called as rapid or
close ended prototyping.
 This type uses very little efforts with minimum
requirement analysis to build a prototype.
 Once the actual requirements are understood, the
prototype is discarded and the actual system is
developed with a much clear understanding of user
requirements.
Prototyping – Types (cont’d)
▫ Evolutionary Prototyping
 Evolutionary prototyping also called as breadboard
prototyping, is based on building actual functional
prototypes with minimal functionality in the beginning.
 The prototype developed forms the heart of the future
prototypes on top of which the entire system is built.
 By using evolutionary prototyping, the well-understood
requirements are included in the prototype and the
requirements are added as and when they are
understood.
Prototyping – Types (cont’d)
▫ Incremental Prototyping
 Refers to building multiple functional prototypes of the
various sub-systems and then integrating all the available
prototypes to form a complete system.

▫ Extreme Prototyping
 Used in the web development domain. It consists of three
sequential phases.
 First, a basic prototype with all the existing pages is
presented in the HTML format.
 Then the data processing is simulated using a prototype
services layer.
 Finally, the services are implemented and integrated to the
final prototype.
Prototyping Model Strengths
• 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.
• It places more effort in creating the actual software
instead of concentrating on documentation.
Prototyping Model Weaknesses
• Costly w.r.t 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 the 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.
• The customer might lose interest in the product if he/she
is not satisfied with the initial prototype.
Prototyping – When to Use
• Where project requirement is not fully known or
are unstable
• Requirements are changing quickly.
• Used for developing user interfaces, and systems
with complex algorithms and interfaces.
Rapid Application Development(RAD)
Model
• Rapid application development is a software
development methodology that uses minimal
planning in favor of rapid prototyping.
• In RAD, the functional modules are developed in
parallel as prototypes and are integrated to make
the complete product for faster product delivery.
• Since there is no detailed preplanning, it makes
it easier to incorporate the changes within the
development process.
RAD Model
• Based on prototyping and iterative development
with no specific planning involved.
• The process of writing the software itself
involves the planning required for developing
the product.
• It focuses on gathering customer requirements
through
▫ workshops or focus groups,
▫ early testing of the prototypes by the customer
▫ reuse of the existing prototypes (components)
▫ continuous integration and rapid delivery.
RAD Model (cont’d)
• RAD has small teams comprising of
▫ developers,
▫ domain experts,
▫ customer representatives
▫ other IT resources
working progressively on their component or
prototype.
• The most important aspect for this model to be
successful is to make sure that the prototypes
developed are reusable.
RAD Phases
RAD Phases
▫ Business Modeling
 The business model for the product under
development is designed in terms of flow of
information and the distribution of information
between various business channels.
 A complete business analysis is performed to find
the vital information for business
 how it can be obtained,
 how and when is the information processed and
 what are the factors driving successful flow of
information.
RAD Phases (cont’d)
▫ Data Modeling
 The information gathered in the Business Modeling
phase is reviewed and analyzed to form sets of data
objects vital for the business.
 The attributes of all data sets is identified and defined.
The relation between these data objects are established
and defined in detail in relevance to the business model.
▫ Process Modeling
 The data object sets defined in the Data Modeling phase
are converted to establish the business information flow
needed to achieve specific business objectives as per the
business model.
 The process model for any changes or enhancements to
the data object sets is defined in this phase. Process
descriptions for adding, deleting, retrieving or modifying
a data object are given.
RAD Strengths
• Adaptable to changes as it incorporates short
development cycles (i.e. users see the RAD
product quickly)
• Reduced cycle time and improved productivity
• Time-box approach mitigates cost and schedule
risk
• Customer involved throughout the complete cycle
minimizes risk of not achieving customer
satisfaction and business needs
• Focus moves from documentation to code
(WYSIWYG)
• Uses modeling concepts to capture information
about business, data, and processes.
RAD Weaknesses
• Risk of never achieving closure
• Requires a system that can be modularized
• Developers and customers must be committed to
rapid-fire activities in an abbreviated time
frame.
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 combines the idea of iterative
development with the systematic, controlled
aspects of the waterfall model(sequential linear
development model) with a very high emphasis
on risk analysis.
• risk-driven software development process model
• It allows incremental releases of the product or
incremental refinement through each iteration
around the spiral.
 Spiral Phases
• Planning phase
• Risk analysis phase
• Engineering phase
• Evaluation phase.
Output driven methodology;
Each circle produces a prototype
Pictorial Representation Of SDLC Spiral Model
better than the previous one.
Activities performed in the spiral model
 Spiral Model – Steps

• There are specific activities

which are done in one
iteration (spiral) where the
output is a small prototype
of the large software. The
same activities are then
repeated for all the spirals
till the entire software is
build.
Advantages of using Spiral Model
• Larger projects or software are created and handled in
a strategic way
• Risk evaluation is proper.
• Control towards all the phases of development.
• More and more features are added in a systematic
way.
• Software is produced early.
• Has room for customer feedback and the changes are
implemented faster.
• Provides early indication of risks, without much cost
• Users see the system early because of rapid
prototyping tools; Development is fast
• Users can be closely tied to all lifecycle steps
Disadvantages of using Spiral model
• Risk analysis is important phase so requires
expert people.
• Is not beneficial for smaller projects; costly
• Spiral may go infinitely.
• Documentation is more as it has intermediate
phases.
• Model is complex
When to Use Spiral model?
• When the project is large/long-term
• For medium to high-risk projects
• Where the software needs continuous cost and risk
evaluation
• Requirements are a bit complicated and require
continuous clarification.
• Software requires significant changes.
• Where enough time frame is there to get end user
feedback.
• Where releases are required to be frequent.
• Users are unsure of their needs
• New product line
Agile Model
• Agile SDLC model is a combination of iterative
and incremental process models with focus on
process adaptability and customer satisfaction
by rapid delivery of working software product.

• Agile Methods break the product into small

incremental builds. These builds are provided in
iterations. Each iteration typically lasts from
about one to three weeks.
Agile Model…
Illustration of Agile Model
Agile Model…
• Every iteration involves cross functional teams
working simultaneously on various areas like −
▫ Planning
▫ Requirements Analysis
▫ Design
▫ Coding
▫ Unit Testing and
▫ Acceptance Testing.

• At the end of the iteration, a working product is

displayed to the customer and important
stakeholders.
Agile SDLC
• There is no detailed planning and there is clarity on
future tasks only in respect of what features need to
be developed.
• Its Feature driven development and the team
adapts to the changing product requirements
dynamically
• Product is tested very frequently, through the
release iterations, minimizing the risk of any major
failures in future.
• The Agile thought process had started early in the
software development and started becoming popular
with time due to its flexibility and adaptability.
Typical Features of Agile
• Continuous Customer Interaction is the backbone of
Agile methodology and is important to get proper
product requirements
• Demo working software is considered the best means of
communication with the customers to understand their
requirements, instead of just depending on
documentation.
• open communication with minimum documentation
• Agile teams work in close collaboration with each other
and are most often located in the same geographical
location.
• Agile Development is focused on quick responses to
change and continuous development.
Agile Model Strengths
• Is a very realistic approach to software development.
• Functionality can be developed rapidly
• Suitable for fixed or changing requirements
• Delivers early partial working solutions.
• Good model for environments that change steadily.
• Little or no planning required.
• Easy to manage.
• Gives flexibility to developers
• Usually less formal
• Have clear visibility on the project's progress
Agile Model Weaknesses
• Not suitable for handling complex dependencies
• An overall plan, an agile leader and agile PM
practice is a must without which it will not work.
• There is a very high individual dependency and
project going off the track, since there is minimum
documentation generated.
• Transfer of technology to new team members may
be quite challenging due to lack of documentation.
• Depends heavily on customer interaction; if he is not
clear, team can be driven in wrong direction
• For larger projects, it is difficult to judge efforts and
time required for the project
When to Use Agile Models?

• Whenever customer need the project very early

• When there is complex project
• When new changes are needed to be
implemented.
• Used for time-critical applications
• High quality software is needed in least possible
time duration
Dynamic Systems Development Method
(DSDM)
• It is an iterative, incremental approach that is largely based
on the RAD methodology.
• DSDM develops system dynamically; it is
▫ based on principle to start implementing a project structure.
▫ Simple
▫ Extendible
▫ But not calming to be the solution to all kind of projects.
DSDM – Agile software development
methodology

• It emphasizes continuous user/customer

involvement
• Paradigm is the 80/20 rule
– majority of the requirements can be delivered
in a relatively short amount of time.
DSDM Principles
There are 9 principles which are essential to any DSDM
implementation, ignoring one of them will break with the
frameworks philosophy and significantly increase project
risks.
1) Active user involvement (collaborate).
2) Teams must be empowered to make decisions
3) Focus on frequent delivery.
4) Product delivery must be made on time and on budget
5) Iterative and incremental development.
6) All changes during development must be reversible.
7) Requirements are base lined at high level before
project starts
8) Testing is integrated throughout the life cycle.
9) Collaborative and co-operative approach between
developers and users
DSDM Lifecycle
Phase 1: Feasibility Study

Phase 2: Business Study

• Business requirements are specified at a high
level
▫ Identifies the overall scope of the project and
results in agreed high level functional and non-
functional requirements
Phase 3:
Functional Model (Iterative Phase)
• Focus is on building the prototype iteratively and
getting it reviewed from the users to bring out the
requirements of the desired system.
• The prototype is improved through
▫ demonstration to the user,
▫ taking the feedback and
▫ incorporating the changes.
This cycle is repeated generally twice or thrice until a
part of functional model is agreed upon.
• The end product of this phase is a functional model
consisting of analysis model and some software
components containing the major functionality
Phase 4:
Design and Build (Iterative Phase)
• Ensuring that the prototypes are properly
engineered to suit their operational
environment.
• The software components designed during the
functional modeling are further refined till they
achieve a satisfactory standard.
• The product of this phase is a tested system
ready for implementation.
Phase 5:
Implementation
• The users are trained and the system is actually put
into the operational environment.
• At the end of this phase, there are four possibilities:
▫ Everything was delivered as per the user demand, so
no further development required.
▫ A new functional area was discovered, so return to
business study phase and repeat the whole process
▫ A less essential part of the project was missed out due
to time constraint and so development returns to the
functional model iteration.
▫ Some non-functional requirement was not satisfied, so
development returns to the design and build iterations
phase.
DSDM Strengths & Weaknesses
DSDM’s strengths include:
• Basic product functionality can be delivered
rapidly
• Developers have easy access to end users
• Projects are reliably completed on time
DSDM’s weaknesses include:
• Can represent a dramatic and disruptive change
in company culture
• Costly to implement
• Not ideal for small organizations
When to Use DSDM?
• Useful for the systems to be developed in short
time span
• Very useful under time constraints and
varying/evolving requirements
• If your organization prioritizes
▫ developing quickly,
▫ delivering on time and on budget
Summery
Predictive or Adaptive?
• Depends upon the nature of the project.
• If project is known and requirements are well
understood, Predictive SDLC must be followed
as it presents a stable and particular
improvement plan; prearranged in the order to
produce a predestined end result in a definite
timeframe.
• While in the case of embryonic projects that face
varying circumstances, Adaptive SDLC is
suitable
Some Basic Terminologies
• Stakeholders are typically the members of a project team,
project managers, executives, project sponsors, customers,
and users.
• Stakeholders are people who are invested in the project and
who will be affected by your project at any point along the way,
and their input can directly impact the outcome.
• Testing of functional requirements is the verification that the
software is executing actions as it should
• while nonfunctional testing helps verify that customer
expectations are being met
• Rigidity-inability to be changed or adapted
• Whenever u develop a software for a specific application is
Software Product
Some Basic Terminologies…
• Robustness-reducing variation in a product
• modularity in design is an approach that
subdivides a system into smaller parts called
modules, that can be independently created and
then used in different systems.
• Scope-the extent of the area or subject matter that
something deals with or to which it is relevant.
• Timeboxing is an approach to task
and time management that sets rigid constraints on
how long a given task or project can take to
complete. Extensions are not permitted.
References
• https://www.tutorialspoint.com/sdlc/sdlc_quick_guide.htm
• https://www.subjectcoach.com/tutorials/detail/contents/introducti
on-to-software-development-life-cycle-sdlc/chapter/prototype-
model-of-sdlc
• https://www.softwaretestinghelp.com/spiral-model-what-is-sdlc-
spiral-model/
• https://www.slideshare.net/Compare2011/software-development-
life-cycle-sdlc?next_slideshow=1
• https://www.tutorialspoint.com/sdlc/sdlc_agile_model.htm
• https://4squareviews.com/2013/02/01/5th-edition-pmbok-guide-
chapter-2-project-life-cycle-types-predictive-iterative-agile/
• https://4squareviews.com/2013/02/01/5th-edition-pmbok-guide-
chapter-2-project-life-cycle-types-predictive-iterative-agile/