After some subtle (and others not so subtle) feedback, I've moved the larger post 'Visual Studio Team System: Overview of Static Analysis' off of the blogs.msdn.com main page.
If you are interested in development tools in Visual Studio Team System or a fan of Static Analysis, it might be worth the download time (The screenshots are 800x600 and are in jpg format…)
Original Post: http://blogs.msdn.com/jason_anderson/archive/2004/09/05/225798.aspx
Here’s an excerpt:
...
If you poke around MSDN and search for terms like Static Analysis, FXCop, PreFast, Code Analysis, etc, you’ll find articles about some of the early versions of Static Analysis tools from Microsoft. In fact, in various forms, Static Analysis tools have been available for a while from Microsoft SDKs, downloads, etc. With Visual Studio Team System, we are finally bringing Static Analysis to you as a fully integrated feature set in Visual Studio Team Developer. This is great stuff, check it out:
The Standard Development Process
Generally speaking, taking your code from source to binary is pretty straightforward:
[[Figure 1: Standard process of building code]]
We start with some source, we compile it, the compiler does preprocessing - checks the grammar - raises errors if it finds any and if it does not - we get a binary.
If we do get compiler errors, Visual Studio (and development tools) helps us find the error in our code and we figure out what went wrong and usually fix it in short order.
Getting a compiler error in our development environment is one of the cheapest types of errors we get in the software development process. This is because we fix the issue without getting others involved and without incurring much overhead in terms of process. Other types of bugs typically require at least one other person, and thus are more expensive. Generally speaking, the more people and process involved in finding and fixing a bug, the more expensive the issue is. Here’s a basic example:
Case 1: Developer writes code, gets a compiler error, finds the issue with the help of development tools, fixes the issue, and recompiles.
Case 2: Developer writes code, gets through compilation, and gets the new code into the daily build of the product. Tester gets the daily build of the product, writes a test against the new code, and finds a bug. Tester writes a bug report, lists the repro steps to find the bug. Developer gets the bug, uses the repro steps to see the problem, investigates the issue, finds the problem, fixes the code and checks the fix back into the daily build. The Tester gets the daily build of the product, verifies the fix and finally closes the bug.
Case 3: Product ships to customers and customers install the product. Product is used and a bug surfaces that some how made it through testing. Many customers call product support and product support specialists try to walk customers through working around the issue. Because the software is flawed (not a problem with configuration, etc) product support logs a bug about the product. Meanwhile, many more customers continue calling and having the problem with the software. In some cases, spending hours on the phone or in email communicating; only to eventually find out the issue is simply a bug. Eventually, a developer on the product team gets the bug report and investigates the issue. The issue is eventually resolved and a new build of the product is done that contains the bug fix. Now testing has to verify that the fix hasn’t caused more problems and has to do a complete testing pass on the product to make sure something unforeseen hasn’t occurred while applying the bug fix. Once the fix is approved, the product update has to be made available to all customers and all customers have to down load the fix. Each time the product is purchased, the new customer still gets a build of the product with the bug until they download the patch (or take advantage of an update mechanism).
Of course, the three sample cases above can get much more complex and complete, use other methodologies and be much more or less expensive… but I think these illustrate the point: The further from the desktop development process we get, the more expensive the process of making quality code.
The utopian case is clear: Write error free code. However, this isn’t very practical. So beyond perfectly written code, if we can get to a point where we detect bugs earlier in the software development lifecycle, we save time and money. Finding bugs earlier in the development process is what Static Analysis is all about.
...
Here's the link: http://blogs.msdn.com/jason_anderson/archive/2004/09/05/225798.aspx
