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

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

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

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

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

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

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

· пройти валидацию - 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 обработчик. Цель создания: обработка данных, полученных от первичного парсера. Создание необходимых полей (фильтров) для товарных позиций, сохранение изменений, формирование корректных выходных данных, готовых для добавления на сайт.

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

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

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.

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

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

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

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

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

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

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

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

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

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

· SQL легок в освоении и понимании;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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” (модуль сессии, не запускает автоматически сессию при старте).

Для работы системы необходимо использовать БД MySQLi.

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

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

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

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

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

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

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

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

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

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

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

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

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

Менеджер:

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

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

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

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

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

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

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

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

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

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

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

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

Размещение технических средств и организация автоматизированных рабочих мест должны быть выполнены в соответствии с требованиями ГОСТ 21958-76 «Система "Человек-машина". Зал и кабины операторов. Взаимное расположение рабочих мест. Общие эргономические требования».

Для электропитания технических средств должна быть предусмотрена трехфазная четырехпроводная сеть с глухо заземленной нейтралью 380/220 В (+10-15)% частотой 50 Гц (+1-1) Гц.

Каждое техническое средство запитывается однофазным напряжением 220 В частотой 50 Гц через сетевые розетки с заземляющим контактом.

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

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

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

Для реализации проекта необходима следующие работники:

· менеджер;

· проектировщик;

· программист;

· верстальщик;

· тестировщик;

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

Таблица 1 - Заработные платы специалистов проекта

Специалист	Заработная плата (руб/мес)
Менеджер	15000
Проектировщик	15000
Программист	25000
Верстальщик	15000
Тестировщик	12000
Дизайнер	12000
Технический писатель	10000

Для эффективной организации разработки была построена диаграмма Гантта. Диаграмма представлена в приложении 5.

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

Для построения диаграммы составим таблицу 2. При построении таблицы будет руководствоваться [1].

Таблица 2 - Этапы выполнения работ

Этапы работы	Дата начала	Длительность, дней	Дата окончания
Процесс поставки: 1. Подготовка 2. Подготовка ответа 3. Подготовка договора 4. Планирование	06.03.2017 06.03.2017 07.03.2017 10.03.2017 14.03.2017	12 1 4 2 5	21.03.2017 06.03.2017 10.03.2017 13.03.2017 21.03.2017
Процесс разработки: 1. Анализ требований к системе 2. Проектирование системной архитектуры 3. Проектирование программной архитектуры 4. Реализация интерфейсов	22.03.2017 22.03.2017 31.03.2017 06.04.2017 19.04.2017	68 7 4 9 6	23.06.2017 30.03.2017 05.04.2017 18.04.2017 26.04.2017
5. Программирование модулей системы 6. Тестирование модулей системы 7. Сборка системы 8. Тестирование системы. 9. Документирование ПО 10. Ввод в действие программных средств	27.04.2017 17.05.2017 26.05.2017 31.05.2017 09.06.2017 16.06.2017	14 7 3 7 5 6	16.05.2017 25.05.2017 30.05.2017 08.06.2017 15.06.2017 23.06.2017
Процесс поставки: 1. Поставка ПО и закрытие договора	26.06.2017 26.06.2017	3 3	28.06.2017 28.06.2017

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

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

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

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

Таблица 3 - Матрица ответственности

Работа	Менеджер	Проектировщик	Программист	Верстальщик	Тестировщик	Дизайнер	Технический писатель
Подготовка процесса поставки	ИО
Подготовка ответа	ИО
Подготовка договора	ИО
Планирование	ИО	К	К
Анализ требований к системе	ИО	И	К
Проектирование системной архитектуры	К	ИО	К
Проектирование программной архитектуры	К	ИО	К
Реализация интерфейсов	К		ИО	ИО		ИО
Программирование модулей системы	К		ИО
Тестирование модулей системы	К		Н		ИО
Сборка системы	О	К	И	И
Тестирование системы	К		Н		ИО
Документирование ПО	К						ИО
Ввод в действие программных средств	ИО		И
Поставка ПО и закрытие договора	ИО

При составлении данной матрицы используют методику RACI.

Методика RACI представляет собой аббревиатуру и является наглядным средством для планирования ответственности членов команды проекта на каждом этапе.

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

