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

Модуль
«Основы информатики» (4)

Оглавление 1

1. Моделирование
предметной области 1

Бизнес-модель 2

Модели
бизнес-процессов 2

Функциональная
модель 3

Организационная
структура 4

Методологии
построения моделей предметной области 4

Методика IDEF0 5

Методика потоков
данных DFD 6

Объектно-ориентированная
методика 7

1. Моделирование предметной области

Автоматизация
управления деятельностью компании
основано на моделировании организационной
структуры, функций управления,
бизнес-процессов, информационных
процессов и данных. Моделирование
предметной области позволяет сократить
сроки проведения проектировочных работ
и получить более эффективный и качественный
проект. Все современные технологии
проектирования ИС основываются на
использовании методологии моделирования
предметной области. К
моделям предметных областей предъявляются
следующие требования:

• формализованное
  описание модели предметной области;

• наглядность
  и информативность модели;

• обеспечение
  оценки эффективности реализации модели
  предметной области на основе определенных
  методов и вычисляемых показателей;

• реализуемость,
  подразумевающая наличие средств
  физической реализации модели предметной
  области в ИС;

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

Структурный
подход к построению моделей предметной
области предполагает создание:

• объектной
  структуры, отражающей состав
  взаимодействующих в процессах
  материальных и информационных объектов
  предметной области;

• функциональной
  структуры, отражающей взаимосвязь
  функций
  (действий) по преобразованию объектов
  в процессах;

• структуры
  управления, отражающей события и
  бизнес-правила, которые воздействуют
  на выполнение процессов;

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

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

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

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

Бизнес-модель

Бизнес-модель
должна
определить миссию, видение и цели
деятельности, функциональную и оргштатную
структуру компании. Согласно международному
стандарту
ISO-15704
миссия
характеризует деятельность, осуществляемую
предприятием для выполнения своих
функций. Одновременно миссия — механизм,
с помощью которого компания реализует
свои цели и задачи. Миссия
разрабатывается,
исходя из рыночной конъюнктуры и
позиционирования компании относительно
других участников внешней среды, с
учетом ресурсных возможностей, принятой
политики и принципов ведения бизнеса.

