Based on your chosen installation configuration, you need to consider hardware and storage requirements, data management and licensing. The Klocwork Servers and other tools should be installed according to the implementation plan created in Phase I.

If you will be deploying Klocwork on the desktop, the Klocwork IDE plug-ins or the command-line software (kwcheck) must be installed on developers' desktops. Each developer can install the desktop analysis plug-in.

In this phase, you identified the method of role-based security. For detailed instructions on how to integrate existing LDAP or NIS infrastructure or use Klocwork Basic access control, see Setting up access control.

For setting up roles for specific users or groups, see Enabling access to Klocwork projects.

In Phase I, Stage 7, you identified the issues and vulnerabilities that Klocwork would be used to identify. Now, you need to make changes to the Klocwork configuration that controls this data. See Configuring checkers for the integration build analysis.

If developers are working independently, they can customize their own configuration. If they are working with a Klocwork integration build analysis, they must have access to synchronize the data to the Klocwork Server, to ensure consistency of analysis between the desktop and the integration project.

Following integration build analysis, information about the analysis is made available through the following Klocwork clients:

• Klocwork Static Code Analysis

Running a Klocwork developer desktop analysis is typically done on a file-by-file basis, rather than the entire system. Developers can use either the Klocwork IDE plug-in or the command line.

It is important to reference a specific Klocwork project on the Klocwork Server for the developer desktop. This approach allows the developer desktop analysis to access configuration files that determine which issues and security vulnerabilities are enabled during analysis. This is done automatically when the developer is using the IDE plug-in or on the command line.

Special Developer Desktop considerations

Once the integration build analysis is completed, developers can now leverage the analysis by synchronizing with the project. If you are using Eclipse with CDT, Eclipse with Java, or Visual Studio, the process is a simple push-button approach to set up the synchronization and perform the analysis. If you are using kwcheck on the command line or running Klocwork in another IDE, it is essential to have a build specification prior to analysis.

There are two ways to generate a build specification at the desktop:

1. Generate a build specification on the fly
2. Use the build specification from the integration project

Option #1 is highly recommended. This option allows the developer to simply create a build specification for the file/modules before performing any analysis on the desktop. The advantage is that you will always get the most up-to-date build specification possible, even for a new file. This method requires the developer to compile code and run a Klocwork build assist tool, such as kwinject, directly in their environment. Alternatively you can use kwshell to automate the process.

Option #2 has the advantage of just using the integration project build specification that was already generated. This option can only be used if developers use the same paths to work on files as the build machine which is used to build the entire system. This is usually fairly unlikely. Additionally, this method does not allow the analysis of new files created on the desktop.

See also Fixing issues before check-in with Klocwork Desktop Analysis.

Once analysis is complete, you can further tune the issue detection in two ways:

• edit the checker configuration
• Tune the analysis through macro simplification or the Klocwork knowledge base (KB).

If you find that there are too many issues of a particular type, you may choose to disable it in the configuration file. Alternatively, you may find that the list is minimal and therefore you want to enable more issues and vulnerabilities.

In some cases, you may notice false positives in the analysis. There are several ways to configure the knowledge base (KB) to reduce or eliminate false positives. See Tuning C/C++ analysis and Tuning Java analysis.

The frequency of your analysis builds will vary depending on your software development process. You may choose to implement nightly builds or weekly builds, or even iteration builds if your developer subscribe to the agile development approach.

Typically you perform an analysis build per release or iteration, per milestone, and then more frequently as needed. Intermediate builds can then be cleared up, per milestone. See Managing integration projects and builds, "build retention policy" for more information.

For large software projects, many organizations focus efforts on newly introduced issues by creating a baseline. This is the practice of performing analysis on a specific build (typically, the first Klocwork analysis of a project) and marking all Klocwork reported issues and vulnerabilities into "Defer" status. This allows the organization to focus only on new issues and vulnerabilities identified in subsequent builds by assigning all existing Klocwork issues to a given holding status. The baselined issues have not disappeared, they are just not visible by default in the developer views, but they can be viewed and returned to an actionable status as and when resources allow and management deems this worthwhile. This aspect is covered by Stage X: Address the backlog.

Baselines can also assist where there are legacy code bases that have already been approved or proven as acceptable and Klocwork is being used merely to ensure that any future modifications are checked for quality, security or compliance. Lastly, the baseline strategy does not necessary have to apply to all issues but can be selective based on perhaps issue severity, or by importing existing granted deviations from other tools or source code comments.

Once baselines of issues have been achieved, developers can use Klocwork Static Code Analysis or the developer tools to apply the appropriate statuses. Everyone should know or be educated about what the statuses represent (Phase I, Stage 7), and issues and vulnerabilities should be marked off with a new status. At this point, developers must fix issues that are in "fix" state.

Subsequent analysis runs are then performed and the entire process begins again.

If Stage 5 is used, establishing a baseline will create a backlog of issues which will, at some point, need to be investigated. This can be done after Klocwork has been used to reduce issues found in new development to a manageable level. This stage is optional and addressed only when resources can be allocated.

Often the process of dealing with existing issues in legacy code is a separate task given to experienced developers that have an understanding of the code in which they are making changes.

With measurable metrics at hand, you can make significant improvements in your processes and productivity. Klocwork provides numerous metrics and trending data that can be used to measure your code such as size, complexity, issue counts, security vulnerabilities and churn. This data will help you to assess and prioritize the development of your software, and will enable you to identify areas of concern and assist in making plans for code improvements or other testing and analysis strategies going forward.

If you deploy Klocwork at both the desktop and integration build levels, the number of issues found in the integration build will decrease over time, due to developers addressing issues before check-in. Klocwork Static Code Analysis can be used to monitor this trend, along with other metrics of interest.

Klocwork provides additional granularity to measure the number of issues or vulnerabilities that are fixed at the desktop. If your organization is using the developer IDE plug-ins or kwcheck, Klocwork will keep track of issues fixed at this level even though these issues will never reach the integration build.

Once Klocwork is integrated into your ongoing development processes, the data that it holds and provides will become invaluable. Therefore it is very important to ensure that you have initiated, verified, and monitored your Klocwork database backup (and restore) procedures. See Backing up Klocwork data.