Portada
mis comunidades
otras secciones
#5:
Y esto es lo que pasa cuando aplicas el desarrollo de software habitual al desarrollo de software crítico.
Crítico: la vida de personas depende directamente del buen funcionamiento del software.
Crítico: la vida de personas depende directamente del buen funcionamiento del software.
#9:
#7 como ha podido pasar algo así, no pasa de vez en cuando, como cosa bestia recuerdo esto:
https://es.wikipedia.org/wiki/Therac-25
https://es.wikipedia.org/wiki/Therac-25
#1:
El aviso de la Agencia Española del Medicamento y Productos Sanitarios sobre esto:
https://www.aemps.gob.es/informa/la-aemps-informa-del-posible-riesgo-de-administracion-excesiva-de-insulina-al-reiniciar-la-aplicacion-mylife-camaps-fx/
https://www.aemps.gob.es/informa/la-aemps-informa-del-posible-riesgo-de-administracion-excesiva-de-insulina-al-reiniciar-la-aplicacion-mylife-camaps-fx/
Comentarios
Y esto es lo que pasa cuando aplicas el desarrollo de software habitual al desarrollo de software crítico.
Crítico: la vida de personas depende directamente del buen funcionamiento del software.
#5 En una optativa de dispositivos medicos en una ingenieria, nos dijeron que al programar algo asi teniamos el mismo nivel de responsabilidad que un medico haciendo una operacion. No se como ha podido pasar algo asi, es una irresponsabilidad.
#7 Pues porque la profesión no está regulada. Follow the money.
#8 Aunque las profesiones reguladas tienen ventajas respecto a las garantías y la seguridad, quizás una profesión innovadora donde se están todavía construyendo las herramientas y entendiendo los procesos... no conviene que este regulada. El resto de países nos adelantaría y nos quedaríamos todavía mas atrás.
La humanidad no sabe como producir software industrialmente. Todo el software del planeta está producido por artesanos o procesos artesanales escalados como se puede alrededor de la propia artesanía que sigue bien presente en el proyecto y en el proceso. . Antes lo asumamos, mejor.
No nos engañemos, las ingenierías llevan su tiempo para germinar, desarrollarse madurar. Esto no tiene ni 60 años siendo practicado a gran escala.
#11 La humanidad saber perfectamente como producir software industrialmente. Y desde hace décadas. De hecho hace 20-30 años se hacía así.
Pero claro, era carísimo. Mucho mejor producir software lleno de bugs para venderlo/alquilarlo rápido y luego los bugs se van arreglando. O no.
#12 Entiendo tu punto de vista. Pero creo que hay un asunto práctico que hay que considerar. Para decir que la humanidad sabe producir software industrialmente se han de cumplir en mi opinión dos premisas, de la que solo se está cumpliendo una:
- tiene que existir una forma predecible y controlable de producir
- tiene que estar en un rango de costes que lo haga viable para el contexto y la escala requerida
La humanidad solo sabe hacer software con garantías a unos costes tan elevados, que si cuentas todo el software con garantías que se necesita, es evidente que simplemente no se puede hacer. Hay un problema de costes y escala.
#13 Pues para eso se usaba el waterfall. Y el problema no era que fuera caro o no fuera escalable. El problema era que tardaba mucho.
Y mira, un ejemplo de diseño que tardó más de 20 años en ponerse en "produccion"
https://es.m.wikipedia.org/wiki/Lockheed_Martin_F-35_Lightning_II
Por qué no se usa este ciclo de desarrollo para el software de la noticia? Pues follow the money, porque estaremos de acuerdo en que diseñar un F35 es más mucho más complejo que un software de administración de insulina... espero.
#15 Precisamente el F35 es un ejemplo de multiples problemas y fallos en los controles de calidad estando incluso ya operativo, llegando al punto de tener que mantenerlos en tierra en varias ocasiones, la última el año pasado mismo si no recuerdo mal. El equivalente a no uses la aplicación hasta que esté actualizada.
#15 Lo siento, pero creo que "tardaba mucho" y "caro" son la misma cosa. El tiempo que tarda un equipo en desarrollar la solución es una parte importante del coste de implementarla, sino la principal. Mas tiempo, mas coste.
#23 Porque no hay responsabilidad penal. Si al coste de desarrollar rápido le sumas una pila de demandas judiciales, indemnizaciones y condenas varias, igual te sale más barato producir software a un ritmo más lento y seguro.
#24 Quizás si existiese esa responsabilidad penal, estaríamos obligados como sociedad a construir todo el software que necesitamos a un coste inasumible como sociedad?
#26 inasumible no, lo asumimos como normal para muchos otros productos. Medicinas, infraestructuras, medios de transporte, industria alimentaria...
#27 En aviiones una cafetera creo que vale miles de Euros y una escobilla de limpiaparabrias 700e, por los seguros y certiificaciiones de que nada falle. Si falla una escobilla se puede quedar sin vision.
#16 #19 Hay bastantes avisos con bombas de insulina.
https://old.meneame.net/search?q=bomba insulina
Una app supongo que te da un recomendacion mas en tiempo real. No se como lo hacen los medicos para regualar estas cosas siintron, insulina, etc) usaran un algoritmo o lo van haciendo a ojo.
#8 como si regularla crease magia y todo fuese perfecto.
Esto pasa por qué el protocolo de pruebas y certificaciones será una mierda.
#18 No es mágico, pero no es lo mismo subir con known bugs cuando hay una responsabilidad penal que puede acabar en condena por homicidio imprudente. Como cuando se cae un puente o descarrila un tren. Aaaamigo, ahí le tiemblan las piernas al más recio de los seniors.
#8 La ingeniería electrónica pata productos domésticos/de consumo tampoco es una profesión regulada, y sólo para tener el sello CE en un dispositivo y poder venderlo legalmente en la UE te miran con lupa, aunque sea un simple cargador de móvil.
Si hablamos de disposotivos médicos, tienen que cumplir ciertas características y pasar unas determinadas pruebas para comprobar que sean seguros, y ésto mismo es lo deberían hacer con el software, no regular la profesión.
#8 Si lo está. Es la regulación de productos sanitarios a nivel de la EU. Y es muy estricta y también se aplica a apps.
#7 como ha podido pasar algo así, no pasa de vez en cuando, como cosa bestia recuerdo esto:
https://es.wikipedia.org/wiki/Therac-25
#9 Creo que tambien se menciono eso, aunque nunca supe a que se referia en concreto, muy interesante, gracias
#6 Y si te quedas frito y no tomas medidas para contrarestarlo? Tambien te puede dar una borrachera conduciendo y conducir irregularmente, cuando no perder el conocimiento.
#5 #7 Se podran hacer algo para evitarlo?
en los aceleradores de coche, hay dos potenciometros invertidos ( 1 aumenta cuando pisas y otro reduce cuando pisas). Y compara que las medidas sean compatibles.
En los aviones creo que se usan algoritmos diferentes para comprobar que llegan al mismo resultado y darlo por valido. A veces pasando por procesadores diferentes para interceptar un fallo de arquitectura.
Los vateres japoneses tienen 3 sistemas de control de temeratura en serie, para no quemarte el culo.
No sé que es adminstrar insulina en Exceso. Puede ser un poco, pero creo que habia una con un error que vaciaba toda la bomba de golpe.
Se me ocurre que haya un comprobador de valores fuera de lo aceptalbe y si el algoritmo los sobrepasa avisar.
#14
Creo que te confundes, esto no va de bombas de insulina sino de una app que te da las pautas.#17 Yo tampoco habiia leiido que valiia para las dos cosas para indicar la administraciion manual y para las bombas de iinsulina
#14 No solo trata de algoritmos más seguros. El software crítico es una serie de estándares, pruebas, trazabilidad obligatoria e irrenunciable... La batería de pruebas, métricas y evidencias necesarias para lanzar un producto así deben ser mayores. También te digo que desconozco que estándar siguen los productos médicos, yo soy de otra rama del software crítico. Pero vamos, en el sector nuclear, defensa, aviación, automoción, espacio... es más una cuestión de métodos que otra cosa. Sistemas redundantes? Si, pero el 90% del tiempo de los programadores se va mas en hacer tests de cobertura, solucionando issues del estándar de código y documentando todo que otra cosa. Evidentemente, hay que tener detrás bien definidas funciones de seguridad y todo eso...
La arquitectura del software, las funciones de seguridad... suelen definirse muy bien al principio del proyecto. También te digo que desarrollar así es caro y lento. No me extrañaría que redujesen la criticidad en algún momento del desarrollo. También lo he visto. 100% de cobertura? Sudando. Lo de misra? Para qué? Pasar valgrind ? Nah. SSOO en tiempo real ? Tiremos de un Ubuntu que la licencia de VxWorks es cara (un poco robo, lo reconozco).
También hay mucho debate en torno a la utilidad de ciertos procedimientos. En mi experiencia, no existe el software seguro, sobre todo cuando alcanza cierto tamaño. He visto software del máximo nivel de criticidad, hecho por gente muy buena, con todo en orden, fallar por estupideces impresionantes.
#25 Interesante. Tambien hay sofware que separa la parte criiica para hacerla mas pequeña y controlable y blindarla de errores en el resto del sofware como el qmail, que ofrece¿ia? una recompensa a quien encuentre un ataque.
https://es.wikipedia.org/wiki/Qmail
No se como influiira las IA. Son muy creativas, pero no tan fiables. No se que será mas seguro poner humanos testando lo que hace la IA o poniendo IA testando lo que hacen los humanos.
Rust tambien se supone que ayuda a hacer sofware seguro en muchos aspectos sin mucho coste.
#7 La pregunta no es si tienes responsabilidad legal o no. La cuestión es quién asume esa responsabilidad legal, y quien tiene capacidad para asumirla, porque para cobrar la pasta seguro que hay alguien dispuesto, y no tiene por qué ser un único programador.
El aviso de la Agencia Española del Medicamento y Productos Sanitarios sobre esto:
https://www.aemps.gob.es/informa/la-aemps-informa-del-posible-riesgo-de-administracion-excesiva-de-insulina-al-reiniciar-la-aplicacion-mylife-camaps-fx/
Tampoco es tan grave, quizás te puedas morir un poco con mala suerte
#3 Morir igual no, porque al notar la bajada de azúcar por el exceso siempre te queda el glucagon.
Pero puede ser muy, muy peligroso.
#6 No conozco ni un solo diabético que hoy día vaya sin su Freestyle Libre o similar. Lo que no me explico es que hacen usando una app random en vez de seguir la pauta de su endocrino, que para algo te dan los ratios....
#16 #6 Me respondo a mi mismo para aclarar que la app controla el suministro de una bomba de insulina, me despisté porque las bombas que yo conozco no van con Android (la propia bomba es la que tiene el software que configuran los endocrinos)
Pues vaya p. gracia...
Y gracias que se han dado cuenta...
Esperemos no vaya a más...
A portada!
Es un ejemplo de por qué los comentarios típicos de "esa app se tarda en hacer dos tardes" o "por qué 700.000 € si eso lo hace un senior en un mes = 2.000 €" están tan desencaminados.
Invertir más tiempo o dinero no es garantía al 100% de nada, pero si hacer software fiable ya es difícil, plantear el desarrollo como una carrera hacia lo barato o rápido tal vez no sea el mejor plan.
#31 Todo lo contrario, razón de más para quejarse. Después de tanto tiempo, tanto dinero, y tanto experto, uno debería esperar algo más de ésta aplicación, cuyo nucleo, al fin y al cabo sólo hace cálculos aritméticos básicos. En todo caso, estos bugs demuestran que, efectivamente, toda esa pasta no ha ido al desarrollo de la aplicación, sino a ciertos bolsillos, como ya nos temíamos.
#34 Estamos de acuerdo. No obstante, mi comentario iba en otra línea, más hacia ese tipo de comentarios que dan a entender que el desarrollo es barato y/o fácil. No, no lo es, y cuando no se da la suficiente importancia a todo lo demás en un proyecto de software que no es simplemente escribir código pasan cosas como esta.
Bueno, por eso, o porque han trincado la pasta como tú indicas