Для
выполнения миссии разрабатывают
бизнес-стратегии (роста, интеграции и
инвестиций в бизнес, для отдельных
продуктов, функций управления (например,
маркетинговые конкурентные стратегии,
ресурсов), которые задают совокупность
взаимосвязанных целей, количественно
выражаемых через измеримые показатели.
Для достижения целей разрабатывается
система мероприятий (проектов) по их
достижению, создаются факторы,
обеспечивающие успех в достижении
целей. Стратегические цели (ST_i),
как правило, взаимосвязаны, существует
определенная последовательность по их
достижению (рис. 1). Так, достижение цели
ST1
возможно последостижения целей ST2
и ST3.

Рисунок
1

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

Понятие функциональной модели предметной области базы данных

Вторым ключевым моментом создания ИС с целью автоматизации информационных процессов организации является анализ функционального взаимодействия объектов автоматизации. Результаты такого анализа многогранны. Аналитики представляют их в виде функциональной модели предметной области базы данных. Функциональная модель предметной области является собирательным понятием. Состав функциональной модели существенно зависит от контекста конкретного ИТ-проекта и может быть представлен посредством довольно широкого спектра документов в виде текстовой и графической информации. К рассмотрению таких документов проектировщик баз данных должен подходить с учетом следующих двух положений:

• главное назначение ИС является базовым критерием оценки достаточности предоставляемой информации;
• функциональная модель предназначена для описания процессов обработки данных в рамках выделенной предметной области с различных точек зрения.

Описать процессы обработки информации всесторонне с помощью одной описательной модели сложно. В последнее время предпринимаются некоторые успешные попытки разработать унифицированную модель в рамках объектно-ориентированного анализа и проектирования (OOA&D) с помощью UML-конструкций. В настоящих лекциях мы основываемся только на результатах структурного анализа предметной области как наиболее прагматичном подходе для проектирования классических реляционных баз данных. Использование объектно-ориентированного подхода к проектированию баз данных — это предмет отдельного курса лекций.

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

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

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

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

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

• контекстная диаграмма;
• диаграмма декомпозиции ;
• диаграмма дерева узлов;
• диаграмма «только для экспозиции».

Контекстная диаграмма является вершиной иерархической структуры диаграмм и представляет самое общее описание системы и ее взаимодействия с внешней средой.

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

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

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

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

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

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

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

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

Выход ( Output ) — это материалы или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода, которая рисуется как стрелка, выходящая из правой грани работы.

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

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

На рис. 2.9 — 2.11 приведены примеры контекстной диаграммы, диаграммы декомпозиции и диаграммы дерева узлов процесса изготовления изделия.

На диаграмме дерева узлов последний уровень декомпозиции показан в виде списка.

Содержание:

Введение

Электронная торговля в виртуальном магазине основывается на той же структуре, что и традиционная торговля. Преимущества виртуального магазина перед реальным очевидны. Уменьшается численность персонала за счет сокращения объема взаимодействия с клиентами, аренда оборудования или услуг виртуального-хостинга у хостинг провайдеров и размещение списка продаваемых товаров в виде каталога на сайте дешевле и проще аренды торговых помещений и размещения товаров на полках, нет нужды в кассовом обслуживании и так далее. Оплата товаров и услуг по доставке в виртуальных магазинах осуществляется с помощью различных платежных систем работающих в сети интернет. Их подключение к процессинговой системе проведения платежей осуществляется программистом при помощи интерфейсов программирования приложений (API – application programming interface) предоставляемых этими сервисами, примеры таких систем: «Paypal», «QIWI», «Merchant WebMoney Transfer», «Яндекс.Деньги» (перечисленные системы имеют возможность привязки кредитных карт к счету в системе), и другие системы.

Интернет-магазин называют также виртуальным магазином. К нему полностью подходит определение виртуального предприятия. Иначе говоря, виртуальный магазин – это сообщество территориально разобщенных сотрудников магазина (продавцов, кассиров, менеджеров-консультантов) и покупателей, которые могут общаться и обмениваться информацией через электронные средства связи при полном (или минимальном) отсутствии личного прямого контакта. Покупки через интернет – это процесс, при котором потребители непосредственно покупают товары или различного рода услуги через интернет, осуществляя оплату при помощи платежных систем или напрямую с банковской карточки. Консультирование может осуществляться с помощью систем: мгновенного обмена сообщениями, таких как ICQ, Skype и др., электронной почты, а также по телефону используя IP-телефонию и другие доступные средства связи.

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

Цель данной работы – проектирование информационной системы интернет-магазина.

Для достижения поставленной цели нужно выполнить ряд задач:

• провести детальный анализ предметной области;
• построить диаграмму вариантов использования;
• построить диаграммы последовательности;
• построить диаграмму состояний;
• построить диаграммы деятельности;
• построить диаграмму классов.

Описание предметной области

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

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

Оплата заказов клиентами осуществляется при помощи платежных систем, поддерживающих привязку к банковской карте, а именно: “PayPal” и “Яндекс.Деньги”. Все вырученные средства поступают на счет компании и затем обрабатываются сотрудниками бухгалтерского отдела. Данные обо всех финансовых операциях будут экспортироваться в корпоративную информационную систему 1С: Предприятие или другую систему, выбранную для эксплуатации. Но это отдельная задача, в этой работе будет рассматриваться только проектирование и разработка непосредственно веб-сайта виртуального магазина и его установка (развертывание) на производственном сервере.

Почтовые отправления осуществляются с помощью различных компаний по отправке почты, таких как EMS, DHL, “Почта России” и других на выбор клиента. Клиент должен оплатить стоимость доставки самостоятельно, если ее стоимость не включена в стоимость товара. Выбор способа доставки осуществляется клиентом во время оформления заказа на веб-сайте. После отправки товара клиенту выдается номер почтового отправления (почтовый идентификатор), по которому можно отслеживать текущий статус и местоположение посылки. Денежные средства за оплаченный товар резервируются до тех пор, пока системой отслеживания почтовых отправлений не будут получены данные о том, что клиент получил свою посылку.

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

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

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

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

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

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

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

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

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

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

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

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

Моделирование деловых процессов, как правило, выполняется с помощью case-средств. К таким средствам относятся: BPwin (изготовитель программного продукта компания PLATINUM technology), Silverrun (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) и др. В данной работе для создания диаграмм IDEF0 был использован программный продукт BPwin.

1.2.1. Функциональные диаграммы

Функциональное моделирование IDEF0 – методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов.

Построение модели информационной системы начинается с описания функционирования системы в целом в виде контекстной диаграммы. Описание выглядит как «чёрный ящик» с входами, выходами, управлением и механизмом, который постепенно детализируется до необходимого уровня. Данная модель используется при организации бизнес-проектов и проектов, основанных на моделировании всех процессов: как административных, так и организационных.

Рассмотрим контекстную диаграмму «Работа интернет-магазина» (рис. 1).

Рисунок 1 – Контекстная диаграмма «Работа интернет-магазина»

Взаимодействие системы с окружающей средой описывается с помощью входов – «Товары» и «Заказы» совершаемые клиентами, выходов – «Обслуженный клиент», «Не обслуженный клиент» и «Доходы», управления – «Документы», и ресурсов необходимых для решения поставленной задачи – «Сотрудники», «ПО» и «ЭВМ».

Товары – закупленные для продажи товары.

Заказы – заказы совершаемые покупателями.

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

Сотрудники – персонал магазина, распределенный по отделам.

Обслуженный клиент – клиент получивший товар или предоставленную услугу.

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

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

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

Далее рассмотрим диаграмму декомпозиции «Организовать работу интернет-магазина» (рис.2)

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

1. Закупка товаров – закупка товаров, которые будут в дальнейшем продаваться в магазине, у поставщиков;
2. Хранение – обеспечение хранения закупленных товаров на продовольственном складе, отправка товаров по почте при поступлении заказов;
3. Продажа – непосредственно продажа товаров. Так как система оформления заказа будет полностью автоматизирована, в основные обязанности сотрудников отдела продаж будут входить консультирование клиентов, изменение статусов заказов и разрешение возникающих спорных ситуаций.

Рисунок 2 – Контекстная диаграмма «Организовать работу интернет-магазина»

Произведем дальнейшее разбиение на подсистемы процесса «Закупка товаров».

Рассмотрим диаграмму декомпозиции процесса «Закупка товаров» (рис.3). Опишем процессы, представленные на данной диаграмме декомпозиции.

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

Составить перечень закупок – сотрудник отдела закупок, основываясь на данных отчета о состоянии рынка, решает какие товары следует закупить и составляет перечень закупок.

Найти поставщиков – сотрудник отдела закупок просматривает данные о поставщиках, анализируя установленные ими, оптовые цены на товары которые находятся в перечне закупок.

Сформировать заявку на закупку – исходя из перечня необходимых закупок и списка поставщиков, формируется заявка на закупку товаров оптом.

Оплатить закупленный товар – оплата закупленного товара по накладным, полученным от поставщика и передача товаров на хранение на складе.

Рисунок 3 – Диаграмма декомпозиции «Закупка товаров»

Далее продолжим декомпозицию диаграммы «Организовать работу интернет-магазина», произведем дальнейшее разбиение на подсистемы процесса «Хранение» и построим соответствующую функциональную диаграмму (рис. 4)

Рисунок 4 – Диаграмма декомпозиции «Хранение»

Опишем процессы, представленные на данной диаграмме декомпозиции.

Получить товар – кладовщик получает закупленные у поставщиков товары.

Отсортировать товар – сотрудник склада сортирует товар и передает список товаров, которые есть на складе, системному администратору.

Обеспечить хранение – сотрудники склада осуществляют контроль над хранением товара.

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

Теперь произведем разбиение на подсистемы процесса «Продажа» и рассмотрим диаграмму декомпозиции этого процесса.

Опишем процессы, представленные на диаграмме декомпозиции процесса «Продажа» (рис. 5).

Рисунок 5 – Диаграмма декомпозиции «Продажа»

Сформировать заказ – клиент через сайт формирует заказ, при этом он должен принять пользовательское соглашение (если еще не был зарегистрирован на сайте). Затем клиент оплачивает счет.

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

Отследить получение посылки – часто случается, что товар может затеряться во время доставки, поэтому нужно отслеживать состояние посылки до момента ее вручения адресату.

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

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

1.2.2. Анализ функциональной модели

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

Оформление заказа клиентом – чтобы оформить заказ клиент должен будет зарегистрировать аккаунт на веб-сайте, в процессе регистрации он вводит свои данные, такие как: адрес доставки, контактный e-mail адрес, фамилию, имя и другое. Просматривая каталог товаров на веб-сайте, клиент начинает оформлять заказ. Выбрав товары, которые клиент хочет приобрести, он кликает на кнопку “Добавить в корзину”, после выбора всех необходимых товаров клиент нажимает кнопку “Оформить заказ”, выбирает на следующей диалоговой странице способ доставки и способ оплаты. Когда заказ оформлен, система автоматически посылает данные о сделанном заказе по электронной почте в почтовый отдел, сотрудники которого после получения письма должны сформировать посылку по данным заказа и сделать почтовое отправление.

Отслеживание посылки – когда сотрудник почтового отдела отправляет заказ, он заносит номер для отслеживания посылки в данные оформленного заказа. Клиент сможет отслеживать местоположение отправленного ему товара по уникальному почтовому идентификатору посылки (распространенно сокращение трек-номер посылки).

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

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

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

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

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

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

Моделирование предметной области

Диаграмма вариантов использования

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

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

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

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

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

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

Рассмотрим диаграмму прецедентов “Интернет-магазин”, которая приведена на рис.5.

Рисунок 5 – Диаграмма прецедентов “Интернет-магазин”

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

Основные прецеденты включают в себя:

• Управление аккаунтом. Он расширяется прецедентами “Авторизация” – процесс прохождения авторизации на сайте, “Регистрация” – регистрация клиента на сайте, ”Управление аккаунтом” – редактирование профиля пользователя, это может быть изменение личных данных, пароля доступа, адреса доставки и другое.
• Просмотр каталога – просмотр клиентом магазина товаров доступных в продаже. Прецедент связан отношением расширения с прецедентами “Получить консультацию” – связаться с менеджером и узнать дополнительную информацию о продукте, “Оценить продукт” – возможность поставить оценку просматриваемому продукту, “Оставить отзыв” – возможность оставить комментарий к продукту и “Искать продукт” – возможность поиска продукта по ассортименту магазина.
• Оформление заказа. Этот прецедент включает в себя прецеденты “Добавление товара в корзину” (тип связи “include”), “Оплатить” – непосредственно проведение транзакции через платежную систему и “Управлять корзиной” – возможность просмотра товаров находящихся в корзине и управление ими (изменение количества, удаление конкретного товара из корзины).
• Консультировать клиента. Клиент может получать консультации как на веб-сайте, так и с помощью систем обратной связи, например форма обратной связи, консультации через системы мгновенного обмена сообщениями и т.д. Консультацию осуществляет менеджер.
• Управление каталогом. Менеджер может управлять каталогом, добавлять новые категории товаров, новые товары, управлять информацией о товарах, редактировать их описание и другое.
• Обработать заказ. Менеджер управляет статусом заказа и указывает номер почтового отправления. В случае если клиент хочет что-либо изменить в заказе, менеджер может это сделать в интерфейсе управления заказами.
• Администрирование сайта. Веб-сайт нуждается в постоянном администрировании, так как малейший простой в случае сбоя может негативно сказаться на рейтинге магазина. Прецедент включает в себя добавление новостей на сайт, управление аккаунтами пользователей и сотрудников магазина.

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

Реальный прецедент описывает конкретное проектное решение по реализации идеального прецедента в терминах выбранной технологии. Описание реальных прецедентов аналогично описанию идеальных прецедентов.

Таблица 1

Описание прецедента регистрации пользователя

Название прецедента	Зарегистрироваться
Исполнитель	Клиент
Цель	Пройти процедуру регистрации на сайте
Основной успешный сценарий	Клиент переходит на веб-сайт магазина. Кликает кнопку зарегистрироваться. Вводит данные в регистрационную форму и нажимает кнопку отправить данные. На указанный адрес электронной почты поступает письмо содержащее информацию о регистрационных данных
Тип	Идеальный
Ссылки	Добавление нового пользователя, Авторизация, Отправка письма

Таблица 2

Описание прецедента регистрации пользователя

Название прецедента	Управление аккаунтом
Исполнитель	Клиент
Цель	Изменить данные профиля
Основной успешный сценарий	Клиент переходит на веб-сайт магазина, регистрируется. Осуществляет процедуру авторизации на сайте. Управляет данными в своем профиле. Система, взаимодействуя с БД, осуществляет изменение данных пользователя
Тип	Идеальный
Ссылки	Отправить на email уведомление о успешном изменении пароля, изменение данных пользователя в БД

Таблица 3

Описание прецедента Оформление заказа

Название прецедента	Оформление заказа
Исполнитель	Клиент
Цель	Оформить заказ
Основной успешный сценарий	Выбрать товары, которые нужно приобрести, нажать напротив товаров кнопку “добавить в корзину”. Повторять действия до тех пор, пока не будет укомплектован заказ. Затем нажать кнопку “Оформить заказ”. Пройти процедуру оплаты.
Тип	Идеальный
Ссылки	Обновить корзину, Авторизация платежа, Отправка данных о оплаченном заказе на email клиента и в почтовый отдел

Диаграмма последовательности

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

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

На рис. 6. изображена диаграмма последовательностей для прецедента просмотра продукта (расширение прецедента просмотра каталога).

Опишем, что на ней изображено. Пользователь с помощью клиента, в качестве которого выступает веб-браузер, переходит по ссылке на продукт, его браузер выполняет HTTP запрос типа GET. Обработчик URL адресов Django проверяет, что ссылка соответствует регулярному выражению, указанному в конфигурационном файле (urls.py). Если ссылка удовлетворяет заданному шаблону, обработчик URL вызывает функцию представления, передавая в качестве параметров имя представления и словарь GET запроса. В функции представления совершается запрос к классу модели на выборку продукта с id указанным в URL. На выходе генерируется словарь (тип данных языка python) содержащий данные о запрашиваемом продукте. Далее в функции представления осуществляется операция визуализации (render) шаблона и пользователь получает ответ от сайта в виде страницы с продуктом.

На рис. 7. изображена диаграмма последовательностей для прецедента «Оформление заказа».

Рисунок 6 – Диаграмма последовательностей для прецедента “Просмотр продукта”

Покупатель после того как он сформировал виртуальную корзину нажимает на кнопку оформить заказ, веб-браузер отправляет HTTP запрос типа POST, содержащий данные о том какие товары находятся в корзине и их количество. После обработки запроса контроллером и обработчиком URL функция представления вызывает метод makeCheckout экземпляра класса Checkout (обработчик платежей). Экземпляр класса обработчика платежей вызывает метод createOrder класса Order (заказ). Затем этот класс вызывает метод класса OrderItem (отдельный экземпляр содержащийся в заказе) в который добавляются данные для каждого продукта содержащегося в виртуальной корзине (id продукта, количество, цена и id экземпляра класса Order), после того как все экземпляры класса созданы, класс Order вычисляет сумму заказа. Затем класс Order возвращает пользователю страницу предварительного просмотра заказа, после того как пользователь нажимает кнопку подтвердить вызывается метод makeCheckoutPayment, класс Checkout еще раз запрашивает данные заказа у класса Order, затем вызывается метод makePayment который создает класс Payment System API взаимодействующий с платежной системой. Далее этот класс возвращает результат оплаты классу обработчику платежей. Если платежная транзакция завершена успешно, то статус заказа меняется на “оплачен” (с этого момента в отделе доставки начинают формировать посылку для отправления). Пользователю возвращается страница с информацией об успешной оплате заказа.

Рисунок 7 – Диаграмма последовательностей для прецедента «Оформление заказа»

Диаграмма состояний

Описать поведение отдельно взятого объекта помогает диаграмма состояний. 

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

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

Рисунок 8 – Проверка заказа

Рисунок 9 – Диаграмма состояний заказа

Рисунок 10 – Ожидание проверки заказа

Рисунок 11 – Подтверждение заказа

Диаграмма деятельности

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

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

Рисунок 12 – Диаграмма деятельности для оформления заказа

Рисунок 13 – Диаграмма деятельности для оформления доставки

Диаграмма классов

На рис. 14 приведена концептуальная диаграмма классов, основанная на анализе предметной области. Она описывает структуру системы, показывая её классы, их атрибуты и методы, а также отношения между классами (их тип и кратность).

Основные типы связи:

• Обобщение – показывает, что один класс является частной формой другого, то есть отношение часть-целое. Обычно такой связью показывают наследование классов. Графически обобщение представляется линией с пустым треугольником у родительского класса.
• Ассоциация – указывает на то, что объекты одного класса связаны с объектами другого класса. Графически представляется как линия связывающая классы, для именованной ассоциации указывается кратность отношения и её имя. Также помимо кратности иногда указывают роли каждого из взаимодействующих объектов.
• Агрегация – отношение целого и его части. Агрегация встречается, когда один класс является коллекцией или контейнером других. Причём по умолчанию, агрегацией называют агрегацию по ссылке, то есть когда время существования содержащихся классов не зависит от времени существования содержащего их класса. Если контейнер будет уничтожен, то его содержимое – нет. Графически агрегация представляется пустым ромбиком на блоке класса и линией, идущей от этого ромбика к содержащемуся классу.
• Композиция – отношение целого и неотъемлемой его части. Композиция имеет жёсткую зависимость времени существования экземпляров класса контейнера и экземпляров содержащихся классов. Если контейнер будет уничтожен, то всё его содержимое будет также уничтожено. Графически представляется как агрегация, но с закрашенным ромбиком.

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

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

Рисунок 14 – Концептуальная диаграмма классов

Экземпляры класса отзыв не могут существовать без продукта, к которому отзыв был оставлен, поэтому тип связи композиция.

Классы “Типы характеристик” и “Статусы заказа” словарные, в программном продукте будут использоваться в соответствии с шаблоном проектирования “Одиночка”, то есть во время работы приложения будет существовать единственный экземпляр каждого из этих классов. Класс “типы характеристик” будет хранить только названия характеристик, например: ширина, тип, размер, вес, цвет и т.д. Класс “Статусы заказа” хранит возможные статусы заказа, например: отправлен, обрабатывается, получен и т.д. На диаграмме представлены как перечисления.

Заключение

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

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

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

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

Для интернет-магазина приводятся диаграммы последовательности, деятельности, состояний, классов. При проектировании было использовано следующее программное обеспечение: средства построения UML диаграмм Enterprise Architect и AllFusion Process Modeler BPWin .

Список использованной литературы

1. Маклаков С.В. Создание информационных систем с ALLFusionModelingSuite 2003 / С.В. Маклаков – Москва.: ДИАЛОГ МИФИ – Москва, 2003. – 432 с.
2. Ларман К. Применение UML 2.0 и шаблонов проектирования / К. Ларман: пер. с англ. – Москва.: ООО «И. Д. Вильямс», 2007. – 736 с.
3. Буч Г. Язык UML. Руководство пользователя / Г. Буч, Д. Рамбо, А. Джекобсон: пер. с англ. – Москва.: ДМК, 2000. – 432 с.
4. Вендоров А.М. Практикум по проектированию программного обеспечения экономических информационных систем: учеб. Пособие / А.М. Вендоров – Москва.:Финансы и статистика, 2002. – 192 с.
5. Проскурин Д.К. Проектирование информационных систем: учеб. Пособие / Д.К. Проскурин, М.В. Шитикова – Воронеж.: Государственный архитектурно- строительный университет – Воронеж, 2003. – 198 с.
6. Django. Разработка веб-приложений на Python / Д. Форсье [и др.].; пер. с англ.– СПб. : Символ-Плюс, 2010. – 456 с.
7. Django. Подробное руководство. 2-е издание / А. Головатый, Д. Каплан-Мосс.; пер. с англ.– СПб. : Символ-Плюс, 2010. – 560 с.
8. Dive into Python / Mark Pilgrim.; United States, New York.: Apress, 2010. – 495 с.
9. Beginning Django E-Commerce / Jim McGaw.; United States, New York.: Apress, 2009. – 409 с.
10. Django 1.2 E-Commerce / Jesse Legg.; England, Birmingham.: PACKT Publishing, 2010. – 244 с.
11. Django 1.1 Testing and Debugging / Karen M. Tracey.; England, Birmingham.: PACKT Publishing, 2010. – 436 с.
12. Лутс М. Изучаем Python. 4-е издание / М. Лутс.; пер. с англ.– СПб. : Символ-Плюс, 2011. – 1280 с.
13. Фаулер. М. Архитектура корпоративных программных приложений / М. Фаулер.; пер. с англ.– М. : Издательский дом Вильямс, 2006. – 544 с.
14. Флэнаган Д. JavaScript. Подробное руководство, 5-е издание / Д. Флэнаган.; пер. с англ.– СПб. : Символ-Плюс, 2008. – 992 с.
15. Мартин Р. Чистый код. Создание, анализ и рефакторинг / Р. Мартин.; пер. с англ. Библиотека программиста – СПб. : Питер, 2010. – 464 с.
16. Макконелл С. Совершенный код. Мастер класс / С. Макконелл.; пер. с англ. Издательско-торговый дом «Русская Редакция» – СПб. : Питер, 2005. – 896 с.

Можно ли результаты дорогих и трудоемких процедур бизнес-обследования и формализации работы предприятия использовать многократно для решения разных задач? Да, можно. Более того, нужно и полезно.

Можно ли результаты дорогих и трудоемких процедур бизнес-обследования и формализации работы предприятия использовать многократно для решения разных задач — создания ИС, оптимизации управленческой деятельности и т. д? Да, можно. Более того, нужно и полезно.

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

Такая схема подходит для тех компаний, где возможно развертывание «шаблонного» решения. Пример — розничные торговые сети. Деятельность одной сети мало отличается от деятельности другой. Конечно же различия есть (объемы продаж, территориальная удаленность между магазинами, категория покупателей и т. д.), но все же в их работе много общего. Ситуация усложняется, когда деятельность компании обширна и уникальна. Особенно это касается крупных предприятий и территориально распределенных холдингов. В этом случае при проведении процесса автоматизации в такой последовательности становится очевидным ряд существенных недостатков. Во-первых, исполнитель не имеет точного представления об объеме работ, который ему придется выполнить, и, вовторых, окончательный выбор решения происходит до начала детального обследования бизнес-деятельности заказчика (иногда процесс подготовки проекта с этого и начинается);

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

Результаты обследования и формализации деятельности предприятия можно не только положить в основу создаваемой ИС, но и применять в других областях, в таких, например, как оптимизация управленческой деятельности или разработка экономической модели предприятия. Преимущества этого подхода очевидны:

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

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

Место ИТ-стратегии

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

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

Путь к оптимизации

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

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

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

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

Заметным преимуществом такого подхода является достижение постоянного соответствия между потребностями бизнес-деятельности предприятия и возможностями ИС.

Формат представления информации

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

Разумнее всего представлять информацию в соответствии с общепринятым стандартом. При выборе формата надо учитывать то, кто будет ее потребителем. Также рекомендуется соблюдать правило: количество различных стандартов в рамках одного проекта должно быть минимальным. В таблице приведены примеры использования наиболее распространенных стандартов для представления различных видов информации. Конечно, это не полный набор возможных вариантов представления информации в МПО. Окончательный выбор зависит от многих факторов, главный из которых — знание формата большинством участников процессов автоматизации и оптимизации деятельности предприятия, а также опыт работы с ним.

Таблица. Примеры использования наиболее распространенных стандартов описания и моделирования.

Представление раздела информации МПО

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

Кто должен разрабатывать МПО

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

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

Удобно, когда разработку МПО ведут штатные бизнес-аналитики. Они отлично представляют себе особенности компании и тенденции развития. Им понадобится меньше времени на получение необходимой информации, а отразить реальное положение вещей они смогут объективно и всесторонне. Штатные аналитики лично знакомы с сотрудниками предприятия, интервью они могут проводить в неформальной обстановке, поэтому ответы на вопросы будут более полными, с обширными комментариями и объяснением причинно-следственной связи различных событий. Штатный аналитик постоянно находится в компании и может непрерывно отслеживать все изменения в бизнес-деятельности и своевременно их формализовывать. Слабой стороной является то, что бизнес-аналитикам, возможно, придется пойти на компромисс между сохранением нормальных отношений с коллегами и тем, чтобы объективно отражать реальное положение вещей. Например, не всем руководителям понравится, что пометка «процесс запутан и не поддается формализации» относится к значительной части бизнес-процессов, курируемых ими. Кроме этого, не в каждой компании есть команда профессиональных бизнес-аналитиков с обширным опытом работы в этой области. Последнее обстоятельство чаще всего вынуждает руководство предприятия обращаться к внешним специалистам. Еще одна важная проблема штатных аналитиков — доверие со стороны топменеджмента. Как известно, нет пророка в своем отечестве… Бизнес-аналитики, которые входят в штат компании-исполнителя, проводящей автоматизацию предприятия, могут хорошо выполнить работу, но вольно или невольно МПО будет ориентирована на информационные технологии (причем вполне определенные), поэтому нарушится один из принципов построения — представление информации на абстрактном уровне. Скорее всего, в результате получится не МПО, а стратегия развития ИС. Кроме того, из «патриотических» чувств к своему работодателю они будут просто обязаны представить результат так, чтобы в нем фигурировали решения, которые предлагает сама компания-исполнитель. Основной критерий для таких бизнес-аналитиков — это дальнейшее (желательно «вечное») развитие деловых отношений их компании с данным предприятием с целью продажи услуг исполнителя. Хотя, наверное, бывают исключения.

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

Многократное использование результатов

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

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

Дмитрий Цуцаев (dmitrij_tn@mail.ru) и Андрей Алексеенко (alexeenkoas@mail.ru) — руководители проектов.

---

Как автоматизировать неформализуемое?

Наличие бизнес-процессов, которые не удается четко формализовать и детализировать, — один из признаков неоптимальной работы предприятия. Руководству следует обратить на эти процессы пристальное внимание. Очевидно, что в данном случае для автоматизации потребуется не менее двух итераций.

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

---

Структура модели предметной области

Разумно, чтобы в основе модели предметной области (МПО) лежали следующие принципы:

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

МПО включает в себя описание бизнес-деятельности только конкретного предприятия.

Список разделов, входящих в МПО:

1. Организационная структура.
2. Иерархия деловых процессов.
3. Список выполняемых действий.
4. Структура информационных объектов.
5. Глоссарий терминов.

Организационная структура

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

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

Иерархия деловых процессов

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

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

Структура информационных объектов

Она включает описание информационных объектов и ихиерархии.

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

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

Список выполняемых действий

Здесь перечислены действия, выполняемые в процессе работы предприятия и связанные с одним или несколькими бизнес-процессами. Каждое действие характеризуется:

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

Глоссарий терминов

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

МПО не включает в себя:

• оценку экономической эффективности того или иного процесса;
• рекомендации по оптимизации того или иного процесса (МПО — этот только формализация состояния «как есть»);
• привязки процессов к информационным системам и рекомендации по выбору информационных технологий.

— Дмитрий Цуцаев

1. Анализ предметной области

Понятие бизнес-процессов

2.

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

3.

Анализ предметной области – это первый
шаг этапа системного анализа, с которого
начинается разработка программной
системы.
Разработчики должны научиться
• понимать язык, на котором говорят
заказчики;
• выявить цели их деятельности;
• определить набор решаемых ими задач;
• определить набор сущностей, с которыми
приходится иметь дело при решении этих
задач.

4. Модели предметной области

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

5.

Цель моделирования: получение ответов на
совокупность вопросов.
Цель моделирования формулируется на
самом раннем этапе разработки модели.

6.

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

7. Процесс 

Процесс
Процесс — это поток работы, переходящий от
одного человека к другому, а для больших
процессов, вероятно, от одного отдела к
другому.
Процесс [от лат. processus –
течение] последовательная смена состояний
в развитии чего-либо;
ход, развитие какого либо явления.

8. Бизнес-процесс

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

9. Типы бизнес-процессов

• Основные бизнес-процессы –
генерируют доходы компании;
• Обеспечивающие бизнес-процессы –
поддерживают инфраструктуру компании,
• Бизнес-процессы управления –
управляют компанией,
• Бизнес-процессы развития –
развивают компанию.

10. Сущность и значение моделирования бизнес-процессов

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

11. Цель моделирования

Систематизация знаний о компании и ее
бизнес-процессах в наглядной
графической форме более удобной
для аналитической обработки
полученной информации.

12. Моделирование бизнес-процессов включает два этапа:

1) Структурное
Выполняется в нотации IDEF0 с
использованием инструментария
BPwin
или на языке UML с использованием
инструментария Rational Rose.

13.

2) Детальное — выполняется на языке
UML.
Выполняется в той же модели и
должно отражать требуемую
детализацию и
обеспечить однозначное представление
о деятельности организации.

14. Под методологией (нотацией)

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

15. Любая методология включает:

– теоретическая база;
–описание шагов, необходимых для
получения заданного результата;
–рекомендации по использованию

16.

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

17. Методологии семейства IDEF

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

18.

IDEF1 – методология моделирования
информационных потоков внутри
системы, позволяющая отображать и
анализировать их структуру и
взаимосвязи;
IDEF1X (IDEF1 Extended) – методология
построения реляционных структур.
Используется для моделирования
реляционных баз данных;
IDEF2 – методология динамического
моделирования развития систем.

19.

IDEF3 – методология документирования
процессов, происходящих в системе.
С помощью IDEF3 описываются сценарий и
последовательность операций для каждого
процесса.
IDEF4 – методология построения объектноориентированных систем.
Средства IDEF4 позволяют наглядно
отображать структуру объектов и
заложенные принципы их взаимодействия.
IDEF5 – методология исследования сложных
систем .

20.

Система ARIS — комплекс средств анализа и
моделирования деятельности
предприятия.
Ее методическую основу составляет
совокупность различных методов
моделирования.
Одна и та же модель может
разрабатываться с использованием
нескольких методов.

