Tracking and evaluating changes occurs throughout the project life cycle and applies to all software providers, internal and subcontracted.
The NASA Systems Engineering Handbook, NASA/SP-2007-6105, Rev1, provides a flowchart of a "typical" change control process. This flowchart, shown below, highlights key activities and roles for capturing and tracking changes that are appropriate considerations for any project establishing a new change control process. Several of these steps are addressed in other guidance in this Handbook (see the table of related guidance at the end of this section), including configuration status accounting (CSA).
Guidance for key elements from this flowchart is included below, including preparing the change request, evaluating the change, and tracking the request through the change control process.
Considerations for capturing the change
- Changes can be requested for baselined software products including specifications, requirements, design, code, databases, test plans, user documentation, training materials, etc.
- Problems or failures.
- Reconfiguration changes, including routine changes, to operational software.
- Changes related to upgrades.
- Enhancement requests.
Capturing the requested change usually involves completing a predefined change request form or problem report and may require access to a change tracking system. A problem reporting/corrective action (PRACA) system is also an option for capturing changes, particularly, after the software is operational (NASA-GB-8719.13, NASA Software Safety Guidebook).
Depending on system access and project procedures, requests may be entered by developers, testers, end users, help desk personnel, etc. See SWE-113 in this Handbook for guidance for change requests and problem reports. Consider the following suggestions for the change capture process:
- Require a separate change request or problem report for each change.
- Use a form/format that clearly guides the writer through the process of capturing all key information needed to capture the issue and process the request.
Considerations for evaluating the change and suggested solution
- Project impact analysis.
- Include appropriate set of stakeholders, such as procurement, quality assurance, risk management, relevant experts, management (e.g., change requested by high visibility customer may result in a business decision to implement a change as opposed to volumes of end users not seeing the problem), etc.
- Evaluate impact to schedule and cost, including making and testing the change and regression testing the software.
- Evaluate impact to other groups and resources, as applicable.
- Evaluate impact to functions and features, interfaces, system resource requirements.
- Evaluate impact to other baseline products, such as design, tests, documentation (traceability matrices are helpful here).
- Evaluate risk of making the change vs. not making it.
- Evaluate size, complexity, criticality of the change.
- Evaluate whether change request is within scope of project.
- Evaluate whether change request is needed to meet project requirements.
- Evaluate impact on performance, reliability, quality, etc.
- Evaluate alternatives to making the change.
- Software safety impact analysis (NASA-STD-8719.13, NASA Software Safety Standard)
- Include software quality assurance, safety personnel in this review.
- Look for potential creation of new hazard contributions and impacts.
- Look for potential modification of existing hazard controls or mitigations.
- Look for detrimental effect on safety-critical software or hardware.
- Determine effect on software safety.
- Determine effect on system safety.
- Capture evaluation/analysis results and related decisions, including action items.
Impact analysis, including impact to the safety of the system, may be performed by a change control board (CCB) or experts they designate to perform the analysis. See SWE-082 for additional guidance on impact analysis as it relates to authorizing changes.
Considerations for tracking the change
- Use a change control system that is compatible with the project environment and capable of tracking change until completed.
- Trace safety-critical problems back to the related system-level hazard.
- Include in the tracking records the actual change request/problem reports, impact analysis, notes from evaluation/approval boards and meetings, etc.
- Track the software products and versions changed as part of implementing the change (requirements, code, specifications, etc.)
- Close change requests only after verification and approval of the implemented change and all associated documentation revisions.
Tracking a change through its disposition (approve, defer, disapprove, etc.) is made easier if the tracking can be done as part of the same system used to capture the change request/problem report. Once disposition decisions are made, the relevant stakeholders are informed of the decisions.
Current status of changes is presented at appropriate reviews, including project life cycle reviews. Review of historical trends and details on open changes is also considered for reviews.
Consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources related to methods, tools, and procedures for tracking and evaluating changes.
Additional guidance related to tracking and evaluating changes to software may be found in the following related requirements in this handbook: