Проектирование информационной системы ООО экскурсионная фирма «Иван Сусанин»

 

Рис. 1.3.  Классификатор «Миссия и  цели»

 

Данные, которые  содержит классификатор, отображены на рис. 1.4.

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

Рис. 1.4.  Классификатор «Организационно-ролевая  структура»

После определения  организационно-ролевой структуры создается классификатор «Функции». В нем определяется функционал фирмы, необходимый для поддержания коммерческой деятельности. Классификатор «Функции» представлен на рис. 1.5.

Создаём классификатор  «Ресурсы», в который включены основные и вспомогательные ресурсы (рис. 1.8.).

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

После определения процессов  необходимо связать функции с  процессами, внутри которых они выполняются. Эти связи вносятся в матричную  проекцию                     «Процессы_функции».

Аналогично создаются  классификаторы и соответствующие  им матричные проекции: «Сотрудники», «Требования», «Права, полномочия, ответственность», «Виды подчиненности», «Документы и сообщения», «Информационные хранилища и Базы данных», «Бизнесы, продукты и услуги», «Хранилища материалов и продукции»; а также создаются отчёты.

 

 

Рис. 1.5.Классификатор  «Функции»

 

Рис. 1.8.  Классификатор «Ресурсы»

 

Рис. 1.10.  Классификатор «Процессы»

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

Рис. 1.12. «Список объектов модели»

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

Рис. 1.13. «Полная диаграмма бизнес-модели экскурсионной фирмы «Иван Сусанин».

Выводы

В данной главе  проведен системный анализ предметной области «Экскурсионная фирма». В ходе этого анализа перечислены основные структурные схемы компании. Произведен обзор возможностей системы бизнес-моделирования ОРГ-МАСТЕР и выбран метод бизнес-моделирования, который  подходит для разработки бизнес-модели в данной системе.

В итоге разработана «AS-IS» бизнес-модель экскурсионной фирмы «Иван Сусанин» перечислены её основные классификаторы, матричные проекции модели и сгенерированы отчёты. Построена полная схема организационной структуры компании.

Разработанная модель содержит:

• 13 классификаторов;
• 13 матричных проекций;
• 8 отчетов.

Глава 2. Моделирование бизнес-процессов экскурсионной фирмы

2.1. Обзор CASE-технологий

 

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

Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими особенностями:

• мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;
• интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки информационной системы;
• использование специальным образом организованного хранилища проектных метаданных (репозитория). [2]

Среди множества продуктов CASE будут рассмотрены BPwinProcessModeler и RationalRose.

BPwin Process Modeler

AllFusion Process Modeler 7 (ранее BPwin) - инструмент для моделирования, анализа, документирования и оптимизации бизнес-процессов. AllFusion Process Modeler 7 можно использовать для графического представления бизнес-процессов. Графически представленная схема выполнения работ, обмена информацией, документооборота визуализирует модель бизнес-процесса. Графическое изложение этой информации позволяет перевести задачи управления организацией из области сложного ремесла в сферу инженерных технологий.

AllFusion Process Modeler 7 (BPwin) помогает четко документировать важные аспекты любых бизнес-процессов: действия, которые необходимо предпринять, способы их осуществления и контроля, требующиеся для этого ресурсы, а также визуализировать получаемые от этих действий результаты. AllFusion Process Modeler 7 повышает бизнес-эффективность ИТ-решений, позволяя аналитикам и проектировщикам моделей соотносить корпоративные инициативы и задачи с бизнес-требованиями и процессами информационной архитектуры и проектирования приложений. Таким образом, формируется целостная картина деятельности предприятия: от потоков работ в небольших подразделениях до сложных организационных функций.

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

Основные  возможности системы:

·  Поддержка различных технологий моделирования;

·  Анализ показателей затрат и производительности;

·  Интеграция процессов/данных;

·  Поддержка стандартных нотаций;

·  Экспорт объектов и свойств в другие модели;

·  Документирование информации в пределах всей модели; 

·  Масштабируемость отчетности без потери качества графиков [3].

RationalRose

