SDLC: как устроены этапы и контрольные точки

Объяснение · Разработка и инженерные процессы · Данил Письменный · опубликовано · версия 2, обновлено

SDLC как итеративный поток через контрольные точки: параллельные процессы, возврат и переход к устойчивой системе

Короткий ответ

SDLC (Software Development Life Cycle) — жизненный цикл программной системы: от появления потребности и требований до эксплуатации и вывода из эксплуатации. В некоторых источниках аббревиатура раскрывается как System Development Life Cycle. Это более широкий уровень, который включает не только ПО, но и оборудование, людей, процессы и операционную среду.

Главный тезис: SDLC описывает, какие работы нужно выполнить и какие результаты получить за время жизни системы. Он не задаёт единственный порядок этапов: процессы могут выполняться параллельно, итеративно и рекурсивно, а команда выбирает подходящую модель жизненного цикла.1 В контрольных точках (gates) принимают решения о следующем шаге — например, начинать ли дорогую разработку или запускать систему.2

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

Карта жизненного цикла

Для этой статьи необходимые работы собраны в учебную карту из девяти этапов:

Классический каркас SDLC: девять этапов от исследования до вывода из эксплуатации, объединённые в четыре смысловых блока; эксплуатация формирует новые требования
Этап Какую неопределённость снимает Главный результат Решение в контрольной точке
1. Потребность и реализуемость нужна ли система и реализуема ли она границы, ожидаемый эффект, исходные риски продолжать работу или остановиться
2. Требования что именно требуется и как это проверить согласованный набор требований и критериев приёмки переходить к архитектуре
3. Архитектура каким способом достичь требуемых свойств архитектурная схема, интерфейсы, ключевые решения переходить к проектированию компонентов
4. Проектирование компонентов достаточно ли решение конкретно для реализации спецификации компонентов, данных и поведения начинать реализацию
5. Реализация существует ли воспроизводимо собираемый продукт код, конфигурация, сборка и автоматические проверки допускать сборку к системным проверкам
6. Тестирование и приёмка соответствует ли продукт требованиям и реальной задаче отчёты о проверках, дефекты, оценка готовности принимать продукт и готовить запуск
7. Внедрение и переход в эксплуатацию готова ли система к безопасному запуску план поставки, отката, мониторинга и поддержки запускать систему
8. Эксплуатация и сопровождение сохраняет ли система ценность и управляемость метрики, инциденты, исправления и новые требования выпускать изменение
9. Вывод из эксплуатации можно ли безопасно прекратить работу миграция/архивирование данных и отключение системы отключать систему

Почему списки этапов различаются

Эта карта — синтез, а не обязательная схема стандарта. Software Engineering Institute перечисляет потребности и ограничения, требования, архитектуру, проектирование компонентов (detailed design), реализацию, тестирование, внедрение и сопровождение, но прямо называет список неполным.3 Вывод из эксплуатации добавлен из полного жизненного цикла ISO/IEC/IEEE 12207 и исторической модели NIST.14

Стандарты и команды группируют одну и ту же работу с разной подробностью. Например, NIST объединял её в пять крупных фаз: инициирование, приобретение или разработку, внедрение, эксплуатацию и сопровождение, вывод из эксплуатации.4 Поэтому процессы жизненного цикла — это необходимые виды работ, а этапы — способ расположить и сгруппировать их в выбранной модели.

Что важно не перепутать

  1. Жизненный цикл (SDLC) — работы, которые нужно выполнить от замысла до прекращения эксплуатации.
  2. Модель жизненного цикла — как эти работы организованы во времени: Waterfall, V-model, спиральная, итеративная, инкрементальная или гибридная модель.
  3. Метод управления работой — как команда планирует и выполняет короткие участки цикла: например, Scrum, Kanban или внутренний процесс компании.
  4. Управление решениями (governance) — кто и на основании каких доказательств разрешает переходить дальше.

