SDLC 1

SDLC
SDLC
RAVIMOHAN
SDLC Definition
Software Development Life Cycle (SDLC) is a logical
process used by a systems analyst to develop an
information system, including requirements,
validation, training, and user (stakeholder) ownership.
Any SDLC should result in a high quality system that
meets or exceeds customer expectations, reaches
completion within time and cost estimates, works
effectively and efficiently in the current
and planned Information Technology Infrastructure,
and is inexpensive to maintain and cost-effective to
enhance.
Different Stages in SDLC
SDLC
SDLC process starts from conception to completion
of any software project. According to this approach
the software development team is responsible for
the whole project development life cycle. After
doing SRS (System Requirement and Specification)
and requirements analysis; developers follow
different models of Software Development Life
Cycle (SDLC) available, while the most common
model is SDLC waterfall model. They divide project
in different stages & phases and the output of each
stage or phase becomes the input for next stage.
THE SDLC WATERFALL
Project Planning
Requirements
Definition
Design
Development
Integration & Test
Installation & Acceptance
WATERFALL MODEL
Stages of Waterfall Model
• Requirement gathering and Analysis.

• System Design.
• Implementation.
• Testing.
• Deployment of System.
• Maintenance.
Requirement Analysis & Definition
All possible requirements of the system to be developed

are captured in this phase. Requirements are set of
functionalities and constraints that the end-user (who will
be using the system) expects from the system. The
requirements are gathered from the end-user by
consultation, these requirements are analyzed for their
validity and the possibility of incorporating the
requirements in the system to be development is also
studied. Finally, a Requirement Specification document is
created which serves the purpose of guideline for the next
phase of the model.
System & Software Design
• Before a starting for actual coding, it is highly
important to understand what we are going to
create and what it should look like? The
requirement specifications from first phase
are studied in this phase and system design
is prepared. System Design
• helps in specifying hardware and system
requirements.
• helps in defining overall system architecture.
The system design specifications serve as
input for the next phase of the model.
Implementation and Unit Testing
On receiving system design documents, the
work is divided in modules/units and actual
coding is started. The system is first developed
in small programs called units, which are
integrated in the next phase. Each unit is
developed and tested for its functionality; this is
referred to as Unit Testing. Unit testing mainly
verifies if the modules/units meet their
specifications.
Integration and System Testing
As specified above, the system is first divided
in units which are developed and tested for
their functionalities. These units are integrated
into a complete system during Integration
phase and tested to check if all modules/units
coordinate between each other and the system
as a whole behaves as per the specifications.
After successfully testing the software, it is
delivered to the customer.
Operation and Maintenance
This phase of "The Waterfall Model" is virtually
never ending phase (Very long). Generally,
problems with the system developed (which are
not found during the development life cycle)
come up after its practical use starts, so the
issues related to the system are solved after
deployment of the system. Not all the problems
come in picture directly but they arise time to
time and needs to be solved; hence this
process is referred as Maintenance.
Advantages of Waterfall Model
The advantage of waterfall development is that it allows
for departmentalization and managerial control. A
schedule can be set with deadlines for each stage of\
development and a product can proceed through the
development process like a car in a carwash, and
theoretically, be delivered on time. Development moves
from concept, through design, implementation, testing,
installation, troubleshooting, and ends up at operation
and maintenance. Each phase of development
proceeds in strict order, without any overlapping or
iterative steps.
Disadvantages of Waterfall Model
The disadvantage of waterfall development is
that it does not allow for much reflection or
revision. Once an application is in the testing
stage, it is very difficult to go back and change
something that was not well-thought out in the
concept stage. Alternatives to the waterfall
model include joint application development\
(JAD), rapid application development (RAD),
synch and stabilize, build and fix, and the spiral
model.
Why Waterfall?
• The relationship of each stage to the others can be
roughly described as a waterfall, where the outputs
from a specific stage serve as the initial inputs for the
following stage.
• During each stage, additional information is gathered
or developed, combined with the inputs, and used to
produce the stage deliverables. It is important to note
that the additional information is restricted in scope;
“new ideas” that would take the project in directions
not anticipated by the initial set of high-level
requirements are not incorporated into the project.
Why Waterfall? Contd..
• Rather, ideas for new capabilities or features
that are out-of-scope are preserved for later
consideration.
• After the project is completed, the Primary
Developer Representative (PDR) and Primary
End-User Representative (PER), in concert
with other customer and development team
personnel develop a list of recommendations
for enhancement of the current software.
PROTOTYPES
• The software development team, to clarify requirements and/or design
elements, may generate mockups and prototypes of screens, reports,
and processes.
• Although some of the prototypes may appear to be very substantial,
they're generally similar to a movie set: everything looks good from the
front but there's nothing in the back.
• When a prototype is generated, the developer produces the minimum
amount of code necessary to clarify the requirements or design
elements under consideration. No effort is made to comply with coding
standards, provide robust error management, or integrate with other
database tables or modules. As a result, it is generally more expensive
to retrofit a prototype with the necessary elements to produce a
production module then it is to develop the module from scratch using
the final system design document.
• For these reasons, prototypes are never intended for business use,
and are generally crippled in one way or another to prevent them from
being mistakenly used as production modules by end-users.
ALLOWED VARIATIONS
• In some cases, additional information is made available
to the development team that requires changes in the
outputs of previous stages. In this case, the
development effort is usually suspended until the
changes can be reconciled with the current design, and
the new results are passed down the waterfall until the
project reaches the point where it was suspended.
• The PER and PDR may, at their discretion, allow the
development effort to continue while previous stage
deliverables are updated in cases where the impacts
• are minimal and strictly limited in scope. In this case,
the changes must be carefully tracked to make sure all
their impacts are appropriately handled.
OTHER SDLC MODELS
• The waterfall model is one of the three
most commonly cited lifecycle models.
• Others include the Spiral model and the

Rapid Application Development (RAD)
model, often referred to as the
Prototyping model.
SPIRAL LIFECYCLE MODEL
• The spiral model starts with an initial pass through a standard waterfall
lifecycle, using a subset of the total requirements to develop a robust
prototype. After an evaluation period, the cycle is initiated again,
adding new functionality and releasing the next prototype. This
process continues, with the prototype becoming larger and larger with
each iteration. Hence, the “spiral.”
• The theory is that the set of requirements is hierarchical in nature, with

additional functionality building on the first efforts. This is a sound
practice for systems where the entire problem is well defined from the
start, such as modeling and simulating software. Business-oriented
database projects do not enjoy this advantage. Most of the functions in
a database solution are essentially independent of one another,
although they may make use of common data. As a result, the
prototype suffers from the same flaws as the prototyping lifecycle
described below. For this reason, the software development team has
decided against the use of the spiral lifecycle for database projects.
RAPID APPLICATION DEVELOPMENT
(RAD) / PROTOTYPING LIFECYCLE
RAD is, in essence, the “try before you buy” approach to software
development. The theory is that end users can produce better
feedback when examining a live system, as opposed to working
strictly with documentation. RAD-based development cycles have
resulted in a lower level of rejection when the application is placed
Into production, but this success most often comes at the expense of
a dramatic overruns in project costs and schedule. The RAD
approach was made possible with significant advances in software
development environments to allow rapid generation and change of
screens and other user interface features. The end user is allowed to
work with the screens online, as if in a production environment. This
leaves little to the imagination, and a significant number of errors are
caught using this process.
RAD / PROTOTYPING LIFECYCLE
The down side to RAD is the propensity of the end user

to force scope creep into the development effort. Since it
seems so easy for the developer to produce the basic
screen, it must be just as easy to add a widget or two. In
most RAD lifecycle failures, the end users and developers
were caught in an unending cycle of enhancements, with
the users asking for more and more and the developers
trying to satisfy them. The participants lost sight of the
goal of producing a basic, useful system in favor of the
siren song of glittering perfection.
RAD / PROTOTYPING LIFECYCLE
For this reason, the software development team does
not use a pure RAD approach, but instead blends
limited prototyping in with requirements and design
development during a conventional waterfall lifecycle.
The prototypes developed are specifically focused on a
subset of the application, and do not provide an
integrated interface. The prototypes are used to
validate requirements and design elements, and the
development of additional requirements or the addition
of user interface options not readily supported by the
development environment is actively discouraged.

SDLC 1

Uploaded by

Copyright:

Available Formats

SDLC 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SDLC 1

Uploaded by

Copyright:

Available Formats

SDLC

• Requirement gathering and Analysis.

All possible requirements of the system to be developed

• Others include the Spiral model and the

• The theory is that the set of requirements is hierarchical in nature, with

The down side to RAD is the propensity of the end user

You might also like