¿Qué es la ingeniería de software de investigación?

La ingeniería de software de investigación (RSE, por sus siglas en inglés) es la disciplina de aplicar prácticas profesionales de ingeniería de software —control de versiones, pruebas, revisión de código, integración continua, documentación y mantenimiento a largo plazo— al código que sustenta la investigación científica. Si alguna vez ha pasado tres semanas depurando un script de análisis de dinámica molecular que solo se ejecuta en la computadora portátil de un posdoctorado, o ha intentado reproducir un resultado publicado a partir de un archivo tar de Python no documentado, ya se ha enfrentado al problema que la ingeniería de software de investigación existe para resolver. Este artículo explica qué es la RSE, en qué se diferencia de los roles adyacentes, qué hace realmente un ingeniero de software de investigación en el día a día y cómo decidir si su grupo necesita uno.

La definición breve y por qué es cuestionada

El término “ingeniero de software de investigación” se acuñó en el Reino Unido alrededor de 2012, en gran parte gracias al trabajo del Software Sustainability Institute, para dar un nombre a una población creciente de personas que no eran ni investigadores tradicionales ni personal de soporte de TI. Escribían código que era esencial para la investigación, pero su progresión profesional, títulos de trabajo y reconocimiento no encajaban en ninguna de las dos categorías.

La definición operativa comúnmente citada es que un ingeniero de software de investigación es alguien que combina:

1. Una comprensión profesional de la ingeniería de software —diseño, pruebas, control de versiones, despliegue, mantenimiento.
2. Un papel activo en la investigación —contribuyendo a las preguntas de investigación, publicaciones y solicitudes de subvenciones, no simplemente implementando una especificación dictada por otra persona.
3. Un compromiso profundo con al menos un dominio de investigación —suficiente para comprender la ciencia, los datos y las limitaciones.

La parte cuestionada es el límite. ¿Es un bioinformático que mantiene un paquete de R ampliamente utilizado un RSE? ¿Es un físico que escribe código de simulación para sus propios artículos un RSE? ¿Es el “administrador de datos” de un grupo de investigación que escribe mucho Python un RSE? No existe un organismo regulador ni una certificación universalmente aceptada, por lo que la etiqueta se aplica de manera pragmática. En la práctica, la característica distintiva es la orientación: los RSE tratan el software como un resultado de investigación de primera clase y un artefacto de larga duración, en lugar de un medio desechable para un solo artículo.

RSE frente a roles adyacentes: una comparación

La forma más rápida de entender la RSE es ver dónde se ubica en relación con los roles con los que a menudo se confunde. La siguiente tabla es una heurística, no una taxonomía; las personas reales desdibujan estas líneas constantemente.

Dimensión	Ingeniero de Software de Investigación	Investigador Tradicional (que programa)	Soporte de TI / Computación de Investigación	Científico / Analista de Datos
Producto principal	Software mantenible y reutilizable	Publicaciones y hallazgos	Infraestructura y servicios operativos	Modelos, análisis, decisiones
Vida útil del código	Años o décadas; versiones controladas	A menudo vinculado a un proyecto/artículo	Vida útil del servicio; a menudo gestionado por el proveedor	A menudo vinculado al proyecto
Habilidades típicas	Diseño de software, pruebas, CI/CD, HPC, ciencia del dominio	Ciencia del dominio, métodos, estadística	Administración de sistemas, redes, planificadores, seguridad	Estadística, ML, datos del dominio
Relación con la pregunta de investigación	La codesfine y le da forma	Es el propietario de la misma	La sirve indirectamente	A menudo responde a una pregunta planteada
Métrica de éxito	Adopción, reproducibilidad, citas del software, sostenibilidad	Publicaciones, subvenciones, impacto	Tiempo de actividad, satisfacción del usuario, costo	Perspectiva de negocio/investigación
Trayectoria profesional	A menudo híbrida; a veces científico permanente	Escalafón de profesor/posdoctorado	Escalafón de TI	Industrial o académico

La idea clave: un RSE no es “un investigador que resulta ser bueno programando”, ni “una persona de TI que ayuda con Python”. El rol se define por ser el dueño del software como un producto de investigación mientras permanece integrado en la ciencia.

Relacionado: DataCamp — Cursos interactivos de Python y ciencia de datos que codifica directamente en el navegador.

Lo que realmente hace un ingeniero de software de investigación

Las descripciones de los puestos varían enormemente, pero el trabajo se agrupa en categorías reconocibles. Una semana realista podría abarcar cuatro o cinco de estas.

1. Construcción y mantenimiento de software de investigación

