Retour à l'accueil
accueil renseignements diffusion
Recherche
avancée
 Numéro 12, Novembre 1996 
Une gestion de projet efficace pour des logiciels de qualité Version Imprimable  Version imprimable
Les remèdes (troisième et dernière partie)

Jean-Guy DUBOIS  (CCDMD)

 

5. L'ASSURANCE QUALITÉ

5.1 Le bernard-l'ermite

Ce crustacé des côtes d'Europe occidentale protège son abdomen mou en habitant la coquille vide d'un gastéropode. Cette coquille est sa seule protection contre les prédateurs ! Il y a cependant un problème : lorsqu'il grandit et que celle-ci devient trop étroite, il l'abandonne et en recherche une autre où il sera à son aise. Cette période critique de recherche le rend très vulnérable. Elle lui est quelquefois fatale !

La nouvelle équipe de la Section de l'informatique du CCDMD, déjà vieille d'un an, se sent très "bernard-l'ermite". Nous ne sommes plus à l'aise dans notre coquille d'antan, d'une époque héroïque mais révolue.

Nous savons que nous sommes montés dans une barque qui prend l'eau et qui donne dangereusement de la gîte ! Nous rêvons d'une barque toute neuve, à notre mesure, qui pourra plus sûrement nous mener à bon port. Nous devons la construire de nos propres mains, de façon à ce qu'elle réponde à nos besoins et nous prévienne des erreurs de navigation du passé. Il lui faudra la solidité et la stabilité voulues pour faire face à une mer plus houleuse et à quelques courants et vents contraires, qui ont tendance hélas à nous faire dévier de notre route principale. Un phare nous guide cependant ; nous apercevons ses feux dans le brouillard. Il porte un nom prestigieux : Assurance Qualité!

 

5.2 Sous-traiter ou ne pas sous-traiter, telle est la question !

La sous-traitance, tout particulièrement celle de la programmation, nous a causé tellement de problèmes, de frustrations et de pertes financières que nous devons sérieusement nous demander s'il ne vaudrait pas mieux engager, diriger et maintenir le personnel nécessaire à l'exécution de nos travaux de développement. Je vois plusieurs avantages à ce que le CCDMD ait sa propre équipe de programmeurs, située dans ses locaux : suivi et contrôle améliorés des travaux, meilleure prise en compte des besoins pédagogiques des projets, mise en place de méthodes de conception et de programmation structurées, application de tests systématiques et de critères de qualité rigoureux, maintenance et réutilisation rendues possibles.

Mais que faire pour les travaux où nous devons recourir à la sous-traitance ?

Dans ce cas, un contrôle serré des risques s'impose. Celui-ci poursuit trois objectifs :

  1. Bien s'assurer de choisir des sous-traitants compétents, qui sont en mesure de réaliser le travail escompté.
  2. Définir clairement l'estimation des charges, des délais et des coûts, préciser la planification du développement, les normes de qualité et les critères d'acceptation des produits.
  3. Effectuer un suivi constant des résultats concrets et de la performance réelle du sous-traitant par rapport à ses engagements.

L'atteinte de ces objectifs exige la mise en place de directives, d'activités et de procédures bien définies et bien documentées qui doivent être suivies rigoureusement. Des normes et des procédures, il en faut pour la sélection des sous-traitants, pour l'estimation et la planification des travaux, pour les tests de qualité des produits, pour la rédaction des ententes contractuelles, pour la gestion et le suivi de celles-ci, et aussi pour la résolution, s'il y a lieu, des conflits engendrés par leur mise en application.

J'ai fouillé partout, dans toutes les armoires et tous les classeurs de notre service : hélas, je n'ai rien trouvé, ou presque, relativement à ces normes et procédures. La prescription est simple : nous avons tout à mettre en oeuvre pour établir une gestion rigoureuse et blindée de la sous-traitance logicielle.

 

5.3 Oh ! les beaux écrans !

Même si un logiciel ne se limite pas uniquement à son interface usager, il devient nécessaire, à une époque où les interfaces graphiques et le multimédia se banalisent, que nos produits présentent les qualités graphiques et médiatiques des meilleurs logiciels du marché. Comme il ne peut y avoir d'hôtel de prestige sans façade imposante, nous ne pouvons plus produire du logiciel de qualité sans interface usager attrayante. Mais attention aux façades éblouissantes, qui ont pour but de maquiller de vieux hôtels délabrés !

