Articulo de referencia

Arquitectura de software funcional

Una arquitectura de software funcional ( FSA , por sus siglas en inglés) es un modelo arquitectónico que identifica las funciones empresariales , las interacciones y las necesid...

Una arquitectura de software funcional ( FSA , por sus siglas en inglés) es un modelo arquitectónico que identifica las funciones empresariales , las interacciones y las necesidades de TI correspondientes . Estas funciones pueden servir de referencia para que diferentes expertos en el dominio desarrollen sistemas de TI como parte de una empresa colaborativa basada en la información. De esta manera, tanto los ingenieros de software como los arquitectos empresariales pueden crear un entorno organizacional integrado y basado en la información.

Descripción general

Cuando se necesita desarrollar e implementar un sistema de software integrado, normalmente se pueden dividir varias tareas y responsabilidades correspondientes:

  1. Los consultores de gestión estratégica y de negocios establecen objetivos en relación con un proceso empresarial más eficiente y eficaz.
  2. Los ingenieros de la empresa diseñan un proceso de negocio más eficiente y solicitan un sistema de información específico en forma de arquitectura empresarial.
  3. Los ingenieros de software diseñan este sistema de información, que describe los componentes y las características estructurales del sistema mediante un lenguaje de descripción de arquitectura (ADL, por sus siglas en inglés).
  4. Los programadores informáticos codifican los diferentes módulos y, de hecho, implementan el sistema.

La división de trabajo descrita es, en realidad, mucho más compleja e involucra a más actores, pero refleja la participación de personas con diferentes perfiles en la creación de un sistema de software que permite a la organización alcanzar sus objetivos comerciales. Es necesario intercambiar y comprender una amplia variedad de material producido por los distintos actores involucrados en este proceso de desarrollo del sistema.

Especialmente en el campo de la ingeniería de software, se desarrollan y utilizan ampliamente numerosas herramientas (A4 Tool, CAME, ARIS ), lenguajes (ACME, Rapide, UML ) y métodos ( DSDM , RUP , ISPL ). Asimismo, la transición entre ingenieros de software (paso 3) y programadores (paso 4) está altamente formalizada, por ejemplo, mediante el desarrollo orientado a objetos .

Definir objetivos estratégicos (paso 1) y la correspondiente búsqueda de oportunidades y debilidades de negocio es un tema ampliamente debatido e investigado durante más de cien años. Conceptos como la reingeniería de procesos de negocio , el análisis del mercado de software de producto y el análisis de requisitos son ampliamente conocidos y utilizados en este contexto. Estos insumos estratégicos deben emplearse para el desarrollo de un buen diseño empresarial (paso 2), que posteriormente podrá utilizarse para el diseño e implementación del software.

Estudios recientes han demostrado que estas arquitecturas empresariales pueden desarrollarse mediante diversos métodos y técnicas. Antes de analizar en detalle estos métodos y técnicas, se ofrece una definición de arquitectura empresarial :

Una arquitectura empresarial es una base de activos de información estratégica que define la misión, la información necesaria para llevarla a cabo y las tecnologías necesarias para ello, así como los procesos de transición para implementar nuevas tecnologías en respuesta a las necesidades cambiantes de la misión.

Esta definición enfatiza el uso de la arquitectura como una valiosa fuente de información estratégica para la mejora de los procesos de negocio y el desarrollo de los sistemas de información necesarios. Si se definen, mantienen e implementan eficazmente, estos planos institucionales contribuyen a optimizar las interdependencias e interrelaciones entre las operaciones comerciales de una organización y la infraestructura de TI subyacente que las respalda.

Tras leer la definición de arquitectura de software funcional al inicio de esta entrada, podemos considerarla como un tipo de arquitectura empresarial que sirve como referencia para el desarrollo de un sistema de información integrado. Denominarla arquitectura de software funcional anima a los profesionales a utilizarla como insumo estratégico para una arquitectura técnica . Por lo tanto, se requiere una correspondencia formal entre la arquitectura de software funcional y un tipo de ADL (Arquitectura de Desarrollo de Aplicaciones). De esta forma, se puede concretar el uso y la reutilización formales de las arquitecturas empresariales como insumo estratégico para las arquitecturas de software.

Desarrollo

A medida que se expande el alcance de una empresa, se vuelve cada vez más importante que todas las partes involucradas desarrollen y compartan una visión general común de las actividades necesarias en materia de negocios, personal y sistemas de TI. [ 1 ] Una arquitectura de software funcional logra esto al desglosar la organización en funciones de negocio y sus correspondientes necesidades de TI. De esta manera, el ingeniero de la empresa proporciona una referencia esquemática completa que el ingeniero de software puede utilizar en el desarrollo de estos sistemas de TI.

El desarrollo de una arquitectura de software funcional puede realizarse mediante diversos métodos y técnicas (combinados). El objetivo principal será cerrar la brecha entre los ingenieros de la empresa y los ingenieros de software mediante la combinación de diferentes métodos y técnicas. Sin embargo, este objetivo solo se alcanzará cuando la combinación de métodos dé como resultado arquitecturas de software funcionales, claras y completas, desarrolladas y utilizadas por ambas partes.

La optimización de los procesos de negocio internos y externos mediante la reingeniería de procesos es uno de los principales objetivos que una empresa puede tener en momentos de alta presión externa. Un proceso de negocio implica actividades que generan valor con ciertas entradas y salidas, las cuales están interconectadas y, por lo tanto, contribuyen conjuntamente al resultado (producto o servicio) del proceso. La reingeniería de procesos abarca diversas perspectivas sobre cómo transformar la organización. Se centra en el rediseño de procesos, sistemas, políticas y estructuras organizativas estratégicas que agregan valor para optimizar los procesos de una organización. [ 2 ]

Modelar el negocio

En el ámbito de la ingeniería empresarial, se diseñan, prueban y utilizan ampliamente metodologías, métodos y técnicas formales con el fin de ofrecer a las organizaciones soluciones de procesos de negocio reutilizables:

Estas metodologías, técnicas y métodos son más o menos adecuados para modelar la empresa y sus procesos subyacentes. Entonces, ¿cuáles de ellos son los más apropiados para el desarrollo de sistemas de tecnología de la información necesarios para procesos rediseñados eficaces y eficientes? Más importante aún, ¿por qué utilizar una metodología empresarial que consume mucho tiempo cuando los ingenieros de software y de información no pueden o no quieren utilizar los resultados poco claros para el desarrollo de sistemas de TI que permitan la eficiencia? Antes de responder a estas preguntas, se ofrecen breves descripciones de los métodos mencionados anteriormente.

Arquitectura de sistemas abiertos para la fabricación integrada por ordenador

CIMOSA proporciona plantillas y estructuras de modelado interconectadas para codificar los aspectos empresariales, humanos y de TI de los requisitos de la empresa. Esto se realiza desde múltiples perspectivas: información, funciones, recursos y organización. Estas estructuras pueden utilizarse además para estructurar y facilitar el diseño e implementación de sistemas de TI detallados.

La división en distintas vistas lo convierte en una referencia esclarecedora para ingenieros de software y de la empresa. Muestra las necesidades de información para las distintas funcionalidades empresariales (actividades, procesos, operaciones) y los recursos correspondientes. De esta forma, se puede determinar fácilmente qué sistema informático satisfará las necesidades de información en una actividad o proceso específico.

Definición integrada (IDEF)

IDEF es una técnica de modelado estructurado , desarrollada inicialmente para el modelado de sistemas de fabricación. La Fuerza Aérea de los Estados Unidos ya la utilizaba en 1981. En un principio, contaba con cuatro notaciones diferentes para modelar una empresa desde una perspectiva específica: IDEF0 , IDEF1 , IDEF2 e IDEF3, destinadas al análisis funcional, de datos, dinámico y de procesos, respectivamente. En las últimas décadas, se han desarrollado progresivamente diversas herramientas y técnicas para la integración de estas notaciones.

IDEF muestra claramente cómo fluye un proceso de negocio a través de diversas funciones empresariales descompuestas, con sus correspondientes entradas, salidas y actores. Al igual que CIMOSA, también utiliza diferentes vistas empresariales. Además, IDEF se puede transformar fácilmente en diagramas UML para el desarrollo posterior de sus sistemas. Estas características positivas lo convierten en un método potente para el desarrollo de arquitecturas de software funcionales.

Redes de Petri

Las redes de Petri son herramientas conocidas para modelar sistemas de fabricación. [ 8 ] Son altamente expresivas y proporcionan buenos formalismos para el modelado de sistemas concurrentes . Sus propiedades más ventajosas son la representación sencilla de estados, las transiciones de sistemas concurrentes y la capacidad de modelar la duración de las transiciones.

Por lo tanto, las redes de Petri pueden utilizarse para modelar ciertos procesos de negocio con sus correspondientes estados, transiciones, actividades y resultados. Además, pueden emplearse para modelar diferentes sistemas de software y las transiciones entre ellos. De esta forma, los programadores las utilizan como referencia esquemática para la codificación.

En los últimos años, varios intentos han demostrado que las redes de Petri pueden contribuir al desarrollo de la integración de procesos de negocio. Una de ellas es la metodología Model Blue, desarrollada por el Laboratorio de Investigación de IBM en China, que resalta la importancia de la integración de negocios basada en modelos como un enfoque emergente para la creación de plataformas integradas. [ 9 ] También se muestra una correspondencia entre su visión de negocio de Model Blue y una red de Petri equivalente, lo que indica que su investigación reduce la brecha entre el negocio y las TI. Sin embargo, en lugar de redes de Petri, utilizan su propia visión de TI de Model Blue, que se puede derivar de su visión de negocio mediante un motor de transformación.

