Модели жизненного цикла для конструирования
Доступ к данным — Основы БД, SQL, конфигурации. Карта — о разделе.
Модели жизненного цикла — Waterfall, Agile и гибриды
От модели жизненного цикла (ЖЦ) зависит когда вы пишете код, сколько его переписываете и какие документы требуют до первой строки. На экзамене по конструированию часто спрашивают Waterfall, инкремент, RAD, спираль, CBSE — как они задают ритм реализации.
С чего начать новичку
Модель ЖЦ отвечает на вопрос: в каком порядке и крупными или мелкими кусками мы проходим планирование → проект → код → тест → внедрение.
Методология (Scrum, Kanban) отвечает: как команда организует работу внутри спринта или потока задач. Можно вести инкрементный ЖЦ по Scrum — это нормальная пара.
| Слово | Запомнить одной фразой |
|---|---|
| Waterfall (каскад) | Сначала всё спроектировали, потом долго пишем код, потом тестируем |
| Инкремент | Каждый релиз добавляет новую функцию для пользователя |
| Итерация | Повторяем цикл "спроектировали → закодировали → проверили"; функция может не расти, но качество растёт |
| RAD | Быстро показать экран заказчику, много готовых UI-компонентов |
| Спираль | На каждом витке снимаем риски прототипом, потом пишем prod-код |
| CBSE | Система = покупные и готовые компоненты + наш "клей" |
Модель жизненного цикла — как распределены фазы (линейно, витками, порциями).
Scrum/Kanban — как команда работает внутри итераций. Один и тот же инкрементный ЖЦ можно вести по Scrum или без него.
Общая карта SDLC — в 7-03/1. Здесь — угол конструирования: что меняется в объёме кода, в рефакторинге и в тестах.
Три стратегии конструирования (IEEE/EIA 12207.2)
Помимо "именованных" моделей (Waterfall, спираль…) стандарт IEEE/EIA 12207.2 выделяет стратегии — как именно наращивается код относительно требований:
| Стратегия | Все требования в начале? | Несколько циклов конструирования? | Промежуточное ПО заказчику? |
|---|---|---|---|
| Однократный проход (водопад) | Да | Нет | Нет |
| Инкрементная (запланированное улучшение) | Да | Да | Может быть |
| Эволюционная | Нет | Да | Да |
Инкрементная — требования зафиксированы заранее, функциональность наращивается релизами по плану (релиз 1 — каталог, релиз 2 — оплата…). Эволюционная — требования уточняются по ходу версий; близка к спирали и прототипированию. В индустрии "инкремент" часто смешивают с Agile-наращиванием — на экзамене уточняйте формулировку: фиксированные требования (инкремент 12207.2) или эволюция требований (эволюционная).
В инкрементных и итеративных моделях между поставками закладывают время на рефакторинг и погашение технического долга — иначе каждый новый инкремент дороже предыдущего. В каскаде риск — "заморозить" дизайн до кодирования и накопить долг к фазе тестирования. Практики XP (TDD, CI, рефакторинг, code review) — в методологии; приёмы — в Методы рефакторинга программного кода.
Сводная таблица моделей
| Модель | Ритм конструирования | Когда уместна | Главный риск для кода |
|---|---|---|---|
| Waterfall / V | Один большой блок после проекта | Стабильное ТЗ, регуляторика | "Замороженный" дизайн устарел к концу кодирования |
| Инкремент / итерация | Порции + наращивание | Продукт, эволюция | Техдолг между инкрементами без рефакторинга |
| RAD | Быстрые прототипы → prod | UI-критичные MVP, CRUD | Прототип без архитектуры в production |
| Спiral (Boehm) | Прототип на рисках → prod-код | Высокая неопределённость, Р&D | Бесконечные витки "ещё один POC" |
| CBSE | Интеграция + доработка компонент | Много COTS, ERP, интеграции | Версионный ад и "склеивание" API |
| Прототипирование | Throwaway или эволюционный код | Неясные требования | Путаница прототипа и финальной системы |
Классический (каскадный) Waterfall
Идея: фазы последовательно — требования → проект → кодирование → тест → внедрение. Выход одной фазы — вход следующей; возврат "назад" формален и дорог.
| Для конструирования | Следствие |
|---|---|
| Код после детального проекта | Меньше "переписывания архитектуры в коде", больше следования spec |
| Изменения дороги | ТЗ и проект должны быть согласованы до старта кодирования |
| Большой объём кода разом | Нужны coding standards, review, статический анализ до merge |
| Длинный цикл без релиза | Интеграция "Big Bang" — первые баги всплывают поздно |
Где встречается: госконтракты, embedded, медтехника (IEC 62304), авионика — там, где нужна traceability требование → модуль → тест.
Для разработчика: конструирование — "исполнение чертежа". Отклонение от проекта — через change request (заявку на изменение требований), а не тихий рефакторинг в пятницу.
Госконтракт на АСУ — год пишут ТЗ и проект, полгода — код без релиза пользователям, потом три месяца приёмочных тестов.
Плюс: всё прослеживается от пункта ТЗ до модуля.
Минус: если за год рынок изменился, часть кода устарела ещё до первого запуска — правки дороги.
V-модель и конструирование
V-модель — надстройка: каждому уровню разработки соответствует уровень тестирования.
| Уровень разработки | Парный тест | Кто на конструировании |
|---|---|---|
| Модули / unit design | Unit-тесты | Разработчик пишет вместе с кодом |
| Интеграция модулей | Integration | Dev + QA после сборки |
| Система | System | QA по сценариям из ТЗ |
| Приёмка | UAT | Заказчик / пользователи |
Практический смысл: тест-план и кейсы для модульного уровня закладывают при проектировании интерфейса, а не "когда всё закодировали". Подробнее — White-box — тестирование потоков управления и данных, Документация тестировщика.
Инкрементная и итерационная модель
Инкремент — продукт растёт функционально: каждый кусок добавляет новую возможность для пользователя.
Итерация — повторение цикла "спроектировали → закодировали → проверили" над одной областью или всем продуктом; функциональность может не расти, но качество и полнота растут.
Инкремент 1: auth + профиль → релиз 0.1 (можно войти)
Инкремент 2: каталог → релиз 0.2 (можно смотреть товары)
Инкремент 3: корзина + оплата → релиз 1.0 (можно купить)
Итерация внутри инкремента 2:
Sprint A — API каталога
Sprint B — фильтры + пагинация
Sprint C — hardening, NFR
| Аспект | Для конструирования |
|---|---|
| Короткие волны кода | Меньше "длинных веток", чаще merge в main |
| Рефакторинг между инкрементами | Модульность критична — иначе каждый инкремент ломает предыдущий |
| CI обязателен | Каждый инкремент — потенциально поставляемый артефакт |
| Definition of Done | Код + тесты + review + документация API |
Scrum — частный случай итераций фиксированной длины (спринт) с инкрементом на выходе. Kanban — непрерывный поток без жёсткого "конца спринта", но конструирование всё равно порциями по карточкам.
Маркетплейс: в 0.1 пользователь только регистрируется; в 0.2 смотрит каталог без покупки; в 1.0 платит.
Каждый инкремент — рабочий релиз на staging/prod.
Код каталога пишут, когда auth уже в main — иначе некому "войти и посмотреть товар".
Инкремент отвечает на "что нового в продукте"
итерация — "какой очередной цикл работы". Один инкремент часто занимает несколько итераций.
Итерации экономят переделки на поздних фазах, но не отменяют их: при частой смене приоритетов отбрасывают уже написанный код, а команда откладывает рефакторинг ("всё равно переделаем в следующем спринте").
Явные DoD, регресс и выделенное время на техдолг снижают этот эффект.
RAD (Rapid Application Development)
Идея: сжать время до видимого результата за счёт прототипов, генераторов, готовых UI-kit и параллельных мини-команд (users + developers together).
Фазы RAD (классическая схема)
| Фаза | Содержание | Конструирование |
|---|---|---|
| Business modeling | Потоки данных, роли | Минимум кода |
| Data modeling | ERD, сущности | Миграции, ORM-модели |
| Process modeling | Сценарии, экраны | Прототип UI |
| Application generation | Сборка из компонент | CRUD, low-code, scaffolding |
| Testing & turnover | Обратная связь пользователей | Доработка + "закалка" |
| Плюс | Риск |
|---|---|
| Заказчик видит UI через недели, а не месяцы | "Прототип в prod" без слоя домена |
| Reuse UI-kit, ORM, admin-панелей | Техдолг, если нет явного этапа refactor |
| Параллельные команды по модулям | Несогласованные контракты между командами |
RAD в COCOMO II — Application Composition — отдельный режим оценки (много готовых частей, мало "с нуля"). См. 7-13/1.
Когда уместен: внутренние админки, MVP с типовым CRUD, пилоты с жёстким дедлайном. Когда опасен: ядро домена с регуляторикой без проектирования границ.
Спиральная модель (Barry Boehm)
Идея: каждый виток спирали — мини-проект: цели → риски → разработка/прототип → план следующего витка. Риски снимают до массового кодирования.
Что кодируют на разных витках
| Виток | Тип кода | Пример |
|---|---|---|
| Ранний | Throwaway prototype | UI на макетах, spike на новом протоколе |
| Средний | Пилотные модули | Интеграция с внешней системой-риском |
| Поздний | Production code | Полное покрытие тестами, NFR, hardening |
Хорошо для: заказных систем с высокой неопределённостью (новый домен, жёсткие NFR, много внешних интеграций). Плохо без дисциплины: бесконечные POC без решения "выбрали архитектуру — пишем prod".
Связь с Agile: спринтовый "spike" — родственник риск-ориентированного витка; разница в том, что спираль явно ставит анализ рисков перед объёмным кодом.
Спираль — не отдельная "третья модель" наряду с каскадом и инкрементом: это итерационный цикл с акцентом на рисках и контрольных точках (COO → LCO → LCA → IOC → FOC). Типовой список рисков Боэма и контрольные точки COO–FOC — в жизненном цикле ПО.
Прототипирование (throwaway и evolutionary)
| Тип | Суть | Конструирование |
|---|---|---|
| Throwaway (быстрый) | Прототип выбрасывают после уточнения требований | Код "на коленке", без тестов — не в prod |
| Evolutionary (эволюционный) | Прототип дорастают до системы | Нужны тесты и рефакторинг с первых витков |
Типичная ошибка: throwaway-прототип "вдруг" попал в production, потому что "и так работает". На экзамене просят различить типы и назвать критерий (выбрасываем vs эволюционируем).
Компонентно-ориентированная модель (CBSE)
Идея: система = сборка готовых (COTS) и заказных компонентов с опубликованными интерфейсами. Конструирование смещается от "писать всё" к интегрировать и адаптировать.
Жизненный цикл CBSE
| Этап | Работа конструктора |
|---|---|
| Поиск COTS | Оценка лицензий, SLA, roadmap вендора |
| Адаптация | Adapter/Facade, маппинг DTO, версионирование API |
| Разработка недостающего | Только "дыры" в функциональности — по контракту |
| Сборка | Интеграционные и контрактные тесты (Интеграционное тестирование) |
CBSE как модель ЖЦ ≠ компонентная архитектура (REP/CCP/CRP в Принципы компонентно-ориентированной архитектуры): первое — процесс поставки; второе — принципы упаковки модулей в репозитории.
Экономика: reuse снижает Size в COCOMO (множитель RUSE), но добавляет интеграционные риски и зависимость от чужих релизов.
RUP — конструирование в итерациях
Rational Unified Process (RUP) — итерационный и инкрементный процесс (2–6 недель на итерацию). Каждая итерация включает анализ, проектирование, реализацию, тестирование, интеграцию и заканчивается работающей системой. RUP согласован с ISO 12207, ISO 9000, CMMI.
Жизненный цикл делится на четыре стадии (каждая — контрольные точки milestone):
| Стадия | Фокус | Результаты для конструктора |
|---|---|---|
| Inception (начало) | Границы проекта, бизнес-кейс | Черновик use case (10–20%), прототип, план итераций |
| Elaboration (уточнение) | Архитектура, снятие рисков | Базовая архитектура, use case ~80%, оценки по use case |
| Construction (конструирование) | Массовая реализация | Инкременты по use case, готовность к beta |
| Transition (ввод) | Beta, деплой, обучение | Релиз, миграция данных, приёмка |
На стадии Construction итерации инкрементные (новая функциональность) и повторяющиеся (улучшение качества). Подробнее про Scrum/Kanban/XP как альтернативы — 7-03.
Стратегии выбора модели (для экзамена и практики)
| Контекст | Частый выбор | Почему для конструирования |
|---|---|---|
| Госконтракт, жёсткое ТЗ | Waterfall + V | Traceability, формальная приёмка |
| Продукт, меняющиеся требования | Инкремент / Scrum | Короткие циклы кода + feedback |
| Неясный UI, много UX-рисков | RAD / throwaway prototype | Быстрая проверка гипотез |
| Новая технология, Р&D, интеграции | Spiral / spikes | Риски до массового кодирования |
| ERP, CRM, много SaaS | CBSE + Agile внутри | Меньше "с нуля", больше glue-кода |
| Сжатые сроки MVP | RAD с явным refactor-sprint | Не оставлять прототип навсегда |
Гибрид "Agile внутри, Waterfall снаружи" для ГИС — 7-03/2: команда работает спринтами, а заказчик принимает версии по регламенту.
Типичные ошибки
- Назвать Scrum "моделью ЖЦ" — это фреймворк; под ним может быть инкремент, спираль или гибрид.
- Путать инкремент и итерацию — см. таблицу выше.
- Спiral без выхода — бесконечные прототипы вместо prod-кода.
- CBSE = "скачать библиотеку" — без квалификации, версий и контрактных тестов интеграция ломается на каждом апдейте.
Частые вопросы на экзамене
Чем Waterfall отличается от V-модели?
Waterfall — порядок фаз; V — парность уровней разработки и тестирования.
Когда RAD не подходит?
Когда доменная логика сложна, регуляторика жёсткая, а "быстрый UI" не снимает риски ядра системы.
Что такое один виток спирали?
Цели → анализ рисков (часто прототип) → разработка и тест витка → план следующего витка.
Рекомендую читать дальше
| Тема | Материал |
|---|---|
| Планирование сроков | Планирование конструирования |
| Стандарты стадии | Конструирование, 12207 |
| Модульность при инкрементах | Связность и сцепление |
| Экономика | COCOMO II |
| Scrum, Kanban, XP | 7-03/1 |