Le cycle de développement comprend des phases et des itérations. Dans les phases et itérations, vous pouvez créer et réutiliser des artefacts de développement. Des relations peuvent exister entre les artefacts de développement. Vous pouvez également référencer et utiliser des artefacts de développement créés dans d'autres cycles de développement. Ces artefacts de développement peuvent se trouver sur des sites Web ou dans des référentiels personnalisés.
Les actifs peuvent contenir des fichiers d'artefacts de développement ou des références à ceux-ci. Par exemple, un artefact distant peut être téléchargé dans le référentiel d'actifs en tant qu'artefact d'actif. L'artefact d'actif peut également être une référence à l'artefact distant dans le référentiel dans lequel il est stocké. L'ensemble approprié d'artefacts et de relations s'affiche dans le référentiel d'actifs. Les équipes peuvent accéder au référentiel pour administrer, rechercher et consulter les scénarios d'utilisation relatifs aux actifs.
Vous pouvez utiliser les flux de travaux inclus avec le produit ou créer des flux de travaux supplémentaires pour le référentiel.
Au niveau de l'actif, les conditions requises pour les cycles de vie maître et de communauté sont héritées par le cycle de vie de l'actif. Les gestionnaires de cycle de vie peuvent ajouter des exigences pour l'actif pour compléter les exigences spécifiées par les administrateurs de référentiels et de communautés.

Par exemple, un gestionnaire de cycle de vie peut décider d'inviter des réviseurs supplémentaires pour un actif spécifique. Ils peuvent également modifier la configuration d'une stratégie, pour mieux répondre aux besoins d'un actif spécifique.
Toute modification que vous apportez à la configuration du cycle de vie d'un actif s'applique uniquement à cet actif. Vos modifications ne s'appliquent pas aux autres actifs de la communauté qui utilisent le même cycle de vie maître ou de communauté. Si vous apportez souvent les mêmes modifications aux actifs, vous pouvez demander à un administrateur de communauté de modifier le cycle de vie au niveau de la communauté.
Si un actif soumis à une communauté ne répond pas aux exigences d'un cycle de vie ou autre processus de révision personnalisé, il intègre un cycle de vie simple comprenant deux états : Soumis et Approuvé. Le propriétaire de l'actif et les administrateurs sont les gestionnaires de cycle de vie de l'actif.
Vous pouvez modifier le cycle de vie d'un actif qui intègre le cycle de vie implicite, mais vous ne pouvez pas modifier ce cycle de vie pour tous les actifs d'une communauté.
Quel que soit son état de cycle de vie, vous pouvez envoyer un actif vers le cycle de vie de mise hors service. Lorsqu'un actif a intégré le cycle de vie de mise hors service, ses gestionnaires de cycle de vie peuvent modifier le cycle de vie de mise hors service pour cet actif. Dans chaque état de ce cycle de vie, vous pouvez restaurer l'actif. Lorsque vous restaurez l'actif, il est à nouveau soumis à la communauté. Il prend le premier état du cycle de vie approprié en fonction du type d'actif ou des catégories de l'actif.
Dans les versions du produit antérieures à la version 7.2, vous pouvez gérer le développement des actifs à l'aide des processus de révision. Dans la version 7.2 ou suivante, vous pouvez utiliser les cycles de vie pour développer les actifs.
| Processus de révision (version 7.1.1.1 ou antérieure) | Cycles de vie (version 7.2 ou ultérieure) | |
|---|---|---|
| Nombre d'états et de transitions | Un flux de travaux est inclus. Vous pouvez également utiliser IBM Rational ClearQuest pour employer un flux de travaux différent. | Vous avez le choix entre plusieurs flux de travaux intégrés qui possèdent chacun différents nombres d'états et de transitions. Vous pouvez également utiliser IBM Rational Team Concert pour augmenter le nombre d'états et de transitions. |
| Flexibilité des états | A chaque état est associée une limitation au niveau des droits, que vous ne pouvez pas modifier. Par exemple, un actif ayant l'état Brouillon ne peut être vu que par son propriétaire et les administrateurs. | Pour chaque état, vous pouvez personnaliser les autorisations, les réviseurs et les stratégies. |
| Transitions | Les utilisateurs doivent demander manuellement les changements d'état d'un actif. | Vous pouvez créer des conditions complexes qui contrôlent le moment où un actif peut passer d'un état à un autre. Les transitions peuvent également se produire automatiquement si l'actif respecte les conditions que vous avez indiquées. |
| Personne guidant les actifs tout au long du cycle de vie | Lorsque vous créez un processus de révision, vous créez un comité de révision ou la liste des utilisateurs qui donnent leur accord final pour la révision de l'actif. Vous pouvez modifier les droits du comité de révision en changeant le rôle intégré Comité de révision pour votre communauté. | Lorsque vous créez un cycle de vie, vous affectez des gestionnaires de cycle de vie qui peuvent ajuster le cycle de vie des actifs et inviter des réviseurs supplémentaires. Les gestionnaires de cycle de vie ont un ensemble prédéfini de droits que vous ne pouvez pas modifier. |
| Personne révisant les actifs | Dans l'état Révision, les réviseurs peuvent visualiser des actifs et voter pour des actifs, et accéder aux forums d'un actif. Vous pouvez sélectionner les réviseurs lors de la configuration du processus de révision. Le comité de révision d'un actif peut sélectionner des réviseurs alors que l'actif a l'état Planification de révision. | Pour tous les états d'un cycle de vie, vous pouvez ajouter des réviseurs qui peuvent visualiser et commenter les actifs, et éventuellement modifier et voter pour des actifs. |
| Fonctionnement des stratégies | Les processus de stratégie doivent être configurés séparément des processus de révision. En général, vous configurez une stratégie de sorte qu'elle s'exécute juste avant une tentative d'action sur l'actif. Lorsqu'une stratégie échoue, vous ne pouvez pas exécuter cette action. Par exemple, une stratégie peut s'exécuter avant qu'un actif soit approuvé, soumis pour révision, supprimé, retiré ou archivé. | Les stratégies sont une composante majeure des cycles de vie. Vous pouvez configurer des stratégies de sorte qu'elles s'exécutent à différents moments, quel que soit l'état de l'actif. Par exemple, une stratégie peut s'exécuter chaque fois qu'un actif est modifié alors qu'il a un état spécifique. Ou bien, une stratégie peut s'exécuter à un moment spécifique après que l'actif est passé à un état donné. Vous pouvez utiliser les résultats des stratégies pour contrôler le moment où les actifs peuvent passer d'un état à un autre. |
| Limitation de l'accès aux actifs périmés ou hors d'usage | Seuls les actifs ayant les états Approuvé et En l'état peuvent accéder aux états Mis hors service et Archivé. | A tout moment, un actif peut, quel que soit son état ou le cycle de vie dans lequel il se trouve, intégrer un cycle de vie de mise hors service. |
La figure ci-dessous illustre un exemple de flux de travaux pour un cycle de vie d'actif. Un flux de travaux contient les états et les actions d'un type d'actif et peut être configuré en tant que composant d'un cycle de vie d'actif pour gouvernance. Vous pouvez appliquer des stratégies à des actions spécifiques du flux de travaux et préciser les utilisateurs autorisés à exécuter chaque action ou à prendre part à un processus de révision.

Le développement d'un actif est cyclique. Dans le cadre d'un flux de travaux, un actif peut passer par différents états au cours de son cycle de vie. Pour un type d'actif donné, vous pouvez définir un modèle de gouvernance afin de contrôler les utilisateurs et les groupes qui peuvent soumettre, réviser, approuver ou rejeter et publier des actifs. Lorsque les utilisateurs modifient un actif et créent des itérations, le cycle de développement passe par les phases suivantes :