that once a work item is finished, it cannot be moved back to the working state: doing so would require undeploying the work item. This restriction comes from database support: once a SQL statement has been applied, there is no going back.
A Work Item is not a software artifact. It is not a file, not an SQL statement, not a library or executable. A work item is a database entity that exists in the same issue tracking system that contains the change order records, as well as in the CM repository that contains the actual software being modified. A ‘work item' is an issue, a task, a change package, a change set.
Whatever concept your tool uses to bundle together changes to multiple software components (files, directories, tables, etc.)-that is a work item. If your tool provides a special built-in entity for this purpose-and most advanced commercial CM tools do-you may have to create a more general work item type using the life cycle editor because the special entities are frequently limited as to what customizations you can perform. Moreover, if you have to combine two or more commercial tools it is probably best to pick one "top" tool and then integrate that tool with the others.
Because work items are the lowest-level entity in the software change process, the amount of metadata associated with each individual work item should be minimized. In our initial LBCM implementation, work items have very few user-specified attributes.
There are no loops in the life cycle: a work item begins in the Working state, and transitions to either Finished or Abandoned. A Finished work item that is not a part of a usable bundle (either no bundle, or a bundle marked as being invalid) may be transitioned to Abandoned. Work items are very simple, very straightforward entities.
Change orders are more complex, and the change order life cycle includes the develop/test/fail loop that the work item life cycle does not. Change orders are what most people think of when they think about doing CM: a document detailing the specifics of the change, traceable from the time it is submitted until it is delivered to the customer. A change order corresponds to a defect or enhancement request, and so each change order implicitly has a test case of some sort associated with it. This test case(s) decides when a change order is satisfied and can be considered delivered. If a developer completes a work item associated with a change order, and the work item is not sufficient to pass the tests for that change order, then the work item remains closed (and deployed on whatever servers it is deployed to), a new work item is added to the change order and additional work performed.
When a change order involved more than one technology in our implementation, we broke it down into at least one separate work item per technology. This was not a requirement of LDM, but was an artifact of the organizational structure at work: Cobol people were different from Java people. (Recall that a work item is usually developed by a single person.) LDM work items will be capable of spanning technologies if your scripting and abstraction permit it. But creating multiple work items is relatively cheap, and also quite likely to be compatible with your political boundaries.
Because thechange order is where most of the work flow modeling occurs, that is where most of the data is going to be collected. The illustration shows only a few fields because any attempt at an exhaustive list would