LA CRISIS DEL SOFTWARE Y SUS POSIBLES SOLUCIONES

Crisis del Software

La expresión «crisis del software» es recurrente en mucha bibliografía técnica, tanto que ya suena a expresión vacía. El caso es que esta crisis existe y para ello basta comparar el desarrollo del hardware y su relación coste/potencia con el del software. En el hardware hay una reutilización sistemática y ahorros de coste continuos a merced de la reducción de materias primas en cada generación de productos, la reutilización de diseños previos, las economías de escala, etc. En el caso del software, donde todas las economías podrían ser de escala, al menos en teoría, no solo no ha ocurrido así sino que el coste no solo no se ha mantenido sino que ha aumentado. Y por otro lado la productividad que ofrece es muy limitada: hoy día el mundo del software ofrece aplicaciones, no soluciones, no se adapta a la forma natural de trabajar de los seres humanos y son sólo poderosas herramientas, a veces incluso sobredimensionadas, en lugar de adaptarse a las actividades del ser humano.

Un fenómeno muy importante es el del despilfarro económico que muchas sociedades realizan con la idea de avanzar en la inclusión digital. Es conocida la ley de Moore, que aún hoy marca la pauta del incremento regular de la relación potencia/coste del hardware. Menos conocida es la de Gilder aplicada de manera semejante a la conectividad. El resultado es que en tres años el hardware es obsoleto incluso a efectos contables. Eso no sería un problema si se hubiera podido amortizar tanta potencia con soluciones software. Pero esas soluciones no existen. Siguen siendo aplicaciones de «bajo nivel».

La crisis del software es el hecho de que el software que se construye no solamente no satisface los requerimientos ni las necesidades pedidos por el cliente, sino que además excede los presupuestos y los horarios de tiempos. La industria del software no ha podido satisfacer la demanda. La complejidad del software producido y demandado se incrementa constantemente. El software es solicitado para ejecutar las tareas demandantes de hoy y está presente en todos los sistemas que van desde los más se los más sencillos hasta los de misión crítica. Las aplicaciones de software son complejas porque modelan la complejidad del mundo real. En estos días, las aplicaciones típicas son muy grandes y complejas para que un individuo las entienda y, por ello, lleva gran tiempo implementar software.

El término “crisis del software” se acuñó en 1968, en la primera conferencia organizada por la OTAN (Organización del Tratado del Atlántico Norte) sobre desarrollo de software; y con él se etiquetaron a los problemas que surgían en el desarrollo de sistemas de software. En la misma conferencia se utilizó por primera vez el término "ingeniería del software" para describir el conjunto de conocimientos que existían en aquel estado inicial. Algunas referencias útiles para comprender cuáles eran los conocimientos estables para el desarrollo de software en 1968 son:

• En 1962 se publicó el primer algoritmo para búsquedas binarias.
• C.Böhm y G. Jacopini publicaron en 1966 el documento que creaba una fundación para la eliminación de "GoTo" y la creación de la programación estructurada.
• En 1968 los programadores se debatían entre el uso de la sentencia GoTo, y la nueva idea de programación estructurada; ese era el caldo de cultivo en el que Edsger Dijkstra escribió su famosa carta "GoTo Statement Considered Harmful" en 1968.
• La primera publicación sobre programación estructurada no vio la luz hasta 1974, publicada por Larry Constantine, Glenford Myers y Wayne Stevens.
• El primer libro sobre métrica de software fue publicado en 1977 por Tom Gilb.
• El primer libro sobre análisis de requisitos apareció en 1979.

El término fue usado para referirse a los rápidos incrementos de la tecnología en la computación y la complejidad de los problemas a los cuales pudieran enfrentarse. En efecto, se refiere a la dificultad de escribir correcta, entendible y verificablemente los lenguajes de programación. Las raíces de la crisis del software son complejas y variables.

"Síntomas"

Uno de los principales problemas en el desarrollo de software de hoy en día es que muchos proyectos empiezan la programación tan pronto se definen y concentran mucho de su esfuerzo en la escritura de código. Últimamente el desarrollo de software se ha relentizado. El estudio de este fenómeno es importante porque la existencia de software científico libre facilita que cualquier laboratorio del mundo pueda desarrollar ciencia libre usando este software como herramienta de trabajo.

Algunos “síntomas” que indican que el software se encuentra en un periodo de crisis son:

• Baja Calidad del Software.
• Tiempo y Presupuesto Excedido.
• Confiabilidad Cuestionable.
• Altos Requerimientos de Personal para desarrollo y mantenimiento.

Factores de Influencia

Para poder llevar el estado del proceso de software como un estado de crisis, los críticos han destacado ciertas características que han permitido esta postura del software respecto a otras etapas de su corta historia. Algunos de esos factores son:

• Aumento del poder computacional.
• Reducción del costo del hardware.
• Rápida obsolescencia de hardware y software.
• Aceptación de la computarización en las empresas.
• Incremento en el número de usuarios de los sistemas de software.
• Tipo de usuario no homogéneo aun en sistemas hechos a la medida.
• Personal de desarrollado y mantenimiento diferente.
• La magnitud del proyecto impacta en:
• Tiempo costo y número de desarrolladores,
• Control administrativo y detalles técnicos
• Aumento en el conocimiento del problema.
• Cambios en el entorno:
• Tecnológicos (Internet, redes, ERP, CRM, SCM).
• Económicos (crisis económicas, globalización, etcétera).
• Sociales (nuevas necesidades, costumbres nuevas, etcétera).

Posibles causas de la crisis del software

Hay varias razones que pueden ser propuestas como causa de la crisis. No son mutuamente excluyentes; de hecho, es posible que la verdadera causa sea una mezcla de todas ellas. Sin embargo, todas tienen en común que son causadas por el método de valorar los avances científicos y el mecanismo actual de financiación de la actividad científica. Las causas de la crisis del software fueron vinculadas a la complejidad en general del proceso de software y a la relativa madurez de la ingeniería de software como una profesión. La crisis se manifestó a sí misma en varias maneras:

• Proyectos gestionados con un sobre-presupuesto.
• Proyectos gestionados con sobre tiempo.
• Software de baja calidad.
• El software a menudo no satisfacía los requerimientos deseados.
• Los proyectos fueron inmanejables, con un código difícil de mantener.

La crisis del software fue dirigida por la implementación de varios procesos y metodologías, siendo la más notable el modelo de cascada de Royce.

Posibles soluciones al problema del software científico

La primera solución puede ser la existencia de una licencia libre, mas que recoja las singularidades del software científico. Esta licencia debería compartir el espíritu de la GPL (General Public License es una licencia creada por la Free Software Foundation a mediados de los 80, y está orientada principalmente a proteger la libre distribución, modificación y uso de software. Su propósito es declarar que el software cubierto por esta licencia es software libre y protegerlo de intentos de apropiación que restrinjan esas libertades a los usuarios) y gran parte de su letra; y debería asegurar la preservación de las libertades propuestas por RMS. Por otro lado, también debería incluir algunas restricciones, fáciles de cumplir y que no limitan la libertad final del código según los criterios expuestos por RMS (Richard Matthew Stallman), como son:

• Si se usa el programa para realizar una investigación, y esa investigación termina en uno o varios artículos publicados, los artículos de dicha investigación deben reconocer qué programas fueron usados, así como citar los artículos en los que fueron descritos. Esta restricción no impide la libertad de libre uso, y, de hecho, la totalidad de los programas libres científicos la incluyen; este sistema hasta ahora parece funcionar. La principal objeción a esta restricción es similar a la crítica que RMS hizo a la licencia BSD ; sin embargo, en este caso no se produce el exceso de verborrea en las citaciones; ya que, en caso de que alguien pueda publicar un artículo en una revista indexada, por la naturaleza de revisadas por asesores externos de estas revistas, ha de ser cierta importancia la aportación al código.
• Si se modifica el código, se ha de identificar adecuadamente la parte modificada como tal. Esto no impide la libertad de modificación, mas permite que, en caso de que la modificación suponga una mejora en el rendimiento o la calidad de los resultados, el autor de la modificación tenga el debido reconocimiento; y, en caso de que la modificación introduzca errores, evita manchar el nombre del programa y del grupo que lo desarrolló.
• Por último, sería interesante abrir un debate en el seno de la comunidad del software libre sobre hasta qué punto es ético usar software libre para desarrollar ciencia no libre.

La segunda solución que puede tener el problema del software científico libre es la creación de una revista indexada destinada específicamente a productos cuya licencia sea libre.

La tercera solución es el apoyo de las instituciones gubernamentales. En una primera solución, financiando proyectos libres, como ya hace el gobierno alemán, solo que en el área de software científico libre. Otra posibilidad es abrir grandes proyectos temáticos de software libre científico.

La última solución, es que aquellos proyectos financiados con dinero del estado deben ser libres.

La última corresponde a la universidad: liberando los resultados de proyectos fin de carrera, de resultados de investigación y de tesis de doctorado bajo GPL de documentación, y el código desarrollado bajo una hipotética GPL científica con las características anteriormente comentadas, ganamos todos. La comunidad porque cuenta con más código libre para compartir, y el investigador porque ve compensado su trabajo con el reconocimiento, los artículos y las citaciones que necesitará para conseguir becas y fondos para seguir investigando.