Retour à l'accueil
accueil renseignements diffusion
Recherche
avancée
 Numéro 10, Septembre 1996 
Une gestion de projet efficace pour des logiciels de qualité Version Imprimable  Version imprimable
Les remèdes (première partie)

Jean-Guy DUBOIS  (CCDMD)

 

Je vous présente aujourd'hui la première partie du dernier article, d'une série de trois, sur la gestion de projet logiciel. Le premier 1 établissait un diagnostic en dressant un tableau des principaux maux dont souffre notre gestion de projet, tout en spécifiant les causes les plus déterminantes de ceux-ci. Le deuxième article 2 (en deux parties) proposait un modèle de gestion de projet logiciel et posait ainsi les bases nécessaires à un traitement éclairé des lacunes de gestion que l'on retrouve en général dans les services de développement informatique. L'objectif de ce troisième article (en deux parties) est de préciser ce traitement par une série de prescriptions adaptées à notre situation particulière. Pour ce faire, je puiserai abondamment dans la vaste "pharmacie du génie logiciel".

 

1. L'ÉGLISE CATHOLIQUE OU PROTESTANTE ?

Tout comme il y a plusieurs médecines, dont l'africaine, l'orientale et l'occidentale, il existe aussi plusieurs écoles ou églises dans le domaine du génie logiciel. À l'article précédent, je mentionnais le Capability Maturity Model (CMM) du Software Engineering Institute (SEI) de l'université Carnegie-Mellon. Ce modèle vient d'être traduit en français 3 par le Centre de génie logiciel appliqué (CGLA) du Centre de recherche informatique de Montréal (CRIM). Je considère le SEI comme la sainte Église catholique de la gestion de projet informatique.

Y en aurait-il une qui soit protestante ? En fait, dans ce domaine, il existe plusieurs églises protestantes. La plus intéressante est sans doute le Software Productivity Research Inc. (SPR), qui est une compagnie de recherche, de consultation et de production d'outils de gestion informatique, située à Burlington, Massachusetts. Son président et cofondateur, M. Capers Jones, est un écrivain très prolifique dans le domaine. Je viens de mettre la main sur l'un de ses ouvrages, qui est en train de devenir mon livre de chevet 4 : tout comme pour le CMM, je m'en inspire abondamment dans le présent article.

Voyons d'abord comment la sainte Église SEI nous présente son modèle d'évolution des capacités logicielles.

Le postulat fondamental du CMM est que la qualité d'un logiciel est grandement tributaire de la maturité du processus appliqué pour le développer et en assurer la maintenance. Rappelons que ce modèle décrit cinq niveaux progressifs de maturité, que nous avons brièvement caractérisés dans l'article précédent : le niveau chaotique ou non structuré, le niveau reproductible ou orienté projet, le niveau défini ou orienté processus, le niveau maîtrisé ou intégré et le niveau optimisé ou pleinement intégré.

Qu'est-ce qui caractérise une organisation mature ? Selon le CMM, une telle organisation se caractérise par un processus de développement défini, documenté, mesuré, contrôlé et institutionnalisé, par des succès reproductibles et dépendants d'une méthode appliquée collectivement, par des coûts, des délais et une qualité prévisibles, par une gestion proactive et une utilisation judicieuse de la technologie.

La description de niveaux de maturité spécifiant la capacité du processus de développement logiciel d'une organisation n'est pas la seule composante du CMM. Chaque niveau de maturité contient des secteurs clés qui réalisent des objectifs explicites. Par exemple, le niveau 2 (reproductible) comprend six secteurs clés : la gestion des exigences, la planification de projet, le suivi et la supervision de projet, la gestion de la sous-traitance, l'assurance qualité et la gestion de la configuration logicielles.

Chaque secteur clé comprend des pratiques clés (316 pour les cinq niveaux de maturité) décrivant l'infrastructure et les activités à mettre en place pour l'atteinte des objectifs associés. Ces pratiques énoncent des directives, des procédures et des activités fondamentales du secteur clé. De plus, les pratiques clés de chaque secteur sont réparties selon cinq caractéristiques communes : l'engagement de réalisation, la capacité de réalisation, les activités réalisées, les mesures et l'analyse, et la vérification de mise en oeuvre. Ces caractéristiques communes sont des attributs indiquant si la mise en oeuvre et l'institutionnalisation du secteur clé considéré sont efficaces, reproductibles et durables.

Comment passer du niveau initial, où règne l'improvisation, au niveau suivant dit reproductible, où domine un processus de gestion structuré ? C'est en grande partie le sujet du présent article : les secteurs clés du niveau visé nous fournissent des prescriptions qu'il s'agit d'appliquer pour enfin quitter l'ère du bricolage qui nous est familier et accéder définitivement à une gestion de projet efficace rendant possible une production logicielle de qualité.

Soyons équitables en présentant aussi une brève description de ce que nous offre l'Église protestante du SPR.

Le livre cité de Jones nous fournit cette description. Il adopte une approche interdisciplinaire en appliquant au développement logiciel un format analogue à celui utilisé dans les écrits médicaux ; plus spécifiquement, à celui du Control of Communicable Deseases in Man, qui est publié annuellement par le U.S. Public Health Service.

Dans son livre, Jones nous présente, en ordre alphabétique, les 60 maladies ou risques connus du développement logiciel. Pour chacune de ces maladies, il suit une méthode de présentation similaire en 20 points : 1. Définition; 2. Sévérité; 3. Fréquence; 4. Occurrence; 5. Susceptibilité et résistance; 6. Causes fondamentales; 7. Problèmes associés; 8. Impact sur les coûts; 9. Méthodes de prévention; 10. Méthodes de contrôle; 11. Produits; 12. Consultants; 13. Support éducationnel; 14. Publications; 15. Périodiques; 16. Standards; 17. Associations professionnelles; 18. Efficacité des thérapies connues; 19. Coûts des thérapies connues; 20. Pronostic à long terme. C'est une mine de références, de statistiques, de méthodes, de techniques et d'outils présentés d'un point de vue critique et pratique.

 

2. UN PLAN TRIENNAL

-- Faites le voeu d'une production logicielle de qualité ! et le génie logiciel vous exaucera !

Hélas, il n'y a pas de génie aussi puissant, même dans le domaine du logiciel !

Ne croyez pas qu'il nous est possible de résoudre nos problèmes de développement logiciel en une seule année ! Dans ce domaine, une planification sérieuse se déploie sur trois ans et plus. D'autre part, il ne suffit pas d'établir formellement le plan qui nous sortira du bricolage pour que par magie nous devenions des maîtres d'oeuvre qualifiés : il nous faut surtout l'implanter et, de plus, le compléter.

Je propose avec audace, mais je l'espère avec réalisme, le plan triennal suivant en trois étapes (une par année) :

 

Étape 1 : Gérer les projets de façon professionnelle

Les études sérieuses sur le développement logiciel nous apprennent que les problèmes de gestion sont les plus fréquents et les plus importants parmi ceux qui affectent négativement celui-ci. Par conséquent, nous devrions consacrer la première année du programme d'amélioration de notre processus de développement logiciel à nous former aux techniques professionnelles les mieux éprouvées de la gestion de projet logiciel, afin de les appliquer judicieusement. En particulier, nous devrions nous familiariser aux techniques de l'estimation et de la planification de projet, des mesures de la productivité et de la qualité logicielle, ainsi qu'à celles des mesures de la satisfaction des utilisateurs.

 

Étape 2 : Mettre en place des méthodes de conception pédagogique appropriées

Notre mission première est de produire des logiciels éducatifs répondant adéquatement aux besoins didactiques et pédagogiques des élèves et des enseignants du niveau collégial québécois. Ce qui ne peut se faire sans une vision articulée, solide et profonde de ce qu'est un logiciel éducatif de qualité pédagogique élevée. Pour y arriver, nous devons d'abord nous approprier les meilleures méthodes actuelles de conception pédagogique du domaine des APO. Mais cela ne suffit pas ! Il nous faut de plus les expliciter avec clarté, de façon structurée et experte, afin que nous puissions, en collaboration avec nos auteurs, les déployer et les appliquer correctement et efficacement.

 

Étape 3 : Implanter un programme complet d'assurance qualité

Pour tuer un loup-garou, vous devez l'atteindre, dit-on, d'une balle d'argent en plein coeur. Dans le domaine du développement logiciel, les loups-garous rôdent, mais il n'existe pas de balle d'argent pour les tuer, même si les gourous sont nombreux à nous en proposer une. Le génie logiciel ne possède pas de remède miracle, mais un traitement en profondeur pour parer à la faible qualité des produits logiciels : c'est l'assurance qualité. Durant la troisième année de notre plan triennal, nous devrions nous centrer sur l'élaboration et la mise en place d'un programme complet d'assurance qualité, par une gestion de notre production ayant pour but l'amélioration de la valeur pédagogique, informatique et médiatique de nos logiciels.

 

