Методология aris

Рис. 14. Взаимосвязь видов моделей ARIS (здание ARIS)

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

В рамках каждого типа представления создаются модели, отражающие ту или иную сторону исследуемой системы. Методология ARIS включает большое количество методов моделирования, в том числе известных как диаграммы Чена ERM, язык UML (Unified Modeling Language), методики ОМТ (Object Modeling Technique), BSC (Balanced Scorecard) и т.п.

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

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

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

Моделирование бизнеса. Методология aris

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

3.4. Фазовая модель aris

Фазовая модель (рис.15) характеризует этапы создания информационных систем [1,2] и подходы, применяемые к описанию моделей бизнеса. Согласно методологии ARIS модель организации структурируется в соответствии с концепцией жизненного цикла информационных систем, который представляется в виде последовательности уровней или этапов. Однако модель жизненного цикла ARIS не может рассматриваться как совокупность процедурных моделей для разработки некоторых независимых объектов на каждом уровне описания. Различные типы представления «выстроены» в модели в зависимости от степени их близости к информационным технологиям (ИТ).

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

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

бизнеса используются только семантические

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

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

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