Este es el núcleo. Incluye diseñar API para códigos de simulación, refactorizar un script de análisis monolítico en una biblioteca probada, empaquetar herramientas para su distribución en PyPI o conda-forge y evitar que las dependencias se rompan. Para un grupo de dinámica molecular, esto podría significar mantener un conjunto de herramientas de análisis de GROMACS o LAMMPS, o escribir un flujo de datos (pipeline) de NumPy/HDF5 que transmita datos de trayectoria sin cargar terabytes en la RAM.

2. Hacer que la investigación sea reproducible

Los RSE suelen ser las personas que introducen environment.yml, pyproject.toml, imágenes de contenedores (Docker, Singularity/Apptainer) y gestores de flujo de trabajo (Snakemake, Nextflow, Common Workflow Language) en un laboratorio. El objetivo es que un resultado pueda ser regenerado en una máquina diferente, por una persona diferente, dos años después. Aquí es donde la RSE se superpone considerablemente con el movimiento de reproducibilidad y con los principios de datos FAIR.

Favorito del lector: Dataquest — Rutas de ciencia de datos basadas en proyectos con una terminal guiada y conjuntos de datos reales.

3. Rendimiento y escalabilidad

El código científico frecuentemente necesita ejecutarse más rápido o a mayor escala. Los RSE realizan el perfilado (profiling) del código, vectorizan operaciones de NumPy, paralelizan con MPI u OpenMP, portan bucles críticos a C/C++/Fortran o usan Numba/Cython, y ajustan la E/S —las opciones de fragmentación (chunking) y compresión de HDF5, por ejemplo, pueden dominar el tiempo de ejecución en el análisis de trayectorias—. También ayudan a los grupos a utilizar los clústeres de HPC y las GPU de forma eficaz.

4. Consultoría y formación

Muchos RSE ofrecen horas de tutoría, revisiones de código y talleres (Software Carpentry, HPC Carpentry, formación específica del dominio). Una gran parte de su impacto proviene de enseñar a los investigadores a escribir mejor código por sí mismos, en lugar de hacerlo todo por ellos.

5. Contribuciones a subvenciones y publicaciones

Los RSE aparecen cada vez más como coautores y como personal nombrado en las subvenciones, porque los financiadores ahora esperan un plan de gestión y sostenibilidad del software. Escribir ese plan, estimar el esfuerzo y comprometerse con el mantenimiento son actividades de RSE.

Ubicación organizativa de los RSE

Existen tres modelos comunes, cada uno con sus ventajas y desventajas:

• Grupo de RSE centralizado (un equipo a nivel de universidad o instituto). Ventajas: experiencia compartida, trayectoria profesional para los RSE, capacidad de asignar personal a múltiples proyectos. Desventajas: puede estar distante de cualquier pregunta de investigación específica; políticas de priorización o de cargo compartido (chargeback).
• Integrado en un grupo de investigación o laboratorio. Ventajas: contexto profundo del dominio, iteración rápida, relaciones sólidas. Desventajas: aislamiento, falta de una comunidad de pares RSE, riesgo de que el RSE se convierta en un recurso general de “arréglame la computadora”.
• Híbrido / matricial. Un grupo central con personal comisionado a proyectos. Cada vez más común; requiere una gestión jerárquica clara y acuerdos de asignación de tiempo.

El Reino Unido tiene una comunidad de RSE particularmente visible, con una conferencia anual de RSE y redes regionales. Existen comunidades similares en Alemania (de-RSE), los Países Bajos, los EE. UU. y Australia. La Society of Research Software Engineering (Society of RSE) se estableció en el Reino Unido como organismo profesional.

Cómo se relaciona la RSE con la reproducibilidad y la ciencia abierta

La crisis de reproducibilidad en la ciencia computacional es, en gran medida, un problema de software. Los análisis dependen de versiones específicas de librerías, pasos de preprocesamiento no documentados y código que nunca fue publicado. Las prácticas de RSE abordan esto directamente:

Relacionado: O'Reilly Learning Platform — Una amplia biblioteca técnica de libros, vídeos y formación en directo sobre informática científica..

• El control de versiones y las versiones etiquetadas (tagged releases) hacen posible citar la versión exacta del software utilizada.
• Las pruebas detectan los errores numéricos silenciosos que producen resultados plausibles pero incorrectos.
• La integración continua garantiza que el código siga funcionando tras las actualizaciones de dependencias.
• El archivo del código en Zenodo o Software Heritage le otorga un DOI y un hogar permanente.
• La documentación permite que otros (incluido usted mismo en el futuro) lo comprendan y reutilicen.

