48
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Жизненный цикл программного обеспечения – это интервал времени,
который берёт начало в момент принятия решения о создании какого-либо
программного продукта и заканчивается в тот момент, когда этот программный
продукт полностью изымается из эксплуатации. Этапы создания системы до
момента ввода в эксплуатацию могут рассматриваться как самостоятельные
проекты, каждый из которых имеет конкретный результат и ограничения.[14]
А так как процесс создания и конфигурирования для различных
информационных систем включает в себя один набор этапов, то можно говорить
о моделях жизненного цикла.
Модель жизненного цикла программного обеспечения принято называть
некую структуру, которая содержит процессы действия и задачи, которые
необходимо осуществить в ходе разработки, использования, а также
сопровождения информационной системы.[15]
Сами фазы жизненного цикла фиксированы и для различных отраслей
человеческой деятельности, по сути, одинаковы:
Планирование проекта;
Анализ и постановка задачи;
Проектирование;
Разработка;
Развертывание и внедрение;
Эксплуатация;
Поддержка;
Модернизация;
Утилизация.
49
Важно понимать, что переход на новые программные решения – это не
утилизация старой и проектирование новой системы.
В настоящее время следующие модели жизненного цикла стали наиболее
распространёнными:
Каскадная модель;
Каскадная модель с промежуточным контролем;
Спиральная модель;
Модель разработки через тестирование.
Каскадная модель.
Каскадная модель жизненного цикла, также называемая моделью
«водопада», была разработана еще в 80-х годах, и на протяжении многих лет она
считалась стандартом для разработки ПО. Данная модель характеризуется тем,
что этапы строго последовательны и переход между ними невозвратный. Это
означает, что в рамках каскадной модели переход к следующему этапу (например,
от проектирования и сбора требований к разработке и развертыванию) может
произойти только по завершении предыдущего этапа. Модель «водопада» была
применена одной из первых и одно из ее основных достоинств в возможности
планирования сроков и стоимости каждого этапа – однако, на практике разработка
системы почти никогда не проходит строго в соответствии с жесткой заранее
продуманной схемой. В частности, это касается сбора требований, так как реально
при старте проекта требования бывают определены только частично и в
дальнейшем уточняются, изменяются и дополняются. К тому же, если изначально
требования были определены неточно, высока вероятность того, что система не
будет удовлетворять потребностям заказчика.
На рисунке 17 изображена схема каскадной модели.
50
Рис. 17 - Каскадная модель жизненного цикла.
Каскадная модель с промежуточным контролем.
В качестве одной из вариаций каскадной модели для того, чтобы
предусмотреть возможность возвращения к предыдущим этапам для внесения
определенных изменений и пересмотра отдельных вопросов, была создана
каскадная модель с промежуточным контролем.
Она предполагает увеличенное время, отведенное на разработку, за счет
проведения промежуточных корректировок между фазами жизненного
цикла. В свою очередь, это снижает риски получения некачественного продукта
на выходе и повышает надежность системы в целом.
Важно отметить, что согласование результатов в двух описанных моделях
происходит только по окончании внедрения – а значит, повышается вероятность
получения программного продукта, который морально устареет либо не будет
востребован рынком. Еще больше увеличивают риски возможные неточности в
51
исходном техническом задании. В итоге можно говорить о проблеме
определенной задержки в получении результата, которая не может быть решена в
«каскадном» варианте разработки и внедрения системы.
На рисунке 18 изображена схема каскадной модели с промежуточным
контролем.
Рис. 18 - Каскадная модель с промежуточным контролем.
Спиральная модель.
Для нивелирования рисков, связанных с вышеописанной проблемой, была
создана спиральная модель. Фазы жизненного цикла непоследовательны, то есть
допустимо начало работ над следующим этапом до завершения предыдущего.
Таким образом, суть спиральной модели состоит в возможности прохождения
всех этапов жизненного цикла системы в несколько итераций, каждый раз
создавая новый прототип и проверяя актуальность требований, по которым он
52
создавался, внося технические доработки в интерфейс и функциональность.
Подобная гибкость позволяет использовать модель на предприятиях любого
масштаба.
Это означает, что процесс создания системы и само управление проектом
будет более гибким и управляемым, с совершенствованием системы на каждом
«витке спирали», то есть при выпуске каждой версии. Уменьшаются риски (в том
числе, финансовые) для заказчика и спонсора системы, которые могут отказаться
от проекта еще на этапе показа первого прототипа в случае абсолютного его
несоответствия ожиданиям и потребностям.
Как правило, подобная модель применяется при разработке нетиповых
систем, предоставляя возможность оперативно создать прототип программного
продукта для проверки его работоспособности с пользователями и
соответственно, быстрого получения комментариев и замечаний к системе.
На рисунке 19 изображена схема спиральной модели.
Рис. 19 - Спиральная модель.
Модель разработки через тестирование.
Приближенная по своей сути к практикам PRINCE2, V-модель разработки
через тестирование была разработана еще в конце 1980-х годов ведомствами
Германии и США, и до сих пор является стандартом немецких правительственных
53
и оборонных проектов. Основной ее принцип состоит в постепенном возрастании
степени детализации проекта с течением времени и одновременном проведении
«горизонтальных» итераций. Таким образом, результаты каждой из фаз левой
стороны буквы V влияют на тестирование и компоновку проекта с правой
стороны буквы V: приемосдаточные испытания основываются на проведенном
анализе требований, интеграционное тестирование – на высокоуровневом
описании архитектуры, модульное тестирование – на архитектуре, интерфейсах,
алгоритмах и прочих элементах детализированных требованиях к системе.
Важна гибкость данной модели, так как по сути она адаптируема под любой
тип организации. Промежуточные результаты проверяются на ранних стадиях, и
минимизация рисков достигается благодаря простому соотнесению фаз/итераций.
V-модель не рассматривает непосредственно стадию обслуживания и утилизации,
учитывая лишь активности по подготовке к ним.
Схема модели разработки через тестирование изображена на рисунке 20.
Рис. 20 - Модель разработки через тестирование.
54
Стандарты жизненного цикла.
Среди стандартов, определяющих жизненный цикл программного
обеспечения можно выделить следующие:
ГОСТ 34.601-90 – применим к автоматизированным системам.
Устанавливает этапы создания программного обеспечения. В данном
стандарте имеется описание работ, проводимых на каждом этапе
жизненного цикла. Стандарт является наиболее подходящим для
каскадной модели жизненного цикла.
ISO/IEC 12207:1995 Information Technology – Software Life Cycle
Process – распространяется на все виды программного обеспечения.
Не имеет конкретных описаний стадий разработки.
ISO/IEC 15288 Systems engineering. System life cycle processes –
данный стандарт является наследником предыдущего. Однако, здесь
имеется полное описание процессов и видов деятельности.
Ориентирован в большей степени на оценку процессов и
возможность их улучшения. Описывает 35 процессов и 201 вид
деятельности.
Custom Development Method – данный стандарт разработан Oracle
для Enterprise-решений. Предназначен для так называемой «быстрой
разработки» или «облегчённого подхода» в случае мелких проектов.
Extreme Programming – экстремальное программирование. Суть
заключается в плотном сотрудничестве и коммуникации между
заказчиком и разработчиком на протяжении всего процесса
разработки. Разработка ведётся с использованием последовательно
дорабатываемых прототипов.
Рассмотрев модели разработки, а также стандарты жизненного цикла
можно сделать вывод, что поскольку задача, решаемая в рамках данного проекта,
возможно, будет развиваться в дальнейшем, то разумно применить спиральную
модель разработки. Что касается стандартов, то в данном случае будет
использоваться экстремальное программирование, поскольку на постоянной
основе заказчику даётся последняя версия ПО, в которой по мере замечаний, в
55
последующем, дополняется и дорабатывается функционал. И это происходит
вплоть до финальной версии ПО.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
На различных этапах жизненного цикла информационной системы
существует вероятность возникновения различных рисков. Пренебрежение
данного факта может пагубно повлиять на процесс разработки. Для
минимизирования рисков предварительно проводится их оценка, а также
разрабатываются способы их устранения.
Управление рисками – систематический процесс снижения
неопределённости и управления вероятностью событий в проекте.
Целью управления рисками является снижение неблагоприятных событий
на проект в целом.
Для управления рисками необходимо планирование реагирования на риски
– анализ и разработка возможных вариантов и действий, которые способны
повлиять на повышение благоприятных возможностей и снизить возможные
угрозы для достижения целей проекта (Рисунок 21).[16]
Рис. 21 - Управление рисками.
56
Рассмотрим самые вероятные риски, способные усложнить разработку
информационной системы в данной работе.
Как уже писалось ранее, весь жизненный цикл программного продукта
состоит из следующих этапов:
Планирование проекта;
Анализ и постановка задачи;
Проектирование;
Разработка;
Развертывание и внедрение;
Эксплуатация;
Поддержка;
Модернизация;
Утилизация.
Фаза планирования проекта.
На фазе планирования проекта существует риск изначально ошибочного
решения создания того или иного программного продукта.
Для исключения данной вероятности требуется тщательный анализ бизнес-
процесса, в общем и целом. Если брать в расчёт непосредственно данный проект,
то необходимо выявление точной причины фактора, замедляющего бизнес-
процесс. В данном случае – это мониторинг цен конкурентов.
Анализ и постановка задачи.
На этом этапе существует риск ошибочного выбора решения проблемы,
выявленной на этапе планирования проекта.
Для минимизации этого риска требуется тщательный анализ выбранного
решения. Необходимо учесть максимальное число нюансов, а также убедиться в
правильности задачи.
57
Проектирование.
Один из самых ответственных этапов. На этом этапе существует риск
выбора неверной архитектуры будущего приложения.
Появление этого риска зависит исключительно от компетентности
руководителя проекта. Т.е. он должен понимать, почему будущее приложение
должно работать именно так, как он планирует, и никак иначе.
Разработка.
На данном этапе число рисков значительно выше, чем на предыдущих:
Риск неправильной интерпретации технического задания;
Риск сдвига сроков;
Риск недостаточного опыта программиста для решения конкретной
задачи.
Кроме того, первые два пункта в данной группе могут быть следствием
последнего. В свою очередь, первый пункт может быть следствием предыдущих
этапов.
Для предотвращения этих рисков следует более тщательно
проанализировать будущий проект и, возможно, вернуться к этапу
проектирования и рассмотреть его более детально. Программист, в свою очередь,
должен оценивать сложность отдельно взятых элементов проекта, а также быть
готовым к альтернативным методам решения одних и тех же задач.
Развертывание и внедрение.
Риски, возможные на данном этапе могут быть следствием проектирования
и разработки. В первую очередь – это риск отказа работоспособности
информационной системы на конкретном рабочем месте.
В случае с Java этот риск практически равен нулю. Однако, следует
заблаговременно оценить будущие системные требования разрабатываемой
информационной системы и сравнить с имеющейся или требуемой аппаратной и