Les processus de gestion des modifications d’ingénierie

Les processus de gestion des modifications d’ingénierie

Le processus de gestion des modifications diffère d’une entreprise à une autre. Il est souvent le résultat d’expériences accumulées au fil des ans. Chen et al. (2002) ont traité dans leur article le modèle traditionnel de référence de gestion de changement d’ingénierie. Ce modèle représente le déroulement d’un changement d’ingénierie depuis la phase de proposition, passant par l’approbation et la notification. À cette dernière phase, un document résume les différentes parties approuvées  de la proposition de changement, et indique le travail à réaliser ainsi que la date du début de la révision; souvent appelée effectivité et les tâches affectées aux différents intervenants. Il est parfois nécessaire de lancer un nouveau processus de changement d’ingénierie si les processus existants ne sont pas appropriés. Le changement d’ingénierie, en lui même, est un processus hautement itératif dans lequel les changements sont revus et approuvés. À la phase de déploiement, les différents responsables sont informés et les modifications sont envoyées aux applications telles que « Enterprise Ressource Planning ERP ».

La phase finale est l’ archivage, au cours de laquelle les modifications réalisées, les raisons et les justifications, les résultats et les influences sont enregistrés. Des systèmes de gestion des données d’ingénierie et des données techniques dans les processus de production et de développement doivent être capables de définir et d’implémenter un processus de changement, relever et suivre une demande de changement d’ingénierie, circuler les notes de changement d’ingénierie et interfacer le changement à effectuer avec l’application concernée. Il est important de noter qu’un processus de changement d’ingénierie possède les caractéristiques d’un processus d’ingénierie concourante, essentiellement orienté processus, basé sur le projet et centré sur le produit.

D’autre part Maurino (1993) a présenté, dans son chapitre intitulé «la gestion des modifications», l’importance de l’analyse de l’impact d’une modification sur l’ensemble des composants d’un produit. Mais cette analyse dépend beaucoup de la connaissance du produit par les intervenants. La criticité de la modification traduit le degré de l’impact sur les fonctions, compositions ou méthodes de réalisation du produit. On retrouve également les mêmes concepts développés par Jukka et al. (2000) dans leur rapport concernant le processus de gestion de modification.

Les outils de gestion des données techniques (PLM)

Il n’est pas dans notre intention de faire un inventaire de performances, de fonctions et de capabilités des systèmes PLM. Nous ne traiterons que les articles qui touchent de près la problématique du présent projet. Juk:ka et al. (2000) ont tracé l’évolution historique des systèmes PLM. Ils notent la diversité des sigles employés, soient EDM, PIM, TDM, TIM, etc., pour désigner un système de gestion des données. Les principales composantes d’un PLM sont: la voûte,le gestionnaire de flux de travail, le gestionnaire des structures des produits, la classification des documents, le gestionnaire de modification et de notification des changements. St-Martin (2001), présente les outils de PLM disponibles. Il signale que le rôle essentiel d’un PLM est la gestion des modifications.

Pour les utilitaires de gestion des informations de produits, la gestion des modifications est restreinte à la gestion des versions et des configurations pour les assemblages complexes. L’outil PLM permet de signaler l’utilité de vérifier manuellement l’état d’un document altéré par des modifications apportées à des documents avec lesquels il est en relation grâce aux liens déjà établis dans le PLM. Les liens entre ces documents peuvent être établis manuellement ou automatiquement par le PLM lui-même. L’auteur précise que les outils PLM s’arrêtent au stade de signalement des modifications apportées aux divers documents sans pour autant être capable de dire avec précision la nature, l’étendue, les conséquences et la gravité de ces modifications. L’organisme « Object Management Group OMG » a lancé, en 2001, un cahier de charges appelé« PDM Enablers »spécifiant les standards d’un système de gestion des données d’un produit. La modélisation a été réalisée à l’aide des diagrammes UML. Un des modules défini est le « PdmChangeManagement ». Dans les spécifications de ce module on ne trouve pas d’indications sur la granularité des informations à traiter. Notons que Plater et al.(2001) présentent des batteries de tests de conformité des PLM. La granularité des entités manipulées n’est pas considérée parmi ces tests.

La gestion des changements dans un contexte de gestion de la complexité

Jacobs (1998) se propose de résoudre la problématique de la complexité de gestion de conception des produits. Une complexité se manifeste à travers le nombre important de pièces d’un assemblage, la définition géométrique compliquée de chaque pièce et les différentes fonctions de chaque pièce. La majorité des logiciels de CAO offrent des outils pour la modélisation des pièces mais ne peuvent supporter les relations complexes entre les diverses composantes. Ces systèmes isolent complètement les informations de conception d’une pièce. Les modèles pour chaque pièce et les modèles pour différentes disciplines; mécanique, électrique, etc. sont développés et maintenus dans des fichiers et formats séparés. Pour gérer la synergie des relations existant entre les diverses représentations, le concepteur devra traquer lui-même ces relations. Les systèmes de PLM tentent de résoudre ce problème en créant et classifiant les liens entre les diverses représentations, mais ils ne réussissent pas à représenter l’information de synergie qui est nécessaire à ces relations.

