Concours EXTERNE d ingénieur des systèmes d information et de communication. «Session 2009»

Transcription

1 Concours EXTERNE d ingénieur des systèmes d information et de communication «Session 2009» Meilleure copie "Rapport Technique" Thème : conception et développement logiciel Note : 15,75/20 Rapport technique : Gestion de projet Estimation des charges de développement et adaptation aux services d exploitation informatique A l attention des chefs de projet de développement d applications. Diffusion : Direction informatique et directions des utilisateurs. I. Gestion de projets de développement informatique Avant de traiter de l organisation, des méthodes, des acteurs d un projet de développement d application, il convient de définir la notion de "projet" ou de "mode projet". Le développement d une application (refonte ou nouveau besoin) spécifique à un métier bien identifié nécessite des actions (préparation, réalisation, ). Lorsque ces actions sont positionnées dans un cadre de délais et de budget fixes, on parle de projet. Ce dernier possède ainsi son propre bilan comptable. Le projet débute par une expression de besoin qui sera mise en œuvre puis validée ; cela par des entités, des personnes voire des sociétés différentes. Là est une des difficultés de bien gérer un projet. Quelques exemples de projets : - déploiement d un portail applicatif sur un intranet - création d une base de connaissance - développement d un outil de gestion des stocks et de planification des commandes L applicatif en lui-même représente un des "livrables" attendus (i.e. un résultat tangible). a. Acteurs et responsabilités On distingue deux grandes entités lorsque l on parle de gestion de projet. La première qui est à l initiative du projet est désignée sous le nom de maîtrise d ouvrage (ou MOA). Elle exprime le besoin des utilisateurs finaux de l application et porte la responsabilité des choix en termes de fonctionnalités. La seconde entité est la maîtrise d œuvre, qui a la charge de réaliser l application. Si les choix techniques et technologiques lui incombent, le maître d œuvre (ou MOE) ne doit pas influer (modifier, ajouter, supprimer) sur les fonctionnalités demandées par la maîtrise d ouvrage. Il est vital pour le projet que le périmètre de chaque entité soit respecté. Ce qui n empêche pas, au contraire, une communication très importante entre les deux parties, par le biais de compte-rendus et de réunions régulières (hebdomadaires, si possible). De plus, l échange entre MOA et MOE ne doit pas s arrêter au cahier des charges, le document contractuel associé au projet. 1

2 Ce cahier des charges réalisé par la maîtrise d ouvrage exprime le besoin de manière simple pour permettre à la maîtrise d œuvre de réaliser une application en adéquation avec ce qui est attendu. De même, il garantit à la MOA que le logiciel réalisé sera conforme, et à la MOE qu aucun développement complémentaire et inopportun ne sera demandé. Le cahier des charges doit contenir : - le contexte du projet - les objectifs - le vocabulaire associé - le périmètre du projet - un calendrier prévisionnel - des clauses juridiques (prestation externe). A ce dernier sujet, il est conseillé de définir de nombreux jalons de vérification (auxquels peuvent s adjoindre des paiements en cas de refacturations internes ou de prestations externes) afin d éviter l effet tunnel et de mauvaises surprises souvent trop tardivement décelées. b. Organisation et méthodologie projet Afin d assurer la rentabilité, l efficacité ou même l aboutissement d un projet, il est indispensable de mettre en place une méthodologie (et un vocabulaire) commune à tous les intervenants. Ainsi, un chef de projet est nommé pour chaque entité (MOA et MOE) pour faciliter la communication. Par la suite et pour distinguer ces deux postes, le chef de projet MOA sera appelé directeur de projet. Un directeur de projet prend en charge un projet initié par le comité directeur qui réalise un schéma directeur dans lequel va s inscrire le projet. Il est important de prendre conscience que le projet en question a sa place dans un tout homogène et ne vit pas seul. Le schéma directeur est constitué de projets terminés, en cours ou à venir. Lorsqu un projet s initie, le comité directeur crée un comité de pilotage qui répondra de l avancement du projet, nomme un directeur de projet et planifie une date d initialisation projet, amorçant ainsi le cycle de vie du logiciel. c. Cycle de vie du logiciel Le cycle de vie du logiciel ou cycle de vie du projet passe par trois phases successives. - La première phase dite "préparatoire" valide l opportunité et la faisabilité du projet. C est également dans cette phase que sont exprimés les besoins en fonctionnalités, déclinés en études fonctionnelles (qui donneront naissance au cahier des charges fonctionnel) et une étude technique proposant une architecture logicielle d implémentation. - La seconde phase est la "réalisation" proprement dite de l application. Une planification détaillée est réalisée à l aide de diagrammes de Gantt. Un suivi opérationnel tout particulier doit être effectué par la maîtrise d œuvre. Néanmoins, la MOA doit rester proactive pour vérifier que le développement se fasse dans le sens qui est attendu et qu aucune incompréhension n ait provoqué une réalisation inattendue. Les premiers tests dits "unitaires" sont réalisés dans cette phase. - La troisième et dernière phase est celle de mise en œuvre de l application, en aval des développements. Cette phase est découpée en trois étapes : deux étapes de tests et validation que sont la qualification et la recette, et une troisième étape cruciale qu est la mise en production. Cette dernière correspond au lancement final de l application (d abord sur sites pilotes, puis sur tous les sites) et doit impérativement être précédée d une conduite du changement afin de préparer les utilisateurs à leur futur nouvel outil. Une conduite du changement bâclée ou inexistante peut conduire à l échec d un projet 2

3 mené de manière exemplaire jusque là ; uniquement par le refus des utilisateurs d utiliser le logiciel. Enfin un bilan global du projet doit permettre de dégager des axes d amélioration sur la méthodologie et l organisation mises en place. II. Outils d estimation de charge de développement L estimation des charges associées à un projet de développement est une tâche sensible car d elle va dépendre le coût du projet, et difficile car assujettie à de nombreux aléas. Nous allons étudier dans ce chapitre deux méthodes très rependues d estimation, puis nous étudierons l adaptation de ces méthodes à notre administration. Enfin, nous mettrons en exemple un scénario de déplacement. a. Concepts et possibilités 1. Le modèle COCOMO Ce modèle qui date des années 1970, a pour objectif de déterminer de manière non subjective l effort et le temps de développement nécessaires à la réalisation d une application. Il divise les projets en trois grandes catégories de logiciels suivant leur complexité : - Les applications de type "S" qui sont de faible complexité, dites déterministes, dont l ensemble des cas de tests est facilement identifiable. - Les applications de type "P", plus complexes mais qui restent déterministes. - Les applications de type E, encore plus complexes qui ne sont pas déterministes. Une analyse préalable en début de projet doit permettre de déterminer le type d application. Ensuite, COCOMO applique trois modèles d estimation : - Le modèle de base ne prend en compte que le nombre de lignes de codes estimé, qui est ensuite ventilé selon les activités. - Le modèle intermédiaire ajoute des facteurs de coûts plus complexes pour affiner les résultats (fiabilité, charge, expérience de l équipe, ). - Le modèle détaillé intègre souvent plusieurs modèles intermédiaires et de base afin d obtenir une meilleure estimation sur les grands projets. Ce modèle COCOMO permet d obtenir de façon très théorique une première estimation de l effort nécessaire au développement d une application. Néanmoins elle est très dépendante du niveau d expertise des personnes l appliquant. 2. Les points de fonction Cette méthode permet d estimer en "points de fonction" la taille d une application en se basant uniquement sur des données métier (fonctionnalité) et non sur la technique. Cette démarche se base sur les points d informations accédés, les entrées et sorties possibles dans l application. Elle est standardisée et permet ainsi d estimer l existant et de le mettre en perspective de ce qui doit être fait. Ainsi en développant des ratios jourxhomme/points de fonction livrés, on obtient rapidement une idée du coût d un projet. Trois autres ratios de Productivité, Réactivité et Qualité sont ainsi calculés. Cette méthode permet de prendre des décisions (choix entre 2 projets) sur des données rationnelles et permet ainsi un meilleur pilotage de l ensemble des projets du système d information. b. Adaptation aux contextes de l administration De telles méthodes d estimation peuvent permettre de mieux cadrer les dépenses en matière de sous-traitance externe. Ainsi lors d une réponse à appel d offres, les coûts envisagés par la structure externe peuvent être comparés à ceux estimés en interne via la méthode COCOMO. 3

4 De même lors de développement d une nouvelle application en interne, l estimation du coût peut être effectuée en comparant ce nouveau projet à un projet présentant le même nombre de points de fonction. Chacune des deux méthodes présentées peut être appliquée à un projet mais la nature du projet fera plutôt pencher la balance vers l un ou l autre. c. Scénario de déploiement Un scénario de déploiement de ces outils se déroulerait en quatre phases : 1. Projets pilotes : Deux projets pilotes (utilisant chacun une méthode) sont lancés de manière simultané. Ces projets ne doivent pas être sensibles. 2. Retour d expérience : Chaque projet présente son retour d expérience de la méthode testée. En fonction des résultats (financiers, comptables) et du ressenti, l une, l autre ou les deux méthodes sont généralisées. 3. Conduite du changement : Avant la généralisation, les acteurs des projets pilotés préparent le changement en sensibilisant les futures chefs de projet impliqués et présentent les avantages indéniables qu ils ont pu constater. 4. Généralisation : Tous les projets adoptent l une ou l autre (ou les deux) méthodes. III. Adaptation de ces méthodes aux travaux d exploitation : Lorsque l on parle des travaux d exploitation, on ne peut quantifier le travail en parlant lignes de codes ou nombres de fonctionnalités. Néanmoins il est envisageable, au même titre que la méthodologie COCOMO est basée sur des statistiques, d estimer la charge des travaux d exploitation pour un projet. En effet, de nombreuses données chiffrées peuvent permettre de déterminer la complexité des tâches à effectuer : nombres d utilisateurs, nombres d applications dépendantes, solutions de sauvegarde, disponibilité exigée par la maîtrise d ouvrage, Ces données peuvent permettre de déterminer la criticité d une application pour le système d information. Plus une application sera critique, plus elle aura des besoins en termes de pilotage (suivi de la plateforme de production), d assistance utilisateurs, de mise en place de solutions de sauvegardes et de modes dégradés. Si on devait faire un parallèle entre COCOMO et une méthode applicable à l exploitation, il faudrait mesurer le temps nécessaire aux tâches d exploitation pour trois types d application : - normal (peu d utilisateurs, faible dépendance des autres applications) - sensible (beaucoup d utilisateurs par exemple) - critique (ex : annuaire d authentification unique pour le SI) Ensuite en ajoutant un coefficient de complexité (technique et/ou fonctionnelle) à l application, des estimations pourront être effectuées. Par ailleurs, des points de criticité peuvent être mis en place de la même manière que les points de fonction. Cette méthode se baserait sur les critères similaires à la méthode précédente et permettrait de dresser un état des lieux de la consommation en ressources actuelles pour l exploitation. 4

5 Néanmoins, les deux méthodes présentées ici ont leurs limites et ne seront probablement pas aussi précises que celles d estimation des coûts de développement. En effet, certains aléas pouvant parfois se produire en série, peuvent mettre à mal une estimation pourtant bien ficelée dans des cas d exploitation normaux (i.e. sans incident majeur, type panne réseau ou onduleurs). Toutefois, ces méthodes peuvent servir de base pour une première estimation grossière qui donnera une idée du coût d exploitation de l application. 5