Regulación de la industria del software [cerrado]


85

Cada pocos años, alguien propone una regulación más estricta para la industria del software.

Este artículo de IEEE ha estado recibiendo atención últimamente sobre el tema.

Si los ingenieros de software que escriben programas para sistemas que exponen al público a riesgos físicos o financieros supieran que se les evaluaría su competencia, según el pensamiento, reduciría las fallas y fallas en el código, y tal vez salvaría algunas vidas en el negocio.

Soy escéptico sobre el valor y el mérito de esto. En mi opinión, parece una apropiación de tierras por parte de quienes lo propusieron.

La cita que lo confirma para mí es:

El examen evaluará los conocimientos básicos, no el dominio de la materia.

porque las grandes fallas (por ejemplo, THERAC-25 ) parecen ser problemas complejos y sutiles que el "conocimiento básico" nunca sería suficiente para prevenir.

Ignorando cualquier problema local (como las protecciones existentes del título de Ingeniero en algunas jurisdicciones):

Los objetivos son nobles: evitar los charlatanes / charlatanes 1 y hacer que esa distinción sea más obvia para aquellos que compran su software. ¿Puede una regulación más estricta de la industria del software lograr su objetivo original?

1 Exactamente como se pretendía hacer la regulación de la profesión médica.


3
Espero que Thomas Owens responda a esto porque sé que tiene la respuesta perfecta.
maple_shaft

3
Por mucho que me gustaría escuchar lo que la gente tiene que decir sobre este tema, me parece una pregunta de discusión que encaja bien con el formato de preguntas y respuestas de Stack Exchange.
PersonalNexus

12
Francamente, estoy a favor de una enmienda constitucional que crea una separación de la tecnología y el estado, dada la falta de idea del Gobierno al regular la tecnología (ver también SOPA)
JohnFx

3
¿Cómo se puede regular una industria cuando cambia todos los días?
Jon Raynor

44
¿No son muchas de estas situaciones "suficientemente buenas" que luego causan errores a menudo la culpa de la administración / marketing diciendo: "ENVÍO ENVÍO ENVÍO!"
Aren

Respuestas:


105

La opinión de que los ingenieros de software pueden ser encasillados en la misma clasificación que los profesionales médicos o contadores es una visión ignorante del "problema" que están tratando de resolver. Antes de dar mi opinión sobre esto, analicemos algunos de los argumentos del Sr. Thornton, quien es Vicepresidente del organismo regulador que propone esta legislación.

"Así como los profesionales en ejercicio, como médicos, contadores y enfermeras, tienen licencia, los ingenieros de software también deberían", dice Thornton. "El público debe poder confiar en algún tipo de credencial al elegir un contratista para escribir software".

- Mitch Thornton, Vicepresidente de IEEE Licensure and Registration

Esto suena muy razonable en la superficie. Después de todo, hay otras industrias que podrían considerarse "reguladas con éxito". Por exitosamente regulado quiero decir que si busca a un médico en las páginas amarillas, puede estar razonablemente seguro de que él o ella ha tenido una educación exhaustiva en una universidad acreditada y ha aprobado varios exámenes y completado una residencia. Aquí hay algunas industrias "exitosamente reguladas" (en términos de personal profesional).

  • Abogados
  • Doctores
  • Contadores
  • Ingenieros nucleares
  • Barberos ( no es broma )

Después de todo, no desea que cualquiera extraiga ese tumor de su páncreas o trabaje en las centrífugas de esa central nuclear a las afueras de la ciudad. ¿Por qué no deberían existir restricciones similares para los ingenieros de software?

Solo aquellos cuyos programas podrían "poner en peligro la salud o la seguridad pública, la seguridad, la propiedad o la economía deberán ser evaluados".

Esta es una declaración vaga y abierta a interpretaciones y aplicaciones liberales. Podría argumentar que Apple Inc. o Facebook son partes integrales de la economía estadounidense: ¿necesito una licencia especial del gobierno para escribir código para ellos ahora, ya que si derribo el sitio con mi incompetencia podría dañar al estadounidense? ¿economía? En mi último trabajo, accidentalmente apagué un elevador de granos con un trabajo cron defectuoso, posiblemente poniendo en peligro el suministro de alimentos.

Me doy cuenta de que estoy evitando la intención real de esta propuesta. La idea detrás de esto es garantizar que la persona que escribe el código para el Sistema de frenos antibloqueo en su nuevo Jetta sea competente y tenga la licencia adecuada para escribir el código de un Sistema de frenos antibloqueo. En tu Jetta.

Aquí está el problema: la ingeniería de software en este día y edad abarca todo y no es posible probar para cada disciplina. Las reglas comerciales son demasiado específicas y varían de disciplina en disciplina. Nuestro ingeniero hipotético escribiendo código para el sistema ABS en un Jetta podría estar escribiendo algo completamente diferente para el sistema ABS en un Elantra. ¿Tiene que volver a certificarse?

¿Y qué pasa si prueba para todas estas disciplinas derivadas? Supongamos por un momento que cada programador que trabaja en un sitio web de comercio electrónico se certifica como un programador capaz de comercio electrónico. ¿Entonces? ¿Significa esto de repente que estos programadores y compañías realmente harán la validación necesaria y desarrollarán el cumplimiento de PCI? Incluso si lo hacen, los problemas técnicos seguirán ocurriendo.