Популярное  средство визуального моделирования  объектно-ориентированных информационных систем компании Rational Software Corp. Работа продукта основана на универсальном языке моделирования UML (Universal Modeling Language). Благодаря уникальному языку моделирования Rational Rose способен решать практически любые задачи в проектировании информационных систем: от анализа бизнес процессов до кодогенерации на определенном языке программирования. Только Rose позволяет разрабатывать как высокоуровневые, так и низкоуровневые модели, осуществляя тем самым либо абстрактное проектирование, либо логическое [4].

Rational Rose не поддерживает ни одну из известных методологий моделирования и анализа бизнес-процессов. Методика построения так называемых «бизнес-моделей», содержащаяся в дополнительном наборе рекомендаций или методике RUP, которая сопровождает пакет Rational Rose, предлагает диаграммы Use Case и Activity для описания бизнес-процессов. Эти диаграммы позволяют описать лишь малую часть сведений, которые нужны для моделирования бизнес-процессов и которые представляются средствами IDEF0. Кроме того, дуги Use Case и Activity диаграмм не имеют тех смысловых типов, которые были указаны для дуг IDEF0. По мнению автора, некие синтаксические соглашения, диктуемые системой при разработке Use Case и Activity-диаграмм, не объединены в законченную и понятную систему; этим диаграммам (что, наверное, главное) не дается никакой интерпретации, объясняющей, как их применять при моделировании. Действительно, что означает, что два процесса соединены стрелкой — просто последовательность их исполнения или, например, то, что второй процесс обрабатывает некоторые результаты деятельности первого, а может быть, наоборот, для работы первого процесса необходима некая информация, которую подготавливает второй? Точно так же непонятно, как интерпретировать связи «процесс-состояние», «состояние-состояние» и др. Поэтому Rational Rose допускает построение синтаксически корректных Activity-диаграмм,  просто не имеющих смысла с точки зрения моделируемого объекта. По этим причинам пользователям Rational Rose при разработке Use Case и Activity-диаграмм приходится придумывать свои оригинальные синтаксические соглашения и давать свою интерпретацию имеющимся, чтобы отразить всю существенную для анализируемого процесса информацию [5].

Исходя из вышесказанного следует только один вывод: CASE-средства, реализованные на основе методологии IDEF0 и поддерживающие ее соглашения, уже только благодаря этому имеют неоспоримые и решающие преимущества перед Rational Rose. (Аналогичную оценку преимущества перед Rational Rose можно дать и системам, основанным на стандарте IDEF3, и ряду других.) Поэтому при необходимости проведения работ, где анализ бизнес-процессов играет важнейшую роль оптимальнее выбирать CASE-средства, основанные на методологии IDEF0 или аналогичной.

 

2.2. Обзор методологий  описания бизнес-процессов

В системе BPwinProcessModeler предусмотрено использование нескольких методологий:

IDEF0

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

Основные элементы и  понятия IDEF0:

Графический язык IDEF0 удивительно  прост и гармоничен. В основе методологии  лежат четыре основных понятия:

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

Каждая из четырех сторон функционального блока имеет  своё определенное значение (роль), при  этом:

• Верхняя сторона имеет значение “Управление” (Control);
• Левая сторона имеет значение “Вход” (Input);
• Правая сторона имеет значение “Выход” (Output);
• Нижняя сторона имеет значение “Механизм” (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы  должен иметь свой уникальный идентификационный  номер.

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

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь  свое уникальное наименование (Arrow Label).

Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Например, для управляющей интерфейсной дуги “распоряжение об оплате” глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т.д. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией [6].

IDEF3

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

• Документировать имеющиеся данные о технологии процесса, выявленные, скажем, в процессе опроса компетентных сотрудников, ответственных за организацию рассматриваемого процесса;
• Определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов;
• Определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса, например изменение конструктивных, технологических или эксплуатационных свойств конечного продукта;
• Содействовать принятию оптимальных решений при реорганизации технологических процессов;
• Разрабатывать имитационные модели технологических процессов, по принципу "КАК БУДЕТ, ЕСЛИ..." [7].

Диаграмма IDEF3 Process Flow Description может состоять из 4 основных описательных блоков:

• работы (boxes, activities);
• стрелки или связи (arrows, links);
• перекрёстки (junctions);
• объекты ссылок.

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

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

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