Projet de Conception N 1 Automatisation d'un processus de paiement. Livrable: Dossier d'initialisation

Transcription

1 Projet de Conception N 1 Automatisation d'un processus de paiement Livrable: Dossier d'initialisation Enseignants : Y.AMGHAR, L.BRUNIE Equipe projet : R.Jeatsa Kengni, X.Lucas, L.Martin, C.Molea (CdP)

2 Avant Propos Ce document a pour but de définir le cadre du déroulement du projet de conception 5IF appellé «Automatisation d'un processus de paiement». PC1 Automatisation d'un processus de paiement 2/19

3 Suivi du livrable Responsable du livrable : Cosmin MOLEA Validation du livrable le : 14/10/2009 Date Version Auteur Modifications 2/10/ Cosmin MOLEA Création du document et définition de sa structure 5/10/ Cosmin MOLEA Edition : Définition des charges et du planning 9/10/ Cosmin MOLEA Edition : Organisation de l'équipe et identification des risques 10/10/ Cosmin MOLEA Edition : Modalités de validation et de recette 11/10/ Cosmin MOLEA Vérification et mise en forme 15/10/ Cosmin MOLEA Corrections par rapport à la revue PC1 Automatisation d'un processus de paiement 3/19

4 Table des matières 1. Objet du projet - Contexte L'objet du projet Le contexte général du projet Vocabulaire Méthodes Modes opératoires Phasage Identification de la méthode utilisée Phasage du projet Livrables attendus Identification des activités et tâches Liste des activités Plan de charges Planning prévisionnel Organisation de l'équipe Définition des rôles Répartition des charges Identification des risques Accumulation du retard Mauvaise compréhension des besoins Perte de documents Modalités de validation et de recette Annexes Plans-types des documents à livrer Dossier d'initialisation (D-I) Dossier d'expression des besoins (D-EB) Dossier d'architecture applicative (D-AA) Dossier de spécification du système de compensation (D-SC) Dossier d'architecture technique (D-AT) Dossier business plan (D-BP) Dossier de bilan (D-B) Modèles de documents de suivi Fiche de revue Fiche de suivi individuelle par phase...19 PC1 Automatisation d'un processus de paiement 4/19

5 1. Objet du projet - Contexte 1.1. L'objet du projet L'entreprise AVENTIX se propose de concurrencer SODEXHO en initialisant un projet qui vise à remplacer les chèques restaurant par une carte à puce. Ainsi, le paiement auprès des commerçants, dans le cadre de différentes actions de consommation ne fera plus appel au traitement papier des chèques, mais laissera placa à un traitement informatique plus performant. Ce projet a comme objectif de réaliser une spécification d'un tel système de paiement. Son positionnement dans le cycle de vie d'un produit informatique le situe dans le cadre de l'étude préliminaire et l'étude détaillée. Parmi les résulatats que la maîtrise d'oeuvre devra proposer au client se trouvent la definition des processus sur le plan métier et organisationnel, un plan d'urbnisation, une proposition d'architecture applicative, une proposition d'architecture technique, une stratégie de déploiement, un business plan Le contexte général du projet Au jour d'aujourd'hui, la chaîne de traitement des chèques restaurant fait intervenir cinq acteurs: une société qui émet les chèques restaurant, l'employeur qui achète les chèques pour les céder aux employés en prenant à sa charge une partie de valeur indiquée, l'employé qui utilise le chèque et enfin le commerçant affilié auprès d'une centrale de règlement des titres (CRT). Le traitement des chèques restaurant est semiautomatique car il nécessite l'envoi des chèques par les commerçants à la centrale de règlement des titres. A ce niveau, les chèques sont traités de façon informatique afin de permettre aux commerçants d'être crédités. Dans la figure ci-dessous on observe le fonctionnement existant avec SODEXHO: PC1 Automatisation d'un processus de paiement 5/19

6 Pour supprimer la partie manuelle dans la chaîne de traitement des chèques restaurant au profit d'un traitement entièrement automarique, on souhaite remplacer le chèque par une carte à puce sans que cela modifie, sur le plan de l'organisation, les procédures d'acquisition et de traitement déjà utilisées. On nommera ce nouveau mode : carte restaurant. Ainsi, on envisage une simplification des protocoles d'acquisition et d'utilisation. Les employeurs reçoivent un nombre de cartes correspondant au nombre d'employés auxquels elles sont destinées. Il communiquent la valeur de la participation et le numéro d'employeur. L'employé se présente chez un commerçant (muni d'un lecteur de cartes à puce) et remet sa carte pour payer. Les informations nécessaires sont envoyées par le lecteur au centre de compensation à travers un réseau de transfert d'informations numériques. Le centre de compensation effectuera des opérations spécifiques afin de permettre aux commerçants d'être crédités. Dans la figure ci-dessous on observe le fonctionnement souhaité avec AVENTIX: 1.3. Vocabulaire CRT = Centrale de Règlement des Titres EDI = Echange de Données Informatiques CaP = Carte à Puce ROI = Return On Investment SI = Système d'information USDP = Unified Software Development Process UML = Unified Modelling Language PC1 Automatisation d'un processus de paiement 6/19

7 2. Méthodes Modes opératoires Phasage 2.1. Identification de la méthode utilisée Ce projet se propose d'étudier la faisabilité d'un système de paiement par carte et d'en réaliser une spécification détaillée. Nous avons choisi d'utiliser la méthode USDP («Unified Software Development Process») pour réaliser l'élaboration de la solution informatique du système. Selon les principes de cette méthode, le cycle de vie d'un produit est constitué de cycles de développement qui se déroulent de la même façon. Le premier cycle de développement correspond à la création du produit, et les cycles suivants correspondent à des évolutions. Un cycle de développement est constitué de phases. L'étude préliminaire définit la portée du produit, réduit les risques, établit que le projet est viable. L'élaboration définit l'architecture, les coûts, et planifie la fin du projet. La construction fabrique le produit fini, et la transition diffuse le produit. Ces quatre phases se déroulent successivement dans le temps. Chacune comporte à des degrés divers les activités classiques du cycle de développement: capture des besoins, analyse, conception, réalisation, tests. Cette méthodologie est bien adaptée à nos besoins, car notre projet s'inscrit dans les phases «Etude préliminaire» et «Elaboration». Une particularité de notre démarche est qu'en parallèle avec ces deux phases, on mènera aussi une phase «Etude» (comprenanant les études sur l'edi et sur les lecteurs de cartes à puce), phase transversale aux deux premières. Il faut préciser que le formalisme que nous avons décidé d'utiliser pendant ce projet est l'uml («Unified Modelling Language»). En s'appuyant sur ce formalisme, on représentera par exemple les différents cas d'utilisation du système, ou bien des diagrammes d'activité ou de séquence significatifs. PC1 Automatisation d'un processus de paiement 7/19

8 2.2. Phasage du projet PC1 Automatisation d'un processus de paiement 8/19

9 3. Livrables attendus Code Nom du livrable Date de remise Séance D-I Dossier d initialisation 14/10/ D-EB Dossier d expression des besoins 14/10/ D-AA Dossier d architecture applicative 21/10/ D-SC Dossier de spécification du système de compensation 4/11/ D-AT Dossier d architecture technique 4/11/ D-BP Dossier business plan 18/11/2009 * D-B Dossier de bilan 18/11/2009 * * Les derniers livrables sont à remettre au maximum 2 semaines après la dernière seance Note : les plans-type des documents à livrer se trouvent dans l'annexe Identification des activités et tâches 4.1. Liste des activités Chaque opération réalisée au cours du projet peut être inscrite dans une des activités suivantes (dont on énumère les principales caractéristiques): Gestion de projet Planification du travail, suivi du projet, coordination de l'équipe, communication avec le client. Assurance qualité Vérification de la qulité des documents produits et du respect des méthodes de travail. Production Rédaction des livrables (spécification, conception, élaboration du business plan). Etude Recherche bibliographique, synthèse, proposition de solutions. PC1 Automatisation d'un processus de paiement 9/19

10 4.2. Plan de charges Le plan de charges est un outil qui sert à : estimer, en début du projet, le volume de travail nécessaire (la charge) pour réaliser chacune des tâches suivre, tout au long du projet, la réalisation des tâches et le positionnement vis-à-vis des prévisions initiales Les quatre dernières colonnes du tableau suivant représentent la repartition des charges prévisionnelles (PV1) aux membres de l'équipe: C = Cosmin, L = Loïc, R = Ronald, X = Xavier (voir la section 5 pour plus de détails sur le rôle de chacun des membres de l'équipe) Les valeurs sont exprimées en heures PV1 Prévisions connues à ce jour REA Réalisé à ce jour RAF Reste à faire à ce jour PV2 Prévisions actualisées = REA + RAF DLT Ecart sur prévisions = PV2 - PV1 Phase Sous-phase/Tâche PV1 REA RAF PV2 DLT C L R X P1 Initialisation Evaluation des charges Etablissement du planning prévisionnel Rédaction du dossier d'initialisation P2 Expression des besoins Définition des règles de gestion 3 3 Définition des acteurs 1 1 Définition du modèle de données 2 2 Cas d'utilisation - Gestion des commandes 6 6 Cas d'utilisation - Gestion des transactions Cas d'utilisation - Gestion B2B + B2C 6 6 Exigences non-fonctionnelles 2 2 P3 Etudes P3.1 - Elaboration de l'architecture applicative Définition du plan d'urbanisation du SI 2 2 Elaboration du schéma d'ensemble de l'architecture 2 2 Description des applications Le portail web PC1 Automatisation d'un processus de paiement 10/19

11 P3.2 Etudes spécifiques Etude sur l'edi 8 8 Etudes des cartes à puce (CaP) P.3.3 Spécification du syst. de compensation Etude sur les formats d'échange et les protocoles 8 8 Evaluation des progiciels existants intégrant EDI 4 4 P3.4 - Elaboration de l'architecture technique Définition des architectures technique et logique 9 9 Définition de l'architecture réseau 4 4 Evaluation du matériel informatique nécessaire 6 6 P4 Elaboration du business plan Définition de la stratégie de marketing 5 5 Définition de la stratégie opérationnelle 6 6 Evaluation des côuts et des ROI 6 6 Evaluation des risques 3 3 P5 Bilan Préparation de la présentation Rédaction du dossier de bilan 6 6 TOTAL Il faut préciser que outre ces charges liées aux tâches, on doit prévoir du temps supplémentaire pour l'ensemble de l'équipe afin de réaliser les actions suivantes: participer aux réunions de pilotage du projet (3h/phase) remplir les documents de suivi (1h/phase) faire valider les livrables (1h/livrable) PC1 Automatisation d'un processus de paiement 11/19

12 4.3. Planning prévisionnel Le planning ci-dessous a été réalisé à l'aide de l'outil MS Project. Il contient l'ensemble des tâches à réaliser afin de mener à bout le projet, regroupées en phases et sous-phases. PC1 Automatisation d'un processus de paiement 12/19

13 5. Organisation de l'équipe 5.1. Définition des rôles Chef de projet : Cosmin MOLEA Chargé de gérer l'équipe, faire le suivi du projet, assurer la communication au sein de l'équipe et avec le client, participer à la réalisation du projet. Responsable qualité : Xavier LUCAS Chargé de définir les documents-type et d'assurer la conformité des livrables avec ceux-ci, mettre en place la procédure qualié, optimiser les méthodes de travail, participer à la réalisation du projet. Equipe de conception : Loïc MARTIN, Ronald JEATSA KENGNI Chargés de participer à la réalisation du projet. Afin de faciliter le travail en équipe, nous avons mis en place un référentiel SVN pour héberger nos fichers communs ( Répartition des charges Nous avons détaillé ci-dessous les histogrammes de charge par personne. Ces histogrammes ont été réalisées toujours avec MS Project en déclinant le planning prévisionnel établi (voir aussi 4.3): PC1 Automatisation d'un processus de paiement 13/19

14 PC1 Automatisation d'un processus de paiement 14/19

15 6. Identification des risques 6.1. Accumulation du retard Gravité : très importante Plan d'action : remise en question du planning (réévaluation éventuelle des charges) et amélioration de la communication au sein de l'équipe Mauvaise compréhension des besoins Gravité : très importante Plan d'action : organiser plus souvent des réunions en interne (pour faire le point sur l'avancement du projet) et aussi des réunions avec le client afin de mieux comprendre ses exigences Perte de documents Gravité : importante Plan d'action: sauvegarde régulière des documents lors de leur rédaction; en plus, il faut «commiter» un document sur le répositoire SVN après chaque modification importante. PC1 Automatisation d'un processus de paiement 15/19

