What are the Software Development Life Cycle (SDLC) phases?

There are various software development approaches defined and designed which are
used/employed during development process of software, these approaches are also referred as
Software Development Process Models (e.g. Waterfall model, incremental model, V-model,
iterative model, etc.). Each process model follows a particular life cycle in order to ensure
success in process of software development.
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.
There are following six phases in every Software development life cycle model:
1. Requirement gathering and analysis
2. Design
3. Implementation or coding
4. Testing
5. Deployment
6. Maintenance
1) Requirement gathering and analysis: Business requirements are gathered in this phase.
This phase is the main focus of the project managers and stake holders. Meetings with managers,
stake holders and users are held in order to determine the requirements like; who is going to use
the system? How will they use the system? What data should be input into the system? What
data should be output by the system? These are general questions that get answered during a
requirements gathering phase. After requirement gathering 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.
2) Design: In this phase the system and software design is prepared from the requirement
specifications which were studied in the first phase. System Design helps in specifying hardware
and system requirements and also helps in defining overall system architecture. The system
design specifications serve as input for the next phase of the model.

3) Implementation / Coding: On receiving system design documents, the work is divided in

modules/units and actual coding is started. Since, in this phase the code is produced so it is the
main focus for the developer. This is the longest phase of the software development life cycle.
4) Testing: After the code is developed it is tested against the requirements to make sure that
the product is actually solving the needs addressed and gathered during the requirements phase.
During this phase unit testing, integration testing, system testing, acceptance testing are done.
5) Deployment: After successful testing the product is delivered / deployed to the customer for
their use.
6) Maintenance: Once when the customers starts using the developed system then the actual
problems comes up and needs to be solved from time to time. This process where the care is
taken for the developed product is known as maintenance.

SDLC:

The software development life cycle (SDLC) is a conceptual model used in project management
that describes the stages involved in an information system development project, from an initial
feasibility study through maintenance of the completed application/product.
V-Model:

The V-Model shows and translates the relationships between each phase of the development life
cycle and its associated phase of testing. The V-model is a software development model which is
considered to be an extension of the waterfall model. Instead of moving down in a linear way,
the process steps are targeted upwards after the coding phase, to form the typical V shape.
Requirements analysis: In this phase, the requirements of the proposed system are collected by
analyzing the needs of the user(s). This phase is concerned about establishing what the ideal
system has to perform. However, it does not determine how the software will be designed or
built. Usually, the users are interviewed and a document called the user requirements document
is generated. The user requirements document will typically describe the systems functional,
physical, interface, performance, data, security requirements etc as expected by the user. The
user acceptance tests are designed in this phase.
System Design: System engineers analyze and understand the business of the proposed system
by studying the user requirements document. They figure out possibilities and techniques by
which the user requirements can be implemented. If any of the requirements are not feasible, the
user is informed of the issue. A resolution is found and the user requirement document is edited
accordingly.

The software specification document which serves as a blueprint for the development phase is
generated. This document contains the general system organization, menu structures, data
structures etc. It may also hold example business scenarios, sample windows, reports for the
better understanding. Other technical documentation like entity diagrams, data dictionary will
also be produced in this phase. The documents for system testing is prepared in this phase.
High-level design: This phase can also be called as high-level design. The baseline in selecting
the architecture is that it should realize all which typically consists of the list of modules, brief
functionality of each module, their interface relationships, dependencies, database tables,
architecture diagrams, technology details etc. The integration testing design is carried out in this
phase.
Low-level design: This phase can also be called as low-level design. The designed system is
broken up in to smaller units or modules and each of them is explained so that the programmer
can start coding directly. The low level design document or program specifications will contain a
detailed functional logic of the module, in pseudo-code - database tables, with all elements,
including their type and size - all interface details with complete API references- all dependency
issues- error message listings- complete input and outputs for a module. The unit test design is
developed in this stage."
Waterfall Model:

The waterfall model is a popular version of the systems development life cycle model for
software engineering. Often considered the classic approach to the systems development life
cycle, the waterfall model describes a development method that is linear and sequential.
Waterfall development has distinct goals for each phase of development. Imagine a waterfall on
the cliff of a steep mountain. Once the water has flowed over the edge of the cliff and has begun
its journey down the side of the mountain, it cannot turn back. It is the same with waterfall
development. Once a phase of development is completed, the development proceeds to the next
phase and there is no turning back.
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.
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.
Stages: Project Planning -> Requirements definition -> Design -> Development -> Integration
and Testing -> Installation/Acceptance -> Maintenance

