Cómo crear un diagrama idef0. Trabajo del curso: Desarrollo de un modelo de empresa de invernadero utilizando metodologías de diseño IDEF0, DFD e IDEF3. Diagrama de descomposición A3

A menudo, a los desarrolladores se les pide no solo que identifiquen y resuelvan un problema en el trabajo de la empresa, sino también que determinen qué papel juega en la estructura de la empresa. Porque es mucho más importante comprender cómo una unidad que funciona mal interactúa con otras que simplemente comprender por qué no funciona correctamente. Por tanto, la identificación de cualquier problema comienza con el estudio del trabajo de la empresa y la elaboración de su modelo funcional.

Dirás que el gerente debe tener un modelo funcional de empresa, independientemente del tipo de empresa de la que estemos hablando. Pero, como muestra la práctica, en la mayoría de los casos este modelo está ausente.

Ventaja gráfica

¿Qué son los modelos IDEF0? Esquemas gráficos con características propias y las reglas para su construcción. ¿Por qué gráficos? Porque es eficaz. Esto se puede ver en varios ejemplos.

Imaginemos que el plan militar de operaciones militares se explica con palabras y no con la ayuda de mapas con símbolos gráficos aplicados. Ahora parece imposible, pero hasta la segunda mitad del siglo XIX era exactamente así. Los gráficos ayudan a comprender qué explicar y, en consecuencia, a comprender qué es lo suficientemente difícil.

Lo mismo ocurre con los procesos comerciales: muchos asignaciones técnicas se puede ejecutar en forma de notaciones gráficas, lo que simplificará enormemente la tarea para los desarrolladores y ahorrará dinero a los clientes.

Beneficios de IDEF0 paraESO-especialistas

Las actividades de los desarrolladores, ya sea, por ejemplo, instalar un CRM o crear un ERP eficaz, están asociadas con la realización de cambios en un sistema ya establecido. Y para hacerlo bien, primero debe estudiar cómo funciona este sistema. Tras estudiarlo, el desarrollador redacta una propuesta comercial en la que expone su visión de la situación, las acciones necesarias para solucionar el problema, así como el resultado esperado. Un documento de este tipo puede ocupar más de una docena de páginas. Por un lado, esto es bueno, porque el cliente obtiene la máxima cantidad de información que le interesa. Por otro lado, se necesita tiempo para estudiar un texto extenso. Hombre de negocios exitoso a menudo no.

Entonces, ¿cómo es posible transmitir la esencia sin recurrir a textos voluminosos? ¡Gráficos! Es ella quien te permite acortar lo que está escrito, demostrando claramente la información necesaria. Después de todo, una imagen puede reemplazar cientos de palabras. Y en relación con el uso de gráficos para describir los procesos comerciales, esto es 100% cierto.

Primero entendamos qué son la notación y el IDEF0 y para qué sirven.

Notación para describir los procesos de negocio: que es

La notación es un formato en el que los procesos de negocio se representan en forma de objetos gráficos utilizados en el modelado y reglas de modelado directo. La notación es una especie de lenguaje gráfico que le permite representar el funcionamiento de una empresa, demostrando la relación entre departamentos y divisiones. Es decir, la notación puede considerarse una especie de lenguaje de programación en inteligencia empresarial.

IDEF0 es ...

IDEF0 es un método de modelado funcional y notación gráfica que se utiliza para describir y formalizar procesos comerciales. La peculiaridad de IDEF0 es que esta metodología está enfocada a la subordinación de objetos. IDEF0 fue desarrollado para la automatización empresarial en 1981 en los Estados Unidos.

Modelo funcional de la empresa

El modelo funcional IDEF0 son bloques, cada uno con múltiples entradas y salidas. Cada bloque tiene controles y mecanismos que se detallan al nivel requerido. La función más importante se encuentra en la esquina superior izquierda. Se conecta al resto de flechas y descripciones de bloques de funciones. Cada flecha o actividad tiene su propio significado. Debido a esto, dicho modelo se utiliza para describir cualquier proceso administrativo y organizativo.

Tipos de flechas

Entrante las tareas están establecidas.

Extrovertido mostrar el resultado de la actividad.

Gerentes(flechas de arriba a abajo) son mecanismos de control.

Mecanismos(flechas de abajo hacia arriba) se utilizan para realizar el trabajo necesario.

Cuando se trabaja con un modelo funcional, se adoptan las siguientes reglas. Por ejemplo, las flechas se nombran con sustantivos (reglas, plan, etc.), bloques, con verbos (mantener registros, concluir un acuerdo).

IDEF0 le permite intercambiar información, mientras que debido a su versatilidad y visibilidad, los participantes del intercambio se entenderán fácilmente entre sí. IDEF0 fue desarrollado y mejorado cuidadosamente, puede trabajar con IDEF0 usando varias herramientas, por ejemplo, ERWIN, VISIO, Bussines studio.

IDEF0 también tiene una ventaja innegable. Esta técnica se desarrolló hace relativamente mucho tiempo y durante tres décadas se ha sometido a un esmerilado y ajuste exhaustivos. Por tanto, es posible crear un modelo funcional de empresa de forma rápida y con una mínima probabilidad de error.

Naturalmente, existen otras metodologías, entonces, ¿por qué recomendamos IDEF0? Puede cortar un trozo de tubería de metal con una sierra para metales, pero, como ve, es mucho más fácil hacerlo con una amoladora. Así es con IDEF0: no existe una herramienta más funcional para modelar, con ella puedes obtener fácil y rápidamente el resultado que necesitas.

Cómo se crea un modelo funcional

Analicemos la creación de un modelo funcional usando el ejemplo de escribir un artículo.

Unidad principal se llamará "Redacción de artículos".

Lo que se necesita para escribir un artículo se refleja en flechas entrantes- "Experiencia", "Lecturas complementarias".

Flechas de control para escribir un artículo: "Esquema del artículo", "Requisitos para el registro", "Reglas del idioma ruso".

Los mecanismos son directamente el propio autor, redactor, editor, software. ¿Cómo se organizan estos mecanismos? El autor crea el texto grabando su versión de audio. El redactor transfiere el texto al formato de texto, centrándose en el plan de publicación, observando los requisitos del editor y las reglas del idioma ruso. Luego, el editor se conecta al trabajo, quien revisa el artículo, corrige los errores de habla, ortografía y puntuación. El software son los programas y herramientas que los participantes en el proceso utilizaron para crear el artículo.

Todo lo anterior es solo un esquema general de trabajo, por lo que debe detallarse.

Volvamos a nuestro modelo y descompongamos el bloque común en varios elementos relacionados.

Entonces, todo el proceso de redacción de un artículo se puede dividir en 4 etapas:

Prepara una versión de audio.
Prepare el texto impreso.
Edición y preparación de texto para imprimir.
Publicación del artículo.

El diagrama refleja información sobre qué controles y mecanismos están involucrados y en qué etapa. Por ejemplo, para crear un texto de calidad, el autor utiliza su propia experiencia y conocimiento, como guía, utiliza el plan de publicación y los requisitos del editor. El redactor, que crea una versión impresa del texto, y el editor, al corregirlo, utilizan las reglas del idioma ruso. Para publicar un artículo, por ejemplo, en una publicación en línea, se requiere un software especial.

Al preparar un modelo funcional, el ejecutante se guía por el propósito de su creación y su punto de vista.

El modelado funcional se utiliza de forma eficaz para tomar diversas decisiones de gestión. En nuestro ejemplo del proceso de redacción de artículos, hay dos especialistas: un redactor y un editor. Y con la optimización necesaria de la financiación del proyecto de acuerdo con el esquema, no es difícil determinar cómo hacerlo. El redactor y el corrector tienen métodos de trabajo similares, por lo que todo el trabajo se puede ofrecer al redactor, ya que trabaja directamente con el texto de audio, lo que el editor no puede hacer. Al mismo tiempo, se puede ofrecer al redactor para hacer este trabajo por la mitad de la cantidad que estaba destinada al editor. Sí, a partir de esto, se puede perder la calidad del texto, pero la tarea de optimización se completó con éxito. Y sería más difícil hacer esto sin un diagrama visual.

Proceso de creación de notaciónIDEF0

Existen muchos programas para crear notaciones. Algunos están diseñados para crear modelos funcionales, mientras que otros le permiten trabajar con cualquier objeto gráfico. Y para alguien, en la primera etapa, una hoja de papel, un lápiz y una goma de borrar es suficiente.

Antes de proceder a la descripción del trabajo de la empresa, es decir, directamente a la creación de la notación de los procesos de negocio, se deben estudiar los principios del funcionamiento de la empresa. Para ello, un tercero especialista realiza una entrevista. En primer lugar, el jefe de la empresa responde a la pregunta, luego los especialistas que supervisan otras etapas del trabajo.

La primera etapa del trabajo da como resultado dos notaciones. Uno reflejará los procesos comerciales en su forma original. Esta notación se creará en base a los resultados de la entrevista, y cada detalle debe ser acordado con el responsable de la empresa y sus empleados. Es imperativo que su comprensión de los procesos comerciales existentes en la empresa coincida con la realidad, esto requiere confirmación en todos los niveles.

La segunda notación se puede llamar "Como debería ser". Se crea sobre la base del primero con cambios realizados de acuerdo con la tarea.

Estándar IDEF0 y sus requisitos

Hablamos sobre los requisitos básicos de IDEF0 justo arriba.

El elemento principal está en la esquina superior izquierda.
Cada elemento debe tener flechas de entrada y salida. Además, las flechas de entrada están a la izquierda, a la derecha, las de salida.
Los elementos de control están ubicados en la parte superior, los mecanismos en la parte inferior.
Al colocar varios bloques en una hoja o pantalla, los siguientes se colocan en la parte inferior derecha del anterior.
Los esquemas deben crearse de modo que las flechas se crucen el número mínimo de veces.

Naturalmente, el estándar IDEF0 tiene normas, requisitos y designaciones generalmente aceptados. No nos detendremos en ellos en detalle, si lo desea, esta información es fácil de encontrar.

Errores al trabajar con IDEF0

Como ocurre con cualquier actividad, se producen errores al realizar el modelado funcional. Analicemos los más típicos.

Usando varios colores

Es importante recordar que en el modelado funcional todos los elementos son importantes, no hay más importantes ni menos importantes. Al modelar en papel o en uno de los programas de computador los usuarios intentan hacer que el diagrama sea más visual coloreando bloques y flechas en diferentes colores... Sin embargo, en la práctica, esto no solo no hace que el diagrama sea más visual, sino que, por el contrario, genera confusión y distorsiona la percepción de lo representado.

Por lo tanto, la opción ideal es un esquema en blanco y negro sin el uso de opciones de color adicionales. Esto no solo ayuda a eliminar malentendidos, sino que también disciplina directamente al creador del modelo, lo que afecta favorablemente la legibilidad y claridad del modelo.

Gran cantidad de bloques

Al componer un modelo funcional del trabajo de una empresa, sus autores a menudo intentan reflejar todo, incluso los detalles más pequeños. Resulta un diagrama con una gran cantidad de bloques y flechas. Como resultado, se reduce su legibilidad y claridad.

Para evitar este error, utilice los detalles que serán suficientes para comprender el problema. Los detalles detallados se preparan solo si realmente se necesitan para resolver un problema importante.

Cambiar la estructura al corregir errores

Al crear un diagrama, es importante que más de un proceso no se quede sin elementos entrantes, salientes u otros elementos importantes. Por ejemplo, si desea eliminar un autor del esquema, debe eliminar todos los elementos y flechas directamente relacionados con él. Si permanecen en el esquema, habrá malentendidos y confusión, ya que durante los detalles no conducirán a nadie sabe dónde.

La misma situación surge con la adición de un bloque. Si necesita completar cualquier información, verifique si ha proporcionado los atributos requeridos. Esto debe ser monitoreado de cerca, ya que al modelar procesos de negocios complejos, incluso un pequeño cambio en una parte implicará cambios en otra.

Nombres de bloques y controles

Las reglas para nombrar los elementos del modelo son bastante simples, pero es extremadamente importante recordarlas: las flechas de control se llaman sustantivos, los bloques se llaman verbos. Esta regla está escrita en el estándar IDEF0 y ayuda a evitar confusiones y errores.

Beneficios de usar IDEF0

Visibilidad. Al representar el trabajo de la empresa en forma de diagrama, queda claro cómo funciona la empresa, dónde pueden surgir problemas y cómo prevenirlos.

Comprensión mutua, exclusión de la posibilidad de una mala interpretación del esquema. La visibilidad y accesibilidad del modelo funcional, que representa el trabajo de la empresa en forma de bloques y elementos de control, le ayudará a la hora de discutir con la dirección del funcionamiento de su empresa. Por cierto, si es necesario, se crea un glosario para el modelo funcional, que contiene todos los términos y convenciones. Por lo tanto, se minimiza la posibilidad de malentendidos entre usted y el gerente, los empleados de la empresa.

Sencillez y ahorro de tiempo a la hora de crear un modelo. Por supuesto, se necesita mucho tiempo para ser bueno en el modelado funcional. En primer lugar, debe aprender a presentar una gran cantidad de información en forma de esquema lacónico, es decir, poder filtrar y comprimir los datos originales. Pero el tiempo y el esfuerzo dedicados a la formación dan sus frutos más adelante. Después de todo, no tomará mucho tiempo crear un modelo funcional y presentarlo de manera accesible.

Mínima probabilidad de error. Trabajar de acuerdo con el estándar IDEF0 requiere un estricto cumplimiento de sus reglas. Esto disciplina al ejecutante y elimina la posibilidad de errores. Además, cualquier incumplimiento de la norma se hace evidente de inmediato.

Y finalmente

Para dos analistas de negocios, los modelos funcionales solo pueden ser iguales si la estructura de la empresa es extremadamente simple. En otros casos, los modelos serán diferentes entre sí. Esto es natural, porque cada analista tiene su propia experiencia, su propia comprensión del funcionamiento de la empresa, su propio punto de vista sobre cómo resolver las tareas que se le asignan. Un analista de negocios desarrolla un modelo funcional desde el punto de vista de un gerente, imagina cómo resolvería las tareas asignadas.

En nuestra opinión, la herramienta IDEF0 será útil no solo para los analistas de negocios profesionales, sino también para aquellos que analizan directamente su negocio y se esfuerzan por construir un sistema de gestión eficaz.

¡Aprenda a ver y comprender la estructura funcional de su negocio!

En la actualidad, en Rusia, el interés en los estándares de gestión generalmente aceptados en Occidente ha aumentado drásticamente, sin embargo, en la práctica de gestión real, hay un momento muy indicativo. Muchos líderes todavía pueden sentirse desconcertados por la cuestión directa de estructura organizativa empresa o sobre el esquema de los procesos comerciales existentes. Los gerentes más avanzados que leen regularmente publicaciones periódicas económicas, por regla general, comienzan a dibujar diagramas jerárquicos que solo son comprensibles para ellos, pero incluso en este proceso generalmente llegan rápidamente a un callejón sin salida. Lo mismo se aplica a los empleados y gerentes de diversos servicios y unidades funcionales. En la mayoría de los casos, el único conjunto de reglas establecidas de acuerdo con las cuales una empresa debe operar es un conjunto de disposiciones individuales y descripciones de trabajo... La mayoría de las veces, estos documentos se redactaron hace más de un año, están mal estructurados y no están interconectados y, como resultado, simplemente están acumulando polvo en los estantes. Por el momento, tal enfoque estaba justificado, ya que durante la formación de la economía de mercado rusa, el concepto de competencia estaba prácticamente ausente y no había necesidad particular de considerar los costos: el beneficio era gigantesco. Como resultado, en los últimos dos años, hemos visto un panorama bastante comprensible: las grandes empresas que crecieron a principios de los 90 están perdiendo gradualmente sus posiciones, hasta su completa retirada del mercado. Esto se debe en parte al hecho de que la empresa no implementó estándares de gestión, el concepto de un modelo funcional de actividad y misión estaba completamente ausente. Con la ayuda de la modelización de diversas áreas de actividad, es posible analizar eficazmente los cuellos de botella en la gestión y optimizar el esquema empresarial general. Pero, como saben, en cualquier empresa, solo aquellos proyectos que traen ganancias directamente son de máxima prioridad, por lo tanto, generalmente es solo durante una crisis tangible en la gestión de la empresa que estamos hablando de la encuesta de actividades y su reorganización.

A finales de la década de los noventa, cuando el mercado era suficientemente competitivo y la rentabilidad de las empresas comenzaba a caer drásticamente, los gerentes sintieron enormes dificultades para tratar de optimizar los costos para que los productos siguieran siendo rentables y competitivos. Justo en este momento se manifestó claramente la necesidad de tener ante los ojos un modelo de la actividad empresarial que reflejara todos los mecanismos y principios de interconexión de varios subsistemas en el marco de un negocio.

El concepto mismo de "modelar procesos de negocio" entró en la vida diaria de la mayoría de los analistas simultáneamente con la aparición en el mercado de complejos productos de software diseñado para la automatización compleja de la gestión empresarial. Tales sistemas siempre implican una profunda encuesta de anteproyecto actividades de la empresa. El resultado de este examen es una opinión experta, en la que las recomendaciones para la eliminación se hacen por puntos separados ". cuellos de botella”En la gestión de actividades. Sobre la base de esta conclusión, inmediatamente antes de la implementación del sistema de automatización, se lleva a cabo la llamada reorganización de los procesos comerciales, a veces bastante grave y dolorosa para la empresa. Esto, y naturalmente, un equipo que se ha desarrollado a lo largo de los años siempre es difícil de obligar a “pensar de una manera nueva”. Estas encuestas complejas de empresas son siempre tareas complejas y muy diferentes de un caso a otro. Existen metodologías y estándares bien probados para resolver estos problemas de modelado de sistemas complejos. Estos estándares incluyen las metodologías de la familia IDEF. Con su ayuda, es posible mostrar y analizar de manera efectiva los modelos de la actividad de una amplia gama de sistemas complejos en varias secciones. Al mismo tiempo, el desarrollador mismo determina la amplitud y profundidad del examen de los procesos en el sistema, lo que permite no sobrecargar el modelo creado con datos innecesarios. V en la actualidad Los siguientes estándares se pueden atribuir a la familia IDEF:

IDEF0 es una metodología de modelado funcional. Con la ayuda del lenguaje gráfico visual IDEF0, el sistema en estudio aparece a los desarrolladores y analistas en forma de un conjunto de funciones interrelacionadas (bloques funcionales - en términos de IDEF0). Normalmente, el modelado IDEF0 es el primer paso para aprender sobre cualquier sistema;

IDEF1: una metodología para modelar los flujos de información dentro del sistema, que le permite mostrar y analizar su estructura y relaciones;

IDEF1X (IDEF1 Extended) es una metodología para construir estructuras relacionales. IDEF1X se refiere al tipo de metodología "Entidad-relación" (ER - Entidad-Relación) y, por regla general, se utiliza para modelar bases de datos relacionales relacionadas con el sistema considerado;

IDEF2 es una metodología para el modelado dinámico de desarrollo de sistemas. Debido a las gravísimas dificultades de análisis de sistemas dinámicos, esta norma fue prácticamente abandonada y su desarrollo se suspendió en la etapa inicial. Sin embargo, en la actualidad existen algoritmos y sus implementaciones informáticas que permiten transformar un conjunto de diagramas IDEF0 estáticos en modelos dinámicos basados en “redes de Petri coloreadas” (CPN - Color Petri Nets);

IDEF3 es una metodología para documentar los procesos que ocurren en el sistema, que se utiliza, por ejemplo, en el estudio de procesos tecnológicos en empresas. IDEF3 describe el escenario y el flujo de trabajo de cada proceso. IDEF3 tiene una relación directa con la metodología IDEF0 - cada función (bloque funcional) se puede representar como un proceso separado por medio de IDEF3;

IDEF4 es una metodología para construir sistemas orientados a objetos. Las herramientas IDEF4 le permiten mostrar visualmente la estructura de los objetos y los principios subyacentes de su interacción, lo que le permite analizar y optimizar sistemas complejos orientados a objetos;

IDEF5 es una metodología para el estudio ontológico de sistemas complejos. Usando la metodología IDEF5, la ontología de un sistema se puede describir usando un vocabulario específico de términos y reglas, sobre la base de los cuales se pueden formar declaraciones confiables sobre el estado del sistema en consideración en un momento determinado. Sobre la base de estas declaraciones, se extraen conclusiones sobre mayor desarrollo sistema y se lleva a cabo su optimización.
En este artículo, veremos la metodología de modelado funcional IDEF0 más utilizada.

La historia del estándar IDEF0

La metodología IDEF0 puede considerarse la siguiente etapa en el desarrollo del conocido lenguaje gráfico para describir sistemas funcionales SADT (Structured Analysis and Design Teqnique). Hace varios años, se publicó en Rusia una pequeña edición del libro del mismo nombre, que se dedicó a la descripción de los principios básicos de la construcción de diagramas SADT. Históricamente, IDEF0 como estándar se desarrolló en 1981 como parte de un extenso programa de automatización industrial llamado ICAM (Fabricación asistida por computadora integrada) y fue propuesto por la Fuerza Aérea de EE. UU. La propia familia de estándares IDEF heredó su designación del nombre de este programa (IDEF = ICAM DEFinition). En el proceso de implementación práctica, los participantes del programa ICAM enfrentaron la necesidad de desarrollar nuevos métodos para analizar los procesos de interacción en los sistemas industriales. Al mismo tiempo, además de un conjunto mejorado de funciones para describir los procesos de negocio, uno de los requisitos para el nuevo estándar era la disponibilidad de una metodología eficaz para la interacción en el marco de “analista-especialista”. En otras palabras, se suponía que el nuevo método proporcionaría trabajo en grupo en la creación del modelo, con la participación directa de todos los analistas y especialistas involucrados en el proyecto.

Como resultado de la búsqueda de soluciones adecuadas, nació la metodología de modelado funcional IDEF0. Desde 1981, el estándar IDEF0 ha sufrido varios cambios menores, en su mayoría de naturaleza limitante, y su última revisión fue publicada en diciembre de 1993 por el Instituto Nacional de Estándares y Tecnología de EE. UU. (NIST).

Elementos y conceptos básicos de IDEF0

El lenguaje gráfico IDEF0 es sorprendentemente simple y armonioso. La metodología se basa en cuatro conceptos principales.

El primero es el concepto de Activity Box. Un bloque funcional se representa gráficamente en forma de rectángulo (ver Fig. 1) y personifica alguna función específica dentro del marco del sistema en consideración. De acuerdo con los requisitos de la norma, el nombre de cada bloque funcional debe formularse en el modo verbal (por ejemplo, "producir servicios", no "producción de servicios").

Cada uno de los cuatro lados de un bloque funcional tiene su propio significado específico (rol), mientras que:

El lado superior es Control;

El lado izquierdo está configurado en "Entrada";

