GESTION DE CONFIGURATION AU SENS SGDT

Les outils de gestion de configuration ont été principalement mis en œuvre dans le secteur du développement logiciel, les outils de GC sont couramment utilisés mais servent surtout à accompagner les procédures de développement et ne font pas que de la gestion de configuration pure. Ils sont notamment liés à la gestion des demandes de changements, aux éditeurs (de code), à la ‘construction’ des exécutables. Une piste que nous proposons d’explorer ici est de voir si d’autres progiciels proches de la GC et utilisés dans le secteur de l’industrie, les Systèmes de Gestion des Données Techniques (SGDT), ne pourraient pas servir de base à un outil de GC dédié SAGT. D’autres pistes sont sans doute à explorer, comme les outils de gestion de patrimoine, mais ce sera l’objet d’une autre étude… 4.1 Introduction aux SGDT Depuis une dizaine d’années, de grands groupes industriels ont cherché à mettre en place des Systèmes de Gestion des Données Techniques, relatives à des produits et leurs processus de fabrication sur tout son cycle de vie. La mise en place d’un outil de gestion de données techniques (SGDT) dans une entreprise répond à des objectifs de sécurité des données, de traçabilité, de non redondance et de cohérence des informations qui définissent « l’offre produit » de l’entreprise. Les informations correspondantes sont souvent de formats et de localisations très divers. Le principe de base de la GDT consiste à organiser la structure d’information autour des nomenclatures de produits. Les projets de SGDT s’inscrivent souvent dans un contexte de raccourcissement des cycles de développement des produits, de maîtrise de la complexité des configurations, de distribution géographique des activités d’ingénierie, voire d’ingénierie concourante. Un SGDT peut en effet assurer des garanties de sécurité des données, aussi bien vis à vis des accès indésirables que des impossibilités de retrouver la bonne information (format illisible, mauvaise version, disque inaccessible..), éviter des ressaisies source d’erreurs, garantir la maîtrise du flux d’informations pour les acteurs concernés. Une gestion de données techniques ne vise pas à se substituer aux outils habituels des acteurs de l’ingénierie (CAO, bureautique, messagerie, …) ou de la production (GPAO, …), mais à s’intégrer dans l’environnement existant tout en le sécurisant. (extrait adapté de http://gilco.inpg.fr/tollenae/sgdt/agile.html). Ce chapitre traite présente la manière dont la gestion de configuration est abordée dans les SGDT, et envisage son applicabilité aux SAGT. En effet, les SGDT ont évolué depuis quelques années. Initialement, leur vocation était de définir et gérer un référentiel comme un coffre de données, en mettant en place des méthodes de définition des données et des modes d’accès normalisés. Dans un second temps, les SGDT ont implémenté la notion de dynamisme, en formalisant le mécanisme de modification et d’échange de données. Le schéma page en suivante illustre les spécificités de la démarche des SGDT.  Mai 2000 Gestion de la configuration Configurateur ? Industry best pratices Gestion d’un coeur de gamme Gestion de Configuration dans les SGDT Savoir ce qui a été fait A une date donnée Dans une configuration nommée Dans le détail: Objets Documentation associée Relations entre tous ces objets Savoir ce que l’on fait (analyse d’impact) Objets reliés entre eux Analyse d’impact de l’évolution d’un de ces objets Objets de modifications Proposition de modification Ordre de modification Instructions Typage des évolutions Workflow pour valider ces évolutions Limites Trop de gestion de configuration = lourdeur trop de complexité évolutions impossibles ! Trop peu de gestion = erreurs pas assez d’information erreurs de conception, de fabrication, d’installation… pas d’analyse d’impac problèmes de compat il faut trouver le bon niveau, dépendant des ses moyens des ses besoins selon technologie selon organisation un bon système d’information permet de répondre à des exigences impossibles à satisfaire auparavant Pas dans le périmètre actuel Evolution avec propagation d’indice Pour pouvoir tracer finement l’évolution d’un objet, je demande de faire évoluer artificiellement des objets reliés (cas le plus fréquent: les nomenclatures qui le contiennent). Cela veut dire que ces objets vont être marqués comme modifiés, uniquement pour distinguer avant la modification et après. Evolution avec scission ou fusion Scission lorsque je veux faire évoluer un objet, je me rends compte que cette évolution n’est pas valable pour tous ses cas d’emploi. Je décide donc de créer un nouvel objet, en conservant un lien « Issu de » avec l’objet original Fusion j’ai identifié deux objets différents mais très semblable. Je décide qu’en en faisant évoluer un des deux, celui-ci peut remplacer les deux. Je modélise donc que cette nouvelle version remplace les deux objets, et ce dans tous les cas d’emploi. Typage des nomenclatures Afin de pouvoir comparer, il est intéressant de définir une « nomenclature type » Les n premiers niveaux de cette nomenclature sont partagés par tous les projets n = 2 Les niveaux inférieurs sont spécifiques Dans l’objectif de rationaliser / standardiser, Qu’est ce que c’est je définis des éléments communs à plusieurs projets. Avantages/inconvénients L’intérêt de rationaliser est évident au niveau macro Centraliser les fournisseurs Centraliser les compétences Rationaliser intéresse aussi les projets Ils bénéficient « gratuitement » des évolutions initiées par les autres Ils peuvent « pousser » leurs particularités pour qu’elles deviennent des standards L’inconvénient est une certaine lourdeur pour les projets Les éléments du coeur de gamme sont plus difficiles à faire évoluer car ils impliquent beaucoup plus d’acteurs Il faut décider, pour chaque nouveauté proposée par un projet, Rationaliser a un coût de l’inclure ou non dans le coeur Peut-être faire financer par le coeur de gamme Il faut motiver les « projets » existants ce qui vient des projets Rationaliser est extrêmement intéressant pour les projets qui démarrent Ils peuvent peut-être financer partiellement ce coeur de gamme.

Gestion de la configuration et SGDT

Comme son nom l’indique, la SGDT gère les données techniques relatives à des produits dans une entreprise industrielle. Les dépendances entre les données dans la chaîne de conception/fabrication d’un produit se traduisent par des impacts sur le produit lorsque les paramètres entrant dans sa définition sont modifiés. Le SGDT permet justement d’identifier et d’anticiper ces impacts. La gestion de configuration dans les SGDT s’articule autour de deux objectifs : ! savoir ce qui a été fait, ! savoir ce que l’on fait.

La connaissance des actions passées

La gestion de référentiel doit permettre de connaître l’état des données gérées en configuration à un instant donné, dans une configuration nommée. Il s’agit là d’une première étape, qui consiste à établir un “ dictionnaire ” des données gérées, avec leur état à un instant donné. Il est également intéressant de pouvoir connaître dans le détail la liste des objets gérés avec leur différentes caractéristiques, la documentation associée à ces objets, et les relations entre tous ces objets.

L’analyse d’impact

Cette connaissance des actions passées est une condition nécessaire mais non suffisante pour obtenir une gestion de configuration parfaitement efficace dans les SGDT. Il est en effet très important de maîtriser ce que l’on fait lorsqu’on modifie l’état d’un référentiel. Ces modifications doivent donc passer par une phase d’analyse d’impact. Cette analyse d’impact est rendue possible par la première étape citée précédemment, qui a permis d’établir une “ photo ” des données gérées en configuration. L’analyse d’impact doit être faite lorsqu’il s’agit d’apporter une modification sur un des objets du référentiel, que cette modification soit mineure ou majeure. Deux cas peuvent se présenter : ! l’objet n’a pas de relation avec d’autres objets, ! un ou plusieurs objets sont reliés à l’objet qui doit être modifié. Dans le premier cas, l’analyse d’impact se réduit à sa plus simple expression : il s’agit simplement d’établir clairement la proposition des modifications à effectuer. Il est évident qu’en pratique, si l’objet n’a pas de relation, les modifications seront effectuées directement sans passer par l’établissement de la proposition de modification. La proposition de modification est en effet utile dans le cadre d’un référentiel partagé entre plusieurs entités, qui doivent toutes valider la proposition de modification avant qu’elle ne puisse être effectuée. Ce principe sera détaillé dans le chapitre sur la gestion du cœur de gamme