Automating CM or Application Lifecycle Management

of working. It's not sufficient that I can model a process. The process needs to evolve easily. I may even need several revisions of a process instantiated at the same time (e.g. the process used for release 1 vs. release 2 vs. release 3).

Smart, but normal process managers will be evolving the process. Not just a single person. And most of them will not want to have to learn yet another application so that they can change the process. Process tools must be intuitive.

All process data needs to be part of the solution. It needs to be in the repository. It needs to change in the same way as other data changes. In a multiple site solution, a change to the process at one site changes it globally. People can migrate from one site to another without having to re-learn how applications work.

So the process models need to include these concepts of fluidity, simplicity and ubiquity. When this happens processes really do evolve successfully. The other thing about process models is that a state-transition diagram does not a process model make. This is just one aspect.

Another component cuts across different applications and deals with role definition. The definition of roles extends down to permissions for state transitions, user interface components and data access. And this part of the model is crucial to ease of use, security and successful workflow. It determines what user interface the user sees, which options on dialog boxes, which menu items, and even which menus. It is recommended that one of the roles even deal with process. Process models should define specific roles, one or more of which can be assigned to each user of the application suite.

Yet another component focuses more on the Project Management application - the task-based process model. It works with the state-transition component and the roles component to spawn tasks to the appropriate in-baskets. Tasks are typically created dynamically as a result of some condition being met. For example, a system integration test task may be spawned based on the creation of a new build. Some process models will allow for recurring tasks, rather than spawning new ones all the time. For example, the system integration test task may be specific for developing a release and may roll in and out of the test team's inbox as new builds are created and subsequently integration tested.

Evolving a Process

How a process evolves is not an exact science. What is important though, is that evolution be supported in a controlled fashion. First of all, it's a good idea to split process into two or three levels of definition. Some parts of the process have to be cast in concrete.

For example, one must not be allowed to change source code without properly approved traceability data (e.g. an approved problem report or feature). Otherwise, there is no traceability for the source code change. This might be referred to as a "rule." Perhaps a "policy" is whether to use features (i.e. Product Requirements) or assigned tasks (typically a Software Requirement) as the unit of traceability. Assuming software requirements are spawned from (and traced back to) product requirements, traceability to requirements are covered either way. Perhaps an "access capability" determines whether or not a function appears in a user's application interface. This might be based more on user maturity or other factors than on hard process rules. So, for example, perhaps only designated senior designers will have the capability to sign-off on a peer review.

When discussing changes to a process, classifying it as a hard rule, a policy or