Réglementation de l'industrie du logiciel [fermé]

85

Toutes les quelques années, quelqu'un propose une réglementation plus stricte pour l'industrie du logiciel.

Cet article de l'IEEE a fait l'objet d'une attention récente sur le sujet.

Si les ingénieurs en logiciels qui écrivent des programmes pour des systèmes exposant le public à des risques physiques ou financiers savaient qu'ils seraient mis à l'épreuve sur leurs compétences, cela réduirait les erreurs et les défaillances du code et permettrait peut-être de sauver quelques vies.

Je suis sceptique quant à la valeur et au mérite de ceci. À mon avis, cela ressemble à une saisie de terres par ceux qui l'ont proposée.

La citation qui décrive cela pour moi est la suivante:

L'examen testera les connaissances de base, pas la maîtrise de la matière

parce que les gros échecs (par exemple THERAC-25 ) semblent être complexes, des problèmes subtils que les "connaissances de base" ne seraient jamais suffisants pour prévenir.

Ignorer les problèmes locaux (tels que les protections existantes du titre Engineer dans certaines juridictions):

Les objectifs sont nobles - éviter les charlatans / charlatans 1 et rendre cette distinction plus évidente pour ceux qui achètent leur logiciel. Une réglementation plus stricte de l'industrie du logiciel peut-elle atteindre son objectif initial?

1 Exactement comme le voulait la réglementation de la profession médicale.

Flexo
la source
3
J'espère que Thomas Owens répondra à cela car je sais qu'il a la réponse parfaite.
maple_shaft
3
Même si j'aimerais entendre ce que les gens ont à dire sur ce sujet, il me semble qu'une question de discussion me conviendrait parfaitement pour le format de questions-réponses de Stack Exchange.
PersonalNexus
12
Franchement, je suis en faveur d'un amendement constitutionnel qui crée une séparation entre technologie et État, étant donné le
manque de maîtrise
3
Comment une industrie peut-elle être réglementée quand elle change tous les jours?
Jon Raynor
4
Beaucoup de ces situations "suffisamment bonnes" ne sont-elles pas à l'origine de bugs par la suite, souvent par la faute de la direction / du marketing: "SHIP SHIP SHIP!"
Aren

Réponses:

105

Le point de vue selon lequel les ingénieurs en logiciel peuvent être classés dans la même classification que les professionnels de la santé ou les comptables est une vision ignorante du "problème" qu’ils tentent de résoudre. Avant de donner mon opinion à ce sujet, décrivons certains des arguments de M. Thornton, vice-président de l'organisme de réglementation proposant ce projet de loi.

«Tout comme les professionnels en exercice, tels que les médecins, les comptables et les infirmières, sont autorisés à le faire par les ingénieurs en logiciel», déclare Thornton. «Le public doit pouvoir compter sur une sorte d’identité lors du choix d’un entrepreneur pour l’écriture de logiciels.»

- Mitch Thornton, vice-président de la licence et de l’enregistrement IEEE

Cela semble très raisonnable en surface. Après tout, d’autres industries pourraient être considérées comme "réglementées avec succès". Par réglementé avec succès, je veux dire que si vous regardez un médecin dans les pages jaunes, vous pouvez être raisonnablement certain qu'il a suivi une formation approfondie dans une université accréditée, qu'il a passé plusieurs examens et terminé sa résidence. Voici quelques industries "réglementées avec succès" (en termes de personnel professionnel).

  • Les avocats
  • Médecins
  • Les comptables
  • Ingénieurs nucléaires
  • Barbiers ( ne plaisante pas )

Après tout, vous ne voulez pas que quiconque enlève cette tumeur de votre pancréas ou travaille sur les centrifugeuses de cette centrale nucléaire juste à l'extérieur de la ville. Pourquoi des restrictions similaires n'existeraient-elles pas pour les ingénieurs en logiciel?

Seuls ceux dont les programmes pourraient «mettre en danger la santé ou la sécurité publiques, la sécurité, la propriété ou l'économie devront être testés»,

Cette déclaration est vague et ouverte à une interprétation et à une application libérales. Je pourrais faire valoir que Apple Inc. ou Facebook font partie intégrante de l'économie américaine - ai-je besoin d'une licence spéciale du gouvernement pour écrire du code pour eux maintenant, car si je détruis le site avec mon incompétence, je pourrais nuire à l'Amérique économie? Lors de mon dernier emploi, j'ai accidentellement arrêté un silo à grain avec un travail défectueux, mettant potentiellement en danger l'approvisionnement en nourriture.

Je me rends compte que j'évite l'intention de cette proposition. L'idée sous-jacente est de s'assurer que la personne qui écrit le code du système de freinage anti-blocage sur votre nouvelle Jetta est compétente et dûment autorisée à rédiger le code d'un système de freinage anti-blocage. Sur ta Jetta.

Voici le problème: à l’époque, le génie logiciel englobe tout et il est impossible de tester toutes les disciplines. Les règles de gestion sont trop spécifiques et varient d’une discipline à l’autre. Notre ingénieur hypothétique qui écrit du code pour le système ABS sur une Jetta pourrait écrire quelque chose de totalement différent pour le système ABS sur une Elantra. Doit-il se faire re-certifier?

Et si vous testiez pour toutes ces disciplines dérivées? Supposons un instant que chaque programmeur travaillant sur un site Web de commerce électronique soit certifié en tant que programmeur capable de commerce électronique. Alors? Cela signifie-t-il soudainement que ces programmeurs et sociétés procéderont à la validation nécessaire et à la conformité PCI? Même s'ils le font, des problèmes continueront à se produire.

Selon Mitch Thornton, vice-président du comité d'homologation et d'enregistrement de l'IEEE, l'examen vérifiera les connaissances de base, et non la maîtrise de la matière.

