Regulamentação da indústria de software [fechada]

A cada poucos anos, alguém propõe uma regulamentação mais rígida para a indústria de software.

Este artigo do IEEE vem recebendo alguma atenção ultimamente sobre o assunto.

Se os engenheiros de software que escrevem programas para sistemas que expõem o público a riscos físicos ou financeiros soubessem que seriam testados em sua competência, continua o pensamento, isso reduziria as falhas e falhas do código - e talvez salvasse algumas vidas em troca.

Sou cético em relação ao valor e mérito disso. A meu ver, parece uma apropriação de terras por aqueles que a propuseram.

A citação que confirma isso para mim é:

O exame testará o conhecimento básico, não o domínio do assunto

porque as grandes falhas (por exemplo, THERAC-25 ) parecem ser questões complexas e sutis que o "conhecimento básico" nunca seria suficiente para evitar.

Ignorando quaisquer problemas locais (como proteções existentes do título Engenheiro em algumas jurisdições):

Os objetivos são nobres - evite os charlatães / charlatães ¹ e torne essa distinção mais óbvia para aqueles que compram seu software. A regulamentação mais rigorosa da indústria de software pode atingir seu objetivo original?

¹ Exatamente como pretendia a regulamentação da profissão médica.

A visão de que os engenheiros de software podem ser colocados na mesma classificação que os profissionais médicos ou contadores é uma visão ignorante do "problema" que eles estão tentando resolver. Antes de dar minha opinião sobre isso, vamos detalhar alguns argumentos do Sr. Thornton, que é vice-presidente do órgão regulador que propõe esta legislação.

"Assim como profissionais, como médicos, contadores e enfermeiros, são licenciados, os engenheiros de software também devem", diz Thornton. "O público precisa confiar em algum tipo de credencial ao escolher um contratado para escrever o software."

- Mitch Thornton, vice-presidente do IEEE Licensure and Registration

Isso parece muito razoável na superfície. Afinal, existem outros setores que podem ser considerados "regulamentados com sucesso". Com regulamentação bem-sucedida, quero dizer que, se você procurar um médico nas páginas amarelas, pode estar razoavelmente certo de que ele ou ela teve uma educação completa em uma universidade credenciada e passou em vários exames e completou uma residência. Aqui estão algumas indústrias "regulamentadas com sucesso" (em termos de pessoal profissional).

• Advogados
• Médicos
• Contadores
• Engenheiros nucleares
• Barbeiros ( sem brincadeira )

Afinal, você não quer que ninguém remova esse tumor do pâncreas ou trabalhe nas centrífugas daquela usina nuclear nos arredores da cidade. Por que não deveriam existir restrições semelhantes para engenheiros de software?

Somente aqueles cujos programas podem "pôr em risco a saúde ou a segurança pública, a segurança, a propriedade ou a economia precisarão ser testados"

Esta é uma declaração vaga e aberta à interpretação e aplicação liberal. Eu poderia argumentar que a Apple Inc. ou o Facebook são parte integrante da economia americana - preciso de uma licença especial do governo para escrever um código para eles agora, já que, se eu derrubar o site com a minha incompetência, poderia prejudicar o americano economia? No meu último emprego, desliguei acidentalmente um elevador de grãos com um trabalho cron defeituoso - possivelmente colocando em risco o suprimento de comida.

Percebo que estou evitando a intenção real desta proposta. A idéia por trás disso é garantir que a pessoa que está escrevendo o código do sistema de freio antibloqueio em seu novo Jetta seja competente e devidamente licenciada para escrever o código para um sistema de freio antibloqueio. No seu Jetta.

Aqui está o problema: a engenharia de software hoje em dia abrange tudo e você não pode testar todas as disciplinas. As regras de negócios são muito específicas e muito variadas de disciplina para disciplina. Nosso hipotético engenheiro escrevendo código para o sistema ABS em um Jetta pode estar escrevendo algo totalmente diferente para o sistema ABS em um Elantra. Ele precisa ser certificado novamente?

E se você testar todas essas disciplinas derivadas? Suponha por um momento que todo programador que trabalha em um site de comércio eletrônico seja certificado como um programador habilitado para comércio eletrônico. Assim? De repente, isso significa que esses programadores e empresas realmente fazem a validação necessária e desenvolvem a conformidade com o PCI? Mesmo se o fizerem - falhas ainda acontecerão.

