1.2 Выбор технологии, среды и языка программирования

1.2.1 Выбор модели жизненного цикла

В основе деятельности по созданию и использованию программного обеспечения (ПО) лежит понятие его жизненного цикла (ЖЦ). ЖЦ ПО называют период от момента появления идеи создания некоторого ПО до момента завершения его поддержки фирмой-разработчиком или фирмой, выполнявшей сопровождение [1].

Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ ПО.

К настоящему времени наибольшее распространение получили следующие три основные модели ЖЦ:

• каскадная модель, которая предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке;

• поэтапная модель с промежуточным контролем, состоящая из последовательно расположенных этапов, каждый из которых имеет обратную связь с предыдущими этапами;

• спиральная модель.

В рамках данного дипломного проекта была выбрана именно спиральная модель ЖЦ (рис. 1). В ней результат появляется фактически на каждом витке спирали. Этот результат, который является промежуточным, анализируется, а затем выявленные недостатки продукта становятся поводом для инициирования следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в итоге выбирается обоснованный вариант, который доводится до реализации. Спираль завершается тогда, когда клиент и разработчик приходят к согласию относительно результата [1].

Модель состоит из последовательно расположенных этапов в пределах одного витка спирали. Внутри витка этапы не имеют обратной связи: анализ результата осуществляется в конце витка и инициирует новый виток спирали.

Как показано на рис. 1, в каждый квадрант модели входят целевые и вспомогательные действия. В первом из них определяются цели, такие как рабочая характеристика, выполняемые функции, возможность внесения изменений, а также альтернативные способы реализации этой части продукта и ограничения, налагаемые на применение альтернативных вариантов. Во втором квадранте модели осуществляется оценка альтернативных вариантов, относящихся к целям и ограничениям, и выполняется определение и разрешение рисков.

Рис. 1. Спиральная модель ЖЦ

Типичные действия, выполняемые в третьем квадранте модели, могут включать в себя создание проекта, его критический анализ, разработку кода, тестирование и компоновку продукта. Первая создаваемая версия основывается на том, что попадает в поле зрения заказчика. Затем начинается фаза планирования: программа возвращается в исходное состояние с целью учета реакции клиента. Степень вносимых изменений от одной версии к следующей уменьшается, что, в конечном счете, приводит к получению функциональной системы.

Действия в последнем квадранте модели могут включать разработку плана проекта, плана менеджмента конфигурации, плана тестирования и плана установки программного продукта.

Исправление ошибок происходит на этапе тестирования на каждом из витков. Фактически часть ошибок исправляется в пределах одного витка посредством связи этапов кодирования и тестирования. Ошибки, которые не могут быть исправлены и требуют более глубоких структурных изменений, инициируют новый виток спирали.

Основная особенность данной методологии состоит в концентрации сложности на начальных этапах жизненного цикла ПО (анализ, проектирование). При этом сложность и трудоемкость последующих этапов в пределах одного витка спирали относительно невысокие. По этой методологии предлагается способ снижения затрат в целом при разработке ПО за счет предотвращения потенциальных ошибок на этапах анализа и проектирования.

Выбору спиральной модели ЖЦ в рамках данного курсового проекта есть ряд причин.

Во-первых, при использовании данной модели значительно сокращается время до появления первых версий программного продукта. Первая рабочая версия должна содержит предварительный интерфейс, который должен реализовывать минимум функций. Последующие версии будут накапливать функционал, и совершенствоваться по сравнению с предыдущими.

Главный принцип здесь – как можно быстрее показать заказчику или непосредственным пользователям предварительную версию программы для того, чтобы они могли высказать свои замечания и дать необходимые рекомендации. Так как разработка и добавление новых функций ведется небольшими порциями, то исправить выявленные на каждом этапе недочеты гораздо легче, нежели переделывать полностью готовый программный продукт, несоответствующий требованиям заказчика.

При таком подходе конечные пользователи, как и заказчик, являются обязательными участниками процесса разработки ПО. Это повышает их заинтересованность в программном продукте, поскольку здесь постоянно учитывается их мнение.

Во-вторых, спецификации, которые конечный пользователь формирует в процессе разработки, будут точнее от одной версии к другой, так как по мере разработки он будет все четче представлять, каким программным продуктом он хотел бы пользоваться. На ранних этапах разработки зачастую бывает довольно сложно определить все то, что должен реализовывать конечный продукт.

В-третьих, при использовании спиральной модели значительно уменьшается вероятность морального устаревания системы за время ее разработки, так как постоянно поддерживается обратная связь с пользователями и заказчиком.