Upload
hoangliem
View
212
Download
0
Embed Size (px)
Citation preview
Gestion de données & documents techniques
Cahier des charges
SOMMAIRE
AVANT PROPOS.....................................................................................................................2FONCTION DU CAHIER DES CHARGES.....................................................................................................2STRUCTURE DU CAHIER DES CHARGES..................................................................................................2CAHIER DES CHARGES....................................................................................................3I. ETAT DES LIEUX........................................................................................................4I.1. LE CONTEXTE.........................................................................................................................4I.2. LA PROBLÉMATIQUE................................................................................................................4I.3. LA SOLUTION PROVISOIRE.......................................................................................................4I.3.1. UN AXE TECHNIQUE …...................................................................................................................... 4I.3.2. UN AXE ORGANISATIONNEL …............................................................................................................4
II. TYPE DE SOLUTION SOUHAITÉE..................................................................................5II.1. PRINCIPE...............................................................................................................................5II.2. OBJECTIFS.............................................................................................................................5III. FONCTIONNALITÉS DU SYSTÈME INFORMATIQUE..........................................................6III.1. FONCTIONNALITÉS GÉNÉRALES...............................................................................................6III.2. FONCTIONNALITÉS DES MODULES DE GESTION DE DONNÉES TECHNIQUES.................................6III.2.1. MODULE DE GESTION DES NOMENCLATURES DE PRODUITS................................................................6III.2.2. MODULE DE GESTION DE LA BIBLIOTHÈQUE DE COMPOSANTS............................................................7III.2.3. MODULE DE GESTION DES PROTOTYPES DE PRODUITS......................................................................8III.2.4. MODULE DE GESTION DE LA LIBRAIRIE DE COMPOSANTS....................................................................8III.3. FONCTIONNALITÉS DU MODULE DE GESTION DE DOCUMENTS TECHNIQUES................................9III.4. FONCTIONNALITÉS LIÉES À L’ERGONOMIE DE L’INTERFACE HOMME / MACHINE........................10IV. DIMENSIONNEMENT DE L’APPLICATION......................................................................11IV.1. NOMBRE D’UTILISATEURS......................................................................................................11IV.2. NOMBRE D’OBJETS À DÉCRIRE..............................................................................................11V. CONTRAINTES TECHNIQUES......................................................................................12V.1. CONTRAINTES MATÉRIELLES.................................................................................................12V.2. CONTRAINTES LOGICIELLES...................................................................................................12ANNEXES..........................................................................................................................13
A - Détails de l’état des lieux...................................................................................................................................14
B – Présentation du type de solution souhaitée......................................................................................................20
C – Mode de représentation des nomenclatures de produits..................................................................................23
D – Spécification formelle du modèle de données..................................................................................................34
E – Spécification technique de la solution logicielle................................................................................................35
F – Jeux d’essais..................................................................................................................................................... 36
GLOSSAIRE......................................................................................................................39
MISE A JOUR EXAMEN APPROBATION APPROBATIONIndice : 2.0
Date : 17/02/2000
Responsable Gestion Qualité AAD
Date : Visa :
Responsable R&D
Date : Visa :
Fournisseur :
Date : Visa :
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 1 / 44
Gestion de données & documents techniques
Cahier des charges
Avant Propos
Fonction du cahier des chargesCe cahier des charges regroupe les éléments constitutifs de la spécification fonctionnelle d’un système
informatique de gestion de données et de documents techniques.Les données techniques sont celles liées aux processus de conception de produits nouveaux et de
modification de produits existants. Les documents techniques sont ceux qui incorporent les données précédentes pour des besoins en documentation externe et/ou interne.
La fonction essentielle de ce cahier des charges est de permettre à nos partenaires potentiels de s’imprégner de notre problématique et de comprendre notre approche des processus de conception et de modification de produits.
Il contient donc (ou contiendra à terme) l’ensemble des informations nécessaires et suffisantes pour permettre à nos partenaires définitifs :
D’établir une spécification formelle du modèle de données sous-jacent à notre problématique De définir la nature de la solution informatique capable d’implémenter ce modèle de données De réaliser une maquette de cette solution informatique capable de répondre à nos besoins
Structure du cahier des chargesCe cahier des charges est structuré de la manière suivante :Chapitre I
Il dresse un état des lieux de la situation, depuis le contexte dans lequel nous évoluons et la problématique à laquelle nous sommes confrontés jusqu’au type de solution provisoire que nous avons mis en place pour y répondre.
Chapitre IIIl présente le type de solution vers lequel nous souhaitons tendre.
Chapitre IIIIl définit les fonctionnalités que nous attendons d’un tel système dans ses différents aspects.
Chapitre IV Il tente d’évaluer le dimensionnement du système à mettre en place.
Chapitre VIl liste les contraintes techniques matérielles et logicielles auxquelles nous sommes confrontés.
Annexes : L’annexe A reprend certains aspects de l’état des lieux dans le détail.L’annexe B présente le type de solution que nous souhaitons mettre en place.L’annexe C introduit le mode de représentation des nomenclatures que nous souhaitons utiliser.L’annexe D contiendra la spécification formelle du modèle de données retenue.L’annexe E contiendra la spécification technique de la solution logicielle retenue.L’annexe F fournira les données nécessaires à l’élaboration d’une maquette.
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 2 / 44
Gestion de données & documents techniques
Cahier des charges
CAHIER DES CHARGES
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 3 / 44
Gestion de données & documents techniques
Cahier des charges
I. Etat des lieux
I.1. Le contexteLa demande en documents techniques, que ce soit pour des besoins externes ou internes, a récemment
évolué de manière significative, tant d’un point de vue quantitatif que qualitatif. La production de documents techniques est devenue une activité à part entière de notre entreprise.
Une description plus détaillée du contexte est présentée en Annexe A1.
I.2. La problématiqueAu cœur de notre problématique (Cf Annexe A2), se situe le besoin de concilier :
la perpétuelle évolution de notre catalogue de produits (nouveaux produits, modifications de produits existants, évolution de la législation, modifications techniques, …)
avec la nécessité de produire dans les meilleurs délais suivant la validation d’un produit (nouveau ou modifié) la documentation technique qui lui est associé. C’est à dire, selon les cas :
l’aspect technique d’une offre commerciale dans un but de proposition, et/ou le cahier des charges pour le client du produit dans un but de contractualisation, et/ou les documents du SDAQ pour l’entreprise dans un but de formalisation.
Par ailleurs, et d’une manière plus générale, nous avons le besoin de décrire notre catalogue de produits sous forme de nomenclatures intégrant l’ensemble des objets techniques associés aux processus de conception de produits nouveaux et de modification de produits existants (Voir plus loin).
I.3. La solution provisoireLa solution provisoire que nous avons mise en place comporte :
I.3.1. Un axe technique …… qui s’appuie sur une solution informatique « tout bureautique » (Cf Annexe A3), utilisant :
le traitement de texte Microsoft Word comme « logiciel de mise en page et de publication », le tableur Microsoft Excel comme « base de données techniques »
Cette solution ne nous convient pas, et nous souhaitons évoluer vers une solution moins « artisanale », capable de nous apporter à la fois plus de rigueur, plus de souplesse, plus de rapidité, plus de sécurité, et offrant de meilleures possibilités de réutilisation de nos informations techniques.
I.3.2. Un axe organisationnel …… qui s’articule sur la solution technique précédemment décrite, mais qui présente des caractéristiques
suffisamment génériques pour que nous souhaitions en conserver le principe (Cf Annexe A4).Il s’agit d’une procédure qui nous permet d’analyser les demandes (provenant essentiellement de nos
clients et prospects) en documents techniques (ou plus fréquemment en familles de documents) afin de les décomposer en demandes élémentaires auprès des services les plus aptes pour y répondre.
Ainsi, après analyse des besoins en informations pour produire une famille de documents : le Service Commercial établit la trame informatique (fichier Word) des documents, le Service Gestion Qualité définit la structure d’une base de données (fichier Excel) dédiée, puis
incorpore les champs de « fusion » au sein de la trame informatique précédemment définie, les services techniques (R&D, Production, Achats, Gestion Qualité) mettent à jour si nécessaire
leurs propres bases de données (fichiers Excel) et/ou documents (fichiers Word) en y ajoutant les informations manquantes (sous réserve des aspects confidentiels),
le Service Commercial renseigne la base de données dédiée à partir des bases de données des services techniques, puis édite l’ensemble des documents par « publipostage ».
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 4 / 44
Gestion de données & documents techniques
Cahier des charges
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 5 / 44
Gestion de données & documents techniques
Cahier des charges
II. Type de solution souhaitée
II.1. PrincipeLe principe de la solution souhaitée (Cf schéma en Annexe B1) consiste à mettre en place un système
informatique constitué : D’une unique base de données techniques destinée à stocker les informations « issues de » et/ou
« utilisées par » les processus de : Conception de produits nouveaux Modification de produits existants Production de document techniques
De modules applicatifs destinés aux activités de gestion : des nomenclatures de produits de la bibliothèque de composants des prototypes de produits de la librairie de composants des modèles de documents et des documents (Cf tableau en Annexe B2)
II.2. ObjectifsCe système informatique doit nous permettre de garantir la cohérence de l’information technique des
catalogues de produits et de composants de l’entreprise dans le respect des règlements, normes et bonnes pratiques en vigueur.
Cette cohérence doit être assurée depuis la définition des produits jusqu’à leur commercialisation, puis après chaque modification qu’ils subissent durant leur présence en linéaire. Les objectifs principaux étant :
Récupérer la gestion des données et documents techniques des produits existants, Assurer la gestion des cycles de conception (modification) de produits nouveaux (existants) Permettre l’intégration de ces données techniques au sein de documents techniques :
à partir de cette base de données techniques, selon des modèles prédéfinis pour chaque famille de documents.
L’objectif opérationnel de ce système informatique est de nous permettre de : produire dans les meilleurs délais n’importe quel type de document technique relatif à un (ou plusieurs) produit(s) dès lors qu’il(s) est(sont) validé(s).
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 6 / 44
Gestion de données & documents techniques
Cahier des charges
III. Fonctionnalités du système informatique
III.1. Fonctionnalités généralesLe système informatique doit être conçu de manière à :
Garantir une maîtrise des flux d’informations Chaque information doit être saisie qu’une fois et une seule Une information ne peut être saisie que par une personne habilitée Chaque information doit pouvoir être utilisée plusieurs fois Une information ne peut être utilisée que par une personne habilitée
Garantir une maîtrise de la dynamique de l’information : Faire coexister plusieurs états d’un même objet simultanément Maîtriser les évènements conditionnels de ces changements d’état Restituer l’état du système d’information à une date passée Anticiper l’état du système d’information à une date future
Intégrer les fonctionnalités suivantes : Gestion des mêmes informations en plusieurs langues (au moins 2 : Français & Anglais) Gestion de différentes unités et format pour l’expression d’une même grandeur Gestion de la notion d’information confidentielle (interne et externe)
Par ailleurs, le système informatique doit nous permettre de gérer (et surtout de visualiser) les nomenclatures de produits selon le mode de représentation décrit en Annexe C.
III.2. Fonctionnalités des modules de gestion de données techniques
III.2.1. Module de gestion des nomenclatures de produitsCe module a pour fonction de définir les entités que nous gérons « en tant que produits ».Cette fonction est essentielle à la formalisation :
de la composition de nos produits, des relations entre :
les demandes fonctionnelles de nos clients et nos réponses techniques nos demandes fonctionnelles et les réponses techniques de nos fournisseurs
Ce module doit nous permettre de définir des nomenclatures hiérarchiques avec un nombre de niveau illimité et un nombre d’entités par niveau illimité. Il doit donc permettre :
de gérer les entités composant les nomenclatures : création, modification et suppression d’entités création, modification et suppression de groupes d’entités définition d’un typage fonctionnel des entités : « spécifiés » ou « référencés »
de gérer les relations entre les entités des nomenclatures : création, modification et suppression de relations entre les entités définition d’un typage des relations entre les entités (composition, référencement, …)
de gérer les aspects techniques des entités : définition d’un typage technique des entités : produit, recette, article, document, … définition d’autres typages des entités : interne, externe (amont / aval)
Les fonctionnalités de ce module doivent également permettre de : de réaliser des opérations sur les nomenclatures :
calcul de tous les composants d’un produit à (ou jusqu’à) un niveau donné calcul de tous les composants d’un produit tous niveaux confondus calcul de la liste des composants d’un produit « à plat »
de réaliser des opérations de « cas d’emploi » (inversion des nomenclatures) : calcul de tous les produits utilisant un composant à un niveau (ou jusqu’à) donné
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 7 / 44
Gestion de données & documents techniques
Cahier des charges
calcul de tous les produits utilisant un composant tous niveaux confondus calcul de tous les produits utilisant un composant « à plat »
de réaliser des opérations de filtrage : par types d’entités par types de relations entre entités jusqu’à un niveau donné
de réaliser des opérations de sélection : de variantes techniques (versions) de variantes commerciales (options) de « vues » métiers
de réaliser des opérations de recherche : de l’ensemble des composants « référencés » pour un composant « spécifié » de l’ensemble des composants « spécifiés » nécessaire à un composant « référencé » de l’ensemble des composants « référencés » chez un fournisseur donné de l’ensemble des composants « spécifiés » par un client donné des besoins en un composant « référencé » donné
de réaliser des opérations de validation : existence et/ou définition des entités utilisées cohérence des nomenclatures (auto-référence, référence circulaire, …) cohérence de la hiérarchie des types
III.2.2. Module de gestion de la bibliothèque de composantsCe module a pour fonction de caractériser les entités que nous gérons « en tant que composants ».Cette fonction est essentielle à la formalisation de la constitution de nos composants :
entités « spécifiées », représentant les besoins en produits de nos clients et nos besoins en composants vis à vis de nos fournisseurs
entités « référencées », représentant les solutions techniques des composants réalisés par nos fournisseurs et des produits que nous réalisons pour nos clients
Ce module doit nous permettre de caractériser nos entités avec un nombre de caractéristiques illimité. Il doit donc permettre :
de gérer les caractéristiques susceptibles d’être utilisées : création, modification et suppression de caractéristiques création, modification et suppression de groupes de caractéristiques
de gérer les relations entre les caractéristiques et les entités : définition d’attributs pour ces relations (mini, cible, maxi, unité, fréquence, méthode, …) définition d’associations groupe d’entités / groupe de caractéristiques définition de valeurs par défaut pour les attributs de certaines associations attribution de valeurs particulières pour chaque caractéristique pour chaque composant
Les fonctionnalités de ce module doivent également permettre : d’extraire les informations relatives aux entités « spécifiées » :
spécifications matières premières, emballages, produits finis, … planning d’études de capabilité et d’analyses extérieures, plan de contrôle au lot
d’extraire les informations relatives aux entités « référencées » : fiches techniques matières premières, emballages, produits finis, …
d’effectuer des opérations sur les caractéristiques : calcul (somme, moyenne, binaire, …) de valeurs de caractéristiques d’un produit en
fonction des valeurs de caractéristiques de ses composants comparaison de valeurs de caractéristiques de composants d’un même groupe
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 8 / 44
Gestion de données & documents techniques
Cahier des charges
III.2.3. Module de gestion des prototypes de produitsCe module a pour fonction de définir des nomenclatures de produits « concrets », sortes d’instances
physiques des nomenclatures de produits « abstraits ».Cette fonction est essentielle à la formalisation de la composition de nos produits « concrets ».Les nomenclatures « concrètes » sont composés par des :
entités « concrètes » « spécifiées », représentant les commandes de prototypes (et d’échantillons) de nos clients et nos commandes de prototypes (et d’échantillons) vis à vis de nos fournisseurs.
entités « concrètes » « référencées », représentant les prototypes (et les échantillons) de composants réalisés par nos fournisseurs et les prototypes (et les échantillons) de produits que nous réalisons pour nos clients
Cette fonction est également nécessaire à la gestion de la transition entre la phase de développement et la phase d’industrialisation :
En phase de développement, les nomenclatures des « concrets » servent à mettre au point la structure des nomenclatures de produits « abstraits »
En phase d’industrialisation, les nomenclature des produits « abstraits » servent à définir la structure des nomenclatures des produits « concrets »
Ce module doit nous permettre de définir des nomenclatures de produits « concrets » relativement aux nomenclatures de produits « abstraits ».
Les fonctionnalités de ce module doivent permettre : de gérer les entités « concrètes » composant les nomenclatures :
création, modification et suppression d’objets « concrets » de gérer les relations entre :
Entités « concrètes » « spécifiées » et « référencées » Entités « spécifiées » « concrètes » et « abstraites » Entités « référencées » « concrètes » et « abstraites »
d’extraire les informations relatives aux : commandes d’échantillons fiche de réalisation d’échantillons
III.2.4. Module de gestion de la librairie de composantsCe module a pour fonction de caractériser les entités « concrètes » qui composent les nomenclatures de
produits « concrets ».Cette fonction est essentielle à la formalisation de la constitution de nos composants « concrets ».Les entités « concrètes » doivent pouvoir être caractérisées avec au minimum les mêmes
caractéristiques que celles utilisées pour caractériser nos entités « abstraites » correspondantes, mais également par des caractéristiques qui leur sont propres.
Cette fonction est également nécessaire à la gestion de la transition entre la phase de développement et la phase d’industrialisation :
En phase de développement, les caractéristiques des composants « concrets » servent à mettre au point les caractéristiques des composants « abstraits »
En phase d’industrialisation, les caractéristiques des composants « abstraits » servent à valider les caractéristiques des composants « concrets »
Les fonctionnalités de ce module doivent permettre : de gérer les caractéristiques des entités « concrètes » :
Cf module de gestion de la bibliothèque de composants d’effectuer des opérations sur les caractéristiques :
consolidation (somme, moyenne, …) de valeurs de caractéristiques historisation de valeurs de caractéristiques
d’extraire les informations relatives aux :
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 9 / 44
Gestion de données & documents techniques
Cahier des charges
fiches de contrôles
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 10 / 44
Gestion de données & documents techniques
Cahier des charges
III.3. Fonctionnalités du module de gestion de documents techniquesCe module a pour fonction de définir les processus de conception, de production et de diffusion de nos
documents, que ce soit pour des usages internes ou externes.Cette fonction est essentielle pour obtenir le niveau de qualité nécessaire à la triple maîtrise :
du contenu de nos documents de la présentation de nos documents (structure et format) des délais de production de nos documents
Les documents (au sens large du terme : documents « papiers » ou « électroniques ») sont les vecteurs des données stockées dans notre système, ils doivent pouvoir être le support d’une même information présentée de différentes manières en fonction de leur rôle et/ou de leur destination.
La gestion des documents doit permettre la diffusion des bonnes informations au sein de l’entreprise et auprès de nos clients, fournisseurs et partenaires, selon des règles qui garantissent que l’information est donnée au bon moment à la bonne personne.
Les fonctionnalités recherchées sont : création, modification et suppression de familles de documents création, modification et suppression de familles de liens entre documents gestion du cycle de vie des documents gestion des validations gestion des listes de diffusion gestion de la confidentialité des informations
Pour ce faire, nous souhaitons pouvoir assurer une gestion séparée, mais dépendante : des modèles à l’origine de ces documents des documents eux-mêmes des données de ces documents
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 11 / 44
Gestion de données & documents techniques
Cahier des charges
III.4. Fonctionnalités liées à l’ergonomie de l’Interface Homme / MachineChapitre en cours de finalisation, …
Liste des fonctionnalités initialement demandées :
Fonctionnalités liées à la présentation des informations : Représentation graphique des nomenclatures … … à la manière de l’explorateur de Windows … cohérente avec notre mode de représentation des nomenclatures
Fonctionnalités liées à la personnalisation de la représentation des informations : Personnalisation des icônes Personnalisation des liens
Fonctionnalités liées à l’utilisation des modules : Navigation hyper textuelle Menu contextuel Appel des propriétés des entités et des relations Support du copier-coller Support du « Drag & Drop »
Fonctionnalités liées à la saisie des informations : Présentation de liste déroulante Fonction de complément de saisie
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 12 / 44
Gestion de données & documents techniques
Cahier des charges
IV. Dimensionnement de l’application
IV.1. Nombre d’utilisateurs
NOMBRE DE PERSONNES POTENTIELLEMENT CONCERNÉES
Service Initiales Potentiellement Nombre
Maquette Nombre
Application Nombre
Qualité JMR 1 1 1R&D / CQ BC / PC / RH / MCJ / MV / MJP / SM 7 1 A définirAchats YT 1 1Production YB / JR / FQ / FG / JCS 5 A définirCommercial PG / CB / NP/ NC / LC / SG / JMD 7 1 A définir
Remarque : Nous souhaitons valider la maquette avec les 3 utilisateurs les plus impliqués dans le processus actuel de production de documents techniques.
IV.2. Nombre d’objets à décrire
NOMBRE D’ENTITES POTENTIELLEMENT CONCERNÉES
Entités Description Potentiellement Nombre
Maquette Nombre
Application Nombre
PRODUIT (distrib.) 90 8-15 TousPalette (pleine) 80 8-15 TousPalettisation 30 2 TousCarton (pleine) 80 8-15 TousCartonnage 10 2 TousEtui (plein) 110 8-15 TousEtuyage 10 2 TousPapillote (pleine)ou sache (pleine)
80 8-12 Tous
Produits (consom.) 40 3 TousRecettes 45 4-6 TousFormules 45 4-6 TousMatières premières spécifiés 70 20 TousMatières premières référencés 140 30 TousPalette (vide) spécifiés 1 1 TousCartons (vide) spécifiés 12 2 TousEtui (vide) spécifiés 75 8-15 TousPapillote (vide) ou sache (vide)
spécifiés 60 8-12 Tous
Caractéristiques PF, MP, SF, PE 120-150 15-20 Tous
Remarque : Nous souhaitons valider la maquette sur 2 ou 3 « produits consommateurs » pour 4 à 5 clients soit au total 8 à 15 « produits distributeurs ».
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 13 / 44
Gestion de données & documents techniques
Cahier des charges
V. Contraintes techniquesNous disposons de PC (caractéristiques moyennes : PII 400 Mhz - 64 Mo RAM - 4 Go DD) sous WIN98
en réseaux.
V.1. Contraintes matériellesMerci de nous préciser les caractéristiques matérielles nécessaires au support de la solution proposée
pour les phases de maquettage et de déploiement.
POSTE SERVEUR
Critère Caractéristiques minimum Caractéristiques conseillées
Type de processeurTaille de la mémoire viveCapacité du disque dur...
POSTE CLIENT
Critère Caractéristiques minimum Caractéristiques conseillées
Type de processeurTaille de la mémoire viveCapacité du disque dur...
RÉSEAU
Critère Caractéristiques minimum Caractéristiques conseillées
...
V.2. Contraintes logiciellesMerci de nous préciser les caractéristiques logicielles nécessaires au support de la solution proposée
pour les phases de maquettage et de déploiement.
POSTE SERVEUR
Critère Caractéristiques minimum Caractéristiques conseillées
Système d’exploitationBase de données...
POSTE CLIENT
Critère Caractéristiques minimum Caractéristiques conseillées
Système d’exploitationBase de données...
RÉSEAU
Critère Caractéristiques minimum Caractéristiques conseillées
...
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 14 / 44
Gestion de données & documents techniques
Cahier des charges
ANNEXES
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 15 / 44
Gestion de données & documents techniques
Cahier des charges
A - Détails de l’état des lieux
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 16 / 44
Gestion de données & documents techniques
Cahier des charges
Annexe A1 - Présentation du contexte
ContexteInitiée par une demande systématique en cahiers des charges accompagnant le référencement de nos
produits à marque de distributeurs, la demande en documents techniques en tous genres a évolué de manière significative ces derniers temps.
Cette évolution se caractérise essentiellement par la volonté de nos clients d’obtenir de notre part des documents de plus en plus complets et précis, mais surtout personnalisés.
De plus en plus de documents techniquesLe nombre de documents techniques ne cesse d’augmenter pour des raisons liées à l’augmentation du
niveau d’activité de la société : plus de clients à marque de distributeur ( … en France) développement de la société sur le marché Européen plus de produits par clients plus de demandes de développements de nouveaux produits extension du principe de contractualisation par cahiers des charges sur le segment 1er Prix augmentation du nombre de dossiers transversaux (Organismes Génétiquement Modifiés,
supplémentation nutritionnelle, sécurité alimentaire, environnement, agriculture raisonnée, emballages, dossiers « export », charte éthique, …).
Des documents de plus en plus volumineuxLe volume des documents techniques augmente :
augmentation du nombre de thèmes à traiter dans un même document augmentation du niveau d’exigence et de détails des informations
Des documents de plus en plus techniquesLa complexité des documents techniques augmente :
structuration des documents (sommaire, pagination, annexes, …) gestion des documents (réutilisation des documents, versionnage, …) personnalisation des documents (structure, présentation, format des données, langue, …)
Des délais de plus en plus courts demande de développement de nouveaux produits plus rapidement précocité du besoin en document dans le processus de développement (dès l’appel d’offre)
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 17 / 44
Gestion de données & documents techniques
Cahier des charges
Annexe A2 - Présentation de la problématiqueLe contexte précédemment décrit est à l’origine d’un certain nombre de difficultés. La quasi-totalité des informations nécessaires à l’élaboration de ces documents techniques existe au sein
de l’entreprise sous forme papier puisqu’elle est en grande partie formalisée dans le corpus documentaire mis en place dans le cadre de notre certification de la qualité.
Néanmoins, la production de ces documents techniques est une tâche complexe, longue et fastidieuse car la structure de notre système documentaire d’assurance qualité ne nous permet pas de répondre efficacement de manière satisfaisante (qualité / délais) aux demandes d’informations de nos clients.
Problèmes liés aux différences de vue sur l’informationEn effet, la vue principale de nos clients est une vue « produit », et chaque produit est décliné en ses
différents aspects.Exemple : Pour un produit donné, il voudra connaître un grand nombre de ses aspects comme sa
composition, les caractéristiques de ses composants (ingrédients, ingrédients des ingrédients composés, emballages et sur-emballages), ses caractéristiques organoleptiques, la législation qui est applicable à son contenu et à son contenant, son procédé de fabrication, son plan de contrôle, son plan de palettisation, ses textes et graphismes d’emballage, son GENCOD (code à barres), son mode de traçabilité, ses caractéristiques environnementales, ...
Or, l’organisation de notre système documentaire d’assurance qualité (SDAQ) est telle que la vue principale est une vue « aspect », et que chaque aspect est décliné selon les produits que nous commercialisons.
Exemple : Pour un aspect donné, nous disposons d’un classeur constitué d’une famille de documents décrivant l’aspect considéré pour chacun de nos produits. Nous avons ainsi un classeur des recettes, un classeur des gammes de fabrication, un classeur des palettisations, ...
Problèmes liés à la factorisation de l’informationEn réalité, pour de nombreux couples aspect - produit, il n’existe pas de document spécifique du SDAQ,
il existe plutôt un document traitant de cet aspect pour un groupe de produits auquel il appartient. Exemple : Il n’existe qu’une seule fiche nutritionnelle de la « barre pomme-abricot sans vitamine » pour
l’ensemble de nos clients, qu’un seul plan de palettisation pour plusieurs produits différents, ...
Problèmes liés aux différentes factorisations possibles de l’informationDe plus, le mode de groupage documentaire des produits pour un aspect donné n’est pas toujours
identique car il est étroitement dépendant de l’aspect considéré.Exemple : Le mode de groupage des fiches nutritionnelles suit à priori une logique « produit » et/ou
« gamme de produit », alors que celui des plans de palettisation a plutôt tendance à suivre une logique « client » et « format de l’U.V.C. ». Certains groupages sont très complexes à mettre en place car ils peuvent dépendre de la présence d’un ingrédient spécifique ou de la destination géographique finale du produit, …
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 18 / 44
Gestion de données & documents techniques
Cahier des charges
Problèmes liés à la granularité de l’information factoriséeEt, difficulté supplémentaire, le mode de groupage documentaire des produits dépend également de la
quantité d’information qui constitue un aspect donné. En effet, moins un aspect comporte d’éléments d’informations, moins on aura besoin de documents différents pour décrire l’ensemble des produits.
Exemple : Si une famille de documents ne décrit que « l’aspect réglementaire de nos produit vis-à-vis du chocolat », deux documents suffisent à décrire cet aspect ; car soit il y a du chocolat dans le produit, soit il n’y en a pas. Si une famille de documents décrit « l’aspect réglementaire de nos produits dans son intégralité », le nombre de documents nécessaires pour décrire cet aspect sera considérablement augmenté compte-tenu de la combinatoire que l’ensemble des éléments d’informations de cet aspect induit.
Conclusion : La logique de structuration de notre SDAQ, qui dérive de notre fonctionnement interne ne nous permet
que de factoriser (très partiellement) l’information utile selon notre propre vision des choses. Elle n’est donc absolument pas adaptée à la production de documents selon la vision principale de nos clients qui est une vue « produit ».
De ce fait, elle ne nous permet pas de satisfaire de manière simple, rapide et efficace aux demandes de ces derniers sans devoir refondre et adapter complètement les documents existants à chaque nouvelle demande de document technique.
Par ailleurs, notre SDAQ est relativement lourd à faire évoluer car il s’appuie sur une organisation essentiellement « papier », même si chaque document « papier » est issu d’un fichier bureautique, la mise à jour du SDAQ est parfois complexe compte-tenu des références croisées qui peuvent exister au sein de certains documents.
En conséquence, il n’est pas adapté (y compris pour des besoins internes) au contexte de perpétuelle évolution de nos données de produits.
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 19 / 44
Gestion de données & documents techniques
Cahier des charges
Annexe A3 - Solution technique provisoireCertains documents de notre SDAQ fournissent l’information technique nécessaire à la description des
produits que nous commercialisons. Cette information disponible sous forme papier est essentiellement stockée dans des fichiers
bureautiques Excel et Word de manière non structurée.En adéquation avec les normes ISO-9002, chaque document est issu d’un modèle dont la trame est
dûment référencée dans le SDAQ.
A chaque trame remplie de documents correspond un fichier Word contenant soit : des données « en dur », mais de plus en plus, des données « liées à un fichier Excel » faisant remonter :
uniquement des champs de données simples des champs de données simples et/ou des champs de données correspondant à des
chemins de « composants documentaires » (fichiers Word en général)
En effet, dans certains cas, nous avons scindé certains documents en sous-documents appelés « composants documentaires ». Ces documents sont alors reconstitués en utilisant simultanément des tables de configuration (fichiers Excel) et le mécanisme de fusion de Word.
Cela nous permet d’apporter un peu de souplesse à notre organisation en autorisant : une plus grande facilité à factoriser l’information une plus fine granularité de l’information gérée
Pourtant, le niveau de souplesse que nous avons introduit est encore insuffisant pour au moins deux raisons :
le choix du découpage en « composants documentaires » a un impact direct sur le niveau de granularité de l’information susceptible d’être traitée en automatique,
Cela ne nous permet donc pas de construire des documents pour ceux de nos clients qui ne catégorisent pas les différents « aspects » d’un « produit » selon la même structure.
Le choix des libellés utilisés au sein des « composants documentaires » a également un impact sur ce niveau de granularité.
Cela ne nous permet donc pas de construire des documents pour ceux de nos clients qui ne désignent pas les différents « aspects » d’un « produit » avec la même terminologie.
Par ailleurs, ne s’appuyant que sur des outils bureautiques, ce système est extrêmement lourd à gérer et à faire évoluer. Par ailleurs, il pose de nombreux problèmes de gestion documentaire car les mécanismes de base de cette gestion (versionnage, validation, diffusion, … ) ne sont absolument pas automatisés.
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 20 / 44
Gestion de données & documents techniques
Cahier des charges
Annexe A4 - Solution organisationnelle provisoire
PROCÉDURE DE TRAITEMENT DES CAHIERS DES CHARGES
PT QUI QUOI COMMENTAIRE
1 LE CLIENT
LA STRUTURE
LE FORMAT :
Présentation
Format du contenu
2 SERVICE COMMERCIALGESTION QUALITER&D
3 SERVICE COMMERCIAL
DOCUMENT WORD
4 GESTION QUALITE
DEFINIR LA BASE DE DONNEES EXCEL
ADAPTATION DES DONNEES TECHNIQUESPAR R&D
5 GESTION QUALITE
MODE PUBLIPOSTAGEDANS WORD
6 SERVICE COMMERCIAL
INFOS TECHNIQUES(Source R&D)
INFO QUALITE(Source Gestion qualité)
7 SERVICE COMMERCIAL
8 R&DGESTION QUALITESERVICE COMMERCIALLE CLIENT
COPIE DU CAHIER DES CHARGES POUR R&D APRES VALIDATION PAR LE CLIENT
9 SERVICE COMMERCIAL
FUSIONNER
ROMPRE LES LIENS
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 21 / 44
DEFINITION DU CAHIER DES CHARGES
DEFINITION DU CAHIER DES CHARGES
ANALYSER LES BESOINSANALYSER LES BESOINS
MISE EN FORME DU MODELE
MISE EN FORME DU MODELE
STRCTURATION DES DONNEES
STRUCTURATION DES DONNEES
IMPLEMENTER LES CHAMPS DE LA BASE DE DONNEES DANS LE MODELE
IMPLEMENTER LES CHAMPS DE LA BASE DE DONNEES DANS LE MODELE
RENSEIGNER LA BASE DE DONNEESRENSEIGNER LA BASE DE DONNEES
EDITER LE CAHIER DES CHARGESEDITER LE CAHIER DES CHARGES
VALIDATIONVALIDATIONNon
OUI
ARCHIVERARCHIVER
Gestion de données & documents techniques
Cahier des charges
B – Présentation du type de solution souhaitée
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 22 / 44
Gestion de données & documents techniques
Cahier des charges
Annexe B1 - Présentation du type de solution souhaitée
SCHÉMA DU TYPE DE SOLUTION SOUHAITEE
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 23 / 44
MODELEDE
DOCUMENTSFAMILLE
DEDOCUMENTSFormat
Structure
OBJETS TECHNIQUES=
ENTITES+
RELATIONS
Structure
Format Contenu
Règles d’extraction du contenu
AUTRES APPLICATIONS : GPAO, …
Contenu
MODULE
GESTION DES NOMENCLATURES
MODULE
GESTION DES PROTOTYPES
MODULE
BIBLIOTHEQUEDE COMPOSANTS
MODULE
LIBRAIRIEDE COMPOSANTS
DICTIONNAIRE
Gestion de données & documents techniques
Cahier des charges
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 24 / 44
Gestion de données & documents techniques
Cahier des charges
Annexe B2 - Type de documents à gérerLes documents dont nous avons besoin peuvent être structurées en au minimum 4 familles principales
dont les caractéristiques essentielles peuvent être résumées par le tableau ci-après :
CARACTÉRISTIQUES DES DOCUMENTS NECESSAIRES
Documents internes Documents externes
EXEMPLES de MODELE de DOCUMENTS Fiche tech. interne
Recette Fiche tech. externe Spécif. produit fini Cahier des charges
Retour d’appel d’offre
FONCTIONNALITESFonction principaleFonction secondaire
Fonctionnement AADFormalisation
ProspectionPrésentation
NégociationAdaptation
ContractualisationPersonnalisation
CARACTERISTIQUESQuantité d’informationNature de l’information
MaximaleConfidentielle
MinimaleNon confidentielle
=> Adaptée=> Pertinente
OptimaleNégociée
CYCLE DE VIEModèle défini parDocument rédigé parDocument destiné à
AADAADAAD
AADAAD«CLIENT»
AADAADAAD et «CLIENT»
« CLIENT » (ou AAD)AAD (ou «CLIENT»)AAD et «CLIENT»
ADAPTATION du MODELEDe la structureDu format (présentation)
NONNON
NONNON (OUI)
OUINON
OUIOUI
ADAPTATION du CONTENUFormat du contenuMulti languesPersonnalisation
NONNONNON
NONOUINON
NONNONOUI
OUIOUIOUI
DIMENSIONNEMENTNb de familles (maxi)Nb de représentants par famille
1 / modèle1 / recette
1 / modèle1 / recette
1 / client – recette1 / client – recette
1 / client – modèle1 / recette du client
CIBLE de FORMAT de FICHIER Sorties « papier »Electronique pure Média
.doc .xls .pdf
.htm (photoshop, …)intranet
.doc
.htmInternet, zip, CD-Rom
.doc
.doc .xls .htmzip, CD-Rom, ...
.doc
.doc .xls .htmzip, CD-Rom, ...
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 25 / 44
Gestion de données & documents techniques
Cahier des charges
C – Mode de représentation des nomenclatures de produits
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 26 / 44
Gestion de données & documents techniques
Cahier des charges
Postulat initial
POSTULAT
Pour un acteur donné, un projet est la rencontre entre : un BESOIN un PRODUIT des RESSOURCES
DÉFINITIONS
Au sens du postulat ci-dessus : Un acteur peut être un individu, un service, une société ou une organisation quelconque Un projet est l’ensemble des actions visant à élaborer un PRODUIT à partir d’une ou plusieurs
RESSOURCES dans le but de satisfaire un BESOIN. il peut être découpé en sous-projets, autant de fois que nécessaire il peut être extrêmement complexe ou très simple
L’expression la plus simple d’un projet élémentaire peut se schématiser comme ci-après.
SCHÉMA
COMMENTAIRES SUR LE MODÈLE
A ce stade de la spécification du modèle de donnée, les concepts de BESOIN, PRODUIT et RESSOURCES sont encore flous, ainsi que la nature des relations entre ces concepts.
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 27 / 44
projet1 -
No
menclature de base.do
c
RESSOURCES
BESOINPRODUIT
Gestion de données & documents techniques
Cahier des charges
Nomenclature de base
NOTION DE NOMENCLATURE DE BASE
Pour un PRODUIT donné d’un acteur donné, les RESSOURCES évoquées dans le schéma précédent sont les produits d’un ou plusieurs autres acteurs.
Définition : La nomenclature de base d’un PRODUIT représente l’ensemble des relations de ce dernier avec ses RESSOURCES.
SCHÉMA
DÉMARCHE
A partir de la représentation d’un projet élémentaire et de cette notion de nomenclature de base, nous utilisons une méthode de représentation de nos PRODUITS sous forme de nomenclatures plus élaborées, qui intègrent en particulier les concepts de RESSOURCES et de BESOINS.
En effet, cette notion de nomenclature de base est insuffisante pour intégrer les concepts souhaités. De plus, une représentation valide de la nomenclature d’un PRODUIT doit à la fois :
être indépendante du point de vue de chaque acteur, rendre compte du point de vue de chacun d’eux être valide pour n’importe quel type de structure
Acteur particulier Entreprise étendue Prestataire de service (ou groupements d’acteurs)
Pour ce faire, nous avons cherché à identifier : la nature des entités élémentaires constitutives de ces nomenclatures la nature des relations entre ces entités élémentaires
La notion de nomenclature de base est ainsi complétée des notions de : Nomenclature étendue Super-nomenclature Nomenclature duelle
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 28 / 44
Liens de COMPOSITION
PRODUIT
RESSOURCES=
produits d’autres acteurs
Gestion de données & documents techniques
Cahier des charges
Nomenclature étendue
INTRODUCTION
Un PRODUIT donné d’un acteur donné est composé de produits d’autres acteurs (qui sont ses « fournisseurs » au sens large du terme), pouvant à leur tour être composés de produits de leurs propres « fournisseurs », etc …
A contrario, un PRODUIT donné d’un acteur donné peut être le composant d’un ou plusieurs produits d’autres acteurs (qui sont ses « clients » au sens large du terme), pouvant à leur tour être les composants des produits de leurs propres « clients », etc …
Un PRODUIT donné d’un acteur donné joue tour à tour le rôle de COMPOSÉ ou de COMPOSANT au sein d’une même nomenclature selon le point de vue « client » ou fournisseur » de l’acteur considéré.
Définition : La nomenclature étendue d’un PRODUIT représente l’ensemble des liens de COMPOSITION avec les produitS des autres acteurs pour l’ensemble des sous-nomenclatures
SCHÉMA
CONCLUSION
Une même chose peut (et doit) être vue comme un composé ou comme un composant selon le point de vue de l’acteur considéré.
COMPOSÉ et COMPOSANT sont deux aspects d’une seule et même chose, il ne s’agit donc pas des entités élémentaires à partir desquelles nous pouvons élaborer notre modèle de données.
NOTES
Un produit peut être composé d’un ou plusieurs produits d’autres acteurs - Un produit peut être le composant d’un ou plusieurs produits d’autres acteurs - Une nomenclature étendue peut être constituée d’un nombre illimité de sous-nomenclatures sur un nombre illimité de niveau - Un acteur donné peut être son propre client et/ou fournisseur. Les produits doivent pouvoir être caractérisés relativement à l’entreprise (interne ou externe (amont ou externe)).
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 29 / 44
produit= composant
PRODUIT= COMPOSÉ
Liens de composition
Produit d’autres acteurs
(FOURNISSEUR)= COMPOSANTS
Produit d’autres acteurs
(CLIENTS)= composés
Gestion de données & documents techniques
Cahier des charges
Super-nomenclature
INTRODUCTION
Pour un PRODUIT donné d’un acteur donné ses RESSOURCES peuvent : composer ce PRODUIT : matières premières, emballages, consommables, …
Ce sont des « composants » ou participer à l’élaboration de ce PRODUIT : procédés, méthodes, documents, …
Ce sont des « ressources »Définition : La super-nomenclature d’un PRODUIT représente l’ensemble des liens de composition et
des liens d’allocation entre un COMPOSÉ et ses COMPOSANTS.
SCHÉMA
CONCLUSION
Une même chose peut (et doit) être vue comme un composant ou comme une ressource selon le point de vue de l’acteur considéré.
Composant et ressource sont deux aspects d’une seule et même CHOSE, il ne s’agit donc pas des entités élémentaires à partir desquelles nous pouvons élaborer notre modèle de données
NOTES
Il existe un nombre illimité de type de liens d’allocation (liens d’utilisation d’une ligne de fabrication, liens de suivi d’une méthode, liens de référence à une documentation (interne, normative, législative, …), …)
Les liens d’allocation doivent pouvoir être caractérisés d’au moins deux manières : Allocation directe ou indirecte pour élaborer un produit donné, Allocation d’une ressource interne ou externe.
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 30 / 44
COMPOSANTS= « ressources »
Liens de composition
COMPOSANTS= « composants »
Liens d’allocation
COMPOSÉ
Gestion de données & documents techniques
Cahier des charges
Nomenclature duelle
INTRODUCTION
Un PRODUIT donné d’un acteur donné est une solution technique conçue pour répondre à un ensemble de fonctions et respecter un certain nombre de contraintes (i.e. BESOIN)
Il existe deux types de relations entre « solution technique » et « fonctions & contraintes » : Une qui permet d’associer un BESOIN à un (ou plusieurs) PRODUIT(S) Une qui permet de décomposer un PRODUIT en besoins élémentaires
Définition : La nomenclature duelle d’un PRODUIT représente l’ensemble des liens de COMPOSITION et des liens de REFERENCEMENT.
SCHÉMA
CONCLUSION
« fonctions & contraintes » et « solution technique » ne dépendent pas du point de vue de l’acteur considéré.
« fonctions & contraintes » et « solution technique » sont deux CHOSES différentes, il s’agit donc d’entités élémentaires à partir desquelles nous pouvons élaborer notre modèle de données
Au sens où nous l’entendons maintenant, la nomenclature d’un produit est plus exactement ce que l’on pourrait appeler une « Super-nomenclature étendue duelle ».
NOTES
Une entité « fonctions & contraintes » peut être en liaison avec plusieurs entités « solution technique », car un même BESOIN peut être satisfait par différents PRODUITS. Une entité « solution technique », peut être en liaison avec plusieurs entités « fonctions & contraintes », car un même PRODUIT peut nécessiter plusieurs BESOINS.
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 31 / 44
COMPOSANTS=
« fonctions & contraintes »
Liens de COMPOSITION
Lien deRÉFÉRENCEMENT
COMPOSANTS=
« solution technique »
Liens de RÉFÉRENCEMENT
COMPOSÉ=
« fonctions & contraintes »
COMPOSÉ=
« solution technique »
Gestion de données & documents techniques
Cahier des charges
Super-nomenclature étendue duelle
COROLLAIRE
La triple nécessité de : Dissocier les notions de « fonctions & contraintes » et « solution technique » Prendre en compte les aspects « composé » et « composant » d’un même PRODUIT et les
aspects « composé » et « composant » d’un même BESOIN Assurer cette gestion sur un nombre illimité de niveau,
nous conduit à la représentation ci-après.
SCHÉMA
CONCLUSION
Les seuls concepts indépendants du point de vue d’un acteur particulier (ou d’un produit particulier) sont les concepts de « fonctions & contraintes » et de « solution technique ».
Ils deviennent des entités élémentaires du modèle de données
Les notions de « composé » et de « composant », ainsi que les notions de « constituant » et de « ressources » sont dépendantes du point de vue des acteurs (ou des produits). Ce ne sont que des aspects différents des concepts présentés ci-dessus.
Elles sont représentées par le type (et/ou le sens) des relations entre les entités élémentaires du modèle de données.
COMMENTAIRE SUR LE MODELE
Par ailleurs, un vocabulaire spécifique nécessite d’être utilisé, afin d’éviter les confusions sur la dénomination des notions dont le nom change en fonction du point de vue.
Les entités « spécifiés » sont celles qui représente un BESOIN = « fonctions & contraintes » Les entités « référencés » sont celles qui représente un PRODUIT = « solution technique »
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 32 / 44
Gestion de données & documents techniques
Cahier des charges
Bibliothèque de composants
INTRODUCTION
Afin de pouvoir caractériser les entités d’une nomenclature aussi finement que possible, il est nécessaire de pouvoir les associer à des propriétés.
Cette association est réalisée via des liens de constitutions entre les entités et des caractéristiques prédéfinies.
Définition : La bibliothèque de composants représente le prolongement de la nomenclature vers les propriétés des PRODUITS.
SCHÉMA
CONCLUSION
Disposer de la possibilité de caractériser les composants au sein du même système est essentiel, mais il faut pouvoir acquérir des valeurs. Il sera donc nécessaire de pouvoir gérer des représentants « concrets » des composants (Cf librairie de composants).
COMMENTAIRE SUR LE MODELE
La représentation des caractéristiques n’est pas finalisée, il se peut que nous ayons besoin de caractéristiques « spécifiées » et de caractéristiques « référencées », si les liens de constitution ne peuvent pas se prêter à certaines représentations.
NOTES
Fonctionnalités à préciser et/ou formaliser : Définir des groupes de caractéristiques - Utiliser le cas d’emploi une caractéristique donnée -remonter une caractéristique de tous les composants au niveau d’un composé - Définir des règles de « propagation » (consolidation) de caractéristiques (binaire, somme, moyenne, mini, maxi, …) - Définir des règles de relations entre caractéristiques (S = L x l) – Gestion des unités du S.I., des dimensions de base exprimées en unité du S.I. et des unités courantes, du format des unités de mesure, des règles d’arrondis.
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 33 / 44
entités« solution technique »
entités« fonctions & contraintes»
caractéristiques« propriétés »
Liens deconstitution
Liens deconstitution
Gestion de données & documents techniques
Cahier des charges
Nomenclature concrète
INTRODUCTION
Afin de pouvoir assurer la gestion de maquettes et d’échantillons de produits il est important de pouvoir disposer d’information sur la composition d’entités « concrètes », espèce de représentante physique des entités « abstraites » correspondantes.
Cette association est réalisée via des liens d’instanciation physique entre : les entités « abstraites », virtuelles, logiques, … les entités « concrètes », réelles, physiques, …
Définition : La nomenclature « concrète » d’un PRODUIT est le prolongement de la nomenclature « abstraite » d’un PRODUIT et représente sa concrétisation physique.
SCHÉMA
FOURNISSEURS ACTEUR CLIENTS
CONCLUSION
Les nomenclatures de « concrètes » et « abstraites » sont nécessaires l’une à l’autre au fil des processus de conception et/ou modification de produits. Les nomenclatures « concrètes » initiales (prototypes) servent à élaborer la structure des nomenclatures « abstraites » qui fourniront celle des nomenclatures « concrètes » finales (échantillons de produit fini).
NOTES
Une nomenclature « abstraite » peut être en relation avec une ou plusieurs nomenclatures « concrètes ». Les nomenclatures « concrètes » issues d’une même nomenclature « abstraite » doivent pouvoir être comparées.
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 34 / 44
« fonctions & contraintes»CONCRETE
« solution technique »CONCRETE
« solutiontechnique»
ABSTRAITE
« fonctions & contraintes»ABSTRAITE
Liens d’instanciation
physique
Gestion de données & documents techniques
Cahier des charges
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 35 / 44
Gestion de données & documents techniques
Cahier des charges
Librairie de composants
INTRODUCTION
Afin de pouvoir caractériser les composants, il est important de pouvoir disposer d’informations sur les « composants réels », espèce de représentant des « composants théoriques ».
Cette association est réalisée via des liens d’instanciation physique entre les PRODUITS virtuels et les produits réels.
Définition : La librairie de composants est l’analogue « concret » de la bibliothèque de composants
SCHÉMA
Représentation hybride entre celles de :- la bibliothèque de composants- la nomenclature « concrète »
CONCLUSION
La nomenclature concrète est également en liaison avec des propriétés, et chaque nomenclature abstraite et concrète « s’informe » mutuellement.
Les valeurs des propriétés mesurées sur les nomenclatures concrètes, peuvent être consolidées. Elle servent de base à l’établissement des tolérances sur les nomenclatures abstraites, qui détermineront la conformité des futures nomenclatures concrètes.
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 36 / 44
Gestion de données & documents techniques
Cahier des charges
Autres fonctionnalités
INTRODUCTION
Un certain nombre d’autres fonctionnalités nous seront également nécessaires, mais elles n’ont pas encore été définies avec précision :
Aspect statique Gestion des options (options client, formule de secours, dérogation, …) Gestion des familles et des groupes
Aspect dynamique Gestion des versions (historique) Gestion des cycles de vie Gestion du prévisionnel
Aspect fonctionnel Analyse des écarts Gestion de l’analyse fonctionnelle (par utilisation de relation entre des entités et des
« fonctions »)
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 37 / 44
Gestion de données & documents techniques
Cahier des charges
D – Spécification formelle du modèle de données
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 38 / 44
Gestion de données & documents techniques
Cahier des charges
E – Spécification technique de la solution logicielle
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 39 / 44
Gestion de données & documents techniques
Cahier des charges
F – Jeux d’essais
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 40 / 44
Gestion de données & documents techniques
Cahier des charges
Annexe F1 - Jeux d’essai de donnéesEn construction
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 41 / 44
Gestion de données & documents techniques
Cahier des charges
Annexe F2 - Jeux d’essai de documentsPour des raisons de volume documentaire, les trames vides des documents que nous avons à produire
(appels d’offres, cahiers des charges, dossiers transversaux, documents du SDAQ, ….) ne peuvent être jointes à ce stade de l’avancement du projet.
Elles ne sont nécessaire ni à la compréhension de la problématique (intérêt strictement informatif), ni à la définition du type de solution à mettre en place pour y répondre.
Elles ne présenterons un intérêt pratique que pour la réalisation d’une maquette fonctionnelle.
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 42 / 44
Gestion de données & documents techniques
Cahier des charges
GLOSSAIRE
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 43 / 44
Gestion de données & documents techniques
Cahier des charges
Glossaire des termes utilisésArticle
Type d’entité nécessaire à la réalisation (logique ou physique) d’un produitCaractéristique
Type d’entité correspondant à la description des propriétés d’une entité de type articleDocument
Type d’entité correspondant un ensemble structuré et formaté de donnéesEntité
Elément de nomenclatureEntité « spécifié »
Elément d’une nomenclature représentant un besoin (demande ou commande)Entité « référencé »
Elément d’une nomenclature représentant une solution (produit ou échantillon)Famille
Ensemble d’objets possédant les mêmes attributs et ne différant que par leur valeursGroupe
Ensemble d’objets ayant des attributs communs, possédant ou non des valeurs identiquesNomenclature
Nomenclature au sens large, c’est à dire une super-nomenclature étendue duelle correspondant à celle du modèle de représentation des produits.
Nomenclature « abstraite » Nomenclature d’un produit logique
Nomenclature « concrète » Nomenclature d’un produit physique
RelationLien entre deux entités
Type d’entitéEntité ayant une justification technique particulière
Article, document, caractéristique, ...Type de relation
Lien entre deux entités jouant un rôle particulierLiens de composition, d’allocation, de référencement, d’instanciation physique, ....
B. CHABOT 17/02/2000 - D:\COMMUN\SGDT\Spécification\Cahier des charges.doc Page 44 / 44