Comme pour la programmation, nous avons le choix entre sous-traiter ou engager le personnel voulu. Encore ici, cette deuxième solution me semble avantageuse, malgré les difficultés administratives qu'elle implique. Ayons à notre service notre propre infographiste, qui répondra adéquatement à nos besoins, qui participera dès le début à la conception de nos logiciels et qui saura imposer un style graphique qui les caractérisera. Que tous nos logiciels passent par le pinceau de l'infographiste !

 

5.4 Des méthodologies structurées

Une connaissance réelle et un choix éclairé des méthodes de gestion, de conception, de réalisation et d'évaluation doivent précéder l'acquisition des outils qui permettent de les appliquer, et non l'inverse. Tout professionnel du développement logiciel devrait connaître les éléments de la conception et de la programmation structurées, de l'analyse des données, des revues et des inspections logicielles, des tests systématiques, et les autres méthodes fondamentales du génie logiciel. Ces méthodes, lorsqu'elles sont appliquées de façon cohérente et bien intégrée, ont un formidable pouvoir de prévention contre la mauvaise qualité, à tout point de vue.

Notre service devrait au moins appliquer systématiquement les techniques les plus puissantes de contrôle de la qualité pédagogique, médiatique et informatique à nos produits ; non seulement les méthodes d'élimination des défauts, mais surtout celles de la prévention de ceux-ci. Ce qui exige que le contrôle de la qualité soit appliqué tout au long du processus de développement d'un logiciel. Puisqu'il existe des erreurs de spécification et des erreurs de conception, aussi bien que des erreurs de codage, il y a des contrôles appropriés à chacune des phases du cycle de vie d'un logiciel. Les corrections sont toujours coûteuses, surtout si elles interviennent tardivement dans le cycle de développement.

En particulier, ne négligeons pas la qualité informatique de nos logiciels ! Mea-culpa ! dans le passé, nous avons eu tendance à refouler vers l'extérieur les aspects purement informatiques de nos projets, pourtant si essentiels. Les exemples de choc en retour ne manquent pas : plus souvent qu'il ne le faut, nous avons obtenu des logiciels médiocres et, quelquefois, nous avons dû abandonner des projets en développement.

 

5.5 Des tests systématiques

Parmi les méthodologies structurées, les tests systématiques tiennent une place de choix. Mais ces tests ne se limitent pas à la programmation ! Que de progrès dans ce domaine depuis les années 70 ! Vous ne le saviez pas ?

Mehr licht !

Sachons d'abord que les tests se planifient longtemps à l'avance. On le fait en les définissant à chacune des phases de conception. Ce qui veut dire que des batteries de tests doivent être spécifiées à chacune de celles-ci : tests de validation à la phase de spécification, tests d'intégration à la phase de conception préliminaire, tests unitaires à la phase de conception détaillée. En vertu de la sacro-sainte cohérence, les jeux de tests définis à une phase donnée servent d'entrée à la phase suivante, pour une expansion de ceux-ci. Ces tests, essentiellement de type fonctionnel, seront exécutés après le codage du logiciel, dans l'ordre inverse de leur spécification. Ils seront faits en boîte noire par un testeur qualifié, dont le but est de mettre systématiquement le programme à l'épreuve. Il importe que ces tests soient appliqués par quelqu'un d'autre que le programmeur du logiciel, qui manque du recul nécessaire pour une mise à l'essai suffisamment agressive et déviante de celui-ci.

Ce dernier, cependant, a la responsabilité des tests structurels en boîte blanche : tests de branche, tests de chemin, tests de décision et tests de conditions multiples. Ils se font au cours de la programmation, à la suite du codage de chaque procédure et de chaque module. Ces tests sont définis à partir de l'analyse de la structure des programmes et ont pour but de contrôler celle-ci.

Programmeurs, à vos marques, prêt, partez ! À l'avenir, nous vous demanderons de nous fournir vos jeux de tests documentés, avec vos données en entrée et en sortie.

Il va de soi que ce travail ennuyeux, mais essentiel, ne sera accompli par nos programmeurs que le jour où nous l'exigerons dans nos ententes contractuelles, en y ajoutant les deniers de la reine rémunérant un tel labeur. Pas question toutefois que ce boulot soit accompli à la main : il existe des outils qui automatisent la presque totalité de cette tâche titanesque.

 

5.6 Des outils appropriés

