Gestion Projet SI

DSCG : UE5 - Management des Systèmes d'Information
gestion de projet : Outils
Table des matières
LES OUTILS DE LA DÉCOMPOSITION CARTÉSIENNE..............................................................2
PBS : PRODUCTS BREAKDOWN STRUCTURE................................................................................................. 2
WBS : WORKS BREAKDOWN STRUCTURE................................................................................................... 2
OBS : ORGANIZATION BREAKDOWN STRUCTURE........................................................................................... 3
RACI.............................................................................................................................................. 5
LES TECHNIQUES D'ORDONNANCEMENT DES TÂCHES........................................................6
DIAGRAMME
DE
GANTT.......................................................................................................................... 6
Méthodologie de construction d'un diagramme de gantt............................................................................................................6
Intérêt du diagramme de gantt...................................................................................................................................................7
THÉORIE
DES GRAPHES ............................................................................................................................. 7
Définition mathématique d'un graphe.........................................................................................................................................7
Divers modes de représentation d'un graphe............................................................................................................................7
PERT........................................................................................................................................... 10
MPM............................................................................................................................................ 10
DÉMARCHES DE QUALITÉ EN INFORMATIQUE........................................................................1
Approche qualité .......................................................................................................................................................................2
Vision processus ......................................................................................................................................................................3
Vision produit ............................................................................................................................................................................5
L'audit qualité.............................................................................................................................................................................6
1/16
11-COURS_MSI_Gestion_projet_SI-Outils
DSCG : UE5 - Management des Systèmes d'Information
gestion de projet : Outils
Les outils de la décomposition cartésienne
(Management des SI M. et P. GILLET -DUNOD)
« Pour appréhender une quelconque réalité, il faut diviser chaque chose en éléments simples afin d'en
maîtriser la compréhension, de les ordonner et de dénombrer les éléments pour s'assurer de ne rien
omettre. » - René Descartes
Les objectifs de la décomposition:
•
ne rien omettre des résultats à obtenir pour garantir que l'objectif global soit atteint;
•
constituer des lots de résultats et de tâches homogènes, qui pourront faire l'objet de
commandes à des prestataires, fournisseurs internes ou externes pour réalisation. Chaque lot
devra être confié à un prestataire unique responsable de sa réalisation, vis-à-vis du chef de
projet.
Trois étapes de décomposition sont à réaliser.
PBS : Products Breakdown Structure
Il fournit une décomposition sous forme d'organigramme des résultats partiels à obtenir pour atteindre
le résultat global objectif du projet. Un résultat élémentaire dans l'organigramme sera confié à un seul
prestataire, chargé de sa réalisation. Ce type de décomposition visant à ne rien omettre suivra un
raisonnement logique et non chronologique. Les branches de premier niveau correspondent à des
axes de réflexion de la décomposition liés au métier ou à la nature du projet. Le degré de
décomposition, ou granularité de la décomposition, dépendra du degré de visibilité du chef de projet.
PBS . organigramme projet
WBS : Works Breakdown Structure
Il fournit la décomposition, sous forme d'organigramme, des tâches à effectuer pour obtenir les
résultats du PBS. En dehors du fait, que cet organigramme porte sur les tâches et non sur les
résultats, il se construit de la même manière que le précédent, en appliquant les mêmes principes. Le
nombre de tâches étant généralement plus important que le nombre des résultats à obtenir,
l'organigramme de décomposition sera présenté par niveau sous forme de plusieurs documents
successifs.
Le WBS constitue les données de base de la planification. Il faudra y ajouter la chronologie et la durée
des tâches pour réaliser un ordonnancement en PERT Temps et la gestion des ressources pour
passer en PERT Coût.
Le niveau inférieur comportant les tâches élémentaires constituera les tâches du graphe
d'ordonnancement et les niveaux supérieurs permettront de matérialiser la notion de tâches
récapitulatives.
2/16
11-COURS_MSI_Gestion_projet_SI-Outils
DSCG : UE5 - Management des Systèmes d'Information
gestion de projet : Outils
OBS : Organization Breakdown Structure
Ce document se présentera sous forme d'un tableau, permettant de définir, pour chacune des tâches
du WBS, les ressources à mettre en œuvre, avec leur rôle, leur durée de travail et leur coût.
Tâches
Niveau 1 du PBS
Niveau 2 du PBS
Tâche
récapitulative de
niveau 1
Tâche
récapitulative de
niveau 2
Mise en place des Mise en place du
moyens techniques site central
Mise en place des Mise en place du
moyens techniques site central
Mise en place des Mise en place des
moyens techniques postes clients
Mise en place des Mise en place des
moyens techniques postes clients
Mise en place des Mise en place des
moyens techniques postes clients
Ressource 1
Ressource 2
Ressource 3
Niveau tâche
élémentaire du
WBS
Quantité de
Quantité de ressource
ressource
Durée de travail
Tâche élémentaire
Durée de travail
Rôle
Rôle
Coût
Coût
Chef de projet
Service informatique
1 personne
Appel d'offre pour 1 personne
1 jour
le serveur
5 jours
Rôle=
Rôle = Production
Certification
Service informatique Chef de projet
Installation du
2 personnes
1 personne
serveur
3 jours
1 jour
Rôle = Production
Rôle =Certification
Service informatique Chef de projet
Évaluations des
2 personnes
1 personne
besoins
2 semaines
1 jour
Rôle = Production
Rôle = Certification
Service informatique Chef de projet
Commandes des 1 personne
1 personne
postes
1 jour
1 jour
Rôle = Production
Rôle = Certification
Service informatique Chef de projet
Installation des
3 personnes
1 personne
postes
1 mois
2 jours
Rôle = Production
Rôle = Certification
3/16
Quantité de
ressource
Durée de travail
Rôle
Coût
11-COURS_MSI_Gestion_projet_SI-Outils
DSCG : UE5 - Management des Systèmes d'Information
gestion de projet : Outils
L'organigramme du WBS : Works Breakdown Structure présente souvent plusieurs niveaux.
Les niveaux supérieurs constitueront ce qu'il est convenu d'appeler des tâches récapitulatives et le
niveau feuille, les tâches élémentaires. Afin de faciliter le passage du tableau de l'OBS à un logiciel de
planification, il est conseillé de prévoir autant de colonnes de présentation des tâches que de niveau
dans l'organigramme du WBS.
•
Il existe plusieurs manières de définir et de gérer les ressources
Les ressources peuvent être gérées de manière individuelle (M. X, Mme Y) ou par rôle (informaticien,
chef de projet, comptable ... ). Dans le cadre de la mise en place de la méthode projets, qui nécessite
une gestion commune des ressources pour l'ensemble des projets, la seconde solution est préférable.
La première solution présente un intérêt par rapport à l'interaction avec les agendas partagés et les
messageries électroniques. Par contre, elle sera gênante dans la consolidation des projets, car elle ne
permettra pas de gérer la polyvalence des acteurs.
•
Quantification des ressources disponibles
Pour chaque ressource, on possédera une information de quantité, en nombre ou en pourcentage (3
maçons, 20 % de chef de projet utilisateur. .. ). Si la quantification décimale parait plus naturelle, elle
sera source d'erreurs dans la planification ultérieure. Il est préférable d'avoir recours à une
quantification en pourcentage. Pour deux personnes à plein temps, on dira 200 % et non 2. Pour une
personne à 10 % de son temps on dira 10 % et non 0,1.
•
Détermination des durées de travail
Pour chaque ressource, on déterminera la durée de travail requise pour la tâche. La durée de travail
d'une ressource est différente de la durée de la tâche en elle-même. Il peut y avoir des temps
d'attente (délai de livraison, par Exemple), qui rallonge la durée de la tâche, mais ne nécessite pas de
travail. Le coût de l'utilisation de la ressource sera donc fonction de son temps de travail et non de la
durée de la tâche en elle-même.
Chaque ressource jouera un rôle dans le cadre de la réalisation d'une tâche
Les rôles définit habituellement sont:
•
R: la Responsabilité sur la tâche
Exemple :
Le directeur informatique est responsable du respect du délai pour la fourniture d'un livrable dans le
cadre d'un développement de logiciel.
• P: la Production de la tâche et du résultat qui en constitue l'objectif
Exemple
le service informatique développe une fonctionnalité dans un logiciel;
l'entreprise de maçonnerie monte les murs de la maison.
• S: le Support dans la réalisation de la tâche constitue un apport de conseil dans un domaine
technique
Exemple
le service informatique offre un support technique pour la mise en place d'un progiciel;
le service juridique apporte son assistance dans la rédaction du cahier des charges.
• C: la Certification de la tâche consiste à garantir que les moyens mis en œuvre correspondent
à ceux qui étaient prévus
Exemple
le groupe de revue de projet certifie que les moyens mis en œuvre correspondent au cahier des
charges;
le chef de projet certifie à la livraison la correspondance avec la commande passée.
à l'approbation définit l'adéquation entre le résultat obtenu et le résultat attendu
Exemple
le comité de pilotage du projet approuve un résultat obtenu;
les utilisateurs effectuent la recette fonctionnelle du logiciel.
Le coût spécifié pour l'obtention d'une ressource nécessaire à la réalisation d'une tâche Il peut être:
Un coût fixe à l'utilisation de la ressource.
4/16
11-COURS_MSI_Gestion_projet_SI-Outils
DSCG : UE5 - Management des Systèmes d'Information
gestion de projet : Outils
Exemple
L'achat d'un « équipement fait l'objet d'un devis et la facture sera à régler aux conditions prévues,
après la livraison.
•
Un coût variable, proportionnel au temps de travail, tenant compte
d'éventuelles heures supplémentaires à un taux majoré.
Exemple
Le coût des trois maçons présents sur le chantier pour monter les murs de la maison sera
proportionnel à la durée de travail nécessaire. De plus, si, pour éviter un retard par rapport aux autres
corps de métiers ou pour éviter des intempéries annoncées, il est nécessaire de faire travailler les
maçons en heures supplémentaires, le coût de l'heure de travail va être plus élevé, compte tenu du
tarif majoré des heures supplémentaires.
RACI
RACI est un outil simple qui liste dans un tableau l'ensemble des participants d'un projet et leurs
responsabilités.
L'acronyme RACI signifie :
•
•
•
•
R : Responsible
A : Accountable
C : Consulted
I : Informed
Cet outil de management permet de communiquer clairement sur :
•
•
•
•
quels sont les membres opérationnels du projet et leurs tâches respectives
qui est l'unique décideur
quels sont les gens pouvant être sollicités comme conseils
quel sont les personnes qui doivent être informées des évolutions du projet
Les règles de construction de cette matrice sont :
•
•
•
•
Le A est celui qui doit rendre des comptes sur l'avancement de l'action. Il y a toujours un
et un seul A pour chaque action. « Avoir le A » signifie être totalement responsable d'une
action
Le A ou les R (le A peut aussi jouer le rôle de R) réalisent l'action. Il y a au moins un R pour
chaque action. Le A est responsable de l’organisation du travail du ou des R. Si les R ne
remplissent pas leurs objectifs, le A reste responsable de la situation.
Le A ou les C sont les participants qui doivent être consultés. Sur consultation du A et des R,
ils donnent leur avis sur les sujets où ils sont experts. Les C n'ont pas autorité. C'est le
A qui décide de prendre en compte ou non l'avis des C.
Les I sont les personnes qui doivent être informés. Elles sont classiquement indirectement
impactées par le projet, comme les utilisateurs, les responsables de projets périphériques...
5/16
11-COURS_MSI_Gestion_projet_SI-Outils
DSCG : UE5 - Management des Systèmes d'Information
gestion de projet : Outils
Les techniques d'ordonnancement des tâches
Diagramme de GANTT
Conçu en 1917, par Henry L. Gantt, pour améliorer la gestion des ateliers des entreprises, cet outil a
très rapidement montré son utilité dans la gestion de tout projet nécessitant la coordination, dans le
temps, d'un ensemble de tâches.
Il se présente sous la forme d'un planning présentant en ligne les tâches élémentaires d'un projet et
en colonne l'échelle de temps retenue (jours, semaine, etc.). Ce tableau permet donc de visualiser
d'un simple coup d'œil les différentes étapes de réalisation d'un projet et leur état d'avancement.
Méthodologie de construction d'un diagramme de gantt
L'élaboration d'un diagramme de GANTT suppose que toutes les tâches nécessaires à la réalisation
de l'objectif poursuivi soient clairement identifiées, hiérarchisées (relations d'antériorité) et quantifiées
en terme de délai d'exécution, de charges ou de ressources nécessaires (humaines, techniques et
financières).
La démarche à suivre, peut passer par les cinq étapes suivantes :
1. Déterminer et structurer la liste des tâches à réaliser pour mener à bien le projet : pour
identifier les tâches à réaliser il est possible d'avoir recours aux différentes techniques
d'idéation (brainstorming, synectiques, groupe nominaux, etc.) ou méthodes rationnelles
(matrice de découverte, méthode morphologique, etc.). La liste obtenue est ensuite
structurée. Les tâches élémentaires sont logiquement regroupées en "lots de tâches"
(workpackages) et hiérarchisées les unes par rapport aux autres.
2. Estimer les durées et les ressources des tâches identifiées : à cette fin, il peut être utile
d'établir un tableau présentant, pour chaque tâche, la durée de celle-ci et les ressources
(matérielles et/ou humaines) affectées.
•
L'unité de temps pour exprimer la durée est, bien entendu, fonction du type de projet
à réaliser. Elle peut aller de la minute (par exemple pour la programmation d'un
concert), à l'année (par exemple pour un important projet de promotion immobilière).
•
La seule précaution à prendre est d'utiliser les mêmes unités de temps et types de
ressources pour toutes les tâches, dans un souci d'harmonisation du diagramme final.
3. Réaliser le "réseau logique" : celui-ci vise à traduire visuellement les relations d'antériorité des
tâches précédemment définies. Il se présente généralement sous la forme d'un diagramme où
l'ensemble des tâches son représentées et reliées entre elles par des liens logiques (relations
d'antécédence et de succession). Son tracé permet de visualiser la chronologie du projet (cf.
graphe PERT et/ou MPM)
4. Tracer le diagramme de GANTT : il s'agit de formaliser les étapes précédentes dans un
diagramme de synthèse, faisant apparaître en ordonnée la liste des "lots de tâches"
(workpackages) et en abscisse l'échelle de temps adopté (généralement en semaines ou
mois).
À l'intérieur de ce cadre, les tâches sont figurées sous la forme de traits ou de rectangles d'une
longueur proportionnelle à leur durée, leur position horizontale reflétant leur ordre logique d'exécution.
La méthode la plus simple consiste à commencer par représenter les tâches n'ayant aucune
antériorité, puis celles qui peuvent immédiatement leur succéder et ainsi de suite jusqu'à ce que
toutes les tâches aient été positionnées.
6/16
11-COURS_MSI_Gestion_projet_SI-Outils
DSCG : UE5 - Management des Systèmes d'Information
gestion de projet : Outils
Éventuellement plusieurs tâches peuvent être réalisées simultanément (sous réserve d'une
disponibilité des ressources nécessaires) ce qui permet de diminuer la durée totale d'exécution du
projet et, donc, son coût.
Intérêt du diagramme de gantt
Ce type de diagramme permet de visualiser l'enchaînement des différentes étapes du déroulement
d'un projet et offre, ainsi, la possibilité :
•
de prévoir suffisamment à l'avance les actions à entreprendre pour minimiser le temps de
réalisation d'un projet
•
d'identifier les tâches critiques (tâches pour lesquelles aucun retard n'est possible sans
retarder d'autant la date de fin du projet) et les marges (totale, libre et certaine) des autres.
•
de faciliter le suivi de l'état d'avancement du projet (notamment évaluation de l'impact global
d'un retard sur une tâche intermédiaire)
•
de gérer au mieux les éventuels conflits de ressources
•
de servir d'outil de communication entre les différents acteurs impliqués dans la réalisation du
projet.
Théorie des graphes
Définition mathématique d'un graphe
Soit un ensemble X de n sommets. Soit une application A entre les éléments de l'ensemble X. Le graphe
est le couple (X,A) qui définit la relation liant les points.
La relation entre deux sommets peut être orientée ou non. Si oui, cette relation est un arc. Si non, cette
relation est une arête. Un graphe dont toutes les relations sont orientées est un graphe orienté.
Il est plus facile d'appréhender le concept de graphe en s'appuyant sur une représentation visuelle.
Divers modes de représentation d'un graphe
Représentation graphique
On peut représenter un graphe via un diagramme sagittal. Les arêtes sont explicitement définies par les
segments reliant les sommets. Si le graphe est orienté, ces segments sont des flèches (sagittal signifiant «
qui a la forme d'une flèche »).
Représentation matricielle
On peut associer au diagramme sagittal une représentation matricielle.
Source
Cible
A
B
C
D
E
F
A
0
0
0
0
0
0
B
1
0
0
0
0
0
C
0
1
0
0
0
0
D
0
1
1
0
1
0
E
1
0
0
0
0
0
F
0
0
0
0
1
0
Un 1 sur le couple Ligne(B) Col(C) indique la présence d'un arc entre les sommets B et C.
En ligne: du sommet E partent les arcs ED et EF.
En colonne: au sommet D arrivent les arcs BD, CD et ED.
7/16
11-COURS_MSI_Gestion_projet_SI-Outils
DSCG : UE5 - Management des Systèmes d'Information
gestion de projet : Outils
Dictionnaire
Le dictionnaire de type 1 fait l'inventaire des sommets immédiatement suivants et immédiatement
précédents. Ce sont les sommets adjacents. Le dictionnaire qui suit correspond au graphe défini cidessus.
Sommets
Immédiatement précédents
Sommets
A
Immédiatement suivants
A
B, E
B
A
B
C, D
C
B
C
D
D
B, C, E
D
E
A
E
F
E
F
F, D
Le dictionnaire de type 2 définit des règles d'antériorité (ou de postériorité) générales.
Sommets
Précédents
Sommets
Suivants
A
B,C,D,E,F
A
B
C, D
C
A,B
C
D
D
A,B,C,E
D
E
A
E
F
A,E
F
A
B
F,D
Ce mode de représentation ne définit pas explicitement le graphe. Plusieurs graphes répondent à un même
dictionnaire.
Construction d'un graphe à partir d'un dictionnaire
Soit le dictionnaire type 2 :
Tâche
Pour lancer cette tâche, il faut que soient réalisées les tâches
A
B
A
C
A,B
D
A,B,C,E
E
A
F
A,E
La construction du graphe s'opère en deux étapes:
1. recherche des niveaux;
2. suppression des redondances.
Recherche des niveaux
La recherche des niveaux s'effectue à partir du dictionnaire.
•
•
Niveau 0 : Sommets sans précédent : A .
Niveau 1 : On élimine dans le dictionnaire les sommets de niveau 0 (A).
Sommets
Précédents
Sommets
A
Précédents
B
B
A
C
B
C
A,B
D
B,C,E
D
A,B,C,E
E
E
A
F
F
A,E
E
On passe du niveau 1 au niveau 2.
• Niveau 1 : Sommets B et E dont tous les précédents ont été éliminés.
• Niveau 2 : On élimine dans le dictionnaire les sommets de niveau 1 (B et E).
Sommets
Précédents
Sommets
B
C
B
8/16
Précédents
C
/
D
C
11-COURS_MSI_Gestion_projet_SI-Outils
DSCG : UE5 - Management des Systèmes d'Information
D
gestion de projet : Outils
B,C,E
F
/
E
F
E
On passe du niveau 2 au niveau 3.
•Niveau 2 : Sommets C et F dont tous les précédents ont été éliminés.
•Niveau 3 : Reste D.
Sommets
Précédents
D
C
On aboutit donc au schéma de répartition des sommets par niveau:
Répartition des sommets par niveau
Niveau 0
Niveau 1
Niveau 2
Niveau 3
C
B
A
D
F
E
Cette recherche peut s'opérer à partir d'une matrice, un peu différente de celle déjà vue car le graphe n'est
pas explicitement défini.
A
0
0
0
0
0
0
A
B
C
D
E
F
B
1
0
0
0
0
0
C
1
1
0
0
0
0
D
1
1
1
0
1
0
E
1
0
0
0
0
0
F
1
0
0
0
1
0
C
1
1
0
0
0
0
2
D
1
1
1
0
1
0
4
E
1
0
0
0
0
0
1
F
1
0
0
0
1
0
2
A est un antécédent pour B, C, D, E et F (011111).
B est un antécédent pour C et D (001100).
C est un antécédent pour D (000100).
E est un antécédent pour D et F (000101).
D et F ne sont des antécédents pour rien (000000).
Sont de niveau 0 les sommets dont le total est égal à
A
0
0
0
0
0
0
0
A
B
C
D
E
F
Σ
o.
B
1
0
0
0
0
0
1
A est de niveau 0.
Pour déterminer le niveau 1, les lignes et les colonnes de niveau 0 (A) sont barrées et le total des colonnes
est recalculé.
B
C
D
E
F
Σ
B
0
0
0
0
0
0
C
1
0
0
0
0
1
D
1
1
0
1
0
3
E
0
0
0
0
0
0
F
0
0
0
1
0
1
B et E sont de niveau 1.
Pour déterminer le niveau 2, les lignes et les colonnes de niveau 1 (8 et E) sont barrées et le total des
colonnes est recalculé.
9/16
11-COURS_MSI_Gestion_projet_SI-Outils
DSCG : UE5 - Management des Systèmes d'Information
gestion de projet : Outils
C
0
0
0
0
C
D
F
Σ
D
1
0
0
1
F
0
0
0
0
Cet F sont de niveau 2. D est de niveau 3.
Suppression des redondances
La suppression des redondances ne s'opère que dans le cas de dictionnaires de type 2. Le graphe est non
complètement défini. Tous les sommets sont fournis (et non seulement les sommets adjacents).
La démarche consiste à rechercher les antécédents des tâches antérieures:
Sommets
Précédents
Antécédents
Antérieur
immédiat
A
B
A
C
A,B
A
B
D
A,B,C,E
A,A,B,A
C,E
E
A
F
A,E
A
A et B sont éliminés car
présents dans les deux
tableaux.
A
A
E
Graphe après suppression des redondances
PERT
Le PERT (Programm of Evaluation and Review Technic) est, comme la MPM, une technique
d'ordonnancement basée sur la théorie des graphes, visant à optimiser la planification des tâches d'un
projet.
Cette technique a été conçue sous l'appellation initiale de méthode CPM (Critical Method Path) par la
marine américaine, en 1958, pour coordonner les tâches des milliers d'entreprises impliquées dans
son projet "Polaris" (programme de développement de missiles à ogive nucléaire).
Compte tenu de son efficacité (elle aurait permis de réduire de 14 à 7 ans la durée globale de
réalisation du projet Polaris) elle s'est rapidement imposée dans les organisations, gouvernementales
ou non, ayant à gérer des projets importants (programme Apollo de la NASA, construction
d'autoroute, etc.) au détriment du diagramme de Gantt.
L'utilisation du PERT permet, notamment, de déterminer la durée minimum nécessaire pour mener à
bien un projet et les dates auxquelles peuvent ou doivent débuter les différentes tâches nécessaires à
sa réalisation pour que cette durée minimum soit respectée.
MPM
La Méthode des Potentiels et antécédents Métra (MPM) est, comme le PERT, une technique
d'ordonnancement basée sur la théorie des graphes, visant à optimiser la planification des tâches d'un
projet
Elle a été mise au point en 1958 par un chercheur français, Bernard Roy, au sein de la société de
conseil Métra, dans le cadre du projet de construction du paquebot "France".
10/16
11-COURS_MSI_Gestion_projet_SI-Outils
DSCG : UE5 - Management des Systèmes d'Information
gestion de projet : Outils
Bien que le PERT se soit d'abord imposé en matière de gestion de projet, la MPM tend, depuis les
années 1980, à le supplanter. Cette méthode s'avère, en effet, beaucoup plus souple et mieux
adaptée à une automatisation du traitement des données (notamment en terme de représentation
graphique et d'algorithme de calcul).
L'utilisation de la MPM permet, notamment, de déterminer la durée minimum nécessaire pour mener à
bien un projet et les dates auxquelles peuvent ou doivent débuter les différentes tâches nécessaires à
sa réalisation pour que cette durée minimum soit respectée.
Démarches de qualité en informatique
(Impact des décisions informatiques sous la direction de Philippe GUGERDIL -PPUR 2005)
La qualité d'un logiciel peut s'exprimer selon plusieurs points de vues. En effet, un utilisateur parlera
volontiers d'ergonomie, un programmeur s'intéressera à la possibilité de réutilisation du code, le
spécialiste système pensera à la performance et à l'optimisation des ressources alors que l'équipe de
maintenance s'attachera plus particulièrement à la facilité d'évolution et de modification du logiciel.
Chacun semble avoir sa propre vision de ce qu'est la qualité. Cette situation crée passablement de
confusion, d'incompréhension et, finalement, d'insatisfaction. Il s'agit donc de donner une définition
claire de la qualité qui permette de concevoir et développer des logiciels de qualité correspondant aux
attentes des utilisateurs.
Définition de l'ISO 9000:
exigences ».
({
Aptitude d'un ensemble de caractéristiques intrinsèques à satisfaire des
Cette définition exprime que la qualité est liée aux exigences. Il n'y a, ainsi, pas une seule mesure
absolue de la qualité du logiciel. La qualité d'un logiciel, c'est son aptitude à satisfaire les besoins
explicites et implicites du client. Cela signifie que toutes les attentes ne doivent pas être traitées sur
un même plan.
Un logiciel mis à disposition du client est composé de fonctions. Ces fonctions sont sensées remplir
les attentes du client. Le Dr Shoji Shiba, expert international dans la gestion de la qualité totale,
identifie trois types de fonctions pour répondre aux besoins des clients :
•
les fonctions obligatoires,
•
les fonctions proportionnelles
•
les fonctions attractives.
C'est le diagramme de Kano qui permet de montrer l'évolution de la satisfaction du client par rapport
au degré de maîtrise des fonctions qui composent le produit
La courbe du bas désigne les fonctions obligatoires qui
correspondent aux attentes implicites du client. Ces
fonctions doivent être parfaitement maîtrisées pour
atteindre un degré de satisfaction neutre. Le moindre
défaut dans cette catégorie de fonctions fait descendre
de manière catastrophique la satisfaction du client.
Nous pouvons ranger dans cette catégorie, entre
autres, toutes les fonctions liées à la sécurité, car elles
se doivent d'être irréprochables en cas de problème.
Nous pouvons très bien imaginer la colère du client, si
en cas d'interruption du courant électrique, la
procédure de récupération des données présente un
défaut et que ceci provoque la perte des commandes
de produits de la journée.
La ligne du milieu désigne les fonctions proportionnelles, selon la terminologie de S. Shiba, qui
correspondent aux attentes explicites du client. Plus ce type de fonction est maîtrisé, plus le client est
satisfait. L'importance d'un éventuel défaut provoque ici une baisse proportionnelle de sa satisfaction.
Cette catégorie correspond aux groupes de fonctionnalités demandées explicitement par le client. Par
exemple, si le nouveau programme d'impression des factures du mois prend trois fois moins de temps
que le précédent, le client sera vraisemblablement très satisfait ; s'il prend autant de temps que le
précédent, il ne sera que moyennement satisfait en fonction de son exigence.
11/16
11-COURS_MSI_Gestion_projet_SI-Outils
DSCG : UE5 - Management des Systèmes d'Information
gestion de projet : Outils
La courbe du haut désigne les fonctions attractives, qui correspondent aux attentes latentes du client.
Même avec un faible degré de maîtrise de ce type de fonction, il est extrêmement satisfait. Nous
sommes ici dans le domaine de l'innovation, les fonctions ne sont pas demandées, mais elles ciblent
exactement une attente latente. Par exemple, un logiciel qui serait capable d'interpréter les pensées
de son utilisateur provoquerait chez celui une très forte satisfaction, même si les seules commandes
disponibles étaient : «imprime les factures du mois» et «cherche produit... ». Le client pourrait
s'enorgueillir de ce type de fonctionnalités même si à l'usage elles ne «marchaient»
qu'imparfaitement.
On apprend ainsi à mieux comprendre la vision du client, ses besoins et ses attentes. Cela permet
ensuite d'orienter le développement et les mesures d'amélioration des caractéristiques clés du logiciel
selon les trois types d'attentes : implicite, explicite et latente.
Pour certains produits, les attentes sont facilement identifiables. Un client qui commande une voiture,
par exemple, peut avoir une attente explicite du type: «je désire un véhicule à quatre roues motrices».
Il n'a pas besoin d'exprimer une attente implicite comme: «je veux que le véhicule soit doté d'une
marche arrière». Une voiture est un produit pour lequel les attentes implicites sont relativement
stables et connues. Pour le logiciel, le problème est plus délicat car les attentes implicites dépendent
du domaine concerné et de l'évolution rapide des technologies. Les utilisateurs connaissent leur
domaine métier, ce qui n'est pas nécessairement le cas des Informaticiens qui auront donc besoin
que leurs interlocuteurs explicitent clairement leurs activités. Le risque existe cependant que des
fonctions implicites, selon l'utilisateur, ne soient pas connues de l'informaticien.
Du point de vue de l'évolution rapide des technologies, il y a également le risque qu'une fonctionnalité
qui, il y a quelques mois, correspondait à une attente latente, aujourd'hui soit explicitement demandée
et que dans un futur proche elle soit complètement implicite. Par exemple, si les «info-bulles»,
informations données quand la souris passe sur un objet graphique de l'interface, étaient il y a
quelque temps encore dans la liste des attentes explicites, elles font partie, aujourd'hui, des attentes
implicites de la plupart des utilisateurs. Comme le montre le diagramme de Kano, si un produit ne
remplit pas une attente implicite, la satisfaction du client diminue très rapidement et ceci peut avoir
des conséquences catastrophiques sur la perception de la qualité du logiciel.
La qualité du logiciel dépend donc de l'expression des attentes et de la façon dont ces attentes seront
satisfaites (processus de développement). Ceci implique que le mandant d'un projet informatique soit
en mesure:
•
de comprendre ce que recouvrent les démarches de qualité en informatique;
•
d'obtenir une garantie de qualité sur le processus de développement ;
•
d'exprimer ce que doit être la qualité du produit et de valider les « livrables ».
Approche qualité
L'approche qualité est basée sur le concept de la roue de Deming , désignée en anglais par Plan, Do,
Check, Act (PDCA). C'est une méthode de gestion de projet qui permet d'une part d'avoir toujours une
vision globale du processus et d'autre part de permettre les adaptations et les évolutions. Cette
approche est à la source du pilotage des processus proposé par la norme internationale ISO 9001.
C'est, en effet, ce modèle qui est employé par un département informatique qui s'engage dans la
certification de son processus de développement de projets informatiques.
L'approche consiste à découper un projet en étapes. Chacune des étapes est planifiée, effectuée,
contrôlée et finalement validée. Ce modèle permet aux acteurs de garder la vision globale du pilotage
du projet et, à chaque fin d'étape, de décider formellement des actions à entreprendre pour le
démarrage de l'étape suivante.
4. Act = valider, prendre les
mesures correctives pour arriver au
résultat et s'assurer que cet acquis
demeurera stable
1. Plan = définir les objectifs et
planifier
3. Check = évaluer, vérifier que les
objectifs sont atteints
2. Do = faire exécuter la tâche
12/16
11-COURS_MSI_Gestion_projet_SI-Outils
DSCG : UE5 - Management des Systèmes d'Information
gestion de projet : Outils
Les démarches de qualité en informatique consistent donc à piloter les projets en procédant par
boucles ou itérations successives .
Chacune des boucles se termine par une validation. Cette validation permet de prendre acte des
conclusions de l'évaluation du processus et du produit. Nous pouvons ainsi progresser en gardant la
vision globale du projet tout en étant capable de faire évoluer celui ci.
Cette démarche peut s'appliquer à n'importe quel projet. Par exemple, un groupes d'amis qui décide
de monter une pièce de théâtre peut choisir de réaliser ce projet en trois boucles:
•
La première boucle peut consister à choisir un texte et un local.
•
La deuxième boucle à apprendre les rôles, créer la mise en scène et régler les aspects
administratifs.
•
La dernière à préparer les costumes, les décors, faire les dernières répétitions et la promotion
du spectacle.
Chacune de ces boucles est planifiée, effectuée, contrôlée et finalement acceptée. Ceci a pour effet,
qu'à la fin de la première boucle, nos amis doivent se méttre d'accord sur le choix du texte et du local.
A la fin de la deuxième boucle les amis doivent vérifier qu:ils connaissent leur rôle, que la mise en
scène est définie et que les aspects administratifs sont réglés. Si ce n'est pas le cas, ils doivent
décider des actions d'amélioration à apporter. Ainsi la planification de la troisième boucle doit prendre
en compte les actions d'amélioration et les autres tâches prévues. L'aspect formel des acceptations
de fin de boucle oblige les amis, chaque fois, à se mettre d'accord. Dans notre exemple, le choix du
texte et du local, à la fin de la première boucle, implique que tout 1e projet va se poursuivre en
fonction de ces choix initiaux.
Vision processus
Le mandant d'un projet informatique doit être en mesure d'obtenir une garantie sur le processus de
développement du projet. Pour ce faire, il va utiliser le concept d'assurance qualité afin de prévenir
l'apparition des défauts. L'outil principal de l'assurance qualité est le plan d'assurance qualité qui décrit
les dispositions spécifiques à prendre et les revues nécessaires à la vérification et à la validation du
développement du projet.
Assurance qualité
L'assurance qualité est, selon la définition ISO 9000, la partie du management de la qualité visant à
donner confiance en ce que les exigences pour la qualité soient satisfaites. En effet, l'une des
hypothèses de base de l'assurance qualité, c'est que la qualité du processus de développement d'un
logiciel a un impact direct sur la qualité du logiciel produit. Il s'agit donc de piloter le processus de
développement en mettant en place un mécanisme de prévention des défauts qui consiste à définir,
au début du projet, les activités de vérification et de validation du cycle de développement
Ce mécanisme d'assurance qualité s'appuie sur l'engagement conjoint de la maîtrise d'ouvrage
(mandant) et de la maîtrise d'œuvre (équipe de projet)s. En particulier, les activités de vérification et
13/16
11-COURS_MSI_Gestion_projet_SI-Outils
DSCG : UE5 - Management des Systèmes d'Information
gestion de projet : Outils
validation doivent être réalistes par rapport au contexte du projet en terme de ressources et de délais.
Elles vont permettre à la maîtrise d'ouvrage de suivre, d'apprécier et d'anticiper l'avancement du
projet, et à la maîtrise d'œuvre d'organiser son travail.
Plan d'assurance qualité (PAQ)
Le plan d'assurance qualité représente l'ensemble des dispositifs qualité spécifiques à un projet mis
en place dans le cadre de l'assurance qualité de façon à permettre à ce projet d'atteindre ses
objectifs. Dans le cas du développement de logiciel, il décrit les dispositions spécifiques prises par
l'entreprise pour obtenir la qualité exigée :
•
Il intègre les exigences qualité du client (clause qualité du contrat). Il définit les actions et les
moyens nécessaires pour chaque activité et spécifie les techniques et méthodes de contrôle
utilisées pour vérifier l'application des règles de qualité.
•
Il est rédigé par le responsable qualité du projet en collaboration avec le chef de projet (ce
dernier assurant la responsabilité globale du projet et de sa qualité).
Pour chaque projet, il s'agit de définir un plan d'assurance qualité qui lui est propre. La structure de ce
plan est généralement fondée sur un standard reconnu. Un des standards existants est celui défini
par la section Logiciel de l'AFCIQ (Association Française pour le Contrôle Industriel et Qualité). A titre
d'illustration, nous en énumérons les douze chapitres.
1. But, domaine d'application et responsabilités
2. Documents applicables et de référence
3. Terminologie
4. Organisation
5. Démarche de développement
6. Documentation
7. Gestion de la configuration
8. Gestion des modifications
9. Méthodes, outils et règles
10. Contrôle des fournisseurs
11. Reproduction, protection, livraison
12. Suivi de l'application du plan qualité
L'essentiel est de faire comprendre aux intervenants du projet que le plan d'assurance qualité, lorsqu'il
est respecté, représente une garantie d'obtention de la qualité.
Le plan d'assurance qualité n'est pas un document figé. Les améliorations proposées par les
différents intervenants du projet doivent être étudiées et intégrées dans le plan d'assurance qualité au
cours de la vie du projet. Le plan d'assurance qualité fait donc l'objet d'enrichissements progressifs et
les changements par rapport à la version précédente sont clairement explicités.
Revue de fin de phase
Les revues de fin de phase sont des actions de contrôle, prévues dans le plan d'assurance qualité,
portant à la fois sur le processus et sur le produit afin de s'assurer que les conditions sont réunies
pour débuter une nouvelle phase. C'est le «Check» de la roue de Deming.
Les travaux à conduire lors de ces actions sont de quatre types et portent sur :
•
l'approbation des dossiers produits en fin de phase;
•
le contrôle qualité des prestations effectuées au cours de la phase;
•
le bilan de fin de phase;
•
l'évaluation des travaux à conduire lors de la phase suivante ainsi que lors des phases
restantes du projet.
14/16
11-COURS_MSI_Gestion_projet_SI-Outils
DSCG : UE5 - Management des Systèmes d'Information
gestion de projet : Outils
Les conclusions formelles sont enregistrées en vue de déterminer les actions à prendre: c'est le «Act»
de la roue de Deming. Ces conclusions peuvent aboutir à une acceptation totale de la phase, une
acceptation conditionnelle, au refus du travail effectué ou à l'arrêt du projet.
Les conditions suivantes sont nécessaires au bon déroulement des revues:
•
Les personnes conviées doivent connaître, avant la réunion, les points qui devront être
acceptés.
•
Les personnes adéquates sont toutes réunies, avec le pouvoir de signature.
•
Les documents sont envoyés et reçus avant la réunion avec un temps raisonnable pour leur
lecture préalable.
•
Les documents d'acceptation sont préalablement discutés et communiqués avant la réunion.
Quand un désaccord ou une erreur est mis en évidence, les acteurs de la revue vont, dans la mesure
du possible, établir une acceptation conditionnelle et fixer un délai pour la réalisation des modifications
nécessaires. L'avantage de l'acceptation conditionnelle sur le refus est qu'elle permet au projet de
continuer, évitant ainsi une nouvelle réunion avec les mêmes acteurs concernant les mêmes thèmes.
Vision produit
S'agissant de la qualité du produit, des listes de contrôle peuvent être élaborées afin d'évaluer le
niveau de qualité en parfaite adéquation avec les facteurs préalablement retenus par l'utilisateur .
Facteurs de qualité du logiciel
Les facteurs qualités d'une application informatique ont été définis par B. Boehm et répartis en trois
catégories : aptitude à être utilisée en l'état, aptitude à être maintenue, aptitude à être transférée. J.
Mac Cali, dans une approche semblable à B. Boehm, a recensé 55 facteurs potentiellement
utilisables. L'expérience a montré que les facteurs tes plus utilisés sont: la conformité, la fiabilité,
l'efficacité, l'intégrité, la facilité d'emploi, la maintenabilité, la testabilité, la flexibilité, la portabilité, la
compatibilité et la réutilsabilité.
Facteurs liés à l'utilisation
•
.
Conformité
Le logiciel fait ce que demande l'utilisateur:
•
Fiabilité
Le logiciel fait ce qui lui est demandé en toutes circonstances.
•
Efficacité
Le logiciel ne consomme que les ressources nécessaires.
•
Intégrité
Le logiciel est protégé des erreurs de manipulation et des intrusions.
•
Facilité d'emploi
Le logiciel est facile à utiliser.
Facteurs liés à la maintenance
•
Maintenabilité
On peut apporter facilement des corrections au logiciel.
•
Testabilité
On peut mettre en œuvre des tests permettant de vérifier le fonctionnement correct
du logiciel après modification.
•
Flexibilité
On peut faire évoluer le logiciel et ajouter facilement de nouvelles fonctionnalités.
Facteurs liés au transfert
•
Portabilité
15/16
11-COURS_MSI_Gestion_projet_SI-Outils
DSCG : UE5 - Management des Systèmes d'Information
gestion de projet : Outils
Le logiciel est facilement utilisable sur un autre ordinateur.
•
Compatibilité
Le logiciel peut être facilement raccordé à d'autres logiciels.
•
Réutilisabilité
Une partie du logiciel peut être réutilisée dans le cadre d'une autre application.
Impact sur l'expression des besoins
Une erreur commune en assurance qualité consiste à croire que lorsque que l'on dit «de bonne
qualité», tout le monde comprend la même chose.
Les facteurs qualités sont très utiles pour nous aider à exprimer nos besoins et nos exigences. Ils
nous permettent d'exprimer nos valeurs qualités implicites et de les rendre explicites. Il est donc
recommandé lors de la phase d'analyse des besoins que les intervenants du projet informatique
procèdent aux trois étapes suivantes:
1. Définir ensemble les facteurs qualités.
2. Fixer l'importance de chaque facteur. En effet des facteurs peuvent s'opposer. Il s'agit donc
de définir des priorités.
3. Etablir des critères de mesure du succès qui permettront de dire si l'objectif est atteint.
Cette démarche permet de définir clairement ce que le terme qualité signifie pour un projet donné.
L'audit qualité
L'audit qualité du projet est un moyen d'évaluer la qualité du processus. L'AFNOR le définit comme «
l'examen méthodique d'une situation relative à un produit, procédé ou organisation, réalisé en
coopération avec les intéressés en vue de vérifier la conformité de cette situation aux dispositions
préétablies et l'adéquation de ces dernières à l'objectif recherché ».
Dans les projets systèmes d'information, l'audit peut prendre différentes formes:
•
l'audit qualité porte sur le respect des dispositions du plan assurance qualité;
•
l'audit d'avancement porte sur l'état réel du projet par rapport à son avancement annoncé;
•
l'audit fonctionnel porte sur l'adéquation du système conçu aux objectifs annoncés.
Les audits ne sont pas planifiés. Ils s'appuient sur des questionnaires précis et concis, préparés à
l'avance. Les audits internes au projet se font à la demande du chef de projet. Les audits externes se
font à la demande de la maîtrise d'ouvrage ou de la direction générale. Certains audits de projet
peuvent être faits lors d'une procédure de certification IS09000. Nous allons aborder ce point dans le
cadre plus large de la qualification des entreprises.
16/16
11-COURS_MSI_Gestion_projet_SI-Outils