Crisis del software: Difference between revisions
No edit summary |
|||
| (18 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{Meta-bok|min=4}} | |||
La '''crisis del software''' es el término acuñado en 1968, en la primera conferencia de la OTAN sobre ingeniería del software celebrada en Garmisch (Alemania), para describir los problemas sistémicos que afectaban a los proyectos de desarrollo de software de la época: proyectos que terminaban tarde, desbordando los presupuestos y con fallos de funcionamiento. La misma conferencia acuñó también el término "ingeniería del software" para nombrar el conjunto de conocimientos que debía desarrollarse para dar solución a esa situación. | |||
Es | La crisis del software no fue un momento puntual sino un diagnóstico sostenido durante décadas sobre la dificultad de construir sistemas de software de forma predecible y con calidad. Es el contexto histórico que explica por qué surgieron los modelos de proceso, los modelos de madurez como [[CMM-SW]] y, más tarde, los enfoques ágiles. | ||
== El problema de fondo == | |||
El crecimiento de la demanda de software en los años sesenta superó con creces la capacidad de la industria para entregarlo de forma fiable. Los proyectos de software presentaban patrones recurrentes de fracaso: retrasos sistemáticos, costes finales muy superiores a los estimados, sistemas que no hacían lo que el cliente necesitaba y software difícil de mantener. | |||
Roger Pressman lo formuló así: | |||
<blockquote><small>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 ingeniería del software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de proyectos. (Pressman, 1992)</small><sup>2</sup></blockquote> | |||
== Hitos del conocimiento sobre desarrollo de software (años 60 y 70) == | |||
El período que rodea a la crisis del software fue también de intensa actividad intelectual: | |||
* '''1962:''' se publica el primer algoritmo para búsquedas binarias. | |||
* '''1966:''' Böhm y Jacopini publican el documento fundacional de la programación estructurada, sentando las bases para eliminar la sentencia GoTo. | |||
* '''1968:''' Edsger Dijkstra escribe su famosa carta "GoTo Statement Considered Harmful", en pleno debate sobre programación estructurada. Ese mismo año se celebra la conferencia de la OTAN. | |||
* '''1976:''' se publica la primera obra sobre programación estructurada y el primer libro sobre análisis de requisitos. | |||
* '''1977:''' Tom Gilb publica el primer libro sobre métricas de software. | |||
== La respuesta: de los procesos a la agilidad == | |||
La reacción inicial a la crisis del software fue la formalización de procesos: [[ingeniería secuencial|modelos secuenciales]] de desarrollo, [[CMM-SW|modelos de madurez]], estándares de proceso. El objetivo era hacer el desarrollo predecible mediante la disciplina de proceso. | |||
[[Category: | Esta respuesta fue parcialmente eficaz pero generó sus propios problemas: procesos pesados, documentación excesiva y poca capacidad de respuesta al cambio. La tensión entre rigor de proceso y adaptabilidad fue el caldo de cultivo del que surgió el [[El manifiesto ágil|''Manifiesto Ágil'']] en 2001. | ||
En cierto sentido, la agilidad no es una negación de las lecciones de la crisis del software, sino una respuesta diferente al mismo problema: cómo entregar software de calidad, a tiempo y que resuelva el problema real del cliente. | |||
== Error frecuente == | |||
<div class="bok-aviso"> | |||
'''Presentar la crisis del software como un problema resuelto.''' Los síntomas que describía la crisis —proyectos tarde, sobre presupuesto y que no hacen lo que el cliente necesita— siguen siendo habituales en 2025. La agilidad ha mejorado significativamente la situación en muchos contextos, pero no ha eliminado el problema. El Chaos Report del Standish Group ha documentado de forma consistente durante décadas que una proporción significativa de proyectos tecnológicos sigue fallando o entregando resultados parciales. | |||
</div> | |||
== Referencias == | |||
* Bauer, F.; Bolliet, L.; Helms, H. (1968). ''Software Engineering. NATO Software Engineering Conference''. Garmisch: Peter Naur y Brian Randell. | |||
* Böhm, C.; Jacopini, G. (1966). "Flow diagrams, Turing machines and languages with only two formation rules". ''Communications of the ACM'', 9(5), 366–371. | |||
* Dijkstra, Edsger W. (1968). ''Go To Statement Considered Harmful''. | |||
* Pressman, Roger. (1992). ''Ingeniería de software: un enfoque práctico''. McGraw-Hill. | |||
== Véase también == | |||
<div class="bok-tags"> | |||
[[El manifiesto ágil]] [[Ingeniería secuencial]] [[CMM-SW]] [[CMMI]] [[Gestión predictiva]] [[Agilidad]] [[Origen de scrum]] | |||
</div> | |||
<div class="bok-ecosistema"> | |||
<div class="texto"> | |||
<span class="titulo">'''¿Quieres avanzar en agilidad?'''</span> | |||
<span class="sub">Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a [https://scrummanager.com/skillarena/ '''Skill Arena''']: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.</span> | |||
</div> | |||
<div class="botones"> | |||
<div class="bok-btn-outline">[https://www.scrummanager.com/website/c/calendar/show-courses.php Buscar convocatorias]</div> | |||
<div class="bok-btn-filled">[https://scrummanager.com/club/ Club Agile]</div> | |||
</div> | |||
</div> | |||
[[Category:Glosario de términos]] | |||
[[Category:Marcos_y_modelos]] | |||
Latest revision as of 14:36, 19 May 2026
La crisis del software es el término acuñado en 1968, en la primera conferencia de la OTAN sobre ingeniería del software celebrada en Garmisch (Alemania), para describir los problemas sistémicos que afectaban a los proyectos de desarrollo de software de la época: proyectos que terminaban tarde, desbordando los presupuestos y con fallos de funcionamiento. La misma conferencia acuñó también el término "ingeniería del software" para nombrar el conjunto de conocimientos que debía desarrollarse para dar solución a esa situación.
La crisis del software no fue un momento puntual sino un diagnóstico sostenido durante décadas sobre la dificultad de construir sistemas de software de forma predecible y con calidad. Es el contexto histórico que explica por qué surgieron los modelos de proceso, los modelos de madurez como CMM-SW y, más tarde, los enfoques ágiles.
El problema de fondo
El crecimiento de la demanda de software en los años sesenta superó con creces la capacidad de la industria para entregarlo de forma fiable. Los proyectos de software presentaban patrones recurrentes de fracaso: retrasos sistemáticos, costes finales muy superiores a los estimados, sistemas que no hacían lo que el cliente necesitaba y software difícil de mantener. Roger Pressman lo formuló así:
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 ingeniería del software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de proyectos. (Pressman, 1992)2
Hitos del conocimiento sobre desarrollo de software (años 60 y 70)
El período que rodea a la crisis del software fue también de intensa actividad intelectual:
- 1962: se publica el primer algoritmo para búsquedas binarias.
- 1966: Böhm y Jacopini publican el documento fundacional de la programación estructurada, sentando las bases para eliminar la sentencia GoTo.
- 1968: Edsger Dijkstra escribe su famosa carta "GoTo Statement Considered Harmful", en pleno debate sobre programación estructurada. Ese mismo año se celebra la conferencia de la OTAN.
- 1976: se publica la primera obra sobre programación estructurada y el primer libro sobre análisis de requisitos.
- 1977: Tom Gilb publica el primer libro sobre métricas de software.
La respuesta: de los procesos a la agilidad
La reacción inicial a la crisis del software fue la formalización de procesos: modelos secuenciales de desarrollo, modelos de madurez, estándares de proceso. El objetivo era hacer el desarrollo predecible mediante la disciplina de proceso.
Esta respuesta fue parcialmente eficaz pero generó sus propios problemas: procesos pesados, documentación excesiva y poca capacidad de respuesta al cambio. La tensión entre rigor de proceso y adaptabilidad fue el caldo de cultivo del que surgió el Manifiesto Ágil en 2001.
En cierto sentido, la agilidad no es una negación de las lecciones de la crisis del software, sino una respuesta diferente al mismo problema: cómo entregar software de calidad, a tiempo y que resuelva el problema real del cliente.
Error frecuente
Presentar la crisis del software como un problema resuelto. Los síntomas que describía la crisis —proyectos tarde, sobre presupuesto y que no hacen lo que el cliente necesita— siguen siendo habituales en 2025. La agilidad ha mejorado significativamente la situación en muchos contextos, pero no ha eliminado el problema. El Chaos Report del Standish Group ha documentado de forma consistente durante décadas que una proporción significativa de proyectos tecnológicos sigue fallando o entregando resultados parciales.
Referencias
- Bauer, F.; Bolliet, L.; Helms, H. (1968). Software Engineering. NATO Software Engineering Conference. Garmisch: Peter Naur y Brian Randell.
- Böhm, C.; Jacopini, G. (1966). "Flow diagrams, Turing machines and languages with only two formation rules". Communications of the ACM, 9(5), 366–371.
- Dijkstra, Edsger W. (1968). Go To Statement Considered Harmful.
- Pressman, Roger. (1992). Ingeniería de software: un enfoque práctico. McGraw-Hill.
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.