Разработка веб-сайта и комплекта технической документации: методологический подход и стандарты (ГОСТ, ISO/IEC)

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

Актуальность данной работы обусловлена необходимостью интеграции двух, казалось бы, противоположных концепций: гибкости современных методологий разработки (Agile/Scrum) и жестких требований к формализации документации, установленных национальными (ГОСТ 34-серии) и международными (ISO/IEC) стандартами. Для студентов технических специальностей, будущих системных аналитиков и инженеров-программистов, понимание этой синергии является ключом к успешной реализации сложных ИТ-проектов. Ведь без качественной, стандартизированной документации невозможно не только сдать проект государственному заказчику, но и обеспечить его долговременную поддержку и масштабирование.

Цель работы — разработка унифицированной методологии создания веб-сайта, включающей анализ наиболее актуальных моделей разработки, обзор нормативной базы (ГОСТ, ISO) для технического документирования и детализацию практических шагов по подготовке полного комплекта проектной и эксплуатационной документации.

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

Теоретические основы и современные методологии веб-разработки

Сравнительный анализ классических и гибких методологий

Процесс создания программного обеспечения, включая веб-сайты, исторически базировался на двух фундаментальных подходах: каскадном (Waterfall) и гибком (Agile). Выбор той или иной методологии критически влияет на структуру документации, последовательность этапов и возможности внесения изменений. Именно правильный выбор модели определяет первичный объем технического задания и уровень детализации требований.

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

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

• Scrum: Использует фиксированные по времени итерации (спринты), каждый из которых завершается выпуском готового, потенциально поставляемого инкремента продукта. Scrum требует постоянной коммуникации с заказчиком и оперативного обновления требований.
• Kanban: Фокусируется на визуализации рабочего процесса, ограничении незавершенной работы (WIP) и непрерывном потоке задач.
• Lean (Бережливая разработка): Основана на принципах устранения потерь и максимальной ценности для клиента.

Критерий сравнения	Waterfall (Каскадная)	Agile (Гибкая)
Требования	Фиксированы, должны быть полными на старте.	Динамичны, могут меняться в процессе.
Документация	Обширная, создается до разработки (Design Up Front).	Минимальная, создается по мере необходимости (Just In Time).
Риски	Высокий риск на поздних этапах при обнаружении ошибок.	Риски распределены, минимизируются в ходе итераций.
Применимость	Государственные проекты, проекты с жесткими регуляторными требованиями, где изменения дороги.	Коммерческие веб-сайты, стартапы, проекты с высокой неопределенностью.

Программная архитектура и метрики качества

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

Ключевым аспектом качества веб-сайта является Юзабилити (Usability) — способность продукта быть понятым, изучаемым, используемым и привлекательным для пользователя. Юзабилити является частью характеристики качества программного продукта согласно международному стандарту ISO/IEC 25010:2011 (Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models).

Оценка юзабилити, в соответствии со стандартом ISO 9241-11 (Руководство по юзабилити), базируется на трех ключевых метриках:

1. Результативность (Effectiveness): Точность и полнота, с которой пользователи достигают поставленных целей (например, процент успешно завершенных покупок).
2. Эффективность (Efficiency): Затраты ресурсов (время, усилия) при достижении целей (например, время, затраченное на заполнение формы).
3. Удовлетворенность (Satisfaction): Субъективное восприятие пользователем степени комфорта и приемлемости использования системы.

Эти метрики закладываются в техническое задание и программу и методику испытаний (ПМИ), что делает юзабилити измеримым показателем качества. Особое внимание уделяется эффективности, поскольку именно она напрямую влияет на конверсию и лояльность пользователей.

Нормативно-методическое обеспечение и Техническое Задание (ТЗ)

Для обеспечения стандартизации, единообразия и юридической силы документации в РФ используется комплекс стандартов, регламентирующих разработку автоматизированных систем (АС), к которым относится и веб-сайт. Этот блок является обязательным для всех проектов, где требуется высокая степень формализации.

Разработка ТЗ на создание автоматизированной системы по ГОСТ

