Deuda técnica - Revision history

Mberne at 11:10, 12 January 2024

2024-01-12T11:10:45Z

← Older revision		Revision as of 13:10, 12 January 2024
Line 39:		Line 39:
	*[[Crisis del software]].		*[[Crisis del software]].
	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]
	~~[[Category:Sueltos]]~~

Mberne at 10:15, 12 January 2024

2024-01-12T10:15:43Z

← Older revision		Revision as of 12:15, 12 January 2024
Line 27:		Line 27:

	Una opción muy extendida para llevar este tipo de diarios es utilizar las listas de tareas que habitualmente incorporan los entornos de desarrollo, las cuales escanean automáticamente el código en busca de comentarios con etiquetas en un formato particular y que, a partir de los hallazgos encontrados, generan un lista. Habitualmente, los entornos de desarrollo suelen aceptar las siguientes '''etiquetas''':		Una opción muy extendida para llevar este tipo de diarios es utilizar las listas de tareas que habitualmente incorporan los entornos de desarrollo, las cuales escanean automáticamente el código en busca de comentarios con etiquetas en un formato particular y que, a partir de los hallazgos encontrados, generan un lista. Habitualmente, los entornos de desarrollo suelen aceptar las siguientes '''etiquetas''':
			*'''FIXME:''' permite marcar una porción de código problemático (se sabe que en determinadas circunstancias falla o puede fallar) y que por tanto requiere una especial atención y/o revisión posterior.
	*FIXME: permite marcar una porción de código problemático (se sabe que en determinadas circunstancias falla o puede fallar) y que por tanto requiere una especial atención y/o revisión posterior.		*'''NOTE:''' permite indicar el funcionamiento interno de código o posibles dificultades que no están documentadas.
	*NOTE: permite indicar el funcionamiento interno de código o posibles dificultades que no están documentadas.		*'''TODO:''' indica posibles mejoras a realizar en un futuro más o menos próximo.
	*TODO: indica posibles mejoras a realizar en un futuro más o menos próximo.		*'''XXX, KLUDGE, KLUGE o HACK:''' cualquiera de ellos advierte de código ineficiente, poco elegante o incluso insondable, pero que, sin embargo, funciona.
	*XXX, KLUDGE, KLUGE o HACK: cualquiera de ellos advierte de código ineficiente, poco elegante o incluso insondable, pero que, sin embargo, funciona.

	Para evitar el riesgo de que estas anotaciones se acumulen con el tiempo (o lo que es lo mismo, de que la deuda técnica se acumule) puede resultar útil incluir la fecha al comentario asociado a la etiqueta para facilitar su seguimiento. Además, también puede resultar interesante anotar el número de veces que esa porción de código ha provocado algún tipo de problema.		Para evitar el riesgo de que estas anotaciones se acumulen con el tiempo (o lo que es lo mismo, de que la deuda técnica se acumule) puede resultar útil incluir la fecha al comentario asociado a la etiqueta para facilitar su seguimiento. Además, también puede resultar interesante anotar el número de veces que esa porción de código ha provocado algún tipo de problema.

	Con toda esta información será posible determinar, en cada momento, la cantidad de deuda técnica que acumula un proyecto para determinar, así mismo, cuando ha llegado el momento de detenerse a resolver cada uno de los problemas de los que se compone.		Con toda esta información será posible determinar, en cada momento, la cantidad de deuda técnica que acumula un proyecto para determinar, así mismo, cuando ha llegado el momento de detenerse a resolver cada uno de los problemas de los que se compone.
			==Véase también==
			*[[Modelo original de Scrum para desarrollo de software]].
			*[[Crisis del software]].
	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]
	[[Category:Sueltos]]		[[Category:Sueltos]]

Mberne at 12:45, 18 December 2023

2023-12-18T12:45:40Z

← Older revision		Revision as of 14:45, 18 December 2023
Line 1:		Line 1:
	~~Neologismo~~ empleado en el sector profesional TIC para describir la deuda de trabajo que se adquiere al producir código pobre, incumpliendo prácticas aconsejadas para el desarrollo de software. Los proyectos que actúan de esta forma, normalmente para atajar los tiempos de entrega adquieren una "deuda técnica", cuyos "intereses" se tendrán que acabar pagando, y supondrán mayor cuantía cuanto más tiempo pase.		'''Deuda técnica''' es un neologismo empleado en el sector profesional TIC para describir la deuda de trabajo que se adquiere al producir código pobre, incumpliendo prácticas aconsejadas para el desarrollo de software.
			==Descripción==
			Los proyectos que actúan de esta forma, normalmente para atajar los tiempos de entrega adquieren una "deuda técnica", cuyos "intereses" se tendrán que acabar pagando, y supondrán mayor cuantía cuanto más tiempo pase.

	La deuda técnica suele materializarse en las siguientes formas:		La deuda técnica suele '''materializarse en las siguientes formas:'''
	* Documentación escasa, incompleta o inservible.		* Documentación escasa, incompleta o inservible.
	* Errores.		* Errores.
Line 7:		Line 9:
	* Arquitectura no escalable.		* Arquitectura no escalable.
	* Rigidez para actualizar a nuevas tecnologías o plataformas.		* Rigidez para actualizar a nuevas tecnologías o plataformas.
			==Origen y evolución==

	El término deuda técnica surge de una analogía utilizada por Ward Cunningham en 1992 en la que realiza la equivalencia entre un desarrollo de software que presentase determinadas carencias debido, generalmente, a la necesidad de realizar una entrega temprana, con la petición de un crédito financiero.		El término deuda técnica surge de una analogía utilizada por Ward Cunningham en 1992 en la que realiza la equivalencia entre un desarrollo de software que presentase determinadas carencias debido, generalmente, a la necesidad de realizar una entrega temprana, con la petición de un crédito financiero.

	Esta analogía ha sido ampliamente extendida ya que de igual forma que dicho crédito permitiría obtener liquidez a corto plazo a costa de generar unos intereses a liquidar durante un período de tiempo prolongado, las carencias introducidas durante el desarrollo del software proporcionan un beneficio a corto plazo (la entrega a tiempo de una versión del software) pero tarde o temprano requerirán gastar el tiempo inicialmente ahorrado sumado a un esfuerzo extra (los intereses), es decir, dichas carencias generarán una deuda técnica con los mismos aspectos negativos que los intereses del crédito financiero solicitado.		Esta analogía ha sido ampliamente extendida ya que de igual forma que dicho crédito permitiría obtener liquidez a corto plazo a costa de generar unos intereses a liquidar durante un período de tiempo prolongado, las carencias introducidas durante el desarrollo del software proporcionan un beneficio a corto plazo (la entrega a tiempo de una versión del software) pero tarde o temprano requerirán gastar el tiempo inicialmente ahorrado sumado a un esfuerzo extra (los intereses), es decir, dichas carencias generarán una deuda técnica con los mismos aspectos negativos que los intereses del crédito financiero solicitado.
			==Clasificación==
	~~Y aunque las~~ deudas técnicas se pueden clasificar en ~~advertidas~~ o inadvertidas~~, y en prudentes o imprudentes, atendiendo~~ al reconocimiento o no de la deuda en el momento en que esta se da y a la realización o no de un análisis de costo frente a beneficios, y ~~a pesar~~ de que cada equipo tendrá que atender sus propias carencias durante el desarrollo de sus proyectos de software, a continuación se listan algunos ejemplos típicos de deudas técnicas:		Las deudas técnicas se pueden clasificar en:
			*'''Advertidas o inadvertidas.''' Si se atiende al reconocimiento o no de la deuda en el momento en que esta se da.
			*'''Prudentes o imprudentes.''' Si se atiende a la realización o no de un análisis de costo frente a beneficios.
			===Ejemplos===
			A pesar de los tipos de deuda técnica y de que cada equipo tendrá que atender sus propias carencias durante el desarrollo de sus proyectos de software, a continuación se listan algunos ejemplos típicos de deudas técnicas:
	*Errores conocidos y no solucionados.		*Errores conocidos y no solucionados.
	*Mejoras en el código no implementadas.		*Mejoras en el código no implementadas.
	*Insuficientes pruebas o pruebas de mala calidad.		*Insuficientes pruebas o pruebas de mala calidad.
	*Documentación desactualizada, incompleta o inexistente.		*Documentación desactualizada, incompleta o inexistente.
			==El diario de deuda técnica==
			Es una herramienta que permite conocer la deuda técnica advertida, acumulada en cualquier momento del proyecto.

	~~El diario de deuda técnica~~		Una opción muy extendida para llevar este tipo de diarios es utilizar las listas de tareas que habitualmente incorporan los entornos de desarrollo, las cuales escanean automáticamente el código en busca de comentarios con etiquetas en un formato particular y que, a partir de los hallazgos encontrados, generan un lista. Habitualmente, los entornos de desarrollo suelen aceptar las siguientes '''etiquetas''':
	~~Un diario de deuda técnica es una herramienta que permite conocer la deuda técnica advertida, acumulada en cualquier momento del proyecto.~~

	Una opción muy extendida para llevar este tipo de diarios es utilizar las listas de tareas que habitualmente incorporan los entornos de desarrollo, las cuales escanean automáticamente el código en busca de comentarios con etiquetas en un formato particular y que, a partir de los hallazgos encontrados, generan un lista. Habitualmente, los entornos de desarrollo suelen aceptar las siguientes etiquetas:

	*FIXME: permite marcar una porción de código problemático (se sabe que en determinadas circunstancias falla o puede fallar) y que por tanto requiere una especial atención y/o revisión posterior.		*FIXME: permite marcar una porción de código problemático (se sabe que en determinadas circunstancias falla o puede fallar) y que por tanto requiere una especial atención y/o revisión posterior.

