Software Quality Assurance Activities

<< Quality Assurance Management, Quality Factors

Software Process, PM Process Groups, Links, PM Phase interactions >>

Software Project Management (CS615)

LECTURE # 19

2. Software Development Fundamentals

Technical Fundamentals

2.15

Quality Assurance Management

⇒ Software Quality Assurance Activities

SQA is the process of evaluating the quality of a product and enforcing adherence

to software product standards and procedures. It is an umbrella activity that

ensures conformance to standards and procedures throughout the SDLC of a

software product. There are a large number of tasks involved in SQA activities.

These include:

Formulating a quality management plan

ii.

Applying software engineering techniques

iii.

Conducting formal technical reviews

iv.

Applying a multi-tiered testing strategy

Enforcing process adherence

vi.

Controlling change

vii.

Measuring impact of change

viii.

Performing SQA audits

ix.

Keeping records and reporting

Formulating a Quality Management Plan

One of the tasks of SQA is the formulation of a quality management plan. The

quality management plan identifies the quality aspects of the software product to

be developed. It helps in planning checkpoints for work products and the

development process. It also tracks changes made to the development process

based on the results of the checks. The quality management plan is tracked as a

live plan throughout the SDLC.

ii.

Applying Software Engineering

Application of software engineering techniques helps the software designer to

achieve high quality specification. The designer gathers information using

techniques such as interviews and FAST. Using the information gathered, the

designer prepares project estimation with the help of techniques such as WBS,

SLOC estimation, or FP estimation.

iii.

Conducting Formal Technical Reviews

Formal technical review (FTR) in conducted to assess the quality and design of

the prototype. It is a meeting with the technical staff to discuss the quality

122

Software Project Management (CS615)

requirements of a software product and its design quality. FTRs help in detecting

errors at an early phase of development. This prevents errors from percolating

down to the latter phases and resulting in rework.

iv.

Applying a Multi-tiered Testing Strategy

Software testing is a critical task of SQA activity, which aims at error detection.

Unit testing is the first level of testing. The subsequence levels of testing are

integration testing and system level testing. There are various testing strategies

followed by organization. At times, developers perform unit testing and

integration testing with independence testing support. There are also occasions

where testers perform functional testing and system level testing with developer

support. Sometimes beta testing with selected clients is also conducted to test the

product before it is finally released.

Enforcing Process Adherence

This task of SQA emphasizes the need for process adherence during product

development. In addition, the development process should also adhere to

procedures defined for product development. Therefore, this is a combination of

two tasks, product evaluation and process monitoring.

vi.

Product Evaluation

Product evaluation ensures that the standards laid down for a project are followed.

During product evaluation, the compliance of the software product to the existing

standards is verified. Initially, SQA activities are conducted to monitor the

standards and procedures of the project. Product evaluation ensures that the

software product reflects the requirements identified in the project management

plan.

vii.

Process Monitoring

Process monitoring ensures that appropriate steps to follow the product

development procedures are carried out. SQA monitors processes by comparing

the actual steps carried out with the steps in the documented procedures.

Product evaluation and process monitoring ensure that the development and

control processes described in the project management plan are correctly carried

out. These tasks ensure that the project-re1ated procedures and standards are

followed. They also ensure that products and processes conform to standards and

procedures. Audits ensure that product evaluation and process monitoring are

performed.

viii.

Controlling Change

This task combines human procedures and automated tools to provide a

mechanism for change control. The change control mechanism ensures software

quality by formalizing requests for change, evaluating the nature of change, and

controlling the impact of change. Change control mechanism is implemented

during the development and maintenance stages.

123

Software Project Management (CS615)

ix.

Measuring Impact of Change

Change is inevitable in the SDLC. However, the change needs to be measured and

monitored. Changes in the product or process are measured using software quality

metrics. Software qua1ity metrics helps in estimating the cost and resource

requirements of a project. To control software quality; it is essential to measure

quality and then compare it with established standards. Software qua1ity metrics

are used to evaluate the effectiveness of techniques and tools, the productivity of

development activities and the qua1ity of products. Metrics enables mangers and

developers to monitor the activities and proposed changes throughout the SDLC

and initiate corrective actions.

Performing SQA Audits

SQA audits scrutinize the software development process by comparing it to

established processes. This ensures that proper control is maintained over the

documents required during SDLC. Audits also ensure that the status of an activity

performed by the developer is reflected in the status report of the developer.

xi.

Keeping Records and Reporting

Keeping records and reporting ensure the collection and circulation of information

relevant to SQA. The results of reviews, audits, change control, testing, and other

SQA activities are reported and compiled for future reference.

⇒ Software Review

Software review is an effective way of filtering errors in a software product.

Typically, an error found after the product release costs 50 times as much to

correct as one detected during the design phase.

