E.E.U.U. pierde anualmente 60.000 MILLONES de dolares por códigos defectuosos

E.E.U.U. pierde anualmente 60.000 MILLONES de dolares por códigos defectuosos
Cuando el software no funciona y el trabajo debe ser suspendido, no sólo se produce molestia entre los usuarios afectados. En Estados Unidos, los fastidiosos “bugs” o errores de código, cuestan al empresariado la elevada suma de 59.5 mil millones de dólares.

En un reciente informe realizado por encargo del Departamento (ministerio) de Comercio, se concluye que los pequeños errores de los programas de informática tienen un grave efecto en la economía corporativa.

“Las consecuencias de los errores de programación son enormes debido a que prácticamente todos los rubros de negocio en EEUU dependen de las TI para desarrollar, producir, distribuir y brindar soporte por sus productos y servicios”, explicó a los medios un funcionario del Instituto Nacional de Estándares y Tecnología.

Alrededor del 80% de los gastos de desarrollo de software son destinados a detectar y corregir errores.

Las grandes pérdidas que el empresariado estadounidense debe afrontar debido a los errores de código motivaron un proyecto de ley que apunta a establecer la responsabilidad legal de los fabricantes frente al pago de indemnizaciones a los usuarios.

La interrogante que surge es que el precio del software aumentaría considerablemente en caso de adoptarse una ley que obligue a los fabricantes a indemnizar las pérdidas ocasionadas por los errores de sus productos. Incluso es posible que algunos fabricantes sencillamente opten por abandonar el negocio.

Comentarios (12)

Anonimo
12 de Julio del 2002
Infelizmente creo que arreglar codigos defectuosos es una tarea un tanto cuanto dificil. Creo que la culpa en parte la tiene el usuario que por si muchas veces no sabe utilizar el software. Lo que si veo bien es que empicen a hacer sistemas mas tolerantes a fallos, pues creo que se da poca atencion al las excepciones. Otro problema que tambien es complicado son los procesadores que por si tb fallan mucho pero como son fallos que pasan de vez en cuando y como son internos es muy dificil de localizarlos.
Salo2 a los que me odian
DevGuru
12 de Julio del 2002
Los errores, hijos mios, son ocasionados gracias a que la mayoria de ustedes cree que sabe programar, no planean, no analizan, y los que lo saben no lo hacen por la presion del maldito tiempo. Se van directo a la programacion y asi las cosas jamas van a funcionar a la perfeccion.

Solo imaginense que un arquitecto se aviente a hacer una casa sin hacer los planos primero. Que pasaria?, esa casa creen ustedes que va a llegar a su consecucion?. Por supuesto que no, yo tampoco soy perfecto pero es una problematica que todos vivimos, y a final de cuentas las victimas y verdugos de nosotros somos nosotros mismos, los programadores, por no discutir con los jefes y usuarios, que no se por que demonios siempre traen prisa, que siempre quieren el sofware de un dia para otro. O no es verdad, diganme si estoy mal?

Yo se que la mayoria de ustedes no se esmera por llevar a cabo las tecnicas y metodologias que les enseñan en la escuela, no las tienen presentes en el cerebro, se quedaron en sus libros y libretas de clases, que muy posiblemente ya no existan en su armario, o esten arrumbadosen el atico del olvido.

Pues asi es como yo veo las cosas, yo creo que la solucion a esta problematica es aplicar las tecnicas con la exactitud requerida y aparte no dejarse llevar por la presion de las exigencias de los usuarios, ya que eso hace que te equivoques mas facil a la hora de desarrollar e invertir dos veces mas el tiempo que te tardarias sin las presiones. Ya he hecho calculos y aqui en mi trabajo les palntee una propuesta en la cual les explico todo esto.

Hagan sus metodologias, haganse de ideas propias, miren hondo, piensen alto, y aprendan siempre de sus experiencias, esa es la clave.
JM
12 de Julio del 2002
Yo particularmente pienso, que la causa fundamental de este problema (la crisis del software) es por culpa directa de dos elementos:
* El Tiempo.
* La Falta de comunicación entre el Programador y el Cliente.

Estos dos elementos (que siempre van juntos), conllevan a que el programador tenga que imaginar qué es lo que el cliente quiere y además de esto, tiene que imaginarse rápidamente lo que va a hacer puesto que tiene el tiempo recortado. Es por ello que el 70% de las veces que un programador vende un software el cliente no queda satisfecho. Sin contar además que la mayoría de los errores son por causa del tiempo.

No es que deje por fuera la posibilidad de que nosotros (los programadores), no hagamos un buen diseño del programa antes de echar código, -puede ocurrir-, pero como lo mencioné antes, es por falta de tiempo y comunicación con los clientes.

Recomiendo (simplemente como consejo) a los programadores, que les pidan a sus clientes toda la información posible referente al programa que quieren, y a los clientes les recomiendo que nos den un poco de tiempo puesto que desarrollar un "BUEN SOFTWARE", requiere de mucho trabajo intelectual para tratar de NO cometer errores, en conjunción a esto, se encuentra el tiempo que uno puede tardar (dependiendo de los requerimientos del programa) en el diseño y luego en la siguiente fase del proceso de desarrollo de software (edición, compilación, prueba, depuración, etc...).

Saludos: JM.

patolin
12 de Julio del 2002
Todo es culpa de Linux y el Open Source
opensource
12 de Julio del 2002
PATOLIN vestia siempre tenes que salir con tus pendejadas, no sabes que el software opensource ha demostrado en la mayoria de los casos ser mas estable que mucho software comercial.. Y otra cosa cambiate ese nombre playo (gay) que tenes...
patolin
12 de Julio del 2002
Para opensource: Escribe tus comentarios en papel carton y luego metetelos entre el C-U-L-O.... no sabes ni de que estamos comentando y aparte de eso ... buscate un libro de ortografia porque a distancia se nota que tu cultura es nula. E insisto: ES CULPA DEL OPENSOURCE....

p.d. Si no te gusta mi nick name sera porque yo si tengo los suficientes H-U-E-V-O-S para poner mi direccion de correo.
shinjy
13 de Julio del 2002
que tiene que ver open source si la mayoria de e.e.u.u no son open source, microsoft lo es, adobe lo es , macromedia lo es, etc, etc pq desde que programas se han echo open source pq ahi mas actualizaciones y con ello mas seguridad, y si eres programador y es open source no lo puedes modificar a tu gusto??? y el post habla de software que cuesta dinero el open source cuesta???
Benito Calcaño
13 de Julio del 2002
Yankees putos sus cagadas cuestan millones de dollares en sudamerica, imperialistas comilones porque no imponen una dictadura bien en Siberia.
Europeos comilones porque no se meten las visas por el orto agarrame la union economica (Bush y amigos TRAGA SABLE!!!!!!!!!!).
Omega
15 de Julio del 2002
Mi punto de vista se basa en la experiencia vivida en empresas dedicadas al desarrollo de software a medida.

En general el mercado informático se encuentra en un circulo vicioso de difícil solución. Diseñar mejor las aplicaciones y probarlas a fondo requiere una cantidad de recursos y tiempo que no corresponde con la realidad que los clientes suelen plantear. Si quieres vender software debes amoldarte al precio que sabes que se va a pagar. Si valoras un proyecto de manera realista y costosa, un cliente jamás se conformará. Sencillamente buscará quien se lo haga en menos tiempo y por menos dinero. Aquí nos encontramos con el primer problema, ser consciente de la complejidad real de desarrollar una aplicación.

Por otro lado si incrementamos la responsabilidad (más aún) que recae sobre los programadores o analistas, estos también deberían cobrar más, lo que nos remite de nuevo a incrementar el precio del producto. Al final comprar un software por su valor real, resultaría mucho mas costoso de lo que se comenta en la noticia.

Finalmente indicar algo que suele sorprender a muchos compradores. Contratar un proyecto sea grande o pequeño requiere un esfuerzo casi equitativo para el cliente y los profesionales informáticos. Quien solicita un servicio debe conocer a fondo lo que está pidiendo, que funcionalidades necesita, que limitaciones existen, y transmitirlo sin dejar en el aire ningún punto. Esto es tan complicado como llevarlo a la práctica. Las pruebas también requieren la participación del cliente, nadie puede efectuar mejores pruebas que el usuario final, que es quien mejor conoce la información con que trabajará el programa. El usuario final debería estar presente en casi todas las fases del desarrollo, y normalmente no se le permite participar en el diseño y de mala gana (con razón) se prestan a probar la aplicación.

En definitiva... un desastre!!!
linuxeando
15 de Julio del 2002
En realidad, me parece curioso que personas completamente neofitas visiten esta página(patolin, nomeescriban y amigos) Lastima que la tecnología les halla llegado a esta especie animal. Porque no mejor dejan en paz a esta página tan seria y tan completa. Bien dicen que la tecnologia no causa daño alguno, los que causan daño son los que la usan.

Atentemente:
Un Integrante de la Organizacion Linux Mundial.
La Mugre
15 de Julio del 2002
Cuando estás investigando alguna nueva función, haces rápidamente (y con toda la emoción) un pequeño programa de prueba, el clásico "Hello world!" y si le metes datos incorrectos, el pobrecito de seguro fallará porque no lo has preparado para gestionar datos incorrectos, pero tenemos que recordar que cuando un cliente nos pide una solución tecnológica esos "programas" no sirven para nada. Estoy de acuerdo con los que comentan que las cosas salen mal por falta de tiempo. Yo estoy en un área que programa desarrollos internos a la medida y créanme TODO URGE (al menos eso dicen los usuarios, jaja) y por hacer las cosas a la carrea, ahi tenemos al usuario "¡Salió un error!" (pues claro) pero hay una realidad, el usuario no tiene la culpa de no saber. El culpar al usuario de las fallas del sistema es una postura muy cómoda, pero debemos dejar esa mentalidad conformista. Un buen sistema, además de cumplir con las necesidades del cliente, también deberá ser a prueba de idio....... mmm, a prueba de fallos.

Otra cosa: Si vemos que los usuarios piden todo demasiado rápido y no dan tiempo de nada ¡A negociar se ha dicho! Hay que saber decir NO (y sin reírse a carcajadas) cuando el cliente te pide de un día para otro un programa que controle las órbitas de un sistema de satélites, que procese información del clima de la ciudad, que realice estimados de tendencias socioeconómicas mundiales y además que te pronostique quién ganará el Super Tazón.

Todo esto aplica para el desarrollo hecho a la medida (in house), pero el artículo habla acerca de software que ya está "probado y requeteprobado", yo creo que en ese caso, la culpa la recae sobre las áreas de "testing", si es que la empresa las tiene, y si no las tiene, sobre los programadores, y si la culpa es de la máquina donde el software se instala, sobre la gente de soporte, y si es del hardware que es chafa de fábrica (mala calidad), pues sobre el fabricante y si la culpa es del software que maneja el fabricante para hacer sus mugres, sobre los programadores que lo hicieron ................... ¡Ups!
anonimo
17 de Julio del 2002
Bueno, para eso recaudan mucho más de lo ke pierden.

Comenta esta noticia

Nombre
Correo (no se visualiza en la web)
Comentarios...
Es necesario revisar y aceptar las políticas de privacidad