86
V-подход (VEE модель) становится моделью создания ИС,
направленной на облегчение понимания всех сложностей, связанных с
процедурой создания систем. Она применяется в рамках реализации
отдельной процедуры создания ПО, аппаратного обеспечения и интерфейса
взаимодействия машины и человека.
Суть V-модель состоит в том, что детализация проекта растет в рамках
передвижения слева на право, параллельно течению времени, и никакой
процесс не поворачивает обратно. Все действия в проекте выполняются по
горизонтали, при этом участвуют левая и правая сторона.
Для подготовки ЖЦ ИС был определен стандарт ISO 12207, который
характерен для большинства АИС и других систем, где пользовательская
часть – это всего лишь один из этапов работ. Общепринятый стандарт
ISO/IEC 12207 отражает принцип и порядок создания и применения ПО, он
охватывает ЖЦ ПО от создания продукта до его вывода. Основное
определение: система — это взаимосвязь одного и более процессов,
технологий, ПО, оборудования и людей для выполнения принципов
удовлетворённости конкретными услугами или продуктами.
В сравнении с Oracle CDM, стандарт ISO 12207 направлен на
реализацию деятельности с двух сторон: поставщика и потребителя.
Используется даже тогда, когда эти две стороны находятся в рамках одной
компании. В сравнении с CDM, стандарт ISO включает несколько
обобщенных процессов: приобретение, создание, получение и т.п. Каждый
процесс тут делится на различные действия, а каждое действие — на
требуемые для его решения задачи. И есть важное отличие ISO: каждый
процесс, действие или задача выражается и проводится другим процессом
по факту необходимости, причем нет заранее созданных
последовательностей (исходя из сохранения связности на начальных этапах
и т.п.).
87
Эволюционный характер стандарта основан на методике выражения
череды реализации процессов и задач, когда реализуемый процесс может
вызвать другой процесс или его часть. Также в нем вложено отражение
архитектуры, процессов, этапов и принципов ЖЦ ПС, также присутствует
список всех требуемых задач и подробная характеристика каждой из них.
Архитектура ЖЦ базируется на 3 важных элементах:
• Приобретение и получение;
• Генерация;
• Применение.
Стандарт не имеет описанных конкретно действий, а также не
включает примеров действий и документации. Он определяет архитектуру
процессов ЖЦ ПО, но не сильно акцентирует внимание на деталях
реализации или реализации задач и услуг, которые в эти процессы
включены. Он также не отражает определенную модель ЖЦ или методику
разработки ПО, но включает в себя понимание, что участники проекта несут
ответственность за определение модели ЖЦ для проекта ПО, за подготовку
процессов и задачи для выбранной модели, за определение и применение
методов создания ПО, за все выполненные задачи и действия, которые
необходимы для конкретного проекта ПО.
Приобретение и получение. Суть задачи – поступление разработчику
предложения заказчика на создание АИС. Именно тут подписывается
договор, отражаются условия и требования. Действующие лица этапа –
представитель от лица заказчика, который проверяет действия
разработчиков, а также управляющий проекта от лица разработчиков.
Именно он получает от заказчика требования, заключает договор,
согласовывает начальные установки и задачи для начала работ. Именно тут
заказчик обязан передать подробное ТЗ, менеджер подписывает его, утоняет
моменты по разработке и оговаривает средние сроки протяженности всех
работ.
88
Генерация. Разработка (генерация) ПО разделяется на множество
этапов, которые поддерживают реализацию ИС, которые отвечают
требованиям заказчика, и в указанные по договору сроки:
• Проводится изучение требований к системе;
• Создание системной структуры;
• Описание требований к системе;
• Создание каркаса системы;
• Проектирование системы детальным образом;
• Создание и проверка готовой системы;
• Установка системы на объекте;
• Проверка результатов работы системы;
• Запуск системы в работу;
• Итоговая приемка системы.
На данном этапе участниками проекта становятся менеджер проекта
и сами разработчики. Управляющий проектом делит задачу разработки ПС
на описанные выше этапы, отслеживает исполнение и ход реализации работ
за каждым программистом. Если это необходимо, самостоятельно участвует
в подготовке и координации действий между конкретными разработчиками.
Выделяет участки работ для конкретного программиста исходя из
квалификации и опыта сотрудников, указывает степень оптимальности
взаимодействия конкретных частей ПС, разрешает проблемные и спорные
моменты.
Разработчики определяют для себя план работ, требуемые действия и
пути решения для выполнения задачи. Выделяют для себя методы решения
своих задач, описывают текущие пути решения для других разработчиков,
определяют специфику функций, протоколов передачи информации и т.п.
Применение. Тут выполняется тестовое испытание ПС,
обнаруживаются слабые и сильные моменты и недоработки, проверяется
общая работоспособность всех компонентов. При обнаружении
89
недоработок подготавливается список ошибок для последующего
исправления разработчиками.
Для разрабатываемого проекта наиболее подойдет каскадная модель
для разработки приложения из-за возможности контроля промежуточных
фаз.
Далее произведем выбор стратегии внедрения разработанной
системы. В настоящий момент выделяется четыре стратегии внедрения
информационной системы:
Параллельная стратегия - для случая, когда старую работающую
систему необходимо заменить новой;
Скачок – эта стратегия подразумевает резкий переход от одной
системы автоматизации к другой;
Опытная эксплуатация "пилотного проекта - это тактика
"скачка", но применяемая к ограниченному числу изделий, наиболее
успешна в малом участке деятельности;
Узкое место - при внедрении "узкого места" план внедрения
выполняется только для "узкого места" и для людей, работающих в нем.
Исходя из описания и условий деятельности компании, а также
особенностей разрабатываемой информационной системы, в качестве
стратегии внедрения была выбрана стратегия Опытная эксплуатация
пилотного проекта, так как в этом случае внедрение системы произойдет
наиболее безболезненно.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их
описание
Любой сложный проект, а особенно проект разработки программного
обеспечения, содержит в себе много неопределенных моментов, которые
влекут за собой риски реализации проекта.
90
Управление рисками заключается в их раннем выявлении и
разработке мер либо полностью предотвращающих их возникновение, либо
минимизирующих их последствия.
В настоящее время существует три общепринятых стратегии
управления рисками:
Избегание рисков – проект реорганизуется таким образом,
чтобы исключить возможность возникновения рисков;
Делегирование рисков – проект реорганизуется таким образом,
чтобы переложить риски на третью сторону (заказчика, банки, вендора и
т.п.);
Принятие рисков – риски признаются в качестве неизбежной
составляющей проекта, проводится постоянный мониторинг симптомов их
наступления, постоянно корректируется план действий в случае
наступления рисков.
Различают две основные категории рисков – прямые и
опосредованные. На прямые риски проектная команда может каким-то
образом повлиять, а опосредованные риски команда контролировать не
может в принципе.
Риски делятся на следующие основные виды:
Ресурсные риски:
o Организация (выполняла ли организация прежде проекты
такого масштаба, существует ли формальный процесс разработки
программного обеспечения и т.п.);
o Финансирование (полностью ли обеспечено финансирование
проекта, фиксирована ли стоимость проекта или она является предметом
для обсуждения, точно ли выполнена оценка затрат и т.п.);
o Люди (достаточно ли людей для выполнения проекта, обладают
ли они необходимыми навыками и опытом, работали ли они вместе раньше
и т.п.);
91
o Время (реалистичен ли план проекта, насколько критичной
является дата окончания проекта и т.п.);
o Бизнес (что произойдет, если конкурент выйдет на рынок
первым, выгода, полученная от реализации проекта больше, чем затраты на
него, что произойдет, если ключевые поставщики не смогут выполнить свои
обязательства и т.п.);
Технические риски:
o Область действия (scope) проекта (могут ли быть измерены
критерии успешного завершения проекта, требования стабильны и хорошо
поняты, область действия жестко фиксирована или может расширяться в
будущем и т.п.);
o Технологии (отлажена ли применяемая технология или она
только была разработана, и т.п.);
o Внешние зависимости (зависит ли проект от других
параллельных проектов, зависит ли успех проекта от внешних поставщиков
технологий и/или продуктов и т.п.).
В данном проекте можно выделить следующие основные риски на
каждом этапе жизненного цикла (таблица 2.1).
Таблица 2.1.
Основные риски на этапах жизненного цикла
информационной системы
Этап Риск Мероприятия
Заказ Несоответствие
выделенного бюджета
масштабу проекта
Переговоры по увеличению
бюджета или отказ от
участия в проекте
92
Заказ Неформализуемая задача
(невозможно
автоматизировать те или
иные бизнес-процессы или
стоимость такой
автоматизации превысит
ожидаемую выгоду)
Пересмотреть область
действия проекта с целью
выделения отдельных
задач, поддающихся
автоматизации.
Провести детальный анализ
бизнес-процессов и
предложить комплекс
мероприятий по их
реорганизации.
Проектирование - неправильное
определение рамок и
масштабов проекта;
- проектирование
ошибочных функций и
интерфейсов будущей
системы;
- выбор неправильных
технологий и методов
решения поставленных
задач;
- несоблюдение требований
заказчика при
проектирование будущей
системы или постоянное
изменение требований.
- обеспечение стабильности
границ проекта,
определенных на
начальном этапе, вплоть до
окончания проекта;
- качественное
планирование работ
;
- своевременная
идентификация проектных
рисков и разработка
рекомендаций по снижению
рисков;
- обеспечение проекта
необходимыми ресурсами;
- обязательное
утверждение и
согласование по проектным
решениям
Разработка Недостаточно ресурсов для
выполнения комплексного
и нагрузочного
тестирования
Заключить договор со
специализированной
организацией на
выполнение ею этих работ.
Недостаточно опыта у
персонала заказчика,
который будет
эксплуатировать систему
Предоставить заказчику
услуги собственного
специалиста для
первоначального
сопровождения системы и
постепенного обучения
персонала заказчика.
Внедрение - увеличение нагрузки на
персонал;
- несогласованность
действий персонала
исполнителя и сотрудников
предметных областей
- проведение обучения
персонала заказчика
работы с системой;
- составление плана
внедрения ИС
Кроме того, в процессе эксплуатации и сопровождения разработанной
ИС могут возникнуть:
технические риски;
93
риски персонала.
Факторами технических рисков являются:
ошибки в программе вызывающие простой системы;
невозможность осуществления требуемых действия,
«зависание» программы;
использование вредоносных программ (вирусы, черви, трояны,
логические бомбы), использование в корыстных целях найденных ошибок
(дыр) в программах,
перехват информации по телекоммуникациям, воровство
информации;
некорректная эксплуатация оборудования;
приостановка деятельности третьего лица (например,
провайдера Интернет услуг), что повлечет за собой невозможность
передачи отчетов из филиалов и контроля деятельности филиалов;
несоответствие функциональных возможностей системы
бизнес-процессам в комплекса задач в следствие реорганизационных
изменений. Предотвратить данные обстоятельства можно, соблюдая
следующие моменты:
тщательное тестирование и выявление ошибок на этапе
разработки;
устранять в кратчайшие сроки ошибки силами прошедших
подготовку на этапе внедрения технических специалистов;
администратор сети должен следить за безопасностью
информации,
использовать и вовремя обновлять антивирусные программы,
правильно настроить FireWall, которые будут разделять локальную и
внешнюю сеть, предоставить работникам организации возможность работы
только с той информацией, которая им необходима для исполнения своих
служебных обязанностей;
94
разделение клиентского и серверного оборудования, а также
необходимо привлечение обученного работе с системой
квалифицированного персонала;
наличие альтернативных средств доступа в Интернет или
других способов передачи данных;
документирование технических условий и их согласование со
всеми заинтересованными участниками проекта;
обязательное утверждение любых изменений.
Факторами возникновения риска персонала являются следующие
обстоятельства:
нарушение информационной безопасности работы - возможна
утечка информации из-за злоумышленных действий сотрудников и не
желании работать с новой системой;
не определен этап выхода их проекта консультантов заказчика.
В противовес этому может выступать:
организация системы поощрений использующего систему
персонала заказчика;
прием на работу сотрудников при условии не разглашения
коммерческой тайны в противном случая - применение штрафных санкций;
четкое планирование сроков проекта и момента прекращения
работы над проектом со стороны исполнителя.
2.1.3. Организационно-правовые и программно-аппаратные
средства обеспечения информационной безопасности и защиты
информации
При эксплуатации разработанной информационной системы для
обеспечения её безопасности от внешних и внутренних угроз используется
комплекс мер по защите информации. В этот комплекс прежде всего входят
95
средства, позволяющие ограничить доступ пользователей к различным
модулям системы.
Для защиты от внутренних угроз в системе используется политика
разделения прав доступа. Характеристика политики приведена в таблице
2.2.
Таблица 2.2.
Разграничение прав пользователей
Группы
пользовател
ей
ПМ
Авторизац
ия
ПМ
формирован
ие запросов
ПМ
формирован
ия отчетов
ПМ работы
со
справочника
ми
Администрато
р системы
Полный Полный Полный Полный
Пользователь Чтение Создание Чтение Нет
Сотрудники Чтение Чтение Чтение Нет
В целях защиты информационной системы проводятся следующие
мероприятия:
обеспечение сетевой безопасности;
обеспечение локальной безопасности;
обеспечение физической безопасности.
Для обеспечения сетевой безопасности используются следующие
средства:
фильтрация трафика;
ограничение доступа в интернет и во внутреннюю сеть;
антивирусная фильтрация;
система обнаружения атак;
контроль содержания трафика;
протоколирование и регулярный мониторинг доступа.
Локальная безопасность обеспечивается осуществлением следующих
мероприятий:
антивирусный контроль;