Для того чтобы поближе познакомится со стандартом IDEF0, о нем необходимо узнать следующее:

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

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

Методология IDEF0 незначительно отличается от классической схемы описания бизнес-процессов DFD. Основным отличием является классификация входов работы.

Классификация входов и выходов работ

Стандарт предлагает следующую типизацию входов работ:

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

Основные элементы диаграммы:

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

Элемент	Графическое отображение и значение	Требования к оформлению
Функциональный блок	Изображается в виде прямоугольника. Представляют функции, определяемые как деятельность, процесс, операция, действие или преобразование.	1. Должен иметь уникальный идентификационный номер в правом нижнем углу; 2. Название должно быть в отглагольном наклонении.
Интерфейсная дуга (стрелка, дуга)	Изображается в виде однонаправленной стрелки. Представляют данные или материальные объекты, связанные с функциями.	1.Должна иметь уникальное наименование. 2.Наименование должно быть оборотом существительного. 3.Началом и концом дуги могут быть только функциональные блоки. 4.Источником может быть только выходная сторона блока, а приемником любая из трех оставшихся.

IDEF0 — модель:

Модель включает следующие документы, которые ссылаются друг на друга:

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

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

Принцип декомпозиции при построении модели бизнес процессов

1. Контекстная диаграмма: цель и точка зрения

Моделирования бизнес процесса начинается с контекстной диаграммы. Эта диаграмма называется А–0 (А минус ноль). На ней система представляется в виде одного блока и дуг, изображающих окружение системы. С помощью диаграммы можно увидеть взаимодействие моделируемой системы с внешней средой, все ее входы и выходы. Диаграмма А–0 устанавливает область моделирования и границы.

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

2. Детализация

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

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

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

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

Принцип туннелирования

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

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

Принцип ограничения сложности

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

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

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

Количественный анализ диаграмм: коэффициент сбалансированности и оценка имен

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

• количество блоков на диаграмме — N;
• уровень декомпозиции диаграммы — L ;
• сбалансированность диаграммы — В;
• число стрелок, соединяющихся с блоком, — А.

Коэффициент сбалансированности

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

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

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

Введем коэффициент сбалансированности диаграммы:

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

Оценка имен

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

Например, для модели БД элементарными могут являться функции «найти запись», «добавить запись в БД», в то время как функция «регистрация пользователя» требует дальнейшего описания.

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

Коэффициент, количественно отражающий данный критерий, можно записать как:

L*C

— произведение уровня модели на число совпадений имен блоков со словами из словаря. Чем ниже уровень модели (больше L), тем ценнее совпадения.

1. Функциональное моделирование информационной системы с использованием CASE-технологии IDEF.
2. Описание логики взаимодействия и последовательности выполнения работ.

2. План занятия

1. Контроль знаний путем тестирования (тест ИСЭ002).
2. Разработка многоуровневой модели деятельности информационной системы (модель AS - IS) с помощью CASE-средства BPwin с использованием технологий IDEF 0 и IDEF 3 :
   • Описание свойств модели (Model Properties).
   • Создание ПЕРВОГО уровня функциональной модели – разработка контекстной диаграммы.
   • Создание ВТОРОГО уровня функциональной модели – проведение детализации контекстной работы и разработка диаграммы декомпозиции.
   • Создание ТРЕТЬЕГО уровня функциональной модели – проведение детализации работы второго уровня, реализующей функцию Учет деятельности организации. Выполнение данного этапа разработки допускает создание диаграммы декомпозиции с использованием одной из двух методологий – IDEF 0 (1-й вариант) или IDEF 3 (2-й вариант). По 2-му варианту создание сценария и диаграммы последовательности выполнения отдельных работ (Workflow Diagram) в процессе учета деятельности выполняется с использованием методологии IDEF 3.
3. Разработка словаря работ и словаря стрелок, которые позволяют отобразить описание соответствующих фрагментов модели.

1. Функциональное моделирование информационной системы с использованием технологии IDEF необходимо проводить, используя CASE-средство BPwin , которое загружается командой Пуск/Программы/Computer Associates/BPwin 4.0/BPwin4.0 . Технологические процессы IDEF-моделирования изложены в разделе 4 «Теоретические сведения к практическому занятию».
2. Разрабатывая контекстную диаграмму, следует учитывать, что свойства модели можно оформить следующим образом, используя сведения соответствующие моделируемой предметной области:
   • Model Name : Деятельность фирмы «Имя»;
   • Project (название проекта): Модель деятельности фирмы «Имя»;
   • ФИО, группа;
   • Scope (область моделирования, включающая цель моделирования, т.е. вопросы, на которые построенная модель должна дать ответ) – например, «Общее управление бизнесом компании: исследование рынка, закупка компонентов, тестирование и продажа продукции» или «Технологические, финансовые и управленческие аспекты деятельности фирмы»;
   • Time Frame (тип модели) : AS-IS;
   • Definition (определение , назначение модели) : Учебная модель, описывающая деятельность фирмы «Имя»;
   • Viewpoint (точка зрения – лицо, чья точка зрения принята при разработке) : Руководитель предприятия и главный менеджер;
   • Status : WORKING;
   • Purpose (цель) : Моделировать текущие бизнес-процессы фирмы «Имя» с целью регламентации ее деятельности;
   • Source (источник информации) : Анализ предметной области и анализ входных документов;
   • Author Name : ФИО.
3. При выполнении декомпозиции контекстной диаграммы следует учитывать, что она, являясь вторым уровнем декомпозиции модели системы, представляет собой подпроцесс или дочернюю работу , реализованную в виде контекстной работы, которая в этом случае выступает как родительская работа , реализованная в виде родительской диаграммы (Parent Diagram ) . Диаграмма декомпозиции второго уровня должна содержать не менее трех функциональных блоков, один из которых должен выполнять функцию моделирования учета деятельности организации, а остальные должны выполнять функцию моделирования бизнес-процессов , реализуемых в системе.
4. На каждом шаге декомпозиции следует следить за процессом автоматического перемещения интерфейсных дуг (стрелок) на нижние уровни модели и стараться без необходимости не допускать создания туннелированных стрелок. В случае их появления следует убирать туннели.
5. При реализации третьего уровня декомпозиции следует учитывать, что каждая из разработанных диаграмм декомпозиции является третьим уровнем декомпозиции работ второго уровня и представляет собой подпроцесс или дочернюю работу, реализованную в виде дочерней диаграммы (Child Diagram) соответствующей работы третьего уровня. Все работы второго уровня в этом случае выступают как родительские работы , реализованные в виде родительских диаграмм (Parent Diagrams ).
6. Декомпозицию работы второго уровня, моделирующей функцию учета, и создание сценария взаимодействия работ следует выполнять, используя технологию IDEF 3, которая использует в качестве функциональных блоков единицы работы (Unit of Work, UOW ) , а также и необходимые объекты ссылок (Referents) , которые могут быть как внедрены в сценарий из словаря стрелок, так и созданы заново.
7. Словарь работ и словарь стрелок создаются на каждом уровне декомпозиции модели, причем необходимым условием их разработки является наличие описания работы (activity) и описания данных, зафиксированных на интерфейсной дуге (arrow ) .
8. Результаты работы сохранить в файле Функц_модель ИС_Имя_ IDEF.bp1 в своей папке ИСЭ .
9. Пример обобщенной функциональной модели приведен в

4. Теоретические сведения к практическому занятию

4.1. IDEF 0-технология

Методология IDEF0 предназначена для моделирования деятельности организации. На начальном этапе разработки проекта создается модель, предназначенная для описания существующих бизнес-процессов и технологических процессов на предприятии по принципу «AS - IS» («Как есть»), причем, что немаловажно, она представляет предприятие с позиции сотрудников, которые на нем работают и досконально знают все нюансы, в том числе и неформальные. AS-IS – «что мы делаем сегодня», перед тем, как перепрыгнуть на то, «что мы будем делать завтра».

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

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

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

Функциональный блок

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

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

• Верхняя сторона – управление.
• Нижняя сторона – механизм.
• Правая сторона – выход.
• Левая сторона – вход.

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

Интерфейсная дуга

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

Имя стрелки указывает ее роль (совокупность возможных ролей обозначается – ICOM ):

Вход функционального блока – I nput .

Управление – C ontrol .

Выход функционального блока – O utput .

Механизм – M echanism .

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

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

Часто сложно определить, являются ли данные входом или управлением. Если данные в работе изменяются или перерабатываются, то это, скорее всего, вход, а если нет – управление. Если определить статус стрелки сложно, рекомендуется рисовать стрелку управления.

Выход (Output) – материал или информация, которые производятся работой. Обязательна хотя бы одна стрелка выхода, исходящая из правой грани работы.

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

На рис. 2.1 все интерфейсные дуги показаны в виде поименованных стрелок. По требованиям стандарта каждый функциональный блок должен иметь по крайней мере один выход и одно управление, так как каждая задача (процесс) должны иметь хотя бы один выход и хотя бы одно правило ее решения. Интерфейсная дуга «Механизм» может не изображаться.

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

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

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

Создание диаграмм в технологии IDEF0

При разработке модели деятельности организации следует использовать три типа диаграмм:

• I тип диаграммы – Контекстная диаграмма (может быть только одна) – вершина древовидной структуры, которая представляет собой наиболее абстрактный уровень описания системы и ее взаимодействие с внешней средой. В ней определена контекстная функция ;
• II тип диаграммы – Диаграмма декомпозиции .

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

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

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

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

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

4.2. Технологический процесс IDEF0-моделирования:

Рис. 2.2

CASE-средство BPWin имеет простой и понятный пользовательский интерфейс для построения требуемых функциональных моделей и сценариев. Он зависит от используемой технологии. На рис. 2.2 показано окно BPWin (Computer Associates BPWin ).

Основная панель инструментов окна Computer Associates BPwin содержит следующие кнопки:

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

Навигатор модели показывает состав модели по уровням разработки. С его помощью можно легко и быстро переходить с уровня на уровень. Работа с навигатором модели аналогична работе с Проводником системы Windows.

Панель специальных инструментов содержит следующие основные кнопки:

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

Подготовка модели

1. Нажать кнопку создания модели для вызова окна диалогового окна BPWin (рис. 2.3):

В диалоговом окне BPWin произвести следующие действия:

• выбрать Business Process (IDEF0) ;
• задать имя модели и нажать кнопку ОК ;
• в окне Properties for New Model зафиксировать фамилию автора модели;
• нажать кнопку ОК .

1. Командой Model/Model Properties вызвать диалоговое окно Model Properties (рис. 4), в котором оформить свойства модели в соответствии с методическими рекомендациями, изложенными в разделе 2.

Первый уровень моделирования

1. Оформить функциональный блок в окне модели, выполнив следующие действия:
   • в контекстном меню функционального блока выбрать команду Name … ;
   • в диалоговом окне Activity Properties (рис. 2.5) в закладке Name задать имя работы (краткое), помещаемой в данный функциональный блок, а в закладке Definition в поле Definition описание работы;
   • в закладке Font задать шрифт Arial Cyr и установить флажки, позволяющие использовать этот шрифт во всех функциональных блоках диаграммы (All activities in this diagram, All activities in this model и Change all occurrences of this font in the model ), после чего нажать кнопку ОК .

• в диалоговом окне Arrow Properties (рис. 2.7), в закладке Name задать имя стрелки (краткое), а в закладке Definition в поле Definition вписать достаточно подробное описание назначения этой стрелки;

• в контекстном меню стрелки выбрать команду Font … ;
• в диалоговом окне Arrow Properties (рис. 2.8), в закладке Font задать шрифт Arial Cyr и установить флажки, позволяющие использовать этот шрифт для всех стрелок диаграммы (All Arrows in this diagram, All Arrows in this model, All instances of this Arrow и Change all occurrences of this font in the model );

1. Оформить стрелку Выход, левые границы правыми ;
2. Оформить стрелку Управление , для чего повторить п. 2, заменив левые границы верхними ;
3. Оформить стрелку Механизм, для чего повторить п. 2, заменив левые границы нижними .

Второй уровень моделирования

Любой уровень моделирования

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

• активизировать щелчком конкретный функциональный блок;
• повторить п. 3 для текущего уровня модели.

1. Тип и стиль оформления стрелки можно выбрать в диалоговом окне Arrow Properties (рис. 2.9), вызываемом командой Style из контекстного меню стрелки.

