Software Quaity Assurance

8/7/2019 Software Quaity Assurance

1/28

Software Quality AssuranceSoftware Quality Assurance

Software quality assurance is the planned and systematicpattern of actions required to ensure the quality in

software. The term quality assurance includes the

following:

Actions taken to ensure that standards and procedures

are adhered.

Policy, procedures and systematic actions are

established.

Assurance that an appropriate development methodogy

is in place.

Effective reviews and audits conducted.

1


Appropriate documentation to support maintenance

and enhancement.

Setting up the software configuration management to

control the change.

Well-planned testing performed.

2


2/28


Goals Technical risks: deal with the risks such as software

will not perform as indented or be too hard to

operate, modify, and/or maintain.

Programmatic risks such as the project will overrun

cost or schedule.

3


The goals of SQA is to reduce these risks by:

Monitoring the software and development process

appropriately.

Ensuring the compliance with standards and

procedures for software and process.

Ensuring that inadequacies in product, process, or

standards are brought to managements attention so

that they may be fixed.

4


3/28


Responsibilities Prepare SQA plan for the project.

Review all development and quality plans for

completeness.

Participate in the development of the projects

software process description.

Participate as inspection moderators in design and

code inspection.

5


Responsibilities

Review al test plans for adherence to set standards

and procedures.

Review samples of all test results to determine

adherence to pan.

Review all documented procedures.

Review all project phases and write down any non-

compliance.

6


4/28

Software Quality Assurance Life CycleSoftware Quality Assurance Life Cycle

Initialization phase Writing and reviewing management plan

Verifying specified standards, procedures and

processes in plan.

Requirement phase

Assuring that software requirements are complete

and testable.

Assuring that software requirements are properly

expressed as functional, performance and interface

requirements.

7


Preliminary design phase

Assuring adherence to approved design standards as

designed in management plan.

Assuring all software requirements are assigned to

software components etc.

Detailed design phase

Assuring that approved design standards followed.

Assuring that allocated modules and results of design

inspections are included.

8


5/28


Implementation phase Auditing the results of coding and design activities

including schedule in software development phase,

status of all deliverable items.

Auditing configuration management activity and

nonconformance reporting and corrective action

system.

Integration and Testing phase

Assuring readiness of all deliverable of all deliverable

items and after testing, test reports are complete and

correct.

9


Integration and Testing phase

Assuring that all test run according to test plans and

procedures, all nonconformance are reported and

corrected.

Acceptance and delivery phase

Assuring the performance of a final configuration

audits.

Assuring the readiness of all deliverable items.

10


6/28

Software Quality Assurance ProgramSoftware Quality Assurance Program

SQA planning: specifies goals and tasks to beperformed.

Setting up standards and procedures

SQA monitoring and controlling: deals with

configuration management monitoring, verification and

validation monitoring, formal test monitoring.

Testing phase ensures effective error detection

Development and collection of relevant metrics and

models

11


SQA planning

Framework to plan for systematic action necessary to

provide adequate confidence that the item or product

conforms to established technical requirements may

be called software quality assurance plan.

12


7/28


Setting of standards and procedures The established criteria to which the software

products are compared defines the standards.

All processes should have well documented

procedures.

13


SQA Monitoring and Controlling

Software and the development process both need to

be evaluated and monitored to improve the quality of

software.

Ensures the software development and control

processes described in the SPM plan.

Products are monitored to the conformance to

procedures.

14


8/28


Testing Ensures that formal testing is done according to plans

and procedures.

SQA monitors:

Test procedures are in accordance with test plans

Test procedures are verifiable.

Test procedures are followed.

Records the nonconformance occurring during the

testing.

Test reports are accurate and complete. Regression testing conducted to assure

nonconformance has been corrected.

15


Developing and controlling quality metrics and

models

There are many factors that need to be estimated.

Software quality metrics may be used to analyze the

time that needs to be taken for the team to submit a

particular deliverable.

Software metrics should be collected to identify the

possible flaws.

16


9/28

Software Quality Assurance ActivitiesSoftware Quality Assurance Activities

Revision

Process evaluation

Software standards

17


Revision

A draft version of an artifact/document submitted by

the group will be evaluated.

Reviewers are allowed to post their comments about

possible flaws in the documentation.

If there is any contradiction then it is discussed

Review is composed of walkthrough and inspection

18


10/28


Process evaluation SQA team is expected to:

Define the process standards such as how reviews

should be conducted and when reviews should be

held.

Monitor the development process to ensure that the

standards are being followed

Report the software project management and to the

customer.

19


Software standards

Standards provides encapsulation of best or at least

most appropriate practice.

Documentation standards specify form and contents

for planning, control of the documentation.

Design standards specify the form and content of

design of the product and documentation of the

design.

Code standards specify the language in which the codeis to be written and define any restriction on use of

language features.

20


11/28

Software Quality Assurance PlanSoftware Quality Assurance Plan

The purpose of SQAP is to define the techniques,

procedures, and methodologies that will be used to

assure timely delivery of the software that meets

specified requirements within project resources.

21


The basic objective of SQA planning may include to:

Determine if there is a problem

Evaluate the effect of change in the development

process

Examine the effectiveness of testing, inspection, or

other analysis techniques.

22


12/28


The basic objective of SQA planning may include to:1. Overview

1.1 Scope

2.References

3. Definitions and acronyms

3.1Definitions

3.2 Acronyms

4. Software Quality Assurance Plan

23


The basic objective of SQA planning may include to:

4.1 Purpose (Section 1 of the SQAP)

4.2 Reference documents (Section 2 of the SQAP)

4.3 Management (Section 3 of the SQAP)

4.4 Documentation (Section 4 of the SQAP)

4.5 Standards, practices, conventions, and metrics

(Section 5 of the SQAP)

4.6 Reviews and audits (Section 6 of the SQAP)

4.7 Test (Section 7 of the SQAP)

4.8 Problem reporting and corrective action (Section 8 of

the SQAP)

4.9 Tools, techniques, and methodologies (Section 9 of

the SQAP)24


13/28


The basic objective of SQA planning may include to:4.10 Code control (Section 10 of the SQAP)

4.11 Media control (Section 11 of the SQAP)

4.12 Supplier control (Section 12 of the SQAP)

4.13 Records collection, maintenance, and retention


4.14 Training (Section 14 of the SQAP)

4.15 Risk management (Section 15 of the SQAP)

25


1.1 Scope

The purpose of this standard is to provide uniform,

minimum acceptable requirements for preparation and

content of Software Quality Assurance Plans (SQAPs).

26


14/28


3. Definitions and acronyms3.1 Definitions

The definitions listed below establish meaning in the

context of this standard.

3.1.1 branch metric:

The result of dividing the total number of modules in

which every branch has been executed at least once by

the total number of modules.

27


4.1 Purpose (Section 1 of the SQAP)

This section shall delineate the specific purpose and scope

of the particular SQAP. It shall list the name(s) of the

software items covered by the SQAP and the intended

use of the software. It shall state the portion of the

software life cycle covered by the SQAP for each software

item specified.

28


15/28


4.2 Reference documents (Section 2 of the SQAP)This section shall provide a complete list of documents

referenced elsewhere in the text of the SQAP.

4.3 Management (Section 3 of the SQAP)

This section shall describe organization, tasks, and

responsibilities.

4.3.1 Organization

This paragraph shall depict the organizational structure

that influences and controls the quality of the software.

This shall include a description of each major element of

the organization together with the delegated

responsibilities.29


30

Project Manager

Management

Team

Architecture

Team

Development

Team

Assessment

Team


16/28


4.3.2 TasksThis paragraph shall describe

a) That portion of the software life cycle covered by the

SQAP;

b) The tasks to be performed with special emphasis on

software quality assurance activities; and

c) The relationships between these tasks and the planned

major checkpoints.

4.3.3 Responsibilities

This paragraph shall identify the specific organizational

elements responsible for each task.

31


4.4 Documentation (Section 4 of the SQAP)

4.4.1 Purpose

This section shall perform the following functions:

a) Identify the documentation governing the development,

verification and validation, use, and maintenance of the

software.

b) State how the documents are to be checked for

adequacy. This shall include the criteria and the

identification of the review or audit by which theadequacy of each document shall be confirmed, with

reference to Section 6 of the SQAP.

32


17/28


4.4.2 Minimum documentation requirements4.4.2.1 Software Requirements Specification (SRS)

The SRS shall clearly and precisely describe each of the

essential requirements (functions, performances, design

constraints, and attributes) of the software and the

external interfaces.

4.4.2.2 Software Design Description (SDD)

The SDD shall depict how the software will be structured

to satisfy the requirements in the SRS. The SDD shall

describe the components and subcomponents of the

software design, including databases and internalinterfaces.

33


4.4.2.3 Software Verification and Validation Plan

(SVVP)

The SVVP shall identify and describe the methods (e.g.,

inspection, analysis, demonstration, or test) to be used to

a) Verify that

1) The requirements in the SRS have been approved by an

appropriate authority;

2) The requirements in the SRS are implemented in the

design expressed in the SDD; and

3) The design expressed in the SDD is implemented in the

code.

b) Validate that the code, when executed, complies with

the requirements expressed in the SRS.

34


18/28



(SVVP)

The SVVP shall identify and describe the methods (e.g.,

inspection, analysis, demonstration, or test) to be used to

a) Verify that

1) The requirements in the SRS have been approved by an

appropriate authority;

2) The requirements in the SRS are implemented in the

design expressed in the SDD; and

3) The design expressed in the SDD is implemented in the

code.b) Validate that the code, when executed, complies with

the requirements expressed in the SRS.

35


4.4.2.4 Software Verification and Validation Report

(SVVR)

The SVVR shall describe the results of the execution of

the SVVP.

4.4.2.5 User documentation

User documentation (e.g., manual, guide) shall specify and

describe the required data and control inputs, input

sequences, options, program limitations, and other

activities or items necessary for successful execution of

the software.

36


19/28


4.4.2.6 Software Configuration Management Plan

(SCMP)

The SCMP shall document methods to be used for

identifying software items, controlling and implementing

changes, and recording and reporting change

implementation status.

37


4.4.3 Other

Other documentation may include the following:

a) Software Development Plan;

b) Standards and Procedures Manual;

c) Software Project Management Plan;

d) Software Maintenance Manual.

38


20/28


4.5 Standards, practices, conventions, and metrics


4.5.1 Purpose

This section shall

a) Identify the standards, practices, conventions, and

metrics to be applied;

b) State how compliance with these items is to be

monitored and assured.

39


4.5.2 Content

The subjects covered shall include the basic technical,

design, and programming activities involved, such as

documentation, variable and module naming,

programming, inspection, and testing. As a minimum, the

following information shall be provided:

a) Documentation standards;

b) Logic structure standards;

c) Coding standards;

d) Commentary standards;

e) Testing standards and practices;

40


21/28


f) Selected software quality assurance product and

process metrics such as

1) Branch metric;

2) Decision point metric; number of decision points in the

module that have been successfully exercised

3) Domain metric;

4) Error message metric;

5) Requirements demonstration metric.

41


4.6 Reviews and audits (Section 6 of the SQAP)

4.6.1 Purpose

This section shall

a) Define the technical and managerial reviews and audits

to be conducted;

b) State how the reviews and audits are to be

accomplished;

c) State what further actions are required and how they

are to be implemented and verified.

42


22/28


4.6.2 Minimum requirements

As a minimum, the reviews and audits in 4.6.2.1 through

4.6.2.10 shall be conducted.

4.6.2.1 Software Requirements Review (SRR)

The SRR is held to ensure the adequacy of the

requirements stated in the SRS.

43


4.6.2.2 Preliminary Design Review (PDR)

