¿Qué pasó con CrossTalk? + Los 10 mejores artículos
En 1987, la Fuerza Aérea de los EE. UU. estableció el Software Technology Support Center (STSC). Su misión era "ayudar a las organizaciones a identificar, evaluar y adoptar tecnologías que mejoren la calidad de los productos de software, la eficiencia de producción y la previsibilidad” (Fuente). Para lograr este objetivo, el STSC fundó una publicación en línea llamada CrossTalk: The Journal of Defensive Software Engineering, la cual publicó en 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 ha estado accesible.
¿Qué le pudo haber pasado? Intentamos averiguarlo explorando la historia de la publicación. Finalmente, cerramos este artículo repasando los 10 artículos más importantes que publicó.
La Historia de CrossTalk
CrossTalk empezó 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 confiabilidad, mantenibilidad y capacidad de respuesta de nuestra capacidad de combate bélico, así como instruir, informar y educar a los lectores sobre decisiones políticas actuales y nuevas tecnologías de ingeniería de software” (Fuente).
Bajo el liderazgo de Reuel Alder (el editor), Tracy Stauder (Editora General) 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, fue creado en diciembre de 1996. Los volúmenes más antiguos pueden encontrarse aquí.
Stsc.hill.af.mil incluía un formulario de suscripción, directrices para aspirantes a escritores y anuncios temáticos. También contenía una página con la información de contacto del personal de planta de la publicación.
CrossTalk permanecería bajo el sitio web 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.
Existe muy poca información disponible sobre lo que 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 basamos en la cantidad de enlaces que cada artículo recibió de responsables web y editores. Los artículos que atraen más enlaces (citas) probablemente sean más importantes que los que atraen menos.
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, utilizan este artículo para argumentar que la educación en Ciencias de la Computación (en 2008) descuidaba habilidades necesarias.
Los autores culpan de esta situación a la adopción generalizada de “Java como primer lenguaje de programación”. Proporcionan un resumen de las habilidades que consideran deben formar parte esencial de todo profesional del software: lenguajes de programación, herramientas de gestión de pruebas para construir programas confiables a gran escala y las metodologías de prueba formal (fuente).
2. Escalando el Desarrollo Ágil: Desarrollo de Productos Grandes y Multisitio con Scrum a Gran Escala
Los consultores Craig Larman y Bas Vodde utilizaron este artículo, escrito en 2013, para resumir el contenido de su serie de dos volúmenes sobre desarrollo ágil a gran escala. Describen 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 han trabajado incluyen Bank of America y Erickson, el proveedor de equipos de infraestructura de telecomunicaciones.
Larman y Vodde informan que sus experiencias los llevaron a publicar dos volúmenes. El Volumen 1 es Pensamiento y herramientas organizacionales para Scrum a gran escala. Este se centra en el liderazgo y el diseño organizacional. El segundo volumen es Prácticas para escalar Lean & Agile Development: Desarrollo de producto grande, multisede y offshore con Scrum a gran escala. Aporta sugerencias prácticas para escalar en diversas circunstancias.
3. Uso conjunto del desarrollo incremental e 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 retos que enfrentan los equipos al tratar con el desarrollo incremental e iterativo: intentar gestionarlos de la misma manera o pensar que cuando se utiliza uno, no se debe utilizar el otro. Concluye 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 de visión sintética híbrida que combina información de sensores en vivo con datos de un sistema de visión sintética para crear una ventana de cabina virtual.”
Los autores presentan el sistema de visión sintética híbrida (HSVS). Se trata de un sistema que describen como la combinación de “datos de sensores en tiempo real con información de un sistema de visión sintética (SVS) para crear imágenes enriquecidas 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 en toda la empresa
El teniente coronel Joe Jarzombek, quien en ese momento trabajaba como director en Earth Science Information Partners (ESIP), una comunidad dedicada a hacer que los datos científicos sean 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 tratan sobre procedimientos organizacionales y competencias que cruzan disciplinas.
Jarzombek presenta la idea de equipos CCMI, denotando un "esfuerzo colaborativo para integrar los CMM". Tales unidades, argumenta, crearían un conjunto de productos incorporados que apoyarían la mejora de procesos y productos en el espacio de desarrollo de software (Fuente).
6. Por qué fracasan los grandes proyectos de software: Las 12 preguntas clave
En este artículo de 2005 realizado por Watts S. Humphrey del Software Engineering Institute (SEISM) de la Universidad Carnegie Mellon, el enfoque está en las 12 preguntas críticas acerca de por qué fracasan 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 desafío gestionar grandes proyectos de software, el tipo de sistemas de gestión requeridos y lo que se debe hacer al implementar estos sistemas (Fuente).
7. Desmitificando la Computación en la Nube
Reflexionando sobre los avances que se estaban produciendo en 2011 en el desarrollo de software, Qusay F. Hassan, de la Facultad de Computación e Información de la Universidad de Mansoura, Egipto, se centra 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” es a menudo mal utilizado por personas que 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 el Software de Alta Integridad
“Los sistemas de software de alta integridad suelen ser tan grandes que los procesos de desarrollo convencionales no pueden acercarse siquiera a lograr tasas de defectos tolerables”, afirman Martin Croxford y el Dr. Roderick Chapman al inicio de este trabajo. Cuando los dos autores escribieron este artículo, trabajaban para Praxis High Integrity Systems, una empresa británica de ingeniería de sistemas especializada en sistemas de misión crítica (Fuente).
En este artículo de 2005, los autores prometen presentar un enfoque que ha producido “software con tasas de defectos muy bajas de forma rentable”. El método del que escriben es la Corrección por Construcción (CbyC). Se trata de un enfoque para el desarrollo de software que se adapta bien a los cambios a lo largo de su vida y cuyas tasas de defectos eran inferiores a las de las prácticas comerciales de entonces (Fuente).
9. Fallos de Diseño en la Interfaz de Usuario del Navegador: Aprovechando la Ignorancia del Usuario
Este artículo fue escrito por Aditya Sood, entonces candidato a doctorado en la Universidad Estatal de Michigan, y Richard Enbody, profesor asociado en el Departamento de Ciencia e Ingeniería de la Computación, también en la Universidad Estatal de Michigan, en 2011. En el resumen del artículo, los autores observan que los “fallos de diseño en los navegadores representan serias amenazas para la seguridad, privacidad e integridad del usuario.”
El artículo se centra 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 entonces trabajaba en investigación sobre productividad de software, se centra en los problemas vinculados al software envejecido en empresas y el sector público. En este artículo de 2007, Jones informa que no era sorprendente entonces encontrar entidades utilizando software de más de 10 años, con aplicaciones de hasta 25 años de antigüedad.
Jones también aborda las consecuencias del envejecimiento del software, señalando que resulta difícil mantener dicho software porque las actualizaciones a menudo destruyen la estructura inicial de las aplicaciones. Esto incrementa la entropía (falta de predictibilidad y orden). Observa que conforme el software envejece, un problema denominado inyección de arreglos conduce a que “se introduzcan accidentalmente nuevos defectos como subproducto de corregir defectos previos” (Fuente).
