Каскадная модель жизненного цикла ИС
Модели жизненного цикла ИС В мировой практике не существует международного стандарта, регламентирующего различные модели жизненного цикла, однако существует ряд различных подходов к их классификации. Наибольшее распространение в этих классификациях получили две модели жизненного цикла: каскадная и итерационная, которые будут рассмотрены далее. Каскадная модель. Каскадная модель жизненного цикла («модель водопада», англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Этапы проекта в соответствии с каскадной моделью: 1.Формирование требований 2.Проектирование 3.Реализация 4.Тестирование 5.Ввод в действие 6.Эксплуатация и сопровождение Каскадные технологические подходы к разработке информационных систем задают некоторую последовательность выполнения процессов, обычно изображаемую в виде каскада. Эти подходы также иногда называют подходами на основе модели водопада. Каскадная модель (waterfall model) жизненного цикла (рис.9) считается основой технологических подходов к ведению жизненного цикла. Эта модель была предложена в 1970 году У. Ройсом. Впоследствии данная модель была регламентирована множеством нормативных документов, в частности, широко известным стандартом Министерства обороны США Dod-STD-2167A и российскими стандартами серии ГОСТ 34. Принципиальными свойствами так называемой «чистой» каскадной модели являются следующее: · фиксация требований к системе до ее сдачи заказчику; · переход на очередную стадию проекта только после того, как будет полностью завершена работа на текущей стадии, без возвратов на пройденные стадии. Рис.9. Каскадная модель жизненного цикла.
Каждая стадия заканчивается получением некоторых результатов, которые служат в качестве исходных данных для следующей стадии. Требования к разрабатываемому программному обеспечению, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Преимущества применения каскадной модели заключаются в следующем: · на каждой стадии формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности; · выполняемые в логичной последовательности стадии работ Каскадная модель может использоваться при создании информационных систем, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем, чтобы предоставить разработчикам свободу реализовать их технически как можно лучше. В эту категорию попадают, как правило, системы с высокой критичностью: сложные системы с большим количеством задач вычислительного характера, системы управления производственными процессами повышенной опасности и др. В то же время этот подход обладает рядом недостатков, вызванных, прежде всего тем, что реальный процесс создания информационных систем никогда полностью не укладывался в такую жесткую схему. Процесс создания системы носит, как правило, итерационный характер: результаты очередной стадии часто вызывают изменения в проектных решениях, выработанных на более ранних стадиях. Таким образом, постоянно возникает потребность в возврате к предыдущим стадиям и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания информационной системы принимает вид: Рис.10. Модель реального процесса разработки системы. Основными недостатками каскадного подхода являются: · позднее обнаружение проблем; · выход из календарного графика, запаздывание с получением результатов; · избыточное количество документации; · невозможность разбить систему на части (весь продукт разрабатывается за один раз); · высокий риск создания системы, не удовлетворяющей изменившимся потребностям пользователей. Практика показывает, что на начальной стадии проекта полностью и точно сформулировать все требования к будущей системе не удается. Это объясняется двумя причинами: · пользователи не в состоянии сразу изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки; · за время разработки могут произойти изменения во внешней среде, которые повлияют на требования к системе.
|