Методология IDEF0. Построение модели IDEF0

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

Наиболее удобным языком моделирования бизнес-процессов является IDEF0, предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT - Structured Analysis and Design Technique. (В начале 70-х годов вооруженные силы США применили подмножество SADT, касающееся моделирования процессов, для реализации проектов в рамках программы ICAM (Integrated Computer-Aided Manufacturing). В дальнейшем это подмножество SADT было принято в качестве федерального стандарта США под наименованием IDEF0. Подробные спецификации на стандарты IDEF можно найти на сайте http://www.idef.com .

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

Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.

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

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

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

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

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

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

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

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

Точка зрения (Viewpoint) . Хотя при построении модели учитываются мнения различных людей, модель должна строиться с единой точки зрения. Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совершенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом. Часто при выборе точки зрения на модель важно задокументировать дополнительные альтернативные точки зрения. Для этой цели обычно используют диаграммы FEO (For Exposition Only).

IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Edit/Model Properties , вызывающий диалог Model Properties (рис. 4). В закладкеPurpose следует внести цель и точку зрения, а в закладкуDefinition - определение модели и описание области.

В закладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). В закладкеSource описываются источники информации для построения модели (например, "Опрос экспертов предметной области и анализ документации"). ЗакладкаGeneral служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели -AS-IS иТО-ВЕ .

Рис. 4. Диалог задания свойств модели

Модели AS-IS и ТО-ВЕ . Обычно сначала строится модель существующей организации работы - AS-IS (как есть). На основе модели AS-IS достигается консенсус между различными единицами бизнеса по тому, "кто что сделал" и что каждая единица бизнеса добавляет в процесс. Модель AS-IS позволяет выяснить, "что мы делаем сегодня" перед тем, как перепрыгнуть на то, "что мы будем делать завтра". Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаками неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияния ее результат), входу (объекты или информация используются нерационально) и т. д. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) - модели новой организации бизнес-процессов. Модель нужна ТО-ВЕ для анализа альтернативных/лучших путей выполнения работы и документирования того, как компания будет делать бизнес в будущем.

Следует указать на распространенную ошибку при создании модели AS-IS - это создание идеализированной модели. Примером может служить создание модели на основе знаний руководителя, а не конкретного исполнителя работ. Руководитель знаком с тем, как предполагается выполнение работы по руководствам и должностным инструкциям и часто не знает, как на самом деле подчиненные выполняют рутинные работы. В результате получается приукрашенная, искаженная модель, которая несет ложную информацию и которую невозможно в дальнейшем использовать для анализа. Такая модель называется SHOULD_BE (как должно бы быть).

Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, т. е. создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС. Построение системы на основе модели AS-IS приводит к автоматизации предприятия по принципу "все оставить как есть, только чтобы компьютеры стояли", т. е. ИС автоматизирует несовершенные бизнес-процессы и дублирует, а не заменяет существующий документооборот. В результате внедрение и эксплуатация такой системы приводит лишь к дополнительным издержкам на закупку оборудования, создание программного обеспечения и сопровождение того и другого.

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

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

Рис. 5. Отчет по модели

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

Модель может содержать четыре типа диаграмм:

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

диаграммы декомпозиции;

диаграммы дерева узлов;

диаграммы только для экспозиции (FEO).

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

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

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

Пример создания функционально модели.

В качестве примера рассматривается деятельность вымышленной компании «Computer Word». Компания занимается в основном сборкой и продажей настольных компьютеров и ноутбуков. Компания не производит компоненты самостоятельно, а только собирает и тестирует компьютеры.

Основные виды работ в компании таковы:

продавцы принимают заказы клиентов;

операторы группируют заказы по типам компьютеров;

операторы собирают и тестируют компьютеры;

операторы упаковывают компьютеры согласно заказам;

кладовщик отгружает клиентам заказы.

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

Методика выполнения работы

1. Запустите BPwin ().

2. Если появляется диалог ModelMart Connection Manager , нажмите на кнопкуCancel (Отмена).

3. Щелкните по кнопке . Появляется диалоговое окноI would like to (рис. 6). Внесите в текстовое полеName имя модели "Деятельность компании" и выберите Туре –Business Process (IDEF0) . Нажмите кнопкуОК .

Рис. 6. Присвоение модели имени и выбор типа модели

4. Откроется диалоговое окно Properties for New Models (Свойства новой модели) (рис. 7). Введите в текстовое полеAuthor (Автор) имя автора модели и в текстовое полеAuthor initials его инициалы. Нажмите последовательно кнопкиApply иОК .

5. Автоматически создается незаполненная контекстная диаграмма (рис. 8).