Il y a trois principes fondamentaux à respecter relativement au choix, à l'achat et à l'utilisation d'outils informatiques de développement logiciel :

  1. La connaissance préalable des méthodes et des techniques qui les sous-tendent ;
  2. L'intégration en un système cohérent et complet des outils utilisés ;
  3. L'adéquation de ceux-ci aux tâches à accomplir.

L'acquisition d'outils modernes de développement logiciel se planifie donc avec le plus grand soin.

Quelques exemples concrets de précautions à prendre, s'il vous plaît ?

 

Exemple 1. Outils de gestion de projet

Les outils adaptés, qui intègrent les principales composantes de la gestion d'un projet logiciel (découpage, estimation, planification, budgétisation, suivi et contrôle) et dont les paramètres s'ajustent selon l'historique des projets développés, sont rares et coûteux. Il vaudrait cependant la peine de se les procurer, en s'assurant qu'ils répondent bien à nos besoins. Il existe des logiciels de planification peu coûteux, tel Microsoft Project, mais on doit s'en méfier, pour deux raisons principales : d'une part, ces outils de planification n'intègrent pas les méthodes d'estimation, dont l'utilisation est un préalable essentiel à toute saine planification de projet ; d'autre part, ce sont des outils génériques qui, comme tels, ne sont pas orientés vers la gestion de projet logiciel, gestion qui a tout de même ses spécificités.

 

Exemple 2. Outils de conception

Le génie logiciel a favorisé le développement de toute une panoplie d'outils CASE (Computer Aided Software Engineering ) de conception logicielle, orientée objet ou non. S'ils sont pleinement intégrés (on parle alors d'outils I-CASE) et utilisés par un personnel qualifié, malgré leur coût élevé, ils présentent un excellent retour sur investissement. Les meilleurs outils I-CASE, en plus de fournir un support à la gestion logicielle, offrent un soutien diversifié et unifié au développement logiciel comme tel : divers supports à la spécification, à la conception, à la modélisation des données, au prototypage, à la programmation, aux tests systématiques, à la qualité logicielle, à la gestion de la configuration, à la maintenance, à la réutilisation, etc. Cependant, je ne connais pas d'outils I-CASE qui soient orientés "logiciel éducatif".

Si nous avions notre propre équipe de programmeurs, il faudrait sérieusement penser à nous procurer un tel arsenal. Est-il envisageable d'exiger de nos sous-traitants l'utilisation de ces outils ? Oui, si nous sommes prêts à y mettre le prix, car ceux qui les emploient font partie des ligues majeures. Non, car nous en perdrions les principaux avantages, puisque chaque sous-traitant applique sa propre méthodologie et utilise ses propres outils. "36 métiers, 36 misères !", me disait mon père. Il n'est pas question non plus de les mettre entre les mains de nos auteurs, car ce sont des outils pour informaticiens.

 

Exemple 3. Outils de programmation

Que de fois, dans le passé, nous avons utilisé un langage de troisième génération (BASIC, Pascal, C/C++) pour programmer un logiciel qu'on aurait développé beaucoup mieux et beaucoup plus rapidement avec un système-auteur. L'art de se compliquer la vie par l'emploi d'un canon pour tuer une mouche !

Monsieur G, qui ne connaît que le C++, aura tendance à utiliser ce langage pour programmer un démonstrateur, par exemple, même si celui-ci n'est pas approprié pour ce type de didacticiel. Dans ce cas, il s'agit de trouver une madame J, connaissant bien MACROMEDIA Director, qui programmera ledit logiciel en cinq fois moins de temps. De plus, elle modifiera sans peine son programme, selon les améliorations que l'auteur S voudra bien y apporter. Finalement, comme il s'agit d'un environnement multiplate-forme, le logiciel obtenu s'exécutera aussi bien sur PC que sur Mac.

Un système-auteur est en fait un outil de prototypage : il est moins général, et alors moins flexible, qu'un langage de troisième génération ; mais comme son utilisation est beaucoup moins laborieuse, le développement s'en trouve accéléré. Un système-auteur permet un prototypage rapide par le fait qu'il fournit tout un ensemble de composants préfabriqués que l'on assemble pour constituer un programme.

On distingue deux approches au prototypage rapide, qui sont différenciées par la dimension des composants. Il y a les outils de prototypage à petits composants, mais généraux : HyperCard et ToolBook en sont des exemples. Le programmeur sélectionne et adapte les composants à ses besoins, et y ajoute le code nécessaire.

L'autre approche est celle des outils de prototypage à grands composants : la coquille transactionnelle du groupe ID2 (cf. l'article précédent dans Clic no11) en est un exemple pour le domaine du logiciel éducatif ; il y en a d'autres 1 . Ces outils sont orientés "conception pédagogique"; on dit qu'ils forment des systèmes AID (Automated Instructional Design). Comme leurs composants sont plus grands, ils accélèrent davantage le temps de développement et demandent peu ou pas de programmation. Ils sont encore moins généraux que les systèmes-auteurs, mais ils ont une bien plus grande densité sémantique, relativement à la conception didactique. De tels outils seraient bien adaptés au développement de plusieurs de nos logiciels, d'autant plus que la mise en scène des aspects pédagogiques est leur préoccupation première.

 

