Unidad1 C1 G2

1
Comprensión general de arquitectura de software.
Luis Fernando González Rengifo, Manuel Felipe López Cuellar, Andrés Felipe Vanegas
Monroy, Daniel Felipe Murcia Báez
Facultad de ingeniería de sistemas, universidad del Tolima Arquitectura de software
ING. German Hernández Rengifo 11 de septiembre de 2020

2
Tabla de Contenido
Introducción .................................................................................................................................................. 4
Objetivo General ........................................................................................................................................... 6
Objetivos específicos ................................................................................................................................ 6
Desarrollo de los Temas Comprensión General de Arquitectura de Software .............................................. 7
Arquitectura de Software .............................................................................................................................. 8
Actividades que Hace un Arquitecto de Software ...................................................................................... 10
Concepción del Proyecto ........................................................................................................................ 10
Figura 3 ....................................................................................................................................................... 11
Requerimientos ....................................................................................................................................... 12
Figura 4 ....................................................................................................................................................... 13
Diseño del sistema .................................................................................................................................. 14
Figura 5 ....................................................................................................................................................... 15
Construcción y pruebas del sistema ........................................................................................................ 16
Figura 6 ....................................................................................................................................................... 17
Liberación ............................................................................................................................................... 18
Procesos de Arquitectura ............................................................................................................................ 19
Figura 7 ....................................................................................................................................................... 20
Estilos Arquitectónicos ............................................................................................................................... 21
Shared Data (Datos Compartidos) .......................................................................................................... 22
Ventajas y desventajas. ....................................................................................................................... 22
Pizarrón (Blackboard) ............................................................................................................................. 22
Cliente-Servidor ...................................................................................................................................... 23
Capas Jerárquicas .................................................................................................................................... 24
Descomposición Orientada a Objetos ..................................................................................................... 25
Tubos y Filtros ........................................................................................................................................ 25
Modelos de control ................................................................................................................................. 26
3
Arquitecturas de Sistemas Distribuidos .................................................................................................. 27

Ventajas y desventajas ........................................................................................................................ 27
Objetos Distribuidos ............................................................................................................................... 27
Peer-To-Peer ........................................................................................................................................... 28
Service Oriented Architecture (SOA) ..................................................................................................... 29
Tipos de Arquitectos ................................................................................................................................... 30
Arquitecto Empresarial ........................................................................................................................... 30
Algunas Actividades. .......................................................................................................................... 30
Arquitectos de soluciones ....................................................................................................................... 30
Algunas Actividades. .......................................................................................................................... 30
Arquitectos de Aplicación....................................................................................................................... 30
Ejemplos. ............................................................................................................................................ 31
Arquitecto por Lenguaje ......................................................................................................................... 31
Ejemplo. .............................................................................................................................................. 31
Arquitecto por Capa ................................................................................................................................ 31
Ejemplos. ............................................................................................................................................ 31
Arquitecto Could..................................................................................................................................... 32
Ejemplos. ............................................................................................................................................ 32
Arquitecto de Infra Estructura................................................................................................................. 32
Arquitecto de Seguridad. ........................................................................................................................ 32
Arquitectos de Datos ............................................................................................................................... 32
Arquitecto de Información ...................................................................................................................... 33
Conclusiones ............................................................................................................................................... 34
Bibliografía ................................................................................................................................................. 36
4
Introducción
Este inicio de semestre nos vemos ceñidos en una nueva etapa como estudiantes al
encontrarnos con una materia fundamental para nuestro crecimiento como ingenieros de sistemas,
es por ello que con mucho entusiasmo le damos apertura a la materia arquitectura de software, en
esta asignatura encontraremos material de sobra que nos ayudará a conceptualizar diversos temas
de aspectos tecnológicos y a su vez entender la importancia de esta carrera.
Llevaremos a cabo una ilustración para dar apertura, a un tema importante como la
comprensión general de la arquitectura de software y esto a su vez tendrá como contenidos ciertos
aparates que se limitan a responder preguntas relativas a: ¿Qué es arquitectura de software?,
¿Actividades que ejecuta un arquitecto de software?, ¿procesos de arquitectura?, ¿estilos
arquitectónicos?
Siendo importante resaltar lo beneficioso que son estos temas para nuestro crecimiento
como futuros ingenieros de sistemas.
Es por eso que es menester, hablar de la arquitectura de software, pues, aunque a simple
vista es algo que ya podemos comprender, no podemos alejarlo de la realidad que acontece
bastante rigurosidad y responsabilidad, ya que, a la hora de este realizar distinguidas labores,
aquella persona que tenga el titulo arquitecto debe estar altamente capacitado para ejercer y
adentrarse en su materia donde es sobresaliente para diseñar proyectos que giren entorno a
aspectos netamente industriales.

