56
риска возможно с помощью проведения более тщательного анализа всех спосо-
бов приобретения системы.
Если риск все-таки осуществился, необходимо провести повторный ана-
лиз вариантов выбора системы. Предыдущий риск взаимосвязан с риском не-
правильного определения функций системы и стратегии автоматизации. Устра-
нение этого риска возможно с помощью применения CASE-средств в процессе
анализа предметной области.
Рассмотрим риски этапа проектирования системы. Одним из рисков этого
этапа является разработка неэффективного плана-графика проекта, который за-
ключается в использовании лишних ресурсов или в дефиците ресурсов. Этот
риск является финансовым, его устранение возможно с помощью использова-
ния программного обеспечения, автоматизирующего процесс планирования
проекта по разработке системы (например, MS Project). Повторное появление
этого риска устраняется с помощью дополнительной корректировкой плана-
графика работ.
Рисками этапа разработки информационного обеспечения задачи являют-
ся разработка неправильной информационной модели и неудобных для пользо-
вателя прототипов экранных форм. Этот риск можно предотвратить с помощью
согласования прототипов экранных форм с пользователями системы. Устране-
ние риска осуществляется при помощи доработки экранных форм.
На этапе подготовки к разработке системы основным риском является
неправильный расчет показателей. Этот риск можно устранить на этапе тести-
рования системы.
На этапе разработки системы основным риском является некорректная
разработка программы. Этот риск устраняется на этапе согласования техниче-
ского задания. Каждый раздел технического задания должен быть разъяснен за-
казчику и только после полного согласования технического задания стоит при-
ступать к разработке системы.
На этапе внедрения существует риск некорректного тестирования техни-
ческого обеспечения программных модулей. Этот риск предотвращается с по-
57
мощью использования лицензионного стендового оборудования, а его устране-
ние осуществляется с помощью дополнительного процесса тестирования.
Рисками этапа сопровождения являются поломка оборудования, мораль-
ное устаревание программного обеспечения и программных средств. Поломку
оборудования можно предотвратить при помощи регулярного мониторинга со-
стояния оборудования. Риск морального устаревания можно предотвратить с
помощью гибко разработанной системы и своевременного осуществления до-
работки программной архитектуры системы.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Рассмотрим аспекты реализации информационной безопасности для по-
ставленной задачи. Защита системы от внутренних угроз предполагает добав-
ление в существующую Политику безопасности организации раздела о разгра-
ничении прав доступа к разрабатываемой системе.
Пользователями системы учета обращений будут сотрудники ИТ-отдела.
Однако у каждой группы пользователей будет доступ не ко всей системе, а
только к некоторым разделам. Диспетчеры должны иметь права на создание и
редактирование заявок, а также на формирование отчетов. Все изменения в си-
стеме должны протоколироваться для возможности выявления лица, нарушив-
шего Политику безопасности. Специалисты ИТ-отдела должны иметь права на
редактирование заявок и формирование отчетов. Права на удаление заявок
должны быть только у администратора системы. Если в процессе работы с си-
стемой была создана ошибочная заявка, ей присваивается статус «закрыта» и
сотрудник пишет соответствующее примечание в заявке.
Определим правила разграничения доступа к разрабатываемой системе.
Для того чтобы определить правила разграничения доступа, выделим группы
пользователей, которые будут работать с разрабатываемой системой:
1. Диспетчер.
58
2. Специалист ИТ-отдела.
3. Администратор системы.
Затем составим список разделов системы и опишем права доступа для
каждой категории пользователей. Права доступа представлены в таблице 8.
Таблица 8
Разграничение прав доступа
Раздел Диспетчер
Специалист
ИТ
-
отдела
Администратор с
и-
стемы
Справочники
Просмотр Просмотр
Редактирование, уд
а-
ление
Заявки
Создание, редактир
о-
вание
Редактирование
Создание, редактир
о-
вание, удаление
Отчеты Просмотр Просмотр
Создание, редактир
о-
вание, удаление
Защита системы от внешних угроз будет реализована с помощью текущей
Политики безопасности организации: на серверное оборудование компании не
установлены сторонние средства удаленного администрирования. Доступ к
серверу осуществляется с помощью «Remote desktop protocol», в том числе на
сервер приложений и СУБД, где будет установлена серверная версия разраба-
тываемой информационной системы. Доступ к серверу осуществляется только
авторизованный.
Для каждого пользователя системы необходима процедура авторизации
для защиты от внутренних угроз информационной безопасности. Ежекварталь-
но система должна запрашивать изменение пароля при авторизации для каждо-
го пользователя, при этом необходимо осуществлять проверку того, не ввел ли
пользователь пароль, который уже им использовался для доступа к системе. На
случай утери пароля или его компрометации необходимо предусмотреть воз-
можность временной блокировки аккаунта.
Для защиты от внешних угроз необходимо хранение паролей в зашифро-
ванном виде и обеспечить надежность каналов связи для того, чтобы избежать
перехвата информации.
Для обеспечения информационной безопасности в организации использу-
ется программное обеспечение «Kaspersky Endpoint Security 11», которое обес-
59
печивает защиту от вредоносного программного обеспечения, и фильтрует се-
тевой трафик, благодаря встроенному брандмауэру.
Также необходимо организовать следующие механизмы обеспечения ин-
формационной безопасности:
• защиту базы данных.
• систему резервного копирования.
Защита базы данных обеспечивается использованием алгоритмов шифро-
вания данных. Резервное копирование осуществляется созданием резервных
копий системы лицом, ответственным за обеспечение информационной без-
опасности.
Защиту от хищения данных злоумышленниками обеспечивает пропускная
система контроля доступа в служебные помещения организации. Защита от
порчи данных регламентируется Политикой информационной безопасности,
которая принята в организации.
На основании вышеперечисленного можно заключить, что в компании
использованы все возможные методы защиты информации, так как нет ни од-
ного уникального метода, который смог бы обеспечить полную информацион-
ную безопасность, а сочетание всех методов позволяет реализовать максималь-
ную информационную безопасность.
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и ее описание
Информационная модель представляет собой новый вариант организации
информационной системы, автоматизирующей процесс приема и распределе-
ния заявок отдела техподдержки. Информационная модель представлена на ри-
сунке 12.
В разрабатываемой информационной системе будут созданы следующие
справочники: сотрудник, должность, абонент, приоритет, вид проблемы, статус
заявки. Также будут таблицы, предназначенные для администрирования систе-
60
мы: пользователь и право доступа. Помимо этого, в системе будут созданы таб-
лицы для хранения оперативных данных: заявка и стадия заявки.
ИС
Спр.
Должность
Спр. Абонент
Спр. Статус
заявки
Спр.
Сотрудник
Диспетчер
Форма
заявки
Форма
отчета
Спр.
Приоритет
Спр.
Должность*
Спр.
Сотрудник*
Форма
редактирования
справочников
Спр. Статус
заявки*
Спр.
Приоритет*
Спр.
Абонент*
Спр. Вид
проблемы
Заявка
Пользователь*
Право*
Стадия заявки
Заявка*
Отчет о проделанной
работе
Диспетчер
Специалист ИТ-отдела
Пользователь
Право
Спр. Вид
проблемы*
Стадия
заявки*
Специалист ИТ-отдела
Рисунок 12. Информационная модель.
Информационная система будет содержать формы заявки, формы отчетов
и редактирования справочников. Формы управления учетными записями поль-
зователей системы. В результате работы системы будет формироваться отчет о
проделанной работе.
61
2.2.2. Характеристика нормативно-справочной, входной и оперативной
информации
Дадим характеристику нормативно-справочной, входной и оперативной
информации. В системе будут доступны следующие справочники:
1. Должность, содержащий информацию о должностях ИТ-отдела и ис-
пользуемый для разграничения функционала системы.
2. Сотрудник, содержащий список всех сотрудников ИТ-отдела.
3. Абонент, который содержит данные об остальных сотрудниках орга-
низации.
4. Вид проблемы, содержащий категорию, к которой относится пробле-
ма.
5. Статус заявки, содержащий информацию об этапе обработки заявки.
6. Приоритет, содержащий данные о срочности выполнения заявки.
Характеристика справочников представлена в таблице 9.
Таблица 9
Характеристика справочников
Характеристика
Должность
Вид проблемы
Приоритет
Ответственный за вед
е-
ние
Администратор системы
Объем справочника в
записях
2 20 4
Частота актуализации
По мере
необходимости
Объем актуализации
1
-
10 записей
Реквизитный состав
Наименование
Наименование
Наименование
Характеристика
Сотрудник
Абонент
Статус заявки
Ответственный за вед
е-
ние
Администратор системы
Объем справочника в
записях
100 10 000 5
Частота
актуализации
По мере необходимости
Объем актуализации
1
-
10 записей
Реквизитный состав
Фамилия
Фамилия
Наименование
Имя
Имя
Отчество
Отчество
Телефон
Телефон
Выходным документом проектируемой системы является отчет о проде-
ланной работе, который содержит следующие поля:
62
1. ФИО сотрудника.
2. Дата начала.
3. Дата окончания.
4. Номер заявки.
5. Статус.
6. Время обработки заявки.
2.2.3. Характеристика результатной информации
Результатной информацией проектируемой системы будет являться отчет
о проделанной работе, в котором будет отражено количество успешно закры-
тых заявок каждого сотрудника ИТ-отдела и количество принятых обращений
каждого диспетчера. Этот документ используется для начисления заработной
платы и контроля деятельности отдела.
В результате пользователю будет выдана отчетная форма, в которой бу-
дут следующие поля:
1. ФИО сотрудника.
2. Дата начала.
3. Дата окончания.
4. Номер заявки.
5. Статус.
6. Время обработки заявки.
Результатная информация содержит данные следующих таблиц базы дан-
ных:
• Статус.
• Заявка.
• Сотрудник.
• Стадия.
Характеристика таблиц с результатной информацией представлена в таблице
10.
63
Таблица 10
Характеристика таблиц с результатной информацией
Наименование таблицы
Наименование поля
Статус
Наименование
Заявка
Номер
Дата
Сотрудник
Фамилия
Имя
Отчество
Стадия
Наименование
2.3. Программное обеспечение задачи
2.3.1. Общие положения (дерево функций и сценарий диалога)
Функции, которые автоматизирует информационная система, делятся на
два типа:
1. Служебные функции.
2. Основные функции [22, стр. 112].
К служебным функциям проектируемой системы будут относиться:
1. Настройка информационной системы.
2. Управление окнами.
3. Помощь по работе с программой.
К основным функциям будут относиться:
1. Редактирование справочников.
2. Создание заявки.
3. Редактирование заявки.
4. Формирование отчетов.
На основании перечисленных функций составим дерево функций систе-
мы (рисунок 13).
64
Рисунок 13. Дерево функций системы.
Затем, на основании дерева функций системы создадим сценарий диало-
га. Для взаимодействия информационной системы с пользователем был выбран
язык типа «Меню». Разрабатываемый сценарий диалога должен обладать воз-
можностью определения состава кадров диалога, содержания каждого кадра и
их соподчиненность. В сценарии диалога должно учитываться:
• работа с формами входных документов.
• формирование результатных документов.
• ввод, редактирование и просмотр данных.
• протоколирование действий пользователей.
• помощь на всех этапах работы с системой [14, стр. 119].
Сценарий диалога представлен на рисунке 14.
65
Главное меню
Заявки
Добавить
Мои заявки
На согласовании
На контроле
Статистика
Заявки в работе по
владельцам и
исполнителям
Настройки
Сбросить
настройки
Найти
Рисунок 14. Сценарий диалога.
2.3.2. Характеристика базы данных
Разработка базы данных осуществляется на основании информационной
модели предметной области. В результате построения информационной модели
были выделены таблицы, в которых будет храниться, и обрабатываться инфор-
мация базы данных. Поскольку база данных будет реляционной, необходимо
описать связи, между таблицами базы.
В качестве стандартной графической нотации, выбрана модель «сущ-
ность-связь» (ER-модель). С её помощью можно выделить ключевые сущности
и обозначить связи, которые могут устанавливаться между этими сущностями.
Во время проектирования базы данных происходит преобразование ER-
модели в конкретную схему базы данных на основе выбранной модели данных
(реляционной).
ER-модель представляет собой формальную конструкцию, которая сама
по себе не предписывает никаких графических средств её визуализации. ER-
модель базы данных АИС, построена в редакторе Erwin Data Modeler и пред-
ставлена на рисунке 15.