57
технологий и, конечно, самих ИС. Следовательно, всё вышесказанное можно
отнести и к ИС.
ИС включены в состав СУБД и являются узконаправленным
инструментальным и прикладным (пользовательским) ПО. Модель
жизненного цикла ПО отражает структуру, определяющую
последовательность реализации и взаимосвязь процессов, действий и задач в
рамках всего ЖЦ. Модель ЖЦ зависит от специфики, масштаба и трудности
проекта и конкретных условий, в которых система развивается и работает.
Сегодня наибольшее распространение получили три базовые модели ЖЦ:
Итерационная модель (70-80 г.г.);
Каскадная модель (70-85 г.г.);
Спиральная модель (сегодняшние дни).
ЖЦ информационной системы обычно представляет собой набор
этапов, работ и операций в порядке их реализации и взаимосвязях,
определяющих ведение работ от составления технического задания до
финальных испытаний ряда версий и завершения эксплуатации ПС или ИС.
Подобные стандарты состоят из правил описания начальной
информации, методики выполнения операций, осуществляют контроль
технологических процессов и правил представления их результатов. Еще они
определяют содержание технологических и эксплуатационных документов на
комплексы ПО. Они выражают организационную структуру коллектива,
поддерживают распределение и планирование заданий, реализуют контроль
над этапами разработки комплекса ПС.
Для составления жизненных циклов (ЖЦ) ИС был выбран стандарт ISO
12207, как стандарт, включающий в себя большинство автоматизированных
систем (АС) и ПС, где ПС – малая часть всего плана работ. Международный
стандарт ISO/IEC 12207 показывает стратегию и общий порядок в разработке
и использовании ПО, он охватывает ЖЦ ПО от зарождения идей до окончания
цикла.
58
Определение стандарта: система — это совокупность одного или более
процессов, аппаратных средств, ПО, оборудования и людей для реализации
возможности удовлетворения конкретных потребностей или целей. В отличие
от Oracle CDM стандарт ISO 12207 одинаково нацелен на организацию
действий каждой из двух сторон: поставщик (создатель) и покупатель
(клиент). Применяется в разных случаях, даже когда обе стороны внутри
одной компании.
В отличии от CDM, стандарт ISO состоит из более крупных обобщенных
процессов: «покупка», «доставка», «создание» и т.п. Любой процесс разделен
на набор действий, а каждое действие — на совокупность задач. Важно одно
отличие ISO: любой процесс, действие или задача определяется и реализуется
другим процессом по мере необходимости, причем нет ранее заданных
последовательностей (конечно, в рамках сохранения логики связей по
начальным сведениям задач и т.п.).
Развивающийся характер стандарта зависит от способа выражения
последовательности выполнения процессов и задач, когда один процесс в
случае необходимости вызывает другой или его часть. Стандарт отражает
архитектуру, процессы, разделы и подразделы ЖЦ ПС, а также указывает
список необходимых работ и подробно описывает содержание каждой из них.
Архитектура ЖЦ ПС в стандарте основывается на 3 основных
компонентах:
1. Покупка или поставка,
2. Создание,
3. Использование.
Стандарт не включает конкретные методы действий, а также заготовки
решений или документации. Он отражает архитектуру процессов ЖЦ ПО, но
не углубляется в детали реализации или выполнения услуги и задачи,
включенных в процессы. Стандарт не указывает конкретную модель ЖЦ или
метод создания ПО, но показывает, что стороны участники использования
стандарта несут ответственность за выбор модели ЖЦ для проекта ПО, за
59
подгонку процессов и задач стандарта к этой модели, за обоснованный выбор
и использование методов создания ПО, за реализацию действий и задач,
уместных для проекта ПО.
Покупка или поставка. Цель этапа – предложение разработчику от
заказчика, на выполнение автоматизированной системы. На этом этапе
заключается договор, корректируются его условия и требования. Участники
этапа – ответственный от лица заказчика, который контролирует и уточняет
направления для разработчиков. А так же менеджер проекта от лица
разработчиков. Он принимает от заказчика требования, подписывает договор,
и согласует начальные установки и задачи для работы. На этом этапе заказчик
должен предоставить развернутое техническое задание (ТЗ), менеджер
утверждает его, уточняются некоторые детали задания и согласовываются
средние сроки выполнения разработки. Создание.
Создание ПО разбито на множество небольших этапов, призванных
обеспечить создание ИС, отвечающей требованиям заказчика, и в
договоренные сроки:
Исследование требований к системе;
Построение системной архитектуры;
Исследование требований к ПС;
Построение архитектуры ПС;
Детальное проектирование ПС;
Реализация и тестирование ПС;
Внедрение ПС;
Квалификационная проверка системы;
Начало эксплуатации ПС;
Финальная приемка ПС.
Основные участники на этом этапе – это менеджер проектов и
непосредственные разработчики. Сам менеджер разбивает задачу разработки
ПС на вышеперечисленные этапы, следит за их выполнением, контролирует
60
ход выполнения за каждым разработчиком. При необходимости сам участвует
в разработке или координации действий между отдельными разработчиками.
Определяет участки работы для каждого отдельного разработчика в
зависимости от квалификации и опыта, определяет степень универсальности
взаимодействия отдельных частей ПС, разрешает коллизии и спорные
моменты. Разработчики принимают план работ, поле деятельности и
конкретные задачи для выполнения. Определяют для себя методы решения
своих задач, согласовывают пути взаимодействия с программными частями
других разработчиков, спецификации функций, протоколов передачи данных,
и др.
Использование. На этом этапе проводятся тестовые испытания ПС,
определяются сильные и слабые моменты, недоработки, и слаженность работы
всех компонентов. При выявлении недоработок определяются перечень
указаний для исправлений разработчиками.
Существуют следующие основные стратегии внедрения системы:
1) Стратегия “Параллельное использование”. Параллельное
использование - параллельно выполняются старая и новая технология
решения задачи, их результаты сравниваются. Если результаты согласуются
длительное время, то осуществляется переход на новую технологию.
Плюсы:
- минимальный риск ошибок в виде новых технологий;
- управления внедрения ИС может осуществлять независимо от
обычного операционного планирования компании.
Минусы: - двойная загрузка персонала; - потребности в удвоенных
мощностях серверов; - необходимость постоянной сверки результатов работы
2х технологий.
2) Стратегия “Пилотный проект”.
Пилотный проект - тактика скачка применяема к ограниченному числу
процессов, областью применения обычно является небольшой участок.
Плюсы:
61
- минимальный риск выбора неверного решения, которое не приводит к
длительному простою всего предприятия;
- возможность изменения планируемой технологии в процессе
внедрения ИС на участке;
- отсутствие 2х затрат на реализацию технологии.
Минусы:
- сложность интеграции информационных потоков формируемых по
старой и новой технологии;
- необходимость управления старой и новой ИС одновременно.
3) Стратегия “Узкое место”. Узкое место - автоматизация малой части
производственного процесса, который обычно выбирается по критериям, их
эффективности приводящих к повышению качества реализации процессов
только в определенном узком месте.
Плюсы:
- после автоматизации каждого узкого места имеется возможность
прервать автоматизацию;
- минимальные требования к уровню планирования работ внедрения.
Минусы:
- выполнение полного цикла планирования на каждом из узких мест -
ввиду возможности прерывания автоматизации процесс может, не закончится
некогда;
- независимость автоматизации узких мест может привести к
формированию избыточного множества программно аппаратных решений.
Таким образом, в условиях ограниченного бюджета и начальной стадии
автоматизации логичным будет выбрать стратегию внедрения «Узкое место».
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
62
На этапах ЖЦ задачи разработки ИС управления персоналом могут
возникнуть риски.
Для начала рассмотрим понятие "риск". Стандарты Practice Standard for
Project Risk Management и PMBOK дают следующее определение: риск – это
неопределенное событие или условие, наступление которого отрицательно
или положительно сказывается на целях проекта
20
.
Существует понятие «Информационный риск». Базовая терминология
теории управления информационными рисками на сегодняшний день
сформирована в системе международных стандартов ISO/IEC 27000, которые
гармонизированы в Российской Федерации в серии ГОСТ Р ИСО/МЭК 27000
[1–4]. Информационный риск – это возможное событие, в результате которого
несанкционированно удаляется, искажается информация, нарушается ее
конфиденциальность или доступность
21
. Следовательно, понятие
информационного риска используется как синоним понятия угроза
безопасности информации.
Основная цель управления риска – уменьшения вероятности появления
нежелательных событий и снижение области действий, продолжительности,
т.е. степени их отрицательного влияния. Управление риском иногда называют
предотвращение риска. Обычно эта деятельность при разработках ИС и
программных пакетов включает определенную последовательность этапов –
идентификация рисков и их категории и источников их возникновения.
Оценка риска – это основной процесс в методологии управления
рисками. Организации используют оценку риска с целью определения степени
потенциальной угрозы и риски, связанные с ИТ-системой на всем протяжении
ее жизненного цикла.
В оценке рисков для ИТ-системы первым шагом является определение
области деятельности. На этом этапе границы его системы идентифицируются
20
Шайдуллина Э.Н., Смоленцева Л.В. Управление рисками информационного проекта // Вест- ник
современных исследований. - 2017. - С. 206-209.
21
Смоленцева Л.В. Анализ подходов к созданию информационных систем для экономистов // Экономика и
социум. - 2014. - №4-6 (13). - С. 69-74.
63
вместе с ресурсами и информацией, которая составляет систему.
Характеризуется система, которая определяет область оценки рисков,
очерчивает оперативные санкции (или аккредитации), границы и обеспечивает
информацию (например, об оборудовании, программном обеспечении,
подключении к системе), необходимую для определения риска.
Целью второго этапа является выявление потенциальных источников
угроз и формирование классов угроз для данной информационной системы.
Выявление уязвимостей должно включать в себя анализ уязвимости,
связанных с системой среды. Целью данного шага является разработка
перечня уязвимостей системы (недостатки или слабые стороны), которые
могут стать жертвой потенциальной угрозы.
Типы рисков:
Проектный тип рисков. В него включены риски, которые связаны с
ошибками в бюджете; в графике работ; с проблемами персонала организации;
риски различных изменений в текущем законодательстве.
Технический тип рисков. К нему относят риски, связанные с проблемами
реализации технических решений и человеческим фактором, а именно риски,
связанные с неспособностью специалистов выполнить необходимую задачу.
Тип бизнес-рисков. Он содержит в себе риски, которые связаны с
финансовой поддержкой задачи учета, или, другими словами, риски
сокращения бюджета, приводящие не только к сокращению проекта и его
задач, но и к его полному провалу в случае не достижения основной цели; риск
потери интереса к задаче ведения и учета внутренних заказов оборудования со
стороны конечных пользователей, риски при оценке рынка данного вида
учета. Данный тип рисков невозможно исключить, но его можно
минимизировать
22
.
22
Смоленцева Л.В., Трутнева Л.А. Анализ рисков при внедрении информационных систем // Аллея науки. -
2017. - №16 (том 1) (Декабрь). - С.947-952.
64
Рисунок 15. Методология оценки риска
Чтобы уменьшить величину данных типов рисков необходимо иметь
достаточно компетентных и квалифицированных сотрудников, имеющих
большой опыт работы в соответствующей области.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Меры по защите информации:
1. защита информации от внутренних угроз;
2. защита информации от внешних угроз.
65
Для защиты от внутренних угроз в системе используется политика
разделения прав доступа. Характеристика политики приведена в таблице 5.
Таблица 5
Разграничение прав пользователей
Группы
пользователей
Модуль
«Авторизация»
Модуль
«Регистрация»
Модуль
«Справочники»
Модуль
«Отчеты»
Сотрудники
предприятия
Чтение
Нет
Чтение
Ограничен
Менеджеры
Чтение
Полный
Чтение
Полный
Системный
администратор
Полный
Полный
Полный
Полный
Защита от внешних угроз осуществляется путем применения
следующих способов:
- использованием программно-аппаратных комплексов (КСЗИ
«Панцирь-К»);
- разработкой и соблюдение политик безопасности;
- использованием защищенных каналов связи при передаче
информации;
- использованием антивирусных средств (Антивирус Касперского);
- физической защитой помещений с наиболее ценной информацией
(СКУД «Elsys»).
КСЗИ «Панцирь-К» собственными средствами реализует все
технические требования, регламентируемые для АС класса защищенности 1Г.
Для шифрования данных в КСЗИ реализована возможность подключения
криптопровайдеров «Signal-COM CSP» (ЗАО «Сигнал КОМ») и «КриптоПро
CSP 3.0» (ООО «Крипто-Про»), сертифицированных ФСБ России по
требованиям безопасности информации к классам «КС1» и «КC2».
КСЗИ может применяться для защиты, как от внешних, так и от
внутренних ИТ-угроз, обеспечивая эффективное противодействия атакам и со
стороны хакеров, и со стороны инсайдеров (санкционированных
66
пользователей, допущенных к обработке информации на защищаемом
вычислительном средстве).
КСЗИ также может использоваться для эффективного противодействия
вирусным атакам и шпионским программам.
СКУД «Elsys» состоит из следующих элементов: Линейное
оборудование, включающее в себя контроллеры СКУД «Elsys-MBSM»,
работающие в автономном режиме. Переход УУ в автономный режим работы
осуществляется после программирования мастер-карты. В автономном
режиме при анализе полномочий пользователя не учитываются временные
расписания. Пользователям может быть назначен один из трёх уровней
доступа, в состав которых входят соответственно первый, второй, или оба
считывателя.
При работе в автономном режиме могут быть использованы настройки
УУ по умолчанию, перечисленные ниже:
две двери с односторонним контролем доступа (включив
последовательно контакты двух реле, можно управлять электромагнитным
замком двусторонней точки доступа);
два считывателя, совмещённых с клавиатурой;
время включения замков двери - 10 с;
задержка включения замков двери - 0 с;
время, отводимое на проход - 10 с;
режим автозакрывания включен;
- интерфейс считывателей - Wiegand (при программировании
мастер-карты возможно задание режима Touch Memory).
Эти настройки могут быть скорректированы с помощью программного
обеспечения "Бастион".
2.2 Информационное обеспечение задачи