O exame testará o conhecimento básico, não o domínio do assunto, de acordo com Mitch Thornton, vice-presidente do Comitê de Licenciamento e Registro do IEEE.

Aqui está o kicker. A falta de conhecimento básico nunca é o problema. Meus freios antibloqueio não pararam de funcionar porque Chuck estava lutando com os conceitos de uma estrutura de controle. Eles falharam porque havia uma falha na ativação do ABS devido a um curto-circuito nas luzes traseiras e a energia não era redirecionada corretamente. Ou alguma coisa.

O software da bomba de insulina que escrevi não parou de funcionar porque me falta habilidades básicas; parou porque houve um erro na maneira como medi a dispensação de insulina quando meu companheiro de equipe europeu usou o sistema métrico e não o fiz.

Isso é algo que você pode considerar no desenvolvimento, mas nunca poderia testar com uma certificação .

Eis o que acontecerá se essa "certificação" entrar em vigor: o número de incidentes permanecerá exatamente o mesmo. Por quê? Porque ele não faz nada para eliminar o problema real de uma falha do ABS ou da bomba de insulina.

Que sorte que ninguém morre graças à regulamentação médica, ninguém é ferido por fraude graças à regulamentação financeira, ninguém tem a casa fechada por causa da regulamentação da habitação, ninguém nunca corta o cabelo graças à regulamentação do barbeiro e nenhum avião cai. graças à regulamentação da aeronave.

Obviamente, a presença de regulamentação não implica ausência de falhas ou falhas. Por outro lado, a presença de falhas ou falhas não implica que a regulamentação evite essas falhas ou falhas. Os engenheiros de software já são altamente regulamentados como membros dos respectivos setores críticos para a segurança e, fora desses setores, há pouca necessidade.

A história mostrou, acredito, apropriadamente, que a diferença entre um excelente artesão e um medíocre não pode ser testada com nenhuma forma de medida objetiva. O conhecimento básico não cria um grande programador, sabedoria e experiência - que realmente não possa ser ensinado ou medido objetivamente - sobre como aplicar esse conhecimento básico.

Além disso, esses testes geralmente acabam sendo apenas algumas palavras de ordem e procedimentos concretos e não medem nada de substancial para começar.

Se a indústria de software quisesse desenvolver algum tipo de guilda, seria uma maneira muito melhor de abordar o problema. No entanto, a centralização só tem o poder de destruir a excelência: não a cria.

Além disso, os problemas que esta medida está tentando evitar provavelmente não seriam detectados por um teste. De qualquer forma, eu também adoraria ver @ThomasOwens responder a esta.

Qual seria o papel do governo, pelo menos da ideologia americana, seria responsabilizar as empresas de software por qualquer dano à propriedade causado por seu software defeituoso ou inseguro. Isso encorajaria as empresas a impor seus próprios padrões e a assumir responsabilidade pessoal pelo assunto. Essa é sempre uma solução melhor e não contém um governo centralizado que ultrapasse seus limites.

Atualizar

Eu estava pensando sobre isso um pouco mais ontem à noite com uma cerveja ou dez.

Tudo o que regulamentou o campo da medicina foi exterminar todos os paradigmas, exceto um. Se o objetivo deles era eliminar médicos homeopatas e naturopatas, a quem a operação gentilmente se referia como "charlatões", então essa regulamentação foi bem-sucedida. No entanto, discordo que tal coisa seja rentável para qualquer pessoa, exceto para as pessoas que escrevem a legislação. Pense no que isso fez. Ele elevou o custo dos cuidados de saúde a níveis insustentáveis, aumentou muito os níveis de responsabilidade dos médicos e removeu todo o poder de escolha e autodeterminação do consumidor do mercado. Não há mais mercado para idéias na comunidade médica, e novos tratamentos e novas formas de pensar sobre medicina agora são suprimidos. Além disso, a barreira para entrada no campo é incrivelmente alta e, como resultado, temos uma escassez de bom MD s. Além disso, as agências reguladoras têm o poder de controlar a oferta de médicos, para que, por sua vez, possam controlar o preço que os médicos recebem.

De fato, há alguns ganhos que recebemos do regulamento médico, mas os custos são totalmente altos.

