En el diagrama idef0, se utiliza un túnel. IDEF0: modelado funcional de procesos de negocio. Historia del estándar IDEF0

Metodología IDEF0

Metodología IDEF0 prescribe la construcción de un sistema jerárquico de diagramas: descripciones únicas de fragmentos del sistema. Primero, se realiza una descripción del sistema en su conjunto y su interacción con el mundo exterior (diagrama de contexto), después de lo cual se lleva a cabo una descomposición funcional: el sistema se divide en subsistemas y cada subsistema se describe por separado (diagramas de descomposición). . Luego cada subsistema se divide en otros más pequeños, y así sucesivamente hasta alcanzar el nivel de detalle deseado.

Cada diagramas IDEF0A Contiene bloques y arcos. Los bloques representan las funciones del sistema modelado. Los arcos unen bloques y representan las interacciones y relaciones entre ellos.

Los bloques funcionales (trabajo) en los diagramas están representados por rectángulos, que representan procesos, funciones o tareas con nombre que ocurren durante un período de tiempo y tienen resultados reconocibles. El nombre de la obra debe expresarse como un sustantivo verbal que denota la acción.

IDEF0 Requiere que el diagrama tenga al menos tres y no más de seis bloques. Estas restricciones mantienen la complejidad de los diagramas y el modelo en un nivel que sea legible, comprensible y utilizable.

Cada lado del bloque tiene un propósito especial y muy específico. El lado izquierdo del bloque es para entradas, la parte superior es para control, el derecho es para salidas y la parte inferior es para mecanismos. Esta designación refleja ciertos principios del sistema: las entradas se convierten en salidas, los límites de control o prescriben las condiciones para llevar a cabo transformaciones, los mecanismos muestran qué y cómo se realiza una función.

Los bloques en IDEF0 están colocados en orden de importancia, según lo entiende el autor del diagrama. Este orden relativo se llama dominancia. Se entiende por dominancia la influencia que tiene un bloque sobre otros bloques del diagrama. Por ejemplo, el bloque más dominante del diagrama puede ser el primero de una secuencia requerida de funciones o una función de planificación o control que influye en todas las demás.

El bloque más dominante suele colocarse en la esquina superior izquierda del diagrama y el menos dominante en la esquina derecha.

La disposición de los bloques en la página refleja la definición de dominancia del autor. Por tanto, la topología del diagrama muestra qué características tienen un mayor impacto en otras. Para enfatizar esto, el analista puede renumerar los bloques según su orden de dominancia. El orden de dominancia se puede indicar mediante un número colocado en la esquina inferior derecha de cada rectángulo: 1 indicaría la mayor dominancia, 2 la siguiente, etc.

La interacción de las obras con el mundo exterior y entre sí se describe en forma de flechas, representadas como líneas simples con flechas en los extremos. Las flechas representan cierta información y se llaman sustantivos.

IDEF0 distingue entre cinco tipos de flechas.

Entrada- objetos utilizados y transformados por el trabajo para obtener un resultado (salida). Se permite que la obra no tenga una sola flecha de entrada. La flecha de entrada se dibuja entrando por el borde izquierdo de la obra.

Control-.información que controla las acciones del trabajo. Normalmente, las flechas de control llevan información que indica lo que debe hacer un trabajo. Cada trabajo debe tener al menos una flecha de control, que se representa entrando en el borde superior del trabajo.

Salida- objetos en los que se convierten las entradas. Cada trabajo debe tener al menos una flecha de salida, que se dibuja como si surgiera del borde derecho del trabajo.

Mecanismo- recursos que realizan el trabajo. La flecha del mecanismo se dibuja entrando por el borde inferior de la obra. A discreción del analista, las flechas del mecanismo pueden no estar representadas en el modelo.

Llamar- una flecha especial que apunta a un modelo operativo diferente. La flecha de llamada se dibuja como si viniera de la parte inferior del trabajo y se utiliza para indicar que se está realizando algún trabajo fuera del sistema que se está modelando.

Arroz. 2.1 tipos de flechas

La metodología IDEF0 requiere solo cinco tipos de interacciones entre bloques para describir sus relaciones: control, entrada, retroalimentación de control, retroalimentación de entrada, mecanismo de salida. Las conexiones de control y entrada son las más simples porque reflejan influencias directas que son intuitivas y muy simples.

Arroz. 2.2. Comunicación de salida

Arroz. 2.3. Comunicaciones de gestión

Una relación de control ocurre cuando la salida de un bloque afecta directamente al bloque menos dominante.

La retroalimentación de control y la retroalimentación de entrada son más complejas porque implican iteración o recursividad. Es decir, los resultados de un trabajo influyen en la ejecución futura de otros trabajos, lo que posteriormente afecta al trabajo original.

Entonces se produce la retroalimentación de control; cuando la salida de algún bloque afecta a un bloque con mayor dominancia.

Las relaciones entre el mecanismo de producción y el mecanismo de producción son raras. Reflejan una situación en la que el resultado de una función se convierte en un medio para alcanzar el fin de otra.

Arroz. 2.4. Comentarios de inicio de sesión

Arroz. 2.5. Comentarios de la gerencia

Las relaciones producto-mecanismo son características de la asignación de fuentes de recursos (por ejemplo, herramientas necesarias, personal capacitado, espacio físico, equipo, financiamiento, materiales).

En IDEF0, un arco rara vez representa un solo objeto. Suele simbolizar un conjunto de objetos. Debido a que los arcos representan colecciones de objetos, pueden tener múltiples puntos de inicio (orígenes) y puntos finales (destinos). Por tanto, los arcos pueden ramificarse y conectarse de diversas formas. Todo el arco o parte del mismo puede extenderse desde uno o más bloques y terminar en uno o más bloques.

Los arcos ramificados, representados como líneas radiantes, significan que todo o parte del contenido de los arcos puede aparecer en cada rama. Un arco siempre está etiquetado antes de una rama para darle un nombre a todo el conjunto. Además, cada rama de un arco puede o no etiquetarse según las siguientes reglas:

las ramas sin etiqueta contienen el peso de los objetos especificados en la etiqueta del arco antes de la rama;

Las ramas etiquetadas después del punto de bifurcación contienen todos o parte de los objetos especificados en la etiqueta del arco antes de la bifurcación.

Las fusiones de arco en IDEFO, representadas como líneas que convergen entre sí, indican que el contenido de cada rama forma una etiqueta para el arco que resulta de fusionar los arcos originales. Después de una fusión, el arco resultante siempre está marcado para indicar el nuevo conjunto de objetos resultantes de la fusión. Además, cada sucursal podrá o no ser marcada antes de fusionarse, de acuerdo con las siguientes reglas:

Arroz. 2.6. Conexión del mecanismo de salida

las ramas sin etiqueta contienen el peso de los objetos especificados en la etiqueta común del arco después de la fusión;

las ramas marcadas antes de fusionarse contienen todos o algunos de los objetos enumerados en la etiqueta común después de fusionarse,

número de bloques en el diagrama - NORTE;

nivel de descomposición del diagrama - l;

equilibrio del diagrama - EN;

número de flechas que se conectan al bloque - A

Este conjunto de factores se aplica a cada diagrama de modelo. A continuación se enumerarán recomendaciones sobre los valores deseados de los factores en el diagrama.

Es necesario esforzarse para que el número de bloques en los diagramas de niveles inferiores sea menor que el número de bloques en los diagramas principales, es decir, a medida que aumenta el nivel de descomposición, el coeficiente disminuye. Así, la disminución de este coeficiente indica que. que a medida que se descompone el modelo, las funciones deben simplificarse, por lo tanto, el número de bloques debe disminuir.

Los diagramas deben estar equilibrados. Esto significa que dentro de un diagrama la situación que se muestra en la Fig. 1 no debería ocurrir. 2.7: la obra 1 tiene significativamente más flechas entrantes y de control que salientes. Cabe señalar que esta recomendación no podrá seguirse en modelos que describan procesos de producción. Por ejemplo, al describir un procedimiento de ensamblaje, un bloque puede incluir muchas flechas que describen los componentes de un producto y una flecha que sale: el producto terminado.

Arroz. 2.7. Ejemplo de gráfico desequilibrado

Introduzcamos el coeficiente de equilibrio del diagrama.

Es necesario esforzarse por q fue mínimo para el gráfico.

Además de analizar los elementos gráficos del diagrama, es necesario considerar los nombres de los bloques. Para evaluar nombres, se compila un diccionario de funciones elementales (triviales) del sistema modelado. De hecho, este diccionario debería incluir las funciones del nivel inferior de descomposición del diagrama. Por ejemplo, para un modelo de base de datos, las funciones "buscar un registro" y "agregar un registro a la base de datos" pueden ser elementales, mientras que la función "registro de usuario" requiere una descripción más detallada.

Después de formar un diccionario y compilar un paquete de diagramas del sistema, es necesario considerar el nivel inferior del modelo. Si hay coincidencias entre los nombres de los bloques del diagrama y las palabras del diccionario, significa que se ha alcanzado un nivel de descomposición suficiente. El coeficiente que refleja cuantitativamente este criterio se puede escribir como L*C- producto del nivel del modelo y el número de coincidencias de nombres de bloques con palabras del diccionario. Cuanto más bajo sea el nivel del modelo (L más grande), más valiosas serán las coincidencias.

Cuando inicia BPWin, la barra de herramientas principal, la paleta de herramientas y el Explorador de modelos aparecen de forma predeterminada.

Al crear un nuevo modelo, aparece un cuadro de diálogo en el que se debe indicar si el modelo se creará de nuevo, o se abrirá desde el repositorio de ModelMart, ingresar el nombre del modelo y seleccionar la metodología en la que se construirá el modelo ( Figura 2.8).

Fig.2.8 Diálogo de creación de modelo

BPWin admite tres metodologías: IDEF0, IDEF3 y DFD. En BPWin es posible construir modelos mixtos, es decir, el modelo puede contener simultáneamente diagramas IDEF0 e IDEF3 y DFD. La composición de la paleta de herramientas cambia automáticamente cuando cambia de una notación a otra.

Un modelo en BPWin se considera como un conjunto de obras, cada una de las cuales opera con un determinado conjunto de datos. Si hace clic en cualquier objeto modelo con el botón izquierdo del mouse, aparece un menú contextual emergente, cada elemento del cual corresponde al editor de una propiedad del objeto.

La construcción de un modelo de sistema debe comenzar con el estudio de todos los documentos que describen su funcionalidad. Uno de estos documentos es la especificación técnica, es decir, las secciones "Propósito del desarrollo", "Metas y objetivos del sistema" y "Características funcionales del sistema".

Después de estudiar los documentos originales y entrevistar a los clientes y usuarios del sistema, es necesario formular el propósito del modelado y determinar el punto de vista sobre el modelo. Consideremos la tecnología de su construcción usando el ejemplo del sistema "Servicio Universitario de Empleo", cuyas principales capacidades se describieron en el trabajo de laboratorio No. 1.

Formulemos el objetivo del modelado: describir el funcionamiento del sistema, que sea comprensible para su usuario, sin entrar en detalles relacionados con la implementación. Construiremos el modelo desde el punto de vista de los usuarios (estudiante, docente, administrador, decano, empresa).

Comencemos construyendo un diagrama de contexto IDEF0. Según la descripción del sistema, la función principal es atender a sus clientes procesando las solicitudes recibidas de ellos. Por lo tanto, definimos el único trabajo del diagrama de contexto como "Servir al cliente del sistema". A continuación, definimos los datos de entrada y salida, así como los mecanismos y el control.

Para atender a un cliente es necesario registrarlo en el sistema, abrir el acceso a la base de datos y procesar su solicitud. Los datos de entrada serán "nombre de cliente", "contraseña de cliente", "base de datos de origen", "solicitud de cliente". La ejecución de una solicitud conduce a recibir información del sistema o a cambiar el contenido de la base de datos (por ejemplo, al compilar evaluaciones de expertos), por lo que los datos de salida serán "informes" y "base de datos modificada". El proceso de procesamiento de la solicitud será realizado por el monitor del sistema bajo el control del administrador.

Así, definimos el diagrama de contexto del sistema (Fig. 2.9).

Figura 2.9. Diagrama de contexto del sistema

Descompongamos el diagrama de contexto, describiendo la secuencia de atención al cliente:

Determinar el nivel de acceso al sistema.

Selección de subsistemas.

Acceso al subsistema.

Cambiar la base de datos (si es necesario).

Obtenemos el diagrama que se muestra en la Fig. 2.10.

Una vez completada la descomposición del diagrama de contexto, proceda a la descomposición del siguiente diagrama de niveles. Normalmente, al considerar el tercer nivel y los inferiores, los modelos vuelven a los diagramas principales y los ajustan.

Arroz. 2.10. Descomposición de la obra “Servicio, cliente del sistema”.

Descomponemos secuencialmente todos los bloques del diagrama resultante. El primer paso para determinar el nivel de acceso al sistema es determinar la categoría de usuario. Se busca el nombre del cliente en la base de datos de usuarios, determinando su categoría. Según una determinada categoría se determinan las facultades otorgadas al usuario del sistema. A continuación se realiza el procedimiento de acceso al sistema, comprobando el nombre de acceso y la contraseña. Al combinar información sobre autoridades y nivel de acceso al sistema, se forma un conjunto de acciones permitidas para el usuario. Por tanto, la determinación del nivel de acceso al sistema será como se muestra en la Fig. 2.11.

Arroz. 2.11. Descomposición del trabajo “Determinación del nivel de acceso al sistema”

Luego de completar el procedimiento de acceso al sistema, el monitor analiza la solicitud del cliente, seleccionando el subsistema que procesará la solicitud. La descomposición del trabajo “Apelación a un subsistema” no se corresponde con el propósito y punto de vista del modelo. El usuario del sistema no está interesado en los algoritmos internos de su funcionamiento. En este caso, para él es importante que la elección del subsistema se haga automáticamente, sin su intervención, por lo que la descomposición del acceso al subsistema sólo complicará el modelo.

Descomponemos el trabajo “Procesamiento de solicitud de cliente”, realizado por el subsistema de procesamiento de solicitudes, determinando las categorías y poderes de los usuarios. Antes de buscar una respuesta a una consulta, debe abrir la base de datos (conectarse a ella). Por lo general, la base de datos puede estar ubicada en un servidor remoto, por lo que puede ser necesario establecer una conexión con el mismo. Determinemos la secuencia de trabajo:

Abriendo la base de datos.

Ejecutando la solicitud.

Generación de informes.

Después de abrir la base de datos, debe informar al sistema que se ha establecido una conexión a la base de datos, luego ejecutar la solicitud y generar informes para el usuario (Fig. 2.12).

Cabe señalar que la "Ejecución de consultas" incluye el trabajo de varios subsistemas. Por ejemplo, si la solicitud incluye pruebas, será ejecutada por el subsistema de pruebas profesionales y psicológicas. En la etapa de ejecución de la consulta, puede ser necesario cambiar el contenido de la base de datos, por ejemplo, al compilar evaluaciones de expertos. Por tanto, es necesario prever esta posibilidad en el diagrama.

Arroz. 2.12.

Al analizar el diagrama resultante surge la pregunta: ¿qué reglas se utilizan para generar informes? Es necesario tener plantillas pregeneradas que se utilizarán para seleccionar de la base de datos, y estas plantillas deben corresponder a consultas y deben estar predefinidas. Además, se debe dar al cliente la oportunidad de elegir la forma del informe.

Ajustemos el diagrama agregando las flechas "Plantillas de informes" y "Solicitudes de cambio de base de datos" y la flecha del túnel "Cliente del sistema". La tunelización del “Cliente del sistema” se utiliza para no colocar la flecha en el diagrama superior, ya que la función de seleccionar el formulario de informe no es lo suficientemente importante como para mostrarse en el diagrama principal.

Cambiar el diagrama dará como resultado ajustes en todos los diagramas principales (Fig. 2.13 - 2.15).

Es recomendable descomponer el trabajo de “Ejecución de consultas” mediante un diagrama DFD (trabajo de laboratorio No. 3), ya que la metodología IDEF0 considera el sistema como un conjunto de trabajos interrelacionados, lo que no refleja bien los procesos de procesamiento de información.

Arroz. 2.13. Descomposición de la obra “Tramitación de la solicitud de un cliente”

Arroz. 2.14. Descomposición del trabajo “Servicio al cliente del sistema” (opción 2)

Arroz. 2.15. Diagrama de contexto del sistema (opción 2)

Pasemos a la descomposición del último bloque “Cambiar la Base de Datos”. Desde el punto de vista del cliente, los datos del sistema se encuentran en una base de datos. En realidad, existen seis bases de datos en el sistema:

base de datos de usuarios,

base de datos de estudiantes, (opcion 2)

base de datos de vacantes,

base de datos de rendimiento académico,

base de datos de prueba,

Base de datos de peritajes,

Currículum de base de datos.

Según el propósito del modelado, es importante que el cliente comprenda que los datos recibidos no se actualizan inmediatamente en el sistema, sino que pasan por una etapa adicional de procesamiento y control. El algoritmo de cambio se puede formular de la siguiente manera:

Se determina la base de datos en la que se cambiará la información.

El operador genera un conjunto de datos temporal y se lo proporciona al administrador.

El administrador controla los datos y los ingresa en la base de datos.

Este modelo se puede implementar de otra manera, brindando la capacidad de actualizar la base de datos directamente cuando se solicite, sin pasar por el proceso de control de datos. En este caso, es necesario asegurar el control de la integridad de la base de datos para evitar su daño. En este caso, el diagrama se verá así (Fig. 2.17).

Arroz. 2.16. Descomposición de la obra “Cambio de base de datos”

Arroz. 2.17. Descomposición del trabajo “Cambiar la base de datos” (opción 2) Para la primera opción, que se muestra en la Fig. 2.12

Llevar a cabo una mayor descomposición de los "Cambios de la base de datos" complicará el modelo, explicando cómo se lleva a cabo el cambio físico de la base de datos en el sistema. En este caso, el usuario no recibirá ninguna información adicional sobre el funcionamiento del sistema del servicio de empleo. Es recomendable descomponer este trabajo durante el proceso de diseño de un sistema de base de datos en la etapa de creación de un modelo lógico de la base de datos.

En la siguiente práctica de laboratorio se llevará a cabo una descomposición del trabajo de Ejecución de consultas, que ilustra el uso de diagramas DFD para describir los procesos de procesamiento de información.

Llevemos a cabo un análisis cuantitativo de los modelos mostrados en la Fig. 2.12 y 2.13, según el método descrito anteriormente. Consideremos el comportamiento del coeficiente ^ para estos modelos. El diagrama principal "Procesamiento de una solicitud de cliente" tiene un coeficiente de 4/2 = 2, y el diagrama de descomposición tiene 3/3 = 1. El valor del coeficiente disminuye, lo que indica una simplificación de la descripción de funciones a medida que el nivel de el modelo disminuye.

Consideremos el cambio en el coeficiente. A b Tiene dos opciones de modelo.

para la segunda opción

Coeficiente A b no cambia su valor, por lo tanto, el equilibrio del diagrama no cambia.

Supondremos que el nivel de descomposición de los diagramas considerados es suficiente para reflejar el propósito del modelado, y en los diagramas de nivel inferior se utilizan funciones elementales como nombres de trabajo (desde el punto de vista del usuario del sistema). .

Resumiendo el ejemplo considerado, es necesario señalar la importancia de considerar varias opciones de diagramas al modelar un sistema. Estas opciones pueden surgir al ajustar diagramas, como se hizo con "Procesamiento de una solicitud de cliente" o al crear implementaciones alternativas de funciones del sistema (descomposición del trabajo "Cambiar la base de datos"). Revisar las opciones le permite seleccionar la mejor e incluirla en un paquete de diagramas para su posterior consideración.

En esta sección se implementa la metodología para definir, clasificar e identificar procesos (sección ____) sobre la base de la metodología de modelado funcional IDEF0.

1. Definición de procesos de negocio en forma de modelo IDEF0.

1.1. Definición de un proceso de negocio.

En la primera etapa de la descripción, es necesario definir los procesos de negocio de la organización. El elemento clave en la definición de un proceso de negocio es la declaración de propósito, que refleja el motivo para crear el modelo (descripción) del proceso de negocio y determina su propósito.

Notas:

1 El propósito del modelo es fijar un cierto ángulo desde el cual se ven y describen las actividades de la organización. Para diferentes propósitos, los ángulos de visión pueden ser diferentes y los modelos de proceso serán diferentes.

Por ejemplo, al describir los procesos en una fábrica de ropa, se pueden formular varios objetivos: optimización de la estructura organizativa de la fábrica, formación de un sistema de gestión de la calidad, ampliación de actividades, etc.

2 El propósito general de los modelos en el marco de este documento es crear un sistema de gestión de calidad que cumpla con los requisitos de STB ISO 9000-2001, STB ISO 9001-2001 y STB ISO 9004-2001.

Para identificar los procesos de negocio, es necesario determinar lo siguiente:

consumidores de los productos y/o servicios de la organización;
productos y/o servicios producidos por la organización y suministrados a los consumidores;
tipos de materias primas y sus proveedores.

NOTA Se pueden considerar diferentes procesos comerciales para diferentes tipos de productos o diferentes categorías de clientes.

Por ejemplo, una fábrica de ropa produce (cose) abrigos de mujer mediante la celebración de contratos con los consumidores. Los consumidores de los productos son tiendas de ropa femenina y empresas comerciales e intermediarias. La fábrica compra materias primas a empresas textiles, así como a empresas comerciales e intermediarias.

La fábrica es una sociedad anónima cerrada. El propósito de construir el modelo es crear un sistema de gestión de calidad. Con base en esta información, se puede distinguir un proceso comercial en las actividades de una fábrica de ropa: "Producir abrigos de mujer". Los insumos de este proceso son: a) información externa, incluyendo los requerimientos de los consumidores (tiendas y empresas); b) materias primas y materiales; c) recursos. Los resultados del proceso son: a) lotes de productos terminados destinados a los consumidores; b) información para los consumidores externos. El control de procesos se lleva a cabo sobre la base de los documentos reglamentarios que regulan los procesos de producción en la fábrica. Teniendo en cuenta que estamos interesados en el proceso desde el punto de vista de la gestión de la calidad, consideraremos como control externo los documentos reglamentarios que regulan esta área, incluidos los requisitos de STB ISO 9000. Se muestra un mapa del proceso de negocio en una fábrica de prendas de vestir. en la Fig. 3.

Arroz. 3 Proceso de negocio en una fábrica de ropa

1.2. Descripción de la estructura del proceso de negocio.

En la segunda etapa de definición de un proceso de negocio, es necesario describir su estructura interna. Para ello es necesario definir:

en qué procesos consta el proceso de negocio modelado;
cómo estos procesos interactúan entre sí.

El modelado IDEF0 utiliza un mecanismo de descomposición para describir la estructura interna de un proceso.

De acuerdo con los requisitos de la metodología IDEF0, para descomponer un proceso de negocio es necesario crear un diagrama hijo. Este diagrama debe representar los procesos que conforman un proceso de negocio dentro de un sistema de gestión de calidad (SGC).

Consideremos la descomposición del proceso empresarial “Producir abrigos de mujer” (Fig. 3).

Teniendo en cuenta los objetivos del modelado: cumplimiento del proceso de negocio con los requisitos de STB ISO 9001 - 2001, la descomposición del proceso de negocio incluye 4 bloques de procesos presentados en la Fig. 4.

De acuerdo con los requisitos de STB ISO 9000, el proceso de negocio “Producción de abrigos de mujer” incluye los siguientes procesos:

– asumir la responsabilidad de la alta dirección por la gestión de la calidad;

– llevar a cabo la gestión de recursos;

– implementar procesos del ciclo de vida;

– realizar mediciones, análisis y mejora del SGC.

Nota – La Figura 4 no muestra las interacciones entre los bloques funcionales que representan la descomposición del proceso “Producir abrigos de mujer”. 1.3. Descripción de las interacciones entre los procesos.

El tercer paso para definir un proceso de negocio es describir las interacciones entre procesos. La interacción entre procesos en IDEF0 se describe mediante arcos de interfaz y denota la transferencia de materiales y/o información desde las salidas de un proceso a las entradas (controles, mecanismos) de otro proceso.

En la metodología IDEF0 se permiten 5 (cinco) tipos de interacciones entre bloques dentro de un diagrama (Tabla 1):

control;
salida entrada;
retroalimentación de la gestión;
retroalimentación de entrada;
salida - mecanismo.

tabla 1

	Relación de control: la salida de un proceso afecta la ejecución de otro proceso, es decir el arco de salida del bloque 1 es el arco de control para el bloque 2. En STB ISO 9001, dicha interacción define la función de control "responsabilidad de gestión" en relación con otros procesos.
	Relación de entrada: la salida de un proceso es la entrada de otro, es decir el arco de salida del bloque 1 es el arco de entrada para el bloque 2. Esta interacción es típica de cualquier proceso en la organización, por ejemplo, para los procesos del ciclo de vida.
	Retroalimentación de control: las salidas de un proceso afectan la ejecución de otros procesos, cuya ejecución a su vez afecta la ejecución del proceso original. El arco de salida del bloque 1 es el arco de control para el bloque 2 y el arco de salida del bloque 2 es el arco de control para el bloque 1. En STB ISO 9001, dicha interacción puede determinar: – función de gestión “responsabilidad de gestión”; – función de gestión “gestión del proceso del ciclo de vida”; – función de gestión “medición, análisis y mejora”
	Retroalimentación de entrada: la salida de un proceso es la entrada de otro proceso, cuya salida es su entrada, es decir el arco de salida del bloque 2 es el arco de entrada del bloque 1, cuya salida es su entrada. En STB ISO 9001-2001, dicha interacción puede definir la función de gestión "gestión del proceso del ciclo de vida"
	La relación “resultado-mecanismo”: el resultado de un proceso es un mecanismo para otro, es decir el arco de salida del bloque 1 es el arco del mecanismo para el bloque 2. Este tipo de conexión se refiere con mayor frecuencia a los procesos de provisión de recursos. En STB ISO 9001, dicha interacción puede determinar la función de gestión "gestión de recursos"

La práctica muestra que los cinco tipos de interacciones enumerados son suficientes para determinar las interacciones entre procesos de cualquier complejidad.

La descripción de las interacciones dentro del modelo de proceso funcional estará completa cuando se definan sus arcos de interfaz para cada bloque funcional.

Nota – La metodología IDEF0 estipula que cada bloque del modelo debe contener al menos un arco de entrada, salida, control y mecanismo. Hay una breve lista de excepciones a esta regla.

Consideremos las interacciones entre los procesos que componen el proceso de negocio “Producir abrigos de mujer” (Fig. 5).

El proceso “Implementar la responsabilidad de la alta dirección por la gestión de la calidad” es el proceso impulsor de todos los demás procesos. En consecuencia, el resultado de este proceso - "Política, objetivos, gestión de calidad, programas de calidad" es la entrada de control para todos los demás procesos presentados en el diagrama (Fig. 5).

El proceso “Realizar la gestión de recursos” tiene una conexión de “mecanismo de salida” con los procesos “Implementar procesos del ciclo de vida” y “Realizar mediciones, análisis y mejora del SGC”.

El diagrama muestra el circuito de retroalimentación: el resultado del proceso "Medir, analizar y mejorar el SGC" con el insumo del proceso "Implementar la responsabilidad de la alta dirección para la gestión de la calidad"

Nota – La regla de integridad del modelo funcional IDEF0 corresponde exactamente a los requisitos de STB ISO 9001 en términos del hecho de que cada proceso debe contar con recursos (arcos de mecanismos en el modelo IDEF0), controlados (arcos de control), producir productos de salida (arcos de salida), procesar materiales y/o información que llega a sus entradas (arcos de entrada).

Fig.5 - Interacciones entre procesos

El número de niveles de detalle del proceso está determinado por los objetivos del modelado y las características específicas de la actividad de la organización modelada. En el marco de esta metodología, el objetivo principal del modelado de procesos es analizar el cumplimiento del proceso con los requisitos del sistema de gestión de la calidad.

En el diagrama A0 (Fig. 5), el proceso de negocio “Producir abrigos de mujer” se presenta en forma de 4 procesos. El diagrama A0 es el primer nivel de descomposición (detalle) de este proceso. Cada uno de los 4 procesos presentados puede a su vez descomponerse. En la Fig. La Figura 6 muestra la descomposición del proceso “Implementar procesos del ciclo de vida”.

En el diagrama A3 (Fig. 6), el proceso “Implementar procesos del ciclo de vida” se presenta en forma de seis procesos, incluido “Realizar adquisiciones”, que también se puede descomponer (Fig. 7).

Arroz. 6.- Descomposición del proceso “Implementar procesos de ciclo de vida”

El glosario de procesos incluye una lista de procesos, objetos procesados dentro de procesos y sus definiciones.

El glosario proporciona una lista de términos organizada alfabéticamente. Cada término de esta lista corresponde a una definición o un enlace a la definición correspondiente dada en los documentos reglamentarios de la organización o autoridades superiores, reglamentos, etc.

Por ejemplo, para el diagrama A34 (Fig. 7), un fragmento del glosario se verá así.

A continuación, consideraremos los métodos estándar de análisis estructural de sistemas descritos por una serie de estándares federales de EE. UU. " Definición de cámara", de acuerdo con . Puede encontrar información detallada sobre todos los estándares de esta serie en http://www.idef.com.

Estándar IDEF0(FIPS183) tiene como objetivo crear un modelo funcional que represente la estructura y las funciones de un sistema, así como los flujos de información y objetos materiales que conectan estas funciones. Este documento es un diseño (por iniciativa del Departamento de Defensa de EE. UU.) en forma de estándar tecnológico para analizar sistemas complejos. TDAA(Técnica de Diseño y Análisis Estructurado), desarrollado por un grupo de analistas estadounidenses liderados por Douglas Ross en 1973.

