GENIE LOGICIEL L’analyse et la gestion des risques

GENIE LOGICIEL L’analyse et la gestion des risques
Hervé DOMALAIN CNAM Aquitaine – 2004 / 2005 Génie logiciel – CNAM Aquitaine – 2004 / 2005

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

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. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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

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 Facteurs de risque = facteurs situationnels ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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 ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Définition de l’analyse 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 d’ouvrage et côté maîtrise d’œuvre), s'inspirer d’une check-list de risques ou bien consulter les suivis de risques effectués sur des projets antérieurs. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Définition du suivi des risques
Cette activité est réalisée à l’aide d’un 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é d’apparition 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. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Construire l’ingénierie du projet (1/2)
Construire l’ingénierie du projet signifie : Avant tout de choisir une stratégie globale de développement adaptée à la situation, 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 d’ouvrage. Cette ingénierie doit permettre de répondre aux exigences qualité et aux objectifs de l’opération définis par le maître d’ouvrage. Le choix d’une stratégie de développement correspond au choix d’un cycle de vie (ou d’une combinaison de cycles de vie). ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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

Choisir la stratégie globale de développement
Il s’agit de déterminer, à partir d’une 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 qu’il 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 qu’un autre le sera par incréments. Dans le cadre d’un projet, le choix de la stratégie globale s’effectue pendant la phase d’étude préalable. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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, c’est-à-dire de ses caractéristiques et d’une estimation globale des charges. Jalons = points de décision Le plan de jalonnement et le plan de livraisons seront abordés en détail dans la parie « Structuration des projets informatiques ». ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Analyser les exigences qualité du projet
Il s’agit de prendre en compte les exigences définies par la maîtrise d’ouvrage (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 l’analyse des risques. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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, c’est-à-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. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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). ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Classification des facteurs situationnels
Incertitude Complexité DOMAINE CIBLE DOMAINE DU PROJET Système d’information Système informatique Charges Structure Acteurs Technologie ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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

