SDLC (Software Development Life Cycle) - это в дословном переводе "жизненный цикл разработки программного обеспечения". Технически это структурированный процесс или набор этапов, через которые проходит любой программный продукт или IT-система.
Разработка ПО может регламентироваться полноценными государственными стандартами, но даже они определяют этапы создания программных продуктов в общих чертах.
Что такое SDLC простыми словами
SDLC в русскоязычном сегменте чаще всего расшифровывается как Software Development LifeCycle, хотя в английском может использоваться расшифровка Systems Development Life Cycle или System Design Life Cycle.
SDLC - это концептуальная модель этапов разработки программного обеспечения, которая разбивает процесс создания программ и IT-продуктов на типовые фазы. Чаще всего в источниках описывается модель из семи шагов:
Однако в реальности такая разбивка условная и никак не стандартизируется.
Для обозначения того же понятия, что и SDLC, могут использоваться другие термины: ADLC (Application Development Life Cycle) и смежный PDLC (Product Development LifeCycle, он же продуктовый цикл).
SDLC применяется в IT-менеджменте, системной инженерии и проектном управлении для формализации процессов разработки.
Основная цель SDLC - систематизировать разработку программного продукта и сделать ее воспроизводимой. За счет этого SDLC помогает снизить риски, повысить качество, а также оптимизировать стоимость программ, как любых других продуктов на свободном рынке.
#1. Этап планирования (Planning)
Этот этап закладывает фундамент всего проекта. Основная цель фазы планирования - понять, стоит ли вообще начинать разработку и можно ли ее реализовать в рамках имеющихся ресурсов.
Стартовая команда (руководитель проекта, стейкхолдеры, архитектор) проводит анализ бизнес-целей, оценивает рыночную потребность, формирует предварительный бюджет, календарный план и примерный состав расширенной команды.
Уже здесь выявляются основные риски, ограничения по срокам, требованиям и технологиям. Отдельные пункты могут потребовать проведения исследований и технико-экономического обоснования - для понимания вопроса "Можно ли сделать продукт с заданными характеристиками и/или ценой?"
Ключевые документы этапа: устав проекта, дорожная карта (roadmap), примерная смета, список рисков и план управления ими.
На этом этапе решается судьба проекта: очень много стартапов закрывается именно здесь, потому что выявляется их нецелесообразность. Правильное планирование снижает риск системных ошибок, таких как превышение бюджета, недооценка сроков и т.п. Уже здесь можно определить подходящую модель разработки: каскадный Waterfall, гибкий подход Agile (итеративный подход) или гибрид. От методологии управления будут зависеть все последующие процессы.
Без четкого планирования дальнейшие этапы превращаются в хаос.
#2. Этап сбора и анализа требований (Requirements Gathering & Analysis)
Самый критичный этап: многие ошибки в проектах возникают именно из-за неправильно понятых стартовых требований.
Бизнес-аналитики, владелец продукта и стейкхолдеры проводят интервью, исследования, анкетирование пользователей, анализ конкурентов и существующих систем (продуктов конкурентов). Требования делятся на:
Все документируется в виде пользовательских историй (User Stories), кейсов использования (Use Cases), спецификаций (SRS, Software Requirements Specification), бэклога или документа бизнес-требований (BRD, Business Requirements Document).
Обязательно проводится приоритизация и валидация требований с заказчиком. Если элементов слишком много, то создается матрица прослеживаемости (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) - они выполняют несколько уровней тестирования:
Баг-трекинг ведется в специальных программах или в хранилищах кода.
Без качественного тестирования даже идеально написанный код может провалиться в продакшене. Этот этап часто занимает около трети времени всего проекта и позволяет обнаружить большинство дефектов и проблем до релиза.
#6. Развертывание / Внедрение (Deployment / Release)
После завершения тестирования продукт попадает к реальным пользователям. Именно здесь облачные сервисы разворачиваются в соответствующей инфраструктуре, а stand-alone продукты передаются заказчикам для проверки или публикуются в маркетплейсах.
На этом этапе тоже могут использоваться специфичные инструменты и подходы, например, сбор данных через системы аналитики, вывод ключевых данных о работе программы в дашборд и прочее.
В некоторых случаях в этап сдачи может входить обучение пользователей, помощь с миграцией данных, вывод из эксплуатации старой информационной системы, исправление багов и недочетов, которые выявил заказчик или реальные пользователи.
Ошибки на этом этапе самые заметные. Обычно они выражаются в "падении" сервиса под нагрузкой, в потере данных клиентов, а также в виде негативных отзывов и оценок на маркетплейсах.
#7. Эксплуатация и сопровождение (Maintenance & Support)
Эта стадия жизненного цикла SDLC в норме существенно дольше по времени, чем все остальные стадии разработки. В поддержку клиентов обычно включают следующие задачи:
Именно на этом этапе окупаются инвестиции в разработку приложения или сервиса. Но здесь же таится и большая часть расходов, связанных с сопровождением.
Проект обычно закрывается, если перестает приносить ценность конечным пользователям. Фаза закрытия тоже может иметь свои нюансы: нужно заранее оповестить клиентов, помочь им с миграцией и сохранением данных, закрыть все обязательства перед партнерами и поставщиками.
Какие существуют модели SDLC
# Waterfall (каскадная модель)
Классический SDLC цикл - линейная модель или каскад. Все этапы идут строго последовательно. Идеально подходит для проектов с жестко зафиксированными требованиями, где изменения минимальны: государственные системы, медицинское ПО, военные и банковские программные комплексы.
Преимущества: четкая структура, стабильная и хорошо детализированная документация, предсказуемые сроки и бюджет.
Недостатки: очень дорого и сложно вносить изменения после запуска процесса создания ПО, минимальная гибкость, позднее обнаружение проблем.
# V-Model (V-образная модель)
Расширение Waterfall с акцентом на тестирование. Каждый этап разработки имеет соответствующий уровень тестирования: unit-, интеграционное и т.д. Завершается все приемочным тестом. Применяется в проектах, где качество и стандартизация предельно критичны: медицина, автомобили, авиация, железнодорожные системы, оборонные системы.
Плюсы: встроенная проверка на каждом уровне, высокая надежность, гарантия полного соответствия исходным требованиям.
Минусы: все та же жесткость "водопада", максимальные сроки реализации.
# Гибкая разработка (Agile)
Итеративно-инкрементный подход, основанный на Манифесте Agile 2001 года. Разработка идет короткими циклами, например, спринтами по 1-4 недели, с постоянной обратной связью от заказчика, с приоритизацией бэклога и адаптацией к изменениям. Основные фреймворки: Scrum, Kanban, SAFe, LeSS.
Доминирует в продуктовых и IT-компаниях - в бизнес-сегменте. Идеален для стартапов, облачных сервисов, мобильных приложений с часто меняющимися требованиями.
Преимущества: быстрое создание ценности для конечных пользователей, высокая адаптивность, минимальный риск провала (так как проект пересматривается и адаптируется на каждой итерации).
Недостатки: требует зрелой команды, активного участия заказчика, может привести к "вечному улучшению" без четких целей.
# Spiral (Спиральная модель)
Вариант итеративной модели с сильным акцентом на управление рисками. Каждый виток спирали включает 4 фазы: планирование, анализ рисков, разработка прототипа, оценка. После очередного витка принимается решение - продолжать, менять или останавливать проект. Такой подход будет интересен для крупных и сложных проектов, например для enterprise-систем.
Плюсы: раннее выявление и минимизация рисков, возможность отказаться от заведомо провального направления, качественные прототипы для проверки гипотез (MVP-модель).
Минусы: дорого и долго, практически нереально спрогнозировать финальные сроки и бюджет, требует опытных риск-менеджеров.
# Incremental (Инкрементальная модель)
ПО разрабатывается и сдается частями - инкрементами. Каждый инкремент - это полноценная, работающая подсистема, добавляющая новую функциональность к предыдущим. Этапы внутри инкремента могут соответствовать разным подходам, в том числе и каскадному.
Преимущества: относительно быстрые запуск продукта, поэтапное финансирование и наращивание функционала, проще управлять рисками.
Недостатки: нужно правильно спроектировать архитектуру, чтобы инкременты стыковались без переделок.
# DevOps / Continuous Delivery / DevSecOps
Оригинальный подход к разработке, где различные модули реализуются как независимые системы и подсистемы, а связи настраиваются по API. В этом случае разработкой каждого блока может заниматься отдельная команда, а в своей работе она может использовать любую методологию управления, язык программирования и архитектурные решения. Тем не менее разработка, тестирование, обеспечение безопасности и операции легко объединяются в единый непрерывный процесс. Это современный стандарт де-факто для высоконагруженных SaaS-продуктов.
Преимущества: максимальная скорость доставки обновлений без остановки работы всей системы, высокая надежность, встроенная безопасность и мониторинг.
Минусы: требует серьезных инвестиций в разработку исходной архитектуры и согласование деталей взаимодействия подсистем - в разработку API.
Разные модели часто комбинируют между собой: Agile + DevOps, Waterfall с элементами итераций, спиральная модель внутри крупных Agile-проектов и т.д. Реальный выбор подхода зависит от размера проекта, уровня неопределенности, входящих требований и зрелости команды.
Source: Projecto