DSCG : UE5 - Management des Systèmes d'information CARTE HEURISTIQUE...1 GESTION DE PROJET...2

Transcription

1 Table des matières CARTE HEURISTIQUE...1 GESTION DE PROJET...2 DÉFINITION D'UN PROJET... 2 LES CLASSIFICATIONS DES PROJETS DE SYSTÈME D'INFORMATION...3 La classification selon des critères généraux...3 La classification selon le type de projet...3 La classification selon le type de projet...3 EXEMPLES DE PROJET DE SI... 3 LES ENJEUX D'UN PROJET DE SYSTÈME D'INFORMATION...4 La place du projet de SI dans la stratégie de l'entreprise...4 L'ORGANISATION DU PROJET... 4 Le comité directeur...5 La maîtrise d'ouvrage...5 Le comité de pilotage...5 Le comité des utilisateurs...5 Le centre de compétences...5 La maitrise d'œuvre...6 Le groupe de projet...6 L'équipe de conception et de réalisation...7 Les relations entre la maîtrise d'ouvrage et la maîtrise d'œuvre...7 Types de structures (organigramme de l'équipe projet)...7 LE CYCLE DE VIE D'UN PROJET Les étapes du cycle de vie...10 L estimation des charges...12 Les paramètres d'un plan d'assurance et contrôle qualité...15 CONDUITE DE PROJET PGI Le contenu d'un projet ERP...17 Les étapes d'un projet ERP...17 Carte heuristique 1/17

2 Gestion de projet Définition d'un projet «Un projet correspond à la situation dans laquelle on se trouve quand on doit atteindre un objectif avec des moyens appropriés dans un délai donné». «La gestion ou conduite de projet a pour but de mener un projet à son terme en prenant en compte les contraintes et en faisant face aux imprévus». A chaque point caractéristique d'un projet (objectif, moyens, délai), la conduite de projet associe une technique de gestion. Le délai donne lieu à une gestion du temps dont le rôle est de définir le parcours, de le jalonner, d'établir des calendriers et de maîtriser la consommation de l'enveloppe temps. Les moyens affectés constituent le budget du projet, qui est transformé en travail, locaux, matériel, temps machine, déplacement... Cette transformation nécessite une gestion des ressources portant sur les ressources humaines et les moyens matériels. Dans les projets système d'information, les ressources humaines occupent une place primordiale. Utiliser chacun au mieux, constituer des équipes efficaces, affecter les personnes au moment adéquat en fonction de leurs compétences, coordonner les travaux, limiter le nombre d'acteurs sans pour autant exclure.. telles sont les attributions de cette fonction L'objectif du projet doit à son terme être concrétisé par une ou plusieurs fournitures. Ce sommet donne naissance à la gestion de la production qui a pour but de suivre et de diriger l'avancement vers l'objectif tout au long du projet. Il faut sans cesse s'assurer que l'on se rapproche du but et que l'on ne part pas dans des directions remettant en cause un avancement consolidé. L'activité de gestion de projet peut être décomposée en trois activités principales : Analyser : déterminer le chemin pour atteindre l'objectif. Découpage du projet en actions à entreprendre et estimation de l'effort nécessaire. Organiser : constituer les équipes, ordonner les tâches, élaborer le calendrier. Piloter : suivre l'avancement du projet en qualité et en quantité, analyser les écarts et prendre les décisions. Un projet se gère du début à la fin. L'approche de la problématique définie à l'issue de l'analyse des risques peut être remise en cause par un aléa interne ou externe. Cela peut conduire à une replanification, une nouvelle répartition des tâches, voire à une modification de l'objectif initial. C'est ce que représente la boucle de rétroaction dans le schéma précédent. Un projet possède quatre caractéristiques: il est unique; s'il existe de nombreux projets analogues ou similaires, aucun projet n'est identique à un autre en raison des évolutions technologiques et des spécificités organisationnelles de chaque entreprise. Contrairement aux processus répétitifs, l'organisation d'un projet est toujours à redéfinir; il est limité dans le temps; un projet est mené par rapport à un calendrier dans un espace temps borné par un début et une fin ; il doit répondre à des contraintes de délais, de coûts, de ressources, mais également de qualité, ce qui impose la mise en place d'un processus de management de projet; il est pluridisciplinaire; il requiert des compétences techniques, administratives, financières, juridiques, etc. 2/17

