Table des matières - jchambon.frjchambon.fr/DSCG/Textes/11-COURS_MSI_Gestion_projet_SI-Outils.pdf · Conçu en 1917, par Henry L. Gantt, pour améliorer la gestion des ateliers des

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.................................................................................................2WBS : WORKS BREAKDOWN STRUCTURE...................................................................................................2OBS : ORGANIZATION BREAKDOWN STRUCTURE...........................................................................................3RACI.............................................................................................................................................. 5

LES TECHNIQUES D'ORDONNANCEMENT DES TÂCHES........................................................6

DIAGRAMME DE GANTT.......................................................................................................................... 6Méthodologie de construction d'un diagramme de gantt............................................................................................................6Intérêt du diagramme de gantt...................................................................................................................................................7

THÉORIE DES GRAPHES............................................................................................................................. 7Définition mathématique d'un graphe.........................................................................................................................................7Divers modes de représentation d'un graphe............................................................................................................................7

PERT........................................................................................................................................... 10MPM............................................................................................................................................ 10

DÉMARCHES DE QUALITÉ EN INFORMATIQUE........................................................................1

Approche qualité .......................................................................................................................................................................2Vision processus ......................................................................................................................................................................3Vision produit ............................................................................................................................................................................5L'audit qualité.............................................................................................................................................................................6

1/16 11-COURS_MSI_Gestion_projet_SI-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.



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 Ressource 1 Ressource 2 Ressource 3

Niveau 1 du PBS Niveau 2 du PBSNiveau tâche élémentaire du WBS

Tâche récapitulative de niveau 1

Tâche récapitulative de niveau 2

Tâche élémentaire

Quantité de ressourceDurée de travailRôleCoût



Mise en place des moyens techniques

Mise en place du site central

Appel d'offre pour le serveur

Service informatique1 personne5 joursRôle = Production

Chef de projet1 personne1 jourRôle=Certification


Mise en place du site central

Installation du serveur

Service informatique2 personnes3 joursRôle = Production

Chef de projet1 personne1 jourRôle =Certification


Mise en place des postes clients

Évaluations des besoins

Service informatique2 personnes2 semainesRôle = Production

Chef de projet1 personne1 jourRôle = Certification



Commandes des postes

Service informatique1 personne1 jourRôle = Production

Chef de projet1 personne1 jourRôle = Certification



Installation des postes

Service informatique3 personnes1 moisRôle = Production

Chef de projet1 personne2 joursRôle = Certification



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.



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.

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



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.



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

Cible

A B C D E F

Sou

rce

A 0 1 0 0 1 0B 0 0 1 1 0 0C 0 0 0 1 0 0D 0 0 0 0 0 0

E 0 0 0 1 0 1F 0 0 0 0 0 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.



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

Sommets Immédiatement précédents Sommets Immédiatement suivants

A A B, E

B A B C, D

C B C D

D B, C, E D

E A E F, D

F E F

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 A B,C,D,E,F

B A B C, D

C A,B C D

D A,B,C,E D

E A E F,D

F A,E F

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 Précédents

A B

B A C B

C A,B D B,C,E

D A,B,C,E E

E A F E

F A,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 Précédents

B C /

C B D C



D 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 B C D E FA 0 1 1 1 1 1B 0 0 1 1 0 0

C 0 0 0 1 0 0D 0 0 0 0 0 0E 0 0 0 1 0 1F 0 0 0 0 0 0

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

A B C D E FA 0 1 1 1 1 1B 0 0 1 1 0 0

C 0 0 0 1 0 0D 0 0 0 0 0 0E 0 0 0 1 0 1F 0 0 0 0 0 0Σ 0 1 2 4 1 2

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 FB 0 1 1 0 0C 0 0 1 0 0

D 0 0 0 0 0E 0 0 1 0 1F 0 0 0 0 0Σ 0 1 3 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é.



C D F

C 0 1 0

D 0 0 0

F 0 0 0

Σ 0 1 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édentsAntérieur immédiat

A

B A A

C A,B A B

D A,B,C,E A,A,B,A C,E

E A A

F A,E A E

A et B sont éliminés car présents dans les deux

tableaux.

Graphe après suppression des redondances

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


http://enset-media.ac.ma/cpa/methode_mpm.htm


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: ({ Aptitude d'un ensemble de caractéristiques intrinsèques à satisfaire des exigences ».

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.



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

3. Check = évaluer, vérifier que les objectifs sont atteints

1. Plan = définir les objectifs et planifier

2. Do = faire exécuter la tâche



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



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.



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é



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.
