Моделирование бизнес-процессов в информационной системе Автомастерской

В нотации IDEF0 система представляется в виде комбинации блоков и дуг.

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

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

В IDEF0 используется четыре типа дуг:

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

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

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

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

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

Рис. 2. Контекстная диаграмма IDEF0 «Деятельность автомастерской»

«Clients call»(Клиенты) - те, для кого работает автомастерская. Они платят деньги в качестве платы за оказываемые услуги («Плата за услуги»).

«Catered facilities»(Обслуженные объекты) – автомобили, которые прошли обслуживание в автомастерской и готовы к отдаче владельцам(«Оказанные услуги»).

В оказании услуг принимают участие «Работники» автомастерской. Чтобы предоставить услуги и получить прибыль, в деятельности автомастерской должны участвовать «Бухгалтерия» и «Материальная база» - обстановка, техника и инструменты для ремонта и т.д. На рис. 3 приведен отчет Model Report по модели ИС:

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

Рис. 3. Диаграмма декомпозиции IDEF0 «Деятельность гостиничного комплекса»

 

Весь процесс «Деятельность  гостиничного комплекса» разбивается  на:

• «Ремонт и обслуживание»;

• «Сборка и тестирование»;

• «Отдача и получение»;

После дальнейшего разбиения  диаграммы получаем 4 диаграммы декомпозиции:

 1. диаграмма декомпозиции IDEF0 «Ремонт и обслуживание»

2. диаграмма декомпозиции IDEF0 «Сборка и тестирование»

3. диаграмма декомпозиции IDEF0 «Отдача и получение»

- описывающие одну  из работ, представленных на  диаграмме верхнего уровня. 

В свою очередь подсистема «Сборка и тестирование» в  результате декомпозиции, разбивается  на 4 подсистемы(Рис.4):

Рис.4 Диаграмма декомпозиции IDEF0 «Сборка и тестирование»

Процесс «Сборка и  тестирование» содержит:

• «Отслеживание и управление сборкой и тестированием»

• «Сборка автомобилей»

• «Сборка деталей»

• «Тестирование автомобилей и деталей»

2.2. Моделирование в IDEF3.

 

IDEF3 (Work Flow Diagram) - это метод,  имеющий основной целью дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе.

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

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

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

В рамках данной курсовой работы представлены описание процесса «Сборка автомобилей» (рис. 5) в методологии IDEF3.

Рис. 5. Диаграмма декомпозиции IDEF3 «Сборка автомобилей»

 

Как только компоненты и детали подготовлены, запускается один последующий за перекрестком (XOR) процесс:

• «Подготовка рабочего места», по окончании которого запускаются одновременно два процесса: «Подготовка инструментов» и «Подготовка электронного оборудования»(Синхронное AND).

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

И последний заключительный процесс «Тестирование автомобилей» (XOR).

Далее при условии  что процесс «Тестирование автомобилей» завершен, обслуженные автомобили отправляют в отдел «Отдача и получение» для передачи владельцам.

Каждая работа в IDEF3 описывает какой-либо сценарий бизнес-процесса и может являться составляющей другой работы. «Сценарий подготовки финансовых отчетов по счетам» показан ниже (рис. 6):

Рис. 6. IDF3-Scenario Diagram «Сценарий сборки автомобилей»

2.3. Моделирование в DFD.

DFD (Data Flow Diagram) используются  для описания документооборота  и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации.

Нотация DFD включает такие  понятия, как «внешняя ссылка» и  «хранилище данных», что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота.

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

Хранилище данных (data store) – графическое представление  потоков данных, импортируемых или экспортируемых из соответствующих баз данных. Обычно это таблицы для хранения документов. В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое и включаются в модель системы в том случае, если имеются этапы технологического цикла, на которых появляются данные, которые необходимо сохранять в памяти. Накопители данных являются неким прообразом базы данных информационной системы организации.

На рис. 7 представлена диаграмма декомпозиции в нотации DFD «Оплата за услуги», описывающая процесс  и варианты оплаты за предоставленные клиентам услуги.

Рис. 7. Диаграмма декомпозиции DFD «Отдача и получение»

 

На диаграмме представлены:

• «Кассир»» - это внешняя ссылка, источник данных извне модели;

• «База данных карточек» - хранилище данных.

В отличие от стрелок IDEF0, которые представляют собой  жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой.

Клиент приходит производить  оплату за выполненную услугу к кассиру, кассир предлагает ему несколько  вариантов оплаты:

1. Наличными деньгами
2. Карточкой
3. Чеком

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

2.4. Расчет оценки функциональной  модели.

BPwin предоставляет аналитику инструмент для оценки модели – стоимостный анализ, основанный на работах (Activity Based Costing, ABC), с целью определить общую стоимость процесса. Стоимостный анализ основан на модели работ, потому что количественная оценка невозможна без детального понимания функциональности  предприятия. Обычно ABC применяется для того, чтобы понять происхождение выходных затрат.

При проведении стоимостного анализа в BPwin сначала задаются единицы измерения времени и денег. В диалоге Activity Properties на вкладке Cost указывается частота проведения данной работы в рамках общего процесса (Frequency) и продолжительность (Duration).

Для расчета оценки модели необходимо установить статьи расходов в меню Cost Center. Для деятельности гостиничного комплекса это будут: материально-техническое оснащение, затраты на персонал и на управление.

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

Рис. 8. Задание стоимости работ в  диалоге Activity Cost

Результаты стоимостного анализа наглядно представляются на специальном отчете BPwin - Activity Cost Report (рис. 9).

Рис. 9. Отчет Activity Cost Report

2.5. Node Tree Diagram.

Node Tree Diagram - это диаграммы,  показывающие не взаимосвязи  между функциями (стрелки), а иерархическую зависимость функций. Диаграмма узлов использует традиционное дерево иерархий, в котором верхний узел (блок) соответствует контекстной диаграмме, а нижний уровень – декомпозицию потомков. На рис. 10 изображена диаграмма дерева узлов модели «Деятельность гостиничного комплекса».

Рис. 10. Диаграмма дерева узлов

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

2.6. Моделирование FEO Diagram.

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

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

Во время выполнения курсовой работы мы построили FEO диаграммы  для диаграмм декомпозиции «Предоплата» (рис. 11) и «Оформление выезда клиента».

Рис. 11. FEO диаграмма для декомпозиции «Сборка и тестирование»

FEO диаграммы позволяют  нарушить любое синтаксическое  правило, поскольку эти диаграммы - фактически обычные картинки - копии

3. Модели данных информационной системы.

 

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

В ERwin существуют два уровня представления и моделирования - логический и

физический.

3.1. Логическая модель данных в 3НФ из ERwin.

Логическое проектирование - построение формализованной модели предметной области. Такая модель строится с использованием стандартных языковых средств, обычно графических,  например ER-диаграмм. Такая модель строится без ориентации на какую-либо  конкретную СУБД.

Основные элементы данной модели:

• описание объектов предметной области и связей между ними;

• описание алгоритмических  зависимостей между данными;

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

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