Incorporating metrics into CI / Production ready software every day

From CitconWiki
Revision as of 21:05, 9 April 2008 by 166.217.94.7 (talk)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Metrics To Consider - Code Duplication - Cyclomatic Complexity - Dependency Analysis - Code Coverage - Coding Standards

Tools

  • Simian (Code Duplication)
  • PMD/CPD (Code Duplication)
  • Source Monitor/JavaNCSS (Cyclomatic Complexity)
  • FxCop (Coding Standards)
  • JDepend (Dependency Analysis)

Key Concepts Trends are more important than data points when considering metrics.

Choosing thresholds based on current status can help direct you to look for trends. (As opposed to arbitrarily picking a number and shooting for it)

Possible rule of thumb for cylomatic complexity: If 3% to 4% of your code has a cc number of greater than 10.

Production Ready Software Every Day: Is it possible? Desirable? Trying to ship production ready software every day poses some issues. First, what does it mean to be "production ready"? Is this the point at which you throw it over the wall to the testers? It was mentioned that in some industries SOX and other regulations require independent testing before shipping. So while it might be possible to throw new software over the wall every day, it might not be possible to ship every day.

Documentation is another issue. If you make changes to functionality, the documentation will most likely lag. Are there ways to bring the documentation people into the process sooner so the documentation happens parallel to development?

Unresolved Question In the "over the wall" testing, how much should the testers be told about what changed? Will telling them about new functionality bias their testing to only that new area?