¿De quién debería ser el código para el software que imprimes?

La pantalla de trabajo y el producto entregado no son lo mismo

Imagine que se ha desarrollado una aplicación de licitación para su empresa. Los empleados inician sesión, seleccionan productos y reciben un PDF. En términos de uso diario, puede parecer que el trabajo está hecho. Sin embargo, cuando el desarrollador que cambiará la tabla de precios se vaya, aún no se sabe si otro equipo podrá ejecutar la aplicación. La cuestión del código fuente cobra importancia en este punto. Discuta las posibilidades de usar la pantalla, cambiar el software y ejecutarlo en una ubicación diferente por separado al comienzo del proyecto. No los trate como envíos que significan lo mismo; Que quede claro qué expediente y qué documento se entregará para cada uno de ellos.

Este artículo no determina el resultado jurídico de un contrato. El alcance de los derechos se evalúa según el acuerdo, los componentes utilizados y la ley aplicable. Revisar las cláusulas del contrato con un experto legal cuando sea necesario. Lo único que se puede hacer técnicamente es traducir el resultado esperado en una lista comprensible. ¿Qué parte se desarrolló específicamente para usted, qué parte se utiliza como un servicio listo para usar y cuál se basa en una biblioteca de terceros? Sin esta distinción, puede resultar engañoso suponer que todo el código se entregará en las mismas condiciones.

Determina el modelo de entrega que necesitas

En un servicio de suscripción ya preparado, no se espera que el proveedor entregue el código fuente. En cambio, se evalúa la exportación de datos, el acceso cuando finaliza el servicio y las posibilidades de integración. En una aplicación específica para usted, se puede solicitar que se incluyan en el alcance de entrega el tanque de soldadura, la descripción de la instalación y las condiciones de modificación. Ambos modelos cumplen diferentes requisitos. No tome su decisión basándose únicamente en el precio inicial. Si la aplicación ejecuta el negocio principal de la empresa, la necesidad de poder continuar con otro proveedor puede ser más evidente.

La entrega solicitada debe ser compatible con el alcance del proyecto. Por ejemplo, cuando obtiene las pantallas de la aplicación escritas para usted, no puede utilizar el software interno del servicio en la nube. Sin embargo, es posible que desee que documente qué datos se enviaron a ese servicio y cómo se estableció la conexión. En lugar de suponer que una entrega que no está incluida en la oferta se realizará automáticamente más adelante, aclare la cuestión por escrito.

¿Qué información debe incluirse junto al código?

Tener los archivos fuente en una carpeta es un buen comienzo; por sí solo no es suficiente para una entrega sostenible. ¿Qué versión del código está activa, qué herramienta de desarrollo se utiliza y cómo se solucionan las versiones de dependencia? Se deben documentar los nombres de las variables de configuración, sus valores de instancia y el método seguro de aprovisionamiento. Las contraseñas o claves reales no deben colocarse en el repositorio de códigos. El nuevo equipo debería poder instalar la aplicación adquiriendo los secretos en un proceso autorizado e independiente. Escribir claramente información confidencial sobre el entorno de producción en el documento de entrega no facilita la entrega; crea un nuevo riesgo.

La estructura de la base de datos, los pasos de instalación, los datos de prueba de muestra y las instrucciones de recuperación de la copia de seguridad también deben incluirse en el paquete. Guarde tareas programadas, conexiones de servicios externos y ubicaciones de almacenamiento de archivos. Este requisito debe conocerse si un informe se genera únicamente con la fuente en un servidor en particular. Describa también los roles de usuario y las acciones que puede realizar el administrador. Estos documentos no tienen que describir todos los detalles de la solicitud en un libro extenso; Debe proporcionar información completa para que el nuevo equipo opere el sistema de manera segura.

Dependencias y términos de uso separados

La aplicación puede utilizar una biblioteca de código abierto, un componente pago o un módulo compartido del proveedor. Sus condiciones de uso no son las mismas. Mantenga un inventario del nombre del componente, la versión, la fuente de la licencia y el requisito de renovación. Si un componente pago está registrado en la cuenta del desarrollador, pregunte con anticipación cómo usarlo en el nuevo equipo. La compra no significa necesariamente una transferencia o uso ilimitado en todos los entornos. Verifique la condición relevante en el documento de licencia real; No tomes una decisión basada en una suposición general.

Mantener el repositorio de códigos en una cuenta comercial puede facilitar el acceso; La propiedad de una cuenta por sí sola no explica todos los derechos de uso. Qué aportaciones entrega el promotor y qué límites existen deben verse en el contrato. Del mismo modo, la propiedad de los datos y la capacidad de migrarlos deben manejarse por separado del código. Si no puede exportar registros de clientes al pasar a un nuevo equipo, es posible que tenga problemas para migrar incluso si se ha entregado el código. Transferencia de datos entre sistemas así que inclúyelo en el plan de entrega.

Verificar la entrega con una pequeña prueba de aceptación

Al final del proyecto, configure un entorno de prueba limpio en lugar de simplemente contar archivos. Ejecute la aplicación utilizando el documento de entrega, inicie sesión con el usuario de muestra y complete una operación básica. Luego restaure la copia de seguridad y exporte los datos de muestra. Si se requiere algún paso durante el proceso que no está incluido en el documento, agréguelo. Realice pruebas sin difundir datos de producción y sin modificar el sistema en vivo. Por lo tanto, la diferencia entre el archivo que se entrega y la entrega que se puede utilizar es claramente visible.

Mantenga la dirección del repositorio, la versión de entrega, la receta de instalación, el inventario de dependencias, la exportación de datos, el mantenedor y los pasos de separación juntos en la lista de verificación final. Esta lista se actualizará cuando se realicen cambios. El objetivo no es utilizar el mismo contrato en todos los proyectos, sino definir la entrega que sustentará su negocio. Cuando el modelo, la oferta y el registro de aceptación discutidos al principio coinciden, el cambio de proveedor se convierte en una tarea técnica más comprensible.

Preguntas frecuentes

¿Es suficiente obtener el código fuente solo?

No. También se requieren documentación de instalación, dependencias, términos de uso adecuados y verificación de funcionamiento en un entorno limpio.

¿Se espera la entrega de código en cada software?

El modelo de entrega del servicio de suscripción listo para usar y el software desarrollado específicamente para usted pueden ser diferentes. Definir claramente el modelo y alcance en el contrato.

¿Cómo probar el cambio de proveedor?

Incluir en las pruebas de aceptación que un nuevo equipo autorizado configure el entorno de prueba con el paquete de entrega y exporte los datos de muestra.