La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Version 1.0 GENIE LOGICIEL Lanalyse et la gestion des risques Hervé DOMALAIN CNAM Aquitaine – 2004 / 2005.

Présentations similaires


Présentation au sujet: "Version 1.0 GENIE LOGICIEL Lanalyse et la gestion des risques Hervé DOMALAIN CNAM Aquitaine – 2004 / 2005."— Transcription de la présentation:

1 Version 1.0 GENIE LOGICIEL Lanalyse et la gestion des risques Hervé DOMALAIN CNAM Aquitaine – 2004 / 2005

2 Génie logiciel (2004 – 2005) 2 ENSEIRB Sommaire 1. Généralités - définitions 2. Analyse des risques en étude préalable et construction de lingénierie du projet 1. Pourquoi analyser les risques dès létude préalable ? 2. Les facteurs situationnels 3. Choix de la stratégie globale de développement 1. Stratégie de description 2. Stratégie de construction et de déploiement 3. Maîtrise des risques en cours de projet

3 Génie logiciel (2004 – 2005) 3 ENSEIRB Pourquoi gérer les risques ? (1/2) Maîtriser les risques est une préoccupation majeure en conduite de projet informatique. Les risques sont définis comme la possibilité qu'un projet ne s'exécute pas conformément aux prévisions de dates, de coûts ou d'expression des besoins, ces dérives étant considérées comme difficilement acceptables, voire inacceptables.

4 Génie logiciel (2004 – 2005) 4 ENSEIRB Pourquoi gérer les risques ? (2/2) Exercer la maîtrise des risques dans un projet permet au chef de projet de mieux communiquer sur les difficultés potentielles du projet et de partager ses responsabilités avec les autres décideurs concernés. En effet, les différents acteurs concernés par le projet (aux niveaux stratégique, fonctionnel ou technique, maîtrise d'ouvrage ou maîtrise d'oeuvre) doivent être impliqués dans le suivi des risques. Cette participation, tout en les engageant davantage dans l'atteinte des objectifs du projet, leur permet de mieux appréhender les risques du projet, de mieux les surveiller tout au long des phases et d'en réduire les effets. Le projet est globalement mieux maîtrisé car son pilotage est ajusté au fur et à mesure des évolutions de son environnement. La visibilité sous- jacente à la maîtrise des risques permet une prise de décision efficace, tout en se focalisant sur les aspects les plus sensibles du projet.

5 Génie logiciel (2004 – 2005) 5 ENSEIRB Les activités relatives à la gestion des risques (1/2) Pour maîtriser les risques, plusieurs activités sont à mettre en œuvre et ce, de manière itérative pendant toute la durée du projet : l'analyse des risques du projet, la réduction des risques et leur suivi. Les résultats de ces activités doivent être capitalisés au sein de l'organisme afin de faire profiter les futurs projets de l'expérience acquise.

6 Génie logiciel (2004 – 2005) 6 ENSEIRB Les activités relatives à la gestion des risques (2/2)

7 Génie logiciel (2004 – 2005) 7 ENSEIRB Le schéma de principe de gestion des risques Facteurs de risques Conséquences inacceptables et impacts Actions préventives ou curatives Réduisent ou évitent Sont causés par Agissent sur Entraînent

8 Génie logiciel (2004 – 2005) 8 ENSEIRB Déclinaison du schéma sur une occurrence Réduit ou évite Est causé par Agit sur Entraîne Retard au déploiement Fonctionnalité non disponible Développement itératif ou incrémental Augmentation des ressources Sous-estimations des charges de développement

9 Génie logiciel (2004 – 2005) 9 ENSEIRB Définition de lanalyse des risques Identification aussi exhaustive que possible de tous les événements générateurs de risques pour le projet, pouvant conduire au non respect des objectifs. L'identification initiale des risques s'effectue en fonction des objectifs, des exigences et du contexte du projet : ses contraintes de délais et de budget, son environnement, son organisation.... Pour effectuer ce recensement, le chef de projet peut procéder à un brainstorming avec les membres du projet (côté maîtrise douvrage et côté maîtrise dœuvre), s'inspirer dune check-list de risques ou bien consulter les suivis de risques effectués sur des projets antérieurs.

10 Génie logiciel (2004 – 2005) 10 ENSEIRB Définition de la réduction des risques Cette activité consiste à mettre en œuvre des dispositions appropriées visant à rendre les risques acceptables pour le projet. Ces dispositions peuvent être de différents types : suppression des causes, partage de responsabilités, limitation des conséquences, acceptation du risque tout en le surveillant… Le choix des actions préventives à engager est effectué en comparant les coûts de leur mise en œuvre avec les coûts des conséquences du risque, en tenant compte de leur probabilité d'apparition.

11 Génie logiciel (2004 – 2005) 11 ENSEIRB Définition du suivi des risques Cette activité est réalisée à laide dun tableau de suivi des risques : Elle permet de suivre l' évolution des risques déjà identifiés (stabilité, à la hausse, à la baisse), de contrôler la pertinence des actions préventives engagées et éventuellement de corriger les dispositions prévues. Elle permet également détudier la probabilité dapparition de ceux-ci. Si de nouveaux facteurs de risques apparaissent, il faut les ajouter à la liste initiale. Enfin, il s'agit de surveiller le déclenchement des événements redoutés et leurs conséquences réelles. Le suivi des risques s'effectue au cours des réunions de projet (comités de suivi et de pilotage) dans lesquelles les différents intervenants concernés sont conviés.

12 Génie logiciel (2004 – 2005) 12 ENSEIRB Sommaire 1. Généralités - définitions 2. Analyse des risques en étude préalable et construction de lingénierie du projet 1. Pourquoi analyser les risques dès létude préalable ? 2. Les facteurs situationnels 3. Choix de la stratégie globale de développement 1. Stratégie de description 2. Stratégie de construction et de déploiement 3. Maîtrise des risques en cours de projet

13 Génie logiciel (2004 – 2005) 13 ENSEIRB Construire lingénierie du projet (1/2) Construire l ingénierie du projet signifie : 1. Avant tout de choisir une stratégie globale de développement adaptée à la situation, 2. Puis, en fonction du type de projet, de définir précisément pour chacune des phases, les étapes à mettre en œuvre et les produits finis à livrer à la maîtrise douvrage. Cette ingénierie doit permettre de répondre aux exigences qualité et aux objectifs de lopération définis par le maître douvrage.

14 Génie logiciel (2004 – 2005) 14 ENSEIRB Construire lingénierie du projet (2/2) Contexte du projet Objectifs et exigences de la maîtrise douvrage Contexte du projet Objectifs et exigences de la maîtrise douvrage Construction de lingénierie du projet Analyse des risques Stratégie de développement Stratégie de développement Plan de jalonnement Plan de livraisons

15 Génie logiciel (2004 – 2005) 15 ENSEIRB Choisir la stratégie globale de développement Il sagit de déterminer, à partir dune analyse des exigences qualité et des facteurs situationnels du projet, exprimés en termes de complexité et d incertitude, quelles sont les stratégies de description, de construction et de déploiement quil faut mettre en œuvre pour maîtriser le développement d'un système. Un projet devra par exemple être réalisé suivant un cycle itératif pendant quun autre le sera par incréments. Dans le cadre dun projet, le choix de la stratégie globale seffectue pendant la phase détude préalable.

16 Génie logiciel (2004 – 2005) 16 ENSEIRB Déterminer le plan de jalonnement et le plan de livraisons Le choix de la stratégie permet de définir le jalonnement sur lequel sera basé le pilotage du projet. Le plan de livraisons définit les produits finis à réaliser pour chaque jalon imposé par la stratégie choisie pour le projet. Il constitue le cœur du plan du projet. Le plan de livraisons est fonction du type de projet, cest-à-dire de ses caractéristiques et dune estimation globale des charges.

17 Génie logiciel (2004 – 2005) 17 ENSEIRB Sommaire 1. Généralités - définitions 2. Analyse des risques en étude préalable et construction de lingénierie du projet 1. Pourquoi analyser les risques dès létude préalable ? 2. Les facteurs situationnels 3. Choix de la stratégie globale de développement 1. Stratégie de description 2. Stratégie de construction et de déploiement 3. Maîtrise des risques en cours de projet

18 Génie logiciel (2004 – 2005) 18 ENSEIRB Analyser les exigences qualité du projet Il sagit de prendre en compte les exigences définies par la maîtrise douvrage (par exemple les facteurs qualité définis par la norme ISO 9126). Leur analyse doit permettre de faire ressortir celles qui sont génératrices de risques pour le projet. Ces derniers sont donc à prendre en compte dans lanalyse des risques.

19 Génie logiciel (2004 – 2005) 19 ENSEIRB Analyser la situation et les risques Le choix de la stratégie repose sur l évaluation des risques (qui intègrent les exigences qualité). Les facteurs de risques, ou facteurs situationnels, se rapportent à la situation du projet, cest-à-dire à son contexte et à son contenu. Ces facteurs permettent de juger du degré de complexité et d incertitude du projet. Cette évaluation faite, il devient possible délaborer une stratégie.

20 Génie logiciel (2004 – 2005) 20 ENSEIRB Quid des facteurs situationnels ? Les facteurs situationnels sont des indicateurs qui permettent de caractériser la situation dans laquelle se trouve le projet, compte tenu de son environnement. Pour faciliter lévaluation des facteurs situationnels, ces derniers sont organisés en fonction des caractéristiques de domaine (cible ou projet) et des caractéristiques de connaissance (complexité ou incertitude).

21 Génie logiciel (2004 – 2005) 21 ENSEIRB Classification des facteurs situationnels Incertitude Complexité DOMAINE CIBLE DOMAINE DU PROJET Système dinformation Système informatique Charges Structure Acteurs Technologie Incertitude Complexité

22 Génie logiciel (2004 – 2005) 22 ENSEIRB Domaine cible Le domaine cible du projet est le résultat de ce que lon construit. Les facteurs situationnels du domaine cible sont regroupés en deux catégories : Le système dinformation qui est constitué dinformations organisées, dévénements ayant un effet sur ces informations et dacteurs qui agissent sur ces informations ou à partir de ces informations, selon des processus visant une finalité de gestion et utilisant les technologies de linformation. Décrire le système dinformation dune organisation (entreprise, organisme) revient à proposer une façon de regarder ce quest cette organisation et comment elle fonctionne. Le système informatique est constitué des matériels et des logiciels des applicatifs sur lesquels sappuient les processus du système dinformation.

23 Génie logiciel (2004 – 2005) 23 ENSEIRB Domaine du projet Le domaine du projet se rapporte à lorganisation responsable de ladaptation du système dinformation, à savoir de la production du logiciel. Les facteurs situationnels du domaine de projet sont regroupés en quatre catégories : Structure du projet : propriétés apparentées à la structure (systèmes de communication, dautorité et flux fonctionnels au sein du projet), Charges du projet : propriétés apparentées aux unités dœuvre assignées, bien définies, Acteurs du projet : propriétés apparentées aux acteurs du projet (exécutants de parties de projet), Technologie du projet : propriétés apparentées à la technologie (méthodes, techniques et outils) à utiliser dans le cadre du projet.

24 Génie logiciel (2004 – 2005) 24 ENSEIRB Domaine cible ou domaine du projet ? Un chantier de construction Un bâtiment Léquipe projet Les utilisateurs du logiciel Un atelier de génie logiciel Un logiciel La gestion des ressources La gestion de stages

25 Génie logiciel (2004 – 2005) 25 ENSEIRB Système dinformation ou système informatique ? Technologies de développement Acteurs au sens UML Processus métier Données en persistance Domaine cible Informations métier Fonctions applicatives Changements organisationnels

26 Génie logiciel (2004 – 2005) 26 ENSEIRB Caractéristiques de connaissances Les caractéristiques de connaissances regroupent les connaissances nécessaires pour gérer la situation dun projet. Ces connaissances sont caractérisées par leur complexité et leur incertitude : La complexité peut être considérée comme une mesure de la difficulté à gérer les connaissances disponibles. Dans léchelle de la complexité, une situation est simple, modérée ou complexe. L incertitude peut être considérée comme une mesure du degré de connaissances disponibles. Dans léchelle dincertitude, une situation est certaine, modérée ou incertaine.

27 Génie logiciel (2004 – 2005) 27 ENSEIRB Complexité ou incertitude ? La tempête de décembre 1999 Le passage à lan 2000 Un périmètre fonctionnel important Des fonctionnalités mal définies Une équipe projet importante Des ressources mobilisées sur plusieurs projets simultanément Mise en œuvre de technologies mal connues par le prestataire Mise en œuvre de technologies novatrices

28 Génie logiciel (2004 – 2005) 28 ENSEIRB Description des tableaux de facteurs situationnels Domaine cible Facteur de complexité Description du facteur de complexité Phases concernées par le facteur de complexité Probabilité dapparition Niveau dimpact Poids du risque Système dinformation ou Système informatique Hétérogénéité des acteurs Les acteurs du système dinformation sont–ils hétérogènes pour des raisons dorganisation, de politique, de spécificité du domaine ou des individus ? Exemple dacteurs : utilisateurs, supérieurs hiérarchiques dutilisateurs, gestionnaires dapplications, … Besoins antagonistes. Ladaptation du système dinformation nest pas acceptée. Étude préalable et/ou Analyse et/ou Conception et/ou Réalisation et/ou Tests et/ou Recette et/ou Déploiement 1 = faible 2 = moyenne 3 = forte 4 = très forte 1 = mineur 2 = moyen 3 = important 4 = majeur Probabilité dapparition x Niveau dimpact Type et description du facteur Quelle phase est concernée par le facteur ? Valorisation du risque Nature du risque engendré par le facteur

29 Génie logiciel (2004 – 2005) 29 ENSEIRB Facteurs de complexité du domaine cible - système dinformation (1/3) Facteur de complexité Description du facteur de complexité et exemples de risques engendrés Phases concernées Hétérogénéité des acteurs Les acteurs du système dinformation sont–ils hétérogènes pour des raisons dorganisation, de politique, de spécificité du domaine ou des individus ? Exemple dacteurs : utilisateurs, supérieurs hiérarchiques dutilisateurs, gestionnaires dapplications,... Besoins antagonistes. Ladaptation du système dinformation nest pas acceptée. Étude préalable Analyse Déploiement Taille du domaine cible Quelle est la taille du domaine cible exprimée en nombre de processus et dunités organisationnelles ou en nombre de cas dutilisation ? Perte de contrôle du projet. Structure organisationnelle du projet insuffisante. Structure consultative difficile à mettre en place. Difficulté à trouver un consensus et à satisfaire les besoins. Étude préalable Analyse Déploiement

30 Génie logiciel (2004 – 2005) 30 ENSEIRB Facteurs de complexité du domaine cible - système dinformation (2/3) Facteur de complexité Description du facteur de complexité et exemples de risques engendrés Phases concernées Taille de la distribution Quelle est la couverture de la diffusion (nombre de sites géographiques utilisateurs) ? Le système dinformation natteint pas ses objectifs. Perte de contrôle du projet. Équipe de diffusion trop faible en moyens. Structure organisationnelle du projet insuffisante. Sites hétérogènes, équipés de versions différentes de lapplication. Étude préalable Analyse Déploiement Complexité de linformation Quelle est la complexité de linformation du domaine cible et la difficulté à définir et à qualifier les données et à obtenir un consensus entre les gestionnaires et les différents types dutilisateurs (exemples : données scientifiques, données juridiques, données cartographiques, données environnementales, données économiques…) ? En termes UML, la complexité de linformation peut se mesurer au vu du nombre et du type dentités métier. Le système dinformation natteint pas ses objectifs. Les données sont trop précises, fastidieuses à saisir, donc partiellement saisies. Les données sont difficiles à qualifier. Léchelle des données est mal choisie. Les données sont incomplètes et ne répondent pas à tous les cas dutilisation. Le dictionnaire de données est imprécis dans ses définitions et ne répond pas aux exigences des métiers. Le système est abandonné par les utilisateurs et partenaires qui développent ultérieurement dautres applicatifs. Étude préalable Analyse Déploiement

