¿Cuáles son los puntos clave a revisar en los contratos de desarrollo de sistemas basados en proyectos?

El Ministerio de Economía, Comercio e Industria de Japón ha presentado cláusulas modelo para contratos de desarrollo de sistemas IT en sus “Directrices para mejorar la confiabilidad de los sistemas de información”. Con la expansión de Internet, los efectos sociales de las interrupciones o disminuciones en la funcionalidad de los servicios y operaciones debido a fallos en los sistemas de información se están volviendo cada vez más graves. Mientras que la mejora de la confiabilidad y seguridad de los sistemas se ha convertido en una cuestión urgente, los contratos de desarrollo de sistemas IT tienden a ser opacos en cuanto a su contenido. Estas cláusulas buscan hacer visible este contenido y clarificar la distribución de roles y relaciones de responsabilidad. En este artículo, explicaremos los puntos a tener en cuenta en los contratos de desarrollo de sistemas IT, citando las cláusulas del contrato modelo del Ministerio de Economía, Comercio e Industria de Japón.

Desarrollo de sistemas y contratos de subcontratación

¿Qué es un contrato de subcontratación?

Un contrato de subcontratación se define en el Código Civil japonés de la siguiente manera:

Artículo 632
La subcontratación tiene efecto cuando una de las partes se compromete a completar un trabajo y la otra parte se compromete a pagar por el resultado de ese trabajo.

En un contrato de subcontratación, es un requisito que se acuerde “completar un trabajo”. Por ejemplo, si el objetivo del contrato es crear un sistema específico para una fecha determinada, la obligación del proveedor es “completar el sistema para la fecha acordada”. Si no se puede completar el sistema para la fecha prometida, se puede imponer la responsabilidad por incumplimiento de contrato debido a un retraso en el cumplimiento. Sin embargo, si se encuentra un defecto después de que se ha completado y entregado el sistema para la fecha límite, la obligación del proveedor ya se ha cumplido, por lo que el incumplimiento del contrato no es un problema y se convierte en un problema de responsabilidad por defectos.

Diferencias con el contrato de mandato

En un contrato de subcontratación, el proveedor tiene la obligación de completar el trabajo, por lo que si el producto entregado tiene defectos, tiene la responsabilidad de garantizar contra defectos. Por otro lado, en un contrato de mandato, no hay obligación de completar el trabajo, por lo que no se asume la responsabilidad de garantizar contra defectos como en un contrato de subcontratación. Sin embargo, si se reconoce la obligación de diligencia en el proceso de manejo de asuntos, puede haber una responsabilidad por incumplimiento de contrato por daños y perjuicios.

Modelo de Cláusulas Contractuales y Puntos de Verificación

Servicios de apoyo para la creación de definiciones de requisitos

La definición de requisitos es el proceso de recopilación de las especificaciones de demanda del sistema que el usuario intenta construir. En la etapa de definición de requisitos, se considera la dirección de la construcción del sistema y se decide qué tipo de sistema se construirá. Dado que no se puede prever concretamente el producto final, el contrato modelo del Ministerio de Economía, Comercio e Industria japonés (Japanese Ministry of Economy, Trade and Industry) lo establece como un tipo de mandato cuasi.

Creación de Documentos de Diseño Externo

(Implementación de la creación de documentos de diseño externo)
Artículo X: El segundo partido, tras la firma del contrato individual especificado en el artículo X, llevará a cabo la creación de documentos de diseño externo para el software en cuestión, basándose en los documentos de definición de requisitos confirmados según las disposiciones del artículo X.

2. Al implementar la creación de documentos de diseño externo, el segundo partido puede solicitar la cooperación necesaria al primer partido, y el primer partido debe responder a esta solicitud de manera oportuna.

La creación de documentos de diseño externo es una tarea que establece el uso de partes relacionadas con la interfaz, como pantallas e informes. Los documentos de diseño externo deben contener toda la información necesaria para que el proveedor pueda desarrollar el programa basándose en ellos. Aunque los documentos de diseño externo incluyen detalles sobre el uso de formatos, el lado del usuario que determina el contenido del trabajo puede cambiar los requisitos especificados. Sin embargo, si los documentos de definición de requisitos, que son el resultado de la fase previa a la creación de documentos de diseño externo, definen claramente las necesidades del usuario y el contenido del trabajo que el proveedor debe completar, es posible firmar un contrato en el que el proveedor sea el principal responsable de la creación de los documentos de diseño externo.

El primer párrafo establece que el proveedor es el principal responsable de la ejecución del trabajo, ya que este proceso es de tipo contractual. Sin embargo, incluso en un contrato de tipo contractual, dado que el diseño externo tiene mucho que ver con la determinación del contenido del trabajo del usuario, se requiere la participación activa del usuario. Por lo tanto, el segundo párrafo aclara que el proveedor puede solicitar la cooperación necesaria del usuario para discutir y decidir las especificaciones del sistema, y que el usuario debe responder a esta solicitud de manera oportuna, lo que indica que la discusión de las especificaciones del sistema es un trabajo conjunto entre el proveedor y el usuario.

(Firma del contrato individual relacionado con la creación de documentos de diseño externo)
Artículo X: El primer y segundo partido decidirán, tras la discusión, las condiciones de transacción especificadas en el artículo X, y firmarán un contrato individual relacionado con la creación de documentos de diseño externo.

El alcance de la creación de documentos de diseño externo se determinará en un contrato individual de acuerdo con las condiciones de transacción establecidas en el artículo anterior.

(Reunión de discusión de diseño externo)
Artículo X: El segundo partido celebrará, con la frecuencia que considere necesaria, una reunión de discusión de diseño externo (en adelante, “reunión de discusión” en esta sección) para aclarar o confirmar los asuntos necesarios para la creación de documentos de diseño externo, según lo especificado en el artículo X, y el primer partido participará en ella.

2. El primer partido también puede celebrar una reunión de discusión si considera que es necesario para la creación de documentos de diseño externo, y el segundo partido participará en ella.

3. Si el primer partido desea cambiar el contenido de los documentos de definición de requisitos a través de la discusión en la reunión de discusión y esto requiere cambiar las condiciones del contrato individual, como el período de trabajo y la tarifa de comisión, se seguirá el procedimiento especificado en el artículo 33 (cambio del contenido de este contrato y del contrato individual).

La colaboración entre el usuario y el proveedor es esencial para la creación de documentos de diseño externo, que determina la interfaz, como las pantallas y los informes. Como este proceso es de tipo contractual, el primer párrafo establece que el proveedor organizará la reunión de discusión y el usuario participará en ella. Todos los asuntos necesarios para la creación de documentos de diseño externo, como la aclaración o confirmación de los contenidos, se tratarán en la reunión de discusión, y tanto el proveedor como el usuario estarán vinculados por los resultados de la discusión en la reunión.

El segundo párrafo establece que el usuario también puede organizar una reunión de discusión si considera que es necesario para la implementación de la creación de documentos de diseño externo.
El tercer párrafo establece que si el usuario desea cambiar el contenido de los documentos de definición de requisitos a través de la discusión en la reunión de discusión y esto requiere cambiar las condiciones del contrato individual, como el período de trabajo y la tarifa de comisión, se seguirá el procedimiento especificado en otro artículo.

(Entrega de documentos de diseño externo)
Artículo X: El segundo partido entregará al primer partido los documentos de diseño externo y la solicitud de aceptación de los documentos de diseño externo (también conocida como nota de entrega) antes de la fecha especificada en el contrato individual.

Como este proceso es de tipo contractual, el proveedor entregará los documentos de diseño externo, etc., como productos finales.

2. Si el primer partido no presenta ninguna objeción con una razón específica por escrito durante el período de revisión de los documentos de diseño externo, se considerará que el primer partido ha aprobado los documentos de diseño externo al final del período de revisión.

3. Los documentos de diseño externo se considerarán confirmados con la aprobación del primer partido según los dos párrafos anteriores.

En el proceso de diseño externo, se confirman los requisitos necesarios para la creación de documentos de diseño interno, etc., pero si la confirmación de los requisitos es ambigua, pueden surgir problemas en el desarrollo posterior. Este artículo establece el procedimiento para que el usuario revise los documentos de diseño externo, que son la base para el trabajo de desarrollo posterior, y los confirme con su aprobación.

El primer párrafo establece que el usuario revisará si los documentos de diseño externo son consistentes con los documentos de definición de requisitos confirmados en otro artículo y con los resultados de la discusión en la reunión de discusión de diseño externo, y si no contienen errores lógicos. También puede haber casos en los que se decida que es necesario corregir los documentos durante la revisión para la aprobación, y la cláusula de excepción en este párrafo establece el procedimiento para estos casos.
El segundo párrafo es una disposición que considera que el usuario ha aprobado los documentos de diseño externo si no presenta ninguna objeción con una razón específica por escrito durante el período de revisión de los documentos de diseño externo. El propósito de este párrafo es prevenir problemas que puedan surgir más adelante si se entra en el diseño interno mientras la aprobación del usuario sigue siendo ambigua.

Y el tercer párrafo establece que los documentos de diseño externo se considerarán confirmados con la aprobación del usuario.

(Responsabilidad por defectos)
Artículo X: Si se descubre una discrepancia entre los documentos de diseño externo y los documentos de definición de requisitos o los asuntos decididos en la reunión de discusión de diseño externo especificada en el artículo X, o un error lógico (en adelante, “defecto” en este artículo) después de la confirmación en el artículo anterior, el primer partido puede solicitar al segundo partido que corrija dicho defecto, y el segundo partido deberá corregirlo. Sin embargo, el segundo partido sólo será responsable de dicha corrección si el primer partido hace la solicitud dentro de los X meses siguientes a la confirmación en el artículo anterior.

2. A pesar del párrafo anterior, si el defecto es menor y la corrección de los documentos de diseño externo requeriría un costo excesivo, el segundo partido no estará obligado a corregirlo.

3. Las disposiciones del primer párrafo no se aplicarán si el defecto se debe a los documentos proporcionados por el primer partido o a las instrucciones dadas por él. Sin embargo, esto no se aplicará si el segundo partido no informó de que los documentos o instrucciones eran inapropiados a pesar de saberlo.

Este artículo establece la responsabilidad por defectos en los documentos de diseño externo. El período de garantía por defectos se determinará en función del tamaño del sistema de información, el precio, etc., y se considerará un período razonable acordado entre las partes.

El primer párrafo define como defecto la discrepancia entre los documentos de diseño externo y los documentos de definición de requisitos o los asuntos decididos en la reunión de discusión de diseño externo, o un error lógico en los documentos de diseño externo.

El segundo párrafo protege al proveedor al establecer que, aunque el defecto sea menor, si la corrección de los documentos de diseño externo requeriría un costo excesivo, el proveedor no estará obligado a corregirlo, de acuerdo con el artículo 634, párrafo 1, de la Ley Civil.

El tercer párrafo establece que, de acuerdo con el artículo 636 de la Ley Civil, si el defecto se debe a las instrucciones o documentos proporcionados por el usuario, el proveedor no estará exento de la responsabilidad de garantía a menos que haya señalado que las instrucciones o documentos eran inapropiados a pesar de saberlo.

Por favor, tenga en cuenta que la responsabilidad por defectos es una disposición opcional, por lo que si no se establece tal disposición, se aplicarán los principios generales de la Ley Civil. La responsabilidad por defectos es un área que se verá muy afectada por la revisión de la Ley Civil que entrará en vigor en abril de 2020, por lo que después de la entrada en vigor de la Ley Civil revisada, la forma de manejarla cambiará.

Servicios de Desarrollo de Software

(Implementación de los servicios de desarrollo de software)
Artículo X: El contratista, tras la firma del contrato individual especificado en el artículo 25, llevará a cabo los servicios de desarrollo de software, desde el diseño interno hasta las pruebas del sistema, basándose en las especificaciones del sistema confirmadas por las secciones anteriores.