2. Исполнитель (Responsible) - исполняет задачу, не несет ответственность за выбор способа её решения, но отвечает за качество и сроки реализации. У каждой задачи должен быть хотя бы один исполнитель.

3. Консультант (Consultbeforedoing) - оказывает консультации в ходе решения задач проекта, контролирует качество реализации.

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

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

Таблица 4 - Затраты на заработную плату по месяцам

	Менеджер	Проектировщик	Программист	Верстальщик	Тестировщик	Дизайнер	Технический писатель
1 месяц (1-23 день)	15000	9310	15217	-	-	-	-
2 месяц (24-46 день)	15000	8182	25000	4091	-	3272	-
3 месяц (47-69 день)	15000	1957	25000	1957	4238	-	-
4 месяц (70-92 день)	15000	6818	-	-	4091	-	2273

Рассчитаем основные отчисления в фонды и прочие затраты на проект. К затратам отнесем:

· заработную плату сотрудников

· отчисления в ПФРФ (ставка 22%);

· отчисления в ФФОМС (ставка 5,1);

· отчисления в ФСС (ставка 2,9);

· аренда помещения;

· коммунальные платежи;

· офисная мебель;

· компьютеры;

· интернет;

· уборка помещения.

На практике, компании занимаются работой сразу над несколькими проектами, поэтому переносить полную стоимость ряда затрат на проект является не корректным решением.

Таким образом, аренда помещения составляет 25000 рублей в месяц, но на проект переносится 10% от данных затрат, коммунальные платежи составляют 8000 рублей в месяц, но на проект переносится 50%. Услуги интернета и уборки помещения составляют по 5000 рублей в месяц каждая, однако, на проект переносится по 50% соответственно. Амортизационные отчисления от офисной мебели и компьютеров сроком полезного использования 5 лет, первоначальная стоимость которых 50000 рублей и 120000 рублей соответственно, составят 850 рублей и 2040 рублей. Подробный расчет затрат можно найти в таблице 5.



Таблица 5 - расчет затрат на проект

Затраты	1 месяц	2 месяц	3 месяц	4 месяц	ВСЕГО:
Заработная плата	39527	48182	41957	21818	151484
Отчисления ПФРФ	8696	10600	9231	4800	33327
Отчисления в ФФОМС	2016	2457	2140	1113	7726
Отчисления в ФСС	1146	1397	1217	633	4393
Аренда помещения	2500	2500	2500	2500	10000
Коммунальные платежи	4000	4000	4000	4000	16000
Офисная мебель	850	850	850	850	3400
Компьютеры	2040	2040	2040	2040	8160
Интернет	2500	2500	2500	2500	10000
Уборка помещения	2500	2500	2500	2500	10000
ВСЕГО:	65775	77026	68935	42754	254490

Таким образом, затраты на проект составят 254490 рублей. Конечная стоимость системы составит 400000 рублей.

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



ЗАКЛЮЧЕНИЕ

В заключении подведем основные итоги проведенной работы.

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

На основе обзора существующих CMS выявлена проблема, связанная с добавлением большого количества однотипной информации на сайт. Предложено оптимизирующее решение, на основе которого поэтапно проведен реинжиниринг бизнес-процесса по добавлению новых товарных позиций на веб-сайт. Были построены модели БП «as-is» и «as-to-be» в нотации функционального моделирования BMPN с помощью программного пакета Bizagi Process Modeller. Все модели прошли валидацию без ошибок. При помощи инструмента Simulation View был произведен анализ «Что-Если». Для этого были выделены временные затраты на каждую из операций в модели, и проведены прогоны моделей на заданном количестве итераций.

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

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

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

В работе описаны основные пункты технического задания для разработки ИС.

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

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

ПРИЛОЖЕНИЕ 1

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

ПРИЛОЖЕНИЕ 2

Диаграмма состояний для сущности «Вторичный парсер»



ПРИЛОЖЕНИЕ 3

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



ПРИЛОЖЕНИЕ 4

Создание таблиц БД на основе ER-диаграммы



ПРИЛОЖЕНИЕ 5

Диаграмма Ганта

Размещено на Allbest.ru