В апреле 2026 года вышла новая редакция ISO/IEC/IEEE 12207, стандарта процессов жизненного цикла программных систем. ISO показывает ISO/IEC/IEEE 12207:2026 как опубликованную вторую редакцию, а страницу ISO/IEC/IEEE 12207:2017 уже относит к предыдущей, отозванной редакции.

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

ISO 12207:2026 не является методологией разработки. Он не выбирает за команду Scrum, Kanban, DevOps, внутренний продуктовый процесс или контрактную модель поставки. Сам ISO отдельно указывает, что стандарт не требует конкретной модели жизненного цикла, методологии, метода моделирования или техники выбора модели. Стандарт задает карту инженерной работы, но не превращает эту карту в единственный маршрут.

Если коротко, новая редакция важна не потому, что «теперь все надо делать по ISO». Она важна потому, что язык жизненного цикла ПО стал ближе к реальности современных программных систем: они живут внутри больших систем, зависят от инфраструктуры, данных, внешних сервисов, поставщиков, цепочек сборки, эксплуатации, сопровождения, рисков безопасности и решений, которые нужно уметь объяснить позже.

Что действительно изменилось в редакции 2026

В предисловии ISO/IEC/IEEE 12207:2026 новая редакция названа технически переработанной. Сам стандарт перечисляет несколько главных изменений:

1. уточнены отдельные технические процессы, включая анализ бизнес-цели или миссии, определение архитектуры системы, реализацию, интеграцию, эксплуатацию и сопровождение;

2. улучшены отдельные процессы технического управления, включая управление рисками и управление конфигурацией;

3. обновлены ключевые понятия в разделе 5, в том числе итеративность, рекурсивность, системы систем и характеристики качества;

4. добавлен новый материал о понятиях и определении системы, а также расширено описание гибких подходов, применения процессов и системных понятий;

5. переработано информативное приложение D о модельно-ориентированной системной и программной инженерии.

Это не отказ от версии 2017 года и не список совершенно новых процессов. Скорее, стандарт точнее описывает то, как на практике уже устроены современные программные системы.

Как читать ISO 12207:2026

Лучше всего читать ISO 12207 не как перечень документов, которые надо подготовить, а как перечень работ, которые важно не потерять.

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

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

В приложении B приведен подробный перечень типовых рабочих продуктов для процессов: артефактов, записей, информационных материалов и хранилищ данных. Для большинства проектов этот перечень будет избыточен как прямой чек-лист, но полезен как подсказка: какие следы обычно оставляет каждый процесс.

Поэтому практический вопрос звучит не так:

«Как внедрить ISO 12207?»

А так:

«Какие инженерные работы у нас уже есть, как они называются, чем подтверждаются и где между ними теряются связи?»

Программная система шире кода

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

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

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

Здесь полезно не смешивать две вещи. Инструкция оператора может быть элементом системы, если она действительно участвует в работе системы. Но документ, модель или запись проверки, которые только описывают систему, обычно являются информационными материалами, а не самой системой.

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

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

Если команда называет системой только репозиторий, она теряет половину жизненного цикла: данные, интерфейсы, окружение, эксплуатационные ограничения, поставщиков, средства сборки и проверки, сценарии сопровождения. ISO 12207:2026 помогает обсуждать это.

Технические процессы: от замысла до сопровождения

В ISO 12207:2026 технические процессы находятся в разделе 6.4. Для практиков особенно важны несколько процессов, которые прямо выделены в предисловии новой редакции.

Анализ бизнес-цели или миссии

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

Для команды это защита от привычного сбоя: сразу бежать в backlog, минуя вопрос «какую проблему мы вообще решаем». На этом уровне еще не нужно спорить о конкретной кнопке, API или архитектурном шаблоне. Нужно понять, что меняется в деятельности организации, какие цели или ограничения появились, какие варианты решения вообще допустимы.

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

Архитектура системы

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

Хорошая архитектурная работа отвечает на вопросы:

• какие интересы заинтересованных сторон важны;

• какие системные требования влияют на архитектуру;

• какие внешние системы и интерфейсы надо учитывать;

• какие альтернативы рассматривались;

• почему выбранное решение приемлемо;

• как архитектурные решения будут проверяться.

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

Реализация

Реализация в стандарте шире, чем написание нового кода. В тексте ISO 12207:2026 говорится, что элементы системы могут быть созданы, смоделированы, адаптированы, приобретены или повторно использованы.

Отдельно стандарт допускает, что при выборе проектных альтернатив команда может рассматривать повторное использование готовых решений, приобретение внешних компонентов, а также low-code и no-code инструменты. Это не рекомендация «делать low-code». Это признание того, что современная реализация часто собирает систему из разных источников.

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

Интеграция

Интеграция в ISO 12207:2026 описывает сборку системных элементов в более полную систему или конфигурацию. Для ПО стандарт прямо связывает интеграцию с частыми или непрерывными практиками разработки и с управлением конфигурацией.

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

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

Проверка соответствия требованиям, валидация и приемка

В русском тексте полезно жестко развести три вещи.

Верификация (проверка соответствия требованиям) отвечает на вопрос: соответствует ли система, элемент или материал заданным требованиям и характеристикам.

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

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

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

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

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

Для команды это означает простую вещь: релиз не закрывает жизненный цикл. Он открывает другую часть жизненного цикла, где инженерная ответственность становится еще заметнее.

Техническое управление: не отчетность, а дисциплина

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

Управление решениями

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

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

Управление рисками

Управление рисками в разделе 6.3.4 ISO 12207:2026 описано как непрерывный процесс: риски выявляют, анализируют, обрабатывают и мониторят. Важное понятие здесь — профиль рисков: живое представление о рисках, их источниках, вероятности, последствиях, порогах и состоянии обработки.

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

Управление конфигурацией

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

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

В ISO 12207:2026 также упоминается перечень состава ПО, или SBOM, который является одним из инструментов управления составом ПО и прослеживаемостью зависимостей.

Информация, измерения и качество

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

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

Обеспечение качества не стоит понимать как синоним тестирования. В ISO 12207:2026 это процесс, который помогает дать уверенность, что требования качества выполняются, а процессы и результаты соответствуют принятым правилам. Проверка соответствия требованиям, валидация и обеспечение качества связаны, но это не одно и то же.

Как применять процессы: параллельно, итеративно и рекурсивно

Один из устойчивых мифов о стандартах жизненного цикла звучит так: если есть список процессов, значит их надо выполнять по порядку. ISO 12207:2026 говорит обратное - процессы могут применяться в разное время, параллельно, итеративно и рекурсивно.

Итеративно — значит команда возвращается к требованиям, архитектуре, реализации, интеграции и проверкам по мере уточнения решения.

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

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

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

Гибкие подходы, применение процессов и характеристики качества

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

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

Системы систем

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

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

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

Без этой рамки обсуждение быстро становится бытовым: «у нас упала интеграция», «поставщик поменял API», «инфраструктура не готова», «эксплуатация не приняла». Системный язык позволяет перевести эти фразы в управляемые связи.

Модели как рабочий носитель инженерных связей

В ISO 12207:2026 есть информативное приложение D о модельно-ориентированной системной и программной инженерии. Ключевое слово здесь — информативное: это не требование срочно купить инструмент моделирования и перенести туда весь проект.

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

Модель полезна не потому, что она «модель», а если помогает быстрее и надежнее отвечать на вопросы:

• какое требование связано с этим архитектурным решением;

• какой элемент системы реализует это требование;

• какая проверка подтверждает соответствие требованиям;

• какая валидация подтверждает пригодность;

• какой риск связан с этим интерфейсом;

• какая конфигурация была поставлена в эксплуатацию;

• что изменится, если заменить внешний сервис или библиотеку.

Если модель не отвечает на такие вопросы, она может быть просто дорогой картинкой. Если отвечает — она становится частью инженерной памяти проекта.

Связь с ISO 15288:2023

ISO 12207:2026 не стоит читать отдельно от системной инженерии. ISO 15288:2023 задает процессы жизненного цикла систем, а ISO 12207 фокусируется на программных системах. В самом тексте ISO 12207:2026 прямо сказано, что процессы в обоих документах имеют одинаковые цели и результаты, но отличаются действиями и задачами для программной и системной инженерии.

Для практической команды это означает: если ПО является частью более крупной системы, язык ISO 12207 помогает говорить с программной стороны, а язык 15288 — с системной. Между ними не должно быть стены.

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

Что можно сделать команде

Ниже не план «внедрения ISO». Это нормальная инженерная ревизия после выхода новой редакции.

1. Проверить словарь.

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

2. Назвать границы рассматриваемой системы.

   Отделить саму систему от внешних взаимодействующих систем, обеспечивающих систем, инфраструктуры, поставщиков и рабочей среды. Это сразу прояснит часть рисков и интерфейсов.

3. Описать реальную модель жизненного цикла.

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

4. Зафиксировать правила адаптации процессов.

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

5. Проверить прослеживаемость связей.

   Минимальная цепочка: потребность -> требование -> архитектурное решение -> элемент системы -> реализация -> проверка соответствия требованиям -> валидация -> приемка -> эксплуатационная обратная связь. Не обязательно делать громоздкую матрицу. Но команда должна уметь восстановить эти связи.

6. Расширить управление конфигурацией за пределы Git.

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

7. Связать решения, риски, измерения и качество.

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

8. Проверить связь с ISO 15288.

   Если ваша программная система является частью более крупной системы, проверьте, где заканчивается язык ISO 12207 и где начинается системный уровень ISO 15288. Особенно это важно для архитектуры, интерфейсов, эксплуатации, безопасности, валидации, приемки и ответственности поставщиков.

9. Выбрать одну область для моделей.

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

Вывод

ISO 12207:2026 стоит читать не как бюрократический шаблон, а как обновленный инженерный язык.

Он не говорит команде, каким процессным ритуалом жить. Он задает более важный вопрос: умеете ли вы назвать и связать работу, без которой программная система не становится надежным продуктом или сервисом?

Где у вас граница системы? Откуда берутся требования? Чем обоснована архитектура? Как управляются риски? Что входит в поставку? Какая конфигурация принята? Что проверено? Что валидировано? Что принято пользователем или заказчиком? Что происходит в эксплуатации? Как сопровождение возвращает знания обратно в разработку?

Если после чтения ISO 12207:2026 команда сможет честно ответить на эти вопросы, стандарт уже принес пользу даже без большой программы «внедрения ISO».