Lecture Software process improvement: Lesson 2 - Dr. Ghulam Ahmad Farrukh

Software Quality Assurance
Lecture # 2

1


SQA Lecture Agenda
•
•
•
•
•

Quality and its need
SQA tasks
SQA group skills and responsibilities
SQA Reviews
SQA Reporting

2


Software Quality
• Low levels of defects when deployed, 
ideally approaching zero
• High reliability, or the capability of running 
without crashes or strange results

3

Why Software Quality? ­ 1
• Reduces time to market for new products
• Enhances market share compared to direct 
competitors
• Minimizes “scrap and rework” expenses
• Attracts and keeps “top­gun” personnel
• Minimizes the risk of serious litigation
4


Why Software Quality? ­ 2
• Minimizes the risk of serious operating 
failures and delays
• Minimizes the risk of bankruptcy or 
business failures, which may be attributed 
directly to poor quality or poor software 
quality

5


Cost to Find and Fix a Defect
100

60.00­100.00

log
scale

10.00

10

1

1.00
0.75

1.50

3.00

test
Design
field
system
Req.
use
code
test


Software Quality Assurance
• So, there is a need for a active and 
independent group within every 
organization, who is devoted to assuring 
quality of software products
• This group is called SQA

7

Goals of SQA ­ 1
• To improve software quality by 
appropriately monitoring both the software 
and development process that produces it
• To ensure full compliance with the 
established standards and procedures for the 
software and the software process

8


Goals of SQA ­ 2
• To ensure that any inadequacies in the 
product, the process, or the standards are 
brought to management’s attention so they 
can be fixed

9


SQA in pictorial form

10


Software Quality Assurance
Process
Formal

Definition & Technical
Standards
Reviews
Analysis
&
Reporting

Test 
Planning
Measurement & Review


Skills of SQA Group
•
•
•
•

Statistical methods
Quality control principles
Software process
An ability to deal effectively with people in 
contentious situations

12


Role of SQA
• The people responsible for the software 
projects are the only people who can be 

held responsible for the quality of software
• The role of SQA is to monitor the way these 
groups perform their responsibilities
• This seems like a contradiction
13


Pitfalls
• 1. It is a mistake to assume that the SQA 
people themselves can do anything about 
quality
• 2. The existence of an SQA group does not 
ensure that the standards and procedures are 
followed

14


Pitfalls
• 3. Unless management periodically 
demonstrates its support for SQA by 
following their recommendations, SQA will 
be ineffective
• 4. Unless line management requires that 
SQA try to resolve their issues with project 
management before escalation, SQA and 
development will not work together 
effectively
15

SQA Responsibilities

16


SQA Responsibilities ­ 1
• Review all development and quality plans 
for completeness
• Participate as inspection moderators in 
design and code inspections
• Review all test plans for adherence to 
standards

17


SQA Responsibilities ­ 2
• Review a significant sample of all test 
results to determine adherence to plans
• Periodically audit SCM performance to 
determine adherence to standards
• Participate in all project quarterly and phase 
reviews and register non­concurrence if the 
appropriate standards and procedures have 
not been reasonably met
18


SQA Reviews

19


What is a Review?
• A process or meeting during which a work 
product, or a set of work products, is 
presented to project personnel, managers, 
users, or other interested parties for 
comment or approval.  Types include code 
review, design review, formal qualification 
review, requirements review, test readiness 
review
– IEEE Std. 610.12­1990 
20


Objectives of Formal Technical 
Reviews (FTRs)

21


Objectives of FTR ­ 1
• Uncover errors in function, logic, or 
implementation for any representation of 
the software
• To verify that the software under review 
meets its requirements
• To ensure that the software has been 

represented according to predefined 
standards
22


Objectives of FTR ­ 2
• To achieve software that is developed in a 
uniform manner
• Make projects more manageable
• Ownership transfers from individual to 
group
23


Objectives of FTR ­ 3
• In addition, the FTR serves as a training 
ground, enabling junior engineers to 
observe different approaches to software 
analysis, design, and implementation
• Also serves as a means of corporate backup

24


What Technical Reviews Are 
Not!
•
•
•
•

A project budget summary
A scheduling assessment
An overall progress report
A mechanism for reprisal or political 
intrigue!!

25