1|SDLC

SEMINAR REPORT

On

“Software Development Life Cycle”

Submitted in

Partial Fulfillment of the Requirements for BCA Ist Year

Session: 2019-20

Submitted To: Submitted by:

Ms. Krupali Nirbhay Agrawal

(Asst. Professor) 19BCAN015

DEPARTMENT OF IT & CA

JECRC UNIVERSITY, JAIPUR

2|SDLC

Table Of Contents
Chapter 1)Software Development Life Cycle Process ..................................... 4
Chapter 2)SDLC Cycle .................................................................................... 5
Chapter 3)SDLC Phases .................................................................................. 5
3.1) Requirement Gathering and Analysis .................................................. 7
3.2) Design ................................................................................................... 8
3.3) Implementation And Coding .............................................................. 11
3.4) Testing ................................................................................................ 14
3.5) Deployment ......................................................................................... 20
3.6) Maintenance ....................................................................................... 22
Chapter 4)Software Development Life Cycle Models ................................... 25
4.1) Waterfall Model .................................................................................. 26
4.2) V-Shaped Model ................................................................................. 28
4.3) Prototype Model ................................................................................. 32
4.4) Spiral Model ....................................................................................... 35
4.5) Iterative Incremental Model ............................................................... 37
4.6) Big Bang Model .................................................................................. 40
4.7) Agile Model ......................................................................................... 45
Chapter 5) Conclusion ……………………...………………………………………………………. 48
Chapter 6) References ……………………..………………………………………………………. 49
3|SDLC

List of Figures
1.) Phases of SDLC………………………………………………………………………………………… 5

2.) Waterfall Model…………………………………………………………………………………….27

3.) V-shaped Model………………………………………………………………………………………28

4.) Prototype Model……………………………………………………………………………………33

5.) Spiral Model……………………………………………………………………………………………..35

6.) Iterative Incremental Model……………………………………………………………………..39

7.) Big Bang Model…………………………………………………………………………………………41

8.) Agile Model……………………………………………………………………………………………….47

4|SDLC

What is Software Development Life Cycle

(SDLC)?
Software Development Life Cycle (SDLC) is a framework that defines the steps
involved in the development of software at each phase. It covers the detailed plan
for building, deploying and maintaining the software. SDLC defines the complete
cycle of development i.e. all the tasks involved in planning, creating, testing, and
deploying a Software Product.

Software Development Life Cycle Process

SDLC is a process which defines the various stages involved in the development of
software for delivering a high-quality product. SDLC stages cover the complete
life cycle of a software i.e. from inception to retirement of the product.

Adhering to the SDLC process leads to the development of the software in a

systematic and disciplined manner.

Purpose:
Purpose of SDLC is to deliver a high-quality product which is as per the
customer’s requirement.

SDLC has defined its phases as, Requirement gathering, Designing, Coding,
Testing, and Maintenance. It is important to adhere to the phases to provide the
Product in a systematic manner.

For Example: A software has to be developed and a team is divided to work on a

feature of the product and is allowed to work as they want. One of the developers
5|SDLC

decides to design first whereas the other decides to code first and the other on the
documentation part.
This will lead to project failure because of which it is necessary to have a good
knowledge and understanding among the team members to deliver an expected
product.

SDLC Cycle
SDLC Cycle represents the process of developing software.

Below is the diagrammatic representation of the SDLC

cycle:

Fig. 1 Phases of SDLC

6|SDLC

SDLC Phases
Software life cycle models describe phases of the software cycle and the order in
which those phases are executed. Each phase produces deliverables required by the
next phase in the life cycle. Requirements are translated into design. Code is
produced according to the design which is called development phase. After coding
and development the testing verifies the deliverable of the implementation phase
against requirements. The testing team follows Software Testing Life Cycle
(STLC) which is similar to the development cycle followed by the development
team.

Given below are the various phases:

 Requirement gathering and analysis
 Design
 Implementation or coding
 Testing
 Deployment
 Maintenance.
7|SDLC

1) Requirement Gathering and Analysis

During this phase, all the relevant information is collected from the customer to
develop a product as per their expectation. Any ambiguities must be resolved in
this phase only.

Business analyst and Project Manager set up a meeting with the customer to gather
all the information like what the customer wants to build, who will be the end-user,
what is the purpose of the product. Before building a product a core understanding
or knowledge of the product is very important.

For Example, A customer wants to have an application which involves money

transactions. In this case, the requirement has to be clear like what kind of
transactions will be done, how it will be done, in which currency it will be done,
etc.
Once the requirement gathering is done, an analysis is done to check the feasibility
of the development of a product. In case of any ambiguity, a call is set up for
further discussion.

Once the requirement is clearly understood, the SRS (Software Requirement

Specification) document is created. This document should be thoroughly
understood by the developers and also should be reviewed by the customer for
future reference.
8|SDLC

2) Design
In this phase, the requirement gathered in the SRS document is used as an input
and software architecture that is used for implementing system development is
derived.

What Is in a Software Requirements Specification Document?

A software requirements specification (SRS) is a document that describes what the

software will do and how it will be expected to perform.

An SRS describes the functionality the product needs to fulfill all stakeholders
(business, users) needs.

A typical SRS includes:

 A purpose
 An overall description
 Specific requirements

The best SRS documents define how the software will interact when embedded in
hardware — or when connected to other software. Good SRS documents also
account for real-life users.

Why Use an SRS Document?

A software requirements specification is the basis for your entire project. It lays the
framework that every team involved in development will follow.

It’s used to provide critical information to multiple teams — development, quality

assurance, operations, and maintenance. This keeps everyone on the same page.
9|SDLC

Using the SRS helps to ensure requirements are fulfilled. And it can also help you
make decisions about your product’s lifecycle — for instance, when to retire a
feature.

Writing an SRS can also minimize overall development time and costs. Embedded
development teams especially benefit from using an SRS.

Software Requirements Specification vs. System Requirements Specification

A software requirements specification (SRS) includes in-depth descriptions of

the software that will be developed.

A system requirements specification (SyRS) collects information on the

requirements for a system.

“Software” and “system” are sometimes used interchangeably as SRS. But, a

software requirement specification provides greater detail than a system
requirements specification.

How to Write an SRS Document

Writing an SRS document is important. But it isn’t always easy to do.

Here are five steps you can follow to write an effective SRS document.

1. Create an Outline (Or Use an SRS Template)

Your first step is to create an outline for your software requirements specification.
This may be something you create yourself. Or you may use an existing SRS
template.
10 | S D L C

If you’re creating this yourself, here’s what your outline might look like:

1. Introduction

1.1 Purpose

1.2 Intended Audience

1.3 Intended Use

1.4 Scope

1.5 Definitions and Acronyms

2. Overall Description

2.1 User Needs

2.2 Assumptions and Dependencies

3. System Features and Requirements

3.1 Functional Requirements

3.2 External Interface Requirements

3.3 System Features

3.4 Nonfunctional Requirements

Once you have your basic outline, you’re ready to start filling it out.
11 | S D L C

3) Implementation and Coding

Implementation/Coding starts once the developer gets the Design document. The
Software design is translated into source code. All the components of the software
are implemented in this phase.

After having the user acceptance of the new system developed, the implementation
phase begins. Implementation is the stage of a project during which theory is
turned into practice. The major steps involved in this phase are:

 Acquisition and Installation of Hardware and Software

 Conversion
 User Training
 Documentation

The hardware and the relevant software required for running the system must be
made fully operational before implementation. The conversion is also one of the
most critical and expensive activities in the system development life cycle. The
data from the old system needs to be converted to operate in the new format of the
new system. The database needs to be setup with security and recovery procedures
fully defined.
During this phase, all the programs of the system are loaded onto the user’s
computer. After loading the system, training of the user starts. Main topics of such
type of training are:

 How to execute the package?

 How to enter the data?
 How to process the data (processing details)?
 How to take out the reports?
12 | S D L C

After the users are trained about the computerized system, working has to shift
from manual to computerized working. The process is called Changeover. The
following strategies are followed for changeover of the system.

1. Direct Changeover: This is the complete replacement of the old system by

the new system. It is a risky approach and requires comprehensive system
testing and training.
2. Parallel run : In parallel run both the systems, i.e., computerized and
manual, are executed simultaneously for certain defined period. The same
data is processed by both the systems. This strategy is less risky but more
expensive because of the following facts:

 Manual results can be compared with the results of the computerized system.
 The operational work is doubled.
 Failure of the computerised system at the early stage does not affect the
working of the organization, because the manual system continues to work, as it
used to do.

(iii) Pilot run: In this type of run, the new system is run with the data from one or
more of the previous periods for the whole or part of the system. The results are
compared with the old

system results. It is less expensive and risky than parallel run approach. This
strategy builds the confidence and the errors are traced easily without affecting the
operations.

The documentation of the system is also one of the most important activity in the
system development life cycle. This ensures the continuity of the system.
Generally following two types of documentations are prepared for any system.
13 | S D L C

 User or Operator Documentation

 System Documentation

User Documentation: The user documentation is a complete description of the

system from the user’s point of view detailing how to use or operate the system. It
also includes the major error messages likely to be encountered by the user.

System Documentation: The system documentation contains the details of system

design, programs, their coding, system flow, data dictionary, process description,
etc. This helps to understand the system and permit changes to be made in the
existing system to satisfy new user needs.

The system design needs to be implemented to make it a workable system it

demands the coding of design into computer language, i.e., programming language.
This is also called the programming phase in which the programmer converts the
program specifications into computer instructions, which we refer to as programs.
It is an important stage where the defined procedures are transformed into control
specifications by the help of a computer language. The programs coordinate the
data movements and control the entire process in a system. A well written code
reduces the testing and maintenance effort. It is generally felt that the programs
must be modular in nature. This helps in fast development, maintenance and future
changes, if required. Programming tools like compilers, interpreters and language
like c, c++, and java etc., are used for coding .with respect to the type of
application. The right programming language should be chosen.
14 | S D L C

4) Testing
Testing starts once the coding is complete and the modules are released for testing.
In this phase, the developed software is tested thoroughly and any defects found
are assigned to developers to get them fixed.

Retesting, regression testing is done until the point at which the software is as per
the customer’s expectation. Testers refer SRS document to make sure that the
software is as per the customer’s standard.

Before actually implementing the new system into operations, a test run of the
system is done removing all the bugs, if any. It is an important phase of a
successful system. After codifying the whole programs of the system, a test plan
should be developed and run on a given set of test data. The output of the test run
should match the expected results. Sometimes, system testing is considered as a
part of implementation process.

Using the test data following test run are carried out:

 Program test
 System test

Program Test: When the programs have been coded and compiled and brought
to working conditions, they must be individually tested with the prepared test data.
All verification and validation be checked and any undesirable happening must be
noted and debugged (error corrected).

System Test: After carrying out the program test for each of the programs of the
system and errors removed, then system test is done. At this stage the test is done
on actual data. The complete system is executed on the actual data. At each stage
15 | S D L C

of the execution, the results or output of the system is analyzed. During the result
analysis, it may be found that the outputs are not matching the expected output of
the system. In such case, the errors in the particular programs are identified and are
fixed and further tested for the expected output. All independent modules be
brought together and all the interfaces to be tested between multiple modules, the
whole set of software is tested to establish that all modules work together correctly
as an application or system or package.

When it is ensured that the system is running error-free, the users are called with
their own actual data so that the system could be shown running as per their
requirements.

Principles of Testing:-

(i) All the test should meet the customer requirements.

(ii) To make our software testing should be performed by third party
(iii) Exhaustive testing is not possible. As we need the optimal amount of testing
based on the risk assessment of the application.
(iv) All the test to be conducted should be planned before implementing it
(v) It follows Pareto rule (80/20 rule) which states that 80% of errors comes from
20% of program components.
(vi) Start testing with small parts and extend it to large parts.
16 | S D L C

Black Box Testing

Testing is broadly based on software requirements and specifications. Black Box
Testing is a technique in which tester is unaware about the internal structure or
code of the software.

The focus is on inputs and outputs ignoring the internal knowledge of the code.
Using black box testing, one can test operating systems like Windows, websites
like Google and even our own customized applications, as the core knowledge
about these operating systems are not required.

How Black Box Testing Works?

Black box testing can broadly be summarized into the following steps.

1. The first step is to thoroughly examine the requirements and specifications of

the system.
2. The tester explores the system’s UI and functionality to understand how the
processes on the system are expected to work.
3. On later stage, the tester checks efficiency of the software by determining
expected outputs with their corresponding inputs.
4. Finally, the developer fixes the bug detected and the output undergoes retesting.

Black Box Testing Techniques

There are three techniques usually employed by organizations and testers in case of
Black Box Testing.

Equivalent Class Testing: It is used to reduce the number of possible test cases to
an ideal level to maintain a reasonable test coverage.
 17 | S D L C

Boundary Value Testing: It determines whether certain range of values are

accepted by the software or not. This helps in reducing number of test cases.
Decision Table Testing: A decision table puts conditions and their outcomes in a
matrix. There is a unique combination in every segment.

Advantages
 Suitable for large code segments
 Increased Efficiency
 Prior knowledge of code is not required
Black box testing is all about enhancing the user experience even if they are from a
non-technical background. On the other hand, for technical support and precise
coding, White box testing is an excellent approach for organizations to employ.
18 | S D L C

White Box Testing

White Box Testing is also known as open, transparent or glass box testing. In white
box testing, the tester has prior knowledge of the code and accordingly prepares
the test case.

The tester has the knowledge of the internals of a system and knows how the
system is implemented. The tester uses this knowledge to develop test cases that
will examine the control flow, information flow, data flow, exception and error
handling as well as coding practices of the system.

How does White Box Testing work?

Here's how White Box Testing works ...

1. The first step for the tester is to understand the source code.
2. White Box testing then involves testing of internal functions of the application,
so knowledge of source code is crucial.
3. The tester should be aware of the secure coding practices as security is the most
important factor in testing.
4. Tester can then write code for testing the application or can prepare certain test
cases with suitable inputs.

White Box Testing Techniques

Code Coverage Analysis: It eliminates gaps in test case suite by identifying the
program which cannot be examined by test cases. In addition, you can create test
cases for untested part of the program which improves the quality of the software.
 19 | S D L C

Statement Coverage: This technique checks every statement of the code at least
once during the test cycle.
Branch Coverage: This technique tests every possible path in the code like If-else
loops and other conditional loops of the software.

Advantages
 It optimizes the code as it tests every statement of the code.
 Automated testing is supported.
 Tests and test scripts can be reused.
 Testing is supported at early development stages.
