Retour à l'accueil
accueil renseignements diffusion
Recherche
avancée
 Numéro 6, Février 1996 
Une gestion de projet efficace pour des logiciels de qualité Version Imprimable  Version imprimable
Le diagnostic

Jean-Guy Dubois  (CCDMD)

1. La route du futur

La production de logiciels éducatifs de qualité destinés au collégial et l'amélioration de ce processus de production restent les enjeux essentiels de la nouvelle équipe de la Section de l'informatique du CCDMD. Sans nier les acquis de ses prédécesseurs, qui sans conteste ont fait preuve de compétence et de professionnalisme, il est normal que cette équipe, par son dynamisme et sa volonté de changement, réfléchisse aux problèmes inhérents à sa gestion de projet.

Les capacités de l'ordinateur personnel ont connu depuis la fin des années 70 une croissance exponentielle. Cette évolution suit la loi de Moore : un dédoublement des performances et des capacités à environ tous les deux ans. Selon Bill Gates 1 , cette loi s'appliquera encore pendant au moins vingt ans. Que de progrès en perspective! Même si le développement du logiciel connaît un temps de retard sur l'évolution du matériel informatique, sa croissance va de pair. L'entrée en scène du multimédia n'est qu'un début. Que nous réservent les inforoutes? Si nous voulons survivre, la diversification et la qualité de nos produits doivent forcément suivre cette progression fulgurante.

 

Comment y arriver? Par l'élimination du bricolage et le passage à des méthodes industrielles de production. Ce virage inévitable sera d'autant plus difficile qu'il s'accompagne de deux contraintes : des délais et des coûts de production réduits. Nous devons faire face à la concurrence internationale, à l'évolution accélérée des applications informatiques et à des restrictions budgétaires significatives.

 

Ces contraintes n'entrent-elles pas en conflit avec la production de logiciels de qualité? De prime abord, il semblerait bien que oui. Des compromis judicieux s'appliqueront sans doute, mais en améliorant nos méthodes de développement, nous espérons également réduire nos délais et nos coûts de production. D'autre part, en parallèle, d'autres solutions sont aussi envisagées. Les récentes ententes de distribution et de coproduction du CCDMD, respectivement avec CRAPO et Le Groupe Micro-Intel, vont dans ce sens. De plus, nous entendons bien utiliser à bon escient cette vitrine sur le monde que nous offre Internet. Du fait même, notre public et notre mission s'élargissent. Voilà des raisons supplémentaires pour produire du logiciel de qualité!


2. Nature des problèmes

Depuis que le programme d'aide au développement de matériel didactique existe, un certain nombre de projets informatiques ont connu, et quelques-uns connaissent encore, des problèmes sérieux de développement, même si pour ces derniers ils sont en bonne voie de résolution. Heureusement, d'autres, et c'est la majorité, ont suivi un développement normal. Essayons de comprendre les causes d'échec partiel des premiers et de succès des autres, afin d'en tirer les leçons qui s'imposent pour un renouvellement de nos méthodes de conduite de projet.

 

Face à la réalité, lorsque quelque chose ne va pas, diverses questions se posent. J'essaierai de répondre à deux de celles-ci, qui sont fondamentales :

 

1. De quoi s'agit-il?

 

2. Que peut-on faire?

 

