Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь FAQ Написать работу КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
В. Разработка архитектуры интегрированных информационных систем (здание ARIS)Содержание книги
Похожие статьи вашей тематики
Поиск на нашем сайте
Метамодель бизнес-процесса 3-го уровня описывает характеристические классы и их взаимоотношения, с помощью которых можно моделировать фактические прикладные процессы 2-го и 1-го уровней. Поскольку объекты 2-го уровня являются экземплярами метауровня, можно использовать только те объекты, классы которых определены на метауровне. В свою очередь типы бизнес-процессов, смоделированные на 2-м уровне, определяют структуру реальных конкретных процедур на 1-м уровне. Таким образом, метамодели по существу определяют возможности проектирования бизнес-процесса. Вследствие большого разнообразия классов и их семантических взаимоотношений модели бизнес-процессов могут быть структурированы с высокой степенью детализации. Полученная при этом структура называется «Архитектурой интегрированных информационных систем» (ARIS). Метамодель бизнес-процесса, приведенная на рис. 13, объединяет следующие классы: - контекстные данные, описывающие инфраструктуру процесса; - исходные и результирующие события; - сообщения; - функции; - человеческий ресурс; - технические ресурсы и компьютерные - средства; - прикладное программное обеспечение; - материальный выход, выход в виде ус - луг и информационные слуги; - финансовые ресурсы; - организационные единицы; - корпоративные цели. Поскольку каждый класс может быть связан с другим классом, структура системы достаточно сложна. Семантические отношения между классами и соответствующими функциями, представленные на рис. 13, отражают лишь фрагмент множества возможных взаимоотношений. Многообразные отношения могут существовать и между самими классами. Например, отношение между функциями и человеческим ресурсом зависит также от того, какой ресурс обеспечивает выполнение процесса. Кроме того, отношения внутри классов могут описывать зависимость между объектами данных или связь между событиями. Для упрощения в разделе В.1 классы со сходными семантическими взаимоотношениями сгруппированы в описания (модели) ARIS различных типов. Это дает возможность рассматривать связи в рамках той или иной модели, избавляя от необходимости сразу же учитывать весь комплекс взаимоотношений с другими моделями. До сих пор мы обсуждали бизнес-процессы больше с точки зрения управления бизнесом, не останавливаясь подробно на использовании информационных технологий (ИТ). Однако поскольку одной из ключевых тем этой книги является внедрение бизнес-моделей в информационные системы (ИС), в разделе В.2 мы введем понятие жизненного цикла, шаг за шагом трансформируя классы бизнес-процессов в объекты ИС. Для более детального описания этих взаимоотношений требуется более формализованный язык, чем в предыдущем материале книги. Этот язык разрабатывается в разделе В. З для создания эскиза информационной модели. Концепция ARIS иллюстрирует также принцип описания бизнес-процессов. Для этой цели мы построим эскиз процедурной модели в разделе В.4. Рис. 14а. Функциональная модель
В.1. Типы моделей в ARIS
Группировка классов и отношений между ними в модели служит для структурирования и совершенствования бизнес-процессов. Разбивка на модели имеет дополнительное преимущество: она позволяет устранить избыточность, часто возникающую при неоднократном использовании объектов в модели процесса. Например, одни и те же контекстные данные, события или организационные единицы могут относиться к ряду функций. Можно также применять методы моделирования, ориентированные на различные типы моделей, которые на практике доказали свою состоятельность. В частности, процедуры, относящиеся к различным типам моделей, с этой точки зрения отличаются от более теоретических концепций моделирования, где системы для упрощения разбиваются на подсистемы, однако, каждая подсистема изображается тем же способом, что и исходная система. Именно поэтому для одной и той же системы при таком подходе невозможно применять разные методы моделирования. Рис. 14б. (Иерархическая) организационная модель Модели ARIS различных типов строятся в соответствии с критерием «семантического корреляционного сходства». На рис. 14а-г представлены модели ARIS, рассматриваемые в контексте метамодели бизнес-процесса, приведенной на рис. 13. Благодаря прямой связи уровней описания эти модели сохраняют силу для уровней 2 и 1. Хотя в метамоделях бизнес-процессов используются только предварительные обозначения классов, относящиеся преимущественно к бизнес-операциям, эти модели пригодятся впоследствии для детализации и реализации классов в категориях ИТ и концепции жизненного цикла. При создании моделей используются различные потоки, о которых шла речь в разделе Б.2.1. В результате получаются следующие виды моделей ARIS. Рис. 14в. Модель данных Функциональные модели. Процессы, преобразующие вход в выход, группируются в функциональную модель (см. рис. 14а). Обозначения «функция», «процесс» и «операция» употребляются как синонимы. В связи с тем, что функции тесно связаны с целями, поскольку они направлены на их достижение и подчиняются их управлению, цели также относят к функциональным моделям. В прикладных системах (ПС) описываются правила компьютерной обработки функции. Таким образом, ПС адекватно подходит под определение «функций» и также относится к функциональной модели. Организационные модели. Класс организационных моделей служит для описания иерархической структуры организации. В организационных моделях группируются субъекты ответственности и средства, выполняющие работу над одним и тем же объектом Именно поэтому сущность «человеческий ресурс», а также средства «финансовые ресурсы» и «компьютерная техника» относятся к организационной модели (см рис. 14б). Модель данных. Модели данных описывают информационный контекст (среду обработки данных), а также сообщения, активизирующие функции или активизируемые ими. С именами данных можно также связать предварительные детали, касающиеся функции информационных систем как носителей данных. В моделях данных неявным образом фиксируются также объекты в виде информационных услуг. Однако в основном такие объекты описываются в моделях выходов. Объекты модели данных представлены на рис. 14в. Модели выходов. Модели выходов содержат все физические и нефизические входы и выходы, включая потоки денежных средств (см. рис. 14г). Модели управления / модели процесса. В этих моделях соответствующие классы моделируются с учетом их внутренних взаимоотношений. Представление отношений между отдельными моделями, так же как и в рамках всего бизнес-процесса, в виде управляющих моделей (или моделей процесса) позволяет постоянно отслеживать все двусторонние отношения между моделями различных типов, а также полностью описать процесс. Рис. 14г. Модель выходов Рис. 15. Модели ARIS В теории систем мы можем провести разграничение между структурой системы и ее поведением. Понятие структуры охватывает статичное представление системы, а поведение описывает ее динамику. В моделях бизнес-процессов динамика выражается управлением событиями и потоком сообщений. Модели функций, организации, данных и выходов описывают структуру системы. Модели управления показывают все структурные связи в рамках упомянутых моделей и описывают динамическое поведение потока, отображающего бизнес-процесс. На рис. 15 приведены модели и некоторые их классы, образующие «здание» ARIS. Модель процесса представлена в виде модели управления. Показано также происхождение объектов модели управления и индивидуальных моделей различных типов.
В. 2. Фазовая модель ARIS
До сих пор мы обсуждали бизнес-процессы с точки зрения управления, т. е. не делая акцента на информационной технологии. Рассмотренные выше прикладные системы (компоненты функциональной модели), компьютерная техника (компонент организационной модели) и носители данных (компоненты модели данных) содержат только имена систем, но не описания в категориях ИТ. Последние включаются в концепцию ARIS в зависимости от степени использования элементов ИТ в рамках каждой модели. Функциональные модели поддерживаются прикладными системами, которые более детально описываются на уровне отдельных модулей, транзакций или языков программирования. Организационные модели, наряду с их производственными и компьютерными ресурсами, можно детализировать путем перечисления сетевых понятий, аппаратных компонентов и других технических спецификаций. Модели данных можно детализировать посредством указания моделей данных, путей доступа и использования памяти. Модели выходов могут иметь различные типы выходов, например, материальный выход и информационные услуги. Здесь существует тесная связь с категориями ИТ. В материальном выходе (например, в развлекательной технике, автомобилях и станках) наряду с необходимыми аппаратными средствами используется все больше компонентов ИТ (например, технология микросхем). Другие сферы услуг, скажем, резервирование авиабилетов, также тесно связаны с ИТ. Поскольку соответствующие модели можно объединить в рамках модели управления, то, согласно приведенной выше аргументации, в ней определенно существует связь с элементами ИТ. Таким образом, описания бизнеса с помощью фазовой модели поэтапно трансформируются в объекты информационных и коммуникационных технологий. Фазовые модели характеризуют этапы описания реализации вопросов бизнеса посредством компьютерных систем. Этот процесс реализации часто описывают с помощью различных концепций. ARIS-модель включает пять фаз (см. рис. 16). На фазе 1 описывается текущее состояние деятельности (или одного из ее направлений) в контексте стратегических установок и с ориентацией на использование ИС. «Ориентация на использование ИС» подразумевает, что основные виды связей объектов и категорий ИТ с новыми корпоративными концепциями уже приняты во внимание. Примерами здесь могут служить создание виртуальных компаний через коммуникационные сети, электронные банковские операции, компьютерная обработка заказов, разработка продуктов в промышленности (CIM), интегрированные системы управления товарами (MMS) в розничной торговле. Стратегическое планирование отражает долгосрочные корпоративные цели организации, общие корпоративные функции и ресурсы. Таким образом, стратегические установки определяют в долгосрочной перспективе бизнес-процессы организации, включая корпоративные цели, критические факторы успеха и распределение ресурсов. Обсуждаемые методы «адаптированы» к представлению концепций управления бизнес-процессами с точки зрения стратегического планирования. Если фактические бизнес-процессы уже описаны, это происходит обычным способом. На данном этапе нежелательно разбивать процессы и функции на модели ARIS и описывать их в деталях. Фаза 2 посвящена определению требований. На этом этапе создаются подробные модели (каждого типа) прикладной системы. И здесь тоже ключевое место занимает организационное содержание бизнеса. На этом уровне следует включить примеры бизнес-процессов, особенно ARIS-модель бизнес-процесса, представленную на рис. 10. Рис. 16 Фазовая модель ARIS Однако на этой фазе, в отличие от стратегического подхода, необходимы более формализованные языки описания, поскольку описания, предназначенные для определения требований, являются отправной точкой для реализации ИТ. Языки описания должны быть понятны с точки зрения бизнеса, чтобы служить отправной точкой для последовательного внедрения ИТ. Кроме того, на данном уровне имеет смысл включить в описание общие объекты ИТ типа баз данных или программ. Фаза 3 связана с разработкой спецификации проекта, где бизнес-модели адаптируются к требованиям интерфейсов инструментальных средств реализации ПС (баз данных, сетевых архитектур, языков программирования и т. д.). На этом этапе реальные программные продукты по-прежнему не имеют значения. Фаза 4 предполагает создание описания реализации, где разработанные требования реализуются в виде физических структур данных, аппаратных компонентов и реальных продуктов. Эти четыре фазы описывают создание информационной системы и поэтому называются «конструктивным временем». Позже законченная система принимает работоспособный вид и вступает в эксплуатационную фазу, которая получила название «реального времени». В нашей монографии эксплуатация информационных систем, т. е. их реальное время, подробно не рассматривается. Фаза определения требований тесно связана с уровнем стратегического планирования, о чем свидетельствует самая широкая стрелка на рис. 16. Однако более узкая стрелка, указывающая на спецификацию проекта, означает, что эта фаза не зависит от конкретной реализации проекта. С другой стороны, описание реализации и эксплуатация тесно связаны с «уровнем аппаратно-программной поддержки». Изменения в информационных технологиях системы немедленно сказываются на типе реализации и эксплуатации. Фазовая концепция не предполагает такой жесткой последовательности в процессе разработки, как это требуют «модели водопада». Скорее, эта концепция включает в себя процедуру эволюционного создания прототипов. Однако даже при эволюционной разработке программного обеспечения обычно используются представленные уровни описания. Фазовые модели применяются прежде всего потому, что они предлагают широкий спектр объектов и методов описания. Здание ARIS на рис. 17 дополнено четырьмя фазами ARIS-модели конструктивного времени. После создания общего концептуального проекта бизнес-процессы разбиваются на модели различных типов и документируются, проходя путь от этапа определения требований к этапу описания реализации. Эти три уровня описания создаются также и для целей управления. Благодаря этому становится возможным создание связей с другими компонентами на каждом уровне описания. Здание ARIS на рис. 17 иллюстрирует архитектуру информационной системы. Эта архитектура, включающая набор моделей различных типов, подразделяется на определение требований, спецификацию проекта и описание реализации и тесно связана с категориями ИТ. Концепция ARIS нацелена на создание и управление бизнес-процессами организации. Помимо связи со стратегическими установками, она перекликается со стратегическим управлением информацией. Управление информацией предполагает планирование, регулирование и внедрение «информационного» ресурса. Поэтому Воллник в модели-прототипе выделяет три аспекта: управление инфраструктурой (управление информационными технологиями), управление прикладной системой и управление внедрением информационных систем. Эти определения вписываются в концепцию ARIS. Первая задача, связанная с инфраструктурой, охватывает уровни информационных технологий и спецификации проекта, представленные на рис. 18. Вторая задача относится к управлению информационными системами и включает реализацию организационных требований в автоматизированных информационных системах с помощью концепции жизненного цикла ARIS, фокусируя внимание на фазах конструктивного времени. Третья задача - управление внедрением информационных систем - относится к фазе реального времени в модели жизненного цикла ARIS. Рис. 17. Здание ARIS и фазовая модель Рис. 18. Здание ARIS, дополненное связями с корпоративной стратегией и управлением информацией В результате влияния информационных технологий на организационные проблемы и происходящие изменения (оно обозначено на рис. 18 стрелкой слева), возникает связь между управлением информацией и корпоративной стратегией (правая часть рисунка). Таким образом, концепция ARIS делает более прозрачной реализацию стратегических установок и создает инфраструктуру для более эффективного управления информацией.
В. З. Предварительная информационная модель ARIS
Здание ARIS создает «каркас» для классификации описательных компонентов бизнес-процесса. Теперь обсудим подробнее отдельные «кирпичики» бизнес-процесса и отношения между ними. Мы будем рассматривать метауровень, где фиксируются элементы общего бизнес-процесса, т. е. без контекстной привязки к конкретным бизнес-процессам. Основой для этого послужит ARIS-модель бизнес-процесса, представленная на рис. 13. Исследуем ее теперь более подробно, анализируя отношения между элементами. Воспользуемся при этом унифицированным языком описания и унифицированными символами для обозначения различных элементов (функций, организационных единиц, ресурсов, сообщений и т. д.), а также их взаимоотношений. Рис. 19. Предварительная информационная модель ARIS Рис. 20. ARIS-компоненты метауровня ARIS Модель сущность-отношение (ERM), предложенная Ченом, прекрасно подходит для описания объектов. Хотя изначально эта модель предназначалась для представления структур данных в прикладных системах, она может служить и языком общего описания, а, следовательно, ее можно применить и к описанию метауровней. При объектно-ориентированных подходах в объектную модель тоже вводятся классы и их отношения. Однако с ними связываются и определенные методы. Что касается объектов моделирования, то на метауровне они идентичны (например, когда речь идет о создании, удалении, редактировании или графическом выводе объекта). Кроме того, в объектно-ориентированных моделях на стадии анализа допустимо использовать только классы и их имена, т. е. атрибуты и методы опускаются. В первом издании этой книги в качестве языка описания мы применяли расширенную модель ERM. Однако сейчас в объектно-ориентированном моделировании все шире применяется язык UML - унифицированный язык моделирования, поэтому для иллюстрации классов мы воспользуемся именно этим языком. Что касается содержания, то оба языка взаимозаменяемы. Язык описания UML позволяет отдельно представлять классы объектов и классы связей в моделях различных типов. Такое представление известно как метамодель ARIS или информационная модель ARIS. В то же время эта информационная модель описывает конструкцию базы данных, где можно хранить модели реального мира, разработанные с помощью методологии ARIS. Организационные и функциональные модели, равно как и модели данных, выхода и управления, относящиеся к тому или иному приложению, рассматриваются как экземпляры базы данных, построенной в соответствии с информационной моделью. Такие базы данных называются репозиториями. Понятие «репозиторий» приобрело популярность в 1989 году, когда корпорация IBM провозгласила новую концепцию разработки программного обеспечения - AD/CYCLE. Для каждой модели ARIS (функциональной, организационной, данных, выхода и управления) репозиторий ARIS содержит модели 2-го уровня, а также их отношения и модели для каждой фазы жизненного цикла ARIS. При моделировании на 1-м уровне, т. е. на уровне 1 экземпляров ARIS, репозиторий необходимо обновлять, вводя в него соответствующие экземпляры процесса. Таким образом, репозиторий становятся ядром информационной системы. Важность и значение информационной модели, содержащейся в репозитории, определяется ее способностью оказывать решающее влияние на эффективность элементов описания. Язык UML оперирует диаграммами классов, которые изображаются прямоугольниками, и ассоциативными связями (или просто связями), которые в свою очередь изображаются рамками. Связи различаются по мощности отношений 1:* (один ко многим), 1:1 (один к одному), *:* (многие ко многим) или *:1 (многие к одному). Звездочка может означать «много» или «n». С помощью этих простых элементов на рис. 19 представлен эскиз информационной модели ARIS. В каждой модели описываются лишь несколько рассмотренных до сих пор классов вместе с их связями. Из различных элементов жизненного цикла сюда включена — только фаза определения требований, т. е. характеристики, связанные со спецификацией проекта и описанием реализации, не используются. Информационная модель, изображенная на рис. 19, дает общее представление об этом типе модели. Отправными точками функциональной модели на рис. 19 являются корпоративные цели, которые управляют функциями; другими словами, для достижения той или иной цели должны быть выполнены определенные функции. Корпоративные цели обычно классифицируются по иерархическому принципу. Общие цели, такие как «максимизация прибыли», «достижение определенной рыночной доли» или «достижение определенного темпа роста», разделяются на подцели, например, «достижение определенной суммы дохода», «снижение расходов на определенную сумму» или «достижение определенного уровня качества». Благодаря интегрированной структуре целей класс КОРПОРАТИВНЫЕ ЦЕЛИ характеризуется связью *:*. Поскольку подцели входят в главные цели, они характеризуются связью «часть целого». Такая связь называется целевой структурой. Она выделяется в самостоятельный класс. Примерами функций являются обработка заказов, продажа или регулирование, которые могут быть детализированы на составляющие их подфункции. Взаимосвязь между функциями, равно как и связь функций с целями, на достижение которых они направлены, предполагает между ФУНКЦИЕЙ и КОРПОРАТИВНЫМИ ЦЕЛЯМИ отношение типа *:*. ФУНКЦИОНАЛЬНАЯ СТРУКТУРА представляет собой связь «часть целого», определяя функции, содержащиеся в других функциях. Центральным элементом в организационной модели является ОРГАНИЗАЦИОННАЯ ЕДИНИЦА. Этот класс включает такие экземпляры, как ПОЗИЦИЯ, ПОДРАЗДЕЛЕНИЕ или ПРЕДПРИЯТИЕ. Независимо от того, являются эти области подчиненными или главными, они всегда характеризуются связью *:* — это «часть целого» в рамках класса ОРГАНИЗАЦИОННАЯ ЕДИНИЦА. Таким образом, эта связь позволяет одной области выступать в качестве подчиненной по отношению к нескольким другим. Это относится, например, к отделу продаж, который связан с рядом основных областей, производящих продукт. Ответственные субъекты или средства («машины», «компьютер», «человеческий ресурс») связываются с организационными единицами. Модель данных (левая часть здания ARIS) отображает структуру данных. Класс ИНФОРМАЦИОННЫЙ ОБЪЕКТ характеризует объекты, описываемые атрибутами баз данных. Между их экземплярами, такими как данные об изделии и данные о клиенте, существуют связи (например, какой клиент какие изделия покупает). Эти связи выражаются отношением *:* внутри класса ИНФОРМАЦИОННЫЙ ОБЪЕКТ. Информационные объекты, относящиеся к области с взаимосвязанным содержанием, можно сгруппировать в диаграмму класса или модель данных. Поскольку из-за идентичных информационных объектов МОДЕЛЬ ДАННЫХ и ИНФОРМАЦИОННЫЙ ОБЪЕКТ могут частично накладываться друг на друга, они связаны отношением *:* — «часть целого». В модели выходов класс ВЫХОД представляет все виды выходов (материальный выход, услуги и информационный выход). Экземплярами выступают классы выходов, связанные с прикладным уровнем, например, изделие, материалы, запчасти, время сборки, гарантийные услуги или сертификаты. Здесь также различные виды выходов могут быть взаимосвязаны (отношением «часть целого»). Связи между всеми четырьмя компонентами (организация, функция, информация и выходы) представлены в модели управления. Связь между ОРГАНИЗАЦИОННОЙ ЕДИНИЦЕЙ и ФУНКЦИЕЙ выражается отношением ОТВЕТСТВЕННОСТЬ. Организационным единицам могут быть присвоены определенные привилегии, относящиеся к ИНФОРМАЦИОННЫМ ОБЪЕКТАМ, которые выражаются отношением ПРИВИЛЕГИИ ДОСТУПА. Полная функциональная модель ARIS подробно описывает классы и отношения между ними в модели мета-бизнес-процесса. Она описывает также все модели ARIS, охватывающие фазы жизненного цикла. Эта модель включает около 300 классов и связей. Информационная модель ARIS представляет собой схему репозитория для хранения соответствующих прикладных моделей. Данные, хранящиеся в репозитории, включают классы реальных приложений (например, для сферы продаж или бухгалтерского учета), хотя обычно - на уровне типов. В то время как объекты типа КЛИЕНТ и ИЗДЕЛИЕ хранятся в репозитории в качестве экземпляров класса ИНФОРМАЦИОННЫЙ ОБЪЕКТ, сами экземпляры, т. е. индивидуальные сущности «клиент» и «изделие» 1-го уровня, как правило, хранятся в базе данных о продажах. При моделировании процессов на уровне экземпляров (например, для приложений workflow) соблюдать это правило не обязательно. На рис. 20 сгруппированы четыре компонента метауровня с указанием их взаимосвязей: мета-бизнес-процесс ARIS, архитектура (Здание ARIS), информационная модель ARIS, репозиторий ARIS.
В.4. Предварительная процедурная модель ARIS
Концепция ARIS предоставляет методологию описания бизнес-процессов от этапа определения требований до этапа описания реализации. Примером может служить обработка заказов, жалоб или страховых исков. Проведение реорганизации тоже можно интерпретировать как бизнес-процесс. В силу того, что реорганизация предполагает участие многочисленного штата сотрудников (как своих, так и посторонних), выполнение множества функций, составление и использование несметного количества документов, не помешает заранее спланировать этот процесс, руководствуясь концепцией ARIS. Процедурная модель ARIS описывает, как реализовать концепцию ARIS, т. е. как необходимо организовать управление проектом, определить функции и получить пакет выходных документов на базе ARIS. Процедурная модель ARIS описывает концепцию ARIS, пользуясь средствами ARIS. Процедурные модели можно строить и на уровне типов (2-й уровень моделирования). В этом случаи они могут служить моделями реального проекта. Процедурные модели для реорганизации бизнес-процессов (английская аббревиатура - BPR), разработки программного обеспечения, реализации систем workflow или стандартных программных решений можно найти в приложениях и научных публикациях. Эти модели используются для создания процедур применительно к конкретным проектам. Если подробное описание процедурной модели отсутствует, это не столь уж важно. Например, процедурная модель BPR, предложенная Хэммером и Чампи, содержит всего пять функций: мобилизацию, диагностику, перепроектирование, переход и управление изменениями. Последняя функция осуществляется одновременно с первыми четырьмя фазами. С другой стороны, для разработки программного обеспечения существует широкий диапазон процедурных моделей, в том числе V-модель Координационного и консультативного управления Германского правительства по информационной технологии в федеральной администрации. Разработаны и различные модели для реализации workflow. Для облегчения реализации стандартных программных решений, в частности SAP/R3 и SAP, ряд консалтинговых фирм предлагает детальные процедурные модели. Рис. 21. Один из вариантов диаграммы EPC для процедурной модели ARIS Рис. 22. ARIS-модели «создания определения требований на уровне функциональной модели» Помимо процедурных моделей различного назначения, имеются коммерческие модели для локальных целей, например, для моделирования данных. Процедурная модель семантических объектов (SOM), разработанная Зинцем и Ферстлем, предназначена для внедрения объектно-ориентированных методов в моделирование бизнес-процессов. На первый взгляд, процедурная модель ARIS включает те же модели и фазы жизненного цикла, которые описаны в ARIS. Однако, используя эти объекты и соответствующие методы, процедурную модель ARIS можно реализовать на гораздо более детальном уровне. На рис. 21 процедурная модель, представленная в виде последовательности процессов, управляемых событиями (EPC), состоит из функций и событий. Отношения последовательности позволяют одновременно реализовать модели функций, организации, данных, выходов и управления для одной и той же фазы. Определение требований начинается с модели управления, т. е. с описания процесса. При разбиении процессов на отдельные конкретные этапы может происходить наложение детализированных областей. В рамках процессов можно задавать различные уровни детализации; однако придерживаться жесткого принципа разбиения на фазы, как в модели «водопада», отнюдь не обязательно. Скорее, различные формы разработки, например создание прототипов, можно представить в виде некоторых упорядоченных отношений. Помимо функций и событий, сюда можно включить и другие элементы описания процесса, например, организационные единицы, данные и выход. На рис. 22 изображена схема «создания определения требований на уровне функциональной модели». Модели данных содержат ключевые вехи процедурной модели (т. е. события и сообщения, инициирующие или завершающие процесс) и контекстных описаний (такие как модели, хранимые в репозитории моделей). Функциональные модели предоставляют стандартные блоки архитектуры ИТ. С ними ассоциируется соответствующее программное обеспечение, будь то текстовый процессор или инструменты моделирования. Организационные модели описывают подразделения, кадры и машинные ресурсы, необходимые для отдельных процессов. Модели выходов определяют входы и выходы функций, т. е. управляющую и функциональную модели. До сих пор мы рассматривали процедурные модели только на уровне определения требований. Поскольку они содержат ИТ-объекты, такие как репозитории моделей, персональные компьютеры и прикладное программное обеспечение (текстовые процессоры, программы моделирования и т. д.), процедурные модели можно перенести также на фазы спецификации проекта и описания реализации. На этапе спецификации проекта определяются проектные характеристики для баз данных репозитория, персональных компьютеров и программных средств моделирования. Затем, на этапе описания реализации описывается их реализация с точки зрения информационных технологий. Если используется ARIS Toolset, то фаза спецификации проекта является тем этапом, где принимается решение о внедрении одной или нескольких пользовательских версий. На уровне описания реализации определяются реальные параметры и фактические базы данных. На базе общей процедурной модели можно построить специализированные модели под конкретные проекты. Например, при реинжиниринге информационной системы отдела продаж общие функции типа «создание определения требований на уровне модели данных» дополняются функцией «создание модели данных и определение требований информационной системы отдела продаж». Это сопоставимо с переходом от моделирования типов к описанию экземпляров. С другой стороны, абстрагирование от конкретных отношений в процедурной модели ARIS дает общую метамодель ARIS на 3-м уровне моделирования. Подведем итоги: Процедурная модель ARIS определяется соответствующей архитектурой ARIS, описывающей бизнес-процессы. Поскольку процедурные модели можно рассматривать как модели бизнес-процессов, они могут описываться теми же концептуальными моделями ARIS, что и любой другой бизнес-процесс. Результаты каждой функции в процедурной модели хранятся в репозитории ARIS. Репозиторий, т. е. информационная модель ARIS, является стандартной схемой для хранения результатов, например проекта базы данных. Эти результаты представляются в виде функциональной модели, модели данных, организационной модели, модели выходов и управления. Модель-прототип процедурной модели также хранится в репозитории ARIS. На рис. 23 показано, как процедурная модель ARIS соотносится с концепцией ARIS - на этот раз на примере организации, занимающейся продажей. Процедурная модель хранится в репозитории ARIS и описывается на 2-м уровне. Ее логика определяется архитектурой ARIS и информационной моделью ARIS. Представляя единичный процесс реализации проекта, процедурная модель, ориентированная на конкретную предметную область, является экземпляром общей процедурной модели для разработки бизнес-процессов с размещением их на 1-м уровне моделирования. Процедурная модель в репозитории соответственно модифицируется. Пунктирные стрелки показывают, каким образом метауровень определяет подчиненные уровни, а сплошные иллюстрируют последовательность операций в процедурной модели. В итоге получаются модели продаж. Эти модели размещаются на 2-м уровне моделирования, описывая общие процессы продажи. Рис. 23. Отношение между концепцией ARIS и информационной моделью ARIS
|
|||||
Последнее изменение этой страницы: 2016-06-19; просмотров: 973; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.147.42.34 (0.022 с.) |