Hispanopedia Wiki
Articulo de referencia

Diagrama de bloques de flujo funcional

Figura 1: Formato del diagrama de bloques de flujo funcional. [ 1 ] Un diagrama de bloques de flujo funcional ( FFBD ) es un diagrama de flujo multinivel, secuenciado en el tiem...

Hispanopedia WikiContenido en espanolLectura gratuita
Figura 1: Formato del diagrama de bloques de flujo funcional. [ 1 ]

Un diagrama de bloques de flujo funcional ( FFBD ) es un diagrama de flujo multinivel, secuenciado en el tiempo y paso a paso del flujo funcional de un sistema . [ 2 ] El término "funcional" en este contexto es diferente de su uso en programación funcional o en matemáticas, donde emparejar "funcional" con "flujo" sería ambiguo. Aquí, "flujo funcional" se refiere a la secuenciación de operaciones, con flechas de "flujo" que expresan la dependencia del éxito de operaciones previas. Los FFBD también pueden expresar dependencias de datos de entrada y salida entre bloques funcionales, como se muestra en las figuras a continuación, pero se centran principalmente en la secuenciación.

La notación FFBD se desarrolló en la década de 1950 y se utiliza ampliamente en la ingeniería de sistemas clásica . Los FFBD son una de las metodologías clásicas de modelado de procesos de negocio , junto con los diagramas de flujo , los diagramas de flujo de datos , los diagramas de flujo de control , los diagramas de Gantt , los diagramas PERT y el IDEF . [ 3 ]

Los FFBD también se conocen como diagramas de flujo funcional , diagramas de bloques funcionales y flujos funcionales . [ 4 ]

Historia

El primer método estructurado para documentar el flujo de procesos, el diagrama de flujo de procesos , fue presentado por Frank Gilbreth a los miembros de la Sociedad Estadounidense de Ingenieros Mecánicos (ASME) en 1921 en la presentación “Diagramas de procesos: primeros pasos para encontrar la mejor manera”. [ 5 ] Las herramientas de Gilbreth se incorporaron rápidamente a los planes de estudio de ingeniería industrial .

A principios de la década de 1930, el ingeniero industrial Allan H. Mogensen comenzó a capacitar a empresarios en el uso de algunas herramientas de la ingeniería industrial en sus Conferencias de Simplificación del Trabajo en Lake Placid , Nueva York . Art Spinanger, graduado de la clase de Mogensen en 1944, llevó estas herramientas a Procter & Gamble, donde desarrolló su Programa de Cambio de Métodos Deliberados. Otro graduado de 1944, Ben S. Graham , director de Ingeniería de Formcraft en Standard Register Industrial , adaptó el diagrama de flujo de procesos al procesamiento de información con el desarrollo del diagrama de flujo múltiple para mostrar varios documentos y sus relaciones. En 1947, la ASME adoptó un conjunto de símbolos como el Estándar ASME para Diagramas de Procesos de Operación y Flujo, derivado del trabajo original de Gilbreth. [ 5 ]

El moderno Diagrama de Bloques de Flujo Funcional fue desarrollado por TRW Incorporated, una empresa relacionada con la defensa, en la década de 1950. [ 6 ] En la década de 1960, la NASA lo utilizó para visualizar la secuencia temporal de eventos en sistemas espaciales y misiones de vuelo. [ 7 ] Los FFBD se generalizaron en la ingeniería de sistemas clásica para mostrar el orden de ejecución de las funciones del sistema. [ 3 ]

Desarrollo de diagramas de bloques de flujo funcionales

Figura 2: Desarrollo de diagramas de bloques de flujo funcional [ 8 ]

