vThe users who have access to the component and the level of access each user has. This information makes up the component's access list.

vThe users who are to be noti®ed about changes to the component. This set of users is called the noti®cation list.

vThe process by which the component handles defects and features.

Releases

An application is likely to contain parts from more than one component. Because you probably want to use some of the same parts in more than one application, or in more than one version of an application, TeamConnection also groups parts into releases. A release is a logical organization of all parts that are related to an application; that is, all parts that must be built, tested, and distributed together. Each time a release is changed, a new version of the release is created. Each version of the release points to the correct version of each part in the release.

Each part in TeamConnection is managed by at least one component and contained in at least one release. One release can contain parts from many components; a component can span several releases. Figure 3 shows the relationships between parts, the releases that contain them, and the components that manage them.

Figure 3. Parts, releases, and components

Each time a new development cycle begins, you can de®ne a separate release. Each subsequent release of an application can share many of the same parts as its predecessor. Thus maintenance of an older release can progress at the same time as development of a newer one. Each release follows a process by which defects and features are handled.

Work areas

A release contains the latest ²official² version of each of its parts. As users check parts out of the releases, update them, and then check them back in, TeamConnection keeps

8User's Guide

Page 28
Image 28
IBM SC34-4499-03 manual Releases, Work areas