46
На любом этапе могут реализовываться несколько процессов, которые
определены стандартом ГОСТ Р ИСО/МЭК 12207-2010, и напротив, один и тот
же самый процесс может реализовываться на разных этапах. Соотношение
между этапами и процессами также определяется применяемой моделью
жизненного цикла информационной системы [Ошибка! Источник ссылки не
найден.]
Модели жизненного цикла ИС
В рамках каскадной модели предполагается последовательное
исполнение всех этапов проекта в строго определенном порядке. Переход к
следующему этапу производится только при полном завершении работ на
предшествующей стадии. Проводится четкое документирование требований в
форме технического задания. Окончание каждого этапа предполагает издание
полного комплекта документов, достаточного для того, продолжения
разработки другой группой специалистов.
Понятие «жизненный цикл проекта» можно интерпретировать как период
времени от зарождения идеи проекта до его завершения, который можно
разделить на соответствующие фазы или этапы [8]:
• Этап замысла.
• Этап разработки.
• Этап производства.
• Этап применения
• Этап поддержки применения.
• Этап прекращения использования и списания
Не существует единого оптимального метода, позволяющего определить
наиболее подходящий жизненный цикл и структуру проекта. У некоторых
предприятий существуют принятые принципы, согласно которым для каждого
проекта подразумевается один и тот же жизненный цикл, в то время как
остальные предприятия позволяют команде управления проектом самим
выбирать жизненный цикл, наиболее подходящий для проекта [26].
47
Модель ЖЦ программного обеспечения представляет собой структуру,
определяющую порядок реализации и взаимосвязи процессов, задач и действий
в течение ЖЦ. Модель ЖЦ находится в зависимости от специфики, сложности
и масштаба проекта, а также специфики условий, в которых создается и
работает система.
Различают такие модели ЖЦ [15]:
• Каскадная модель - подразумевает последовательное выполнение
всех этапов проекта в строго определенном порядке. Переход на следующий
этап выполняется только после полного завершения работ на предыдущем.
• Итерационная модель - подразумевает разделение жизненного
цикла проекта на определенную последовательность итераций, напоминающих
«мини-проект», каждый из которых включает все процессы разработки в
использовании к формированию меньших сегментов функциональности, в
сравнении с проектом в общем. Цель каждой итерации состоит в получении
функционирующей версии программного продукта, включающей
функциональность, которая определена интегрированным содержанием всех
прошлых, и текущей итерации. В результате завершающей итерации
содержится вся требуемая функциональность продукта.
• Спиральная модель - складывается из нескольких итераций (витков
спирали) путем создания прототипов (черновых версий программы). Любая из
итераций соответствует формированию сегмента или версии ПО, на ней
уточняются характеристики и цели проекта, осуществляется оценка качества
полученных результатов и планирование работ следующей итерации.
Для разработки требуемого приложения автоматизации
документооборота выбрана спиральная модель, представленная на рисунке 2.1
48
Рисунок 2.1 - Спиральная модель
Структура модели жизненного цикла программного обеспечения приведена
согласно стандарту ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология.
Процессы жизненного цикла программных средств [14]. Концепция спиральной
модели, разработанная Барри Боэмом в 1986 году, применяется в рамках разработки
большого количества информационных систем [8]. Она выступает в роли технологии
разработки программного обеспечения, сочетающей в себе как стадии
проектирования, так и постадийного прототипирования с целью сочетания
достоинств восходящих и нисходящих алгоритмов, в которой делается упор на работу
с начальными этапами жизненного цикла: стадий анализа и проектирования.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
На различных этапах жизненного цикла ИС деятельности службы
технической поддержки различные риски могут реализовываться по-разному.
В процессе эксплуатации разрабатываемой информационной системы
вероятно возникновение различного рода рисков, которые могут оказывать
влияние, как и на технологию разработки, так и на функционирование
49
компании. Проведем анализ ожидаемых рисков по этапам жизненного цикла
более подробно.
• Стадия разработки и внедрения.
o Для данной стадии характерно наличие рисков, связанных с
нарушением методологии ведения проекта.
В таблице 2.1 представлены предполагаемые риски на этапах ЖЦ и план
реагирования в случае возникновения рисковых ситуаций.
Таблица 2.1
Ожидаемые риски на этапах ЖЦ
№
этапа
Этап ЖЦ Название риска Меры противодействия
1
Предпроектный
этап
Риск сотрудников со
стороны заказчика и
исполнителя
Риск неполноты сбора
информации
Документирование рисков,
включение в договор моментов
неполного сбора информации
2
Проектировани
е
Риск выработки
неправильных
проектных решений
Риск неправильного
планирования
Ценовой риск
Форс - мажор
Экспертиза технических заданий
совместно ИТ, профильными и
экономическими службами,
страхование
3
Разработка
Риск сотрудников
Технический риск
Тестирование на всех этапах
разработки, экспертиза
создаваемого ПО на всех стадиях
создания, работа в команде
4
Внедрение
Риск сотрудников
Программный и
технический риск
Тестирование на всех этапах
внедрения, экспертиза ПО на всех
стадиях создания, работа в команде
5
Эксплуатация и
сопровождение
Технические риски
Риск сотрудников
Юридическое
обеспечение
договоров, работа в команде
В качестве мер по предотвращению рисков подобного рода можно
рассматривать [Ошибка! Источник ссылки не найден.]:
четкое разграничение прав и обязанностей группы разработчиков;
проведение обучения группы разработчиков, администраторов и
ключевых пользователей;
разработку эксплуатационной документации на разработанную
систему;
50
документальное подтверждение по изменениям, вносимым в
проект;
o Риски, связанные с ведением проекта:
ошибки в определении рамок и масштабов проекта;
наличие ошибок в функциях и интерфейсах;
выбор технологий и методов, несоответствующих специфике
решаемых задач;
несоблюдение требований при проектировании информационной
системы или постоянное внесение изменений в требования.
В качестве мерами по предотвращению обозначенных выше рисков
можно рассматривать [20]:
обеспечение стабильности границ проекта, определенных на
начальной стадии;
обеспечение качества при планировании работ;
обеспеченность проекта необходимыми ресурсами;
обязательность утверждения и согласования по проектным
решениям;
проведение дополнительного анализа функций и целей проекта,
тщательная формулировка концепции;
o Риски, связанные с ошибками в планировании:
недостаточность проработки плана внедрения системы;
несоблюдение сроков выполнения;
В качестве мер предотвращения данных обстоятельств можно
рассматривать следующие [4]:
укомплектованность проектной команды квалифицированными
разработчиками;
равномерное распределение работ в соответствии со
специализацией разработчиков;
51
ведение документации по всем видам работ на стадии проектировки
и обеспечения доступности данных для всех участвующих в проекте;
o Технический и программный риски вызывают:
полную или частичную приостановку стадии разработки вследствие
ошибок в применяемом ПО;
частичная или полная потеря программного кода;
контрольным примером не учитываются все особенности системы,
другими словами он считается недостаточно проработанным;
В документацию по системе не включено подробное описание всего
функционала системы.
Этого можно избежать следующим образом [15]:
использовать лицензионного программное обеспечение;
производить регулярное резервное копирование данных;
проводить многократные прогоны и проверки работоспособности
системы, чтобы обнаружить малейшие неисправности в процессе работы;
проводить проверку документации перед тем, как передать систему
в эксплуатацию.
• Этапы эксплуатации:
o Риск персонала;
трудности в обучении персонала из-за отсутствия желания работать
с новой системой;
отсутствует поддержка внедрения ИС со стороны некоторых
основных участников проекта;
неучастие руководителей высшего звена в проекте;
нарушение информационной безопасности в процессе работы
системы.
Этого всего можно избежать, реализация такие идеи:
составление плана по внедрению ИС;
обучение сотрудников работе с системой;
52
доведение до сотрудников сути внедрения автоматизированной
системы;
организация системы поощрений использующего систему
персонала заказчика;
активное привлечение высшего руководства.
o Технический риск:
утрата данных в процессе внедрения ИС;
потенциальный отказ технического оборудования в процессе
внедрения ИС;
«зависание» программы, невозможность реализации требуемых
действия;
ошибки в программе, которые приводят к простою системы;
Применение вредоносных программ (трояны, черви, вирусы,
логические бомбы), применение найденных ошибок в корыстных целях;
приостановка деятельности третьего лица (к примеру, провайдера
Интернет услуг);
В качестве мер по предупреждению данных рисков можно рассматривать
[Ошибка! Источник ссылки не найден.2]:
использование пилотного, поэтапного подхода к организации
процесса внедрения;
тщательность при проведении тестирования и выявления ошибок на
стадии разработки;
обеспечение своевременности при устранении ошибок;
наличие альтернативных средств доступа в Интернет либо других
методов передачи данных;
обязательное утверждение любых изменений системы.
53
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Разрабатываемая ИС должна соответствовать требованиям
законодательства и требованиям защиты информации, которые утверждены.
Выделим главные виды угроз, которые возникают при
функционировании ИС:
- Внутренние, которые возникают из-за некорректных действий
пользователя. В процессе анализе потенциала этого вида угрозы было
установлено, что главным пользователем системы считается единственный
специалист, использование системы строгого разграничения доступа считается
нецелесообразным. Чтобы уменьшить потенциал угроз необходимо провести с
пользователем инструктаж под роспись о правилах информационной
безопасности;
- Внешние, которые возникают из-за внешних воздействий (Интернет-
угроз, несанкционированного копирования, вирусной активности, технических
сбоев)
Следовательно, в разрабатываемую ИС необходимо включить
компоненты резервного копирования БД, парольной защиты. На рабочей
станции специалиста, на которой будет разворачиваться БД службы
технической поддержки, необходимо применять общие для предприятия
политики безопасности.
После проведения экспертизы проекта на наличие компонентов
информации конфиденциального характера можно принять решение о
использовании технических и организационных мер по защите информации:
- Отключение USB-портов, чтобы ограничить возможность
несанкционированного копирования информации;
- Опечатывания рабочей станции;
- Причисление помещения, в котором расположена рабочая станция с БД,
к категории выделенных помещений.
54
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
Информационная модель представляется 3Д моделью системы.
После построения всех деталей информационной системы мобильного
робота можно переходить к формированию сборки. Первый элемент, который
был добавлен в сборку – основание. Именно на основании располагаются все
детали робота. Первоначально на верхнюю часть основания крепятся два
батарейных отсека и кнопка включения (выключения) питания (рисунок 2.2). В
каждый батарейный отсек вставляются по четыре пальчиковых батарейки.
Рисунок 2.2 – Установка на верхнюю часть основания
батарейного отсека и кнопки включения (выключения) питания
На следующим этапе на верхнюю часть основания устанавливают
основные электронные элементы робота - драйвера двигателя L298N,
Бредбоард и Arduino UNO (рисунок 2.3). Бредбоард представляет собой
печатную плату, имеющую множество контактных пазов, для удобного
соединения проводников и радиоэлементов электронной техники.
55
Рисунок 2.3 – Установка на верхнюю часть основания
драйвера двигателя L298N, Arduino UNO и Бредбоард
На нижнюю часть основания устанавливают мотор редукторы
(двигатели), на которые крепятся ведущие колеса, и опорное колесо (рисунок
2.4). Опорное колесо способно свободно вращаться вокруг установочной оси.
Рисунок 2.4 – Установка на нижнюю часть основания мотор
редукторов, ведущих колес и опорного колеса
Завершающим этапом сборки является установка веб-камеры на
контейнер для батареек (рисунок 2.5).