Сравнительный анализ каскадной и спиральной моделей

Файл : ref_analiz.doc (размер : 111,616 байт)

Министерство образования РФ

Воронежский Государственный Университет

Факультет Компьютерных Наук

Сравнительный анализ каскадной и спиральной моделей разработки программного обеспечения

Выполнил : Шумлянский Михаил Сергеевич

Воронеж 2003

Содержание

Введение………………………………………………………………………………………………..2

Водопадная модель процесса разработки……………………………………………………………..3

Спиральная модель процесса разработки……………………………………………………………..4

Итерации по спирали………………………………………………………………………………4

Общие характеристики этапов разработки программного обеспечения…………………………..5

Этап планирования и анализа требований…………………………………………….5

Этап разработки………………………………………………………………………………6

Реализация………………….…………………………………………………………………...10

Внедрение………………………………………………………………………………………10

Сопровождение и Эксплуатация……………………………………………………………………..10

Заключение………………………………………………………………………………………………..11

Список источников……………………………………………………………………………………….11

Введение

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

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

( стратегическое планирование; анализ требований;( проектирование (предварительное и детальное); ( кодирование (программирование); ( тестирование и отладка; ( эксплуатация и сопровождение.

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

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

Водопадная модель процесса разработки

К середине 80-х годов наибольшее распространение получил "водопадный" (waterflow) или "каскадный" процесс создания программного обеспечения. Схема "водопадного" процесса приведена на рис. 1.1. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

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

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