Retour à l'accueil
accueil renseignements diffusion
Recherche
avancée
 Numéro 7, Mars 1996 
Une gestion de projet efficace pour des logiciels de qualité Version Imprimable  Version imprimable
Le modèle (première partie) - Dessine-moi une maison

Jean-Guy Dubois  (CCDMD)

1. Dessine-moi une maison

La rencontre du Petit Prince et d'Antoine de Saint-Exupéry 1 aurait pu débuter par ces paroles :

 

- S'il vous plaît... dessine-moi une maison !

- Hein !

-Dessine-moi une maison...

Je n'ai pas l'intention de vous dessiner une maison, mais un modèle, semblable à celui de la construction d'une maison, qui pourrait nous servir de guide dans notre gestion de projet. Pour mon propos, j'utiliserai ce modèle comme une carte routière, dont les points de repère jalonneront le traitement suggéré en réponse au diagnostic établi lors du précédent article 2 . Pour l'instant, le traitement présenté restera général ; au prochain article, les remèdes indiqués seront plus spécifiques.

Malgré ses singularités, le développement d'un projet logiciel ressemble sous bien des aspects à la construction d'une maison. Cette analogie, qui m'est fournie par John Rakos 3 , nous aidera à mieux comprendre le modèle du cycle de vie du développement d'un projet logiciel. Celui-ci, tout comme la construction d'une maison, se déploie dans le temps : il se subdivise en phases bien définies. Cette approche est à la base des principales méthodologies de la gestion des projets informatiques.

 

Les sept phases de la construction d'une maison :

 

1. Phase de DÉFINITION

 

J'ai d'abord une histoire à vous raconter, purement fantaisiste. Il s'agit de la famille Lautochtone, qui vivait sous la tente, quelque part sur la Côte-Nord. J'étais alors chargé de projet d'une compagnie de construction immobilière. Le chef de famille vint me voir, un bel après-midi d'hiver, vers la mi-janvier 1992, si je me rappelle bien, pour me raconter ses problèmes :

 

Je vis depuis longtemps sous la tente, sur un îlot perdu au nord de Gagnon.

 

"Quel problème avez-vous avec cette façon de vivre ? La vie au grand air ne vous plaît pas !", lui dis-je. Il m'exposa alors ses besoins :

 

"C'est l'hiver et il fait beaucoup trop froid dans ma tente ; tandis qu'en été, il fait trop chaud. J'aurais besoin de contrôler la température.

Pendant le jour, c'est trop clair à l'intérieur ; tandis que c'est beaucoup trop noir durant la nuit. J'aurais besoin de contrôler la lumière.

Pour mes petits besoins, je dois sortir et creuser un trou dans la neige. Si je veux me laver, je dois chauffer l'eau sur un feu à ciel ouvert. J'ai besoin de commodités.

Ma femme et mes trois enfants vivent avec moi sous la tente. J'ai besoin d'intimité et de m'isoler du bruit."

 

Il m'expliqua ainsi tous ses besoins, et j'en établis avec précaution la liste complète. J'avais en main les principaux éléments qui constituaient les requêtes de mon client. À partir de celles-ci, je pouvais lui proposer la petite maison de rêve qui allait satisfaire ses principaux besoins.

 

2. Phase de SPÉCIFICATION

 

Ayant en main le document des requêtes, je fis appel à l'ingénieur analyste de la compagnie, afin qu'il me définisse les spécifications fonctionnelles pour la maison qui correspondrait le mieux aux besoins de mon client. Quelques jours plus tard, l'ingénieur me remit le cahier des charges contenant, parmi d'autres, les spécifications suivantes :

 

La maison de monsieur Lautochtone aura des chambres avec des murs opaques et insonorisés lui fournissant l'intimité et la tranquillité voulues.

Il y aura un thermostat sur le mur de chacune des pièces, afin que la température de celles-ci puisse être contrôlée individuellement. Un diagramme du thermostat est inclus.

Il y aura un interrupteur variable pour chacune des pièces, afin que l'intensité de la lumière puisse être contrôlée pour chacune de celles-ci. Un diagramme de l'interrupteur est inclus.

La maison possédera une salle de bains avec douche, pour les nécessités personnelles et la toilette. Un diagramme des VC est inclus.

La douche aura un robinet permettant d'ajuster la température de l'eau à l'intensité voulue. Un diagramme du robinet est inclus.

 

Et ainsi de suite.

 

L'ingénieur analyste décrit ce que la maison apportera à l'utilisateur : les entrées, les sorties et les interfaces entre la maison et celui-ci. Il n'y a aucune mention de la façon dont sera construite cette maison : à ce stade, on ne s'intéresse pas au COMMENT, mais seulement au QUOI, c'est-à-dire à ce que comprendra la maison pour répondre aux besoins de l'utilisateur. Avec les spécifications fonctionnelles, je peux faire différentes propositions à mon client, selon le montant qu'il est prêt à investir pour sa maison.

 

