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


85

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

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


3
Espero que Thomas Owens responda a isso porque sei que ele tem a resposta perfeita.
Maple_shaft

3
Por mais que eu gostaria de ouvir o que as pessoas têm a dizer sobre esse tópico, parece-me uma pergunta para discussão ser uma boa opção para o formato de perguntas e respostas sobre o Stack Exchange.
PersonalNexus

12
Francamente, eu sou a favor de uma emenda constitucional que cria uma separação de tecnologia e estado dada a nora, o Governo parece estar ao regulamentar tecnologia (ver também SOPA)
JohnFx

3
Como uma indústria pode ser regulamentada quando muda todos os dias?
21412 Jon Jonnor

4
Não são muitas dessas situações "suficientemente boas" que mais tarde causam erros, muitas vezes culpa da gerência / marketing dizendo: "NAVIO NAVIO NAVIO!"
Aren

Respostas:


105

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.


33
+1 excelente resposta. Eu gosto especialmente: "A falta de conhecimento básico nunca é o problema".
Jonathan Henson

4
Ótima resposta, mas leva em consideração a engenharia de software da perspectiva dos programadores. A verdadeira engenharia de software é, na realidade, um esforço de equipe que envolve várias habilidades e disciplinas, analistas de negócios, garantia de qualidade, gerenciamento de projetos, etc ... Incidentes são tão prováveis ​​do resultado de uma programação ruim quanto de requisitos perdidos, requisitos incompreendidos, projetos mal gerenciados e teste inadequado. O teste do OP menciona algo disso? Claro que não porque é para programadores.
Maple_shaft

3
Eu acrescentaria, no entanto, que acho que toda a ideia do IEEE é lixo, para começar. Tudo o que o governo precisa fazer é o seu trabalho para solucionar o problema. Responsabilize todos os danos causados ​​a alguém. Isso por si só vai cuidar do problema
Jonathan Henson

16
Discordo de "A falta de conhecimento básico nunca é o problema". De fato, muitas vezes é o problema. Com que frequência os novos programadores (ou mais antigos) negligenciam a higienização das entradas? Verificação em caso de canto? Para sistemas físicos, posso ler um sensor. Pode ser ligado ou desligado. E quanto a quebrado? Como meu software pode dizer? Então o que eu faço sobre isso? Presume que está ligado ou desligado? Esses tipos de coisas "básicas" são realmente comuns.
Sdg

3
@ JonathanHenson Então, novamente, considero que a maioria das instâncias de injeção de SQL é exatamente isso - sem conhecimento básico ... mas no geral, boa publicação. +1.
Jeff Ferland

72

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.


10
+1 para "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"
Trevor Boyd Smith

3
Não gosto do tom cínico dessa resposta. Você está dizendo que não há necessidade de regulamentação, uma vez que a regulamentação nunca resolve nenhum problema?
21812 Fred Foo

8
Estou dizendo que, além de um certo ponto, mais regulamentação raramente resolve mais problemas. Mandar certas práticas de teste de software em máquinas capazes de matar pessoas faz sentido. Aderir a mais um exame de certificação de habilidades básicas até o final de um programa de graduação apenas adiciona burocracia.
Karl Bielefeldt

2
@larsmans Eu concordo com Karl, se o governo está lidando com um míssil ou algo em que acredita que altos padrões devam ser exigidos, deixe-os contratar seus próprios programadores e engenheiros de acordo com o padrão que escolherem. De qualquer forma, o setor privado não deveria ganhar dinheiro com riscos públicos - isso é fascismo. Uma indústria privada não deve colocar em perigo o público, para começar. As pessoas que sabem o que precisam melhor são as pessoas que assumem o risco. Deixe que eles cuidem de seus próprios assuntos. E sim, eu sei que a Lockheed-Martin e outros fazem isso. Eles não deveriam ter permissão para isso.
Jonathan Henson

3
Considerando o número de grandes empresas que perderam os detalhes do cartão de crédito nos últimos anos, diria que não existe uma auto-regulação satisfatória. Você poderia argumentar que esses sistemas não são críticos para a vida - mas o efeito nos bolsos das pessoas pode ser igualmente difícil após esses incidentes.
HorusKol 08/02/12

