SDLC

Stage Key Question Result

1 Recognition of Need :- What is the Problem?  Statement of scope & objective
(aim)
 Preliminary Survey  Performance criteria.

 Investigation

2 Feasibility Study :- Is the problem worth New Scope

solving? New Objective
 Evaluation of existing
Cost Benefit analysis
system.
Its technical behavior and stability.
 Analysis of alternative
system.

 Cost estimates.

3 Analysis :- What must be done to Logical model of system.

solve a problem ? eg. data dictionary & data flow
 Detailed evaluation of diagram.
present system. What are the facts ?

 Data collection.
 Stage Key Question Result
4 Design :- How must the problem  Implementation
be solved ? specification / schedule.
 General specification and  Final Cost / Benefit
 Detailed specification. analysis.

5 Coding :-  Approval of system by

user programs.
 Programming languages,
----
 Platform,
 Technology
6 Testing :- How well the system  Secured, actual, formal
is Ready? system.
 Unit Testing
 Integration Testing.
 Acceptance Testing
7 Implementation & Maintenance :- What is the actual  User manual, user friendly
operation ? documentation.
 User requirements met.
 User training & file / system
conversion
 Software Process Model
“A software process model is an abstract representation of a
software process. ”

Software process models:

• The waterfall model
• Prototyping model
• RAD model
• Evolutionary development
Incremental Model
Spiral Model
• Component-based software engineering
 Waterfall Model
• The waterfall model is a classical
development process model proposed
by R. W. Royce in 1970.
• In this model, software development
proceeds through an orderly sequence
of transitions from one phase to the
next in order (like a waterfall).
• In waterfall, development of one
phase starts only when the previous
phase is complete.
• This model produces standard outputs
at the end of every phase, which is
called work products.

• This model was enhanced with a

feedback process, which is referred to
as an iterative Waterfall model.
S.No Phase Activities Performed Work Products
1 Requirement Analysis Capture all the requirements and RUD ( Requirements
ensure that the requirements are Understanding
testable or not. Document)

2 System Design As per the requirements, create the Design Document

front-end and database design
3 Implementation As per the design create the programs / Programs
code
Integrate the codes for the next phase.

4 System Testing Unit testing of the code Test cases

Integrate the unit tested code and test it Test reports
to make sure if it works as expected. Defect reports
5 System Deployment Make sure that the test exit criteria are User Manual
met. Deploy the application in the Environment definition /
respective environment. specification

6 System maintenance Make sure that the application is up and User Manual
running in the respective environment.
 When to use Waterfall Model?
• Requirements are firm and not changed
frequently.
• An application is small.
• The environment is stable.
• The tools and technology used is definite
• Resources are well trained and are available.
Limitations of using Waterfall model
• Cannot adopt the changes in requirements
• It becomes very difficult to move back to the phase.
• For bigger and complex projects, this model is not
good as a risk factor is higher.
• Since the testing is done at a later stage, it does not
allow identifying the challenges and risks in the
earlier phase so the risk mitigation strategy is
difficult to prepare.
• Delivery of the final product is late as there is no
prototype which is demonstrated intermediately.
 Prototyping Model
• Developer and customer meet and define
the overall objectives for the software.
• A quick design occurs focusing on those
aspects of the software that will be visible
to the customer /user (e.g., input
approaches and output formats). The
quick design leads to the construction of
a prototype.
• The prototype is evaluated by the
customer / user and used to refine
requirements for the software to be
developed.
• Iteration occurs as the prototype is tuned
to satisfy the needs of the customer,
while at the same time enabling the
developer to better understand what
needs to be done.
 When to use Prototyping Model?
• Prototyping is very effective in the analysis and
design of on-line systems.

• Prototyping is especially good for designing good

human-computer interfaces such as Google voice
search App.

• Prototype as the software specification is normally

reserved for software development within an
organization.
 Limitations of using Prototyping model
• Often clients expect that a few minor changes to the prototype
will more than suffice their needs.

• The developers may lose focus on the real purpose of the

prototype and compromise the quality of the product. For
example, they may employ some of the inefficient algorithms
or inappropriate programming languages used in developing
the quick design.

• A prototype will hardly be acceptable in risk in the event that

the client does not agree that the developer has discharged
his/her obligations.
Rapid Application Development (RAD) Model
The phases in the rapid application development (RAD) model
are:
Business modeling: The information flow is identified between
various business functions.

Data modeling: Information gathered from business modeling is

used to define data objects that are needed for the business.

Process modeling: The process description is created for adding,

modifying, deleting or retrieving a data object.

Application generation: Automated tools are used to convert

process models into code and the actual system.

Testing and turnover: Test new components and all the

interfaces.
 When to use RAD model?
• RAD should be used when there is a need to
create a system that can be modularized in 2-3
months of time.
• It should be used if there’s high availability of
designers for modeling and the budget is high
enough to afford their cost along with the cost
of automated code generating tools.
• RAD model should be chosen only if resources
with high business knowledge are available.
 Limitations of using RAD model
• Depends on strong team and individual performances for
identifying business requirements.

• Only system that can be modularized can be built using RAD

• Requires highly skilled developers/designers.

• High dependency on modeling skills.

• Inapplicable to cheaper projects as cost of modeling and

automated code generation is very high.
 Incremental Model
• The incremental build model is a
method of software development
where the model is designed,
implemented and tested incrementally
(a little more is added each time) until
the product is finished.

• It involves both development and

maintenance. The product is defined as
finished when it satisfies all of its
requirements.

• This model combines the elements of

the waterfall model with the iterative
philosophy of prototyping.
 When to use Incremental Model?

• This model can be used when the requirements of

the complete system are clearly defined and
understood.
• Major requirements must be defined; however,
some details can evolve with time.
• There is a need to get a product to the market early.
• A new technology is being used
• Resources with needed skill set are not available
• There are some high risk features and goals.
Limitations of using Incremental model
• Needs good planning and design.
• Problems may arise pertaining to system
architecture because not all requirements are
gathered up front for the entire software life
cycle.
• Total cost is quite higher.
 Spiral Model
• This model is best used for large
projects which involves
continuous enhancements. 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.
Planning: Requirements are studied and gathered. Feasibility
study and reviews to streamline the requirements are carried
out.

Risk Analysis: Requirements are studied and brain storming

sessions are done to identify the potential risks. Once the risks
are identified , risk mitigation strategy is planned and finalized

Engineering: Actual development and testing of the software

takes place in this phase

Evaluation: Customers evaluate the software and provide their

feedback and approval
 When to Use Spiral model?

• When the project is large.

• Where the software needs continuous risk
evaluation.
• Requirements are a bit complicated and require
continuous clarification.
• Software requires significant changes.
• Where enough time frame is their to get end
user feedback.
• Where releases are required to be frequent.
 Limitations of Spiral Model
• Risk analysis is important phase so requires
expert people.
• Is not beneficial for smaller projects.
• Spiral may go infinitely.
• Documentation is more as it has intermediate
phases.
• It is costly for smaller projects.