Software testing is the most important part for maintaining the quality of the
software. Manual and automated testing both are required to test the software
thoroughly.

Taking up the black box and white box testing using an automated testing tool such
as Testing Whiz is highly recommended. Automated testing allows the tester to
focus more on the high priority issues plaguing on the deployment of the software
instead of the repetitive mundane tasks that testing needs. This helps save time,
increase productivity and efficiency of the testers along with boosting employee
morale. Moreover, testers from all backgrounds can use it seamlessly.
20 | S D L C

5) Deployment
Once the product is tested, it is deployed in the production environment or
first UAT (User Acceptance testing) is done depending on the customer
expectation.
In the case of UAT, a replica of the production environment is created and the
customer along with the developers does the testing. If the customer finds the
application as expected, then sign off is provided by the customer to go live.

In this phase, the system or system modifications are made operational in a

production environment.

The phase is initiated after the system has been tested and accepted by the user.

Activities in this phase include notification to end users, execution of previously

defined training plan, data entry or conversion, and post deployment review.

Regardless of the type of system, all aspects of the deployment phase should be
followed. This will ensure the smoothest possible transition to the organization’s
desired goal.

Tasks and activities in the deployment phase are associated with certain
deliverables described in section 4. Tasks and activities actually performed depend
on the nature of the project.

The notice of deployment should include:

 The schedule of the deployment

 a brief description of the benefits of the new system
21 | S D L C

 the difference between the old and new system

 responsibilities of end user affected by the deployed changes
 the process to obtain technical support, including contact names and phone
numbers
22 | S D L C

6) Maintenance
After the deployment of a product on the production environment, maintenance of
the product i.e. if any issue comes up and needs to be fixed or any enhancement is
to be done is taken care by the developers.

The maintenance phase involves making changes to hardware, software, and

documentation to support its operational effectiveness. It includes making changes
to improve a system's performance, correct problems, enhance security, or address
user requirements. To ensure modifications do not disrupt operations or degrade a
system's performance or security, organizations should establish appropriate
change management standards and procedures.

Change management (sometimes referred to as configuration management)

involves establishing baseline versions of products, services, and procedures and
ensuring all changes are approved, documented, and disseminated. Change
controls should address all aspects of an organization's technology environment
including software programs, hardware and software configurations, operational
standards and procedures, and project management activities. Management should
establish change controls that address major, routine, and emergency software
modifications and software patches.

Major modifications involve significant changes to a system's functionality.

Management should implement major modifications using a well-structured
process, such as an SDLC methodology.

Routine changes are not as complex as major modifications and can usually be
implemented in the normal course of business. Routine change controls should
23 | S D L C

include procedures for requesting, evaluating, approving, testing, installing, and

documenting software modifications.

Emergency changes may address an issue that would normally be considered

routine, however, because of security concerns or processing problems, the
changes must be made quickly. Emergency change controls should include the
same procedures as routine change controls. Management should establish
abbreviated request, evaluation, and approval procedures to ensure they can
implement changes quickly. Detailed evaluations and documentation of emergency
changes should be completed as soon as possible after changes are implemented.
Management should test routine and, whenever possible, emergency changes prior
to implementation and quickly notify affected parties of all changes. If
management is unable to thoroughly test emergency modifications before
installation, it is critical that they appropriately backup files and programs and have
established back-out procedures in place.

Software patches are similar in complexity to routine modifications. This

document uses the term "patch" to describe program modifications involving
externally developed software packages. However, organizations with in-house
programming may also refer to routine software modifications as patches. Patch
management programs should address procedures for evaluating, approving,
testing, installing, and documenting software modifications. However, a critical
part of the patch management process involves maintaining an awareness of
external vulnerabilities and available patches.

Maintaining accurate, up-to-date hardware and software inventories is a critical

part of all change management processes. Management should carefully document
24 | S D L C

all modifications to ensure accurate system inventories. (If material software

patches are identified but not implemented, management should document the
reason why the patch was not installed.)

Management should coordinate all technology related changes through an

oversight committee and assign an appropriate party responsibility for
administering software patch management programs. Quality assurance, security,
audit, regulatory compliance, network, and end-user personnel should be
appropriately included in change management processes. Risk and security review
should be done whenever a system modification is implemented to ensure controls
remain in place.
25 | S D L C

Software Development Life Cycle Models

A software life cycle model is a descriptive representation of the software
development cycle. SDLC models might have a different approach but the basic
phases and activity remain the same for all the models.

One of the basic notions of the software development process is SDLC models
which stands for Software Development Life Cycle models. SDLC – is a
continuous process, which starts from the moment, when it’s made a decision to
launch the project, and it ends at the moment of its full remove from the
exploitation. There is no one single SDLC model. They are divided into main
groups, each with its features and weaknesses.
Evolving from the first and oldest “waterfall” SDLC model, their variety
significantly expanded. The SDLC models diversity is predetermined by the wide
number of product types – starting with a web application development to a
complex medical software. And if you take one of the SDLC models mentioned
below as the basis – in any case, it should be adjusted to the features of the
product, project, and company.
26 | S D L C

1) Waterfall Model
Waterfall Model is the very first model that is used in SDLC. It is also known as
the linear sequential model.
In this model, the outcome of one phase is the input for the next phase.
Development of the next phase starts only when the previous phase is complete.

 First, Requirement gathering and analysis is done. Once the requirement is

freeze then only the System Design can start. Herein, the SRS document
created is the output for the Requirement phase and it acts as an input for the
System Design.
 In System Design Software architecture and Design, documents which act as
an input for the next phase are created i.e. Implementation and coding.
 In the Implementation phase, coding is done and the software developed is
the input for the next phase i.e. testing.
 In the testing phase, the developed code is tested thoroughly to detect the
defects in the software. Defects are logged into the defect tracking tool and
are retested once fixed. Bug logging, Retest, Regression testing goes on until
the time the software is in go-live state.
 In the Deployment phase, the developed code is moved into production after
the sign off is given by the customer.
 Any issues in the production environment are resolved by the developers
which come under maintenance.
27 | S D L C

Fig.2 Waterfall Model

Advantages of the Waterfall Model:
 Waterfall model is the simple model which can be easily understood and is
the one in which all the phases are done step by step.
 Deliverables of each phase are well defined, and this leads to no complexity
and makes the project easily manageable.

Disadvantages of Waterfall model:

 Waterfall model is time-consuming & cannot be used in the short duration
projects as in this model a new phase cannot be started until the ongoing
phase is completed.
 Waterfall model cannot be used for the projects which have uncertain
requirement or wherein the requirement keeps on changing as this model
expects the requirement to be clear in the requirement gathering and analysis
phase itself and any change in the later stages would lead to cost higher as
the changes would be required in all the phases.
28 | S D L C

2) V-Shaped Model
The V-model is a type of SDLC model where process executes in a sequential
manner in V-shape. It is also known as Verification and Validation model. It is
based on the association of a testing phase for each corresponding development
stage. Development of each step directly associated with the testing phase. The
next phase starts only after completion of the previous phase i.e. for each
development activity, there is a testing activity corresponding to it.

Fig.3 V-Shaped Model

29 | S D L C

Verification: It involves static analysis technique (review) done without executing

code. It is the process of evaluation of the product development phase to find
whether specified requirements meet.

Validation: It involves dynamic analysis technique (functional, non-functional),

testing done by executing code. Validation is the process to evaluate the software
after the completion of the development phase to determine whether software
meets the customer expectations and requirements.
So V-Model contains Verification phases on one side of the Validation phases on
the other side. Verification and Validation phases are joined by coding phase in V-
shape. Thus it is called V-Model.

Design Phase:

 Requirement Analysis: This phase contains detailed communication with the

customer to understand their requirements and expectations. This stage is
known as Requirement Gathering.
 System Design: This phase contains the system design and the complete
hardware and communication setup for developing product.
 Architectural Design: System design is broken down further into modules
taking up different functionalities. The data transfer and communication
between the internal modules and with the outside world (other systems) is
clearly understood.
 Module Design: In this phase the system breaks dowm into small modules.
The detailed design of modules is specified, also known as Low-Level Design
(LLD).
30 | S D L C

Testing Phases:
 Unit Testing: Unit Test Plans are developed during module design phase.
These Unit Test Plans are executed to eliminate bugs at code or unit level.
 Integration testing: After completion of unit testing Integration testing is
performed. In integration testing, the modules are integrated and the system is
tested. Integration testing is performed on the Architecture design phase. This
test verifies the communication of modules among themselves.
 System Testing: System testing test the complete application with its
functionality, inter dependency, and communication .It tests the functional and
non-functional requirements of the developed application.
 User Acceptance Testing (UAT): UAT is performed in a user environment
that resembles the production environment. UAT verifies that the delivered
system meets user’s requirement and system is ready for use in real world.


Why preferred?
 It is easy to manage due to the rigidity of the model. Each phase of V-Model
has specific deliverables and a review process.
 Proactive defect tracking – that is defects are found at early stage.

When to use?
 Where requirements are clearly defined and fixed.
 The V-Model is used when ample technical resources are available with
technical expertise.
31 | S D L C

Advantages:
 This is a highly disciplined model and Phases are completed one at a time.
 V-Model is used for small projects where project requirements are clear.
 Simple and easy to understand and use.
 This model focuses on verification and validation activities early in the life
cycle thereby enhancing the probability of building an error-free and good
quality product.
 It enables project management to track progress accurately.

Disadvantages:
 High risk and uncertainty.
 It is not a good for complex and object-oriented projects.
 It is not suitable for projects where requirements are not clear and contains
high risk of changing.
 This model does not support iteration of phases.
 It does not easily handle concurrent events.
32 | S D L C

