Quality metrics are used to estimate characteristics or qualities of a software product. Examples of these metrics include complexity metrics, and readability indexes for software documents. The use of these metrics for quality assessment is based on the assumptions that the metric measures some inherent property of the software, and that the inherent property itself influences the behavioral characteristics of the final product.
Some metrics may be both management metrics and quality metrics, i.e., they can be used for both project control and quality assessment. These metrics include simple size metrics (e.g., lines of code, number of function points) and primitive problem, fault, or error metrics. For example, size is used to predict project effort and time scales, but it can also be used as a quality predictor, since larger projects may be more complex and difficult to understand, and thus more error-prone.
Following are the QA Metrics
The main reasons to measure requirements specifications is to provide early warnings of quality problems, to enable more accurate project predictions, and to help improve the specifications.
The main reasons for computing metrics during the design phase are the following: gives early indication of project status; enables selection of alternative designs; identifies potential problems early in the lifecycle; limits complexity; and helps in deciding how to modularize so the resulting modules are both testable and maintainable. In general, good design practices involve high cohesion of modules, low coupling of modules, and effective modularity.
Metrics used during the implementation phase can be grouped into four basic types: size metrics, control structure metrics, data structure metrics, and other code metrics.
Test metrics may be of two types: metrics related to test results or the quality of the product being tested; and metrics used to assess the effectiveness of the testing process.
Installation and Checkout Metrics
Most of the metrics used during the test phase are also applicable during installation and checkout. The specific metrics used will depend on the type of testing performed. If acceptance testing is conducted, a requirements trace may be performed to determine what percentage of the requirements are satisfied in the product (i.e., number of requirements fulfilled divided by the total number of requirements).
Operation and Maintenance Metrics
Every metric that can be applied during software development may also be applied during maintenance. The purposes may differ somewhat. For example, requirements traceability may be used to ensure that maintenance requirements are related to predecessor requirements, and that the test process covers the same test areas as for the development. Metrics that were used during development may be used again during maintenance for comparison purposes (e.g., measuring the complexity of a module before and after modification). Elements of support, such as customer perceptions, training, hotlines, documentation, and user manuals, can also be measured.