3. Phase de CONCEPTION

 

Le concepteur est l'architecte ; son objectif est d'établir un plan détaillé de la maison. Le plan ne comprend pas seulement les divisions en diverses pièces correspondant à des fonctions spécifiques (salle à manger, salle de bains, salon, chambres à coucher, etc.), mais aussi comment les pièces sont reliées entre elles. De plus, toutes les connexions entre les divers systèmes doivent être bien indiquées : système de chauffage, système électrique, plomberie, etc.

 

La conception montre, par l'élaboration d'un plan dessiné, COMMENT la maison sera construite. Le plan présente d'abord une vue d'ensemble de celle-ci : c'est la conception préliminaire. Il présente ensuite, pour certaines sections du plan, les détails nécessaires à la construction des parties correspondantes : c'est la conception détaillée.

 

4. Phase de PROGRAMMATION

 

L'équivalent de la programmation pour la construction d'une maison, c'est le travail de l'entrepreneur, des charpentiers, des plombiers, des électriciens, etc. Tous travaillent selon les indications du plan de l'architecte, selon les spécifications de la conception.

 

5. Phase des TESTS

 

Au fur et à mesure de la construction, l'architecte et l'entrepreneur testent systématiquement chaque composante de la maison : le sous-sol, le premier et le deuxième plancher, le toit, le système électrique, le système de chauffage, la plomberie, et ainsi de suite (tests unitaires), conformément à la conception détaillée. Vers la fin, ils s'assurent que les diverses parties de la maison et tous ces systèmes fonctionnent correctement ensemble (tests d'intégration), conformément à la conception préliminaire.

 

6. Phase de VALIDATION

 

Le demandeur vient maintenant voir la maison complétée, peut-être pour la première fois. S'il est prudent, il vérifie toutes les parties de la maison et tous les systèmes, afin de s'assurer que ceux-ci fonctionnent selon les spécifications indéquées. S'il se présente un problème, l'entrepreneur est tenu de faire le nécessaire pour le corriger. Lorsque le demandeur est satisfait, il ne lui reste plus qu'à payer, selon les termes du contrat.

 

7. Phase d'EXPLOITATION

 

Finalement, la maison est occupée par le propriétaire et sa famille. Généralement, une période de garantie est accordée, afin de s'assurer qu'il n'y a pas de défauts cachés. C'est au cours de cette période que les occupants évaluent leur habitation. Correspond-elle à leurs besoins ? Est-ce vraiment la maison qu'ils désiraient ? Tôt ou tard leurs besoins évolueront : ils seront ainsi amenés à y introduire des aménagements, des agrandissements ou une nouvelle façade (version 2 !).

 

Ce modèle est-il suivi par notre Section de l'informatique au CCDMD ?

 

Pour notre Section, un projet logiciel est défini lors de sa soumission, à la suite de l'Appel de projets. Les phases de spécifications fonctionnelles et de conception préliminaire sont en partie couvertes par le devis pédagogique présenté par l'auteur du projet. Quant aux phases de conception détaillée et des tests, comme elles sont la plupart du temps escamotées par le programmeur, elles devront être mises en place de façon systématique. La phase de validation est sous la responsabilité de l'auteur pédagogique et du technicien.

 

2. L'assurance qualité

 

Munissons notre gestion de projet d'une assurance qualité, afin de nous assurer d'une production de qualité ! Tel pourrait être le premier traitement général à appliquer aux maux de notre conduite de projet. La difficulté est de taille, car la qualité d'un logiciel éducatif comprend trois aspects essentiels à bien coordonner : l'aspect pédagogique, l'aspect informatique et l'interface usager. On doit assurer une maison à trois étages !

 

La qualité est attribuée à un produit, qu'il possède à divers degrés. L'assurance qualité va de pair avec le contrôle de la qualité : la première planifie et met en oeuvre un processus impliquant une production de qualité, qu'il faut gérer et superviser, tandis que le deuxième évalue la qualité des produits de ce processus, afin d'y amener, si nécessaire, et le plus tôt possible, les correctifs qui s'imposent. L'assurance qualité définit un ensemble de normes, de procédures et de mesures à appliquer, qui sont consignées dans un document généralement appelé Manuel Qualité Logiciel. Ce manuel constitue en quelque sorte la base de connaissances de tout service sérieux de développement logiciel. Son plan de contrôle de la qualité indique les documents contrôlés, la nature des contrôles, quand ils sont effectués et par qui ils le sont.