5
Este a su vez tiene derivadas, las cuales son fundamentales pues de esta manera sabremos
si un proyecto tecnológico es factible o no. Pues dependiendo ello se diseñará y se entregará un
buen trabajo donde el cliente se sienta satisfecho con el producto.

6
Objetivo General
Entender y ejemplificar de manera coherente la concepción general de la arquitectura de
software.
Objetivos específicos
• Comprender que es la arquitectura de software.
• Identificar qué actividades hace un arquitecto de software
• Describir los procesos de arquitectura
• Identificar los estilos arquitectónicos
• Describir los tipos de arquitectos de software

7
Desarrollo de los Temas Comprensión General de Arquitectura de Software
La base de cualquier sistema de software es su arquitectura y por años los diseñadores de
software han estado desarrollando sistemas sin tomar en cuenta este aspecto y por lo tanto los
sistemas resultantes no son lo que los clientes desean o en el mejor de los casos no cumple con
todos los objetivos establecidos, por lo tanto se realizan sistemas sin calidad y se requiere de más
tiempo y esfuerzo para repararlos, El proceso del desarrollo de la Arquitectura de Software es un
paso muy importante en el desarrollo de sistemas de software complejos y grandes, donde un gran
número de personas deben colaborar para el desarrollo de la misma (clientes, usuarios finales,
desarrolladores, administradores de proyectos, los que le darán mantenimiento, etc.), donde se
define a alto nivel los componentes y su interrelación, así como su responsabilidad dentro del
sistema. La Arquitectura de Software deberá plasmar el(los) estilos arquitectónicos en que estará
basada, así como fundamentar el uso del mismo para satisfacer los requerimientos funcionales y
los atributos de calidad, dejando plasmado en un documento todas las decisiones que se hayan
tomado (tradeoffs, reutilización de componentes, evaluación de la arquitectura, etc.) para que esté
a su vez sirva como medio de comunicación entre los stakeholders. (Araceli, 2006)
8
Arquitectura de Software
La arquitectura de software es un concepto fácil de entender y que la mayoría de los
ingenieros aprecian intuitivamente, sobre todo los que tienen un poco de experiencia, pero resulta
difícil definirlo con precisión. En concreto, es difícil dibujar una línea precisa entre el diseño y la
arquitectura, la arquitectura es un aspecto de diseño que se concentra en algunas características
específicas.
En An Introduction to Software Architecture (Introducción a la arquitectura de software),
David Garlan y Mary Shaw sugieren que la arquitectura es un nivel de diseño que se centra en
aspectos: "Beyond the algorithms and data structures of the computation; designing and
specifying the overall system structure emerges as a new kind of problem. Structural issues
include gross organization and global control structure; protocols for communication,
synchronization, and data access; assignment of functionality to design elements; physical
distribution; composition of design elements; scaling and performance; and selection among
design alternatives." (Más allá de los algoritmos y estructuras de datos de la computación; el
diseño y la especificación de la estructura general del sistema emergen como una clase nueva de
problema. Los aspectos estructurales incluyen la estructura global de control y la organización
general; protocolos de comunicación, sincronización y acceso de datos; asignación de funciones
para diseñar elementos; distribución física, composición de elementos de diseño; ajuste y
rendimiento; y selección entre otras alternativas de diseño). (IBM Corp, 2006)

9
Figura 1 Figura 2
Arquitectura de software Arquitectura
Nota. La arquitectura de software Nota. La arquitectura va más allá de

también se relaciona con aspectos como cuatro paredes y un techo, cada
rendimiento, usabilidad, presupuesto, edificación tiene un significado en una
tecnología e ciudad, localidad o lugar donde se
incluso cuestiones estéticas. encuentre ubicado, ya que pueden
Tomada de (INTERWARE, 2018) simbolizar hitos urbanos con el pasar del
tiempo. Tomada de (Definición XYZ,
2015)
10
Actividades que Hace un Arquitecto de Software
Concepción del Proyecto
Un proyecto de desarrollo de software, particularmente cuando se trata de un desarrollo a
la medida, inicia generalmente por una etapa en la cual se debe de generar una propuesta técnica
y económica, muchas veces en un periodo corto de tiempo. En esta etapa, el arquitecto juega un
papel muy importante pues en general en él recae la responsabilidad de realizar una traducción de
las necesidades que expresa un cliente hacia una solución técnica preliminar, que es una pieza
clave para producir una estimación del esfuerzo necesario para realizar el desarrollo. El arquitecto
puede, de hecho, también participar en el trabajo de estimación del sistema. Durante esta etapa
del proyecto, el arquitecto debe hacer uso de habilidades técnicas (“duras”) y no técnicas
(“suaves”). Como parte de las habilidades técnicas, debe poder identificar estilos arquitectónicos
y tecnologías que sean apropiados para resolver el problema y proponer una solución preliminar.
Como parte de las habilidades no-técnicas, debe ser capaz de realizar un análisis de las
necesidades del cliente, especialmente desde una perspectiva de negocio y poder explicar la
solución técnica que propone a los distintos involucrados del proyecto.

11
Figura 3
Nota. Línea plana ilustración de gráfico nació proyecto de inicio de proyecto de proceso de
la idea de éxito para la bandera del sitio web y la página de destino, infografía e icono. Tomada
de (123RF, s.f.)
12
Requerimientos
Durante la fase de requerimientos, el arquitecto de software se involucra con los
requerimientos que influyen en la arquitectura (“drivers”) y particularmente con respecto a los
atributos de calidad del sistema. El arquitecto debe preocuparse por que se identifiquen atributos
de calidad pertinentes para el sistema (alineados a los objetivos de negocio) y que las métricas
asociadas estén justificadas. En caso de que el cliente solicite atributos de calidad con métricas
muy demandantes (por ejemplo, una disponibilidad del 99.99%) debe ser capaz de entender la
justificación de esas métricas y, en caso necesario, debe poder negociar con el cliente para
establecer métricas adecuadas. Nuevamente, el arquitecto debe emplear aquí una combinación de
habilidades “duras” y “suaves” con el fin de lograr una identificación adecuada de los
requerimientos que influirán sobre el diseño arquitectónico.

13
Figura 4
Nota. Una etapa fundamental en proyectos de ingeniería de software, es la identificación y
documentación de los requerimientos del futuro sistema al comienzo del proyecto, pues en
numerosas ocasiones se ha demostrado que es cuando pueden prevenirse errores que puedan
significar el fracaso del proyecto. Tomada de (Pmoinformatica.com, 2016)

14
Diseño del sistema
La etapa de diseño del sistema es aquella donde el arquitecto de software juega el papel
principal, particularmente al momento de diseñar la arquitectura. Aquí el arquitecto debe hacer
uso de todas sus habilidades técnicas con el fin de establecer una solución técnica pertinente que
satisfaga, en la medida de lo posible, los requerimientos que influyen en la arquitectura. Durante
la etapa de diseño, el arquitecto debe también hacer uso de muchas habilidades no-técnicas. La
comunicación durante esta etapa es fundamental, ya que el arquitecto debe ser capaz de comunicar
el diseño, y las decisiones que lo llevaron al mismo, ya sea de forma escrita, como parte de la
documentación de la arquitectura, o bien de forma oral al explicar el diseño de la arquitectura al
equipo de desarrollo. Durante la evaluación del diseño de la arquitectura, el arquitecto debe ser
capaz de presentar el contexto del problema y el diseño de la arquitectura al comité de evaluación,
y debe ser capaz de responder a las preguntas de dicho comité, o bien de aceptar las observaciones
que se hacen al diseño.

15
Figura 5
Nota. Durante el diseño de la arquitectura, el arquitecto toma como entrada los
requerimientos de influyen la arquitectura (drivers) y produce un diseño arquitectónico. Tomada
de (Diseño De Software, 2016)

16
Construcción y pruebas del sistema
Durante de la construcción del sistema, el esfuerzo técnico del arquitecto disminuye, aunque
esto no significa que ya no se realizan actividades técnicas. En esta etapa, desde un punto de vista
técnico, el arquitecto debe terminar de completar las partes faltantes del diseño de la arquitectura
y corregir las decisiones previas que hayan resultado ser equivocadas. Desde un punto de vista
no-técnico, el esfuerzo aumenta pues el arquitecto debe enfocarse en cuidar que el sistema se
desarrolle de acuerdo a la arquitectura que se definió para el mismo. Aquí el arquitecto juega un
papel de mentor y muchas veces debe explicar cuestiones del diseño del sistema al equipo de
desarrollo. El arquitecto puede también realizar actividades de aseguramiento de calidad tales
como inspecciones de productos de trabajo, ya que su nivel técnico y conocimiento del dominio
del problema le da una ventaja para identificar problemas que posiblemente podrían no ser
identificados por ingenieros con un nivel técnico y conocimiento del dominio del problema
menores. Al momento de realizar pruebas del sistema, la participación del arquitecto es
importante, particularmente al momento de realizar pruebas relativas a los atributos de calidad
del sistema.
17
Figura 6
Nota. Dependiendo del tamaño de la Empresa que usara el Sistema y el riesgo asociado a
su uso. Tomada de (Prueba, implementación y mantenimiento del sistema, s.f.)

