Презентация на тему Сравнительный анализ подходов к проектированию ИС

проектов заканчиваются успехом.
Обязательным условием успешности развития, работы и

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

которая бы помогла сформировать требования к ИС, спроектировать и

разработать систему, отвечающую этим требованиям.

Наличие такой технологии (особенно при параллельном ведении большого количества проектов) является решающим фактором успеха при создании ИС.

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

позволяют, так или иначе, создавать модели бизнес-процессов предприятий.

Их

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

 Важнейшими из подходов  являются:
структурный (функциональный),
объектно-ориентированный,
отдельно выделяется методология ARIS.

программное обеспечение использовать в проекте («ARIS лучше BPWin?», «ERWin

лучше ARIS?» и т.п.);
как моделировать процессы с использованием продукта «Х»?;
как проводить анализ и выявлять проблемы при помощи продукта «Х»?;
какую методологию использовать для описания процессов?

для создания бизнес-процессов предприятий.
Выбор системы в значительной мере

определяет весь дальнейший ход проекта.
Рациональный выбор системы возможен при понимании руководством компании нескольких аспектов:
целей проекта;
требований к информации, характеризующей бизнес-процессы и необходимой для анализа и принятия решений в рамках конкретного проекта;
возможностей CASE-систем по описанию процессов с учетом требований.

на следующие вопросы:
какие процедуры (функции, работы) необходимо выполнить для

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

зрения: 1. Организационной структуры. 2. Функциональной структуры. 3. Структуры данных. 4. Структуры процессов.
При

этом каждая из этих точек зрения разделяется еще на три подуровня:
- описание требований;
описание спецификации;
описание внедрения.

Для описания бизнес-процессов предлагается использовать около 80 типов моделей, каждая из которых принадлежит тому или иному аспекту.
В АRIS имеется мощная репрезентативная графика, что делает модели особенно удобными для представления руководству.

следующие: * ЕРС (event-driven process chain) - метод описания процессов,

нашедший применение в системе SAP R/3; * ERM (Entity Relationship Model) - модель сущность-связь для описания структуры данных; * UML (Unified Modeling Language) - объектно-ориентированный язык моделирования.

(АБИ)
ARIS eEPC - extended Event Driven Process Chain –

расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия).

быть инициирована событием и должна завершаться событием.
В каждую функцию

не может входить более одной стрелки, «запускающей» выполнение функции, и выходить не более одной стрелки, описывающей завершение выполнения функции.
Бизнес-процесс представляет собой последовательность процедур, расположенных в порядке их выполнения.

Стрелка, соединяющая Событие 1 и Функцию 1 «активирует» или инициирует выполнение Функции 1. Функция 1 «создает» Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3.

изготовителю несколько изделий.
2. На основе информации о клиенте

и изделиях изучается вопрос о технической возможности и экономической целесообразности изготовления данных изделий.
3. После поступления заказа у поставщика приобретаются необходимые материалы.
4. После получения материалов и последующего планирования заказа предприятие изготавливает изделия в соответствии с графиком работ.
5. Предприятие отправляет изделия клиенту вместе с надлежащей документацией.

точек зрения.
В теории систем мы можем разграничить структуру системы

и ее поведение.

Рассмотрим:

описания субъектов (сущностей) ответственности и отношений, участвующих в бизнес-процессе;
динамическое поведение при помощи последовательности функций. Выходные потоки описывают результаты выполнения процесса, а информационные потоки — обмен документами, участвующими в процессе.

выхода (организационные единицы), выходные и информационные объекты представлены различными

символами. Потоки обозначены стрелками.

единицы), участвующие в бизнес-процессе, для каждого из них показан

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

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

Диаграммы взаимодействия широко применяются в теории бизнеса.

же бизнес-процесс при помощи функций с указанием их последовательности.

Главная роль здесь отводится не исполнителям (на статичной диаграмме взаимодействия), а динамичной последовательности функций.

Для наглядности на диаграмме представлены и операционные единицы.

Функциональные потоки представляют собой последовательности выполнения функций для создания выхода и, таким образом, они могут характеризовать бизнес-процесс.

