Титульная страница
ISO 9000 ISO 14000
GMP Consulting
 

РД IDEF 0 - 2000
МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ IDEF0
Руководящий документ
Издание официальное
ГОССТАНДАРТ РОССИИ
М о с к в а
РД IDEF0 - 2000


Предисловие
1. РАЗРАБОТАН Научно-исследовательским Центром CALS – технологий
«Прикладная Логистика»
ВНЕСЕН Научно-исследовательским Центром CALS – технологий «Приклад-
ная Логистика»
2. ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России
от 2000 г. №
3. Настоящий Руководящий документ составлен по материалам Федерального
стандарта США INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEF0) .
Draft Federal Information Processing Standards Publication 183 ,1993 December 21 и содер-
жит основные сведения о методологии функционального моделирования IDEF0 , о
ее графическом языке и методике построения и практического применения функ-
циональных моделей организационно-экономических и производственно-
технических систем.
4 ВВЕДЕН ВПЕРВЫЕ
© ИПК Издательство стандартов, 2000
Настоящий Руководящий документ не может быть полностью или частично вос-
произведен, тиражирован и распространен в качестве официального издания без
разрешения Госстандарта России
РД IDEF0 - 2000
3
Содержание
Стр.
1. ВВЕДЕНИЕ 5
2. КОНЦЕПЦИЯ IDEF0 7
3. ОСНОВНЫЕ ПОНЯТИЯ МЕТОДОЛОГИИ И ЯЗЫКА IDEF0 9
4. СИНТАКСИС ГРАФИЧЕСКОГО ЯЗЫКА IDEF0 13
4.1. Блок 13
4.2. Стрелка 13
4.3. Синтаксические правила 14
5. СЕМАНТИКА ЯЗЫКА IDEF0 15
5.1. Семантика блоков и стрелок 15
5.2. Имена и метки 16
5.3. Семантические правила блоков и стрелок 16
5.4. Диаграмма IDEF0 17
5.5. Контекстная диаграмма верхнего уровня 18
5.6. Дочерняя диаграмма 19
5.7. Родительская диаграмма 19
5.8. Текст и глоссарий 21
5.9. Диаграммы – иллюстрации (FEO) 22
6. СВОЙСТВА ДИАГРАММ 23
6.1. Стрелки как ограничения 23
6.2. Параллельное функционирование 24
6.3. Ветвление и слияние сегментов стрелок 24
6.4. Отношения блоков на диаграммах 26
7. ОТНОШЕНИЯ МЕЖДУ БЛОКАМИ ДИАГРАММЫ И ДРУГИМИ ДИА-
ГРАММАМИ (ОКРУЖАЮЩЕЙ СРЕДОЙ) 30
7.1. Граничные стрелки 30
7.2. ICOM –кодирование граничных стрелок 31
7.3. Стрелки, помещенные в «туннель» 33
8. ПРАВИЛА ПОСТРОЕНИЯ ДИАГРАММ 35
9. ССЫЛОЧНЫЕ НОМЕРА (КОДЫ) 40
9.1. Номера блоков 40
9.2. Узловые номера 40
9.3. Перечень узлов 41
9.4. Дерево узлов 42
10. МЕТОДИКА РАЗРАБОТКИ ФУНКЦИОНАЛЬНЫХ
МОДЕЛЕЙ В СРЕДЕ IDEF0 43
10.1. Общие положения 43
10.2. Классификация функций, моделируемых блоками IDEF0 45
10.3. Организационно-технические структуры и механизмы IDEF0-моделей. 47
10.4. Управление – особый вид процесса, операции, действия 49
10.5. Типизация функциональных моделей и IDEF0 -диаграмм 50
РД IDEF0 - 2000
4
11. ОРГАНИЗАЦИЯ ПРОЦЕССА ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ
И УПРАВЛЕНИЕ ПРОЕКТОМ 52
11.1 Общие положения 52
11.2 Состав участников проекта и структура их взаимодействия 53
11.2.1 Руководитель проекта 55
11.2.2 Разработчики (авторы) проекта 55
11.2.3 Технический совет 57
11.2.4 Эксперт 57
11.2.5 Библиотекарь 58
11.2.6 Источники информации 59
11.3 Заключительные замечания 59
12. ПЕРСПЕКТИВЫ РАЗВИТИЯ МЕТОДОЛОГИИ
ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ
60
ЛИТЕРАТУРА
ПРИЛОЖЕНИЕ 1
ПРИЛОЖЕНИЕ 2
62
РД IDEF0 - 2000
5
1. Введение
Постоянное усложнение производственно-технических и организационно-
экономических систем – фирм, предприятий, производств, и др. субъектов
производственно-хозяйственной деятельности - и необходимость их анализа
с целью совершенствования функционирования и повышения эффективности
обусловливают необходимость применения специальных средств описания и
анализа таких систем. Эта проблема приобретает особую актуальность в свя-
зи с появлением интегрированных компьютеризированных производств и
автоматизированных предприятий.
В США это обстоятельство было осознано еще в конце 70-ых годов, когда
ВВС США предложили и реализовали Программу интегрированной компью-
теризации производства ICAM (ICAM - Integrated Computer Aided Manufacturing),
направленную на увеличение эффективности промышленных пред-
приятий посредством широкого внедрения компьютерных (информацион-
ных) технологий.
Реализация программы ICAM потребовала создания адекватных методов
анализа и проектирования производственных систем и способов обмена ин-
формацией между специалистами, занимающимися такими проблемами. Для
удовлетворения этой потребности в рамках программы ICAM была разрабо-
тана методология IDEF (ICAM Definition), позволяющая исследовать струк-
туру, параметры и характеристики производственно-технических и организа-
ционно-экономических систем (в дальнейшем, там, где это не вызывает не-
доразумений – систем). Общая методология IDEF состоит из трех частных
методологий моделирования, основанных на графическом представлении
систем:
• IDEF0 используется для создания функциональной модели, отображаю-
щей структуру и функции системы, а также потоки информации и матери-
альных объектов, связывающие эти функции.
• IDEF1 применяется для построения информационной модели, отобра-
жающей структуру и содержание информационных потоков, необходи-
мых для поддержки функций системы;
• IDEF2 позволяет построить динамическую модель меняющихся во вре-
мени поведения функций, информации и ресурсов системы.
К настоящему времени наибольшее распространение и применение имеют
методологии IDEF0 и IDEF1 (IDEF1X), получившие в США статус феде-
ральных стандартов. [1 ,2 ].
Методология IDEF0, особенности и приемы применения которой описы-
ваются в настоящем Руководящем документе (РД), основана на подходе,
РД IDEF0 - 2000
6
разработанном Дугласом Т. Россом в начале 70–ых годов и получившем на-
звание SADT (Structured Analysis & Design Technique - метод структурного
анализа и проектирования). Основу подхода и, как следствие, методологии
IDEF0, составляет графический язык описания (моделирования) систем, об-
ладающий следующими свойствами.
• Графический язык - полное и выразительное средство, способное нагляд-
но представлять широкий спектр деловых, производственных и других
процессов и операций предприятия на любом уровне детализации.
• Язык обеспечивает точное и лаконичное описание моделируемых объек-
тов, удобство использования и интерпретации этого описания.
• Язык облегчает взаимодействие и взаимопонимание системных аналити-
ков, разработчиков и персонала изучаемого объекта (фирмы, предпри-
ятия), т.е. служит средством «информационного общения» большого чис-
ла специалистов и рабочих групп, занятых в одном проекте, в процессе
обсуждения, рецензирования, критики и утверждения результатов.
• Язык прошел многолетнюю проверку и продемонстрировал работоспо-
собность как в проектах ВВС США, так и в других проектах, выполняв-
шихся государственными и частными промышленными компаниями.
• Язык легок и прост в изучении и освоении.
• Язык может генерироваться рядом инструментальных средств машинной
графики; известны коммерческие программные продукты, поддерживаю-
щие разработку и анализ моделей - диаграмм IDEF0, например, продукт
Design/IDEF 3.7 (и более поздние версии) фирмы Meta Software Corporation
(США).
Перечисленные свойства языка предопределили выбор методологии IDEF0
в качестве базового средства анализа и синтеза производственно-технических
и организационно-экономических систем, что нашло свое отражение в упо-
мянутых федеральных стандартах США.
В связи с расширяющимся применением информационных технологий и,
в частности, CALS-технологий в народном хозяйстве Российской Федерации
в настоящем РД приводятся основные сведения о методологии IDEF0 и гра-
фическом языке описания моделей , а также некоторые практические реко-
мендации по разработке таких моделей.
РД IDEF0 - 2000
7
2. Концепция IDEF0
Методология IDEF0 основана на следующих концептуальных положениях.
2.1 Модель – искусственный объект, представляющий собой отображение
(образ) системы и ее компонентов. Согласно [ 3 ],
М моделирует А, если М отвечает на вопросы относительно А.
Здесь М – модель, А – моделируемый объект (оригинал). Модель разра-
батывают для понимания, анализа и принятия решений о реконструкции
(реинжиниринге) или замене существующей, либо проектировании но-
вой системы. Система представляет собой совокупность взаимосвязан-
ных и взаимодействующих частей, выполняющих некоторую полезную
работу. Частями (элементами) системы могут быть любые комбинации
разнообразных сущностей, включающие людей, информацию, программ-
ное обеспечение, оборудование, изделия, сырье или энергию (энергоно-
сители). Модель описывает, что происходит в системе, как ею управля-
ют, какие сущности она преобразует, какие средства использует для вы-
полнения своих функций и что производит.
2.2 Блочное моделирование и его графическое представление. Основной
концептуальный принцип методологии IDEF – представление любой изу-
чаемой системы в виде набора взаимодействующих и взаимосвязанных
блоков, отображающих процессы, операции, действия (определения – см.
ниже), происходящие в изучаемой системе. В IDEF0 все, что происходит в
системе и ее элементах, принято называть функциями. Каждой функции
ставится в соответствие блок. На IDEF0 –диаграмме, основном докумен-
те при анализе и проектировании систем, блок представляет собой прямо-
угольник. Интерфейсы, посредством которых блок взаимодействует с дру-
гими блоками или с внешней по отношению к моделируемой системе сре-
дой, представляются стрелками ), входящими в блок или выходящими из
него. Входящие стрелки показывают, какие условия должны быть одно-
временно выполнены, чтобы функция, описываемая блоком, осуществи-
лась.
2.3 Лаконичность и точность. Документация, описывающая систему,
должна быть точной и лаконичной. Многословные характеристики, изло-
женные в форме традиционных текстов, неудовлетворительны. Графиче-
ский язык позволяет лаконично, однозначно и точно показать все элемен-
ты (блоки) системы и все отношения и связи между ними, выявить оши-
бочные, лишние или дублирующие связи и т.д..
2.4 Передача информации. Средства IDEF0 облегчают передачу информа-
ции от одного участника разработки модели (отдельного разработчика или
рабочей группы) к другому. К числу таких средств относятся:
• диаграммы, основанные на простой графике блоков и стрелок, легко
читаемые и понимаемые;
РД IDEF0 - 2000
8
• метки на естественном языке для описания блоков и стрелок, а также
глоссарий и сопроводительный текст для уточнения смысла элемен-
тов диаграммы;
• последовательная декомпозиция диаграмм, строящаяся по иерархи-
ческому принципу, при котором на верхнем уровне отображаются
основные функции, а затем происходит их детализация и уточнение;
• древовидные схемы иерархии диаграмм и блоков , обеспечивающие
обозримость модели в целом и входящих в нее деталей.
2.5 Строгость и формализм. Разработка моделей IDEF0 требует соблюде-
ния ряда строгих формальных правил, обеспечивающих преимущества
методологии в отношении однозначности, точности и целостности слож-
ных многоуровневых моделей. Эти правила описываются ниже. Здесь от-
мечается только основное из них: все стадии и этапы разработки и коррек-
тировки модели должны строго, формально документироваться с тем,
чтобы при ее эксплуатации не возникало вопросов , связанных с непол-
нотой или некорректностью документации.
2.6 Итеративное моделирование. Разработка модели в IDEF0 представляет
собой пошаговую, итеративную процедуру. На каждом шаге итерации
разработчик предлагает вариант модели, который подвергают обсужде-
нию, рецензированию и последующему редактированию, после чего цикл
повторяется. Такая организация работы способствует оптимальному ис-
пользованию знаний системного аналитика, владеющего методологией и
техникой IDEF0, и знаний специалистов – экспертов в предметной облас-
ти, к которой относится объект моделирования.
2.7 Отделение «организации» от «функций». При разработке моделей
следует избегать изначальной «привязки» функций исследуемой системы
к существующей организационной структуре моделируемого объекта
(предприятия, фирмы). . Это помогает избежать субъективной точки зре-
ния, навязанной организацией и ее руководством. Организационная
структура должна явиться результатом использования (применения) мо-
дели. Сравнение результата с существующей структурой позволяет, во-
первых, оценить адекватность модели, а во-вторых – предложить реше-
ния, направленные на совершенствование этой структуры.
РД IDEF0 - 2000
9
3. Основные определения (понятия) методологии и языка IDEF0.
3.1 Блок: прямоугольник, содержащий имя и номер и используемый для опи-
сания функции.
3.2 Ветвление: разделение стрелки на два или большее число сегментов.
Может означать «развязывание пучка» (см. 3.27).
3.3 Внутренняя стрелка: входная, управляющая или выходная стрелка, кон-
цы которой связывают источник и потребителя, являющиеся блоками од-
ной диаграммы. Отличается от граничной стрелки.
3.4 Входная стрелка: класс стрелок, которые отображают вход IDEF0-блока,
то есть данные или материальные объекты, которые преобразуются функ-
цией в выход. Входные стрелки связываются с левой стороной блока
IDEF0.
3.5 Выходная стрелка: класс стрелок, которые отображают выход IDEF0-
блока, то есть данные или материальные объекты, произведенные функ-
цией. Выходные стрелки связываются с правой стороной блока IDEF0.
3.6 Глоссарий: список определений для ключевых слов, фраз и аббревиатур,
связанных с узлами, блоками, стрелками или с моделью IDEF0 в целом.
3.7 Граничная стрелка: стрелка, один из концов которой связан с источни-
ком или потребителем, а другой не присоединен ни к какому блоку на
диаграмме. Отображает связь диаграммы с другими блоками системы и
отличается от внутренней стрелки.
3.8 Декомпозиция: разделение моделируемой функции на функции - компо-
ненты.
3.9 Дерево узлов: представление отношений между родительскими и дочер-
ними узлами модели IDEF0 в форме древовидного графа. Имеет то же
значение и содержание, что и перечень узлов (см. 3.23).
3.10 Диаграмма A-0: специальный вид (контекстной) диаграммы IDEF0,
состоящей из одного блока, описывающего функцию верхнего уровня, ее
входы, выходы, управления, и механизмы, вместе с формулировками цели
модели и точки зрения, с которой строится модель.
3.11 Диаграмма: часть модели, описывающая декомпозицию блока.
3.12 Диаграмма-иллюстрация (FEO): графическое описание, используе-
мое, для сообщения специфических фактов о диаграмме IDEF0. При по-
строении диаграмм FEO можно не придерживаться правила IDEF0.
3.13 Дочерний блок: блок на дочерней (порожденной) диаграмме.
3.14 Дочерняя диаграмма: диаграмма, детализирующая родительский (по-
рождающий) блок.
3.15 Имя блока: глагол или глагольный оборот, помещенный внутри блока
и описывающий моделируемую функцию.
3.16 Интерфейс: разделяющая граница, через которую проходят данные
или материальные объекты; соединение между двумя или большим чис-
РД IDEF0 - 2000
10
лом компонентов модели, передающее данные или материальные объекты
от одного компонента к другому.
3.17 Код ICOM: аббревиатура( Input - Вход, Control - Управление, Output -
Выход, Mechanism – Механизм), код, обеспечивающий соответствие гра-
ничных стрелок дочерней диаграммы со стрелками родительского блока;
используется для ссылок.
3.18 Контекст: окружающая среда, в которой действует функция (или
комплект функций на диаграмме).
3.19 Контекстная диаграмма: диаграмма, имеющая узловой номер A-n
( n ? 0 ), которая представляет контекст модели, Диаграмма A-0, состоя-
щая из одного блока, является необходимой (обязательной) контекстной
диаграммой; диаграммы с узловыми номерами A-1, A-2,... - дополнитель-
ные контекстные диаграммы.
3.20 Метка стрелки: существительное или оборот существительного, свя-
занные со стрелкой или сегментом стрелки и определяющие их значение.
3.21 Модель IDEF0: графическое описание системы, разработанное с опре-
деленной целью (см. 3.46 ) и с выбранной точки зрения (см. 3.39 ). Ком-
плект одной или более диаграмм IDEF0, которые изображают функции
системы с помощью графики, текста и глоссария.
3.22 Номер блока: число (0 - 6), помещаемое в правом нижнем углу блока и
однозначно идентифицирующее блок на диаграмме.
3.23 Перечень узлов: список, часто ступенчатый, показывающий узлы мо-
дели IDEF0 в упорядоченном виде. Имеет то же значение и содержание,
что и дерево узлов (см. 3.9 ).
3.24 Примечание к модели: текстовый комментарий, являющийся частью
диаграммы IDEF0 и используемый для записи факта, не нашедшего гра-
фического изображения.
3.25 Родительская диаграмма: диаграмма, которая содержит родительский
блок.
3.26 Родительский блок: блок, который подробно описывается дочерней
диаграммой.
3.27 Связывание/развязывание: объединение значений стрелок в составное
значение (связывание в «пучок»), или разделение значений стрелок (раз-
вязывание «пучка»), выраженные синтаксисом слияния или ветвления
стрелок.
3.28 Сегмент стрелки: сегмент линии, который начинается или заканчи-
вается на стороне блока, в точке ветвления или слияния, или на границе
(несвязанный конец стрелки).
3.29 Семантика: значение синтаксических компонентов языка.
3.30 Синтаксис: Структурные компоненты или характеристики языка и
правила, которые определяют отношения между ними.
3.31 Слияние: объединение двух или большего числа сегментов стрелок в
один сегмент. Может означать «развязывание пучка» (см. 3.27 )
РД IDEF0 - 2000
11
3.32 С-номер: номер, создаваемый в хронологическом порядке и исполь-
зуемый для идентификации диаграммы и прослеживания ее истории; мо-
жет быть использован в качестве ссылочного выражения при определении
конкретной версии диаграммы.
3.33 Стрелка: направленная линия, состоящая из одного или нескольких
сегментов, которая моделирует открытый канал или канал, передающий
данные или материальные объекты от источника (начальная точка стрел-
ки), к потребителю (конечная точка с «наконечником»). Имеется 4 класса
стрелок: входная стрелка, выходная стрелка, управляющая стрелка,
стрелка механизма (включает стрелку вызова). (См.: сегмент стрелки,
граничная стрелка, внутренняя стрелка).
3.34 Стрелка вызова: вид стрелки механизма, который обозначает обраще-
ние из блока данной модели (или части модели) к блоку другой модели
( или другой части той же модели) и обеспечивает связь между моделями
или между разными частями одной модели.
3.35 Стрелка механизма: класс стрелок, которые отображают механизмы
IDEF0, то есть средства, используемые для выполнения функции; включа-
ет специальный случай стрелки вызова. Стрелки механизмов связываются
с нижней стороной блока IDEF0.
3.36 Стрелка, помещенная в туннель (туннельная стрелка): стрелка (со
специальной нотацией), не удовлетворяющая обычному требованию, со-
гласно которому каждая стрелка на дочерней диаграмме должна соответ-
ствовать стрелкам на родительской диаграмме.
3.37 Текст: любой текстовый (не графический) комментарий к графической
диаграмме IDEF0.
3.38 Тильда: небольшая ломаная (волнистая) линия, используемая для со-
единения метки с конкретным сегментом стрелки или примечания модели
с компонентом диаграммы.
3.39 Точка зрения: указание на должностное лицо или подразделение орга-
низации, с позиции которого разрабатывается модель
3.40 Узел: блок, порождающий дочерние блоки; родительский блок.( См.:
перечень узлов, дерево узлов, узловой номер, узловая ссылка, номер узла
диаграммы).
3.41 Узловая ссылка: код, присвоенный диаграмме, для ее идентификации
и определения положения в иерархии модели; формируется из сокращен-
ного имени модели и узлового номера диаграммы с дополнительными
расширениями.
3.42 Узловой номер диаграммы: часть узловой ссылки диаграммы , которая
соответствует номеру родительского блока.
3.43 Узловой номер: код, присвоенный блоку и определяющий его поло-
жение в иерархии модели; может быть использован в качестве подробного
ссылочного выражения.
3.44 Управляющая стрелка: класс стрелок, которые в IDEF0 отображают
РД IDEF0 - 2000
12
управления, то есть условия, при выполнении которых выход блока будет
правильным. Данные или объекты , моделируемые как управления, могут
преобразовываться функцией, создающей соответствующий выход.
Управляющие стрелки связываются с верхней стороной блока IDEF0.
3.45 Функция: деятельность, процесс или преобразование (моделируемые
блоком IDEF0), идентифицируемое глаголом или глагольной формой, ко-
торая описывает, что должно быть выполнено.
3.46 Цель: краткая формулировка причины создания модели.
РД IDEF0 - 2000
4. Синтаксис графического языка IDEF0.
Набор структурных компонентов языка, их характеристики и правила, опре-
деляющие связи между компонентами, представляют собой синтаксис языка.
Компоненты синтаксиса IDEF0 – блоки, стрелки, диаграммы и правила..
Блоки представляют функции, определяемые как деятельность, процесс, опе-
рация, действие или преобразование (см. ниже). Стрелки представляют дан-
ные или материальные объекты, связанные с функциями. Правила опреде-
ляют, как следует применять компоненты; диаграммы обеспечивают формат
графического и словесного описания моделей. Формат образует основу для
управления конфигурацией модели.
4.1 Блок.
Блок описывает функцию. Типичный блок показан на рис. 1. Внутри
каждого блока помещается его имя и номер. Имя должно быть активным
глаголом или глагольным оборотом, описывающим функцию. Номер блока
размещается в правом нижнем углу. Номера блоков используются для их
идентификации на диаграмме и в соответствующем тексте.
4.2. Стрелка.
Стрелка формируется из одного или более отрезков прямых и наконеч-
ника на одном конце. Как показано на рис. 2, сегменты стрелок могут быть
прямыми или ломаными; в последнем случае горизонтальные и вертикаль-
ные отрезки стрелки сопрягаются дугами, имеющими угол 90о. Стрелки не
представляют поток или последовательность событий, как в традиционных
блок-схемах потоков или процессов. Они лишь показывают, какие данные
или материальные объекты должны поступить на вход функции для того,
чтобы эта функция могла выполняться. Рис. 2. Синтаксис стрелок.
• Имя функции –глагол или
глагольный оборот
• Показан номер блока
4.3.1 Блоки
1.Размеры блоков должны быть достаточными для того, чтобы включить
имя блока.
2.Блоки должны быть прямоугольными, с прямыми углами.
3.Блоки должны быть нарисованы сплошными линиями.
4.3.2 Стрелки
1. Ломаные стрелки изменяют направление только под углом 90 град.
2. Стрелки должны быть нарисованы сплошными линиями различной тол-
щины.
3. Стрелки могут состоять только из вертикальных или горизонтальных от-
резков; отрезки, направленные по диагонали , не допускаются.
4. Концы стрелок должны касаться внешней границы функционального бло-
ка, но не должны пересекать ее.
5.Стрелки должны присоединяться к блоку на его сторонах. Присоединение в
углах не допускается.
5. Семантика языка IDEF0.
Семантика определяет содержание (значение) синтаксических компонентов
языка и способствует правильности их интерпретации. Интерпретация уста-
навливает соответствие между блоками и стрелками с одной стороны и
функциями и их интерфейсами – с другой.
5.1 Семантика блоков и стрелок
Поскольку IDEF0 есть методология функционального моделирования, имя
блока, описывающее функцию, должно быть глаголом или глагольным обо-
ротом; например, имя блока "Выполнить проверку", означает, что блок с
таким именем превращает непроверенные детали в проверенные. После при-
сваивания блоку имени, к соответствующим его сторонам присоединяются
входные, выходные и управляющие стрелки, а также стрелки механизма, что
и определяет наглядность и выразительность изображения блока IDEF0.
Чтобы гарантировать точность модели, следует использовать стандартную
терминологию. Блоки именуются глаголами или глагольными оборотами и
эти имена сохраняются при декомпозиции Стрелки и их сегменты, как от-
дельные, так и связанные в «пучок», помечаются существительными или
оборотами существительного. Метки сегментов позволяют конкретизировать
данные или материальные объекты, передаваемые этими сегментами, с со-
блюдением синтаксиса ветвлений и слияний.
Каждая сторона функционального блока имеет стандартное значение с точки
зрения связи блок/стрелки, В свою очередь, сторона блока, к которой при-
соединена стрелка, однозначно определяет ее роль. Стрелки, входящие в
левую сторону блока - входы. Входы преобразуются или расходуются
функцией, чтобы создать то, что появится на ее выходе. Стрелки, входящие
в блок сверху - управления. Управления определяют условия, необходимые
функции, чтобы произвести правильный выход. Стрелки, покидающие блок
справа – выходы, т.е. данные или материальные объекты, произведенные
функцией.
Стрелки, подключенные к нижней стороне блока, представляют механизмы.
Стрелки, направленные вверх, идентифицируют средства, поддерживающие
выполнение функции. Другие средства могут наследоваться из родительско-
го блока. Стрелки механизма, направленные вниз, являются стрелками вызо-
ва. Стрелки вызова обозначают обращение из данной модели или из данной
части модели к блоку, входящему в состав другой модели или другой части
модели, обеспечивая их связь, т.е. разные модели или разные части одной и
той же модели могут совместно использовать один и тот же элемент (блок).
Стандартное расположение стрелок показано на рис.3.
5.2 Имена и метки.
Как указывалось, имена функций – глаголы или глагольные обороты. При-
меры таких имен:
производить детали планировать ресурсы наблюдать
наблюдать за выполнением проектировать систему эксплуатировать
разработать детальные чертежи изготовить компонент проверять деталь
Стрелки идентифицируют данные или материальные объекты, необходимые
для выполнения функции или производимые ею. Каждая стрелка должна
быть помечена существительным или оборотом существительного, напри-
мер:
Спецификации отчет об испытаниях бюджет
Конструкторские требования конструкция детали директива
Инженер-конструктор плата в сборе требования
Пример размещения меток стрелок и имени блока показан на рис. 4.
5.3 Семантические правила блоков и стрелок
1. Имя блока должно быть активным глаголом или глагольным оборотом.
2. Каждая сторона функционального блока должна иметь стандартное от-
ношение блок/стрелки:
а) входные стрелки должны связываться с левой стороной блока;
б) управляющие стрелки должны связываться с верхней стороной блока;
в) выходные стрелки должны связываться с правой стороной блока;
г) стрелки механизма (кроме стрелок вызова) должны указывать вверх и
подключаться к нижней стороне блока.
д) стрелки вызова механизма должны указывать вниз, подключаться к ниж-
ней стороне блока, и помечаться ссылкой на вызываемый блок.
3. Сегменты стрелок, за исключением стрелок вызова, должны помечаться
существительным или оборотом существительного, если только единствен-
ная метка стрелки несомненно не относится к стрелке в целом.
4. Чтобы связать стрелку с меткой, следует использовать "тильду" ( ) .
5. В метках стрелок не должны использоваться следующие термины:
функция, вход, управление, выход, механизм, вызов.
5.4 Диаграммы IDEF0.
IDEF0-модели состоят из трех типов документов: графических диаграмм,
текста и глоссария. Эти документы имеют перекрестные ссылки друг на
друга. Графическая диаграмма – главный компонент IDEF0-модели, содер-
жащий блоки, стрелки, соединения блоков и стрелок и ассоциированные с
ними отношения. Блоки представляют основные функции моделируемого
объекта. Эти функции могут быть разбиты (декомпозированы) на составные
части и представлены в виде более подробных диаграмм; процесс декомпо-
зиции продолжается до тех пор, пока объект не будет описан на уровне дета-
лизации, необходимом для достижения целей конкретного проекта. Диа-
грамма верхнего уровня обеспечивает наиболее общее или абстрактное опи-
сание объекта моделирования. За этой диаграммой следует серия дочерних
диаграмм, дающих более детальное представление об объекте.
5.5 Контекстная диаграмма верхнего уровня.
Каждая модель должна иметь контекстную диаграмму верхнего уровня, на
которой объект моделирования представлен единственным блоком с гранич-
ными стрелками. Эта диаграмма называется A-0 (А минус нуль). Стрелки
на этой диаграмме отображают связи объекта моделирования с окружающей
средой. Поскольку единственный блок представляет весь объект, его имя –
общее для всего проекта. Это же справедливо и для всех стрелок диаграммы,
поскольку они представляют полный комплект внешних интерфейсов объек-
та. Диаграмма A-0 устанавливает область моделирования и ее границу. При-
мер диаграммы A-0 показан на рис. 5.
Контекстная диаграмма A-0 также должна содержать краткие утверждения,
определяющие точку зрения должностного лица или подразделения, с пози-
ций которого создается модель, и цель, для достижения которой ее разраба-
тывают. Эти утверждения помогают руководить разработкой модели и вве-
сти этот процесс в определенные рамки. Точка зрения определяет, что и в
каком разрезе можно увидеть в пределах контекста модели. Изменение точ-
ки зрения, приводит к рассмотрению других аспектов объекта. Аспекты,
важные с одной точки зрения, могут не появиться в модели, разрабатываемой
с другой точки зрения на тот же самый объект.
Формулировка цели выражает причину создания модели, т.е. содержит пере-
чень вопросов, на которые должна отвечать модель, что в значительной мере
Руководство программиста
определяет ее структуру. Наиболее важные свойства объекта обычно выяв-
ляются на верхних уровнях иерархии; по мере декомпозиции функции верх-
него уровня и разбиения ее на подфункции, эти свойства уточняются. Каждая
подфункция, в свою очередь, декомпозируется на элементы следующего
уровня, и так происходит до тех пор, пока не будет получена релевантная
структура, позволяющая ответить на вопросы, сформулированные в цели
моделирования. Каждая подфункция моделируется отдельным блоком Каж-
дый родительский блок подробно описывается дочерней диаграммой на
более низком уровне. Все дочерние диаграммы должны быть в пределах
области контекстной диаграммы верхнего уровня.
5.6 Дочерняя диаграмма .
Единственная функция, представленная на контекстной диаграмме верхнего
уровня, может быть разложена на основные подфункции посредством созда-
ния дочерней диаграммы. В свою очередь, каждая из этих подфункций может
быть разложена на составные части посредством создания дочерней диа-
граммы следующего, более низкого уровня, на которой некоторые или все
функции также могут быть разложены на составные части. Каждая дочерняя
диаграмма содержит дочерние блоки и стрелки, обеспечивающие дополни-
тельную детализацию родительского блока.
Дочерняя диаграмма, создаваемая при декомпозиции, охватывает ту же об-
ласть, что и родительский блок, но описывает ее более подробно. Таким
образом, дочерняя диаграмма как бы вложена в свой родительский блок. Эта
структура иллюстрируется рис. 6.
5.7 Родительская диаграмма
Родительская диаграмма – та, которая содержит один или более родитель-
ских блоков. Каждая обычная (не-контекстная) диаграмма является также
дочерней диаграммой, поскольку, по определению, она подробно описывает
некоторый родительский блок. Таким образом, любая диаграмма может быть
как родительской диаграммой (содержать родительские блоки), так и дочер-
ней (подробно описывать собственный родительский блок). Аналогично,
блок может быть как родительским (подробно описываться дочерней диа-
граммой) так и дочерним (появляющимся на дочерней диаграмме). Основное
иерархическое отношение существует между родительским блоком и дочер-
ней диаграммой, которая его подробно описывает (рис.6).
То, что блок является дочерним и раскрывает содержание родительского
блока на диаграмме предшествующего уровня, указывается специальным
ссылочным кодом, написанным ниже правого нижнего угла блока. Этот ссы-
лочный код может формироваться несколькими способами, из которых
Более общее представление
Более детальное представление
Этот блок - родительский
для этой диаграммы
A4
A42
ПРИМЕЧАНИЕ: Номер узла показывает,
что этот блок был декомпозирован .
С-номер или номер листа дочерней
диаграммы может использоваться
вместо узлового номера
A0
0
РД IDEF0 - 2000
21
самый простой заключается в том, что код , начинающийся с буквы А(по
имени диаграммы А-0), содержит цифры, определяемые номерами родитель-
ских блоков. Например, показанные на рис.7 коды означают, что диаграмма
является декомпозицией 1-го блока диаграммы, которая, в свою очередь яв-
ляется декомпозицией 6-го блока диаграммы А0, а сами коды образуются
присоединением номера блока.
Рис. 7
Таким образом, код формируется так:
А 6 1 * * * *
| | | | |__________ и т.д.
| | | |___________ Номер блока на диаграмме А61
| | |_____________Номер блока на диаграмме А6
| |______________ Номер блока на диаграмме А0
|________________ Имя блока А0
5.8 Текст и глоссарий
Диаграмме может быть поставлен в соответствие структурированный текст,
представляющий собой краткий комментарий к содержанию диаграммы.
Текст используется для объяснений и уточнений характеристик, потоков ,
внутриблочных соединений и т.д. Текст не должен использоваться для опи-
сания и без того понятных блоков и стрелок на диаграммах.
Глоссарий предназначен для определения аббревиатур (акронимов), ключе-
вых слов и фраз, используемых в качестве имен и меток на диаграммах.
Глоссарий определяет понятия и термины, которые должны быть одинаково
понимаемы всеми участниками разработки и пользователями модели, чтобы
правильно интерпретировать ее содержание.
5.9 Диаграммы - иллюстрации (FEO).
Эти диаграммы используются в качестве дополнений, поясняющих специ-
фику содержания основных диаграмм в тех случаях, когда это необходимо.
Диаграмма FEO не должна подчиняться синтаксическим правилам IDEF0.
РД IDEF0 - 2000
23
6. Свойства диаграмм.
6.1 Стрелки как ограничения .
Стрелки на диаграмме IDEF0 , представляя данные или материальные объек-
ты , одновременно задают своего рода ограничения (условия). Входные и
управляющие стрелки блока, соединяющие его с другими блоками или с
внешней средой, по сути описывают условия, которые должны быть выпол-
нены для того, чтобы реализовалась функция, записанная в качестве имени
блока .
6.3 Ветвление и слияние сегментов стрелок
Ветвление и слияние стрелок призвано уменьшить загруженность диаграмм
графическими элементами (линиями). Чтобы стрелки и их сегменты пра-
вильно описывали связи между блоками - источниками и блоками - потреби-
телями, используется аппарат меток. Метки связываются с сегментами по-
средством тильд. При этом между сегментами возникают определенные от-
ношения, описанные ниже:
- непомеченные сегменты (рис.10) содержат все объекты, указанные в метке
стрелки перед ветвлением (т.е. все объекты принадлежат каждому из сегментов);
- сегменты, помеченные после точки ветвления (рис. 11), содержат все объ-
екты, указанные в метке стрелки перед ветвлением, или их часть, описы-
ваемую меткой каждого конкретного сегмента;
- при слиянии непомеченных сегментов объединенный сегмент стрелки
содержит все объекты, принадлежащие сливаемым сегментам и указанные
в общей метке стрелки после слияния (рис.12;
- при слиянии помеченных сегментов (рис. 13) объединенный сегмент со-
держит все или некоторые объекты, принадлежащие сливаемым сегмен-
там и перечисленные в общей метке после слияния; если общая метка по-
сле слияния отсутствует, это означает, что общий сегмент передает все
объекты, принадлежащие сливаемым сегментам;
Первое из перечисленных отношений определяется взаимным распо-
ложением блоков на диаграмме. Предполагается, что блоки, расположенные
на диаграмме выше и левее, «доминируют» над блоками, расположенными
ниже и правее. «Доминирование» понимается как влияние, которое один
блок оказывает на другие блоки диаграммы.
Остальные пять отношений описывают связи между блоками и изо-
бражаются соответствующими стрелками.
Отношения управления и выход – вход являются простейшими, поскольку
отражают прямые взаимодействия, которые понятны и очевидны.
Отношение управления (рис.14) возникает тогда, когда выход одного блока
служит управляющим воздействием на блок с меньшим доминированием.
Отношение выход – вход (рис. 15) возникает при соединении выхода одно-
го блока с входом другого блока с меньшим доминированием.
Обратная связь по управлению и обратная связь по входу являются более
сложными типами отношений, поскольку они представляют итерацию (вы-
ход функции влияет на будущее выполнение других функций с большим
доминированием, что впоследствии влияет на исходную функцию).
Обратная связь по управлению (рис. 16) возникает тогда, когда выход не-
которого блока создает управляющее воздействие на блок с большим доми-
нированием.
Отношение обратной связи по входу (рис. 17) имеет место тогда, когда
выход блока становиться входом другого блока с большим доминированием.
Связи «выход – механизм» (рис. 18) отражают ситуацию, при которой вы-
ход одной функции становиться средством достижения цели для другой.
Связи «выход – механизм» возникают при отображении в модели процедур
пополнения и распределения ресурсов , создания или подготовки средств для
выполнения функций системы (например, приобретение или изготовление
требуемых инструментов и оборудования, обучение персонала, организация
физического пространства, , финансирование, закупка материалов и т.д.;
подробнее – см. ниже, разд. … .).
7. Отношения между блоками диаграммы и другими диаграммами (ок-
ружающей средой).
Все описанные выше отношения отображаются внутренними стрелками,
т.е. такими, у которых оба конца связаны с блоками диаграммы. Отношения
между блоками диаграммы и другими диаграммами, являющимися по отно-
шению к рассматриваемой диаграмме окружающей средой (окружением),
описываются граничными стрелками (см. разд. … , п…) . Обе ситуации
отражены на рис. 19.
7.1 Граничные стрелки.
На обычной (не контекстной) диаграмме граничные стрелки представля-
ют входы, управления, выходы или механизмы родительского блока диа-
граммы. Источник или потребитель граничных стрелок можно обнаружить,
только изучая родительскую диаграмму. Все граничные стрелки на дочерней
диаграмме (за исключением стрелок, помещенных в тоннель (см. … ,)) долж-
ны соответствовать стрелкам родительского блока, как показано на рис. 20.
7.2 ICOM - кодирование граничных стрелок.
ICOM - коды связывают граничные стрелки на дочерней диаграмме со
стрелками родительского блока. Нотация, названная ICOM - кодом, опреде-
ляет значения соединений. Буквы I, C, O или M, написанные около несвя-
занного конца граничной стрелки на дочерней диаграмм идентифицируют
стрелку как Вход (Input), Управление (Control), Выход (Output) или Меха-
низм (Mechanism) в родительском блоке. Буква следует за числом, опреде-
ляющим относительное положение точки подключения стрелки к родитель-
скому блоку; это положение определяется слева направо или сверху вниз.
Например, код "C3", написанный возле граничной стрелки на дочерней диа-
грамме, указывает, что эта стрелка соответствует третьей (считая слева)
управляющей стрелке родительского блока.
Это кодирование связывает каждую дочернюю диаграмму со своим роди-
тельским блоком. Если блоки на дочерней диаграмме подвергаются даль-
нейшей декомпозиции и подробно описываются на дочерних диаграммах
следующего уровня, то на каждую новую диаграмму назначаются новые
ICOM - коды, связывающие граничные стрелки этих диаграмм со стрелка-
ми их родительских блоков.
Иногда буквенные ICOM - коды, определяющие роли граничных стре-
лок (вход, управление, механизм), могут меняться при переходе от родитель-
ского блока к дочерней диаграмме. Например, управляющая стрелка в роди-
тельском блоке может быть входом на дочерней диаграмме. Аналогично,
вход родительского блока может быть управлением для одного или более
дочерних блоков. Примеры изменения ролей стрелок можно видеть на рис.
7.3 Стрелки , помещенные в «туннель» .
Туннель - круглые скобки в начале и/или окончании стрелки. Туннельные
стрелки означают, что данные, выраженные этими стрелками, не рассматри-
ваются на родительской диаграмме и/или на дочерней диаграмме.
Рис.22
Стрелка, помещенная в туннель там, где она присоединяется к блоку (рис.
22), означает, что данные, выраженные этой стрелкой, не обязательны на
следующем уровне декомпозиции.
Стрелка, помещаемая в туннель на свободном конце (рис. 23) означает,
что выраженные ею данные отсутствуют на родительской диаграмме.
8. Правила построения диаграмм
1. В составе модели должна присутствовать контекстная диаграмма A-0, ко-
торая содержит только один блок. Номер единственного блока на контекст-
ной диаграмме A-0 должен быть 0.
2. Блоки на диаграмме должны располагаться по диагонали – от левого
верхнего угла диаграммы до правого нижнего в порядке присвоенных номе-
ров. Блоки на диаграмме, расположенные вверху слева «доминируют» над
блоками, расположенными внизу справа. «Доминирование» понимается как
влияние, которое блок оказывает на другие блоки диаграммы. Расположение
блоков на листе диаграммы отражает авторское понимание доминирования.
Таким образом, топология диаграммы показывает, какие функции оказывают
большее влияние на остальные.
3. Неконтекстные диаграммы должны содержать не менее трех и не более
шести блоков. Эти ограничения поддерживают сложность диаграмм на уров-
не, доступном для чтения, понимания и использования.
Диаграммы с количеством блоков менее трех вызывают серьезные со-
мнения в необходимости декомпозиции родительской функции. Диаграммы с
количеством блоков более шести сложны для восприятия читателями и вы-
зывают у автора трудности при внесении в нее всех необходимых графиче-
ских объектов и меток.
4. Каждый блок неконтекстной диаграммы получает номер, помещаемый
в правом нижнем углу; порядок нумерации - от верхнего левого к нижнему
правому блоку (номера от 1 до 6).
5. Каждый блок, подвергнутый декомпозиции, должен иметь ссылку на
дочернюю диаграмму; ссылка (например, узловой номер, C-номер или
номер страницы) помещается под правым нижним углом блока.
6. Имена блоков (выполняемых функций) и метки стрелок должны быть
уникальными. Если метки стрелок совпадают, это значит, что стрелки
отображают тождественные данные.
7. При наличии стрелок со сложной топологией целесообразно повторить
метку для удобства ее идентификации.
8. Следует обеспечить максимальное расстояние между блоками и пово-
ротами стрелок, а также между блоками и пересечениями стрелок для
облегчения чтения диаграммы. Одновременно уменьшается вероят-
ность перепутать две разные стрелки.
9. Блоки всегда должны иметь хотя бы одну управляющую и одну вы-
ходную стрелку, но могут не иметь входных стрелок.
10. Если одни и те же данные служат и для управления, и для входа, вы-
черчивается только стрелка управления. Этим подчеркивается управ-
ляющий характер данных и уменьшается сложность диаграммы.
11. Максимально увеличенное расстояние между параллельными стрел-
РД IDEF0 - 2000
ками облегчает размещения меток, их чтение и позволяет проследить
пути стрелок.
Обратные связи по входу должны быть показаны как "вниз и под" (рис.
27,б). Так же показываются обратные связи посредством механизма. Таким
образом обеспечивается показ обратной связи при минимальном числе линий
и пересечений.
14. Циклические обратные связи для одного и того же блока изображаются
только для того, чтобы их выделить. Обычно обратную связь изображают на
диаграмме, декомпозирующей блок. Однако иногда требуется выделить по-
вторно используемые объекты (рис.28).
15. Стрелки объединяются, если они имеют общий источник или приемник,
или они представляют связанные данные. Общее название лучше описывает
суть данных. Следует минимизировать число стрелок, касающихся каждой
стороны блока, если, конечно, природа данных не слишком разнородна (рис.
16. Если возможно, стрелки присоединяются к блокам в одной и той же по-
зиции. Тогда соединение стрелок конкретного типа с блоками будет со-
гласованным и чтение диаграммы упростится.
17. При соединении большого числа блоков необходимо избегать необяза-
тельных пересечений стрелок. Следует минимизировать число петель и по-
воротов каждой стрелки.
18. Блоки (функции) являются сопряженными через среду, если они имеют
связи с источником, генерирующим данные, без конкретного определения
отношения отдельной части данных к какому-либо блоку.
19. Две или более функций являются сопряженными через запись, если они
связаны с набором данных и не обязательно зависят от того, представлены
ли все возможные интерфейсы как сопряжение через среду. Тип интер-
фейса, показанный на рисунке 34, предпочтителен, поскольку определя-
ются отношения конкретных элементов данных к каждому блоку.
9. Ссылочные выражения (коды).
Ссылочные выражения (коды) присваиваются всем элементам модели:
диаграммам, блокам, стрелкам и примечаниям. Ссылочные выражения затем
могут использоваться в различных контекстах для точного указания на нуж-
ный элемент модели.
Основное ссылочное выражение - узловой номер, который появляется
там, где выполняется декомпозиция функционального блока и создается его
подробное описание на дочерней диаграмме. Все остальные ссылочные коды
базируются на узловых номерах.
9.1. Номера блоков.
Каждому блоку на диаграмме присваивается номер, помещаемый в нижнем
правом внутреннем углу блока. Эта система нумерации необходима для од-
нозначной идентификации блоков в пределах диаграммы и для генерации
узловых номеров. Эти номера используются также для ссылок на блоки в
тексте и глоссарии.
На контекстной диаграмме A-0 единственному блоку присваивается номер
0 (нуль). На всех других диаграммах блоки нумеруются цифрами от 1 до 6,
начиная с верхнего левого блока (при их диагональном размещении) и кон-
чая нижним правым блоком. Если некоторые блоки на диаграмме размещены
не по диагонали, то сначала нумеруются «диагональные» блоки (также на-
чиная с левого верхнего блока) , а затем – «недиагональные» блоки, начиная
с нижнего правого против часовой стрелки .
9.2 Узловые номера.
Узловой номер базируется на положении блока в иерархии модели.
Обычно узловой номер формируется добавлением номера блока к номеру
диаграммы, на которой он появляется. Например, узловой номер блока 2 на
диаграмме A25 - A252. Все узловые номера IDEF0 начинаются с заглавной
буквы, например, "A". Когда родительский блок подробно описывается до-
черней диаграммой, узловые номера родительского блока и дочерней диа-
граммы совпадают.
Контекстные диаграммы и дочерняя диаграмма верхнего уровня - исклю-
чения в вышеуказанной схеме узловой нумерации. Каждая модель IDEF0
имеет контекстную диаграмму верхнего уровня - диаграмму A-0. Эта диа-
грамма содержит единственный "высший блок", который является уникаль-
ным родителем всей модели и несет уникальный номер 0 (нуль) и узловой
номер A0. Каждая модель IDEF0 должна также иметь по крайней мере одну
РД IDEF0 - 2000
дочернюю диаграмму, содержащую декомпозицию блока А0 на 3 … 6 дочер-
них блоков. Этим блокам присваиваются уникальные узловые номера A1,
A2, A3, … A6. Таким образом, последовательность [A0, A1,..., A2,..., A3,...]
начинает нумерацию узлов для любой модели.
Например, модель может иметь следующие узловые номера:
...
A-1 Дополнительная контекстная диаграмма
A-0 Обязательная контекстная диаграмма верхнего уровня
(содержащая высший блок А0)
A0 Верхняя дочерняя диаграмма
A1, A2, ..., A6 Дочерние диаграммы
A11, A12, ...., A16, ...., A61, ... , A66 Дочерние диаграммы
A111, A112, ..., A161, ...., A611, ..., A666 Дочерние диаграммы
... Дочерние диаграммы нижнего уровня
Узловой номер используется также для обозначения того, что блок под-
вергнут декомпозиции. В этом случае узловой номер, совпадающий с номе-
ром дочерней диаграммы, помещается под правым нижним углом блока на
родительской диаграмме ( см. рис.6).
9.3 Перечень узлов.
Перечень узлов представляет информацию о входящих в модель узлах в
форме списка, напоминающего обычное оглавление и отражающего иерар-
хическую структуру модели, как показано на рис. 36.
A21 Разработать основной график
A22 Разработать график координации работ
A23 Оценивать затраты и приобретать ресурсы
A24 Следить за выполнением графика и расходом ресурсов
A0 Производить продукт
A1 Планировать производство
A2 Разрабатывать и управлять граафиком выпуска и ресурсами
A3 Планировать выпуск продукции
А11 Выбрать технологию производства
A12 Оценить требуемое время и затраты на производство
A13 Разработать производственные планы
A14 Разработать план вспомогательных действий
Рис. 36.
РД IDEF0 - 2000
42
9.4 Дерево узлов.
Разработанная модель IDEF0 со всеми уровнями структурной декомпо-
зицией может быть представлена на единственной диаграмме в виде дерева
узлов, дополняющего перечень узлов. Для изображения этого дерева нет
стандартного формата. Единственное требование состоит в том, что вся ие-
рархия узлов модели должна быть представлена наглядно и понятно. Пример
дерева узлов показан на рис.37.
Рис. 37.
РД IDEF0 - 2000
43
10. Методика разработки функциональных моделей среде IDEF 0.
В предыдущих разделах описаны инструментальные возможности методо-
логии IDEF0 как средства функционального моделирования производствен-
но-технических и организационно-экономических систем. В настоящем раз-
деле кратко излагаются некоторые методические приемы построения моде-
лей, облегчающие практическое применение этой методологии.
10.1 Общие положения.
Как уже отмечалось во Введении, объектами функционального моделиро-
вания и структурного анализа по методологии IDEF0 являются организаци-
онно-экономические и производственно-технические системы. Согласно
основным положениям системного анализа и системотехники [ 4 ] системой
называется совокупность взаимодействующих объектов любой, в том числе
различной, физической природы, обладающая выраженным системным свой-
ством (свойствами), т.е. свойством, которого не имеет ни одна из частей сис-
темы при любом способе членения, и не выводимым из свойств частей. Части
системы, обладающие собственными системными свойствами, называются
подсистемами. Объединение нескольких систем, обладающее системным
свойством, называют надсистемой или системой более высокого (2-го, 3-ьего
и т.д.) порядка. Элементом системы является объект с однозначно опреде-
ленными известными свойствами, вытекающими из физических или эконо-
мических законов.
Система (подсистема, элемент) имеют входы и выходы. Входом называет-
ся дискретное или непрерывное множество «контактов», через которое воз-
действие среды передается системе. Выход – множество «контактов», через
которое система воздействует на среду. Любой элемент системы имеет по
крайней мере один вход и один выход. Воздействие может состоять в пере-
даче вещества, энергии, информации или комбинации этих сущностей.
Приведенные определения корреспондируются с определением функцио-
нального блока IDEF0 с той лишь разницей, что в методологии входные
контакты подразделяются на собственно входы и управления.
Функциональный блок, как отображающий моделируемую систему в целом
(блок А0), так и блок на любом уровне декомпозиции являются преобра-
зующими блоками. Преобразующий блок – блок IDEF0 – диаграммы, пре-
образующий входы в выходы под действием управлений при помощи «меха-
низмов» (см. разд. 2, 3). Преобразование – цель и результат работы любого
блока на диаграмме любого уровня декомпозиции.
Преобразованию в блоке могут подвергаться материальные и информацион-
ные объекты, образующие соответствующие потоки.
Материальный поток – непрерывное или дискретное множество матери-
РД IDEF0 - 2000
44
альных объектов, распределенное во времени.
Информационный поток – множество информационных объектов, распре-
деленное во времени.
Информация, участвующая в процессах, операциях, действиях и деятельно-
сти в целом, может быть классифицирована на три группы:
ограничительная информация;
описательная информация;
предписывающая (управляющая) информация.
Ограничительная информация - сведения о том, чего нельзя делать:
а) никогда, ни при каких обстоятельствах (кроме, быть может, форс-
мажорных) в любой фазе и на любом этапе функционирования системы в
целом;
б) в рамках функционирования конкретного блока.
Ограничительная информация содержится в законах, подзаконных актах,
международных, государственных и отраслевых стандартах, а также в специ-
альных внутренних положениях и документах предприятия, в частности, в
технических требованиях, условиях, регламентах и т.д.
Описательная информация – сведения об атрибутах объекта (потока) пре-
образуемого функциональным блоком. Содержится в чертежах, технических
и иных описаниях, реквизитах и т.п. документах, являясь неотъемлемым
компонентом объекта в течение всего жизненного цикла. Эта информация
сама преобразуется (изменяется) в результате выполнения функции.
Предписывающая (управляющая) информация – сведения о том, как , при
каких условиях и по каким правилам следует преобразовать объект (по-
ток) на входе в объект (поток) на выходе блока. Содержится в технологиче-
ских (в широком смысле) инструкциях, руководствах, документах, опреде-
ляющих «настройки» и характеристики блока.
предписывающая информация изображается стрелками, присоединяемыми к
блоку на стороне управления, а описательная информация поступает на вход
блока и формируется на его выходе, отображаясь стрелками входа и выхода
соответственно.
Материальный поток и описывающий его информационный поток везде,
где это не вызывает недоразумений, можно изображать одной стрелкой.
10.2 Классификация функций, моделируемых блоками IDEF0.
Единообразное представление явлений и событий реального мира, проис-
ходящих в моделируемых системах, в виде функциональных блоков является
большим преимуществом графического языка IDEF0 . Вместе с тем, практика
построения моделей требует введения классификации явлений и событий с
целью облегчения построения и интерпретации (понимания) функциональ-
ных моделей. Такая классификация облегчает выбор глубины декомпозиции
моделируемых систем и способствует выработке единообразных подходов и
приемов моделирования в конкретных предметных областях.
В настоящем РД предлагается классификация, ориентированная на дос-
таточно широкий круг организационно-экономических и производственно-
технических систем. Классификация делит все функции таких систем на че-
тыре основных и два дополнительных вида. Каждая рубрика в классифика-
ции представляет собой класс преобразующих блоков, экземпляры которого
возникают и используются при моделировании конкретной системы
А) Основные виды функций.
1.Деятельность ( синонимы: дело, бизнес) – совокупность процессов, вы-
полняемых (протекающих) последовательно или/и параллельно, преобра-
зующих множество материальных или/и информационных потоков во мно-
жество материальных или/и информационных потоков с другими свойства-
ми. Деятельность осуществляется в соответствии с заранее определенной и
постоянно корректируемой целью, с потреблением финансовых, энергетиче-
ских, трудовых и материальных ресурсов, при выполнении ограничений со
стороны внешней среды.
В модели IDEF0 деятельность описывается блоком А0 на основной контек-
стной диаграмме А-0.
При моделировании крупных, многопрофильных структур (фирм, организа-
ций, предприятий), которые по своему статусу занимаются различными ви-
дами деятельности, последние представляют собой различные экземпляры
класса «деятельность» и могут найти отражение в дополнительной контек-
стной диаграмме А-1. В этом случае общая модель такой сложной структуры
будет состоять из ряда частных моделей, каждая из которых относится к кон-
кретному виду деятельности. Связь между этими частными моделями пред-
РД IDEF0 - 2000
46
ставляет отдельную методическую проблему, которая в рамках настоящего
РД не рассматривается.
2.Процесс (синоним: бизнес-процесс) – совокупность последовательно или/и
параллельно выполняемых операций, преобразующая материальный или/и
информационный потоки в соответствующие потоки с другими свойствами.
Процесс протекает в соответствии с управляющими директивами, выраба-
тываемыми на основе целей деятельности . В ходе процесса потребляются
финансовые, энергетические, трудовые и материальные ресурсы и выполня-
ются ограничения со стороны других процессов и внешней среды.
3.Операция – совокупность последовательно или/и параллельно выполняе-
мых действий, преобразующих объекты, входящие в состав материального
или/и информационного потока, в соответствующие объекты с другими
свойствами. Операция выполняется : а) в соответствии с директивами, вы-
рабатываемыми на основе директив, определяющих протекание процесса, в
состав которого входит операция; б) с потреблением всех видов потребных
ресурсов; в) с соблюдением ограничений со стороны других операций и
внешней среды.
4. Действие – преобразование какого-либо свойства материального или ин-
формационного объекта в другое свойство. Действие выполняется в соответ-
ствии с командой, являющейся частью директивы на выполнение операции,
с потреблением необходимых ресурсов и с соблюдением ограничений, нала-
гаемых на осуществление операции.
Б) Дополнительные виды функций:
5. Субдеятельность – совокупность нескольких процессов в составе дея-
тельности, объединенная некоторой частной целью (являющейся «подцелью»
деятельности).
6. Подпроцесс – группа операций в составе процесса, объединенная техноло-
гически или организационно.
Введенные выше понятия группы А образуют естественную иерархию
блоков на IDEF0-диаграммах при декомпозиции, предусматривая четыре
уровня последней. Однако при анализе сложных видов деятельности могут
потребоваться промежуточные уровни декомпозиции, основанные на приме-
нении функций группы Б.
Уровни декомпозиции, детализирующие действия, естественно считать
состоящими из элементарных или простых функций.
В Приложении 1 приведены IDEF0-диаграммы, показывающие описан-
ную в классификации иерархию функций в виде абстрактной метамодели. Из
нее видно, как эти функции взаимодействуют между собой на разных уров-
нях декомпозиции. Метамодель служит шаблоном, применение которого
может облегчить создание реальной модели в конкретной предметной облас-
ти.
РД IDEF0 - 2000
47
10.3 Организационно-технические структуры и механизмы
IDEF0-моделей.
Все функции, входящие в приведенную выше классификацию, находятся
между собой в отношениях иерархической подчиненности по принципу
«сверху вниз»: деятельность – субдеятельность – процесс – подпроцесс –
операция – действие. Согласно методологии IDEF0 каждая функция выпол-
няется посредством механизма. В большинстве систем, анализируемых при
помощи функциональных моделей такими механизмами служат организаци-
онно-технические структуры. Одним из концептуальных принципов функ-
ционального моделирования (см. разд. 2, п. 2.7) является «отделение «орга-
низации» от функций». Вместе с тем анализ показывает, что между иерархи-
ей функций (преобразований ) и иерархией механизмов существует соответ-
ствие, иллюстрируемое рис.39.
Используя приведенные выше понятия системного анализа, определим
элементы иерархии механизмов следующим образом.
Организационно-техническая система - организационная структура, пер-
сонал и комплекс технических средств (оборудование), необходимые для
осуществления деятельности .
Организационно-техническая подсистема – часть организационно-
технической системы, обеспечивающая протекание процесса (субдеятельно-
сти).
Организационно-технический комплекс (модуль) - часть организацион-
но-технической подсистемы, предназначенная для выполнения операции.
Организационно-технический блок – часть организационно-технического
комплекса, обеспечивающая выполнение действия.
Деятельность Организационно - техническая система
Процесс Организационно - техническая подсистема
Операция
Действие
Организационно - технический модуль (комплекс)
Организационно - технический блок
РД IDEF0 - 2000
Таким образом, при корректном построении модели (без априорной при-
вязки к «организации») появляется возможность связать ее блоки на разных
уровнях декомпозиции с объектами организационно-технической структуры,
выступающими в качестве механизмов. В этом случае, и это методически
крайне важно, организационно-техническая структура становится ре-
зультатом функционального моделирования.
Во многих моделях находит или должно находить отражение явление, со-
стоящее в формировании или специфической настройке (перестройке) меха-
низмов в ходе деятельности. Это явление часто именуется реинжинирнгом
производства и/или бизнес-процессов на предприятии (в организации).
Явление отражается в модели как субдеятельность, поскольку почти всегда
состоит из нескольких процессов. Укрупненная схема этой субдеятельности
приведена на рис.40. Согласно схеме входом и одновременно потребляемым
ресурсом субдеятельности являются финансы, преобразуемые в другие
виды ресурсов – энергетические, трудовые, материальные (оборудование,
вспомогательные материалы и т.п.). ( см. Приложение 1) .
Механизм любого уровня обеспечивает выполнение деятельности (процесса,
операции, действия), потребляя ресурсы: финансовые, энергетические, тру-
довые, непосредственно или с помощью промежуточных преобразований
(рис. 40), т.е. специфических процессов, которые можно назвать поддержи-
вающими, обеспечивающими или вспомогательными ( по аналогии с вспо-
могательными производствами, цехами, участками на машиностроительном
предприятии) по отношению к основным процессам, где происходят преоб-
разования, однозначно обусловленные целью деятельности.
Существенный признак вспомогательного процесса: этот процесс не
создает конечного продукта деятельности и, следовательно, прибыли.
10.4 Управление – особый вид процесса, операции, действия.
Один из общих принципов методологии IDEF 0 требует, чтобы к каждому
блоку на диаграмме должна быть присоединена хотя бы одна управляющая
стрелка, отображающая условия правильного функционирования блока ( см.
разд. 8). Это требование есть следствие положения системотехники, согласно
которому управление есть такое воздействие ( преимущественно информа-
ционное) на систему, которое стимулирует ее функционирование в направ-
лении достижения некоторой цели [4 ]. В связи с этим можно сформулиро-
вать ряд определений и методических положений, которыми следует руково-
дствоваться при отражении управлений на функциональных моделях.
Управление деятельностью – процесс, состоящий, как минимум, из сле-
дующих операций:
формулирование целей деятельности;
оценивание ресурсов, необходимых для осуществления деятельности и их
сопоставление с имеющимися ресурсами;
сбор информации об условиях протекания и фактическом состоянии дея-
тельности («глобальная» обратная связь);
выработка и принятие решений, направленных на достижение целей по п.1, в
частности, решений о распределении ресурсов по процессам, входящим в
состав деятельности; оформление решений в виде директив на управление
процессами;
реализация решений (исполнение директив) и оценка их результатов («ло-
кальная обратная связь»);
корректировка (в случае необходимости, например, при нехватке ресурсов)
ранее сформулированных целей (самонастройка, адаптация).
Именно решения и их реализация – суть те стимулирующие воздействия
на систему, о которых говорилось выше.
Управление процессом – операция, состоящая, как минимум, из сле-
дующих действий:
анализ директивы на управление процессом, ее декомпозиция на директивы
управления операциями;
сбор (прием по каналам связи) информации о ходе выполнения операций, ее
обобщение и формирование сведений о состоянии процесса; передача дан-
ных в подсистему управления деятельностью;
сопоставление информации о ходе операций с данными директив и выработ-
ка локальных решений, направленных на устранение отклонений:
корректировка (в случае необходимости) директив на выполнение операций.
Управление операцией – действие, состоящее в выработке на основании
директивы на управление операцией команд на управление действиями, в
реализации этих команд, оценке результатов выполнения, передаче необхо-
димой информации в комплекс управления процессом, корректировке ко-
РД IDEF0 - 2000
манд в случае необходимости.
Блоки управления должны присутствовать на каждой IDEF 0-диаграмме
(кроме тех, которые являются декомпозициями самих таких блоков). Через
них осуществляются управляющие воздействия на остальные блоки диа-
граммы. Именно эти блоки воспринимают ограничивающую и предписы-
вающую информацию и преобразуют ее в соответствующие директивы и
команды. Имена блоков управления, как правило, содержат глагол «Управ-
лять…».
Стрелки, исходящие из блока с именем «Управлять …», описывают цен-
трализованную схему управления (управленческую «вертикаль»). Возмож-
ны варианты структур, в которых выходная информация одного из блоков
является управляющей для другого. Это отображает децентрализацию
управления («горизонтальные» связи) (см. Приложение 1) .
10.5 Типизация функциональных моделей и IDEF 0– диаграмм.
Эффективность и производительность труда разработчиков функциональ-
ных моделей могут быть повышены за счет применения типовых моделей и
отдельных диаграмм, ориентированных на применение в конкретных пред-
метных областях. Так, например, на основе представлений о жизненном цик-
ле продукции (изделия) можно предложить типовую диаграмму уровня А0
для промышленного предприятия, которая может иметь вид, схематически
показанный на рис.41.
11. Организация процесса функционального моделирова-
ния и управление проектом
11.1 Общие положения
Для эффективного моделирования и получения результатов в соответ-
ствии со сроками и сметами управление проектом должно представлять со-
бой процесс, в ходе которого координируется работа авторов, экспертов и
тех, кто принимает окончательную версию модели системы или ее части.
Это должен быть процесс, в полной мере использующий возможности
методологии, основанной на разделении функций участников проекта и ите-
ративном характере рецензирования, в ходе которого проверяется коррект-
ность диаграмм и/или моделей, а также соответствие их поставленной цели и
точке зрения.
IDEF0–модель есть результат скоординированной коллективной рабо-
ты, при которой авторы создают первоначальные диаграммы, основанные на
собранной информации об объекте моделирования, и передают их другим
участникам проекта для рассмотрения и формулирования замечаний. Поря-
док, изложенный ниже, требует, чтобы каждый эксперт, у которого есть за-
мечания к диаграмме, сделал их письменно и передал автору диаграммы.
Этот цикл продолжается до тех пор, пока диаграммы, а затем и вся модель не
будут приняты. Процесс моделирования иллюстрируется рис. 42. Диаграмма
отражает тот факт, что этот процесс - итеративная процедура, приводящая к
точному описанию системы.

Ценность модели (проекта) определяется ее приемлемостью для экс-
пертов.
Эта приемлемость достигается следующими путями:
1) постоянным рецензированием экспертами развивающейся модели,
что обеспечивает необходимый уровень соответствия модели кон-
кретной моделируемому объекту (если модель отражает состояние
«как есть») или предполагаемому (состояние «как должно быть») в
том понимании, которое соответствует мнению экспертов.
2) периодическим обсуждением диаграмм, частей модели и модели в
целом на техническом совете, решение которого (оформленное в
виде протокола) позволяет автору продолжить уточняющее модели-
рование или закончить его ввиду достаточности детализации и при-
емлемости проекта (модели).
Если в процессе моделирования выявляется несогласованность оценок
экспертов, то такая несогласованность должна быть преодолена, чтобы полу-
чить модель, представляющую объект моделирования или какую-то его часть
адекватно.
Методология IDEF0 предусматривает необходимость сохранения запи-
сей о всех решениях и альтернативных подходах по мере того, как они воз-
никают на протяжении проекта.
Копии диаграмм, разработанные автором, критически (конструктивно)
анализируются компетентными экспертами, которые заносят свои замечания
и предложения непосредственно на копиях диаграмм. Авторы отвечают на
каждое замечание письменно на тех же копиях.
Предложения принимаются или отвергаются письменно с указанием
причин. После внесения изменений и исправлений старые варианты диа-
грамм остаются в архиве проекта.
В процессе чтения диаграмм ничто не должно предполагаться в модели
по умолчанию, а также не должны делаться выводы, выходящие за пределы
действия и утверждения модели. Это побуждает автора к тщательному ком-
ментированию и иллюстрированию каждого добавляемого к модели фраг-
мента, чтобы при чтении и интерпретации модели ее толкование было одно-
значным и соответствующим поставленной цели и установленной точке зре-
ния без личного присутствия автора и его дополнительных пояснений.
11.2 Состав участников проекта и структура их взаимодействия
В коллектив, занимающийся проектированием (моделированием),
должны входить следующие участники:
• Руководитель проекта.
• Авторы (разработчики) модели.
• Технический совет
РД IDEF0 - 2000
54
• Эксперты в предметной области.
• Библиотекарь.
Дополнительный специфический участник проекта - "Источники информа-
ции".
При проведении работ с привлечением сторонних организаций может
создаваться Координационный совет, обеспечивающий взаимодействие
всех участников проекта, работающих как в составе проектирующей органи-
зации, так и вне ее. Выполняемая функция («роль», которую выполняет уча-
стник проекта) не зависит от должности. Один и тот же человек может вы-
полнять несколько функций. Однако «роль» каждого участника проекта ин-
дивидуальна, должна быть определена и зависит от рассматриваемой части
проекта. Структура взаимодействия участников проекта приведена на рис.43.
Принципы коллективной работы в IDEF0 – методологии гарантируют,
что окончательная версия IDEF0 – модели будет верной, так как модель кор-
ректируется по результатам рецензирования частей модели, оформленных в
виде папок. Более подробная детализация достигается построением необхо-
димого количества диаграмм. По новым частям модели делаются новые за-
мечания, вносятся новые изменения. Окончательная модель соответствует
представлениям автора и экспертов о системе, смоделированной с данной
точки зрения и для данной цели.
Руководитель проекта и разработчики модели (авторы) должны быть
РД IDEF0 - 2000
55
главными исполнителями. Хотя конечной целью разработчика является по-
лучение одобрения модели техническим советом, утверждает результаты
руководитель проекта. Таким образом, обеспечивается согласованность ин-
тересов авторов, рецензентов, совета и руководителя проекта.
11.2.1 Руководитель проекта
Руководитель проекта - лицо, осуществляющее административное
управление проектом. Руководитель проекта должен выполнять при модели-
ровании следующие основные функции:
• Выбирать разработчиков модели (авторов). Главным аспектом дан-
ной функции является достижение руководителем проекта и разра-
ботчиком модели согласия относительно основополагающих пра-
вил, в соответствии с которыми выполняется моделирование. Сюда
входят использование методологии, степень контроля за разработ-
чиком модели со стороны руководителя проекта, область действия и
ориентация разрабатываемой модели.
• Определять обязательные источники информации, на которые раз-
работчик модели будет опираться при построении модели. Этими
источниками могут быть либо люди, осведомленные о различных
аспектах рассматриваемой сферы деятельности, либо документы,
освещающие предметную область моделирования. Эти источники
определяются на начальной стадии моделирования, но список их в
процессе моделирования должен пересматриваться и уточняться,
поскольку по мере построения модели потребности в информации
меняются.
• Выбирать экспертов, чьи знания будут использованы разработчиком
для получения оценки (одобрения) диаграмм и частей модели.. Спи-
сок экспертов составляется на начальной стадии проекта и уточня-
ется по мере необходимости.
• Формировать технический совет. Руководитель проекта. – неизби-
раемый председатель технического совета. Этот совет под его пред-
седательством периодически собирается для обсуждения сущест-
венных вопросов, рецензирования и определения статуса модели и
ее частей.
• Присваивать статус рассматриваемой советом части модели.
11.2.2 Разработчики (авторы) модели
Разработчики (авторы) модели - лица, создающие IDEF0 –модели. Разра-
РД IDEF0 - 2000
56
ботчик создает модель на основе материала, собранного из источников ин-
формации.
Разработчик должен:
• собирать исходные данные от обязательных источников информа-
ции, определенных руководителем проекта; при недостаточности
собранных сведений автор вправе использовать любые другие ис-
точники информации с обязательным указанием ссылок на них;
• обучать (при необходимости) основам IDEF0-моделирования руко-
водителя проекта, экспертов (рецензентов и читателей) и других
членов технического совета для обеспечения правильного понима-
ния ими моделей, создаваемых авторами;
• оформлять модель в виде IDEF0-диаграмм;
• организовывать разработку модели.
В период подготовки проекта разработчик вместе с руководителем
проекта изучает и устанавливает область действия модели. Затем он намечает
план проекта, т.е. состав и последовательность работ, которые необходимо
выполнить для достижения поставленных целей.
Руководитель проекта обеспечивает разработчика списком источников
информации и списком экспертов, к которым разработчик может обратиться.
Разработчик должен удостовериться, что со всеми участниками проекта ус-
тановлен необходимый контакт.
Исходную информацию разработчик собирает из источников, установ-
ленных руководителем проекта. Природа этой информации во многом зави-
сит от стадии разработки модели. Источниками информации могут служить
люди и документы. Разработчик должен понимать, что каждый эксперт-
источник информации смотрит на информацию со своей точки зрения. Раз-
работчик должен стараться увидеть глазами источника информации ее смысл
и структуру. Синтезируя эти точки зрения в процессе сравнения и противо-
поставления, разработчик создает образ изучаемого объекта моделирования.
Второй функцией разработчика является помощь в технике моделиро-
вания всем, кому она может понадобиться. Эта помощь заключается в общем
ориентировании членов технического совета, источников информации и экс-
пертов, ознакомлении их с навыками чтения модели, а также с навыками
моделирования.
Третьей функцией является оформление модели в виде IDEF0-
диаграмм. Для рецензирования он оформляет папки с диаграммами для пере-
дачи их в библиотеку проекта.
Разработчик организует построение модели. Для поддержки принятых
разработчиком решений и регистрации вклада каждого участника записи
исходной информации, собранной в процессе моделирования, сохраняются
РД IDEF0 - 2000
57
в течение определенного времени после завершения проекта. Это позволяет
разработчику следить за тем, чтобы исследуемая область была охвачена со
всех сторон. Зная, кто и в каких областях поставлял информацию, и как это
происходило, разработчик может оценить степень соответствия стадии моде-
лирования исходным целям.
11.2.3 Технический совет
Это элемент организации процесса создания моделей, предлагающий
арбитражные решения по моделированию и рекомендации по установлению
статуса диаграмм, части и/или модели в целом (статусы: "Рабочий проект",
«Эскиз», «Рекомендовано» и Публикация»).
Технический совет проводит политику проекта через рекомендации и
замечания авторам, предложения по установлению статуса руководителю
проекта и подготовку компромиссных решений для разрешения конфликтов,
которые могут возникнуть в процессе проекта. В техническом совете должно
быть несколько специалистов с высоким уровнем компетентности способных
отстоять свои решения перед высшим руководством объекта моделирования.
Технический совет формируется из экспертов и профессионалов, зна-
комых с предметной областью моделирования. Руководитель проекта фор-
мирует этот совет и является его председателем. Поскольку основной причи-
ной, побуждающей создавать модель, является необходимость повышения
эффективности объекта моделирования, важно, чтобы в совете были пред-
ставлены все службы , имеющие отношение к рассматриваемой в проекте
предметной области. Полезно включать в совет экспертов из смежных облас-
тей объекта моделирования, не входящих в исследуемую область, но связан-
ных с ней. Эти эксперты помогают адекватно оценить влияние окружающей
среды на объект моделирования.
Эксперты могут быть членами совета. Эксперту обычно показывают
только ограниченные фрагменты модели на промежуточных стадиях, в то
время как совет должен принять решение по всей модели. Иногда в совет
могут входить лица, играющие роль источников. В силу очевидной противо-
речивости интересов нецелесообразно, чтобы в совет входили разработчики
модели.
11.2.4 Эксперт
Эксперт - выбираемое руководителем проекта лицо, обладающее спе-
циальными знаниями некоторых аспектов моделируемой области. Его опыт в
предметной области, к которой относится моделируемый объект, позволяет
делать полезные критические замечания в процессе создания модели.
Эксперты призваны критически оценивать создаваемую по частям мо-
дель. Это осуществляется в ходе нескольких циклов изучения с использова-
нием читательских папок (цикл автор/читатель). Папки обеспечивают экс-
РД IDEF0 - 2000
58
перта набором информации, предназначенным для описания законченного
фрагмента моделируемого объекта. С помощью папок эксперту предоставля-
ется информация в наглядном виде. В процессе рецензирования ему может
понадобиться заполнить пробелы или даже завершить изложение материала,
представленного в папке. Хотя папка во многом основывается на интерпре-
тации разработчиком ранее полученной информации, комментарии экспер-
тов служат ценным материалом для уточнения модели. В информационных
папках перед экспертом должны ставиться конкретные, четко сформулиро-
ванные вопросы, связанные с моделированием.
Главной задачей эксперта является оценка соответствия модели соот-
ветствующей предметной области. Экспертная оценка является основным
средством в достижении консенсуса среди изучающих модель экспертов.
Одобренная модель - это модель, согласованная с экспертами. Если эксперты
согласны с тем, что модель или ее часть адекватно представляет рассматри-
ваемый объект, то модель считается одобренной. Если есть не согласившиеся
с этим, то их мнение должно обязательно фиксироваться, и модель считается
неправильной, пока не доказано обратное. Для достижения консенсуса авто-
ры учитывают комментарии и замечания экспертов при пересмотре той части
модели, к которой эти замечания относятся.
Эксперты подразделяются на две группы:
• Эксперты – рецензенты
• Эксперты – читатели.
Эксперт-рецензент - член коллектива разработчиков, знающий предметную
область моделирования, специализирующийся на некоторой конкретной
функции предприятия и ответственный за обеспечение критических коммен-
тариев относительно разрабатываемой модели. Эксперт – рецензент должен
знать IDEF0 - методологию и уметь делать письменные структурированные
замечания в рассылаемых папках. Он является постоянным и активным уча-
стником цикла автор/читатель.
Эксперт–читатель - член коллектива разработчиков, профессионально
знающий предметную область моделирования, понимающий IDEF0 - мето-
дологию и умеющий читать IDEF0 - диаграммы. Эксперт - читатель знако-
мится с документацией (IDEF0 - папкой), не делая письменных комментари-
ев. От экспертов-читателей авторы получают замечания с помощью опроса.
11.2.5. Библиотекарь
библиотекарь - лицо, ответственное за хранение документации, изго-
товление копий, координацию обмена письменной и/или электронной ин-
формацией (рассылка папок, получение рецензий, регистрация и публикация
диаграмм и модели).
РД IDEF0 - 2000
11.2.6 Источники информации
Исходная информация для IDEF0-модели поступает к разработчику из
разных источников: от людей и от документов. Люди, являющиеся источни-
ками информации, обладают конкретными знаниями о частных свойствах
объекта моделирования, управлении или ходе бизнес–процесса и их участие
в моделировании может быть ограничено несколькими минутами опроса.
Однако именно эти источники обеспечивают основу для моделирования.
Информация, предоставляемая ими, используется для создания модели, а
восприятие этой информации обеспечивает разработчику понимание, необ-
ходимое для построения точной модели.
Руководитель проекта подбирает адекватные источники информации,
исходя из направления проекта и потребностей разработчика. По мере разви-
тия процесса моделирования потребности в информации изменяются, и спи-
сок источников информации руководитель проекта пересматривает. Соби-
раемая разработчиком информация должна как можно точнее фиксироваться.
Каждый источник воспринимает предметную область по-своему, и на
разработчике лежит ответственность за правильный отбор информации. Осо-
бенно это относится к источникам-документам.
Источник - документ отражает состояние объекта моделирования в не-
который момент времени. Поэтому документы являются важным источником
информации для модели, но для их эффективного использования необходима
значительная работа, связанная с интерпретацией, пониманием и подтвер-
ждением.
Лица, выступающие в роли источников информации, могут оказывать
разработчику модели дополнительную помощь, объясняя, как сообщенная
ими информация поступает, интерпретируется или используется. Разработ-
чик должен воспользоваться этой помощью для понимания того, как воспри-
ятие информации одного источника связано с восприятием другого.
11.3 Заключительные замечания
1. Функциональная модель - плод коллективного труда всех участников
процесса моделирования.
2. Создание моделей, адекватно отражающих объект предметную область,
возможно лишь при выполнении обязательных условий:
• IDEF0-диаграммы следует разрабатывать в точном соответствии с
IDEF0-методологией;
• при моделировании должен быть организован итеративный процесс
рецензирования каждого фрагмента модели и модели в целом;
• начинать следующий уровень декомпозиции можно лишь после полно-
го завершения работы над родительской диаграммой, т.е. после при-
своения ей статуса "Публикация" .
РД IDEF0 - 2000
60
12. Перспективы развития методологии функционального
моделирования
Из знакомства с IDEF0 следует, что эта методология представляет собой
четко формализованный подход к созданию функциональных моделей -
структурных схем изучаемой системы. Схемы строятся по иерархическому
принципу с необходимой степенью подробности и помогают разобраться в
том, что происходит в изучаемой системе, какие функции в ней выполняются
и в какие отношения вступают между собой и с окружающей средой ее
функциональные блоки. Совокупность схем (IDEF0 - диаграмм) образует
модель системы. Эта модель носит качественный, описательный, деклара-
тивный характер. Она принципиально не может ответить на вопросы о том,
как протекают процессы в системе во времени и в пространстве, каковы их
характеристики и в какой мере удовлетворяются (или не удовлетворяются)
требования, предъявляемые к системе. Все эти вопросы с неизбежностью
возникают после того, как достигнут нижний уровень декомпозиции, т.е.
обозначены « ... функции нижнего уровня, с помощью которых и работает
система»([ 3 ], стр. 141).
В этом случае рекомендуется переходить к другим моделям - математи-
ческим, имитационным моделям, описывающим процессы в функциональ-
ных блоках IDEF0 - модели . По терминологии, принятой в исследовании
операций, IDEF0 - модели относятся к классу концептуальных. Именно
концептуальные модели являются основой построения математических
моделей . Пытаться «нагрузить» концептуальную модель количественными
соотношениями не следует - это разные уровни абстракции. Видимо, этим
объясняется существование специальной методологии IDEF2, предназначен-
ной для моделирования динамических процессов в функциональных моде-
лях.
В отсутствии стандарта, регламентирующего применение методологии
IDEF2, целесообразно ставить вопрос о наполнении IDEF0 - структур коли-
чественным содержанием, т.е. о создании методики построения моделей,
адекватно описывающих процессы в изучаемой системе, в т.ч. и во времени,
в динамике
Описание и количественная оценка преобразований требуют создания
математических моделей, которые должны отображать (имитировать) физи-
ческие, экономические, организационные, финансовые, логические и т.п.
отношения между сущностями, входящими в IDEF0 – модель, разворачи-
вающиеся во времени.
Исходя из общих соображений, связанных с возможными областями при-
менения функционального моделирования и структурного анализа предпри-
ятий и организаций, можно указать несколько классов математических мо-
делей, которые найдут применение в качестве средств описания процессов и
РД IDEF0 - 2000 явлений, протекающих в IDEF0 - блоках. К их числу, в первую очередь, от-
носятся:
! распределительные модели теории исследования операций (оптималь-
ное распределение ресурсов);
! модели теории массового обслуживания (детерминированные и стати-
стические);
! модели теории управления запасами;
! транспортные модели ;
! динамические модели передачи сигналов (детерминированные и сто-
хастические);
! регрессионные и корреляционные прогностические модели (в т.ч. мо-
дели, предсказывающие вероятность возникновения редких событий);
! некоторые модели теории игр.
Распределительные модели могут найти применение в тех случаях, когда
требуется оптимальное распределение ресурсов, например, финансовых или
трудовых, необходимых для выполнения некоторого подмножества операций
IDEF0 - модели. Модели теории массового обслуживания и управления запа-
сами могут оказаться наиболее применимыми, поскольку многие процессы в
организационно – экономических и производственно-технических системах -
это процессы получения и обслуживания заявок на работы (услуги), а также
процессы накопления, расходования, хранения и пополнения запасов, причем
и те, и другие процессы необходимо вести с максимальной эффективностью.
Модели обслуживания позволяют оценивать производительность блоков,
выполняющих те или иные операции обработки (преобразования) матери-
альных и информационных объектов , определять реальную пропускную
способность каналов , по которым передаются эти объекты, выявлять узкие
места и резервы , оценивать зависимость производительности (пропускной
способности) от надежности элементов, а также от расходования ресурсов
(например, от текущих и капитальных затрат).Транспортные модели позво-
ляют не только оптимальным в каком-либо смысле образом планировать
перевозки грузов, но и в более общем случае управлять передачей матери-
альных или информационных объектов из пунктов их возникновения в пунк-
ты потребления или переработки. Динамические модели передачи сигналов
позволяют оценивать временные характеристики (запаздывания) передачи
информации и помехозащищенность информационных каналов. Наконец,
прогностические модели позволяют решать задачи оптимального планирова-
ния с учетом тенденций развития изучаемой системы и ее компонентов.
Модели теории игр могут использоваться в качестве средств поддержки
принятия решений при анализе структур, описываемых функциональными
моделями.
В качестве программной среды для реализации моделей можно использо-
вать любую среду, поддерживающую принципы объектно-ориентированного
РД IDEF0 - 2000 программирования и обеспечивающую событийное управление вычисли-
тельными процессами.
Литература.
1. INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEF0) . Draft Federal
Information Processing Standards Publication 183 ,1993 December 21
2. INTEGRATION DEFINITION FOR INFORMATION MODELING (IDEF1X), Draft Federal
Information Processing Standards Publication 184 1993 December 21.
3. Давид Марка, Клемент МакГоуэн, Методология структурного анализа и
проектирования. Пер. с англ. М.:1993, 240 с. , ISBN 5-7395-0007-9
4. Дружинин В.В., Конторов Д.С. Системотехника. – М.: Радио и связь. 1985,
- 200 с.

 
Rambler's Top100