This means the cost of fixing a defect rises dramatically if it is found late in the

development life cycle of the product. Therefore, you need to filter errors as early

as possible.

Software review is used as a filter at various points of software development.

Reviews conducted at each of these phases, analysis, design, coding, and testing

reveal areas of improvement in the product.

Reviews also indicate those areas that do not need any improvement. You can use

software reviews to achieve consistency and uniformity across products. Reviews

also make the task of product creation more manageable. Some of the most

common software review techniques, practiced across software organizations

include:

a) Inspection

b) Walkthrough

c) Formal technical reviews

a) Inspections

124

Software Project Management (CS615)

Inspections improve the reliability, availability, and maintainability of a

software product. Anything readable that is produced during software

development can be inspected. The readable material can be requirements

specifications, design documents and models, test plans, system

documentation, and user aids. Group inspections enable team members to

exchange knowledge and ideas during an inspection session.

Inspections can be combined with structured, systematic testing to provide a

powerful tool for creating defect-free programs. The inspection activity

follows a specified process and the participants play well-defined roles. An

inspection team consists of three to eight members who play the roles of

moderator, author, reader, recorder, and inspector.

Moderator leads the inspection, schedules meetings, controls meetings, reports

inspection results, and follows up on rework issues. Author creates or

maintains the work product being inspected. Reader describes the sections of

the work product to the team as they proceed through inspection. Recorder

classifies and records defects and issues raised during the inspection. The

moderator might perform this role in a small inspection team. Inspector finds

errors in the product. All participants play the role of inspectors. However,

good inspectors are those who have created the specification for the work

product being inspected. For example, the designer can act as an inspector

during code inspection while a quality assurance representative can act as

standard enforcer. It also helps to have a client representative participate in

requirements specification inspections.

b) Walkthroughs

The term walkthrough refers to a group activity in which the developer of the

product guides the progress of the review. Walkthroughs are less rigorous than

either formal inspections or peer reviews in which the developer plays a more

passive role. Normally walkthroughs turn into a presentation by the author.

The focus of finding errors is diluted. Such misadventures make walkthroughs

usually less successful at detecting bugs than the more formal review

methods.

Two useful walkthrough approaches adopted worldwide are group reviews

with individual preparation and individual peer desk-checks. Group reviews

are not very rigorous like inspections. The group reviews involve many of the

same activities and roles, such as individual preparation and the use of a

moderator and a recorder. Usually the overview meeting and the follow-up

steps are skipped and checklists are used sparingly. At the end, the readers

paraphrase their interpretation of what a program is doing.

125

Software Project Management (CS615)

Individual peer desk-checks are quite cost-effective. Only one person besides

the author examines the material. This approach can be more effective if there

are individuals who are extremely good at finding defects on their own.

Tip:

If someone consistently finds most of the group-identified defects during the

individual preparation step, such a person is fit to perform individual peer

desk-checks.

c) Formal Technical Reviews

One of the most common, yet important, software quality assurance activity

performed is FTR. This activity is performed to check errors in logic,

function, or implementation for any representation of the software.

Using FTR, you can verify whether or not the software product adheres to the

defined standards. FTR is also conducted to check for consistency in the

software product and audit the manageability of the software product. It

includes activities such as walkthrough and inspection.

FTR focuses on specific parts of the software product, such as the

requirements components, detailed design module, and the source code listing

for a module.

FTR also concentrates on the entire product. The participants in FTR are the

developer, the project leader, and all the reviewers.

At the end of the review meeting, the issues recorded are formalized into

review issues list. The minutes of the meeting are summarized into a review

summary report as displayed in table 4.

Technical Review Report

Review Identification

Project Name

Current Phase

Review Number

Product Identification

Item Reviewed

Version No.

Developer

Brief Description

Documents Referred (along with versions, if any)

Start Name

End Time

Review Material Attached: Yes / No

Participants

Role

Preparation Time

126

Software Project Management (CS615)

Total Review Time (No. of Participants * Actual duration of meeting)

Total Review Person Hours

Product Appraisal

Accepted as is ( )

With Minor Modification ( )

Not Accepted Major Revision ( )

Minor Revision ( )

Review Not Completed (Explanation as follows)

Supplementary Material Attached

Issue Lists:

Others

Revise and Reschedule (if required)

Target Date for Next Review

Verification of Defect Closure

Responsibility of:

Planned Date of Verification

Recommended for Release

Signature:

Date:

Table 4: Technical Review Report

Tip:

To prepare realistic schedule, you can collect data from past projects. Speak to related

project managers regarding time estimation for reviews, the review capacity of the

reviewer, and estimates the review effort accordingly.

Most Organizations Are somewhere around this

point

Fastest schedule

(BEST schedule)

Development

Time Time

95% 100%

Percentage of

Defects Removed

127

Table of Contents: