Projet personnel encadré

LYCÉE DE LA CCI Projet personnel encadré BTS SIO SLAM BESSET Maylis 2014/2015

TABLE DES MATIÈRES I. Contexte... 5 1. Définition du projet... 5 2. Objectifs du projet... 6 3. Contraintes de temps... 6 4. Contraintes matérielles... 6 5. Contraintes techniques... 6 II. Analyse du besoin... 7 6. Besoins fonctionnels... 7 7. Orientation... 7 8. Schéma de la structure applicative... 7 III. Solutions proposées... 8 9. Liste des fonctionnalités de l'application par acteur... 8 10. Fonctionnalités générales... 9 11. Description fonctionnelle des phases individuelles... 9 IV. Mise en oeuvre du projet... 11 12. Planning... 11 13. Ressources... 11 Ressource matérielles... 11 Ressources humaines... 11 Ressources logicielles... 11 14. Règles de gestion génerales... 11 Membres du personnel... 11 Utilisateur... 12 Technicien :... 12 Intervention... 12 Materiel... 12 MaterielAchat... 12 MaterielLocation... 12 Phase de travail... 13 Niveau technicien :... 13 15. Règles inclusion... 13 V. Réalisation... 13 2

16. Triggers (Declencheurs)... 13 Les triggers généraux... 13 Les triggers des phases individuelles... 16 17. Procédures stockées... 16 Les procédures pour les phases communes... 16 Les procédures pour les phases individuelles... 18 18. Vues... 19 Vue entre les tables personnel technicien... 19 Vue entre les tables personnel - utilisateur... 19 Le code... 19 Vue entre les tables matériel - achat... 20 Vue entre les tables matériel - location... 20 Le code... 20 19. Méthodes complémentaires en PHP... 21 20. tableau des méthodes... 22 VI. Dossier d'analyse... 25 21. Modèle conceptuel de données... 25 22. Diagramme de classes... 26 Ddictionnaire de données... 26 Table PERSONNEL... 26 Table TECHNICIEN... 27 Table UTILISATEUR... 27 Table NIVEAUTECHNICIEN... 27 Table MATERIEl... 28 Table INTERVENTION... 28 Table PhaseTravail... 28 VII. Développement du projet... 29 23. Normalisation de la charte graphique... 29 24. Normalisation de la base de données... 29 VIII. Gestion de projet... 29 25. Mise en oeuvre... 29 26. Repartition des taches... 30 IX. Bilan du projet... 31 27. Problèmes TEChniques... 31 3

28. Problèmes organisationnels... 31 29. Bilan fonctionnel... 31 X. Conclusion... 32 XI. Descriptif de la situation professionnelle... 33 4

CAHIER DES CHARGES DU PPE 3 CONTEXTE DÉFINITION DU PROJET Ce premier projet personnel encadré en deuxième année de BTS SIO doit nous permettre d'aborder les phases de développement suivant : - Analyse du cahier des charges d'un service à produire. - Détermination des tests nécessaires à la validation d'un service. - Définition des niveaux d'habilitation associés à un service. - Test d'intégration et d'acceptation d'un service. - Accompagnement de la mise en place d'un nouveau service. - Participation à un projet. - Proposition d'une solution applicative. - Etude de propositions de contrat de service (client, fournisseur). - Conception ou adaptation d'une base de données. - Gestion d environnements de développement et de test. - Réalisation des tests nécessaires à la validation d éléments adaptés ou développés. Notre groupe s'est composé selon les affinités l'équipe est constituée de quatre personnes : LAMBERT Jean-Baptiste : projet 2 Gestion des activités des visiteurs médicaux. GUALMINI Cédric : projet 2 Gestion des activités des visiteurs médicaux. PINOL Mathieu : projet 1 Gestion du parc informatique et de l'assistance. BESSET Maylis : projet 1 Gestion du parc informatique et de l'assistance. Le laboratoire Galaxy Swiss Bourdin, issu de la fusion des entreprises pharmaceutiques Galaxy et Swiss Bourdin souhaite optimiser son nouveau groupe afin d assurer l épanouissement de son activité. On souhaite mettre à disposition du personnel une application Web répartie visant à permettre une gestion des futures activités des visiteurs médicaux. 5

OBJECTIFS DU PROJET L objectif est d élaborer une application Web qui sera dans un premier temps sous la forme d un Web service. L application finale doit être accessible depuis des terminaux mobiles (tablettes et Smartphones) ainsi que des ordinateurs classiques et destinée à la gestion des activités des visiteurs médicaux et du personnel du laboratoire. CONTRAINTES CONTRAINTES DE TEMPS Le projet devait être mis en ligne sur le client FTP Filezilla le 1 décembre dernier délai afin que le projet soit en production lors sa présentation orale. CONTRAINTES MATÉRIELLES Concernant le développement de l application, le cahier des charges nous imposer d utiliser le langage PHP et une base de données SQL. CONTRAINTES TECHNIQUES L application doit être accessible depuis un navigateur web (Chrome, Mozilla, IE). L application doit proposer un grand nombre de méthodes et tenir compte des besoins présents et de ceux à venir. Les normes et règles de développement doivent être respectées, le nom des méthodes doit être le plus explicite possible afin qu elle soit facilement utilisable pour les futurs développeurs (notation Camel), un tableau documenté doit également être mis a leur disposition. Un moyen d authentification devra être mis en œuvre afin de permettre à un utilisateur de s authentifier dès l ouverture de l application, cette authentification se fera par une connexion http. L utilisateur doit avoir la possibilité de valider son login et son mot de passe de manière à ce que l'application se connecte à partir d une connexion IP. L application doit comportée un tableau dynamique répertoriant les méthodes exposées par le web service, ce tableau est destiné aux autres développeurs. 6

ANALYSE DU BESOIN BESOINS FONCTIONNELS L'application doit prendre en charge le parc informatique de la société ainsi que les demandes des utilisateurs (prise en charge de panne, demande concernant le matériel) et ce avec le plus de précision afin de limiter les interrogations des clients. ORIENTATION L'application doit être accessible par les différents membres du personnel, elle sera donc développée en PHP avec une base de données élaboré sur SQL Server. Se mise en ligne sur Internet facilitera son accès pour tous les utilisateurs travaillant pour le laboratoire. SCHÉMA DE LA STRUCTURE APPLICATIVE 7

SOLUTIONS PROPOSÉES LISTE DES FONCTIONNALITÉS DE L'APPLICATION PAR ACTEUR Liste des acteurs : - Les utilisateurs - Les techniciens - Les visiteurs - Les responsables du service technique Les utilisateurs : - Accède à l'application. - Emet une demande et renseigne le matériel concerné, l'objet, le niveau d'urgence. - Donne ses coordonnées. - Possibilité de suivre le traitement de l'intervention. Les techniciens : - Donne ses coordonnées renseigne sur leur niveau, leur compétences et leur formation. - Accède à l'application et gère les demandes qui lui sont associés (soit par téléphone, sur site ou par télémaintenance) après s'être authentifié. - Affecte la demande à un ticket d'incident. - Se renseigne sur les matériels disponibles. - Donne des informations sur ses phases de travail. Les visiteurs : - Donne ses coordonnées renseigne sur son objectif, ses avantages, sa prime et son budget. - Accède à l'application et gère les demandes qui lui sont associés après s'être authentifié. Les responsables du service technique : - Accède à l'application après s'être authentifié. - Enregistre les information liées à ses demandes (état de la demande, date de début,...). 8

FONCTIONNALITÉS GÉNÉRALES Page index avec un tableau dynamique qui affiche les méthodes de gestion. Une sécurisation de l'application établit grâce à une fonction permettant de valider l'identification de l'utilisateur. Disposer d'une cellule chargée de prendre en charge les demandes d'assistance. DESCRIPTION FONCTIONNELLE DES PHASES INDIVIDUELLES Fonction : Création des demandes d'intervention (utilisateur) Objectif : Etablir un système de gestion simple des demandes d'interventions pour les membres du personnel. Description : L'application doit permettre à chaque membre du personnel d'effectuer un rendu de ses intervention (nouvelle intervention, modifier une intervention,...). Contraintes/règles de gestion : Chaque demande d'intervention est enregistrée sur un ticket d incident. Chaque demande est émise par un unique utilisateur qui doit renseigner sur le matériel concerné, l'objet et le niveau d'urgence, la demande est automatiquement horodatée. Chaque demande porte sur un seul matériel, le responsable technique indique l état (Enregistré (par défaut), En cours de traitement, Résolue, Clôturée) et le type de prise en charge (téléphone, télémaintenance, sur site). Le matériel est soit loué soit acheté auprès d'un fournisseur. Lorsque la demande est en cours de traitement il faut enregistrer les phases de travail du technicien (dates, heures, travail réalisé). Tous les membres du personnel possèdent une identité ainsi qu un matricule qui dépend du nom, du prénom et de l identifiant de la personne. La date d embauche et les régions dans lesquelles le salarié a été embauché doivent être mentionnées. Les techniciens possèdent un niveau d intervention et des compétences et ils ont reçu une formation. chacun ayant des caractéristiques spécifiques. Un technicien de premier niveau n'est affecté qu'aux demandes de premier niveau. Un utilisateur ne peut accéder qu'à ses propres demandes. 9