21. Способы описания бизнес-процессов

Способы описания бизнеспроцессов
1. Вертикальное описание
Показывают только работы и их
иерархический порядок в дереве бизнеспроцесса.
Имеются только вертикальные связи
между родительскими и дочерними
работами

22.

23.

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

24.

25. Существуют три основных способа горизонтального описания бизнес-процессов:

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

26. 1. Текстовый способ

• Текстовое последовательное описание
бизнес-процесса

27. Пример. Бизнес процесс: «Оформление заказа»

• Продавец принимает заказ от
покупателя,
• оформляет договор,
• принимает предоплату.
• Предоплата передается в бухгалтерию.
• Информация о заказе поступает
директору, и запускается следующий
бизнес-процесс «Выполнение заказа».

28. 2. Табличный

№
1
Операция
Принять
заказ
Ответствен
От кого
Что
Что (Вход)
-ный
(Поставщик) (Выход)
Продавец
Заказ
Покупатель
—
—
Договор
Директор, бп. «Выполнение заказа».
2
Оформить
договор
3
Получить
предоплату
Продавец
—
—
Кому
(Клиент)
Продавец Предоплата Покупатель Предоплата Бухгалтерия

29. 3. Графический

30. Выделение основных и вспомогательных бизнес-процессов мебельного цеха

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