6. Обратите внимание на кнопку на панели инструментов. Эта кнопка включает и выключает инструмент просмотра и навигации -Model Explorer (Браузер модели).Model Explorer имеет три вкладки –Activities (), Diagrams () и Objects (). Во вкладкеActivities щелчок правой кнопкой по объекту в браузере модели позволяет выбрать опции редактирования его свойств (рис. 9).

Рис. 8. Незаполненная контекстная диаграмма

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

7. Перейдите в меню Model/Model Properties . Во вкладкеGeneral диалогового окнаModel Properties в текстовое полеModel name следует внести имя модели "Деятельность компании", а в текстовое полеProject имя проекта "Модель деятельности компании", и, наконец, в текстовоеTime Frame (Временной охват) -AS-IS (Как есть) (рис. 10).

Рис. 10. Окно задания свойств модели

8. Во вкладке Purpose диалогового окнаModel Properties в текстовое полеPurpose (цель) внесите данные о цели разработки модели - "Моделировать текущие (AS-IS) бизнес-процессы компании", а в текстовое полеViewpoint (точка зрения) - "Директор" (рис. 11).

Рис. 11. Внесение данных о цели моделирования и точке зрения

9. Во вкладке Definition диалогового окнаModel Properties в текстовое полеDefinition (Определение) внесите "Это учебная модель, описывающая деятельность компании" и в текстовое полеScope (охват) - "Общее управление бизнесом компании: исследование рынка, закупка компонентов, сборка, тестирование и продажа продуктов" (рис. 12).

10. Перейдите на контекстную диаграмму и правой кнопкой мыши щелкните по прямоугольнику представляющему, в нотации IDEF0 , условное графическое обозначение работы. В контекстном меню выберите опциюName (рис. 13). Во вкладкеName внесите имя "Деятельность компании" (рис. 14).

11. Во вкладке Definition диалогового окнаActivity Properties в текстовое полеDefinition (Определение) внесите "Текущие бизнес-процессы компании" (рис. 15). Текстовое полеNote (Примечания) оставьте незаполненным.

Рис. 12. Внесение дополнительных данных определяющих модель

Рис. 13. Контекстное меню для работы с выбранной опцией Name

Рис. 14. Присвоение работе названия

Рис. 15. Внесение дополнительных данных о работе

12. Создайте ICOM -стрелки на контекстной диаграмме (таблица 1).

Таблица 1 - Стрелки контекстной диаграммы

Название стрелки (Arrow Name )	Определение стрелки (Arrow Definition )	Тип стрелки (Arrow Type )
Звонки клиентов	Запросы информации, заказы, техподдержка и т.д.
Правила и процедуры	Правила продаж, инструкции по сборке, процедуры тестирования, критерии производительности и т. д.
Проданные продукты	Настольные и портативные компьютеры
Бухгалтерская система	Оформление счетов, оплата счетов, работа с заказами

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

Рис. 16. Внесение текста в поле диаграммы с помощью редактора Text Block Editor

14. Создайте отчет по модели. В меню Tools/Reports/Model Report (рис. 17) задайте опции генерирования отчета (установите галочки) и нажмите кнопкуPreview (Предварительный просмотр) (рис. 18).

Рис. 17. Задание опций генерирования отчета Model Report

Рис. 18. Предварительный просмотр отчета Model Report

Декомпозиция производственных процессов по методологии IDEF 0

Работы (Activity)

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

Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы. Для описания других свойств работы служит диалогActivity Properties (рис. 2).

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

Рис. 2. Редактор задания свойств работы

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

Возникает диалог Activity Box Count (рис. 3), в котором следует указать нотацию новой диаграммы и количество работ на ней. Выберем нотациюIDEF0 и щелкнем наОК . Появляется диаграмма декомпозиции (рис. 4). Допустимый интервал числа работ 2-8. Декомпозировать работу на одну работу не имеет смысла: диаграммы с количеством работ более восьми получаются перенасыщенными и плохо читаются. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от трех до шести блоков на одной диаграмме.

Рис . 3. Диалог Activity Box Count

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

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

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

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

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

Стрелки (Arrow)

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

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

Вход (Input) - материал или информация, которые используются или преобразуется работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был придуман IDEF0) не возникает проблем определения входов. Действительно, "Сырье" на рис. 1. - это нечто, что перерабатывается в процессе "Изготовление изделия" для получения результата. При моделировании ИС, когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при "Приеме пациента" карта пациента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в этом примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе - "Заполненная карта пациента"). Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может служить то, перерабатываются/изменяются ли данные в работе или нет. Если изменяются, то скорее всего это вход, если нет - управление.

Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рис. 1 стрелки "Задание"и "Чертеж" - управление для работы "Изготовление изделия". Управление влияет на работу, но не преобразуется работой. Если цель работы - изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или вход) рекомендуется рисовать стрелку управления.