Fonction : Traitement et clôture des interventions (technicien + responsable technique) Objectif : Créer un système capable de clôturer chaque intervention une fois sont traitement terminé. Description : Un membre du personnel renseigne le niveau de traitement de son intervention et peut la modifier en utilisant les méthodes du WebService. Contraintes/règles de gestion : Lorsque la demande est en cours de traitement il faut enregistrer les phases de travail du technicien (dates, heures, travail réalisé). Tous les membres du personnel possèdent une identité ainsi qu un matricule qui dépend du nom, du prénom et de l identifiant de la personne. La date d embauche et les régions dans lesquelles le salarié a été embauché doivent être mentionnées. Les techniciens possèdent un niveau d intervention et des compétences et ils ont reçu une formation. chacun ayant des caractéristiques spécifiques. Un technicien de premier niveau n'est affecté qu'aux demandes de premier niveau. Chaque demande est émise par un unique utilisateur qui doit renseigner sur le matériel concerné, l'objet et le niveau d'urgence, la demande est automatiquement horodatée. Chaque demande porte sur un seul matériel, le responsable technique indique l état (Enregistré (par défaut), En cour de traitement, Résolue, Clôturée) et le type de prise en charge( téléphone, télémaintenance, sur site). Le matériel est soit loué soit acheté auprès d'un fournisseur. 10

MISE EN OEUVRE DU PROJET PLANNING Nous avions prévu de travailler ensemble pendant les heures de cours qui étaient réservées au PPE. Cependant, chacun d'entre nous a travaillé de son côté pendant son temps libre afin de pouvoir terminer le projet dans le temps qui nous était imparti. RESSOURCES RESSOURCE MATÉRIELLES Le matériel mis à ma disposition pour développer le projet était : - Les ordinateurs du lycée avec le serveur local wamp, WinDesign et SQL Management Studio installés. - Un environnement de tests sur le serveur local wamp et un environnement de production sur le serveur du lycée. RESSOURCES HUMAINES Tout au long de mon projet nos professeurs restés à notre disposition en cas d éventuelles questions sur le projet. Nous pouvions aussi nous appuyer sur les différents membres du projet. RESSOURCES LOGICIELLES Environnement : serveur web local wamp server, serveur du lycée pour la mise en production. Logiciels: Notepad++,SublimeText, Microsoft Visual Development Express 2010, Modélisation base de données : SQL Management Studio 2008 R2, Win Design. Navigateurs : Mozilla Firefox, Chrome, Opéra, Internet Explorer. Client FTP : FileZilla. REGLES DE GESTION GÉNERALES MEMBRES DU PERSONNEL Tous les membres du personnel possèdent un matricule, un nom, un prénom, une adresse, la date d embauche et les différentes régions dans lesquelles il a travaillé. Ils disposent aussi d un login et d un mot de passe pour s authentifier. 11

Les utilisateurs peuvent recevoir une prime, ils ont un budget, des avantages et un objectif. Les techniciens sont caractérisés par leur formation, par leurs compétences et par leur niveau. Un membre du personnel peut être affecté à un ou plusieurs matériels. UTILISATEUR Un utilisateur demande 1 et 1 seule intervention. Un utilisateur est affecté à 1 ou plusieurs matériels. Utilisateur hérite des attributs de la table Personnel. TECHNICIEN : Un technicien gère aucune ou plusieurs interventions. Un technicien possède 1 et 1 seul niveau. Un technicien enregistre aucunes ou plusieurs phases de travails. Technicien hérite des attributs de la table Personnel. On change l état du technicien avec un booléen (activité/désactivé) pour conserver son travail. INTERVENTION Une intervention est demandée par aucun ou plusieurs utilisateurs Une intervention est gérée par aucun ou 1 seul technicien. Une intervention est concernée par 1 et 1 seul matériel. Une intervention correspond à aucune ou plusieurs phases de travail. MATERIEL Un matériel est affecté à aucun ou plusieurs utilisateurs Un matériel est concerné par aucunes ou plusieurs interventions. Un matériel se caractérise par l identifiant du technicien auquel i est affecté, par un état, par son type et par son fournisseur. MATERIELACHAT Un matériel acheté dispose d une garantie et d une date d achat. MaterielAchat hérite des attributs de la table Materiel. MATERIELLOCATION Un matériel loué dispose d une date de location. MaterielAchat hérite des attributs de la table Materiel. 12

PHASE DE TRAVAIL Une phase de travail correspond à 1 et 1 seule intervention. Une phase de travail est enregistrée par un seul technicien. NIVEAU TECHNICIEN : Un niveau est possédé par aucun ou plusieurs techniciens. REGLES INCLUSION Une intervention ne peut être gérée par un technicien que si un utilisateur l'a préalablement demandée. Cette contrainte et gérer par la base de données (par une contrainte de nullité). Une phase de travail ne peut correspondre à une intervention que si l'intervention est gérée par un technicien. Cette contrainte est gérée par le trigger " PhaseTravailIntervention". RÉALISATION TRIGGERS (DECLENCHEURS) LES TRIGGERS GÉNÉRAUX Les déclencheurs permettent de mettre en œuvre les mécanismes d'intégrité complexes (contraintes) sur une base de données. Ce sont des procédures stockées particulières qui contiennent des instructions et sont associés à une table ou à une vue, ils s'exécutent automatiquement lorsqu'une action associée à cette table se produit. Dans le cadre de notre projet nous avons chacun utilisé des triggers qui nous on permit de gérer les évènements suivants: - Insertion des enregistrements dans les tables. - Mise à jour de données de champs. - Suppression d'enregistrements. Voici un exemple de déclencheurs d'insertion, de mise à jour et de suppression sur la table PersonnelTechnicien. Les mêmes triggers ont été créé sur les autres tables PersonnelUtilisateur, MaterielLocation et MaterielAchat. 13

Trigger permettant d'insérer un nouveau technicien dans la table Technicien mais aussi dans la table «Personnel». CREATE TRIGGER insertpersonneltechicien ON PersonnelTechnicien INSTEAD OF INSERT AS BEGIN SET NOCOUNT ON; DECLARE @matriculepersonnel varchar(50), @nom varchar(50), @prenom varchar(50),@adresse varchar(50), @dateembauche date, @region varchar(50), @login varchar(50), @password varchar(50), @idniveautechnicien int, @formation varchar(50), @competences varchar(50) SELECT @matriculepersonnel=inserted.matriculepersonnel, @nom=inserted.nom, @prenom=inserted.prenom, @adresse=inserted.adresse, @dateembauche=inserted.dateembauche, @region=inserted.region, @login=inserted.login, @password=inserted.password, @idniveautechnicien=inserted.idniveautechnicien, @formation=inserted.formation, @competences=inserted.competences FROM inserted INSERT INTO personnel(personnel.matriculepersonnel, personnel.nom,personnel.prenom,personnel.adresse, personnel.dateembauche, personnel.region, personnel.login, personnel.password) VALUES (@matriculepersonnel, @nom, @prenom, @adresse, @dateembauche, @region, @login, @password) INSERT INTO technicien(technicien.idpersonnel, technicien.idniveautechnicien, technicien.formation, technicien.competences) VALUES(@@identity, @idniveautechnicien, @formation,@competences) END; Trigger permettant la mise à jour d'un technicien dans la table Technicien et dans la tables Personnel. CREATE TRIGGER [dbo].[updatepersonneltechicien] ON [dbo].[personneltechnicien] INSTEAD OF UPDATE AS BEGIN SET NOCOUNT ON; 14

DECLARE @id int, @matriculepersonnel varchar(50), @nom varchar(50), @prenom varchar(50),@adresse varchar(50), @dateembauche date, @region varchar(50), @login varchar(50), @password varchar(50), @idniveautechnicien int, @formation varchar(50), @competences varchar(50) SELECT @id=inserted.idpersonnel, @matriculepersonnel=inserted.matriculepersonnel, @nom=inserted.nom, @prenom=inserted.prenom, @adresse=inserted.adresse, @dateembauche=inserted.dateembauche, @region=inserted.region, @login=inserted.login, @password=inserted.password, @idniveautechnicien=inserted.idniveautechnicien, @formation=inserted.formation, @competences=inserted.competences FROM inserted UPDATE personnel SET personnel.matriculepersonnel=@matriculepersonnel, personnel.nom=@nom,personnel.prenom=@prenom,personnel.adresse=@adres se, personnel.dateembauche=@dateembauche, personnel.region=@region, personnel.login=@login, personnel.password=@password WHERE personnel.idpersonnel=@id UPDATE technicien SET technicien.idniveautechnicien=@idniveautechnicien, technicien.formation=@formation, technicien.competences=@competences WHERE technicien.idpersonnel=@id END; Trigger supprimant les données du technicien de la table Personnel lors de la suppression de ce technicien. CREATE TRIGGER [dbo].[deletepersonneltechnicien] ON [dbo].[personneltechnicien] INSTEAD OF DELETE AS BEGIN SET NOCOUNT ON; DECLARE @id int SELECT @id=deleted.idpersonnel FROM deleted END; DELETE FROM personnel WHERE personnel.idpersonnel=@id DELETE FROM technicien WHERE technicien.idpersonnel=@id 15