3) Prototype Model
Software prototypes are built prior to the actual software to get valuable feedback
from the customer. Feedbacks are implemented and the prototype is again
reviewed by the customer for any change. This process goes on until the model is
accepted by the customer. Prototype models have limited functional capabilities
and inefficient performance when compared to the actual software. Dummy
functions are used to create prototypes.

Once the requirement gathering is done, the quick design is created and the
prototype which is presented to the customer for evaluation is built. Customer
feedback and the refined requirement is used to modify the prototype and is again
presented to the customer for evaluation. Once the customer approves the
prototype, it is used as a requirement for building the actual software. The actual
software is build using the Waterfall model approach.

There are 2 approaches for this model:

1. Rapid Throwaway Prototyping: This technique offers a useful method of

exploring ideas and getting customer feedback for each of them. In this
method, a developed prototype need not necessarily be a part of the ultimately
accepted prototype. Customer feedback helps in preventing unnecessary
design faults and hence, the final prototype developed is of a better quality.
2. Evolutionary Prototyping: In this method, the prototype developed initially
is incrementally refined on the basis of customer feedback till it finally gets
accepted. In comparison to Rapid Throwaway Prototyping, it offers a better
approach which saves time as well as effort. This is because developing a
33 | S D L C

prototype from scratch for every iteration of the process can sometimes be
very frustrating for the developers.

Fig.4 Prototype Model

Advantages
 The customers get to see the partial product early in the life cycle. This
ensures a greater level of customer satisfaction and comfort.
 New requirements can be easily accommodated as there is scope for
refinement.
34 | S D L C

 Errors can be detected much earlier thereby saving a lot of effort and cost,
besides enhancing the quality of the software.
 The developed prototype can be reused by the developer for more complicated
projects in the future.
 Flexibility in design.

Disadvantages
 There may be too much variation in requirements each time the prototype is
evaluated by the customer.
 Poor Documentation due to continuously changing customer requirements.
 It is very difficult for the developers to accommodate all the changes
demanded by the customer.
 There is uncertainty in determining the number of iterations that would be
required before the prototype is finally accepted by the customer.
 The customer might lose interest in the product if he/she is not satisfied with
the initial prototype.

Use
The Prototyping Model should be used when the requirements of the product are
not clearly understood or are unstable. It can also be used if requirements are
changing quickly. This model can be successfully used for developing user
interfaces, high technology software-intensive systems, and systems with complex
algorithms and interfaces. It is also a very good choice to demonstrate the technical
feasibility of the product.
35 | S D L C

4) Spiral Model
The Spiral Model includes iterative and prototype approach.
Spiral model phases are followed in the iterations. The loops in the model
represent the phase of the SDLC process i.e. the innermost loop is of requirement
gathering & analysis which follows the Planning, Risk analysis, development, and
evaluation. Next loop is designing followed by Implementation & then testing.

Spiral Model has four phases:

 Planning
 Risk Analysis
 Engineering
 Evaluation

Fig.5 Spiral Model

36 | S D L C

i. Planning
The planning phase includes requirement gathering wherein all the required
information is gathered from the customer and is documented. Software
requirement specification document is created for the next phase.

ii. Risk Analysis:

In this phase, the best solution is selected for the risks involved and analysis is
done by building the prototype. For Example, the risk involved in accessing the
data from a remote database can be that the data access rate might be too slow. The
risk can be resolved by building a prototype of the data access subsystem.

iii. Engineering:
Once the risk analysis is done, coding and testing are done.

iv. Evaluation:
Customer evaluates the developed system and plans for the next iteration.

Advantages of Spiral Model:

 Risk Analysis is done extensively using the prototype models.
 Any enhancement or change in the functionality can be done in the next
iteration.

Disadvantages of Spiral Model:

 The spiral model is best suited for large projects only.
 The cost can be high as it might take a large number of iterations which can
lead to high time to reach the final product.
37 | S D L C

5) Iterative Incremental Model

The iterative incremental model divides the product into small chunks.

For Example, Feature to be developed in the iteration is decided and

implemented. Each iteration goes through the phases namely Requirement
Analysis, Designing, Coding, and Testing. Detailed planning is not required in
iterations.
Once the iteration is completed, a product is verified and is delivered to the
customer for their evaluation and feedback. Customer’s feedback is implemented
in the next iteration along with the newly added feature.

Phases of Iterative & Incremental Development Model:

 Inception phase
 Elaboration Phase
 Construction Phase
 Transition Phase

(i) Inception Phase:

Inception phase includes the requirement and scope of the Project.

(ii) Elaboration Phase:

In the elaboration phase, the working architecture of a product is delivered which
covers the risk identified in the inception phase and also fulfills the non-functional
requirements.
38 | S D L C

(iii) Construction Phase:

In the Construction phase, the architecture is filled in with the code which is ready
to be deployed and is created through analysis, designing, implementation, and
testing of the functional requirement.

(iv) Transition Phase:

In the Transition Phase, the product is deployed in the Production
environment.Incremental Model is a process of software development where
requirements divided into multiple standalone modules of the software
development cycle. In this model, each module goes through the requirements,
design, implementation and testing phases. Every subsequent release of the module
adds function to the previous release. The process continues until the complete
system achieved.

When we use the Incremental Model?

 When the requirements are superior.

 A project has a lengthy development schedule.
 When Software team are not very well skilled or trained.
 When the customer demands a quick release of the product.
 You can develop prioritized requirements first.
39 | S D L C

Fig 6. Iterative Incremental Model

Advantage of Incremental Model

 Errors are easy to be recognized.

 Easier to test and debug

 More flexible.

 Simple to manage risk because it handled during its iteration.

 The Client gets important functionality early.

Disadvantages of Incremental Model

 Need for good planning

 Total Cost is high.

 Well defined module interfaces are needed.

40 | S D L C

6) Big Bang Model

Big Bang Model does not have any defined process. Money and efforts are put
together as the input and output come as a developed product which might be or
might not be the same as what the customer needs.

Big Bang Model does not require much planning and scheduling. The developer
does the requirement analysis & coding and develops the product as per his
understanding. This model is used for small projects only. There is no testing team
and no formal testing is done, and this could be a cause for the failure of the
project.

The Only Step: Bang

Unlike nearly all other popular SDLC models, the Big Bang model is unique in
that it requires virtually no planning, organization, best practices, or typical
procedures. Instead, the Big Bang model is fundamentally about simply starting the
project right now, at this instant, with no formal development structure or
organization. It is typical that very few if any team members, let alone the
customer, are completely familiar with what the requirements are for the project,
nor what is necessary to meet those goals, and thus every single aspect of the
project is developed and implemented on the fly.

Day-to-day development occurs at the whim of the team members and is loosely
based on the requirements that are generally known and accepted at that present
moment, without much regard for consequences or future requirements that may
arise. Everything about the project is completed with a laissez-faire attitude, with
41 | S D L C

little regard or care for what may come next, and instead simply enjoying the work
that is being performed at that very moment. In short, the Big Bang model is the
heavy metal of software development methodologies.

Fig.7 Big Bang Model

Big Bang Deployment

As a lesser component of software development, the deployment phase of a

product or release is typically one of the final and most critical steps in the
software development life cycle. While most projects will opt for a typical,
incremental rollout for a new deployment, in some instances it can be infeasible to
42 | S D L C

slowly introduce a new system, particularly when creating a dramatically new

version of a product or release.

In such cases, the only logical solution is a deployment that occurs instantly, like
flipping a switch. This method is often referred to as big bang adoption, which
requires that all users of a system are moved to the new system at a specific date
and time.

It should come as no surprise that implementing any system via big bang
deployment — in particular a new software system — is fraught with numerous
risks. In many cases, unforeseen issues can cause quirks in the system or failures to
properly handle migrated information that may exist when coming from a previous
version of the system.

In the worst cases, such instantaneous deployment can lead to bugs in the code that
are so severe, the system virtually fails to function on all fronts. One such real-
world example of a big bang deployment that went terribly wrong was in 1992
with the Computer Aided Dispatch program for the London Ambulance Service.
The software was intended to facilitate the rapid allocation of responding
ambulances to emergency services calls.

Unfortunately, within just a few hours of the system going live, numerous
problems arose, such as the software sending multiple units to one location while
other locations were completely ignored. The application began producing such as
massive number of error messages on dispatchers’ terminals that incoming
emergency calls were completely lost. A mere eight days after the system was
launched, it was completely shut down in favor of the old, manual system.
 43 | S D L C

Advantages of the Big Bang Model

 No Planning Requirements: Perhaps the biggest advantage to the Big Bang

model of software development is the ability to just start coding. With no formal
need to write out tons of requirements, story cards, or specification documents,
developers can simply sit down, open their favorite editor, and begin hacking away
at the code itself, potentially producing something tangible and functional in a
relatively short period time.
 No Management Requirements: With no planning documentation or formalized
requirements, there’s also very little need for managerial staff. In most cases with
a Big Bang model project, everyone on the team will effectively be peers, with no
formal management hierarchy.
 Well-Suited for Small Projects: Given the chaotic nature of a project implemented
using the Big Bang model an application most suited to this method is that of a
particularly small venture. The Big Bang model is actually quite common, whether
developers know or acknowledge they’re using it or not, within small teams of just
a handful of developers. Hackathons, where collaborators get together over the
course of a few days to rapidly develop a piece of functional software, are a great
example of where the Big Bang model really shines.
 Great Introduction to Software Development: While certainly not always relevant
to most projects, the Big Bang model is particularly great at introducing
newcomers to the core concepts of software development, as it allows them to get
straight into the code and focus on the development aspects, without being bogged
down in the minutiae of most typical SDLC models, like documentation, testing,
and so forth.
 44 | S D L C

 Ideal of Multi-Disciplined Developers: Since everyone involved in the project is