En répondant à la première, on pose un diagnostic (c'est le but du présent article); à la deuxième, on propose des remèdes ou un traitement.

 

Comme c'est en médecine que le diagnostic fut le plus approfondi, je le prendrai comme modèle méthodologique. Ce diagnostic a pour premier objectif l'identification des signes de la maladie, soit la désignation des symptômes. Son deuxième objectif est la détermination des causes de la maladie. Celle-ci se traduit généralement par un ensemble de symptômes, les uns subjectifs, les autres objectifs. Lorsque cet ensemble relève de causes diverses, il porte le nom de syndrome. Les maux dont souffre le développement logiciel forment en général des syndromes.

 

Il m'est facile de poser un diagnostic d'identification, car les événements indicatifs de la faillite relative des projets informatiques sont communs à la plupart de ceux-ci. D'autre part, les histoires d'horreur décrites dans les nombreux livres sur le génie logiciel ne font essentiellement qu'exploiter ces événements. De plus, ils sont fréquents, pour ne pas dire quotidiens, dans les entreprises vouées au développement logiciel. En voici la liste, en ordre de sévérité décroissante :

 

1. Annulation du projet;

 

2. Prolongation significative des délais;

 

3. Dépassement important du budget;

 

4. Faible qualité des produits livrés;

 

5. Démotivation des intervenants;

 

6. Volatilité des responsables.

 

En général, ces événements ne sont pas indépendants les uns des autres et se présentent à des degrés divers. Par exemple, la prolongation des échéances est souvent responsable du dépassement des coûts et de la perte de motivation des intervenants; ce qui, dans certains cas, entraîne même l'annulation du projet. D'autre part, certains projets peuvent dépasser substantiellement les délais et les coûts prévus et sont quand même considérés comme réussis. Cependant, plus le temps de conception et de réalisation d'un logiciel est long, plus il est sujet aux incidents désastreux : désuétude due à l'évolution technologique, désengagement du programmeur ou départ du chargé de projet responsable, faillite de l'entreprise chargée de sa réalisation, parution d'un logiciel équivalent de meilleure qualité, etc. Le temps de développement d'un projet informatique est sans doute la composante la plus critique de sa gestion, celle sur laquelle doit porter la plus grande part des efforts de planification.

 

L'identification des symptômes reste un exercice inutile tant qu'on n'a pas déterminé les causes des problèmes qu'ils manifestent. Elles sont plus difficiles à établir, car elles sont variées, moins apparentes et souvent spécifiques à un projet. Bref, un tel diagnostic causal exige une analyse en profondeur. Risquons-nous à avancer quelques-unes de ses composantes, parmi les plus déterminantes.

 

3. Description des causes


3.1. Lacunes du devis pédagogique

Notre Section appelle devis pédagogique ce que les ingénieurs désignent généralement par cahier des charges; celui-ci est produit par le ou les auteurs du projet. Il définit principalement les fonctions pédagogiques et informatiques du logiciel à réaliser, c'est-à-dire le QUOI de l'application à produire.

 

Il ne suffit pas d'avoir mis le doigt sur un besoin pédagogique réel et important, qu'un logiciel éducatif original pourrait combler adéquatement, pour que l'on puisse passer immédiatement à sa réalisation informatique. Il faut d'abord que le ou les auteurs présentent une description rigoureuse, la plus complète possible, des éléments qui le composent : c'est la spécification du logiciel. Cette description est essentielle à la réalisation de celui-ci, de sa conception informatique à sa validation, en passant par sa programmation : la qualité des phases de développement qui s'ensuivent dépend généralement de la qualité du devis. Comme toute oeuvre de création, concevoir correctement un didacticiel original est une tâche difficile, qui demande un esprit pédagogique inventif, de la profondeur et de la rigueur. On y arrive rarement du premier coup.

Les principaux défauts de la spécification sont bien connus 2 , et on les rencontre généralement dans les devis pédagogiques qui nous sont présentés. Ce sont les sept péchés capitaux de la spécification :

 

1. Inconsistance des spécifications par la présence de contradictions ou d'incohérences entre deux documents ou des parties d'un même document;

 

2. Présence d'ambiguïtés par la présentation d'informations donnant lieu à des interprétations multiples;

 

3. Existence de silences par l'omission d'éléments importants ou de parties de ceux-ci;

 

4. Présence de bruits par l'introduction d'éléments superflus ou de redondances par la répétition d'éléments semblables dans différentes parties d'un document;

 

5. Énoncé de lieux communs ou de voeux pieux par l'utilisation de concepts trop généraux ou trop vagues, qui ne peuvent être validés;

 

6. Présence de surdétails par des descriptions à un niveau de détail trop fin (appartenant à la conception informatique interne alors qu'il s'agit de spécification des fonctionnalités, par exemple) par rapport au niveau du document concerné;

 

7. Référence à des items qui n'ont pas encore été définis ou discutés, et cela possiblement à plus d'un niveau.


3.2. Mise en oeuvre de ressources inadéquates

Je me restreindrai aux ressources humaines affectées au codage : ce sont celles qui affectent le plus nos délais et nos coûts de production. Plusieurs de nos développeurs furent, et certains restent encore, des enseignants du collégial : c'est souvent l'auteur ou l'un des auteurs du projet ou un collègue de travail qui effectue la programmation. Certains autres sont des programmeurs à la pige, travaillant généralement sous le couvert de leur propre entreprise, qui n'ont souvent qu'une formation informatique de niveau collégial ou qui ont appris la programmation sur le tas.

 

Du temps des Apple II et des 8088, le choix de ces programmeurs a sans doute permis des économies substantielles et facilité la communication entre les intervenants et même, dans la majorité des cas, donné de bons résultats; mais l'expérience nous apprend de plus en plus que c'est de moins en moins le cas. Ce n'est pas tant la compétence de cette catégorie de programmeurs qui est en cause, que le fait qu'en général ils ne consacrent à la programmation de nos logiciels qu'une partie accessoire de leur temps de travail. Nos applications ayant pris de l'ampleur, en volume et en complexité, même si nous disposons maintenant d'environnements de développement beaucoup plus puissants, nos délais de production s'allongent ainsi indûment, tout en exposant le développement à des risques difficilement contrôlables.

 

D'autre part, nos développeurs se plaignent souvent d'être sous-payés, donnant généralement comme raison une sous-estimation des coûts. Le fait qu'ils aient signé une entente n'arrange pas nécessairement le problème. La qualité du logiciel en souffre presque toujours. La tendance est alors d'arrondir les coins : certaines fonctionnalités sont escamotées, l'interface usager laisse à désirer, la fonction d'aide est absente, la phase des tests est abrégée ou disparaît purement et simplement, etc. Résultat : on obtient un logiciel qui manque de fini ou qui n'est pas terminé; il reste quelquesfois dans cet état pour toujours. De tels incidents sont sources de tension et de conflit, qui engendrent des retards et de l'insatisfaction de part et d'autre.

 

3.3. Analyse informatique escamotée

 

À mes débuts au CCDMD, j'ai vécu pendant quelque temps une ambiguïté qui m'apparaît aujourd'hui instructive : lorsqu'on me parlait du devis informatique d'un projet, je croyais qu'il s'agissait d'un document détaillant sa conception informatique, alors qu'on parlait de la section sur les modalités de paiement, de la lettre d'entente entre le collège producteur et le programmeur. Cette section, d'une page en général, énumère les principales étapes de la réalisation informatique du logiciel, avec les échéances et les montants respectifs à payer pour la réalisation de chacune d'elles.

C'est trop peu pour un véritable devis informatique, du moins au sens où on l'entend en génie logiciel. Un tel document, qui décrit le COMMENT de la réalisation informatique des spécifications fonctionnelles du cahier des charges, est généralement produit par un analyste-programmeur et comprend la conception détaillée du logiciel. À quelques exceptions près, de tels devis informatiques, il n'en existe tout simplement pas! Pourtant, le Guide de développement de logiciels éducatifs 3 , longtemps utilisé dans notre Section comme une référence de base, contient bien un chapitre sur l'analyse informatique (chapitre V). L'analyse informatique... le programmeur l'aurait-il mangée?

 

Pas complètement, car on retrouve dans la plupart des devis pédagogiques une conception préliminaire des pages-écrans. On peut la considérer comme une composante de l'analyse informatique. Le guide de développement de la DGEC mettait avec raison l'accent sur le design de ces pages-écrans, mais, hélas, la conception informatique d'un logiciel ne se limite pas au design de son interface usager.


3.4. Insuffisance du contrôle qualité

Le contrôle de la qualité d'un logiciel apparaît comme une activité nécessaire face à des utilisateurs de plus en plus exigeants. Mais qu'est-ce qu'un logiciel de qualité? Quels sont les facteurs qui font qu'un logiciel est dit de qualité? Les vues sont divergentes selon que l'on est administrateur, réalisateur ou utilisateur. Le premier insiste sur l'adaptabilité, la portabilité et la maintenabilité : les profits et les coûts en dépendent. Pour le deuxième, c'est la modularité, la performance et la fiabilité : les aspects techniques sont mis en avant-scène. Tandis que pour le troisième, c'est la facilité d'apprentissage, la banalité d'emploi, la tolérance aux erreurs : le confort est sa principale préoccupation.

Existe-t-il une définition qui permet de transcender des approches aussi diverses de la qualité du logiciel? J'utiliserai celle qui est la plus couramment admise 4 : La qualité d'un logiciel est son aptitude à satisfaire les besoins des utilisateurs.. Elle est suffisamment générale pour concilier divers points de vue. Pour nous qui sommes intéressés au logiciel éducatif au collégial, les besoins des utilisateurs sont avant tout ceux des enseignants et des élèves des collèges : les besoins ne sont pas uniquement informatiques, mais avant tout pédagogiques. Les qualités informatiques, médiatiques, ergonomiques et didactiques d'un logiciel doivent être mises au service de l'apprentissage.

 

Nous réussissons en général à livrer des logiciels qui remplissent les fonctions demandées par l'auteur pédagogique, même s'il arrive que ce soit à la baisse. Mais ces fonctions répondent-elles aux véritables besoins des utilisateurs? Ils sont aussi sans bogues apparents, mais trop souvent au prix d'un va-et-vient maintes fois répété entre l'auteur et le programmeur : ce qui prolonge indûment les délais de parution. Pour les tests, nous faisons confiance au programmeur... À tort vraisemblablement : l'application de ceux-ci n'étant pas planifiée et contrôlée, cette phase n'est jamais réalisée systématiquement, et elle est même souvent escamotée. Quant à l'interface usager, elle est dépassée pour plusieurs de nos logiciels, tout particulièrement pour ceux tournant sur la plate-forme IBM : ils ont mal au DOS. L'utilisabilité de ces logiciels en souffre d'autant, surtout s'ils sont en mode texte.

 

D'autre part, notre contrôle qualité se limite à l'identification de défauts externes en fonction de standards et de critères mal définis. Or la plupart des erreurs débouchant sur un produit de mauvaise qualité proviennent des phases en amont de celles de codage et de validation. Il en coûte cher d'éteindre les feux; il vaudrait mieux les prévenir. C'est donc à toutes les phases du cycle de développement qu'il faudrait appliquer des méthodes appropriées de planification et de contrôle de la qualité.

 

3.5. Cauchemar de la documentation

 

J'emprunte ce titre au Guide de développement de logiciels éducatifs de la DGEC (Tome II, Figure 6.1.1), dont le deuxième tome est entièrement consacré à la documentation. Cet ouvrage mentionne quatre guides (guide du professeur, de l'étudiant, de mise en route et de l'analyste-programmeur) et une fiche descriptive. On y prône une stratégie anti-cauchemar, qui n'est probablement pas passée dans les faits, car dans bien des cas la documentation reste encore pour nous une difficulté majeure.

 

Va pour les guides produits par l'auteur pédagogique : ils sont généralement de bonne qualité. Le principal problème que nous ayons : ces guides tardent souvent à venir. Quant au Guide de l'analyste-programmeur, il est aussi rare que l'analyse informatique elle-même. En l'absence d'un tel guide, on s'attendrait à ce que le programmeur nous remette un code source bien documenté, d'autant plus qu'il s'engageait dans l'entente de production à en remettre un qui le soit. Oh surprise! Lorsqu'on regarde de près ces codes sources, on s'aperçoit tout de suite qu'ils sont peu documentés, et encore, dans les rares cas où ils le sont.

 

Le problème de la documentation reste pour notre Section, comme pour tout service de développement de logiciels, un problème global qui dépasse la réparation des défauts locaux mentionnés plus haut. La documentation fait partie intégrante de tout le cycle de développement et de maintenance du logiciel. Comme il est un produit abstrait, surtout avant sa réalisation, il n'existe que par les divers documents reflétant les états qu'il traverse lors de son cycle de vie.

 

C'est d'abord le principal moyen fiable de communication entre les intervenants. Plusieurs acteurs participent à la conception, à la réalisation et à l'exploitation d'un logiciel : l'auteur pédagogique, le concepteur et le réalisateur informatique, l'évaluateur, les responsables, les utilisateurs, l'installateur, le diffuseur, le proposé au service à la clientèle, etc. Face à l'utilisation d'une documentation, les motivations sont diverses, voire divergentes.

 

La documentation remplit des fonctions variées : de mémoire, d'historique, d'assistance, d'information, de gestion, de formalisation, de formation, etc. L'une de ces fonctions, et elle est fondamentale pour un service comme le nôtre, est l'assurance qualité. Cette assurance-là est assez spéciale. On ne peut en espérer aucun remboursement sur nos pertes, mais elle peut nous prémunir d'en subir.

 

L'assurance qualité, bien connue dans l'industrie, comprend un ensemble d'activités préétablies et systématiques nécessaires pour qu'un service ou produit satisfasse aux exigences reconnues de qualité dans le domaine considéré. Pour l'élaboration du logiciel, le référentiel d'une telle assurance est un Manuel Qualité Logiciel, sorte de plan type des activités à mettre en oeuvre pour atteindre la qualité voulue du produit.

Le guide de développement de la DGEC jouait en partie ce rôle pour ce qu'on appelait alors le devis de production, ainsi que pour la documentation afférente au logiciel. Mais ce document de référence essentiel, faute de maintenance, est aujourd'hui désuet, même si on peut encore en cueillir de la graine. Il en est de même du bel ouvrage de Bernard Mataigne 5 sur les interfaces utilisateurs : ses illustrations ont vieilli autant que nos logiciels, quoique les principes généraux énoncés restent toujours valables. Concernant l'assurance qualité, nous avons quelque peu régressé; il y a là un manque qu'il presse de combler.


3.6. Empirisme de la gestion de projet

 

La gestion de projet est notre pain quotidien. Afin d'accroître notre efficacité, il est naturel que nous nous interrogions, individuellement et collectivement, sur nos méthodes de conduite de projet. Le renouvellement de notre équipe fut l'occasion favorable à une telle réflexion.

 

Nous devions d'abord nous accorder sur les composantes d'un projet; c'était un préalable. Ce n'était pas si simple... Dans le passé, n'avait-on pas eu tendance à négliger des phases aussi fondamentales du cycle de développement que celles de l'analyse informatique et des tests, comme je le soulignais aux sections 3.3 et 3.4 ? Les difficultés proviennent d'une réflexion insuffisante sur le Quoi faire? et Avec qui?, mais surtout d'un accord plus difficile sur le Comment faire?.

 

Les réponses aux deux premières interrogations définissent un cadre de référence, un modèle à suivre en quelque sorte. Les méthodes, techniques et outils à utiliser apportent une réponse à la dernière, sur la façon de réaliser les objectifs préconisés par ce modèle. En pratique, la diversité et l'hétérogénéité des projets à réaliser nous amènent à adapter et à diversifier notre méthodologie. Il ne faudrait pas, cependant, que ce soit là une voie d'échappement favorisant le retour à l'empirisme facile, et si répandu, de la conduite de projet.

 

Pour un chargé de projet, à quoi sert un bon découpage du développement d'un logiciel en phases, puis en activités et finalement en tâches? Tout simplement à l'amélioration du processus d'estimation, de planification et de suivi. Un découpage précis du chemin à parcourir permet une bonne identification et une meilleure optimisation des ressources, des délais, des charges et des coûts. Pour maîtriser la complexité des activités d'un projet, rien de mieux que d'appliquer ce bon vieux principe cartésien : lorsqu'un problème s'avère complexe, sa décomposition en unités plus simples permet une meilleure approche de sa résolution.

 

4. Et la suite?

 

Le développement d'un projet logiciel constitue une aventure captivante pour les personnes qui y sont impliquées. Elle s'annonce merveilleuse dans les premières étapes, puis trop souvent elle s'assombrit au fur et à mesure que les obstacles surgissent. Les parties en présence, malgré leur bonne volonté, finissent par s'engager dans un attentisme qui engendre diverses frustrations démotivant les principaux acteurs. Après l'accalmie, on en tire peu de leçons, si ce n'est celle qu'il faudra, la prochaine fois, éviter la répétition des mêmes erreurs.

 

J'espère dépasser ce simple constat. J'ai osé avancer un diagnostic; j'essaierai, dans deux prochains articles, de proposer un modèle de développement ainsi que des remèdes.

 


Notes

  1. Gates, B. : La route du futur, Éditions Robert Laffont, Paris, 1995. Retour au texte.

  2. Meyer, B. : On Formalism in Specification. IEEE Software 2, no 1, 1985, p. 6-26. Retour au texte.

  3. Section du matériel didactique informatisé : Guide de développement de logiciels éducatifs, DGEC, MESS, Gouvernement du Québec, 1988. Retour au texte.

  4. Martin, J. P. : La qualité des logiciels, Association française de normalisation, Paris, 1987. Retour au texte.

  5. Mataigne, B. : Le design de l'interface utilisateur, DGEC, MESS, Gouvernement du Québec, 1991. Retour au texte.

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