3 Les projets de SI revêtent également ces caractéristiques générales. Les classifications des projets de système d'information La diversité des projets de système d'information incite les entreprises à procéder à des classifications qui peuvent se fonder soit sur des critères généraux, soit sur le type de projet conduit. La classification selon des critères généraux Une première classification s'appuie sur les critères généraux que sont: le budget, qui correspond au montant engagé pour la réalisation du projet; le périmètre, qui détermine l'ensemble des activités et processus concernés par le projet; la complexité de lancement et de mise en œuvre du projet, tant au niveau technologique qu'au niveau organisationnel. Cette classification est utile pour déterminer l'ordre de réalisation des projets en fonction des contraintes et des ressources de l'entreprise. Le projet d'intégration d'un progiciel de gestion intégré (PGI) dans un groupe est un projet essentiel de plusieurs centaines de milliers d'euros demandant une définition très précise des objectifs et se déroulant sur deux années. Il est complexe étant donné que son périmètre concerne l'ensemble des processus. Une organisation de ce projet doit être mise en place pour sa mise en œuvre. Le projet de mise en œuvre d'un progiciel de gestion de stock est un projet secondaire de quelques dizaines de milliers d'euros demandant une définition moins précise en raison du recours à une solution éprouvée sur le marché et répondant aux besoins fonctionnels du service utilisateur de l'entreprise. Un seul acteur de l'organisation se charge de sa mise en œuvre en raison de la simplicité de l'élaboration de la solution envisagée. La classification selon le type de projet Le type du projet détermine son mode de pilotage. Un projet obligatoire sera piloté par les coûts, un projet de productivité par la rentabilité. En revanche, un projet stratégique pourra s'appuyer sur l'une ou l'autre approche. Type de projet Projet stratégique Projet de productivité Projet obligatoire Description Exemples Refonte d'un système d'information obsolète Projet impactant la stratégie Implantation d'un PGI permettant de proposer globale de l'entreprise de nouveaux services Informatisation d'un processus Projet améliorant la productivité de l'entreprise Reconfiguration d'un processus Intégration des modifications du plan comptable général dans le logiciel de gestion des immobilisations Projet résultant de contraintes légales, réglementaires, etc Implantation d'un logiciel de consolidation respectant les normes IAS/IFRS dans un groupe coté Exemples de projet de SI Le terme projet concerne toute évolution du système d information requérant une décision d investissement informatique. Y compris en interne à une DSI. Il peut s agir aussi bien : d une application nouvelle quelle qu en soit la nature : gestion de connaissances, workflow, application métier, application interne à la DSI comme la gestion d un centre d appels, etc. ; de la rationalisation d un existant : migration de plate-forme matérielle ou logicielle, refonte logicielle, mutualisation de ressources logicielles ou applicatives, etc. ; de projets internes DSI mais structurants pour l entreprise : gestion d annuaire par exemple, gestion centralisée des habilitations, etc. ; de projets «partenaires» : extranet, EDI, etc. 3/17

4 Les enjeux d'un projet de système d'information Les enjeux d'un projet de SI sont de contribuer à l'efficacité et à la maîtrise du système d'information ainsi qu'à la performance globale de l'entreprise tant le système d'information est un véritable actif stratégique au service de la stratégie globale de l'entreprise. La place du projet de SI dans la stratégie de l'entreprise Un projet de système d'information doit s'inscrire dans la stratégie globale de l'entreprise car il consomme des ressources importantes (humaines, financières, etc.) pendant une longue période. C'est la raison pour laquelle l'entreprise doit, avant même de se lancer dans un projet, définir ses objectifs à moyen terme dans un schéma directeur informatique Ce document permettra une planification globale des projets et des investissements à conduire dans l'entreprise, selon différents critères (budget, délais, risques, charges internes, besoins en conduite de changement, etc.) Les projets sont ensuite analysés sous l'angle de leur périmètre. Si le projet est trop étendu ou trop complexe, il est décomposé en sous-projets avec des périmètres différents. Le projet d'intégration d'un progiciel de gestion intégré dans un groupe pourra donner lieu à plusieurs sous-projets: SP1 : intégration du module de gestion des ventes; SP2 : intégration du module de comptabilité; etc. Les sous-projets sont hiérarchisés pour déterminer l'ordre de leur réalisation. Ils peuvent être regroupés en lots: on parle alors de «lotissement». Cette subdivision permet de faciliter la réalisation de projets de système d'information. L'organisation du projet Une fois la décision de lancer un projet prise, se pose la question de la gestion de ce projet. La conduite d'un projet nécessite la mise en place d'une démarche méthodologique visant à assurer la coopération et la coordination des acteurs ainsi que l'organisation des tâches dans un souci de rentabilité, d'efficacité et de qualité. Elle se base sur une organisation du projet en deux entités distinctes que sont: la maîtrise d'ouvrage (MOA), qui est le client du projet; la maîtrise d œuvre (MOE), qui est le fournisseur, l'organe réalisateur du projet. Ces deux entités peuvent appartenir à la même entreprise. L'organisation du projet est mise en place par un comité directeur. Le comité directeur Le comité directeur des projets de système d'information est un comité permanent composé de membres de la direction générale et, éventuellement, de représentants de la direction des systèmes d'information (DSI) et des directions métiers (DM). Il définit la politique informatique de l'entreprise et élabore le schéma directeur. Dans le cadre d'un projet, le comité directeur: initie le projet et précise ses orientations; 4/17

