Software Quality

Assurance
By Eng. Hany Kadry
 What Is a Software ?
 IEEE Definition :-

 Software is : computer programs, procedures, and possibly

associated documentation and data pertaining to the
operation of a computer system

 Almost identical to ISO definition

 Computer programs ……… (“the code”)
 Procedures define the order and schedule
 Data necessary for operating the software system ……
(“parameters, codes, …..”)
 Documentations are needed for developers, users,
maintenance personnel
The Nine Causes of Software errors
 Faulty requirements definition
 Client-developer communication failures
 Deliberate deviation from software requirements
 Logical design errors
 Coding errors
 Non-compliance with documentation and coding
instructions
 Shortcomings of the testing process
 Procedure error
 Documentation errors
 Software Quality
 Software quality is defined as : conformance
to explicitly stated functional and performance
requirements, explicitly documented
development standards, and implicit
characteristics that are expected of all
professionally developed software

 Good software engineering practices (GSEP),

reflecting state-of-the-art professional practices,
to be met by the developer even though not
explicitly mentioned in the contract
 Difference Between Quality Control
and Quality Assurance
 Quality control is defined as “a set of activities designed to evaluate
the quality of a developed or manufactured product” (IEEE), in other
words activities whose main objective is the withholding of any
product that does not qualify

 The main objective of quality assurance is to minimize the cost of

guaranteeing quality by a variety of activities performed throughout
the development and manufacturing. These activities prevent the
cause of errors, and detect and correct them early in the
development process

 As a result, QA activities substantially reduce the rate of products

that do not qualify for shipment, and at the same time, reduce the
cost of guaranteeing quality in most cases

 QC activities are only a part of the total range of QA activities

 SQA
 Software quality assurance is :-
a systematic , planned set of actions necessary to
provide adequate confidence that the software
development process or the maintenance
process of a software system product conforms
to established functional technical requirements
as well as with the managerial requirement of
keeping the schedule and operating costs with
the budgetary confines (ISO, CMM)
SQA System Overview
 SQA System Architecture
 An SQA system combines a wide range of SQA
components

 The components are employed to challenge the

multitude of sources of SW errors and to achieve an
acceptable level of SW quality

 Two considerations :-
 Task of SQA is unique due to the specific characteristics of sw
 The environment in which sw development and maintenance is
undertaken directly influence of the SQA components
 SQA System Components
Classes
 Components can be classified into six
classes :-
 Pre-project quality components
 Project lifecycle quality components
 Infrastructure error preventive and improvement
components
 Software quality management components
 Standardization, Certification and SQA assessment
components
 Organizing for SQA – the human components
1- Pre-Project
Components
 1- Pre-Project Components
 Objective is to assure that :-

 (a) the project commitments have been

adequately defined considering :-
 The resources required
 The schedule
 The budget

 (b) the development and quality plans have

been correctly determined
 …. Cont
 These SQA components are meant to
improve the preparatory steps prior to
initiating work on the project itself :-

 Contract review

 Development and quality plans

 Contract review
 SW may be developed within a framework
of :-

 A contract negotiated with a customer

 Internal order originating in another

department :-
 Order of software product to be sold as a package
 An internal software application to be used by the
company
 Contract review …. cont
 In all instances, the development unit is
committed to an agreed-upon :-

 Functional specifications
 Budget
 schedule
 ….. cont
 Accordingly, contract review activities
must include a detailed examination of :-

 (a)- The project proposal draft

 (b)- the contract draft
 …. cont
 Contract review activities specifically include :-

 Clarification of the customer’s requirements

 Review of the project’s schedule and resource
requirement estimates
 Evaluation of the professional staff’s capacity to carry
out the proposed project
 Evaluation of the customer’s capacity to fulfill his
obligations
 Evaluation of development risks
 Development and Quality Plans
 Overview
 Once the contract has been signed or a commitment has
been made to undertake an internal project, a plan is
prepared of the project (“development plan”) and its
integrated quality assurance activities (“quality plan”)

 These plans include additional details and needed

revisions based on prior plans that provided the basis for
the current proposal and contract

Note : it is quite common for several months to pass between

the tender submission and the signing of the contract
 …. cont
 The main issues treated in the development
plan are :-
 Schedules
 Required manpower and hardware resources
 Risk evaluations
 Organizational issues: team members, subcontractors
and partnership
 Project methodology , development tools, ..etc
 Software reuse plans
 …. cont
 The main issues treated in the project’s
quality plan are :-

 Quality goals, expressed in the appropriate

measurable terms
 Criteria for starting , and ending each project
stage
 List of reviews , tests, and other scheduled
verification and validation activities
 2- Software Project
Lifecycle Components
 2- Software Project Lifecycle
Components
 Project lifecycle is composed of two
stages :-

 The development lifecycle stage

 The operation-maintenance stage

 …. cont
 Several SQA components enter the lifecycle at
different points
 They should be planned prior to project’s
initiation. They are :-
 Reviews
 Expert opinion
 Software testing
 Software maintenance
 Assurance of the quality of the subcontractor’s work
and the customer-supplied parts
 Reviews
 The design phase produces a variety of
documents :-
 Design reports
 Software test documents
 Software installation plans
 Software manuals
 Others
 Reviews can be categorized into :-
 Formal design reviews (DRs)
 Peer reviews
Formal Design Reviews (DRs)
 The committee:- senior professionals
including :
 The project leader
 The department manager
 The chief software engineer
 Heads of other related departments
 The majority of participants hold
professional and administrative ranks
higher than the project leader
 The DRs
 The DR report includes a list of required
corrections (“action items”)
 The committee has several options :-
 Immediate approval to continue to the next
development phase
 Approval to proceed after all action items have been
completed and inspected by the committee
representative
 An additional DR is required and scheduled after all
action items have been completed and inspected by
the committee representative
 Peer Reviews
 Are directed at reviewing short, parts of a
report, a coded printout of a software
module

 The main objective is to detect as many

design and programming faults as
possible
 Expert Opinions
 Outside experts
 Useful in the following situations :-

 Insufficient in-house capabilities in a given

area
 In small organization, the expert can join the
DR
 Extreme work pressure
 In case of major disagreement
 Software Testing
 Test cases that represent a variety of
expected scenarios
 All tests should be designed and planned
and approved
 Highly recommended to test by
independent test unit rather than the
project team
 Tests can be manual or automated
 Software Maintenance
Components
 Maintenance services fall into :-
 Corrective maintenance
 Adaptive maintenance (ex: HW change)
 Functionality improvement maintenance (functionality,
performance)

 Pre-maintenance components
 Maintenance contract review
 Maintenance plan

 Software development lifecycle components

3- Infrastructure
Components
 3- Infrastructure components For
Error Prevention and Improvement
 The goals of SQA infrastructure are the
prevention or lowering the software faults
rates
 This class of components include :-
 Procedures and work instructions
 Templates and checklists
 Staff training, retraining and certification
 Configuration management
 Documentation control
 Procedures and Work Instructions

 QA procedures usually provide detailed

definitions for the performance of specific
types of development activities in a way
that assures effective achieving quality
results

 The collection of all SQA procedures is

usually referred as the SQA procedures
manual
 Work Instructions
 Work instructions deal with the application
of procedures adapted to the
requirements of a specific project team,
customer, or other relevant party

 While general methodology is defined in a

procedure, the specific details that allow
its application to a specific project or unit
are often laid out in a work procedure
 Templates & Checklists
 One way to combine higher quality with
higher efficiency is to use supporting
quality devices , such as templates and
checklists
 checklists
 Checklist refers to the list of items
specially constructed for each type of
document, or menu of preparations to be
completed prior to perform an activity
 Staff Training, Instruction and
Certification
 Trained and well-instructed professional staff is the key
to efficient , quality performance

 Within the frame of SQA , keeping an organization’s

human resources knowledgeable and updated at the
level required is achieved by :-
 Training new employees and retraining those who have changed
assignments
 Continuously updating staff with respect to professional
developments
 Certifying employees after their knowledge and ability have been
demonstrated
Prevention & Corrective Actions
 Systematic study of the data collected regarding
instances of failure and success contribute to
the QA :-
 Implementation of changes that prevent similar
failures in the future
 Correction of similar faults founds in other projects
 Implementing proven successful methodologies to
enhance the probability of repeat successes

 The source of data are design review reports,

software test reports, and customer
complaints…
 Configuration Management
 The regular software development and
maintenance operations involve intensive
activities that modify software to create new
versions and releases
 Different team members carry out these
