{"id":12850,"date":"2023-12-18T17:47:59","date_gmt":"2023-12-18T23:47:59","guid":{"rendered":"https:\/\/www.itrends.com.mx\/?p=12850"},"modified":"2023-12-18T18:06:40","modified_gmt":"2023-12-19T00:06:40","slug":"envejecimiento-del-software","status":"publish","type":"post","link":"https:\/\/www.itrends.com.mx\/en\/envejecimiento-del-software\/","title":{"rendered":"Envejecimiento del Software"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

<\/span>ABSTRACT<\/strong><\/span><\/h2>

Los programas, al igual que las personas, envejecen. No podemos evitar el envejecimiento, pero podemos entender sus causas, tomar medidas para limitar sus efectos, revertir temporalmente algunos de los da\u00f1os que ha causado y prepararnos para el d\u00eda en que el software ya no sea viable. Una se\u00f1al de que la profesi\u00f3n de Ingenier\u00eda de Software ha madurado ser\u00e1 que perdamos nuestra preocupaci\u00f3n por la primera versi\u00f3n y nos centremos en la salud a largo plazo de nuestros productos. Los investigadores y profesionales deben cambiar su percepci\u00f3n de los problemas del desarrollo de software. Solo entonces la Ingenier\u00eda de Software merecer\u00e1 ser llamada Ingenier\u00eda.<\/p>

<\/span>\u00a1Qu\u00e9 tonter\u00eda!<\/strong><\/span><\/h2>

Puedo imaginar f\u00e1cilmente la reacci\u00f3n de algunos cient\u00edficos de la computaci\u00f3n ante el t\u00edtulo de este documento. “El software es un producto matem\u00e1tico; las matem\u00e1ticas no se degradan con el tiempo. Si un teorema era correcto hace 200 a\u00f1os, seguir\u00e1 siendo correcto ma\u00f1ana. Si un programa es correcto hoy, lo ser\u00e1 dentro de 100 a\u00f1os. Si est\u00e1 mal dentro de 100 a\u00f1os, debe haber estado mal cuando se escribi\u00f3. No tiene sentido hablar del envejecimiento del software”.<\/p>

Como muchas afirmaciones de este tipo, la cita imaginada es verdadera pero no realmente relevante. Los productos de software muestran un fen\u00f3meno que se asemeja estrechamente al envejecimiento humano. El software antiguo ha empezado a perjudicar a sus antiguos orgullosos propietarios; muchos productos ahora son vistos como un legado molesto del pasado. Se est\u00e1 destinando un esfuerzo cada vez mayor al soporte de estos productos m\u00e1s antiguos. Al igual que el envejecimiento humano, el envejecimiento del software es Inevitable, pero al igual que el envejecimiento humano, hay cosas que podemos hacer para frenar el proceso y, a veces, incluso revertir sus efectos. El envejecimiento del software no es un fen\u00f3meno nuevo, pero est\u00e1 adquiriendo importancia debido a la creciente relevancia econ\u00f3mica del software y al hecho de que, cada vez m\u00e1s, el software es una parte importante del “capital” de muchas empresas de alta tecnolog\u00eda. Muchos productos de software antiguos se han vuelto piezas esenciales en la maquinaria de nuestra sociedad. El envejecimiento de estos productos est\u00e1 obstaculizando el desarrollo continuo de los sistemas que los incluyen.<\/p>

Los autores y propietarios de nuevos productos de software a menudo miran con desprecio al software envejecido. Creen que, si el producto hubiera sido dise\u00f1ado utilizando las t\u00e9cnicas actuales, no estar\u00eda causando problemas. Tales comentarios me recuerdan a un joven corredor burl\u00e1ndose de un hombre de 86 a\u00f1os (que, desconocido para el corredor, fue un nadador campe\u00f3n hasta los 50) y diciendo que deber\u00eda haber hecho m\u00e1s ejercicio en su juventud.<\/p>

As\u00ed como todos envejeceremos (si tenemos suerte), el envejecimiento del software puede y ocurrir\u00e1 en todos los productos exitosos. Debemos reconocer que suceder\u00e1 con nuestros productos y prepararnos para ello. Cuando llegue la vejez, debemos estar preparados para enfrentarla.<\/p>

El prop\u00f3sito de este documento es explicar c\u00f3mo un producto abstracto y matem\u00e1tico puede envejecer y luego revisar algunos enfoques para lidiar con ello.<\/p>

<\/span>Las causas del envejecimiento del software.<\/span><\/h2>

Existen dos tipos bastante distintos de envejecimiento del software. El primero se debe al fracaso de los propietarios del producto al modificarlo para satisfacer las cambiantes necesidades; el segundo es el resultado de los cambios que se realizan. Este “golpe uno-dos” puede llevar a un r\u00e1pido declive en el valor de un producto de software.<\/p>

<\/span>Falta de movimiento<\/span><\/h3>

En las \u00faltimas tres d\u00e9cadas, nuestras expectativas sobre los productos de software han cambiado enormemente. Recuerdo los d\u00edas en que un programador “parcheaba” un programa almacenado en cinta de papel usando pegamento y papel. Est\u00e1bamos dispuestos a presentar grandes montones de tarjetas y esperar horas o d\u00edas para que el trabajo se compilara y ejecutara. Cuando apareci\u00f3 la programaci\u00f3n interactiva, est\u00e1bamos dispuestos a usar lenguajes de comandos cr\u00edpticos. Hoy en d\u00eda, todos dan por sentado el acceso en l\u00ednea, la respuesta “instant\u00e1nea” y las interfaces basadas en men\u00fas. Esperamos capacidades de comunicaci\u00f3n, almacenamiento masivo en l\u00ednea, etc. El primer producto de software que constru\u00ed (en 1960) har\u00eda su trabajo perfectamente hoy (si pudiera encontrar una computadora Bendix), pero nadie lo usar\u00eda. Ese software ha envejecido incluso aunque nadie lo haya tocado. Aunque los usuarios en la d\u00e9cada de 1960 estaban entusiasmados con el producto, los usuarios de hoy esperan m\u00e1s. Mi antiguo software, en el mejor de los casos, podr\u00eda ser el n\u00facleo de un sistema m\u00e1s conveniente en el mercado actual. A menos que el software se actualice con frecuencia, los usuarios se sentir\u00e1n insatisfechos y cambiar\u00e1n a un nuevo producto tan pronto como los beneficios superen los costos de la capacitaci\u00f3n y la conversi\u00f3n. Se referir\u00e1n a ese software como antiguo y obsoleto.<\/p>

<\/span>Cirug\u00eda ignorante<\/span><\/h3>

Aunque es esencial actualizar el software para prevenir el envejecimiento, cambiar el software puede causar una forma diferente de envejecimiento. El dise\u00f1ador de un software generalmente ten\u00eda un concepto simple en mente al escribir el programa. Si el programa es grande, entender ese concepto permite encontrar las secciones del programa que deben modificarse cuando se necesita una actualizaci\u00f3n o correcci\u00f3n. Comprender ese concepto tambi\u00e9n implica comprender las interfaces utilizadas dentro del sistema y entre el sistema y su entorno. Los cambios realizados por personas que no comprenden el concepto de dise\u00f1o original casi siempre provocan que la estructura del programa se degrade. En esas circunstancias, los cambios ser\u00e1n inconsistentes con el concepto original; de hecho, invalidar\u00e1n el concepto original. A veces, el da\u00f1o es peque\u00f1o, pero a menudo es bastante severo. Despu\u00e9s de esos cambios, se deben conocer tanto las reglas de dise\u00f1o originales como las nuevas excepciones introducidas a las reglas para entender el producto. Despu\u00e9s de muchos cambios de este tipo, los dise\u00f1adores originales ya no comprenden el producto. Aquellos que hicieron los cambios, nunca lo hicieron. En otras palabras, nadie comprende el producto modificado. El software que ha sido modificado repetidamente (mantenido) de esta manera se vuelve muy costoso de actualizar. Los cambios llevan m\u00e1s tiempo y es m\u00e1s probable que introduzcan nuevos “errores”. El envejecimiento inducido por el cambio a menudo se agrava por el hecho de que los encargados sienten que no tienen tiempo para actualizar la documentaci\u00f3n. La documentaci\u00f3n se vuelve cada vez m\u00e1s inexacta, dificultando a\u00fan m\u00e1s los cambios futuros.<\/p>

<\/span>Fallo renal<\/span><\/h3>

Un problema que a menudo se confunde, pero es distinto del envejecimiento del software, es la desaceleraci\u00f3n del sistema causada por la falta de liberaci\u00f3n de memoria asignada. Los archivos pueden crecer y requerir poda. A veces, una rutina de asignaci\u00f3n de memoria puede no liberar todo el espacio que se ha asignado. Lentamente, se disminuyen el espacio de intercambio y el espacio de archivo y el rendimiento se degrada. Este problema a menudo es una falla de dise\u00f1o cong\u00e9nita y puede ocurrir a cualquier edad; pero tambi\u00e9n puede ser el resultado de una cirug\u00eda ignorante o agravarse por patrones de uso cambiantes. Sin embargo, se cura m\u00e1s f\u00e1cilmente que el “envejecimiento” que es el tema de este documento. Un proceso tipo di\u00e1lisis puede intervenir y limpiar el sistema de archivos y la memoria, rutinas mejoradas pueden hacer que la limpieza ocurra r\u00e1pidamente y el software puede considerarse completamente “curado”.<\/p>

<\/span>Los costos del envejecimiento del software<\/span><\/h3>

Los s\u00edntomas del envejecimiento del software reflejan los del envejecimiento humano: (1) los propietarios de software envejecido encuentran cada vez m\u00e1s dif\u00edcil mantenerse al d\u00eda con el mercado y pierden clientes frente a productos m\u00e1s nuevos, (2) el software envejecido a menudo se degrada en su rendimiento espacio\/temporal como resultado de una estructura que se deteriora gradualmente, (3) el software envejecido a menudo se vuelve “defectuoso” debido a errores introducidos cuando se realizan cambios. Cada uno de estos resultados tiene costos reales para el propietario.<\/p>

<\/span>Incapacidad para mantenerse al d\u00eda<\/span><\/h3>

A medida que el software envejece, crece en tama\u00f1o. Este “aumento de peso” es el resultado de que la forma m\u00e1s f\u00e1cil de agregar una funci\u00f3n es agregar nuevo c\u00f3digo. Modificar el c\u00f3digo existente para manejar nuevas situaciones a menudo es dif\u00edcil porque ese c\u00f3digo no es ni bien comprendido ni bien documentado. A medida que el tama\u00f1o de un programa aumenta, a veces en uno o dos \u00f3rdenes de magnitud durante varios a\u00f1os, los cambios se vuelven m\u00e1s dif\u00edciles de varias maneras. En primer lugar, hay m\u00e1s c\u00f3digo para cambiar; un cambio que podr\u00eda haberse hecho en una o dos partes del programa original ahora requiere modificar muchas secciones del c\u00f3digo. En segundo lugar, es m\u00e1s dif\u00edcil encontrar las rutinas que deben cambiarse. Como resultado, los propietarios no pueden agregar nuevas funciones lo suficientemente r\u00e1pido. Los clientes pueden cambiar a un producto m\u00e1s joven para obtener esas caracter\u00edsticas. La empresa experimenta una notable disminuci\u00f3n en los ingresos; cuando lanzan una nueva versi\u00f3n, suscita inter\u00e9s en una base de clientes cada vez m\u00e1s reducida. Si intentan mantenerse al d\u00eda con el mercado aumentando su fuerza laboral, los costos adicionales de los cambios y las demoras conducen a una mayor p\u00e9rdida de clientes.<\/p>

<\/span>Reducci\u00f3n de rendimiento<\/span><\/h3>

A medida que el tama\u00f1o del programa crece, exige m\u00e1s memoria de la computadora y hay m\u00e1s demoras mientras el c\u00f3digo debe intercambiarse desde el almacenamiento masivo. El programa responde m\u00e1s lentamente; los clientes deben actualizar sus computadoras para obtener una respuesta aceptable. La eficiencia tambi\u00e9n disminuye debido a un dise\u00f1o deficiente. El software ya no se comprende bien y los cambios pueden afectar negativamente el rendimiento. Un producto m\u00e1s joven, cuyo dise\u00f1o original reflejaba la necesidad de caracter\u00edsticas recientemente introducidas, funcionar\u00e1 m\u00e1s r\u00e1pido o usar\u00e1 menos memoria.<\/p>

<\/span>Disminuci\u00f3n de la confiabilidad<\/span><\/h3>

A medida que se mantiene el software, se introducen errores. Incluso en los primeros a\u00f1os de la industria, los observadores pudieron documentar situaciones en las que cada error corregido introduc\u00eda (en promedio) m\u00e1s de un error. Cada vez que se intentaba disminuir la tasa de fallos de los sistemas, empeoraba. A menudo, la \u00fanica opci\u00f3n era abandonar el producto o al menos dejar de reparar errores. Me han contado sobre productos de software m\u00e1s antiguos en los que la lista de errores conocidos pero a\u00fan no reparados superaba las 2000 entradas.<\/p>

<\/span>Reducci\u00f3n de los costos del envejecimiento del software<\/span><\/h3>

Los programadores inexpertos a menudo pueden ser reconocidos por la alegr\u00eda que muestran la primera vez que obtienen resultados correctos de un programa. “\u00a1He terminado; \u00a1funciona!” es el grito de un nuevo programador que acaba de tener una exitosa primera demostraci\u00f3n. El programador experimentado se da cuenta de que esto es solo el comienzo. Saben que cualquier producto serio requiere pruebas extensas, revisi\u00f3n y revisi\u00f3n despu\u00e9s de la primera ejecuci\u00f3n exitosa. El trabajo invertido por organizaciones responsables y profesionales despu\u00e9s de la primera ejecuci\u00f3n exitosa y antes del primer lanzamiento suele ser mucho mayor que el necesario para obtener la primera ejecuci\u00f3n exitosa. Sin embargo, incluso los programadores experimentados se centran en ese primer lanzamiento. Nuestra experiencia con el envejecimiento del software nos dice que debemos mirar mucho m\u00e1s all\u00e1 del primer lanzamiento hasta el momento en que el producto sea antiguo.<\/p>

Demasiados documentos en conferencias de ingenier\u00eda de software se centran en los problemas para llegar al primer lanzamiento. Demasiados documentos se centran en los problemas de gesti\u00f3n (por ejemplo, gesti\u00f3n y control de configuraciones). Lidiar con el envejecimiento del software requiere m\u00e1s que “gesti\u00f3n paciente”; requiere una ingenier\u00eda s\u00f3lida. El prop\u00f3sito del resto de este documento es considerar qu\u00e9 acciones podr\u00edamos tomar para reducir los costos asociados con el envejecimiento del software.<\/p>

<\/span>Medicina preventiva<\/span><\/h2>

Dado que el envejecimiento del software es un problema tan serio, la primera pregunta que debemos hacernos es qu\u00e9 podemos hacer para retrasar el deterioro y limitar sus efectos.<\/p>

<\/span>Dise\u00f1o para el \u00e9xito<\/span><\/h3>

El primer paso para controlar el envejecimiento del software es aplicar el antiguo lema “dise\u00f1ar para el cambio”. Desde principios de los a\u00f1os 70, sabemos c\u00f3mo dise\u00f1ar software para el cambio. El principio a aplicar se conoce con varios nombres, como “ocultamiento de informaci\u00f3n”, “abstracci\u00f3n”, “separaci\u00f3n de preocupaciones”, “ocultamiento de datos” o, m\u00e1s recientemente, “orientaci\u00f3n a objetos”. Para aplicar este principio, se comienza por tratar de caracterizar los cambios que es probable que ocurran a lo largo de la “vida \u00fatil” del producto. Dado que no podemos prever los cambios reales, las predicciones ser\u00e1n sobre clases de cambios, por ejemplo, representaci\u00f3n de expresiones revisada, reemplazo del terminal por un nuevo tipo, cambios en la interfaz de usuario, cambio a un nuevo sistema de ventanas, etc. Dado que es imposible hacer que todo sea igualmente f\u00e1cil de cambiar, es importante estimar las probabilidades de cada tipo de cambio. Luego, se organiza el software de manera que los elementos m\u00e1s propensos a cambiar est\u00e1n “confinados” a una peque\u00f1a cantidad de c\u00f3digo, de modo que si esas cosas cambian, solo se ver\u00eda afectada una peque\u00f1a cantidad de c\u00f3digo. A pesar de la simplicidad de este principio y a pesar de su amplia aceptaci\u00f3n, no veo mucho software que est\u00e9 bien dise\u00f1ado desde este punto de vista. Vale la pena examinar algunas de las razones por las cuales la industria no aplica este principio correctamente.<\/p>

Muchos manuales de software mencionan esta t\u00e9cnica, pero la cubren de manera superficial. Dicen que uno deber\u00eda ocultar o abstraer los “detalles de implementaci\u00f3n”, pero no discuten ni ilustran el proceso de estimar la probabilidad de cambio para diversas clases de cambios. El principio es simple; aplicarlo correctamente requiere mucho pensamiento sobre la aplicaci\u00f3n y el entorno. Los libros de texto no dejan eso claro.<\/p>

Muchos programadores son impacientes con tales consideraciones; est\u00e1n tan ansiosos por hacer funcionar la primera versi\u00f3n o cumplir con alg\u00fan plazo inminente que no se toman el tiempo para dise\u00f1ar pensando en el cambio. La gesti\u00f3n est\u00e1 tan preocupada por el pr\u00f3ximo plazo (y tan ansiosa por ascender) que los costos futuros de mantenimiento no tienen la m\u00e1xima prioridad.<\/p>

Los dise\u00f1os que resultan de una aplicaci\u00f3n cuidadosa del ocultamiento de informaci\u00f3n son bastante diferentes de los dise\u00f1os “naturales” que resultan del trabajo intuitivo de la mayor\u00eda de los programadores. La intuici\u00f3n del programador es pensar en pasos en el procesamiento de datos, no en cambios probables. Incluso cuando se les dice que asocien cada m\u00f3dulo con un “secreto”, algo que es probable que cambie y que deber\u00eda encapsularse, usan “secretos” del tipo “c\u00f3mo…”. Los dise\u00f1adores tienden a imitar otros dise\u00f1os que han visto. No ven muchas aplicaciones efectivas del ocultamiento de informaci\u00f3n. Un ejemplo de dise\u00f1o basado en el ocultamiento de informaci\u00f3n se encuentra en [9].<\/p>

Los programadores tienden a confundir principios de dise\u00f1o con lenguajes. Por ejemplo, creen que no se pueden aplicar ideas “orientadas a objetos” sin un lenguaje “orientado a objetos”. Peor a\u00fan, piensan que han aplicado las t\u00e9cnicas si han utilizado ese lenguaje.<\/p>

Muchas personas que se dedican al desarrollo de software no tienen una educaci\u00f3n adecuada para el trabajo. Temas que son “pan comido” para aquellos que asisten a esta conferencia son desconocidos o t\u00e9rminos vagos para muchos que escriben software. Cada industria tiene sus propias conferencias de software y muchos programadores en cada industria trabajan como si sus problemas fueran \u00fanicos.<\/p>

Los investigadores en Ingenier\u00eda de Software contin\u00faan predicando a los convertidos, escribiendo papers entre ellos y ignorando lo que est\u00e1 sucediendo donde se escribe la mayor\u00eda del software. Asumen que “dise\u00f1ar para el cambio” es un problema antiguo, no uno que requiera m\u00e1s trabajo. \u00a1Est\u00e1n equivocados!<\/p>

Aunque el principio del ocultamiento de informaci\u00f3n se enunci\u00f3 por primera vez a principios de los a\u00f1os 70 (e incluso se ilustr\u00f3 antes), es raro encontrar un producto de software que haya sido dise\u00f1ado correctamente desde este punto de vista. El c\u00f3digo a menudo es ingenioso, eficiente y correcto; realiza funciones bastante asombrosas, pero rara vez se dise\u00f1a para cambiar f\u00e1cilmente. El problema no es que nadie sepa c\u00f3mo hacerlo, sino que la mayor\u00eda de los programadores no lo hacen. Sospecho que algunos programadores piensan que su programa ser\u00e1 tan bueno que no tendr\u00e1 que cambiarse. Esto es absurdo. Los \u00fanicos programas que no se cambian son aquellos tan malos que nadie quiere usarlos. Dise\u00f1ar para el cambio es dise\u00f1ar para el \u00e9xito.<\/p>

<\/span>Mantener registros – documentaci\u00f3n<\/span><\/h3>

Incluso cuando el c\u00f3digo est\u00e1 dise\u00f1ado de manera que los cambios se pueden llevar a cabo eficientemente, los principios de dise\u00f1o y las decisiones de dise\u00f1o a menudo no se registran de una forma \u00fatil para los futuros mantenedores. La documentaci\u00f3n es el aspecto de la ingenier\u00eda de software m\u00e1s descuidado tanto por los investigadores acad\u00e9micos como por los profesionales. Es com\u00fan escuchar a un programador decir que el c\u00f3digo es su propia documentaci\u00f3n; incluso investigadores de lenguajes altamente respetados sostienen esta posici\u00f3n, argumentando que si se utiliza su \u00faltimo lenguaje, la estructura ser\u00e1 expl\u00edcita y obvia.<\/p>

Cuando se escribe documentaci\u00f3n, suele estar mal organizada, incompleta e imprecisa. A menudo, la cobertura es aleatoria; un programador o gerente decide que una idea en particular es ingeniosa y escribe un memo al respecto, mientras que otros temas igualmente importantes son ignorados. En otras situaciones, donde la documentaci\u00f3n es un requisito contractual, se contrata a un redactor t\u00e9cnico, que no comprende el sistema, para escribir la documentaci\u00f3n. La documentaci\u00f3n resultante es ignorada por los programadores de mantenimiento porque no es precisa. Algunos proyectos mantienen dos juegos de libros; est\u00e1 la documentaci\u00f3n oficial, escrita seg\u00fan lo requerido por el contrato, y la documentaci\u00f3n real, escrita informalmente cuando surgen problemas espec\u00edficos.<\/p>

La documentaci\u00f3n que parece clara y adecuada para sus autores a menudo es tan clara como el barro para el programador que debe mantener el c\u00f3digo 6 meses o 6 a\u00f1os despu\u00e9s. Incluso cuando la informaci\u00f3n est\u00e1 presente, el programador de mantenimiento no sabe d\u00f3nde buscarla. Es casi tan com\u00fan encontrar que el mismo tema se cubre dos veces, pero que las declaraciones en la documentaci\u00f3n son inconsistentes entre s\u00ed y con el c\u00f3digo.<\/p>

La documentaci\u00f3n no es un tema de investigaci\u00f3n “atractivo”. El a\u00f1o pasado, suger\u00ed a un l\u00edder de un proyecto de Esprit que estaba buscando un tema para una conferencia, que se centrara en la documentaci\u00f3n. Su respuesta fue que no ser\u00eda interesante. Objet\u00e9, diciendo que hay muchos aspectos interesantes en este tema. Su respuesta fue que el problema no era que la discusi\u00f3n no fuera interesante, sino que el tema no sonar\u00eda interesante y no atraer\u00eda a la audiencia.<\/p>

Durante los \u00faltimos cinco o seis a\u00f1os, mi propia investigaci\u00f3n y la de muchos de mis estudiantes y colegas cercanos se ha centrado en los problemas de la documentaci\u00f3n. Hemos demostrado c\u00f3mo los m\u00e9todos matem\u00e1ticos pueden usarse para proporcionar documentaci\u00f3n clara, concisa y sistem\u00e1tica del dise\u00f1o del programa [3,4]. Hemos inventado e ilustrado nuevas notaciones matem\u00e1ticas que son mucho m\u00e1s adecuadas para su uso en documentaci\u00f3n, pero no menos formales [5,6,7]. La reacci\u00f3n de acad\u00e9micos y profesionales a este trabajo ha sido provocadora de reflexiones. Ambos lados no reconocen la documentaci\u00f3n como el tema de nuestro trabajo. Los acad\u00e9micos siguen se\u00f1alando que estamos descuidando “obligaciones de prueba”; los revisores industriales clasifican nuestro trabajo como “verificaci\u00f3n”, que consideran (a menudo correctamente) demasiado dif\u00edcil y te\u00f3rico. Ning\u00fan grupo puede ver la documentaci\u00f3n como un tema m\u00e1s f\u00e1cil y, en cierto sentido, m\u00e1s importante que la verificaci\u00f3n. Para ellos, la documentaci\u00f3n es ese “blah blah” que hay que escribir. De hecho, a menos que podamos resolver el problema de la documentaci\u00f3n, el trabajo de verificaci\u00f3n ser\u00e1 una p\u00e9rdida de tiempo.<\/p>

Al hablar con personas que desarrollan software comercial, encontramos que la documentaci\u00f3n se descuida porque no acelerar\u00e1 el pr\u00f3ximo lanzamiento. Nuevamente, programadores y gerentes est\u00e1n tan impulsados por el plazo m\u00e1s inminente que no pueden planificar para la vejez del software. Si reconocemos que el envejecimiento del software es inevitable y costoso, que el primer o pr\u00f3ximo lanzamiento del programa no es el final de su desarrollo, que los costos a largo plazo superar\u00e1n las ganancias a corto plazo, comenzaremos a tomar la documentaci\u00f3n m\u00e1s en serio.<\/p>

Cuando comenzamos a tomarnos en serio la documentaci\u00f3n, veremos que, al igual que en otros tipos de ingenier\u00eda, la documentaci\u00f3n de software debe basarse en matem\u00e1ticas. Cada documento ser\u00e1 una representaci\u00f3n de una o m\u00e1s relaciones matem\u00e1ticas. La \u00fanica forma pr\u00e1ctica de registrar la informaci\u00f3n necesaria en una documentaci\u00f3n adecuada ser\u00e1 mediante el uso de notaci\u00f3n formalmente definida.<\/p>

<\/span>Segundas opiniones – revisiones<\/span><\/h3>

En ingenier\u00eda, al igual que en medicina, la necesidad de revisiones por parte de otros profesionales nunca se cuestiona. En el dise\u00f1o de un edificio, un barco o una aeronave, siempre hay una serie de documentos de dise\u00f1o cada vez m\u00e1s precisos y cada uno es revisado cuidadosamente por otros. Aunque el tema de las revisiones de dise\u00f1o se discute ampliamente en las conferencias de ingenier\u00eda de software, es sorprendente ver cu\u00e1ntas veces se producen programas comerciales sin una revisi\u00f3n adecuada. Hay muchas razones para esto:<\/p>

Muchos programadores no tienen formaci\u00f3n profesional en software en absoluto. Algunos son ingenieros de otros campos, algunos son “cient\u00edficos ca\u00eddos” que aprendieron programaci\u00f3n incidentalmente mientras obten\u00edan su educaci\u00f3n. Algunos eran matem\u00e1ticos y otros proven\u00edan de antecedentes no t\u00e9cnicos. En muchas de esas \u00e1reas, el concepto de preparar y llevar a cabo una revisi\u00f3n de dise\u00f1o no existe.<\/p>

Incluso entre aquellos que tienen t\u00edtulos en Ciencias de la Computaci\u00f3n, han tenido una educaci\u00f3n que ha descuidado preocupaciones profesionales como la necesidad de documentaci\u00f3n y revisiones de dise\u00f1o. El \u00e9nfasis est\u00e1 en las matem\u00e1ticas y la ciencia; la disciplina profesional no es un tema para una educaci\u00f3n “liberal”.<\/p>

La mayor\u00eda de los profesionales (y muchos investigadores) no saben c\u00f3mo proporcionar documentaci\u00f3n precisa y legible de un dise\u00f1o, distinta de una implementaci\u00f3n. No hay una descripci\u00f3n precisa, aparte del c\u00f3digo detallado, disponible para su revisi\u00f3n. Las revisiones de dise\u00f1o al principio de un proyecto, cuando ser\u00edan m\u00e1s \u00fatiles, se reducen a sesiones de charla porque no hay documentos de dise\u00f1o detallados para discutir.<\/p>

Gran parte del software se produce como una industria casera, donde no hay personas que puedan servir como revisores calificados y no hay financiamiento para contratar revisores externos.<\/p>

Con frecuencia, el software se produce bajo presi\u00f3n de tiempo que enga\u00f1a a los dise\u00f1adores haci\u00e9ndoles pensar que no tienen tiempo para revisiones adecuadas.<\/p>

Muchos programadores consideran la programaci\u00f3n como un “arte” y se molestan con la idea de que alguien podr\u00eda o deber\u00eda revisar el trabajo que han hecho. He conocido a programadores que dejan de trabajar porque se molestan por el hecho de que su trabajo estar\u00eda sujeto a revisi\u00f3n.<\/p>

Para cualquier organizaci\u00f3n que tenga la intenci\u00f3n de mantener sus productos de software durante varios a\u00f1os, las revisiones son esenciales y deben tomarse m\u00e1s en serio de lo que es com\u00fan ahora. En particular, para mitigar los problemas del envejecimiento del software, cada dise\u00f1o debe ser revisado y aprobado por alguien cuyas responsabilidades sean para el futuro a largo plazo del producto. Las revisiones realizadas por personas preocupadas por el mantenimiento deben llevarse a cabo cuando se propone el dise\u00f1o y mucho antes de que exista c\u00f3digo. Puedes encontrar una discusi\u00f3n sobre c\u00f3mo revisar documentos de dise\u00f1o en [2].<\/p>

<\/span>Por qu\u00e9 el envejecimiento del software es inevitable<\/span><\/h3>

Incluso si tomamos todas las medidas preventivas razonables y lo hacemos de manera religiosa, el envejecimiento es inevitable. Nuestra capacidad para dise\u00f1ar para el cambio depende de nuestra capacidad para predecir el futuro. Solo podemos hacerlo aproximadamente y de manera imperfecta. A lo largo de los a\u00f1os, realizaremos cambios que violan nuestras suposiciones originales. La documentaci\u00f3n, incluso si es formal y precisa, nunca ser\u00e1 perfecta. Las revisiones sacar\u00e1n a la luz problemas que los dise\u00f1adores pasan por alto, pero tambi\u00e9n hay problemas que los revisores pasan por alto. Las medidas preventivas valen la pena, pero cualquiera que piense que esto eliminar\u00e1 el envejecimiento est\u00e1 viviendo en un mundo de fantas\u00eda.<\/p>

<\/span>Geriatr\u00eda del software<\/span><\/h2>

La prevenci\u00f3n siempre es la mejor medicina, pero a\u00fan tenemos que lidiar con el software antiguo. Esta secci\u00f3n describe varias cosas que se pueden hacer para tratar el envejecimiento del software que ya ha ocurrido.<\/p>

<\/span>Detener el deterioro<\/span><\/h3>

Si el software ha sido mantenido durante alg\u00fan tiempo sin mucha atenci\u00f3n a los problemas planteados aqu\u00ed, se observar\u00e1 un marcado deterioro. El primer paso deber\u00eda ser ralentizar el progreso del deterioro. Esto se logra introduciendo o recreando estructura cada vez que se realizan cambios. Los principios de dise\u00f1o mencionados anteriormente pueden usarse para guiar el cambio y el mantenimiento tambi\u00e9n. Si se cambia una decisi\u00f3n de dise\u00f1o sobre el sistema, la nueva estructura de datos o algoritmo puede ocultarse (encapsularse) de manera que facilite cualquier cambio futuro en ese aspecto del sistema. Revisiones cuidadosas deben asegurar que cada cambio sea consistente con la intenci\u00f3n de los dise\u00f1adores originales, que el concepto de dise\u00f1o original no sea violado por los nuevos cambios.<\/p>

Detener el deterioro es, como muchas otras cosas en Ingenier\u00eda de Software, m\u00e1s f\u00e1cil de decir que de hacer. Muchas empresas han permitido que el crecimiento canceroso contin\u00fae sin control en su software durante a\u00f1os. Cuando las cosas van bien, el crecimiento es r\u00e1pido y no hay una raz\u00f3n evidente para ser cauteloso. El resultado es que un solo proyecto puede existir en muchas versiones, cada una con estructuras ligeramente diferentes y basadas en suposiciones ligeramente diferentes. Cuando el per\u00edodo de r\u00e1pido crecimiento ha terminado, cada cambio debe hacerse muchas veces y los mantenedores se confunden por la profusi\u00f3n de versiones casi iguales. Alguien tiene que realizar un estudio serio de todas esas versiones y registrar las diferencias. Luego, un equipo tendr\u00e1 que ponerse de acuerdo sobre la estructura adecuada y todas las versiones tendr\u00e1n que ajustarse a ese molde. En un momento en que las cosas no van bien, es dif\u00edcil obtener suficiente personal para hacer el trabajo adecuadamente. Deben crearse y revisarse nuevos documentos. Luego, el c\u00f3digo debe verificarse para asegurarse de que se haya vuelto consistente con estos nuevos documentos. Un proceso as\u00ed podr\u00eda llevar varios a\u00f1os y durante ese tiempo seguir\u00e1n llegando demandas de cambios y correcciones. Cortar el crecimiento desde el principio es mucho m\u00e1s preferible. La retirada siempre es dolorosa.<\/p>

<\/span>Documentaci\u00f3n retrospectiva<\/span><\/h3>

Un paso importante para frenar el envejecimiento del software m\u00e1s antiguo, y a menudo rejuvenecerlo, es mejorar la calidad de la documentaci\u00f3n. A menudo, la documentaci\u00f3n es descuidada por los programadores de mantenimiento debido a su prisa por corregir problemas informados por los clientes o para introducir caracter\u00edsticas demandadas por el mercado. Cuando documentan su trabajo, a menudo lo hacen mediante un memorando que no est\u00e1 integrado en la documentaci\u00f3n existente, sino que simplemente se agrega a ella. Si el software es realmente valioso, la documentaci\u00f3n no estructurada resultante puede, y deber\u00eda, ser reemplazada por una documentaci\u00f3n cuidadosamente estructurada que haya sido revisada para ser completa y correcta. A menudo, cuando se sugiere tal proyecto, los programadores (que rara vez est\u00e1n entusiasmados con cualquier forma de documentaci\u00f3n) ridiculizan la sugerencia como impr\u00e1ctica. Sus intereses son a corto plazo y su satisfacci\u00f3n laboral proviene de ejecutar programas. No obstante, hay situaciones en las que es de inter\u00e9s del propietario insistir en que el producto est\u00e9 documentado en una forma que pueda servir como referencia para futuros programadores de mantenimiento.<\/p>

Un efecto secundario agradable de los esfuerzos de documentaci\u00f3n es a menudo la mejora del software. La documentaci\u00f3n formal que recomendamos requiere un examen detallado y sistem\u00e1tico del c\u00f3digo y a menudo revela errores, funciones duplicadas o casi id\u00e9nticas y formas de mejorar el rendimiento. En un experimento reciente, le ped\u00ed a un estudiante de pregrado que produjera documentaci\u00f3n para un software que ya no funcionaba. El autor hab\u00eda dejado nuestro pa\u00eds. Aunque no se le pidi\u00f3 que encontrara errores, el an\u00e1lisis sistem\u00e1tico necesario para crear la documentaci\u00f3n formal lo oblig\u00f3 a examinar cada rutina cuidadosamente. Suger\u00eda algunos cambios y ahora el software es funcional, adem\u00e1s de estar bien documentado para cambios futuros.<\/p>

<\/span>Modularizaci\u00f3n incremental retrospectiva<\/span><\/h3>

Aunque todos los expertos en software ahora admiten la importancia de la modularizaci\u00f3n y la mayor\u00eda de los programas grandes tienen algunas unidades consideradas m\u00f3dulos, una buena comprensi\u00f3n de los principios de la modularizaci\u00f3n rara vez se refleja en el c\u00f3digo. La modularizaci\u00f3n requiere m\u00e1s que simplemente identificar subrutinas o peque\u00f1os grupos de procedimientos y llamarlos m\u00f3dulos. Cada m\u00f3dulo debe comprender todos los programas “conocen” (est\u00e1n basadas en) una decisi\u00f3n de dise\u00f1o particular que es probable que cambie. Reconocer cosas que probablemente cambiar\u00e1n requiere experiencia, y ocultar o confinar con \u00e9xito el conocimiento de una decisi\u00f3n de dise\u00f1o a un m\u00f3dulo requiere habilidades y comprensi\u00f3n que son raras. A\u00fan as\u00ed, los programadores que comprenden el ocultamiento de informaci\u00f3n y la abstracci\u00f3n generalmente pueden encontrar segmentos de c\u00f3digo que deber\u00edan ser m\u00f3dulos y recopilarlos en unidades. Un consultor, que ve el software con ojos frescos, a menudo puede mostrar c\u00f3mo se realiza el trabajo. Hacerlo facilita en gran medida el mantenimiento futuro del c\u00f3digo. A menudo, estas mejoras se pueden hacer a un costo m\u00ednimo como un efecto secundario de los cambios que deben hacerse de todos modos.<\/p>

<\/span>Amputaci\u00f3n<\/span><\/h3>

Ocasionalmente, una secci\u00f3n de c\u00f3digo ha sido modificada tantas veces y de manera tan descuidada que no vale la pena guardarla. Grandes secciones pueden descartarse y reemplazarse por “mu\u00f1ones” artificiales que realizan la funci\u00f3n de alguna otra manera. La amputaci\u00f3n siempre es una decisi\u00f3n dif\u00edcil y controvertida. Aquellos que han creado el c\u00f3digo antiguo no est\u00e1n dispuestos a admitir que no vale la pena conservarlo. Nuevamente, los consultores suelen ser \u00fatiles si se les puede informar completamente. No tienen el apego emocional al c\u00f3digo que los autores podr\u00edan tener.<\/p>

<\/span>Cirug\u00eda mayor: reestructuraci\u00f3n<\/span><\/h3>

Cuando una familia grande e importante de productos se sale de control, es apropiado realizar un esfuerzo importante para reestructurarla. El primer paso debe ser reducir el tama\u00f1o de la familia de programas. Se deben examinar las diversas versiones para determinar por qu\u00e9 y c\u00f3mo difieren. Si se pueden introducir m\u00f3dulos que oculten esas diferencias, acordar (y documentar) interfaces est\u00e1ndar para esos m\u00f3dulos y luego realizar esos cambios en las diversas versiones, se pueden colapsar las versiones en un solo sistema que difiera solo en algunos m\u00f3dulos. Reemplazar las versiones antiguas con las reestructuradas permite que los cambios futuros en el c\u00f3digo compartido sean compartidos por muchas versiones. En muchas situaciones, las versiones separadas pueden combinarse en una sola mediante la introducci\u00f3n de “interruptores” que se verifican en tiempo de ejecuci\u00f3n para determinar qu\u00e9 versi\u00f3n de comportamiento se desea. Esto introduce una peque\u00f1a ineficiencia en tiempo de ejecuci\u00f3n pero reduce en gran medida el tama\u00f1o del personal de mantenimiento. He visto algunas organizaciones que pudieron ofrecer lo que parec\u00eda ser una amplia familia de productos distribuyendo un solo fragmento de c\u00f3digo y configurando interruptores ocultos para crear sistemas que parec\u00edan bastante diferentes. Los costos de mantenimiento de estas organizaciones son mucho m\u00e1s bajos de lo que ser\u00edan si tuvieran versiones separadas. Lamentablemente, algunos de sus clientes encontraron los interruptores y pudieron disfrutar de los beneficios de funciones que no hab\u00edan comprado. A pesar de esto, sospecho que el fabricante de software estaba adelante debido a los costos reducidos de mantenimiento.<\/p>

<\/span>Planificaci\u00f3n anticipada<\/span><\/h2>

Si queremos prevenir, o al menos frenar, el envejecimiento del software, debemos reconocerlo como un problema y planificar para ello. Cuanto antes planifiquemos para la vejez, m\u00e1s podremos hacer.<\/p>

<\/span>Un nuevo “Estilo de vida”<\/span><\/h3>

Es hora de dejar de actuar como si “hacer que funcione” fuera lo \u00fanico que importa. Obviamente, es importante llevar un producto al cliente r\u00e1pidamente, pero no podemos seguir actuando como si no hubiera un ma\u00f1ana. No debemos permitir que las presiones de hoy resulten en un producto (y empresa) mutilado el pr\u00f3ximo a\u00f1o. No podemos hacer un buen trabajo bajo estr\u00e9s, especialmente el estr\u00e9s constante de una crisis de 25 a\u00f1os. La industria misma debe tomar medidas para frenar el r\u00e1pido ritmo de desarrollo. Esto se puede lograr imponiendo est\u00e1ndares en la estructura y la documentaci\u00f3n, asegur\u00e1ndose de que los productos producidos utilizando “atajos” no lleven el “sello de calidad” de la industria.<\/p>

<\/span>Planificaci\u00f3n para el cambio<\/span><\/h3>

Los dise\u00f1os deben documentarse y revisarse cuidadosamente antes de que comience la codificaci\u00f3n. Los programas deben documentarse y revisarse. Los cambios deben documentarse y revisarse. Un an\u00e1lisis exhaustivo de los cambios futuros debe ser parte de cada dise\u00f1o de producto y acci\u00f3n de mantenimiento. Las organizaciones que son m\u00e1s grandes que unas pocas personas deber\u00edan tener un profesional o un departamento dedicado a revisar los dise\u00f1os para la capacidad de cambio. Deber\u00edan tener el poder de vetar cambios que hagan que las cosas se hagan m\u00e1s r\u00e1pido ahora pero a un gran costo m\u00e1s tarde.<\/p>

<\/span>Si no est\u00e1 documentado, no est\u00e1 hecho<\/span><\/h3>

Si un producto no est\u00e1 documentado seg\u00fan su dise\u00f1o, utilizando la documentaci\u00f3n como un medio de dise\u00f1o [1], ahorraremos un poco hoy, pero pagaremos mucho m\u00e1s en el futuro. Es mucho m\u00e1s dif\u00edcil recrear la documentaci\u00f3n de dise\u00f1o que crearla a medida que avanzamos. La documentaci\u00f3n que se ha creado despu\u00e9s de que se haya completado el dise\u00f1o y se haya enviado el producto generalmente no es muy precisa. Adem\u00e1s, dicha documentaci\u00f3n no estaba disponible cuando (y si) se revis\u00f3 el dise\u00f1o antes de la codificaci\u00f3n. Como resultado, incluso si la documentaci\u00f3n es tan buena como lo habr\u00eda sido, ha costado m\u00e1s y ha sido menos valiosa.<\/p>

Ingenieros el\u00e9ctricos, el software en el campo de la fabricaci\u00f3n automatizada es escrito por ingenieros mec\u00e1nicos, etc. Los ingenieros de programaci\u00f3n en esas industrias no se consideran a s\u00ed mismos como profesionales en el sentido en que lo hacen los ingenieros aeron\u00e1uticos o nucleares. Adem\u00e1s, no han recibido una educaci\u00f3n formal en el campo en el que ahora trabajan. Descubrimos que los ingenieros que escriben programas saben muy poco sobre la ciencia de la computaci\u00f3n, pero los graduados en ciencias de la computaci\u00f3n saben muy poco sobre los procedimientos y disciplinas de ingenier\u00eda. A menudo escucho: “cualquiera puede escribir un programa” y es cierto, pero los programas escritos de manera no profesional envejecer\u00e1n mucho m\u00e1s r\u00e1pidamente que los programas escritos por ingenieros que han recibido educaci\u00f3n en las matem\u00e1ticas y t\u00e9cnicas importantes para el dise\u00f1o de programas, [8].<\/p>

<\/span>Planes de ahorro para la jubilaci\u00f3n<\/span><\/h3>

En otras \u00e1reas de la ingenier\u00eda, se reconoce la obsolescencia del producto y se incluye en los planes de dise\u00f1o y marketing. El autom\u00f3vil nuevo que compras hoy ya es “antiguo” para los ingenieros que ya est\u00e1n trabajando en modelos futuros. El autom\u00f3vil tiene garant\u00eda solo por un tiempo (muy) limitado y las piezas de repuesto tambi\u00e9n deben estar disponibles solo durante per\u00edodos establecidos. Cuando compramos un autom\u00f3vil, sabemos que envejecer\u00e1 y eventualmente tendr\u00e1 que ser reemplazado. Si somos sabios, comenzamos a planificar ese reemplazo tanto financieramente como leyendo sobre nuevos desarrollos. Los fabricantes muestran una previsi\u00f3n similar. Solo en la industria del software, la gente trabaja como si su producto “viviera” para siempre. Cada dise\u00f1ador y comprador de software deber\u00eda estar planeando el d\u00eda en que el producto deba ser reemplazado. Una parte de esta planificaci\u00f3n es la planificaci\u00f3n financiera, asegur\u00e1ndose de que cuando llegue el momento de instalar o desarrollar un nuevo producto, los fondos y las personas est\u00e9n disponibles.<\/p>

<\/span>Barreras para el progreso<\/span><\/h2>

Si vamos a mejorar el problema del envejecimiento del software, tendremos que hacer algunos cambios profundos en nuestra profesi\u00f3n. Hay cuatro barreras b\u00e1sicas para el progreso en Ingenier\u00eda de Software. Estas son actitudes y suposiciones que hacen imposible que la investigaci\u00f3n marque la diferencia.<\/p>

<\/span>\u00bfUna crisis de 25 a\u00f1os?<\/span><\/h3>

Escuch\u00e9 por primera vez el t\u00e9rmino “crisis del software” hace 25 a\u00f1os y lo he escuchado usar para describir un problema actual todos los a\u00f1os desde entonces. Esto es claramente absurdo. Una crisis es una emergencia seria, repentina y a corto plazo. La llamada “crisis del software” ciertamente es seria, pero no es ni repentina ni a corto plazo. No puede tratarse como si fuera una emergencia repentina: necesita una terapia cuidadosa a largo plazo. Las soluciones “r\u00e1pidas y f\u00e1ciles” nunca han funcionado y no funcionar\u00e1n en el futuro. La frase “crisis del software” ayuda a tratar con ciertas agencias de financiamiento, pero impide el an\u00e1lisis profundo necesario para curar una enfermedad cr\u00f3nica. Conduce a un pensamiento a corto plazo y a un envejecimiento r\u00e1pido del software.<\/p>

<\/span>“Nuestra industria es diferente.”<\/span><\/h3>

El software se utiliza en casi todas las industrias, como la aeron\u00e1utica, militar, automotriz, energ\u00eda nuclear y telecomunicaciones. Cada una de estas industrias se desarroll\u00f3 como una comunidad intelectual antes de depender del software. Cada una tiene sus propias organizaciones profesionales, organizaciones comerciales, sociedades t\u00e9cnicas y revistas t\u00e9cnicas. Como resultado, encontramos que muchas de estas industrias est\u00e1n abordando sus problemas de software sin estar al tanto de los esfuerzos en otras industrias. Cada industria ha desarrollado su propio vocabulario y documentos que describen la forma en que se debe construir el software. Algunas han desarrollado sus propias notaciones de especificaci\u00f3n y convenciones de diagramaci\u00f3n. Hay muy poca comunicaci\u00f3n cruzada. Los ingenieros de la industria nuclear discuten sus problemas de software en reuniones de la industria nuclear, mientras que los ingenieros de telecomunicaciones discuten problemas muy similares en reuniones completamente diferentes. Para llegar a su audiencia prevista, un art\u00edculo sobre ingenier\u00eda de software tendr\u00e1 que publicarse en muchos lugares diferentes. Nadie quiere hacer eso (pero los comit\u00e9s de promoci\u00f3n lo recompensan).<\/p>

Este aislamiento intelectual es inapropiado y costoso. Es inapropiado porque los problemas son muy similares. A veces, las estructuras de costos que afectan a las soluciones son diferentes, pero los problemas t\u00e9cnicos son muy similares. Es costoso porque el aislamiento a menudo resulta en que las personas reinventen la rueda, y con mayor frecuencia, reinventen ruedas muy irregulares y estructuralmente d\u00e9biles. Por ejemplo, la industria de las telecomunicaciones y aquellos interesados en los sistemas de fabricaci\u00f3n rara vez se comunican, pero sus problemas de protocolo de comunicaci\u00f3n tienen muchas similitudes. Se observa que las personas que trabajan en las dos industrias a menudo no se dan cuenta de que tienen los mismos problemas y repiten los errores del otro. Incluso la separaci\u00f3n entre software cr\u00edtico para la seguridad y software no cr\u00edtico para la seguridad (que podr\u00eda parecer sensata) es desafortunada porque las ideas que funcionan bien en una situaci\u00f3n a menudo son aplicables en las dem\u00e1s.<\/p>

Necesitamos construir una identidad profesional que se extienda a personas en todas las industrias. En este momento, alcanzamos a algunas personas en todas las industrias, pero no parece que estemos llegando a la persona t\u00edpica en esas industrias.<\/p>

<\/span>\u00bfD\u00f3nde est\u00e1n los profesionales?<\/span><\/h3>

La partici\u00f3n de personas e industrias con problemas de software es un s\u00edntoma de un problema diferente. Aunque tenemos muchas personas que reciben un salario por escribir software, no tenemos ingenieros de software en el sentido en que tenemos ingenieros aeron\u00e1uticos, el\u00e9ctricos o civiles. Estos \u00faltimos grupos son principalmente personas que han recibido una educaci\u00f3n profesional en el campo en el que trabajan, pertenecen a sociedades profesionales en ese campo y se espera que se mantengan al d\u00eda en ese campo. En cambio, descubrimos que el software en el campo nuclear es escrito por ingenieros nucleares que han aprendido un lenguaje de programaci\u00f3n, el software en el campo de las telecomunicaciones es escrito por comunicaciones<\/p>

<\/span>Habl\u00e1ndonos a nosotros mismos<\/span><\/h3>

Los investigadores deben empezar a replantearse su audiencia. Con demasiada frecuencia, escribimos art\u00edculos para impresionar a nuestros colegas, a otros investigadores. A\u00fan peor, si intentamos escribir un art\u00edculo para el profesional, los \u00e1rbitros se quejan si incluimos definiciones o problemas b\u00e1sicos. Terminamos escribiendo art\u00edculos que son le\u00eddos por nuestros colegas investigadores, pero no por muchos otros. Tambi\u00e9n dedicamos muy poco tiempo a descubrir lo que los profesionales saben, piensan y necesitan. En las Facultades de Ingenier\u00eda, se reconoce la pr\u00e1ctica profesional como esencial para una buena ense\u00f1anza e investigaci\u00f3n. En muchas facultades de Ciencias, se ve simplemente como una forma de ganar dinero extra. Esta es una de las muchas razones por las que creo que los Departamentos de Ciencias de la Computaci\u00f3n funcionar\u00edan mejor si siempre fueran parte de una Facultad de Ingenier\u00eda.<\/p>

<\/span>Conclusiones para nuestra profesi\u00f3n<\/span><\/h3>

(1) No podemos asumir que lo antiguo se conoce y no funcion\u00f3. Si no funcion\u00f3, tenemos que averiguar por qu\u00e9. A menudo es porque no se intent\u00f3.<\/p>

(2) No podemos asumir que lo antiguo funcionar\u00e1. A veces, las creencias ampliamente aceptadas son incorrectas.<\/p>

(3) No podemos ignorar los peque\u00f1os grupos de ingenier\u00eda de software. Juntos superan en n\u00famero a las personas que leer\u00e1n nuestros art\u00edculos o vendr\u00e1n a nuestras conferencias.<\/p>

(4) Los productos modelo son imprescindibles. Si no podemos ilustrar un principio con un producto real, puede que haya algo mal con el principio. Incluso si el principio es correcto, sin modelos reales, la tecnolog\u00eda no se transferir\u00e1. Los profesionales imitan lo que ven en otros productos. Si queremos que nuestras ideas se difundan, tenemos que ponerlas en productos. Hay un lugar leg\u00edtimo, honorable e importante para los investigadores que “no inventan nuevas ideas, sino que aplican, demuestran y eval\u00faan las antiguas.<\/p>

(5) Necesitamos que la frase “ingeniero de software” signifique algo. Hasta que tengamos est\u00e1ndares profesionales, requisitos educativos razonablemente estandarizados y una identidad profesional, no tenemos derecho a usar la frase “Ingenier\u00eda de Software”.<\/p>

<\/span>Referencias<\/span><\/h2>

[1] HESTER, S.D., PARNAS, D.L., UTTER, D. F., \u201cUsing Documentation as a Software Design Medium\u201d, Bell System Technical Journal, 60, 8, October 1981, pp. 1941-1977.<\/p>

[2] PARNAS, D. L., \u201cActive Reviews: Principles the 8th International Engineering, London, August 1985. Also published in Journal of System and Software, December 1987.<\/p>

[3] VAN SCHOUWEB, A.J., PARTNAS, D.L., MADEY, J. \u201cDocumentation Requirements for Computer Systems\u201d, presented at RE \u201993 IEEE International Simposium on Reqirements Engineering, San Diego, CA, 4-6 Janauary, 1993.<\/p>

[4] PARNAS, D.L., MADEY, J. \u201cFunctionalk Documentation for Computer Systems Engineering (Version 2)\u201d, CRL Report 237, CRL-TRIO McMaster University, September 1991, 14 pgs. (to be published in Science Computer Programming\u201d)<\/p>

[5] PARNAS, D.L., \u201cTabular Representation of Relations\u201dCRL Report 260, CRL. McMaster University, October 1992, 17 pgs.<\/p>

[6] JANICKI, R., \u201cTowards a Formal Semantics of Tables\u201d, CRL Report 264. CRL McMaster University September 1993, 18 pgs.<\/p>

[7] ZUCKER, J.I., \u201cNorman and Invented Function Tables\u201d, CRL Report 265, CRL, McMaster University, December 1993, 16 pgs.<\/p>

[8] PARNAS D.L., \u201cEducation for computing Professionals\u201d, IEEE Computer, vol. 23, no. 1, January 1990, pp. 17-22.<\/p>

[9] PARNAS, D.L. CLEMENTS, P.C., WEISS, D.M., \u201cThe Modular Structure of Complex Systems\u201d, IEEE Transactions on Software Engineering, March 1985, Vol. SE-111 No. 3, pp. 259-266. Also published in Proceedings of 7th International Conference on Software Engineering, March 1984, pp. 408-417.<\/p>

<\/span>Cr\u00e9ditos:<\/strong><\/span><\/h2>

David Lorge Parnas
Communications Research Laboratory
Deparment of Electrical and Computer Engineering
MacMaster University, Hamilton, Ontario, Canada L8S 4K1<\/p>

Traducido utilizando Chat GPT, revisado por Carlos Mario P\u00e9rez Aguilar.<\/p>

\u00a0<\/p>

Fuente: <\/strong>https:\/\/www.researchgate.net\/publication\/3560773_Software_aging<\/a><\/p>

Descargar en Espa\u00f1ol: Envejecimiento del Software<\/a><\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"

ABSTRACT Los programas, al igual que las personas, envejecen. No podemos evitar el envejecimiento, pero podemos entender sus causas, tomar medidas para limitar sus efectos,…<\/p>\n","protected":false},"author":1,"featured_media":12862,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[122],"tags":[],"class_list":["post-12850","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-desarrollo-de-software"],"acf":[],"yoast_head":"\nEnvejecimiento del Software - iTRENDS<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.itrends.com.mx\/en\/envejecimiento-del-software\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Envejecimiento del Software - iTRENDS\" \/>\n<meta property=\"og:description\" content=\"ABSTRACT Los programas, al igual que las personas, envejecen. No podemos evitar el envejecimiento, pero podemos entender sus causas, tomar medidas para limitar sus efectos,…\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.itrends.com.mx\/en\/envejecimiento-del-software\/\" \/>\n<meta property=\"og:site_name\" content=\"iTRENDS\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/itrendsmx\" \/>\n<meta property=\"article:published_time\" content=\"2023-12-18T23:47:59+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2023-12-19T00:06:40+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.itrends.com.mx\/wp-content\/uploads\/2023\/12\/software-aging.jpeg\" \/>\n\t<meta property=\"og:image:width\" content=\"1200\" \/>\n\t<meta property=\"og:image:height\" content=\"628\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Carlos Mario P. Aguilar\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@itrendsmx\" \/>\n<meta name=\"twitter:site\" content=\"@itrendsmx\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Carlos Mario P. Aguilar\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"33 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/envejecimiento-del-software\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/envejecimiento-del-software\\\/\"},\"author\":{\"name\":\"Carlos Mario P. Aguilar\",\"@id\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/#\\\/schema\\\/person\\\/0aaf2383a6cc51e0b20a7ca8f5177e05\"},\"headline\":\"Envejecimiento del Software\",\"datePublished\":\"2023-12-18T23:47:59+00:00\",\"dateModified\":\"2023-12-19T00:06:40+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/envejecimiento-del-software\\\/\"},\"wordCount\":7677,\"publisher\":{\"@id\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/envejecimiento-del-software\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.itrends.com.mx\\\/wp-content\\\/uploads\\\/2023\\\/12\\\/software-aging.jpeg\",\"articleSection\":[\"Desarrollo de Software\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/envejecimiento-del-software\\\/\",\"url\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/envejecimiento-del-software\\\/\",\"name\":\"Envejecimiento del Software - iTRENDS\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/envejecimiento-del-software\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/envejecimiento-del-software\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.itrends.com.mx\\\/wp-content\\\/uploads\\\/2023\\\/12\\\/software-aging.jpeg\",\"datePublished\":\"2023-12-18T23:47:59+00:00\",\"dateModified\":\"2023-12-19T00:06:40+00:00\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/envejecimiento-del-software\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/envejecimiento-del-software\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/envejecimiento-del-software\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.itrends.com.mx\\\/wp-content\\\/uploads\\\/2023\\\/12\\\/software-aging.jpeg\",\"contentUrl\":\"https:\\\/\\\/www.itrends.com.mx\\\/wp-content\\\/uploads\\\/2023\\\/12\\\/software-aging.jpeg\",\"width\":1200,\"height\":628},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/envejecimiento-del-software\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Inicio\",\"item\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Envejecimiento del Software\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/#website\",\"url\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/\",\"name\":\"iTRENDS\",\"description\":\"Desarrollo de Software, Aplicaciones m\u00f3viles y Servicios Cloud\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/#organization\",\"name\":\"iTRENDS\",\"url\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/www.itrends.com.mx\\\/wp-content\\\/uploads\\\/2019\\\/02\\\/logo-itrends-final.png\",\"contentUrl\":\"https:\\\/\\\/www.itrends.com.mx\\\/wp-content\\\/uploads\\\/2019\\\/02\\\/logo-itrends-final.png\",\"width\":227,\"height\":30,\"caption\":\"iTRENDS\"},\"image\":{\"@id\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/#\\\/schema\\\/logo\\\/image\\\/\"},\"sameAs\":[\"https:\\\/\\\/www.facebook.com\\\/itrendsmx\",\"https:\\\/\\\/x.com\\\/itrendsmx\",\"https:\\\/\\\/instagram.com\\\/itrendsmx\",\"https:\\\/\\\/www.youtube.com\\\/channel\\\/UC4ZbNQ5Y9ccZe5KT8NgFupQ\"]},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.itrends.com.mx\\\/en\\\/#\\\/schema\\\/person\\\/0aaf2383a6cc51e0b20a7ca8f5177e05\",\"name\":\"Carlos Mario P. Aguilar\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/6aad0e2d387eea096838992239155356c0a55949d509cd2366c41efb0c06295d?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/6aad0e2d387eea096838992239155356c0a55949d509cd2366c41efb0c06295d?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/6aad0e2d387eea096838992239155356c0a55949d509cd2366c41efb0c06295d?s=96&d=mm&r=g\",\"caption\":\"Carlos Mario P. Aguilar\"}}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Envejecimiento del Software - iTRENDS","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.itrends.com.mx\/en\/envejecimiento-del-software\/","og_locale":"en_US","og_type":"article","og_title":"Envejecimiento del Software - iTRENDS","og_description":"ABSTRACT Los programas, al igual que las personas, envejecen. No podemos evitar el envejecimiento, pero podemos entender sus causas, tomar medidas para limitar sus efectos,…","og_url":"https:\/\/www.itrends.com.mx\/en\/envejecimiento-del-software\/","og_site_name":"iTRENDS","article_publisher":"https:\/\/www.facebook.com\/itrendsmx","article_published_time":"2023-12-18T23:47:59+00:00","article_modified_time":"2023-12-19T00:06:40+00:00","og_image":[{"width":1200,"height":628,"url":"https:\/\/www.itrends.com.mx\/wp-content\/uploads\/2023\/12\/software-aging.jpeg","type":"image\/jpeg"}],"author":"Carlos Mario P. Aguilar","twitter_card":"summary_large_image","twitter_creator":"@itrendsmx","twitter_site":"@itrendsmx","twitter_misc":{"Written by":"Carlos Mario P. Aguilar","Est. reading time":"33 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.itrends.com.mx\/en\/envejecimiento-del-software\/#article","isPartOf":{"@id":"https:\/\/www.itrends.com.mx\/en\/envejecimiento-del-software\/"},"author":{"name":"Carlos Mario P. Aguilar","@id":"https:\/\/www.itrends.com.mx\/en\/#\/schema\/person\/0aaf2383a6cc51e0b20a7ca8f5177e05"},"headline":"Envejecimiento del Software","datePublished":"2023-12-18T23:47:59+00:00","dateModified":"2023-12-19T00:06:40+00:00","mainEntityOfPage":{"@id":"https:\/\/www.itrends.com.mx\/en\/envejecimiento-del-software\/"},"wordCount":7677,"publisher":{"@id":"https:\/\/www.itrends.com.mx\/en\/#organization"},"image":{"@id":"https:\/\/www.itrends.com.mx\/en\/envejecimiento-del-software\/#primaryimage"},"thumbnailUrl":"https:\/\/www.itrends.com.mx\/wp-content\/uploads\/2023\/12\/software-aging.jpeg","articleSection":["Desarrollo de Software"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/www.itrends.com.mx\/en\/envejecimiento-del-software\/","url":"https:\/\/www.itrends.com.mx\/en\/envejecimiento-del-software\/","name":"Envejecimiento del Software - iTRENDS","isPartOf":{"@id":"https:\/\/www.itrends.com.mx\/en\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.itrends.com.mx\/en\/envejecimiento-del-software\/#primaryimage"},"image":{"@id":"https:\/\/www.itrends.com.mx\/en\/envejecimiento-del-software\/#primaryimage"},"thumbnailUrl":"https:\/\/www.itrends.com.mx\/wp-content\/uploads\/2023\/12\/software-aging.jpeg","datePublished":"2023-12-18T23:47:59+00:00","dateModified":"2023-12-19T00:06:40+00:00","breadcrumb":{"@id":"https:\/\/www.itrends.com.mx\/en\/envejecimiento-del-software\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.itrends.com.mx\/en\/envejecimiento-del-software\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.itrends.com.mx\/en\/envejecimiento-del-software\/#primaryimage","url":"https:\/\/www.itrends.com.mx\/wp-content\/uploads\/2023\/12\/software-aging.jpeg","contentUrl":"https:\/\/www.itrends.com.mx\/wp-content\/uploads\/2023\/12\/software-aging.jpeg","width":1200,"height":628},{"@type":"BreadcrumbList","@id":"https:\/\/www.itrends.com.mx\/en\/envejecimiento-del-software\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Inicio","item":"https:\/\/www.itrends.com.mx\/en\/"},{"@type":"ListItem","position":2,"name":"Envejecimiento del Software"}]},{"@type":"WebSite","@id":"https:\/\/www.itrends.com.mx\/en\/#website","url":"https:\/\/www.itrends.com.mx\/en\/","name":"iTRENDS","description":"Desarrollo de Software, Aplicaciones m\u00f3viles y Servicios Cloud","publisher":{"@id":"https:\/\/www.itrends.com.mx\/en\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.itrends.com.mx\/en\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.itrends.com.mx\/en\/#organization","name":"iTRENDS","url":"https:\/\/www.itrends.com.mx\/en\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.itrends.com.mx\/en\/#\/schema\/logo\/image\/","url":"https:\/\/www.itrends.com.mx\/wp-content\/uploads\/2019\/02\/logo-itrends-final.png","contentUrl":"https:\/\/www.itrends.com.mx\/wp-content\/uploads\/2019\/02\/logo-itrends-final.png","width":227,"height":30,"caption":"iTRENDS"},"image":{"@id":"https:\/\/www.itrends.com.mx\/en\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/itrendsmx","https:\/\/x.com\/itrendsmx","https:\/\/instagram.com\/itrendsmx","https:\/\/www.youtube.com\/channel\/UC4ZbNQ5Y9ccZe5KT8NgFupQ"]},{"@type":"Person","@id":"https:\/\/www.itrends.com.mx\/en\/#\/schema\/person\/0aaf2383a6cc51e0b20a7ca8f5177e05","name":"Carlos Mario P. Aguilar","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/6aad0e2d387eea096838992239155356c0a55949d509cd2366c41efb0c06295d?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/6aad0e2d387eea096838992239155356c0a55949d509cd2366c41efb0c06295d?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/6aad0e2d387eea096838992239155356c0a55949d509cd2366c41efb0c06295d?s=96&d=mm&r=g","caption":"Carlos Mario P. Aguilar"}}]}},"jetpack_featured_media_url":"https:\/\/www.itrends.com.mx\/wp-content\/uploads\/2023\/12\/software-aging.jpeg","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.itrends.com.mx\/en\/wp-json\/wp\/v2\/posts\/12850","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.itrends.com.mx\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.itrends.com.mx\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.itrends.com.mx\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.itrends.com.mx\/en\/wp-json\/wp\/v2\/comments?post=12850"}],"version-history":[{"count":9,"href":"https:\/\/www.itrends.com.mx\/en\/wp-json\/wp\/v2\/posts\/12850\/revisions"}],"predecessor-version":[{"id":12861,"href":"https:\/\/www.itrends.com.mx\/en\/wp-json\/wp\/v2\/posts\/12850\/revisions\/12861"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.itrends.com.mx\/en\/wp-json\/wp\/v2\/media\/12862"}],"wp:attachment":[{"href":"https:\/\/www.itrends.com.mx\/en\/wp-json\/wp\/v2\/media?parent=12850"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.itrends.com.mx\/en\/wp-json\/wp\/v2\/categories?post=12850"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.itrends.com.mx\/en\/wp-json\/wp\/v2\/tags?post=12850"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}