Dossier de spécification Gestion des effectifs : Beaufour IPSEN Industrie TW52

(1)

Dossier de spécification

effectifs : Beaufour IPSEN Industrie

Automne

Matthieu LEROMAIN GI05 Ömer MADEN

Tuteur de stage : J.C. Gavoille Suiveur de la TW52 : A. Koukam

Automne 2007

Dossier de spécification – Gestion des effectifs : Beaufour IPSEN Industrie

0 | P a g e

Automne 2007

Matthieu LEROMAIN GI05 Ömer MADEN GI05 Tuteur de stage : J.C. Gavoille Suiveur de la TW52 : A. Koukam

Automne 2007

Gestion des

effectifs : Beaufour IPSEN Industrie – TW52

(2)

1 | P a g e

Remerciements

Nous remercions, tout d’abord, l’entreprise IPSEN et plus particulièrement le site de production de Dreux pour nous avoir permis d’effectuer ce travail au sein de leur entreprise.

Nous remercions Jean-Charles Gavoille, pour sa disponibilité et pour la liberté et la confiance qu’il a su nous accorder.

Sans oublier les responsables opérationnels de secteur qui nous ont éclairés sur les différentes fonctionnalités et les spécificités qu’ils leur paraissaient nécessaires de voir implémentées dans le logiciel.

Merci également à Christian Fisher pour son aide quant à l’élaboration de notre base de données.

Merci à l’UTBM qui permet à ses étudiants d’effectuer des stages de ce genre durant leur semestre d’étude ce qui leur permet d’approfondir leurs connaissances et de développer leur savoir-faire dans un domaine particulier.

(3)

2 | P a g e

Sommaire

Remerciements _____________________________________________________________ 1 Sommaire _________________________________________________________________ 2 1. Introduction ____________________________________________________________ 4 1.1) Buts de l’application _______________________________________________________ 4 1.2) Présentation générale du document __________________________________________ 4 1.3) Travail demandé __________________________________________________________ 5 2. Description générale _____________________________________________________ 6

2.1) Environnement et contexte du système _______________________________________ 6 2.2) Caractéristiques des utilisateurs _____________________________________________ 8 2.3) Contraintes de développement ______________________________________________ 9 3. Besoins fonctionnels ____________________________________________________ 10

3.1) Description générale ______________________________________________________ 10

3.2) La gestion des comptes d’utilisateurs et de l’identification _______________________ 11 3.2.a) Description détaillée des cas d’utilisation ______________________________________________ 12 3.2.b) Scénarii représentatifs de l’identification d’un utilisateur _________________________________ 13

3.3) La consultation des plannings et des informations employés _____________________ 15 3.3.a) Description détaillée des cas d’utilisation ______________________________________________ 16 3.3.b) Scénario représentatif de l’identification d’un utilisateur _________________________________ 17

3.4) La modification physique de données ________________________________________ 18 3.4.a) Gestion des plannings ______________________________________________________________ 19

3.4.a).i) Description détaillée des cas d’utilisation __________________________________________ 20 3.4.a).ii) Scénarii représentatifs de la gestion de plannings ___________________________________ 22 3.4.b) Gestion des informations des employés _______________________________________________ 24 3.4.b).i) Description détaillée des cas d’utilisation __________________________________________ 25 3.4.b).ii) Scénario représentatif de la gestion des informations ________________________________ 26 3.4.c) Gestion des lignes de production _____________________________________________________ 27 3.4.c).i) Description détaillée des cas d’utilisation __________________________________________ 28 3.4.c).ii) Scénario représentatif de la gestion des lignes de production__________________________ 29

4. Spécification des structures de données _____________________________________ 30

4.1) Modèle conceptuel de données _____________________________________________ 30 4.1.a) Contrat _________________________________________________________________________ 30 4.1.b) Employé ________________________________________________________________________ 31 4.1.c) Planning _________________________________________________________________________ 32 4.1.d) Ligne de production _______________________________________________________________ 33 4.2) Dictionnaire de données ___________________________________________________ 34

(4)

3 | P a g e 4.1.a) Contrat _________________________________________________________________________ 34 4.1.b) Employé ________________________________________________________________________ 35 4.1.c) Planning _________________________________________________________________________ 35 4.1.d) Ligne de production _______________________________________________________________ 36

4.3) Modèle logique relationnel normalisé ________________________________________ 37 4.1.a) Contrat _________________________________________________________________________ 37 4.1.b) Employé ________________________________________________________________________ 38 4.1.c) Planning _________________________________________________________________________ 39 4.1.d) Ligne de production _______________________________________________________________ 40

4.4) Modèle logique relationnel optimisé _________________________________________ 41 4.1.a) Contrat _________________________________________________________________________ 41 4.1.b) Employé ________________________________________________________________________ 42 4.1.c) Planning _________________________________________________________________________ 43 4.1.d) Ligne de production _______________________________________________________________ 44

4.5) Diagramme de classes _____________________________________________________ 45 4.5.a) Contrat _________________________________________________________________________ 45 4.5.b) Employé ________________________________________________________________________ 46 4.5.c) Planning _________________________________________________________________________ 47 4.5.d) Ligne de production _______________________________________________________________ 48

5. Spécification des interfaces externes _______________________________________ 49

5.1) Interface matériel-logiciel __________________________________________________ 49 5.1.a) Application locale seulement ________________________________________________________ 49 5.1.b) Application client – serveur _________________________________________________________ 50 5.2) Interface logiciel-logiciel ___________________________________________________ 50 5.3) Interface homme-logiciel __________________________________________________ 51 6. Les besoins en performance ______________________________________________ 52

6.1) Application locale ________________________________________________________ 52 6.2) Client – serveur __________________________________________________________ 53 7. Les contraintes de développement _________________________________________ 54 8. Références ____________________________________________________________ 59

(5)

4 | P a g e

1. Introduction

1.1) Buts de l’application

’entreprise ne possédant aucun outil simple et standardisé pour gérer ses effectifs, il s’agit de développer un outil, permettant la gestion des différentes fonctionnalités, relatives au personnel d’une entreprise et nécessaires au bon déroulement de l’activité industrielle.

Son rôle aura pour but aussi bien de concentrer les informations personnelles des salariés comme leurs préférences au niveau des équipes (matin, après-midi, nuit, week-end), leurs formations ou leurs aptitudes, par le biais d’une base de données, que de permettre leurs affectations à différents plannings.

Les plannings devront pouvoir contenir les différentes lignes de production du bâtiment de l’entreprise concerné et ainsi permettre d’associer un employé à un poste et à un horaire spécifique.

L’entreprise possédant plusieurs bâtiments et donc des structures industrielles différentes, il devra être possible à l’administrateur du système de créer ses propres lignes de production ainsi que d’affecter seulement les employés utilisés dans ce bâtiment.

1.2) Présentation générale du document

e document rappelle avant toute chose, le travail tel qu’il a été demandé par le commanditaire, ici l’entreprise Beaufour IPSEN Industrie basée à Dreux (28). Ce projet est réalisé en collaboration entre l’Université Technologique de Belfort – Montbéliard (U.T.B.M. (90)) et l’entreprise commanditaire. Il donne dans un premier temps une vision globale de l’application dans son environnement en identifiant les différents types d’utilisateurs du système.

La deuxième partie décrit les besoins du système en termes de fonctionnalités à assurer. Les différents cas d’utilisation sont étudiés.

La partie suivante précise les interfaces entre le matériel et l’homme / les logiciels.

Enfin, nous verrons les besoins en performance ainsi que les contraintes de développement définies.

L

C

(6)

5 | P a g e

1.3) Travail demandé

e travail demandé peut se décomposer en différentes parties principales :

Gestion des informations personnelles des salariés : un salarié doit pouvoir être créé, modifié, supprimé et on doit pouvoir consulter les différentes informations relatives à cette personne.

Gestion d’un planning : un planning comportant les différents salariés ainsi que les postes et les horaires qui leur sont associés devra pouvoir être mis en place et imprimé. Le planning sera mis à jour par semaine.

Gestion des demandes de contrat : les demandes de contrat pour les intérimaires doivent pouvoir être renseignées avec leur numéro de contrat ainsi que la description des tâches à effectuer. De plus, la personne soumise au contrat pourra subir une évaluation permettant de déterminer sa capabilité ; dans l’objectif de recourir ou non plus tard à cette même personne. Enfin, un suivi du contrat devra être mis en place suivant différents statuts :

o module de formation en cours o évaluation effectuée

o contrat en cours o contrat à faire o temps partiel

Gestion des congés des salariés : les demandes de congés devront être renseignées pour chaque salarié et devront être comptabilisées. Des récapitulatifs par mois devront être possibles. Les congés peuvent être de différentes formes :

o Absence partielle o Absence validée o RTT imposée o RTT secteur o Déplacement o Jour férié

Gestion des polyvalences des chefs d’équipe : les chefs d’équipe peuvent opérer sur différentes lignes. Une grille doit permettre leur repartitionnement par semaine suivant leurs compétences et les horaires choisis.

Gestion de la répartition des équipes : les salariés peuvent avoir des préférences quant au choix de leur horaire (matin, après-midi, nuit, week-end).

L

(7)

6 | P a g e

2. Description générale

2.1) Environnement et contexte du système

rès peu d’acteurs sont nécessaires pour interagir avec le système, nous avons seulement :

L’administrateur Les managers Les utilisateurs

L’utilisateur principal de notre système sera l’administrateur qui gère le système. Les managers n’auront comme possibilités que les droits accordés par l’administrateur lors de la création de leurs comptes. Les managers pourront transmettre des messages à l’administrateur par le biais de l’interface de gestion. Les utilisateurs n’auront aucun droit de modification ; ils pourront seulement consulter les informations des employés et les plannings.

T

(8)

7 | P a g e Evénement Acteurs Activité Réponse Destinataire Gestion des

comptes utilisateurs

Administrateur Création, modification, suppression de

comptes.

Gestion des droits.

Compte actualisé.

Système

Gestion des lignes de production

Administrateur Création, modification, suppression des

différentes lignes de production.

Ligne actualisée.

Système

Gestion des employés

Administrateur, Manager

Création, modification,

suppression d’employés ainsi que les informations

qui en découlent.

Employé actualisé.

Système

Gestion du planning

Administrateur, Manager

Mise en place du planning à

partir des employés présents dans la base de données

et des lignes créées.

Planning créé.

Système

Consultation des informations des employés

Administrateur, Manager, Utilisateur

Permet la consultation des

informations relatives aux employés.

Affichages des fiches personnell

es des employés.

Système

Consultation des plannings

Administrateur, Manager, Utilisateur

Permet la consultation des

différents plannings créés.

Affichage du planning demandé.

Système

Envoi de demandes d’autorisation

Manager Permet l’envoi de demandes à l’administrateur

L’admin reçoit une demande.

Administrateur

(9)

8 | P a g e

2.2) Caractéristiques des utilisateurs

e programme comporte différents types d’utilisateur et chacun de ces utilisateurs possède des droits différents et donc des possibilités plus ou moins restreintes.

Tout d’abord, le statut « utilisateur simple » est le statut possédant le plus de restriction. Ce statut permet la consultation des plannings déjà créés ainsi que celle des informations relatives aux employés. En aucun cas ce statut ne permet d’agir sur la modification des employés ni des plannings.

Ensuite, le statut de « manager » correspond aux comptes habilités par l’administrateur à effectuer des modifications d’ordre physique sur les données.

Suivant les droits accordés par l’administrateur, le manager peut effectuer des modifications sur les employés. Ces modifications peuvent être de l’ordre de la création, de la mise à jour ou de la suppression d’un employé. Le manager peut également créer un planning à partir des employés présents dans la base de données.

Lors de certaines actions, le manager pourrait être amené à demander une autorisation à l’administrateur ou le prévenir de la réalisation d’une tâche. Ces actions étant ensuite notifiées à l’administrateur lors de sa connexion. Evidemment, ce statut peut également effectuer les actions permises dans le cas d’un utilisateur simple.

Pour terminer, le statut d’ « administrateur » correspond au statut le plus important du programme, il permet de réaliser toutes les opérations permises au manager mais il peut également réaliser toutes les opérations permises par le programme. Il peut par exemple gérer les différents comptes en créant ou en modifiant les droits qui leur sont associés ou encore en les supprimant. L’administrateur peut également créer, modifier ou supprimer des lignes de production. Les lignes de production comportent des postes où seront associés des employés. L’administrateur pourra enfin gérer toutes les options demeurant possibles par l’application.

L

(10)

9 | P a g e

2.3) Contraintes de développement

e programme sera développé en JAVA. Ce langage permettant une bonne portabilité, ce qui est important pour l’entreprise qui, si elle opère une migration de sa plate-forme informatique, pourra toujours utiliser le programme.

De plus, le programme devra s’exécuter sur différents ordinateurs dans des bâtiments différents par ce fait, ce langage est intéressant et le logiciel pourra être exporté facilement. C’est un langage puissant, de haut niveau et orienté objet ce qui lui permet de gérer des applications plus sûres et plus stables.

Les données concernant les différents employés seront stockées dans des fichiers XML ou directement dans une base de données de type PostgreSQL. Utiliser le XML plutôt qu’une base de données est un choix compliqué car d’un côté le logiciel pourra être installé très facilement et la maintenance sera vraiment minime et par ce fait mettre en place une base de données de type SGDB serait plus compliqué. De plus, les données présentes dans les différentes licences n’auront rien en commun, donc centraliser les données dans un SGDB n’a pas vraiment d’intérêt. Cependant, d’un point de vue du développement la mise en place d’une SGDB de type PostgreSQL sera beaucoup plus propre et permettra plus facilement des évolutions du logiciel.

Le logiciel devra être dynamique et adaptable dans le sens qu’il sera utilisé dans différentes parties de l’entreprise. En effet, chaque partie de l’entreprise possède des lignes de production différentes il ne peut donc pas être question de créer un logiciel dont les lignes de production soient fixes. Il faut que l’administrateur puisse à l’ouverture du programme, créer des lignes suivant la configuration présente dans son bâtiment.

Les plannings devront pouvoir être archivés pour cela on pourra également utiliser des fichiers XML ou prévoir une table au niveau d’un SGDB. Ces plannings devront être imprimables pour pouvoir être affichés dans les bâtiments. Ils devront être organisés suivant les lignes de production et non par nom pour pouvoir être plus facilement identifié les différents éléments présents sur les lignes.

Le personnel devant utiliser le logiciel n’étant pas informaticien, il est plus que nécessaire que la plupart des opérations soient automatiques, et un grand nombre de notifications devront être apportées lors de l’exécution du programme.

Cependant, l’utilisateur (conformément à ses droits) devra toujours avoir la possibilité de forcer.

L

(11)

10 | P a g e

3. Besoins fonctionnels

3.1) Description générale

e diagramme suivant présente une vue générale des cas d’utilisations de notre système. Ce diagramme permet de dégager les grandes opérations qui seront possibles avec le système, c’est à dire l’identification, la consultation d’informations, ainsi que la création de données.

L

(12)

11 | P a g e

3.2) La gestion des comptes d’utilisateurs et de l’identification

eux grandes parties pour cette partie du système, l’inscription et la connexion ont chacun des héritiers similaires, qui dépendent du rôle : utilisateur simple, manager ou administrateur. La connexion se passe de la même manière pour ces différents utilisateurs.

Seul l’administrateur peut créer des comptes en fournissant un login, un mot de passe et des informations concernant les droits attribués.

Il peut y avoir un échange d’identifiant et de mot de passe entre l’utilisateur et l’administrateur (création de compte ou oubli de mot de passe par exemple).

D

(13)

12 | P a g e

3.2.a) Description détaillée des cas d’utilisation

Nom du cas S’identifier

Objectif Permettre la connexion à un utilisateur du système. Ce cas est souvent utilisé dans le système afin de vérifier les droits des utilisateurs avant une action quelconque

Acteur Tous les utilisateurs

Flot de données Login et mot de passe de l’utilisateur Pré Conditions Compte utilisateur créé

Post Conditions L’utilisateur est connecté au système

Exceptions Login et mot de passe incorrects, connexion refusée

Nom du cas Créer compte

Objectif Permettre à l’administrateur de créer différents comptes Acteur Administrateur

Flot de données Nouveau login et nouveau mot de passe Pré Conditions Administrateur connecté

Post Conditions Un compte utilisateur est créé Exceptions /

Nom du cas Attribuer droits

Objectif Permettre à l’administrateur de choisir les actions permises ou non à un utilisateur particulier

Acteur Administrateur Flot de données Restrictions imposées

Pré Conditions Compte en cours de création ou créé Post Conditions Droits de l’utilisateur modifiés Exceptions /

Nom du cas Demander mot de passe

Objectif Permettre la transmission de l’identifiant et du mot de passe directement par le système au titulaire d’un compte en cas de création de celui-ci ou d’oubli de ces informations

Acteur Système

Flot de données Login et mot de passe de l’utilisateur Pré Conditions Posséder un compte

Post Conditions L’utilisateur est en possession de ses identifiants Exceptions /

(14)

13 | P a g e

3.2.b) Scénarii représentatifs de l’identification d’un utilisateur

Un utilisateur doit, pour pouvoir se connecter au programme, fournir son login et son mot de passe. Dans le cas où ses identifiants sont acceptés, il accède à ses fonctionnalités. Il peut également demander un rappel de ses identifiants.

(15)

14 | P a g e Avant de pouvoir se connecter, l’utilisateur doit tout d’abord posséder un compte d’utilisateur. C’est l’administrateur du logiciel qui va permettre la création de ce compte. En donnant un login, un mot de passe et en choisissant les droits qui lui sont accordés, l’administrateur peut permettre à un utilisateur d’accéder à certaines fonctionnalités du programme.

(16)

15 | P a g e

3.3) La consultation des plannings et des informations employés

ette partie constitue les fonctionnalités les plus basiques de l’application et celles qui sont accessibles à tous. Elles correspondent à la possibilité de consulter un planning archivé préalablement ou les informations disponibles pour chaque employé enregistré. Il suffit donc pour cela que l’utilisateur choisisse dans une liste déroulante le nom d’un employé pour pouvoir accéder aux données. Il faut également qu’il choisisse un planning archivé pour pouvoir le consulter.

Dans tous les cas, bien que nous soyons en présence des fonctionnalités les plus simples, il demeure impératif de se connecter par le biais d’une identification à l’application. Ceci dans le but de protéger les données des employés qui restent quand même d’ordre personnel.

C

(17)

16 | P a g e

3.3.a) Description détaillée des cas d’utilisation

Nom du cas Afficher les informations

Objectif Permettre à un utilisateur de consulter les fiches d’informations des employés

Acteur Tous les utilisateurs

Flot de données Informations des employés Pré Conditions Employé déterminé

Post Conditions Fiche de l’employé affichée Exceptions /

Nom du cas Afficher un planning

Objectif Permettre à un utilisateur de consulter un planning préalablement archivé

Acteur Tous les utilisateurs Flot de données Planning concerné

Pré Conditions Planning archivé déterminé Post Conditions Planning affiché

Exceptions /

Nom du cas Choix d’un employé

Objectif Permettre par le biais d’une liste déroulant de déterminer un employé dans le but d’afficher ses informations

Acteur Tous les utilisateurs Flot de données Employé sélectionné

Pré Conditions Utilisateur connecté, employé créé Post Conditions Employé déterminé

Exceptions /

Nom du cas Choix d‘un planning

Objectif Permettre le choix d’un planning qui a été archivé précédemment Acteur Tous les utilisateurs

Flot de données Planning sélectionné

Pré Conditions Utilisateur connecté, planning archivé Post Conditions Planning déterminé

Exceptions /

(18)

17 | P a g e

3.3.b) Scénario représentatif de l’identification d’un utilisateur

(19)

18 | P a g e

3.4) La modification physique de données

a modification physique des données correspond à toutes les opérations permises par l’application permettant de modifier des données de manière physique. Cela peut correspondre par exemple à tout ce qui permet de gérer les plannings, les employés, les lignes de production ou encore les comptes utilisateur.

Nous verrons donc dans cette partie des diagrammes de cas d’utilisation pour la gestion des plannings, c'est-à-dire la création, la suppression ou la modification de plannings. Mais aussi pour la gestion des employés et de leurs informations. Enfin, nous verrons les diagrammes de cas d’utilisation pour la gestion des lignes de production.

Ces fonctionnalités ne sont plus d’ordre basique, elles ne sont accessibles que par des utilisateurs qualifiés d’avancé voir même parfois seul l’administrateur peut effectuer ces opérations.

L

(20)

19 | P a g e

3.4.a) Gestion des plannings

(21)

20 | P a g e 3.4.a).i) Description détaillée des cas d’utilisation

Nom du cas Gestion des plannings

