rapport final

La mise en place d’un système

des Réalisations

Soutenu par :

Mr.FahdJamalELKODRI

Mr.Mouad BenCHCHAOUI

Ecole national de l’Industrie Minérale

Sujet

La mise en place d’un système de Suivi

des Réalisations de Projets de Promotion Immobilière

Sous la direction de

Mr.FahdJamalELKODRI

AOUI Mr.Ayoub Benbouzid

Mr.Charefeddine Benabdesselam

Mr.Mahmoud Nassar

Année Universitaire 2008-2009

Compagnie

CDG

de Suivi

de Projets de Promotion Immobilière

s la direction de :

Mr.Ayoub Benbouzid

Mr.Charefeddine Benabdesselam

Mr.Mahmoud Nassar

ompagnie Générale Immobilière

CDG DEVELOPPEMENT

Résumé

Dans le cadre de notre stage de formation à l’Ecole Nationale de l’Industrie Minérale (ENIM), on a effectué Notre stage au sein de la compagnie générale immobilière.

L’objectif du stage fut la conception et la réalisation d’un système de suivi des réalisations de projet de promotion immobilière pour le compte du pôle tertiaire (les domaines de l’immobilier non social).

Notre Mission dans ce Stage a consisté à :

Etude de la méthode de suivi et Reporting existante, pour parvenir a proposé

une solution qui répond aux exigences du client.

Etablissement de la dernière version du cahier des charges fonctionnel qui

servira par la suite pour continuer sur la réalisation du projet.

Réalisation des spécifications fonctionnelles des différents modules du

système.

Conception détaillée de la solution.

Maitrise de l’architecture et le mode de fonctionnement des outils et

Framework de développement DOT.NET 3.5, ASP.NET MVC, Entity

Framework, SQL Server Reporting Server 2008.

Réalisation des deux modules métiers de la solution, « Suivi budgétaire de

projets », « Reporting & Tableau de bord ».

Elaboration de la documentation technique à la fin de la mission.

Rapport de stage formation(ENIM) 2008- 2009

Liste des abréviations

Abréviation Désignation

2TUP 2 Tracks Unified Process.

ADO ActiveX Data Object

CDG Caisse de Dépôt et de Gestion.

CGI Compagnie générale immobilière.

MO Maîtrise d’Ouvrage.

MOD Maîtrise d’Ouvrage Déléguée.

SGBDR Système de Gestion de Bases de Données Relationnelles

SSRS SQL Server Reporting Services

SQL Standard Query Language

UML Unified Modeling Language.


Liste des figures

FIGURE 1.1 CHIFFRES SIGNIFICATIFS CGI ........................................................................................................................... 14

FIGURE 1.2 ORGANIGRAMME DE LA CGI ........................................................................................................................... 16

FIGURE 1.3 NIVEAUX DE TABLEAUX DE BORD ...................................................................................................................... 17

FIGURE 1.4 LE PROCESSUS DE DEVELOPPEMENT 2TUP ......................................................................................................... 21

FIGURE 1.5 PLANNING DES TACHES A EFFECTUER..................................................................... ERROR! BOOKMARK NOT DEFINED.

FIGURE 2.1 METHODE DE SUIVI EXISTANTE ........................................................................................................................ 24

FIGURE 2.2 TYPES DES REPRESENTATIONS GRAPHIQUES ........................................................................................................ 27

FIGURE 2.3 CANEVAS D'ETAT « CHIFFRE D'AFFAIRES » CGI SELON LE MODE DE GESTION (MO, MOD, MODECEM, FILIALE) ........... 28

FIGURE 3.1 DIAGRAMMES GENERAL DES CAS D’UTILISATIONS ................................................................................................ 38

FIGURE 3.2 DIAGRAMME DU CAS D'UTILISATION "S'AUTHENTIFIER" ........................................................................................ 39

FIGURE 3.3 DIAGRAMME DE CAS D’UTILISATION DU MODULE " ADMINISTRATION " .................................................................... 40

FIGURE 3.4 DIAGRAMME DE CAS D'UTILISATIONS DU MODULE PARAMETRAGE SYSTEME .............................................................. 42

FIGURE 3.5 DIAGRAMME DE CAS D'UTILISATION DU MODULE SUIVI BUDGETAIRE DE PROJETS ....................................................... 44

FIGURE 3.6 DIAGRAMME DU CAS D’UTILISATION DU MODULE REPORTING & TDB PROJET ........................................................... 45

FIGURE 3.5 DIAGRAMME DE CLASSE ................................................................................................................................. 47

FIGURE 4.1 VERSION CUMULEES DU .NET FRAMEWORK ...................................................................................................... 49

FIGURE 4.2 ARCHITECTURE FRAMEWORK .NET [6] .............................................................................................................. 50

FIGURE 4.3 ARCHITECTURE DU .NET FRAMEWORK 3.5 ........................................................................................................ 51

FIGURE 4.4 ARCHITECTURE ASP.NET ................................................................................................................................ 52

FIGURE 4.5 LA STRUCTURE DE L'APPLICATION "DASHBOARD CGI TERTIAIRE" ........................................................................... 53

FIGURE 4.6 FONCTIONNEMENT DU FRAMEWORK ENTITY [8] ................................................................................................. 55

FIGURE 4.7 NOUVELLE FONCTIONNALITES DE SQL SERVER 2008 [9] ...................................................................................... 57

FIGURE 4.8 ARCHITECTURE SERVEUR DE REPORTING SSRS [10] ............................................................................................ 57

FIGURE 4.9 EXEMPLE DE RAPPORT GENERER AVEC SSRS 2008 ............................................................................................. 58

FIGURE 4.10 ARCHITECTURE APPLICATIVE DU SYSTEME ........................................................................................................ 58

FIGURE 4.12 PAGE D'ACCES AU SYSTEME .......................................................................................................................... 60

FIGURE 4.13 IHM, GESTION COMPTE UTILISATEURS ............................................................................................................ 60

FIGURE 4.14 IHM, AJOUTER UTILISATEUR ......................................................................................................................... 61

FIGURE 4.15 IHM, AJOUTER ROLE SYSTEME ...................................................................................................................... 61

FIGURE 4.16 IHM, SAISIE BUDGET ANNUEL ....................................................................................................................... 61

FIGURE 4.17 IHM, SAISIE AVANCEMENT PHYSIQUE ............................................................................................................. 62

FIGURE 4.18 IHM, LISTE AVANCEMENT PHYSIQUE .............................................................................................................. 62

FIGURE 4.19 IHM, SAISIE DES INVESTISSEMENTS ................................................................................................................ 62

FIGURE 4.20 IHM, AJOUTER PROJET ................................................................................................................................ 63

FIGURE 4.21 IHMLISTE DE PROJETS ................................................................................................................................. 63

FIGURE A.1 DESIGN PATTERN MVC [] .............................................................................................................................. 71

FIGURE A.2 DIAGRAMME DE SEQUENCE « CREATION DE PROJET » .......................................................................................... 77

FIGURE A.3 DIAGRAMME DE SEQUENCE « SAISIE L’AVANCEMENT PHYSIQUE» ........................................................................... 77

FIGURE A.4 DIAGRAMME DE SEQUENCE « SAISIE L’ACTUALISATION DU BUDGET» ...................................................................... 78

FIGURE A.5 DIAGRAMME DE SEQUENCE « SAISIE DU COMPTABILISE» ...................................................................................... 78

FIGURE A.6 CONSULTATION DU TABLEAU DE BORD « ETAT CUMULE CONSOLIDE DE LA DIRECTION » .............................................. 79

FIGURE A.7 ETAT MENSUEL CONSOLIDE DES INVESTISSEMENTS PAR DIRECTION ET PAR MODE ....................................................... 80

FIGURE A.8 ETAT CUMULE CONSOLIDE DES INVESTISSEMENTS PAR DIRECTION ET PAR MODE ........................................................ 80

FIGURE A.9 ETAT MENSUEL CONSOLIDE DES ENCAISSEMENTS PAR (DIR RABAT, NORD, CASA & SUD) PAR MODE ............................ 81

FIGURE A.10 ETAT CUMULE CONSOLIDE DES ENCAISSEMENTS PAR (DIR RABAT, NORD, CASA & SUD) PAR MODE ............................ 81

FIGURE A.11 ETAT MENSUEL CONSOLIDE DU CA PAR (DIR RABAT, NORD, CASA & SUD) PAR MODE ............................................. 82

FIGURE A.12 ETAT CUMULE DES INVESTISSEMENTS ENCAISSEMENTS & CA PAR PROJET EN MO ET MODCEM PAR DIRECTION ......... 83

FIGURE A.13 ETAT MENSUEL ANNUEL DES INVESTISSEMENTS ENCAISSEMENTS & CA PROJET EN MOD PAR DIRECTION ..................... 83

FIGURE A.14 ETAT CUMULE DES INVESTISSEMENTS ENCAISSEMENTS & CA PROJET EN MOD PAR DIRECTION .................................. 84

FIGURE A.15 ETAT CUMULE DES INVESTISSEMENTS ENCAISSEMENTS & CA PROJET EN MOD PAR DIRECTION .................................. 85

FIGURE A.16 REPRESENTATION DES INDICATEURS SOUS FORME GRAPHIQUE ............................................................................ 86

6

Liste des Tableaux

TABLEAU 1.1 FICHE SIGNALETIQUE ................................................................................................................................... 12

TABLEAU 3.2 LES MODULES DES CAS D'UTILISATIONS ........................................................................................................... 37

TABLEAU 3.3 CAS D’UTILISATION " S’AUTHENTIFIER " .......................................................................................................... 39

TABLEAU 3.4 CAS D’UTILISATION « GERER COMPTE UTILISATEUR » ........................................................................................ 40

TABLEAU 3.5 CAS D’UTILISATION « GESTION DE PROJETS » ................................................................................................... 42

TABLEAU 3.6 CAS D’UTILISATION « GESTION DE PERIODE » ................................................................................................... 43

TABLEAU 3.7 CAS D’UTILISATION « SAISIE DE L’AVANCEMENT PHYSIQUE » ............................................................................... 44

TABLEAU 3.8 CAS D’UTILISATION « SAISIE DU REALISE» ........................................................................................................ 45

TABLEAU 3.9 CAS D’UTILISATION CONSULTATION REPORTING & TDB PROJET ........................................................................... 46

TABLEAU A.10 PROCESSUS DU PROJET .............................................................................................................................. 68

TABLEAU A.11 PLAN DE COMMUNICATION DU PROJET ......................................................................................................... 69

TABLEAU A.12 PLAN DE GESTION DES RISQUES .................................................................................................................... 69

TABLEAU A.13 COMPARATIF ENTRE LES PROCESSUS DE DEVELOPPEMENT ................................................................................. 73

TABLEAU A.14 CAS D'UTILISATIONS DETAILLES DU SYSTEME .................................................................................................. 76

7

TABLE DES MATIERES

RESUME ........................................................................................................................................................... 2

LISTE DES ABREVIATIONS .......................................................................................................................... 7

LISTE DES FIGURES ....................................................................................................................................... 5

LISTE DES TABLEAUX ................................................................................................................................... 6

TABLE DES MATIERES ............................................................................................................................... 10

INTRODUCTION .......................................................................................................................................... 12

CHAPITRE 1 : CONTEXTE GENERAL DU PROJET

INTRODUCTION .................................................................................................................................................. 11

1 PRESENTATION DE L’ORGANISME D’ACCUEIL ...................................................................................... 11

1.1 La compagnie générale immobilière ..................................................................................................... 11 1.1.1 Historique et faits marquants ............................................................................................................................. 12

1.2 Activité de la CGI .................................................................................................................................. 14

1.3 L’organigramme de la CGI ..................................................................................................................... 15

1.4 La direction de l'Organisation et Système d'Information ..................................................................... 16

1.5 Le Pôle Tertiaire ..................................................................................................................................... 16

2 PRESENTATION DU PROJET TABLEAU DE BORD DU POLE ................................................................ 17

2.1 Tableau de bord : Outil de suivi et pilotage .......................................................................................... 17 2.1.1 Termes et définitions .......................................................................................................................................... 17

2.1.2 Indicateurs de pilotage Tertiaire ........................................................................................................................ 18

2.2 Présentation du projet : Tableau de bord du Pôle Tertiaire ................................................................. 19

3 CONDUITE DE PROJET ............................................................................................................................... 20

3.1 Processus de développement .................................................................................................................. 20 3.1.1 Le processus 2TUP .............................................................................................................................................. 20

3.2 Planification du projet ................................................................................ Error! Bookmark not defined.

CONCLUSION ..................................................................................................................................................... 22

CHAPITRE 2 : ETUDE DE L’EXISTANT ET SPECIFICATION DES BESOINS FONCTIONNELS

INTRODUCTION ............................................................................................................................................ 24

1. ETUDE DE L’EXISTANT .............................................................................................................................. 24

1.1. Description de l’existant ......................................................................................................................... 24

1.2. Limitation du fonctionnement actuel ................................................................................................... 25

2. SPECIFICATION DES BESOINS ................................................................................................................... 25

2.1. Les besoins verticaux .............................................................................................................................. 26

2.2. Besoins transversaux .............................................................................................................................. 26

3. REGLES DE GESTION .................................................................................................................................. 30

3.1. Axes de calculs ....................................................................................................................................... 30

3.2. Règles de calcules ................................................................................................................................... 30

3.3. Qualité du système et service attendu ..................................................................................................... 31

CONCLUSION ................................................................................................................................................. 32

CHAPITRE 3 : ETUDE CONCEPTUELLE DU PROJET

INTRODUCTION ............................................................................................................................................ 34

1. DIAGRAMME DES CAS D’UTILISATION GENERAL .................................................................................. 34

1.1. Identification des acteurs ........................................................................................................................ 34

1.2. Diagramme de contexte .......................................................................................................................... 35

1.3. Identification des messages..................................................................................................................... 35

1.4. Identification des cas d’utilisations.......................................................................................................... 36

2. DESCRIPTION DES CAS D’UTILISATIONS ................................................................................................. 39

2.1. Module « Authentification » .................................................................................................................... 39

2.2. Module « Administration » ..................................................................................................................... 40

2.3. Module « Paramétrage système » ............................................................................................................. 42

2.4. Module « Suivi budgétaire du projet » ................................................................................................. 44

8

2.5. Module « Reporting & Tableau de bord » ............................................................................................ 45

3. DIAGRAMME DE CLASSE ............................................................................................................................. 47

CONCLUSION ................................................................................................................................................. 47

CHAPITRE 4 : REALISATION DU PROJET TABLEAU DE BORD TERTIAIRE

INTRODUCTION............................................................................................................................................ 49

1. CHOIX TECHNIQUES................................................................................................................................... 49

1.1. Framework .Net ..................................................................................................................................... 50

1.2. Les composants du .NET ....................................................................................................................... 51 1.2.1. Le langage C# ...................................................................................................................................................... 51

1.2.2. Asp.Net ............................................................................................................................................................... 51

1.2.3. ADO.Net ............................................................................................................................................................. 52

1.3. Framework d’application Asp.NET MVC ............................................................................................... 52 1.3.1. Présentation du Framework Asp.Net MVC ......................................................................................................... 53

1.4. Framework de persistance « Entity Framework » ................................................................................ 54

1.5. Outils de travail ...................................................................................................................................... 56 1.5.1. Visual Studio Team System 2008 ........................................................................................................................ 56

1.5.2. Le choix du SGBD SQL Server Entreprise Edition 2008 ....................................................................................... 56

1.5.3. Le serveur de reporting : SQL Server Reporting Services 2008........................................................................... 57

2. ELEMENT SUR L’IMPLEMENTATION DU SYSTEME TABLEAU DE BORD TERTIAIRE ..................... 58

2.1. Architecture logicielle ............................................................................................................................. 58

2.2. Les interfaces Homme Machine ............................................................................................................. 59 2.2.1. Charte graphique ................................................................................................................................................ 59

2.2.2. Page d’accès au système .................................................................................................................................... 60

2.2.3. Module « Administration »................................................................................................................................. 60

2.2.4. Module « Suivie budgétaire du projet » ............................................................................................................. 61

2.2.5. Module « Paramétrage de l’application » .......................................................................................................... 63

CONCLUSION ............................................................................................................................................... 63

CONCLUSION ET PERSPECTIVES ............................................................................................................ 64

BIBLIOGRAPHIE .......................................................................................................................................... 66

ANNEXE A .................................................................................................................................................... 67

ANNEXE B .................................................................................................................................................... 71

ANNEXE C .................................................................................................................................................... 72

ANNEXE D .................................................................................................................................................... 74

ANNEXE E .................................................................................................................................................... 80

Introduction

9

INTRODUCTION

Aujourd’hui, le contexte économique a changé. L’instabilité, l’incertitude et le risque sont devenus des constantes de notre environnement. La concurrence n’est plus industrielle mais informationnelle. Aussi, les décideurs et managers doivent prendre les bonnes décisions et le plus rapidement possible. Face à cette situation, les entreprises commencent à prendre au sérieux le sujet du manque d’informations mises à la disposition des décideurs par les systèmes classiques de tableau de bord (tableaux Excel différenciés…) Pour une entreprise leader telle la CGI (Compagnie Générale Immobilière), des projets sont lancés pour la mise en place de tels outils. Ce rapport dont le thème est « la mise en place d’un système de suivi des réalisations de projets de promotion immobilière » s’inscrit dans ce cadre. Ce système est conçu et destiné au pilotage, à la gestion et au suivi budgétaire des réalisations du pôle tertiaire pour avoir une visibilité sur les encours et les actualisations. Le présent rapport comporte quatre chapitres : Le premier chapitre du rapport est consacré à la présentation de l’organisme d’accueil et à la description du contexte général du projet et la démarche adoptée pour la conduite du projet. L’étude de l’existant et la spécification des besoins fonctionnels font l’objet du deuxième chapitre. Le troisième chapitre fera l’objet de la phase d’analyse et conception du projet en utilisant le standard UML. Le quatrième et dernier chapitre décrit la phase de la réalisation du projet. Il présente les différents outils et Framework utilisés ainsi que quelques interfaces de l’application.

Enfin, nous présentons une conclusion est quelques perspectives du projet.

Chapitre 1 : Contexte général du projet


CHAPITRE 1 :

CONTEXTE GÉNÉRAL DU PROJET

INTRODUCTION .................................................................................................................................................. 11

1 PRESENTATION DE L’ORGANISME D’ACCUEIL ...................................................................................... 11

1.1 La compagnie générale immobilière ..................................................................................................... 11 1.1.1 Historique et faits marquants ............................................................................................................................. 12

1.2 Activité de la CGI ..................................................................................................................................... 14

1.3 L’organigramme de la CGI .......................................................................................................................... 15

1.4 La direction de l'Organisation et Système d'Information ...................................................................... 16

1.5 Le Pôle Tertiaire ........................................................................................................................................ 16

2 PRESENTATION DU PROJET TABLEAU DE BORD DU POLE ................................................................ 17

2.1 Tableau de bord : Outil de suivi et pilotage .......................................................................................... 17 2.1.1 Termes et définitions .......................................................................................................................................... 17

2.1.2 Indicateurs de pilotage Tertiaire ........................................................................................................................ 18

2.2 Présentation du projet : Tableau de bord du Pôle Tertiaire .................................................................. 19

3 CONDUITE DE PROJET ............................................................................................................................... 20

3.1 Processus de développement ........................................................................................................................... 20 3.1.1 Le processus 2TUP .............................................................................................................................................. 20

3.2 Planification du projet ..................................................................................... Error! Bookmark not defined.

CONCLUSION ................................................................................................................................................ 22



Introduction

Le but de ce chapitre est la présentation de l’organisme au sein duquel a été effectué

Notre stage de formation . Nous présentons dans un premier temps la CGI, son

positionnement au sein du groupe CDG, ses activités, pour examiner ensuite le sujet

du projet, son objectif et la méthode de conduite de projet adoptée.

1 Présentation de l’organisme d’accueil

1.1 La compagnie générale immobilière

Spécialisée dans le domaine de la promotion

immobilière, la Compagnie Générale Immobilière

(CGI) développe des métiers polyvalents dans des

domaines d’interventions très diversifiées (résidentiel –

tertiaire – maîtrise d’ouvrage délégué).

Avec un demi-siècle d’existence, la Compagnie Générale Immobilière fait preuve

d’un formidable dynamisme. En renforçant sa présence dans tous les métiers de

l’immobilier, elle renouvelle sans cesse son approche, en accompagnant les grandes

évolutions du secteur par des projets structurants.

Adossé à la Holding CDG Développement, la CGI a développé des domaines

d'intervention très diversifiés avec un souci de qualité architecturale et un objectif de

rentabilité, qui en font un intervenant majeur de l'immobilier au Maroc.

Aujourd'hui la CGI cotée à la bourse de Casablanca depuis Août 2007 (20 % de son

Capital), s'appuie sur son expérience, son savoir-faire et sur l’immobilisation de ses

équipes pour asseoir sa présence sur toute la gamme des besoins immobiliers,

résidences, bureaux, centres commerciaux, hôtels clés en main. Cette polyvalence et



poly compétence lui permet d'être présente sur des opérations structurantes et

complexes telle : la Marina à Casablanca, Chrifia à Marrakech.

1.1.1 Historique et faits marquants

Historique :

La CGI est l’une des sociétés les plus importantes en matière de promotion

immobilière au Maroc, elle a été créée en 1960 et est détenue à 99,9% par CDG

Développement qui est est-elle filiale à 100% de la CDG (Groupe Caisse de Dépôt

et de Gestion).

Ces deux dernières années marquent positivement l’histoire de la CGI à savoir qu’en

2006, la CGI a décroché le label qualité Iso 9001 version 2000 par le cabinet BVQI

avec brio et en 2007, elle a fait une entrée spectaculaire à la bourse de Casablanca et

ce n’est qu’un début, ses ambitions stratégiques de développement sont telles que

seule une équipe performante, soudée et professionnelle peut y parvenir.

Fiche signalétique :

Tableau 1.1 Fiche signalétique

Dénomination sociale Compagnie Générale Immobilière SA (CGI)

Siège social Immeuble de la Caisse de Dépôt et de Gestion, Place My El Hassan, Rabat

Siège administratif et commercial

Espace Oudayas, Avenue Mehdi Ben Barka, BP 2177, Hay Riad, Rabat

Date de constitution 12 mars 1960 Exercice social Du 1er janvier au 31 décembre Forme juridique Société Anonyme à Conseil de Surveillance et

Directoire Capital social actuel 1.620.000.000 DH entièrement libéré et divisé

en 16 200 000 actions de 100 Dh chacune, toutes de même catégorie.

Tél (05 37) 23 94 94 Fax (05 37) 56 32 25 Email [email protected]

Site Web www.cgi.ma



Dates clés [1] :

1988 : Distinction internationale « Meilleur prix arabe d'habitat » pour l'opération « Hay Al

Fath » à Rabat, portant sur 2500 appartements.

1960 : Date de création avec un capital détenu à 99,99% par la CDG.

2004 : la CGI devient filiale de CDG Développement (holding en charge du développement

territorial dans les métiers opérationnels non financiers)

2006 : La CGI a décroché le label qualité (ISO 9001 version 2000) par le cabinet BVQI avec

brio.

2007 : Repositionnement de la CGI sur des projets de grandes envergures tels que la

Casablanca Marina ;

Entrée à la Bourse de Casablanca, ses ambitions stratégiques de développement sont telles que

seule une équipe performante, soudée et professionnelle peut y parvenir.

2008 : Signature d'un accord de partenariat stratégique avec le Groupe Jordanien Mawared

avec pour objet la création d'une Holding marocaine détenue à parts égales par la CGI et

Mawared International Morocco en vue de porter des projets structurants.

Acquisition de 100% du capital de DYAR AL MANSOUR, acteur important du logement

économique et social jusque-là filiale de CDG Développement.

2009 : La Compagnie Générale Immobilière - CGI vient de passer avec succès, son audit de

maintien de certification selon la nouvelle norme ISO 9001 version 2008, par le groupe

international Bureau Veritas Certification pour l'ensemble de ses activités [1].

27 mai 2009 2 : Signature d’un accord de partenariat stratégique entre les filiales CGI et

MADAEF du groupe CDG et le groupe PIERE & VACANCES. Ce partenariat concrétise la

volonté de deux Groupes de promouvoir sur le territoire marocain le concept des résidences

de tourisme.


Rapport de stage formation(ENIM) 2008

Chiffres significatifs

1.2 Activité de la CGI

La CGI se positionne sur le segment du moyen et du haut standing. Alors qu’elle était également présente sur le segment 2004 d’une filiale de CDGsur ce segment, a complètementque cela soit en maîtrise d’ouvrage ou en

Il est à savoir que l’essentiel des programmespour le compte propre de la CGI à travers des opérations en maîtrise d’ouvrage. Le reste, à savoir les opérationscompte d’organismes publics et privésmener à bien leurs projets immobiliers.

Les deux modes d’intervention de la CGI se déclinent comme suit :

Maîtrise d’ouvrage (MO)

La CGI (maître d’ouvrage) prend l’initiative des réalisations immobilières et assumela responsabilité du financement et de la coordination des opérations.

Maîtrise d’Ouvrage Déléguée (MOD)

La CGI (mandataire ou maître d’ouvrage délégué) reçoit du maître d’ouvrage l’autorisation de gérer un certain nombre de projets en son nom, à travers une convention de mandat.

Stocks de construction en cours : Logement: 727 unités

Contexte général du projet


Chiffres significatifs

Figure 1.1 Chiffres significatifs CGI

Activité de la CGI

La CGI se positionne sur le segment du moyen et du haut standing. Alors qu’elle présente sur le segment du logement social, la spécialisation depuis

2004 d’une filiale de CDG Développement désormais dénommée Dyar Al Mansour sur ce segment, a complètement désengagé la CGI de ce premier segment d’activité que cela soit en maîtrise d’ouvrage ou en maîtrise d’ouvrage déléguée.

Il est à savoir que l’essentiel des programmes (projets) réalisés par la CGI se fait de la CGI à travers des opérations en maîtrise d’ouvrage. Le

reste, à savoir les opérations réalisées en maîtrise d’ouvrage déléguée,compte d’organismes publics et privés qui recourent au savoir faire de la CGI pour mener à bien leurs projets immobiliers.

modes d’intervention de la CGI se déclinent comme suit :

Maîtrise d’ouvrage (MO) :

ge) prend l’initiative des réalisations immobilières et assumeresponsabilité du financement et de la coordination des opérations.

Maîtrise d’Ouvrage Déléguée (MOD) :

La CGI (mandataire ou maître d’ouvrage délégué) reçoit du maître d’ouvrage gérer un certain nombre de projets en son nom, à travers une

Capital social : 1 620 000 000 dirhams

Chiffre d'affaire : 1 575 080 000

Stocks de terrains:3663 H


Resultat d'exploitation consolidé : 346 000 000 DH

Resultat net: 371 000 000 DH

La CGI se positionne sur le segment du moyen et du haut standing. Alors qu’elle du logement social, la spécialisation depuis

Développement désormais dénommée Dyar Al Mansour désengagé la CGI de ce premier segment d’activité

vrage déléguée.

réalisés par la CGI se fait de la CGI à travers des opérations en maîtrise d’ouvrage. Le

réalisées en maîtrise d’ouvrage déléguée, se fait pour le qui recourent au savoir faire de la CGI pour

modes d’intervention de la CGI se déclinent comme suit :

ge) prend l’initiative des réalisations immobilières et assume responsabilité du financement et de la coordination des opérations.

La CGI (mandataire ou maître d’ouvrage délégué) reçoit du maître d’ouvrage gérer un certain nombre de projets en son nom, à travers une

Capital social : 1 620 000 000 dirhams


Resultat d'exploitation consolidé : 346 000 000 DH



Ainsi, ses métiers se déclinent en maîtrise d’ouvrage et en maîtrise d’ouvrage déléguée et tournent autour des domaines d’intervention suivants :

� Appartements et villas � Résidences d’habitations sécurisées � Résidences intégrées dans les zones touristiques � Opérations de renouvellement urbain non-social � Bureaux � Centres commerciaux � Centres de loisirs � Centres hospitaliers � Les unités hôtelières � Complexes multi-fonctionnels

1.3 L’organigramme de la CGI

L’organisation de la CGI est décrite dans le schéma (cf. figure 1.2), on a effectué le stage à la Direction de l'Organisation et Système d'Information située au sein du pôle support.

Ce pôle a pour mission de :

• Définir les stratégies en matière de gestion des ressources humaines et

matérielles et des SI,

• Piloter les activités de support,

• Mettre en place les contrats cadre avec les prestataires de services et de

travaux,

• Piloter des actions d’amélioration des processus de la société,

Gérer le contentieux et assurer le conseil juridique.



1.4 La direction de l'Organisation et Système d'Information

La Direction de l’OSI est en charge d’accompagner le l’entreprise et lui offrir les outils et supports nécessaires. Dans ce sens, la CGI s’est dotée d’une solution client-secteur de l’immobilier.

L’entreprise dispose aussi d’un site Internet hébergé à la CDG.

1.5 Le Pôle Tertiaire

Le pôle tertiaire se charge des réalisations de la CGI autres que le logement, à savoir les bureaux, les commerces ainsi que les projets de la CGI dans le secteur du tourisme.

Le pôle dispose également de deux départements opérationnels :

Le Marketing qui assure la veille marché et le marketing produit;

Le Commercial qui assure la promotion et la vente des produits.

Contexte général du projet


Figure 1.2 Organigramme de la CGI

La direction de l'Organisation et Système d'Information

OSI est en charge d’accompagner le développement de l’activité de l’entreprise et lui offrir les outils et supports nécessaires. Dans ce sens, la CGI s’est

- serveur sous Oracle et d’un système intégré spécifique au

ssi d’un site Internet hébergé à la CDG.

Le Pôle Tertiaire

Le pôle tertiaire se charge des réalisations de la CGI autres que le logement, à savoir les bureaux, les commerces ainsi que les projets de la CGI dans le secteur du

galement de deux départements opérationnels :



La direction de l'Organisation et Système d'Information

développement de l’activité de l’entreprise et lui offrir les outils et supports nécessaires. Dans ce sens, la CGI s’est

serveur sous Oracle et d’un système intégré spécifique au

Le pôle tertiaire se charge des réalisations de la CGI autres que le logement, à savoir les bureaux, les commerces ainsi que les projets de la CGI dans le secteur du





2 Présentation du projet Tableau de bord du Pôle

2.1 Tableau de bord : Outil de suivi et pilotage

Le pilotage dans le secteur immobilier repose sur la bonne compréhension et l’utilisation d’outils de gestion tels : les budgets, les investissements globaux et les tableaux de bord. Ces outils offrent aux managers chaque responsable à son niveau (cf. figure 1.3), la possibilité de suivre la réalisation des objectifs stratégiques et opérationnels, de localiser et d’interpréter les écarts significatifs entre objectif et réalisé et d’adopter les mesures correctives adéquates.

Un tableau de bord synthétique par niveau de responsabilité :

Figure 1.3 Niveaux de tableaux de bord

Réf. Le MÉTROscope Indicateurs et Tableaux de bord (Développement de logiciel) Edition d’ADELI

2.1.1 Termes et définitions

Pour les besoins du présent rapport, les termes et définitions suivants s'appliquent.

� Indicateur : information choisie, associée à un critère, destinée à en observer les évolutions à intervalles définis.

� Tableau de bord : outil de pilotage et d’aide à la décision regroupant une sélection d’indicateurs.

� MODCEM : MOD clé en main. � Consolidation : les niveaux de consolidation des états et tableaux de bord :

pôle, directions. � Chiffres clés : se sont les indicateurs de performance du pôle tertiaire :

investissement, encaissement, chiffre d’affaires.



2.1.2 Indicateurs de pilotage Tertiaire Les indicateurs de pilotage du pôle tertiaire se résument comme suit :

Investissement : c’est l’ensemble des dépenses engagées dans le projet et qui

ne sont d’autres que :

� Foncier � Autorisations & Taxes � Régies � Etudes � VRD � Construction � Gestion � Commercialisation & communication � SAV � Autre types de dépenses qui peuvent surgir durant les étapes des

projets. Chiffre d’affaires : la définition du chiffre d’affaires varie selon le mode

d’activité de CGI :

� en MO : est l’équivalent du montant des ventes du projet (constaté à la livraison)

� en MOD : est l’équivalent du montant des honoraires CGI (constaté après facturation au fur et à mesure qu’on avance dans le projet)

� en MODCEM : est l’équivalent du montant des honoraires et des ventes

� en filiales : est l’équivalent du montant des honoraires et des ventes Encaissement :

� en MO : est l’équivalent des avances clients � en MOD : est l’équivalent du montant facturé des honoraires CGI � en MODCEM : est l’équivalent du montant facturé des honoraires et

des ventes � en filiales : est l’équivalent du montant des honoraires et des ventes



2.2 Présentation du projet : Tableau de bord du Pôle Tertiaire

La compagnie générale immobilière, cherche à satisfaire ses clients en s’appuyant sur

une politique de qualité dans tous ses secteurs d’activités, parmi lesquels le suivi des

projets de promotion immobilière. Reconnaissant l’impact de ce facteur dans les

activités de la compagnie, la direction de l’organisation et SI a été chargée de mettre

en place un système de suivi stratégique pour le compte du pôle tertiaire permettant

de faire le suivi budgétaire des réalisations pour avoir une visibilité sur les encours et

les actualisations.

Le système en question doit permettre, à la hiérarchie d’analyser mensuellement

l’état d’avancement de tous les projets du pôle tertiaire à travers des indicateurs clés

tel que les engagements, le chiffre d’affaires et les encaissements par direction et par

mode de gestion. Ce système doit également permettre aux directeurs de projets de

suivre les réalisations des projets de la direction et de relever les actions correctives

correspondantes. Il doit aussi offrir aux directeurs de chantiers la possibilité de

garder un rythme soutenu des réalisations en maîtrisant leur échéancier financier.

Ainsi ce système sera dédié aux besoins d’analyse statistique et de pilotage.

Par ailleurs, le système doit permettre la production automatique de tableaux de bord

mensuels et cumulés du pôle et faire ressortir les écarts par rapport aux objectifs.

Finalement, il est nécessaire de prendre en compte l’intégration de l’outil réalisé dans

le système d’information de la société qui est en phase de migration.



3 Conduite de projet

3.1 Processus de développement

Le processus de développement constitue un facteur déterminant dans la réussite

d’un projet, du fait qu’il cadre ses différentes phases et caractérise les principaux

traits de sa conduite. Pour cela, le choix d’une méthode de développement, qui soit

adéquate aux particularités et exigences d’un projet, doit être élaboré au préalable

afin d’obtenir un produit de qualité qui répond aux besoins et attentes des

utilisateurs.

Vu que chaque type d’application en informatique (développement, intégration,

maintenance …), présente des exigences particulières en termes de méthodologie et

de la démarche à suivre, on a commencé par une étude comparative entre les

différents processus utilisés dans le cadre de développement de projet informatique,

afin de choisir celui le plus adéquat avec notre projets (voir Annexe C).

En se basant sur les résultats de cette étude, nous constatons que toutes ces

méthodologies proposent de travailler de façon itérative, que ce soit au niveau des

plannings, des spécifications, ou du développement. Et puisque le 2TUP reste la

meilleure solution en réservant des branches entières à la technologie et au

fonctionnel dans son processus de développement, il semble le plus adapté pour

mener à bien notre projet.

3.1.1 Le processus 2TUP

Le 2TUP propose un cycle de développement en Y en dissociant les aspects techniques des aspects fonctionnels comme illustré en figure 4, le processus en Y s'articule autour de 3 phases :

� Une branche technique � Une branche fonctionnelle une phase de réalisation � Une branche Conception-Réalisation.



2TUP est un processus qui répond également à d’autres caractéristiques telles que :

� Un processus incrémental piloté par les risques

� Un processus piloté par les exigences des utilisateurs

� Un processus de modélisation avec UML

Figure 1.4 Le processus de développement 2TUP



Conclusion

Dans ce chapitre, et après une présentation de l’organisme d’accueil, on a défini le contexte général du projet, ses objectifs et le processus de développement adopté pour sa mise en œuvre. Le prochain chapitre traitera la première phase du projet à savoir : l’étude de l’existant et spécification des besoins fonctionnels.

CHAPITRE 2 :

Chapitre 2: Etude de l’existant et spécification des besoins fonctionnels


ETUDE DE L’EXISTANT ET SPÉCIFICATION

DES BESOINS FONCTIONNELS

INTRODUCTION ............................................................................................................................................ 24

1. ETUDE DE L’EXISTANT .............................................................................................................................. 24

1.1. Description de l’existant ......................................................................................................................... 24

1.2. Limitation du fonctionnement actuel ................................................................................................... 25

2. SPECIFICATION DES BESOINS ................................................................................................................... 25

2.1. Les besoins verticaux .............................................................................................................................. 26

2.2. Besoins transversaux .............................................................................................................................. 26

3. REGLES DE GESTION .................................................................................................................................. 30

3.1. Axes de calculs ....................................................................................................................................... 30

3.2. Règles de calcules ................................................................................................................................... 30

3.3. Qualité du système et service attendu ..................................................................................................... 31

CONCLUSION ................................................................................................................................................. 32

CHAPITRE 3 : ETUDE CONCEPTUELLE DU PROJET

INTRODUCTION ............................................................................................................................................ 34













CONCLUSION ................................................................................................................................................. 47



Introduction

Dans ce chapitre on présente l’analyse fonctionnelle du système tableau de bord du Pôle. Cette phase passe un rappel de l’existant, description de ses fonctionnalités et ses limites. Cela Nous permettra de cerner les fonctionnalités à intégrer dans le système.

1. Etude de l’existant

1.1. Description de l’existant

Le suivie des réalisations de projet de promotion immobilière au sein de la CGI est aujourd’hui assuré par quelques directeurs et chefs de projets qui communiquent l’état d’avancement et les réalisations mensuels de leurs projets.

Une fois les données enregistrées au niveau du Département Reporting et Etudes de faisabilité sont ensuite reprises manuellement par la chargée d’études pour créer des fichiers Excel mensuels et annuels, qui contiennent le détail de tous les projets (le réalisé physique, l’avancement physique, le comptabilisé, le budget, l’actualisation du budget).

Figure 2.1 Méthode de suivi existante



1.2. Limitation du fonctionnement actuel

La situation courante présente un ensemble de limitations :

Absence d’un reporting consolidé pour la hiérarchie,

Absence d’un reporting unifié par direction,

Méthodes de calcul d’indicateurs non identiques,

Une tâche pénible de saisie qui augmente le risque d’erreur,

Actualisations des réalisations ne suivent pas une procédure ni un timing

déterminé,

Grande difficulté pour la validation des données vu la grande masse

d’information saisie au niveau du tableur,

Génération manuelle des indicateurs,

Absence d’analyse des écarts.

Par conséquent, un nouveau système de suivi et Reporting pour alimenter la base de

données et consulter les avancements des projets s’avère nécessaire pour la CGI. Ce

système devra être flexible, évolutif et convivial en termes d’ergonomie, facilitant

l’accès aux données et automatisant la production d’états de tableaux de bord.

2. Spécification des besoins

La phase de spécification met en relation les besoins des utilisateurs avec la solution

à mettre en place. Cette phase décrit non seulement le comportement cible de la

solution mais également son mode de fonctionnement, tout en distinguant les

spécifications fonctionnelles générales, les spécifications fonctionnelles détaillées et

les spécifications techniques.

Nous devons donc déterminer les principaux besoins dont il doit répondre ce

nouveau système.



2.1. Les besoins verticaux

Puisque les données communiquées par les chefs de projets étaient enregistrées sur

des fichiers Excel, le premier besoin exprimé par le Pôle Tertiaire était celui de

réaliser un outil de saisie qui répond aux besoins suivants :

� Saisie des réalisations et avancements physiques :

L’outil doit permettre de saisir les réalisations et les avancements physiques

(avancement du chantier) des différents projets une fois par mois.

� Saisie du budget et des actualisations

Une fois par an, le chargé d’études procédera à la saisie du budget et trois fois par an

pour l’actu et ce par projet.

� Saisie du comptabilisé

Une fois par mois les investissements, encaissements et chiffre d’affaires qui

émanent de la comptabilité doivent être renseignés par le chargé d’études.

� Saisie de l’investissement global

Renseignement par le chargé d’études de l’investissement global du projet (un seul

montant) avec possibilité de le modifier en fonction de l’avancement du projet.

2.2. Besoins transversaux

Pour tirer plus d’information, les utilisateurs de la compagnie générale immobilière

plus précisément le Pôle Tertiaire, ont exprimé des besoins transversaux :

Simplicité d’accès aux données et ergonomique

Afin d’accéder à l’information d’une manière simple, les utilisateurs demandent bien

avoir des interfaces conviviales avec un affichage rapide, sur lesquelles ils peuvent

saisir les informations mensuelles concernant les projets et visualiser par la suite le

résultat.



En effet ceci sera garanti via les différents types de tableaux de bord, qui vont être

présentés en détail dans l’annexe E :

1) Tableau de bord chefs de projets : permettre aux chefs de projets de

disposer d’un TDB de leurs projets mensuels et cumulés.

2) Tableau de bord directeurs de projets : permettre aux directeurs de

projets d'avoir un TBD de leurs projets et de leur direction.

3) Tableau de bord Directeur Pôle : permettre au directeur de pôle d'avoir

un TBD de tous les projets du pôle.

4) Tableau de bord Chargé d’études : permettre à la chargée d’études

d’avoir un TDB de tous les projets du pôle avec plusieurs niveaux de

consolidation (par direction, par mode de gestion).

Possibilité d’exporter les données

Grâce aux fonctionnalités offertes par l’outil Excel, l’un des besoins transversaux

était d’exporter les données vers ce dernier, afin de profiter des présentations

graphiques des données exportées.

Figure 2.2 Types des représentations graphiques



Production d’état et de tableaux de bord

Une fois les données saisies et stockées dans la base de données et la génération des indicateurs de pilotage est faite, il s’agit ensuite de publier les données sous forme de rapports et états. La chargée d’études demande de garder le format de rapport et état actuel générer par les tableurs Excel voir schémas (cf. figure 2.3) le reste est fournie en annexe E :

Figure 2.3 Canevas d'état « chiffre d'affaires » CGI selon le mode de gestion (MO, MOD, MODECEM, Filiale)

Chaque état produit par le système est présenté sous forme des indicateurs de

performances et axes de calculs.

Axes et indicateurs :

Le tableau suivant définit les indicateurs, les axes et les hiérarchies correspondants.

Indicateurs

Axes d’analyse

Hiérarchie

Encaissement

Temps Temps : Année -> Trimestre -> Mois

Chiffre d’affaires

(CA)

Budget Budget

Actu Actu : Actu1, Actu2, Actu3

Réalisé physique Réalisé

Comptabilisé Comptabilisé

Investissement

Temps, Budget,

Actu, Réalisé,

Comptabilisé

Avancement

physique

Avancement

Tableau 2.1 Indicateur, Axes du tableau de bord Tertiaire



Description des Tableaux de bord :

Plusieurs tableaux de bord et états ont été identifiés lors de la phase cadrage du

projet. On décrit ci-dessous quelques tableaux de bord de l’application « Tableaux de

Bord du Pôle », la structure de ces tableaux de bord est fournie en annexe.

Numéro

Du Tableau de

bord

Intitulé du tableau de bord

Indicateur (s)

1 Etat mensuel consolidé des

Investissements par direction et par

mode

Investissement

2 Etat mensuel consolidé des

Encaissements par (Direction Rabat,

Nord, Casa & Sud) par mode

Encaissement

3 Etat mensuel des Investissements

encaissements & CA par projet en MO et

MODCEM par direction

Investissement,

Encaissement

4 Etat mensuel des Investissements

encaissements & CA projet en MOD par

direction

Investissement,

Encaissement, CA

5 Etat cumulé des Investissements

encaissements & CA projet en MOD par

direction

Investissement,

Encaissement, CA

6 Etat cumulé des Investissements

encaissements & CA projet en Filiales par

direction

Investissement,

Encaissement, CA

Tableau 2.2 La liste des états de restitution à produire



3. Règles de gestion

3.1. Axes de calculs

Le tableau suivant résume les différents axes de calcules de notre système :

Axes Description

Avancement physique correspond au montant cumulé de l’avancement physique du chantier.

L’avancement physique du mois M doit être supérieur ou égale à celui du

mois M-1.

L’avancement physique à la fin du projet à 100% de l’investissement

engagé.

Le réalisé c’est le montant des prestations réalisées pour le projet communiqué par

les BET & OPC non encore facturé.

Le comptabilisé c’est le montant des factures comptabilisées (niveau comptabilité)

Le budget c’est les objectifs annuels en investissement, CA et encaissement (ne doit

pas changer)

Actu1 actualisation du budget (à la hausse ou à la baisse) en mars (janvier à

mars réel le reste estimé)

Actu2 actualisation du budget (à la hausse ou à la baisse) en juin (janvier à juin

réel le reste estimé)

Actu3 actualisation du budget (à la hausse ou à la baisse) en septembre (janvier

à septembre réel le reste estimé)

Tableau 2.3 Axes de calcules du système tableau de bord

3.2. Règles de calcules

Calcul des écarts actu & budget

� Ecart mensuel budget = Réalisé mensuel – budget mensuel � Ecart mensuel actu= Réalisé mensuel - actu mensuel � Ecart annuel budget = Réalisé annuel – budget annuel � Ecart annuel actu= Réalisé annuel – actu annuel



Indicateurs chef de projet

� Investissement mensuel = ∑ des types de dépenses renseignées par mois.

� Encaissement mensuel = ∑ des avances clients et/ou honoraires CGI mensuelles (en fonction du mode)

� CA mensuel = ∑ des ventes (à la livraison) et/ou honoraires CGI (à la facturation) mensuelles (en fonction du mode)

Indicateurs Direction

� Investissement mensuel = ∑ Investissement mensuel des projets de la direction

� Encaissement mensuel = ∑ Encaissement mensuel des projets de la direction

� CA mensuel = ∑ CA mensuel des projets de la direction

Indicateurs Pôle (Consolidé)

� Investissement mensuel = ∑ Investissement mensuel des projets du pôle

� Encaissement mensuel = ∑ Encaissement mensuel des projets du pôle

� CA mensuel = ∑ CA mensuel des projets du pôle

3.3. Qualité du système et service attendu

Le système de suivi « Dashboard CGI Tertiaire », doit garantir autant que possible

les facteurs de qualité suivants [X]:

� Fiabilité :

La fiabilité est l'aptitude du logiciel à maintenir son niveau de service dans des

conditions précises et pendant une période déterminée. La fiabilité recouvre les

notions de fréquence des défaillances, de tolérance aux fautes et de possibilité de

récupération après une défaillance.

- Disponibilité du service souhaitée: 24 H /24 et 7J/7.



� Facilité d’utilisation :

La facilité d’utilisation porte sur l'effort nécessaire pour l'utilisation du logiciel et se

traduit par des sous-caractéristiques de facilité de compréhension, facilité

d'apprentissage et facilité d'exploitation, complétude et sécurité.

� Rendement :

Le rendement traduit les performances du logiciel dans l'utilisation des ressources

qui lui sont allouées (périphériques, espace mémoire) et inclut son comportement en

matière de temps de réponse et de temps de traitement des différentes fonctions.

- Temps de réponse souhaité : 5 S

� Maintenabilité :

La maintenabilité recouvre les capacités du logiciel à être rapidement et facilement

corrigé, et à évoluer (aptitude à supporter facilement les modifications de ses

spécifications).

Conclusion

L’étude fonctionnelle a permis de préciser les principales caractéristiques du système

de suivi de projet. L’étude conceptuelle de l’outil fera l’objet du prochain chapitre

Chapitre 3 : Etude conceptuelle du projet


CHAPITRE 3

ETUDE CONCEPTUELLE DU

PROJET

INTRODUCTION ............................................................................................................................................ 34













CONCLUSION .................................................................................................................................................... 47



Introduction

Dans ce chapitre, on va présenter l’analyse et la conception de l’intranet Tableaux du système, et ce, en utilisant le diagramme de modélisation UML et en suivant les étapes du cycle de développement en Y.

1. Diagramme des cas d’utilisation général

1.1. Identification des acteurs

Dans ce paragraphe, on va énumérer les acteurs susceptibles d’interagir avec notre système :

Un acteur peut consulter et/ou modifier directement l’état du système, par émission et/ou réception de messages éventuellement porteurs de données.

Les acteurs identifiés à partir du CPS sont les suivants (cf. figure 3.1) :

� Directeur du Pôle Tertiaire. � La chargée d’études. � Directeurs des projets. � Chefs de projets.

Figure 3.1 Les acteurs du système « Tableau de bord Tertiaire »

Chaque utilisateur possède un profil qui détermine ses droits dans l’application (cf. Tableau 3.1) : C : Consultation, U : Utilisation, A : Administration



Tableau 3.

1.2. Diagramme de contexte