Spiral Model:

There are four phases in the "Spiral Model" which are: Planning, Evaluation, Risk Analysis and
Engineering. These four phases are iteratively followed one after other in order to eliminate all
the problems, which were faced in "The Waterfall Model". Iterating the phases helps in
understating the problems associated with a phase and dealing with those problems when the
same phase is repeated next time, planning and developing strategies to be followed while
iterating through the phases.
Agile Process:

Agile aims to reduce risk by breaking projects into small, time-limited modules or time boxes
("iterations") with each iteration being approached like a small, self-contained mini-project, each
lasting only a few weeks. Each iteration has its own self-contained stages of analysis, design,
production, testing and documentation. In theory, a new software release could be done at the
end of each iteration, but in practice the progress made in one iteration may not be worth a
release and it will be carried over and incorporated into the next iteration. The project's priorities,
direction and progress are re-evaluated at the end of each iteration.

Test life cycle:

1. Test Requirements stage - Requirement Specification documents, Functional Specification
documents, Design Specification documents (use cases, etc), Use case Documents, Test Traceability Matrix for identifying Test Coverage.
2. Test Plan - Test Scope, Test Environment, Different Test phase and Test Methodologies,
Manual and Automation Testing, Defect Management, Configuration Management, Risk
Management, Evaluation & identification Test, Defect tracking tools, test schedule, resource
allocation.
3. Test Design - Traceability Matrix and Test coverage, Test Scenarios Identification & Test Case
preparation, Test data and Test scripts preparation, Test case reviews and Approval, Base lining
under Configuration Management.
4. Test Environment Setup - Test Bed installation and configuration, Network connectivity's, All
the Software/ tools Installation and configuration, Coordination with Vendors and others.
5. Test Automation - Automation requirement identification, Tool Evaluation and Identification,
Designing or identifying Framework and scripting, Script Integration, Review and Approval,
Base lining under Configuration Management.
6. Test Execution and Defect Tracking - Executing Test cases, Testing Test Scripts, Capture,
review and analyze Test Results, Raise the defects and tracking for its closure.
7. Test Reports and Acceptance - Test summary reports, Test Metrics and process Improvements
made, Build release, Receiving acceptance.
Bug Life Cycle

Some terminologies in the Defect / Bug life cycle.

Bug:

Product is still not yet released in the market. Found before production.
Defect:

Product is released in the market. Found after production.

Defect States:

States:
-Open
-Fixed
-Verified
-Closed
-Double/Duplicate
-Reject (Works as per Requirements, wont fix, works for me)
Defect Content:

Defect heading: IE Error. Error Loading https://localhost:10000/index.cgi Connection refused

Hardware Used:
Software version:
Environmental parameters:
Failed Test case ID:
Failed Requirement Id:
Occurrence: Repeatable/Random
Severity:
Keyword/Responsible:
Steps to Reproduce the Problem:
Expected Result: IE login page should be displayed.
Actual Result: Error is displayed. Error Loading https://localhost:10000/index.cgi Connection
refused
Screenshots if any:
Log files if any:
Time stamp for crash defects:
Severity:

Severity refers to the level of impact, the defect has created on the users. This is set by the tester.
Below are some of the common types.
Unacceptable Risk/Blocker: Crash or A risk to the patient/user, operator, service personnel, etc.
Creates a Safety Risk
Design NC/Critical: Non-conformance to design input (product specification)
Improvement Opportunity: Observations that do not represent a Design Defect or belong to any

of the previous classes

- Enhancements
- Productivity Opportunities
However this varies from company to company.
Priority:

Priority refers to the "Urgency" with which the incident has to be fixed. This is set by the lead.
In most of the cases a critical incident can be of high priority.
Defect example for each severity:

Unacceptable Risk - In a patient monitoring system if the Product /application Crashes, Incorrect
parameter value (ex. Instead of 60 Heart Rate 80 Heart Rate is displayed)
Design NC - Patient information not displayed under User Information.
Minor Issue - IP address textbox should be grayed out when DHCP is selected
Improvement Opportunity - Some cosmetic defect which is negligible. ex. when a sub-menu is
opened the borders of the sub-menu is cut off. or Documentation Issue.
What to do when a defect is not reproducible:
1. Test on another setup.
2. Take pictures and video the first time the defect occurs.
3. Save and Attach the Log file.