Overview of the UCM process

In UCM, your work follows a cycle that complements an iterative software development process. Members of a project team work in a UCM project. A project is the object that contains the configuration information needed to manage a significant development effort, such as a product release. A project contains one main shared work area and typically multiple private work areas. Private work areas allow developers to work on activities in isolation. The project manager and integrator are responsible for maintaining the project shared work area. Work within a parallel development environment progresses as follows:

1. You create a project and identify an initial set of baselines of one or more components. A component is a group of related directory and file elements, which you develop, integrate, and release together. A baseline is a version of one or more components.
2. Developers join the project by creating their private work areas and populating them with the contents of baselines that are used by the team.
3. You or your developers create activities and the developers work on one activity at a time. An activity records the set of files that a developer creates or modifies to complete a development task, such as fixing a bug. This set of files associated with an activity is known as a change set.
4. When developers complete activities, they build and test their work in their private work areas.
5. They share their tested work with the project team by performing deliver operations. A deliver operation merges work from the developer’s private work area to the project shared work area.
6. Periodically, the integrator builds the project executable files in the shared work area, using the delivered work.
7. If the project builds successfully, the integrator creates new baselines. In a separate work area, a team of software quality engineers performs more extensive testing of the new baselines.
8. Periodically, as the quality and stability of baselines improve, the integrator adjusts the promotion level attribute of baselines to reflect appropriate milestones, such as Built, Tested, or Released. When the new baselines pass a sufficient level of testing, the integrator designates them as the recommended set of baselines.
9. Developers perform rebase operations to update their private work areas to include the set of versions represented by the new recommended baselines.
10. Developers continue the cycle of working on activities, delivering completed activities, updating their private work areas with new baselines.