Este web (ojo web 0.5 o anterior ! ) contiene enlaces a una serie de artículos sobre errores de software. Explicaciones sobre fallos de programación que dieron lugar a problemas serios. Por ejemplo un error en el software de la máquina para tratar el cáncer Therac-25 hizo que varias personas murieran. El fallo de los misiles Patriot por otro error de software, la explosión del cohete Ariane 5, el fallo de un avión chino, ...
Los ordenadores aun no estan preparados para funcionar en produccion. Se le da mas importancia a las nuevas funcionalidades que al correcto funcionamiento de las que ya existen. Un entorno mas bonito es mas importante que uno mas estable y funcional.
Muchos diran que esa mentalidad solo es aplicable a los pcs de usuario y no a grandes servidores o entornos criticos. Por desgracia eso no es cierto.
Los programadores que programan para esos entornos se han criado en un ambiente donde los errores son "normales" y "aceptables". Que un programa falle en sus primeras versiones es aceptable, aunque su funcion sea muy importante o critica.
Lo estamos viendo continuamente en todo tipo de noticias, las empresas que venden por internet u ofrecen servicios bancarios intentan esconder esos errores que acaban convirtiendose en perdida de dinero para la empresa y el usuario final de sus servicios.
Se deberian crear leyes lo suficientemente duras y eficaces para conseguir que se parara la produccion de nuevas funcionalidades en software y las empresas se vieran obligadas a centrarse en hacer funcionar correctamente sus productos actuales.
Se que es una utopia, pero de no hacerlo los desastres seran cada vez mayores debido a la dependencia continua que estamos consiguiendo de estos sistemas.
Pronto llegara el DNI electronico, permitiendo hacer gestiones como compra-venta de casas pulsando un boton en un ordenador. Ya se estan haciendo pruebas de voto electronico.
Y todo eso con programas de software defectuosos, lineas de comunicacion inseguras y una falta total de la cultura necesaria para su uso por parte de la sociedad.
La descripción que hace del Ariane 5 es un poco sosa...
Lo del Ariane 5 fue por reutilizar un componente del Ariane 4 que había ido bien y que en teoría no se debía de usar (se usaba antes del despegue, no después), la conversión de un float de 64 bits a un entero de 16 como se menciona. Como pensaron que nunca se usaría, no manejaron la excepción (algo muuuy importante en Ada para los que hayan programado en ese lenguaje)(si no recuerdo mal además se pasó de Ada83 en el Ariana 4 a Ada95 en el Ariane 5 pero no estoy seguro de esto) y ésta se propago hasta el "procedure" principal, y finalmente "colgo" la CPU.
Se dice que fue más un fallo de diseño que un problema del lenguaje (algunos usan esto para criticar a Ada), si lo hubieran tenido en cuenta y hubieran manejado la excepción correctamente no hubiera pasado... http://en.wikipedia.org/wiki/Talk:Ada_programming_language#Ariane_5 http://www.rvs.uni-bielefeld.de/publications/Incidents/DOCS/Research/Rvs/Misc/Additional/Reports/ariane.html
El problema es el desconocimiento de las técnicas de desarrollo de software de las autoridades competentes. Incluso en la Universidad no se enseña como corresponden. Son pocos los gobiernos que legalizan sobre los métodos de desarrollo. Por ejemplo se debería legislar sobre el software médico y exigir que este se desarrolle mediante métodos formales.
¿Por qué siempre se le hecha la culpa al software que hace y no al software que prueba lo que se hace? Es el software de prueba el que tiene la obligación de garantizar el correcto funcionamiento. Si no está probado que funciona ¿Por qué tiene que funcionar?
Será porque el software de test es secundario, se deja en manos de becarios, no se entrega completo, y sobre todo porque NO hay nunca responsabilidades que puedan recaer sobre el mismo.
¿Por qué no se hacen nunca investigaciones sobre el software de prueba? Mucha basura saldría de ahí.
Comentarios
La meneo por "web 0.5 o anterior"
Los ordenadores aun no estan preparados para funcionar en produccion. Se le da mas importancia a las nuevas funcionalidades que al correcto funcionamiento de las que ya existen. Un entorno mas bonito es mas importante que uno mas estable y funcional.
Muchos diran que esa mentalidad solo es aplicable a los pcs de usuario y no a grandes servidores o entornos criticos. Por desgracia eso no es cierto.
Los programadores que programan para esos entornos se han criado en un ambiente donde los errores son "normales" y "aceptables". Que un programa falle en sus primeras versiones es aceptable, aunque su funcion sea muy importante o critica.
Lo estamos viendo continuamente en todo tipo de noticias, las empresas que venden por internet u ofrecen servicios bancarios intentan esconder esos errores que acaban convirtiendose en perdida de dinero para la empresa y el usuario final de sus servicios.
Se deberian crear leyes lo suficientemente duras y eficaces para conseguir que se parara la produccion de nuevas funcionalidades en software y las empresas se vieran obligadas a centrarse en hacer funcionar correctamente sus productos actuales.
Se que es una utopia, pero de no hacerlo los desastres seran cada vez mayores debido a la dependencia continua que estamos consiguiendo de estos sistemas.
Pronto llegara el DNI electronico, permitiendo hacer gestiones como compra-venta de casas pulsando un boton en un ordenador. Ya se estan haciendo pruebas de voto electronico.
Y todo eso con programas de software defectuosos, lineas de comunicacion inseguras y una falta total de la cultura necesaria para su uso por parte de la sociedad.
La descripción que hace del Ariane 5 es un poco sosa...
Lo del Ariane 5 fue por reutilizar un componente del Ariane 4 que había ido bien y que en teoría no se debía de usar (se usaba antes del despegue, no después), la conversión de un float de 64 bits a un entero de 16 como se menciona. Como pensaron que nunca se usaría, no manejaron la excepción (algo muuuy importante en Ada para los que hayan programado en ese lenguaje)(si no recuerdo mal además se pasó de Ada83 en el Ariana 4 a Ada95 en el Ariane 5 pero no estoy seguro de esto) y ésta se propago hasta el "procedure" principal, y finalmente "colgo" la CPU.
Se dice que fue más un fallo de diseño que un problema del lenguaje (algunos usan esto para criticar a Ada), si lo hubieran tenido en cuenta y hubieran manejado la excepción correctamente no hubiera pasado...
http://en.wikipedia.org/wiki/Talk:Ada_programming_language#Ariane_5
http://www.rvs.uni-bielefeld.de/publications/Incidents/DOCS/Research/Rvs/Misc/Additional/Reports/ariane.html
El problema es el desconocimiento de las técnicas de desarrollo de software de las autoridades competentes. Incluso en la Universidad no se enseña como corresponden. Son pocos los gobiernos que legalizan sobre los métodos de desarrollo. Por ejemplo se debería legislar sobre el software médico y exigir que este se desarrolle mediante métodos formales.
¿Por qué siempre se le hecha la culpa al software que hace y no al software que prueba lo que se hace? Es el software de prueba el que tiene la obligación de garantizar el correcto funcionamiento. Si no está probado que funciona ¿Por qué tiene que funcionar?
Será porque el software de test es secundario, se deja en manos de becarios, no se entrega completo, y sobre todo porque NO hay nunca responsabilidades que puedan recaer sobre el mismo.
¿Por qué no se hacen nunca investigaciones sobre el software de prueba? Mucha basura saldría de ahí.