Diferencia entre revisiones de «Crisis del software»
Revertidos los cambios de 200.25.239.136 a la última edición de Herraiz con monobook-suite |
|||
| Línea 22: | Línea 22: | ||
= Referencias = |
= Referencias = |
||
[[http://www.cs.utexas.edu/ |
[[http://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html|Edsger Dijkstra, The Humble Programmer]] |
||
Revisión del 15:14 13 oct 2007
El término crisis del software se acuñó en 1968, en la primera conferencia organizada por la OTAN sobre desarrollo de software (en esa misma conferencia también se acuañó el término Ingeniería de Software). El término fue acuñado por F. L. Bauer, aunque ya había sido usado antes por Edsger Dijkstra en su obra The Humble Programmer (catalogada en la obra de Dijkstra como EWD 340).
Básicamente, la crisis del software se refiere a la dificultad en escribir programas libres de defectos, fácilmente comprensibles, y que sean verificables. Las causas de la crisis del software son, entre otrass, la complejidad que supone la tarea de programar, y los cambios a los que se tiene que ver sometido un programa para que ser continuamente adaptado a las necesidades de los usuarios.
Además, no existen todavía herramientas que permitan estimar de una manera exacta, antes de comenzar el proyecto, cuál es el esfuerzo que se necesitará para desarrollar un programa. Este hecho provoca que la mayoría de las veces no sea posible estimar cuánto tiempo llevará un proyecto, ni cuánto personal será necesario. Cuando se fijan plazos normalmente no se cumplen por este hecho. Del mismo modo, en muchas ocasiones el personal asignado a un proyecto se incrementa con la esperanza de disminuir el plazo de ejecución.
Por último, las aplicaciones de hoy en día son programas muy complejos, inabordables por una sola persona.
En sus comienzos se valoró como causa también la inmadurez de la Ingeniería de Software, aunque todavía hoy en día no es posible realizar estimaciones precisas del coste y tiempo que necesitará un proyecto de software.
La crisis del software englobó a una serie de sucesos que se venían observando en los proyectos de desarrollo de software:
- Los proyectos no terminaban en plazo
- Los proyecto no se ajustaban al presupuesto inicial
- Baja calidad del software generado
- Software que no cumplía las especificaciones
- Código inmantenible que dificultaba la gestión y evolución del proyecto
Aunque se han propuesto diversas metodologías para intentar subsanar los problemas mencionados, lo cierto es que todavía hoy no existe ningún método que haya permitido estimar de manera fiable el coste y duración de un proyecto antes de su comienzos.