UNIVERSIDAD TECNICA DE ESMERALDAS

LUIS VARGAS TORRES

FACULTAD DE INGENIERÍAS
VIII SEMESTRE

FACULTAD:
FACI

CARRERA:
TECNOLOGÍAS DE LA INFORMACIÓN Y LA COMUNICACIÓN

ASIGNATURA:
GESTIÓN DE SOFTWARE

TEMA:
MÉTODOS Y ESTRUCTURAS

AUTOR:
CONSTANTINE FRANCO LUIS VILLACIS OLIVO ROMMEL
PERDOMO CEPEDA ANAHÍ ZAMBRANO ANDRADE MICHAEL
RUALES CORREA KEVIN ZAMBRANO GUANOQUIZA KEVIN

PARALELO:
“B”

JORNADA:
VESPERTINA

PERIODO:
AGOSTO 2022 – DICIEMBRE 2022
ESMERALDAS - ECUADOR
 2.2 Métodos y estructuras
Para proporcionar más información sobre los diferentes aspectos que una arquitectura
empresarial modelo puede abarcar, describiremos una serie de arquitectura bien conocida
marcos. Los frameworks (Estructuras) estructuran técnicas de descripción de arquitectura
por identificar y relacionar diferentes puntos de vista arquitectónicos y el modelado técnicas
asociadas a ellos. No proporcionan los conceptos para el actual modelado, aunque algunos
marcos están estrechamente relacionados con un lenguaje de modelado o conjunto de
lenguajes.

La mayoría de los marcos de arquitectura son bastante precisos al establecer qué elementos
debe ser parte de una arquitectura empresarial. Sin embargo, para garantizar la calidad de la
arquitectura empresarial durante su ciclo de vida, la adopción de un determinado marco es
insuficiente. Las relaciones entre los diferentes tipos de dominios, vistas o capas. de la
arquitectura debe permanecer clara, y cualquier cambio debe llevarse a cabo a través
metódicamente en todos ellos. Para ello, se dispone de una serie de métodos, que ayudan a
los arquitectos en todas las fases del ciclo de vida de las arquitecturas.
2.2.1 Métodos de la arquitectura empresarial
Un método de arquitectura es una colección estructurada de técnicas y pasos de proceso
para crear y mantener una arquitectura empresarial. Los métodos suelen especificar las
diversas fases del ciclo de vida de una arquitectura, qué entregables deben producirse en
cada etapa, y cómo se verifican o prueban. Los siguientes métodos para desarrollo de la
arquitectura vale la pena mencionar:

▪ Aunque está diseñado para el desarrollo de software, Rational Unified Process

(RUP) (Jacobson et al. 1999) es de interés aquí, ya que define un proceso iterativo,
como opuesto al clásico proceso en cascada, que realiza el software agregando
funcionalidad a la arquitectura en cada incremento. Una extensión hacia la empresa
La arquitectura de TI está dada por McGovern et al. (2004) en forma de Proceso
Unificado Empresarial.
▪ La Metodología de Modelado UN/CEFACT (UMM) es un negocio incremental
Metodología de construcción de modelos de proceso e información. el alcance es
restringido intencionalmente a operaciones comerciales, omitiendo tecnología
específica aspectos. El Business Collaboration Framework (BCF), que actualmente
está en desarrollo, será una especialización de la UMM encaminada a definir los
 intercambios de información externa de una empresa y su negocio subyacente
actividades. Véase ONU/CEFACT (2004).

▪ El Método de Desarrollo de Arquitectura TOGAF (ADM) (ver Secc. 2.2.4),

desarrollado por The Open Group, proporciona una fase detallada y bien descrita
para desarrollo de una arquitectura de TI. La versión actual de TOGAF (The Open
Group 2011) proporciona un marco y un método de desarrollo para el desarrollo
empresarial arquitecturas.
▪ El Consejo de Directores de Información ha creado The Federal Enterprise
Framework de Arquitectura (FEAF) acompañado de un práctico y útil manual para
el desarrollo de arquitectura empresarial para organizaciones gubernamentales (CIO
Consejo 2004). Otras iniciativas del gobierno de EE.UU. incluyen el Federal
Arquitectura Empresarial (FEA) del Programa Federal de Arquitectura Empresarial
Gerencia de Oficina (FEAPMO 2004) y Desarrollo de Arquitectura de Tesorería
Proceso por el Departamento del Tesoro (US Treasury 2004).
Varias empresas de consultoría han desarrollado sus propios métodos de arquitectura y
marcos Los ejemplos incluyen DYA de Sogeti, IAF de Capgemini, Enterprise de IBM
Método de arquitectura y Motion de Microsoft. Debido a la propiedad a menudo naturaleza
de estos métodos, no los discutimos en este libro.

2.2.2. El estándar IEEE 1471–2000/ISO/IEC 42010

En el año 2000, la IEEE computer society, aprobó la IEEE 1471-2000 la cual construye una
sólida base teórica para la definición, análisis y descripción de arquitecturas de sistemas.

Este se enfoca principalmente en sistemas intensivos en software, como sistemas de

información, sistemas embebidos, y sistemas compuestos en el contexto de la computación.

IEEE 1471 utiliza el civil Metáfora de la arquitectura para describir arquitecturas de

sistemas de software. En este sentido, proporciona, en los términos de una "práctica
recomendada", un número de valiosos conceptos y términos de referencia, que reflejan el
"generalmente aceptado tendencias en la práctica para la descripción de la arquitectura’ y
que ‘codifican esos elementos en que hay consenso’.
En primer lugar, la norma proporciona un conjunto de definiciones de términos clave como
adquirente, arquitecto, descripción de la arquitectura, modelos arquitectónicos, arquitectura,
ciclo de vida modelo, sistema, parte interesada del sistema, preocupaciones, misión,
contexto, arquitectura vista, punto de vista arquitectónico. Como ideas esenciales notamos
una clara separación entre una arquitectura y sus descripciones de arquitectura (definidas
como medios para arquitecturas de registro), y el papel central de la relación entre
arquitectura Mirador y vista arquitectónica. La norma también proporciona un marco
conceptual, que se significa:

• Explicar cómo los términos clave se relacionan entre sí en un modelo conceptual

para descripción de la arquitectura

 • Explicar el papel de las partes interesadas en la creación y el uso de una arquitectura

descripción;

• Proporcionar una serie de escenarios para las actividades arquitectónicas durante el

ciclo de ciclo: arquitecturas de sistemas únicos, arquitectura iterativa para evolución

de sistemas, arquitectura para sistemas existentes y evaluación arquitectónica.

Además, el estándar proporciona seis prácticas de descripción de arquitectura:

• Documentación arquitectónica referente a identificación, versión y descripción

general información.

• Identificación de los actores del sistema y de sus preocupaciones, establecidos para

ser relevante para la arquitectura.

• Selección de miradores arquitectónicos, conteniendo la especificación de cada

mirador que ha sido seleccionado para organizar la representación de la arquitectura

y las razones por las cuales fue seleccionado.

• Vistas arquitectónicas correspondientes a los miradores seleccionados.

• Coherencia entre vistas arquitectónicas.

• Justificación arquitectónica para la selección de la arquitectura actual a partir de un

número de alternativas consideradas.

IEEE 1471 también proporciona una serie de puntos de vista arquitectónicos relevantes

juntos con sus especificaciones en cuanto a preocupaciones, lenguajes y modelado y

métodos de análisis.
Es importante observar que las descripciones de arquitectura que cumplen con IEEE 1471

se pueden usar para cumplir los requisitos de otros estándares, como el Modelo de

Referencia de proceso distribuido abierto.

2.2.3 The Zachman Framewor

En 1987, John Zachman presentó la primera y más conocida arquitectura empresarial

framework (Zachman 1987), aunque en ese entonces se llamaba ‘Framework for

Arquitectura de Sistemas de Información’. El marco que se aplica a las empresas es

simplemente una estructura lógica para clasificar y organizar lo descriptivo

representaciones de una empresa que son significativas para la gestión de la empresa, así

como al desarrollo de los sistemas de la empresa.

Estos roles se etiquetan de manera un tanto arbitraria como planificador y subcontratista y

son incluido en el marco gráfico que comúnmente se exhibe. Desde el mismo inicio del
marco, algunas otras abstracciones de productos fueron sabía que existía porque era obvio
que además de qué, cómo y dónde, una descripción completa necesariamente tendría que
incluir el primitivo restante interrogativos: quién, cuándo y por qué.

Estos tres interrogativos adicionales se manifestarían como tres columnas adicionales de

modelos que, en el caso de las empresas, representaría: quién hace qué trabajo, ¿cuándo
suceden las cosas y por qué son diferentes elecciones hechas?

Las ventajas del marco de Zachman son que es fácil de entender, aborda la empresa como
un todo, se define independientemente de las herramientas o metodologías, y cualquier
problema se puede mapear contra él para comprender dónde adaptar. Un inconveniente
importante es el gran número de celdas, que es un obstáculo para la aplicabilidad práctica
del marco. Asimismo, las relaciones entre los diferentes las celdas no están tan bien
especificadas. A pesar de estos inconvenientes, Zachman debe ser se le atribuye haber
proporcionado el primer marco integral para la arquitectura empresarial, y su trabajo
todavía se usa ampliamente.

2.2.4 El marco de arquitectura de grupo abierto (TOGAF)

Se originó como un marco genérico y una metodología para el desarrollo de arquitecturas
técnicas, pero evolucionó hacia un marco y método de arquitectura empresarial.

Desde la versión 8 en adelante. TOGAF está dedicado a las arquitecturas empresariales.

TOGAF tiene los siguientes componentes principales:

• Un marco de capacidad de arquitectura, que aborda la organización, los procesos,

las habilidades, los roles y las responsabilidades necesarios para establecer y operar
una función de la arquitectura dentro de una empresa.
• El Método de Desarrollo de Arquitectura (ADM), que proporciona una “manera de
trabajando’ para arquitectos. El ADM se considera el núcleo de TOGAF, y consiste
en un enfoque cíclico gradual para el desarrollo de la arquitectura empresarial.
• El marco de contenido de la arquitectura, que considera una empresa global
arquitectura compuesta por cuatro arquitecturas estrechamente interrelacionadas:
Business Arquitectura, arquitectura de datos, arquitectura de aplicaciones y
tecnología (TI) Arquitectura.
 • El Enterprise Continuum, que comprende varios modelos de referencia, como el
modelo de referencia técnica, la base de información de estándares de The Open
Group (SIB) y la base de información de bloques de construcción (BBIB).

Métodos y Frameworks

El ADM de TOGAF es iterativo, durante todo el proceso, entre fases, y dentro de las fases.
Para cada iteración del ADM, se debe tomar una nueva decisión. en cuanto a:
• Se definirá la amplitud de la cobertura de la empresa;

• El nivel de detalle a definir;

• La extensión del horizonte temporal al que se apunta, incluido el número y la

extensión de cualesquiera horizontes temporales intermedios;
• Los activos arquitectónicos que se aprovecharán en el continuo empresarial de la
organización, incluidos los activos creados en iteraciones anteriores del ciclo
ADM dentro del empresa y activos disponibles en otras partes de la industria.
Método de desarrollo de arquitectura TOGAF
Estas decisiones deben tomarse sobre la base de una evaluación práctica de disponibilidad
de recursos y competencias, y el valor que puede ser realista que se espera obtener para la
empresa a partir del alcance elegido del trabajo de arquitectura.

Como método genérico, el ADM está destinado a ser utilizado por empresas en una amplia
variedad de diferentes geografías y aplicado en diferentes sectores verticales/industria tipos
Como tal, puede ser, pero no necesariamente tiene que ser, adaptado a necesidades
específicas. necesidades.

2.2.5 Arquitectura dirigida por modelos (MDA) de OMG.

La arquitectura impulsada por modelos (MDA) tiene como objetivo proporcionar un

