SQA plan and quality standards

SQA plan

An SQA plan is a document that serves as a road map for software quality assurance on a project. It is prepared by the SQA group (or by the software team where no SQA group exists) and states which quality activities will be carried out, when, by whom, and against which standards.

Contents of an SQA plan (based on the IEEE standard for SQA plans, IEEE 730):

1. Purpose and scope of the plan.
2. Work products covered: description of every work product that falls under SQA (SRS, design, code, test plans, user manual).
3. Applicable standards and practices used during the process.
4. SQA actions and tasks, including reviews and audits, and where they occur in the process.
5. Tools and methods that support SQA tasks.
6. Software configuration management procedures for managing change.
7. Methods for assembling, safeguarding and maintaining quality records.
8. Organizational roles and responsibilities for quality.

Software quality standards

A software quality standard is a documented set of rules, practices or requirements that a software product or process must meet. Standards record best practice, define what "quality" means for the organization, and allow quality to be checked objectively.

Sommerville divides standards into two types:

Important international standards

1. ISO 9000 series (ISO 9001)

   • A generic standard for quality management systems in any industry, including software.
   • Requires the organization to document its processes, follow them, keep records, carry out internal audits, take corrective action and focus on the customer.
   • An external body audits the organization and issues an ISO 9001 certificate.
   • Example: a software company in Kathmandu documents its requirements, design, testing and release procedures, trains staff, keeps review and test records, and passes an external audit to become ISO 9001 certified, which helps it win foreign outsourcing contracts.

2. IEEE software engineering standards

   • IEEE 730: SQA plans.
   • IEEE 830: software requirements specification (SRS) format.
   • IEEE 829: software test documentation (test plan, test case, test report).
   • IEEE 1016: software design descriptions.
   • Example: a project writes its SRS using the IEEE 830 outline so that every requirement is complete, consistent and verifiable.

3. SEI CMM / CMMI

   • Process maturity models with five levels (Initial to Optimizing) used to assess and improve an organization's software process.
   • Example: an organization at CMMI level 3 has a defined, organization-wide standard process.

4. Coding standards

   • Example: MISRA C for safety-critical embedded software, or a company's Java naming and commenting rules.

Why standards help: they capture lessons learned, give a framework for the quality assurance process, give continuity when staff change, and build customer confidence.