Рассмотрим, каким образом в кризис происходит изменение RUP в соответствии с теми особенностями жизненного цикла, которые используются или выбираются при разработке программных продуктов. Мы рассмотрим каскадный жизненный цикл, инкрементный или инкрементальный и эволюционный. Первое, что мы рассмотрим, это каскадный или водопадный жизненный цикл. Мы помним, что при этом стадии жизненного цикла — анализ, проектирование первичное и детальное, затем реализация с тестированием, интеграция с тестированием и после передачи заказчику сопровождение — происходит строго сверху вниз в один проход без возврата. При этом жизненный цикл RUP выглядит так, как это показано на слайде. Мы видим, что первые стадии — это собственно все, что происходит до передачи — можно сказать, что представляют собой одну сплошную итерацию или фазу с, естественно, четкими критериями выхода. Дело в том, что мы можем даже не дробить это на разные фазы, просто потому что разработка происходит в один проход. Критерий выхода — готов первичный прототип концепции, готов первичный скелет архитектуры и готов релиз к передаче, как мы это видим. При этом, какие условия накладывает кризис на необходимость работы по такой схеме. Это, скажем, существует стабильный продукт или существует требование стабильный продукт, т. е. эти требования не существенно меняются во времени, можно сказать, они практически стабилизированы. Если мы говорим о системе, которая нужна, предположим, для Министерства обороны, управления вооружением, понятно, что эта система не будет претерпевать существенных изменений на протяжении достаточно большого времени. Мы понимаем, что требования четко определены, требования фиксированы. Мы понимаем, что в Министерстве обороны существует большое количество специалистов, которые способны продуктивно, с полным пониманием вести диалог, скажем, на формальном языке диаграммирования типа UML и т. д. и они достаточно хорошо владеют современными стандартами разработки. Таким образом, мы действительно можем в один проход пройти, собственно, все фазы, которые необходимы до передачи изделия заказчику. Таким образом, если речь идет о разработке нового стабильного продукта либо о добавлении некоторого небольшого ограниченного фрагмента функциональности, которая опять-таки заранее известна и стабильна к существующему продукту, можно выбрать такой подход. Естественно, новая функциональность, те самые use-case, те самые диаграммы прецедентов или сценарии использования, те самые ключевые функции, которые необходимо добавить к продукту, хорошо известны и определены. Естественно, наша команда разработки достаточно хорошо владеет предметной областью и существующим продуктом, если такой есть или гипотетическим продуктом, достаточно хорошо представляет себе, что должно получиться на выходе. Вот в таких условиях каскадную модель по приведенной на слайде схеме и можно использовать вместе с Rational Unified Process. Это, я замечу, при том, что сам по себе процесс является итеративным и ориентирован на многократное повторение. Но после передачи, как мы видим, возможно потребуется несколько уточняющих итераций, которые характеризуют уточнение, улучшение, усовершенствование релиза для полной передачи заказчику именно того продукта, который требуется.