Software Development

Life Cycle (SDLC)

 SDLC Model
A framework that describes the activities
performed at each stage of a software
development project.
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
• 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 Deficiencies
• All requirements must be known upfront
• Deliverables created for each phase are
considered frozen – inhibits flexibility
• Can give a false impression of progress
• Does not reflect problem-solving nature of
software development – iterations of phases
• Integration is one big bang at the end
• Little opportunity for customer to preview the
system (until it may be too late)
 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.
V-Shaped SDLC Model
• A variant of the Waterfall
that emphasizes the
verification and validation
of the product.
• Testing of the product is
planned in parallel with a
corresponding phase of
development
 V-Shaped Steps
• Project and Requirements • Production, operation and
Planning – allocate resources maintenance – provide for
enhancement and corrections
• Product Requirements and • System and acceptance testing –
Specification Analysis – complete check the entire software system
specification of the software in its environment
system

• Architecture or High-Level Design • Integration and Testing – check

– defines how software functions that modules interconnect
fulfill the design correctly

• Detailed Design – develop • Unit testing – check that each

algorithms for each architectural module acts as expected
component
• Coding – transform algorithms
into software
 V-Shaped Strengths
• Emphasize planning for verification and
validation of the product in early stages of
product development
• Each deliverable must be testable
• Project management can track progress
by milestones
• Easy to use
 V-Shaped Weaknesses
• Does not easily handle concurrent events
• Does not handle iterations or phases
• Does not easily handle dynamic changes
in requirements
• Does not contain risk analysis activities
 When to use the V-Shaped Model
• Excellent choice for systems requiring high
reliability – hospital patient control
applications
• All requirements are known up-front
• When it can be modified to handle
changing requirements beyond analysis
phase
• Solution and technology are known
Structured Evolutionary Prototyping
Model
• Developers build a prototype during the
requirements phase
• Prototype is evaluated by end users
• Users give corrective feedback
• Developers further refine the prototype
• When the user is satisfied, the prototype
code is brought up to the standards
needed for a final product.
Structured Evolutionary Prototyping
Steps
• A preliminary project plan is developed
• An partial high-level paper model is created
• The model is source for a partial requirements
specification
• A prototype is built with basic and critical attributes
• The designer builds
– the database
– user interface
– algorithmic functions
• The designer demonstrates the prototype, the user
evaluates for problems and suggests improvements.
• This loop continues until the user is satisfied
Structured Evolutionary Prototyping
Strengths
• Customers can “see” the system requirements
as they are being gathered
• Developers learn from customers
• A more accurate end product
• Unexpected requirements accommodated
• Allows for flexible design and development
• Steady, visible signs of progress produced
• Interaction with the prototype stimulates
awareness of additional needed functionality
Structured Evolutionary Prototyping
Weaknesses
• Tendency to abandon structured program
development for “code-and-fix” development
• Bad reputation for “quick-and-dirty” methods
• Overall maintainability may be overlooked
• The customer may want the prototype delivered.
• Process may continue forever (scope creep)
 When to use
Structured Evolutionary Prototyping
• Requirements are unstable or have to be
clarified
• As the requirements clarification stage of a
waterfall model
• Develop user interfaces
• Short-lived demonstrations
• New, original development
• With the analysis and design portions of object-
oriented development.
Rapid Application Model (RAD)
• 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
(WYSIWYG).
• 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
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
• Develop high-risk or major functions first
• Each release delivers an operational product
• Customer can respond to each build
• Uses “divide and conquer” breakdown of tasks
• 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
• 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
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
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 Quadrant
Determine objectives, alternatives and constraints

• Objectives: functionality, performance,

hardware/software interface, critical success factors, etc.
• Alternatives: build, reuse, buy, sub-contract, etc.
• Constraints: cost, schedule, interface, etc.
 Spiral Quadrant
Evaluate alternatives, identify and resolve risks

• Study alternatives relative to objectives and constraints

• Identify risks (lack of experience, new technology, tight
schedules, poor process, etc.
• Resolve risks (evaluate if money could be lost by
continuing system development
 Spiral Quadrant
Develop next-level product
• Typical activites:
– Create a design
– Review design
– Develop code
– Inspect code
– Test product
 Spiral Quadrant
Plan next phase
• Typical activities
– Develop project plan
– Develop configuration management plan
– Develop a test plan
– Develop an installation plan
 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
• Spiral may continue indefinitely
• Developers must be reassigned during non-development
phase activities
• 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)