K2 BPM SSII ACCOMPAGNEMENT

Indicateurs de qualité

Le chiffrage est primordial pour un projet si il est mal effectué, il risque d’être sous chiffré et donc d’obtenir un dépassement de budget/délai.

Le planning doit également être rigoureux et suivi car il permet de répartir la charge du projet entre les différents acteurs (Chef de projet, Consultant Fonctionnel, Consultant Technique, Analyste développeur, testeurs …). Cette répartition doit permettre de ne pas surcharger l’équipe et donc d’être face à un goulot d’étrangement.

Les livrables sont le résultat attendu par le client, ils sont important en terme de délais, le non respect de ces délais engendre un ensemble de problèmes (arrêt des chaines de production, cout plus ou moins important, remise en question de la confiance entre le prestataire et le client…). Ils doivent être suivi, testé, stressé (dans le cas d’application web), ceux ci afin de garantir une certaine qualité.

Normes

Nous retrouverons l’utilisation de plusieurs normes françaises ou européennes qui permettront d’atteindre les objectifs. Ces normes peuvent nous aider à garder le capte mais ils ne sont pas le garant d’une réussite car c’est vous qui piloté.

  • IEEE 830 : Norme sur la rédaction du cahier des charges.
  • FDX50-171 Juin 2000 : Système de management de la qualité – Indicateurs et tableaux de bord
  • FDX50-680 Juillet 1998 : Management par la qualité et la mercatique totales – Outil d’aide au management
  • FDX50-129 Mai 2003 : Management de la qualité et assurance de la qualité – Guide pour l’utilisation des méthodes statistiques dans le management de la qualité

Ne réinventons pas la roue

 

Les indicateurs de qualité

Introduction

Rappelons ce que veut dire « assurer » en termes de qualité. C’est :

  • Dire ce qu’on fait
  • Faire ce qu’on dit
  • Le vérifier

Comment vérifier ?

  • Par la mise en place d’indicateurs, de tableaux de bord pertinents par rapport aux objectifs.
  • Par la mise en place de tests.

Attention : La qualité ne doit pas produire de cout inadéquat (sur-qualité).

 

L’un des principes de base de la qualité est la prévention et l’amélioration permanente. Cela signifie que la qualité est un projet sans fin dont le but est de prendre en compte les dysfonctionnements le plus en amont possible.

Ainsi la qualité peut être représentée par un cycle d’actions correctives et préventives, appelé «roue de Deming». Cette représentation de la qualité n’est pas la seul, mais elle permet une mise en place rapide et il est rapide de la comprendre.

Déroulement

La roue de Deming est une illustration de la méthode de gestion de la qualité PDCA (Plan-Do-Check-Act).

La méthode comporte quatre étapes, chacune entraine l’autre, et vise à établir un cercle vertueux. Sa mise en place doit permettre d’améliorer sans cesse la qualité d’un produit, d’une œuvre, d’un service…

  • Plan : Préparer, Planifier (ce que l’on va réaliser)
  • Do : Développer, réaliser, mettre en œuvre
  • Check : Contrôler, vérifier
  • Act (ou Adjust): Agir, ajuster, réagir (si on a testé à l’étape « Do », on déploie lors de la phase « Act »)

 

La première étape « Plan »

Objectif : poser le vrai problème, trouver les causes racines et choisir les solutions optimums.

Elle consiste à planifier la réalisation. Elle se déroule généralement en trois étapes :

  • Identification du problème « QQOQCCP ».
  • Recherche des causes racines « diagramme d’Ishikawa ».
  • Recherche de solutions avec écriture du cahier des charges et établissement d’un planning.
QQOQCCP

On remarque que le questionnement d’un problème rencontré nécessite de répondre toujours aux mêmes questions et en particulier :

  • Que fait-on ?
  • Avec quoi le fait-on ?
  • Qui ? Qui le fait ? Et pourquoi cette personne ?
  • Où le fait-on ?
  • Quand le fait-on ?
  • Avec quelle quantité ?
  • Combien ça coute ?
  • Comment le fait-on ?
  • Pourquoi ? Pourquoi y a-t-il ce problème ? Et pourquoi le fait-on ? Et pourquoi là…

