\n(Implementaci\u00f3n de la creaci\u00f3n de documentos de dise\u00f1o externo)<\/strong>2. Al implementar la creaci\u00f3n de documentos de dise\u00f1o externo, el segundo partido puede solicitar la cooperaci\u00f3n necesaria al primer partido, y el primer partido debe responder a esta solicitud de manera oportuna.<\/p>\n<\/blockquote>\n\n\n\n
La creaci\u00f3n de documentos de dise\u00f1o externo es una tarea que establece el uso de partes relacionadas con la interfaz, como pantallas e informes. Los documentos de dise\u00f1o externo deben contener toda la informaci\u00f3n necesaria para que el proveedor pueda desarrollar el programa bas\u00e1ndose en ellos. Aunque los documentos de dise\u00f1o 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\u00f3n de requisitos, que son el resultado de la fase previa a la creaci\u00f3n de documentos de dise\u00f1o 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\u00f3n de los documentos de dise\u00f1o externo.<\/p>\n\n\n\n
El primer p\u00e1rrafo establece que el proveedor es el principal responsable de la ejecuci\u00f3n del trabajo, ya que este proceso es de tipo contractual. Sin embargo, incluso en un contrato de tipo contractual, dado que el dise\u00f1o externo tiene mucho que ver con la determinaci\u00f3n del contenido del trabajo del usuario, se requiere la participaci\u00f3n activa del usuario. Por lo tanto, el segundo p\u00e1rrafo aclara que el proveedor puede solicitar la cooperaci\u00f3n 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\u00f3n de las especificaciones del sistema es un trabajo conjunto entre el proveedor y el usuario.<\/p>\n\n\n\n
\n(Firma del contrato individual relacionado con la creaci\u00f3n de documentos de dise\u00f1o externo)<\/strong>El alcance de la creaci\u00f3n de documentos de dise\u00f1o externo se determinar\u00e1 en un contrato individual de acuerdo con las condiciones de transacci\u00f3n establecidas en el art\u00edculo anterior.<\/p>\n\n\n\n
\n(Reuni\u00f3n de discusi\u00f3n de dise\u00f1o externo)<\/strong>2. El primer partido tambi\u00e9n puede celebrar una reuni\u00f3n de discusi\u00f3n si considera que es necesario para la creaci\u00f3n de documentos de dise\u00f1o externo, y el segundo partido participar\u00e1 en ella.<\/p>\n\n\n\n
3. Si el primer partido desea cambiar el contenido de los documentos de definici\u00f3n de requisitos a trav\u00e9s de la discusi\u00f3n en la reuni\u00f3n de discusi\u00f3n y esto requiere cambiar las condiciones del contrato individual, como el per\u00edodo de trabajo y la tarifa de comisi\u00f3n, se seguir\u00e1 el procedimiento especificado en el art\u00edculo 33 (cambio del contenido de este contrato y del contrato individual).<\/p>\n<\/blockquote>\n\n\n\n
La colaboraci\u00f3n entre el usuario y el proveedor es esencial para la creaci\u00f3n de documentos de dise\u00f1o externo, que determina la interfaz, como las pantallas y los informes. Como este proceso es de tipo contractual, el primer p\u00e1rrafo establece que el proveedor organizar\u00e1 la reuni\u00f3n de discusi\u00f3n y el usuario participar\u00e1 en ella. Todos los asuntos necesarios para la creaci\u00f3n de documentos de dise\u00f1o externo, como la aclaraci\u00f3n o confirmaci\u00f3n de los contenidos, se tratar\u00e1n en la reuni\u00f3n de discusi\u00f3n, y tanto el proveedor como el usuario estar\u00e1n vinculados por los resultados de la discusi\u00f3n en la reuni\u00f3n.<\/p>\n\n\n\n
El segundo p\u00e1rrafo establece que el usuario tambi\u00e9n puede organizar una reuni\u00f3n de discusi\u00f3n si considera que es necesario para la implementaci\u00f3n de la creaci\u00f3n de documentos de dise\u00f1o externo.
\n(Entrega de documentos de dise\u00f1o externo)<\/strong>Como este proceso es de tipo contractual, el proveedor entregar\u00e1 los documentos de dise\u00f1o externo, etc., como productos finales.<\/p>\n\n\n\n
\n2. Si el primer partido no presenta ninguna objeci\u00f3n con una raz\u00f3n espec\u00edfica por escrito durante el per\u00edodo de revisi\u00f3n de los documentos de dise\u00f1o externo, se considerar\u00e1 que el primer partido ha aprobado los documentos de dise\u00f1o externo al final del per\u00edodo de revisi\u00f3n.<\/p>\n\n\n\n
3. Los documentos de dise\u00f1o externo se considerar\u00e1n confirmados con la aprobaci\u00f3n del primer partido seg\u00fan los dos p\u00e1rrafos anteriores.<\/p>\n<\/blockquote>\n\n\n\n
En el proceso de dise\u00f1o externo, se confirman los requisitos necesarios para la creaci\u00f3n de documentos de dise\u00f1o interno, etc., pero si la confirmaci\u00f3n de los requisitos es ambigua, pueden surgir problemas en el desarrollo posterior. Este art\u00edculo establece el procedimiento para que el usuario revise los documentos de dise\u00f1o externo, que son la base para el trabajo de desarrollo posterior, y los confirme con su aprobaci\u00f3n.<\/p>\n\n\n\n
El primer p\u00e1rrafo establece que el usuario revisar\u00e1 si los documentos de dise\u00f1o externo son consistentes con los documentos de definici\u00f3n de requisitos confirmados en otro art\u00edculo y con los resultados de la discusi\u00f3n en la reuni\u00f3n de discusi\u00f3n de dise\u00f1o externo, y si no contienen errores l\u00f3gicos. Tambi\u00e9n puede haber casos en los que se decida que es necesario corregir los documentos durante la revisi\u00f3n para la aprobaci\u00f3n, y la cl\u00e1usula de excepci\u00f3n en este p\u00e1rrafo establece el procedimiento para estos casos.
Y el tercer p\u00e1rrafo establece que los documentos de dise\u00f1o externo se considerar\u00e1n confirmados con la aprobaci\u00f3n del usuario.<\/p>\n\n\n\n
\n(Responsabilidad por defectos)<\/strong>2. A pesar del p\u00e1rrafo anterior, si el defecto es menor y la correcci\u00f3n de los documentos de dise\u00f1o externo requerir\u00eda un costo excesivo, el segundo partido no estar\u00e1 obligado a corregirlo.<\/p>\n\n\n\n
3. Las disposiciones del primer p\u00e1rrafo no se aplicar\u00e1n si el defecto se debe a los documentos proporcionados por el primer partido o a las instrucciones dadas por \u00e9l. Sin embargo, esto no se aplicar\u00e1 si el segundo partido no inform\u00f3 de que los documentos o instrucciones eran inapropiados a pesar de saberlo.<\/p>\n<\/blockquote>\n\n\n\n
Este art\u00edculo establece la responsabilidad por defectos en los documentos de dise\u00f1o externo. El per\u00edodo de garant\u00eda por defectos se determinar\u00e1 en funci\u00f3n del tama\u00f1o del sistema de informaci\u00f3n, el precio, etc., y se considerar\u00e1 un per\u00edodo razonable acordado entre las partes.<\/p>\n\n\n\n
El primer p\u00e1rrafo define como defecto la discrepancia entre los documentos de dise\u00f1o externo y los documentos de definici\u00f3n de requisitos o los asuntos decididos en la reuni\u00f3n de discusi\u00f3n de dise\u00f1o externo, o un error l\u00f3gico en los documentos de dise\u00f1o externo.<\/p>\n\n\n\n
El segundo p\u00e1rrafo protege al proveedor al establecer que, aunque el defecto sea menor, si la correcci\u00f3n de los documentos de dise\u00f1o externo requerir\u00eda un costo excesivo, el proveedor no estar\u00e1 obligado a corregirlo, de acuerdo con el art\u00edculo 634, p\u00e1rrafo 1, de la Ley Civil.<\/p>\n\n\n\n
El tercer p\u00e1rrafo establece que, de acuerdo con el art\u00edculo 636 de la Ley Civil, si el defecto se debe a las instrucciones o documentos proporcionados por el usuario, el proveedor no estar\u00e1 exento de la responsabilidad de garant\u00eda a menos que haya se\u00f1alado que las instrucciones o documentos eran inapropiados a pesar de saberlo.<\/p>\n\n\n\n
Por favor, tenga en cuenta que la responsabilidad por defectos es una disposici\u00f3n opcional, por lo que si no se establece tal disposici\u00f3n, se aplicar\u00e1n los principios generales de la Ley Civil. La responsabilidad por defectos es un \u00e1rea que se ver\u00e1 muy afectada por la revisi\u00f3n de la Ley Civil que entrar\u00e1 en vigor en abril de 2020, por lo que despu\u00e9s de la entrada en vigor de la Ley Civil revisada, la forma de manejarla cambiar\u00e1.<\/p>\n\n\n\n
<\/span>Servicios de Desarrollo de Software<\/span><\/h3>\n\n\n\nEn lo que sigue, se establecen las cl\u00e1usulas para el caso en que un proveedor realice el desarrollo de software bajo contrato. <\/figcaption><\/figure>\n\n\n\n\n(Implementaci\u00f3n de los servicios de desarrollo de software)<\/strong>2. Al implementar los servicios de desarrollo de software, el contratista puede solicitar la cooperaci\u00f3n necesaria al cliente, y el cliente debe responder a esta solicitud de manera oportuna.<\/p>\n<\/blockquote>\n\n\n\n
En lo que sigue, se establecen las cl\u00e1usulas para el caso en que un proveedor realice el desarrollo de software bajo contrato. En la etapa de dise\u00f1o interno del sistema, es com\u00fan 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\u00eda, Comercio e Industria de Jap\u00f3n lo establece como un contrato de obra.<\/p>\n\n\n\n
\n(Firma del contrato individual relacionado con los servicios de desarrollo de software)<\/strong>El alcance de los servicios de desarrollo de software se determinar\u00e1 en un contrato individual, de acuerdo con las condiciones de transacci\u00f3n establecidas anteriormente.<\/p>\n\n\n\n
\n(Entrega de los productos)<\/strong>Dado que este proceso es un contrato de obra, se entregar\u00e1 el software terminado como un producto sujeto a inspecci\u00f3n. El primer p\u00e1rrafo establece que los productos se entregar\u00e1n junto con el formulario de solicitud de aceptaci\u00f3n (tambi\u00e9n conocido como factura).<\/p>\n\n\n\n
El segundo p\u00e1rrafo establece la implementaci\u00f3n de la inspecci\u00f3n por parte del usuario.
\n(Aceptaci\u00f3n del software en cuesti\u00f3n)<\/strong>2. Si el software en cuesti\u00f3n cumple con la inspecci\u00f3n del p\u00e1rrafo anterior, el cliente debe firmar y sellar el certificado de aprobaci\u00f3n de la inspecci\u00f3n y entregarlo al contratista. Adem\u00e1s, si el software en cuesti\u00f3n no pasa la inspecci\u00f3n del p\u00e1rrafo anterior, el cliente debe entregar r\u00e1pidamente al contratista un documento que explique las razones espec\u00edficas por las que no pas\u00f3, y solicitar correcciones o complementos. Cuando se reconozcan las razones de la no aprobaci\u00f3n, el contratista deber\u00e1 corregirlo sin cargo dentro del plazo acordado tras las negociaciones y entregarlo al cliente, y el cliente deber\u00e1 realizar nuevamente la inspecci\u00f3n especificada en el p\u00e1rrafo anterior en la medida necesaria.<\/p>\n\n\n\n
3. Incluso si no se entrega el certificado de aprobaci\u00f3n de la inspecci\u00f3n, si el cliente no presenta objeciones con razones espec\u00edficas por escrito durante el per\u00edodo de inspecci\u00f3n, se considerar\u00e1 que el software en cuesti\u00f3n ha pasado la inspecci\u00f3n especificada en este art\u00edculo.<\/p>\n\n\n\n
4. La aceptaci\u00f3n del software en cuesti\u00f3n se considerar\u00e1 completada con la aprobaci\u00f3n de la inspecci\u00f3n especificada en este art\u00edculo. <\/p>\n<\/blockquote>\n\n\n\n
Dado que este proceso es un contrato de obra, este art\u00edculo establece el procedimiento para la aceptaci\u00f3n del software entregado.<\/p>\n\n\n\n
El primer p\u00e1rrafo establece que el cliente debe inspeccionar el software en cuesti\u00f3n dentro del per\u00edodo de inspecci\u00f3n, de acuerdo con las especificaciones de inspecci\u00f3n, y verificar si las especificaciones del sistema y el software en cuesti\u00f3n coinciden.
\n(Responsabilidad por defectos)<\/strong>Dado que este proceso es un contrato de obra, este art\u00edculo establece la responsabilidad por defectos de los productos. La frontera entre la responsabilidad por incumplimiento de la obligaci\u00f3n cuando no se ha realizado el cumplimiento (el trabajo no est\u00e1 terminado) y la responsabilidad por defectos despu\u00e9s de que se ha completado el cumplimiento (el trabajo est\u00e1 terminado) es dif\u00edcil de determinar en la pr\u00e1ctica. Hay un precedente judicial (Sentencia del Tribunal de Distrito de Tokio del 22 de abril del a\u00f1o 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 \u00faltima etapa prevista en el contrato original. Si se descubre un defecto despu\u00e9s de la entrega y la aprobaci\u00f3n de la inspecci\u00f3n del software, en principio se aplicar\u00e1 la responsabilidad por defectos.<\/p>\n\n\n\n
El primer p\u00e1rrafo 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\u00f1o externo se determinar\u00e1n no por este art\u00edculo, sino por las disposiciones sobre la responsabilidad por defectos en la etapa de dise\u00f1o externo, etc. El per\u00edodo de garant\u00eda de defectos se determinar\u00e1 como un per\u00edodo razonable mediante negociaciones entre las partes, teniendo en cuenta la escala del sistema de informaci\u00f3n y la remuneraci\u00f3n, etc.<\/p>\n\n\n\n
El segundo p\u00e1rrafo establece una disposici\u00f3n similar a la del art\u00edculo 634, p\u00e1rrafo 1, de la Ley Civil, que establece que si el defecto es menor y la correcci\u00f3n del producto requiere un costo excesivo, el proveedor no est\u00e1 obligado a corregirlo gratuitamente.<\/p>\n\n\n\n
El tercer p\u00e1rrafo es una disposici\u00f3n similar a la del art\u00edculo 636 de la Ley Civil, que establece que el proveedor no es responsable de la garant\u00eda si el defecto se debe a las instrucciones o documentos proporcionados por el usuario, pero si el proveedor no se\u00f1ala que dichos documentos o instrucciones son inapropiados a pesar de saberlo, no estar\u00e1 exento de la responsabilidad de la garant\u00eda.<\/p>\n\n\n\n
<\/span>Asistencia en la Preparaci\u00f3n y Transici\u00f3n de la Operaci\u00f3n del Software<\/span><\/h3>\n\n\n\nEn la etapa de aceptaci\u00f3n e implementaci\u00f3n del sistema, es com\u00fan que el usuario tome la iniciativa. Por lo tanto, en el contrato modelo del Ministerio de Econom\u00eda, Comercio e Industria japon\u00e9s (METI), se establece que el usuario es el principal actor y el proveedor lo apoya en una forma semi-delegada.<\/p>\n\n\n\n
<\/span>Determinaci\u00f3n de la naturaleza del contrato<\/span><\/h2>\n\n\n\nPara determinar la naturaleza de un contrato, se debe examinar el contrato en su totalidad y considerar si su prop\u00f3sito es “proporcionar un producto finalizado” o si el proveedor tiene la obligaci\u00f3n de “realizar su trabajo de manera razonable”. Un indicador general ser\u00eda 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.<\/p>\n","protected":false},"excerpt":{"rendered":"
El Ministerio de Econom\u00eda, Comercio e Industria de Jap\u00f3n ha presentado cl\u00e1usulas modelo para contratos de desarrollo de sistemas IT en sus “Directrices para mejorar la confiabilidad de los siste […]<\/p>\n","protected":false},"author":1,"featured_media":57328,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16],"tags":[19,31],"acf":[],"_links":{"self":[{"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/posts\/57200"}],"collection":[{"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/comments?post=57200"}],"version-history":[{"count":2,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/posts\/57200\/revisions"}],"predecessor-version":[{"id":57558,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/posts\/57200\/revisions\/57558"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/media\/57328"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/media?parent=57200"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/categories?post=57200"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/tags?post=57200"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}