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

Рисунок 1: Формат функциональной блок-схемы.[1]

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

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

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

История

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

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

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

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

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

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

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

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

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

Обзор основных атрибутов FFBD:[1]

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

Функциональный символизм

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

Рисунок 3. Функциональный символ
Рисунок 4. Направленные линии

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

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

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

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

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

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

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

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

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

Рис. 8. Иллюстрация функции 0 FFBD.
Рисунок 9. Иллюстрация функции 2 FFBD

Смотрите также

Примечания

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

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