PERIODOS EVOLUTIVOS DE LA AE

La evolución de la Arquitectura empresarial y el origen de los marcos de referencia

de AE más discutidos: Zachman, FEAF y el estándar TOGAF, tienen comienzo en
la década de los 1960 con la adopción de la terminología inicial y las primeras
propuestas realizadas en caminadas a AE, las cuales fueron avanzando y
estructurándose gracias al aporte de las partes interesadas, esta larga historia
puede ser lógicamente dividida en tres períodos distintos:

1. Sistemas de planificación de negocio

2. Arquitectura Empresarial Temprana
3. Arquitectura Empresarial Moderna

1. SISTEMAS DE PLANIFICACIÓN DE NEGOCIO

Los enfoques de planificación temprana contemplan diversas consideraciones

sobre cómo diseñar sistemas de información corporativa basados en una
estrategia de organización, el flujo de datos entre departamentos, los
proveedores y los pedidos, factores críticos de éxito, los requerimientos de
información de gestión y las decisiones. Sin embargo, los primeros orígenes
del concepto moderno de AE se remontan a la metodología de Planificación
Business Systems (BSP) iniciada por IBM en la década de 1960 y dirigida por
Duane P. [1]

BSP

Los aspectos más importantes de la primera edición de BSP (BSP 1975

encaminados a la AE son:
 En la metodología BSP las actividades se llevan a cabo por un grupo
dedicado de expertos (BSP equipo de estudio), cuyas responsabilidades
incluyen la recopilación de datos mediante entrevistas a gerentes y el
desarrollo de planes de sistemas de información de arriba hacia abajo.
[1]

 En la metodología BSP los planes de sistemas de información describen

la relación entre la organización, los procesos de negocio, datos y
sistemas de información. [1]

 BSP utiliza matrices de relación, redes de sistemas de información,

diagramas de flujo, y otras técnicas para modelar procesos, sistemas y
datos. BSP se lleva a cabo de manera escalonada a partir de la
identificación de los objetivos del negocio, la definición de los procesos
de negocio y los datos, el análisis del entorno de TI existente y el
desarrollo de uno deseado.[1]
 BSP fue la primera y más ampliamente metodología de planificación utilizada
por diferentes empresas. Todas estas metodologías utilizan la noción de la
arquitectura como una descripción formal de la relación entre negocio y TI. [1]

Las ediciones posteriores de BSP (BSP 1984) utilizan el concepto de

arquitectura para describir la relación entre los procesos de negocio y las
clases de datos (Periasamy 1993; Periasamy y Feeny, 1997). La metodología
BSP se muestra en la Figura 1.

2. ARQUITECTURA EMPRESARIAL TEMPRANA

La comprensión moderna de AE entendida como una estructura lógica que se

encarga de la descripción de la organización, fue introducida por primera vez en
1986 como resultado de un proyecto de investigación patrocinado por un grupo de
cincuenta empresas que incluían a IBM, cuyo principal tema fue la Integración de
sistemas de información y el Negocio. (PRISM: Dispersion and Interconnection: Approaches to
Distributed Systems Architecture, CSC Index, Cambridge, MA (1986).)

PRISM

El marco PRISM fue el primer marco de AE publicado en la comprensión moderna

de este concepto, organiza una descripción arquitectónica en 16 categorías de
acuerdo a cuatro dominios (organización, datos, aplicaciones infraestructura) y
cuatro tipos (inventario, principios, modelos y estándares). (1)

El marco PRISM EA se muestra en la Figura 2.

Zachman

Un año después, en 1987, un marco similar para la organización de la

documentación arquitectónica fue publicado por un especialista en marketing de
IBM, John Zachman. El Marco Zachman organiza una descripción arquitectónica
en 15 categorías de acuerdo a cinco perspectivas (planificador, propietario,
diseñador, constructor, y subcontratistas) y tres interrogativos (qué, cómo y
dónde). (1)

Cinco años después, en 1992, la versión extendida de la “Zachman Framework”

fue publicado en el IBM Systems Journal (Sowa y Zachman 1992a). La versión
extendida del Marco Zachman organiza una descripción arquitectónica en 30
categorías de acuerdo a cinco perspectivas (planificador, propietario, diseñador,
constructor, y subcontratistas) y seis interrogativos (qué, cómo, dónde, quién,
cuándo y por qué).

NIST

En 1989, el Nacional Instituto de Estándares y Tecnología (NIST) publicó la

primera guía oficial de AE (Rigdon 1989). El modelo NIST AE organiza una
descripción arquitectónica en cinco diferentes niveles de arquitectura: la unidad de
negocio, información, sistemas de información, de datos, y sistema de suministro.
El modelo NIST AE se muestra en la Figura 3.
El concepto formal de “arquitectura empresarial” es determinado por primera vez
gracias a Gary L. Richardson en 1990 como resultado de analizar la aplicación del
marco PRIMS en una empresa petrolera, se puntualiza la AE como una
arquitectura que “define e interrelaciona datos, hardware, software, y recursos de
comunicaciones, así como la organización de apoyo necesaria para mantener la
estructura física global requerido por la arquitectura” ( G.L. Richardson, B.M. Jackson, G.W.
Dickson: A Principles- Based Enterprise Architecture: Lessons from Texaco and Star Enterprise, MIS Quarterly (14:4),
pp.385-403 (1990))

Metodología EAP

La primera metodología AE llamada arquitectura de la empresa Planificación

(PEA) fue propuesto por Spewak y Hill (1992). “EAP tiene sus raíces en el BSP de
IBM” (Spewak & Hill 1992, p.53) y prescribe esencialmente la siguiente secuencia
de pasos para la práctica de AE:

1. Comprender y documentar el estado actual de una organización.

2. Desarrollar el estado futuro deseado de una organización.
3. Analizar las diferencias entre los estados actuales y futuras.
4. Preparar el plan de implementación.
5. Implementar el plan.

Posteriormente, la metodología EAP ha servido de base para muchas modernas

Metodologías de AE (Spewak y Tiemann 2006). La metodología de EAP “pastel de
bodas” se muestra en la Figura 4. Al mismo tiempo, la Oficina de Responsabilidad
del Gobierno (GAO) publicó una metodología de desarrollo de la arquitectura en
cierto modo similar recomendado para las agencias federales (GAO 1992).
Esta metodología se compone de ocho pasos:

1. Misión y estrategia de identificación

2. Identificación y análisis de funciones
3. Las necesidades de información de identificación y análisis
4. Datos necesita identificación y análisis
5. Aplicaciones
6. definición del sistema lógico
7. identificación arquitectura Alternativa y análisis
8. Target selección arquitectura

TAFIM

En 1994, surge Marco de Arquitectura Técnica para la Gestión de la Información

(TAFIM), introducido por La  Agencia de
Sistemas de Información de Defensa (DISA), con el fin de acelerar la entrega de
sistemas de información, reducir sus costos, y promover la integración y la
flexibilidad, este modelo de referencia proporciono orientación a nivel empresarial
al Departamento de Defensa de los Estados Unidos (DOD) en toda su
infraestructura técnica identificando servicios, estándares, conceptos,
componentes y configuraciones.

TAFIM describe práctica AE como un proceso iterativo de siete pasos, incluyendo

la documentación de la línea de base y luego dirigirse estados, el análisis de los
espacios entre ellos, la preparación de los planes de aplicación, y los siguientes
(1996b TAFIM).

TAFIM recomienda que describe cuatro dominios de AE: organización del trabajo,
de información, aplicaciones y tecnología (1996b TAFIM).
 3. ARQUITECTURA EMPRESARIAL MODERNA

En 1996 fue aprobada por el congreso de los Estados Unidos la ley Clinger-
Cohen, conocida como la ley para la reforma de la gestión de la tecnología de la
información, en ella se exige el uso de principios de gestión basados en el
rendimiento para la adquisición de sistemas de TI. Por tanto el Gobierno Federal y
todos sus departamentos comenzaron a desarrollar arquitecturas consistentes
compatibles con el modelo NIST AE, con el fin de mejorar el uso de sistemas de
información (OMB 1997).

FEAF

Como respuesta, en 1999 el Consejo Federal CIO inició el programa Federal

Enterprise Architecture (FEA) y publicó el marco correspondiente FEA (FEAF)
(FEA 2001; FEAF 1999). FEAF se basa en la metodología de EAP y alineado con
el modelo de NIST AE (FEAF 1999; Thomas et al 2000;. Zachman & Sessions
2007).

Por lo tanto, FEAF determina que se deben seguir la misma secuencia de pasos
para la práctica de AE, pero recomienda describir negocios, datos, aplicaciones y
arquitecturas de tecnología de una manera segmentada. De manera similar a
EAP, se afirma que FEAF se basa en el Marco Zachman; Sin embargo, el Marco
Zachman está de nuevo “utilizado” sólo como un símbolo sin ningún tipo de
consecuencias de largo alcance (FEAF 1999, pp.20-23).
Posteriormente de que se aprobara la Ley Clinger-Cohen en 1996 TAFIM fue
remplazado por el concepto Comando, Control, Informática, Comunicaciones,
Inteligencia, Vigilancia, y Reconocimiento (C4ISR), un marco para organizar la
información multimedia que fue retirado oficialmente en el 2000, C4ISR, a su vez
fue reemplazado por El Marco de Arquitectura del Departamento de Defensa 
(DoDAF) en 2003.
TOGAF

Una vez remplazado TAFIM toda su documentacion se le dio explicitamente a The

Open Group y sirvieron de base para la creación del marco de arquitectura
empresarial TOGAF ® norma iniciada en 1995, ampliando los conceptos
encontrados en el marco TAFIM. TOGAF 7 se lanzó en diciembre de 2001 como
la "Edición técnica", seguido de TOGAF 8 Enterprise Edition en diciembre de
2002; luego se actualizó a TOGAF 8.1 en diciembre de 2003. El Open Group se
hizo cargo de TOGAF en 2005 y lanzó TOGAF 8.1.1 en noviembre de 2006.
TOGAF 9 se introdujo en 2009, con nuevos detalles sobre el marco general,
incluyendo un aumento de pautas y técnicas. La versión más reciente de TOGAF
es TOGAF 9.1, que se lanzó en 2011.

Actualmente TOGAF (2011) es la publicación más citada y ampliamente en la

literatura AE (Simon et al. 2013). Encarna la comprensión moderna de la AE y se
considera incluso como un marco de facto estándar de la industria en la práctica
de AE por algunos autores (Brown y Obitz 2011; Dietz y Hoogervorst 2011;
Gosselt 2012;. Lankhorst et al 2010; Sarno y Herdiyanti 2010; Sobczak 2013).
Imágenes

Referenciar

PROCESO DE DESARROLLO DE SOFTWARE

Proceso de desarrollo de software

Un proceso de desarrollo de software es un conjunto de personas, estructuras de
organización, reglas, políticas, actividades y sus procedimientos, componentes de
software, metodologías, y herramientas utilizadas o creadas específicamente para
definir, desarrollar, ofrecer un servicio, innovar y extender un producto de software.
https://sg.com.mx/revista/1/procesos-software

Para que un proceso de software sea efectivo debe adaptase a las necesidades
de la empresa y su funcionalidad haber sido probada en la práctica, es efectivo
cuando habilita a la organización a incrementar la productividad, ya que permite
estandarizar esfuerzos, promover reusó, repetición y consistencia entre proyectos,
permite introducir mejores prácticas, y orienta a la organización a que las
herramientas deben ser utilizadas para soportar un proceso.

El proceso de software desde el punto de vista de mantenimiento y soporte

permite definir claramente como se manejan los cambios y liberaciones a sistemas
de software existentes, cómo lograr la transición del software a la operación y
como ejecutar los esfuerzo de operación y soporte.

LAS ETAPAS DEL PROCESO DE DESARROLLO DE SOFTWARE

Cualquier sistema de información va pasando por una serie de fases a lo largo de
su vida. Su ciclo de vida comprende una serie de etapas entre las que se
encuentran las siguientes: (r)

- Planificación
- Análisis
- Diseño
- Implementación
- Pruebas
- Instalación o despliegue
- Uso y mantenimiento
PSP – Personal Software ProcessSM
Personal Software Process (PSP) es un proceso diseñado para ayudar a los
ingenieros de software a controlar, manejar y mejorar su trabajo. PSP está basado
en una motivación: La calidad de software depende del trabajo de cada uno de los
ingenieros de software. Debido a que los costos de personal constituyen 70% del
costo del desarrollo de software, las capacidades y hábitos de trabajo de los
ingenieros determinan en gran manera los resultados del desarrollo de software.

El PSP puede ser usado por ingenieros para estructurar y disciplinar el desarrollo
de software. El ingeniero de software podrá planear mejor el trabajo, conocer con
precisión el desempeño, medir la calidad de productos, y mejorar las técnicas.
PSP puede ser aplicado en:

 Desarrollo de programas.
 Definición de requerimientos.
 Documentación.
 Pruebas de sistemas.
 Mantenimiento de sistemas.

RUP

El Rational Unified Process (RUP) es un proceso de software desarrollado y

comercializado por Rational Software (ahora parte de IBM). RUP está diseñado
alrededor de seis mejores prácticas para el desarrollo de software:

 Desarrollar de manera iterativa.

 Administrar los requerimientos.
 Utilizar arquitecturas basadas en componentes.
 Modelar el software visualmente.
 Verificar la calidad de manera continua.
 Controlar los cambios.

RUP es una guía que define roles, actividades, flujos de trabajo y lineamientos
para ejecutar proyectos de software de acuerdo a estas mejores prácticas.

RUP organiza los proyectos de software en dos dimensiones: la del tiempo y la de

las actividades. En base al tiempo, los proyectos se dividen en cuatro fases
secuenciales:

1. Concepción – Definición de alcance, identificación de riesgos.

2. Elaboración – Resolución de riesgos, establecimiento de arquitectura.
3. Construcción – Generación del producto.
 4. Transición – Disponibilidad a la comunidad de usuarios finales.

Las actividades se organizan en nueve diferentes disciplinas que son ejecutadas

durante las diferentes fases.

ARQUITECTURA DE SOFTWARE

Una arquitectura de software define la estructura general de un sistema. Las

arquitecturas varían de acuerdo con el tipo de sistema a desarrollar. Pueden ser
arquitecturas basadas en elementos sencillos o en componentes prefabricados de
mayor tamaño. La selección de una arquitectura afecta aspectos como la
extensibilidad del sistema y debe ser escogida de manera que minimice los
efectos de los cambios que pueda haber en el futuro.

(Complementar, que arquitectura de software se usaría en el proyecto)