Software Fundamentals Collected Papers by David L. Parnas Edité par Daniel M. Hoffman, David M. Weiss. ISBN 0-201-70369-6 Mars 2001 664 page
Commentaire:
Passages intéressants. Douteux par endroit.
Qui est David L. Parnas?
David L. Parnas est l'auteur de plusieurs articles influents dans le monde du développement informatique. Ces travaux portent sur l'utilisation de modèles mathématiques comme un moyen d'améliorer la qualité des systèmes informatiques. D'origine canadienne, il est détenteur d'un doctarat en génie électrique de l'université Carnegie Mellon. Il a obtenu en 1998 le "Outstanding Research Award" du ACM SIGSOFT.
Trente-trois articles
Le livre Software Fundamentals est une sélection de trente-trois articles parmi les quelques deux cents que l'auteur a publié. Bien que certains datent de plusieurs années, la plupart restent d'actualité. Le ton du livre est parfois prococateur.
Les trois quarts des articles présentés sont largement techniques; l'auteur propose l'utilisation de modèles mathématiques, similaires à ceux utilisés en génie, comme un moyen d'améliorer le développement de logiciel.
Quatre de ces articles ont un contenu plus politique, pour ne pas dire contreversé. Ingénieur lui-même, Parnas propose que le développement du logiciel soit une activité relevant du génie. Ces chapîtres sont:
27) SDI: A Violation of Professional Responsability 28) The Professional Responsabilities of Software Engineers 31) Teaching Programming as Engineering 32) Software Engineering: An Unconsummated Marriage
SDI: A Violation of Professional Responsability Dans cet article, Parnis explique pourquoi il pense que le programme SDI (Stategic Defence Initiative, plus connu sous le nom du programme Star Wars") est voué à l'échec parce que trop complexe, et que tout professionnel qui ne croit pas au succès d'un projet ne doit pas continuer d'y travailler.
The Professional Responsabilities of Software Engineers Parnas fait une distinction entre les responsabilités personnelles, partagées par tout travailleur, des responsabilités professionnelles, propres à chaque profession et qui vont au-délà des reponsabilités personnelles. Il insiste sur cinq obligations que devraient avoir tout professionnel en développement logiciel: accepter une responsabilité individuelle, régler le vrai problème du client, être honnête au sujet de ses compétences, accepter que leur conception soit revue et mise en doute, et faciliter l'évolution future du bien livré.
Teaching Programming as Engineering L'auteur présente ici l'importance de la place que devrait avoir les mathématiques dans la programmation, et pourquoi la programmation devrait être considéré comme une branche du génie.
Software Engineering: An Unconsummated Marriage Parnas déplore ici le manque de communication entre le monde du génie d'autre part, et le monde du développememnt de logiciels d'autre part.
Appreciation
Parnas presente de facon convainquante des moyens d'ameliorer la conception de logiciels. En ce sens, la contribution de Parnas a l'informatique est indeniable. Ce qui agace par contre, c'est que l'auteur rejette avec fracas tout ce qui est eloigne de son champ d'expertise. L'enseignement des langages de programmation modernes a peu de valeur intellectuelle (page 582); les formalismes a la UML sont flous et sont tout sauf une bonne idée (page 141). Les sens bonnes choses selon l'auteur semblent etre les principes de genie electrique, les mathematiques discretes et le FORTRAN. Si vous cherchez un livre qui vous donne une image globale, neutre et balancee de la discipline informatique, vous seriez mieux d'aller voir ailleurs.
Conclusions
L'insistance que met Parnas à la nécessité d'améliorer le processus du développement du logiciel recoupe sur plusieurs points les principes de l'APIIQ et de son code de déontologie; en ce sens son livre est plus que pertinent pour tout quiconque à coeur une pratique professionnelle de qualite.
Pour ce qui est de la position de Parnas que le développement logiciel devrait relever du génie traditionnel, son argumentation paraît faible sur plusieurs points, mais c'est un point de vue qui est malheurement largement accepté dans certains milieux. Il y a au moins deux points sur lequels Parnas reste muet:
1) Si le développement du logiciel relevait du génie, qu'adviendrait-ils des professionels non-ingénieurs mais compétents en génie logiciel? En quoi cette exclusion de professionnels compétents est compatible avec la protection du public?
2) Si le développement du logiciel relevait du génie, qu'est-ce qui empêcherait légalement un ingénieur non formé en informatique (par exemple un ingénieur civil) de se présenter au public comme un ingénieur logiciel?
C'est dans des situations semblabes que l'existance d'associations fortes comme l'APIIQ est nécessaire pour faire en sorte que des points de vues différents de ceux de Parnas puissent se faire entendre à l'oreille de nos décideurs.
======
Positions commentées de David L. Parnas
Qu'est-ce que le génie logiciel ?
"Le génie logiciel est défini commme le développemnt par plus d'une personne d'un programme livré en plus d'une version." (Parnas, page 257)
Selon cette définition, un ingénieur qui écrit un petit programme en C pour configurer un micro-processeur qu'il met au point ne fait pas du génie logiciel.
Par contre, un groupe d'informaticiens developpant une application de gestion de personnel, application livrée en plusieurs versions, font du génie logiciel.
---
"Les ingénieurs ne prennnt pas la programmation au sérieux; ceux qui écrivent des programmes n'ont pas été formé pour la tâche; ils en savent habituellement peu sur l'informatique ou les méthodes de programmation; ils ne font qu'écrire du code comme on en écrivaient il y a trente ans". (Parnas, page 545).
---
"Des ingénieurs australiens m'ont rendu consient d'un problème général. Comme membres d'une société professionnelle, ils prennent leurs responsabilité au sérieux, mais doivent utiliser des outils logiciels écrits par des gens qui ne pas membres d'aucun regroupement similaire. Ils croient que seuls des ingénieurs devrait pouvoir écrire du logiciel destinés à des ingénieurs." (Parnas, page 545).
En suivant la même logique, seuls des comptables devraient pouvoir écrire des logiciels destinés aux comptables; seuls les médecins devraient pouvoir écrire des logiciels destinés à d'autres médecins. La profession d'informaticien disparaitrait donc et l'expertise sur le développement de logiciel de qualité se trouverait dispersé dans plusieurs professions.
---
"La programmation n'est ni une science ni mathématique; les programmeurs n'ajoutent rien à notre bagage de connaissances: ils construisent des produits. Utiliser la science et les mathématiques est ce que les ingénieurs font. ". (Parnas page 596).
L'informatique, comme l'économie et la démographie, est une discipline qui utilise énormément les mathématiques. Par contre les sciences physiques (physique, chimie et biologie) servent peu en informatique, alors qu'elles sont omniprésentes en génie. C'est une distinction fondamentale entre l'informatique d'une part et le génie de l'autre. Le développement du logiciel n'est pas une sous-branche du génie; c'est une discipline à la frontière du génie, de la gestion, de la technologie et des sciences sociales (voir "Les zones frontalières, La spécificité de la discipline informatique page 6).
--
Specification et Conception
Citation de Parnas
Monsieur Hubert Stephenne, directeur général de l'OIQ, mentionnait à "La Presse", dans cet article du 10 mars dernier, que "Tout au plus, la modernisation de la Loi sur les ingénieurs réservera certains actes aux membres de l'Ordre dans différents domaines, notamment en informatique, quand il s'agit de programmes <<conçus>> spécialement pour évaluer la résistance de la structure d'un pont, par exemple".
http://www.apiiq.qc.ca/public/archives/interface/face9502.html#oiq Est du ressort exclusif de l'ingénieur l'exercice de l'un ou l'autre des actes suivants(..) <<concevoir>> des ouvrages, des travaux, des systèmes ou des procédés, ou les vérifier. (..) l'audit de <<conception>>, les services d'assurance-qualité, ainsi que la direction de ces activités de la <<conception>>.
Le
rôle de l'informaticien n'est pas de fournir les
<<spécifications>> des systèmes qu'il doit
<<concevoir.>> Nul doute que seul l'ingénieur est formé pour fournir les spécifications d'un système d'aide à la conception d'un pont. Par contre, seul l'informaticien est formé et qualifié pour s'assurer que le système conçu répondra à ces spécifications. Seul l'informaticien est formé pour la gestion d'un projet informatique.
Il est temps de remettre en question le contenu intellectuel des plusieurs cours en informatique. En quoi ces cours se comparent-ils aux autres cours en génie. Le cours type en programmation montre un langage de programmation, pas des verites mathematiques. De tels cours sont comme un manuel d'instruction de calculettes, ou sont les boutons, comment changer l'affichage, etc. Les informaticiens pensent que l'on devrait enseigner des langages plus modernes que le Fortran. Je ne crois pas que l'enseignement de 'vieux' langages soient le vrai probleme. (Parnas p582).
== Au sujet d'UML
N'importe quel diagramme dessinés semple précis; mais la signification de ces boites et de ces fleches est floue. Il y a maintenant plusieurs UMLs (Undefined Modeling Langages) qui ajoutent a la non-comprehension. Meme les partisans de tels langages admettent qu'ils non jamais ete bien definis mais croient que quelqu'un va les definir plus tard. Les UMLs sont une mauvaise idee.
La recente popularite d'UML semble donner contredire l'opinion de Parnas. A moins que tout le monde ait tort et que Parnas est raison.
Probleme de l'an 2000
Au sujet des risques informatiques, on mentionne rarement le probleme de base : la plupart des programmeurs n'ont pas ete formés pour le travail qu'ils font. Le probleme illustre bien ce point. Depuis trente ans, nous savons comment concevoir des programmes de facon a ce qu'il soit facile a modifier le format des donnees comme les dates. Neanmoins, des milliers de programmeurs ont ecris des milions de lignes de code qui violaient ces bons principes. Pourquoi? Parce ce que ceux qui concevaient et approuvaient ces logiciels etaient incompetents. (p 595)
Il faut noter que le logiciel fautif a ete produit en grande partie dans les annees 70, avant la mise en place de la plupart des programmes universitaires en informatique et a une epoque ou les langages de programmation soutenaient moins bien les types abstrait de donnees. Les programmes ecrits dans les annees 90, par des gens qui etaient reelement des informaticiens, ont bien passés le test de l'an 2000.