Une méprise lourde de conséquences, hélas, souvent commise, est de croire que développer un logiciel, c'est d'abord écrire un programme. On confond ainsi architecture et maçonnerie ! Développeurs, ne cédez pas trop vite à la tentation de la machine ! Ce n'est pas la conception qui doit s'adapter au programme, mais ce dernier qui doit se conformer à celle-ci. À cette danse à deux, la première mène, le deuxième suit. Rappelez-vous cet énoncé provocateur de Weinberg 4 : "Si les architectes faisaient construire les bâtiments de la même façon que les programmeurs écrivent les programmes, le premier pivert venu détruirait la civilisation." Heureusement, la méthodologie de développement de logiciel s'est quelque peu améliorée depuis les années 70.

 

Le coût de la correction des erreurs est d'autant plus élevé qu'une erreur provenant d'une phase en amont est découverte tard en aval. L'assurance qualité et le contrôle de la qualité doivent donc être mis en place dès les premières phases de développement d'un logiciel ; en fait, dès l'expression des besoins de la phase de définition. En effet, la pire chose qui puisse arriver à un logiciel est qu'il ne corresponde pas aux besoins des utilisateurs. Cette erreur lui est fatale ! Généralement, il en meurt !

 

Un logiciel de qualité exige que les besoins exprimés soient conformes aux besoins réels et que le logiciel produit soit conforme aux besoins exprimés. Le rôle de l'assurance qualité est de permettre de construire cette conformité à chacune des phases de développement du logiciel et d'en permettre la vérification par un contrôle adéquat.

 

La gestion de la qualité est un processus en quatre étapes :

 

1. L'assurance qualité définit les règles à respecter pour satisfaire les objectifs de qualité à atteindre. Ces règles sont comprises dans le Manuel Qualité Logiciel.

 

2. Durant le cycle de vie du logiciel, chacune des phases produit le document ou programme qui exprime la solution obtenue à cette étape de développement.

 

3. L'évaluation des réalisations est à la base du contrôle de la qualité, en assurant une comparaison entre les règles proposées et les résultats obtenus.

 

4. S'il y a lieu, des corrections sont appliquées à chacune des étapes pour parer aux lacunes ou aux erreurs identifiées.

 

Les fonctions remplies par le ou les responsables de la qualité sont multiples. Elles s'appliquent à toutes les phases du cycle de vie du logiciel et, s'il s'agit de logiciel éducatif, elles doivent tenir compte de l'aspect pédagogique, autant qu'informatique et interface usager.

Ces fonctions se regroupent en cinq catégories 5 :

 

1. Détecter et analyser les lacunes, les erreurs et les problèmes communs à un ensemble de projets ou spécifiques à l'un d'eux, que ce soit pour les projets passés ou courants.

 

2. Développer des normes, des règles et des procédures relatives au processus de développement, à la conception, à la programmation, aux évaluations, à la documentation, etc.

 

3. Revoir l'environnement de gestion de la qualité ou, s'il est absent, en mettre un en place, avec la collaboration des principaux intervenants.

 

4. Fournir des avis ou des conseils techniques sur les politiques mises en oeuvre, les standards à suivre, les méthodes et techniques à appliquer, les outils à utiliser, etc.

 

5. Procéder à des revues de projet par l'application systématique de méthodes et de techniques destinées à la vérification du bon passage d'une étape par des points de contrôle incontournables sur la qualité des produits.

 

3. La gestion des risques

 

L'industrie du logiciel s'est créé une réputation terrible de sous-estimation des projets, que ce soit par rapport aux délais, aux charges ou aux coûts. La Section de l'informatique du CCDMD n'y échappe pas.

 

Ah ! si nous vivions dans un monde idéal !

 

Un monde où les auteurs ne changeraient pas d'idée en cours de route ; où ils rempliraient avec diligence toutes leurs responsabilités, y compris la livraison à temps d'une documentation de qualité. Un monde où l'administration nous soutiendrait dans toutes nos décisions et satisferait à tous nos besoins ; où l'on disposerait de toutes les ressources nécessaires, et au moment voulu, sans limites de temps et d'argent ; où l'on contrôlerait complètement notre production, sans faire appel à des sous-traitants. Un monde où les programmeurs testeraient systématiquement leurs programmes, les structureraient et les documenteraient de façon à en faciliter la maintenance. Un monde où les responsables de projet auraient toutes les connaissances et les compétences nécessaires, tant informatiques que pédagogiques, tout en étant des gestionnaires exceptionnels. Et encore plus ! Le paradis, où tout le monde est beau et gentil, quoi !

 

La dure réalité, hélas ! est bien différente et souvent triste !

 