Выход (Output) - материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. На рис. 1 стрелка "Готовое изделие" является выходом для работы "Изготовление изделия".

Механизм (Mechanism) - ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы. На рис. 1 стрелка "Персонал предприятия" является механизмом для работы "Изготовление изделия". По усмотрению аналитика стрелки механизма могут не изображаться в модели.

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

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

Для внесения граничной стрелки входа следует:

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

Имена вновь внесенных стрелок автоматически заносятся в словарь (Arrow Dictionary ).

ICOM-коды. Диаграмма декомпозиции предназначена для детализации работы. В отличие от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в IDEF0 - это не элемент управления нижестоящими работами. Работы нижнего уровня - это то же самое, что работы верхнего уровня, но в более детальном изложении. Как следствие этого границы работы верхнего уровня - это то же самое, что границы диаграммы декомпозиции.ICOM (аббревиатура отInput, Control, Output и Mechanism ) - коды, предназначенные для идентификации граничных стрелок. КодICOM содержит префикс, соответствующий типу стрелки (I ,С ,О илиМ ), и порядковый номер. BPwin вносит ICOM-коды автоматически. Для отображения ICOM-кодов следует включить опциюShow ICOM codes на закладке Presentation диалога Model Properties .

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

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

Рис . 5. Диалог Arrow Properties

Рис. 6. Словарь стрелок

Несвязанные граничные стрелки (unconnected border arrow). При декомпозиции работы входящие в нее и исходящие из нее стрелки (кроме стрелки вызова) автоматически появляются на диаграмме декомпозиции (миграция стрелок), но при этом не касаются работ. Такие стрелки называются несвязанными и воспринимаются в BPwin как синтаксическая ошибка. Для связывания стрелок входа, управления или механизма необходимо перейти в режим редактирования стрелок, щелкнуть по наконечнику стрелки и щелкнуть по соответствующему сегменту работы. Для связывания стрелки выхода необходимо перейти в режим редактирования стрелок, щелкнуть по сегменту выхода работы и затем по стрелке.

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

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

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

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

Обратная связь по входу (output-input feedback) , когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов.

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

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

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

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

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

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

Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления не именована какая-либо из ветвей. BPwin определяет такую стрелку как синтаксическую ошибку.

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

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

Для их "перетаскивания" наверх нужно сначала выбрать кнопку на палитре инструментов и щелкнуть по квадратным скобкам граничной стрелки. Появляется диалог Border Arrow Editor (рис. 7).

Рис . 7. Диалог Border Arrow Editor

Если щелкнуть по кнопке Resolve Border Arrow , стрелка мигрирует на диаграмму верхнего уровня, если по кнопкеChangeToTunnel- стрелка будет затоннелирована и не попадет на другую диаграмму.

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

Пример создания диаграммы декомпозиции

1. Выберите кнопку перехода на нижний уровень в палитре инструментов и в диалоговом окнеActivity Box Count (рис. 8) установите число работ на диаграмме нижнего уровня - 3 - и нажмите кнопкуОК .

Рис. 8. Диалоговое окно Activity Box Count

2. Автоматически будет создана диаграмма декомпозиции (рис. 9).

Рис. 9. Диаграмма декомпозиции

Правой кнопкой мыши щелкните по работе расположенной в левом верхнем углу области редактирования модели, выберите в контекстном меню опцию Name и внесите имя работы. Повторите операцию для оставшихся двух работ. Затем внесите определение, статус и источник для каждой работы согласно данным таблицы 1.

Таблица 1. Работы диаграммы декомпозиции А0

Диаграмма декомпозиции примет вид представленный на рис. 10.

Рис.10 Диаграмма декомпозиции после присвоения работам наименований

3. Для изменения свойств работ после их внесения в диаграмму можно воспользоваться словарем работ (рис. 11). Вызов словаря производится при помощи пункта главного меню Dictionary /Activity .

Рис . 11. Словарь Activity Dictionary

Если описать имя и свойства работы в словаре, ее можно будет внести в диаграмму позже с помощью кнопки в палитре инструментов. Невозможно удалить работу из словаря, если она используется на какой-либо диаграмме. Если работа удаляется из диаграммы, из словаря она не удаляется. Имя и описание такой работы может быть использовано в дальнейшем. Для добавления работы в словарь необходимо перейти в конец списка и щелкнуть правой кнопкой по последней строке. Возникает новая строка, в которой нужно внести имя и свойства работы. Для удаления всех имен работ, не использующихся в модели, щелкните по кнопке(Purge (Чистить)).

