Dédicace - Cours et formations - Télécharger PDFmcours.net/cours/memoires/Mise_en_place_d_une_solution... · Web viewEn effet, Hibernate fourni un langage d'interrogation extrêmement

Ecole Nationale Supérieure

d’Informatique et d’Analyse

des Systèmes

CDG Développement

Mémoire de Projet de Fin d’Études

Pour l’Obtention du Titre d’Ingénieur d’État en Informatique Option :

Génie Logiciel&

Informatique et Aide à la Décision

Su j e t :

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

suivi des projets deCDG Développement et

ses filiales

Soutenu par : - Abbes SADI

- Omar HAJI

Sous la direction de :

- M. Radouane CHIHEB (ENSIAS)

- M. Salah BAINA (ENSIAS)

- M. Alaeddine DAOUDI (CDG Développement)

Année Universitaire 2007-2008

Dédicaces

Projet de fin d‘études 2008Abbes SADI / Omar HAJI 2

Dédicaces

A nos très chers

parents… A nos

sœurs et nos

frères… A nos

familles…

A tous nos

amis… A

L’ENSIAS…

Remerciements


Remerciements

Il nous est agréable de nous acquitter d’une dette de reconnaissance auprès de toutes les personnes, dont l’intervention au cours de ce projet, a favorisé son aboutissement.

Ainsi, nous tenons à remercier tout le personnel de CDG Développement, pour son soutien et pour sa générosité considérable quant à l’offre de l’information.

Nos très chers remerciements vont à M. Alaeddine DAOUDI & M. Souhail BENCHRIFA nos encadrants au sein de CDG Développement, qui n’ont pas manqué de nous préparer les conditions favorables au bon déroulement du projet.

Nos remerciements les plus sincères vont aussi à M. Salah BAINA & M. Radouane CHIHEB, nos encadrants à l’ENSIAS, pour les conseils qu’ils nous ont prodigués, leur judicieux encadrement ainsi que leur assistance pour la rédaction du rapport.

Nous saisissons aussi l’occasion pour remercier M. Amine EL HAJHOUJ, Mme. Fatime Zahra ALAOUI, M. Abedelhafid LAZREQ et M. Mounir EL FARISSI pour avoir été toujours à l’écoute et pour leurs conseils et coopérations.

Nous tenons également à adresser nos plus sincères remerciements à l’ensemble du corps enseignant de l’ENSIAS, pour avoir porté un vif intérêt à notre formation, et pour avoir accordé le plus clair de leur temps, leur attention et leur énergie et ce dans un cadre agréable de complicité et de respect.

Enfin, que tous ceux et celles qui ont contribué de près ou de loin à l’accomplissement de ce travail trouvent l’expression de nos remerciements les plus chaleureux.

Résumé


Résumé

Le présent document est le fruit de notre travail dans le cadre du projet de fin d’études effectué au sein du Holding CDG Développement. Ce projet a pour but la mise en place d’une solution informatique pour la gestion et le suivi des projets de CDG Développement et ses filiales.

Durant notre projet, nous avions pour mission dans un premier temps de cerner le sujet et de délimiter le périmètre du projet. Après une analyse approfondie de la problématique, nous avons élaboré un modèle conceptuel de la solution. Ensuite, nous avons abordé la phase de la mise en œuvre et de l’implémentation du système. La dernière étape a fait l’objet du déploiement, des tests et de la validation.

Pour bien mener notre projet, nous avons choisi de suivre un cycle de développement en Y (2TUP), démarche qui a fait ses preuves dans le domaine des projets informatiques.

Ce rapport est axé sur cinq grandes parties. La première partie définit le contexte général du projet en présentant l’organisme d’accueil et en définissant le périmètre du projet. Dans la deuxième partie, nous présentons l’analyse fonctionnelle du projet en exposant les différentes fonctionnalités du système avant de présenter dans la troisième partie l’étude conceptuelle de la solution. La quatrième partie présente les différentes étapes de la mise en œuvre du projet en abordant l’architecture technique et la technologie utilisée. Quant au dernier chapitre, il présente un scénario d’utilisation et de validation des différents modules du projet. A la fin du rapport, nous présentons les différentes annexes

Résumé


traitant les fiches descriptives des filiales de l’organisme d’accueil, le plan assurance qualité, ainsi qu’un complément d’informations se rapportant à la plateforme J2EE, à la technologie d’AJAX et à la méthodologie 2TUP.

Liste des abréviations


Liste des abréviations

Abréviation Designation

2TUP 2 Track Unified ProcessAJAX Asynchronous Java And XmlAPI Application Programming InterfaceBPO Business Process OutsourcingCDG Caisse de Dépôt et de GestionCGI Compagnie Générale ImmobilièreCSV Comma Separated ValuesDSPR Direction de Suivi des Projets et

RéalisationsENSIAS Ecole Nationale Supérieur d’Informatique et d’Analyse des

HQL Hibernate Query LanguageHTML HyperText Markup LanguageIDE Integrated Development EnvironmentIHM Interface Homme MachineITO Information Technology OutsourcingJ2EE Java 2 Entreprise EditionJDBC Java DataBase ConnectivityJSP Java Server PagesMVC Modèle Vue ContrôleurPAQ Plan Assurance QualitéPDF Portable Document FormatRTF Rich Text FormatSDK Sun Developpement KitSGBD Système de Gestion des Bases de

DonnéesSOMED SOciété Maroc Emirat de DéveloppementSQL Structured Query Language

TRI Taux de Retour sur InvestissementUML Unified Modeling LanguageWYSIWYG What You See Is What You GetXML eXtensible Markup Language

Liste des figures


Liste des figures

Figure 1: Filiales de CDG Développement ............................................................................................. 15

Figure 2: Organisation de CDG Développement ................................................................................... 18

Figure 3: Cycle de développement en Y ................................................................................................ 21

Figure 4: Planning prévisionnel du projet ............................................................................................. 23

Figure 5: Utilisateurs du système .......................................................................................................... 28

Figure 6: Diagramme des cas d'utilisation d'administration ................................................................. 32

Figure 7: Diagramme des cas d'utilisation du responsable de suivi...................................................... 33

Figure 8: Diagramme des cas d'utilisation du Top Management.......................................................... 34

Figure 9: Diagramme des cas d'utilisation du chef de projet ................................................................ 35

Figure 10: Diagramme des cas d'utilisation du directeur de projet ...................................................... 36

Figure 11: Architecture fonctionnelle du système ................................................................................ 37

Figure 12: Diagramme de séquence d'ouverture de session ................................................................ 43

Figure 13: Diagramme de séquence d'administration des utilisateurs................................................. 44

Figure 14: Diagramme de séquence de gestion de projets................................................................... 46

Figure 15: Diagramme de séquence de suivi de projet ......................................................................... 47

Figure 16: Diagramme de séquence de validation de projet ................................................................ 48

Figure 17: Diagramme de package du système .................................................................................... 49

Figure 18: Diagramme de classes (dimensions: ville, organisme et tranche) ....................................... 52

Figure 19: Diagramme de classes (Dimensions: personne et intervenant) .......................................... 53

Figure 20: Modèle physique de données .............................................................................................. 54

Figure 21: Architecture Modèle-Vue-Contrôleur .................................................................................. 59

Figure 22: L'implémentation du modèle MVC par Struts...................................................................... 59

Figure 23: L'architecture en couches du système ................................................................................. 64

Figure 24: La page d'authentification.................................................................................................... 68


Liste des figures

Figure 25: La page de la liste des projets .............................................................................................. 69

Figure 26: Diagramme de Gantt de tous les projets ............................................................................. 70

Figure 27: Exemple de rapports d'état .................................................................................................. 70

Figure 28: Exemple de présentation ..................................................................................................... 71

Figure 29: Tableau de bord d'un projet................................................................................................. 72

Figure 30: Diagramme de Gantt d'un projet ......................................................................................... 73

Figure 31: La page de la recherche multicritère.................................................................................... 73

Figure 32: Page des statistiques ............................................................................................................ 74

Figure 33: TRI moyen des filiales ........................................................................................................... 75

Figure 34: Inventaire des projets par région ......................................................................................... 76

Figure 35: Carte des projets et réalisations........................................................................................... 76

Figure 36: Boucle de validation de la solution proposée ...................................................................... 78

Figure 37: Diagramme d'activité du processus de suivi ........................................................................ 80

Figure 38: Vue haut niveau de l’architecture d'Hibernate .................................................................. 104

Figure 39: Architecture légère d'Hibernate......................................................................................... 105

Figure 40: Architecture complète d'Hibernate ................................................................................... 105

Figure 41: Cycle de vie d'un rapport Jasper ........................................................................................ 113

Figure 42: Sources de données supportées par JasperReports .......................................................... 114

Liste des tableaux


Liste des tableaux

Tableau 1:Tableau des rôles et des droits d'accès des utilisateurs....................................................... 31

Tableau 2: Tableau des classes.............................................................................................................. 51

Tableau 3: Objectifs techniques du système........................................................................................ 57

Tableau 4: Les rôles et les relations de la couche Présentation ........................................................... 65

Tableau 5: Les rôles et les relations de la couche Application .............................................................. 66

Tableau 6: Les rôles et les relations de la couche Entreprise................................................................ 66

Tableau 7: Les rôles et les relations de la couche Mapping .................................................................. 67

Tableau 8: Les rôles et les relations de la couche Stockage .................................................................. 68

Table des matières


Table des matières

REMERCIEMENTS ............................................................................................................................................. 3

RESUME ........................................................................................................................................................... 4

LISTE DES ABREVIATIONS ................................................................................................................................. 5

LISTE DES FIGURES ........................................................................................................................................... 6

LISTE DES TABLEAUX ........................................................................................................................................ 8

TABLE DES MATIERES ....................................................................................................................................... 9

INTRODUCTION GENERALE ............................................................................................................................ 11

CHAPITRE 1 : CONTEXTE GENERAL DU PROJET ............................................................................. 13

1.1 INTRODUCTION A LA GESTION DE PROJETS ...................................................................................... 141.2 PRESENTATION DE L’ORGANISME D’ACCUEIL ................................................................................... 14

1.2.1 Domaines d’activités de CDG Développement et ses filiales ..................................................... 141.2.2 Projets et réalisations de CDG Développement et ses filiales .................................................... 161.2.3 Organisation de CDG Développement ........................................................................................ 17

1.3 PRESENTATION DE PROJET ................................................................................................................ 18

1.3.1 Périmètre du projet ........................................................................................................................ 181.3.2 Objectifs du projet ......................................................................................................................... 19

1.4 DOSSIER DE PILOTAGE ....................................................................................................................... 20

1.4.1 Plan assurance qualité ................................................................................................................... 201.4.2 Conduite du projet ......................................................................................................................... 201.4.3 Déroulement du projet .................................................................................................................. 22

CHAPITRE 2 : ETUDE FONCTIONNELLE DU PROJET ..................................................................... 25

2.1 ETUDE DE L’EXISTANT ET BENCHMARKING ..................................................................................... 262.2 IDENTIFICATION DES ACTEURS.......................................................................................................... 282.3 CAS D’UTILISATION ............................................................................................................................. 322.4 DESCRIPTION DES FONCTIONNALITES .............................................................................................. 36

Table des matières


2.4.1 Architecture fonctionnelle ............................................................................................................. 362.4.2 Module de gestion des projets ...................................................................................................... 372.4.3 Module d’édition des rapports ...................................................................................................... 392.4.4 Module de la recherche multicritère............................................................................................. 402.4.5 Module des Statistiques ................................................................................................................ 402.4.6 Module de la carte ......................................................................................................................... 402.4.7 Module d’administration ............................................................................................................... 41

CHAPITRE 3 : ANALYSE ET CONCEPTION ......................................................................................... 42

3.1 COMPORTEMENT ET TRAITEMENT DES DONNEES ........................................................................... 433.2 COMPOSITION DU SYSTEME ............................................................................................................... 493.3 ANALYSE DES DONNEES ..................................................................................................................... 503.4 MODELE PHYSIQUE DE DONNEE ....................................................................................................... 53

CHAPITRE 4 : REALISATION ET MISE EN ŒUVRE ........................................................................... 56


Table des matières

4.1 CAPTURE DE BESOINS TECHNIQUES .................................................................................................. 574.2 ENVIRONNEMENT DE DEVELOPPEMENT.......................................................................................... 584.3 OUTILS DE DEVELOPPEMENT ............................................................................................................ 624.4 ARCHITECTURE LOGICIELLE DU SYSTEME ........................................................................................ 644.5 PRESENTATION DE QUELQUES INTERFACES ..................................................................................... 68

CHAPITRE 5 : VALIDATION ET SCENARIO D’UTILISATION........................................................... 78

4.1 REPONSE A LA PROBLEMATIQUE........................................................................................................ 794.2 DESCRIPTION DU FONCTIONNEMENT DU SYSTEME ......................................................................... 804.3 SCENARIOS D’UTILISATION ................................................................................................................ 81

CONCLUSION ET PERSPECTIVES ...................................................................................................................... 86

BIBLIOGRAPHIE .............................................................................................................................................. 87

ANNEXES ........................................................................................................................................................ 88

ANNEXE A : PLAN ASSURANCE QUALITE ......................................................................................................... 89

ANNEXE B : LE FRAMEWORK HIBERNATE ..................................................................................................... 102

ANNEXE C : JASPERREPORTS ........................................................................................................................ 110

Introduction générale



Depuis de nombreuses années déjà, les entreprises se voient contraintes d’augmenter sans cesse leur efficacité tout en diminuant leurs coûts. Dans le cas des sociétés de gestion (ou holdings), une des solutions les plus performantes développées actuellement consiste à s’organiser autour des projets menés par ses filiales, dans le but de piloter, structurer, assurer et optimiser le bon déroulement d’un projet.

Un projet peut être définit comme étant toute activité complexe orientée vers la production d’un ou plusieurs biens ou services et mobilisant, sur une période assez longue mais finie, un ensemble conséquent de ressources. La gestion et le suivi de projets ont donc pour but de mener un projet à son terme, en prenant en compte les différentes contraintes de réalisations et en faisant face aux imprévus.

La difficulté dans la conduite du projet réside en grande partie dans la multiplicité des acteurs qu'il mobilise. En effet, contrairement aux projets personnels ou aux projets internes à faible envergure pour lesquels le besoin et la réponse à ce besoin peuvent être réalisés par la même personne ou par un nombre limité d'intervenants, dans un projet, au sens professionnel du terme, l'expression du besoin et la satisfaction de ce besoin sont portés par des acteurs généralement distincts.

Certaines recherches soulignent que 85 à 90% des projets lancés par les entreprises ne parviennent pas à atteindre leurs objectifs en termes de délais, budget ou qualité. Pourquoi ? Les raisons en sont multiples : manque d’objectifs, de planification, de définition des rôles, de communication, de contrôle et de suivi,



de formation à la gestion de projet, de gestion des risques ou des changements, etc. Pour éviter ces écueils, il faut se donner les moyens de la réussite : mettre en œuvre une méthode simple et efficace de gestion de projet, adaptée à l’environnement et à la mission de la société.

C’est dans cette perspective que le holding CDG Développement a décidé de mettre en place une solution informatique de gestion et de suivi de projet, solution qui a



pour finalité l’optimisation et l’automatisation des activités opérationnelles de la« Direction Suivi des Projets et Réalisations ».

La DSPR a pour mission d’assurer le suivi des différents projets que mènent les filiales du holding. Pour bien mener sa mission, elle doit disposer de toutes sortes d’informations tout au long du projet. Informations pouvant être de nature opérationnelle ou financière, souvent destinées à la prise de décision. Le souci des responsables de suivi au niveau de CDG Développement est donc d’avoir constamment une information valide et pertinente. Leur mission consiste, en effet, à consolider l’information remontée à partir des filiales, à préparer des fiches de synthèse concernant les projets et à élaborer des présentations récapitulatives, ce travail étant destiné au pôle stratégique et à la direction générale.

