¿Cuáles son los problemas legales relacionados con el servidor e infraestructura de desarrollo de sistemas?

En cierto sentido, los sistemas de TI que se utilizan en las empresas se crean mediante la elaboración de especificaciones y documentos de diseño, y la escritura de código fuente que corresponde a estos contenidos. Sin embargo, un sistema solo puede funcionar realmente si cuenta con una infraestructura física, es decir, una computadora. En este artículo, explicaremos los problemas legales que están estrechamente relacionados con el campo de la infraestructura en los proyectos de desarrollo de sistemas.

¿Qué es la infraestructura en los sistemas de TI?

Los técnicos que desarrollan sistemas se conocen como Ingenieros de Sistemas (SE, por sus siglas en inglés). Y los proyectos de desarrollo comienzan con procesos iniciales como la creación de especificaciones y documentos de diseño, seguidos por la implementación del programa y la realización de pruebas. Esto es, en términos generales, el flujo de trabajo. Sin embargo, se puede decir que un Ingeniero de Sistemas (SE) en un sentido amplio es un técnico que se encarga de todas las tareas necesarias para estos procesos, aunque dependiendo de la empresa o el lugar de trabajo, pueden diferenciar aún más los nombres según las tareas y áreas a cargo. El término “Ingeniero de Infraestructura” se refiere a los técnicos que, como parte de su trabajo en el desarrollo y operación de sistemas de TI, se encargan especialmente de preparar el entorno operativo físico de la computadora. Los sistemas de TI utilizados en empresas y lugares de trabajo son, en cierto sentido, construcciones abstractas compuestas por combinaciones de código fuente. Sin embargo, para que estos sistemas desempeñen el papel que se espera de ellos, es esencial construir un entorno alrededor de la infraestructura, incluyendo servidores y redes. El trabajo práctico de desarrollo de sistemas avanza sobre dos ruedas: la implementación del programa y el código fuente, y la preparación del entorno que soporta su funcionamiento. Se considera que esta perspectiva es importante para prevenir la aparición de problemas imprevistos.

Escenarios concretos en los que los problemas de infraestructura pueden incendiar un proyecto

En los proyectos de desarrollo de sistemas, es posible que se concentre demasiado en el diseño abstracto de programas y códigos fuente, descuidando la perspectiva del mantenimiento de la infraestructura. Sin embargo, si estos dos aspectos no están alineados, puede aumentar el riesgo de que el proyecto se incendie.

¿Cómo un error en el dimensionamiento del servidor puede provocar un conflicto?

Por ejemplo, después de que se haya completado toda la implementación y prueba del programa, puede suceder que la capacidad de procesamiento del servidor no sea suficiente y el sistema no pueda ser utilizado en la práctica. Este proceso de prever la carga que el sistema puede soportar en la fase de operación y realizar el mantenimiento de la infraestructura de acuerdo con la escala del sistema se llama “dimensionamiento”. Hay casos en los que un error en el dimensionamiento del servidor ha causado problemas y ha llevado a conflictos. (Aunque finalmente se resolvió mediante un acuerdo, este caso puede servir como referencia.) Para más detalles sobre cómo resolver conflictos entre las partes a través de un “acuerdo”, consulte el siguiente artículo.

https://monolith.law/corporate/disputes-related-to-system-development[ja]

El hecho de que el conflicto se resolviera mediante un acuerdo significa, en términos simples, que el conflicto se resolvió a través de una “discusión” entre las partes. Por lo tanto, a diferencia de cuando se dicta una sentencia en un tribunal, el contenido del acuerdo no se acumula como un precedente judicial y suele ser muy específico.

La esencia del caso es el alcance de la obligación del proveedor de responder a las especificaciones ambiguas

En última instancia, la esencia de estos conflictos puede ser “hasta qué punto el proveedor debe asumir la responsabilidad de los elementos que no están explícitamente especificados”. Teniendo en cuenta este punto, se pueden obtener muchas pistas del contenido del siguiente artículo.

https://monolith.law/corporate/system-development-specs-function[ja]

