CDIO расшифровывается как:

Conceive → Design → Implement → Operate
Замыслить → Спроектировать → Реализовать → Эксплуатировать

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

Изначально CDIO создавался как модель инженерного образования: инженер должен уметь не только рассчитывать или программировать отдельный компонент, а доводить систему через весь цикл от потребности до эксплуатации. Сейчас рамку можно использовать шире: для проектирования продуктов, программных систем, аппаратных решений и инженерных образовательных программ. citeturn530876search0turn530876search8

1. Conceive — сформировать замысел

Это не просто «придумать идею».

На этапе Conceive определяется, зачем система вообще должна существовать:

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

Результатом становится не архитектура, а осмысленная постановка инженерной задачи.

Например, для системы бронирования отелей:

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

Главный вопрос этапа

Что именно мы строим, для кого, зачем и в каких границах?

Типичные артефакты

problem statement;
stakeholder map;
бизнес-требования;
функциональные и нефункциональные требования;
ограничения;
критерии успеха;
feasibility assessment;
концепция продукта;
первоначальная оценка рисков.

2. Design — спроектировать

На этапе Design замысел превращается в описание будущей системы.

Определяются:

архитектура;
компоненты;
интерфейсы;
модели данных;
алгоритмы;
протоколы взаимодействия;
способы обеспечения безопасности;
механизмы масштабирования;
способы обработки отказов;
технология производства или разработки;
критерии тестирования.

Для программной системы здесь решается:

будет ли система модульным монолитом или набором сервисов;
где хранить данные;
как обеспечить консистентность;
нужен ли Kafka;
где применять Redis;
как организовать API;
как обеспечивать идемпотентность;
как система переживает падение отдельных компонентов;
какие SLO и SLA должны поддерживаться.

Главный вопрос этапа

Как должна быть устроена система, чтобы выполнить сформулированные требования?

Типичные артефакты

архитектурная схема;
ADR;
модель предметной области;
ER-диаграмма;
API-контракты;
sequence diagrams;
threat model;
capacity estimation;
прототипы;
план тестирования;
deployment design.

Важно: Design не равен рисованию диаграммы. Диаграмма является лишь следом принятых решений. Само проектирование состоит в выборе конструкции и фиксации оснований выбора.

3. Implement — реализовать

На этапе Implement проект превращается в физически или программно существующую систему.

Для программного продукта сюда входят:

написание кода;
создание инфраструктуры;
настройка CI/CD;
миграции базы данных;
интеграция компонентов;
автоматическое тестирование;
нагрузочное тестирование;
security testing;
сборка;
развёртывание;
подготовка документации.

Главный вопрос этапа

Как превратить проектное описание в реально работающую систему?

Здесь обнаруживается разрыв между:

системой, которую нарисовали;
системой, которую смогли построить;
системой, которая действительно работает.

Например, архитектор может заложить «exactly-once processing», но при реализации окажется, что внешняя платёжная система не поддерживает идемпотентные операции. Тогда проектное решение придётся пересматривать.

Типичные артефакты

исходный код;
инфраструктурный код;
Docker-образы;
pipeline;
тесты;
миграции;
рабочие сборки;
эксплуатационная документация;
release package;
результаты приёмки.

4. Operate — эксплуатировать

Это принципиально важная часть CDIO.

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

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

На этапе Operate выполняются:

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

Главный вопрос этапа

Как система будет создавать ценность и сохранять работоспособность после запуска?

Типичные артефакты

dashboards;
алерты;
runbooks;
SLI/SLO;
incident reports;
postmortems;
эксплуатационные регламенты;
capacity plans;
планы резервного восстановления;
данные о фактическом использовании.

Сквозной пример: система бронирования отелей

Этап	Что происходит
Conceive	Определяем пользователей, бизнес-модель, правила бронирования, требования по доступности, оплате и отмене
Design	Проектируем модель `Hotel → RoomType → Inventory → Reservation`, API, блокировки остатков, платежи и таймеры бронирования
Implement	Пишем сервисы, создаём базу, интегрируем платёжную систему, настраиваем Kafka, Redis, тестирование и CI/CD
Operate	Следим за ошибками бронирования, задержками оплаты, overselling, нагрузкой, инцидентами и стоимостью инфраструктуры

CDIO не является просто очередным SDLC

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

SDLC

Software Development Life Cycle обычно описывает процесс разработки программного обеспечения:

требования → проектирование → разработка → тестирование → развёртывание → сопровождение

CDIO

CDIO описывает инженерную способность провести систему через весь жизненный цикл:

потребность → замысел → конструкция → воплощение → реальная эксплуатация

Различие можно выразить так:

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

CDIO не ограничивается программным обеспечением. Это может быть:

самолёт;
медицинский прибор;
промышленная линия;
телекоммуникационная система;
банковская платформа;
робот;
городской транспортный комплекс;
программно-аппаратный продукт.

CDIO как образовательная система

Полный CDIO Framework шире четырёх слов.

В нём есть:

CDIO Syllabus: структура компетенций инженера.
CDIO Standards: принципы построения инженерной образовательной программы.
Проектно-ориентированное обучение: знания осваиваются в контексте создания реальных систем.
Оценка результатов: проверяется не только знание теории, но и способность применять её в инженерной деятельности.

CDIO Syllabus включает четыре крупных класса результатов обучения:

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

Официальная инициатива называет CDIO Syllabus центральным элементом рамки и подчёркивает, что он объединяет технические, личные, межличностные навыки и навыки построения систем. citeturn530876search7

Основная идея CDIO

CDIO борется с разрывом между:

«человек знает технические дисциплины»

«человек способен создать работающую инженерную систему».

Можно знать:

алгоритмы;
базы данных;
сети;
паттерны;
Kubernetes;
Kafka;
распределённые транзакции;

но не уметь:

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

CDIO помещает техническое знание внутрь полного инженерного действия. Не «изучить Kafka», а понять:

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

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