PLAN RAPPORT PFEnicolas.ferrary.free.fr/rapport pfe final.doc · Web view2003-04-04 · Le...

Adrien BONNEFOY

Jean LAMY

Jérémy LUSSAGNET

Vanak OUCH

BONNEFOY – LAMY – LUSSAGNET – OUCH INRA, unité CSE

1. LE PROJET 3

A. LE CLIENT 3B. LE TUTEUR 3C. L’ÉQUIPE 3D. POURQUOI CE PROJET ? 4E. DESCRIPTION 4

2. GESTION DU PROJET 6

A. MÉTHODOLOGIE DE TRAVAIL 6B. TRAVAIL RÉALISÉ 7C. PROBLÈMES RENCONTRÉS 9

3. BILAN 10

ANNEXES 11

A. PLANIFICATION 11B. COMPTES RENDUS DE RÉUNION AVEC LE CLIENT 12C. EXEMPLES DE FONCTIONS DU SYSTÈME 18D. EXEMPLE DE DIAGRAMME DE CAS D’UTILISATION 19e. Exemple de Cas d’Utilisation 20

PFE 2003 sur 20


1. Le Projet

a. Le client

Le client demandeur et bénéficiaire de notre projet de fin d’étude (nous emploierons le

terme PFE dans la suite du document) est l’INRA d’Avignon, plus particulièrement l’unité

CSE (Climatologie, Sol et Environnement). L’INRA est l’Institut National de la Recherche

Agronomique. Deux pôles de recherche majeurs se dégagent au centre d’Avignon :

o Ingénierie de la gestion de l'environnement, pour les territoires cultivés et la

forêt méditerranéenne,

o Maîtrise de la qualité des produits cultivés et transformés pour la santé du

consommateur.

Mais notre projet ne concernait pas un des pôles de recherche. Nous sommes

intervenus uniquement auprès des personnes responsables de l’informatique à l’unité CSE. Il

s’agit de Mme Nathalie MOITRIER et M. Philippe CLASTRE, ingénieurs et responsables

informatique.

b. Le tuteur

La personne chargée du suivi du PFE durant tout le déroulement du projet est M.

Patrick NASARRE, enseignant à l’IUP dans le pôle gestion, économie et entreprise,

responsable des relations entreprises mais aussi consultant extérieur. Son rôle était de suivre

l’évolution du projet et de nous guider dans la réalisation de celui-ci.

c. L’équipe

Notre équipe est formée de 4 personnes, bien entendu toutes en 3ème année :

o Jérémy LUSSAGNET, option Administration et réseaux

o Vanak OUCH, option Génie Logiciel

o Adrien BONNEFOY, option Génie Logiciel

o Jean LAMY, option Génie Logiciel

PFE 2003 sur 20


d. Pourquoi ce projet ?

Chaque unité de l’INRA d’Avignon gère son parc informatique de manière autonome ;

les moyens humains et matériels sont donc hétérogènes d’une unité à l’autre.

L’unité CSE met à disposition de son personnel six personnes pour gérer les

ressources (chacune à 20% de son temps), lesquelles se coordonnent pour assurer un bon

fonctionnement du parc informatique. Travaillant la plupart du temps dans l’urgence, ces

personnes n’ont pas le temps de mettre en place des moyens adaptés pour les aider dans la

gestion du parc. Ceci engendre un défaut de traçabilité des opérations et des difficultés pour

obtenir une vision claire de l’état du parc à un instant donné.

L’acquisition d’un logiciel se révélant à la fois onéreuse et pas complètement adaptée

à leurs besoins, Mme MOITRIER et M. CLASTRE ont préféré soumettre un projet à des

étudiants de l’IUP GMI d’Avignon.

e. Description

L’objectif principal de l’outil à développer était de faciliter leur organisation du

travail, et plus particulièrement de réaliser des économies de temps au quotidien.

D’un point de vue plus fonctionnel, l’application devait offrir les possibilités

suivantes :

Gestion de l’équipement informatique de l’unité

Gestion des utilisateurs (description, statut, droits,…)

Gestion de la maintenance du parc (problèmes, interventions)

Réservations de matériels.

Gestion de la localisation de matériel

PFE 2003 sur 20


Comme l’outil sera utilisé par l’ensemble du personnel, il était donc important qu’il

soit convivial. De plus, il devait présenter un aspect évolutif (intégration de nouveaux types

de matériels à gérer) et extensible (ajout facile de nouvelles fonctionnalités).