LES TRIGGERS DES PHASES INDIVIDUELLES Déclencheur permettant l affectation d une intervention à un technicien. Lors de l insertion d une intervention, l état de l intervention sera automatiquement passé à enregistré, ce qui signifie qu une l intervention est disponible et doit être prise en charge. Si l intervention est prise en charge, on utilisera les procédures cloturer et TraitementIntervention décrites plus bas. CREATE TRIGGER [dbo].[affectationintervention] ON [dbo].[intervention] INSTEAD OF INSERT AS BEGIN DECLARE @idmateriel int, @idtechnicien int, @idutilisateur int, @ticketincident int, @objet varchar(255), @typepriseencharge varchar(255), @niveauurgence varchar(255), @etat varchar(255), @horodate date SELECT @idmateriel=inserted.idmateriel,@idtechnicien=inserted.idtechnicien, @idutilisateur=inserted.idutilisateur, @ticketincident=inserted.ticketincident, @objet=inserted.objet, @typepriseencharge=inserted.typepriseencharge, @niveauurgence=inserted.niveauurgence,@etat=inserted.etat, @horodate=inserted.horodate FROM inserted INSERT INTO intervention(intervention.idmateriel, intervention.idtechnicien, intervention.idutilisateur, intervention.ticketincident, intervention.objet, intervention.typepriseencharge, intervention.niveauurgence, intervention.etat, intervention.horodate) VALUES (@idmateriel,@idtechnicien, @idutilisateur, @ticketincident, @objet, @typepriseencharge,@niveauurgence,'enregistrée',@horodate) END PROCÉDURES STOCKÉES LES PROCÉDURES POUR LES PHASES COMMUNES Procédure qui permet de désactiver un technicien en passant son état à false/désactivé. CREATE PROCEDURE DesactiveTechnicien @idpersonnel int AS UPDATE technicien SET technicien.etat='false' WHERE idpersonnel=@idpersonnel; 16

Procédure qui gère l inclusion entre la table PhaseTravail, Intervention et Technicien. Une phase de travail ne peut correspondre à une intervention que si l'intervention est gérée par un technicien. CREATE TRIGGER [dbo].[phasetravailintervention] ON [dbo].[phasetravail] FOR INSERT AS BEGIN TRANSACTION IF (SELECT i.idintervention FROM inserted, intervention i WHERE inserted.idintervention=i.idintervention) <> NULL BEGIN COMMIT TRANSACTION END ELSE PRINT 'ERREUR, aucune technicien ne gère cette intervention' ROLLBACK TRANSACTION Procédure stockée permet de gérer les types d'authentification. Elle doit renvoyer un entier qui correspond à un niveau d'authentification. - 0 : la personne n'est pas autorisée à accéder à l'application. - 1 : la personne est un utilisateur. - 2 : la personne est un technicien. - 3 : la personne est un membre du personnel (responsable du service technique ou visiteur médical). CREATE PROCEDURE EnregAuth @login varchar(255), @password varchar(255) AS DECLARE @errmsg int IF EXISTS (SELECT niveaupersonnel FROM PersonnelUtilisateur WHERE @login=personnelutilisateur.login AND @password=personnelutilisateur.password) BEGIN SET @errmsg='1' SELECT @errmsg END ELSE BEGIN 17

END IF EXISTS (SELECT niveaupersonnel FROM PersonnelTechnicien WHERE @login=personneltechnicien.login AND @password=personneltechnicien.password) BEGIN SET @errmsg='2' SELECT @errmsg END ELSE BEGIN IF EXISTS (SELECT niveaupersonnel FROM personnel WHERE @login=personnel.login AND @password=personnel.password) BEGIN SET @errmsg='3' SELECT @errmsg END ELSE BEGIN SET @errmsg='0' SELECT @errmsg END END LES PROCÉDURES POUR LES PHASES INDIVIDUELLES Procédure qui clôture une intervention. L identifiant de l intervention résolue est passé en paramètre, la table intervention est ensuit mis à jour, c est-à-dire que son état prend la valeur clôturée. CREATE PROCEDURE cloturer @idintervention int AS UPDATE intervention SET intervention.etat='clôturée' WHERE idintervention=@idintervention; Procédure qui permet de changer l état de l intervention lorsqu elle est prise en charge par un technicien. La procédure met à jour la table intervention est le champ état obtient la valeur en cours de traitement. CREATE PROCEDURE [dbo].[traitementintervention] @idintervention int AS UPDATE intervention SET intervention.etat='en cours de traitement' WHERE idintervention=@idintervention; 18

VUES Une vue est une table virtuelle, c'est-à-dire dont les données ne sont pas stockées dans une table de la base de données, et dans laquelle il est possible de rassembler des informations provenant de plusieurs tables. VUE ENTRE LES TABLES PERSONNEL TECHNICIEN VUE ENTRE LES TABLES PERSONNEL - UTILISATEUR LE CODE SELECT FROM JOIN dbo.personnel INNER JOIN dbo.utilisateur ON dbo.personnel.idpersonnel = dbo.utilisateur.idpersonnel INNER dbo.technicien ON dbo.personnel.idpersonnel = dbo.technicien.idpersonnel 19

VUE ENTRE LES TABLES MATERIEL - ACHAT VUE ENTRE LES TABLES MATERIEL - LOCATION LE CODE SELECT FROM JOIN dbo.materiel INNER JOIN dbo.materielachat ON dbo.materiel.idmateriel = dbo.materielachat.idmateriel INNER dbo.materielocation ON dbo.materiel.idmateriel = dbo.materielocation.idmateriel 20

