LA GESTION DE PROJETS INFORMATIQUES
Ahmed Salem Cheik
Avant-propos
L’Université Virtuelle Africaine (UVA) est fière de participer à accès à l’éducation dans les pays africains en produisant du matériel d’apprentissage de qualité. Nous sommes également fiers de contribuer à la connaissance globale, pour nos ressources éducatives sont principalement accessibles de l’extérieur du continent africain.
Ce module a été développé dans le cadre d’un programme de diplôme et diplôme en
informatique appliquée, en collaboration avec 18 institutions partenaires dans 16 pays africains.
Un total de 156 modules ont été développés ou traduits pour assurer la disponibilité en anglais, français et portugais. Ces modules sont également disponibles en tant que ressources éducatives ouvertes (OER) à oer.avu.org.
Au nom de l’Université Virtuelle Africaine et notre patron, nos institutions partenaires, la Banque africaine de développement, je vous invite à utiliser ce module dans votre établissement, pour leur propre éducation, partager aussi largement que possible et participeractivement aux communautés AVU de pratique d’intérêt. Nous nous engageons à être à l’avant-garde du développement et de partage ouvert de ressources pédagogiques.
L’Université Virtuelle Africaine (UVA) est une organisation intergouvernementale
panafricaine mis en place par lettre recommandée avec un mandat d’augmenter l’accès à l’enseignement supérieur et de formation de qualité grâce à l’utilisation novatrice des technologies de communication de l’information. Une charte instituant la UVA Organisation intergouvernementale, signée à ce jour par dix-neuf (19) Les gouvernements africains - Kenya, Sénégal, Mauritanie, Mali, Côte d’Ivoire, Tanzanie, Mozambique, République démocratique du Congo, Bénin, Ghana, République de Guinée, le Burkina Faso, le Niger, le Soudan du Sud, le Soudan, la Gambie, la Guinée-Bissau, l’Ethiopie et le Cap-Vert.
Les institutions suivantes ont participé au programme informatique appliquée: (1) Université d’Abomey Calavi au Bénin; (2) University of Ougagadougou au Burkina Faso; (3) Université Lumière Bujumbura Burundi; (4) Université de Douala au Cameroun; (5) Université de
Nouakchott en Mauritanie; (6) Université Gaston Berger Sénégal; (7) Université des Sciences, Techniques et Technologies de Bamako au Mali (8) Institut de la gestion et de l’administration
publique du Ghana; (9) Université des sciences et de la technologie Kwame Nkrumah au Ghana; (10) Université Kenyatta au Kenya; (11) Université Egerton au Kenya; (12) Université d’Addis-Abeba en Ethiopie (13) Université du Rwanda; (14) University of Salaam en Tanzanie Dar; (15) Université Abdou Moumouni Niamey Niger; (16) Université Cheikh Anta Diop au Sénégal; (17) Université pédagogique au Mozambique; E (18) L’Université de la Gambie en Gambie.
Bakary Diallo le Recteur
Auteur
Ahmed Salem Cheik
Pair Réviseur
Cherif Diallo
UVA – Coordination Académique
Dr. Marilena Cabral
Coordinateur global Sciences Informatiques Apliquées
Prof Tim Mwololo Waema
Coordinateur du module
Robert Oboko
Concepteurs pédagogiques
Elizabeth Mbasu Benta Ochola Diana Tuel
Equipe Média
Sidney McGregor Michal Abigael Koyier
Barry Savala Mercy Tabi Ojwang
Edwin Kiprono Josiah Mutsogu
Kelvin Muriithi Kefa Murimi
Victor Oluoch Otieno Gerisson Mulongo
Droits d’auteur
Ce document est publié dans les conditions de la Creative Commons Http://fr.wikipedia.org/wiki/Creative_Commons
Attribution http://creativecommons.org/licenses/by/2.5/
Le gabarit est copyright African Virtual University sous licence Creative Commons Attribution- ShareAlike 4.0 International License. CC-BY, SA
Supporté par
Projet Multinational II de l’UVA financé par la Banque africaine de développement.
Avant-propos 2
Crédits de production 3
Droits d’auteur 4
Supporté par 4
La Gestion de Projets informatiques 7 Introduction 7
I.1. Définitions: 7
I.1.1Qu’est-ce qu’un projet 7
I.1.2 Projet informatique : Une définition 7
I.1.3 La gestion de projet 7
I.2. Acteurs du projet 8
I.2.1 Maître d’Ouvrage (MOA) 8
Différentes fonctions MOA 9
I.2.2 Maîtrise d’Œuvre (MOE) 10
II Le cycle de vie d’un projet 11 II.1 Les activités d’un cycle de vie d’un projet informatique 12 II.1.1. Etude d’opportunité et de faisabilité (Définition des Objectifs) 12 II.1.2. Analyse du système (Définition des Besoins) 12 II.1.3. Spécification et conception (Définition du Produit) 12
II.1.4 Planification et gestion de projet 12
II.1.5. Implémentation du système 13
II.1.6. Maintenance du système 13
II.2 Typologie des cycles de vie 13
II.2.1 Le modèle traductionnel 13
II.2.2 Le Modèle flexible ou expérimental 13
II.2.3 Modèle intermédiaire 14
II 3 Modèles de cycle de vie 14
II.3.2 Le cycle en V 15
II.3.3 Le Cycle de vie évolutif 16
II.3.4 RAD (Développement rapide d’applications) 17
II.3.5 Cycle en spirale 19
III Outils Pour La Gestion De Projet 20 III.1 Outils de conception de formalisation 20
III.1.1 La méthode MERISE 20
III.1.1.2 Le langage de modélisation UML 21
III.2 Outils de planification et de suivi 21
III.2.1 Le diagramme de Gantt 22
III.2.2 Le diagramme PERT : exploration des réseaux de tâches 23
III.2.3 La courbe en S 24
III.2.4 Tableau de bord 24
III.3 Les outils informatiques 24
IV La Documentation du projet 25 V gestion du changement 26 V.1. Les objectifs de la gestion du changement 26 V.2 Méthodologies de la gestion du changement 27 Liens & Références 29
La Gestion de Projets informatiques
Introduction I.1. Définitions:
I.1.1Qu’est-ce qu’un projet
Un projet est un ensemble d’actions mis en place pour la réalisation d’objectifs définis et précis dans un délai fixé (il a un début et une fin) et pour un bénéficiaire donnée. Ainsi un projet étant une action temporaire avec un début et une fin, mobilisant des ressources identifiées (humaines et matérielles) durant sa réalisation, celui-ci possède également un coût et fait donc l’objet d’une budgétisation de moyens et d’un bilan indépendant de celui de l’entreprise.
I.1.2 Projet informatique : Une définition
Un projet informatique est un projet dont les réalisations (livrables) se constituent d’outils de méthodes ou de services informatiques.
Les projets informatiques sont généralement, par nature, complexes. Cette complexité s’explique notamment par la grande diversité des acteurs qu’ils font intervenir : techniciens, responsables métier, marketeurs, gestionnaires...
I.1.3 La gestion de projet
La gestion de projet est l’utilisation d’un savoir, d’habiletés, d’outils et de techniques dans le cadre des activités d’un projet, en vue de satisfaire ou de dépasser les exigences et les attentes des parties prenantes à l’égard d’un projet. Le gestionnaire de projet, parfois appelé coordonnateur ou chef de projet, en administre les détails, au jour le jour. Il s’agit là d’un défi constant qui demande une compréhension du contexte plus général du projet et la capacité de concilier des exigences contradictoires telles que :
• les ressources disponibles et les attentes;
• les priorités des parties prenantes;
• les besoins définis et à la portée du projet;
• la qualité et la quantité.
Une approche mécaniste de la gestion de projet prend en compte quatre critères : le coût, la qualité, les délais et la satisfaction du client. En effet, un chef de projet doit réaliser son projet en coûts, délais et qualité fixé initialement. Aussi est nécessaire de s’assurer tout au long du projet, que le produit en cours de réalisation correspond clairement aux attentes du client.
Le projet est avant tout une aventure humaine, qui mobilise un ensemble d’acteurs pour atteindre un but. Chaque acteur assume, dans le projet, une responsabilité propre : planifier, concevoir, développer, valider, tester...
Le projet est avant tout une aventure humaine, qui mobilise un ensemble d’acteurs pour atteindre un but. Chaque acteur assume, dans le projet, une responsabilité propre : planifier, concevoir, développer, valider, tester...
Parmi cette somme d’acteurs, on peut identifier deux entités essentielles de l’organisation :
• la MOA, maîtrise d’ouvrage : le client du projet (mais pas forcément l’utilisateur) ;
• la MOE, maîtrise d’oeuvre : l’organe réalisateur du projet, représenté par le chef de projet.
I.2. Acteurs du projet
Un acteur est une personne qui jour un rôle dans le déroulement d’un projet. Le rôle consiste en une fonction temporaire, indépendamment de la position de la personne dans l’organigramme de l’entreprise.
Dans le cas de petits projets, il y a peu souvent d’acteurs qui sont concernés, et on peut se limiter à une relation client - fournisseur. Le client (ou maître d’ouvrage (MOA)) est la personne (physique ou morale) qui exprime un besoin. Le fournisseur (ou maître d’œuvre (MOE) est la personne (physique ou morale) qui satisfait le besoin.
Le projet est porté en général par un seul fournisseur qui fait appel éventuellement à des partenaires ou des intervenants externes, qui seront fournisseurs de parties de projets.
L’ensemble des acteurs impliqués dans un projet s’appelle les parties prenantes
I.2.1 Maître d’Ouvrage (MOA)
Le MOA est la personne qui commande et paie un système (un ouvrage) qui répond à des besoins. Il est l’entité qui représente les utilisateurs finaux dont le système est destiné.
Partant des besoins des utilisateurs du système, le MOA rédige un Cahier des Charges qui peut servir de base à un appel d’offres. Après la sélection d’un fournisseur, elle passe un contrat avec ce dernier, qui jouera le rôle de maîtrise d’œuvre.
Différentes fonctions MOA
On distingue dans la Maîtrise d’ouvrage (MOA) plusieurs rôles ou fonctions. En voici une liste non-exhaustive :
a. Maître d’ouvrage délégué (MOAD)
Le maître d’ouvrage délégué aide le maître d’ouvrage lorsqu’il n’a pas les compétences
nécessaires. Elle est chargée de faire l’interface entre le maître d’œuvre et le maître d’ouvrage, notamment en apportant une aide et un soutien à la MOA pour la définition des cahiers des charges, la validation de certains livrables. Elle justifie généralement d’une double compétence (informatique et métier) qui apporte à la maîtrise d’ouvrage une aide technique pour jouer au mieux son rôle.
b. La maîtrise d’ouvrage stratégique (MOAS)
C’est lui qui prend les décisions importantes concernant la MOA, qui arbitre les différends entre ses collaborateurs, qui signe le contrat avec la Maîtrise d’œuvre (MOE), qui participe au Comité de pilotage ou le comité directeur du projet. Comme le système d’information (SI) est, dans la plupart des entreprises, à la fois la concrétisation de la stratégie et la condition de sa mise en œuvre, les décisions essentielles sont prises par le MOAS (notamment pour le lancement des grands projets et des programmes d’entreprise).
Le rôle du MOAS est de s’assurer de la bonne adéquation entre:
• d’une part la stratégie « métier » de l’entreprise ou de l’organisation : les objectifs, les enjeux, inscrits dans leur contexte, les opportunités et menaces, ainsi que les forces et faiblesses (vulnérabilités) (voir risque et SWOT).
• et d’autre part le système d’information qui doit se mettre au service de cette stratégie.
c. Le sponsor ou commanditaire
Lorsque la fonction de maîtrise d’ouvrage est moins impliquée dans le projet, on parle parfois de « sponsor » .On retrouve dans cette appellation les origines du vocabulaire de maîtrise d’ouvrage : le sponsor est celui qui « paie ».
Lorsque le projet est de grande envergure et qu’il met en jeu de nombreuses directions métiers au sein de l’entreprise ou de l’organisation, le maître d’ouvrage délégué est mandaté par la direction principale de l’entreprise (la direction générale, ...) - dans ce cas, le MOAD peut s’appuyer sur des relais au sein des différentes directions métier de l’entreprise : ce sont des « sponsors ».
d. Le maître d’ouvrage opérationnel (MOAO)
Le « maître d’ouvrage opérationnel » (MOAO) est, dans l’entité, un expert qui connaît parfaitement l’un des grands processus du métier. Lorsque le SI est organisé en applications, le MOAO est celui qui connaît parfaitement l’application. Il sait, quand on veut faire des choses nouvelles, s’il sera possible d’y parvenir en modifiant des paramètres, ou s’il faudra un développement important ; il connaît les référentiels utilisés, les règles de gestion, les échanges et interfaces avec les autres applications, etc.
Souvent, le MOAO est une personne seule qui possède une expertise précieuse. La
situation peut être catastrophique s’il tombe malade, ou quand il prend sa retraite. Trop peu d’entreprises pensent à ce type de risque, mais souvent le MOAO lui-même n’est pas enclin à partager son savoir.
e. L’assistant à maîtrise d’ouvrage (AMO ou AMOA
Le travail que doivent réaliser un MOAD ou un MOAO comporte des périodes de surcharge lorsqu’il faut spécifier, suivre ou recetter une importante évolution du système d’information
; lorsqu’il faut concevoir ou mettre en place des méthodes nouvelles ; lorsqu’il faut mettre en œuvre une expertise que l’entité ne possède pas.
Dans ces cas, l’entité fait appel, pour réaliser les travaux dévolus à la maîtrise d’ouvrage, à des consultants externes ou à des personnes que l’entreprise a mis à sa disposition : elles rédigent les spécifications ou documents méthodologiques, tiennent à jour les tableaux de bord, etc.
On appelle ces personnes «assistants à maîtrise d’ouvrage» (AMO ou AMOA).
I.2.2 Maîtrise d’Œuvre (MOE)
La MOA est l’entité retenue par la MOA en qualité de chef de projet responsable des choix techniques. Elle est garante de la bonne réalisation technique des solutions, elle fournit le produit. Elle peut réaliser elle-même cette solution, ou missionner un ou plusieurs fournisseurs pour sa réalisation.
Les principaux rôles de l’équipes- projet MOE :
• Les concepteurs / architectes: Responsables de concevoir le système aux étapes d’étude préalable (ou générale) et études détaillées. Le rôle est généralement tenu par un informaticien, mais peut parfois être tenu par des organisateurs ou des gestionnaires
• Les développeurs / programmeurs: Responsables de l’écriture des programmes et de leurs premiers contrôles. Le rôle est tenu par un informaticien
• Les testeurs: Responsables de vérifier que le comportement du système est conforme à ses spécifications générales et détaillées. Le rôle peut être tenu par des informaticiens ou des gestionnaires ; les équipes mixtes sont à privilégier.
Le schéma suivant reprend les principales interactions entre les différents acteurs concernés par un projet informatique:
II. Le cycle de vie d’un projet
Les définitions du cycle de vie d’un projet sont multiples mais elles s’accordent tout de même à le définir comme étant la décomposition d’un projet en un ensemble d’étapes nécessaires au développement d’un produit ou d’un service. Cette décomposition participe également à la gestion des risques ainsi qu’à l’évaluation du produit fini.
Le cycle de vie d’un projet est les étapes de développement d’un produit de sa conception à sa disparition. Il s’applique à tous les produits dont les produits informatiques : logiciels et systèmes d’information…
On distingue deux types de cycle de vie
• Le cycle de vie des produits s›applique à tous les types de produits, et peut être considéré comme un outil de gestion.
• Le cycle de développement des logiciels s›insère dans le précédent, on l›appelle souvent cycle de vie des logiciels
II.1 Les activités d’un cycle de vie d’un projet informatique
II.1.1. Etude d’opportunité et de faisabilité (Définition des Objectifs)
Cette première étape est cruciale et donnera lieu à la production du schéma directeur du projet qui répondra à un ensemble d’interrogations :
la finalité stratégique du projet: Le management étudie la stratégie et décide de la nécessité de fabriquer ou acheter un nouveau produit;
• l’analyse coût/bénéfice ;
• l’analyse des risques ;
• les ressources nécessaires ;
• l’état de l’art en la matière ;
• l’étude et l’analyse de solutions alternatives ;
• les critères d’évaluation du projet ; etc.
II.1.2. Analyse du système (Définition des Besoins)
Cette étape fournira la description détaillée du logiciel à développer aussi bien d’un point de vue fonctionnel que technique. Le produit de cette étape peut être associé à un cahier des charges décrivant les besoins. Un appel d’offres est éventuellement lancé
II.1.3. Spécification et conception (Définition du Produit)
La phase de conception conduit à l’élaboration d’une solution abstraite du produit à implémenter satisfaisant aux besoins préalablement identifiés. La solution reste encore majoritairement indépendante des contraintes techniques.
Les spécifications précises du produit sont décrites ainsi que les contraintes de réalisation.
A l’issue de cette phase, les fournitures intermédiaires sont le dossier de spécifications fonctionnelles et une première version du manuel utilisateur.
Pendant cette phase l’architecture du logiciel est définie ainsi que les interfaces entre les différents modules. On doit veiller à rendre les différentes parties constituants du produits aussi indépendants que possible de manière à faciliter à la fois le développement parallèle et la maintenance future.
II.1.4 Planification et gestion de projet
La phase de planification permet de découper le projet en tâches, de décrire leur enchaînement dans le temps, d’affecter à chacune une durée et un effort calculé en
II.1.5. Implémentation du système
Il s’agit ici de la mise en œuvre du système opérationnel : développement hardware et software, formation des utilisateurs, tests par modules et tests d’intégration, conversion du système existant.
II.1.6. Maintenance du système
Cette dernière étape concerne l’évolution du projet développé. Elle peut prendre la forme de maintenance de type corrective si le projet révèle à l’usage des dysfonctionnements ou des erreurs de programmation. Elle peut également tenir en certains travaux visant à faire évoluer le projet en fonction des problèmes nouveaux rencontrés ou des desiderata des utilisateurs.
II.2 Typologie des cycles de vie
Un certain nombre de méthodologies ou encore de modèles de développement de projet ont été élaborés depuis les années 60, afin d’aider les gestionnaires de projet dans leur tâche. Ces divers modèles se caractérisent par un agencement particulier des étapes de base décrites précédemment, selon la complexité du projet à développer, l’environnement organisationnel, le degré de complexité des spécifications ou encore le degré d’implication souhaité des utilisateurs.
II.2.1 Le modèle traductionnel
Il vise avant tout le contrôle et à la réduction des incertitudes du projet. Il favorise la régulation et se caractérise par une approche top down, enfermant le projet dès le départ dans des choix assez strictement définis et peu adaptables en cours de développement. Cette rigidité permet d’isoler le projet des perturbations de la réalité sociale. La séparation des rôles de concepteurs et d’utilisateurs est flagrante, l’implication des utilisateurs étant réduite au strict minimum. Le cycle de vie du projet est strictement défini avec un début et une fin clairement identifiés.
Nous pouvons citer comme modèles faisant partie de cette catégorie : Le cycle de vie en cascade, le cycle de développement en V, ...etc.
II.2.2 Le Modèle flexible ou expérimental
Ce type de modèle s’attache d’avantage à la gestion de l’incertitude de la réalité sociale avec un projet plus modularisé, fragmenté dans le temps et en fonction des changements et évolutions survenus suite à l’expérimentation du projet par les utilisateurs.
Les concepteurs font donc évoluer le projet en fonction des réactions des utilisateurs, mais ils restent aux commandes du projet. Les rôles de concepteurs et d’utilisateurs restent toujours
Le cycle de vie du projet n’est pas clairement fini dans le temps : le projet apparaît comme étant toujours en cours de développement.
Les choix techniques sont flexibles et peuvent être adaptés au cours du processus de développement.
Les cycles de vie les plus classiques appartenant au modèle flexible sont sans conteste le cycle de vie évolutif ou encore celui du développement en spirale.
II.2.3 Modèle intermédiaire
Ce dernier modèle tend à conjuguer les avantages des deux modèles précédents. Parmi les modèles intermédiaires, citons l’approche RAD.
II.3 Modèles de cycle de vie II.3.1 Modèle en cascade
Le modèle en cascade est hérité de l’industrie du Bâtiment et travaux publics. Ce modèle repose sur les hypothèses suivantes :
• on ne peut pas construire la toiture avant les fondations ;
• les conséquences d’une modification en amont du cycle ont un impact majeur sur les coûts en aval (on peut imaginer la fabrication d’un moule dans l’industrie du plastique).
Les phases traditionnelles de développement sont effectuées simplement les unes après les autres, avec un retour sur les précédentes, voire au tout début du cycle.
Les étapes préconisées sont :
• l’étude de faisabilité
• la définition des besoins
• la conception
• l’implémentation
• la maintenance
Le modèle en cascade est d’avantage adapté aux projets de petite taille. Il a connu au cours du temps plusieurs variantes destinées à pallier à sa rigidité, la principale critique qui lui est adressée.
Les avantages du modèle en cascades :
• les étapes sont clairement définies et il est facile d’y associer un output documentable et vérifiable ;
• la découpe des tâches est simple et intuitive ;
• la responsabilité humaine est facilement associable à chaque étape du projet;
• le suivi des étapes et de l’évolution du projet reste relativement aisé ;
• cette méthode permet la réduction du risque de changement continuel des spécifications du projet.
Les inconvénients :
• la rigidité des phases et la complexité du retour ;
• l’estimation du coût est difficile à faire ;
• on constate une mauvaise intégration et anticipation du changement ;
• le point de contrôle reste principalement basé sur la production d’un document.
II.3.2 Le cycle en V
Le modèle du cycle en V a été imaginé pour pallier le problème de réactivité du modèle en cascade. Ce modèle est une amélioration du modèle en cascade qui permet en cas d’anomalie, de limiter un retour aux étapes précédentes. Les phases de la partie montante doivent
renvoyer de l’information sur les phases en vis-à-vis lorsque des défauts sont détectés afin d’améliorer le logiciel.
De plus le cycle en V met en évidence la nécessité d’anticiper et de préparer dans les étapes descendantes les « attendus » des futures étapes montantes : ainsi les attendus des tests de validation sont définis lors des spécifications, les attendus des tests unitaires sont définis lors de la conception, etc.
II.3.3 Le Cycle de vie évolutif
Basé sur le modèle du prototype à jeter, le modèle évolutif améliore sans cesse la version initiale du prototype jusqu’à l’obtention du produit fini.
Il est plutôt adapté à une conception participative avec un nombre réduit d’utilisateurs.
Les avantages :
• meilleure adéquation du produit fini aux besoins des utilisateurs ;
• flexibilité et bonne prise en considération des changements éventuels ;
• participation des utilisateurs.
Les inconvénients :
• manque de méthode ;
• il n’est pas toujours aisé de terminer ce genre de projets ;
• risque de logiciel mal structuré, manque de vue globale.
II.3.4 RAD (Développement rapide d’applications)
Cette approche peut être considérée comme un intermédiaire entre le modèle de l’épure et le modèle évolutif. En effet, la première phase du projet se caractérise plutôt par une approche en cascade, la suite du projet étant davantage caractérisée par une approche itérative- incrémentale du besoin de l’utilisateur afin d’assurer l’adéquation des résultats finaux aux besoins exprimés.
Le cycle RAD introduit par James Martin comporte trois phases :
cadrage (Joint Requitement Planning) : cette étape couvre l’analyse des besoins, le périmètre et la planification de l’itération ;
conception (Joint Application Design) : elle couvre la conception, la description, l’organisation des données et des traitements avec les utilisateurs ;
construction (Construction Assistance Team) : cette ultime étape couvre le développement et les tests.
Le modèle de développement RAD est plus particulièrement adapté aux projets où les
Les avantages :
• assure la conformité de l’application aux exigences des utilisateurs. Il participe ainsi à l’assurance qualité.
Les inconvénients :
• le gestionnaire de projet doit faire preuve d’une certaine expérience en la matière
;
• parce qu’il initialement conçu pour une culture de projet américaine, il faudra s’assurer des conditions et du contexte d’un projet RAD avant d’y souscrire.
II.3.5 Cycle en spirale
Le développement reprend les différentes étapes du cycle en V. Par l’implémentation de versions successives, le cycle recommence en proposant un produit de plus en plus complet et robuste.
Le cycle en spirale met cependant plus l’accent sur la gestion des risques que le cycle en V.
En effet, le début de chaque itération comprend une phase d’analyse des risques. Celle-ci est rendue nécessaire par le fait que, lors d’un développement cyclique, il y a plus de risques de défaire, au cours de l’itération, ce qui a été fait au cours de l’itération précédente
III. Outils Pour La Gestion De Projet III.1 Outils de conception de formalisation
Les outils de conception permettent d’avoir une vision globale, de se poser les bonnes questions. Il existe plusieurs outils mais les plus utilisés sont les deux suivant:
III.1.1 La méthode MERISE
MERISE est une méthode de conception, de développement et de réalisation de projets informatiques. Le but de cette méthode est d’arriver à concevoir un système d’information.
MERISE constitue depuis le milieu des années 80 un standard de fait dans le domaine des systèmes d’information de gestion en France et dans les pays francophones.
Cette méthode intègre à la fois les aspects décisionnels et techniques, elle s’apparente en cela au modèle en spirale mais procède plutôt en cascade. Elle est utilisée pour développer des systèmes d’information complets et subit des mises à jour fréquentes. Elle traite l’ensemble du cycle de vie d’un système d’information et adopte une approche systémique de l’entreprise.
Elle tient compte des 3 axes: cycle de décision, cycle d’abstraction et cycle de vie.
Merise procède par étapes :
• Schéma directeur: approche globale du problème prenant en compte la stratégie
• Étude préalable de chaque domaine
• Étude détaillée de chaque sous domain
• Étude technique par projet
• Réalisation par projet
• Mise en œuvre projet par projet
• Exploitation du produit
• Maintenance du produit
Comme dans le cycle de vie en spirale ou dans le modèle incrémental on met en exploitation les projets issus des différents domaines les uns après les autres jusqu’à obtenir un système complet.
La méthode opère par une modélisation descendante des systèmes et utilise une séparation données / traitements /communication
Le système d’information est décomposé en différents niveaux - conceptuel (description de l’activité: QUOI) - organisationnel (QUI, OU, QUAND)
Ces trois niveaux s’appuient sur un certain nombre de modèles, Modèle de communication Modèles de données, Modèles de traitements.
MERISE est en constante évolution, en particulier MERISE intègre aujourd’hui les concepts et techniques de l’ approche objets.
III.1.1.2 Le langage de modélisation UML
UML (Unified Modeling Language ) ou Langage de modélisation unifié, est un langage de modélisation graphique à base de pictogrammes. Il est utilisé en développement logiciel, et en conception orientée objet. UML est également utilisé dans les projets logiciels. ...
Cette modélisation objet permet de créer une représentation informatique des éléments du monde réel auxquels on s’intéresse, sans se préoccuper de l’implémentation, ce qui signifie indépendamment d’un langage de programmation.
L’intérêt d’une méthode objet c’est qu’elle permet de définir le problème à haut niveau sans rentrer dans les spécificités d’un langage. Il représente ainsi un outil permettant de définir un problème de façon graphique, afin par exemple de le présenter à tous les acteurs d’un projet et les différents cas d’utilisation.
III.2 Outils de planification et de suivi
La planification c’est l’activité qui consiste à déterminer et à ordonnancer les tâches du projet, à estimer leurs charges et à déterminer les profils nécessaires à leur réalisation.
La planification du projet est initialisée au début d’un projet et mise à jour pendant toute sa durée de vie. L’outil requis est le planning. Un même projet peut faire l’objet de plusieurs plannings : un planning global et un ou des planning(s) détaillé(s). L’ensemble de ces plannings permet de gérer les principales tâches et jalons du projet.
Les objectifs du planning sont les suivants :
déterminer si les objectifs sont réalisés ou dépassés suivre et communiquer l’avancement du projet affecter les ressources aux tâches
III.2.1 Le diagramme de Gantt
Le diagramme de Gantt permet de planifier un projet et rendre plus simple le suivi de son avancement. Il est l’un des outils les plus efficaces pour représenter visuellement l’état
d’avancement des différentes activités (tâches) qui constituent un projet. Il permet de visualiser facilement le déroulement du projet, ainsi que de prévoir suffisamment à l’avance les actions à penser. On pourra aussi gérer plus facilement les conflits de ressources et les éventuels retards en visualisant l’impact de ceux-ci sur le déroulement du projet.
En outre, le diagramme de GANTT est un bon outil de communication avec les différents acteurs du projet.
Le diagramme permet donc de visualiser d’un coup d’œil :
· Les différentes tâches à envisager
· La date de début et la date de fin de chaque tâche
· La durée escomptée de chaque tâche
· Le chevauchement éventuel des tâches, et la durée de ce chevauchement
· La date de début et la date de fin du projet dans son ensemble
Dans un diagramme de GANTT chaque tâche est représentée par une ligne, tandis que les colonnes représentent les jours, semaines ou mois du calendrier selon la durée du projet. Le temps estimé pour une tâche se modélise par une barre horizontale dont l’extrémité gauche est positionnée sur la date prévue de démarrage et l’extrémité droite sur la date prévue de fin de réalisation. Les tâches peuvent s’enchaîner séquentiellement ou bien être exécutées en parallèle.
Tache Semaine1 Semaine2 Semaine3 Semaine4 .... Semainen
Préparation Conception Développement Maintenance
Un exemple de diagramme de Gantt simple
III.2.2 Le diagramme PERT : exploration des réseaux de tâches
Le diagramme PERT (Project Évaluation and Review Technique) permet d’évaluer la durée de réalisation d’un projet complexe et de détecter les parties de ce projet ne supportant aucun retard. Elle résout des problèmes appelés problèmes d’ordonnancement.
Le projet sera subdivisé en tâches. En général, elles ne pourront toutes être réalisées
simultanément, certaines tâches devront être achevées avant que d’autres ne puissent débuter.
On utilise un graphe de dépendances PERT pour chaque tâche, on indique une date de début et de fin au plus tôt et au plus tard.
Le diagramme permet de déterminer le chemin critique qui conditionne la durée minimale du projet. Ces techniques ne pas propres au projet informatique; elles sont aussi appliquées dans tout type de projet.
Exemple:
Supposons un projet composé des taches, A, B,C,D avec contraintes suivantes:
· A et B sont indépendants
· L›exécution de la tâche D ne peut commencer que si A et B sont exécutées.
· L›exécution de C peut commencer si D est exécuté
Le graphe sera un graphe valué dont les arcs seront les tâches et les sommets représenteront des états d›avancement du projet, numérotés de 1 à n
III.2.3 La courbe en S
La courbe en S permet de mettre en évidence les différences entre les prévisions et la réalité du projet. Elle peut par exemple être utile si l’on souhaite visualiser la différence entre les dépenses effectuées et les dépenses prévisionnelles:
III.2.4 Tableau de bord
Un Tableau de bord ou “journal de bord” est tenu à jour et permet de garder une trace des informations communiquées, des problèmes rencontrés, des décisions prises, des responsables désignés pour mener à bien les actions et la date de réalisation de l’action
III.3 Les outils informatiques
Il existe divers outils informatiques permettant de nous assister dans les différentes phases d’un projet. Le travail de ces outils de gestion de projet est généralement d’automatiser des tâches de sauvegarde et/ou de la gestion du temps. Par exemple, les systèmes de gestion de versions, ou les systèmes de gestion de configuration enregistrent différents états d’un projet et gardent une trace de la date de modification.
Une part importante des logiciels de gestion de projet s’occupent de la planification des projets, c’est-à-dire de l’ordonnancement de tâches en vue de leur réalisation future par exemple permet de modéliser les outils de gestion (diagrammes de Gantt, diagrammes PERT,...).
MSProject: est un outil complet de gestion de projet qui permet de bâtir un planning très rapidement et de piloter les gros projets comme les petits. Il offre en outre la possibilité de faire des présentations graphiques personnalisées avec les affichages GANTT / PERT / CALENDRIER. Les version récentes de MS Project utilise les technologies d’Internet pour
D’autre permettent de faciliter la phase de développement comme:
• VS (Concurrent Version System): CVS permet de gérer le développement simultané
• SourceForge: Site d’hébergement de projets de développement coopératif de logiciel.
IV. La Documentation du projet
La documentation d’un projet c’est l’outil de communication et de dialogue entre les membres de l’équipe projet et les intervenants extérieurs (membre des instances de pilotage, chef de projet, utilisateurs, etc...). Elle assure aussi la pérennité des informations au sein du projet.
La documentation associée à un projet doit être le reflet de la vie de ce projet. Elle est élaborée et mise à jour tout au long du projet.
Afin d’organiser la gestion de la documentation produite par projet, il convient au préalable d’identifier tous les types de documents relatifs aux diverses phases du projet, de les
référencer de manière homogène pour ensuite définir un mode de gestion commun à tous les projets.
Documents de référence
Il s’agit des diverses documentations associées au projet, on distingue les éléments
destinés aux utilisateurs, ceux destinés aux développeurs pendant le développement et aux mainteneurs en phase de maintenance.
Documents liés à une phase du cycle de vie (essentiellement destiné aux développeurs et mainteneurs)
– cahier des charges
– document de spécifications fonctionnelles – plan d’intégration
– manuel de conception globale et détaillée
– procédures de validation tests unitaires, d’intégration, de validation, de non régression
– code
Documents transversaux à la vie du projet
- Le glossaire, la liste des abréviations.
- Le plan projet
Documents remis au client
- Le manuel utilisateur - Le manuel d’installation - Le manuel de maintenance
V. gestion du changement
Le changement déstabilise les acteurs d’un projet au travers de certaines situations, telles qu’une perte de repères dans les actes de gestion quotidiens, un manque de maîtrise des nouvelles procédures ou encore des difficultés liées à une nouvelle organisation.
Une conduite du changement doit faire l’objet d’un travail continu tout au long du projet de la part de la MOA. Elle doit couvrir trois domaines clés: la communication, l’information et la formation.
V.1. Les objectifs de la gestion du changement
Une nouvelle représentation basée sur les trois piliers de l’entreprise que sont l’homme, la fonction et l’organisation permet d’ores et déjà de se rappeler que les 3 objectifs majeurs de la conduite du changement en système d’information sont :
• L’appropriation de l’outil par l’utilisateur final en le sensibilisant dès la naissance du projet SI, en lui apportant une visibilité régulière sur son avancement et en le responsabilisant dans ses attributions futures.
• L’adéquation et la pertinence de l’outil dans la fonction en définissant les nouvelles méthodes de travail à adopter ainsi que les règles, les process et les procédures associées.
• L’intégration de l’outil dans l’organisation en impliquant les acteurs à tous les niveaux de la ligne hiérarchique et en tenant compte des nouvelles interactions transversales générées par l’outil.
V.2 Méthodologies de la gestion du changement
La méthodologie adoptée pour piloter la conduite du changement doit permettre d’atteindre plusieurs objectifs:
• En étude préalable, démontrer et faire savoir l’implication de la Direction afin d’impulser le changement et de le traduire en organisation et en processus de travail nouveaux clairs.
• En phase de conception/réalisation, faire travailler de façon efficace MOA et utilisateurs de façon à élaborer un plan de conduite du changement réellement adapté au projet et au terrain
• En phase de déploiement, faire en sorte que les opérations de conduite du changement décidées permettent au projet d’être vite et bien compris, bien admis, vite et bien utilisé, grâce à une information et une formation efficaces, c’est-à-dire parvenant à temps aux bons destinataires et répondant à leurs préoccupations réelles.
Démarche de conduite du changement (change management) en trois étapes
La mise en place d’une démarche de gestion du changement permet de minimiser la perte de productivité au démarrage, d’ancrer le changement dans les habitudes et les comportements ainsi qu’optimiser le retour-sur-investissement.
Permet également d’analyser les impacts sur les populations concernées par le changement (rôles et responsabilités des différents acteurs, cartographie des populations, importance du changement et de la résistance des acteurs),
Définition et mise en œuvre du plan de changement, dont l’intensité et la forme sont adaptées en fonction de l’importance du changement, des résistances précédemment identifiées et de la culture de l’organisation :
• Plan de formation : définition de la stratégie de formation, du planning, des cursus, du matériel pédagogique, animation des formations etc., pour une prise en main et une montée en compétence des utilisateurs,
• Plan de communication : définition de la stratégie, des messages en fonction des populations, du planning, création de supports différenciés adaptés à la culture de l’entreprise, mise en œuvre de la communication pour une sensibilisation des utilisateurs et une adhésion enthousiaste au projet,
• Assistance utilisateurs : définition et dimensionnement du plan d’assistance et des structures à mettre en place (hotline, référents métiers etc.)
Ce qui permet d’améliorer le suivi du changement en entreprise La reconnaissance et les incitations
Les formations
La présence d’une tierce personne de soutien
Un moyen de diffusion de l’information simple et le retour d’information L’homogénéisation de l’accès à l’information
Expliquer clairement l’importance des changements
L’implication des personnes concernées par le changement dans tout le processus de développement du projet.
support utilisateurs au moment du déploiement
La planification du projet de conduite du changement et son intégration dans le projet
“principal”
Ce qu’il faut éviter
Ne pas tenir compte des enjeux et risques individuels Ne communiquer que sur l’objectif
Mauvaise utilisation de l’outil par manque de formation des utilisateurs, Manque d’information des utilisateurs et du management opérationnel.
Liens & Références
1. Anne-Marie Hugues © 19/12/02
2. “ Le management de projet “ de J-M HAZEBROUCQ et O.BADOT 3. “ Animer et Gérer un projet “ de L.BELLENGER et M-J COUCHAERE
4. “Fonctions dans la maîtrise d’ouvrage », de Michel Volle (2002), sous licence de documentation libre GNU.
5. De l’Informatique : Savoir vivre avec l’automate, Michel Volle, Economica, 2006, ISBN 2717852190)
6. DeMarco, Tom, Controlling Software Projects, New York: Yourdon Press,1982.
7. Jones,Capers. Assessment and Control of Software Risks. Englewood Cliffs N.J.:Yourdon Press,1994. Estimation,Project management.
8. Lobet-Maris Claire, Nigot Sylvie, Henin Laurent (2002), Valorisation des résultats de recherches COST, Namur, Mai 2002, 202 pages
9. Winston W. Royce. Managing the Development of Large Software Systems. IEEE Wescon, p. 1-9, 1970
10. John McDermid et Knut Ripken. Life cycle support in the ADA environment.
University Press, 1984.
11. Barry W. Boehm. A Spiral Model of Software Development and Enhancement. IEEE Computer, 21(5), p. 61-72, 1988.
12. James Martin. Rapid Application Development. Macmillan Coll. Div., 1991.
13. Philippe Kruchten. The Rational Unified Process: An Introduction. Addison-Wesley, Longman Publishing, Co., Inc. Boston, Massachusetts, 2000.
14. PRATIQUES DE LA CONDUITE DU CHANGEMENT, Comment passer du discours à l’action, David Autissier, Jean-Michel Moutot, DUNOD – 2003
15. http://www.gestion-projet-informatique.vivre-aujourdhui.fr/
16. GPI : http://projetsinformatiques.free.fr
17. Comment ça marche : http://w w w.commentcamarche.nethttp://w w w.
commentcamarche.net/
18. http://www.commentcamarche.net/
19. Gilb,Tom. Principles of Software Engineering Management. Workingham,Englang:
Addison Wesley,1988. Practical advices for estimating software schedule.Focus on the importance of controlling the project to achieve your objectives rather than passive prediction about it.
21. Katwijk, J. van, Inleiding software engineering, (1994)
22. Pressman, Roger S., (adapted by Darrel Ince) Software engineering “A practitioner’s approach”, (1994)
Siège de l’Université Virtuelle Africaine The African Virtual University
Headquarters Cape Office Park Ring Road Kilimani PO Box 25405-00603 Nairobi, Kenya
Tel: +254 20 25283333 contact@avu.org oer@avu.org
Bureau Régional de l’Université Virtuelle Africaine à Dakar Université Virtuelle Africaine
Bureau Régional de l’Afrique de l’Ouest Sicap Liberté VI Extension
Villa No.8 VDN
B.P. 50609 Dakar, Sénégal Tel: +221 338670324 bureauregional@avu.org