31 Génie logiciel (2004 – 2005) 31 ENSEIRB Facteurs de complexité du domaine cible - système dinformation (3/3) Facteur de complexité Description du facteur de complexité et exemples de risques engendrés Phases concernées Complexité des processus Quelle est la complexité des processus exprimée en nombre de processus et dinterfaces, en degré de complexité des règles de gestion et des algorithmes, en nombre dutilisateurs « partenaires » qui exploitent les données du système ? En termes UML, la complexité des processus peut se mesurer au vu de la complexité : des cas dutilisation, des diagrammes de séquence, des diagrammes de collaboration, des diagrammes dactivité. Le système dinformation natteint pas ses objectifs. Le système est abandonné par les utilisateurs et partenaires qui développent dautres applicatifs, indépendants du domaine cible. Étude préalable Analyse Déploiement

32 Génie logiciel (2004 – 2005) 32 ENSEIRB Facteurs de complexité du domaine cible - système informatique (1/3) Facteur de complexité Description du facteur de complexité et exemples de risques engendrés Phases concernées Complexité des données Quelle est la complexité des données exprimée en nombre dindividus, en nombre de propriétés, dans la complexité des relations, dans la complexité du MCD ou du diagramme de classes persistantes, mais surtout avec le nombre de relations et de clés daccès demandées ? En termes UML, la complexité des données peut se mesurer au vu du nombre de classes, dassociations, de propriétés. Le système informatique ne fonctionne pas. Étude préalable Analyse Conception Réalisation Tests Déploiement Complexité des fonctions automatisées Quelle est la complexité des processus à informatiser : longs à mettre au point, algorithmes complexes, peu de processus réutilisables ? En termes UML, la complexité peut se mesurer au vu du nombre de méthodes. Le système informatique ne fonctionne pas. Le système informatique ne traite pas toutes les fonctions demandées par le maître douvrage. Le système informatique traite partiellement certaines fonctions. Le système informatique traite certaines fonctions avec des erreurs de gestion. Étude préalable Analyse Conception Réalisation Tests Déploiement

33 Génie logiciel (2004 – 2005) 33 ENSEIRB Facteurs de complexité du domaine cible - système informatique (2/3) Facteur de complexité Description du facteur de complexité et exemples de risques engendrés Phases concernées Complexité des propriétés qualitatives Quelle est la complexité des critères de qualité retenus pour le domaine cible par le maître douvrage ? Exemples : efficacité, sécurité, fiabilité, maintenabilité, portabilité et utilisabilité (cf. norme ISO 9126). Le système informatique ne répond pas aux normes souhaitées et manque de précision. Le système informatique manque de fiabilité. Le système informatique est difficile et coûteux à faire évoluer. Le système informatique ne peut pas être installé sur tous les matériels des utilisateurs. Étude préalable Analyse Conception Réalisation Tests Déploiement Nombre de duplications du système informatique Combien de systèmes informatiques doivent-ils être installés ? Perte de contrôle du projet. Tous les sites utilisateurs nont pas la même version, dans les architectures déconcentrées. Étude préalable Analyse Conception Réalisation Tests Déploiement

34 Génie logiciel (2004 – 2005) 34 ENSEIRB Facteurs de complexité du domaine cible - système informatique (3/3) Facteur de complexité Description du facteur de complexité et exemples de risques engendrés Phases concernées Complexité de la technologie cible Quel est le degré de complexité de la technologie du système informatique, de larchitecture technique utilisée pour le développement et lexploitation du système informatique ? Le système informatique ne fonctionne pas. Les plates-formes cibles ont été mal définies et lapplication ne peut pas sinstaller. La plate-forme de développement ne fait pas partie des architectures recommandées et pose des problèmes avec les plates-formes cibles. Étude préalable Analyse Conception Réalisation Tests Recette Déploiement

35 Génie logiciel (2004 – 2005) 35 ENSEIRB Facteurs dincertitude du domaine cible - système dinformation (1/4) Facteur dincertitude Description du facteur dincertitude et exemples de risques engendrés Phases concernées Attitude des acteurs Quelle est le degré dengagement et de motivation des acteurs ? Manque de participation des acteurs. Adaptation du système dinformation non acceptée. Étude préalable Analyse Déploiement Capacité des acteurs Quels sont les niveaux dexpérience, de compétences métier et de disponibilité des acteurs ? Système dinformation inadéquat. Validations incomplètes. Règles de gestion oubliées ou mal formalisées. Comportement des objets mal compris. Étude préalable Analyse Déploiement Stabilité de lenvironne- ment Quelle est la stabilité du système sur les plans réglementaire, politique, juridique, procédural, financier, organisationnel... ? Besoins évolutifs (modification dobjectif). Impossibilité de valider et de réceptionner les livrables. Nombreuses orientations et décisions remises en cause. Étude préalable Analyse Déploiement

36 Génie logiciel (2004 – 2005) 36 ENSEIRB Facteurs dincertitude du domaine cible - système dinformation (2/4) Facteur dincertitude Description du facteur dincertitude et exemples de risques engendrés Phases concernées Formalisation de linformation Est-il aisé de formaliser et de décrire les informations à partir des spécifications de la maîtrise douvrage ? Critères non atteignables. Informations, tableaux, graphiques incompréhensibles. Étude préalable Analyse Déploiement Formalisation des processus Est-il aisé de formaliser les processus via des diagrammes de séquence et de collaboration ? Critères non atteignables. Incapacité à formaliser. Étude préalable Analyse Déploiement Stabilité de linformation et des processus Linformation est-elle stable du point de vue de son environnement, cest-à-dire compte tenu de la fréquence, du nombre et du type de changements ou dévolutions prévisibles ? Besoins évolutifs (modification dobjectif). Étude préalable Analyse Déploiement

37 Génie logiciel (2004 – 2005) 37 ENSEIRB Facteurs dincertitude du domaine cible - système dinformation (3/4) Facteur dincertitude Description du facteur dincertitude et exemples de risques engendrés Phases concernées Spécificité du système dinformation Quelle est la spécificité du système dinformation : original, peu usuel, nécessitant un développement spécifique très sophistiqué ? Difficulté à trouver des experts. Difficulté dappropriation du domaine par léquipe projet. Surcoûts possibles. Étude préalable Analyse Déploiement Compréhen- sion du système existant Quel est le degré de compréhension du système dinformation existant par les acteurs ? Système dinformation existant inadéquat. Coûts imprévisibles. Application non utilisée. Étude préalable Analyse Déploiement Importance stratégique Quelle est limportance stratégique du SI ? Manque dimplication des cadres et des agents au niveau de la maîtrise douvrage. Application non utilisée. Étude préalable Analyse Déploiement

38 Génie logiciel (2004 – 2005) 38 ENSEIRB Facteurs dincertitude du domaine cible - système dinformation (4/4) Facteur dincertitude Description du facteur dincertitude et exemples de risques engendrés Phases concernées Importance des changements organisation- nels Quel est limpact sur la structure organisationnelle du client et sur les tâches des futurs utilisateurs ? Adaptation du SI non acceptée. Coûts imprévisibles pour le client. Étude préalable Analyse Déploiement Disponibilité, clarté et stabilité des besoins Les besoins exprimés par la maîtrise douvrage sont-ils stables ou évolutifs ? Besoins incertains, mal spécifiés et changeants. Interfaçage avec dautres systèmes mal défini. Étude préalable Analyse Déploiement Qualité des spécifications existantes Quelle est la qualité des spécifications de la maîtrise douvrage et des documentations des phases antérieures ? Système dinformation inadéquat. Coûts de projet imprévisibles. Étude préalable Analyse Déploiement

39 Génie logiciel (2004 – 2005) 39 ENSEIRB Facteurs dincertitude du domaine cible - système informatique Facteur dincertitude Description du facteur dincertitude et exemples de risques engendrés Phases concernées Importance des changements technologi- ques Quelle est limportance du changement et limpact provoqués par ladaptation du système dinformation (le logiciel) ? Insuffisance des propriétés qualitative. Adaptation du S.I. non acceptée. Coûts imprévisibles pour lorganisation. Étude préalable Analyse Conception Réalisation Tests Déploiement Nouveauté de la technologie cible La technologie cible est-elle novatrice par rapport à létat de lart de la technique ? Insuffisance des propriétés qualitative. Adaptation du S.I. non acceptée. Coûts de projet imprévisibles. Étude préalable Analyse Conception Réalisation Tests Déploiement