L’organisation en fichiers des bases de données des logiciels PLM et la classification manuelle forcent les concepteurs à gérer les diverses représentations à un niveau élevé de granularité. L’auteur propose une structure d’organisation et de gestion des informations de conception afin d’assister le concepteur et d’automatiser la gestion de la complexité. Il propose ainsi une structure permettant d’automatiser les tâches d’organisation et de gestion des modifications des diverses composantes. Il s’inspire des modélisations et des conceptions orientées objets pour présenter des objets d’agrégation, de relations et de version. Ces objets sont munis des méthodes nécessaires pour suivre les modifications. Ce travail reste toujours au sein même d’une seule application de conception et ne peut pas intégrer d’autres applications nécessaires au développement des produits.Le deuxième travail qui s’est intéressé à la gestion de la complexité de la définition des données des produits a été réalisé par Eustache (Eustache 2002).

Il propose un modèle de Graphe Hiérarchique d’Entités et des Contraintes (GHEC) figure 2. Il vise à résoudre le problème de la gestion de la complexité dans un processus de conception de produits mécaniques tout en maintenant la cohérence de la définition du produit. Le GHEC est une composition du produit en entités liées par des contraintes. L’entité est un« objet ou une idée qui existe en soi, en dehors de tout contexte. L’idée correspond à l’état abstrait d’une entité et l’objet à l’état concret». L’entité est un objet au sens de l’Orienté Objet, par conséquent, elle possède des attributs et des méthodes. Parmi les attributs on trouve l’adresse et le type du contenant (type d’application et fichier de stockage). L’objet entité peut être décomposable ou agrégé. Ainsi, on parle des sous entités. Quant aux contraintes, elles sont définies comme étant des « degrés de liberté que l ‘on peut exprimer sous forme de contraintes ».

De la même manière que les entités, les contraintes seront représentées par des objets en association avec les entités. Une contrainte possède des attributs et des méthodes, tel qu’un identifiant unique, un type, une fonction à satisfaire, des droits d’accès, etc. Une contrainte peut être raffinée; décomposée en sous contraintes reliant des sous entités. L’auteur présente une classification des contraintes selon le lien entre les entités. ll distingue 4 types de contrainte. La contrainte de dépendance indique une relation de dépendance générale entre les entités, d’un niveau sémantique faible et dont l’automatisation lors d’une opération d’évaluation est impossible. L’opérateur aura la responsabilité de contrôler ces contraintes. Le deuxième type de contrainte est relationnel, c’est l’ajout des expressions relationnelles de type égalité, infériorité, supériorité, etc. Le troisième type des contraintes représente les contraintes booléennes. Enfin, les contraintes liées aux métiers sont appelées contraintes règles.

En effet, ce graphe représente une hiérarchisation des entités et des contraintes ainsi que différents niveaux d’automatisation de validation de ces contraintes. Suite à une modification ou suppression d’une entité ou d’une contrainte, le GHEC doit être mis à jour. Au cours de cette opération, l’invalidation d’une entité ou d’une contrainte provoque une propagation d’invalidation qui peut invalider tout le GHEC. L’auteur propose alors d’inclure un état intermédiaire où les entités ne sont pas invalides mais en attente d’une vérification. Lorsqu’une entité est modifiée et si les contraintes liées à elle ne sont pas modifiées, alors il est inutile de propager la modification. Concernant le traitement des modifications, l’auteur ne propose dans son travail que le suivi de la validité des entités et des contraintes, donc il ne traite pas la façon de modifier la définition des entités et des contraintes.

Les définitions de l’entité et des liens

Un modèle d’information pour gérer l’ensemble des données d’un projet de génie civil a été développé par Mokhtar et aL (1998). Après une large revue bibliographique, les auteurs concluent que la gestion des changements de conception ne dispose pas d’une solution standard. Le problème consiste à informer les différents intervenants, de toute discipline participante au projet de développement, des modifications faites par d’autres disciplines et affectant directement leurs données. Les auteurs résument les techniques utilisées par les professionnels pour résoudre ce problème : des réunions régulières où les différents intervenants essaient de trouver dans les documents présentés des changements qui touchent à leur travail Le concepteur qui effectue un changement en informe les autres.

Un autre moyen consiste en l’utilisation d’une check-list. Certains utilisent des comparateurs de modèles fournis par certaines compagnies de CAO. Tous ces moyens sont jugés inefficaces, surtout pour un projet de  grande envergure. Les auteurs proposent alors un modèle d’information ayant, entre autres, les caractéristiques suivantes :
a. être capable de gérer les changements de conception en aidant à propager les modifications vers les disciplines affectées uniquement;
b. suivre l ‘historique des changements;
c. donner la possibilité de planifier les futures modifications.