MÉTHODES COMPLÉMENTAIRES EN PHP Méthode d authentification. On entre le login et le mot de passe passés en paramètres, ils sont ensuite mis dans un tableau, on compare le login et le mot de passe aux champs login et mot de passe de la table Personnel où figure les logins et mot de passe valident. La méthode récupère le niveaupersonnel correspondant au login et au mot de passes passés en paramètres, le niveaupersonnel est inséré dans un tableau. Pour finir on retourne la première case que tableau donne le niveaupersonnel correspondant au login et au mot de passe. public function auth($login, $password) { $selection = array('login', 'password'); $selectionarg = array($login, $password); $liste=gestion::lister('personnel',$selection, $selectionarg); return $liste[0]->getniveaupersonnel(); / } Méthode qui retourne le niveau du personnel correspondant sous forme d entier. Cet entier correspond au niveau d authentification (1 : utilisateur, 2 : technicien, 3 : autre membre du personnel, 4 : n est pas autorisé). public function getniveaupersonnel(){return $this->niveaupersonnel;} Méthode qui clôture une intervention à partir du Web Service. On passe en paramètre l identifiant de l intervention que l on veut clôturée. La fonction liste l intervention passée en paramètre, on obtient ainsi un tableau qui liste les interventions et applique la méthode setetat() à l'intervention dans la première case du tableau. On modifie la première case du tableau c est-à-dire l intervention passé en paramètre. public function cloturer($idintervention){$liste = Gestion::lister('Intervention', 'idintervention',$idintervention); $liste[0]->setetat(); Gestion::modifier($liste[0]);} Méthode permettant de clôturer une intervention en passant par le service client. public function setetat(){ $this->etat='clôturée';} 21

Méthode qui modifie l état d une intervention lorsque celle-ci et prise en charge par un technicien. L identifiant de l intervention concernée est passé en paramètre, la méthode modifie l état de l intervention en appelant. public function traiter($idintervention) { $this->etat = $etat;} TABLEAU DES MÉTHODES 22

23

24

DOSSIER D'ANALYSE MODÈLE CONCEPTUEL DE DONNÉES 25

DIAGRAMME DE CLASSES DICTIONNAIRE DE DONNÉES Type de donnée : indique la nature des champs. Description : désigne la fonction des champs. Champs : Code ou nom des champs. TABLE PERSONNEL CHAMPS DESCRIPTION TYPE idpersonnel Identifiant personnel entier matriculepersonnel Matricule de varchar membre personnel nom Nom du personnel varchar prenom Prénom du membre Varchar du personnel adressse Adresse du membre Varchar 26

dateembauche region login password niveaupersonnel du personnel Date d'embauche du membre du personnel Régions dans lesquelles le membre du personnel a travaillé Login d'un membre du personnel Mot de passe attribué à un membre du personnel Niveau auquel va correspondre le membre du personnel pendant l'authentification Date Varchar varchar varchar entier TABLE TECHNICIEN CHAMPS DESCRIPTION TYPE idniveautechnicien Identifiant du niveau entier du technicien formation Formation du Varchar technicien compétences Compétences du varchar technicien etat Booléen qui change l état du technicien active/désactivé booléen TABLE UTILISATEUR CHAMPS DESCRIPTION TYPE objectif Objectif du visiteur varchar prime si le visiteur reçoit une Boolean prime ou non avantage Les avantages du varchar visiteur budget Le budget du visiteur entier TABLE NIVEAUTECHNICIEN 27

CHAMPS DESCRIPTION TYPE idniveautechnicien Identifient du entier niveau du technicien libelleniveautechnicien Libelle du niveau du technicien varchar TABLE MATERIEL CHAMPS DESCRIPTION TYPE idmateriel Identifiant du matériel entier etat Etat du matériel varchar Type Type du matériel varchar fournisseur Le fournisseur du matériel varchar TABLE INTERVENTION CHAMPS DESCRIPTION TYPE idintervention Identifiant de l'intervention entier ticketincident Ticket d'incident de entier l'intervention objet Objet de l'intervention varchar typepriseencharge Type de prise pour varchar l'intervention niveauurgence Niveau d'urgence de varchar l'intervention etat Etat de l'intervention varchar horodate Date et heure de l'intervention datetime TABLE PHASETRAVAIL 28