Техническое Задание (ТЗ) — это основополагающий документ, определяющий назначение, цели, требования к системе, а также порядок ее создания и приемки.

Для разработки ТЗ на веб-сайт (как АС) необходимо руководствоваться национальным стандартом ГОСТ 34.602-89 («Техническое задание на создание автоматизированной системы»).

Структура ТЗ по ГОСТ 34.602-89 включает следующие обязательные разделы:

1. Общие положения: Наименование системы, заказчик, разработчик, основание для разработки.
2. Назначение и цели создания (развития) системы: Описание решаемых задач и достигаемых эффектов (экономических, социальных).
3. Характеристики объекта автоматизации: Описание бизнес-процессов, которые будут автоматизированы.
4. Требования к системе: Центральный раздел, включающий:
   • Требования к функциям (функциональные).
   • Требования к видам обеспечения: техническое, программное, информационное, лингвистическое, организационное, методическое.
   • Требования к надежности, безопасности, эргономике (юзабилити).
5. Состав и содержание работ по созданию системы: Перечень этапов и стадий (например, эскизный проект, технический проект, рабочая документация).
6. Порядок контроля и приемки системы.
7. Требования к документированию.
8. Источники разработки.

Применение ГОСТ 34.602-89 неразрывно связано с комплексом стандартов:

• ГОСТ 34.201-89 («Виды, комплектность и обозначения документов») определяет, какие виды документов должны быть разработаны на каждой стадии проекта.
• РД 50-34.698-90 («Требования к содержанию документов») детализирует требования к наполнению каждого документа (например, Технического проекта или Рабочей документации), включая описание общих системных, организационных и программных решений.

Этап разработки Рабочей документации (РД), следующий за Техническим проектом (ТП), детализирует архитектуру и логику до уровня, необходимого для непосредственной реализации. В этом контексте применяются стандарты, такие как ГОСТ 19.402–78 («Описание программы»), который устанавливает требования к содержанию программного документа.

Применение международных стандартов в документировании

Наряду с национальными стандартами, в международной практике ИТ-инженерии активно используются стандарты ISO/IEC/IEEE, которые обеспечивают глобальную унификацию терминологии и подходов. Для чего ограничивать себя только национальными рамками, если лучшие мировые практики уже предлагают готовые решения для структурирования сложных систем?

Для описания требований и архитектуры веб-сайта могут применяться:

1. ISO/IEC/IEEE 42010 («Systems and software engineering — Architecture description»): Этот стандарт устанавливает требования к описанию архитектуры системы. Он помогает систематизировать представление о структуре, компонентах и их взаимодействии, обеспечивая ясность и проверяемость архитектурных решений, заложенных в Технический проект (ТП) и Рабочую документацию (РД).
2. IEEE 830 («Specification for Software Requirements»): Руководство по созданию спецификации требований к программному обеспечению (SRS). Этот стандарт предоставляет структуру и рекомендации для составления исчерпывающего, непротиворечивого и проверяемого документа требований, который может служить детальным дополнением к функциональным требованиям в ТЗ по ГОСТ.
3. ISO/IEC/IEEE 24765 («Systems and software engineering — Vocabulary»): Обеспечивает единый словарь терминов в области системной и программной инженерии, что критически важно для устранения двусмысленности в технической документации.

Интеграция требований ГОСТ с лучшими мировыми практиками (ISO/IEC/IEEE) позволяет создать документацию, которая одновременно соответствует нормативным требованиям РФ и обеспечивает высокий уровень качества, понятный международному ИТ-сообществу.

Роль системного аналитика в процессе документирования

В современном процессе разработки программного обеспечения системный аналитик (СА) занимает центральное место, выступая «переводчиком» между потребностями бизнеса и технической реализацией.

Функции аналитика и отличия от технического писателя

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

• Функциональные спецификации (FSD).
• Пользовательские истории (User Stories) или сценарии использования (Use Cases).
• Спецификации нефункциональных требований (безопасность, производительность, надежность).
• Проектные документы, такие как ТЗ (по ГОСТ 34.602-89) и Технический проект (ТП).

