16
1) Частные бизнес-процессы являются внутренними для конкретной
организации и не пересекают пулы или организационные границы.
2) Абстрактные бизнес-процессы. Это происходит между частным /
внутренним процессом и другим участником или процессом. Абстрактный
процесс показывает внешнему миру последовательность сообщений,
необходимых для взаимодействия с частным процессом. Он не показывает сам
частный / внутренний процесс.
3) Совместные бизнес-процессы. Они показывают взаимодействие
между двумя или несколькими бизнес-объектами [15, с. 49].
1.2.5 Методология UML
UML (Unified Modeling Language) представляет собой стандартизованный
язык моделирования, состоящий из интегрированного набора диаграмм,
разработанных для помощи разработчикам систем и программного обеспечения
для определения, визуализации, построения и документирования артефактов
программных систем, а также для моделирования бизнеса и других
непрограммных систем. UML включает в себя набор лучших инженерных
практик, которые оказались успешными при моделировании больших и
сложных систем [12, с. 32].
UML является важной частью разработки объектно-ориентированного
программного обеспечения и процесса разработки программного обеспечения.
В основном UML использует графические обозначения для выражения дизайна
программных проектов. Использование UML помогает командам проекта
взаимодействовать, исследовать потенциальные проекты и проверять
архитектурный дизайн программного обеспечения [18, с. 11].
Целью UML является предоставление стандартной нотации, которая
может использоваться всеми объектно-ориентированными методами, а также
выбор лучших элементов нотификаций предшественников. UML был
разработан для широкого спектра приложений, следовательно, он
предоставляет конструкции для широкого спектра систем и видов деятельности
17
(например, распределенные системы, анализ, проектирование и развертывание
системы) [22, с. 80].
Поскольку стратегическая ценность программного обеспечения
возрастает для многих компаний, отрасль ищет методы автоматизации
производства программного обеспечения и повышения качества и сокращения
затрат и времени выхода на рынок. Эти методы включают компонентную
технологию, визуальное программирование, шаблоны и рамки. Предприятия
также ищут методы для управления сложностью систем по мере их увеличения
масштабов и масштаба. В частности, они признают необходимость решения
повторяющихся архитектурных проблем, таких как физическое распределение,
параллелизм, репликация, безопасность, балансировка нагрузки и
отказоустойчивость. Кроме того, разработка World Wide Web, упрощая
некоторые вещи, усугубила эти архитектурные проблемы. Унифицированный
язык моделирования (UML) был разработан для удовлетворения этих
потребностей. Основные цели в разработке UML в фундаментальном объектно-
ориентированном дизайне являютcя [6, с. 32]:
Предоставление пользователям готового, выразительного языка
визуального моделирования, чтобы они могли разрабатывать и обменивать
модели.
Предоставление механизмов расширения и специализации для
расширения основных концепций независимо от конкретных языков
программирования и процессов разработки.
Повышение роста рынка инструментов.
Поддержка концепций развития более высокого уровня, таких как
сотрудничество, структуры, шаблоны и компоненты.
Интеграция лучших практик.
Следует отметить, что в UML есть много разных диаграмм (моделей).
Причина этого в том, что можно смотреть на систему с разных точек зрения. У
разработки программного обеспечения будет много заинтересованных сторон,
18
играющих важную роль: аналитики, программисты, веб-дизайнеры, менеджеры
контроля качества и др.
Все эти люди заинтересованы в различных аспектах системы, и каждый
из них требует различного уровня детализации. Например, веб-дизайнер
должен понимать дизайн системы и иметь возможность преобразовать дизайн в
код низкого уровня. Напротив, программист заинтересован в поведении
системы в целом и должен понимать, как функционирует продукт. UML
помогает предоставить язык программирования настолько выразительным, что
все заинтересованные стороны могут извлечь выгоду из одной диаграммы
UML.
IDEF (Integrated Definition) - это графическая методология
моделирования процессов, используемая для внедрения систем и инженерного
программного обеспечения. Эти методы используются в функциональном
моделировании данных, имитации, объектно-ориентированном анализе и
приобретении знаний [13, с. 14].
IDEF был разработан ВВС США в середине 1970-х годов, как
стандартный метод документирования и анализа бизнес-процессов. Теперь эта
методология используется как регламентированный подход к анализу
предприятия, захват моделей процессов «как есть» и для моделирования
действий в рамках бизнес-группы. Несмотря на то, что IDEF был
первоначально разработан для производственной среды, теперь эта
методология моделирования процессов применяется для более широкого
использования и для разработки программного обеспечения в целом [6, с. 32].
IDEF относится к семейству языков моделирования, который включает 16
различных методов. Эти методы моделирования процессов охватывают
широкий спектр применений, и каждый метод захватывает определенный тип
данных [17, с. 32].
Наиболее часто используемые методами являются DEF0 – IDEF4.
Рассмотрим, каким образом работает стандарт Idef0.
19
IDEF0 во многих отношениях является очень простым методом. Одним из
примеров этого является то, что в методологии есть только один тип блоков.
Каждый блок представляет собой один процесс, как и другие подходы, но
IDEF0 отличается при использовании и размещения стрелок. Как и обычные
входы и выходы, существуют два других типа стрелок, которые представляют
собой «элементы управления» и «механизмы».
Элементы управления являются формой ввода, но используются для
направления активности в процессе. Иногда возникает некоторая
неопределенность относительно того, является ли элемент входным или
управляющим. Простым способом их отличия является то, что входные данные
каким-либо образом преобразуются или изменяются для создания выходов, в то
время как элементы управления редко изменяются. Стандарты, планы,
шаблоны и контрольные списки - все формы контроля.
Механизмы - это ресурсы и инструменты, необходимые для завершения
процесса. Сюда входят люди с особыми навыками, машинами и другими
инструментами.
Четыре типа стрелок, входы, элементы управления, выходы и механизмы
совместно называются ICOM, а IDEF - сокращением ICOMDEFinition. На
IDEF0 есть нуль, поскольку существует ряд дополнительных стандартов
IDEF [2, с. 32].
Различные стрелки ICOM идентифицируются рядом с полем действия, к
которому они прикасаются. Таким образом, входы находятся слева, элементы
управления сверху, выходы справа и механизмы внизу. Это может сделать
диаграммы немного сложнее, но сделать их более легко читаемыми.
20
Рисунок 2 - Функциональный блок IDEF0
Когда на диаграмме имеется много стрелок, они могут сделать диаграмму
менее читаемой, поэтому стрелки могут быть объединены. Стрелки всегда
называются, поэтому, когда они расщепляются, должно быть ясно, что они
представляют.
Каждая диаграмма IDEF0 состоит из трех-шести полей операций с
стрелками ICOM, соединяющими ящики. Каждый блок действий может быть
разбит, чтобы показать подпроцесс, который он представляет. Когда это
произойдет, стрелки ICOM, которые вводят и оставляют окно, обычно
появляются в разложенном процессе. Это не принудительно, и когда стрелки не
появятся на разложенной диаграмме, стрелка содержит круглые скобки вокруг
нее. Аналогично, когда новая диаграмма ICOM используется на диаграмме,
которая не была показана на родительской диаграмме, скобки используются в
начале стрелки [17, с. 32].
Нумерация используется для связывания диаграмм вместе. Каждая
диаграмма имеет A-номер. Диаграмма верхнего уровня, содержащая один поле
активности, называется диаграммой A-0 (минус нуль). Диаграммы нижнего
уровня нумеруются в соответствии с полем, из которого они были начаты
21
процессы, поэтому первый квадрат на диаграмме A0 становится A1, причем
первое поле на этой диаграмме становится A11 и т. д.
Каждая диаграмма также имеет «C-число», в котором учитываются
последовательные версии одной и той же диаграммы. Номер C может
сопровождаться предыдущим C-номером в круглых скобках, чтобы обеспечить
историческую привязку. Линии ICOM нумеруются сверху и слева, поэтому
самый левый элемент управления - C1, а следующий - C2 и так далее [7, с. 32].
Ниже представлена декомпозиция бизнес-процессов в виде схем.
Рисунок 3 - Декомпозиция бизнес-процессов IDEF0
Четыре типа стрелок, входы, элементы управления, выходы и механизмы
совместно называются ICOM, а IDEF - сокращением ICOM. На IDEF0 есть
нуль, поскольку существует ряд дополнительных стандартов IDEF.
Различные стрелки ICOM идентифицируются рядом с полем действия, к
которому они прикасаются. Таким образом, входы находятся слева, элементы
управления сверху, выходы справа и механизмы внизу. Это может сделать
диаграммы немного сложнее, но сделать их более легко читаемыми.
22
В Данной проектно-аналитической работе будет использоваться метод
IDEF0. Он используется для моделирования функций предприятия и создает
графическую модель, которая показывает, что контролирует функцию, кто ее
выполняет, какие ресурсы используются, что она производит и какие
отношения она имеет для других функций.
Таким образом, данный выбор обосновывается тем, что IDEF0 имеет ряд
больших преимуществ:
IDEF0 может использоваться практически во всех возможных
областях, в промышленности или в области технологий.
Диаграммы IDEF0 легко воспринимаются.
IDEF0 подробно описывает формальную методологию для
процессов именования, диаграмм.
IDEF0 может использоваться как полезный инструмент для
проектирования процесса.
IDEF0 позволяет увидеть значение выходного процесса, чтобы
убедиться, что дизайн процессов является практичным [25, с. 16].
1.3. Особенности бизнес-моделирования в предпринимательской
деятельности
N. Melao и M. Pidd [9, с. 31], в своей работе сосредоточены
исключительно на бизнес-процессах и их моделировании. Они принимают
четыре разных точки зрения для понимания характера бизнес-процессов, а
затем определяют наиболее общие подходы к моделированию для каждой из
них.
Первая – рассматривает бизнес-процессы как детерминированные
машины, то есть как фиксированную последовательность четко определенных
действий, которые преобразуют входные данные в результаты для достижения
четких целей. Для этой точки зрения достаточно моделирование статического
23
процесса с помощью таких методов, как интегрированные методы определения
(IDEF0, IDEF3) и диаграммы активности роли (RAD).
Вторая – рассматривает бизнес-процессы как сложные динамические
системы, сборки взаимозаменяемых компонентов. Эта вторая точка зрения
фокусируется на сложных, динамических и интерактивных функциях бизнес-
процессов. Авторы предлагают моделирование дискретных событий как
подходящий способ моделирования динамического поведения этого подхода.
Третья – это взаимодействие циклов обратной связи, которые выделяют
структуру обратной связи информации в бизнес-процессах. Для этой
перспективы рекомендуются динамические системы.
И последняя – это социальная составляющая, где акцентируется
внимание на людях/сотрудниках. Это люди, которые создали и внедряют
бизнес-процессы, люди с разными ценностями, ожиданиями и ролями.
Эта сторона бизнес-процессов может быть смоделирована с помощью
неструктурированных иллюстративных моделей. Однако реальный бизнес-
процесс включает в себя элементы для всех четырех перспектив, и,
следовательно, очевидно, что такого метода моделирования не существует,
который может охватывать все эти разнообразные характеристики, которые
составляют бизнес-процесс.
Автор R. S. Aguilar-Saven [1, с. 44] представляет основные методы
моделирования процессов и классифицирует их на основе двух измерений:
первое измерение с четырьмя различными целями использования и
классифицирует модели бизнес-процессов на основе того, являются ли они:
1) описательными для обучения;
2) обеспечивают поддержку принятия решений для
разработки/проектирования процессов;
3) обеспечивают поддержку принятия решений для выполнения процесса;
4) обеспечивают поддержку информационных технологий (ИТ).
Во втором измерении различаются активные и пассивные модели. В
качестве активных считаются те модели, которые позволяют пользователю
24
взаимодействовать с ними (динамическая модель), в то время как пассивные -
те, которые не предоставляют эту возможность.
Предлагаются три группы для классификации методов моделирования
бизнес-процессов, как показано на рисунке 1.
Первая группа (диаграммные модели) включает модели бизнес-
процессов, которые представляют бизнес-процесс с использованием
визуальной диаграммы.
Второй группе (математические модели) соответствуют модели, в
которых все элементы имеют математическое или формальное обоснование.
Наконец, третья группа (языки бизнес-процессов) содержит языки на
основе программного обеспечения, которые поддерживают моделирование
бизнес-процессов.
Рисунок 4 - Три группы классификации методов
моделирования
Классификация наиболее типичных методов моделирования показана на
диаграмме Венна на рисунке 4.
На сегодняшний день известно множество методов моделирования
бизнес-процессов и языков, на котором данное моделирование будет
осуществляться (нотация). Эти методы обеспечивают фокус на различные
25
аспекты. Они содержат как графические, так и текстовые инструменты,
благодаря которым возможно визуализировать основные компоненты процесса
и дать точные определения параметров и соотношений элементов.
В основе методов моделирования бизнес-процессов могут лежать как
структурный, так и объектно-ориентированный подходы к моделированию.
1. Методология структурного анализа и проектирования SADT
Методология SADT была разработана Дугласом Россом в 1969г. На ее
основе разработана, в частности, известная методология IDEF0.
Данная методология представляет собой совокупность методов, правил и
процедур. Они предназначены для построения функциональной модели объекта
какой-либо предметной области. Данная модель отображает производимые
объектом действия и связи между ними (рис. 5) [22, с. 19].
Рисунок 5 - Структура SADT модели
Отличительной данной методологии является строгость и точность.
Основными правилами SADT являются:
- ограниченное количество блоков на каждом уровне декомпозиции (как
правило, их бывает 3-6);
- связность диаграмм (номера блоков);
- уникальность меток и наименований, т.е. отсутствуют повторяющиеся
имена);
- различные синтаксические правила для графики (блоков и дуг);
- разделение входов и управлений (правило определения роли данных).