About Defect Impact Analysis

Performing an impact analysis allows you to see the scope of a defect's impact at a glance. You can generate a Defect Impact Analysis report from either a defect or defect action to see the impact of that defect against all model versions.

This page discusses:

See Also
Defect Impact Analysis Report
About Affecting Defects

Direct Defect Impact Analysis Report

The scope of the direct Defect Impact Analysis report is all model versions in the hierarchy directly affected by a defect, starting at either the model version against which the defect was directly reported (when run from a defect) or the model version to which the defect action is committed (run from a defect action).

The direct Defect Impact Analysis report traverses the model version hierarchy upwards, collecting all ancestors of the context model version revision. This is visually represented as a reverse model version hierarchy. When launched from a defect, the starting point of a direct Defect Impact Analysis report is the model version revision against which defect was reported.

When launched from a defect action, the starting point is of a direct Defect Impact Analysis report is the model version revision to which the defect action is committed. If the defect action is in the Open state, only those model version revisions in the hierarchy that are currently affected by the issue are shown. If the defect action is in the Closed state, only those model version revisions that might have been affected when the issue was open are shown.

Full Defect Impact Analysis Report

The scope of the full Defect Impact Analysis report is expanded to include other revisions and derivations of the model version that may be affected by the defect or defect action, and the hierarchy of model versions that use each of those revisions.

The full Defect Impact Analysis report is more complex and more inclusive than the direct Defect Impact Analysis report. It spans the model version derivations from the Introduced In or Reported Against revisions to the Committed Model Version revisions and shows all model versions in the hierarchy of each revision.

Determining Start and End Points for the Report

You should understand the scope of the full Defect Impact Analysis report so that you understand how the defects listed were selected.

The starting point of the full Defect Impact Analysis report is either the model version in which the defect was introduced or, if this link (which is optional) does not exist, the revision against which the defect was reported (which must exist). The ending point of the full Defect Impact Analysis report is a moving target. The process consists of two phases: one entails drilling down into the derived versions and branches to find the set of revisions of the starting model version to be considered, and the other involves ascending up the model version hierarchy from each of those revisions to collect the referencing model versions. This logic involves different steps, depending on whether the report is being generated from a defect or defect action.

Generating the Report from a Defect

You can generate the full Defect Impact Analysis report from a defect.

The process of generating a full Defect Impact Analysis report starting from a defect is:

  1. Start at either the model version in which the defect was introduced or the revision against which the defect was reported.
  2. For each defect action of the defect, if a Committed Model Version relationship exists, set this revision as the end point.
  3. Beginning with the start point, scan down the derivation tree, collecting all revisions and branches. At this point, the Derived relationship and the Derived Type attribute (which suggests the type of derivation—whether Derived, Branched, or Merged) are used. Further examine the Derived, Branched, and possibly Merged derivation types.
  4. If a model version revision that is an end point is reached, stop for that branch; otherwise, continue until the route is exhausted. If for some reason there are two end points, stop at the first one. The end point itself is included unless the defect action is in the Closed state (until the defect action is closed, it is assumed that the problem still exists, but that it will be fixed and there are no child revisions).

This provides the starting set of revisions of the initial model version. The app then scans the model version hierarchy upwards from each of these revisions to get the other model versions that are affected by the defect.

If the start point is also an end point in the Closed state, the defect was found and fixed in the same revision and is assumed not to affect any model versions. In this case, the app simply reports that there are no model versions affected.

If the derivation tree is deep, this report may contain a large number of model version revisions entangled in a fairly complex hierarchical structure. You can display the report in Summary view to make it more legible.

Generating the Report from a Defect Action

You can generate the full Defect Impact Analysis report from a defect action.

The process of generating a full Defect Impact Analysis report starting from a defect action that has a Committed Model Version is:

  1. Start at the Committed Model Version revision. Include the Committed Model Version itself, unless it is in the Closed state. (It is assumed that the issue exists until it is closed.)
  2. Scan backwards up the derivation tree, collecting all revisions (using the Derived relationship and only the Derived and Branched types). The state of the defect action is not considered during this process.
  3. Stop at and include the start point.

If the start point is also an end point in the Closed state, the defect was found and fixed in the same revision and is assumed not to affect any model versions. In this case, the app simply reports that there are no model versions affected.

Processing Merge Edges

Merged edges are taken into account when generating a full Defect Impact Analysis report from a defect.

Note: Your Business Administrator can disable this functionality.

For example, starting from a defect that was introduced in Chip 1.6, the process is:

  1. Scan down the derivation tree and collect more versions and branches affected by the defect, such as 1.6.1, 1.6.2, 1.7, 1.7.1.1, 1.8, and 1.9.
  2. If Chip 1.8 is the Committed Model Version for a defect action, stop there (and do not include 1.8, if it is in the Closed state, or 1.9).
  3. Ascend the model version hierarchy and continue collecting all ancestors and add them to the list.
  4. Pass the final list to the structure browser.

When tracing back from a model version revision to find earlier revisions, there is a choice of whether or not to follow Merged type derived relationships. Since it is not possible to know for certain whether a merge includes the files that contained a defect or those that resolved a defect, the search algorithm opts to follow merge edges by default. For example, if an issue that was introduced in version 1.3.1.2 were to be merged across to version 1.7 and then fixed in version 1.3.1.3, the merge tree would look something like this:

By default, the search algorithm follows the merge edge, which means it assumes that version 1.7 includes the defect (since it includes the merge code from version 1.3.1.2) and version 1.8 does not have the defect (since it was merged from version 1.3.1.4, which has the fix).