32

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.


8
Embora eu concorde com o objetivo geral de sua afirmação, acho que a parte mais interessante é a primeira frase. Você caracteriza o desenvolvimento de software como um ofício , que é exatamente o problema . Um não criar uma ponte de suspensão; um cria uma ponte suspensa para garantir sua eficácia e segurança. Os engenheiros de software ainda agem mais como artesãos do que engenheiros, independentemente do título que você atribuir a eles.
Eric Lippert

4
@ Jonathan Henson: Eles certamente não, em geral. Muitas lojas marcam zero no teste Joel. ( joelonsoftware.com/articles/fog0000000043.html ) Se não deveriam , essa é uma decisão comercial, não moral. Todas essas coisas custam dinheiro: muito e muito dinheiro. Se você está construindo um sistema de controle de aeronaves, é lucrativo, a longo prazo, arcar com esses custos; se você está construindo um jogo no facebook, talvez não.
Eric Lippert

1
Não, um selo de arquiteto é tão bom quanto um selo de PE. Eu certamente diria que precisamos incorporar muitas coisas que atualmente são chamadas de disciplinas de engenharia, assim como um arquiteto. A arquitetura ainda é considerada mais uma arte. De qualquer forma, a engenharia também é provavelmente um ofício, então eu posso estar minuciosamente trocando palavras.
Jonathan Henson

1
@Andy, acho que devemos pedir troca pilha para alterar o título deste site para softwareengineers.stackexchange.com :)
Jonathan Henson

1
@JonathanHenson Offend? De jeito nenhum, não se preocupe! :) Eu deveria ter deixado um pouco mais claro o fato de ter postado o link apenas porque foi estranhamente coincidente com o seu comentário.
9111 yannis

23

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.


Estou tentando decidir se essa é uma resposta completa ou um comentário bem-humorado. (Ambos talvez?)
Lyndon Branco

@Oxinabox data de 31 de junho é bem
gnat

"Aprenda a programar em 10 dias!" hehe #
09/09

20

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 .


Estou um pouco mal, por isso, se eu perdi alguma coisa ou algo não faz sentido, cutuque-me e eu vou consertar. Obrigado rapazes.
Thomas Owens

"dois dos três merecem a atenção de um engenheiro qualificado" você está certo, naves espaciais não são tão difícil de fazer
zzzzBov

+1 obrigado por adicionar sua opinião sobre o assunto. Espero que você se sinta melhor.
Jonathan Henson

12

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.


8
Uma adição fantástica a essa resposta seria uma lista de empresas de software existentes que provavelmente não teriam sido iniciadas se esses regulamentos estivessem em vigor. A Microsoft e o Facebook são um bom começo, já que uma certificação provavelmente exigiria um diploma (quase todas as profissões que começam com testes adicionam um requisito de graduação, se não começarem com um).
Psr

1
@maple_shaft, a IMO comparar médicos / advogados com engenharia de software não é válida. Os campos são muito diferentes para comparar (consulte a resposta de Jarrod Nettles para ver por que você não pode comparar a engenharia de software com médicos / advogados).
Trevor Boyd Smith

1
@ maple_shaft - Você está sugerindo que a certificação melhoraria a qualidade da engenharia. Sou bastante cético quanto ao resultado. Acho que o tempo gasto estudando para a maioria dos testes não é tempo aprendendo melhor engenharia.
Psr

4
Acredito que todo mundo está assumindo que o licenciamento de médicos e advogados realmente melhora a qualidade de médicos e advogados. Sou muito cético em relação a essa suposição. Tudo o que o licenciamento garante é que médicos e advogados cobram taxas ultrajantes e não há nada que alguém possa fazer a respeito. Nesse sentido, sou a favor de licenciar engenheiros de software. Não vai melhorar a qualidade do software nem um pouco, mas certamente enriquecerá muitos de nós. Haha quando o governo prende o garoto do ensino médio por praticar software sem licença.
Húmido

1
@maple_shaft que depende inteiramente da natureza do fracasso - o Facebook não responde não é crítico (além de afetar os bolsos dos investidores) - o Facebook disponibiliza todos os seus dados pessoais e mensagens privadas para todos os usuários da Internet. Além disso - os aplicativos / jogos que usam detalhes do cartão de crédito (como no Facebook), liberar acidentalmente os detalhes do cartão de crédito teriam sérias repercussões.
HorusKol

11

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.


10

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.


5
+1 IMHO, o que você realmente está sugerindo é que a regulamentação precisa estar no produto, não nos engenheiros. Por exemplo, os regulamentos (aprovações) necessários para os sistemas de alarme de incêndio e intrusão garantem que o software funcione, e não a capacidade dos engenheiros que o criaram. (Muitos dos regulamentos parecem muito a mesma de quando os sistemas foram feitos inteiramente de circuitos eletrônicos.)
jwernerny

8

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.


4

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.


2
Esta é exatamente a minha opinião. O setor de aviação possui regras rígidas para programar o controle e teste de qualidade. As empresas precisam auditar seus ativos de informações e implementar mais testes e análises. Acho que esses são os dias sombrios do software, porque muitos ainda estão cortando os cantos por não fazerem o que sabem ser a coisa certa a fazer, e os próprios desenvolvedores não são suficientes para mudar o setor.
Tjaart

Ponto importante - o software que executa o dispositivo é da responsabilidade da empresa por uma engenharia boa e segura e da engenharia industrial.
Jarrod Nettles

3

É 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)


1
+1 - Para: "A maioria dos erros críticos de segurança são erros de integração". De fato, com todo o processo que passamos, quase nunca ocorre um erro de codificação. Em 99,98% do tempo, é um problema de entendimento entre diferentes módulos e dispositivos sobre como eles deveriam funcionar.
Húmido

@ Dunk obrigado, na verdade é um qoute da Levison. Um fato que eu pretendia incluir no texto, mas parece que eu esqueci :)
Rune FS

2

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.


4
Geralmente esses regulamentos acabam sendo requisitos legais também. Por exemplo, engenharia civil exigindo um PE
Paul Nathan

@PaulNathan Good point, é por isso que a progressão natural para uma disciplina universalmente aceita começa na auto-regulação (por exemplo, MPAA) e, eventualmente, leva à regulamentação por lei (conselhos estaduais, FCC, etc.)
maple_shaft

7
Não acredito que o desenvolvimento de software esteja pronto para a auto-regulação, ou mesmo próximo disso. Francamente, a ideia de que "engenheiros de verdade" têm "qualidade real" é uma espécie de piada para mim. Ônibus espaciais explodiram, foguetes acenderam fogo, pontes caíram, edifícios desabaram ... etc. Seria bom tentar impor qualidade de cima, mas haha.
Paul Nathan

1
Comparar a engenharia mecânica à engenharia de software me faz pensar em qual seria o análogo da engenharia do mundo real para algo como sistemas operacionais modernos.
FrustratedWithFormsDesigner

1
@ maple_shaft - o principal problema é que você não pode usar Linux / BSD / grep / vi / Firefox etc porque eles não foram escritos por um SE oficial. Enquanto alguém com um certificado MSCE no VB estiver OK.
Martin Beckett

1

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.


Dou +1, pois deve haver alguma maneira de manter o riff-raff de certos tipos de sistemas. No entanto, dou -1 porque a maioria dos softwares hoje em dia pode ser adequadamente desenvolvida por hackers e impedi-los de fornecer esse serviço para manter os custos baixos é contra o interesse público. Da mesma forma, o mesmo vale para advogados e médicos. 90% do que fazem podem ser tratados de maneira bastante econômica e com a mesma competência de pessoas com qualificações inferiores. No entanto, com as leis de hoje, eles são livres para atrair o público à vontade.
Dunk

As habilidades não devem ser avaliadas durante o processo de contratação. Ah, espere, o RH contrata pessoas com base em credenciais em papel (que não demonstram conhecimento aplicável no desenvolvimento de software) e as pessoas de RH não sabem absolutamente nada sobre as necessidades / requisitos para desenvolver software. Duplo falhar ...
Evan Solha

0

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.


0

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.