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

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 ¹ 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?

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

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.

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.

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.

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.

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 .

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.

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.

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.

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.

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.

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)

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é.

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.

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.

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.