Los principios FAIR para el software de investigación, desarrollados por la Research Data Alliance, extienden las pautas de datos FAIR explícitamente al software. Las revistas exigen cada vez más declaraciones de disponibilidad del código, y algunas requieren la revisión del código como parte de la publicación.

Cómo decidir si necesita un RSE

No todos los grupos necesitan un RSE dedicado. Utilice estos criterios como un filtro aproximado:

Probablemente necesite uno si:

Nuestra elección: Udemy — Compre cursos individuales de Python científico directamente, frecuentemente con grandes descuentos.

• El software es fundamental para sus resultados de investigación y es utilizado por personas ajenas a su grupo.
• Mantiene código a lo largo de múltiples subvenciones y años, y este sigue fallando.
• Está reconstruyendo repetidamente la misma infraestructura (E/S, paralelismo, empaquetado) que otros ya han resuelto.
• Los revisores, colaboradores o financiadores preguntan sobre la sostenibilidad del software y usted no tiene una respuesta satisfactoria.
• Su grupo dedica un tiempo significativo al mantenimiento de software que es invisible en las publicaciones.

Es posible que no necesite uno (todavía) si:

• Su código es genuinamente desechable: un análisis único para una sola figura.
• Sus necesidades están cubiertas por herramientas comunitarias bien mantenidas y usted solo escribe scripts de enlace (glue scripts).
• Tiene un miembro del grupo que realmente disfruta de esto, es bueno en ello y tiene tiempo.

Un punto medio: contratar a un RSE a tiempo parcial, participar en un grupo central o invertir en formación para ayudar a los investigadores actuales a adoptar las mejores prácticas. El peor resultado sería contratar a un RSE y luego utilizarlo como soporte de TI ad hoc.

Trayectorias profesionales y cómo convertirse en RSE

Las carreras de RSE son verdaderamente diversas. Los puntos de entrada incluyen:

• Doctorado en un dominio computacional (física, química, bioinformática) que se inclinó hacia la parte del software.
• Ingeniero de software de la industria que desea trabajar en problemas científicos.
• Personal de investigación que formaliza su rol de software.

Habilidades que más importan, aproximadamente en orden de frecuencia de aparición:

1. Conocimiento de Python (y a menudo C++, Fortran o Julia para código crítico en rendimiento).
2. Control de versiones con Git, incluyendo flujos de trabajo de ramificación (branching) y revisión de código.
3. Marcos de pruebas (Pytest, GoogleTest) y CI (GitHub Actions, GitLab CI).
4. Empaquetado y gestión de entornos (Conda, Pip, Contenedores).
5. HPC y programación paralela (MPI, OpenMP, CUDA, planificadores de trabajos como Slurm).
6. Competencia científica en el campo: suficiente para hablar con los investigadores como colegas.
7. Habilidades de comunicación y enseñanza.

La escala profesional está menos estandarizada que en la academia o la industria. Algunos RSE se convierten en científicos permanentes; algunos pasan al liderazgo en computación de investigación; algunos regresan a la facultad; otros se van a la industria. La falta de una escala clara es un problema real y frecuentemente discutido en la comunidad, y una razón por la cual los organismos profesionales y los grupos centrales son importantes.

Conceptos erróneos comunes

• “La RSE es solo soporte de TI para científicos”. No; los RSE dan forma a las preguntas de investigación y son dueños de los productos de software. El soporte de TI mantiene la infraestructura.
• “Cualquier buen programador puede hacer RSE”. El contexto del dominio importa enormemente. Un desarrollador web brillante puede no saber por qué el orden de una suma de punto flotante cambia un resultado.
• “Los RSE solo escriben código”. Una gran parte del trabajo consiste en consultoría, formación y discusión de diseño.
• “La RSE es un trampolín hacia un trabajo académico ‘real’”. Para algunos lo es; para muchos es una carrera legítima y permanente.
• “Necesita un título en informática”. La mayoría de los RSE provienen de dominios científicos, no de informática.

Conclusiones clave

• La ingeniería de software de investigación aplica prácticas profesionales de software al código de investigación, tratando el software como un resultado de investigación de primera clase y de larga duración.
• Un RSE se define por la combinación de habilidades de ingeniería de software, participación activa en la investigación y experiencia en el dominio, no por un título de trabajo o certificación específicos.
• La RSE se diferencia del soporte de TI, la ciencia de datos y los “investigadores que programan” principalmente en la propiedad del software como producto y su vida útil plurianual.
• Las actividades principales incluyen la construcción y el mantenimiento de código, la habilitación de la reproducibilidad, el ajuste del rendimiento, la consultoría, la formación y la contribución a subvenciones y publicaciones.
• Los RSE pueden estar centralizados, integrados o ser híbridos; cada modelo tiene compensaciones reales en cuanto a contexto, trayectoria profesional y priorización.
• Decidir si necesita un RSE depende de si el software es central, reutilizado y de larga duración, no solo del tamaño del grupo.