6. LE NERF DE LA GUERRE

6.1 Le nerf spirituel

De fabuleuses sirènes nous guettent ! Déjà, quelques-uns de leurs chants langoureux nous séduisent ! Leurs doux airs nous incitent à tabler sur le paraître plutôt que sur l'être, à miser sur la quantité plutôt que sur la qualité, à fuir en surface sans cesse vers l'avant plutôt qu'à construire en profondeur sur du solide et du durable. La fibre de notre nerf spirituel sera-t-elle suffisamment robuste pour y résister ?

J'ai bon espoir ! Notre équipe a du potentiel et possède les qualités voulues ! Le succès de nos opérations repose moins sur la connaissance des principes et des outils (cela s'apprend !) que sur un état d'esprit. Ne dit-on pas que le changement des mentalités demeure le préalable essentiel à toute action ? Toutefois, le changement ne s'improvise pas : il demande de nous accorder sur le chemin à parcourir, de nous engager collectivement, d'assurer la continuité du processus, d'être soutenus par la hiérarchie et, bien sûr, d'investir en ressources humaines et en temps.

Soyons conscients que nous sommes ici en pleine pensée divergente, propre à la logique dialectique de l'action, plutôt que dans le domaine de la pensée convergente, typique de la logique linéaire des mathématiques et des sciences physiques, qui s'applique aux connaissances théoriques abstraites. Ainsi, à toute solution concrète à implanter dans notre pratique quotidienne, on peut assez facilement trouver des arguments contraires pour défendre le statu quo. Le discours hélas, si éblouissant soit-il, n'est pas suffisant pour faire la toilette de notre jardin, où poussent encore fébrilement les baobabs, cette plante terrible qui infestait la planète du Petit Prince de Saint-Exupéry.

Comme dans les vrais problèmes de la vie -- ceux de la politique, de l'économie, de l'éducation et de la famille --, il faut toujours triompher des contraires ou les concilier. À nous de nous imposer courageusement la discipline nécessaire à ce travail très ennuyeux, mais très utile, que nous recommande le Petit Prince : "Il faut s'astreindre régulièrement à arracher les baobabs dès qu'on les distingue d'avec les rosiers auxquels ils ressemblent beaucoup quand ils sont très jeunes." 2

 

6.2 Le nerf matériel

La vivacité du nerf spirituel ne peut se maintenir sans celle du nerf matériel. Et ce dernier, on le sait, ne vibre qu'à l'argent sonnant !

Nous avons perdu cette année la rampe de lancement de nos projets qu'était le programme PAREA. Quoique nous en ayons récupéré quelques poutres, la travée principale a disparu. Une diminution de notre subvention, prévisible pour l'an prochain, pourrait bien cette fois faire éclater notre nerf matériel déjà faiblard. Et si cela impliquait une réduction de notre équipe, dont la dimension se trouve à un minimum critique ! Je n'ose y penser ! Cette éventualité survenant, dans quel état se retrouverait notre nerf spirituel et que deviendraient nos intentions de changement ?

Cauchemar ! j'ai rêvé que cela s'était produit ! J'invitais alors notre équipe de vaillants mousquetaires à prendre une bière. Pendant que notre tristesse se diluait lentement dans la Blanche de Chambly, je leur racontais le roman de ma longue expérience des passions inutiles...

 


Notes
  1. Spector, J.M., Polson, M.C., & Muraida, D.J. (Eds.) : Automated instructional design: Concepts and issues, Educational Technology Publications, Englewood Cliffs, NJ, 1993. Retour au texte
  2. Saint-Exupéry, A. : Le Petit Prince, Éditions Gallimard, Paris, 1946, p. 24. Retour au texte

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