Objectif Permettre de réaliser toutes les opérations nécessaires au bon déroulement de la mise en place de plannings

Acteur Utilisateur avancé Flot de données Message d’information

Pré Conditions Utilisateur connecté, actions et plannings déterminés Post Conditions Planning actualisé

Exceptions Utilisateur connecté ne possédant pas les droits, refus de toute opération

Nom du cas Créer un planning

Objectif Permettre la création de planning Acteur Utilisateur avancé

Flot de données Message de confirmation de création

Pré Conditions Choix d’une date, choix des éléments à insérer Post Conditions Planning créé

Exceptions Choix des éléments incompatibles, message d’erreur. Utilisateur connecté ne possédant pas les droits, refus de l’opération

Nom du cas Modifier un planning

Objectif Permettre de modifier un planning préalablement créé et archivé Acteur Utilisateur avancé

Flot de données Message de confirmation de modification Pré Conditions Choix d’un planning

Post Conditions Planning modifié

Exceptions Mauvaise modification, message d’erreur. Utilisateur connecté ne possédant pas les droits, refus de l’opération

Nom du cas Supprimer un planning

Objectif Permettre de supprimer un planning préalablement créé et archivé Acteur Utilisateur avancé

Flot de données Message de confirmation de suppression Pré Conditions Choix d’un planning

Post Conditions Planning supprimé

Exceptions Utilisateur connecté ne possédant pas les droits, refus de l’opération

(22)

21 | P a g e Nom du cas Choix d’une date

Objectif Permettre de déterminer une date à partir de laquelle on va créer un planning

Acteur Utilisateur avancé Flot de données Date

Pré Conditions Consulter calendrier Post Conditions Date déterminée

Exceptions Date déjà utilisée pour un planning archivé, message d’erreur

Nom du cas Choix d’un élément à insérer

Objectif Permettre d’insérer un élément dans un planning donné Acteur Utilisateur avancé

Flot de données Elément d’insertion

Pré Conditions Choix d’un employé, choix du poste à intégrer Post Conditions Elément à insérer déterminé

Exceptions Elément déjà présent sur le planning, mauvaise utilisation des alternances d’équipe, formation dépassée, message d’erreur

Nom du cas Consulter calendrier

Objectif Permettre la consultation du calendrier pour choisir une date où élaborer un planning

Acteur Utilisateur avancé Flot de données Calendrier

Pré Conditions Utilisateur connecté en mode avancé Post Conditions Calendrier affiché

Nom du cas Choix de l’employé

Objectif Permettre de choisir un employé à insérer dans le planning Acteur Utilisateur avancé

Flot de données Employé

Pré Conditions Employé créé, utilisateur connecté en mode avancé Post Conditions Employé sélectionné

(23)

22 | P a g e Nom du cas Choix du poste

Objectif Permettre de choisir un poste où sera affecté un employé Acteur Utilisateur avancé

Flot de données Message de confirmation de choix de poste Pré Conditions Poste créé, utilisateur connecté en mode avancé Post Conditions Poste sélectionné

Nom du cas Choix d‘un planning

Objectif Permettre le choix d’un planning qui a été archivé précédemment Acteur Utilisateur avancé

Flot de données Planning sélectionné

Pré Conditions Utilisateur connecté, planning archivé Post Conditions Planning déterminé

3.4.a).ii) Scénarii représentatifs de la gestion de plannings

(24)

23 | P a g e

(25)

24 | P a g e

3.4.b) Gestion des informations des employés

(26)

25 | P a g e 3.4.b).i) Description détaillée des cas d’utilisation

Nom du cas Gestion des informations des employés

Objectif Permettre de réaliser toutes les opérations nécessaires au bon déroulement de l’enregistrement des employés

Acteur Utilisateur avancé Flot de données Message d’information

Pré Conditions Utilisateur connecté, actions et employés déterminés Post Conditions Employé actualisé

Nom du cas Créer un employé

Objectif Permettre la création d’un employé Acteur Utilisateur avancé

Flot de données Message de confirmation de création Pré Conditions Choix des informations initiales à intégrer Post Conditions Employé créé

Nom du cas Modifier un employé

Objectif Permettre la mise à jour d’un employé Acteur Utilisateur avancé

Flot de données Message de confirmation de modification Pré Conditions Choix d’un employé

Post Conditions Employé modifié

Nom du cas Supprimer un employé

Objectif Permettre la suppression d’un employé Acteur Utilisateur avancé

Flot de données Message de confirmation de suppression Pré Conditions Choix d’un employé

Post Conditions Employé supprimé

(27)

26 | P a g e Nom du cas Choix des informations initiales

Objectif Remplir les informations personnelles d’un employé, postes formés, informations diverses

Acteur Utilisateur avancé Flot de données Formulaire rempli

Pré Conditions Utilisateur connecté en mode avancé Post Conditions Informations initiales déterminées

Nom du cas Choix d’un employé

Objectif Permettre le choix d’un employé créé préalablement Acteur Utilisateur avancé

Flot de données Employé sélectionné

Pré Conditions Employé créé, utilisateur connecté en mode avancé Post Conditions Employé déterminé

3.4.b).ii) Scénario représentatif de la gestion des informations

(28)

27 | P a g e

3.4.c) Gestion des lignes de production

(29)

28 | P a g e 3.4.c).i) Description détaillée des cas d’utilisation

Nom du cas Gestion des lignes de production

Objectif Permettre de réaliser toutes les opérations nécessaires au bon déroulement de l’enregistrement des lignes de production Acteur Administrateur

Flot de données Message d’information

Pré Conditions Administrateur connecté, actions et lignes déterminées Post Conditions Ligne actualisée

Nom du cas Créer une ligne

Objectif Permettre la création d’une ligne de production Acteur Administrateur

Flot de données Message de confirmation de création Pré Conditions Choix des informations initiales à intégrer Post Conditions Ligne de production créée

Nom du cas Modifier une ligne

Objectif Permettre la modification d’une ligne de production Acteur Administrateur

Flot de données Message de confirmation de modification Pré Conditions Choix d’une ligne de production

Post Conditions Ligne de production modifiée

Nom du cas Supprimer une ligne

Objectif Permettre la suppression d’une ligne de production Acteur Administrateur

Flot de données Message de confirmation de suppression Pré Conditions Choix d’une ligne de production

Post Conditions Ligne de production supprimée

(30)

29 | P a g e Nom du cas Choix des informations initiales

Objectif Remplir les informations nécessaires au bon fonctionnement de la ligne, nombre de postes, détermination des postes, nom de la ligne…

Acteur Administrateur Flot de données Formulaire rempli

Pré Conditions Utilisateur connecté en mode administrateur Post Conditions Informations initiales déterminées

Nom du cas Choix d’une ligne de production

Objectif Permettre le choix d’une ligne de production créée préalablement Acteur Administrateur

Flot de données Ligne de production sélectionnée

Pré Conditions Ligne de production créée, utilisateur connecté en mode administrateur

Post Conditions Ligne de production déterminée

3.4.c).ii) Scénario représentatif de la gestion des lignes de production

(31)

30 | P a g e

4. Spécification des structures de données

4.1) Modèle conceptuel de données

4.1.a) Contrat

(32)

31 | P a g e

4.1.b) Employé

e sous-modèle comprend une contrainte d’unicité (CIF). Elle permet de préciser l’identifiant de l’association « have for ». L’entité cible est l’entité « Function ».

La contrainte d’unicité permet de représenter le fait qu’une personne à une date donnée ne peut occuper qu’une et une seule fonction. Sans la contrainte une personne pourrait occuper plusieurs fonctions différentes à une date donnée.

C

(33)

32 | P a g e

4.1.c) Planning

e même que le sous-modèle précédent, le sous-modèle ci-dessous contient une contrainte d’unicité. L’entité cible étant l’entité « Shift », la contrainte permet de représenter le fait qu’une personne à une semaine donnée ne peut préférer qu’une et une seule équipe.

D

(34)

33 | P a g e

4.1.d) Ligne de production

ne contrainte d’unicité est également utilisée dans le dernier sous-modèle.

L’entité cible est l’entité « Employé ». La contrainte permet de représenter le fait qu’une ligne de production à une semaine donnée ne peut être gérer par un et un seul manager.

U

(35)

34 | P a g e

4.2) Dictionnaire de données

4.1.a) Contrat

Nom informatique Description Type Dimension Calculé

numEmployee Numéro employé AN 10 N

titleEmployee Titre employé AN 32 N

lastNameEmployee Nom employé AN 32 N

firstNameEmployee Prénom employé AN 32 N

dateBirthEmployee Date de naissance employé D 8 N

adressEmployee Adresse employé AN 197 N

streetEmployee Rue employé AN 128 N

cityEmployee Ville employé AN 32 N

postalEmployee Code postal employé N 5 N

countryEmployee Pays employé AN 32 N

phoneEmployee Téléphone employé AN 32 N

mobileEmployee Portable employé AN 32 N

mailEmployee Email employé AN 128 N

dateEntranceEmployee Date d’entrée employé D 8 N socialNumberEmployee Numéro de sécurité sociale

employé

N 30 N

nationalityEmployee Nationalité employé AN 32 N

photoEmployee Photo employé AN 32 N

payEmployee Paie employé N 10 N

objectiveEmployee Objectif employé AN 128 N

noteEmployee Commentaire employé AN 128 N

numBatEmployee Numéro de bâtiment employé

N 2 N

loginEmployee Login employé AN 32 N

passwordEmployee Mot de passe employé AN 32 N

dateCreationEmployee Date de création employé D 32 N dateLastConnectionEmployee Date de dernière

connexion employé

D 32 N

numContract Numéro contrat AN 10 N

typeContract Type contrat (CDI, CDD, …) AN 32 N

descriptionContract Libellé contrat AN 128 N

dateBeginContract Date début contrat D 8 N

dateEndContract Date fin contrat D 8 N

numEvaluation Numéro évaluation AN 10 N

descriptionEvaluation Libellé évaluation AN 128 N

numApplication Numéro application AN 10 N

descriptionApplication Libellé application AN 128 N

(36)

35 | P a g e

4.1.b) Employé

numFunction Numéro fonction AN 10 N

descriptionFunction Libellé fonction AN 128 N

dateFunction Date de la prise de fonction

D 8 N

numPosition Numéro poste AN 10 N

descriptionPosition Libellé poste AN 128 N

durationBeforeTrainingPosition Durée avant formation sur le poste

N 3 N

numTraining Numéro formation AN 10 N

dateBeginTraining Date de début formation D 8 N

durationTraining Durée de formation N 3 N

dateEndTraining Date de fin formation D 8 O

nbHoursTraining Nombre d’heures de formation

N 3 N

nameTrainerTraining Nom du formateur AN 32 N

numTypeLeave Numéro type congé AN 10 N

descriptionTypeLeave Libellé type congé (RTT, maladie, …)

AN 128 N

numLeave Numéro de congé AN 10 N

dateBeginLeave Date de début congé D 8 N

durationLeave Durée du congé N 3 N

dateEndLeave Date de fin congé D 8 O

4.1.c) Planning

numShift Numéro équipe AN 10 N

descriptionShift Libellé équipe AN 128 N

scheduleShift Horaire d’équipe AN 32 N

numYearWeek Numéro de semaine

combiné avec l’année

N 6 N

(37)

36 | P a g e

4.1.d) Ligne de production

Nom informatique Description Type Dimension Calculé numLineProduction Numéro ligne de

production

AN 10 N

nameLineProduction Nom de la ligne de production

AN 32 N

nbMachinesLineProduction Nombre de machines pour une ligne de production

N 2 N

nbEmployeesLineProduction Nombre d’employées pour une ligne de production

N 2 N

Type Légende

AN Caractère Alphanumérique N Caractère Numérique D Date

Calculé Légende

O Oui (champs calculé) N Non (champs non calculé)

(38)

37 | P a g e

4.3) Modèle logique relationnel normalisé

4.1.a) Contrat

(39)

38 | P a g e

4.1.b) Employé

(40)

39 | P a g e

4.1.c) Planning

(41)

40 | P a g e

4.1.d) Ligne de production

(42)

41 | P a g e

4.4) Modèle logique relationnel optimisé

4.1.a) Contrat

(43)

42 | P a g e

4.1.b) Employé

e sous-modèle a été optimisé en supprimant la table « Date » qui ne comporte qu’une clé primaire « DATEFUNCTION » ; et en conséquence l’index primaire associé est supprimé.

C

(44)

43 | P a g e

4.1.c) Planning

e sous-modèle a été optimisé en supprimant la table « Week » qui ne comporte qu’une clé primaire « NUMYEAR_WEEK » ; et en conséquence l’index primaire associé est supprimé.

C

(45)

44 | P a g e

4.1.d) Ligne de production

e sous-modèle contenant également la table « Week », l’optimisation précédente peut se voir ici aussi.

C

(46)

45 | P a g e

4.5) Diagramme de classes

4.5.a) Contrat

(47)

46 | P a g e

4.5.b) Employé

(48)

47 | P a g e

4.5.c) Planning

(49)

48 | P a g e

4.5.d) Ligne de production

(50)

49 | P a g e

5. Spécification des interfaces externes

5.1) Interface matériel-logiciel

e projet est basé sur une application simple développée en Java et qui se connecte à une base de données de type PostgreSQL par le biais du framework Hibernate.

L’application peut être utilisée de deux manières. Tout dépend comment l’entreprise souhaite l’utiliser. Par défaut l’application est configurée pour une utilisation locale (déterminé par l’entreprise Beaufour IPSEN Industrie) mais peut tout aussi bien être reconfigurée pour être utilisée à la manière d’un client – serveur. Pour cela, il suffit juste de modifier l’URL de connexion à la base de données.

Il suffit de modifier la ligne du fichier XML « hibernate.cfg.xml » suivante, en changeant « localhost » par l’adresse IP du serveur où sera installée la base de données :

<property

name="hibernate.connection.url">jdbc:postgresql://localhost/ipsen</property>

5.1.a) Application locale seulement

Pour utiliser l’application en version locale, il est nécessaire d’installer l’application en elle-même ainsi que le SGDB (PostgreSQL) sur le même poste.

Une configuration de type PC équipée de, Windows XP (ou version supérieure) ou bien Unix, nécessaire pour l’utilisation de la base de données PostgreSQL 8.2, d’un processeur cadencé à 1.5 Ghz, de 512 Mo de RAM et d’une capacité de stockage de 5 Go semble un minimum pour le bon déroulement de l’application. Il faut également que le poste possède sa propre machine virtuelle Java pour pouvoir faire tourner l’application Java.

L

(51)

50 | P a g e

5.1.b) Application client – serveur

a partie serveur du logiciel nécessite l’installation du SGBD (PostgreSQL 8.2 pour Windows XP (ou version supérieure) ou bien Unix) et doit permettre la gestion de plusieurs dizaines d’utilisateurs cibles connectés simultanément dans l’objectif que l’application soit accessible à plusieurs managers de l’entreprise.

Une configuration de type PC équipée de Windows XP, d’un processeur cadencé à 1.5 Ghz, de 512 Mo de RAM et d’une capacité de stockage de 30 Go semble un minimum.

Coté client, un client léger de type PC, MAC ou Linux peut être utilisé indifféremment. Il faut juste que le client possède sa propre machine virtuelle Java pour pouvoir faire tourner l’application Java.

5.2) Interface logiciel-logiciel

Côté Serveur :

Un système d’exploitation de type Windows Server ou Unix pour le support du serveur PostgreSQL.

Une base de données basée sur le SGBD PostgreSQL, destinée à hiérarchiser toutes les données relatives aux différents utilisateurs du système, ainsi que les données nécessaires pour avoir une application effective.