18
Liberación
Al momento de implantar el sistema en el ambiente productivo, muchas veces es necesario
realizar ajustes finos sobre el sistema, en particular una vez que el sistema ya está operando en el
ambiente de uso definitivo. La participación del arquitecto puede estar enfocada a realizar ajustes
finos de la aplicación con el fin de lograr un funcionamiento óptimo de la misma. es importante
también mencionar los procesos de arquitectura; La arquitectura de procesos, en general
identificar que procesos definen una estructura funcional y se anticipa al proceso mismo,
representa el conjunto de Procesos Esenciales de la empresa, sus interrelaciones entre sí y con
algunos Procesos de Soporte y de Administración.
Para esta Arquitectura se utilizan los “Diagramas de Arquitectura de Procesos” (PAD –
Process Architecture Diagram, por sus siglas en inglés), dichos diagramas son el portafolio de
procesos de la empresa y una representación o modelado detallado de las actividades que se
realizan en ellos.
Los diagramas PAD son los responsables de la estrategia de negocios, ya que definen
objetivos, metas y acciones, que deberán estar contemplados en los procesos esenciales de la
organización, asegurando así, que sean considerados en la estrategia de Tecnologías de
Información (TICs), diseñada para soportar dichos procesos.
Con la incorporación de las TICs contar con una arquitectura de procesos, desde una
perspectiva sistemática es de gran importancia, pues comprende una especificación conceptual de
la estrategia de la empresa sobre la cual se sustentan sus servicios de información.

19
Procesos de Arquitectura
La arquitectura de procesos, en general identifica que procesos definen una estructura
funcional y se anticipa al proceso mismo, representa el conjunto de Procesos Esenciales de la
empresa, sus interrelaciones entre sí y con algunos Procesos de Soporte y de Administración.
Para esta Arquitectura se utilizan los “Diagramas de Arquitectura de Procesos” (PAD –
Process Architecture Diagram, por sus siglas en inglés), dichos diagramas son el portafolio de
procesos de la empresa y una representación o modelado detallado de las actividades que se
realizan en ellos.
Los diagramas PAD son los responsables de la estrategia de negocios, ya que definen
objetivos, metas y acciones, que deberán estar contemplados en los procesos esenciales de la
organización, asegurando así, que sean considerados en la estrategia de Tecnologías de
Información (TICs), diseñada para soportar dichos procesos.
Con la incorporación de las TICs contar con una arquitectura de procesos, desde una
perspectiva sistemática es de gran importancia, pues comprende una especificación conceptual de
la estrategia de la empresa sobre la cual se sustentan sus servicios de información.
La arquitectura de procesos es un elemento esencial del modelo de negocios de toda

20
organización, en este trabajo se propone la forma de convertir las relaciones de las unidades de
trabajo de una empresa, en procesos, mediante un Diagrama de Arquitectura de Procesos (PAD
de Primer corte), y utilizando este como marco de referencia en las tareas de reingeniería o
rediseño de los procesos esenciales para lograr un diagrama mejorado (PAD de Segundo corte).
La conversión de unidades de trabajo a Procesos es una tarea que requiere primeramente la
comprensión de la estructura de ambos términos. (Fernando Arciniega, s.f.)
Figura 7
Nota. dichos diagramas son el portafolio de procesos de la empresa y una representación o
modelado detallado de las actividades que se realizan en ellos. Tomada de (Mayra, s.f.)
21
Estilos Arquitectónicos
La idea detrás de los estilos arquitectónicos es que los sistemas complejos se encuentran
compuestos de diferentes subsistemas que tienen como objetivo trabajar en conjunto para el
desarrollo de un objetivo, y que son controlados por un subsistema mayor. Así, un estilo
arquitectónico presenta los subsistemas, las diferentes reglas para el comportamiento estos y como
interactúan entre sí, con el fin de permitir tomar decisiones acertadas en cuanto el diseño de un
software y permitir su uso a gran escala.
“La arquitectura de software para un Sistema es la estructura o estructuras del sistema, que
están formadas por elementos, sus propiedades visibles, y las relaciones entre ellos” (Clements,
2003). Una estructura de estructuras plantea la abstracción de un sistema a partes atómicas que
tienen una sola función y que permiten la creación de una red de estructuras, en el estudio de los
estilos arquitectónicos, se intenta definir cómo se van a agrupar las diferentes partes en estructuras
y cómo será la comunicación de estas entre sí, como es de esperarse, los diferentes estilos se
acomodan a una serie de necesidades en específico, lo que implica que estos tengan asociados
ventajas y desventajas, las cuáles serán discutidas a lo largo de este documento. Algunos estilos
arquitectónicos son:
22
Shared Data (Datos Compartidos)
Se basa en un conjunto central de datos, diferentes componentes y como estos operan sobre
él. El intercambio de datos es crucial en este estilo, ya que se tiene acceso múltiple a la
información y el almacenamiento es compartido
Ventajas y desventajas.
Presenta una forma eficiente para compartir grandes cantidades de datos, ya que estos no
se transmiten de un componente a otro, pero esto supone que los diferentes sistemas deben estar
de acuerdo con respecto al uso del repositorio.
Pizarrón (Blackboard)
Se basa en un conjunto de datos que determina el comportamiento de la aplicación, cuando
se realiza un cambio en los datos la aplicación responde oportunamente y según qué cambio se
haya realizado.
En cuanto a respaldos de seguridad, control de acceso y recuperación están centralizadas.

23
Cliente-Servidor
El sistema se divide entre un cliente y un servidor, por lo general el procesamiento de datos
se realiza de parte del cliente y del lado del servidor solo se muestra la información y mediante
esta el cliente puede hacer llamados al servidor para que este realice operaciones y de igual manera
estas sean mostradas. Existen 2 tipos de cliente, el cliente fino y el cliente grueso, la diferencia
entre los 2 es que el cliente fino solo se encarga de ejecutar únicamente la capa de presentación y
deja en su totalidad el procesamiento y gestión de datos al servidor, en cambio el cliente grueso
se encarga del procesamiento de datos y la presentación y el servidor se encarga únicamente de
la gestión de los datos.
Se presenta una centralización del control, la integridad de los datos es controlada por el
servidor de forma que un ente no autorizado no puede dañar el sistema, este es escalable ya que
se puede mejorar la experiencia de los clientes o servidores por separado. Sin embargo, se puede
presentar una congestión de tráfico cuando una gran cantidad de clientes envían peticiones
simultáneas al servidor. Y el software está limitado a la cantidad de clientes que pueda soportar
hardware.
24
Capas Jerárquicas
El sistema se divide en diferentes capas que tienen un propósito establecido y la
comunicación de cada capa tiene que ser con la capa inmediatamente anterior, en cuanto a la
recepción de datos, y con la inmediatamente superior para la entrega de datos. Existen dos
modelos para este estilo arquitectónico, el modelo escrito y el modelo relajado, el modelo estricto
es el estilo arquitectónico como tal y el modelo relajado permite que la comunicación pueda de
vez en cuando “saltarse” una o varias capas. En este estilo arquitectónico ninguna capa sabe de la
existencia de las demás y solo se encargan de recibir, procesar y entregar datos.
Este estilo arquitectónico facilita la comprensión la reutilización, portabilidad y
mantenimiento, sin embargo, la interpretación de un comando que afecte varios niveles puede
llegar a afectar negativamente el desempeño, y no siempre es fácil identificar los diferentes
niveles de abstracción necesarios para desarrollar bajo este estilo arquitectónico.

25
Descomposición Orientada a Objetos
El sistema se descompone en los objetos que lo componen y cada uno de estos se comunica
con los demás, en este estilo se hace uso de herencia y polimorfismo, mecanismos que permiten
la reutilización y extensibilidad del código.
Se puede cambiar fácilmente la implementación de un objeto y esto no afecta a los demás,
mediante los mecanismos mencionados anteriormente se te puede reutilizar componentes, y
gracias que cada objeto abstrae un objeto de la realidad es sencillo entender a la estructura que
pueda tener el sistema. De mismo modo, el cambio en una interface afecta a todos los objetos que
la utilizan.
Tubos y Filtros
Existen módulos con función establecida que se comunican con una interacción establecida
como que los datos llegan a un filtro, este los procesa y los envía a otro tubo. Solo existe un tubo
que puede pasar y recibir datos de múltiples filtros, por lo general este tubo es el tubo de control.
26
Se facilita la comprensión pues el pensamiento de secuencias de procesamiento de datos es
muy intuitivo, además que se pueden reutilizar filtros y agregar fácilmente una nueva
transformación al sistema para lograr que evolucione.
Sin embargo, los sistemas se tienen que construir de forma genérica si los diferentes
componentes son reutilizados en algún punto, y los sistemas que sean interactivos serán más
difíciles de construir.
Modelos de control
Se presentan el control centralizado, estilo en el cual un subsistema controla al resto. O el
control basado en eventos, en el que el sistema responde a eventos generados por otro sistema, un
subsistema o por un elemento del ambiente del sistema.
Se presenta un control centralizado, lo que permite que el control del sistema sea más
sencillo, sin embargo, en un sistema basado en control por manejo de eventos, la implantación
estará dependiente de determinados eventos lo que la hace difícilmente escalable.

27
Arquitecturas de Sistemas Distribuidos
El procesamiento de los datos está distribuido en diferentes computadoras. Puesto que los
componentes en las diferentes computadoras pueden estar implementados en lenguajes diferentes,
las computadoras pueden tener diferentes tipos de procesadores, o usar diferentes protocolos de
comunicación, resulta necesario el uso de middleware, software que se encarga de gestionar el
intercambio de datos. Estos son adquiridos comercialmente pues estos poseen un propósito
general.
Ventajas y desventajas
Puesto que el sistema es distribuido, se comparten recursos, de tal manera que se posee una
tolerancia a fallas mayor que toros modelos, y este es fácilmente escalable. Sin embargo, la
implementación posee una mayor complejidad y se presentan problemas de seguridad pues la
aplicación se encuentra distribuida en diferentes computadores
Objetos Distribuidos
Este estilo plantea que el sistema está compuesto de diferentes objetos que proveen y usan
diferentes servicios, en este caso no existe una distinción entre clientes y servidores, existe una
red de computadoras que se comunican mediante el uso de middleware

28
Este estilo permite que la aplicación implementada tenga gran concurrencia pues los
recursos disponibles en la red se pueden utilizar de manera simultánea por diferentes usuarios, lo
que permite que los fallos sean independientes de los componentes, pues cada componente puede
fallar independientemente, y los demás pueden continuar ejecutando sus diferentes acciones
Peer-To-Peer
Estilo arquitectónico que dicta que el sistema debe ser uno descentralizado, en el que se
realicen las diferentes operaciones en cualquier nodo de la red en la que se encuentre, esto permite
que se utilice el poder de almacenamiento y procesamiento de varios computadores, pero es
necesario que cada uno de ellos tenga una copia de la aplicación.
En los sistemas con arquitectura p2p se pueden presentar problemas de seguridad, y exceso
de tiempos de computación o uso de memoria y ancho de banda.

29
Service Oriented Architecture (SOA)
Estilo arquitectónico que se adapta a software que intenta hacer la información accesible a
todo tipo de personas, mediante el uso de una interface web. El servicio que estas aplicaciones
prestan es independiente de cualquier aplicación que pueda llegar a utilizarlo, de tal forma que
una aplicación puede ser construida utilizando diferentes servicios.
El servicio es independiente de las aplicaciones que lo puedan llegar a utilizar. Lo que dicta
que para si se cambia algo en el servicio, la aplicación puede llegar a cambiar, y habrá que cambiar
las interfaces que utilicen el servicio.

30
Tipos de Arquitectos
Arquitecto Empresarial
Se encarga de que los sistemas de software estén alineados con los procesos y la estrategia
de la empresa. Podría haber arquitectura empresarial, sin sistemas de información.
Algunas Actividades.
Especificar la comunicación con sistemas externos. Analizar cómo las personas usan el
software para los procesos de negocios.
Arquitectos de soluciones
Convierte requerimientos en una arquitectura que los resuelve.
Algunas Actividades.
Trabajan con analista de negocios product owners. Diseñan Conexiones entre sistemas.
Facilitan la comunicación entre varios equipos.
Arquitectos de Aplicación
Se enfoca en una o más aplicaciones específicas.

31
Ejemplos.
Arquitecto del sistema contable. Arquitecto de aplicaciones xyz.
Arquitecto por Lenguaje
Muy común en empresas de desarrollo a la medida.
Ejemplo.
Arquitectura.NET. Arquitectura java.
Arquitecto por Capa
Se especializa en una capa o parte del sistema
Ejemplos.
Arquitecto Fronted. Arquitecto Móvil. Arquitecto IOS. Arquitecto Android.

32
Arquitecto Could
Se especializa en computación en la nube
Ejemplos.
Arquitecto AWS. Arquitecto Azure.
Arquitecto de Infra Estructura
se encarga de que el hardware soporte las necesidades del negocio y e software se relaciona
con componentes como: Servidores. Dispositivos de red (enrutadores, firewalls, balanceadores de
carga,). sistemas de almacenamiento (SAN)
Arquitecto de Seguridad.
Se encarga de la seguridad de la red, datos y dispositivos algunas actividades: realizar
pruebas de vulnerabilidad implementar estándares de seguridad.encontrar huecos de seguridad en
arquitecturas.
Arquitectos de Datos
Diseña, despliega y administra los datosde una empresa algunas actividades diseñar como
los datos serán guardados, utilizados e integrados definir procesos para hacer backups, recuperar
y archivar datos. Monitear rendimiento de bases de datos.

33
Arquitecto de Información
Se enfocan en usuarios, y como los datos afectan su experiencia algunas actividades:
Realizar pruebas de usabilidad. Trabajan con diseñadores para mejora la experiencia de usuarios
(UX)
34
Conclusiones
Fue muy interesante encontrar que todos los temas eran bastantes convergentes lo que lo
hace muy sencillo de comprender, la información redactada fue muy sencilla de encontrar es por
eso que investigar por nuestra propia cuenta también será una manera factible para complementar
las dudas que podamos llegar a tener, es por eso que durante el desarrollo del informe se llegó a
la conclusión que estos temas pueden aportar amplios conocimientos necesarios para el
crecimiento profesional del ingeniero de sistemas.
Hablar de la función contextual del arquitecto, lo lleva a cumplir satisfactoriamente sus
labores con una mira de éxito inquebrantable, puesto que basa su trabajo en mantener una línea
lógica para no perder la noción objetiva y general de su creación.
Es necesario que a medida que concluye su labor, es menester ahorrar gastos, para tener la
posibilidad de darle cavidad a otros espacios donde se desarrolla con más fluidez el proceso y
verificar una evolución dentro de sus funciones emanadas por códigos aritméticos, el cual tiende
a buscar continuamente la mayor perfección posible.
Configurarlo de tal manera que se tenga un pleno conocimiento amplio de él, pues las
habilidades del arquitecto es cotejar la marcha de su creación, permitiéndole avocar otras
alternativas para mejorar la eficiencia y su postergada eficacia.
Un arquitecto imperativamente centra sus virtudes en las diferentes plataformas para
acelerar la rapidez con que ejecuta actividades, la forma en que soluciona errores y alcanza las
35
expectativas humanas incluso en los asuntos más complejos respecto a tareas humanamente
inalcanzables en tiempo y espacio.
Así mismo podemos entre ver el enfoque que todo el tiempo y en cada párrafo de nuestro
proyecto es vital la exigencia de la audiencia pública entorno a los avances significativos de la
última década y es la evolución en los comportamientos tecnológicos y biotecnológicos, lo que
incita y en algunas ocasiones se exigen grandes aportes que apuntan a un resultado positivo por
parte de la sociedad, el cual se hace mención a la innovación en estas plataformas, con el ánimo
de curar las carencias de las tareas humanas y hagan más fácil y sencilla la vida de los mismos,
con el compromiso inminente y comprometedor de que actué de tal forma positivamente con un
avance progresivo en la humanidad y permitan la posibilidad de darle un giro total a la calidad de
vida, a la que nos tiene acostumbrados esta materia a través de la historia.

36
Bibliografía
Araceli, N. M. (30 de julio de 2006). Proceso para el desarrollo de arquitecturas de
software basado en DFSS. Obtenido de
https://cimat.repositorioinstitucional.mx/jspui/bitstream/1008/89/2/TE%20197.pdf
IBM Corp. (2006). Concepto: Arquitectura de software. Obtenido de IBM Corp:
https://cgrw01.cgr.go.cr/rup/RUP.es/SmallProjects/core.base_rup/guidances/concepts/sof
tware_architecture_4269A354.html
INTERWARE. (6 de junio de 2018). ¿Cómo lograr una buena arquitectura de software?
[fotografia]. Obtenido de INTERWARE: https://www.interware.com.mx/blog/como- lograr-una-
buena-arquitectura-de-software
Definición XYZ. (2015). Concepto de Arquitectura.[fotografia] Obtenido de Definición
XYZ: https://www.definicion.xyz/2017/02/arquitectura.html
Cervantes, H. (s.f.). El Rol del Arquitecto de Software. Obtenido de Software Guru :
https://sg.com.mx/revista/33/el-rol-del-arquitecto-software
123RF. (s.f.). 123RF.[fotografia] Obtenido de 123RF:
https://es.123rf.com/photo_57231353_línea-plana-ilustración-de-gráfico-nació-proyecto- de-
inicio-de-proyecto-de-proceso-de-la-idea-de-éxito-para-la-b.html
37
Pmoinformatica.com. (3 de Agosto de 2016). 7 Técnicas de levantamiento de
requerimientos software [fotografia]. Obtenido de Pmoinformatica.com:
http://www.pmoinformatica.com/2016/08/tecnicas-levantamiento-requerimientos.html
Diseño De Software. (28 de Mayo de 2016). Arquitectura en el Diseño del software
[fotografia].
Obtenido de DiseñoDe Software:
http://ingenieriadesoftwareisc.blogspot.com/2016/05/arquitectura-en-el-diseno-del-
software.html
Prueba, implementación y mantenimiento del sistema. (s.f.). Prueba, implementación y
mantenimiento del sistema [fotografia]. Obtenido de Prueba, implementación y mantenimiento
del sistema: https://sites.google.com/site/apuntesmercadotecnia/home/1- 7-construccion-de-un-
sitio-web-de-comercio-electronico/1-7-4-prueba-implementacion- y-mantenimiento-del-sistema
Fernando Arciniega. (s.f.). Arquitectura de Procesos. Obtenido de Fernando Arciniega:
https://fernandoarciniega.com/arquitectura-de-procesos/
Mayra, R. (s.f.). Metodología de Procesos [fotografia]. Obtenido de LA
ARQUITECTURA DE PROCESOS: https://mayrareyesbpm.wordpress.com/la-arquitectura-de-
procesos-2/
38
Rincon, C. N. (2017). StuDocu. Obtenido de Estilos arquitectonicos:
https://www.studocu.com/co/document/universidad-pedagogica-y-tecnologica-de-
colombia/ingenieria-de-software/informe/estilos-arquitectonicos/5102680/view
Zapata, M. (22 de Octubre de 2019). YouTube. Obtenido de 10 tipos de arquitectos de
software: https://youtu.be
39

