Titre de niveau 1tollenam/ipro... · Web viewet/ou le cahier des charges pour le client du produit...

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 / 44


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.



Cahier des charges

CAHIER DES CHARGES



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 ».



Cahier des charges



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).



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é



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



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 :



Cahier des charges

fiches de contrôles



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



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



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 ».



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


Type de processeurTaille de la mémoire viveCapacité du disque dur...

RÉSEAU


...

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


Système d’exploitationBase de données...

POSTE CLIENT


Système d’exploitationBase de données...

RÉSEAU


...



Cahier des charges

ANNEXES



Cahier des charges

A - Détails de l’état des lieux



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)



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, …



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.



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.



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


INFOS TECHNIQUES(Source R&D)

INFO QUALITE(Source Gestion qualité)


8 R&DGESTION QUALITESERVICE COMMERCIALLE CLIENT

COPIE DU CAHIER DES CHARGES POUR R&D APRES VALIDATION PAR LE CLIENT


FUSIONNER

ROMPRE LES LIENS


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


Cahier des charges

B – Présentation du type de solution souhaitée



Cahier des charges

Annexe B1 - Présentation du type de solution souhaitée

SCHÉMA DU TYPE DE SOLUTION SOUHAITEE


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


Cahier des charges



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, ...



Cahier des charges

C – Mode de représentation des nomenclatures de produits



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.


projet1 -

No

menclature de base.do

c

RESSOURCES

BESOINPRODUIT


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


Liens de COMPOSITION

PRODUIT

RESSOURCES=

produits d’autres acteurs


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)).


produit= composant

PRODUIT= COMPOSÉ

Liens de composition

Produit d’autres acteurs

(FOURNISSEUR)= COMPOSANTS

Produit d’autres acteurs

(CLIENTS)= composés


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.


COMPOSANTS= « ressources »

Liens de composition

COMPOSANTS= « composants »

Liens d’allocation

COMPOSÉ


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.


COMPOSANTS=

« fonctions & contraintes »

Liens de COMPOSITION

Lien deRÉFÉRENCEMENT

COMPOSANTS=

« solution technique »

Liens de RÉFÉRENCEMENT

COMPOSÉ=

« fonctions & contraintes »

COMPOSÉ=

« solution technique »


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 »



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.


entités« solution technique »

entités« fonctions & contraintes»

caractéristiques« propriétés »

Liens deconstitution

Liens deconstitution


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.


« fonctions & contraintes»CONCRETE

« solution technique »CONCRETE

« solutiontechnique»

ABSTRAITE

« fonctions & contraintes»ABSTRAITE

Liens d’instanciation

physique


Cahier des charges



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.



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 »)



Cahier des charges

D – Spécification formelle du modèle de données



Cahier des charges

E – Spécification technique de la solution logicielle



Cahier des charges

F – Jeux d’essais



Cahier des charges

Annexe F1 - Jeux d’essai de donnéesEn construction



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.



Cahier des charges

GLOSSAIRE



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, ....


Titre de niveau 1tollenam/ipro... · Web viewet/ou le cahier des charges pour le client du produit...

Documents

Transcript of Titre de niveau 1tollenam/ipro... · Web viewet/ou le cahier des charges pour le client du produit...