-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-06-02 a las 00:30 +0200, miguel gmail escribió:
Hay hasta programs de esos de munchas pelas, que se dedican a auditar el código y encontrarte problemillas y problemones.
Imagino que esos programas no hacen sino aplicar reglas previamente definidas. Pues vaya. Yo quiero saber qué metología habría que seguir en una programación segura.
Si, bueno, imagino que aplican heurísticas que han ido desarrollando, pero no precisamente lo que te explican en un libro de metodología, porque en una buena metodología (que yo no he estudiado las de verdad, soy teleco, no informático) puedes tardar un año hasta escribir la primera linea de código. Esos programas son a posteriori, para cazar errores después de producidos por no seguir un buen método.
No se ahora mismo un libro de eso... hay mucho "arte". Un buen libro de programación, realmente bueno y no un sacacuartos, debe explicar esas cosas.
Uhm... realmente... un libro de programación para eso?? No sé, mas bien un libro de seguridad en si mismo.
Rafa ha dicho alguno. En informática tienen asignaturas enteras de metodologías.
Se que hay metodologías específicas de desarrollo a prueba de errores (por ejemplo, uno no espera que un avión se caiga por un error de sw,
¿NOOO? Yo si...
'sagerao'!
¡JA! :-P
Primer avión que cruza el ecuador: flip, panza arriba. Y el segundo, flip. Y el tercero, flip.
No comment...
Lo había oido... siempre pense que era una leyenda urbana. Veamos, seamos un poco practicos.
No, no lo es. Quien me lo contó, hace unos cuantos años, tenía motivos para saberlo de verdad.
Cuantos aviones vuelan cada día? Miles. Cuantos tienen problemas? Algunos Cuantos tienen problemas debido al sw? Bueno, no lo sabemos realmente.
Eso es el problema, no se sabe. No se publica, eso se oculta. Mira, en yanquilandia tenían un grupo de la nasa, si no recuerdo mal, cuyo trabajo era recibir anónimamente "denuncias" de los pilotos y otros técnicos de problemas que habían encontrado, pero que no podían denunciar oficialmente porque podían despedirlos. Esa gente localizó muchos fallos de muchos tipos. Desafortunadamente, recortaron gastos y lo quitaron, o quitaron la gente que luego los analizaban. (Lo se por un estudio que salió en el ieee spectrum hace poco sobre la seguridad aerea relacionada con las interferencias radioeléctricas). No es el único problema informático gordo que conozco, he oído de otros. Un avión que es temido por los pilotos es el airbus, porque toma sus propias decisiones. Me contaron de un avión que estaba aterrizando, el piloto decide abortar por no se que, tira de gas y de palanca a tope para remontar el vuelo, y el ordenador cancela la orden y mantiene vuelo nivelado, estrellándose. ¿Porqué? Pues porque el ordenador calculó que con esa orden del piloto el avión iba a entrar en pérdida y estrellarse de cola a mayor altura, y decidió que era mejor estrellarse en horizontal... No es exactamente un fallo de software, es más bien un fallo de entrenamiento en lo que supone un cacharro tan sofisticado.
Hombre, estoy pensando que ha habido satélites que se han estrellado, perdido o cosas parecidas por errores como usar kms en un modulo y millas en otro, confundir el 'arriba' con el 'abajo' (daba gravedad negativa en lugar de positiva, con lo que el satelite de cuyo nombre no quier acordarme no abrío el paracaidas y se estampó contra el suelo con la tele dándolo en directo, y es que la gravedad nunca alcanzo cierto valor... positivo). Pero esto son errores de comunicación o como mucho de diseno, no de desarrollo _en si_.
El de la Nasa con la misión a Marte entre las medidas imperiales y las del SI (la nasa usa el SI) fué muy estudiado. Fué un fallo de método en la empresa, que no se leyó las especificaciones y trabajaron en medidas imperiales en contra de las especificaciones de la nasa. De esos hay muy gordos. Los rusos perdieron otro. A ver si me acuerdo... ah, estos es que usanban la misma cpu para análisis y experimentos y para navegación. Programaron remotamente (en vuelo) un experimento, y colaron un bug. La cpu hizo el experimento (enfocar una cámara, por ejemplo) y al terminar no pudo tomar el control de navegación y reorientar la antena hacia la Tierra... silencio absoluto, se perdió. Los americanos usaban dos procesadores, en ese tiempo al menos. Falló la orientación, pero por culpa de un bug en el código que mandaron desde la Tierra.
Pero si que se que hay metodologías de desarrollo que minimizan al mínimo minimísimo el numero de errores (y creo recordar que valen 50 veces más que un desarrollo 'normal')
Hubo un número del ieee dedicado precisamente a fallos de software... uno de los artículos era de una empresa inglesa que garantizaba código libre de fallos a la primera. O casi. Y lo consiguen. Son los que dije que pueden estar un año o dos estudiando antes de escribir una sóla linea de código. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEf39AtTMYHG2NR9URAuk6AJ0UEwENlwtmQWG+nazxKZmERfrafgCdFixu ySERaZ5yare/m/+aV3DhsOM= =R9gm -----END PGP SIGNATURE----- -- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com