Методы и средства моделирования бизнес-процессов

Преимущества и недостатки использования IDEF0

Преимущества

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

Недостатки

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

Задание 2. Знакомство с компонентами диаграммы потоков данных (DFD) в BPwin

Ознакомьтесь с результатом использования DFD для описания процесса отгрузки горючего (рис.1).

На диаграмме продемонстрированы процессы, преобразующие входные данные в выходные.

Рис. 1. Диаграмма потоков данных процесса отгрузки горючего

Основными компонентами диаграммы потоков данных являются:

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

Рис.2. Изображение процесса

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

Рис. 3. Потоки данных

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

Рис. 4. Внешняя сущность

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

Рис. 5. Изображение хранилища данных (накопителя)

Процессы, хранилища имеют номера. Подчиненные блоки отображают уровни иерархии в номерах (рис. 6).

Классы и объекты

Класс – некоторый тип объектов (множество похожих объектов),Экземпляр – конкретный объект (представитель класса).

Объекты имеют:
имя (через двоеточие может быть указано имя класса)
свойства — описываются с помощью атрибутов
поведение — представляется с помощью операций

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

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

Преимущества и недостатки каждой диаграммы

Диаграмма DFD:

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

Недостатки диаграммы DFD:

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

Диаграмма IDEF0:

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

Недостатки диаграммы IDEF0:

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

Консалтинг при автоматизации предприятий: подходы, методы, средства

Глава 17
ОБЗОР РОССИЙСКОГО РЫНКА CASE-СРЕДСТВ

17.1. Краткое описание основных возможностей пакетов Продукты
фирмы CA (BPWin, ERWin)

Пакет BPWin основан на методологии IDEF0 и предназначен для функционального
моделирования и анализа деятельности предприятия. Модель в BPWin представляет
собой совокупность SADT-диаграмм, каждая из которых описывает отдельный
процесс в виде разбиения его на шаги и подпроцессы. С помощью соединяющих дуг
описываются
объекты, данные и ресурсы, необходимые для выполнения функций. Имеется
возможность для любого процесса указать стоимость, время и частоту его выполнения.
Эти
характеристики в дальнейшем могут быть просуммированы с целью вычисления
общей стоимости затрат — таким образом выявляются узкие места технологических
цепочек,
определяются затратные центры. BPWin может импортировать фрагменты информационной
модели из описываемого ниже средства проектирования баз данных ERWin
(при этом сущности и атрибуты информационной модели ставятся в соответствие
дугам
SADT-диаграммы).
Генерация отчетов по модели может осуществляться в формате MS Word и
MS Excel. Требования к ресурсам:

процессор — Intel 386 и выше
память — 8 Mb RAM
операционная система — MS Windows 3.1 или Windows 95.

Семейство продуктов ERWin предназначено для моделирования и создания баз
данных произвольной сложности на основе диаграмм “сущность-связь”.
В настоящее время
ERWin является наиболее популярным пакетом моделирования
данных благодаря поддержке широкого спектра СУБД самых различных классов:
SQL-серверов
(Oracle, Informix,
Sybase SQL Server, MS SQL Server, Progress, DB2, SQLBase,
Ingress, Rdb и др.) и “настольных” СУБД типа XBase (Clipper, dBASE, FoxPro,
MS Access,
Paradox
и др.).
Информационная модель представляется в виде диаграмм
“сущность-связь”, отражающих основные объекты предметной
области и связи
между ними. Дополнительно определяются
атрибуты сущностей, характеристики связей, индексы и
бизнес-правила, описывающие ограничения и закономерности
предметной области.
После создания ER-диаграммы
пакет автоматически генерирует SQL-код для создания таблиц,
индексов и других объектов базы данных. По заданным бизнес-правилам
формируются
стандартные
триггеры БД для поддержки целостности данных, для сложных
бизнес-правил можно
создавать
собственные триггеры, используя библиотеку шаблонов.
Пакет может осуществлять реинжиниринг существующих БД:
по SQL-текстам автоматически генерируются ER-диаграммы.
Таким образом, пакет
полностью поддерживает
технологию FRE (forward and reverse engineering), последовательность
этапов которой
приведена ниже:

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

Для разработки клиентской части приложения имеются
специальные версии пакета, обеспечивающие интеграцию
с такими инструментами
как SQLWindows,
PowerBuilder,
Visual Basic, Delphi. Предлагаются и усеченные
версии продукта:

ERWin/SQL, обеспечивающая лишь прямое проектирование
для любых СУБД
ERWin/Desktop, поддерживающая технологию
FRE только для“настольных” СУБД.

Требования к ресурсам, необходимым для функционирования пакета, совпадают
с приведенными выше соответствующими требованиями для пакета BPWin.

Для коллективной разработки модели БД предназначен специальный продукт ModelMart,
позволяющий контролировать версии модели, гибко распределять права доступа
между членами группы, строить библиотеки моделей, осуществлять объединение
моделей и т.п. Продукт построен в архитектуре “клиент-сервер”, репозитарий
использует одну из трех СУБД — Oracle, Sybase, MS SQL Server и требует 32 Mb
RAM и 50 Mb HDD. ERWin-клиент для своего функционирования требует процессор
Intel 486 или Pentium, 16 Mb RAM и 10 Mb HDD.

Диаграммы потоков данных DFD (Data Flow Diagrams)

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

DFD содержит процессы, которые преобразуют данные, потоки данных, которые переносят данные, активные объекты, которые производят и потребляют данные, и хранилища данных, которые пассивно хранят данные.

Инструменты моделирования бизнес-процессов

В России для моделирования и анализа бизнес-процессов чаще всего применяются следующие инструменты моделирования: Oracle Designer, Rational Rose, AllFusion Process Modeler (BPWin) и AllFusion ERwin Data Modeler(ERWin), Power Designer, ARIS. За рубежом, кроме перечисленных, активно используются такие средства как Ithink Analyst, System Architect, ReThink и т.д.

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

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

Выберем те инструменты моделирования, которые соответствуют выделенным критериям. В этом случае дальнейшему рассмотрению подлежат Oracle Designer, BPWIn/ERWin, Rational Rose, ARIS, Power Designer, по которым ниже дано более подробное описание.

Элементы диаграммы последовательности

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

Отношение сообщения моделирует материальный или информационный поток.
Прием сообщений инициирует выполнение некоторого действия получателем

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

Зачем нужна нотация DFD?

Исторически синтаксис этой нотации применяется в двух вариантах — Йордана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Различия между ними – в таблице ниже:

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

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

Из чего состоит информационная система?
Что нужно, чтобы обработать информацию?

Непосредственно DFD нотация состоит из следующих элементов:

Процесс (англ. Process), т.е. функция или последовательность действий, которые нужно предпринять, чтобы данные были обработаны. Это может быть создание заказа, регистрация клиента и т.д. В названиях процессов принято использовать глаголы, т.е. «Создать клиента» (а не «создание клиента») или «обработать заказ» (а не «проведение заказа»). Здесь нет строгой системы требований, как, например, в IDEF0 или BPMN, где нотации имеют жестко определенный синтаксис, так как они могут быть исполняемыми. Но все же определенных правил стоит придерживаться, чтобы не вносить путаницу при чтении DFD другими людьми.
Внешние сущности (англ. External Entity). Это любые объекты, которые не входят в саму систему, но являются для нее источником информации либо получателями какой-либо информации из системы после обработки данных. Это может быть человек, внешняя система, какие-либо носители информации и хранилища данных.
Хранилище данных (англ. Data store). Внутреннее хранилище данных для процессов в системе. Поступившие данные перед обработкой и результат после обработки, а также промежуточные значения должны где-то храниться. Это и есть базы данных, таблицы или любой другой вариант организации и хранения данных. Здесь будут храниться данные о клиентах, заявки клиентов, расходные накладные и любые другие данные, которые поступили в систему или являются результатом обработки процессов.
Поток данных (англ. Data flow). В нотации отображается в виде стрелок, которые показывают, какая информация входит, а какая исходит из того или иного блока на диаграмме.

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

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

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