5 définit le périmètre du projet, voire, si la définition des processus est difficile, les fonctions ou les services impactés ; met en place le comité de pilotage; valide le budget et décide du démarrage du projet. Dès la fin de l'étude préalable, le comité directeur n'intervient plus directement dans le cycle de vie du projet. La maîtrise d'ouvrage L'AFNOR (Association française de normalisation) définit la maîtrise d'ouvrage comme «une personne physique ou morale qui sera propriétaire de l'ouvrage [et] assure le paiement des dépenses liées à la réalisation». La MOA peut faire appel à un assistant à la maîtrise d'ouvrage (AMOA ou AMO), entité interne ou externe qui l'assistera dans la conduite du projet. L'organisation de la MOA est fonction de la taille du projet, mais elle est généralement constituée d'un comité de pilotage et d'un comité des utilisateurs. Le comité de pilotage Le comité de pilotage est l'organe directeur de la maîtrise d'ouvrage en charge des arbitrages nécessaires à la conduite du projet (révision des délais, modification du périmètre du projet, etc.). Il est créé par le comité directeur, à qui il rend compte de l'évolution du projet. Présidé par un directeur de projet (chef de projet MOA), il est composé de représentants opérationnels concernés par la nouvelle application, de l'assistant à la maîtrise d'ouvrage, d'experts internes ou externes. Le chef de projet MOA doit disposer d'une bonne connaissance de l'entreprise, de son activité et de ses usages. Le groupe Pages jaunes définit ainsi, dans ses publications de poste, la mission d'un chef de projet MOA : il doit «garantir le bon déroulement des projets qui lui sont confiés. Il conçoit et réalise les recettes, planifie et suit l'avancement des projets et participe à l'accompagnement du changement pour les utilisateurs. [... ]» ( Le comité des utilisateurs Le comité des utilisateurs est constitué de représentants des utilisateurs qui interviennent dans les domaines d'activité concernés par le projet, d'experts métiers et du chef de projet MOA. Il est important d'obtenir une réelle participation de ses membres durant le déroulement du projet afin que la solution réalisée dans le cadre du projet soit acceptée par les utilisateurs finaux. Ses attributions sont les suivantes: expression des besoins; validation des livrables; participation aux tests de la solution; participation aux actions de formation; réception définitive de la solution. Le centre de compétences Le Centre de Compétences (CC) diffère des structures traditionnelles fonctionnant en mode projet hiérarchisé. C'est une structure dédiée à l'accompagnement des utilisateurs dans laquelle se mobilisent des experts techniques, fonctionnels et opérationnels' selon la nature des dysfonctionnements à résoudre et leurs niveaux de complexité. Si le niveau de complexité nécessite des compétences qui ne sont pas présentes dans l'entreprise le CC peut faire appel aux consultants de l'éditeur, de l'intégrateur, ou autre partenaire. Les CC ont pour objectif principal d'assurer une intégration réussie de l'erp dans l'entreprise tout en garantissant la qualité de son usage. La proximité de ces experts avec le terrain, la réactivité dans les interventions, une communicationconcertation-coordination de qualité entretenue avec les utilisateurs, l'ajustement et la mutualisation des compétences pour faire face aux dysfonctionnements rencontrés font partie des éléments clés du CC. 5/17

6 Nature dynamique du cc Le CC a la responsabilité de l'animation de groupes de travail pluridisciplinaires sur les processus transverses et joue un rôle important dans la formation des utilisateurs et celui du conseil aussi bien technique que métier. Le CC a en particulier une incidence positive dans la diminution du risque humain, il participe à ne pas laisser les personnes au «bord de la route». La structure CC fonctionne de manière dynamique et en mode réseau, elle peut être composée de plusieurs équipes réparties dans les différents services de l'organisation. Ces équipes, une fois le problème résolu, se dissolvent. Elles peuvent se recomposer en partie ou de manière totalement différente selon l'apparition d'un nouveau besoin. Les va et vient entre la structure CC et les services fonctionnels et/ou opérationnels font que les membres du CC diffusent leurs retours d'expériences dans l'organisation. Le renouvellement périodique des membres du CC par de nouvelles personnes fait que le vivier de compétences existant s'enrichit en permanence et se démultiplie dans les services de manière stimulante. Le CC participe à la mise en œuvre des régulations positives pour créer les conditions favorables à la stabilisation des nouvelles routines et régulations organisationnelles. Dans ce cadre, il aide les utilisateurs dans le nouvel environnement construit autour de l'erp à abandonner les systèmes de relations antérieures et d'en apprendre de nouveaux. La maitrise d'œuvre L'AFNOR définit la maîtrise d' oeuvre comme«une personne physique ou morale qui réalise l'ouvrage pour le compte du maître d'ouvrage, assure la responsabilité globale de la qualité technique, du délai et du coût». La MOE est responsable de la solution jusqu'à sa livraison et de la qualité de la soluution fournie pendant la période de garantie. De plus, elle a un devoir de conseil et d'alerte au sujet des risques pouvant résulter des orientations prises par le chef de projet MOA. La maîtrise d'oeuvre assure notamment les responsabilités suivantes: analyse des besoins de la maîtrise d'ouvrage; proposition d'une ou de plusieurs solutions techniques; identification et planification des tâches à réaliser; définition des moyens humains et matériels nécessaires à la conduite du projet; réalisation de la solution retenue dans la conformité des besoins exprimés et suivi des activités externalisées ; compte rendu au directeur de projet de l'avancement du projet et soumission des éléments à valider; livraison au directeur de projet de la solution testée; déploiement de la solution avec la participation de la MOA (responsabilités partagées). Si elle ne dispose pas en interne des compétences nécessaires, la MOE peut exterrnaliser certaines tâches inhérentes à la réalisation de la solution, voire être représentée par une SSII sélectionnée par la MOA. La MOE est généralement constituée d'un groupe de projet et d'une équipe de conception et de réalisation. Le groupe de projet Le groupe de projet est dirigé par un chef de projet MOE, qui assure les fonctions d'animation au sein de la MOE et de communication avec la MOA, au travers de réunions et/ou de tableaux de bord permettant le pilotage du projet. Il doit disposer d'une réelle expertise technique pour piloter une équipe de conception et de réalisation composée de techniciens et d'ingénieurs en informatique. Cadresonline précise dans ses fiches métiers que «le chef de projet MOE a pour mission d'assurer l'organisation et la mise en place d'un projet informatique avec l'aide de ressources internes et externes à l'entreprise. Les tâches comprennent: le recueil des besoins et la rédaction des spécifications; 6/17

7 la planification des phases de réalisation; la coordination de la maîtrise d'ouvrage et des équipes de développement; la supervision des tests et de la recette; la participation au support de production (documentation, formation); l'animation de réunions avec le client ; le reporting de l'activité. Le chef de projet MOE peut travailler dans une SSII, dans une entreprise utilisatrice ou encore chez un éditeur de logiciels». ( Le groupe de projet a pour principale tâche de gérer les équipes de développement et/ou de paramétrage, internes ou externes. Il organise l'assurance qualité et suit l'avancement et la consommation des ressources du projet. L'équipe de conception et de réalisation L'équipe de conception et de réalisation programme, développe, paramètre la solution. Lorsque ces activités sont confiées à un prestataire externe, il est indispensable qu'une personne de l'entreprise fasse partie du groupe de projet. Les relations entre la maîtrise d'ouvrage et la maîtrise d'œuvre Un des principaux facteurs de succès d'un projet est la qualité de la relation entre la MOA et la MOE. De nombreux dysfonctionnements proviennent d'un manque de communication, de coopération, de coordination et de confiance entre ces deux entités. Pour renforcer la confiance entre les acteurs des deux entités, les principes suivants doivent être respectés: définir avec précision les rôles respectifs de la MOA et de la MOE; doter le projet de structures décisionnelles, fixer un calendrier de réunions (fréquence, thèmes abordés, participants), déterminer les modalités d'arbitrage en cas de conflit; favoriser la communication, la coopération et la coordination en organisant des réunions de travail et des points d'avancement. La MOA doit rester forte et conserver l'orientation stratégique du projet, même si la MOE joue un rôle de conseil. Types de structures (organigramme de l'équipe projet) Facilitateur Aucune ressource n'es dédiée à plein temps au projet. Coordinateur Un seul individu est affecté à plein temps au projet. Il puise dans l'organisation les autres ressources humaines. 7/17

8 Matricielle Un chef de projet est affecté à temps plein au projet. Il puise les autres ressources humaines dans l'organisation. Il s'appuie sur une structure de direction des projets et sur une répartition plus formalisée des temps que consacrent au projet les différents intervenants. Task Force Cette structure s'appuie sur des ressources dédiées. Les intervenants qui travaillent sur le projet sont officiellement extraits des entités de la structure de l'organisation pour être placé sous l'autorité du chef de projet. 8/17

9 Critères de choix Critère Facilitateur Coordinateur Matriciel Task Force Important Important Standard Standard Complexe Forte Moyenne Importante Très faible Moyenne Importante Moyenne Importante Très faible Moyenne Importante Nombre de projets Moyenne Moyenne Criticité des délais Moyenne Importante Différenciation avec les autres projets Importante Moyenne Degré d'incertitude Complexité technologique Taille du projet Importance du projet pour l'organisation Durée Complexité des relations Le cycle de vie d'un projet Le cycle de vie d'un projet est l'enchaînement des phases et des validations nécessaires tout au long du processus, qui débute par l'expression des besoins et se termine par la réalisation du produit final. Le cycle de vie diffère selon les modèles de développement retenus, les projets à conduire et les entreprises qui les pilotent, mais il présente des phases et des étapes clés. Les étapes du cycle de vie Principaux modèles Cascade Fontaine En V En W Incrémental et itératif 9/17

10 Malgré la diversité des projets, différentes phases et étapes clés sont communes à tout projet et nécessitent l'implication de la MOA et de la MOE. Les différentes phases et étapes du cycle de vie d'un projet de SI Phases Étapes Acteurs impliqués Conception générale Étude préalable MOA 10/17

11 Développement Analyse MOA Appel d'offres MOA Conception détaillée MOA et MOE Réalisation MOE Recettage de la solution MOA et MOE Déploiement MOA et MOE Maintenance MOA et MOE Un jalon est un événement important à l'intérieur d'une phase ou en fin de phase. Un événement n'a pas de durée; il correspond au franchissement d'une étape lorsque les exigences fixées préalablement en termes de délais, de coûts, de ressources et de qualité sont remplies. Un jalon permet donc de vérifier que les conditions de poursuite du projet sont réunies. Cycle de vie d'un projet de développement Phases Étapes Nombre de jalons Expression des besoins Étude d'opportunité Portefeuille de projets Planification globale livrables 2 Cahier des charges MOA Rapport d'opportunité initial 2 Rapport d'opportunité mis à jour Plan de projet initial Analyse fonctionnelle Analyse détaillée 2 Plan de projet complété Analyse détaillée Développement et tests Intégration Recettes techniques Recettes fonctionnelles 1 PV de recettes fonctionnelles Déploiement 2 Feu vert de démarrage PV de mise en production Exploitation et maintenance 1 Bilan du projet Avant-projet Initialisation Analyse Réalisation L estimation des charges Notions générales La charge représente la quantité de travail nécessaire indépendamment du nombre de personnes qui seront affectées à la réalisation du projet. Elle s exprime en jour/homme. Un mois/homme est équivalent à 20 jours/homme. Elle permet d obtenir le coût prévisionnel en fonction de la charge estimée et du coût complet d un jour/homme. L unité jour/homme est donc l unité d œuvre pour le calcul analytique du coût du projet. Exemple : pour une durée prévue de 60 mois/homme à 10 K le mois/homme, le coût prévisionnel du projet est estimé à 600 K. La durée du projet dépend du nombre de personnes affectées à sa réalisation (par exemple, une personne pendant 5 ans ou 5 personnes pendant 1 an). Ordre de grandeur de la taille des projets : Très petit projet : <= 6 mois/homme ; Petit projet : entre 6 et 12 mois/homme ; Projet moyen : entre 12 et 30 mois/homme ; Grand projet : entre 30 et 100 mois/homme ; Très grand projet : >= à 100 mois/homme. 11/17

12 Les méthodes d'estimation de la charge Descriptions Méthodes Décomposition Multiplication Analogie Délimitation Pourcentages Cette méthode se fonde sur une estimation descendante. Dans un premier temps, le projet est décomposé en phases. Dans un deuxième temps, les phases sont décomposées à leur tour en activités significatives et évaluables en termes de charge. Ensuite, la charge totale du projet est déterminée avec une majoration de 10 à 20 % pour couvrir la gestion de projet à proprement parler. Cette méthode est utilisée pour les tâches répétitives (par Exemple, le déploiement sur des postes). Cette méthode est basée sur l'expérience en gestion de projet. Cette méthode utilise des minimas et des maximas pour extraire une valeur réaliste. Cette méthode utilise les pourcentages généralement admis par les méthodes structurées (par Exemple, s'agissant du développement interne, selon la méthode HERMES: 5 % pour l'étude préalable, 35 % pour la conception, 55 % pour la réalisation et 5 % pour l'introduction). COCOMO Cette méthode se fonde sur la taille du projet exprimée en lignes (COnstructive de code. COstMOdel) Ces différentes méthodes sont utilisées par les entreprises selon leur expérience des projets à conduire et la nature de ces derniers. En l absence d estimation précise de la charge de travail et de contrôle du travail, on risque de voir apparaître le phénomène décrit par la «loi de Parkinson 1957» : «Tout travail se dilate jusqu à remplir le temps disponible». Les différentes méthodes appartiennent à trois familles : Le jugement d experts qui estime la charge du projet d après leur expérience sur des projets similaires méthode DELPHI ; Les méthodes de répartition proportionnelles : elles sont basées sur l hypothèse que les différents sous-ensembles sont liés par une relation de proportionnalité ; Les méthodes utilisant un modèle : Le modèle Cocomo et sa variante le modèle Diebold ; Le modèle d évaluation analytique ; Le modèle des points fonctionnels. Chacune de ces méthodes a pour point commun de : Construire une base de connaissances sur l expertise de projets antérieurs ; Faire l estimation du projet selon une unité de mesure ; Convertir la taille en charge ; Ajuster la taille en fonction des particularités du projet ; Répartir la taille dans les différentes étapes. La méthode DELPHI Cette méthode fut élaborée en 1948 par la Rand Corporation. La méthode consiste à rechercher des analogies avec des projets antérieurs. Ces projets peuvent être internes ou externes à l entreprise. L analogie prend en compte les facteurs d environnement. chaque expert propose une estimation en utilisant sa propre expérience ; les jugements sont rendus publics, mais restent anonymes. Chaque expert peut alors modifier ou confirmer son estimation ; les nouvelles estimations sont dévoilées et chaque expert peut se justifier ; normalement les experts arrivent à un consensus et cela permet de construire en commun une première analyse du projet. La méthode de répartition proportionnelle Elle s appuie sur le découpage temporel de référence. On utilise généralement la répartition suivante : Étapes Ratios Étude préalable 10 % du total du projet Étude détaillée 20 à 30 % du total du projet Étude technique 5 à 15 % de la charge de réalisation Réalisation 2 fois la charge d étude détaillée Mise en œuvre 30 à 40% de la charge de réalisation 12/17

13 Ces ratios sont issus des expériences positives et négatives de projets. Ces ratios sont à la fois des recommandations et des règles. Ainsi, une étude préalable ne doit pas consommer plus de 10% des ressources du projet. Chacune de ces étapes est découpée en phases (par exemple pour l étude préalable, le découpage donne 3 phases : observation, conception/organisation, appréciation) et chacune de ces phases fait l objet du même principe d estimation (par exemple pour les trois phases ci-dessus : observation : 30 à 40%, conception/organisation : 50 à 60%, appréciation : 10% de la charge d étude préalable). Le modèle Cocomo Proposé en 1981 par B.W BOHEM, le mot Cocomo signifie Constructive Cost Model c est-à-dire modèle de construction des coûts. Elle repose sur deux hypothèses : Un informaticien sait plus facilement donner une évaluation de la taille du logiciel à développer que faire une estimation du travail nécessaire ; Il faut toujours le même effort pour écrire un nombre donné de lignes de programme quel que soit le langage de troisième génération employé. Ces deux hypothèses ont permis à l auteur de calculer des coefficients de corrélation entre la taille du logiciel et la charge consommée à partir d observation sur une certaines de projets réalisés. L unité d œuvre est l instruction source. Il faut donc disposer du nombre estimé de lignes de programme du programme source. Ce modèle permet d obtenir la charge de réalisation en mois/homme. Les formules de calcul de la charge et du délai sont les suivantes : Charge en mois/homme = a (kisl) b Délai normal en mois = c (charge mois/homme) d Avec : kisl = nombre de milliers d instructions source livrées. Les paramètres a, b et c varient selon la taille du projet. D après l expérience les valeurs sont les suivantes : Type de projet Charge en mois/homme Délai en mois Simple Charge = 3,2 (kisl) 1,05 D = 2,5 (charge mois/homme) 0,38 Moyen Charge = 3 (kisl) 1,12 D = 2,5 (charge mois/homme) 0,35 1,2 Complexe Charge = 2,8 (kisl) D = 2,5 (charge mois/homme) 0,32 Ces valeurs «brutes» sont ensuite corrigées en fonction des caractéristiques du projet. La charge du projet est ainsi multipliée par un facteur correcteur. Ces corrections sont dues à quatre sources de risque : Logiciel Projet Matériel Personnel Fiabilité Utilisation d une méthode Taille mémoire Compétence des concepteurs Base de données Utilisation d un AGL Stabilité de l environnement Expérience des concepteurs Complexité Contrainte de délai Disponibilité de la machine de test Compétence des développeurs Temps d exécution Connaissance de l environnement technique Expérience du langage La démarche pour l utilisation du modèle Cocomo se déroule ainsi en 5 étapes : Estimation du nombre d instructions sources ; Calcule de la charge brute ; Sélection des facteurs correcteurs ; Application des facteurs correcteurs pour obtenir la charge nette ; Évaluation du délai normal. La méthode d évaluation analytique Elle s appuie sur une typologie des programmes à développer. Les unités d œuvre sont donc les différents types de programmes. La typologie est permanente mais les poids affectés aux unités d œuvre varient en fonction de l environnement et de l équipe de développement. Type de transaction Menu Consultation Mise à jour Édition en temps réel Type de programme par lots Extraction Mise à jour Édition Facile 0,25 1 1,5 1 Facile 0,5 2 1,5 13/17 Moyen 0,5 2,5 3 2 Moyen 1 3 2,5 Difficile Difficile 1,5 5 4

14 Les poids standards sont en jour/homme. On fait une estimation du nombre de programmes à réaliser en les ventilant par nature en fonction de la demande du client (cahier des charges ou dossier de spécification). La charge calculée à l aide des poids ci-dessus, appelée charge de réalisation, comprend la programmation, l élaboration des jeux d essai de test et la mise au point des programmes. Pour obtenir la charge totale, il faut rajouter le temps pour les tests d enchaînement et pour l encadrement (respectivement 10 et 20% de la charge de réalisation). Le temps minimum incompressible de réalisation du projet est donné par la formule : Délai = 2,5 * charge en mois homme 1/3 La méthode des points fonctionnels L auteur est Alan Albrecht en 1979, salarié d IBM. Cette méthode a d abord été diffusée dans les entreprises clientes d IBM puis adopté par la suite par de nombreux professionnels grâce à la constitution d association d utilisateurs. Le principe est de faire une estimation de la charge par rapport à la description externe du projet, de ses fonctions. On identifie cinq types d unités d œuvre et trois degrés de complexité. A chaque degré et à chaque type, on affecte un nombre de points. La méthode permet de calculer pour un projet donné son poids en points de fonction. Différentes règles permettent ensuite de passer des points de fonction à la charge de travail du projet. La démarche comporte trois étapes : Calcul de la taille : dénombrement des différents composants fonctionnels et de leur degré de complexité. Cinq types de composants servent d unités d œuvre : deux relatifs aux données : 1. groupe logique de données internes (GDI) : correspond à une entité ou à une association porteuse de données dans une modèle Entité / Association ; 2. groupe logique de données externes (GDE) ; et trois relatifs aux traitements : 1. entrée (ENT) ; 2. sortie (SOR) ; 3. interrogation (INT). Ajustement de la taille : on ajuste les points obtenus en fonction de la spécificité du produit (système distribué, performance, réutilisation du code, convivialité, etc.) au total 14 facteurs de pondération ; Transformation des points de fonction en charge : elle est différente selon l environnement et le facteur humain. Différentes formules ou études sont utilisées. Le cabinet Butler-Cox a ainsi estimé que l utilisation d un L4G donne 1 jour de charge pour 10 points. Les paramètres d'un plan d'assurance et contrôle qualité Paramètres Définitions Fiabilité Aptitude avec laquelle le SI fonctionne sans défaillance pour une durée donnée (robuste, constant, etc.) Efficacité Aptitude avec laquelle le SI fonctionne avec un optimum de ressources et de temps Sécurité (Intégrité) Convivialité Réutilisabilité Interopérabilité Portabilité Aptitude avec laquelle le SI est protégé contre les altérations ou les accès non autorisés Effort requis pour l'apprentissage et le dialogue homme/machine et la documentation Aptitude avec laquelle le SI peut être utilisé dans de multiples applications Aptitude avec laquelle le SI peut communiquer ou interagir avec d'autres systèmes Effort requis pour le transférer d'un environnement à un autre. La portabilité peut être vue sous ses deux aspects : 14/17 Critères y contribuant Disponibilité Robustesse Sécurité Bonne utilisation des ressources machines (mémoire, etc.) Disponibilité Intégrité Confidentialité Ergonomie Facilité d'utilisation Facilité d'apprentissage Modularité Indépendance logiciel et matériel Niveau de paramétrage Compatibilité Interfaçage Modularité Indépendance logiciel et matériel

15 Paramètres Définitions Critères y contribuant intégrable sur d'autres systèmes d'exploitation; intégrable sur d'autres machines. Effort requis pour s'assurer de son bon fonctionnement (jeu d'essais et vérification de résultats) Effort requis pour localiser et corriger une erreur (lisibilité, traçabilité, accessibilité, etc.) Effort requis pour l'amélioration, à spécifications inchangées, ou pour le modifier afin de répondre à de nouvelles versions du système d'exploitation Testabilité Corrigibilité Adaptabilité Automatisation des tests Facilité d'analyse des résultats Qualité de la documentation Traitement des erreurs Perfectibilité Flexibilité Modularité Niveau de paramétrage Le PACQ peut prévoir un paragraphe précisant les mesures de la qualité (propriété et métrique). Il décrit ainsi les paramètres retenus pour définir les objectifs et les engagements qualité. Il est à adapter en fonction des spécificités du projet. Exemples de paramètres de qualité applicables à un projet Paramètres Engagements qualité Propriétés Disponibilité Fiabilité Sécurité Garantir la fiabilité du système Livrer chaque version du système avec un minimum d'anomalies Garantir la sécurité du système et la Utilisation et intégrité confidentialité des des données informations traitées Maintenabilité Assurer la mainte nabilité et la réversibilité du système Corrigibilité Garantir la réactivité requise en cas de demandes de modification Efficacité Convivialité Métriques Indisponibilité du système, relative à une anomalie, inférieure à 8 heures cumulées par trimestre Aucune anomalie bloquante recensée dans les versions diffusées auprès des utilisateurs Les bases réelles ne devront pas être utilisées pour les tests. À chaque version, l'ensemble de la Lisibilité, exhaustivité et documentation technique est conforme, cohérence de la exhaustive et cohérente avec la version de documentation référence du système, avec un taux technique associée à maximum de 5 % par rapport à une liste de chaque version contrôle. Taux de satisfaction Les trois quarts des personnels concernés des équipes lors de doivent considérer cette prestation comme l'exécution d'opérations correctement exécutée. de réversibilité Respect du délai de Livraison des versions intermédiaires selon correction des délai arrêté Livraison des versions anomalies bloquantes semestrielles selon délai arrêté, avec [... ] Respect du délai de traçabilité totale entre les demandes de livraison pour les modification et les modifications réalisées versions semestrielles Conduite de projet PGI Spécificité de la démarche généralités importance stratégique pour l'entreprise impacter la gestion de tous les processus représente un cout très important de manière directe ou indirecte engage l'organisation sur le long terme Critères de réussite Bien connaitre les besoins de l'organisation mener une analyse préalable définir précisément les règles de gestion à mettre en place 15/17

16 définir précisément les changements organisationnels souhaitables rechercher un PGI adapté aux besoins vérifier l'usage dans le secteur d'activité vérifier l'usage dans les organisations d'organisation de taille et fonctionnement comparable définir le paramétrage à mettre en place avec l'aide de l'intégrateur mesurer les besoins d'adaptation mutuelle Méthode de déploiement Architecture Client Serveur ou n-tier Utilisation des Bases de données relationnelles modules applicatifs orientés gestion des processus opérationnels et Outils d'aide à la décision Analyse du risque nécessité de gérer la conduite du changement organisationnel critères de mesure du risque taille maitrise des techniques degré d'intégration durée stabilité de l'équipe projet Le contenu d'un projet ERP «Quelles sont les principales différences entre un projet ERP et un projet de développement classique? Nous en citons ici les principales: Tout d'abord, il faudra mener une évaluation rigoureuse à la fois des besoins de l'entreprise et de l'offre d'une première sélection de différents progiciels présents sur le marché, ce afin de choisir le produit. L'analyse des processus devra être extrêmement approfondie, car elle permettra de définir les bases du paramétrage du progiciel. Ce paramétrage est le cœur opérationnel du projet. Des équipes de paramétrage seront donc constituées, avec un profil et des compétences spécifiques; elles intègrent souvent des consultants, l'entreprise ne disposant pas en général d'une ressource suffisante en interne. La principale tâche des informaticiens sera de réaliser l'intégration du progiciel (reprise des données pour initialiser le système, interfaces avec l'existant). Dans certains cas, on leur demandera également de programmer des modules complémentaires pour combler les «trous fonctionnels» du progiciel. Compte tenu de l'étendue des projets, une réflexion particulière doit être accordée au déploiement: le projet ERP concerne souvent plusieurs activités et/ou plusieurs sites (filiales). Il faudra planifier l'organisation et le rythme des mises en œuvre. Si l'on fait le bilan de ces différents points, il apparaît clairement que le projet ERP va demander une plus grande implication aux utilisateurs et à leur management: ceux-ci seront en effet leaders du projet tant dans la phase de choix du produit que dans celle de l'analyse des processus, du paramétrage et du déploiement. Dans un projet de développement spécifique classique, le leadership était sans conteste celui des informaticiens; dans les nouveaux projets de développement, on peut parler d'un partenariat étroit; mais dans les projets ERP, la responsabilité et l'effort opérationnel basculent clairement dans le camp des utilisateurs. Les étapes d'un projet ERP Jean-Louis Tomas identifie douze phases dans l'implantation d'un ERP : 16/17

17 La planification revêt une importance particulière du fait de l'étendue des projets ERP. Elle va permettre de découper le projet en étapes, tâches, livrables l, accomplies par les différents acteurs et permet ainsi de faire le suivi du projet. L'analyse opérationnelle correspond à l'étude des processus élémentaires et de leur évolution. La formation des équipes permettra d'informer et de former quatre groupes intervenant sur le projet: le management, le comité de pilotage du projet, les équipes de mise en œuvre (qui feront le paramétrage) et les équipes d'infrastructure technique (informaticiens ). L'adéquation et la configuration visent à définir comment implanter les principaux processus dans l'erp et à paramétrer ceux-ci afin d'obtenir un premier prototype. Les simulations en taille réelle vont permettre aux acteurs d'affiner le paramétrage en testant le fonctionnement, la cohérence et l'ergonomie des choix effectués. La fermeture des trous fonctionnels pose la question des fonctionnalités non couvertes en standard par le produit: il faudra déterminer dans quels cas l'entreprise peut s'adapter au produit, pour éviter des modifications spécifiques et, si c'est impossible, faire réaliser par les informaticiens des modifications spécifiques, compatibles avec l'erp. Ces derniers effectueront également la création de liens avec l'environnement, c'est-à-dire la reprise des données et les interfaces avec les systèmes existants. La documentation utilisateur décrit les procédures opérationnelles mises en œuvre dans l'erp ainsi que les modifications spécifiques éventuelles. La formation des utilisateurs consistera à identifier des profils d'utilisation et à organiser des sessions de formations adaptées aux besoins des différents profils. Enfin, on pourra envisager la mise en production, qui ne sera qu'une étape avant le déploiement sur d'autres sites ou d'autres activités... Au total, le projet ERP pourra s'étendre sur plusieurs mois, voire une ou deux années. En pratique, l'entreprise devra également passer par une longue phase d'apprentissage opérationnel afin d'intégrer le nouveau fonctionnement et de bénéficier des avantages de l'erp.»(in Management des SI MH DELMOND, Y PETIT, JM GAUTIER Dunod 2007) 17/17