The Summary report is your project dashboard, providing quick diagnostic information about the health of your project. The Summary report provides four default reports:

• Citing Backlog, showing two trends--issues in Analyze status and issues in Fix (to be fixed) status
• Top Issues, showing the top issues for the latest build
• Complexity Trend, showing the number of methods with a complexity over 20
• All Issues by State, showing the variance of states across all issues (such as new, open, fixed)

Click any report to see a more detailed and editable view.

You can edit this report to add other default reports or reports that you have created.

Similar to other reports, you can enable or disable whether issues are grouped for the Summary report's issue count header (you'll need to make a copy of this report to change this setting, as default reports cannot be edited). The grouping setting for the reports placed on the dashboard is determined from each report's grouping setting, if applicable. Editing this setting for the Summary report affects the number of issues displayed at the top of the report, as seen here:

Category Details

The Category Details report shows how detected issues are distributed across taxonomies and categories.

For each taxonomy (and category in that taxonomy, if applicable), you see:

• tables showing Error Distribution or Warning Distribution so that you can see how issues are distributed by category in the current project
• a table called Top 10 Files/Classes with the most issues (listed in descending order) for each category that contains detected issues. You can define the number of files/classes that appear.

Taxonomies that contain categories show the issue distribution and Top 10 files/classes by category. In this case, you see the <taxonomy_name>:<category_name> heading. The example below shows tables for detected issues in the Buffer Overflow category for the C/C++ taxonomy:

Some taxonomies may not contain categories. In this case, you see the distribution and Top 10 by taxonomy (MISRA C, for example).

Organizations can set up customized categories to reflect their own processes. See Configuring checkers for the integration build analysis.

From Category Details you can:

• sort by column heading for each table.
• access the Issue list from the available links in the tables to display only the issues of interest.

Citing Activity Since Last Build

Citing Activity displays changes in issue status since the last build.

The Citing Activity report shows:

• an Update Summary in the form of a pie chart, which indicates user updates by status type. You can access a list of issues by status by clicking a segment.
• an Update History indicating user updates over time. The time frame on the X-axis is determined by your selected dates. Intervals are by:
  • day for a date range less than or equal to 28 days
  • week for a range greater than 28 days and less than or equal to 62 days
  • month for a range greater than 62 days
• User updates in a table format that capture the number of issues changed to a given status. The Backlog column captures the number of issues that are still in Analyze status, which indicates that these issues haven't been assessed. You'll only see a particular status column if an issue has been changed to that status. Column headings are sortable and clicking the "number link" in a status column brings you to a list of issues.

Citing Backlog

The Citing Backlog report shows two trends per day:

• the backlog of issues that are still in 'Analyze' status (which require developer attention to gate accordingly using the available Klocwork statuses). This trend is shown in blue. See Issue statuses.
• the backlog of issues that have been assigned to Fix status but have yet to be fixed. This trend is shown in red.

If you choose to see this report over a number of builds, then the backlog trends are shown from the day of the first build date to the day of the last build. Selecting the "last <n> builds" shows the date of each build up until the current date.

The table below the chart shows the Analyze and Fix backlog by owner.

The issues shown on this graph are in any state but Fixed. See Issue states.

Fix Activity by Module

The default Fix Activity report summarizes defect fixes by module for the integration project. You can edit this report to show what defects your developers have prevented from entering the code stream.

When more than one build is selected or a time frame is selected that contains more than one build, bars in the graph show build pairs. For example, if three builds are selected, then two bars would be shown: one showing the number of fixed issues between build_1 and build_2, and a second showing the number of fixed issues between build_2 and build_3.

If only one build is selected, this report shows fixes since the previous build.

Fix Activity reports can be summarized by:

• owner (if file/class ownership has been loaded into the Klocwork database)
• module

By default, Fix Activity Summarized by Owner displays desktop fixes for the last 10 builds on the Project Summary page.

Fix Activity reports show a count of:

• all issues fixed at both the desktop and system levels
• desktop fixes, which are issues fixed before being checked in to integration builds
• system fixes that occur to issues detected in the integration build analysis

When an issue shows up in the desktop component but not in the integration build, it means that the desktop issue was detected and fixed while the developer was coding (before submitting code to the integration build). Desktop fixes are preventative fixes because the problems were fixed before check-in. Viewing Fix Activity by desktop indicates who has been using Klocwork on the desktop.

Top 10 Open Issues

The default pie graph shows you how the top 10 detected issues are distributed in the latest build by issue type. You can customize the number of issues on the fly.

Clicking on a segment displays the issue list for the selected issue type.

Issue Trend reports provide a high-level view of code issues over multiple builds. You can adjust the timeline to target one or more specific builds. The Y-axis displays number of issues.

Trending provides an overall view of product quality and fix rates that allows you to gauge the effectiveness of your organization's strategy, policies (for example, staff training) or compliance with industry standards such as MISRA C or MISRA C++.

There are three types of Issue Trend reports by default: Open Issues by Module, Open Issues by Owner and Rejected Issues by Owner.

Open Issues (by Module or Owner) reports show the distribution of issues by their current status in the build(s) you select.

The Rejected Issues by Owner report shows the issues that have been rejected in the build(s) you select. A rejected issue is an issue that has been set to status of 'Ignore' or 'Not a problem'.

Tip: The build(s) represented in the report are customizable by clicking-and-dragging over a section of the report timeline at the bottom of the report.

Complexity Trend

Displays the number of functions or class-methods that exceed the specified cyclomatic complexity threshold.

The default cyclomatic complexity threshold for the report is 20. For information about thresholds, see System Complexity.

Complexity Details

Shows you the number of instances of the top 15 complex methods and a list of modules that exceed the specified complexity threshold.

Whereas the Complexity report provides trending information, Complexity Details provides further information about the latest build such as the number of methods with complexity greater than the threshold for each module.

Information displayed depends on the module you select.

Size Trend

Tallies the total lines of code for the project or selected module.