Software Development Life Cycle (SDLC)

DR. SANGEETA ARORA

(HOD,P.G DEPT OF COMPUTER SCIENCE & IT)

​

​

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 Planning – allocate resources

​

• Product Requirements and Specification Analysis – complete specification of the software system

​

• Architecture or High-Level Design – defines how software functions fulfill the design

​

• Detailed Design – develop algorithms for each architectural component

​

​

• Production, operation and maintenance – provide for enhancement and corrections
• System and acceptance testing – check the entire software system in its environment

​

​

• Integration and Testing – check that modules interconnect correctly

​

• Unit testing – check that each module acts as expected

​

• 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)

​

THANK YOU