65
Рисунок 2.1 - Основные процессы жизненного цикла ПО
В зависимости от проекта процессы, действия и задачи стандарта
выбираются, упорядочиваются и включаются в модель ЖЦ. При применении
они могут перекрывать, прерывать друг друга, выполняться итерационно или
рекурсивно. Это определяет "динамический" характер стандарта и позволяет
реализовать с его помощью произвольную модель ЖЦ ПС.
Из данного стандарта можно выбрать только те процессы, которые
более всего подходят для реализации конкретной ПС. Обязательными
являются основные процессы, которые присутствуют во всех известных
моделях ЖЦ. В зависимости от целей и задач предметной области они могут
быть пополнены дополнительными (документирование, обеспечение
качества, верификация и валидация и т.п.) и организационными
(планирование, управление и др.) процессами этого стандарта. Разработчик
принимает решение о включении в новую создаваемую модель ЖЦ процесса
обеспечения качества компонентов и системы управления проектом или
определения набора проверочных (верификационных) процедур для
обеспечения правильности продукта и соответствия его заданным
требованиям.
Для рассматриваемой ИС выделяются следующие базовые процессы
жизненного цикла [1]:
1. Разработка
Планирование и анализ требований (предпроектная стадия);
66
Проектирование;
Реализация;
Тестирование
Внедрение;
2. Эксплуатация
Поддержка пользователей;
Техническое обслуживание компонентов системы;
3. Сопровождение
Сбор рекламаций
Исправление ошибок и недоработок
Модернизация
На предпроектной стадии необходимо провести системный анализ,
включающий анализ функционирования склада и выявление недостатков
существующей технологии складского учета. [16] На основе выявленных
недостатков формулируется потребность в совершенствовании системы
управления складом, создается технико-экономическое обоснование проекта
(ТЭО), формулируются технические условия и требования к ИС. Результаты
должны быть оформлены в виде ТЗ (технического задания). Первый этап
выполняется бизнес-аналитиком отдела, с привлечением сотрудников склада.
Входную информацию бизнес-аналитик получает из интервью с
сотрудниками склада, складской документации, должностных инструкций,
регламента работы склада и прочих документов, характеризующих
существующие бизнес-процессы.
Следующий этап – проектирование ИС – включает в себя разработку в
соответствии со сформулированными требованиями состава
автоматизируемых функций (функциональная архитектура), состава
обеспечивающих подсистем (системная архитектура), оформление
технического проекта ИС. Входной информацией для проектирования
является ТЗ. На этом этапе определяется состав программных подсистем и
компонентов оборудования, составляются спецификации требований к
67
компонентам ПО, определяется состав компонентов ПО (в том числе
повторно используемых компонентов), интерфейсы с БД, структуры
хранения данных, алгоритмы обработки информации, спецификации
интерфейсов с другими системами автоматизации, требования к тестам.
Данный этап является очень ответственным с точки зрения качества всей
последующей разработки.
На этапе реализации выполняется физическое проектирование,
программирование, наполнение баз данных, тестирование, разработка
инструкций для персонала.
Тестирование ИС. На этом этапе оценивается система в целом на
соответствие требованиям ТЗ.
Внедрение системы необходимо проводить в три этапа [2, с.79]:
подготовка объекта к внедрению;
опытное внедрение;
сдача проекта в промышленную эксплуатацию.
На этапе подготовки объекта к внедрению планируется провести
следующие работы:
закупить и установить сервер системы и серверное ПО;
развернуть на сервере базу данных;
установить клиентское ПО на все компьютеры АРМ системы;
сконфигурировать взаимодействие АРМ системы с сервером базы
данных;
ввести учетные записи и настроить им права доступа;
заполнить справочники системы реальными данными;
обеспечить пользователей эксплуатационной документацией;
обучить персонал работе с системой.
В процессе внедрения системы участвуют: разработчики системы
(проектировщик, программист), системный администратор и будущие
пользователи системы. Системный администратор должен обеспечить место
для установки нового сервера; подключение к локальной сети для сервера и
68
АРМ пользователей системы; доступ к компьютерам, необходимым для
развертывания системы, с правами администратора. Проектировщик системы
проводит обучение пользователей, конфигурирует систему, заполняет
справочники, проверяет правильность взаимодействия всех подсистем.
Программист оперативно устраняет возникающие при развертывании
системы неполадки.
Опытная эксплуатация системы должна проводиться не менее 3
месяцев. В случае обнаружения ошибок на этапе опытной эксплуатации,
осуществляется поиск причин и устранение ошибок, внесение коррективов в
программу, в технологию обработки данных. После устранения ошибок
подписывается «Акт о проведении опытной эксплуатации», который служит
началом перехода к третьему этапу – сдаче системы в промышленную
эксплуатацию.
На этапе эксплуатации производятся следующие работы:
- периодическая актуализация справочников системы (осуществляется
ответственным за справочник лицом);
- периодическое архивирование информационной базы системы на CD-
носителях (администратор системы);
- локализация проблем и устранение причин их возникновения
(программист);
- модификация ПО (бизнес-анатилик, программист);
- подготовка предложений по совершенствованию системы
(пользователи системы);
- развитие и модернизация системы (бизнес-анатилик, программист).
В настоящее время существует две основные модели жизненного цикла
– это каскадная и спиральная модели. В каскадной модели процесс
разработки идет поэтапно, шаг за шагом. Переход к следующему этапу
происходит только после завершения предыдущего. В спиральной модели
разработка проходит по нарастающей. На начальном этапе разрабатывается
система с высоким уровнем абстракции, а на последующих витках эта
69
разработка все больше и больше конкретизируется. Для жизненного цикла
текущего проекта была выбрана каскадная модель, так как для
разрабатываемой системы больше подходит поэтапная разработка. Переход к
следующему этапу происходит только после завершения всех работ на
предыдущем этапе (Рис. 2.2), включая подготовку полного пакета
документации, достаточной для того, чтобы разработка могла быть
продолжена другой группой разработчиков и есть возможность
планирования сроков завершения работ и затрат на их выполнение.
70
Рисунок 2.2 - Каскадная схема разработки ПО
Каскадный метод хорошо подходит для построения систем, где в самом
начале разработки можно достаточно точно и полно сформулировать все
требования, с тем, чтобы предоставить разработчикам свободу
реализовывать их как можно лучше с технической точки зрения. Однако в
случае, если в середине разработки вскрываются ошибки, допущенные в
начале, то приходится прибегать к энтраверсии проекта и реальная схема
каскадной модели приобретает другой вид (Рис. 2.3). Таким образом,
каскадный метод более всего подходит к конкретной разработке.
71
Рисунок 2.3 - Реальный процесс разработки ПО по каскадной схеме
Существуют следующие основные стратегии внедрения системы:
Параллельная стратегия - когда одновременно работают старая
(ручная) и новая система, и их выходные документы сравниваются. Если они
согласуются длительное время, осуществляется переход на новую систему.
"Скачок". Эта стратегия привлекательна, но не рекомендуется.
"Пилотный проект". Это наиболее часто используемая стратегия.
"Пилотный проекта" - это тактика "скачка", но применяемая к ограниченному
числу процессов. Область применения стратегии - небольшой участок
деятельности. Такой подход снижает риск и наиболее надежен. Практически
все предприятия применяют эту тактику сегодня.
"Узкое место". "Узкое место" - это малая часть производственного
процесса. При использовании похода "узкое место" план внедрения
выполняется только для "узкого места" и для людей, работающих в нем.
Точность данных повышается только для изделий в этом "узком месте";
переподготовка- только для людей, работающих в нем; анализ эффект-затрат
делается только для него и т.д.
72
Выбираем параллельную стратегию,как наиболее подходящую.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Процессы анализа и сокращения рисков должны сопутствовать
основным этапам разработки и обеспечения жизненного цикла сложных
программных средств в соответствии с международными стандартами. [6]
При формулировании постановки задачи и требований к системе могут
возникнуть ошибки и неточности, которые приведут к полному
несоответствию разработанного программного продукта потребностям
склада. Для снижения данного риска необходимо привлечь к выполнению
задачи наиболее опытных разработчиков, а также руководство компании.
На этапах проектирования и реализации системы имеются риски:
ухода одного или группы ключевых специалистов. В этом случае
разработка системы может оказаться под угрозой срыва. Руководству
компании необходимо предпринимать меры для снижения этих рисков, в
частности обеспечивать более тесное сотрудничество сотрудников, обмен
ключевой информацией, взаимозаменяемость сотрудников.
затягивания процесса разработки, соответственно удорожание
разработки. Для снижения этого риска необходим строгий контроль
соблюдения графика разработки. Привлеченные к разработке ИС склада
специалисты не должны привлекаться к прочим проектам и заданиям, их
рабочее время должно быть полностью посвящено разработке ИС.
изменяющихся требований по ходу работы над проектом, которые
могут нарушить все сроки и оценки. Для снижения этих рисков необходимо
привлечение сотрудников склада на границах каждого этапа, чтобы
обнаруживать изменения на ранних стадиях работы над проектом системы.
возникновения дефектов программного продукта вследствие ошибок,
допущенных на различных этапах разработки системы. Классификация
дефектов приведена в таблице 2.1.
Таблица 2.1
Характеристики дефектов программного продукта
73
Этапы возникновения дефектов и
ошибок
Типы первичных дефектов и
ошибок программного средства и
документации
Разработка требований к ПО
Дефекты исходных требований
заказчика
Планирование работ
Дефекты, обусловленные
реальной сложностью проекта
Проектирование архитектуры системы
Ошибки планирования и
системного проектирования
программного средства
Детальное проектирование ПО
Системные и алгоритмические
дефекты и ошибки проекта
Кодирование ПО
Программные дефекты и ошибки
компонентов и документов
программного средства
Тестирование ПО
Программные и алгоритмические
ошибки программного средства и
документации
Разработка документации
Дефекты и ошибки обобщающих
документов
На этапе эксплуатации возможны риски, возникающие по причинам:
1) Злоумышленных, активных воздействий заинтересованных лиц. Для
защиты от внешних угроз необходимо применять средства обеспечения
защиты программ и данных (аутентификация пользователей, защита
локальной сети при помощи межсетевых экранов, применение антивирусных
программ и пр.).
2) Случайных негативных проявлений внешней среды, дефектов
системы или ошибочных действий пользователей. Основными источниками
отказовых ситуаций могут быть некорректные исходные требования, сбои и
74
отказы в аппаратуре, дефекты или ошибки в программах и данных
функциональных задач, проявляющиеся при их исполнении в соответствии с
назначением. При таких воздействиях внешняя, функциональная
работоспособность систем может разрушаться не полностью, однако
невозможно полноценное выполнение заданных функций и требований к
качеству информации для потребителей.
Для снижения рисков, связанных с дефектами системы, необходимо
проводить тщательное тестирование на контрольных примерах,
приближенных к действительности. Для снижения рисков, связанных с
ошибочными действиями пользователей, необходимо предусмотреть защиту
от применения ошибочных действий по удалению и порче данных.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Под информационной безопасностью (ИБ) АИС понимается состояние
защищенности информационной среды АИС, обеспечивающее её
формирование, использование и развитие, которое не приводит к искажению,
разрушению или несанкционированному использованию информационных
ресурсов, включая хранимую, обрабатываемую и передаваемую
информацию, а также программные средства.
Выделяют следующие основные цели ИБ:
♦ конфиденциальность (доступность информации только
определенному кругу лиц);
♦ доступность (возможность получения информации авторизованными
пользователями в нужное для них время);
♦ целостность (гарантия существования информации в неискаженном,
истинном виде).
Информация, обрабатываемая и сохраняемая в, является ценной:
- технологическая – это наличие на складе товаров различных
категорий; их размещение, остаток, кому предназначаются. Эта информация
не является конфиденциальной, но в любой момент она должна быть