Software Development Life Cycle
Software Development Life Cycle
Career prospects
SDLC
● SDLC is Software Development
Life Cycle.
● Describes how to develop,
design and maintain a software.
● SDLC contains methods to
change existing systems.
● Also, can be used for creating
new systems.
● SDLC helps to improve the
quality of software project.
Video
Requirements Analysis
Stakeholders
Non-
Functional
Functional
Requirements
Requirements
Logical Physical
Design Design
Design Phase
● The software development process starts moving from what to how of
the software.
● Logical Design
○ An abstract design of the project
○ Finding the type of information needed
○ The process involves arranging data into a series of logical relationships called
entities and attributes
● Physical Design
○ Contains the physical implementation details
○ Deciding the programming, hardware and software details
Implementation Phase
Planning and
Acquire hardware Acquire software
announcing the
resources resources
implementation
Educate Prepare
Prepare physical
participants and implementation
facilities
users schedule
Testing Phase
● Verifies that the system works and meets all of the business
requirements defined in the analysis phase
● Two primary testing activities:
○ Write the test conditions
■ Test conditions - the detailed steps the system must perform along with the
expected results of each step
○ Perform the testing of the system
■ Unit testing
■ System testing
■ Integration testing
■ User acceptance testing (UAT)
Maintenance Phase
● Monitor and support the new system to ensure it continues to meet the
business goals.
● Primary activities:
○ Help desk - a group of people who responds to knowledge workers’ questions
○ Auditing the System - Including a post implementation review of the system
○ Maintaining the system
○ Re-engineering proposals
In Class Activity 1
● What is the appropriate pairing
of items in the two columns
listing various activities
encountered in a software life
cycle in the next slide?
In Class Activity 1
P. Requirements Capture 1.Module Development and Integration
Q. Design 2.Domain Analysis
R. Implementation 3.Structural and Behavioral Modeling
S. Maintenance 4.Performance Tuning
A) P-3, Q-2, R-4, S-1
B) P-2, Q-3, R-1, S-4
C) P-3, Q-2, R-1, S-4
D) P-2, Q-3, R-4, S-1
In Class Activity 1
Answer: (B)
Prototype
Evolutionary Rapid Model
Model Application
Development
Classical Waterfall Model
Feasibility Study
Req. Analysis
Development
Phases Design
Coding
Testing
Maintenance
(https://www.youtube.com/watch?v=ic52qU7pLoQ)
Activities during Feasibility Study
● Determine whether developing the product is
○ financially worthwhile
○ technically feasible
● Roughly understand what the customer wants
Relative Effort
● Work out an overall understanding of the problem.
● Formulate different solution strategies.
● Examine alternate solution strategies in terms of:
○ resources required,
○ cost of development, and
○ development time.
Requirements Analysis and Specification
● To understand the exact
requirements of the customer and
document them properly in form of
Software Requirement Specification
document.
● Consists of two distinct activities:
○ requirements gathering and analysis
○ requirements specification
Requirements Gathering
● Gathering relevant data:
○ usually collected from the end-users through interviews and discussions.
○ For example, for a business accounting software: interview all the accountants of the
organization to find out their requirements.
● The data you initially collect from the users:
○ would usually contain several contradictions and ambiguities.
○ each user typically has only a partial and incomplete view of the system.
Requirements Analysis
● Ambiguities and contradictions:
○ must be identified
○ resolved by discussions with the customers
● Next, requirements are organized into a Software Requirements Specification
(SRS) document.
● Engineers doing requirements analysis and specification are designated as
analysts.
Design
● Identify all the functions to be performed.
● Identify data flow among the functions.
● Decompose each function recursively into sub-functions.
● Identify data flow among the sub-functions as well.
● Identify the design required:
○ High-level design:
■ decompose the system into modules,
■ represent invocation relationships among the modules.
○ Detailed design:
■ different modules designed in greater detail:
■ data structures and algorithms for each module are designed.
Implementation
● Purpose of implementation phase is to translate software design into source
code.
● During the implementation phase:
○ each module of the design is coded,
○ each module is tested independently as a stand alone unit, and debugged
( Unit Testing).
○ each module is documented.
Integration and System Testing
● Different modules are integrated in a planned manner:
○ modules are almost never integrated in one shot.
○ Normally integration is carried out through a number of steps.
○ During each integration step, the partially integrated system is tested.
● After all the modules have been successfully integrated and tested: system
testing is carried out.
○ System testing ensure that the developed system functions according to its requirements
as specified in the SRS document.
Maintenance
● Corrective maintenance:
○ Correct errors which were not discovered during the product development phases.
● Perfective maintenance:
○ Improve implementation of the system
○ enhance functionalities of the system.
● Adaptive maintenance:
○ Port software to a new environment,
○ e.g. to a new computer or to a new operating system.
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.
● Applications: Waterfall model was used to develop enterprise applications like
○ Customer Relationship Management (CRM) systems,
○ Human Resource Management Systems (HRMS),
○ Supply Chain Management Systems, Inventory Management Systems,
○ Point of Sales (POS) systems for Retail chains etc.
Example
● Take the example of automobile building.
● We need to make a car as specified by the client company.
Example
● So steps will be followed as:
○ Requirement Analysis: To analyse the type of car client company needs.
○ All specifications regarding the car size, its color, its functionalities are locked in this
phase.
○ Design: The company creates a design based on the type of requirements specified by the
user.
○ Implementation: The actual making of car parts and assembling is done in this process.
○ Testing: The car is tested by us and by the customer as well.
Example
● Let’s say in middle of implementation phase while the car engine is being
made, the client comes,
I want to some changes (in
terms of bug removal) in I am sorry Sir. But changes
the car design. And I want in design can not be
changes in the size and incorporated at this stage.
structure of the car.
Iterative Waterfall Model
Iterative Waterfall Model
● Classical waterfall model is idealistic and assumes that no defect is introduced
during any development activity.
● In practice, defects do get introduced in almost every phase of the life cycle.
● For example, a design defect might go unnoticed till the coding or testing
phase. Therefore we need feedback paths in the classical waterfall model.
Example
● Let’s say in middle of implementation phase while the car engine is being
made, the client comes,
I want to some changes in Sure Sir, Let’s see what
the car design. And I want changes can be
changes in the size and incorporated in the design.
structure of the car.
Verification Validation
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 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
Prototyping Model
Prototyping Model
● A prototype is a toy implementation of a system is built before actual
development with :
○ limited functional capabilities,
○ low reliability,
○ inefficient performance.
● Start with approximate requirements.
● Carry out a quick design.
Reasons for developing a prototype
● Illustrate to the customer:
○ input data formats, messages, reports, or interactive dialogs.
● Examine technical issues associated with product development:
○ Major design decisions depend on issues like:
■ response time of a hardware controller,
■ efficiency of a sorting algorithm, etc.
● It is impossible to ``get it right'' the first time.
○ we must plan to throw away the first product ,if we want to develop a good product.
Prototyping Model
● Prototype model is built using several short-cuts that might involve using
inefficient, inaccurate, or dummy functions.
● For ex: A function may use a table look-up rather than performing the actual
computations.
○ The developed prototype is submitted to the customer for his the user feedback,
requirements are refined.
○ The actual system is developed using the classical waterfall approach.
When to use 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
Example
● Let’s say a client asked you to create a website for his business and specified
the requirements.
But this is not how I want it
toIbe looking.
need
I alsotoneed The
change the the
to change
Sir, thisSir,
Sure is how your
We will requirements
header, have
tochanged
the payment
main section include
website is going
incorporate all to be
your slightly
moredue
gateway toimages.
and
new some
the navigation
Also
looking
changes and create a new internal
bar changes
change
needsthe footer.
more I don’t
columns.
prototype.
like this one.