Mise en place d’une solution de gestion de parc informatique

ANALYSE ET SPÉCIFICATION DES BESOINS

Introduction: Dans le but de développer un système cohérent et complet d’une solution de gestion de parc informatique, une phase de spécification des besoins est jugée très importante. En effet, elle permet de recenser les fonctionnalités du système et de définir son architecture fonctionnelle et c’est l’objectif de ce chapitre.

Spécification des besoins 

Définition des acteurs : Notre application comporte deux acteurs:
 Administrateur : le technicien informatique qui a la possibilité de gérer l’application, d’ajouter, supprimer ou modifier un matériel, consulter l’état du parc en temps réel, gérer les tickets (les interventions)  Utilisateur : un employé ou bien un enseignant qui a la possibilité d’authentifier, ajouter ou supprimer une demande de réclamation et consulter l’état de la demande.

Les besoins fonctionnels : Les besoins fonctionnels représentent les actions que le système doit exécuter.
Selon notre application, nous avons identifié les besoins fonctionnels pour l’administrateur (le Technicien), d’une part et pour l’utilisateur (Employé ou bien Enseignant), d’autre part.
L’administrateur (le Technicien) peut réaliser les actions suivantes :

1. Authentification :  S’identifier par un login et un mot de passe 2. Gérer utilisateur :  Ajouter un utilisateur  Modifier un utilisateur  Supprimer utilisateur  Rechercher utilisateur
3. Gérer matériel:  Ajouter un matériel  Modifier un matériel  Supprimer un matériel  Rechercher un matériel 4. Gérer Bureau :  Ajouter un bureau  Modifier un bureau  Supprimer un bureau  Rechercher un bureau 5. Gérer Fournisseur :  Ajouter un Fournisseur  Modifier un Fournisseur  Supprimer un Fournisseur  Rechercher un Fournisseur 6. Consulter l’état du parc  Imprimer l’inventaire du matériel  Suivi l’état du parc en temps réel 7. Contrôler les Tickets :  Consulter la liste des demandes d’interventions  Imprimer la liste des demandes d’interventions  Changer l’état de maintenance (attribuer les solutions aux réclamations)  Imprimer un bon de sortie en cas d’envoi du matériel pour réparation par une société privée.

L’utilisateur (Employé ou bien Enseignant) peut effectuer les actions suivantes :
1. Authentification :  S’identifier par un identifient 2. Gérer une Ticket :  Ajouter une demande d’intervention  Annuler une demande d’intervention  Suivre l’état de la demande d’intervention

Les besoins non fonctionnels : Dans notre application, on a défini les besoins fonctionnels qui sont indispensables pour le bon fonctionnement de notre système. Il existe d’autres besoins non fonctionnels qui sont exprimés en matière de performance et du type de matériel utilisé. Dans notre projet nous pouvons citer :
 Ergonomie : L’interface de l’application doit être simple et utilisable pour les utilisateurs pour qu’ils puissent l’exploiter.  L’authentification : Notre application devra assurer une bonne sécurité, chaque utilisateur doit avoir un identifiant.  L’extensibilité : Notre application doit être extensible qui signifie la possibilité d’ajout de nouvelles fonctionnalités ou modification de l’existant.  L’intégrité : Notre application doit être intégrée à d’autres systèmes et utilisable par d’autres applications.  La disponibilité : Notre application puisse fonctionner dans n’importe quel système d’exploitation à condition d’avoir une connexion internet.

Conclusion : Dans ce chapitre, nous avons spécifié les besoins pour notre application web en identifiant plus particulièrement les besoins fonctionnels et non fonctionnels.

Dans le chapitre suivant nous allons traiter les méthodologies de conception, tout en présentant les diagrammes de séquences et les diagrammes de classe.

Importance de la modélisation : Le recours à la modélisation est depuis longtemps une pratique indispensable pour tout système voire le développement logiciel, car un modèle est prévu pour arriver à anticiper les résultats du codage.

Un modèle est en effet une représentation abstraite d’un système destiné à en faciliter l’étude et à le documenter. C’est un outil majeur de communication entre les différents intervenants au sein d’un projet. Chaque membre de l’équipe, depuis l’utilisateur jusqu’au développeur, utilise et enrichit le modèle différemment.

Le modèle présente notamment l’atout de faciliter la traçabilité du système, à savoir la possibilité de partir d’un de ses éléments et de suivre ses interactions et ses liens avec d’autres parties du modèle.

Les diagrammes UML

Diagramme de cas d’utilisation 
Les diagrammes de cas d’utilisation sont des diagrammes UML utilisés pour donner une vision globale du comportement fonctionnel d’un système logiciel. Un cas d’utilisation représente une unité discrète d’interaction entre un utilisateur (humain ou machine) et un système. Il est une unité significative de travail. Dans un diagramme de cas d’utilisation, les utilisateurs sont appelés acteurs (actors), ils interagissent avec les cas d’utilisation (use cases).
Présentation des cas d’utilisation (diagramme des cas d’utilisations): Cas d’utilisation « s’authentifier » pour un utilisateur
Avant d’accéder à l’application, les différents utilisateurs doivent saisir correctement leurs paramètres de connexions. Scénario principal : 1- L’utilisateur demande la page gestion de la maintenance 2- Le système affiche la page d’authentification. 3- L’utilisateur saisi leur identifiant. 4- Le système d’authentification vérifie l’identité de l’utilisateur. Si l’identifient est invalide, le système signale l’erreur et affiche un message pour ressaisir. Cas d’utilisation « gérer utilisateurs » :

Ce cas d’utilisation permet au Technicien la gestion des utilisateurs « employé ou bien enseignant » (Ajouter, Modifier et Supprimer).

Cas d’utilisation « Ajout utilisateur » :
– Le technicien ouvre la fenêtre d’administration – Il clique sur le bouton de gestion des utilisateurs. – Il choisit l’action à réaliser. – Action d’ajout d’un utilisateur : saisir les informations d’un employé ou un enseignant (identifient, Nom, Prénom, …) ensuite clique sur le bouton ajouter. Si l’identifient existe, un message d’erreur sera affiché.
Cas d’utilisation « modifier utilisateur » :
Action de modification d’un utilisateur : sélectionner l’employé à modifier à partir du tableau, puis modifier les champs existants et sauvegarder.
Cas d’utilisation « suppression utilisateur » :
Sélectionner l’utilisateur à supprimer, puis appuyer sur un bouton de suppression.

Table des matières

Introduction générale
Chapitre I : Etat de l’art
Introduction
I. Présentation de l’organisme d’accueil
I.1. Services administratifs
I.2. Organigramme
II. Etude de l’existant
II.1. Problématique
II.2. La critique de l’existant
II.3. Solution Proposée
Conclusion
Chapitre II : Analyse et spécification des besoins
Introduction
I. Spécification des besoins
I.1. Définition des acteurs
I.2 Les besoins fonctionnels
I.3. Les besoins non fonctionnels
Conclusion
Chapitre III : Conceptions
Introduction
I. Architecture fonctionnelle de l’application
II. Importance de la modélisation
III. Les diagrammes UML
III.1. Diagramme de cas d’utilisation
III.2. Diagramme de classe
III.3. Diagramme de séquence
Conclusion
Chapitre IV : Réalisation
Introduction
I. Les outils de développement
I.1. Notepad++
I.2. WampServer
I.3. PHP Maker
I.4. Adobe Dreamwaver
II. Les interfaces de l’application
II.1. Interfaces utilisateur
II.2. Interfaces administrateur
Conclusion
Webographie

Télécharger le rapport complet