The PDR (also known as the top-level design review) is

held to evaluate the technical adequacy of the preliminary

design (also known as the top-level design) of the

software as depicted in the preliminary software design

description.

4.6.2.3 Critical Design Review (CDR)

The CDR (also known as detailed design review) is held

to determine the acceptability of the detailed software

designs as depicted in the detailed software designdescription in satisfying the requirements of the SRS.

44


23/28



Review (SVVPR)

The SVVPR is held to evaluate the adequacy and

completeness of the verification and validation methods

defined in the SVVP.

4.6.2.5 Functional audit

This audit is held prior to the software delivery to verify

that all requirements specified in the SRS have been met.

4.6.2.6 Physical audit

This audit is held to verify that the software and its

documentation are internally consistent and are ready fordelivery.

45


4.6.2.7 In-process audits

In-process audits of a sample of the design are held to

verify consistency of the design, including the following:

a) Code versus design documentation;

b) Interface specifications (hardware and software);

c) Design implementations versus functional requirements;

d) Functional requirements versus test descriptions.

46


24/28


4.6.2.8 Managerial reviews

Managerial reviews are held periodically to assess the

execution of all of the actions and the items identified in

the SQAP. These reviews shall be held by an

organizational element independent of the unit being

reviewed, or by a qualified third party. This review may

require additional changes in the SQAP itself.

4.6.2.9 Software Configuration Management Plan

Review (SCMPR)

The SCMPR is held to evaluate the adequacy and

completeness of the configuration management methods

defined in the SCMP.

47


4.6.2.10 Post-mortem review

This review is held at the conclusion of the project to

assess the development activities implemented on that

project and to provide recommendations for appropriate

actions.

4.6.3 Other

Other reviews and audits may include the user

documentation review (UDR). This review is held to

evaluate the adequacy (e.g., completeness, clarity,

correctness, and usability) of user documentation.

48


25/28


4.7 Test (Section 7 of the SQAP)

This section shall identify all the tests not included in the

SVVP for the software covered by the SQAP and shall

state the methods to be used.

4.8 Problem reporting and corrective action


This section shall

a) Describe the practices and procedures to be followed

for reporting, tracking, and resolving problems

identified in both software items and the software

development and maintenance process;b) State the specific organizational responsibilities

concerned with their implementation.

49


4.9 Tools, techniques, and methodologies (Section

9 of the SQAP)

This section shall identify the special software tools,

techniques, and methodologies that support SQA, state

their purposes, and describe their use.

50


26/28


4.10 Code control (Section 10 of the SQAP)

This section shall define the methods and facilities used to

maintain, store, secure, and document controlled versions

of the identified software during all phases of the software

life cycle. This may be implemented in conjunction with a

computer program library. This may be provided as a part

of the SCMP. If so, an appropriate reference shall be made

thereto.

51


4.11 Media control (Section 11 of the SQAP)

This section shall state the methods and facilities to be

used to

a) Identify the media for each computer product and the

documentation required to store the media, including the

copy and restore process; and

b) Protect computer program physical media from

unauthorized access or inadvertent damage or

degradation during all phases of the software life cycle.

52


27/28


4.12 Supplier control (Section 12 of the SQAP)

This section shall state the provisions for assuring that

software provided by suppliers meets established

requirements.

In addition, this section shall state the methods that will

be used to assure that the software supplier receives

adequate and complete requirements.

53


4.13 Records collection, maintenance, and

retention (Section 13 of the SQAP)

This section shall identify the SQA documentation to be

retained; shall state the methods and facilities to be used

to assemble, safeguard, and maintain this documentation;

and shall designate the retention period.

4.14 Training (Section 14 of the SQAP)

This section shall identify the training activities necessary

to meet the needs of the SQAP.

54


28/28


4.15 Risk management (Section 15 of the SQAP)

This section shall specify the methods and procedures

employed to identify, assess, monitor, and control areas of

risk arising during the portion of the software life cycle

covered by the SQAP.

55

Documents

Software Quaity Assurance