31. Пример. Основные бизнес-процессы мебельного цеха

Пример. Основные бизнес-процессы
мебельного цеха
–Оформление заказа;
–Выполнение заказа;
–Доставка заказа покупателю;
–Разработка новой модели.

32. Вспомогательные бизнес-процессы:

Вспомогательные бизнеспроцессы:
Технологическая проработка заказа;
Получение материалов со склада;
Работа склада;
Работа бухгалтерии.

33. Подходы к улучшению бизнес-процессов

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

34. Методика быстрого анализа решения

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

35. Улучшениями при применении FAST-подхода являются:

Улучшениями при применении FASTподхода являются:
• снижение затрат,
• длительности цикла;
• уровня ошибок на 5-15% за 3месячный период.
Выявление возможностей для
улучшений и одобрение их внедрения
осуществляется за 1 -2 дня, поэтому
данный подход и получил свое
название FAST2.

36.  Подход FAST реализуется в ходе следующих 8 этапов:

Подход FAST реализуется в ходе
следующих 8 этапов:
1. Определяется процесс, кандидат
на FAST
2. Заказчик соглашается поддержать
инициативу проведения FAST в
отношении процесса
3. Назначается команда FAST,
подготавливается набор целей и
одобряется заказчиком.

37.

4. Команда FAST собирается в течение 1-2-х
дней для разработки обобщенной блоксхемы процесса и определения
мероприятий, способных улучшить
показатели процесса
5. Члены команды FAST должны признать
свою ответственность за внедрение всех
рекомендаций, переданных заказчику
6. По истечении 1-2-х дневного совещания
заказчик присоединяется к совещанию и
команда FAST представляет ему свои выводы