4. Перейдите в режим рисования стрелок и свяжите граничные стрелки, воспользовавшись кнопкой на палитре инструментов так, как это показано на рис. 12.

Рис. 12. Связанные граничные стрелки на диаграмме А0

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

Рис. 13. Стрелка "Правила сборки и тестирования"

Рис. 14. Стрелка "Система оформления заказов"

6. Альтернативный метод внесения имен и свойств стрелок - использование словаря стрелок (вызов словаря - меню Dictionary/ Arrow ). Если внести имя и свойства стрелки в словарь (рис. 15), ее можно будет внести в диаграмму позже.

Рис. 15. Словарь стрелок

Стрелку нельзя удалить из словаря, если она используется на какой-либо диаграмме. Если удалить стрелку из диаграммы, из словаря она не удаляется. Имя и описание такой стрелки может быть использовано в дальнейшем. Для добавления стрелки необходимо перейти в конец списка и щелкнуть правой кнопкой по последней строке. Возникает новая строка, в которой нужно внести имя и свойства стрелки.

7. Создайте новые внутренние стрелки так, как показано на рис. 16.

Рис. 16. Внутренние стрелки диаграммы А0

8. Создайте стрелку обратной связи (по управлению) "Результаты сборки и тестирования", идущую от работы "Сборка и тестирование компьютеров" к работе "Продажи и маркетинг". Измените, при необходимости, стиль стрелки (толщина линий) и установите опцию Extra Arrowhead (Дополнительный Наконечник стрелы) (из контекстного меню). Методомdrag&drop перенесите имена стрелок так, чтобы их было удобнее читать. Если необходимо, установите из контекстного менюSquiggle (Загогулину). Результат возможных изменений показан на рис. 17.

Рис. 17. Результат редактирования стрелок на диаграмме А0

9. Создайте новую граничную стрелку выхода "Маркетинговые материалы", выходящую из работы "Продажи и маркетинг". Эта стрелка автоматически не попадает на диаграмму верхнего уровня и имеет квадратные скобки на наконечнике (рис. 18).

Рис. 18. Стрелка Маркетинговые материалы

10. Щелкните правой кнопкой мыши по квадратным скобкам и выберите пункт меню Arrow Tunnel (рис. 19).

В диалоговом окне Border Arrow Editor (Редактор Граничных Стрелок) выберите опциюResolve it to Border Arrow (Разрешить как Граничную Стрелку) (рис. 20).

Рис . 19. Пункт меню Arrow Tunnel

Рис . 20. Диалоговое окно Border Arrow Editor

Для стрелки "Маркетинговые материалы" выберите опцию Trim (Упорядочить) из контекстного меню. Результат выполнения лабораторной работы показан на рис. 21.

Рис. 21. Результат выполнения декомпозиции

6.2. Назначение и состав методологии SADT (IDEF0)

Методология SADT (Structured Analysis and Design Technique – методология структурного анализа и проектирования) представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели системы.

Начало разработки данной методологии было положено Дугласом Россом (США) в середине 60-х гг. ХХ в. С тех пор системные аналитики компании SofTech, Inc. улучшили SADT и использовали ее в решении широкого круга проблем. Программное обеспечение телефонных сетей, диагностика, долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, конфигурация компьютерных систем, обучение персонала, управление финансами и материально-техническим снабжением – вот некоторые из областей эффективного применения SADT. Широкий спектр областей указывает на универсальность и мощь методологии SADT. В программе «Интеграции компьютерных и промышленных технологий» (Integrated Computer Aided Manufacturing, ICAM) Министерства обороны США была признана полезность SADT. Это привело к публикации ее части в 1981 г., называемой IDEF0 (Icam DEFinition), в качестве федерального стандарта на разработку программного обеспечения. Под этим названием SADT стала применяться тысячами специалистов в военных и промышленных организациях . Последняя редакция стандарта IDEF0 была выпущена в декабре 1993г. Национальным институтом по стандартам и технологиям США (National Institute Standards and Technology, NIST).

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

Описывать любые системы, а не только информационные (DFD предназначена для описания программного обеспечения);

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

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

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

Модель (AS-IS, TO-BE или SHOULD-BE) может содержать 4 типа диаграмм [ , ]:

Контекстную диаграмму;

Диаграммы декомпозиции;

Диаграммы дерева узлов;

Диаграммы только для экспозиции (for exposition only, FEO).

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

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

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

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

6.3. Элементы графической нотации IDEF0

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

На следующем рисунке показаны основные элементы графической нотации IDEF0 .