Классический SDLC — не обязательно Waterfall. Одни и те же процессы жизненного цикла могут выполняться и в каскадной, и в итеративной разработке, но их группировка, порядок, размер инкрементов и контрольные точки будут различаться.1

Этапы классического SDLC

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

1. Потребность и реализуемость

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

2. Требования

Потребности заинтересованных сторон переводятся в проверяемые требования, сценарии использования, бизнес-правила, интерфейсы и ограничения качества. Требования должны дать команде способ проверить результат, а не только описать желаемую функцию. В формальной среде их готовность может оцениваться отдельной экспертной проверкой.7

3. Архитектура и системное проектирование

Архитектура задаёт крупные компоненты, границы ответственности, потоки данных, интеграции, топологию развёртывания и ключевые компромиссы. Она должна объяснять, как система сохраняет требуемые свойства при отказах, росте нагрузки и изменениях, а также какие рискованные решения ещё нужно проверить прототипом.

4. Проектирование компонентов

Следующий уровень отвечает на более узкий вопрос: достаточно ли конкретно описано устройство компонентов, чтобы их можно было реализовать и проверить? Здесь появляются алгоритмы, структуры данных, схемы БД, состояния, протоколы, форматы ошибок и правила валидации. Граница с архитектурой подвижна, но спецификации компонентов не должны противоречить архитектурным решениям. Перед реализацией формальная экспертная проверка может оценивать зрелость проектного решения.8

5. Реализация

Проектное решение превращается в код, конфигурацию, инфраструктуру и миграции. Воспроизводимая сборка, ревью кода, статический анализ, проверки безопасности и модульные тесты выполняются вместе с реализацией, а не откладываются до отдельной «фазы качества».

6. Тестирование и приёмка

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

7. Внедрение и переход в эксплуатацию

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

8. Эксплуатация и сопровождение

После запуска команда исправляет дефекты, управляет зависимостями, наблюдает за системой и развивает продукт. Метрики, обращения пользователей и инциденты возвращаются в цикл как основания для новых требований и изменений.

9. Вывод из эксплуатации

Жизненный цикл заканчивается управляемым прекращением работы: миграцией и архивированием данных, отключением интеграций, отзывом доступов, удалением инфраструктуры и выполнением юридических обязательств. В ранней модели NIST этот этап называется disposition.4

Что V-модель добавляет к карте этапов

V-модель полезна не как ещё один список фаз, а как карта соответствий. Слева система определяется от потребности к требованиям, архитектуре и компонентам. Справа собранный продукт проходит соответствующие уровни интеграции, верификации и валидации. Реализация находится в нижней точке V.

V-модель связывает потребность с валидацией, требования с приёмкой, архитектуру с интеграцией, проектирование компонентов с модульными проверками; реализация находится в нижней точке
Что определяется до реализации Чем подтверждается после реализации
Потребность и ожидаемый эффект валидацией результата в пользовательском и продуктовом контексте
Системные требования и критерии приёмки системными и приёмочными проверками
Архитектура и интерфейсы интеграционными, контрактными и архитектурными проверками
Проектирование компонентов модульными, статическими и основанными на свойствах проверками

В NASA Systems Engineering Handbook каждому уровню определения слева соответствует уровень интеграции и проверки справа. Способ проверки предлагают определять одновременно с разработкой требования, чтобы не получить требование, соответствие которому невозможно измерить или доказать.11

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

Я называю такую адаптацию микро-V одного изменения. Это авторская рабочая модель, а не отдельный отраслевой стандарт.

Почему это особенно важно при работе с агентами разработки

Агент ускоряет появление реализации, но сам по себе не доказывает её правильность. В эксперименте OpenAI с полностью агентно создаваемой кодовой базой рост потока изменений сделал человеческую QA-ёмкость ограничением. Команда отвечала на это не более длинными отчётами агентов, а доступными агенту интерфейсом приложения, логами и метриками, воспроизводимыми окружениями и механически исполняемыми архитектурными ограничениями.12

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

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

Практически это означает четыре правила:

  1. До передачи изменения агенту связать существенные критерии с методом проверки и ожидаемыми доказательствами.
  2. Давать агенту автономность до той контрольной точки, где результат можно проверить автоматически или дёшево перепроверить.
  3. Для дорогих и труднообратимых решений не считать тест или самооценку, созданные тем же агентом, достаточным независимым подтверждением.
  4. Оставлять человеку выбор цели, бизнес-валидацию и принятие остаточного риска, даже если техническая верификация автоматизирована.

Как работает контрольная точка (gate)

Четыре соседних понятия описывают разные события:

Термин Что это Обязательно ли решение
Веха (milestone) значимая точка на плане или календаре нет
Экспертная проверка (review) оценка результатов, рисков и доказательств экспертами не всегда
Контрольная точка (gate/KDP) момент, когда уполномоченная сторона определяет следующий шаг да
Базовая версия (baseline) утверждённая версия требований, проектного решения, конфигурации или плана, которая дальше меняется контролируемо нет, это состояние артефакта

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

Решение обычно укладывается в один из пяти вариантов:

  • переходить дальше (go);
  • переходить с условиями (go with conditions): зафиксировать условия и их владельцев;
  • приостановить (hold): собрать недостающие доказательства;
  • вернуть на доработку (rework): вернуться к предыдущему этапу;
  • остановить (stop): закрыть проект или выбрать другой вариант.

В небольшом проекте решение в контрольной точке можно зафиксировать в запросе на включение изменений, согласовании релиза или подтверждении владельца продукта; основанием может служить короткий чек-лист. В регулируемой или критичной для безопасности системе состав участников и форма протокола определяются применимыми стандартами. NASA называет формальную точку такого решения KDP (Key Decision Point).2

Перед экспертной проверкой и решением команда разделяет:

  • входные критерии (entrance criteria): что должно быть готово, чтобы проверку вообще имело смысл проводить;
  • критерии успешного прохождения проверки (success criteria): что должно быть подтверждено по итогам проверки;
  • критерии выхода (exit criteria): какие условия должны быть выполнены, чтобы разрешить переход;
  • доказательства (evidence): чем команда подтверждает выполнение критериев.

Учебный пример: команда готовит тест скорости поиска. По плану он должен пройти на базе из миллиона записей. Команда представляет сборку и план теста, но на экспертной проверке выясняется, что тестовая база пуста. Ответственный откладывает тест. Команда заполняет базу сгенерированными данными и прикладывает отчёт с числом записей. После повторной проверки ответственный разрешает начать тест.

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

Пример минимального маршрута контрольных точек

Для обычного бизнес-продукта полный набор формальных проверок обычно несоразмерен риску. Я бы начинал с такого сокращённого маршрута:

Переход Решение в контрольной точке Что подтверждает готовность
Идея → Исследование или создание начинать работу записаны проблема пользователя, ожидаемый эффект и ограничения; владелец продукта подтвердил задачу
Требования → Архитектура переходить к архитектуре у требований есть критерии приёмки и приоритеты; зафиксировано, кто их согласовал
Проектирование → Реализация начинать реализацию описаны интерфейсы, записаны причины выбора проектного решения и оставшиеся риски
Реализация → Тестирование допускать сборку к системным проверкам сборка воспроизводится и развёрнута в тестовой среде; отчёт подтверждает прохождение автоматических проверок
Тестирование → Внедрение принимать продукт и готовить запуск отчёт тестирования подтверждает выполнение критериев приёмки; зафиксировано, кто принял оставшиеся дефекты и риски
Внедрение → Эксплуатация запускать систему есть результаты проверки развёртывания и отката; мониторинг включён, ответственные за поддержку назначены, инструкции доступны
Изменение в эксплуатации → Новый выпуск выпускать изменение есть результаты тестов затронутых функций и ревью изменений; оставшиеся риски приняты ответственным за выпуск