El método propuesto por el estándar IDEF0 está destinado al modelado funcional, es decir, modelar el desempeño de las funciones de un objeto, mediante la creación de un modelo gráfico descriptivo que muestra qué, cómo y quién se hace dentro del funcionamiento de la empresa. Un modelo funcional es una representación estructurada de las funciones de un sistema o entorno de producción, la información y los objetos que conectan estas funciones. El modelo se construye mediante el método de descomposición: desde grandes estructuras compuestas hasta otras más pequeñas y simples. Los elementos de cada nivel de descomposición representan acciones para procesar información o recursos materiales bajo ciertas condiciones utilizando mecanismos específicos. Cada acción se descompone en operaciones más pequeñas para procesar una determinada parte de información o recursos materiales en determinadas condiciones utilizando parte de los mecanismos especificados. Las operaciones se presentan de manera similar. El último paso de descomposición debería dar como resultado un modelo cuyo nivel de detalle satisfaga los requisitos especificados al comienzo del proceso de creación del modelo.

La metodología IDEF0 se basa en los siguientes principios:

1. Sistema y modelo. Un modelo es un objeto artificial que es una representación (imagen) de un sistema y sus componentes. METRO modelos A, Si METRO responde preguntas sobre A. Aquí METRO- modelo, A– objeto modelado (original). El modelo se desarrolla para comprender, analizar y tomar decisiones sobre la reconstrucción (reingeniería) o reemplazo de un sistema existente, o el diseño de un nuevo sistema. Un sistema es una colección de partes interconectadas e interactivas que realizan algún trabajo útil. Las partes (elementos) de un sistema pueden ser cualquier combinación de varias entidades, incluidas personas, información, software, equipos, productos, materias primas o energía. El modelo describe lo que sucede en el sistema, cómo se controla, qué entidades transforma, qué herramientas utiliza para realizar sus funciones y qué produce.

2. Modelado de bloques y su representación gráfica.. El principio conceptual principal de la metodología IDEF es la representación de cualquier sistema en estudio como un conjunto de bloques interactuantes e interconectados que muestran los procesos, operaciones y acciones que ocurren en el sistema en estudio. En IDEF0 todo lo que sucede en el sistema y sus elementos se llama funciones. A cada función se le asigna un bloque. En un diagrama IDEF0 (más comúnmente llamado diagrama SADT), el documento principal en el análisis y diseño de sistemas, el bloque es un rectángulo. Las interfaces a través de las cuales un bloque interactúa con otros bloques o con el entorno externo al sistema que se está modelando se representan mediante flechas que entran o salen del bloque. Las flechas entrantes indican qué condiciones deben cumplirse simultáneamente para que ocurra la función descrita por el bloque.

3. Rigor y formalismo. El desarrollo de modelos IDEF0 requiere el cumplimiento de una serie de reglas formales estrictas que garantizan que la metodología se beneficie en términos de falta de ambigüedad, precisión e integridad de modelos complejos de múltiples niveles. Estas reglas se describen a continuación en términos de tecnología SADT. Aquí solo se señala lo principal: todas las etapas y etapas de desarrollo y ajuste del modelo deben estar documentadas estricta y formalmente para que durante su funcionamiento no surjan preguntas relacionadas con documentación incompleta o incorrecta.

4. Modelado iterativo. El desarrollo del modelo en IDEF0 es un procedimiento iterativo paso a paso. En cada paso de la iteración, el desarrollador propone una versión del modelo, que está sujeta a discusión, revisión y posterior edición, tras lo cual el ciclo se repite. Esta organización del trabajo contribuye al uso óptimo del conocimiento de un analista de sistemas que domina la metodología y técnica IDEF0, y el conocimiento de especialistas - expertos en el área temática a la que pertenece el objeto de modelado.

5. Separar "organización" de "funciones". Al desarrollar modelos, se debe evitar "vincular" inicialmente las funciones del sistema en estudio a la estructura organizativa existente del objeto modelado (empresa, firma). Esto ayuda a evitar un punto de vista subjetivo impuesto por la organización y su dirección. La estructura organizacional debe ser el resultado del uso (aplicación) del modelo. Comparar el resultado con la estructura existente permite, en primer lugar, evaluar la adecuación del modelo y, en segundo lugar, proponer soluciones destinadas a mejorar esta estructura.

Ejemplos de problemas resueltos con base en la metodología de modelado IDEF0:

Análisis y reingeniería de procesos de negocio.

Desarrollo de un sistema de información para la gestión de datos de calidad.

Desarrollo de normativas y procedimientos para asegurar la calidad del producto y creación de sistemas de procesamiento de datos de calidad. El modelo funcional permite sustituir los manuales de calidad tradicionales en forma de documentos de texto descriptivos en papel por modelos electrónicos estandarizados, cuya integridad y coherencia se mantienen automáticamente. Si es necesario, siempre puede obtener un informe en papel en la forma habitual.

Diseño de infraestructura de información, procedimientos y regulaciones para la interacción de la información.

Tareas de análisis de riesgos en materia de seguridad de la información.

Consideremos, de acuerdo con el trabajo, los principios de construcción de diagramas utilizando tecnología SADT (IDEF0).

El lenguaje gráfico de SADT es sencillo y armonioso. La metodología se basa en cuatro conceptos principales.

El primero de ellos es el concepto “ bloque de funciones" Un bloque funcional se representa gráficamente como un rectángulo (ver Fig. 3.23) y representa una función específica dentro del sistema considerado. De acuerdo con los requisitos de la norma, el nombre de cada bloque funcional debe formularse en modo verbal (por ejemplo, “ producir servicios", pero no " producción de servicios"). Cada uno de los cuatro lados del bloque funcional tiene su propio significado específico (rol), mientras que: el lado superior tiene el significado “ control" (continúa r ol); el lado izquierdo tiene el significado " entrada» ( aporte); el lado derecho significa " salida» ( producción); la parte inferior significa " mecanismo» ( mecanismo). Cada bloque funcional dentro de un único sistema considerado debe tener su propio número de identificación único.

