Topic: wftk -- Usage scenarios: Closed-source software project

wftk home ] [ usage scenarios ] [ discussion ]
In contrast to open-source projects, which consist of many small changes, closed-source projects (in my experience) are characterized by many requests rolled into a single large release. The general way this happens is as follows, really:
  1. Users request changes or identify bugs for some time.
  2. At some point, an analyst selects a number of change requests and says those requests will make it into the next release.
  3. The analyst creates a project plan for achieving the release.
  4. Developers execute the project plan.
  5. For each change completed, there are certain tasks to be done: unit test, integration test, regular builds, and so forth.
  6. After development, the new release is deployed.
(2/21/00) XML process definition here.

There are two things about this scenario that differ from the previous ones so far: first, we're talking about several workflow processes in an integrated system, and second, the step "execute the project plan" is exactly an ad-hoc process and beautifully supported by the notion of a compound process. The cool thing being that the subprocess to be executed is itself a deliverable of an earlier step.

Multiple workflow processes in an integrated system
OK, we've talked about this idea already, it's true, in the open-source usage scenario. But this is a little more complicated. For instance, one process is the bug submission process. The user notes a bug, somebody gets notified and checks it out, and a change request may or may not be created in the database. Another is the release planning process, which is really the main process in this outline. Another is the unit change approval process: the developer signals completion, testing is done by another department, the test plan might be changed, and after acceptance, that task in the subprocess "execute project plan" is considered complete, at which point the engine determines which task(s) come next.

My point in all this is that the processes must be aware of one another, must be bound to one another and capable of affecting one another. A sufficient mechanism for this would be a set of functions available to process definitions which would provide the functions mentioned in the open-source scenario.

Ad-hoc compound processes
The problem here that I had originally was that the project plan is a deliverable and a subprocess definition. But Thomas's idea of multiple repositories for scalability also solves this problem neatly: if the deliverable repository is made available as an alternate process definition repository, then it's easy to see that when it's time to execute the project plan, we just copy the current version of the deliverable and start executing.

This was originally the first of my scenarios which showed a compound process, and at the time it was quite mind-blowing. Of course, Anthony had anticipated me, so now it doesn't look as astounding. Ah well.


  • Processes exist in a system of processes. Processes must have facilities to affect one another. (Already covered in the open-source scenario.)
  • The definition of a subprocess may be a deliverable of an earlier task in the current process. This is best served by allowing the deliverable repository function as a "remote" process definition repository.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.