Le présent rapport décrit l’essentiel du travail réalisé lors de ce projet. Il comporte cinq chapitres. Le premier définit le contexte général du projet, à savoir une introduction à la gestion de projets, la présentation de l’organisme d’accueil ainsi que la présentation du projet. Le deuxième chapitre décrit l’étude fonctionnelle et les modules du futur système. Le troisième chapitre décrit la conception de la solution. Quant au quatrième et avant dernier chapitre, il présente une description détaillée de la phase de la mise en œuvre du projet. Le dernier chapitre est réservé à la validation du projet en mettant en œuvre un scénario d’utilisation du système réalisé.

Chapitre 1 : Contexte général du projet



Dans la première section de ce chapitre, nous donnons un bref aperçu sur le métier de la gestion de projet. L’organisme d’accueil, à savoir CDG Développement, son organisation, son domaine d’activité et les différents projets qu’il réalise sont présentés dans la deuxième section. La dernière section sera dédiée à une description détaillée du projet, ses objectifs ainsi que la démarche adoptée pour le mener à bien.



1.1 Introduction à la gestion de projets

La gestion de projet ou conduite de projet est une démarche visant à structurer, assurer et optimiser le bon déroulement d’un projet suffisamment complexe pour devoir :

- Être planifié dans le temps : c’est l’objet de la planification ;

- Être budgétisé (étude préalable des coûts et avantages ou revenus attendus en contrepartie, des sources de financement, étude des risques opérationnels et financiers et des impacts divers …) ;

- Maîtriser et piloter les risques ;

- Atteindre le niveau de qualité souhaité ;

- Faire intervenir de nombreuses parties prenantes : c’est l’objet des organisations qui identifient maîtrise d'œuvre et maîtrise d'ouvrage ;

- Responsabiliser le chef de projet ou le directeur de projet, mettre en place un comité de pilotage ;

- Suivre des enjeux opérationnels et financiers importants.

1.2 Présentation de l’organisme d’accueil

1.2.1 Domaines d’activités de CDG Développement et ses filiales

Filiale à 100% de la Caisse de Dépôt et de Gestion, CDG Développement a été créée en 2004 afin d’incarner la stratégie du groupe CDG dans les activités opérationnelles non financières. CDG Développement possède 24 filiales et sous-filiales, elle regroupe 28 participations et près de 2 800 collaborateurs.

La déclinaison de la mission de CDG développement est multiple :

- Être un levier de développement et d’innovation ;

- Maximiser l’efficacité des missions d’intérêt général ;


Chapitre 1 : Contexte général du projet- Renforcer son positionnement de leader dans le développement territorial ;

- Maximiser la création de valeur pour l’actionnaire ;

- Asseoir son statut de référence comme partenaire des collectivités locales ;



- Développer et structurer de nouveaux métiers ;

- Atteindre des niveaux de rentabilité des fonds propres en ligne avec les marchés ;

- Concilier performance financière et utilité collective.

La Philosophie d’intervention de l’organisme est de servir les ambitions des Collectivités Locales, de concevoir des concepts territoriaux novateurs, de proposer des offres de valeur territoriales, d’enclencher une dynamique partenariale et enfin de développer des projets structurants et emblématiques.

L’organisation de CDG Développement répond aux missions classiques d’un holding sur les aspects suivants :

- Pilotage stratégique : Synergies et Développement.

- Pilotage financier : Services aux filiales.

- Contrôle financier et opérationnel.

- CDG Développement gère plus de 20 filiales à travers le royaume. Ces filiales sont réparties en quatre domaines d’activités :


Chapitre 1 : Contexte général du projetFigure 1: Filiales de CDG Développement



- Ingénierie, Aménagement et Promotion :

Le Groupe CDG Développement est un opérateur immobilier présent sur toute la chaîne de valeur : l’ingénierie, l’aménagement et l’extension urbaine, la promotion et la réhabilitation urbaine et les services à l’immobilier.

- Tourisme :

Le Groupe CDG est un acteur historique dans le tourisme, qui représente l’un des secteurs les plus porteurs de l’économie marocaine. La gestion des unités hôtelières du Groupe se fait actuellement soit de façon directe par le biais des filiales spécialisées de CDG Développement soit à travers une formule de partenariat avec des groupes de renommée mondiale.

- Filière Bois :

CDG Développement est présente sur la filière Bois où elle se positionne sur l'ensemble des maillons de la chaîne de valeur : production de bois et gestion d’actifs forestier, fabrication de pâte à papier et production de papier.

- Grands Projets Urbains, Infrastructures et services aux collectivités locales :

CDG Développement intervient sur cette ligne métier dans une logique de partenariat avec les collectivités locales, impliquant le développement de l’assistance à maîtrise d’ouvrage et la création de Sociétés d'Economie Mixte (SEM) pour porter et gérer de nouveaux projets.

1.2.2 Projets et réalisations de CDG Développement et ses filiales

Parmi les grands chantiers ouverts au Maroc, on repère plusieurs projets réalisés par le Holding et ses filiales :

- La station balnéaire Mazagan :


Chapitre 1 : Contexte général du projetCe projet consiste en l’aménagement d’une nouvelle zone touristique Mazagan entre les sites touristiques d’EL Haouzia et d’EL Jadida sur la côte atlantique. D’une superficie de 504 ha, ce projet est un consortium comprenant SOMED (Société Maroc Emirat de Développement), le groupe sud africain Kerzner international et CDG Développement. Le complexe disposera à terme de 3900 lits hôteliers, 4100 lits résidentiels, des



équipements d’animation et de loisirs et des équipements commerciaux. Le montant d’investissement de ce projet s’élève à 3 milliards de dirhams.

- Casablanca Nearshore Park :

Ce projet a pour objectif de gérer et développer le premier parc d’affaire marocain dédié aux activités de BPO (Business Process Outsourcing) et ITO (Information Technology Outsourcing). Il est situé dans un emplacement stratégique, à proximité du nouveau centre d’activité de Casablanca et à 15 mn de l’aéroport international Mohammed V. Etalé sur un plateau de 53 ha, le parc offre 250 000 m2 d’espaces de bureaux, commerces et services aux meilleurs standards internationaux et un cadre législatif favorisant l’investissement extérieur. Le montant d’investissement est de l’ordre de 2,8 Milliards de dirhams.

- Zone touristique Chrifia:

Chrifia est un projet touristique, fruit d’un partenariat entre les Holding CDG Développement et Sama Dubaï., La maitrise d’ouvrage étant la compagnie CGI (Compagnie Générale Immobilière). Ce projet s’étale sur une superficie de 382 431 m2. Le complexe comporte hôtels, résidences, commerces, golf de 18 tours, animation, wellness, sport et loisirs. Son montant d’investissement est de l’ordre de 4,8 Milliards de dirhams.

1.2.3 Organisation de CDG Développement

L’organigramme ci-dessous (cf. Figure 2) présente les différentes directions de CDG Développement :



Figure 2: Organisation de CDG Développement

Notre stage de fin d’étude s’est déroulé au sein de la Direction Support. En effet, la Direction Suivi des Projets & réalisations a sollicité cette direction pour mettre en place un système de gestion de suivi des projets du holding, mission qui nous a été confié durant la période de notre stage.

1.3 Présentation de projet

1.3.1 Périmètre du projet

La DSPR (Direction Suivi Projets & Réalisations) a pour mission d’assurer le suivi des différents projets que mène le holding. Pour bien mener sa mission, la DSPR doit disposer de toutes sortes d’informations relatives aux projets menés par ses filiales. Ces informations peuvent être de nature opérationnelle ou financière, souvent destinées à la prise de décision. Le souci des responsables de suivi est donc d’avoir une information valide et


Chapitre 1 : Contexte général du projetpertinente tout au long du projet. Leur mission consiste, en effet, à consolider l’information remontée à partir des filiales, à préparer des fiches de synthèse concernant



les projets et à élaborer des présentations récapitulatives. Ce travail étant destiné au pôle stratégique et à la direction générale.

Ainsi, notre projet consiste en la mise en place d’une solution informatique de gestion et de suivi des projets et réalisations, permettant à la DSPR de bien mener sa mission. Cet outil garantira la validité de l’information tout en automatisant les principales activités opérationnelles de la direction.

Parmi les fonctionnalités que propose le futur système, on peut citer :

- Gestion des projets, des tranches et des sous tranches ;

- Recherche multicritère des projets ;

- Génération de rapports (en format PDF ou WORD) regroupant les informations clés des projets ;

- Génération de présentations Power Point concernant les projets ;

- Génération du diagramme Gantt d’un projet ;

- Gestion d’un fond documentaire, avec la possibilité d’uploader et de télécharger un document ;

- Visualisation des statistiques relatives aux filiales, aux régions, aux projets ;

- Consultation de la liste des partenaires et des opérateurs de CDG Développement.

1.3.2 Objectifs du projet

Parmi les principaux buts du projet, on peut citer :

- L’optimisation des activités opérationnelles de la DSPR :

Disposer d’un outil technologique répondant aux besoins opérationnels va améliorer le rendement interne en garantissant un gain de temps et de ressources remarquable. De plus, ce système permettrait aux collaborateurs de rechercher l’information pertinente dont ils ont besoin en un temps réduit.


Chapitre 1 : Contexte général du projet- L’automatisation des supports de suivi des projets et réalisations :

La génération de fiches descriptives des projets contenants les informations clés, la génération des diagrammes de Gantt des projets, la génération des présentations



Power Point, permettraient à la DSPR de réduire ses coûts en termes de temps et ressources. De plus, ceci contribuera à une gestion centralisé respectant un standard.

- Disposer d’une base de données pour tous les projets de CDG Développement et ses filiales.

- Disposer d’un tableau de bord synthétisant l’état d’avancement de tous les projets.

- Disposer d’un système de reporting pour la génération des états de sorties et la prise de décision.

1.4 Dossier de pilotage

1.4.1 Plan assurance qualité

Dans le but d’obtenir un logiciel qui répond aux besoins fonctionnels, techniques et qualité, nous avons élaboré notre plan assurance qualité. Dans ce plan, nous avons décrit les dispositions que nous nous sommes engagés à appliquer afin d’aboutir à un logiciel de qualité conforme aux spécifications exprimées. Nous y avons aussi décrit les différentes structures du projet et le planning de réalisation. La description totale du PAQ est présentée dans l’annexe A.

Dans ce qui suit, nous allons présenter le cycle de développement adopté ainsi que le planning du déroulement du présent projet.

1.4.2 Conduite du projet

Un processus de développement définit une séquence d’étapes, en partie ordonnée, qui concoure à l’obtention d’un système logiciel nouveau ou à l’évolution d’un système existant. Ce processus a pour objectifs de produire des solutions informatiques de qualité répondant aux besoins des utilisateurs dans des temps et des coûts prévisibles.


Chapitre 1 : Contexte général du projetDe ce fait, l’adéquation du projet au processus de développement peut largement affecter le sort d’un projet informatique. Pour éviter tout risque, nous avons choisi le processus 2TUP qui s’adapte le mieux à notre projet. En effet, notre projet présente une difficulté technique et fonctionnelle élevée. La difficulté technique réside dans l’utilisation des technologies de pointes. Quant à la difficulté fonctionnelle, elle réside essentiellement



dans l’étude de l’existant et la description des fonctionnalités riches du système. Cette description devra porter sur les multiples fonctionnalités offertes par le système de gestion et suivi des projets. Ainsi, pour faire face à cette complexité, le processus 2TUP propose un cycle de développement en Y, qui dissocie les aspects techniques des aspects fonctionnels, ce qui permet de gérer les risques que présente notre projet.

Le schéma ci-dessous illustre la démarche du processus en Y :

Figure 3: Cycle de développement en Y



Le processus en Y ou Two Track Unified Process (2TUP) est un processus qui s’articule autour de l’architecture. Il est constitué de deux branches, l’une fonctionnelle et l’autre technique. Celles-ci se rencontrent dans la partie de la réalisation, d’où son appellation de cycle en Y.

L’étude fonctionnelle a pour objectif de capturer les besoins fonctionnels en termes de fonctionnalités que doit remplir le système cible. L’étude technique, quant à elle, précise les contraintes techniques à prendre en considération, et propose une architecture logicielle et applicative qui répond aux contraintes dégagées. La phase suivante de conception consiste à reprendre le modèle d’analyse et le refaire selon les décisions prises dans la branche technique. Il s’agit donc d’adapter le modèle d’analyse à l’architecture logicielle adoptée et aux Frameworks techniques choisis.

1.4.3 Déroulement du projet

La planification du projet est une phase importante d'avant-projet. Elle consiste à prévoir le déroulement du projet tout au long des phases constituant le cycle de développement. Grâce aux réunions tenues avec les intervenants au sein de CDG Développement, nous avons pu définir cinq grandes étapes : la première est dédiée à l’étude préliminaire pour bien délimiter le périmètre du projet. La seconde est consacrée à l’étude fonctionnelle et technique dont les objectifs sont de bien cerner le sujet. Quant à la troisième étape, elle traite l’analyse et la conception de la solution. L’étape suivante consiste en la mise en œuvre de la solution, et finalement, la dernière étape consiste à la validation et au déploiement de la solution.



Le diagramme de Gantt (cf. Figure 4) suivant présente le planning prévisionnel de notre projet :

Figure 4: Planning prévisionnel du projet


Conclusion

Dans ce chapitre, nous avons commencé par un bref aperçu sur le domaine de la gestion de projet. Nous sommes ensuite passés à la présentation de l’organisme d’accueil. Enfin, nous avons décrit le contexte, les objectifs de notre projet, ainsi que le processus de développement 2TUP, que nous avons adopté pour le développement de la solution. A base de ce processus, nous avons établi un planning de travail afin de bien maîtriser les ressources et contraintes liées au projet.

Le chapitre suivant est consacré à l’étude fonctionnelle du projet.

Chapitre 2 : Etude fonctionnelle du projet



Dans ce chapitre nous présenterons l’analyse fonctionnelle de notre projet. Dans un premier temps nous étudierons l’existant avant de décrire l’architecture fonctionnelle du système. Nous listerons ensuite les principales fonctionnalités et les différents acteurs de l’application. La dernière partie sera réservée à la description des différents cas d’utilisation.



2.1 Etude de l’existant et Benchmarking

Nous avons jugé nécessaire de faire une étude préalable en matière de gestion de projet au sein de CDG Développement dans le but de concevoir une solution complète qui obéit aux attentes de l’organisme.

CDG Développement ne dispose d’aucun outil informatisé assurant le suivi et la gestion de projet. Toutes les informations concernant les différentes réalisations des filiales sont regroupées dans des fichiers Excel ou sous forme de fiches dans des documents Word. Les informations sont donc récupérées à partir des notes de réunions, des messages électroniques ou encore des entretiens téléphoniques. Ces informations sont ensuite consolidées au niveau de CDG Développement et exploitées par les responsables de suivis.

Ceci dit, le site web officiel du holding offre une certaine visibilité sur les projets et réalisations de CDG développement. Cependant, les informations publiées sur le site sont obsolètes et ne sont pas mises à jour. Ceci est du à l’indisponibilité d’une base de données alimentée et mise à jour. Les nouveaux projets ne figurent donc pas et l’information est devenue rapidement invalide.

C’est pour améliorer ce système et mettre en place une plateforme remédiant à ces problématiques la DSPR a cherché à mettre en place son propre système informatique.

Avant de prendre la décision de procéder par un développement spécifique de la solution, nous nous sommes intéressés aux solutions existantes sur le marché. Nous avons donc réalisé une étude comparative entre les différents outils disponibles.

Parmi les outils que nous avons étudiés, nous pouvons citer :

- ActiveCollab [ w w w . ac tiv eco ll ab . co m] :

http://www.activecollab.com/


Chapitre 2 : Etude fonctionnelle du projetUn outil permettant la gestion de projets qui inclus un module de suivi de projets, ainsi que plusieurs fonctionnalités à savoir l’administration (permissions, profils, organisme, etc.…), la gestion des fichiers et des tâches concernant les projets. La version0.7.1 d’ActiveCollab est open source.



- Jprojet [ www .j pro j e t . c o m ] :

Un outil de gestion de projets, dont le but est de pouvoir suivre l’évolution d’un projet du début jusqu'à la clôture en passant par les différents changements de versions. Cet outil se compose de plusieurs modules à savoir l’administration qui permet de définir les utilisateurs et leurs rôles (permissions, profils, organisme, etc.…), le module projets qui permet de décrire un projet, faire le suivi des versions et joindre des documents.

- Dotproject [ www . d o t p r o j ec t . c o m ]:

DotProject est un outil de gestion de projet basé sur une interface web, multiutilisateurs et multi-langues. Il est libre et gratuit pour toute utilisation et est maintenu par une communauté de programmeurs bénévoles.

Malgré les riches fonctionnalités que proposent les outils cités ci-dessus, ils ne proposent pas l’ensemble des services dont la DSPR a besoin. En effet, tous ces outils n’intègrent pas les fonctionnalités de reporting pour la génération de rapports et de présentations ou encore un module de statistiques pour la prise de décision. De plus, aucun de ces outils n’offre la possibilité de visualiser les projets sur une carte.

De cette étude nous avons conclu que les solutions existantes ne répondent pas aux besoins émis par la Direction de Suivi des Projets et Réalisations (DSPR). De plus, l’organisation de CDG développement et ses filiales fait qu’ils ne peuvent s’adapter à ce genre de solutions souvent dédiées à la gestion de projets et non au suivi et des projets et des filiales.

A part le côté fonctionnel du système, assurer le suivi des projets relève du pôle stratégique de l’organisme. Ceci dit, l’enjeu est majeur et le holding ne peut courir le risque de dépendre d’une solution open source, ne présentant aucune garantie et ne couvrant

http://www.dotproject.com/

http://www.jprojet.com/


Chapitre 2 : Etude fonctionnelle du projetpas l’ensemble des besoins de l’organisme.

Ainsi, au terme de cette étude et vu l’enjeu stratégique du projet et le nombre de plus en plus importants des investisseurs, nous avons décidé de procéder par un développement spécifique tenant compte de l’ensemble des besoins de l’organisme en matière de gestion de projet.



2.2 Identification des acteurs

Au travers des différentes réunions avec le comité de maîtrise d’ouvrage et le site pilote (la CGI), nous avons pu identifier huit utilisateurs potentiels de l’application. En effet, la sensibilité de l’information et la manière dont les données sont exploitées varient d’un organisme à un autre et d’un utilisateur à un autre. Les responsabilités des acteurs diffèrent selon l’organisme auquel ils appartiennent, selon le poste qu’ils occupent et selon la hiérarchie dont ils font partie.

La figure 5 illustre les huit acteurs du système :

Figure 5: Utilisateurs du système



On peut regrouper les utilisateurs en deux catégories : les utilisateurs au sein même de CDG Développement et les utilisateurs au sein de ses filiales. Ainsi, on retrouve :

Au niveau de CDG Développement :

- Le Top Management- L’administrateur fonctionnel- Le responsable de suivi

Au niveau des filiales :

- Le directeur générale de la filiale- Le directeur de pôle- Le directeur de projet- Le chef de projet- L’utilisateur groupe

L e t o p m ana g e m en t

Ce rôle est réservé au président et à l’administrateur directeur général de CDG Développement. Il accède aux informations classées top secrets relevant d’un partenariat stratégique ou concernant un projet non encore dévoilé. Un utilisateur avec rôle peut utiliser tous les services de l’application en mode consultation. Il peut notamment exporter des rapports ou générer des présentations ou encore visualiser les statistiques.

L ’ ad m i n i s t r ateu r f o n c t io nne l

L’administrateur fonctionnel est chargé de la gestion des droits d’accès, ainsi que la gestion des filiales, des partenaires et des opérateurs. Cette gestion comprend l’ajout, la modification et la suppression de ces différentes entités.

R e s p o n s ab le d e s u i v i


Chapitre 2 : Etude fonctionnelle du projetEtant chargé de superviser l’avancement de tous les projets de CDG Développement et de ses filiales, le responsable de suivi accède aux informations clés concernant un projet donné. Cet utilisateur peut consulter le journal, le diagramme de



Gantt, les fichiers et la liste des opérateurs et partenaires relatives à un projet. Il a accès également aux statistiques et à la carte.

L e d i r ecteu r g éné r a le d e la f i l i a le

Un utilisateur avec ce rôle accède à toutes les informations des projets relevant de la responsabilité de son organisme. L’accès lui est attribué en mode consultation.

L e d i r ecteu r d e Pô le

Le directeur de pôle est chargé de superviser un directeur de projet dont il est le supérieur hiérarchique. Il accède aux projets en consultation.

L e d i r ecteu r d e P r o j e t

Cet acteur joue le rôle de superviseur de plusieurs chefs de projet. Après la création d’un projet le directeur de projet peut faire son suivi par lui-même, ou l’affecter à un chef de projet. Il est également responsable de la validation et de la publication des données du projet.

L e c he f d e P r o j e t

Cet acteur est chargé de faire la gestion et le suivi d’un certain nombre de projets dont il est responsable. Suite à la création d’un nouveau projet, le chef de projet doit renseigner les informations sur les tranches et les sous tranches qui le constituent.

Après la clôture d’un projet, le chef de projet doit attribuer une note aux collaborateurs, opérateurs ou partenaires dans le but de capitaliser l’expérience acquise.

L ’ ut i l i s ateu r g r o up e

Il peut consulter la liste de tous les projets ainsi que la fiche descriptive. Cette fiche ne contient pas les informations clés, mais seulement des informations générales, tel que le nom et le type de projet. Cet acteur ne peut pas accéder au journal ou au diagramme


Chapitre 2 : Etude fonctionnelle du projetde Gantt.

Le tableau dans la page qui suit résume les opérations qui peuvent être effectuées par les différents rôles.



Profile

Fonctionnalité

Top Mana

g- ement

Responsable suivi

Admin. fonctionnel

DGfilial

e

D. de pôle

D. de projet

Chef de projet

Utilisateur groupe

Consulter la Fiche des projets X X X X X X X X

Consulter la carte et les statistiques

X X X X X X X X

Recherche multicritère X X X X X X X X

Visualiser l’état d’avancement du projet

X X X X X X X

Exporter les rapports et les présentations

X X X X X X X

Consulter la liste des contacts X X X X X X X

Voter pour un contact X X X X

Créer ou modifier un projet X X XRenseigner l’état d’avancement des projets

X X X

Gestion des tranches et des sous tranches

X X X

Créer les partenaires et les opérateurs.

X X X

Tableau 1:Tableau des rôles et des droits d'accès des utilisateurs


2.3 Cas d’utilisation

Les cas d'utilisation permettent de représenter le fonctionnement du système vis-à- vis de l'utilisateur : c'est donc une vue du système dans son environnement extérieur.

Les acteurs du système sont les personnes qui utilisent les fonctions du système. Les acteurs principaux de notre système sont au nombre de huit : Administrateur, responsable suivi, top management, DG filiale, directeur de pôle, directeur de projet, chef de projet et utilisateur groupe.

Dans les paragraphes qui suivent, nous présentons quelques cas d’utilisation qui mettent en évidence les principales fonctionnalités de chaque rôle.

Administrateur (cf. Figure 6):

C’est l’administrateur fonctionnel qui prend en charge la gestion des filiales, des utilisateurs, des partenaires et des opérateurs.

Gérer l es fi l i al es

<>

Gérer l es uti l i sateurs

Gérer l es partenai res

<>

<>

Authenti fi cati on

Admi ni strateur <>

Gérer l es opérateurs

Figure 6: Diagramme des cas d'utilisation d'administration

- Gérer les filiales : L’administrateur prend en charge la gestion


des filiales, en termes d’ajout, de suppression et de mise à jour des informations correspondantes.

- Gérer les utilisateurs : L’administrateur se charge aussi de gérer les utilisateurs. En ajoutant un utilisateur, l’administrateur précise son supérieur hiérarchique selon son profil et son organisme.

- Gérer les partenaires : Après le lancement d’un projet ou bien avant le lancement, la maitrise d’ouvrage cherche des partenaires au projet. Ces partenaires sont des investisseurs participant aux fonds du projet.

- Gérer les opérateurs : un opérateur est un organisme chargé de gérer un composant d’un projet. Par exemple, après la construction d’un complexe touristique, la maitrise d’ouvrage peut déléguer la tâche de gestion du parc à un opérateur.

Responsable suivi (cf. Figure 7) :

C’est le responsable de suivi, au sein de la Direction Suivi des Projets et Réalisation au niveau de CDG Développement, qui se charge de faire le suivi des projets de toutes lesfiliales.

Consul ter l a fi che du proj et

Générer un rapport descri pti f

<>

<>

Générer une présentati on des proj ets

<>

Authenti fi cati on

Responsabl e sui vi

Rechercher l es proj ets

<>

<>

Consul ter l es stati sti ques

Figure 7: Diagramme des cas d'utilisation du responsable de suivi

- Consulter la fiche du projet : Pour réussir sa mission, le responsable se suivi peut consulter la fiche descriptif du projet contenant les différentes informations opérationnelles du projet. En consultant la fiche descriptif du projet, il peut voir les informations concernant les tranches du projet ainsi que ses sous tranches.

- Générer un rapport descriptif : Le responsable de suivi a la possibilité de générer un rapport descriptif, contenant une image descriptive et les informations clés à la gestion et au suivi du projet. Ces fiches sont en formats PDF ou WORD.

- Générer une présentation des projets : notre solution donne au responsable de suivi l’option de générer une présentation Power Point contenant trois images du projet : la première satellitaire, la deuxième descriptive et la troisième met en valeur l’état d’avancement du projet ainsi que les informations sur le projet sélectionné.

- Rechercher les projets : le responsable de suivi peut chercher dans la base de données les projets des filiales suivant plusieurs critères à savoir : le nom du projet, la maitrise d’œuvre, le chef du projet, le type du projet, la date de début, la date de fin et le TRI.

- Consulter les statistiques : Le responsable de suivi a le droit de consulter des statistiques concernant les projets, les filiales, les types de projet, les surfaces globales des projets, le TRI moyen des filiales, la répartition des projets par région, etc. Ceci offre à la DSPR l’information synthétisée concernant les différents projets de toutes les filiales.

Top management (cf. Figure 8) :

Le rôle Top management est réservé au président et à l’administrateur directeur général de CDG développement.

Consul ter l es proj et sécuri sés

<>

T op management

Générer un rapport descri pti f

Consul ter l es stati sti

ques<>

<>

Authenti fi cati on

Figure 8: Diagramme des cas d'utilisation du Top Management

- Consulter les projets sécurisés : Le groupe Top management a le privilège de consulter les projets sécurisés ou bien les projets top secret. Il accède aux informations classées top secrets relevant d’un partenariat stratégique ou concernant un projet non encore dévoilé.

Chef de projet (cf. Figure 9) :

Parmi les principaux acteurs de la filiale, le chef de projet est chargé de renseigner et de mettre à jour les différentes informations concernant un projet.

Aj outer un nouveau proj et<>

Authenti fi cati on

Chef de proj etMettre à j our un proj et <>

Figure 9: Diagramme des cas d'utilisation du chef de projet

- Ajouter un nouveau projet : le chef de projet a le droit d’ajouter un nouveau projet en renseignant les différentes informations liées à ce projet à savoir les tranches, les sous tranches, les fichiers liés à ce projet, les partenaires et les opérateurs.

- Mettre à jour un projet : le chef de projet peut aussi mettre à jours les informations relatives à son propre projet.

Directeur de projet (cf. Figure 10) :

C’est le supérieur hiérarchique d’un chef de projet. Il prend en charge la validation et la publication (rendre le projet visible pour l’utilisateur groupe) des informations d’un projet créé par le chef de projet.

Val i der un proj et<>

Authenti fi cati on

Di recteur de proj et publ i er un proj

et<>

Figure 10: Diagramme des cas d'utilisation du directeur de projet

- Valider un projet : pour que les projets soient visibles au niveau CDG Développement, il est nécessaire que ces projets soient valides. c’est le directeur de projet qui se charge de valider les projets qu’il supervise.

- Publier un projet : le directeur de projet rend un projet public, pour qu’il soit visible à l’utilisateur groupe.

2.4 Description des fonctionnalités

2.4.1 Architecture fonctionnelle

Pour minimiser les risques liés au développement et garder une certaine indépendance entre les différentes briques fonctionnelles du futur système, nous avons choisi d’articuler l’architecture fonctionnelle sur six modules :

- Gestion des projets- Recherche multicritère- Edition des rapports- Statistiques- Carte- Administration

La figure 11 présente l’architecture adoptée en précisant les fonctionnalités de quelques modules.

Figure 11: Architecture fonctionnelle du système

2.4.2 Module de gestion des projets

Gestion d’un projet

L’ajout d’un projet permet de faire le suivi et la gestion des différentes phases qui le constituent depuis son lancement jusqu’à sa clôture. La particularité de l’ajout de projets est que chaque projet possède un identifiant construit à partir d’un compteur propre à la filiale à laquelle il appartient. En effet, à chaque filiale on attribue un compteur. La combinaison de ce dernier, de l’acronyme de l’organisme et de l’année de son lancement constitue l’identifiant du projet. Cette méthode d’affectation d’identifiant permet d’avoir un bon nombre d’information sans effectuer des recherches supplémentaires. On peut ainsi connaître la maîtrise d’ouvrage, l’année de lancement du projet et l’ordre du projet à partir de son identifiant.

Un projet regroupe un ensemble d’informations telles les tranches qui le constituent, les partenaires et les opérateurs du projet, les documents qui y sont attachés ou encore le journal des actions effectuées. Lors de la mise à jour de l’une de ces informations, le projet n’est plus valide et nécessite donc une validation par le directeur de projet.

La consultation de la liste des projets donne un aperçu sur les informations générales concernant chaque projet (le nom du projet, la maitrise d’ouvrage, l’avancement et le montant d’investissement…). Toutefois, il est possible d’avoir plus de détails en accédant à la fiche du projet voulu. Cette fiche, accompagnée d’une image illustrative, liste l’ensemble des informations renseignées sur le projet.

Puisque l’état d’avancement d’un projet est une information clé qui permet d’évaluer la progression du projet et le respect des délais initialement prévus, on a jugé intéressant d’offrir à l’utilisateur la possibilité de consulter les projets suivant un tri qui porte sur l’état du projet. La consultation se fait alors selon que le projet soit en cours, achevé, pas commencé, suspendu ou archivé. Ainsi un utilisateur souhaitant consulter uniquement les projets en cours ne sera pas contraint de parcourir la liste de tous les projets, sa consultation sera ciblé et ceci permet une exploitation plus efficace de l’information et favorise l’optimisation du temps en permettant un accès plus rapide aux données.

Diagramme de Gantt des projets

A partir des informations renseignées par le chef ou le directeur de projet sur les tranches et les sous tranches, un diagramme de Gantt est automatiquement généré. Ce diagramme est accessible à partir de la fiche projet. On peut y voir les dates de début et de fin ainsi que l’avancement de chaque tranche ou sous

tranche.

En plus du diagramme de Gantt spécifique à chaque projet, un diagramme de Gantt regroupant tous les projets listés peut être consulté à partir de la liste des projets. Ce diagramme a la particularité de résumer l’avancement de tous les projets, mettant ainsi en évidence les projets qui sont en retard ou qui sont suspendus.

Journal

L’application permet d’affecter à chaque projet un journal contenant la description des opérations effectuée sur le projet. Cette description précise la nature de l’opération effectuée (ajout, modification, validation, publication, etc.), la date de l’opération et également l’intervenant qui a effectué l’opération. Le journal permet de contrôler l’accès aux projets et constitue une bonne référence en cas d’anomalie. Ceci aide à diminuer la saisie de l’information erronée, la publication de projets qui ne sont pas encore validé ou la suppression de projets appartenant à plusieurs filiales sans que ces dernières aient donné leur accord.

Fond documentaire

Les fichiers attachés à un projet (images, documents, rapports) servent à mieux décrire le projet. Il existe alors une fonctionnalité qui offre la possibilité de consulter et d’ajouter tout document nécessaire pour la description du projet aussi bien du côté fonctionnel, organisationnel ou financier.

2.4.3 Module d’édition des rapports

Les rapports d’état

La génération automatique de rapports (en format WORD ou PDF) constitue l’un des points forts du système. Un utilisateur peut donc générer et puis télécharger un rapport contenant les fiches des projets qui l’intéressent. Chaque fiche reprend les informations clé du projet plus une image illustrative. Il faut préciser que chaque fiche est accompagnée de la date de sa création permettant ainsi aux responsables de suivi de construire un historique des états du projet.

Les présentations

Comme pour l’édition des rapports, un utilisateur peut

générer automatiquement une présentation (Power Point) concernant un projet ou une liste de projets. Pour un projet, une présentation est composée de deux slides. Le premier slide affiche trois images concernant le projet. Le deuxième slide liste les informations clé de ce projet.


2.4.4 Module de la recherche multicritère

Le volet recherche permet de rechercher des projets spécifiques, obéissant à certains critères. Pour un directeur de projet qui s’occupe de la supervision d’un certain nombre de chefs de projet, il serait intéressant de pouvoir consulter les projets concernant un chef de projet déterminé sans avoir à consulter la liste de tous les projets.

Parmi les principaux critères de recherche, on peut citer :

- Le nom du projet ;- Le maître d’ouvrage ;- Le maître d’ouvrage délégué ;- La ville ;- La région ;- Le chef de projet ;- Les dates de début et de fin ;- Le TRI ;- Le type du projet.

2.4.5 Module des Statistiques

Étant donné que le rôle de l’application est de permettre le suivi de projets, il est pertinent d’élaborer un certain nombre de statistiques pouvant être très utiles pour l’aide à la décision. Les statistiques concernant le montant d’investissement global des projets réalisés par filiale, par type de projet, par région et par surface permettront d’analyser la variation de ce montant en fonction des ces paramètres.

Un décideur peut, à travers ces statistiques, remarquer l’importance que prend un type de projet en termes de montant d’investissement par rapport à d’autres types qui pourront être tout aussi bien rapporteur de bénéfice, ce qui lui permettra de faire le point sur la politique adopté dans la réalisation de projet afin de pouvoir l’adapter aux besoins changeants du marché.

2.4.6 Module de la carte


La représentation des projets sur une carte géographique du Maroc permet d’estimer leur répartition en fonction des régions, de détecter ainsi les régions les moins


exploités et où il serait intéressant d’investir. D’un autre côté, la consultation de projets sur une carte permet de rendre l’application plus conviviale.

2.4.7 Module d’administration

L’administration permet de faire la gestion des filiales, des utilisateurs, des partenaires et des opérateurs. Cette gestion comprend l’ajout, la consultation, la modification et la suppression de ces différentes entités. A travers ce module l’administrateur peut ajouter de nouveaux utilisateurs en leur attribuant un login et un mot de passe pour qu’ils puissent accéder aux fonctionnalités de l’application selon leurs profils.

L’utilisateur a la possibilité de changer le mot de passe, en accédant à ses paramètres personnels. Il peut alors redéfinir un nouveau mot de passe sans avoir recours à l’administrateur.

Conclusion

Dans ce chapitre, nous avons défini les acteurs du système en décrivant leurs rôles et leurs principales tâches. Tout au long de la section nous avons parcouru les fonctionnalités et les services que propose l’application.

Le chapitre suivant présente la conception détaillée du projet.

Chapitre 3 : Analyse et conception



Pour présenter le travail effectué dans cette phase, nous allons tout d’abord détailler les diagrammes de séquence élaborés qui nous ont permis de dégager la composition interne du système en termes d’objets, puis nous allons présenter le modèle analytique des données à travers les diagrammes de classes.



3.1 Comportement et traitement des données

Les diagrammes de séquence sont des diagrammes d’interactions qui permettent de modéliser les scénarios. Ils ont pour objectif de mieux représenter les interactions entre les objets de notre projet selon un point de vue temporel.

Ainsi, nous présentons à titre indicatif 5 exemples de diagrammes de séquence décrivant quelques scénarios d’utilisation.

Ouverture de session

Le premier diagramme de séquence illustré dans la figure 12 correspond au scénario commun à tous les utilisateurs. En effet, chaque utilisateur disposant d’un compte dans la base de données doit d’abord s’authentifier sur le système pour avoiraccès aux fonctionnalités correspondantes à son rôle.

A u t en t i f i ca t i o n P e rsonn e S e ssi o n Fi l e

Uti l i sateur

DmderLogi n()

l ogi n

DmderLogi n()

Authenti fi

er() Logi

n(Fal se)

Logi n(T rue) créerDossi erT emporai re()

servi ces

deconnecter()suppri merDossi erT emp()

fermerSessi on()

DmderLogi n()

Figure 12: Diagramme de séquence d'ouverture de session


Chapitre 3 : Analyse et conceptionLa première étape correspond naturellement à la saisie du login et du mot de passe de l’utilisateur. Le couple (login, mdp) est ensuite recherché dans la base de données. Dans le cas où l’authentification échoue un message est renvoyé à l’utilisateur l’incitant à vérifier son login et son mot de passe. Si l’authentification réussie, le système crée un

dossier temporaire qui va héberger tous les fichiers temporaires créés durant la session. L’utilisateur peut ensuite accéder à tous les services que lui permet son profile. A la déconnexion, le dossier temporaire est bien évidemment supprimé et la session devient invalide.

Administration des utilisateurs

L’administration des utilisateurs relève des tâches de l’administrateur fonctionnel de l’application. Le diagramme de séquence ci-dessous (cf. Figure 13) illustre le scénariod’ajout d’un nouvel utilisateur.

A d m i n A ct i o n O rgan i sm e Co m p t eu r P e rsonn e

Admi ni strateur

aj outerOrgani sme()

demanderInfos

i nfos

val i derInfos()créerOrgani sme()

affecterCompteur()

aj outerChefProj et() sel ecti onnerOrgani sme()

l i steDi recteurs

sai si rDi recteur() créerPersonne()

suppri merCompte() suppri merCompte()

Figure 13: Diagramme de séquence d'administration des utilisateurs

Dans notre cas, nous supposons que la filiale à la quelle appartient le nouveau utilisateur n’existe pas dans la base de données. L’administrateur doit donc ajouter ledit l’organisme avant de procéder à la création du nouveau compte utilisateur. Après avoir renseigné les données sur la filiale et si les informations respectent les contraintes de saisie, un nouvel enregistrement est stocké dans la table des organismes.

Il faut préciser qu’à chaque organisme correspond un compteur. Ce compteur a pour but de gérer les identifiants des projets menés par cet organisme. En effet, grâce à ce compteur, nous pouvons déjà disposer de quelques informations sur le projet rien qu’en consultant son identifiant. Par exemple, « CGI-3-2008 » correspond au troisième projet de la CGI en 2008. Dans le diagramme de séquence, nous remarquons qu’à chaque fois qu’un nouvel organisme est créé un compteur lui est affecté.

Après avoir renseigné les informations sur la filiale, l’administrateur peut ensuite créer des comptes utilisateurs pour les collaborateurs qui y travaillent. Le diagramme illustre le cas de l’ajout d’un nouveau chef de projet ; L’administrateur demande le service de création d’un nouveau chef de projet, il sélectionne l’organisme, choisit le directeur de projet (En supposant qu’il est déjà dans la base de données) qui est en général le supérieur hiérarchique du chef de projet.

Gestion de projets

La gestion des projets relève des missions du chef de projet ou du directeur de projet dans la filiale. En effet, un directeur de projet peut non seulement valider et publier les informations renseignées par le chef de projet mais aussi créer son propre projet ou un projet qu’il va assigner à un chef de projet. Le diagramme de séquence ci-dessous (cf. Figure 14) illustre le cas d’un chef de projet ajoutant un nouveau projet puis modifie les données renseignées.

P ro j e t i n t e rf a ce P ro j e t Fo rm

P ro j e t A ct i o n

P ro j e t Fi l e Jou rna l

Chef de proj et

sasi rDonnées()

val i derFormul ai re()

val i dati on(Not OK)

add()

aj outerProj et() j ournal i ser()

créerArborescence()

MAJDonnées()val i derFormul ai re()

val i dati on(not OK) modi fy()

modi fi erProj et() j ournal i ser()

i nval i der()

Figure 14: Diagramme de séquence de gestion de projets

Bien entendu après authentification, le chef de projet émet la demande de créer un nouveau projet. Il saisie les informations requises qui vont être validées. Si les données respectent les contraintes spécifiées, un nouvel enregistrement est stocké dans la base de données et l’action est journalisée (D’une manière plus général, chaque action que ce soit ajout, modification, suppression ou génération de rapport est journalisée de façon à garder une traçabilité des actions effectuées par les différents utilisateurs). A chaque projet dans la base de données, correspond une arborescence dans le système de fichier du serveur. Ces dossiers hébergent les documents, images ou rapports uploadés par les utilisateurs ou générés par le système. Cette arborescence de dossier est donc créée en même temps que le projet comme on peut

le voir sur le diagramme.

La mise à jour des données s’effectue de la même manière. Premièrement, la saisie et la validation des informations, ensuite la mise à jour dans la base de données. Il faut préciser qu’après une mise à jour d’une information relative au projet, ce dernier est invalidé et doit faire l’objet d’une validation par le directeur de projet.

Suivi de projet

Le suivi des projets est assuré au niveau de CDG Développement par les responsables de suivi. C’est une mission de consolidation de l’information, de préparation des rapports, des fiches de synthèse et des présentations. Ce travail étant destiné au pôle stratégique et au conseil d’administration. Le diagramme de séquence ci-dessous (cf. Figure 15) illustre le processus de génération de rapports et des présentations par un responsable de suivi.

Repo rt A ct i o n Repo rt P ro j e t Fi ch i e r

Responsabl e de sui vi

Choi si rT ypeRapport() créerRapport()

getLi steProj ets()

l i ste

getFi chi er()

i mage

rapportgénérerRapport()

rapport

Choi si rProj ets()créerPrésentati on()

getLi steProj ets()

retournerLi ste()

getLi steImages()

retournerImages()

tél échargerPrésentati on()

générerPrésentati on()

Figure 15: Diagramme de séquence de suivi de projet

Dans un premier temps, l’utilisateur choisit les projets et le type de rapport qu’il veut générer (PDF ou WORD). Durant le processus de génération de rapport, la liste des projets sélectionnés est renvoyée par les classes de mapping. L’image principale relative au

projet (uploadé précédemment par le chef de projet) est aussi renvoyée pour la construction du rapport.

Le même processus est appliqué à la génération de présentation sauf que dans ce cas, il y a 3 images au lieu d’une seule.

Validation de projet

La validation et la publication des données d’un projet relève des tâches du directeur de projet (supérieur hiérarchique du chef de projet). La validation est le mécanisme qui assure au responsable de suivi une information fiable et valide. Il faut préciser qu’au niveau de CDG Développement, les informations ne sont visibles que si elles sont validées. Au sein même de la filiale, un directeur de pôle (supérieur hiérarchique du directeur de projet) ne voit que l’information valide. Le diagramme de la figure 16illustre le processus de validation d’un projet.

P ro j e t T ran ch e sou s t ran ch e Repo rt Jou rna l

Di recteur de proj etconsul terFi che() getLi steT

ranches() getLi steSST ranches()

fi chetranches

soustranches

val i derProj et() générerRapport()

val i derT ranche()

j ournal i ser()

val i derSsT ranche()

val i date()

publ i erProj et()

publ i sh()

Figure 16: Diagramme de séquence de validation de projet

Le directeur de projet doit d’abord accéder à la fiche de projet. Il valide ensuite le projet qui déclenche un processus de validation des tranches du projet et des sous

tranches des tranches. Cette validation consiste à changer le statut des valeurs temporaires en valeurs valides. Le mécanisme de validation déclenche aussi une génération d’un rapport de synthèse (dans le dossier rapports de l’arborescence relative au projet). Ce fichier est écrasé s’il s’agit du même mois. Ceci permet de garder une trace de l’information valide tout au long des mois de l’année.

3.2 Composition du système

Après avoir élaboré les diagrammes des cas d’utilisation et de séquences, nous passons à la décomposition du système.

Ainsi, le diagramme de paquetage illustrant cette décomposition est le suivant :

Mappi ng Entrepri se

Appl i cati on

Stati sti ques T ool s Presentati on

Reporti ng Gantt T ags

Figure 17: Diagramme de package du système

Les principaux packages qui forment le noyau du système sont :

- Présentation : Ce package englobe toutes les classes qui ont

une relation avec la couche présentation du projet à savoir les Actions et les Forms.

- Application : Ce package contient l’ensemble des classes représentant la couche applicative du système. Ces classes offrent des services au package présentation et demande des services au package entreprise.


- Entreprise : Ce package encapsule toutes les classes permettent de servir le package Application, au sien de ses classes on peut ouvrir une connexion Hibernate en faisant appel au package mapping.

- Mapping : Ce package contient les classes relatives aux objets du mapping objet/relationnel, ces classes sont générées par Hibernate.

- Tags : Ce package englobe des classes permettant d’alimenter les listes déroulantes qui sont déclarées à partir des tags.

- Tools : Il rassemble les classes qui ont une utilité commune et une utilisation récurrente par les autres classes des autres packages de notre projet (formatage des dates, manipulation des fichiers, cryptage des données, etc.).

- Gantt : Ce package concerne la génération du diagramme de Gantt d’un projet, ou bien un diagramme de Gantt de l’ensemble des projets sélectionnés.

- Reporting : Ce package contient les différentes classes permettent la génération d’un rapport PDF ou WORD ou encore une présentation POWER POINT.

- Statistiques : Ce package contient des classes permettent de générer des statistiques concernant les projets, les filiales, les régions, etc.

3.3 Analyse des données

Dans ce paragraphe, nous allons découvrir les principales classes auxquelles a abouti notre analyse des données. Compte tenu des spécifications établies dans les chapitres précédents et la réalisation du dictionnaire des données, notre diagramme de classes est constitué des classes listées dans le tableau 2 :


JavaBean CommentaProje Regroupe les informations élémentaires d’un Tranc

heun projet peut avoir plusieurs tranches. Parmi les attributs du JavaBean Projet on

SousTranche Une tranche peut avoir plusieurs sous-tranches. Parmi les attributs du JavaBean Tranche on trouve un « set » de tranches.

Vill Bean des propriétés d’une villeRégio Bean des propriétés d’une région

Organisme Représente le maître d’ouvrage ou le maître d’ouvrage délégué d’un projet

Intervenant Représente un partenaire ou un opérateur Person

neChef du projet ou toute personne utilisant le systèmeCompteur Bean associé à un organisme pour la numérotation des projets

TypeProjet Bean associé à un projet pour définir le type de ce projet

Fichier

A un projet correspond un ensemble de documents, et d’images instanciés grâce à

TypeFichier Bean associé à un ficher pour définir son type

Profile

Rôle d’un utilisateur

TypeIntervenant Renseigne sur le type d’un intervenant (opérateur ou partenaire)

EtatProjet Renseigne sur l’état du projet (en cours, suspendu, archivé…)

Tableau 2: Tableau des classes

Pour garantir plus de visibilité et de clarté dans les diagrammes, nous ne présenterons pas toutes les classes dans les figures qui suivent.

Le schéma de la figure 18 illustre le diagramme de classes concernant un projet, ses tranches et ses sous tranches. Il met aussi en évidence l’organisme auquel il appartient et la ville où il se trouve.

tranche

+ I d T r an c h e + nomT ranche+ numero+ dateDebutT ranche+ dateFi nT ranche+ avancementT ranche

1..1

1..* Sous tranch

sous tranche

+ i dEtape+ numeroEtape+ nomEtape+ dateDebutEtape+ dateFi nEtape+ avancementEtape


vi l l e

+ i dVi l l e+ nomVi l l e 0..*

1..1Regi on

regi on

+ i dRegi on+ nomRegi on

0..1Vi l l

e

0..*organi sme

0..*fi l i al e

Organi sme

+ i dOrgani sme+ nomOrgani sme+ rai sonSoci al e+ capi tal Soci al+ statutJuri di que+ si teWeb

0..1MOD 0..*

1..1MO

0..*

0..*

+++++

proj et

i dProj et nomProj et descProj et dateDebut dateFi n

1..1

1..*T ranche

e

Figure 18: Diagramme de classes (dimensions: ville, organisme et tranche)

A un projet correspond un « Set » (ensemble) de tranche. Une tranche à son tour contient un ensemble de sous tranche. La classe projet a une double relation avec la classe organisme. En effet, en plus du maître d’ouvrage, un projet peut avoir un maître d’ouvrage délégué selon les situations. La classe organisme a une relation réflexive permettant de connaître, pour un organisme donné, les filiales qui lui sont affiliées. Enfin, à un projet correspond une ville qui elle-même correspond à une région.

Le schéma de la figure 19 présente un autre volet correspondant à la gestion de projets : le responsable du projet et les intervenants dans ce projet.

personne1..1 Intervenant

+ i dpersonne+ matri cul e+ nom+ prenom+ l ogi n+ mdp

ChefDeProj et + i dIntervenant+ nomIntervenant+ rai sonSoci al e+ capi tal Soci al+ statutJuri di que

: l on g : j ava.l ang.Stri ng: j ava.l ang.Stri ng: l ong: j ava.l ang.Stri ng

0..*Col l aborateur

0..*Partenai re ou Opérateur IntervenantProj et

1..1

Organi sme

+ i dOrgani sme

0..*

0..*

proj et

+ part+ noteProj et

: fl oat: fl oat

+ nomOrgani sme+ rai sonSoci al e+ capi tal Soci al+ statutJuri di que+ si teWeb

0..1MOD

0..*

+ i dProj et+ nomProj et+ descProj et+ dateDebut+ dateFi n

1..1MO 0..*

Figure 19: Diagramme de classes (Dimensions: personne et intervenant)

Dans un projet, on peut retrouver des partenaires d’investissement ou des opérateurs au niveau stratégique ; ce sont les intervenants. Selon le type de l’intervenant il s’agira donc soit d’un partenaire, soit d’un opérateur.

Bien entendu, à un projet correspond une personne. Il peut s’agir d’un chef de projet ou d’un directeur de projet.

3.4 Modèle physique de donnée

Le modèle physique de données représentant les tables de notre base de données relationnelles est illustré dans le schéma de la figure 20:



Figure 20: Modèle physique de données


Ce schéma reprend la logique présente dans les diagrammes de classe. La table projet est la table centrale de la base de données. On peut parler d’un schéma en étoile et de dimensions. Atour de la table projet, gravite les tables de la base de donnée constituant les dimensions du modèle.

Conclusion

Nous avons présenté dans ce chapitre une vue conceptuelle de la solution à mettre en place. Ainsi, nous avons présenté les différents diagrammes UML pour mieux comprendre les fonctionnalités offertes et mieux représenter la communication entre les différents objets du projet.

Chapitre 4 : Réalisation et mise en oeuvre


Chapitre 4 : Réalisation et mise en œuvre

Dans ce chapitre, nous aborderons la partie réalisation du projet. Dans un premier temps nous parlerons des exigences du système avant de passer à l’analyse technique de la mise en œuvre de la solution. Nous parlerons ainsi de l’environnement de développement en présentant la plateforme et les frameworks utilisés. Nous décrirons par la suite l’architecture technique de l’application avant de terminer par la présentation de quelques interfaces d’utilisation.



4.1 Capture de besoins techniques

Pour la branche technique, il s’agit dans un premier temps de spécifier les activités techniques attendues de notre projet, avant d’établir les couches logicielles. Ainsi, la capture des besoins techniques couvre, en complémentarité avec celle des besoins fonctionnels, toutes les contraintes qui ne traitent ni de la description du métier des utilisateurs, ni de la description applicative.

L’architecture logicielle de l’application répond à un certain nombre d’objectifs et contraintes en termes de sécurité, de disponibilité et de maintenance. Le choix d’une architecture logicielle constitue une étape technologique primordiale. En effet, il faut définir les grands objectifs techniques de la future architecture, c’est-à-dire de bien prendre en compte l’ensemble des forces qui vont s’exercer sur le futur système ainsi que la puissance de chacune d’entre elles.

Le tableau suivant fournit plus de détails concernant les objectifs techniques du système:

Objectif Description

Disponibilité être en permanence à la disposition de ses utilisateurs.

Sécurité

assurer un système de sécurité flexible permettant d’accéder aux fonctionnalités du système selon les droits de l’utilisateur, en plus de la gestion des autorisations et des authentifications.Evolutivité permettre d’étendre le système.

Réutilisation inclure la possibilité de réutiliser les modules du système.

Tableau 3: Objectifs techniques du système



4.2 Environnement de développement

- La plateforme J2EE

L’élaboration de notre application s’appuie sur la plateforme J2EE. Ce choix est justifié par plusieurs facteurs. D’une part, cette plateforme offre plusieurs avantages à savoir :

-La maturité et la richesse de cette technologie ;

-La possibilité de la réutilisation des différents composants qui en font partie ;

-La séparation forte qu’offre la plupart des frameworks relevant de cette architecture.

Et d’autre part, ce choix est recommandé par les responsables du projet, vu la nouvelle orientation de CDG Développement vers une stratégie d’ouverture à ses filiales. En effet, La solution mise en place doit être indépendante de tout langage de programmation et système d’exploitation. De ce fait, notre solution doit garantir une parfaite interopérabilité, et par la suite, libérer les filiales de CDG Développement de toute contrainte technologique.

- Méthodologie de développement : la démarche MVC

La plateforme adaptée pour le développement de ce projet est la plateforme J2EE. Celle-ci offre une panoplie d’outils et de frameworks permettant la mise en place d’une architecture fiable et évolutive. Le modèle le mieux adapté à ce type de projet est le modèle MVC (Modèle - Vue – Contrôleur). En effet, Le modèle MVC cherche à séparer les couches présentation, traitement et accès aux données, ce qui assure la clarté de l’architecture et simplifie la tâche du développeur responsable de la maintenance et de l’amélioration du projet. Les différentes interactions entre le modèle, la vue et le contrôleur sont résumées par le schéma de la figure 21.

des 2008Abbes SADI / Omar HAJI 59 Projet de fin d‘étu


Figure 21: Architecture Modèle-Vue-Contrôleur

L'interface utilisateur est un navigateur web à partir duquel l’utilisateur accède à l’ensemble des fonctionnalités de l’application. La logique applicative est constituée des scripts traitant les demandes de l'utilisateur. La source de données est une base de données (SQL Server dans notre cas) qui contient l’ensemble des informations manipulées dans l’application.

- Le framework STRUTS

Le modèle décrit ci-dessus sera implémenté grâce au framework « apache Struts ». En effet, la méthodologie Struts définit une méthode de développement standard qui respecte l’architecture MVC pour les applications web écrites en JAVA. La figure 22 montre comment Struts implémente cette architecture.

des 2008Abbes SADI / O


Figure 22: L'implémentation du modèle MVC par Struts



Tout au long de la réalisation il s’agira donc de:

- Définir des vues. Ce sont des pages JSP qui constituent l’interface entre l’utilisateur et l’application ;

- Ecrire des classes Javabean correspondant aux formulaires ;- Ecrire des classes Action chargées de traiter les informations des formulaires ;- Ecrire d’éventuelles classes métier ou d’accès aux données.

- Le framework HIBERNATE

Travailler dans les deux univers que sont l'orienté objet et le relationnel peut être lourd et consommateur en temps. Hibernate est un outil de mapping objet/relationnel pour le monde Java. Il 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 aussi de requêter les données et propose des moyens de les récupérer. Il peut donc réduire de manière significative le temps de développement qui aurait été autrement perdu dans une manipulation manuelle des données via SQL et JDBC.

Hibernate réduit de 95% les tâches de programmation liées à la persistance des données. C’est l’une des meilleures solutions pour les applications centrées sur le traitement des données. il est le plus utile dans les modèles métier orientés objets dont la logique métier est implémentée dans une couche intermédiaire Java. Hibernate permet aussi la transformation des données d'une représentation tabulaire à une représentation sous forme de graphe d'objets.

Hibernate est adaptable en termes d'architecture ; il peut donc être utilisé aussi bien dans un développement client lourd, que dans un environnement web léger de type Apache Tomcat.


Chapitre 4 : Réalisation et mise en oeuvreHibernate apporte une solution aux problèmes d'adaptation entre le paradigme objet et les SGBD en remplaçant les accès à la base de données par des appels à des méthodes objet de haut niveau.



Principaux avantages du framework Hibernate :

- La définition d’une limite claire entre la persistance et la couche métier, ce qui se révèle très utile dans le cas d'une application trois tiers ;

- Les objets métiers sont plus faciles à manipuler ;- Peu de dépendance envers une base de données précise.

Théoriquement, il n'y a que le fichier de configuration à changer si on passe d'une base de données comme SQL Server vers Oracle.

L’annexe B présente Hibernate plus en détails.

- L’API JasperReportsJasperReports est un outil de Business Intelligence et de

reporting. Il peut produire des documents type de manière dynamique, à partir de données existantes, et ce dans divers formats. Il permet notamment de les exporter aux formats: PDF, HTML, XLS, CSV, XML, RTF, TXT. C’est un outil Open Source de création d'états sous Java.