D’un point de vue interface, le client souhaitait avoir que le logiciel soit basé sur une

interface WEB pour pouvoir faciliter son apprentissage par le personnel. Ainsi, dès le début

nous avons convenu que le développement se ferait en PHP avec une base de données à

choisir.

Pour cela, nous devions travailler en collaboration avec les clients afin de valider les

différentes étapes de la réalisation du projet.

PFE 2003 sur 20


2. Gestion du projet

a. Méthodologie de travail

o Equipe

Afin d’être les plus efficaces possibles, nous avons mis en place une organisation interne

particulière.

L’équipe était divisée en deux binômes dont la composition était variable ce qui a permis de

mixer les compétences. Tout travail effectué par un binôme était revu par l’autre afin de

bénéficier d’un point de vue différent, ce qui permettait d’appliquer certaines corrections et

ensuite de valider cette tâche en interne.

Nous avons décidé qu’un membre de l’équipe occuperait la fonction de chef de projet, il

s’agissait de Jérémy Lussagnet. Ce dernier était chargé de composer les binômes, répartir les

différentes tâches à accomplir entre eux, coordonner le travail et assurer la communication

avec le client et le tuteur (essentiellement par mail, téléphone si nécessaire).

La fonction d’animateur de réunion a été assurée par Jean Lamy et le rôle de secrétaire était

défini ponctuellement pour chaque réunion.

o Réunions

Durant tout le déroulement du projet, nous avons organisé des réunions régulières avec le

client. Chacune de ces réunions était préparée à l’avance : nous dressions une liste de sujets à

discuter et nous préparions les documents à présenter. Ceci permettait de valider les différents

travaux réalisés ou d’apporter les modifications nécessaires. A la fin de chaque entrevue, un

membre de l’équipe se chargeait de la rédaction d’un compte rendu à partir des notes prises.

De la même façon, nous avons été amenés à rencontrer notre tuteur afin d’avoir un suivi de

l’évolution du projet : présentation des derniers travaux réalisés et définition de la suite des

opérations.

PFE 2003 sur 20


b. Travail réalisé

o Cahier des charges

Lors de la réunion de prise de contact, le 29 Novembre 2003, les clients nous ont

présenté le projet. Nous avons donc pu élaborer le cahier des charges à partir des

informations collectées ce jour-là afin de définir les points suivants :

Cadre du projet

Objectifs

Cadre de développement

Spécifications Techniques

Cadre Financier

o Elaboration du document d’analyse

Comme dans tout projet informatique, l’étape d’analyse est la partie la plus

importante. Elle représente souvent la moitié du temps total d’un projet. Nous avons donc

rédigé un document d’analyse complet comportant les éléments suivants :

Description du contexte

Liste des besoins en terme de service rendu à l’utilisateur

Cette liste correspond aux « requirements » en UML.

Présentation des acteurs

Spécifications des fonctions du système

Présentation des cas d’utilisation, illustrée par des diagrammes.

La liste des cas d’utilisation est la plus complète possible afin de comprendre le

fonctionnement de chaque partie de l’application.

Modèle Conceptuel de Données

Ce schéma présente comment les données seront organisées entre elles dans la base

de données.

Maquettes d’interfaces (d’un point de vue fonctionnel)

Ces maquettes fournissent une représentation visuelle des possibilités de l’application.

PFE 2003 sur 20


Pour réaliser une grande partie du document nous nous sommes basés sur la méthodologie

UML, seul le Modèle Conceptuel de Données a été défini à partir de la méthode MERISE 2.

Afin que ce document puisse être lu et compris aussi bien par une personne compétente dans

le domaine (un futur développeur) qu’une personne non initiée, nous avons complété chaque

partie de commentaires explicatifs.

PFE 2003 sur 20


c. Problèmes rencontrés

Le problème majeur que nous avons rencontré lors du déroulement de ce projet a été de

comprendre les objectifs de l’application dans son ensemble. En effet, même si les clients

avaient su exprimer clairement leurs attentes en terme de fonctionnalités globales, ils ne

pouvaient pas nous donner immédiatement de représentation précise de tous les aspects

pratiques de l’application. Ceux-ci se sont clarifiés au fur et à mesure de l’avancement de

l’analyse et de nos contacts, ce qui a eu plusieurs conséquences sur notre travail.

D’une part, des changements plus ou moins radicaux de certains points nous ont forcé à revoir

ces derniers en totalité.

D’autre part, lorsque nous émettions des propositions, ils devaient ensuite en discuter en

interne car ils ne pouvaient pas décider sur le moment de la solution la mieux adaptée.

Bien que toutes ces discussions et retours en arrière aient ralenti notre travail, ils ont permis, à

la fois pour le client, et pour nous de mieux cerner l’application dans son intégralité.

PFE 2003 sur 20


3. Bilan

D’un point de vue général, les échanges réguliers avec le client ont favorisé un transfert de

connaissances. Nous leur avons apporté des points de vues différents et variés sur la manière

de formaliser les concepts sous-jacents à leurs besoins et en contrepartie ils nous ont fait

découvrir l’aspect formel de réunions d’ordre professionnel.

Compte tenu de l’envergure du projet, nous nous sommes focalisés sur l’analyse afin de

produire un document d’analyse rigoureux. Ce dernier contient toutes les spécifications de

l’application et qui permet d’avoir une base solide avant de commencer la conception puis le

développement proprement dit du logiciel.

Le projet se poursuit : il sera terminé par l’un d’entre nous dans le cadre du stage de fin

d’étude de 3ème année pour une durée de 5 mois

PFE 2003 sur 20


Annexes

a. Planification

PFE 2003 sur 20


b. Comptes Rendus de Réunion avec le Client

Compte rendu de réunion du 29/11/2002

Personnes présentes : Les Clients : Mme Nathalie Moitrier

M. Philippe Clastre

L’équipe PFE :M. Jean Lamy M. Adrien BonnefoyM. Vanak OuchM. Jeremy Lussagnet

Ordre du jour : Prise de contact avec le client en vue de l’élaboration du cahier des charges.

LOGICIEL DE GESTION DE PARC INFORMATIQUE

Contexte

Les informaticiens sont en annexe de l’INRA. Pour l’instant il n’existe pas d’informaticien à temps plein (un poste devrait être créé prochainement).L’outil à réaliser sera destiné bien sûr à faciliter l’organisation de leur travail, et à leur faire économiser du temps au quotidien.

Objectifs du produit

Pourquoi veulent-ils ce produit ?- Pour en avoir la maîtrise totale ;- Pour qu’il soit totalement adapté à leurs besoins.

Le Produit en lui-même

Principe :

La fonction principale sera de gérer les PCs ainsi que le matériel informatique au sens large (périphériques, projecteur, etc…).L’interface du produit doit présenter un tableau de bord, c’est-à-dire permettre d’obtenir une vision globale du parc informatique. Une interface WEB facilitera l’apprentissage du logiciel par les utilisateurs.2 types de droits d’accès avec le logiciel :

- Administration : droit d’ajout/modification/suppression des données pour les administrateurs

- Consultation : permet de voir les données sans les modifier pour les utilisateurs

PFE 2003 sur 20


Possibilités :

Réservation de matériel :Un utilisateur pourra réserver un matériel pour une période donnéeChoisir entre deux méthodes :

o il effectue sa réservation directemento il fait une demande de réservation et un administrateur doit la confirmer

Localisation du matériel (carte)Les prises réseaux seront utilisés pour localiser le matériel connecté (ex : PC, Imprimante réseau). On sait à quel commutateur est relié une prise réseau (et sur quel port).Il existe aussi du matériel qui n’est pas toujours connecté (ex : vidéo projecteur).

Gestion de Logiciels et des LicencesL’outil doit permettre de savoir quels logiciels sont installés sur les machines.Il doit aussi intégrer la gestion des licences logicielles (notamment les licences à jetons) pour pouvoir vérifier qu’ils sont à jour.

InterventionsLorsqu’un dépannage est effectué sur un matériel par un administrateur du parc, le système permettra de d’enregistrer cette intervention avec tous les détails utiles (administrateur l’ayant effectué, date, descriptif).

Indications :

6 personnes du département informatique du CSE ont déjà travaillé sur le Modèle Conceptuel des Données, mais les idées pour le compléter sont les bienvenues.La gestion des utilisateurs n’est pas précisée en tant que fonctionnalité, elle est bien entendue implicite.Se mettre à la place d’un utilisateur pour rendre l’utilisation de l’application la plus simple possible.Le logiciel doit être évolutif afin de prendre en compte l’évolution future du parc.

Notes diverses :

- Le cahier des charges sera réalisé sous WORD pour le client (afin de faciliter l’ajout de remarques) et HTML pour l’IUP.

- La Base de Données utilisée par l’application sera à définir entre MySQL et PosgreSQL

- Le langage de développement sera PHP (possibilité d’achat de livres pour se documenter)

- Rédaction de manuel utilisateur et administrateur.- Rédaction d’une documentation technique.

Disponibilité du client pour future réunion : Les 3, 5, 9 décembre (penser à indiquer la date à laquelle on veut une réponse à notre

cahier des charges par mail).

PFE 2003 sur 20


Annexe du CR:

Les questions auxquelles on doit pouvoir répondre avec la base (fournies par le client)

CONSULTATION

Caractéristiques de micro

Général :- Liste des micro-ordinateurs- Liste des micro-ordinateurs connectés au réseau- Liste des portables- Liste des serveurs- Liste des micros (+nombre), dont la date d’achat est > x années. - Liste des micros qui sont sous garantie - Liste des micros dont les caractéristiques techniques sont (i.e. vitesse CPU < 100 / OS

== Windows 98 …) - Liste des micros de tel type ( description croisée : desktop et Windows98 )- Liste des micros utilisées par untel

Spécifique :

Caractéristique du micro-ordinateur

- de l’utilisateur X.- connecté sur la prise Y- qui s’appelle pclim28- situé dans le bureau 28 bâtiment 1- connecté sur le switch xx

Périphériques

Interventions

Quelles sont les interventions réalisées sur pclimxx- dans le service- dans le bâtiment 2- Liste du matériel en réparation- Liste des interventions en attente

Disponibilité

- Liste des micros disponibles à ce jour disponible pour une période d’utilisation prévue

- Peut-on prolonger la période d’utilisation de pclim28, de combien de temps

PFE 2003 sur 20


Logiciel

Général :

- Liste des logiciels- Liste des logiciels en fonction du type de licences

Spécifique :

- Liste des produits installés sur un poste- Sur quelle machine est installé tel produit- Combien de licences installées / achetées pour un produit

Utilisateur

Général :

- Liste les stagiaires- Liste des stagiaires pour une période donnée- Liste les stagiaires dont X est responsable- Liste les lieux ou sont les stagiaires de X- Liste les utilisateurs du bureau 200, sur la période xx au yy

Spécifique :

- Qui est responsable du stagiaire Durand- Qui administre pcsol28

MODIFICATION

Ajout/Suppression de toutes les données par les administrateurs de la base

PFE 2003 sur 20


Compte rendu de la réunion du 31/01/2002

Personnes présentes :

Mme Nathalie MoitrierM. Philippe ClastreM. Jean Lamy M. Adrien BonnefoyM. Vanak OuchM. Jeremy Lasagne

Ordre du jour : Présentation de la méthode d’analyse (UML)

Résoudre les problèmes et répondre aux interrogations le MCD

Choix de la base de données : PosgreSQL 7.3

Etape de l’Analyse à réaliser :

Prise en compte des acteurs : administrateur, utilisateursCas d’utilisations

Changement :

Elimination de la gestion des licencesLe logiciel KeyServer sera acheté pour gérer cette partie de façon indépendante.

Elimination de la gestion des logicielsA terme tous les logiciels seront installés sur chaque machine.

PFE 2003 sur 20


Questions sur le dernier mail :

Interventions : L’utilisateur qui remarque un problème le signale lui-même avec le logiciel

Question : quand un problème est déclaré qui doit répondre à la demande ? Réponse : Idée : un des responsables, mais on doit prendre en compte le fait qu’un responsable décide de prendre en charge la déclaration du problème avant de faire l’intervention.(le nom du responsable peut apparaître dans la déclaration du problème).

Proposition : - Un problème déclaré depuis un certain devrait être signalé par un code couleur différent (rouge par exemple pour les plus urgents).

- Prévoir un affichage d’aide à la déclaration du problème en fonction du composant.

- Présenter les détails du composant pour le validateur afin qu’il sache s’il est en mesure de résoudre ou non le problème (par exemple si c’est un problème sur une machine Linux et qu’il ne connaît que Windows).

- Quand un responsable consulte un problème et le prend en charge il met un titre au problème(type d’intervention à réaliser : réinstaller le disque dur,…)

