Software Quality Assurance
As software project is becoming larger and more complex, the role of Software Quality Assurance (SQA) is becoming more critical. Even today, methods for assuring software quality are often not well understood by many project managers. Assuring software quality requires that engineering knowledge and discipline be applied at ALL phases of the development life cycle, NOT the last phases of test or release as many people misunderstood. Software Quality Assurance engineers are required to possess many years of software development and sufficient domain knowledge to evaluate the completeness and correctness of system requirements, and they must have the ability to determine whether the design has incorporated all requirements accurately. Ultimately, SQA engineers are responsible for advising management whether a software product is reliable and meet quality standards. For this kind of works, SQA engineers probably should be the most experience persons in the organization. They should work as software developers for many years and move up to technical leader or architect and perform this work for years before becoming SQA engineers.
The “Handbook of Software Quality Assurance”, define SQA as: “The set of systematic activities providing evidence of the ability of the software process to produce a software product that is fit to use. The focus, therefore, of SQA is to monitor continuously throughout the software development life cycle to ensure the quality of the delivered product. This requires monitoring both the processes and the products. In process assurance, SQA provides management with objective feedback regarding compliance to approved plans, procedures, standards, and analyses. Product assurance activities focus on the changing level of product quality within each phase of the life cycle, such as the requirements, design, code, and test plan. The objective is to identify and eliminate defects throughout the life cycle as early as possible, thus reducing test and maintenance costs.
The Institute of Electrical and Electronics Engineers’ (IEEE) defines quality as “the degree to which a system, component, or process meets specified requirements, and customer or user needs or expectations While this definition seems to be clear and unambiguous, many software project managers still complains that quality is “hard to define, impossible to measure, difficult to recognize” and therefore ignore it. Following is another detailed definition of software quality as defined in the standard “Handbook of Software Quality Assurance”.
Correctness: extent to which a project fulfills its specifications.
Efficiency: use of resources execution and storage.
Flexibility: ease of making changes required by changes in the operating environment.
Integrity: protection of the project from unauthorized access.
Interoperability: effort required to integrate the system to another system.
Maintainability: effort required to locate and fix a fault in the project within its operating environment.
Portability: effort required to transfer a project from one environment to another.
Reliability: ability not to fail.
Reusability: ease of re-using software in a different context.
Testability: ease of testing the project to ensure that it is error-free and meets its specification.
Usability: ease of use of the software.
Of course, in a perfect world all of these criteria would be met, but in reality tradeoffs are a part of all development projects. Often the most efficient software is not portable, as portability would require additional code, decreasing the efficiency. Usability is subjective and varies depending on the experience of users. When using the criteria to define the assurance objectives of a software system, the purpose and use of the system must be taken into account. In the real work of software development, criteria for quality are identified and applied to differing extents as a result of trade-off decisions.
With globalization, as many companies are doing business across national borders, the requirement for a quality product is becoming more important. It has been proven that having SQA is to ensure that there is discipline and control in the software development process via independent evaluation therefore SQA will determine whether a product will be accepted in certain places or not. There are two popular models of reviewing and assuring software quality: The ISO 9000 and the CMMI. The International Standard Organization (ISO 9000) provided a way to gain external accreditation for a quality management system. Many companies have used the application of ISO to software, but the issue is that it focuses mostly on procedures rather than process. The other is the Software Engineering Institute’s Capability Maturity Mode Integration (CMMI) focuses on the basis that the quality of the software product is largely determined by the quality of the software development and maintenance processes used to build it.
To ensure quality is critical for all future business. Having experienced SQA is essential for the business but even today, many software companies rarely invest or have sufficient funds to perform SQA works. Some believe they can avoid it as much as possible. The attitude of “Cutting costs” and having poor quality product are unacceptable in the highly competitive world. Many will NOT survive for long as more customers are demanding better quality product with the best safety, and reliability.
Sources
- Blogs of Prof. John Vu, Carnegie Mellon University
