Définitions Maîtrise d’œuvre MOE

Présentation au sujet: "Définitions Maîtrise d’œuvre MOE"— Transcription de la présentation:

1 Maîtrise d’ouvrage et maîtrise d’œuvre dans la conduite des projets informatiques

2 Définitions Maîtrise d’œuvre MOE
Maître d’œuvre Prime Contractor Personne morale (entreprise, direction etc.) garant de la bonne réalisation technique des solutions. Il a un devoir de conseil vis-à-vis du Maître d’ouvrage. En cas de pluralité de fournitures, il veille à leur cohérence et à la qualité des interfaces. Il coordonne l’action des fournisseurs en optimisant la qualité technique, en minimisant les risques et en assurant le respect des délais fixés par le Maître d’ouvrage. Il valide la recette technique des solutions.

3 Définition Maîtrise D’ouvrage MOA
Maître d’ouvrage Customer Personne morale (entreprise, direction etc.) chargée d’une mission. Le maître d’ouvrage est responsable de l’efficacité de son organisation, de ses méthodes de travail et de son système d’information. Il fait appel à des maîtres d’œuvre* pour obtenir les solutions qui lui permettent de réaliser sa mission. Il leur fournit les spécifications fonctionnelles, et valide la recette fonctionnelle de ces solutions. Les fonctions du maître d'ouvrage sont remplies par des personnes ou des équipes : le maître d'ouvrage stratégique* est le patron de la personne morale considérée ; le maître d'ouvrage délégué* est l'expert qui assiste le maître d'ouvrage stratégique pour lui permettre d'exercer ses responsabilités ; le maître d'ouvrage opérationnel est un expert spécialisé dans l'automatisation d'un processus (Voir ci-dessous les définitions). 

4 Définition Maîtrise d’ouvrage délégué
Maître d'ouvrage délégué Business Technologist Le maître d’ouvrage délégué (MOAD) est une personne, soit seule, soit à la tête d’une équipe, qui veille à la qualité du SI de l’entité tant du point de vue de la conception que de la façon dont il est utilisé. Il assiste le maître d’ouvrage stratégique en lui fournissant les éléments nécessaires à la décision et à l’alignement stratégique du SI. Ses interlocuteurs naturels au sein de l’entité sont les chefs de service et les maîtres d’ouvrage opérationnels. Son interlocuteur naturel au sein de la direction informatique est le responsable de domaine

5 Définition Maîtrise d’ouvrage opérationnel
Maître d'ouvrage opérationnel Le maître d’ouvrage opérationnel (MOAO) est, dans l’entité, un expert qui connaît à fond l’un des grands processus du métier. Il recueille les demandes des utilisateurs et établit ou supervise les spécifications générales. Il a pour interlocuteur naturel à la direction informatique le chef de projet maîtrise d’œuvre*. 

6 Définition Maîtrise d’ouvrage stratégique
Maître d'ouvrage stratégique Le maître d’ouvrage stratégique (MOAS) du SI d'une entité est le dirigeant de cette entité : PDG ou DG pour l’entreprise, DGA ou directeur pour une direction de l’entreprise, chef de service pour les unités qui constituent la direction etc. Le SI étant à la fois la concrétisation de la stratégie et la condition de sa mise en œuvre, le MOAS prend les décisions essentielles concernant la maîtrise d'ouvrage (notamment pour le lancement des grands projets). Il arbitre les différends entre ses collaborateurs et signe le contrat avec la maîtrise d'œuvre.  Le MOAS n’est pas, en général, un expert en matière de SI. Il se fait assister par un maître d’ouvrage délégué (MOAD) auquel il délègue (c’est le sens même de l’expression) l’expertise en matière de SI.

7 Missions de la maîtrise d’ouvrage
Assurer la pertinence du SI en regard des priorités du métier, de la « stratégie » Suivi et contrôle de la mise en œuvre du SI Spécification fonctionnelle des évolutions et suivi des projets Déploiement et formation des utilisateurs

8 Missions de la maîtrise d’œuvre
Assurer l’exploitation de la plate-forme informatique Performance, disponibilité, support aux utilisateurs Assurer l’évolution du SI Qualité des développements, recette, mise en exploitation

9 Spécifications Spécifications générales (modèle métier)
Responsable : MOA Spécifications détaillées (modèle d’analyse) Responsable : MOE, validée par MOA Spécifications techniques (modèle technique) Responsable : MOE

