Практическая работа в среде ARIS (Методичка). Методические указания по выполнению лабораторных работ введение
 Скачать 2.02 Mb.
|
|
МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ И ИНФОРМАЦИОННЫХ СИСТЕМ В СРЕДЕ ARIS Методические указания по выполнению лабораторных работ ВВЕДЕНИЕ Методология ARIS предполагает определенный подход к формализации информации о деятельности организации и представление ее в виде графических моделей, удобном для понимания и анализа. Модели, создаваемые по методологии ARIS, отражают существующую ситуацию с той или иной степенью приближенности. Степень детализации описания зависит от целей проекта, в рамках которого проводится моделирование. Модели ARIS могут быть использованы для анализа и выработки различного рода решений по реорганизации деятельности предприятия, в том числе по внедрению информационной системы управления, разработке систем менеджмента качества и др. Методология ARIS реализует принципы структурного анализа и позволяет определить и отразить в моделях основные компоненты организации, протекающие процессы, производимую и потребляемую продукцию, используемую информацию, а так же выявить взаимосвязи между ними. Создаваемые модели представляют собой документированную совокупность знаний о системе управления, включая организационную структуру, бизнес-процессы, взаимодействия между организацией и субъектами рынка, состав и структуру документов, последовательность шагов процессов, должностные инструкции отделов и их сотрудников. В отличие от других подходов, методология ARIS предполагает хранение всей информации в едином репозитории, что обеспечивает целостность и непротиворечивость процесса моделирования и анализа, а также позволяет проводить верификацию моделей. К основным преимуществам методологии ARIS относятся:
Инструментальная система ARIS 6.2, реализующая методологию ARIS, предназначена для визуального представления принципов и условий функционирования различного рода организаций, а также для анализа их деятельности по различным показателям. Целью такого анализа является определение требуемых характеристик, реформирование организационной структуры, функций, бизнес-процессов, используемых данных. В рамках среды ARIS имеется также возможность определить требования к автоматизированной системе управления и провести ее проектирование. 1. ОСНОВЫ АРХИТЕКТУРЫ ARIS Методология ARIS основывается на концепции интеграции, предлагающей целостный взгляд на бизнес-процессы, и представляющей собой множество различных методологий, интегрированных в рамках единого системного подхода. Это позволяет говорить об общей архитектуре ARIS. К наиболее важным компонентам архитектуры ARIS относятся типы представления и уровни описания моделируемого объекта. В методологии ARIS выделено пять основных типа представлений (рис. 1): • организационные модели, описывающие иерархическую структуру системы — иерархию организационных подразделений, должностей, полномочий конкретных лиц, многообразие связей между ними, а также территориальную привязку структурных подразделений; • функциональные модели, описывающие функции (процессы, операции), выполняемые в организации; • информационные модели (модели данных), отражающие структуру информации, необходимой для реализации всей совокупности функций системы; • модели процессов/управления, представляющие комплексный взгляд на реализацию деловых процессов в рамках системы и объединяющие вместе другие модели; • модели входов/выходов, описывающие потоки материальных и нематериальных входов и выходов, включая потоки денежных средств.  Рис. 1. Типы представлений Типы представления являются первой компонентой архитектуры. Они позволяют структурировать бизнес-процессы и выделять их составные части, что делает рассмотрение более простым. Применение этого принципа позволяет с различных точек зрения описывать содержание отдельных частей бизнес-процесса, используя специальные методы, наиболее полно соответствующие каждой точке зрения. Это избавляет пользователя от необходимости учитывать множество связей и соединений. В рамках каждого типа представления создаются модели, отражающие ту или иную сторону исследуемой системы. Второй компонент архитектуры ARIS состоит из различных уровней описания. Они ориентированы, в основном, на информационно-техническую организацию бизнеса (рис.2.). Такая концепция обеспечивает целостное описание управления бизнесом, вплоть до его технической реализации.  Рис. 2. Уровни описания Анализ проблем бизнеса является начальной точкой при моделировании. Модели на этом уровне — не очень детальные семантические описания бизнес-процессов, однако они достаточно точно отражают цели, которые стоят перед разработчиками. На этом этапе в описание включаются характеристики будущей модели организации, связанные с бизнес-процессами. Для описания проблем бизнеса используются только семантические модели. Полученные модели еще не содержат достаточно детальной информации и однозначных технических формулировок, чтобы служить исходным материалом для автоматической передачи их непосредственно на этап реализации информационной системы (ИС). На уровне определения требований необходимо описать требования к прикладной информационной системе, создаваемой для решения рассматриваемой проблемы бизнеса. Оно должно поддерживаться формализованным описанием требований с целью последующего использования в качестве стартовой точки для трансляции сформулированных требований в информационную систему. Этот процесс также очень близок к семантическому (смысловому) моделированию. Определение требований тесно связано с описанием проблем бизнеса. Уровень спецификации проекта достигается, как только концептуальные понятия проблем бизнеса, сформулированные на уровне определения требований, трансформируются в категории, связанные с информационными технологиями. На данном уровне описываются уже не функции, а пользовательские или модульные транзакции, которые выполняют функции. Это может рассматриваться как отображение сформулированных требований в категории и методы описания, связанные непосредственно с информационными системами и выраженные в терми нах соответствующих технологий. Таким образом, уровни определения требований и спецификации проекта связаны достаточно тесно. Спецификация проекта может изменяться, не оказывая влияния на результаты предыдущего уровня определения требований. Однако это не означает, что определение требований и спецификация проекта могут прорабатываться независимо друг от друга. После того как завершен этап определения требований, его наиболее важная содержательная часть, отражающая категории управления бизнесом, должна быть определена таким образом, чтобы все, относящееся к области информационных технологий и программных решений (например, производительность информационной системы), не влияло на предметное содержание. На уровне описания реализации спецификация проекта трансформируется в конкретные аппаратные и программные компоненты. Таким образом, осуществляется физическая связь с информационной системой. Отдельные уровни описания имеют различные циклы корректировки. Частота корректировок выше всего на уровне описания реализации и ниже всего на уровне определения требований. Уровень описания реализации очень тесно связан с разработкой информационной системы: на этом уровне производится многократная корректировка функционирования системы по результатам коротких циклов (тестов) ее работы. Уровень определения требований особенно важен, поскольку его можно рассматривать как репозиторий для прикладных программных систем, используемых в течение длительного времени, и как стартовую точку при описании реализации. Документы, созданные на уровне определения требований, имеют наиболее продолжительный жизненный цикл, и благодаря их близости к описанию проблем бизнеса, которое также является документом, они чрезвычайно полезны для разработки информационных систем. По этой причине уровень определения требований, или семантическая модель, имеет наивысший приоритет. Семантические модели образуют связь между пользователями и первоначальным описанием их проблем на языке, ориентированном на категории информационных систем. Создание различных видов моделей и проработка каждой из них по уровням описания в сочетании с формулировкой проблем бизнеса и составляет процесс работы в архитектуре ARIS. Каждый тип представления подвергается разложению на три уровня описания: определение требований, спецификацию проекта и описание реализации (рис.3).  Рис. 3. Представления и уровни описания Таким образом, в архитектуре ARIS зафиксирован набор видов моделей, каждая из которых «расписывается» по уровням. Вместе с описанием проблем бизнеса, которое служит стартовой точкой для анализа, они составляют набор компонент архитектуры ARIS. 2. МОДЕЛИ УРОВНЯ ФОРМИРОВАНИЯ ТРЕБОВАНИЙ 2.1. Организационные модели На сервере LOCAL создайте новую базу данных Auto Business, в которой разместите папки, как показано на рис.4.  Рис. 4. Создание новой базы данных Для обеспечения доступности всех моделей, реализованных в среде ARIS, включите полный методологический фильтр, используя пункт меню Вид Параметры Вход как показано на рис.5 и перезапустите ARIS.  Рис. 5. Включение полного методологического фильтра Приступим к разработке моделей. Начнем со схемы, моделирующей организационную структуру нашей компании. Модель 1: В окне Содержимое элемента Требования (правое окно) для папки Организационные модели используя правую клавишу мыши создайте новую модель Организационная структура (типа Организационная схема) (рис. 6)  Рис.6. Создание новой модели. Используя панель моделирования создайте модель организационной структуры компании (рис.7). Для определения типа и назначения объектов и связей, вносимых в модель, используйте глоссарий, приведенный в приложении.  Рис. 7. Организационная структура компании Обратите внимание, что на приведенном на рис.7 фрагменте, отсутствуют некоторые должностные единицы и сотрудники. Доработайте данную модель самостоятельно. 2.2. Функциональные модели Модель 2: В папке Требования для Функциональных моделей создайте новую модель Целей (типа Диаграмма целей), в которой сформируйте дерево стратегических целей компании (рис.8).  Рис.8. Дерево целей Модель 3: В этой же папке создайте модель Дерево функций (типа Дерево функций), в которой детально декомпозируйте функцию Продажи, как показано на рис.9.  Рис. 9 Дерево функции Продажи 2.3. Модели процессов Концептуальному уровню представленных выше моделей соответствует модели Дерево продуктов/услуг и Диаграмма цепочки добавленного качества. Модель 4: Для моделирования первой структуры создайте в папке Требования (Модели процессов) модель Продукция/услуги (тип Дерево продуктов/услуг), как показано на рис.10.  Рис. 10. Дерево продуктов/услуг Модель 5: Для построения модели Процесс добавления качества (типа Диаграмма цепочки добавленного качества), в той же папке создайте новую модель указанного типа (рис.11).  Рис. 11. Процесс добавления качества Поскольку объекты моделей Дерево функций и Процесс добавления качества являются функциями, эти модели можно связать. Выберите из контекстного меню функции Продажи (диаграмма Процесс добавления качества) пункт Назначения Создать. В появившемся диалоге выберите опцию Существующие модели, а затем – Дерево функций. В результате из функции Продажи диаграммы Процесс добавления качества можно будет попасть на диаграмму Дерево функций. Следующими концептуальными моделями процессов являются Модели управления бизнесом (тип – Диаграмма управления бизнесом) и конкуренции (тип - Модель Конкуренция ). Диаграмма управления бизнесом описывает все потенциальные риски бизнес-процесса и управление ими. Риск означает потенциальную опасность для процесса не достигнуть желаемой цели. Управление риском — это путь исключения риска или уменьшения его степени. Решение по риску означает реализацию управления отдельным риском. Модель конкуренции предназначена для описания связей выпускаемой продукции, партнеров и конкурентов. Создайте отмеченные модели, как показано на рис. 12, 13. Модель 6:  Рис. 12. Модель Риски Модель 7:  Рис. 13. Модель Конкуренция Модель 8: Важнейшей моделью процессов уровня определения требований является модель Событийная цепочка процесса (Extended event driven process chain – EPC). Модель Событийная цепочка процесса отражает последовательность функциональных шагов (действий) в рамках одного бизнес-процесса, которые выполняются организационными единицами, а также ограничения по времени, налагаемые на отдельные функции. Для каждой функции могут быть определены начальное и конечное события, ответственные исполнители, материальные и документарные потоки, сопровождающие модель, а также проведена декомпозиция на более низкие уровни (подфункции и т.д.). Модель Событийная цепочка процесса является наиболее информативной и удобной при описании деятельности подразделений организации.  Рис. 14. Событийная цепочка Процесса продаж Создайте новую модель Процесс продаж (типа EPC) (рис.14). При формировании модели придерживайтесь следующих рекомендаций: • процесс всегда инициируется некоторым свершившимся событием; • процесс всегда направлен сверху вниз; • в центре модели располагаются функции; • справа – элементы оргструктуры (исполнители); • слева – элементы информационных моделей (данные, которые необходимы для реализации функции; • при определении объектов модели используйте уже имеющиеся объекты (элементы организационных и функциональных моделей); • процесс всегда заканчивается некоторым событием. Модель 9: Следующие две модели – Диаграмма распределения функции и Диаграмма ролей обычно используются в паре. Диаграмма распределения функции (тип – Диаграмма распределения функции) предназначена для того, чтобы описать все объекты, которые окружают функцию, исполнителей, входные и выходные потоки информации, документы, материалы, продукты/услуги, а так же используемое оборудование. Этот тип моделей целесообразно применять для детализации функций в моделях Дерево функций или Событийная цепочка процесса, в результате чего отражаются дополнительные связи и отношения, детализирующие эту функцию на уровне данных. Откройте созданную модель Дерево функции Продажи. Для функции Обработка заказа клиента из контекстного меню (Назначения Создать) создайте новую модель типа Диаграмма распределения функций (рис. 15).  Рис. 15. Распределение функции Обработка заказа клиента На рис.15 отображены сущности, информация атрибутов которых используется при выполнении функции. Модель 10: Другим взглядом на функцию является Диаграмма ролей. Она также предназначена для более точного описания функции. Ее главным назначением является описание прав, обязанностей и ролей организационных единиц, реализующих функцию. Создайте из модели Дерево функции Продажи Диаграмму ролей для функции Заключение договора, как показано на рис.16.  Рис. 16. Диаграмма ролей Модель 11: Следующей важной моделью на уровне определения требований является Карта знаний. Карта знаний, как правило, ориентирована на организационную структуру, т.е. соответствующая категория знаний «связывается» с каждой организационной единицей. Откройте модель Организационная структура. Для должности Служащий КГ создайте новую модель типа Карта знаний, как показано на рис.17.  Рис. 17. Карта знаний Служащего КГ Модели производственного (тип – Промышленный процесс) и офисного (тип – Офисный процесс) процессов описывают практически те же процессы, что и модель Событийная цепочка процесса. Однако эти две модели используют ограниченное число объектов и символов, которые представляются наглядными, легко понимаемыми пиктограммами. Преимущество пиктографического представления состоит в том, что сотрудники различных подразделений могут не только понимать эти модели без предварительной подготовки, но и самостоятельно их разрабатывать и при необходимости изменять. Модель 12: Откройте модель Дерево функции Продажи. Для функции Производство создайте модель типа Промышленный процесс, как показано на рис.18.  Рис. 18. Модель Производство Модель 13: Для создания модели типа Офисный процесс используем уже существующую модель. Откройте модель Событийная цепочка Процесса продаж. Выполните команды Правка Выделить всё Копировать. Создайте новую модель Процесс продаж, но с типом Офисный процесс. Выполните команду Правка Вставить. В результате модель типа Событийная цепочка процесса трансформируется в модель типа Офисный процесс, как показано на рис.19.  Рис. 19. Модель Процесс продаж (Офисный процесс) 2.4. Модели данных При моделировании бизнеса часто приходится иметь дело с многочисленными терминами, определяющими информационные и иные объекты в организациях. Например, то, что понимается под термином «Данные о продажах» в отделе продаж, может значительно отличаться от того, что под этим подразумевают сотрудники производственного отдела. Введение соответствующей терминологии для организации и ее подразделений позволяет сделать информацию более понятной. Так, например, можно определить, из чего складывается понятие «Данные о продаже». Для этого служит модель Технических терминов (тип – Модель технических терминов). Модель 14: Эта модель является одной из основных концептуальных моделей данных уровня определения требований. На рис. 20 приведен пример этой модели. Создайте ее в папке Требования раздела Модели данных.  Рис. 20. Данные о продаже Модель 15: Если Модель технических терминов описывает некоторую иерархию или вложенность понятий (данных), то Модель семантики данных (Semantic data model – SeDaM) призвана отразить смысловую взаимосвязь информационных объектов (сущностей), в которых будет храниться информация (данные). По сути дела, эта модель, как правило, представляет собой модель «сущность-отношение» на уровне сущностей. Модель семантики данных также является концептуальной моделью уровня определения требований. Создайте эту модель в той же папке, как показано на рис.21.  Рис. 21. Модель Семантика данных Данную модель можно дополнить атрибутами сущностей, поскольку соответствующий инструментарий присутствует на панели моделирования. Однако для более детального представления структуры данных используется модель Расширенная модель «сущность - отношение» (тип модели – Extended entity - relationship model - eERM). В этой модели принято раскрывать не только семантику, но и атрибутный состав сущностей. Модель 16: Создайте указанную модель используя механизм Назначения Создать для объекта База данных, который находится в модели Событийная цепочка Процесса продаж (eEPC) (папка Требования раздела Модели процессов) (рис.22).  Рис. 22. Модель База данных Обратите внимание, что построенные Модели семантики данных и Расширенная модель «сущность-отношение» не полностью соответствуют Модели технических терминов в части учета требований и пожеланий клиентов. Кроме того, в этих моделях не отражено участие сотрудников в процессе продаж. Доработайте модели Семантика данных и База данных самостоятельно. К основным моделям данных рассматриваемого уровня относится также Диаграмма структуры знаний (Knowledge structure diagram). Эта диаграмма, как правило, является производной от Карты знаний, рассмотренной выше. Откройте ранее созданную модель Служащий КГ (типа Карта знаний), находящуюся в папке Требования раздела Модели процессов. Для категории Знание авто создайте новую модель типа Диаграмма структуры знаний, как показано на рис.23.  Рис. 23. Модель Знание авто 3. МОДЕЛИ УРОВНЕЙ СПЕЦИФИКАЦИИ И РЕАЛИЗАЦИИ В связи с тем, что модели уровней спецификации и реализации в значительной степени взаимосвязаны между собой, их следует рассматривать (и разрабатывать) совместно по всем типам моделей. 3.1. Организационные модели 3.1.1. Уровень спецификации Единственной моделью, относящейся к данному уровню, является модель Топология сети, которая описывает расположение и взаимодействие технических компонентов информационной системы. В папке Спецификация раздела Организационные модели создайте модель Топология сети КГ (типа Топология сети), как показано на рис.24.  Рис. 24. Модель Топология сети коммерческой группы Обратите внимание на пиктограмму рядом с организационной единицей Служащий КГ. Она является результатом экспорта ссылки на модель карты знаний, созданной ранее. 3.1.2. Уровень реализации Модель Диаграмма сети соответствующая данному уровню, по своему назначению и реализации аналогична модели Топология сети. Создайте ее в той же папке самостоятельно ! Данный уровень представлен также моделью Технические ресурсы. При помощи модели можно иерархически упорядочить ресурсы, присвоить им тип и классифицировать. Создайте ее, как показано на рис.25.  Рис. 25. Модель Технические ресурсы 3.2. Функциональные модели 3.2.1. Уровень спецификации Диаграмма типа прикладной системы (Application system type diagram - ASTD). Данная диаграмма предназначена для моделирования прикладных информационных систем, используемых в организации. В папке Cпецификация раздела Функциональные модели создайте модель Диаграмма типов IT систем (рис.26).  Рис. 26. Модель Диаграмма типов IT систем 3.2.2. Уровень реализации С рассмотренной выше моделью связывается, как правило, модель Диаграмма прикладной системы (Application system diagram). Раскройте структуру системы ARIS 7.0 как показано на рис.27.  Рис. 27. Модель ARIS 7.0 (Диаграмма прикладной системы) 3.3. Модели процессов 3.3.1. Уровень спецификации Основными моделями данного уровня являются модель Диаграмма доступа и Блок-схема программы Оба типа моделей также связываются, как правило, с моделью типа Диаграмма типа прикладной системы.. Для элемента ПО DBMS создайте модель, как показано на рис.28.  Рис. 28. Модель доступа ПО DBMS В данной модели присутствует процедура аутентификации. Создайте для нее алгоритм в виде блок-схемы программы (рис.29).  Рис. 29. Блок-схема процедуры Аутентификация 3.3.2. Уровень реализации Для моделей процессов данный уровень представлен моделью Диаграмма физического доступа (тип - Диаграмма доступа (физическая))Смысл и назначение ее практически аналогичны простой Диаграмме доступа. Создайте её самостоятельно! 3.4. Модели данных Используя опыт создания моделей в среде ARIS 6.2, самостоятельно создайте модель уровня спецификации Диаграмма окружения атрибутов (Attribute allocation diagram), используя разработанную модель eERM и модель уровня реализации Диаграмма таблиц (Table diagram). 4. ЭЛЕМЕНТЫ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО МОДЕЛИРОВАНИЯ В папке Автомобильная компания создайте новую папку – UML, в которой создайте модель Взаимосвязь моделей (типа Structuring model), как показано на рис.30.  Рис. 30. Взаимосвязь моделей Данная модель структуры показывает взаимосвязь и порядок разработки объектно-ориентированных моделей на языке UML, которые описывают реализацию взаимосвязанных функций Учет требований клиента и Обработка заказа клиента (см. модель Дерево функции Продажи). Показанные на рис.30 модели, приведены на рис. 31…38.  Рис. 31. Пакеты  Рис. 32. Обработка запроса клиента (UML Диаграмма прецедентов)  Рис. 33. Обработка запроса клиента (UML Диаграмма деятельности) Рис. 34. Определение цены  Рис. 35. Контроль заказа клиента  Рис. 36. Запросы клиента  Рис. 37. Позиции запроса клиента  Рис. 38. Компоненты системы продаж Для обеспечения взаимосвязи моделей (рис.30), интегрируйте их по соответствующим объектам (рис.39).  Рис. 39. Взаимосвязь моделей по объектам
|