– при нажатии «ОК» окно закрывается, обработка продолжается (попробовать кликнуть мышью по интерфейсу программы вне окна, должно быть возможно).
Такова традиционная модель: выясняем у заказчика, что нужно сделать, фиксируем, далее выполняем, проверяем результат на соответствие критериям, передаем результат заказчику.
Жизненный цикл требования состоит из его формулирования (сбора) и выполнения – это и есть простая модель требования.
Традиционная методология водопада отлично согласуется с такой моделью требования.
Поговорим об этом подробнее.
«Водопад» – методология на простой модели требований
Как известно, «Водопадная», или каскадная модель – модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.
Традиционно для каскадной модели фазы следуют в таком порядке:
– определение требований;
– проектирование;
– конструирование;
– воплощение;
– тестирование и отладка;
– инсталляция;
– поддержка.
Переход от одной фазы к другой происходит только после полного и успешного завершения предыдущей.
Следуя каскадной модели, разработчик переходит от одной стадии к другой строго последовательно.
Сначала полностью завершается этап «определение требований», в результате чего получается список требований.
После того как требования полностью определены, происходит переход к проектированию и далее, последовательно, по всем фазам, вплоть до инсталляции и поддержки.
Задумаемся, какие ограничения устанавливаются для требований в момент завершения фазы определения требований по каскадной методологии? Ответ достаточно очевиден – в этот момент требования фиксируются и далее являются неизменными.
Что означает «неизменными» с точки зрения проекта? Как минимум, следующее:
– содержание требования, как его понимают все участники проекта, более не меняется;
– связи требования с другими требованиями прояснены и не изменяются значимым для понимания других требований образом;
– не возникает новых требований;
– существующие требования не удаляются из рассмотрения.
По существу, мы имеем вышеописанную нами простую модель требований, когда они зафиксированы, поняты и более не могут изменяться вплоть до окончания проекта.