El examen evaluará los conocimientos básicos, no el dominio de la materia, según Mitch Thornton, vicepresidente del Comité de Licencias y Registro de IEEE.

Aquí está el pateador. La falta de conocimientos básicos nunca es el problema. Mis frenos antibloqueo no dejaron de funcionar porque Chuck estaba luchando con los conceptos de una estructura de control. Fracasaron porque hubo un fallo en el que el ABS se apagó debido a un cortocircuito eléctrico en las luces traseras y la energía no se desvió correctamente. O algo.

El software de la bomba de insulina que escribí no dejó de funcionar porque me faltan habilidades básicas; se detuvo porque hubo un error en la forma en que medí la dispensación de insulina cuando mi compañero de equipo europeo usó el sistema métrico y yo no.

Eso es algo que puede tener en cuenta en el desarrollo, pero nunca podría probar con una certificación .

Esto es lo que sucederá si esta "certificación" entra en vigencia: la cantidad de incidentes se mantendrá exactamente igual. ¿Por qué? Porque no hace nada para eliminar el problema real de una falla de ABS o bomba de insulina.


33
+1 excelente respuesta. Me gusta especialmente: "La falta de conocimientos básicos nunca es el problema".
Jonathan Henson

44
Gran respuesta, pero solo tiene en cuenta la ingeniería de software desde la perspectiva de los programadores. La verdadera ingeniería de software es en realidad un esfuerzo de equipo que involucra múltiples conjuntos de habilidades y disciplinas, analistas de negocios, aseguramiento de la calidad, gestión de proyectos, etc. Los incidentes son tan probablemente el resultado de una programación deficiente como los requisitos incumplidos, los requisitos mal entendidos, los proyectos mal administrados. y pruebas inadecuadas. ¿La prueba del OP menciona algo de eso? Por supuesto que no porque es para programadores.
maple_shaft

3
Sin embargo, agregaría que creo que toda la idea de IEEE es basura para empezar. Todo lo que el gobierno tiene que hacer es su trabajo para solucionar el problema. Responsabilizar a todos por los daños que puedan ocasionar a cualquier persona. Esto solo resolverá el problema
Jonathan Henson

16
No está de acuerdo con "La falta de conocimientos básicos nunca es el problema". De hecho, a menudo es el problema. ¿Con qué frecuencia los nuevos programadores (o los más antiguos) descuidan la desinfección de insumos? Verificación de caso de esquina? Para sistemas físicos, podría leer un sensor. Puede estar encendido o apagado. ¿Qué hay de roto? ¿Cómo puede saber mi software? Entonces, ¿qué hago al respecto? ¿Presume que está encendido o apagado? Estos tipos de cosas "básicas" son de hecho comúnmente en cuestión.
sdg

3
@JonathanHenson Por otra parte, considero que la mayoría de las instancias de inyección SQL son exactamente eso, sin conocimientos básicos ... pero en general, buena publicación. +1.
Jeff Ferland

72

Qué afortunado de que nadie muera gracias a la regulación médica, que nadie sea herido por fraude gracias a la regulación financiera, que nadie tenga su casa embargada gracias a la regulación de la vivienda, que nadie se corte el pelo gracias a la regulación del peluquero, y que ningún avión se estrelle nunca gracias a la regulación de aeronaves.

Obviamente, la presencia de regulación no implica la ausencia de fallas o fallas. Por el contrario, la presencia de fallas o fallas no implica que la regulación prevenga esas fallas o fallas. Los ingenieros de software ya están altamente regulados como miembros de las respectivas industrias críticas para la seguridad, y fuera de esas industrias hay poca necesidad.


10
+1 para "Los ingenieros de software ya están altamente regulados como miembros de las respectivas industrias críticas para la seguridad, y fuera de esas industrias hay poca necesidad"
Trevor Boyd Smith

3
No me gusta el tono cínico de esta respuesta. ¿Estás diciendo que no hay necesidad de regulación, ya que la regulación nunca resuelve ningún problema?
Fred Foo

8
Estoy diciendo que más allá de cierto punto, más regulación rara vez resuelve más problemas. Es obligatorio imponer ciertas prácticas de prueba de software en máquinas capaces de matar personas. Agregar un examen más de certificación de habilidades básicas al final de un programa de grado solo agrega burocracia.
Karl Bielefeldt

2
@larsmans Estoy de acuerdo con Karl, si el gobierno está tratando con un misil o algo en lo que cree que deben imponerse altos estándares, permítales contratar a sus propios programadores e ingenieros de acuerdo con el estándar que elijan. El sector privado no debería ganar dinero con el riesgo público de todos modos, eso es fascismo. Para empezar, no se debe permitir que una industria privada ponga en peligro al público. Las personas que saben lo que necesitan mejor son las personas que corren el riesgo. Déjelos manejar sus propios asuntos. Y sí, sé que Lockheed-Martin y demás hacen esto. Sin embargo, no se les debe permitir.
Jonathan Henson

3
Teniendo en cuenta la cantidad de grandes corporaciones que han perdido los datos de su tarjeta de crédito durante el último año, diría que no existe una autorregulación satisfactoria. Se podría argumentar que estos sistemas no son críticos para la vida, pero el efecto en los bolsillos de las personas puede ser tan difícil después de estos incidentes.
HorusKol

32