Domaine du projet Le domaine du projet se rapporte à l’organisation responsable de l’adaptation du système d’information, à 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, d’autorité 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. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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 ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Système d’information 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 ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Caractéristiques de connaissances
Les caractéristiques de connaissances regroupent les connaissances nécessaires pour gérer la situation d’un 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 d’incertitude, une situation est certaine, modérée ou incertaine. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Complexité ou incertitude ?
La tempête de décembre 1999 Le passage à l’an 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 ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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é d’apparition Niveau d’impact Poids du risque Système d’information ou Système informatique Hétérogénéité des acteurs Les acteurs du système d’information sont–ils hétérogènes pour des raisons d’organisation, de politique, de spécificité du domaine ou des individus ? Exemple d’acteurs : utilisateurs, supérieurs hiérarchiques d’utilisateurs, gestionnaires d’applications, … Besoins antagonistes. L’adaptation du système d’information n’est pas acceptée. Étude préalable et/ou Analyse Conception Réalisation Tests Recette Déploiement 1 = faible 2 = moyenne 3 = forte 4 = très forte 1 = mineur 2 = moyen 3 = important 4 = majeur x Type et description du facteur Valorisation du risque Quelle phase est concernée par le facteur ? Le travail d’analyse des risques est itératif : il doit être produit à chaque phase du projet afin de réajuster en permanence la stratégie de réduction des risques. Les tableaux sont utilisables quelque soit la phase. Les facteurs situationnels ne sont par contre pas applicables pour toutes les phases (voir colonne 4). Nature du risque engendré par le facteur ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Facteurs de complexité du domaine cible - système d’information (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 d’information sont–ils hétérogènes pour des raisons d’organisation, de politique, de spécificité du domaine ou des individus ? Exemple d’acteurs : utilisateurs, supérieurs hiérarchiques d’utilisateurs, gestionnaires d’applications, ...  Besoins antagonistes.  L’adaptation du système d’information n’est 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 d’unités organisationnelles ou en nombre de cas d’utilisation ?  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. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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 d’information n’atteint 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 l’application. Étude préalable Analyse Déploiement Complexité de l’information Quelle est la complexité de l’information 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 d’utilisateurs (exemples : données scientifiques, données juridiques, données cartographiques, données environnementales, données économiques…) ? En termes UML, la complexité de l’information peut se mesurer au vu du nombre et du type d’entités métier. 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 d’utilisation. 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 d’autres applicatifs. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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 d’interfaces, en degré de complexité des règles de gestion et des algorithmes, en nombre d’utilisateurs « 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 d’utilisation, des diagrammes de séquence, des diagrammes de collaboration, des diagrammes d’activité.  Le système d’information n’atteint pas ses objectifs.  Le système est abandonné par les utilisateurs et partenaires qui développent d’autres applicatifs, indépendants du domaine cible. Étude préalable Analyse Déploiement ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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 d’individus, 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 d’accès demandées ? En termes UML, la complexité des données peut se mesurer au vu du nombre de classes, d’associations, 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 traite pas toutes les fonctions demandées par le maître d’ouvrage.  Le système informatique traite partiellement certaines fonctions.  Le système informatique traite certaines fonctions avec des erreurs de gestion. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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 d’ouvrage ? 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 n’ont pas la même version, dans les architectures déconcentrées. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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 l’architecture technique utilisée pour le développement et l’exploitation du système informatique ?  Le système informatique ne fonctionne pas.  Les plates-formes cibles ont été mal définies et l’application ne peut pas s’installer.  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 ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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

Facteur d’incertitude Description du facteur d’incertitude et exemples de risques engendrés Phases concernées Formalisation de l’information Est-il aisé de formaliser et de décrire les informations à partir des spécifications de la maîtrise d’ouvrage ?  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 ?  Incapacité à formaliser. Stabilité de l’information et des processus L’information est-elle stable du point de vue de son environnement, c’est-à-dire compte tenu de la fréquence, du nombre et du type de changements ou d’évolutions prévisibles ?  Besoins évolutifs (modification d’objectif). ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Facteur d’incertitude Description du facteur d’incertitude et exemples de risques engendrés Phases concernées Spécificité du système d’information Quelle est la spécificité du système d’information : original, peu usuel, nécessitant un développement spécifique très sophistiqué ?  Difficulté à trouver des experts.  Difficulté d’appropriation 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 d’information existant par les acteurs ?  Système d’information existant inadéquat.  Coûts imprévisibles.  Application non utilisée. Importance stratégique Quelle est l’importance stratégique du SI ?  Manque d’implication des cadres et des agents au niveau de la maîtrise d’ouvrage. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Facteur d’incertitude Description du facteur d’incertitude et exemples de risques engendrés Phases concernées Importance des changements organisation-nels Quel est l’impact 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 d’ouvrage sont-ils stables ou évolutifs ?  Besoins incertains, mal spécifiés et changeants.  Interfaçage avec d’autres systèmes mal défini. Qualité des spécifications existantes Quelle est la qualité des spécifications de la maîtrise d’ouvrage et des documentations des phases antérieures ?  Système d’information inadéquat.  Coûts de projet imprévisibles. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Facteurs d’incertitude du domaine cible - système informatique
Facteur d’incertitude Description du facteur d’incertitude et exemples de risques engendrés Phases concernées Importance des changements technologi-ques Quelle est l’importance du changement et l’impact provoqués par l’adaptation du système d’information (le logiciel) ?  Insuffisance des propriétés qualitative.  Adaptation du S.I. non acceptée.  Coûts imprévisibles pour l’organisation. É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 l’art de la technique ?  Coûts de projet imprévisibles. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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 d’anné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. Loi de Brooks (1975): « Adding more programmers to a late project make it later » Soit N programmeurs, le nombre de canaux de communications C est égal à: C = N*(N-1)/2. Lorsque la taille du groupe augmente, le nombre de liens de communication potentiels entre membres augmente proportionnellement au carré de la taille du groupe. Le nombre de liens potentiels dans un groupe de N personnes est N*(N-1). S'il y a deux membres A et B, il y a deux liens AB et BA. S'il y a trois membres A, B et C, il y a six liens. Si l'on considère que les liens AB et BA forment un même canal alors pour un groupe de 2 personnes il y a 1 canal de communication et pour un groupe de trois il y a 3 canaux. Pour un groupe de 5 personnes on trouve 10 canaux de communication. Il y a donc, même pour les petits groupes, beaucoup de canaux de communications potentiels. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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 d’interfaces avec d’autres adaptations du SI Quelle est la difficulté de contrôler la phase considérant le nombre d’interfaces externes avec d’autres adaptations du système d’information (d’autres logiciels appartenant au même SI) ? Déploiement ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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 d’acteurs de la phase Quel est le nombre de parties prenantes qui interviennent sur la phase, en tant qu’utilisateurs, experts, développeurs, clients, gestionnaires, ... ? Perte de contrôle du projet. Étude préalable Analyse Conception Réalisation Tests Recette Déploiement ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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 ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Facteurs d’incertitude du domaine du projet – charges du projet
Facteur d’incertitude Description du facteur d’incertitude et exemples de risques engendrés Phases concernées Nouveauté de l’adaptation du SI Le caractère innovant de l’adaptation du S.I. (logiciel) a-t-il un impact sur le rendement de l’équipe projet ? Système d’information 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 l’urgence du projet, est-il possible ? Qualité médiocre des livrables. Coûts accrus pour le projet. 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 d’ouvrage, est-il possible ? Retards de livraison. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Facteurs d’incertitude du domaine du projet – structure du projet
Facteur d’incertitude Description du facteur d’incertitude 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 d’autres adaptations du SI Le projet est-iI interfacé avec d’autres projets sur lesquels les intervenants (maîtrise d’œuvre et maîtrise d’ouvrage) n’ont aucun contrôle ? Besoins changeants. Problèmes d’intégration et de déploiement. Recette Formalisation de la relation client - fournisseur La contractualisation de la prestation est-elle suffisante ? Adaptation du SI (logiciel) non acceptée. Étude préalable ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Facteurs d’incertitude du domaine du projet – acteurs du projet
Facteur d’incertitude Description du facteur d’incertitude et exemples de risques engendrés Phases concernées Capacité de l’équipe projet Quels sont les compétences, les connaissances, les capacités, l’expérience, l’engagement 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 ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Facteurs d’incertitude du domaine du projet – technologie du projet
Facteur d’incertitude Description du facteur d’incertitude 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 l’art 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é d’une technique de projet adéquate La technologie susceptible d’être utilisée est-elle adaptée aux environnement serveurs et aux plates-formes clients ? Déploiement ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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 : 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 Hétérogénéité des acteurs Taille du domaine cible Taille de la distribution Complexité de l'information Complexité des processus Importance des changements technologiques Nouveauté de la technologie cible Attention, les facteurs du domaine du projet (listés ci-dessous) permettent de réaliser l’analyse des risques de la phase d’étude préalable, ce qui permet de qualifier cette phase : Ce sont tous les facteurs situationnels du domaine cible. 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 Taille de la phase Nombre de sous-traitants Nombre d'acteurs de la phase Nouveauté de l'adaptation du SI Conformité au planning Conformité au budget Formalisation de la relation client - fournisseur Capacité de l'équipe projet ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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

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

Exemple de graphe (une analyse) ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Exemple de graphe (3 analyses) ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Les processus de description, de construction et de déploiement
L’objectif est de déterminer la meilleure solution pour décrire (spécifier), construire (réaliser) et déployer sur l’ensemble des sites concernés, le futur système d’information. La description dans le cadre du projet : Processus consistant à analyser et à concevoir le système et en particulier son champ d’application, 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, d’analyse 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 d’exé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 n’est mis en œuvre que dans le projet de déploiement. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Démarche de type conceptuel
La description d’un système s’appuie 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 l’information 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 s’agit 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 s’agit d’expérimenter le futur système avec des utilisateurs. Cela demande par exemple de réaliser des prototypes avec ou sans modélisation préalable. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Démarche de type organisationnel
Une démarche de type organisationnel indique comment les acteurs du projet travaillent avec les utilisateurs du système d’information 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é d’experts 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. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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. Choix de la démarche de type organisationnel : Situation du projet en terme de complexité Simple Complexité de l’information ou des processus Complexité de l’organisation ou hétérogénéité des acteurs Certaine Participative Conduite par des experts Situation du projet en terme d’incertitude Incertaine avec capacité des acteurs faible ou délais tendus Incertaine : autres cas d’incertitude ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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 s’agit, 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. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Facteurs situationnels Démarche de construction et de déploiement
Stratégies de construction et de déploiement – tableau d’aide à la décision Facteurs situationnels Démarche de construction et de déploiement Délais Degré de complexité Degré d’incertitude Unitaire Incrémentale Itérative Normaux Simple Certain ♦ Incertain Complexe Tendus D’une manière générale, on estime que les stratégies doivent être de type : itératif lorsque la situation est incertaine, incrémental lorsque la situation est complexe, mais certaine, incrémental ou itératif lorsque les délais sont tendus (installer quelque chose aussi vite que possible), unitaire lorsque les délais sont normaux et la situation est simple et certaine. Il convient toutefois de s’orienter vers une stratégie itérative lorsque l'importance des changements organisationnels est grande. Bien entendu, ce choix est à adapter par le chef de projet : un projet peut être caractérisé par une simplicité fonctionnelle et par une incertitude technique, ce qui amènera à adapter plus finement la stratégie du projet. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Exemple 1 - Construction et déploiement unitaires
Étude préalable Analyse Conception Réalisation Tests Recette Déploiement Le projet est simple. On utilise donc un schéma standard enchaînant les phases les unes après les autres sans découpage en lots ou en versions. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Exemple 2 - Construction incrémentale et déploiement unitaire
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 Étude préalable Analyse lot 1 Conception lot 1 Réalisation lot 1 Tests lot 1 Recette lot 1 Le système est fonctionnellement complexe. Par contre, la mise en place ne pose pas de problème particulier. La construction de l’application se réalise par incréments pour lesquels les spécifications ne sont pas remis en cause. L’accompagnement du changement, quant à lui, couvre l’ensemble du projet et le déploiement est réalisée en une seule fois. NOTA : Les tests et la recette du lot 3 concernent le lot lui-même, mais aussi les tests et le recette d’intégration. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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 2 Analyse V2 Conception V2 Réalisation V2 Tests V2 Déploiement V2 Recette V2 Version 1 Étude préalable Analyse V1 Conception V1 Réalisation V1 Tests V1 Déploiement V1 Recette V1 Si le projet est incertain et présente un risque d’acceptation ou d’organisation, la construction de l’application et son déploiement se réalisent par versions successives entre lesquelles les spécifications peuvent évoluer. L’objectif est de livrer aux utilisateurs des versions successives de l’application, de recueillir au plus tôt les demandes d’évolution afin de compléter les besoins et réaliser une nouvelle version. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Exemple 4 - Construction itérative et déploiement unitaire
Version finalisée Analyse V3 Conception V3 Réalisation V3 Tests V3 Déploiement Recette 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 Cette stratégie est une solution pour une architecture technique complexe. Dans ce cas, il est en effet décidé de livrer une seule version de l’application. Cependant, la complexité de l’architecture technique impose un processus de construction itératif. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

La démarche de maîtrise des risques
Elle consiste à : 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é, Mettre en évidence les risques critiques, Trouver les solutions pour les réduire, Piloter la mise en œuvre des solutions en surveillant les charges et les délais. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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 l’analyse 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). ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Les facteurs situationnels à étudier en cours de projet
Phases Analyses des risques à réaliser Étude préalable Domaine cible Itération 1 Domaine du projet Phase d’étude préalable Analyse itération 2 Phase d’analyse Conception Itération 3 Phase de conception Réalisation et tests Itération 4 Phases de réalisation et tests Recette Itération 5 Phase de recette Déploiement Itération 6 Phase de déploiement Étude préalable Analyse Conception Réalisation Tests Recette Déploiement ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Mettre en évidence les risques critiques
Probabilité d’apparition Niveau d’impact Très forte Forte Moyenne Faible Majeur Important Moyen Mineur Risques critiques ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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 l’information 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. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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…). Proposer une démarche conjointe de tests et de mesure. Complexité des propriétés qualitatives Prévoir l'approbation des critères par MO sur les jalons majeurs (recettes intermédiaires). ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Facteurs situationnels Parades Stabilité de l’environne-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 l’information 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 Stabilité de l’information 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 d’information Alerter la ME sur les impacts de la carence de l'équipe en compétences fonctionnelles. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

