Why Is Software Quality Assurance Important?

1. Software Quality Assurance

In a manufacturing organization, the quality assurance department is responsible for assuring that the products are built as designed, according to an approved project and quality process. Deviations from the process are identified and corrected. Software quality assurance (SQA) can be seen in a similar way, assuring that the necessary processes are written and followed and the resulting software (output) is free from any anomalies or defects.

As part of the quality system, software quality assurance is important as it defines and measures the adequacy of the software (SW) process, providing evidence that establishes confidence to produce SW products of suitable quality for their intended purposes.

SQA also is a practice of monitoring the software engineering processes and methods used in a project to ensure the proper quality of the software is achieved. It may include ensuring conformance to standards or models, such as ISO 25010, which superseded ISO/IEC 9126, CMMI, or ASPICE.

SQA encompasses the entire software development process, including software requirements, design, coding, code reviews, source code control, software configuration management, testing, release management and software integration. It is organized into goals, commitments, abilities, activities, measurements, verification, and validation. Drivers for SQA such as the number lines of code in the SW has driven the need for focus on quality.

 

2. SQA Engineer

Typically, the responsibility of the SQA engineer is to understand software quality development and implementation, software inspection, testing, verification and validation, maintenance processes and methods. An additional responsibility of the SQA engineer is to perform internal audits and/or to ensure the company meets or exceeds quality metrics. The SQA engineer typically resides outside the software team or even from a different department or organization. They are an independent group, separate from the development team(s) to help with independence in review.

 

3. Capability Models

 

3.1. 

CMM

Since the ‘80s, the SW development industry has been concerned with establishing mechanisms that help companies in charge of defining SW architectures as well as its development and verification to ensure that these milestones are executed successfully and with quality.

The creation of the Capability Maturity Model (CMM), which was developed between 1987 and 1997, is one of the first models created to assess the level of maturity of companies in charge of SW development. CMM refers broadly to a process-improvement approach that is based on a process model. CMM also specifically refers to the first model of its kind, developed by the Software Engineering Institute (SEI).

There were 5 levels of the CMM: 

• Level 1: Initial – Processes are usually suitable, and the organization usually does not provide a stable environment.

• Level 2: Repeatable – Software development processes are repeatable.

• Level 3: Defined – The organization’s set with standard processes.

• Level 4: Managed – Using precise measurements, management can effectively control the software development effort.

• Level 5: Optimizing – Focusing on continually improving process performance through both incremental and innovative technological improvements.

3.2. 

CMMI

In order to adopt a culture of continuous improvement, the Capability Maturity Model Integration (CMMI) was created in 2002, built upon the Capability Maturity Model (CMM).

The CMMI is a process and behavioral model that helps organizations streamline process improvement and encourage productive, efficient behaviors that decrease risks in software, product, and service development.

Like the CMM, the CMMI also has 5 levels:

• Level 1: Initial – Processes are usually ad hoc and chaotic.

• Level 2: Managed – The projects in an organization have ensured that requirements are managed and that processes are planned, performed, measured and controlled.

• Level 3: Defined – Processes are well characterized and understood, and are described in standards, procedures, tools and methods.

• Level 4: Quantitatively Managed – Subprocesses are selected that significantly contribute to overall process performance. These selected subprocesses are controlled using statistical and other quantitative techniques.

• Level 5: Optimizing – Processes are continually improved based on a quantitative understanding of the common causes of variation inherent in processes.

3.3.

Difference Between CMM and CMMI

CMM concentrates on the completion of specific tasks or processes and does not motivate the organization to focus on process architecture. CMMI, on the other hand, has an iterative lifecycle that integrates the latest best practices from the industry and attacks risks in process architecture at an early stage.

3.4. 

Timeline

 

3.5. 

ASPICE

Automotive Software Process Improvement and Capability dEtermination (ASPICE) was developed in 2001 as a variant of ISO 15504 (SPICE) by the Automotive Special Interest Group (ASIG). This group consists of the SPICE User Group, the Procurement Forum, and German automotive constructors: Audi, BMW, Daimler, Porsche, Volkswagen, and other international automotive manufacturers like Fiat, Ford, Jaguar, Land Rover and Volvo. It provides rough guidelines to improve your software development processes and assess suppliers. This means that practically the whole European automotive industry must follow ASPICE.

ASPICE has six capability levels, incorporating nine process attributes as below:

• Level 0: Incomplete Process – The process is not implemented or fails to achieve its process purpose.

• Level 1: Performed Process – The implemented process achieves its process purpose.

• Level 2: Managed Process – The previously described performed process is now implemented in a managed fashion (planned, monitored and adjusted), and its work products are appropriately established, controlled and maintained.

• Level 3: Established Process – The previously described managed process is now implemented using a defined process that can achieve its process outcomes.

• Level 4: Predictable Process – The previously described established process now operates predictively within defined limits to achieve its process outcomes. Quantitative management needs are identified, measurement data are collected and analyzed to identify assignable causes of variation. Corrective action is taken to address assignable causes of variation.

• Level 5: Innovating Process – The previously described predictable process is now continually improved to respond to organizational change.

 

4. Conclusion

SQA is the best recognized way of minimizing uncertainties and maximizing the predictability of the software lifecycle. Do it once and do it right, and there will be less rework, less variation in design, better performance overall in addition to cost savings. SW development gets delivered on time and gets released more productively. Poor quality is much more difficult to manage; predictability decreases as rework grows, and the likelihood of a late, lower-quality product increases.

Reputation is an important Key Performance Indicator of quality. A good, solid reputation is hard to establish and easy to lose. A few mistakes and that reputation can be gone, creating major obstacles to sales and consequently, loss of trust.

A quality product satisfies the customer. A satisfied customer comes back for more and provides positive referrals. Customer loyalty is heavily driven by the quality of the software and the service provided.