Voici le kicker. Un manque de connaissances de base n'est jamais le problème. Mes freins anti-blocage n'ont pas cessé de fonctionner parce que Chuck luttait contre les concepts d'une structure de contrôle. Ils ont échoué parce qu’il y avait un problème avec l’ABS qui s’est éteint en raison d’un court-circuit dans les feux arrière et où l’alimentation n’a pas été correctement déviée. Ou quelque chose.

Le logiciel de pompe à insuline que j'ai écrit n'a pas cessé de fonctionner car je manque de compétences de base; cela s'est arrêté parce qu'il y avait un problème dans la façon dont j'ai mesuré la distribution d'insuline lorsque mon coéquipier européen a utilisé le système métrique et que je ne l'ai pas fait.

Vous pouvez en tenir compte dans le développement, mais vous ne pouvez jamais effectuer de test avec une certification .

Voici ce qui se passera si cette "certification" entre en vigueur: le nombre d'incidents restera exactement le même. Pourquoi? Parce qu'il ne fait rien pour éliminer le problème réel d'une défaillance de la pompe ABS ou de la pompe à insuline.

Jarrod Nettles
la source
33
+1 excellente réponse. J'aime particulièrement: "Un manque de connaissances de base n'est jamais le problème."
Jonathan Henson
4
Excellente réponse, mais cela ne prend en compte que l’ingénierie logicielle du point de vue des programmeurs. Une véritable ingénierie logicielle est en réalité un travail d’équipe impliquant de multiples compétences et disciplines, analystes d’entreprise, assurance qualité, gestion de projet, etc. et des tests incorrects. Le test du PO mentionne-t-il cela? Bien sûr, pas parce que c'est pour les programmeurs.
maple_shaft
3
J'ajouterais cependant que je pense que l'idée entière de l'IEEE est une foutaise pour commencer. Tout ce que le gouvernement doit faire, c'est son travail pour résoudre le problème. Tenir tout le monde responsable des dommages qu’ils subissent. Cela seul
Jonathan Henson
16
En désaccord avec "Un manque de connaissances de base n'est jamais le problème." En fait , il souvent est le problème. À quelle fréquence les nouveaux programmeurs (ou les plus âgés) négligent-ils la désinfection des entrées? Vérification de cas en coin? Pour les systèmes physiques, je pourrais lire un capteur. Il peut être activé ou désactivé. Qu'en est-il cassé? Comment mon logiciel peut-il dire? Alors que fais-je à ce sujet? Présume qu'il est allumé ou éteint? Ces types de choses "de base" sont effectivement en cause.
Sdg
3
@JonathanHenson Encore une fois, je considère que la plupart des instances d'injection SQL sont exactement cela: des connaissances de base insuffisantes ... mais dans l'ensemble, une bonne publication. +1
Jeff Ferland
72

Quelle chance que personne ne meure grâce à une réglementation médicale, que personne ne soit victime de fraude grâce à une réglementation financière, que sa maison ne soit pas fermée à cause de la réglementation relative au logement, que personne ne se coupe mal grâce à la réglementation du coiffeur et qu'aucun avion ne s'écrase grâce à la réglementation des avions.

De toute évidence, la présence d'une réglementation n'implique pas une absence de défauts ou d'échecs. Inversement, la présence de défauts ou d’échecs n’implique pas qu’une réglementation empêcherait ces défauts ou ces échecs. Les ingénieurs en logiciel sont déjà très réglementés en tant que membres des industries respectives critiques pour la sécurité, et en dehors de ces industries, ils sont peu nécessaires.

Karl Bielefeldt
la source
10
+1 pour "Les ingénieurs en logiciel sont déjà fortement réglementés en tant que membres des industries respectives critiques pour la sécurité, et en dehors de ces industries, il y a peu de nécessité"
Trevor Boyd Smith
3
Je n'aime pas le ton cynique de cette réponse. Voulez-vous dire qu'il n'y a pas besoin de réglementation, puisque la réglementation ne résout jamais aucun problème?
Fred Foo
8
Je dis qu'au-delà d'un certain point, plus de réglementation résout rarement plus de problèmes. Imposer certaines pratiques de test de logiciel sur des machines capables de tuer des gens est logique. Passer un autre examen de certification des compétences de base à la fin d'un programme menant à un diplôme ne fait qu'ajouter à la bureaucratie.
Karl Bielefeldt
2
@ Larsmans Je suis d'accord avec Karl. Si le gouvernement utilise un missile ou un objet pour lequel il estime que des normes élevées devraient être imposées, laissez-le engager ses propres programmeurs et ingénieurs conformément à la norme de son choix. Le secteur privé ne devrait de toute façon pas gagner de l'argent avec le risque public - c'est du fascisme. Une industrie privée ne devrait pas être autorisée à mettre en danger le public. Les personnes qui savent ce dont elles ont le mieux besoin sont celles qui prennent le risque. Laissez-les gérer leurs propres affaires. Et oui, je sais que lockheed-martin et les autres font cela. Ils ne devraient pas être autorisés à bien.
Jonathan Henson
3
Compte tenu du nombre de grandes entreprises qui ont perdu des informations sur leurs cartes de crédit au cours des 12 derniers mois, je dirais qu’il n’ya pas d’autoréglementation satisfaisante. Vous pourriez faire valoir que ces systèmes ne sont pas essentiels à la vie - mais l'impact sur les poches des gens peut être tout aussi difficile à la suite de ces incidents.
HorusKol
32

L'histoire a montré, à juste titre je crois, que la différence entre un excellent artisan et un médiocre ne peut être testée avec aucune forme de mesure objective. Les connaissances de base ne font pas un bon programmeur, la sagesse et l'expérience - ce qui ne peut pas vraiment être enseigné ou mesuré de manière objective - de la manière d'appliquer ces connaissances de base.