10 Maîtrise d’ouvrage Maîtrise d’oeuvre Modèle métier Modèle d’analyse Modèle technique Production Validation

11 MOA / MOE

12 Nouvelles relations entre maîtrise d’ouvrage et maîtrise d’œuvre
1

13 Nouveaux rôles L ’entreprise s ’organise autour des processus et des composants Les métiers modélisent leur système d ’information Le système d ’information s ’ajuste pour équiper les processus des métiers Émergence de la « maîtrise d ’ouvrage » Organisation et sémantique : des règles simples aux applications diversifiées Professionnalisation de la maîtrise d ’ouvrage et de l ’informatique

14 Nouveaux rôles Généralisation de l ’assisté par ordinateur
Articulation de l ’homme organisé et de l ’automate programmable Un nouveau professionnalisme de la MOA... Équiper la stratégie d ’entreprise Élucider les processus des métiers Veille SI … en relation avec celui de l ’informatique Solide plate-forme technique Maîtrise des coûts Veille techno : langages, middleware, solutions, Maîtrise des fournisseurs

15 Principes de la MOA Axes fondamentaux Méthodes Sobriété
Fermeté et disponibilité Esprit de coopération Méthodes Spécifications, validations, qualité de la validation recettes, déploiement 6

16 Problèmes essentiels Priorité : « domaines » ou « projets » ?
Frontière de l ’externalisation Maîtrise de la diversification des compétences techniques Vers un nouveau type d ’entreprise

17 Relation entre la maîtrise d’ouvrage et ses utilisateurs

18 Relation MOA - utilisateurs
2 utilisateurs : « terrain » et « concepteur » étapes de la relation : expression des besoins, recette fonctionnelle, formation, déploiement, conduite du changement, aide aux utilisateurs, exploitation technique de proximité Lorsque l ’on parle des « utilisateurs » du système d ’information, il faut distinguer deux catégories de personnes : les utilisateurs « de terrain », ceux qui en pratique feront fonctionner l ’application et s ’en serviront pour leur travail quotidien ; et les « concepteurs », généralement affectés à la direction générale, et qui sont chargés de concevoir les nouvelles applications en fonction des orientations stratégiques de métiers de l ’entreprise. Les concepteurs ne sont pas des utilisateurs finals, mais ce sont eux qui sont chargés de transcrire les besoins de l ’entreprise en termes de fonctionnalités qui seront fournies par l ’application. Les relations entre la maîtrise d ’ouvrage et les utilisateurs comportent plusieurs étapes, que nous pouvons parcourir dans l ’ordre chronologique : d ’abord l ’expression des besoins, puis la recette fonctionnelle qui permet aux utilisateurs de vérifier que l ’application correspond bien à leur demande, puis la formation des utilisateurs « de terrain », le déploiement, la conduite du changement, l ’aide aux utilisateurs, l ’exploitation technique de proximité. Nous considérerons dans cet exposé uniquement la première de ces étapes, l ’expression de besoins.

19 Étapes de l’expression des besoins
Expression informelle Validation par les responsables Formalisation du besoin Convergence MOA Convergence MOA-MOE L ’expression de besoins se fait selon plusieurs étapes : - une première expression, dite « informelle » pour la distinguer des expressions formalisées, est d ’abord nécessaire pour que l ’on puisse bien comprendre de quoi il s ’agit : bien qu ’informelle, elle doit être rigoureuse. Elle est exprimée en langage courant, et elle est compréhensible à la lecture par tout le monde, y compris par les dirigeants. - l ’expression informelle doit être validée par les dirigeants responsables, de sorte que l ’on soit certain qu ’elle correspond bien aux priorités et à la stratégie de l ’entreprise. Cette validation est indispensable, car sinon on court le risque d ’un désaveu après plusieurs mois de travail dans une direction erronée. - on établit ensuite une expression formalisée, selon un langage que nous allons décrire ci-dessous. La formalisation fait parfois apparaître des lacunes de l ’expression informelle, et il faut donc que l ’on parcoure des itérations jusqu ’à ce que l ’on dispose d ’une expression informelle et d ’une expression formelle cohérentes. - jusqu ’à présent, on en est resté à la maîtrise d ’ouvrage, responsable de l ’expression des besoins. Lorsque celle-ci est terminée, elle est communiquée à la maîtrise d ’œuvre et il faut s ’assurer que celle-ci la comprend bien. Un jeu de questions et réponses conduit à l ’expression des besoins finale, dûment comprise et validée par la maîtrise d ’œuvre.

