사용자가 정의하는 프로젝트 카테고리는 시스템 전반에서 사용 가능합니다. 카테고리를 여러 프로젝트에서 재사용하고 일관적으로 분류할 수 있습니다. CategoryType 레이블도 시스템 전반에서 사용할 수 있습니다. 보안 정책으로 카테고리의 보안을 설정하여 특정 사용자에게 카테고리를 숨기거나 사용 가능하게 할 수 있습니다. 카테고리와 카테고리 유형으로 프로젝트의 분류 시스템을 모델링할 수 있습니다. 계층 구조 카테고리 세트를 정의하여 대규모 시스템을 보다 관리하기 쉬운 소규모 단위로 나눌 수도 있습니다.
하나 이상의 ClearQuest® 그룹을 ALM 보안 정책 레코드에 추가하여 보안 정책을 정의합니다. 보안 정책이 설정되면 프로젝트 관리자는 새 프로젝트를 작성하고 이 프로젝트에 필요한 기존 보안 정책을 선택할 수 있습니다. 새 정책이 필요한 경우에만 보안 정책을 정의해야 합니다.
관리 레코드 유형은 누가 프로젝트, 카테고리, 레이블을 작성할 수 있는지 판별합니다.
유형은 작업의 네이처를 식별하는 데 사용됩니다. 유형은 요청, 태스크, 활동 레코드에 적용됩니다. 시스템 전반에 유형을 설정합니다. 그러면 프로젝트 팀이 작업 구성을 작성하여 사용할 유형을 구성합니다. 유형의 몇 가지 예로 개선사항, 결함, 새 기능이 있으며 단 이에 한하지 않습니다.
ALMSecurityPolicy 레코드는 카테고리와 연관되며 카테고리를 참조하는 프로젝트가 작성되면 프로젝트와도 연관됩니다. 컴포넌트 개발을 수행하는 팀의 경우 각 컴포넌트에 자체 카테고리와 릴리스가 하나 이상의 오퍼링의 일부로 포함된 여러 컴포넌트가 있을 수 있습니다. 이 경우 카테고리와 SecurityPolicy 간의 일대일 관계로 인해 일부 레코드가 이 레코드를 필요로 하는 사용자에게 표시되지 않을 수 있습니다. 이와 같은 가시성 문제를 해결하려면 SecurityPolicy에 하나의 대규모 ClearQuest 사용자 그룹이 ratl_context_groups 참조로 포함되거나 컴포넌트에 대해 작업하는 모든 개발 팀이 공유할 SecurityPolicy에 참조되는 모든 사용자 그룹과 함께 각 컴포넌트의 사용자 그룹이 있어야 합니다. 하나의 대규모 그룹을 사용하는 것보다는 규모가 작은 그룹 세트를 유지보수하고(또는 SecurityPolicy를 Everyone 그룹으로 설정) 컴포넌트 구조로 그룹과 SecurityPolicy 레코드를 구성하는 것이 성능에 도움이 됩니다.
버전 지정된 새로운 각 개발 작업은 카테고리가 컴포넌트를 지정하고 릴리스가 이 카테고리의 버전을 지정하는 프로젝트일 수 있습니다.
'ComponentZ'의 ALMTask에 대한 활동이 작성되고 솔루션이 개발, 문서화, 테스트됩니다. 실제 기준선이 작성될 때 프로젝트 카테고리='ComponentZ' 및 릴리스='3.4'에 대한 ALMBaseline 레코드가 작성되고 프로젝트 카테고리='OfferingA' 및 릴리스='1.1'에 대한 두 번째 ALMBaseline이 작성됩니다. 이 ALMBaseline 레코드에는 프로젝트 카테고리='ComponentZ' 및 릴리스='3.4'인 ComposedOfBaseline 값(다른 기준선 레코드)이 있습니다.
프로젝트 카테고리='OfferingA' 및 릴리스='1.1'인 ALMBaseline에 대한 BTBuild가 작성됩니다. 테스터는 프로젝트 카테고리='OfferingA' 및 릴리스='1.1'인 태스크의 활동 양식 제어에 표시되는 'Dev' 활동의 Composite.Build 열과 빌드 열에 BTBuild가 표시됨을 확인할 수 있습니다. 컴포지트 기준선에서 생성된 최소 하나의 빌드 ID가 있음을 확인하고 조회의 결과 세트에서 이 빌드의 이름을 볼 수 있습니다. 컴포넌트 테스터와 오퍼링 테스터가 모두 컴포지트 기준선을 기반으로 하는 빌드가 있음을 확인할 수 있습니다.
컴포지트 기준선 레코드에서 컴포넌트가 ComposedOfBaselines 필드에 나열됩니다.