Software Change Impact Analysis Process

Source: http://expedoc.com/

This method is abbreviated to highlight steps applicable to software developers in general and may not be acceptable for projects developing safety-critical product. The method is based off my experiences with releases of avionics products that comply with Chapter 11 Oversight of Software Change Impact Analyses Used to Classify Software Changes as Major or Minor in the FAA Order 8110.49 Software Approval Guidelines.

The goals of a software change impact analysis (CIA) include:

1. To determine the scope of changes between baselines. The scope of a CIA is the list changes from one baseline to another. A change is a defect, an added feature or a removal of specifications, test procedures or code.

2. To optimize the reverification activities to ensure the changed product and documentation are sufficiently complete and correct. Sufficiently, in this case, means adaptable to the business and regulatory requirements for the product to:

- Do what it is specified to do,

- Be reliable,

- and/or be safe.

You may define flexibility into your reverification activity selection method such that very minor changes (e.g. spelling correction in a requirements document) to require only informal review and major changes (e.g. added feature) require layers and combinations of verification activities. Verification activities include various review, analysis and test methods.

Based on your company's needs, a CIA may be formal or informal. Informal analysis is analysis based only on expert judgment and experience. Formal analysis is based on expert judgment, experience and objective evidence.

A CIA may be performed when a problem report is added to your change tracking system or as a deliverable in the planning stages of a release cycle performed only on the problem reports within the scope of the release.

The following are considerations, as a system and/or for each change, to determine the scope of reverification activities:

(1) Traceability analysis identifies areas that could be affected by each software change. Changes include:

- After the root cause of each defect is identified, to determine the changes required to fix the code and impacted documentation (e.g. requirements, design, architecture, test cases and test procedures).

- When a new feature is added to an existing software baseline, to determine the scope of additions required to add the feature to the documentation and code.

- When specifications, test procedure and code are removed, to determine the scope of deletions required to remove the affected data from the documentation and code.

(2) Memory margin analysis

- If applicable, the memory allocation specifications are changed.

- For embedded systems, tracking peak memory usage during stress testing provides assurance that acceptable memory margins are maintained.

- When changes impact code that utilizes memory allocation or deallocation features, reverification activities may include using tools that check for memory leaks.

(3) Timing margin analysis

- If applicable, the timing specifications are changed.

- For embedded systems, tracking timing during stress testing provides assurance that acceptable timing margins are maintained.

(4) Data flow analysis

- If public or global constants or public or global variables are changed, identify the changes to data flow and coupling between components.

(5) Control flow analysis

- Identify when changes affect the control flow and coupling of components.

(6) Input/output analysis

- Identify when changes that adversely impacted the input and output (including bus loading, memory access, and hardware input and output device interfaces) specifications of the product.

(7) Development environment and process analyses

- Identify changes to the compiler options, versions, and optimizations.

- Identify changes to the linker, assembler, and loader instructions or options change;

- Identify changes to off the shelf software tools and libraries.

(8) Operational characteristics analysis

- Evaluate changes to shared aspects of the software architecture (such as changes to gains, filters, limits, data validation, interrupt and exception handling, and fault mitigation).

(9) Changes to Hardware

- Identify significant processor changes as this change typically result in major reverification.

(10) Partitioning analysis

- Identify changes that impact partitioning incorporated in the design.

(11) Document impact

- Additional features or changes to behaviors may require updates to user manuals or notes of the changes in release notes.

- Changes to the build process may result in changes to installation or manufacturing build procedures.

Based on the aspects of the changes noted above, the engineers can determine the reverification activities (Reviews, Analyses and Tests) needed ensure the target quality and reliability goals for the product are achieved.

Safety engineers can use this information to assess the impact of changes to the hazards analysis and/or system safety assessment.

Note: The added benefit of using this method is that when the contents of formal development documentation is kept current, the company’s intellectual property is protected.