Всё для Учёбы — студенческий файлообменник
1 монета
pdf

Студенческий документ № 049133 из МГИК (бывш. МГУКИ)

РД IDEF 0 - 2000

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

МОДЕЛИРОВАНИЯ IDEF0

Руководящий документ

Издание официальное

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

М о с к в а

Предисловие

1. РАЗРАБОТАН Научно-исследовательским Центром CALS - технологий "Прикладная Логистика"

ВНЕСЕН Научно-исследовательским Центром CALS - технологий "Прикладная Логистика"

2. ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России

от 2000 г. №

3. Настоящий Руководящий документ составлен по материалам Федерального стандарта США INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEF0) .

Draft Federal Information Processing Standards Publication 183 ,1993 December 21 и содержит основные сведения о методологии функционального моделирования IDEF0 , о ее графическом языке и методике построения и практического применения функциональных моделей организационно-экономических и производственнотехнических систем.

4 ВВЕДЕН ВПЕРВЫЕ

(c) ИПК Издательство стандартов, 2000

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

разрешения Госстандарта России

Содержание

Стр. 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

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

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

ЛИТЕРАТУРА 62

ПРИЛОЖЕНИЕ 1

ПРИЛОЖЕНИЕ 2

1. Введение

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

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

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

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

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

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

К настоящему времени наибольшее распространение и применение имеют методологии IDEF0 и IDEF1 (IDEF1X), получившие в США статус федеральных стандартов. [1 ,2 ].

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

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

• Язык обеспечивает точное и лаконичное описание моделируемых объектов, удобство использования и интерпретации этого описания.

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

• Язык прошел многолетнюю проверку и продемонстрировал работоспособность как в проектах ВВС США, так и в других проектах, выполнявшихся государственными и частными промышленными компаниями.

• Язык легок и прост в изучении и освоении.

• Язык может генерироваться рядом инструментальных средств машинной графики; известны коммерческие программные продукты, поддерживающие разработку и анализ моделей - диаграмм IDEF0, например, продукт Design/IDEF 3.7 (и более поздние версии) фирмы Meta Software Corporation (США).

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

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

2. Концепция IDEF0

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

2.1 Модель - искусственный объект, представляющий собой отображение

(образ) системы и ее компонентов. Согласно [ 3 ],

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

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

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

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

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

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

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

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

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

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

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

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 Интерфейс: разделяющая граница, через которую проходят данные или материальные объекты; соединение между двумя или большим числом компонентов модели, передающее данные или материальные объекты от одного компонента к другому.

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 )

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.

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

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

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

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

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

РАЗРАБОТАТЬ МОДЕЛЬ

1 • Имя функции -глагол или глагольный оборот

• Показан номер блока

Рис. 1.. 4.2 Стрелка.

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

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

Прямолинейный отрезок стрелки

• Ломаный сегмент стрелки. Дуга сопряжения -90 град.

Ветвление стрелок

• Слияние стрелок

Рис. 2.. 4.3.1 Блоки

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

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

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

4.3.2 Стрелки

1. Ломаные стрелки изменяют направление только под углом 90 град.

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

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

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

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

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

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

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

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

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

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

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

Рис.3. 5.2 Имена и метки.

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

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

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

Спецификации отчет об испытаниях бюджет

Конструкторские требования конструкция детали директива

Инженер-конструктор плата в сборе требования

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

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

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

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

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

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

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

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

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

Конструкторские

требования

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

4. Чтобы связать стрелку с меткой, следует использовать "тильду" ( ) .

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

функция, вход, управление, выход, механизм, вызов.

5.4 Диаграммы IDEF0.

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

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

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

программистов ЦЕЛЬ: оценка трудоемкости, планирование, организация информационного потока, определение функций менеджера проекта. ТОЧКА ЗРЕНИЯ: Служба информационной интеграции QA/A-0 Управлять информационными ресурсами Рис.5.

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

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

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

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

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

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

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

Более общее представление

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

MFG/A61 Рис. 7

Таким образом, код формируется так:

А 6 1 * * * *

| | | | |__________ и т.д.

| | | |___________ Номер блока на диаграмме А61 | | |_____________Номер блока на диаграмме А6

| |______________ Номер блока на диаграмме А0

|________________ Имя блока А0

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

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

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

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

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

Диаграмма FEO не должна подчиняться синтаксическим правилам IDEF0.

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

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

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

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

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

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

обеспечивает работу функций 2 и3

tl а) б)

Рис.9. 6.3 Ветвление и слияние сегментов стрелок

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

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

Рис.10.

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

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

в общей метке стрелки после слияния (рис.12;

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

Рис.13.

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

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

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

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

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

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

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

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

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

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

Рис. 14.

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

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

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

Рис. 16. Рис.17.

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

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

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

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

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

Рис. 20. 7.2 ICOM - кодирование граничных стрелок.

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

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

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

Рис. 21.

7.3 Стрелки , помещенные в "туннель" .

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

Рис.22

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

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

Рис.23

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

Рис. 24 8. Правила построения диаграмм

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 25.

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

Рис.26

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

а) б) в)

Рис.27.

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

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

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

Рис. 29

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

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

Рис. 31 Рис. 32

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

Рис.33

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

Рис. 34

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

Рис. 35

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

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

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

9.1. Номера блоков.

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

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

9.2 Узловые номера.

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

Контекстные диаграммы и дочерняя диаграмма верхнего уровня - исключения в вышеуказанной схеме узловой нумерации. Каждая модель IDEF0 имеет контекстную диаграмму верхнего уровня - диаграмму A-0. Эта диаграмма содержит единственный "высший блок", который является уникальным родителем всей модели и несет уникальный номер 0 (нуль) и узловой номер A0. Каждая модель IDEF0 должна также иметь по крайней мере одну дочернюю диаграмму, содержащую декомпозицию блока А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.

A0 Производить продукт A1 Планировать производство

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

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

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

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

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

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

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

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

A24 Следить за выполнением графика и расходом ресурсов A3 Планировать выпуск продукции

Рис. 36.

9.4 Дерево узлов.

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

Рис. 37.

10. Методика разработки функциональных моделей среде IDEF 0.

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

10.1 Общие положения.

Как уже отмечалось во Введении, объектами функционального моделирования и структурного анализа по методологии IDEF0 являются организационно-экономические и производственно-технические системы. Согласно основным положениям системного анализа и системотехники [ 4 ] системой называется совокупность взаимодействующих объектов любой, в том числе различной, физической природы, обладающая выраженным системным свойством (свойствами), т.е. свойством, которого не имеет ни одна из частей системы при любом способе членения, и не выводимым из свойств частей. Части системы, обладающие собственными системными свойствами, называются подсистемами. Объединение нескольких систем, обладающее системным свойством, называют надсистемой или системой более высокого (2-го, 3-ьего и т.д.) порядка. Элементом системы является объект с однозначно определенными известными свойствами, вытекающими из физических или экономических законов.

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

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

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

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

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

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

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

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

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

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

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

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

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

Ограничитель-

Ресурсы Оборудование, персонал

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Организационно - техническая система Деятельность

Организационно - техническая подсистема Процесс

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

Организационно - технический блок Действие

Рис. 39.

Используя приведенные выше понятия системного анализа, определим элементы иерархии механизмов следующим образом.

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

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

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

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

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

О

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

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

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

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

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

Один из общих принципов методологии IDEF 0 требует, чтобы к каждому блоку на диаграмме должна быть присоединена хотя бы одна управляющая стрелка, отображающая условия правильного функционирования блока ( см. разд. 8). Это требование есть следствие положения системотехники, согласно которому управление есть такое воздействие ( преимущественно информационное) на систему, которое стимулирует ее функционирование в направлении достижения некоторой цели [4 ]. В связи с этим можно сформулировать ряд определений и методических положений, которыми следует руководствоваться при отражении управлений на функциональных моделях.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.5 Типизация функциональных моделей и IDEF 0- диаграмм.

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

Рис. 41. Фрагмент типовой модели промышленного предприятия в формате IDEF0 дан в Приложении 2 .

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

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

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

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

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

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

Рис.42.

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

Эта приемлемость достигается следующими путями:

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

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

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

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

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

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

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

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

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

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

• Авторы (разработчики) модели.

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

• Эксперты в предметной области.

• Библиотекарь.

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

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

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

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

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

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

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

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

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

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

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

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

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

ботчик создает модель на основе материала, собранного из источников информации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Эксперты - рецензенты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

моделирования

Из знакомства с IDEF0 следует, что эта методология представляет собой четко формализованный подход к созданию функциональных моделей структурных схем изучаемой системы. Схемы строятся по иерархическому принципу с необходимой степенью подробности и помогают разобраться в том, что происходит в изучаемой системе, какие функции в ней выполняются и в какие отношения вступают между собой и с окружающей средой ее функциональные блоки. Совокупность схем (IDEF0 - диаграмм) образует модель системы. Эта модель носит качественный, описательный, декларативный характер. Она принципиально не может ответить на вопросы о том, как протекают процессы в системе во времени и в пространстве, каковы их характеристики и в какой мере удовлетворяются (или не удовлетворяются) требования, предъявляемые к системе. Все эти вопросы с неизбежностью возникают после того, как достигнут нижний уровень декомпозиции, т.е. обозначены " ... функции нижнего уровня, с помощью которых и работает система"([ 3 ], стр. 141).

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

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

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

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

* распределительные модели теории исследования операций (оптимальное распределение ресурсов);

* модели теории массового обслуживания (детерминированные и статистические);

* модели теории управления запасами;

* транспортные модели ;

* динамические модели передачи сигналов (детерминированные и стохастические);

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

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

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

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

Литература.

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 с.

РД IDEF0 - 2000

РД IDEF0 - 2000

4

5 РД IDEF0 - 2000

РД IDEF0 - 2000

2 2 РД IDEF0 - 2000

2

Номер: 1

Заголовок: Управлять

Заголовок:

Заголовок:

Заголовок:

Заголовок:

Показать полностью…
994 Кб, 1 ноября 2016 в 21:45 - Россия, Москва, МГИК (бывш. МГУКИ), 2016 г., pdf
Рекомендуемые документы в приложении