La historia ha demostrado, acertadamente, creo, que la diferencia entre un excelente artesano y un mediocre no puede probarse con ninguna forma de medida objetiva. El conocimiento básico no es un gran programador, la sabiduría y la experiencia, que realmente no se puede enseñar o medir objetivamente, de cómo aplicar ese conocimiento básico.

Además, estas pruebas generalmente terminan siendo solo algunas palabras de moda y procedimientos concretos y, al principio, no pueden medir nada sustantivo.

Si la industria del software quisiera desarrollar un gremio de algún tipo, esa sería una forma mucho mejor de abordar el problema. Sin embargo, la centralización solo tiene el poder de destruir la excelencia: no crearla.

Además, los problemas que esta medida está tratando de prevenir probablemente no sean detectados por una prueba de todos modos. De todos modos, también me encantaría ver a @ThomasOwens responder a esta.

Lo que sería el papel del gobierno, al menos desde la ideología estadounidense, sería responsabilizar a las compañías de software por cualquier daño a la propiedad causado por su software defectuoso o inseguro. Esto alentaría a las empresas a hacer cumplir sus propios estándares y asumir la responsabilidad personal del asunto. Esta es siempre una mejor solución, y no contiene un gobierno centralizado que sobrepase sus límites.

Actualizar

Estaba pensando en esto un poco más anoche con una cerveza o diez.

Todo lo que hizo la regulación del campo médico fue exterminar todos los paradigmas menos uno. Si su objetivo era eliminar a los médicos homeópatas y naturopáticos, a quienes el operador amablemente denominó "charlatanes", entonces dicha regulación fue exitosa. Sin embargo, no estoy de acuerdo con que tal cosa sea rentable para nadie, excepto para las personas que escriben la legislación. Piensa en lo que ha hecho esto. Ha aumentado el costo de la atención médica a niveles insostenibles, ha aumentado considerablemente los niveles de responsabilidad para los médicos y ha eliminado del mercado todo el poder de elección y autodeterminación del consumidor. No hay más mercado para ideas en la comunidad médica, y ahora se suprimen los nuevos tratamientos y formas de pensar sobre la medicina. Además, la barrera para ingresar al campo es increíblemente alta y, como resultado, tenemos una escasez de buenos MD s. Además, las agencias reguladoras tienen el poder de controlar el suministro de médicos para que a su vez puedan controlar el precio que se les paga a los médicos.

De hecho, hay algunas ganancias que hemos recibido de la regulación médica, pero los costos son demasiado altos.

Lo mismo ocurrirá con los ingenieros de software si se aprueba dicha regulación. Puedo verlo ahora, las agencias reguladoras dictaminarán que la programación orientada a objetos es el único estándar de diseño y que los programadores funcionales y de procedimiento no podrán practicar. Luego comenzarán a decirnos que no podemos administrar nuestra propia memoria porque no es segura. Luego, meterán JAVA y C # en nuestras gargantas y nos dirán que tenemos que usarlo mientras Oracle y Microsoft se vuelven más gordos y felices. La innovación será sofocada y la creatividad será prohibida. Microsoft y Google redactarán la legislación, por lo que las reglas del mercado se inclinarán hacia su propia rentabilidad y contra el bienestar social.

Además, permítanme recordarles a todos que las computadoras comenzaron como un aficionado y un esfuerzo académico. Aparte de las guerras de Unix de los años 80 y principios de los 90, hemos tenido sistemas operativos gratuitos, compiladores gratuitos, programas gratuitos, etc. Esto terminaría rápidamente. El mundo que nos dejaron Richard Stallman, Linus Torvalds y Dennis Richtie se desvanecerá gradualmente de la existencia.

En resumen, ¿me canso de tener que competir con "Te diseñaré un sitio de WordPress CMS por $ 25 por hora" o con "cualquier aplicación de iPhone por $ 500"? ¿No realmente por qué? Porque soy muy bueno en lo que hago y los clientes que quiero están dispuestos a pagar por la excelencia. Cuando asumo un proyecto de forma independiente o en mi lugar de trabajo, corro el riesgo de que mis f * & ^ ups sobre mi propia cabeza y reputación. Eso me seguirá a donde quiera que vaya. Además, la mayoría de las personas saben que obtienen lo que pagan. De todos modos, un cliente que solo está dispuesto a pagarme el precio que le pagan a su chico del césped será una pesadilla. Si el gobierno fijara la estructura legal para obligar a los proveedores de servicios a compensar sus daños, entonces habría muy pocos programadores malos que todavía tuvieran empleo en el campo.

Por cierto, todavía tenemos malos médicos, la única diferencia es que hay muy pocas fuerzas para sacarlos del mercado. Si tuvieran que asumir la responsabilidad de sus propias acciones, estarían fuera del negocio antes de tener otra oportunidad de causar estragos incompetentes sobre sus clientes.


8
Aunque estoy de acuerdo con el objetivo general de su declaración, creo que la parte más interesante es la primera oración. Caracterizas el desarrollo de software como un oficio , que es exactamente el problema . Uno no crea un puente colgante; Uno diseña un puente colgante para garantizar su eficacia y seguridad. Los ingenieros de software siguen actuando más como artesanos que ingenieros, sin importar qué título les des.
Eric Lippert

44
@ Jonathan Henson: Ciertamente no, en general. Muchas tiendas obtienen cero en la prueba de Joel. ( joelonsoftware.com/articles/fog0000000043.html ) En cuanto a si no deberían , es una decisión comercial, no una decisión moral. Todas esas cosas cuestan dinero: mucho, mucho dinero. Si está construyendo un sistema de control de aeronaves, es rentable a largo plazo asumir esos costos; si estás creando un juego de Facebook, tal vez no.
Eric Lippert

1
No, un sello de arquitecto es tan bueno como un sello de PE. Sin embargo, diría que necesitamos incorporar muchas cosas que actualmente se llaman disciplinas de ingeniería, tal como lo hace un arquitecto. Sin embargo, la arquitectura todavía se considera más como una artesanía. De todos modos, la ingeniería también es probablemente un oficio, por lo que puedo estar picando palabras sobre nada.
Jonathan Henson

1
@ Andy, supongo que deberíamos pedirle a Exchange Exchange que cambie el título de este sitio a softwareengineers.stackexchange.com :)
Jonathan Henson

1
@JonathanHenson Offend? De ninguna manera, no te preocupes! :) Debería haber dejado un poco más claro que publiqué el enlace solo porque era extrañamente coincidente con tu comentario.
Yannis

23

Noticias de Silicon Valley - 31 de junio de 2015

Horror: programador no certificado hizo abortar programa

"Nunca podré volver a correr", dice la víctima. La policía está investigando.

Criminal: Se revocó la licencia del Dr. H. Acker Jr. por uso incorrecto del puntero e intentos de lectura del archivo del sistema

El abogado dice que habrá una apelación ante la Corte Suprema.

Anuncios: los programadores de Cobol certificados en 1975 deben volver a certificarse a más tardar en 2025

La certificación IEEE confirmada no cambió desde entonces.

Anuncios: Certificación garantizada con Magic Knowledge Stuffers, Inc

Enséñese a programar en 21 días.


Estoy tratando de decidir si esta es una respuesta completa o un comentario chistoso. (¿Ambos tal vez?)
Lyndon White

@Oxinabox La fecha del 31 de junio es humorística
mosquito

"¡Enséñate a programar en 10 días!" jeje
Bћовић

20

Hay algunas formas diferentes de aplicar la regulación a cualquier profesión: un cuerpo de conocimiento bien definido, un código de ética, acreditación de programas educativos, certificación y licencias, y sociedades profesionales que apoyan el desarrollo profesional, así como los otros aspectos de un profesión. La ingeniería de software tiene la mayoría de las características de una profesión.

Me gusta pensar que comienza con el Cuerpo de Conocimientos de Ingeniería de Software (SWEBOK) y el Código de Ética y Práctica Profesional de Ingeniería de Software . Aunque la aceptación común de estos aún es bastante limitada, creo que sirven como una buena base para identificar los tipos de cosas que alguien que se identifica a sí mismo como ingeniero de software debería conocer y cómo esa persona debería actuar en calidad profesional. Eso no significa que estas son reglas estrictas, sino que estos documentos guían a los ingenieros de software profesionales en cuanto a lo que generalmente es relevante para el trabajo que se les puede pedir que hagan. El SWEBOK se revisa periódicamente para garantizar que siga siendo relevante.

La siguiente característica es la acreditación de los programas educativos. En los Estados Unidos, ABET maneja la acreditación de programas de ingeniería de software . También acreditan informática, tecnología de la información, ingeniería informática y otras profesiones relacionadas con la informática. ABET publica sus requisitos de programas acreditados en su sitio web: la ingeniería de software se considera un programa de ingeniería. El propósito de la acreditación es garantizar la coherencia entre los graduados de diferentes programas de ingeniería, al menos en términos de la materia que se enseña en el aula. No dice nada sobre la calidad de la educación.

Después de la graduación, la certificación y las licencias se utilizan para evaluar el conocimiento aprendido en el aula (y, en algunos casos, en el trabajo) frente a los cuerpos de conocimiento estándar. Aunque las escuelas acreditadas tienen un cuerpo definido de material para ser enseñado, no hay una medida de qué tan bien se enseña este material y cuánto aprenden los estudiantes al finalizar el programa. La certificación y las licencias proporcionan métodos para hacerlo: todos toman los mismos exámenes y demuestran un conocimiento en los diversos cuerpos de conocimiento en los que se basa la profesión. En ingeniería de software, el IEEE ofrece certificaciones que se basan en SWEBOK: el desarrollo de software certificado Asociado para personas mayores y recién graduados y el Profesional Certificado en Desarrollo de Softwarepara aquellos con experiencia en la industria. Para que estos agreguen valor, se requiere la aceptación de SWEBOK como una buena definición de lo que es la ingeniería de software.

Finalmente, las sociedades profesionales mantienen los documentos guía para la profesión, facilitan conferencias y publicaciones para el intercambio de conocimientos e ideas, cubren brechas entre la academia y la industria, etc. Las dos sociedades líderes son la IEEE Computer Society y la ACM , pero hay otras sociedades en todo el mundo. Estos envuelven todo en un pequeño paquete agradable y ayudan a entregar información a las personas adecuadas.

A partir de aquí, hay otras preguntas que hacer. ¿Es el desarrollo de software una disciplina de ingeniería? ¿La certificación o la licencia agregan algún valor a los ingenieros de software? ¿Es útil la certificación?

No creo que todo el desarrollo de software necesite el rigor de una disciplina de ingeniería. Eso no quiere decir que un estudio empírico y científico de la ciencia y la ingeniería del software de construcción no ayude a todos, lo hace. Sin embargo, hay una gran diferencia entre desarrollar el último videojuego, desarrollar el software integrado para un marcapasos o construir la próxima nave espacial. El énfasis es diferente en todos ellos: dos de los tres merecen la atención de un ingeniero experto. El otro puede aprender de las prácticas de ingeniería, pero no necesita confiar en ellas para completar con éxito el proyecto.

La certificación y la licencia requieren un cuerpo de conocimiento aceptado. El SWEBOK es un buen documento que proporciona una base sólida, pero no es ampliamente aceptado. A menos que pueda basar sus programas académicos y exámenes de certificación / licencia en algo concreto que sería aceptado por los profesionales, entonces realmente no tiene sentido. Si el SWEBOK o el documento alternativo se acepta ampliamente (al menos en aquellos campos que requieren el rigor de la ingeniería), entonces los exámenes de certificación o licencia pueden usarse para medir la comprensión del conocimiento requerido.

Sin embargo, hay un problema evidente con la certificación: es una prueba en un libro. Algunas personas son buenas para leer, aprender, memorizar y tomar un examen. Sin embargo, eso no significa que sean buenos ingenieros. La gente se desliza por las grietas todo el tiempo. Una certificación o licencia es solo un paso. En el trabajo, la capacitación y el asesoramiento de otros ingenieros experimentados es obligatorio para preparar a un buen profesional. Además, la capacidad de evitar que las personas practiquen en entornos críticos también puede ayudar a mitigar los riesgos para la sociedad y las empresas.

Un buen libro con una discusión bastante profunda sobre esto es el Desarrollo de software profesional de Steve McConnell : horarios más cortos, productos de mayor calidad, proyectos más exitosos y carreras mejoradas .


Estoy un poco deprimido, así que si me perdí algo o algo no tiene sentido, tócame y lo arreglaré. Gracias chicos.
Thomas Owens

"dos de los tres merecen la atención de un ingeniero experto" tienes razón, naves espaciales no son tan difíciles de hacer
zzzzBov

+1 gracias por agregar su opinión sobre el asunto. Espero que te sientas mejor.
Jonathan Henson

12

Si se aprueban las regulaciones gubernamentales, la industria del software en los EE. UU. Se contraerá significativamente, porque el costo asociado con el cumplimiento de esas regulaciones será más alto de lo que las nuevas empresas y las pequeñas empresas pueden pagar.

La escasez y el costo asociados con un título de Derecho o un Doctor en Medicina serán más o menos visibles en nuestra industria. No es bueno cuando la alternativa es que cada Joe podría construir el próximo Facebook.

La gente comete errores, y ninguna cantidad de regulación evitará que ocurran desastres. Considere la NASA, que tiene los requisitos más estrictos para el desarrollo de software conocidos por el hombre. ¿Todavía tienen errores de software? (Sí, sí, y muchas veces, ¡sí!)

El mercado resuelve estos problemas mucho mejor que las regulaciones. Las empresas que crean software que causa problemas son responsables por las personas a las que lesionan. El resto de nosotros no necesita pagar por sus errores.


8
Una adición fantástica a esta respuesta sería una lista de compañías de software existentes que probablemente no se habrían iniciado si estas regulaciones estuvieran vigentes. Microsoft y Facebook son un buen comienzo, ya que una certificación probablemente requeriría un título (casi todas las profesiones que comienzan con las pruebas agregan un requisito de grado si no comienzan con una).
psr

1
@maple_shaft, la OMI que compara médicos / abogados con la ingeniería de software no es válida. Los campos son demasiado diferentes para comparar (consulte la respuesta de Jarrod Nettles para ver por qué no puede comparar la ingeniería de software con los médicos / abogados).
Trevor Boyd Smith

1
@maple_shaft: insinúa que la certificación mejoraría la calidad de la ingeniería. Soy bastante escéptico, ese sería el resultado. Creo que el tiempo dedicado a estudiar para la mayoría de las pruebas es tiempo no dedicado a aprender una mejor ingeniería.
psr

44
Creo que todo el mundo está asumiendo que no está comprobado que otorgar licencias a médicos y abogados en realidad mejora la calidad de los médicos y abogados. Soy muy escéptico de esa suposición. Todo lo que garantiza la licencia es que los médicos y abogados pueden cobrar tarifas escandalosas y no hay nada que nadie pueda hacer al respecto. En ese sentido, estoy a favor de licenciar ingenieros de software. No mejorará la calidad del software ni un ápice, pero seguramente nos hará ricos a muchos de nosotros, los desarrolladores de software. Jaja cuando el gobierno arresta al chico de secundaria por practicar software sin licencia.
Dunk

1
@maple_shaft que depende completamente de la naturaleza de la falla - Facebook no responde no es crítico (más allá de afectar los bolsillos de los inversores) - Facebook hacer que todos sus datos personales y mensajes privados estén disponibles para cada usuario de Internet es un asunto diferente. Además, las aplicaciones / juegos que toman detalles de tarjetas de crédito (como en Facebook) al liberar accidentalmente detalles de tarjetas de crédito tendrían serias repercusiones.
HorusKol

11

En 1999, el ACM emitió una declaración sobre licencias cuando se retiró en gran medida del trabajo de IEEE SWEBOK. Después de revisar los documentos SWEBOK disponibles públicamente y la declaración de ACM, apoyo la opinión de ACM.

Echando un vistazo al artículo, se requiere que alguien con 4-6 años de experiencia tome el examen, que evalúa los conocimientos básicos. Eso es más que ridículo, y debería reírse por la puerta.


10

Los componentes de software de un dispositivo son un detalle de implementación. Por ejemplo, en la industria de los sistemas de control, todos los dispositivos de seguridad solían estar cableados y la gente no confiaba en el software. Sin embargo, ahora estamos viendo dispositivos de seguridad basados ​​en software como relés de seguridad y PLC de seguridad. Estos son permisibles porque todavía tienen que cumplir con las regulaciones de la industria para dispositivos de seguridad (dependiendo de la categoría de seguridad). Por lo tanto, en algunos casos los dispositivos necesitan procesadores redundantes y código redundante escrito por dos equipos diferentes, etc.

Es el producto que debe cumplir con las pautas de seguridad para que el público pueda venderlo y consumirlo. Esas reglas no cambian porque el producto contiene software. El trabajo del ingeniero es asegurarse de que el producto cumpla con todos los criterios reglamentarios y, si contiene software, deben revisarlo y ser competentes en ese campo . Si no lo están, ellos (o su compañía) son responsables si aprobaron el diseño y resulta ser defectuoso.

Realmente no es necesario regular a todos los programadores solo porque algunos productos deben cumplir con requisitos más estrictos. En los casos en que dichos productos involucren software, necesita una disciplina de ingeniería bien desarrollada que pueda determinar de manera confiable que el componente de software cumple con los requisitos. En todo caso, eso es lo que significa el IEEE: el campo relativamente joven de la ingeniería de software debe desarrollarse al nivel de confiabilidad y confianza de otras disciplinas de ingeniería.

Realmente no tiene nada que ver con "programación" y todo que ver con "ingeniería".

Esto, por supuesto, nos devuelve al tema polémico de la diferencia entre un desarrollador y un ingeniero. Estos son generalmente dos roles diferentes que se superponen regularmente. La parte del desarrollador significa que haces software. La parte de ingeniería de la función significa que si estampa el diseño, asume la responsabilidad de la seguridad pública. Usted puede ser uno sin el otro.


55
+1 En mi humilde opinión, lo que realmente estás insinuando es que la regulación debe estar en el producto, no en los ingenieros. Por ejemplo, las regulaciones (aprobaciones) necesarias para los sistemas de alarma de incendio e intrusión aseguran que el software funcione, no la capacidad de los ingenieros que lo escribieron. (Muchas de las regulaciones son muy parecidas a cuando los sistemas estaban hechos completamente de circuitos electrónicos.)
jwernerny

8

El software ya está estrictamente regulado en la industria aeronáutica. Ver DO-178B .

Estoy seguro de que otros subconjuntos de la industria tienen sus normas.

El "software" abarca mucho en estos días. Creo que sería absurdo tener una regulación obligatoria que lo abarque todo.


4

La regulación de la industria del software se realiza mejor a través de la regulación de los procesos de Garantía de Calidad.

Esto ya está hecho: las grandes compañías de software tienen multitud de probadores, gerentes de control de calidad, suites de pruebas automatizadas, procesos de revisión de código, procesos de prueba, y así sucesivamente. Hay compañías cuyo propósito es realizar auditorías de calidad de software en otras compañías. Las organizaciones de estándares tienen pautas para el control de calidad y para las auditorías de control de calidad.

Dentro de una empresa, un ingeniero de software es responsable de la calidad de su trabajo. Sin embargo, sus controles y contrapesos se encuentran en los procesos de calidad de la empresa.


2
Esta es exactamente mi opinión. La industria de la aviación tiene reglas estrictas para programar el control de calidad y las pruebas. Las empresas necesitan auditar sus activos de información e implementar más pruebas y revisiones. Creo que estos son los días oscuros del software, porque muchos todavía están cortando esquinas al no hacer lo que saben que es lo correcto, y los propios desarrolladores no son suficientes para cambiar la industria.
Tjaart

Gran punto: el software que ejecuta el dispositivo es tanto responsabilidad de la empresa para una ingeniería buena y segura como lo es para la ingeniería industrial.
Jarrod Nettles

3

Es lo mismo que la mayoría de los intentos modernos de resolver "problemas relacionados con el software". Aquellos que intentan legislar tienen poco conocimiento de la raíz del problema. Si sigue el proceso prescrito (y la intención, por supuesto) al desarrollar un software crítico para la seguridad, sea que para las aeronaves, las plantas nucleares de equipos médicos, un solo error nunca será suficiente para causar una falla. Un algoritmo completo puede implementarse incorrectamente sin que nadie resulte perjudicado.

La FDA y el TLC requieren un análisis de riesgos y, en base a eso, una estrategia de mitigación. La última suele ser una estrategia de queso suizo donde uno acepta que cualquier mitigación es defectuosa, por lo que se aplican múltiples mitigaciones para el mismo riesgo (una mitigación también se puede aplicar a varios riesgos) cada mitigación es como una rebanada de queso suizo que puede ver a través de uno, tal vez dos rebanadas juntas, pero junte suficientes rebanadas y eso ya no es posible. Incluso cuando las mitigaciones se implementan perfectamente, eso no da como resultado un equipo 100% seguro. Si el análisis de riesgos es incorrecto, habrá riesgos en los que nadie pensó (Y2K).

Puede probar a los ingenieros todo lo que quiera, incluso podría probar sobre el tema y requerir un nivel extremadamente alto, pero sería muy importante. La mayoría de los errores críticos de seguridad son errores de integración. No son errores en el código de un solo hombre, sino que surgen debido a desalineaciones entre el software y el hardware de dos sistemas de software o porque una partícula alfa eliminó el contador del programa de su ubicación correcta.

He estado en varios sistemas críticos de seguridad con desarrolladores altamente experimentados y capaces, que pasarían cualquier prueba sensata en su campo. Nunca he estado en un proyecto donde no tuvimos un error crítico de seguridad. (Afortunadamente, nunca he estado en uno donde el sistema haya dañado a alguien)


1
+1 - Para: "La mayoría de los errores críticos de seguridad son errores de integración". De hecho, con todo el proceso por el que pasamos casi nunca hay un error de codificación. El 99,98% de las veces es un problema de comprensión entre diferentes módulos y dispositivos en cuanto a cómo se suponía que debían funcionar.
Dunk

@ Dunk, gracias, en realidad es un qoute de Levison. Un hecho que quería incluir en el texto, pero parece que lo olvidé :)
Rune FS

2

Uno nunca puede eliminar completamente a los charlatanes y charlatanes porque existen en casi todas las profesiones, incluso en las profesiones médicas a pesar de las prácticas y tradiciones establecidas desde hace mucho tiempo.

Sin embargo, dado que esta afirmación es un acaparamiento de tierras, no estoy seguro de qué oscuro y aterrador señor de todas las cosas que TI está diabólicamente tramando su control y regulación sin restricciones del desarrollo de software. Si de hecho está hablando del IEEE, ciertamente tienen un aspecto regulatorio, pero el cumplimiento de los estándares del IEEE es más o menos a voluntad, y no a punta de pistola. Están tratando de desarrollar estándares universales de la industria para que todos hablemos el mismo idioma y aumentemos la eficiencia en todos los ámbitos.

Además, los estándares que establecen ayudan a legitimar las prácticas comunes y sientan las bases para que el desarrollo de software se convierta en un campo de ingeniería más disciplinado, no muy diferente de la ingeniería mecánica o la ingeniería química. Si bien el software se está acercando a ese objetivo, es probable que nunca sea completamente aceptado universalmente como una disciplina de ingeniería.

El problema central es que un desarrollador de software podría estar haciendo cualquier cosa, desde escribir un widget de escritorio bonito, hasta implementar sistemas de guía de misiles. En uno, la gravedad y la consecuencia del error es mucho mayor que el otro, y por lo tanto exige una disciplina de ingeniería estrictamente regulada para abordar de manera razonable, segura y eficiente. Esto es muy parecido a la gravedad del error en un puente que se diseña incorrectamente y que se derrumba como resultado. Los diseñadores del puente deben cumplir con mis estándares de ingeniería para garantizar la calidad.


44
Por lo general, dichas regulaciones también son requisitos legales. Por ejemplo, ingeniería civil que requiere un PE
Paul Nathan

@PaulNathan Buen punto, por eso la progresión natural a una disciplina universalmente aceptada comienza en la autorregulación (por ejemplo, MPAA) y finalmente conduce a la regulación por ley (juntas estatales, FCC, etc.)
maple_shaft

77
No creo que el desarrollo de software esté listo para la autorregulación, ni siquiera cerca de él. Francamente, la idea de que los "ingenieros reales" tienen "calidad real" es una especie de broma para mí. Los transbordadores espaciales han explotado, los cohetes se han encendido, los puentes se han caído, los edificios se han derrumbado ... etc. Sería bueno tratar de imponer calidad desde arriba, pero, jaja.
Paul Nathan

1
Al comparar la ingeniería mecánica con la ingeniería de software, me pregunto cuál sería el análogo de ingeniería del mundo real para algo así como los sistemas operativos modernos.
FrustratedWithFormsDesigner

1
@maple_shaft: el problema central será que no puedes usar Linux / BSD / grep / vi / Firefox, etc., porque no están escritos por un SE oficial. Mientras que alguien con un certificado MSCE en VB estará bien.
Martin Beckett

1

No lo llamaría una regulación más estricta, sino barreras de entrada. En ese sentido, creo que hay mérito. Para una mayor calidad, eso es muy discutible.

Actualmente, cualquier John / Jane Doe puede escribir un programa. No hay barrera de entrada. Elija algunos libros sobre secuencias de comandos y tecnología web y comience a piratear, o peor aún, comience a buscar en Google cómo "hacerlo".

Cuando nosotros, como un todo colectivo, decidamos que tal vez es hora de aumentar las barreras de entrada, mantener a la industria a un nivel más alto, evolucionar de hacker / artesano a ingeniero, ese tipo de regulación en la que estoy metido.

Hay demasiados individuos no calificados que programan hoy. Ya sea que funcionen o no en sistemas críticos, todavía están produciendo código, todavía producen Big Balls of Mud .

En ese sentido, la autorregulación o la creación de barreras de entrada más acertadamente es algo bueno. Porque estamos diciendo, oye, no puedes salir de la calle y llamarte ingeniero de software. En realidad, tienes que demostrar un nivel de habilidad.

Demostrar habilidad es más que solo tomar una prueba u obtener una "insignia de honor". Una prueba es solo una validación. La validación real es la escuela, la pasantía, el aprendizaje, la tutoría para personas mayores, la práctica, todo es parte de ella.

Puedo ver lo que el IEEE está tratando de lograr, pero en este punto es un ejercicio infructuoso. La industria cambia rápidamente, hay demasiada demanda para sacar el producto por la puerta, la mentalidad de "pirata informático", etc. La regulación tiene que venir desde dentro, si es que lo hace.


Doy +1 porque debería haber alguna forma de evitar el riff-raff de ciertos tipos de sistemas. Sin embargo, doy -1 porque la mayoría del software actual puede ser desarrollado adecuadamente por piratas informáticos y evitar que puedan proporcionar ese servicio para mantener bajos los costos va en contra del interés público. Del mismo modo, lo mismo ocurre con abogados y médicos. El 90% de lo que hacen puede ser manejado de manera bastante rentable e igual de competente por personas con calificaciones inferiores. Sin embargo, con las leyes de hoy son libres de destripar al público a voluntad.
Dunk

¿No deberían evaluarse las habilidades durante el proceso de contratación? Oh, espera, RR. HH. Contrata a personas en función de las credenciales en papel (que no demuestran el conocimiento aplicable en el desarrollo de software) y las personas de RR. HH. No saben absolutamente nada acerca de las necesidades / requisitos para desarrollar software. Double fail ...
Evan Plaice

0

No he leído el artículo, pero si la pregunta es si la regulación de la industria del software puede beneficiar a la humanidad, creo que depende de las circunstancias:

  1. La industria en su conjunto abarca una amplia variedad de dominios, algunos de los cuales son críticos para la vida (por ejemplo, controlar la dosis de radiación en un dispositivo médico), y otros no (la aplicación de Facebook "¿Qué Muppet eres?"). No puedo ver ningún argumento a favor de la regulación para aplicaciones donde las apuestas son bajas.

  2. Uno no debe comenzar con la regulación legal. Más bien, uno debe comenzar con un programa de certificación para desarrolladores. Solo si el programa de certificación produce algún beneficio medible debería haber una cuestión de regulación legal.

  3. Incluso si un programa de certificación produce resultados medibles, es probable que la industria se estandarice al requerir esta certificación por razones estrictamente comerciales, y no necesitaríamos una regulación legal. (Es por eso que existen delegaciones como MCSE : las empresas prefieren contratar MCSE para los dominios en los que se capacita a MCSE).

  4. Dicho todo esto, todavía quedan dominios en los que tiene sentido comercial causar daño (a menudo, estas son externalidades negativas , a veces son el resultado del poder de mercado para algunas instituciones). Por ejemplo, un área puede tener un solo hospital local; en este caso, la calidad del software de back-end puede marcar una gran diferencia en el nivel de atención que recibe un paciente, pero no hace mucha diferencia en qué hospital elige el paciente. Entonces, el hospital no necesariamente tiene muchos argumentos comerciales para invertir en desarrolladores de mayor calidad. En este caso, puede haber un caso de salud pública para regular a los desarrolladores que el hospital puede contratar.

EN MI HUMILDE OPINIÓN.


0

Tengo que responder a esta ...

Comenzando con lo que dijo @JonathanHenson y la entrada de @gnat, lo que digo está bien, las personas que tienen dinero pueden pagar por cosas certificadas, las personas o países que no tienen dinero no pueden pagar por las licencias (tanto por cosas certificadas ), por lo que aún habrá renegados si eso se pone en práctica. Incluso si los métodos de entrega tradicionales (y no tan tradicionales) están cerrados, las personas aún encontrarán formas de entregar software a los usuarios interesados. Incluso si significa desarrollar otro protocolo HTTP o incluso una pila de red completa alternativa, solo enfocada en hacer que las conexiones sean indetectables (vea el último párrafo, para alguien que pueda hacer esto).

Además, la idea de pagar por algo está en riesgo, ya que el mundo se está volviendo cada vez más pobre, por lo que cada vez más personas tendrán cada vez menos dinero para pagar las cosas, incluso hay países que solo usan el software FOSS, sin ningún tipo de certificación (Brasil e India vienen a la mente, pero hay otros seguros), y algunos de esos países se están volviendo grandes, realmente grandes. Y utilizan software no certificado creado por programadores desconocidos, cuya habilidad es desconocida.

Además, incluso si hay algún tipo de certificación, la certificación solo certificará el conocimiento, no la ética, solo piensa que algunos médicos usan órganos que las personas extraen de manera no autorizada, por lo que también habría programadores certificados que no tiene ética y escribe código descuidado ya sea intencionalmente o no. Mientras que en la mayoría de los proyectos FOSS, la mayoría de los programadores potencialmente no calificados también revisan el código de otros e intentan encontrar errores, de una manera que hace que la programación de pares sea algo poco.

Por último, ¿qué dices de los grupos de piratería (no grupos de piratas de sombrero negro, sino grupos de sombrero blanco o gris), que saben mucho más sobre seguridad y desarrollan software de seguridad de una manera que solo coincide con los programadores más especializados de ciertos departamentos gubernamentales.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.