Автоматизация и обеспечение информационной безопасности обработки заявок ООО «АТД». Часть 2

Страницы: 1 2 3

II. Проектная часть

1.1.  Обоснование проектных решений

2.1.1Обоснование проектных решений по информационному обеспечению

Информационная поддержка (ИО) подсистемы представляет собой информационную модель работы сотрудников предприятия.

К информационной поддержке применяются следующие общие требования:

— информационная поддержка должна быть достаточной для поддержки всех автоматизированных функций объекта;

— принятые классификаторы должны использоваться для кодирования информации;

— структура документов и экранных форм должна соответствовать характеристикам терминалов на рабочих местах конечных пользователей;

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

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

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

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

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

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

Разрабатываемая система должна содержать в себе следующие модули:

— модуль авторизации;

— модуль работы со справочниками;

— модуль ввода данных;

— модуль получения отчетов;

— модуль поиска.

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

Информационная база данных должна состоять:

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

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

2.1.2.  Обоснование проектных решений по программному обеспечению

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

При выборе набора технических средств для разработки системы одним из важнейших критериев является выбор операционной системы. В настоящее время наиболее распространенными являются следующие операционные системы: Windows Vista, Apple Mac OS X, Windows 7, Linux Ubuntu.

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

Наиболее правильным выбором в этой ситуации является операционная система Windows 7 по следующим причинам:

— Удобный интерфейс пользователя;

— Нет необходимости переучиваться;

— Простота администрирования;

— Более низкая стоимость, чем Apple OS;

— Наличие всех необходимых функций.

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

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

Существует огромное количество интегрированных сред разработки, доступных для создания программ под управлением Windows. К ним относятся: Visual С+ +, С+ + Builder, Delphi, Visual Basic. Выбор среды программной разработки для автоматизированной системы сделаем в пользу Delphi, который обеспечивает чрезвычайно высокую производительность и удобство использования.

2.1.3. Обоснование проектных решений по техническому обеспечению

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

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

— персональные компьютеры менеджеров;

— сервера;

— соединительные линии локальной компьютерной сети.

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

— скорость процессора;

— место на жестком диске;

— объем оперативной памяти;

— производительность видеокарты.

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

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

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

• Разработка проекта автоматизации

2.2.1.  Этапы жизненного цикла проекта автоматизации

 

Жизненный цикл информационной системы — это период времени, который начинается, когда принимается решение о создании ИС, и заканчивается, когда она полностью выводится из эксплуатации.

Для реализации проектного решения необходимо изначально определить основные этапы жизненного цикла будущей системы. Из всех доступных стандартов наиболее оптимальным является ISO 12207 -99 [2].  ISO 12207 включает в себя в общей сложности 16 процессов, которые сгруппированы в 3 группы (рисунок 9).

Рисунок 9 Структура стандарта ISO 12207-99

Согласно выбранному стандарту следует выделить следующие этапы:

1.Подготовка проекта

2.Разработка

3. Тестирование настроек системы
4. Внедрение
5. Эксплуатация
6. Сопровождение

Оператор будет нести ответственность за работу готовой системы. Его задача будет включать в себя:

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

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

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

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

Таблица 5

Разграничение прав пользователей

 

Защита от внешних угроз осуществляется путем применения следующих способов:

— разработкой и соблюдение политик безопасности; использованием антивирусных средств;

— физической защитой помещений с наиболее ценной информацией;

— использованием программно-аппаратных комплексов защиты от несанкционированного доступа.

В качестве основного средства защиты от проникновения используется СКУД «Elsys». Elsys предназначена для автоматического контроля доступа и управления исполнительными устройствами (автоматические ворота, шлагбаумы, лифты, турникеты, замки и др.) в соответствии с указанными полномочиями и графиками.

Информационная модель и ее описание

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

Информационная модель включает в себя четыре области: область выходной информации, область эталонной системы, область обработки информации и область входной информации.

Этот процесс показан в информационной модели на рисунке 10.

 

Рисунок 10 Информационная модель системы

 

 

2.2.2. Характеристика нормативно-справочной, входной и оперативной информации

 

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

— Запрос на обслуживание-полученный от клиентов компании по одному из каналов связи (форма обратной связи на сайте компании, электронная почта, телефон), содержит следующую информацию

— Сведения о клиенте (название компании или фамилия, имя и отчество физического лица, номер договора, ФИО и должность контактного лица, номер телефона, адрес электронной почты).

— Описание проблемы и пошаговое описание того, как воспроизвести проблему (если это возможно).

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

— Критичность-указывает на важность решения данной проблемы.

— Приоритет-указывает, как быстро этот запрос должен быть обработан.

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

— Скриншот проблемы в сжатом формате (gif, png, jpg)

Регистрация заявки осуществляется путем ввода данных в экранную форму «учет заявок».

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

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

— Название;

— № договора;

— Фамилия; Имя; Отчество;

— Должность;

Телефон;

— Email.

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

— Фамилия;

— Имя;

— Отчество;

— Дата рождения;

— Должность;

— Телефон;

— Тип пользователя;

— Логин;

— Пароль;

— Дата регистрации.

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

— Справочник Улица;

— Справочник Тип Клиента;

— Справочник Статус;

— Справочник Тип пользователя;

— Справочник Населенный пункт;

— Справочник Приоритет;

— Справочник Должность.

 

2.2.3. Характеристика результатной информации

 

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

1. Журнал поступления заявок от клиентов;
2. Ведомость учета работ специалистов отдела техподдержки;
3. Ведомость учета и контроля поступления заявок от клиентов за период;
4. Отчет об оказанных дополнительных услугах;
5. Отчет о степени загруженности сотрудников отдела технической поддержки;
6. Аналитический отчет о наиболее часто возникающих проблемах клиентов;
7. Отчет по заявке;
8. Сводный отчет по клиентам.
9. Отчет о выполненных заявках клиентов за период,
10. Аналитический отчет о выполнении заявок клиентов за период

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

В данном документе рассчитываются следующие показатели:

• Общее количество поступивших заявок;
• Общее количество распределенных заявок;
• Общее количество выполненных заявок.

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

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

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

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

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

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

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

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

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

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

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

2.3. Программное обеспечение задачи

2.3.1. Общие положения (дерево функций и сценарий диалога)

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

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

Рисунок 11 Дерево функций пользователя ИС

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

— Клиент;

— Заявка;

— Справочник;

— Пользователь;

— Отчеты;

— Выход.

Сценарий диалога приведен на рисунке 12.

Рисунок 12 Сценарий диалога системы

2.3.2. Характеристика базы данных

Инфологическая (концептуальная) модель — это формализованное описание предметной области, выполняемое независимо от используемого в дальнейшем программного и аппаратного обеспечения. [3]

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

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

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

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

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

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

Схема базы данных представлена на рисунке 13.

Описание таблиц представлено на рисунках ниже.

Рисунок 13 Схема БД

Рисунок 14 Таблица Клиент

Рисунок 15 Таблица Заявка

Рисунок 16 Таблица Пользователь

Рисунок 17 Таблица Справочник Причина

Рисунок 18 Таблица Справочник Отделение

Рисунок 19 Таблица Справочник Услуга

        Остальные таблицы, такие, как:

• Справочник Улица;
• Справочник Тип Клиента
• Справочник Статус;
• Справочник Тип пользователя;
• Справочник Населенный пункт;
• Справочник Приоритет;
• Справочник Должность;

Имеют в своем составе только код записи и наименование соответствующего атрибута.

2.3.3. Структурная схема пакета (дерево вызова программных модулей

 

Структурная схема пакета ИС приведена на рисунке 20.

Рисунок 20 Структурная схема пакета ИС

Описание программных модулей приведено в пункте 2.3.4.

2.3.4. Описание программных модуле

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

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

Сервер приложений располагается на втором уровне. На втором уровне сосредоточена большая часть бизнес-логики. Сервер приложений разработан при помощи технологии Delphi XE2 DataSnap. Передача данных между клиентом и сервером осуществляется через протокол TCP.

Сервер приложений взаимодействует с базой данных через СУБД Microsoft SQL Express. Подключение к базе данных выполняется через технологию ADO.

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

В структуре сервера можно выделить две основные части: Модуль управления сервером (TdmServer) и модуль предоставления данных (TdssmRemoteData). Описание модулей приведено ниже.

Таблица 6

Структура сервера приложений

 

Модуль управления сервером

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

Рисунок 21 Состав модуля TdmServer

Как уже отмечалось, сервер передает данные по протоколу TCP (за это отвечает компонент DSTCPServerTransport). Поэтому порт прослушивания должен быть установлен для сервера. В нашем случае он имеет значение 5000.

При подключении на сервере создается отдельный поток. Клиент должен передать аутентификационные данные (имя пользователя и пароль), которые проверяются компонентом DS AuthenticationManager. Если процедура аутентификации проходит успешно, сервер создает интерфейс для передачи данных между сервером и клиентом. Этот интерфейс является экземпляром класса TdssmRemoteData.

Если возникает ошибка проверки подлинности, сервер создает исключение и уничтожает поток, созданный для этого соединения.

Интерфейс взаимодействия

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

Рисунок 22 Состав модуля TdssmRemoteData

Цепочка передачи данных между клиентом и сервером выглядит так:

1. Компонент подключения к БД (TADOConnection);
2. Набор данных (TADOTable или TADOQuery);
3. Провайдер набора данных (TDataSetProvider);
4. Компонент клиентского соединения (TSQLConnection);
5. Клиентский компонент соединения с провайдером данных (TDSProviderConnection);
6. Клиентский набор данных (TClientDataSet).

Пункты 1, 2, 3 – выполняются на стороне сервера, а пункты 4, 5, 6 – на стороне клиента. Компоненты класса TDataSetProvider служат для определения прав доступа и настройки параметров передачи данных клиенту. В его настройках можно указать такие параметры как: доступность набора данных для клиента, режим «только чтение», запрет редактирования, запрет вставки, запрет удаления и т.д.

Модуль выдачи рекомендаций

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

В состав модуля входит компонент Request (класс TRequest) внутри которого реализован ряд методов для быстрого подсчета количества однотипных заявок и их стоимости за различные периоды времени.

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

Модуль описания заявки

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

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

Клиент

Основой клиентской части является модуль TdmData. Модуль выполняет следующие функции: получение доступа к функциональности сервера (создание проекции интерфейса взаимодействия «TdssmRemoteData»); управление предоставленными сервером наборами данных; соединение с сервером.

Для подключения к серверу используется компонент SQLConnection. В качестве параметров подключения мы указываем: IP-адрес сервера; порт подключения (5000); логин и пароль пользователя; протокол взаимодействия (в нашем случае TCP); тип подключения (DataSnap).

Чтобы получить доступ к функциональности сервера и данных, используется специальный компонент DSProviderConnection. Этот компонент необходим для подключения клиентского набора данных (TClientDataSet) к поставщику набора данных (TDataSetDrovider).

После успешного подключения к серверу доступные наборы данных активируются (набор данных открывается).

После открытия набора пользователь может редактировать набор данных с помощью визуальных компонентов (таких как TDBGrid, TDBEdit, TDBMemo, TDBImage, TDBNavigator и т. д.).) разработан специально для работы с базами данных. Однако визуальные компоненты не подключаются непосредственно к клиентскому набору данных, а используют специальный «посредник» (объект класса TDataSource), предназначенный для унификации использования визуальных компонентов с различными типами наборов данных.

Клиент также получает доступ к интерфейсу взаимодействия сервера TdssmRemoteData. На стороне клиента через компонент DSProviderConnection создается «проекция» класса TdssmRemoteData, которая включает в себя все методы серверного класса с открытым спецификатором. Класс проекции инициализируется сразу же после подключения клиента к серверу.

Рисунок 23 Схема модуля TdmData

Блок-схема модуля построения списка заявок приведена на рисунке 24

Рисунок 24 Блок-схема модуля построения списка заявок

Страницы: 1 2 3