La méthodologie de conduite d’un projet systèmes d’information

La phase de conception

Cette phase consiste à étudier la faisabilité du projet afin d’identifier les éventuelles incohérences qui peuvent entraver l’avancement du projet. Cette phase permet donc de réduire les risques dans la phase de développement de la solution en s’appuyant sur une analyse fonctionnelle.
Cette analyse fonctionnelle repose sur les techniques de modélisation permettant l’analyse et la conception de l’information contenue dans le système. Il en découlera donc la description des éventuelles bases de données à créer, les programmes et la méthode d’intégration de l’ensemble de ces éléments.

La phase de réalisation

La phase de réalisation correspond au développement de la solution. Cette activité nécessite un travail préalable d’organisation les équipes de développement, d’ordonnancement des tâches du projet, d’estimation des charges des équipes et à la détermination des profils correspondants à la réalisation de cette phase.
La conduite du projet repose sur un découpage chronologique en précisant les tâches, les ressources, les livrables et le déroulement de l’étape de validation. Il s’agit de WBS (Work Breakdown Structure) qui correspond à la structure hiérarchique des tâches du projet en partant de la liste des résultats ou des livrables attendus par le projet. Il s’agit de dresser l’inventaire des activités nécessaires à la réalisation pour chacun de ces livrables.
L’ordonnancement des tâches quant à lui, passe par la mise en place d’un plan d’actions permettant d’identifier les séquences ou les parallélismes possibles entre des tâches précédemment
identifiées. Cette activité nécessite l’utilisation des techniques de planification à savoir :
▪ Le diagramme de GANTT : il s’agit d’un diagramme qui permet de modéliser la planification de tâches nécessaires à la réalisation d’un projet.
▪ La méthode PERT (Project Evaluation and Review Technique) : il s’agit d’une méthode qui permet de de gérer l’ordonnancement dans un projet en représentant sous forme de graphe un réseau de tâches. L’enchaînement de ces tâches permet d’aboutir à l’atteinte des objectifs d’un projet.

La phase de la recette et de la réception

La phase de la recette, appelée également “essais de réception”, repose sur la vérification de la conformité de la solution développée en regard du besoin exprimé. Selon les réponses apportées au guide d’entretien mené avec le chef de projet MOA, aucune négligence n’est tolérée dans la phase de la recette. Cette dernière doit être menée rigoureusement vu sa grande importance dans le bon déroulement du projet.
Pour mener la phase de recette, la MOA procède à l’élaboration d’un cahier de recette qui inclut tous les tests à effectuer (s’assurer de ce qui doit fonctionner et de ce qui ne doit pas fonctionner ; et, pour chaque cas, les résultats attendus vs les résultats obtenus ; l’adéquation des deux permet de valider la recette). Il faudra noter qu’il est déconseillé de mettre des contrôles bloquants partout car cela risque de rendre l’application ingérable. Il faudra être le plus exhaustif possible tout en pensant à faire des recettes par sondage en prenant des cas génériques qui peuvent couvrir la majorité du périmètre.
La MOA teste principalement les cas généraux alors que le métier peut vouloir tester, en complément, des « cas exceptionnels », rencontrés dans la réalisation de leurs fonctions. Cela n’empêchera pas, une fois la mise en production réalisée, de rencontrer « encore » des cas non recettés.
Pendant cette phase, il faudra garder une trace de toutes les recettes menées (fiche de preuves comportant les captures d’écran des messages d’erreurs par exemple) pour faire un suivi correct et lister les éléments à corriger par la MOE afin de couvrir la totalité des éléments nécessaires pour la livraison.

Bonnes pratiques

La phase de la recette devra être menée comme étant un sous-projet avec des tâches bien identifiées et affectées à des ressources en mettant en place une planification rigoureuse et en maintenant un suivi de l’avancement.
Plusieurs outils peuvent être utilisés pour assurer le bon déroulement de cette phase de recette, nous citons à titre d’exemple l’outil JIRA utilisé pour établir le suivi des tickets d’anomalies ou d’évolution. Le seul inconvénient de cet outil est que ces anomalies ne sont pas forcément intégrées dans le document des spécifications.
En méthode agile, les anomalies sont remontées directement aux personnes concernées lors des échanges quotidiens entre les différents acteurs. Il faudra noter qu’il est très important de maintenir à jour le document des spécifications et ne jamais bâcler la phase de recette même si cela peut engendrer un retard sur le projet. Il est très important de faire un maximum de tests possibles afin de pouvoir répondre aux différentes questions des métiers.

La livraison

La phase de livraison correspond à la mise à disposition de la solution au profit des utilisateurs finaux à travers la mise en place de sites pilotes qui permettent de tester la solution et identifier les éventuels dysfonctionnements afin de les corriger. Cette phase de livraison passe également par un déploiement généralisé de la solution auprès des utilisateurs finaux et par conséquent la mise en place d’une conduite de changement.
Le volet de conduite de changement joue un rôle fondamental dans l’appropriation du projet par les acteurs concernés. L’ensemble des actions à entreprendre permettent d’accompagner les populations concernées par la solution dans l’évolution de leur métier et le changement de leurs habitudes. Cette conduite de changement s’appuie sur des leviers d’actions comme la formation, la communication, la documentation, le transfert de compétences etc. Faisant partie de l’équipe des consultants travaillant sur une mission d’étude du modèle de coûts au sein d’un établissement public, le volet conduite de changement a été primordial dans la réussite de la mise en œuvre du modèle de coûts proposé.
Ceci a nécessité des actions de conduite du changement pendant toute la durée du projet, qui seront entreprises dès la phase avant-projet et qui s’appuieront sur 3 types d’actions. Ces actions, s’intégrant dans la Gestion Prévisionnelle des Emplois et Compétences (GPEC), devront nécessairement associer les services RH, notamment pour l’évolution de la fonction de contrôleur de gestion.

Le modèle Scrum des méthodes agiles

Selon l’ouvrage « Manager un projet informatique : Comprendre pour faire les bons choix tout au long du projet », ce modèle est inspiré d’une équipe de rugby qui doit faire preuve de réactivité et de travail d’équipe afin d’atteindre un but.
La méthode Scrum est la plus connue et la plus utilisée des méthodes agiles. Elle repose sur une approche itérative qui favorise la collaboration et propose un cadre de travail permettant de développer des applications nécessitant une grande adaptabilité.
La conception de ce modèle vise l’amélioration significative de la productivité des équipes de développement qui se trouvaient souvent bloquées par des méthodologies lourdes ne permettant pas d’intégrer les changements et la prise en compte des différentes modifications.

Phase de processus métier

Cette première phase vise à décrire les processus métier concernés par la solution à développer et à identifier les différents acteurs intervenant dans ces processus. Le diagramme d’activité proposé par UML peut être utilisé comme support de représentation des processus métier. Cette première phase repose également sur la définition des concepts métiers du domaine étudié. Ces concepts correspondent aux différents objets de gestion transformés, créés ou modifiés dans les processus métier. Dans ce cas, le diagramme de classe proposé par UML nous servira comme support de description des concepts métier.

Phase des exigences fonctionnelles

Compte tenu de la difficulté d’identifier directement la description détaillée des besoins fonctionnels, il est nécessaire de respecter la progression dans la définition des besoins en commençant par une description plus globale des besoins permettant de faire adhérer les décideurs à un niveau stratégique. Ensuite, une description plus détaillée sera élaborée visant l’exhaustivité de la description des besoins.
La maille ou le niveau de détail de la description des besoins prise en charge par la MOA doit être ajustée avec la MOE de façon à s’assurer que l’essentiel du besoin est suffisamment bien décrit. Les diagrammes de cas d’utilisation peuvent être utilisés pour décrire un niveau plus général des exigences fonctionnelles en identifiant : l’acteur, le cas d’utilisation et l’interaction entre l’acteur et le cas d’utilisation.

Composition de l’équipe

Dans un contexte de mission de conseil, le niveau de séniorité exigé pour traiter la problématique étudiée diffère selon le type de la mission. Je donnerai l’exemple de la mission sur laquelle j’ai travaillé pendant ma période de stage : il s’agit d’une mission stratégique qui demande des connaissances et compétences d’expert dans les domaines de contrôle de gestion et de la finance. Ma contribution dans cette mission portait essentiellement sur la production des livrables, la prise de notes, la participation dans la rédaction des comptes rendus, la participation dans l’établissement des questionnaires et le suivi de la mission. L’étape de recueil des besoins génère une charge de travail importante avec une obligation d’être à jour par rapport à la production des comptes-rendus et de leur validation afin de mieux comprendre la position de chaque interlocuteur et d’apporter plus d’efficacité dans le travail.

Bien communiquer pour éviter les éventuels blocages

Comme nous l’avons souligné dans les chapitres précédents de ce mémoire, la phase d’analyse du besoin nécessite d’interagir avec différentes parties prenantes qui ne parlent pas forcément le même langage. Ceci ne doit pas nous empêcher d’impliquer l’ensemble des acteurs concernés dès les phases initiales du projet. Le rôle du maître d’ouvrage à ce stade consiste à assurer la traduction entre chaque catégorie d’acteur. Par exemple, pour un informaticien, il s’agit de lui fournir la vision par le biais d’un diagramme de classe, tandis que pour les métiers, il s’agit de leur fournir un schéma plus simplifié comportant les éléments de langage qui leur sont habituels.

LES ACTEURS DE LA PHASE D ’ANALYSE DU BESOIN CLIENT

Comme nous l’avons évoqué dans les chapitres précédents de ce mémoire, les acteurs d’un projet systèmes d’information sont : La maîtrise d’ouvrage, la maîtrise d’œuvre, le comité de pilotage, l’équipe de réalisation, les utilisateurs finaux et les utilisateurs référents. D’un point de vue pratique, quels sont les acteurs de la phase d’analyse du besoin et quel est le rôle de chacun d’eux ?

Les équipes Métiers

Il s’agit des équipes qui sont à l’origine du besoin et qui doivent être accompagnés par la MOA tout au long du projet. Ils expriment le besoin d’un point de vue purement fonctionnel et peuvent être amenés à former la MOA sur les spécificités de leurs métiers afin d’instaurer un langage commun et intelligible.

Le chef de projet MOA

D’après les réponses au guide d’entretien, La MOA joue principalement une rôle d’interface entre le métier et la MOE. Elle devra donc disposer des compétences technico fonctionnelles facilitant à la fois les échanges avec les métiers ainsi qu’avec la MOE. La MOA doit faire preuve d’esprit d’analyse et disposer de grandes compétences rédactionnelles et de synthèse. Ces compétences sont primordiales lors des échanges avec la MOE afin qu’elle puisse développer la solution qui sera en adéquation avec les besoins du métier.
Ce qui est très important à noter c’est que la MOA n’a pas le droit de se substituer aux métiers et doit garder plutôt un rôle de conseil pour éclairer les métiers dans leur expression de besoins : il s’agit d’alerter les métiers par rapport à la faisabilité de leurs besoins et de leur proposer d’autres alternatives (moins couteuses, plus efficaces) qui peuvent correspondre à leurs besoins.

La maîtrise d’œuvre

La MOE doit assurer la conception et la réalisation de la solution conformément aux besoins communiqués par la MOA.
La MOE doit être calibrée de la même façon que la MOA (équilibre dans le nombre des membres des équipes MOA-MOE) afin d’assurer le bon déroulement du projet. Il faudra noter également que la MOA n’a pas le droit de se substituer à la MOE même si le fait d’être à la fois MOA et MOE peut des fois générer des gains de temps en termes de rapidité d’analyse et d’étude d’impact. Le périmètre de chacun des acteurs (Métier, MOA, MOE) doit être rigoureusement respecté afin d’assurer le bon déroulement de cette phase de recueil et d’analyse des besoins.

LES ENJEUX D’UNE BONNE DEFINITION DES BESOINS

La définition des besoins métiers constitue l’une des étapes incontournables qui conditionne la réussite d’un projet système d’informations. Cependant, la réalisation d’une expression des besoins complète et cohérente peut souvent faire l’objet de plusieurs enjeux et difficultés qui peuvent entraver le bon déroulement de cette phase.

Phase d’analyse du besoin relativement longue

En pratique, la phase d’analyse du besoin peut être relativement longue car elle repose sur de multiples points d’échanges avec les métiers et la MOE. Dans cette première phase d’analyse, la MOA joue un rôle de conseil et d’accompagnement vis-à-vis des métiers et une fois que le besoin fonctionnel est correctement exprimé, la MOA assure un deuxième rôle de traduction du besoin fonctionnel sur la solution technique vis-à-vis de la MOE en répondant aux questions suivantes :
▪ Quel est le rapport coût / qualité de ce besoin ?
▪ Quel est le meilleur moyen pour répondre à ce besoin ?
▪ Quels sont les impacts qui peuvent être engendrés à la suite de la mise en place de la réponse au besoin exprimé ?
Généralement, cette phase d’analyse du besoin ne se déroule pas de façon linéaire mais il faudra prendre en compte des boucles de rétroaction dues aux différents échanges avec la MOE et les métiers afin d’apporter plus de précision et éclairer les zones d’ombre.

La capacité d’assurer la traduction du besoin en tre le Métier et la MOE

Etant donné que la MOA doit assurer son rôle d’interface entre les Métiers et la MOE, ceci nécessite l’acquisition des compétences technico fonctionnelles facilitant à la fois les différents échanges fonctionnels avec les métiers ainsi que les échanges techniques avec la MOE. Il faudra également connaître les disponibilités des métiers pour échanger en cas de besoin. Il faudra donc que tous les acteurs soient disponibles pour assurer des interactions de qualité dans une atmosphère de confiance et de partage (bannir le stress et la pression dans les échanges).

L’établissement d’une distinction entre le véritable besoin et l’accessoire

Lors des échanges avec les Métiers, la MOA procède au recueil des besoins en les classant par ordre de priorité et d’importance tout en faisant la distinction entre ce qui est utile et ce qui est accessoire et qui peut coûter plus cher.
La MOA ne peut pas définir les vrais besoins mais elle prendra en charge tous les besoins en définissant, avec le métier, un ordre de priorité tout en gardant à l’esprit la distinction entre un vrai besoin et ce qui est utile mais pas nécessaire. Cette distinction sera traitée de manière détaillée dans les chapitres suivants de ce mémoire.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport-gratuit.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

INTRODUCTION
PARTIE 1 : – LA CONDUITE D’UN PROJET SYSTEMES D’INFORMATION 
CHAPITRE 1 – LA GESTION D’UN PROJET SYSTEMES D’INFORMATION 
I. Définitions et notions de base
II. La méthodologie de conduite d’un projet systèmes d’information
III. Les spécificités d’un projet systèmes d’information
CHAPITRE 2 – LES ETAPES D’UN PROJET SYSTEMES D’INFORMATION 
I. Les phases d’un projet informatique
II. Les modèles de développement des projets informatiques
III. L’importance de la phase d’analyse du besoin
CHAPITRE 3 – LA PHASE D’ANALYSE DU BESOIN CLIENT 
I. Quelques éléments clés
II. Les acteurs de la phase d’analyse du besoin client
III. Les enjeux d’une bonne définition des besoins
PARTIE 2 – L’ETAPE DE RECUEIL ET D’ANALYSE DU BESOIN CLIENT : METHODOLOGIE ET BONNES PRATIQUES
CHAPITRE 4 – LA METHODOLOGIE DE LA PHASE D’ANALYSE DU BESOIN 
I. La démarche et les techniques de recueil du besoin
II. Les activités préparatoires à la rédaction du cahier de charges fonctionnel
III. Les enjeux et les difficultés liés à cette étape
CHAPITRE 5 – LA REDACTION DU CAHIER DE CHARGES FONCTIONNEL 
I. La méthodologie de rédaction d’un cahier de charges fonctionnel
II. Les difficultés rencontrées
III. Les bonnes pratiques pour un cahier de charges fonctionnel réussi
CHAPITRE 6 – LES BONNES PRATIQUES A METTRE EN PLACE 
I. Les critères de réussite de la phase d’analyse du besoin client
II. Organisation en mode projet et comparaison avec l’organisation en mode agile
III. Projet en mode agile : les principaux changements pour la MOA
PARTIE 3 – LE ROLE DE LA MOA DANS LA REUSSITE DE LA PHASE DE RECUEIL DU BESOIN CLIENT 
CHAPITRE 7 – LES COMPETENCES REQUISES POUR UNE PHASE D’ANALYSE DE BESOINS REUSSIE
I. Les compétences et les responsabilités de la MOA
II. Les méthodes et les outils mobilisés par la MOA pour concrétiser l’analyse du besoin
III. Le rôle de la MOA en dehors des projets systèmes d’information
CHAPITRE 8 – LES INTERACTIONS MOA – MOE DANS UN PROJET SYSTEMES D’INFORMATION
I. La répartition des rôles et des responsabilités entre la MOA et la MOE
II. Les difficultés rencontrées dans les échanges MOA-MOE
CHAPITRE 9 – LES BONNES PRATIQUES A METTRE EN PLACE 
I. Les recommandations pour l’établissement d’une relation partenariale MOA-MOE
II. Le fonctionnement de la MOA en mode agile en se référant à SCRUM
III. Les qualités et les compétences à développer pour assurer le bon déroulement d’un projet systèmes d’information
CONCLUSION

Rapport PFE, mémoire et thèse PDFTélécharger le rapport complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *