The goal of most software development teams is to maximize both quality and productivity. However, when developing software, you must consider the following factors:
Changing the requirements for one of these factors can impact the other two.
Generally, the criticality of your application determines the balance between these three variables – your quality model. With classical testing processes, development teams generally try to achieve their quality model by testing the modules in an application until each module meets the required quality level. Unfortunately, this process often ends before quality requirements are met, because the available time or budget has been exhausted.
Polyspace® verification allows a different process. Polyspace verification can support both productivity improvement and quality improvement at the same time, although you have to reach a balance between these goals.
To achieve maximum quality and productivity, however, you cannot simply perform code verification at the end of the development process. You must integrate verification into your development process, in a way that respects time and cost restrictions.
This chapter describes how to integrate Polyspace verification into your software development cycle. It explains both how to use Polyspace verification in your current development process, and how to change your process to get more out of verification.
Polyspace verification can be used throughout the software development cycle. However, to maximize both quality and productivity, the most efficient time to use it is early in the development cycle.
Polyspace Verification in the Development Cycle
Typically, verification is conducted in two stages. First, you verify code as it is written, to check coding rules and quickly identify obvious defects. Once the code is stable, you verify it again before module/unit testing, with more stringent verification and review criteria.
Using verification at this stage of the development cycle improves both quality and productivity, because it allows you to find and manage defects soon after the code is written. This saves time because each developer is familiar with their own code, and can quickly determine why the code contains defects. In addition, defects are cheaper to fix at this stage as they can be addressed before the code is integrated into a larger system.