Проектирование информационной системы обработки контента сайта

Проектирование информационной системы обработки контента сайта

СОДЕРЖАНИЕ

 

ВВЕДЕНИЕ

ГЛАВА 1. ОСНОВНЫЕ ПОЛОЖЕНИЯ. СОВРЕМЕННОЕ СОСТОЯНИЕ ДЕЛ В ОБЛАСТИ ОБРАБОТКИ КОНТЕНТА САЙТОВ

.1 Актуальные способы создания веб-сайтов и обработки контента

.2 Обзор программных решений

.3 Предлагаемые пути развития

ГЛАВА 2. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ ОБРАБОТКИ КОНТЕНТА САЙТА

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

.2 Проектирование системы в нотации языка UML

.2 Проектирование базы данных системы

.3 Техническое задание

.4 Управление проектом по созданию информационной системы обработки контента

ЗАКЛЮЧЕНИЕ

СПИСОК ЛИТЕРАТУРЫ

ПРИЛОЖЕНИЯ

 

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

В заключении приводятся основные результаты работы и делаются выводы.

ГЛАВА 1. ОСНОВНЫЕ ПОЛОЖЕНИЯ. СОВРЕМЕННОЕ СОСТОЯНИЕ ДЕЛ В ОБЛАСТИ ОБРАБОТКИ КОНТЕНТА САЙТОВ

1.1 Актуальные способы создания веб-сайтов и обработки контента

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

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

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

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

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

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

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

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

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

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

Из источника информации [12] мы узнаем, что функции систем управления контентом можно разделить на несколько категорий.

.     Создание - предоставляет удобные и привычные средства создания контента для пользователей.

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

.        Публикация - автоматическое размещение информации на терминале пользователя.

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

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

Согласно работе [4], система управления сайтом - это прежде всего программа, которая предназначена для работы в Интернете. В данном случае, подразумевается, что CMS работает на хостинге, который предоставляется некоторым провайдером. Хостинг - это удаленный сервер, который соответствует системным требованиям, оснащен соответствующим программным обеспечением (ПО) и определенной операционной системной (ОС). По сути, установка CMS на абстрактный компьютер (хостинг), аналогична установке программы на компьютер, поэтому веб-сервер должен удовлетворять системным требованиям для соответствующей системы. Как правило, в качестве ОС выступает семейство UNIX/Linux-систем: FreeBSD, Debian, Fedora, CentOs, Red Hat, Windows Server. В качестве веб-сервера как правило используется Apache - это полнофункциональный веб-сервер с открытым кодом. Основными достоинствами Apache считаются надёжность и гибкость конфигурации. Он позволяет подключать внешние модули для предоставления данных, использовать СУБД для аутентификации пользователей, модифицировать сообщения об ошибках. Более подробную информацию о различных веб-серверах можно найти в [20]. Как правило, на хостинге уже установлено необходимое для работы ПО и вопросы требований к техническим аспектам отпадают.

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

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

К примеру рассмотрим структуру бесплатной CMS Opencart 2.0. Согласно [24] данная система состоит из следующих разделов:

·    admin - директория, которая содержит компоненты с моделями, представлением, контроллерами для функционирования административной части,

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

·        image - каталог, содержащий изображения для товарных позиций, изображения для товарных позиций без фотографий, каталогов, кэшированные копии изображений,

·        system - каталог содержащий информацию о ядрах Opencart (системные файлы),

·        install - каталог, отвечающий за установку и первичную настройку,

·        .htaccess.txt- файл содержащий настройки URL ссылок, с целью привести их виду, понятному человеку (SEF URL).

·        config.php - конфигурационный файл, содержащий описание глобальных переменных для папок сайта,

·        index.php - главный файл, который осуществляет перенаправление при обращении,

·        php.ini - файл настроек для php. В нем задаются параметры для стандартной кодировки, памяти выделенной для сайта.

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

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

После установки системы управления содержимым, пользователь получает полностью рабочий сайт с заполненной БД, стандартным шаблоном верстки и функционал, предусмотренный выбранной CMS. Пример фрагмента ER-диаграммы для базы данных, полученной после установки CMS OpenCart 2.0., представлен на рисунке 1.

Из работы [12] следует, что все CMS имеют два раздела:

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

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

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

·    статистика по сайту: посещаемость, количество покупателей, количество заказов, активность пользователей на сайте, диаграммы и графики;

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

·        просмотр групп пользователей, удаление и добавление учетных записей;

·        установка дополнений, модулей, каналов продвижения, подключение статистики;

·        настройка сайта, выбор шаблонов, установка мета-тегов для SEO оптимизации, выбор изображения в качестве логотипа и т.д;

Рисунок 1 - Фрагмент ER-диаграммы БД OpenCart 2.0

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

Большинство систем управления имеют модульную архитектуру, что позволяет администратору выбирать и настраивать компоненты, которые ему необходимы. Функционал CMS систем хорошо расширяем. Для этого используются модули - расширения, интегрирующиеся в систему. Модули могут быть представлены: форумами, блогами, досками объявлений, баннерами, чатами и прочим функционалом, который расширяет возможности системы.

Из работы [22] мы узнаем, что по способу работы, системы управления содержимым можно разделить на три типа:

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

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

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