3. LA PLANIFICATION DE PROJET

3.1 Un point d'appui à la planification

On attribue à Archimède cette parole : "Qu'on me donne un point d'appui, et je soulèverai la Terre." La planification est le premier levier à appliquer pour faire basculer nos projets logiciels du côté de la qualité. Mais ce levier, tout comme celui d'Archimède, a besoin d'un point d'appui. Il nous est fourni par l'estimation : il n'existe pas de planification sérieuse sans des méthodes d'estimation valables des charges. Ce n'est qu'en évaluant correctement les efforts à fournir pour réaliser un projet que l'on peut, par un calcul fiable des délais et des coûts, en planifier avec réalisme l'accomplissement.

La mise en oeuvre d'une méthode d'estimation requiert la présence d'un découpage en produits, activités et ressources. Ce n'est qu'à partir de la liste détaillée des productions à réaliser, documents et modules de programme que s'organise l'estimation de l'effort global à fournir pour la réalisation du travail envisagé. Mais pour déterminer autrement qu'au "pifomètre" la quantité de travail à réaliser, l'utilisation d'une unité d'oeuvre s'avère indispensable.

 

3.2 Une unité d'oeuvre pour estimer

Je viens de renouveler le tapis recouvrant les planchers de ma maison. Pour ce faire, j'ai fait appel à des spécialistes de la pose de tapis. Après avoir choisi le type de tapis qui s'harmonisait le mieux avec les rideaux, la couleur des murs et les meubles de ma maison, on me proposa une évaluation gratuite du coût des travaux. Je fus émerveillé par la simplicité et la précision de la méthode appliquée. Ayant en main la dimension totale du tapis à poser, tenant compte du coût au mètre carré du tapis choisi, du coût horaire de la main d'oeuvre et du fait particulier qu'il y avait six marches d'escalier à couvrir, en moins de dix minutes (et sans ordinateur !) on me présenta une facture détaillée des charges et des coûts, tout en m'indiquant le temps pris pour la réalisation des travaux.

Le secret de cette efficacité ? Les poseurs de tapis ont une unité d'oeuvre !

Donnez-moi une unité d'oeuvre fiable pour la production logicielle, et je saurai en estimer avec exactitude les charges, les délais et les coûts. Le génie logiciel (encore lui !) nous la donne gratuitement : il s'agit de la méthode des points fonctionnels.

Cette unité de mesure des projets logiciels, développée par A.J. Albrecht de chez IBM, consiste à comptabiliser les fonctionnalités externes perçues par l'utilisateur. Un poids est attribué à la complexité de chaque fonction. La somme ainsi obtenue est rapportée à des abaques donnant la charge en mois/homme. Cette méthode peut même s'appliquer lors de la phase de spécification : c'est l'un de ses grands avantages. Dans ce cas, la qualité de la méthode repose sur celle des spécifications : on demande qu'elles soient détaillées, complètes et précises.

 

3.3 Des objectifs précis et mesurables

Je vous raconte une histoire personnelle récente, mais tout à fait fictive. L'un de mes amis, dont je tairai le nom, vient d'être promu à un poste de direction d'une firme informatique bien connue, mais qui éprouve quelques difficultés financières. Il fut à peine installé dans ses nouvelles fonctions que le président-directeur général lui demanda de définir les objectifs qui permettront d'améliorer la production logicielle de la compagnie pour la prochaine année, tout en diminuant ses dépenses courantes. Une tâche difficile et risquée...

Après y avoir réfléchi quelques jours, il réussit à formuler cinq objectifs qui allaient, croyait-il, guérir les maux du développement logiciel de sa compagnie. Cependant, d'un naturel prudent, avant de les présenter à son p.-d.g., il se dit : "Pourquoi ne pas les montrer d'abord à mon vieil ami J.-G., qui vient tout juste d'écrire une série d'articles pour le Clic sur la gestion de projet logiciel ?".

C'est ainsi qu'il se présenta à mon bureau du 6220, Sherbrooke Est, juste avant mon départ pour les vacances d'été. Il me remit une feuille en me disant : "Regarde J.-G. les objectifs qui nous permettront, l'an prochain, de remettre sur les rails notre compagnie. Qu'en penses-tu ?"

J'y jette un oeil, pour y lire :

Objectif 1. Multiplier par deux le nombre de logiciels produits par année.
Objectif 2. Réduire à 12 mois le temps de développement d'un logiciel.
Objectif 3. Diminuer de 50% le coût de développement d'un logiciel.
Objectif 4. Augmenter de beaucoup la qualité des logiciels produits.
Objectif 5. Automatiser davantage nos méthodes de gestion.

