The philosophy of static code analysis is very simple. The earlier a bug is found, the cheaper it is to fix. Static analysis tools carry it out in three steps.
Step one. Simply start using static analysis, no matter how often. If you have never used it previously, once a month will do. Just make sure you do that. A bug found by you is cheaper to fix than one found by your customer.
Step two. Start running static analysis on the build server at night. Catching bugs daily rather than once in a while makes them cheaper to fix.
Step three. Have the static analysis tool installed on your developers' machines as well. Fixing bugs the next day after a night build is nice, but what if the developers could fix them before their code gets to the repository? Use the analyzer while writing the code so that you could immediately check only those files that have been modified during the last build.
Have a huge project? And get a pile of messages you can't cope with? Just ignore them! Mark these messages as irrelevant and you won't see them again. This allows you to start benefitting from static analysis right from the first day of use, as warnings will be issued only for freshly written or modified code.
Static analysis to replace other methodologies? Static analysis is not a cure-all! It can't replace unit testing or code review. Static analysis is an answer to the question: "What else can we do to make our code better?" What does it mean, "better"? It means that it's easier to maintain, develop, and fix. If your company's income depends on software code, you simply can't do without static code analysis.