78
Каскадная модель хороша в циклах разработки программного
продукта, где используется фиксированное определение продукта и есть
понятные технические методики.
Спиральная модель особое внимание уделяет начальным этапам
разработки – подготовке стратегии, проектированию и анализу, где все
применяемые технические решения проверяются и обосновываются
методом создания прототипов. Каждый виток спирали означает создание
компонента или версии ПО. В них можно уточнять цели и характеристики
проекта, его качество, а также выражаются работы на следующем витке.
Таким образом, углубляются и конкретизируются детали проекта, и в
результате определяется обоснованный вариант, который и реализуется.
Спиральная модель показывает в себе преимущества каскадной
модели. При этом она также имеет риски, умеет или управлять, а также
имеет процессы поддержки и менеджмента. Тут также имеется разработка
ПО при использовании прототипирования или быстрой разработки
программ при помощи языков программирования и средств разработки 4-
го поколения.
Особые свойства спиральной модели – отказ от закрепления
требований и установки приоритетов пользовательским требованиям;
создание последовательных прототипов, начиная с наиболее высшего;
определение и анализ риска на каждом шаге; оценка результата по итогам
каждой итерации и планирование проведения следующей итерации.
Преимуществами спиральной модели можно назвать:
• Быстрая разработка (получение более раннего результата за
счет прототипа);
• Постоянное присутствие заказчика с процессе разработки;
• Разбиение большого проекта на малые части;
• Снижение рисков (более предсказуемое поведение системы).
Для нашего проекта больше всего подойдет каскадная модель для
создания приложения, т.к. она имеет возможность контроля
79
промежуточных значений, а также проект не слишком большой, что может
повлиять на отсутствие ее недостатков.
Затем производится выбор направления внедрения созданной
системы. Сегодня выделяют 4 стратегии внедрения ИС:
• Параллельная стратегия, которая подразумевает замену старой
на новую;
• Скачок – подразумевается резкий переход с одной системы
сразу на другую;
• Опытное использование пилотного проекта – та же тактика
скачка, только к некоторому количеству изделий, при этом очень успешна
на малом участке работы;
• Узкое место – внедрение узкого места план выполняется
только для него самого, и для сотрудников, которые там работают.
В качестве стратегии внедрения ИС в ООО «РУСКОНБЕЛЬТ» был
выбран «Пилотный проект».
Пилотный проект – это первый этап внедрения, позволяющий
убедиться в применимости и эффективности предлагаемой системы до eѐ
окончательного внедрения, обучить сотрудников компании работе с
системой, а также определить и спланировать организационные и
технические мероприятия на этапе промышленного внедрения. Пилотный
проект позволяет уменьшить затраты и ускорить полномасштабное
внедрение.
Данная стратегия внедрения информационной системы была
выбрана, потому что это наиболее часто используемая компаниями
стратегия. Такой подход снижает риск и наиболее надежен.
Таким образом, каскадный метод более всего подходит к конкретной
разработке, следовательно, используем стандарт ISO/IEC 12207.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их
описание
Современные ИС представляют собой комплексные и достаточно
сложные решения, и их реализация, как правило, требует серьезных
80
финансовых вложений со стороны компании. ИТ системы – представляют
собой комплекс технических и программных средств, используемых для
хранения, обработки и анализа данных. Средства анализа, включенные в
ИТ системы, дают возможность быстро обрабатывать огромные массивы
данных и уже в результате предлагать конкретные действия в соответствии
с исходной ситуацией.
Современные ИТ тесто интегрированы в бизнес-процессы компании,
организуя все службы и уровни компании. И любое изменение в такой
структуре так или иначе оказывает влияние на все сферы деятельности
компании. Данное обстоятельство очень затрудняет оценку эффективности
использования ИТ, поскольку порой сложно выделить их влияние на
функциональные процессы, вывести для этого отдельную переменную и
тяжело охватить все направления влияния применяемых ИТ.
Выделим некоторые типичные причины реализации рисков при
проведении ИТ-проектов:
1. Неподготовленность управляющего звена к переменам в
бизнес-процессах предприятия и организационной структуры.
2. Отстраненность руководства главных подразделений и их
непосредственных подчиненных.
3. Изменения в кадровом составе в процессе реализации ИТ-
проекта.
4. Недостаточность квалификации менеджера проекта и других
ответственных исполнителей.
5. Неимение четких и понятных методологических основ такого
процесса.
Основываясь на указанных выше факторах, отслеживание рисков
проектов по внедрению ИТ, аппаратного и программного обеспечения,
методик сохранения данных, сетевых технологий, реализующих
доступность коммуникации и ИС состоит в том, чтобы на начальном этапе
выявить все возможные риски и провести некоторые защитные
81
мероприятия для минимизации последствий серьезных проблем на всем
протяжении реализации проекта.
Успех ИТ-проекта зависит от многих факторов. Но
основополагающих можно выделить три: ресурсы, время и качество.
Главная задача руководителя ИТ-проекта – успеть все реализовать в
заданные сроки с указанным бюджетом и требуемым качеством. Поэтому
основные риски, зачастую характерные для любых ИТ-проектов состоят в
срыве сроков реализации проекта, увеличении стоимости и ухудшении
качества. Но главной причиной реализации этих рисков, особенно в ИТ-
проектах, является физическая неподготовленность компании к
реализации таким проектам.
Говоря о проектах внедрения ИТ важно заметить, что почти все
новые технологии создаются в условиях высокой неопределённости и
негативного окружения. Это объясняется тем, что реализация почти всех
ИТ-проектов, особенно крупных, делается в условиях, когда все другие
стандартные методы управления уже не применить. Уникальность целей
проекта и неимение подобных практик в прошлом порождает некую
неопределенность касательно выбора современных технологий, выражения
методов и средств достижения указанной цели, поддержки той или иной
методологии.
Управление рисками в сегодняшних компаниях становится
тщательно продуманным процессом. Процесс управления рисками
рассматривается не только как отдельно стоящая задача, которая требует
решения, а как часть общей корпоративной системы управления. Целью
контроля рисков, в конечном счете, становится увеличение эффективности
бизнеса за счет работы компании и полноценная отдача от применяемой
методики.
Есть множество методик, содержащих различные варианты и
способы управления проектными рисками. Но поскольку почти каждый
проект внедрения, как правило, не является единообразным в связи со
82
спецификой построения компании, ее структуры и существующими
бизнес-процессами, всегда есть отдельные моменты, не подходящие в
полной мере для исследуемой фирмы. Это означает, что процесс
управления рисками почти всегда связан со спецификой отрасли и
направлением деятельности компании. Очень часто специалисты создают
собственный подход к управлению рисками, являющийся
комбинированным решением нескольких методик и приспособленным к
требованиям организации. Быстрое распространение ИТ требует
пристального внимания и созданию специальных методов контроля
рисков, связанных с реализацией и применением ИТ на предприятии.
Опираясь на различные источники, можно представить 6 базовых
процедур управления рисками, которые адаптируются к специфике ИТ-
проектов:
1. Планирование контроля возможных рисков, т.е. выбор подходов и
описание деятельности по управлению рисками проекта.
Данный процесс включает в себя решения по организации,
кадровому обеспечению методик управления рисками проекта, выбору
наилучшей методологии, источников информации для определения
рисков, правила реализации процедур. Важно грамотно спланировать
управление рисками, чтобы оно соответствовало и неопределенности, и
рискам, так и важности проекта для самой компании.
Исходя из отчета консалтинговой компании Accenture, которая
занимается разработкой проектов в области ИТ, на подготовительной
стадии и планировании создания проекта (первые 10%) реализуется более
90% его полезности. Именно в этот момент учитываются наиболее
болезненные последствия: увеличение сроков, огромный бюджет,
минимальная функциональность. При этом заказчик и консультант могут
рассматривать проблему по-разному, что часто приводит к разным
методам управления рисками, которые закладываются на ранних этапах.
83
Поэтому каждая компания создает собственный план управления рисками,
включающий общие регламенты и приемлемые методики.
2. Выявление рисков, которые могут повлиять на проект, и описание
их характеристик.
Определение рисков ИТ-проекта состоит в подготовке перечня
факторов рисков, которые могут повлиять на выполнения ИТ-проекта в
срок, в границах бюджета и с указанным заранее качеством. Реализация
определения рисков требует понимания процессов ИТ в самой компании,
понимания бизнеса, осуществляемого с помощью ИТ и раздельно,
основных взаимосвязей информационных, управленческих и
производственных процессов внутри фирмы, а также связи с внешним
миром и окружением.
Исходный список рисков создается командой ИТ-проекта или
группой аналитиков рисков. В качестве средств поиска может применятся
обзор документации, предполагающий проведение анализа уже созданных
документов группой управления рисками проекта, сочетает в себе
поэтапный анализ плана проекта и созданных ограничений, как на уровне
проекта в целом, так и на уровне каждой работы, в частности. Могут
применятся методы «мозгового штурма», метод Дельфи, проведение
опросов, SWOT-анализ и пр.
3. Качественная оценка рисков включает в себя анализ рисков и
условий их реализации для выявления их влияния на итог проекта.
Такая оценка реализуется на этапах анализа, планирования и
создания проекта с учетом имеющихся данных по определению рисков.
Примером выбранного критерия и качественной оценки в отдельном ИТ-
проекте становится вероятность поломки любого оборудования, например,
ПК, за некоторый промежуток времени. Примером субъективного
критерия при оценке ИТ риска становится оценка владельца
информационного ресурса процента возможного выхода из строя ПК. Для
этого строится качественная шкала с несколькими градациями.
84
Источниками данных, предназначенных для оценки риска ИТ-
проект, зачастую служат:
• Техническая инфраструктура для выявления технических и
технологических рисков;
• Требования к защищенности данных для выявления рисков для
информации;
• Штатное расписание и организационная структура компании
для определения организационных рисков;
• Карты технологических потоков для выявления технико-
производственных рисков;
• Контракты и договоры для выявления юридических и деловых
рисков и т.д.;
4. Количественная оценка включает в себя некий анализ
вероятности реализации и влияния последствий выполнения рисков на сам
проект.
При качественной оценке реализуется ряд мероприятий для
выявления уровня каждого риска, который может применяться и для
оценки рисков ИТ-проекта. Большое распространение имеет методика
вероятностной оценки риска, вычисляемая при помощи вероятностного
анализа для отдельного риска на базе 2 факторов: степени влияния риска и
вероятности его возникновения.
5. Планирование реакции на риски подразумевает ряд процедур и
методов по уменьшению негативных последствий рисков и применению
возможных преимуществ.
Типичные методы реагирования для ИТ-проекта состоят из
дополнительных методов реагирования на риски ИТ, к примеру:
• Комплексный подход. Важно учитывать тенденции в
собственном бизнесе и указанной области автоматизации, план развития
компании, внедренные системы, привычки и культуру пользователей.
85
• Заинтересованность. Использование в проекте всех тех, кто
станет в итоге пользователями системы. Это даст возможность
минимизировать негативное отношение к проекту и увеличить его
внедряемость.
• Дробление. Разделение проекта на небольшие этапы или на
самостоятельные проекты с отдельными задачами и целями, в
совокупности составляющие проектную программу. Создавать систему
лучше всего поэтапно — от прототипа до полноценной системы, от ядра с
минимальным функционалом до полноценной рабочей версии, то есть
«очередями».
• Выделенность. В проекте нужно иметь подразделения: первое,
отвечающее за качество проекта, второе — за стоимость и сроки работ.
Опираясь на план реагирования на риски ИТ-проекта выбирается
решение о реализации или отказе от противорисковых мер.
6. Отслеживание и контроль рисков – выявление рисков, подсчет
еще не ликвидированных рисков, выполнение плана управления рисками
проекта, и подсчет показателя эффективности решений по уменьшению
рисков.
Реализация мониторинга и контроля рисков влечет за собой выбор
иных стратегий, проведение корректирующих действий, изменение плана
проекта. Изменяется БД по рискам, которая может в будущем применяться
при разработке подобных проектов и в повседневной деятельности
компании. Для лучшей реализации плана управления рисками между
менеджерами проекта и специалистами по управлению рисками
необходимо постоянное взаимодействие.
2.1.3 Организационно-правовые и программно-аппаратные
средства обеспечения информационной безопасности и защиты
информации
Конфиденциальную информацию можно разделить на предметную и
служебную. Служебная информация (например, пароли пользователей) не
86
относится к определенной предметной области, в информационной
системе она играет техническую роль, но ее раскрытие особенно опасно,
поскольку оно чревато получением несанкционированного доступа ко всей
информации, в том числе предметной.
Существует два основных вида обеспечения информационной
безопасности – это защита от внутренних угроз и защита от внешних
угроз.
Защита от внутренних угроз может быть реализована путем
разграничения доступа к компьютерам с помощью стандартных функций
операционной системы. Кроме того, доступ к информационной системе
будет открыт исключительно тем пользователям, которые должны
осуществлять работу с информационной системой.
Защита от внешних угроз реализована в компании благодаря
использованию маршрутизатора. Маршрутизатор позволяет обеспечить
защиту как от вирусного программного обеспечения, так и от
целенаправленных атак злоумышленников.
Для защиты от внутренних угроз в системе используется политика
разделения прав доступа. Характеристика политики приведена в таблице
2.1.
Таблица 2.1
Разграничение прав пользователей
Группы
пользователей
Модуль
«Заявки»
Модуль
«Справочники»
Модуль
«Настрой
ки»
Модуль
«База
данных»
Клиент
Чтение
Нет
Нет
Ограничен
Сотрудник отдела
Ограничен
Ограничен
Ограничен
Ограничен
Администратор
системы
Полный
Полный
Полный
Полный
87
Локальная безопасность обеспечивается осуществлением следующих
мероприятий:
антивирусный контроль;
аппаратная защита от несанкционированного доступа;
криптографическая защита данных;
защита персональным файрволом;
резервирование данных;
протоколирование доступа.
Для обеспечения физической информации файрвол, веб-сервер,
сервера IDS и контроля за трафиком и все сервера данных находится в
отдельном помещении, доступ в которое разрешен только
администраторам, у которых есть ключ или магнитная карта к этой
комнате (комната закрыта). Помещение оборудовано принудительной
вентиляцией и пожарной защитой (полуавтоматической). Вход в офис
компании должен осуществляться только по магнитным картам.
Чтобы войти в сеть компании, сотруднику необходимо знать имя и
пароль. Работа в беспарольном (гостевом) режиме не допускается в
принципе.
Для обеспечения конфиденциальности данных в компании
реализованы принципы организационного и технического разделения
подразделений, которые имеют доступ и работаю с разной информацией.
Подобная задача осуществляется с использованием сетевой ОС, в которой
для обеспечения сохранности данных доступ и все права пользователей
ограничены персональными каталогами. Все права назначаются
относительно производственной необходимости, которая определяется
начальником подразделения.
Данные для входа в сеть, а также личные параметры (логин, пароль)
пользователем не разглашаются. Се копии на бумажных носителях
хранятся в недоступных местах. При попытке взлома пароля пользователь
должен сразу сообщить об этом в IT-отдел для его замены.