Р 50.1.028-2001

Информационные технологии поддержки жизненного
цикла продукции

МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО
МОДЕЛИРОВАНИЯ

ГОССТАНДАРТРОССИИ

Москва

Предисловие

1 РАЗРАБОТАНЫ Научно-исследовательским ЦентромCALS-технологий «Прикладная Логистика» при участии Всероссийскогонаучно-исследовательского института стандартизации (ВНИИстандарт)

ВНЕСЕНЫ Техническим комитетом постандартизации ТК 431 «CALS-технологии»

2 ПРИНЯТЫ И ВВЕДЕНЫ В ДЕЙСТВИЕ ПостановлениемГосстандарта России от 2 июля 2001 г. № 256-ст

3 ВВЕДЕНЫ ВПЕРВЫЕ

Содержание

Введение

Постоянноеусложнение производственно-технических и организационно-экономических систем -фирм, предприятий, производств и других субъектов производственно-хозяйственнойдеятельности - и необходимость их анализа с целью совершенствованияфункционирования и повышения эффективности обусловливают необходимостьприменения специальных средств описания и анализа таких систем. Эта проблемаприобретает особую актуальность в связи с появлением интегрированныхкомпьютеризированных производств и автоматизированных предприятий.

В США в конце 70-х годов была предложена иреализована Программа интегрированной компьютеризации производства ICAM(Integrated Computer Aided Manufacturing), направленная на увеличениеэффективности промышленных предприятий посредством широкого внедрениякомпьютерных (информационных) технологий.

Реализация программы ICAM потребовала созданияадекватных методов анализа и проектирования производственных систем и способовобмена информацией между специалистами, занимающимися такими проблемами. Дляудовлетворения этой потребности в рамках программы ICAM была разработанаметодология моделирования IDEF (ICAM Definition), позволяющая исследоватьструктуру, параметры и характеристики производственно-технических иорганизационно-экономических систем. Общая методология IDEF состоит из трехчастных методологий моделирования, основанных на графическом представлениисистем:

IDEF0 используетсядля создания функциональной модели,отображающей структуру и функции системы, а также потоки информации иматериальных объектов, преобразуемые этими функциями;

IDEF1 применяетсядля построения информационной модели,отображающей структуру и содержание информационных потоков, необходимых дляподдержки функций системы;

IDEF2 позволяетпостроить динамическую модельменяющихся во времени поведения функций, информации и ресурсов системы.

К настоящему времени наибольшее распространение иприменение имеют методологии IDEF0 и IDEF1 (IDEF1X).

Методология IDEF0, особенности и приемы применениякоторой описываются в настоящих рекомендациях, основана на подходе, получившемназвание SADT (Structured Analysis & Design Technique - метод структурногоанализа и проектирования). Основу этого подхода и методологии IDEF0 составляетграфический язык описания (моделирования) систем.

В связи с расширяющимся применением информационных технологийи, в частности, CALS-технологий в народном хозяйстве Российской Федерации внастоящих рекомендациях приводятся основные сведения о методологии IDEF0 играфическом языке описания моделей, а также практические указания по методикеразработки таких моделей.

Р 50.1.028-2001

Информационные технологии поддержки жизненного циклапродукции

МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ

Continuousacquisition and life-cycle support.
Methodology of functional modelling

1 Область применения

Настоящиерекомендации по стандартизации предназначены для использования при анализе исинтезе производственно-технических и организационно-экономических системметодами функционального моделирования в различных отраслях экономики.Рекомендации содержат описание комплекса средств для наглядного представленияширокого спектра деловых, производственных и других процессов и операцийпредприятия на любом уровне детализации, а также организационные и методическиеприемы применения этих средств.

2 Определения

В настоящих рекомендациях применяют следующиетермины:

2.1 блок:Прямоугольник, содержащий имя и номер и используемый для описания функции.

2.2 ветвление:Разделение стрелки на два или большее число сегментов. Может означать«развязывание пучка» (см. 2.27).

2.3 внутренняястрелка: Входная, управляющая или выходная стрелка, концы которойсвязывают источник и потребителя, являющиеся блоками одной диаграммы. Отличаетсяот граничной стрелки.

2.4 входнаястрелка: Класс стрелок, отображающих вход IDEF0-блока, то естьданные или материальные объекты, которые преобразуются функцией в выход.Входные стрелки связываются с левой стороной блока IDEF0.

2.5. выходная стрелка:Класс стрелок, отображающих выход IDEF0-блока, то есть данные или материальныеобъекты, произведенные функцией. Выходные стрелки связываются с правой сторонойблока IDEF0.

2.6 глоссарий:Список определений для ключевых слов, фраз и аббревиатур, связанных с узлами,блоками, стрелками или с моделью IDEF0 в целом.

2.7. граничная стрелка: Стрелка, один из концовкоторой связан с источником или потребителем, а другой не присоединен ни ккакому блоку на диаграмме. Отображает связь диаграммы с другими блоками системыи отличается от внутренней стрелки.

2.8 декомпозиция:Разделение моделируемой функции на функции-компоненты.

2.9 дерево узлов: Представление отношений междуродительскими и дочерними узлами модели IDEF0 в форме древовидного графа. Имеетто же значение и содержание, что и перечень узлов (см. 2.23).

2.10 диаграмма А-0(А минус ноль): Специальный вид (контекстной) диаграммы IDEF0,состоящей из одного блока, описывающего функцию верхнего уровня, ее входы,выходы, управление, и механизмы, вместе с формулировками цели модели и точкизрения, с которой строится модель.

2.11 диаграмма:Часть модели, описывающая декомпозицию блока.

2.12 диаграмма-иллюстрация (FEO): Графическоеописание, используемое для сообщения специфических фактов о диаграмме IDEF0.При построении диаграмм FEO можно не придерживаться правил IDEF0.

2.13 дочернийблок: Блок на дочерней (порожденной) диаграмме.

2.14 дочерняядиаграмма: Диаграмма, детализирующая родительский (порождающий) блок.

2.15 имя блока:Глагол или глагольный оборот, помещенный внутри блока и описывающиймоделируемую функцию.

2.16 интерфейс:Разделяющая граница, через которую проходят данные или материальные объекты;соединение между двумя или большим числом компонентов модели, передающее данныеили материальные объекты от одного компонента к другому.

2.17 код ICOM(аббревиатура Input - вход, Control - управление, Output - выход, Mechanism -механизм): Код, обеспечивающий соответствие граничных стрелок дочернейдиаграммы со стрелками родительского блока; используется для ссылок.

2.18 контекст:Окружающая среда, в которой действует функция (или комплект функций надиаграмме).

2.19 контекстнаядиаграмма: Диаграмма, имеющая узловой номер А-n (А минус n) (n ≥ 0),которая представляет контекст модели. Диаграмма А-0, состоящая из одного блока,является необходимой (обязательной) контекстной диаграммой; диаграммы сузловыми номерами А-1, А-2, (А минус 1, А минус 2)..., - дополнительныеконтекстные диаграммы.

2.20 меткастрелки: Существительное или оборот существительного, связанные сострелкой или сегментом стрелки и определяющие их значение.

2.21 модель IDEF0:Графическое описание системы, разработанное с определенной целью (см. 2.46) и с выбранной точки зрения (см. 2.39). Комплект документов IDEF0, которыеизображают функции системы с помощью графики (диаграмм), текста и глоссария.

2.22 номер блока:Число (0 - 6), помещаемое в правом нижнем углу блока и однозначноидентифицирующее блок на диаграмме.

2.23 перечень узлов: Список, часто ступенчатый,показывающий узлы модели IDEF0 в упорядоченном виде. Имеет то же значение исодержание, что и дерево узлов (см. 2.9).

2.24 примечание кмодели: Текстовый комментарий, являющийся частью диаграммы IDEF0 ииспользуемый для записи факта, не нашедшего графического изображения.

2.25 родительскаядиаграмма: Диаграмма, которая содержит родительский блок.

2.26 родительскийблок: Блок, который подробно описывается дочерней диаграммой.

2.27 связывание/развязывание: Объединениезначений стрелок в составное значение (связывание в «пучок»), или разделениезначений стрелок (развязывание «пучка»), выраженные синтаксисом слияния или ветвлениястрелок.

2.28 сегментстрелки: Сегмент линии, который начинается или заканчивается настороне блока, в точке ветвления или слияния, или на границе (несвязанный конецстрелки).

2.29 семантика:Значение синтаксических компонентов языка.

2.30 синтаксис:Структурные компоненты или характеристики языка и правила, которые определяютотношения между ними.

2.31 слияние:Объединение двух или большего числа сегментов стрелок в один сегмент. Можетозначать «связывание пучка» (см. 2.27).

2.32 С-номер:Номер, создаваемый в хронологическом порядке и используемый для идентификациидиаграммы и прослеживания ее истории; может быть использован в качествессылочного выражения при определении конкретной версии диаграммы. ОбычноС-номер состоит из инициалов автора модели и хронологических данных (датысоздания очередной версии диаграммы).

2.33 стрелка:Направленная линия, состоящая из одного или нескольких сегментов, котораямоделирует открытый канал или канал, передающий данные или материальные объектыот источника (начальная точка стрелки), к потребителю (конечная точка с«наконечником»). Имеется четыре класса стрелок: входная, выходная, управляющаястрелка механизма (включает стрелку вызова). (См. сегмент стрелки, граничнаястрелка, внутренняя стрелка).

2.34 стрелкавызова: Вид стрелки механизма, который обозначает обращение из блокаданной модели (или части модели) к блоку другой модели (или другой части той жемодели) и обеспечивает связь между моделями или между разными частями одноймодели.

2.35 стрелкамеханизма: Класс стрелок, которые отображают механизмы IDEF0, тоесть средства, используемые для выполнения функции; включает специальный случайстрелки вызова. Стрелки механизмов связываются с нижней стороной блока IDEF0.

2.36 стрелка, помещенная в туннель (туннельная стрелка):Стрелка (со специальной нотацией), не удовлетворяющая обычному требованию,согласно которому каждая стрелка на дочерней диаграмме должна соответствоватьстрелкам на родительской диаграмме. Туннельные стрелки - дополнительноесредство графического языка, облегчающее чтение и понимание диаграмм.

2.37 текст:Любой текстовый (не графический) комментарий к графической диаграмме IDEF0.

2.38 тильда:Небольшая ломаная (волнистая) линия, используемая для соединения метки сконкретным сегментом стрелки или примечания модели с компонентом диаграммы.

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

2.40 узел:Блок, порождающий дочерние блоки; родительский блок. (См. перечень узлов,дерево узлов, узловой номер, узловая ссылка, номер узла диаграммы).

2.41 узловаяссылка: Код, присвоенный диаграмме для ее идентификации иопределения положения в иерархии модели; формируется из сокращенного именимодели и узлового номера диаграммы с дополнительными расширениями.

2.42 узловой номердиаграммы: Часть узловой ссылки диаграммы, которая соответствуетномеру родительского блока.

2.43 узловойномер: Код, присвоенный блоку и определяющий его положение виерархии модели; может быть использован в качестве подробного ссылочноговыражения.

2.44 управляющаястрелка: Класс стрелок, которые в IDEF0 отображают управления, тоесть условия, при выполнении которых выход блока будет правильным. Данные илиобъекты, моделируемые как управления, могут преобразовываться функцией,создающей соответствующий выход. Управляющие стрелки связываются с верхнейстороной блока IDEF0.

2.45 функция:Деятельность, процесс или преобразование (моделируемые блоком IDEF0),идентифицируемое глаголом или глагольной формой, которая описывает, что должнобыть выполнено.

2.46 цель: Краткая формулировка причины созданиямодели.

3 Сокращения

Сокращения, принятые в настоящих рекомендациях:

ICAM - интегрированнаякомпьютеризация производства.

ICOM - вход (Input), управление(Control), выход (Output), механизм (Mechanism).

IDEF0 - методология,используемая для создания функциональной модели.

IDEF1 - методология,используемая для создания информационной модели.

IDEF2 - методология,используемая для создания динамической модели.

FEO - диаграмма-иллюстрация.

4 Концепция IDEF0

Методология IDEF0 основана на следующихконцептуальных положениях.

4.1 Модель -искусственный объект, представляющий собой отображение (образ) системы и еекомпонентов. Считается, что

М моделирует А, если Мотвечает на вопросы относительно А.

Здесь М- модель, А - моделируемый объект(оригинал). Модель разрабатывают для понимания, анализа и принятия решений ореконструкции (реинжиниринге) или замене существующей, либо проектированииновой системы. Системапредставляет собой совокупность взаимосвязанных и взаимодействующих частей,выполняющих некоторую полезную работу. Частями (элементами) системы могут бытьлюбые комбинации разнообразных сущностей, включающие людей, информацию,программное обеспечение, оборудование, изделия, сырье или энергию(энергоносители). Модель описывает, что происходит в системе, как ею управляют,что она преобразует, какие средства использует для выполнения своих функций ичто производит.

4.2 Блочное моделирование и егографическое представление. Основной концептуальныйпринцип методологии IDEF - представление любой изучаемой системы в виде наборавзаимодействующих и взаимосвязанных блоков, отображающих процессы, операции,действия (определения - см. ниже), происходящие в изучаемой системе. В IDEF0все, что происходит в системе и ее элементах, принято называть функциями. Каждой функции ставится всоответствие блок. На IDEF0-диаграмме, основном документе прианализе и проектировании систем, блок представляет собой прямоугольник.Интерфейсы, посредством которых блок взаимодействует с другими блоками или свнешней по отношению к моделируемой системе средой, представляются стрелками, входящими в блок или выходящимииз него. Входящие стрелки показывают, какие условия должны быть одновременновыполнены, чтобы функция, описываемая блоком, осуществилась.

4.3 Лаконичность и точность. Документация,описывающая систему, должна быть точной и лаконичной. Сведения о свойствах ихарактеристиках системы в форме традиционных текстов в этом смысленеудовлетворительны, поскольку зачастую содержат избыточную информацию,допускают неоднозначное толкование и т.д. Графический язык позволяет лаконично,однозначно и точно показать все элементы (блоки) системы и все отношения исвязи между ними, выявить ошибочные, лишние или дублирующие связи и т.д.

4.4 Передача информации. Средства IDEF0облегчают передачу информации от одного участника разработки модели (отдельногоразработчика или рабочей группы) к другому. К числу таких средств относятся:

- диаграммы, основанные на простой графике блоков истрелок, легко читаемые и понимаемые;

- метки на естественном языке для описания блоков истрелок, а также глоссарий и сопроводительный текст, уточняющие смысл элементовдиаграммы;

- последовательная декомпозиция диаграмм, строящаясяпо иерархическому принципу, при котором на верхнем уровне отображаются основныефункции, а затем происходит их детализация и уточнение;

- древовидныесхемы иерархии диаграмм и блоков, обеспечивающие обозримость модели в целом ивходящих в нее деталей, что особенно важно при моделировании больших систем.

4.5 Строгость и формализм. Разработкамоделей IDEF0 требует соблюдения ряда строгих формальных правил, обеспечивающихпреимущества методологии в отношении однозначности, точности и целостностисложных многоуровневых моделей. Эти правила описываются ниже. Здесь отмечаетсятолько основное из них: на всех стадиях и этапах разработки и корректировкимодели должны строго, формально соблюдаться синтаксические и семантическиеправила графического языка, а результаты - тщательно документироваться с тем,чтобы при ее эксплуатации не возникало вопросов, связанных с неполнотой илинекорректностью документации. Программный продукт Design/IDEF 3.7 (и болеепоздние версии) фирмы Meta Software Corporation поддерживает автоматическоесоблюдение большинства из перечисленных правил.

4.6 Итеративное моделирование. Разработкамодели в IDEF0 представляет собой пошаговую, итеративную процедуру. На каждомшаге итерации разработчик предлагает вариант модели, который подвергаютобсуждению, рецензированию и последующему редактированию, после чего цикл повторяется.Такая организация работы способствует оптимальному использованию знанийсистемного аналитика, владеющего методологией и техникой IDEF0, и знанийспециалистов - экспертов в предметной области, к которой относится объектмоделирования.

4.7 Отделение«организации» от «функций». При разработке моделейследует избегать изначальной «привязки» функций исследуемой системы ксуществующей организационной структуре моделируемого объекта (предприятия,фирмы). Это помогает избежать субъективной точки зрения, навязаннойорганизацией и ее руководством. Организационная структура должна явитьсярезультатом использования (применения) модели. Сравнение результата ссуществующей структурой позволяет, во-первых, оценить адекватность модели, аво-вторых - предложить решения, направленные на совершенствование этойструктуры.

5 Синтаксис графического языка IDEF0

Набор структурных компонентов языка, иххарактеристики и правила, определяющие связи между компонентами, представляютсобой синтаксис языка. Компоненты синтаксиса IDEF0 - блоки, стрелки, диаграммыи правила. Блоки представляют функции, определяемые как деятельность, процесс,операция, действие или преобразование (см. ниже). Стрелки представляют данныеили материальные объекты, связанные с функциями. Правила определяют, какследует применять компоненты; диаграммы обеспечивают формат графического исловесного описания моделей. Формат образует основу для управленияконфигурацией модели.

5.1Блок

Блок описывает функцию. Типичный блок показан нарисунке 1. Внутри каждого блока помещаются его имя и номер. Имя должно бытьактивным глаголом или глагольным оборотом, описывающим функцию. Номер блокаразмещается в правом нижнем углу. Номера блоков используются для ихидентификации на диаграмме и в соответствующем тексте.

Рисунок 1

5.2Стрелка

Стрелка формируется из одного или несколькихотрезков прямых и наконечника на одном конце. Как показано на рисунке 2,сегменты стрелок могут быть прямыми или ломаными; в последнем случаегоризонтальные и вертикальные отрезки стрелки сопрягаются дугами, имеющими угол90°. Стрелки не представляют поток или последовательность событий, как втрадиционных блок-схемах потоков или процессов (потоковых диаграммах). Они лишьпоказывают, какие данные или материальные объекты должны поступить на входфункции для того, чтобы эта функция могла выполняться.

5.3Синтаксические правила

Рисунок 2

5.3.1 Блоки

Для блоков установлены следующие синтаксическиеправила:

- размеры блоков должны быть достаточными для того,чтобы включить имя и номер блока.

- блоки должны быть прямоугольными, с прямымиуглами;

- блоки должны быть нарисованы сплошными линиями.

5.3.2 Стрелки

Для стрелок установлены следующие синтаксическиеправила:

- ломаные стрелки изменяют направление только подуглом 90°;

- стрелки должны быть нарисованы сплошными линиями.Можно использовать линии различной толщины;

- стрелки могут состоять только из вертикальных илигоризонтальных отрезков; отрезки, направленные по диагонали, не допускаются;

- концы стрелок должны касаться внешней границы функциональногоблока, но не должны пересекать ее;

- стрелки должны присоединяться к блоку на егосторонах. Присоединение в углах не допускается.

6 Семантика языка IDEF0