En el artículo anterior, se explica hasta qué punto el proveedor tiene la obligación de implementar elementos que no están especificados en las especificaciones. Aquí, se explica que la historia es muy diferente entre los elementos del “lado de la pantalla” que se pueden visualizar fácilmente en documentos como los de definición de requisitos y diseño básico (el llamado “front-end”) y los del “lado de la lógica” como la migración de datos (el llamado “back-end” o “base de datos”). En otras palabras, se puede pensar que los elementos del “lado de la pantalla”, que son fácilmente verificables en las especificaciones por el cliente/usuario (que normalmente no tiene conocimientos especializados sobre proyectos de desarrollo de sistemas), tienden a ser atribuidos al cliente/usuario. Por otro lado, los problemas del “lado de la lógica” tienden a ser atribuidos al proveedor. Teniendo en cuenta estos puntos, se puede pensar que los problemas de dimensionamiento del servidor, que son difíciles de reconocer a menos que se sea un experto en tecnología, tienden a ser atribuidos al proveedor. Por lo tanto, a menos que haya circunstancias activas para eximir al proveedor de su responsabilidad, se puede prever que el proveedor será desfavorecido si este punto se disputa seriamente en un juicio.

Medidas para prevenir problemas debido a errores en el dimensionamiento del servidor

Para prevenir los problemas mencionados anteriormente, es importante coordinar las tareas como la implementación del programa y la escritura del código fuente con la preparación del entorno de infraestructura. Las medidas concretas que se pueden considerar incluyen las siguientes:

Clarificar en el contrato quién es responsable del dimensionamiento del servidor

No solo en estos casos, sino que en muchos conflictos relacionados con proyectos de desarrollo de sistemas, a menudo se observa que el problema se origina en que no está claro quién es responsable entre el proveedor, que es un experto en desarrollo de sistemas, y el usuario, que conoce la situación interna de la empresa. Aunque es innecesario decir que la estrecha colaboración entre ambas partes es necesaria para el progreso fluido del proyecto, sería deseable aclarar tanto como sea posible el reparto de roles y el alcance de la responsabilidad en el contrato de antemano.

Concretar los requisitos de desarrollo y gestionar completamente los cambios

Además, si los requisitos funcionales que se deben lograr son ambiguos, el riesgo de conflictos aumenta. Esto tiene dos aspectos: la clarificación de las especificaciones en la fase de definición de requisitos iniciales y la gestión de cambios durante el proyecto. En cuanto a cómo manejar los cambios en las especificaciones durante el proyecto, se explica en detalle en el siguiente artículo.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

Elegir un modelo de desarrollo que se adapte a la naturaleza del proyecto

Además, aunque está profundamente relacionado con las dos medidas anteriores, es importante elegir un modelo de desarrollo adecuado para el proyecto de desarrollo de sistemas en función de su naturaleza y escala. En general, para el desarrollo de sistemas de cierta escala en los que el dimensionamiento del servidor puede ser importante, se considera que los beneficios de adoptar el modelo de cascada, que es adecuado para aclarar las especificaciones y el alcance de la responsabilidad, aumentan. En cuanto a la elección del modelo de desarrollo adecuado teniendo en cuenta la naturaleza del proyecto, se explica en detalle en el siguiente artículo.

https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]

Resumen

Los problemas que surgen de la preparación del entorno de infraestructura para el progreso fluido de los proyectos de desarrollo de sistemas son puntos que fácilmente pueden pasar desapercibidos. Se considera que prestar atención incluso a los problemas de infraestructura no es una carga pequeña para aquellos que no son expertos en tecnología. Sin embargo, las medidas preventivas para estos problemas pueden considerarse una extensión de medidas básicas como “clarificación de especificaciones / gestión rigurosa de cambios”, “clarificación de roles / alcance de responsabilidad”, y “selección de un modelo de desarrollo acorde al tamaño y presupuesto del proyecto”. Lo que las personas involucradas en los asuntos legales corporativos deben entender primero es que los fundamentos de la prevención legal pueden ser suficientemente aplicables incluso a los problemas de infraestructura. Además, si eres un ingeniero en IT, es importante entender que los problemas de infraestructura pueden convertirse en un riesgo grave de incendio para el proyecto y gestionar eficazmente las operaciones.