enfoque abierto e independiente del proveedor para la interoperabilidad. Se basa en los
estándares de modelado del Grupo de gestión de objetos: el Lenguaje de modelado
unificado, la Instalación de meta objetos (MOF) (Grupo de gestión de objetos 2006) y el
Metamodelo de almacén común (CWM) . Las descripciones de aplicaciones independientes
de la plataforma creadas con estos estándares se pueden realizar utilizando diferentes
plataformas abiertas o propietarias, como CORBA, Java, .NET, XMI/XML y servicios web.
El paradigma MDA puede cambiar fundamentalmente la forma en que se desarrolla el
software. MDA quiere elevar el nivel de abstracción en el que se especifican las soluciones
de software mediante la definición de un marco respaldado por una colección de estándares
que establece un estándar para generar código a partir de modelos y viceversa. Ahora, las
herramientas de desarrollo de software basadas en MDA ya admiten la especificación de
software en UML en lugar de en un lenguaje de programación como Java. El OMG ha
ampliado el enfoque de MDA a la capa del modelo independiente de computación (CIM),
en la que se cubren los aspectos comerciales de una empresa. Por lo tanto, MDA comprende
tres niveles de abstracción con mapeos entre ellos.

1. Los requisitos para el sistema se modelan en un modelo independiente de

computación (CIM) que describe la situación en la que se utilizará el sistema.
Este modelo a veces se denomina modelo de dominio o modelo de negocio.
Oculta mucha o toda la información sobre el uso de sistemas automatizados de
procesamiento de datos.
 2. El Modelo independiente de la plataforma (PIM) describe el funcionamiento de
un sistema mientras oculta los detalles necesarios para una plataforma en
particular. Un PIM muestra esa parte de la especificación completa que no
cambia de una plataforma a otra.
3. Un modelo específico de plataforma (PSM) combina las especificaciones en el
PIM con los detalles que especifican cómo ese sistema usa un tipo particular de
plataforma.
UML está respaldado como lenguaje de modelado tanto para PIM como para PSM. A nivel
de la CIM. Ya se ha publicado un lenguaje para la especificación de procesos comerciales y
actualmente se están desarrollando lenguajes para la descripción de reglas comerciales y
modelos comerciales. Al igual que UML, estos nuevos lenguajes se desarrollarán dentro del
marco MDA. Estos desarrollos harán que MDA sea tan relevante para la arquitectura
empresarial como lo es ahora para el desarrollo de software. Una de las características clave
de la MDA es la noción de mapeo. Un mapeo es un conjunto de reglas y técnicas utilizadas
para modificar un modelo para obtener otro modelo. En ciertas situaciones restringidas,
puede ser posible una transformación totalmente automática de un PIM a un PSM, y las
herramientas de desarrollo de software admitirán estas asignaciones automatizadas. Hasta
qué punto es factible la automatización de mapeos entre CIM y PIM sigue siendo un tema
de investigación.

Si estos mapeos se realizan de forma predefinida (formal), se pueden asegurar las relaciones
entre modelos de diferentes niveles de abstracción. Meta Object Facility (MOF) es un
estándar para repositorios que juega un papel central en el marco MDA. Un repositorio
compatible con MOF permite administrar modelos de manera integrada, incluso cuando los
modelos están expresados en diferentes idiomas. Para que un repositorio sea efectivo para
EA, debe ser posible modelar relaciones entre modelos en el repositorio. MOF en sí mismo
no ofrece una solución para esto, pero se pueden agregar modelos en un lenguaje de
modelado como ArchiMate para modelar estas relaciones. Además de MOF, OMG ha
desarrollado la especificación QVT (Consultas, Vistas y Transformaciones) (Object
Management Group 2008), que aborda la forma en que se logran las asignaciones entre
modelos cuyos lenguajes se definen mediante MOF y define una forma estándar de
consultar MOF. modelos y la creación de vistas de estos modelos.
2.2.6 Otros marcos