Сами выходные потоки будут показаны отдельно.

весьма неоднозначно. В наиболее общем смысле выход в бизнесе

есть результат производственного процесса. Выход может быть физическим (материальный выход) и нефизическим (услуги). В то время как материальный выход легко поддается определению (например, доставка материала, изготовленные детали или даже готовый продукт), с понятием «услуги» дело обстоит сложнее, поскольку оно охватывает услуги самого разнообразного характера. Например:
театральные представления (драматические спектакли, концерты), где выходом является исполнение на сцене (потребление этого выхода происходит одновременно с его созданием);
банковские услуги в виде займов или кредитов; в этом случае услуга состоит в предоставлении необходимых денежных средств и сама по себе является результатом других банковских услуг (проверка кредитоспособности, услуги по депозиту и т. д.);
услуги по страхованию;
услуги государственного сектора (выдача водительских удостоверений, удостоверений личности и т. д.).

под символом каждого выхода указана создающая его функция. В

данном случае выходом являются информационные услуги, например, «проверенный заказ», «производственный план», «заказ», «документация на заказ», «заказ на отправку». Изделия же, представляющие собой непосредственный результат процесса производства, рассматриваются как материальный выход.
На примере показан результат процесса «изготовление изделия», т. е. материальный выход в виде изготовленного изделия. Аналогичным образом в процессе изготовления выполняется и документируется проверка качества. Все данные, относящиеся к заказчику, фиксируются в «документации на заказ».
После каждой внутрифирменной функции описывается поставляемый ею выход, который в свою очередь поступает в следующий процесс уже в качестве входа. Чтобы не перегружать диаграмму, организационные единицы на рисунке опущены. Диаграмма не позволяет описать последовательность выполнения функций.

описывают информационные объекты бизнес-процесса и данные, которыми они обмениваются.

Каждый информационный объект имеет свое имя. Ему можно присвоить и другие атрибуты, но для экономии места в диаграмме они не приведены.

Объекты, отнесенные к разряду информационных услуг, обведены двойной рамкой.

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

работающие с информационными объектами, являются частью объектов, предоставляющих информационные услуги.

Можно

соотнести функции и с другими информационными объектами, однако это будут уже подфункции по отношению к функциям процесса, поэтому на диаграмме они не показаны.

Например, детальную функцию «проверка кредитоспособности» можно соотнести с информационным объектом КЛИЕНТ в рамках функции процесса «проверка заказа».

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

представленных потоков (организационный, функциональный, выходной и информационный) не позволяет

смоделировать бизнес-процесс полностью. Следовательно, необходимо собрать все описания воедино. Для этого нужно взять за основу одно из описаний, а затем интегрировать его с остальными.

Поскольку к определению бизнес-процесса ближе всего подходит поток функций, его можно взять за основу. (позже рассмотрим как можно использовать в этой роли информационные потоки).

Различные потоки в диаграмме представлены разными линиями.

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

управляющими элементами в виде событий и сообщений. Это позволяет

более адекватно описать последовательность выполнения процесса.

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

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

связями можно использовать последовательные, параллельные, альтернативные и комбинированные методы.

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

После того как события «производственный план составлен» и «заказ (поставщику) обработан» посредством соответствующих сообщений активизировали функцию «изготовление изделия», происходит событие «изделие выполнено». Таким образом данный процесс завершается, и это событие посредством сообщений активизирует наступление последующих событий.

только события, имеющие отношение к непрерывному бизнес-процессу. Такие события

называются релевантными.

Потоки функций, управляемые событиями, известны также под названием Event-driven Process Chain (EPC) — событийные диаграммы процесса. Метод ЕРС разработан в 1992 году Институтом информационных систем (Iwi) при Университете Заарланда (Германия) совместно с сотрудниками SAP в рамках проекта научно-исследовательских и опытно-конструкторских разработок, финансировавшегося фирмой SAP AG.
Сейчас этот метод является одним из ключевых компонентов модуля, предназначенного для описания моделей в системе SAP R/3.