El lado derecho está configurado en "Salida";

El lado inferior es "Mecanismo".

Cada bloque funcional dentro del marco de un único sistema considerado debe tener su propio número de identificación único.

Figura 1. Bloque funcional.

La segunda “ballena” de la metodología IDEF0 es el concepto de arco de interfaz (Flecha). Además, los arcos de interfaz a menudo se denominan corrientes o flechas. El arco de la interfaz muestra un elemento del sistema que es procesado por un bloque de funciones o que afecta la función que muestra este bloque de funciones.

La visualización gráfica del arco de la interfaz es una flecha unidireccional. Cada arco de interfaz debe tener su propio nombre exclusivo (Etiqueta de flecha). Como lo requiere la norma, el nombre debe ser un cambio de sustantivo.

Con la ayuda de arcos de interfaz, se muestran varios objetos que, en un grado u otro, determinan los procesos que tienen lugar en el sistema. Dichos objetos pueden ser elementos del mundo real (piezas, automóviles, empleados, etc.) o flujos de datos e información (documentos, datos, instrucciones, etc.).

Dependiendo de cuál de los lados sea adecuado para este arco de interfaz, se le llama "entrante", "saliente" o "control". Además, solo los bloques funcionales pueden ser la "fuente" (comienzo) y el "sumidero" (final) de cada arco funcional, mientras que la "fuente" solo puede ser el lado de salida del bloque, y el "sumidero" puede ser cualquier de los tres restantes.

Cabe señalar que cualquier bloque funcional, de acuerdo con los requisitos de la norma, debe tener al menos un arco de interfaz de control y uno saliente. Esto es comprensible: cada proceso debe seguir algunas reglas (mostradas por el arco de control) y debe producir algún resultado (arco saliente); de lo contrario, no tiene sentido considerarlo.

Al construir diagramas IDEF0, es importante separar correctamente los arcos de interfaz entrantes de los de control, lo que a menudo no es fácil. Por ejemplo, la figura 2 muestra el bloque de función "Procesar pieza".

En un proceso real, el trabajador que realiza el procesamiento recibe una pieza e instrucciones tecnológicas para el procesamiento (o reglas de seguridad al trabajar con la máquina). Puede ser un error pensar que tanto la pieza como el documento con instrucciones tecnológicas son objetos entrantes, pero no es así. De hecho, en este proceso, la pieza de trabajo se procesa de acuerdo con las reglas reflejadas en las instrucciones tecnológicas, que deben mostrarse respectivamente en el arco de la interfaz de control.

Figura 2.

Otra cosa es cuando las instrucciones tecnológicas son procesadas por el tecnólogo jefe y se les hacen cambios (Fig. 3). En este caso, se muestran como un arco de interfaz ya entrante y el objeto de control son, por ejemplo, nuevos estándares industriales, en base a los cuales se realizan estos cambios.

Figura 3.

Los ejemplos anteriores enfatizan la naturaleza aparentemente similar de los arcos de interfaz entrantes y salientes, pero siempre hay ciertas distinciones para los sistemas de la misma clase. Por ejemplo, en el caso de considerar empresas y organizaciones, existen cinco tipos principales de objetos: flujos de materiales (partes, bienes, materias primas, etc.), flujos financieros (efectivo y no efectivo, inversiones, etc.), documento flujos (documentos comerciales, financieros y organizativos), flujos de información (información, datos de intención, instrucciones orales, etc.) y recursos (empleados, máquinas, máquinas, etc.). En este caso, en varios casos, todos los tipos de objetos se pueden mostrar mediante arcos de interfaz entrantes y salientes, que controlan solo aquellos relacionados con los flujos de documentos e información, y solo los recursos pueden mostrarse mediante arcos-mecanismos.

La presencia obligatoria de arcos de interfaz de control es una de las principales diferencias del estándar IDEF0 con otras metodologías de las clases DFD (Data Flow Diagram) y WFD (Work Flow Diagram).

El tercer concepto básico del estándar IDEF0 es la descomposición. El principio de descomposición se utiliza cuando se descompone un proceso complejo en sus funciones constituyentes. En este caso, el nivel de detalle del proceso lo determina directamente el desarrollador del modelo.

La descomposición le permite representar de forma gradual y estructurada el modelo del sistema en forma de una estructura jerárquica de diagramas individuales, lo que lo hace menos congestionado y fácil de digerir.

El modelo IDEF0 siempre comienza con la presentación del sistema como un todo: un solo bloque funcional con arcos de interfaz que se extienden más allá del área considerada. Un diagrama de este tipo con un bloque funcional se denomina diagrama de contexto y se indica con el identificador "A-0".

El texto explicativo del diagrama de contexto debe indicar el Propósito de construir el diagrama en forma de una breve descripción y fijar el punto de vista (Punto de vista).

Definir y formalizar el propósito de desarrollar un modelo IDEF0 es un punto extremadamente importante. De hecho, el objetivo identifica las áreas relevantes en el sistema en estudio en las que se debe enfocar primero. Por ejemplo, si modelamos las actividades de una empresa para construir en el futuro sobre la base de este modelo sistema de informacion, entonces este modelo diferirá significativamente del que desarrollaríamos para la misma empresa, pero con el objetivo de optimizar las cadenas de suministro.

El punto de vista define la dirección principal de desarrollo del modelo y el nivel de detalle requerido. Una clara fijación del punto de vista permite descargar el modelo, abandonando el detalle y la búsqueda de elementos individuales que no son necesarios, en función del punto de vista elegido sobre el sistema. Por ejemplo, los modelos funcionales de la misma empresa desde el punto de vista del tecnólogo jefe y el director financiero diferirán significativamente en la dirección de su detalle. Esto se debe al hecho de que, al final, el director financiero no está interesado en los aspectos del procesamiento de las materias primas en las máquinas de producción y el jefe de tecnología no necesita diagramas dibujados. flujos financieros... La elección correcta del punto de vista reduce significativamente el tiempo dedicado a la construcción del modelo final.

En el proceso de descomposición, el bloque funcional, que en el diagrama de contexto muestra el sistema como un todo, se perfora en otro diagrama. El diagrama resultante del segundo nivel contiene bloques funcionales que muestran las subfunciones principales del bloque funcional del diagrama de contexto y se denomina diagrama secundario en relación con él (cada uno de los bloques funcionales que pertenecen al diagrama secundario se denomina respectivamente cuadro secundario ). A su vez, el bloque de función principal se denomina bloque principal en relación con el diagrama secundario (Cuadro principal), y el diagrama al que pertenece se denomina diagrama principal (Diagrama principal). Cada una de las subfunciones del diagrama hijo se puede detallar más mediante una descomposición similar del bloque funcional correspondiente. Es importante tener en cuenta que en cada caso de descomposición de un bloque funcional, todos los arcos de interfaz incluidos en este bloque o que salen de él se fijan en el diagrama hijo. Esto logra la integridad estructural del modelo IDEF0. El principio de descomposición se muestra claramente en la Figura 4. Debe prestar atención a la relación entre la numeración de los bloques funcionales y los diagramas; cada bloque tiene su propio número de serie único en el diagrama (el número en la esquina inferior derecha del rectángulo) , y la designación en el ángulo recto indica el número del diagrama hijo para este bloque ... La ausencia de esta designación significa que no hay descomposición para este bloque.

A menudo hay casos en los que los arcos de interfaz individuales no tienen sentido para continuar considerándose en los diagramas secundarios por debajo de un cierto nivel en la jerarquía, o viceversa: los arcos individuales no tienen un significado práctico por encima de un cierto nivel. Por ejemplo, un arco de interfaz que representa un "detalle" en la entrada del bloque de funciones "Proceso en torno”No tiene sentido reflexionar sobre los diagramas de niveles superiores, solo sobrecargará los diagramas y hará que sean difíciles de entender. Por otro lado, existe la necesidad de deshacerse de los arcos de interfaz "conceptuales" separados y no detallarlos más allá de cierto nivel. Para resolver estos problemas, el estándar IDEF0 prevé el concepto de tunelización. La designación Arrow Tunnel en forma de dos paréntesis alrededor del comienzo del arco de interfaz denota que este arco no fue heredado del bloque padre funcional y apareció (del "túnel") solo en este diagrama. A su vez, la misma designación alrededor del extremo (flecha) del arco de interfaz en las inmediaciones del bloque receptor significa el hecho de que en el diagrama secundario de este bloque este arco no se mostrará y no se considerará. Muy a menudo sucede que los objetos individuales y sus correspondientes arcos de interfaz no se consideran en algunos niveles intermedios de la jerarquía; en este caso, primero se “sumergen en el túnel” y luego, si es necesario, se “devuelven del túnel”.

El último de los conceptos de IDEF0 es el Glosario. Para cada uno de los elementos IDEF0: diagramas, bloques funcionales, arcos de interfaz, el estándar existente implica la creación y mantenimiento de un conjunto de definiciones relevantes, palabras clave, narrativas, etc. que caracterizan el objeto desplegado por este elemento. Este conjunto se denomina glosario y es una descripción de la esencia de este elemento. Por ejemplo, para un arco de interfaz de control “orden de pago”, el glosario puede contener una lista de campos del documento correspondiente al arco, el conjunto de visas requerido, etc. El glosario complementa armoniosamente el lenguaje gráfico, proporcionando a los diagramas la información adicional necesaria.

Figura 4. Descomposición de bloques funcionales.

Principios para limitar la complejidad de los diagramas IDEF0

Normalmente, los modelos IDEF0 llevan información compleja y concentrada, y para limitar su congestión y hacerlos legibles, se adoptan los límites de complejidad correspondientes en el estándar correspondiente:

Limitar el número de bloques funcionales en el diagrama de tres a seis. El límite superior (seis) obliga al diseñador a utilizar jerarquías al describir elementos complejos, y el límite inferior (tres) asegura que haya suficiente detalle en el diagrama correspondiente para justificar su creación;

Limitar el número de arcos de interfaz adecuados para un bloque funcional (dejando un bloque funcional) a cuatro.
Por supuesto, no es necesario seguir estrictamente estas restricciones, sin embargo, como muestra la experiencia, son muy prácticas en el trabajo real.

Disciplina del trabajo en grupo en el desarrollo del modelo IDEF0

El estándar IDEF0 contiene un conjunto de procedimientos que permiten a un gran grupo de personas de diferentes áreas del sistema modelado desarrollar y acordar un modelo. Normalmente, el proceso de desarrollo es iterativo y consta de las siguientes etapas condicionales:

Creación de un modelo por un grupo de especialistas relacionados con diversas áreas de la empresa. Este grupo se denomina Autores en términos de IDEF0. La construcción de un modelo inicial es un proceso dinámico durante el cual los autores preguntan a personas competentes sobre la estructura de varios procesos. Sobre la base de las disposiciones existentes, los documentos y los resultados de la encuesta, se crea un borrador (Borrador del modelo) del modelo.

Distribución del borrador para revisión, aprobaciones y comentarios. En esta etapa, hay una discusión del borrador del modelo con una amplia gama de personas competentes (en términos de lectores de IDEF0) en la empresa. Al mismo tiempo, cada uno de los diagramas del borrador del modelo es criticado y comentado por escrito y luego transferido al autor. El autor, a su vez, también está de acuerdo por escrito con la crítica o la rechaza, esbozando la lógica de la toma de decisiones y devuelve el borrador revisado para su posterior consideración. Este ciclo continúa hasta que los autores y lectores llegan a un consenso.

Aprobación del modelo. El modelo aprobado es aprobado por el jefe del grupo de trabajo en el caso de que los autores del modelo y los lectores no tengan desacuerdos sobre su adecuación. El modelo final es una visión coherente de la empresa (sistema) desde un punto de vista dado y para un propósito determinado.
La visibilidad del lenguaje gráfico IDEF0 hace que el modelo sea bastante legible para personas que no participaron en el proyecto de su creación, así como efectivo para la realización de espectáculos y presentaciones. En el futuro, sobre la base del modelo construido, se pueden organizar nuevos proyectos destinados a realizar cambios en la empresa (en el sistema).

Características de la práctica nacional de utilizar modelos funcionales mediante IDEF0

V últimos años El interés por las metodologías de la familia IDEF crece constantemente en Rusia. Constantemente observo esto, mirando las estadísticas de llamadas a mi página web personal (http://www.vernikov.ru), que describe brevemente los principios básicos de estos estándares. Al mismo tiempo, yo diría que el interés en estándares como el IDEF3-5 es teórico y el IDEF0 está prácticamente justificado. De hecho, las primeras herramientas Case que permiten construir diagramas DFD e IDEF0 aparecieron en el mercado ruso en 1996, simultáneamente con el lanzamiento del popular libro sobre los principios del modelado en los estándares SADT.

Sin embargo, la mayoría de los ejecutivos todavía consideran la aplicación práctica del modelado en los estándares IDEF como una declaración de moda más que como una forma efectiva de optimizar el sistema de gestión empresarial existente. Lo más probable es que esto se deba a una pronunciada falta de información sobre la aplicación práctica de estas metodologías y al indispensable sesgo de software de la gran mayoría de publicaciones.

No es ningún secreto que casi todos los proyectos de relevamiento y análisis de finanzas y actividad económica Las empresas ahora en Rusia están de una forma u otra relacionadas con la construcción. sistemas automatizados administración. Gracias a esto, los estándares IDEF en el entendimiento de la mayoría se han vuelto condicionalmente inseparables de la implementación tecnologías de la información, aunque con su ayuda a veces es posible resolver eficazmente incluso pequeños problemas locales, literalmente con la ayuda de un lápiz y papel.

Al realizar proyectos complejos de encuestas empresariales, el desarrollo de modelos en el estándar IDEF0 le permite mostrar visual y eficazmente todo el mecanismo de la actividad empresarial en el contexto deseado. Sin embargo, lo más importante es la colaboración que brinda IDEF0. En mi práctica, hubo bastantes casos en los que la construcción del modelo se llevó a cabo con la ayuda directa de empleados de varios departamentos. Al mismo tiempo, el consultor les explicó los principios básicos del IDEF0 en un tiempo bastante corto y les enseñó a trabajar con el software de aplicación correspondiente. Como resultado, los empleados de varios departamentos crearon diagramas IDEF de las actividades de su unidad funcional, que debían responder a las siguientes preguntas:

¿Qué va a la unidad "en la entrada"?

¿Qué funciones y en qué secuencia se realizan dentro de la unidad?

¿Quién es el responsable de cada una de las funciones?

¿En qué se guía el ejecutor en el desempeño de cada una de las funciones?

¿Cuál es el resultado del trabajo de la unidad (salida)?

Después de acordar los borradores de los diagramas dentro de cada departamento específico, el consultor los ensambla en un borrador del modelo empresarial, en el que todos los elementos de entrada y salida están vinculados. En esta etapa, se registran todas las discrepancias de los diagramas individuales y sus lugares controvertidos. Además, este modelo pasa nuevamente por los departamentos funcionales para una mayor coordinación y hacer los ajustes necesarios. Como resultado, en un tiempo bastante corto y con la participación de un mínimo de recursos humanos de una empresa consultora (y estos recursos, como saben, son muy costosos), se obtiene un modelo IDEF0 de una empresa de acuerdo con el “ Como es ”principio, y, lo que es importante, representa una empresa con puestos de empleados que laboran en ella y conocen a fondo todos los matices, incluidos los informales. En el futuro, este modelo se trasladará para su análisis y procesamiento a analistas de negocio que buscarán cuellos de botella en la gestión de la empresa y optimizarán los procesos clave, transformando el modelo “Como está” en la vista “Como debe ser” correspondiente. Con base en estos cambios, se llega a una conclusión final, que contiene recomendaciones para reorganizar el sistema de gestión.

Por supuesto, este enfoque requiere una serie de medidas organizativas, principalmente por parte de la dirección de la empresa encuestada. Esto se debe a que esta técnica implica la asignación de algunos empleados responsabilidades adicionales sobre el desarrollo y aplicación práctica de nuevas metodologías. Sin embargo, al final, esto vale la pena, ya que las una o dos horas adicionales de trabajo de los empleados individuales durante varios días pueden ahorrar significativamente dinero en el pago de servicios de consultoría a una empresa externa (que en cualquier caso interrumpirá el trabajo). de los mismos empleados con cuestionarios y preguntas). En cuanto a los propios empleados de la empresa, de una forma u otra, no he encontrado ninguna oposición expresada por su parte.

La conclusión de todo esto se puede hacer de la siguiente manera: no es en absoluto necesario encontrar soluciones para problemas estándar cada vez. Siempre que se enfrente a la necesidad de analizar un sistema funcional en particular (desde un sistema de diseño de naves espaciales hasta el proceso de preparación de una cena compleja), utilice métodos que se han probado y probado a lo largo de los años. Uno de estos métodos es IDEF0, que le permite resolver problemas complejos de la vida con la ayuda de sus herramientas simples y comprensibles.

Conocida hoy no solo en círculos estrechos, la abreviatura IDEF0 es la primera metodología para estandarizar el trabajo en los procesos comerciales. Fue desarrollado a mediados del siglo pasado como parte de un proyecto aeroespacial en los Estados Unidos y, habiendo demostrado su efectividad, se ha convertido en un estándar federal. En nuestro país en el año 2000 se elaboró un documento " Metodología de Modelado Funcional IDEF0. Documento guía Metodología de modelado funcional Documento de orientación IDEF0. Edición oficial. Gosstandart de Rusia RD IDEF0 - 2000. Desarrollado por el Centro de Investigación CALS - Tecnologías "Logística Aplicada". Adoptado y puesto en vigor por la Resolución del Gosstandart de Rusia 2000, Moscú”, Pero como estándar nunca fue aprobado. Aunque esto no impidió que esta metodología se convirtiera en una de las herramientas más populares para el modelado gráfico de procesos de negocios en nuestro país. En este artículo, los invito a revisar el modelo IDEF0 y evaluar la relevancia actual de este enfoque.

Conceptos básicos y abreviaturas

Entendamos un poco sobre los nombres de los elementos clave de la metodología. El estándar gráfico IDEF0 es parte de la metodología SADT (Structured Analysis and Design Technique). IDEF es una abreviatura de ICAM Definition, e ICAM se deriva de Integrated Computer Aided Manufacturing, que se traduce como informatización integrada de la producción. La metodología SADT es toda una familia de 15 modelos diferentes, que en conjunto se suponía que permitían el estudio de la estructura, parámetros y características de los sistemas productivos-técnicos y organizativos-económicos.

IDEF0 es un modelo funcional, que es el núcleo de todas las demás estructuras, vincula los flujos de información y materiales, la estructura organizativa, las acciones de control y la propia actividad de la empresa. El estándar gráfico para los procesos de modelado también se llama notación. Es decir, la notación es un sistema de requisitos y reglas para construir un modelo de actividad de una forma u otra. Por tanto, conviene llamar IDEF0 a la notación que forma parte de la metodología SADT.

La notación IDEF0 es una técnica bastante rigurosa que se desarrolló originalmente, como los estándares de diseño técnico, para el modelado manual. Por lo tanto, contiene requisitos para la ubicación de flechas, el formato de todos los elementos, el contenido del marco de información para el diagrama IDEF0, etc. Dado que las actividades de la empresa son un complejo sistema de acciones multinivel, siempre hay muchos esquemas, y se requiere una sistematización y navegación inequívocas a través de todos los elementos del modelo. Ahora bien, esto se hace principalmente por sistemas informáticos que admiten el modelado en esta notación. En el territorio de Rusia, los más famosos y disponibles en la actualidad son los sistemas AllFusion Process Modeler y Business Studio. Planeo dedicar artículos separados a la revisión de estos sistemas.

Bloque funcional

El elemento central del modelo IDEF0 es la función, que se muestra en el diagrama como bloque funcional- un rectángulo, dentro del cual se indica la acción en forma de sustantivo verbal. La acción puede ser muy diferente en escala, desde las actividades de la empresa en general hasta la manipulación específica en particular. Ejemplos: "Producción y venta de vajillas de cerámica" y "Dibujo de un producto".

Elementos de bloque de función obligatorios en IDEF0

Independientemente de la escala de acciones, todas las funciones se muestran de manera uniforme y necesariamente contienen 4 flujos de teclas, que se asignan rígidamente a los lados del bloque funcional:

a la izquierda, insumos o recursos utilizados para realizar la función;
a la derecha - salidas o resultados de la ejecución de la función;
en la parte superior - acciones de control que determinan cómo y cuántos resultados deben producirse;
a continuación: mecanismos que reflejan quién y con la ayuda de qué debe hacer este trabajo.

Este enfoque le permite ahorrar un poco en las explicaciones de los diagramas y lograr una ambigüedad en la visualización de los flujos, lo que hace que todo el modelo sea más delgado.

Para construir un modelo funcional, la metodología IDEF0 requiere que se observen las siguientes reglas.

Los insumos son recursos que transfieren su valor a los productos por completo, es decir, se gastan en crear un resultado en su totalidad, y los mecanismos son recursos que transfieren su valor solo parcialmente (equipos a través de la depreciación y personas a través de los salarios).
La gestión es un elemento necesario del modelo, ya que vincula todas las acciones al sistema de normativa de la empresa, indicando claramente qué normas y requisitos deben observarse en el proceso de desempeño de la función. A menudo, este flujo se trata formalmente, pero el esquema pierde su rigor y, a veces, incluso su significado.
Cada bloque funcional debe tener al menos una flecha a cada lado (ya que no puede haber trabajo sin recursos o resultados, y una instrucción sin ejecutor o instrucción estará incompleta).

El esquema considerado es un "bloque de construcción" del enfoque IDEF0. El modelado funcional implica una transición gradual de lo general a lo particular a través de la descomposición. La descomposición es "profundizar" en la función en consideración, dividiéndola en funciones más pequeñas. Al mismo tiempo, cuando la función de nivel superior se presenta de forma generalizada y después de descomponerla, conviene llamarla proceso.

Diagrama contextual

Al más alto nivel, la empresa se presenta como una "caja negra" en la que se desarrolla alguna actividad que traduce entradas en salidas. Este nivel se suele denominar "", es decir, un diagrama que describe el contexto de las actividades de la empresa. Además, el diagrama de contexto muestra las características clave de todo el modelo.

El objetivo es una formulación específica del propósito del modelo, que se puede utilizar para verificar la precisión de la construcción del modelo en el futuro.
Punto de vista: en cuya cara se construye el modelo, ya que el modelo siempre depende de su autor y foco de atención. Si construimos un modelo general de empresa, generalmente se presenta desde el punto de vista de su director.
El tipo de modelo es una indicación de la información que se muestra en los diagramas. Puede haber 2 opciones principales: TAL CUAL ("como está") o POR SER ("como será"). Esta separación es necesaria, ya que podemos construir modelos tanto para analizar actividades como para transformarlas. Debemos ser claramente conscientes de lo que estamos haciendo y también transmitir esta información a los demás.

Así, el diagrama de contexto contiene en la forma más generalizada una descripción de las actividades de la empresa, que está impregnada de los flujos que conectan a la empresa con el mundo exterior. Creo que también deberíamos detenernos en ellos con más detalle.

Corrientes principales

La experiencia ha demostrado que, a pesar de la aparente sencillez y formalidad de este nivel, muchas veces es necesario permanecer en él durante mucho tiempo, ya que aquí deben reflejarse todos los resultados que son significativos para el propietario y el mercado. Un error puede llevar a la creación de modelos que no cumplan con los objetivos del negocio. Para verificar que se reflejen los flujos significativos, asegúrese de que los 4 tipos de flujo principales estén presentes en su diagrama.

Material: materiales y componentes en la entrada y productos terminados a la salida.
Cliente: un cliente potencial entrante y un cliente satisfecho.
Financiero: en la entrada, suelen ser inversiones, pagos de clientes (ingresos), préstamos y otros ingresos; el resultado son pagos a proveedores, impuestos, pagos de préstamos y ganancias.
Informativo: en la entrada, todos estos son flujos de información sobre el entorno externo (condiciones del mercado, comportamiento de los competidores, innovación tecnológica etc.), y el resultado es el flujo de información que la empresa comunica sobre sí misma al mundo (toda la información publicitaria, así como todo tipo de informes a las autoridades reguladoras).

Tenga en cuenta que una empresa es un sistema abierto y nada aparece ni desaparece en él. Una empresa solo puede transformar flujos entrantes en flujos salientes, y si lo hace bien, entonces un adicional Flujo de efectivo(beneficio), reflejando, en cierto sentido, la calidad de todo el sistema.

(Click para agrandar)

Es bueno si resaltas cada uno de estos tipos de flujos con tu propio color para que puedas distinguir fácilmente el movimiento de los recursos y no perderte puntos importantes... Por ejemplo, a menudo es posible observar la ausencia de un cliente en los flujos de la empresa, por lo tanto, trabajar con él se basa en un principio sobrante: el cliente a menudo se siente como un obstáculo para los empleados de la empresa, cuyas tareas se centran en procesar el flujo de documentos.

Las flechas de control se pueden representar mediante un solo tipo de flujo: el flujo de información, que se puede dividir en 2 subespecies. El primero son documentos como:

leyes y regulaciones;
pedidos, pedidos;
instrucciones y reglamentos;
planes;
documentación de diseño, etc.

La segunda es la información no documentada, que a menudo incluye los requisitos de los propietarios.

Y, finalmente, mecanismos: solo hay 2 tipos de flujos: equipo (material) e intérpretes (departamentos y personas). ¡No puede haber documentos aquí, al igual que no puede haber personas en las flechas de control!

El modelo proporciona numeración continua para la navegación. El diagrama de contexto está numerado "A-0". En el futuro, cada bloque funcional obtendrá su propio número, sin importar cuán profunda sea la descomposición.

Descomposición

Después de calcular los flujos del diagrama de contexto, podemos proceder a la descomposición. Pasando a un nivel inferior, como abriendo una "caja negra", primero vemos una hoja en blanco con flechas que se han adjuntado al bloque funcional.

(Click para agrandar)

Y aquí comienza el modelado funcional real: debemos comprender qué conjunto de acciones pueden conectar estos flujos y garantizar que se cumplan todos los requisitos. La dificultad radica en el hecho de que hay muchas acciones en la empresa y, en el diagrama, tenemos derecho a mostrar no más de 9 funciones; de lo contrario, el diagrama se volverá ilegible y, en consecuencia, inútil.

No siempre es fácil organizar actividades complejas de tal manera que sigan siendo visuales, legibles y al mismo tiempo completas. Muy a menudo, recurren a dividir toda la variedad de procesos en grandes bloques principales, los más importantes de los cuales son los siguientes.

Creación de un producto (resultado).
Promoción y venta: trabajar con el flujo de clientes.
El apoyo a las actividades de creación de productos son procesos secundarios que son necesarios para cumplir con los requisitos gubernamentales o para asegurar la conveniencia del trabajo (personal y contabilidad, servicios de transporte, limpieza de locales, etc.).
Creación de flujos de gestión: la actividad de desarrollar soluciones de gestión que determinarán los requisitos para todos los procesos de la empresa.

La siguiente figura muestra el diagrama de descomposición de nuestro ejemplo.

(Click para agrandar)

En el diagrama, los procesos deben organizarse en diagonal, esto se llama principio de dominio, que implica la disposición de bloques funcionales de izquierda a derecha y de arriba a abajo, en orden de importancia o en orden cronológico. La numeración de bloques es la misma.

El trabajo adicional en el modelo es similar al primer paso: cada bloque funcional del primer nivel se descompone. La numeración del bloque contendrá el número del primer nivel: A1.1… A1n, A2.1… A2.n, etc.

Conclusiones sobre la relevancia de la notación

En el marco de este artículo, fue posible mostrar solo los conceptos básicos de la notación IDEF0 utilizando un breve ejemplo de IDEF0, por el cual, por supuesto, es difícil juzgar la metodología en su conjunto. Pero mucha experiencia en el uso de esta notación en la práctica me permite sacar las siguientes conclusiones.

El modelo tiene un buen potencial visualizador, pero, en mi opinión, su mayor importancia está en el efecto disciplinario. Las reglas y limitaciones incrustadas en la metodología nos obligan a desarrollar una actitud sistemática y estricta hacia los modelos, lo que repercute muy bien en la calidad del resultado final.
El modelo le permite construir flujos de comunicación entre cosas aparentemente no fuertemente conectadas: conectar los subsistemas de front y back office con la administración, lo cual es mucho peor para otras notaciones.
El enfoque es simple y directo para la mayoría de los participantes del proyecto. La construcción y lectura de diagramas en esta notación está limitada solo por el deseo de profundizar en las complejidades de los flujos comerciales.

Algunos de los argumentos anteriores hacen pensar que este enfoque es el mejor y el único para un modelado completo de actividades. Pero no olvide que el modelo funcional está diseñado solo para el nivel superior de modelado. El uso de la notación IDEF0 para el diseño del trabajo a nivel de intérpretes conduce al hecho de que los esquemas son puramente ilustrativos y sobre su base es imposible construir una regulación sensata, ya que no contienen:

concretar los eventos de inicio y parada del proceso;
condiciones para la transición de una acción a otra;
la capacidad de mostrar visualmente todos los recursos e intérpretes sin sobrecargar el diagrama con flechas.

Por lo tanto, si usa esta notación para las tareas para las que está destinada (estructurar actividades de alto nivel), IDEF0 es prácticamente la única notación actual que le permite hacer esto de manera significativa y precisa.

V gestión de proyectos este estándar de modelado es más aplicable cuando necesita vincular diferentes proyectos o procesos con flujos visuales. Al mismo tiempo, el modelo gráfico permitirá distribuir de forma más racional la responsabilidad y los recursos por tareas. La lógica de las tareas del proyecto, reflejada en los diagramas, ayudará a preparar una mejor calidad. plan de calendario en forma de diagrama de Gantt.

6.2. Objeto y composición de la metodología SADT (IDEF0)

Metodología SADT (Técnica de Diseño y Análisis Estructurado - metodología de diseño y análisis estructural) es un conjunto de métodos, reglas y procedimientos diseñados para construir un modelo funcional de un sistema.

El desarrollo de esta metodología fue iniciado por Douglas Ross (EE. UU.) A mediados de los años 60. Siglo XX Desde entonces, los analistas de sistemas de SofTech, Inc. mejoró SADT y lo usó para resolver una amplia gama de problemas. Software de redes telefónicas, diagnóstico, planificación estratégica y a largo plazo, producción automatizada y el diseño, la configuración del sistema informático, la capacitación del personal, la gestión financiera y de adquisiciones son algunas de las áreas en las que la SADT se puede utilizar de manera eficaz. La amplia gama de áreas indica la versatilidad y el poder de la metodología SADT. En el programa "Integración de computadora y tecnologias industriales La Fabricación Asistida por Computadora Integrada (ICAM) por el Departamento de Defensa de los Estados Unidos ha sido reconocida como una SADT útil. Esto llevó a la publicación de una parte en 1981 llamada IDEF0 (DEFinición de Icam), como estándar federal desarrollar software... Bajo este nombre, SADT ha llegado a ser utilizado por miles de profesionales en organizaciones militares e industriales. La última revisión del estándar IDEF0 se publicó en diciembre de 1993. Instituto Nacional de Estándares y Tecnología (NIST).

Esta metodología compite con los métodos orientados al flujo de datos (DFD) al describir el aspecto funcional de un sistema de información. Por el contrario, IDEF0 permite:

Describa cualquier sistema, no solo los sistemas de información (DFD está destinado a describir el software);

Cree una descripción del sistema y su entorno externo antes de definir los requisitos finales para él. En otras palabras, con la ayuda de esta metodología, uno puede construir y analizar gradualmente el sistema incluso cuando todavía es difícil imaginar su implementación.

Por lo tanto, IDEF0 se puede aplicar en las primeras etapas de la construcción de una amplia gama de sistemas. Al mismo tiempo, se puede utilizar para analizar funciones. sistemas existentes y desarrollar soluciones para su mejora.

La base de la metodología IDEF0 es un lenguaje gráfico para describir procesos. Un modelo en notación IDEF0 es una colección de diagramas interconectados y ordenados jerárquicamente. Cada diagrama es una unidad de descripción del sistema y se encuentra en una hoja separada.

El modelo (TAL CUAL, FUTURO o DEBE SER) puede contener 4 tipos de gráficos [ , ]:

Diagrama contextual;

Diagramas de descomposición;

Diagramas de árbol de nodos;

Para diagramas de exposición solamente (FEO).

Diagrama contextual (diagrama de nivel superior), que es la parte superior de la estructura de árbol de los diagramas, muestra el propósito del sistema (función principal) y su interacción con el entorno externo. Cada modelo puede tener solo un diagrama de contexto. Luego de la descripción de la función principal, se realiza la descomposición funcional, es decir, se determinan las funciones que componen la principal.

Además, las funciones se dividen en subfunciones y así sucesivamente hasta que se alcanza el nivel de detalle requerido del sistema en estudio. Los diagramas que describen cada uno de esos fragmentos del sistema se denominan diagramas de descomposición ... Después de cada sesión de descomposición, se llevan a cabo sesiones de examen: los expertos en el área temática indican la correspondencia de los procesos reales con los diagramas creados. Se eliminan las inconsistencias encontradas, luego de lo cual se procede a detallar más los procesos.

Diagrama de árbol de nodos muestra la dependencia jerárquica de funciones (obras), pero no la relación entre ellas. Puede haber varios de ellos, ya que el árbol se puede construir a una profundidad arbitraria y desde un nodo arbitrario.

Gráficos de exposición se construyen para ilustrar fragmentos individuales del modelo con el fin de mostrar un punto de vista alternativo sobre los procesos que ocurren en el sistema (por ejemplo, desde el punto de vista de la gestión de la organización).

6.3. Elementos de la notación gráfica IDEF0

La metodología IDEF0 ha encontrado una amplia aceptación y aplicación, principalmente debido a la notación gráfica simple utilizada para construir el modelo. Los componentes principales del modelo son diagramas. Muestran las funciones del sistema en forma de rectángulos, así como las conexiones entre ellos y el entorno externo mediante flechas. El uso de solo dos primitivas gráficas (rectángulo y flecha) le permite explicar rápidamente las reglas y principios de la construcción de diagramas IDEF0 a personas que no estén familiarizadas con esta metodología. Esta ventaja le permite conectar y activar la actividad del cliente en la descripción de procesos comerciales utilizando un lenguaje gráfico formal y visual.

La siguiente figura muestra los elementos básicos de la notación gráfica IDEF0.

Arroz. 6.1. Elementos de la notación gráfica IDEF0

El rectángulo representa trabajo (proceso, actividad, función o tarea) , que tiene un objetivo fijo y conduce a algún resultado final. El nombre de la obra debe expresar la acción (por ejemplo, "Fabricación de una pieza", "Cálculo de velocidades permitidas", "Formación de la lista de la casa centralizada número 3").

La interacción de las obras entre ellos mismos y el mundo exterior se describe en forma de flechas. IDEF0 distingue 5 tipos de flechas :

- Entrada (Entrada en inglés) - material o información que el trabajo utiliza y transforma para obtener un resultado (salida). El inicio de sesión responde a la pregunta "¿Qué se va a procesar?" La entrada puede ser un objeto material (materia prima, una pieza, un boleto de examen) o uno que no tiene contornos físicos claros (una consulta a la base de datos, una pregunta de un profesor). Se asume que la obra puede no tener flechas de entrada. Las flechas de entrada siempre se dibujan al entrar en el lado izquierdo de la obra;

- control (Control en inglés): datos de control, reglamentarios y reglamentarios que guían el trabajo. El departamento responde a la pregunta “¿De acuerdo con qué se está haciendo el trabajo?”. La dirección influye en el trabajo, pero no se ve transformada por él, es decir, actúa como una limitación. Como gestión, puede haber reglas, estándares, regulaciones, precios, instrucciones orales. Las flechas de control se dibujan como parte de la cara superior del trabajo. Si, al construir un diagrama, surge la pregunta de cómo dibujar correctamente una flecha desde arriba o hacia la izquierda, se recomienda dibujarla como entrada (flecha a la izquierda);

- producción (Salida en inglés) - material o información que representa el resultado del trabajo. El resultado responde a la pregunta "¿Cuál es el resultado del trabajo?" La salida puede ser un objeto material (pieza, automóvil, documentos de pago, una declaración) o intangible (obtener datos de una base de datos, responder una pregunta, indicación verbal). Las flechas de salida se dibujan desde el lado derecho del trabajo;

- mecanismo (Mecanismo de ing.) - recursos que realizan el trabajo. El mecanismo responde a la pregunta "¿Quién está haciendo el trabajo o por qué medios?" El mecanismo puede ser el personal de la empresa, el estudiante, la máquina, el equipo, el programa. Las flechas del mecanismo se dibujan entrando en el borde inferior de la obra;

- llama (Llamada en inglés): la flecha indica que parte del trabajo se está realizando fuera del bloque en cuestión. Las flechas de salida se dibujan como provenientes del borde inferior de la obra.

6.4. Tipos de vínculos entre trabajos

Después de determinar la composición de las funciones y las relaciones entre ellas, surge la pregunta sobre su correcta composición (asociación) en módulos (subsistemas). Esto implica que cada función separada debe resolver una, estrictamente una tarea especifica... De lo contrario, se requiere una mayor descomposición o separación de funciones.

Cuando se combinan funciones en subsistemas, es necesario esforzarse por que la conectividad interna (entre funciones dentro de un módulo) sea lo más fuerte posible y externa (entre funciones incluidas en diferentes módulos) lo más débil posible. A partir de la semántica de los enlaces de la metodología, introducimos una clasificación de enlaces entre funciones (trabajos). Esta clasificación es una extensión. Los tipos de enlaces se enumeran en orden decreciente de importancia (fuerza de enlace). En los ejemplos citados, las líneas engrosadas resaltan las funciones entre las cuales existe el tipo de conexión considerado.

1. Relación jerárquica (relación "parte" - "todo") tiene lugar entre la función y las subfunciones que la componen.

Arroz. 6.2. Relación jerárquica

2. Comunicación regulatoria (control, subordinada) refleja la dependencia de una función de otra, cuando la salida de un trabajo se envía para controlar otro. La función de la que sale el control debe considerarse reguladora o controladora, y en la que ingresa: subordinada. Distinguir enlace de control directo cuando el control se transfiere de un trabajo de nivel superior a uno de nivel inferior (figura 6.3), y retroalimentación de la gerencia cuando el control se transfiere de aguas abajo a aguas arriba (Fig. 6.4).

3. Comunicación funcional (tecnológica) ocurre cuando la salida de una función sirve como entrada para la siguiente función. Desde el punto de vista del flujo de objetos materiales, esta relación muestra la tecnología (secuencia de trabajo) de procesar estos objetos. Distinguir conexión directa en la entrada cuando la salida se transfiere del trabajo de nivel superior al de nivel inferior (figura 6.5), y retroalimentación de entrada cuando la salida se transfiere de aguas abajo a aguas arriba (Figura 6.6).


Arroz. 6.5. Conexión directa a la entrada	Arroz. 6.6. Retroalimentación de entrada

4. Comunicación con el consumidor ocurre cuando la salida de una función sirve como mecanismo para la siguiente función. Así, una función consume los recursos generados por la otra.

Arroz. 6.7. Comunicación con el consumidor

5. Enlace lógico observado entre funciones lógicamente homogéneas. Tales funciones, por regla general, realizan el mismo trabajo, pero de diferentes formas (alternativas) o utilizando diferentes datos iniciales (materiales).

Arroz. 6.8. Enlace lógico

6. Comunicación colegiada (metódica) tiene lugar entre funciones cuyo algoritmo de operación está determinado por el mismo control. Un análogo de dicha comunicación es el trabajo conjunto de los empleados de un departamento (colegas), subordinados al jefe, que da instrucciones y órdenes (señales de control). Tal conexión también surge cuando los algoritmos para el funcionamiento de estas funciones están determinados por el mismo soporte metodológico (SNIP, GOST, materiales regulatorios oficiales, etc.), que sirve como control.

Arroz. 6,9. Conexión metódica

7. Conexión de recursos ocurre entre funciones que utilizan los mismos recursos para su trabajo. Las funciones que dependen de los recursos generalmente no se pueden ejecutar al mismo tiempo.

Arroz. 6.10. Conexión de recursos

8. Comunicación de información tiene lugar entre funciones utilizando la misma información como entrada.

Arroz. 6.11. Comunicación de información

9. Conexión temporal ocurre entre funciones que deben ejecutarse simultáneamente antes o simultáneamente después de otra función.

Además de los casos indicados en la figura, esta conexión también tiene lugar entre otras combinaciones de control, entrada y mecanismo que ingresan a una función.

Arroz. 6.12. Conexión temporal

10. Conexión aleatoria ocurre cuando hay poca o ninguna conexión específica entre funciones.

Arroz. 6.13. Conexión aleatoria

De los tipos de enlaces anteriores, el más fuerte es el enlace jerárquico, que, de hecho, determina la combinación de funciones en módulos (subsistemas). Los lazos regulatorios, funcionales y de consumo son algo más débiles. Las funciones con estos enlaces generalmente se implementan en un subsistema. Las conexiones lógicas, colegiales, de recursos e informativas se encuentran entre las más débiles. Las funciones que las poseen, por regla general, se implementan en diferentes subsistemas, con la excepción de las funciones lógicamente homogéneas (funciones conectadas por conexión lógica). La conexión temporal indica una dependencia débil de las funciones entre sí y requiere su implementación en módulos separados.

Por lo tanto, al combinar funciones en módulos, los primeros cinco tipos de enlaces son los más deseables. Las funciones asociadas con los últimos cinco enlaces se implementan mejor en módulos separados.

IDEF0 tiene convenciones (reglas y pautas) para crear diagramas que faciliten la lectura y el examen del modelo [,]. Algunas de estas reglas son compatibles con CASE automáticamente, otras deben aplicarse manualmente.

1. Antes de construir un modelo, es necesario decidir qué modelo (s) del sistema se construirán. Esto implica definir su tipo TAL CUAL, FUTURO o DEBERÍA, así como definir la posición desde el punto de vista del cual se construye el modelo. Es mejor imaginar un "punto de vista" como un lugar (posición) de una persona u objeto, en el que uno debe estar para ver el sistema en acción. Por ejemplo, al construir un modelo para el funcionamiento de una tienda de abarrotes, puede elegir un vendedor, cajero, contador o director entre los posibles solicitantes desde cuyo punto de vista se está considerando el sistema. Por lo general, se elige un punto de vista, que cubre más completamente todos los matices del funcionamiento del sistema y, si es necesario, se construyen diagramas FEO para algunos diagramas de descomposición, mostrando un punto de vista alternativo.

2. El diagrama de contexto muestra un bloque que muestra el propósito del sistema. Se recomienda que muestre de 2 a 4 flechas que entran y salen de cada lado.

3. El número de bloques en los diagramas de descomposición se recomienda dentro del rango de 3 a 6. Si hay dos bloques en el diagrama de descomposición, generalmente no tiene sentido. Con una gran cantidad de bloques, el diagrama se vuelve sobresaturado y difícil de leer.

4. Los bloques en el diagrama de descomposición deben organizarse de izquierda a derecha y de arriba a abajo. Esta disposición le permite reflejar más claramente la lógica y la secuencia del trabajo. Además, las rutas de flechas serán menos confusas y tendrán un número mínimo de intersecciones.

5. No se permite la ausencia de flechas de control y de entrada para la función. Esto significa que el lanzamiento de esta función no está controlado y puede ocurrir en cualquier momento arbitrario o nunca.

Arroz. 6.14. Función sin control y entrada

Un bloque con solo control puede verse como una llamada en un programa de una función (procedimiento) sin parámetros. Si el bloque tiene una entrada, entonces es equivalente a llamar a una función con parámetros en el programa. Por tanto, un bloque sin control ni entrada equivale a una función que nunca se llama para su ejecución en el programa.

En la Fig. 6.7–6.12, mostrando fragmentos de diagramas IDEF0, hay bloques sin entrada ni control. Esto no debe verse como un error, ya que se da a entender que una de estas flechas debe ser.

6. Cada bloque debe tener al menos una salida.

Arroz. 6.15. Sin función de salida

Las obras sin resultados no tienen sentido y no deben modelarse. Una excepción es el trabajo que se muestra en el modelo TAL CUAL. Su presencia indica la ineficiencia e imperfección de los procesos tecnológicos. En el modelo TO-BE, estos trabajos deberían estar ausentes.

7. Al construir diagramas, debe minimizar el número de intersecciones, vueltas y giros de flechas.

8. Las retroalimentaciones y las iteraciones (acciones cíclicas) se pueden representar mediante arcos hacia atrás. La retroalimentación en la entrada es dibujada por el bucle "inferior", retroalimentación en el control - por el "superior" (ver Fig. 6.4 y 6.6).

9. Cada bloque y cada flecha en los diagramas deben tener un nombre. Está permitido utilizar flechas de ramificación (descomposición) o fusión (composición). Esto se debe al hecho de que los mismos datos u objetos generados por un trabajo se pueden utilizar en varios otros trabajos a la vez. Por el contrario, los mismos u homogéneos datos y objetos generados por diferentes obras se pueden utilizar en un solo lugar.

Arroz. 6.16. Flechas ramificadas

En este caso, se permite asignar nombres de calificación a diferentes ramas de la flecha después de la ramificación (antes de la fusión). Si alguna rama después de la rama no tiene nombre, entonces se considera que su nombre corresponde al nombre de flecha registrado antes de la rama.

Entonces, en la fig. 6.16 los controles incluidos en los bloques "Fabricación de piezas" y "Montaje del producto" tienen significados aclaratorios y son parte de más administración General"Planos". Todos los dibujos se utilizan para el funcionamiento del bloque "Control de calidad".

No está permitido dibujar flechas en el diagrama si no se nombran antes y después de la ramificación. En la Fig. 6.17 la flecha incluida en el bloque "Generación de listas estándar" no tiene un nombre antes y después de la bifurcación, lo cual es un error.

Arroz. 6.17. Nombre de flecha incorrecto

10. Al construir diagramas para una mejor legibilidad, se puede utilizar el mecanismo de túnel de flechas. Por ejemplo, para no saturar los diagramas de los niveles superiores (padre) con detalles innecesarios, en los diagramas de descomposición el inicio del arco se coloca en el túnel.

Arroz. 6.18. Flechas de tunelización

V este ejemplo al construir un modelo de conducción Fiesta de Año Nuevo el mecanismo "dos ejes" no se mostrará en los diagramas de los niveles superiores, al leer lo que puede surgir una pregunta justa: "¿Por qué necesitamos dos ejes en la fiesta de Año Nuevo?"

Del mismo modo, puede hacer un túnel con el objetivo opuesto, sin permitir que la flecha aparezca en los diagramas de nivel inferior. En este caso, los paréntesis se colocan al final de la flecha. En el diagrama de contexto (ver Fig. 6.21), el mecanismo "Path Service Engineer" está tunelizado, que se incluye en el bloque "Determinación de velocidades permitidas". Se tomó esta decisión, ya que el ingeniero está directamente involucrado en todo el trabajo que se muestra en el diagrama de descomposición de este bloque (ver Fig. 6.22). Para no mostrar esta conexión y no saturar el diagrama de descomposición, la flecha fue tunelizada.

11. Todas las flechas que entran y salen del bloque, al construir un diagrama de descomposición para él, deben mostrarse en él. La excepción son las flechas de túnel. Los nombres de las flechas arrastradas al diagrama de descomposición deben coincidir con los nombres que se muestran en el diagrama de nivel superior.

12. Si dos flechas corren paralelas (comienzan en la misma faceta de un trabajo y terminan en la misma faceta del otro trabajo), entonces, si es posible, deben combinarse y denominarse un solo término.

Arroz. 6.19. Fusión de enlaces

13. Cada bloque de los diagramas debe tener su propio número. Para indicar la posición de cualquier gráfico o bloque en la jerarquía, se utilizan números de gráfico. El bloque en el diagrama de nivel superior se indica con 0, los bloques en los diagramas de segundo nivel, con números del 1 al 9 (1, 2, ..., 9), los bloques en el tercer nivel, con dos números. , el primero de los cuales indica el número del bloque detallado del diagrama principal, y el segundo número de bloque en orden en el diagrama actual (11, 12, 25, 63), etc. El diagrama de contexto tiene la designación "A - 0 ", el diagrama de descomposición del primer nivel es" A0 ", los diagramas de descomposición de los siguientes niveles constan de la letra" A "seguida del número del bloque a descomponer (por ejemplo," A11 "," A12 "," A25 "," A63 "). La figura muestra un árbol de diagrama típico (diagrama de árbol de nodo) con numeración.

Arroz. 6.20. Jerarquía de gráficos

En las herramientas CASE modernas, los mecanismos de numeración de trabajos se admiten automáticamente. Las herramientas CASE también proporcionan la construcción automática de diagramas de árbol de nodos que contienen solo enlaces jerárquicos. La parte superior de dicho diagrama puede ser cualquier nodo (bloque) y se puede trazar a cualquier profundidad.

6.6. Un ejemplo de construcción de un modelo IDEF0 para un sistema para determinar velocidades permitidas

Calcular las velocidades permitidas del tren es una laboriosa tarea de ingeniería. Cuando el tren pasa por cualquier tramo velocidad real el movimiento del tren no debería exceder el máximo permitido. Esta velocidad máxima permitida se establece en base a la experiencia operativa y pruebas especialmente realizadas sobre la dinámica del movimiento y el impacto en la vía del material rodante. No superar esta velocidad garantiza la seguridad del tráfico ferroviario, condiciones confortables para los pasajeros, etc. Se determinan en función del tipo de material rodante (marca de locomotora y tipo de vagones), parámetros de la superestructura (como raíles, balasto, traviesas). ) y planta (curvas de radio, curvas de transición, elevación del carril exterior, etc.). Como regla general, para establecer las velocidades permitidas, es necesario determinar al menos dos (en línea recta) y cinco (en curvas) velocidades, a partir de las cuales se selecciona la velocidad final permitida, como la más baja de todas las calculadas. El cálculo de estas velocidades está regulado por la Orden del Ministerio de Ferrocarriles de Rusia No. 41 del 12 de noviembre de 2001 "Normas para las velocidades permitidas del material rodante en vías férreas de ancho 1520 (1524) mm del Transporte Ferroviario Federal".

Como se señaló, la construcción del modelo IDEF0 comienza con la representación de todo el sistema como un componente simple (diagrama de contexto). Este diagrama muestra el propósito (función principal) del sistema y los datos de entrada y salida requeridos, la información de control y regulatoria, y los mecanismos.

El diagrama de contexto para el problema de determinar las velocidades permisibles se muestra en la Figura 6.21. Para construir el modelo, se utilizó el producto BPwin 4.0 de Computer Associates.

Arroz. 6.21. Diagrama de contexto del sistema para la determinación de velocidades permitidas (metodología IDEF0)

Como información de contexto, sobre cuya base se lleva a cabo la determinación de las velocidades permitidas, se utilizan:

Datos del proyecto de una nueva línea o de un proyecto de reconstrucción (contienen toda la información necesaria para la implementación del proyecto, a saber, el kilometraje, los ejes de los puntos separados, el plano de la línea, etc.);

Perfil longitudinal detallado (contiene información similar a la discutida anteriormente);

Pasaporte de la distancia de la pista (contiene información similar a la discutida anteriormente, así como información sobre la estructura superior de la pista (VSP));

Datos sobre los resultados de la encuesta del plano de la pista por el coche de medición de la pista;

Lista de elevaciones del carril exterior en curvas (contiene información sobre el plano de la vía).

Parte de la información original se puede obtener de diferentes fuentes... En particular, la información sobre el plan (parámetros de curvas) se puede tomar del proyecto de una nueva línea o un proyecto de reconstrucción, un perfil longitudinal detallado, un pasaporte de la distancia de la pista, etc.

Control de datos están:

Instrucciones del jefe del servicio de vías de la carretera o del Departamento de vías y estructuras de los ferrocarriles rusos para el cálculo;

Orden No. 41, que contiene información normativa y de referencia, el procedimiento y fórmulas para determinar las velocidades permitidas;

Información sobre el tráfico ferroviario actual o previsto (datos sobre las marcas de las locomotoras en circulación y los tipos de vagones utilizados);

Información sobre las reparaciones previstas de la vía, reconstrucción y reorganización de estructuras y dispositivos.

El resultado El funcionamiento del sistema debe ser:

Hojas de velocidades permitidas, que contienen todo tipo de velocidades calculadas y le permiten establecer el motivo de su limitación;

Boletín de la Orden de la cabecera de vía sobre el establecimiento de velocidades admisibles en las vías y puntos diferenciados (Orden "N") de acuerdo con el formulario adoptado en la vía. La Orden "N" aprobada fija oficialmente las velocidades permitidas del tren;

Formularios estándar No. 1, 1a y 2, que contienen las velocidades permisibles planificadas para el desarrollo del horario de trenes.

Las velocidades contenidas en la Orden "H" y los formularios estándar pueden diferir de las calculadas y mostradas en las hojas de velocidades permitidas. Esto se debe a que reflejan los límites de velocidad no solo por el diseño del material rodante, parámetros y curvas del VSP, sino también por el estado de los dispositivos y estructuras (deformación de la calzada, desviación de los soportes de la red de contactos, etc. .). Además, se ajustan teniendo en cuenta las reparaciones de vías previstas, reconstrucción y reorganización de estructuras y dispositivos, etc.

Una vez construido, el diagrama de contexto se detalla utilizando un diagrama de descomposición de primer nivel. Este diagrama muestra las funciones del sistema que deben implementarse dentro de la función principal. El diagrama por el cual se realiza la descomposición, en relación a los diagramas que lo detallan, se denomina padre ... El diagrama de descomposición en relación con el padre se llama subsidiario .

El diagrama de descomposición del primer nivel para el problema en consideración se muestra en la Figura 6.22. Como regla general, al construir un diagrama de descomposición, la función original (que se descompondrá) se divide en 3 a 8 subfunciones (bloques). En este caso, se recomienda colocar los bloques en el diagrama de descomposición de izquierda a derecha, de arriba a abajo, para que la secuencia y la lógica de interacción de las subfunciones sea mejor visible.

Arroz. 6.22. Diagrama de descomposición de nivel 1 (Metodología IDEF0)

La secuencia de funciones para resolver el problema en consideración es la siguiente:

Introducción y corrección de información y datos de referencia en tramos de carretera (bloques 1 y 2);

Elaboración de un trabajo para el cálculo (bloque 3). Indica para qué tramo y vía, así como la marca de la locomotora y el tipo de vagones, se debe realizar el cálculo;

Cálculo de las velocidades admisibles de acuerdo con el procedimiento y las fórmulas especificadas en la orden nº 41 (bloque 4). La información inicial son los datos a lo largo del recorrido de la sección (plano, estructura superior de la pista, etc.) y los estándares seleccionados en base a la tarea para el cálculo;

Formación de listas de velocidades permitidas (bloque 5). Con base en los resultados del cálculo, se crean varios tipos de documentos de salida que, por un lado, permiten identificar el motivo de los límites de velocidad, por otro lado, actúan como base para la preparación de documentos regulados;

Formación y elaboración del proyecto de Orden "N" y fichas estándar (bloques 6 y 7).

Después de que se construye el diagrama de descomposición de primer nivel, se construyen diagramas separados (diagramas de descomposición de segundo nivel) para las funciones indicadas en él. Luego, el proceso de descomposición (construcción de diagramas) continúa hasta que los detalles adicionales de las funciones pierden su significado. Para cada función atómica que describe una operación elemental (es decir, una función que no tiene diagrama de descomposición), se elabora una especificación detallada que define sus características y algoritmo de implementación. Se pueden utilizar diagramas de flujo de algoritmos para complementar la especificación. Así, el proceso de modelado funcional consiste en construir gradualmente una jerarquía de funciones.

6.7. Códigos ICOM

Las flechas que entran y salen del bloque en el diagrama de nivel superior son las mismas que las flechas que entran y salen del diagrama de nivel inferior, porque el bloque y el diagrama representan la misma parte del sistema (ver Fig. Y ). Como consecuencia, los límites de la función de nivel superior son los mismos que los del diagrama de descomposición.

Códigos ICOM (acrónimo de Entrada, Control, Salida y Mecanismo) son para identificar flechas de límite. El código ICOM contiene un prefijo correspondiente al tipo de flecha (I, C, O o M) y un número de secuencia (ver figura).

Descripción de los diagramas de procesos comerciales "Contabilidad de equipos informáticos de la empresa"

Descripción del diagrama IDEF0

Para construir un proceso de negocio, se utilizó un diagrama IDEF0. La metodología IDEF0 prescribe la construcción de un sistema jerárquico de diagramas: descripciones únicas de fragmentos del sistema. En primer lugar, se realiza una descripción del sistema en su conjunto y su interacción con el mundo exterior (diagrama de contexto). Se construyeron tres niveles del diagrama:

1. Contextual

2. Descomposición funcional

Figura 1 - Diagrama de contexto "Contabilidad del equipo informático empresarial"

La figura 1 muestra un diagrama de contexto del proceso empresarial "Contabilidad de equipos informáticos empresariales". Muestra el sistema en su conjunto y su interacción con los principales flujos externos de información.

Las flechas se indican en el diagrama de contexto.

Tipos de flechas:

Entrada (materiales de entrada: computadoras y accesorios)

Salida (la salida es un informe)

Las flechas de control son documentos y administradores

Las flechas de los mecanismos son empleados y equipos.

Información de entrada para su procesamiento:

Computadoras: PC (computadoras personales) ubicadas en la empresa

Componentes: materiales necesarios para actualizar las computadoras (tarjetas de video, placas base, procesadores, carcasas, fuentes de alimentación, módulos de memoria)

Flujos de salida:

Informe: un informe listo para usar sobre la contabilidad de los equipos informáticos de la empresa.

Controles de entrada:

Reglas: condiciones que deben cumplirse para lograr el objetivo.

Órdenes: la tarea asignada a la empresa (mantener registros de equipos informáticos en la empresa utilizando ciertos sistemas de información)

Los gerentes son directores y gerentes generales de la empresa.

Recursos de entrada:

PC: computadoras con la ayuda de las cuales se lleva a cabo la contabilidad.

Los empleados son especialistas que llevan a cabo las instrucciones asignadas por la dirección. Después de construir el modelo conceptual, se llevó a cabo una descomposición funcional: el sistema se dividió en subsistemas y cada subsistema se describió por separado (diagramas de descomposición).

La figura 2 muestra una descomposición funcional de cuatro trabajos.

Figura 2 - Descomposición funcional "Contabilidad del equipo informático empresarial"

Se identificaron los siguientes tipos de trabajo:

1) Registro de entregas: el proceso en el que se asigna la identificación al producto, se envía al almacenamiento, al almacén y se ingresa información sobre el producto en el programa.

La obra Registro de suministros incluye siete flechas de límite (entrada, control, mecanismo) y una flecha interna hojas (conexión por entrada).

Flecha de comunicación en la entrada entre las obras Registro de entregas y Mantenimiento de la computadora (computadora);

Las flechas de entrada, salida, control se repiten en trabajos posteriores.

2) Mantenimiento de computadoras: el proceso en el que se lleva a cabo el ensamblaje, reparación y modernización de computadoras.

El trabajo de mantenimiento de la computadora incluye cuatro flechas de límite (entrada, control, mecanismo, salida) y varias flechas internas (comunicación de entrada, retroalimentación de entrada).

Control de flechas: reglas, órdenes, líder;

Conexión de flecha en la entrada entre los trabajos de Mantenimiento y Colocación de Computadoras (ingreso de datos en la base de datos), entre los trabajos de Mantenimiento de Computadoras y Reportes (ingreso de datos en la base de datos);

3) Colocación: el proceso en el que se lleva a cabo la colocación de computadoras en oficinas (oficinas).

Control de flechas: reglas, órdenes, líder;

Mecanismo de flecha - empleados;

Enlace de flecha en la entrada entre Difusión e Informes (asignando una identificación);

4) Elaboración de un informe: la etapa final del proceso contable, que consiste en resumir los totales obtenidos al realizar los datos anteriores de la contabilidad actual.

Luego, cada subsistema se divide en descomposiciones más pequeñas, y así sucesivamente, hasta lograr el grado de detalle deseado.

La Figura 3 es un diagrama que muestra el trabajo de Adquisiciones con más detalle.

Como resultado del detallado, se destacaron las funciones principales. La sección "Registro de suministros" incluye siete flechas principales (entrada, salida, control, mecanismo).

Entrada de flecha: computadoras y accesorios;

Las flechas de control son reglas, órdenes y un líder. Bifurcando flechas;

Flechas de mecanismo, ramificación - PC, empleados;

Flechas de entrada, control, mecanismos se repiten en todas las obras.

1) Asignar un número: asignar un número individual a computadoras y accesorios.

Flechas de entrada: computadoras y accesorios. Los ordenadores Arrow se repiten en trabajos posteriores, salvo en la elaboración del informe;

Flechas de control: reglas, órdenes y líder;

Flechas de mecanismo: PC y empleados;

Enlace de flecha en la entrada entre las obras Asignar un número y Enviar mercancía a un almacén (transferencia), entre Asignar un número y Poner en equilibrio (entrar en la base);

2) Envío de mercancías al almacén: envío de las mercancías con el número asignado al almacén.

Flecha de salida - Computadora;

Flechas de control: reglas, órdenes y líder.

Enlace de flecha en la entrada entre las obras "Envío de mercancías al almacén" y "Ajuste en el balance" (cantidad);

3) Equilibrio: ingresar información en una computadora.

Flechas de control: reglas, órdenes y líder;

Flechas de mecanismo: PC y empleados;

La Figura 4 es un diagrama que detalla el mantenimiento de la computadora con más detalle.

Como resultado del detallado, se destacaron las principales funciones que se realizan en el proceso de mantenimiento informático.

El trabajo de mantenimiento de la computadora incluye 4 flechas de límite (entrada, salida, control, mecanismo). Flechas internas (retroalimentación de entrada, comunicación de entrada).

1) Montaje de computadoras - configuración de computadoras para órdenes individuales de gerentes.

Flecha de inicio de sesión - computadoras;

Flechas de control: reglas, órdenes y líder;

Flechas de mecanismo - Empleados;

Enlace de flecha en la entrada entre las obras: "Montaje de ordenadores" y "Reparación de ordenadores" (ordenador);

2) Reparación de computadoras - montaje de computadoras aprobadas para mejora.

Flecha de inicio de sesión - computadoras;

Flecha de salida: entrada a la base;

Flechas de control: reglas, órdenes y líder;

Flechas de mecanismo - Empleados;

Las flechas de entrada, salida, control, mecanismo se ramifican;

Enlace de flecha en la entrada entre las obras: "Reparación de computadoras" y "Actualización" (accesorios);

3) Actualización: mejora, mejora, actualización de la computadora.

Flecha de salida: entrada a la base;

Flechas de control: reglas, órdenes y líder;

Flechas de mecanismo - Empleados;

Las flechas de control, el mecanismo se ramifican;

La figura 5 muestra el gráfico de informes con más detalle. La descomposición del trabajo La presentación de informes incluye 4 flechas de límite (entrada, salida, control, mecanismos). Flechas internas (retroalimentación de entrada, comunicación de entrada).

Como resultado del trabajo, se derivaron las siguientes funciones:

1) Recopilación de datos: recopilación de información para análisis y toma de decisiones.

Ingrese la flecha - identificación de asignación;

Flechas de control: reglas, órdenes y líder;

Las flechas de entrada, control, mecanismo se ramifican;

Enlace de flecha en la entrada entre trabajos: recopilación de datos y validación de datos (registros);

2) Verificación de datos: verificación de la información y envío a la preparación de un informe.

Flecha de inicio de sesión: asigna una identificación, ingresa datos en la base de datos;

Flecha de salida - Informe;

Flechas de control: reglas, órdenes y líder;

Flechas de mecanismo - Empleados, PC;

Las flechas de entrada (asignación de identificación), control, mecanismo se bifurcan;

Ingrese la flecha de retroalimentación de "Verificación de datos" a "Adquisición de datos" (verificación repetida).

Descripción del diagrama DFD

La descomposición del trabajo de mantenimiento de computadoras La Figura 1 define cuatro actividades internas, dos entidades externas y dos almacenes de datos.

Figura 1 - Mantenimiento de la computadora

1) Ensamblaje de computadora: el proceso de ensamblar una computadora a partir de componentes existentes.

2) Elaboración de un informe - proceso que consiste en resumir los indicadores finales obtenidos al realizar el trabajo de la contabilidad actual.

3) Diagnóstico: verificación de rendimiento

4) Actualización: mejora, mejora, actualización de la computadora.

Entidades externas: computadoras y componentes

Almacenes de datos:

1) Almacén: un lugar donde se almacenan las computadoras ensambladas y actualizadas.

2) DB: una base de datos que almacena todos los informes y toda la información sobre el trabajo realizado.

Recopilamos información sobre la computadora y seleccionamos componentes para su ensamblaje. Luego ensamblamos la computadora y la enviamos al almacén para su almacenamiento, pero además de eso, después de ensamblarla, primero podemos enviarla para diagnóstico, verificar su operatividad y luego solo al almacén. Después de diagnosticar la computadora ensamblada, enviamos los datos para compilar un informe sobre el trabajo realizado e ingresar la información en la Base de datos.

También tenemos otra entidad externa, esta es una computadora. Lo enviamos para modernización, luego de lo cual es para diagnóstico para verificar su operatividad, luego elaboramos un informe e ingresamos información sobre el trabajo realizado en la Base de datos. O, después de la modernización, enviamos las mercancías al almacén y luego realizamos diagnósticos, elaboramos un informe e ingresamos la información en la Base de datos.

La descomposición del trabajo "Informes" La Figura 2 define tres actividades internas, tres entidades externas y dos almacenes de datos.

1) Recopilación de datos: recopilación de información sobre computadoras y componentes.

2) Validación: comprobación de la precisión de los datos.

3) Informe: redacción de un informe sobre el trabajo realizado.

Entidades externas: componentes, computadoras, administrador.

Almacén de datos: datos sobre equipos y componentes, datos de informes.

Recopilar información sobre computadoras y accesorios y luego enviarlos para su almacenamiento. Después de eso, verificamos la precisión de los datos, redactamos un informe y lo enviamos para su almacenamiento al primer almacén de datos (Figura 2), o enviamos los datos del informe al segundo almacén de datos (Figura 2) y luego lo enviamos al gerente para verificación.

El gerente verifica, toma notas, corrige y envía para volver a verificar. Después de eso, el informe se envía para su almacenamiento hasta que se vuelva a verificar el administrador.

Descripción del diagrama IDEF3

En la descomposición del trabajo Mantenimiento informático (Fig. 1), se definen varias intersecciones que conectan uno o varios trabajos, varios trabajos internos.

1) Reparación: montaje de la computadora con componentes prefabricados

2) Ensamblaje: devolver la computadora a la normalidad

3) Actualización: actualización de la computadora

4) Computadoras: un producto después del ensamblaje y la modernización

5) Enviar al almacén: enviar al almacén después de la mejora (montaje)

6) Diagnóstico: verificación de funcionamiento.

7) Informe: información sobre el trabajo realizado.

Intersecciones - Conectores:

1) J2: todas las acciones comienzan al mismo tiempo.

2) J6 - Cruce de confluencia. Un nodo que reúne muchas flechas en una, lo que indica la necesidad de la condición de completar las fuentes de trabajo de las flechas para continuar el proceso.

3) J7: se muestra que estas condiciones no se pueden cumplir simultáneamente.

4) J9 - estas acciones finalizan al mismo tiempo, después de lo cual se elabora un informe sobre el trabajo realizado.

El diagrama IDEF3 muestra que la unión J2 tiene dos flechas de ramificación para el trabajo (construcción y actualización) que comienzan al mismo tiempo. Solo después de que se completan estos trabajos, sale el producto terminado (computadora), conecta la intersección J6. Después de eso, hay una conexión en la intersección J7, que muestra que dos trabajos (envío de mercancía al almacén y diagnóstico) no se pueden realizar simultáneamente. Una vez finalizada la obra anterior, se encuentra en marcha el proceso de elaboración de un informe de la obra, que está conectado por el empalme J9.