Manager avec les ERP
138
© Groupe Eyrolles
◗ Application. Application {composition = logiciels (fonctions, modules
internes), ListePropriétés (application)} Classe d’application : comptabilité,
GPAO, gestion financière, etc.
Si une application ne rentre pas forcément dans le cadre d’une catégorie prédéterminée, il faut lui affecter une classe autre et la décrire. C’est notamment le
cas de certaines applications métiers.
◗ Module (il s’agit de module externe aux applications progicielles et logicielles).
Module {Composants, ListePropriétés (module)} Classe de module : module
d’ERP, module tierce partie, progiciel externe, développement spécifique,
autre.
On ne décrit les composants que si une « orientation objet » est donnée au
projet. En particulier, si l’approche composant n’a pas de signification dans le
projet, alors le module devient l’élément unitaire des applications, on notera :
Module = Nom du module, ListePropriétés (module), Classe de module :
module d’ERP, module tierce partie, progiciel externe, développement spécifique, autre.
◗ IHM. IHM {Objet d’IHM, ListePropriétés (IHM)} Classes d’IHM : gestion,
CAO, etc.
On définit les classes d’IHM selon celles qui sont déjà utilisées dans l’entreprise. Elles sont très variées et sont très dépendantes des métiers.
En pratique, l’IHM détermine a priori les postes de travail.
Les objets possibles de l’IHM sont : barre de menu, onglet, bouton radio,
bouton poussoir, ascenseur horizontal, ascenseur vertical, touche et bouton
« Aide », etc.
Il est recommandé de descendre à ce niveau de détail, car les outils de développement modernes permettent de réaliser des IHM à l’identique de spécifications précises. On s’assure ainsi d’une homogénéité d’interface, dans le
périmètre d’une même application.
◗ Input. Input = ListePropriétés (input), Classes d’input : saisie, pièce, reconnaissance optique de caractères, lecture à code-barres, EDI, fichier, etc.
◗ Output. Output = ListePropriétés (output), Classes d’output : fichier, listing,
état documentaire, envoi EDI, etc.
Pour les termes suivants, si l’on n’a pas opté pour une « orientation objet » du
projet, on peut se dispenser de leur description, encore que le terme composant
puisse être utilisé, même quand on n’est pas dans un domaine d’orientation objet.
Il est prudent de prévoir que des modules répétitifs s’appuient sur un composant
bien stabilisé. C’est le cas des conversions franc/euro qui sont impératives
entre 1999 et 2002.
138
© Groupe Eyrolles
◗ Application. Application {composition = logiciels (fonctions, modules
internes), ListePropriétés (application)} Classe d’application : comptabilité,
GPAO, gestion financière, etc.
Si une application ne rentre pas forcément dans le cadre d’une catégorie prédéterminée, il faut lui affecter une classe autre et la décrire. C’est notamment le
cas de certaines applications métiers.
◗ Module (il s’agit de module externe aux applications progicielles et logicielles).
Module {Composants, ListePropriétés (module)} Classe de module : module
d’ERP, module tierce partie, progiciel externe, développement spécifique,
autre.
On ne décrit les composants que si une « orientation objet » est donnée au
projet. En particulier, si l’approche composant n’a pas de signification dans le
projet, alors le module devient l’élément unitaire des applications, on notera :
Module = Nom du module, ListePropriétés (module), Classe de module :
module d’ERP, module tierce partie, progiciel externe, développement spécifique, autre.
◗ IHM. IHM {Objet d’IHM, ListePropriétés (IHM)} Classes d’IHM : gestion,
CAO, etc.
On définit les classes d’IHM selon celles qui sont déjà utilisées dans l’entreprise. Elles sont très variées et sont très dépendantes des métiers.
En pratique, l’IHM détermine a priori les postes de travail.
Les objets possibles de l’IHM sont : barre de menu, onglet, bouton radio,
bouton poussoir, ascenseur horizontal, ascenseur vertical, touche et bouton
« Aide », etc.
Il est recommandé de descendre à ce niveau de détail, car les outils de développement modernes permettent de réaliser des IHM à l’identique de spécifications précises. On s’assure ainsi d’une homogénéité d’interface, dans le
périmètre d’une même application.
◗ Input. Input = ListePropriétés (input), Classes d’input : saisie, pièce, reconnaissance optique de caractères, lecture à code-barres, EDI, fichier, etc.
◗ Output. Output = ListePropriétés (output), Classes d’output : fichier, listing,
état documentaire, envoi EDI, etc.
Pour les termes suivants, si l’on n’a pas opté pour une « orientation objet » du
projet, on peut se dispenser de leur description, encore que le terme composant
puisse être utilisé, même quand on n’est pas dans un domaine d’orientation objet.
Il est prudent de prévoir que des modules répétitifs s’appuient sur un composant
bien stabilisé. C’est le cas des conversions franc/euro qui sont impératives
entre 1999 et 2002.