Модели процесса разработки: code-and-fix, водопад, V-модель, инкремент, итерации, спираль

Модель процесса отвечает на один вопрос: в каком порядке и сколько раз мы проходим стадии разработки. Требования, проектирование, кодирование, тестирование, поставка есть в любой модели — различается их последовательность, количество проходов и то, что происходит при обнаружении ошибки.

Разбираться с моделями стоит не ради классификации. Причина практическая: выбор модели фиксирует, когда вы узнаете правду. Водопад откладывает момент истины до интеграции, итерации приносят его каждые две недели, V-модель заставляет подумать о проверке до написания кода. Стоимость проекта в большей степени определяется не самой ошибкой, а задержкой её обнаружения — и именно этой задержкой управляет модель.

Заодно наведём порядок в терминах, которые в русскоязычных материалах смешаны:

Дальше в главе речь идёт именно о моделях. Подходы и методологии — тема следующей главы, а этапы SDLC сами по себе разобраны в треке про разработку софта.

1. Code-and-fix: модель, от которой все убегали

Историческая нулевая точка: пишем код, находим ошибки, чиним, снова пишем. Ни требований, ни архитектуры, ни отдельного тестирования. Это не выдуманный антипример — так писали софт в 1950–60-е, и так пишут сегодня в двух ситуациях: в очень маленьких скриптах и в командах, где процесс потеряли.

Модель имеет ровно два достоинства — нулевая накладная стоимость и мгновенный старт — и две смертельные болезни. Структура деградирует: каждое исправление накладывается на предыдущее, и через несколько месяцев стоимость следующего изменения растёт быстрее, чем польза от него. Нет критерия готовности: неизвестно, что должно работать, поэтому неизвестно, когда закончили.

Порог применимости честный: если работа умещается в несколько дней одного человека и результат выбрасывается, code-and-fix оптимальна, а любой процесс поверх неё — накладные расходы. Всё остальное, что исторически придумано в этой области, — попытки не скатиться обратно в code-and-fix.

2. Водопад: что на самом деле написал Ройс

Это обязательный кусок главы: без него вся дальнейшая история моделей не читается.

В 1970 году Уинстон Ройс опубликовал статью «Managing the Development of Large Software Systems». На второй странице он приводит простую последовательную схему — требования, анализ, проектирование, кодирование, тестирование, эксплуатация — и тут же пишет, что она не работает: «I believe in this concept, but the implementation described above is risky and invites failure». Дальше в статье пять рекомендаций, которые сегодня звучат почти как Agile:

1. Проектирование предшествует анализу — сначала предварительный архитектурный проход, чтобы понять осуществимость.
2. Документируйте проект — иначе знание невоспроизводимо (это единственный пункт, который отрасль услышала).
3. Сделайте это дважды: первая версия системы — пилот, который выбрасывается. Буквально: «if the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version».
4. Планируйте, контролируйте и мониторьте тестирование — тестирование это отдельная работа, а не хвост кодирования.
5. Вовлекайте заказчика — формально, письменно и на протяжении всего проекта, а не в начале и в конце.

Ройс также рисует обратные связи между соседними стадиями и предупреждает: если петля обратной связи оказывается длинной (например, из тестирования назад в требования), проект попадает в зону перерасхода в разы. То есть в оригинале водопад уже содержит итерацию, прототип и раннюю верификацию.

Как схема стала нормативом. В 1985 году Министерство обороны США выпустило стандарт DoD-STD-2167, который описывал разработку военного ПО как строгую последовательность фаз с формальными обзорами и комплектом документов на каждой. Стандарт не запрещал итерации явно, но вся его структура — контрактные вехи, привязанные к завершению фаз, — делала итерации организационно невозможными: подрядчику платили за сдачу документа фазы. Любой, кто хотел получать деньги Минобороны, работал каскадно. В 1988-м вышел 2167A, в 1994-м его заменили на MIL-STD-498, который итерации уже разрешал прямо, — но к этому моменту поколение инженеров и целая отрасль подрядчиков успели усвоить водопад как норму.

Отсюда мораль, полезная далеко за пределами истории: форма оплаты определяет процесс сильнее, чем методология. Если деньги приходят за сдачу фазы, процесс станет фазовым независимо от того, что написано в регламенте разработки.

Что в водопаде действительно хорошо. Прозрачность для заказчика: в любой момент понятно, где мы находимся. Стоимость и объём определены заранее — на этом строится фиксированная цена. Не нужны тестировщики высокой квалификации: есть подробная спецификация, по которой пишутся проверки. Модель поддаётся планированию через диаграмму Ганта и хорошо ложится на контракт, ГОСТ и конкурсную документацию.

Что плохо. Тестирование в конце: ошибка в требованиях доживает до момента, когда написан код и документация, и стоит максимально дорого. Заказчик видит результат один раз — в конце, когда менять поздно. Большой объём документации, который надо синхронно поддерживать при каждом изменении. И главное — водопад предполагает, что требования известны и стабильны; там, где это неверно, он не «плохо работает», а работает над не той системой с высокой точностью.

3. Прототипная модель и модель хаоса

Прототипная модель — это ответ на вопрос «что делать, если заказчик не может сформулировать требования, пока не увидит». Строится дешёвый прототип (от бумажного макета до работающего скелета), на нём выясняются требования, и только после этого начинается основная разработка. Ключевое решение — что делать с прототипом дальше: выбросить (throwaway prototyping) или развивать (evolutionary prototyping). Обе стратегии законны, но смешивать их катастрофично: прототип, который «временно» уехал в прод, — самый распространённый источник неубираемого технического долга, потому что он строился с явным отказом от качества. Практика прототипирования подробно разобрана в треке системного анализа.

Модель хаоса (Рэймонд Дж. А. Буэ, 1994) — попытка описать разработку как рекурсивное применение одного цикла «определить главную нерешённую проблему → решить её → интегрировать» на всех масштабах сразу: от строки кода до всей системы. Практического распространения модель не получила и в проектах не встречается, но её тезис полезен как наблюдение: разработчик в реальности не идёт по фазам, а на каждом уровне вложенности выбирает самую важную нерешённую проблему. Строго говоря, это ближе к описанию поведения, чем к модели процесса.

4. V-модель: проверка проектируется вместе с решением

V-модель (появилась в 1980-е, закреплена в немецком стандарте V-Modell и его наследнике V-Modell XT) — это водопад, согнутый пополам. Левая ветвь идёт вниз по уровням декомпозиции: потребности → системные требования → архитектура → детальное проектирование. Правая ветвь идёт вверх по уровням проверки: модульное → интеграционное → системное → приёмочное тестирование. Уровни связаны попарно.

Главная идея не в форме буквы, а в правиле: план проверки каждого уровня пишется на этом же уровне, слева, до того как написан код. Формулируя приёмочные тесты одновременно с требованиями, вы обнаруживаете непроверяемые требования сразу («система должна быть удобной» — как измерим?), а не через полгода. Это тот же принцип, что в TDD, только на уровне системы.

Различают верификацию («правильно ли мы построили систему» — соответствие спецификации) и валидацию («ту ли систему мы построили» — соответствие реальной потребности). Верхняя горизонталь V — валидация, все нижние — верификация. Проект, где есть только верификация, может безупречно построить не то.

Где применяется по-настоящему. Там, где регулятор требует прослеживаемости: каждое требование должно быть связано с проектным решением, кодом и подтверждающим тестом.

Почему в вебе почти не встречается. Не потому что «устарела», а потому что цена ошибки другая. В интернет-магазине ошибка стоит одного отката релиза длиной в четыре минуты; в блоке управления тормозами — жизни, отзыва партии и уголовного дела. Правая ветвь V стоит дорого (документированные тесты на каждом уровне, независимая верификация, прослеживаемость), и эта цена окупается только при высокой стоимости отказа. Обратное тоже верно: попытка сделать веб-стартап по ISO 26262 убьёт стартап раньше, чем он найдёт клиента.

Практически полезный кусок V-модели переносится куда угодно и бесплатно: писать критерии приёмки одновременно с требованием. Как это делается в современных командах — в треке тестирования и в главе про приёмку.

5. Инкремент против итерации: это разные вещи

Самая частая путаница в теме. Оба слова означают «делаем по частям», но части разные.

• Инкремент — приращение по объёму. Мы делим систему на куски и достраиваем: сначала каталог, потом корзина, потом оплата. Каждый кусок сделан «начисто», целое собирается к концу.
• Итерация — повторение по качеству. Мы делаем всю систему грубо, а затем проходим по ней снова, делая лучше: сначала весь сценарий покупки на заглушках, потом он же с реальной оплатой, потом он же с быстрой и надёжной оплатой.

Классическую иллюстрацию дал Джефф Паттон в заметке «Don’t Know What I Want, But I Know How to Get It»: инкремент — это дом, который строят по кускам (фундамент, стены, крыша — жить нельзя до последнего шага); итерация — это картина, которую сначала набрасывают целиком, а потом прорабатывают.

Главный практический вывод: это не альтернативы, а две оси, и в реальной работе используют обе. Первый релиз — итеративный (тонкий сквозной сценарий на заглушках, чтобы проверить, то ли строим); дальше — инкрементальный (добавляем сценарии), с итерациями внутри там, где решение неочевидно.

Пример инкремента: социальная сеть. Заказчик написал подробное ТЗ. Команда делает сначала профиль и чат, выпускает их, смотрит на пользователей; затем параллельно достраивает загрузку фотографий, обмен документами, музыку — приращение за приращением приближаясь к описанному в ТЗ. Плюсы: не нужно вкладывать весь бюджет вперёд, ранняя обратная связь, дешевле цена архитектурной ошибки. Минусы, реальные и известные: несколько команд, строящих разные куски, легко приходят к разному интерфейсу и разным моделям данных (лечится общим дизайн-языком и договорённостями об интеграции на старте); и есть устойчивый соблазн бесконечно «пилить мелочёвку», не трогая тяжёлое ядро.

Пример итерации: мессенджер. Заказчик не знает, каким должен быть продукт. Команда делает приложение, где можно добавить друга и написать в чат — целиком, но грубо. Выкатывает, смотрит, как пользуются. Дальше добавляются видео, фото, аудиосообщения, но главное — каждый следующий проход улучшает то же самое: скорость доставки сообщения, надёжность на плохой сети, простоту первого запуска. Плюс: быстрый выпуск минимального продукта и фокус на важном. Минусы: инфраструктурные решения, принятые на первой итерации (схема БД, один сервер), под нагрузкой приходится переписывать, а бюджет и срок принципиально не фиксированы, что тяжело для заказчика, привыкшего к смете.

6. Спиральная модель Боэма: риск как двигатель

Барри Боэм опубликовал спиральную модель в 1988 году («A Spiral Model of Software Development and Enhancement»). Её обычно помнят как «итерации по кругу», и это упускает суть. Спираль — риск-ориентированная модель: содержание очередного витка определяется не планом, а тем, какой риск сейчас самый крупный.

Каждый виток проходит четыре сектора:

1. Определить цели, альтернативы и ограничения данного витка.
2. Оценить альтернативы, выявить и снять риски — прототип, эксперимент, нагрузочный тест, моделирование.
3. Разработать и проверить результат витка (в позднем витке это может быть полноценный водопадный проход).
4. Спланировать следующий виток — и принять решение о продолжении.

Три вещи, которые делают спираль важной за пределами её собственного применения.

Радиус витка растёт вместе с вложениями. На картинке Боэма расстояние от центра — накопленная стоимость. Ранние витки дёшевы и посвящены самым неопределённым вопросам; поздние дороги, но к ним неопределённость уже снята. Это прямая экономическая логика: сначала покупаем информацию, потом строим.

«Кто рискует, тот и итерирует». Количество витков не назначается календарём — оно определяется тем, сколько неопределённости надо снять. Проект с известными требованиями и знакомой технологией честно делается в один виток, и это будет водопад. Проект, где неизвестно и что строить, и на чём, требует нескольких дешёвых витков до первой серьёзной траты.

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

Пример: система «умный дом». Виток 1 — управление чайником с телефона: цель понятна, риск в том, нужно ли это пользователям; проходим быстрый цикл и выпускаем. Виток 2 — управление телевизором: оцениваем спрос по факту первого витка, считаем бюджет, делаем. Виток 3 — холодильник: на секторе анализа рисков выясняется, что встроить модуль сложно, производители не заинтересованы, а спрос гипотетичен. Риск превышает ожидаемую выгоду — виток не начинается, ресурсы уходят на улучшение существующего. Это и есть работающая спираль: решение не начинать — такой же законный результат анализа, как решение начать.

Недостатки честные: модель дорогая в накладных расходах (каждый виток требует настоящего анализа рисков, а не галочки), требует людей, умеющих этот анализ делать, и склонна к застреванию на ранних витках, если никто не ограничивает исследование. Прямые наследники спирали — RUP с его четырьмя фазами и риск-ориентированным подходом и практика спайков в Agile; разбор — в главе про RAD, итеративность и RUP.

7. Сводная таблица моделей

8. Кривая стоимости исправления дефекта и её честная критика

Практически в каждой презентации о качестве встречается кривая: дефект, найденный на этапе требований, стоит 1; на этапе проектирования — 5; в коде — 10; при тестировании — 50; в проде — 100 и больше. Источник обычно указывают как «Boehm» — имеется в виду «Software Engineering Economics» (1981) и более поздние работы Боэма и Бэзили.

Аргумент направленно верен и физически понятен: чем позже обнаружена ошибка, тем больше артефактов на ней построено (код, тесты, документация, обучение пользователей, данные в проде), тем шире круг людей, вовлечённых в исправление, и тем дороже координация. С этим спорить не приходится.

Спорить приходится с точностью и универсальностью. Лоран Боссави в «The Leprechauns of Software Engineering» проследил цитирования этой кривой и показал типичную картину для отрасли: цифры кочуют из статьи в статью, ссылки ведут на источники, которые сами ссылаются на другие, первичные данные относятся к небольшому числу проектов 1970-х годов на технологиях, которых больше нет, часть исходных наборов данных недоступна, а конкретный множитель «100×» в первоисточниках в таком виде не обнаруживается. Отдельная проблема — систематическая ошибка отбора: дорого обходятся именно те дефекты, которые дожили до прода, потому что они сложны и незаметны; дешёвые дефекты ловятся рано просто в силу своей простоты. Часть наблюдаемого роста стоимости объясняется не «поздним обнаружением», а тем, что это изначально разные дефекты.

Что из этого следует практически:

1. Не используйте кривую как расчётный инструмент. «Раннее тестирование сэкономит нам 100× на каждом дефекте» — не оценка, а риторика. В бизнес-кейсе такое число не выживет при первом же вопросе.
2. Пользуйтесь качественным выводом. Сокращать задержку обнаружения дефекта полезно — это подтверждается независимо, через исследования DORA о связи короткой петли обратной связи с производительностью (dora.dev и книга «Accelerate»).
3. Измеряйте у себя. Стоимость исправления считается по вашим данным: время от появления до обнаружения, время на исправление, количество вовлечённых людей. Своя кривая полезнее чужой и убеждает сильнее.

Это, кстати, хорошая иллюстрация к дисклеймеру из карты трека: в управлении разработкой много утверждений, направленно верных и численно необоснованных, и профессиональный навык — держать эти два уровня раздельно.

9. Типичные ошибки

10. Как это выглядит в проде

Финтех, платёжное ядро и мобильное приложение. Ядро живёт по правилам, близким к V-модели: требования прослеживаются до тестов, изменения проходят обзор, есть независимая верификация, релизы редкие и подготовленные. Приложение живёт двухнедельными итерациями с еженедельными выкатками. Это один продукт и две разные модели — потому что цена ошибки в списании денег и в цвете кнопки различается на несколько порядков. Стык оформлен контрактом API и фиксированной каденцией согласования.

Госконтракт на информационную систему. Календарный план с этапами и актами по каждому — водопад в чистом виде, и обсуждать это бессмысленно: так устроена конкурсная документация. Что реально можно сделать: внутри этапа работать итеративно, показывать заказчику промежуточный результат раньше формальной сдачи и добиться, чтобы приёмочные тесты были согласованы вместе с ТЗ, а не написаны за неделю до приёмки. Первое даёт короткую петлю обратной связи, второе — единственный способ узнать про непроверяемые требования заранее.

Продуктовый стартап. Первые полгода — итеративность в чистом виде: тонкий сквозной сценарий на заглушках, каждую неделю переделываемый целиком. После того как ядро ценности подтверждено, модель сдвигается к инкрементальной: сценарии добавляются, ядро стабилизируется. Момент перехода определяется не календарём, а фактом: гипотеза ценности перестала опровергаться.

Медицинское устройство с ПО. IEC 62304 определяет почти всё: класс безопасности, состав документации, требование прослеживаемости. Здесь V-модель не выбор, а условие допуска на рынок. Внутри всё равно живут итерации — но каждая завершается обновлением полного комплекта документов, и именно это делает цикл дорогим. Экономия достигается не срезанием документации, а сокращением количества изменений в критичной части: их выносят в отдельный контур с отдельной каденцией.

Мини-итог

• Модель процесса определяет, когда вы узнаете правду. Не «правильная» и «неправильная» модель, а разная задержка обнаружения ошибки и разная цена её исправления.
• Водопад в оригинале Ройса содержал итерации, прототип и раннее тестирование. Нормативом каскад сделал DoD-STD-2167 и привязка оплаты к сдаче фаз: форма оплаты определяет процесс сильнее методологии.
• V-модель — не устаревший водопад, а водопад с обязательной проверкой на каждом уровне. Живёт там, где регулятор требует прослеживаемости; переносимая бесплатно часть — писать критерии приёмки вместе с требованием.
• Инкремент и итерация — разные оси. Инкремент добавляет объём и снимает риск сроков; итерация улучшает целое и снимает риск ценности. Здоровая разработка использует обе.
• Спираль Боэма — это гейты по рискам, а не по фазам. Радиус витка равен накопленным вложениям, число витков определяется объёмом неопределённости, а решение не начинать очередной виток — законный результат анализа.
• Кривая стоимости дефекта верна направленно и не выдерживает проверки численно. Пользуйтесь качественным выводом о короткой петле обратной связи и считайте собственные цифры.

Источники

• Royce W., «Managing the Development of Large Software Systems», IEEE WESCON, 1970.
• Boehm B., «A Spiral Model of Software Development and Enhancement», IEEE Computer, 1988.
• Boehm B., «Software Engineering Economics», 1981 — источник кривой стоимости дефекта.
• Bossavit L., «The Leprechauns of Software Engineering» — разбор происхождения кривой и других «фактов» отрасли.
• Patton J., «Don’t Know What I Want, But I Know How to Get It» — классическая иллюстрация различия инкремента и итерации.
• DOD-STD-2167A и MIL-STD-498 — как каскад стал нормативом и как перестал им быть.
• V-Modell XT — современная редакция немецкого стандарта.
• IEC 62304, ISO 26262, DO-178C — отрасли, где V-модель обязательна.
• Larman C., Basili V., «Iterative and Incremental Development: A Brief History», IEEE Computer, 2003 — итеративная разработка существовала задолго до Agile.
• Forsgren N., Humble J., Kim G., «Accelerate», 2018; DORA Research — данные о связи короткой петли обратной связи с результатами.

Что дальше

Модели описывают порядок стадий, но ничего не говорят о том, как именно работать внутри стадии: кто принимает решения, как планируется работа, какие практики обязательны. Этот слой называется методологиями и фреймворками, и именно здесь живут RUP, XP, Scrum, Kanban и весь спор вокруг Agile.

Следующая глава наводит порядок в трёх уровнях сразу: подход (предиктивный, итеративный, адаптивный) — модель — методология, и разбирает семейство Agile целиком: откуда взялся манифест, что в нём написано на самом деле, чем XP отличается от Scrum, где заканчивается гибкость и почему «гибридный» подход стал в крупных организациях нормой, а не признаком незрелости.

Читайте: Подходы и методологии: предиктивный, итеративный, гибкий — и семейство Agile целиком