20 Formalisation du besoin
vers la modélisation métier professionnalisation du maître d'ouvrage transcription de la stratégie de l'entreprise dans le système d'information Une fois l ’expression de besoin en français rédigée et validée, il est utile de la modéliser. On dispose maintenant, avec le langage UML (Unified modeling language) d  ’un langage de modélisation bien adapté. Il permet de préciser les besoins de façon à supprimer toute ambiguïté pour l ’entreprise qui sera par la suite chargée de la réalisation. Il utilise les concepts propres à l ’orienté objet (classes, composants, attributs, liens etc.) : proche de l ’utilisateur, dont il formalise la demande, il fournit à la réalisation une base conceptuelle qui sera réutilisée et précisée lors des étapes ultérieures, ce qui permet un gain de temps précieux. La maîtrise du langage de modélisation UML (ou de tout autre langage analogue dans le futur ; pour le moment, c ’est UML qui s ’impose) est une étape importante de la professionnalisation des maîtrises d ’ouvrage. Alors que les expression de besoins étaient auparavant souvent imprécises et versatiles, les maîtrises d ’œuvre vont désormais disposer de descriptions complètes, établies selon une procédure qui garantit leur pérennité. Le modèle devient le langage dans lequel le métier structure ses fondations conceptuelles. Il sert aussi (ou plutôt il servira, car nous sommes ici en avance par rapport à la pratique de la plupart des entreprises) à mettre en forme les choix stratégiques et à les expliciter. Dès lors le modèle est la transcription de la stratégie de l ’entreprise, dont il donne une description complète et précise, propre à la réalisation technique qui lui fait suite.

21 Modèle UML Présentation stratégique Présentation des processus
Explication de la modélisation Modèle formel Un modèle UML se compose de plusieurs documents en langage courant et d ’un document formalisé : il ne se limite en aucun cas au seul document formalisé, car celui-ci est pratiquement incompréhensible si on le présente seul, sauf peut-être pour des experts en UML, mais ces personnes sont rares. Le premier document est la présentation stratégique, expliquant pourquoi l ’entreprise a voulu se doter de l ’outil considéré, les buts qu ’elle cherche à atteindre, le calendrier de réalisation qu ’elle a prévu, etc. Le second document est une présentation des processus de travail par lesquels la stratégie doit se réaliser. Il doit être illustré par une présentation des écrans qui seront affichés devant les utilisateurs, de sorte que le lecteur puisse voir comment l ’application va fonctionner en pratique. Le troisième document est une explication des choix et des méthodes utilisés pour la modélisation formelle : il s ’agit de reproduire, pour le lecteur, les discussions qui ont présidé à ces choix. Le quatrième document est le modèle formel lui-même. Il comporte des diagrammes, des liens hypertextes permettant l ’ouverture de fenêtres de contenu textuel. Parmi les diagrammes, on doit présenter en premier le diagramme d ’activité, qui montre l ’enchaînement des « use cases » au sein du processus et qui est le plus immédiatement compréhensible ; puis le diagramme de séquence, qui montre l ’enchaînement des opérations à l ’intérieur d ’un « use case ». Enfin, le diagramme de classes, qui est le plus précis conceptuellement mais aussi le plus difficile à lire.

22 Convergence MOA En fait l ’élaboration du modèle, avec ses parties formelles et ses parties en langage naturel, se fait de façon itérative. On rédige d ’abord une première expression de besoins en langage naturel ; la modélisation formelle fait apparaître les ambiguïtés et incohérences inévitables dans une première rédaction : on les corrige, ce qui conduit à construire une deuxième version du modèle formel, etc. A la fin du processus, la maîtrise d ’ouvrage dispose d ’un modèle livrable à la maîtrise d ’œuvre, composé de ses deux parties (formelle et en langage naturel) dûment cohérentes. Avant d ’être livré, ce modèle doit être validé par les dirigeants responsables, qui liront surtout les documents en langage naturel. Cette élaboration demande une gestion documentaire attentive : il importe que les diverses versions des textes soient numérotées et leur cohérence vérifiée, de sorte que le destinataire n ’ait pas le souci de devoir vérifier la cohérence de ce qui lui est livré. Le livrable fourni par la maîtrise d ’ouvrage à la maîtrise d ’œuvre s ’appelle « modèle métier », « modèle fonctionnel » ou encore « spécifications générales », ces deux termes étant synonymes.

23 Convergence MOA-MOE Maîtrise d’ouvrage Maîtrise d’œuvre
Lorsque le modèle métier est fourni au maître d ’œuvre, celui-ci doit se l ’approprier et s ’assurer qu ’il l ’a bien compris. Il peut ainsi relever des points obscurs. On entre donc dans un cycle de remarques du maître d ’œuvre, auxquelles le maître d ’ouvrage répond en précisant ou modifiant le modèle. A la fin de ce cycle, on dispose d ’un modèle métier stabilisé, parfaitement compris par les deux parties, et qui va servir de fondation à la réalisation.

24 Suite de l ’histoire modèle métier -> modèle d ’analyse
(spécifications générales -> spécifications détaillées) modèle d ’analyse -> modèle technique (specs détaillées -> specs techniques) specs techniques -> développement etc. Il est important de bien voir la chaîne des démarches qui conduisent à la réalisation. Le vocabulaire comporte des synonymes, mais la démarche est claire : - le « modèle métier » (ou « spécifications générales ») est celui qui est livré par la maîtrise d ’ouvrage à la maîtrise d ’œuvre. - le « modèle d ’analyse » (ou « spécifications détaillées ») est rédigé par le maître d ’œuvre, et validé par le maître d ’ouvrage. Il a pour but d ’apporter au modèle métier des précisions de nature technique (cardinalité des liens, définition des classes etc.) afin de préparer une réalisation efficace. Il doit être validé par la maîtrise d ’ouvrage et devient ensuite le modèle sur lequel fournisseur et client se sont mis d ’accord, et qui servira de charte à la réalisation. - le « modèle technique » (ou « spécifications techniques ») est le document qui sera fourni aux développeurs pour la réalisation. Il fixe les choix techniques nécessaires. Il est interne à la réalisation, et n ’a pas à être validé par le maître d ’ouvrage. Pour comprendre cette succession, il est utile d ’utiliser une métaphore inspirée de la vie courante. Supposons que vous fassiez construire une maison. Vous avez le plan sous les yeux, et vous dites : « dans cette chambre, il faudra quatre prises de courant, un interrupteur commandant une prise, et une applique commandée par un interrupteur ». Ce sont vos spécifications générales. L ’électricien vous demandera de préciser l ’endroit où il faut installer les prises, les interrupteurs et l ’applique. Noter ces emplacements précis, c ’est les spécifications détaillées. Puis l ’électricien fera le plan de câblage, et déterminera le parcours des goulottes et saignées. Ce sont les spécifications techniques, qui ne vous intéressent pas (il vous demandera peut-être de donner votre accord avec l ’emplacement de l ’armoire de raccordement, où se trouveront les disjoncteurs). Toute réalisation doit parcourir ces trois étapes, et être conduite de telle sorte que l ’on ait pas lors d ’une étape à remettre en cause les choix opérés lors des étapes précédentes.

25 Qualité Logiciel AFNOR X50-151 : Cahier des charges Fonctionnel
ISO9001/ISO :Cycle de vie du Logiciel ISO15504 : L’assurance qualité

26 Qualité Logiciel La maîtrise de la qualité à pour objectifs pratiques de réduire les coûts par la réduction des dysfonctionnements et par la même de garantir une régularité de production. La maîtrise de la qualité implique en premier lieu la maîtrise des processus d'ingénierie du logiciel. Celle-ci se base désormais sur la normalisation ISO ou CMM qui représente actuellement l’état de l’art

27 ISO 15504 L’assurance qualité « ISO 15504 - CMM »
Dans une organisation impliquée dans la normalisation de sa chaîne de production de logiciel, la notion de Plan Qualité s’applique à l’organisation. La notion de Plan d’assurance Qualité s’applique toujours au projet et correspond à un document décrivant le protocole du projet en incluant les points suivants : la formalisation des Exigences et des contraintes du projet, l’organisation de la communication, la précision de la méthodes et du processus de production, la description des livrables et des conditions de recette à chaque étape, la planification de contrôles systématiques de qualité appliqués aux livrables.

28 ISO 15504 La documentation ISO se compose de 9 parties auxquelles correspondent autant de documents : · 1 - Introduction aux concepts fondamentaux. · 2 - Modèle de gestion de l’ingénierie des processus. · 3 - Processus d’évaluation du niveau d’aptitude. · 4 - Guide de conduite de l’évaluation. · 5 - Modèle d'évaluation, guide des indicateurs, outils. · 6 - Guide pour la qualification des évaluateurs. · 7 - Guide de mise en œuvre de l’amélioration des processus. · 8 - Guide de détermination des aptitudes des fournisseurs. · 9 - Dictionnaire, vocabulaire et terminologie. La figure suivante décrit les principes d’interaction des 9 parties. A ces 9 parties s'ajoute un fascicule de documentation, élaboré en France, dont l'objet est de présenter de manière synthétique l'utilisation de la norme.

29 Critères qualité d’un Logiciel
l'adaptabilité mesure l'aptitude du logiciel à faciliter l'adjonction de nouvelles fonctionnalités ou la modification de fonctionnalités existantes (cet aspect couvre la correction des défauts provenant d'une mauvaise expression des besoins), la confidentialité mesure l'aptitude d'un logiciel à être protégé contre tout accès non autorisé , la correction mesure le degré de conformité par rapport aux spécifications, la couplabilité mesure l'aptitude d'un logiciel à être intégré dans un ensemble plus vaste, l'efficacité mesure l'aptitude d'un logiciel à minimiser la consommation des ressources qu'il utilise, l’ergonomie mesure l'aptitude d'un logiciel à être d'une utilisation agréable et facile pour l'utilisateur à qui il est destiné, la maintenabilité mesure l'aptitude d'un logiciel à faciliter la localisation et la correction d'erreurs résiduelles (il s'agit bien là de correction de défauts de non-conformité par rapport aux spécifications et non de défauts provenant d'une mauvaise expression des besoins), la portabilité mesure l'aptitude du logiciel à minimiser les conséquences d'un changement d'environnement technique, la réutilisabilité mesure l'aptitude du logiciel à une réutilisation de tout ou partie de ses composants dans le cadre d'un autre projet, la robustesse mesure l'aptitude du logiciel à conserver un comportement conforme aux besoins dans le cas d'événements imprévus, la testabilité mesure l'aptitude d'un logiciel à faciliter la vérification de son comportement par rapport à des critères de test et de recette. 

30 Qualité Logiciel L’assurance qualité regroupe l’ensemble de ces préoccupations dans un cadre générique dont l’aboutissement opérationnel peut s’exprimer par la production d’un document spécifique à un projet particulier : le plan d’assurance qualité. Ce plan est constitué de la description systématique des conditions d’exécution du projet et du pilotage permanent des processus. L’adaptation permanente de ces deux activités s’effectue dynamiquement par l'élimination des défauts ou des déviations mis en évidence lors de leur exécution. Une responsabilité formelle doit être chargée des activités d'assurance qualité.·

31 Assurance Qualité Qualité applicative et qualité technique
En termes de qualité de la production, il importe de dissocier la qualité applicative de la qualité technique. La qualité applicative se mesure par le degré de satisfaction de l’utilisateur à l'égard : de la couverture fonctionnelle de ses besoins réels, de l’ergonomie générale et des facilités d’appropriation, des temps de réponse de l’application, De divers autres facteurs d’appréciation. La qualité technique est un ensemble de critères qui couvre : le nombre de « bugs » résiduels, la lisibilité du code et sa documentation, la concision des modules programmés, ’unicité et la hiérarchisation des fonctions internes, la non-redondance des appels de fonctions, la réduction des parties d’interfaces similaires, la généralisation et la sécurité des procédures d’erreur.

32 Assurance Qualité Une direction des études informatiques soucieuse de sa performance s'attache à définir, préalablement à chaque projet, son niveau de besoin en terme de suivi et de qualité. Cette notion de « niveaux de services » recouvre entre autres : le niveau de conduite de projet, le niveau de levée des risques, le niveau de qualité documentaire, le niveau de qualité applicative. Les deux liste suivantes présentent un exemple plus détaillé de cette vision « à la carte » de la rigueur « juste nécessaire » que requiert la qualité assujettie à des conditions de performance économique.

