GENIE LOGICIEL L’analyse et la gestion des risques

Version 1.0

GENIE LOGICIEL L’analyse et

la gestion des risques

Hervé DOMALAINCNAM Aquitaine – 2004 / 2005

Génie logiciel (2004 – 2005) 2ENSEIRB

Sommaire

1. Généralités - définitions2. Analyse des risques en étude préalable et construction

de l’ingénierie du projet1. Pourquoi analyser les risques dès l’étude préalable ?2. Les facteurs situationnels3. Choix de la stratégie globale de développement

1. Stratégie de description2. Stratégie de construction et de déploiement

3. Maîtrise des risques en cours de projet


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.


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.


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.


Les activités relativesà la gestion des risques (2/2)

Début du projet

Fin du projet

Analyse des risques

CapitalisationRéduction des risques

Suivi des risques

Actions préventives

Actions curatives


Le schéma de principede gestion des risques

Facteurs de risques

Facteurs de risques

Conséquences inacceptables et

impacts

Conséquences inacceptables et

impacts

Actions préventives ou

curatives

Actions préventives ou

curatives

Réduisent ou évitentSont causés par

Agissent sur

Entraînent


Déclinaison du schémasur une occurrence

Réduit ou éviteEst causé par

Agit sur

Entraîne

Retard au déploiementFonctionnalité non

disponible

Développement itératifou incrémental

Augmentation desressources

Sous-estimationsdes charges dedéveloppement


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.


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.


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.


Sommaire






Construire l’ingé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 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.


Construire l’ingénierie du projet (2/2)

Contextedu projet

Objectifs etexigences

de la maîtrised’ouvrage

Contextedu projet

Objectifs etexigences

de la maîtrised’ouvrage

Constructionde l’ingénierie

du projet

An

alys

e d

es r

isq

ues

An

alys

e d

es r

isq

ues

Str

atég

ie d

e d

ével

op

pem

ent

Str

atég

ie d

e d

ével

op

pem

ent

Pla

n d

e ja

lon

nem

ent

Pla

n d

e ja

lon

nem

ent

Pla

n d

e li

vrai

son

sP

lan

de

livr

aiso

ns


Choisir la stratégie globalede 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.


Déterminer le plan de jalonnementet 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.


Sommaire






Analyser les exigencesqualité 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.


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.


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).


Classification des facteurs situationnels

IncertitudeComplexité

DOMAINE CIBLE

DOMAINE DU PROJET

Système d’information

Système informatique

Charges

Structure

Acteurs

Technologie

IncertitudeComplexité


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.


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.


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


Système d’informationou 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


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.


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


Description des tableauxde 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’informationou

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éalableet/ou

Analyseet/ou

Conceptionet/ou

Réalisation et/ou

Testset/ou

Recette et/ou

Déploiement

1 = faible2 = moyenne 3 = forte 4 = très forte

1 = mineur2 = moyen 3 = important4 = majeur


xNiveau

d’impact

Type et description du facteur

Quelle phase est concernée par le facteur ?

Valorisation du risque

Nature du risque engendré par le facteur


Facteurs de complexité du domaine cible - système d’information (1/3)


Description du facteur de complexitéet exemples de risques engendrés

Phases concernées


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.






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.


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. Le système d’information n’atteint 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 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.






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.



Facteurs de complexité du domaine cible - système informatique (1/3)



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 fonctionne pas.

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.






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.


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.






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


Facteurs d’incertitude du domaine cible - système d’information (1/4)

Facteur d’incertitude

Description du facteur d’incertitudeet 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.


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.






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.


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.


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).






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.


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. Application non utilisée.






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.


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.



Facteurs d’incertitude du domaine cible - système informatique



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.


Nouveauté de la technologie cible

La technologie cible est-elle novatrice par rapport à l’état de l’art de la technique ? Insuffisance des propriétés qualitative. Adaptation du S.I. non acceptée. Coûts de projet imprévisibles.



Facteurs de complexité du domaine du projet – charges du projet



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)


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


Facteurs de complexité du domaine du projet – structure du projet



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) ?Perte de contrôle du projet.



Facteurs de complexité du domaine du projet – acteurs du projet



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.



Facteurs de complexité du domaine du projet – technologie du projet



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


