58
отражает структуру ЖЦ, включающую в себя процессы, действия и задачи,
реализуемые за время разработки ПО.
Исходя их этого стандарта, структура ЖЦ ПО основана на 3 группах
процессов:
Рисунок 2.1 Процессы ЖЦ ПО
Любой такой процесс определяется некоторыми задачами и методами их
решения, начальными данными, приобретенными на предыдущем этапе, и
результатами. Итогами анализа, у примеру, становятся функциональные и
информационные модели, а также соответствующие им диаграммы. ЖЦ ПО носит
итерационный характер: итоги прошедшего этапа влекут изменения в проектных
решениях, основанных на более ранних этапах.
ЖЦ информационных продуктов и услуг является базой для ЖЦ
информационных технологий и, конечно, самих ИС. Следовательно, всё
вышесказанное можно отнести и к ИС.
ИС включены в состав СУБД и являются узконаправленным
инструментальным и прикладным (пользовательским) ПО.
Модель жизненного цикла ПО отражает структуру, определяющую
последовательность реализации и взаимосвязь процессов, действий и задач в
рамках всего ЖЦ. Модель ЖЦ зависит от специфики, масштаба и трудности
проекта и конкретных условий, в которых система развивается и работает.
Сегодня наибольшее распространение получили три базовые модели ЖЦ:
• Каскадная;
59
• Спиральная;
• Итеративная;
• V-Model
ЖЦ программных средств (ПС) обычно представляет собой набор этапов,
работ и операций в порядке их реализации и взаимосвязях, определяющих ведение
работ от составления технического задания до финальных испытаний ряда версий
и завершения эксплуатации ПС или ИС. Подобные стандарты состоят из правил
описания начальной информации, методики выполнения операций, осуществляют
контроль технологических процессов и правил представления их результатов. Еще
они определяют содержание технологических и эксплуатационных документов на
комплексы ПО. Они выражают организационную структуру коллектива,
поддерживают распределение и планирование заданий, реализуют контроль над
этапами разработки комплекса ПС.
Каскадный подход неплохо зарекомендовал себя при создании относительно
простых ИС, когда в самом начале проекта можно очень точно и емко
сформулировать нужные требования к системе. Главным недостатком такого
подходя можно назвать то, что процесс реального создания системы не может
полностью уложится в такую жесткую схему, постоянно есть потребность в
возвращении к предыдущим этапам и просмотре или изменении ранее принятых
решений. В итоге реальный процесс разработки ИС оказывается похож на
поэтапную модель с промежуточным контролем.
Выделяют следующие положительные стороны использования каскадного
подхода:
• Каждый этап включает в себя законченный набор проектной
документации, отвечающий критериям согласованности и полноты;
• Реализуемые в логической последовательности работы дают
возможность планировать сроки завершения всех работ и подсчитывать затраты.
Цикличная модель ЖЦ создавалась для преодоления вышеперечисленных
проблем. На этапах анализа и проектирования степень создания технических
решений и удовлетворенность потребностей заказчика оценивалась методикой
создания прототипов. Каждый цикл характеризовал создание работоспособного
фрагмента или версии программы. Такой подход позволял уточнить требования,
60
цели и параметры проекта, оценить качество разработки, выделить работы
следующего цикла. Таким образом, углубляются и оговариваются детали проекта, и
в результате применяется обоснованный вариант, удовлетворяющий всем
требованиям заказчика, который затем уже доводится до финальной реализации.
Но и такая схема не дает возможности оперативно учитывать возникающие
доработки и изменения требований к системе. Согласование параметров разработки
с пользователями делается только в отдельных точках, планируемых после
завершения некоторого объема работ, а общие требования к ИС отражены в
техническом задании на все время ее создания. Поэтому пользователи часто
получают систему, которая не полностью удовлетворяет их реальным
потребностям.
Итеративная разработка показывает объективно существующий цикл
разработки сложных систем. Она дает возможность переходить на следующий этап,
не дожидаясь окончательного завершения работы на текущем этапе и решить
главную задачу – оперативное и быстрее представить пользователям
работоспособный продукт, тем самым, заранее начиная процесс уточнения
корректировки требований.
V-Model (или VEE модель) является моделью разработки информационных
систем (ИС), направленной на упрощение понимания сложностей, связанных с
разработкой систем. Она используется для определения единой процедуры
разработки программных продуктов, аппаратного обеспечения и человеко-
машинных интерфейсов.
Основной принцип V-образной модели заключается в том, что детализация
проекта возрастает при движении слева направо, одновременно с течением
времени, и ни то, ни другое не может повернуть вспять. Итерации в проекте
производятся по горизонтали, между левой и правой сторонами буквы.
Для составления жизненных циклов (ЖЦ) ИС был выбран стандарт ISO
12207, как стандарт, включающий в себя большинство автоматизированных систем
(АС) и ПС, где ПС – малая часть всего плана работ. Международный стандарт
ISO/IEC 12207 показывает стратегию и общий порядок в разработке и
использовании ПО, он охватывает ЖЦ ПО от зарождения идей до окончания цикла.
Определение стандарта: система — это совокупность одного или более процессов,
61
аппаратных средств, ПО, оборудования и людей для реализации возможности
удовлетворения конкретных потребностей или целей.
В отличие от Oracle CDM стандарт ISO 12207 одинаково нацелен на
организацию действий каждой из двух сторон: поставщик (создатель) и покупатель
(клиент). Применяется в разных случаях, даже когда обе стороны внутри одной
компании. В отличии от CDM, стандарт ISO состоит из более крупных
обобщенных процессов: «покупка», «доставка», «создание» и т.п. Любой процесс
разделен на набор действий, а каждое действие — на совокупность задач. Важно
одно отличие ISO: любой процесс, действие или задача определяется и реализуется
другим процессом по мере необходимости, причем нет ранее заданных
последовательностей (конечно, в рамках сохранения логики связей по начальным
сведениям задач и т.п.).
Развивающийся характер стандарта зависит от способа выражения
последовательности выполнения процессов и задач, когда один процесс в случае
необходимости вызывает другой или его часть. Стандарт отражает архитектуру,
процессы, разделы и подразделы ЖЦ ПС, а также указывает список необходимых
работ и подробно описывает содержание каждой из них. Архитектура ЖЦ ПС в
стандарте основывается на 3 основных компонентах:
Покупка или поставка,
Создание,
Использование.
Стандарт не включает конкретные методы действий, а также заготовки
решений или документации. Он отражает архитектуру процессов ЖЦ ПО, но не
углубляется в детали реализации или выполнения услуги и задачи, включенных в
процессы. Стандарт не указывает конкретную модель ЖЦ или метод создания ПО,
но показывает, что стороны участники использования стандарта несут
ответственность за выбор модели ЖЦ для проекта ПО, за подгонку процессов и
задач стандарта к этой модели, за обоснованный выбор и использование методов
создания ПО, за реализацию действий и задач, уместных для проекта ПО.
Покупка или поставка. Цель этапа – предложение разработчику от заказчика,
на выполнение автоматизированной системы. На этом этапе заключается договор,
корректируются его условия и требования. Участники этапа – ответственный от
62
лица заказчика, который контролирует и уточняет направления для разработчиков.
А так же менеджер проекта от лица разработчиков. Он принимает от заказчика
требования, подписывает договор, и согласует начальные установки и задачи для
работы. На этом этапе заказчик должен предоставить развернутое техническое
задание (ТЗ), менеджер утверждает его, уточняются некоторые детали задания и
согласовываются средние сроки выполнения разработки.
Создание. Создание ПО разбито на множество небольших этапов,
призванных обеспечить создание ИС, отвечающей требованиям заказчика, и в
договоренные сроки:
Исследование требований к системе;
Построение системной архитектуры;
Исследование требований к ПС;
Построение архитектуры ПС;
Детальное проектирование ПС;
Реализация и тестирование ПС;
Внедрение ПС;
Квалификационная проверка системы;
Начало эксплуатации ПС;
Финальная приемка ПС.
Основные участники на этом этапе – это менеджер проектов и
непосредственные разработчики. Сам менеджер разбивает задачу разработки ПС на
вышеперечисленные этапы, следит за их выполнением, контролирует ход
выполнения за каждым разработчиком. При необходимости сам участвует в
разработке или координации действий между отдельными разработчиками.
Определяет участки работы для каждого отдельного разработчика в зависимости от
квалификации и опыта, определяет степень универсальности взаимодействия
отдельных частей ПС, разрешает коллизии и спорные моменты.
Разработчики принимают план работ, поле деятельности и конкретные
задачи для выполнения. Определяют для себя методы решения своих задач,
согласовывают пути взаимодействия с программными частями других
разработчиков, спецификации функций, протоколов передачи данных, и др.
63
Использование. На этом этапе проводятся тестовые испытания ПС,
определяются сильные и слабые моменты, недоработки, и слаженность работы
всех компонентов. При выявлении недоработок определяются перечень указаний
для исправлений разработчиками.
Есть несколько вариантов внедрения системы
Стратегия “Параллельное использование” – предполагает параллельно
выполнять старые и новые технология решения задачи, затем сравнить итоги. Если
итоги согласуются длительное время, то происходит переход на новую
технологию.
Преимущества:
• Малый риск ошибок в рамках новой технологии;
• Контроль внедрения ИС реализуется независимо от классического
планирования компании.
Недостатки:
• Нагрузка персонала в 2 раза больше;
• Большие мощности серверов;
• Постоянная сверка итогов работы двух технологий.
Стратегия “Скачек” – когда старая технология работает до какого-то
момента, а потом сразу делается переход на новую технологию, и по факту
внедрения применяется только новая технология.
Преимущества:
• Очень короткое время переходного периода;
• Отсутствие двойных затрат на деятельность компании;
• Обновленные процессы оптимальные из-за отсутствия переходного
периода.
Недостатки:
• Повышенный риск несоблюдения уровня качества ИС требованиям
компании;
• Повышенные требования к процессу планирования перехода на
обновленную технологию.
64
Стратегия “Пилотный проект” – является тактикой скачка, применяемой к
лимитированному числу процессов, областью использования становится малый
участок.
Преимущества:
• Малый риск выбора ложного решения, которое не приведет к простою
компании;
• Доступность корректировки технологии в рамках внедрения ИС на
участке;
• Нет двойных затрат сразу на 2 технологии.
Недостатки:
• Трудность объединения с информационными потоками,
составленными по старой и новой технологии;
• Важность установки старой и новой ИС сразу.
Стратегия “Узкое место” – является автоматизацией малой части
производства, выбираемой по параметрам эффективности, приводящей к
увеличению качества реализации процессов на конкретном участке.
Преимущества:
• По факту автоматизации узкого места есть возможность закончить
автоматизацию;
• Малые требования к уровню планирования работ установки.
Недостатки:
• Полный цикл планирования по каждому из узких мест;
• Независимость автоматизации узких мест приводит к созданию
избыточного множества решений.
По итогу, в условиях минимального бюджета и начальной стадии
автоматизации будет правильно использовать стратегию «Узкое место».
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Данный раздел описывает риски, которые могут возникнуть на этапах ЖЦ
задачи разработки ИС управления персоналом. Риском является возможность
появления обстоятельств, обусловливающих неуверенность или невозможность
получения ожидаемых результатов от реализации поставленной цели, нанесение
65
материального ущерба, опасность валютных потерь и др. Существуют следующие
типы рисков:
Проектный тип рисков. В него включены риски, которые связаны с
ошибками в бюджете; в графике работ; с проблемами персонала организации;
риски различных изменений в текущем законодательстве.
Технический тип рисков. К нему относят риски, связанные с проблемами
реализации технических решений и человеческим фактором, а именно риски,
связанные с неспособностью специалистов выполнить необходимую задачу.
Тип бизнес-рисков. Он содержит в себе риски, которые связаны с
финансовой поддержкой задачи учета, или, другими словами, риски сокращения
бюджета, приводящие не только к сокращению проекта и его задач, но и к его
полному провалу в случае не достижения основной цели; риск потери интереса к
задаче ведения и учета внутренних заказов оборудования со стороны конечных
пользователей, риски при оценке рынка данного вида учета. Данный тип рисков
невозможно исключить, но его можно минимизировать.
Чтобы уменьшить величину данных типов рисков необходимо иметь
достаточно компетентных и квалифицированных сотрудников, имеющих большой
опыт работы в соответствующей области и при этом взаимозаменяемых на
сотрудников, не менее соответствующих данным характеристикам (таблица 2.1).
Таблица 2.1
Характеристики дефектов программного продукта
Этапы возникновения дефектов и ошибок
Типы первичных дефектов и ошибок
программного средства и
документации
Формирование
требований
Разработка требований
к ПО
Дефекты исходных требований
заказчика
Проектирование
Планирование работ
Дефекты, обусловленные реальной
сложностью проекта
Проектирование
архитектуры системы
Ошибки планирования и системного
проектирования программного
средства
Детальное
проектирование ПО
Системные и алгоритмические
дефекты и ошибки проекта
Реализация
Кодирование ПО
Программные дефекты и ошибки
компонентов и документов
программного средства
66
Тестирование
Тестирование ПО
Программные и алгоритмические
ошибки программного средства и
документации
Ввод в действие
Разработка
документации
Дефекты и ошибки обобщающих
документов
Эксплуатация и
сопровождение
Эксплуатация ПО
Программные дефекты.
На этапе эксплуатации возможны риски, возникающие по причинам:
1) Злоумышленных, активных воздействий заинтересованных лиц. Для
защиты от внешних угроз необходимо применять средства обеспечения защиты
программ и данных (аутентификация пользователей, защита локальной сети при
помощи межсетевых экранов, применение антивирусных программ и пр.).
2) Случайных негативных проявлений внешней среды, дефектов системы
или ошибочных действий пользователей. Основными источниками отказовых
ситуаций могут быть некорректные исходные требования, сбои и отказы в
аппаратуре, дефекты или ошибки в программах и данных функциональных задач,
проявляющиеся при их исполнении в соответствии с назначением. При таких
воздействиях внешняя, функциональная работоспособность систем может
разрушаться не полностью, однако невозможно полноценное выполнение заданных
функций и требований к качеству информации для потребителей.
Для снижения рисков, связанных с дефектами системы, необходимо
проводить тщательное тестирование на контрольных примерах, приближенных к
действительности. Для снижения рисков, связанных с ошибочными действиями
пользователей, необходимо предусмотреть защиту от применения ошибочных
действий по удалению и порче данных.
На стадии доработки могут возникнуть следующие риски:
• увеличение нагрузки на персонал - несогласованность действий
персонала исполнителя и сотрудников предметных областей;
• трудности с обучением персонала заказчика из-за нежелания работать
с новой системой;
• отсутствие поддержки внедрения ИС со стороны отдельных ключевых
участников проекта;
• неучастие руководителей в проекте.
67
Для минимизации указанных рисков необходимо принимать следующие
меры:
• проведение обучения персонала работы с системой;
• доведение до персонала смысла внедрения автоматизированной
системы;
• активное вовлечение высшего руководства в проект, активное
взаимодействие с ним в ходе проекта и своевременное принятие решений,
необходимых для нормальной реализации проекта.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Комплекс мер по защите информации в разрабатываемой системе включает в
себя следующие аспекты:
защита информации непосредственно в информационной системе от
внутренних угроз;
защита информации от внешних угроз.
Для защиты от внутренних угроз в системе используется политика
разделения прав доступа. Характеристика политики приведена в таблице 2.2.
Таблица 2.2
Разграничение прав пользователей
Группы
пользователей
Модуль
«Авторизация»
Модуль
«Регистрация»
Модуль
«Справочники»
Модуль
«Отчеты»
Сотрудники
предприятия
Чтение
Нет
Чтение
Ограничен
Менеджеры
Чтение
Полный
Чтение
Полный
Администратор
системы
Полный
Полный
Полный
Полный
Защита от внешних угроз осуществляется путем применения следующих
способов:
- использованием программно-аппаратных комплексов;
- разработкой и соблюдение политик безопасности;
- использованием защищенных каналов связи при передаче информации;