Conduite de projets informatiques

Transcription

1 Conduite de projets informatiques Développement, analyse et pilotage Brice-Arnaud GUÉRIN 3 ième édition Nouvelle édition

2 Table des matières 1 Les exemples à télécharger sont disponibles à l'adresse suivante : Saisissez la référence ENI de l'ouvrage DP3CPR dans la zone de recherche et validez. Cliquez sur le titre du livre puis sur le bouton de téléchargement. Avant-propos 1. Objectifs du livre Structure du livre Chapitre 1 Un projet informatique 1. Les enjeux Les buts d'un projet Les protagonistes d'un projet Exemples de projets Les moyens et les ressources Les moyens techniques Les postes de développement Les serveurs de documentation de projet Les autres types d'équipements Les moyens financiers Les moyens généraux Les ressources humaines Les contraintes Le cahier des charges La maîtrise des coûts La maîtrise de la qualité La maîtrise des délais La matrice d'ajustement Le cadre d'un projet Les objectifs de la conduite de projet

3 2 Conduite de projets informatiques Développement, analyse et pilotage 6. Trois exemples de projets Mise en œuvre d'un CRM Contexte Besoin exprimé Cadre du projet Les enjeux du projet Développement d'une application de pilotage d'activité Analyse de la situation et perspectives Résumé des exigences Dotation et contraintes Les enjeux du chef de projet Création d'un site de vente en ligne Des moyens conséquents au service d'un projet unique De la stratégie au plan projet Les enjeux d'une équipe Chapitre 2 Les aspects financiers 1. La structure de coût d'un projet Les salaires et prestations de réalisation Des grilles de coûts Négocier les coûts journaliers en régie Négocier les prestations au forfait Le plan de charge financier Les prestations d hébergement Les modes d'hébergement Le plan de charge financier Les prestations d exploitation et de maintenance Les prestations de support aux utilisateurs Les coûts refacturés Les coûts non liés à l informatique Les budgets Constitution des budgets

4 Table des matières Les indicateurs liés aux budgets Le compte de résultats (Profit And Loss) Le modèle économique Licence et maintenance L'abonnement (SaaS) Le modèle transactionnel (Pay as you go) La projection financière Les flux de trésorerie L'analyse financière Les indicateurs clés VAN, TRI, break even Le business case La proposition de valeur Le top line financier L'executive summary Le suivi financier des projets Les comptes rendus d activité La reconnaissance du chiffre Étude financière du site de vente en ligne Structure de coûts et budgets estimés Budget d'investissement CAPEX (capital expenditure) Budget de fonctionnement OPEX (operational expenditure) Business case et P&L Résumé exécutif Proposition de valeur Prévisions de ventes Analyse financière sur trois ans Résumé financier Scénarios de suivi financier Budget d'investissement CAPEX Identification d'économies sur le budget de fonctionnement OPEX Révision du P&L

5 4 Conduite de projets informatiques Développement, analyse et pilotage Chapitre 3 La prise en compte du risque 1. Les trois axes Le modèle de développement Le modèle cascade Le modèle en V Le modèle itératif Le modèle RAD Le modèle Extreme Programming Le modèle RUP (Rational Unified Process) Le modèle d'analyse Le principe de modélisation en analyse L'exemple du dictionnaire de termes L'exemple des figures géométriques Le modèle Merise Le modèle UML Le modèle de pilotage Les faits relatifs au projet Les indicateurs clés de performance (KPI) Indicateurs relatifs au planning Indicateurs relatifs à la qualité Indicateurs relatifs à la roadmap Indicateurs financiers Indicateurs relatifs à l'équipe Indicateurs liés au risque Le pilotage du projet Décisions sur l'issue du projet Décisions sur le contrôle du projet Conduite de la communication Constitution de la base de connaissances Prendre en compte le risque L'analyse des risques

6 Table des matières Les classes de risques L'identification des risques La caractérisation du risque Le plan de risques Les stratégies de gestion du risque Choisir le modèle de projet en fonction du risque Étude du risque pour le projet de CRM Analyse des risques La faisabilité du projet La disponibilité des ressources La dimension personnelle Des aspects informatiques et techniques Facteurs de réussite du projet Plan de gestion des risques L'évaluation des risques La conduite du risque Choix des modèles Chapitre 4 Démarrer un projet 1. Le point de départ L appel d offres Les documents constitutifs d'un appel d'offres Les dispositions réglementaires La demande directe Les premiers choix Le cadrage du projet Le contexte L'objet Un exemple de cadrage L analyse préalable Le recueil des informations disponibles Conceptualisation de la solution

7 6 Conduite de projets informatiques Développement, analyse et pilotage La restitution (project master plan) L organigramme des tâches Une approche générale Les unités d'œuvre propres au modèle cascade Les unités d'œuvre du cycle en V Les contributions du modèle itératif La structuration du projet Le dimensionnement du projet La charge totale en jours.homme L'effectif participant au projet Les écueils habituels liés au chiffrage La maîtrise d ouvrage La maîtrise d œuvre La constitution de l équipe La distribution académique des rôles Les configurations à privilégier et celles à éviter L externalisation des ressources L outsourcing La délocalisation (développement offshore) La sous-traitance Les équipes transversales Macroplanning L'initialisation (kick-off) La plate-forme technique Démarrer le projet de pilotage d activité Cadrage du projet Contexte Objet Structuration Expression de besoins Organigramme des tâches (WBS) et estimation des charges Dimensionnement

8 Table des matières Analyse des risques Choix des modèles Macroplanning et initialisation Chapitre 5 L'analyse 1. Le domaine métier Les bases de données relationnelles Les tables Les clés et les relations Les vues et les requêtes Les traitements et les procédures stockées Les autres types de bases de données Les bases de données hiérarchiques (XML) Les bases de données objets Les bases de données semi-structurées Le modèle d analyse Merise Les modèles de délimitation du système Le modèle conceptuel de données MCD Le modèle logique de données MLD Le modèle physique de données MPD Les outils de modélisation Le périmètre fonctionnel Les processus et les flux de travail (workflows) La cartographie fonctionnelle Le modèle d analyse UML Les modèles de délimitation du système Les modèles associés aux diagrammes de classes Les modèles de description logique et technique Les outils de modélisation Le contexte technique en phase d'analyse Les outils de recherche d'information Le langage SQL

9 8 Conduite de projets informatiques Développement, analyse et pilotage Les langages LINQ et HQL Les langages XPath et XQuery Les outils de structuration d'application (design pattern) Motifs de structuration logique Motifs de structuration technique La documentation de projet Le cahier des charges Le contenu d'un cahier des charges Élaborer un cahier des charges Les référentiels de spécifications Le dossier d intégration fonctionnelle (DIF) Le dossier d intégration technique (DIT) Les spécifications détaillées Les normes de développement L'analyse du projet de pilotage d'activité Le dossier d'intégration fonctionnelle Le dossier d'intégration technique Chapitre 6 Les référentiels techniques 1. Les problématiques d intégration Les développements spécifiques Les progiciels et l intégration d applications d entreprises (EAI) Le modèle fonctionnel Le modèle technique Les architectures distribuées Le découpage en couches Les composants distribués Les architectures orientées services (SOA) Les middlewares orientés message (MOM) Les services web

10 Table des matières Les services web AJAX et le modèle REST Les plates-formes types Les généralistes J2EE et.net Java et J2EE Windows et.net Les serveurs de bases de données SQL Les environnements décisionnels et les infocentres Les serveurs intégrés ERP, CRM, CMS Les serveurs d'intégration (EAI) Les serveurs virtuels De l'asp au cloud computing L'accès locatif aux applications Le client mobile : du portable à la tablette L'infrastructure à la demande Chapitre 7 Le développement du projet 1. La maîtrise de la qualité du code Les normes de codage L'indentation Les noms dans les programmes La notion de modularité La gestion de la documentation Les commentaires La documentation générée Les régions Les revues de code Définir les règles de codage Utiliser des outils de contrôle durant le codage Préparer une revue de code Effectuer une revue Les outils d'analyse et de couverture

11 10 Conduite de projets informatiques Développement, analyse et pilotage 1.5 Les référentiels de code source Installation du serveur et création d'un référentiel Création d'un projet lié au référentiel Extraction et archivage de fichiers Gestion des historiques Opérations avancées La gestion des versions Production d une version Les numéros de version Les release notes Montée de version L intégration continue Les tests Tests unitaires Tests d intégration Tests fonctionnels Boîte noire Boîte blanche Le banc d'essais (benchmark) Tests de charge et de performances Tests de stress et de montée en charge Tests d'endurance Tests aux limites Les méthodologies de test Cycles de test Le plan de tests Stratégie de tests descendants Stratégie de tests ascendants Tests de non-régression L'utilisation d'un logiciel de suivi, activité et bug tracking Installation et paramétrage d'un outil Création de projets et de versions Enregistrement de défauts (bogues)

12 Table des matières Établissement de rapports L industrialisation La configuration L installation ou setup Les tests de déploiement et de mise à jour Le développement du projet de pilotage d activité Organisation du développement La gestion du code source et des éléments de travail La documentation Les revues La production des versions La mesure de l'avancement du développement Organisation des tests La préparation des scénarios de tests Les tests automatisés La non-régression Les jeux d'essais La planification des tests La gestion des anomalies Les statistiques utiles Le déploiement La préparation des environnements Les procédures de déploiement Les mises à jour Chapitre 8 La planification et le chiffrage 1. L estimation des charges Les charges et les délais L'estimation par abaque L'estimation analytique L'estimation imposée

13 12 Conduite de projets informatiques Développement, analyse et pilotage 2. L emploi du temps du chef de projet Les charges d'encadrement Les tâches d'organisation La gestion des ressources Le plan de charge La montée en charge et la disponibilité La surcharge La planification Les éléments d'un planning Les unités d'œuvre et les tâches Les jalons (points de phase) Les dépendances entres les tâches et les contraintes Les ressources Le calendrier La création du planning Le recensement des tâches Le recensement des ressources La définition de l'horizon temporel L'identification du plan de charge La constitution du planning à partir du plan de développement La représentation des plannings Le diagramme de Gantt Le diagramme PERT Le chemin critique Les outils de planification La planification du projet de pilotage d activité Différentes estimations Estimation selon la méthode des points fonctionnels Estimation par abaque Estimation ad hoc Le planning du projet Analyse des périodes critiques

14 Table des matières 13 Chapitre 9 Le suivi et le pilotage 1. Le suivi de projet Le compte rendu d activité L'avancement des tâches L'évolution du planning Les réunions de projet Les réunions d'équipe Les sessions de spécification ou d'analyse Les séances de briefing et de formation Les coups d'envoi (kick-off) La centralisation de la documentation La gestion des imprévus Les complications techniques Détection et diagnostic Les causes possibles Les solutions La base de connaissances Les conflits Les types de conflits Les techniques de résolution Les aléas organisationnels Retards Qualité médiocre des livraisons Communication défaillante Le comité de pilotage Les règles de pilotage Les réunions de pilotage Les modifications de planning L'allocation de ressources L interruption ou l arrêt d un projet

15 14 Conduite de projets informatiques Développement, analyse et pilotage 4. Terminer un projet La livraison Les livrables Les modalités de livraison La réception et la recette La gestion du changement Le pilote La formation Le support La maintenance Suivi du projet de pilotage d activité Organisation et suivi des réunions de projet Les réunions daily standup meetings Les réunions d'avancement Quelques imprévus Les réunions de 30 minutes s'éternisent Démarrage trop tardif de tâches sans alerte La charge des testeurs en dent de scie Suivi du projet par le comité de pilotage Quand le projet vire à l'orange La malédiction des données de production Le go live Le processus de lancement L'adhésion au nouvel outil Le bilan Glossaire Index

16 67 Chapitre 3 La prise en compte du risque 1. Les trois axes La prise en compte du risque Le chef de projet en devenir est parfois perplexe face au nombre des éléments qu'il doit organiser pour aboutir. Dans quelle direction partir? Par quoi commencer et comment continuer? Pour répondre à ces questions, il faut d'abord se représenter le processus du projet tel que nous l'avons décrit au chapitre Un projet informatique. Cette fois-ci, nous choisissons un espace structuré par trois axes, le temps (cycle de vie), l'analyse et le pilotage. Chaque dimension de cet espace correspond elle-même à une méthode plus ou moins standard, et qui donnera lieu à un processus que le chef de projet devra suivre.

17 68 Conduite de projets informatiques Développement, analyse et pilotage Le premier axe (en abscisse horizontal) est celui qui décrit les phases du projet, tel que l'on peut le préfigurer. Le schéma ci-dessus propose un modèle de développement assez standard, partant de l'expression des besoins, évoluant jusqu'à la livraison (production) et la maintenance du projet. En toute rigueur, on devrait introduire la mort du projet, car nous savons que le cadre support n'est pas infini. Nous le verrons par la suite, d'autres modèles de développement existent et proposent des organisations différentes. Vient ensuite l'axe d'analyse (en ordonnée, vertical). Il indique le niveau d'abstraction du projet. Plus l'ordonnée est haute, plus grande est l'abstraction. Inversement, une faible ordonnée équivaut à un niveau de détail très important. Dans l'exemple figurant sur le schéma, on voit nettement l'abstraction grandir au début du projet avant de redescendre progressivement. Ce type de courbe est assez caractéristique des méthodes d'analyse basées sur UML (Unified Modeling Language) et Merise. Là encore, d'autres schémas sont envisageables et ils traduisent d'autres façons de procéder. Editions ENI - All rights reserved

18 La prise en compte du risque Chapitre 3 69 Sur le dernier axe sont représentés les aléas, les points de contrôles, les prises de décision... Il s'agit de l'axe de pilotage (cycle de décision). Par rapport aux deux autres axes, c'est celui qui réserve le plus de "surprises", mais il ne faudrait pas non plus le laisser totalement libre. Des méthodes se sont forgées au fil des projets pour organiser le pilotage de manière méthodique et efficace. Ainsi le "secret" du démarrage d'un projet résiderait-il dans le choix des méthodes associées à chaque dimension? Ce n'est pas tout à fait suffisant, car il faut encore s'assurer d'un mélange harmonieux de ces trois composantes, d'une communication efficace, bref d'un sens pratique sans lequel les meilleures recommandations du monde resteront vaines. Autrement dit, l'application isolée, cloisonnée, d'une méthode sur un seul axe ne donne pas de meilleurs résultats qu'un projet dans lequel on oublierait l'existence des autres axes. Le tableau suivant donne un aperçu du résultat lorsque les méthodes sont appliquées seules (indépendamment les unes des autres) ou lorsqu'elles font défaut : Méthode/axe Développement Analyse Application seule ou indépendante En général, la méthode d'analyse est censurée ou ne donne aucun résultat probant. Vision beaucoup trop conceptuelle ; le projet devient techniquement risqué car les tests d'intégration sont oubliés. Non application (absence) Non-conformité (l'expression des besoins est prise en compte tardivement). Dérive du projet (difficulté à stabiliser la solution par manque de tests). Non-conformité (focus sur des fonctions mineures, alors que les fonctions majeures manquent). Code non optimal entraînant des difficultés à le faire évoluer (pas de factorisation).

19 70 Conduite de projets informatiques Développement, analyse et pilotage Méthode/axe Pilotage Application seule ou indépendante Inadéquation du pilotage par rapport aux caractéristiques du projet. Non application (absence) Non tenue des objectifs, manque de contrôle. Explosion de l'équipe projet en cas de montée en charge. Conduite du changement inexistante : rejet de l'application livrée. Ce tableau récapitule donc six constructions (antipatterns) qu'il convient absolument d'éviter. Et pourtant, les occasions de se tromper ne manquent pas, soit parce que les habitudes ont la vie dure, soit parce qu'une nouvelle méthode n'est pas toujours à même de s'intégrer facilement dans le paysage d'un référentiel de conduite de projets. Remarque Les exemples d'achoppement sont légion. Le chef de projet doit toujours garder en tête que les trois composantes sont indispensables, et qu'elles doivent coopérer pour être efficaces. 2. Le modèle de développement Le modèle de développement constitue l'un des premiers choix que doit effectuer le chef de projet. Il façonne de manière explicite l'organisation temporelle du projet et a une grande influence sur le résultat final. Il n'y a pas de bon et de mauvais modèle, du moins parmi les grandes classes dont l'énumération suit. Cependant, chaque projet a des caractéristiques qui rendent l'application d'un modèle judicieuse ou au contraire inefficace. Editions ENI - All rights reserved

20 La prise en compte du risque Chapitre Le modèle cascade On l'appelle aussi modèle linéaire ou modèle nominal. C'est certainement le modèle le plus simple, ce qui ne le déprécie pas pour autant! Dans ce modèle chaque étape suit la précédente, sans autre nécessité que "d'attendre" son issue ; dès que l'expression des besoins est terminée, les spécifications sont écrites. Au terme de ce travail, le développement est réalisé jusqu'à son achèvement. Les tests unitaires s'enchaînent, et ainsi de suite. Avant d'expliquer l'appellation cascade, intéressons-nous aux différentes étapes prévues par ce modèle. Idée - démarrage Expression des besoins Spécifications Développement C'est le point de départ du projet, le moment où les conditions matérielles sont remplies, et où la vision du projet est partagée par l'équipe. Après la décision d'enclencher un projet, on refait le tour des utilisateurs pour recueillir plus en détail leurs exigences fonctionnelles. Ces requêtes sont consignées dans un classeur (papier ou tableur), identifiées, et finalement regroupées ou recoupées. L'ensemble des requêtes est considéré selon différentes approches dictées par le modèle d'analyse : importance, priorité, difficulté technique, risques... Il ressort des spécifications un découpage technico-fonctionnel de l'application. Les spécifications sont traduites en code, en projetant le découpage modulaire (composants) sur la plate-forme choisie par l'architecte.