33 Assurance Qualité 1. Niveau de service « projet »
Planification et suivi de l'avancement. Planification et suivi des risques. Planification et suivi de la sécurité. Formalisation des activités de conduite de projet. Formalisation de la gestion des changements. Formalisation de la gestion de la configuration. Formalisation de la gestion des tests.

34 Assurance Qualité 2. Niveau de service « application »
Production de l'application, qualité technique. Production de l'application, qualité fonctionnelle. Production de la documentation technique. Production de la documentation d'utilisation.

35 ISO 12207 La norme ISO établit un référentiel pour les processus associés au cycle de vie des produits logiciels et ceci avec une terminologie bien définie, pour l’industrie du logiciel. La norme contient des processus, activités et tâches qui se doivent d’être appliqué lors de l’acquisition d’un système contenant des composantes logiciels, d’un produit logiciel ainsi que lors des services informatiques pour les étapes d’approvisionnement, de développement, de mise à disposition et de maintenance des ces produits logiciels. La norme propose également un processus afin de définir, contrôler et améliorer les processus du cycle de vie des produits logiciels.

36 ISO 12207 La norme présente trois groupes de processus qui sont requis durant le cycle de vie des produits logiciels. Pour chacun des processus, un ensemble d’activités y est décrit et pour chaque activité, un ensemble de tâches. Voici maintenant une courte description des trois groupes: Le premier groupe constitue les processus primaires du cycle de vie et contient les processus suivants : acquisition, approvisionnement, développement, mise à disposition et maintenance. Le deuxième groupe comprend les processus de support qui sont: la documentation, la gestion de la configuration, l’assurance qualité, la vérification, la validation, les revues conjointes, les audits et la résolution des problèmes. Finalement, le troisième groupe contient les processus organisationnels qui sont: gestion, organisation, amélioration et formation. La norme est applicable pour l’acquisition de systèmes, de produits et de services logiciels qui peut comprendre les étapes d’approvisionnement, de développement, de mise à disposition et finalement de maintenance, autant à effectuer au sein de l’entreprise qu’à l’extérieur.

37 ISO 12207 Quels sont les avantages?
La norme ISO permet de sélectionner les processus, les activités et les tâches qui sont applicables pour des projets spécifiques. Elle permet la mise en place et l’amélioration continue des processus nécessaires, au sein de l’entreprise ainsi qu’à l’extérieur de l’entreprise, pour les différentes étapes de développement et de maintenance des produits logiciels. Quelles sont les limites? La norme ISO définit une architecture des processus requis mais ne spécifie pas les détails d’implantation ou d’exécution des activités et des tâches qui sont incluses dans les processus. Elle ne prescrit pas le nom, le format et de façon explicite le contenu des documents à produire et ne prescrit pas un modèle de cycle de vie ou de méthodologie de développement. Quels sont les coûts associés? Les coûts de formation sont estimés à $ 1,5K par personne pour une formation d'une durée de trois jours. L'élaboration des processus peut prendre de 40 à 100 heures par processus. Sans oublier les frais reliés au support externe, qui peuvent atteindre entre $ 30K et $ 75K.

38 Traçabilité La traçabilité est une procédure visant à suivre automatiquement un produit ou un service depuis sa naissance jusqu'à sa valorisation finale L’objectif premier de la traçabilité est de pouvoir identifier un produit, un lot de produits ou encore un service afin de pouvoir le retirer très rapidement et avec un maximum de sécurité en cas de non conformité, de danger. La traçabilité offre également l’avantage de pouvoir intervenir en amont de la distribution en permettant par exemple de contrôler la qualité du produit depuis l’origine des ses matières premières. Ce qui autorise une nette diminution des coûts de non qualité intervenant traditionnellement sur les produits finis. De nombreuses statistiques peuvent ressortir d’une traçabilité, très utile pour un service S.A.V. ou un service marketing. Les flux de matières premières, de produits finis sont également mieux identifiés. En résumé, la traçabilité permet d’améliorer la qualité, le service et l’efficacité globale d’une entreprise.

39 Maintenance

40 Maintenance Préventive
La maintenance préventive est axée sur la correction des défauts des applications, en vue de minimiser le risque d'une répétition des problèmes. La maintenance corrective apporte des solutions ponctuelles pour garder les applications en fonction, tandis que la maintenance préventive fait l'analyse détaillée des problèmes récurrents et s'attaque aux « causes profondes ». Les interventions de maintenance préventive comprennent la restructuration des codes sources, la réorganisation des bases de données et la réécriture des programmes. Maintenance pour l’amélioration La maintenance pour l’amélioration est un processus d'amélioration continuelle qui a pour but d'optimiser le rendement d'une application. Ce genre de maintenance produit une application à haute performance, stable, qui procure un degré élevé de satisfaction des utilisateurs.

