SDLC Vs STLC

SDLC (Software Development Life Cycle)

SDLC, Software Development Life Cycle is a process used by software industry to design, develop and test high quality softwares. The SDLC aims to produce a high quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates.

SDLC is the acronym of Software Development Life Cycle.

It is also called as Software development process. 

The software development life cycle (SDLC) is a framework defining tasks performed at each step in the software development process. 

ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be the standard that defines all the tasks required for developing and maintaining software. 

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. 

 

SDLC Iterative Model

Following is the pictorial representation of Iterative and Incremental model:

This model is most often used in the following scenarios:

Requirements of the complete system are clearly defined and understood.

Major requirements must be defined; however, some functionalities or requested enhancements may evolve with time.

There is a time to the market constraint.

A new technology is being used and is being learnt by the development team while working on the project.

Resources with needed skill set are not available and are planned to be used on contract basis for specific iterations.

There are some high risk features and goals which may change in the future.

 

SDLC Spiral Model

The spiral model has four phases. A software project repeatedly passes through these phases in iterations called Spirals.

Identification:This phase starts with gathering the business requirements in the baseline spiral. In the subsequent spirals as the product matures, identification of system requirements, subsystem requirements and unit requirements are all done in this phase.

This also includes understanding the system requirements by continuous communication between the customer and the system analyst. At the end of the spiral the product is deployed in the identified market. 

Design:Design phase starts with the conceptual design in the baseline spiral and involves architectural design, logical design of modules, physical product design and final design in the subsequent spirals.

Construct or Build:Construct phase refers to production of the actual software product at every spiral. In the baseline spiral when the product is just thought of and the design is being developed a POC (Proof of Concept) is developed in this phase to get customer feedback.

Then in the subsequent spirals with higher clarity on requirements and design details a working model of the software called build is produced with a version number. These builds are sent to customer for feedback.

Evaluation and Risk Analysis:Risk Analysis includes identifying, estimating, and monitoring technical feasibility and management risks, such as schedule slippage and cost overrun. After testing the build, at the end of first iteration, the customer evaluates the software and provides feedback.

Following is a diagrammatic representation of spiral model listing the activities in each phase:

 

V Model

The V - model is SDLC model where execution of processes happens in a sequential manner in V-shape. It is also known as Verification and Validation model. 

V - Model is an extension of the waterfall model and is based on association of a testing phase for each corresponding development stage. This means that for every single phase in the development cycle there is a directly associated testing phase. This is a highly disciplined model and next phase starts only after completion of the previous phase.

The below figure illustrates the different phases in V-Model of SDLC.

 

SDLC Big Bang Model

The Big Bang model is SDLC model where there is no specific process followed. The development just starts with the required money and efforts as the input, and the output is the software developed which may or may not be as per customer requirement.

B ig Bang Model is SDLC model where there is no formal development followed and very little planning is required. Even the customer is not sure about what exactly he wants and the requirements are implemented on the fly without much analysis. 

Usually this model is followed for small projects where the development teams are very small.

 

Agile Model

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. 

 

RAD Model

Following image illustrates the RAD Model:

Following are the typical scenarios where RAD can be used:

RAD should be used only when a system can be modularized to be delivered in incremental manner.

It should be used if there.s high availability of designers for modeling.

It should be used only if the budget permits use of automated code generating tools.

RAD SDLC model should be chosen only if domain experts are available with relevant business knowledge.

Should be used where the requirements change during the course of the project and working prototypes are to be presented to customer in small iterations of 2-3 months.

Software Prototyping

The Software Prototyping refers to building software application prototypes which display the functionality of the product under development but may not actually hold the exact logic of the original software.

Software prototyping is becoming very popular as a software development model, as it enables to understand customer requirements at an early stage of development. It helps get valuable feedback from the customer and helps software designers and developers understand about what exactly is expected from the product under development.

Following is the stepwise approach to design a software prototype:

Basic Requirement Identification: This step involves understanding the very basics product requirements especially in terms of user interface. The more intricate details of the internal design and external aspects like performance and security can be ignored at this stage. 

Developing the initial Prototype: The initial Prototype is developed in this stage, where the very basic requirements are showcased and user interfaces are provided. These features may not exactly work in the same manner internally in the actual software developed and the workarounds are used to give the same look and feel to the customer in the prototype developed. 

Review of the Prototype:The prototype developed is then presented to the customer and the other important stakeholders in the project. The feedback is collected in an organized manner and used for further enhancements in the product under development.

Revise and enhance the Prototype: The feedback and the review comments are discussed during this stage and some negotiations happen with the customer based on factors like , time and budget constraints and technical feasibility of actual implementation. The changes accepted are again incorporated in the new Prototype developed and the cycle repeats until customer expectations are met. 

STLC (Software Testing Life Cycle)

Contrary to popular belief, Software Testing is not a just a single activity. It consists of series of activities carried out methodologically to help certify your software product. These activities (stages) constitute the Software Testing Life Cycle (STLC).

The different stages in Software Test Life Cycle -

Each of these stages have a definite Entry and Exit criteria  , Activities & Deliverable associated with it.

In an Ideal world you will not enter the next stage until the exit criteria for the previous stage is met. But practically this is not always possible. So for this tutorial , we will focus of activities and deliverables for the different stages in STLC. Lets look into them in detail.

 

Requirement Analysis

During this phase, test team studies the requirements from a testing point of view to identify the testable requirements. The QA team may interact with various stakeholders (Client, Business Analyst, Technical Leads, System Architects etc) to understand the requirements in detail. Requirements could be either Functional (defining what the software must do) or Non Functional (defining system performance /security availability ) .Automation feasibility for the given testing project is also done in this stage.

Activities

· Identify types of tests to be performed. 

· Gather details about testing priorities and focus.

· Prepare Requirement Traceability Matrix (RTM).

· Identify test environment details where testing is supposed to be carried out. 

· Automation feasibility analysis (if required).

Deliverables 

· RTM

· Automation feasibility report. (if applicable)

 

Test Planning

This phase is also called Test Strategy phase. Typically , in this stage, a Senior QA manager will determine effort and cost estimates for the project and would prepare and finalize the Test Plan.

Activities

· Preparation of test plan/strategy document for various types of testing

· Test tool selection 

· Test effort estimation 

· Resource planning and determining roles and responsibilities.

· Training requirement

Deliverables 

· Test plan /strategy document.

· Effort estimation document.

 

Test Case Development

This phase involves creation, verification and rework of test cases & test scripts. Test data , is identified/created and is reviewed and then reworked as well.

Activities

· Create test cases, automation scripts (if applicable)

· Review and baseline test cases and scripts 

· Create test data (If Test Environment is available)

Deliverables 

· Test cases/scripts 

· Test data

 

Test Environment Setup

Test environment decides the software and hardware conditions under which a work product is tested. Test environment set-up is one of the critical aspects of testing process and can be done in parallel with Test Case Development Stage. Test team may not be involved in this activity if the customer/development team provides the test environment in which case the test team is required to do a readiness check (smoke testing) of the given environment.

Activities 

· Understand the required architecture, environment set-up and prepare hardware and software requirement list for the Test Environment. 

· Setup test Environment and test data 

· Perform smoke test on the build

Deliverables 

· Environment ready with test data set up 

· Smoke Test Results.

 

Test Execution

 During this phase test team will carry out the testing based on the test plans and the test cases prepared. Bugs will be reported back to the development team for correction and retesting will be performed.

Activities 

· Execute tests as per plan

· Document test results, and log defects for failed cases 

· Map defects to test cases in RTM 

· Retest the defect fixes 

· Track the defects to closure

Deliverables 

· Completed RTM with execution status 

· Test cases updated with results 

· Defect reports

 

Test Cycle Closure

Testing team will meet , discuss and analyze testing artifacts to identify strategies that have to be implemented in future, taking lessons from the current test cycle. The idea is to remove the process bottlenecks for future test cycles and share best practices for any similar projects in future.

 

