Saltar al contenido

Traspaso de software: qué debe poder hacer el nuevo equipo

Una instalación independiente y un cambio pequeño muestran si el código, la configuración y el conocimiento operativo encajan.

Katharina Weber2 min de lectura
Carpeta de proyecto azul con etiqueta marcada y pequeña llave plateada.

Un traspaso completo debería evaluarse por la capacidad de otro equipo para instalar la aplicación, hacer un cambio concreto y desplegarla en pruebas. El código fuente es necesario. El intento independiente revela si también se ha transferido el conocimiento complementario.

Para el cliente, la pregunta práctica es cuánto sigue dependiendo de una persona o de un ordenador concreto. Un archivo descargable no lo aclara.

Un entorno limpio revela carencias

En un ejemplo ficticio, el nuevo equipo recibe la versión aprobada R-1 de un portal de pedidos. Todo arranca en el portátil anterior. En un sistema de prueba limpio faltan, sin embargo, la versión exacta del entorno de ejecución, la preparación de la base vacía y el significado de dos variables de entorno. El código ha llegado; parte de la instalación sigue sin aclararse.

Un documento general extenso puede dejar la misma carencia. Ayuda una guía que permita seguir los pasos realmente necesarios. Los principios Twelve-Factor separan configuración variable y código, y favorecen entornos de desarrollo y producción similares. Orientan, pero no constituyen un registro completo de traspaso para cualquier tecnología.

Un cambio pequeño como prueba

En el ejercicio, R-1 se instala con dependencias definidas. El equipo crea una base de prueba vacía, utiliza credenciales ficticias y completa el pedido T-31. Las claves de producción no deben incluirse en el repositorio ni en las instrucciones.

Después cambia la etiqueta «Referencia» por «Referencia del cliente», vuelve a compilar y despliega en pruebas. Por último, restaura la versión anterior. La intervención comprueba si instalación, cambio, despliegue y reversión se entienden conjuntamente. No demuestra dominio de todas las funciones futuras.

Si el equipo anterior tiene que aportar pasos que faltan, incorpórelos al traspaso y pruébelos de nuevo. Una explicación oral resuelve el momento; la carencia queda resuelta de forma duradera cuando el conocimiento sigue disponible para el siguiente intento.

Cuándo basta un alcance menor

En una ampliación limitada de una plataforma ya operada conjuntamente, entregar el código modificado puede ser un paso intermedio útil. Crear todo un entorno operativo nuevo podría ser desproporcionado. Debe quedar claro qué conocimientos y accesos existen y quién sigue siendo responsable.

También son válidos servicios simulados si el ejercicio no debe usar integraciones reales. Indique qué parte queda sin probar. Un pago simulado no demuestra una conexión de producción operativa.

Para un cambio completo de equipo, el ejercicio independiente es un criterio más sólido. Hace visible el trabajo restante antes de que el contacto anterior deje de estar disponible. El registro de aceptación debería indicar versión, proceso completado y dependencias abiertas.

Fuentes

Escrito por

  • Katharina WeberRedactora de software y tecnologíaKatharina Weber se encarga en ASES de los artículos sobre desarrollo de software. Escribe sobre las cuestiones que se plantean las empresas al elegir software, desarrollar nuevas aplicaciones y modernizar sus sistemas existentes.

Seguir a ASES

Seguir leyendo

Todos los artículos

Desarrollo de software con ASES

Software a medida, aplicaciones web y móviles