La Crisis del software se refiere a los problemas que, desde sus inicios, ha ido experimentando el software, muchas veces problemas de gran magnitud, debido, principalmente, a la mínima eficacia que presentan una gran cantidad de empresas al momento de realizar un software. Sin embargo, no fue hasta 1968 cuando en la primera conferencia elaborada por la OTAN (Organización del Tratado del Atlántico Norte), Friedrich L. Bauer habló por primera vez del conjunto de dificultades o errores ocurridos en la planificación, estimación de los costos, productividad y calidad de un software, o bien, lo que se conoce como la crisis del software, dicho término se le atribuyó a F. L. Bauer aunque ya había sido utilizado por Edsger Dijkstra en su libro The Humble Programmer. Para dar solución a los problemas que se presentaban en esta conferencia se creó una nueva rama de ingeniería, la ingeniería de software.[1]
Causas
Existen múltiples causas que originan la crisis del software. Una de ellas es que el desarrollo de un software es un proceso relativamente “nuevo”, del cual no se tiene personal lo suficientemente capacitado, debido a una pobre implementación de los procesos más organizados. Por otro lado, debido a que el software es el conjunto de programas o instrucciones de una computadora, y que por lo tanto, no es un elemento de carácter físico; es poco probable que resulte exitoso el primer intento de elaboración, ya que el personal encargado de su realización no posee total claridad de los requerimientos de su cliente, lo que a su vez, vuelve en exceso complicado hacer un diseño detallado de requerimientos, pues es importante mencionar que su calidad se mide con respecto a su funcionamiento.
En muchos casos la automatización representa retribuciones económicas directas, pero para casos específicos puede ser difícil notar una diferencia ya que la retribución que se obtiene no es precisamente monetaria, sino que puede aumentar la velocidad de producción o volverla más flexible. En cualquier situación el desarrollo de software es una actividad capaz de añadir valores.
En 1981 Barry Boehm estimó que el costo total del software en Estados Unidos fue del 2% del Producto Interno Bruto en 1980 lo que representa $40 billones. Después en 1985 el costo total se elevó a $70 billones en Estados Unidos y $140 billones en todo el mundo. Para 1999 Boehm y Sullivan estimaron que el costo en 1998 aumentó a los $300 - 400 billones en Estados Unidos y casi el doble a nivel mundial. El costo total del software es una parte muy importante ya que no solo involucra el desarrollo del mismo, sino que también contempla el costo del mantenimiento una vez que se entrega y se encuentra funcionando. Es aquí donde se pueden encontrar la mayoría de los problemas ya que generalmente los proyectos carecían de una planeación y se trabajaba con mucha informalidad.[2]
En los años ‘60s las personas empezaban a notar que las técnicas que se utilizaban para programar habían quedado obsoletas, incluso algunos todavía creían que la programación de software debía considerarse un arte, como una actividad que debía ser más creativa que tradicional y disciplinada. Otro de los problemas es que muchos programadores no obtuvieron una educación formal y por lo tanto habían aprendido experimentando.
En conjunto provocaban que los resultados se obtuvieran pasada la fecha de entrega, los programas no funcionaban de manera correcta, era difícil realizar cambios y se excedían los plazos y costos planeados. La mayor parte de los errores se encuentran en una mala redacción del código (38.33%), le siguen los errores de diseño (24.17%), los de documentación (13.33%), de requerimientos (12.50%) y de correcciones mal implementadas (11.67%). Estos porcentajes nos dicen que el mayor número de errores provienen de la redacción del código, pero un error generado en la recolección de requerimientos puede propagarse al diseño y al código, incluso puede no aparecer hasta después de haber entregado el producto. En la mayoría de los casos es más barato arreglar un error en el código que arreglar un error de requerimientos ya que este afecta de manera directa el diseño y el código. Una buena práctica sería aplicar actividades que prevengan errores de requerimientos, desgraciadamente se dedica muy poco tiempo a la recolección de requerimientos y las especificaciones.[3]
Para evitar errores de este tipo lo mejor que se puede hacer es realizar revisiones formales ya que cuantos más errores se puedan encontrar antes de escribir el código menos impacto tendrán en el mismo, la fase de pruebas y en la respectiva documentación. Muchas fallas en proyectos son atribuidas a un código mal escrito, pero en muchos casos estas acusaciones no están bien fundamentadas o el software no es completamente culpable. A veces los errores tienen un origen más simple, un mal manejo del software, mala comunicación o falta de entrenamiento.
Proyectos Fallidos en la Crisis del Software
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.[4]
Referencias
Dijkstra, Edger. The Humble Programmer.
Van Vliet, Hans (2008). SOFTWARE ENGINEERING. Chichester, England: Wiley.
Karam, Orlando, Tsui, Frank (2007). Essentials of Software Engineering. Sudbury, Massachusetts: Jones and Bartlett.
↑ Weitzenfeld, Alfredo (2005). Ingeniería de Software Orientada a Objetos con UML, Java e Internet. D.F., México: Thomson.
Datos:Q1065938
Agosto 09, 2021
crisis, software, refiere, problemas, desde, inicios, experimentando, software, muchas, veces, problemas, gran, magnitud, debido, principalmente, mínima, eficacia, presentan, gran, cantidad, empresas, momento, realizar, software, embargo, hasta, 1968, cuando, . La Crisis del software se refiere a los problemas que desde sus inicios ha ido experimentando el software muchas veces problemas de gran magnitud debido principalmente a la minima eficacia que presentan una gran cantidad de empresas al momento de realizar un software Sin embargo no fue hasta 1968 cuando en la primera conferencia elaborada por la OTAN Organizacion del Tratado del Atlantico Norte Friedrich L Bauer hablo por primera vez del conjunto de dificultades o errores ocurridos en la planificacion estimacion de los costos productividad y calidad de un software o bien lo que se conoce como la crisis del software dicho termino se le atribuyo a F L Bauer aunque ya habia sido utilizado por Edsger Dijkstra en su libro The Humble Programmer Para dar solucion a los problemas que se presentaban en esta conferencia se creo una nueva rama de ingenieria la ingenieria de software 1 Causas EditarExisten multiples causas que originan la crisis del software Una de ellas es que el desarrollo de un software es un proceso relativamente nuevo del cual no se tiene personal lo suficientemente capacitado debido a una pobre implementacion de los procesos mas organizados Por otro lado debido a que el software es el conjunto de programas o instrucciones de una computadora y que por lo tanto no es un elemento de caracter fisico es poco probable que resulte exitoso el primer intento de elaboracion ya que el personal encargado de su realizacion no posee total claridad de los requerimientos de su cliente lo que a su vez vuelve en exceso complicado hacer un diseno detallado de requerimientos pues es importante mencionar que su calidad se mide con respecto a su funcionamiento En muchos casos la automatizacion representa retribuciones economicas directas pero para casos especificos puede ser dificil notar una diferencia ya que la retribucion que se obtiene no es precisamente monetaria sino que puede aumentar la velocidad de produccion o volverla mas flexible En cualquier situacion el desarrollo de software es una actividad capaz de anadir valores En 1981 Barry Boehm estimo que el costo total del software en Estados Unidos fue del 2 del Producto Interno Bruto en 1980 lo que representa 40 billones Despues en 1985 el costo total se elevo a 70 billones en Estados Unidos y 140 billones en todo el mundo Para 1999 Boehm y Sullivan estimaron que el costo en 1998 aumento a los 300 400 billones en Estados Unidos y casi el doble a nivel mundial El costo total del software es una parte muy importante ya que no solo involucra el desarrollo del mismo sino que tambien contempla el costo del mantenimiento una vez que se entrega y se encuentra funcionando Es aqui donde se pueden encontrar la mayoria de los problemas ya que generalmente los proyectos carecian de una planeacion y se trabajaba con mucha informalidad 2 En los anos 60s las personas empezaban a notar que las tecnicas que se utilizaban para programar habian quedado obsoletas incluso algunos todavia creian que la programacion de software debia considerarse un arte como una actividad que debia ser mas creativa que tradicional y disciplinada Otro de los problemas es que muchos programadores no obtuvieron una educacion formal y por lo tanto habian aprendido experimentando En conjunto provocaban que los resultados se obtuvieran pasada la fecha de entrega los programas no funcionaban de manera correcta era dificil realizar cambios y se excedian los plazos y costos planeados La mayor parte de los errores se encuentran en una mala redaccion del codigo 38 33 le siguen los errores de diseno 24 17 los de documentacion 13 33 de requerimientos 12 50 y de correcciones mal implementadas 11 67 Estos porcentajes nos dicen que el mayor numero de errores provienen de la redaccion del codigo pero un error generado en la recoleccion de requerimientos puede propagarse al diseno y al codigo incluso puede no aparecer hasta despues de haber entregado el producto En la mayoria de los casos es mas barato arreglar un error en el codigo que arreglar un error de requerimientos ya que este afecta de manera directa el diseno y el codigo Una buena practica seria aplicar actividades que prevengan errores de requerimientos desgraciadamente se dedica muy poco tiempo a la recoleccion de requerimientos y las especificaciones 3 Para evitar errores de este tipo lo mejor que se puede hacer es realizar revisiones formales ya que cuantos mas errores se puedan encontrar antes de escribir el codigo menos impacto tendran en el mismo la fase de pruebas y en la respectiva documentacion Muchas fallas en proyectos son atribuidas a un codigo mal escrito pero en muchos casos estas acusaciones no estan bien fundamentadas o el software no es completamente culpable A veces los errores tienen un origen mas simple un mal manejo del software mala comunicacion o falta de entrenamiento Proyectos Fallidos en la Crisis del Software EditarTanto en sus inicios como en la epoca actual una gran cantidad de proyectos de software tuvieron diversos problemas con respecto al tiempo y presupuesto que se le habia estimado causando accidentes que mas alla de costos involucraban danos 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 avion de combate se estrello por culpa de un giro descontrolado atribuido a una expresion if then para la cual no habia una expresion else debido a que los desarrolladores del software lo consideraron innecesario 4 Muertes por el Therac 25 1985 1987 El Therac 25 fue una maquina de radioterapia que causo la muerte de varios pacientes en diversos hospitales de Estados Unidos y Canada debido a las radiaciones de alto poder aplicadas sin control las cuales fueron atribuidas a la falta de control de calidad del software medico 4 Sobrecosto retraso y cancelacion en el sistema del Bank of America 1988 En el ano de 1988 este banco invirtio 23 millones de dolares en un sistema computarizado llamado MasterNet el cual servia para contabilidad y reportes de fideicomisos No obstante para que el sistema funcionara se tuvo que invertir 60 millones de dolares mas por lo que finalmente el sistema fue cancelado 4 Referencias Editar Dijkstra Edger The Humble Programmer Van Vliet Hans 2008 SOFTWARE ENGINEERING Chichester England Wiley Karam Orlando Tsui Frank 2007 Essentials of Software Engineering Sudbury Massachusetts Jones and Bartlett a b c Weitzenfeld Alfredo 2005 Ingenieria de Software Orientada a Objetos con UML Java e Internet D F Mexico Thomson Datos Q1065938Obtenido de https es wikipedia org w index php title Crisis del software amp oldid 134120445, wikipedia, wiki, leyendo, leer, libro, biblioteca,