activities simultaneously
 As a result serious dangers arise …!!
 CM deals with these hazards by introducing
procedures to control the change process
 ….. cont
 CM procedures relate to :-
 The approval of change
 The recording of the changes
 The issuing of new SW versions and releases
 The recording of the versions and releases
specifications of SW installed in each site
 The prevention of any changes in approved versions
and releases once they are issued

 Most CM systems implement computerized tools

 Documentation Control
 SQA requires the application of measures to
ensure the efficient long-term availability of
major documents related to software
development (“controlled documents”)

 Controlled documents contain information

important to the long-term development and
maintenance of the software system such as :-
 SW test results
 Design review (DR) reports
 Problem reports
4- Management SQA
Components
4-Management SQA Components
 Supports the managerial control of
software development projects and
maintenance services. They include :-

 Project progress control

 SW quality metrics
 SW quality costs
 Project Progress Control
 The main objective of project progress control is
to detect the appearance of any situation that
may induce deviations from the project’s plan
and maintenance service performance. Project
progress control activities focus on :-

 Resource usage
 Schedules
 Risk management activities
 The budget
 Software Quality Metrics
 The measurements apply to the functional
quality, productivity, and organizational aspects
of the project
 SW quality metrics are :-

 Quality of SW development & maintenance activities

 Development team’s productivity
 Helpdesk and maintenance team’s productivity
 SW faults density
 5- SQA Standards, System
Certification, and Assessment
Components
5- SQA Standards, System Certification,
Assessment Components
 External tools offer another avenue to achieving
the goal of SQA
 The main objectives of this class of
components are :-

 Utilization of international professional knowledge

 Improvement of coordination with other organizations’
quality systems
 Objective professional evaluation and measurement
of the achievements of the organization’s quality
systems
 Standards available
 The standards available may be classified into two main
sub-classes :-

 Quality management standards :- focus on the “what” is

required and leave the “how” to achieve it to the organization :-
 SEI CMM assessment standard
 ISO 9001 and ISO 9000-3 standards

 Project process Standards :- methodological guidelines

(dealing with the “how”) for the development team :-
 IEEE 1012 standard
 ISO/IEC 12207 standard
 6- Organizing for SQA
The Human Components
 6- Organizing For SQA
The Human Components
 SQA cannot be applied in an
organizational vacuum: they require an
organizational base
 The base (organizational SW quality
framework) includes :-
 Organization’s management
 SQA Unit and SW testing personnel
 Mission of The Organizational Base
 Develop and support implementation of SQA
components

 Detect deviations from SQA procedures and

methodology

 Suggest improvements to the SQA components

Note : although the entire organizational base shares these

objectives, each segment of the organizational base
concentrates on specific tasks
 Management’s Role in SQA
 The responsibilities of top management (through
the executive in charge of SW quality),
departmental management and project
management include the following:
 Definition of the quality policy
 Effective follow-up of quality policy implementation
 Allocation of sufficient resources to the
implementation of the quality policy
 Assignment of adequate staff
 Follow-up compliance
 The SQA Unit
 This unit and SW testers devote their full
time to SQA matters :-
 Preparation of annual quality programs
 Consultation with in-house staff and outside
experts on SW quality issues
 Conduct of internal QA audits
 Support of existing quality assurance
infrastructure components and their updates,
and development of new components
Software Quality Metrics
 Metrics Classifications
 First classification distinguishes between
the development lifecycle and other
phases of a software system :-

 Process metrics ……….. Development

 Product metrics ……….. Maintenance

 …. cont
 The second classification category refers
to the subject of the measurement :-

 Quality
 Timetable
 Effectiveness (of error removal)
 productivity
 Estimating the Software Size

 KLOC (thousands of code lines)

 Depends on the programming language

 FP (function points)
 Does not depend on the programming
language
Sizing … cont
 Process Metrics
 Process metrics categories :-

 SW process quality metrics

 SW process timetable metrics
 Error removal effectiveness metrics
 SW process productivity metrics
 The Function Point Method
 It measures the project/program size by
functionality not by KLOC (the number of
code lines can only be counted after
programming completion which occurs at
a very late stage of the project)
 Function Point Calculation

 FP = CFP X (0.65 + 0.01 X RCAF)

 CFP = Crude Function Point

 RCAF = Relative Complexity Adjustment Factor

Thank You