Crisis del software - Revision history

Mberne: /* Referencias */

2026-05-19T12:36:40Z

Referencias

← Older revision		Revision as of 14:36, 19 May 2026
Line 30:		Line 30:
	</div>		</div>
	== Referencias ==		== Referencias ==
	Bauer, F.; Bolliet, L.; Helms, H. (1968). ''Software Engineering. NATO Software Engineering Conference''. Garmisch: Peter Naur y Brian Randell.		* 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.

	~~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 ==		== Véase también ==
	<div class="bok-tags">		<div class="bok-tags">

Mberne: /* La respuesta: de los procesos a la agilidad */

2026-05-12T12:19:10Z

La respuesta: de los procesos a la agilidad

← Older revision		Revision as of 14:19, 12 May 2026
Line 21:		Line 21:
	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.		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.

	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.		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.		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.

Mberne at 12:18, 12 May 2026

2026-05-12T12:18:54Z

← Older revision		Revision as of 14:18, 12 May 2026
Line 1:		Line 1:
			{{Meta-bok\|min=4}}

	~~El término~~ '''~~“crisis~~ del ~~software”~~''' ~~se acuñó~~ en 1968~~<sup>1</sup>~~, en la primera conferencia ~~que~~ 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.		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.

	~~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~~.		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í:

	Es en ~~este contexto donde comienza a tener razón~~ de ~~ser~~ el ~~concepto~~ de ~~"proyecto~~ de ~~software"~~. ~~Según Roger~~ Pressman:		<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>

	<blockquote><small>[...] 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.</small><sup>2</sup></blockquote>		== Hitos del conocimiento sobre desarrollo de software (años 60 y 70) ==
	==~~Conocimientos~~ sobre el 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:
	*En 1962 se ~~publicó~~ el primer algoritmo para búsquedas binarias.		* '''1962:''' se publica el primer algoritmo para búsquedas binarias.
	*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~~<sup>3</sup>~~.		* '''1966:''' Böhm y Jacopini publican el documento fundacional de la programación estructurada, sentando las bases para eliminar la sentencia GoTo.
	*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<sup>4</sup>~~.		* '''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.
	*La primera ~~publicación~~ sobre programación estructurada ~~no vio la luz hasta 1976<sup>5</sup>.~~		* '''1976:''' se publica la primera obra sobre programación estructurada y el primer libro sobre análisis de requisitos.
	*El primer libro sobre ~~métrica~~ de ~~software fue publicado en 1976 por Tom Gilb<sup>6</sup>~~.		* '''1977:''' Tom Gilb publica el primer libro sobre métricas de software.
	*~~El primero~~ sobre ~~análisis~~ de ~~requisitos apareció en 1976<sup>7</sup>~~.

	==~~Referencias~~==		== La respuesta: de los procesos a la agilidad ==
	*<~~sup~~>1</~~sup~~> Bauer, F., Bolliet, L.~~, &~~ Helms, H. (1968): ''Software Engineering. ~~Nato~~ Software Engineering Conference'' ~~(pág. 136)~~. Garmisch: Peter Naur ~~and~~ Brian Randell.		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.
	*<sup>2</sup> Pressman, R. (1992) ''Ingenieria de software, un enfoque práctico'', Mc Graw Hill.
	*<sup>3</sup> Böhm C. & Jacopini G. (1966) "Flow diagrams, ~~turing~~ machines and languages with only two formation rules", ''~~Magazine~~ Communications of the ACM'', ~~Volume~~ 9 ~~Issue~~ 5, ~~may, p. 366-371. New York~~.		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.
	*<sup>4</sup> Dijkstra, Edsger W. (1968) ''Go To Statement Considered Harmful''.
	*<sup>5</sup> Yourdon, ~~Edward & Constantine Larry L~~. (~~1979~~) ''~~Structured design~~: ~~fundamentals of a discipline of computer program and systems design~~''~~, Yourdon Press computing series~~.		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.
	*<~~sup~~>6</~~sup~~> ~~Gilb, T. (1977)~~ ''~~Software Metrics~~''~~, Winthrop Publishers.~~
	*<~~sup~~>7<~~/sup~~> ~~Bell, T~~., ~~& Thayer, T~~. ~~(1976) "Software requirements: Are they really a problem?"~~ ''~~ICSE~~ '~~76 Proceedings of the 2nd international conference on Software engineering~~''.		== Error frecuente ==
	==~~Véase también~~==		<div class="bok-aviso">
	*[~~[Modelo original de Scrum para desarrollo de software~~]].		'''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:Glosario de términos]]
	[[Category:Marcos_y_modelos]]		[[Category:Marcos_y_modelos]]

