{"id":59279,"date":"2023-11-10T17:08:05","date_gmt":"2023-11-10T08:08:05","guid":{"rendered":"https:\/\/monolith.law\/es\/?p=59279"},"modified":"2024-04-01T19:50:59","modified_gmt":"2024-04-01T10:50:59","slug":"server-infrastructure-for-system-development","status":"publish","type":"post","link":"https:\/\/monolith.law\/es\/it\/server-infrastructure-for-system-development","title":{"rendered":"\u00bfCu\u00e1les son los problemas legales relacionados con el servidor e infraestructura de desarrollo de sistemas?"},"content":{"rendered":"\n<p>En cierto sentido, los sistemas de TI que se utilizan en las empresas se crean mediante la elaboraci\u00f3n de especificaciones y documentos de dise\u00f1o, y la escritura de c\u00f3digo fuente que corresponde a estos contenidos. Sin embargo, un sistema solo puede funcionar realmente si cuenta con una infraestructura f\u00edsica, es decir, una computadora. En este art\u00edculo, explicaremos los problemas legales que est\u00e1n estrechamente relacionados con el campo de la infraestructura en los proyectos de desarrollo de sistemas.<\/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\/server-infrastructure-for-system-development\/#%C2%BFQue_es_la_infraestructura_en_los_sistemas_de_TI\" title=\"\u00bfQu\u00e9 es la infraestructura en los sistemas de TI?\">\u00bfQu\u00e9 es la infraestructura en los sistemas de TI?<\/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\/server-infrastructure-for-system-development\/#Escenarios_concretos_en_los_que_los_problemas_de_infraestructura_pueden_incendiar_un_proyecto\" title=\"Escenarios concretos en los que los problemas de infraestructura pueden incendiar un proyecto\">Escenarios concretos en los que los problemas de infraestructura pueden incendiar un proyecto<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/monolith.law\/es\/it\/server-infrastructure-for-system-development\/#%C2%BFComo_un_error_en_el_dimensionamiento_del_servidor_puede_provocar_un_conflicto\" title=\"\u00bfC\u00f3mo un error en el dimensionamiento del servidor puede provocar un conflicto?\">\u00bfC\u00f3mo un error en el dimensionamiento del servidor puede provocar un conflicto?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/monolith.law\/es\/it\/server-infrastructure-for-system-development\/#La_esencia_del_caso_es_el_alcance_de_la_obligacion_del_proveedor_de_responder_a_las_especificaciones_ambiguas\" title=\"La esencia del caso es el alcance de la obligaci\u00f3n del proveedor de responder a las especificaciones ambiguas\">La esencia del caso es el alcance de la obligaci\u00f3n del proveedor de responder a las especificaciones ambiguas<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/monolith.law\/es\/it\/server-infrastructure-for-system-development\/#Medidas_para_prevenir_problemas_debido_a_errores_en_el_dimensionamiento_del_servidor\" title=\"Medidas para prevenir problemas debido a errores en el dimensionamiento del servidor\">Medidas para prevenir problemas debido a errores en el dimensionamiento del servidor<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/monolith.law\/es\/it\/server-infrastructure-for-system-development\/#Clarificar_en_el_contrato_quien_es_responsable_del_dimensionamiento_del_servidor\" title=\"Clarificar en el contrato qui\u00e9n es responsable del dimensionamiento del servidor\">Clarificar en el contrato qui\u00e9n es responsable del dimensionamiento del servidor<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/monolith.law\/es\/it\/server-infrastructure-for-system-development\/#Concretar_los_requisitos_de_desarrollo_y_gestionar_completamente_los_cambios\" title=\"Concretar los requisitos de desarrollo y gestionar completamente los cambios\">Concretar los requisitos de desarrollo y gestionar completamente los cambios<\/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\/server-infrastructure-for-system-development\/#Elegir_un_modelo_de_desarrollo_que_se_adapte_a_la_naturaleza_del_proyecto\" title=\"Elegir un modelo de desarrollo que se adapte a la naturaleza del proyecto\">Elegir un modelo de desarrollo que se adapte a la naturaleza del proyecto<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/monolith.law\/es\/it\/server-infrastructure-for-system-development\/#Resumen\" title=\"Resumen\">Resumen<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"%C2%BFQue_es_la_infraestructura_en_los_sistemas_de_TI\"><\/span>\u00bfQu\u00e9 es la infraestructura en los sistemas de TI?<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Los t\u00e9cnicos que desarrollan sistemas se conocen como Ingenieros de Sistemas (SE, por sus siglas en ingl\u00e9s). Y los proyectos de desarrollo comienzan con procesos iniciales como la creaci\u00f3n de especificaciones y documentos de dise\u00f1o, seguidos por la implementaci\u00f3n del programa y la realizaci\u00f3n de pruebas. Esto es, en t\u00e9rminos generales, el flujo de trabajo. Sin embargo, se puede decir que un Ingeniero de Sistemas (SE) en un sentido amplio es un t\u00e9cnico que se encarga de todas las tareas necesarias para estos procesos, aunque dependiendo de la empresa o el lugar de trabajo, pueden diferenciar a\u00fan m\u00e1s los nombres seg\u00fan las tareas y \u00e1reas a cargo. El t\u00e9rmino &#8220;Ingeniero de Infraestructura&#8221; se refiere a los t\u00e9cnicos que, como parte de su trabajo en el desarrollo y operaci\u00f3n de sistemas de TI, se encargan especialmente de preparar el entorno operativo f\u00edsico 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\u00f3digo fuente. Sin embargo, para que estos sistemas desempe\u00f1en el papel que se espera de ellos, es esencial construir un entorno alrededor de la infraestructura, incluyendo servidores y redes. El trabajo pr\u00e1ctico de desarrollo de sistemas avanza sobre dos ruedas: la implementaci\u00f3n del programa y el c\u00f3digo fuente, y la preparaci\u00f3n del entorno que soporta su funcionamiento. Se considera que esta perspectiva es importante para prevenir la aparici\u00f3n de problemas imprevistos.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Escenarios_concretos_en_los_que_los_problemas_de_infraestructura_pueden_incendiar_un_proyecto\"><\/span>Escenarios concretos en los que los problemas de infraestructura pueden incendiar un proyecto<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\/10\/shutterstock_1532780735-1024x620.jpg\" alt=\"\" class=\"wp-image-5570\" \/><figcaption class=\"wp-element-caption\">Descuidar el mantenimiento de la infraestructura puede ser una causa de riesgo de &#8220;incendio&#8221;.<\/figcaption><\/figure>\n\n\n\n<p>En los proyectos de desarrollo de sistemas, es posible que se concentre demasiado en el dise\u00f1o abstracto de programas y c\u00f3digos fuente, descuidando la perspectiva del mantenimiento de la infraestructura. Sin embargo, si estos dos aspectos no est\u00e1n alineados, puede aumentar el riesgo de que el proyecto se incendie.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"%C2%BFComo_un_error_en_el_dimensionamiento_del_servidor_puede_provocar_un_conflicto\"><\/span>\u00bfC\u00f3mo un error en el dimensionamiento del servidor puede provocar un conflicto?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Por ejemplo, despu\u00e9s de que se haya completado toda la implementaci\u00f3n 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\u00e1ctica. Este proceso de prever la carga que el sistema puede soportar en la fase de operaci\u00f3n y realizar el mantenimiento de la infraestructura de acuerdo con la escala del sistema se llama &#8220;dimensionamiento&#8221;. Hay casos en los que un error en el dimensionamiento del servidor ha causado problemas y ha llevado a conflictos. (Aunque finalmente se resolvi\u00f3 mediante un acuerdo, este caso puede servir como referencia.) Para m\u00e1s detalles sobre c\u00f3mo resolver conflictos entre las partes a trav\u00e9s de un &#8220;acuerdo&#8221;, consulte el siguiente art\u00edculo.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/disputes-related-to-system-development\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/disputes-related-to-system-development[ja]<\/a><\/p>\n\n\n\n<p>El hecho de que el conflicto se resolviera mediante un acuerdo significa, en t\u00e9rminos simples, que el conflicto se resolvi\u00f3 a trav\u00e9s de una &#8220;discusi\u00f3n&#8221; 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\u00edfico.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"La_esencia_del_caso_es_el_alcance_de_la_obligacion_del_proveedor_de_responder_a_las_especificaciones_ambiguas\"><\/span>La esencia del caso es el alcance de la obligaci\u00f3n del proveedor de responder a las especificaciones ambiguas<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>En \u00faltima instancia, la esencia de estos conflictos puede ser &#8220;hasta qu\u00e9 punto el proveedor debe asumir la responsabilidad de los elementos que no est\u00e1n expl\u00edcitamente especificados&#8221;. Teniendo en cuenta este punto, se pueden obtener muchas pistas del contenido del siguiente art\u00edculo.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/system-development-specs-function\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/system-development-specs-function[ja]<\/a><\/p>\n\n\n\n<p>En el art\u00edculo anterior, se explica hasta qu\u00e9 punto el proveedor tiene la obligaci\u00f3n de implementar elementos que no est\u00e1n especificados en las especificaciones. Aqu\u00ed, se explica que la historia es muy diferente entre los elementos del &#8220;lado de la pantalla&#8221; que se pueden visualizar f\u00e1cilmente en documentos como los de definici\u00f3n de requisitos y dise\u00f1o b\u00e1sico (el llamado &#8220;front-end&#8221;) y los del &#8220;lado de la l\u00f3gica&#8221; como la migraci\u00f3n de datos (el llamado &#8220;back-end&#8221; o &#8220;base de datos&#8221;). En otras palabras, se puede pensar que los elementos del &#8220;lado de la pantalla&#8221;, que son f\u00e1cilmente 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 &#8220;lado de la l\u00f3gica&#8221; tienden a ser atribuidos al proveedor. Teniendo en cuenta estos puntos, se puede pensar que los problemas de dimensionamiento del servidor, que son dif\u00edciles de reconocer a menos que se sea un experto en tecnolog\u00eda, 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\u00e1 desfavorecido si este punto se disputa seriamente en un juicio.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Medidas_para_prevenir_problemas_debido_a_errores_en_el_dimensionamiento_del_servidor\"><\/span>Medidas para prevenir problemas debido a errores en el dimensionamiento del servidor<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\/10\/shutterstock_1501344230-1024x717.jpg\" alt=\"\" class=\"wp-image-5572\" \/><figcaption class=\"wp-element-caption\">Explicaremos medidas concretas para prevenir problemas.<\/figcaption><\/figure>\n\n\n\n<p>Para prevenir los problemas mencionados anteriormente, es importante coordinar las tareas como la implementaci\u00f3n del programa y la escritura del c\u00f3digo fuente con la preparaci\u00f3n del entorno de infraestructura. Las medidas concretas que se pueden considerar incluyen las siguientes:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Clarificar_en_el_contrato_quien_es_responsable_del_dimensionamiento_del_servidor\"><\/span>Clarificar en el contrato qui\u00e9n es responsable del dimensionamiento del servidor<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>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\u00e1 claro qui\u00e9n es responsable entre el proveedor, que es un experto en desarrollo de sistemas, y el usuario, que conoce la situaci\u00f3n interna de la empresa. Aunque es innecesario decir que la estrecha colaboraci\u00f3n entre ambas partes es necesaria para el progreso fluido del proyecto, ser\u00eda deseable aclarar tanto como sea posible el reparto de roles y el alcance de la responsabilidad en el contrato de antemano.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Concretar_los_requisitos_de_desarrollo_y_gestionar_completamente_los_cambios\"><\/span>Concretar los requisitos de desarrollo y gestionar completamente los cambios<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Adem\u00e1s, si los requisitos funcionales que se deben lograr son ambiguos, el riesgo de conflictos aumenta. Esto tiene dos aspectos: la clarificaci\u00f3n de las especificaciones en la fase de definici\u00f3n de requisitos iniciales y la gesti\u00f3n de cambios durante el proyecto. En cuanto a c\u00f3mo manejar los cambios en las especificaciones durante el proyecto, se explica en detalle en el siguiente art\u00edculo.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/howto-manage-change-in-system-development\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/howto-manage-change-in-system-development[ja]<\/a><\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Elegir_un_modelo_de_desarrollo_que_se_adapte_a_la_naturaleza_del_proyecto\"><\/span>Elegir un modelo de desarrollo que se adapte a la naturaleza del proyecto<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Adem\u00e1s, aunque est\u00e1 profundamente relacionado con las dos medidas anteriores, es importante elegir un modelo de desarrollo adecuado para el proyecto de desarrollo de sistemas en funci\u00f3n 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\u00f3n del modelo de desarrollo adecuado teniendo en cuenta la naturaleza del proyecto, se explica en detalle en el siguiente art\u00edculo.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/legal-merits-and-demerits-of-development-model\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/legal-merits-and-demerits-of-development-model[ja]<\/a><\/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 de la preparaci\u00f3n del entorno de infraestructura para el progreso fluido de los proyectos de desarrollo de sistemas son puntos que f\u00e1cilmente pueden pasar desapercibidos. Se considera que prestar atenci\u00f3n incluso a los problemas de infraestructura no es una carga peque\u00f1a para aquellos que no son expertos en tecnolog\u00eda. Sin embargo, las medidas preventivas para estos problemas pueden considerarse una extensi\u00f3n de medidas b\u00e1sicas como &#8220;clarificaci\u00f3n de especificaciones \/ gesti\u00f3n rigurosa de cambios&#8221;, &#8220;clarificaci\u00f3n de roles \/ alcance de responsabilidad&#8221;, y &#8220;selecci\u00f3n de un modelo de desarrollo acorde al tama\u00f1o y presupuesto del proyecto&#8221;. Lo que las personas involucradas en los asuntos legales corporativos deben entender primero es que los fundamentos de la prevenci\u00f3n legal pueden ser suficientemente aplicables incluso a los problemas de infraestructura. Adem\u00e1s, 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.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>En cierto sentido, los sistemas de TI que se utilizan en las empresas se crean mediante la elaboraci\u00f3n de especificaciones y documentos de dise\u00f1o, y la escritura de c\u00f3digo fuente que corresponde a est [&hellip;]<\/p>\n","protected":false},"author":32,"featured_media":68288,"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\/59279"}],"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\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/comments?post=59279"}],"version-history":[{"count":1,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/posts\/59279\/revisions"}],"predecessor-version":[{"id":68289,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/posts\/59279\/revisions\/68289"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/media\/68288"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/media?parent=59279"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/categories?post=59279"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/es\/wp-json\/wp\/v2\/tags?post=59279"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}