Что такое SDLC? Практическое руководство по жизненному циклу разработки программного обеспечения в 2026 году

Жизненный цикл разработки программного обеспечения является основой того, как современные команды создают, выпускают и поддерживают ПО. Независимо от того, запускаете ли вы MVP стартапа или масштабируете корпоративную платформу, понимание SDLC предоставляет вам повторяемую структуру для превращения идей в надежные продукты. В этом руководстве подробно описана каждая фаза, сравниваются наиболее распространенные модели SDLC и показано, как инструменты оркестрации, такие как BridgeApp, поддерживают все взаимосвязи.

Под капотом

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

Большинство SDLC имеют семь ключевых фаз — планирование, требования, проектирование, разработка, тестирование, развертывание и сопровождение — независимо от того, использует ли команда каскадную модель, гибкую модель, итеративную модель или модель «большого взрыва». Фазы остаются неизменными; модель определяет, как вы по ним продвигаетесь.

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

Что такое SDLC?

SDLC означает Жизненный Цикл Разработки Программного Обеспечения. Это сквозной процесс разработки, который ведет команду разработчиков через планирование, проектирование, создание, тестирование, развертывание и сопровождение программных систем. Представьте его как карту всего процесса разработки ПО — от первого обсуждения того, что нужно создать, до постоянного обслуживания через годы после запуска.

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

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

Почему SDLC важен для современных команд разработчиков ПО

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

Рассмотрим цифры: согласно отчету CHAOS Report 2025 от Standish Group, примерно 71% программных проектов по-прежнему «проблемны» (превышают бюджет, сроки или объем) или полностью терпят неудачу. Только около 29% выполняются полностью по плану. Четкий SDLC снижает эти показатели неудач, согласовывая бизнес-цели, пользовательские требования и технические ограничения с первого дня, а не реагируя поздно на этапе развертывания.

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

Большинство организаций следуют 6-7-этапному SDLC: планирование, требования, проектирование, разработка, тестирование, развертывание и сопровождение. В реальных командах разработчиков программного обеспечения эти фазы часто пересекаются — особенно в Agile или DevOps — но каждая фаза имеет свои distinct цели, артефакты и владельцев.

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

Планирование и анализ осуществимости

Фаза планирования — это место, где менеджеры по продукту, архитекторы и технические руководители анализируют бизнес-цели, высокоуровневый объем, бюджет и сроки, чтобы решить, является ли проект реалистичным. Ключевые мероприятия включают интервью с заинтересованными сторонами, исследование конкурентов, высокоуровневый анализ рисков и первоначальную оценку рентабельности инвестиций.

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

Определение требований

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

Бизнес-аналитики, владельцы продуктов, сотрудники службы безопасности и команда разработчиков постоянно сотрудничают для проверки предположений и уточнения спецификаций программного обеспечения. Трассируемость критически важна: каждое требование должно соответствовать тестам на более поздних этапах SDLC. Это намного проще, когда требования хранятся в централизованном инструменте, таком как задачи и базы данных BridgeApp. Четкие требования сокращают объем переделок и помогают тестировщикам и разработчикам программного обеспечения согласовать, что на самом деле означает «готово».

Проектирование системы и программного обеспечения

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

Команды должны учитывать масштабируемость, отказоустойчивость, наблюдаемость и безопасность — шифрование, контроль доступа, моделирование угроз — на этом этапе, а не после развертывания. Прототипирование критически важных программных компонентов или потоков пользовательского интерфейса на этом этапе помогает выявить проблемы на ранней стадии. Согласно контрольным показателям Cleverix за 2026 год, ошибка, исправление которой на этапе кодирования стоит около 25 долларов, может стоить более 10 000 долларов, если она достигнет производственной среды. Проектные решения сильно влияют на скорость разработки, качество кода и будущие затраты на обслуживание.

Разработка (Реализация)

На этом этапе разработчики программного обеспечения начинают писать код. Инженеры реализуют проект, используя согласованные стандарты кодирования, стратегии ветвления (GitFlow или разработка на основе магистрали) и ревью кода. Работа разбивается на задачи или пользовательские истории, которые проходят через доски — Kanban, Scrum-спринты — с использованием инструментов управления проектами, таких как BridgeApp, для отслеживания прогресса и ответственности.

Современные практики включают непрерывную интеграцию, автоматические сборки, статический анализ и шлюзы качества кода для предотвращения регрессий. Агенты ИИ для кодирования, такие как Magic Coder от BridgeApp, могут ускорить реализацию, сохраняя при этом изменения проверяемыми и контролируемыми. Модульное тестирование, интеграционное тестирование и переключатели функций должны быть реализованы вместе с новым кодом с использованием систем контроля версий, а не прикреплены задним числом.

Тестирование и обеспечение качества

Фаза тестирования использует многоуровневую стратегию: модульное тестирование, интеграционное тестирование, системное тестирование, регрессионное, производительности, безопасности и приемочное тестирование пользователем (UAT). Команды QA и разработчики сотрудничают для создания планов тестирования, тестовых случаев и автоматизированных наборов тестов, интегрированных в CI-конвейеры.

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

Развертывание и управление выпусками

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

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

Сопровождение, поддержка и развитие

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

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

Общие модели SDLC (каскадная, гибкая, итеративная и другие)

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

Каскадная модель

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

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

Итеративная модель

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

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

Гибкая модель (Agile)

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

Общие фреймворки — Scrum, Kanban, Scrumban, SAFe — по-прежнему соблюдают те же фазы SDLC, просто повторяют их часто. Около 97% организаций сейчас в той или иной степени используют Agile, при этом проекты Agile показывают примерно 75% успешности против 56% для традиционных подходов. Платформы, такие как BridgeApp, поддерживают Agile, объединяя дорожные карты, доски спринтов, обсуждения и документы в едином слое оркестровки, что позволяет командам отслеживать прогресс разработки без переключения контекста.

Спиральная модель

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

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

V-модель (модель верификации и валидации)

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

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

Модель «Большого взрыва»

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

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

Основные преимущества хорошо реализованного SDLC

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

Основные преимущества включают:

• Снижение затрат: Выявление дефектов на ранних стадиях значительно экономит средства. Ошибка на этапе кодирования стоит примерно $25; в производстве эта цифра может превысить $10,000 за дефект. Стоимость низкого качества программного обеспечения только в США достигает, по оценкам, $2.41 триллиона ежегодно.
• Предсказуемость: Четкие фазы, артефакты и контрольные точки качества делают сроки и бюджеты более надежными.
• Улучшенная коммуникация: Команды разработчиков, менеджеры проектов и заинтересованные стороны используют общий язык и рабочий процесс.
• Поддержка соответствия: Документация и прослеживаемость удовлетворяют аудиторов и регулирующие органы.
• Удобство поддержки: Структурированный дизайн и тестирование создают программные приложения, которые легче развивать в течение многих лет.

Эти преимущества усиливаются, когда SDLC сочетается с автоматизацией, наблюдаемостью и слоем оркестровки, таким как BridgeApp, который поддерживает согласованность всех участников. Отсутствие дисциплинированного SDLC почти всегда проявляется в виде пропущенных сроков, расползания объёма работ и устранения неполадок после выпуска.

Как BridgeApp организует весь жизненный цикл разработки

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

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

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

Лучшие практики современного SDLC в 2026 году

SDLC — это не фиксированный контрольный список. Он развивается с такими практиками, как DevOps, DevSecOps и разработка с помощью ИИ. Лучшие команды по разработке программного обеспечения в 2026 году рассматривают свой SDLC как живую систему, которую они постоянно совершенствуют.

• Внедряйте непрерывную интеграцию, автоматизированное тестирование и частые развертывания для сокращения циклов обратной связи.
• Поддерживайте легкую, но всеобъемлющую документацию (SRS, примечания к дизайну, руководства по эксплуатации) в едином источнике истины, таком как BridgeApp — избегайте разрозненных вики и электронных писем.
• Определите четкие «Определение готовности» и «Определение завершения» для всех команд, чтобы предотвратить попадание незавершенной работы на более поздние этапы.
• Проводите регулярные ретроспективы на уровне проектов и релизов, чтобы устранить трения в процессе разработки.

Интеграция непрерывной интеграции и DevOps в SDLC

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

Общие инструменты разработки, такие как Jenkins, GitLab CI и GitHub Actions, формируют цепочку сборки-тестирования-развертывания. BridgeApp может размещать руководства по развертыванию, каналы инцидентов и уведомления о конвейере, обеспечивая согласованность всех заинтересованных сторон по статусу выпуска. Интеграция CI/CD и DevOps в SDLC улучшает пропускную способность, сокращает время выполнения и стабилизирует выпуски в производственной среде.

Балансирование между соответствием, безопасностью и скоростью

Многие команды должны внедрять проверки безопасности и соответствия на нескольких этапах SDLC: требования (политики), проектирование (моделирование угроз), кодирование (стандарты безопасного кодирования) и тестирование (сканирование безопасности). Подход DevSecOps автоматизирует эти проверки непрерывно, вместо того чтобы выполнять их только при финальном обзоре.

Фиксация утверждений, оценок рисков и решений, имеющих отношение к аудиту, в BridgeApp обеспечивает прослеживаемость для сложных проектов в финансовой, медицинской и государственной сферах. Ранняя работа по обеспечению безопасности и соответствия снижает затраты на переделки и ущерб репутации от утечек или неудачных аудитов. ИИ следует использовать разумно — человеческий обзор остается essentiel для критических путей кода, архитектуры и политик, позволяя командам уверенно развертывать программное обеспечение.

Как выбрать правильную модель SDLC для вашей команды

Не существует единственной универсально лучшей модели SDLC. Правильный выбор зависит от типа вашего проекта, регуляторных требований и частоты изменения требований.

Ключевые факторы принятия решений:

• Стабильность требований: Четко определенный объем работ благоприятствует Waterfall или V-модели. Меняющиеся требования благоприятствуют Agile или итеративной разработке.
• Риски предметной области и соответствие: Финансы и здравоохранение требуют прослеживаемости и формальной верификации; приложение для потребителей на ранней стадии — нет.
• Зрелость команды: Опытные команды могут справляться со сложным Agile в масштабе; новые команды могут получить выгоду от большей структуры.
• Частота выпусков: Еженедельные развертывания указывают на Agile/DevOps; ежегодные выпуски допускают Waterfall.
• Доступность заинтересованных сторон: Активное участие заинтересованных сторон поддерживает Agile; ограниченный доступ подходит для моделей, требующих больше документации.

Гибридные модели хорошо работают для многих команд — например, Waterfall для ранней регуляторной документации в сочетании с Agile-спринтами для реализации и тестирования. BridgeApp поддерживает переходы между моделями, сохраняя все артефакты проекта и обсуждения в одном месте, даже по мере развития процессов. Цель всегда состоит в том, чтобы создавать программное обеспечение, которое соответствует ожиданиям клиентов, оставаясь при этом удобным в поддержке и безопасным.

Часто задаваемые вопросы

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

Является ли SDLC тем же, что и Agile?

Нет. SDLC — это общая концепция, описывающая фазы разработки — планирование, проектирование, разработка, тестирование, развертывание, поддержка. Agile — это семейство моделей и практик того, как итеративно проходить эти фазы. Гибкая методология — это один из способов структурирования жизненного цикла разработки программного обеспечения, наряду с такими альтернативами, как Waterfall, Итеративная и Спиральная. Команды часто сочетают Agile с DevOps и CI/CD, но основные фазы SDLC остаются узнаваемыми.

Сколько времени обычно занимает один цикл SDLC?

Продолжительность сильно варьируется. Небольшая функция в Agile-команде может завершить полный мини-цикл за 1–3 недели, в то время как крупная регулируемая система может занимать 12–24 месяца. Современные команды предпочитают более короткие циклы с непрерывными выпусками, что снижает риски и позволяет быстрее получать обратную связь от пользователей. Отслеживание времени выполнения и длительности цикла в таких инструментах, как BridgeApp, помогает понять и улучшить скорость SDLC в вашей организации.

Какая модель SDLC лучше всего подходит для стартапов?

Стартапы на ранней стадии обычно получают наибольшую выгоду от Agile или итеративной модели, которая позволяет частые изменения на основе обратной связи с клиентами. Тяжеловесный, ориентированный на документы Waterfall обычно избыточен, если только это не требуется регулированием или корпоративными клиентами. Стартапы могут использовать BridgeApp для хранения заметок по продуктовому поиску, дорожных карт и работы по спринтам вместе, что делает быструю итерацию менее хаотичной.

Какова роль документации в SDLC, если мы используем Agile?

Agile не устраняет документацию — он предпочитает «достаточную» документацию, которая остается точной и полезной. Основные документы включают пользовательские истории, критерии приемки, обзоры архитектуры, контракты API и постмортемы инцидентов. Хранение актуальной документации в централизованных инструментах, таких как документы BridgeApp, поддерживает ее в актуальном состоянии, позволяет совместно редактировать и напрямую связывать с задачами и выпусками.

Как инструменты ИИ, такие как Magic Coder от BridgeApp, могут вписаться в SDLC?

ИИ-агенты для кодирования могут помогать на нескольких этапах: генерировать шаблонный код во время разработки, предлагать рефакторинг, писать тестовые случаи или суммировать проектную документацию. Вывод ИИ всегда должен проверяться инженерами-программистами, особенно для критически важного с точки зрения безопасности кода, архитектуры и чувствительных к производительности программных компонентов. Использование Magic Coder в общем рабочем пространстве BridgeApp обеспечивает соответствие изменений, управляемых ИИ, командным стандартам, рекомендациям по кодированию и контексту проекта, определенным в других частях SDLC.