SOLIDWORKS PDM : gestion des modifications de conception rejetées

Un flux de travail PDM typique pour les documents contrôlés par révision comprend un «En attente d'approbationétat pour les fichiers en cours d'examen pour approbation. Cet état permet normalement au réviseur soit d'approuver la modification proposée et de publier la nouvelle révision, soit de renvoyer le document pour un travail plus approfondi – l'hypothèse ici est que la modification serait être acceptée ultérieurement si les modifications supplémentaires requises sont apportées au document.

Flux de travail typique avec transitions pour l'approbation et le renvoi

Mais il y a un hic…

Que se passe-t-il si la modification proposée est simplement rejetée ? Que faites-vous des nouvelles versions qui ont été créées dans l'historique de votre modèle une fois que vous avez abandonné la modification proposée ? Dans l'exemple suivant, SW-201754 a été modifié en ajoutant des congés. Comme le montre l'historique des versions, la version 2 a été publiée en tant que révision A, mais maintenant, en raison des congés ajoutés, il existe une nouvelle version (3) qui contient la modification envisagée pour révision. Si cette modification est rejetée, la dernière version ne reflète plus la dernière révision publiée. Cela peut dérouter certains utilisateurs, surtout si la modification de la version 3 ne sera jamais publiée.

De nombreuses entreprises utiliseront simplement le retour en arrière fonctionnalité de SOLIDWORKS PDM deux remettent leurs fichiers de conception dans le Libéré état et de supprimer les versions qui ne sont plus nécessaires. Cependant, la restauration peut être délicate et problématique ; gérer correctement le contrôle de version des fichiers référencés et savoir quoi faire des références parentales peut entraîner de la confusion et mener à des erreurs dommageables qui ne peuvent pas être corrigées facilement. De plus, certaines entreprises préfèrent conserver leur historique de conception intact, afin qu'il reflète avec précision toutes les modifications qui ont été apportées aux fichiers de conception, même si ces modifications ont finalement été rejetées.

Mais il existe une alternative à l’utilisation du rollback : une petite technique que j’appelle

la manœuvre du saute-mouton

La manœuvre Leapfrog vous permet de maintenir les meilleures pratiques de gestion de fichiers qui stipulent que la dernière version doit également être la dernière révision publiée pour tout fichier qui se trouve dans un Libéré état. Pour restaurer cet état maintenant que des versions supplémentaires inédites ont été ajoutées à la fin de votre historique de fichiers, vous devez créer une autre version de la conception (version 4, dans cet exemple) qui a un contenu identique à la dernière révision publiée, et tamponner le fichier avec la révision actuelle (et non la révision suivante). Voici à quoi cela ressemblerait dans l'historique des versions :

Comme vous pouvez le constater, la version 2 a fait un bond en avant sur la version 3 et est maintenant dupliquée en tant que version 4, et estampillée à nouveau avec la révision A, créant la version 5.

Les étapes de la manœuvre de saut de grenouille sont les suivantes :

1. Consultez le fichier, qui obtiendra la dernière version dans votre vue locale.
2. Maintenant, récupérez la dernière version estampillée de révision (version 2 dans l'exemple), afin que votre vue locale reflète la révision réellement publiée.
3. Ensuite, réenregistrez le fichier, en créant une nouvelle version (version 4) dont le contenu de conception est identique à la dernière révision publiée.
4. Finalement, ré-estampillez les fichiers avec la révision existante.

Les trois premières étapes sont faciles, mais la dernière étape nécessite quelques modifications au déroulement du travail. Voici un exemple de flux de travail avec la modification permettant de contourner une idée de conception rejetée à l'aide de la manœuvre Leapfrog :

Comme vous pouvez le voir sur l'image, en plus de retourner le fichier pour des modifications, il existe maintenant une transition depuis l'état de révision qui peut être utilisée lorsque la modification proposée doit être abandonnée. Cette transition place les fichiers de conception dans un état d'attente temporaire, dans lequel les trois premières étapes de la manœuvre Leapfrog sont exécutées. La transition depuis l'état Dépasser l'état de retour à la Libéré L'état est l'endroit où la magie se produit. Dans cette transition, la variable de révision est réinitialisée à la valeur du compteur de révision actuel (%revision%) et le compteur de révision est incrémenté d'une valeur de zéro, ce qui fait que les fichiers sont réestampillés avec la même révision qu'ils avaient auparavant.

Un des effets secondaires de la manœuvre de saute-mouton est que l'historique des fichiers affiche deux versions différentes avec la même révision. Cela peut paraître étrange au premier abord, mais un peu de logique et une formation appropriée permettent aux utilisateurs de comprendre que dans cette situation, la révision A réelle est celle avec le numéro de version le plus élevé ; celle qui se produit plus tard dans l'historique des fichiers.

La version 5 remplace la version 2 en tant que Rev A officielle

Chaque entreprise doit décider de la meilleure façon de gérer les modifications de conception avortées. La manœuvre Leapfrog offre une alternative à la restauration simple, mais parfois problématique. Leapfrog permet à l'historique de conception de rester intact avec les modifications de conception proposées mais rejetées toujours disponibles dans les versions antérieures, tout en maintenant une gestion appropriée des fichiers en garantissant que la dernière version est toujours la dernière révision publiée.