38.

7. Перед окончанием совещания
заказчик одобряет или отвергает
предложенные улучшения
8. Одобренные решения внедряются
назначенными членами команды FAST
в течение следующих 3-х месяцев

39. Бенчмаркинг (Benchmarking) процесса

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

40. Сравнительный анализ

Сравнение некоторых наборов
показателей схожих элементов.
Снижает затраты, длительность цикла и
уровень ошибок на 20-50%
Занимает от 4-х до 6-ти месяцев

41.

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

42.

Эта концепция проектирования процессов
часто называется концепцией наиболее
выгодного нацеленного на будущее
решения Best-Value Future-State Solution
(BFSS))
BFSS — сочетание корректирующих
воздействий и изменений, которые могут
быть применены к изучаемому предмету
(процессу) для увеличения его ценности
для акционеров.

43. Перепроектирование процесса (Концентрированное улучшение)

• Концентрирует усилия команды по
улучшению процесса (Process
Improvement Team (PIT)) на
совершенствовании существующего
процесса
• применяется к процессам, которые
достаточно успешно работают и в
настоящий момент

44. Перепроектирование процесса

• снижает затраты
• длительность цикла
• количество ошибок на 30-60%.

45.

• Используется для 70-90% основных бизнеспроцессов.
• При перепроектировании процессов
строится имитационная модель текущего
состояния (as-is).
• После этого применяются следующие
средства:
• Устранение бюрократии
• Анализ добавленной ценности
• Устранение дублирования

