SDLC
Overview
SDLC, Software
Development Life Cycle is a process used by software industry to design,
develop and test high quality software. The SDLC aims to produce high quality
software that meets or exceeds customer expectations, reaches completion within
times and cost estimates.
A typical Software
Development life cycle consists of the following stages:
·
Stage 1: Planning and Requirement Analysis
·
Stage 2: Defining Requirements
·
Stage 3: Designing the product architecture
·
Stage 4: Building or Developing the Product
·
Stage 5: Testing the Product
·
Stage 6: Deployment in the Market and Maintenance
SDLC
Models
There are various
software development life cycle models defined and designed which are followed
during software development process. These models are also referred as
"Software Development Process Models". Each process model follows a
Series of steps unique to its type, in order to ensure success in process of
software development.
Following are the
most important and popular SDLC models followed in the industry:
·
Waterfall Model
·
Iterative Model
·
Spiral Model
·
V-Model
·
Big Bang Model
The other related
methodologies are Agile Model, RAD Model, Rapid Application Development and
Prototyping Models.
SDLC
Waterfall Model
Following is a
diagrammatic representation of different phases of waterfall model.
The sequential phases
in Waterfall model are:
·
Requirement Gathering
and analysis: All possible requirements of the system to be developed are
captured in this phase and documented in a requirement specification doc.
·
System Design: 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
and also helps in defining overall system architecture.
·
Implementation: With inputs from
system design, 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 which is referred to as Unit Testing.
·
Integration and
Testing: All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the
entire system is tested for any faults and failures.
·
Deployment of system: Once the functional
and non-functional testing is done, the product is deployed in the customer
environment or released into the market.
·
Maintenance: There are some issues
which come up in the client environment. To fix those issues patches are
released. Also to enhance the product some better versions are released.
Maintenance is done to deliver these changes in the customer environment.
All these phases are
cascaded to each other in which progress is seen as flowing steadily downwards
(like a waterfall) through the phases. The next phase is started only after the
defined set of goals are achieved for previous phase and it is signed off, so
the name "Waterfall Model". In this model phases do not overlap.
Pros
|
Cons
|
·
Simple and easy to
understand and use
·
Easy to manage due
to the rigidity of the model . each phase has specific deliverables and a
review process.
·
Phases are
processed and completed one at a time.
·
Works well for
smaller projects where requirements are very well understood.
·
Clearly defined
stages.
·
Well understood
milestones.
·
Easy to arrange
tasks.
·
Process and results
are well documented.
|
·
No working software
is produced until late during the life cycle.
·
High amounts of
risk and uncertainty.
·
Not a good model
for complex and object-oriented projects.
·
Poor model for long
and ongoing projects.
·
Not suitable for
the projects where requirements are at a moderate to high risk of changing.
So risk and uncertainty is high with this process model.
·
It is difficult to
measure progress within stages.
·
Cannot accommodate
changing requirements.
·
No working software
is produced until late in the life cycle.
·
Adjusting scope
during the life cycle can end a project.
·
Integration is done
as a "big-bang. at the very end, which doesn't allow identifying any
technological or business bottleneck or challenges early.
|
Spiral Model
Pros
|
Cons
|
|
|
V-
Model design
Under V-Model, the
corresponding testing phase of the development phase is planned in parallel. So
there are Verification phases on one side of the .V. and Validation phases on
the other side. Coding phase joins the two sides of the V-Model.
The below figure
illustrates the different phases in V-Model of SDLC.
Verification
Phases
Following are the Verification
phases in V-Model:
·
Business Requirement
Analysis: This is the first phase in the development cycle where the
product requirements are understood from the customer perspective. This phase
involves detailed communication with the customer to understand his
expectations and exact requirement. This is a very important activity and need
to be managed well, as most of the customers are not sure about what exactly
they need. The acceptance test design planning is done at this stage as
business requirements can be used as an input for acceptance testing.
·
System Design: Once you have the
clear and detailed product requirements, it.s time to design the complete
system. System design would comprise of understanding and detailing the
complete hardware and communication setup for the product under development.
System test plan is developed based on the system design. Doing this at an
earlier stage leaves more time for actual test execution later.
·
Architectural Design: Architectural
specifications are understood and designed in this phase. Usually more than one
technical approach is proposed and based on the technical and financial
feasibility the final decision is taken. System design is broken down further
into modules taking up different functionality. This is also referred to as
High Level Design (HLD).
The data transfer and
communication between the internal modules and with the outside world (other
systems) is clearly understood and defined in this stage. With this
information, integration tests can be designed and documented during this
stage.
·
Module Design: In this phase the detailed internal design for all the system
modules is specified, referred to as Low Level Design (LLD). It is important
that the design is compatible with the other modules in the system architecture
and the other external systems. Unit tests are an essential part of any
development process and helps eliminate the maximum faults and errors at a very
early stage. Unit tests can be designed at this stage based on the internal
module designs.
Coding Phase
The actual coding of
the system modules designed in the design phase is taken up in the Coding
phase. The best suitable programming language is decided based on the system
and architectural requirements. The coding is performed based on the coding
guidelines and standards. The code goes through numerous code reviews and is
optimized for best performance before the final build is checked into the
repository.
Validation
Phases
Following are the
Validation phases in V-Model:
·
Unit Testing: Unit tests designed
in the module design phase are executed on the code during this validation
phase. Unit testing is the testing at code level and helps eliminate bugs at an
early stage, though all defects cannot be uncovered by unit testing.
·
Integration Testing: Integration testing
is associated with the architectural design phase. Integration tests are
performed to test the coexistence and communication of the internal modules
within the system.
·
System Testing: System testing is
directly associated with the System design phase. System tests check the entire
system functionality and the communication of the system under development with
external systems. Most of the software and hardware compatibility issues can be
uncovered during system test execution.
·
Acceptance Testing: Acceptance testing is
associated with the business requirement analysis phase and involves testing
the product in user environment. Acceptance tests uncover the compatibility
issues with the other systems available in the user environment. It also
discovers the non functional issues such as load and performance defects in the
actual user environment.
V- Model
Application
V- Model application
is almost same as waterfall model, as both the models are of sequential type.
Requirements have to be very clear before the project starts, because it is
usually expensive to go back and make changes. This model is used in the
medical development field, as it is strictly disciplined domain. Following are
the suitable scenarios to use V-Model:
·
Requirements are well defined, clearly documented and
fixed.
·
Product definition is stable.
·
Technology is not dynamic and is well understood by
the project team.
·
There are no ambiguous or undefined requirements.
·
The project is short.
V- Model Pros
and Cons
The advantage of
V-Model is that it.s very easy to understand and apply. The simplicity of this
model also makes it easier to manage. The disadvantage is that the model is not
flexible to changes and just in case there is a requirement change, which is
very common in today.s dynamic world, it becomes very expensive to make the
change.
The following table
lists out the pros and cons of V-Model:
Pros
|
Cons
|
·
This is a highly
disciplined model and Phases are completed one at a time.
·
Works well for
smaller projects where requirements are very well understood.
·
Simple and easy to
understand and use.
·
Easy to manage due
to the rigidity of the model . each phase has specific deliverables and a
review process.
|
·
High risk and
uncertainty.
·
Not a good model
for complex and object-oriented projects.
·
Poor model for long
and ongoing projects.
·
Not suitable for
the projects where requirements are at a moderate to high risk of changing.
·
Once an application
is in the testing stage, it is difficult to go back and change a
functionality
·
No working software
is produced until late during the life cycle.
|
Big
Bang Model design and Application
Big bang model
comprises of focusing all the possible resources in software development and
coding, with very little or no planning. The requirements are understood and
implemented as they come. Any changes required may or may not need to revamp
the complete software.
This model is ideal
for small projects with one or two developers working together and is also
useful for academic or practice projects. It.s an ideal model for the product
where requirements are not well understood and the final release date is not
given.
Big
Bang Model Pros and Cons
The advantage of Big
Bang is that its very simple and requires very little or no planning. Easy to
mange and no formal procedure are required.
However the Big Bang
model is a very high risk model and changes in the requirements or
misunderstood requirements may even lead to complete reversal or scraping of
the project. It is ideal for repetitive or small projects with minimum risks.
Following table lists
out the pros and cons of Big Bang Model:
Pros
|
Cons
|
·
This is a very
simple model
·
Little or no
planning required
·
Easy to manage
·
Very few resources
required
·
Gives flexibility
to developers
·
Is a good learning
aid for new comers or students
|
·
Very High risk and
uncertainty.
·
Not a good model
for complex and object-oriented projects.
·
Poor model for long
and ongoing projects.
·
Can turn out to be
very expensive if requirements are misunderstood
|
What is Agile?
Agile
model believes that every project needs to be handled differently and the
existing methods need to be tailored to best suit the project requirements. In
agile the tasks are divided to time boxes (small time frames) to deliver
specific features for a release.
Iterative
approach is taken and working software build is delivered after each iteration.
Each build is incremental in terms of features; the final build holds all the
features required by the customer.
Here is a
graphical illustration of the Agile Model:
Agile
thought process had started early in the software development and started
becoming popular with time due to its flexibility and adaptability.
The most popular agile methods include Rational
Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming
(1996), Adaptive Software Development, Feature Driven Development, and Dynamic
Systems Development Method (DSDM) (1995). These are now collectively referred
to as agile methodologies, after the Agile Manifesto was published in 2001.
Following are the Agile
Manifesto principles
·
Individuals
and interactions - in agile development, self-organization and motivation
are important, as are interactions like co-location and pair programming.
·
Working
software - Demo working software is considered the best means of
communication with the customer to understand their requirement, instead of
just depending on documentation.
·
Customer
collaboration - As the requirements cannot be gathered completely in the
beginning of the project due to various factors, continuous customer
interaction is very important to get proper product requirements.
·
Responding
to change - agile development is focused on quick responses to change and
continuous development.
Agile Vs
Traditional SDLC Models
Agile is
based on the adaptive software
development methods where as the traditional SDLC models like waterfall model
is based on predictive approach.
Predictive
teams in the traditional SDLC models usually work with detailed planning and
have a complete forecast of the exact tasks and features to be delivered in the
next few months or during the product life cycle. Predictive methods entirely
depend on the requirement analysis and planning done in the beginning of cycle.
Any changes to be incorporated go through a strict change control management
and prioritization.
Agile
uses adaptive approach where there is no detailed planning and there is clarity
on future tasks only in respect of what features need to be developed. There is
feature driven development and the team adapts to the changing product
requirements dynamically. The product is tested very frequently, through the
release iterations, minimizing the risk of any major failures in future.
Customer
interaction is the backbone of Agile methodology, and open communication with
minimum documentation are the typical features of Agile development
environment. The agile teams work in close collaboration with each other and
are most often located in the same geographical location.
Agile Model Pros
and Cons
Agile
methods are being widely accepted in the software world recently, however, this
method may not always be suitable for all products. Here are some pros and cons
of the agile model.
Following
table lists out the pros and cons of Agile Model:
Pros
|
Cons
|
·
Is a
very realistic approach to software development
·
Promotes
teamwork and cross training.
·
Functionality
can be developed rapidly and demonstrated.
·
Resource
requirements are minimum.
·
Suitable
for fixed or changing requirements
·
Delivers
early partial working solutions.
·
Good
model for environments that change steadily.
·
Minimal
rules, documentation easily employed.
·
Enables
concurrent development and delivery within an overall planned context.
·
Little
or no planning required
·
Easy to
manage
·
Gives
flexibility to developers
|
·
Not
suitable for handling complex dependencies.
·
More
risk of sustainability, maintainability and extensibility.
·
An
overall plan, an agile leader and agile PM practice is a must without which it
will not work.
·
Strict
delivery management dictates the scope, functionality to be delivered, and
adjustments to meet the deadlines.
·
Depends
heavily on customer interaction, so if customer is not clear, team can be
driven in the wrong direction.
·
There
is very high individual dependency, since there is minimum documentation
generated.
·
Transfer
of technology to new team members may be quite challenging due to lack of
documentation.
|
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.
The product is decomposed into a number of components, each of
which are designed and built separately (termed as builds). Each component is
delivered to the client when it is complete. This allows partial utilisation of
product and avoids a long development time. It also creates a large initial
capital outlay with the subsequent long wait avoided. This model of development
also helps ease the traumatic effect of introducing completely new system all
at once.
There are some problems with this model. One is that each new
build must be integrated with previous builds and any existing systems. The
task of decomposing product into builds not trivial either. If there are too
few few builds and each build degenerates this turns into Build-And-Fix model.
However if there are too many builds then there is little added utility from
each build.
Advantages
·
Generates
working software quickly and early during the software life cycle.
·
More
flexible – less costly to change scope and requirements.
·
Easier
to test and debug during a smaller iteration.
·
Easier
to manage risk because risky pieces are identified and handled during its
iteration.
·
Each
iteration is an easily managed milestone.
Disadvantages
·
Each
phase of an iteration is rigid and do not overlap each other.
·
Problems
may arise pertaining to system architecture because not all requirements are
gathered up front for the entire software life cycle.
When to use this model
·
Such
models are used where requirements are clear and can implement by phase wise.
From the figure it’s clear that the requirements ® is divided into R1, R2……….Rn
and delivered accordingly.
·
Mostly
such model is used in web applications and product based companies.
No comments:
Post a Comment