В итеративной разработке эти решения принимаются чаще и на меньшем объёме работы. Небольшое изменение проверяют по короткому списку критериев готовности; отдельные проверки архитектуры, безопасности и эксплуатации проводят там, где этого требует риск.

Где в SDLC находится безопасность и качество

Безопасность, качество, конфигурационное управление, документация и управление рисками проходят через весь цикл. Качество задаётся требованиями, поддерживается проектными решениями и ревью кода, проверяется тестами и наблюдается по данным эксплуатации. Требования безопасности влияют на архитектуру; журналирование, резервное копирование и восстановление проектируются до развёртывания; результаты проверок и данные эксплуатации возвращаются в требования. Такую сквозную работу описывал исторический NIST SP 800-64 Rev. 2, а актуальное руководство по системному проектированию безопасности содержится в NIST SP 800-160 Vol. 1 Rev. 1.56

Как проверить свой жизненный цикл

Связность процесса можно проверить по шести признакам:

  • ясная связь между целями, требованиями, проектными решениями, кодом и тестами;
  • явные владельцы решений и критериев приёмки;
  • контроль соразмерен риску: высокая цена ошибки требует более тщательной и независимой проверки;
  • возможность вернуться назад, если доказательств недостаточно;
  • воспроизводимые сборка, тестирование и поставка;
  • обратная связь из эксплуатации в новые требования.

У каждого этапа должны быть понятны результат и неопределённость или риск, которые он помогает снять. Контрольная точка отвечает на вопрос: достаточно ли доказательств, чтобы принять решение о следующем шаге?

Источники

  1. IEEE/ISO/IEC 12207-2026, “Software life cycle processes” — действующий стандарт: общий процессный каркас от замысла до retirement, возможность параллельного, итеративного и рекурсивного применения процессов и построения собственной модели из stages. ↩ ↩2 ↩3 ↩4

  2. NASA Software Engineering Handbook, KDP and phase transitions — связь критериев перехода, формальных проверок и Key Decision Points. ↩ ↩2

  3. SEI, “Rethinking the Software Life Cycle” — перечень типичных SDLC activities, его неполнота и оговорка, что он не задаёт конкретную модель разработки. ↩

  4. NIST SP 800-64 Rev. 1 — историческая общая пятифазная модель SDLC: initiation, acquisition/development, implementation, operations/maintenance и disposition. ↩ ↩2 ↩3

  5. NIST SP 800-64 Rev. 2, “Security Considerations in the System Development Life Cycle” — историческое руководство по встраиванию security activities во весь SDLC; NIST отозвал публикацию 31 мая 2019 года как устаревшую. ↩

  6. NIST SP 800-160 Vol. 1 Rev. 1, “Engineering Trustworthy Secure Systems” — актуальное руководство NIST по системной инженерии защищённых и заслуживающих доверия систем на всём жизненном цикле. ↩

  7. NASA Software Engineering Handbook, SWE-019 и Entrance/Exit Criteria, SRR — роль проверки требований и критериев перехода между фазами. ↩

  8. NASA Software Engineering Handbook, CDR criteria — назначение Critical Design Review перед implementation/testing. ↩

  9. NASA Software Engineering Handbook, TRR criteria — условия готовности к тестированию. ↩

  10. NASA Software Engineering Handbook, ORR criteria — условия готовности к operational use. ↩

  11. NASA Systems Engineering Handbook, “The Project Cycle for Major NASA Systems” — Vee как соответствие декомпозиции и определения слева интеграции и проверке справа; метод проверки определяется при разработке требований. ↩

  12. OpenAI, “Harness engineering: leveraging Codex in an agent-first world” — первичный инженерный отчёт о спецификации намерения, feedback loops, машиночитаемом окружении и исполняемых архитектурных ограничениях в полностью агентно создаваемой кодовой базе. ↩

  13. Anthropic, “Demystifying evals for AI agents” — первичный инженерный отчёт о требованиях к evals агентов разработки: определённым задачам, стабильным средам, проверкам кода и оценке фактического результата. ↩