40 Génie logiciel (2004 – 2005) 40 ENSEIRB Facteurs de complexité du domaine du projet – charges du projet Facteur de complexité Description du facteur de complexité et exemples de risques engendrés Phases concernées Taille de la phase Quel est le nombre de mois.hommes ou dannées.hommes par exemple ? Perte de contrôle du projet. (cf. loi de Brooks) Étude préalable Analyse Conception Réalisation Tests Recette Déploiement Complexité de la migration Quelle est la complexité de la migration sur tous les sites opérationnels du domaine cible ? Perte de contrôle du projet. Analyse Conception Réalisation Tests Recette Déploiement

41 Génie logiciel (2004 – 2005) 41 ENSEIRB Facteurs de complexité du domaine du projet – structure du projet Facteur de complexité Description du facteur de complexité et exemples de risques engendrés Phases concernées Nombre de sous-traitants Quelle est la difficulté de contrôler la phase considérant le nombre de ressources externes ? Perte de contrôle du projet. Étude préalable Analyse Conception Réalisation Tests Recette Nombre dinterfaces avec dautres adaptations du SI Quelle est la difficulté de contrôler la phase considérant le nombre dinterfaces externes avec dautres adaptations du système dinformation (dautres logiciels appartenant au même SI) ? Perte de contrôle du projet. Analyse Conception Réalisation Tests Recette Déploiement

42 Génie logiciel (2004 – 2005) 42 ENSEIRB Facteurs de complexité du domaine du projet – acteurs du projet Facteur de complexité Description du facteur de complexité et exemples de risques engendrés Phases concernées Nombre dacteurs de la phase Quel est le nombre de parties prenantes qui interviennent sur la phase, en tant quutilisateurs, experts, développeurs, clients, gestionnaires,... ? Perte de contrôle du projet. Étude préalable Analyse Conception Réalisation Tests Recette Déploiement

43 Génie logiciel (2004 – 2005) 43 ENSEIRB Facteurs de complexité du domaine du projet – technologie du projet Facteur de complexité Description du facteur de complexité et exemples de risques engendrés Phases concernées Complexité de la technologie du projet Est-il aisé de mettre en œuvre la technologie retenue pour le projet en phases de conception, réalisation (développement) et de recette ? Perte de contrôle du projet. Conception Réalisation Tests Recette

44 Génie logiciel (2004 – 2005) 44 ENSEIRB Facteurs dincertitude du domaine du projet – charges du projet Facteur dincertitude Description du facteur dincertitude et exemples de risques engendrés Phases concernées Nouveauté de ladaptation du SI Le caractère innovant de ladaptation du S.I. (logiciel) a-t-il un impact sur le rendement de léquipe projet ? Système dinformation infaisable. Coûts imprévisibles pour le projet. Étude préalable Analyse Conception Réalisation Tests Conformité au planning Le respect du planning, rendu difficile à cause de mauvaises estimations ou compte tenu de lurgence du projet, est-il possible ? Qualité médiocre des livrables. Coûts accrus pour le projet. Étude préalable Analyse Conception Réalisation Tests Recette Déploiement Conformité au budget Le respect du budget, rendu difficile à cause de mauvaises estimations ou compte tenu des exigences de coûts de la maîtrise douvrage, est-il possible ? Qualité médiocre des livrables. Retards de livraison. Étude préalable Analyse Conception Réalisation Tests Recette Déploiement

45 Génie logiciel (2004 – 2005) 45 ENSEIRB Facteurs dincertitude du domaine du projet – structure du projet Facteur dincertitude Description du facteur dincertitude et exemples de risques engendrés Phases concernées Dépendance envers les sous-traitants Les prestations des sous-traitants sont-elles suffisamment contrôlées ou contrôlables ? Défauts sur les livrables fournis par les sous-traitants. Perte de contrôle du projet. Analyse Conception Réalisation Tests Déploiement Dépendance envers dautres adaptations du SI Le projet est-iI interfacé avec dautres projets sur lesquels les intervenants (maîtrise dœuvre et maîtrise douvrage) nont aucun contrôle ? Besoins changeants. Problèmes dintégration et de déploiement. Conception Réalisation Tests Recette Déploiement Formalisation de la relation client - fournisseur La contractualisation de la prestation est-elle suffisante ? Besoins changeants. Adaptation du SI (logiciel) non acceptée. Étude préalable Analyse Conception Réalisation Tests Recette

46 Génie logiciel (2004 – 2005) 46 ENSEIRB Facteurs dincertitude du domaine du projet – acteurs du projet Facteur dincertitude Description du facteur dincertitude et exemples de risques engendrés Phases concernées Capacité de léquipe projet Quels sont les compétences, les connaissances, les capacités, lexpérience, lengagement et la disponibilité de léquipe projet ? S.I. inadéquat et donc adaptation non acceptée. Capacités informatiques contraignantes. Qualité médiocre et retards sur les livraisons. Coûts imprévisibles pour le projet. Étude préalable Analyse Conception Réalisation Tests Recette Déploiement

47 Génie logiciel (2004 – 2005) 47 ENSEIRB Facteurs dincertitude du domaine du projet – technologie du projet Facteur dincertitude Description du facteur dincertitude et exemples de risques engendrés Phases concernées Nouveauté de la technologie du projet La technologie mise en œuvre est-elle novatrice comparée à létat de lart de la technique ? Qualité médiocre et retards sur les livraisons. Coûts imprévisibles pour le projet. Analyse Conception Réalisation Tests Recette Disponibilité dune technique de projet adéquate La technologie susceptible dêtre utilisée est-elle adaptée aux environnement serveurs et aux plates-formes clients ? Qualité médiocre et retards sur les livraisons. Coûts imprévisibles pour le projet. Analyse Conception Réalisation Tests Recette Déploiement

48 Génie logiciel (2004 – 2005) 48 ENSEIRB Les facteurs situationnels à étudier en étude préalable Les tableaux précédents décrivent tous les facteurs situationnels, quelque soit la phase du projet. Voici les facteurs permettant de construire l ingénierie du projet en étude préalable : Hétérogénéité des acteurs Taille du domaine cible Taille de la distribution Complexité de l'information Complexité des processus Complexité des données Complexité des fonctions automatisées Complexité des propriétés qualitatives Nombre de duplications du système informatique Complexité de la technologie cible Attitude des acteurs Capacité des acteurs Stabilité de l'environnement Formalisation de l'information Formalisation des processus Stabilité de l'information et des processus Spécificité du système d'information Compréhension du système existant Importance stratégique Importance des changements organisationnels Disponibilité, clarté et stabilité des besoins Qualité des spécifications existantes Importance des changements technologiques Nouveauté de la technologie cible Ce sont tous les facteurs situationnels du domaine cible.

49 Génie logiciel (2004 – 2005) 49 ENSEIRB Les commentaires sur la complexité et lincertitude du projet Les tableaux de facteurs situationnels doivent être commentés par le chef de projet car les commentaires servent de support à largumentation de la stratégie choisie. Il est très important que lanalyse soit également réalisée par dautres acteurs en plus du chef de projet : un représentant de la maîtrise douvrage, un autre membre de léquipe projet,... Ce qui permet dobtenir plusieurs points de vue et de garantir une meilleure exhaustivité de lanalyse.

50 Génie logiciel (2004 – 2005) 50 ENSEIRB Calculs de complexité et dincertitude du projet (1/3) Il est possible de sappuyer sur une approche chiffrée de lanalyse des risques : En quantifiant la probabilité dapparition du risque : 1 = faible, 2 = moyenne, 3 = forte, 4 = très forte. En quantifiant le niveau dimpact du risque : 1 = mineur, 2 = moyen, 3 = important, 4 = majeur. Ce qui permet de déterminer le poids du risque : « probabilité dapparition » x « niveau dimpact » => poids de 1 à 16 Dans ce cas aussi, limplication de plusieurs personnes pour évaluer le poids dun risque crédibilise les chiffres avancés.

51 Génie logiciel (2004 – 2005) 51 ENSEIRB Calculs de complexité et dincertitude du projet (2/3) Exemple de graphe (une analyse)

52 Génie logiciel (2004 – 2005) 52 ENSEIRB Calculs de complexité et dincertitude du projet (3/3) Exemple de graphe (3 analyses)

53 Génie logiciel (2004 – 2005) 53 ENSEIRB Sommaire 1. Généralités - définitions 2. Analyse des risques en étude préalable et construction de lingénierie du projet 1. Pourquoi analyser les risques dès létude préalable ? 2. Les facteurs situationnels 3. Choix de la stratégie globale de développement 1. Stratégie de description 2. Stratégie de construction et de déploiement 3. Maîtrise des risques en cours de projet

54 Génie logiciel (2004 – 2005) 54 ENSEIRB Les processus de description, de construction et de déploiement Lobjectif est de déterminer la meilleure solution pour décrire (spécifier), construire (réaliser) et déployer sur lensemble des sites concernés, le futur système dinformation. La description dans le cadre du projet : Processus consistant à analyser et à concevoir le système et en particulier son champ dapplication, ses fonctions, ses exigences et son architecture. Une description peut prendre plusieurs formes : des spécifications, des maquettes, des prototypes. Les phases détude préalable, danalyse et de conception en particulier contiennent des éléments de description. La construction du projet : Processus consistant à traduire une description de système en éléments opérationnels (tests inclus). Le processus de construction comprend par exemple les phases de réalisation et de tests, la phase dexécution de la recette ou encore la préparation de la phase de déploiement. Le déploiement du produit du projet : Processus consistant à rendre le système opérationnel dans le domaine cible. Ce processus correspond à la diffusion et nest mis en œuvre que dans le projet de déploiement.

55 Génie logiciel (2004 – 2005) 55 ENSEIRB Sommaire 1. Généralités - définitions 2. Analyse des risques en étude préalable et construction de lingénierie du projet 1. Pourquoi analyser les risques dès létude préalable ? 2. Les facteurs situationnels 3. Choix de la stratégie globale de développement 1. Stratégie de description 2. Stratégie de construction et de déploiement 3. Maîtrise des risques en cours de projet

56 Génie logiciel (2004 – 2005) 56 ENSEIRB Démarche de type conceptuel La description dun système sappuie sur une démarche de type conceptuel et sur une démarche de type organisationnel. Une démarche de type conceptuel indique la façon dont linformation est traitée pour prendre des décisions de conception : elle peut être analytique ou expérimentale. Analytique : utilisation d'abstractions et de spécifications. Il sagit par exemple délaborer des modèles du système futur (Merise, UML). Expérimentale : utilisation d'expériences, de maquettes et de prototypes. Il sagit dexpérimenter le futur système avec des utilisateurs. Cela demande par exemple de réaliser des prototypes avec ou sans modélisation préalable.

57 Génie logiciel (2004 – 2005) 57 ENSEIRB Démarche de type organisationnel Une démarche de type organisationnel indique comment les acteurs du projet travaillent avec les utilisateurs du système dinformation pendant le processus de description : elle peut être conduite par des experts ou participative. Conduite par des experts : la production des documents et leur évaluation sont séparées. Le groupe de travail est constitué dexperts des domaines concernés. La validation est réalisée par les utilisateurs. Participative : évaluation et production sont conjointes. Le groupe de travail est constitué des utilisateurs.

58 Génie logiciel (2004 – 2005) 58 ENSEIRB Choix de la stratégie de description Choix de la démarche de type conceptuel : Si la situation du projet est certaine, la démarche de type conceptuel préconisée est analytique. Dans le cas contraire, la démarche est expérimentale. Situation du projet en terme de complexité SimpleComplexité de linformation ou des processus Complexité de lorganisation ou hétérogénéité des acteurs CertaineParticipative Conduite par des experts Situation du projet en terme dincertitude Incertaine avec capacité des acteurs faible ou délais tendus Conduite par des experts Incertaine : autres cas dincertitude Participative Conduite par des experts Choix de la démarche de type organisationnel :

59 Génie logiciel (2004 – 2005) 59 ENSEIRB Sommaire 1. Généralités - définitions 2. Analyse des risques en étude préalable et construction de lingénierie du projet 1. Pourquoi analyser les risques dès létude préalable ? 2. Les facteurs situationnels 3. Choix de la stratégie globale de développement 1. Stratégie de description 2. Stratégie de construction et de déploiement 3. Maîtrise des risques en cours de projet

60 Génie logiciel (2004 – 2005) 60 ENSEIRB Démarche de construction Elle peut être unitaire (construction en une fois), incrémentale ou itérative : Construction unitaire : une version unique est construite et testée en une seule étape. Il sagit, la plupart du temps, de petits projets. Construction incrémentale : les parties sont construites et testées en une séquence détapes. Aucune modification des descriptions n'est admise après la construction. Beaucoup de grands projets sont réalisés de cette manière. Construction itérative : les versions sont construites et testées en une séquence détapes. Les modifications des descriptions restent possibles après les tests. Les démarches RAD sont de ce type.

61 Génie logiciel (2004 – 2005) 61 ENSEIRB Démarche de déploiement La stratégie de déploiement peut se définir suivant deux axes, un axe fonctionnel et un axe géographique. Axe fonctionnel : Déploiement unitaire : une version unique est mise en service en une seule étape. La plupart des petits projets sont mis en place en une fois. Déploiement incrémental : les parties sont mises en service en une séquence détapes. Aucune modification des descriptions n'est admise après la mise en service. La plupart des grands projets sont mis en place de cette manière. Déploiement itératif : les versions sont mises en service en une séquence détapes. Les modifications des descriptions restent possibles après les tests. Les progiciels du marché sont en général déployés par versions successives. Axe géographique : Déploiement global : la mise en service est réalisée simultanément dans tous les sites utilisateurs. Déploiement progressif (ou local) : la mise en service se fait en une séquence détapes avec couverture progressive des sites.

62 Génie logiciel (2004 – 2005) 62 ENSEIRB Stratégies de construction et de déploiement – tableau daide à la décision Facteurs situationnelsDémarche de construction et de déploiement DélaisDegré de complexitéDegré dincertitudeUnitaireIncrémentaleItérative NormauxSimpleCertain Incertain ComplexeCertain Incertain TendusSimpleCertain Incertain ComplexeCertain Incertain

63 Génie logiciel (2004 – 2005) 63 ENSEIRB Exemple 1 - Construction et déploiement unitaires Étude préalable Analyse Conception Réalisation Tests Recette Déploiement

64 Génie logiciel (2004 – 2005) 64 ENSEIRB Exemple 2 - Construction incrémentale et déploiement unitaire Étude préalable Analyse lot 1 Conception lot 1 Réalisation lot 1 Tests lot 1 Recette lot 1 Analyse lot 2 Conception lot 2 Réalisation lot 2 Tests lot 2 Recette lot 2 Analyse lot 3 Conception lot 3 Réalisation lot 3 Tests lot 3 Recette lot 3 Déploiement

65 Génie logiciel (2004 – 2005) 65 ENSEIRB Exemple 3 - Construction et déploiement itératifs Version finale Analyse V3 Conception V3 Réalisation V3 Tests V3 Déploiement V3 Recette V3 Version 1 Étude préalable Analyse V1 Conception V1 Réalisation V1 Tests V1 Déploiement V1 Recette V1 Version 2 Analyse V2 Conception V2 Réalisation V2 Tests V2 Déploiement V2 Recette V2

66 Génie logiciel (2004 – 2005) 66 ENSEIRB Exemple 4 - Construction itérative et déploiement unitaire Prototype 2 Analyse V2 Conception V2 Réalisation V2 Tests V2 Prototype 1 Étude préalable Analyse V1 Conception V1 Réalisation V1 Tests V1 Version finalisée Analyse V3 Conception V3 Réalisation V3 Tests V3 Déploiement Recette

67 Génie logiciel (2004 – 2005) 67 ENSEIRB Sommaire 1. Généralités - définitions 2. Analyse des risques en étude préalable et construction de lingénierie du projet 1. Pourquoi analyser les risques dès létude préalable ? 2. Les facteurs situationnels 3. Choix de la stratégie globale de développement 1. Stratégie de description 2. Stratégie de construction et de déploiement 3. Maîtrise des risques en cours de projet

68 Génie logiciel (2004 – 2005) 68 ENSEIRB La démarche de maîtrise des risques Elle consiste à : 1. Identifier les causes de risques potentielles (facteurs de risques) et estimer les conséquences (analyse des risques) en termes de charge, de délais et de qualité, 2. Mettre en évidence les risques critiques, 3. Trouver les solutions pour les réduire, 4. Piloter la mise en œuvre des solutions en surveillant les charges et les délais.

69 Génie logiciel (2004 – 2005) 69 ENSEIRB Identifier et analyser les facteurs de risque Tous les facteurs situationnels sont à étudier : Les facteurs relatifs au domaine cible ont été étudiés en étude préalable pour définir une ingénierie de projet. La maîtrise des risques tout au long du projet nécessite de réitérer lanalyse des risques pour chaque phase. Les facteurs relatifs au domaine du projet sont également à étudier, mais ils diffèrent selon chaque phase (voir dernière colonne « phases concernées » des tableaux de facteurs situationnels).

70 Génie logiciel (2004 – 2005) 70 ENSEIRB Les facteurs situationnels à étudier en cours de projet Étude préalable AnalyseConception Réalisation Tests Recette Déploiement PhasesAnalyses des risques à réaliser Étude préalableDomaine cible Itération 1 Domaine du projet Phase détude préalable AnalyseDomaine cible itération 2 Domaine du projet Phase danalyse ConceptionDomaine cible Itération 3 Domaine du projet Phase de conception Réalisation et testsDomaine cible Itération 4 Domaine du projet Phases de réalisation et tests RecetteDomaine cible Itération 5 Domaine du projet Phase de recette DéploiementDomaine cible Itération 6 Domaine du projet Phase de déploiement

71 Génie logiciel (2004 – 2005) 71 ENSEIRB Mettre en évidence les risques critiques Probabilité dapparition Niveau dimpact Très forteForteMoyenneFaible Majeur Important Moyen Mineur Risques critiques

72 Génie logiciel (2004 – 2005) 72 ENSEIRB Trouver les solutions pour réduire les risques critiques (1/11) Pour chaque risque critique, il convient de mettre en œuvre une ou plusieurs parades. Les tableaux suivants proposent un arsenal de solutions pour chacun des facteurs.

73 Génie logiciel (2004 – 2005) 73 ENSEIRB Trouver les solutions pour réduire les risques critiques (2/11) Facteurs situationnels Parades Hétérogénéité des acteurs Faire préciser les attentes par la MO afin de les redéfinir dans des réunions conjointes. Prévoir des points de validation intermédiaire pour figer les bases des travaux. Faire valider par un expert technique l'adéquation entre les fonctions de la solution et les attentes. Taille du domaine cible Identifier précisément les déficiences de l'équipe et adapter la structure de l'équipe aux besoins. Adopter un plan de livraison compatible avec les moyens de production de l'équipe. Alerter la ME et la MO sur les impacts résultants des déficiences de l'équipe (dérapages, …). Prévoir une étape de cadrage des méthodes de travail et de management avec la MO. Prévoir un interlocuteur unique ayant pouvoir de décision pour l'ensemble des domaines couverts. Rédiger le plan de charges de la MO. En comité de pilotage ou de suivi, examiner le plan d'avancement de la MO. Si défaillance, proposer l'étude de solutions alternatives. Associer la MO aux travaux. Faire des validations intermédiaires Alerter la MO sur la planification des travaux à sa charge. Provoquer un comité extraordinaire sur les rôles et responsabilités de la MO. Prévoir des comités adaptés (management, technique, …) avec comptes rendus et plans d'action systématiques. Analyser les écarts de charge. Prendre des mesures d'anticipation pour les travaux ultérieurs. Planifier des livraisons partielles et organiser les recettes correspondantes. Alerter la MO sur les impacts (charges, délais) dus aux délais de validation. Proposer un dispositif de validation renforcé (assistance, …) pour satisfaire les délais.

74 Génie logiciel (2004 – 2005) 74 ENSEIRB Trouver les solutions pour réduire les risques critiques (3/11) Facteurs situationnels Parades Taille de la distribution Établir un relevé des écarts (fonctionnels, techniques, …). En fonction des écarts, émettre des préconisations pour tendre vers les prestations attendues. Organiser moyens de production et livraisons internes, en fonction de la dispersion de léquipe en charge du déploiement. Communiquer le planning global à toutes les équipes. Alerter la MO sur les impacts du manque de moyens de léquipe de diffusion. Ajuster la planification avec les charges réelles d'installation en production. Prévoir l'intégration des exploitants dans le projet (préparation de l'exploitation, …). Planifier des points de synchronisation avec les exploitants. Complexité de linformation Réévaluer toutes les tâches, lors des jalons majeurs du projet (en fin de phase, …). Définir et borner les critères de qualité à respecter (PAQ). Déterminer un projet dédié à la qualification et à la reprise de données. Décrire dans un document l'ensemble du processus de reprise de données et les synchronisations. Dédier une cellule technique à l'industrialisation de la production et à la surveillance des performances. Valider avec la MO au début du projet, l'architecture de référence pour les tests de performance. Valider avec la MO au début du projet, les volumes de référence et les caractéristiques des réseaux Complexité des processus Figer une version de référence, avec recette formelle. Gérer les évolutions sous forme de versions. Définir et borner les critères de qualité à respecter (PAQ).

75 Génie logiciel (2004 – 2005) 75 ENSEIRB Trouver les solutions pour réduire les risques critiques (4/11) Facteurs situationnels Parades Complexité des données Définir les critères d'acceptation et d'exploitation attendus, avant la production des livrables. Prévoir l'approbation des critères par la MO sur les jalons majeurs (recettes intermédiaires). Proposer une démarche conjointe de tests et de mesures. Valider avec la MO au début du projet, l'architecture de référence pour les tests de performance. Valider avec la MO au début du projet, les volumes de référence et les caractéristiques de réseaux. Complexité des fonctions automatisées Intégrer des utilisateurs pour les travaux de recette des changements de produits/composants. Réévaluer toutes les tâches, lors des jalons majeurs du projet (fin de phase…). Définir les critères d'acceptation et d'exploitation attendus, avant la production des livrables. Prévoir l'approbation des critères par la MO sur les jalons majeurs (recettes intermédiaires). Proposer une démarche conjointe de tests et de mesure. Valider avec la MO au début du projet, l'architecture de référence pour les tests de performance. Valider avec la MO au début du projet, les volumes de référence et les caractéristiques de réseaux. Complexité des propriétés qualitatives Définir les critères d'acceptation et d'exploitation attendus, avant la production des livrables. Prévoir l'approbation des critères par MO sur les jalons majeurs (recettes intermédiaires). Proposer une démarche conjointe de tests et de mesure. Valider avec la MO au début du projet, l'architecture de référence pour les tests de performance. Valider avec la MO au début du projet, les volumes de référence et les caractéristiques de réseaux.

76 Génie logiciel (2004 – 2005) 76 ENSEIRB Trouver les solutions pour réduire les risques critiques (5/11) Facteurs situationnels Parades Nombre de duplications du système informatique Ajuster la planification avec les charges réelles de gestion des versions des logiciels livrés. Ajuster la planification avec les charges réelles d'installation en production. Complexité de la technologie cible Pour les techniques innovantes, définir avec la MO les achats de licences et droits d'utilisation. Définir avec la MO les conditions d'acceptation (fonctions, performances) des techniques innovantes. Définir avec la MO les conditions de garantie et de maintenance des techniques innovantes. Effectuer un bilan de recette interne, en fonction de la configuration utilisée. Édicter les préconisations relatives à la configuration de recette. Attitude des acteurs Prévoir la participation des acteurs de la MO (validation, recette). Rédiger un plan de charge des acteurs de la MO. Analyser les causes de l'instabilité de l'équipe. Adopter des mesures y remédiant. Adopter un plan de livraison compatible avec les moyens de production de l'équipe. Alerter la ME et la MO sur les impacts résultant de l'instabilité de l'équipe. Réunir l'équipe, décrire les enjeux, proposer aux personnels la visibilité au-delà du projet. Capacité des acteurs Compléter la planification des prises de connaissance et formations nécessaires. En fonction des écarts, émettre des préconisations pour tendre vers les prestations attendues. Préconiser le suivi des prestations par des indicateurs appropriés. Faire valider par un expert technique l'adéquation entre les fonctions de la solution et les attentes. S'il n'y a pas adéquation totale de la solution technique, proposer des solutions correctrices.

77 Génie logiciel (2004 – 2005) 77 ENSEIRB Trouver les solutions pour réduire les risques critiques (6/11) Facteurs situationnels Parades Stabilité de lenvironne- ment Figer une version de référence, avec recette formelle. Gérer les évolutions sous forme de versions. Acter les modifications en comité et modifier/réactualiser le planning de manière contractuelle. Vérifier que la MO met en œuvre une conduite du changement adaptée aux changements organisationnels. Définir et borner les prestations et les fournitures annexes (formation, conduite du changement). Décrire les livrables, les acteurs, les pré-requis et faire acter en comité. Formalisation de linformation Définir et borner les critères de qualité à respecter (PAQ). Planifier et exécuter des revues de documents conformément au PAQ. Formalisation des processus Définir et borner les critères de qualité à respecter (PAQ). Planifier et exécuter des revues de documents conformément au PAQ. Stabilité de linformation et des processus Utiliser le journal et les fiches de modification. Faire acter en comité que les fiches de modification sont contractuelles, leur aval valant avenant. Spécificité du système dinformation Alerter la ME sur les impacts de la carence de l'équipe en compétences fonctionnelles.

78 Génie logiciel (2004 – 2005) 78 ENSEIRB Trouver les solutions pour réduire les risques critiques (7/11) Facteurs situationnels Parades Compréhen- sion du système existant Faire une liste des interfaces. Prévoir une phase de clarification des interfaces au début du projet. Organiser la structure de coordination des interfaces dès le début du projet. Prévoir des tests détaillés des interfaces avec les systèmes existants Importance stratégique Définir les livrables attendus et les livrables à fournir aux autres projets. Pour chaque interface avec les autres projets, donner la date de livraison prévue et les conséquences des dérives. Importance des changements organisation- nels Vérifier que la MO met en œuvre une conduite du changement adaptée aux changements organisationnels. Disponibilité, clarté et stabilité des besoins Soumettre les points ambigus à la MO afin qu'elle précise sa position. Acter en comité les décisions prises sur le périmètre fonctionnel. Faire un relevé exhaustif des écarts fonctionnels et faire valider par la MO. Qualité des spécifications existantes Planifier et exécuter des revues de documents conformément au PAQ.

79 Génie logiciel (2004 – 2005) 79 ENSEIRB Trouver les solutions pour réduire les risques critiques (8/11) Facteurs situationnels Parades Importance des changements technologi- ques Pour les techniques innovantes, définir avec la MO les achats de licences et droits d'utilisation. Définir avec la MO les conditions d'acceptation (fonctions, performances) des techniques innovantes. Définir avec la MO les conditions de garantie et de maintenance des techniques innovantes. Nouveauté de la technologie cible Planifier des tâches de qualification et d'intégration des produits ou composants nouveaux. Impliquer la MO sur la validation de l'architecture technique. Provoquer la mise en place d'une task-force MO-ME pour valider l'architecture technique. Taille de la phase Lotir. Indiquer pour chaque lot, la liste des livrables (documents, logiciels, jeux d'essais, …). Établir les priorités du projet en fonction des contraintes de la MO. Planifier des livraisons partielles et organiser les recettes correspondantes. Complexité de la migration Remonter les charges sous-estimées ou oubliées et actualiser les ratios utilisés. Nombre de sous-traitants Définir clairement le processus de suivi des sous-traitants et évaluer les charges associées. Remonter les charges de suivi des sous-traitants et actualiser les ratios correspondants.

80 Génie logiciel (2004 – 2005) 80 ENSEIRB Trouver les solutions pour réduire les risques critiques (9/11) Facteurs situationnels Parades Nombre dinterfaces avec dautres adaptations du SI Planifier l'intégration en environnement dexploitation pour MO, ME, exploitants, utilisateurs. Pour l'intégration en environnement dexploitation, décrire composants, interfaces, architectures. Nombre dacteurs de la phase Actualiser régulièrement le planning, dans ses versions détaillées et dans sa version globale. Affecter des charges aux prestations de pilotage, expertises, qualité. Affecter clairement les budgets des différentes équipes. Communiquer à tous le planning global. Identifier clairement les responsabilités respectives, notamment pour vérification et coordination. Adopter une montée en charge maîtrisable. Si elle est rapide prévoir un encadrement renforcé. Complexité de la technologie du projet Présenter en comité les impacts des incidents (charges, délais) dus à la complexité de la technologie. Alerter le management sur les impacts du manque de support technique en charges et en délais. Alerter le management sur les impacts de l'absence de vision globale par un architecte technique maîtrisant le projet. Nouveauté de ladaptation du SI Identifier un expert métier et prévoir une charge d'intervention d'un tel expert. Prévoir une participation renforcée d'utilisateurs (validation, exécution des recettes). Prévoir une charge d'étude permettant d'appréhender le système existant.

81 Génie logiciel (2004 – 2005) 81 ENSEIRB Trouver les solutions pour réduire les risques critiques (10/11) Facteurs situationnels Parades Conformité au planning Alerter la MO sur les impacts (charges, délais) dus aux délais de validation. Proposer un dispositif de validation renforcé(assistance,..) pour satisfaire aux délais. Faire valider par la MO les changements de produit ou composants, ainsi que leurs impacts. Si le taux de modifications est déraisonnable, provoquer un comité sur les modifications. Conformité au budget Établir les modalités de recette (objectifs, environnements, jeux d'essais,...). Établir un relevé des avenants nécessaires, suite aux modifications et incidents. Dépendance envers les sous-traitants Prévoir les instances adaptées pour coordonner et contrôler les partenaires. Formaliser les dispositions de contrôle des sous-traitants. Planifier les réunions de coordination des sous-traitants. Obtenir des sous-traitants un engagement de qualité des prestations (livrables, délais, performances). Dépendance envers dautres adaptations du SI Définir clairement les rôles et responsabilités relevant de la maîtrise d'ouvrage (coordination inter-projets). Aux comités, suivre le plan d'avancement de la MO. Si défaillance proposer l'étude de solutions. Obtenir en début de projet, toutes les garanties sur la disponibilité des interlocuteurs de la MO.

82 Génie logiciel (2004 – 2005) 82 ENSEIRB Trouver les solutions pour réduire les risques critiques (11/11) Facteurs situationnels Parades Formalisation de la relation client - fournisseur Planifier la charge et le délai de qualification des livrables issus des fournisseurs et sous-traitants. Remonter les charges de recette des produits externes et actualiser les ratios correspondants. Conditionner la recette des prestations des fournisseurs et sous-traitants à l'obtention de la recette MO. Capacité de léquipe projet Renforcer le dispositif d'encadrement intermédiaire (responsables de lots). Formaliser en détail les normes et standards de développement. Exercer de manière exhaustive les vérifications et contrôles prévus au PAQ. Alerter la ME sur les impacts des carences de l'équipe en compétence technique. Nouveauté de la technologie du projet Ajuster la planification avec les charges réelles d'installation de l'environnement de développement. Proposer que le prototype devienne la référence du système, à compter de la date où il est livré. Disponibilité dune technique de projet adéquate Figer des versions de référence des progiciels et définir les impacts de changements de version. Spécifier dans l'architecture technique, les contraintes de stabilité des versions (logiciels de base, SGBD).

83 Génie logiciel (2004 – 2005) 83 ENSEIRB Piloter la mise en œuvre des solutions (1/8) La maîtrise des risques en cours de projet nécessite un suivi précis des solutions mises en œuvre pour réduire les risques critiques. Cette activité implique le choix dindicateurs permettant de surveiller en continu lévolution des charges et des délais. Une première série de quatre tableaux permet de classer les natures de risques engendrées par les facteurs situationnels par grands types de risques. Les trois tableaux suivants proposent des indicateurs de suivi des grands types de risques.

84 Génie logiciel (2004 – 2005) 84 ENSEIRB Piloter la mise en œuvre des solutions (2/8) 1ENJEUXLe système n'atteindra pas les enjeux fixés ENJBesoins antagonistes ENJLe système d'information n'atteint pas ses objectifs ENJSystème d'information inadéquat ENJCritères non atteignables ENJBesoins incertains, mal spécifiés et changeants 2CONTRIB. MOLa maîtrise d'ouvrage ne pourra pas assurer la contribution nécessaire CMOStructure consultative difficile à mettre en place CMOÉquipe de diffusion trop faible en moyens CMOManque de participation des acteurs CMOManque d'implication des cadres et des agents 3PILOTAGELa maîtrise d'œuvre ne maîtrise pas assez le pilotage du projet PILStructure organisationnelle du projet insuffisante PILDifficulté d'appropriation du domaine PILDifficulté à trouver des experts PILPerte de contrôle du projet 4DELAISLes délais seront dépassés DELQualité médiocre des livrables DELRetards de livraison DELBesoins changeants. Problèmes d'intégration

85 Génie logiciel (2004 – 2005) 85 ENSEIRB Piloter la mise en œuvre des solutions (3/8) 5SPECIFLes spécifications ne seront pas validées en temps voulu SPEDifficulté à trouver un consensus et à satisfaire les besoins. SPELe dictionnaire de données est imprécis et ne répond pas aux exigences des métiers SPEValidations incomplètes SPERègles de gestion oubliées ou mal formalisées SPEComportement des objets mal compris SPEBesoins évolutifs (modification d'objectif) SPEImpossibilité de valider et de réceptionner les livrables SPENombreuses orientations et décisions remises en cause SPEInformations, tableaux, graphiques incompréhensibles SPEIncapacité à formaliser 6RECETTELes recettes ne seront pas prononcées comme prévu RECLe système informatique ne traite pas toutes les fonctions demandées par le maître d'ouvrage RECLe système informatique traite partiellement certaines fonctions RECLe système informatique traite certaines fonctions avec des erreurs de gestion RECLe système informatique ne répond pas aux normes souhaitées et manque de précision

86 Génie logiciel (2004 – 2005) 86 ENSEIRB Piloter la mise en œuvre des solutions (4/8) 7DEMARRLes conditions de mise en service et de déploiement ne seront pas réunies DEMSites hétérogènes, équipés de versions différentes de l'application DEMLes données sont trop précises, fastidieuses à saisir, donc partiellement saisies DEMLes données sont difficiles à qualifier DEML'échelle des données est mal choisie DEMLes données sont incomplètes et ne répondent à tous les cas d'utilisation DEM La plateforme de développement ne fait pas partie des architectures recommandées et pose des problèmes avec les plateformes cibles DEMSystème d'information existant inadéquat DEMInterfaces incertaines avec d'autres systèmes 8EXPLOITLes critères d'exploitabilité ne seront pas atteints EXPLe système informatique manque de fiabilité EXPLe système informatique ne peut pas être installé sur tous les matériels des utilisateurs EXPTous les sites utilisateurs n'ont pas la même version dans les architectures déconcentrées EXPLes plates formes cibles ont été mal définies et l'application ne peut pas s'installer EXPCapacités informatiques contraignantes

87 Génie logiciel (2004 – 2005) 87 ENSEIRB Piloter la mise en œuvre des solutions (5/8) 9UTILISLe système sera mal accepté ou rejeté par les utilisateurs UTI Le système est abandonné par les utilisateurs et partenaires qui développent d'autres applicatifs, indépendants du domaine cible UTILe système informatique ne fonctionne pas UTIApplication non utilisée UTIInsuffisance des propriétés de qualité UTIAdaptation du SI non acceptée 10EVOLUTLa maintenance et les évolutions du système seront difficiles et coûteuses EVOLe système informatique est difficile et coûteux à faire évoluer 11ARRETLe projet sera arrêté avant les termes prévus ARRSurcoûts possibles ARRCoûts imprévisibles ARRSystème d'information infaisable

88 Génie logiciel (2004 – 2005) 88 ENSEIRB Piloter la mise en œuvre des solutions (6/8) 1ENJEUXLe système n'atteindra pas les enjeux fixés ENJ-01Nombre d'écarts relevés suite aux validations des dossiersNb écarts ENJ-02Taux de dépassement du budget prévu% ENJ-03Taux de satisfaction des exigences des utilisateurs% 2CONTRIB. MOLa maîtrise d'ouvrage ne pourra pas assurer la contribution nécessaire CMO-01Nombre de jours*h moyen non fournis mensuellement par MONb jours*h CMO-02Nombre de jours*h impactés en charge pour MENb jours*h CMO-03Nombre de jours impactés en délais pour MENb jours 3PILOTAGELa maîtrise d'œuvre ne maîtrise pas assez le pilotage du projet PIL-01Taux de dépassement en charges% PIL-02Nombre de jours moyen de dépassement en délaisNb jours PIL-03Taux d'incidence des perturbations du projet (incidents, …)% PIL-04Nombre de demandes de modificationsNb modif. PIL-05Satisfaction des fournitures de la MO% PIL-06Satisfaction des fournitures des prestataires extérieurs% PIL-07Nombre d'interfaces / flux supplémentairesNb flux

89 Génie logiciel (2004 – 2005) 89 ENSEIRB Piloter la mise en œuvre des solutions (7/8) 4DELAISLes délais seront dépassés DEL-01Nombre de jours de retard moyen sur les livraisons des spécificationsNb jours DEL-02Nombre de jours de retard moyen sur les livraisons des logicielsNb jours DEL-03Nombre de jours de retard moyen sur les livraisons de matérielsNb jours DEL-04Taux de rotation de l'équipe de projet% 5SPECIFLes spécifications ne seront pas validées en temps voulu SPE-01Nombre de jours moyen de retard de validation par la MONb jours SPE-02Nombre d'anomalies bloquantes en phase de validation des maquettesNb anos SPE-03Nombre d'anomalies bloquantes en phase de validation des dossiersNb anos SPE-04Nombre de demandes de modificationsNb modif. REC-01Nombre d'anomalies bloquantes par jour et par valideur en phase d'intégrationNb anos/J/H REC-02Nombre d'anomalies bloquantes par jour et par valideur en phase de recetteNb anos/J/H REC-03Satisfaction des conditions de recette% 7DEMARRLes conditions de mise en service et de déploiement ne seront pas réunies DEM-01Nombre de jours de retard sur la disponibilité des moyens de mise en serviceNb jours

90 Génie logiciel (2004 – 2005) 90 ENSEIRB Piloter la mise en œuvre des solutions (8/8) 8EXPLOITLes critères d'exploitabilité ne seront pas atteints EXP-01Taux d'évolution du stock d'anomalies% EXP-02Écart entre performances attendues et performances constatées% EXP-03Délai moyen de correction d'une anomalieNb jours EXP-04Taux d'interconnexion sensibles avec d'autres systèmes% 9UTILISLe système sera mal accepté ou rejeté par les utilisateurs UTI-01Nombre d'écarts fonctionnels relevés suite aux validations des dossiersNb écarts UTI-02Taux de satisfaction des exigences des utilisateurs% UTI-03Ecart entre performances attendues et performances constatées% 10EVOLUTLa maintenance et les évolutions du système seront difficiles et coûteuses EVO-01Délai de prise en charge d'une anomalieNb jours EVO-02Délai moyen de correction d'une anomalieNb jours EVO-03Taux de réécriture de code% EVO-04Taux d'interconnexions sensibles avec d'autres systèmes% EVO-05Taux de réutilisation de composants% 11ARRETLe projet sera arrêté avant les termes prévus ARR-01Le retard dépasse le seuil tolérableNb jours ARR-02Le périmètre fonctionnel ne peut pas être définiNb écarts ARR-03L'impact financier dépasse le seuil tolérableMontant


Télécharger ppt "Version 1.0 GENIE LOGICIEL Lanalyse et la gestion des risques Hervé DOMALAIN CNAM Aquitaine – 2004 / 2005."

Présentations similaires


Annonces Google