1. Для установки переноса по словам следует, выделив название, уменьшить размер прямоугольника, после чего он автоматически увеличится книзу.
2. Каждая стрелка, нарисованная на диаграмме высшего уровня, должна обязательно присутствовать на диаграмме более низкого уровня.
3. Новая стрелка, нарисованная на диаграмме низкого уровня (неразрешенная (unresolved ) стрелка), помещается в квадратные скобки (туннели), которые подчеркивают отсутствие такой стрелки на более высоком уровне. Чтобы убрать туннели следует:
   • выбрать пункт меню Arrow Tunnel ;
   • в диалоговом окне Border Arrow Editor (Редактор граничных стрелок) выбрать опцию Resolve it to Border Arrow (Разрешить как граничную стрелку). В результате туннель на текущем уровне будет убран, а стрелка появится на предыдущем уровне, причем если он не первый, то она – туннелированная (рис. 2.10).

1. Чтобы копировать туннелированные стрелки с нижнего уровня на верхний следует:
   • щелкнуть правой клавишей мыши по квадратным скобкам;
   • выбрать пункт меню Off Page Reference ;
   • в диалоговом окне Off_Page Arrow Reference выбрать диаграмму, на которую следует поместить стрелку и установить требуемый переключатель типа стрелки (рис. 2.11);

• нажать одну из кнопок: ОК and Go To Diagram (перейти к выбранной диаграмме) или ОК and Remain In Current Diagram (остаться в текущей диаграмме).

Недопустимо оставление несвязанных граничных стрелок (unconnected border arrow ) – стрелок, автоматически переносимых в диаграмму декомпозиции из родительской диаграммы (режим миграции стрелок). Эти стрелки не касаются работ и должны быть связаны с работами в режиме Создание стрелок (Precedence Arrow Tool – ).

Оформление правильного расположения и начертания стрелок по умолчанию:

• выполнить команду Model/Model Properties ;
• в окне Model Properties (рис. 2.12) выбрать закладку Layout ;
• установить флажок (опцию) Automatically space arrows в группе Arrows

1. При создании стрелки обратной связи по управлению следует установить опцию указания направления стрелки Extra Arrowhead (из контекстного меню).
2. Если надписи на стрелках расположены неудачно (очень далеко и т. п.), следует установить флажок Squiggle (в контекстном меню) для выноски надписи.

1. В диаграмме декомпозиции слева вверху располагается функциональный блок, в котором помещается наиболее важная и выполняемая первой работа. Последовательно вниз идут работы менее важные или выполняемые позже.
2. Перенос по словам внутри работ производится в режиме Name Editor … нажатием клавиши Enter .
3. Диагональ в левом верхнем углу прямоугольника означает, что соответствующая работа не декомпозирована.
4. Чтобы показать не только номера дочерних работ, которые появляются автоматически, но и префиксы (А), следует выбрать команду Model/Model Properties, закладку Numbering, флажок (опция) Show prefix (рис. 2.13).

1. Чтобы у дочерних работ показать номера работ и номера уровней (двух-, трех-, четырехзначные номера) следует выбрать команду Model/Model Properties, закладку Numbering, флажок (опция) Use diagram numbering format (рис. 2.13).
2. Чтобы различить разные версии одной и той же диаграммы, отдельным версиям следует присвоить номера (C - number), задаваемые произвольно в меню Diagram Properties на закладке Kit.

Построение дерева модели

• командой Diagramm/Add/Node Tree вызвать диалоговое окно Node Tree Wizard_Step 1 of 2 (рис. 2.14);
• провести диалог, выбрав нужное количество уровней дерева узлов (Number of levels );
• нажать кнопку Готово.

4.3. IDEF3-технология

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

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

Технология IDEF3 предназначена для обеспечения сбора данных о процессе и позволяет:

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

Сценарий в IDEF3-технологии

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

При использовании IDEF3-технологии в основе всех построений лежат два типа диаграмм:

1. Диаграмма описания последовательности этапов процесса.
2. Диаграмма состояний объекта.

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

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

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

Символ J перекрестка может принимать одно из следующих значений:

• & – слияние результатов всех действий, если стрелки входят в перекресток; запуск всех действий, если стрелки выходят из него;
• О – слияние результатов действий, если хотя бы одно из входных действий завершено; запуск хотя бы одного действия;
• Х – слияние только одного действия из ряда входящих в перекресток; запуск только одного действия из выходящих из него.

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

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

	Работа 3 происходит, когда выполнены Работа 1 и Работа 3
	Работа 1 и Работа 2 происходят вместе
	Работа 3 происходит, когда выполнены Работа 1 или Работа 2, или обе вместе
	Работа 1 и Работа 2 происходят вместе или отдельно
	Работа 3 происходит, когда выполнены Работа1 или Работа 2
	Происходит Работа 1 или Работа 2

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

4.4. Технологический процесс IDEF3-моделирования

Подготовка модели

1. Нажать кнопку создания модели.
2. В диалоговом окне BPWin выполнить следующие действия:
   • выбрать Process Flow (IDEF3) ;
   • задать имя модели;
   • нажать кнопку ОК ;
   • в диалоговом окне Properties for New Model подтвердить указанные там свойства.

Оформление действия

1. Нажать кнопку создания действия (Activity Box Tool ).
2. В нужном месте окна модели щелкнуть левой клавишей мыши.
3. В контекстном меню действия выбрать команду Name …
4. В диалоговом окне Activity Properties , в закладке Name задать имя действия (рис. 2.16).

1. В диалоговом окне Activity Properties в закладке Font задать Arial Cyr, ОК .

Оформление данных

1. Нажать кнопку создания данных. (Referent Tool ).
2. В нужном месте окна Referent щелкнуть левой клавишей мыши, чтобы внедрить имена данных из созданного словаря сущностей (опция Entity ) или из созданного словаря стрелок (опция Arrow ), или создать их заново (опция Other ) (рис. 2.17).

1. В диалоговом окне Referent Properties (рис. 2.18), в закладке Font задать Arial Cyr установить нужные флажки и нажать кнопку ОК .

5. Домашнее задание к следующему занятию

1. Продумать и определить материальные объекты или физические лица, представляющие собой источники или приемники информации (внешние сущности).
2. Продумать и разработать реляционную модель данных, обрабатываемых информационной системой:
   • составить список сущностей и их атрибутов,
   • показать отношения между сущностями.
3. На основе разработанного технического задания продумать и предложить преподавателю названия отдельных работ, реализуемых в системе в процессе выполнения каждой из ключевых работ, помещенных в диаграмму декомпозиции второго уровня.
4. Выполнение п.п. 1–3 домашнего задания зафиксировать в файле с именем «Информация ко 3-му занятию.doc », выполненном в Word, и представить преподавателю.
5. Проработать раздел «Теоретические сведения к практическому занятию » практикума по 3-му занятию.

1.6. Фрагмент диаграммы дерева узлов (Node Tree Diagram) при выполнении декомпозиции блока учет деятельности по второму варианту (IDEF3)

Словарь работ (Activity Dictionary)

Name	Definition
	Анализ информации, считанной из БД, на удовлетворение заданным критериям
Анализ документов	Анализ сопроводительных и входящих документов на соответствие нормативам
Ведение БД	Выполнение операций обновления данных
ВЫПОЛНЯЕМАЯ РАБОТА	Имя контекстной функции, определяющей ЦЕЛЬ и ГРАНИЦЫ моделирования
Завершающая обработка	Принятие и формулировка решения (ПОЛОЖИТЕЛЬНОГО в случае удовлетворения данных заданным критериям и ОТРИЦАТЕЛЬНОГО в противном случае), а также со­здание и оформление необходимых документов
Контроль качества и тестирование	Работа, завершающая производственный процесс или процесс разработки
Обработка данных	Выполнение операций поиска и анализа данных и принятие решения на основе проведенного анализа
Обработка результатов контроля качества	Систематизация и анализ результатов на соответствие стандарту
Обработка результатов тестирования	Анализ результатов на исправность, надежность и живучесть
Оформление документов	Прием документов и выбор информации для занесения в базу данных
	Поиск данных в таблицах БД на основе запросов, созданных пользователем
Пополнение БД	Занесение новых данных в таблицы БД
Прием и регистрация документов	Прием и регистрация входящих сопроводительных документов
Производство или разработка	Наименование ключевого бизнес процесса компании (модель производственной части предметной области)
Работа на 1-м этапе бизнес-процесса1	Действие, обобщающее технологические операции на первой стадии производственного процесса
Работа на 2-м этапе бизнес-процесса1	Действие, обобщающее технологические операции на второй стадии производственного процесса
Работа на 3-м этапе бизнес-процесса1	Действие, обобщающее технологические операции на третьей стадии производственного процесса
Обработка результатов производственной деятельности	Прием и анализ документов по результатам выполнения текущих работ и контроля
Редактирование БД	Изменение записей в таблицах БД
УЧЕТ ДЕЯТЕЛЬНОСТИ	Обработка документации и ведение отчетности (модель непроизводственной части предметной области)

Словарь стрелок (Arrow Dictionary)

Name	Definition
	Объекты, не соответствующие требованиям стандарта
ВХОДНЫЕ ДАННЫЕ	Входящие документы и объекты обработки
Входные данные БД	Данные для записи в таблицы БД
Входящие документы	Документы, сопровождающие объекты обработки и документы, инициирующие бизнес-процесс
ВЫХОДНЫЕ ДАННЫЕ	Выходящие документы, новые и измененные объекты
Выходящие документы	Документы (бланки, отчеты, инструкции, ведомости, договора и т. п.), создаваемые в процессе учета
Государственный стандарт	Государственный стандарт на оформление документации
Данные таблиц БД	Данные, считываемые из таблиц БД
Данные, полученные в результате анализа	Информация, предназначенная для оформления выходящих документов и используемая при принятии решения
Данные, характеризующие результаты работы с документами	Информация, отражающая реквизиты (качественные и количественные характеристики) обрабатываемых объектов
Документы по результатам тестирования и контроля	Документы, отражающие данные, полученные на этапе завершающей стадии обработки объектов
Должностная инструкция	Инструкция, отражающая должностные обязанности исполнителя
Запросы пользователя
Новые и измененные объекты	Объекты, созданные и измененные в процессе реализации производственного цикла
Объекты БД	Таблицы, формы, запросы, отчеты, макросы и модули
Объекты обработки	Объекты, изменяемые на разных стадиях исполнения производственного процесса
Объекты, обработанные на 1-м этапе	Объекты, изменяемые на 1-м этапе производственного процесса
Объекты, обработанные на 2-м этапе	Объекты, изменяемые на 2-м этапе производственного процесса
Объекты, обработанные на 3-м этапе	Объекты, изменяемые на 3-м этапе производственного процесса
	Отдел технического контроля, проверяющий создаваемый объект на удовлетворение требованиям стандарта
Подразделения компании и специалисты-профессионалы	Субъекты, участвующие в производственном процессе или в процессе разработки
ПРАВИЛА ВЫПОЛНЕНИЯ	Правила преобразования процессов и данных
Правила учета	Система учета и оформления документации, сопровождающей производственный процесс или процесс разработки
ПРИНЯТОЕ РЕШЕНИЕ	Положительное или отрицательное решение, принимаемое в зависимости от удовлетворения анализируемых данных заданным критериям
Принятые документы	Документы, прошедшие регистрацию
Программное обеспечение	Платформа, на базе которой реализована разрабатываемая БД
Результаты анализа документов	Результаты, полученные после анализа входящих и сопроводительных документов на соответствие нормативам
Результаты контроля качества
Результаты поиска	Информация из таблиц БД, полученная по запросам пользователя
Результаты тестирования	Данные, полученные на завершающем этапе обработки
Руководство пользователя	Инструкции и правила для работы с БД
Служба учета	Подразделения, занятые процессом учета и оформления документации
Сопроводительные документы	Документы, сопутствующие входящим объектам обработки
Специалисты- профессионалы	Субъекты, участвующие в производственной деятельности
Технологическая инструкция	Последовательность операций технологического процесса
Запросы пользователя	Запросы, создаваемые пользователем для выборки необходимой информации из БД и для создания выходящих документов
МЕХАНИЗМ ИСПОЛНЕНИЯ	Ресурсы, выполняющие преобразование входных данных в выходные
Новые записи	Записи в таблицах БД, появившиеся после занесения новых данных
Коррекция
	Субъект, производящий экспертизу

Версия для печати

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

При построении модели должна быть поставлена цель моделирования, отвечающая на следующие вопросы:

· почему этот процесс должен быть смоделирован?

· что должна показывать модель?

· что может получить читатель?

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

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

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

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

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

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

Рис. 1. Контекст IDEF0.

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

В IDEF0 различают пять типов стрелок:

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

2. Управление - правила, стратегии, процедуры или стандарты, которыми руководствуется блок. Управление влияет на блок, но не преобразуется им.

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

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

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

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

1. Связь по входу - стрелка выхода вышестоящего блока направляется на вход нижестоящего (рис. 2).

Рис. 2. Отношение «выход-вход».

2. Связь по управлению - выход вышестоящего блока направляется на управление нижестоящего (рис. 3).

Рис. 3. Отношение «выход-управление».

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

Рис. 4. Обратная связь по управлению

4. Обратная связь по входу - выход нижестоящего блока направляется на вход вышестоящего (рис. 5).

Рис. 5. Отношение обратной связи по входу

5. Связь выход-механизм - выход одного блока направляется на механизм другого (рис. 6).

Рис. 6 Связь «выход-механизм».

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

Рис. 7 Пример контекстной диаграммы IDEF0.

После чего проводится функциональная декомпозиция (рис.8) – этот блок деятельности (большой процесс) подразделяется на крупные подпроцессы – и каждый подпроцесс описывается отдельно (диаграммы декомпозиции). Затем каждый подпроцесс декомпозируется на более мелкие - и так далее до достижения необходимой детализации описания.

Рис.8 Пример диаграммы декомпозиции IDEF0.

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

Определение

IDEF 0 (Integration Definition for Function Modeling) – методология функционального моделирования для описания функций предприятия, предлагающая язык функционального моделирования для анализа, разработки, реинжиниринга и интеграции информационных систем бизнес процессов; или анализа инженерии разработки ПО (or software engineering analysis).

Методология IDEF0 является развитием метода структурного анализа и проектирования SADT (Structured Analysis and Design Technique).

IDEF0 как стандарт был разработан в 1981 году в рамках программы ICAM (Integrated Computer Aided Manufacturing – интегрированная компьютерная поддержка производства).

IDEF 0 – Integration DEFinition language 0 – основан на SADT и в своей исходной форме включает одновременно: определение языка графического моделирования (синтаксис и семантику) и описание полной (comprehensive) методологии разработки моделей.

Последняя редакция IDEF0 была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).

В 1993 году IDEF0 была принята в качестве федерального стандарта в США, а в 2000 году – в качестве стандарта в Российской Федерации.

Применение IDEF0

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

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

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

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

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

Цели стандарта IDEF0

Основные цели (objectives) стандарта:

задокументировать и разъяснить технику моделирования IDEF0 и правила ее использования;

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

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

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

общий (generic) – для анализа систем и предметных областей;

строгий и точный (rigorous and precise) – для создания корректных, пригодных к использованию моделей);

краткий (concise) – для облегчения понимания, коммуникации, согласия между заинтересованными лицами и проверки. (to facilitate understanding, communication, consensus and validation);

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

гибкий ­– для поддержки различных фаз жизненного цикла проекта.

Строгость и точность (Rigor and Precision)

Правила IDEFØ требуют достаточной строгости и точности для удовлетвроения нужд без чрезмерных ограничений аналитика (to satisfy needs without overly constraining the analyst). IDEFØ правила включают следующее:

управление детализацией (control of the details communicated at each level) – от трех до шести функциональных блоков на каждом уровне декомпозиции;

связанный контекст (Bounded Context) – не должно быть недостающийх или лишних, выходящих за установленные рамки деталей;

связанность интерфейса диаграмм (Diagram Interface Connectivity) – номера узлов, функциональных блоков, C-numbers и Detail Reference Expression);

связанность структуры данных. (Data Structure Connectivity) – ICOM codes and the use of parentheses;

уникальные метки и заголовки (Unique Labels and Titles) – отсутствие повторяющихся названий;

синтаксические правила для графики (Syntax Rules for Graphics) – функциональные блоки и стрелки;

ограничения на разветвления стрелок данных (Data Arrow Branch Constraint) – метки для ограничений потоков данных на разветвлениях;

