|
|
|
| R2012a Documentation → Polyspace | |
Learn more about Polyspace |
|
| Contents | Index |
| On this page… |
|---|
Displaying Metrics for Single Project Version Creating a File Module and Specifying Quality Level |
For a development manager or quality assurance engineer, the Polyspace Metrics Summary view provides useful high-level information, including quality trends, over the course of a project.
To obtain the Summary view for a project:
Open the Polyspace Metrics project index. See Accessing Polyspace Metrics.
Click anywhere in the row that contains your project. You see the Summary view.
At the top of the Summary view, use the From and To filters to specify the project versions that you want to examine. By default, the From and To fields specify the earliest and latest project versions respectively.
In addition, by default, the Quality Objectives filter is OFF, and the Display Mode is Review/Justification Progress (%).
Below the filters, you see:
Plots that reveal how the number of verified files, lines of code, defects, and run-time selectivity vary over the different versions of your project
A table containing summary information about your project versions.
If you have projects with two or more file modules in the Polyspace verification environment, by default, Polyspace Metrics displays verification results using the same module structure. However, Polyspace Metrics also allows you to create or delete file modules. See Creating a File Module and Specifying Quality Level.
With the default filter settings, you can monitor progress in terms of coding rule violations and run-time checks that quality assurance engineers or developers have reviewed.
You can also monitor progress in terms of software quality objectives. You may, for example, want to find out whether the latest version fulfills quality objectives.
To display software quality information, from the Quality Objectives drop-down list, select ON .
Under Software Quality Objectives, you look at Review Progress for the latest version (V4), which indicates that the review of verification results is incomplete (only 85.7% reviewed). You also see that the Overall Status is FAIL. This status indicates that, although the review is incomplete, the project code fails to meet software quality objectives for the quality level SQO-4. With this information, you may conclude that you cannot release version V4 to your customers.
When Polyspace Metrics adds the results for a new project version to the repository, Polyspace Metrics also imports comments from the previous version. For this reason, you rarely see the review progress metric at 0% after verification of the first project version.
Note You may want to find out whether your code fulfills software quality objectives at another quality level, for example, SQ0-3. Under Software Quality Objectives, in the Level cell, select SQ0-3 from the drop-down list. There are seven quality levels, which are based on predefined software quality objectives. You can customize these software quality objectives and modify the way quality is evaluated. See Customizing Software Quality Objectives. |
To investigate further, under Run-Time Errors, in the Confirmed Defects cell, you click the link 3. This action takes you to the Run-Time Checks view, where you see an expanded view of check information for each file in the project.
To view any of these checks in the Polyspace verification environment, in the appropriate cell, click the numeric value for the check. The Polyspace verification environment opens with the Results Manager perspective displaying verification information for this check.
Note If you update any check information through the Polyspace verification environment (see Review Coding Rule Violations and Run-Time Checks), when you return to Polyspace Metrics, click Refresh to incorporate this updated information. |
If you want to view check information with reference to check type, from the Group by drop-down list, select Run-Time Categories .
Returning to the Summary view, under Coding Rules and in the Violations cell, you also see that there are coding rule violations. You may want to review these violations. See Review Coding Rule Violations and Run-Time Checks.
To display metrics for a single project version:
In the From field, from the drop-down list, select the required project version.
In the To field, from the drop-down list, select the same project version.
In # items field, enter the maximum number of files for which you want information displayed.
The software displays:
Bar charts with file defect information, ordering the files according to the number of defects in each file
A table with information about the selected project version
You can group files into a module and specify a quality level for the module, which applies to all files within the module. By grouping your files in different modules, you can specify different quality levels for your files.
To create a module of files:
Select a tab, for example, Summary.
In the Verification column, expand the node corresponding to the verification that you are interested. You see the verified files.
Select the files that you want to place in a module.
Right-click the selected files, and, from the context menu, select Add To Module. The Add to Module dialog box opens.
In the text field, enter the name for your new module, for example, Example_module. Click OK. You see a new node.
To specify a quality level for the module:
Select the row containing the module.
Under Software Quality Objectives, click the Level cell.
From the drop-down list, select the quality level for your module.
To remove files from a module:
Expand the node corresponding to the module.
Select the files that you want to remove from the module.
Right-click your selection, and from the context menu, select Remove From Module. The software removes the files from the module. If you remove all files from the module, the software also removes the module from the tree.
Note You can drag and drop files into and out of folders. For example, you can select MISRA_my_c_file.c and drag the file to Example_module. |
You can compare metrics of two versions of a project.
In the From drop-down list, select one version of your project.
In the To drop-down list, select a newer version of your project.
Select the Compare check box.
In each view, for example, Summary, you see metric differences and tooltip messages that indicate whether the newer version is an improvement over the older version.
You can specify a project version and focus on the differences between the verification results of your specified version and the previous verification. For example, consider a project with versions 1.0, 1.1, 1.2, 2.0, and 2.1.
In the To field, specify a version of your project, for example, 2.0.
Select the New Findings Only check box. In the From field, you see 1.2 in dimmed lettering, which is the previous verification. The charts and tables now show the changes in results with respect to the previous verification.
To manage the content of the bar charts, in the # items field, enter the maximum number of files for which you want information displayed. The software displays file defect information, ordering the files according to the number of defects in each file.
If you have installed Polyspace on your computer, you can use Polyspace Metrics to review and add information about coding rule violations and run-time checks produced by a verification.
Note By default, Polyspace Metrics does not use coding rule violations to evaluate software quality for C++ projects. However, you can customize software quality objectives (SQO) to incorporate coding rule violations. See Customizing Software Quality Objectives. |
You may use the Review Progress metric in the Summary view to decide when your team of developers should start work on the next version of the software. For example, you may wait until the review is complete (Review Progress cell displays 100%), before informing your development team.
Consider an example, where you see the following in the Summary view.
Review progress is incomplete (31.5%), and there are four coding rule violations. In the Violations cell, click 4, which takes you to Polyspace Metrics Coding Rules view.
The Reviewed column reveals the files that you have not reviewed completely. In this example, example.c is unreviewed (0.0%). To continue reviewing violations in this file, expand example.c.
You see that there are three violations of rule 17.4.
Note If you want to review coding rule violations with reference to the coding rules, in the Polyspace Metrics Coding Rules view, from the Group by drop-down list, select Coding Rules and expand a specific coding rule. |
On the row corresponding to rule 17.4, click the value in the Review Progress cell, 3. This action opens the Polyspace verification environment and takes you to the Results Manager perspective. On the Results Summary tab, you see the list of unreviewed violations.
Double-click a row. In the Check Details pane, you see information about the violated rule. In the Source pane, you see the code that causes this rule violation.
Select the Check Review tab. If you want to classify the violation as a defect, from the Classification drop-down list, select High, Medium, or Low . This will increment the Confirmed Defect value in Polyspace Metrics.
You can assign a status to this violation. From the Status drop-down list, select a status, for example, Fix or No action planned. When you assign a status to a violation, the software considers the violation to be reviewed.
If you consider the presence of a violation justifiable, select the Justified check box. In the Comments column, you can enter remarks justifying this violation.
Save the review. See Saving Review Comments and Justifications.
Note Classifying a coding rule violation as a defect or assigning a status for an unreviewed violation in the Polyspace verification environment, increases the corresponding metric values (Confirmed Defects and Review Progress) in the Summary and Coding Rules views of Polyspace Metrics. |
Consider an example, where you see the following in the Summary view.
Under Run-Time Errors, click any cell value. This action takes you to the Run-Time Checks view.
The Review Progress column reveals the progress level for each file, for example, 2.8% for __polyspace__stdstubs.c. Expand __polyspace__stdstubs.c.
In the row containing the ASRT check, click the value in the red Checks cell, which opens the Polyspace verification environment with the Results Manager perspective. The software displays the ASRT check on the Results Summary tab.
Double-click the row with the ASRT check, which brings the check into the Check Details pane.
On the Check Review tab, using the drop-down list for the Classification field, you can classify the check as a defect (High, Medium, or Low) or specify that the check is Not a defect.
Using the drop-down list for the Status field, you can assign a status for the check, for example, Fix or Investigate. When you assign a status, the software considers the check to be reviewed.
If you think that the presence of the check in your code can be justified, select the check box Justified. In the Comment field, enter remarks that justify this check.
Save the review. See Saving Review Comments and Justifications.
Note Classifying a run-time check as a defect or assigning a status for an unreviewed check in the Polyspace verification environment increases the corresponding metric values (Confirmed Defects and Review Progress) in the Summary and Run-Time Checks views of Polyspace Metrics. |
When you click a coding rule violation or run-time check, Polyspace downloads result files from the Polyspace Metrics web interface to a local folder. You can specify this folder as follows:
Select Options > Preferences > Server configuration.
If you want to download result files to the folder from which the verification is launched, select the check box Download results automatically.
If this launch folder does not exist, specify another path in the Folder field.
If you do not specify a folder using step 2 or 3, when you click a violation or check, the software opens a file browser. Use this browser to specify the download location.
By default, when you save your project (Ctrl+S), the software saves your comments and justifications to a local folder. See Specifying Download Folder for Polyspace Metrics.
If you want to save your comments and justifications to a local
folder and the Polyspace Metrics repository,
on the Results Manager toolbar,
click the button
.
This default behavior allows you to upload your review comments and justifications only when you are satisfied that your review is, for example, correct and complete.
If you want the software to save your comments and justifications to the local folder and the Polyspace Metrics repository whenever you save your project (Ctrl+S):
Select Options > Preferences > Server configuration.
Select the check box Save justifications in the Polyspace Metrics database.
If you are a software developer, you can begin to fix defects in code when, for example:
In the Summary view, Review Progress shows 100%
Your quality assurance engineer informs you
You can use Polyspace Metrics to access defects that you must fix.
Within the Summary view, under Run-Time Errors, click any cell value. This action takes you to the Run-Time Checks view.
You want to fix defects that are classified as defects.
In the Confirmed Defects column, click a non-zero cell value. For example, if you click 2, the Polyspace verification environment opens with the checks visible on the Results Summary tab.
Double-click the row containing a check. In the Check Details pane, you see information about this check. You can now go to the source code and fix the defect.
Polyspace Metrics supports the generation of code complexity metrics. The majority of these metrics are predefined and based on the Hersteller Initiative Software (HIS) standard.
To review the complexity of the code in your project, in the Summary view, click any value in a Code Metrics cell. The Code Metrics view opens.
The software generates numeric values or pass/fail results for various metrics. For information about:
The Hersteller Initiative Software (HIS) standard, see HIS Source Code Metrics.
Other, non-HIS, code metrics, see SQO Level 1.
How Polyspace evaluates these metrics and how you can customize code complexity metrics, see About Customizing Software Quality Objectives and SQO Level 1.
 | Accessing Polyspace Metrics | Customizing Software Quality Objectives |  |
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
