67
управление и т.п.), включая их сочетания, создаваемые в организациях.
Стандарт устанавливает стадии и этапы создания автоматизированной системы.
ISO 12207 – стандарт применяется при приобретении систем, программных
продуктов и оказании соответствующих услуг (внедрение, сопровождение). А
также при поставке, разработке, эксплуатации и сопровождении программных
продуктов и программных компонентов программно-аппаратных средств как в
самой организации, так и вне нее.
ISO 15288 – стандарт обеспечивает общие основы процессов, составляющих
жизненной цикл систем, созданных человеком. Этот жизненный цикл
охватывает концепции идей вплоть до снятия системы с эксплуатации. Он
обеспечивает процессы для приобретения и поставки системы.
RUP (Rational Unified Process – рациональный унифицированный процесс) – это
методология разработки программного обеспечения, созданная и
распространяемая корпорацией Rational Software (www.rational.com). Она
описывает упорядоченный подход к распределению задач и обязанностей в
организации-разработчике.
XP (eXtreme Programming) – методология содержит совершенно иные базовые
принципы, нежели RUP. Основными чертами являются определение точных
кратковременных планов (как правило, недельных), постоянное
перепланирование, тесное общение с заказчиком. Эта методология больше
подходит для полуисследовательских и инновационных проектов.
MSF (Microsoft Solutions Framework – методология создания программных
решений) – В модели процессов приводится общее описание организации работ
над проектом по разработке и внедрению ИТ-решений. Предлагаемая схема
достаточно гибка и может применяться к самым разным проектам в области
информационных технологий. В версии 3.1 концепция была расширена и теперь
охватывает практически весь цикл создания решений – начиная с их обсуждения
и заканчивая внедрением.
COBIT (Control Objectives for Information and Related Technology – цели контроля
для информационных и смежных технологий) – основная идея стандарта COBIT
выражается следующим образом: все ресурсы информационной системы
68
должны управляться набором естественно сгруппированных процессов для
обеспечения компании необходимой и надежной информацией.
Oracle CDM (Custom Development Method – методика разработки ИС под заказ)
– позволяет стандартизировать процесс создания приложений. CDM охватывает
полный жизненный цикл разработки приложений, описывая
последовательность и взаимную зависимость задач, решаемых в процессе
разработки.
В компании было принято решение использовать методологию разработки и
внедрения IT-решений – Microsoft Solution Framework (MSF). Это решение было
принято в связи с тем, что компания уже некоторое время работает с продукцией
корпорации Microsoft, работает с ее продукцией и использует ее технологии. Рабочие
станции компании и сервер работают под управлением операционных систем,
разработанных корпорацией Microsoft. Компания поставляет заказчикам рабочие
станции, и сервера устанавливая на них программное обеспечение данной корпорации.
Особенность этой модели состоит в том, что благодаря своей гибкости
и отсутствию жестко навязываемых процедур она может быть применена при
разработке весьма широкого круга IT-проектов. Эта модель сочетает в себе свойства
двух стандартных производственных моделей: каскадной и спиральной. Она
покрывает весь жизненный цикл создания решения, начиная с его отправной точки и
заканчивая непосредственно внедрением. Процесс MSF ориентирован на «вехи» –
ключевые точки проекта, характеризующие достижение в его рамках какого-либо
существенного (промежуточного либо конечного) результата. Этот результат может
быть оценен и проанализирован, что подразумевает ответы на вопросы: «Пришла ли
проектная группа к однозначному пониманию целей и рамок проекта?», «В
достаточной ли степени готов план действий?», «Соответствует ли продукт
утвержденной спецификации?», «Удовлетворяет ли решение нужды заказчика?» и т. д.
Модель процессов MSF учитывает частые изменения проектных требований.
Она основывается на том, что создание решения включает в себя короткие циклы,
создающие поступательные движения от простейших версий решения к его итоговому
виду. В модели MSF есть 5 фаз ЖЦ: создание концепции, построение плана,
разработка, тестирование, внедрение. Этап создания концепции состоит из заложения
одной из фундаментальных основ успеха проекта – сбор и сплочение проектной
69
группы на базе выработки единого видения. Проектная группа должна четко понимать,
что она хочет сделать для заказчика и выразить цель таким образом, чтобы 100%
мотивировать и заказчика, и проектную команду. В таком случае в роли заказчика
выступает сам разработчик. Создание высокоуровневого взгляда на цели и варианты
проекта расценивается как ранняя стадия планирования. Она готовит почву для
процессов разработки детальных планов, которые осуществятся непосредственно во
время фазы планирования. Главными задачами этапа создания концепции становится
сборка ядра проектной группы и подготовка документа с описанием рамок проекта и
общими требованиями. Составление видения проекта и специфицирование его рамок
не является одним и тем же, хотя для успеха проекта важны оба компонента. Видение
– это неограниченное представление о том, каким хотелось бы видеть решение. Рамки
же задают понятные границы того, что из предложенного этим видением будет
возможно реализовать в условиях уже созданных проектных ограничений. За время
проведения этапа подготовки концепции реализуется определение и анализ бизнес
требований. Подробнее эти требования уже анализируются во время этапа
планирования. Веха «Концепция утверждена» – в ней проектная группа составляет
соглашение об общих задачах проекта, доступных в решении функциональности и
конкретных временных рамках. Итоги:
Базовое описание и рамки проекта;
Составление структуры проекта.
Этап планирования включает в себя основную работу по составлению планов
проекта. Он подразумевает составление проектной группой функциональной
спецификации, создание дизайнов, доработку рабочих планов, оценку затрат на проект
и срока доработки разных составляющих проекта. В начале этапа планирования
проектная группа изучает и документирует проектные требования. Они делятся на 4
общих категории: бизнес-требования, потребительские требования, требования по
использованию и системные требования, касающиеся решения в целом.
В рамках проектирования решения и разработки его функциональной
спецификации важно следить за соответствием между указанными требованиями и
проектируемой функциональностью. Это соответствие не так важно и будет взаимно-
однозначным. Оно является одним из способов отслеживания корректности дизайна и
его полноты для достижения поставленных перед решением целей. Процесс
70
проектирования можно назвать систематическим способом продвижения от
абстрактных задач к конкретным техническим деталям. Он начинается с методичного
анализа профилей пользователей, описывающих различные типы пользователей
(включая персонал сопровождения) и их должностные обязанности. Значительная
часть этой работы реализуется во время фазы подготовки концепции. Затем
составляется набор сценариев применения, в каждом из которых прогоняется
выполнение какой-либо операции конкретным типом пользователя. В итоге каждый
сценарий использования разделяется на последовательность специфических действий,
называемых примерами использования, необходимыми для выполнения
пользователем с целью реализации операции. Есть 3 уровня процесса проектирования:
логический дизайн, концептуальный дизайн и физический дизайн. Работа над
логическим дизайном начинается через определенный промежуток времени после
начала работы над концептуальным дизайном, а создание физического дизайна
начинается через некоторый промежуток времени после начала работы над
логическим. Результаты процесса проектирования описываются в функциональной
спецификации. Функциональные спецификации представляют вид и поведение
каждой компоненты решения. Также для всех составляющих имеется их архитектура
и дизайн. Функциональная спецификация используется для множества целей. Главные
из них:
Команды разработчикам о том, что они должны будут реализовать;
База для оценки объема работы;
Полноценное соглашение с заказчиком о том, что нужно делать;
Оптимизация деятельности всей проектной команды.
Как только разработана базовая версия функциональной спецификации,
начинается детальное планирование. Руководитель проектной группы готовит план и
участвует в командных сессиях планирования.
Примеры планов состоят из плана внедрения, плана тестирования, плана
использования, плана мер безопасности, плана обучения.
Далее проектная группа совместно оценивает планы и находит
взаимозависимости между ними. Все планы синхронизируются и выражаются в виде
сводного плана проекта. Члены проектной группы, входящие в разные ролевые
кластеры, подсчитывают нужное для выполнения запланированных задач время и
71
готовят календарный график сдачи результатов. Далее идет синхронизация
календарных графиков с последующим их внедрением в сводный календарный график
проекта.
Веха «Планы проекта утверждены» отражает соглашение между проектной
группой. Промежуточные вехи этапа планирования успешно пройдены,
подготовленные календарные графики реалистичны, все роли распределены и
ответственности в команде указаны должным образом. Функциональные
спецификации, сводный план и сводный календарный график проекта становятся
основой для принятия альтернативных решений в будущем. Утвержденные планы,
таблицы, графики и т. д. составляют начальную версию проекта. Она состоит из всех
соглашений, принятых на основе общего мнения с учетом 3 плановых показателей
проекта: ресурсы, время и функциональность решения. После создания и утверждения
базовой версии проекта, проектная группа начинает ее разрабатывать. Изменения в
исходной базовой версии проекта строго отслеживаются. Это не означает, что все
принятые во время этапа планирования решения неизменны – в ходе этапа разработки
проектная группа должна изучить и формально утвердить или опровергнуть все
предлагаемые корректировки базовой версии. Итоги:
Описание функционала;
График и план выполнения проекта.
Этап разработки включает в себя создание проектной группой компонент
решения (документацию и программный код). Но часть этой работы может
продолжаться также на этапе тестирования, если такая необходимость имеется.
Данный этап также включает в себя создание инфраструктуры. Активность проектной
команды на этом этапе не ограничена составлением кода – все ролевые кластеры
участвуют в разработке и тестировании решения. Веха «Разработка завершена»
становится итогом всего этапа разработки. К моменту ее наступления разработка всех
компонентов завершена, и решение готово к тестированию и стабилизации. Компания
может оценить решение и определить все оставшиеся проблемы и нерешенные
вопросы, которые важно уладить до выпуска решения. Итоги:
Готовый исходный код приложений;
Скрипты конфигурации и инсталляции;
Окончательная доработка функционала;
72
Обоснование решения;
Сценарии и описание тестов.
Этап тестирования подразумевает проведение проверки разработанного
решения. При этом внимание приковано к его работе в реалистичной модели
производственной среды. Проектная группа занята нахождением и устранением
ошибок, а также подготовкой решения к выпуску. После того, как появляется версия,
достаточно стабильная для того, чтобы быть кандидатом для выпуска, производится
первоначальное внедрение решения. Этап тестирования завершается вехой
«Готовность решения утверждена». В состоянии, которые имеется к данному моменту,
решение может полноценно внедряться в производственную среду. Также к моменту
наступления этой вехи проектная группа заканчивает разрешение всех существенных
проблем и реализует внедрение решения. Ответственность за постоянное управление
и поддержку решения теперь лежит на команде сопровождения. Итоги:
Готовый продукт;
Готовая документация;
Обоснование решения;
Итоги всех тестов;
Код работающего приложения;
Проектная документация;
Результаты пройденного этапа.
Этап внедрения включает в себя внедрение решения проектной группой,
тестирование внедренного решения, передачу работы персоналу поддержки и
сопровождения. По итогам внедрения проектная группа анализирует итоги работы и
удовлетворенность заказчика. В момент этого этапа по ходу переноса компонент
решения из среды тестирования в производственную среду также идут работы по
тестированию всего комплекса. Веха «Внедрение завершено» является окончанием
этапа внедрения. К этому времени решение уже дает заказчику некоторую бизнес-
отдачу, а проектная группа заканчивает свою деятельность. Решение разрабатывается
стабильным и четко удовлетворяющим выработанным критериям успешности.
Стабильность решения показывает также готовность систем его использования и
обслуживания. Итоги:
ИС эксплуатации и поддержки;
73
Процессы и процедуры;
Журналы протоколов, базы знаний и отчеты;
Версии проектных документов, массивы информации и программный код,
созданный во время проекта;
Отчет об окончании проекта;
Итоговые версии всех проектных документов;
Уровень удовлетворенности заказчика и потребителей;
Описание других шагов.
В процессе использования персонал компании должен четко следовать всем
инструкциям, которые относятся к созданной ИС. В случае проблем или вопросов,
персонал обращается в службу поддержки. Эта служба проанализирует конкретную
ситуацию, и примет меры для возобновления работы.
Ожидаемые риски на этапах жизненного цикла и их описание
В процессе ЖЦ создаваемой ИС не избежать разного рода рисков.
Выделим главные риски, характерные для каждого этапа ЖЦ нашей ИС и
обозначим меры их минимизации.
Этап подготовки концепции – есть риск сознания концепции, которую в
дальнейшем будет почти невозможно реализовать. В подготовке концепции должны
быть описаны главные функции разрабатываемой ИС. Главное выделить основу, и в
дальнейшем развивать разработанную систему. Для предотвращения реализации
рисков на этапе подготовки концепции, важно четко понимать свои возможности. Для
предотвращения переоценки собственных сил изначально нужно создать общую
концепцию, в которой уже будут заложены только базовые функции системы. И по
мере углубления в эту разработку можно увеличивать дополнительные функции. Этап
планирования имеет риск неверного планирования, создание очень оптимистичных
планов проекта, где компания не сможет уложиться, вследствие чего придется
увеличивать время разработки, что может привести к удорожанию проекта в целом. К
этапу планирования нужно отнестись очень важно, отслеживать каждый шаг и
анализировать реалистичность результатов. Для минимизации риска на этапе
планирования нужно во время планирования заложить в график поправки на
74
некоторые задержки в выполнении тех или иных действий. Так нужно постараться
создать гибкий график, который бы не корректировался из-за задержки или
опережения. Этап разработки содержит риск того, что разработка некоторого модуля
будет связана с большими трудностями, а отдельная функция будет мешать
продвижению разработки. На данном этапе нужно вовремя выявить проблемный
модуль или функцию и по возможности упростить ее, заменить другой или удалить
полностью из проекта. Чтобы предотвратить риск разработки сложного модуля,
принимается несколько решений: либо разбивать данный модуль на несколько и
решать указанные задачи по отдельности, либо упрощать сложный модуль, если это
является единственным вариантом преодоления риска. Этап тестирования имеет риск
выявления большого количества ошибок в программном коде, что повлечёт большие
затраты на доработку и устранение всех выявленных ошибок. Нельзя предсказать,
какой количество ошибок будет найдено и как много времени будет нужно на их
устранение.
Для минимизации рисков на этапе тестирования необходимо данному этапу
отвести максимально возможное время, выделенное на создание системы, поскольку в
зависимости от того, как качественно будет реализован продукт, зависит, примет ли
заказчик данную разработку или нет. Этап внедрения может быть очень длительным,
если заказчик каким-то образом будет не доволен созданным продуктом, а также сам
персонал автоматизируемой компании может отрицательно относиться к внедрению
нового ПО. Для минимизации рисков на данном этапе важно произвести качественное
обучение персонала еще до начала внедрения, подготовить службу сопровождения и
поддержки, понять, какие проблемы имеют место быть в процессе внедрения и быть
готовым к их решению. Постоянно отвечать на вопросы персонала по поводу
возникающих у него проблем, открыть горячую линию для решения возможных
проблем.
Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
В данном пункте дипломного проекта рассматривается вопрос обеспечения
безопасности разработанного приложения. Обеспечение безопасности можно
75
разделить на две составляющих – защита от внутренних угроз, к которым относятся
недобросовестные пользователи, инсайдеры и так далее, и внешних угроз, к которым
можно отнести хакеров, конкурентов и других лиц, стремящихся получить
конфиденциальную информацию о предприятии.
Защита от внешних угроз осуществляется путем применения следующих
способов:
Использованием программно-аппаратных комплексов;
Разработкой и соблюдение политик безопасности;
Использованием защищенных каналов связи при передаче информации;
Использованием антивирусных средств;
Физической защитой помещений с наиболее ценной информацией.
Характеристика используемых средств от внешних угроз информационной
безопасности приведена в таблице 2.1.
Таблица 2.1
Характеристика используемых средств от внешних угроз информационной
безопасности
Способ (метод)
Описание (наименование средства)
Программно-аппаратные
комплексы защиты информации
КСЗИ «Панцирь-К»
Разработка и соблюдение политик
безопасности
- ограничение доступа
пользователей к информации;
- анализ и статистика нарушений
информационной безопасности;
- информационный мониторинг;
- распределение ответственности по
обеспечению информационной
безопасности;
- определение порядка работы с
информацией, являющейся
конфиденциальной.
Защита каналов связи
протокол SSH
Антивирусная защита
Kaspersky Total Space Security
Физическая защита помещений
- система контроля и управления
доступом;
- оборудование помещений
решетками на окнах;
- разграничение прав доступа в
помещения.
Электронный замок «Соболь»
76
Созданный и поставляемый ЗАО НИП «Информзащита», «Соболь» включает в
себя следующие функций защиты:
Определение и аутентификация пользователей;
Отслеживание целостности файлов и физических секторов накопителя данных;
Запрет загрузки ОС с внешних устройств;
Запрет на вход в систему зарегистрированного пользователя при исчерпании им
указанного количества неверных попыток входа;
Запись событий, относящихся к безопасности системы.
Среда применения Etoken - строгая двухфакторная аутентификация
пользователей при попытке доступа к защищённым данным (компьютерам, сетям,
программам).
Исполнение аппаратных криптографических операций в защищённой среде
(внутри микросхемы ключа: подбор ключей шифрования, симметричное и
асимметричное шифрование, просчет хэш-функции, подготовка ЭЦП). Защищённый
метод хранения критически важной информации - криптографических ключей,
пользовательских профилей, настроек ПО, цифровых сертификатов и пр.
осуществляется в энергонезависимой памяти ключа. eToken совместим с
большинством современных ОС, бизнес-программ и продуктов по защите данных в
качестве средства определения и идентификации пользователя. eToken может служить
альтернативой для замены стандартной парольной защиты на более надежную
двухфакторную аутентификацию (когда пользователь имеет нечто - eToken, и знает
нечто - PIN код). К плюсам этого решения относятся:
Мобильность для пользователя и способность работы в "недоверенной среде" (с
чужого ПК) благодаря тому, что ключи шифрования и ЭЦП создаются
аппаратно и не могут быть перехвачены.
Безопасное применение – использовать его может только тот, кто знает PIN-код
авторизации.
Простота работы – ключ представляет из себя брелок со светодиодными
индикаторами режимов работы и подключается к USB-портам, которые сейчас
имеются на 100% компьютеров, не требует дополнительного оборудования,
внешнего питания и других проводов.