Overview
This activity describes the process of analyzing and deciding the appropriate action to be taken on a Software Trouble Report. All Software Trouble Report information is stored in the project’s software configuration management (SCM) tracking system. On large projects, the personnel performing this activity may be doing so as members of a dedicated Software Trouble Report Board (STRB).
Roles and Responsibilities
The reviewer (a developer) is responsible for analyzing the Software Trouble Report, documenting the results on the Software Trouble Report form, and entering the Software Trouble Report into the project’s SCM tracking system. The reviewer may be asked to summarize the analysis and provide supplementary information to the project software manager.
The project software manager is responsible for assigning a reviewer to analyze the reported problem, reviewing the Software Trouble Report analysis, and determining if a change to a software product is required.
The SCM manager is responsible for granting access to the Software Trouble Report forms in the project’s SCM tracking system and verifying that the data was entered correctly.
Controls
The Software Trouble Report form and instructions (see Appendix C), which are documented in the Configuration Control section of the project’s SCM Plan (SCMP) (see Appendix E).
The Configuration Change Request (CCR) form and instructions (see Appendix C), which are documented in the project-level Configuration Management (CM) Plan (CMP).
Inputs
The Software Trouble Report to be analyzed, which was entered into the SCM tracking system.
Procedures
1) The SCM manager receives a Software Trouble Report, grants write access to the project software manager, assigns a unique number to the Software Trouble Report, and uses E-mail to send copies of it to the project software manager and software engineering manager.
2) The project software manager assigns one or more reviewers to analyze the Software Trouble Report and selects a requested completion date. The project software manager records this information on the Software Trouble Report form in the SCM tracking system and notifies each reviewer via E-mail. The SCM manager then grants each reviewer write access to the Software Trouble Report.
3) The responsible reviewer analyzes the Software Trouble Report to determine the source of trouble. The reviewer first determines if the Software Trouble Report is a duplicate of one already received. The reviewer then attempts to reproduce the problem and determine if it is a result of a user error, hardware problem, software-product error (e.g., incorrect code or mistake in installation instructions), or problem with an interfacing piece of software (e.g., interfacing computer software configuration item (CSCI) failure). If the reviewer determines that the Software Trouble Report results from a software product error, the reviewer also checks the change history of the product to determine if the error has been corrected in a later revision. If the error was corrected in a later version, the reviewer notifies the individual or organization reporting the problem of the availability of the updated product.
4) If there is a software product error, the responsible reviewer uses the Software Trouble Report to document the error location, all code units or documents that must be changed to correct the error, and any other potential problems or errors discovered while performing the analysis. The reviewer then records the completion date; saves the updated Software Trouble Report into the SCM tracking system; and notifies the project software manager, software engineering manager, and SCM manager via E-mail that the analysis is complete, sending them copies of the updated Software Trouble Report.
5) The SCM manager verifies that the data was correctly entered and that the project software manager and software engineering manager received copies of the updated Software Trouble Report via E-mail.
6) The project software manager examines the completed Software Trouble Report and determines whether or not a change to a software product is required. The project software manager bases this determination on a careful review of the Software Trouble Report analysis. If the project software manager requires further information, the project software manager discusses the analysis with the reviewer.
7) If the project software manager determines that a change is required to a software product under the project software manager’s control, the project software manager assigns the responsibility for writing the Software Change Request (SCR) (see Appendix C) to a staff member and notifies that individual via E-mail.
8) If the cause of the problem is a software product not under the control of the project software manager, the project software manager forwards the Software Trouble Report to the responsible manager and requests a reply by a certain date. If the problem is found in a commercial product, the project software manager contacts the vendor and attempts to identify possible work-arounds.
9) If a system problem (e.g., a flaw in the hardware) is found to be the cause, the project software manager writes a Configuration Change Request (CCR) (see Appendix C) and attaches the Software Trouble Report. The project software manager submits the SCR to a member of the project-level, configuration management (CM) staff. The format and method of submitting CCRs are documented in the project-level CMP, and, thus, are not detailed in this Guidebook. If no CCR form is specified in the project-level CMP, a SCR form may be used.
10) The project software manager documents the final disposition of the Software Trouble Report (e.g., no action taken, SCR written) on the form in the SCM tracking system.
Outputs
Possibly a CCR submitted to the project-level CM staff.
A Software Trouble Report which identifies a problem in a software product.