Функциональная блок-схема

Блок -схема функционального потока ( FFBD ) — это многоуровневая, упорядоченная по времени, пошаговая блок-схема функционального потока системы . ^[2] Термин «функционал» в этом контексте отличается от его использования в функциональном программировании или математике, где сочетание «функционала» и «потока» было бы неоднозначным. Здесь «функциональный поток» относится к последовательности операций, при этом стрелки «потока» выражают зависимость от успеха предыдущих операций. FFBD также могут выражать зависимости входных и выходных данных между функциональными блоками, как показано на рисунках ниже, но FFBD в первую очередь ориентированы на секвенирование.

Обозначение FFBD было разработано в 1950-х годах и широко используется в классической системной инженерии . FFBD — это одна из классических методологий моделирования бизнес-процессов , наряду с блок-схемами , диаграммами потоков данных , диаграммами потоков управления , диаграммами Ганта , диаграммами PERT и IDEF . ^[3]

FFBD также называют функциональными блок-схемами , функциональными блок-схемами и функциональными потоками . ^[4]

История

Первый структурированный метод документирования технологического процесса, блок-схема процесса , был представлен Фрэнком Гилбретом членам Американского общества инженеров-механиков (ASME) в 1921 году в виде презентации «Диаграммы процесса — первые шаги в поиске лучшего пути». ^[5] Инструменты Гилбрета быстро нашли применение в учебных программах по промышленному проектированию .

В начале 1930-х годов промышленный инженер Аллан Х. Могенсен начал обучать деловых людей использованию некоторых инструментов промышленного проектирования на своих конференциях по упрощению труда в Лейк-Плэсиде , Нью-Йорк . Выпускник класса Могенсена в 1944 году, Арт Спинэнгер, отнес инструменты обратно в компанию «Проктер энд Гэмбл» , где разработал программу преднамеренного изменения методов. Другой выпускник 1944 года, Бен С. Грэм , директор по разработке форм в Standard Register Industrial , адаптировал блок-схему процесса для обработки информации, разработав многопоточную схему процесса для отображения нескольких документов и их взаимосвязей. В 1947 году ASME принял набор символов в качестве стандарта ASME для рабочих и технологических схем, заимствованный из оригинальной работы Гилбрета. ^[5]

Современная функциональная блок-схема была разработана компанией TRW Incorporated, оборонной компанией, в 1950-х годах. ^[6] использовало его В 1960-х годах НАСА для визуализации временной последовательности событий в космических системах и полетных миссиях. ^[7] FFBD стали широко использоваться в классической системной инженерии, чтобы показать порядок выполнения системных функций. ^[3]

Разработка функциональных блок-схем

FFBD могут разрабатываться на нескольких уровнях. FFBD отображают те же задачи, которые определены посредством функциональной декомпозиции, и отображают их в их логических, последовательных отношениях. Например, вся полетная миссия космического корабля может быть определена в FFBD верхнего уровня, как показано на рисунке 2. Каждый блок на диаграмме первого уровня затем может быть расширен до ряда функций, как показано на диаграмме второго уровня для «выполнять миссионерские операции». Обратите внимание, что на схеме показаны как вход (переход на рабочую орбиту), так и выход (переход на орбиту космической транспортной системы), тем самым инициируя процесс идентификации и управления интерфейсом. Каждый блок на диаграмме второго уровня можно постепенно превратить в ряд функций, как показано на диаграмме третьего уровня на рисунке 2. ^[8]

Эти диаграммы используются как для разработки требований, так и для определения прибыльных торговых исследований. Например, обнаруживает ли антенна космического корабля спутник слежения и ретрансляции данных (TDRS) только тогда, когда должны быть переданы данные полезной нагрузки, или она постоянно отслеживает TDRS, чтобы обеспечить прием экстренных команд или передачу экстренных данных? FFBD также включает в себя альтернативные и экстренные операции, которые повышают вероятность успеха миссии. Блок-схема обеспечивает понимание всей работы системы, служит основой для разработки операционных и аварийных процедур, а также определяет области, где изменения в операционных процедурах могут упростить общую работу системы. В некоторых случаях альтернативные FFBD могут использоваться для представления различных средств выполнения конкретной функции до тех пор, пока не будут получены данные, что позволяет выбирать среди альтернатив. ^[8]

Строительные блоки

Ключевые атрибуты

Обзор ключевых атрибутов FFBD: ^[1]

Функциональный блок : Каждая функция на FFBD должна быть отдельной и представлена одним прямоугольником (сплошная линия). Каждая функция должна обозначать определенное, конечное, дискретное действие, которое должны выполнить элементы системы.
Нумерация функций : Каждый уровень должен иметь последовательную схему нумерации и предоставлять информацию о происхождении функции. Эти номера устанавливают идентификацию и взаимосвязи, которые будут осуществляться через все действия по функциональному анализу и распределению, а также облегчат отслеживание от нижнего до верхнего уровней.
Функциональная ссылка : каждая диаграмма должна содержать ссылку на другие функциональные диаграммы с использованием ссылки на функциональное название (поле в скобках).
Соединение потока : линии, соединяющие функции, должны обозначать только поток функций, а не промежуток времени или промежуточную деятельность.
Направление потока : диаграммы должны быть расположены так, чтобы направление потока обычно было слева направо. Стрелки часто используются для обозначения функциональных потоков.
Суммирующий вентиль : кружок используется для обозначения суммирующего вентиля и используется, когда присутствует И/ИЛИ. AND используется для обозначения параллельных функций, и для продолжения работы должны быть выполнены все условия. OR используется для указания того, что альтернативные пути могут быть удовлетворены для продолжения.
Путь GO и NO-GO : «G» и «полоса G» используются для обозначения состояний «проход» и «непроход». Эти символы размещаются рядом со строками, оставляющими определенную функцию и указывающими альтернативные пути.

Функциональная символика

Функция должна быть представлена прямоугольником, содержащим название функции (глагол действия, за которым следует именное словосочетание) и ее уникальный десятичный номер, разделенный разделителями. Горизонтальная линия должна отделять этот номер и заголовок, как показано на рисунке 3 выше. На рисунке также показано, как представлять ссылочную функцию, которая обеспечивает контекст внутри конкретного FFBD. На рисунке 9 приведен пример использования опорной функции. ^[9]

Направленные линии

Линия с одной стрелкой должна изображать функциональный поток слева направо, см. рисунок 4. ^[9]

Логические символы

Должны использоваться следующие основные логические символы. ^[9]

И: условие, при котором требуются все предыдущие или последующие пути. Символ может содержать один вход с несколькими выходами или несколько входов с одним выходом, но не несколько входов и выходов вместе взятых (рис. 5). Прочтите рисунок следующим образом: F2 И F3 могут начинаться параллельно после завершения F1. Аналогично, F4 может начаться после завершения F2 И F3.

Исключающее ИЛИ: условие, при котором требуется один из нескольких предыдущих или последующих путей, но не все. Символ может содержать один вход с несколькими выходами или несколько входов с одним выходом, но не несколько входов и выходов вместе взятых (рис. 6). Прочтите рисунок следующим образом: F2 ИЛИ F3 может начаться после завершения F1. Аналогично, F4 может начаться после завершения F2 ИЛИ F3.
Включающее ИЛИ: условие, при котором требуется один, некоторые или все из нескольких предыдущих или последующих путей. На рис. 7 изображена логика «включающее ИЛИ» с использованием комбинации символа «И» (рис. 5) и символа «исключающее ИЛИ» (рис. 6). Прочтите рисунок 7 следующим образом: F2 ИЛИ F3 (исключительно) может начаться после завершения F1, ИЛИ (опять же исключительно) F2 И F3 может начаться после завершения F1. Аналогично, F4 может начаться после завершения F2 ИЛИ F3 (исключительно), ИЛИ (опять исключительно) F4 может начаться после завершения как F2, так и F3.

Контекстные и административные данные

Каждый FFBD должен содержать следующие контекстные и административные данные: ^[9]

Дата создания диаграммы
Имя инженера, организации или рабочей группы, создавшей диаграмму.
Уникальный десятичный номер отображаемой функции, разделенный запятой.
Уникальное имя функции, отображаемой на диаграмме.

На рисунках 8 и 9 представлены данные в FFBD. Рисунок 9 представляет собой декомпозицию функции F2, представленной на рисунке 8, и иллюстрирует контекст между функциями на разных уровнях модели.

См. также

Примечания

^ Jump up to: ^а ^б Основы системной инженерии. Архивировано 28 июля 2011 г. в издательстве Wayback Machine Defense Acquisition University Press, 2001 г.
^ Первая версия этой статьи полностью основана на РУКОВОДСТВЕ ПО РАЗРАБОТКЕ СИСТЕМЫ NAS, РАЗДЕЛ 4.4, ВЕРСИЯ 3.1 от 06.06.06.
^ Jump up to: ^а ^б Томас Дюфрен и Джеймс Мартин (2003). «Моделирование процессов для электронного бизнеса». Архивировано 20 декабря 2006 г. в Wayback Machine . INFS 770 Методы проектирования информационных систем: управление знаниями и электронный бизнес. Весна 2003 г.
^ Jump up to: ^а ^б Инструменты анализа задач, используемые в процессе разработки . FAA 2008. Проверено 25 сентября 2008 г.
^ Jump up to: ^а ^б Бен Б. Грэм (2004). «Детальная диаграмма процесса: разговор на языке процесса». стр.1
^ Тим Вейлкиенс (2008). Системное проектирование с использованием SysML/UML: моделирование, анализ, проектирование . Страница 257.
^ Гарольд Честнат (1967). Методы системной инженерии . Страница 254.
^ Jump up to: ^а ^б ^с НАСА (2007). Справочник НАСА по системному проектированию , декабрь 2007 г., стр. 53.
^ Jump up to: ^а ^б ^с ^д ФАУ (2006). РУКОВОДСТВО ПО ПРОЕКТИРОВАНИЮ СИСТЕМЫ NAS, РАЗДЕЛ 4.4, ВЕРСИЯ 3.1, 06.06.06.

Дальнейшее чтение

ДАУ (2001) Основы системной инженерии. Издательство Университета оборонных закупок.
ФАУ (2007) Руководство по системному проектированию . Федеральное управление гражданской авиации Вашингтона.

[SEF01-1] Jump up to: ^а ^б Основы системной инженерии. Архивировано 28 июля 2011 г. в издательстве Wayback Machine Defense Acquisition University Press, 2001 г.

[2] Первая версия этой статьи полностью основана на РУКОВОДСТВЕ ПО РАЗРАБОТКЕ СИСТЕМЫ NAS, РАЗДЕЛ 4.4, ВЕРСИЯ 3.1 от 06.06.06.

[TD03-3] Jump up to: ^а ^б Томас Дюфрен и Джеймс Мартин (2003). «Моделирование процессов для электронного бизнеса». Архивировано 20 декабря 2006 г. в Wayback Machine . INFS 770 Методы проектирования информационных систем: управление знаниями и электронный бизнес. Весна 2003 г.

[FAA08-4] Jump up to: ^а ^б Инструменты анализа задач, используемые в процессе разработки . FAA 2008. Проверено 25 сентября 2008 г.

[BBG02-5] Jump up to: ^а ^б Бен Б. Грэм (2004). «Детальная диаграмма процесса: разговор на языке процесса». стр.1

[6] Тим Вейлкиенс (2008). Системное проектирование с использованием SysML/UML: моделирование, анализ, проектирование . Страница 257.

[7] Гарольд Честнат (1967). Методы системной инженерии . Страница 254.

[NASA07-8] Jump up to: ^а ^б ^с НАСА (2007). Справочник НАСА по системному проектированию , декабрь 2007 г., стр. 53.

[FAA06-9] Jump up to: ^а ^б ^с ^д ФАУ (2006). РУКОВОДСТВО ПО ПРОЕКТИРОВАНИЮ СИСТЕМЫ NAS, РАЗДЕЛ 4.4, ВЕРСИЯ 3.1, 06.06.06.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

v т и TRW Inc.
Дочерние компании	Лукас Индастриз ЛукасВэрити ТРВ Автомотив TRW Видар
Продукты	Рентгеновская обсерватория Чандра Комптонская гамма-обсерватория Спускающаяся двигательная установка Функциональная блок-схема Программа Обсерватории астрономии высоких энергий Астрономическая обсерватория высоких энергий 1 Астрономическая обсерватория высоких энергий 2 [Обсерватория Эйнштейна] Астрономическая обсерватория высоких энергий 3 Диаграмма N2 Пионер 1 Пионер 10 Пионер 11 ТР-201 Винтовка TRW, не требующая особого ухода
Люди	Саймон Рамо Дин Вулдридж
Похожие статьи	Астролинк Аэрокосмическая корпорация Гудрич Корпорейшн Нортроп Грумман