SQA-Lecture-4.pptx

Software Quality Assurance
and Testing
Lecture 4
Software Quality Assurance
Software Quality Assurance (SQA)
Plans

Software Quality Assurance an overview 2
Outline
 Cost of Quality
 Definitions
 Purpose of SQA Plan
 Contents of SQA Plan

Cost of Quality
 Cost of quality --> includes all costs incurred in the pursuit of
quality or perform quality related work
 Prevention costs include
 quality planning
 formal technical reviews
 test equipment
 Training
 Internal failure costs include
 rework
 repair
 failure mode analysis
Software Quality Assurance & Testing 3
External failure costs are
 complaint resolution
 product return and
replacement
 help line support
 warranty work

Definitions
 Software Quality Assurance
 “Set of systematic activities providing evidence of the
ability of the software process to produce a software
product that is fit to use”
G. Schulmeyer and J. McManus, Software Quality Handbook, Prentice Hall, 1998.
 Quality assurance plan is the central aid for planning and
checking the quality assurance.

Purpose of SQA Plan
 This document describes the procedures and control
methods to obtain the desired quality level of the end
products and the process by which these end products
are created.
 This document serves as a guide for the managers and
developers of the project.
 It should be produced very early in software
development project.
 It may not exists as a separate document, it could be
incorporated into project’s software development plan.

Contents of SQA Plan
Purpose of Plan
„
Referenced
documents
„
Management †
Documentation
Standards,
Practices and
Conventions
„
Reviews and
Audits
Configuration
Management
„
Problem
Reporting and
Corrective
action
Tools,
Techniques and
Methodologies
Code Control Media Control Supplier control
Records
Collection,
Maintenance
and Retention

Purpose
 States the specific purpose and scope of the SQA plan.

„
Referenced Documents
 A complete list of the documents referenced in the
plan.
 For e.g.,
 Project Overview version 1.0
 Project Plan version 1.0
 Software Requirements Specification
 IEEE Guide for Software Quality Assurance Planning

Management
 IEEE standard lays down three aspects:
 Organization structure
 Hierarchy
 SQA tasks
 Preparing :
 SRS, SQA plan, software development plan,
 Software requirement review,
 Software test plan,
 Draft support documents, e.g., user manuals etc,
 Design reviews

Management Cont’d
 Roles and responsibilities related to product quality
 The project managers and design/development teams have primary
responsibility for the quality controls.
The quality manager will:
 Define the responsibilities of quality personnel
 Agree to quality plan with project manager
 Approve the plan of audit
 Resolves disagreement between project manager and quality
personnel
 Reviews the activities performed
 Review the contents of quality procedures, software standards, etc.

Management Cont’d
 Quality personnel will:
 Carry out internal audit of the project
 Agree on corrective actions
 Evaluate defect trends and take appropriate actions
 Refer and unresolved discrepancies to the quality
manager for resolution.

Documents
 Purpose of this section is to describe the
documentation to be produced and how it is to be
reviewed.
 Software requirement specification
 Software design specification
 Software verification plan
 Software quality objectives

Standards, Practices and
Conventions
 SQA plan should contain the following:
 Documentation standards
 Coding standards
 Commentary standards

Reviews and Audits
 This section states that which technical and managerial
reviews will be undertaken and how they will be carried
out.
 The ANSI standard (American National Standards
Institute) suggests following:
 SRS review
 Preliminary design review
 Critical design review
 Software verification review , etc.

Problem Reporting, Tracking, and
Resolving
 Describe the practices and procedures to be followed
for reporting, tracking, and resolving problems
 Who can report a problem?
 How is it reported?
 How is it tracked?
 Who determines if it is a problem that going to be resolved?
 How is it assigned for resolution?
 How does the person indicate it has been corrected?
 Who reviews it to determine if it can be closed?

Problem Reporting and Corrective Action
 This section describes the system which ensures that software
problems are documented and resolved
 All the problems should be
 Promptly reported at appropriate level, acted upon and resolved.
 Should be capable of being tracked throughout the lifecycle.
 Should be analyzed to determine its significance and causes and
classified according t category.
 Should have security level and priority number.
 Some corrective action and target completion date should be
identified.
 Informed to appropriate level of management.
 Corrective action taken will be evaluated to ensure that it solved the
problem without introducing any more problems.

Tools, techniques, training
 What tools?
 e.g., excel spreadsheet for problem reporting/tracking, ...
 What techniques?
 e.g., formal peer review for deliverables, checklists for
defect detection, ...
 What training is needed on tools, techniques?

Configuration Management
 Software configuration management has four major
activities:
 Identification
 Refers to the general structure of the product being produced
and how the items (modules, classes) are to be identified
 Control
 Refers to the methods to be implemented for the management
and technical control of configuration items.

Configuration Management
 Status accounting
 Refers to reporting to all concerned –management, client and
technical- information describing items and their status
 Auditing
 Refers to activities, which are designed to assure the
correct functioning of SCM system

Code Control
 It is implemented in conjunction with library function
The library
 Receives and maintains copies of all the software tools
and documentation.
 It will issue all the material and ensure that most recently
authorized version is the one available.
 Access is controlled to ensure that no unauthorized use
or modification takes place.
 It also ensures that correct version of software is
submitted for testing.

Media Control
 This section describes how the media are to be protected
from unauthorized access or damage . At least one backup
copy of the current configuration should be held safely in a
remote off-site location . Security threats to the software
project come from the following environment factors.
 Fire damage
 Water damage
 Energy variation
 Unauthorized intrusion
 Viruses
 Misuse of software, data and services

Records Collection, and Maintenance
 It is necessary to ensure the availability of all records
and documents quickly and efficiently when required
This section will identify who is responsible for ensuring
that the appropriate documents will be produced and
stored

Supplier Control
 This is in relevance when outsourcing some of the
components of the project. It is important to ensure that
the externally developed software is of appropriate quality.
Under CMM-1 “Supplier Agreement Management” is a new
area. This section describes how
 To ensure that sub-contractors implement a QA plan.
 The software received must be evaluated and tested before
use.
 In some cases like re-usable objects little can be done. Same
is the case with Operating Systems. If the supplier is in
dominant economic position he supplies on “ take it or
leave it” basis.

SQA-Lecture-4.pptx

Related slideshows

More Related Content

SQA-Lecture-4.pptx