Разработка ПО: этапы и жизненный цикл
Жизненный цикл разработки (SDLC) — это путь продукта от идеи до вывода из эксплуатации через этапы: требования, проектирование, разработка, тестирование, релиз, поддержка. Поверх них накладывается модель — порядок прохождения: жёстко (Waterfall) или циклами (Agile).
Code Pilots с 2014 года занимается заказной разработкой полного цикла — от MVP до highload-продуктов, и почти все провалы, которые мы видели у новых клиентов, имели один корень: процесса не было или он был выстроен неправильно. Ниже — этапы, модели, артефакты и как выбрать своё.
В статье
- Что такое SDLC и зачем он бизнесу
- Этапы разработки: полный цикл
- Этап → артефакт → роль → риск
- Модели жизненного цикла
- Сравнительная таблица моделей
- Agile vs Waterfall на практике
- Методологии и практики поверх цикла
- Артефакты и документация
- Роли в команде полного цикла
- Что значит «полный цикл» у студии
- Цикл для highload и интеграций
- От чего зависят стоимость и сроки
- Чек-лист: как выбрать модель
- Коротко о главном
- Часто задаваемые вопросы
Что такое жизненный цикл разработки ПО (SDLC) и зачем он бизнесу
SDLC (Software Development Life Cycle, жизненный цикл разработки ПО) — это структурированный процесс создания программного продукта, разбитый на последовательные этапы, от первого замысла до момента, когда продукт окончательно снимают с эксплуатации. Каждый этап имеет вход (что нужно, чтобы начать), результат (что получаем на выходе) и ответственных.
Зачем вообще загонять творческую, по сути, работу в рамки процесса? Затем же, зачем чертёж дому. Без процесса разработка превращается в набор героических подвигов отдельных программистов, где никто не знает, что будет завтра, а заказчик впервые видит продукт за неделю до дедлайна — и обнаруживает, что построили не то. SDLC решает три бизнес-задачи разом.
Предсказуемость. Когда работа разбита на этапы с понятными результатами, проект перестаёт быть чёрным ящиком. Видно, на какой стадии он находится, что сделано и что осталось.
Управление рисками. Каждый этап — это точка, где можно поймать ошибку, пока она дёшева. Неверно понятое требование стоит часа работы аналитика. То же требование, обнаруженное после релиза, стоит переписывания модуля, простоя и репутации. Чем раньше этап, тем дешевле на нём ошибка — эта зависимость не линейная, а экспоненциальная.
Качество и повторяемость. Процесс позволяет встроить контроль качества, документацию и проверки в каждый шаг, а не надеяться, что в финале всё как-нибудь сойдётся.
Отдельно стоит развести два термина, которые постоянно путают. Жизненный цикл разработки ПО (SDLC) описывает создание самого софта: требования, код, тесты, релиз.
Жизненный цикл продукта (PDLC, Product Development Life Cycle) шире — он охватывает ещё исследование рынка, продуктовую стратегию, развитие и в конце уход продукта с рынка. Разработка живёт внутри продуктового цикла как его инженерная часть. Хороший подрядчик держит в голове оба: он не просто пишет код по ТЗ, а понимает, какую задачу бизнеса продукт решает и как будет жить дальше.
Этапы разработки ПО: полный жизненный цикл
Канонический SDLC — это семь-восемь этапов. Конкретный набор и названия у разных команд отличаются (кто-то объединяет анализ с планированием, кто-то выделяет дизайн в отдельную фазу), но логика общая и неизменная. Пройдёмся по каждому: что на нём происходит, кто его ведёт, что получается на выходе и где главная опасность.
1. Планирование и сбор требований
Старт проекта. Здесь определяют, что вообще строим и зачем: бизнес-цели, ожидаемый результат, бюджетные и временные рамки, ключевые риски. Заказчик приносит проблему («нужна система, которая автоматизирует приём заявок»), команда превращает её в осмысленную задачу: кто пользователи, какие у них сценарии, что считать успехом.
На этом же этапе проводят предпроектное исследование — разбирают предметную область, конкурентов, существующие системы, с которыми придётся интегрироваться. Чем сложнее продукт, тем важнее эта работа: для нагруженной системы с десятком интеграций пропустить дискавери — значит заложить мину под весь проект.
Кто ведёт: бизнес-аналитик, продакт-менеджер, иногда архитектор. Результат: концепция проекта, верхнеуровневые требования, оценка осуществимости. Главный риск: построить не то — когда команда бросается решать неправильно понятую задачу.
2. Анализ и формализация требований
Требования из общих формулировок превращаются в точный документ, по которому можно проектировать и кодить. Их делят на два типа, и оба критичны.
Функциональные требования описывают, что система делает: пользователь регистрируется по номеру телефона, администратор видит список заявок, отчёт выгружается в Excel.
Нефункциональные требования (NFR) описывают, какой система должна быть: как быстро отвечает, сколько одновременных пользователей держит, насколько защищена, какова допустимая доля простоя.
Их любят забывать — и зря: именно NFR определяют архитектуру. Систему, спроектированную под сотню пользователей, не получится «дописать» до миллиона; её придётся переделывать. Для нагруженных продуктов нефункциональные требования вообще выходят на первый план — время ответа под пиком и устойчивость к нагрузке там определяют половину успеха.
Результат этапа фиксируют в техническом задании (ТЗ) или его международном аналоге — SRS (Software Requirements Specification). Это не бюрократия ради бюрократии: ТЗ — единственная защита обеих сторон от ситуации «я имел в виду совсем другое» через полгода работы.
Кто ведёт: системный и бизнес-аналитики. Результат: ТЗ/SRS, спецификации, прототипы экранов, глоссарий. Главный риск: размытые или меняющиеся требования. По данным многолетних исследований PMI и Standish Group, дефекты требований — одна из главных причин провала IT-проектов. Сэкономили на аналитике — оплатите переделками.
3. Проектирование и дизайн
Этап делится на две части, которые часто путают, хотя они про разное.
Проектирование архитектуры — это инженерное решение о том, из каких компонентов состоит система, как они общаются, где хранятся данные, как обеспечивается отказоустойчивость и масштабирование.
Архитектор выбирает стек, проектирует базу данных, описывает API-контракты. Различают верхнеуровневое проектирование (общая структура системы) и низкоуровневое (устройство отдельных модулей). Ошибка архитектуры на нагруженном проекте — самая дорогая из возможных: это не баг, который правится за день, а фундамент, который придётся перезаливать.
UX/UI-дизайн — проектирование того, как с продуктом взаимодействует человек: логика экранов, прототипы, визуальный стиль, дизайн-система. Технически безупречный продукт с неудобным интерфейсом проигрывает; пользователь не прощает трения.
Кто ведёт: архитектор, UX/UI-дизайнер, ведущие разработчики. Результат: схема архитектуры, выбранный стек, ER-диаграммы, API-контракты, дизайн-макеты и UI Kit. Главный риск: архитектура не выдержит реальной нагрузки и интеграций; неудобный интерфейс.
4. Разработка: написание кода и код-ревью
Самый объёмный этап — обычно около половины всего бюджета проекта. Программисты пишут клиентскую часть (то, что видит пользователь) и серверную (логика, база данных, API), подключают сторонние сервисы и интеграции. Работа делится между frontend-, backend- и mobile-разработчиками; на сложных продуктах их несколько на каждом направлении.
Ключевая практика зрелой команды на этом этапе — код-ревью: каждый кусок кода перед попаданием в общую ветку читает другой разработчик. Через pull request он отлавливает ошибки, проверяет соответствие стандартам и не даёт расти техническому долгу. Команда, которая «экономит» на ревью, экономит на собственном будущем: непроверенный код копит проблемы, которые всплывут на тестировании или, хуже, в проде.
Разработку почти никогда не ведут одним монолитным куском. Её бьют на итерации (спринты) по одной-две недели, в конце каждой — работающий фрагмент, который можно показать и проверить. Это снижает риск «полгода писали, а оказалось не то».
Кто ведёт: разработчики, тимлид. Результат: рабочий код, прошедший ревью. Главный риск: технический долг и срыв сроков из-за недооценённой сложности.
5. Тестирование: от модульного до нагрузочного
Контроль качества проверяет, что продукт работает так, как задумано, и не ломается на краю. Тестирование многослойно:
- модульное — проверка отдельных функций и компонентов;
- интеграционное — как компоненты работают вместе;
- системное — поведение всей системы целиком;
- приёмочное — соответствие требованиям с точки зрения заказчика.
Для сложных и нагруженных продуктов сюда добавляются нагрузочное тестирование (что будет при пике трафика) и тестирование безопасности — то, что массовые гайды обычно опускают, а зря: уязвимость, найденная злоумышленником, а не вашим QA, обходится несопоставимо дороже.
Важнейшая оговорка: тестирование — не финальный рубеж перед релизом, а процесс, идущий параллельно разработке. Чем позже находят дефект, тем дороже он стоит.
Кто ведёт: QA-инженеры (мануальные и автоматизаторы). Результат: тест-план, тест-кейсы, отчёты о дефектах, протестированная сборка. Главный риск: баги в проде и недотестированные сценарии на пике нагрузки.
6. Релиз и развёртывание
Продукт выкатывают в продакшен. Настраивают инфраструктуру, разворачивают серверы, конфигурируют мониторинг. В зрелых командах это не ручной подвиг в ночь перед релизом, а отлаженный конвейер автоматической сборки и доставки (CI/CD), где выкатка и откат — рутинная, предсказуемая операция.
Кто ведёт: DevOps-инженер, команда. Результат: продукт в продакшене, релизная документация, runbook, настроенный пайплайн. Главный риск: падение при выкатке, отсутствие плана отката.
7. Поддержка, сопровождение и борьба с техническим долгом
Релиз — не финиш, а смена режима. Продукт начинает жить: выходят новые версии iOS, Android и браузеров, устаревают библиотеки, всплывают баги, которые не нашли на тестах, пользователи просят новое. Поддержка — это мониторинг, исправление дефектов, обновления безопасности и развитие функциональности.
Отдельная и недооценённая часть сопровождения — управление техническим долгом. Техдолг — это накопленные в спешке компромиссы в коде и архитектуре: то, что когда-то сделали «временно и побыстрее», а оно осталось.
Сам по себе он не катастрофа, это нормальный побочный продукт разработки. Катастрофа — когда его не замечают и не гасят. Зрелый процесс предполагает инвентаризацию техдолга, оценку риска по каждому пункту и плановое погашение прямо в спринтах, а не «когда-нибудь потом, когда всё перепишем» (этого «потом» не наступает никогда). Кстати, команда без джунов плодит техдолг заметно медленнее — просто потому, что меньше учится за счёт вашего проекта.
Кто ведёт: команда поддержки, DevOps. Результат: стабильно работающий и развивающийся продукт, SLA, дашборды мониторинга. Главный риск: деградация без поддержки, неконтролируемый техдолг.
8. Вывод из эксплуатации
Этап, который опускают почти все, хотя он реален. Рано или поздно продукт устаревает, его заменяют новым или закрывают направление. Грамотный вывод из эксплуатации — это миграция данных, корректное отключение, уведомление пользователей, архивация. Брошенная без вывода система превращается в забытый сервер с устаревшим софтом — то есть в дыру в безопасности.
Этап → артефакт → роль → риск: всё в одной таблице
Этапы удобно держать в голове сразу в четырёх измерениях: что делаем, что получаем на выходе, кто отвечает и чего боимся. Такой связки нет ни у одного конкурента в выдаче — а она экономит часы объяснений на старте проекта.
| Этап | Главный артефакт | Кто ведёт | Доля бюджета | Главный риск |
|---|---|---|---|---|
| Планирование | Концепция, оценка | Аналитик, PM | ~5–10% | Решаем не ту задачу |
| Анализ требований | ТЗ / SRS, прототипы | Аналитик | ~10–15% | Размытые требования |
| Проектирование | Схема архитектуры, дизайн-макеты | Архитектор, дизайнер | ~10–15% | Не выдержит нагрузку |
| Разработка | Код, прошедший ревью | Разработчики | ~40–55% | Техдолг, срыв сроков |
| Тестирование | Тест-план, отчёты о дефектах | QA | ~10–15% | Баги в проде |
| Релиз | CI/CD-пайплайн, runbook | DevOps | сквозная статья | Падение при выкатке |
| Поддержка | SLA, мониторинг | Команда, DevOps | отдельный бюджет | Деградация, техдолг |
Проценты здесь — ориентир по структуре, а не наша смета: реальные доли плавают от проекта к проекту. Но один вывод из таблицы железобетонен: разработка (написание кода) — это лишь половина проекта. Когда подрядчик предлагает выкинуть аналитику, дизайн и тестирование, чтобы «вышло дешевле», он вырезает не балласт, а ровно те этапы, которые определяют, заработает продукт или будет лежать в сторе мёртвым грузом.
Модели жизненного цикла разработки ПО
Этапы отвечают на вопрос «что делаем». Модель отвечает на «в каком порядке и как часто». Все модели — это точки на шкале между двумя крайностями, а самый короткий цикл на этой шкале — выпустить MVP и учиться на реальных пользователях: пройти этапы один раз строго по очереди или ходить по ним кругами, выпуская продукт частями.
Понимание моделей — это то, что отличает разговор с подрядчиком на равных от ситуации, когда вам продают «у нас аджайл» как магическое заклинание.
Waterfall (каскадная модель) — и главный миф индустрии
Классика: этапы идут строго друг за другом, как вода по каскаду. Закончили требования — перешли к проектированию, и назад дороги нет. Каждый этап полностью завершается и документируется до начала следующего.
Плюсы: предельная прозрачность и предсказуемость, полная документация, легко планировать бюджет и сроки — если ничего не меняется. Минусы: негибкость; любое изменение требований на середине ломает каскад и стоит дорого; рабочий продукт виден только в конце, когда менять что-либо уже поздно и больно. Когда оправдана: стабильные, зафиксированные требования — госконтракты, регуляторика, интеграция в готовую систему с жёсткими рамками.
Любопытный исторический факт, который полезно знать, чтобы не повторять чужих ошибок. Каскадную модель принято возводить к статье Уинстона Ройса 1970 года. Ирония в том, что Ройс в ней как раз предупреждал об опасности однопроходного подхода и предлагал делать минимум две итерации и возвращаться к ранним этапам.
Сам термин «waterfall» он не использовал — его закрепили позже, в 1976 году, Белл и Тэйер. То есть индустрия полвека ссылается на работу, которая призывала к ровно противоположному. Когда кто-то противопоставляет «надёжный водопад» «модному аджайлу», стоит помнить: даже отец водопада был за итеративность.
V-образная модель
Развитие каскада, где каждому этапу разработки сопоставлен уровень тестирования: требованиям — приёмочные тесты, архитектуре — системные, модулям — модульные. Тесты планируют заранее, параллельно с проектированием.
Плюсы: высокое качество за счёт раннего планирования проверок, прослеживаемость требований. Минусы: та же негибкость, что у Waterfall. Когда оправдана: системы с высокой ценой ошибки — медицинский софт, авионика, embedded, банковский бэкенд.
Итеративная модель
Продукт создаётся повторяющимися циклами. В каждой итерации проходят мини-версию полного цикла и улучшают результат предыдущей. Первая итерация даёт грубую, но работающую версию, следующие её шлифуют.
Плюсы: ранняя обратная связь, риски всплывают рано. Минусы: требует сильной архитектуры, заложенной заранее, иначе переделки съедят выигрыш.
Инкрементная модель
Функциональность наращивается частями-инкрементами: сначала ядро, потом по куску. Каждый инкремент — законченный рабочий модуль, который добавляется к продукту.
Плюсы: ценность поставляется рано, бюджет можно распределять по частям. Минусы: нужна модульная архитектура и хорошее планирование, чтобы куски состыковались. На практике итеративный и инкрементный подходы часто сочетают: наращивают функциональность кусками и шлифуют каждый по кругу.
Спиральная модель
Итерации, в которых обязательным элементом каждого витка является анализ рисков. Виток спирали проходит четыре сектора: планирование, анализ рисков, разработку и оценку. Чем дальше от центра, тем больше вложено и тем серьёзнее ставки.
Плюсы: системное управление рисками. Минусы: дорогая и тяжёлая, избыточна для простых проектов. Когда оправдана: крупные, дорогие проекты с высокой неопределённостью и серьёзными рисками. Предложил модель Барри Бом в 1986 году — и она остаётся эталоном risk-driven подхода.
Agile: не модель, а образ мышления
Agile — это семейство гибких подходов, выросшее из «Манифеста гибкой разработки» (февраль 2001 года, горнолыжный курорт Сноуберд в Юте, семнадцать человек, четыре ценности и двенадцать принципов). Суть: короткие итерации, рабочий софт важнее исчерпывающей документации, реакция на изменения важнее следования первоначальному плану, постоянное вовлечение заказчика.
Плюсы: гибкость, ранняя и регулярная поставка ценности, продукт развивается вместе с пониманием задачи. Минусы: сложнее зафиксировать бюджет и срок «под ключ», требует зрелой команды и вовлечённого заказчика. Agile — это зонтик, под которым живут конкретные фреймворки.
Scrum
Самый распространённый фреймворк Agile. Работа идёт спринтами (обычно одна-четыре недели), в конце каждого — готовый инкремент. Есть роли (Product Owner отвечает за бэклог и приоритеты, Scrum Master — за процесс, команда — за реализацию), артефакты (бэклог продукта и спринта, инкремент) и церемонии (планирование спринта, ежедневный пятнадцатиминутный стендап, ревью, ретроспектива).
Когда оправдан: продуктовая разработка с меняющимися требованиями, где важна регулярная поставка.
Kanban
Визуализация потока задач на доске с колонками (сделать → в работе → готово) и лимитами на число одновременных задач (WIP-лимиты). В отличие от Scrum — без жёстких спринтов, непрерывным потоком.
Когда оправдан: поддержка и поток задач с непредсказуемым приоритетом, где спринты только мешают.
RAD и гибридные модели
RAD (Rapid Application Development) делает ставку на быстрое прототипирование и переиспользование готовых компонентов. Быстро, но требует опытной команды и плотного вовлечения заказчика.
Гибриды — то, как на самом деле работает большинство серьёзных команд. Самый частый — условный «Water-Scrum-Fall»: снаружи, на уровне контракта и документации, проект выглядит как каскад (зафиксированный скоуп, этапы, приёмка), а внутри разработка ведётся спринтами по Agile. В вебе любят противопоставлять Agile и Waterfall как «или-или», но в enterprise с регуляторикой и живыми требованиями честный ответ почти всегда — гибрид.
Сравнительная таблица моделей
Признать, что «модель надо выбирать под проект», легко. Дать инструмент для выбора — сложнее, и поэтому сводной таблицы нет ни у одного конкурента в топе. Вот она.
| Модель | Гибкость к изменениям | Объём документации | Управление рисками | Предсказуемость бюджета | Когда виден результат | Лучше всего для |
|---|---|---|---|---|---|---|
| Waterfall | Низкая | Высокий | Слабое | Высокая (если скоуп заморожен) | В конце | Фикс-скоуп, регуляторика, госзаказ |
| V-образная | Низкая | Высокий | Среднее (через тесты) | Высокая | В конце | Медицина, авионика, embedded |
| Итеративная | Средняя | Средний | Среднее | Средняя | После каждой итерации | Продукты с уточняемой логикой |
| Инкрементная | Средняя | Средний | Среднее | Средняя | По мере инкрементов | Поэтапный запуск функциональности |
| Спиральная | Средняя | Высокий | Сильное | Средняя | После каждого витка | Крупные, рисковые, дорогие проекты |
| Agile / Scrum | Высокая | Низкий–средний | Сильное (риски всплывают рано) | Гибкая | Каждый спринт | Продуктовая разработка, стартапы, MVP |
| Kanban | Очень высокая | Низкий | Среднее | Гибкая | Непрерывно | Поддержка, поток задач |
Agile vs Waterfall на практике: когда план выигрывает, а когда убивает проект
Спор «Agile против Waterfall» в интернете обычно ведётся на уровне религии: одни считают каскад бюрократическим динозавром, другие — Agile прикрытием для бардака. Истина, как водится, зависит от проекта, и вот честные ориентиры из практики.
Waterfall (и его строгая родня) выигрывает, когда требования действительно зафиксированы и не будут меняться: вы интегрируетесь в государственную систему с утверждённым регламентом, делаете продукт под сертификацию, работаете по контракту с жёстким ТЗ и фиксированной приёмкой. Здесь предсказуемость и полная документация — ценность, а гибкость — лишний риск.
Waterfall убивает проект, когда требования на старте известны лишь наполовину — то есть в большинстве продуктовых историй. Стартап, новый сервис, выход на новый рынок: вы узнаёте, что на самом деле нужно пользователю, только показав ему первую версию. Заморозить требования в этой ситуации — значит потратить полгода на тщательную реализацию гипотезы, которая может оказаться неверной.
Agile выигрывает там, где есть неопределённость и нужно учиться на ходу: продукт с гипотезами, MVP, регулярные релизы, тесная работа с заказчиком. Он же буксует, когда у заказчика нет ресурса вовлекаться (Agile требует постоянной обратной связи), когда нужен железно зафиксированный бюджет «под ключ» или когда команда понимает под Agile только стендапы и доску, а не дисциплину.
На практике большинство наших проектов — гибрид: дискавери и архитектуру мы фиксируем основательно, как в каскаде (на сложном продукте нельзя начинать кодить без понятой архитектуры), а саму разработку ведём спринтами, гибко. Это не беспринципность, а инженерная честность: брать у каждой модели то, что работает под конкретную задачу.
Методологии и практики поверх жизненного цикла
Здесь живёт путаница, которую тиражируют почти все статьи: DevOps, CI/CD, Lean и XP называют «моделями разработки» в одном ряду с Waterfall и Scrum. Это ошибка. Модель ЖЦ определяет, как организованы этапы. А DevOps, CI/CD, Lean и XP — это практики и культура, которые накладываются поверх любой модели и улучшают то, как команда работает.
DevOps — культура и набор практик, стирающие стену между разработкой (Dev) и эксплуатацией (Ops). Цель — быстрая, частая и надёжная поставка изменений в продакшен. DevOps не заменяет Scrum или Waterfall, он делает доставку их результата управляемой.
CI/CD — техническое сердце DevOps. Непрерывная интеграция (CI) автоматически собирает и прогоняет тесты на каждый коммит, не давая коду «протухнуть». Непрерывная доставка/развёртывание (CD) автоматизирует выкатку, превращая релиз из стресса в рутину.
Lean — подход из бережливого производства: устранять всё, что не создаёт ценности, и принимать решения как можно позже, когда информации больше.
XP (Extreme Programming) — набор инженерных практик: парное программирование, разработка через тесты (TDD), частые мелкие релизы, постоянный рефакторинг. XP — про то, как писать код качественно, а не про то, как организовать проект.
QA и DevOps — это сквозные процессы, а не этапы в конце
Самое дорогое и самое живучее заблуждение в разработке звучит так: «сначала всё напишем, потом протестируем и задеплоим». На линейной схеме SDLC тестирование рисуют одной коробочкой ближе к концу, и заказчик невольно так его и воспринимает. На практике при таком подходе баги копятся месяцами и обрушиваются все разом перед релизом, когда их исправление стоит дороже всего.
В зрелом процессе тестирование начинается вместе с разработкой и идёт параллельно ей — это называют сдвигом тестирования влево (shift-left). Код проверяется по мере написания, автотесты гоняются на каждый коммит, дефекты ловятся на свежем коде, пока разработчик ещё помнит контекст.
DevOps работает так же: конвейер сборки и доставки настраивают с первого дня, а не «когда дойдём до релиза». Когда QA и DevOps встроены в процесс с самого начала, релиз перестаёт быть лотереей. Когда их прикручивают в последний момент — релиз превращается в аврал с переработками. Если подрядчик говорит, что тестирование начнётся «ближе к концу», это повод насторожиться.
Артефакты и документация по этапам
Каждый этап оставляет после себя документы и материалы — артефакты. Они нужны не для отчётности, а чтобы знание о проекте не жило в голове одного человека (который завтра уйдёт в отпуск или сменит работу).
- Требования: ТЗ / SRS, спецификации, нефункциональные требования, глоссарий.
- Планирование: бэклог продукта, user story (короткие формулировки «как пользователь, я хочу…»), дорожная карта, оценка.
- Проектирование: схема архитектуры, ER-диаграммы базы данных, API-контракты, дизайн-макеты и UI Kit.
- Разработка: код, pull request, результаты код-ревью.
- Тестирование: тест-план, тест-кейсы, баг-репорты.
- Релиз: релиз-чеклист, релизная документация, runbook (инструкция по эксплуатации).
- Поддержка: SLA, дашборды мониторинга, отчёты по инцидентам.
Стандарты: ГОСТ 19, ГОСТ 34, ISO/IEC 12207 — когда они реально нужны
Тему стандартов в популярных статьях обходят стороной — то ли боятся занудства, то ли не знают. Между тем для части заказчиков это вопрос допуска к проекту, а не теории.
ГОСТ 19 (ЕСПД, Единая система программной документации). Регламентирует документацию на программы. Конкретно ГОСТ 19.102-77 описывает пять стадий разработки: техническое задание, эскизный проект, технический проект, рабочий проект, внедрение.
ГОСТ 34 (ГОСТ 34.601-90). Стадии создания автоматизированных систем (АС) — это уже не отдельная программа, а система целиком. Восемь стадий: от формирования требований к АС и разработки концепции до ввода в действие и сопровождения. Часто требуется в госзаказе.
ISO/IEC 12207. Международный стандарт процессов жизненного цикла ПО. Описывает процессы — основные, вспомогательные и организационные, — а не жёсткую последовательность стадий. Гибкая рамка, совместимая с любой моделью.
ISO/IEC 15288. Шире — процессы жизненного цикла систем (системная инженерия), для сложных комплексов «железо плюс софт плюс процессы».
Практический вывод без занудства: ГОСТ-документация нужна не всем. Если вы делаете коммерческое мобильное приложение или SaaS — она вам, скорее всего, ни к чему, и навязывать её было бы лишней тратой. Но если проект для госзаказчика, для объекта критической инфраструктуры (КИИ) или под отраслевую сертификацию — соответствие ГОСТ становится обязательным, и это закладывают в процесс с самого начала.
Кто делает продукт: роли в команде полного цикла
За каждым этапом стоят люди, а не абстрактные «разработчики». Полный состав команды выглядит так:
- Бизнес- и системный аналитик — превращает идею в требования и ТЗ.
- Проджект- и продакт-менеджер — отвечают за сроки, бюджет, коммуникацию и продуктовое видение.
- Архитектор — проектирует структуру системы и принимает ключевые технические решения.
- UX/UI-дизайнер — проектирует интерфейс и пользовательский опыт.
- Разработчики — frontend, backend, mobile; пишут код.
- QA-инженер — мануальный тестировщик и/или автоматизатор.
- DevOps-инженер — инфраструктура, CI/CD, мониторинг.
- Тимлид — техническое лидерство и качество в команде.
На небольшом проекте один человек закрывает несколько ролей, на крупном — на роль приходится несколько специалистов. Но сам набор ролей не сокращается: уберёте аналитика — получите сырые требования, уберёте QA — получите баги у пользователей.
Что значит «полный цикл» у студии и как это снижает риск
«Разработка полного цикла» давно стала строчкой на каждом втором лендинге, и от частоты употребления почти потеряла смысл. А смысл простой и важный (подробнее — в материале про кастомную разработку ПО): все роли, нужные на всех этапах SDLC, находятся в одной команде и работают над проектом вместе.
Чтобы понять, зачем это, посмотрите на альтернативу. Когда аналитику отдают одному подрядчику, дизайн — фрилансеру, разработку — другой команде, а тестирование — третьей, на каждой передаче возникает «испорченный телефон».
Требования, которые аналитик понял правильно, доходят до разработчика искажёнными. Дизайнер рисует то, что невозможно реализовать в выбранной архитектуре. QA тестирует не то, что имел в виду заказчик. Каждый стык между подрядчиками — это точка потери информации и зона, где все кивают друг на друга, когда что-то идёт не так.
Когда команда полного цикла внутри одной студии, этих стыков нет: аналитик, архитектор, дизайнер, разработчики, QA и DevOps работают в общем контексте и несут общую ответственность за результат.
Именно поэтому выбор модели — вопрос важный, но вторичный. Самая правильная методология не спасёт, если в команде нет аналитика или к тестированию относятся по остаточному принципу. Мы в Code Pilots держим полный состав внутри и работаем командой уровня middle+ и senior, без джунов «на обучении» за счёт клиента — для сложных продуктов с интеграциями и нагрузкой это условие, при котором цикл проходится без катастроф на стыках.
Как меняется жизненный цикл для highload и интеграционных продуктов
Все рассмотренные этапы одинаковы что для простого приложения, что для нагруженной платформы — но акценты смещаются радикально, и об этом не пишет никто из конкурентов. Для продукта, который должен держать десятки и сотни тысяч пользователей или плотно интегрирован с внешними системами, цикл меняется на нескольких этапах.
На проектировании появляется нагрузочное моделирование. Архитектуру выбирают не «чтобы работало», а под целевые показатели задержки (latency) и пропускной способности (throughput). Решения о кешировании, очередях, шардировании базы принимаются здесь — переиграть их потом стоит как новый проект.
На анализе требований нефункциональные требования выходят на первый план. Для обычного приложения NFR — приятное дополнение. Для highload это половина успеха: сколько одновременных пользователей, какое допустимое время ответа под пиком, какой уровень доступности по SLA.
Интеграции превращаются в отдельный поток требований. Каждая внешняя система — это чужой API со своими ограничениями, лимитами и отказами, которые нужно проектировать и тестировать как полноценную часть продукта, а не «прикрутить в конце».
Тестирование обязательно включает нагрузочное и стресс-тестирование: систему проверяют не только на корректность, но и на поведение под пиком и за его пределами.
Поддержка превращается в capacity-планирование: нагрузка растёт, и инфраструктуру масштабируют заранее, а не когда всё уже легло. Это профильная для нас зона: приложение VK Fest, например, должно было выдерживать всплески десятков тысяч установок на старте — и такие пики закладываются в архитектуру на самом первом этапе, а не лечатся после падения.
От чего зависят стоимость и сроки разработки
Точную цену проекта заочно не назовёт никто — она считается по конкретным требованиям, и любая цифра «на глаз по телефону» будет либо случайной, либо маркетинговой. Зато понятно, какие факторы её формируют:
- Объём и сложность функциональности — число функций, ролей, сценариев.
- Сложность бизнес-логики — простой каталог и финансовая система с расчётами это разные вселенные.
- Количество интеграций — каждая внешняя система добавляет работы и рисков.
- Нагрузка и требования к безопасности — highload и регуляторика поднимают планку архитектуры и тестирования.
- Состав и уровень команды — сильные специалисты дороже в час, но дешевле в пересчёте на результат: меньше переделок и техдолга.
- Выбранная модель и характер требований — фиксированный скоуп и меняющийся продукт оцениваются по-разному.
Оценку мы выделяем в отдельный шаг — оценка проекта и прототип за 5 дней. Оценивают проект несколькими методами: экспертно (на опыте похожих задач), по аналогии с прошлыми проектами или через декомпозицию — разбивая работу на мелкие задачи и оценивая каждую (в Agile для этого используют Story Points).
И главный вывод из всего цикла: дешевле в итоге обходится не самый низкий ценник в смете, а грамотно пройденный процесс — с нормальной аналитикой на входе, сквозным QA по дороге и контролем техдолга. Экономия на этапах оплачивается переделками, просто счёт приходит позже.
Чек-лист: как выбрать модель разработки под ваш проект
Пройдите по вопросам — ответы покажут, к какой модели вам ближе.
- Требования зафиксированы и точно не изменятся? Да (контракт, регуляторика, интеграция в готовую систему) → Waterfall или V-образная. Нет → итеративные подходы или Agile.
- Высокая ли цена ошибки? Медицина, финансы, безопасность, КИИ → добавьте V-образную или спиральную модель с усиленным тестированием и анализом рисков.
- Это новый продукт с гипотезами? Да (стартап, MVP, новый рынок) → Agile/Scrum, чтобы учиться на реальной обратной связи.
- Готов ли заказчик постоянно вовлекаться? Нет ресурса на регулярную обратную связь → Agile в чистом виде не взлетит, нужен гибрид с фиксированными контрольными точками.
- Нужен ли железно зафиксированный бюджет «под ключ»? Да → фиксируйте скоуп и работайте ближе к каскаду или по гибриду с зафиксированным дискавери.
- Это поддержка и поток разноприоритетных задач? Да → Kanban.
Если по ответам вырисовывается смесь — это нормально и даже хорошо: гибрид (зафиксированные дискавери и архитектура плюс гибкая разработка спринтами) подходит большинству реальных проектов.
Коротко о главном
Жизненный цикл разработки — это карта пути продукта от идеи до вывода из эксплуатации. Этапы (требования → проектирование → разработка → тестирование → релиз → поддержка) отвечают на «что делаем», модели (Waterfall, итеративные, Agile) — на «в каком порядке», а стандарты, артефакты и роли наполняют процесс содержанием.
Но три вещи важнее выбора красивой методологии: полный состав команды без дыр в ролях, отношение к QA и DevOps как к сквозным процессам и честная аналитика на входе. Именно на этом проекты выживают или разваливаются — независимо от того, что написано в графе «методология» вашего договора.
Если перед вами продукт со сложной логикой, интеграциями или нагрузкой и нужно провести его через весь цикл без провалов на стыках — расскажите о задаче. Подскажем подходящую модель, соберём команду полного цикла и подготовим оценку по вашему ТЗ.
Часто задаваемые вопросы
Классически — семь-восемь: планирование, анализ требований, проектирование, разработка, тестирование, релиз, поддержка и вывод из эксплуатации. Пропускать их соблазнительно, но обманчиво: чаще всего предлагают выкинуть аналитику или тестирование. Эти этапы не исчезают — просто их работу за вас сделают пользователи через баги и переделки, и это выйдет дороже.
Нет. Модель жизненного цикла (Waterfall, итеративная, спиральная) определяет порядок прохождения этапов. Agile — это философия гибкой разработки, а Scrum и Kanban — конкретные фреймворки внутри неё. DevOps, CI/CD, Lean, XP — это уже практики, которые накладываются поверх любой модели. Путаница в этих понятиях — верный признак неопытного подрядчика.
Отталкивайтесь от требований: если они жёсткие и неизменные — ближе к Waterfall; если продукт новый и будет уточняться — Agile и итеративные модели; если высока цена ошибки — добавьте элементы спиральной или V-модели. На практике чаще всего работает гибрид. Подробный чек-лист выбора — в разделе выше.
Простой продукт или MVP — несколько месяцев, средний с интеграциями — около полугода, сложный или enterprise — год и больше. Срок зависит от объёма и сложности функциональности, числа интеграций, требований к нагрузке и безопасности, а также от выбранной модели. Точную оценку дают по конкретному ТЗ.
Для коммерческого приложения или SaaS — обычно нет, это была бы лишняя бюрократия. Соответствие ГОСТ 19 (ЕСПД) или ГОСТ 34 становится обязательным для госзаказа, объектов критической инфраструктуры и проектов под отраслевую сертификацию. Если ваш проект из этой категории, требования к документации закладывают в процесс с самого начала.
