59
внедрение. Каждая фаза разбивается на этапы, в результате которых выпускается
версия для внутреннего или внешнего использования. Циклом разработки в
данном случае является – прохождение через четыре основные фазы, где каждый
цикл завершается генерацией версии системы. Если после этого работа над
проектом не прекращается, то полученный продукт продолжает развиваться и
снова минует те же фазы. Суть работы в рамках RUP – это создание и
сопровождение моделей на базе универсального языка моделирования UML.
Microsoft Solution Framework (MSF) – методология разработки
программного обеспечения от Microsoft. MSF опирается на практический опыт
корпорации Майкрософт и описывает управление людьми и рабочими
процессами в процессе разработки решения. MSF представляет собой
согласованный набор концепций, моделей и правил [13].
Extreme Programming (XP). В основе экстремального программирования
лежит 3 методологии: командная работа, эффективная коммуникация между
заказчиком и исполнителем в течение всего проекта по разработке ИС, а
разработка ведется с использованием последовательно дорабатываемых
прототипов.
Custom Development Method (методика Oracle) по разработке прикладных
информационных систем – технологический материал, детализированный до
уровня заготовок проектных документов, рассчитанных на использование в
проектах с применением Oracle. Применяется CDM для классической модели ЖЦ
(предусмотрены все работы/задачи и этапы), а также для технологий «быстрой
разработки» (FastTrack) или «облегченного подхода», рекомендуемых в случае
малых проектов [15].
Рассмотрев стандарты жизненного цикла ИС, выбран стандарт MSF.
Поскольку АО «Нива» использует технологии и продукцию Microsoft, то у
сотрудников имеется огромные знания и опыт работы с продуктами Microsoft.
Платформа Microsoft Solutions Framework (MSF) реализует гибкий подход,
который позволяет быстрее создавать технологические решения, привлекая
меньше людей, снижая риски и повышая уровень качества.
Модель процессов MSF представляет собой общую методологию
разработки и внедрения IT-решений. Благодаря гибкости данная модель может
60
использоваться для разработки широкого круга IT-решений, она охватывает весь
жизненный цикл создания решения, с самых ранних этапов до внедрения. Модель
процессов MSF сочетает в себе качества двух классических моделей: каскадной и
спиральной.
Процесс MSF ориентирован на «вехи» (milestones). Вехи – ключевые точки
процесса разработки, которые характеризуют достижение какого-либо
существенного результата [20].
Модель процессов MSF учитывает постоянные изменения требований к
конечному продукту, процесс разработки состоит из коротких циклов и
представляет собой поступательное движение от простейших ранних версий
продукта к его окончательному виду.
Основными фазами модели MSF являются:
1. Создание общей картины приложения
На этом этапе решаются следующие основные задачи:
определение состава команды;
определение структуры проекта;
определение бизнес-целей;
оценка существующей ситуации;
создание документа общей картины и области действия проекта;
определение требований и профилей пользователей;
разработка концепции решения;
оценка риска;
закрытие этапа.
На этапе выделяются две промежуточные контрольные точки:
«Организован костяк команды» и «Создана общая картина решения».
Организован костяк команды. В документах структуры проекта
необходимо определить роль и обязанность каждого члена команды, а также
описать иерархию отчетности и ответственности в группе, каналы
взаимодействия с заказчиком и общую структуру команды.
Создана общая картина решения. Речь идет о разработке концепции
решения, которым должна руководствоваться команда для достижения
долгосрочных бизнес-целей проекта. Область действия проекта определяет, что
61
включается в контекст проекта, а что выходит за его рамки. На этой временной
точке речь идет о создании первой версии документа, который находится в стадии
рецензирования участниками команды и согласования заказчиком. Этап
завершается контрольной точкой «Утверждение документа общей картины и
области действия проекта».
2. Планирование.
На данном этапе команде необходимо сформировать план реализации
продукта. Для этого готовится функциональная спецификация, создается проект
решения, детализируются планы работы, выполняется оценка стоимости и сроков
получения результатов.
На этом этапе проводится анализ требований, которые делятся на бизнес-
требования, пользовательские, функциональные и системные требования. После
сбора и анализа требований команды разрабатывается проект решения,
определяются профили пользователей, после чего формируются сценарии
применения решения, выполняемые пользователями одного типа, а затем
определяются варианты использования системы.
Этап состоит из трех стадий: концептуальное, логическое и физическое
проектирование. На стадии концептуального проектирования задача
рассматривается с точки зрения пользовательских и бизнес-требований и
заканчивается определением набора сценариев использования системы. При
логическом проектировании задача рассматривается с точки зрения проектной
команды, решение представляется в виде набора сервисов. И уже на стадии
физического проектирования задача рассматривается с точки зрения
программистов, уточняются используемые технологии и программные
интерфейсы.
В ходе данного этапа решаются такие задачи:
разработка проекта и архитектуры решения;
создание функциональной спецификации;
разработка планов проекта;
разработка календарного графика;
создание среды разработки, тестирования и пилотной эксплуатации;
закрытие этапа.
62
Контрольные точки этапа планирования связаны с достижением
следующих результатов:
функциональная спецификация;
план управления рисками;
определение среды разработки и тестирования;
генеральный план и календарный график проекта.
Результаты данного этапа служат для принятия компромиссных решений в
дальнейшем.
3. Разработка
На этапе разработки создается решение, в том числе пишется и
документируется код. В начале этого этапа команда проверяет выполнение всех
задач, характерных для предыдущих этапов, а затем приступает к решению
следующих задач:
создание прототипа приложения;
разработка программных компонентов приложения;
создание решения (последовательность ежедневных или более частых
сборок приложения);
закрытие разработки (реализация всех функций, поставка кода и
документации).
Результаты этапа предполагают следующие элементы:
исходный текст кода и исполняемые файлы;
сценарии установки и конфигурации для развертывания;
окончательная функциональная спецификация;
элементы поддержки решения;
спецификации и сценарии тестирования.
Основная контрольная точка этапа – «Окончательное утверждение области
действия проекта». В этот момент все функции продукта готовы и прошли
тестирование в рамках данного модуля. После этого продукт готов к внешнему
тестированию и стабилизации. Кроме того, заказчики, пользователи, сотрудники
службы поддержки и сопровождения, а также ключевые участники проекта могут
предварительно оценить продукт и указать все недостатки, которые нужно
устранить до его поставки.
63
4. Стабилизация
Данный этап – подготовка к выпуску окончательной версии продукта,
доводка его до заданного уровня качества. Здесь выполняется комплекс работ по
тестированию (обнаружение и устранение дефектов), а также проверяется
сценарий развертывания продукта и проводится пилотная эксплуатация.
Тестирование подразумевает следующие основные виды работ:
тестирование компонентов;
тестирование баз данных;
тестирование инфраструктуры;
тестирование защиты;
тестирование интеграции;
анализ удобства работы с продуктом;
нагрузочное тестирование (включая анализ ресурсоемкости и
производительности);
регрессивное тестирование;
ведение отчетности по тестированию.
Когда решение становится достаточно устойчивым, проводится его
пилотная эксплуатация в тестовой среде с привлечением пользователей и
применением реальных сценариев работы.
Один из главных показателей этапа стабилизации – число обнаруженных
ошибок. Сходимость этой величины в сторону устойчивого уменьшения –признак
того, что близится завершение работ над продуктом. Важнейшая промежуточная
контрольная точка – появление версии, в которой усилиями самой проектной
команды не обнаружено ни одной ошибки. Далее следуют выпуски кандидат-
релизов продукта для их исследования в условиях пилотной эксплуатации.
Завершающая контрольная точка – подтверждение готовности продукта к
выпуску и полноценному развертыванию в промышленной среде.
5. Развертывание
На этом этапе выполняется установка решения и необходимых
компонентов окружения, проводится его стабилизация в промышленных
условиях и передача проекта в руки группы сопровождения. Кроме того,
64
анализируется проект в целом на предмет уровня удовлетворенности заказчика.
Основные контрольные точки данного этапа таковы:
развернуты основные компоненты;
развернуто решение в целом;
развернутое решение стабилизировано;
решение развернуто и передано в эксплуатацию заказчику.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Рассмотрены риски, которые возникают на этапах жизненного цикла ИС.
Выявление рисков является начальной стадией процесса управления ими. Оно
должно быть осуществлено как можно раньше, и к нему необходимо постоянно
возвращаться на протяжении всего жизненного цикла проекта.
1. Создание общей картины приложения. В данной фазе может возникнут
риск создания концепции, которую будет сложно реализовать. Для того, чтобы
предотвратить этот риск необходимо понимать возможности и более подробно
проработать цели и задачи.
2. Планирование. На фазе планирования могут возникнуть риск неверно
сформированной архитектуры выбираемого решения. Неправильно или не совсем
корректно сформированная архитектура выбираемого решения. В фазе
планирования важно следить за каждым этапом и анализировать реалистичность
результатов.
3. Разработка. На фазе разработки возможны следующие риски:
Неправильная интерпретация технического задания и как следствие
неправильная программирование архитектуры и сдвиг сроков. Для того чтобы
предотвратить риск разработки необходимо четко написать техническое задание
для программиста.
Еще одним важным риском в данном проекте является разработка
определенного модуля с трудностями. Поэтому важно вовремя определить
проблемный модуль упростить его, заменить, либо убрать из проекта полностью.
65
4. Стабилизация. В фазе тестирования может возникнуть риск, когда
программный продукт будет протестирован не до конца. Поэтому необходимо
проводить повторное тестирование на следующей итерации разработки.
5. Развертывание. В фазе развертывания могут возникнуть следующие
Риски неправильного принятия решения о законченности части проекта.
Возникновение данных рисков ведет за собой проблему незаконченности
решения и возможность возникновения нестыковок с другими частями
разрабатываемой ИС.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Для защиты от внутренних угроз в системе используется разграничение
прав доступа изображенные в таблице 2.1.
Таблица 2.1
Разграничение прав доступа
Группы
пользователей
Авторизация
пользователя
Регистрация
документов
(учетная
запись)
Постановка
документа
на контроль
Отметка об
исполнении
Сотрудник
Чтение
Полный
Полный
Ограничен
Руководитель
подразделения
Чтение
Нет
Полный
Полный
Системный
администратор
Полный
Полный
Полный
Полный
Характеристика используемых средств от внешних угроз информационной
безопасности приведена в таблице 2.2.
66
Таблица 2.2
Средства от внешних угроз информационной безопасности
Способ
Описание
Разработка и соблюдение политик
безопасности
ограничение доступа пользователей к
информации;
анализ и статистика нарушений
информационной безопасности;
информационный мониторинг;
распределение ответственности по
обеспечению информационной
безопасности;
определение порядка работы с
информацией, являющейся
конфиденциальной.
Антивирусная защита
ESET Endpoint Antivirus 6
Физическая защита помещений
система контроля и управления доступом;
оборудование помещений решетками на
окнах;
ведение видеонаблюдения за помещение;
разграничение прав доступа в помещения.
На предприятии АО «Нива» защита от внешних угроз осуществляется
путем антивирусника ESET Endpoint Antivirus 6, поскольку у них не имеется
уникального одного метода, который смог бы обеспечить полную
информационную безопасность, то вся надежда ложится только на него.
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
Информационная модель представляет собой схему, отражающую
преобразование информационных реквизитов от источников информации до её
67
получателей или, иными словами, процесс обработки информации в
информационной системе [16].
Опишем, как будет осуществляться работа информационной модели.
В первую очередь системный администратор должен зарегистрировать
сотрудника организации для этого он использует данные о сотруднике и
справочник «Должности». Системный администратор может читать,
редактировать и изменять данные для доступа каждого сотрудника в
информационной системе.
Сотрудники организации, которые имеют доступ авторизовываются в
систему, видит пришедшие документы, регистрирует их. Для этого он использует
Справочник «Типы документов», таким образом, он изменяет таблицу
«документы»
Руководители подразделений формируют Резолюцию (надпись на
документе при использовании таблицы «Резолюция».
Из базы ИС в рамках моделируемой задачи используются справочники
«Должности», «Типы документов» (Под справочником понимается обычная
таблица, которая содержит условно-постоянную информацию).
На выходе моделируемая ИС предоставляет:
Для системного администратора список сотрудников и историю
захождения в систему сотрудников.
Для сотрудников и руководителей предоставляется список документов
по типам, список документов с подписанной резолюцией, список документов
находящийся в архиве и список документов, находящихся на контроле.
Информационная модель представлена на рисунке 2.4.
68
Рис. 2.4 Информационная модель
2.2.2 Характеристика нормативно-справочной, входной и оперативной
информации
В системе используются справочники «Должности», «Тип документа»,
«Документ».