Mberne at 12:16, 12 May 2026

2026-05-12T12:16:15Z

← Older revision		Revision as of 14:16, 12 May 2026
Line 6:		Line 6:
	Es en este contexto donde comienza a tener razón de ser el concepto de "proyecto de software". Según Roger Pressman:		Es en este contexto donde comienza a tener razón de ser el concepto de "proyecto de software". Según Roger Pressman:

	<blockquote>''[...] 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.''<sup>2</sup></blockquote>		<blockquote><small>[...] 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.</small><sup>2</sup></blockquote>
	==Conocimientos sobre el desarrollo de software (años 60 y 70)==		==Conocimientos sobre el desarrollo de software (años 60 y 70)==
	*En 1962 se publicó el primer algoritmo para búsquedas binarias.		*En 1962 se publicó el primer algoritmo para búsquedas binarias.

Mberne at 13:59, 11 May 2026

2026-05-11T13:59:58Z

← Older revision		Revision as of 15:59, 11 May 2026
Line 26:		Line 26:
	*[[Modelo original de Scrum para desarrollo de software]].		*[[Modelo original de Scrum para desarrollo de software]].
	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]
			[[Category:Marcos_y_modelos]]

Mberne at 10:30, 12 January 2024

2024-01-12T10:30:58Z

← Older revision		Revision as of 12:30, 12 January 2024
Line 23:		Line 23:
	*<sup>6</sup> Gilb, T. (1977) ''Software Metrics'', Winthrop Publishers.		*<sup>6</sup> Gilb, T. (1977) ''Software Metrics'', Winthrop Publishers.
	*<sup>7</sup> Bell, T., & Thayer, T. (1976) "Software requirements: Are they really a problem?" ''ICSE '76 Proceedings of the 2nd international conference on Software engineering''.		*<sup>7</sup> Bell, T., & Thayer, T. (1976) "Software requirements: Are they really a problem?" ''ICSE '76 Proceedings of the 2nd international conference on Software engineering''.
			==Véase también==
			*[[Modelo original de Scrum para desarrollo de software]].
	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]

Mberne at 10:30, 12 January 2024

2024-01-12T10:30:03Z

← Older revision		Revision as of 12:30, 12 January 2024
Line 10:		Line 10:
	*En 1962 se publicó el primer algoritmo para búsquedas binarias.		*En 1962 se publicó el primer algoritmo para búsquedas binarias.
	*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<sup>3</sup>.		*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<sup>3</sup>.
	*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]])~~.		*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<sup>4</sup>.
	*La primera publicación sobre programación estructurada no vio la luz hasta 1976 ~~([[Yourdon E. & Constantine L.]])~~.		*La primera publicación sobre programación estructurada no vio la luz hasta 1976<sup>5</sup>.
	*El primer libro sobre métrica de software fue publicado en 1976 por Tom Gilb ~~([[Gilb 1977]])~~.		*El primer libro sobre métrica de software fue publicado en 1976 por Tom Gilb<sup>6</sup>.
	*El primero sobre análisis de requisitos apareció en 1976 ~~([[Bell & Thayer]])~~.		*El primero sobre análisis de requisitos apareció en 1976<sup>7</sup>.

	==Referencias==		==Referencias==
Line 19:		Line 19:
	*<sup>2</sup> Pressman, R. (1992) ''Ingenieria de software, un enfoque práctico'', Mc Graw Hill.		*<sup>2</sup> Pressman, R. (1992) ''Ingenieria de software, un enfoque práctico'', Mc Graw Hill.
	*<sup>3</sup> Böhm C. & Jacopini G. (1966) "Flow diagrams, turing machines and languages with only two formation rules", ''Magazine Communications of the ACM'', Volume 9 Issue 5, may, p. 366-371. New York.		*<sup>3</sup> Böhm C. & Jacopini G. (1966) "Flow diagrams, turing machines and languages with only two formation rules", ''Magazine Communications of the ACM'', Volume 9 Issue 5, may, p. 366-371. New York.
			*<sup>4</sup> Dijkstra, Edsger W. (1968) ''Go To Statement Considered Harmful''.
			*<sup>5</sup> Yourdon, Edward & Constantine Larry L. (1979) ''Structured design: fundamentals of a discipline of computer program and systems design'', Yourdon Press computing series.
			*<sup>6</sup> Gilb, T. (1977) ''Software Metrics'', Winthrop Publishers.
			*<sup>7</sup> Bell, T., & Thayer, T. (1976) "Software requirements: Are they really a problem?" ''ICSE '76 Proceedings of the 2nd international conference on Software engineering''.
	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]

Mberne at 10:25, 12 January 2024

2024-01-12T10:25:44Z

← Older revision		Revision as of 12:25, 12 January 2024
Line 7:		Line 7:

	<blockquote>''[...] 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.''<sup>2</sup></blockquote>		<blockquote>''[...] 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.''<sup>2</sup></blockquote>
	==~~Bibliografía==~~		==Conocimientos sobre el desarrollo de software (años 60 y 70)==
	~~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.
	*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<sup>3</sup>.
	*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]]).		*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.]]).		*La primera publicación sobre programación estructurada no vio la luz hasta 1976 ([[Yourdon E. & Constantine L.]]).
Line 19:		Line 18:
	*<sup>1</sup> Bauer, F., Bolliet, L., & Helms, H. (1968): ''Software Engineering. Nato Software Engineering Conference'' (pág. 136). Garmisch: Peter Naur and Brian Randell.		*<sup>1</sup> Bauer, F., Bolliet, L., & Helms, H. (1968): ''Software Engineering. Nato Software Engineering Conference'' (pág. 136). Garmisch: Peter Naur and Brian Randell.
	*<sup>2</sup> Pressman, R. (1992) ''Ingenieria de software, un enfoque práctico'', Mc Graw Hill.		*<sup>2</sup> Pressman, R. (1992) ''Ingenieria de software, un enfoque práctico'', Mc Graw Hill.
			*<sup>3</sup> Böhm C. & Jacopini G. (1966) "Flow diagrams, turing machines and languages with only two formation rules", ''Magazine Communications of the ACM'', Volume 9 Issue 5, may, p. 366-371. New York.
	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]

Mberne at 10:21, 12 January 2024

2024-01-12T10:21:26Z

← Older revision		Revision as of 12:21, 12 January 2024
Line 4:		Line 4:
	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.		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 ~~[[Pressman\|~~Roger Pressman]]:		Es en este contexto donde comienza a tener razón de ser el concepto de "proyecto de software". Según Roger Pressman:

	<blockquote>''[...] 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.''</blockquote>		<blockquote>''[...] 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.''<sup>2</sup></blockquote>
	==Bibliografía==		==Bibliografía==
	Algunas referencias útiles para comprender cuáles eran los conocimientos estables para el desarrollo de software en los 60 y 70:		Algunas referencias útiles para comprender cuáles eran los conocimientos estables para el desarrollo de software en los 60 y 70:
Line 17:		Line 17:

	==Referencias==		==Referencias==
	*<sup>1</sup>Bauer, F., Bolliet, L., & Helms, H. (1968): ''Software Engineering. Nato Software Engineering Conference'' (pág. 136). Garmisch: Peter Naur and Brian Randell.		*<sup>1</sup> Bauer, F., Bolliet, L., & Helms, H. (1968): ''Software Engineering. Nato Software Engineering Conference'' (pág. 136). Garmisch: Peter Naur and Brian Randell.
			*<sup>2</sup> Pressman, R. (1992) ''Ingenieria de software, un enfoque práctico'', Mc Graw Hill.
	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]

Mberne at 11:12, 22 December 2023

2023-12-22T11:12:43Z

← Older revision		Revision as of 13:12, 22 December 2023
Line 1:		Line 1:

	El término '''“crisis del software”''' se acuñó en 1968 ~~[[Bauer, Bolliet, & Helms]]~~, en la primera conferencia que 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.		El término '''“crisis del software”''' se acuñó en 1968<sup>1</sup>, en la primera conferencia que 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.		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.