Component-oriented Projects
Development teams can organize their work in terms of reusable assets. These teams use projects to create individual components and composite baselines that select baselines of several components. Low-level or core components can be used to construct mid-level components or subsystems, until the highest level components are integrated into a product.
In the figure, project X uses components A and C to produce a set of baselines that define the X subsystem, and project Z uses components B, C, and D to implement the Z subsystem. Project Y uses the subsystems created by the X and Z projects, represented by the baselines that these projects produce. Additionally, project Y does custom work in component E.
The key attribute of managing the configuration is that all the code of a subsystem is released together. To the development team, the important factor is that the subsystem represents assets that can be easily reused. Designing a product, or a family of products based on subsystems allows the development effort to be divided into logical units. This organization simplifies the development efforts, allows better management for risk, and provides opportunities for code reuse.
The key aspect of this organization is that each project has access to two classes of components: modifiable components and read-only components. Each project does its development work on modifiable components, and only one project can modify these components. The read-only components are shared, but projects do not plan to modify the read-only components, because that violates the sharing model. Accordingly, these shared components are specified to be read-only in the project.
The teams in a development group with this type of project organization are restricted to a limited number of components that they can modify. Because the lower level components can be shared, the changes must be made in a central, compatible manner, in the project dedicated to that component. For example, if project Y needs changes in the A and C components, that work must be done in project X.
In a component-oriented organization, each project has more freedom in selecting baselines of shared components. Because these shared components are not modified by the project, theoretically the project should be able to change from one version of a shared component to any other version of that component. The component-oriented project organization works well when components are loosely coupled with well-defined interfaces. This type of project organization tends to promote component reuse more effectively than the release-oriented project organization does.