BUGS (el origen)

On 30 octubre, 2011, in Curiosidades, errores, Sin categoría, by twiindan

Siempre hemos oido que un software puede tener errores o bugs que produciran fallos, actualmente todo el mundo conoce a los errores de un sistema como “bugs”, pero realmente porque les llamamos así? Que relación tienen realmente los defectos del software con estos pequeños bichos?

La historia se remonta al 1947 cuando los creadores del Mark II detectaron un error dentro del ordenador que estaban creando. Despues de mucho investigar, descubrieron que el error era debido a un problema electromagnético. Este error era producido por una “polilla” que se encontraba dentro de uno de los reles y provocaba que este se quedará abierto.

Uno de los desarrolladores del Mark II cogio la polilla y la pego mediante una cinta adhesiva a un cuaderno o bitacora refieriendose a ella como bicho para describir la causa del problema.

Posteriormente también utilizaron el juego de palabras debug para referirse a los depuradores de código.

Como podéis ver es curioso como incidentes absurdos como encontrar una polilla dentro de un relé puede producir que 50 años más tardes millones de personas utilicen ese termino!

Ahora ya sabéis a encontrar muchos bugs!

Tagged with:  

Me ha llegado a traves de Alex Rauet una noticia sobre un fallo informático en la empresa española Inditex.

Durante la mañana del día 23 de Febrero del 2011 Inditex tuvo durante varias horas diversas prendas de la nueva colección de Zara a solo un euro! La verdad toda una ganga para los usuarios.

Los usuarios podían escoger algunas de las prendas de la nueva colección por un euro sin que apareciera ningún error durante la transacción. Parece ser que el fallo informático solo afectaba alguna de los articulos, no a todos.

A las pocas horas Inditex arreglaba el desajuste informático y comunicaba a los clientes que habían comprado alguno de los articulos que el pedido se anulaba porque el precio ofertado habia sido incorrecto.

Este error puede tener un gran impacto ya que puede disminuir la confianza de los clientes de la firma sobretodo en la tienda online que solo lleva operativa 6 meses.  Parece ser que este no es el primer error de la marca, donde ya tuvo un problema hace pocas semanas con unas fotos publicadas en la web que resultaron ser plagios de imagenes de pasarela.

Esperemos que despues de estos problemas Inditex se tome más en cuenta la calidad de su portal web. Por si las moscas ire visitando la web a ver si cazo alguna ganga :p.

 

 

Tagged with:  

Todo el mundo sabe la gran rivalidad que existe actualmente entre Apple y Adobe, debido a que esta primera ha criticado duramente sobre su principal fuente de ingresos Adobe Flash a la hora de entrar en el mercado del Iphone.

Realmente es exagerada la crítica que realiza el CEO de Apple Steve Jobs contra Adobe?

Si analizamos el porcentaje de desarrollo dedicado en la última versió de MacOS (10.6.5) vemos que el 42 % de los errores “fixed” en esta versión forman parte de la plataforma Adobe Flash.

Es decir 42 de cada 100 errores arreglados en esta versión tienen que ver con los complementos de Adobe dentro de MacOS, una cifra bastante escandalosa. Si lo miramos friamente vemos que se han arraglado los mismos errores para este complemento que para el resto del desarrollo del sistema operativo en general.

Vemos entonces que los motivos que tienen desde Apple para atacar a Adobe Flash es infundado y una vez más se ve la importancia de la calidad y testing de un producto para no dañar la imagen de la empresa. Quizás Adobe debe realizar una politica diferente respecto a la calidad de su producto si no quiere seguir viendose criticado por empresas como Apple entre otras, y más ahora que empiezan a existir alternativas como HTML5.

Via 9to5Mac.

Tagged with:  

Porque existen los errores?

On 12 octubre, 2010, in Articulos, Prácticas desarrollo, by twiindan

Una tarde de viernes, despues de una semana de trabajo y de vispera de puente, con una cerveza, unos cacahuetes y los compañeros del trabajo, que mejor escenario para tener una típica discusión entre developers y testers!

Aunque esta vez de la discusión aprendi un par de cosas que me han hecho reflexionar durante estos dias. En la discusión me comentaba un compañero de desarrollo que efectivamente a medida que un developer va ganando experiencia y aprendiendo, seguramente no necesite un tester para encontrar errores porque casi no los cometera. Como no, a mi me parece un razonamiento imposible ya que un developer como persona humana que es (al igual que un tester) siempre comenterá algún error en su código por muy bueno que sea.

Pero esto me hizo pensar en algo curioso… realmente el único motivo por el cual existimos los testers es porque el departamento de desarrollo hace mal ( o no óptimo)  su trabajo? Es culpable el departamento de desarrollo de todos los errores que encontramos?

Si para ti la respuesta es NO, entonces coincidimos perfectamente y por ese motivo me gustaria hacer una pequeña lista de las razones por las que pueden haber errores en el sistema:

  1. Errores al programar: Es el primero que nos viene a la cabeza y el inicio de la discusión con mis compañeros. Los humanos no somos perfectos y por lo tanto cualquier persona (developers o testers) cometeremos errores dentro del ciclo de vida del software.
  2. Cambios de última hora: Siempre existen, son como una lacra que sabes que tarde o temprano llegarán, son los temidos cambios a dos semanas de entregar una aplicación, unos cambios que en principio no afectan a “nada” y al final afectan a “todo”.  En todos los proyectos existen cambios, y generalmente no se le dan la importancia que merecen ya que muchos de ellos ni siquiera estan planificados.
  3. Errores de terceros: Siempre que utilicemos software de terceras partes como los entornos de desarollo o librerias externas a nuestro proyecto existe la posibilidad de que existan errores no contemplados. Estos errores son heredados por nuestro software y generalmente son dificiles de detectar en las fases de desarrollo.
  4. Errores de comunicación: Para mi la principal fuente de errores ya que esto conduce en parte al punto 2 (cambios de última hora). La comunicación es una de las partes más imporantes dentro del desarrollo del producto y de ella deriivan los requisitos, especificaciones, diseño… Por lo tanto un error de comunicación en algunas fases de proyecto pueden resultar fatales derivando en especificaciones incompletas o erroneas.
  5. Control de versiones: Generalmente otra fuente de problemas provienen del control de versiones de cada uno de los módulos de desarrollo. Aunque existen una gran variedad de aplicaciones o herramientas para realizar esta tarea es fácil que las malas prácticas dentro de desarrollo acaben con una versión antigua de algún módulo o algún componente erróneo.
  6. Malas prácticas de diseño: Otro de los grandes focos de errores, sobretodo en sistemas que son muy complejos o donde se utilizan nuevas tecnologías o nuevas arquitecturas. Generalmente se designa a un solo analista o arquitecto para realizar el diseño de los componentes de software, en lugar de realizar un brainstorming o realizar revisiones de diseño entre arquitectos para detectar errores tempranos.
  7. Malas practicas de codificación: Aun recuerdo el dia que se instauraron en los departamento de desarrollo las guias de buenas prácticas, un poco más y nos cortan el cuello!!! Pero un tiempo despues se ha comprabado que los errores detectados por las malas practicas han disminuido considerablemente, y ahora la gente de desarrollo se han acostumbrado llegando incluso dejar de lado todas sus manias a la hora de codificar o utilizar herramientas de debugging, analizadores, validarores… un buen programador no solo escribe líneas de código si no que las realiza de las mejor manera posible!
  8. Tiempo de desarrollo imposible: He querido dejar este para el último ya que creo que es de los pocos que estamos de acuerdo todos los departamentos. Cuando se planifica un proyecto de software, nunca he visto que se tenga en cuenta realmente el esfuerzo de este ya que generalmente quien lo planifica no sabe lo dificil que es realizar software. Esto se traduce en presión y stress sobre los departamentos de desarrollo, que incomodan a los programadores y les inducen a producir más errores. A parte como hemos comentado anteriormente (en el punto 2) los cambios que se piden desde el cliente en cualquier punto del proyecto muchas veces no se contemplan en la planificación al igual que la resolución de errores.

He nombrado ocho posibles factores a la hora de introducir errores, pero existen una infinidad más ya que miles de factores influyen en el ciclo de vida del software, aun así remarcar que no toda la responsabilidad de la introducción de errores es por parte de desarrollo ni mucho menos, si no que los errores se introducen en todas las fases desde los requerimientos, diseño… hasta los propios testers que como el resto del mundo, tambien somos humanos!(con nuestro corazoncito, y nuestra alma)

Conoceís algunos factores más que puedan influir en la introducción de errores¿?