48
3. Финансовыми.
Эти виды рисков взаимосвязаны между собой. Например, в случае болезни
сотрудника, выполняемую им работу можно отложить, что приведет к увеличению
сроков выполнения проекта или другие сотрудники могут выполнять эту работу
сверхурочно, что потребует дополнительного бюджета. После выявления рисков
руководитель проекта составляет документ «План реагирования на риски». Это
позволяет в самом начале проекта создать резервные ресурсы, которые могут
потребоваться в случае осуществления того или иного риска.
Для каждого этапа проекта по разработке системы, автоматизирующей
процесс внутрикорпоративного взаимодействия, выделим риски и разработаем план
реагирования на них.
Рисками этапа анализа могут быть:
Неполное выявление требований к системе. Сюда входят и
функциональные, и нефункциональные требования;
Ошибки при формировании этапов и работ проекта.
В результате осуществления этих рисков возникнет потребность в доработке
системы, которая будет выявлена на этапе эксплуатации системы. Реализация этого
риска повлечет за собой дополнительные финансовые и временные затраты.
Чтобы предотвратить эти риски, необходимо использование средств
автоматизации проектирования информационных систем, например, CASE-средств
для моделирования бизнес-процессов на этапе выявления требований
пользователей.
Следующим риском этапа анализа являются ошибки при выявлении функций
системы. При реализации этого риска возникает новый риск неправильного выбора
способа приобретения системы. Предотвращение этого риска возможно с помощью
проведения тщательного анализа всех способов приобретения системы. Если риск
все-таки осуществился, нужно провести повторный анализ способов приобретения
системы.
Опишем риски этапа проектирования. Одним из них является создание
неэффективного плана-графика работ проекта. Это влечет за собой либо
избыточность ресурсов, либо, наоборот, их дефицит. Этот риск относится к группе
финансовых рисков. Устранить его можно с помощью использования программного
49
обеспечения, автоматизирующего процесс планирования проекта по разработке
системы (например, MS Project, Lotus, GanntPro). При повторном появлении этого
риска потребуется повторная корректировка плана-графика работ.
На этапе реализации существует риск разработки неправильной
информационной модели и неудобных для пользователя прототипов экранных
форм. Этот риск можно предотвратить с помощью согласования прототипов
экранных форм с пользователями системы. Устранение риска осуществляется при
помощи доработки экранных форм.
На этапе проектирования системы основным риском является неправильный
расчет показателей. Этот риск можно устранить на этапе тестирования системы.
На этапе реализации системы основным риском является некорректная
разработка программного кода. Этот риск можно устранить на этапе согласования
технического задания. Каждый раздел технического задания должен быть разъяснен
заказчику и только после полного согласования технического задания стоит
приступать к разработке системы.
Риском этапа тестирования системы является не полное выявление ошибок в
функционировании системы. Эти ошибки могут быть выявлены на этапе
эксплуатации и потребуют дополнительных затрат на их устранение. Такая ситуация
достаточно часто встречается, минимизировать этот риск можно с помощью
высококвалифицированных специалистов, задействованных не только на этапе
тестирования, но и на этапе реализации. Это может потребовать увеличения
бюджета проекта, но снизит риск дополнительных затрат при обнаружении ошибок
в ходе эксплуатации системы.
Риском этапа внедрения системы являются: некорректное тестирование
технического обеспечения программных модулей. Этот риск предотвращается с
помощью использования лицензионного оборудования, а его устранение
осуществляется с помощью дополнительного тестирования.
Рисками этапа сопровождения являются поломка оборудования, моральное
устаревание программного обеспечения и программных средств. Поломку
оборудования можно предотвратить при помощи регулярного мониторинга
состояния оборудования. Риск морального устаревания можно предотвратить с
помощью гибко разработанной системы и своевременного осуществления
50
доработки программной архитектуры системы. Эта группа рисков ложится на
заказчиков программного обеспечения.
2.1.3. Организационно-правовые и программно-аппаратные средства обеспечения
информационной безопасности и защиты информации
Под информационной безопасностью (ИБ) АИС понимается состояние
защищенности информационной среды АИС, обеспечивающее её формирование,
использование и развитие, которое не приводит к искажению, разрушению или
несанкционированному использованию информационных ресурсов, включая
хранимую, обрабатываемую и передаваемую информацию, а также программные
средства [6].
Выделяют следующие основные цели ИБ [4]:
конфиденциальность (доступность информации только определенному
кругу лиц);
доступность (возможность получения информации авторизованными
пользователями в нужное для них время);
целостность (гарантия существования информации в неискаженном,
истинном виде).
Информация, обрабатываемая и сохраняемая в, является ценной [18]:
технологическая. Эта информация не является конфиденциальной, но в
любой момент она должна быть целостной и доступной, иначе работа остановится,
и предприятие понесет убытки.
деловая. Эта информация должна быть конфиденциальной, доступной
и целостной.
Само функционирование системы также относится к ценным активам
компании, т.к. нарушение работы ИС приведет к потере доступа к ценной
информации. Поставки будут сорваны, рабочее время потеряно.
Определим, какие угрозы имеются с точки зрения информационной
безопасности:
Внутренние угрозы (исходящие от так называемых «инсайдеров» -
сотрудников компании). Это может быть умышленная и непредумышленная порча
51
или удаление файлов с ценной информацией, ввод неверных данных, а также
незаконное копирование (хищение) информации;
Внешние угрозы: действия хакеров, промышленный шпионаж, вирусы
и т.п.;
Нарушение связи по вычислительной сети с офисом;
Отключения электропитания, пожары, наводнения и т.п.
Для того, чтобы обеспечить защиту разрабатываемой системы от внутренних
угроз необходимо добавить в Политику безопасности организации раздел, в котором
будут описаны правила разграничения прав доступа к разрабатываемой системе.
Пользователями системы будут все сотрудники организации. Однако у всех будет
разный доступ к разделам системы. Для этого выделим роли пользователей
проектируемой системы:
1. Администратор – сотрудник, отвечающий за управление доступом к
информационной системе, а также объектами системы: справочниками и
документами.
2. Руководитель – руководитель структурного подразделения, который
осуществляет контроль учета рабочего времени персонала.
3. Сотрудник отдела управления персоналом – специалист, отвечающий
за ведение табеля учета рабочего времени.
4. Пользователь – остальные сотрудники организации.
Определим правила разграничения доступа к разрабатываемой системе. Затем
составим список разделов системы и опишем права доступа для каждой категории
пользователей. Права доступа представлены в таблице 8.
Таблица 8
Разграничение прав доступа
Раздел
Руководитель
Пользователь
Сотрудник
отдела
кадров
Администратор
Справочники
Просмотр
Редактиров
ание
Создание,
редактирование,
удаление
Документы
Просмотр
Создание,
редактиров
ание
Отчет
Просмотр
-
Просмотр
52
Защита системы от внешних угроз будет реализована с помощью текущей
Политики безопасности организации: на серверное оборудование компании не
установлены сторонние средства удаленного администрирования. Доступ к серверу
осуществляется с помощью приложения «Remotedesktop protocol», в том числе и к
серверу приложений и СУБД, где будет установлена серверная версия
разрабатываемой информационной системы. Доступ к серверу может быть только
авторизованным.
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
Информационная модель представляет собой схему движения входных,
промежуточных и результативных потоков и функций предметной области [13].
Кроме того, она объясняет, на основе каких входных документов и какой
нормативно-справочной информации происходит выполнение функций по
обработке данных и формирование конкретных выходных документов.
Информационная модель представлена на рисунке 14.
Информационная модель будет включать следующие справочники:
1. Сотрудник.
2. Должность.
3. Отдел.
4. График работы.
Помимо этого, в базе данных информационной системы будут созданы таблиц
для учета оперативных данных об отработанном времени. Также в информационной
системе будут предусмотрены следующие формы:
1. Форма справочника.
2. Форма документа.
3. Форма отчета.
53
ИС
Спр.
Сотрудник
Т. Смена
Спр. График
работы
Т. Табель
Руководитель
Форма
документа
Спр.
Должность
Спр.
Отдел*
Спр.
Сотрудник*
Форма
справочника
Спр.
График
работы*
Т. Табель*
Спр.
Должность*
Т.
Пользователь
Т. Смена*
Т. Рабочее
время*
Т.
Пользователь*
Учет
рабочего
времени
Руководитель
Т. Право
доступа*
Спр. Отдел
Т. Рабочее
время
Т. Право
доступа
Т. Роль
пользователя
Форма
отчета
Т. Роль
пользователя*
Сотрудник отдела
управления
персоналом
Администратор
Пользователь
Сотрудник отдела
управления персоналом
Т.
Документ-
осование
Т. Документ-
основание*
Рисунок 14. Информационная модель
В результате ввода данных в систему будет доступна отчетная форма табеля
учета рабочего времени сотрудников.
Ввод данных в систему будет осуществляться руководителями структурных
подразделений организации, специалистами отдела управления персонала,
администратором системы и остальными сотрудниками организации.
2.2.2. Характеристика нормативно-справочной, входной и оперативной
информации
Входными документами проектируемой системы являются:
заявления (заявление о предоставлении ежегодного оплачиваемого
отпуска, заявление о предоставлении отпуска без сохранения заработной платы);
больничные листы;
54
приказы (приказ о привлечении работника к сверхурочной работе).
Заявления о предоставлении очередного оплачиваемого отпуска и о
предоставлении отпуска без содержания не являются унифицированными
документами. Заявления содержат следующие данные:
1. ФИО сотрудника;
2. Должность;
3. Даты отсутствия;
4. Причину отсутствия.
Больничный лист является унифицированным документом и содержит
следующие данные:
1. ФИО сотрудника;
2. Название организации;
3. Даты больничного листа.
Приказ о привлечении сотрудников к сверхурочной работе не является
унифицированным документом. В нем содержатся следующие данные:
1. Номер приказа.
2. Дата приказа.
3. ФИО сотрудников.
4. Даты работы.
5. Количество отработанных сверхурочных часов.
Данные входных документов будут храниться в таблице «Документ-
основание». Макет формы ввода данных о документе-основании представлен на
рисунке 15.
На основании информационной модели в системе были выделены следующие
справочники:
1. Сотрудник.
2. Должность.
3. Отдел.
4. График работы.
55
Рисунок 15. Макет формы входного документа
Создадим экранные формы справочников информационной системы. На
рисунке 16 представлена экранная форма справочника «Должность».
Рисунок 16. Экранная форма справочника «Должность»
На рисунке 17 представлена экранная форма справочника «Отдел».
56
Рисунок 17. Экранная форма справочника «Отдел»
На рисунке 18 представлена экранная форма справочника «Сотрудник».
Рисунок 18. Экранная форма справочника «Сотрудник»
На рисунке 19 представлена экранная форма справочника «График работы».
57
Рисунок 19. Экранная форма справочника «График работы»
Характеристика справочников представлена в таблице 9.
Таблица 9
Характеристика справочников
Характеристика
Сотрудник
Отдел
Должность
График
работы
Ответственный за
ведение
Администратор
Объем
справочника в
записях
500
10
30
2
Частота
актуализации
По мере необходимости
Характеристика
Сотрудник
Отдел
Должность
График
работы
Объем
актуализации
5%