Эволюция гибкости: от стандартов к RUP
Прежде чем говорить о гибкой разработке, сформулируем, что нового вносит Rational Unified Process (RUP) по сравнению со старыми подходами.
С
ГОСТ 34 всё понятно: это довольно жесткая система. RUP предлагает гораздо более гибкую модель жизненного цикла. Точнее, RUP — это не конкретная модель, а шаблон, на основе которого можно создать множество разных моделей.
Если сравнивать со стандартом
12207, который в принципе допускает любые модели жизненного цикла, то RUP накладывает определенные рамки. В нем существует заданная структура, и в ее границах возможны различные настройки, но совсем отказаться от этой структуры нельзя.
Фундаментальное ограничение: запрет на «пульсацию»
Это ограничение продиктовано самой технологией. Суть в том, что объект проектирования — наша информационная система — в результате каждого шага должна только
прирастать. Мы можем многое менять в процессе, но не можем позволить системе сокращаться или откатываться назад.
Такой подход гарантирует достижение конечного результата. Если мы разрешаем продукту «пульсировать» — то есть сначала создаем большой объем функционала, затем отказываемся от части, снова возвращаемся к началу или середине и переделываем всё иначе, а затем опять отвергаем изменения — этот процесс рискует никогда не закончиться. Подобная цикличность разрушительна и не ведет к завершению проекта.
Парадигма инкрементности
Поэтому основная парадигма RUP — это
инкрементность (incrementality). Продукт всё время наращивается. А всё, что можно разрешить с точки зрения гибкости, не нарушая этого принципа поступательного роста, допускается без ограничений. В этом и заключается переход к управляемой гибкой разработке.
Краткие итоги
Сравнение подходов к организации жизненного цикла разработки позволяет увидеть фундаментальный сдвиг в проектном мышлении. От жесткой регламентации ГОСТ 34 индустрия движется к адаптивности, однако полная свобода, заложенная в стандарте 12207, таит в себе риски хаотизации. Материал фиксирует промежуточную, но крайне важную ступень эволюции, представленную RUP. Ее суть — замена формальных бюрократических ограничений одним сущностным технологическим требованием.
Идея запрета на сокращение или переделку созданного функционала является не просто административным правилом, а прямым следствием внутренней логики построения сложных информационных систем. Разработка рассматривается как процесс кристаллизации, где каждый этап оставляет неуничтожимый след в архитектуре. Это снимает противоречие между стремлением команды к экспериментам и потребностью бизнеса в прогнозируемом результате. Практическая ценность такого подхода в том, что он создает безопасное пространство для маневра: команда может менять траекторию, но не может разрушать уже созданный фундамент.
Диагностика «пульсации» становится важнейшим управленческим навыком. Регулярные откаты и переработки сигнализируют не о гибкости, а о глубинных проблемах целеполагания. Внедрение принципа инкрементности блокирует психологическую ловушку «бесконечного улучшения» и заставляет искать решения, совместимые с уже достигнутым прогрессом. Именно это отличает зрелый итеративный процесс от имитации бурной деятельности, которая никогда не конвертируется в готовый продукт.
1. RUP представляет собой не фиксированную модель жизненного цикла, а настраиваемый шаблон для создания множества моделей.
2. В отличие от стандарта 12207, допускающего любые модели, RUP накладывает строгое ограничение, связанное с природой разработки.
3. Ключевое технологическое правило RUP: система в результате каждого шага должна только наращиваться, но не сокращаться.
4. Запрет на откаты и удаление созданного функционала является гарантией достижения конечного результата.
5. Процесс неконтролируемых переделок и откатов называется «пульсацией» продукта.
6. «Пульсация» опасна тем, что создает бесконечный цикл изменений и делает завершение проекта невозможным.
7. Основная парадигма RUP — инкрементность, то есть постоянный прирост возможностей системы.
8. Инкрементность позволяет системе эволюционировать, а не хаотично меняться.
9. Любые гибкие изменения в процессе разрешены, если они не нарушают принцип поступательного роста системы.
10. Эволюция подходов идет от жесткости ГОСТ 34 через полную свободу 12207 к управляемой гибкости RUP.
11. Успех проекта напрямую связан со способностью команды наращивать функционал без уничтожения предыдущих результатов.
12. RUP формализует инженерную дисциплину, при которой гибкость не превращается в хаос.
1. Чем подход RUP к модели жизненного цикла принципиально отличается от модели, предлагаемой ГОСТ 34?
2. Почему RUP называют шаблоном для создания моделей жизненного цикла, а не готовой моделью?
3. В чем заключается ограничение RUP по сравнению с полной свободой выбора моделей в стандарте 12207?
4. Каково главное технологическое ограничение, накладываемое RUP на изменение продукта?
5. Что такое «пульсация» продукта в процессе разработки?
6. Почему «пульсация» или частые откаты функционала приводят к провалу проекта?
7. Дайте определение инкрементности в парадигме RUP.
8. Как инкрементность обеспечивает гарантию достижения конечного результата?
9. Каким образом принцип «только прирастать» влияет на принятие архитектурных решений?
10. Какие изменения в процессе разрешены с точки зрения парадигмы инкрементности?
11. В чем коренное различие между гибкостью в RUP и гибкостью, понимаемой как хаотичные изменения?
12. Почему запрет на сокращение системы назван в лекции «гарантией достижения результата»?