Пакет Designer/2000 (Oracle)

Designer/2000 — инструмент, работающий в среде MS Windows и развивающий подход
фирмы Oracle к созданию и сопровождению сложных информационных систем.
В основе подхода лежит собственная методология фирмы CASE*Method, базирующаяся
на структурном
анализе и проектировании системы, четком разбиении ее жизненного цикла
на
этапы, автоматизации перехода между этапами.
Центральной частью пакета является репозитарий, содержащий спецификации
проекта на всех его этапах и обеспечивающий согласованную работу всех его
участников.
Для доступа к репозитарию и управления им используется специальное средство
(навигатор по объектам репозитария), позволяющее просматривать и модифицировать
объекты, хранящиеся в репозитарии, а также осуществлять административные
функции: удаление, управление доступом, экспорт/импорт и т.п.
Первым этапом методологии является моделирование и анализ процессов, т.е.
построение моделей деятельности предприятия, выявление их недостатков и
возможных источников
усовершенствования. Поддерживающие средства позволяют строить наглядные
представления процессов и их взаимосвязей, а также анализировать их с использованием
средств
мультимедиа.
Второй этап (системное моделирование) предполагает разработку детальных
концептуальных моделей предметной области и фактически является этапом
выявления, анализа
и формализации требований к будущей системе. Для описания используются
диаграммы “сущность-связь”, диаграммы иерархии функций и диаграммы потоков
данных.
Третий этап (системное проектирование) на основании концептуальных моделей
вырабатывает технические спецификации будущей системы, при этом первоначальный
вариант спецификаций может быть получен автоматически. На этом этапе применяются
диаграммы схем БД (расширения ER-диаграмм), диаграммы взаимодействий модулей
(аналог структурных карт Джексона) и схемы модулей, описывающие структуру
модулей с позиций используемых в них данных.
Наконец, на четвертом этапе (генерация приложений) создаются программы,
отвечающие требованиям проектных спецификаций. Так генератор серверной
части по спецификации
БД автоматически генерирует SQL-тексты, а генераторы приложений строят
экранные формы и отчеты. При необходимости сгенерированные тексты могут
быть доработаны
с помощью дополнительного пакета Developer/2000.
Имеется облегченная версия пакета (Database Designer), основанная на диаграммах
“сущность-связь” и предназначенная для создания информационных моделей.

Разница в нотации при построении диаграммы DFD и IDEF0

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

Диаграмма потоков данных (DFD)

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

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

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

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

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

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

Список использованной литературы

Агальцов, В.П. Базы данных. В 2-х т. Т. 2. Распределенные и удаленные базы данных: Учебник / В.П. Агальцов. — М.: ИД ФОРУМ, НИЦ ИНФРА-М, 2013. — 272 c.
Бритов Г., Осипова Т. Моделирование бизнес-процессов. — М.:LAP, 2014. – 124 с.
Голицына, О.Л. Базы данных: Учебное пособие / О.Л. Голицына, Н.В. Максимов, И.И. Попов. — М.: Форум, 2012. — 400 c.
Давыдова Е. М. Базы данных Учеб. пособие для вузов / Е. М. Давыдова, Н. А. Новгородова. — 3-е изд., перераб. и доп. — Томск : В-Спектр, 2012. — 128 с.
Дейт К.Дж. Введение в системы баз данных. — К.: Диалектика, 2012. — 360 c.
Илюшечкин В. Основы использования и проектирования баз данных. Учебник. — М.:Юрайт, 2014. — 214с.
Исаев Г. Проектирование информационных систем. Учебное пособие. — М.: Омега-Л, 2015. — 432с.
Карпова, И.П. Базы данных: Учебное пособие / И.П. Карпова. — СПб.: Питер, 2013. — 240 c.
Кириллов, В.В. Введение в реляционные базы данных.Введение в реляционные базы данных / В.В. Кириллов, Г.Ю. Громов. — СПб.: БХВ-Петербург, 2012. — 464 c.
Кит Т. Томпсон Автоматизация продаж. Умный подход. — М.: Вершина, 2016 — 272 с.
Коваленко В. Проектирование информационных систем. — М.: Форум, 2012. — 320с.
Кузин, А.В. Базы данных: Учебное пособие для студ. высш. учеб. заведений / А.В. Кузин, С.В. Левонисова. — М.: ИЦ Академия, 2012. — 320 c.
Кузнецов С. Базы данных. — М.: Academia, 2012. — 496с.
Малыхина М. Базы данных. Основы, проектирование, использование. — СПб.: БХВ-Петербург, 2012. — 528с.
Марков А.С., Лисовский К.Ю. Базы данных. Введение в теорию и методологию: Учебник. – М.: Финансы и статистика, 2015. – 512 с.
Пирогов, В.Ю. Информационные системы и базы данных: организация и проектирование: Учебное пособие / В.Ю. Пирогов. — СПб.: БХВ-Петербург, 2014. — 528 c.
Редько В.Н., Бассараб И.А. Базы данных и информационные системы. — М.: Знание, 2015. — 602 c.
Уткин В., Балдин К. Информационные системы в экономике. — М.: Academia, 2012. — 288с.
Хаббард Дж. Автоматизированное проектирование баз данных — М.: Мир, 2014. — 453 c.
Шаймарданов Р.Б. Моделирование и автоматизация проектирования структур баз данных — М.: Юнити, 2016. — 469 c.

Приложение

Текст регламента

Кадровая стратегия в системе стратегического управления организацией
Диагностика и построение корпоративной культуры (Содержание понятия корпоративной культуры, ее функции и основные признаки)
Понятие и виды трудового стажа
Организация безналичных расчетов в банках на примере коммерческого банка ПАО УралСиб (Теоретические основы организации безналичных расчетов)
Ценообразование на спортивные товары и услуги.
Валютные отношения и валютная система. Валютный контроль
Кадровая стратегия в системе стратегического управления организацией (Виды кадровых стратегий)
Формирование лояльности персонала в организации
Кадровая стратегия в системе стратегического управления организацией (Теоретические положения стратегии организаций)
Специфика использования человеческих факторов
Применение программных средств создания серверных программ
Основы программирования на языке Pascal (Использование процедур в языке Pascal)

Методы моделирования бизнеса

Структурные методы

Основаны на последовательной декомпозиции системы на все более мелкие подсистемы.

Принципы структурного подхода:

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

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

Наибольшее распространение получили методологии:

IDEF0 – функциональные модели, основанные на методе SADT;
IDEF1X – диаграммы данных «сущность-связь» (ERD);
IDEF3 — диаграммы потоков работ (Work Flow Diagrams);
DFD — диаграммы потоков данных (Data Flow Diagrams).

Методы объектно-ориентированного моделирования

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

Наиболее известные методы:

Booch’93 Г. Буча,
OMT Дж. Румбаха
OOSE А. Джекобсона
UML (Unified Modeling Language) – на основе Booch’93, OMT, OOSE

Главным структурообразующим элементом является объект.В программировании объект — это структура, объединяющая данные и процедуры.В модели бизнеса объекты – это участники бизнес-процесса (активные объекты) и пассивные объекты (материалы, документы), над которыми выполняют действия активные объекты.

Методы имитационного моделирования

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

Наиболее распространенные методы:

сети Петри и раскрашенные сети Петри (CPN, Colored Petri Nets);
GPSS (General Purpose Simulating System) – унифицированный язык имитационного моделирования;
SIMAN (SIMulation ANalysis) – язык визуального моделирования.

Интегрированные методы

Интегрированные методы моделирования объединяют различные виды моделей – структурного анализа, объектно-ориентированные, имитационные и др.

ARIS (Architecture of Integrated Information System) позволяет отражать в единой интегрированной модели: оргструктуры, функции, данные, процессы. Использует множество типов моделей.
G2 — методология создания динамических интеллектуальных систем позволяет моделировать процессы с использованием знаний эксперта.
BRM (Business Rules Management) – методология управления бизнес-правилами.

Применение DFD и IDEF0 в практике

DFD в практике

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

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

IDEF0 в практике

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

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

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

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

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

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

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

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

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