Функциональное моделирование idef0 примеры. IDEF0: функциональное моделирование деловых процессов. История возникновения стандарта IDEF0

Научитесь видеть и понимать функциональную структуру своего бизнеса!

В настоящее время в России резко возрос интерес к общепринятым на Западе стандартам менеджмента, однако, в реальной практике управления существует один очень показательный момент. Многих руководителей до сих пор можно поставить в тупик прямым вопросом об организационной структуре компании или о схеме существующих бизнес-процессов. Наиболее продвинутые и регулярно читающие экономическую периодику менеджеры, как правило, начинают чертить понятные только им одним иерархические диаграммы, но и в этом процессе обычно быстро заходят в тупик. То же самое касается сотрудников и руководителей различных служб и функциональных подразделений. В большинстве случаев, единственным набором изложенных правил, в соответствии с которыми должно функционировать предприятие, является набор отдельных положений и должностных инструкций. Чаще всего эти документы составлялись не один год назад, слабо структурированы и невзаимосвязаны между собой и, вследствие этого, просто пылятся на полках. До поры до времени подобный подход был оправдан, так как во время становления российской рыночной экономики понятие конкуренции практически отсутствовало, да и затраты считать не было особой необходимости - прибыль была гигантской. В результате этого, мы видим в течение последних двух лет вполне объяснимую картину: крупные компании, выросшие в начале 90-х годов, постепенно сдают свои позиции, вплоть до полного ухода с рынка. Отчасти это обусловлено тем, что на предприятии не были внедрены стандарты управления, полностью отсутствовало понятие функциональной модели деятельности и миссии. С помощью моделирования различных областей деятельности можно достаточно эффективно анализировать “узкие места” в управлении и оптимизировать общую схему бизнеса. Но, как известно, на любом предприятии высший приоритет имеют только те проекты, которые непосредственно приносят прибыль, поэтому речь об обследовании деятельности и ее реорганизации обычно идет только во время ощутимого кризиса в управлении компанией.

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

Само же понятие “моделирование бизнес-процессов” пришло в быт большинства аналитиков одновременно с появлением на рынке сложных программных продуктов, предназначенных для комплексной автоматизации управления предприятием. Подобные системы всегда подразумевают проведение глубокого предпроектного обследования деятельности компании. Результатом этого обследование является экспертное заключение, в котором отдельными пунктами выносятся рекомендации по устранению “узких мест” в управлении деятельностью. На основании этого заключения, непосредственно перед проектом внедрения системы автоматизации, проводится так называемая реорганизация бизнес-процессов, иногда достаточно серьезная и болезненная для компании. Это и естественно, сложившийся годами коллектив всегда сложно заставить “думать по-новому”. Подобные комплексные обследования предприятий всегда являются сложными и существенно отличающимися от случая к случаю задачами. Для решения подобных задач моделирования сложных систем существуют хорошо обкатанные методологии и стандарты. К таким стандартам относятся методологии семейства IDEF. С их помощью можно эффективно отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными. В настоящий момент к семейству IDEF можно отнести следующие стандарты:

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

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

IDEF1X (IDEF1 Extended) – методология построения реляционных структур. IDEF1X относится к типу методологий “Сущность-взаимосвязь” (ER – Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

IDEF2 – методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. Однако в настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе “раскрашенных сетей Петри” (CPN – Color Petri Nets);

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

IDEF4 – методология построения объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;

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

История возникновения стандарта IDEF0

Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). Несколько лет назад в России небольшим тиражом вышла одноименная книга, посвящанная описанию основных принципов построения SADT-диаграмм. Исторически, IDEF0, как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing) и была предложена департаментом Военно-Воздушных Сил США. Собственно семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=ICAM DEFinition). В процессе практической реализации, участники программы ICAM столкнулись с необходимостью разработки новых методов анализа процессов взаимодействия в промышленных системах. При этом кроме усовершенствованного набора функций для описания бизнес-процессов, одним из требований к новому стандарту было наличие эффективной методологии взаимодействия в рамках “аналитик-специалист”. Другими словами, новый метод должен был обеспечить групповую работу над созданием модели, с непосредственным участием всех аналитиков и специалистов, занятых в рамках проекта.

В результате поиска соответствующих решений родилась методология функционального моделирования IDEF0. C 1981 года стандарт IDEF0 претерпел несколько незначительных изменения, в основном ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом По Стандарам и Технологиям США (NIST).

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

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

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

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

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

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

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

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

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

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

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

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

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

Рисунок 2.

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

Рисунок 3.

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

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

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

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

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

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

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

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

В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 – модели. Наглядно принцип декомпозиции представлен на рисунке 4. Следует обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм - каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует.

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

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

Рисунок 4. Декомпозиция функциональных блоков.

Принципы ограничения сложности IDEF0-диаграмм

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

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

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

Дисциплина групповой работы над разработкой IDEF0-модели

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

Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов. На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.

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

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

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

В последние годы интерес в России к методологиям семейства IDEF неуклонно растет. Это я постоянно наблюдаю, просматривая статистику обращений к своей персональной web-странице (http://www.vernikov.ru), на которой кратко описаны основные принципы этих стандартов. При этом интерес к таким стандартам, как IDEF3-5 я бы назвал теоретическим, а к IDEF0 вполне практически обоснованным. Собственно говоря, первые Case-средства, позволяющие строить DFD и IDEF0 диаграммы появились на российком рынке еще в 1996 году, одновременно с выходом популярной книги по принципам моделирования в стандартах SADT.

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

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

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

Что поступает в подразделение “на входе”?

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

Кто является ответственным за выполнение каждой из функций?

Чем руководствуется исполнитель при выполнении каждой из функций?

Что является результатом работы подразделения (на выходе)?

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

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

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

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 содержит следующие кнопки:

Навигатор модели показывает состав модели по уровням разработки. С его помощью можно легко и быстро переходить с уровня на уровень. Работа с навигатором модели аналогична работе с Проводником системы 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 (остаться в текущей диаграмме).

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. Диаграмма состояний объекта.

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

IDEF0 — модель:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оценка имен

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

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

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

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

L*C

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

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

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

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

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

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

Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT ( Structured Analysis and Design Technique ). Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing ). Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы ( IDEF = Icam DEFinition), и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США ( NIST ).

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

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

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

• верхняя сторона имеет значение "Управление" (Control);
• левая сторона имеет значение "Вход" (Input);
• правая сторона имеет значение "Выход" (Output);
• нижняя сторона имеет значение "Механизм" ( Mechanism ).

Рис. 6.1.

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

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

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

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

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

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

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

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

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

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

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

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

Выделение подпроцессов . В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы , и называется дочерней (Child Diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 –модели.

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

• Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов, создавая модели деятельности подразделений. При этом их интересуют ответы на следующие вопросы:

  Что поступает в подразделение "на входе"?

  • Какие функции и в какой последовательности выполняются в рамках подразделения?
  • Кто является ответственным за выполнение каждой из функций ?
  • Чем руководствуется исполнитель при выполнении каждой из функций ?
  • Что является результатом работы подразделения (на выходе)?

  На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.

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

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

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