2. Al implementar los servicios de desarrollo de software, el contratista puede solicitar la cooperación necesaria al cliente, y el cliente debe responder a esta solicitud de manera oportuna.

En lo que sigue, se establecen las cláusulas para el caso en que un proveedor realice el desarrollo de software bajo contrato. En la etapa de diseño interno del sistema, es común que el objeto de desarrollo y las especificaciones se hayan definido en las etapas anteriores, por lo que el contrato modelo del Ministerio de Economía, Comercio e Industria de Japón lo establece como un contrato de obra.

(Firma del contrato individual relacionado con los servicios de desarrollo de software)
Artículo X: El cliente y el contratista determinarán las condiciones de transacción especificadas en el artículo X, párrafo X, tras las negociaciones, y firmarán un contrato individual relacionado con los servicios de desarrollo de software.

El alcance de los servicios de desarrollo de software se determinará en un contrato individual, de acuerdo con las condiciones de transacción establecidas anteriormente.

(Entrega de los productos)
Artículo X: El contratista entregará al cliente los productos especificados en el contrato individual, junto con el formulario de solicitud de aceptación (también conocido como factura), antes de la fecha límite establecida en el contrato individual.
2. Cuando se realice la entrega, el cliente realizará la inspección de acuerdo con las especificaciones de inspección del artículo siguiente, de acuerdo con las disposiciones del artículo X (Aceptación del software en cuestión).
3. Al entregar los productos, el contratista puede solicitar la cooperación necesaria al cliente, y el cliente debe responder a esta solicitud de manera oportuna.
4. El riesgo de pérdida o daño de los productos será asumido por el contratista antes de la entrega, y por el cliente después de la entrega.

Dado que este proceso es un contrato de obra, se entregará el software terminado como un producto sujeto a inspección. El primer párrafo establece que los productos se entregarán junto con el formulario de solicitud de aceptación (también conocido como factura).

El segundo párrafo establece la implementación de la inspección por parte del usuario.
El tercer párrafo establece la obligación de cooperación del usuario en el caso de la entrega al lugar especificado en el contrato individual, ya que puede haber casos en los que se requiera la cooperación del usuario (por ejemplo, cuando se entrega en la oficina del usuario, o cuando se entrega en un estado operativo en el entorno de operación real del usuario).
El cuarto párrafo es una cláusula sobre el riesgo de pérdida o daño de los productos, y divide el momento de la transferencia del riesgo según la transferencia del control físico.

(Aceptación del software en cuestión)
Artículo X: En cuanto al software en cuestión entre los productos entregados, el cliente debe inspeccionarlo dentro del período especificado en el contrato individual (en adelante, “período de inspección”) de acuerdo con las especificaciones de inspección del artículo anterior, y verificar si las especificaciones del sistema y el software en cuestión coinciden.

2. Si el software en cuestión cumple con la inspección del párrafo anterior, el cliente debe firmar y sellar el certificado de aprobación de la inspección y entregarlo al contratista. Además, si el software en cuestión no pasa la inspección del párrafo anterior, el cliente debe entregar rápidamente al contratista un documento que explique las razones específicas por las que no pasó, y solicitar correcciones o complementos. Cuando se reconozcan las razones de la no aprobación, el contratista deberá corregirlo sin cargo dentro del plazo acordado tras las negociaciones y entregarlo al cliente, y el cliente deberá realizar nuevamente la inspección especificada en el párrafo anterior en la medida necesaria.

3. Incluso si no se entrega el certificado de aprobación de la inspección, si el cliente no presenta objeciones con razones específicas por escrito durante el período de inspección, se considerará que el software en cuestión ha pasado la inspección especificada en este artículo.

4. La aceptación del software en cuestión se considerará completada con la aprobación de la inspección especificada en este artículo.

Dado que este proceso es un contrato de obra, este artículo establece el procedimiento para la aceptación del software entregado.

