Suivi du travail et des sous-versions

Ces rubriques décrivent comment créer des enregistrements de version de référence et de sous-version, et comment suivre et réaliser les activités, les tâches et des demandes.

Un type d'enregistrement de projet peut être utilisé pour suivre la production d'une édition de produit. Un projet peut inclure le nom d'un produit, des informations sur l'édition et l'ensemble des itérations associées au projet. Il peut également inclure des informations sur le composant d'un projet.

A chaque modification du code source, l'application est générée et vérifiée afin de s'assurer que sa qualité est suffisante pour lancer un test. Une fois vérifiée, la sous-version est déployée sur les serveurs de test en vue du test. Ce modèle de distribution de changements du code source, de conception de l'application et de test s'applique quelle que soit la portée ou l'amplitude d'une édition (par exemple, qu'il s'agisse de la révision majeure d'une application existante, d'un correctif ou d'un correctif logiciel). Lorsque des erreurs sont détectées, les incidents sont consignés et le code source est modifié afin de corriger l'incident. Une fois encore, l'application doit être générée et déployée vers les serveurs de test en vue d'un test.

Les enregistrements ALM Baseline et Build peuvent être utilisés avec les projets utilisant les intégrations UCM IBM Rational ClearCase/ClearQuest, ainsi qu'avec ceux qui ne les utilisent pas. Les enregistrements Baseline et Build peuvent être utilisés pour s'assurer de la distribution des projets ou des éditions de produit, ainsi que des informations destinées aux clients. Par exemple, les enregistrements Baseline et Build permettent de transférer automatiquement les informations du développement au test, afin d'informer les testeurs sur des sous-versions de produit qui contiennent les correctifs de demandes spécifiques.

Le schéma ALM prend en charge un modèle de flux de travaux acceptant développement et test itératifs et parallèles. Les changements sont générés, puis testés :

Dans ce modèle, toutes les activités sont liées. Lorsque les développeurs mettent en oeuvre la fonctionnalité et corrigent les incidents, les ingénieurs d'édition doivent connaître quelle source inclure à la sous-version ou quand la générer (c'est-à-dire, à la fin de tous les travaux). Lorsque des incidents liés à la sous-version se produisent, les ingénieurs d'édition doivent identifier la cause de l'incident, à savoir si l'incident se trouve dans le script de sous-version ou s'il provient d'une erreur générée par l'équipe de développement. En même temps, les testeurs doivent savoir quand une sous-version adéquate sera disponible en vue d'un test, quelles fonctionnalités sont incluses dans la sous-version et quels tests seront effectués. A chaque signalement d'un incident, il est nécessaire de connaître les jeux d'essai qui ont permis de découvrir l'incident, ainsi que les références de l'exigence initiale. Lorsque le développeur corrige l'incident et distribue le code, le cycle recommence.

Dans les projets de développement de logiciels, de nouvelles sous-versions sortent constamment. Les questions courantes que se posent les équipes de développement sont les suivantes : Qu'est-ce qui a été mis en oeuvre dans la sous-version ? Qu'est-ce qui va être testé dans la sous-version ? L'enregistrement Build permet aux équipes de capturer des informations sur chaque sous-version, y compris son statut. L'enregistrement Baseline vous permet de suivre les activités distribuées dans chaque sous-version. Il peut être utilisé pour capturer l'état des activités à un moment donné. L'utilisation des enregistrements Baseline, Build et Activity permet aux testeurs de savoir ce qu'il faut tester et de suivre les tests qui ont été exécutés par rapport à la sous-version

Concepts associés
Présentation
Utilisation des projets
Gestion du travail
Données exemples
Zones obligatoires pour les types d'enregistrement ALM
Tâches associées
Premières étapes pour les administrateurs

Retour d'informations