Los FFBD se pueden desarrollar en una serie de niveles. Los FFBD muestran las mismas tareas identificadas mediante la descomposición funcional y las presentan en su relación lógica y secuencial. Por ejemplo, la misión de vuelo completa de una nave espacial se puede definir en un FFBD de nivel superior, como se muestra en la Figura 2. Cada bloque del diagrama de primer nivel se puede expandir a una serie de funciones, como se muestra en el diagrama de segundo nivel para "realizar operaciones de misión". Nótese que el diagrama muestra tanto la entrada (transferencia a órbita operativa) como la salida (transferencia a órbita del sistema de transporte espacial), iniciando así el proceso de identificación y control de la interfaz. Cada bloque del diagrama de segundo nivel se puede desarrollar progresivamente en una serie de funciones, como se muestra en el diagrama de tercer nivel de la Figura 2. [ 8 ]

Estos diagramas se utilizan tanto para desarrollar requisitos como para identificar estudios de viabilidad rentables. Por ejemplo, ¿la antena de la nave espacial adquiere la señal del satélite de seguimiento y retransmisión de datos (TDRS) solo cuando se van a transmitir los datos de la carga útil, o realiza un seguimiento continuo del TDRS para permitir la recepción de comandos de emergencia o la transmisión de datos de emergencia? El diagrama de flujo de funciones (FFBD) también incorpora operaciones alternativas y de contingencia, que mejoran la probabilidad de éxito de la misión. El diagrama de flujo proporciona una comprensión del funcionamiento total del sistema, sirve de base para el desarrollo de procedimientos operativos y de contingencia, e identifica áreas donde los cambios en los procedimientos operativos podrían simplificar el funcionamiento general del sistema. En ciertos casos, se pueden utilizar FFBD alternativos para representar diversos medios para satisfacer una función particular hasta que se adquieran los datos, lo que permite seleccionar entre las alternativas. [ 8 ]

bloques de construcción

Atributos clave

Descripción general de los atributos clave de FFBD: [ 1 ]

Explicación gráfica de un "bloque de función" utilizado en estos diagramas. El flujo va de izquierda a derecha. [ 4 ]
  • Bloque de funciones : Cada función en un FFBD debe estar separada y representada por un solo recuadro (línea continua). Cada función debe representar una acción definida, finita y discreta que deben realizar los elementos del sistema.
  • Numeración de funciones : Cada nivel debe tener un esquema de numeración coherente y proporcionar información sobre el origen de la función. Estos números establecen la identificación y las relaciones que se mantendrán a lo largo de todas las actividades de análisis y asignación funcional, y facilitan la trazabilidad desde los niveles inferiores hasta los superiores.
  • Referencia funcional : Cada diagrama debe contener una referencia a otros diagramas funcionales mediante una referencia de título funcional (recuadro entre corchetes).
  • Conexión de flujo : Las líneas que conectan funciones solo deben indicar el flujo de la función y no un lapso de tiempo o una actividad intermedia.
  • Dirección del flujo : Los diagramas deben diseñarse de manera que la dirección del flujo sea generalmente de izquierda a derecha. A menudo se utilizan flechas para indicar flujos funcionales.
  • Compuerta sumadora : Un círculo se utiliza para indicar una compuerta sumadora y se emplea cuando hay una operación AND/OR. AND se utiliza para indicar funciones paralelas y todas las condiciones deben cumplirse para continuar. OR se utiliza para indicar que se pueden seguir caminos alternativos para continuar.
  • Rutas de "seguir" y "no seguir" : Las letras "G" y "G con barra" se utilizan para indicar las condiciones de "seguir" y "no seguir". Estos símbolos se colocan junto a las líneas que salen de una función específica para señalar rutas alternativas.

Simbolismo funcional

Una función se representará mediante un rectángulo que contenga su título (un verbo de acción seguido de una frase nominal) y su número decimal único. Una línea horizontal separará este número del título, como se muestra en la Figura 3. La figura también ilustra cómo representar una función de referencia, que proporciona contexto dentro de un FFBD específico. Véase la Figura 9 para un ejemplo de uso de una función de referencia. [ 9 ]

Líneas dirigidas

Una línea con una sola punta de flecha representará el flujo funcional de izquierda a derecha, véase la Figura 4. [ 9 ]

Símbolos lógicos

Se utilizarán los siguientes símbolos lógicos básicos. [ 9 ]

  • Y: Una condición que requiere todas las rutas precedentes o posteriores. El símbolo puede contener una sola entrada con múltiples salidas o múltiples entradas con una sola salida, pero no múltiples entradas y salidas combinadas (Figura 5). Lea la figura de la siguiente manera: F2 y F3 pueden comenzar en paralelo después de que se complete F1. Del mismo modo, F4 puede comenzar después de que se completen F2 y F3.
  • OR exclusivo: Condición en la que se requiere una de las múltiples rutas precedentes o sucesoras, pero no todas. El símbolo puede contener una sola entrada con múltiples salidas o múltiples entradas con una sola salida, pero no múltiples entradas y salidas combinadas (Figura 6). La figura se interpreta de la siguiente manera: F2 o F3 pueden comenzar después de completar F1. Del mismo modo, F4 puede comenzar después de completar F2 o F3.
  • OR inclusivo: Una condición en la que se requiere uno, algunos o todos los múltiples caminos precedentes o sucesores. La figura 7 muestra la lógica OR inclusivo utilizando una combinación del símbolo AND (figura 5) y el símbolo OR exclusivo (figura 6). Lea la figura 7 de la siguiente manera: F2 O F3 (exclusivamente) puede comenzar después de completar F1, O (nuevamente exclusivo) F2 Y F3 puede comenzar después de completar F1. Del mismo modo, F4 puede comenzar después de completar F2 O F3 (exclusivamente), O (nuevamente exclusivo) F4 puede comenzar después de completar F2 Y F3.
Figura 7. Lógica "OR inclusivo".

Datos contextuales y administrativos

Cada FFBD deberá contener los siguientes datos contextuales y administrativos: [ 9 ]

  • Fecha en que se creó el diagrama
  • Nombre del ingeniero, organización o grupo de trabajo que creó el diagrama.
  • Número decimal único de la función que se está diagramando.
  • Nombre único de la función que se está diagramando.

Las figuras 8 y 9 presentan los datos en un diagrama de bloques funcionales (FFBD). La figura 9 es una descomposición de la función F2 contenida en la figura 8 e ilustra el contexto entre las funciones en diferentes niveles del modelo.

Véase también

Notas

  1. 1 2 Fundamentos de ingeniería de sistemas. Archivado el 28/07/2011 en Wayback Machine. Defense Acquisition University Press, 2001.
  2. ↑ La primera versión de este artículo se basa completamente en el MANUAL DE INGENIERÍA DEL SISTEMA NAS SECCIÓN 4.4 VERSIÓN 3.1 06/06/06.
  3. 1 2 Thomas Dufresne y James Martin (2003). "Modelado de procesos para el comercio electrónico". Archivado el 20 de diciembre de 2006 en Wayback Machine . INFS 770 Métodos para la ingeniería de sistemas de información: Gestión del conocimiento y comercio electrónico. Primavera de 2003.
  4. 1 2 Herramientas de análisis de tareas utilizadas durante el desarrollo . FAA 2008. Consultado el 25 de septiembre de 2008.
  5. 1 2 Ben B. Graham (2004). "Diagramas de procesos detallados: Hablando el lenguaje del proceso". p.1
  6. ↑ Tim Weilkiens (2008). Ingeniería de sistemas con SysML/UML: modelado, análisis y diseño . Página 257.
  7. ↑ Harold Chestnut (1967). Métodos de ingeniería de sistemas . Página 254.
  8. 1 2 3 NASA (2007). Manual de ingeniería de sistemas de la NASA, diciembre de 2007. pág. 53.
  9. 1 2 3 4 FAA (2006). MANUAL DE INGENIERÍA DEL SISTEMA NAS SECCIÓN 4.4 VERSIÓN 3.1 06/06/06.

Lecturas adicionales

  • DAU (2001) Fundamentos de ingeniería de sistemas. Defense Acquisition University Press.
  • FAA (2007) Manual de Ingeniería de Sistemas . Administración Federal de Aviación, Washington.