likely to be a developer, Big Bang model projects are ideal at catering to the skills
of multi-disciplined or full-stack developers, who are capable of working with a
wide range of technologies.

Disadvantages of the Big Bang Model

 Extremely Risky: Perhaps it goes without saying, but the use of the Big Bang
model for all but the simplest of projects comes with some very real and very
dangerous risks. Without proper planning, formal leadership, or even standard
coding practices and procedures, it is all too easy to run into a potentially serious
problem later down the line once deep into the project, which may require a
massive if not total rewrite of the entire code base up to that point.
 Too Simple for Complex Projects: While the Big Bang model works fairly well
with smaller projects and tiny teams, on the flip side, it is categorically disastrous
for larger or long-term projects. Even in the best case for a lengthy project,
problems would be discovered frequently but relatively soon after they were
created, which would already require hours if not days of necessary refactoring and
alterations to existing components.
 Potentially Expensive: While the Big Bang model is about as inexpensive a model
as it gets when the project first gets out of the gates, it also comes with some risks,
which can cause it to unintentionally become one of the most
expensive SDLC models in the long run. While initial funds and budget will be
spent on a whim for whatever is necessary to get the ball rolling, such lack of
planning can quickly spiral out of control when requirements of the project
dramatically change without notice.
45 | S D L C

7) Agile Model
Agile Model is a combination of the Iterative and incremental model. This model
focuses more on flexibility while developing a product rather than on the
requirement.

In Agile, a product is broken into small incremental builds. It is not developed as a

complete product in one go. Each build increments in terms of features. The next
build is built on previous functionality.

In agile iterations are termed as sprints. Each sprint lasts for2-4 weeks. At the end
of each sprint, the product owner verifies the product and after his approval, it is
delivered to the customer.

Customer feedback is taken for improvement and his suggestions and enhancement
are worked on in the next sprint. Testing is done in each sprint to minimize the risk
of any failures.

Up to date, Agile SDLC is one of the most popular software development models.
The year 2001 is considered to be the beginning of Agile methodologies.
Seventeen software developers published the Agile Manifesto that described the
underlying principles of Agile best practices.

Provided flexibility is the first and foremost benefit of the Agile software
development life cycle. The model promotes the development of software in small,
quick steps. Agile practices are based on continuous iterations of software that
allow companies to release updates to users more frequently. Each new release
serves as a base for the next one.
46 | S D L C

A development team or company must complete a phase before moving to the next
one. This is the main differentiating factor from traditional software development
life cycle models.

In Agile software development, a company determines the scope of required

changes and goes through the cycle of analysis, design, development, and testing.
This allows the team to release small changes into production instead of releasing a
single major update. One such cycle, usually called a sprint, may range from a
couple of weeks to 30 days, and varies from company to company.

Agile software development life cycle is designed to contribute to continuous

software deliverables, continuous project improvements, instant updates, and rapid
development. The Agile SDLC methodology is based on two approaches –
iterative and incremental.

Instead of creating a detailed overview of predicted needs and sticking to it

throughout the whole development process, a company applies an incremental
approach. With incremental development, software is created piece by piece. New
functionality is added at each step and new features are built on top of existing
ones. This approach helps to deliver the minimum viable product (MVP) really
fast.

An iterative approach means that you create new software through refinements.
You create an MVP and, later, refine the features and various tools. This approach
helps the development team simultaneously work on various parts of a product and
make changes easily.
47 | S D L C

Fig.8 Agile Model

Advantages of Agile Model:
 It allows more flexibility to adapt to the changes.
 The new feature can be added easily.
 Customer satisfaction as the feedback and suggestions are taken at every
stage.

Disadvantages:
 Lack of documentation.
 Agile needs experienced and highly skilled resources.
 If a customer is not clear about how exactly they want the product to be,
then the project would fail.
48 | S D L C

Conclusion
Adherence to a suitable life cycle is very important, for the successful completion
of the Project. This, in turn, makes the management easier.

Different Software Development Life Cycle models have their own Pros and Cons.
The best model for any Project can be determined by the factors like Requirement
(whether it is clear or unclear), System Complexity, Size of the Project, Cost, Skill
limitation, etc.

Example, in case of an unclear requirement, Spiral and Agile models are best to be
used as the required change can be accommodated easily at any stage.
Waterfall model is a basic model and all the other SDLC models are based on that
only.
49 | S D L C

References
 https://www.softwaretestinghelp.com/software-development-
life-cycle-sdlc

 https://www.tutorialspoint.com/sdlc/sdlc_overview.html

 http://softwaretestingfundamentals.com/software-
development-life-cycle/

 https://mlsdev.com/blog/agile-sdlc

 https://www.geeksforgeeks.org/software-engineering-sdlc-v-
model/

 https://www.testingexcellence.com/software-development-life-
cycle-sdlc-phases/

 https://blog.testlodge.com/software-development-life-cycle/