CM: THE NEXT GENERATION of Quality in your Configuration

From my perspective, the two most important guidelines are to keep it simple and to automate.  But how do you keep CM simple?  And how much effort do you spend automating?  What's the most effective marching strategy?  Let's take a look.

Process and Team Work

Take a fresh development team who have been working away for weeks or months
without any CM tools.  Now tell them that they have to start using a CM tool and put all of their existing work into the CM tool.  The complaints begin:  We don't have time to introduce a new tool.  Our designers will balk at the idea.  We don't want to lose focus and we've got a deadline to meet.

Your development team may have some valid points.  If you try the approach:  "I know you'll take a hit, but it will improve product quality", you may make some inroads, but you
may not get very far.  Rather than imposing a CM tool on your team, take a different approach.  "I want to make everyone's job easier. The result will be a better product."  Now you'll get a bit more attention. So how do you deliver?

You have to get your product from the start line to the finish line.  Not only that, but you have to make sure that what you finish with satisfies the requirements you started
with. And you have to make sure the result is of high quality.  Walk through the steps.  How are you going to accomplish this?  Well you'll need to test the product at the end.  You'll also need to ensure that all of the requirements are covered by the tests.  And then there's
everything in between:

• You take the requirements of the customer/market and turn them into a product functional specification.
• You take the functional specification and create a design around it.
• You take the design and you structure your code base accordingly.
• You fill in the modules of your code base using the best available integrated development environments.
• You integrate the modules and do some sanity testing.
• You do you full verification testing.

OK.  That's one way.  The waterfall method.  Or perhaps you prefer a more agile, iterative approach.  The big difference here is that you have various iterations running through these steps in an overlapping fashion.  You may start your specification and even your design based on only a small subset of your requirements.  Your requirements may be
phased in so that you can give your customer feedback and iteratively refine the requirements.  Your verification team can start building tests to hard requirements, or even dig up an old test suite which covers a portion of your requirements.

How you go about your design process may be very important.  The waterfall method may be most appropriate.  Agile development may work better.  But the bottom line remains that you have to start with a set of requirements and end up with a quality product that meets those requirements.

Your CM tools and processes must support you in doing this.  And don't forget,
you've already promised to make everyone's job easier.
 
The entire team needs to be part of the process.  They need to have an overview of what the ALM processes are and must have open avenues for making recommendations.  Furthermore information and input solicitation meetings should be made available. When everyone feels they are part of the process team, they will use the available avenues to recommend process improvements or to highlite problems in the process.  This will
lead to continuous process improvement, and higher quality products.

What's My Job

"Hi,
I'm Bob, a programmer on the project.  My manager gave me an API that I have to implement.  I just want to write the code in a few files in my directory, compile them and