-- Paul, lui dis-je, tu me mets dans l'embarras !
-- Comment ?
-- Ces objectifs ne veulent rien dire !
-- Hein ! T'es sérieux ou c'est une farce ?
-- Prends le temps de t'asseoir, Paul, je suis très sérieux !

En effet, de tels objectifs sont si ambigus qu'il n'y a aucune façon de les interpréter correctement, encore moins de les atteindre. D'abord, ils sont basés sur un multiple plus ou moins vague d'une valeur initiale implicite qui n'est pas connue. De plus, malgré les apparences, leur formulation reste qualitative, générale et abstraite. Finalement, il n'existe aucun moyen permettant un contrôle efficace de leur réalisation. De tels objectifs, écrits pour éblouir la galerie, resteront à coup sûr lettre morte.

Alors, comment faire ?

D'abord, savoir d'où l'on part.

Afin qu'il soit possible de définir des objectifs précis et concrets d'amélioration, il faut préalablement adopter une unité d'oeuvre assurant une mesure précise et efficace de la productivité et de la qualité logicielle. L'utilisation de la méthode des points fonctionnels, par exemple, permet d'établir un programme de mesures fiables de l'état actuel de la productivité et de sa qualité. Partant d'une connaissance précise de celui-ci, il est alors possible de définir correctement des objectifs spécifiques qui dépassent cet état et qui soient réalisables, contrôlables et vérifiables.

Ensuite, savoir où placer la cible à atteindre.

Pourquoi ne pas prendre comme modèle de performance les gagnants du Baldrige Award ? Ce prix est décerné annuellement par le U.S. Department of Commerce, en l'honneur de l'économiste Malcolm Baldrige, à une firme reconnue pour le niveau de qualité élevé de sa production logicielle. Merci M. Jones pour toutes ces informations !

Lorsque Paul me quitta à 18 h 05, ce bel après-midi du 28 juin 1996, il avait en main cinq pages bien remplies d'objectifs qui allaient donner à sa firme du fil à retordre pour au moins trois ans. Avant de le quitter, je pris une photocopie de celles-ci : ce travail pourrait aussi servir à notre section de l'informatique !

Les objectifs élaborés avec Paul sont répartis en cinq catégories (j'indique aussi quelques sous-catégories) : 1. Objectifs de productivité (1.1 Pour les nouveaux projets, 1.2 Pour les nouvelles versions, 1.3 Pour les transports sur une nouvelle plate-forme) ; 2. Objectifs de temps de développement et de mise en marché ; 3. Objectifs de réduction des coûts ; 4. Objectifs de qualité (4.1 Qualité logicielle, 4.2 Qualité de la maintenance, 4.3 Satisfaction des usagers) ; 5. Objectifs d'utilisation des technologies de gestion de projet.

Voulez-vous plus de détails ? Nous n'avons qu'à lire les objectifs formulés avec Paul. Par exemple, ceux sur la qualité logicielle commencent comme suit :

4.1.1 Arriver à un nombre de défauts potentiels inférieur à 1 par point de fonction (les défauts sont totalisés sur les phases de spécification, de conception et de codage, sur la documentation et sur les corrections) ;

4.1.2 Atteindre une moyenne cumulative de correction des défauts supérieure à 95% (le nombre de tous les défauts trouvés durant le développement est comparé à celui de la première année d'application) ;

4.1.3 Parvenir en moyenne à moins de 0,025 bogues signalés par les utilisateurs par point de fonction par année ;

Etc.

Si le sujet vous intéresse et que vous voulez en savoir plus, venez me rencontrer au CCDMD, ou mieux, contactez Paul...

 


Notes

  1. Dubois, J.-G. : "Une gestion de projet efficace pour des logiciel de qualité. Le diagnostic", Clic, no 6, 1996. Retour au texte

  2. Dubois, J.-G. : "Une gestion de projet efficace pour des logiciel de qualité. Le modèle", Clic, no 7 et 8, 1996. Retour au texte

  3. Paulk, M.C. et al : Modèle d'évolution des capacités logicielleset Pratique du CMM, version 1.1, CGLA, CRIM, Montréal, 1996. Retour au texte

  4. Jones, C. : Assessment and Control of Software Risks, Yourdon Press, Prentice Hall Building, Englewood Cliffs, 1994. Retour au texte

Creative Commons License Cette création est mise à disposition sous un contrat Creative Commons. Dernières mises à jour : 10/04/2015