1. Cycle de Préparation au C.I.S.A
Système de développement
d’application, acquisition,
implémentation et maintenance
Mohamed SAÂD
I.T.M et consultant en Systèmes d’Information
1
2. SOMMAIRE
I- Développement d’applications informatiques
Approche traditionnelle SDLC
Rôles et responsabilités des groupes et des individus
Risques associés au développement logiciel
Utilisation des techniques d’analyse, de conception et de
développement
Description des phases du SDLC
Méthodologies de développement du logiciel
Systèmes de développement Orientés Objet
Prototypage
RAD
AGILE
Reengineering
Reverse Engineering
II- Pratiques de maintenance des systèmes d’information
Gestion du changement
Management de la configuration
Contrôle de la librairie logicielle
III- Pratiques de management des projets
2
3. SOMMAIRE
IV- Pratiques d’amélioration des processus de développement du
logiciel
ISO 9126
SPICE
CMM
CMMI
V- Audit des systèmes de développement, de l’acquisition et de la
maintenance
Gestion des projets
Étude de faisabilité
Expression des besoins
Processus d’acquisition logiciel
Étude détaillé et les phases de développement
Phase de tests
Phase implémentation
Revue de l’implémentation
Procédures de changement et processus de migration
3
5. I- La gestion de projets
Ensemble de processus permettant de maîtriser la
réalisation d’un projet et de la mener à terme :
Découpage et description du projet en :
processus,
phases,
étapes.
Définition claire des entrées des processus, des phases et
étapes, des productions attendues et des conditions de
passage d’une phase à l’autre.
Répartition claire du rôle et des responsabilités des acteurs
5
6. Caractéristiques d’un projet
Implique le changement.
Possède un début et une fin.
Requiert des activités.
Implique des individus.
Fait dans un but précis.
Destiné à un ou plusieurs clients
6
8. Facile ?
« Il n ’y a rien de plus risqué, de plus difficile à
planifier et de plus dangereux à gérer que
l’implantation d ’un nouveau système ! »
Résistance acharnée de tous ceux qui auraient
quelque chose à perdre par l ’implantation du
nouveau système
Soutien mitigé de tous ceux qui auraient quelque
chose à gagner
8
9. Les différents points de vue
Différents besoins et points de vue :
Le client,
Les utilisateurs,
L’équipe,
Le chef de projet doit les comprendre et essayer de
les satisfaire
9
10. Les différents points de vue
Client :
Livraison rapide
Peu coûteux
Fonctions nécessaires
Utilisateurs :
Beaucoup de fonctions
Convivialité
Fiabilité
Performance
10
11. Les différents points de vue
L’équipe :
Les responsables :
haute qualité
respect des délais
respect des budgets
aucune surprise
Les développeurs :
travail motivant
analyse seulement
plan de carrière
11
12. Les différents points de vue
L’équipe :
les opérateurs de maintenance :
facilité d’opération,
facilité de maintenance,
fiabilité,
documentation,
respect des standards.
12
14. Les principaux apports de la gestion de projets
Suivi de projets plus efficace
Prise en compte des risques au plus tôt
Mise en évidence des bénéfices
Gestion des points en suspens
Gestion des demandes de changement
14
15. Les enjeux de la gestion de projets
Le succès, l’échec d ’un projet repose sur :
La compréhension des processus de l’activité
Une définition claire du périmètre
Un contrôle permanent des résultats attendus et une vision
globale du «comment le projet est réalisé»
Une bonne anticipation et gestion des risques
Une gestion rigoureuse des changements
Une structure clairement définie : gestion, décision,
communication
15
18. Les Processus
Processus de lancement
Processus d’évolution du système d’information
Processus d’évolution du système informatique
1
Organisation
2
Opportunité
Et
Lancement
Du projet
3
Élaboration
D’une solution
-Solution avec progiciel
-Solution spécifique
Intégration et
Industrialisation
Du système
informatique
4
Mise en oeuvre
5 Conduite du changement
6 Management de l’équipe projet et Gestion de projet
7 Assurance et maîtrise de la Qualité
8 Urbanisme du Système d’Information
18
19. Activités supports
Suivi de projet : ensemble des moyens et des actions
qui permettent de mesurer ce qui a été fait et
d’évaluer ce qui reste à faire
Rédaction et suivi des contrats, relation avec les
utilisateurs
Estimation des charges, planification
Organisation des équipes
19
20. Activités supports
Gestion de la qualité :
Spécifications des caractéristiques de qualité
Dispositions préventives
Procédures de contrôle
20
21. Activités supports
Gestion de la documentation :
Gestion de la configuration :
Conception et mise à jour des règles :
identification
structuration
Production et diffusion.
Identification et gestion des composants et des
configurations :
constitution de versions sur la base des composants
bibliothécaire de projet
Maîtrise des modifications
21
24. Différentes tailles de projets
Petits projets :
Quelques personnes
Moins de 30 mois/homme
Environnement familier
Moyens projets :
5 à 10 personnes en pointe
De 30 à 100 mois/homme
24
25. Différentes tailles de projets
Grands projets :
Plus d'une dizaine de personnes en pointe,
Plus d’un niveau hiérarchique,
Accent mis sur la gestion de projet,
De 100 à 1000 mois/hommes.
Très gros projets :
Au moins 40 personnes en pointe,
Plus de 1000 mois/hommes,
Accent mis sur l’assurance qualité,
Plus le projet est important, plus les exigences en matière de
pilotage et de qualité seront fortes.
25
26. Différents types de projet
Projet de gestion
Projet système
Développement d’un progiciel
Projet de maintenance…
26
27. Différents types de projet
Différences :
Corps de métier
Répartition du temps par phase
Répartition des activités
Identique :
Problèmes humains
Processus supports
27
28. La maîtrise d’ouvrage
Donne son accord sur l’opportunité du projet,
S'assure du financement du projet,
Met en place les structures de pilotage,
Définit les objectifs du projet et les besoins
fonctionnels en regard de ces objectifs,
Fixe le cadre des travaux confiés au maître d'œuvre,
Effectue la recette définitive des prestations fournies
par le maître d'œuvre
28
29. La maîtrise d’ouvrage
Pilote la conduite du changement :
Organiser et suivre les actions de communication
formation, et production de la documentation
Et y participer le cas échéant
Pilote les actions de sous-traitance
NB : Certaines tâches peuvent être sous-traitées par
la maîtrise d'ouvrage : aide à la rédaction de la
définition des besoins et à la rédaction du cahier des
charges; assistance à la réception du produit;
pilotage des actions de conduite du changement, de
communication et de formation
29
31. La maîtrise d’œuvre
Constitue l’équipe projet et désigne le chef de projet,
Assure la gestion de projet (ordonnancement,
estimation, planification des tâches, gestion des
risques et suivi du projet)
Participe à la synthèse des besoins et réalise les
travaux d'étude
Réalise l'intégration du système (tests unitaires et
d'intégration),
Gère le contrôle qualité
Rend compte à la maîtrise d'ouvrage de l'avancement
du projet et lui soumet les éléments de choix relevant
de sa compétence
31
34. La méthode
Elle recouvre deux aspects :
Une démarche de développement (cycle de vie et cycle de
décision) :
phases
étapes
livrables
Une technique de conception.
modélisation
34
35. La méthode
Trois grandes approches de développement:
Une approche spécifique pour les développements sur
mesure
Une approche progiciel comprenant deux étapes
successives:
évaluation, sélection et conception de l'intégration dans
l'environnement fonctionnel et technique de l'entreprise
installation, adaptation, paramétrage, réalisation et mise en
œuvre
Le développement itératif pour satisfaire un besoin mal
connu et/ou peu formalisé. Démarche cyclique de
prototypage, validation et mise en œuvre
35
37. Comparaison des phases selon les méthodes
MERISE
AXIAL
SDM/S
MCP
Schéma Directeur
Diagnostic
Détermination des besoins
Exp. Des besoins
Étude préalable
Schéma directeur
Chois d’architecture système
Étude d’opportunité
Étude détaillée
Conception Fnelle
Spécif Externes
Étude du S.I
Étude technique
Conception Technique
Spécif Interne
Élaboration du C.des charges
Réalisation
Étude de migration
Programmation
Étude du S.I
Mise en oeuvre
Plan de mise en oeuvre
Tests
Programmation et essais
Évaluation économique
Intégration
Réception provisoire
Conception détaillée
Recette
Lancement sous contrôle
Réalisation et tests
Généralisation
Évaluation de l’application
Mise en production
Maintenance
Évaluation du projet
37
38. Les méthodes: quelques recommandations
Adopter une démarche et s’y tenir :
Choisir un cadre de référence (méthodes du marché et
méthodes "maisons"
Définir processus, activités, tâches, documentation,rôles et
acteurs
Avoir la volonté d’appliquer la démarche
Pas de règle miracle :
Pragmatisme
Bon sens
38
40. Estimation des charges
Répond à un besoin de prévision de durée, du coût et
de la répartition de l’effort à fournir (j/h) et permet de :
Faire une estimation de la rentabilité de l’investissement
Évaluer une durée vraisemblable du projet
Prévoir l’ordonnancement des étapes
Prévoir les ressources (affectation des personnes)
40
41. Estimation des charges
Besoins d’estimation à différents niveaux :
Projet : durée, budget, rentabilité
Phase : ajuster le découpage, décision de soustraiter,prévoir les délais, les ressources
Étape : planification, suivi du projet pour surveiller les
écarts, affecter les ressources
Tâche : planification fine pour suivre les équipes
41
43. Familles de méthodes
Il existe plusieurs familles de méthodes d'estimation:
Modèles algorithmiques (coût fonction de variables)
Jugement d'experts
Analogie (référence à d'autres projets similaires)
Estimation globale puis décomposition
Décomposition (estimation individuelle détaillée puis
agrégation)
43
44. Estimations: Modèles algorithmiques
Principe
Avantages :
Objectif,
Reproductible,
Simple,
Expérimental.
Inconvénients :
Consiste à estimer à l'aide de fonctions mathématiques des
variables jugées significatives.
Entrées subjectives,
Prise en compte des cas exceptionnels,
Il existe de nombreux
Modèles, lequel choisir ?
44
45. Estimations: Jugement d’experts
Principe
Avantages :
Estimation par des experts :
Soit individuellement,
Soit en groupe avec une méthode de consensus.
Prise en compte globale du contexte et des situations
exceptionnelles.
Inconvénients :
Estimation subjective en fonction des experts,
Non reproductible.
45
47. Estimations: Analogie
Avantages :
Capitalisation sur l'expérience
Bonne prise en compte du contexte
Réutilisation possible de composants
Inconvénients :
Degré de signification des projets passés
Prise en compte des situations exceptionnelles
47
48. Estimations: Globale
Principe :
Avantages :
Estimation globale partir des propriétés globales du
processus et du produit
Obtention d'une catégorie de projet parmi n à partir des
propriétés globales (Matrice des familles de projet en charge
et délai)
On n'oublie pas les éléments communs
Inconvénients :
Ne met pas en évidence les problèmes de détail
48
49. Estimations: Décomposition
Principe de la décomposition analytique
Avantages :
Estimation individuelle de chacun des éléments analytiques
(par activité et tâche) à partir de barèmes
Agrégation et ajout des coûts communs
Analyse plus approfondie
Répartition des risques
Permet l'itération
Inconvénients :
Plus long,
Ne regroupe pas les tâches similaires
49
50. Estimations: Décomposition
La décomposition nécessite des barèmes
Exemples de barèmes:
Compte-rendu d'interview et vérifications : 0,5 personne-jour
par interview
Interview: 0,5 personne-jour+déplacement
Rédaction de rapport : 10 à 20 pages par personne - jour
Codage et test unitaire d'un IHM simple : 0,5 personne-jour
50
51. Quelques principes
Pas de modèle universel.
Mais nécessité d'une démarche formalisée.
Analyser en priorité :
Les particularités du projet
L’identification des tâches
Les contraintes
Faire plusieurs estimations si nécessaire.
Savoir justifier.
Une bonne estimation repose sur la capitalisation.
51
53. Outils de gestion de projets
Existence de nombreux logiciels de gestion de projet.
Permettent de :
Planifier le projet,
Créer des tâches,
Affecter des ressources aux tâches,
Indiquer le coût des ressources,
Calculer le chemin critique,
Faire des simulations (pour constater les impacts d'un retard
par exemple).
53
54. Outils de gestion de projets
Composants essentiels :
Réseau PERT :
se présente sous forme graphique et ressemble à un
organigramme informatique horizontal montrant les liens
entre les tâches
renseigne surtout sur le "chemin critique"
Diagramme de GANTT :
orienté sur la gestion du temps
indique les dates de début et de fin des tâches
permet de planifier les tâches et réduire la date de fin du
projet
54
55. Outils de gestion de projets
Il existe de nombreux progiciels (plus de 80 dans le
catalogue du CXP)
Quelques exemples de produits:
MS Project, PMW, PSN 8, On Target, Artemis, Primavera,
Plantrac TM, Harvard, Time Line, WINGS, Pertmaster,
Etc...
55
56. Quelques produits
MS PROJECT pour Windows (Microsoft)
Mise au point de planning,
Présentations graphiques de PERT, GANTT et calendrier,
Suivi des délais, gestion des coûts simple,
Outil simple à manipuler, public non spécialiste de la gestion
de projet.
On Target (Symantec Corporation)
Gère jusque 1500 tâches par projet,
Gère un nombre illimité de ressources par tâche,
Possibilité d'établir des liens graphiques temps/ressources
avec la souris,
Utilisation facile
56
57. Quelques produits
PSN 8 (Scitor Corporation)
Outil généraliste de planification de tâches et de gestion de
ressources (individuelles ou en groupes) au sein d'un
département
Permet de réaliser des simulations en temps réel, des
analyses et des synthèses
Sait gérer plusieurs projets
Gère 2000 activités par projet et 500 ressources par table,
Produit des états de taille réglable
PMW (ABT Corporation)
Outil orienté gestion des ressources
S'adresse à un public connaissant bien la gestion de projet
57
59. Constats généraux
De nombreux projets «avortent».
Retard dans la livraison.
Dépassement de budget.
Problèmes d’exploitation et de maintenance.
Résistance aux changements.
Manque de compétences des gestionnaires.
59
60. Lois, règles et légendes
L'effort nécessaire à fournir pour atteindre les
objectifs prévus croît géométriquement avec le temps
Les projets progressent rapidement jusqu’à ce qu’ils
soient terminés à 90% puis, restent à 90%
Lorsque les choses vont bien, quelque chose ne va
pas
Lorsque les choses ne peuvent pas être pires, elles le
deviendront encore davantage
60
61. Lois, règles et légendes
Si on tolère le changement, le rythme de changement
dépassera le rythme de développement
En moyenne, les grands projets finissent un an en
retard, coûtent deux fois plus que l’évaluation initiale
Un projet mal planifié prendra trois fois plus de temps
à réaliser que prévu alors qu'un projet bien planifié ne
prendra que deux fois plus de temps
Aucun grand projet informatique n'est achevé dans
les délais, dans les limites budgétaires prévues à
l'origine et avec les mêmes responsables qu'à son
initialisation
61
62. Constats généraux: quelques statistiques
Dans la mesure où les dérives sur les projets de
grande taille sont très fréquentes, il convient de ne
pas sous-estimer les coûts, qui peuvent se révéler à
terme beaucoup plus élevés
A titre d'information, quelques statistiques sur la
tenue des délais dans des moyens (30 à 100
mois/hommes) et grands projets (100 à 1000
mois/hommes) (source Carper-Jones) :
Projets annulés : 13%
Projets en retard de plus de 12 mois : 12%
Projets en retard de plus de 6 mois : 35%
Projets approximativement à l'heure : 37%
Projets terminés plus tôt que prévu : 3%
62
64. Déroulement d’une mission d’audit
5 phases :
Lancement du projet et compréhension du contexte
Recueil de l’existant
Analyse de l'existant
Recommandations
Présentation finale
64
65. Déroulement d’une mission d’audit
Phase de lancement :
Précision du champ de la mission et définition des objectifs
associés :
éléments à l ’origine de la mission justifiant son opportunité,
ses objectifs et les enjeux correspondants
définition du champ de l ’étude et éventuellement des
ambiguïtés subsistant sur le champ de la mission
identification des différents services concernés
évolutions prévisibles à prendre en compte
65
66. Déroulement d’une mission d’audit
Phase de lancement :
Organisation de la mission et planning :
identification nominative des intervenants et disponibilité
requise
planning prévisionnel
première convocation pour les entretiens
66
67. Déroulement d’une mission d’audit
Recueil de l’existant :
Description des structures existantes,
Description des ressources logicielles et matérielles,
Mise en évidence :
objectifs,
problèmes
besoins
facteurs clés de succès.
67
68. Déroulement d’une mission d’audit
Analyse de l’existant :
Analyse critique de l’existant sur les aspects
Organisationnels
Fonctionnels
Techniques
Financiers
68
69. Déroulement d’une mission d’audit
Recommandations :
C’est à partir de l’analyse de l’existant que sont proposées
des solutions ou des préconisations visant à optimiser : le
fonctionnement, les dépenses, la réponse aux besoins
utilisateurs
Préconisations en terme de :
sécurité
architecture informatique
outils de développement
conduite de projet
méthodologie
organisation
relation maîtrise d’ouvrage / maîtrise d'œuvre
69
70. Déroulement d’une mission d’audit
Présentation finale :
Présentation aux commanditaires de la mission,
Synthèse avec :
rappel du contexte
indication des modalités de déroulement
exposé rapide de l’existant
mise en évidence des points forts
mise en évidence des points faibles
dysfonctionnements
recommandations classées par priorité
organisation, conduite du projet, ressources…
70
71. Quelques points de repères
Difficultés les plus courantes constatées dans la
relation MOA/MOE:
Manque de confiance mutuelle
Manque de transparence dans la stratégie et l’action
Manque d’objectivité dans l’appréciation des problèmes
Difficultés à prendre des décisions claires
Lourdeur des structures de pilotage
Résistance naturelle aux changements
La MOE tend souvent à se substituer à la MOA sur des
sujets qui relèvent de la responsabilité de la MOA et
réciproquement
Validations difficiles
71
72. Quelques points de repères
Difficultés ressenties par la MOA :
Difficultés à fixer des orientations politiques tranchées
Manque de visibilité sur les travaux en cours
Mauvaise compréhension et appréciation des évaluations de
charges et délais élevés fournies par la MOE
72
73. Quelques points de repères
Difficultés perçues par la MOE :
Manque de disponibilité de la MOA
Besoins insuffisamment précis et stables
Manque d’engagement de la MOA
Difficulté à évaluer les charges et les délais et à les expliquer
à la MOA
73
75. Audit de projet
L'audit de projet est présenté en trois volets :
Une sensibilisation aux risques spécifiques de chaque type
de grand projet de système d'information
Réf.: Guide d'Audit, "Audit des grands projets de systèmes
d'information : Évaluation des risques", IFACI)
Une analyse générique des risques liés à la conduite de
projet
Une analyse des risques spécifiques à chaque phase du
cycle de vie du projet
75
77. Typologie de projets
Projet à niveau élevé d'engagements budgétaires
Projet stratégique au niveau de l'entreprise
Projet transverse
Projet aux enjeux organisationnels forts (de type
"change management")
Projet à base de technologies novatrices (exemples:
technologie objet, Internet, EDI,…)
Système de gestion spécifique complexe ou peu
répandu
Entreprise Ressource Planning (ERP) - Progiciel de
Gestion Intégré (PGI)
77
78. Typologie de projets
Outsourcing de l'informatique ou des systèmes
d'information (total ou partiel)
Fusion et regroupement d'entreprises ou d'activités
(entre plusieurs sociétés), acquisition, filialisation
Projet international d'unification de systèmes
informatiques ou de systèmes d'information
nationaux (exemple: un groupe avec ses filiales)
Fusion/regroupement de systèmes d'information ou
de centres informatiques
Projet à délai imposé
78
79. Audit de projet
Projet à niveau élevé d'engagements budgétaires
Motivations et raisons du choix de ce type de projet
Remplacement d'une application lourde nécessitant des
équipes de conception-développement volumineuses
Déploiement d'équipements à grande échelle
79
80. Audit de projet
Projet à niveau élevé d'engagements budgétaires
Risques généraux
Dépassement budgétaire
Présentation de coûts sous -estimés ou incomplets
Recherche d'économies au détriment de la qualité
Phases aval du projet réalisées rapidement, pour rattraper
les dérives constatées sur les phases amont
Méthodes de travail ne permettant pas de garder la maîtrise
du déroulement du projet
Arrêt du projet et dispersion de toutes les équipes après le
déploiement
Contractualisation avec les prestataires externes présentant
des points faibles ou des lacunes
80
81. Audit de projet
Projet stratégique au niveau de l'entreprise
Motivations et raisons du choix de ce type de projet
Lancement d'un nouveau produit, d'une nouvelle prestation
ou d'un nouveau métier
Mise en conformité avec une nouvelle réglementation
Risques généraux
Manque d'implication des commanditaires / Commanditaires
trop directifs
Déclinaison incorrecte des éléments du plan stratégique
Essoufflement du projet avant son total déploiement
Dépassement de délai
La bonne fin d'un tel projet repose en grande partie
sur l'Étude d'opportunité
81
82. Audit de projet
Projet transverse
Motivations et raisons du choix de ce type de projet
Passage d'une gestion verticale à une approche par
processus
Risques généraux
Absence de vision transverse
Pilotage fort d'une fonction, au détriment des fonctions
connexes
Non prise en compte de la culture d'entreprise
82
83. Audit de projet
Projet aux enjeux organisationnels forts (de type
"change management")
Motivations et raisons du choix de ce type de projet
Bouleversement des conditions d'exercice du métier
Repositionnement de l'entreprise sur son marché
Risques généraux
Manque d'implication de la Direction Générale jusqu'à la
bonne fin du projet de changement
Mauvaise intégration du volet social
Manque d'homogénéité entre le projet SI et les choix
organisationnels
Dépassement de délai
83
84. Audit de projet
Projet à base de technologies novatrices (Technologie
objet, Internet, EDI,…)
Motivations et raisons du choix de ce type de projet
Recherche d'un avantage concurrentiel
Vitrine technologique
Remplacement d'une technologie obsolète et mise en place
d'un socle technique évolutif et pérenne
Risques généraux
Attrait de l'innovation pour elle-même
Dépendance vis -à-vis des fournisseurs
Mauvaise intégration dans le système d'information et
manque de coordination avec les projets des partenaires
Oubli des coûts
84
85. Audit de projet
Système de gestion spécifique complexe ou peu
répandu
Motivations du choix de la DG
Compte tenu du caractère spécifique, la seule solution
possible est faire des développements
Risques associés
Spécifications fonctionnelles pointues et particulières
Perturbation des systèmes amont et aval et propagation des
dysfonctionnements
La solution d'informatisation n'est pas nécessairement la
solution du problème
Dépassement de coûts : manque d'expérience par rapport à
des domaines plus standard
85
86. Audit de projet
Enterprise Ressource Planning (ERP) - Progiciel de
Gestion Intégré (PGI)
Motivations du choix de la DG
Les concurrents ont pris un ERP (effet de mode)
Aller vite et avoir une couverture plus large des besoins
fonctionnels
Disposer d'une technologie plus avancée
Suppression des interfaces applicatives
Solution plus souple et moins chère qu'un développement
maison
Diffusion d'un modèle d'organisation unique pour
l'ensemble des filiales
Meilleure intégration et structuration des informations (une
base de données unique pour l'entreprise)
Mise à disposition plus rapide et plus complète des
informations stratégiques (besoins de niveau DG)
86
87. Audit de projet
Enterprise Ressource Planning (ERP) - Progiciel de
Gestion Intégré (PGI)
Risques généraux
Résistance au changement
Forte intégration du système
Complexité du paramétrage
Diversité de l'environnement technique
Risques liés à la migration et les interfaces
Des enjeux importants liés aux coûts et aux délais
Inadéquation fonctionnelle ou couverture fonctionnelle
incomplète, ce qui va obliger à plus de développements
spécifiques
Surdimensionnement fonctionnel, sous -utilisation des
fonctions du produit
87
88. Audit de projet
Enterprise Ressource Planning (ERP) - Progiciel de
Gestion Intégré (PGI)
Risques généraux (suite)
Sous -estimation des coûts et des délais de mise en œuvre
Sous -estimation des impacts organisationnels
Perte de maîtrise de l'évolution de l'organisation et des
processus métier
Diminution de l'avantage concurrentiel (alignement).
Sécurité logique insuffisante
88
89. Audit de projet
Outsourcing de l'informatique ou des systèmes
d'information (total ou partiel)
Motivations et raisons du choix de ce type de projet:
Se recentrer sur son métier de base, l'informatique étant une
activité de support
Réduire la taille et le coût des services centraux
Améliorer la qualité du service rendu aux utilisateurs
Faciliter les changements de structure de l'entreprise
89
90. Audit de projet
Outsourcing de l'informatique ou des systèmes
d'information (total ou partiel)
Risques généraux
Perte de confidentialité
Dégradation de la qualité de service
Inflation des coûts
Mauvaise gestion des changements
Démotivation du personnel
90
91. Audit de projet
Fusion et regroupement d'entreprises ou d'activités
(entre plusieurs sociétés), acquisition, filialisation
Motivations et raisons du choix de ce type de projet
Une réduction des frais fixes
Un développement du business
Une synergie commerciale et une amélioration des parts de
marché
Risques généraux
Absence de questionnement sur le fait de garder ou non des
S.I. différents (Convergence en matière de S.I. et
architecture technique)
Réduction des avantages escomptés de l'opération
Perturbation de fonctionnement
Dérapage des coûts, des délais et de la qualité
91
92. Audit de projet
Projet international d'unification de systèmes
informatiques ou de systèmes d'information
nationaux (exemple: un groupe avec ses filiales)
Motivations et raisons du choix de ce type de projet
Centralisation du pilotage
Économies de coûts
Rationalisation et unification des pratiques de gestion
Conséquences attendues : installation du même « core
system » partout
Gains escomptés : mise en cohérence des informations de
gestion et rapidité de consolidation, vision exacte des
filiales
92
93. Audit de projet
Projet international d'unification de systèmes
informatiques ou de systèmes d'information
nationaux (exemple: un groupe avec ses filiales)
Risques généraux
Erreur d'appréciation au départ : base réputée identique
partout
Réalité différente : analyse trop schématique, sous
-estimation des particularismes locaux
Découverte des problèmes après -coup, ce qui oblige à des
compléments d'étude et entraîne des dépassements de
coûts
Non atteinte des performances attendues
93
94. Audit de projet
Fusion/regroupement de systèmes d'information ou
de centres informatiques
Motivations et raisons du choix de ce type de projet
Rationalisation du fonctionnement, économies de coûts.
Risques généraux
Dérapage des délais, d'où dérapage des coûts.
Impacts sur les clients, sur le personnel (pertes de
compétence : les meilleurs partent, démotivation du
personnel : perte.
Non atteinte de la cible.
Arrêt du projet.
94
95. Audit de projet
Fusion/regroupement de systèmes d'information ou
de centres informatiques (suite)
1er cas : Risques déclinés en fonction du cas de
regroupement
Le regroupement de centres informatiques peut se faire
dans deux configurations possibles côté constructeur :
– même constructeur: il faut vérifier les économies et le
fonctionnement
– constructeurs différents: la décision étant politique, un audit
n'est pas nécessaire
Les risques portent principalement sur:
– la migration des données
– l'architecture du réseau
– l'organisation de l'exploitation et du support
– le projet RH
95
96. Audit de projet
Fusion/regroupement de systèmes d'information ou
de centres informatiques (suite)
2ème cas : Risques en cas de fusion et de regroupement de
SI:
L'existence d'une étude de benchmarking et de son
application
La décision du choix du SI ou des applicatifs à retenir, la
migration des données, le projet RH, la formation des
utilisateurs, l'organisation des processus
L'existence d'un document de choix et d'un relevé de
décisions, d'un plan de migration
La satisfaction des besoins de la maîtrise d'ouvrage, la
manière dont est organisé leur suivi
96
97. Audit de projet
Projet à délai imposé
Motivations de ce type de projet
En général, projets résultant de contraintes réglementaires,
fiscales, etc
Maintien du bon fonctionnement de l'entreprise tout en
intégrant les contraintes
Risques généraux : ils portent sur l'identification incomplète
des domaines à couvrir, des problèmes à traiter; ou bien sur
la non tenue du planning (préparation et réalisation). Il en
découle :
Réparation à chaud sans ordre, ce qui engendre des risques
aggravés et des coûts plus importants, une perte de clients,
et des pertes d'exploitation
Absence de plan de secours avec arrêt potentiel de l'activité,
Tests incomplets du plan de secours
97
98. Audit de projet
Projet à délai imposé (suite)
Risques relatifs à l'organisation du projet
Affectation de ressources trop importantes sur le reporting
par rapport aux forces vives nécessaires en traitement des
problèmes,
Le reporting est en décalage avec la réalité du terrain (il
nécessite d'être validé et affiné par des audits qualité),
Le schéma global de résolution de problèmes n'est pas
réaliste,
La démarche n'est pas à l'état de l'art (cf. ISACA,…), n'est
pas structurée ni exhaustive, n'est pas formalisée ni
communiquée,
Toutes les compétences ne sont pas réunies ; l'appel à
l'expertise externe nécessaire n'a pas été effectué,
Les solutions ne sont pas mutualisées (cf. Forum des
compétences du secteur financier).
98
100. Les cinq questions clés
Existe-t-il un consensus sur les objectifs du projet ?
Processus de décision/validation et suivi
d'application de ces décisions ?
Qui fait quoi dans le projet ?
Tous les acteurs disposent-ils des informations
nécessaires pour agir dans le sens du projet ?
Quel est le niveau d'avancement du projet ?
100
101. Audit de projet
Les risques liés à la conduite de projet sont abordés
selon les thèmes suivants
1) Objectifs du projet
2) Structure de projet
3) Instances de pilotage et de suivi
4) Méthode et outils
5) Planification
6) Contrôle du projet
7) Qualité
101
102. 1) Objectifs du projet
Concernant l'intégration du projet dans l'entreprise,
s'assurer des points suivants :
Existence d'une définition claire du projet, de son périmètre,
Existence d'un projet en accord avec la stratégie de
l'entreprise et sa culture,
Existence d'un plan de communication
102
103. Objectifs du projet
Les objectifs et les besoins
Les objectifs du projet sont-ils définis et connus des MOA et
MOE ?
Les besoins sont-ils clairement définis ?
Le périmètre est-il défini et stabilisé ?
Les interactions et leurs impacts avec d'autres projets ontils été identifiés ?
Les risques
A t-on identifié et formalisé les risques potentiels ?
103
104. 2) Structure de projet
Vérifier l'existence d'une structure de projet : assurer
l'organisation du projet
Vérifier l'existence d'un chef de projet (MOE et MOA)
S'assurer de la constitution d'une équipe de projet
Remarque : la structure d'un projet n'est pas
nécessairement figée. Selon la nature et l'importance
du projet, elle peut évoluer dans le temps
104
105. Structure de projet
Vérifier la participation de tous les acteurs au projet :
Propriétaire du projet clairement identifié
Maîtrise d'ouvrage :
Liste des intervenants
Rôle et responsabilités
Maîtrise d'œuvre :
Liste des intervenants
Rôle et responsabilités
S'assurer que les rôles et les responsabilités de la maîtrise
d'ouvrage et de la maîtrise d'œuvre sont formellement
identifiés
105
106. Structure de projet
Les moyens :
Moyens humains :
Organiser en fonction des besoins
Équilibre entre l'expérience et le potentiel
Moyens techniques :
Environnement de développement efficace
Outils de développement
Aménagement de l'environnement physique
106
107. Structure de projet
Direction de projet
Évaluer les compétences de la direction de projet,
Vérifier la motivation des équipes,
Sonder la maîtrise d'ouvrage :
besoins,
craintes,
communication,
Le but est d ’obtenir le meilleur rendement possible des
équipes en place.
Les principaux atouts appartiennent au domaine des
relations humaines motivation esprit d ’équipe leadership,
délégation... :
Évaluer la résistance au changement.
107
108. Structure de projet
Existence d'un groupe projet :
Membres permanents
Rôles et responsabilités
Réunions périodiques
Vérifier l'échange d'informations entre la direction de
projet et le groupe projet
108
109. Structure de projet
Les acteurs :
Identification claire des fournisseurs :
Rôle et responsabilités
Résultats attendus
Délai
Acteurs externes :
Obligations légales (ex: fiscal, CNIL…)
Résultats à fournir
Délai
109
110. 3) Instances de pilotage et de suivi
Le mode de pilotage, les processus de
décision/validation
La structure de pilotage est-elle définie ?
La structure de pilotage est -elle adaptée ?
La structure de pilotage est -elle formalisée et connue de
tous les acteurs ?
Les différentes instances de pilotage connaissent -elles
leurs "niveaux de délégation" ?
Les objectifs de délégations sont -ils atteints ?
Vérifier l'existence d'un comité de pilotage
Vérifier l'existence d'un comité de projet
Vérifier l'existence d'un comité des utilisateurs.
Étudier la pertinence des participants présents au comité de
projet et au comité de pilotage.
110
111. Instance de pilotage et de suivi
Les attributions respectives des instances de projet
sont les suivantes :
Comité de pilotage :
Instance de décision et de pilotage stratégique du projet
(lancement, développement de la solution, conduite du
changement et mise en œuvre, management du projet)
Comité de projet :
Instance de pilotage opérationnel du projet agissant pour le
compte du comité de pilotage, comprenant des
représentants de la maîtrise d'œuvre
Comité des utilisateurs :
Instance chargée de l'expression détaillée des besoins et
des règles de gestion; de la validation des dossiers de
conception présentés par l'équipe projet; de la participation
aux tests du système, à l'élaboration de la documentation
utilisateurs, aux actions de formation ; de la réception
définitive du logiciel
111
112. Instance de pilotage et de suivi
Le mode de pilotage, les processus de
décision/validation
Les comités de pilotage et de projet sont-ils adaptés et
efficaces ?
Les participants aux différents comités sont-ils
représentatifs , ont-ils le bon niveau de décision ?
Les utilisateurs sont-ils représentés dans les comités de
pilotage ?
Les gestionnaires et la production ont-ils été intégrés dans
les structures de pilotage ?
Les participants ne sont-ils pas trop nombreux ?
La fréquence des comités est-elle correcte ?
Qui prépare, anime, fait le compte-rendu des comités de
pilotage ? Et dans quel délai ?
Existe-t-il une revue de projet ? (réunion MOA-MOE
périodique pour suivre l'avancement du projet)
112
113. Instance de pilotage et de suivi
Le reporting
Les indicateurs de suivi sont-ils définis ?
Les indicateurs de suivi sont-ils adaptés en fonction de
l'étape ?
Les indicateurs de suivi sont-ils mis à jour ?
Les indicateurs de suivi sont-ils pertinents par rapport aux
objectifs du projet (contraintes de délais, de qualité, de coût,
…)
Existe-t-il un formalisme de reporting ?
Le reporting se fait-il sous forme de tableau de bord ?
Le reporting est-il conjoint et unique MOA-MOE ?
Quelle est la fréquence du reporting ? est-t-elle adaptée au
suivi?
113
114. Instance de pilotage et de suivi
La gestion des changements (évolutions de
périmètre)
Les demandes d'évolutions de périmètre sont-elles
formalisées?
Les évolutions de périmètre sont-elles fréquentes ? Si oui,
combien y en a-t-il eu ?
La gestion des évolutions de périmètre est-elle bien
maîtrisée ?
Existe-t-il une procédure de gestion des évolutions de
périmètre ?
Les décisions sont-elles prises ?
Les mesures d'impact sont-elles faites ?
Y a t-il une gestion des versions ?
114
115. Instance de pilotage et de suivi
Les décisions
Les décisions sont-elles prises ? Avec un délai satisfaisant?
Sur la base d'un niveau d'information pertinent ?
Les points de décision sont-ils respectés (exemple: réunion
et note de lancement, décision d'opportunité) ?
115
116. 4) Méthodes et outils
S’assurer de l'existence d'une méthode :
Vérifier qu'elle est bien appliquée
Identifier les points pouvant être bloquants tels que :
Outils associés à la méthode
Formation à la méthode et aux outils
Cas de dérogation d'utilisation
Vérifier la mise en œuvre d'outils
116
117. 5) Planification
Vérification d'un point de vue général :
Existe-t-il un planning directeur commun à tout le projet ?
La planification s'effectue du général au particulier et l'on
procède par itération :
Existence d'un plan de projet initial
Ce plan de projet a-t-il été révisé et pourquoi ?
Existence de plans détaillés initiaux
Révision des plans détaillés ?
Gestion des ressources
117
118. Planification
Définition des produits à développer :
Notions de projet, sous-projet, lots
Identifications des phases et étapes :
Contraintes
Dates limites
118
119. Planification
Estimation des charges :
Utilisation d'une méthode d'estimation :
Vérifier son application
Vérifier la cohérence d'ensemble
Mise en adéquation des moyens :
Humains
Techniques
119
120. Planification
Avancement du projet (points en suspens)
Le planning général du projet est-il représentatif de la
réalité?
Les acteurs se sont-ils engagés à respecter le planning
général du projet ?
Les lots sont-ils bien identifiés et suivis dans le planning ?
Le chemin critique est-il identifié ?
La mesure de l'avancement du projet est-elle réalisée ?
La notion de reste à faire est-elle comprise par tous les
acteurs ?
La réestimation périodique et en commun des reste-à-faire
est-elle faite ?
Existe-t-il des "capteurs" d'alertes ?
Existe-t-il des procédures pour traiter les alertes
« urgentes » ?
120
121. Planification
Évaluer la prise en compte des risques :
Par rapport :
à la technologie utilisée
aux projets en cours
aux délais
à la synchronisation des activités
121
122. 6) Contrôle du projet
Le contrôle du projet est directement lié à la
planification
Il permet de vérifier :
Avancement des travaux
Contrôle des livrables
Contrôle de la qualité
122
123. Contrôle du projet
Vérifications nécessaires :
A-t-on mis l'accent sur les écarts et la recherche de
solutions ?
A-t-on pris en compte des demandes de changement après
évaluation?
Les demandes d'évolutions de périmètre sont-elles
formalisées ?
Les évolutions de périmètre sont-elles fréquentes ? Si oui,
combien y en a-t-il eu ?
La gestion des évolutions de périmètre est-elle maîtrisée ?
Existe-t-il une procédure de gestion des évolutions de
périmètre ?
Les décisions sont-elles prises ? Les mesures d'impacts
sont-elles faites ?
Y-a-il une gestion des versions ?
A-t-on pris en compte les points en suspens ?
123
124. Contrôle du projet
Point essentiel: le suivi périodique de l’état
d’avancement du projet
Le reporting
Les indicateurs de suivi sont-ils définis ?
Les indicateurs de suivi sont-ils mis à jour ?
Les indicateurs de suivi sont-ils pertinents par rapport aux
objectifs du projet (contrainte de délais, contrainte de
qualité, contrainte de coût,…) ?
Existe-t-il un formalisme de reporting ?
Le reporting se fait-il sous forme de tableau de bord ?
Le reporting est-il conjoint et unique MOE-MOA ?
124
125. Contrôle du projet
Point essentiel : Le suivi périodique de l'état
d'avancement du projet
Efficacité du processus de décision/validation effectué par
les instances de pilotage
125
126. Contrôle du projet
Vérifications nécessaires :
Application du MAQ et PAQ s'ils existent (cf. partie Qualité)
Existence des revues (techniques, livrables)
Circuit d'approbation des livrables
Graduation des livraisons
Documentation produite
126
127. 7) Qualité
Quelques définitions (AFNOR)
L ’assurance qualité est la mise en œuvre d ’un ensemble
approprié de dispositions préétablies et systématiques
destinées à donner confiance en l ’obtention de la qualité
requise.
La qualité est ce que le client souhaite explicitement ou
implicitement
La qualité du logiciel est son aptitude à satisfaire les
besoins des utilisateurs
127
128. Qualité
Les objectifs qualité ont-ils été formalisés ?
Existe-t-il des moyens pour s'assurer de la qualité ?
Existence d'un manuel d'assurance qualité de l'entreprise
Existence d'un plan d'assurance qualité du projet
128
129. Le manuel d’Assurance Qualité
Dispositions générales prises par l ’Entreprise pour
obtenir la qualité de ses produits et services.
Contient :
Les règles de gestion de la qualité
Les règles et procédures de gestion de l’Entreprise
Les plans types de documentation
L’organisation associée
129
130. Le plan d’Assurance Qualité
Établi à partir du MAQ
Décrit les procédures, les règles, les méthodes
applicables au projet
Fixe aux différents acteurs du projet leurs droits mais
aussi leurs devoirs en matière de qualité
L’élaboration du PAQ est du ressort du Responsable
Assurance Qualité du projet
130
131. Exemple de PAQ
Introduction :
Glossaire et abréviations.
Organisation :
Contexte, périmètre, procédures associées au PAQ.
Rôle des intervenants et des structures de pilotage.
Plan de développement :
Démarche, activités, livrables…
131
132. Exemple de PAQ
Documentation :
Procédures diverses :
Identification, contenu, validation
Gestion des fournisseurs, gestion des configurations,
gestion des modifications
Gestion des points en suspens, gestion des risques, gestion
de la recette
Reproduction, protection, livraison
Suivi de l’application du Plan d’Assurance Qualité
132
133. Qualité
A t-on formalisé les objectifs de qualité du produit
(Plan Qualité Projet)?
Les utilisateurs ont -ils été impliqués dans la définition du
niveau de qualité du produit ?
A-t-on formalisé les objectifs de qualité de service
attendue ?
Les utilisateurs ont -ils été impliqués dans la définition du
niveau de qualité attendue ?
133
135. Les grandes phases de conduite de projet
Étude d'opportunité/Lancement
Conception générale/Analyse
Conception détaillée
Développement/Réalisation ou Paramétrage
(progiciel)
Qualification : Tests/Recettes
Mise en œuvre/Conduite du changement
135
136. Étude d’opportunité/Lancement
Vérifier l'existence d'une expression détaillée et
formalisée des besoins dans un cahier des charges
fait par la MOA Document contractuel : justification
du projet
S'assurer que l'étude d'opportunité comprend :
Les objectifs du projet
L'analyse des déficiences des systèmes existants
Les enjeux du projet
Les bénéfices attendus
Les contraintes relatives au projet
Les acteurs concernés
136
137. Étude d’opportunité/Lancement
S'assurer de l'intégration du projet au schéma
directeur ou plan directeur
Cohérence du projet dans le plan directeur informatique,
Cohérence du projet dans le système d'information actuel ou
futur,
S'assurer de la participation de la direction du département
utilisateur concerné dans la phase d'initialisation.
S'assurer de la participation au projet des acteurs
concernés : pertinence de l'équipe de projet
Identifier les acteurs de l'équipe de projet et leurs
responsabilités,
Évaluer l'adéquation entre les qualifications des personnes
impliquées et leurs tâches,
Vérifier la participation des principaux utilisateurs à l'équipe
de projet.
137
138. Étude d’opportunité/Lancement
Vérifier la formalisation de l'approbation du projet :
Validation de l'étude d'opportunité.
S'assurer que l'étude d'opportunité a été revue par les
directions des départements utilisateurs concernés et par la
direction informatique
Vérifier que l'approbation a été formalisée par écrit
Vérifier la qualité de la personne qui a autorisé la poursuite
du projet
138
139. Conception générale/Analyse
S'assurer de l'existence d'une analyse comparative
des scénarios possibles : contrôle de la pertinence de
la solution de développement retenue.
Vérifier l'exhaustivité des scénarios proposés, y compris
celui de ne rien faire.
Vérifier la qualité de l'analyse technologique de chaque
alternative.
Besoins/disponibilités de matériels et de logiciels
Besoins en formation
Besoins/disponibilités de ressources humaines
Faisabilité opérationnelle
Implication du responsable technique
Contraintes juridiques/réglementaires
139
140. Conception générale/Analyse
S'assurer de l'existence d'une analyse comparative
des scénarios possibles : contrôle de la pertinence de
la solution de développement retenue
Vérifier la qualité de l'analyse économique de chaque
alternative
Coûts de développement
Coûts de formation
Coûts de maintenance/exploitation
Coûts de conversion/migration/paramétrage
Coûts annexes
Bénéfices attendus
Coûts de fonctionnement
Implication du responsable utilisateur
140
141. Conception générale/Analyse
S'assurer de l'existence d'une analyse comparative
des scénarios possibles : contrôle de la pertinence de
la solution de développement retenue
Vérifier l'existence d'une analyse des risques pour chaque
alternative
Valeur et sensibilité des informations traitées
Vulnérabilités
Besoins correspondant en matière de contrôles internes
Implication du responsable sécurité
S'assurer de l'existence de critères d'évaluation pour
réaliser l'analyse comparative en toute objectivité
141
142. Conception générale/Analyse
Vérifier la prise en compte des aspects de contrôle
interne et de sécurité dans l'élaboration du cahier des
charges afin d'assurer la sécurité du futur
développement
S'assurer que la conception générale du futur système
s'inscrit dans les objectifs généraux de contrôle en vigueur
dans l'environnement.
S'assurer que les contrôles d'exploitation ont été identifiés.
S'assurer de la prise en considération des besoins
spécifiques en matière de contrôles.
S'assurer de l'identification et de la description des besoins
en matière de contrôles programmés.
142
143. Conception générale/Analyse
Vérifier la formalisation de la poursuite du projet :
validation de la conception générale et choix de la
solution de développement
S'assurer que les études de faisabilité proposées ont été
revues par les membres du Comité du Projet
S'assurer de la présentation des différentes solutions
possibles au Comité de Pilotage
Vérifier la qualité de la personne qui a autorisé la poursuite
du projet
Vérifier l'existence d'une approbation écrite
143
144. Conception détaillée
S'assurer de l'utilisation d'une méthode d'analyse et
de conception: qualité de la phase de conception.
Vérifier l'existence d'une méthode d'analyse/de conception
S'assurer que cette méthode est correctement utilisée
Evaluer la maîtrise de cette méthode
Vérifier la conformité des spécifications détaillées au
cahier des charges : correcte interprétation des
besoins exprimés.
Vérifier l'exhaustivité des spécifications détaillées par
rapport à la conception générale
Evaluer la définition et la documentation des spécifications .
144
145. Conception détaillée
Vérifier la qualité des contrôles programmés
Vérifier l'existence de contrôles adaptés à chaque point
critique du système
Contrôles préventifs
Vérifier l'existence et la pertinence des contrôles correctifs
S'assurer de l'implication du responsable de la sécurité
Vérifier l'existence de pistes d'audit permettant de suivre la
totalité des transactions de leur point d'origine jusqu'aux
totalisations de contrôle correspondantes et vice-versa
145
146. Conception détaillée
S'assurer de l'implication suffisante des acteurs
concernés (utilisateurs, administrateurs de données,
responsable sécurité,…)
Vérifier la formalisation de la validation de la
conception détaillée
S'assurer que la conception détaillée préparée a été revue
par les membres du Comité de Projet
S'assurer que le document a été présenté au Comité de
Projet
Vérifier la qualité de la personne qui a autorisé la poursuite
du Projet
Vérifier l'existence d'une approbation écrite
146
147. Recommandations en matière de spécification
Pour assurer que la réalisation du logiciel correspond aux
besoins, au minimum, les documents suivants doivent exister:
Spécifications externes (ou spécifications fonctionnelles)
Ce
document décrit, précisément et clairement, toutes les
caractéristiques du logiciel à réaliser (fonctions, contraintes, règles
de calcul) ainsi que toutes les interfaces externes. Une fois
approuvé par le utilisateurs, il constitue le document de référence.
Toutes les caractéristiques seront décrites de façon à ce qu'il soit
possible d'en vérifier objectivement la réalisation
Spécifications internes (ou spécifications organiques globales)
Ce
document décrit tous les éléments d'architecture du système,
c'est-à-dire, les sous -ensembles à réaliser en précisant leurs
fonctions, et tous les éléments communs (modules de service,
fichiers, tables, bases de données, interfaces,…)
147
148. Développement/Réalisation
S'assurer de l'utilisation d'une méthode de
développement (pérennité et fiabilité des traitements)
Vérifier l'existence d'une méthode de développement
S'assurer que cette méthode est correctement utilisée
Évaluer la maîtrise de cette méthode par les développeurs
Vérifier le respect des normes de documentation et de
vérification
Étudier la pertinence des normes en vigueur
Vérifier l'application de ces normes par les développeurs
Apprécier la qualité de la documentation
S'assurer de la revue par le responsable du services études
de la documentation constituée
148
149. Développement/Réalisation
Vérifier la formalisation d'un programme général de
tests
Vérifier l'existence d'un plan de mise en place.
Vérifier l'existence et la pertinence du plan de mise en place
Vérifier l'approbation et la diffusion du plan de mise en place
S'assurer que le plan de mise en place définit au minimum :
La nature des travaux à réaliser et leur ordonnancement
Les charges de travail correspondantes et la durée des
travaux
Les acteurs concernés
Leurs rôles et responsabilités
149
150. Développement/Réalisation
Vérifier l'existence de procédures de contrôle et de
sécurité lors de la migration : assurer la réussite du
projet de conversion
Vérifier l'existence et la pertinence du plan du plan de
migration
S'assurer du respect des normes de développement et de
vérification du programme de conversion
S'assurer du respect des procédures de contrôles en
matière de passage en production
Vérifier l'existence d'une image des systèmes et des
données avant et après conversion
Vérifier l'implication du responsable assurance qualité dans
le processus de conversion
S'assurer de la formalisation de l'examen et de l'approbation
des résultats du processus de conversion par les directions
concernées
150
151. Développement/Réalisation
Objectif : Personnaliser le progiciel pour répondre
aux besoins exprimés par les utilisateurs
Définir et enregistrer les paramètres de configuration pour
adapter le progiciel au contexte organisationnel et technique
cible
Faire réaliser les adaptations spécifiques nécessaires pour
satisfaire les besoins non couverts
151
152. Paramétrage (Solution Progiciel)
Vérifier l'existence du dossier de spécification du
paramétrage
Le dossier doit consigner les options retenues sur le produit
(approche itérative en partant des options les plus
structurantes)
La démarche constitué par l'éditeur peut constituer le fil
conducteur pour le travail de paramétrage
Vérifier qu'un prototype représentatif a été réalisé
(implication des utilisateurs)
152
153. Qualification: tests/Recettes
Les tests représentent le vecteur principal de
l’amélioration de la qualité de l’application
Cependant, tester reste une des activités les moins
populaires chez les développeurs d’applications. En
effet, contrairement à la conception ou à la production
de code, le test ne génère que des fiches d’anomalies
De plus, étant réalisés en fin de processus de
développement, les tests ont tendance à être limités,
voire « oubliés », du fait des retards déjà accumulés
et de la pression pouvant être exercée sur l’équipe de
projet.
153
154. Tests/Recettes
La phase de tests constitue néanmoins une activité
centrale puisqu’elle assure la qualité absolument
nécessaire qui n’est fournie ni par les logiciels de
conception, ni par les outils de développements
Les conséquences économiques et financières
démontrent la nécessité de tester les applications en
cours de développement ; néanmoins, il est
impossible de tester l'application entièrement
Une partie importante des problèmes d’exploitation
résulte de défaillances de tests
154
155. Tests/Recettes
S'assurer du respect des normes de recette finale :
Procès-verbal (PV) de recette
Vérifier l'existence et la pertinence d'une procédure
formalisée de recette finale destinée à accepter formellement
l’application
Vérifier la participation active des acteurs concernés
S'assurer de la maîtrise suffisante du système par les
personnes impliquées dans la recette
Vérifier la pertinence des jeux d'essais et s'assurer de
l'étendue des tests
S'assurer que les tests de performances sont réalisés dans
les futures conditions d'exploitation du système
S'assurer de la formalisation des résultats des jeux d'essais
et de la recette finale par la direction du département
utilisateur
155
156. Conduite du changement
Enjeu capital dans la réussite ou l’échec d’un projet, le
changement vécu par les organisations lors d’une évolution du
système d’information doit être maîtrisé et géré comme un
processus à part entière.
Ce processus doit aboutir à une réelle appropriation du nouveau
système d’information par tous les utilisateurs dès la phase de
démarrage.
La démarche de la conduite du changement est structurée en 6
phases :
Identification et évaluation des changements,
Plan de communication,
Plan de formation,
Élaboration définitive de la documentation,
Organisation du soutien,
Reprise des données.
156
157. Conduite du changement
Identification et évaluation des changements
Existe-t-il une synthèse de l'évaluation des changements ?
L'évaluation a t-elle été validée ?
S'assurer que les entretiens réalisés sont représentatifs ?
Les utilisateurs participent-ils à l'évaluation des
changements ?
157
158. Conduite du changement
Plan de communication
Existe-t-il un plan de communication ?
Est-il complet ?
Les messages sont-ils clairs et simples ?
Y-a-t-il une progressivité de la communication par rapport au
développement du projet ?
Existe-t-il un soutien fort de la Maîtrise d'Ouvrage ?
158
159. Conduite du changement
Plan de formation
Vérifier l'existence d'un plan de formation des utilisateurs et
des opérateurs.
La hiérarchie des personnes à former est-elle impliquée ?
Vérifier l'identification des profils types des personnes à
former.
Vérifier la pertinence de la population à former.
Les objectifs de chaque formation sont-ils identifiés et
affichés?
Evaluer les cessions et apporter les éventuelles adaptions.
159
160. Conduite du changement
Plan de formation (suite)
Vérifier l'adéquation du planning de formation au planning
du projet.
Vérifier la pertinence de la durée du programme de
formation.
S'assurer de la qualité pédagogique des formateurs et du
contenu de la formation.
Vérifier l'existence d'une procédure d'évaluation des formés
et des formateurs.
160
161. Conduite du changement
Élaboration de la documentation
Vérifier l'existence d'un manuel d'utilisation, d'un aide
mémoire, d'un guide utilisateurs, d'une aide en ligne.
S'assurer de la bonne répartition entre documentation en
ligne et documentation papier.
Les accès à la documentation répondent-ils en priorité aux
besoins des utilisateurs ?
161
162. Conduite du changement
Vérifier l'existence d'un manuel utilisateurs
Vérifier que le manuel utilisateurs est conforme aux normes
en vigueur.
S'assurer de sa disponibilité et de sa compréhension par
l'ensemble des utilisateurs.
Vérifier qu'il comprend au minimum :
les objets du système et la description des dessins d'écran
et des commandes disponibles,
les responsabilités concernant le redressement des erreurs
ou anomalies,.
La description des sorties et leur mode de diffusion,
Les responsabilités en matière de
sauvegarde/archivage/purge.
S'assurer qu'il fait l'objet d'une procédure de mise à jour.
162
163. Conduite du changement
Vérifier l'existence d'un manuel d'exploitation.
Vérifier que le manuel d'exploitation est conforme aux
normes en vigueur.
S'assurer de son accessibilité et de sa compréhension par
les opérateurs.
S'assurer qu'il a été testé lors des tests finaux.
Vérifier qu'il comprend au minimum :
la fonction des programmes,
le libellé exact des fichiers concernés,
la liste des messages opérateurs et les réponses attendues,
les actions à suivre en cas d'anomalies,
la liste des états générés et leurs destinations,
les procédures de reprise,
les responsabilités de l'exploitation en matière de contrôles
globaux.
S'assurer qu'il fait l'objet d'une procédure de mise à jour.
163
164. Conduite du changement
Organisation du soutien
Une organisation d'assistance aux utilisateurs a-t-elle été
mise en place dans la phase d'exploitation du nouveau
système ?
Son organisation générale a-t-elle été bien anticipée ?
S'assurer de la disponibilité réelle d'une formation et d'une
expertise.
Les différents niveaux de soutien sont-ils coordonnés et
cohérents ?
164
165. Conduite du changement
Reprise des données
Existe-t-il un dossier d'organisation de la reprise des
données ?
Le niveau de qualité des données d'origine est-il bien
maîtrisé ?
S'assurer de la mise en place de contrôles automatiques de
la qualité des données obtenues après reprise.
S'assurer de la mobilisation le plus tôt possible des
utilisateurs devant participer à la reprise des données.
165
166. Conduite du changement
Le bilan qualité comporte deux parties :
Le bilan qualité élaboré en référence au PAQ,
Le bilan qualité exprimé par les utilisateurs.
166
167. Bilan Qualité
Bilan de la qualité du logiciel élaboré en référence au PAQ :
Réalisé en prenant comme référence les exigences qualité fixées
par la maîtrise d’ouvrage, traduites par le maître d’œuvre en
objectifs et critères à respecter par le logiciel.
Exigences fixées par les utilisateurs au niveau du système:
Conformité
: conformité aux besoins fonctionnels et techniques
exprimés par le cahier des charges fonctionnel et technique ;
Performance : temps de traitement des échanges courants au
niveau des serveurs doit être inférieur à trois secondes dans au
moins 95% des cas d’utilisations de ces échanges, sur une
journée, pour environ 200 échanges par minute ;
Sécurité : système disponible et intègre. Système disponible pour
les utilisateurs, tous les jours ouvrés, pour l’ensemble des
traitements, avec une indisponibilité maximale acceptée inférieure
à deux heures par semaine
Convivialité : système facile d’exploitation sans aucune installation
de logiciel sur le poste client.
167
168. Bilan Qualité
Bilan qualité exprimé par les utilisateurs
Il est fortement recommandé d’élaborer un bilan en prenant
l’avis direct des utilisateurs.
Cette appréciation peut se recueillir à l’aide d’un
questionnaire qui doit passer en revue tous les aspects du
logiciel.
Critères d’appréciation de la qualité d’un logiciel :
Complétude et qualité des fonctionnalités présentes,
Ergonomie,
Performance,
Qualité de la documentation,
Robustesse et fiabilité,
Formation reçue,
Qualité et efficacité de l’assistance et du soutien.
168
170. Mission n°1: Contexte et objectifs
Avant de lancer la réalisation d'un nouveau système
destiné à remplacer les outils actuels de gestion
administrative, physique et douanière des
marchandises, une société a souhaité évaluer les
risques liés au projet et étudier l'opportunité d'une
solution alternative de type logiciel intégré.
Cette société travaille avec un prestataire
informatique spécialisé dans le domaine.
Phase d'intervention de la mission:
Définition des Besoins du Système (Cahier des charges en
cours de rédaction)
170
171. Mission n°1: Contexte et objectifs
Thèmes examinés :
Existence d'une solution satisfaisante "logiciel/progiciel
intégré" unique
Modernité et pertinence technique du projet
Modernité et pertinence fonctionnelle du projet
Montage projet pour la rédaction du cahier des charges et
pour la réalisation du système
Montage contractuel pour la réalisation du système
171
172. Mission n°1: Personnes rencontrées
Personnes rencontrées
Directeur général adjoint,
DSI client,
Chef de projet EDI client,
Chef de projet client,
Directeur technique prestataire,
Chef de projet prestataire.
172
173. Mission n°1: Principaux constats
Les solutions "logiciel intégré"
La mise en place d'un logiciel/progiciel intégré unique pour
la gestion des moyens de transport et des marchandises ne
semble pas appropriée (faible intérêt fonctionnel).
Risques humains et sociaux importants dans le contexte de
la ville.
Pas d'offre sur le marché des logiciels/progiciels intégrés
spécifiques pour une gestion globale de ce genre d'activité.
Une solution de ce type unique serait donc coûteuse.
173
174. Mission n°1: Principaux constats
Principaux constats (suite)
Modernité et pertinence technique du produit
envisagé
La méthode qui a été adoptée pour définir l'architecture
technique cible dans le cahier des charges est satisfaisante.
Globalement, les exigences essentielles ont été posées dans
le cahier des charges pour un réseau de communication
sécurisé appuyé sur des bases de données relationnelles.
Le cahier des charges présente les besoins techniques et
les contraintes à respecter. A ce titre, il est une base pour les
propositions des prestataires.
174
175. Mission n°1: Principaux constats
Modernité et pertinence fonctionnelle du produit
envisagé
La description des nouvelles fonctionnalités doit être
complétée :
Les fonctionnalités détaillées sont très proches de celles
existantes ;
Les nouvelles fonctionnalités sont peu explicites.
Absence d'une réelle étude des besoins
175
176. Mission n°1: Principaux constats
Montage du projet pour la rédaction du cahier des charges
Des difficultés ont été rencontrées dans le cadre de la rédaction
du cahier des charges.
Manque de clarté dans la définition des rôles et responsabilités
des différents acteurs de la gestion du projet : le chef de projet
utilisateurs (maîtrise d'ouvrage) n'a pas été formellement
identifié.
Absence d'axe directeur donné au projet qui nuit à la
pertinence et à la cohérence des travaux des responsables
de projet informatiques et explique les différences de points
de vue entre parties à la rédaction du cahier des charges.
Manque de disponibilité de ressources dédiées qui explique
la dérive dans les délais initialement prévus.
176
177. Mission n°1: Principaux constats
Montage projet pour la réalisation du système
Risques importants de dysfonctionnement liés à la structure
pressentie pour la réalisation du système.
Origine de ces risques : la confusion des rôles entre maîtrise
d'œuvre et maîtrise d'ouvrage.
Une des causes majeures de l'échec des grands projets (*).
La MOE tend à se substituer à la MOA sur des sujets qui
relèvent de la responsabilité de la MOA ;
La réciproque étant vraie (ex : une MOA raisonnant en
termes de solutions).
(*) Projets mobilisant plus d'une dizaine de personnes en pointe,
plus d'un niveau hiérarchique, avec un accent mis sur la gestion
de projet.
177
178. Mission n°1: Principaux constats
Montage du projet pour la réalisation du système
Les structures pressenties ne permettent pas de garantir
totalement :
L'adéquation des fonctionnalités du système réalisé avec
les besoins exprimés,
La livraison d'un outil techniquement performant,
La réalisation et la mise en œuvre du système dans des
délais raisonnables.
Montage contractuel pour la réalisation du système
La question n'a pas été abordée
178
179. Mission n°1: Recommandations
Recommandations générales
Il semble souhaitable de continuer le projet et pour qu'il se
déroule dans les meilleures conditions possibles, de :
Nommer un chef de projet utilisateurs ;
Créer les conditions d'association d'une SSII expérimentée à
la société informatique spécialisée pour la réalisation du
système ;
Approfondir les possibilités de contractualisation dans le
cadre d'une mise en concurrence pour la réalisation du
système. La mobilisation d'une expertise juridique sur ce
sujet est conseillée.
179
180. Mission n°1: Recommandations
Pertinence technique du produit
La définition de l'architecture technique cible dans le cahier
des charges est satisfaisante
Pertinence fonctionnelle du produit :
L'absence réelle d’étude des besoins est un handicap
important.
Le caractère novateur du système peut être un atout
concurrentiel important de la société face à ses clients. D’où
la nécessité de vérifier rapidement les évolutions prévisibles
dans ce domaine :
Auprès de quelques grandes sociétés de transport ;
Auprès de la société la plus avancée sur le plan mondial
dans le domaine de l'informatisation logistique.
180
181. Mission n°1: Recommandations
Montage du projet pour la rédaction du cahier des
charges
Désigner un chef de projet utilisateur pour fixer les
orientations générales à donner au projet.
Montage du projet pour la réalisation du système
Même si des procédures adéquates d'arbitrage et de gestion
des relations entre les partenaires ont été prévues dans le
projet de convention pour la réalisation du système ;
Il conviendra de clarifier les rôles de chacun et de réfléchir à
l'opportunité de s'associer les compétences d'un prestataire
informatique expérimenté.
181
182. Mission n°1: Recommandations
Montage contractuel
Nécessité de choisir une procédure.
Les instances appropriées devront se prononcer sur le choix
d'une procédure pour le montage contractuel (appel d'offre
ouvert, appel d'offre restreint, marché négocié avec ou sans
compétition). Trois modèles de montages contractuels sont
possibles :
Sous-traitance totale de l'informatique : appel d’offre,
Parrainage par une société chargée de l'exploitation du
système (situation actuelle).
La solution " marché négocié sans mise en concurrence"
entre le maître d'ouvrage et le maître d'œuvre présenterait
des risques financiers et juridiques qu'il conviendra
d'analyser.
182
183.
Chiffrage du projet
Le chiffrage actuel ne tient pas suffisamment compte de
l'existant, des projet précédents et de la connaissance du
métier et des outils des partenaires.
Le chiffrage du projet pourrait être revu à la baisse sur la
base d'une version validée du cahier des charges.
On peut noter que lorsqu'une entreprise lance un appel
d'offres pour choisir un prestataire, elle demande une
évaluation du coût du projet.
Toutefois, dans la mesure où les dérives sur les projets de
cette taille sont très fréquentes, il convient de ne pas sousestimer les coûts, qui peuvent se révéler à terme beaucoup
plus élevés.
183
184. Mission n° 2: Contexte et objectifs
L'objectif de notre intervention consiste, dans le
cadre d'une acquisition potentielle, à dresser une
revue générale de l'informatique pour le compte du
repreneur de la société.
Pour ce faire, notre champ d'étude couvre cinq
domaines :
l’organisation de la fonction informatique,
l’architecture technique,
une revue des applications existantes,
la sécurité du système d'information (sécurité logique et
physique, plan de continuité des opérations, procédures de
développement et de maintenance, etc.),
les contrats de prestations de services.
184
185. Mission n° 2: Contexte et objectifs
Et essentiellement une prise de connaissance du
projet de migration informatique sur le nouveau
progiciel, y compris les chantiers Euro et An 2000. A
ce titre, nous avons étudié :
Les modalités de choix du progiciel,
L’organisation du projet et son degré d'avancement,
Ainsi que la nature et l’évaluation globale des travaux
restant à réaliser.
Phase d'intervention:
Migration du système d’information vers un progiciel
bancaire dans le cadre de la mise en place d’un schéma
directeur.
185
186. Mission n° 2: Personnes rencontrées
Directeur informatique et Directeur adjoint,
Responsable Réseau/Micro,
Directeur de l’Organisation,
Directeur de l'Agence Centrale,
Direction Commerciale, Secrétariat Crédits,
Direction des Opérations, Département Etranger,
Département Comptabilité,
Manager d'un cabinet de conseil et d'audit
(Maîtrise d'ouvrage déléguée du projet de migration
vers le nouveau progiciel).
186
187. Mission n° 2: Principaux constats sur le projet de
migration
De nombreux chantiers ne sont pas encore stabilisés,
le maintien d'un démarrage prévu dans les deux mois
à venir présente des risques importants :
Risques d'insuffisance des tests compte tenu des délais
restants,
États de gestion internes ne répondant que partiellement
aux besoins de la société,
Absence de maîtrise des processus complets d’exploitation,
Risque d'une solution dégradée au démarrage pour
plusieurs applicatifs.
187
188. Mission n° 2: Principaux constats sur le projet de
migration
Les risques potentiels associés au projet de migration
ont un impact fort sur le plan :
De la continuité de l’activité
Absence de solution de secours sur le système cible.
Des coûts de mise en place
Le budget de vingt millions de francs initialement alloué au
projet de migration est largement dépassé. Le non-respect
des délais fixés est susceptible de générer un surcoût
important (assistance supplémentaire de prestataires...).
De la continuité de l’exploitation
Perturbations organisationnelles et fonctionnelles,
Insuffisance de tests compte tenu des délais fixés,
Maîtrise partielle ou insuffisante de l’enchaînement des
processus d’exploitation.
188
189. Mission n° 2: Principaux constats sur le projet de
migration
Les risques potentiels associés au projet de migration ont un
impact fort sur le plan (suite) :
Du respect des exigences réglementaires et interbancaires
De la solution de secours
Faible visibilité à ce jour sur la pertinence des solutions
minimales requises.
De la forte dépendance de l’établissement vis-à-vis de
l’éditeur du logiciel,
De la motivation des équipes dédiées au projet
Leur mobilisation est une condition indispensable au
succès de la migration.
Le maintien d'un démarrage dans les deux mois à venir présente
des risques de perturbations importants et/ou de blocages non
maîtrisés,
189
190. Mission n° 2: Recommandations
Compte tenu des risques évoqués, nous
recommandons de ne pas faire l'acquisition de
l'institution financière avant la migration vers le
progiciel
Un audit approfondi devrait être effectué après cette
migration n Nous recommandons de prendre en
compte les risques relatifs à une éventuelle rupture
des contrats informatiques en cours et le cas échéant
procéder à une analyse approfondie des contrats par
un juriste spécialisé.
190
191. Mission n° 3: Contexte et objectifs
Notre mission consiste à effectuer une revue d’un
dispositif téléindicateur pour le compte d’une grande
entreprise de transport.
La Maîtrise d’œuvre est assurée par une PME
spécialisée dans le développement de ce type de
produit.
Phase d'intervention :
Qualification/homologation du système : tests et recettes.
191
192. Mission n° 3: Personnes rencontrées
Personnes rencontrées
Au niveau du maître d'œuvre :
Président Directeur Général de l'entreprise,
Directeur Commercial,
Chef de Projet.
Au niveau de l'entreprise de transport :
Représentant des utilisateurs,
Commanditaire du système,
Chargé de la maintenance du système sur site.
192
193. Mission n° 3: Principaux constats
Diagnostic général
La réception définitive du système n’est pas prononcée
(portefeuille de bogues important) ;
Le projet a engagé à ce jour des charges significativement
supérieures aux coûts prévus et n’est pas économiquement
en mesure, de prendre toutes les initiatives qui pourraient
être nécessaires ;
La maîtrise technique du système est concentrée sur une
seule personne. Cette situation est fragilisante pour le client.
193
194. Mission n° 3: Principaux constats
Le projet
Pas de méthode de conduite de projet,
Modifications effectuées pendant les développements sans
mise à jour de la documentation,
Peu de suivi de projet (planification et suivi d'avancement),
Manque de procédures,
Documentation inexistante ou inexploitable,
Formation des utilisateurs très insuffisante,
194
195. Mission n° 3: Principaux constats
Plate-forme de tests et qualification insuffisantes,
Procédure de gestion des anomalies trop peu
rigoureuse,
Contribution insuffisante de la maîtrise d'ouvrage
dans les phases de tests,
Aucun plan d'acceptation du système fourni par la maîtrise
d'ouvrage,
Manque de communication entre maîtrise d'œuvre et la
maîtrise d'ouvrage,
Relations conflictuelles entre la MOA et MOE.
195
196. Mission n° 3: Principaux constats
Le logiciel
Points faibles:
Produit incomplet,
Ne peut fournir le service attendu sans incidents,
Niveau de maintenabilité très insuffisant.
Point fort:
Caractère évolutif du produit
196
197. Mission n° 3: Recommandations
Organisation du projet :
Nécessité de mettre en place une nouvelle équipe de projet
et de prévoir une période de transition,
Formaliser une procédure précisant les modalités de
collaboration entre les utilisateurs et la fonction
informatique : confusion MOA/MOE,
Préciser les responsabilités de la MOE et de la MOA.
197
198. Mission n° 3: Recommandations
Contrôle du projet :
Continuer de stabiliser l'existant i.e. les demandes
d'évolution doivent rester gelées
Envisager l'acquisition d'outils performants de
développements pour améliorer la qualité du logiciel,
Nécessité de gérer la configuration et les versions du
logiciel,
Nécessité de mettre en œuvre une gestion rigoureuse des
anomalies,
Suivre une démarche de mise au point et de qualification du
logiciel en mettant en œuvre des procédures de tests,
La mise en place d'un site pilote est indispensable dans la
procédure de qualification.
198
199. Mission n° 3: Recommandations
Documentation :
Nécessité de constituer une documentation du système en
précisant :
Les spécifications externes ou fonctionnelles,
Les spécifications internes ou organiques globales,
L'architecture technique globale et l'architecture modulaire
détaillée (les documents sont manuscrits),
199
200. Mission n° 3: Recommandations
Documentation (suite) :
Le plan de développement : document contenant les
informations de planification liées au développement du
logiciel.
Le découpage du projet en tâches élémentaires et
l’estimation de la charge de réalisation de chaque tâche en
précisant la compétence choisie et le temps requis ;
La planification des tâches et la consommation induite des
ressources
Les événements clés permettant de contrôler l’avancement.
On pourra ainsi mesurer le suivi d’avancement du projet en
comparant ressources consommées/résultats obtenus d’une
part et délais prévisionnels/délais réels d’autre part.
200
201. Mission n° 3: Recommandations
Documentation :
Nécessité de constituer un dossier « Utilisateurs »
comportant :
Le manuel utilisateur
Le guide de maintenance
201
202. Mission n° 3: Recommandations
Communication :
Implication de la direction générale dans la gestion des
projets,
Raisonner en terme de structure et non en terme de
personnes,
Respecter les rôles et responsabilités de chacun,
Compréhension du logiciel par les utilisateurs,
Participation importante des utilisateurs.
202
204. Les causes principales de dysfonctionnement
sont:
Une mauvaise prévision : mauvaise prévision des
tâches à effectuer, mauvaise prévision des
conséquences de la mise en place du nouveau
système
Une mauvaise organisation : partage des rôles entre
les intervenants imprécis, fonctions non identifiées,
taux de participation trop flou
Une mauvaise communication : contexte et objectifs
du projet méconnus, validations implicites,
interlocuteurs concernés non impliqués, compterendu insuffisant du maître d'œuvre au directeur de
projet
204
205. Les causes principales de dysfonctionnement
sont:
Des engagements contractuels mal définis entre la
maîtrise d'ouvrage et la maîtrise d'œuvre.
Les conséquences de ces dysfonctionnements
peuvent être un surcroît de charges, un allongement
des délais, une mauvaise qualité du logiciel ou des
services offerts aux utilisateurs pouvant aller même
jusqu'au rejet de l'application.
205
206. Maîtriser le développement du projet
Au plan de l'organisation :
Une implication forte de la hiérarchie ;
Des représentants maîtrise d'ouvrage et maîtrise d'œuvre
désignés ;
Des structures de travail (groupes utilisateurs, de pilotage)
et de décision (comité directeur, comité exécutif) équilibrées,
effectives et représentatives ;
Des rôles bien définis pour chaque participant
206
207. Maîtriser le développement du projet
Au plan de l'organisation (suite):
Un document de départ à l'intention de la maîtrise d'œuvre
définissant clairement les objectifs du projet, les contraintes
et les résultats attendus, les exigences de qualité et les
travaux préalables ;
Un calendrier et un budget prévoyant à l'avance les tâches à
effectuer et leur durée ;
Un tableau de bord et des procédures de contrôle de
l'avancement ;
Des procédures de validation et de recette ;
Un plan d'actions pour la maîtrise d'ouvrage.
207
208. Maîtriser le développement du projet
Au plan des méthodes et des outils :
Une démarche : succession de tâches à assumer et de
résultats à produire ;
Une méthode d'évaluation des charges ;
Une méthode de planification et de suivi de l'avancement
permettant d'avoir en permanence une bonne visibilité sur
'avancement du projet ;
Un plan d'assurance qualité ;
Des outils : atelier de génie logiciel, outil de conduite de
projet, etc.
208
209. Maîtriser le développement du projet
Toutes ces dispositions préétablies et systématiques
destinées à donner confiance en l'obtention de la
qualité requise doivent être consignées dans un plan
d'assurance qualité (PAQ).
Ce plan doit être spécifique à chaque projet et établi
en fonction des exigences qualité formulées par la
maîtrise d'ouvrage.
Les exigences qualité doivent être traduites en
facteurs qualité ou en critères qualité véritables.
209