Рис. 6.1. Элементы графической нотации IDEF0

Прямоугольник представляет собой работу (процесс, деятельность, функцию или задачу) , которая имеет фиксированную цель и приводит к некоторому конечному результату. Имя работы должно выражать действие (например, «Изготовление детали», «Расчет допускаемых скоростей», «Формирование ведомости ЦДЛ № 3»).

Взаимодействие работ между собой и внешним миром описывается в виде стрелок. В IDEF0 различают 5 видов стрелок :

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

- управление (англ. control) – управляющие, регламентирующие и нормативные данные, которыми руководствуется работа. Управление отвечает на вопрос «В соответствии с чем выполняется работа?». Управление влияет на работу, но не преобразуется ей, т.е. выступает в качестве ограничения. В качестве управления могут быть правила, стандарты, нормативы, расценки, устные указания. Стрелки управления рисуются входящими в верхнюю грань работы. Если при построении диаграммы возникает вопрос, как правильно нарисовать стрелку сверху или слева, то рекомендуется ее рисовать как вход (стрелка слева);

- выход (англ. output) – материал или информация, которые представляют результат выполнения работы. Выход отвечает на вопрос «Что является результатом работы?». В качестве выхода может быть как материальный объект (деталь, автомобиль, платежные документы, ведомость), так и нематериальный (выборка данных из БД, ответ на вопрос, устное указание). Стрелки выхода рисуются исходящими из правой грани работы;

- механизм (англ. mechanism) – ресурсы, которые выполняют работу. Механизм отвечает на вопрос «Кто выполняет работу или посредством чего?». В качестве механизма могут быть персонал предприятия, студент, станок, оборудование, программа. Стрелки механизма рисуются входящими в нижнюю грань работы;

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

6.4. Типы связей между работами

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

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

1. Иерархическая связь (связь «часть» – «целое») имеет место между функцией и подфункциями, из которых она состоит.

Рис. 6.2. Иерархическая связь

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

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

Рис. 6.5. Прямая связь по входу	Рис. 6.6. Обратная связь по входу

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

Рис. 6.7. Потребительская связь

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

Рис. 6.8. Логическая связь

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

Рис. 6.9. Методическая связь

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

Рис. 6.10. Ресурсная связь

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

Рис. 6.11. Информационная связь

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

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

Рис. 6.12. Временная связь

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

Рис. 6.13. Случайная связь

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

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

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

1. Перед построением модели необходимо определиться, какая модель (модели) системы будет построена. Это подразумевает определение ее типа AS-IS, TO-BE или SHOULD-BE, а также определения позиции, с точки зрения которой строится модель. «Точку зрения» лучше всего представлять себе как место (позицию) человека или объекта, в которое надо встать, чтобы увидеть систему в действии. Например, при построении модели работы продуктового магазина можно среди возможных претендентов, с точки зрения которых рассматривается система, выбрать продавца, кассира, бухгалтера или директора. Обычно выбирается одна точка зрения, наиболее полно охватывающая все нюансы работы системы, и при необходимости для некоторых диаграмм декомпозиции строятся диаграммы FEO, отображающие альтернативную точку зрения.

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

3. Количество блоков на диаграммах декомпозиции рекомендуется в пределах 3–6. Если на диаграмме декомпозиции два блока, то она, как правило, не имеет смысла. При наличии большого количества блоков диаграмма становится перенасыщенной и трудно читаемой.

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

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

Рис. 6.14. Функция без управления и входа

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

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

6. У каждого блока должен быть как минимум один выход.

Рис. 6.15. Функция без выхода

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

7. При построении диаграмм следует минимизировать число пересечений, петель и поворотов стрелок.

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

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

Рис. 6.16. Ветвление стрелок

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

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

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

Рис. 6.17. Неправильное именование стрелок

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

Рис. 6.18. Туннелирование стрелок

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

Аналогичным образом можно выполнять туннелирование с обратной целью – недопущения отображения стрелки на диаграммах низших уровней. В этом случае круглые скобки ставятся на конце стрелки. На контекстной диаграмме (см. рис. 6.21) затуннелирован механизм «Инженер службы пути», входящий в блок «Определение допускаемых скоростей». Такое решение принято, так как инженер непосредственно участвует во всех работах, отображенных на диаграмме декомпозиции этого блока (см. рис. 6.22). Чтобы не показывать эту связь и не загромождать диаграмму декомпозиции, стрелка была затуннелирована.

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

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

Рис. 6.19. Объединение связей

