Configurações de Registro

É possível utilizar as configurações em todo o sistema para tipos de registros, para ajudar a gerenciar, categorizar e aplicar as políticas de segurança nos processos de trabalho.
Os seguintes tipos de configurações amplas do sistema são para gerenciar ambos os projetos e trabalho:

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.

Exemplo de Desenvolvimento de Componente

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.

Um cliente localiza um problema em um produto maior produzido pela sua equipe de desenvolvimento. Este Produto (conhecido como Oferta) inclui diversos Componentes, cada um dos quais é desenvolvido por equipes separadas. Quando o cliente encontra o problema, ele pensa na Oferta como se tivesse o problema e não nos Componentes da Oferta. Quando a orientação da equipe segue o processo de triagem para um Pedido para essa Oferta e revisa o Pedido, ela notará que:
  • O problema está em um Componente incluído na Oferta e precisa ser corrigido nesse local e não na Oferta, que pode não ser nada mais do que uma coleta de Componentes e não ter qualquer de seus próprios códigos separados daquilo que acompanha os Componentes incluídos
  • A Oferta precisa incluir a nova versão do Componente depois de ser corrigida e uma nova versão dessa Oferta precisa ser fornecida para, no mínimo, o cliente que descobriu o problema e provavelmente para todos os outros clientes.
A equipe de triagem cria dois registros ALMTask que estão associados ao ALMRequest digitado no Projeto para uma determinada Categoria e Release (por exemplo, Categoria='OfferingA' e Release = '1.0'):
  • ALMTask com Categoria de Projeto='OfferingA' e Release = '1.1'
  • ALMTask com Categoria de Projeto = 'ComponentZ' e Release= '3.4'
A equipe de triagem primeiro revisou o registro ALMBaseline para a Categoria de Projeto='OfferingA' e Release = '1.0' porque esses valores são aqueles que o ALMRequest identificou como FoundInProject e podem ver que o Release do 'ComponentZ' que está listado no campo ALMBaseline ComposedOfBaselines é Release = '3.3'.

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.


Feedback