Automating CM or Application Lifecycle Management

difference between these two cases? Why are they not treated the same? The goal is to minimize manual actions and increase data accuracy. If 92% of problems and 24% of features are implemented by a single change, we're helping to achieve the goal. But we can do better, so we take the 8% and say: don't promote the problem to fixed if there's another change against the problem which has not yet been checked in. This gives us another 2% or 3% data accuracy. Policy decisions often deal with increasing data accuracy. It doesn't mean that we don't need a more strict process to improve it further. But it does mean that we can improve it further with fewer resources. Whether or not we do this automated promotion is a policy decision. In CM+ such policy decision would be implemented, typically, as part of a trigger, whether a state transition trigger or a trigger on another type of user action.

Complexity of Views and Terminology

The final area I'd like to discuss is that of complexity. It's very easy to make a simple process complex. In the 1980s, someone introduced the term Artificial Intelligence, or AI. It came across as a technology breakthrough. I couldn't see it. It didn't look different from what we had traditionally done. And it wasn't. Apart from Neural Network technology, there wasn't anything new - but it was a phrase that caught on well. I didn't like it because it made me think that I was missing something. To me this was an added complexity until I figured out that AI was an encapsulation of current techniques under an umbrella - not a breakthrough.

With process it's the same. Don't throw new terms at your audience for no reason. If your corporated culture has always called a problem report a DPAR, continue to do so. Everyone's familiar with the term already. Over the long term you can still gradually adopt industry terminology. But do so carefully.

We have bigger problems in terminology in the CM and ALM worlds. The word baseline is used when it's not immutable. The phrase "check out" is used by some even when you're not checking out (i.e. borrowing, reserving, locking,...) a file. A product is often referred to as a project. The concepts of task and change package are sometimes confused. Is a delta report the same as a difference report?

So the task is difficult. Use the most accepted terminology in your environment. Lean it toward the CM industry when the CM industry agrees on a term. Don't invent new terms. For automation to be achieved, everyone must have a common understanding.

Context Views

There's plenty of data in an ALM environment. Automation isn't just performing automatic data transitions. It involves presenting an intelligent set of alternatives in the right order. For example, if I perform a non-object-oriented operation, say a check-in operation, I want the CM tool to popup the most likely change, not just an arbitrary list. Context views can help here. An ALM environment must allow you to identify the product and development stream/release/build that you're focused on. When you do, the tool can narrow down choices for you and present most recently used or otherwise most likely objects as the default.

The goal is to reduce the complexity by setting a context. Within a context, the parallel development world can look like a single stream of development for the most part. When you ask for outstanding problem reports and your view is release 2 of product ABC, you see only those problem reports outstanding for