Facteurs d’incertitude du domaine du projet – charges du projet



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.


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 ?Qualité médiocre des livrables.Retards de livraison.



Facteurs d’incertitude du domaine du projet – structure du projet



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.

•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


Facteurs d’incertitude du domaine du projet – acteurs du projet



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.



Facteurs d’incertitude du domaine du projet – technologie du projet



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 ? Qualité médiocre et retards sur les livraisons. Coûts imprévisibles pour le projet.



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 acteursTaille du domaine cibleTaille de la distributionComplexité de l'informationComplexité des processus

Complexité des donnéesComplexité des fonctions automatiséesComplexité des propriétés qualitativesNombre de duplications du système informatiqueComplexité de la technologie cible

Attitude des acteursCapacité des acteursStabilité de l'environnementFormalisation de l'informationFormalisation des processusStabilité de l'information et des processusSpécificité du système d'informationCompréhension du système existantImportance stratégiqueImportance des changements organisationnelsDisponibilité, clarté et stabilité des besoinsQualité des spécifications existantes

Importance des changements technologiques


Ce sont tous les facteurs situationnels du domaine cible.


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.


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.



0

2

4

6

8

10

12

14

16

18

Hétérogénéitédes acteurs

Taille dudomaine cible

Taille de ladistribution

Complexité del'information

Complexitédes

processus

Complexitédes données

Complexitédes fonctionsautomatisées

Complexitédes propriétés

qualitatives

Nombre deduplicationsdu systèmeinformatique

Complexité dela technologie

cible

Exemple de graphe (une analyse)


0

2

4

6

8

10

12

14

16

18

Hé

téro

gé

né

itéd

es

act

eu

rs

Ta

ille

du

do

ma

ine

cib

le

Ta

ille

de

lad

istr

ibu

tion

Co

mp

lexi

té d

el'i

nfo

rma

tion

Co

mp

lexi

téd

es

pro

cess

us

Co

mp

lexi

téd

es

do

nn

ée

s

Co

mp

lexi

téd

es

fon

ctio

ns

au

tom

atis

ée

s

Co

mp

lexi

téd

es

pro

pri

été

sq

ua

lita

tive

s

No

mb

re d

ed

up

lica

tion

sd

u s

ystè

me

info

rma

tiqu

e

Co

mp

lexi

té d

ela

tech

no

log

ieci

ble


Exemple de graphe(3 analyses)


Sommaire






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.


Sommaire






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.


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.


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é

Simple Complexité de l’information

ou des processus

Complexité de l’organisation ou hétérogénéité des

acteurs

Certaine Participative Participative Conduite par des experts

Situation du projet en terme d’incertitude

Incertaine avec capacité des acteurs faible ou délais tendus

Conduite par des experts



Incertaine : autres cas d’incertitude

Participative Participative Conduite par des experts

Choix de la démarche de type organisationnel :


Sommaire






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.


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.


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 Certain ♦Incertain ♦

Tendus Simple Certain ♦ ♦Incertain ♦

Complexe Certain ♦Incertain ♦


Exemple 1 - Construction et déploiement unitaires

Étude préalable

Analyse

Conception

Réalisation

Tests

Recette

Déploiement


Exemple 2 - Construction incrémentale et déploiement unitaire

Étude préalable

Analyse lot 1

Conception lot 1

Réalisation lot 1Tests 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


Exemple 3 - Construction et déploiement itératifs

Version finale

Analyse V3Conception V3

Réalisation V3

Tests V3Déploiement V3

Recette V3Version 1

Étude préalable


Réalisation V1

Tests V1

Déploiement V1

Recette V1

Version 2


Réalisation V2

Tests V2

Déploiement V2

Recette V2


Exemple 4 - Construction itérative et déploiement unitaire

Prototype 2


Réalisation V2

Tests V2

Prototype 1

Étude préalable


Réalisation V1

Tests V1

Version finalisée


Réalisation V3

Tests V3

Déploiement

Recette


Sommaire






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.


Identifier et analyserles 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).


Les facteurs situationnels à étudier en cours de projet

Étude préalable

Analyse Conception

Réalisation

Tests

Recette

Déploiement

Phases Analyses des risques à réaliser

Étude préalable Domaine cibleItération 1

Domaine du projetPhase d’étude préalable

Analyse Domaine cibleitération 2

