Automne 2007 Dossier de spécification Gestion des effectifs : Beaufour IPSEN Industrie TW52 Matthieu LEROMAIN GI05 Ömer MADEN GI05 Tuteur de stage : J.C. Gavoille Suiveur de la TW52 : A. Koukam Automne 2007 0 Page
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. 1 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 2 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 3 P a g e
1. Introduction L 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. C 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. 4 P a g e
L 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). 5 P a g e
2. Description générale T 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. 6 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 7 P a g e
2.2) Caractéristiques des utilisateurs L 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. 8 P a g e
2.3) Contraintes de développement L 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. 9 P a g e
3. Besoins fonctionnels 3.1) Description générale L 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. 10 P a g e
3.2) La gestion des comptes d utilisateurs et de l identification D 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). 11 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 / 12 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. 13 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. 14 P a g e
3.3) La consultation des plannings et des informations employés C 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. 15 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 / 16 P a g e
3.3.b) Scénario représentatif de l identification d un utilisateur 17 P a g e
3.4) La modification physique de données L 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. 18 P a g e
3.4.a) Gestion des plannings 19 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 20 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é Exceptions Utilisateur connecté ne possédant pas les droits, refus de l opération 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é Exceptions Utilisateur connecté ne possédant pas les droits, refus de l opération 21 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é Exceptions Utilisateur connecté ne possédant pas les droits, refus de l opération 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é Exceptions Utilisateur connecté ne possédant pas les droits, refus de l opération 3.4.a).ii) Scénarii représentatifs de la gestion de plannings 22 P a g e
23 P a g e
3.4.b) Gestion des informations des employés 24 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é Exceptions Utilisateur connecté ne possédant pas les droits, refus de toute opération 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éé Exceptions Utilisateur connecté ne possédant pas les droits, refus de l opération 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é Exceptions Utilisateur connecté ne possédant pas les droits, refus de l opération 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é Exceptions Utilisateur connecté ne possédant pas les droits, refus de l opération 25 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 Exceptions Utilisateur connecté ne possédant pas les droits, refus de l opération 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é Exceptions Utilisateur connecté ne possédant pas les droits, refus de l opération 3.4.b).ii) Scénario représentatif de la gestion des informations 26 P a g e
3.4.c) Gestion des lignes de production 27 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 Exceptions Utilisateur connecté ne possédant pas les droits, refus de toute opération 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 Exceptions Utilisateur connecté ne possédant pas les droits, refus de l opération 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 Exceptions Utilisateur connecté ne possédant pas les droits, refus de l opération 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 Exceptions Utilisateur connecté ne possédant pas les droits, refus de l opération 28 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 Exceptions Utilisateur connecté ne possédant pas les droits, refus de l opération 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 Exceptions Utilisateur connecté ne possédant pas les droits, refus de l opération 3.4.c).ii) Scénario représentatif de la gestion des lignes de production 29 P a g e
4. Spécification des structures de données 4.1) Modèle conceptuel de données 4.1.a) Contrat 30 P a g e
4.1.b) Employé C 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. 31 P a g e
4.1.c) Planning D 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. 32 P a g e
4.1.d) Ligne de production U 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. 33 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 N 30 N employé 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 N 2 N employé 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 D 32 N connexion employé 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 34 P a g e
4.1.b) Employé Nom informatique Description Type Dimension Calculé numfunction Numéro fonction AN 10 N descriptionfunction Libellé fonction AN 128 N datefunction Date de la prise de D 8 N fonction numposition Numéro poste AN 10 N descriptionposition Libellé poste AN 128 N durationbeforetrainingposition Durée avant formation N 3 N sur le poste 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 N 3 N formation nametrainertraining Nom du formateur AN 32 N numtypeleave Numéro type congé AN 10 N descriptiontypeleave Libellé type congé (RTT, AN 128 N maladie, ) 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 Nom informatique Description Type Dimension Calculé 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 35 P a g e
4.1.d) Ligne de production Nom informatique Description Type Dimension Calculé numlineproduction Numéro ligne de AN 10 N production namelineproduction Nom de la ligne de AN 32 N production nbmachineslineproduction Nombre de machines N 2 N pour une ligne de production 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é) 36 P a g e
4.3) Modèle logique relationnel normalisé 4.1.a) Contrat 37 P a g e
4.1.b) Employé 38 P a g e
4.1.c) Planning 39 P a g e
4.1.d) Ligne de production 40 P a g e
4.4) Modèle logique relationnel optimisé 4.1.a) Contrat 41 P a g e
4.1.b) Employé C 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é. 42 P a g e
4.1.c) Planning C 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é. 43 P a g e
4.1.d) Ligne de production e sous-modèle contenant également la table «Week», l optimisation précédente Cpeut se voir ici aussi. 44 P a g e
4.5) Diagramme de classes 4.5.a) Contrat 45 P a g e
4.5.b) Employé 46 P a g e
4.5.c) Planning 47 P a g e
4.5.d) Ligne de production 48 P a g e
5. Spécification des interfaces externes 5.1) Interface matériel-logiciel L 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. 49 P a g e
5.1.b) Application client serveur L 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. 50 P a g e
5.3) Interface homme-logiciel Toolbar Calendrier Menu d accès rapide Maquette page d accueil du logiciel Planning Maquette mode principal planning 51 P a g e
6. Les besoins en performance S 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à. 52 P a g e
O 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. 53 P a g e
7. Les contraintes de développement T 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é. 54 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. 55 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. 56 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é, ). 57 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. 58 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-tomcatstruts-et-hibernate : site d apprentissage pour Netbeans, Tomcat, Struts et Hibernate http://docs.postgresqlfr.org/ : documentation pour PostgreSQL 8.2 59 P a g e