Курсовая работа студента (-ки) группы (фамилия, имя, отчество)

1. Теоретические основы изучаемой темы

1.1Обзор информационных технологий для моделирования и автоматизации бизнес-процессов предприятия

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

Наиболее трудоемкими этапами разработки информационных систем являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую информационную систему, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями [3].
В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Современный рынок программных средств насчитывает более 300 различных CASE- средств¹.
На сегодняшний день существует достаточно много обзоров CASE-средств и их сравнений. Но как сама область визуального моделирования, так и инструментальные средства быстро развиваются – существующие языки устаревают, появляются новые конкурентные средства и технологии, требующие соответствующей поддержки.
На рисунке 1.1 представлен обзорный список современных CASE- средств с подробным описанием функционала. В данной главе более подробно описаны несколько средств проектирования.

Рис.1.1 – Обзор современных CASE- средств
Модели бизнес-процессов не следует путать с картами процессов — еще одним распространенным типом диаграмм бизнес-процессов[11]. Карты процессов основаны на отчетах сотрудников, создаются вручную и обеспечивают представление рабочих процессов более высокого уровня. Модели процессов — это углубленные исследования, основанные на данных, которые представляют более объективные представления о рабочих процессах².
В данном разделе необходимо изучить понятие и сущность языка моделирования бизнес-процессов. Язык моделирования бизнес-процессов (BPML) — это метаязык стандарта XML, используемый для описания бизнес-процессов в простой для понимания форме. Он может охватывать все части бизнес-процесса, такие как транзакции, исключения, потоки данных, запланированные события, роли и безопасность. Он был заменен языком выполнения бизнес-процессов (BPEL) и в конечном итоге был полностью заменен нотацией моделирования бизнес-процессов (BPMN). Многие из его стандартов потока процессов были использованы для обогащения более позднего стандарта Unified Modeling Language (UML). Назначение BPML
BPML был разработан как полноценный язык, способный выразить любой бизнес-процесс. Эти процессы могут быть выражены как в виде высокоуровневой блок-схемы, так и в виде стандартного кода XML. Это позволило программистам, руководителям и бизнес-аналитикам понимать и совместно работать над процессами.
BPML ориентирован на веб-службы со структурой, ориентированной на конкретные действия. Простые действия — это предопределенные функции, такие как назначение, вызов или передача. Сложные функции могут быть построены путем объединения простых действий[2].
Код BPML можно ввести в системы программного обеспечения для управления бизнес-процессами (BPMS) и непосредственно внедрить.
BPML был впервые разработан Инициативой управления бизнес-процессами (BPMI) в 2000 году и официально опубликован в 2001 году. Он не получил широкого распространения в существующих механизмах управления бизнес-процессами, поскольку предпочтение отдавалось более простому BPEL. После слияния BPMI и Object Management Group (OMG), другой организации по стандартизации, BPML был официально объявлен устаревшим для более полной BPMN в 2008 году. BPEL больше не используется активно, но его наследие как одного из первых метаязыков XML для бизнес-процессов установили применимость этих стандартов³.
BPML и BPEL — это разные языки, которые могут выражать схожие процессы. Оба они могут выражать взаимодействие с веб-службой с помощью XML-кода. BPEL4WS (BPEL для веб-служб) было проще реализовать, и поэтому он использовался несколькими приложениями бизнес-процессов, такими как сервер Microsoft BizTalk. По сравнению с BPML, BPEL не мог выразить все операции и нуждался в вспомогательных веб-языках для заполнения некоторых недостающих функций.
BPMN формально заменил BPEL в качестве стандарта, поскольку обе методологии играли одинаковую роль. Оба стандарта поддерживают использование как XML-кода, так и нотации графической блок-схемы.
UML включает в себя многие идеи BPML, например нотацию процессов. UML был разработан только для общего моделирования структуры и потока программного обеспечения, он не может быть непосредственно реализован системой, как исполняемый код, такой как BPML.
Business Process Master List— это совершенно отдельная сущность по сравнению с языком моделирования бизнес-процессов (BPML). Поскольку оба могут использоваться в контексте бизнес-процесса, их легко спутать. Мастер-лист бизнес-процессов — это стандартная диаграмма SAP, которая помогает определить весь проект для руководства реализацией. Он определяет сценарии, бизнес-процессы и транзакции в виде диаграммы Microsoft Excel. Язык BPMN основан на блок-схемах и графических обозначениях. Обозначения разделены на четыре категории для построения диаграмм:
Опишем, как работает BPMN. Объекты потока: описательные объекты, которые используются для определения процесса, такие как события, действия и шлюзы. Как правило, процессы запускаются начальным событием, имеют действия/задачи и шлюзы (точки принятия решений) в середине и завершаются конечным событием. Сложные процессы также включают в себя подпроцессы и промежуточные события, а также различные типы шлюзов, чтобы показать, как рабочий процесс перемещается по диаграмме. Например, эксклюзивный шлюз имеет только один вариант перемещения, инклюзивный шлюз имеет варианты, основанные на решении, принятом на шлюзе, а параллельные шлюзы представляют собой две параллельные задачи в рабочем процессе.
Соединяющие объекты: символы, которые используются для соединения объектов потока, таких как потоки сообщений, потоки последовательности и ассоциации. Потоки представлены пунктирными или прямыми линиями со стрелками, в то время как ассоциации используют пунктирную линию, чтобы показать, что определенные документы или артефакты связаны с событием или шлюзом[15].
Плавательные дорожки: контейнеры, которые отделяют набор действий от других, таких как бассейны и дорожки. На диаграммах BPMN пулы представляют основных участников процесса. Другой пул может быть другой компанией, отделом или клиентом, вовлеченным в процесс. Дорожки в пуле показывают действия и поток для определенной роли или участника, определяя, кто отвечает за определенные части процесса⁴.

Рис. 1.1 – Элементы диаграммы
Артефакты: дополнительная информация о процессе, такая как объекты данных, группы и аннотации. Объект данных показывает, какие данные необходимы для действия, группа показывает логическую группировку действий, а аннотация предоставляет подробную информацию о том, что происходит в части диаграммы.
На следующей диаграмме BPMN показан процесс заказа клиентом чеков в банке. Клиент и банк показаны как участники процесса в своих пулах. Различные события и задачи связаны потоками последовательности, как показано в этом примере из документации IBM[16]. (рис.1.1)