Côté Client :

Un système d’exploitation de type Windows, Mac ou Unix.

Une machine virtuelle Java.

L

(52)

51 | P a g e

5.3) Interface homme-logiciel

Maquette page d’accueil du logiciel

Maquette mode principal planning Menu d’accès rapide

Calendrier

Toolbar

Planning

Menu d’accès rapide

(53)

52 | P a g e

6. Les besoins en performance

uivant la façon dont l’utilisateur utilise son application, les besoins en performance peuvent être nuancés. En effet, les besoins ne seront pas les mêmes dans le cadre d’une application locale que pour un client – serveur de base.

6.1) Application locale

Le programme ne manipule pas de fichiers ou très peu, il se sert uniquement d’une base de données d’accès local dont il est le seul à avoir l’accès. Le fait qu’il soit le seul à manipuler les données et qu’il ait accès directement à partir de son poste assure une plus grande fluidité de l’application et les opérations sont également traitées plus rapidement.

Vu que les ressources demandées par la base de données ne sont pas nécessaires à d’autres postes, il n’est pas nécessaire de mettre en place d’autres outils pour améliorer la performance du système. Le seul problème est que du même coup le client va prendre en charge le traitement des données de la base tandis que d’habitude c’est le serveur qui s’en occupe, on a donc une perte de performance dans ce cas là.

S

(54)

53 | P a g e

6.2) Client – serveur

n peut estimer que le nombre de terminaux connectés simultanément est illimité. En effet, le programme est une application permettant de gérer les effectifs mais de manière discontinue. En effet, chaque application ne sera pas en même temps en train de traiter des données, ce qui implique que la consommation de ressources sur le serveur n’est pas continue.

Dans ce cas la mise en place de certains index, en particulier pour la table

« employé », sera réellement nécessaire car chaque bâtiment pouvant compter plusieurs dizaines voir centaines d’employés, certaines tables de la base de données deviendront trop imposantes et il faudra donc améliorer la rapidité des recherches dans ces tables. La solution à moindre coût et la plus simple par défaut réside dans la mise en place de ces index.

O

(55)

54 | P a g e

7. Les contraintes de développement

out d’abord, chaque employé pourra déterminer ses préférences en matière d’horaires de travail. Il pourra choisir s’il préfère travailler en journée, de matin, d’après midi ou de nuit. Il pourra également choisir s’il souhaite ces horaires toute l’année, seulement quelques mois ou quelques semaines (semaines paires et impaires).

Après, à partir de ça, ces préférences seront enregistrées dans la base de données et l’application devra prévenir l’utilisateur lors de l’établissement d’un planning si les contraintes ne sont pas respectées. Néanmoins l’utilisateur pourra forcer la demande pour ne pas rester bloquer sur une incompatibilité.

T

(56)

55 | P a g e Ensuite, toujours au niveau des employés le statut de chef d’équipe devra être particulier. L’utilisateur de l’application devra pouvoir mettre en place une grille de polyvalence des chefs d’équipe. Car ils sont susceptibles de changer de ligne de production en cours de l’année.

(57)

56 | P a g e L’utilisateur devra également pouvoir gérer des demandes de contrat de type intérimaire. Il devra pouvoir rentrer le numéro de commande ainsi que la durée du contrat pour chacune des personnes. Ensuite il devra pouvoir spécifier si le contrat est en cours, à faire, si le module de formation a été démarré ou encore si l’évaluation (satisfaisant, bon, ne pas reprendre, …) de la personne a été effectuée.

(58)

57 | P a g e Pour finir, l’utilisateur devra pouvoir gérer les congés (absence partielle, absence validée, RTT imposé, RTT secteur, déplacement, jour férié, …).

(59)

58 | P a g e Enfin, le planning devra pouvoir regrouper tout ça, et son affichage devra se faire avec pour entête de colonne les noms de ligne de production.

(60)

59 | P a g e

8. Références

Programmer en Java, Claude Delannoy, Editions Eyrolles

UML 2 Initiation, exemples et exercices corrigés, Laurent Debrauwer et Fien Van der Heyde, Eni Editions

UML 2 en action : De l’analyse des besoins à la conception, Pascal Rogues, Editions Eyrolles

Hibernate 3.0, Gestion optimale de la persistance dans les applications Java/J2EE, Anthony Patricio, Editions Eyrolles

Design patterns : Tête la première, Eric Freeman, O’reilly

Bases fondamentales de la programmation objet, Jean-Charles Créput, Université Technologique de Belfort – Montbéliard

Génie logiciel, Abderrafìâa Koukam, Université Technologique de Belfort – Montbéliard

Conception de bases de données, Christian Fischer, Université Technologique de Belfort – Montbéliard

Documents techniques transmis par les managers de l’entreprise Beaufour IPSEN Industrie, Dreux, France (28)

http://www.hibernate.org/hib_docs/reference/fr/html/ : documentation de référence pour Hibernate

http://www.developpez.com/ : site d’entraide de développeurs

http://www.bourzeix.com/weblog/post/2005/05/21/121-netbeans-tomcat-

struts-et-hibernate : site d’apprentissage pour Netbeans, Tomcat, Struts et Hibernate

http://docs.postgresqlfr.org/ : documentation pour PostgreSQL 8.2