{"id":309,"date":"2020-05-28T01:20:44","date_gmt":"2020-05-28T01:20:44","guid":{"rendered":"https:\/\/arsum.cl\/?page_id=309"},"modified":"2020-06-17T21:25:04","modified_gmt":"2020-06-17T21:25:04","slug":"arquitectura-o-diseno-de-software","status":"publish","type":"page","link":"https:\/\/arsum.cl\/?page_id=309","title":{"rendered":"\u00bfArquitectura o dise\u00f1o de software?"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t\n

No existe una definici\u00f3n universal de arquitectura de software. El sitio web del Instituto de Ingenier\u00eda de Software recopila definiciones de la literatura y de profesionales de todo el mundo. Hasta ahora, se han recopilado m\u00e1s de 150 definiciones.\u00a0Cuando se intenta comprender un sistema, es importante saber qu\u00e9 hacen realmente sus partes individuales, c\u00f3mo funcionan juntas y c\u00f3mo interact\u00faan con el mundo que las rodea, en otras palabras, su arquitectura. Una definici\u00f3n ampliamente aceptada de arquitectura de software es:<\/span><\/p>\n

<\/p>\n

\u201cLa arquitectura de un sistema es el conjunto de conceptos o propiedades fundamentales del sistema, plasmados en sus elementos, relaciones y los principios de su dise\u00f1o.\u201d<\/em><\/strong><\/p>\n

<\/p>\n

La pregunta de c\u00f3mo la arquitectura de software es diferente del dise\u00f1o ha llegado a los talones de la comunidad de desarrollo de software durante a\u00f1os, y en este contexto es importante, porque la pregunta trata de qu\u00e9 deber\u00edamos poner en un documento de arquitectura y qu\u00e9 deber\u00edamos poner en otro lugar.<\/p>\n

<\/p>\n

Lo primero que podemos decir es que claramente la arquitectura es dise\u00f1o, pero no todo dise\u00f1o es arquitectura. Es decir, muchas de las decisiones de dise\u00f1o quedan sin consolidar por la arquitectura, quedando, finalmente, a la discreci\u00f3n y buen juicio de los dise\u00f1adores y desarrolladores posteriores. La arquitectura establece restricciones en las actividades posteriores, y esas actividades deben producir artefactos (dise\u00f1os y c\u00f3digos m\u00e1s finos) que cumplan con la arquitectura.<\/p>\n

<\/p>\n

Por lo tanto, las decisiones arquitect\u00f3nicas son las que permiten que un sistema cumpla con sus atributos de calidad y requisitos de comportamiento. Todas las dem\u00e1s decisiones son no arquitect\u00f3nicas y pertenecen al dise\u00f1o del software.<\/p>\n

<\/p>\n

\u00bfPor qu\u00e9 documentar la arquitectura del software?<\/strong><\/p>\n

<\/p>\n

Incluso la mejor arquitectura, la m\u00e1s adecuada para el trabajo, ser\u00e1 esencialmente in\u00fatil si las personas que necesitan usarla no saben lo que es, no pueden entenderlo lo suficiente como para aplicarlo, o -lo peor de todo- lo malinterpretan y aplican incorrectamente. Por lo tanto, crear una arquitectura no es suficiente; tiene que ser comunicada de manera que sus partes interesadas puedan usarla adecuadamente para hacer su trabajo. La documentaci\u00f3n habla por el arquitecto, cuando \u00e9l o ella hayan abandonado el proyecto, y ahora alguien m\u00e1s est\u00e9 a cargo de su evoluci\u00f3n y mantenimiento.<\/p>\n

<\/p>\n

Los mejores arquitectos producen la mejor documentaci\u00f3n, no porque sea \u00abrequerida\u00bb, sino porque ven que es esencial para el asunto en cuesti\u00f3n: producir un producto de alta calidad, de manera predecible y con el menor trabajo posible. Ven a sus partes interesadas inmediatas como las personas m\u00e1s \u00edntimamente involucradas en esta empresa: desarrolladores, implementadores, probadores y analistas.<\/p>\n

<\/p>\n

Pero los mejores arquitectos tambi\u00e9n ven la documentaci\u00f3n como un valor para s\u00ed mismos. La documentaci\u00f3n sirve como recept\u00e1culo para guardar los resultados de las decisiones de dise\u00f1o a medida que se toman. Un esquema de documentaci\u00f3n bien pensado puede hacer que el proceso de dise\u00f1o sea mucho m\u00e1s fluido y sistem\u00e1tico. La documentaci\u00f3n ayuda al arquitecto mientras la arquitectura est\u00e1 en progreso, ya sea en una fase de dise\u00f1o de seis meses o en un sprint <\/em>\u00e1gil de seis d\u00edas.<\/p>\n

<\/p>\n

\u00bfCu\u00e1les son las caracter\u00edsticas de una documentaci\u00f3n de arquitectura de software?<\/strong><\/p>\n

<\/p>\n

La documentaci\u00f3n de arquitectura debe servir para diversos prop\u00f3sitos: Debe ser lo suficientemente abstracto como para que los nuevos empleados lo entiendan r\u00e1pidamente; debe ser lo suficientemente concreto como para servir como proyecto para la construcci\u00f3n y, por \u00faltimo, debe tener suficiente informaci\u00f3n para servir de base para el an\u00e1lisis.<\/p>\n

<\/p>\n

La documentaci\u00f3n de arquitectura es tanto prescriptiva como descriptiva. Para algunas audiencias, prescribe lo que deber\u00eda ser cierto, imponiendo restricciones a las decisiones que a\u00fan deben tomarse. Para otras audiencias, describe lo que es verdad, relatando las decisiones ya tomadas sobre el dise\u00f1o de un sistema.<\/p>\n

<\/p>\n

Fundamentalmente, la documentaci\u00f3n de arquitectura tiene tres usos.<\/p>\n

<\/p>\n

    \n
  1. La arquitectura sirve como un medio de educaci\u00f3n. <\/strong>El uso educativo consiste en introducir a las personas al sistema. La gente puede ser nuevos miembros del equipo, analistas externos o incluso un nuevo arquitecto. En muchos casos, la \u00abnueva\u00bb persona es el cliente a quien le est\u00e1 mostrando su soluci\u00f3n por primera vez, una presentaci\u00f3n que espera dar\u00e1 como resultado la aprobaci\u00f3n de fondos o aprobaci\u00f3n.

    <\/li>\n
  2. La arquitectura sirve como veh\u00edculo principal para la comunicaci\u00f3n entre las partes interesadas. <\/strong>El uso preciso de una arquitectura como veh\u00edculo de comunicaci\u00f3n depende de qu\u00e9 partes interesadas se est\u00e9n comunicando. Quiz\u00e1s uno de los consumidores m\u00e1s \u00e1vidos de documentaci\u00f3n de arquitectura no sea otro que el arquitecto en el futuro del proyecto. El futuro arquitecto puede ser la misma persona que el actual, o \u00e9l o ella puede ser un reemplazo, pero en cualquier caso se le garantiza una enorme participaci\u00f3n en la documentaci\u00f3n. Los nuevos arquitectos est\u00e1n interesados en aprender c\u00f3mo sus predecesores abordaron los dif\u00edciles problemas del sistema y por qu\u00e9 se tomaron decisiones particulares. Incluso si el futuro arquitecto es la misma persona, \u00e9l o ella usar\u00e1 la documentaci\u00f3n como dep\u00f3sito de pensamiento, un almac\u00e9n de decisiones de dise\u00f1o demasiado numerosas e irremediablemente entrelazadas para ser reproducibles solo de memoria.

    <\/li>\n
  3. Documentar una arquitectura ayuda en el proceso de dise\u00f1o de la arquitectura<\/strong>. Primero, la documentaci\u00f3n proporciona compartimentos dedicados para registrar varios tipos de decisiones de dise\u00f1o tan pronto como se toman. En segundo lugar, la documentaci\u00f3n le brinda una forma aproximada pero \u00fatil de medir el progreso y el trabajo restante: a medida que \u00abTBD\u00bb desaparece del documento, la finalizaci\u00f3n se acerca. Finalmente, la documentaci\u00f3n proporciona un marco para el ataque sistem\u00e1tico en el dise\u00f1o de la arquitectura. Las decisiones de dise\u00f1o clave, generalmente hechas temprano, deben escribirse de manera que la sombra que arrojan sobre las decisiones de dise\u00f1o posteriores sea expl\u00edcita y recordada.<\/li>\n<\/ol>\n

    <\/p>\n

    Stakeholders <\/em>involucrados en la documentaci\u00f3n de la arquitectura de software<\/strong><\/p>\n

    <\/p>\n

    Finalmente, es importante considerar quienes est\u00e1n involucrados en el proceso de documentaci\u00f3n de arquitectura de software. Veamos:<\/p>\n

    <\/p>\n

      \n
    • Arquitecto.<\/strong> Es el responsable del desarrollo de la arquitectura y su documentaci\u00f3n. Usa la documentaci\u00f3n de arquitectura para negociar y compensar entre requisitos competitivos y enfoques de dise\u00f1o. Un recipiente para registrar decisiones de dise\u00f1o. Aportando evidencia de que la arquitectura satisface sus requisitos.<\/li>\n<\/ul>\n

      <\/p>\n

        \n
      • Analista de negocios<\/strong>. Responsable del funcionamiento de la entidad empresarial \/ organizacional propietaria del sistema. Incluye responsabilidad gerencial \/ ejecutiva, responsabilidad de definir procesos de negocios y m\u00e1s. La documentaci\u00f3n de arquitectura le permite comprender la capacidad de dicha arquitectura para cumplir los objetivos comerciales.<\/li>\n<\/ul>\n

        <\/p>\n

          \n
        • Administrador de Base de Datos<\/strong>. Implicado en muchos aspectos de los almacenes de datos, incluido el dise\u00f1o de bases de datos, an\u00e1lisis de datos, modelado y optimizaci\u00f3n de datos, instalaci\u00f3n de software de bases de datos, y el monitoreo y administraci\u00f3n de seguridad de bases de datos. La documentaci\u00f3n de arquitectura le permite comprender c\u00f3mo los datos son creados, utilizados y actualizados por otros elementos arquitect\u00f3nicos, y qu\u00e9 propiedades deben tener los datos y la base de datos para que el sistema general cumpla con sus objetivos de calidad.<\/li>\n<\/ul>\n

          <\/p>\n

            \n
          • DevOp<\/strong>. Responsable de aceptar el sistema completo del esfuerzo de desarrollo y desplegarlo, para hacerlo operativo y cumplir con su funci\u00f3n comercial asignada. La documentaci\u00f3n de la arquitectura le sirve para comprender los elementos arquitect\u00f3nicos que se entregan y se instalan en el sitio del cliente o del usuario final, y su responsabilidad general hacia la funci\u00f3n del sistema.<\/li>\n<\/ul>\n

            <\/p>\n

              \n
            • Dise\u00f1ador<\/strong>. Responsable del dise\u00f1o de sistemas y\/o software aguas abajo de la arquitectura, aplicando la arquitectura para cumplir con los requisitos espec\u00edficos de las partes de las que son responsables. La documentaci\u00f3n de arquitectura le ayuda a resolver la contenci\u00f3n de recursos y establecer el rendimiento y otros tipos de presupuestos de consumo de recursos en tiempo de ejecuci\u00f3n, as\u00ed como tambi\u00e9n comprender c\u00f3mo su parte se comunicar\u00e1 e interactuar\u00e1 con otras partes del sistema.<\/li>\n<\/ul>\n

              <\/p>\n

                \n
              • Administrador de Sistemas<\/strong>. Responsable del mantenimiento y supervisi\u00f3n del hardware y software de una red inform\u00e1tica. Esto puede incluir la implementaci\u00f3n, configuraci\u00f3n, mantenimiento y monitoreo de componentes de red. La documentaci\u00f3n de arquitectura le permite determinar las cargas de red durante varios perfiles de uso y comprender los usos de la red.<\/li>\n<\/ul>\n

                <\/p>\n

                  \n
                • Jefe de Proyectos<\/strong>. Es el responsable de planificar, secuenciar, programar y asignar recursos para desarrollar componentes de software y entregar componentes para actividades de integraci\u00f3n y prueba. La documentaci\u00f3n de arquitectura le ayuda a establecer el presupuesto y el cronograma, medir el progreso con respecto al presupuesto y cronograma establecidos, e identificar y resolver la contenci\u00f3n de recursos en tiempo de desarrollo.<\/li>\n<\/ul>\n

                  <\/p>\n

                    \n
                  • Ingeniero QA<\/strong>. Responsable de las pruebas (independientes) y verificaci\u00f3n del sistema o sus elementos contra los requisitos formales y la arquitectura. Con la documentaci\u00f3n de arquitectura puede crear pruebas basadas en el comportamiento y la interacci\u00f3n de los elementos del software.<\/li>\n<\/ul>\n

                    <\/p>\n

                      \n
                    • Usuario<\/strong>. Es quien pertenece al grupo de usuarios finales reales del sistema. Puede haber distintos tipos de usuarios, como administradores, superusuarios, etc. Los usuarios, en el papel de revisores, pueden confiar en la documentaci\u00f3n de la arquitectura para verificar si se est\u00e1 entregando la funcionalidad deseada. Los usuarios tambi\u00e9n pueden consultar la documentaci\u00f3n para comprender cu\u00e1les son los principales elementos del sistema, que pueden ayudarlos en el mantenimiento de emergencia en el campo.<\/li>\n<\/ul>\n

                      <\/p>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"

                      No existe una definici\u00f3n universal de arquitectura de software. El sitio web del Instituto de Ingenier\u00eda de Software recopila definiciones de la literatura y de profesionales de todo el mundo. Hasta ahora, se han recopilado m\u00e1s de 150 definiciones.\u00a0Cuando se intenta comprender un sistema, es importante saber qu\u00e9 hacen realmente sus partes individuales, c\u00f3mo funcionan […]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":305,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"ocean_post_layout":"full-width","ocean_both_sidebars_style":"","ocean_both_sidebars_content_width":0,"ocean_both_sidebars_sidebars_width":0,"ocean_sidebar":"0","ocean_second_sidebar":"0","ocean_disable_margins":"enable","ocean_add_body_class":"","ocean_shortcode_before_top_bar":"","ocean_shortcode_after_top_bar":"","ocean_shortcode_before_header":"","ocean_shortcode_after_header":"","ocean_has_shortcode":"","ocean_shortcode_after_title":"","ocean_shortcode_before_footer_widgets":"","ocean_shortcode_after_footer_widgets":"","ocean_shortcode_before_footer_bottom":"","ocean_shortcode_after_footer_bottom":"","ocean_display_top_bar":"default","ocean_display_header":"default","ocean_header_style":"","ocean_center_header_left_menu":"0","ocean_custom_header_template":"0","ocean_custom_logo":0,"ocean_custom_retina_logo":0,"ocean_custom_logo_max_width":0,"ocean_custom_logo_tablet_max_width":0,"ocean_custom_logo_mobile_max_width":0,"ocean_custom_logo_max_height":0,"ocean_custom_logo_tablet_max_height":0,"ocean_custom_logo_mobile_max_height":0,"ocean_header_custom_menu":"0","ocean_menu_typo_font_family":"0","ocean_menu_typo_font_subset":"","ocean_menu_typo_font_size":0,"ocean_menu_typo_font_size_tablet":0,"ocean_menu_typo_font_size_mobile":0,"ocean_menu_typo_font_size_unit":"px","ocean_menu_typo_font_weight":"","ocean_menu_typo_font_weight_tablet":"","ocean_menu_typo_font_weight_mobile":"","ocean_menu_typo_transform":"","ocean_menu_typo_transform_tablet":"","ocean_menu_typo_transform_mobile":"","ocean_menu_typo_line_height":0,"ocean_menu_typo_line_height_tablet":0,"ocean_menu_typo_line_height_mobile":0,"ocean_menu_typo_line_height_unit":"","ocean_menu_typo_spacing":0,"ocean_menu_typo_spacing_tablet":0,"ocean_menu_typo_spacing_mobile":0,"ocean_menu_typo_spacing_unit":"","ocean_menu_link_color":"","ocean_menu_link_color_hover":"","ocean_menu_link_color_active":"","ocean_menu_link_background":"","ocean_menu_link_hover_background":"","ocean_menu_link_active_background":"","ocean_menu_social_links_bg":"","ocean_menu_social_hover_links_bg":"","ocean_menu_social_links_color":"","ocean_menu_social_hover_links_color":"","ocean_disable_title":"default","ocean_disable_heading":"enable","ocean_post_title":"","ocean_post_subheading":"La creaci\u00f3n de software es un proceso que consta de muchas partes diferentes. Entre los aspectos m\u00e1s importantes se encuentran el desarrollo de la arquitectura y el dise\u00f1o de software. Por alguna raz\u00f3n, estas dos etapas cr\u00edticas del desarrollo de software a menudo se confunden entre s\u00ed. Esta confusi\u00f3n puede conducir a malentendidos que pueden poner en riesgo todo el proceso de desarrollo.","ocean_post_title_style":"background-image","ocean_post_title_background_color":"","ocean_post_title_background":364,"ocean_post_title_bg_image_position":"center center","ocean_post_title_bg_image_attachment":"","ocean_post_title_bg_image_repeat":"","ocean_post_title_bg_image_size":"","ocean_post_title_height":0,"ocean_post_title_bg_overlay":0.5,"ocean_post_title_bg_overlay_color":"","ocean_disable_breadcrumbs":"default","ocean_breadcrumbs_color":"","ocean_breadcrumbs_separator_color":"","ocean_breadcrumbs_links_color":"","ocean_breadcrumbs_links_hover_color":"","ocean_display_footer_widgets":"default","ocean_display_footer_bottom":"default","ocean_custom_footer_template":"0"},"_links":{"self":[{"href":"https:\/\/arsum.cl\/index.php?rest_route=\/wp\/v2\/pages\/309"}],"collection":[{"href":"https:\/\/arsum.cl\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/arsum.cl\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/arsum.cl\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/arsum.cl\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=309"}],"version-history":[{"count":36,"href":"https:\/\/arsum.cl\/index.php?rest_route=\/wp\/v2\/pages\/309\/revisions"}],"predecessor-version":[{"id":365,"href":"https:\/\/arsum.cl\/index.php?rest_route=\/wp\/v2\/pages\/309\/revisions\/365"}],"up":[{"embeddable":true,"href":"https:\/\/arsum.cl\/index.php?rest_route=\/wp\/v2\/pages\/305"}],"wp:attachment":[{"href":"https:\/\/arsum.cl\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=309"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}