Crisis del software cumple los años el 3 de marzo.
Crisis del software nació el día 3 de marzo de 3.
La edad actual es 2021 años. Crisis del software cumplió 2021 años el 3 de marzo de este año.
Crisis del software es del signo de Piscis.
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.
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.
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.
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.
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:
Escribe un comentario o lo que quieras sobre Crisis del software (directo, no tienes que registrarte)
Comentarios
(de más nuevos a más antiguos)