This chapter covers core concepts associated with Policy Center. See Getting Started with DTP Enterprise Pack for installation, system requirements, and other operational information.

In this section:

Policies

Policies are non-functional requirements that can be automatically monitored in an exception-based manner. For example, you could have the “Company X – Application Security Policy.” This policy would define the minimum criteria for how code should be constructed and tested to mitigate the risk of security vulnerabilities.

A policy must be automatically measurable and enforceable. Practices, such as automated static code analysis and penetration testing, can check for patterns associated with unsecured code. The policy can be enforced by monitoring test and analysis data in the background and only notifying dev/test teams when their work fails to meet the defined expectations. This "exception-based" approach prevents disruptions to team members' daily activities.

Policies often include coding standards and leverage static analysis as a mechanism for monitoring compliance. The most effective policies, though, extend well beyond single practices and include multiple levels of static analysis, regression testing, and penetration testing. Parasoft can correlate multiple factors, such as defect density, regression failures, and complexity, to enforce complex and specific policies. You can configure policies that always monitor compliance to a fixed set of criteria as well as policies whose criteria can be changed over time (e.g., to require compliance to one set of conditions in the early phases of an iteration, and a stricter set of requirements as the deadline approaches). Both types can be used to establish gates for promoting an application to the next phase of the SDLC.

Practices

Practices are any means of automatically assessing the software being produced, such as static analysis, metrics analysis, code coverage, and unit testing. When you create a policy, you can associate practices with it that define acceptable and unacceptable dev/test results.  

Individual practices are available as extensions in the marketplace.

Gates

Gates measure compliance to one or more policies at a particular point in time. If the policy expectations are not met, the gate can prevent the software from proceeding to the next phase of the SDLC.

Prior to the gate's target date, the gate indicator will visualize how close the project is to meeting the specified expectations. On and after a gate's target date, that gate indicator will visualize whether the policy expectations were met on that date.

Green indicates success, yellow indicates unstable, red indicates failure/error, and gray indicates a lack of data. See Defining Gates for details. 

Projects

Projects refers to the development projects for which you are defining policies and gates. See Creating and Managing Projects.