Liste mnémotechnique :

Lettre Question Exemples
Q De qui, Avec qui… Responsable, acteur, sujet…
Q Quoi, Avec quoi… Outil, objet, résultat…
O Lieu, service…
Q Quand, tous les quand… Date, périodicité, durée…
C Comment, par quel procédé… Procédure, technique, action…
C Combien Quantités, budget…
P Pourquoi Justification, raison d’être

Un moyen mnémotechnique pour se rappeler cette suite de lettres consiste à changer l’ordre de lettres en CQQCOQP (« c’est cucul, c’est occupé »).

Diagramme d’Ishikawa

Diagramme de causes et effets, diagramme d’Ishikawa ou diagramme en arêtes de poisson est le résultat des travaux de Kaoru Ishikawa pour la gestion de la qualité.

Cet outil graphique issu d’un brainstorming, recense les causes aboutissant à un effet. Son analyse permet une aide à la décision pour soit corriger un fait existant, soit la mise en place d’un projet.

Les causes sont réparties dans les cinq catégories appelées 5M :

  1. Matière : Les matières premières, et plus généralement les inputs du processus.
  2. Matériel : Concerne l’équipement, les machines, le matériel informatique, les logiciels, et les technologies.
  3. Méthode : Le mode opératoire et la recherche et développement.
  4. Main d’œuvre : tout ce qui concerne les ressources humaines.
  5. Milieu : l’environnement, le positionnement, le contexte.

Chaque branche reçoit d’autres causes ou catégories hiérarchisées selon leur niveau d’importance ou de détail.

Le classement doit aussi mettre en évidence les causes les plus directes.

Écriture du cahier des charges

Le cahier des charges est important dans la gestion de la qualité d’un projet mais il n’est pas toujours évidant pour un client. Il incombe à l’équipe projet (prestataire) d’accompagner, de conseiller le client sur cette necessité.

Plusieurs normes permettent la rédaction d’un cahier des charges, la norme IEEE 830 permet de le rédiger sur la base d’un ensemble de UC (Use Case) mais il doit alors être accompagné de spécifications fonctionnelles détaillées.

Établissement d’un planning.

La planification est la mise en œuvre d’objectifs dans le temps en tenant compte de critères (Urgence, priorité, dépendance…)

Le planning a pour caractéristique principale l’axe « temps ». L’optimiser d’éléments et de ressource sans utiliser les notions « temps/durée » est également possible mais dans ce cas nous ne pouvons parler de planning. La notion de planning est indissociable de la notion de temps.

Souvent ébauchée par une todo list, elle se concrétise ensuite par un plan répondant de façon détaillée et concrète aux principaux aspects opérationnels du type QQOQCCP : qui, quoi, où, quand, comment, combien.

Parmi les outils de planification, on trouve l’analyse (par exemple méthodes QQOQCCP, SWOT…), la prévision, le budget, les scénarios (entre lesquels choisir), les probabilités, les solutions alternatives ou de repli (pour être préparé en cas d’obstacle lors de l’exécution du plan) etc.

Etablissement du plan de tests

Un projet de plan de test est un document qui décrit les objectifs, la portée, l’approche et est orienté sur l’effort nécessaire pour tester un programme. Le processus de préparation d’un plan de test est une méthode pratique pour définir les efforts qui seront nécessaire pour valider l’assurance qualité d’un produit. Le document complété peut aussi aider les personnes extérieures à l’équipe de test à comprendre « pourquoi » et « comment » le produit sera validé.

Un plan de test défini quelles seront les fonctions qui seront testées et à quel niveau, dans quel ordre elles seront testés et quelle sera la stratégie de test de chaque fonction et l’environnement de test utilisé.

L’objectif de chaque plan de test est de définir un schéma de vérification, et par les tests, s’assurer que le produit satisfera à toutes les normes de qualité en vigueur. Dans le cas de test de validation, il s’agit souvent de tester que les fonctionnalités se comportent comme prévu par le cahier des charges initial et produisent les résultats escomptés.