Сайты, с применением систем управления содержанием, основываются на ряде технологий: БД под управлением СУБД, веб-сервер, веб-приложения, файловый менеджер. Подробную информацию о данных технологиях можно найти в работах [12, 9]. На практике, такие системы функционируют на основе многоуровневой архитектуры «клиент-сервер» (трехуровневая архитектура). Данная архитектура позволяет вынести на сторону сервера слой логики и слой данных. Таким образом, на сервере функционирует необходимое веб-приложение, а слой клиента, организуется посредством браузера пользователя. Более подробную информацию о многоуровневой архитектуре можно найти в [17]. Схематично данную схему можно представить в виде диаграммы развертывания в нотации языка UML. Из работы [5] следует, что диаграмма развертывания - это диаграмма, на который отражены физические связи узлов системы, процессов и объектов. Диаграмма развертывания представлена на рисунке 2.

Рисунок 2 - Диаграмма развертывания для CMS.

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

1.2 Обзор программных решений

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

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

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

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

.     InSales.

2.      OpenCart.

.        CS-Cart.

Рассмотрим данные системы по следующим пунктам:

2.      Установка.

.        Каталог товаров.

.        Оформление заказа.

.        Работа с SEO-параметрами.

InSales - система управления контентом интернет-магазина. Платформа разрабатывается с 2008 года компанией InSales. Платформа специализируется исключительно на создании интернет-магазинов. Система доступна только по модели SaaS. Подходит как для самостоятельной настройки пользователем, так и оказывает услуги по настройке, разработке дизайна и интернет-маркетингу. Согласно источнику информации [25] CMS InSales содержит:

·        полное управление контентом (каталог товаров, меню, страницы, блоки, баннеры, новости, блоги);

·              настраиваемые темы оформления и редактор кода HTML/CSS/JS;

·              регистрация покупателей (необязательная);

·              спецблоки с товарами, акциями, баннерами;

·              разделение прав доступа к разделам бэк-офиса;

·              история изменений заказов;

·              возможность создать мультиязычный магазин.

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

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

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

Рисунок 3 - Форма карточки товаров CMS InSales

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

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

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

Оформление заказа осуществляется с помощью кнопки «В корзину». Пользователю показывается информация о количестве товаров в корзине и суммарной цене корзины.

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

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

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

Рисунок 4 - Список заказов в панели управления InSales

Создавать мета-теги можно для всех страниц. Соответствующие поля есть в формах для этих элементов. Человеко-понятные URL (ЧПУ) настроены по умолчанию.

Адреса страниц формируются автоматически при добавлении товарных позиций. Страницы с ошибкой 404 (страница не найдена) работают корректно.

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

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

Из источника информации [26] следует, что OpenCart - платформа, ориентированная на создание интернет-магазинов. Является свободным программным обеспечением, распространяемым по лицензии GNU General Public License v3. OpenCart разрабатывается с 2012 года компанией OpenCart Limited из Гонконга. OpenCart - предоставляется бесплатно. Однако, она содержит хороший набор функция для интернет-магазина. Также для данной системы управления содержимым много готовых дополнительных модулей и шаблонов. Они могут быть как платными, так и бесплатными.

Для установки OpenCart потребуется свой хостинг. Установка осуществляется путем скачивания архива с системой, переноса на хостинг, создания базы данных (БД) и непосредственно установки CMS.

В результате получается магазин с тестовыми товарами и стандартным шаблоном. Функционалом предусмотрена создание категорий и разделов товаров любой вложенности. Пример формы карточки товара представлен на рисунке 5.

 

Рисунок 5 - Форма карточки товаров CMS OpenCart

Система позволяет отображать один и тот же товар в разных категориях. Карточка товара будет доступна по нескольким адресам, но у них будет канонический URL. То есть, поисковые системы не будут считать данный товар дублированным контентом. Функционал позволяет добавлять «Рекомендуемые товары».

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

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

Расчет стоимости товарной корзины и количества товаров происходит автоматически. При оформлении заказа, система предлагает зарегистрироваться пользователю, либо продолжить без регистрации. Вся информация о заказе заполняется на одной странице. В административной части сайта предусмотрена возможность включения ряда способов доставки. Встроенная возможность по добавлению своих способов доставки не предусмотрена. Для этого необходимо подключать дополнительные модули. Заказа «в 1 клик» отсутствует. Для добавления данного функционала потребуется программист. Список всех заказов хранится в панели управления CMS. Пример списка заказов представлен на риснуке 6.

Рисунок 6 - Список заказов в панели управления OpenCart

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

Из минусов CMS OpenCart можно отметить:

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

2.      После добавления через карточку товара, пользователь оказывается в полном списке товаров. То есть в случае повторного редактирования, товар придется искать снова в общем списке товаров и открыть форму для редактирования.

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

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

CS-Cart - движок для сайта, ориентированный на интернет-магазины. Представляет мощную и удобную панель управления, высокую скорость работы и устойчивость к нагрузкам и взломам. Присутствуют встроенные возможности для проведения маркетинговых операций, адаптивный дизайн. CMS разрабатывается российской компанией Simtech с 2005 года.

Система предоставляется в платном варианте в размере 24500 рублей. Оплата производится единожды.

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