13. Каждый блок на диаграммах должен иметь свой номер. Для того чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Блок на диаграмме верхнего уровня обозначается 0, блоки на диаграммах второго уровня – цифрами от 1 до 9 (1, 2, …, 9), блоки на третьем уровне – двумя цифрами, первая из которых указывает на номер детализируемого блока с родительской диаграммы, а вторая номер блока по порядку на текущей диаграмме (11, 12, 25, 63) и т. д. Контекстная диаграмма имеет обозначение «А – 0», диаграмма декомпозиции первого уровня – «А0», диаграммы декомпозиции следующих уровней – состоят из буквы «А», за которой следует номер декомпозируемого блока (например, «А11», «А12», «А25», «А63»). На рисунке показано типичное дерево диаграмм (диаграмма дерева узлов) с нумерацией.

Рис. 6.20. Иерархия диаграмм

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

6.6. Пример построения модели IDEF0 для системы определения допускаемых скоростей

Расчет допускаемых скоростей движения поездов является трудоемкой инженерной задачей. При проходе поездом какого-либо участка фактическая скорость движения поезда не должна превышать предельно допускаемую. Эта предельно допускаемая скорость устанавливается исходя из опыта эксплуатации и специально проводимых испытаний по динамике движения и воздействию на путь подвижного состава. Непревышение этой скорости гарантирует безопасность движения поездов, комфортабельные условия езды пассажиров и т. п. Они определяются в зависимости от типа подвижного состава (марки локомотива и типа вагонов), параметров верхнего строения пути (типа рельсов, балласта, эпюры шпал) и плана (радиуса кривых, переходных кривых, возвышения наружного рельса и т. д.). Как правило, для установления допускаемых скоростей необходимо определить не менее двух (на прямых) и пяти (в кривых) скоростей, из которых и выбирается окончательная допускаемая скорость, как наименьшая из всех рассчитанных. Расчет этих скоростей регламентируются Приказом МПС России № 41 от 12 ноября 2001 г. «Нормы допускаемых скоростей движения подвижного состава по железнодорожным путям колеи 1520 (1524) мм Федерального железнодорожного транспорта».

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

Контекстная диаграмма для задачи определения допускаемых скоростей показана на рис.6.21. Для построения модели использовался продукт BPwin 4.0 фирмы Computer Associates.

Рис. 6.21. Контекстная диаграмма системы определения допускаемых скоростей (методология IDEF0)

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

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

Подробный продольный профиль (содержит информацию, аналогичную рассмотренной выше);

Паспорт дистанции пути (содержит информацию, аналогичную рассмотренной выше, а также сведения о верхнем строении пути (ВСП));

Данные о результатах съемки плана пути вагоном-путеизмерителем;

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

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

Управляющими данными являются:

Указание начальника службы пути дороги или Департамента пути и сооружений ОАО «РЖД» на расчет;

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

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

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

Результатом работы системы должны быть:

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

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

Типовые формы № 1, 1а и 2, содержащие планируемые допускаемые скорости для разработки графика движения поездов.

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

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

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

Рис. 6.22. Диаграмма декомпозиции первого уровня (методология IDEF0)

Очередность выполнения функций для решения рассматриваемой задачи следующая:

Ввод и корректировка нормативно-справочной информации и данных по участкам дороги (блоки 1 и 2);

Подготовка задания на расчет (блок 3). В нем указывается, для какого участка и пути, а также марки локомотива и типа вагонов следует выполнить расчет;

Расчет допускаемых скоростей в соответствии с порядком и формулами, указанными в Приказе № 41 (блок 4). В качестве исходной информации выступают данные по пути участка (план, верхнее строение пути и т. д.) и нормативы, выбираемые на основании задания на расчет;

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

Формирование и подготовка проекта Приказа «Н» и типовых ведомостей (блоки 6 и 7).

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

6.7. ICOM-коды

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

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

Известная сегодня уже не только в узких кругах аббревиатура IDEF0 является первой методологией, стандартизирующей работу над бизнес-процессами. Она была разработана в середине прошлого века в рамках аэрокосмического проекта в США и, показав свою эффективность, стала федеральным стандартом. В нашей стране в 2000 году подготовлен документ «Методология функционального моделирования IDEF0. Руководящий документМетодология функционального моделирования IDEF0 Руководящий документ. Издание официальное. Госстандарт России РД IDEF0 – 2000. Разработан Научно-исследовательским Центром CALS – технологий «Прикладная Логистика». Принят и введен в действие Постановлением Госстандарта России 2000 г. Москва », но как стандарт он так и не был утвержден. Хотя это не помешало данной методологии стать в нашей стране одним из наиболее популярных инструментов графического моделирования бизнес-процессов. В данной статье я предлагаю вам рассмотреть модель IDEF0 и оценить актуальность этого подхода в настоящее время.

