Fragilidad del software

De Wikipedia, la enciclopedia libre

Fragilidad del software es el término irónico que describe la dificultad incremental de arreglar software antiguo. El término es derivado de analogías al trabajo del metal.

Cuando el software es nuevo, es infinitamente maleable; puede ser formado completamente al gusto de sus implementadores. Pero tan pronto como un proyecto dado crece más y más, y desarrolla una gran base de usuarios con mayor experiencia con el software, se vuelve menos y menos maleable. Como un metal que ha sido forjado, el software se vuelve un sistema heredado (legacy system), frágil e incapaz de ser fácilmente cambiado sin fracturar el sistema completo.

Hay muchas razones detrás de esta fragilidad:

• Los usuarios esperan una relativamente constante interfaz de usuario; una vez que una característica ha sido implementada y expuesta a los usuarios, es muy difícil de convencerlos de aceptar cambios mayores a esa característica, incluso si esa característica no estaba bien diseñada en principio o la existencia de la misma bloquea un mayor progreso.

Demasiada documentación puede describir el comportamiento actual (del software) y sería costoso de cambiar. Además, es esencialmente imposible recordar todas las copias de la documentación existente así que es más probable que los usuarios se refieran de nuevo a los manuales obsoletos de todos modos.

• Los implementadores originales (aquellos que conocían cómo las cosas realmente funcionaban) se han mudado y han dejado una documentación insuficiente del funcionamiento interno del software. Muchos detalles de implementaciones de tamaño pequeño solamente fueron entendidos a través de las transmisión oral directa del equipo de diseño y muchos de estos detalles se han perdido, o se han podido perder, aunque algunos pueden ser redescubiertos a través de la aplicación diligente de una arqueología de software. Sobre esto Cunningham, Hunt, Marick y Thomas explican :

A los programadores a menudo se les entrega un sistema (de software) de tamaño considerable, construido por gente que no conocen, tocado por muchas personas desde entonces, documentado mínimamente si es que lo fue. Se les dice que lo mejoren. Su tarea debería ser corregir un error, agregar una característica, o una refabricación completa. Están bajo la presión del tiempo, así que necesitan minimizar el tiempo total destinado a aprender del sistema y el tiempo gastado en mejorarlo. Cunningham, Hunt, Marick & Thomas

• Los parches software se han efectuado probablemente a través de los años, cambiando sutilmente el comportamiento del software. En muchos casos, estos parches corrigen el fallo por el cual fueron efectuados pero introducen otros fallos más sutiles en el sistema. Estos fallos sutiles hacen cambios subsecuentes al sistema lo que lo vuelve finanalmente más complicado.

Es común para los sistemas de software volverse ligeramente frágiles dentro de, digamos, cinco años y casi inmantenibles dentro de quince años. Es muy raro que encontremos un proyecto de software tan bien diseñado que pueda sostenerse un periodo de tiempo mayor siendo fácilmente mantenible. Más a menudo, la antigua base de código será simplemente abandonada y un sistema completamente nuevo será iniciado desde cero; el nuevo sistema puede estar libre de muchas de las cargas del sistema heredado.

[editar] Otros enlaces

• Edward Yourdon
• Fred Brooks
• The Mythical Man-Month