Gérer les changements de version produit

Réponse courte

À chaque version, comparez le périmètre livré aux hypothèses, composants et preuves du produit.

Disponibilité produit : À confirmer pour le rejeu d’interface ; méthode utilisable sur les données accessibles. Les modules et commandes dépendent de l’édition et des permissions ; libellés à confirmer lorsque la recette n’est pas réalisée.

Préparer la démarche

Travaillez sur un produit et une version identifiés, avec les personnes habilitées et des sources partageables. Les étapes ci-dessous organisent le travail humain ; elles ne promettent pas un workflow automatique supplémentaire.

Étapes et décisions

1. Identifiez précisément la nouvelle version et sa date de diffusion, sans remplacer la description de l’ancienne version dans les pièces historiques.
2. Comparez composants, configuration, exposition et fonctionnalités. Un changement de dépendance peut modifier les versions affectées.
3. Reprenez les points de sécurité, vulnérabilités et risques dont les hypothèses ont changé.
4. Actualisez les actions et preuves pertinentes, puis les sections de documentation technique et la période de support si la décision évolue.
5. Préparez un export relu pour cette version et conservez la provenance des pièces utilisées.

Résultat attendu

La documentation permet de distinguer les états avant et après livraison.

Limites et récupération

Un scan de la branche de développement ne démontre pas l’état des versions déjà distribuées. Si une information manque, attribuez sa vérification et conservez l’incertitude plutôt que de la remplacer par une hypothèse non signalée.

Articles liés

• mettre a jour la documentation technique dans le temps
• integrer cra manager dans un cycle release

Article issu de la base de connaissance CRA Manager.