O mesmo acontecerá com os engenheiros de software se essa regulamentação for aprovada. Eu posso ver agora, as agências reguladoras decidirão que a programação orientada a objetos é o único padrão de design e os programadores funcionais e procedimentais não terão permissão para praticar. Então eles começarão a nos dizer que não temos permissão para gerenciar nossa própria memória porque não é segura. Então eles enfiam JAVA e C # em todas as nossas gargantas e nos dizem que precisamos usá-lo enquanto Oracle e Microsoft ficam mais gordos e felizes. A inovação será sufocada e a criatividade será proibida. A Microsoft e o Google redigirão a legislação, para que as regras do mercado sejam inclinadas para sua própria lucratividade e contra o bem-estar social.

Além disso, gostaria de lembrar a todos que os computadores começaram como um hobby e um esforço acadêmico. Além das guerras do Unix nos anos 80 e início dos 90, tivemos sistemas operacionais gratuitos, compiladores gratuitos, programas gratuitos e assim por diante ... Isso terminaria rapidamente. O mundo que Richard Stallman, Linus Torvalds e Dennis Richtie nos legaram gradualmente desaparecerá da existência.

Em resumo, eu me canso de ter que competir com "vou criar um site wordpress CMS por US $ 25 por hora" ou com o pessoal "qualquer aplicativo para iPhone por US $ 500"? Na verdade não, por quê? Porque sou muito bom no que faço e os clientes que quero estão dispostos a pagar pela excelência. Quando assumo um projeto de forma independente ou no meu local de trabalho, corro o risco de meus f * & ^ ups sobre minha própria cabeça e reputação. Isso vai me seguir onde quer que eu vá. Além disso, a maioria das pessoas sabe que recebe o que paga. Um cliente que só está disposto a me pagar o preço que pagará ao sujeito do gramado será um pesadelo para lidar com isso. Se o governo fixasse a estrutura legal para forçar os provedores de serviços a compensar seus danos, haveria muito poucos programadores ruins que ainda tivessem emprego no campo.

A propósito, ainda temos médicos ruins, a única diferença é que existem muito poucas forças para removê-los do mercado. Se eles tivessem que assumir a responsabilidade por suas próprias ações, estariam fora do negócio antes que tivessem outra chance de causar estragos incompetentes em seus clientes.

Notícias do Vale do Silício - 31 de junho de 2015

Horror: programador não certificado interrompeu o programa

"Eu nunca poderei correr de novo", mostra a vítima. A polícia está investigando.

Criminoso: revogada a licença do Dr. H. Acker Jr. por uso incorreto do ponteiro e tentativas de leitura do arquivo do sistema

O advogado diz que haverá apelo à Suprema Corte.

Anúncios: programadores Cobol certificados em 1975 devem recertificar até 2025

A certificação confirmada pelo IEEE não mudou desde então.

Anúncios: Certificação garantida com Magic Knowledge Stuffers, Inc

Aprenda a programar em 21 dias.

Existem algumas maneiras diferentes de aplicar a regulamentação a qualquer profissão - um corpo de conhecimento bem definido, um código de ética, acreditação de programas educacionais, certificação e licenciamento e sociedades profissionais que apóiam o desenvolvimento profissional, bem como os outros aspectos de uma profissão. profissão. A engenharia de software tem a maioria das características de uma profissão.

Gosto de pensar nisso como começando com o Conhecimento em Engenharia de Software (SWEBOK) e o Código de Ética e Prática Profissional de Engenharia de Software . Embora a aceitação comum disso ainda seja bastante limitada, acho que eles servem como uma boa base para identificar os tipos de coisas que alguém que se identifica como engenheiro de software deve ter conhecimento e como essa pessoa deve agir em uma capacidade profissional. Isso não significa que essas são regras rígidas, mas esses documentos orientam os engenheiros de software profissionais sobre o que é normalmente relevante para o trabalho que eles podem ser solicitados a fazer. O SWEBOK é revisado periodicamente para garantir que permaneça relevante.

A próxima característica é a acreditação de programas educacionais. Nos EUA, o credenciamento de programas de engenharia de software é realizado pela ABET . Eles também credenciam ciência da computação, tecnologia da informação, engenharia da computação e outras profissões relacionadas à computação. A ABET publica em seu site os requisitos de programas credenciados - a engenharia de software é considerada um programa de engenharia. O objetivo do credenciamento é garantir a consistência entre os graduados de diferentes programas de engenharia, pelo menos em termos da matéria ensinada na sala de aula. Não diz nada sobre a qualidade da educação.

Após a graduação, a certificação e o licenciamento são usados ​​para avaliar o conhecimento aprendido na sala de aula (e, em alguns casos, no trabalho) em relação aos corpos de conhecimento padrão. Embora as escolas credenciadas possuam um corpo definido de material a ser ensinado, não há uma medida de quão bem esse material é ensinado e quanto os alunos aprendem ao concluir o programa. A certificação e o licenciamento fornecem métodos para fazer isso - todos fazem os mesmos exames e demonstram conhecimento nos vários corpos de conhecimento em que a profissão está enraizada. Na engenharia de software, o IEEE oferece certificações enraizadas no SWEBOK - o Certified Software Development Associado para idosos e recém-formados e o Profissional certificado de desenvolvimento de softwarepara aqueles com experiência no setor. Para agregar valor, é necessária a aceitação do SWEBOK como uma boa definição do que é a engenharia de software.

Por fim, as sociedades profissionais mantêm os documentos orientadores da profissão, facilitam conferências e publicações para o intercâmbio de conhecimentos e idéias, colmaram lacunas entre a academia e a indústria, e assim por diante. As duas sociedades líderes são a IEEE Computer Society e a ACM , mas existem outras sociedades em todo o mundo. Elas agrupam tudo em um pequeno pacote e ajudam a fornecer informações para as pessoas certas.

A partir daqui, há outras perguntas a serem feitas. O desenvolvimento de software é uma disciplina de engenharia? A certificação ou o licenciamento agregam algum valor aos engenheiros de software? A certificação é útil?

Não acho que todo desenvolvimento de software precise do rigor de uma disciplina de engenharia. Isso não quer dizer que um estudo científico empírico da ciência e engenharia da construção de software não ajude a todos - mas sim. No entanto, existe uma grande diferença entre o desenvolvimento do videogame mais recente, o desenvolvimento do software incorporado para o marcapasso ou a construção da próxima nave espacial. A ênfase é diferente em todos eles - dois dos três merecem a atenção de um engenheiro qualificado. O outro pode aprender com as práticas de engenharia, mas não precisa confiar nelas para concluir o projeto com sucesso.

A certificação e o licenciamento exigem um corpo de conhecimento aceito. O SWEBOK é um bom documento que fornece uma base sólida, mas não é amplamente aceito. A menos que você possa basear seus programas acadêmicos e exames de certificação / licenciamento em algo concreto que seria aceito pelos profissionais, então não há realmente sentido. Se o SWEBOK ou documento alternativo for amplamente aceito (pelo menos nos campos que exigem o rigor da engenharia), os exames de certificação ou licenciamento poderão ser utilizados para avaliar a compreensão do conhecimento necessário.

No entanto, há um problema flagrante com a certificação - é um teste em um livro. Algumas pessoas são boas em ler, aprender, memorizar e fazer um teste. No entanto, isso não significa que eles sejam um bom engenheiro. As pessoas escorregam pelas rachaduras o tempo todo. Uma certificação ou licença é apenas uma única etapa. No trabalho, o treinamento e a orientação de outros engenheiros experientes são obrigatórios para preparar um bom profissional. Além disso, a capacidade de impedir que as pessoas pratiquem em ambientes críticos também pode ajudar a mitigar os riscos para a sociedade e as empresas.

Um bom livro com uma discussão bastante aprofundada disso é o Desenvolvimento de software profissional de Steve McConnell : cronogramas mais curtos, produtos de maior qualidade, projetos mais bem-sucedidos e carreiras aprimoradas .

Se as regulamentações governamentais forem aprovadas, a indústria de software nos EUA terá um contrato significativo, porque o custo associado ao cumprimento dessas regulamentações será maior do que as startups e pequenas empresas podem pagar.

A escassez e o custo associados a um curso de Direito ou a um Doutor em Medicina se tornarão mais ou menos visíveis em nossa indústria. Não é bom quando a alternativa é que todo Joe possa construir o próximo Facebook.

As pessoas cometem erros, e nenhuma quantidade de regulamentação impedirá a ocorrência de desastres. Considere a NASA, que tem de longe os requisitos mais rigorosos para o desenvolvimento de software conhecidos pelo homem. Eles ainda têm bugs de software? (Sim, sim, e muitas vezes, sim!)

O mercado resolve esses problemas muito melhor do que os regulamentos. As empresas que criam software que causa problemas são responsabilizadas pelas pessoas que feriram. O resto de nós não precisa pagar por seus erros.

Em 1999, a ACM emitiu uma declaração sobre licenciamento quando largou o trabalho da IEEE SWEBOK. Depois de revisar os documentos SWEBOK disponíveis ao público e a declaração da ACM, apoio a opinião da ACM.

Olhando de relance para o artigo, alguém com 4-6 anos de experiência é obrigado a fazer o exame, que testa o conhecimento básico. Isso é mais do que ridículo, e deve ser ridicularizado do lado de fora.

Os componentes de software de um dispositivo são um detalhe de implementação. Por exemplo, no setor de sistemas de controle, todos os dispositivos de segurança costumavam ser conectados e as pessoas não confiavam no software. No entanto, agora estamos vendo dispositivos de segurança baseados em software, como relés de segurança e CLPs de segurança. Eles são permitidos porque ainda precisam cumprir os regulamentos da indústria para dispositivos de segurança (dependendo da categoria de segurança). Portanto, em alguns casos, os dispositivos precisam de processadores redundantes e código redundante escrito por duas equipes diferentes, etc.

É o produto que precisa atender às diretrizes de segurança para ser vendido e consumido pelo público. Essas regras não mudam porque o produto contém software. O trabalho do engenheiro é garantir que o produto atenda a todos os critérios regulatórios e, se ele contiver software, eles deverão revisar o software e ser competentes nesse campo . Caso contrário, eles (ou a empresa) são responsáveis ​​se aprovarem o design e se mostrar defeituoso.

Você realmente não precisa regular todos os programadores apenas porque alguns produtos precisam atender a requisitos mais rigorosos. Nos casos em que esses produtos envolvem software, você precisa de uma disciplina de engenharia bem desenvolvida que possa determinar com segurança que o componente de software atende aos requisitos. Na verdade, é isso que o IEEE significa: o campo relativamente jovem da Engenharia de Software precisa ser desenvolvido para o nível de confiabilidade e confiança de outras disciplinas de engenharia.

Realmente não tem nada a ver com "programação" e tudo a ver com "engenharia".

É claro que isso nos traz de volta à questão controversa da diferença entre um desenvolvedor e um engenheiro. Geralmente, esses são dois papéis diferentes que se sobrepõem regularmente. A parte do desenvolvedor significa que você cria software. A parte de engenharia da função significa que, se você carimbar o design, estará assumindo a responsabilidade pela segurança pública. Você pode ser um sem o outro.

O software já está fortemente regulamentado na indústria aeronáutica. Veja DO-178B .

Tenho certeza de que outros subconjuntos da indústria têm suas normas.

"Software" abrange muito hoje em dia. Eu acho que seria absurdo ter qualquer regulamentação obrigatória abrangente.

A regulamentação da indústria de software é melhor realizada através da regulamentação dos processos de Garantia da Qualidade.

Isso já foi feito - as grandes empresas de software têm vários testadores, gerentes de controle de qualidade, conjuntos de testes automatizados, processos de revisão de código, processos de teste e assim por diante. Existem empresas cujo objetivo é realizar auditorias de qualidade de software em outras empresas. As organizações de padrões têm diretrizes para controle de qualidade e auditorias de controle de qualidade.

Interno de uma empresa, um engenheiro de software é responsável pela qualidade de seu trabalho. Seus freios e contrapesos, no entanto, estão nos processos de qualidade da empresa.

É o mesmo que as tentativas mais modernas de solucionar "problemas relacionados a software". Aqueles que tentam legislar têm pouco conhecimento do curso raiz do problema. Se seguir o processo prescrito (e a intenção, é claro) ao desenvolver software crítico de segurança, seja para aeronaves, usinas nucleares de equipamentos médicos, um único bug nunca será suficiente para causar uma falha. Um algoritmo inteiro pode ser implementado incorretamente sem que ninguém seja prejudicado.

O FDA e o TLC requerem uma análise de risco e, com base nisso, uma estratégia de mitigação. A última geralmente é uma estratégia de queijo suíço, em que se aceita que qualquer mitigação é falha; portanto, várias mitigações para o mesmo risco são aplicadas (uma mitigação também pode ser aplicada a vários riscos) cada mitigação é como uma fatia de queijo suíço que você pode observar um, talvez duas fatias juntas, mas junte fatias suficientes e isso não é mais possível. Mesmo quando as mitigações são implementadas perfeitamente, isso não resulta em um equipamento 100% seguro. Se a análise de risco estiver incorreta, haverá riscos em que ninguém pensou (Y2K).

Você pode testar os engenheiros da maneira que quiser, até testar no assunto e exigir um nível extremamente alto, mas isso importaria muito. A maioria dos erros críticos de segurança são erros de integração. Eles não são erros no código de um homem, mas surgem devido a desalinhamentos entre software e hardware de dois sistemas de software ou porque uma partícula alfa arrancou o contador do programa de seu local apropriado.

Estive em vários sistemas críticos de segurança com desenvolvedores altamente experientes e capazes, que passariam por qualquer teste sensato em seu campo. Nunca participei de um projeto em que não tivéssemos um erro crítico de segurança. (Felizmente nunca estive em um lugar em que o sistema prejudicou alguém)

Nunca se pode eliminar completamente os charlatães e charlatães, porque eles existem em quase todas as profissões, mesmo nas profissões médicas, apesar das práticas e tradições estabelecidas há muito tempo.

Embora essa afirmação seja uma conquista de terras, não tenho certeza de que susto assustador de todas as coisas que a TI está diabolicamente traçando seu controle e regulamentação irrestritos do desenvolvimento de software. Se você está de fato falando sobre o IEEE, eles certamente têm um aspecto regulatório, mas a conformidade com os padrões do IEEE é mais ou menos à vontade, e não à mão armada. Eles estão tentando desenvolver padrões universais do setor, para que todos falemos o mesmo idioma e aumentemos a eficiência em geral.

Além disso, os padrões que eles estabelecem ajudam a legitimar práticas comuns e preparam o terreno para o desenvolvimento de software se tornar um campo mais disciplinado da engenharia, não muito diferente da engenharia mecânica ou da engenharia química. Embora o software esteja se aproximando desse objetivo, provavelmente nunca será completamente aceito universalmente como uma disciplina de engenharia.

O principal problema é que um desenvolvedor de software pode estar fazendo qualquer coisa, desde a criação de um widget de área de trabalho bonito até a implementação de sistemas de orientação de mísseis. Em uma, a gravidade e a conseqüência do erro são muito maiores que a outra e, portanto, exigem uma disciplina de engenharia estritamente regulamentada para abordar de maneira razoável, segura e eficiente. É muito parecido com a gravidade do erro em uma ponte que está sendo projetada incorretamente e, como resultado, ela é recolhida. Os projetistas da ponte devem cumprir meus padrões de engenharia para garantir a qualidade.

Eu não chamaria isso de regulamentação mais rígida, mas barreiras à entrada. A esse respeito, acho que há mérito. Para maior qualidade, isso é muito discutível.

Atualmente, qualquer John / Jane Doe pode escrever um programa. Não há barreira para entrada. Pegue alguns livros sobre scripts e tecnologia da Web e comece a piratear ou, pior ainda, comece a pesquisar no Google como "fazê-lo".

Quando nós, como um todo coletivo, decidimos que talvez seja hora de aumentar as barreiras de entrada, manter a indústria em um padrão mais alto, evoluir de hacker / artesão para engenheiro, esse tipo de regulamentação em que eu sou fã.

Hoje existem muitos indivíduos não qualificados programando. Quer eles trabalhem ou não em sistemas críticos, eles ainda estão produzindo código, ainda produzindo Big Balls of Mud .

Nesse sentido, a auto-regulação ou a criação mais adequada de barreiras à entrada é uma coisa boa. Porque estamos dizendo, ei, você não pode simplesmente sair da rua e se chamar engenheiro de software. Você realmente tem que demonstrar um nível de habilidade.

Habilidade de demonstração é mais do que apenas fazer um teste ou obter um "distintivo de honra". Um teste é apenas uma validação. A validação real é a escola, o estágio, o aprendizado, a orientação de idosos, a prática, tudo isso faz parte.

Eu posso ver o que o IEEE está tentando alcançar, mas neste momento é um exercício infrutífero. O setor muda rapidamente, muita demanda por empurrar o produto para fora da porta, a mentalidade de "hacker" etc. A regulamentação precisa vir de dentro, se é que existe.

Não li o artigo, mas se a questão é se a regulamentação da indústria de software pode beneficiar a humanidade, acho que depende das circunstâncias:

1. A indústria como um todo abrange uma ampla variedade de domínios, alguns dos quais são críticos para a vida (por exemplo, controle da dosagem de radiação em um dispositivo médico) e outros não (o aplicativo do Facebook "Que Muppet É Você?"). Não vejo nenhum argumento de regulamentação para aplicações em que as apostas são baixas.

2. Não se deve começar com regulamentação legal. Em vez disso, deve-se começar com um programa de certificação para desenvolvedores. Somente se o programa de certificação produzir algum benefício mensurável, deve haver uma questão de regulamentação legal.

3. Mesmo que um programa de certificação produza resultados mensuráveis, é provável que o setor padronize a exigência dessa certificação por motivos estritamente comerciais, e não precisaremos de regulamentação legal. (É por isso que existem delegações como o MCSE - as empresas preferem contratar MCSEs para os domínios em que os MCSEs são treinados.)

4. Dito isso, ainda restam domínios nos quais faz sentido para os negócios causar danos (geralmente são externalidades negativas , às vezes são o resultado do poder de mercado de algumas instituições). Por exemplo, uma área pode ter um único hospital local; Nesse caso, a qualidade do software de back-end pode fazer uma enorme diferença no nível de atendimento que um paciente recebe, mas não faz tanta diferença em qual hospital o paciente escolhe. O hospital, então, não tem necessariamente muitos motivos de negócios para investir em desenvolvedores de alta qualidade. Nesse caso, pode haver um caso de saúde pública para regulamentar os desenvolvedores que o hospital está autorizado a contratar.

NA MINHA HUMILDE OPINIÃO.

Eu tenho que responder a este ...

Começando com o que o JonathanHenson disse e com a entrada do @gnat, o que eu digo é ok, pessoas que têm dinheiro podem pagar por material certificado, pessoas ou países que não têm dinheiro não podem pagar por licenças (muito pelo material certificado ), então ainda haverá renegados se isso entrar em prática. Mesmo que os métodos de entrega tradicionais (e não tão tradicionais) sejam fechados, as pessoas ainda encontrarão maneiras de fornecer software aos usuários interessados. Mesmo que isso signifique desenvolver outro protocolo HTTP ou mesmo uma pilha de rede inteira alternativa, focada apenas em tornar as conexões indetectáveis ​​(consulte o último parágrafo, para alguém que possa fazer isso).

Além disso, a ideia de pagar por algo está em risco, uma vez que o mundo está ficando cada vez mais pobre, para que mais e mais pessoas tenham cada vez menos dinheiro para pagar por coisas, existem até países que usam apenas o software FOSS, sem nenhum certificação (Brasil e Índia vêm à mente, mas existem outros) e alguns desses países estão ficando grandes, muito grandes. E eles usam software não certificado feito por programadores desconhecidos, cuja habilidade é desconhecida.

Além disso, mesmo que exista algum tipo de certificação, a certificação só certifica o conhecimento, não a ética, apenas pensa que alguns médicos usam órgãos que são removidos de maneira não autorizada das pessoas, para que também haja programadores certificados que não tenha ética e escreva códigos incorretos intencionalmente ou não. Enquanto na maioria dos projetos de software livre, os programadores potencialmente não especializados também revisam o código de outros e tentam encontrar erros, de uma maneira que torna a programação em pares algo pouco.

Por fim, o que você diz dos grupos de hackers (não grupos de hackers de chapéu preto, mas grupos de chapéu branco ou cinza), que sabem muito mais sobre segurança e desenvolvem software de segurança de uma maneira que só corresponde aos programadores mais especializados de determinados departamentos governamentais.