2. Importance of SQAP
SQA plan provides a road map for instituting software quality
assurance.
The plan serves as a template for SQA activities that are
instituted for each software project.
define the techniques, procedures, and methodologies that
will be used to assure timely delivery of the software that
meets specified requirements within project resources.
3. Software Quality Assurance Planning
What is not tracked is not done”
The Goals of Software Quality Assurance:
To improve software quality by appropriately monitoring both the
software and the development process that produces it.
To ensure full compliance with the established standards and
procedures for the software and the software process.
To ensure that any inadequacies in the process, product and standards
are brought to managements attention so that these inadequacies can
be fixed
4. Software Quality Assurance Plan
For each development project the SQAP specifies:
Its goals
SQA tasks to be performed
Standards against which development work is to be measured
Software quality organizational structure
Software quality procedures
5. IEEE Standard for SQAP
IEEE Std 730-1989
Standard for Software Quality Assurance Plans
IEEE Guide for Software Quality Assurance Planning
6. IEEE 730-1989 Standard for Software Quality
Assurance Plans
1. Purpose
2. Reference Documents
3. Management
4. Documentation
5. Standards, Practices, Conventions and Metrics
6. Reviews and Audits
7. Test
8. Problem Reporting and Corrective Action
9. Tools, Techniques, and Methodologies
10. Code Control
11. Media Control
12. Supplier Control
13. Records Collection
14. Training
15. Risk Management
7. Contents of SQA Plan - Purpose
Purpose
Describes the purpose of the project SQAP
List software covered by SQAP
State portion of software life cycle covered
Measurable Objectives
Answers the following:
What is the intended use of the software (criticality, interfaces etc…)?
What is the scope of this SQAP?
How will this plan contribute to the success of the project?
Name the SDLC that applies to the project and deviations.
8. Contents of SQA Plan – Purpose (Measurable
Objectives)
Example Objectives
Technical review of all project documents
Ensure maximum inspection rates of 6 pages/hour for
documentation and 200 LOC/hour for code.
Have a process defect yield of 99.9% before delivery.
Have a delivered defect density < 1 defect/1000 LOC for first
12 months of operation
9. Contents of SQA Plan – Reference
Documents
Reference Documents
complete list of documents referenced elsewhere in the SQAP
For example:
Standards and guidelines
10. Contents of SQA Plan – Management
organization - depict structure of org.
responsibilities
tasks
tasks to be performed
relationship between tasks and checkpoints
sequence of tasks
responsibilities
of each organizational unit
11. Contents of SQA Plan – Documentation
identify required documents
state how documents will be evaluated
minimum documents required by IEEE 730
SRS - Software Requirements Specification
SDD - Software Design Description
SVVP – S. Verification and Validation Plan
SVVR - S. Verification and Validation Report
User documentation - manual, guide
SCMP – S. Configuration Management Plan
12. Contents of SQA Plan – Standards, Practices,
Conventions and metrics
Identify S,P,C,and M to be applied
How compliance is to be monitored and assured
Minimum
documentation standards, logic structure standards, coding standards,
testing standards
List Selected SQA product and process metrics
Defects Found, Change Activity, Software Structure, Availability,…
Must be related to measurable objectives in Purpose Section.
13. Contents of SQA Plan – Reviews and
Audits
purpose
define what reviews/audits will be done
how they will be accomplished
what further actions are required
Minimum
Software Requirements Reviews
Preliminary Design Review
evaluate technical adequacy of top-level design
14. Min Set of Reviews/Audits
Critical Design Review
acceptability of detailed designs
Software Verification and Validation Plan Review
adequacy of planned verification and validation
Functional Audit
all requirements in SRS have been met
Physical Audit
software and documents are consistent and ready
In-Process Audit
Managerial Reviews
15. Test and Problem Reporting
Contents of SQA Plan – Test
Identify all tests that are not included in SVVP for the software
covered by the SQAP and shall state the methods to be used.
Contents of SQA Plan – Problem Reporting
Practices and Procedures for reporting, tracking, and resolving
problems
Organizational responsibilities
16. Tool, Techniques etc
Contents of SQA Plan – Tools, Techniques and Methodologies
identify the special software tools, techniques and
methodologies
purpose
describe use
17. Code Control
The purpose of this section is to define the methods and facilities used to
maintain, store, secure and document controlled versions of the identified
software.
Code control includes the items listed below:
Identifying, labeling, and cataloging the software to be controlled
Identifying the physical location of the software under control
Identifying the location, maintenance, and use of backup copies
Distributing copies of the code
Identifying the documentation that is affected by a change
Establishing a new version
Regulating user access to the code.
18. Media Control
Media control includes the items listed below:
Regularly scheduled backup of the media.
Labeled and inventoried media filed in a storage area in
accordance with security requirements and in a controlled
environment that prevents degradation or damage to the
media.
Adequate protection from unauthorized access.
19. Supplier Control
The purpose of this section is to state the provisions by which
SQA assures that software provided by suppliers meets
established requirements.
20. Records - collection, maintenance, and
retention
Identify the SQA documentation to be retained, state the methods
and facilities to be used to assemble, safeguard, and maintain this
documentation, and designate the retention period.
SQA activities are documented by records and reports that provide
a history of product quality throughout the software life cycle.
Measurement data collected will be reviewed for trends and
process improvement.
21. Training
Identify the training activities necessary to meet the needs of the
SQA Plan.
provides a matrix that identifies the required skills to perform
SQA tasks to implement this SQA Plan.
The training schedule will be compatible with the project
schedule
In some cases, training will be conducted as On-the-Job (OJT)
training
22. Risk Management
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 SQA Plan
SQA will review and evaluate the technical risk analysis and
any risk reduction plan
SQA reporting will confirm that the identified risks are
managed in accordance with the provisions of the project’s
risk management plans.
23. Standards
Standards provide a basis against which activities can be
measured and evaluated
Document, established by consensus and approved by a
recognized body, that provides, for common and repeated
use, rules, guidelines or characteristics for activities or their
results, aimed at the achievement of the optimum degree of
order in a given context. (ISO – International Organization for
Standardization)
24. Types of Standards
Regulatory Standards - imposed by Government legislation
or regulation;
Speed Limits;
Electric Voltages for Distribution;
Some Communications standards.
Consensus Standards - adopted by a community of interest
to further the interests of the community
most professional Standards and many manufacturing Standards.
25. Types of Standards
External Standards - define the ways in which an
organisation relates to its clients and competitors.
e.g. AS 3563; ISO 9001; ANSI/IEEE 730 etc.
Internal Standards - define the practices and
procedures in place within an organisation.
26. Focus of Standards
Standards which define in detail a specific product .
Standards which define the process through which
products in the field need to pass.
Standards which define requirements for a particular
resource to be used in the development process.
27. The Language of Standards
“shall” or “shall not”
to indicate requirements strictly to be followed in order to conform to the
standard and from which no deviation is permitted.
“should” or “should not”
to indicate that among several possibilities one is recommended as particularly
suitable, or that a certain course of action is preferred but not necessarily
required.
“may” or “need not”
to indicate a course of action permissible within the limits of the standard.
“can” or “cannot”
for statements of possibility and capability, whether material, physical or causal.
28. Sources of Standards
International Standards
The International Organisation for Standardisation (ISO)
The International ElectroTechnical Commission (IEC).
Other bodies concerned with international standards exist but
normally have a limited scope of interest (e.g. the International
Telecommunications Union (ITU); Internet Standards Group;
etc.)
29. Sources of Standards
In Information Technology, the ISO and IEC have set up a
Joint Technical Committee, JTC1.
JTC1 operates through a series of sub-committees
Sub-committee 7 (JTC1/SC7) is responsible for Software
Engineering Standards
30. Sources of Standards
In-house Development
Standards from whatever source may need to be tailored or
adapted to an individual companies needs.
Three Major Approaches
Ad Hoc standardization
Standards Groups
Standards Committees
31. The Standards Process – usually
followed
Formulation
Definition
Approval
Implementation
Comment
32. Areas of Standardization in Software
Development examples
Software Development Life Cycle standards
Documentation
Coding standards
Naming standards
Operating Procedures and Protocols
User Development