Lenguaje de modelado unificado

UML es un lenguaje de modelado ampliamente aceptado para el desarrollo de sistemas y aplicaciones de software. La comunidad orientada a objetos también intenta utilizar UML para fines de modelado empresarial. Hacen hincapié en el uso de objetos empresariales u objetos de negocio a partir de los cuales se construyen sistemas empresariales complejos. Una colección de estos objetos y las interacciones correspondientes entre ellos pueden representar un sistema o proceso empresarial complejo. Mientras que las redes de Petri se centran en la interacción y los estados de los objetos, UML se centra más en los objetos de negocio en sí mismos. A veces se les llama "bloques de construcción empresariales", que incluyen recursos, procesos, objetivos, reglas y metamodelos. [ 10 ] Aunque UML de esta manera se puede utilizar para modelar un sistema de software integrado, se ha argumentado que la realidad empresarial se puede modelar con un lenguaje de modelado de software. En respuesta, la comunidad orientada a objetos crea extensiones empresariales para UML y adapta el lenguaje. UEML se deriva de UML y se propone como un lenguaje de modelado empresarial. La pregunta sigue siendo si esta transformación empresarial es la correcta. Anteriormente se dijo que UML en combinación con otros métodos empresariales "puros" puede ser una mejor alternativa.

Diagramas de funciones empresariales

EFD es una técnica de modelado utilizada para la representación de funciones empresariales y sus interacciones. En estas representaciones, se pueden modelar diferentes procesos de negocio mediante el uso de "módulos de función" y disparadores. Un proceso de negocio inicial proporciona diferentes entradas a diferentes funciones. Un proceso que fluye a través de todas las funciones y subfunciones crea múltiples salidas. Los diagramas de funciones empresariales ofrecen una representación detallada y fácil de usar de un proceso de negocio y sus funciones, entradas, salidas y disparadores correspondientes. En este sentido, EFD comparte muchas similitudes con los diagramas IDEF0, que también representan jerárquicamente los procesos de negocio como una combinación de funciones y disparadores. La diferencia radica en que EFD sitúa las funciones de negocio en la perspectiva jerárquica de la organización, que describe el flujo descendente de ciertos procesos dentro de la misma. Por el contrario, los diagramas IDEF0 muestran las responsabilidades de ciertas funciones de negocio mediante flechas. Además, IDEF0 ofrece una representación clara de las entradas y salidas de cada (sub)función.

EFD podría utilizarse como interfaz de negocio para un lenguaje de modelado de software como UML. Su gran parecido con IDEF como herramienta de modelado indica que es posible. Sin embargo, se necesita más investigación para perfeccionar la técnica EFD y permitir la creación de mapeos formales a UML. [ 1 ] El estudio sobre el uso complementario de IDEF y UML ha contribuido a la aceptación de IDEF como interfaz de negocio. Se debería realizar un estudio similar con EFD y UML.

Referencias

  1. 1 2 Kim & Weston & Hodgson & Lee (2002); El uso complementario de IDEF y UML. Ingeniería de sistemas de información, Universidad Deajon, Corea del Sur, Computers & Industrial Engineering 50, 35–56.
  2. Zakarian y Kusiak; Análisis y reingeniería de procesos: Departamento de Ingeniería Industrial, Universidad de Iowa, EE. UU., Computers & Industrial Engineering 41, 135–150
  3. Beekman, (1989); Comité Europeo de Normalización, ECN TC310 WG1, 1994
  4. Fuerza Aérea de EE. UU. (1981); Arquitectura ICAM, parte 1, Ohio, Laboratorio de Materiales de la Fuerza Aérea, Wright-Patterson
  5. Peterson JL (1981); Teoría de redes de Petri y modelado de sistemas, Englewood Cliffs, NJ, Prentice Hall.
    1. Marshall, C. (2000); Modelado empresarial con UML, ISBN 0-201-43313-3Addison-Wesley, MA.
  6. François Vernadat ; Una visión para el trabajo futuro del grupo de trabajo (IFAC-IFIP).
  7. Silva, M. y Valette, R. (1989); Redes de Petri y fabricación flexible. Lecture Notes on Computer Science, 424, 374–417.
  8. Zhu et al. (2004); Integración y gestión de procesos de negocio basados ​​en modelos: un estudio de caso con la plataforma de servicios regionales del Banco SinoPac, IBM Corporation, Res. & Dev. Vol. 48 No. 5/6.
  9. Eriksson y Penker (1998); UML Toolkit, Wiley, Nueva York.