En outre, ces tests finissent généralement par ne comporter que quelques mots à la mode et des procédures concrètes et ne permettent pas de mesurer quoi que ce soit de fond pour commencer.

Si l'industrie du logiciel souhaitait créer une guilde, ce serait une bien meilleure façon d'aborder le problème. Cependant, la centralisation n'a que le pouvoir de détruire l'excellence: ne pas la créer.

De plus, les problèmes que cette mesure tente de prévenir ne seraient probablement pas couverts par un test de toute façon. Quoi qu'il en soit, j'aimerais aussi voir @ThomasOwens répondre à cette question.

Quel serait le rôle du gouvernement, du moins de l'idéologie américaine, serait de tenir les éditeurs de logiciels responsables de tout dommage matériel causé par un logiciel défectueux ou non sécurisé. Cela inciterait les entreprises à appliquer leurs propres normes et à assumer la responsabilité personnelle en la matière. C'est toujours une meilleure solution, et elle ne contient pas de gouvernement centralisé dépassant ses limites.

Mise à jour

J'y pensais un peu plus hier soir avec une bière ou dix.

Tout ce que réglementait le domaine médical était d'exterminer tous les paradigmes sauf un. Si leur objectif était d'éliminer les médecins homéopathes et naturopathes, que l'opérateur a gentiment qualifiés de "charlatans", cette réglementation a été couronnée de succès. Cependant, je ne suis pas d'accord pour dire qu'une telle chose est rentable pour quiconque à l'exception des rédacteurs du projet de loi. Pensez à ce que cela a fait. Il a entraîné le coût des soins de santé à des niveaux insoutenables, considérablement accru les niveaux de responsabilité des médecins et supprimé du marché tout pouvoir de choix et d'autodétermination du consommateur. Il n’existe plus de marché pour les idées dans la communauté médicale et de nouveaux traitements et méthodes de réflexion sur la médecine sont maintenant supprimés. En outre, la barrière d’entrée sur le terrain est incroyablement élevée, ce qui entraîne une pénurie de médicaments de qualité médicale. s. En outre, les organismes de réglementation ont le pouvoir de contrôler l'offre de médecins afin de pouvoir contrôler à leur tour le prix que les médecins paient.

Nous avons certes obtenu des gains du règlement médical, mais les coûts sont tout à fait trop élevés.

La même chose va arriver aux ingénieurs logiciels si une telle réglementation est adoptée. Je peux le voir maintenant, les organismes de réglementation décideront que la programmation orientée objet est la seule norme de conception et les programmeurs fonctionnels et procéduraux ne seront pas autorisés à pratiquer. Ensuite, ils commenceront à nous dire que nous ne sommes pas autorisés à gérer notre propre mémoire car elle n’est pas sûre. Ensuite, ils écraseront tous nos gorges avec JAVA et C # et nous diront que nous devons l’utiliser pendant que Oracle et Microsoft deviennent plus gros et plus heureux. L'innovation sera étouffée et la créativité sera interdite. Microsoft et Google écriront la législation, donc les règles du marché seront orientées vers leur propre rentabilité et contre le bien-être social.

En outre, permettez-moi de rappeler à tout le monde que les ordinateurs ont commencé comme un projet universitaire et universitaire. Outre les guerres Unix des années 80 et du début des années 90, nous avons des systèmes d’exploitation gratuits, des compilateurs gratuits, des programmes gratuits, etc., et cela prend fin rapidement. Le monde que Richard Stallman, Linus Torvalds et Dennis Richtie nous ont légué disparaîtra progressivement.

En résumé, est-ce que je suis fatigué de devoir concurrencer "je vais vous concevoir un site wordpress CMS à 25 $ l'heure" ou "n'importe quelle application iPhone à 500 $"? Pas vraiment, pourquoi? Parce que je suis sacrément bon dans ce que je fais et que les clients que je veux sont prêts à payer pour l’excellence. Lorsque j'entreprends un projet indépendamment ou sur mon lieu de travail, je prends le risque de mes erreurs sur ma tête et ma réputation. Cela me suivra partout où je vais. En outre, la plupart des gens savent qu'ils en ont pour leur argent. Un client qui est seulement disposé à me payer le prix qu’il paye à son préposé à la pelouse va être un cauchemar à gérer de toute façon. Si le gouvernement fixait la structure juridique pour obliger les fournisseurs de services à indemniser leurs dommages, très peu de mauvais programmeurs auraient encore un emploi sur le terrain.

En passant, nous avons toujours de mauvais médecins, la seule différence est qu’il existe très peu de forces pour les retirer du marché. S'ils devaient assumer la responsabilité de leurs propres actes, ils seraient en faillite avant d'avoir une autre chance de causer des ravages incompétents à leurs clients.