16 7. Modalités de validation et de recette La procédure de validation et de recette est présentée dans le schéma ci-dessous: La remise des documents au client (dans notre cas à l'enseignant) se fera via la plateforme pédagogique Moodle ( Le chemin d'accès vers l'espace dédié à ce projet est le suivant: Moodle second cycle -> IF Informatique -> 5IF -> Projets -> 5IF-PDC-APE PC1 Automatisation d'un processus de paiement 16/19

17 8. Annexes 8.1. Plans-types des documents à livrer Dossier d'initialisation (D-I) - Objet du projet - Contexte - Méthodes Modes opératoires Phasage - Livrables attendus - Identification des activités et tâches - Liste des activités - Plan de charges - Planning prévisionnel - Organisation de l'équipe - Identification des risques - Modalités de validation et de recette - Annexes - Plans-types des documents à livrer - Modèles de documents de suivi Dossier d'expression des besoins (D-EB) - Objet du projet - Contexte - Règles de gestion - Exigences fonctionnelles - Définition des acteurs - Modèle de données - Cas d'utilisation - Gestion des commandes - Gestion des transactions - Gestion B2B - Exigences non-fonctionnelles Dossier d'architecture applicative (D-AA) - Objet du projet - Contexte - Plan d'urbanisation du SI - L'architecture applicative - Schéma d'ensemble - Description des applications - Le portail web - Annexes - Etude sur l'edi Dossier de spécification du système de compensation (D-SC) - Objet du projet - Contexte - Caractéristiques d'un EDI PC1 Automatisation d'un processus de paiement 17/19

18 - Les formats d'échange EDI - Protocoles de communication utilisés - Progiciels existants intégrant EDI Dossier d'architecture technique (D-AT) - Objet du projet - Contexte - Architecture technique - Architecture logique - Architecture réseau - Matériel informatique - Annexes - Etudes des cartes à puce (CaP) Dossier business plan (D-BP) - Objet du projet Contexte - Services offerts par AVENTIX - Stratégie de marketing - Stratégie opérationnelle - Evaluation des côuts - Evaluation des retours sur investissement - Evaluation des risques Dossier de bilan (D-B) - Objet du projet Contexte - Bilan global du projet - Bilan des charges - Bilans individuels PC1 Automatisation d'un processus de paiement 18/19

19 8.2. Modèles de documents de suivi Fiche de revue PC1 Automatisation d'un processus de paiement Revue n : Date : Heure : Liste des présents : N Point abordé Commentaires Conclusion : Fiche de suivi individuelle par phase Nom : Exemple Prénom Date Tâche Phase n... PC1 Automatisation d'un processus de paiement Temps prévu Temps réel 12/10/2009 Tâche A 3h 4h 40 13/10/2009 Tâche B 1h 1h /10/2009 Tâche A 2h 2h 100 % Note 1: Chaque membre de l'équipe doit remplir régulièrement sa fiche de suivi individuelle (une par phase). Le remplissage régulier de ces fiches individuelles est très important parce qu'elles permettent au CdP de suivre en «temps réel» l'évolution du projet (voir section 4.2 Plan de charges). Note 2: Le champ «%» signifie l'état d'avancement de la tâche. Note 3: Ces fiches se trouvent sur le répositoire SVN, dans le dossier suivant: «Gestion de projet->suivi->suivi individuel». PC1 Automatisation d'un processus de paiement 19/19