51
отражает структуру ЖЦ, включающую в себя процессы, действия и задачи,
реализуемые за время разработки ПО.
Любой такой процесс определяется некоторыми задачами и методами их
решения, начальными данными, приобретенными на предыдущем этапе, и
результатами. Итогами анализа, у примеру, становятся функциональные и
информационные модели, а также соответствующие им диаграммы. ЖЦ ПО носит
итерационный характер: итоги прошедшего этапа влекут изменения в проектных
решениях, основанных на более ранних этапах.
ЖЦ информационных продуктов и услуг является базой для ЖЦ
информационных технологий и, конечно, самих ИС. Следовательно, всё
вышесказанное можно отнести и к ИС.
ИС включены в состав СУБД и являются узконаправленным
инструментальным и прикладным (пользовательским) ПО.
Модель жизненного цикла ПО отражает структуру, определяющую
последовательность реализации и взаимосвязь процессов, действий и задач в
рамках всего ЖЦ. Модель ЖЦ зависит от специфики, масштаба и трудности
проекта и конкретных условий, в которых система развивается и работает.
Сегодня наибольшее распространение получили три базовые модели ЖЦ:
Задачная модель;
Каскадная модель (70-85 г.г.);
Спиральная модель (сегодняшние дни).
ЖЦ программных средств (ПС) обычно представляет собой набор этапов,
работ и операций в порядке их реализации и взаимосвязях, определяющих
ведение работ от составления технического задания до финальных испытаний
ряда версий и завершения эксплуатации ПС или ИС. Подобные стандарты состоят
из правил описания начальной информации, методики выполнения операций,
осуществляют контроль технологических процессов и правил представления их
результатов. Еще они определяют содержание технологических и
эксплуатационных документов на комплексы ПО. Они выражают
организационную структуру коллектива, поддерживают распределение и
планирование заданий, реализуют контроль над этапами разработки комплекса
ПС.
52
Для составления жизненных циклов (ЖЦ) ИС был выбран стандарт ISO
12207, как стандарт, включающий в себя большинство автоматизированных
систем (АС) и ПС, где ПС – малая часть всего плана работ. Международный
стандарт ISO/IEC 12207 показывает стратегию и общий порядок в разработке и
использовании ПО, он охватывает ЖЦ ПО от зарождения идей до окончания
цикла. Определение стандарта: система — это совокупность одного или более
процессов, аппаратных средств, ПО, оборудования и людей для реализации
возможности удовлетворения конкретных потребностей или целей.
В отличие от Oracle CDM стандарт ISO 12207 одинаково нацелен на
организацию действий каждой из двух сторон: поставщик (создатель) и
покупатель (клиент). Применяется в разных случаях, даже когда обе стороны
внутри одной компании. В отличии от CDM, стандарт ISO состоит из более
крупных обобщенных процессов: «покупка», «доставка», «создание» и т.п. Любой
процесс разделен на набор действий, а каждое действие — на совокупность задач.
Важно одно отличие ISO: любой процесс, действие или задача определяется и
реализуется другим процессом по мере необходимости, причем нет ранее
заданных последовательностей (конечно, в рамках сохранения логики связей по
начальным сведениям задач и т.п.).
Развивающийся характер стандарта зависит от способа выражения
последовательности выполнения процессов и задач, когда один процесс в случае
необходимости вызывает другой или его часть. Стандарт отражает архитектуру,
процессы, разделы и подразделы ЖЦ ПС, а также указывает список необходимых
работ и подробно описывает содержание каждой из них. Архитектура ЖЦ ПС в
стандарте основывается на 3 основных компонентах:
Покупка или поставка,
Создание,
Использование.
Стандарт не включает конкретные методы действий, а также заготовки
решений или документации. Он отражает архитектуру процессов ЖЦ ПО, но не
углубляется в детали реализации или выполнения услуги и задачи, включенных в
процессы. Стандарт не указывает конкретную модель ЖЦ или метод создания ПО,
но показывает, что стороны участники использования стандарта несут
53
ответственность за выбор модели ЖЦ для проекта ПО, за подгонку процессов и
задач стандарта к этой модели, за обоснованный выбор и использование методов
создания ПО, за реализацию действий и задач, уместных для проекта ПО.
Покупка или поставка. Цель этапа – предложение разработчику от
заказчика, на выполнение автоматизированной системы. На этом этапе
заключается договор, корректируются его условия и требования. Участники этапа
– ответственный от лица заказчика, который контролирует и уточняет направления
для разработчиков. А так же менеджер проекта от лица разработчиков. Он
принимает от заказчика требования, подписывает договор, и согласует начальные
установки и задачи для работы. На этом этапе заказчик должен предоставить
развернутое техническое задание (ТЗ), менеджер утверждает его, уточняются
некоторые детали задания и согласовываются средние сроки выполнения
разработки.
Создание. Создание ПО разбито на множество небольших этапов,
призванных обеспечить создание ИС, отвечающей требованиям заказчика, и в
договоренные сроки:
Исследование требований к системе;
Построение системной архитектуры;
Исследование требований к ПС;
Построение архитектуры ПС;
Детальное проектирование ПС;
Реализация и тестирование ПС;
Внедрение ПС;
Квалификационная проверка системы;
Начало эксплуатации ПС;
Финальная приемка ПС.
Основные участники на этом этапе – это менеджер проектов и
непосредственные разработчики. Сам менеджер разбивает задачу разработки ПС
на вышеперечисленные этапы, следит за их выполнением, контролирует ход
выполнения за каждым разработчиком. При необходимости сам участвует в
разработке или координации действий между отдельными разработчиками.
Определяет участки работы для каждого отдельного разработчика в зависимости
54
от квалификации и опыта, определяет степень универсальности взаимодействия
отдельных частей ПС, разрешает коллизии и спорные моменты.
Разработчики принимают план работ, поле деятельности и конкретные
задачи для выполнения. Определяют для себя методы решения своих задач,
согласовывают пути взаимодействия с программными частями других
разработчиков, спецификации функций, протоколов передачи данных, и др.
Использование. На этом этапе проводятся тестовые испытания ПС,
определяются сильные и слабые моменты, недоработки, и слаженность работы
всех компонентов. При выявлении недоработок определяются перечень указаний
для исправлений разработчиками.
Существует несколько различных стратегии внедрения системы:
1) Стратегия “Параллельное использование” предполагает параллельное
выполнение старой и новой технологии решения задачи, их результаты
сравниваются. Если результаты сравниваются длительное время, то реализуется
переход на новую технологию.
Положительные стороны:
• Отсутствие риска ошибок в виде новых технологий;
• Внедрением ИС можно заниматься независимо от обычного
операционного планирования фирмы.
Негативные стороны:
• Сильная загрузка персонала;
• Необходимость удвоения мощности серверов;
• Необходимость сверки результатов деятельности двух технологий.
2) Стратегия “Скачек” – это не новая технология, и работает она до
определенного момента, затем реализуется внедрение новой технологии, а затем
уже используется только новая технология.
Положительные стороны:
• Почти незаметный переходный период;
• Отсутствие двойных затрат на деятельность компании;
• Новые процессы более оптимальны поскольку нет переходного
периода.
Негативные стороны:
55
• Повышенный риск несоответствия качества ИС требованиям
предприятия;
• Повышенные требования к процессу планирования перехода на
обновленную технологию;
3) Стратегия “Пилотный проект” применяет тактику скачка к некоторому
числу процессов, областью применения зачастую становится небольшой участок.
Положительные стороны:
• Отсутствии риска выбора неверного решения, приводящего к
длительному простою всего предприятия;
• Доступность изменения планируемой технологии в процессе
установки ИС на участке;
• Отсутствие двойных затрат на реализацию проекта.
Негативные стороны:
• Запутанное объединение информационных потоков, составляемых
по старой и новой технологии;
• Одновременное управление и старой, и новой ИС.
4) Стратегия “Узкое место” автоматизирует малую часть производственного
процесса, который зачастую выбирается по критериям эффективности,
приводящих к увеличению качества внедрения процессов только выделенном
узком месте.
Положительные стороны:
• После окончания автоматизации каждого узкого места можно
прервать автоматизацию;
• Невысокие требования к уровню планирования внедренческих работ.
Негативные стороны:
• Проведение полного цикла планирования на каждом из узких мест –
имея возможность прерывания автоматизации, сам процесс может никогда не
закончится;
• Независимость автоматизации узких мест приводит к созданию
лишнего множества программно-аппаратных решений.
56
Следующим этапом становится этап тестирования системы, в котором
определяются ее недостатки и узкие места, а также реализуются меры по
устранению и модернизации системы.
Использование и обслуживание ИС.
Этап использования и обслуживания системы в динамично развивающемся
предприятии выражает довольно сложную задачу. Обновление программно-
аппаратной части, вызванное физическим и моральным устареванием
компонентов АСУ; важность отслеживания изменений в законодательстве;
требования пользователей по доработке системы под новые функциональные
задачи; реализация безопасности данных в процессе эксплуатации – все эти и
многие другие вопросы периодически возникают перед персоналом,
ответственным за использование и обслуживание системы.
Таким образом, в условиях ограниченного бюджета и начальной стадии
автоматизации логичным будет выбрать стратегию внедрения «Узкое место».
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Данный раздел описывает риски, которые могут возникнуть на этапах ЖЦ
задачи учета поиска радиоэлектронных компонентов для ООО «Торговый Дом
Евразия».. Риском является возможность появления обстоятельств,
обусловливающих неуверенность или невозможность получения ожидаемых
результатов от реализации поставленной цели, нанесение материального ущерба,
опасность валютных потерь и др. Существуют следующие типы рисков:
Проектный тип рисков. В него включены риски, которые связаны с
ошибками в бюджете; в графике работ; с проблемами персонала организации;
риски различных изменений в текущем законодательстве.
Технический тип рисков. К нему относят риски, связанные с проблемами
реализации технических решений и человеческим фактором, а именно риски,
связанные с неспособностью специалистов выполнить необходимую задачу.
Тип бизнес-рисков. Он содержит в себе риски, которые связаны с
финансовой поддержкой задачи учета, или, другими словами, риски сокращения
бюджета, приводящие не только к сокращению проекта и его задач, но и к его
57
полному провалу в случае не достижения основной цели; риск потери интереса к
задаче ведения и учета внутренних заказов оборудования со стороны конечных
пользователей, риски при оценке рынка данного вида учета. Данный тип рисков
невозможно исключить, но его можно минимизировать.
Чтобы уменьшить величину данных типов рисков необходимо иметь
достаточно компетентных и квалифицированных сотрудников, имеющих большой
опыт работы в соответствующей области и при этом взаимозаменяемых на
сотрудников, не менее соответствующих данным характеристикам (таблица 2.1).
Таблица 2.1
Характеристики дефектов программного продукта
Этапы возникновения дефектов и ошибок
Типы первичных
дефектов и ошибок
программного средства
и документации
Формирование
требований
Разработка требований к
ПО
Дефекты исходных
требований заказчика
Проектирование
Планирование работ
Дефекты,
обусловленные
реальной сложностью
проекта
Проектирование
архитектуры системы
Ошибки планирования
и системного
проектирования
программного средства
Детальное
проектирование ПО
Системные и
алгоритмические
дефекты и ошибки
проекта
Реализация
Кодирование ПО
Программные дефекты
и ошибки компонентов
и документов
программного средства
Тестирование
Тестирование ПО
Программные и
алгоритмические
ошибки программного
средства и
документации
Ввод в действие
Разработка
документации
Дефекты и ошибки
обобщающих
документов
Эксплуатация и
сопровождение
Эксплуатация ПО
Программные дефекты.
58
Ниже представлены риски в зависимости от этапов жизненного цикла, а
также приведены методы их предотвращения.
Этап подготовки проекта
Риск персонала
Риски:
• Набор необученного персонала к выполнению проекта;
• Набор в состав разработчиков «случайных» сотрудников, а не
главных участников автоматизируемых бизнес процессов;
• Неимение выработанной стратегии автоматизации№
• Отсутствие общих целей и задач проекта;
• Отсутствие мотивационных поощрений сотрудникам;
• Нежелание персонала участвовать в проекте;
• Хаотичный план ведения работ.
Методики предотвращения:
• Постоянное взаимодействие с руководством в процессе всего
проекта, оперативное принятие решений;
• Привлечение к проекту ведущих специалистов и консультантов;
• Четкая формулировка целей и задач;
• Выработка единой стратегии автоматизации компании;
• Неизменный состав рабочей группы во время подготовки проекта.
Риск ведения проекта
Риски:
• Ошибочное определение рамок и масштаба проекта;
• Выделение ошибочных функций системы;
• Подбор неверных технологий и методов решений задач;
• Несоблюдение приведенных заказчиком требований.
Методики предотвращения:
• Поддержка стабильности границ проекта, которые выделяются еще
на начальном этапе и неизменны вплоть до финала проекта;
• Точное планирование выполняемых работ;
• Включение в проект необходимых ресурсов;
59
• Согласованное и утвержденное проектное решение;
• Высокий порог принятия изменений.
Риск неверного планирования
Риски:
• Неэффективный план организации разработки системы;
• Несоблюдение сроков выполнения работ по этапам.
Методики предотвращения:
• В начальных стадиях проекта проведение учета, организация
командной работы, выделение ролей и стимулирование;
• Описание и сохранение всех проведенных работ и открытый доступ
к этим данным для всех участников проекта.
Этап разработки
Риск персонала
Риски:
• Увольнение сотрудников, которые отвечают за проведение
разработки;
• Несогласованность действий между участниками проекта из-за
плохой системы коммуникации;
• Ошибочное представление задачи проектирования;
• Набор разработчиком без опыта работы с подобными системами.
Методики предотвращения:
• Грамотный набор сотрудников, участвующих в проекте;
• Реализация четкой системы коммуникации между сотрудниками,
постоянное документирование изменений в системе.
Технические риски
Риски:
• Остановка разработки из-за ошибок в применяемом ПО;
• Пользовательская документация включает в себя описание не всех
функции системы.
Методики предотвращения:
• Работа только с проверенным лицензионным ПО, регулярное
резервное копирование данных;
60
• Отслеживание полноты сведений во всех документах.
Этап внедрения
Риск персонала
Риски:
• Разрозненность деятельности разработчика и специалистов
предметной области;
• Отсутствие желания у сотрудников использовать новую систему и
связанные с этим трудности их обучения;
• Безучастность руководства.
Методики предотвращения:
• Обучение пользователей со стороны заказчика методики работы с
системой;
• Подготовка плана внедрения системы;
• Обоснование важности и нужности автоматизации персоналу;
• Привлечение руководящего персонала в проект и активное
взаимодействие с ним во время проведения всего проекта.
Технические риски
Риски:
• Утрата информации при внедрении системы.
Методики предотвращения:
• Наем квалифицированных сотрудников, имеющих опыт разработки
подобных систем.
Этап эксплуатации и сопровождения
Технические риски
Риски:
• Баги и ошибки ПО, приводящие к невозможности использования
системы;
• Неправильное использование оборудования;
• Отсутствие функциональных возможностей системы из-за
реорганизации предприятия.
Методики предотвращения: