Réglementation de l'industrie du logiciel
Toutes les quelques années, quelqu'un propose une réglementation plus stricte pour l'industrie du logiciel.
Ce article IEEE a récemment attiré l'attention sur le sujet.
Si les ingénieurs logiciels qui écrivent des programmes pour des systèmes qui exposent le public à des risques physiques ou financiers savaient qu'ils seraient testés sur leurs compétences, la pensée va, cela réduirait les défauts et les défaillances du code - et sauverait peut-être quelques vies dans le marché.
Je suis sceptique quant à la valeur et au mérite de cela. À mon avis, cela ressemble à un accaparement de terres par ceux qui l'ont proposé.
La citation qui en ressort pour moi est la suivante:
L'examen testera les connaissances de base et non la maîtrise du sujet
parce que les gros échecs (par exemple THERAC-25 ) semblent être des problèmes complexes et subtils que les "connaissances de base" ne seraient jamais suffisantes pour éviter.
Ignorer les problèmes locaux (tels que les protections existantes du titre Ingénieur dans certaines juridictions):
Les objectifs sont nobles - éviter les charlatans/charlatans1 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 la réglementation de la profession médicale était censée le faire.
L'opinion selon laquelle les ingénieurs logiciels 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 essaient de résoudre. Avant de donner mon avis à ce sujet, permettez-moi de détailler certains des arguments de M. Thornton, vice-président de l'organisme de réglementation qui propose ce projet de loi.
"Tout comme les professionnels en exercice tels que les médecins, les comptables et les infirmières sont titulaires d'une licence, les ingénieurs logiciels devraient en faire autant", déclare Thornton. "Le public doit pouvoir s'appuyer sur une sorte de justificatif d'identité lors du choix d'un entrepreneur pour écrire un logiciel."
- Mitch Thornton, vice-président de la licence et de l'enregistrement de l'IEEE
Cela semble très raisonnable en surface. Après tout, il existe d'autres secteurs qui pourraient être considérés comme "réglementés avec succès". Par réglementé avec succès, je veux dire que si vous recherchez 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 et a passé un certain nombre d'examens et terminé une résidence. Voici quelques industries "réglementées avec succès" (en termes de personnel professionnel).
- Avocats
- Médecins
- Comptables
- Ingénieurs nucléaires
- Barbiers ( sans blague )
Après tout, vous ne voulez pas que quiconque retire 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 ne devraient-elles pas exister pour les ingénieurs logiciels?
Seuls ceux dont les programmes pourraient "mettre en danger la santé ou la sécurité publique, la sécurité, la propriété ou l'économie devront être testés".
Il s'agit d'une déclaration 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 fais tomber le site avec mon incompétence, je pourrais endommager l'économie américaine? Lors de mon dernier travail, j'ai accidentellement fermé un élévateur à grains avec un cron défectueux - ce qui peut mettre en danger l'approvisionnement alimentaire.
Je me rends compte que j'évite l'intention réelle de cette proposition. L'idée derrière cela est de s'assurer que la personne qui écrit le code du système de freinage antiblocage sur votre nouvelle Jetta est compétente et correctement autorisée à écrire le code d'un système de freinage antiblocage. Sur votre Jetta.
Voici le problème: le génie logiciel de nos jours englobe tout et vous ne pouvez pas tester pour toutes les disciplines. Les règles commerciales sont trop spécifiques et trop variées 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 complètement différent pour le système ABS sur une Elantra. Doit-il être recertifié?
Et si vous testez toutes ces disciplines dérivées? Supposons un instant que chaque programmeur qui travaille sur un site Web de commerce électronique soit certifié comme programmeur capable de commerce électronique. Donc? Est-ce que cela signifie soudainement que ces programmeurs et ces entreprises vont réellement faire la validation nécessaire et la mise en conformité PCI? Même s'ils le font, des problèmes surviendront toujours.
L'examen permettra de tester les connaissances de base, et non la maîtrise de la matière, selon Mitch Thornton, vice-président du comité de licence et d'enregistrement de l'IEEE.
Voici le kicker. Un manque de connaissances de base n'est jamais le problème. Mes freins antiblocage n'ont pas cessé de fonctionner parce que Chuck se débattait avec les concepts d'une structure de contrôle. Ils ont échoué car il y avait un problème où l'ABS s'est désactivé en raison d'un court-circuit électrique dans les feux arrière et l'alimentation n'a pas été correctement redirigée. Ou quelque chose.
Le logiciel de pompe à insuline que j'ai écrit n'a pas cessé de fonctionner parce que je n'ai pas les compétences de base; il s'est arrêté parce qu'il y avait un bug 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 je ne l'ai pas fait.
C'est quelque chose que vous pouvez prendre en compte dans le développement, mais vous ne pourriez jamais tester 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 l'ABS ou de la pompe à insuline.
Quelle chance que personne ne meurt grâce à la réglementation médicale, personne ne soit blessé par la fraude grâce à la réglementation financière, personne n'a sa maison saisie grâce à la réglementation du logement, personne ne se fait couper les cheveux grâce à la réglementation du barbier et aucun avion ne s'écrase grâce à la régulation 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 de défaillances n'implique pas qu'une réglementation empêcherait ces défauts ou défaillances. Les ingénieurs logiciels 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, il n'y a pas grand besoin.
L'histoire a montré, à juste titre je pense, que la différence entre un excellent artisan et un artisan médiocre ne peut être testée avec aucune forme de mesure objective. Les connaissances de base ne font pas un grand programmeur, une sagesse et une expérience - qui ne peuvent pas vraiment être enseignées ou mesurées objectivement - de la façon d'appliquer ces connaissances de base.
En outre, ces tests finissent généralement par être quelques mots à la mode et des procédures concrètes et ne parviennent pas à mesurer quoi que ce soit de substantiel pour commencer.
Si l'industrie du logiciel voulait créer une guilde quelconque, 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: pas de la créer.
De plus, les problèmes que cette mesure tente de prévenir ne seraient probablement pas détectés de toute façon. Quoi qu'il en soit, j'aimerais aussi voir @ThomasOwens répondre à celle-ci.
Quel serait le rôle du gouvernement, du moins selon l'idéologie américaine, serait de tenir les éditeurs de logiciels responsables de tout dommage matériel causé par leur logiciel défectueux ou non sécurisé. Cela encouragerait les entreprises à appliquer leurs propres normes et à assumer la responsabilité personnelle de la question. C'est toujours une meilleure solution, et elle ne contient pas un gouvernement centralisé dépassant ses limites.
Mise à jour
J'y pensais encore plus hier soir autour d'une bière ou de dix.
Tout ce que la réglementation du domaine médical a fait, c'est d'exterminer tous les paradigmes sauf un. Si leur objectif était d'éliminer les médecins homéopathes et naturopathes, que le p.p. aimablement appelés "charlatans" alors une telle réglementation a réussi. Cependant, je ne suis pas d'accord qu'une telle chose soit rentable pour n'importe qui, sauf pour les personnes qui rédigent la loi. Pensez à ce que cela a fait. Il a fait monter le coût des soins de santé à des niveaux insoutenables, a considérablement augmenté les niveaux de responsabilité des médecins et a supprimé tout pouvoir de choix et d'autodétermination du consommateur sur le marché. Il n'y a plus de marché pour les idées dans la communauté médicale, et de nouveaux traitements et façons de penser la médecine sont désormais supprimés. En outre, la barrière à l'entrée sur le terrain est incroyablement élevée et, par conséquent, nous manquons de bons M.D.s. En outre, les organismes de réglementation ont le pouvoir de contrôler l'offre de médecins afin qu'ils puissent à leur tour contrôler le prix payé aux médecins.
Il y a en effet certains gains que nous avons reçus de la réglementation médicale, mais les coûts sont tout à fait trop élevés.
La même chose arrivera 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 entasseront Java et C # dans toutes nos gorges et nous diront que nous devons l'utiliser pendant qu'Oracle et Microsoft deviennent plus gros et plus heureux. L'innovation sera étouffée et la créativité sera proscrite. Microsoft et Google rédigera la législation, de sorte que les règles du marché seront orientées vers leur propre rentabilité et contre le bien-être social.
Aussi, permettez-moi de rappeler à tout le monde que les ordinateurs ont commencé comme un amateur et un 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. ... Cela prendrait rapidement fin. Le monde que Richard Stallman, Linus Torvalds et Dennis Richtie nous ont légué disparaîtra progressivement de l'existence.
En résumé, est-ce que je me lasse d'avoir à rivaliser avec "Je vais vous concevoir un site CMS wordpress pour 25 $ par heure" ou les "n'importe quelle application iPhone pour 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. Quand je prends un projet de façon indépendante ou sur mon lieu de travail, je prends le risque de mes f * & ^ ups sur ma propre tête et ma réputation. Cela me suivra partout où je vais. De plus, la plupart des gens savent qu’ils en ont pour leur argent. Un client qui ne veut me payer que le prix qu’il paie à son gazon va être un cauchemar Si le gouvernement fixait la structure juridique pour obliger les prestataires de services à compenser leurs dommages, alors il y aurait très peu de mauvais programmeurs qui auraient encore un emploi sur le terrain.
Soit dit en passant, nous avons encore de mauvais médecins, la seule différence est qu'il y a très peu de forces pour les retirer du marché. S'ils devaient prendre la responsabilité de leurs propres actions, ils feraient faillite avant d'avoir une autre chance de faire des ravages incompétents sur leurs clients.
Nouvelles de la Silicon Valley - 31 juin 2015
Horreur: Un programmeur non certifié a fait avorter un programme
"Je ne pourrai plus jamais courir", sort la victime. La police enquête.
Criminel: révocation de la licence du Dr H. Acker Jr. pour mauvaise utilisation du pointeur et tentatives de lecture à partir du fichier système
L'avocat dit qu'il va y avoir un appel devant la Cour suprême.
Annonces: les programmeurs Cobol certifiés en 1975 devraient recertifier au plus tard en 2025
L'IEEE a confirmé que la certification n'a pas changé depuis.
Annonces: Certification garantie avec Magic Knowledge Stuffers, Inc
Enseignez-vous la programmation en 21 jours.
Il existe plusieurs façons d'appliquer la réglementation à n'importe quelle profession - un ensemble de connaissances bien défini, un code d'éthique, l'accréditation des programmes d'éducation, la certification et l'octroi de licences, et des sociétés professionnelles qui soutiennent le développement professionnel ainsi que les autres aspects d'un profession. Le génie logiciel présente la plupart des caractéristiques d'une profession.
J'aime penser que cela commence par Corpus de connaissances en génie logiciel (SWEBOK) et Code d'éthique et de pratique professionnelle en génie logiciel . Bien que leur acceptation commune soit encore assez limitée, je pense qu'ils servent de bonne base pour identifier les types de choses que quelqu'un qui s'identifie comme ingénieur logiciel devrait avoir une connaissance et comment une telle personne devrait agir à titre professionnel. Cela ne signifie pas que ce sont des règles strictes, mais plutôt ces documents guident les ingénieurs logiciels professionnels quant à ce qui est généralement pertinent pour le travail qu'ils pourraient être appelés à faire. Le SWEBOK est révisé de temps à autre pour s'assurer qu'il reste pertinent.
La prochaine caractéristique est l'accréditation des programmes d'enseignement. 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 leurs exigences des programmes accrédités sur leur site Web - le génie logiciel est considéré comme un programme d'ingénierie. Le but de l'accréditation est d'assurer la cohérence entre les diplômés des différents programmes d'ingénierie, au moins en termes de 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 l'octroi de licences sont utilisés pour évaluer les connaissances acquises en classe (et, dans certains cas, au travail) par rapport aux ensembles de connaissances standard. Bien que les écoles accréditées aient un ensemble défini de matériel à enseigner, il n'y a pas de mesure de la façon dont ce matériel est enseigné et du niveau d'apprentissage des élèves à la fin du programme. La certification et l'octroi de licences fournissent des méthodes pour ce faire - tout le monde passe les mêmes examens et démontre une connaissance des divers corps de connaissances dans lesquels la profession est enracinée. En génie logiciel, l'IEEE propose des certifications qui sont enracinées dans le SWEBOK - le Certified Software Development Associate pour les seniors et les jeunes diplômés et le Certified Software Development Professional pour ceux qui ont une expérience dans l'industrie. Pour que ceux-ci ajoutent de la valeur, cela nécessite l'acceptation du SWEBOK comme une bonne définition de ce qu'est l'ingénierie logicielle.
Enfin, les sociétés professionnelles conservent les documents d'orientation de la profession, facilitent les conférences et les publications pour l'échange de connaissances et d'idées, comblent les écarts entre le monde universitaire et l'industrie, etc. Les deux principales sociétés sont la IEEE Computer Society et la ACM , mais il existe d'autres sociétés dans le monde. Ceux-ci regroupent tout dans un joli petit paquet et aident à fournir des informations aux bonnes personnes.
De là, il y a d'autres questions à poser. Le développement de logiciels est-il une discipline d'ingénierie? La certification ou les licences ajoutent-elles une valeur aux ingénieurs logiciels? La certification est-elle utile?
Je ne pense pas que tout développement logiciel ait besoin de 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 - elle le fait. Cependant, il y a une grande différence entre développer le dernier jeu vidéo, développer le logiciel embarqué pour un stimulateur cardiaque ou construire le prochain vaisseau 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 s'appuyer sur elles pour mener à bien le projet.
La certification et l'octroi de licences 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 académiques et vos examens de certification/licence sur quelque chose de concret qui serait accepté par les praticiens, alors cela ne sert à rien. Si le SWEBOK ou un document alternatif est largement accepté (au moins dans les domaines qui nécessitent 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 flagrant 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 passent tout le temps à travers les mailles du filet. Une certification ou une licence n'est qu'une étape. La formation en cours d'emploi et le mentorat par d'autres ingénieurs expérimentés sont obligatoires pour préparer un bon praticien. En outre, la capacité d'empêcher les gens de pratiquer dans des environnements critiques peut également aider à atténuer les risques pour la société et les entreprises.
Un bon livre avec une discussion assez approfondie à ce sujet est celui de Steve McConnell Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, and Enhanced Careers .
Si les réglementations gouvernementales sont adoptées, l'industrie du logiciel aux États-Unis se contractera considérablement, car le coût associé à la conformité à ces réglementations sera plus élevé que les startups et les petites entreprises ne peuvent se le permettre.
La rareté et le coût associés à un diplôme en droit ou à un docteur en médecine deviendront plus ou moins visibles dans notre industrie. Pas bon quand l'alternative est que chaque joe pourrait potentiellement construire le prochain Facebook.
Les gens font des erreurs et aucune réglementation n'empêchera les catastrophes de se produire. 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 bogues logiciels? (Oui, oui, et plusieurs fois, oui!)
Le marché résout ces problèmes beaucoup mieux que la réglementation. Les entreprises qui créent des logiciels qui causent des problèmes sont tenues responsables par les personnes blessées. Nous n'avons 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 des travaux de l'IEEE SWEBOK. Après avoir examiné les documents SWEBOK accessibles au public et la déclaration ACM, je soutiens l'opinion de l'ACM.
En jetant un coup d'œil à l'article, une personne ayant 4 à 6 ans d'expérience est requise pour passer l'examen, qui teste les connaissances de base. C'est au-delà du ridicule et devrait être ri par la porte.
Les composants logiciels d'un appareil sont un détail d'implémentation. Par exemple, dans l'industrie des systèmes de contrôle, tous les dispositifs de sécurité étaient câblés et les gens ne faisaient pas confiance aux logiciels. 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 appareils nécessitent des processeurs redondants et du code redondant écrit par deux équipes différentes, etc.
C'est le produit qui doit respecter les consignes de sécurité s'il doit être vendu et consommé par le public. Ces règles ne changent pas car le produit contient un logiciel. C'est le travail de l'ingénieur de s'assurer que le produit répond à tous les critères réglementaires, et s'il contient un logiciel, alors ils doivent revoir 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ù ces produits impliquent des logiciels, vous avez besoin d'une discipline d'ingénierie bien développée qui peut déterminer de manière fiable que le composant logiciel répond aux exigences. En fait, c'est ce que signifie l'IEEE: le domaine relativement récent du génie logiciel doit être développé au niveau de fiabilité et de confiance des autres disciplines de l'ingénierie.
Cela n'a vraiment rien à voir avec la "programmation" et tout à voir avec "l'ingénierie".
Bien sûr, cela nous ramène à la question litigieuse 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 tamponnez la conception, vous assumez la responsabilité de la sécurité publique. Vous pouvez être l'un sans l'autre.
Les logiciels sont déjà strictement 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.
Le "logiciel" englobe tellement de nos jours. Je pense qu'il serait absurde d'avoir un règlement obligatoire global.
La régulation de l'industrie du logiciel se fait mieux par la régulation des processus d'assurance qualité.
Cela est déjà fait - les grandes sociétés de logiciels ont une multitude de testeurs, de gestionnaires d'assurance qualité, de suites de tests automatisés, de processus de révision de code, de processus de test, etc. Il existe des entreprises dont le but est d'effectuer des audits de qualité logicielle sur d'autres entreprises. Les organismes de normalisation ont des directives pour l'AQ et pour les audits d'AQ.
En interne à une entreprise, un ingénieur logiciel est responsable de la qualité de son travail. Leurs freins et contrepoids font cependant partie des processus 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 la racine 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é, sachez que pour les avions, les centrales nucléaires d'équipements médicaux, un seul bug ne sera jamais suffisant pour provoquer une panne. Un algorithme entier peut être implémenté de manière incorrecte sans que personne ne soit blessé.
La FDA et l'ALE nécessitent toutes deux une analyse des risques et, sur cette base, une stratégie d'atténuation. La dernière est généralement une stratégie de fromage suisse où l'on accepte que toute atténuation est défectueuse, donc plusieurs atténuations pour le même risque sont appliquées (une atténuation peut également être appliquée à plusieurs risques) chaque atténuation est comme une tranche de fromage suisse que vous pouvez regarder à travers une, peut-être deux tranches réunies mais réunissez suffisamment de tranches et ce n'est plus possible. Même lorsque les atténuations sont parfaitement mises en œuvre, cela ne donne pas un équipement 100% sûr. Si l'analyse des risques est incorrecte, il n'y aura des risques auxquels personne n'a pensé (Y2K).
Vous pouvez tester les ingénieurs tout ce que vous voulez, vous pouvez même tester sur le sujet et exiger 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 homme, mais elles sont dues à des désalignements entre le logiciel et le matériel de deux systèmes logiciels ou parce qu'une particule alpha a fait tomber le compteur de programme de son emplacement approprié.
J'ai été sur plusieurs systèmes critiques pour la sécurité avec des développeurs hautement expérimentés et capables, qui passeraient n'importe quel test raisonnable dans leur domaine. Je n'ai jamais été sur un projet où nous n'avons pas eu 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 traditions établies de longue date.
Cependant, cette déclaration étant une prise de terre, je ne sais pas quel seigneur noir et effrayant de toutes les choses que l'informatique trace diaboliquement son contrôle et sa régulation sans entraves du développement de logiciels. Si vous parlez en fait de l'IEEE, ils ont certainement un aspect réglementaire, mais le respect des normes de l'IEEE est plus ou moins à volonté, et non sous la menace d'une arme. Ils essaient de développer des normes universelles de l'industrie afin que nous parlions tous le même langage et d'augmenter l'efficacité à tous les niveaux.
En outre, les normes qu'ils définissent aident à légitimer les pratiques courantes et à jeter les bases du développement de logiciels pour devenir à terme un domaine d'ingénierie plus discipliné, un peu comme le génie mécanique ou le génie chimique. Bien que le logiciel se rapproche de cet objectif, il ne sera probablement jamais complètement accepté universellement comme une discipline d'ingénierie.
Le problème principal est qu'un développeur de logiciel pourrait faire n'importe quoi, de l'écriture d'un joli widget de bureau à la mise en œuvre de systèmes de guidage missile. Dans l'un, la gravité et les conséquences des erreurs sont beaucoup plus élevées que l'autre et nécessitent donc une discipline d'ingénierie strictement réglementée pour aborder de manière raisonnable, sûre et efficace. Cela ressemble beaucoup à la gravité de l'erreur dans un pont mal conçu et à son effondrement. Les concepteurs du pont doivent respecter mes normes d'ingénierie pour garantir 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 aucune barrière à l'entrée. Procurez-vous quelques livres sur les scripts et la technologie Web et commencez à pirater, ou pire, lancez simplement Google pour savoir comment "le faire".
Lorsque nous, en tant qu'ensemble, décidons peut-être qu'il est temps d'augmenter les barrières à l'entrée, de maintenir l'industrie à un niveau plus élevé, d'évoluer de pirate/artisan à ingénieur, ce genre de réglementation sur laquelle je suis.
Il y a trop de programmes pour les individus non qualifiés aujourd'hui. Qu'ils travaillent ou non sur des systèmes critiques, ils produisent toujours du code, ils produisent toujours Big Balls of Mud .
À cet égard, l'autorégulation ou la création plus appropriée 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 logiciel. Vous devez en fait démontrer un niveau de compétence.
La compétence de démonstration est plus que simplement passer un test ou obtenir un "badge d'honneur". Un test n'est qu'une validation. La vraie validation est l'école, le stage, l'apprentissage, le mentorat auprès des seniors, la pratique, tout cela en fait partie.
Je peux voir ce que l'IEEE essaie de réaliser, mais à ce stade, c'est un exercice infructueux. L'industrie évolue rapidement, trop de demande pour pousser les produits à l'extérieur, la mentalité de "hacker", etc. La réglementation doit venir de l'intérieur, si elle l'est.
Je n'ai pas lu l'article, mais si la question est de savoir si la réglementation de l'industrie du logiciel peut bénéficier à l'humanité, je pense que cela dépend des circonstances:
L'industrie dans son ensemble englobe une grande variété de domaines, dont certains sont essentiels à la vie (par exemple, contrôler la dose de rayonnement dans un appareil médical), et d'autres non (l'application Facebook "Quel Muppet êtes-vous?"). Je ne vois aucun argument en faveur d'une réglementation pour les applications où les enjeux sont faibles.
Il ne faut pas commencer avec une réglementation légale. Il faut plutôt commencer par un programme de certification pour les développeurs. Uniquement si le programme de certification produit un avantage mesurable, il devrait y avoir une question de réglementation légale.
Même si un programme de certification produit des résultats mesurables, il est probable que l'industrie se normaliserait en exigeant cette certification pour des raisons strictement commerciales, et nous n'aurions pas besoin d'une réglementation légale. (C'est pourquoi des délégations comme MCSE existent - les entreprises préfèrent embaucher des MCSE pour les domaines dans lesquels les MCSE sont formés.)
Cela dit, il reste encore des domaines dans lesquels il est logique de faire du tort aux entreprises (souvent ce sont externalités négatives , parfois elles sont le résultat de pouvoir de marché pour certaines institutions ). Par exemple, une zone peut avoir un seul hôpital local; dans ce cas, la qualité du logiciel principal peut faire une énorme différence dans le niveau de soins qu'un patient reçoit, mais ne fait pas beaucoup de différence dans l'hôpital choisi par le patient. L'hôpital n'a donc pas forcément beaucoup d'arguments commerciaux pour investir dans des développeurs de meilleure qualité. Dans ce cas, il peut y avoir un dossier de santé publique pour réglementer les développeurs que l'hôpital est autorisé à embaucher.
A MON HUMBLE AVIS.
Je dois répondre à celle-ci ...
À partir de ce que @JonathanHenson a dit et de l'entrée de @gnat, ce que je dis est correct, 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 les licences (tant pour les choses certifiées ), il y aura donc encore des renégats si cela se concrétise. Même si les méthodes de livraison traditionnelles (et pas si traditionnelles) sont fermées, les gens trouveront toujours des moyens de fournir des logiciels aux utilisateurs intéressés. Même si cela signifie développer un autre protocole HTTP ou même une pile de réseau entière alternative, uniquement concentré sur la possibilité de rendre les connexions indétectables (voir le dernier paragraphe, pour quelqu'un qui pourrait le faire).
De plus, l'idée de payer pour quelque chose est en danger, car le monde devient de plus en plus pauvre, donc de plus en plus de gens auront de moins en moins d'argent pour payer les choses, il y a même des pays qui n'utilisent que des logiciels libres, sans la certification (le Brésil et l'Inde 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 fabriqués par des programmeurs inconnus, dont les compétences sont inconnues.
De plus, même s'il existe un certain type de certification, la certification ne fera que certifier les connaissances, pas l'éthique, il suffit de penser que certains médecins utilisent des organes qui sont retirés de manière non autorisée de personnes, il y aurait donc également des programmeurs certifiés qui ne pas avoir d'éthique et écrire du code bâclé, intentionnellement ou non. Alors que dans la plupart des projets FOSS, la plupart des programmeurs potentiellement non qualifiés examinent également le code des autres et essaient de trouver des erreurs, d'une manière qui rend la programmation par paires quelque chose de peu.
Enfin, que dites-vous des groupes de piratage (pas des groupes de hackers Black Hat, mais des groupes de chapeaux blancs ou gris), qui en savent beaucoup plus sur la sécurité et développent des logiciels de sécurité d'une manière qui ne correspond qu'aux programmeurs les plus spécialisés de certains ministères.