62
II Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Жизненный цикл разработки ПО представляет собой методику,
охватывающую все стандарты и процедуры, оказывающие влияние на
планирование, сбор требований и анализ, разработку проекта, конструирование и
внедрение программной системы. Для каждого проекта можно применить
отдельную модель жизненного цикла.
В нашем случае итерационная модель является наиболее правильным
выбором. Разработка системы предполагает возвращения к предыдущим фазам
проектирования системы.
Графическое представление итерационной модели ИС представлено на
рисунке 2.1.
Рисунок 2.1 – Графическое представление итерационной модели ИС
Итерационная модель хорошо зарекомендовала себя при построении
информационных систем, для которых в самом начале разработки можно достаточно
точно и полно сформулировать все требования, с тем, чтобы предоставить
разработчикам свободу реализовать их как можно лучше с технической точки
зрения.
Применение итерационной модели характерно для ситуаций, когда
требования и их реализация максимально чётко определены и понятны.
63
Итерационная модель хорошо функционирует при её применении в циклах
разработки программного продукта, в которых используется неизменяемое
определение продукта и вполне понятные технические методики.
Преимущества итерационной модели.
модель хорошо известна потребителям, не имеющим отношения к
разработке ПО, и конечным пользователям.
она упорядоченно справляется со сложностями и хорошо срабатывает для
тех проектов, которые достаточно понятны.
она весьма доступна для понимания.
она проста и удобна для применения, так как процесс разработки
выполняется поэтапно.
её структурой может руководствоваться даже слабо подготовленный в
техническом плане персонал.
она отличается стабильностью требований.
она хорошо срабатывает тогда, когда требования к качеству доминируют
над требованиями к затратам и графиком выполнения проекта.
она способствует осуществлению строгого контроля менеджмента
проекта.
она облегчает работу менеджеру проекта по составлению плана и
комплектации команды разработчиков.
Итерационная модель хорошо функционирует при её применении в циклах
разработки программного продукта, в котором используется неизменяемое
определение продукта и вполне понятные технические методики.
Выбор модели жизненного цикла разработки программного обеспечения
является важным этапом. Поэтому для проекта выбор модели жизненного цикла
разработки программного обеспечения проводился на основе анализа требований к
проекту, характеристик команды разработчиков и конечных пользователей, а также
типа проекта и рисков. Данные представлены в приложении А.
Подсчитав количество ответов, которые были подчеркнуты, можно составить
таблицу моделей жизненного цикла с проставленными суммарными баллами. По
результатам выбирается та модель жизненного цикла, у которой наибольший
суммарный балл (таблица 2.1).
64
Таблица 2.2
Определение приемлемой модели ЖЦ
Модель ЖЦ
Вес в баллах
Каскадная модель ЖЦ
5
Итерационная модель ЖЦ
14
В данном случае суммарный балл итерационной модели ЖЦ наибольший. Это
означает, что для реализации проекта целесообразно применить итерационную
модель ЖЦ ПО.
Она имеет следующие этапы:
определение требований;
спецификация требований;
проектирование;
реализация;
тестирование и отладка;
эксплуатация и сопровождение.
Цель этапа «Определение требований» - формирование требований к
информационной системе.
«Спецификация требований» - определение технических спецификаций.
Стадия делится на подстадии, задачи: определение функций ИС и стратегии
автоматизации, обоснование проектных решений по техническому, информации и
программного обеспечения. Основная информация - эта документация по
техническому заданию.
Цель этапа «Проектирование» - разработка проекта автоматизации и
разработка задач информационной поддержки. Разработка проекта автоматизации
включает в себя разработку схемы, архитектуры проекта, анализ рисков и оценку
стоимости проекта. Разработка информационной поддержки задачи включает в себя
разработку информационной модели, классификаторов и прототипы экранов.
Эффективная информация - это проектная документация.
Цель этапа «Реализация» - разработка программного обеспечения. Этап
включает в себя подготовку к разработке программного обеспечения и разработку
программного обеспечения. Эффективная информация - это документация
программного обеспечения.
65
Цель этапа «Тестирование и отладка» включает в себя установку элементов
ИС и технической поддержки, а также тестирование и устранение выявленных
ошибок.
Цель этапа «Эксплуатация и обслуживание» - мониторинг и обслуживание
программных и аппаратных средств, а также работа с пользователями.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Современные информационные системы представляют собой достаточно
сложные и комплексные решения, и их внедрение, как правило, требует
значительных инвестиций со стороны предприятия. ИТ системы - это комплекс
программных и технических средств, которые используются для анализа, хранения
и обработки данных. Средства анализа, входящие в ИТ системы, позволяют с
высокой скоростью обрабатывать гигантские массивы данных и на основе
полученных результатов предлагать корректирующие действия в соответствии со
сложившейся ситуацией.
Перечислим несколько типичных причин возникновения рисков при
реализации ИТ-проектов [19]:
Неготовность топ-менеджмента к изменениям в бизнес-процессах
предприятия и организационной структуры.
Незаинтересованность руководителей основных подразделений и их прямых
подчиненных.
Смена в ходе реализации проекта менеджера проекта.
Недостаточная квалификация менеджера проекта и ответственных
исполнителей.
Отсутствие ясных и четких методологических основ этого процесса.
Основываясь на перечисленных факторах, управление рисками проектов по
внедрению информационных технологий (ИТ-проектов) заключается в том, чтобы
заранее выявить все возможные риски и провести комплекс предупреждающих
мероприятий для того, чтобы избежать серьезных проблем во время реализации
проекта.
Проекты в специфических предметных областях, таких как ИТ или проекты,
осуществляемые с применением узкоспециальных технологий, проекты для
вертикальных рынков (таких как здравоохранение, высшее образование,
66
правительственная деятельность, банковские услуги и пр.), а также проекты со
специфическим конечным продуктом могут содержать риски, уникальные для своей
области. Например, в области банковской деятельности существуют риски,
связанные с кражей, потерей или искажением информации в результате
злоумышленного действия или случайного события. При работе над проектами в
таких областях полезно расширить имеющиеся классификации рисков общего
назначения.
Выбор классификации рисков зависит от специфики ИТ-проекта и
профессиональных предпочтений менеджера проекта. В основном риски любого
ИТ-проекта можно классифицировать следующим образом:
Технические риски. Практически в любом ИТ-проекте существуют риски,
связанные с техникой (отказ и сбои в работе оборудования, ошибки в монтаже и т.п.).
Риски оценки сроков. Для большинства ИТ-проектов (особенно в проектах по
разработке и внедрению программного обеспечения) характерны ошибки в оценках
сроков работ проекта.
Интеграционные риски. Интеграционные риски в ИТ-проектах, особенно в
крупных компаниях, всегда высоки, поскольку любое ИТ решение должно быть
интегрировано в существующую инфраструктуру. Наиболее характерны риски
перехода на новую систему, которые включают в себя расходы на остановку
предприятия во время внедрения ИТ решений, обучение персонала и т.д.
Риски не принятия продукта проекта пользователями. Любой проект, в т.ч. в
ИТ сфере - это, в первую очередь, изменение технологии работы. Техническая
составляющая любого проекта, безусловно, важна, но не менее важна
организационная часть.
Коммерческие риски. Это риски, связанные с выбором технологии и
поставщика. Необходимо оценить успешность технологии на рынке, ее актуальность
на протяжении жизненного цикла ИТ-проекта, доступность необходимого
аппаратного и программного обеспечения, его качество, частоту модернизации.
Риски не соблюдения технологии. Эти риски возникают в случае, если
менеджер проекта имеет единоличное решение по рискам (идентификация, анализ,
выбор метода реагирования). Чем больше и сложнее проект, тем выше данный риск.
67
Говоря о проектах внедрения ИТ, нужно отметить, что любые новые
технологии реализуются в условиях большой неопределенности и негативного
воздействия окружающей среды. Это вызвано тем, что осуществление большинства
ИТ-проектов, особенно крупных, происходит в условиях, когда трудно применить
стандартные методы управления. Уникальность целей проекта и отсутствие
подобных практик в компании порождает неопределенность относительно выбора
новых технологий, определения методов и средств достижения поставленной цели,
принятия той или иной методологии.
Управление рисками в современных банковских организациях является
тщательно планируемым процессом. Процесс управления рисками рассматривается
не как отдельно стоящая задача, требующая решения, а как часть изменения общей
корпоративной системы управления. Целью управления рисками, в конечном счете,
является повышение эффективности бизнеса за счет контроля деятельности
компании и максимальная отдача от используемой методики.
Управление рисками ИТ-проектов - это определение, оценка и контроль
эффекта, внутренних и внешних факторов, которые могут негативно повлиять на
стоимость и процесс внедрения новых информационных технологий в компании.
Анализ исследований в области управления рисками ИТ-проектов с учетом
требований современной экономики позволяет нам выделить основные принципы
управления:
Разбивать крупные проекты на более мелкие (принцип «Дельфины вместо
китов»). При этом обязательно должен быть единый человек (как правило директор
программы), который одновременно управляет всеми проектами и добивается не
локальных успехов, а реализацию решения в целом.
Привлекать для управления проектами профессионалов в управлении, а не
узко технических специалистов. Эти специалисты видят проект в первую очередь со
своей технической точки зрения и забывают о единой управленческой
составляющей.
Привлекать независимых (не включенных в проектную команду) экспертов
для оценки рисков. Если все решения по рискам проекта принимают только люди,
которые изначально мотивированы на успех проекта, многие технические и
68
технологические трудности они невольно могут рассматриваться как
несущественные.
Учитывать риски связанные с организационной составляющей проекта. Для
успешной реализации проекта необходимо большое количество согласований и
соблюдения формальностей. Следует детально продумать систему организации и
протоколирования проектных встреч, согласования документов, принятия
результатов, обучение пользователей и т.п.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Создание системы информационной безопасности на предприятии, которое
обрабатывает информацию, так или иначе связано с вопросами
конфиденциальности, которые должны быть приведены в соответствие с
действующим законодательством и соответствовать требованиям норм и правил в
области информационной безопасности.
Среди основных документов по защите информации, в первую очередь,
Конституция Российской Федерации [1]. В ст. 23 устанавливается право на
неприкосновенность частной жизни, личную и семейную тайну, тайну телефонных
переговоров, почтовых и других сообщений. В этом случае ограничение этого права
допускается только на основании судебного решения. Конституция Российской
Федерации не допускается сбор, хранение, использование и распространение
информации о частной жизни лица без его согласия.
27 июля 2006 Президент России подписал два важных для сферы управления
делопроизводством федеральных закона: № 149 - ФЗ «Об информации,
информационных технологиях и о защите информации» и № 152 - ФЗ «О
персональных данных».
10 января 2002 года Президент подписал закон «Об электронной цифровой
подписи», разрабатывающий и детализирующий положения указанного выше
закона № 149.
Основные законы Российской Федерации, также «О государственной тайне»
от 22 июля 2004; «О коммерческой тайне» от 29 июля 2004 года (он содержит
информацию, которая является коммерческой тайной, коммерческую тайну,
разглашение сведений, составляющих коммерческую тайну); «Об утверждении
69
перечня сведений, которые не могут быть коммерческой тайной», «Об утверждении
перечня конфиденциальной информации», «Об утверждении перечня сведений,
составляющих государственную тайну». Ряд подзаконных нормативных актов
регулируют организацию защиты государственной тайны, ведение секретного
делопроизводства, порядок допуска к государственной тайне должностных лиц и
граждан Российской Федерации: «Об утверждении Положения о лицензировании
деятельности по технической защите конфиденциальной информации» и т. д.
Ряд вопросов, связанных с защитой конфиденциальной информации,
регулируется Уголовно-процессуального кодексом, он содержит положения,
касающиеся тайны переписки, телефонных и иных переговоров, почтовых,
телефонных и иных сообщений.
Нормы, регулирующие отношения, возникающие при работе с
конфиденциальной информацией, также содержатся в Гражданском кодексе.
Критерии, по которым информация является конфиденциальной и коммерческой
тайной, содержатся в ст.139 Гражданского кодекса. В нем говорится, что
информация является служебной или коммерческой тайной в случае, когда:
˗ Эта информация имеет действительную или потенциальную ценность в силу
неизвестности ее третьим лицам.
˗ Эта информация не является свободно доступной на законном основании и
обладатель принимает меры по охране ее конфиденциальности.
Кроме того, определение коммерческой тайны, содержащиеся в ст.727
Гражданского кодекса.
Уголовный кодекс содержит ряд положений, касающихся защиты
информации с ограниченным доступом и ответственности за ее неправильное
использование.
Особый вид ответственности установлен за нарушение коммерческой тайны:
лишение соответствующей сертификации, лицензии уполномоченным органом. Но
привлечение к этому типу ответственности, как правило, не получило к настоящему
времени широкого распространения [9].
Правовые нормы, регулирующие использование конфиденциальной
информации в судебных процессах - Эти нормы, в частности, установить в
Гражданско-процессуального кодекса Российской Федерации.
70
Основные требования к обращению с конфиденциальной информацией в
государственных и коммерческих структурах также содержатся в Федеральном
законе «О противодействии легализации (отмыванию) доходов, полученных
преступным путем, и финансированию терроризма».
Законодательные акты не в полной мере регулируют порядок учета, хранения
и использования документов, содержащих конфиденциальную информацию. Тем не
менее, некоторые законы содержат определенные положения, которые определяют
общие принципы учета, хранения и использования документов, содержащих
конфиденциальную информацию [12].
Таким образом, весь комплекс вопросов, которые возникают при решении
организационно-правовой поддержки, может быть представлен в виде схемы,
показанной на рисунке 2.2.
Обеспечение организационно-правовой защиты информации
Организационная и
правовая основа
Техническая и
математическая сторона
Юридическая сторона
Подразделения и лица,
которые ответственны
за защиту
Фиксирование подписей
под документами
Законные правила
защиты информации
Нормативно-правовые,
руководящие и
методические документы
Фиксирование факта
ознакомления с
информацией
Законные меры
ответственности за
нарушения
Меры ответственности за
нарушения
Фиксирование факта
изменения информации
Законные технико-
математические
решения
Порядок разрешения
спорных ситуаций
Фиксирование факта
копирования
информации
Законные
процессуальные
процедуры
Рисунок 2.2 – Обеспечение организационно-правовой защиты информации
Ниже приведены требования к реализации этапов защиты.
Идентификация/аутентификация пользователей
71
ИА должна выполняться аппаратно до этапа загрузки ОС. Базы данных ИА
должны храниться в энергонезависимой памяти СЗИ, организованной так, чтобы
доступ к ней средствами ПЭВМ был невозможен. Программное обеспечение
контроллера должно храниться в памяти контроллера, защищенной от
несанкционированных модификаций. Целостность ПО контроллера СЗИ должна
обеспечиваться технологией его изготовления.
Идентификация должна осуществляться с применением отчуждаемого
носителя информации.
Стойкость системы защиты связана с длиной пароля. При этом длина пароля
может привести к трудностям при его запоминании. Для преодоления этих
трудностей рекомендуется использовать фразы, облегчающие запоминание пароля.
Для генерации пароля следует применять аппаратный датчик случайных
чисел.
Разграничение прав доступа к информации разрабатываемой системы
(таблица 2.2).
Таблица 2.3
Разграничение прав доступа в ООО «АРСЕНАЛЪ»
Группы
пользователе
й
Модуль
Программные
, информа-
ционные и
технические
средства
предприятия
Модуль
«Информация о
пользовате-лях
ИС
предприятия»
Модуль «База
нарушений
конфиденциаль
ности, целос-
тности или
доступности
ИС
предприятия»
Требовани
я к
паролям
Требовани
я к частоте
смены
пароля
Руководство
компании
Чтение
Чтение/удалени
е
Чтение
Не менее 6
символов
Один раз в
месяц
Сист.админ
Полный
Чтение/созда-
ние/удаление
Чтение/созда-
ние/удаление
Не менее 8
символов
Один раз в
2 недели
Инженер
отдела ИТ
Полный
Чтение/создани
е/удаление
Чтение/создан
ие/удаление
Не менее
8-и
символов
Один раз в
2 недели
Оператор баз
данных
Чтение
Чтение/редакти
рование
Чтение
Не менее
6-и
символов
Один раз в
месяц
Сотрудники
Чтение
Чтение
Чтение
Нет
Нет
Контроль целостности технического состава ПЭВМ должен выполняться
контроллером СЗИ до загрузки ОС. При этом должны контролироваться: