Un diagrama de bloques de flujo funcional ( FFBD ) es un diagrama de flujo paso a paso de varios niveles, secuenciado en el tiempo, 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 secuencia de operaciones, con flechas de "flujo" que expresan dependencia del éxito de las operaciones anteriores. Los FFBD también pueden expresar dependencias de datos de entrada y salida entre bloques funcionales, como se muestra en las figuras siguientes, pero los FFBD se centran principalmente en la secuenciación.
La notación FFBD se desarrolló en la década de 1950 y se usa ampliamente en la ingeniería de sistemas clásica . FFBDs son uno de los clásicos de modelado de procesos de negocio metodologías, junto con diagramas de flujo , el flujo de datos diagramas , diagramas de flujo de control , diagramas de Gantt , PERT diagramas y IDEF . [3]
FFBDs también se conocen como diagramas funcionales de flujo , diagramas de bloques funcionales , y los flujos funcionales . [4]
Historia
El primer método estructurado para documentar el flujo del proceso, el diagrama de flujo del proceso , fue presentado por Frank Gilbreth a los miembros de la Sociedad Estadounidense de Ingenieros Mecánicos (ASME) en 1921 como la presentación "Gráficos de proceso: primeros pasos para encontrar la mejor manera". [5] Las herramientas de Gilbreth se abrieron camino rápidamente en los planes de estudio de ingeniería industrial .
A principios de la década de 1930, un ingeniero industrial, Allan H. Mogensen, comenzó a capacitar a empresarios en el uso de algunas de las herramientas de la ingeniería industrial en sus Conferencias de Simplificación del Trabajo en Lake Placid , Nueva York . Un graduado de 1944 de la clase de Mogensen, Art Spinanger, llevó las herramientas a Procter and 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 proceso de flujo al procesamiento de información con su desarrollo del diagrama de proceso de flujo múltiple para mostrar múltiples documentos y sus relaciones. En 1947, ASME adoptó un conjunto de símbolos como el estándar ASME para gráficos de proceso 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 aprovechó para visualizar la secuencia temporal de eventos en sistemas espaciales y misiones de vuelo. [7] Los FFBD se utilizaron ampliamente 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
Los FFBD se pueden desarrollar en una serie de niveles. Los FFBD muestran las mismas tareas identificadas mediante la descomposición funcional y las muestran 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 en el diagrama de primer nivel puede luego expandirse a una serie de funciones, como se muestra en el diagrama de segundo nivel para "realizar operaciones misioneras". Tenga en cuenta que el diagrama muestra tanto la entrada (transferencia a la órbita operativa) como la salida (transferencia a la órbita del sistema de transporte espacial), iniciando así el proceso de identificación y control de la interfaz. Cada bloque en el diagrama de segundo nivel se puede desarrollar progresivamente en una serie de funciones, como se muestra en el diagrama de tercer nivel en la Figura 2. [8]
Estos diagramas se utilizan tanto para desarrollar requisitos como para identificar estudios comerciales rentables. Por ejemplo, ¿la antena de la nave espacial adquiere el satélite de seguimiento y retransmisión de datos (TDRS) solo cuando se van a transmitir los datos de carga útil, o sigue el TDRS continuamente para permitir la recepción de comandos de emergencia o la transmisión de datos de emergencia? El 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 de la operación total del sistema, sirve como base para el desarrollo de procedimientos operativos y de contingencia, y señala áreas donde los cambios en los procedimientos operativos podrían simplificar la operación general del sistema. En ciertos casos, se pueden usar FFBD alternativos para representar varios medios de satisfacer una función particular hasta que se adquieran datos, lo que permite la selección entre las alternativas. [8]
Bloques de construcción
Atributos claves
Una descripción general de los atributos clave de FFBD: [1]
- Bloque de función : cada función en un FFBD debe estar separada y representada por un solo cuadro (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 numérico coherente y proporcionar información sobre el origen de la función. Estos números establecen la identificación y las relaciones que llevarán a cabo todas las actividades de Asignación y Análisis Funcional y facilitarán la trazabilidad desde los niveles inferiores a los superiores.
- Referencia funcional : cada diagrama debe contener una referencia a otros diagramas funcionales mediante el uso de una referencia funcional (cuadro entre paréntesis).
- Conexión de flujo : las funciones de conexión de líneas solo deben indicar el flujo de la función y no un lapso de tiempo o actividad intermedia.
- Dirección del flujo : los diagramas deben trazarse de manera que la dirección del flujo sea generalmente de izquierda a derecha. Las flechas se utilizan a menudo para indicar flujos funcionales.
- Puertas sumadoras: Un círculo se usa para denotar una puerta sumadora y se usa cuando Y / O está presente. Y se utiliza para indicar funciones paralelas y todas las condiciones deben cumplirse para continuar. OR se utiliza para indicar que se pueden satisfacer rutas alternativas para continuar.
- Rutas PASA y NO PASA : "G" y "barra G" se utilizan para indicar condiciones de "avance" y "no avance". Estos símbolos se colocan junto a las líneas dejando una función particular para indicar caminos alternativos.
Simbolismo de funciones
Una función estará representada por un rectángulo que contiene el título de la función (un verbo de acción seguido de un sintagma nominal) y su número único delimitado por decimales. Una línea horizontal separará este número y el título, como se muestra en la Figura 3 anterior. La figura también muestra cómo representar una función de referencia, que proporciona contexto dentro de un FFBD específico. Consulte la Figura 9 para ver un ejemplo sobre el 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, ver Figura 4. [9]
Símbolos lógicos
Se utilizarán los siguientes símbolos lógicos básicos. [9]
- Y: una condición en la que se requieren todas las rutas anteriores 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 completar F1. Del mismo modo, F4 puede comenzar después de completar F2 Y F3.
- OR exclusivo: una condición en la que se requiere una de las múltiples rutas anteriores o posteriores, 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). Lea la figura de la siguiente manera: F2 O F3 puede comenzar después de completar F1. Del mismo modo, F4 puede comenzar después de completar F2 O F3.
- O inclusivo: condición en la que se requieren una, algunas o todas las múltiples rutas anteriores o posteriores. La Figura 7 muestra la lógica O inclusiva utilizando una combinación del símbolo Y (Figura 5) y el símbolo O 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
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 único delimitado por decimales de la función que se está diagramando
- Nombre de función único de la función que se está diagramando.
La Figura 8 y la Figura 9 presentan los datos en un FFBD. La figura 9 es una descomposición de la función F2 contenida en la figura 8 e ilustra el contexto entre funciones en diferentes niveles del modelo.
Ver también
- Diagrama de actividad
- Diagrama de bloques
- Mapeo de procesos de negocio
- Flujo de datos
- DRAKON
- Diagrama de flujo
- Diagrama de proceso de flujo
- Modelo de función
- Diagrama de bloques funcional
- IDEF0
- Gráfico N2
- SADT
- Flujo de señal
- Gráfico de flujo de señal
Notas
- ^ a b Fundamentos de ingeniería de sistemas. Archivado el 28 de julio de 2011 en la Wayback Machine Defense Acquisition University Press, 2001
- ^ 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.
- ↑ a b Thomas Dufresne y James Martin (2003). "Modelado de procesos para 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 2003
- ^ a b Herramientas de análisis de tareas utilizadas durante todo el desarrollo . FAA 2008. Consultado el 25 de septiembre de 2008.
- ↑ a b Ben B. Graham (2004). "Detalle de gráficos de proceso: hablar el lenguaje del proceso". p.1
- ^ Tim Weilkiens (2008). Ingeniería de Sistemas con SysML / UML: Modelado, Análisis, Diseño . Página 257.
- ^ Harold Chestnut (1967). Métodos de ingeniería de sistemas . Página 254.
- ^ a b c NASA (2007). Manual de ingeniería de sistemas de la NASA, diciembre de 2007. p.53.
- ↑ a b c d FAA (2006). MANUAL DE INGENIERÍA DEL SISTEMA NAS SECCIÓN 4.4 VERSIÓN 3.1 06/06/06.
Otras lecturas
- DAU (2001) Fundamentos de la ingeniería de sistemas. Prensa Universitaria Adquisición de Defensa.
- FAA (2007) Manual de ingeniería del sistema . Administración Federal de Aviación de Washington.