La figure suivante montre le diagramme de contexte illustrant les différents acteursinteragissant avec le système

1.3. Identification des messages

Réalisé et Avancement

physique

C

Directeur du Pôle

X

Chargée d’études

X

Directeurs de

projets

X

Chefs de projets X

Administrateur

: Etude conceptuelle du projet


Tableau 3.1 La pré-configuration des profils

Diagramme de contexte

La figure suivante montre le diagramme de contexte illustrant les différents acteursinteragissant avec le système (cf. figure 3.1) :

Figure 3.2 Diagramme de contexte

Identification des messages

Réalisé et Avancement

physique

Comptabilisé Budget et Actu

U C U C U

X X

X X X X

X X

X X X

La figure suivante montre le diagramme de contexte illustrant les différents acteurs

Administration application

A

X



On va détailler maintenant les différents messages échangés entre système et acteur.

C’est quoi un message :

Un message représente une interaction (communication) entre acteurs et système.

La réception d’un message est normalement considérée comme un événement.

Il faut se demander :

� Pour chaque acteur, quels sont les messages qui déclenchent un

comportement attendu par l’acteur du système, dans le cadre de son activité. � Pour le système, quels sont les messages émis à l’attention d’un acteur

particulier et qui portent une information utilisée par ce destinataire.

L’identification des interactions des acteurs avec le système consiste à l’identification des différents messages échangés par ces acteurs avec le système qu’on développera.

• Message(s) émis par les acteurs :

o Les authentifications (les login et mots de passe). o La gestion des projets. o La saisie des réalisations et avancement physiques. o La saisie du budget et des actualisations. o La saisie du comptabilisé. o La saisie de l’investissement global. o Les demandes des Reporting & TDBs des projets, /Direction et par

mode de gestion. • Message (s) reçu par les acteurs :

o Les différents types de Reporting & TDBs.

1.4. Identification des cas d’utilisations

Un cas d’utilisation modélise un service rendu par le système. Il exprime les interactions acteurs/système.

Dans notre système on a pu identifier les principaux cas d’utilisations que on a regroupées sous forme de modules pour une bonne structuration de l’application (cf. tableau 3.3) la liste complète fournie en annexe D :

Module Cas d’utilisation Acteur

Authentification S’authentifier Tous les acteurs



Administration Gérer Comptes Administrateur système

Gérer profils

Paramétrage application Gérer projets Chargé d’études

Gérer période

Gérer entités de base

Suivi budgétaire de projets Saisir de l’avancement physiques / investissement

Chefs de projets

Saisir du réalisé / Investissement, CA, Encaissement.

Saisir du budget annuel / projet

Saisir du comptabilisé Chargé d’études

Saisir investissement global

Saisir de l’investissement global

Reporting & Tableau de bord Reporting & TDB projet consolidé du pôle.

Directeur du Pôle

Reporting & TDB consolidé / Direction

Reporting & TDB des projets de la direction

Directeurs de projets

Reporting & TDB projets consolidé de la direction

Directeurs de projets

Reporting & TDBs Chargé d’études

Reporting & TDB projets Chef de projets

Exporter TDB Excel Directeur de pôle, Chargé d’études, chef de projets.

Tableau 3.2 Les modules des cas d'utilisations



Après avoir identifié les cas d’utilisation de l’application, on va les représente sur un diagramme de cas d’utilisations comme illustré ci-dessous :

Figure 3.3 Diagrammes général des cas d’utilisations



2. Description des cas d’utilisations

Vu la taille de l’application, on va détailler que quelques cas d’utilisations qui illustrent le cœur de fonctionnement de l’application, les cas d’utilisations restants et les diagrammes de séquence sont mis en annexe D.

2.1. Module « Authentification »

Figure 3.4 Diagramme du cas d'utilisation "S'authentifier"

� Cas d’utilisation s’authentifier :

Ce cas d’utilisation est le cas initial de l’application, donc avant toute action sur le Tableau de bord, les acteurs doivent s’authentifier.

Nom du cas S’authentifier

But Sécurisé l’accès au système

Acteurs Tous les utilisateurs

Pré-conditions Le système on marche

Post-condition � La session est ouverte � Chargement du profil

Tableau 3.3 Cas d’utilisation " s’authentifier "

Tous les utilisateurs du Système peuvent accéder au système. Cependant, chacun d’eux à un certain nombre de privilèges et profils. C’est pour cela, qu’il faut au début s’identifier en donnant son login et son mot de passe.



� Scénario nominal :

� Au démarrage l’utilisateur saisie son login et mot de passe sur la page d’authentification pour activer la session et charger son profil.

� Si le login et le mot de passe est incorrect, l’exception ‘E1’ est généré. � Fin de cas d’utilisation.

� Exception :

� E1 : Sur la page d’authentification on signale que le login ou le mot de passe est incorrect et on demande leurs saisies à nouveau.

2.2. Module « Administration »

Figure 3.5 Diagramme de cas d’utilisation du module " administration "

� Cas d’utilisation « gérer compte utilisateur »

Nom du cas d’utilisation

Gestion des utilisateurs

But Gérer les comptes utilisateurs et gérer profils.

Acteurs Administrateur système

Pré-conditions L’administrateur est authentifié.

Post-condition Les mises à jour sont effectuées.

Tableau 3.4 Cas d’utilisation « gérer compte utilisateur »


Ce cas d’utilisation commence lorsque l’administrateur demande la gestion des comptes utilisateurs du système.

o Enchainement ‘1’ : Ajout d’un nouvel utilisateur



L’administrateur saisit le login et le mot de passe de l’utilisateur à créer et lui associe un profil. Si l’utilisateur en question est : directeur ou bien chef de projets, les projets doivent être précisés.

Si le login choisi existe déjà, il faut déclencher [Exception 1 : login déjà existant]

o Enchainement ‘2’ : Modification d’un utilisateur

L’administrateur clique sur le login de l’utilisateur qu’il désire modifier. Une page d’édition des données de l’utilisateur est alors affichée lui permettant d’effectuer les modifications qu’il souhaite.

Si le nouveau login choisi (après la modification) existe déjà, il faut déclencher

[Exception 1 : login déjà existant]

o Enchainement ‘3’ : Désactivation d’un compte utilisateur

L’administrateur sélectionne l’utilisateur, puis il clique sur désactiver. Le système demande une confirmation de désactivation avant de désactiver l’utilisateur. Si l’utilisateur à désactiver est un chef de projets, le(s) projet(s) doivent être affectés à autre chef

Ce cas d’utilisation se termine lorsque la chargée d’études valide la mise à jour des comptes utilisateurs.

� Cas d’utilisation « gérer profil »


Ce cas d’utilisation commence lorsque l’administrateur demande la gestion des profils du système.

o Enchainement ‘1’ : Affectation profils.

L’administrateur sélectionne le nom de profil et lui associe un ou plusieurs utilisateurs, si le profil sélectionner et directeur du pôle et ce dernier est déjà affecter, il faut déclencher une exception [Exception 2 : Profil occupé].

o Enchainement ‘2’ : Modification d’un profil existant:

L’administrateur liste tous les profils qui existent dans le système, sélectionne celui qu’elle désire modifier. Une page d’édition s’affiche en lui permettant d’effectuer les modifications qu’elle souhaite. Le système demande une confirmation de modification.

Ce cas d’utilisation se termine lorsque L’administrateur valide la mise à jour des profils.



o Exception :

[Exception 1 : Profil occupé]

Un message d’erreur doit être affiché précisant que le profil est occupé (cas de directeur du pôle, directeur de projets).

[Exception 1 : login déjà existant]

Un message d’erreur doit être affiché précisant que le login choisi a déjà été utilisé.

[Exception 2 : Profil occupé]

Un message d’alerte s’affiche, informant l’utilisateur que le profil choisi est réservé pour un autre utilisateur du système.

2.3. Module « Paramétrage système »

Figure 3.6 diagramme de cas d'utilisations du module paramétrage système

� Cas d’utilisation « Gestion de projets »


Gestion de projets

But Détaille les étapes permettant à la chargée d’études de bien gérer les projets du Pôle (création suppression…), gérer les paramètres globales du projet (mode de gestion, maitrise d’ouvrages, prestataires).

Acteurs Chargée d’études

Pré-conditions La chargée d’études est authentifiée.

Post-condition La mise à jour est effectuée.

Tableau 3.5 Cas d’utilisation « Gestion de projets »




Ce cas d’utilisation commence lorsque la chargée d’études demande l’administration des projets (Création/Modification/Suppression/Fusion et éclatement).

o Enchainement ‘1’ : Création d’un projet :

La chargé d’études saisie les différents attributs du projet. Puis le système valide les

informations et ajoute le nouveau projet.

o Enchainement ‘2’ : Suppression d’un projet :

La chargée d’études recherche un projet, puis demande sa suppression. Le système demande une confirmation de la suppression avant de supprimer le projet.

o Enchainement ‘5’ : Modification d’un projet :

La chargée d’études sélectionne le projet qu’elle désire modifier. Une page d’édition des données du projet est alors affichée lui permettant d’effectuer les modifications qu’il souhaite.

Ce cas d’utilisation se termine lorsque la chargée d’études quitte la partie ‘Création d’un projet’.

� Cas d’utilisation « gérer de période »


Gestion de période

But Autorisation d’une période précise de saisie au cas où l’utilisateur à dépasser la période autorisée.

Acteurs Chargée d’études

Pré-conditions La chargée d’études est authentifiée.

Post-condition Le prolongement est effectué.

Tableau 3.6 Cas d’utilisation « gestion de période »


Ce cas d’utilisation commence lorsque la chargée d’études demande la gestion de période de saisie.

o Enchainement ‘1’ : Prolonger la durée de saisie :

La chargée d’études liste toutes les demandes de prolongement de période de saisie, puis elle clique sur autorisé saisie.



Ce cas d’utilisation se termine lorsque la chargée d’études valide la mise à jour des profils.

2.4. Module « Suivi budgétaire du projet »

Figure 3.7 diagramme de cas d'utilisation du module suivi budgétaire de projets

On détaillerai les deux cas d’utilisation, « saisie de l’avancement physique », « saisie du réalisé », le reste suit la même démarche

� Cas d’utilisation « Saisie de l’avancement physique »


Saisie de l’avancement physique

But Saisir mensuellement le pourcentage de l’avancement physique, tout en respectant la règle ; (Avancement (M) >= Avance (M-1))

Acteur(s) Chef de projet

Pré-conditions Le chef de projet est authentifié et période de saisie c’est la 1ère semaine du mois M.

Post-condition La saisie est effectuée.

Tableau 3.7 Cas d’utilisation « Saisie de l’avancement physique »

�� Scénario nominal :

Ce cas d’utilisation commence lorsque le chef de projets demande la saisie mensuelle de l’avancement physique en terme d’investissement (foncier, VRD, …) pour son projet.

o Le chef de projet commence par sélectionner le scénario souhaité puis sélectionne le projet.



o Le système envoie le formulaire de saisie des investissements avec les

différents types de dépense.

Ce cas d’utilisation se termine lorsque le chef de projet quitte la partie suivi de projets.

� Cas d’utilisation « Saisie du réalisé» Nom du cas d’utilisation

Saisie du réalisé

But Saisir mensuellement le montant des prestations réalisées pour le projet.

Acteur(s) Chef de projet

Pré-conditions Le chef de projet est authentifié et période de saisie c’est la 1ère semaine du mois M.

Post-condition La saisie est effectuée.

Tableau 3.8 Cas d’utilisation « Saisie du réalisé»

2.5. Module « Reporting & Tableau de bord »

Figure 3.8 Diagramme du Cas d’utilisation du module reporting & TDB projet



� Cas d’utilisation « Consultation Reporting & TDB du Pôle ».

Nom du cas Consultation Reporting & TDB du Pôle

But Production d’états et de tableaux de bord

Acteurs Directeur du Pôle

Pré-conditions Session directeur du Pôle est ouverte.

Post-condition Génération & visualisation de reporting & TDBs des projets.

Tableau 3.9 Cas d’utilisation Consultation reporting & TDB projet

Ce cas d’utilisation englobe deux sous cas d’utilisations globaux (consultation TDBs consolidé par direction/ consultation TDBs consolidé du pôle) permettra le suivi des états des projets du pôle tertiaire à travers des différents indicateurs de pilotages (Investissement, Encaissement, CA).

�� Scénario nominal :

o Ce cas d’utilisation commence lorsque le directeur du Pôle demande la consultation de TDB des projets.

o Le directeur du pôle choisi l’un des types des TDBs (voir tableau A.5 « annexe D »)



3. Diagramme de classe

En se basant sur les diagrammes des cas d’utilisations et de séquences (voir annexe D) on a élaboré le diagramme de classe.

Vu le nombre important des classes dans chaque module, on va présente seulement le diagramme des classes des deux modules « suivi budgétaire de projet » et « Authentification et sécurité ».

Figure 3.9 Diagramme de classe

Conclusion On a présenté dans ce chapitre une vue conceptuelle sur le système tableau de bord tertiaire. Le diagramme des cas d’utilisations et diagramme reflète les fonctionnalités offertes aux utilisateurs de notre système, dans le prochain chapitre nous aborderons la phase de réalisation du projet.

Chapitre 4 : Réalisation du projet Tableau de bord Tertiaire


CHAPITRE 4

RÉALISATION DU PROJET

TABLEAU DE BORD TERTIAIRE

INTRODUCTION............................................................................................................................................ 49

1. CHOIX TECHNIQUES................................................................................................................................... 49

1.1. Framework .Net ..................................................................................................................................... 50

1.2. Les composants du .NET ....................................................................................................................... 51 1.2.1. Le langage C# ...................................................................................................................................................... 51

1.2.2. Asp.Net ............................................................................................................................................................... 51

1.2.3. ADO.Net ............................................................................................................................................................. 52

1.3. Framework d’application Asp.NET MVC ............................................................................................... 52 1.3.1. Présentation du Framework Asp.Net MVC ......................................................................................................... 53

1.4. Framework de persistance « Entity Framework » ................................................................................ 54

1.5. Outils de travail ...................................................................................................................................... 56 1.5.1. Visual Studio Team System 2008 ........................................................................................................................ 56

1.5.2. Le choix du SGBD SQL Server Entreprise Edition 2008 ....................................................................................... 56

1.5.3. Le serveur de reporting : SQL Server Reporting Services 2008........................................................................... 57

2. ELEMENT SUR L’IMPLEMENTATION DU SYSTEME TABLEAU DE BORD TERTIAIRE ..................... 58

2.1. Architecture logicielle ............................................................................................................................. 58

2.2. Les interfaces Homme Machine ............................................................................................................. 59 2.2.1. Charte graphique ................................................................................................................................................ 59

2.2.2. Page d’accès au système .................................................................................................................................... 60

2.2.3. Module « Administration »................................................................................................................................. 60

2.2.4. Module « Suivie budgétaire du projet » ............................................................................................................. 61

2.2.5. Module « Paramétrage de l’application » .......................................................................................................... 63

CONCLUSION ............................................................................................................................................ 63



Introduction

L'un des sujets les plus controversés en matière de développement d'applications est celui du choix des outils de développement, et ceux qui décident ce choix sont les membres de la haute direction, les directeurs et chefs de projets SI, développeurs expérimentés aussi bien que les nouveaux développeurs.

Bien souvent, ce sont des concepts à la mode qui l'emportent, comme indépendance des fournisseurs, solution ouverte ou multi-langage. Parfois la préférence va vers un fournisseur ou un langage de programmation déterminé. Il est important de faire le bon choix car cela se traduira par des capacités et des performances supérieures de l’application, une plus grande facilitée de développement et de maintenance et des frais de propriété moindres.

A cet effet, On va tout d’abord commencer par le choix de la technologie adéquate, ensuite on présentera les différents Framework utilisés, après on enchainera par la présentation de l’architecture logicielle adaptée pour présenter à la fin les différents Interfaces Homme Machine qu’offre le ‘Tableau de bord Tertiaire’.

1. Choix techniques

Pour développer notre système de suivi, nous avons utilisé la technologie .Net de Microsoft, version 3.5.

Due que ce choix est imposé par l’entreprise qui vise la migration vers DOT.Net.

Figure 4.1 Version cumulées du .NET Framework



1.1. Framework .Net

Le Framework .NET (prononcez «Dotnet») est un standard proposé par la société Microsoft, pour le développement d'applications d'entreprises multi-niveaux, basées sur des composants. Microsoft .NET constitue ainsi la réponse de Microsoft à la plate-forme J2EE de Sun.

.NET permet de construire, de déployer et d’exécuter des applications Web, des services Web, aussi des applications classiques s’exécutant sur Windows. Le .NET Framework est un environnement qui est disponible gratuitement sur toutes les versions de Windows depuis 95. Les .NET Servers sont la nouvelle génération des serveurs Microsoft qui vont donc succéder aux Windows 2003 Servers.

Figure 4.2 Architecture Framework .Net [6]

Nouveautés du .Net Framework 3.5

Microsoft fait évoluer les langages C# et VB .NET, de manière à leur ajouter de nouveaux concepts (initialiseur d’objets, méthodes d’extension, inférence de type, type anonyme). L’introduction de ces concepts ont permis d’intégrer dans le jeu instructions des langages, des instructions de requêtage, permettant de requêter différentes sources de données : grappes d’objets (Linq For Object), flux XML (Linq For XML), base de données SQL Server (Linq For SQL, Linq For Entities).



La figure 3 illustre l’architecture fonctionnelle de .NET 3.5 :

Figure 4.3 Architecture du .NET Framework 3.5

1.2. Les composants du .NET

Nous décrivons dans cette partie les composants de .Net que nous avons utilisé pour la réalisation du système. 1.2.1. Le langage C#

Le langage C# est devenu le langage de référence de Microsoft. C’est le langage star de la nouvelle version de Visual Studio .NET, un langage dérivé du C++, qui reprend des caractéristiques du langage Java. C# peut être utilisé pour créer des applications Windows et Web. Le langage C# ajoute au C++ les techniques de construction de programmes sur base de composants prêts à l’emploi avec propriétés et événements.

Il a les caractéristiques suivantes : � Purement orienté objet : tout est classe, � Types précisément conformes à l’architecture .NET et vérifications de

type plus élaborées, � Gestion automatique de la mémoire (ramasses miettes).

Pas d’héritage multiple mais plusieurs interfaces.

1.2.2. Asp.Net

ASP.NET est la nouvelle version d’Active Server Pages (ASP) et fait partie intégrante du Framework .NET, permet la création d’applications web au sein de .NET et non pas de pages web comme avec ASP.



Figure 4.4 Architecture Asp.Net

1.2.3. ADO.Net ADO.Net est conçu pour charger des données à partir d’une source de données et pour les utiliser ensuite dans un état déconnecté.

Cet état déconnecté permet au formulaire Web de fonctionner de façon semi indépendante par rapport aux sources de données et de réduire ainsi le trafic sur le réseau. ADO.Net utilise le langage XML (Extensible Markup langaage) comme format de transmission universel, garantissant une intéropérabilité avec n’importe quelle plate-forme sur laquelle est installé un analyseur XML.

1.3. Framework d’application Asp.NET MVC

Compte tenu du choix effectué au niveau de la technologie adopté pour le développement de notre système : .Net, et avec l’objectif d’avoir une architecture n tierces favorisant un coût de maintenance réduit, il était logique de s’orienter vers le



nouveau Framework dans le monde Microsoft Asp.NET MVC version 1.0 qui permet d’organiser le développement selon le design pattern MVC1.

1.3.1. Présentation du Framework Asp.Net MVC

ASP.NET MVC est l’implémentation du design pattern MVC pour la conception d’applications web. Ce design pattern permet le découpage de notre application en 3 couches distinctes : Model, View et Controller.

� La structure d’un projet ASP.NET MVC :

Figure 4.5 La structure de l'application "Dashboard CGI Tertiaire"

1 Pour plus de détail sur le design Pattern MVC veuillez vous référer à l’Annexe B

Ce dossier contiendra les classes qui feront

office de contrôleur.

Dans ce dossier se trouve toutes les vues.

Le Global.asax contient toutes les informations sur les « Routes ».

Ici se trouve toutes les classes de manipulation de données.

Les modules de test unitaires,



Remarque :

La structure d’un projet ASP.NET MVC est un peu différente de celle d’un projet ASP.NET classique. On remarque la présence des dossiers Controllers, Models et Views.

Il présente plusieurs avantages par rapport au Framework classique comme :

� La facilité de gérer une architecture complexe en divisant l'application en un modèle, une vue et un contrôleur.

� Il offre un meilleur support pour le développement dirigé par les tests. � Le support des fonctionnalités existantes d'ASP.NET classique.

1.4. Framework de persistance « Entity Framework »

L’Entity Framework est une technologie intégrée à ADO .Net, qui permet de développer des applications de gestion de données, sans se soucier de la conception du schéma de base de données devant contenir les données de l’application. Il constitue une couche d'abstraction, au travers d'entités définies dans un modèle, appelé Entity Data Model (EDM) (cf. figure 4.6). Ce modèle est divisé en 3 parties :

� Modèle conceptuel : syntaxe CSDL au format XML (Conceptual Schema Definition Language) qui définit les entités et les associations entre elles. Il décrit les classes utilisées dans l’application pour accéder et gérer les données.

� Modèle logique : syntaxe SSDL (Store Schema Definition Language). Il définit

les tables et l’ensemble des contraintes sur ces tables. Il présente ainsi une vue de la base de données.

� Schéma de liaison : syntaxe MSL (Mapping Specification Language) qui permet de faire le lien entre les 2 modèles précédents. Il réalise alors les opérations de mapping. Ce Framework est choisi par ses différents avantages pour persister la base de données « Tableau de bord Tertiaire »



Figure 4.6 Fonctionnement du Framework Entity [8]



1.5. Outils de travail Les outils de travail utilisés dans la réalisation de projet se présentent comme suit

� Système d’exploitation : Windows Server 2003 R2 � Editeur Visual Studio Team System 2008. � Système de Gestion de Base de Données : SQL Server Entreprise Edition

2008. � Serveur de Reporting : SQL Server Reporting Services 2008. � Serveur d’applications : IIS.

1.5.1. Visual Studio Team System 2008

Pou faciliter la tâche du développeur, Microsoft propose un environnement de développement logiciel de collaboration, de métrique et de reporting. Avec Visual Studio le développement .NET devient beaucoup plus rapide et simple.

En effet avec Visual Studio Team System on peut :

� gérer l'évolution des besoins tout au long du projet ; � renforcer la communication entre les chefs de projet, les développeurs et les

testeurs ; � tester avec précision la qualité et la fiabilité des applications ; � avoir une parfaite visibilité sur l'avancement du projet pour prendre les

décisions qui s'imposent et respecter les délais ; � respecter la stratégie internationale de développement, les obligations légales

et les exigences de conformité.

1.5.2. Le choix du SGBD SQL Server Entreprise Edition 2008

SQL Server 2008 est la dernière version du SGBDR de Microsoft (Système de Gestion de Base de Données Relationnelles) (cf. figure 4.7).



Figure 4.6 Nouvelle fonctionnalités de SQL Server 2008 [9]

Cette version de SQL Server intègre de nouvelles fonctionnalités et des améliorations qui augmentent la puissance et la productivité des développeurs et des administrateurs qui conçoivent, développent et maintiennent des systèmes de stockage de données (Améliorations de la sécurité, Améliorations de la disponibilité).

1.5.3. Le serveur de reporting : SQL Server Reporting Services 2008

Le SSRS est une technologie serveur de création de rapports qui prend en charge la création, la distribution, la gestion et l'accès de l'utilisateur final aux rapports.

Figure 4.7 Architecture Serveur de Reporting SSRS [10]

La réalisation des rapports a été confiée à SQL Server Reporting Services 2008. En effet, cet outil dédié à ce genre de travail et est doté d’une puissance et d’une robustesse impressionnante grâce à sa simplicité lors de la génération des rapports personnalisés. (Voir figure 4.9)



Figure 4.

2. Elément sur l’implémentation dubord Tertiaire

2.1. Architecture logicielle

L’architecture de l’application décomposition web n-tière, cette architecture permentre les couches et une grande réutilisation de plusieurs modules, la communication entre les couches est assurée par le FMVC.

La figure 4.10 illustre l’architecture applicative de notre projet

Figure 4.

� Couche présentation

Couche présentant l’interface web avec laquelle va interagir l’utilisateur final

: Réalisation du projet Tableau de bord Tertiaire


Figure 4.8 Exemple de rapport générer avec SSRS 2008

Elément sur l’implémentation du système Tableau de

Architecture logicielle

L’architecture de l’application Tableau de bord Tertiairetière, cette architecture permet un faible couplage

entre les couches et une grande réutilisation de plusieurs modules, la les couches est assurée par le Framework

illustre l’architecture applicative de notre projet :

Figure 4.9 Architecture applicative du système

Couche présentation :

Couche présentant l’interface web avec laquelle va interagir l’utilisateur final

système Tableau de

Tableau de bord Tertiaire adopte une et un faible couplage

entre les couches et une grande réutilisation de plusieurs modules, la ramework ASP.NET

Couche présentant l’interface web avec laquelle va interagir l’utilisateur final.



� Couche logique applicative :

Couche qui contient la logique métier de l’application et l’expose sous forme de service à la couche présentation.

� Couche Accès aux données :

Couche d’accès aux données, elle encapsule l’exécution des requêtes passées à la base de données.

� Couche de mappging :

Couche de mapping objet relationnel assurée par le Framework Entity.

2.2. Les interfaces Homme Machine

2.2.1. Charte graphique

Dans tout projet de développement web, il est important de dispose d’une unité graphique, pour qu’il soit agréable à utiliser, c’est ce qu’on désigne par la charte graphique. La charte graphique signifie tout ce qui apparaît au niveau des interfaces de l’application comme les couleurs utilisées, les logos et les images…

Toute charte graphique cohérente repose sur deux piliers :

� Un choix de couleurs dominantes pour l’outil : généralement deux couleurs principales et leurs dérivés.

� Un style bien marqué que l’on retrouvera tout au long du projet pour en marquer l’identité.

Les éléments à prendre en considération et à respecter pour l’élaboration de la charte graphique de notre application sont les suivants :

� L’identité visuelle et le logo de CGI. � Les couleurs suivants : gris, rouge, noir, blanc.

Chaque couleur porte un sens en termes de communication visuelle :

� Le gris : couleur conservatrice, sécurité, maturité, fiabilité � Le rouge : action, énergie, force, capte l’attention � Le noir : espace, puissance, élégance, sérieux � Le blanc : pureté, vie.



2.2.2. Page d’accès au système

La première interface qui s’affiche lorsqu’on lance l’application est

Figure 4.10 page d'accès au système

2.2.3. Module « Administration »

� Gestion des comptes utilisateur

Figure 4.11 IHM, Gestion compte utilisateurs



� Ajouter utilisateur

Figure 4.12 IHM, Ajouter utilisateur

� Paramétrage profil, ajouter rôle :

Figure 4.13 IHM, Ajouter Rôle système

2.2.4. Module « Suivie budgétaire du projet »

� Saisie du budget annuel par projet :

Figure 4.14 IHM, Saisie budget annuel



� Saisie de l’avancement physique par projet :

Figure 4.15 IHM, Saisie avancement physique

� Lise des avancements physique saisie

Figure 4.16 IHM, Liste avancement physique

� Saisie des investissements

Figure 4.17 IHM, Saisie des investissements



2.2.5. Module « Paramétrage de l’application » � Ajouter projet

Figure 4.18 IHM, Ajouter projet

� Liste de projet du Pôle Tertiaire

Figure 4.19 IHMListe de projets

Conclusion

On a présenté dans ce chapitre une vue globale sur la réalisation du système de suivi,

et cela en décrivant l’environnement du travail, les différents outils et Framework

utilisés et quelques interfaces de l’application.

Projet de fin d’études - ENSIAS 2009 Page | 64

Conclusion et Perspectives

Aujourd'hui le besoin en matière d'aide à la décision devient crucial. Pour piloter

dans un / en un environnement perturbé, instable et chaotique, il faut concevoir un

système de mesure de la performance conforme et efficace. Dans cette optique ce

travail peut être considéré comme une initiation à la mise en place d’une solution

décisionnelle complète au sein de la Compagnie Générale Immobilière, ainsi ouvrant

la voie pour introduire de nouveaux domaines, d’autres axes d’analyse, de nouveaux

indicateurs.

En guise de conclusion, revenons à l’objectif du travail. Notre projet de fin d’études

consistait en l’étude, la conception et la réalisation d’un système de suivi de projets

de promotion immobilière, en passant par les différentes étapes du cycle du

développement d’un projet depuis l’étude de l’existant et la spécification des besoins,

suivi de la modélisation du le système suivant le langage UML, au terme de son

étude fonctionnelle, et enfin, la mise en exploitation et le déploiement du système.

L’expérience vécue durant ce stage était fort profitable, dans la mesure où elle a

permis de consolider mes acquis au sein de l’ENIM notamment en matière de

développement informatique, On a eu ainsi l’opportunité de travailler dans un

environnement de très haute niveau et de développer notre relationnel au sein de

l’organisme d’accueil.

On a pu également développer nos connaissances en manipulant des outils de

développement très complets, dotés de fonctionnalités puissantes et adaptés au

travail de groupe. Sur le plan personnel le stage de fin d’études m’a permis de voir

une autre dimension du métier de l’informaticien, celui de l’informaticien

communicateur qui a pour mission de comprendre un nouveau métier au point de

pouvoir en exprimer les besoins et les traduire techniquement pour les mettre en

place par la suite.


Les principales difficultés rencontrées durant notre projet résident dans la

compréhension des données utilisées et des besoins du client. En effet il a été

difficile de bien cerner leurs besoins afin de les retranscrire sur papier. De plus, la

particularité des données utilisées a nécessité une bonne compréhension de celles ci

et des différentes étapes de leur traitement.

Bibliographie

Projet de fin d’études - ENSIAS 2009 Page | 66

Bibliographie & Webographie

Bibliographie :

[1] Document Note d’information CGI ‘Introduction En bourse A la Hauteur de 20 % du Capital

[2] Document communiqué 2009 CGI : www.cgi.ma

[3] Le MÉTROscope Indicateurs et Tableaux de bord (Développement de logiciel) État de la

normalisation Les Éditions d’ADELI

[4] Gestion d'un projet système d'information Ch. MORLEY

[5] Manager un projet pour la première fois, DE L’IDÉE À LA RÉALISATION, EYROLLES

Edition d’organisation

[6] Pro LINQ Object Relational Mapping with C# 2008, Vijay P. Mehta, Apress

[7] Pro C# 2008 .NET 3.5 Platform Andrew Troelsen Apress.

[8] Pro ASP.NET MVC Framework by Steven Sanderson 2009.

[9] Professional ASP.NET MVC 1.0, by Wiley Publishing, Edition Wrox.

[10] .NET Framework 3.5 Enhancements Training Kit, Microsoft, August 2008 Release.

WeboGraphie :

[1] http://technet.microsoft.com/en-us/magazine/cc434691.aspx

[2] http://msdn.microsoft.com/fr-fr/magazine/dd695917.aspx

[3] http://www.dotnetguru.org/

[4] http://dotnet.developpez.com/cours/

[5] http://msdn.microsoft.com/en-us/library/ms229862.aspx

[6] http: // www.laboratoire-microsoft.org/articles/sql-server-reporting-service-

2005/2/#38

[7] http: // vincenthomedev.wordpress.com/2008/03/12/linq-to-sql-vs-linq-to- entities/

Annexes


Annexe A Extraits du plan management de projet

1. Introduction L’annexe A sera dédié à la présentation du PMP qu’on a élaboré à la phase de

démarrage de notre projet.

Le plan de management de projet est un document qui donne un aperçu sur la

portée du projet, ses objectif, ses contraintes, la liste des livrables, un sommaire du

calendrier et le plan de la mise en œuvre de la gestion du projet.

2. Contraintes du projet : Lors de l’élaboration de notre projet de fin d’études on a été soumi à un ensemble de

contraintes qui sont :

Le délai pour la livraison du produit final est fixé pour le mi-aout. Les

produits intermédiaires (CPS, PMP, Dossier Technique, …) seront livrés

suivant les délais fixés par les encadrants interne et externe en vue de valider

le passage d’une phase à une autre.

Une formation doit être prévue pour assimiler les technologies autour de la

plateforme Dot.net 3.5 à savoir Link To Entity, ASP.Net MVC… ainsi que

les principes de l’outil de Reporting (SSRS, Serveurs d’applications, Report

Definition Language...)

Il faut prendre en considération la disponibilité des encadrants interne

(Mr.Nassar) et externe (Mr.Benbouzid).

La disponibilité du serveur pour la réalisation du projet.

Annexes


3. Les processus du projet :

Processus

phases descriptions

Démarrage

Démarrage et planification Cadrage du projet rédaction de la dernière version du cahier des charges et du PMP

Planification

Formation technologiques, étude de l’existant, élaboration du dossier technique,

Identification des besoins et choix des solutions open source

Exécution

Réalisation des modules du système

Exécution de la migration par module.

Maitrise Evaluation & Tests Test du système et ces différents composants

Clôture Clôture Clôture du projet (Archivage des documents et livrables du projet)

Tableau A.1 Processus du projet

4. Plan de Communication :

La communication entre les différentes parties prenantes du projet s’effectue par des

réunions et des communiqués par e-mail. Les réunions étaient planifier soit par notre

demande ou de la part des encadrants interne et externe.

Annexes


Type Type de diffusion Sujet Périodicité Responsable

Personnes

concernées

Réunion

Demande de la part des encadrant externes ou du stagiaires.

Faire le point sur l’avancement du projet et résolution des problèmes

Chaque Jour

Elkodri Benchchaoui

A.Benbouzid C.Benabdesselam M.Kallida

Réunion

Demande de la part des personnes de pilotage du projet (chargée d’études)

Etat d’avancement du projet + validation des phases

A la demande

Pôle Tertiaire CGI

N.Soufiani A.Benbouzid C.Benabdesselam

Tableau A.2 Plan de communication du projet

5. Plan de gestion des risques :

Description du risque

probabilité impact Mesure

Dépassement des délais

25 % 3 Opter pour une gestion de projet modulaire avec des livraisons intermédiaires

Difficultés technologiques

50 % 1

Consacré une grande période pour la documentation et la formation sur les frameworks, ASP.Net MVC, Entity Framwork

Problèmes techniques durant la réalisation

50 % 2 Respecter la stratégie initiale

Perte du code / Des documents 40 % 3

Réplication des documents.

Difficulté durant les tests

50 % 3 Respecter la démarche

* 1 : Faible, 2 : Moyen, 3 : Fort Tableau A.3 plan de gestion des risques

Annexes


6. Plan de gestion de configuration

La gestion de configuration consiste à gérer la description technique d’une application (et de ses divers composants), ainsi qu'à gérer l'ensemble des modifications apportées au cours de l'évolution du projet au code sources et aux différents documents. Dans le cadre de notre projet, la gestion de configuration est divisée en deux parties : celle des livrables et celle du code.

Concernant les livrables, pour chaque modification, la version du document est incrémentée et la date de modification est spécifiée. Et s’agissant des documents de configuration et techniques, on archive les différentes versions des documents.

7. Plan d’assurance et contrôle de qualité : Le plan d'assurance et contrôle qualité vise à décrire les dispositions prises pour obtenir la qualité de la réalisation du projet. Il définit les méthodes, l'organisation et les activités d'assurance et de contrôle de la qualité spécifique au projet, ainsi que les procédures à suivre, les outils à utiliser, les normes à respecter, la méthodologie et la démarche de la réalisation et les contrôles prévues pour chaque activité.

En ce qui concerne notre projet, le tableau de bord tertiaire doit garantir les facteurs de qualité suivants :

Adaptabilité : minimiser l'effort nécessaire pour le modifier par suite

d'évolution des spécifications

Conformité : contenir un minimum d'erreurs, et satisfaire les spécifications.

Efficacité : se limiter à l'utilisation des ressources strictement nécessaires à

l'accomplissement de ses fonctions.

Sécurité : sécuriser l’ensemble des composants de l’intranet.

Portabilité : minimiser l’effort pour se faire transporter dans un autre

environnement matériel et/ou logiciel.

8. Plan de clôture du projet : Pour le plan de clôture du projet, il s’agira d’effectuer les taches suivantes :

D’archiver l’ensemble des documents produits pendant le déroulement du

projet.

La sauvegarde du code de la version cible réalisée.

La livraison du rapport final du stage qui englobe la description détaillée des différentes phases du projet.

Annexes


Annexe B

Le Modèle-Vue-Contrôleur (MVC) est une architecture et une méthode de conception qui organise l'interface Hommedivise l'ihm en un modèleutilisateur) et un contrôleur (logique desynchronisation), chacun ayant un rôle précis dans

MODEL : Cette couche va contenir l’accès aux données via LinqSQL/Entities ou via votre propre provider de données. Cette couche permettra aussi la mise à jour des donnée