- Prévoir le fait que certains problèmes soient non résolubles ( incapacité de traiter le problème,…).- Si un administrateur juge qu’un problème n’est pas de son ressort, il le supprime (aucune intervention n’est donc faite) et l’utilisateur ayant signalé ce problème doit être informé par mail que ce type de problème ne doit pas être signalé.

Gestion des réservations : Identification au moment où il fait une réservation. ( uniquement par adresse mail ).

Proposition : lorsqu’une réservation est faite par un utilisateur un mail de confirmation lui est envoyé avec un code aléatoire qui lui permettra de l’annuler / ou la modifier.

Cas des administrateurs : ils disposent d’une identification login + password.

Les composants

Un composant peut dépendre d’un autre. Permettra de le localiser plus facilement ( par exemple : un scanner).

Interface

La résolution du logiciel sera800x600.Pour la présentation des informations, nous sommes libres de faire une interface qui nous semble la plus approprié.Trois navigateurs devront être supportés: Mozilla, Internet Explorer, Netscape.

PFE 2003 sur 20


c. Exemples de Fonctions du Système

Les fonctions listées ci-dessous référent aux composants (ex : PC, Imprimantes, etc…)

Fonctions de baseC1. Enregistrer l’ajout d’un composantC2. Enregistrer la modification d’un composantC3. Supprimer un composantC4. Recherche multicritères des composants

par typepar caractéristiques proprespar emplacement (connexion au réseau)par réservationsous la responsabilité d’une personnepar problème

C5. Afficher un composant

Type de composant :C6. Enregistrer l’ajout d’un type de composantC7. Enregistrer la modification d’un type de composantC8. Supprimer un type de composantC9. Trouver le type d’un composant

Caractéristique de composant :C10. Enregistrer l’ajout d’un type de caractéristique de composantC11. Enregistrer la modification d’un type de caractéristique de composantC12. Supprimer un type de caractéristique de composantC13. Trouver les types de caractéristique d’un type de composantC14. Trouver la valeur de la caractéristique d’un composant Responsabilité Composant – Personne:C15. Enregistrer une personne comme responsable d’un composantC16. Trouver le responsable d’un composant s’il existeC17. Supprimer la responsabilité d’une personne pour un composant

Dépendance Composant – Composant:C18 Enregistrer une dépendance entre deux composantsC19. Supprimer la dépendance d’un composantC20. Trouver les composants dépendant d’un composant donnéC21. Trouver de quel composant dépend un composant donné

Divers :C22. Trouver la connexion d’un composant

PFE 2003 sur 20


d. Exemple de Diagramme de Cas d’Utilisation

PFE 2003 sur 20

Ce diagramme indique toutes les opérations que l’utilisateur peut effectuer.


e. Exemple de Cas d’Utilisation

Recherche de composants :Importance : PrimaireActeur impliqué : Utilisateur Pré condition : il faut qu’il y ait au moins un composantDétail :

Action de l’acteur Réponse du système1 demande de lister les composants 2 affiche le formulaire de recherche3 saisit les critères de recherche d’un composant et valide

4 SI la recherche aboutit ALORS afficher le(s) résultats, et proposer de :

- valider ou - quitter

allez en 10SINON propose :

- annuler - recommencer la recherche

allez en 55 annule ou recommence 6 SI ANNULE

ALORS fin processus 12SI RECOMMENCE aller 2

7 optionnellement Clique sur un résultat de la recherche

8 appelle le use case « Demander les détails d’un composant» (dans une pop up)

9. optionnellement Sélectionne un composant avec un bouton radio (par exemple) (option valable seulement lorsque ce use case est appelé depuis un autre)10. - Valide (sur un bouton OK) - Quitte

11. SI OK- SI rien n’est sélectionné alors fin

processus en 12- SINON retour au cas d’utilisation

appelant avec le composant sélectionné et fin processus

SI QUITTE fin processus en 12

12 FIN PROCESSUS

Fonctions couvertes :C4. Recherche multicritères des composants

par typepar caractéristiques proprespar emplacement (connexion au réseau)par réservationsous la responsabilité d’une personnepar problème

Toutes les fonctions de « Demander les détails d’un composant ».

PFE 2003 sur 20

PLAN RAPPORT PFEnicolas.ferrary.free.fr/rapport pfe final.doc · Web view2003-04-04 · Le...

Documents

Transcript of PLAN RAPPORT PFEnicolas.ferrary.free.fr/rapport pfe final.doc · Web view2003-04-04 · Le...