El primer párrafo establece que el cliente debe inspeccionar el software en cuestión dentro del período de inspección, de acuerdo con las especificaciones de inspección, y verificar si las especificaciones del sistema y el software en cuestión coinciden.
El segundo párrafo obliga al proveedor a corregir y entregar una versión corregida al usuario si se descubre que el software en cuestión no cumple con las especificaciones del sistema.
El tercer párrafo es una disposición que previene la prolongación de la aceptación debido a la conveniencia del usuario, estableciendo una aceptación de inspección presunta.
El cuarto párrafo especifica claramente que la aceptación del software en cuestión se considera completa con la aprobación de la inspección.

(Responsabilidad por defectos)
Artículo X: Después de la inspección completa del artículo anterior, si se descubre una discrepancia (incluyendo errores, en adelante “defectos”) entre los productos y las especificaciones del sistema, el cliente puede solicitar al contratista que corrija dicho defecto, y el contratista deberá corregir dicho defecto. Sin embargo, el contratista sólo será responsable de dicha corrección si la solicitud se hace dentro de los X meses siguientes a la finalización de la aceptación del artículo anterior.
2. Sin perjuicio de lo dispuesto en el párrafo anterior, si el defecto es menor y la corrección del producto requiere un costo excesivo, el contratista no estará obligado a corregirlo según lo dispuesto en el párrafo anterior.
3. Las disposiciones del párrafo 1 no se aplicarán si el defecto se debe a los documentos proporcionados por el cliente o a las instrucciones dadas por el cliente. Sin embargo, esto no se aplicará si el contratista no informa de que dichos documentos o instrucciones son inapropiados a pesar de saberlo.

Dado que este proceso es un contrato de obra, este artículo establece la responsabilidad por defectos de los productos. La frontera entre la responsabilidad por incumplimiento de la obligación cuando no se ha realizado el cumplimiento (el trabajo no está terminado) y la responsabilidad por defectos después de que se ha completado el cumplimiento (el trabajo está terminado) es difícil de determinar en la práctica. Hay un precedente judicial (Sentencia del Tribunal de Distrito de Tokio del 22 de abril del año 14 de la era Heisei (2002)) que sostiene que si un sistema se considera terminado o no en el desarrollo de sistemas debe basarse en si el trabajo ha terminado hasta la última etapa prevista en el contrato original. Si se descubre un defecto después de la entrega y la aprobación de la inspección del software, en principio se aplicará la responsabilidad por defectos.

El primer párrafo define como “defecto” la “discrepancia con las especificaciones del sistema” que se produce en los servicios de desarrollo de software. Los defectos como la falta de funciones que se producen en la etapa de diseño externo se determinarán no por este artículo, sino por las disposiciones sobre la responsabilidad por defectos en la etapa de diseño externo, etc. El período de garantía de defectos se determinará como un período razonable mediante negociaciones entre las partes, teniendo en cuenta la escala del sistema de información y la remuneración, etc.

El segundo párrafo establece una disposición similar a la del artículo 634, párrafo 1, de la Ley Civil, que establece que si el defecto es menor y la corrección del producto requiere un costo excesivo, el proveedor no está obligado a corregirlo gratuitamente.

El tercer párrafo es una disposición similar a la del artículo 636 de la Ley Civil, que establece que el proveedor no es responsable de la garantía si el defecto se debe a las instrucciones o documentos proporcionados por el usuario, pero si el proveedor no señala que dichos documentos o instrucciones son inapropiados a pesar de saberlo, no estará exento de la responsabilidad de la garantía.

Asistencia en la Preparación y Transición de la Operación del Software

En la etapa de aceptación e implementación del sistema, es común que el usuario tome la iniciativa. Por lo tanto, en el contrato modelo del Ministerio de Economía, Comercio e Industria japonés (METI), se establece que el usuario es el principal actor y el proveedor lo apoya en una forma semi-delegada.

Determinación de la naturaleza del contrato

Para determinar la naturaleza de un contrato, se debe examinar el contrato en su totalidad y considerar si su propósito es “proporcionar un producto finalizado” o si el proveedor tiene la obligación de “realizar su trabajo de manera razonable”. Un indicador general sería si el contenido del producto final a completar se ha definido con cierto grado de especificidad y si el proyecto ha avanzado hacia ese objetivo.