As categorias do projeto definidas estão disponíveis em todo o sistema. Isso permite a reutilização e a classificação consistente através de vários projetos. Os rótulos CategoryType também estão disponíveis em todo o sistema. As categorias podem ser protegidas por uma Política de Segurança e, desta forma, estarem disponíveis ou ocultas a partir de um usuário específico. As categorias e os tipos de categorias permitem modelar seu sistema de classificação para os projetos. Também é possível definir um conjunto de categorias hierárquicas para decompor sistemas maiores em unidades menores mais gerenciáveis.
As políticas de segurança são definidas incluindo um ou mais grupos ClearQuest em um registro da Política de Segurança ALM. Quando definido, os gerentes de projetos podem criar novos projetos e escolher a política de segurança existente necessária para esse projeto. Você precisa apenas definir uma política de segurança, se uma nova política for necessária.
O tipo de registro Admin determina quem pode criar projetos, categorias e rótulos.
Os tipos são utilizados para identificar a natureza do trabalho. Eles se aplicam aos registros de Pedido, Tarefa e Atividade. Configure os tipos em todo o sistema. Em seguida, as equipes do projeto configuram quais tipos utilizar para criar uma Configuração de Trabalho. Alguns exemplos de um Tipo incluem, mas não se limitam ao, Aprimoramento, Defeito e Novo Recurso.
Os registros ALMSecurityPolicy estão associados a uma Categoria e também estão associados aos Projetos, como são criados Projetos que fazem referência à Categoria. Para equipes que executam o desenvolvimento de componente, pode haver vários Componentes, cada um com suas próprias Categorias e Releases, como parte de uma ou mais Ofertas. Neste caso, um relacionamento um a um entre uma Categoria e uma SecurityPolicy pode fazer com que alguns registros não sejam visíveis às pessoas que precisam vê-los. Para evitar problemas de visibilidade, um SecurityPolicy deve incluir um grupo de usuários ClearQuest grande como sua referência ratl_context_groups ou deve ter um grupo de usuários para cada componente com todos os grupos de usuários referenciados pela SecurityPolicy que devem ser compartilhados por todas as equipes de desenvolvimento que trabalham nos componentes. Também existem benefícios de desempenho ao manter um conjunto de grupos menores do que utilizar um grande grupo (ou configurar uma SecurityPolicy para o grupo Everyone) e organizar grupos e registros SecurityPolicy pela estrutura dos componentes.
Cada parte com versão do novo trabalho de desenvolvimento pode ser um Projeto com uma Categoria que especifica o componente e um Release que especifica a versão dessa Categoria.
As atividades são criadas para ALMTask para 'ComponentZ' e a solução está desenvolvida, documentada e testada. Um registro ALMBaseline é criado quando a linha de base real for criada para a Categoria de Projeto = 'ComponentZ' e Release = '3.4' e uma segunda ALMBaseline for criada para a Categoria de Projeto = 'OfferingA' e Release = '1.1' e que o registro ALMBaseline possui um valor ComposedOfBaselines (outro registro de Linha de Base) que possui uma Categoria de Projeto = 'ComponentZ' eRelease = '3.4'.
Um BTBuild é criado para ALMBaseline cuja Categoria de Projeto = 'OfferingA' e Release = '1.1'. Os testadores podem ver que um BTBuild é exibido na coluna Construção e a coluna Composite.Build da Atividade 'Dev' exibida no controle de Formulário de Atividade da Tarefa cuja Categoria de Projeto = 'OfferingA' e Release = '1.1'. Eles podem ver que existe, pelo menos, o ID de uma Construção produzido a partir da linha de base composta e, no conjunto de resultados da consulta, eles podem ver o nome dessa Construção. Os testadores de Componentes e os testadores de Oferta podem ver que existe uma Construção baseada na Linha de Base Composta.
No registro Linha de Base Composta, o Componente é listado no campo ComposedOfBaselines.