Основные понятия и сокращения

Разберемся немного с названиями ключевых элементов методологии. Графический стандарт IDEF0 является частью методологии SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования). IDEF – это сокращение от ICAM Definition, а ICAM образовано от Integrated Computer Aided Manufacturing, что переводится как интегрированная компьютеризация производства. Методология SADT – это целое семейство из 15 разных моделей, которые в комплексе должны были позволить исследовать структуру, параметры и характеристики производственно-технических и организационно-экономических систем.

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

Нотация IDEF0 – это достаточно строгая методика, которая изначально была разработана, как и стандарты технического конструирования, для ручного моделирования. Поэтому там содержатся требования по размещению стрелок, формату всех элементов, содержанию информационной рамки к IDEF0 диаграмме и пр. Поскольку деятельность компании – это сложная многоуровневая система действий, то схем получается всегда много, и необходима однозначная систематизация и навигация по всем элементам модели. Сейчас это делают в основном компьютерные системы, поддерживающие моделирование в данной нотации. На территории России наиболее известными и доступными на сегодня являются системы AllFusion Process Modeler и Business Studio. Обзору этих систем я планирую посвятить отдельные статьи.

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

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

Обязательные элементы функционального блока в IDEF0

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

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

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

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

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

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

Контекстная диаграмма

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

1. Цель – конкретная формулировка назначения модели, по которой можно сверять в дальнейшем точность построения модели.
2. Точка зрения – от чьего лица строится модель, так как модель зависима всегда от ее автора и фокуса внимания. Если мы строим общую модель предприятия, то обычно она представляется с точки зрения его директора.
3. Тип модели – это указание на то, какая информация отображена на схемах. Здесь может быть 2 принципиальных варианта: AS IS («как есть») или TO BE («как будет»). Такое разделение необходимо, так как мы можем строить модели как для анализа деятельности, так и для ее трансформации. Мы должны четко отдавать себе отчет в том, что мы делаем, а также доносить эту информацию до окружающих.

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

Основные потоки

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

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

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

(нажмите для увеличения)

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

Стрелки управления могут быть представлены только 1 видом потока – информационным, который можно разбить на 2 подвида. Первый – это документы, такие как:

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

Второй – это недокументированная информация, к которой чаше всего относятся требования собственников.

И, наконец, механизмы – здесь только 2 вида потоков: оборудование (материальный) и исполнители (подразделения и люди). Здесь не может быть документов, как и не может быть людей на стрелках управления!

Для навигации в модели предусмотрена сквозная нумерация. Контекстная диаграмма нумеруется «А-0». В дальнейшем каждый функциональный блок получает свой номер, какой бы глубокой ни была декомпозиция.

Декомпозиция

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

(нажмите для увеличения)

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

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

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

На рисунке ниже представлена диаграмма декомпозиции нашего примера.

(нажмите для увеличения)

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

Дальнейшая работа над моделью аналогична первому шагу – проводится декомпозиция каждого функционального блока первого уровня. Нумерация блоков будет содержать при этом номер первого уровня: А1.1 … А1.n, A2.1 … A2.n и т.д.

Выводы об актуальности нотации

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

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

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

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

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

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

Постановка задач Цель работы: сократить время и повысить удобство разработки диаграмм IDEF0 за счет удобного, интуитивно понятного интерфейса, большой области для работы. Задачи: Проанализировать предметную область и объект проектирования Выбрать методы решения; Закодировать и оттестировать; Внедрить.

Функциональные требования Создание следующих компонентов диаграммы IDEF0 на рабочей области: функционального ICOM-блока; интерфейсной дуги; комментариев. Перемещение компонентов диаграммы последовательности на рабочей области путем перетаскивания мышкой (с помощью технологии drag and drop). Удаление компонентов и связанных с ней элементов диаграммы с рабочей области: функционального ICOM-блока; интерфейсной дуги; комментариев. Установка фокуса на элемент диаграммы (для реализации функций удаления и технологии drag and drop). Редактирование название компонента диаграммы, изменение текста без удаления самой надписи. Ассоциирование комментариев с конкретными компонентами диаграммы. Сохранение и загрузка диаграммы в файл с расширением.xml Экспорт изображения

Нефункциональные требования Соответствие стандарту IDEF0. Соответствие варианту задания. стрелки должны быть проаннотированы, включая выносные аннотации; должны быть реализованы изогнутые стрелки; должна быть реализована стандартная IDEF рамка диаграммы. Реализация технологии Drag and Drop. Работать под управлением ОС Windows XP, 7. Продукт должен ставиться на «чистую» ОС, без требований установки дополнительных программ. Разрешающая способность экрана: 1024*768. Интерфейс на русском языке. Интерфейс однооконный. Наличие инсталлятора.

