Что такое SDLC и как устроен жизненный цикл разработки ПО

SDLC (Software Development Life Cycle) — это в дословном переводе «жизненный цикл разработки программного обеспечения». Технически это структурированный процесс или набор этапов, через которые проходит любой программный продукт или IT-система.

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

Содержание:

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

Что такое SDLC простыми словами

SDLC в русскоязычном сегменте чаще всего расшифровывается как Software Development LifeCycle, хотя в английском может использоваться расшифровка Systems Development Life Cycle или System Design Life Cycle.

SDLC — это концептуальная модель этапов разработки программного обеспечения, которая разбивает процесс создания программ и IT-продуктов на типовые фазы. Чаще всего в источниках описывается модель из семи шагов: 

1. Планирование
2. Сбор и анализ требований
3. Проектирование
4. Реализация
5. Тестирование
6. Развертывание / Внедрение
7. Эксплуатация и сопровождение

Однако в реальности такая разбивка условная и никак не стандартизируется.

Для обозначения того же понятия, что и SDLC, могут использоваться другие термины: ADLC (Application Development Life Cycle) и смежный PDLC (Product Development LifeCycle, он же продуктовый цикл).

SDLC применяется в IT-менеджменте, системной инженерии и проектном управлении для формализации процессов разработки.

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

Ключевые этапы жизненного цикла разработки программного обеспечения

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

1. Этап планирования (Planning)

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

Стартовая команда (руководитель проекта, стейкхолдеры, архитектор) проводит анализ бизнес-целей, оценивает рыночную потребность, формирует предварительный бюджет, календарный план и примерный состав расширенной команды.

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

Ключевые документы этапа: устав проекта, дорожная карта (roadmap), примерная смета, список рисков и план управления ими.

На этом этапе решается судьба проекта: очень много стартапов закрывается именно здесь, потому что выявляется их нецелесообразность. Правильное планирование снижает риск системных ошибок, таких как превышение бюджета, недооценка сроков и т.п. Уже здесь можно определить подходящую модель разработки: каскадный Waterfall, гибкий подход Agile (итеративный подход) или гибрид. От методологии управления будут зависеть все последующие процессы.

Топ причин, по которым стартапы терпят неудачи.

Без четкого планирования дальнейшие этапы превращаются в хаос.

2. Этап сбора и анализа требований (Requirements Gathering & Analysis)

Самый критичный этап: многие ошибки в проектах возникают именно из-за неправильно понятых стартовых требований.

Бизнес-аналитики, владелец продукта и стейкхолдеры проводят интервью, исследования, анкетирование пользователей, анализ конкурентов и существующих систем (продуктов конкурентов). Требования делятся на:

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

Все документируется в виде пользовательских историй (User Stories), кейсов использования (Use Cases), спецификаций (SRS, Software Requirements Specification), бэклога или документа бизнес-требований (BRD, Business Requirements Document).

Обязательно проводится приоритизация и валидация требований с заказчиком. Для этого могут пригодиться методы: MoSCoW, Кано, WSJF, RICE и другие. Если элементов слишком много, то создается матрица прослеживаемости (traceability matrix), чтобы каждое требование можно было отследить вплоть до стадии написания кода и тестирования.

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

По окончании этапа заказчик подписывает документ с требованиями, который становится юридической основой контракта.

3. Этап проектирования (Design)

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

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

UX/UI-дизайнеры создают наброски (упрощенные прототипы) интерфейса программы. Проектируются технические спецификации, ER-диаграммы, UML, последовательности вызовов, механизмы безопасности и масштабирования на случай пикового роста нагрузки.

Артефакты этой стадии жизненного цикла: макеты интерфейсов, схемы связей ключевых элементов и подсистем продукта, API-спецификации, инфраструктурная схема (IaC).

4. Стадия реализации / создания программного обеспечения (Implementation / Coding)

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

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

Что такое пайплайн

Frontend- и backend-программисты, системные администраторы, DevOps-инженеры работают одновременно в спринтах (при гибкой методологии) или последовательно (если используется каскадная модель).

Параллельно организуется документирование кода и создание технической документации продукта для передачи клиенту или для специалистов поддержки.

Ключ к успеху — чистый читаемый код, покрытый тестами.

Самые существенные риски стадии: накопление технического долга и вынужденное изменение архитектуры. Последнее обходится дороже всего.

5. Тестирование (Testing & QA)

Этап, на котором проверяется, соответствует продукт требованиям и ожиданиям стейкхолдеров или нет. Обычно тут в дело вступают тестировщики (QA, QE, SDET) — они выполняют несколько уровней тестирования:

• Unit-тесты (автоматические)
• Интеграционные
• Системные
• Приемочные (UAT)
• Нагрузочный и стресс-тест, устойчивость к взломам (penetration testing) проверка юзабилити.

Баг-трекинг ведется в специальных программах или в хранилищах кода.

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

6. Развертывание / Внедрение (Deployment / Release)

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

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

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

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

7. Эксплуатация и сопровождение (Maintenance & Support)

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

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

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

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

Государственные стандарты и официальные нормы разработки ПО

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

• Международные стандарты: ISO/IEC/IEEE 12207, ISO/IEC/IEEE 15288.
• Российские стандарты: ГОСТ Р ИСО/МЭК 12207-2010, ГОСТ Р 57193-2016 (аналог ISO 15288), ГОСТ Р 56923-2016, а также ГОСТ 34.601-90 (уже устаревший).

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

1. Соглашения — касаются процесса обсуждения требований и приобретения ПО.
2. Процессы оргобеспечения — управление жизненным циклом разработки, организацией инфраструктуры, портфелями проектов, качеством и т.п.
3. Процессы проекта — все, что относится к реализации отдельного проекта.
4. Технические процессы — очень похожи на предметные стадии SDLC, которые мы описали выше, но только в разрезе реализации комплексной системы.

Наглядная схема связи процессов:

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

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

Какие существуют модели SDLC

Наиболее популярные модели SDLC напрямую связаны с концепциями управления.

1. Waterfall (каскадная модель)

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

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

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

2. V-Model (V-образная модель)

Расширение Waterfall с акцентом на тестирование. Каждый этап разработки имеет соответствующий уровень тестирования: unit-, интеграционное и т.д. Завершается все приемочным тестом. Применяется в проектах, где качество и стандартизация предельно критичны: медицина, автомобили, авиация, железнодорожные системы, оборонные системы.

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

Минусы: все та же жесткость «водопада», максимальные сроки реализации.

3. Гибкая разработка (Agile)

Итеративно-инкрементный подход, основанный на Манифесте Agile 2001 года. Разработка идет короткими циклами, например, спринтами по 1-4 недели, с постоянной обратной связью от заказчика, с приоритизацией бэклога и адаптацией к изменениям. Основные фреймворки: Scrum, Kanban, SAFe, LeSS.

Доминирует в продуктовых и IT-компаниях — в бизнес-сегменте. Идеален для стартапов, облачных сервисов, мобильных приложений с часто меняющимися требованиями.

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

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

4. Spiral (Спиральная модель)

Вариант итеративной модели с сильным акцентом на управление рисками. Каждый виток спирали включает 4 фазы: планирование, анализ рисков, разработка прототипа, оценка. После очередного витка принимается решение — продолжать, менять или останавливать проект. Такой подход будет интересен для крупных и сложных проектов, например для enterprise-систем.

Плюсы: раннее выявление и минимизация рисков, возможность отказаться от заведомо провального направления, качественные прототипы для проверки гипотез (MVP-модель).

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

5. Incremental (Инкрементальная модель)

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

Преимущества: относительно быстрые запуск продукта, поэтапное финансирование и наращивание функционала, проще управлять рисками.

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

6. DevOps / Continuous Delivery / DevSecOps

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

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

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

Разные модели часто комбинируют между собой: Agile + DevOps, Waterfall с элементами итераций, спиральная модель внутри крупных Agile-проектов и т.д. Реальный выбор подхода зависит от размера проекта, уровня неопределенности, входящих требований и зрелости команды.

Как Projecto помогает организовать работу в соответствии с моделью жизненного цикла ПО

Projecto — на 100% российский сервис управления задачами и проектами, который легко подстраивается под любую модель разработки ПО: от строгого каскадного до гибких Scrum, Kanban или DevOps.

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

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