Из информационного ресурса [27] мы узнаем, что товарные категории можно создавать в любом количестве и в любой степени вложенности. Форма для добавления товаров имеет 16 вкладок с различными параметрами. Пример формы для товарной карточки представлен на рисунке 7.

Рисунок 7 - Форма карточки товаров CMS CS-Cart

Форма предоставляет большое количество настроек для товаров:

·    название, описание, цену, фотографии, количество;

·        цену доставки отдельно для этого товара (либо сделать доставку товара бесплатной);

·        скидки, бонусные баллы;

·        характеристики;

·        сопутствующие товары;

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

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

В разделе «Товары - Характеристики» можно добавлять свойства к товарам, например, размер экрана, объем памяти и т.д. А в разделе «Товары - Фильтры» можно настроить фильтр по всем этим характеристикам. Для разных категорий можно выводить как разные фильтры, так и общий. Есть возможность разместить один товар в нескольких категориях. Есть функция «За ту же цену», которая позволяет разместить блок товаров со схожей ценой. Функционалом предусмотрена следующая система скидок:

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

·        купоны на скидку;

·        скидки в зависимости от суммы заказа;

·        можно указывать оптовые скидки.

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

Однако, данную функцию необходимо включать для каждого товара в панели управления администратора. CS-Cart позволяет выводить на главную страницу блоки следующего вида: «Хиты продаж». «Новинки», «Спецпредложения» и т.п. Отзывы и рейтинг к товару встроены по умолчанию. Также отзывы можно оставлять целиком к сайту. По умолчанию, отзывы о новых заказ не приходят, но их можно включить в панели управления.

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

Аналогичным образом добавляются способы оплаты товара из панели управления. Заказ «в 1 клик» встроен по умолчанию и содержит 3 поля для заполнения: имя, телефон или адрес электронной почты. Заказы из формы «в 1 клик» и полноценные заказы попадают в разные разделы списка заказов в панели управления CMS. Уведомления о новом заказе приходят на почту администратору и клиенту. Пример списка для полноценных заказов представлен на рисунке 8.

Рисунок 8 - Список заказов в панели управления CS-Cart

Мета-параметры задаются для всех страниц в соответствующих полях для каждого из разделов. ЧПУ настроены по умолчанию. Адреса страниц добавляются на латинице автоматически при создании страницы. При желании адреса можно скорректировать вручную. Страница с ошибкой 404 «Страница не найдена» обрабатывается корректно.

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

1.3 Предлагаемые пути развития

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

Данный подход влечет за собой ряд минусов:

·    большие временные затраты на обработку входных;

·        большая вероятность внесения ошибочных данных.

Из работы [18] мы узнаем, что для описания бизнес-логики системы (приложения) используются различные модели. Это обусловлено тем, что диаграммы, описывающие бизнес логику, визуально кажутся понятными и простыми. Для моделирования поведения системы в условиях применения CMS воспользуемся нотацией функционального моделирования BPMN. Данные схемы позволяют рассмотреть систему с высокоуровневой модели, которая дает общее предоставление о характере исполнения бизнес-процесса.

Целью применения данной нотации, является уменьшение разрыва между моделями «Как-Есть» и «Как-Должно-Быть». В качестве рассматриваемых моделей, будем использовать исполняемые модели системы, так как они обладают достаточной степенью детализации бизнес-процессов, позволяют верифицировать модель. Следовательно, появляется возможность расширить наиболее узкие места в существующей системе и найти наиболее эффективные способы обработки информации. Для этого воспользуемся диаграммой взаимодействия. Данная схема позволяет описать обмен сообщения между участниками бизнес-процесса (БП), управляемыми по отдельности, каждый из своего центра. Более подробную информацию о нотации BPMN и диаграмме деятельности можно найти в работах [18, 28, 29, 23].

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

Рисунок 9 - Диаграмма взаимодействия процесса «Добавить товар» as-is

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

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

В ином случае, пользователь получает сообщение об ошибке и CMS перенаправляет поток к исходному состоянию. Следующим этапом осуществляется ввод данных о товарной позиции пользователем. Данная операция представлена подпроцессом, который имеет маркер операции для случая (ad-hoc).

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

Следовательно, пользователь сам выбирает нужные ему операции в произвольном порядке, определенном им самим. Развернутый подпроцесс представлен на рисунке 10.

Рисунок 10 - Развернутый подпроцесс «Внести данные о товаре»

Согласно данному подпроцессу, после инициализации формы, пользователь может выполнить одну из 4 операций:

·    сформировать описание товара - описание товарной позиции в товарной карточке. Технические и иные характеристики моделей, ее плюсов и минусов, если таковые имеются;

·        создать мета-теги товара. Данная операция, определяет ключевые слова для улучшения индексации сайта поисковыми системами;

·        загрузить изображения. Данный атрибут является неотъемлемой частью товарной карточки. Именно изображения позволяют оценить первичное качество товара и создать впечатление о товарной позиции в целом;

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

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

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

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

Для наибольшей наглядности, воспользуемся инструментом симуляции потока работ (Simulation View), который входит в состав программного обеспечения для моделирования бизнес-процессов Bizagi Process Modeller. Данный инструмент позволяет провести имитационное моделирование системы с различной степенью детализации.

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

Рисунок 11 - Диаграмма оркестровки для пользователя as-is

Данная схема представлена в виде открытого процесса. Это означает, что пул явно не указывается, а только подразумевается. Однако, поток управления не может пересекать границы пула. На данном этапе развития, Simulation View работает с примитивными потоками управления. Однако, согласно работе [23], нотация BMPN позволяет моделировать как исполняемые, так и аналитические модели системы. В данном случае, используется аналитическая модель, которая позволяет минимизировать степень детализации операций.

Для определения временных затрат, воспользуемся вторым уровнем Simulation View - Time Analysis. Подробную информацию о Simulation View и программном продукте Bizagi Process Modeller можно найти в [30]. Для этого расставим каждой из операции время на выполнение. При формирование временных границ, будем опираться на здравый смысл и эмпирический опыт. Таким образом, временные затраты для данных операций составят:

·    сгенерировать форму ввода - 2 секунды;

·        добавить наименование товара - 1 минута;

·        добавить описание товара - 2 минуты;

·        загрузить изображение товара - 3 минуты;

·        сохранить изменения - 3 секунды;

·        обработать ошибку - 1 минута.

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

В случае, если данные верны, поток завершается. Если данные введены с ошибкой, либо имеют некорректный формат, пользователю необходимо обработать ошибку и снова сохранить изменения. На развилке логического оператора указываются вероятности перехода к одному из событий или операций. Для данного примера, вероятность ошибки составляет 10%. В качестве количества итераций для симуляции данной модели возьмем 100 итераций, что эквивалентно добавлению 100 товарных позиций на сайт. Результаты проведенных симуляций потока работ отражены на рисунках 12 - 13.

Рисунок 12 - Результат моделирования Simulation View

Рисунок 13 - Детализация временных затрат as-is

На рисунке 12 представлены 3 параметра:

·    количество завершенных итераций;

·        среднее время на прохождение одной итерации;

·        суммарное время всех итераций для текущей модели.

Интервал между стартом итераций для данной модели в среднем составляет 1 минуту. Остановкой процесса служит достижение стартовым событием количества заданных итераций. Исходя из рисунка 2, время добавления 100 товарных позиций, составляет 10 часов 24 минуты. Наиболее трудоемкими действиями являются операции добавления наименование, описания, изображения товарных позиций, что составляет 1 час 40 минут, 3 часа 20 минут, 5 часов соответственно. В результате прогона модели на протяжении 100 итераций, пользователь может допустить в среднем 15 ошибок с вероятностью 10%. Суммарное время обработки ошибок составляет 15 минут.

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

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

ГЛАВА 2 ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ ОБРАБОТКИ КОНТЕНТА САЙТА

 

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

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

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

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

Поэтому требуется произвести реинжиниринг данного процесса. Согласно определению М. Хаммера и Д.Чампи в работе [19] реинжиниринг бизнес-процессов определяется, как «фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения коренных улучшений в основных показателях деятельности предприятия». Из работы [16] мы узнаем, что для идентификации бизнес-процессов можно воспользоваться матрицей ранжирования бизнес-процессов. Матрица ранжирования БП представлена рисунке 14.

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

Критические факторы успеха	8					П1
	7
	5			П2
	4
	3
	2
	1	П3,П4,П5
		1	2	3	4	5
	Проблемность бизнес-процессов

Рисунок 14 - Матрица ранжирования бизнес-процессов

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

Процесс П2 - «Обработать входные данные» представляет собой работу по структурированию входного массива данных в виде excel файла. Данный БП находится в желтой зоне, т.е. он влияет на работу систему в меньшей степени, но также может быть подвержен реинжинирингу. Процессы П3, П4, П5 - это процессы, отвечающие за формирование статистики, установку модулей и дополнений. Данные процессы работают хорошо и не требуют реинжиниринга.

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

Этап прямого реинжиниринга предполагает построение модели «as-to-be». Для этого воспользуемся методологией BPMN и построим диаграмму взаимодействия для БП «Добавить товар». Данная диаграмма представлена на рисунке 15.

Рисунок 15 - Диаграмма взаимодействия процесса «Добавить товар» as-to-be

Поток управления начинается аналогично БП «Добавить товар» as-is. Однако, вместо пула CMS используется пул парсер. Следует отметить, что данный функционал не является инновационным. Парсинг сайтов - это синтаксический анализ информации, размещенной на интернет-страницах. Текст веб-страниц представляет иерархический набор данных, структурированный с помощью компьютерных и человеческих языков. Парсинг позволяет эффективно решать следующие задачи:

·    обход огромного количества страниц в кратчайшие сроки;

·        отделение технической информации (тегов) от человеческой;

·        исключение ошибок при отборе параметров, ввиду человеческого фактора;

·        сбор данных в компактный вид в необходимом формате для пользователя.

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

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

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

2.      Происходит создание массива из данных, хранящихся в файле.

.        Осуществляется подключение к БД системы.

.        Создается цикл, осуществляющий проход по ранее созданному массиву.

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

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

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

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

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

После успешной авторизации, пользователь загружает обработанный файл в систему. Вторичный парсер проверяет формат данных на входе. Если введен неверный формат файла, либо данные отсутствуют, пользователю вернется сообщение об ошибке. При введение корректного файла, парсер инициализирует необходимые поля в графическом интерфейсе согласно данным в файле. Следующим этапом, пользователю необходимо определить товарные фильтры. Данный этап подразумевает выбор параметров для их однозначной идентификации на сайта. К ним можно отнести: артикул, оптовая и розничная цена, остаток товаров на складе, ссылки на изображения для товаров, ссылки на товарные позиции, индивидуальные параметры для товаров. Практика показывает, что любому пользователю, работающему в той или иной системе всегда присущи ошибки. Это обусловлено человеческим фактором. При условии большого количества входной информации, человеку сложно сохранять «адекватное» состоянии на всем протяжении работы с системой. Поэтому для исключения влияния человеческого фактора используется процесс валидации введенных данных. Пользователь использует специально сгенерированные кнопки для параметров требующих предварительно заданный формат. При вызове данной функции, пользователь отправляет запрос к БД системы, в которой осуществляется сравнение введенных параметров с существующими записями в БД. В результате проведенной валидации, пользователь получает информацию в наглядном виде об ошибках. Данная процедура позволяет автоматизировать подпроцесс проверки данных на корректность. Финальным этапом, лицо ответственное за наполнения сайта контентом, выбирает функцию добавления товарных позиций. Вторичный парсер обрабатывает полученные данные, подключается к БД и заполняет поля в БД, руководствуясь полями которые определил пользователь на начальном этапе. Процесс добавления товаров происходит в асинхронном автоматическом режиме. Если по каким-либо причинам в одной или нескольких товарных позициях были допущены ошибки, то система игнорирует ошибочные данные, сформирует и отправит пользователю сообщение об ошибках и продолжит добавление товарных позиций в списке. В результате работы системы, вторичный парсер отправляет пользователю сообщения об успешно завершенной операции, в виде наборе артикулов товаров на сайте.

Проведем временной анализ БП as-to-be с применением инструмента Simulation View. Для этого построим схему оркестровки в виде открытого процесса. Данная диаграмма представлена рисунке 1.

Рисунок 16 - Диаграмма оркестровки для пользователя as-to-be

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

·    загрузить файл - 10 секунд;

·        пройти валидацию - 10 секунд;

·        добавить товарные позиции - 3 минуты;

·        обработать ошибки - 10 минут.

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

Представим временные затраты в виде сводной таблицы, после применения предлагаемого решения. Таблица отражена на рисунке 18.

Рисунок 17 - Результат моделирования Simulation View

Рисунок 18 - Детализация временных затрат as-to-be

Из таблицы видно, что общее время на проход всех процессов составляет 5 минут 19 секунд. В данном прогоне модели, пользователь не совершил ошибку при добавление товарных позиций средствами вторичного парсера. Однако, исходя из того, что объем тестовых испытаний достаточно мал, можно предположить, что пользователь совершит ошибку при добавлении товарных позиций. При учете обработки ошибки, суммарное время составит 15 минут 19 секунд.

Таким образом, в данном параграфе был произведен ряд этапов по реинжинирингу бизнес-процесса. Выявлены процессы, требующие реинжиниринга в текущий момент времени и БП, которые работают удовлетворительно или хорошо. Введено понятие парсинга для товарных позиций и рассмотрен ряд диаграмм с точки зрения «Как-Должно-Быть». С помощью инструментов для моделирования потоков работ было рассчитано среднее время добавления товарных позиций на сайт. В результате перехода от старой модели с применением CMS к новой модели, разница во временных затрат приблизительно составит 9 часов. Следовательно, данная модель БП может быть использована для проектирования и реализации системы.

2.2 Проектирование системы в нотации языка UML

Сформулируем базовые требования к разрабатываемой системе.

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

Необходимые функции программы:

·    возможность подключения к базе данных (БД);

·        возможность добавления, удаления товарных позиций;

·        возможность редактирования товарных позиций;

·        возможность добавления фильтров товара;

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

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

·        обработка запросов;

·        возможность входа и выхода из системы;

·        возможность работы с остатками: обнуление остатков, обновление статусов товаров;

·        возможность обработки ошибок в ходе добавления товаров;

·        возможность войти в систему;

·        возможность генерирования выходных данных в excel листы;

·        обработка данных с помощью VBA макросов;

·        возможность сохранения изменений системы;

·        возможность инициализации полей формы;

·        возможность разработки нового функционала.

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

1.   Первичный парсер. Цель создания: обновление товарных позиций на сайте, поиск новых товаров для добавления на сайт, обработка ошибок в ходе поиска товаров, формирование выходных данных системы в виде excel листа.

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

.        Вторичный парсер.

Цель создания: проверка полей на корректность введенных данных, обработка запросов пользователя и передача соответствующих запросов в БД (добавление, удаление товара).

4.   База данных. Цель создания: сбор, хранение и обработка всей информации о товарах, структуре сайта, отображаемом контенте. Вывод данных, соответствующих запросам пользователей.

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

6.      Обновление остатков и статусов. Цель создания: отвечает за обнуление остатков товаров на складе, обновляет статусы товарных позиций (есть в наличии, отсутствует на складе).

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

7.   Графический интерфейс пользователя (GUI). Цель создания: является связующим звеном между excel файлом и вторичным парсингом для пользователя, работающего с системой. GUI позволяет работать с системой конечному пользователю и выполнять ряд операций, связанных с обработкой товаров. Графический интерфейс - один из важнейших элементов системы, т.к. позволяет работать, не требуя от конечного пользователя навыков программирования и администрирования.

8.      Обработчик файлов. Цель создания: генерирование среды Microsoft Visual Basic for Applications для обработки excel файлов по заданным параметрам. Является связующим звеном между excel файлом и VBA обработчиком.

9.      MySQL. Цель создания: система управления базой данных (СУБД) позволяет создавать и обрабатывать различные запросы пользователя, работающего с системой. Позволяет вносить изменения в таблицы БД и получать из них необходимую информацию.

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

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

Класс Values (значения) - это параметризованный класс (шаблон), который определен в виде массива из строк и со значениями Items типа Type. Данный класс привязан командой <bind> к классу БД.

В качестве архитектуры данного приложения воспользуемся шаблоном проектирования model-view-controller (MVC). Для отображения соответствующих компонентов на диаграмме классов согласно Rational Unified Process, возможно использование специальных стереотипов класса: класс-разграничитель (boundary), класс-контроллер (control), класс-сущность (entity). Подробную информацию о шаблоне проектирования MVC можно найти в [13].

Согласно [15], для данной системы необходимо построить диаграмму вариантов использования (ВИ), отражающую функциональные возможности пользователей системы. Диаграмма прецедентов представлена на рисунке 19.

Рисунок 19 - Диаграмма вариантов использования

Сущность «Пользователь» может быть представлена одним или несколькими специалистами, работающими с системой. Это могут быть: контент-менеджер, проект-менеджер или любое другое компетентное лицо. Пользователь имеет ряд возможностей. Он может войти в систему, загружать данные в систему, добавлять и удалять товарные позиции, осуществлять поиск необходимых товаров, обрабатывать остатки, изменять статусы товаров (есть в наличии, отсутствует), добавлять и изменять товарные категории товарных позиций, пройти валидацию товаров на соответствие записям в БД.

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

Далее, необходимо рассмотреть динамические аспекты системы, то есть как объекты меняют свое состояние на протяжении жизненного цикла (ЖЦ) системы. Согласно [11], для этих целей воспользуемся диаграммой состояний. Под состоянием будем понимать: ситуацию в жизненном цикле объекта, во время которой он удовлетворяет некоторому условию, выполняет определенную деятельность или ожидает какого-то события. С точки зрения функциональности системы и смены состояний на протяжении ЖЦ системы, классы первичного и вторичного парсинга являются наиболее необходимыми в рассмотрении. Диаграмма состояния для первичного парсера представлена на рисунке 20.

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

Рисунок 20 - диаграмма состояния для первичного парсинга

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

Данная библиотека позволяет преобразовать HTML текст в DOM (представление документа в виде дерева объектов) и работать с иерархией тегов на сайте. На выходе данного состояния, получается элемент массива, содержащий необходимую информацию о товаре: наименование товара, фильтры, классифицирующие данный товар. В случае достижения счетчика итераций заданного порогового значения, происходит выход из цикла. Об этом сигнализирует событие изменений (change event) - событие, которое возникает когда некоторое логическое условие становится истинным, будучи до этого ложным. Массив выходных данных заносится в соответствующий excel файл, изменения фиксируются, происходит закрытие файла.

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

Рассмотрим диаграмму состояний для вторичного парсинга. Данная диаграмма представлена в приложении 2. Полученный excel файл с новыми товарными позициями, передается на вход через пользовательский файл. Заполненный определенным образом файл, позволяет сгенерировать необходимые поля для добавления на сайт. Система подключается к БД аналогичным образом, описанным выше, Далее происходит добавление сущности продукт. Последующие состояния отвечают за добавление соответствующих записей в БД системы под руководством СУБД. После успешного добавления товарной позиции, система возвращает результат пользователю в виде соответствующего артикула товара на сайте. В случае, если во время добавления товара произошла ошибка (данные не были переданы или данные являются дубликатами для первичных ключей в таблице БД), то происходит вызов функции mysqli_rollback и происходит откат текущей транзакции. В свою очередь пользователь получает сообщение об ошибке, а также состояние, ответственное за ошибку.

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

Как было отмечено выше, для данной системы одним из наиболее важных для рассмотрения критериев, является динамический аспект. Необходимо знать не только как изменяется состояние объекта для экземпляра класса, но и обмен сообщениями между объектами системы во времени. Для этого воспользуемся диаграммой последовательности для моделирования отношений между классами, ролями, компонентами системы в рамках прецедента. Более подробную информацию о диаграмме последовательности можно найти в работе [21]. Диаграмма последовательности отражена в приложении 3.

Данную диаграмму можно условно разделить на два этапа:

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

2.      Добавление подготовленных данных из файла на сайт.

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

