Issues with implementing Software Quality Assurance (SQA)
by: Ian Fleming
Issues with implementing Software Quality Assurance (SQA).
Software Quality Assurance SQA Definition:-
"The function of software quality that assures that the standards, processes, and procedures are appropriate
for the project and are correctly implemented." From software definitions at NASA.
This definition comes directly from the Quality Movement that was first established in Japan in 1946 by the U.S. Occupation Force's. The only difference between QA of the Quality Movement and SQA is the term software is introduced to both the term and the definition.
It is understandable that many attempts have been made to metamorphous the manufacturing QA definition (and practice) into software QA, due to the overwhelming success of the quality movement as demonstrated in Japanese manufacturing. Some 60 years later, however, the only aspect of QA that has been successfully transformed to SQA is the goals, namely Fujitsu’s slogan of “Quality built-in, with cost and performance as prime consideration”.
The main issue with basing SQA on QA is due to the intangible nature of the software product.
As stated by Frederick P. Brooks, Jr. in his No Silver Bullet: Essence and Accidents of Software Engineering
“The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract in that such a conceptual construct is the same under many different representations. It is nonetheless highly precise and richly detailed”.
It is the abstract nature of software that impedes the manufacturing QA definition being applied directly to software. To be more precise it is actually Quality Control (QC) that is problematic for software. In manufacturing there would be a separate group Quality Control (QC) that would measure the components, at various manufacturing stages. QC would make sure the components were within acceptable “tolerances”, i.e. they did not vary from agreed specifications. Within software production, however, the intangible nature of software makes it difficult to set up a Test and Measurement QC department that follows the manufacturing model.
In order to overcome the essential difficulties of implementing Software Quality Control SQC procedures two strategies have evolved. These strategies are typically used together in the Software Development Life Cycle (SDLC).
The first strategy involves a pragmatic characterization of software attributes that can be measured, thereby subjecting them to SQC. The idea here is to make visible the costs and benefits of software by using a set of attributes. These attributes include Functionality, Usability, Supportability, Adaptability, Reliability, Performance etc. Then Quality Control can be set up to ensure that procedures and guidelines are followed and these procedures and guidelines exist in order to achieve the desired software characteristic. The adage, "what can be measured can be controlled" applies here. This means that when these characteristics are measured the effectiveness of the procedures and guidelines can be determined. The software production process can then be subjected to SQA (audits to make sure procedures and guidelines are followed) as well as continuous process improvement.
SQA is only a part of continuous improvement (see CMMI); however continuous improvement cannot be achieved without the measurements of SQC and the audits of SQA.
A number of models, and references, for software characterization can be found on the internet. One such model is called the FURPS model which was developed by Robert Grady at Hewlett Packard. If a pure implementation of the FURPS model, or similar, was possible then QC and QA, from manufacturing, could be applied to software production.
The second strategy, to overcome the essential difficulties of software production, is prototyping.
With this approach a risk (or immeasurable characteristic) is identified, i.e. Usability, and a prototype that addresses that risk is built. In this way a given aspect of the software product can be measured. The prototype itself could evolve into the end product or it could be 'thrown away'. This approach takes an interactive path as it is quite possible the software requirements (which should include all the software characteristics) may need to be revisited.
Whilst SQA and SQC, definitions, can be traced to their manufacturing counter parts, the implementation of SQA and SQC continues to find their own unique paths. The goal of SQA and QA, however, still remain the same and that is Fujitsu’s slogan "Quality built-in, with cost and performance as prime consideration". It is the actual measurement of the "cost and performance" of software that make SQA and SQC so problematic.
About The Author
Ian Fleming
25 years IT experience, including HP Labs Inc. and SAP Labs inc. Founder of
http://www.sqa.net.