46.

• Упрощение методов
• Сокращение длительности цикла
• Защита от ошибок (анализ текущих
проблем)
• Модернизация процесса (реструктуризация
организации)
• Простой язык
• Стандартизация
• Партнерские отношения с поставщиками
• Автоматизация, механизация, применение
информационных технологий.

47. Реинжениринг процесса

• Называют инновацией процесса,
поскольку его успех в основном
основывается на инновациях и
творческих способностях команды по
улучшению процесса.
• В некоторых организациях этот подход
называют «Анализ общей картины»
или «Разработка нового процесса»

48. Реинжениринг процесса

• Обеспечивает свежий взгляд на цели
процесса и
• полностью игнорирует существующий
процесс и структуру организации.
• Все начинается с чистого листа бумаги

49. Достоинства

• снижает затраты и длительность цикла
на 60-90%
• снижает уровень ошибок на 40-70%.
• является правильным шагом для 5-20%
основных процессов, протекающих в
рамках организации

50.

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

51. Недостатки

• наиболее дорогостоящий из всех
подходов к улучшению б.-п.
• требует много времени
• наибольшая степень риска

52.

• Часто такой подход процесса включает
в себя организационную перестройку
и может быть крайне разрушительным
для организации.
• Большинство организаций могут
единовременно эффективно внедрять
не более одного изменения такого
масштаба.

53. Подход реинжениринга процесса для реализации BFSS состоит из четырех задач

Задача № 1. Анализ общей картины
Задача № 2. Теория единиц (of ones)
Задача № 3. Имитация процесса
Задача № 4. Моделирование процесса