Распределение обязанностей Насонов: Программирование и отладка функций для работы с элементом «DiagramItem»: – создание – редактирование – перемещение в любую область рабочего поля – Удаление Программирование и отладка функций для работы элемента «TextItem»: – создание – редактирование – удаление Заводовский: Программирование и отладка функций для работы элемента «Arrow»: – Создание – Удаление

Распределение обязанностей Шалыгина: Программирование и отладка функций для работы с файлом: Составление структуры ide файла Осуществление записи ide файла Редактирование ide файла, Считывание ide файла Реализация функции «Создать», Реализация функции «Сохранить », «Сохранить как» Реализация функции «Открыть» Куц: Тестирование программы Проектирование интерфейса Составление плана работ Предложение концепции выбора технологии

Методика испытаний 1Создание стандартной рамки Вход: данные, необходимые для заполнения рамкиВыход: на рабочей области работает Статус: работает 2Добавление ICOM блока Вход: Выбор элемента «ICOM блок» и размещение его на рабочей области Выход: Появление элемента «ICOM блок» и размещение его на рабочей области Статус: работает 3Соединение блоков стрелками Вход: Выбор элемента «стрелка» и соединение ею двух ICOM блоков Выход: Появление элемента «стрелка» на рабочей области Статус: работает 4Удаление стрелки Вход: выделение стрелки и нажатие кнопки «удалить» Выход: стрелка удаляетсяСтатус: работает 5Удаление ICOM блока Вход: выделение ICOM блока и нажатие кнопки «удалить» Выход: ICOM блок удаляетсяСтатус: работает 6Аннотирование блока Вход: выделение ICOM блока, нажатие кнопки «добавить текст» Выход: добавлен текст к блокуСтатус: работает

Методика испытаний 7Аннотирование стрелок Вход: Выделение стрелки, нажатие кнопки «добавить текст» Выход: добавлен текст к стрелке Статус: работает 8Перетаскивание блока Вход: Нажатие левойкнопкой мыши на ICOM блок и перенос на другое место на сцене Выход: Блок изменил свои координаты на сцене Статус: работает

Полученные результаты По результатам проделанных работ стало возможно использовать следующие функции: Создание следующих компонентов диаграммы IDEF0 на рабочей области: функционального ICOM-блока; интерфейсной дуги; комментариев. Перемещение компонентов диаграммы последовательности на рабочей области путем перетаскивания мышкой (с помощью технологии drag and drop). Удаление компонентов и связанных с ней элементов диаграммы с рабочей области: функционального ICOM-блока; интерфейсной дуги; комментариев. Установка фокуса на элемент диаграммы (для реализации функций удаления и технологии drag and drop). Редактирование название компонента диаграммы, изменение текста без удаления самой надписи. Ассоциирование комментариев с конкретными компонентами диаграммы. Сохранение и загрузка диаграммы в файл с расширением.xml Экспорт изображения

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

Перспективы По результатам второго релиза наша команда готова предоставить заказчику редактор IDEF0 диаграмм с полным перечнем функций, заявленных в требованиях. Мы надеемся, что Вам понравились результаты работы на первом релизе. Нам приятно будет сотрудничать с Вами в дальнейшем. С уважением, Шалыгина М.М., Заводовский В.Б., Куц Д.В., Насонов А, А.

IDEF0 methods are intended to model the functions of a process, creating a graphical model that displays: what controls the function, who makes it, what resources are used and how they are connected with other functions. The IDEF0 tool is used to model the decisions, actions, and activities of a software system during the development process . IDEF0 diagram graphically depicts a model of a desired version of the application. ConceptDraw PRO allows you to create and communicate the IDEF0 diagrams of any complexity.

Swim Lane Diagrams are the kind of process flow diagrams and effective tool for documenting the business processes required for any business company for its productive work, for easy defining the weak points, reasons of defects, or delays during the process. Swim Lane Diagram is based on the IDEF3 standard and was developed primarily for using in projecting. Its name derives from the use of horizontal or vertical lanes. The blocks that denote the parts of the processes are arranged within definite lanes according to the belonging to responsible worker. So the process of any complexity is visually divided into the parts and represented with indication the responsibility for execution of each part. This significantly facilitates the comprehension of its work. Use the ConceptDraw PRO software and predesigned vector objects from the Swim Lanes library of Business Process Mapping Solution included to ConceptDraw Solution Park to easy develop Swim Lanes Flowcharts and Diagrams, for modeling and documenting the business processes in a simple and visual graphic form.