Soutenance du projet de fin d'études 2009 au sein de la BCP par Yassine EL AZRI

06/07/2009
Etude et développement d'un système d'édition automatisée de contrats d'assurance
1
Office de la Formation Professionnelleet de la Promotion du TravailInstitut Spécialisé de Technologie AppliquéeISTA NTIC II Sidi Maârouf
Groupe Banques PopulairesBanque Centrale PopulairePôle des Systèmes d’InformationCentre National de Recherche & Développement
Etude et développement d’un système d’éditionautomatisée de contrats d’assurance
Réalisé par Yassine EL AZRI
Encadré par:
Encadrant au sein du CNRD :
Mr Zakaria RIFAÏ
Enseignants tuteurs :
Mr Omar EL BEGGAR (suivi)
Melle Naïma ALAMI (évaluation)

Office de la Formation Professionnelleet de la Promotion du TravailInstitut Spécialisé de Technologie AppliquéeISTA NTIC II Sidi Maârouf
Groupe Banques PopulairesBanque Centrale PopulairePôle des Systèmes d’InformationCentre National de Recherche & Développement
Etude et développement d’un système d’éditionautomatisée de contrats d’assurance
Réalisé par Yassine EL AZRI
Encadré par:
Encadrant au sein du CNRD :
Mr Zakaria RIFAÏ
Enseignants tuteurs :
Mr Omar EL BEGGAR (suivi)
Melle Naïma ALAMI (évaluation)

Remerciements
Les membres du jury
Melle Mounia Naamany
Melle Naïma Alami
Les formateurs à NTIC II
Les collaborateurs au sein du CNRD
Les amis
La famille
06/07/2009
3

Plan de la présentation
06/07/2009
4
Ordre du jour

Ordre du jour
Introduction
Contexte du stage
Informatisation du métier
Analyse et conception
Architectures du projet
Etudes techniques
Perspectives et évolutions
Conclusion
06/07/2009
5

06/07/2009
6
Introduction

Introduction
Motivation du stage
Objectif de la prestation
Cas de B2B
Solution répartie entre 2 architectures
Dimension Open-Source du projet
06/07/2009
7

Présentation de l’entité d’accueilet son organisme de tutelle
06/07/2009
8
Contexte du stage

GBP : Groupe Banques POPULAIRES
Groupement bancaire : BCP + BPR
Historique:
1921: introduction du modèle organisationnel et commercial des banques mutualisées.
Années 20: Création de plusieurs banques populaires se basant sur ce modèle dans les principales villes du Royaume.
1961: Création du CPM par dahir.
1969: Le CPM devient le 1er réseau bancaire du Maroc avec 43 agences.
1972: Mise en place d’un système informatique pour améliorer les traitements et sécuriser les opérations de la banque.
1974: Le Groupe devient leader du secteur bancaire national en matière de dépôts, avec 1 milliard de DHs de ressources.
2004: Introduction en Bourse de la Banque Centrale Populaire.
06/07/2009
9

Orientations stratégiques:
Consolidation des positions acquises
Banque citoyenne de proximité
Amélioration des performances
Elargissement du créneau et croissance externe
06/07/2009
10

Modèle de gouvernance:
06/07/2009
11

BCP : Banque centrale populaire
06/07/2009
12

BCP : Banque centrale populaire
Organigramme
06/07/2009
13

PSI : Pôle systèmes d’information
Plus de 300 collaborateurs dont 250 ingénieurs
Gère l’ensemble du SI du GBP
Missions:
Elaborer et mettre en œuvre le SI du Groupe et des systèmes informatiques, de télécommunications et monétique dont ils se composent
Préserver le patrimoine informatique tangible et intangible du Groupe
06/07/2009
14

PSI : Pôle systemes d’information
Organes:
06/07/2009
15

PSI : Pôle systemes d’information
Organigramme:
06/07/2009
16

CNRD : Centre national R&D
06/07/2009
17

CNRD : Centre national R&D
Fondé en 2009
Abrite la DED du PSI
La DED a pour domaines de responsabilité :
La maitrise d'œuvre des projets informatiques.
L'acquisition ou développement de solutions informatiques.
La maintenance et la documentation des applications en exploitation.
06/07/2009
18

Problématique métier et besoins fonctionnels
06/07/2009
19
Informatisation du métier

PROJET GLOBAL
Fiche Signalétique:
Projet initié en novembre 2008
MOA: Pôle Bancassurances (BCP)
MOE: Division Etudes et Développement (PSI)
Objectif:
amélioration et automatisation des procédures de traitement des prestations relatives aux offres d’assurance :
AddamaneChaabi
MoustakbalChaabi
InjadChaabi
06/07/2009
20

Projet global
Présentation deCNIA Assurance
Présentation du produit AddamaneChaabi
Epargne de retraite
Souscription
Règlement
Liquidation (rente ou capital)
Rachats (totals ou partiels)
06/07/2009
21

Etude de l’existant
Processus de gestion des demandes de prestations de rachats/liquidations AddamaneChaabi:
Etapes:
Responsabilités:
06/07/2009
22

Circuit de validation des demandes de rachats/liquidations AddamaneChaabi et de leurs quittances d’indemnité (1/2):
06/07/2009
23

Circuit de validation des demandes de rachats/liquidations AddamaneChaabi et de leurs quittances d’indemnité (2/2):
06/07/2009
24

Critique de l’existant
Lenteur des procédures
Transmission par voie traditionnelle
Risque éventuel d’erreurs ou d’incohérences
Intégrations des informations en deux temps (au niveau du SI BCP et au du SI CNIA)
06/07/2009
25

Objectif de la prestation
Dématérialisation des demandes de prestations (sous format numérique)
Automatisation de la transmission entre la BCP et la CNIA (par voie numérique)
L’ édition de la quittance au niveau de l’agence BP
06/07/2009
26

Buts escomptés
Satisfaction de la clientèle à travers le raccourcissement des délais
Affranchir les agences BP des tâches administratives de routines
Fiabilisation et sécurisation du processus de traitement et de transmission
06/07/2009
27

Valeur ajoutée du projet
Gain du temps à travers le raccourcissement des délais
Réduction des coûts et affranchissement vis-à-vis de la lourdeur du support papier
Fidélisation de la clientèle à travers la promotion d’une image de marque et de qualité
06/07/2009
28

étendue et périmètre
Concerne la gestions front-office des prestations de rachats/liquidations spécifiques au produit AddamaneChaabi
Met en exergue les SI respectifs de la BCP et de la CNIA
L’édition et les demandes de prestations se fera au niveau des guichets BP et sont réalisés par les agents chargés du client.
La souscription et les avenants modificatifs ne peuvent être réalisés que par des agents estampillés « Administrateur AddamaneChaabi »
La fonction propriétaire de la l’application est la Division de la Production Bancaire (DPB).
06/07/2009
29

Transposition de la problématique métier en un modèle informatique
06/07/2009
30
Analyse et conception

Modèle de développement en V
06/07/2009
31

Modèle de développement en V
Souple et facile à mettre en œuvre
Imaginé suite au problème de réactivité du modèle en cascade
permet, en cas d'anomalie, de limiter un retour aux étapes précédentes
Chaque phase de la branche de droite introduit à la fois la phase suivante, et la phase de validation correspondante de la branche de gauche
06/07/2009
32

UML: UnifiedModelinglanguage
UML: langage graphiquesemi-formel de modélisation des données,des traitements et des processus métier.
Fusion des anciens langages de modélisation objet
N’implique pas l’usage d’une méthode de développement particulière
Version 2.0 publiée par l’OMG en 2006
06/07/2009
33

UML: AXES de modélisation
06/07/2009
34

UML: AXES de modélisations
06/07/2009
35

Nouvelle norme : UML 2.0
Diagrammes structurels ou statiques
Diagramme de classes
Diagramme d'objets
Diagramme de composants
Diagramme de déploiement
Diagramme des paquetages
Diagramme de structure composite (*)
Diagrammes comportementaux
Diagramme des cas d'utilisation
Diagramme états-transitions
Diagramme d'activité
Diagrammes d'interaction ou dynamiques
Diagramme de séquence
Diagramme de communication (*)
Diagramme global d'interaction (*)
Diagramme de temps (*)
06/07/2009
36

UML: quelle demarche?
06/07/2009
37

Méthodologie Mi-chemin UP/XP
Compromis entre:
Processus Unifié (UP)
eXtremeProgramming (XP)
Caractéristiques du processus UP/XP:
piloté par les cas d’utilisation (comme UP) mais beaucoup plus simple
relativement léger et restreint (comme XP) mais sans négliger les activités de modélisation en analyse et conception
utilisation d’un sous-ensemble nécessaire et suffisant du langage UML.
06/07/2009
38

Méthodologie Mi-chemin UP/XP
06/07/2009
39

Contexte statique
06/07/2009
40

Services offerts
06/07/2009
41

Interaction avec l’utilisateur
Authentification:
06/07/2009
42

Authentification
06/07/2009
43

Souscription (1/2)
06/07/2009
44

Souscription (2/2)
06/07/2009
45

Demande de prestation (1/2)
06/07/2009
46

Demande de prestation (2/2)
06/07/2009
47

Demande de prestation
06/07/2009
48

Analyse du domaine
06/07/2009
49

Référentiel de stockage
06/07/2009
50

Environnement cible et architecture spécifique
06/07/2009
51
Architectures du projet

Environnement cible
06/07/2009
52

Environnement cible
Scindé en 2 architectures:
Partie Back-Office:
Système CICS
Mainframe IBM zSeries sous Z/Os (MVS)
Partie Front-Office:
Application Web multi-tiers multi-couches
Architecture JEE 5
Serveur applicatif W.A.S
06/07/2009
53

MAINFRAME
Ordinateur central relié à des terminaux
Traitement entièrement centralisé
Avantages:
Sécurité
Fiabilité
Haute disponibilité
Coûts d’exploitation réduits
06/07/2009
54

Système Z/OS
Système Z/OS:
Système 64 bits pour les zSeries (mainframes IBM)
Fusion de MVS et Unix
Au sein du GBP:
Version courante Z/OS 9.0
les terminaux Z/Os sont virtualisés
Système C.I.C.S:
permet d'effectuer des opérations transactionnelles(CRUD) avec une très grande économie de moyens.
06/07/2009
55

Java 2 EnteRpriseedition
06/07/2009
56

API Java EE 5
06/07/2009
57

Architecture multi-tiers
06/07/2009
58

Couche Métier
Architectures multi-couches
06/07/2009
59
Couche Présentation
Couche Contrôle
Couche Service
Couche Domaine
Couche DAO

Pattern MVC
l’utilisateur manipule l’interface homme/machine. Un événement est envoyé. Cet événement est récupéré par le contrôleur.
le contrôleur effectue l’action demandée par l’utilisateur en appelant les méthodes nécessaires sur le modèle.
le contrôleur informe la vue d’un changement d’état du modèle.
la vue interroge le modèle afin de connaître son état.
l’utilisateur voit le résultat de son action.
06/07/2009
60

PATTERN MVC
Avantages:
le modèle étant séparé des autres composants, il est développé indépendamment.
le modèle n’est pas lié à une interface, il peut donc être réutilisé.
diminution de la duplication du code.
centralisation du contrôle.
augmentation de la maintenabilité et de l’évolutivité du code.
06/07/2009
61

MVC 2 = MVC++
Principe: 1 Contrôleur frontal + plusieurs contrôleurs délégués
06/07/2009
62

Outils et technologies utilisés
06/07/2009
63
Etudes techniques

Technologies utilisées
Une ébauche des technologies utilisées…
06/07/2009
64

Référentiel de stockage
Base de production:
Datawarehouse sous IBM DB2
Référentiel du SI de la BCP
Base de développement:
Base de données relationnelle sous MySQL5/InnoDB
Shémas réduit spécifique aux prestations AddamaneChaabi
Motivation du choix du SGBD de développement:
Système HSQL très rapide d’accès
Moteur InnoDB: transactions, contrainte d’intégrité, concurrence
06/07/2009
65

Mapping objet/realitionnel
Prolonger la durée de vie des objets au-delà d’une session applicative
Réduction du temps de développement du code d’accès au données
Accès aux données de manière orientée objet (persistance transparente)
Plusieurs frameworks: JDO/JPA, Hibernate, TopLink, iBatis,…
06/07/2009
66

Framework hibernate
Framework ORM Open-Source
Standard « de fait »
Adaptable en terme d’architecture
Mappage des classe et des associations dans des fichiers XML
06/07/2009
67

Architecture hibernate
06/07/2009
68

Hibernate : best practice
Cacher l’implémentation de Hibernate
Classes DAO
SessionManager
TransactionManager
06/07/2009
69

Java server faces
Framework MVC2 orienté composants
Etat des composants conservé entredeux rêquetes
Standard dans la plateforme JEE 5(JSR 2522)
Plusieurs implémentations: Sun RI, VWF, Oracle ADF, Apache MyFaces, JbossRichFaces, IceFaces…
Surcouche d’autres technologies:
06/07/2009
70

FRAMEWORK JSF
Un ensemble d'APIs pour la représentation et la gestion des composants, de leur état, des évènements, de la validation des entrées et la conversion des sorties, l'internationalisation et l'accessibilité ainsi que la navigation inter-vues
2 jeux de composants standards : html et core
2 bibliothèques de balises JSP (une pour chaque jeu de composants) pour permettre l'utilisation des pages JSP pour la construction de vues JSF
Un modèle évènementiel côté serveur
Les Managed-Beans : qui forment la couche contrôle de JSF
Unified Expression Language (abrégé en EL) ou langage d'expressions unifié pour JSF et JSP 2.0. Il permet de lier les composants aux managed-beans
06/07/2009
71

Java server faces
Cycle de traitement d’un requête JSF:
06/07/2009
72

JSF : best practice
06/07/2009
73

EDITION de documents électroniques
Omniprésent dans le processus métier
Plusieurs solutions:
LateX
Outils de Reporting
Processeurs XSL-FO
Outils spécialisés
06/07/2009
74

FRAMEWORK FOP
FOP: Formatting Object Processor
Processeur XSL-FO Open Souce (Fondation Apache) écrit en Java
Séparation entre:
modèle (données brutes),
contrôleur (règles de formatage)
la vue (rendu affiché ou imprimé)
Peut être utilisé:
Comme application standalone
Comme API à intégrer à un projet Java
06/07/2009
75

Framework FOP
Processus de génération simple d’un document électronique via FOP:
06/07/2009
76
Document XSLT(feuille de transformation)
FOP

Architecture détaillée
Serveur applicatif JEE 5avec conteneur web
Hibernate.cfg.xml(fichier de configuration)
Requêtes HTTP
javabean
Web.xml (descripteurde déploiement)
Faces Servlet(JSF front-controller)
POJO
(objets persistants)
Client WEB léger
API JDBC 3.0
Valeurs des champs
Faces-config.xml(fichier de config JSF)
Hibernate 3.0
Couche DAO (Data Access Objects)
Document PDF
Pages WEB (*.jsf, *.jsfx, *.jsp, *.jspf)
MaClasse.hbm.xml(fichier de mapping)
Table
Control manager bean(delegatecontroller)
Backingbean
Arbre composants JSF
Model managedbean
77

Arborescence du projet
06/07/2009
78

Interfaces Homme-Machine
06/07/2009
79
Captures d’écran

CAPTURES…
06/07/2009
80

CAPTURES…
06/07/2009
81

CAPTURES…
06/07/2009
82

CAPTURES…
06/07/2009
83

CAPTURES…
06/07/2009
84

CAPTURES…
06/07/2009
85

CAPTURES…
06/07/2009
86

CAPTURES…
06/07/2009
87

CAPTURES…
06/07/2009
88

CAPTURES…
06/07/2009
89

CAPTURES…
06/07/2009
90

CAPTURES…
06/07/2009
91

Evolutions éventuelles en vue
06/07/2009
92
Perspectives

Factorisation des validations coté client et côté serveur via Struts Shale Common Validators
Mise en œuvre des technologies RIA (Web 2.0) pour le tiers présentatif
Traitement en temps réél
Transmission des lots de demandes via des trames XML
Intégration à CH@ABI-NET, l’extranet du GBP
06/07/2009
93

Intégration à CH@ABI-NET, l’extranet du GBP
06/07/2009
94

06/07/2009
95
CONLUSION

06/07/2009
96
Des questions ?