Метод ЕРС не проводит жесткого разграничения между описанными потоками. В частности, выходной и управляющий потоки часто могут объединяться, а сообщения не используются. Возможно, именно это упрощение способствовало успешному применению метода ЕРС в реальной практике.

отображение входов и выходов
На диаграмме фактор «производственные ресурсы» представлен

соответствующей машиной, компьютерной системой (рабочей станцией) для управления производственным процессом и компьютером, управляющим данной машиной.

Человеческий ресурс (на выходе или входе), относящийся к объекту (выход, связанный с объектом), представлен с добавлением категории «оператор машины».

Управление (планирование и контроллинг объединенного процесса) определяется стремлением к цели «высокое качество» — одному из ключевых компонентов выполнения процесса. Аспекты, относящиеся к организационной структуре, показаны в привязке к функциям организационных единиц (в данном случае — производственного цеха).

Использование материалов как факторов объектов иллюстрирует соответствующий материал.

быть также поточные объекты, бесплатные и предоставляемые заказчиком, например,

ткань, предоставляемая красильной фабрикой. В качестве других примеров поточных объектов можно привести пациентов больницы или клиентов парикмахерской.

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

Услуги, предоставляемые внешними партнерами, относятся к производству (например, ремонтные услуги), но они не имеют отношения к нефизическому входу, напрямую связанному с обрабатываемым объектом.

разграничить события, активизирующие управляющий поток посредством сообщений, и поток

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

потоки. Характеризуют управление организационными единицами и их обязанности.

2. Целевые

потоки. Характеризуют концептуальные и бизнес-цели, которых требуется достичь в результате выполнения того или иного процесса или действия. Цели ставит руководство.

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

выходов и потоки услуг. Потоки услуг могут функционировать сами

по себе, тогда как потоки материальных выходов обычно управляются и сопровождаются потоками услуг. Услуги подразделяются на информационные (создание и предоставление информации) и прочие. Потоки финансовых ресурсов являются компонентами потоков выходов.

5. Потоки ресурсов. Отображают «доставку» используемого выхода — потенциального фактора «ресурсы». Понятие «ресурсы» охватывает как производственное оборудование, так и компьютерные средства.

6. Потоки человеческих ресурсов. Показывают «доставку» прямого человеческого ресурса.

7. Информационные потоки. Эти потоки управляют доступом к информации, представляющей собой совокупность целенаправленных знаний и навыков, необходимых для выполнения функций.

в виде более детальных бизнес-процессов. Функция рассматривается как процесс

на следующем лежащем ниже уровне, если когда этот процесс можно описать теми же элементами ARIS.

ARIS-модель сосредоточена на концепциях бизнеса, поэтому в центре внимания находятся функции и управляющие ими потоки.

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

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

бизнес-процесса и экземпляром этого процесса существует отношение класс —

экземпляр.

Совокупность конкретных процессов обработки заказа составляет класс, или тип, называемый «бизнес-процесс обработки заказа». Конкретные процессы являются экземплярами (элементами) этого класса. Классы «перенимают» характеристики своих элементов, хотя каждый из классов — это абстракция отдельных его экземпляров.

Целью моделирования бизнес-процесса является усовершенствование организационных изменений всего процесса управления предприятием.
При этом, экземпляры «выстраиваются» в соответствии с новой, усовершенствованной схемой. Если ходе выполнения процесса отдельные экземпляры выпадают из его структуры, то это меняется либо модель либо сам процесс.

уровни типа называются 2-м уровнем описания.

1-й и 2-й уровни

находятся в таком же отношении, как классы и экземпляры. Каждый класс характеризуется именем и перечнем атрибутов, описывающих соответствующий экземпляр. Например, класс КЛИЕНТ характеризуется атрибутами «номер клиента», «имя клиента» и «платежный период». Экземпляры, имеющие эти характеристики, являются предметом описания на 1-м уровне.

Если проводить абстрагирование далее и создать из подмножества на 2 уровне родительский класс (операция называется «обобщение» и обозначается символом «треугольник»), то он будет присваиваются 3-му уровню, который является метауровнем. Полученная схема будет иллюстрировать общие классы описания бизнес-процессов и отношения между ними.