View : Cette couche correspond à l’interface de votre application. Elle permettra d’afficher les données du model et de récupérer les entrées utilisateurs.

Controller : C’est la couche qui pilotera toute votre application. Elle permettra de gérer les actions à réaliser sur les formulaires suivant les actions utilisateurs. De plus, elle gèrera les modifications à apporter à la couche Model donc aux données.

En résumé, le workflow d’une application basée sur MVC est le suivant :

la requête est analysée par le contrôleur le contrôleur demande au modèle approprié d'effectuer les traitements le contrôleur renvoie la vue adaptée, si le modèle ne l'a pas déjà fait.


Le Design Pattern MVC

Contrôleur (MVC) est une architecture et une méthode de organise l'interface Homme-machine d'une application logicielle. Il

divise l'ihm en un modèle (modèle de données), une vue (présentation, interface utilisateur) et un contrôleur (logique de contrôle, gestion des évènements,

chacun ayant un rôle précis dans l'interface.

Figure A.1 Design Pattern MVC []

: Cette couche va contenir l’accès aux données via LinqSQL/Entities ou via votre propre provider de données. Cette couche permettra aussi la mise à jour des données affichées dans la vue.

: Cette couche correspond à l’interface de votre application. Elle permettra d’afficher les données du model et de récupérer les entrées

: C’est la couche qui pilotera toute votre application. Elle permettra de gérer les actions à réaliser sur les formulaires suivant les actions utilisateurs. De plus, elle gèrera les modifications à apporter à la couche Model donc aux données.


la requête est analysée par le contrôleur le contrôleur demande au modèle approprié d'effectuer les traitementsle contrôleur renvoie la vue adaptée, si le modèle ne l'a pas déjà fait.

Le Design Pattern MVC

Contrôleur (MVC) est une architecture et une méthode de machine d'une application logicielle. Il

(modèle de données), une vue (présentation, interface contrôle, gestion des évènements,

: Cette couche va contenir l’accès aux données via Linq-To-SQL/Entities ou via votre propre provider de données. Cette couche

s affichées dans la vue. : Cette couche correspond à l’interface de votre application. Elle

permettra d’afficher les données du model et de récupérer les entrées

: C’est la couche qui pilotera toute votre application. Elle permettra de gérer les actions à réaliser sur les formulaires suivant les actions utilisateurs. De plus, elle gèrera les modifications à apporter à la couche


le contrôleur demande au modèle approprié d'effectuer les traitements le contrôleur renvoie la vue adaptée, si le modèle ne l'a pas déjà fait.

Annexes


Annexe C Comparatif de processus de développement

1. Introduction :

Un processus de développement est un ensemble d'étapes partiellement ordonnées, qui concourent à l'obtention d'un système logiciel ou à l'évolution d'un système existant (comme c’est le cas pour les projets de migrations). L’objectif final de l’adoption d’un processus de développement est de produire des logiciels de qualité (qui répondent aux besoins des utilisateurs) et dans des temps et des coûts prévisibles.

Dans chaque étape du processus, on produit des modèles, et/ou de la documentation, et/ou du code.

2. UML et les processus de développement :

UML (Unified Modeling Language) n’est qu’un langage, parce qu’il ne spécifie pas comment décrire des cas d'utilisation, des classes, des interactions...et il ne préjuge pas de la démarche employée. C’est la raison pour laquelle on trouve des méthodes qui s’appuient sur UML comme :

� 2TUP (2 track unified process) � RUP (Rational Uni_ed Process) � XP (eXtreme Programming) � ….

Annexes


3. Comparaison entre les processus de développement

Description Points forts Points faibles Cascade - Propose de dérouler les

phases projet de manière séquentielle - Cité pour des raisons historiques

- Distingue clairement les phases projet

- Non itératif - Ne propose pas de modèles de documents

RUP Rational Unified Process

- Promu par Rational. - Le RUP est à la fois une méthodologie et un outil prêt à l'emploi (documents types partagés dans un référentiel Web) - Cible des projets de plus de 10 personnes

- Itératif - Spécifie le dialogue entre les différents intervenants du projet : les livrables, les plannings, les prototypes… - Propose des modèles de documents, et des canevas pour des projets types

- Coûteux à personnaliser - Très axé processus, au détriment du développement : peu de place pour le code et la technologie

XP eXtreme Programming

- Ensemble de « Best Practices » de développement (travail en équipes, transfert de compétences…) - Cible des projets de moins de 10 personnes

- Itératif - Simple à mettre en œuvre - Fait une large place aux aspects techniques : prototypes, règles de développement, tests…

- Ne couvre pas les phases en amont et en aval au développement : capture des besoins, support, maintenance, tests d'intégration… - Elude la phase d'analyse, si bien qu'on peut dépenser son énergie à faire et défaire - Assez flou dans sa mise en œuvre: quels intervenants, quels livrables ?

2TUP Two Track Unified Process

- Itératif - Fait une large place à la technologie et à la gestion du risque - Définit les profils des intervenants, les livrables, les plannings, les prototypes

- Plutôt superficiel sur les phases situées en amont et en aval du développement : capture des besoins, support, maintenance, gestion du changement… - Ne propose pas de documents types

Tableau A.4 Comparatif entre les processus de développement

Annexes


Annexe D Complément Analyse et conception

4. Le formalisme UML 2.0

UML 2.0 définit 13 diagrammes pour représenter les différents points de vue de la modélisation. Ils permettent de visualiser et de manipuler les éléments de la modélisation.

Les caractéristiques du formalisme UML :

UML permet de mener la phase d’analyse et de conception tout en bénéficiant de la puissance et de la simplicité de ses diagrammes ;

Le processus de développement adopté se base sur des diagrammes ;

La notation UML facilite la compréhension et la communication d’une modélisation objet ;

UML est aujourd’hui un standard, adopté par les grands constructeurs de logiciel du marché.

Je présente dans ce qui suite quelques diagrammes de séquences qu’on élaborer

durant la phase de conception de notre système, plus Le tableau (cf. tableau A.5)

suivant illustre l’ensemble des cas d’utilisation de l’application :

Acteur

Fonction

Directeur du

Pôle

� Consulter le TDB consolidé de tous les projets du pôle :

� Consulter le TDB consolidé de tous les projets par direction : • Visualiser l’état mensuel consolidé des Investissements par direction et par

mode. • Visualiser l’état cumulé consolidé des Investissements par direction et par mode. • Visualiser l’état mensuel consolidé des Encaissements par direction et par mode. • Visualiser l’état cumulé consolidé des Encaissements par direction et par mode. • CA mensuel et consolidé ….

� Générer les différents TDBs produits sous forme d’un tableur Excel.

Annexes


Directeur de

projets

� Consulter le TDB consolidé de tous les projets de la direction : • Visualiser l’état mensuel consolidé des Investissements de la direction et par

mode. • Visualiser l’état cumulé consolidé des Investissements de la direction et par

mode. • Visualiser l’état mensuel consolidé des Encaissements de la direction et par

mode. • Visualiser l’état cumulé consolidé des Encaissements de la direction et par mode.

� Consulter le TDB de la direction par projet: • Visualiser l’état mensuel des Investissements encaissement & CA de la

direction et par mode (MO, MOD, MODCEM, filiailes). • Visualiser l’état cumulé des Investissements encaissement & CA de la direction

et par mode.


� Charger des feuilles de calcul depuis un tableur vers la base de données.

Chef de

projets

� Consulter le TDB de son projet: • Visualiser l’état mensuel des Investissements encaissement & CA de sa

direction et par mode (MO, MODCEM).

- Visualiser l’avancement physique du projet. - Visualiser le réalisé du projet. - Visualiser le facturé du projet. - Visualisé le comptabilisé du projet. - Visualisé le budget du projet. - Visualisé l’actu trimestrielle du projet.

• Visualiser l’état cumulé des Investissements encaissement & CA de sa direction

et par mode (MO, MODCEM).

- Visualiser l’avancement physique du projet. & - Visualiser le réalisé du projet. & - Visualiser le facturé du projet. & - Visualisé le comptabilisé du projet. & - Visualisé le budget du projet. & - Visualisé l’actu trimestrielle du projet. &

• Visualiser l’état mensuel des Investissements encaissement & CA de sa direction en filiales :

- Visualiser l’avancement physique du projet. - Visualiser le réalisé du projet. - Visualiser le facturé du projet. - Visualisé le comptabilisé du projet. - Visualisé le budget du projet. - Visualisé l’actu trimestrielle du projet.

• Visualiser l’état mensuel

� Saisie de l’avancement physique et le réalisé mensuellement du projet en termes d’investissement (foncier, autorisation & taxes, régies).



Annexes


Chargée

d’études

� Consulter Reporting & TDBs: • Visualiser l’état mensuel

� Saisie de l’investissement global du projet.

� Saisie du budget annuel par projet.

� Saisie de l’actu trimestrielle.

� Saisie de l’avancement physique et le réalisé mensuellement du projet en termes de CA et encaissement pour les différents modes de gestion.

� Gestion des projets. • Création. • Suppression. • Fusion. • Eclatement. • ….

� Paramétrage des projets.

� Administration • Administrer utilisateurs. • Administrer profils



� Saisie du facturé: • Renseigner les décomptes signés par le directeur du pôle une fois par mois.

� Saisie du comptabilisé • Renseigner les investissements qui émanent de la comptabilité une fois par moi. • Renseigner les encaissements qui émanent de la comptabilité une fois par moi. • Renseigner les chiffres d’affaires qui émanent de la comptabilité une fois par moi.

Tableau A.5 Cas d'utilisations détaillés du système

Annexes


Les scénarios modélisés par les diagrammes de séquence représentent l’aspect métier de l’application.

� Création de projet :

Figure A.2 Diagramme de séquence « création de projet »

� Saisie de l’avancement physique

Figure A.3 Diagramme de séquence « Saisie l’avancement physique»

Annexes


� Saisie de l’actualisation de budget

Figure A.4 Diagramme de séquence « Saisie l’actualisation du budget»

� Saisie du comptabilisé

Figure A.5 Diagramme de séquence « Saisie du comptabilisé»

Annexes


� Consultation du tableau de bord : Etat cumulé consolidé de la direction :

Figure A.6 Consultation du tableau de bord « Etat cumulé consolidé de la direction »

Annexes


Annexe E Production d’états et de tableaux de bord

La liste de figures des états de restitution à produire est la suivante :

1. Etat mensuel consolidé des Investissements par direction et par mode :

Figure A.7 Etat mensuel consolidé des Investissements par direction et par mode

2. Etat cumulé consolidé des Investissements par direction et par mode

Figure A.8 Etat cumulé consolidé des Investissements par direction et par mode

Annexes


3. Etat mensuel consolidé des Encaissements par (Dir Rabat, Nord, Casa & Sud) par mode :

Figure A.9 Etat mensuel consolidé des Encaissements par (Dir Rabat, Nord, Casa & Sud) par mode

4. Etat cumulé consolidé des Encaissements par (Dir Rabat, Nord, Casa & Sud) par mode

Figure A.10 Etat cumulé consolidé des Encaissements par (Dir Rabat, Nord, Casa & Sud) par mode

Annexes


5. Etat mensuel consolidé du CA par (Dir Rabat, Nord, Casa & Sud) par mode

Figure A.11 Etat mensuel consolidé du CA par (Dir Rabat, Nord, Casa & Sud) par mode

6. Etat cumulé consolidé du CA par (Dir Rabat, Nord, Casa & Sud) par mode

Annexes


7. Etat cumulé des Investissements encaissements & CA par projet en MO et MODCEM par direction

Figure A.12 Etat cumulé des Investissements encaissements & CA par projet en MO et MODCEM par direction

8. Etat mensuel annuel des Investissements encaissements & CA projet en MOD par direction

Figure A.13 Etat mensuel annuel des Investissements encaissements & CA projet en MOD par direction

Annexes


9. Etat cumulé des Investissements encaissements & CA projet en MOD par direction

Figure A.14 Etat cumulé des Investissements encaissements & CA projet en MOD par direction

Annexes


Figure A.15 Etat cumulé des Investissements encaissements & CA projet en MOD par direction

Annexes


10. Production d’états sous format graphique :

Un exemple de graphique que le système produira dans le but de donner un rendu visuel plus parlant pour les décideurs au sein du Pôle Tertiaire.

Figure A.16 Représentation des indicateurs sous forme Graphique

rapport final

Documents