results, sign-offs, approvals, defect and impact classification, root cause analysis, and whatever other data your group or company associates with changes. A change order is just exactly what you think it is: a ticket in your change tracking system. Change orders are broken down into individual work items by the development team.
Each work item represents a logically related set of changes, usually made by a single developer. These are tight, coherent sets of changes. A work item may be created for a single change to a single value, if that is all that is required to effect the required change. Work items collect very little data during their life cycle-mainly the developer's id and the start and end time stamps. Instead, they link together the set of changes made by the developer. Work items may be implemented using the task or change set feature of your CM tool, but in many cases these built-in entities won't work and a separate issue type must be created.
A change order may be broken into work items in two different ways. First, the work items may be parallel sub-tasks of the order, each one independent of the others. Second, the work items may be sequential updates to the same area: the first item contains a bug, so a second item is created, etc. Both of these approaches work, and work items can be allocated in either fashion (or both) within a single change order.
Nearly every change control implementation includes a looping lifecycle: some mechanism whereby a change can be tested, failed, and sent back for rework. In our LDM implementation, that loop is in the change order lifecycle. All work items are one-way, no-going-back entities. When a work item fails to deliver what is required, the change order containing that work item loops, if necessary, and another work item is created.
This "accumulation" of change is a crucial part of the technical implementation. Making each work item an atomic, irreversible entity enables LDM to support database development, and significantly simplifies geographically distributed development.
If a change order has one work item already delivered to test and a second work item in development (a bug fix, or a separate sub-task), the "status" of that change order may be unclear. Is it "in development" or "partially ready for testing?" This is an implementation issue: your team's culture will decide whether status is given optimistically or pessimistically. While this uncertainty is okay for a change order, the status of the individual work items must never be unclear. Work items are either done, or not done. The question of whether a particular work item has been deployed to a particular target location is answered using back end objects.
LDM depends on having the "uncertainty" concentrated in the change orders. All of the back end objects link to the work items, not the change orders. Concentrating the uncertainty into the change order type allows the rest of the LDM model to be extensively automated.
The LDM back end is significantly different from a traditional CM solution. This part of LDM derives from the ITIL configuration tracking model, and connects the work items ( not the change orders) to discrete locations where the changes represented by the work items have been deployed. The connection uses Bundle, Deployment, and Location entities to establish an accurate picture of the configuration of each location.
Supporting database development is the sine qua non of LDM. There are traditional CM techniques that can support geographically distributed development, and some can be abstracted to support disparate development technologies. But managing changes