Семантика определяет содержание (значение)синтаксических компонентов языка и способствует правильности их интерпретации.Интерпретация устанавливает соответствие между блоками и стрелками с однойстороны и функциями и их интерфейсами - с другой.

6.1Семантика блоков и стрелок

Поскольку IDEF0 есть методология функциональногомоделирования, имя блока, описывающее функцию, должно быть глаголом илиглагольным оборотом. Например имя блока «Выполнить проверку» означает, что блокс таким именем превращает непроверенные детали в проверенные. Послеприсваивания блоку имени, к соответствующим его сторонам присоединяютсявходные, выходные и управляющие стрелки, а также стрелки механизма, что иопределяет наглядность и выразительность изображения блока IDEF0 (см. рисунок3).

Рисунок 3

Чтобы гарантировать точность модели, следуетиспользовать стандартную терминологию. Блоки именуются глаголами илиглагольными оборотами, и эти имена сохраняются при декомпозиции. Стрелки и ихсегменты, как отдельные, так и связанные в «пучок», помечаются существительнымиили оборотами существительного. Метки сегментов позволяют конкретизироватьданные или материальные объекты, передаваемые этими сегментами, с соблюдениемсинтаксиса ветвлений и слияний.

Каждая сторона функционального блока имеетстандартное назначение с точки зрения связи блок/стрелки. В свою очередь,сторона блока, к которой присоединена стрелка, однозначно определяет ее роль.Стрелка(и), входящая(ие) в левую сторону блока, - вход(ы). Входы преобразуются или расходуются функцией, чтобысоздать то, что появится на ее выходе. Стрелка(и), входящая(ие) в блок сверху,- управление(я). Управление(я)определяет(ют) условия, необходимые функции, чтобы произвести правильный выход.Стрелка(и), покидающая(ие) блок справа, - выход(ы),то есть данные или материальные объекты, произведенные функцией.

Стрелки, подключенные к нижней стороне блока,представляют механизмы, то естьвсе то, с помощью чего осуществляется преобразование входов в выходы. Стрелки,направленные вверх, идентифицируют средства, поддерживающие выполнение функции.Другие средства могут наследоваться из родительского блока. Стрелки механизма,направленные вниз, являются стрелками вызова. Стрелки вызова обозначаютобращение из данной модели или из данной части модели к блоку, входящему всостав другой модели или другой части модели, обеспечивая их связь, то естьразные модели или разные части одной и той же модели могут совместноиспользовать один и тот же элемент (блок).

Стандартное расположение стрелок показано на рисунке3.

6.2Имена и метки

Как указывалось, имена функций - глаголы илиглагольные обороты.

Примеры такихимен:

Стрелки идентифицируютданные или материальные объекты, необходимые для выполнения функции илипроизводимые ею. Каждая стрелка должна быть помечена существительным илиоборотом существительного, например:

Пример размещения меток стрелок и имени блокапоказан на рисунке 4.

Рисунок 4

6.3Сводка семантических правил для блоков и стрелок

а) Имя блока должно быть глаголом или глагольнымоборотом.

б) Каждая сторона функционального блока имеетстандартное отношение блок/стрелки:

- входные стрелки должны связываться с левойстороной блока;

- управляющие стрелки должны связываться с верхнейстороной блока;

- выходные стрелки должны связываться с правойстороной блока;

- стрелки механизма (кроме стрелок вызова) должныуказывать вверх и подключаться к нижней стороне блока;

- стрелки вызова механизма должны указывать вниз,подключаться к нижней стороне блока, и помечаться ссылкой на вызываемый блок.

в) Сегменты стрелок, за исключением стрелок вызова,должны помечаться существительным или оборотом существительного, если толькоединственная метка стрелки не относится к стрелке в целом.

г) Чтобы связать стрелку с меткой, следуетиспользовать ломаную молниеобразную выносную

д) В метках стрелок не должны использоваться следующие термины: функция, вход,управление, выход, механизм, вызов.

6.4Диаграммы IDEF0

IDEF0-модели состоят из документов трех типов:графических диаграмм, текста и глоссария. Эти документы имеют перекрестныессылки друг на друга. Графическая диаграмма - главный компонент IDEF0-модели,содержащий блоки, стрелки, соединения блоков и стрелок и ассоциированные с нимиотношения. Блоки представляют основные функции моделируемого объекта. Этифункции могут быть разбиты (декомпозированы) на составные части и представленыв виде более подробных диаграмм; процесс декомпозиции продолжается до тех пор,пока объект не будет описан на уровне детализации, необходимом для достиженияцелей конкретного проекта.

Диаграмма верхнего уровня обеспечивает наиболееобщее описание объекта моделирования. За этой диаграммой следует серия дочернихдиаграмм, дающих более детальное представление об объекте.

6.5Контекстная диаграмма верхнего уровня

Каждая модель должна иметь контекстную диаграммуверхнего уровня, на которой объект моделирования представлен единственнымблоком с граничными стрелками. Эта диаграмма называется А-0 (А минус ноль).Стрелки на этой диаграмме отображают связи объекта моделирования с окружающейсредой. Поскольку единственный блок представляет весь объект, его имя - общеедля всего проекта. Это же справедливо и для всех стрелок диаграммы, посколькуони представляют полный комплект внешних интерфейсов объекта. Диаграмма А-0устанавливает область моделирования и ее границу. Пример диаграммы А-0 показанна рисунке 5.

Рисунок 5

Контекстная диаграмма А-0 также должна содержатькраткие утверждения, определяющие точку зрения должностного лица или подразделения,с позиций которого создается модель, и цель, для достижения которой ееразрабатывают. Эти утверждения помогают руководить разработкой модели и ввестиэтот процесс в определенные рамки. Точка зрения определяет, что и в какомразрезе можно увидеть в пределах контекста модели. Изменение точки зренияприводит к рассмотрению других аспектов объекта. Аспекты, важные с одной точкизрения, могут не появиться в модели, разрабатываемой с другой точки зрения натот же самый объект.

Формулировка цели выражает причину создания модели,то есть содержит перечень вопросов, на которые должна отвечать модель, что взначительной мере определяет ее структуру. Наиболее важные свойства объектаобычно выявляются на верхних уровнях иерархии; по мере декомпозиции функции верхнегоуровня и разбиения ее на подфункции, эти свойства уточняются. Каждаяподфункция, в свою очередь, декомпозируется на элементы следующего уровня, итак происходит до тех пор, пока не будет получена релевантная структура,позволяющая ответить на вопросы, сформулированные в цели моделирования. Каждаяподфункция моделируется отдельным блоком. Каждый родительский блок подробноописывается дочерней диаграммой на более низком уровне. Все дочерние диаграммыдолжны быть в пределах области контекстной диаграммы верхнего уровня.

6.6Дочерняя диаграмма

Единственная функция, представленная на контекстнойдиаграмме верхнего уровня, может быть разложена на основные подфункциипосредством создания дочерней диаграммы.В свою очередь, каждая из этих подфункций может быть разложена на составныечасти посредством создания дочерней диаграммы следующего, более низкого уровня,на которой некоторые или все функции также могут быть разложены на составныечасти. Каждая дочерняя диаграмма содержит дочерние блоки и стрелки,обеспечивающие дополнительную детализацию родительского блока.

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

Таким образом, дочерняя диаграмма как бы вложена всвой родительский блок. Эта структура иллюстрируется рисунком 6.

Рисунок 6

6.7Родительская диаграмма

Родительская диаграмма - та, которая содержит одинили более родительских блоков. Иными словами, это диаграмма верхнего уровня, накоторой располагается декомпозируемая функция со всеми ее связями. Каждаяобычная (неконтекстная) диаграмма является также дочерней диаграммой,поскольку, по определению, она подробно описывает некоторый родительский блок.Таким образом, любая диаграмма может быть как родительской диаграммой(содержать родительские блоки), так и дочерней (подробно описывать собственныйродительский блок). Аналогично, блок может быть как родительским (подробноописываться дочерней диаграммой), так и дочерним (появляющимся на дочернейдиаграмме). Основное иерархическое отношение существует между родительскимблоком и дочерней диаграммой, которая его подробно описывает (рисунок 6).

То, что блокявляется дочерним и раскрывает содержание родительского блока на диаграммепредшествующего уровня, указывается специальным ссылочным кодом, написаннымниже правого нижнего угла блока. Этот ссылочный код может формироватьсянесколькими способами, из которых самый простой заключается в том, что код,начинающийся с буквы А (по имени диаграммы А-0), содержит цифры, определяемыеномерами родительских блоков. Например показанные на рисунке 7 коды означают,что диаграмма является декомпозицией 1-го блока диаграммы, которая, в своюочередь, является декомпозицией 6-го блока диаграммы А0, а сами коды образуютсяприсоединением номера блока.

Рисунок 7

Следовательно, код формируется так:

6.8Текст и глоссарий

Диаграмме может быть поставлен в соответствиеструктурированный текст, представляющий собой краткий комментарий к содержаниюдиаграммы.

Текст используется для объяснений и уточненийхарактеристик, потоков, внутриблочньх соединений и т.д. Текст не должениспользоваться для описания и без того понятных блоков и стрелок на диаграммах.При большом объеме текст располагается на отдельном листе модели (текстовойстранице).

Глоссарий предназначен для определения аббревиатур,ключевых слов и фраз, используемых в качестве имен и меток на диаграммах.Глоссарий определяет понятия и термины, которые должны быть одинаково понимаемывсеми участниками разработки и пользователями модели, чтобы правильноинтерпретировать ее содержание. Глоссарий составляется с любой необходимойстепенью подробности.

6.9Диаграммы-иллюстрации (FEO)

