{"id":58830,"date":"2023-10-05T13:24:57","date_gmt":"2023-10-05T04:24:57","guid":{"rendered":"https:\/\/monolith.law\/es\/?p=58830"},"modified":"2023-10-16T17:07:00","modified_gmt":"2023-10-16T08:07:00","slug":"system-flaw-measure-after-acceptance","status":"publish","type":"post","link":"https:\/\/monolith.law\/es\/it\/system-flaw-measure-after-acceptance","title":{"rendered":"\u00bfCu\u00e1les son las medidas a tomar si se descubre un fallo en el sistema despu\u00e9s de la aceptaci\u00f3n?"},"content":{"rendered":"\n<p>En t\u00e9rminos generales, el desarrollo de sistemas implica la implementaci\u00f3n de programas de acuerdo con lo que se decidi\u00f3 en la fase de definici\u00f3n de requisitos. Finalmente, tanto el usuario como el proveedor verifican si el resultado final cumple con las especificaciones y, si pasa la aceptaci\u00f3n, se considera terminado.<\/p>\n\n\n\n<p>Sin embargo, en la pr\u00e1ctica, es completamente posible que se descubran errores o problemas que no se detectaron durante las pruebas o la aceptaci\u00f3n en fases posteriores de operaci\u00f3n. Si se ha aceptado una entrega, \u00bfqu\u00e9 se puede solicitar legalmente? <br><\/p>\n\n\n\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_53 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<span class=\"ez-toc-title-toggle\"><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/monolith.law\/es\/it\/system-flaw-measure-after-acceptance\/#No_es_sorprendente_que_aun_queden_errores_despues_de_la_aceptacion_o_las_pruebas\" title=\"No es sorprendente que a\u00fan queden errores despu\u00e9s de la aceptaci\u00f3n o las pruebas\">No es sorprendente que a\u00fan queden errores despu\u00e9s de la aceptaci\u00f3n o las pruebas<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/monolith.law\/es\/it\/system-flaw-measure-after-acceptance\/#Normalmente_se_considera_que_la_deuda_en_si_misma_ya_ha_sido_cumplida\" title=\"Normalmente, se considera que la deuda en s\u00ed misma ya ha sido cumplida\">Normalmente, se considera que la deuda en s\u00ed misma ya ha sido cumplida<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/monolith.law\/es\/it\/system-flaw-measure-after-acceptance\/#El_camino_para_perseguir_la_responsabilidad_basada_en_la_garantia_de_defectos\" title=\"El camino para perseguir la responsabilidad basada en la garant\u00eda de defectos\">El camino para perseguir la responsabilidad basada en la garant\u00eda de defectos<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/monolith.law\/es\/it\/system-flaw-measure-after-acceptance\/#Primero_verifique_el_grado_de_gravedad_y_seriedad_de_los_errores_y_defectos\" title=\"Primero, verifique el grado de gravedad y seriedad de los errores y defectos\">Primero, verifique el grado de gravedad y seriedad de los errores y defectos<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/monolith.law\/es\/it\/system-flaw-measure-after-acceptance\/#A_continuacion_aclare_lo_que_se_debe_solicitar_al_vendedor\" title=\"A continuaci\u00f3n, aclare lo que se debe solicitar al vendedor\">A continuaci\u00f3n, aclare lo que se debe solicitar al vendedor<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/monolith.law\/es\/it\/system-flaw-measure-after-acceptance\/#Otros_puntos_a_tener_en_cuenta\" title=\"Otros puntos a tener en cuenta\">Otros puntos a tener en cuenta<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/monolith.law\/es\/it\/system-flaw-measure-after-acceptance\/#Es_importante_prestar_atencion_a_como_se_llevan_a_cabo_los_actos_legales_como_la_rescision_de_contratos\" title=\"Es importante prestar atenci\u00f3n a c\u00f3mo se llevan a cabo los actos legales, como la rescisi\u00f3n de contratos\">Es importante prestar atenci\u00f3n a c\u00f3mo se llevan a cabo los actos legales, como la rescisi\u00f3n de contratos<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/monolith.law\/es\/it\/system-flaw-measure-after-acceptance\/#Es_preferible_resolver_los_problemas_a_traves_de_negociaciones_en_lugar_de_disputas\" title=\"Es preferible resolver los problemas a trav\u00e9s de negociaciones en lugar de disputas\">Es preferible resolver los problemas a trav\u00e9s de negociaciones en lugar de disputas<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/monolith.law\/es\/it\/system-flaw-measure-after-acceptance\/#Deberiamos_distinguir_entre_bugs_y_defectos_y_la_falta_de_funcionalidad\" title=\"Deber\u00edamos distinguir entre bugs y defectos, y la falta de funcionalidad\">Deber\u00edamos distinguir entre bugs y defectos, y la falta de funcionalidad<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/monolith.law\/es\/it\/system-flaw-measure-after-acceptance\/#Resumen\" title=\"Resumen\">Resumen<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"No_es_sorprendente_que_aun_queden_errores_despues_de_la_aceptacion_o_las_pruebas\"><\/span>No es sorprendente que a\u00fan queden errores despu\u00e9s de la aceptaci\u00f3n o las pruebas<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Desde un punto de vista t\u00e9cnico, no es raro que se descubran varios errores y problemas despu\u00e9s de completar las diversas etapas de prueba del proveedor y despu\u00e9s de la aceptaci\u00f3n por parte del usuario. Lo que los usuarios suelen hacer en el proceso de aceptaci\u00f3n es principalmente verificar las entradas y salidas que se pueden confirmar desde la pantalla. Sin embargo, los sistemas de TI a menudo tienen una estructura compleja y detallada en la base de datos detr\u00e1s de la apariencia de la pantalla que los usuarios pueden ver, y en las partes del programa que controlan varios c\u00e1lculos y controles. Por lo tanto, hay un l\u00edmite en lo que se puede investigar a partir de la verificaci\u00f3n de las entradas y salidas en la pantalla desde la perspectiva del usuario. Por lo tanto, no es realista verificar exhaustivamente todas las posibilidades de problemas que pueden ocurrir en la fase de operaci\u00f3n despu\u00e9s de la verificaci\u00f3n.<\/p>\n\n\n\n<p>Las mismas circunstancias se aplican cuando se mira desde la perspectiva del proveedor que se encarga del desarrollo. Por ejemplo, el proceso de prueba es para verificar si hay errores o problemas en el contenido del programa implementado. Sin embargo, incluso en el proceso de prueba, no siempre es posible verificar exhaustivamente todas las posibilidades de errores y problemas. Incluso despu\u00e9s de que el sistema desarrollado comienza a utilizarse en serio en los negocios, se requiere una excelente habilidad t\u00e9cnica para crear un sistema que contin\u00fae funcionando sin problemas, incluso cuando se realizan operaciones que el proveedor no anticip\u00f3, o cuando se comienza a registrar una gran cantidad de datos, o cuando varios usuarios comienzan a acceder al mismo tiempo.<\/p>\n\n\n\n<p>Deber\u00edamos entender primero que no es realista descubrir todos los errores y problemas en las etapas de aceptaci\u00f3n y prueba, y que es posible que se descubran varios problemas despu\u00e9s de comenzar a usar el sistema de TI.<br><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Normalmente_se_considera_que_la_deuda_en_si_misma_ya_ha_sido_cumplida\"><\/span>Normalmente, se considera que la deuda en s\u00ed misma ya ha sido cumplida<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/monolith.law\/wp-content\/uploads\/2019\/09\/shutterstock_326816432-1024x977.jpg\" alt=\"\" class=\"wp-image-4911\" \/><figcaption class=\"wp-element-caption\">En la actualidad, a menudo es dif\u00edcil responsabilizar al proveedor por los problemas que surgen despu\u00e9s de comenzar a usar el programa.<\/figcaption><\/figure>\n\n\n\n<p>Entonces, \u00bfc\u00f3mo deber\u00edamos manejar estos problemas cuando realmente surgen? Vamos a organizarlo de acuerdo con el orden legal.<\/p>\n\n\n\n<p>Primero, si se han descubierto varios errores o problemas despu\u00e9s del hecho, el usuario querr\u00e1 responsabilizar de alguna manera al proveedor que ha estado encargado del trabajo hasta ahora. Sin embargo, normalmente, si la entrega ya se ha completado y ha pasado la inspecci\u00f3n, es a menudo dif\u00edcil responsabilizar al proveedor bas\u00e1ndose en el incumplimiento de la deuda.<\/p>\n\n\n\n<p>En primer lugar, a menos que se haya preparado alg\u00fan acuerdo especial, las regulaciones sobre la implementaci\u00f3n del programa en el contrato de desarrollo del sistema se extienden a las regulaciones del contrato de trabajo en el C\u00f3digo Civil japon\u00e9s. <\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"El_camino_para_perseguir_la_responsabilidad_basada_en_la_garantia_de_defectos\"><\/span>El camino para perseguir la responsabilidad basada en la garant\u00eda de defectos<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Entonces, \u00bfqu\u00e9 y en qu\u00e9 orden deber\u00edamos considerar cuando buscamos una respuesta del vendedor basada en la garant\u00eda de defectos? Vamos a verificarlo a continuaci\u00f3n.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Primero_verifique_el_grado_de_gravedad_y_seriedad_de_los_errores_y_defectos\"><\/span>Primero, verifique el grado de gravedad y seriedad de los errores y defectos<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Cuando se descubren errores y defectos despu\u00e9s del hecho y se busca alguna garant\u00eda alegando que son &#8220;defectos&#8221; legales, la gravedad de los errores y defectos se convierte en un problema. Los problemas de defectos legales son, en primer lugar,<\/p>\n\n\n\n<ol>\n<li>Aunque se puede decir que son errores y defectos, son solo menores y no se pueden considerar como &#8220;defectos&#8221; legales.<\/li>\n\n\n\n<li>Corresponde a un &#8220;defecto&#8221; legal, pero a\u00fan es posible lograr el objetivo del contrato.<\/li>\n\n\n\n<li>Corresponde a un &#8220;defecto&#8221; legal, y tambi\u00e9n es imposible lograr el objetivo del contrato.<\/li>\n<\/ol>\n\n\n\n<p>Estos se dividen en tres patrones. Lo que distingue la posibilidad de perseguir la responsabilidad basada en la garant\u00eda de defectos es la l\u00ednea entre 1 y 2, y lo que distingue la posibilidad de rescindir el contrato basado en la garant\u00eda de defectos es la l\u00ednea entre 2 y 3.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"A_continuacion_aclare_lo_que_se_debe_solicitar_al_vendedor\"><\/span>A continuaci\u00f3n, aclare lo que se debe solicitar al vendedor<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Adem\u00e1s, es necesario aclarar qu\u00e9 se debe solicitar a la otra parte. Si desea rescindir el contrato, no es suficiente demostrar que es un defecto, sino que debe ser algo que &#8220;no puede lograr el prop\u00f3sito del contrato&#8221;. En la determinaci\u00f3n de este &#8220;prop\u00f3sito&#8221;, las actas de las reuniones realizadas al inicio del proyecto de desarrollo del sistema y los detalles de las especificaciones son pistas importantes. Dado que tambi\u00e9n es posible que se descubran errores y defectos despu\u00e9s de la aceptaci\u00f3n, se debe asegurar la conservaci\u00f3n de varios documentos incluso despu\u00e9s de la finalizaci\u00f3n del proyecto de desarrollo.<\/p>\n\n\n\n<p>Adem\u00e1s de la rescisi\u00f3n, lo que se puede solicitar como contenido de la garant\u00eda de defectos incluye reclamaciones de indemnizaci\u00f3n por da\u00f1os y reclamaciones de reparaci\u00f3n de defectos.<br><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Otros_puntos_a_tener_en_cuenta\"><\/span>Otros puntos a tener en cuenta<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/monolith.law\/wp-content\/uploads\/2019\/09\/shutterstock_1299988513-1024x684.jpg\" alt=\"\" class=\"wp-image-4913\" \/><figcaption class=\"wp-element-caption\">Es importante tener en cuenta la gesti\u00f3n de documentos y el flujo de procedimientos legales hasta la finalizaci\u00f3n del proyecto.<\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Es_importante_prestar_atencion_a_como_se_llevan_a_cabo_los_actos_legales_como_la_rescision_de_contratos\"><\/span>Es importante prestar atenci\u00f3n a c\u00f3mo se llevan a cabo los actos legales, como la rescisi\u00f3n de contratos<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Si se va a rescindir un contrato como parte de la responsabilidad por defectos, tambi\u00e9n deber\u00eda aprender c\u00f3mo llevar a cabo los procedimientos legales para la rescisi\u00f3n. <\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Es_preferible_resolver_los_problemas_a_traves_de_negociaciones_en_lugar_de_disputas\"><\/span>Es preferible resolver los problemas a trav\u00e9s de negociaciones en lugar de disputas<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Adem\u00e1s, estos argumentos legales no s\u00f3lo tienen sentido cuando se produce un juicio. La resoluci\u00f3n de disputas a trav\u00e9s de juicios es una gran carga para ambas partes. Por el contrario, estos conocimientos legales tambi\u00e9n son muy \u00fatiles en la etapa de negociaci\u00f3n antes de llegar a juicio. <\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Deberiamos_distinguir_entre_bugs_y_defectos_y_la_falta_de_funcionalidad\"><\/span>Deber\u00edamos distinguir entre bugs y defectos, y la falta de funcionalidad<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>La discusi\u00f3n var\u00eda dependiendo de si hay bugs o defectos en las funciones y especificaciones que se han implementado, o si simplemente no est\u00e1n presentes. Si las funciones necesarias no est\u00e1n presentes, es posible que no se reconozca la &#8220;finalizaci\u00f3n del trabajo&#8221; en el contrato de subcontrataci\u00f3n, y puede que no se reconozca el cumplimiento de la obligaci\u00f3n.<\/p>\n\n\n\n<p>Adem\u00e1s, incluso si no se proporcionan las funciones y especificaciones necesarias, si el usuario no ha proporcionado informaci\u00f3n adecuada en la etapa de definici\u00f3n de requisitos, puede que sea inapropiado considerarlo como parte del contenido del contrato en primer lugar.<br><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Resumen\"><\/span>Resumen<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Los problemas que surgen durante el proceso de un proyecto pueden manifestarse mientras el proyecto est\u00e1 en marcha o pueden revelarse posteriormente, como en la etapa de operaci\u00f3n. Incluso si se ha completado con \u00e9xito todas las etapas del proyecto, la caracter\u00edstica de los proyectos de desarrollo de sistemas que no necesariamente garantiza la tranquilidad parece estar simbolizada en el sistema de &#8220;responsabilidad por defectos&#8221;. Se considera importante comprender todo este proceso y asegurar una gesti\u00f3n de documentos exhaustiva que tenga en cuenta lo que sucede despu\u00e9s de la finalizaci\u00f3n del proyecto de desarrollo del sistema.<br><\/p>\n","protected":false},"excerpt":{"rendered":"<p>En t\u00e9rminos generales, el desarrollo de sistemas implica la implementaci\u00f3n de programas de acuerdo con lo que se decidi\u00f3 en la fase de definici\u00f3n de requisitos. Finalmente, tanto el usuario como el pr [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":58910,"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\/58830"}],"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=58830"}],"version-history":[{"count":1,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/posts\/58830\/revisions"}],"predecessor-version":[{"id":58914,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/posts\/58830\/revisions\/58914"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/media\/58910"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/media?parent=58830"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/categories?post=58830"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/tags?post=58830"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}