3.1.
Модели жизненного цикла программного обеспечения
Под моделью жизненного цикла ПО понимается структура,
определяющая последовательность выполнения и взаимосвязи
процессов, действий и задач на протяжении ЖЦ. Модель ЖЦ зависит от
спецификации, масштаба и сложности проекта и спецификации условий,
в которых система создается и функционирует. Модель ЖЦ ПО включает
в себя: стадии, результаты выполнения работ на каждой стадии,
ключевые события – точки завершения работ и принятия решений.
Модель ЖЦ любого конкретного ПО определяет характер процесса его
создания, который представляет собой совокупность упорядоченных во
времени, взаимосвязанных и объединенных в стадии работ, выполнение
которых необходимо и достаточно для создания ПО, соответствующего
заданным требованиям. Под стадией понимается часть процесса
создания ПО, ограниченная определенными временными рамками и
22
заканчивающаяся
выпуском
конкретного
продукта
(моделей,
программных компонентов, документации), определяемого заданными
для данной стадии требованиями. На каждой стадии могут выполнятся
несколько процессов, определённых в стандарте ГОСТ Р ИСО/МЭК
12207-2010, и наоборот один и тот процесс может выполняться на
различных стадиях. Соотношение между стадиями и процессами также
определяется используемой моделью ЖЦ ПО. Далее рассмотрим модели
и их классификации [2, 25].
3.1.1.
Каскадная модель
Первой
моделью,
получившей
широкую
известность
и
действительно структурирующей процесс разработки, является
каскадная (водопадная) модель. Каждая стадия каскадной модели
заканчивается получением некоторых результатов, которые служат в
качестве исходных данных для следующей стадии. Требования к
разрабатываемому ПО, определенные на стадии формирования
требований, строго документируются в виде технического задания и
фиксируются на все время разработки проекта.
Рис. 3.1 Стандартная водопадная модель
Преимущества применения каскадной модели заключаются в
следующем:
на каждой стадии формируется законченный набор проектной
документации, отвечающий критериям полноты и
согласованности;
23
выполняемые в логичной последователь стадии работ позволяют
планировать сроки завершения всех работ и соответствующие
затраты.
Каскадная модель может использоваться при создании ПО, для
которого в самом начал разработки можно достаточно точно и полно
сформулировать все требования. В то же время этот подход обладает
рядом недостатков, вызванных прежде всего тем, чьл реальный процесс
создания ПО никогда полностью не укладывался в такую жесткую схему.
Спустя непродолжительное время после появления на свет
каскадная модель была доработана Уинстом Ройсом с учетом
взаимозависимости этапов и необходимости возврата на предыдущие
ступени, что может быть вызвано, например, неполнотой требований или
ошибками в формировании задания. Процесс создания ПО носит как
правило, итерационный характер: результаты очередной стадии часто
вызывают изменения в проектных решениях, выработанных на более
ранних стадиях. Таким образом, постоянно возникает потребность в
возврате к предыдущим стадиям и уточнении или пересмотре ранее
принятых решений. В результате реальный процесс создания ПО
принимает вид, изображенный на рисунке .
1
.
Рис. 3.1. Модифицированная водопадная модель
Наиболее распространенным результатом каскадного похода к
разработке ПО является поздняя неудача. Кажется, что проекты
выполняются нормально, но только до тех пор, пока работы не вступят в
24
завершающий этап, и тогда выясняется, что потребители недовольны
созданным продуктом [25].
Достарыңызбен бөлісу: |