Эти диаграммы используются в качестве дополнений,поясняющих специфику содержания основных диаграмм в случаях, когда этонеобходимо. Диаграмма FEO не должна подчиняться синтаксическим правилам IDEF0.

7 Свойства диаграмм

7.1Стрелки как ограничения

Стрелки на диаграмме IDEF0, представляя данные или материальныеобъекты, одновременно задают своего рода ограничения (условия). Входные иуправляющие стрелки блока, соединяющие его с другими блоками или внешнейсредой, описывают условия, которые должны быть выполнены для того, чтобыреализовалась функция, записанная в качестве имени блока.

Рисунок 8иллюстрирует случай, при котором «функция 3» может быть выполнена только послеполучения данных, выработанных «функцией 1» и «функцией 2».

Рисунок 8

7.2Параллельное функционирование

Различные функции в модели могут быть выполненыпараллельно, если удовлетворяются необходимые ограничения (условия). Какпоказано на рисунке 9, один блок может создать данные (а) или материальныеобъекты (б), необходимые для параллельной работы нескольких блоков.

Рисунок 9

7.3Ветвление и слияние сегментов стрелок

Ветвление и слияние стрелок призвано уменьшитьзагруженность диаграмм графическими элементами (линиями).

Чтобы стрелки и их сегменты правильно описывалисвязи между блоками-источниками и блоками-потребителями, используется аппаратметок. Метки связываются с сегментами посредством тильд. При этом междусегментами возникают определенные отношения, описанные ниже:

- непомеченные сегменты (рисунок 10) содержат всеобъекты указанные в метке стрелки перед ветвлением (то есть все объектыпринадлежат каждому из сегментов)

Рисунок 10

- сегменты, помеченные после точки ветвления (рисунок 11), содержат всеобъекты, указанные в метке стрелки перед ветвлением, или их часть, описываемуюметкой каждого конкретного сегмента;

Рисунок 11

- при слиянии непомеченных сегментов объединенный сегмент стрелкисодержит все объекты, принадлежащие сливаемым сегментам и указанные в общейметке стрелки после слияния (рисунок 12);

Рисунок 12

- при слиянии помеченных сегментов (рисунок 13) объединенный сегментсодержит все или некоторые объекты, принадлежащие сливаемым сегментам иперечисленные в общей метке после слияния; если общая метка после слиянияотсутствует, это означает, что общий сегмент передает все объекты,принадлежащие сливаемым сегментам;

Рисунок 13

7.4Отношения блоков на диаграммах

В методологии IDEF0 существует шесть типов отношениймежду блоками в пределах одной диаграммы:

- доминирование;

- управление;

- выход - вход;

- обратная связь по управлению;

- обратная связь по входу;

- выход - механизм.

Первое из перечисленных отношений определяетсявзаимным расположением блоков на диаграмме. Предполагается, что блоки,расположенные на диаграмме выше и левее, «доминируют»над блоками, расположенными ниже и правее. «Доминирование»понимается как влияние, которое один блок оказывает на другие блоки диаграммы.

Остальные пять отношений описывают связи междублоками и изображаются соответствующими стрелками.

Отношения управления и выход - вход являютсяпростейшими, поскольку отражают прямые взаимодействия, которые понятны иочевидны.

Отношениеуправления (рисунок 14) возникает, когда выход одногоблока служит управляющим воздействием на блок с меньшим доминированием.

Рисунок 14

Отношение выход - вход (рисунок 15)возникает при соединении выхода одного блока с входом другого блока с меньшимдоминированием.

Рисунок 15

Обратная связь по управлению иобратная связь по входу являются более сложными типами отношений, посколькуони представляют итерацию (выход функции влияет на будущее выполнение другихфункций с большим доминированием, что впоследствии влияет на исходную функцию).

Обратная связь по управлению (рисунок 16)возникает, когда выход некоторого блока создает управляющее воздействие на блокс большим доминированием.

Рисунок 16

Отношение обратной связи по входу (рисунок 17)имеет место, когда выход блока становится входом другого блока с большимдоминированием.

Рисунок 17

Связи«выход - механизм» (рисунок 18) отражают ситуацию, прикоторой выход одной функции становится средством достижения цели для другой.Связи «выход - механизм» возникают при отображении в модели процедур пополненияи распределения ресурсов, создания или подготовки средств для выполненияфункций системы (например приобретение или изготовление требуемых инструментови оборудования, обучение персонала, организация физического пространства,финансирование, закупка материалов и т.д.; подробнее - см. 11.3).

Рисунок 18

8 Отношения между блоками диаграммы и другимидиаграммами (окружающей средой)

Все описанные выше отношения отображаютсявнутренними стрелками, то есть такими, которых оба конца связаны с блокамидиаграммы. Отношения между блоками диаграммы и другими диаграммами, являющимисяпо отношению к рассматриваемой диаграмме окружающей среде (окружением),описываются граничными стрелками (см. 2.7).Обе ситуации отражены на рисунке 19.

Рисунок 19

8.1Граничные стрелки

На обычной (неконтекстной) диаграмме граничныестрелки представляют входы, управления выходы или механизмы родительского блокадиаграммы. Источник или потребитель граничных стрелок можно обнаружить, толькоизучая родительскую диаграмму. Все граничные стрелки на дочерней диаграмме (заисключением стрелок, помещенных в туннель, см. 2.36) должны соответствовать стрелкам родительскогоблока, как показано на рисунке 20.

Рисунок 20

8.2ICOM-кодирование граничных стрелок

ICOM-коды связывают граничныестрелки на дочерней диаграмме со стрелками родительского блока. Нотация,названная ICOM-кодом, определяет значениясоединений. Буквы I, С, О или М, приведенные около несвязанного концаграничной стрелки на дочерней диаграмме, идентифицируют стрелку как Вход (Input), Управление (Control), Выход (Output) или Механизм (Mechanism)в родительском блоке. Буква следует за числом, определяющим относительноеположение точки подключения стрелки к родительскому блоку; это положениеопределяется слева направо или сверху вниз. Например, код «ЗС» возле граничнойстрелки на дочерней диаграмме указывает, что эта стрелка соответствует третьей(считая слева) управляющей стрелке родительского блока.

Этокодирование связывает каждую дочернюю диаграмму со своим родительским блоком.Если блоки на дочерней диаграмме подвергаются дальнейшей декомпозиции иподробно описываются на дочерних диаграммах следующего уровня, то на каждуюновую диаграмму назначаются новые ICOM-коды, связывающие граничные стрелки этихдиаграмм со стрелками их родительских блоков.

Иногда буквенные ICOM-коды, определяющие ролиграничных стрелок (вход, управление, механизм), могут меняться при переходе отродительского блока к дочерней диаграмме. Например управляющая стрелка вродительском блоке может быть входом на дочерней диаграмме. Аналогично, входродительского блока может быть управлением для одного или нескольких дочернихблоков. Примеры изменения ролей стрелок можно видеть на рисунке 21.

Примечание -Штриховые линии показывают отношения между граничными стрелками и стрелкамиродительского блока.

Рисунок 21

8.3Стрелки, помещенные в «туннель»

Туннель - круглые скобки в начале и/или в концестрелки. Туннельные стрелки означают, что данные, выраженные этими стрелками,не рассматриваются на родительской диаграмме и/или на дочерней диаграмме.

Стрелка, помещенная в туннель там, где онаприсоединяется к блоку (рисунок 22), означает, что данные, выраженные этойстрелкой, не обязательны на следующем уровне декомпозиции.

Рисунок 22

Стрелка, помещаемая в туннель на свободном конце(рисунок 23), означает, что представляемые ею данные отсутствуют народительской диаграмме.

Рисунок 23

Более детально эта ситуация поясняется на рисунке24.

Рисунок 24

9 Правила построения диаграмм

При построении диаграмм необходимо выполнятьследующие правила.

1 В составе модели должна присутствовать контекстнаядиаграмма А-0, которая содержит только один блок. Номер единственного блока наконтекстной диаграмме А-0 должен быть 0.

2 Блоки на диаграмме должны располагаться подиагонали - от левого верхнего до правого нижнего угла диаграммы в порядкеприсвоенных номеров. Блоки на диаграмме, расположенные вверху слева, «доминируют» над блоками, расположеннымивнизу справа. «Доминирование»понимается как влияние, которое блок оказывает на другие блоки диаграммы.Расположение блоков на листе диаграммы отражает авторское пониманиедоминирования. Таким образом, топология диаграммы показывает, какие функцииоказывают большее влияние на остальные. При параллельном функционированииблоков отношение доминирования часто носит формальный характер, и диагональноерасположение блоков лишь способствует читаемости диаграммы.

3 Диаграммы (кроме диаграммы А-0) должны содержатьне менее трех и не более шести блоков. Эти ограничения поддерживают сложностьдиаграмм на уровне, доступном для чтения, понимания и использования.

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

4 Каждый блок неконтекстной диаграммы получаетномер, помещаемый в правом нижнем углу; порядок нумерации - от верхнего левогок нижнему правому блоку (от 1 до 6).

5 Каждый блок, подвергнутый декомпозиции, должениметь ссылку на дочернюю диаграмму; ссылка (например узловой номер, С-номер илиномер страницы) помещается под правым нижним углом блока.

6 Имена блоков (выполняемых функций) и метки стрелокдолжны быть уникальными. Если метки стрелок совпадают, это значит, что стрелкиотображают тождественные данные.

7 При наличии стрелок со сложной топологиейцелесообразно повторить метку для удобства ее идентификации.

