Software Development

Life Cycle (SDLC)

“You’ve got to be very careful if you don’t
know where you’re going, because you might
not get there.”
1. Requirements phase – involves establishing
a high-level plan of the intended project and
determining project goals
2. Analysis phase – involves analyzing end-
user business requirements and refining
project goals into defined functions and
operations of the intended system
• Business requirement – detailed set of business
requests that the system must meet in order to make the
business successful
3. Design phase – involves describing the desired
features and operations of the system including
screen layouts, business rules, process diagrams,
pseudo code, and other documentation

3. Development phase – involves taking all of the

detailed design documents from the design phase
and transforming them into the actual system
5. Testing phase – involves bringing all the project
pieces together into a special testing environment
to test for errors, bugs, and interoperability and
verify that the system meets all of the business requirements
defined in the analysis phase

6. Implementation phase – involves placing the

system into production so users can begin to
perform actual business operations with the system
Waterfall Model
• Requirements – defines
needed information, function,
behavior, performance and
interfaces.
• Design – data structures,
software architecture, interface
representations, algorithmic
details.
• Implementation – source
code, database, user
documentation, testing.
 Waterfall Strengths
• Easy to understand, easy to use
• Sets requirements stability
• Works well when quality is more important than
cost or schedule
• Easy to explain to the user
• Stages and activities are well defined
• Verification at each stage ensures early
detection of errors / misunderstanding
 Waterfall Deficiencies
• All requirements must be known upfront
• Little opportunity for customer to preview the
system (until it may be too late)
• Never backward (Traditional)
• Difficulty responding 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.
Incremental SDLC Model
• Construct a partial
implementation of a total
system
• Then slowly add increased
functionality
• The incremental model
prioritizes requirements of the
system and then implements
them in groups.
• Each subsequent release of
the system adds function to
the previous release, until all
designed functionality has
been implemented.
 Incremental Model Strengths
• Incremental model includes use of the software
by user to for changes. 
• Each release delivers an operational product
• Customer can respond to each build
• Testing is easy
• Lowers initial delivery cost
• Initial product delivery is faster
• Customers get important functionality early
• Risk of changing requirements is reduced
Incremental Model Weaknesses
• Requires good planning and design

• Well-defined module interfaces are

required (some will be developed long
before others)
• Total cost of the complete system is not
lower
When to use the Incremental Model
• Risk, funding, schedule, program complexity, or
need for early realization of benefits.
• Most of the requirements are known up-front but
are expected to evolve over time
• A need to get basic functionality to the market
early
• On projects which have lengthy development
schedules
• On a project with new technology
Rapid Application Model (RAD)
• Developed by James martin in 1991.
• Requirements planning phase (a workshop
utilizing structured discussion of business
problems).
• User description phase – automated tools capture
information from users.
• Construction phase – productivity tools, such as
code generators, screen generators, etc. inside a
time-box. (“Do until done”).
• Cutover phase -- installation of the system, user
acceptance testing and user training
 RAD Strengths
• Reduced cycle time and improved productivity
with fewer people means lower costs
• 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 .
• Uses modeling concepts to capture information
about business, data, and processes.
 RAD Weaknesses
• Accelerated development process must give
quick responses to the user
• Risk of never achieving closure
• Hard to use with legacy systems
• 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 SDLC Model
• Adds risk analysis,
and 4gl RAD
prototyping to the
waterfall model
• Each cycle involves
the same sequence of
steps as the waterfall
process model
 Spiral Model Strengths
• Provides early indication of insurmountable
risks, without much cost
• Users see the system early because of rapid
prototyping tools
• Critical high-risk functions are developed first
• The design does not have to be perfect
• Users can be closely tied to all lifecycle steps
• Early and frequent feedback from users
• Cumulative costs assessed frequently
 Spiral Model Weaknesses
• Time spent for evaluating risks too large for small or low-
risk projects
• Time spent planning, resetting objectives, doing risk
analysis and prototyping may be excessive
• The model is complex
• Risk assessment expertise is required
• Applied differently for each application.
• May be hard to define objective, verifiable milestones
that indicate readiness to proceed through the next
iteration
 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 (research and
exploration)
 Agile SDLC’s
• Speed up or bypass one or more life cycle
phases
• Usually less formal and reduced scope
• Used for time-critical applications
• Used in organizations that employ
disciplined methods
THANK YOU