👤 Уинстон Ройс и его подход к разработке ПО¶

1. Кто такой Уинстон Ройс?¶

Winston W. Royce — инженер компании TRW Inc.
В 1970 году опубликовал знаменитую статью “Managing the Development of Large Software Systems”, где впервые описал * каскадную модель* (Waterfall) и, что важнее, показал её ограничения и способы улучшения.

2. Что предложил Ройс?¶

Хотя многие знают Ройса как «отца» классического Waterfall, на самом деле он:

Критиковал линейную модель
– указал, что жёсткий переход от требований → коду → тесту приводит к большим рискам.
Предложил итерации и прототипирование
– разбить крупный проект на более мелкие «итерации»: сначала сделать прототип (pilot), затем основную систему.
Ввёл идею “Do it twice”
– сначала «черновой» дизайн и код, потом полную переработку с учётом полученного опыта.
Добавил формальные документы и проверки на каждом этапе: планы, спецификации, дизайн-ревью, тест-планы.
Подчёркивал важность валидации с пользователем (acceptance review) ещё до полного кодирования.

3. Чем его подход отличается от классического Waterfall?¶

Аспект	Waterfall (позднее понимание)	Подход Ройса
Итеративность	отсутствует	присутствует («двойное прохождение»)
Прототипирование	не используется	ключевой элемент («pilot» перед проектом)
Формальные проверки	в конце	на каждом этапе
Документация	часто минимальная	обширная: требования, дизайн, тест-планы
Вовлечение пользователя	только на приёмке	привлечение к эскизам и прототипам

4. Наследие Ройса¶

Не отдельная «Royce-методология», а улучшенная каскадная модель, заложившая основы для:
- RUP (итерации + роли + артефакты),
- Инкрементно-эволюционных подходов,
- Agile-практик (ранняя доставка, обратная связь).

5. Кратко¶

Royce показал: простого «водопада» недостаточно — нужен прототип, итерации, плановые проверки и * двойная разработка*, чтобы снизить риски и обеспечить качество.

Связь Уинсттона Ройса и V-модели¶

1. Контекст Ройса (1970)¶

Royce в статье “Managing the Development of Large Software Systems” впервые описал классический «водопад»
Он же сразу указал на его ограничения и предложил механизмы улучшения:
1. «Do it twice» – сначала прототип, затем основная реализация
2. Итерации и прототипирование для снижения рисков
3. Формальные ревью и планирование тестов на каждом этапе

2. Переход к V-модели¶

V-модель возникла как эволюция идей Ройса:
- Связывает фазы проектирования (левая ветвь V) с фазами тестирования (правая ветвь V)
- Подчёркивает парное проект→тест:
  - Системный дизайн ↔ системное тестирование
  - Детальный дизайн ↔ интеграционное тестирование
  - Кодирование ↔ модульное тестирование
  - Требования ↔ приёмочное тестирование

3. Унаследованные принципы от Ройса¶

Прототипирование и итерации
V-модель формирует тест-планы заранее (итерации планирования), хотя сама реализация остаётся последовательной.
Ранняя валидация
Ройс призывал готовить критерии приёмки ещё на этапе требований – в V-модели это отражено в разработке Acceptance Test Plan сразу после сбора требований.
Формальные проверки
Как и у Ройса, V-модель предполагает чёткие вехи (reviews/sign-off) перед каждым крупным этапом и соответствующее тестирование.

4. Вывод¶

V-модель можно рассматривать как прямого «потомка» идей Уинстона Ройса по усилению Waterfall-подхода:
– Ройс показал, что простого «водопада» мало →
– V-модель жестко привязывает к каждому этапу разработки соответствующее тестирование, тем самым минимизируя риски и улучшая качество.