разделение данных на Вход и Управление (Input versus Control Separation) – правило для определения роли данных);

маркировка стрелок данных. Data Arrow Label Requirements (minimum labeling rules);

наличие Управления (Minimum Control of Function) – все функции должны иметь минимум одно Управление;

цель и точка зрения (Purpose and Viewpoint) – все модели имеют формулировку цели и точки зрения.

Основные понятия IDEF0

В основе методологии лежат четыре основных понятия:

функциональный блок;

интерфейсная дуга;

декомпозиция;

глоссарий.

Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы.

По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги»).

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

верхняя сторона имеет значение «Управление» (Control);

левая сторона имеет значение «Вход» (Input);

правая сторона имеет значение «Выход» (Output);

нижняя сторона имеет значение «Механизм» (Mechanism).

Рис. Функциональный блок

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

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

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

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

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

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

Последним из понятий IDEF0 является глоссарий (Glossary).

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

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

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

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

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

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

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

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

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

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

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

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

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

IDEF0 - методология функционального моделирования

В ходе реализации программы интегрированной компьютеризации производства (ICAM), предложенной в свое время ВВС для аэрокосмической промышленности США, была выявлена потребность в разработке методов анализа взаимодействия процессов в производственных системах. Для удовлетворения этой потребности была разработана методология IDEF0 (Integrated Definition Function Modeling), которая в настоящее время принята в качестве федерального стандарта США. Методология успешно применялась в самых различных отраслях, продемонстрировав себя как эффективное средство анализа, проектирования и представления деловых процессов. В настоящее время методология IDEF0 широко применяется не только в США, но и во всем мире. В России IDEF0 успешно применялся в государственных учреждениях (к примеру, в Государственной Налоговой Инспекции), в аэрокосмической промышленности (при проектировании космодрома в Плесецке), в Центральном Банке и коммерческих банках России, на предприятиях нефтегазовой промышленности и предприятиях других отраслей.

Основные понятия IDEF0

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

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

Принципы моделирования в IDEF0

В IDEF0 реализованы три базовых принципа моделирования процессов:

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

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

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

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

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

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

Применение IDEF0

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

Построение модели КАК ЕСТЬ . Обследование предприятия является обязательной частью любого проекта создания или развития корпоративной информационной системы. Построение функциональной модели КАК ЕСТЬ позволяет четко зафиксировать, какие деловые процессы осуществляются на предприятии, какие информационные объекты используются при выполнении деловых процессов и отдельных операций. Функциональная модель КАК ЕСТЬ является отправной точкой для анализа потребностей предприятия, выявления проблем и "узких" мест и разработки проекта совершенствования деловых процессов.

Бизнес-правила . Модель деловых процессов позволяет выявить и точно определить бизнес-правила, используемые в деятельности предприятия.

На рис. 3 представлен фрагмент функциональной модели документооборота. При выполнении операции "сортировать документы" используется бизнес-правило: "регистрации не подлежат: документы, присланные в копии для сведения, телеграммы и письма о разрешении командировок и отпусков...". Это правило зафиксировано в инструкции по документообороту. Функциональная модель позволяет не только идентифицировать существование этого правила, но также определить, при выполнении какой операции и на каком рабочем месте оно должно применяться.

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

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

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

Информационные объекты . Функциональная модель позволяет идентифицировать все информационные объекты, которыми оперирует предприятие в своей деятельности. В отличие от информационных моделей (Data Flow Diagrams, IDEF1X) функциональная модель IDEF0 отражает, как именно используются информационные объекты в рамках деловых процессов.

Построение модели КАК БУДЕТ . Создание и внедрение корпоративной информационной системы приводит к изменению условий выполнения отдельных операций, структуры деловых процессов и предприятия в целом. Это приводит к необходимости изменения системы бизнес-правил, используемых на предприятии, модификации должностных инструкций сотрудников. Функциональная модель КАК БУДЕТ позволяет уже на стадии проектирования будущей информационной системы определить эти изменения. Применение функциональной модели КАК БУДЕТ позволяет не только сократить сроки внедрения информационной системы, но также снизить риски, связанные с невосприимчивостью персонала к информационным технологиям.

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

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

Программные системы IDEF0

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

ЗАКЛЮЧЕНИЕ

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

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