Project Decomposition Terms

There are a least a dozen different terms in broad use for very similar concepts. We are trying to focus our own nomenclature to give us a more consistent presentation to each other and to the world. Using the same terms to mean precisely the same things, we lower to barrier to introducing consultants to projects—the uncertainty is reduced because the form is familiar like sitting in your favorite chair.

Project decomposition is an important principle for surviving complex software projects. It allows planning in smaller, more manageable chunks of time and functionality. It creates regular milestones that make progress tangible. It enforces rigor to finish and finalize in smaller, less taxing increments. Do it, you will like it.

Iterations are temporary build milestones:

• 1-2 weeks of effort, design/build/unit test
  
• Demo-ready
  
• Increment your patch-level RuleSet versions for each
  

Slivers are temporary build artifacts:

• 6-8 weeks of effort [3-4 iterations], design/build
  
• Smaller, individually-useful, 'partial' applications
  
• Tested [2 week], patched and documented
  
• Production-ready, but not necessarily deployed
  
• Increment your minor-level RuleSet versions for each
  

 

Modules are a permanent design elements:

• Technical vs. Functional
  
• Reusable and Individually testable
  

Releases are a temporary deployment artifacts:

• One or more Slivers, though ideally no more than 2
  
• Practical selection based on deployment windows
  
• Production visible, so involved transition activities such as training and support
  
• Increment you major-level RuleSet version for each
  

Applications are permanent production artifacts

• Increment your Application record version for each