Software Fundamentals



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.

Source : http://www.apiiq.qc.ca/public/archives/interface/face9505.html

==
  L'enseignement des langages de programmation

 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.

 



Dernière mise à jour: 26 novembre 2009.