- •Понятие бизнес-процесса.
- •Классификация систем.
- •Понятие информационной системы. Требования, предъявляемые к информационной системе. Классификация информационных систем.
- •Понятийный аппарат теории систем.
- •Структура ис. Функциональный, организационный компонент и сод. Все виды обеспечения ис. Программные продукты, требующие моделирования при создании ис.
- •Функциональные компоненты ис
- •Компоненты системы обработки данных
- •Организационные компоненты ис
- •Цели и задачи проведения обследования.
- •Основные определения системного процесса.
- •Понятие жизненного цикла ис. Понятие модели жизненного цикла ис. Типы моделей жц ис. Особенности, преимущества, недостатки.
- •Методы проведения обследования.
- •Методы сбора данных при обследовании.
- •Стандарты графического описания бп.
- •Анализ модели бизнес-процесса.
- •Основные принципы структурной методологии проектирования.
- •Сущность структурного подхода
- •Принцип необходимого разнообразия Эшби.
- •Понятие методологии, методов и технологии моделирования ис. Требования, предъявляемые к современным технологиям моделирования ис.
- •Понятие сложной системы. Неоднородные связи в системе.
- •Обратный инжиниринг.
- •Сферы применения обратной разработки Электроника
- •Программное обеспечение
- •Базы данных
- •Промышленность
- •Военная промышленность
- •Для анализа исходного кода
- •Условия успешного проведения инжиниринга.
- •Типичные ошибки при проведении реинжиниринга.
- •Концепция врм.
- •Критерии оценки решений Аналитики Gartner выделяют как основные следующие критерии оценки bpm-решений:
- •Цели внедрения bpm Концепция предполагает внедрение bpm-решения для достижения следующих целей:
- •Основные участники управления бизнес-процессами
- •Оценивание сложный систем в условиях определенности.
- •Этапы проектирования базы данных. Цель и виды работ на этапе логического проектирования базы данных.
- •Цели внедрения концепции врм.
- •Критерии оценки решений
- •Цели внедрения bpm
- •Цикл Шухарта-Деминга.
- •Понятие предметной области. Значение предметной области для моделирования ис. Способы описания предметной области. Методы сбора данных для описания предметной области. Понятие предметной области
Стандарты графического описания бп.
Стандарты графического описания БП
В настоящее время широко используются и пользуются большой популярностью несколько стандартов моделирования бизнес-процессов:
· Семейство стандартов IDEF (в частности, IDEF0, DFD, IDEF3);
· Семейство стандартов ARIS (в частности, нотация eEPC);
· Семейство стандартов UML (Usecase diagram, activity diagram).
Каждое из этих семейств стандартов представляет собой определенную методологию, и реализовано рядом программных продуктов (CASE-средств). Наиболее популярное ПО, реализующее ту или иную методологию, представлено в таблице ниже.
Таблица 1
|
|
|
Методология |
Программное обеспечение |
|
IDEF |
AllFussion Business Modeler (BPwin), MS Visio |
|
ARIS |
ARIS Toolset |
|
UML |
Rational Rose, MS Visio, ARIS Toolset |
|
|
|
|
Разумеется, в таблице представлены далеко не все программные продукты, которые реализуют ту или иную нотацию описания. На самом деле их значительно больше.
Кроме этого, на практике часто встречаются модели БП, подготовленные с использованием шаблона Audit diagram в программе MS Visio.
Семейство стандартов IDEF
Стандарт моделирования бизнес-процессов IDEF0 был принят в качестве такового в 1981 году. Исторически он возник из стандарта SADT (Structured Analysis and Design Teqnique), активно применявшегося с конца 60-х годов, в частности, Министерством обороны США. IDEF является аббревиатурой от ICAM DEFinition. ICAM - Integrated Computer Aided Manufacturing.
Семейство стандартов IDEF включает в себя ряд графических нотаций, которые могут быть использованы для моделирования бизнес-процессов:
· IDEF0 - стандарт описания бизнес-процессов;
· DFD - диаграмма потока данных (DataFlow Diagram);
· IDEF3 - стандарт моделирования потока работ (workflow).
Семейство стандартов ARIS
ARIS расшифровывается как Arhitecture of Integrated Information Systems (архитектура интегрированных информационных систем). В методологию ARIS входит пять типов представлений моделей:
· Организационные модели, описывающие иерархическую структуру системы: иерархию организационных подразделений, должностей, полномочий конкретных лиц и т.д.;
· Функциональные модели, описывающие функции (процессы, операции), выполняемые в организации;
· Информационные модели (модели данных), отражающие структуру информации, необходимой для реализации всей совокупности функций системы;
· Модели процессов/управления, представляющие комплексный взгляд на реализацию деловых процессов в рамках системы и объединяющие вместе другие модели;
· Модели входов и выходов, описывающие потоки материальных и нематериальных входов и выходов процедур, включая, в частности, потоки денежных средств.
В каждом из этих типов моделей есть ряд нотаций, отличающихся методами моделирования, и число этих нотаций довольно велико. В частности, ARIS Toolset поддерживает ряд нотаций языка моделирования UML (Unified Modeling Language).
Число поддерживаемых ARIS нотаций довольно велико, и описывать каждую из них не целесообразно. Имеет смысл дать основы нотации eEPC, как наиболее, на наш взгляд, применимой для моделирования бизнес-процессов.
Нотация ARIS eEPC расшифровывается следующим образом: Extended Event Driven Process Chain - расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В таблице ниже приводятся основные используемые в рамках нотации графические объекты.
Таблица 2
|
|
|
|
Наименование |
Описание |
Графическое представление |
|
Функция |
Объект «Функция» служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия. |
|
|
Событие |
Объект «Событие» служит для описания реальных состояний системы, влияющих и управляющих выполнением функций |
|
|
Организационная единица |
Объект, отражающий различные организационные звенья предприятия (например, управление или отдел) |
|
|
Документ |
Объект, отражающий реальные носители информации, например бумажный документ |
|
|
Прикладная система |
Объект отражает реальную прикладную систему, используемую в рамках технологии выполнения функции |
|
|
Кластер информации |
Объект характеризует данные, как набор сущностей и связей между ними. Используется для создания моделей данных |
|
|
Стрелка связи между объектами |
Объект описывает тип отношений между другими объектами, например - активацию выполнения функции некоторым событием |
|
|
Логическое «И» |
Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса |
|
|
Логическое «ИЛИ» |
Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса |
|
|
Логическое исключающее «ИЛИ» |
Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса |
|
|
|
|
|
|
В таблице указаны только основные виды пиктограмм, применяемые в данной нотации. Использование большего числа элементов допустимо, но делает модель плохо читаемой.
На рисунке представлена простейшая модель eEPC, описывающая фрагмент бизнес-процесса предприятия.
На рисунке видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1 «активирует» или инициирует выполнение Функции 1. Функция 1 «создает» Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3. Нотация eEPC построена на определенных семантических правилах описания:
· Каждая функция должна быть инициирована событием и должна завершаться событием;
· В каждую функцию не может входить более одной стрелки, «запускающей» выполнение функции, и выходить не более одной стрелки, описывающей завершение выполнения функции.
Кроме этих правил, существуют и другие важные правила формирования моделей в ARIS. Эти правила можно изучить при помощи методического материала «Методы ARIS», который устанавливается на компьютер одновременно с демо-версией продукта.
На рисунке ниже показано применение различных объектов ARIS при создании модели бизнес-процесса.
Каждый объект в системе ARIS Toolset, которая поддерживает метод описания бизнес-процессов ARIS, имеет определенный набор атрибутов. Пользователю предлагается воспользоваться стандартными атрибутами для описания объектов или ограниченным количество т.н. пользовательских атрибутов.
Из рисунка видно, что бизнес-процесс в нотации eEPC представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длительность выполнения процедур в eEPC визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например графики Ганта в системе MS Project.
Таким образом, при помощи нотации eEPC ARIS можно описывать бизнес-процесс в виде потока последовательно выполняемых работ (процедур, функций).
Семейство стандартов UML
Аббревиатура UML расшифровывается как Unified Modeling Language (унифицированный язык моделирования).
UML предназначен в первую очередь для быстрого проектирования и разработки программных продуктов, и описание бизнес-процессов с его использованием целесообразно делать, если в конечном итоге требуется разработать корпоративную информационную систему, которая бы отражала особенности протекания бизнес-процессов на предприятии заказчика.
Язык UML был создан в компании Rational одним из ведущих идеологов объектно - ориентированного подхода к программированию Гради Бучем (Grady Booch), совместно с Джимом Рамбо (Jim Rumbaugh) и Иваром Джекобсоном (lvar Jacobson) в 1994 году.
UML включает в себя ряд типов диаграмм, некоторые из которых могут быть использованы для моделирования бизнес-процессов. В частности, это диаграмма прецедентов (Use-case diagram) и диаграмма действий (Activity Diagram).
Диаграмма прецедентов служит для моделирования типичных сценариев работы с системой.
Диаграмма прецедентов состоит из прецедентов (use-case) - типичных взаимодействий между пользователем и компьютерной системой - и субъектов (actor) - ролей, которые пользователи играют относительно системы. Также на ней могут быть указаны отношения между прецедентами: связь расширения (extends) и связь использования (uses).
Диаграмма действий имеет много общего с блок-схемой, но на ней можно также показывать параллельные процессы. Диаграмма состоит из действий, - некоторых задач, которые должны быть выполнены человеком или компьютером - условных и безусловных переходов, и распараллеливания.
К вопросу о выборе нотации моделирования
Среди специалистов в области моделирования бизнес-процессов часто возникают споры - какую методологию лучше использовать для создания моделей? Каждая из этих методологий имеет свои достоинства и недостатки, какие-то моменты удобнее и эффективнее отражать в той или иной нотации. Однако на наш взгляд однозначного ответа на этот вопрос нет. Выбор той или иной методологии зависит в первую очередь от целей и задач проекта реинжиниринга БП. При этом надо учитывать также степень владения командой аналитиков той или иной методологией, наличие соответствующего ПО, да и просто личные предпочтения руководства проекта.
В любом случае важно, чтобы каждый специалист понимал основные принципы каждой из методологий и умел читать диаграммы, подготовленные с ее использованием.
Критерии ценности информации и минимума эвристик.
Современные методы моделирования ИС. Особенности, области применения.
БИЛЕТ №____7____