Objetivo del trabajo:

estudiar los principios básicos de la metodología IDEF0,
creando un nuevo proyecto en BPWin,
formación de un diagrama de contexto,
hacer conexiones.

La descripción de un sistema que utiliza IDEF0 se denomina modelo funcional. El modelo funcional está diseñado para describir los procesos de negocio existentes, que utiliza lenguajes tanto naturales como gráficos. Para transmitir información sobre un sistema específico, la fuente del lenguaje gráfico es la propia metodología IDEF0.

Cada diagramas IDEF0 a contiene bloques y arcos. Los bloques representan las funciones del sistema modelado. Los arcos unen bloques y representan las interacciones y relaciones entre ellos.

El bloque más dominante suele colocarse en la esquina superior izquierda del diagrama y el bloque menos dominante está en la esquina derecha.

tipos de flechas

IDEF0 distingue entre cinco tipos de flechas.

Salida- objetos en los que se convierten las entradas. Cada trabajo debe tener al menos una flecha de salida, que se dibuja como si surgiera del borde derecho del trabajo.

Arroz. 2.1 tipos de flechas

Arroz. 2.2. Comunicación de salida

Arroz. 2.3. Comunicaciones de gestión

Una relación de control ocurre cuando la salida de un bloque afecta directamente al bloque menos dominante.

Entonces se produce la retroalimentación de control; cuando la salida de algún bloque afecta a un bloque con mayor dominancia.

Arroz. 2.4. Comentarios de inicio de sesión

Arroz. 2.5. Comentarios de la gerencia

las ramas sin etiqueta contienen el peso de los objetos especificados en la etiqueta del arco antes de la rama;
Las ramas etiquetadas después del punto de bifurcación contienen todos o parte de los objetos especificados en la etiqueta del arco antes de la bifurcación.

Arroz. 2.6. Conexión del mecanismo de salida

las ramas sin etiqueta contienen el peso de los objetos especificados en la etiqueta del arco compartido después de la fusión;
las ramas marcadas antes de fusionarse contienen todos o algunos de los objetos enumerados en la etiqueta común después de fusionarse,

Análisis de gráficos cuantitativos

Para realizar un análisis cuantitativo de los diagramas, enumeramos los indicadores del modelo:

número de bloques en el diagrama - NORTE;
nivel de descomposición del diagrama - l;
equilibrio del diagrama - EN;
número de flechas que se conectan al bloque - A

Este conjunto de factores se aplica a cada diagrama de modelo. A continuación se enumerarán recomendaciones sobre los valores deseados de los factores en el diagrama.

Arroz. 2.7. Ejemplo de gráfico desequilibrado

Introduzcamos el coeficiente de equilibrio del diagrama.

Es necesario esforzarse por q fue mínimo para el gráfico.

Kit de herramientas de BPWin

Cuando inicia BPWin, la barra de herramientas principal, la paleta de herramientas y el Explorador de modelos aparecen de forma predeterminada.

Fig.2.8 Diálogo de creación de modelo

Ejemplo

Comencemos construyendo un diagrama IDEF0 de contexto. Según la descripción del sistema, la función principal es atender a sus clientes procesando sus solicitudes. Por lo tanto, definimos el único trabajo del diagrama de contexto como "Servir al cliente del sistema". A continuación, definimos los datos de entrada y salida, así como los mecanismos y el control.

Diagrama contextual

Así, definimos el diagrama de contexto del sistema (Fig. 2.9).

Figura 2.9. Diagrama de contexto del sistema

Descompongamos el diagrama de contexto, describiendo la secuencia de atención al cliente:

Determinar el nivel de acceso al sistema.
Selección de subsistemas.
Acceso al subsistema.
Cambiar la base de datos (si es necesario).

Obtenemos el diagrama que se muestra en la Fig. 2.10.

Arroz. 2.10. Descomposición de la obra “Servicio, cliente del sistema”.

Arroz. 2.11. Descomposición del trabajo “Determinación del nivel de acceso al sistema”

Abriendo la base de datos.
Ejecutando la solicitud.
Generación de informes.

Después de abrir la base de datos, debe informar al sistema que se ha establecido una conexión a la base de datos, luego ejecutar la solicitud y generar informes para el usuario (Fig. 2.12).

Arroz. 2.12.

Ajuste de gráfico

Cambiar el diagrama dará como resultado ajustes en todos los diagramas principales (Fig. 2.13 - 2.15).

Arroz. 2.13. Descomposición de la obra “Tramitación de la solicitud de un cliente”

Arroz. 2.14. Descomposición del trabajo “Servicio al cliente del sistema” (opción 2)

Arroz. 2.15. Diagrama de contexto del sistema (opción 2)

base de datos de usuarios,
base de datos de estudiantes, (opcion 2)
base de datos de vacantes,
base de datos de rendimiento académico,
base de datos de prueba,
Base de datos de peritajes,
Currículum de base de datos.

Se determina la base de datos en la que se cambiará la información.
El operador genera un conjunto de datos temporal y se lo proporciona al administrador.
El administrador controla los datos y los ingresa en la base de datos.

Arroz. 2.16. Descomposición de la obra “Cambio de base de datos”

Arroz. 2.17. Descomposición del trabajo “Cambiar la base de datos” (opción 2) Para la primera opción, que se muestra en la Fig. 2.12

Consideremos el cambio en el coeficiente. k b Tiene dos opciones de modelo.

para la segunda opción

Coeficiente k b no cambia su valor, por lo tanto, el equilibrio del diagrama no cambia.

Preguntas de control

Lista Preguntas de seguridad:

¿Qué es un modelo en notación IDEF0?
¿Qué significan los trabajos en IDEF0?
¿Cuál es el orden de denominación de las obras?
¿Cuántas obras deben estar presentes en un diagrama?
¿Cuál es el orden de dominancia?
¿Cómo se organizan las obras según el principio de dominancia?
¿Cuál es el propósito de los lados de los rectángulos de trabajo en los diagramas?
Enumera los tipos de flechas.
Nombra los tipos de relaciones.
¿Cómo se llaman las flechas de límite?
Explique el principio de nombrar flechas que se ramifican y fusionan.
¿Qué metodologías soporta BPWin?
Enumere los elementos principales de la ventana principal de BPWin.
Describe el proceso de creación de un nuevo modelo en BPWin.
¿Cómo hacer conexiones entre obras?
Cómo configurar un nombre de trabajo.
Describe el proceso de descomposición del trabajo.
¿Cómo agregar trabajo a un diagrama?
¿Cómo resolver flechas tunelizadas?
¿Puede un modelo BPWin contener diagramas de múltiples metodologías?

IDEF0 es hoy el principal estándar para el modelado de procesos de negocio. La descripción de un sistema que utiliza IDEF0 se llama modelo funcional . El modelo describe lo que sucede en el sistema, cómo se controla, qué entidades transforma, qué herramientas utiliza para realizar sus funciones y qué produce.

Al construir un modelo, se debe indicar propósito del modelado, respondiendo las siguientes preguntas:

· ¿Por qué debería modelarse este proceso?

¿Qué debería mostrar el modelo?

· ¿Qué puede obtener el lector?

Ejemplos de definición de objetivos: “identificar y definir los problemas actuales, permitir analizar posibles mejoras”, “identificar los roles y responsabilidades de los empleados para redactar descripciones de trabajo”, “determinar la posibilidad de automatización...”, “regular el proceso ...", etc.

Punto de vista También es uno de los elementos clave a la hora de construir un modelo. Un punto de vista se puede representar como la visión de una persona que ve el sistema en el aspecto requerido para modelarlo. El punto de vista debe corresponder al propósito del modelado.

El principio conceptual principal de la metodología IDEF es la representación de cualquier sistema en estudio como un conjunto de bloques interactuantes e interconectados que muestran los procesos, operaciones y acciones que ocurren en el sistema en estudio. En IDEF0, todo lo que sucede en el sistema y sus elementos se suele llamar funciones. Cada función está asignada bloquear.

Los bloques funcionales en los diagramas están representados por rectángulos, que representan procesos, funciones, trabajos u operaciones con nombre que ocurren durante un período de tiempo y tienen resultados reconocibles. Dentro de cada bloque está su nombre y número. El nombre del bloque debe ser un verbo activo, una frase verbal o un sustantivo verbal que denote una acción.

Los bloques en IDEF0 están colocados en orden de importancia, según lo entiende el autor del diagrama. Este orden relativo se llama dominancia. Se entiende por dominancia la influencia que tiene un bloque sobre otros bloques del diagrama. El bloque más dominante suele colocarse en la esquina superior izquierda del diagrama y el menos dominante en la esquina derecha.

Se representan las interfaces a través de las cuales un bloque interactúa con otros bloques o con un entorno externo al sistema que se está modelando. flechas, entrar o salir del bloque. Cada lado de un bloque de funciones tiene un significado estándar en términos de la relación bloque/flecha. La disposición estándar de las flechas se muestra en la Fig. 1.

Arroz. 1. Contexto IDEF0.

Flechas describir la interacción de los bloques con el mundo exterior y entre sí. Las flechas representan cierta información y se llaman sustantivos o frases de un sustantivo.

Hay cinco tipos de flechas en IDEF0:

1. Entrada: material o información que un bloque funcional utiliza o transforma para producir un resultado (salida). Se permite que la obra no tenga una sola flecha de entrada.

2. Gobernanza: las reglas, políticas, procedimientos o estándares que rigen la unidad. El control afecta al bloque, pero no es transformado por él.

3. Salida: material o información que produce el bloque. Un bloque sin resultado no tiene sentido y no debe modelarse.

4. Mecanismo: recursos que realizan el bloqueo, por ejemplo, personal de la empresa, máquinas, dispositivos, etc. A discreción del analista, las flechas del mecanismo pueden no estar representadas en el modelo.

5. Llamar: una flecha especial que apunta a un modelo de trabajo diferente. Se utiliza una flecha de llamada para indicar que se está realizando algún trabajo fuera del sistema que se está modelando.

Las flechas en el diagrama de contexto se utilizan para describir la interacción del sistema con el mundo exterior. Flechas de límite- flechas que comienzan en el borde del diagrama y terminan en la obra o viceversa. Flechas interiores conecta los bloques entre sí. Hay cinco tipos de conexiones laborales.

1. Comunicación por entrada: la flecha de salida del bloque superior se dirige a la entrada del inferior (Fig. 2).

Arroz. 2. Relación salida-entrada.

2. Comunicación de control: la salida del bloque de nivel superior se envía al control del de nivel inferior (Fig. 3).

Arroz. 3. Relación producción-control.

3. Retroalimentación de control: la salida del bloque de nivel inferior se envía al control del de nivel superior (Fig. 4).

Arroz. 4. Retroalimentación de control

4. Realimentación de entrada: la salida del bloque de nivel inferior se envía a la entrada del de nivel superior (Fig. 5).

Arroz. 5. Relación de retroalimentación de entrada

5. Conexión del mecanismo de salida: la salida de un bloque se dirige al mecanismo de otro (Fig. 6).

Arroz. 6 Conexión del mecanismo de salida.

En la notación IDEF0, la descripción del sistema (modelo) está organizada en forma de diagramas interconectados y ordenados jerárquicamente. Primero, se realiza una descripción del sistema en su conjunto y su interacción con el mundo exterior (diagrama de contexto). El diagrama de contexto incluye solo un bloque que caracteriza todo el conjunto de procesos modelados, sin detalles.

Arroz. 7 Ejemplo de un diagrama de contexto IDEF0.

Después de lo cual se lleva a cabo una descomposición funcional (Fig. 8): este bloque de actividad (gran proceso) se divide en grandes subprocesos, y cada subproceso se describe por separado (diagramas de descomposición). Luego, cada subproceso se descompone en otros más pequeños, y así sucesivamente hasta lograr el detalle requerido de la descripción.

Fig.8 Ejemplo de diagrama de descomposición IDEF0.