DoDAF/C4ISR
El marco de arquitectura de comando, control, comunicaciones, computadoras, inteligencia,
vigilancia y reconocimiento fue desarrollado originalmente en 1996, para el Departamento
de Defensa de los EE. UU., para garantizar un enfoque unificador común para el comandos,
servicios militares y agencias de defensa a seguir en la descripción de sus varias
arquitecturas. El marco fue retitulado Marco de Arquitectura del Departamento de Defensa
(DoDAF) en

2003 DoDAF ve la descripción de la arquitectura como una integración de tres vistas

principales: vista operativa, vista del sistema y vista técnica.

RM-ODP
El modelo de referencia para procesamiento distribuido abierto (RM-ODP) es un estándar
ISO/ITU (ITU 1996) que define un marco para la especificación de la arquitectura de
grandes sistemas distribuidos.

Tiene como objetivo proporcionar soporte para Inter funcionamiento, interoperabilidad,

portabilidad y distribución, y por lo tanto permitir la construcción de espacios abiertos,
integrados, flexibles, El estándar tiene cuatro partes:

Parte 1: Referencia, que contiene una descripción general motivacional del estándar y su
concepto (UIT 1996).

Parte 2: Fundamentos, definición de los conceptos, el marco analítico para la descripción

de los sistemas ODP, y un marco general para la evaluación y conformidad (UIT 1995a).

Parte 3: Arquitectura, que describe el marco ODP de puntos de vista para la especificación
de sistemas ODP en diferentes lenguajes de punto de vista (UIT 1995b). Identifica cinco
puntos de vista sobre un sistema y su entorno: empresa, información, computación,
ingeniería y tecnología.

Parte 4: Semántica arquitectónica, mostrando cómo los conceptos de modelado de La Parte

2 y los lenguajes de punto de vista de la Parte 3 se pueden complementar en un número de
técnicas de descripción formal, como LOTOS, Estelle, SDL y Z (UIT 1997).
GERAM
La Arquitectura y Metodología de Referencia Empresarial Genérica (GERAM) (IFIP-IFAC
Task Force 1999) define el genérico relacionado con la empresa conceptos recomendados
para su uso en ingeniería empresarial y proyectos de integración.

Estos conceptos se pueden clasificar en:

• Conceptos orientados al ser humano para describir el papel de los seres humanos
como parte integral de la organización y operación de una empresa y para
apoyar a los humanos durante diseño, construcción y cambio de empresas.
• Conceptos orientados a procesos para la descripción de los procesos de negocio
de la empresa;
• Conceptos orientados a la tecnología para la descripción de la tecnología de
soporte involucrado tanto en la operación empresarial como en los esfuerzos de
ingeniería empresarial (modelado y apoyo al uso del modelo).
El modelo propuesto por GERAM tiene tres dimensiones: la dimensión del ciclo de vida, la
dimensión de creación de instancias que permite diferentes niveles de particularización
controlada, y la dimensión de vista con cuatro vistas: Entidad Modelo Vista de contenido,
Entidad Vista de propósito, vista de implementación de entidad y vista de manifestación
física de entidad. Referencias

al., M. L. (2013). Enterprise Architecture at Work. London: Springer Heidelberg New York
Dordrecht London.
PREGUNTAS
¿Qué proporciona TOGAF?
Es un esquema de arquitectura empresarial que proporciona un enfoque para el diseño,
planificación, implementación y gobierno de una arquitectura empresarial de información.
¿Para qué sirve un método y arquitectura empresarial?
Sirven para establecer y desarrollar la estructura empresarial haciendo uso de técnicas de
modelado y los distintos estándares para garantizar una sólida estructura en la arquitectura
empresarial.

El estándar RM-ODP consta de cuatro partes, ¿cuáles son?

Referencia, Fundamentos, Arquitectura, Semántica Arquitectónica ¿Qué
construye el estándar IEEE 1471-200?
Una sólida base teórica para la definición, análisis y descripción de arquitecturas de
sistemas
¿Qué es un mapeo?
Un mapeo es un conjunto de reglas y técnicas utilizadas para modificar un modelo para
obtener otro modelo.