Jonathan Henson
la source
8
Bien que je souscrive à l'objectif général de votre déclaration, je trouve que la partie la plus intéressante de celle-ci est la toute première phrase. Vous caractérisez le développement logiciel comme un métier , ce qui est exactement le problème . On n'a pas CRAFT un pont suspendu; on conçoit un pont suspendu pour assurer son efficacité et sa sécurité. Les ingénieurs en logiciel agissent toujours plus comme des artisans que des ingénieurs, quel que soit le titre que vous leur donnez.
Eric Lippert
4
@ Jonathan Henson: Ce n'est certainement pas le cas, en général. Beaucoup de magasins ont un score de zéro au test Joel. ( joelonsoftware.com/articles/fog0000000043.html ) S'ils le devraient ou non , il s'agit d'une décision commerciale et non d'une décision morale. Toutes ces choses coûtent de l'argent: beaucoup, beaucoup d'argent. Si vous construisez un système de contrôle d'aéronef, il est rentable à long terme d'assumer ces coûts; si vous construisez un jeu facebook, peut-être pas.
Eric Lippert
1
Non, un tampon d'architecte est aussi bon qu'un tampon PE. Je dirais certainement que nous devons incorporer beaucoup de choses que l’on appelle actuellement les disciplines de l’ingénierie, comme le fait un architecte. L'architecture est toujours considérée comme plus d'un métier bien. Quoi qu'il en soit, l'ingénierie est probablement un métier aussi, alors je me contenterais peut-être de mots pour rien.
Jonathan Henson
1
@Andy, je suppose que nous devrions demander à stack exchange de changer le titre de ce site en softwareengineers.stackexchange.com :)
Jonathan Henson Le
1
@ JonathanHenson Offend? Aucun moyen, ne vous inquiétez pas! :) J'aurais dû préciser un peu plus que j'ai posté le lien juste parce qu'il coïncidait étrangement avec votre commentaire.
Yannis
23

Silicon Valley News - 31 juin 2015

Horreur: Abandon de programme par un programmeur non certifié

"Je ne pourrai plus jamais courir", lance la victime. La police enquête.

Criminel: licence du Dr H. Acker Jr. révoquée pour utilisation incorrecte du pointeur et tentatives de lecture à partir du fichier système

L'avocat dit qu'il y aura un appel devant la Cour suprême.

Annonces: les programmeurs Cobol certifiés en 1975 doivent se recertifier au plus tard en 2025

IEEE a confirmé que la certification n'avait pas changé depuis.

Ads: Certification garantie avec Magic Knowledge Stuffers, Inc

Enseignez-vous à la programmation en 21 jours.

moucheron
la source
J'essaie de décider s'il s'agit d'une réponse complète insite ou d'un commentaire humoristique. (Les deux peut-être?)
Lyndon White
@Oxinabox 31 Juin jour est plein d' humour
moucheron
"Apprenez-vous à programmer en 10 jours!" hehe
BЈовић
20

Il existe différentes manières d’appliquer une réglementation à une profession: un corpus de connaissances bien défini, un code de déontologie, l’accréditation des programmes de formation, la certification et l’octroi de licences, et des sociétés professionnelles appuyant le développement professionnel, ainsi que les autres aspects de la métier. Le génie logiciel a la plupart des caractéristiques d'un métier.

J'aime penser que cela commence avec le corpus de connaissances en génie logiciel (SWEBOK) et le code de déontologie et de pratique professionnelle en génie logiciel . Bien que l'acceptation commune de ceux-ci soit encore assez limitée, je pense qu'ils constituent un bon point de départ pour identifier les types de choses qu'une personne s'identifiant en tant qu'ingénieur en logiciel devrait connaître et comment elle devrait agir à titre professionnel. Cela ne veut pas dire que ce sont des règles strictes, mais plutôt que ces documents aident les ingénieurs en logiciel professionnels à déterminer ce qui est généralement pertinent pour le travail qui pourrait leur être demandé. Le SWEBOK est révisé de temps en temps pour s’assurer qu’il reste pertinent.

La caractéristique suivante est l'accréditation des programmes d'éducation. Aux États-Unis, l’accréditation des programmes de génie logiciel est gérée par ABET . Ils accréditent également l'informatique, les technologies de l'information, le génie informatique et d'autres professions liées à l'informatique. ABET affiche ses exigences en matière de programmes accrédités sur son site Web. L'ingénierie logicielle est considérée comme un programme d'ingénierie. L’accréditation a pour but d’assurer la cohérence entre les diplômés de différents programmes d’ingénierie, du moins en ce qui concerne la matière enseignée en classe. Cela ne dit rien sur la qualité de l'éducation.

Après l’obtention du diplôme, la certification et les licences sont utilisées pour évaluer les connaissances acquises en classe (et, dans certains cas, au travail) par rapport aux corps de connaissances standard. Bien que les écoles agréées aient un ensemble défini de matériel à enseigner, il n’est pas possible de déterminer dans quelle mesure ce matériel est enseigné et combien les élèves apprennent à la fin du programme. La certification et les licences fournissent des méthodes pour le faire - tout le monde passe les mêmes examens et démontre une connaissance des divers corps de connaissances qui ancrent la profession. En génie logiciel, l'IEEE offre des certifications qui sont enracinées dans le SWEBOK - le développement de logiciel certifié Associé pour les aînés et les diplômés récents et le Certified Software Development Professionalpour ceux qui ont de l'expérience dans l'industrie. Pour que ceux-ci apportent une valeur ajoutée, il faut que le SWEBOK soit accepté comme une bonne définition de ce qu'est le génie logiciel.

Enfin, les sociétés professionnelles gèrent les documents d'orientation de la profession, facilitent les conférences et les publications pour l'échange de connaissances et d'idées, établissent des ponts entre le monde universitaire et l'industrie, etc. Les sociétés IEEE Computer Society et ACM sont les deux sociétés phares , mais il en existe d'autres dans le monde. Ceux-ci rassemblent tout dans un joli petit paquet et aident à fournir des informations aux bonnes personnes.

A partir de là, il y a d'autres questions à poser. Le développement de logiciels est-il une discipline d'ingénierie? La certification ou l'octroi de licence ajoute-t-il de la valeur aux ingénieurs en logiciel? La certification est-elle utile?

Je ne pense pas que tout développement logiciel nécessite la rigueur d'une discipline d'ingénierie. Cela ne veut pas dire qu'une étude empirique et scientifique de la science et de l'ingénierie des logiciels de construction n'aide pas tout le monde - c'est le cas. Cependant, il existe une grande différence entre développer le dernier jeu vidéo, développer le logiciel intégré pour un stimulateur cardiaque ou construire le prochain engin spatial. L'accent est différent sur chacun d'eux - deux des trois méritent l'attention d'un ingénieur qualifié. L'autre peut apprendre des pratiques d'ingénierie, mais n'a pas besoin de compter sur elles pour mener à bien le projet.

La certification et la licence nécessitent un ensemble de connaissances accepté. Le SWEBOK est un bon document qui fournit une base solide, mais il n’est pas largement accepté. À moins que vous puissiez baser vos programmes universitaires et vos examens de certification / licence sur quelque chose de concret qui serait accepté par les praticiens, cela ne sert à rien. Si le SWEBOK ou le document alternatif est largement accepté (du moins dans les domaines qui requièrent la rigueur de l'ingénierie), des examens de certification ou de licence peuvent être utilisés pour évaluer la compréhension des connaissances requises.

Cependant, il y a un problème criant avec la certification: c'est un test sur un livre. Certaines personnes savent lire, apprendre, mémoriser et passer un test. Cependant, cela ne signifie pas qu'ils sont un bon ingénieur. Les gens se faufilent tout le temps. Une certification ou une licence n'est qu'une étape. La formation en cours d'emploi et l'encadrement par d'autres ingénieurs expérimentés sont obligatoires pour former un bon praticien. En outre, la capacité d'empêcher des personnes de pratiquer dans des environnements critiques peut également contribuer à atténuer les risques pour la société et les entreprises.

Le développement de logiciels professionnels de Steve McConnell : calendriers plus courts, produits de meilleure qualité, projets plus aboutis et carrières améliorées est un bon livre avec une discussion assez approfondie à ce sujet .

Thomas Owens
la source
Je suis un peu sous le temps, donc si j'ai oublié quelque chose ou si quelque chose n'a pas de sens, piquez-moi et je vais le réparer. Merci les gars.
Thomas Owens
"deux des trois méritent l'attention d'un ingénieur qualifié" vous avez raison, les
vaisseaux
+1 merci pour votre contribution sur le sujet. J'espère que vous irez mieux.
Jonathan Henson
12

Si les réglementations gouvernementales sont adoptées, l'industrie des logiciels aux États-Unis se contractera considérablement, car les coûts associés au respect de ces réglementations seront plus élevés que ceux que les startups et les petites entreprises peuvent se permettre.

La rareté et les coûts associés à un diplôme en droit ou à un doctorat en médecine deviendront plus ou moins visibles dans notre secteur. Pas bon quand l’alternative est que chaque Joe peut potentiellement construire le prochain Facebook.

Les gens font des erreurs et aucune réglementation n'empêchera les catastrophes. Prenons la NASA, qui a de loin les exigences les plus strictes en matière de développement logiciel connues de l’homme. Ont-ils encore des bugs logiciels? (Oui, oui et plusieurs fois, oui!)

Le marché règle ces problèmes beaucoup mieux que la réglementation ne le peut. Les entreprises qui créent des logiciels à l'origine de problèmes sont tenues pour responsables par les personnes qu'elles ont blessées. Le reste d'entre nous n'a pas besoin de payer pour leurs erreurs.

George Stocker
la source
8
Un ajout fantastique à cette réponse serait une liste des éditeurs de logiciels existants qui n’auraient probablement pas été lancés si ces réglementations étaient en vigueur. Microsoft et Facebook sont un bon début, car une certification nécessiterait probablement un diplôme (presque chaque profession qui commence par le test ajoute une exigence de diplôme si elle n'en commence pas par un).
psr
1
@maple_shaft, l’OMI comparant les médecins / avocats au génie logiciel n’est pas valide. Les champs sont trop différents pour pouvoir être comparés (voir la réponse de Jarrod Nettles pour comprendre pourquoi vous ne pouvez pas comparer l'ingénierie logicielle à celle de médecins / avocats).
Trevor Boyd Smith le
1
@maple_shaft - Vous insinuez que la certification améliorerait la qualité de l'ingénierie. Je suis assez sceptique que ce serait le résultat. Je pense que le temps passé à étudier pour la plupart des tests n'est pas du temps passé à apprendre un meilleur ingénieur.
psr
4
Je pense que tout le monde part de l’hypothèse non prouvée que l’octroi de licences aux médecins et aux avocats améliore réellement la qualité des médecins et des avocats. Je suis très sceptique quant à cette hypothèse. Tout ce que la licence garantit, c’est que les médecins et les avocats perçoivent des frais exorbitants et qu’il n’ya aucune chose à faire pour rien. À cet égard, je suis tout pour les licences d'ingénieurs en logiciel. Cela n'améliorera pas la qualité des logiciels d'un iota, mais cela enrichira certainement beaucoup d'entre nous, développeurs de logiciels. Haha quand le gouvernement arrête le lycéen pour avoir utilisé un logiciel sans licence.
Dunk
1
@maple_shaft dépend entièrement de la nature de l'échec - Facebook ne répond pas n'est pas critique (au-delà des poches des investisseurs) - Facebook met tous vos détails personnels et vos messages privés à la disposition de chaque utilisateur d'internet. En outre, des applications / jeux prenant des informations de carte de crédit (comme sur Facebook), qui auraient accidentellement divulgué des informations de carte de crédit, auraient de graves répercussions.
HorusKol
11

En 1999, l'ACM a publié une déclaration sur les licences lorsqu'elle s'est largement retirée du travail IEEE SWEBOK. Après avoir examiné les documents SWEBOK disponibles au public et la déclaration de l'ACM, je soutiens l'opinion de l'ACM.

En jetant un coup d'œil à l'article, une personne de 4 à 6 ans d'expérience est nécessaire pour passer l'examen, qui teste les connaissances de base. C'est plus que ridicule, et il faut rire de la porte.

Paul Nathan
la source
10

Les composants logiciels d'un périphérique constituent un détail de la mise en œuvre. Par exemple, dans le secteur des systèmes de contrôle, tous les dispositifs de sécurité étaient câblés et les logiciels ne faisaient pas confiance aux utilisateurs. Cependant, nous voyons maintenant des dispositifs de sécurité logiciels tels que des relais de sécurité et des automates de sécurité. Celles-ci sont autorisées car elles doivent toujours respecter les réglementations de l'industrie relatives aux dispositifs de sécurité (en fonction de la catégorie de sécurité). Par conséquent, dans certains cas, les périphériques ont besoin de processeurs redondants et de code redondant écrits par deux équipes différentes, etc.

C'est le produit qui doit respecter les consignes de sécurité pour pouvoir être vendu et consommé par le public. Ces règles ne changent pas car le produit contient un logiciel. L’ingénieur a pour tâche de s’assurer que le produit répond à tous les critères réglementaires. S’il contient des logiciels, il doit alors examiner le logiciel et être compétent dans ce domaine . S'ils ne le sont pas, ils (ou leur entreprise) sont responsables s'ils ont approuvé la conception et que celle-ci s'avère défectueuse.

Vous n'avez pas vraiment besoin de réglementer tous les programmeurs simplement parce que certains produits doivent répondre à des exigences plus strictes. Dans les cas où de tels produits impliquent un logiciel, vous avez besoin d'une discipline d'ingénierie bien développée, capable de déterminer de manière fiable que le composant logiciel répond aux exigences. C'est ce que l'IEEE veut dire: le domaine relativement jeune du génie logiciel doit être développé de manière à atteindre le niveau de fiabilité et de confiance des autres disciplines du génie.

Cela n'a vraiment rien à voir avec la "programmation" et tout avec "l'ingénierie".

Ceci, bien sûr, nous ramène à la question controversée de la différence entre un développeur et un ingénieur. Ce sont généralement deux rôles différents qui se chevauchent régulièrement. La partie développeur signifie que vous créez des logiciels. La partie ingénierie du rôle signifie que si vous marquez la conception, vous prenez la responsabilité de la sécurité publique. Vous pouvez être l'un sans l'autre.

Scott Whitlock
la source
5
+1 à mon humble avis, ce que vous insinuez vraiment, c’est que la réglementation doit s’appliquer au produit, et non aux ingénieurs. Par exemple, les réglementations (approbations) requises pour les systèmes d'alarme incendie et anti-intrusion garantissent le bon fonctionnement du logiciel, et non la capacité des ingénieurs qui l'ont écrit. (Beaucoup de réglementations ressemblent beaucoup à celles des systèmes entièrement fabriqués à partir de circuits électroniques.)
jwernerny
8

Les logiciels sont déjà étroitement réglementés dans l'industrie aéronautique. Voir DO-178B .

Je suis sûr que d'autres sous-ensembles de l'industrie ont leurs normes.

"Logiciel" englobe tellement ces jours-ci. Je pense qu’il serait absurde d’avoir un quelconque règlement obligatoire.

Emilio M Bumachar
la source
4

La réglementation de l’industrie du logiciel s’effectue mieux par la réglementation des processus d’assurance qualité.

Ceci est déjà fait - les grands éditeurs de logiciels disposent de multitudes de testeurs, de responsables QA, de suites de tests automatisés, de processus de révision de code, de processus de test, etc. Certaines entreprises ont pour objectif de réaliser des audits de qualité logicielle sur d’autres entreprises. Les organisations de normalisation disposent de directives pour l’assurance qualité et les audits d’assurance qualité.

Au sein d'une entreprise, un ingénieur logiciel est responsable de la qualité de son travail. Leurs freins et contrepoids, cependant, sont dans les processus de qualité de l'entreprise.

Bringer128
la source
2
C'est exactement mon avis. L’industrie aéronautique a des règles strictes pour la programmation du contrôle qualité et des tests. Les entreprises doivent auditer leurs actifs informationnels et mettre en œuvre davantage de tests et d'analyses. Je pense que nous vivons une époque sombre en matière de logiciels, car beaucoup d’entre eux échappent encore aux décisions en ne faisant pas ce qu’ils savent être la bonne chose à faire, et les développeurs eux-mêmes ne suffisent pas pour changer l’industrie.
Tjaart
Excellent point - le logiciel qui exécute l’appareil relève de la responsabilité de l’entreprise pour une ingénierie sûre et de qualité, ainsi que de l’ingénierie industrielle.
Jarrod Nettles
3

C'est la même chose que la plupart des tentatives modernes de résolution de "problèmes liés aux logiciels". Ceux qui tentent de légiférer ont peu de connaissances sur le fond du problème. Si vous suivez le processus prescrit (et l'intention bien sûr) lors du développement de logiciels critiques pour la sécurité, que ce soit pour les avions ou les centrales nucléaires d'équipements médicaux, un seul bug ne suffira jamais à provoquer une panne. Un algorithme entier peut être implémenté de manière incorrecte sans que personne ne soit blessé.

La FDA et la FTA nécessitent à la fois une analyse des risques et une stratégie d’atténuation. Ce dernier est généralement une stratégie de fromage suisse dans lequel on accepte que toute mesure d'atténuation soit erronée. Ainsi, plusieurs mesures d'atténuation sont appliquées pour le même risque (une mesure d'atténuation peut également être appliquée à plusieurs risques). Chaque mesure d'atténuation est similaire à une tranche de fromage suisse à consulter. une, peut-être deux tranches assemblées, mais réunissez suffisamment de tranches et ce n’est plus possible. Même lorsque les mesures d'atténuation sont parfaitement mises en œuvre, cela ne garantit pas un équipement 100% sûr. Si l'analyse des risques est incorrecte, il y aura des risques auxquels personne ne pense (Y2K).

Vous pouvez tester les ingénieurs autant que vous voulez, même sur un sujet et nécessiter un niveau extrêmement élevé, mais cela importerait beaucoup. La plupart des erreurs critiques pour la sécurité sont des erreurs d'intégration. Ce ne sont pas des erreurs dans le code d'un utilisateur, mais résultent de désalignements entre le logiciel et le matériel de deux systèmes logiciels ou du fait qu'une particule alpha a projeté le compteur de programme hors de son emplacement approprié.

J'ai utilisé plusieurs systèmes critiques pour la sécurité avec des développeurs très expérimentés et capables, qui réussiraient n'importe quel test raisonnable dans leur domaine. Je ne suis jamais allé sur un projet où nous n'avions pas d'erreur critique de sécurité. (Heureusement, je n'ai jamais été sur un système où le système n'a jamais fait de mal à personne)

Rune FS
la source
1
+1 - Pour: "La plupart des erreurs critiques pour la sécurité sont des erreurs d'intégration." En fait, avec tout le processus que nous traversons, il n’ya presque jamais d’erreur de codage. 99,98% du temps, c'est un problème de compréhension entre différents modules et périphériques quant à la manière dont ils étaient censés fonctionner.
Dunk
@Dunk merci, c'est en fait une commande de Levison. Un fait que je voulais inclure dans le texte, mais il semblerait que j'ai oublié :)
Rune FS
2

On ne peut jamais éliminer complètement les charlatans et les charlatans, car ils existent dans presque toutes les professions, même les professions médicales, malgré les pratiques et les traditions bien établies.

Cependant, cette déclaration étant un accaparement de terres, je ne suis pas sûr de savoir quel sombre seigneur effrayant de tout ce qui se trouve dans l'informatique, il consulte de manière diabolique son contrôle et sa régulation sans entraves du développement logiciel. Si vous parlez de l'IEEE, ils ont certes un aspect réglementaire, mais le respect des normes IEEE se fait plus ou moins à leur guise, et non sous la menace d'une arme. Ils essaient d'élaborer des normes universelles de l'industrie afin que nous parlions tous le même langage et améliorions l'efficacité à tous les niveaux.

En outre, les normes qu’elles établissent aident à légitimer les pratiques courantes et à jeter les bases du développement de logiciels afin de devenir un domaine plus discipliné de l’ingénierie, un peu comme le génie mécanique ou le génie chimique. Bien que les logiciels se rapprochent de cet objectif, ils ne seront probablement jamais une universalité universellement acceptée.

Le principal problème est qu’un développeur de logiciel peut faire quelque chose, de l’écriture d’un joli widget de bureau à la mise en œuvre de systèmes de guidage par missile. Dans l’un, la gravité et les conséquences de l’erreur sont beaucoup plus graves que dans l’autre, ce qui exige une discipline technique rigoureusement réglementée pour une approche raisonnable, sûre et efficace. Cela ressemble beaucoup à la gravité des erreurs dans un pont mal conçu, ce qui entraîne son effondrement. Les concepteurs du pont doivent respecter mes normes d'ingénierie pour assurer la qualité.

maple_shaft
la source
4
Habituellement, de telles réglementations finissent par être des exigences légales. Par exemple, le génie civil nécessitant un PE
Paul Nathan
@PaulNathan Bon point, c'est pourquoi la progression naturelle vers une discipline universellement acceptée commence par l'autoréglementation (par exemple, la MPAA) et débouche finalement sur une réglementation légale (conseils d'État, FCC, etc.)
maple_shaft
7
Je ne crois pas que le développement de logiciels soit prêt pour l’autorégulation, ou même presque. Franchement, l'idée que les "vrais ingénieurs" ont "une vraie qualité" est pour moi une blague. Les navettes spatiales ont explosé, des roquettes ont pris feu, des ponts se sont effondrés, des bâtiments se sont effondrés, etc. Ce serait bien d'essayer d'imposer la qualité d'en haut, mais, haha.
Paul Nathan
1
En comparant l'ingénierie mécanique à l'ingénierie logicielle, je me demande ce que l'analogue d'ingénierie du monde réel pourrait être par rapport à un système d'exploitation moderne.
FrustratedWithFormsDesigner
1
@maple_shaft - le problème principal est que vous ne pouvez pas utiliser Linux / BSD / grep / vi / Firefox, etc., car ils ne sont pas écrits par un SE officiel. Alors que quelqu'un avec un cert MSCE en VB sera OK.
Martin Beckett
1

Je n'appellerais pas cela une réglementation plus stricte, mais plutôt des barrières à l'entrée. À cet égard, je pense qu'il y a du mérite. Pour une qualité accrue, c'est très discutable.

Actuellement, tout John / Jane Doe peut écrire un programme. Il n'y a pas de barrière pour l'entrée. Procurez-vous quelques livres sur les scripts et la technologie Web et commencez à vous débrouiller, ou pire encore, démarrez Google pour savoir comment le "faire".

Quand nous, en tant que collectivité, décidons qu'il est peut-être temps d'augmenter les barrières à l'entrée, d'obliger l'industrie à se conformer à des normes plus strictes, de passer de pirate informatique / d'artisan à ingénieur, ce genre de réglementation que je suis tout à fait.

Il y a trop de programmeurs individuels non qualifiés aujourd'hui. Qu'ils travaillent ou non sur des systèmes critiques, ils produisent toujours du code, tout en produisant de grandes boules de boue .

À cet égard, l’autorégulation ou, plus judicieusement, la création de barrières à l’entrée est une bonne chose. Parce que nous disons, hé, vous ne pouvez pas simplement sortir de la rue et vous appeler un ingénieur en logiciel. Vous devez réellement démontrer un niveau de compétence.

La compétence de démonstration ne consiste pas simplement à passer un test ou à obtenir un "badge d’honneur". Un test est juste une validation. La véritable validation, c’est l’école, les stages, l’apprentissage, le mentorat pour personnes âgées, la pratique, en fait partie.

Je peux voir ce que l'IEEE tente de réaliser, mais pour le moment, il s'agit d'un exercice infructueux. L'industrie évolue rapidement, avec une demande excessive de produits, la mentalité de "pirate informatique", etc. La réglementation doit venir de l'intérieur, voire pas du tout.

Jon Raynor
la source
Je donne +1 car il devrait exister un moyen de ne pas se mêler de certains types de systèmes. Cependant, je donne -1 parce que la plupart des logiciels actuels peuvent être développés de manière adéquate par des pirates informatiques et les empêcher de pouvoir fournir ce service afin de réduire les coûts est contraire à l'intérêt public. De même, il en va de même pour les avocats et les médecins. 90% de ce qu'ils font peuvent être traités de manière très rentable et avec autant de compétence par des personnes moins qualifiées. Cependant, avec les lois actuelles, ils sont libres de frapper le public à leur guise.
Dunk
Les compétences ne devraient pas être évaluées au cours du processus d'embauche. Oh, attendez, les ressources humaines recrutent des personnes sur la base de références papier (qui ne démontrent pas les connaissances requises pour le développement de logiciels) et les ressources humaines ne savent absolument rien des besoins / exigences en matière de développement de logiciels. Double échec ...
Evan Plaice
0

Je n'ai pas lu l'article, mais si la question est de savoir si la réglementation de l'industrie du logiciel peut profiter à l'humanité, je pense que cela dépend des circonstances:

  1. L’industrie dans son ensemble englobe une grande variété de domaines, dont certains sont critiques (par exemple, le contrôle de la dose de rayonnement dans un dispositif médical) et d’autres non (l’application Facebook "Qui sommes-nous?"). Je ne vois pas d'argument en faveur d'une réglementation pour les applications où les enjeux sont faibles.

  2. Il ne faut pas commencer par une réglementation légale. Au lieu de cela, il convient de commencer par un programme de certification pour les développeurs. Ce n'est que si le programme de certification produit un bénéfice mesurable qu'il devrait être question de réglementation légale.

  3. Même si un programme de certification produit des résultats mesurables, il est probable que l'industrie normaliserait l'exigence de cette certification pour des raisons strictement commerciales, et nous n'aurions pas besoin d'une réglementation légale. (C’est la raison pour laquelle des délégations comme MCSE existent - les entreprises préfèrent embaucher des MCSE pour les domaines dans lesquels elles sont formées.)

  4. Cela étant dit, il reste encore des domaines dans lesquels il est logique de causer un préjudice (il s'agit souvent d' externalités négatives , parfois du fait du pouvoir de marché de certaines institutions). Par exemple, une région peut avoir un seul hôpital local; Dans ce cas, la qualité du logiciel back-end peut faire une énorme différence quant au niveau de soins qu'un patient reçoit, mais ne fait pas une grande différence quant à l'hôpital choisi par le patient. L’hôpital n’a alors pas nécessairement beaucoup d’argent commercial pour investir dans des développeurs de meilleure qualité. Dans ce cas, il peut y avoir un cas de santé publique pour réglementer les développeurs que l'hôpital est autorisé à embaucher.

A MON HUMBLE AVIS.

Aidan Cully
la source
0

Je dois répondre à celui-ci ...

En commençant par ce que @JonathanHenson a dit et l'entrée de @gnat, ce que je dis est ok, les gens qui ont de l'argent peuvent payer pour des choses certifiées, les personnes ou les pays qui n'ont pas d'argent ne peuvent pas payer pour des licences (tant pour des choses certifiées ), donc il y aura toujours des renégats si cela entre en pratique. Même si les méthodes de livraison traditionnelles (et moins traditionnelles) sont fermées, les gens trouveront toujours des moyens de fournir des logiciels aux utilisateurs intéressés. Même s’il s’agit de développer un autre protocole HTTP ou même une pile de réseau complète alternative, nous nous efforcerons uniquement de rendre les connexions indétectables (voir le dernier paragraphe pour les personnes susceptibles de le faire).

De plus, l'idée de payer pour quelque chose est à risque, car le monde s'appauvrit de plus en plus, de plus en plus de gens auront de moins en moins d'argent pour payer des choses, il y a même des pays qui utilisent seulement des logiciels libres, sans aucun certification (le Brésil et l’Inde me viennent à l’esprit, mais il y en a sûrement d’autres), et certains de ces pays deviennent très gros. Et ils utilisent des logiciels non certifiés conçus par des programmeurs inconnus et dont les compétences sont inconnues.

En outre, même s’il existe un type de certification, celle-ci certifiera uniquement les connaissances, pas l’éthique; il suffit de penser que certains médecins utilisent des organes qui sont prélevés de manière non autorisée sur des personnes. Il y aurait donc aussi des programmeurs certifiés qui n'ayez aucune éthique et écrivez un code bâclé, intentionnellement ou non. Tandis que dans la plupart des projets FOSS, la plupart des programmeurs potentiellement non qualifiés révisent également le code des autres et essaient de trouver des erreurs, de manière à rendre la programmation par paires quelque chose de petit.

Enfin, que dites-vous des groupes de piratage (pas de groupes de hackers à chapeau noir, mais de groupes à chapeau blanc ou gris), qui en savent beaucoup plus sur la sécurité et développent des logiciels de sécurité de manière à ne faire correspondre que les programmeurs les plus spécialisés de certains ministères.

Coyote21
la source