Paramètres d'enregistrement

Vous pouvez utiliser des paramètres dans la totalité du système pour les types d'enregistrement afin de gérer, catégoriser et appliquer les stratégies de sécurité dans les processus de travaux.
Les types de paramètre système suivants permettent de gérer les projets et les travaux :

Les enregistrements ALMSecurityPolicy sont associés à une catégorie, ainsi qu'à des projets, car des projets référençant la catégorie sont créés. En ce qui concerne les équipes chargées du développement de composants, plusieurs composants peuvent être disponibles, chacun possédant ses propres catégories et éditions, dans le cadre d'une ou de plusieurs offres. Dans ce cas, une relation stricte entre une catégorie et une stratégie de sécurité peut empêcher certaines personnes de voir des enregistrements qui leur sont essentiels. Pour éviter tout problème de ce genre, une stratégie de sécurité doit inclure un groupe d'utilisateurs ClearQuest important comme référence ratl_context_groups ou doit posséder un groupe d'utilisateurs pour chaque composant. Ce groupe contiendrait tous les groupes d'utilisateurs référencés par la stratégie de sécurité et serait partagé par les équipes de développement travaillant sur les composants. La gestion de plus petits groupes au détriment d'un groupe important (ou la configuration d'une stratégie de sécurité pour le groupe Everyone) et l'organisation de groupes et d'enregistrements de stratégie de sécurité selon la structure des composants apportent des avantages en termes de performances.

Exemple de développement de composant

Chaque élément versionné du nouveau travail de développement peut être un projet avec une catégorie spécifiant le composant et une édition spécifiant la version de cette catégorie.

Un client détecte un problème dans un produit majeur développé par votre équipe de développement. Ce produit (nommé offre) contient plusieurs composants développés par différentes équipes. Lorsque le client détecte le problème, il pense que l'offre, et non ses composants, présente un problème. Lorsque le responsable de l'équipe suit le processus de tri d'une demande pour cette offre et révise la demande, on observe ce qui suit:
  • Le problème réside dans un composant de l'offre et doit être corrigé directement. La correction ne doit pas être effectuée dans l'offre, qui n'est rien de plus qu'un ensemble de composants ne possédant pas de code qui lui est propre.
  • L'offre doit inclure la nouvelle version du composant une fois celui-ci corrigé et une nouvelle version de cette offre doit être fournie au moins au client qui a découvert l'incident et probablement à tous les autres clients.
L'équipe de tri crée deux enregistrements ALMTask associés à l'enregistrement ALMRequest saisi dans le cadre du projet pour une catégorie et une édition données (par exemple, Category='OfferingA' et Release = '1.0') :
  • ***ALMTask with Project Category='OfferingA' and Release = '1.1'
  • ***ALMTask with Project Category = 'ComponentZ' and Release= '3.4'
L'équipe de tri a d'abord révisé l'enregistrement ALMBaseline de Project Category='OfferingA' et Release = '1.0' car ces valeurs représentent ce que l'enregistrement ALMRequest a identifié comme FoundInProject et constate que l'édition de 'ComponentZ' répertoriée dans la zone ALMBaseline ComposedOfBaselines est Release = '3.3'.

Les activités sont créées pour l'enregistrement ALMTask de 'ComponentZ' et la solution est développée, documentée et testée. Un enregistrement ALMBaseline est créé lorsque la version de référence réelle est créée pour Project Category = 'ComponentZ' et Release = '3.4'. Un deuxième enregistrement ALMBaseline est créé pour Project Category = 'OfferingA' et Release = '1.1'. Cet enregistrement ALMBaseline possède une valeur ComposedOfBaselines (un autre enregistrement Baseline) pour laquelle Project Category = 'ComponentZ' et Release = '3.4'.

Un enregistrement BTBuild est créé pour l'enregistrement ALMBaseline dans lequel Project Category = 'OfferingA' et Release = '1.1'. Les testeurs peuvent constater qu'un enregistrement BTBuild s'affiche dans la colonne Build et la colonne Composite.Build de l'activité de développement. Cette activité est affichée dans le contrôle du formulaire d'activité de tâche et possède les valeurs suivantes : Project Category = 'OfferingA' et Release = '1.1'. L'équipe constate la présence de l'ID d'une version produite à partir de la version de référence composite et le nom de cette version dans l'ensemble de résultats de la recherche. Les testeurs du composant et de l'offre constatent qu'il existe une version basée sur la version de référence composite.

Dans l'enregistrement Composite Baseline, le composant est répertorié dans la zone ComposedOfBaselines.


Commentaires