8 Следует обеспечить максимальное расстояние междублоками и поворотами стрелок, а также между блоками и пересечениями стрелок дляоблегчения чтения диаграммы. Одновременно уменьшается вероятность того, что дверазные стрелки будут перепутаны.

9 Блоки всегда должны иметь хотя бы одну управляющуюи одну входную стрелку, но могут не иметь выходных стрелок.

10 Если одни и те же данные служат и для управления,и для входа, вычерчивается только стрелка управления. Этим подчеркиваетсяуправляющий характер данных и уменьшается сложность диаграммы.

11 Максимально увеличенное расстояние междупараллельными стрелками облегчает размещения меток, их чтение и позволяетпроследить пути стрелок (рисунок 25).

Рисунок 25

12 Стрелкисвязываются (сливаются), если они представляют сходные данные и их источник неуказан на диаграмме (рисунок 26).

Рисунок26

13 Обратныесвязи по управлению должны быть показаны как «вверх и над» (рисунок 27а).

Рисунок 27

Обратные связи по входу должны быть показаны как«вниз и под» (рисунок 27б). Так же показываются обратные связи посредствоммеханизма (рисунок 27в). Таким образом обеспечивается показ обратной связи приминимальном числе линий и пересечений.

14 Циклические обратные связи для одного и того жеблока изображаются только для того, чтобы их выделить. Обычно обратную связьизображают на диаграмме, декомпозирующей блок. Однако иногда требуется выделитьповторно используемые объекты (рисунок 28).

Рисунок 28

15 Стрелки объединяются, если они имеют общийисточник или приемник, или они представляют связанные данные. Общее названиелучше описывает суть данных. Следует минимизировать число стрелок, касающихсякаждой стороны блока, если, конечно, природа данных не слишком разнородна(рисунок 29).

Рисунок 29

16 Если возможно, стрелки присоединяются к блокам водной и той же позиции. Тогда соединение стрелок конкретного типа с блокамибудет согласованным и чтение диаграммы упростится (рисунок 30).

Рисунок 30

17 Присоединении большого числа блоков необходимо избегать необязательных пересеченийстрелок (рисунок 31). Следует минимизировать число петель и поворотов каждойстрелки (рисунок 32).

Рисунок 31

Рисунок 32

18 Блоки(функции) дочерней диаграммы являются сопряженными через среду (диаграмму илиродительский блок), если они имеют связи с источником, генерирующим данные, безконкретного определения того, как отдельные части данных относятся ккакому-либо блоку (рисунок 33).

Рисунок 33

19 Тип интерфейса, показанный на рисунке 34,предпочтителен, поскольку в этом случае определяются конкретные данные,относящиеся к каждому блоку.

Рисунок 34

20 Необходимо использовать(там, где это целесообразно) выразительные возможности ветвящихся стрелок(рисунок 35).

Рисунок 35

21 Каждая диаграмма IDEF0 изображается настандартном бланке, именуемом мастер-страницей. Бланк снабжен верхним и нижним штампами,содержащими информацию как о конкретной диаграмме, так и в целом о проекте, всостав которого входит диаграмма. Форма бланка с расшифровкой всех полейштампов приведена в приложенииА.

10 Ссылочные выражения (коды)

Ссылочные выражения (коды) присваиваются всемэлементам модели: диаграммам, блокам, стрелкам и примечаниям. Ссылочныевыражения затем могут использоваться в различных контекстах для точногоуказания на нужный элемент модели.

Основное ссылочное выражение - узловой номер,который появляется там, где выполняется декомпозиция функционального блока исоздается его подробное описание на дочерней диаграмме. Все остальные ссылочныекоды базируются на узловых номерах.

10.1Номера блоков

Каждому блоку на диаграмме присваивается номер,помещаемый в нижнем правом внутреннем углу блока. Эта система нумерациинеобходима для однозначной идентификации блоков в пределах диаграммы и для генерацииузловых номеров. Эти номера используются также для ссылок на блоки в тексте иглоссарии.

На контекстной диаграмме А-0 единственному блокуприсваивается номер 0 (нуль). На всех других диаграммах блоки нумеруются от 1до 6, начиная с верхнего левого блока (при их диагональном размещении) и кончаянижним правым блоком. Если некоторые блоки на диаграмме размещены не подиагонали, то сначала нумеруются «диагональные» блоки (также начиная с левоговерхнего блока), а затем - «недиагональные» блоки, начиная с нижнего правогопротив часовой стрелки.

10.2Узловые номера

Узловой номер базируется на положении блока виерархии модели. Обычно узловой номер формируется добавлением номера блока кномеру диаграммы, на которой он появляется. Например узловой номер блока 2 надиаграмме А25-А252. Все узловые номера IDEF0 начинаются с заглавной буквы,например «А». Когда родительский блок подробно описывается дочерней диаграммой,узловые номера родительского блока и дочерней диаграммы совпадают.

Контекстные диаграммы и дочерняя диаграмма верхнегоуровня - исключения в вышеуказанной схеме узловой нумерации. Каждая модельIDEF0 имеет контекстную диаграмму верхнего уровня - диаграмму А-0. Этадиаграмма содержит единственный «высший блок», который является уникальнымродителем всей модели и несет уникальный номер 0 (нуль) и узловой номер А0.Каждая модель IDEF0 должна также иметь по крайней мере одну дочернюю диаграмму,содержащую декомпозицию блока А0 на 3 ... 6 дочерних блоков. Этим блокамприсваиваются уникальные узловые номера А1, А2, A3, ..., А6. Таким образом,последовательность [А0, А1, . . ., А2, . . ., A3, . . .] начинает нумерациюузлов для любой модели.

Например, модель может иметьследующие узловые номера:

Узловой номер используется также для обозначения того, что блок подвергнутдекомпозиции. В этом случае узловой номер, совпадающий с номером дочернейдиаграммы, помещается под правым нижним углом блока на родительской диаграмме (рисунок 36).

10.3Перечень узлов

Перечень узлов представляет информацию о входящих вмодель узлах в форме списка, напоминающего обычное оглавление и отражающегоиерархическую структуру модели, как показано на рисунке 36.

А0 Производить продукт

А1 Планировать производство

А11 Выбрать технологию производства

А12 Оценить требуемое время и затраты на производство

А13 Разработать производственные планы

АН Разработать план вспомогательных действий

А2 Разрабатывать и управлять графиком выпуска и ресурсами

А21 Разработать основной график

А22 Разработать график координации работ

А23 Оценивать затраты и приобретать ресурсы

А24 Следить за выполнением графика и расходом ресурсов

A3 Планироватьвыпуск продукции

Рисунок 36

10.4Дерево узлов

Разработанная модель IDEF0 со всеми уровнями структурнойдекомпозицией может быть представлена на единственной диаграмме в виде дереваузлов, дополняющего перечень узлов. Для изображения этого дерева нетстандартного формата. Единственное требование состоит в том, что вся иерархияузлов модели должна быть представлена наглядно и понятно. Пример дерева узловпоказан на рисунке 37.

Рисунок 37

11 Методика разработки функциональных моделейв среде IDEF0

В предыдущих разделах описаны инструментальныевозможности методологии IDEF0 как средства функционального моделированияпроизводственно-технических и организационно-экономических систем. В настоящемразделе кратко излагаются некоторые методические приемы построения моделей,облегчающие практическое применение этой методологии.

11.1Общие положения

Как ужеотмечалось во введении, объектами функционального моделирования и структурногоанализа по методологии IDEF0 являются организационно-экономические ипроизводственно-технические системы.

Функциональный блок, отображающий моделируемуюсистему в целом (блок А0), и блоки на любом уровне декомпозиции являютсяпреобразующими блоками. Преобразующий блок- блок IDEF0-диаграммы, преобразующий входы в выходы под действием управленийпри помощи «механизмов» (см. разделы2, 4). Преобразование - цель и результат работылюбого блока на диаграмме любого уровня декомпозиции.

Преобразованию в блоке могут подвергатьсяматериальные и информационные объекты, образующие соответствующие потоки.

Материальный поток - непрерывноеили дискретное множество материальных объектов, распределенное во времени.

Информационный поток - множествоинформационных объектов, распределенное во времени.

Информация, участвующая в процессах, операциях,действиях и деятельности в целом, может быть классифицирована на три группы:

- ограничительная;

- описательная;

- предписывающая (управляющая).

Ограничительная информация - сведения отом, что нельзя делать:

а) никогда, ни при каких обстоятельствах (кроме,быть может, форс-мажорных), в любой фазе жизненного цикла и на любом этапефункционирования системы в целом;

б) в рамках функционирования конкретного блока.

Ограничительная информация содержится взаконах, подзаконных актах, международных, государственных и отраслевыхстандартах, а также в специальных внутренних положениях и документахпредприятия, в частности, в технических требованиях, условиях, регламентах ит.д.

Описательная информация - сведения обатрибутах объекта (потока), преобразуемого функциональным блоком. Содержится вчертежах, технических и иных описаниях, реквизитах и других документах, являясьнеотъемлемым компонентом объекта в течение всего жизненного цикла. Этаинформация сама преобразуется (изменяется) в результате выполнения функции.

Предписывающая (управляющая) информация - сведения отом, как, при каких условиях и по какимправилам следует преобразовать объект (поток) на входе в объект(поток) на выходе блока. Содержится в технологических (в широком смысле)инструкциях, руководствах, документах, определяющих «настройки» ихарактеристики блока.

Рисунок 38

Схематическое изображение связей преобразующегоблока в соответствии с соглашениями системы IDEF0 показано на рисунке 38.Ограничительная и предписывающая информация изображается стрелками,присоединяемыми к блоку на стороне управления, а описательная информацияпоступает на вход блока и формируется на его выходе, отображаясь стрелкамивхода и выхода соответственно.