Smanager at 10:27, 26 April 2021

2021-04-26T10:27:33Z

← Older revision		Revision as of 12:27, 26 April 2021
Line 36:		Line 36:

	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]
	[[Category:~~Información complementaria: ingeniería del software~~]]		[[Category:Sueltos]]

Smanager at 19:15, 6 May 2014

2014-05-06T19:15:04Z

← Older revision		Revision as of 21:15, 6 May 2014
Line 36:		Line 36:

	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]
	~~[[Category:Temario Técnicas ágiles en el desarrollo de software]]~~
	[[Category:Información complementaria: ingeniería del software]]		[[Category:Información complementaria: ingeniería del software]]

Smanager at 19:10, 6 May 2013

2013-05-06T19:10:10Z

← Older revision		Revision as of 21:10, 6 May 2013
Line 26:		Line 26:

	*FIXME: permite marcar una porción de código problemático (se sabe que en determinadas circunstancias falla o puede fallar) y que por tanto requiere una especial atención y/o revisión posterior.		*FIXME: permite marcar una porción de código problemático (se sabe que en determinadas circunstancias falla o puede fallar) y que por tanto requiere una especial atención y/o revisión posterior.
	NOTE: permite indicar el funcionamiento interno de código o posibles dificultades que no están documentadas.		*NOTE: permite indicar el funcionamiento interno de código o posibles dificultades que no están documentadas.
	*TODO: indica posibles mejoras a realizar en un futuro más o menos próximo.		*TODO: indica posibles mejoras a realizar en un futuro más o menos próximo.
	*XXX, KLUDGE, KLUGE o HACK: cualquiera de ellos advierte de código ineficiente, poco elegante o incluso insondable, pero que, sin embargo, funciona.		*XXX, KLUDGE, KLUGE o HACK: cualquiera de ellos advierte de código ineficiente, poco elegante o incluso insondable, pero que, sin embargo, funciona.

Smanager at 11:58, 5 March 2013

2013-03-05T11:58:56Z

← Older revision		Revision as of 13:58, 5 March 2013
Line 35:		Line 35:


	[[Category:Glosario de términos]][[Category:Temario Técnicas ágiles en el desarrollo de software]]		[[Category:Glosario de términos]]
			[[Category:Temario Técnicas ágiles en el desarrollo de software]]
			[[Category:Información complementaria: ingeniería del software]]

Smanager at 16:29, 23 January 2013

2013-01-23T16:29:27Z

← Older revision		Revision as of 18:29, 23 January 2013
Line 8:		Line 8:
	* Rigidez para actualizar a nuevas tecnologías o plataformas.		* Rigidez para actualizar a nuevas tecnologías o plataformas.

	[[Category:Glosario de términos]]
			El término deuda técnica surge de una analogía utilizada por Ward Cunningham en 1992 en la que realiza la equivalencia entre un desarrollo de software que presentase determinadas carencias debido, generalmente, a la necesidad de realizar una entrega temprana, con la petición de un crédito financiero.

			Esta analogía ha sido ampliamente extendida ya que de igual forma que dicho crédito permitiría obtener liquidez a corto plazo a costa de generar unos intereses a liquidar durante un período de tiempo prolongado, las carencias introducidas durante el desarrollo del software proporcionan un beneficio a corto plazo (la entrega a tiempo de una versión del software) pero tarde o temprano requerirán gastar el tiempo inicialmente ahorrado sumado a un esfuerzo extra (los intereses), es decir, dichas carencias generarán una deuda técnica con los mismos aspectos negativos que los intereses del crédito financiero solicitado.

			Y aunque las deudas técnicas se pueden clasificar en advertidas o inadvertidas, y en prudentes o imprudentes, atendiendo al reconocimiento o no de la deuda en el momento en que esta se da y a la realización o no de un análisis de costo frente a beneficios, y a pesar de que cada equipo tendrá que atender sus propias carencias durante el desarrollo de sus proyectos de software, a continuación se listan algunos ejemplos típicos de deudas técnicas:

			*Errores conocidos y no solucionados.
			*Mejoras en el código no implementadas.
			*Insuficientes pruebas o pruebas de mala calidad.
			*Documentación desactualizada, incompleta o inexistente.

			El diario de deuda técnica
			Un diario de deuda técnica es una herramienta que permite conocer la deuda técnica advertida, acumulada en cualquier momento del proyecto.

			Una opción muy extendida para llevar este tipo de diarios es utilizar las listas de tareas que habitualmente incorporan los entornos de desarrollo, las cuales escanean automáticamente el código en busca de comentarios con etiquetas en un formato particular y que, a partir de los hallazgos encontrados, generan un lista. Habitualmente, los entornos de desarrollo suelen aceptar las siguientes etiquetas:

			*FIXME: permite marcar una porción de código problemático (se sabe que en determinadas circunstancias falla o puede fallar) y que por tanto requiere una especial atención y/o revisión posterior.
			NOTE: permite indicar el funcionamiento interno de código o posibles dificultades que no están documentadas.
			*TODO: indica posibles mejoras a realizar en un futuro más o menos próximo.
			*XXX, KLUDGE, KLUGE o HACK: cualquiera de ellos advierte de código ineficiente, poco elegante o incluso insondable, pero que, sin embargo, funciona.

			Para evitar el riesgo de que estas anotaciones se acumulen con el tiempo (o lo que es lo mismo, de que la deuda técnica se acumule) puede resultar útil incluir la fecha al comentario asociado a la etiqueta para facilitar su seguimiento. Además, también puede resultar interesante anotar el número de veces que esa porción de código ha provocado algún tipo de problema.

			Con toda esta información será posible determinar, en cada momento, la cantidad de deuda técnica que acumula un proyecto para determinar, así mismo, cuando ha llegado el momento de detenerse a resolver cada uno de los problemas de los que se compone.


			[[Category:Glosario de términos]][[Category:Temario Técnicas ágiles en el desarrollo de software]]

Smanager: Created page with "Neologismo empleado en el sector profesional TIC para describir la deuda de trabajo que se adquiere al producir código pobre, incumpliendo prácticas aconsejadas para el desa..."

2013-01-11T16:38:10Z

Created page with "Neologismo empleado en el sector profesional TIC para describir la deuda de trabajo que se adquiere al producir código pobre, incumpliendo prácticas aconsejadas para el desa..."

New page

Neologismo empleado en el sector profesional TIC para describir la deuda de trabajo que se adquiere al producir código pobre, incumpliendo prácticas aconsejadas para el desarrollo de software. Los proyectos que actúan de esta forma, normalmente para atajar los tiempos de entrega adquieren una "deuda técnica", cuyos "intereses" se tendrán que acabar pagando, y supondrán mayor cuantía cuanto más tiempo pase.

La deuda técnica suele materializarse en las siguientes formas:
* Documentación escasa, incompleta o inservible.
* Errores.
* Ausencia o deficiente control de versiones.
* Arquitectura no escalable.
* Rigidez para actualizar a nuevas tecnologías o plataformas.

[[Category:Glosario de términos]]