VI. NONCONFORMANCE REPORTING AND CORRECTIVE ACTION A. Concepts and Definitions The purpose of a Nonconformance Reporting and Corrective Action (NRCA) system or procedure is to report, analyze, and correct nonconformances and collect information from which reports on the overall status of nonconformances can be made. A nonconformance, often called a problem, discrepancy, anomaly, fault, or error, is any failure of any software document, code, or data structure to meet its requirements or standards. Corrective action is a general name for the process by which nonconformances are corrected and controlled. The need for a NRCA system arises early in the software life cycle, as soon as the first documents and other products are developed. A NRCA system should track nonconformances, assign priorities, record their dispositions, note the version of the product in which they are corrected, notify the originator of the nonconformance about the actions taken, and produce management reports. B. Activities 1. Nonconformance Detection and Reporting By definition, a nonconformance is a deviation of any product from its requirements or standards. Nonconformance reports may be filed against any product in any phase of the software life cycle by anyone associated with the project. Normally, the NRCA system is used after a product is first approved or baselined by its developer and released for wider use. For example, while a developer is unit testing his/her code, errors found may be tracked only locally. After the code is declared correct and released for integration, the NRCA system is used to inform users of the code about nonconformances and to assure that the nonconformances are corrected and not overlooked. Usually, a special form is used to make the nonconformance report. Examples of the information the form might contain are: Date and time of detection of the nonconformance. Error identification (report number and title). Reporting individual and organization. Individual responsible for corrective action. Criticality of the nonconformance. Statement of the nonconformance. Proposed fix for the nonconformance. Identifier of the unit of code, data, or documentation in which corrective action must be taken. Life cycle phase in which the nonconformance was introduced. Life cycle phase in which the nonconformance was detected. Final closure resolution. Date and/or version of the configuration item in which the correction will be included. Date on which the nonconformance is closed. A DID for a discrepancy report is given in the Management Control and Status Reports volume of the NASA Documentation Standard. 2. Tracking and Management Reports After the report is prepared by the individual who found the nonconformance, the data are entered into some form of controlling system. Data base management systems are often used to help automate the otherwise laborious clerical effort of tracking the nonconformances and providing management reports. A nonconformance tracking and reporting system should be able to provide management reports containing such information as error and correction status, the number of errors found per product, and the criticality of open problems. The data enable the impact of nonconformances to be evaluated so that the use of resources may be prioritized. 3. Impact Assessment and Corrective Action Nonconformance reports should be evaluated for criticality and level of importance. Factors to be considered include: The impact of not correcting the nonconformance. The resources required for correcting the nonconformance. The impact on other baselined items if the nonconformance is corrected. If the decision is made to correct a nonconformance, there should be procedures to control the corrective action process. Such procedures should include followup to ensure the nonconformance has been documented and corrected in the appropriate version of software, and to assure that adequate testing, including regression testing, is done. C. Interrelationships NRCA is a basic and fundamental tool for project management and for software assurance. As such, it impacts and interacts with many software management, development, and assurance activities. For example, CM has to track the product changes and versions that result from correcting nonconformances. In addition, some nonconformance reports will contain requirements changes disguised as nonconformances. These reports should result in the opening of a change request. If the nonconformance is in a code or data product, those responsible for V&V activities must develop tests to ensure that the problem is indeed satisfactorily corrected. In addition, regression testing is needed to make sure that no new problems have been introduced by the fix. SQA must assure that proper procedures are followed in processing nonconformances, and that shortcuts are not taken since they would threaten product integrity. SQA must also ensure that the modified product still meets its standards. SQA may use the numbers of nonconformances detected in specific areas of the system or that occurred in specific life cycle phases to identify process or product areas that might benefit from an audit. The NRCA system is a useful tool for SQE, since it is often true that a product or component of a product with a large number of nonconformances is of poor quality and/or reliability and needs to be reexamined. In systems with significant safety and/or security requirements, the safety and security staffs will review nonconformances both to assure that their requirements are not compromised and to look for weaknesses that the problems might have uncovered. D. Techniques and Tools Each project should consider an automated tracking system for nonconformance reports and an automated updating capability to identify and record the product changes that occur as a result of the resolution of the nonconformances.