The project categories you define are available system-wide. This allows for reuse and consistent classification across multiple projects. CategoryType labels are also available system-wide. Categories can be secured by a Security Policy and so they are available or hidden from a particular user. Categories and category types allow you to model your classification system for projects. You could also define a set of hierarchical categories to decompose large systems into smaller more manageable units.
Security policies are defined by adding one or more ClearQuest® groups to an ALM Security Policy record. Once set, project managers can create new projects and choose the existing security policy needed for that project. You only need to define a security policy if a new policy is needed.
The Admin record type determines who can create projects, categories, and labels.
Types are used to identify the nature of the work. Types apply to Request, Task, and Activity records. You set the types system-wide. Project teams then configure which types to use by creating a Work Configuration. Some examples of a Type include, but are not limited to, Enhancement, Defect, and New Feature.
ALMSecurityPolicy records are associated with a Category, and are also associated with Projects, as Projects are created that reference the Category. For teams doing component development, there can be several Components, each with its own Categories and Releases, as part of one or more Offerings. In this case, a one to one relationship between a Category and a SecurityPolicy may cause some records to be not visible to people that need to see them. To prevent visibility issues, a SecurityPolicy should include either one large ClearQuest user group as its ratl_context_groups reference or it should have a user group for each component with all of the user groups referenced by the SecurityPolicy that would be shared by all of the development teams working on components. There are also performance benefits by maintaining a set of smaller groups rather than using one large group (or setting a SecurityPolicy to the Everyone group), and organizing groups and SecurityPolicy records by the structure of the components.
Each versioned piece of new development work can be a Project with a Category that specifies the component and a Release that specifies the version of that Category.
Activities are created for the ALMTask for 'ComponentZ' and the solution is developed, documented and tested. An ALMBaseline record is created when the actual baseline is created for Project Category = 'ComponentZ' and Release = '3.4' and a second ALMBaseline is created for Project Category = 'OfferingA' and Release = '1.1' and that ALMBaseline record has a ComposedOfBaselines value (another Baseline record) that has a Project Category = 'ComponentZ' and Release = '3.4'.
A BTBuild is created for the ALMBaseline whose Project Category = 'OfferingA' and Release = '1.1'. Testers can see that a BTBuild is displayed in the Build column and the Composite.Build column of the 'Dev' Activity displayed in the Task's Activity Form control whose Project Category = 'OfferingA' and Release = '1.1'. They can see that there is at least the ID of a Build produced from the composite baseline and in the result set of the query they can see the name of that Build. Component testers and Offering testers can both see that there is a Build based on the Composite Baseline.
In the Composite Baseline record the Component is listed in the ComposedOfBaselines field.