ВУЗ:
Составители:
го комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой
разработчиков.
Положительные стороны применения каскадного подхода заключаются в следующем:
• на каждом этапе формируется законченный набор проектной документации, отвечающий критериям
полноты и согласованности;
• выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения
всех работ и соответствующие затраты.
Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разра-
ботки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчи-
кам свободу реализовать их как можно лучше с технической точки зрения. В эту категорию попадают сложные
расчетные системы, системы реального времени и другие подобные задачи. Однако в процессе использования
этого подхода обнаружился ряд его недостатков,
Рис. 2.1 Каскадная схема разработки ПО
Рис. 2.2 Реальный процесс разработки ПО по каскадной схеме
вызванных прежде всего тем, что реальный процесс создания ПО никогда полностью не укладывался в такую
жесткую схему. В процессе создания ПО постоянно возникала потребность в возврате к предыдущим этапам и
уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ПО принимал
вид, представленный на рис. 2.2.
Основным недостатком каскадного подхода является существенное запаздывание с получением результа-
тов. Согласование результатов с пользователями производится только в точках, планируемых после завершения
каждого этапа работ, требования к ИС «заморожены» в виде технического задания на все время ее создания.
Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет
полностью завершена. В случае неточного изложения требований или их изменения в течение длительного пе-
риода создания ПО пользователи получают систему, не удовлетворяющую их потребностям. Модели (как
функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их ут-
верждением.
Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ (рис. 2.3), делающая
упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений
проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии
ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы сле-
дующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в
результате выбирается обоснованный вариант, который доводится до реализации.
Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Непол-
ное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завер-
шения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить
Страницы
- « первая
- ‹ предыдущая
- …
- 34
- 35
- 36
- 37
- 38
- …
- следующая ›
- последняя »