41 Maintenance Corrective
La maintenance corrective consiste à réparer les défauts qui empêchent une application de traiter correctement les données ou de produire des résultats exacts. Elle consiste à régler des problèmes opérationnels ou à corriger des anomalies qui entravent l'exécution d'un processus. La maintenance corrective exige un soutien 7 jours/24 heures, afin de maintenir les applications à leur efficacité maximale.

42 Maintenance Adaptative
La maintenance adaptative a pour but d'améliorer constamment les applications selon l'évolution des besoins de l'entreprise. Les améliorations peuvent prendre diverses formes : les mises à niveau logicielles, les modifications exigées par la réglementation, l’intégration de systèmes, etc. La maintenance adaptative s’assure que les applications progressent au rythme des changements constants qui surviennent, que ceux-ci soient d'origine commerciale, technologique ou réglementaire.

43 Récapitulatif de Méthodes de gestion de projets informatique
1. Les origines 2. Notion de projet et caractéristiques d'un projet 3. Lancement d'un projet et évaluation d'un projet 4. Les causes d'échecs et la perte de contrôle 5. Le triangle projet : les objectifs, les délais, les moyens 6. Parmi les moyens : les acteurs 7. Le contexte psychologique, motiver l'équipe de projet

44 Les origines années 1950 : réflexion pour les grands projets industriels (aéronautique, armement, travaux public) aujourd'hui : projets de plus en plus importants besoin de méthode : constat d'échec et situation de crise (coûts, délais,non-fiabilité...) influence organisationnelle : certaines organisations se structurent en mode projet

45 Outils de gestion de projets informatique
1. Le contexte de la gestion de projet 2. Découper pour estimer 3. Estimer pour planifier 4. La planification du projet 5. Le suivi et le contrôle

46 Caractéristiques d’un projet
une action unique et ponctuelle, non répétitive limité dans le temps : dates de début et de fin une démarche spécifique : atteindre l'objectif en maîtrisant la qualité du produit fini, les coûts et les délais grâce à des étapes et des jalons mobilise des compétences multiples et complémentaires

47 Lancement d’un Projet Avant acceptation ou lancement, se poser des questions : Toute difficulté identifiée devra faire l'objet d'un dialogue approfondi avec le demandeur pour soit annuler, infléchir ou différer le projet soit négocier des moyens de réussite à la hauteur des enjeux et des conditions de réussite identifiées.

48 Evaluer un projet Évaluer sous différents angles :
Evaluer par le résultat attendu et les enjeux générateur de résultats économiques ? initiateur de changements dans les structures et comportements ? Evaluer par la pertinence de la demande : est t-elle mûre ? identifier le demandeur (initiateur, décideur,destinataire) cerner la demande : demande énoncée clairement,nature de la demande, cadre de la demande, les délais Evaluer par la cohérence du projet dans le contexte de l'organisation Evaluer par la conduite de projet

49 Causes des Echecs l'incapacité à dialoguer entre partenaires
Côté utilisateur l'incapacité à dialoguer entre partenaires la mauvaise dénition des objectifs l'absence d'implication des utilisateurs le manque de qualité du produit livré l'absence de calcul des risques

50 Causes des Echecs mise en oeuvre de moyens inadaptés
Côté fournisseur mise en oeuvre de moyens inadaptés contraintes de délais, charges et coûts démotivation de l'équipe absence d'outils

51 Perte de contrôle Quelques symptômes :
perte de contrôle sur certains responsables on ne peut plus s'engager sur la date de livraison la qualité du produit en développement est incertaine non-détection à temps des écarts de délai, de coûts ou de conformité aux spécifications

52 Triangle Projet

53 Les Acteurs Diversité d'acteurs et d'intérêts : parmi les clients :
les décideurs le chef de projet les usagers parmi les fournisseurs : les concepteurs les équipes de fabrication

54 Les Acteurs

55 Les Objectifs Quoi faire ?
Définir le domaine couvert en termes de fonctionnalités La difficulté réside dans les détails techniques : temps de réponse d'un système informatique évolution des volumes traités Difficulté à les prévoir en termes de faisabilité, délais, et coûts