La première considération à prendre en compte dans un plan de tests est le public cible. Un plan de test sera différent s’il est conçu pour coordonner l’équipe de tests, ou si vous voulez informer votre client de la méthode de validation utilisée. Dans le cas d’un document externe, n’hésitez pas à le faire de haut niveau, en évitant les points de détail qui n’intéresseront pas votre client et détaillez plutôt les délais nécessaires.

Commencez votre plan de test le plus tôt possible ! Généralement il est préférable de le commencer en même temps que les analyses préliminaires du produit, et de le compléter au fur et à mesure. Le plan de test peut (et doit) avoir un impact sur le projet. C’est pour cette raison qu’un plan de test fait aux premiers moments peut aider à fixer un planning plus précis pour le projet en entier.

La deuxième étape « Do »

Objectif : Construire, développer et réaliser les actions décrites dans la première partie.

Le cahier des charges définit des besoins, souvent les besoins du client, et est complété dans le planning par les besoins de l’équipe :

  • Matériel
  • Ressource
  • Budget

Les actions sont construites de manière à pouvoir réaliser le projet (Nouveau projet, maintenance applicative, correction…). Afin de permettre le développement de ce projet il conveint de mettre en place les actions et de définir les éléments devant être mis en place.

Construire doit permettre à l’Architect ou au consultant technique de mettre en place la ou les solutions en place pour avoir une solution optimisé pour la suite du projet.

Développer est un ensemble d’action qui sont partagé entre les acteurs du projet (développeur) sous le control régulier de l’Architect. Cette élément pourrai dans le cas de gros projet de plusieurs itération. Ces itérations devront mettre en œuvre une nouvelle version de la « roue de deming » ceci afin de garantir une rééquilibrage du projet. Il faut bien garder en tête qu’un projet n’est jamais prévisible dans sa globalité, il est en constante modification et il incombe au chef de projet de réétudier le planning et donc de mettre un nouveau plan d’action en place.

Réaliser est souvent confondu avec l’action de développer, mais ceci est faut la réalisation est l’ensemble des actions permettant de valider le développement, la documentation (installation, configuration, utilisation…). Cette action est le début de la phase suivant.

La troisième étape « Check »

Objectif : Vérifier que les actions mises en place sont efficaces et atteignent l’objectif défini.

L’erreur étant humaine, les bugs dans les logiciels ne peuvent être évités. Cependant, des périodes de tests peuvent permettre de chasser les défauts les plus évidents. Encore faut-il savoir qualifier et classer les bugs pour déterminer lesquels corriger en priorité.

Mesurer les résultats des solutions mises en place et les comparer à la situation initiale.

· Critique :

Ce type de bug peut avoir des conséquences désastreuses sur l’intégrité du système impacté.

Par exemple : perte de données critiques, crash du système, perte de sureté (diffusion de données confidentielles), perte de sécurité (erreurs dans le programme de guidage d’une fusée), etc …

  • Sévère :

Le bug de type sévère peut avoir de graves conséquences sur les fonctionnalités du système, et il n’existe pas de manipulation permettant d’éviter l’erreur (appelé communément work-around).

  • Majeur :

L’erreur peut avoir de graves conséquences mais il existe un work-around.

Par exemple : Perte de données lors de lourdes charges de travail ou fonctionnalité défaillante mais il existe un work-around.

  • Mineur :

L’erreur n’a que peut d’influence sur le système.

Par exemple : manque d’affichage d’un message d’information, la police de caractères utilisée n’est pas celle spécifiée par le client.

  • Trivial :

L’erreur n’a aucune influence sur le système.

Par exemple : une fonction n’est pas détaillée dans la documentation, une faute d’orthographe dans le titre d’une boîte de dialogue ou dans l’intitulé d’un menu.La quatrième étape « Act »

Objectif : Vérifier que les actions mises en place sont efficaces dans le temps.

Cette étape est constituée de trois phases

  • Formaliser les solutions et dans certains cas mettre en place des systèmes anti-erreur,
  • Généraliser les solutions si possible
  • Valoriser le groupe de travail et les personnes ayant mis en œuvre les actions

Essentiel pour les indicateurs « Qualité »

Si certain éléments sont important ou intéressant ils ne sont pas tous à mettre en place, du moins en même temps.

Dans cette section nous allons voir les indicateurs à mettre en place sur tous les projets.

Comments:0

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *