In this section:
Specify the policy type (fixed or gated).
A gated policy can be parameterized so that you can establish different thresholds at different gates and different points in time.
A fixed policy cannot be parameterized in this way; it is always applied in the exact same way.
For example, you might have a defect prevention policy requiring compliance to an increasingly strict set of static analysis rules as the SDLC progresses: maybe the initial phase might require compliance only to severity 1 rules, but compliance to severity 1-3 rules must be achieved by code freeze.
Specify metadata, such as version, description, author, and approval information.
Document policies in natural, understandable human language within the context of the associated business goals. For example, if you want a policy that requires all methods to be unit tested, benefits to the business should be clearly described.
Quantifying risk is an important step in achieving a credible and compelling reason for action. For example, this might involve quantifying the cost of an outage or understanding the impact to brand equity in quantifiable terms. Far too often, the concept of software quality is addressed in a "fluffy" manner of fear, uncertainty, and doubt rather than of known quantifiable impacts. With an understanding of business demands, development teams can then focus their efforts on the aspects of the application that are truly most important to the business.
Click the Clone Policy button to create a policy with duplicate settings>
Click Delete to delete the policy.