Activities

· Evaluate cycle completion criteria based on Time,Test coverage,Cost,Software,Critical Business Objectives , Quality

· Prepare test metrics based on the above parameters. 

· Document the learning out of the project 

· Prepare Test closure report 

· Qualitative and quantitative reporting of quality of the work product to the customer. 

· Test result analysis to find out the defect distribution by type and severity.

 

Deliverables 

· Test Closure report 

· Test metrics

Finally, summary of STLC along with Entry and Exit Criteria
 

STLC Stage	Entry Criteria	Activity	Exit	Deliverables
			Criteria
Requirement	Requirements	Analyse business	Signed off	RTM
Analysis	Document	functionality to	RTM	Automation
	available	know Test		feasibility
	(both	the  business	automation	report
	functional	modules	feasibility	(if applicable)
	and non	and module	report
	functional)	specific	signed off
	Acceptance	functionalities.	by the
	criteria	Identify all	client
	defined.	transactions
	Application	in the modules.
	architectural	Identify all the
	document	user profiles.
	available.	Gather user
		interface/
		authentication,
		geographic
		spread
		requirements.
		Identify types
		of tests to
		be performed.
		Gather details
		about testing
		priorities and
		focus.
		Prepare
		Requirement
		Traceability
		Matrix (RTM).
		Identify test
		environment
		details where
		testing is
		supposed
		to be carried out.
		Automation
		feasibility
		analysis (if
		required).
Test Planning	Requirements	Analyze various	Approved test	Test plan/
	Documents	testing approaches	plan	strategy
	Requirement	available Finalize	/strategy	document.
	Traceability	on the best suited	document.	Effort
	matrix.Test	approach Preparation	Effort	estimation
	automation	of test plan/	estimation	document.
	feasibility	strategy	document
	document.	document for various	signed off.
		types of testing
		Test tool selection
		Test effort
		estimation Resource
		planning and
		determining
		roles and
		responsibilities.
Test case	Requirements	Create test cases,	Reviewed and	Test cases
development	Documents	automation	signed	/scripts
	RTM and	scripts	test Cases/	Test data
	test plan	(where applicable)	scripts
	Automation	Review and	Reviewed
	analysis	baseline test	and signed
	report	cases and scripts	test data
		Create test data
Test Environment	System Design	Understand the	Environment	Environment
setup	and	required	setup is	ready with test   data set up
	architecture	architecture,	working as	Smoke Test
	documents	environment set-	per the plan	Results.
	are available	up	and checklist
	Environment	Prepare hardware	Test data
	set-up plan is	and software	setup is
	available	requirement list	complete
		Finalize connectivity	Smoke test
		requirements	is successful
		Prepare environment
		setup checklist
		Setup test Environment
		and test data
		Perform smoke test on
		the build Accept/reject
		the build depending on
		smoke test result
Test Execution	Baselined RTM	Execute tests as per	All tests planned	Completed RTM
	, Test Plan ,	plan	are executed	with execution
		Document test results,	Defects logged	status
	Test case/scripts	and log	and tracked to	Test cases
	are available	defects for failed	closure	updated
	Test	cases		with results
	environment is	Update test plans/		Defect reports
	ready Test data	test
	set up is done	cases, if
	Unit/Integration	necessary
	test report	Map defects to test
	for the build	cases in RTM
	to be tested is	Retest the defect
	available	fixes
		Regression testing
		of
		application
		Track the defects to
		closure
Test Cycle	Testing has	Evaluate cycle	Test Closure
closure	been	completion	report signed
	completed	criteria	off by client
	Test results	based on - Time,
	are available	Test
	Defect logs	coverage ,
	are available	Cost , Software
		Quality , Critical
		Business
		Objectives
		Prepare test
		metrics based
		on the above
		parameters.
		Document the
		learning out
		of the project
		Prepare Test
		closure report
		Qualitative and
		quantitative
		reporting
		of quality of the
		work product to
		the customer.
		Test result analysis
		to find out the
		defect distribution
		by type and
		severity