CHAMPS DESCRIPTION TYPE idphasetravail Identifiant de la phase de travail entier date Date de début de la phase de Date travail heuredebut Heure de début de la phase de Time travail heurefin Heure de fin de la phase de Time travail travailrealise Travail réalisé pendant la phase de travail varchar DÉVELOPPEMENT DU PROJET NORMALISATION DE LA CHARTE GRAPHIQUE J ai créé une page index en PHP dans laquelle nous avons créé un tableau en HTML avec un fichier CSS associé qui me permet de modifier l'apparence du tableau. De plus, j'ai récupéré un template et j'ai modifié son index pour y afficher mon tableau de méthodes en dynamique. NORMALISATION DE LA BASE DE DONNÉES Lorsque nous avons créé notre base de données nous avons respecté les normes de développement suivantes (notation Camel) : Non utilisation d'accents dans les noms des tables et des champs. Aucun espace dans les noms de champs. Utilisation d'une majuscule pour le deuxième mot qui compose le nom des champs (exemple : idintervention). GESTION DE PROJET MISE EN OEUVRE Afin de pouvoir organiser mon travail le répertoire était organisé de la manière suivante. 29

REPARTITION DES TACHES Des phases communes devaient être couvertes par chaque membre du groupe. Description de la solution retenue : - Contexte, objectifs et contraintes. - Gestion du projet (planning, répartition des tâche, suivi des indicateurs). - Spécifications conceptuelles (règle de gestion, modèle de données, cas d'utilisation, diagramme de classes,...). - Spécifications techniques des opérations (modèle physique de la base de donnée, éléments programmables, classes métiers, classes de gestion,...). Modélisation et implémentation physique de la base de données. Organisation de la gestion des versions. Méthodes d'authentification et gestion des différents profils. Création automatisée du tableau des méthodes exposées par le Web Service. Les phases individuelles étaient réparties en équipe de projet : Projet 1 : Gestion du parc informatique et de l'assistance. Pinol Mathieu : - Gestion des différents personnels et zone d'authentification et différents profils de personnels. - Gestion des équipements et de leur affectation (technicien). Besset Maylis : - Création des demandes d'intervention (utilisateur). - Traitement et clôture des interventions (techniciens + responsables technique). Projet 2 : Gestion des activités des visiteurs médicaux. Cédric Gualmini : - Zone d'authentification et différents profils de visiteurs. - Création et gestion des différents visiteurs. - Gestion des produits (visiteur). - Gestion des praticiens à partir d'un fichier de données (à concevoir), réaliser un module d importation (responsable ou délégué). Jean-Baptiste Lambert : - Gestion et affectation des activités complémentaires (visiteurs + responsables). - Affectation et gestion des budgets par le responsable. - Création et gestion des visites (visiteur). - Calcul du coût des visites. 30

BILAN DU PROJET PROBLÈMES TECHNIQUES Nous avons bien sûr été confrontés à des problèmes techniques au cours de l'élaboration de notre projet. Problème au niveau du MCD : Nous avons passé beaucoup de temps sur l'élaboration de notre MCD car nous devions gérer les contraintes sur nos tables ainsi que les différents héritages. Problème au niveau de la base de données : Les normes imposées par PDO nous on a plusieurs reprises contraint de recommencer nos classes métiers. (Exemple récurrente d'erreur : les violations d'intégrités). En effet, la base de données suit des règles sémantiques et vérifie après chaque mise à jour qu aucune contrainte d'intégrité n'est violée. PROBLÈMES ORGANISATIONNELS Les problèmes techniques nous on fait perdre du temps et nous avons tous du revenir à un moment de du projet sur la conception de nos classes métiers ou de notre base de données. Je n ai pas eu le temps de gérer les phases individuelles de ma partie. Ces parties ont été développées après ma présentation à mon premier oral. BILAN FONCTIONNEL Fonctionnalités Description de la solution retenue Modélisation et implémentation physique de la base de données. Etat Terminé Terminé Organisation de la gestion des versions. Méthodes d'authentification et gestion des différents profils. Création automatisée du tableau des méthodes exposées par le Web Service. Terminés Terminé 31

CONCLUSION Ce troisième projet nous aura permis de nous familiariser avec le langage XML et de confirmer nos compétences en PHP, CSS et en SQL. La mise en situation de ce projet aura été bénéfique pour notre groupe car elle nous a permise de nous rapprocher d'un cas concret d'entreprise. 32

ANNEXES DESCRIPTIF DE LA SITUATION PROFESSIONNELLE BTS Services informatiques aux organisations Session 2015 E4 Conception et maintenance de solutions informatiques Coefficient 4 DESCRIPTION D UNE SITUATION PROFESSIONNELLE Épreuve ponctuelle PARCOURS SISR Contrôle en cours de formation PARCOURS SLAM NOM et prénom du candidat : BESSET Maylis N candidat : 0315873734 Contexte de la situation professionnelle : Ce projet personnel encadré simule une demande de la part du laboratoire Galaxy Swiss Bourdin. Suite à la fusion entre deux entreprises pharmaceutiques, le laboratoire GSB désire optimiser son parc informatique. Il souhaite donc mettre à disposition de son personnel une application Web répartie visant à permettre une gestion des futures actions du laboratoire. Intitulé de la situation professionnelle : L objectif consistait à mettre à disposition des techniciens de la société une application Web répartie visant à permettre une gestion des futures activités des visiteurs médicaux. Période de réalisation : Octobre/Décembre 2014 Lieu : Lycée de la CCI Nîmes Modalité : Seul En équipe 33

Principale(s) activité(s) concernée(s) : - A1.1.1/ Analyse du cahier des charges d'un service à produire. - A1.2.3/ Détermination des tests nécessaires à la validation d'un service. - A1.3.1/ Test d'intégration et d'acceptation d'un service. - A1.3.4/ Déploiement d un service. - A1.4.1/ Participation à un projet. - A3.1.2/ Maquettage et prototypage d une solution d infrastructure. - A4.1.1/ Proposition d'une solution applicative. - A4.1.3/ Conception ou adaptation d une base de données. - A4.1.6/ Gestion d environnements de développement et de test. - A4.1.7 Développement, utilisation ou adaptation de composants logiciels. - A4.1.8/ Réalisation des tests nécessaires à la validation d éléments adaptés ou développés. Conditions de réalisation² (ressources fournies, résultats attendus) Ressources fournies : - Cahier des charges. - Documentation contenant les normes de développement de PHP. - Requêtes et méthodes PDO3. - Dossier répertoriant un fichier d exemple du Soap-client. - TP Android effectués pendant la formation. - Ressources sur Internet. Résultats attendus: Elaboration est mise en production d une application sous la forme d'un Web Service. Avec une modèle client-serveur. Productions associées - Documentation technique. - Sauvegarde local du Service et de l application (WebService, MCD,tests, rapports de tests). - Sauvegarde du Web service en production et application en production (WebService, MCD,tests, rapports de tests). 34

Modalités d accès aux productions 1 : Mot de passe base de données : 30BE41 Login base de données : Besset Lien pour le Web service sur le logiciel de production FileZilla : http://srvsioc.lycnim.cci.local/sio2015/besset/ppe4/webservice/ Au verso de cette page, le candidat présente un descriptif détaillé de la situation professionnelle et des productions réalisées sous forme d un rapport d activité permettant notamment de mettre en évidence la démarche suivie et les méthodes retenues. BTS Services informatiques aux organisations Session 2015 E4 Conception et maintenance de solutions informatiques Coefficient 4 DESCRIPTIF DE LA SITUATION PROFESSIONNELLE 1 Conformément au référentiel du BTS SIO «Dans tous les cas, les candidats doivent se munir des outils et ressources techniques nécessaires au déroulement de l épreuve. Ils sont seuls responsables de la disponibilité et de la mise en oeuvre de ces outils et ressources. Les candidats qui n en sont pas munis sont pénalisés dans les limites prévues par la grille d aide à l évaluation proposée par la circulaire nationale d organisation.». Il s agit par exemple des identifiant, mot de passe, URL d un espace de stockage et de la présentation de l organisation du stockage. 35

La situation professionnelle consistait à mettre en place une application qui serait tout d abord sous la forme d un Web service. L architecture de l application est serveur/client. Le service dispose d un système d authentification qui gère les différents niveaux de personnel (technicien, utilisateur,..). L application prend également en compte la création, la prise en charge et la clôture des interventions affectées aux techniciens. Dans un premier temps, une analyse du cahier des charges qui a été fourni par nos enseignants, a permis de cibler les besoins et les contraintes liées à l application. Par la suite, une définition des règles de gestion a été nécessaire afin d élaborer le modèle conceptuel de données. Une fois le MCD validé, la génération du script a permis l implantation de la base de données sous SQL Server. La création des classes s est effectuée à l aide de la documentation contenant les normes de développement en PHP. Le MCD s est vu modifier afin que les contraintes sur héritage puissent être incluses. Le service contient une documentation des méthodes utilisée par le service, le descriptif est disponible dans le tableau de la page index. Des vues ont été créées sous SQL Server ainsi que les déclencheurs qui permettent de gérer les insertions, les suppressions et les modifications des données dans la base. Les déclencheurs plus spécifiques ont été développés après que la gestion des contraintes d inclusion fut traitée (incluant une nouvelle modification du MCD). Des procédures ont été ajouté afin de gérer les différents niveaux d'authentification des membres du personnel (méthode authentification). Des tests unitaires et fonctionnels ont été établis sur le serveur local et à travers le service développé (soap-client). Le projet a été mis en production grâce au client FTP FileZilla, il est accessible depuis le lien suivant : http://srvsioc.lycnim.cci.local/sio2015/besset/ppe3/webservice/ sur le réseau du lycée de la CCI. Un dossier technique récapitule l ensemble des fonctionnalités du service. De plus, il constitue une aide pour les futurs programmeurs. 36