OMGL 6 Helpdesk Radoslav Cvetkoski, Xavier Fanti, Yohann Haution, Yanis Salti, Sébastien Tassier
Sommaire Helpdesk... 1 0. Historique du document... 3 1. Introduction... 3 2. Présentation de la société... 3 3. Présentation générale du projet... 4 4. Organisation du projet... 4 5. Etude de l existant... 4 6. Les besoins fonctionnels... 5 7. Les besoins non fonctionnels... 17 8. Les contraintes... 18 9. Les solutions... 18 10. Le coût... 18 11. Le planning... 19 13. Glossaire... 21 Page 2
0. Historique du document 28/01/2012 : Version 1.0 29/01/2012 : Version 1.1 30/01/2012 : Version 1.2 1. Introduction Notre projet doit répondre aux besoins de la société Smith & Jones Inc. qui souhaiterait mettre en place un helpdesk pour gérer les problèmes matériels et/ou logiciels des demandeurs possédant un parc informatique. 2. Présentation de la société Smith & Jones Inc est une jeune entreprise informatique. Raison Social : Smith & Jones Inc Statut : SA Capital : 1000000 Date de Création : Printemps 2011 Adresse : 9 Rue de l arc en ciel 74940 Annecy-le-Vieux Mail : Smith&Jones@live.fr Activité : Informatique Page 3
3. Présentation générale du projet Le but du projet est la mise en place d un helpdesk qui a pour objectif principal de faciliter la gestion des problèmes matériels et logiciels des postes informatiques des membres de l'entreprise. Ce projet est indispensable à l entreprise pour gérer les problèmes d un parc informatique important. Les personnes concernées sont les employés de l entreprise Smith&Jones qui rencontrent un problème informatique. Ce projet devra permettre à l entreprise de gérer au mieux ses problèmes informatiques en utilisant un principe de ticket détaillant les problèmes rencontrés. 4. Organisation du projet Sponsor/mandant : Nicolas Meger Comité de pilotage : Smith & Jones Nicolas Meger Équipe de projet : Radoslav Cvetkoski Xavier Fantin Yohann Haution Yanis Salti Sébastien Tassier Maîtrise d ouvrage : Nicolas Meger Maîtrise d œuvre : Radoslav Cvetkoski Xavier Fantin Yohann Haution Yanis Salti Sébastien Tassier 5. Etude de l existant Page 4
Aucun système informatique ne permettait de gérer les pannes auparavant. 6. Les besoins fonctionnels Prérequis pour tous les cas d'utilisation : On suppose que l'utilisateur du système, qu'il soit opérateur, demandeur, ou responsable de service, est connecté au système. L entreprise Smith&Jones attend de ce projet une application web permettant : Page 5
Cas d utilisation : Déterminer date résolution Opérateur, Responsable du service Indiquer la date à laquelle le problème sera traité. Précondition : Le ticket doit être saisi dans le système. Scénario nominal : 1. L opérateur recherche le ticket. (Voir use case correspondant) 2. L opérateur ou le responsable estime la date à laquelle il pourra résoudre le problème. Page 6
3. Il valide ensuite cette date. Cas d utilisation : Requalifier ticket Responsable, Opérateur ------------------------------------------------------------- Requalifier le type de problème et le degré d importance des tickets. Précondition : Le ticket doit être saisi dans le système. Scénario nominal : Page 7
1. L opérateur recherche le ticket. (Voir use case correspondant) 2. L opérateur ou le responsable saisit les nouvelles informations. 3. L opérateur ou le responsable valide les changements. Scénario alternatif : 3.1. L opérateur a oublié de saisir le degré d importance ou le type de problème. 3.2. Une boîte de dialogue est déclenchée pour avertir l utilisateur qu il a oublié de remplir un des deux champs obligatoires. 3.3. Retour à l étape 2. Voir Use Case «Déterminer date résolution». Cas d utilisation : Rechercher ticket Responsable, Opérateur ---------------------------------------------------------------------------- Rechercher des tickets par critères multiples. Scénario nominal : 1. L opérateur ou le responsable saisit les critères de recherche. (Voir maquettes) 2. Le système affiche le résultat. Scénario alternatif : 2.1. Aucun résultat n est trouvé. 2.2. Retour à l'étape 1. Page 8
--------------------------------------------------------------------- Cas d utilisation : Clore ticket. Responsable, Opérateur Fermer un ticket Précondition : Le ticket doit être saisi dans le système et ne pas être déjà clos. Scénario nominal : 1. L opérateur ou le responsable a corrigé le problème. 2. L opérateur ou le responsable ferme le ticket. Page 9
Scénario alternatif : 1.1. Le problème ne peut pas être corrigé. 1.2. Le ticket est fermé par le responsable de service. -------------------------------------------------------------- Cas d utilisation : Consulter ses tickets. Responsable, Opérateur, Demandeur Consulter les tickets. Page 10
Scénario nominal : 1. La personne clique sur consulter ses tickets. 2. Le système affiche les tickets qui : - soit ont été émis par l'utilisateur, si celui-ci est un demandeur, - soit sont attribués à l'utilisateur, si celui-ci est un opérateur ou le responsable de service. Scénario alternatif : 2.1. L utilisateur n a émis ou ne s occupe d aucun ticket. 2.2. Le système affiche : «Aucun ticket à consulter» 2.3. Retour à l accueil du site. -------------------------------------------------------------------- Page 11
Cas d utilisation : Commenter ticket Responsable de Service, Opérateur Ajouter un commentaire au ticket. Précondition : Le ticket doit être saisi dans le système. Scénario Nominal : 1. L opérateur ou le responsable consulte ses tickets et sélectionne celui à commenter. 2. L opérateur ou le responsable commente le ticket. 3. Il enregistre le ticket. Cas d utilisation : Transférer ticket Responsable de Service, Opérateur Transférer un ticket à un autre opérateur Précondition : Le ticket doit être saisi dans le système. ---------------------------------------------------------------- Scénario Nominal : 1. Le responsable ou l opérateur consulte ses tickets et sélectionne le ticket à transférer. 2. Il sélectionne, selon lui, l opérateur qualifié pour traiter le problème. 3. Il choisit la raison du transfert : «surcharge» ou «non-compétence». 4. Il envoie le ticket Voir Use Case «Déterminer date résolution». -------------------------------------------------------------------------- Cas d utilisation : Visionner statistiques Page 12
Responsable de Service Renseigner le responsable de service sur des statistiques pertinentes. Scénario Nominal : 1. Le responsable du service sélectionne le type de statistique qu il souhaite visualiser. Il choisit pour cela les paramètres de son graphique. 2. Le système affiche les statistiques demandées. --------------------------------------------------------------------------- Cas d utilisation : Page 13
Ajouter Opérateur Responsable de Service Un nouvel opérateur sera enregistré dans le système. Scénario Nominal : 1. Le responsable créé un nouvel opérateur. 2. Il remplit les champs obligatoires dont le nom, le prénom, l adresse mail. 3. Il doit aussi obligatoirement sélectionner un domaine dans lequel l opérateur est compétant. ----------------------------------------------------------------------- Page 14
Cas d utilisation : Modifier Opérateur Responsable de Service Modifier les données sur l opérateur comme le nom, prénom, etc. Précondition : L opérateur à modifier existe. Scénario Nominal : 1. L' écran est le même que pour l ajout d un client. Les champs sont déjà pré-remplis par les informations actuelles. 2. Le responsable choisit les informations à modifier puis il valide la modification. Scénario alternatif : 2.1. Le responsable oublie de remplir un des champs obligatoire. 2.2. Une boite de dialogue s'affiche lui indiquant son erreur. 2.3. Retour à l'étape 1. Voir Use Case «Ajouter opérateur». ---------------------------------------------------------------- Cas d'utilisation : Attribuer un ticket Acteur Système Attribuer à un opérateur compétent le ticket qui vient d'être saisi. Scénario nominal : 1. Le système choisit l'opérateur qui dispose des compétences nécessaires au traitement du problème. 2. Il redirige le ticket. Scénario secondaire : 1.1. Aucun opérateur ne dispose des compétences nécessaires au traitement du problème. 1.2. Le système redirige le ticket vers le responsable du service. Page 15
Pas d'écran, opération effectuée par le système. ----------------------------------------------------------------------- Cas d'utilisation : Répertorier une intervention. Système Garder en mémoire toutes les interventions passées. Scénario principal : 1. Une fois le ticket clos le système garde en mémoire les informations le concernant. Pas d'écran, opération effectuée par le système. ------------------------------------------------------------------------- Cas d'utilisation : Saisir ticket Demandeur Permettre au demandeur d avertir un opérateur de son problème. Scénario nominal : 1. Le demandeur saisit les informations, c'est à dire le type de problème, son numéro de poste et le niveau d'urgence. 2. Le système enregistre le ticket et le traite (voir cas d'utilisation attribuer ticket). Page 16
7. Les besoins non fonctionnels Compatible avec les navigateurs internet principaux comme Mozilla Firefox, Opéra, Google Chrome et Internet Explorer (à partir d IE 8). Chaque fonctionnalité du helpdesk doit être accessible en moins de quatre clics. Le site doit être ergonomique : pas plus de 3 clics pour accéder à une fonctionnalité. Page 17
8. Les contraintes Contraintes organisationnelles avec un délai très strict avec le rendu du Cahier des Charges le 30 Janvier et le rendu du projet le 28 Mars. Contraintes humaines, avec seulement 5 personnes disponibles dans l équipe de projet. L'utilisation du Framework Symfony oblige les développeurs à respecter la convention de nommage du Framework. 9. Les solutions Solutions techniques : Pour réaliser l'application web nous avons choisi d'utiliser le Framework Symfony. Nous utiliserons le langage de programmation PHP 5 avec une architecture MVC pour réaliser l'application. La base de données utilisée est une base de données Oracle. Interfaces graphiques : Voir «Les besoins fonctionnels». Les maquettes présentées précédemment sont susceptibles d'évoluer légèrement au cours du développement. 10. Le coût Voir document Excel ci-joint : Estimation des coûts. Page 18
11. Le planning Mode Tâche Nom de la tâche Durée Début Fin Prédécesseurs Noms ressources Lun Helpdesk 68 hr 23/01/12 28/03/12 Lun Mar Conception 20 hr automatiquement 23/01/12 07/02/12 automatiquement 8 hr Planning 8 hr prévisionnel Analyse économique du projet 8 hr Conception détaillé / Dossier de 12 hr spécification logicielle Réalisation et tests 36 hr Réalisation du script de création de la base de données Réalisation de l'application cliente Saisir un ticket 4 hr 36 hr 6 hr Gérer opérateur 14 hr Gérer ticket Attribuer ticket Répertorier ticket Déterminer date résolution Consulter ticket 14 hr 6 hr 4 hr 6 hr 4 hr Lun 23/01/12 Lun 23/01/12 Lun 23/01/12 Lun 30/01/12 08/02/12 08/02/12 08/02/12 08/02/12 08/02/12 Mar 21/02/12 Mar 28/02/12 Lun 05/03/12 Mar 28/02/12 Mar 21/02/12 27/01/12 27/01/12 27/01/12 Mar 07/02/12 16/03/12 10/02/12 16/03/12 Lun 20/02/12 Lun 27/02/12 02/03/12 02/03/12 Mar 06/03/12 02/03/12 22/02/12 2 2 2 10 11 15 11 10 Tous Xavier Fantin Xavier Fantin Tous Yanis Salti Xavier Fantin, Sébastien Tassier Radoslav Cvetkoski, Yanis Salti, Yohann Haution Radoslav Cvetkoski, Yanis Salti, Yohann Haution Xavier Fantin, Sébastien Tassier Xavier Fantin, Sébastien Tassier Radoslav Cvetkoski, Yanis Salti, Yohann Haution Xavier Fantin, Sébastien Tassier Page 19
Visionner statistique 12 hr Réalisation des dossiers de recettes et 32 hr dossiers de tests Finalisation des dossiers et 12 hr automatiquement préparation de la soutenance Rédaction du 4 hr manuel Rédaction du dossier de gestion de 4 hr projet Préparation de la 4 hr soutenance Finalisation des dossiers de tests de recette et de gestion de projet 4 hr 07/03/12 08/02/12 Lun 19/03/12 Lun 19/03/12 Lun 19/03/12 21/03/12 Mar 27/03/12 16/03/12 Mar 13/03/12 28/03/12 Mar 20/03/12 Mar 20/03/12 23/03/12 28/03/12 14 7 Radoslav Cvetkoski, Yanis Salti, Yohann Haution Tous Tous Tous Tous Page 20
12. Glossaire Framework : Kit de composants logiciels structurels, qui servent à créer les fondations ainsi que les grandes lignes de tout ou partie d'un logiciel (architecture). Ici le Framework est essentiellement constitué des classes mères qui seront dérivées et étendues par héritage. (Source : Wikipédia) Page 21