¿Qué pasó con CrossTalk? + Los 10 mejores artículos
En 1987, la Fuerza Aérea de EE. UU. estableció el Centro de Soporte de Tecnología de Software (STSC). Su misión era "ayudar a las organizaciones a identificar, evaluar y adoptar tecnologías que mejoren la calidad del producto software, la eficiencia de producción y la predictibilidad” (Fuente). Para alcanzar este objetivo, el STSC fundó una publicación en línea llamada CrossTalk: The Journal of Defensive Software Engineering, la cual gestionó desde su sitio web (Stsc.hill.af.mil) desde 1996 hasta 2016.
Posteriormente, el STSC creó el sitio web Crosstalkonline.org, donde CrossTalk continuó publicándose. Sin embargo, desde 2017, el sitio no es accesible.
¿Qué pudo haberle pasado? Intentamos averiguarlo explorando la historia de la publicación. Terminamos este artículo repasando los 10 artículos más importantes que publicó.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
La Historia de CrossTalk
CrossTalk comenzó a publicarse en 1988 para fomentar técnicas que aseguren el desarrollo de software de alta calidad. Según el STSC, el objetivo de la publicación era “mejorar la fiabilidad, mantenibilidad y capacidad de respuesta de nuestras capacidades de combate y también instruir, informar y educar a los lectores sobre decisiones políticas actualizadas y nuevas tecnologías de ingeniería de software” (Fuente).
Bajo el liderazgo de Reuel Alder (el editor), Tracy Stauder (editora gerente) y Sandi Gaskin (editora senior), CrossTalk creció de aproximadamente 200 suscriptores a 29.000 (Fuente).
Stsc.hill.af.mil, el sitio donde inicialmente se publicó CrossTalk, se estableció en diciembre de 1996. Los volúmenes anteriores pueden encontrarse aquí.
Stsc.hill.af.mil incluía un formulario de suscripción, guías para escritores potenciales y anuncios de temas. También contenía una página con la información de contacto del personal de planta de la publicación.
CrossTalk permanecería en el sitio del STSC hasta noviembre de 2010, cuando se trasladó a su propio sitio: Crosstalkonline.org. El último número de CrossTalk capturado en internet corresponde a agosto de 2017.
Hay muy poca información disponible sobre qué ocurrió tanto con el sitio web como con la publicación después de agosto de 2017.
Los 10 Artículos Más Importantes Publicados por CrossTalk
En memoria de CrossTalk, identificamos 10 de los artículos más importantes que publicó a lo largo de su existencia.
Para identificarlos, nos centramos en el número de enlaces que cada uno de los artículos recibió por parte de administradores web y editores. Los artículos que reciben más enlaces (citas) probablemente sean más importantes que los que reciben menos enlaces.
1. Educación en Ciencias de la Computación: ¿Dónde están los Ingenieros de Software del Mañana?
Los académicos Robert Dewar y Edmond Schonberg, entonces ambos profesores de Ciencias de la Computación en la Universidad de Nueva York, se valen de este artículo para argumentar que la educación en Ciencias de la Computación (en 2008) descuidaba habilidades necesarias.
Los autores responsabilizan a la adopción generalizada de “Java como primer lenguaje de programación” de esta situación. Presentaron un resumen de las habilidades que, en su opinión, deben formar parte del conjunto básico de todo profesional del software: lenguajes de programación, herramientas de gestión de pruebas para construir programas fiables a gran escala y metodologías de demostración formal (fuente).
2. Escalando el Desarrollo Ágil: Desarrollo de Productos a Gran Escala y en Múltiples Sitios con Scrum de Gran Escala
Los consultores Craig Larman y Bas Vodde utilizaron este artículo, escrito en 2013, para resumir el contenido de su serie de libros en dos volúmenes sobre el desarrollo ágil a muy gran escala. Describieron cómo han trabajado con clientes para introducir dos marcos de trabajo Scrum a gran escala en grandes grupos globales. Ejemplos de empresas con las que trabajaron incluyen Bank of America y Erickson, el proveedor de equipos de infraestructura de telecomunicaciones.
Larman y Vodde informan que sus experiencias les llevaron a publicar dos volúmenes. El Volumen 1 es Herramientas de pensamiento y organizacionales para Scrum a gran escala. Se centra en el liderazgo y el diseño organizacional. El segundo volumen es Prácticas para escalar el desarrollo Lean & Ágil: Desarrollo de productos grandes, multisede y offshore con Scrum a gran escala. Ofrece sugerencias prácticas para la escalabilidad en diversas circunstancias.
3. Uso tanto del Desarrollo Incremental como del Iterativo
El autor de este artículo de 2008, el Dr. Alistair Cockburn (descrito por CrossTalk como un experto en diseño orientado a objetos (OO), metodologías de desarrollo de software, casos de uso y gestión de proyectos) se centra en el desarrollo incremental y el desarrollo iterativo en el ámbito del software.
El Dr. Cockburn identifica los desafíos que enfrentan los equipos al abordar el desarrollo incremental y el desarrollo iterativo: intentar gestionarlos de la misma manera o pensar que cuando se usa uno, no debería usarse el otro. Finaliza resumiendo sus ideas: "La palabra incrementar significa añadir; la palabra iterar significa rehacer” (Fuente).
4. SmartCam3D proporciona nuevos niveles de conciencia situacional
En este artículo de 2005, Janis White (consultora estadística), Frank Delgado (trabajando para la NASA) y Mike Abernathy (especialista en software) se centran en el SmartCam3D (SC3D). Este es un “sistema híbrido de visión sintética que combina la información de sensores en vivo con datos de un sistema de visión sintética para crear una ventana virtual en la cabina”.
Los autores presentan el sistema híbrido de visión sintética (HSVS). Este es un sistema que describen como la combinación de “datos en vivo de sensores con información de un sistema de visión sintética (SVS) para crear imágenes ricas en información y en tiempo real.” Concluyen diciendo que el SC3D fue el primer sistema HSVS en tiempo real, sugiriendo que “este software salvará vidas” (Fuente).
5. CMMI Apoya la Mejora de Procesos a Nivel Empresarial
El teniente coronel Joe Jarzombek, que entonces trabajaba como director en Earth Science Information Partners (ESIP), una comunidad dedicada a hacer los datos científicos más accesibles, utilizó este artículo para introducir la idea de los Modelos de Madurez de Capacidades (CMMs). Esto se refiere a conjuntos de modelos que abordan procedimientos organizacionales y competencias que abarcan varias disciplinas.
Jarzombek presenta la idea de los equipos CCMI, refiriéndose a un "esfuerzo colaborativo para integrar los CMMs." Tales unidades, argumenta, crearían un conjunto de productos integrados que apoyan la mejora de procesos y productos en el ámbito del desarrollo de software (Fuente).
6. Por qué fallan los grandes proyectos de software: Las 12 preguntas clave
En este artículo de 2005 producido por Watts S. Humphrey del Instituto de Ingeniería de Software (SEISM) de la Universidad Carnegie Mellon, el enfoque está en las 12 preguntas críticas sobre por qué fallan los grandes proyectos de software.
Para Humphrey, las respuestas a las preguntas que plantea en el artículo ayudarán a los desarrolladores de software a mejorar sus proyectos. Él cree que los principales problemas están vinculados a las razones por las que a menudo es un reto gestionar grandes proyectos de software, el tipo de sistemas de gestión requeridos y lo que debe hacerse al implementar estos sistemas (Fuente).
7. Desmitificando la Computación en la Nube
Reflexionando sobre los avances que estaban teniendo lugar en 2011 en el desarrollo de software, Qusay F. Hassan, de la Facultad del Departamento de Computadoras e Información de la Universidad de Mansoura en Egipto, se enfoca en la computación en la nube.
En el artículo, intenta abordar la idea de que el término “computación en la nube” suele ser mal utilizado por las personas cuando se refieren a cosas que pueden no estar relacionadas con su definición y alcance reales. ¿Se trata solo de alojamiento web? pregunta. Luego pasa a definir varios conceptos como Alojamiento Web, Proveedor de Servicios de Aplicaciones (ASP), Computación Voluntaria y Compartición de Archivos en Línea, entre muchos otros (Fuente).
8. Corrección por Construcción: Un Manifiesto para Software de Alta Integridad
“Los sistemas de software de alta integridad suelen ser tan grandes que los procesos de desarrollo convencionales no pueden ni siquiera acercarse a conseguir tasas de defectos tolerables”, afirman Martin Croxford y el Dr. Roderick Chapman al comienzo de este artículo. Cuando los dos autores escribieron esta pieza, trabajaban para Praxis High Integrity Systems, una empresa británica de ingeniería de sistemas especializada en sistemas críticos (Fuente).
En este artículo de 2005, los autores prometen presentar un enfoque que ha producido “software con tasas de defectos muy bajas a un coste efectivo”. El método sobre el que escriben es la Corrección por Construcción (CbyC). Este es un enfoque para el desarrollo de software que se adapta bien al cambio durante todo su ciclo de vida y cuyas tasas de defecto eran más bajas que las prácticas comerciales de aquel entonces (Fuente).
9. Defectos en el Diseño de la Interfaz de Usuario del Navegador: Aprovechando la Ignorancia del Usuario
Este artículo fue escrito por Aditya Sood, entonces doctorando en la Universidad Estatal de Michigan, y Richard Enbody, Profesor Asociado en el Departamento de Ciencias de la Computación e Ingeniería también en la Universidad Estatal de Michigan, en 2011. En el resumen del artículo, los autores señalan que los “defectos de diseño en los navegadores representan graves amenazas para la seguridad, la privacidad y la integridad del usuario”.
La pieza se enfoca en los fallos de diseño en la Interfaz Gráfica de Usuario (GUI)
de los componentes de los navegadores. Los autores sugieren que estos son los fallos que los estafadores aprovechan cuando engañan a los usuarios para que realicen acciones que comprometen su seguridad (Fuente).
10. Problemas Geriátricos del Software Envejecido
Capers Jones, quien por entonces trabajaba en investigación sobre productividad de software, se centra en los problemas vinculados al envejecimiento del software en empresas y el sector público. En este artículo de 2007, Jones advierte que no era sorprendente encontrar entidades utilizando software de más de 10 años de antigüedad, con aplicaciones que alcanzaban hasta 25 años.
Jones también trata las consecuencias del software envejecido, señalando que se vuelve difícil de mantener porque las actualizaciones suelen destruir la estructura inicial de las aplicaciones. Esto aumenta la entropía (falta de previsibilidad y orden). Señala que a medida que el software envejece, un problema llamado inyección de correcciones lleva a que “aparezcan nuevos defectos (de manera accidental) como subproducto de corregir defectos previos” (Fuente).