JasperReports se base sur des fichiers XML (dont l'extension est en général .jrxml) pour la présentation des états. Il peut être couplé à iReport (outil WYSIWYG : What You See Is What You Get) pour faciliter sa mise en œuvre dans une application Java orientée web.

JasperReports accepte plusieurs types de sources de données. Que ce soit classiquement une base de donnée, du CSV ou encore des Beans Java.

L’annexe C discute L’API JasperReports plus en détails en présentant quelques une des fonctionnalités qu’il offre.

- L a techn o l ogi e A J A X

Cette technologie, basée essentiellement sur le JavaScript, permet d’accéder de manière asynchrone avec les actions de


Chapitre 4 : Réalisation et mise en oeuvrel’utilisateur à la base de données et ce en utilisant en plus du JavaScript, une classe XMLHTTPREQUEST, qui comporte des méthodes permettant de communiquer avec le serveur, offrant ainsi à l’utilisateur une réponse rapide et instantanée.



La technologie AJAX est présentée plus en détail dans la partie Annexe de ce document.

4.3 Outils de développement

- Environnement de développement intégré : EasyEclipse

EasyEclipse est un projet visant à fournir des packages Eclipse préconfigurés sous forme de "distributions" pour différents usages. Chaque distribution se compose d'une archive contenant la plate-forme Eclipse et différents plugins spécifiques à chaque sujet. Chaque distribution d'EasyEclipse est conçue pour un environnement de développement spécifique avec les fonctionnalités liées à cet environnement.

EasyEclipse est un logiciel gratuit, open source, facile à télécharger et à installer. De plus, il est simple à maintenir et indépendant. Son but est d'augmenter la facilité de l'installation et de l'utilisation de la distribution d'Eclipse.

Nous avons utilisé pour la réalisation de notre projet la version EasyEclipse Server

Java 1.2.2 qui intègre les plugins suivants :

- Eclipse Platform- Java JDK for Windows- Eclipse Java Development Tools- Eclipse Tools- Eclipse Utils Plugins- Color Editor- Sysdeo Tomcat Launcher- Hibernate Tools- Eclipse J2EE tools- Amateras IDE- Eclipse Web tools editors- Eclipse HTML Tidy- Amateras HTML and XML editor- Eclipse Database tools- Eclipse Data Tools- QuantumDB



- Système de gestion de bases de données : SQL Server 2005

Microsoft SQL Server est un Système de gestion de bases de données relationnelles reconnu sur le marché, très complet et c’est l’un des SGBD les plus performants en configuration par défaut. Ses avantages sont multiples :

- Performance : SQL Server se classe parmi les SGBDR les plus rapides.

- Evolutivité et fiabilité : vous pouvez répartir la charge sur plusieurs serveurs, bénéficier des avantages des systèmes multiprocesseurs.

- Rapidité de mise en œuvre : avec SQL Server, le développement, le déploiement et l’administration d’applications destinées au Web sont accélérés grâce aux nombreuses fonctionnalités dédiées.

- Indépendance entre les diverses bases, facilitant l'intégration de plusieurs applicatifs dans une même instance.

- Serveur d’application : Apache TomCat 5.5

Tomcat est un servlet, c'est à dire un programme tournant sur un serveur (Apache) qui gère d'autres servlets, permettant de générer des pages web dynamiques. Il gère en particulier des servlets Java et des pages serveur java (JSP ou Java serveur pages). Il peut être utilisé seul ou couplé avec un autre serveur. Tomcat répond aux spécifications de Sun concernant les servlets et leurs gestionnaires. Il supporte à ce titre l'ensemble des classes définies par Sun dans le document « Java API Servlet Specifications ».

Apache TomCat est totalement gratuit et généralement utilisé en couplage avec un serveur Apache. Ecrit en Java, il nécessite, pour pouvoir fonctionner, la présence d'une machine virtuelle Java,


Chapitre 4 : Réalisation et mise en oeuvreet plus précisément du SDK Sun Developpement Kit complet. Ceci implique qu’il est totalement portable et peut être mis en œuvre sur des systèmes radicalement différents, tels que Linux ou Windows. Dans le cadre de la mise en place de notre application, nous avons utilisé Apache TomCat dans sa version 5.5.



4.4 Architecture logicielle du système

Parmi les différentes façons de structurer une architecture, la mieux comprise et maîtrisée en informatique est l’approche par couches. Une couche (Layer en anglais) est une division logique, horizontale d’un système qui fournit une abstraction particulière du système aux couches supérieures. Chaque couche possède des rôles spécifiques. Dans une structuration par couches, les couches inférieures prennent en charge des rôles qui offrent un fonctionnement de base pour les couches supérieures, permettant par la suite d’abstraire l’implémentation de ces services basiques.

Ainsi, nous avons adopté un découpage en 5 couches. Une telle architecture permet également d’obtenir un bon niveau de réutilisation, à travers l’utilisation des solutions aux problèmes ayant un fonctionnement similaire. Cette exploitation est prise en compte pour chaque couche de l’architecture. La figure suivante résume le découpage adopté :

Figure 23: L'architecture en couches du système



Couche Présentation :

Cette couche est dédiée principalement à la gestion du domaine visuel des applications et aux interactions avec les utilisateurs. Chargée de dessiner les fenêtres et autres composants graphiques, elle intercepte les événements et fait appel aux services de la couche Application.

Les rôles de la couche Présentation sont résumés dans le tableau comme suit :

Rôles

Gestion du domaine de l'écran

Affichage des pages Web

Gestion de l'interaction avec l'utilisateur

Validation syntaxique

Relations

Demandes de contenu à la couche Application pour affichage / édition

Ordres de traitement à la couche Application pour création/ mise à jour / suppressionTableau 4: Les rôles et les relations de la couche Présentation

Couche Application :

Son principal but est de fournir des services spécifiques à la couche Présentation. Ces services correspondent aux règles du métier définies lors de la phase d’analyse. Elle prend en charge les aspects de contrôle des cas d'utilisation. La communication avec la couche supérieure se fait à travers la classe « ApplicationFacade ».



Le Tableau suivant résume les rôles et les relations de la couche Application :

Rôles

Services spécifiques au domaine

Services externes

Contrôle des cas d'utilisation

Relations

Accès aux entités métier de la couche Entreprise pour implémenter les services.

Tableau 5: Les rôles et les relations de la couche Application

Couche Entreprise :

Cette couche est centrée sur le métier de l’application, c'est-à-dire les règles métier, sémantiques et logiques. C’est un package qui comporte les classes chargées, d’une part, de garantir la validation sémantique de l'information métier, et d’autre part, de gérer l’interaction avec la base de données à travers les sessions hibernate fournies par la couche Mapping.

La communication avec la couche Application se fait à travers la Classe

« EntrepriseFacade ».

Le Tableau suivant résume les rôles et les relations de la couche Entreprise :

Rôles

Comportement métier

Validation sémantique

Relations

Echange de l'état des composants entités métier avec la couche Mapping.

Tableau 6: Les rôles et les relations de la couche Entreprise



Couche Mapping

Cette couche est certainement l'une des plus importantes. C'est ici que l'on trouve les fonctionnalités de base qui offrent les mécanismes de conversion objet/relationnel à travers les getters et les setters. Les classes constituant cette couche sont générées par Hibernate.

Le Tableau suivant résume les rôles et les relations de la couche Mapping :

Rôles

Services basiques de Création / Lecture / Mise à jour / Suppression

Conversion Objet/Relationnel

Relations

Echange de l'état des composants entités métier avec la couche Entreprise.

Couche Stockage

Tableau 7: Les rôles et les relations de la couche Mapping

Cette couche est responsable du stockage physique de données. Elle assure le support transactionnel. En ce qui concerne notre système, cette couche se basera sur le modèle relationnel. La base de données est générée à partir d’un script SQL généré lui- même à partir du modèle physique de données.

Les tables existantes sont transformées en classes par Hibernante. Au niveau du code java, le développeur manipule des classes et utilise des requêtes avec le langage HQL. Les actions effectuées sur les instanciations de classes sont répercutées sur les tables de la base de données. Hibernante utilise un mécanisme de cache pour optimiser le traitement des requêtes.

Le Tableau suivant résume les responsabilités et les relations de la couche Stockage.

Rôles

Stockage / restitution des états des composants métier

Gestion transactionnelle avec respect des propriétésRelations

Cette couche stocke les objets du domaine en passant par la couche de Mapping

Tableau 8: Les rôles et les relations de la couche Stockage

4.5 Présentation de quelques interfaces

L’objectif de ce paragraphe est de donner un aperçu de l’interface homme/machine de l’application. Il s’agira aussi de mettre en évidence les points forts de la solution déployée tels la génération des rapports et des présentations ou encore la consultation des statistiques.

La page d’authentification :

Figure 24: La page d'authentification

La page d’accès à l’application demande à l’utilisateur son login et son mot de passe. Cette page a pour but d’éveiller la curiosité de l’utilisateur à découvrir l’ensemble des fonctionnalités offertes. Elle lui donne aussi une image forte de CDG Développement avec le logo qui occupe la partie gauche de la page.

La liste des projets :

Figure 25: La page de la liste des projets

Selon le profil de l’utilisateur, une liste des projets le concernant lui est offerte. Cette interface offre la possibilité d’agir sur les projets de plusieurs manières. D’une part, on peut organiser la liste des projets suivant la propriété qui nous intéresse (le montant d’investissement ou le maître d’ouvrage par exemple). D’ autre part, on peut aussi trier les projets selon leur état ; On peut alors voir les projets qui n’ont pas encore commencés, qui sont en

cours ou suspendus ou encore les projets achevés ou archivés. Pour le chef de projet et le directeur de projet, ils peuvent consulter les projets non encore validés ou non publiés. Le lien « Gantt » ouvre une fenêtre pop-up affichant l’avancement de tous les projets offrant ainsi un visuel graphique des chiffres qu’il voit sur le tableau. Le graphique de la figure 26 montre un exemple de ce diagramme.


Figure 26: Diagramme de Gantt de tous les projets

A partir de cette même page l’utilisateur peut exporter les fiches des projets en cochant ceux qui l’intéressent. Il choisit alors le format qu’il veut (PDF, WORD ou PPT). La figure 27 donne un exemple de deux fiches rapports exportées sous format PDF.

Figure 27: Exemple de rapports d'état


Dans le cas où l’utilisateur choisit de générer une présentation de certains projets, un fichier PowerPoint est téléchargé sur le disque qu’il peut ouvrir ensuite. La figure suivante donne un exemple d’une présentation générée à partir des données de deux projets :

Figure 28: Exemple de présentation

Pour générer des présentations nous avons utilisé l’API POI. POI (Poor Obfuscation Implementation ou mise en œuvre de l'obfuscation pauvre) est un projet de l'Apache Software Fondation permettant de manipuler avec le langage Java divers types de fichiers créés par Microsoft Office, en l’occurrence des fichiers Power Point.


La fiche détaillée d’un projet :

Dans la liste des projets, un chef de projet par exemple peut accéder aux détails d’un projet dont il est responsable pour pouvoir consulter ou éditer les informations. En cliquant sur le nom du projet, il accède à la page présentée dans la figure qui suit :

Figure 29: Tableau de bord d'un projet

Cette page joue le rôle d’un tableau de bord pour les responsables de suivi au niveau de CDG Développement et un espace de gestion pour les chefs de projets au niveau des filiales. A partir de cette fiche, on peut ajouter des objets (des tranches, des sous-tranches, des documents, etc.), valider ou publier le projet (pour les directeurs de projets) ou encore visualiser le diagramme de Gantt, comme le montre la figure 30:


Figure 30: Diagramme de Gantt d'un projet

La recherche multicritère :

La page de recherche offre à l’utilisateur un ensemble de critères suivant lesquels il peut effectuer une recherche sur les projets existants dans la base de données.

La figure 31 donne un aperçu de cette page :

Figure 31: La page de la recherche multicritère


La recherche est effectuée par une requête construite selon les critères sélectionnés. Ainsi, la liste des projets retournée est le résultat de l’exécution d’une requête HQL (Hibernate Query Langage). En effet, Hibernate fourni un langage d'interrogation extrêmement puissant qui ressemble au SQL (Structured Query Langage). La puissance de ce langage vient du fait qu’il est totalement orienté objet. Lors de la recherche, nous construisons donc une requête HQL en utilisant le Javabean associé au formulaire.

Les statistiques :

L’un des points forts de l’application est le module des statistiques. Il s’agit d’une synthèse globale des activités du groupe à travers divers diagrammes. Dans le menu, le lien « Statistiques » renvoie l’utilisateur vers une page où il peut visualiser plusieurs diagrammes représentant quelques statistiques calculées à partir de la base de données.

Le module des statistiques a été totalement implémenté en utilisant l’API JFreeChart. Cette API Java permet de créer des graphiques et des diagrammes de très bonne qualité. Cette API est open source et sous licence LGPL. Par contre, la documentation est payante.

La figure 32 donne un aperçu de ce qu’on peut visualiser :


Figure 32: Page des statistiques


En cliquant sur l’un des diagrammes, une fenêtre pop-up s’ouvre avec une image plus grande pour plus de visibilités.

Parmi les diagrammes les plus importants on trouve le diagramme du TRI moyen par filiale (taux de retour sur investissement par filiale). Ce diagramme résume l’ensemble des activités d’investissement d’une filiale en calculant le TRI moyen des projets de cette filiale. On peut voir ce diagramme plus en détails dans la figure 33 :

Figure 33: TRI moyen des filiales

CDG Développement est l’un des acteurs majeurs dans le développement du territoire. Il est aussi pertinent pour les responsables de suivi de voir les zones où il y a plus de projets, c’est-à-dire plus d’investissement. Le diagramme de la figure 34 donne la répartition des projets de CDG Développement suivant les régions :


Figure 34: Inventaire des projets par région

La visualisation de la carte :

Figure 35: Carte des projets et réalisations


Cette page permet à un utilisateur de naviguer à travers les villes du pays pour parcourir tous les projets que mène CDG Développement dans territoire national.

En cliquant sur une ville, une liste des projets se trouvant dans ville apparait. On peut alors cliquer sur l’un des projets pour consulter ses informations plus en détail.

Toute fois, il faut signaler que l’ajout d’une ville sur la carte nécessite une intervention du développeur pour mettre à jour la liste des villes.

Pour implémenter ce module, nous avons utilisé la solution de développement Flex. Flex est un framework Open Source très productif, qui permet de créer et de mettre à jour des applications web efficaces se déployant à l'identique sur la plupart des navigateurs, postes de travail et systèmes d'exploitation. Pour sa partie présentation, Flex utilise la technologie Flash (on estime aux alentours de 97% le nombre de machines équipées du Flash Player), ce qui rend par conséquent les applications Flex relativement multi plates-formes et facilement déployables. Ce dernier point étant discutable, étant donnée l'installation nécessaire d'un plug-in Flash Player sur les machines clientes, ce qui n'est pas le cas avec une interface écrite selon la méthode AJAX car tous les navigateurs Web autorisent par défaut le JavaScript. Cependant, l'interprétation de Javascript étant différente selon les navigateurs, un des intérêts de Flex est de proposer une interface homogène, quel que soit l'équipement de l'utilisateur.

Conclusion

Dans ce chapitre, nous avons présenté la plateforme de développement ainsi que l’ensemble des frameworks sur lesquelles nous avons basé la phase de mise en œuvre. Nous nous sommes


aussi intéressés à l’architecture technique de l’application en présentant le modèle en couches. Pour finir, nous avons donné un aperçu de l’IHM réalisée.

Le chapitre suivant a pour objectif la validation du travail effectué en présentant un scénario d’utilisation.

Chapitre 5 : Validation et scénario d’utilisation



Dans ce chapitre, nous reposons la problématique en comparant le travail accompli par rapport aux objectifs établis. Nous présentons aussi le macro-diagramme d’activités avant de terminer avec un scénariod’utilisation.

Figure 36: Boucle de validation de la solution proposée



4.1 Réponse à la problématique

L’objectif initial était de mettre en place un système de gestion et de suivi des projets de CDG Développement et ses filiales. La problématique était d’assurer une gestion centralisée des différents projets du holding. La recherche, la consolidation et la synthétisation de l’information constituent le cœur du métier de la DSPR. Le système mis en place répond-t-il à cette problématique ?

Le système réalisé permet à un chef de projet d’une filiale donnée de créer un projet et de renseigner les différentes informations liées à ce projet :

- Les tranches constituant le projet ;

- Les sous tranches liées aux tranches ;

- Les fichiers (images, documents, rapports ou autres) liés au projet ;

- Les partenaires du projet avec leur participation.

Ensuite, le directeur de projet, qui est le supérieur hiérarchique du chef de projet, est amené à valider les différentes informations saisies et à compléter les informations manquantes. La validité et la disponibilité de l’information est ainsi assurée.

Le Responsable de suivi, au niveau de la DSPR, peut consulter la fiche descriptive du projet contenant les informations sur l’état d’avancement (validé par le directeur de projet). Il peut consulter le diagramme de Gantt du projet mettant en valeur l’état d’avancement de chaque tranche et de chaque sous-tranche. Il peut aussi télécharger les fichiers liés au projet et uploader de nouveaux fichiers. De plus, le responsable de suivi peut visualiser les partenaires, les opérateurs ainsi que le journal des actions (qui fait quoi et quand). Ceci offre au responsable de suivi une vision globale des projets menés par les filiales facilitant ainsi sa mission de suivi.


Chapitre 5 : Validation et scénario d’utilisationCitons aussi qu’on peut générer des rapports et des présentations concernant les projets, ces documents étant destinés à être présentés à la direction générale.

Ainsi, le système constitue pour CDG Développement et ses filiales une plateforme d’échange et un outil de reporting puissant et fiable quant à la validité de



l’information. L’ensemble des services proposé par notre système répondent effectivement aux besoins spécifiques de la DSPR.

4.2 Description du fonctionnement du système

La figure 37 présente le diagramme d’activités qui illustre la séquence du mécanisme de gestion et suivi des projets :

Authenti fi cati on au système

Véri fi cati on du l ogi n et du mot de pass

Véri fi cati on du profi l[OUI] [NON]

Véri fi cati on du profi l "Chef de proj et"

Créati on d'un nouveau proj et

[OUI] [NON]Véri fi cati on du profi l "Di recteur de proj et"

Mi se à j our du proj et

[OUI][NON]

Véri fi cati on du profi l "Responsabl e sui vi "

Val i dati on du proj et

[NON]

Générarti on d'un rapport mensuel

[OUI]

Consul tati on des i nformati ons val i des du proj et

T él échargement du rapport mensuel

Générati on des présentati ons

Générati on des fi ches proj ets

Figure 37: Diagramme d'activité du processus de suivi

1. L’utilisateur s’authentifie sur le système ;2. Le système vérifie son login et son mot de passe ;3. En cas de succès, le système vérifie le profil de l’utilisateur

connecté pour lui offrir ses droits et ses fonctionnalités;4. Dans un premier temps, le système commence par vérifier si

l’utilisateur connecté est un « chef de projet » ;5. En cas de succès, le système donne la main au chef de

projet pour créer un nouveau projet (c’est la fonctionnalité principale d’un chef de projet) ;

6. Ensuite, le système donne la possibilité au chef de projet de mettre à jour le projet;7. En cas d’échec, le système vérifie, si l’utilisateur connecté

est un « directeur de projet »;8. En cas de succès, le directeur de projet est amené à

valider les informations relatives à un projet déjà créé par un chef de projet. Après la validation, le système génère un rapport d’état pour le mois en cours ;

9. En cas d’échec, le système vérifie, si l’utilisateur connecté est un « responsable de suivi » ;

10. En cas de succès, le responsable de suivi, pour bien accomplir sa mission de suivi, est amené à consulter les informations valides du projet, en suite le responsable de suivi peut télécharger le rapport mensuel, générer des présentations ou bien générer les fiches descriptives des projets.

4.3 Scénarios d’utilisation

Pour valider cette application, nous proposons le scénario d’utilisation qui suit :

Tout d’abord, l’administrateur s’authentifie est crée une filiale, un directeur général pour cette filiale, un directeur de pôle, un directeur de projet en affectant ce directeur de projet au directeur

de pôle récemment crée, un chef de projet et affecte ce chef de projet au directeur de projet de la même filiale. Ensuite l’administrateur crée des partenaires et des opérateurs potentiels aux projets de CDG Développement et ses filiales.

Après, le chef de projet de la filiale s’authentifie et crée un nouveau projet en précisant les tranches du projet, les sous tranches des tranches, les fichiers liés au projet et il affecte des partenaires et des opérateurs au projet (ajoutées au préalable par l’administrateur dans la base de données).

Ensuite, le directeur de projet s’authentifie et valide les informations saisies par le chef de projet. Après un rapport mensuel est généré automatiquement.

Maintenant, que les informations du projet sont valides, le responsable de suivi peut consulter les informations relatives au projet. Il peut générer des présentations, des fiches descriptives ou encore télécharger les documents liés au projet,

Ensuite, un directeur de pôle peut s’authentifier, pour consulter les fiches des projets de son pôle, il peut visualiser le diagramme de Gantt des tous les projets de son pôle.

Puis, le directeur général de la filiale se connecte au système pour voir l’état d’avancement de tous les projets en cours.

L’utilisateur groupe se connecte au système pour consulter les projets publics.

Conclusion

Nous avons vu sans cette section que le système répond bien à la problématique posée. Nous avons ainsi présenté le diagramme de workflow avant de terminer par un scénario d’utilisation.

Conclusion et perspectives

Conclusion et perspectives

Notre mission a consisté en l’étude, l’analyse, la conception et la mise en place d’une solution informatique de gestion et de suivi des projets de CDG Développement et ses filiales. Cette solution a pour objectif d’optimiser les activités opérationnelles de la DSPR en automatisant les supports de suivi des projets et réalisations.

Pour réaliser ce projet, nous avons adopté le processus de développement en Y (2TUP). Nous avons commencé par une étude de l’existant avant d’aborder les deux branches fonctionnelle et technique du cycle de développement. Au terme de ces deux branches, nous avions établit un architecture fonctionnelle et logicielle répondants aux besoins et aux exigences du système. Lors de la phase de la conception, nous avons présenté les différents diagrammes UML pour mieux comprendre la communication entre les différents objets du projet. Enfin, nous avons mis e œuvre notre solution de gestion et suivi des projets.

Le stage que nous avons effectué au sein de CDG développement nous a donné l’occasion de faire le lien entre nos connaissances académiques et le monde professionnel. D’une part, Ils nous ont permis de développer nos compétences techniques, d’approfondir nos connaissances théoriques et pratiques et de stimuler notre créativité. D’autre part, l’environnement de travail nous a permis d’améliorer notre savoir-faire et notre rigueur et d’affermir notre esprit d’équipe et notre professionnalisme. Enfin, cette expérience a aiguisé nos capacités d’analyse et de synthèse et a surtout fortifié notre motivation, notre détermination et notre ambition.

Conclusion et perspectivesNotre projet constitue une solution complète et fiable pour la

gestion et le suivi des projets nationaux. En perspective pour ce projet, nous envisageons de développer une deuxième version de la solution pour prendre en compte les projets internationaux du holding. Des modules complémentaires pourront être intégrés à la solution comme la gestion financière des projets.

Bibliographie

Bibliographie

Ouvrages

[CHRGAV

06]

[DAV06]

[GIU07]

[GJI99]

[JAM06]

[RYANAT0

2]

[TCG02]

Christian Bauer & Gavin King, Java Persistence With Hibernate, Manning Publications Décembre 2006.David Heffelfinger, JasperReports: Reporting for JavaDevelopers,Packt Publishing 1 edition July 2006.Giulio Toffoli, The Definitive Guide to iReport (Expert's Voice), Apress 1 edition August 2007.G.Booch, J. Rumbaugh & I. Jacobson, “The Unified modelingLanguage User Guide”, Addison-Wesley 1999.James Holmes, “Struts: The Complete Reference”, McGrawHill/Osborne 2nd Edition 2006.Ryan Asleson & Nathaniel T.Schutta, Pro Ajax and JavaFrameworks, Apress July 2006.Ted Husted & Cedric Dumoulin & George Franciscus, Struts in Action: Building Web Applications With the Leading Java Framework, Manning Publications Novembre 2002.

Adresses Internet[wwwAJAX]

h tt p : // ajax t a g s . s o u rce f o r ge . ne t / Site officiel de “AjaxTags”

[wwwDEV] http://www.developpez.com/Portails de développeurs

[wwwIREP] www .ja s per f orge . org/ ja s per s o f t / open s o u rce/b u s i ne ss _ i n t e lli gence/ i repor t / Site officiel de Jasperforge (Documentation de iReport)

[wwwJASP] h tt p : // ja s p errepo r ts . s o u r ce f orge . ne t / Site officiel de Jasperforge (Documentation

http://jasperreports.sourceforge.net/

http://www.jasperforge.org/jaspersoft/opensource/business_intelligence/ireport/

http://www.jasperforge.org/jaspersoft/opensource/business_intelligence/ireport/

http://www.developpez.com/

http://ajaxtags.sourceforge.net/

http://ajaxtags.sourceforge.net/

Bibliographiede JaserReports) [wwwJFRE] h tt p : //w w w .jf ree . org/ jf reech a r t /

Site officiel de l’API JFreeChart[wwwWIKI] http://fr.wikipedia.org/wiki/Accueil

Encyclopédie virtuelle sur le net

http://fr.wikipedia.org/wiki/Accueil

http://www.jfree.org/jfreechart/

Annexes

Annexes

Ann e x e A : P l a n Assu ra n c e Qu a lité

Annexe A : Plan Assurance Qualité



Projet : Mise en place d’une solution informatique pour le suivi des projets et réalisations

Réf Projet : 03/2008

PLAN D’ASSURANCE QUALITE

Description :

Sujet Plan d’Assurance Qualité

Auteur Equipe Projet

Version 1.0

1Etat En approbation

Diffusion2 Interne

Liste de diffusion :

Pour Validation Pour Information

M. Amine ElHajhouj Mme Alaoui Fatime Zahra

M. Benchrifa Souhail M. Mounir EL Farissi

1EN PREPARATION, EN APPROBATION, VALIDE

2 Interne / externe



Historique des révisions :

Date Version Commentaire Auteur



IntroductionLe présent document a pour but de définir et de

décrire la structure organisationnelle du projet, les livrables, les documents et les règles établies au sein des différents groupes de projet afin de valider la norme qualité définie.

Ce document constitue une référence quant à l’organisation structurelle et fonctionnelle des différents comités de l’entité Organisation et Systèmes d’information et la direction Suivi des projets et réalisations de CDG Développement.

Chaque membre du groupe doit se conformer aux règles d’organisation et de méthodologie de travail définies par le présent document et les appliquer durant toute la période du projet de manière à garantir la qualité du produit final.

1. Objet du plan assurance qualitéLe Plan Assurance Qualité (PAQ) regroupe les procédures et

instructions qualité qui sont nécessaires au projet. Il énonce l'ensemble des dispositions spécifiques prises pour assurer la qualité du produit fourni ainsi que la qualité du processus de développement.

Le Plan Assurance Qualité permet de décrire :

- L'organisation générale du projet et les interactions entre ses différents membres (Maîtrise d'Œuvre, Maîtrise d'Ouvrage), les structures de communication, de validation et de décision, et les moyens à mettre en œuvre;

- Les critères qualité retenus pour répondre aux besoins en fonction de l'état de l'art de la profession ;

- Les documents établis au cours du cycle de vie du projet ;

- Les règles, méthodes et outils mis en œuvre lors du projet.

Le PAQ permet, en le communiquant à l'ensemble des


Ann e x e A : P l a n Assu ra n c e Qu a lité intervenants concernés, de piloter le projet avec la clarté et la transparence nécessaires.

Il fournit à l'équipe en place les règles d'auto contrôle assurant une production de qualité.



Contenu d u P AQ :

Ce Plan Assurance Qualité contient les principales parties décrites ci-dessous et dont le contenu et le nombre seront amenés à évoluer avec le projet. Le tableau suivant présente les parties constituant Ce PAQ:

• Partie • Description

2. Objectifs généraux du projetDans le cadre d’une optimisation de ses activités

opérationnelles, la DSPR souhaite procéder à une automatisation des supports de suivi des projets et réalisations de la holding CDG Développement et ses filiales. En effet, disposer d’un outil technologique répondant aux besoins opérationnels et automatisant les processus de la direction ; attribuera à améliorer le rendement interne en garantissant un gain de temps et de ressources remarquable, et une qualité d’information à jour, qui permettra aux décideurs de disposer à tout moments de l’état d’avancement des projets. De plus, Le système mis en place va permettre aux collaborateurs non seulement de rechercher l’information pertinente dont ils ont besoin en un temps réduit mais aussi de générer fiches synthétisant l’information.

Notant que cet outil doit répondre aux objectifs suivants :- Disposer d’une base de données pour tous les

projets de CDG Développement et ses filiales.

- Disposer d’un outil d’administration pour la saisie et la mise à jour des informations.

- Avoir la possibilité de lier des documents aux différents


Ann e x e A : P l a n Assu ra n c e Qu a lité projets dans la base de données.



- Disposer d’un système de reporting pour la génération des états de sorties et la prise de décision.

- Avoir la possibilité de rechercher les informations utiles suivant des critères donnés.

- Disposer d’un système d’alerte pour la notification des utilisateurs en cas d’anomalie par rapport à un projet.

- Disposer d’un tableau de bord synthétisant l’état d’avancement de tous les projets.

3. Organisation du projet3.1 Description des différentes structures

L’organisation du projet est articulée autour des structures suivantes :

- Le comité de pilotage.

- Le comité de suivi.

- Le comité de projet.

- L’équipe de projet.

Pour le bon déroulement du projet, il est nécessaire de définir clairement les rôles de chaque entité et d'identifier au sein de la maîtrise d'ouvrage (DSPR) et de la maîtrise d'œuvre (DSI) un représentant. Un groupe suivi associant les chefs de projet de la maîtrise d'ouvrage et de la maîtrise d'œuvre doit ainsi se réunir lorsque cela est nécessaire pour résoudre les conflits liés aux exigences de la maîtrise d'ouvrage ou à la coordination du projet.



Comité de pilotage

Comité de suivi Comité de projet

• Fréquence: se réunit chaque deux semaines.

• Composition:

- M. Souhail BENCHERIFA- Mme Fatime ZAHRA ALAOUI

• Missions:- Définir les orientations et les objectifs

généraux,- Contrôler et le suivre l’avancement du

projet,- Résoudre les problèmes

• Fréquence: se réunit à la fin de chaque phase.

• Composition:- M. Amine EL HAJHOUJ- M. Souhail BENCHERIFA

• Missions:- valider les livrables de chaque

phase,- suivre la mise en œuvre du projet,- prendre les décisions et régler les

conflits éventuels.

• Fréquence: Réunions hebdomadaires : chaque vendredi.

• Composition:- Chef de projet MOE : M. Alaeddine DAOUDI- Chef de projet MOA : M. Mounir EL FARISSI

• Missions:- Etablir un suivi hebdomadaire de l’avancementdu projet,

- Faire le point sur les problèmes rencontrés,

Equipe de projet

Mode de fonctionnement des structures du projet

• Fréquence: Travaille au quotidien pendant toute la durée du projet

• Composition:- M. Abbes SADI- Mlle Mariam SEBBAB- M. Omar HAJI- M. Yassir LACHHAB

• Missions:- Assurer les tâches de développement,- Mettre en place de la solution.

3.2 Structure du comité de pilotageLe Comité de Pilotage est l'organe de contrôle permanent du projet :- Il se réunit pour valider les grandes étapes telles que le

lancement du projet, la réception des versions successives du système ou encore la recette finale des livrables.

- Il fait le point sur l'état d'avancement du projet, analyse les difficultés éventuelles et décide des actions correctrices à appliquer.

- Il contrôle et mesure l’avancement du projet, analyse les difficultés rencontrées au cours du déroulement du projet et propose les actions correctives à appliquer, ou éventuellement présentes des solutions au comité de maîtrise d’ouvrage pour les problèmes ne relevant pas de son autorité.

Le comité de pilotage est formé des intervenants suivants :- M. Amine EL HAJHOUJ- M. Souhail BENCHERIFA

3.3 Structure du comité de suivi

Le comité de suivi, composé de membres de la DSPR et de l’entité SI et

Organisation, assure :- La définition des orientations et des objectifs généraux- Le contrôle et le suivi de l’avancement du projet,- La résolution des problèmes

Le comité de suivi se prononce aussi sur les mesures de correction proposées et est formé des intervenants suivants :

- M. Souhail BENCHERIFA- Mme Fatime ZAHRA ALAOUI

3.4 Structure du comité de projet

Le comité de projet est une structure de coordination constitué du chef de projet

MOE et chef de projet MOA.

Les membres du Comité de Projet sont chargés :- D’établir un suivi hebdomadaire de l’avancement du projet,- De faire le point sur les problèmes rencontrés,- De proposer des solutions au Comité de Pilotage.

Une fois par semaine, le comité de projet se. Cette réunion permet de faire le point sur les actions menées lors de la semaine précédente, de noter leur achèvement ou de remonter, le cas échéant, les problèmes et quantifier le retard dont ils sont la cause.

La réunion d’avancement hebdomadaire est également consacrée à la détermination des objectifs de la semaine suivante. Ce suivi à court terme permet de constater et mesurer au plus tôt les dérives par rapport à la planification initiale du projet.

Les dérives importantes et/ou non résolues au niveau hebdomadaire devront être remontées et traitées lors des réunions du Comité de Pilotage.

Le comité de projet est formé des intervenants suivants :- M. Alaeddine DAOUDI- M. Mounir EL FARISSI

3.5 Structure de l’équipe projet

L’équipe projet, composée de stagiaires au sein de l’entité SI et Organisation, se charge de :

- Mettre en place la solution- Produire les livrables et les sous livrables- Assurer les tâches de développement

Les membres de l’équipe projet sont :

- M. Abbes Sadi- Mlle Maryam Sebbab- M. Omar Haji- M. Yassir Lachhab

4. Livrables du projetNom/Liste Fonction Auteur Approbation Information

Charte du projet identifie la documentation de référence et les dispositions spécifiques d’organisation de la phase de développement à venir

AD SB

FA

ME

AE

PAQ précise les éléments permettant d’assurer la mise en œuvre et l’efficacité des activités prévues pour obtenir la qualité requise

AD AE

SB

FA

MF

SFD : spécifications fonctionnelles détaillées

précise les besoins fonctionnels, techniques et organisationnels exprimés par la maîtrise d'ouvrage et les utilisateurs

AS

MS

OH

YL

AD

ME

SB

FA

AE

SFT : spécifications techniques détaillées

AS

MS

OH

YL

AD

ME

SB

FA

AE

Planning de réalisation

Présente les différentes phases de réalisation du projet, ses livrables, ainsi que le délai relatif à chacune.

AD

AS

MS

OH

YL

ME

FA

SB

AE

Rapports d’avancement

Offre un aperçu sur l’état d’avancement du projet

AS

MS

OH

YL

AD

ME

FA

AE

SB

Rapport d’exploitation

Constitue le guide d’utilisation du système

AS

MS

AD

ME

FA

AE


OH

YL

SB

Rapport d’installation

Décrit le processus de déploiement de l’application

AS

MS

OH

YL

AD

ME

FA

AE

SB

Document recensant les anomalies et les améliorations à apporter

Le client produit en phase de test ce document pour permettre au producteur de corriger les anomalies

AE

FA

ME

AD

SB

AS

MS

OH

YL

PV de validation Validation du projet AD

ME

FA

AE

SB

AS

MS

OH

YL

Abbes SADI / Omar HAJI 99 Projet de fin d‘études 2008



PV de réception Réception du projet AD

ME

FA

AE

SB

AS

MS

OH

YL

Rapport de clôture

met fin au projet AD SB

FA

AE

ME

AS

MS

OH

YL

- AE : Amine EL HAJHOUJ- SB : Souhail BENCHERIFA- FA : Fatime ZAHRA ALAOUI- ME : Mounir EL FARISSI- AD : Alaeddine DAOUDI- AS : Abbes SADI- MS : Maryam SEBBAB- OH : Omar HAJI- YL : Yassir LACHHAB



ConclusionLe Plan Assurance qualité a pour principale finalité de garantir

un produit final opérationnel et répondant au besoin de la DSPR. En décrivant l’organisation des différentes entités intervenantes, il trace une fiche de route pour le suivi du projet en réalisation et propose une méthodologie de travail claire et rigoureuse. Y figurent aussi les livrables du projet et sert de référence au cours de la démarche de développement.

Ann e x e B : L e f ra m e w o r k Hib er n a te


Annexe B : Le framework Hibernate



Géné r a l i té s :

Travailler dans les deux univers que sont l'orienté objet et la base de données relationnelle peut être lourd et consommateur en temps dans le monde de l'entreprise d'aujourd'hui. Hibernate est un outil de mapping objet/relationnel pour le monde Java. 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é sur un schéma SQL.

Non seulement, 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), mais il permet de requêter les données et propose des moyens de les récupérer. Il peut donc réduire de manière significative le temps de développement qui aurait été dépensé autrement dans une manipulation manuelle des données via SQL et JDBC.

Le but d'Hibernate est de libérer le développeur de 95 pourcent des tâches de programmation liées à la persistance des données communes. Hibernate n'est probablement pas la meilleure solution pour les applications centrées sur les données qui n'utilisent que les procédures stockées pour implémenter la logique métier dans la base de données, il est le plus utile dans les modèles métier orientés objets dont la logique métier est implémentée dans la couche Java dite intermédiaire. Cependant, Hibernate vous aidera à supprimer ou à encapsuler le code SQL spécifique à votre base de données et vous aidera sur la tâche commune qu'est la transformation des données d'une représentation tabulaire à une représentation sous forme de graphe d'objets.

Ar ch i tectu re :

Voici dans la figure une vue haut niveau de l'architecture d'Hibernate :



Figure 38: Vue haut niveau de l’architecture d'Hibernate

Ce diagramme montre Hibernate utilisant une base de données et des données de configuration pour fournir un service de persistance (et des objets persistants) à l'application.

Nous aimerions décrire une vue plus détaillée de l'architecture. Malheureusement, Hibernate est flexible et supporte différentes approches. Nous allons en montrer les deux extrêmes. L'architecture légère laisse l'application fournir ses propres connexions JDBC et gérer ses propres transactions. Cette approche utilise le minimum des APIs Hibernate :



Figure 39: Architecture légère d'Hibernate

L'architecture la plus complète abstrait l'application des APIs JDBC/JTA sous- jacentes et laisse Hibernate s'occuper des détails.

Figure 40: Architecture complète d'Hibernate



Voici quelques définitions des objets des diagrammes :

- SessionFactory (net.sf.hibernate.SessionFactory)

Un cache threadsafe (immuable) des mappings vers une (et une seule) base de données. Une factory (fabrique) de Session et un client de ConnectionProvider. Peut contenir un cache optionnel de données (de second niveau) qui est réutilisable entre les différentes transactions que cela soit au niveau processus ou au niveau cluster.

- Session (net.sf.hibernate.Session)

Un objet mono-threadé, à durée de vie courte, qui représente une conversation entre l'application et l'entrepôt de persistance. Encapsule une connexion JDBC. Factory (fabrique) des objets Transaction. Contient un cache (de premier niveau) des objets persistants, ce cache est obligatoire. Il est utilisé lors de la navigation dans le graphe d'objets ou lors de la récupération d'objets par leur identifiant.

- Objets et Collections persistants

Objets mono-threadés à vie courte contenant l'état de persistance et la fonction métier. Ceux-ci sont en général les objets de type JavaBean (ou POJOs) ; la seule particularité est qu'ils sont associés avec une (et une seule) Session. Dès que la Session est fermée, ils seront détachés et libre d'être utilisés par n'importe laquelle des couches de l'application (ie. de et vers la présentation en tant que Data Transfer Objects - DTO : objet de transfert de données).

- Objets et collections transients

Instances de classes persistantes qui ne sont actuellement pas associées à une Session. Elles ont pu être instanciées par l'application et ne pas avoir (encore) été persistées ou elles ont


Ann e x e B : L e f ra m e w o r k Hib er n a te pu être instanciées par une Session fermée.

- Transaction (net.sf.hibernate.Transaction)

(Optionnel) Un objet mono-threadé à vie courte utilisé par l'application pour définir une unité de travail atomique. Abstrait l'application des transactions sous-jacentes qu'elles



soient JDBC, JTA ou CORBA. Une Session peut fournir plusieurs Transactions dans certain cas.

- ConnectionProvider (net.sf.hibernate.connection.ConnectionProvider)

(Optionnel) Une fabrique de (pool de) connexions JDBC. Abstrait l'application de la Datasource ou du DriverManager sous-jacent. Non exposé à l'application, mais peut être étendu/implémenté par le développeur.

- TransactionFactory (net.sf.hibernate.TransactionFactory)

(Optionnel) Une fabrique d'instances de Transaction. Non exposé à l'application, mais peut être étendu/implémenté par le développeur.

Dans une architecture légère, l'application n'utilisera pas les APIs Transaction/TransactionFactory et/ou n'utilisera pas les APIs ConnectionProvider pour utiliser JTA ou JDBC.

C o nfi g u r a t io n d e la S e ss io n F act o ry :

Parce qu'Hibernate est conçu pour fonctionner dans différents environnements, il existe beaucoup de paramètres de configuration. Heureusement, la plupart ont des valeurs par défaut appropriées et la distribution d'Hibernate contient un exemple de fichier hibernate.properties qui montre les différentes options. Généralement, vous n'avez qu'à placer ce fichier dans votre classpath et à l'adapter.

Alternativement, vous pouvez laisser la SessionFactory ouvrir les connexions pour vous. La SessionFactory doit recevoir les propriétés de connexions JDBC de l'une des manières suivantes :

1. Passer une instance de java.util.Properties à Configuration.setProperties().

2. Placer hibernate.properties dans un répertoire racine du classpath


Ann e x e B : L e f ra m e w o r k Hib er n a te 3. Positionner les propriétés System en utilisant java -

Dproperty=value.

4. Inclure des éléments <property> dans le fichier hibernate.cfg.xml

Le Mapping des classes vers les tables de la base de données est contrôlé par le fichier hibernate.cfg.xml :



<?xml version="1.0" encoding="utf-8"?><!DOCTYPE hibernate-configuration PUBLIC"-//Hibernate/Hibernate Configuration DTD 3.0//EN" "h t t p : //h i be r na t e . s our c efor g e . n e t /h i b e rn a t e - c o nf i g ura t i on -3.0. d t d "><hibernate-configuration>

<session-factory><property name="hibernate.bytecode.use_reflection_optimizer">false</property><property name="hibernate.cache.use_query_cache">false</property><property name="hibernate.cache.use_second_level_cache">false</property>

<property name="hibernate.connection.autocommit">true</property><property name="hibernate.connection.driver_class">com.microsoft.sqlserver.jdbc.SQLServerDriv er</property><propertyname="hibernate.connection.url">jdbc:sqlserver://server2\MSSQLSERVER;databasename=sper;user=sa;password=</property><property name="hibernate.dialect">org.hibernate.dialect.SQLServerDialect</property>

<mapping resource="cdgdev/pms/mapping/Typefichier.hbm.xml" /><mapping resource="cdgdev/pms/mapping/Fichier.hbm.xml" /><mapping resource="cdgdev/pms/mapping/Notification.hbm.xml" /><mapping resource="cdgdev/pms/mapping/Personne.hbm.xml" /><mapping resource="cdgdev/pms/mapping/Etape.hbm.xml" /><mapping resource="cdgdev/pms/mapping/Region.hbm.xml" /><mapping resource="cdgdev/pms/mapping/Typeprojet.hbm.xml" /><mapping resource="cdgdev/pms/mapping/Intervenantprojet.hbm.xml" /><mapping resource="cdgdev/pms/mapping/Journal.hbm.xml" /><mapping resource="cdgdev/pms/mapping/Typeintervenant.hbm.xml" /><mapping resource="cdgdev/pms/mapping/Organisme.hbm.xml" /><mapping resource="cdgdev/pms/mapping/Tranche.hbm.xml" /><mapping resource="cdgdev/pms/mapping/Vote.hbm.xml" /><mapping resource="cdgdev/pms/mapping/Ville.hbm.xml" /

http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd

http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd


Ann e x e B : L e f ra m e w o r k Hib er n a te <mapping resource="cdgdev/pms/mapping/Etatprojet.hbm.xml"

/><mapping resource="cdgdev/pms/mapping/Compteur.hbm.xml" /><mapping resource="cdgdev/pms/mapping/Projet.hbm.xml" /><mapping resource="cdgdev/pms/mapping/Profile.hbm.xml" />

</session-factory>

Cl a ss e s pe rs i s tante s :

Les classes persistantes sont les classes d'une application qui implémentent les entités d'un problème métier (ex. Client et Commande dans une application de commerce électronique). Les classes persistantes ont, comme leur nom l'indique, des instances transiantes mais aussi persistantes c'est-à-dire stockées en base de données.



Hibernate fonctionne de manière optimale lorsque ces classes suivent quelques règles simples, aussi connues comme le modèle de programmation Plain Old Java Object (POJO).

Voici un exemple simple de POJO :

public class Ville implements java.io.Serializable {

private static final long serialVersionUID = 1L;

private long idville;

private Region region;

private String nomville;

private Set projets = new HashSet(0);

public Ville() {

}

// minimal constructor

public Ville(long idville, Region region) {

this.idville = idville;

this.region = region;

}

// Property accessors

public long getIdville() {

return this.idville;

}

public void setIdville(long idville) {

this.idville = idville;

}

public Region getRegion() {

return this.region;

}

public void setRegion(Region region) {

this.region = region;

}

public String getNomville() {

return this.nomville;

}

public void setNomville(String nomville) {

this.nomville = nomville;

}

public Set getProjets() {

return this.projets;

}

public void setProjets(Set projets) {

this.projets = projets;

}

Ann e x e C : J a sp er R e po r t s


Annexe C : JasperReports



Int r o duct io n a u R ep o r t i n g :

Le reporting est la présentation périodique de rapports sur les activités et résultats d'une organisation, d'une unité de travail ou du responsable d'une fonction, destinée à en informer ceux chargés de les superviser en interne ou en externe, ou tout simplement concernés par ces activités ou résultats.

Le reporting concerne un type de rapports qui répond à la question « Que s’est-il passé ? » ou dans un contexte opérationnel à la question « Que se passe-t-il en ce moment? ». Il existe d’autres types de rapport pour répondre à la question analytique « Pourquoi est-ce que cela s’est passé ? » et à la question pronostique « Que va-t-il se passer? ». Tous ces différents rapports sont produits le plus souvent à partir d’un entrepôt de données.

Le terme désigne également une technique informatique de préparation de ces rapports, consistant à extraire des données pour les présenter dans un rapport humainement lisible (affichable ou imprimable).

Les étapes mises en œuvre sont les suivantes :

- Ciblage des données puis des sources de données à rassembler, avec par exemple un paramétrage de l'année, du domaine, etc.

- Extraction des informations utiles : groupement, tris, fonctions d'agrégation, calculs d'indices, etc.

- Mise en forme d'un rapport avec un canevas défini

- Production du rapport sous sa forme lisible

- Publication ou diffusion du rapport (intranet, messagerie électronique, document, etc.)



- Ja s per R ep o r t s :

Présentation

Brève présentation

JasperReports est outil 100% Open Source de génération d'états/ rapports développé en Java, pour des applications Java.

Il se présente sous la forme de librairies à intégrer aux applications.

Ces librairies permettent la visualisation ou l'export de données vers de multiples formats.

Ce que peux ou ne peux pas faire l'outil

JasperReports est un outils de Business

Intelligence, de reporting, Il peut :

- Produire des documents types: bons de commande, factures, rapports d'activités,

... bref des documents le plus souvent dynamiques, à partir de données existantes, et ce dans divers formats

- Permettre l'export de données à des formats divers pour une application existante

(sortie imprimable,

mailing ...) Mais il ne

peut pas :

- Permettre aux utilisateurs eux même de créer leur rapport ou alors des utilisateurs

qui connaissent SQL et un peu de Java ...

- Faire griller les toasts et faire le café

Pré requis pour utiliser l'outil

Matériels / logiciels :

- Rien à signaler niveau puissance machine ... ce n'est pas un outils que l'on peut classer comme gourmand



- OS: Linux, MS Windows, Mac ou autre pas de soucis, dès qu'il y a une machine virtuelle Java de disponible !



- Un JDK (version 1.3 minimum)

- Les drivers JDBC pour votre source de données (si base de données)

Le rapport

Cycle de vie d'un rapport

Figure 41: Cycle de vie d'un rapport Jasper

Fichier XML

Dans un premier temps, le développeur crée le rapport au format XML, via l'éditeur graphique iReport ou encore n'importe quel éditeur de texte. Ce fichier porte généralement l'extension .jrxml (Jasper Report XML).

Fichier jasper

Le fichier JRXML est ensuite compilé pour pouvoir être utilisé. Cette compilation peut se faire dans iReport comme dans le code d'une application. Dans le cas d'une application ce sera souvent le fichier compilé qui sera appelé car il est généralement inutile et


Ann e x e C : J a sp er R e po r t s coûteux de recompiler le XML à chaque appel du rapport



Sortie au format désiré

A partir du même fichier jasper, JasperReports peut ensuite produire plusieurs types de fichier:

- PDF- XLS (Excel)- ODF (OpenOffice)- RTF (Word en autres)- CSV- Texte

Pour cela, on transmet les paramètres voulus (si besoin), on spécifie le type de sortie désiré et voilà, un beau fichier !

Sources de données

JapserReports accepte plusieurs types de sources de données. Que ce soit classiquement une base de donnée, du CSV ou encore des Beans Java ... (via des dataSources).Toutefois, une rapport ne peut avoir qu'une seule source de données et ne peut faire qu'une seule requête SQL ! Heureusement un rapport peut être composé de sous-rapports qui auront chacun leur requête.


Ann e x e C : J a sp er R e po r t s Figure 42: Sources de données supportées par JasperReports

Ann e x e D : L a t ec hnol o gie A J AX


Annexe D : La technologie AJAX



1- Présentation de la technologie

AJAX, ou Asynchronous JavaScript And XML (« XML et Javascript asynchrones »), est un acronyme désignant une méthode informatique de développement d'applications Web.

À l'image de DHTML ou de LAMP, AJAX n'est pas une technologie en elle-même, mais un terme qui évoque l'utilisation conjointe d'un ensemble de technologies couramment utilisées sur le Web :

HTML (ou XHTML) pour la structure sémantique des informations ; CSS pour la présentation des informations ; DOM et JavaScript pour afficher et interagir dynamiquement

avec l'information présentée ; l'objet XMLHttpRequest pour échanger et manipuler les

données de manière asynchrone avec le serveur Web. XML et XSLT

En alternative au couple XML/XSLT, les applications AJAX peuvent utiliser d'autres technologies: le HTML préformaté, et les fichiers texte plats par exemple.

Les applications AJAX peuvent être utilisées au sein des navigateurs Web qui supportent les technologies décrites précédemment. Parmi eux, on trouve Mozilla, Firefox, Internet Explorer, Konqueror, Safari ou encore Opera. Toutefois, ce dernier ne supporte pas les transformations XSLT nativement pour les versions antérieures à la 9.0.

2- Comparaison avec les applications Web traditionnelles :

Les applications Web permettent aux utilisateurs d'effectuer des choix (suivre un lien, remplir et valider un formulaire). Une


Ann e x e D : L a t ec hnol o gie A J AX requête est alors envoyée au serveur HTTP, qui agit en fonction de l'action et des données reçues, et renvoie une nouvelle page. Ce fonctionnement consomme inutilement une partie de la bande passante, une grande partie du code (X) HTML étant commune aux différentes pages de l'application. Et parce qu'une requête au serveur HTTP doit être réalisée à chaque interaction avec l'application, le temps de réponse de l'application dépend fortement du temps de réponse du serveur



HTTP. Cela conduit à des interfaces utilisateurs plus lentes que leurs équivalents natives. Les navigateurs actuels mettent les éléments communs en cache, donc le chargement de pages nouvelles n'oblige pas le serveur à redonner les mêmes éléments à chaque fois.

Les applications utilisant les techniques AJAX quant à elles peuvent envoyer des requêtes au serveur HTTP pour récupérer uniquement les données nécessaires en utilisant la requête HTTP XMLHttpRequest, et en utilisant la puissance des feuilles de style (CSS) ainsi que le langage Javascript côté client pour interpréter la réponse du serveur HTTP. Les applications sont alors plus réactives, la quantité de données échangées entre le navigateur et le serveur HTTP étant fortement réduite. Le temps de traitement de la requête côté serveur est également légèrement réduit, une partie du traitement étant réalisé sur l'ordinateur d'où provient la requête.

En contrepartie, le chargement de la première page peut être pénalisé si l'application utilise une bibliothèque AJAX volumineuse.

3- Les approches côté serveur

Un des points critiques dans la programmation avec AJAX est de déterminer l'architecture client/serveur. En théorie, AJAX fonctionne indépendamment du serveur. En pratique, la technologie côté serveur choisie a un impact significatif sur les choix de programmation à disposition.

Java fournit une technologie à maturité avec un support des threads et un important soutien de la communauté Open Source.

2- Avantages et inconvénients

L'avantage de cette méthode est la vitesse à laquelle une


Ann e x e D : L a t ec hnol o gie A J AX application AJAX répond aux actions de l'utilisateur, dont les actions sont traitées (en partie au moins) localement par le navigateur.

L'utilisateur d'applications AJAX doit autoriser l'exécution de code Javascript par son navigateur, ce qui peut laisser craindre des problèmes de sécurité. Avec les versions d'Internet Explorer 5 ou 6 pour Windows, il doit aussi autoriser les ActiveX car le composant XMLHTTP n'y est pas natif comme dans ses concurrents (Firefox, Safari,



Opera, etc.) ou la version 7. Utilisant des techniques apparentées au HTML dynamique, les applications AJAX doivent être testées sur chaque navigateur, en raison du non respect des normes officielles.

Un autre inconvénient que l'on peut avancer est la question du référencement puisque les robots d'indexation ne sont pas en mesure d'indexer les contenus engendrés dynamiquement.

Enfin, en modifiant le contexte de navigation sans que l'utilisateur n'en soit nécessairement averti (en fonction de son mode d'accès au Web), AJAX pose de nombreuses questions d'accessibilité. C'est le cas notamment pour les utilisateurs de lecteurs d'écran ou de dispositifs d'agrandissement (loupes virtuelles).

Documents

Dédicace - Cours et formations - Télécharger PDFmcours.net/cours/memoires/Mise_en_place_d_une_solution... · Web viewEn effet, Hibernate fourni un langage d'interrogation extrêmement