Материальный поток и описывающий его информационныйпоток везде, где это не вызывает недоразумений, можно изображать однойстрелкой.

11.2Классификация функций, моделируемых блоками IDEF0

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

В настоящихрекомендациях предлагается классификация, ориентированная на достаточно широкийкруг организационно-экономических и производственно-технических систем.Классификация делит все функции таких систем на четыре основных и двадополнительных вида. Каждая рубрика в классификации представляет собой класспреобразующих блоков, экземпляры которого возникают и используются примоделировании конкретной системы.

а) Основные виды функций:

1 Деятельность (синонимы: дело, бизнес) - совокупность процессов,выполняемых (протекающих) последовательно или/и параллельно, преобразующих множествоматериальных или/и информационных потоков во множество материальных или/иинформационных потоков с другими свойствами. Деятельностьосуществляется в соответствии с заранее определенной и постоянно корректируемойцелью, с потреблением финансовых, энергетических,трудовых и материальных ресурсов,при выполнении ограничений состороны внешней среды.

В модели IDEF0 деятельность описывается блоком А0 наосновной контекстной диаграмме А-0.

При моделировании крупных, многопрофильных структур(фирм, организаций, предприятий), которые по своему статусу занимаютсяразличными видами деятельности,последние представляют собой различныеэкземпляры класса «деятельность»и могут найти отражение в дополнительной контекстной диаграмме А-1. В этомслучае общая модель сложной структуры будет состоять из ряда частных моделей,каждая из которых относится к конкретному виду деятельности.

2 Процесс (синоним: бизнес-процесс) - совокупностьпоследовательно или/и параллельно выполняемых операций,преобразующая материальный или/и информационный потоки в соответствующие потокис другими свойствами. Процесспротекает в соответствии с управляющими директивами, вырабатываемыми на основе целей деятельности. В ходе процессапотребляются финансовые, энергетические, трудовые и материальные ресурсы и выполняются ограничения со стороны других процессов ивнешней среды.

3 Операция - совокупностьпоследовательно или/и параллельно выполняемых действий,преобразующих объекты, входящие в состав материального или/и информационногопотока, в соответствующие объекты с другими свойствами. Операция выполняется:а) в соответствии с директивами,вырабатываемыми на основе директив, определяющих протекание процесса, в составкоторого входит операция; б) с потреблением всех видов необходимых ресурсов; в) с соблюдением ограничений состороны других операций и внешней среды.

4 Действие -преобразование какого-либо свойства материального или информационного объекта вдругое свойство. Действие выполняется в соответствии с командой, являющейся частью директивы на выполнение операции, спотреблением необходимых ресурсов и с соблюдением ограничений, налагаемых наосуществление операции.

б)Дополнительные виды функций:

5 Субдеятельность - совокупностьнескольких процессов в составе деятельности, объединенная некоторой частнойцелью (являющейся «подцелью» деятельности).

6 Подпроцесс - группаопераций в составе процесса, объединенная технологически или организационно.

Понятия группы а) образуют естественную иерархиюблоков на IDEF0-диаграммах при декомпозиции, предусматривая четыре уровняпоследней. При анализе сложных видов деятельности могут потребоватьсяпромежуточные уровни декомпозиции, основанные на применении функций группы б).

Уровни декомпозиции, детализирующие действия,естественно считать состоящими из элементарныхили простых функций.

В приложении Б приведены IDEF0-диаграммы, показывающиеописанную в классификации иерархию функций в виде абстрактной метамодели. Из неевидно, как эти функции взаимодействуют между собой на разных уровняхдекомпозиции. Метамодель служит шаблоном, применение которого может облегчитьсоздание реальной модели в конкретной предметной области.

11.3Организационно-технические структуры и механизмы IDEF0-моделей

Все функции, входящие в приведенную вышеклассификацию, находятся между собой в отношениях иерархической подчиненностипо принципу «сверху вниз»: деятельность - субдеятельность - процесс -подпроцесс - операция - действие. Согласно методологии IDEF0 каждая функциявыполняется посредством механизма. В большинстве систем, анализируемых припомощи функциональных моделей, такими механизмами служаторганизационно-технические структуры. Одним из концептуальных принциповфункционального моделирования (см. 4.7)является «отделение «организации» от функций». Вместе с тем анализ показываетчто между иерархией функций (преобразований) и иерархией механизмов существуетсоответствие, иллюстрируемое рисунком 39.

Элементы иерархии механизмов определяются следующимобразом.

Рисунок 39

Организационно-техническая система -организационная структура, персонал и комплекс технических средств(оборудование), необходимые для осуществления деятельности.

Организационно-техническаяподсистема - часть организационно-технической системы,обеспечивающая протекание процесса (субдеятельности).

Организационно-технический комплекс(модуль) - часть организационно-технической подсистемы,предназначенная для выполнения операции.

Организационно-технический блок - частьорганизационно-технического комплекса, обеспечивающая выполнение действия.

Таким образом, при корректном построении модели (безаприорной привязки к «организации») появляется возможность связать ее блоки на разныхуровнях декомпозиции с объектами организационно-технической структуры,выступающими в качестве механизмов. В этом случае организационно-техническая структура становится результатомфункционального моделирования.

Во многих моделях находит или должно находитьотражение явление, состоящее в формировании или специфической настройке(перестройке) механизмов в ходе деятельности. Это явление часто именуется реинжинирингом производства и/илибизнес-процессов на предприятии (в организации).

Явление отражается в модели как субдеятельность,поскольку почти всегда состоит из нескольких процессов. Укрупненная схема этойсубдеятельности приведена на рисунке 40.

Э - энергия, П - персонал, О - оборудование, Ф - финансы

Рисунок 40

Согласно схеме входоми одновременно потребляемым ресурсомсубдеятельности являются финансы,преобразуемые в другие виды ресурсов - энергетические, трудовые, материальные(оборудование, вспомогательные материалы и т.д.). (см. приложение Б).

Механизм любого уровня обеспечивает выполнениедеятельности (процесса, операции, действия), потребляя ресурсы: финансовые,энергетические, трудовые, непосредственно или с помощью промежуточныхпреобразований (рисунок 40), то есть специфических процессов, которые можноназвать поддерживающими, обеспечивающими или вспомогательными(по аналогии с вспомогательными производствами, цехами, участками намашиностроительном предприятии) по отношению к основным процессам, где происходят преобразования, однозначнообусловленные целью деятельности.

Существенный признаквспомогательного процесса: этот процесс не создает конечного продуктадеятельности и, следовательно, прибыли.

11.4Управление - особый вид процесса, операции, действия

Один из общихпринципов методологии IDEF0 требует, чтобы к каждому блоку на диаграмме былаприсоединена хотя бы одна управляющая стрелка, отображающая условия правильногофункционирования блока (см. раздел 9). Ниже сформулирован рядопределений и методических положений, которыми следует руководствоваться приотражении управлений на функциональных моделях.

Управление деятельностью - процесс, состоящий как минимум изследующих операций:

- формулирование целей деятельности;

- оценивание ресурсов, необходимых для осуществлениядеятельности и их сопоставление с имеющимися ресурсами;

- сбор информации об условиях протекания ифактическом состоянии деятельности («глобальная» обратная связь);

- выработка и принятие решений, направленных надостижение целей, в частности, решений о распределении ресурсов по процессам,входящим в состав деятельности; оформление решений в виде директив науправление процессами;

- реализация решений (исполнение директив) и оценкаих результатов («локальная обратная связь»);

- корректировка (в случае необходимости, напримерпри нехватке ресурсов) ранее сформулированных целей (самонастройка, адаптация).

Управление процессом - операция, состоящая какминимум из следующих действий:

- анализ директивы на управление процессом, еедекомпозиция на директивы управления операциями;

- сбор (прием по каналам связи) информации о ходевыполнения операций, ее обобщение и формирование сведений о состоянии процесса;передача данных в подсистему управления деятельностью;

-сопоставление информации о ходе операций с данными директив и выработкалокальных решений, направленных на устранение отклонений;

- корректировка (в случае необходимости) директив навыполнение операций.

Управление операцией - действие, состоящее ввыработке на основании директивы на управление операцией команд на управление действиями, вреализации этих команд, оценке результатов выполнения, передаче необходимойинформации в комплекс управления процессом, корректировке команд в случае необходимости.

Блоки управления должны присутствовать на каждойIDEF0-диаграмме (кроме тех, которые являются декомпозициями самих такихблоков). Через них осуществляются управляющие воздействия на остальные блоки диаграммы.Именно эти блоки воспринимают ограничивающую и предписывающую информацию ипреобразуют ее в соответствующие директивы и команды. Имена блоков управления,как правило, содержат глагол «Управлять . . . ».

Стрелки, исходящие из блока с именем «Управлять . .. », описывают централизованную схемууправления (управленческую «вертикаль»). Возможны варианты структур, в которыхвыходная информация одного из блоков является управляющей для другого. Этоотображает децентрализациюуправления («горизонтальные» связи) (см. приложение Б).

11.5Типизация функциональных моделей и IDEF0-диаграмм

Эффективность и производительность трударазработчиков функциональных моделей могут быть повышены за счет применениятиповых моделей и отдельных диаграмм, ориентированных на применение вконкретных предметных областях. Так, например, на основе представлений ожизненном цикле продукции (изделия) можно предложить типовую диаграмму уровняА0 для промышленного предприятия, которая может иметь вид, схематическипоказанный на рисунке 41.

Фрагмент типовой модели промышленного предприятия вформате IDEF0 дан в приложении В.

Аналогичные типовые модели могут быть разработаныдля других видов бизнеса (оказание услуг, транспорт, банковское дело,финансовая деятельность и т.д.).

Рисунок 41

12 Организация процесса функциональногомоделирования и управление проектом

12.1Общие положения

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

Это должен быть процесс, в полной мере использующийвозможности методологии, основанной на разделении функций участников проекта иитеративном характере рецензирования, в ходе которого проверяется корректностьдиаграмм и/или моделей, а также соответствие их поставленной цели и точкезрения.

IDEF0-модель есть результат скоординированнойколлективной работы, при которой авторы создают первоначальные диаграммы,основанные на собранной информации об объекте моделирования, и передают ихдругим участникам проекта для рассмотрения и формулирования замечаний. Порядок,изложенный ниже, требует, чтобы каждый эксперт, у которого есть замечания кдиаграмме, сделал их письменно и передал автору диаграммы. Этот циклпродолжается до тех пор, пока диаграммы, а затем и вся модель не будут приняты.Процесс моделирования иллюстрируется рисунком 42. Диаграмма отражает тот факт,что этот процесс - итеративная процедура, приводящая к точному описаниюсистемы.

Рисунок 42

Ценность модели (проекта) определяется ееприемлемостью для экспертов. Эта приемлемость достигается следующими путями:

1) постоянным рецензированием экспертамиразвивающейся модели, что обеспечивает необходимый уровень соответствия -адекватности - модели существующему моделируемому объекту (если модель отражаетсостояние «как есть») или предполагаемому (состояние «как должно быть») в томпонимании, которое соответствует мнению экспертов;

2) периодическим обсуждением диаграмм, частей моделии модели в целом на техническом совете, решение которого (оформленное в видепротокола) позволяет автору продолжить уточняющее моделирование или закончитьего ввиду достаточности детализации и приемлемости проекта (модели).

Если в процессе моделирования выявляетсянесогласованность оценок экспертов, то она должна быть преодолена, чтобыполучить модель, адекватно представляющую объект моделирования или какую-то егочасть.

Методология IDEF0 предусматривает необходимость сохранениязаписей обо всех решениях и альтернативных подходах по мере того, как онивозникают на протяжении проекта.

Копии диаграмм, разработанные автором, критически(конструктивно) анализируются компетентными экспертами, которые заносят своизамечания и предложения непосредственно на копиях диаграмм. Авторы отвечают накаждое замечание письменно на тех же копиях.

Предложения принимаются или отвергаются письменно суказанием причин. После внесения изменений и исправлений старые вариантыдиаграмм остаются в архиве проекта.

В процессе чтения диаграмм ничто не должнопредполагаться в модели по умолчанию, а также не должны делаться выводы,выходящие за пределы действия и утверждения модели. Это побуждает автора ктщательному комментированию и иллюстрированию каждого добавляемого к моделифрагмента, чтобы при чтении и интерпретации модели ее толкование былооднозначным и соответствующим поставленной цели и установленной точке зрениябез личного присутствия автора и его дополнительных пояснений.

12.2Состав участников проекта и структура их взаимодействия

В коллектив, занимающийся проектированием(моделированием), должны входить следующие участники:

- руководитель проекта;

- авторы (разработчики) модели;

- технический совет;

- эксперты в предметной области;

- библиотекарь.

Дополнительный специфический участник проекта -«Источники информации».

При проведении работ с привлечением стороннихорганизаций может создаваться технический совет, обеспечивающий взаимодействиевсех участников проекта, работающих как в составе проектирующей организации,так и вне ее. Выполняемая функция («роль», которую выполняет участник проекта)не зависит от должности. Один и тот же человек может выполнять несколькофункций. Однако «роль» каждого участника проекта индивидуальна, должна быть определенаи зависит от рассматриваемой части проекта. Структура взаимодействия участниковпроекта приведена на рисунке 43.

Рисунок 43

Принципы коллективной работы в IDEF0-методологиигарантируют, что окончательная версия IDEF0-модели будет верной, так как моделькорректируется по результатам рецензирования частей модели, оформленных в видепапок. Более подробная детализация достигается построением необходимогоколичества диаграмм. По новым частям модели делаются новые замечания, вносятсяновые изменения. Окончательная модель соответствует представлениям автора иэкспертов о системе, смоделированной с данной точки зрения и для данной цели.

Руководитель проекта и разработчики модели (авторы)должны быть главными исполнителями. Хотя конечной целью разработчика являетсяполучение одобрения модели техническим советом, утверждает результатыруководитель проекта. Таким образом, обеспечивается согласованность интересовавторов, рецензентов, совета и руководителя проекта.

12.2.1 Руководительпроекта

Руководительпроекта - лицо, осуществляющее административное управление проектом.Руководитель проекта должен выполнять следующие основные функции:

- выбирать разработчиков модели (авторов). Главнымаспектом данной функции является достижение руководителем проекта и разработчикоммодели согласия относительно основополагающих правил, в соответствии с которымивыполняется моделирование. Сюда входят использование методологии, порядок истепень контроля за разработчиком модели со стороны руководителя проекта,область действия и ориентация разрабатываемой модели;

- определять обязательные источники информации, накоторые разработчик модели будет опираться при построении модели. Этимиисточниками могут быть либо люди, осведомленные о различных аспектахрассматриваемой сферы деятельности, либо документы, освещающие предметнуюобласть моделирования. Эти источники определяются на начальной стадиимоделирования, но список их в процессе моделирования должен пересматриваться иуточняться, поскольку по мере построения модели потребности в информациименяются;

- выбирать экспертов, чьи знания будут использованыразработчиком для получения оценки (одобрения) диаграмм и частей модели. Списокэкспертов составляется на начальной стадии проекта и уточняется о меренеобходимости;

- формировать технический совет. Руководительпроекта по должности является председателем технического совета. Этот совет подего председательством периодически собирается для обсуждения существенныхвопросов, рецензирования и определения статуса модели и ее частей;

- присваиватьстатус рассматриваемой советом части модели.

12.2.2 Разработчики(авторы) модели

Разработчики (авторы) модели - лица, создающиеIDEF0-модели. Разработчик создает модель на основе материала, собранного изисточников информации.

Разработчик должен:

- собирать исходные данные от обязательныхисточников информации, определенных руководителем проекта; при недостаточностисобранных сведений автор вправе использовать любые другие источники информациис обязательным указанием ссылок на них;

- обучать (при необходимости) основамIDEF0-моделирования руководителя проекта, экспертов (рецензентов и читателей) идругих членов технического совета для обеспечения правильного понимания имимоделей, создаваемых авторами;

- оформлять модель в виде IDEF0-диаграмм;

- организовать разработку модели.

В период подготовки проекта разработчик вместе сруководителем проекта изучает и устанавливает область действия модели. Затем оннамечает план проекта, то есть состав и последовательность работ, которые необходимовыполнить для достижения поставленных целей.

Руководитель проекта обеспечивает разработчикасписком источников информации и списком экспертов, к которым разработчик можетобратиться. Разработчик должен удостовериться, что со всеми участниками проектаустановлен необходимый контакт.

Исходную информацию разработчик собирает изисточников, установленных руководителем проекта. Природа этой информации вомногом зависит от стадии разработки модели. Источниками информации могутслужить люди и документы. Разработчик должен понимать, что каждыйэксперт-источник информации смотрит на информацию со своей точки зрения.Разработчик должен стараться увидеть смысл и структуру информации глазами ееисточника. Синтезируя эти точки зрения в процессе сравнения и противопоставления,разработчик создает адекватный образ объекта моделирования.

Второй функцией разработчика является помощь втехнике моделирования всем, кому она может понадобиться. Эта помощь заключаетсяв общем ориентировании членов технического совета, источников информации иэкспертов, ознакомлении их с навыками чтения модели, а также с навыкамимоделирования.

Третьей функцией является оформление модели в видеIDEF0-диаграмм. Для рецензирования разработчик оформляет папки с диаграммамидля передачи их в библиотеку проекта.

Разработчик организует построение модели. Дляподдержки принятых разработчиком решений и регистрации вклада каждого участниказаписи исходной информации, собранной в процессе моделирования, сохраняются втечение определенного времени после завершения проекта. Это позволяетразработчику следить за тем, чтобы исследуемая область была охвачена со всехсторон. Зная, кто и в каких областях поставлял информацию и как этопроисходило, разработчик может оценить степень соответствия стадии моделированияисходным целям.

12.2.3 Техническийсовет

Этот элемент организации процесса создания моделейпредлагает арбитражные решения по моделированию и рекомендации по установлениюстатуса диаграмм, части и/или модели в целом (статусы: «Рабочий проект»,«Эскиз», «Рекомендовано» и «Публикация»).

Технический совет проводит политику проекта черезрекомендации и замечания авторам, предложения по становлению статусаруководителю проекта и подготовку компромиссных решений в конфликтныхситуациях, которые могут возникнуть в процессе проекта. В техническом советедолжно быть несколько специалистов с высоким уровнем компетентности, способныхотстоять свои решения перед высшим руководством объекта моделирования.

Технический совет формируется из экспертов ипрофессионалов, знакомых с предметной областью моделирования. Руководительпроекта формирует этот совет и является его председателем. Поскольку основнойпричиной, побуждающей создавать модель, является необходимость повышенияэффективности объекта моделирования, важно, чтобы в совете были представленывсе службы, имеющие отношение к рассматриваемой в проекте предметной области.Полезно включать в совет экспертов из смежных подразделений объектамоделирования, не входящих в исследуемую область, но связанных с ней. Эти экспертыпомогают адекватно оценить влияние окружающей среды на объект моделирования.

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

12.2.4 Эксперт

