One can make a distinction of when static analysis MUST be run versus when it is CONVENIENT to be run. Organizations are increasingly using the results of static analysis as part of the acceptance criteria for a codebase. Meeting acceptance criteria may be just before release, before collapsing a development branch into the main line or even before a developer checks in code. It makes a lot of sense to ensure that all reported issues have been addressed as part of graduating the code from one level to the next.
Of course, we all know it's a good practice to prepare well in advance of a future requirement. By providing static analysis throughout the development process, you eliminate the situation where you're two days before release and you run the static analysis tool and find that you have hundreds of problems yet to be addressed. Clearly, fixing bugs as you develop will improve the quality and security of the software early, letting you more comfortably coast into and through your acceptance process.
What else should be in your acceptance process? The static analysis workflow is a convenient place to find and fix other problems other than just bugs. Here are some additional things that static analysis can help you enforce, conveniently borrowing the same workflow.
- Industry coding standards such as MISRA, Scott Meyers Effective C++
- Government compliance standards such as DO-178B, PCI and FDA
- Internal coding standards
- Architectural coding standards
So leverage existing workflows by adding other types of checking during the right points in the development process. And then arm the developers with the ability to meet their goals easily. The more you can push checking up front, the more likely you'll meet your time pressure goals.