Системный аналитик отвечает за содержание и корректность заложенной логики.

Технический писатель-аналитик же фокусируется на документации как на самостоятельном продукте, обеспечивая ее структуру, доступность и актуальность. Технический писатель:

• Организует информацию, предоставленную СА и разработчиками, в удобные для чтения форматы (Руководство пользователя, Руководство администратора, API-документация).
• Поддерживает согласованность документации с фактическим состоянием продукта, особенно при внесении изменений в требования (change requests).
• Работает над внешней документацией, ориентированной на конечных пользователей или разработчиков (API).

Таким образом, если СА создает базу знаний о системе, то технический писатель создает интерфейс к этой базе, делая ее понятной целевой аудитории. Это разделение труда позволяет гарантировать как методологическую чистоту требований, так и их пользовательскую доступность.

Инструментарий для системного моделирования

Для наглядного и однозначного представления структуры и логики системы системный аналитик активно использует графические модели. Эти диаграммы являются неотъемлемой частью рабочей документации и Технического проекта.

Для создания таких моделей часто используются инструменты, поддерживающие подход «Документация как код» (например, PlantUML), который позволяет описывать диаграммы с помощью простого текстового синтаксиса, а не графических редакторов.

Ключевые диаграммы, используемые СА:

Тип диаграммы	Назначение	Применение в веб-проекте
Диаграмма последовательности (Sequence Diagram, UML)	Описывает временную последовательность взаимодействия объектов или компонентов для выполнения конкретного сценария.	Моделирование процесса регистрации пользователя, оформления заказа, взаимодействия Frontend и Backend.
ER-диаграмма (Entity-Relationship)	Графическое представление структуры данных (сущности, их атрибуты и связи).	Проектирование схемы базы данных веб-сайта (пользователи, товары, заказы).
BPMN-диаграмма (Business Process Model and Notation)	Моделирование бизнес-процессов, которые автоматизирует веб-сайт.	Описание логики обработки платежей, модерации контента или работы с поставщиками.
Диаграмма состояний (State Diagram, UML)	Описание жизненного цикла сущности и ее переходов между состояниями.	Моделирование статусов заказа (создан, оплачен, отгружен, завершен).

Эти модели, будучи включенными в Рабочую документацию, значительно повышают уровень детализации, требуемый, например, в разделе «Программное обеспечение» РД 50-34.698-90.

Специфика документирования Frontend- и Backend-компонентов

Веб-сайт представляет собой двухуровневую архитектуру: клиентскую часть (Frontend) и серверную часть (Backend). Документирование каждой из них требует уникального набора документов и специфического фокуса.

Документация для Frontend (UI/UX)

Frontend — это клиентская часть, которая отвечает за пользовательский интерфейс (UI) и пользовательский опыт (UX). Эта часть документации наиболее тесно связана с требованиями юзабилити (ISO 9241-11).

Документирование Frontend-части включает:

1. User Interface Specification (Спецификация пользовательского интерфейса): Детальное описание всех экранов, их элементов, правил поведения при различных состояниях (например, ошибки валидации, загрузка данных).
2. UI/UX Логика: Описание, как пользователь взаимодействует с элементами, включая навигацию, анимацию и отклики системы. Этот раздел часто включает Wireframes (каркасы) и Mockups (макеты), которые, хотя и не являются строго технической документацией по ГОСТ, необходимы для визуализации требований.
3. Требования к кроссбраузерности и адаптивности: Фиксация целевых браузеров, операционных систем и разрешений экрана, на которых сайт должен корректно работать.

Документация для Backend (API и Архитектура)

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

Ключевые документы для Backend:

1. API-спецификации: Описание протокола взаимодействия программ и модулей. Если сайт использует RESTful API, то спецификация оформляется с использованием стандартов, таких как OpenAPI (ранее Swagger). Если используются другие технологии (например, gRPC), применяется соответствующий язык описания интерфейса (gRPC IDL). Описание интерфейсов взаимодействия, согласно ГОСТ 19.502, является отдельным, обязательным программным документом.
2. Схемы баз данных (DB Schema): Детальное описание таблиц, полей, типов данных, первичных и внешних ключей, а также хранимых процедур и триггеров. Основываются на ER-диаграммах, разработанных системным аналитиком.
3. Описание бизнес-логики: Детализация алгоритмов, по которым обрабатываются данные и выполняются ключевые операции (например, расчет стоимости, аутентификация). Этот раздел напрямую связан с функциональными требованиями из ТЗ и должен быть исчерпывающим.
4. Описание программной архитектуры (HLD): В соответствии с ISO/IEC/IEEE 42010, этот документ описывает высокоуровневую структуру системы (например, монолит, микросервисы), используемые технологии и принципы взаимодействия между ними.

Инструменты и методики ведения технической документации

Поддержание документации в актуальном и легкодоступном состоянии — одна из самых сложных задач в Agile-проектах. Для ее решения используются современные подходы и специализированные платформы.

Принцип «Документация как код» (Docs as Code)

Подход Docs as Code (Документация как код) рассматривает документацию как равноправный с программным кодом актив. Это означает применение к документации стандартных инженерных практик:

• Хранение в репозитории: Документы (написанные в легковесных форматах Markdown или reStructuredText (*.rst)) хранятся в системе контроля версий (Git), рядом с кодом.
• Версионирование: Каждое изменение в документации или в коде отражается в новой версии, что обеспечивает отслеживаемость и актуальность.
• Автоматизированная сборка (CI/CD): Документация собирается из исходных файлов в готовый формат (HTML, PDF) с помощью специальных генераторов.

Наиболее популярный генератор документации в этом подходе — Sphinx, написанный на Python. Он позволяет использовать разметку reStructuredText или Markdown для написания текста и автоматически генерировать структурированные и кросс-ссылочные документы, которые затем могут быть опубликованы.

Централизованные платформы

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

Confluence является де-факто стандартом для создания корпоративных вики-систем и централизованных хранилищ знаний. Его преимущества:

• Удобный редактор и шаблоны: Позволяет нетехническим пользователям (менеджерам, заказчикам) легко создавать и редактировать страницы.
• Интеграция с Jira: Позволяет связывать документацию с задачами разработки, улучшая отслеживаемость.
• История версий: Поддерживает отслеживание изменений на уровне страницы.

Для обеспечения актуальности данных и объединения преимуществ обоих подходов используется интеграция: документация хранится как код в репозитории, обрабатывается Sphinx, а затем публикуется в Confluence с помощью специализированных плагинов, например, Confluence Builder. Это позволяет сохранить строгое версионирование и контроль качества Docs as Code, одновременно обеспечивая удобство доступа, предоставляемое вики-системой. Разве не это идеальный баланс между инженерной строгостью и простотой использования?

Юридические и нормативные требования к веб-сайту в РФ

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

Обеспечение защиты персональных данных (ФЗ-152)

Любой владелец веб-сайта, который собирает ПД (имена, email, телефоны, IP-адреса) через формы обратной связи, регистрации или подписки, становится оператором персональных данных и обязан соблюдать требования Федерального закона №152-ФЗ «О персональных данных».

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

1. Политика обработки персональных данных: Обязательный публичный документ, описывающий цели, способы, сроки и объем обработки ПД. Должна быть размещена на сайте.
2. Согласие на обработку ПД: Должно быть получено от пользователя в явной форме (например, проставление галочки перед отправкой формы).

В соответствии с Постановлением Правительства РФ №1119 от 01.11.2012, оператор обязан определить уровень защищенности персональных данных (УЗ), обрабатываемых в информационной системе (ИСПДн). Существует четыре уровня защищенности (УЗ1, УЗ2, УЗ3, УЗ4), выбор которых зависит от категории обрабатываемых данных (специальные, биометрические, общедоступные) и количества субъектов ПДн.