Nos budgets sont de plus en plus limités ; on parle même d'autofinancement. Certains projets sont beaucoup trop ambitieux, les besoins sont mal identifiés, le devis de l'auteur est incomplet et reste imprécis sur bien des points. Les ententes avec les réalisateurs informatiques sont signées à partir d'estimations optimistes et grossières des charges, des délais et des coûts, qui sont généralement dépassées en cours de réalisation. Les ressources attribuées à certains projets sont inadéquates : l'auteur a peu d'aptitude pour la conception d'une interface usager, le responsable ne possède aucune connaissance du contenu disciplinaire considéré, l'environnement informatique de développement ne convient pas, le programmeur n'entend rien à la conception informatique, les tests systématiques et structurés ne sont pas prévus, etc. Souvent, le responsable a peu de contrôle sur les délais : certains intervenants ne consacrent au projet qu'une partie réduite de leur temps de travail ou habitent en région éloignée, souffrant ainsi d'un manque d'encadrement efficace. Certaines charges sont oubliées, les responsabilités de chacun sont mal définies, la conception de l'auteur évolue et ses demandes aussi, le programmeur impose son point de vue, au détriment de l'approche pédagogique de l'auteur, etc. Petit à petit, certains projets s'enlisent et leurs principaux acteurs se démobilisent.

 

Le paradis nous est inaccessible ! Nous sommes quelquefois condamnés aux affres de l'enfer ! Nous aspirons à de nouvelles nourritures terrestres ! Nous voulons neutraliser les sortilèges et les maléfices qui nous affligent : pas besoin de magie ou d'exorcisme, prévenons-nous d'abord du pire par une meilleure gestion des risques.

 

La gestion des risques comprend trois volets :

 

1. L'anticipation des risques

 

La première compétence à acquérir : savoir reconnaître une situation risquée. Pour se sensibiliser à de telles situations, rien de mieux que de regarder vers le passé, que d'analyser sa propre histoire.

 

Il faut d'abord dresser la liste de tous les problèmes significatifs qui se sont présentés et, ensuite, en rechercher les causes. La "dure réalité" décrite plus haut identifie déjà un certain nombre de ces situations à risque élevé. Cette liste reste ouverte : de nouveaux problèmes se présenteront au cours des années, qui seront ajoutés à la liste. Afin de déterminer leur degré d'importance, il convient de classifier les éléments de la liste en trois catégories : les situations à faible risque, à moyen risque et à fort risque.

 

2. L'estimation des risques

 

Nous avons une formule à mettre dans notre potion anti-risque ! Pour un projet dont on veut estimer les risques, on dresse d'abord la liste des situations risquées qui peuvent s'y présenter, en s'aidant de la liste type produite au volet 1. On attache ensuite à chacun de ceux-ci une priorité, que l'on calcule en prenant le produit de la probabilité que la situation correspondante se produise par son impact sur le projet. À l'aide des priorités ainsi obtenues, on ordonne en ordre de sévérité décroissante les items de la liste. Finalement, du tableau des situations risquées ainsi établi, on détermine, pour chacune d'elles, les causes du risque.

 

3. La réduction des risques

 

L'estimation des risques nous sert à les éliminer si possible, sinon à les réduire. En commençant par les items de plus haute sévérité, on recherche la façon la plus efficace d'éliminer les causes du risque identifié. Pour les situations à haut risque, il ne faut pas craindre de prendre les décisions qui s'imposent, même si elles sont quelquefois douloureuses.

 

Lorsque nous ne pouvons éliminer les causes d'une situation risquée, nous cherchons au moins à en réduire l'impact sur le projet, par l'élaboration d'un plan parant à toute éventualité. Pour chacune d'elles, il faut prévoir une solution de remplacement permettant de faire face à la musique : avoir en réserve une ressource appropriée, pouvoir ajuster les délais et les coûts en conséquence, etc. Sinon, nous continuerons à jouer aux sapeurs-pompiers : attendre qu'un incendie se déclare avant d'agir, avec tous les ravages qui sont alors causés.

 

Malgré tous nos efforts, il y aura toujours des situations irréparables. Lorsque les choses vont vraiment mal, évitons la panique et gardons le contrôle de la situation ! Sinon, prions...

 


Notes
  1. Saint-Exupéry, A. Le Petit Prince, Éditions Gallimard, Paris, 1946. Retour au texte.

  2. Dubois, J.-G. Une gestion de projet efficace pour des logiciels de qualité. Le diagnostic. CLIC, no 6, février 1996. Retour au texte.

  3. Rakos, J. J. Software Project Management For Small to Medium Sized Projects, Prentice Hall, Englewood Cliffs, 1990. Retour au texte.

  4. Weinberg, G.M. The Psychology of Computer Programming, Van Nostrand Reinhold, New York, 1971. Retour au texte.

  5. Perry, W.E. Quality Assurance for Information Systems: Methods, Tools, and Techniques, John Wiley & Sons, New York, 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