Каскадная (водопадная) модель
Каскадный способ – разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (рис.2.1). Иначе называется водопадной моделью.
Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Рис. 2.1- Модель каскадного подхода Однако в процессе создания ИС часто возникает потребность в возврате к предыдущим этапам, уточнении или пересмотре ранее принятых решений. Реальный процесс создания ИС в этом случае принимает следующий вид (рис. 2.2):
Основные недостатки каскадного подхода: - существенная задержка с получением результатов и, отсюда, слабая связь с заказчиком. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением; - примитивная автоматизация (" механизация") существующих производственных действий работников. Подразумевается, что разработка начинается на системном уровне и проходит через анализ, проектирование, кодирование, тестирование и сопровождение. При этом моделируются действия стандартного инженерного цикла. Системный анализ задает роль каждого элемента в компьютерной системе, взаимодействие элементов друг с другом. Поскольку ПО является лишь частью большой системы, то анализ начинается с определения требований ко всем системным элементам и назначения подмножества этих требований программному «элементу». Необходимость системного подхода явно проявляется, когда формируется интерфейс ПО с другими элементами (аппаратурой, людьми, базами данных). На этом же этапе начинается решение задачи планирования проекта ПО. В ходе планирования проекта определяются объем проектных работ и их риск, необходимые трудозатраты, формируются рабочие задачи и план-график работ. Анализ требований относится к программному элементу — программному обеспечению. Уточняются и детализируются его функции, характеристики и интерфейс. Все определения документируются в спецификации анализа. Здесь же завершается решение задачи планирования проекта.
Рис. 2.3 -Вариант классического жизненного цикла разработки ПО Проектирование состоит в создании представлений: - архитектуры ПО; - модульной структуры ПО; - алгоритмической структуры ПО; - структуры данных; - входного и выходного интерфейса (входных и выходных форм данных). Исходные данные для проектирования содержатся в спецификации анализа, то есть в ходе проектирования выполняется трансляция требований к ПО во множество проектных представлений (моделей, спецификаций и др.), называемых артефактами. При решении задач проектирования основное внимание уделяется качеству будущего программного продукта. Кодирование состоит в переводе результатов проектирования в текст на языке программирования. Тестирование — выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта. Сопровождение — это внесение изменений в эксплуатируемое ПО. Цели изменений: - исправление ошибок; - адаптация к изменениям внешней для ПО среды; - усовершенствование ПО в соответствии с требованиями заказчика. Сопровождение ПО состоит в повторном применении каждого из предшествующих шагов (этапов) жизненного цикла к существующей программе, но не в разработке новой программы. Как и любая инженерная схема, классический жизненный цикл имеет достоинства и недостатки. Достоинства каскадного подхода: - на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности; - дает план и временной график, выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты по всем этапам проекта, упорядочивает ход конструирования. Недостатки классического жизненного цикла: - реальные проекты часто требуют отклонения от стандартной последовательности шагов; - цикл основан на точной формулировке исходных требований к ПО (реально в начале проекта требования заказчика определены лишь частично); - результаты проекта доступны заказчику только в конце работы.
|