Уровень защищенности определяет состав и содержание организационных и технических мер, которые должны быть реализованы в системе. Эти меры детально описаны в Приказе ФСТЭК России № 21 от 18.02.2013 («Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»). Технические требования из этого Приказа должны быть заложены в соответствующий раздел ТЗ и Технического проекта, касающийся безопасности. Если эти требования не будут зафиксированы на этапе проектирования, последующая доработка системы может потребовать значительных финансовых и временных затрат.

Состав обязательной внутренней документации по ПД

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

Основные внутренние документы:

• Положение об обработке персональных данных: Внутренний регламент, определяющий порядок работы с ПД.
• Приказ о назначении ответственных лиц: Фиксация сотрудников, ответственных за организацию обработки и обеспечение безопасности ПД.
• Регламент определения уровня защищенности: Документ, обосновывающий выбор УЗ1, УЗ2, УЗ3 или УЗ4.
• Технический паспорт информационных систем персональных данных (ИСПДн): Ключевой документ, описывающий архитектуру системы, технические средства защиты и места хранения ПД.
• Модель угроз безопасности ПД: Документ, содержащий анализ потенциальных угроз и методов их нейтрализации, разработанный в соответствии с методическими документами ФСТЭК и ФСБ России.

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

Заключение

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

Основные результаты и выводы:

1. Методологическая основа: Определен критерий выбора модели разработки (Waterfall для фиксированных требований, Agile/Scrum для динамичных), с акцентом на то, что даже при использовании Agile, финальная техническая документация должна соответствовать требованиям стандартизации.
2. Нормативное ядро: Подтверждена критическая роль ГОСТ 34.602-89 как основы для ТЗ на создание веб-сайта (как АС), а также роль РД 50-34.698-90 и международных стандартов ISO/IEC/IEEE 42010 и IEEE 830 для обеспечения глубины и качества проектной документации.
3. Роль специалиста: Выявлено ключевое различие между функциями Системного аналитика (создание логического содержания, моделирование через UML/BPMN) и Технического писателя (структурирование, оформление и публикация).
4. Специфика документирования: Разработана структура документирования, учитывающая особенности Frontend (UI/UX, кроссбраузерность) и Backend (API-спецификации по OpenAPI, архитектура, схемы БД).
5. Автоматизация: Обосновано применение подхода «Docs as Code» с использованием Sphinx и централизованных платформ (Confluence) для обеспечения актуальности, версионирования и доступности документации.
6. Юридическая чистота: Проанализированы обязательные требования ФЗ-152, включая необходимость определения 4 уровней защищенности ПДн согласно Постановлению №1119 и реализации технических мер по Приказу ФСТЭК № 21, что требует включения в ТЗ и Технический паспорт ИСПДн.

Разработанная методика имеет высокую практическую значимость, позволяя ИТ-специалистам не только создавать функциональные веб-ресурсы, но и обеспечивать их соответствие высоким стандартам качества (юзабилити по ISO 9241-11) и требованиям законодательства РФ, что является необходимым условием для успешной профессиональной деятельности в сфере программной инженерии.

Список использованной литературы

1. Agile или Waterfall? Сравнение методологий веб-разработки // VC.RU. URL: https://vc.ru/u/102927-soft-team/38075-agile-ili-waterfall-sravnenie-metodologiy-veb-razrabotki (дата обращения: 23.10.2025).
2. Владельцам сайтов: изменения в законе о персональных данных // Tilda Education. URL: https://tilda.education/articles-site-personal-data-law-changes/ (дата обращения: 23.10.2025).
3. Выбор архитектуры для мобильных приложений : Текст научной статьи // КиберЛенинка. URL: https://cyberleninka.ru/article/n/vybor-arhitektury-dlya-mobilnyh-prilozheniy (дата обращения: 23.10.2025).
4. ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы // Веб-студия ONVOLGA. URL: https://onvolga.ru/document/gost-34-602-89 (дата обращения: 23.10.2025).
5. Документирование по ГОСТ 34* — это просто // Habr. URL: https://habr.com/ru/articles/122046/ (дата обращения: 23.10.2025).
6. Документация на программное обеспечение — структура, ГОСТы, ISO и IEEE // etence. URL: https://etence.me/dokumentaciya-na-programnoe-obespechenie-struktura-gosty-iso-i-ieee/ (дата обращения: 23.10.2025).
7. Документы по персональным данным в 2025 году // Legal Box. URL: https://legal-box.ru/blog/dokumenty-po-personalnym-dannym-neobhodimye-v-2023-godu/ (дата обращения: 23.10.2025).
8. Docs as code против или вместе с Confluence? Обзор нескольких способов публикации из репозитория в Confluence // Habr. URL: https://habr.com/ru/articles/484346/ (дата обращения: 23.10.2025).
9. Ещё раз про семь основных методологий разработки // Habr. URL: https://habr.com/ru/articles/271295/ (дата обращения: 23.10.2025).
10. Инструменты для создания документации // Skypro. URL: https://sky.pro/media/instrumenty-dlya-sozdaniya-dokumentacii/ (дата обращения: 23.10.2025).
11. Как составить ТЗ на разработку сайта – пошаговая инструкция с примерами // Craftum. URL: https://craftum.com/blog/kak-sostavit-tz-na-razrabotku-sajta-poshagovaya-instrukciya-s-primerami (дата обращения: 23.10.2025).
12. Закон о персональных данных: приводим сайт в порядок // Мойбизнес.рф. URL: https://xn--90aifddrld7a.xn--p1ai/docs/zakon_o_personalnykh_dannykh_privodim_sayt_v_poryadok/ (дата обращения: 23.10.2025).
13. МОНИТОРИНГ ЮЗАБИЛИТИ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА : Текст научной статьи // КиберЛенинка. URL: https://cyberleninka.ru/article/n/monitoring-yuzabiliti-polzovatelskogo-interfeysa (дата обращения: 23.10.2025).
14. Нормативные документы по защите персональных данных — полный пакет по 152-ФЗ. URL: https://b-152.ru/normativnye-dokumenty-po-zashchite-personalnykh-dannykh/ (дата обращения: 23.10.2025).
15. Push sphinx docs to confluence using sphinxcontrib-confluencebuilder // Atlassian. URL: https://community.atlassian.com/t5/Confluence-questions/Push-sphinx-docs-to-confluence-using-sphinxcontrib-confluencebuilder/qaq-p/2607153 (дата обращения: 23.10.2025).
16. Раздел I. Роль системного аналитика в разработке информационных систем для бизнеса. URL: https://systems.education/rol-sistemnogo-analitika-v-razrabotke/ (дата обращения: 23.10.2025).
17. Системный аналитик — кто это и его роль в разработке продукта // terabit.ai. URL: https://terabit.ai/blog/sistemnyy-analitik (дата обращения: 23.10.2025).
18. Сравнение методологий веб-разработки Agile и Waterfall // IT Only. URL: https://it-only.online/blog/sravnenie-metodologij-veb-razrabotki-agile-i-waterfall/ (дата обращения: 23.10.2025).
19. Техническая документация в Confluence // Atlassian. URL: https://www.atlassian.com/ru/software/confluence/guides/technical-documentation (дата обращения: 23.10.2025).
20. Техническое задание на сайт разработка и создание по ГОСТ // Технический писатель-аналитик. URL: https://techwrconsult.com/tehnicheskoe-zadanie-na-sajt-razrabotka-i-sozdanie-po-gost/ (дата обращения: 23.10.2025).
21. Технический писатель-аналитик. Кто он такой и чем занимается в команде разработки // Flow 2022. URL: https://flowconf.ru/2022/techwriter-analyst (дата обращения: 23.10.2025).
22. Требования к защите персональных данных при их обработке в информационных системах персональных данных // КонсультантПлюс. Документ КОНСУЛЬТАНТПЛЮС № 169974. URL: https://www.consultant.ru/document/cons_doc_LAW_169974/ (дата обращения: 23.10.2025).