Автоматизация и обеспечение информационной безопасности приема и анализа заявок технической поддержки. Часть 3

или напишите нам прямо сейчас:

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

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

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

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

или напишите нам прямо сейчас:

Жизненный цикл (ЖЦ) информационной системы — период времени, который начинается с момента принятия решения о необходимости создания ИС и заканчивается в момент ее полного изъятия из эксплуатации.

Ниже приведено описание основных стандартов жизненного цикла:

ГОСТ 34.601-90 – стандарт распространяется на автоматизированные системы и определяет стадии и этапы их создания. Также в стандарте содержится описание состава работ по каждому этапу.

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

Oracle CDM (Custom Development Method) — стандарт по разработке прикладных ИС, детализированный до уровня заготовки проектной документации. Стандарт применяется при разработке с применением Oracle и рекомендуется в случае малых проектов.

RUP (Rational Unified Process) – предполагает итеративную модель разработки согласно четырем фазам: начало, исследование, построение и внедрение. Каждая фаза может подразделяться на этапы, в результате выполнения которых выпускается версия для внутреннего или внешнего использования.

MSF (Microsoft Solution Framework) – стандарт, сходный с RUP. Включает в себя четыре фазы: анализ, проектирование, разработка и стабилизация. Также как и RUP предполагает итеративную модель с использованием объектно-ориентированного моделирования. MSF в отличии от RUP ориентирована более на разработку бизнес-приложений.

XP (Extreme Programming) – стандарт «экстремальное программирование» разработан в 1996 года, в его основе лежат следующие принципы: командная работа, эффективная коммуникация между заказчиком и исполнителем и также ведение разработок с использованием последовательно дорабатываемых прототипов.

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

Стандарт ISO 12207 включает всего 16 процессов, которые объединяются в 3 группы (рисунок 2.1).

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

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

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

Заказ;
Поставка;
Разработка;
Эксплуатация;
Сопровождение.

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

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

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

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

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

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

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

Анализ деятельности
Проведение предпроектного обследования
Разработка плана проекта

Разработка

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

Тестирование настроек системы

Настройка словарей и справочников
Тестирование работоспособности системы
Корректировка системы по результатам тестирования
Подготовка документации для внедрения
План эксплуатации
Документация по установке и настройке ПО
Подготовка плана внедрения

Внедрение

Установка на сервер СУБД
Установка серверных компонентов системы учета заявок
Установка клиентских приложений системы учета заявок
Настройка серверной и клиентских частей
Тестирование работоспособности
Демонстрация работы системы
Подготовка плана по обучению пользователей
Проведение семинара по обучению работе с системой
Обучение службы эксплуатации

Эксплуатация

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

Сопровождение

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

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

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

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

Далее выберем модель жизненного цикла информационной системы.

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

Каскадная;
Циклическая;
Итеративная.

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

Можно выделить следующие положительные стороны применения каскадного подхода:

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

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

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

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

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

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

Существует 4 основных способа начала использования новой системы

Параллельная стратегия;
Скачок;
Узкое место;
Опытная эксплуатация пилотного проекта.

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

2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание

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

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

Этап подготовки проекта

Риск персонала

Риски:

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

Способы предотвращения:

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

Риск ведения проекта

Риски:

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

Способы предотвращения:

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

Риск неверного планирования

Риски:

Неэффективный организационный план внедрения системы
Срыв сроков выполнения работ по этапам

Способы предотвращения:

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

Этап разработки

Риск персонала

Риски:

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

Способы предотвращения:

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

Технические риски

Риски:

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

Способы предотвращения:

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

Этап внедрения

Риск персонала

Риски:

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

Способы предотвращения:

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

Технические риски

Риски:

Потеря данных при внедрение системы

Способы предотвращения:

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

Этап эксплуатации и сопровождения

Технические риски

Риски:

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

Способы предотвращения:

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

1.1.3 Организационно-правовые и программно-аппаратные средства обеспечения информационной безопасности и защиты информации

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

защита информации непосредственно в информационной системе от внутренних угроз;
защита информации от внешних угроз.

Для защиты от внутренних угроз в системе используется политика разделения прав доступа. Характеристика политики приведена в таблице 2.1.

Таблица 2.1

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

Группы пользователей	Модуль «Авторизация»	Модуль «Учет заявок»	Модуль «Ввод данных»	Модуль «Отчеты»
Сотрудник	Чтение	Нет	Нет	Ограничен
Администратор системы	Полный	Полный	Полный	Полный

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

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

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

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

Аппаратной основой системы являются контроллеры Elsys-MB, выпускаемые в различных по характеристикам вариантах исполнения Pro, Pro4, Standard, Light и SM. Наличие этих вариантов, а также модулей расширения памяти различной емкости к ним, позволяет при проектировании оптимизировать технико-экономические характеристики систем различного масштаба.

Контроллеры Elsys-MB объединяются в сеть по двухпроводному интерфейсу RS-485 (до 63 контроллеров в одной линии связи). Линии связи RS-485 подключаются к серверу оборудования СКУД через преобразователи интерфейсов RS-232/RS-485 или USB/232-485 (до 15 линий на один ПК), либо по компьютерной сети предприятия через коммуникационные сетевые контроллеры (КСК) Elsys-MB-Net (до 256 КСК на один ПК). Кроме того, в системе может быть несколько серверов оборудования, объединенных компьютерной сетью, что обеспечивает практически неограниченные возможности масштабирования системы.

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

Правила парольной защиты;
Правила защиты от вирусов и злонамеренного программного обеспечения;
Требования по контролю за физического доступом;
Инструкция по безопасному уничтожению информации или оборудования;
Правила осуществления удаленного доступа;
Требования резервного сохранения информации;
Требование мониторинга доступа и использования систем и ведения лог файлов;
Требования при обращении с носителями данных;
Требования при регистрации пользователей;
Требования по проверке прав пользователей;
Требования по контролю доступа в операционную систему;
Требование к процедуре входа в систему (log on);
Правила использования системных утилит;
Правила удаленной работы мобильных пользователей;
Требование распределения ответственности при обеспечении безопасности;
Правила безопасности при выборе персонала;
Требования контроля оперативных изменений;
Требования к применению криптографических средств управления;
Требования по контролю доступа к исходным текстам программ и библиотек;
Требования контроля вносимых изменений;
Ограничения на изменения прикладного ПО.

2.2 Информационное обеспечение задачи

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

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

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

Область выходной информации
Область справочников системы
Область обработки информации
Область входной информации

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

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

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

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

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

Заявка на обслуживание – поступает от клиентов компании по одному из каналов связи (форма обратной связи на сайте компании, электронная почта, телефон,), содержит следующие сведения
Реквизиты клиента (название организации или фамилия, имя и отчество физического лица, номер договора, ФИО и должность контактного лица, телефон, email).
Описание проблемы и пошаговое описание действий по воспроизведению проблемы (по возможности).
Воспроизводимость — показывает случайный или неслучайный характер носит описываемая проблема.
Критичность – указывает важность решения данной проблемы.
Приоритет – указывает, как быстро следует обработать данное обращение.
Дополнительная информация — все что угодно, в контексте обращения.
Скриншот возникшей проблемы в сжатом формате (gif, png, jpg)

Заявка учитывается путем внесения данных в экранную форму «Учет заявок»

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

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

Название;
№ договора;
Фамилия;
Имя;
Отчество;
Должность;
Телефон;

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

Фамилия;
Имя;
Отчество;
Дата рождения;
Должность;
Телефон;
Тип пользователя;
Логин;
Пароль;
Дата регистрации.

В справочниках:

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

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

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

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

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

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