Unidad1 C1 G2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad1 C1 G2

Cargado por

Copyright:

Formatos disponibles

1

Comprensión general de arquitectura de software.

Monroy, Daniel Felipe Murcia Báez

Facultad de ingeniería de sistemas, universidad del Tolima Arquitectura de software

ING. German Hernández Rengifo 11 de septiembre de 2020

Arquitecturas de Sistemas Distribuidos .................................................................................................. 27

de aspectos tecnológicos y a su vez entender la importancia de esta carrera.

aparates que se limitan a responder preguntas relativas a: ¿Qué es arquitectura de software?,

¿Actividades que ejecuta un arquitecto de software?, ¿procesos de arquitectura?, ¿estilos

como futuros ingenieros de sistemas.

bastante rigurosidad y responsabilidad, ya que, a la hora de este realizar distinguidas labores,

aspectos netamente industriales.

si un proyecto tecnológico es factible o no. Pues dependiendo ello se diseñará y se entregará un

buen trabajo donde el cliente se sienta satisfecho con el producto.

Entender y ejemplificar de manera coherente la concepción general de la arquitectura de

• Comprender que es la arquitectura de software.

• Identificar qué actividades hace un arquitecto de software

• Describir los procesos de arquitectura

• Identificar los estilos arquitectónicos

• Describir los tipos de arquitectos de software

Desarrollo de los Temas Comprensión General de Arquitectura de Software

La base de cualquier sistema de software es su arquitectura y por años los diseñadores de

tiempo y esfuerzo para repararlos, El proceso del desarrollo de la Arquitectura de Software es un

desarrolladores, administradores de proyectos, los que le darán mantenimiento, etc.), donde se

La arquitectura de software es un concepto fácil de entender y que la mayoría de los

arquitectura, la arquitectura es un aspecto de diseño que se concentra en algunas características

En An Introduction to Software Architecture (Introducción a la arquitectura de software),

synchronization, and data access; assignment of functionality to design elements; physical

design alternatives." (Más allá de los algoritmos y estructuras de datos de la computación; el

problema. Los aspectos estructurales incluyen la estructura global de control y la organización

general; protocolos de comunicación, sincronización y acceso de datos; asignación de funciones

para diseñar elementos; distribución física, composición de elementos de diseño; ajuste y

rendimiento; y selección entre otras alternativas de diseño). (IBM Corp, 2006)

Arquitectura de software Arquitectura

Nota. La arquitectura de software Nota. La arquitectura va más allá de

tiempo. Tomada de (Definición XYZ,

Actividades que Hace un Arquitecto de Software

Concepción del Proyecto

Un proyecto de desarrollo de software, particularmente cuando se trata de un desarrollo a

solución técnica que propone a los distintos involucrados del proyecto.

Durante la fase de requerimientos, el arquitecto de software se involucra con los

requerimientos que influyen en la arquitectura (“drivers”) y particularmente con respecto a los

requerimientos que influirán sobre el diseño arquitectónico.

Nota. Una etapa fundamental en proyectos de ingeniería de software, es la identificación y

significar el fracaso del proyecto. Tomada de (Pmoinformatica.com, 2016)

Diseño del sistema

principal, particularmente al momento de diseñar la arquitectura. Aquí el arquitecto debe hacer

satisfaga, en la medida de lo posible, los requerimientos que influyen en la arquitectura. Durante

documentación de la arquitectura, o bien de forma oral al explicar el diseño de la arquitectura al

capaz de presentar el contexto del problema y el diseño de la arquitectura al comité de evaluación,

que se hacen al diseño.

Nota. Durante el diseño de la arquitectura, el arquitecto toma como entrada los

requerimientos de influyen la arquitectura (drivers) y produce un diseño arquitectónico. Tomada

de (Diseño De Software, 2016)

Construcción y pruebas del sistema

desarrollo. El arquitecto puede también realizar actividades de aseguramiento de calidad tales

menores. Al momento de realizar pruebas del sistema, la participación del arquitecto es

importante, particularmente al momento de realizar pruebas relativas a los atributos de calidad

su uso. Tomada de (Prueba, implementación y mantenimiento del sistema, s.f.)

Al momento de implantar el sistema en el ambiente productivo, muchas veces es necesario

finos de la aplicación con el fin de lograr un funcionamiento óptimo de la misma. es importante

también mencionar los procesos de arquitectura; La arquitectura de procesos, en general

representa el conjunto de Procesos Esenciales de la empresa, sus interrelaciones entre sí y con