Facteurs situationnels Parades Nombre d’interfaces avec d’autres adaptations du SI Planifier l'intégration en environnement d’exploitation pour MO, ME, exploitants, utilisateurs. Pour l'intégration en environnement d’exploitation, décrire composants, interfaces, architectures. Nombre d’acteurs 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 l’adaptation 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. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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 d’autres 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. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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é d’une 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). ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

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 d’indicateurs 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. ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

1 ENJEUX Le système n'atteindra pas les enjeux fixés ENJ Besoins antagonistes Le système d'information n'atteint pas ses objectifs Système d'information inadéquat Critères non atteignables Besoins incertains, mal spécifiés et changeants 2 CONTRIB. MO La maîtrise d'ouvrage ne pourra pas assurer la contribution nécessaire CMO Structure consultative difficile à mettre en place Équipe de diffusion trop faible en moyens Manque de participation des acteurs Manque d'implication des cadres et des agents 3 PILOTAGE La maîtrise d'œuvre ne maîtrise pas assez le pilotage du projet PIL Structure organisationnelle du projet insuffisante Difficulté d'appropriation du domaine Difficulté à trouver des experts Perte de contrôle du projet 4 DELAIS Les délais seront dépassés DEL Qualité médiocre des livrables Retards de livraison Besoins changeants. Problèmes d'intégration ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