56 Motiver l’équipe Projet
Chaque acteur s'engagera d'autant plus que : le résultat de son action est visible le résultat envisagé est désiré sa confiance dans sa capacité à agir est grande Provoquer ces trois facteurs : s'accorder sur le chemin à parcourir assurer la continuité du processus faire adhérer les équipes agir par la hiérarchie investir en ressources humaines, temps, argent

57 Découpage d’un Projet 1. Pourquoi découper ? 2. Principes du découpage
3. Les difficultés du découpage 4. Choisir une méthode de découpage 5. Découpage PBS, WBS et OBS 6. Découpage selon norme AFNOR

58 Découpage d’un Projet Faire face à la complexité des activités (diviser pour régner) Aborder le projet en termes d'unités de fabrication (Toujours se souvenir de l'objectif initial) Diminuer les risques de dérives (Cloisonnement des activités) Affecter des activités aux acteurs (Faire correspondre besoins et compétences) Ordonnancer (Planifier le travail sur un calendrier)

59 Difficulté du découpage
Identifier précisément les tâches Recenser les lots à fabriquer

60 Principe du découpage Objets du découpage : des éléments autonomes
Méthodes courantes de découpage sur critère temporel : succession d'étapes et de phases sur critère structurel : définition des modules

61 Choisir une Méthode de découpage
Méthodes générales 1. PBS (Product Breakdown Structure) 2. WBS (Work Breakdown Structure) 3. OBS (Organisation Breakdown Structure) Méthodes de conception spécique métier : Exemple développements informatiques : Merise UML Méthode plus spécifique, ex : Norme de conduite de projet AFNOR Z67-101

62 Exemple WBS (Work) division hiérarchique du travail global à réaliser en work packages, qui peuvent être estimés, planifés, et affectés à un responsable (personne ou service).

63 PBS Vue hiérarchique des composants, parties, sous-parties,
nécessaires à la construction du produit.

64 OBS hierarchie de l'organisation qui mène le projet, qui permet de mettre en relation PBS avec WBS pour identifier les responsabilités vis-à-vis des work-packages.

65 Relation OBS/WBS

66 Synthèse WBS/OBS/PBS La méthode est générale, et peut s'appliquer à tout projet. Certaines spéficités du métiers ne sont pas prises en compte (trop générale). La structure hiérarchique arborescente favorise un découpage récursif des éléments. Dans la pratique, on utilise des patrons (templates) dénis pour un type de projet donné. Exemple : l'armée U.S. demande à ses sous-traitants de se conformer au WBS normalsé US MIL-STD-881 (

67 Découpage temporel du projet
Méthode pour projets industriels 1. Étude de faisabilité (analyse, recherche, études de terrain) 2. Définition des solutions (représentation précise de l'objectif, solutions possibles) 3. Conception détaillée (contrats de réalisation, cahier des charges fournisseurs) 4. Réalisation (exécutions des contrats achevées par des recettes) L'étape 4 occupe généralement 90% des efforts et dépenses

68 Estimer un Projet Pourquoi estimer ? Cerner la durée du projet
Déterminer les ressources à mettre en oeuvre Déterminer la faisabilité technique du projet Pouvoir négocier Éviter les dérives de coûts

69 Estimer a différents Niveau
Niveau projet déterminer enveloppe budgétaire poids du projet en termes d'effort estimation de la rentabilité évaluer une durée vraisemblable Niveau étape planification précise calendrier des fournitures intermédiaires prévoir suivi de projet prévoir les montées/baisses en charge

70 Norme AFNOR pour estimer
Norme Z "recommandations pour la conduite de projets informatiques" s'inspire de la méthode Merise et normalise le découpage du processus de développement.

71 Méthode DELPHI Chaque expert donne anonymement une estimation
Les résultats sont rassemblés et exposés au groupe Chaque expert argumente sur son estimation Les experts s'accordent sur une estimation consensuelle

72 Méthode de répartition Proportionnelle

73 Méthode COCOMO Soit t le nombre de milliers de lignes de code livrées (sans les commentaires). Le type de projet est alors : taille t type de projet t < 50 simple > 50 < 300 moyen t > 300 complexe La charge c et le délai d sont estimés par : Type projet Charge en mois/homme Délai en mois

74 Méthode Pert

75 Méthode Gantt