The purpose of the software quality assurance plans (SAQP) is to specify all the work products that need to be produced during the project, activities that need to be performed for checking the quality of each of the work products, and the tools and methods that may be used for the SQA activities.
It is interested in the quality of not only the final product, but also of the intermediate products. The SQAP specifies the tasks that need to be undertaken at different times in the life cycle to improve the software quality and how they are to be managed.
These tasks will generally include reviews and audits. The documents that should be produced during software development to enhance software quality should also be specified by the SQAP. It should identify all documents that govern the development, verification, validation, use and maintenance of the software and how these documents are to be checked for adequacy.
We’ll be covering the following topics in this tutorial:
Verification and Validation
In verification and validation we are mostly concerned with the correctness of the product. Verification is the process of determining whether or not the products of a given phase of software development fulfill the specifications established during the previous phase. Verification activities include proving, testing, and review. Validation is the process of evaluating software at the end of the software development to ensure compliance with the software requirements.
The major V&V activities for software development are inspection, reviews, and testing. Inspection is “a formal evaluation technique in which software requirements, design or code are examined in detail by a person or a group other than the author to detect faults, violations of development standards, and other problems”. It is formal, peer evaluation of a software element whose objective is to verify that the software element satisfies its specifications and conforms to standards.
Inspections and Reviews
The software inspection process was started by IBM in 1972 to improve software quality and increase productivity. Much of the earlier interest was focused on inspecting code. It was soon discovered that mistakes occur not only during coding but also during design, and this realization led to design inspections.
IEEE defines inspection as “a formal evaluation technique in which software requirement, design or code are examined in details by a person or a group other than the author to detect faults, violation of development standards, and other problems.
As is clear from the definitions, the purpose of an inspection is to perform a careful scrutiny of the product by peers. It is different from a walkthrough, which is generally informal and whose purpose is to train or inform someone about a product. In a walkthrough, the author describes the work product in an informal meeting on his peers or superiors to get feedback or inform or explain to them the work product.
In an inspection, in contrast to a walkthrough, the meeting and the procedure are much more formal. There are three reasons for having reviews or inspections.
Provide information for project monitoring.
The primary purpose of inspection is to detect defects at different level during a project.