Оглавление
Этапы разработки программного обеспечения: порядок, сроки и модели
2 октября 2026
Время чтения: 14 минут
Заказчик приходит с идеей, а через несколько месяцев получает работающую систему. Между этими точками проект проходит шесть этапов разработки программного обеспечения: сбор требований, проектирование, разработку, тестирование, развёртывание и сопровождение.
В статье разбираем этапы по порядку: что происходит на каждом, с каким результатом он закрывается, сколько длится и сколько стоит. Отдельно сравниваем модели жизненного цикла разработки ПО и показываем, как стадии описаны в ГОСТ.
Последовательность взята из нашей практики. По ней AppFox ведёт проекты по разработке программного обеспечения на заказ, от корпоративных систем до замены ERP.
6этапов от идеи до сопровождения
≈3 мес.занимает MVP мобильного приложения
от 1 млн ₽бюджет MVP мобильного приложения
5моделей жизненного цикла в сравнении
Коротко: шесть этапов разработки ПО по порядку
Если нужна только последовательность этапов разработки программного обеспечения, вот она. Каждая карточка ведёт к подробному разбору этапа.
- 01 Сбор требований Выясняем цели бизнеса и сценарии пользователей, собираем ограничения Техническое задание
- 02 Проектирование Выбираем архитектуру и технологии, проектируем интерфейс Архитектура и прототип
- 03 Разработка Пишем код и подключаем внешние системы Рабочая версия продукта
- 04 Тестирование Проверяем, что всё работает по ТЗ и выдерживает нагрузку Отчёт о тестировании
- 05 Развёртывание Запускаем систему в рабочей среде и обучаем сотрудников Система у пользователей
- 06 Сопровождение Исправляем ошибки и выпускаем новые версии Новые версии и план развития
Этапы идут в этом порядке почти в любом проекте. Меняется другое: сколько раз команда проходит этот круг и насколько этапы накладываются друг на друга. За это отвечает модель жизненного цикла, о ней ниже.
Что такое жизненный цикл разработки ПО
Жизненный цикл разработки ПО (по-английски SDLC, Software Development Life Cycle) описывает путь программы от замысла до вывода из эксплуатации.
Этапы и модель
Этапы жизненного цикла разработки ПО отвечают на вопрос «что делать». Модель отвечает на вопрос «в каком порядке и сколько раз». В каскадной модели требования собирают один раз в начале, а тестируют уже готовый продукт. В Scrum те же шесть этапов команда проходит в каждом спринте, который длится не больше месяца.
Процесс разработки программного обеспечения шире этапов. В него входят ещё управление проектом и работа с заказчиком: отчёты и согласования. Этапы описывают, что происходит с продуктом, процесс описывает, как вокруг него работает команда.
Этапы разработки программного обеспечения в правильной последовательности
Дальше подробно о каждом этапе: что делает команда и с каким результатом этап закрывается. Результат здесь главное. Если его нет, переходить к следующему этапу рано.
Этап 1 из 6
Аналитика в MVP: 1–2 недели
Аналитик, владелец продукта
1. Сбор требований и техническое задание
На первом этапе команда выясняет, зачем нужна система и кто будет ею пользоваться. Аналитик проводит интервью с владельцем продукта и будущими пользователями, разбирает текущие процессы компании и собирает ограничения: бюджет, сроки, требования безопасности, обязательные интеграции.
Требования делят на функциональные и нефункциональные. Функциональные описывают, что система делает: «менеджер видит все заказы клиента на одном экране». Нефункциональные описывают, как она это делает: за сколько секунд открывается экран и сколько людей работает в системе одновременно. Про вторые часто забывают, а потом именно они ломают архитектуру.
Итог этапа оформляют в техническое задание. Хорошее ТЗ отвечает на два вопроса: что будет сделано и по каким признакам работу примут. Из чего оно состоит, мы разбирали в статье «Что такое хорошее ТЗ и почему без него не стартуем».
Если у заказчика есть только идея, ТЗ можно заказать отдельно. Так устроена наша услуга подготовки технического задания: документ собираем по ГОСТ 34, ГОСТ 19 или по внутренним стандартам компании.
Результат этапа
Согласованное ТЗ
Критерии приёмки
Этап 2 из 6
Дизайн в MVP: 2–4 недели
Архитектор, дизайнер
2. Проектирование: архитектура, технологии, прототипы
На этапе проектирования требования превращаются в план системы. Архитектор решает, из каких частей она будет состоять, как части обмениваются данными и где работают: в облаке или на серверах заказчика. Здесь же выбирают стек: язык программирования с фреймворками и базу данных.
Параллельно дизайнеры проектируют интерфейс. Сначала появляются схемы экранов и пути пользователя, потом кликабельный прототип. Его показывают заказчику и будущим пользователям до того, как написана первая строка кода.
Исправить ошибку в прототипе дешевле, чем переделывать готовую разработку.
Если продукт мобильный, на этом этапе подключается дизайн мобильного приложения. У iOS и Android свои правила интерфейса, и их учитывают с первых макетов.
Ошибка проектирования проявляется не сразу. Первый релиз работает нормально, а через год каждая новая функция требует переписывать соседние модули. Поэтому архитектуру проверяют на планы развития на несколько лет вперёд, одного текущего ТЗ для этого мало.
Результат этапа
Схема архитектуры
Выбранный стек
Прототип интерфейса
План работ с оценкой сроков
Этап 3 из 6
В MVP: 5–8 недель
Разработчики, тимлид
3. Разработка
Самый длинный этап. Программисты пишут серверную часть и интерфейсы, настраивают базы данных, подключают внешние системы: платёжные сервисы, CRM, 1С, ERP.
Работу делят на небольшие задачи и собирают в итерации. В конце каждой итерации заказчик видит работающую часть продукта, а не процент готовности в отчёте. Код проходит ревью: второй разработчик читает изменения до того, как они попадут в общую ветку.
Из практики AppFox
Если новая система заменяет старую, разработку строят так, чтобы бизнес не останавливался. Для замены ERP мы используем метод Parallel Running: старая и новая системы какое-то время работают параллельно, результаты сверяют, и компания переключается, когда новая система показывает те же цифры.
Результат этапа
Рабочая версия со всеми функциями из ТЗ
Исходный код и документация
Этап 4 из 6
В MVP: 2–3 недели
Тестировщики
4. Тестирование
Тестирование не ждёт конца разработки. Тестировщик подключается, когда готов первый модуль, и проверяет каждую итерацию. Если тестировать только в конце, команда получает большой список ошибок в момент, когда сроки уже поджимают, и часть исправлений задевает архитектуру.
Что проверяют:
- ФункцииКаждая работает так, как описано в ТЗ
- РегрессНовые изменения не сломали старое
- НагрузкаСистема выдерживает расчётное число пользователей
- БезопасностьПрава доступа и хранение персональных данных
- СовместимостьПриложение одинаково работает на разных устройствах и в браузерах
Результат этапа
Отчёт о тестировании
Критичные ошибки закрыты
Приёмочные тесты по ТЗ пройдены
Этап 5 из 6
Подготовка к запуску в MVP: 1–2 недели
DevOps-инженер, менеджер проекта
5. Развёртывание и запуск
Готовую систему переносят в рабочую среду: настраивают серверы с резервным копированием и мониторингом, переносят данные из старых систем. Корпоративное ПО часто запускают через пилот. Сначала систему получает один отдел или филиал, и только после него вся компания.
Вместе с запуском заказчик получает документацию, а его сотрудники проходят обучение. Дальше они могут развивать систему сами: полный контроль над кодом мы передаём.
Если продукт мобильный
У мобильных приложений на этом этапе есть свой шаг: публикация в магазинах приложений и проверка модераторами. Как этот путь выглядит целиком, мы рассказали в статье об этапах разработки мобильного приложения.
Результат этапа
Система в рабочей среде
Данные перенесены
Сотрудники обучены
Документация передана
Этап 6 из 6
После релиза, постоянно
Команда поддержки
6. Сопровождение и развитие
С релиза начинается новая стадия жизни продукта. Появляются реальные пользователи и данные об их поведении. Всплывают ошибки, которые не поймали тесты.
На сопровождении команда:
- исправляет ошибки и следит за стабильностью;
- обновляет библиотеки и закрывает уязвимости;
- выпускает версии под новые требования iOS и Android;
- добавляет функции по плану развития и по данным аналитики.
Кто отвечает за поддержку после запуска, лучше решить ещё на первом этапе. Иначе через полгода выясняется, что продукт работает, а исправлять в нём ошибки некому.
Результат этапа
Новые версии по графику
План развития на следующий период
Сколько длятся этапы и сколько стоит разработка
Сроки и цена зависят от объёма и сложности, поэтому точный ответ даёт только оценка конкретного проекта. Ориентиры по нашим услугам такие:
MVP мобильного приложения
от 1 млн ₽
около 3 месяцев
Первая рабочая версия: главный сценарий, базовый дизайн, тестирование и подготовка к релизу.
Как считаем MVPЦифровое обновление бизнеса: замена устаревших систем
от 1,5 млн ₽
от 3 месяцев
Замена иностранного ПО (Salesforce, SAP, Pega)
от 2 млн ₽
от 4 месяцев
Эксклюзивное решение под ключ
от 2,5 млн ₽
от 6 месяцев
Миграция ERP методом Parallel Running
от 3 млн ₽
от 6 месяцев
MVP мобильного приложения
Сколько длится каждый этап
нижняя граница срокаверхняя граница
Если сложить верхние границы, получится больше трёх месяцев, и это не ошибка. Этапы частично идут параллельно: разработка стартует до того, как нарисованы все экраны, а тестирование начинается по мере готовности модулей.
MVP мобильного приложения
Как распределяется бюджет
Подробно этот расчёт разобран в статье «Сколько реально уходит на MVP».
У проектов крупнее и сроки другие. Вот диапазоны по кейсам из нашего портфолио мобильных приложений:
Модели жизненного цикла разработки ПО
Модель определяет, как этапы связаны во времени. Одни модели проходят этапы один раз и строго по порядку, другие повторяют их короткими циклами. Ниже модели разработки ПО, которые встречаются чаще всего.
Гибкость к изменениям: низкая
Каскадная модель (Waterfall)
Каскадная, или водопадная, модель проходит этапы строго друг за другом: следующий начинается, когда закончен предыдущий. Требования фиксируют в начале, и менять их по ходу дорого.
Подходит
Требования известны заранее и не изменятся, например в государственных заказах или при переносе готовой системы на новую платформу.
Риск
Заказчик видит продукт только в конце, и ошибка в требованиях всплывает поздно.
Гибкость к изменениям: низкая
V-модель
V-модель развивает каскадную: к каждому этапу проектирования она привязывает свой уровень тестирования. Например, требованиям соответствуют приёмочные испытания, а проекту отдельных модулей модульные тесты. Планы проверок пишут одновременно с документами проектирования, ещё до кода.
Подходит
Цена ошибки высока: медицинское ПО, системы управления транспортом.
Риск
К изменениям требований модель приспособлена так же плохо, как каскадная.
Гибкость к изменениям: средняя
Итеративная и инкрементная модель
Продукт строят частями. Сначала выпускают версию с базовыми функциями, затем в каждом цикле добавляют новые и дорабатывают существующие. Каждая итерация проходит все шесть этапов в уменьшенном виде.
Подходит
Продукт можно запускать частями. Так обычно делают MVP: первая версия проверяет гипотезу на реальных пользователях, следующие расширяют продукт по их данным.
Риск
Без плана архитектура не выдержит роста.
Гибкость к изменениям: средняя
Спиральная модель
Спиральную модель описал Барри Боэм в 1986 году. Разработка идёт витками, и в начале каждого витка команда оценивает риски: что может сорвать проект и как проверить это дешевле всего. Часто ответом становится прототип, который строят до основной разработки.
Подходит
Большим проектам с высокой неопределённостью, например при работе с новой для команды технологией.
Риск
Для небольшого продукта анализ рисков на каждом витке обходится слишком дорого.
Гибкость к изменениям: высокая
Scrum
Kanban
Гибкие методологии: Agile, Scrum, Kanban
Agile это набор принципов из манифеста 2001 года. Два из них определяют подход: работающий продукт важнее исчерпывающей документации, готовность к изменениям важнее следования плану.
Scrum делит работу на спринты длиной до месяца, чаще по две недели. В каждом спринте команда планирует задачи, разрабатывает, тестирует и показывает результат заказчику. Сложность задач при этом часто оценивают покерным планированием.
Kanban обходится без спринтов. Задачи идут по доске через колонки статусов, а команда ограничивает число задач, которые находятся в работе одновременно. Его выбирают для непрерывного потока задач, например на сопровождении.
Подходит
Требования будут меняться: новый продукт или рынок, который ещё изучают.
Риск
Если объём не зафиксирован, итоговую сумму сложнее предсказать.
Как выбрать модель
| Модель | Гибкость | Когда подходит | Главный риск |
|---|---|---|---|
| Каскадная | низкая | Требования известны и не изменятся | Ошибка в требованиях всплывает в конце |
| V-модель | низкая | Высокая цена ошибки, нужна строгая проверка | Изменения по ходу обходятся дорого |
| Итеративная | средняя | Продукт можно запускать частями | Без плана архитектура не выдержит роста |
| Спиральная | средняя | Большой проект с технологическими рисками | Слишком дорогая для небольших проектов |
| Agile (Scrum, Kanban) | высокая | Требования будут меняться | Итоговый бюджет сложнее предсказать |
Как работаем мы
На практике модели часто совмещают. В наших проектах выбор зависит от задачи: Agile, Waterfall или их сочетание. Частый гибрид выглядит так: требования и архитектуру фиксируют по-каскадному в начале, а разработку ведут спринтами. Заказчик заранее знает объём и бюджет и при этом после каждого спринта видит работающий результат.
Этапы разработки ПО по ГОСТ
В российских стандартах этапы называют стадиями. Для госзаказчиков и многих крупных компаний ГОСТ обязателен, поэтому полезно понимать, как стадии стандартов соотносятся с этапами выше.
ЕСПД
Программы
ГОСТ 19.102-77: стадии разработки программ
5стадий
- Техническое задание
- Эскизный проект
- Технический проект
- Рабочий проект
- Внедрение
Испытания программы входят в рабочий проект. Стандарт разрешает исключить эскизный проект, а в технически обоснованных случаях и технический: на схеме они с пунктирной рамкой.
Автоматизированные системы
Действует с 30.04.2022
ГОСТ Р 59793-2021: стадии создания автоматизированных систем
8стадий
- Формирование требований к АС
- Разработка концепции АС
- Техническое задание
- Эскизный проект
- Технический проект
- Рабочая документация
- Ввод в действие
- Сопровождение АС
До этого стандарта в документах чаще всего ссылались на ГОСТ 34.601-90. Испытания и опытная эксплуатация входят в стадию ввода в действие.
Как стадии стандартов соотносятся с шестью этапами:
| Этап | ГОСТ 19.102-77 | ГОСТ Р 59793-2021 |
|---|---|---|
| Сбор требований | Техническое задание | Формирование требований, концепция АС, техническое задание |
| Проектирование | Эскизный и технический проект | Эскизный и технический проект |
| Разработка | Рабочий проект | Рабочая документация |
| Тестирование | Рабочий проект: испытания программы | Ввод в действие: испытания, опытная эксплуатация |
| Развёртывание | Внедрение | Ввод в действие |
| Сопровождение | Отдельной стадии нет | Сопровождение АС |
Содержание работ совпадает, различается состав документов. По ГОСТ результат каждой стадии оформляют документами установленного вида, в коммерческих проектах состав документов согласуют с заказчиком.
Типичные ошибки на разных этапах
- Этап 1Начинать разработку без ТЗКоманда пишет код по устным договорённостям, а на приёмке выясняется, что стороны понимали задачу по-разному.
- Этап 1Не описывать нефункциональные требованияО нагрузке и требованиях безопасности узнают после запуска, когда менять архитектуру уже дорого.
- Этап 2Пропускать прототипОшибку в логике экранов находят в готовом коде, и исправлять её приходится в нём.
- Этап 4Оставлять тестирование на конецОшибки копятся, и релиз превращается в аврал.
- Весь проектЗатягивать согласованияДаже хорошо спланированный проект срывает сроки, если каждый экран согласуют неделю.
- Этап 6Считать релиз финаломБез плана сопровождения продукт быстро устаревает.
Чек-лист: можно ли переходить к следующему этапу
Перед переходом проверьте, что у предыдущего этапа есть результат. Пункты можно отмечать прямо здесь.
Главное
- Сбор требований
- Проектирование
- Разработка
- Тестирование
- Развёртывание
- Сопровождение
Основные этапы разработки программного обеспечения идут в одной последовательности. Модель жизненного цикла меняет только то, сколько раз команда проходит этот круг и как этапы пересекаются.
Каждый этап закрывается конкретным результатом: ТЗ, прототипом, рабочей версией, отчётом о тестировании, запущенной системой. Если результата нет, следующий этап начинается на догадках, и ошибка обходится дороже с каждым шагом.
FAQ
Сколько этапов в разработке программного обеспечения?
Чаще всего выделяют шесть: сбор требований, проектирование, разработку, тестирование, развёртывание и сопровождение. Встречаются схемы с пятью или семью этапами: анализ иногда отделяют от сбора требований, а развёртывание объединяют с тестированием. По ГОСТ 19.102-77 стадий пять, по ГОСТ Р 59793-2021 восемь.
Какой этап самый важный?
Сбор требований. Ошибка в ТЗ переходит во все следующие этапы, и чем позже её находят, тем дороже исправление. Самый долгий этап при этом разработка: в MVP мобильного приложения на неё уходит 5–8 недель из примерно трёх месяцев.
Сколько длится разработка ПО?
MVP мобильного приложения занимает около трёх месяцев. Корпоративная система под ключ или миграция ERP занимают от шести месяцев. Точный срок называют после сбора требований.
Можно ли пропустить какой-то этап?
Сократить можно, пропустить нельзя. Для небольшой доработки проектирование займёт день, а не месяц, но без него новая функция может сломать старые. ГОСТ 19.102-77 тоже разрешает убрать эскизный, а в обоснованных случаях и технический проект, но техническое задание и рабочий проект с испытаниями остаются.
Чем этапы разработки отличаются от модели разработки?
Этапы описывают, какую работу нужно сделать. Модель описывает порядок: пройти этапы один раз подряд, как в каскадной модели, или повторять их короткими циклами, как в Scrum.
Нужно ли техническое задание при работе по Agile?
Нужно, но другое. Вместо полного ТЗ на весь проект составляют документ с целями, границами продукта, нефункциональными требованиями и списком задач (бэклогом). Детали задач уточняют перед каждым спринтом. Без такого документа трудно оценить бюджет и проверить, что сделано именно то, что требовалось.
Хотите обсудить ваш проект?
Свяжитесь с нами для получения бесплатной консультации:
