Software Quality Assurance (SQA)

Software Quality Assurance (SQA)

SQA encompasses: (1) a quality management approach; (2) effective software engineering technology (methods and tools); (3) formal technical reviews applied throughout the software process; (4) a multi-tiered testing strategy; (5) control of software documentation and of the changes made to it; (6) a procedure for ensuring compliance with software development standards; and (7) measurement and reporting mechanisms.

When an item is examined on the basis of its measurable characteristics, two kinds of quality can be identified: quality of design and quality of conformance of the final product.

Quality of design refers to the characteristics that designers specify for an item.

Quality of conformance is the degree to which the design specifications are followed during manufacturing. The greater the degree of conformance, the higher the quality of conformance.

Quality control

Change control can be equated with quality control. Quality control consists of the series of inspections, reviews and tests used throughout the software process to ensure that each work product meets the requirements defined for it. Quality control includes a feedback loop to the process that created the work product.

Quality assurance

Quality assurance consists of the auditing and reporting functions of management. Its goal is to give management the data it needs to stay informed about product quality, and thereby to gain insight and confidence that product quality is meeting its goals.

Cost of quality

The cost of quality includes all costs incurred in the pursuit of quality or in performing quality-related activities. Cost-of-quality studies are conducted to establish a baseline for the current cost of quality, to identify opportunities for reducing it, and to provide a normalized basis for comparison. Quality costs are divided into prevention, appraisal and failure costs.

For the purposes of SQA, software quality is defined as conformance to explicitly stated functional and performance requirements, to explicitly documented development standards, and to the implicit characteristics that are expected of all professionally developed software.

Many different groups share responsibility for software quality assurance: software engineers, project managers, customers and salespeople are all people who belong to the SQA group.

The SQA group acts as the customer’s in-house representative; in other words, the people who perform SQA must look at the software from the customer’s point of view.

SQA activities

The role of the SQA group is to help the software team achieve a high-quality final product.

Its activities include: (1) preparing an SQA plan for the project; (2) participating in the development of the project’s software process description; (3) reviewing software engineering activities to verify compliance with the defined software process; (4) auditing designated software work products to verify compliance with those defined as part of the software process; (5) ensuring that deviations in software work and work products are documented and handled according to a documented procedure; and (6) recording any noncompliance and reporting it to senior management.

The primary objective of formal technical reviews (FTRs) is to find errors before they are passed on to another software engineering activity or released to the customer.

The objectives of an FTR are:

(1) to uncover errors in function, logic or implementation for any representation of the software; (2) to verify that the software under review meets its requirements; (3) to ensure that the software has been represented according to predefined standards; (4) to achieve software that is developed in a uniform manner; and (5) to make projects more manageable.

The review meeting

Regardless of the FTR format chosen, every review meeting should abide by the following constraints:

• Between three and five people should normally be involved in the review.
• Advance preparation should take place, but it should require no more than two hours of work per person.
• The review meeting should last less than two hours.

Given these constraints, it is clear that an FTR focuses on a small, specific part of the overall software.

The SQA plan

The SQA plan provides a road map for instituting software quality assurance. Developed by the SQA group, it serves as a template for the SQA activities that are applied to each software project.

An introduction to the Capability Maturity Model for software companies (SW-CMM)

Software companies need to present some evidence to prove their quality and capabilities. The Capability Maturity Model is used to assess the software processes of companies, and it can be considered the most credible worldwide credential for demonstrating a company’s ability to win and deliver software projects. SW-CMM is a model for determining the maturity of a software company’s processes and for identifying the key practices needed to increase the capability and quality of those processes. The standard was developed by the Software Engineering Institute (SEI), one of the leading research and development centers in the United States, which operates at Carnegie Mellon University with federal funding from the U.S. Department of Defense to improve the processes of software organizations. The main goal of SW-CMM is to improve the processes of software companies and to move them from ad hoc, chaotic processes to mature, disciplined ones. SW-CMM is a staged standard: it places the processes used by software companies on a five-level scale. As a company moves up to higher levels, the predictability, effectiveness and control of its software processes improve.

Maturity levels of software organizations

The SW-CMM maturity levels are:

1. Initial: companies at this level have ad hoc and occasionally chaotic software processes. Few of their processes are defined and documented in advance.
2. Repeatable (managed): basic project management processes are in place to plan and track cost, schedule and functionality. Processes that succeed can be repeated on other projects.
3. Defined: the management and software engineering processes of the assessed company are documented, standardized and integrated. All of its projects use an approved, standard version of the processes to develop and maintain software.
4. Quantitatively managed: detailed measures of the quality of software processes and products are collected. Software processes and products are quantitatively understood and controlled.
5. Optimizing: continuous process improvement is enabled by quantitative feedback from the processes and by piloting innovative ideas and technologies.

Source: http://www.rayantech.blogfa.com