Для этого на диаграмме последовательности используется альтернативный фрейм. В случае если авторизация пройдена, контроллер возвращает результат true (верно) и процесс обмена сообщениями продолжается. В случае, если авторизация не пройдена, контроллер организует ответ в виде ошибки и направляет его в класс GUI со стереотипом <<boundary>>. Ошибка может быть представлена в разном виде, а именно: диалогового окна, текстового сообщения, отдельной страницы, вкладки. Класс GUI представляет собой класс-разграничитель. Он отделяет внутреннюю структуру системы от внешней среды. В данной системе он представляет графический интерфейс пользователя, который отправляет и передает данные контроллеру. После авторизации, первичный парсер обрабатывает массив входных данных, создает файл и отправляет сообщение в класс GUI с необходимой статистикой. Из диаграммы следует, что объект «Файл» создается в процессе взаимодействия. Для этого используется сообщение о создании <<создать>>. Данный файл представлен стереотипом класса-сущности (entity) и хранит в себе структурированную информацию о бизнес-объектах. На следующем этапе, сгенерированный файл отправляется синхронным сообщения сообщением от пользователя и инициализирует запуск макроса в классе котроллере «VBA обработчик». На данном этапе, файл обрабатывается контроллером по заданным правилам, изменяет свою структуру, заполняется необходимой информацией и сохраняется. В результате, пользователь получает ответ в виде файла, с правильной структурой.

Второй этап начинается с отправки сообщения пользователем о загрузке файла во вторичный парсер. Данный класс инициализирует необходимые поля, согласно данным, полученным из excel файла. В результате, в графическом интерфейсе пользователя образуется соответствующий интерфейс для добавления данных. Пользователь проводит валидацию данных. Под валидацией данных, понимается действия по сверке данных из excel файла с данным из БД системы. После того как валидация пройдена, происходит добавление товара. Данные передаются из контроллера вторичного парсера и начинается процесс авторизации, аналогичный, описанному выше. После успешной авторизации, запрос на добавление товара обрабатывается следующим образом: создается сущность «продукт» в соответствующей таблице БД. Данный объект заполняется информацией из excel файла. Для этого также, создаются записи в различных таблицах базы данных системы при помощи синтаксиса MySQL. По окончании добавления файла, в графический интерфейс отправляется сообщение об успешном добавлении товара в виде артикула товарной позиции на сайте. Артикул индексируется в БД таким образом, что товары можно найти на сайте, используется поиск по товарным позициям. Далее пользователь удаляет файл из системы, линии жизни всех классов завершаются, объект «файл» окончательно удаляется из системы.

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

2.3 Проектирование базы данных системы

Согласно источнику информации [6], построение базы данных (как и любой информационной системы, любого программного продукта) начинается с проектирования. БД - это контейнер для хранения упорядоченных данных. БД позволяет структурировать данные и упростить работу с ними. Поэтому, возникает необходимость спроектировать БД для данной системы. База данных - это хранилище, созданное и управляемое посредством системы управления базой данных. В качестве СУБД для данной системы будем использовать MySQL. Этот выбор обусловлен тем, что:

·    SQL не относится к числу патентованных языков, используемых разработчиками определенных баз данных. Почти все большие СУБД поддерживают SQL;

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

MySQL представляет собой реляционную СУБД, то есть систему управления реляционными базами данных. Реляционная БД состоит из таблиц, имеющих уникальные имена.

Таблицы состоят из строк, которые в свою очередь не должны повторяться. Столбцы таблиц имеют определенные типы данных, заданные пользователем. Каждая из таблиц БД представляет собой набор записей об однотипных объектах. То есть, таблица product содержит в себе необходимые сведения (атрибуты) о всех продуктах в системе. Как было отмечено выше, строки таблиц должны быть уникальными, то есть набор строк обязан отличаться как минимумом одним атрибутом. Для этого используются различные ключи. Опираясь на источник информации [6], первичный ключ - это минимальный набор столбцов, совокупность значений которых однозначно определяет строку. Для данной системы, так же используются суррогатные ключи. Суррогатный ключ - это ключ, который создан искусственным образом. Основная цель данного ключа - служить первичным. Использование данного типа ключей, обусловлено тем, что он является неизменным на всем протяжении ЖЦ системы, позволяет гарантировать уникальность строк в отличии от первичного ключа, уникальность которого может быть скомпрометирована с течением времени. Стоит отметить, что данные ключи используются с хранимой процедурой автоинкремента. Данная процедура является встроенным триггером в систему. Запуск триггера осуществляется с помощью ключевого слова AFTER. Таким образом, после добавления очередной строки, происходит вызов триггера и суррогатный ключ увеличивает свое значение на 1.

В работе [14] описаны следующие этапы проектирования БД:

.     Определение требований к БД.

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

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

·    идентификатор продукта - артикул продукта, позволяющий однозначно идентифицировать товар с целью его поиска на сайте и в БД;

·        статус товарной позиции - атрибут, отвечающий за видимость товарной позиции на сайте;

·    остатки поставщиков - параметр, определяющий количество оставшегося товара на складе у поставщика (на практике, поставщиков может быть 1..n);

·    оптовая цена, розничная цена - параметры, определяющие цены товарных позиций на сайте соответственно;

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

·        имя товара - это строка, определяющая наименование товара на сайте;

·        описание товара - текст, репрезентирующий товар;

·        ключевые слова (Meta-Keywords). Поисковые системы используют данный атрибут для определения релевантности, или соответствия, ссылки. Используется для индексации товара в поисковых системах;

·        идентификатор фильтра - позволяет однозначно определить фильтры для продуктов;

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

·        идентификатор поставщика - это параметр, который позволяет идентифицировать определенного поставщика;

·        остаток - результирующий атрибут, который отражает количество товара на складе в текущий момент времени;