Le modèle présenté est une base de données d’un projet central composé de deux parties. La première est une base de données de toutes les composantes de conception nécessaires à tout le projet. Notons que les composantes de conception «building components » sont les données nécessaires à la description du projet (un édifice en l’occurrence). Ces données sont suffisamment détaillées pour produire les documents d  détail. La deuxième partie est la base de données de gestion. Elle contient l’information nécessaire pour gérer toutes les fonctions du modèle. Le concept est d’assigner la tâche de propagation des modifications aux composantes du projet (building components) elles-mêmes. Chaque composante est responsable de trouver les disciplines affectées par la modification dans l ‘un de ses attributs.

La composante envoie un message aux autres disciplines clarifiant la modification et la manière dont elle affecte chaque discipline. De cette façon, on s’assure d’éliminer la possibilité qu’une personne initie un changement et oublie d’en informer les autres, ou croit qu’elle n’aura pas d’influence sur les autres disciplines ou qu’une autre discipline n’en sera pas affectée. Ces composantes doivent être équipées des « liens de connaissances : linking knowledge » qui permettent d’identifier les disciplines affectées par un changement et la façon dont elles seront affectées. Les modèles utiliseront des règles (relations, contraintes) de deux types pour capturer ces connaissances. Le premier type est le «préétabli» le deuxième type est le «dynamique».

Les règles préétablies sont dictées au moment de la configuration du modèle au début du projet. Les règles dynamiques sont créées à la volée « on the fly » au cours de la préparation des dessins de détail et lors de l’utilisation du modèle. Ces dernières sont capturées par le module de captation des règles. Ce module fait partie de la manipulation des données et est interfacé avec les concepteurs. Lorsqu’un changement survient, la composante vérifie les règles préétablies et dynamiques stockées. Les  messages sont automatiquement envoyés aux autres composantes affectées. Ces messages sont sans ambiguïté et définissent clairement les attributs à modifier. Un suivi d’historique des changements est également possible. Les auteurs se sont intéressés aussi à la planification des changements et ont remarqué qu’un changement peut donner lieu à plusieurs scénarios. Ils ont présenté un modèle dont l’idée est de bâtir un dépôt unique de toutes les composantes qui provoquent des changements de conception. Ils utilisent des données textuelles, plutôt que des dessins, comme principal moyen pour sauver et communiquer les informations de conception. Mais ce concept ne s’adapte pas aux documents méthodes dans un projet de conception mécanique. Giguère et al. (2002) ont proposé un modèle qui vise à automatiser des tâches de modélisation répétitives.

Les auteurs proposent l’utilisation d’une «caractéristique contextuelle ». Ils définissent alors un lien technologique par une relation de dépendance entre deux éléments d’information. Le lien de dérivation quant à lui est une relation unidirectionnelle entre une caractéristique cible et une caractéristique source. Le lien est utilisé pour dériver une caractéristique cible à partir d’une caractéristique source. Ce même lien jouera un rôle important pour la propagation des modifications.

Table des matières

ABSTRACT
REMERCIEMENTS
LISTE DES FIGURES
INTRODUCTION
CHAPITRE 1 PROBLÉMATIQUE
1.1 Introduction
1.2 Contexte d’étude
1.3 Scénario de propagation des changements
CHAPITRE 2 REVUE DE LITTÉRATURE
2.1 Introduction
2.2 Les processus de gestion des modifications d’ingénierie
2.3 Les outils de gestion des données techniques (PLM)
2.4 La gestion des versions
2.5 La gestion des changements dans un contexte de gestion de la  complexité
2.6 Les définitions de l’entité et des liens
2. 7 Conclusion
CHAPITRE 3 MODÈLE DE GESTION DE LA PROPAGATION DES MODIFICATIONS
3.1 Introduction
3.2 Définitions
3.2.1 Entité et granularité des données
3.2.2 État d’un document vs version
3.2.3 Liens et associations
3.2.4 Modification
3.2.5 Notification et propagation des modifications
3.3 Choix des entités à manipuler
3.4 Modèle proposé
3 .4.1 Description de l’architecture générale
3 .4.2 Description des modules
3.5 Mécanisme de gestion des liens
3.6 Propagation des modifications
3.7 Conclusion
CHAPITRE 4 LE PROTOTYPE DE VALIDATION
4.1 Introduction
4.2 Traduction de l’architecture générale du modèle en diagramme UML
4.2.1 Module central
4.2.2 Module document
4.3 Choix des systèmes et des documents
4.4 Développements réalisés
4.4.1 Développement du module central
4.4.2 Surcharge des entités dans CATIA
4.4.3 Module document (autre que CATIA VS)
4.5 Exemple d’application
4.5.1 Scénario
4.5.2 Étude de l’impact de la modification
4.6 Conclusion
CHAPITRE 5 DISCUSSION
5.1 Limitations du modèle
5.2 Efficacité du modèle vis-à-vis de la propagation des modifications
5.3 Création des liens
5.4 Traitement d’un nombre élevé de liens
CONCLUSION
ANNEXE 1 Surcharge des caractéristiques dans CATIA
BIBLIOGRAPHIE

Télécharger le rapport complet