Fuentes y lecturas adicionales

• Research software engineering — Wikipedia: Research software engineering is the application of software engineering practices, methods and techniques for research software, i.e. software that was made for…
• Software engineering — Wikipedia: Software engineering is a branch of both computer science and engineering focused on designing, developing, testing, and maintaining software applications. It involves…

Preguntas frecuentes

¿Qué es la ingeniería de software de investigación en términos sencillos?

La ingeniería de software de investigación es la práctica de construir y mantener el software en el que confían los científicos, utilizando los mismos estándares profesionales —pruebas, control de versiones, documentación, mantenimiento— que utilizan los equipos de software comercial. Un ingeniero de software de investigación trabaja en la intersección del desarrollo de software y un dominio científico, por lo que comprende tanto el código como la ciencia a la que sirve. El objetivo es un software que sea correcto, reutilizable y que siga funcionando años después.

¿En qué se diferencia un ingeniero de software de investigación de un ingeniero de software?

Un desarrollador de software tradicional normalmente crea productos para usuarios o clientes, y los requisitos suelen ser determinados por un equipo de producto. Un desarrollador de software de investigación trabaja en software cuyo propósito es generar o respaldar conocimiento científico, donde los requisitos suelen ser de naturaleza exploratoria y el resultado “correcto” puede desconocerse de antemano. Los RSE también suelen requerir conocimiento real del dominio, suficiente para juzgar si un resultado numérico es físicamente plausible, no solo si el código se ejecutará.

¿Necesito un doctorado para convertirme en ingeniero de software de investigación?

No, pero el conocimiento del dominio es esencial y un doctorado es una forma común de adquirirlo. Muchos RSE tienen doctorados en física, química, bioinformática o campos relacionados y avanzaron hacia el lado del software de su trabajo. Otros provienen de la ingeniería de software de la industria y aprenden el dominio en el trabajo. Lo que importa es poder interactuar con los investigadores como pares sobre la ciencia, no la credencial en sí.

¿Qué lenguajes de programación utilizan los ingenieros de software de investigación?

Python domina, especialmente para análisis, secuencias de comandos y código puente, a menudo junto con NumPy, pandas y E/S basadas en HDF5. Los componentes críticos para el rendimiento se escriben con frecuencia en C++, Fortran o C, y Julia y Rust ganan terreno. R sigue siendo importante en estadística y bioinformática, y los lenguajes de scripting de shell, Make y flujo de trabajo como Snakemake y Nextflow son omnipresentes. El lenguaje importa menos que las prácticas que lo rodean.

¿Es la ingeniería de software de investigación una buena carrera?

Para las personas que disfrutan tanto de la ciencia como del software, puede ser una carrera excelente con una gran demanda, problemas variados y un impacto visible. La principal advertencia es que las estructuras profesionales están menos estandarizadas que en la academia o la industria, por lo que la progresión depende en gran medida de la institución y de si existe un grupo central de RSE. Muchos RSE consideran que el trabajo es más estable y mejor remunerado que los puestos de posdoctorado, aunque la falta de una escalera universal es un problema reconocido.

¿Cómo apoya la ingeniería de software de investigación la reproducibilidad?

Las prácticas de RSE hacen que los resultados sean reproducibles al fijar versiones exactas del software, automatizar compilaciones y pruebas, documentar dependencias y archivar el código con un DOI para que pueda citarse y recuperarse. Sin estas prácticas, los análisis a menudo dependen de pasos no documentados y versiones de bibliotecas específicas que son imposibles de reconstruir más adelante. Los RSE también introducen contenedores y administradores de flujo de trabajo que capturan un entorno computacional completo, no solo el código.

Lecturas adicionales y fuentes autorizadas

• El artículo de Wikipedia sobre ingeniería de software de investigación proporciona una descripción general y la historia del término.
• El Software Sustainability Institute (software.ac.uk) publica extensamente sobre definiciones, carreras y encuestas comunitarias de RSE.
• La Sociedad de Ingeniería de Software de Investigación (society-rse.org) es el organismo profesional del Reino Unido para este campo.
• Los Principios FAIR para Software de Investigación, de Research Data Alliance, extienden las pautas de datos FAIR específicamente al software.
• El Journal of Open Source Software (joss.theoj.org) y el Journal of Open Research Software publican software de investigación revisado por pares.