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