71
2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл программного обеспечения (ПО) определяет период
времени, наступающий с момента принятия решения о важности разработки
ПО и оканчивающийся в момент его фактического изъятия из пользования.
Этот цикл — процесс создания и эволюции ПО.
Понятие ЖЦ ПО пришло тогда, когда разработчики осознали
важность перехода от единоличных кустарных методов разработки
программ к технологичному промышленному их созданию. И зачастую в
подобных ситуациях многие пытаются перенести в свою сферу опыт их
других направлений производства. Таким образом было перенято понятие
ЖЦ.
Главные этапы ЖЦ ПО:
• Исследование требований,
• Построение макета,
• Программирование,
• Отладка и исправление ошибок,
• Внедрение и использование.
Нюансом разработки ПО становится принятие решений на первичных
этапах с их реализацией на заключительных этапах. Ошибки в требованиях
к ПО могут привести не только к потерям в процессе создания и
использования, но и к полному провалу проекта. Корректировка и
изменения в спецификациях ПО зачастую влечет за собой повторение всех
следующих этапов построения модели и реализации ПО.
Сам ЖЦ ПО является непрерывным процессом, начинающимся в
момент принятия решения о важности его создания и оканчивающимся в
момент его окончательного выведения из эксплуатации.
72
Главный нормативный документ, контролирующий ЖЦ ПО –
международный стандарт ISO/IEC 12207 (ISO, International Organization of
Standardization – Общемировая компания по стандартизации, IEC,
International Electrotechnical Commission – Международная коллегия по
электротехнике). Он отражает структуру ЖЦ, включающую в себя
процессы, действия и задачи, реализуемые за время разработки ПО.
Любой такой процесс определяется некоторыми задачами и методами
их решения, начальными данными, приобретенными на предыдущем этапе,
и результатами. Итогами анализа, к примеру, становятся функциональные и
информационные модели, а также соответствующие им диаграммы. ЖЦ ПО
носит итерационный характер: итоги прошедшего этапа влекут изменения в
проектных решениях, основанных на более ранних этапах.
ЖЦ информационных продуктов и услуг является базой для ЖЦ
информационных технологий и, конечно, самих ИС. Следовательно, всё
вышесказанное можно отнести и к ИС.
ИС включены в состав СУБД и являются узконаправленным
инструментальным и прикладным (пользовательским) ПО.
Модель жизненного цикла ПО отражает структуру, определяющую
последовательность реализации и взаимосвязь процессов, действий и задач
в рамках всего ЖЦ. Модель ЖЦ зависит от специфики, масштаба и
трудности проекта и конкретных условий, в которых система развивается и
работает.
Сегодня наибольшее распространение получили три базовые модели
ЖЦ:
• Задачная модель;
• Каскадная модель (70-85 г.г.);
• Спиральная модель (сегодняшние дни).
ЖЦ программных средств (ПС) обычно представляет собой набор
этапов, работ и операций в порядке их реализации и взаимосвязях,
определяющих ведение работ от составления технического задания до
73
финальных испытаний ряда версий и завершения эксплуатации ПС или ИС.
Подобные стандарты состоят из правил описания начальной информации,
методики выполнения операций, осуществляют контроль технологических
процессов и правил представления их результатов. Еще они определяют
содержание технологических и эксплуатационных документов на
комплексы ПО. Они выражают организационную структуру коллектива,
поддерживают распределение и планирование заданий, реализуют контроль
над этапами разработки комплекса ПС.
Для составления жизненных циклов (ЖЦ) ИС был выбран стандарт
ISO 12207, как стандарт, включающий в себя большинство
автоматизированных систем (АС) и ПС, где ПС – малая часть всего плана
работ. Международный стандарт ISO/IEC 12207 показывает стратегию и
общий порядок в разработке и использовании ПО, он охватывает ЖЦ ПО от
зарождения идей до окончания цикла. Определение стандарта: система —
это совокупность одного или более процессов, аппаратных средств, ПО,
оборудования и людей для реализации возможности удовлетворения
конкретных потребностей или целей.
В отличие от Oracle CDM стандарт ISO 12207 одинаково нацелен на
организацию действий каждой из двух сторон: поставщик (создатель) и
покупатель (клиент). Применяется в разных случаях, даже когда обе
стороны внутри одной компании. В отличии от CDM, стандарт ISO состоит
из более крупных обобщенных процессов: «покупка», «доставка»,
«создание» и т.п. Любой процесс разделен на набор действий, а каждое
действие — на совокупность задач. Важно одно отличие ISO: любой
процесс, действие или задача определяется и реализуется другим процессом
по мере необходимости, причем нет ранее заданных последовательностей
(конечно, в рамках сохранения логики связей по начальным сведениям задач
и т.п.).
Развивающийся характер стандарта зависит от способа выражения
последовательности выполнения процессов и задач, когда один процесс в
74
случае необходимости вызывает другой или его часть. Стандарт отражает
архитектуру, процессы, разделы и подразделы ЖЦ ПС, а также указывает
список необходимых работ и подробно описывает содержание каждой из
них. Архитектура ЖЦ ПС в стандарте основывается на 3 основных
компонентах:
• Покупка или поставка,
• Создание,
• Использование.
Стандарт не включает конкретные методы действий, а также
заготовки решений или документации. Он отражает архитектуру процессов
ЖЦ ПО, но не углубляется в детали реализации или выполнения услуги и
задачи, включенных в процессы. Стандарт не указывает конкретную модель
ЖЦ или метод создания ПО, но показывает, что стороны участники
использования стандарта несут ответственность за выбор модели ЖЦ для
проекта ПО, за подгонку процессов и задач стандарта к этой модели, за
обоснованный выбор и использование методов создания ПО, за реализацию
действий и задач, уместных для проекта ПО.
Покупка или поставка. Цель этапа – предложение разработчику от
заказчика, на выполнение автоматизированной системы. На этом этапе
заключается договор, корректируются его условия и требования. Участники
этапа – ответственный от лица заказчика, который контролирует и уточняет
направления для разработчиков. А также менеджер проекта от лица
разработчиков. Он принимает от заказчика требования, подписывает
договор, и согласует начальные установки и задачи для работы. На этом
этапе заказчик должен предоставить развернутое техническое задание (ТЗ),
менеджер утверждает его, уточняются некоторые детали задания и
согласовываются средние сроки выполнения разработки.
Создание. Создание ПО разбито на множество небольших этапов,
призванных обеспечить создание ИС, отвечающей требованиям заказчика,
и в договоренные сроки:
75
• Исследование требований к системе;
• Построение системной архитектуры;
• Исследование требований к ПС;
• Построение архитектуры ПС;
• Детальное проектирование ПС;
• Реализация и тестирование ПС;
• Внедрение ПС;
• Квалификационная проверка системы;
• Начало эксплуатации ПС;
• Финальная приемка ПС.
Основные участники на этом этапе – это менеджер проектов и
непосредственные разработчики. Сам менеджер разбивает задачу
разработки ПС на вышеперечисленные этапы, следит за их выполнением,
контролирует ход выполнения за каждым разработчиком. При
необходимости сам участвует в разработке или координации действий
между отдельными разработчиками. Определяет участки работы для
каждого отдельного разработчика в зависимости от квалификации и опыта,
определяет степень универсальности взаимодействия отдельных частей ПС,
разрешает коллизии и спорные моменты.
Разработчики принимают план работ, поле деятельности и
конкретные задачи для выполнения. Определяют для себя методы решения
своих задач, согласовывают пути взаимодействия с программными частями
других разработчиков, спецификации функций, протоколов передачи
данных, и др.
Использование. На этом этапе проводятся тестовые испытания ПС,
определяются сильные и слабые моменты, недоработки, и слаженность
работы всех компонентов. При выявлении недоработок определяются
перечень указаний для исправлений разработчиками.
На настоящий момент существуют такие модели жизненного цикла,
как каскадная, поэтапная с промежуточным контролем, спиральная.
76
В спиральной модели особое внимание уделяется начальным этапам
разработки – выработке стратегии, анализу и проектированию, где
реализуемость тех или иных технических решений проверяется и
обосновывается посредством создания прототипов (макетирования).
Каждый виток спирали предполагает создание фрагмента (компонента) или
версии программного продукта. На них уточняются цели и характеристики
проекта, определяется его качество и планируются работы следующего
витка спирали. Таким образом углубляются и последовательно
конкретизируются детали проекта и в результате выбирается обоснованный
вариант, который доводится до реализации.
Для разрабатываемого проекта наиболее подойдет каскадная модель
для разработки приложения из-за возможности контроля промежуточных
фаз.
Далее произведем выбор стратегии внедрения разработанной
системы. В настоящий момент выделяется четыре стратегии внедрения
информационной системы:
• Параллельная стратегия - для случая, когда старую работающую
систему необходимо заменить новой;
• Скачок – эта стратегия подразумевает резкий переход от одной
системы автоматизации к другой;
• Опытная эксплуатация "пилотного проекта - это тактика
"скачка", но применяемая к ограниченному числу изделий, наиболее
успешна в малом участке деятельности;
• Узкое место - при внедрении "узкого места" план внедрения
выполняется только для "узкого места" и для людей, работающих в нем.
Исходя из описания и условий деятельности компании, а также
особенностей разрабатываемой информационной системы, в качестве
стратегии внедрения была выбрана стратегия Опытная эксплуатация
пилотного проекта, так как в этом случае внедрение системы произойдет
наиболее безболезненно.
77
2.1.2 Ожидаемые риски на этапах жизненного цикла и их
описание
Любой сложный проект, а особенно проект разработки программного
обеспечения, содержит в себе много неопределенных моментов, которые
влекут за собой риски реализации проекта.
Управление рисками заключается в их раннем выявлении и
разработке мер, либо полностью предотвращающих их возникновение, либо
минимизируют их последствия.
В настоящее время существует три общепринятых стратегии
управления рисками:
• Избегание рисков – проект реорганизуется таким образом,
чтобы исключить возможность возникновения рисков;
• Делегирование рисков – проект реорганизуется таким образом,
чтобы переложить риски на третью сторону (заказчика, банки, вендора и
т.п.);
• Принятие рисков – риски признаются в качестве неизбежной
составляющей проекта, проводится постоянный мониторинг симптомов их
наступления, постоянно корректируется план действий в случае
наступления рисков.
Различают две основные категории рисков – прямые и
опосредованные. На прямые риски проектная команда может каким-то
образом повлиять, а опосредованные риски команда контролировать не
может в принципе.
Риски можно разделить на отдельные основные виды.
Ресурсные риски:
• Организация (делала ли организация ранее проекты такого
масштаба, есть ли формальный процесс создания ПО и т.п.);
78
• Инвестиции (достаточно ли денежных средств для развития
проекта, указана ли стоимость проекта или она еще находится в процессе
обсуждения, верно ли проведена оценка затрат и т.п.);
• Коллектив (хватает ли людей для выполнения проекта, имеют
ли они необходимые навыки и опыт, могли ли они участвовать в других
проектах вместе раньше и т.п.);
• Время (адекватен ли план проекта, как важна дата завершения
проекта и т.п.);
• Бизнес (что случится, если конкурент представит на рынке
аналогичный товар первым, прибыль, полученная от реализации проекта
будет выше, чем затраты на него, что случится, если основные поставщики
не будут соблюдать свои обязательства и т.п.).
Технические риски:
• Рамки действия проекта (могут ли быть отражены критерии
успешного окончания проекта, все требования конечны и отлично поняты,
рамки работы жестко фиксированы или поддерживают расширение в
будущем и т.п.);
• Технологии (устойчива ли используемая технология или она
только недавно создана и т.п.);
• Внешние зависимости (связан ли проект ос другими
параллельными проектами, зависит ли успех проекта от сторонних
поставщиков продуктов или технологий и т.п.).
В данном проекте можно выделить следующие основные риски на
каждом этапе жизненного цикла (таблица 9).
Таблица 9 Основные риски на этапах жизненного цикла
информационной системы
Этап
Риск
Мероприятия
Заказ
Несоответствие выделенного
бюджета масштабу проекта
Переговоры по увеличению
бюджета или отказ от участия
в проекте
79
Заказ
Неформализуемая задача
(невозможно
автоматизировать те или иные
бизнес-процессы или
стоимость такой
автоматизации превысит
ожидаемую выгоду)
Пересмотреть область
действия проекта с целью
выделения отдельных задач,
поддающихся автоматизации.
Провести детальный анализ
бизнес-процессов и
предложить комплекс
мероприятий по их
реорганизации.
Проектирование
- неправильное определение
рамок и масштабов проекта;
- проектирование ошибочных
функций и интерфейсов
будущей системы;
- выбор неправильных
технологий и методов
решения поставленных задач;
- несоблюдение требований
заказчика при
проектирование будущей
системы или постоянное
изменение требований.
- обеспечение стабильности
границ проекта, определенных
на начальном этапе, вплоть до
окончания проекта;
- качественное планирование
работ;
- своевременная
идентификация проектных
рисков и разработка
рекомендаций по снижению
рисков;
- обеспечение проекта
необходимыми ресурсами;
- обязательное утверждение и
согласование по проектным
решениям
Разработка
Недостаточно ресурсов для
выполнения комплексного и
нагрузочного тестирования
Заключить договор со
специализированной
организацией на выполнение
ею этих работ.
Недостаточно опыта у
персонала заказчика, который
будет эксплуатировать
систему
Предоставить заказчику
услуги собственного
специалиста для
первоначального
сопровождения системы и
постепенного обучения
персонала заказчика.
Внедрение
- увеличение нагрузки на
персонал;
- несогласованность действий
персонала исполнителя и
сотрудников предметных
областей
- проведение обучения
персонала заказчика работы с
системой;
- составление плана
внедрения ИС
Также в процессе использования и сопровождения созданной ИС
возникают:
• технические риски;
• риски персонала.
Причинами технических рисков становятся:
80
• Ошибки в ПО, вызывающие остановку системы;
• Недоступность реализации требуемых действия, «зависание»
программы;
• Применение вредоносных программ (логические бомбы,
вирусы, трояны, черви, шифровальщики), активированные в корыстных
целях внутри найденных ошибок (дыр) в ПО,
• Перехват данных по сетям связи, воровство данных;
• Неправильная эксплуатация оборудования;
• Проблемы в работе третьего лица (к примеру, провайдера
Интернет услуг), что влечет за собой недоступность передачи отчетов из
филиалов и контроля работы филиалов;
• Расхождение функциональных возможностей системы текущим
бизнес-процессам в комплекс задач ввиду проведенных реорганизационных
изменений.
Минимизировать данные обстоятельства можно, соблюдая некоторые
моменты:
• Подробное тестирование и выявление ошибок на этапе создания
проекта;
• Устранение всех недочетов и ошибок в минимальные сроки
силами прошедших подготовку на этапе внедрения технических
специалистов;
• Сам администратор сети обязан следить за безопасностью
данных, применять и вовремя обновлять антивирусное ПО, грамотно
настроить FireWall, разделяющий локальную и внешнюю сеть, давать
работникам компании возможность работы только с той информацией,
которая им нужна для реализации своих служебных обязанностей;
• Разделение клиентского и серверного оборудования, а также
привлечение обученного работе с системой опытного персонала;
• Доступность альтернативных средств выхода в Интернет или
наличие других способов отправки информации;