In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.
Product versus Project
Product, project. We all know what a product is and what a project is, don't we? So why would these two terms cause confusion in a development shop, some may ask. Others know. The primary reason is the use of the term project in IDEs, such as Eclipse and Microsoft's Visual Studio. The IDEs want to focus on the project that is being completed as part of the development effort. But in the end, the IDE project outlasts the project. In fact, product would have been a better word, or perhaps deliverable, deliverable set, or package. An IDE project creates some deliverable(s). When the release is all done, the IDE project persists to create the deliverables for the next release.
Traditionally, a project is a managed set of activities, and this set of activities culminates, frequently, in a release, be it a new internal/external release, a variant Release or a milestone. The project is identified by a work breakdown structure which outlines the activities to be performed. An IDE may be used for some of these activities (and a wider set in more recent IDE releases), but the IDE project is a misnomer.
A product is a collection of deliverables which together meet a product specification. A product may be a hierarchy of products, with sub-Products being reusable across multiple products. So here's my take:
My Vote: Product, project and IDE project
1) Product: A collection of deliverables which meet a product specification
2) Project: A managed set of Activities culminating in a release or other milestone
3) IDE Project: The term used by some IDEs for their product file collections
Process flow, work flow, state flow. I'm not really sure if there is confusion about these terms in the industry. It's hard to tell. But just to be sure, here's my take on them.
State flow (also known as state-transition flow). State applies to an item/artifact. As it moves through the process it assumes different states which indicate who may act on it and what actions are permitted. For example, a problem moves from its original state through a triage process that puts it in one of several states. Eventually the problem gets fixed or answered and reaches a closed state. Only the originator of the problem can agree that it is closed (i.e., the original problem has been addressed, and this would only be done once the problem reached some sort of fixed and tested or answered state).
Work flow. Work flow shows how some input flows through the system to cause some output. For example, a request may cause a feature activity to be created which may cause a change to requirements. The activity may