UN OUTIL DE SUIVI DE PROJET - Fabian Piaucv.fabianpiau.com/.../01...Projet_PMBox_Sylis_2009.pdf · UN OUTIL DE SUIVI DE PROJET. R. APPORT INTERMEDIAIRE. Projet du mercredi en entreprise

UN OUTIL DE SUIVI DE PROJET RAPPORT INTERMEDIAIRE Projet du mercredi en entreprise

Benjamin Foucot Elodie Guinet Loïc Nadji Emmanuel Peudon Fabian Piau Version 1.2

Projet PMBox

APPROBATION DES MEMBRES La signature des membres de l’équipe du projet signifie que le signataire a lu et approuvé le contenu de ce document.

Emmanuel NOCET Maître d’ouvrage

Fabian PIAU Maître d’œuvre

Benjamin FOUCOT Développeur

Elodie GUINET Développeur

Loïc NADJI Développeur

Emmanuel PEUDON Développeur

DOCUMENTS LIES

03_Annexes_Projet_PMBox_Sylis.doc Toutes les annexes du projet

SUIVI DES VERSIONS

1.0 Début Janvier 2009 Rapport intermédiaire

1.1 Fin Janvier 2009 Prise en compte des remarques d’Emmanuel Nocet

1.2 Début Février 2009 Suppression des annexes pour les mettre dans un dossier indépendant + quelques améliorations diverses

01 - Rapport intermédiaire Page 2 | 64

Projet PMBox

SOMMAIRE 1 ............................................................ 8 Présentation de SYLIS

1.1 ........................................................................... 8 Le groupe SYLIS1.1.1 ............................................................................................ 9 Historique1.1.2 ...................................................................... 9 Organisation du groupe1.1.3 .............................................................................................. 10 Chiffres1.1.4 ....................................................................................... 10 Perspectives1.1.5 ......................................................... 11 Les activités du groupe SYLIS

1.2 ............................................... 12 Organisation de SYLIS France1.2.1 ................................................................... 13 Le site SYLIS de Nantes1.2.2 ...................................................................................... 13 Pôle N.T.I.C.

2 .................................................... 14 Note de cadrage du projet2.1 ................................................................................ 14 Introduction

2.1.1 ............................................................................ 14 Rappel du contexte2.1.2 ............................................................................... 14 Origine du projet2.1.3 ....................................................... 15 Description succincte de l’étude

2.2 ........................................... 15 La portée et les limites de l’étude2.2.1 ............................................................................................. 15 Objectifs2.2.2 ........................................................................ 15 Les impacts du projet2.2.3 ....................................................................... 16 Les contours du projet2.2.4 ......................................................................... 17 Les risques du projet

2.3 ............................................................................. 17 L’organisation2.3.1 ................................................................ 17 Organigramme de l’équipe2.3.2 ........................................ 18 La démarche retenue pour l’avant-projet2.3.3 .................................................................... 18 Calendrier prévisionnel2.3.4 .......................................... 19 Création d’une plateforme collaborative2.3.5 .......................... 23 Interface de développement et outils collaboratifs

3 ..................................... 24 Phasage et planification du projet3.1 ............................................................................... 24 Les dates clés3.2 ................................................ 25 Les phases et étapes du projet3.3 ............................................ 27 Les différents livrables attendus3.4 .............................................................. 27 Planification du projet

4 ........................... 29 Cahier des charges fonctionnel général4.1 ......................................................... 29 Environnement du projet4.2 ..................................................................... 29 Etude de l’existant4.3 ............................................................................... 30 Les fonctions

4.3.1 .................................................................................. 30 Modèle général4.3.2 ............................................... 32 Description des principales fonctions

4.4 ................................................................................. 33 Les données4.4.1 .................................................................... 33 Description des données4.4.2 .......................................................................... 33 Reprise de l’existant


Projet PMBox

4.5 .................................................................................. 34 Contraintes4.5.1 ........................................................... 34 Contraintes d’environnement4.5.2 .......................................................... 34 Exigence de qualité de service4.5.3 ................................................................... 34 Contraintes d’ergonomie4.5.4 ................................. 34 Contraintes et exigences liées à l’exploitation

5 ......................................................... 35 Document avant projet5.1 ................................................ 35 Analyse de la solution retenue

5.1.1 ...................................................... 35 Description de la mise en œuvre5.1.2 ............................................................. 35 Condition de mise en œuvre

5.2 ............................................................................. 36 L’organisation6 ............................... 37 Dossier d’analyse technique détaillée

6.1 ................................... 37 Architecture technique de la solution6.1.1 .............................................................. 38 Couche DAO ou persistance6.1.2 ................................................................................... 38 Couche service6.1.3 ............................................................. 38 Couche web ou Présentation

6.2 ................................................................................. 40 Les données6.2.1 .............................................. 40 La relation entre PMBox et TeamBox6.2.2 ........................................... 40 Récupération des données de TeamBox6.2.3 ........................................................ 41 Révision du modèle de données

6.3 ................................................................................. 42 Les modules6.3.1 ........................................................... 42 Le module « Administration »6.3.2 .................................................... 46 Le module « Gestion des risques »6.3.3 ................................................ 52 Le module « Suivi des événements »

6.4 .................................................................................... 57 Les écrans6.4.1 ........................................ 57 Les écrans du module « Administration »6.4.2 .................................. 59 Les écrans du module « Gestion des risques»6.4.3 ............................... 63 Les écrans du module « Suivi des événements»


Projet PMBox

LISTE DES FIGURES

Figure 1 – Implantation géographique du groupe SYLIS ...................................... 8

Figure 2 – Organigramme du groupe SYLIS .......................................................... 9

Figure 3 – Répartition du CA par secteur au 31/12/2007 ..................................... 10

Figure 4 – Répartition du chiffre d'affaires par activité ....................................... 11

Figure 5 – Organigramme de SYLIS France ......................................................... 12

Figure 6 – Secteur d'activité des clients ................................................................ 12

Figure 7 – Organigramme de l’agence de Nantes ................................................. 13

Figure 8 – Organigramme de l’équipe ................................................................... 18

Figure 9 – Accueil du groupe Google « PMBox » ................................................... 20

Figure 10 – Wiki « Planning » ................................................................................ 21

Figure 11 – Wiki « FAQ » ........................................................................................ 21

Figure 12 – Wiki « Liste des fichiers » ................................................................... 22

Figure 13 – Wiki « How-to utiles » ......................................................................... 23

Figure 14 – Le diagramme de Gantt du projet ...................................................... 25

Figure 15 – Tableau récapitulatif du diagramme de Gantt ................................. 26

Figure 16 – Quelques explications sur le SAPA .................................................... 28

Figure 17 – Architecture 3-Tier de PMBox ........................................................... 37

Figure 18 – Principe de fonctionnement du Framework Struts ........................... 39

Figure 19 – Les relations entre TeamBox et PMBox au niveau des données ..... 41

Figure 20 – Cas d’utilisation du module Administration ..................................... 42

Figure 21 – Diagramme d’activité de ADMIN-CU01 ............................................ 43



Figure 24 – Cas d'utilisation du module Risques .................................................. 46

Figure 25 – Activité RISQUE-CU01-AC02 : Consulter un risque ....................... 48

Figure 26 – Activité RISQUE-CU01-AC03 : Ajouter un risque ........................... 48

Figure 27 – Activité RISQUE-CU01-AC04 : Modifier un risque .......................... 49

Figure 28 – Activité RISQUE-CU02-AC02 : Consulter une action du PRR ........ 50

Figure 29 – Activité RISQUE-CU02-AC03 : Ajouter une action au PRR ............ 51

Figure 30 – Activité RISQUE-CU02-AC04 : Modifier une action du PRR .......... 52

Figure 31 – Cas d'utilisation du module Evénements .......................................... 53


Projet PMBox

Figure 32 – Activité EVENEMENT-CU01-AC03 : Ajouter un incident .............. 55

Figure 33 – Activité EVENEMENT-CU01-AC04 : Modifier un incident ............. 56

Figure 34 – Activité EVENEMENT-CU07-AC05 : Supprimer un document ...... 56

Figure 35 – Ecran de connexion à l’application..................................................... 57

Figure 36 – Ecran de recherche d’un projet .......................................................... 57

Figure 37 – Liste des fonctionnalités concernant un projet ................................. 58

Figure 38 – Ecran de suivi des risques .................................................................. 59

Figure 39 – Ecran de consultation d'un risque ..................................................... 59

Figure 40 – Ecran d'ajout d'un risque .................................................................... 60

Figure 41 – Ecran de modification d'un risque ..................................................... 60

Figure 42 – Ecran de suivi des PRR ...................................................................... 61

Figure 43 – Ecran de consultation d'une action d'un PRR ................................... 61

Figure 44 – Ecran d'ajout d'une action à un PRR ................................................. 62

Figure 45 – Ecran de modification d'une action d'un PRR ................................... 62

Figure 46 – Ecran de suivi des incidents ............................................................... 63

Figure 47 – Ecran de consultation d’incidents ...................................................... 63

Figure 48 – Ecran d’ajout d’incidents .................................................................... 64

Figure 49 – Ecran de modification d’incident ........................................................ 64


Projet PMBox

LISTE DES TABLES

Table 1 – Les risques du projet .............................................................................. 17

Table 2 – Les actions et les livrables ..................................................................... 18

Table 3 – Calendrier prévisionnel .......................................................................... 19

Table 4 – Cas d’utilisation ADMIN-CU01 : Connexion à PMBox ........................ 43

Table 5 – Cas d’utilisation ADMIN-CU02 : Recherche d’un projet ...................... 44

Table 6 – Cas d’utilisation ADMIN-CU03 : Gestion d’un projet .......................... 45

Table 7 – Cas d’utilisation RISQUE-CU01: Risques ............................................ 47

Table 8 – Cas d’utilisation RISQUE-CU02: Plan de réduction des risques ......... 49

Table 9 – Cas d’utilisation EVENEMENT-CU01: Suivi des événements ............ 53


Projet PMBox

1 PRESENTATION DE SYLIS

1.1 LE GROUPE SYLIS

Le groupe SYLIS est une Société de Services et d’Ingénierie Informatique (SSII) créée en 1984. Il possède le statut de société anonyme à conseil d’administration.

Comme vous pouvez le voir sur la figure 1, le groupe est présent en France, en Belgique, au Luxembourg ainsi qu’aux Pays-Bas. Il possède un effectif d’environ 1 700 personnes. Son siège social est situé à Lambersart (département 59, près de Lille).

- 9 agences en France ; - 3 agences en Belgique ; - 1 filiale au Luxembourg ; - 1 filiale aux Pays-Bas.

Figure 1 – Implantation géographique du groupe SYLIS


Projet PMBox

1.1.1 Historique

La société SYLIS SA est créée en 1984.

En 1997, elle est introduite sur le second marché de la bourse de Paris et à partir de 1998, le groupe profite de la conjoncture favorable pour assurer son développement, notamment par une méthode de croissance externe. Il acquiert donc successivement différentes SSII jusqu’en 2000.

En 2004, la fusion des 4 filiales françaises forme SYLIS France. Il s’en suit une nouvelle direction générale en 2005.

Puis, c’est une étape de consolidation et de recentrage des activités autour du service, notamment avec la session de la filiale S.B.S. dédiée aux solutions ERP pour les PME en 2006.

1.1.2 Organisation du groupe Le groupe SYLIS est une holding regroupant les différentes sociétés SYLIS

européennes ainsi que les sociétés acquises par croissance externe. SYLIS France est implanté sur 12 sites, regroupés géographiquement en trois zones : Ile de France (IDF), Manche Atlantique Méditerranée (MAM), Nord-est/Sud-est (NESE).

SYLIS Holding

• B lles ruLi

xe• è ge • Gand

• Luxembourg • Rotterdam

• Lille • Strasbourg • Metz • Lyon

• Nantes • Bordeaux • Toulouse • Aix en Provence

• Paris

SY ISL Pays- Bas

Zone IDFZone MAM

SYLIS France

Zone NESE

SYLIS Belgique

SYLIS Luxembourg

Figure 2 – Organigramme du groupe SYLIS


Projet PMBox

1.1.3 Chiffres

Le groupe SYLIS possède un capital de 1 932 213,40 € (pour l’année 2007).

Le chiffre d’affaires pour l’exercice 2007 est en augmentation par rapport à 2006 pour atteindre 138 millions d’euros. C’est le meilleur exercice depuis 5 ans et les objectifs de SYLIS ont été revus à la hausse en 2008.

Le groupe compte environ 1 740 personnes en 2007.

Figure 3 – Répartition du CA par secteur au 31/12/2007

1.1.4 Perspectives Aux vues de ses bons résultats, voici les différents objectifs que s’est fixés le

groupe pour la période 2008 :

• Optimiser les coûts de structure ;

• Fidéliser, attirer, gérer les ressources informatiques ;

• Maintenir et améliorer les prix de vente ;

• Différencier l’offre ;

• Elargir le fond de commerce.


Projet PMBox

1.1.5 Les activités du groupe SYLIS

Le groupe propose à ses clients quatre types de prestations :

• Le conseil et l’expertise :

Accompagner les maîtrises d’ouvrage et maîtrises d’œuvre dans les mutations métiers des systèmes d’information pour servir au mieux les évolutions stratégiques des entreprises.

• La gestion des systèmes d’information :

Accompagner les maîtrises d’œuvre dans le cadre de la gestion de l’évolution et la maintenance des systèmes d’information.

• L’exploitation des systèmes d’information :

Accompagner l’exploitation, la production, l’infogérance globale, l’outsourcing, les normes et méthodes des systèmes d’information en place.

• La gestion des infrastructures :

Accompagner la conception, le déploiement, et la maintenance des infrastructures systèmes et postes de travail.

Ces activités se répartissent le chiffre d’affaires de la façon suivante :

Figure 4 – Répartition du chiffre d'affaires par activité


Projet PMBox

1.2 ORGANISATION DE SYLIS FRANCE

La société SYLIS France est la plus grande société détenue par le groupe SYLIS. Le chiffre d’affaires réalisé par SYLIS France représentait 69% du chiffre d’affaires du groupe en 2007.

Sur l’organigramme, Figure 5, nous observons que sont centralisées dans la holding SYLIS, la « Direction Marketing et communication », la « Direction Juridique et des Ressources Humaine », ainsi qu’une « Direction Financière ». La Direction Qualité est rattachée à SYLIS France, qui est d’ailleurs certifiée ISO 9001. Enfin, SYLIS France possède sa propre Direction du Système d’Information.

DACFrance

Centres Nationaux de Services

D.S.I.

SYLIS Holding

SYLIS France Président

SYLIS France Directeur Général

Marketing & Communication

Direction Qualité

Zone IDFD.G. Adjoint

Zone NESED.G. Adjoint

Zone MAMD.G. Adjoint

Direction Financière

DirectionJuridique & RH

Figure 5 – Organigramme de SYLIS France

Le chiffre d’affaires de Sylis France se trouve réparti parmi les différents secteurs d’activité de ses clients avec les proportions suivantes :

Figure 6 – Secteur d'activité des clients


Projet PMBox

Parmi les principaux clients de SYLIS France, nous pouvons nommer, respectivement du plus important au moins important, en termes de chiffre d’affaires : PSA, l’UNEDIC, le Crédit Agricole, Groupama-GAN, ARCELOR, MSA, France Télécom, Société Générale, etc.

1.2.1 Le site SYLIS de Nantes Nantes concentre principalement ses activités sur la Tierce Recette Applicative

(ce terme regroupe toutes les méthodes mises en œuvre dans l'optique d'améliorer la qualité d'une application), mais possède aussi un pôle Nouvelles Technologies de l’Information et de la Communication.

Parmi ses principaux clients, nous retrouvons PSA, l’UNEDIC, la SNCF, la Poste, banques et assurances présentes sur le secteur, etc.

L’agence de Nantes compte 115 personnes dont 39 nouvelles en 2007 ce qui montre bien qu’elle développe ses activités. Vous trouverez sur la figure suivante l’organisation de l’agence de Nantes.

NTIC

Gestion commerciale Direction Normes Méthode Outils Qualité et projets

Offre TMA/TDA

Ing. commercial

Collaborateurs

Pôle Opérationnel Pôle Commercial

Direction Agence

Pôle Administratif

Figure 7 – Organigramme de l’agence de Nantes

1.2.2 Pôle N.T.I.C. Notre projet du mercredi se déroule au sein du pôle Nouvelles Technologies de

l’Information et de la Communication (N.T.I.C.) de Nantes, spécialisé dans la conception et la réalisation d’application principalement basées sur les technologies Java J2EE.


Projet PMBox

2 NOTE DE CADRAGE DU PROJET

2.1 INTRODUCTION

2.1.1 Rappel du contexte Ce stage se déroule d’octobre 2008 à mars 2009, il est intégré dans la formation

continue de la MIAGE de Nantes. A raison d’un jour par semaine en entreprise, nous devons travailler en équipe sur un projet informatique.

Ainsi, tous les mercredis, nous nous réunissons dans les locaux de Sylis Nantes pour mener à bien notre projet.

L’équipe est constituée de quatre étudiants en M1, ils sont chargés de la réalisation des tâches (étude de l’existant, développement, test et aussi une phase de spécification) ; ils sont les principales ressources du projet. L’équipe compte également un étudiant en M2 qui s’occupe de la gestion du projet : la planification des tâches, la communication avec le MOA, la remontée des informations du MOA vers l’équipe et inversement, la coordination des activités, le respect du planning, les prévisions dans l’avancement, etc. Il a aussi un rôle d’assistant envers les M1 pour les aider à réaliser leurs tâches. L’étudiant en M2 est, en quelque sorte, un chef de projet junior. Sylis Nantes a été certifiée ISO 9001 en octobre 2007. L’objectif pour l’année 2008 est d’étendre le périmètre de certification aux autres agences de la région « Manche Atlantique Méditerranée » (MAM) à savoir Bordeaux, Aix et Toulouse. Afin de faciliter ce déploiement, la zone MAM souhaite automatiser les procédures propres à la norme ISO 9001 autour des outils utilisés ou à utiliser, en particulier au sein des Centres de Services du groupe. C’est dans ce contexte que ce projet a été instauré.

2.1.2 Origine du projet Le projet est récent, il s’agit du développement d’une application interne de

gestion de projet nommée « PMBox » (Project Management toolBOX). En quelques mots, « PMBox » est une application web à usage interne qui permet de gérer et de suivre les différents projets. L’application a commencé à être développée par un stagiaire au sein de l’agence de Toulouse, durant l’été 2008. Aujourd’hui, l’application n’a pas encore été finie et n’est donc pas encore opérationnelle. Pour satisfaire ses besoins internes, Sylis Nantes a décidé de reprendre et continuer ce projet. Cette tâche nous a été confiée.


Projet PMBox

2.1.3 Description succincte de l’étude Notre travail s’organise en deux grandes phases.

Une première phase correspondant à la montée en connaissance et compétence sur l’application (installation sur les postes, rédaction de la documentation d’installation qui est inexistante, découverte des technologies et frameworks utilisés, modèle en couches, etc.). Il y a une véritable étude de l’existant à faire. La seconde phase correspond à la maintenance technique de l’application (organisée sous forme de lots qui contiennent différents modules). Actuellement, uniquement l’analyse des modules a été réalisée, notre équipe doit continuer le « processus » de développement en passant par toutes les étapes traditionnelles (spécification, développement, test, intégration, recette).

2.2 LA PORTEE ET LES LIMITES DE L’ETUDE

2.2.1 Objectifs L’objectif de cette application est l’automatisation du suivi de projet, ceci passe

par le traçage de l’information, des contrôles réguliers et rigoureux, la restitution de documents de suivis.

Le développement de « PMBox » va être effectué en plusieurs phases appelées lot (voir p. 30 et 31). Comme énoncé précédemment, l’application existe et le lot 1 a été en partie développé, mais l’application est très instable et souffre de lacunes. En effet, de nombreux bogues sont présents, des liens vers des fonctionnalités inexistantes, le code source ne respecte pas toutes les contraintes internes de Sylis (conventions de codage, documentation, etc.).

Les contraintes de temps étant très fortes (nous disposons de 20 jours ce qui équivaut à 100 jours-homme), le but n’est pas de développer toute l’application en mettant en œuvre les quatre lots, ce ne serait tout simplement pas possible.

L’objectif a été initialement défini comme étant la maintenance technique du lot 1 ainsi que le développement du lot 2. Après l’étude de l’existant et aux vues de la charge de travail très conséquente sur le lot 1, l’objectif a été corrigé.

Notre objectif est donc de revoir tout le lot 1 afin de livrer une application fonctionnelle, stable, opérationnelle et documentée pour que les personnes qui reprendront le projet « PMBox » après nous puissent développer les lots restants sans difficulté majeure.

2.2.2 Les impacts du projet Actuellement Sylis ne dispose pas d’un outil homogène et référencé de gestion

des évènements projet. Les données d’un projet sont reparties entre plusieurs fichiers de types différents stockés dans divers répertoires. Il existe par exemple de nombreux tableaux au format Excel et documents Word pour les plannings du projet, la saisie des


Projet PMBox

charges consommées, les consignes du projet. Ainsi, le suivi de projet est difficile, les saisies se font manuellement ce qui est contraignant et coûteux du point de vue temps ; de plus, il ne peut pas y avoir de contrôles stricts. Il est donc nécessaire de se doter d’un outil permettant d’automatiser le suivi de projet. En fait, une application de gestion de projet existe déjà au sein de l’entité. Elle se nomme « TeamBox », mais elle ne répond pas à toutes les demandes de l’agence de Nantes. Par exemple certaines fonctionnalités comme la gestion des événements ou la gestion des risques sur un projet n’ont pas été prévue. Les raisons pour lesquelles « TeamBox » n’a pas été modifié directement pour ajouter ces fonctionnalités viennent du fait que :

- « TeamBox » a été développé par une autre agence Sylis à destination de toutes les autres agences. « Teambox » est donc utilisé à l’échelle nationale. Modifier « TeamBox » aurait un impact très important.

- Les besoins diffèrent suivant les agences. Ainsi, l’agence de Lille n’a pas besoin de ces fonctionnalités additionnelles qui seraient, pour elle, une charge d’information supplémentaire.

C'est pourquoi « PMBox » sera développé et utilisé à Nantes avant tout. Si d’autres agences sont intéressées par les nouvelles fonctionnalités, elles pourront à leur tour utiliser « PMBox ».

2.2.3 Les contours du projet Sous forme d’application web, cet outil est principalement destiné aux directeurs

de projet et chefs de projet leur permettant un suivi complet des projets internes et projets à engagement de résultat. L’idée est qu’ils puissent l’exploiter chez leurs clients.

Les utilisateurs de « PMBox » seront, dans un premier temps, les chefs et directeurs de projet de Sylis Nantes. Une fois l’application développée avec tous les lots, il est tout à fait possible qu’elle soit utilisée à une échelle nationale si les utilisateurs de Sylis de Nantes l’utilisent quotidiennement et en sont pleinement satisfaits. Après, ce sera une question de « publicité » vers les autres agences.

Ce projet implique une étude approfondie de l’existant:

- Installation des environnements de développement sur chacun des postes. Nous allons voir ce qui existe, tester les fonctionnalités, voir ce qui ne va pas, voir ce qu’il faut refaire, etc.

- Documentation. Comment installer « PMBox » du point de vue développeur ? La documentation n’existe pas encore. Nous allons nous charger de sa rédaction. Cette documentation d’installation inclut une documentation et des références sur Tomcat, Postgres, Eclipse, CheckStyle, Tortoise SVN qui sont les outils utilisés pour le développement de « PMBox ». Cette documentation doit s’appuyer sur un modèle Word Sylis fourni. Elle sera à destination des futurs développeurs qui seront amenés à travailler sur les lots 2, 3 et 4.

- Exécution et test de l’application. Il y a une compréhension du code (Frameworks Hibernate, Struts, modèle en couches, etc.).


Projet PMBox

- Retrospécification. La spécification actuelle n’est pas à jour et ne respecte pas toutes les normes internes de Sylis. L’objectif est donc de re-versionner selon le nouveau modèle de spécification.

Une fois cette étude terminée, nous commencerons la seconde grande phase qui est la mise en conformité et stabilisation technique. Cette phase de développement doit respecter des conventions de codage interne Sylis et inclus l'application d'une charte graphique fournie par Sylis. Ce projet étant amené à être repris par d’autres développeurs, la qualité de la documentation et du code est très importante.

2.2.4 Les risques du projet Voici un tableau résumant l’ensemble des risques liés au projet. Nous devons les

minimiser autant que possible.

Conséquence Type de contrainte

Description

Faible Connaissance Nous ne connaissons pas très bien les frameworks Struts, les outils de collaboration tels SVN (en particulier les M1) et Hibernate (équipe)

il faut un temps pour se familiariser avec ces outils Elevé Temporelle La découverte de l’application, l’étude de l'existant et la mise en

compétence ne doivent pas prendre trop de temps Très élevé Taille et contenu

du projet Les conventions de codage n’ont pas été très respectées (beaucoup de points à revoir selon l’audit de qualité) L’application actuelle est autonome alors qu’elle devrait utiliser des données existantes (modèle des données à revoir) Modification en profondeur des requêtes Hibernate

beaucoup de modification à faire dans le code source

Table 1 – Les risques du projet

2.3 L’ORGANISATION

2.3.1 Organigramme de l’équipe Voici un organigramme résumant la hiérarchie entre les membres de l’équipe

ainsi que les relations avec les responsables de projet chez Sylis. Le chef de projet junior a un rôle central dans cette organisation, il s’occupe de faire remonter et descendre l’information entre l’équipe et le maître d’ouvrage.


Projet PMBox

Figure 8 – Organigramme de l’équipe

2.3.2 La démarche retenue pour l’avant-projet

Actions à mener

Résultats et livrables attendus

Analyse de l’existant - Documentation d’installation

- Retrospécification du lot 1 (3 modules :

Admin, Risques, Evénements)

Analyse des besoins - Cahier des charges

- Conception fonctionnelle

- Conception technique

Implémentation - Modèle de données

- Code source de l’application

Table 2 – Les actions et les livrables

2.3.3 Calendrier prévisionnel

Numéro de semaine

Jour de travail

Commentaire

1 semaine 41 mercredi 8 octobre 2 semaine 42 mercredi 15 octobre 3 semaine 43 mercredi 22 octobre 4 semaine 44 mercredi 29 octobre 5 semaine 45 mercredi 5 novembre 6 semaine 46 mercredi 12 novembre

Benjamin Foucot Développeur

Fabian Piau Maitre d’œuvre M2 MIAGE

Loïc Nadji Développeur M1 MIAGE

Elodie Guinet Développeur M1 MIAGE

Emmanuel Peudon Développeur M1 MIAGE

Emmanuel Nocet Maitre d’ouvrage Sylis

M1 MIAGE


Projet PMBox

7 semaine 47 mercredi 19 novembre 8 semaine 48 mercredi 26 novembre 9 semaine 49 mercredi 3 décembre

10 semaine 50 mercredi 10 décembre 11 semaine 51 mercredi 17 décembre X semaine 52 mercredi 24 décembre Vacances de Noël X semaine 1 mercredi 31 décembre Vacances de Noël X semaine 2 mercredi 7 janvier Semaine d'examen pour les M1 12 semaine 3 mercredi 14 janvier 13 semaine 4 mercredi 21 janvier 14 semaine 5 mercredi 28 janvier 15 semaine 6 mercredi 4 février 16 semaine 7 mercredi 11 février 17 semaine 8 mercredi 18 février 18 semaine 9 mercredi 25 février 19 semaine 10 mercredi 4 mars 20 semaine 11 mercredi 11 mars X semaine 12 mercredi 18 mars Date prévisionnelle de

soutenance

Table 3 – Calendrier prévisionnel

Le projet aura lieu tous les mercredis dans les locaux de Sylis dans le centre-ville de Nantes (sauf période de vacances).

Il y aura donc, en tout, 20 mercredis en entreprise consacrés au projet, 3 mercredis chômés et 1 dernier mercredi sera consacré à notre soutenance orale.

2.3.4 Création d’une plateforme collaborative Le groupe « PMBox » a été créé pour le projet. Ce groupe de discussion hébergé gratuitement par Google permet de centraliser toutes les informations autour du projet. En quelques mots, un groupe est une plateforme collaborative disponible sur internet où les utilisateurs peuvent s’échanger des messages, des fichiers, etc.

Voici les fonctionnalités que nous utilisons :

- Espace de stockage de fichiers ; - Les wikis (système de gestion de contenu modifiable par l’ensemble des

utilisateurs inscrit au groupe) ; - Envoi d’emails à une liste de diffusion (utilisateurs inscrits au groupe).


Projet PMBox

Voici quelques copies d’écran de notre plateforme collaborative pour mieux comprendre ce dont il s’agit :

Figure 9 – Accueil du groupe Google « PMBox »


Projet PMBox

Quatre thèmes de wiki ont été créés pour faciliter la gestion du projet et la coordination entre les membres de l’équipe. Ils sont regroupés au sein de la rubrique « Pages ».

- « Planning » : une version simplifiée du SAPA avec des liens directs vers les livrables et le SAPA (voir p. 27 - 28 pour des explications sur le SAPA).

Figure 10 – Wiki « Planning »

- « FAQ » : l'ensemble des questions et réponses demandées à nos responsables Sylis. Certaines réponses peuvent être utiles à plusieurs membres de l’équipe, cela permet donc une centralisation de la connaissance.

Figure 11 – Wiki « FAQ »


Projet PMBox

- « Liste des fichiers » : La liste des liens (avec une courte description pour chacun) vers tous les fichiers présents sur l’espace de stockage du groupe. Les fichiers sont classés suivant plusieurs catégories (Planning, Schéma de données, Documentation, Retrospécification, Développement, Rapport MIAGE). Ce wiki a été créé du fait qu’il n’est pas possible d’organiser les fichiers dans des répertoires. Il est donc facile de s’y perdre quand il y a un nombre de fichiers conséquent.

Figure 12 – Wiki « Liste des fichiers »


Projet PMBox

- « How-to utiles » : Cette page regroupe les liens vers des tutoriaux trouvés sur internet et concernant les outils que nous serons amenés à utiliser (frameworks, logiciels).

Figure 13 – Wiki « How-to utiles »

2.3.5 Interface de développement et outils collaboratifs Nous allons utiliser de nombreux outils très variés pour ce projet de gestion des projets. Voici les principaux outils que nous utiliserons lors du développement de l’application :

Eclipse / Tomcat pour le développement J2EE

L’application sera développée sous l’environnement de développement intégré Eclipse Europa 3.3.

Eclipse IDE est un environnement de développement intégré libre extensible, universel et polyvalent, permettant potentiellement de créer des projets de développement mettant en œuvre n'importe quel langage de programmation. Eclipse IDE est principalement écrit en Java, et ce langage, grâce à des bibliothèques spécifiques, est également utilisé pour écrire des extensions.

La spécificité d'Eclipse IDE vient du fait de son architecture totalement développée autour de la notion de plug-in : toutes les fonctionnalités de cet atelier logiciel sont développées en tant que plug-in.

Les langages sont d'ores et déjà supportés (la plupart grâce à l'ajout de plug-ins), parmi lesquels : Java, C#, C++, C, PHP, Javascript, XML, HTML, SQL, etc.


Projet PMBox

Le serveur d’application utilisé est Tomcat en version 5.5. Il s’agit d’un des projets libres de la fondation Apache.

Le code source de l’application « PMBox » nous a été fourni. Nous utilisons un dépôt SVN pour partager les sources. Les outils collaboratifs, reliés au dépôt, seront les suivants :

Subclipse

Subclipse est un plug-in Eclipse open source gratuit pour le système de contrôle de version Subversion. C'est-à-dire que Subclipse gère des fichiers et des répertoires à travers le temps. En effet, ce logiciel se base sur le concept client/serveur afin de pouvoir gérer les différentes versions. Ainsi, un dépôt servant de référentiel est déployé sur le serveur SVN. Chaque membre de l’équipe utilise une copie locale (sur leur poste de travail) de ce dépôt pour effectuer ses modifications. Une fois ces modifications fonctionnelles, la personne propage les changements sur le dépôt (avec un message textuel résumant les modifications), ce qui créé une nouvelle révision. Ce système de révision est pratique, car il est possible de revenir à une ancienne révision à tout moment.

Trac

Nous allons utiliser également l’outil Trac qui est un système de gestion de projet par internet.

Il comprend un wiki, un rapport de bogues (anomalies), un historique, un gestionnaire de feuille de route ainsi qu’un explorateur Subversion. Il est très utile pour suivre le développement d’un projet informatique et s’avère nécessaire pour faire un développement propre et productif.

3 PHASAGE ET PLANIFICATION DU PROJET

3.1 LES DATES CLES

Le projet du mercredi débute le 8 octobre 2008 par la découverte de l’entreprise et du projet « PMBox » et s’achève le 18 mars 2009 par une soutenance oral de l’équipe accompagné de nos responsables chez Sylis et responsables universitaires.


Projet PMBox

3.2 LES PHASES ET ETAPES DU PROJET

Voici le diagramme de Gantt du projet accompagné de son tableau récapitulatif. Il a été réalisé avec MS Project.

Figure 14 – Le diagramme de Gantt du projet


Projet PMBox

Figure 15 – Tableau récapitulatif du diagramme de Gantt


Projet PMBox

3.3 LES DIFFERENTS LIVRABLES ATTENDUS

Sur le diagramme de Gantt, nous représentons les trois jalons principaux par une étoile rouge. Ils correspondent à des rendus de livrables ; dans l’ordre chronologique, nous avons :

- Livraison de la documentation d’installation (22 octobre 2008) ; - Livraison des rétrospécifications (10 décembre 2008) ; - Livraison de l’application avec le lot 1 développé et fonctionnel (25 février 2009).

3.4 PLANIFICATION DU PROJET

Pour planifier le projet, nous utilisons, en complément du diagramme de Gantt, un document interne de Sylis : le SAPA (Suivi d’Avancement Par Activité).

Un SAPA est établi chaque mois et reprend les données du SAPA du mois précédent. Au mois d’octobre, le SAPA n’était pas très précis, il s’est amélioré progressivement pour englober toutes les informations du projet à partir du mois de décembre.

Le SAPA est un tableau Excel, nous y retrouvons les informations indispensables pour la planification du projet comme les étapes, les tâches avec les ressources affectées. Des informations comme l’avancement des tâches, des statistiques sur les tâches et les ressources sont également présentes.

Ce document permet aux responsables Sylis de suivre l’avancement du projet. Il nous permet également de bien planifier notre projet. Contrairement au diagramme de Gantt, il n’y a pas d’aspect visuel, mais les informations sont très complètes et de plus, il est facilement manipulable et modifiable. Nous avons donc privilégié cet outil de planification.


Projet PMBox

Voici un extrait du SAPA pour le mois de décembre avec quelques explications. Vous trouverez les SAPAs (d’octobre à décembre) complets en annexe.

Cartouche, informations sur le projet

Les différentes activités du projet Code couleur correspondant à la granularité du projet :

- Projet - Etape - Sous-étape - Tâche

Figure 16 – Quelques explications sur le SAPA

Le numéro de semaine

Les croix symbolisent une semaine chômée Consommé du mois

Reste à faire Total consommé à la fin du mois précédent (pris sur le SAPA du mois précédent) Total consommé ( + )

Ecart. C’est la différence entre (le consommé du mois + le reste à faire) et la durée estimée ( + - ) Avancement réel de la tâche (en %)

Autres statistiques

Durée totale estimée

Durée totale révisée (C’est la durée estimée à laquelle on ajoute des jours dans le cas d’une évolution par exemple)

La personne affectée à une tâche (représentée par 3 lettres : première lettre de son prénom suivi des deux premières lettres de son nom)


Projet PMBox

4 CAHIER DES CHARGES FONCTIONNEL GENERAL

4.1 ENVIRONNEMENT DU PROJET

Au sein de l’entreprise, nous avons travaillé sur 3 postes de travail : un pour le chef de projet (Fabian), et un par binôme (Benjamin-Loïc et Elodie-Emmanuel). Deux autres postes seront peut-être mis à disposition en début d’année si cela est nécessaire pour le développement, sinon nous continuerons en « Pair-Programming ». Chaque poste est équipé des environnements suivants :

- Environnement de développement : Eclipse 3.3 (logiciel de développement Java), équipé du plugin Clay Database Modeling, permettant de créer un modèle de base de données et de générer le code de création de celui-ci, ainsi que le plug-in Subclipse, permettant le travail collaboratif. Le JDK (kit de développement Java) utilisé est le JDK 1.6.

- Moteur JSP-Servlet : Apache Tomcat 5.5

- Base de données : PostgreSQL 8.0.4, système de gestion de base de données libre.

Pour nous aider dans la réalisation de l’application, nous utiliserons divers frameworks (de présentation : Struts, et de persistance : Hibernate). Nous les expliquerons plus en détail lorsque nous présenterons l’architecture technique de l’application.

4.2 ETUDE DE L’EXISTANT

Nous ne sommes pas repartis de zéro dans le développement de l’application « PMBox ». En effet, un stagiaire de Toulouse avait déjà commencé à travailler sur l’application. Nous sommes donc repartis de son code et de ses documents.

Voici un bref bilan réalisé sur l’existant de l’application à partir de l’audit réalisé par Sylis, de notre utilisation de l’application et de la lecture des documents. Seuls les points négatifs sont retenus ici, c’est ceux qu’il faudra corriger.

- Ergonomie : La majeure partie de l’IHM a été créée. Les pages nécessaires sont pour la plupart existantes. Cependant, nous avons remarqué un certain nombre de problèmes de navigation entre les pages : liens erronés (dû à des liens relatifs), pages inexistantes.

- Maintenabilité : La documentation n’a pas été créée (Javadoc, outils permettant de générer la documentation à partir des commentaires dans le code). Les logs ne sont pas générés pour suivre les traces de l’application (utile pour le débogage). L’architecture générale n’est pas respectée (séparation en plusieurs couches de service qui respecte le modèle MVC). Les conventions de nommage ne sont pas toujours respectées.


Projet PMBox

- Performances : Absence des logs (même remarque que précédemment). Absence d’index dans la base de données, qui permettraient de réduire le temps d’accès aux données dans le cas où il y en aurait beaucoup.

- Stabilité : Absence de blocs « try-catch » pour gérer les exceptions. Non-respect de l’architecture générale (même remarque que précédemment). Absence de contrôle de certaines règles de gestion. Mauvaise utilisation des clés primaires et clés étrangères.

- Données : Au niveau données, l’application est totalement indépendante, alors qu’elle est censée reprendre une partie des données de « TeamBox » : tables des utilisateurs et des projets en particulier. Cependant, il est logique, en phase de développement, de tester l’application sur une base de données indépendante, en cas d’erreurs.

En dehors de l’application, il existait déjà les documents de spécification des modules. Il nous a été demandé de refaire ces documents, car il existait des incohérences entre ce qui était demandé, ce qui était décrit dans ces documents, et ce qui était mis en application dans le code et le schéma de la base de données. Il nous a également fallu revoir le schéma de la base de données qui n’était pas totalement cohérent non plus avec ce qui était demandé, et qui ne prenait pas en compte le fait que l’application allait reprendre des données de « TeamBox ».

4.3 LES FONCTIONS

4.3.1 Modèle général L’application est organisée en quatre lots. Ils seront développés au fur et à

mesure. Chaque lot est organisé en un ou plusieurs modules.

Lot 1

Incidents

Décisions

Réunions

Livrables

Documentation

Actions

Avenants

Module « Suivi des événements »

Plan de réduction des

risques

Module « Gestion des risques »

Evaluation des

risques

Description des

risques


Projet PMBox


Menu principal après sélection

d’un projet Liste des projets

Accueil

Module « Administration-Accueil »

Lot 2

Restitution graphique et

Génération des tableaux de

bord

Suivi des livrables

Suivi des délais

Suivi des demandes de maintenance

Respect du PQP

Respect des

processus

Indicateurs ISO

Respect du

planning

Lot 3

Suivi du coût

Suivi des charges

Suivi et contrôle du projet

Emission des

alertes

Gestion des alertes

Paramétrage des

alertes

Lot 4

Gestion des exigences

Analyse et

référencement des exigences

Gestion des liens entre exigences

Gestion des

changements d’exigences

Gestion des liens avec le PBS

Génération des

tableaux de bord

Suivi de l’évolution budgétaire

Création d’une Gestion des accès Base Salaire

Lot 1 : Lot 2 : Lot 3 : Lot 4: Separation des lots:

Projet PMBox

Pour le projet, nous nous intéresserons au premier lot qui comporte trois modules :

- le module « Suivi des événements » ; - le module « Gestion des risques » ; - le module « Administration-Accueil ».

4.3.2 Description des principales fonctions Le Lot 1 comprend le suivi des évènements, la gestion des risques ainsi que le

module administration de l’application.

Module 1 : Suivi des événements

Le module suivi des événements a pour but de conserver de façon chronologique les traces des différents échanges avec le client (et échanges internes). Il permet de regrouper l’ensemble des événements relatifs à un projet.

Les types d’évènements suivis sont :

- Les incidents ; - Les réunions ; - Les décisions ; - Les actions ; - Les avenants ; - Les livrables ; - La documentation.

L’utilisateur aura la possibilité de :

- Consulter les listes des évènements relatifs à un projet, classées par type d’évènement ;

- Modifier ou enregistrer de nouveaux événements liés à un projet ; - Exporter les données au format Excel ou PDF ; - Accéder rapidement aux documents associés à un évènement.

Module 2 : Gestion des risques Le module gestion des risques a pour but de suivre l’ensemble des risques

relatifs à un projet et les plans de réduction des risques associés.

L’utilisateur aura la possibilité de :

- Consulter les listes des risques relatifs à un projet ; - Modifier ou enregistrer de nouveaux risques liés à un projet ; - Exporter les données au format Excel ou PDF ; - Accéder rapidement aux documents associés à un risque.


Projet PMBox

Module 3 : Administration - Accueil

Le module administration et accueil de l’application a pour but :

‐ D’authentifier l’utilisateur depuis le formulaire de l’écran de connexion ; ‐ D’afficher la liste de tous ses projets en cours et terminés ; ‐ D’accéder au menu de gestion d’un projet après sélection d’un projet dans sa liste.

Le nom de module « Administration » peut faire penser qu’il permettra l’administration de l’application, c'est-à-dire la gestion des utilisateurs, de leurs droits, profils, etc., mais en fait il s’agit de l’administration des projets (affichage, sélection). La gestion des utilisateurs est faite depuis « TeamBox ».

4.4 LES DONNEES

4.4.1 Description des données « PMBox » sera indépendante des autres applications au niveau matériel et

logiciel, mais « PMBox » ne sera pas indépendante au niveau des données. En effet, elle devra avoir accès aux données de l’application « TeamBox » en lecture.

L’application « PMBox » utilise donc des données externes provenant de l’application « TeamBox ». Elle utilise également ses propres données contenues dans sa base de données. Il faut donc mettre en relation les données de ces deux applications. La difficulté supplémentaire vient du fait que l’application « PMBox » a été développée comme si elle était complètement indépendante de « TeamBox ». Le modèle de données doit donc être revu en profondeur, et à fortiori le code des requêtes Hibernate correspondantes.

4.4.2 Reprise de l’existant Comme énoncé précédemment, l’application « PMBox » est actuellement

indépendante de l’application « TeamBox ». Cela signifie que chaque application possède sa propre base de données. Il y a donc duplication de certaines informations (utilisateurs, projets, etc.) pouvant conduire à des incohérences (modifications de la base « TeamBox » non répercutées sur « PMBox »). Afin d’éviter cela, nous aurions pu relier les deux applications et leurs bases de données, mais afin de conserver l’indépendance de « TeamBox » nous avons opté pour une autre solution. Nous allons réaliser des « vues » de « TeamBox ». Cela veut dire que nous allons créer des requêtes permettant de faire des copies de certaines informations de « TeamBox ». Ces copies sont sous forme de tables et seront inclues dans la base « PMBox ». Elles seront accessibles uniquement en lecture puisque nous souhaitons seulement avoir l’accès aux données de « TeamBox » sans pouvoir les modifier. De cette manière, nous allons pouvoir reprendre les données de l’application « TeamBox » sans les modifier (ensemble cohérent) et en conservant une relative indépendance entre les deux applications (« TeamBox » reste complètement autonome avec sa propre base de données).


Projet PMBox

4.5 CONTRAINTES

4.5.1 Contraintes d’environnement

Un ou plusieurs liens vers l’application « PMBox » doivent être mis en place depuis l’application « TeamBox ». L’utilisation de données issues de « TeamBox » d’une part et la création de données propres à la nouvelle application d’autre part, peuvent poser le problème de l’intégrité des données.

4.5.2 Exigence de qualité de service - Nécessite la disponibilité du serveur d’applications Tomcat ; - Nécessite la disponibilité de la base de données PostgreSQL. Exigences en termes de résistance à la charge et temps de réponse - Implémentation des bonnes pratiques de conception d’application Web ; - Optimisation des accès aux données ; - Conception de pages Web légères ; - Utilisation de Frameworks éprouvés.

Exigences en termes de disponibilité

L’application devra être disponible 24h/24h - 7j/7j.

Exigences en termes de sécurité

Les personnes non autorisées ne peuvent pas accéder au système. Les utilisateurs autorisés à accéder au système ont des habilitations sur les fonctionnalités de l’application.

4.5.3 Contraintes d’ergonomie

L’ergonomie de la nouvelle application web devra respecter les normes du groupe Sylis et sera soumise à validation par la MOA Sylis.

4.5.4 Contraintes et exigences liées à l’exploitation Exigences de supervision

L’application devra être livrée accompagnée d’un dossier d’exploitation et d’un manuel d’utilisation afin de d’assurer de sa bonne mise en service ainsi que de sa supervision.


Projet PMBox

5 DOCUMENT AVANT PROJET

5.1 ANALYSE DE LA SOLUTION RETENUE

5.1.1 Description de la mise en œuvre Description fonctionnelle

L’objectif du lot 1 est de développer trois modules :

‐ Suivi des événements : ce module sert à avoir un historique des différents échanges avec le client et permet de regrouper l’ensemble des évènements liés à un projet.

‐ Gestion des risques : ce module sert à recenser l’ensemble des risques liés à un projet et à établir des plans de réduction de risques.

‐ Administration : ce module permet l’authentification des utilisateurs, l’affichage de la liste de tous les projets (qu’ils soient en cours ou terminés), et l’accès au menu de gestion d’un projet une fois que ce dernier a été sélectionné.

Description technique

L’application PMBox sera sous la forme d’une application Web J2EE et devra respecter les normes du groupe Sylis.

Le fait de développer une application web (client léger) et non un client lourd facilite le déploiement. En effet, une application web est installée uniquement sur le serveur, contrairement aux clients lourds qui doivent être installés sur les machines de chaque utilisateur. Pour utiliser PMBox, les utilisateurs auront donc seulement besoin de leur navigateur Internet. De la même manière, lors de la sortie d’une nouvelle version ou d’une mise à jour de l’application web, elle n’aura besoin d’être installée qu’une seule fois, sur le serveur, et non sur tous les postes client.

5.1.2 Condition de mise en œuvre

Nous avions à notre disposition seulement 3 ordinateurs, nous avons donc réalisé 3 équipes, Benjamin et Loïc se sont mis ensemble, de même que Elodie et Emmanuel. Fabian disposait d'un ordinateur pour lui seul, ce qui lui permettait de faire son travail de développeur, et également son travail de chef de projet. Avant de commencer le projet, nous devions réaliser l'installation de tous les logiciels nécessaires au développement de l'application. En parallèle de l'installation des outils, nous devions rédiger les notices d'installation. Cette méthode est employée à Sylis afin de pouvoir rapidement modifier l'application en cas de problème en évitant la perte de temps liée aux problèmes d'installation et aux réglages des logiciels.


Projet PMBox

Afin de faciliter la communication entre chaque membre de l'équipe, Fabian a créé un groupe sur Google groups. Il contient un espace de stockage qui permet de déposer et de récupérer la documentation liée au projet, de laisser des messages à l'ensemble du groupe, etc. Fabian a également mis en place une FAQ (Foire aux Questions) afin de partager l'expérience au sein de l’équipe ; par exemple les difficultés rencontrées et les solutions associées. Notre objectif est de terminer le lot 1, c'est-à-dire le module de suivi des événements, de gestion des risques et d'administration-accueil. Pour cela, il fallait tout d'abord effectuer une rétrospécification. Il s'agissait de reprendre la spécification, réalisée par l'équipe de développement de Toulouse, pour la remettre en conformité avec les nouveaux standards de Sylis. Nous devions également revérifier les documents et corriger les erreurs avec l'aide d'Emmanuel Nocet qui était présent pour répondre à toutes nos questions. Après la phase de rétrospécification, nous devions passer à la phase de développement. Nous devions reprendre l'application existante, pour corriger les bogues et terminer le lot 1 en nous aidant des nouvelles spécifications. Nous avions également une autre contrainte : nous devions respecter le concept MVC. Il s'agit de séparer le code en trois parties distinctes : le Modèle (la base de données), la Vue (l'affichage des pages à l'écran) et le contrôleur (qui fait l'intermédiaire entre la vue et les données). Nous expliquerons les concepts de ce modèle lorsque nous présenterons l’architecture technique de l’application dans la partie suivante. Cette séparation en couche permet une plus grande réutilisabilité et une maintenance du code facilitée. Cependant, le modèle MVC n'a pas toujours été respecté, nous devons donc reprendre une grande partie du code afin de l’appliquer.

5.2 L’ORGANISATION

Le projet PMBox a été commencé en 2008 par un stagiaire de l'équipe de développement de Toulouse. Ce stagiaire a réalisé toute la spécification du lot 1 (suivi des événements, gestion des risques et accueil-administration) puis a commencé le développement de l'application. A la fin de son stage, il n’a pas pu terminer le lot 1 par manque de temps. Le projet a alors été confié à Sylis Nantes afin d'être achevé. Actuellement le projet est sous la direction de Guillaume Kasiborski (Directeur de projet) et Emmanuel Nocet (Chef de projet). Ainsi, ce sont eux qui nous encadrent et c'est en particulier Emmanuel Nocet qui répond à nos questions et nous guide dans la spécification et le développement de l'application. Une fois que nous aurons achevé le développement du lot 1, l'application sera confiée à deux équipes :

‐ La première, l'équipe de recettage, aura pour rôle de tester l'application afin de relever les bogues et dysfonctionnements de l'application et de nous les faire remonter pour correction.

‐ La seconde équipe, l'équipe d'intégration, a pour but de finaliser l'application afin de la rendre indépendante et prête à l'usage.


Projet PMBox

6 DOSSIER D’ANALYSE TECHNIQUE DETAILLEE

6.1 ARCHITECTURE TECHNIQUE DE LA SOLUTION

L’architecture technique globale de l’application est une architecture 3-Tier, de type MVC (Modèle Vue Contrôleur). Ce modèle logique d'architecture applicative vise à séparer très nettement trois couches logicielles au sein d'une même application ou système, à modéliser et présenter cette application comme un empilement de trois couches, étages, niveaux ou strates dont le rôle est clairement défini :

‐ la présentation des données : correspondant à l'affichage, la restitution sur le poste client, le dialogue avec l'utilisateur.

‐ le traitement métier des données : correspondant à la mise en œuvre de l'ensemble des règles de gestion et de la logique applicative.

‐ et enfin l’accès aux données persistantes : correspondant aux données qui sont destinées à être conservées sur la durée, voire de manière définitive.

Ces trois couches sont traitées par le serveur d’application tandis que l’enregistrement des données persistance se fait sur le serveur de base de données.

Figure 17 – Architecture 3-Tier de PMBox


Projet PMBox

6.1.1 Couche DAO ou persistance

La couche persistance contient toutes les méthodes permettant d’accéder aux objets persistants de l’application. Cette couche est composée de DAO (Data Access Object) qui encapsulent tout le code SQL nécessaire à la manipulation de la base de données.

La manipulation des données nécessite l’utilisation d’un outil de mapping objet-relationnel. Hibernate est le framework utilisé pour PMBox.

Hibernate

Travailler dans les deux « univers » que sont l'orienté objet et la base de données relationnelle peut être lourd et consommateur en temps. Hibernate se propose de joindre ces deux univers, à travers le mapping objet/relationnel. Le terme mapping objet/relationnel (ORM) décrit la technique consistant à faire le lien entre la représentation objet des données et sa représentation relationnelle, basée sur un schéma SQL.

Hibernate s'occupe du transfert des classes Java dans les tables de la base de données (et des types de données Java dans les types de données SQL). Il permet également de requêter les données et propose des moyens de les récupérer.

Nous pouvons voir Hibernate comme une fine surcouche de JDBC qui lui ajouterait une dimension objet. JDBC est une API (c.-à-d. un ensemble de fonctions) permettant aux programmes Java d'accéder à des bases de données.

6.1.2 Couche service

Cette couche contient l'ensemble du code métier de l'application, elle organise et orchestre les accès à la couche DAO et ses aspects transactionnels.

6.1.3 Couche web ou Présentation

C’est la couche d'entrée dans l'application du point de vue du client. Elle appelle les traitements de la couche Service en fonction des actions effectuées par le client et récupère les données retournées. Elle met ensuite en forme ces données pour les afficher au client.

Struts

Struts est un framework servant à développer des applications Web utilisant des Servlets et des JSP. Il permet d'implémenter simplement le modèle MVC. Nous pouvons schématiser une telle application Web de la manière suivante:


Projet PMBox

Figure 18 – Principe de fonctionnement du Framework Struts

Informations supplémentaires sur JSP et les servlets (Sources : © Wikipedia)

JSP (Java Server Pages) est une technologie basée sur Java qui permet aux développeurs de générer dynamiquement du code HTML, XML ou tout autre type de page web. La technologie permet au code Java et à certaines actions prédéfinies d'être ajoutés dans un contenu statique. La syntaxe du JSP ajoute des balises XML, appelées actions JSP, qui peuvent être utilisées pour appeler des fonctions. De plus, la technologie permet la création de bibliothèques de balises JSP (taglib) qui agissent comme des extensions au HTML ou au XML. Les bibliothèques de balises offrent une méthode indépendante de la plate-forme pour étendre les fonctionnalités d'un serveur HTTP. Les JSP sont compilées par un compilateur JSP pour devenir des servlets Java.

Une servlet est une application Java qui permet de générer dynamiquement des données au sein d'un serveur HTTP. Ces données sont le plus généralement présentées au format HTML, mais elles peuvent également l'être au format XML ou tout autre format destiné aux navigateurs web. Ce programme Java s'exécute dynamiquement sur le serveur web et permet l'extension des fonctions de ce dernier comme l’accès à des bases de données. Une servlet peut être chargée automatiquement lors du démarrage du serveur web ou lors de la première requête du client. Une fois chargées, les servlets restent actives dans l'attente d'autres requêtes du client. L'utilisation de servlets se fait par le biais d'un conteneur de servlets côté serveur. Celui-ci constitue l'environnement d'exécution de la servlet et lui permet de persister entre les requêtes des clients.

L'utilisation de Struts se justifie pleinement pour le développement des grosses applications Web pour lesquelles l'implémentation du modèle MVC est un gage de réutilisabilité et d'extensibilité (malgré son coût en termes de temps de développement et de performances). La structure de l’application rend, en effet, simple la réutilisation de portions de code et l’ajout de nouvelles fonctionnalités.


Projet PMBox

6.2 LES DONNEES

6.2.1 La relation entre PMBox et TeamBox Les applications « PMBox » et « TeamBox » sont très liées. « PMBox » est en fait

une amélioration de « TeamBox » dans le sens où il va lui ajouter des fonctionnalités (gestion des risques, suivi des événements, indicateurs, etc.). Malgré le fait que « PMBox » peut être lancé de manière indépendante, « PMBox » peut être vu comme un « plug-in », car il reste dépendant des données fournies par « TeamBox ». En effet, « PMBox » a besoin de la liste des utilisateurs et de la liste des projets. « PMBox » devra donc avoir accès aux données de l’outil « TeamBox » en lecture.

6.2.2 Récupération des données de TeamBox Voici comment nous allons gérer les interactions avec « TeamBox » : dans le

schéma de « PMBox », il faudra créer des vues sur les tables de « TeamBox » dont nous avons besoin (utilisateur, projet). Ces vues auront les mêmes caractéristiques que les tables de « TeamBox » dont elles sont issues. Nous ne prendrons que les champs qui correspondent aux données qui nous intéressent. Par exemple, la table « projet » de « TeamBox » contient beaucoup d’information qui ne sera pas utilisée par « PMBox ». Les vues permettent de gérer facilement cela ainsi que les contraintes de lecture seule.

Les fonctionnalités supplémentaires de « PMBox » auront besoin de leurs propres tables, il faudra donc créer ces tables (table « risque », « type risque », etc.).

Lors de la phase de développement, nous créerons des tables à la place des vues, avec les mêmes données que « TeamBox ». Lors de la phase d’intégration, nous créerons et connecterons les vues « PMBox » aux vraies tables de « TeamBox ». Cette manipulation sera caractérisée par la modification du fichier de configuration d’Hibernate dû aux modifications du schéma de données. Ce changement sera totalement transparent pour l’application et ne devra pas apporter de régression. Ainsi, « PMBox » utilisera son schéma de données qui contiendra ses propres tables (accès en lecture/écriture) et les vues sur les tables de « TeamBox » (accès en lecture).


Projet PMBox

Voici un diagramme schématisant les relations entre les deux applications et la base de données. Base de

données

Accès SQL (lecture/écriture) Accès SQL

(lecture/écriture sur les tables + lecture sur les vues)

Schéma TeamBox

Schéma PMBox

Application PMBox

Application TeamBox

Vues

Figure 19 – Les relations entre TeamBox et PMBox au niveau des données

L’application « TeamBox » va fournir les données suivantes à « PMBox » :

‐ Information sur les utilisateurs ; ‐ Information sur les projets.

Si les données sont fournies, les fonctionnalités correspondantes resteront sous « TeamBox » (et ne seront pas utilisables depuis « PMBox »):

‐ La gestion des utilisateurs (gestion des mots de passe, des droits, ajout, suppression et modification d’utilisateur, etc.) ;

‐ La gestion des projets (ajout, suppression, modification, affectation, etc.). « PMBox » permettra de gérer les projets, mais à un second niveau :

‐ Rechercher un projet ; ‐ Gestion des risques et événements sur un projet.

6.2.3 Révision du modèle de données L’application « PMBox » a déjà été développée (lot 1), mais sans prendre en

compte les interactions avec « TeamBox ». Il n’y a aucun lien entre les deux applications. C'est-à-dire qu’actuellement, « PMBox » utilise ses tables avec leurs propres caractéristiques. « PMBox » possède donc sa propre table « projet », sa propre table « utilisateur », etc. Une difficulté supplémentaire vient du fait que ces tables ne sont pas en concordance avec celles de « TeamBox » (attributs manquants ou de noms différents, attributs à prendre dans des tables différentes, etc.), nous devons donc revoir cela. Vous trouverez en annexe le modèle de données actuel de « PMBox ».


Projet PMBox

6.3 LES MODULES

6.3.1 Le module « Administration »

Description du module

Le module « Administration-accueil » correspond à l’affichage des projets de l’utilisateur connecté. L’ensemble des projets est importé depuis « TeamBox ».

Une fois connecté, c’est cette première page qui s’affiche. L’utilisateur aura la possibilité de filtrer la liste de ses projets selon différents critères. Il pourra également sélectionner un projet et accéder à la gestion des risques et des événements associés à ce projet.

Acteurs du module Tous les utilisateurs ont accès à l’écran de connexion de « PMBox », mais

uniquement les utilisateurs connectés ont accès à la page d’accueil de l’application contenant la liste de ses projets ainsi qu’à toutes les pages qui en découlent.

Les cas d’utilisation

Figure 20 – Cas d’utilisation du module Administration


Projet PMBox

Cas d’utilisation ADMIN-CU01: Connexion à PMBox

Description L’utilisateur se connecte à l’application

Acteurs L’utilisateur Evénement déclenchant L’utilisateur lance l’application Pré-conditions - Post-conditions L’utilisateur est « en mémoire » et l’affichage des écrans

suivants correspond à cet utilisateur (Liste de ses projets) Concurrence d’accès - Cas d’échec ou Exception Le login ou mot de passe est incorrect, l’écran de

connexion est réaffiché

Table 4 – Cas d’utilisation ADMIN-CU01 : Connexion à PMBox

Figure 21 – Diagramme d’activité de ADMIN-CU01

Pour vérifier l’existence du login et du mot de passe, nous utilisons la vue sur la table « utilisateur » du schéma de « TeamBox ».

Si la recherche n’a pas retourné d’utilisateur correspondant au login et mot de passe saisis (l’utilisateur n’existe pas dans l’application, le login et le mot de passe ne correspondent pas ou encore le format saisi n’est pas valide), le système affiche un message d’erreur.

Si la recherche retourne un utilisateur, nous mettons l’identifiant, le nom et le prénom de l’utilisateur en session.


Projet PMBox

Cas d’utilisation ADMIN-CU02: Recherche d’un projet dans la liste

Description L’utilisateur recherche un projet

Acteurs L’utilisateur Evénement déclenchant - Pré-conditions L’utilisateur s’est authentifié avec succès Post-conditions Un projet est sélectionné, ce projet est « en mémoire » et

les sous-menus du projet s’y réfèrent automatiquement. Concurrence d’accès - Cas d’échec ou Exception Le cas « Aucun projet ne correspond aux critères saisis »

ne peut avoir lieu, car il n’y a pas de recherche par saisie de numéro de projet, mais une sélection de filtres et de tris sur les projets existants.

Table 5 – Cas d’utilisation ADMIN-CU02 : Recherche d’un projet

Utilisation de filtres, de tris, boutons page précédente,

suivante

Lien « deconnexion »

ADMIN-CU02-AC01: rechercher un

projet

ADMIN-CU02-AC02: Se

déconnecter

Utilisation de filtres, de tris, boutons page précédente,

suivante


Si l’utilisateur change des critères de recherche, affiche la page précédente/suivante du tableau de projets ou modifie le nombre de lignes par page, l’écran est rechargé. Les données du tableau sont rafraîchies en respectant les nouveaux critères.

Si l’utilisateur se déconnecte, la session est supprimée et l’utilisateur est ramené à l’écran de connexion.


Projet PMBox

Cas d’utilisation ADMIN-CU03: Gestion d’un projet sélectionné

Description L’utilisateur choisit le type de suivi de projet qu’il

souhaite afficher (suivi des risques, suivi des événements, etc.)

Acteurs L’utilisateur Evénement déclenchant Pré-conditions L’utilisateur a sélectionné un projet Post-conditions L’utilisateur a accès à la page principale du projet qui

permet d’afficher ses caractéristiques et d’accéder aux différentes fonctionnalités de gestion de projet (incluses dans les lots 1)

Concurrence d’accès - Cas d’échec ou Exception -

Table 6 – Cas d’utilisation ADMIN-CU03 : Gestion d’un projet

Sélection d’un projet

Lien « deconnexion »

ADMIN-CU03-AC01: Gérer un

projet

ADMIN-CU03-AC02: Se

déconnecter


Si l’utilisateur choisit un projet, les paramètres de celui-ci doivent être affichés à l’écran.


Projet PMBox

6.3.2 Le module « Gestion des risques »

Description du module Le module gestion des risques a pour but de suivre l’ensemble des risques

relatifs à un projet et le plan de réduction des risques associé.

En effet, un projet possède une liste de risques. A chaque risque est attaché un Plan de Réduction des Risques (PRR) qui contient l’ensemble des actions à faire pour prévenir, limiter ou corriger ce risque.

Le module est donc divisé en deux parties, la gestion des risques et la gestion des PRR. Chaque partie a des fonctionnalités similaires : le suivi, la consultation, l’ajout et la modification.

Nous accédons à la gestion des risques à partir du menu d’un projet. Une fois entré, l’écran de suivi des risques apparaît. Il est possible d’atteindre la gestion du PRR d’un risque, soit par l’onglet PRR, en choisissant dans une liste déroulante le risque concerné, soit par un lien situé au niveau de chaque risque de la liste de suivi des risques.

Acteurs du module Seuls les utilisateurs membres de l’équipe travaillant sur ce projet sont habilités

à consulter les suivis des risques pour ce projet.

Pour un projet donné, seuls les utilisateurs ayant le profil de Directeur de projet ou Chef de projet seront habilités à enregistrer ou modifier les informations concernant la gestion des risques.


RISQUE-CU01: Risques RISQUE-CU02: Plans de réduction des risques

Utilisateur

Etend

Figure 24 – Cas d'utilisation du module Risques


Projet PMBox

Cas d’utilisation RISQUE-CU01: Risques

Description L’utilisateur visualise la liste des risques relatifs à un projet.

Acteurs L’utilisateur Evénement déclenchant Clic sur « Gestion des risques » ou clic sur l’onglet

« Risques » de « Gestion de risques » Pré-conditions L’utilisateur est connecté. Post-conditions - Concurrence d’accès - Cas d’échec ou Exception -

Table 7 – Cas d’utilisation RISQUE-CU01: Risques

Ce cas d'utilisation comporte quatre activités différentes, qui sont le suivi des risques, la consultation, l'ajout et la modification d'un risque. Nous allons détailler ci-après chacune de ces activités.

Activité RISQUE-CU01-AC01 : Suivre les risques

Cette fonctionnalité permet de consulter l’ensemble des risques d’un projet sous forme d’un tableau. Il contient la référence, la cause, le type d’impact, la criticité et l’état de chaque risque. De plus, chaque ligne possède des liens afin d’accéder à d’autres pages. Il y a un lien « modifier », un lien « consulter », et un lien au niveau de la référence du risque qui permet également de le consulter. C’est aussi au niveau de cette page qu’un risque peut être ajouté.

Activité RISQUE-CU01-AC02 : Consulter un risque

Nous accédons à cette fonctionnalité à partir du suivi des risques, en cliquant sur le lien « consulter » ou en cliquant sur la référence du risque à consulter. Cela permet de voir l’intégralité des informations d’un risque, puisque certaines données ne sont pas présentes dans le tableau de suivi des risques.

À partir de cet écran, il est possible d’accéder directement à la modification d’un risque en utilisant le bouton « modifier », ou bien retourner au suivi des risques en utilisant le bouton « Retour ».


Projet PMBox

Figure 25 – Activité RISQUE-CU01-AC02 : Consulter un risque

Activité RISQUE-CU01-AC03 : Ajouter un risque

Cette fonctionnalité permet d’ajouter un risque au projet. Elle est accessible depuis le suivi des risques d’un projet par le lien « Ajouter un risque ». Afin d’ajouter le risque, il faut renseigner les champs du formulaire de la page.

L’ajout se fait si les champs obligatoires sont renseignés. Dans ce cas, la référence du risque est générée automatiquement en fonction de la dernière référence enregistrée et l’application retourne au suivi des risques. Dans le cas où l’utilisateur valide alors que certains champs obligatoires ne sont pas remplis, l’ajout n’est pas réalisé et un message d’erreur apparaît.

Figure 26 – Activité RISQUE-CU01-AC03 : Ajouter un risque


Projet PMBox

Activité RISQUE-CU01-AC04 : Modifier un risque

Cette fonctionnalité permet de modifier un risque du projet. Elle est accessible depuis le suivi des risques d’un projet par le lien « modifier » ou par un bouton depuis la consultation d’un risque. Lors de l’affichage de l’écran, les informations du risque sont affichées, il est alors possible de les modifier.

La modification se fait si les champs obligatoires ne sont pas vides. Dans ce cas, la modification est prise en compte et l’application retourne au suivi des risques. Dans le cas où l’utilisateur valide alors que certains champs obligatoires ne sont pas remplis, la modification n’est pas réalisée et un message d’erreur apparaît.

Figure 27 – Activité RISQUE-CU01-AC04 : Modifier un risque

Cas d’utilisation RISQUE-CU02: Plan de réduction des risques

Description L’utilisateur visualise le plan de réduction des risques.

Acteurs L’utilisateur Evénement déclenchant Clic sur le lien « PRR » depuis le suivi des risques ou sur

l’onglet « Plan de réduction des risques » Pré-conditions L’utilisateur est connecté. Post-conditions - Concurrence d’accès - Cas d’échec ou Exception -

Table 8 – Cas d’utilisation RISQUE-CU02: Plan de réduction des risques


Projet PMBox

De même que le cas d'utilisation précédent, celui-ci comporte quatre activités différentes. Ces activités sont le suivi des PRR, la consultation, l'ajout et la modification d'une action d'un PRR. Nous allons détailler ci-après chacune de ces activités.

Activité RISQUE-CU02-AC01 : Suivre le plan de réduction des risques

Le suivi d’un PRR d’un risque se fait de deux manières. Nous pouvons parvenir directement au PRR d’un risque en cliquant sur « lien vers PRR » correspondant au risque souhaité dans la page de suivi des risques. Il est également possible d’utiliser l’onglet « PRR » puis choisir à l’aide d’une liste déroulante le risque voulu.

Le suivi d’un PRR est réalisé à l’aide d’un tableau. Il contient les références, les libellés, les responsables, les priorités et les états des actions d'un PRR. De plus de même que pour le suivi des risques, chaque ligne possède des liens afin d’accéder à d’autres pages. Il y a un lien « modifier » qui permet d'apporter des modifications à une action, un lien « consulter » et un lien au niveau de la référence du risque qui permettent de consulter une action du PRR. C’est aussi au niveau de cette page qu’une action peut être ajoutée.

Activité RISQUE-CU02-AC02 : Consulter une action du PRR

Nous accédons à cette fonctionnalité à partir du suivi des PRR, en cliquant sur le lien « consulter » ou en cliquant sur la référence de l'action à consulter. Cela permet de voir l’intégralité des informations d’une action, puisque certaines données ne sont pas présentes dans le tableau de suivi des risques.

À partir de cet écran, nous pouvons accéder directement à la modification d’une action en utilisant le bouton « modifier », ou bien retourner au suivi des PRR en utilisant le bouton « Retour ».

Figure 28 – Activité RISQUE-CU02-AC02 : Consulter une action du PRR

Activité RISQUE-CU02-AC03 : Ajouter une action au PRR


Projet PMBox

Cette fonctionnalité permet d’ajouter une action à un PRR. Elle est accessible depuis le suivi des PRR d’un risque par le lien « Ajouter une action ». Afin d’ajouter l'action, il faut renseigner les champs du formulaire de la page.

L’ajout se fait si les champs obligatoires sont renseignés. Dans ce cas, la référence de l'action est générée automatiquement en fonction de la dernière référence enregistrée et l’application retourne au suivi des PRR. Dans le cas où l’utilisateur valide alors que certains champs obligatoires ne sont pas remplis, l’ajout n’est pas réalisé et un message d’erreur apparaît.

RISQUE-CU02-AC01 : Suivre les actions du PRR

RISQUE-CU02-AC03 : Ajouter une

action au PRR

Renseignement des champs et clic sur le bouton « valider »

RISQUE-CU02-AC03-R10RISQUE-CU02-AC03-R11

RISQUE-CU02-AC03-M01

Figure 29 – Activité RISQUE-CU02-AC03 : Ajouter une action au PRR

Activité RISQUE-CU02-AC04 : Modifier une action du PRR

Cette fonctionnalité permet de modifier une action d'un PRR. Elle est accessible depuis le suivi des PRR d’un risque par le lien « modifier » ou par un bouton depuis la consultation d’une action. Lors de l’affichage de l’écran, les informations de l'action sont affichées, il est alors possible de les modifier.

La modification se fait si les champs obligatoires ne sont pas vides. Dans ce cas, la modification est prise en compte et l’application retourne au suivi des PRR. Dans le cas où l’utilisateur valide alors que certains champs obligatoires ne sont pas remplis, la modification n’est pas réalisée et un message d’erreur apparaît.


Projet PMBox

Figure 30 – Activité RISQUE-CU02-AC04 : Modifier une action du PRR

6.3.3 Le module « Suivi des événements »

Description du module Le module suivi des événements a pour but de conserver de façon chronologique

les traces des différents échanges avec le client (et échanges internes). Il permettrait aussi d’accéder aux dossiers en indiquant le chemin d’accès ou en créant un lien direct. Cette fonctionnalité permettrait aux collaborateurs de retrouver rapidement un document même lorsqu’ils sont en déplacement.

Les événements pris en compte sur un projet sont les suivants : Incidents, Réunions, Décisions, Avenants, Actions, Livrables, et Documentation.

Le module est divisé en sept parties, prenant chacun en charge un type d’évènement. Chaque partie a des fonctionnalités similaires : le suivi, la consultation, l’ajout et la modification. Il existe également une fonction de suppression pour la documentation (afin de ne pas surcharger le serveur). Nous accédons au suivi des événements à partir du menu d’un projet. Une fois entré, l’écran de suivi des incidents apparaît. Il est possible d’atteindre le suivi des autres événements par des onglets situés au-dessus du tableau de suivi.

Acteurs du module Seuls les utilisateurs membres de l’équipe travaillant sur ce projet sont habilités

à consulter les suivis des événements pour ce projet.

Pour un projet donné, seuls les utilisateurs ayant le profil de Directeur de projet ou Chef de projet seront habilités à enregistrer ou modifier les informations concernant les événements.


Projet PMBox


Figure 31 – Cas d'utilisation du module Evénements

Cas d’utilisation EVENEMENT-CU01: Suivi des incidents

Les informations suivantes donnent le fonctionnement du cas d’utilisation EVENEMENT-CU01. Les autres cas d’utilisation, excepté le CU07 (option suppression supplémentaire), sont similaires.

Description L’utilisateur peut visualiser, ajouter, modifier ou consulter les incidents

Acteurs L’utilisateur Evénement déclenchant Clic sur « Incidents » Pré-conditions L’utilisateur a sélectionné le suivi des évènements Post-conditions - Concurrence d’accès - Cas d’échec ou Exception -

Table 9 – Cas d’utilisation EVENEMENT-CU01: Suivi des événements


Projet PMBox

Ce cas d'utilisation comporte quatre activités différentes, qui sont le suivi des incidents, la consultation, l'ajout et la modification d'un incident. Nous allons détailler ci-après chacune de ces activités.

Activité EVENEMENT-CU01-AC01 : Suivi des incidents

Cette fonctionnalité permet de consulter l’ensemble des incidents d’un projet sous forme d’un tableau. Il contient la référence, la nature, le libellé, le responsable et l’état de chaque incident. De plus, chaque ligne possède des liens afin d’accéder à d’autres pages. Il y a un lien « modifier », un lien « consulter », et un lien au niveau de la référence de l’incident qui permet également de le consulter. C’est aussi au niveau de cette page qu’un incident peut être ajouté.

Activité EVENEMENT -CU01-AC02 : Consulter un incident

Nous accédons à cette fonctionnalité à partir du suivi des incidents, en cliquant sur le lien « consulter » ou en cliquant sur la référence de l’incident à consulter. Cela permet de voir l’intégralité des informations d’un incident, puisque certaines données ne sont pas présentes dans le tableau de suivi des incidents.

À partir de cet écran, il est possible d’accéder directement à la modification d’un incident en utilisant le bouton « modifier », ou bien retourner au suivi des incidents en utilisant le bouton « Retour ».

Activité EVENEMENT-CU01-AC03 : Ajouter un incident

Cette fonctionnalité permet d’ajouter un incident au projet. Elle est accessible depuis le suivi des incidents d’un projet par le lien « Ajouter un incident ». Afin d’ajouter l’incident, il faut renseigner les champs du formulaire de la page.

L’ajout se fait si les champs obligatoires sont renseignés. Dans ce cas, la référence de l’incident est générée automatiquement en fonction de la dernière référence enregistrée et l’application retourne au suivi des incidents. Dans le cas où l’utilisateur valide alors que certains champs obligatoires ne sont pas remplis, l’ajout n’est pas réalisé et un message d’erreur apparaît.


Projet PMBox

Figure 32 – Activité EVENEMENT-CU01-AC03 : Ajouter un incident

Activité EVENEMENT-CU01-AC04 : Modifier un incident

Cette fonctionnalité permet de modifier un incident du projet. Elle est accessible depuis le suivi des incidents d’un projet par le lien « modifier » ou par un bouton depuis la consultation d’un incident. Lors de l’affichage de l’écran, les informations sur l’incident sont affichées, il est alors possible de les modifier.

La modification se fait si les champs obligatoires ne sont pas vides. Dans ce cas, la modification est prise en compte et l’application retourne au suivi des incidents. Dans le cas où l’utilisateur valide alors que certains champs obligatoires ne sont pas remplis, la modification n’est pas réalisée et un message d’erreur apparaît.


Projet PMBox

Figure 33 – Activité EVENEMENT-CU01-AC04 : Modifier un incident

Activité EVENEMENT-CU07-AC05 : Supprimer un document

Cette fonctionnalité permet de supprimer un document relatif au projet. Elle est accessible depuis le suivi de la documentation d’un projet par le lien « supprimer ».

La suppression se fait instantanément (bien qu’une demande de confirmation sera certainement intégrée) et l’application retourne au suivi de la documentation.

Figure 34 – Activité EVENEMENT-CU07-AC05 : Supprimer un document


Projet PMBox

6.4 LES ECRANS

Voici les maquettes des écrans appartenant aux différents modules du lot 1.

6.4.1 Les écrans du module « Administration »

Figure 35 – Ecran de connexion à l’application

Figure 36 – Ecran de recherche d’un projet


Projet PMBox

Figure 37 – Liste des fonctionnalités concernant un projet


Projet PMBox

6.4.2 Les écrans du module « Gestion des risques»

Figure 38 – Ecran de suivi des risques

Figure 39 – Ecran de consultation d'un risque


Projet PMBox

Figure 40 – Ecran d'ajout d'un risque

Figure 41 – Ecran de modification d'un risque


Projet PMBox

Figure 42 – Ecran de suivi des PRR

Figure 43 – Ecran de consultation d'une action d'un PRR


Projet PMBox

Figure 44 – Ecran d'ajout d'une action à un PRR

Figure 45 – Ecran de modification d'une action d'un PRR


Projet PMBox

6.4.3 Les écrans du module « Suivi des événements»

Dans ce module chaque onglet représente un type d’événement. A chaque événement correspond quatre écrans : un écran de suivi, un écran de consultation, un écran d’ajout, un écran de modification. En raison du nombre important d’onglets de ce module, nous allons montrer uniquement les écrans de l’onglet « Incident », les autres étant construits sur le même principe.

Figure 46 – Ecran de suivi des incidents

Figure 47 – Ecran de consultation d’incidents


Projet PMBox


Figure 48 – Ecran d’ajout d’incidents

Figure 49 – Ecran de modification d’incident

Documents

UN OUTIL DE SUIVI DE PROJET - Fabian Piaucv.fabianpiau.com/.../01...Projet_PMBox_Sylis_2009.pdf · UN OUTIL DE SUIVI DE PROJET. R. APPORT INTERMEDIAIRE. Projet du mercredi en entreprise