It’s also important to think about the maturity of the product under development because it impacts the method for static analysis.
- Existing project: in current development
Static analysis is most commonly rolled out in the midst of current projects. Each project can adopt the tools at the beginning of a sprint or major feature update.
Recommended approach: a line in the sand – improving new code as it’s developed while deferring less severe warnings as technical debt.
- Existing project: product on the market in maintenance
This is a product that is in the elder years of the software development lifecycle, in which little new code is being written – only to fix lingering bugs and security vulnerabilities.
Recommended approach: acknowledge and defer – Since little new code is being developed, all discovered bugs and security vulnerabilities are added to existing technical debt.
- Greenfield project
Although it’s not often that software teams get to have a fresh start, a new product and project is the ideal point to integrate new tools and techniques into the development process. In these projects, little existing code specific to the project exists, but it still may rely on third-party and open-source software.
Standard approach: greenfield – Developers can integrate static analysis in their development environments from the start, ensuring a high standard of quality as code is being written. This allows for the adoption of coding standards and ensuring critical static analysis warnings are dealt with as they arise, thus adding less bugs and vulnerabilities.