Crisis Del Software

Crisis del software
El término “crisis del software” se acuñó en 1968 Bauer, Bolliet, & Helms, en la primera conferencia
qeu la organización OTAN celebró sobre desarrollo de software. Con dicho término se definieron
los problemas que surgían en el desarrollo de sistemas de software, cuyos proyectos terminaban
tarde, desbordando los presupuestos y con problemas de funcionamiento.
También se acuñó el término “ingeniería del software” para describir el conjunto de conocimientos
que debía desarrollarse para dar solución a la situación.
Es en este contexto donde comienza a tener razón de ser el concepto de proyecto de software.
Según Roger Pressman “la gestión de proyectos implica la planificación, supervisión y control del
personal, del proceso y de los eventos que ocurren mientras evoluciona el software desde la fase
preliminar a la implementación operacional. La gestión eficaz del proyecto de software se centra
en las cuatro “P”: personal, producto, proceso y proyecto. El gestor que se olvida de que el trabajo
de ingeniera del software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de
proyectos. Un gestor que no fomenta una minuciosa comunicación con el cliente al principio de la
evolución del proyecto se arriesga a construir una elegante solución para un problema equivocado.
El administrador que presta poca atención al proceso corre el riesgo de arrojar métodos técnicos y
herramientas eficaces al vacio.”
Algunas referencias útiles para comprender cuáles eran los conocimientos estables para el
desarrollo de software en los 60 y 70:
En 1962 se publicó el primer algoritmo para búsquedas binarias (Iverson).
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 (Böhm & Jacopini).
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 (Dijkstra).
La primera publicación sobre programación estructurada no vio la luz hasta 1976 (Yourdon E. &
Constantine L.).
El primer libro sobre métrica de software fue publicado en 1976 por Tom Gilb (Gilb 1977).
El primero sobre análisis de requisitos apareció en 1976 (Bell & Thayer)

La percepción de que esta crisis existía empezó a mediados de los años 60. Una de las primeras
referencias al término, y de las más notables, fue hecha por E.W.Dijkstra, en el discurso que
pronunció durante la entrega del premio Turing en 1972.
En este trabajo abordaremos porque se produjo esta crisis, y cuál fue el camino adoptado para
resolverla, o minimizar sus efectos de algún modo.
CAUSAS DE LA CRISIS DEL SOFTWARE
Durante finales de los años 50 y principios de los 60 la potencia computacional de las maquinas era
bastante limitada. Es por esto que los programas que se desarrollaban eran “simples” desde
nuestro punto de vista actual.
Seguían un proceso de desarrollo bastante artesanal, sin una metodología o un camino a seguir
para su desarrollo. En esta época se solían usar los lenguajes de bajo nivel para el desarrollo de
Software.
Pero a finales de los 60, la potencia de las maquinas empezó a aumentar de forma considerable.
Empezaron a aparecer los lenguajes de programación de alto nivel, y las maquinas necesitaban
programas mucho más complejos de los desarrollados hasta la época. En definitiva, fue un salto
tremendo en cuanto a potencial de hardware, que no fue acompañado por un salto en el
desarrollo de software.
En esta época, se empezó a concebir el Software como producto, y se empezaron a desarrollar

algunos proyectos para que funcionaran en las máquinas de la época. Pero aparecieron
importantes problemas: los productos excedían la estimación de costes, había retrasos en las
entregas, las prestaciones no eran las solicitadas, el mantenimiento se hacía extremadamente
complicado y a veces imposible, las modificaciones tenían un coste prohibitivo…en resumen, se
desarrollaba software de mala calidad, ya que la técnica utilizada para desarrollar pequeños
programas para maquinas con mucho menos potencial se quedaba desfasada, y muchas veces este
software acababa en el olvido. Como ejemplo, podemos ver este gráfico del año 1979, en el que se
recoge la inversión en desarrollo de sistemas software en ese año ($6.8 Millones), y como acabó
ese software
Una de las principales causas de todo esto, si no la principal, era el enfoque dado al proceso de
desarrollo de software, el cual era malo e incluso a veces era inexistente. En este proceso, solo ¼
del tiempo de desarrollo se dedicaba a las fases de análisis, diseño, codificación y pruebas, y más
de ¾ del tiempo se dedicaba a correcciones y mantenimiento. Es evidente que dedicándole sol ¼
del tiempo a las primeras fases, se arrastran errores graves, sobre todo procedentes de las fases de
análisis y diseño, lo que dificultaba muchísimo la implementación, produciendo constantes paradas
y retrocesos para revisar este análisis/diseño.
Para que nos hagamos una idea, el conjunto de las fases de análisis y diseño abarcaban el 8% del
tiempo total de desarrollo de software. Además, casi el 80% de los errores se producían en estas
dos fases, con lo que se incrementaba el coste de corrección de errores conforme evolucionaban
las fases de manera bestial. Con estos indicadores estaba claro que algo estaba fallando y que el
proceso de desarrollo de software necesitaba un cambio radical.
Proyectos fallidos
Tanto en sus inicios, como en la época actual, una gran cantidad de proyectos de software tuvieron
diversos problemas con respecto al tiempo y presupuesto que se le había estimado, causando
accidentes que más allá de costos, involucraban daños a propiedades, y en el peor de los casos, la
muerte de personas.
Algunos ejemplos son:
Accidente de un F-18 (1986): En abril de 1986 un avión de combate se estrelló por culpa de un
giro descontrolado atribuido a una expresión “if then”, para la cual no había una expresión “else”,
debido a que los desarrolladores del software lo consideraron innecesario.4
Muertes por el Therac-25 (1985-1987): El Therac-25 fue una máquina de radioterapia que causó
la muerte de varios pacientes en diversos hospitales de Estados Unidos y Canadá, debido a las
radiaciones de alto poder aplicadas sin control, las cuales fueron atribuidas a la falta de control de
calidad del software médico.4
Sobrecosto, retraso y cancelación en el sistema del Bank of America (1988): En el año de 1988,
este banco invirtió 23 millones de dólares en un sistema computarizado llamado MasterNet, el cual
servía para contabilidad y reportes de fideicomisos. No obstante, para que el sistema funcionara,
se tuvo que invertir 60 millones de dólares más, por lo que finalmente el sistema fue cancelado
Fuente: https://histinf.blogs.upv.es/2011/01/04/la-crisis-del-software/

Crisis Del Software

Cargado por

Copyright:

Formatos disponibles

Crisis Del Software

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Crisis Del Software

Cargado por

Copyright:

Formatos disponibles

Crisis del software

En 1962 se publicó el primer algoritmo para búsquedas binarias (Iverson).

El primero sobre análisis de requisitos apareció en 1976 (Bell & Thayer)

CAUSAS DE LA CRISIS DEL SOFTWARE

En esta época, se empezó a concebir el Software como producto, y se empezaron a desarrollar

Algunos ejemplos son:

También podría gustarte