Эксперт - выбираемое руководителем проекта лицо,обладающее специальными знаниями некоторых аспектов моделируемой области. Егоопыт в предметной области, к которой относится моделируемый объект, позволяетделать полезные критические замечания в процессе создания модели.

Эксперты призваны критически оценивать создаваемуюпо частям модель. Это осуществляется в ходе нескольких циклов изучения сиспользованием читательских папок (цикл автор/читатель). Папки обеспечиваютэксперта набором информации, предназначенным для описания законченногофрагмента моделируемого объекта. С помощью папок эксперту предоставляетсяинформация в наглядном виде. В процессе рецензирования ему может понадобитьсязаполнить пробелы или даже завершить изложение материала, представленного впапке. Хотя папка во многом основывается на интерпретации разработчиком ранееполученной информации, комментарии экспертов служат ценным материалом дляуточнения модели. В информационных папках перед экспертом должны ставитьсяконкретные, четко сформулированные вопросы, связанные с моделированием.

Главной задачей эксперта является оценкаадекватности модели соответствующей предметной области. Экспертная оценкаявляется основным средством в достижении консенсуса среди изучающих модельэкспертов. Одобренная модель - это модель, согласованная с экспертами. Еслиэксперты согласны с тем, что модель или ее часть адекватно представляетрассматриваемый объект, то модель считается одобренной. Если есть несогласившиеся с этим, то их мнение должно обязательно фиксироваться, и модельсчитается неправильной, пока не доказано обратное. Для достижения консенсусаавторы учитывают комментарии и замечания экспертов при пересмотре той частимодели, к которой эти замечания относятся.

Эксперты подразделяются на две группы:

- эксперты-рецензенты;

- эксперты-читатели.

Эксперт-рецензент - член коллектива разработчиков,знающий предметную область моделирования, специализирующийся на некоторойконкретной функции предприятия и ответственный за обеспечение критическихкомментариев относительно разрабатываемой модели. Эксперт-рецензент должензнать IDEF0-методологию и уметь делать письменные структурированные замечания врассылаемых папках. Он является постоянным и активным участником циклаавтор/читатель.

Эксперт-читатель - член коллектива разработчиков,профессионально знающий предметную область моделирования, понимающийIDEF0-методологию и умеющий читать IDEF0-диаграммы. Эксперт-читатель знакомитсяс документацией (IDEF0-папкой), не делая письменных комментариев. Отэкспертов-читателей авторы получают замечания с помощью опроса.

12.2.5 Библиотекарь

Библиотекарь - лицо, ответственное за хранениедокументации, изготовление копий, координацию обмена письменной и/илиэлектронной информацией (рассылка папок, получение рецензий, регистрация ипубликация диаграмм и модели).

12.2.6 Источникиинформации

Исходная информация для IDEF0-модели поступает кразработчику из разных источников: от людей и от документов. Люди, являющиесяисточниками информации, обладают конкретными знаниями о частных свойствахобъекта моделирования, управлении или ходе бизнес-процесса, и их участие вмоделировании может быть ограничено несколькими минутами опроса. Однако именноэти источники обеспечивают основу для моделирования. Информация,предоставляемая ими, используется для создания модели, а восприятие этойинформации обеспечивает разработчику понимание, необходимое для построенияадекватной модели.

Руководитель проекта подбирает источники информации,исходя из направления проекта и потребностей разработчика. По мере развитияпроцесса моделирования потребности в информации изменяются, и список источниковинформации руководитель проекта пересматривает. Собираемая разработчикоминформация должна как можно точнее фиксироваться.

Каждый источник воспринимает предметную областьпо-своему, и на разработчике лежит ответственность за правильный отборинформации. Особенно это относится к источникам-документам.

Источники-документы отражают состояние объектамоделирования в некоторый момент времени, и их роль крайне важна, но для ихэффективного использования необходима значительная работа, связанная синтерпретацией, пониманием и подтверждением содержащихся в них сведений.

Лица, выступающие в роли источников информации,могут оказывать разработчику модели дополнительную помощь, объясняя, каксообщенная ими информация поступает, интерпретируется или используется.Разработчик должен воспользоваться этой помощью для понимания того, каквосприятие информации одного источника связано с восприятием другого.

12.3Заключительные замечания

1 Функциональная модель - плод коллективного трудавсех участников процесса моделирования.

2 Создание моделей, адекватно отражающих предметнуюобласть, возможно лишь при выполнении обязательных условий:

- IDEF0-диаграммы следует разрабатывать в точномсоответствии с IDEF0-методологией;

- при моделировании должен быть организованитеративный процесс рецензирования каждого фрагмента модели и модели в целом;

- начинать следующий уровень декомпозиции можно лишьпосле полного завершения работы над родительской диаграммой, то есть послеприсвоения ей статуса «Публикация».

ПРИЛОЖЕНИЕ А
(обязательное)

Стандартный бланк методологии IDEF0 и правилаего заполнения

А.1 Мастер-страница (Master Page)

Мастер-страница содержит шаблон (бланк), которыйкопируется на каждую страницу модели (рисунок А.1). Мастер-страница содержиттри области.

1 Область проектной информации - в верхней частистраницы.

2 Рабочая область, в которой располагается диаграммаили другая информация - в центральной части страницы.

3 Область идентификации - вдоль нижнего краястраницы.

Рисунок А.1 -Мастер-страница

А.2Стандартный бланк

Стандартный бланк диаграммы (рисунок А.2)формируется на базе мастер-страницы и обеспечивает единообразное оформление ихранение всех документов, относящихся к модели. Бланк имеет формат А4.

Стандартный бланк содержит следующие информационныеполя.

Рабочее поле

Поле содержит всю информацию, относящуюся кдиаграмме: изображения блоков и стрелок, метки, примечания и т.д. Оно служиттакже для размещения глоссария, текстовых комментариев, замечаний, иллюстраций,эскизов и т.д. Автор не должен использовать никаких других бумаг, кроместандартного бланка.

Рисунок А.2 -Стандартный бланк

Область проектной информации

1 Поле «Используется в:»

Содержит название общей модели, составной частьюкоторой является настоящая модель, или область ее применения.

2 Поле «Автор»

В этом поле указывают имя автора диаграммы илинаименование организации-разработчика проекта.

3 Поле «Проект»

Содержит название проекта или его аббревиатуру.

4 Поле «Замечания»

Используется для указания количества замечаний натекущей странице. Чтобы указать количество замечаний, соответствующее числоперечеркивают крестом (символом «X») или обводят это число эллипсом.

5 Поле «Версия»

Используется для указания информации о версиидиаграммы.

6 Дата и время создания страницы.

7 Дата и время внесения последнего изменения настранице.

8 Текущая дата и время.

9 Поля для установления статуса страницы.

В зависимости от присвоенного статуса (см. ниже) всоответствующем поле ставится символ «X».

10 Наименования устанавливаемых статусов.

Наименования статуса, присваиваемого диаграмме помере ее продвижения по циклам «автор - читатель». Приняты следующие видыстатусов диаграмм в зависимости от уровня их готовности.

«Рабочая версия» - диаграмма с большим числомизменений. Новые диаграммы являются рабочими версиями.

«Проект» - диаграмма имеет меньше изменений посравнению с предыдущим уровнем, что свидетельствует о достижении некоторогосогласия с экспертами. Статус «Проект» присваивается диаграмме по предложениюруководителя работ, до ее рассмотрения экспертами и одобрения техническимсоветом.

«Рекомендовано» - диаграмма и сопутствующие ейтексты прорецензированы и утверждены техническим советом. В нее непредполагается внесение существенных изменений.

«Публикация» - материал, который может бытьпредставлен заказчику модели и рассылаться для окончательной печати иопубликования.

11 Поля для подписей читателей (экспертов)диаграммы.

12 Дата прочтения диаграммы экспертом.

13 Поле «Контекст»

Содержит миниатюрную картинку страницы диаграммы(без стрелок), содержащей родительский блок, который на этой картинке затемнен.Это позволяет иметь перед глазами структуру родительской диаграммы и место наней декомпозируемого блока, не вызывая диаграмму на экран.

Область идентификации

14 Поле «Узел»

В поле помещается номер родительского блока для этойстраницы диаграммы.

15 Поле «Заголовок»

В поле помещается текст имени родительского блока, врезультате декомпозиции которого создана текущая страница.

16 Поле «Номер»

Поле содержит номер данной страницы, на которыйимеется ссылка на родительской диаграмме (под декомпозируемым блоком). Этоможет быть С-номер или номер страницы (см. раздел 6).

ПРИЛОЖЕНИЕ Б
(справочное)

Метамодель

На рисунках Б.1 - Б.5 представлены диаграммыметамодели (см. раздел 11).

Рисунок Б.1 -Контекстная диаграмма

Рисунок Б.2 -Декомпозиция контекстной диаграммы

Рисунок Б.3 - Декомпозиция блока А1

Рисунок Б.4 -Декомпозиция блока А11

Рисунок Б.5 - Декомпозиция блока A3

ПРИЛОЖЕНИЕВ
(справочное)

Функциональная модель предприятия

На рисунках В.1 - В.7 представлены диаграммыфрагмента типовой функциональной модели промышленного предприятия в формате IDEF0.

Рисунок B.1 - Контекстная диаграмма

Рисунок В.2 -Декомпозиция контекстной диаграммы

Рисунок В.3 -Декомпозиция блока А1

Рисунок В.4 -Декомпозиция блока А14

Рисунок В.5 -Декомпозиция блока A3

Рисунок В.6 -Декомпозиция блока А4

Рисунок В.7 -Декомпозиция блока А6