5 SPECIF Les spécifications ne seront pas validées en temps voulu SPE Difficulté à trouver un consensus et à satisfaire les besoins. Le dictionnaire de données est imprécis et ne répond pas aux exigences des métiers Validations incomplètes Règles de gestion oubliées ou mal formalisées Comportement des objets mal compris Besoins évolutifs (modification d'objectif) Impossibilité de valider et de réceptionner les livrables Nombreuses orientations et décisions remises en cause Informations, tableaux, graphiques incompréhensibles Incapacité à formaliser 6 RECETTE Les recettes ne seront pas prononcées comme prévu REC Le système informatique ne traite pas toutes les fonctions demandées par le maître d'ouvrage Le système informatique traite partiellement certaines fonctions Le système informatique traite certaines fonctions avec des erreurs de gestion Le système informatique ne répond pas aux normes souhaitées et manque de précision ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

7 DEMARR Les conditions de mise en service et de déploiement ne seront pas réunies DEM Sites hétérogènes, équipés de versions différentes de l'application 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 à tous les cas d'utilisation La plateforme de développement ne fait pas partie des architectures recommandées et pose des problèmes avec les plateformes cibles Système d'information existant inadéquat Interfaces incertaines avec d'autres systèmes 8 EXPLOIT Les critères d'exploitabilité ne seront pas atteints EXP Le système informatique manque de fiabilité Le système informatique ne peut pas être installé sur tous les matériels des utilisateurs Tous les sites utilisateurs n'ont pas la même version dans les architectures déconcentrées Les plates formes cibles ont été mal définies et l'application ne peut pas s'installer Capacités informatiques contraignantes ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

9 UTILIS Le 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 Le système informatique ne fonctionne pas Application non utilisée Insuffisance des propriétés de qualité Adaptation du SI non acceptée 10 EVOLUT La maintenance et les évolutions du système seront difficiles et coûteuses EVO Le système informatique est difficile et coûteux à faire évoluer 11 ARRET Le projet sera arrêté avant les termes prévus ARR Surcoûts possibles Coûts imprévisibles Système d'information infaisable ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

1 ENJEUX Le système n'atteindra pas les enjeux fixés ENJ-01 Nombre d'écarts relevés suite aux validations des dossiers Nb écarts ENJ-02 Taux de dépassement du budget prévu % ENJ-03 Taux de satisfaction des exigences des utilisateurs 2 CONTRIB. MO La maîtrise d'ouvrage ne pourra pas assurer la contribution nécessaire CMO-01 Nombre de jours*h moyen non fournis mensuellement par MO Nb jours*h CMO-02 Nombre de jours*h impactés en charge pour ME CMO-03 Nombre de jours impactés en délais pour ME Nb jours 3 PILOTAGE La maîtrise d'œuvre ne maîtrise pas assez le pilotage du projet PIL-01 Taux de dépassement en charges PIL-02 Nombre de jours moyen de dépassement en délais PIL-03 Taux d'incidence des perturbations du projet (incidents, …) PIL-04 Nombre de demandes de modifications Nb modif. PIL-05 Satisfaction des fournitures de la MO PIL-06 Satisfaction des fournitures des prestataires extérieurs PIL-07 Nombre d'interfaces / flux supplémentaires Nb flux ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

4 DELAIS Les délais seront dépassés DEL-01 Nombre de jours de retard moyen sur les livraisons des spécifications Nb jours DEL-02 Nombre de jours de retard moyen sur les livraisons des logiciels DEL-03 Nombre de jours de retard moyen sur les livraisons de matériels DEL-04 Taux de rotation de l'équipe de projet % 5 SPECIF Les spécifications ne seront pas validées en temps voulu SPE-01 Nombre de jours moyen de retard de validation par la MO SPE-02 Nombre d'anomalies bloquantes en phase de validation des maquettes Nb anos SPE-03 Nombre d'anomalies bloquantes en phase de validation des dossiers SPE-04 Nombre de demandes de modifications Nb modif. REC-01 Nombre d'anomalies bloquantes par jour et par valideur en phase d'intégration Nb anos/J/H REC-02 Nombre d'anomalies bloquantes par jour et par valideur en phase de recette REC-03 Satisfaction des conditions de recette 7 DEMARR Les conditions de mise en service et de déploiement ne seront pas réunies DEM-01 Nombre de jours de retard sur la disponibilité des moyens de mise en service ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

EXPLOIT Les critères d'exploitabilité ne seront pas atteints EXP-01 Taux d'évolution du stock d'anomalies % EXP-02 Écart entre performances attendues et performances constatées EXP-03 Délai moyen de correction d'une anomalie Nb jours EXP-04 Taux d'interconnexion sensibles avec d'autres systèmes 9 UTILIS Le système sera mal accepté ou rejeté par les utilisateurs UTI-01 Nombre d'écarts fonctionnels relevés suite aux validations des dossiers Nb écarts UTI-02 Taux de satisfaction des exigences des utilisateurs UTI-03 Ecart entre performances attendues et performances constatées 10 EVOLUT La maintenance et les évolutions du système seront difficiles et coûteuses EVO-01 Délai de prise en charge d'une anomalie EVO-02 EVO-03 Taux de réécriture de code EVO-04 Taux d'interconnexions sensibles avec d'autres systèmes EVO-05 Taux de réutilisation de composants 11 ARRET Le projet sera arrêté avant les termes prévus ARR-01 Le retard dépasse le seuil tolérable ARR-02 Le périmètre fonctionnel ne peut pas être défini ARR-03 L'impact financier dépasse le seuil tolérable Montant ENSEIRB Génie logiciel (2004 – 2005) Génie logiciel – CNAM Aquitaine – 2004 / 2005

GENIE LOGICIEL L’analyse et la gestion des risques

Présentations similaires

Présentation au sujet: "GENIE LOGICIEL L’analyse et la gestion des risques"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

GENIE LOGICIEL L’analyse et la gestion des risques

Présentations similaires

Présentation au sujet: "GENIE LOGICIEL L’analyse et la gestion des risques"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back