Domaine du projetPhase d’analyse

Conception Domaine cibleItération 3

Domaine du projetPhase de conception

Réalisation et tests Domaine cibleItération 4

Domaine du projetPhases de réalisation et tests

Recette Domaine cibleItération 5

Domaine du projetPhase de recette

Déploiement Domaine cibleItération 6

Domaine du projetPhase de déploiement


Mettre en évidence les risques critiques


Niveau d’impact

Très forte Forte Moyenne Faible

Majeur

Important

Moyen

Mineur

Risques critiques


Trouver les solutions pourré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.


Trouver les solutionspour réduire les risques critiques (2/11)

Facteurs situationnels

Parades


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édiairesAlerter 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.




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.Définir et borner les critères de qualité à respecter (PAQ).




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.




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.




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

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 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.




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.




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.


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.




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.




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.




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).


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.


Piloter la mise en œuvre des solutions (2/8)1 ENJEUX Le système n'atteindra pas les enjeux fixés

ENJ Besoins antagonistes

ENJ Le système d'information n'atteint pas ses objectifs

ENJ Système d'information inadéquat

ENJ Critères non atteignables

ENJ 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

CMO Équipe de diffusion trop faible en moyens

CMO Manque de participation des acteurs

CMO 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

PIL Difficulté d'appropriation du domaine

PIL Difficulté à trouver des experts

PIL Perte de contrôle du projet

4 DELAIS Les délais seront dépassés

DEL Qualité médiocre des livrables

DEL Retards de livraison

DEL Besoins changeants. Problèmes d'intégration


Piloter la mise en œuvre des solutions (3/8)

5 SPECIF Les spécifications ne seront pas validées en temps voulu

SPE Difficulté à trouver un consensus et à satisfaire les besoins.

SPE Le dictionnaire de données est imprécis et ne répond pas aux exigences des métiers

SPE Validations incomplètes

SPE Règles de gestion oubliées ou mal formalisées

SPE Comportement des objets mal compris

SPE Besoins évolutifs (modification d'objectif)

SPE Impossibilité de valider et de réceptionner les livrables

SPE Nombreuses orientations et décisions remises en cause

SPE Informations, tableaux, graphiques incompréhensibles

SPE 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

REC Le système informatique traite partiellement certaines fonctions

REC Le système informatique traite certaines fonctions avec des erreurs de gestion

REC Le système informatique ne répond pas aux normes souhaitées et manque de précision



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

DEM Les données sont trop précises, fastidieuses à saisir, donc partiellement saisies

DEM Les données sont difficiles à qualifier

DEM L'échelle des données est mal choisie

DEM Les données sont incomplètes et ne répondent à tous les cas d'utilisation

DEMLa plateforme de développement ne fait pas partie des architectures recommandées et pose des problèmes avec les plateformes cibles

DEM Système d'information existant inadéquat

DEM 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é

EXP Le système informatique ne peut pas être installé sur tous les matériels des utilisateurs

EXP Tous les sites utilisateurs n'ont pas la même version dans les architectures déconcentrées

EXP Les plates formes cibles ont été mal définies et l'application ne peut pas s'installer

EXP Capacités informatiques contraignantes



9 UTILIS Le système sera mal accepté ou rejeté par les utilisateurs

UTILe système est abandonné par les utilisateurs et partenaires qui développent d'autres applicatifs, indépendants du domaine cible

UTI Le système informatique ne fonctionne pas

UTI Application non utilisée

UTI Insuffisance des propriétés de qualité

UTI 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

ARR Coûts imprévisibles

ARR Système d'information infaisable



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 Nb jours*h

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 Nb jours

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



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 Nb jours

DEL-03 Nombre de jours de retard moyen sur les livraisons de matériels Nb jours

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 Nb jours

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 Nb anos

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 Nb anos/J/H

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 Nb jours


Piloter la mise en œuvre des solutions (8/8)8 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 Nb jours

EVO-02 Délai moyen de correction d'une anomalie Nb jours

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 Nb jours

ARR-02 Le périmètre fonctionnel ne peut pas être défini Nb écarts

ARR-03 L'impact financier dépasse le seuil tolérable Montant

GENIE LOGICIEL L’analyse et la gestion des risques

Documents

Transcript of GENIE LOGICIEL L’analyse et la gestion des risques