Page tree

Skip to end of metadata
Go to start of metadata

In this chapter:


This slice calculates risky code change metrics and displays them in multiple forms (pie chart, bubble chart, and table report). The risky code changes slice derives three different metrics on a per file basis:

  • test score
  • maintainability score
  • risk score.

The metrics are derived according to the following calculations:

  • Test Deficit – 100 – (# Tests / 2 * # Methods * 100 (capped at 100) + 4 * Coverage (percentage * 100) / 5
  • Maintenance Burden – 200 – Maintainability Index (capped at 200)
  • Quality Debt – (Severity 1 & 2 violations + # Test Failures)/ Logical lines of code

Once the scores have been computed, they can be displayed in various formats depending on the mode parameter sent in the request.

Resubmit Data if Updating Risky Code Changes to 2.0.1

As a result of changes in 2.0.1 to improve performance, previously reported coverage data cannot be used to calculate risky code changes. After installing DTP 5.3.2, send a new test and coverage report to DTP server to and set it as a baseline build to compare with a target build when configuring the widget.

You can resubmit a previous build report to the data collector to populate the data. Once the data is in DTP, make sure to archive the build so that it won't be removed during normal database clean up (see Locking and Archiving Builds).


  • Parasoft Extension Designer 5.3.2 or higher. 
  • Parasoft DTP 5.3.2 or higher.
  • A filter must be configured in DTP to receive all types of analysis: Static Analysis, Metrics, Dynamic Analysis (unit testing, functional testing, manual testing), and Coverage. See Associating Coverage Images with Filters.
  • The following metrics should be enabled in the code analysis tool (see Editing Test Configurations) for the DTP filter:
    • METRIC.MI (Maintainability Index)
    • METRIC.NOLLOCIF (Number of Logical Lines in Files)
    • METRIC.NOMIT (Number of Methods in Types)
  • DTP enables you to constrain how much coverage data is processed. Verify that the coverage image associated with the data you want to process is accepted. See Controlling Coverage Data Processing for Enterprise Pack Artifacts.


DTP ProjectThe root level at which the analysis tools report data. Comes preconfigured with a “filter” that gathers all the Run Configurations that are reported to the project.
FilterA DTP configuration that allows users to pick and choose what data from different analysis runs is used to populate the reports generated in the dashboards.
Run ConfigurationA Run Configuration is an abstract mapping of various metadata associated with an analysis run (e.g. machine, test configuration, user, session tag, etc). This metadata is used to differentiate the data reported during different analysis runs. It can narrow the data shown for a given filter. 
Build IDAnalysis run metadata that is used to aggregate data across multiple analysis runs into a single “build”

You can confirm that the filter and build meet these requirements by checking the Build Administration page in DTP:


See Downloading and Installing Artifacts for information on installing extensions for DTP Enterprise Pack.

Once the Risky Code Changes slice is installed into PIE Slice Designer, a model profile called demo is installed. The demo profile is an example that is full configured and includes three risk level thresholds:

  • low
  • medium 
  • high

See Working with Model Profiles for information on configuring model profiles.

Caching the Data

Because you can run the Risky Code Changes slice over extended periods of time, the slice includes a caching mechanism to speed up multiple requests for the same data. When data is requested for a filter, the slice first determines if the data is already computed and cached. If the cache exists, the data is returned directly and the lengthy computation is skipped. The cache is cleared and recomputed on the fly, however, if the data is not cached, if the cached data is for a different build combination, or if more analysis data has been reported to the build combination, then the cache is cleared and recomputed on the fly. There is a maximum of one cache per filter and combination of baseline and target build.

Clearing the Cache

Because the slice does not automatically remove cached data, the cache can grow as more filters are introduced. To help you clear out old cache data, the slice provides a way to delete all cached calculations from the PIE database. This flow cleans all cached calculations. The cache also clears at 00:00 every day. You can configure the auto cache clearing setting by editing the Clean Cache inject node.

Risky Code Change Widgets

The Risky Code Changes slice includes the following widgets that can be added to DTP after installation and deployment:

  • Risky Code Changes - Pie Chart. This widget shows risky code change aggregates (e.g., the number of files that fall into the various risk levels defined in the profile).
  • Risky Code Changes - Bubble. This widget shows the risky code changes per file. The test score is mapped to the X-Axis, the maintainability score is mapped to the Y-Axis, and the risk score is mapped to the bubble size:

Widget Configuration

See Adding Widgets for details on adding widgets.

Check Build Administration to Get the Correct Build

By default, Baseline Build is set to Previous Build and Target Build is set to Latest Build when you configure the widgets. The slice will automatically select the two most recent builds, but these builds may not contain test and coverage details. You should check the Build Administration page in DTP and use an appropriate baseline and target build when configuring the widget as described in the Requirements section. Also see Build Administration.


You will receive an error instead of a rendered widget if the coverage information is inaccessible (see Requirements). 

The following error is returned when the filter has a coverage tag that does not contain coverage information:

Verify that the filter has a coverage image associated with it (see Associating Coverage Images with Filters) and that Data Collector is configured to accept the coverage image (see Controlling Coverage Data Processing for DTP Enterprise Pack Artifacts). New reports must be sent to DTP after properly configuration.

The following error is returned when Data Collector is configured to accept your coverage data, but the specific coverage image does not contain data.

Verify that the filter has a coverage image associated with it (see Associating Coverage Images with Filters) and that the correct coverage image was selected when you added the widget (see Widget Configuration).

Drill-down Reports

Click on a widget after adding it to your dashboard to open the Risky Code Changes drill-down report.



Performance improvements related to test cases and resources.

The coverage tag now appears in the drill-down reports.

  • No labels