·        идентификатор категории - атрибут, позволяющий определить товарную категорию;

·        статус категории - параметр, задающий видимость текущей категории товаров на сайте;

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

·        дата добавления категории - атрибут, фиксирующий дату создания категорий.

В результате, получим предварительную структуру базы данных. Однако, на практике, БД реальной системы содержит еще ряд таблиц и данных: filter_description (описание фильтров), filter_group, filter_group_description (группы фильтров и описание этих групп соответственно), product_image (служит для связывания товарных позиций и соответствующих им изображений) и т.д. Но, для функционирования проектируемой системы, таблицы, описанные выше и ряд прочих таблиц либо используются только косвенным образом, либо не используются вообще. Представим, полученную структуру в виде ER-диаграммы на рисунке.

Рассмотрим выделенные объекты.

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

2.      Filters - объект, содержащий записи о товарных фильтрах, по которым производится группировка товара на сайте. Атрибуты: идентификатор фильтра, идентификатор группы фильтра, которой он принадлежит, порядок сортировки. Идентификатор группы позволяет сформировать группы фильтров из всего пространства их имен. К примеру, группа «материал» имеет значение filter_group_id = 4 и содержит все виды материалов. Используя связанный запрос: можно получить полный список материалов и использовать его для решения ряда задач.

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

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

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

На основе, построенной схемы БД, создадим таблицы, используя синтаксис MySQL. Результат создания таблиц БД представлен на рисунках в приложении 4.

Рисунок 21 - ER-диаграмма БД

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

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

2.4 Техническое задание

 

. Общие сведения

Полное наименование системы: Информационная система обработки контента.

Краткое наименование системы: ИС ОК.

2. Назначение и цели создания системы

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

Цели создания системы: ИС ОК создается с целью:

·    ускорения времени обработки входной информации;

·        ускорения процесса редактирования и добавления товаров на сайт;

·        снижения затрат на проект;

·        снижения предъявляемых требований к пользователям, ответственным за наполнение интернет-ресурса данными;

·        сбора необходимой статистической информации о функционировании проекта.

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

·    время обработки и добавления данных на сайт;

·        затраты на проект;

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

·        корректность информации на сайте.

3. Характеристика объектов автоматизации

Структурное подразделение	Наименование процесса	Возможность автоматизации	Решение об автоматизации в ходе решения проекта
Отдел обработки контента	Добавить контент на сайт	Возможна	Будет автоматизирован

 

4. Требования к системе

Требования к структуре и функционированию системы: ИС ОК должна располагаться на удаленном веб-сервере с многоуровневой архитектурой.

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

подсистема управления содержимым OpenCart 2.0 служит ядром для сайта и предоставляет дружелюбный интерфейс для просмотра и редактирования содержимого в ручном режиме;

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

В качестве протокола взаимодействия между пользователями и системой обработки контентеа на транспортно-сетевом уровне необходимо использовать протокол TCP/IP.

В качестве веб-сервера рекомендуется использовать Apache ver. 2.2.22 или Windows IIS.

В качестве серверного языка программирования должен быть использования PHP ver. 5.2.X. Лимит памяти на исполнение PHP скрипта от 64Мб и более. Время на выполнение PHP скрипта не более 10 минут. Должны быть установлены следующие настройки PHP:

·    отключена директива Magic Quotes GPC;

·        отключена директива Register Globals;

·        включена директива File Uploads;

·        для директивы session auto start установлено значение “0” (модуль сессии, не запускает автоматически сессию при старте).

Требования к численности персонала: В состав персонала, необходимого для обеспечения эксплуатации ИС ОК, необходимо выделение следующих ответственных лиц:

·    программист - 1 человек.

·        менеджер - 1 человек.

Данные лица должны выполнять следующие функциональные обязанности:

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

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

Требования к квалификации персонала: К квалификации персонала, эксплуатирующего ИС ДВК предъявляются следующие требования.

·    администратор системы - глубокое знание СУБД, опыт администрирования СУБД, знание языка запросов SQL, опыт программирования на языках PHP, Java Script, HTML, CSS, знание библиотеки jQuery;

·        менеджер - глубокое знание предметной области, знание ПК, знание MS Excel.

Функциональные возможности пользователей системы

Программист:

.     Войти в систему.

2.      Обработать входные данные.

Менеджер:

.     Войти в систему.

2.      Загрузить данные.

.        Удалить файлы.

.        Обработать входную информацию.

.        Проверить корректность введенных данных по шаблону.

.        Добавить товарную позицию.

.        Добавить товарную категорию.

.        Удалить товарную позицию.

.        Удалить товарную категорию.

Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы: Согласно [2] условия эксплуатации, а также виды и периодичность обслуживания технических средств Системы должны соответствовать требованиям по эксплуатации, техническому обслуживанию, ремонту и хранению, изложенным в документации завода-изготовителя (производителя) на них.

Технические средства Системы и персонал должны размещаться в существующих помещениях Заказчика, которые по климатическим условиям должны соответствовать ГОСТ 15150-69 «Машины, приборы и другие технические изделия.

Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды» (температура окружающего воздуха от 5 до 40 °С, относительная влажность от 40 до 80 % при Т=25 °С, атмосферное давление от 630 до 800 мм ртутного столба).