Portada
mis comunidades
otras secciones
#3:
"Al día de hoy día muchos programadores de software alegan frases como “nadie murió por un error en el código“. Seguramente ellos no conozcan la historia de la Therac 25."
No hace falta conocerla. Si la máquina fallaba es porque no se probó lo suficiente antes de sacarla al mercado. NO EXISTE EL PROGRAMADOR PERFECTO QUE HAGA UN PROGRAMA PERFECTO A LA PRIMERA. En TODOS los programas del mundo hay errores. La culpa, evidentemente no es del programador, es del tío que dijo: "ok, terminado, funciona perfecto y sin errores".
“nadie murió por un error en el código“. La gente murió porque las cosas no se prueban como dios manda.
No hace falta conocerla. Si la máquina fallaba es porque no se probó lo suficiente antes de sacarla al mercado. NO EXISTE EL PROGRAMADOR PERFECTO QUE HAGA UN PROGRAMA PERFECTO A LA PRIMERA. En TODOS los programas del mundo hay errores. La culpa, evidentemente no es del programador, es del tío que dijo: "ok, terminado, funciona perfecto y sin errores".
“nadie murió por un error en el código“. La gente murió porque las cosas no se prueban como dios manda.
#12:
#3 Eres programador, no? Es que yo fui testeador en el departamento de control de calidad de un software y también puedo decir que "NO EXISTE EL CONTROL DE CALIDAD PERFECTO QUE DETECTE TODOS LOS ERRORES A LA PRIMERA". Así, también en mayúsculas. La cuestión es pasar siempre el muerto a otro (y desgraciadamente, nunca mejor dicho) 
#13:
#12 precisamente porque ni todos los programas estan bien programados a la primera, ni existe control de calidad que detecte todos los errores a la primera, se DEBEN PROBAR LAS COSAS COMO DIOS MANDA (siguiendo con las mayúsculas).
No paso el muerto a nadie, tan solo digo que no se probó lo suficiente.
No paso el muerto a nadie, tan solo digo que no se probó lo suficiente.
#15:
Si miramos la Wikipedia podemos ver que no fue un solo error, sino una cadena de errores de diseño y programación que podía derivar en un mal uso: http://es.wikipedia.org/wiki/Therac-25
La cantidad de errores es bestial, solo se puede explicar si hicieron el diseño y la puesta en marcha sin realizar un solo test.
La cantidad de errores es bestial, solo se puede explicar si hicieron el diseño y la puesta en marcha sin realizar un solo test.
#18:
Del enlace a la wikipedia de #15:
La falla sólo ocurría cuando una secuencia particular de teclas era ingresado en la terminal VT-100 que controlaba la computadora PDP-11: la X que (erróneamente) seleccionaba el modo de fotones de 25MV, seguido de "cursor arriba", "E" que (correctamente) seleccionaba el modo de electrones de 25MeV y luego "Enter". Esa secuencia de pulsaciones era improbable, y por lo tanto el problema no ocurría muy seguido y fue desconocido por un largo tiempo.
Que cachondo el programador metiendo el konami code en una máquina de hospital.
La falla sólo ocurría cuando una secuencia particular de teclas era ingresado en la terminal VT-100 que controlaba la computadora PDP-11: la X que (erróneamente) seleccionaba el modo de fotones de 25MV, seguido de "cursor arriba", "E" que (correctamente) seleccionaba el modo de electrones de 25MeV y luego "Enter". Esa secuencia de pulsaciones era improbable, y por lo tanto el problema no ocurría muy seguido y fue desconocido por un largo tiempo.
Que cachondo el programador metiendo el konami code en una máquina de hospital.
#14:
A mi abuelo en el Hospital de León se lo cargaron al darle una sesión para disolver piedras en el riñón demasiado fuerte con una máquina nueva "Lithostar Modularis de Siemens" que o no estaba bien calibrada o no tenían ni puta idea de usar...
#10:
Los peores bugs de la historia - http://axxon.com.ar/not/156/c-1560164.htm (aparece el Therac 25)
Comentarios
"Al día de hoy día muchos programadores de software alegan frases como “nadie murió por un error en el código“. Seguramente ellos no conozcan la historia de la Therac 25."
No hace falta conocerla. Si la máquina fallaba es porque no se probó lo suficiente antes de sacarla al mercado. NO EXISTE EL PROGRAMADOR PERFECTO QUE HAGA UN PROGRAMA PERFECTO A LA PRIMERA. En TODOS los programas del mundo hay errores. La culpa, evidentemente no es del programador, es del tío que dijo: "ok, terminado, funciona perfecto y sin errores".
“nadie murió por un error en el código“. La gente murió porque las cosas no se prueban como dios manda.
#3 llevas la razon
#3 Eres programador, no? Es que yo fui testeador en el departamento de control de calidad de un software y también puedo decir que "NO EXISTE EL CONTROL DE CALIDAD PERFECTO QUE DETECTE TODOS LOS ERRORES A LA PRIMERA". Así, también en mayúsculas. La cuestión es pasar siempre el muerto a otro (y desgraciadamente, nunca mejor dicho)
#12 precisamente porque ni todos los programas estan bien programados a la primera, ni existe control de calidad que detecte todos los errores a la primera, se DEBEN PROBAR LAS COSAS COMO DIOS MANDA (siguiendo con las mayúsculas).
No paso el muerto a nadie, tan solo digo que no se probó lo suficiente.
#3, #12, #13 Es un problema de concepto. Es imposible demostrar que no hay errores. Las pruebas deben orientarse a localizarlos.
#12 No es cuestión de pasar el muerto pero si trabajas en un control de calidad la responsabilidad recae sobre dicho controlador, es tu trabajo verificar. Todos entendemos que todos somos humanos y cometemos errores.
#3 amen hermano!
Los peores bugs de la historia - http://axxon.com.ar/not/156/c-1560164.htm (aparece el Therac 25)
Si miramos la Wikipedia podemos ver que no fue un solo error, sino una cadena de errores de diseño y programación que podía derivar en un mal uso: http://es.wikipedia.org/wiki/Therac-25
La cantidad de errores es bestial, solo se puede explicar si hicieron el diseño y la puesta en marcha sin realizar un solo test.
Del enlace a la wikipedia de #15:
La falla sólo ocurría cuando una secuencia particular de teclas era ingresado en la terminal VT-100 que controlaba la computadora PDP-11: la X que (erróneamente) seleccionaba el modo de fotones de 25MV, seguido de "cursor arriba", "E" que (correctamente) seleccionaba el modo de electrones de 25MeV y luego "Enter". Esa secuencia de pulsaciones era improbable, y por lo tanto el problema no ocurría muy seguido y fue desconocido por un largo tiempo.
Que cachondo el programador metiendo el konami code en una máquina de hospital.
#18 Era un Easter Egg.
A mi abuelo en el Hospital de León se lo cargaron al darle una sesión para disolver piedras en el riñón demasiado fuerte con una máquina nueva "Lithostar Modularis de Siemens" que o no estaba bien calibrada o no tenían ni puta idea de usar...
Relacionada: Software asesino, 9 muertos, 14 heridos graves
Software asesino, 9 muertos, 14 heridos graves
itweb.co.zaPues a mí estos me dan miedo.
http://thearchnemesis.com/images/bug.jpg
http://www.thefilmyap.com/wp-content/uploads/2009/08/starship_troopers_bugs.jpg
¡Recios de Raszac!
¡La infantería pelea
y la flota se pasea!
#7 Rico! You know what to do!!
Muy interesante, sobre todo ahora que en la lista de correo del Concurso Universitario de Software Libre se ha alzado un flame sobre si la Ingeniería del Software es necesaria o no.
#1 ¿? O de los programadores de videojuegos??
------
Lo del 'error informático' es demasiado fácil. Así todos piensan 'la culpa del que programó'... VENGA YA!!! El q lo programó no era médico, así q culpa de los tests.
La redacción de la noticia deja mucho que desear, que parece que los que tienen la culpa de todo, siempre, los informáticos!!
Desde luego estas cosas no deberían ocurrir, hay que hacer los controles rigurosos y comprobar que las cosas de verdd funcionan, no cagarla al final, cuando ya s stán utilizando esas máquinas, y decir 'uis! fallo informático!'.
#2 Edito, pq te leí y no me enteré, y al releer.... No entiendo que se pueda plantear la utilidad de la Igeniería del Software! Está claro que sin ella un proyecto de cualquier tipo se va a la mierda!
Reedito! #28 Aplauso!!!!
#29 O por ejemplo, si resulta que el software falla por una casuística extraña provocada por un error del compilador o intérprete. ¿Empapelamos al que ha hecho el compilador? A ver quien tiene huevos de ponerse a desarrollar esas cosas entonces.
Es un error hacer analogías entre Ingeniería Informática y Mecánica por ejemplo. En la mecánica hay un marco físico que acota la complejidad, en informática tienes N capas o abstracciones todas dependientes de ámbitos distintos.
#31 Estoy de acuerdo contigo eh? El caso es que lo que más se oye en todos lados es 'fallo informático' y ale, todos tan contentos. Y todo el mundo piensa 'a por el programador, que puso mal un for y se cargó a X personas!'. Entonces.... la culpa sería de los tests q s hicieron al aparatito, que eran 1 asco, o quizá de múltiples factores que por desgracia se juntaron y provocaron el desastre. Pero no, lo más fácil es decir 'fallo informático'.
#35 Sí, se abusa demasiado del "fallo informático". Tienes toda la razón. Es un problema ya que si encima de que los fallos informáticos son difíciles de detectar, lo utilizamos sistemáticamente como excusa cuando muchas veces el fallo es claramente a otros niveles, mal asunto. Por ejemplo, hace poco en un hospital ví un cartel que decía algo como "debido al nuevo sistema informático pueden darse grandes colas de forma imprevisible". Y efectivamente, vaya caos. Digo yo que un software de gestión no es tan difícil probarlo mínimamente para asegurar una calidad sin tener que molestar a los pacientes que muchos bastante tendrán con lo suyo. Pasa lo de siempre, concesiones a empresas que promenten oro por cuatro duros, becarios explotados, proyecto entregado como finalizado cuando no ha habido pruebas casi ni por parte de los desarrolladores (alfa).
En el caso del Therac se juntaron varios factores y el software no tenía un error, tenía muchos.
Resulta que reutilizaron código de una versión anterior de la máquina que no había dado ningún problema...luego descubrieron que el código estaba mal pero que no daba problemas porque la versión anterior de la máquina tenía una serie de medidas de seguridad hardware que la nueva no tenía.
Además había varias condiciones de carrera, el interfaz de usuario era poc claro... Vamos, es todo un ejemplo de cómo NO hacer software
Y quien no prueba el efecto de ingredientes en productos? Mucho mas devastadores. Asbestos, plomo en la pintura, nicotina, mercurio,...
" vió una extraña cara de ansiedad en el operario"
El equipamiento de radioterapia, lleva un control de calidad brutal. Se hacen controles de calidad mensuales, anuales y diarios. Se controla la mecánica, la dosis, los tratamientos, y tambien el planificador, que es el software que "diseña" el tratamiento y le dice a la máquina lo que tiene que hacer. En caso de que la máquina falle, el error se debe detectar antes de que el tratamiento se suministre al paciente, ya que se comprueba todo. Si había un error de programación, debía haberse detectado 2 o 3 veces antes de tumbar al paciente. Todo esto, es trabajo del radiofísico, por tanto, la responsabilidad es suya.
Yo he trabajado en el departamento de informática de un hospital... Si supierais algunos detalles, más de uno no pisaría un hospital en su vida.
Voy a dar uno solo respecto a la informática. La aplicación que se encargaba de la gestión de los medicamentos para cada paciente, un buen día le dio por cambiarla a una planta entera, o sea, había pacientes que tenían que recibir una medicación concreta y la aplicación se encargó de cambiarla por la de otro paciente de la misma planta pero con otra enfermedad. Por fortuna para ellos las enfermeras les pareció raro que pacientes que llevaban ya una semana se le cambiase la medicación por otra que no tenía mucho sentido y dieron la voz de alarma.
Lo peor de todo es que no es la primera vez que falla esa aplicación.
#40 deberíais pedir responsabilidades al ingeniero que firmase ese proyecto de software.
Oh, que el software no va firmado .. pues nada
#44 Oh!!! Que el software lo vendio una empresa... uY claro, lo logico es pedirle responsabilidades al programador... no a la empresa que es la que dicta como y cuando se comercializa el producto!!!
Y ay! si! que el colegio de informaticos revisaria cada linea de codigo de cada proyecto que haria cualquiera de sus colegiados. Igual que el de arquitectos y el de ingenieros realiza 3 veces los calculos de cada uno de los elementos que componen los proyectos de sus colegiados.
Uh!! sopresa! que el ningun colegio ni asociacion iba a solucionar este tipo de fallos!!! porque simplemente no revisan los proyectos, y normalmente los proyectos los hace otra gente y sus colegiados solo cobran por firmar!!! Tambien sin revisar
A quien tendran que pedirle responsabilidades será al que les VENDIO el producto sea persona fisica o juridica y este ya repercutira dichas "sanciones". pero no, segun tu, el cliente iria al colegio y el presidente del colegio entraria en mi oficina y cogeria de la oreja al que se sienta 3 filas detras de mi, por malo malo mal.
Repito... cansinos y/o mentirosos!!!
#60 espera, espera .. que en los colegios recalculan tres veces cada proyecto para visarlo ? Aaaaaaaaaay que me LOL !!
! De qué planeta hablamos, Omicrom Ingenieril 4º ? Porque en el planeta Tierra, con suerte comprueban que estén ciertos documentos en regla para no pillarse los dedos y a partir de ahí a cuñar sin más miramientos.
Los colegios, las atribuciones, las competencias, no es que se las tengan que dar a los informáticos, es que tienen que desaparecer, TODAS. En España hay más mafia en los colegios que en los partidos políticos, lo único que hacen es mantener VAGOS.
Una reevaluación periódica, y el que valga y sepa trabajar competentemente, que trabaje, y el que no, por muchas competencias y mucho número de colegiado que tenga, a dedicarse a otra cosa, punto.
Luego se vencen las naves agrícolas, se levantan las carreteras, se vuelven locas las máquinas de una fábrica y la culpa para el currito, claro claro ..
#62 y un arquitecto puede estar 100% convencido de que la viga que ha colocado en un edificio no viene con burbujas en la aleación por un fallo en la fundición. Y un teleco sabe a ciencia cierta que ese script que ha programado para su proyecto en una empresa de comunicaciones no tiene bugs de software.
Y el industrial que programa aquel robot para una línea de producción, también firma el proyecto a sabiendas de que sus mil líneas de código no tienen un solo error.
Bueno y si lo tienen ya lo detectan en los colegios respectivos del planeta donde vive #60 claro, claro ..
Repito; no defiendo atribuciones para los informáticos, me parece que las atribuciones en general, son del siglo pasado. En España concretamente de cuando Franco, y si las ingenierías informáticas hubiesen existido entonces, no dudéis de que también tendrían atribuciones, colegios y toda esa parafernalia inútil.
Por lo tanto aquí habría que aplicar la máxima de "o f*llamos todos, o la p*ta al río", y por mi, al río con ella.
Aburrís.
#66 yo prefiero "la p*ta al rio".
La viga que usaran tiene una garantia de que no va a fallar. Se hacen pruebas, el edificio se construye para soportar dos o tres veces el peso que tiene que aguantar.
Si yo soy el que tiene que tirar codigo(la viga) ten por seguro que no tendras suficiente dinero para pagar el que vaya a cargar con las culpas si algo sucede.
Y si yo no cargo con ellas sera el ingeniero que para eso cobraria mas y debe ser el que se responsabilice de que no falle nada.
Ten por seguro que yo seré el primero en pagar por un software que me aseguren no falla, porque pienso forrarme a costa el imbécil que haya firmado el proyecto.
#44 Se te nota que no tienes ni idea de ingenieria informatica.
Hay una cosa sobre desarrollar aplicaciones que cualquiera con dos dedos de frente sabe:
Nunca puedes asegurar que un codigo este libre de errores, solo demostrar que los tiene.
Así que si piensas que puedes firmar un proyecto diciendo "esta todo correcto" vas jodido. Podrás revisar el código letra a letra y ni aún así asegurar que todo este correcto.
#40 Me parece acojonante que nadie tenga la responsabilidad sobre esa aplicación. Si en un cortocircuito muere algun paciente de esa misma planta planta, van: a por el ingeniero que realizó el proyecto, a por el que dirigió la obra, a por el instalador, a por el organismo de control de que realizara la inspección y a por los técnicos de industria.
El ficticio caso del "Robot asesino", donde se estudian las implicaciones éticas, la responsabilidad del programador, las presiones contractuales, los intereses empresariales para adelantar (incluso falsear) los tests del software, etc.:
http://www.onlineethics.org/Resources/Cases/killerrobot.aspx
En este caso hipotético se estudia el caso de un robot industrial que mata a su operario por un fallo en la programación del movimiento de los brazos robóticos, y en el que se descubre que el programador ha cometido un error de bulto en el código, confundiendo variables, al programar bajo presión, en el que la empresa se ha saltado las pruebas para no sobrepasar el plazo de entrega, etc.
Igual hasta merecería un meneo propio...
En España, la culpa no sería del programador, sería del teleco que dió de paso el proyecto por ser él quien tiene las competencias en cuanto a software.
En otros países afortunadamente no hay competencias, el que hace un trabajo es el mejor, sea informático, teleco o panadero, si es el mejor haciéndolo, él es quien lo hace, punto.
#8 Claro, y el que sepa hacer edificios mejor, pues que los haga, aunque sea panadero. Y luego si se cae y ocurre una desgracia, pues a reclamar al maestro armero.
#9 ¿Hace falta tener una carrera para asumir responsabilidades?
#9 Pues si el panadero es el que mejor sabe hacer edificios ya me diras que mierda pasa con los ingenieros.
#8 ¿Me puedes citar una sóla competencia exclusiva que tengan los telecos en cuanto a ingeniería de software?
En España un proyecto de ing. software no quiere la firma de nadie, tampoco de telecos. Un proyecto de ingeniería de software puede llegar a ser tan complejo como tu mente imagine y desde la gestión hasta la implementación del software, pasando por las herramientas utilizadas, todo, depende de personas. No es difícil ver que es inviable asignar responsabilidad análoga a la ingeniería civil. Como mucho se puede pedir el cumplimiento de unos requisitos generales pero eso se puede hacer por contrato de empresa a empresa. Y que conste que soy ing. tec. informático, y no hace mucho pensaba distinto por cierto, pero trabajar es lo que tiene.
Por último, no tendría mucho sentido dar privilegios a fulanito por tener el título X cuando resulta que ha sacado la carrera en la universidad "Broma europea" o similares. En USA se está optando por exámenes por ejemplo. Y si un físico pasa ese exámen, y ese exámen es para acreditar conocimientos de ingeniero de software, pues ese físico está acreditado como ingeniero de software. Hay que aprender a diferenciar entre formación y profesión. En España mezclamos todo y así nos va, con graves problemas estructurales.
#28 si estoy de acuerdo contigo, sencillamente digo que en España el programador no tiene responsabilidad civil alguna, asi que habría que pedírsela al que firma el proyecto que aquí podría ser, por ejemplo, un teleco.
Ni es un ataque contra los telecos, ni pido competencias para los informáticos ni nada parecido, por favor no saquéis los pies del tiesto, que ya veis cosas donde no las hay.
Un proyecto de software no va firmado en España, pero la Therac-25 no es un programa para un cajero de BBVA hecho en una cárnica, no te confundas, ese cacharro aquí lo firmaría un industrial, incluido su código fuente.
A quién le reclamamos la responsabilidad civil por ese fallo de software ? Si el software no puede tener responsabilidad civil, no ? Qué hacemos, lo camuflamos diciendo que es un fallo de la máquina en general, a pesar de que se trate exclusivamente de un error de software ?
A eso me refiero.
Y estoy contigo, hay universidades y "universidades" pero lamentablemente ese es otro tema que no tiene nada que ver con este, pienso yo, puesto que un industrial de la Pública de Valladolid y uno de la Católica de Ávila tiene exactamente los mismos "privilegios" como tú lo llamas, a ver si ahora solo se estudia la ingeniería informática en las privadas, y el resto de ingenierías no se regalan también en esas mismas universidades de corta y pega.
Por lo tanto, el comentario de las universidades de broma, aunque coincido al 100% contigo, creo que aquí sobra.
Espero que este comentario mío no lo saques de contexto, como hiciste con el anterior.
Yo también soy ITIS
#28 "En USA se está optando por exámenes por ejemplo. Y si un físico pasa ese exámen, y ese exámen es para acreditar conocimientos de ingeniero de software, pues ese físico está acreditado como ingeniero de software."
¿Y qué coño es una carrera sino una sucesión de exámenes? De todas maneras, eso plantea muchas dudas (y muchas además legales). ¿Yo puedo ejercer de médico si paso un hipotético "exámen" de medicina? ¿Puedo ejercer de arquitecto si paso un hipotético "exámen" de arquitectura? ¿Y abogado? Y así hasta el infinito.
El problema es que ahora nadie se hace responsable legal de los fallos de un programa. Es más, en la propia licencia de uso de los programas, la empresa te dice que se desentienden de cualquier error ocasionado por el mismo. En vez de apechugar con las consecuencias de esos errores, no, qué coño, aquí más chulos que nadie, el usuario que se joda, que sabía a lo que se exponía. Eso en medicina y arquitectura NO pasa, y si pasa, se paga con la cárcel, o se arreglan los desperfectos, o se indemniza.
Pues mirad, la opinión de un jefe de proyecto (vale, si, argumento de autoridad y encima sin demostrar).
Aquí no se va de rositas ninguno, ni el programador que ha entregado un programa hecho una mierda, ni el analista que le ha pasado unos requerimientos de mierda, ni el tester que ha hecho unas pruebas de mierda, ni el ingeniero que ha diseñado una maquina en la que la mitad de los controles dejan de funcionar, ...
Dejad de echaros la culpa entre programadores y testers. Es obligación INELUDIBLE del programador entregar un programa PERFECTO. Y es obligación INELUDIBLE del tester localizar TODOS los errores que se le hayan colado al programador. Y es obligación INELUDIBLE del jefe del proyecto (no me extiendo con todos los escalones de la cadena) diseñar un sistema tan cerrado de especificaciones que ni el programador tenga dudas de lo que tiene que hacer, ni el tester de cómo debería funcionar.
Precísamente porque nadie es perfecto se ponen tantas capas de seguridad. Y no hace falta tener el título de ingeniero en informática para ser capaz de ver todo eso y resolverlo. Aunque es evidente que un ingeniero en informatica lo tiene más fácil que otro, que para eso está entrenado expresamente en ello, ¿no?
Y todo ello ya sin entrar también en la parta electrica, electrónica y mecánica del proyecto, que también habría para repartir.
#46 "Es obligación INELUDIBLE del programador entregar un programa PERFECTO. Y es obligación INELUDIBLE del tester localizar TODOS los errores que se le hayan colado al programado"
¿Soy el único que ve un problema de lógica en esas frases? Eso o en tu empresa la gente no dura ni dos días porque eso que dices es simplemente imposible. ¿Has programado alguna vez o has saltado a jefe por X razones?
#48 evidentemente sabemos que con lógica pura esas afirmaciones no se sostienen. Pero creo que sabes de lo que se trata. Hacen falta pruebas por que es imposible que no se cometa algún error. Y también es posible que alguno se escape. Pero tendrás que reconocer que de lo que hablamos es de una cadena de despropósitos que encima se aplican a un producto en el que hay en juego vidas humanas.
La actitud de la que hablaba #46 es la adecuada. Lo que no vamos a hacer luego es echar por la ventana al programador cuando ha cometido un fallo.
#53: y si le echamos por la ventana a él, también al Jefe de Proyecto, porque además de todo lo que ha dicho #46, que es correcto, falta:
- "es responsabilidad INEXCUSABLE del Jefe del Proyecto que entre el analista, programador y responsable de pruebas del proyecto desarrollen un proyecto sin fallos".
Y "responsabilidad" de la de verdad, claro, no de la que hablan los políticos cuando dicen "asumo toda la responsabilidad".
No sé vosotros... pero no he leído en ningún sitio que haya sido un fallo de software. El artículo simplemente dice que murió por la máquina, pero de ahí a que sea un fallo de software dista mucho.
Con respecto a #46... sois todos unos patatas. x'D (era una broma hombre no te me enfades...)
¿De verdad hay programadores que no conocían el caso de Therac 25?
Por si queréis más casos:
http://en.wikipedia.org/wiki/List_of_software_bugs
Como anécdota relacionada: un amigo trabaja para GE reparando equipo médico, y nos cuenta como hay máquinas (creo que laser, o de rayos) que llevan un LED que indica actividad. Si ese LED está averiado la máquina no puede funcionar, se trata de un mecanismo de seguridad que evita el funcionamiento en caso de que no se pueda saber si la máquina está radiando o no.
El hecho de que muchos informáticos desconozcan la historia del Therac-25, y otras similares y más recientes, muestra a las claras la inmadurez de la profesión. Es impensable un ingeniero de caminos que no conozca historias de hundimientos de puentes o edificios, o ingenieros navales que no sepan lo que pasó con el Titanic o ingenieros aeronáuticos que desconozcan la historia de sus accidentes, etc. En cambio en informática no es así. Anda que no nos queda...
La frase final generaliza... porque es verdad que por ejemplo nadie muere por un bug en un software de gestión.
Serán los programadores de software...sanitario?
http://web.archive.org/web/20071212183729/http://neptune.netcomp.monash.edu.au/cpe9001/assets/readings/www_uguelph_ca_~tgallagh_~tgallagh.html
"The machine stopped 5 seconds into the treatment with an error. The technician seeing that "No Dose" had been administered (according to the computer) hit the 'P' key thus proceeding with the dose."
Claro, totalmente lógico, ante un fallo, inténtalo de nuevo. Las veces que sea
"As he attempted to get up the 2nd dose was administered. The technician would have known the man was in pain if the audio and visual equipment was working."
Maldito software que no comprueba si el interfono funciona... oh, wait.
"It was not until the fifth incident that any formal action was taken by the AECL."
Léase: culpa del software por... porque la empresa decidió pasar olímpicamente las primeras 4 veces.
"There was only one person programming the code for this system and he largely did all the testing."
...y porque era Canadá, si fuese España además habría sido becario.
Salvo si el código estuviese firmada por el programador, que entonces no habría pasado nada como dicen arriba... oh, wait again.
En todos los hospitales en los que existe un acelerador de este tipo para radiar con altas energías a los pacientes, está el departamento de Radiofísica que controla exhaustivamente las energías irradiadas por sesión y si se detecta la más mínima anomalía se aborta inmediatamente la emisión de partículas. Y el software puede decir MISA.
En el proceso de creación de software existen muchas fases, desde el diseño, que lo realiza el analista, el programador que realiza el código hasta los testing que lo realizan los testeadores. Algo muy común es echar siempre la culpa al sector informático, "se ha programado mal", habría que analizar bien si está mal programado o mal diseñado. También habría que ver si las pruebas que paso antes de pasar al mercado fueron las precisas. Además que por ejemplo en España se nos llena la boca diciendo el tema de fallos informáticos -ya sé que este soft probablemente no lo hayan hecho en españa- pero es que almenos aquí lo que prima no es tener a informáticos de calidad sino en muchas ocasiones a gente recien salida de un FP que cuesta dos duros, y con esto no quiero desmerecer a los FP, simplemente aclarar que se mira más por el ahorro que por la calidad de código.
Un saludo
Y una vez mas... los colegios evitarian estas cosas... no se si llamar a esta gente cansina o mentirosa.
joder qué bien... y yo en un mes me someto a una operación por radiofrecuencia para curarme un cavernoma en el tronco del cerebro... alegría!
#63 Mucha suerte con eso. Los controles para estas cosas han cambiado desde entonces, ¡no te preocupes!
También pasó en España. A mi tía (entre otras personas), quien le dijo repetidas veces a quien le daba las sesiones "me quema, me quema" y no le hicieron caso. El único enlace que he encontrado:
http://www.elpais.com/articulo/sociedad/INSTITUTO_NACIONAL_DE_LA_SALUD_/INSALUD/QUIMIOTERAPIA_/_RADIOTERAPIA/Tercera/muerte/radioterapia/Zaragoza/accidente/grave/mundo/Insalud/elpepisoc/19910222elpepisoc_13/Tes?print=1
Todo el la vida tiene errores y bug, sin duda alguno son más peligrosos que otros para la vida, pero imaginar un bug en los sistemas de misiles de algunos países, también sería una catástrofe.
edit:
iva a hacer un chiste, lo mandé y despues me arrepentí
A ver si lo adivino, el posteador está a favor de los colegios informáticos?
Esto es un bug en toda regla, y es un error enormemente grave para una máquina dedicada a la medicina. Y si, el que se encargó de programar eso tiene a todos los efectos la primera responsabilidad, junto con toda la cadena de testeo y calidad.
¡Es una historia aterradora!
Relacionada: meneame.net/story/software-mato-mi-gato-violo-mis-hermanas
Ojala este tema fuera de video juegos, realmente es lamentable que pasase algo. Es imposible que un software cualquiera esté excento de bugs, pero en este caso fueron claramente irresponsables.
Putos programadores, siempre escurriendo el bulto
Hay mucha gente que muere por culpa de un bicho...
A todo esto estamos hablando de 1985, y de sistemas de diez años antes... Las cosas han evolucionado un pelín desde entonces
Él mismo fue.
Wow... el programador debe sentirse como las pelotas
"There was only one person programming the code for this system and he largely did all the testing."
http://web.archive.org/web/20071212183729/http://neptune.netcomp.monash.edu.au/cpe9001/assets/readings/www_uguelph_ca_~tgallagh_~tgallagh.html
Seguro que había 400 comerciales, 150 general manager y 50 jefes de departamento.
#33 Lo cierto es que entonces hay un error metodológico de entrada y es que un desarrollador difícilmente puede hacer buenas pruebas de su propio código a todos los niveles porque su punto de vista está muy condicionado.
Pero aún así, difícilmente se puede asignar responsabilidad a personas concretas. Deberían ser temas a resolver por seguros de empresas por ejemplo. Es la empresa la responsable de hacer lo posible para que no haya errores graves en sistemas críticos, y en los casos en los que haya, está el seguro.
Es que ya me imagino a la familia llamando asesino al programador y como que no.
#34 En éso coincido contigo, en este caso precisamente al programador es al que menos responsabilidad le cargaría sino más bien al gestor que se encarga de establecer presupuestos para cada departamento. Salvo que ese probramador cobrase él solito lo que el resto de los trabajadores de la empresa, cosa que dudo.