Software Development Life Cycle
Software Development Life Cycle
A software life cycle model (also termed process model) is a pictorial and diagrammatic
representation of the software life cycle. A life cycle model represents all the methods
required to make a software product transit through its life cycle stages. It also captures the
structure in which these methods are to be undertaken.
In other words, a life cycle model maps the various activities performed on a software
product from its inception to retirement. Different life cycle models may plan the necessary
development activities to phases in different ways. Thus, no element which life cycle model
is followed, the essential activities are contained in all life cycle models though the action
may be carried out in distinct orders in different life cycle models. During any life cycle
stage, more than one activity may also be carried out.
Need of SDLC
The development team must determine a suitable life cycle model for a particular plan and
then observe to it.
Without using an exact life cycle model, the development of a software product would not be
in a systematic and disciplined manner. When a team is developing a software product, there
must be a clear understanding among team representative about when and what to do.
Otherwise, it would point to chaos and project failure. This problem can be defined by using
an example. Suppose a software development issue is divided into various parts and the parts
are assigned to the team members. From then on, suppose the team representative is allowed
the freedom to develop the roles assigned to them in whatever way they like. It is possible
that one representative might start writing the code for his part, another might choose to
prepare the test documents first, and some other engineer might begin with the design phase
of the roles assigned to him. This would be one of the perfect methods for project failure.
A software life cycle model describes entry and exit criteria for each phase. A phase can
begin only if its stage-entry criteria have been fulfilled. So without a software life cycle
model, the entry and exit criteria for a stage cannot be recognized. Without software life cycle
models, it becomes tough for software project managers to monitor the progress of the
project.
SDLC Cycle
SDLC Cycle represents the process of developing software. SDLC framework includes the
following steps:
The stages of SDLC are as follows:
The senior members of the team perform it with inputs from all the stakeholders and domain
experts or SMEs in the industry.
Planning for the quality assurance requirements and identifications of the risks associated
with the projects is also done at this stage.
ADVERTISEMENT
Business analyst and Project organizer set up a meeting with the client to gather all the data
like what the customer wants to build, who will be the end user, what is the objective of the
product. Before creating a product, a core understanding or knowledge of the product is very
necessary.
For Example, A client wants to have an application which concerns money transactions. In
this method, the requirement has to be precise like what kind of operations will be done, how
it will be done, in which currency it will be done, etc.
Once the required function is done, an analysis is complete with auditing the feasibility of the
growth of a product. In case of any ambiguity, a signal is set up for further discussion.
Once the requirement analysis is done, the next stage is to certainly represent and document
the software requirements and get them accepted from the project stakeholders.
In this phase of SDLC, the actual development begins, and the programming is built. The
implementation of design begins concerning writing code. Developers have to follow the
coding guidelines described by their management and programming tools like compilers,
interpreters, debuggers, etc. are used to develop and implement the code.
Stage5: Testing
After the code is generated, it is tested against the requirements to make sure that the
products are solving the needs addressed and gathered during the requirements stage.
During this stage, unit testing, integration testing, system testing, acceptance testing are done.
Stage6: Deployment
Once the software is certified, and no bugs or errors are stated, then it is deployed.
Then based on the assessment, the software may be released as it is or with suggested
enhancement in the object segment.
After the software is deployed, then its maintenance begins.
Stage7: Maintenance
Once when the client starts using the developed systems, then the real issues come up and
requirements to be solved from time to time.
This procedure where the care is taken for the developed product is known as maintenance.
SDLC Models
Software Development life cycle (SDLC) is a spiritual model used in project management
that defines the stages include in an information system development project, from an initial
feasibility study to the maintenance of the completed application.
There are different software development life cycle models specify and design, which are
followed during the software development phase. These models are also called "Software
Development Process Models." Each process model follows a series of phase unique to its
type to ensure success in the step of software development.
Waterfall Model
The waterfall is a universally accepted SDLC model. In this method, the whole process of
software development is divided into various phases.
RAD Model
Spiral Model
The spiral model is a risk-driven process model. This SDLC model helps the group to adopt
elements of one or more process models like a waterfall, incremental, waterfall, etc. The
spiral technique is a combination of rapid prototyping and concurrency in design and
development activities.
Each cycle in the spiral begins with the identification of objectives for that cycle, the different
alternatives that are possible for achieving the goals, and the constraints that exist. This is the
first quadrant of the cycle (upper-left quadrant).
The next step in the cycle is to evaluate these different alternatives based on the objectives
and constraints. The focus of evaluation in this step is based on the risk perception for the
project.
The next step is to develop strategies that solve uncertainties and risks. This step may involve
activities such as benchmarking, simulation, and prototyping.
V-Model
In this type of SDLC model testing and the development, the step is planned in parallel. So,
there are verification phases on the side and the validation phase on the other side. V-Model
joins by Coding phase.
Incremental Model
The incremental model is not a separate model. It is necessarily a series of waterfall cycles.
The requirements are divided into groups at the start of the project. For each group, the SDLC
model is followed to develop software. The SDLC process is repeated, with each release
adding more functionality until all requirements are met. In this method, each cycle act as the
maintenance phase for the previous software release. Modification to the incremental model
allows development cycles to overlap. After that subsequent cycle may begin before the
previous cycle is complete.
Agile Model
Agile methodology is a practice which promotes continues interaction of development and
testing during the SDLC process of any project. In the Agile method, the entire project is
divided into small incremental builds. All of these builds are provided in iterations, and each
iteration lasts from one to three weeks.
Any agile software phase is characterized in a manner that addresses several key assumptions
about the bulk of software projects:
1. It is difficult to think in advance which software requirements will persist and which
will change. It is equally difficult to predict how user priorities will change as the
project proceeds.
2. For many types of software, design and development are interleaved. That is, both
activities should be performed in tandem so that design models are proven as they are
created. It is difficult to think about how much design is necessary before construction
is used to test the configuration.
3. Analysis, design, development, and testing are not as predictable (from a planning
point of view) as we might like.
Iterative Model
Big bang model is focusing on all types of resources in software development and coding,
with no or very little planning. The requirements are understood and implemented when they
come.
This model works best for small projects with smaller size development team which are
working together. It is also useful for academic software development projects. It is an ideal
model where requirements are either unknown or final release date is not given.
Prototype Model
The prototyping model starts with the requirements gathering. The developer and the user
meet and define the purpose of the software, identify the needs, etc.
A 'quick design' is then created. This design focuses on those aspects of the software that will
be visible to the user. It then leads to the development of a prototype. The customer then
checks the prototype, and any modifications or changes that are needed are made to the
prototype.
Waterfall model
Winston Royce introduced the Waterfall Model in 1970.This model has five phases:
Requirements analysis and specification, design, implementation, and unit testing, integration
and system testing, and operation and maintenance. The steps always follow in this order and
do not overlap. The developer must complete every phase before the next phase begins. This
model is named "Waterfall Model", because its diagrammatic representation resembles a
cascade of waterfalls.
1. Requirements analysis and specification phase: The aim of this phase is to understand
the exact requirements of the customer and to document them properly. Both the customer
and the software developer work together so as to document all the functions, performance,
and interfacing requirement of the software. It describes the "what" of the system to be
produced and not "how."In this phase, a large document called Software Requirement
Specification (SRS) document is created which contained a detailed description of what the
system will do in the common language.
2. Design Phase: This phase aims to transform the requirements gathered in the SRS into a
suitable form which permits further coding in a programming language. It defines the overall
software architecture together with high level and detailed design. All this work is
documented as a Software Design Document (SDD).
3. Implementation and unit testing: During this phase, design is implemented. If the SDD
is complete, the implementation or coding phase proceeds smoothly, because all the
information needed by software developers is contained in the SDD.
During testing, the code is thoroughly examined and modified. Small modules are tested in
isolation initially. After that these modules are tested by writing some overhead code to check
the interaction between these modules and the flow of intermediate output.
4. Integration and System Testing: This phase is highly crucial as the quality of the end
product is determined by the effectiveness of the testing carried out. The better output will
lead to satisfied customers, lower maintenance costs, and accurate results. Unit testing
determines the efficiency of individual modules. However, in this phase, the modules are
tested for their interactions with each other and with the system.
5. Operation and maintenance phase: Maintenance is the task performed by every user
once the software has been delivered to the customer, installed, and operational.
Some Circumstances where the use of the Waterfall model is most suited are:
o This model is simple to implement also the number of resources that are required for
it is minimal.
o The requirements are simple and explicitly declared; they remain unchanged during
the entire project development.
o The start and end points for each phase is fixed, which makes it easy to cover
progress.
o The release date for the complete product, as well as its final cost, can be determined
before development.
o It gives easy to control and clarity for the customer due to a strict reporting system.
o In this model, the risk factor is higher, so this model is not suitable for more
significant and complex projects.
o Since the testing done at a later stage, it does not allow identifying the challenges and
risks in the earlier phase, so the risk reduction strategy is difficult to prepare.