Введение

Результаты исследования, проведенного в рамках научно‑исследовательского гранта РФФИ № 16–36-00031 «мол_а» в 495 ИТ‑субъектах Томской области (ОКВЭД класс 62), позволили установить, что создание ИТ‑продуктов в ходе выполнения ИТ‑проектов сопровождается разработкой как проектной, так и юридической документации. Согласно ГОСТ 21.101 [1] и ст. 48 ГрК РФ [2], проектной документацией принято называть совокупность материалов в текстовой форме и (или) в виде схем, формализующих архитектурные, функционально‑технологические, конструктивные и инженерно‑технические решения, которые направлены на создание запланированного объекта [Болтанова и др., 2022].

Стоит отметить, что законодатель предъявляет определенные требования к комплектности, к содержанию и оформлению проектной документации. Например, если создается объект капитального строительства, то согласно Постановлению № 87 [3] проектная документация должна включать схему планировочной организации земельного участка, перечень инженерно‑технических мероприятий, технологические решения, проект организации строительства и др.

В области информационных технологий (далее — ИТ) комплектность, содержание и оформление, состав, виды, наименования и обозначения проектной документации регулируются требованиями национальных стандартов по созданию автоматизированных систем [Миронов, 2022; Filippov et al., 2023]. В частности, документы национальной системы стандартизации в области ИТ описывают этапы разработки проектной документации, вводят глоссарий, закрепляют требования к оформлению и наличию обязательных разделов. Например, требования к последовательности работ по созданию ИТ‑продуктов закреплены в ГОСТ Р 59 793 [4], требования к составу, видам, наименованию, комплектности и обозначению проектной документации — в ГОСТ 34.201 [5], требования к содержанию проектной документации — в ГОСТ Р 59 795 [6], требования к оформлению проектной документации — в стандартах единой системы программной документации (далее — ЕСПД) серии ГОСТ 19 [7][8][9][10][11][12][13][14], требования к последовательности приемки созданного ИТ‑продукта — в ГОСТ Р 59 792 [15].

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

Для достижения поставленной цели были решены следующие задачи:

  1. анализ национальных стандартов, закрепляющих требования к последовательности работ по созданию ИТ-продуктов (ГОСТ Р 59793), к составу, видам, наименованию, комплектности и обозначению проектной документации (ГОСТ 34.201), к содержанию проектной документации (ГОСТ Р 59795), к оформлению проектной документации (серия ГОСТ 19) и к последовательности приемки созданного ИТ-продукта (ГОСТ Р 59792);

  2. усовершенствование структуры документального сопровождения создания ИТ-продуктов в рамках выполнения ИТ-проектов.

Анализ национальных стандартов, закрепляющих требования к документальному сопровождению создания ИТ-продуктов

Рассматривая характер требований национальных стандартов, декларирующих документальное сопровождение создания ИТ‑продуктов в рамках выполнения ИТ‑проектов, нельзя не упомянуть принцип добровольности применения документов по стандартизации (ст. 4 Закона 162-ФЗ) [16]. Диспозитивность требований национальных стандартов означает, что ИТ‑субъект может самостоятельно определять содержание проектных документов в зависимости от требований заинтересованных сторон, используемых стилей управления, а также наличия ресурсов.

Согласно требованиям ГОСТ Р 59 853 [17], проектная документация включает проектно‑сметную, рабочую, приемочную и эксплуатационную документацию (рис. 1).

Рис. 1. Структура проектной документации согласно ГОСТ Р 59853
Рис. 1. Структура проектной документации согласно ГОСТ Р 59853

Проектно‑сметная документация. Как следует из ГОСТ Р 59853, под проектно‑сметной документацией понимается документация, которая определяет цели создания ИТ‑продукта, функциональные, пользовательские и бизнес‑требования, даты начала и окончания работ, ресурсы и финансовое обеспечение. Основным проектно‑сметным документом является техническое задание (далее — ТЗ), которое, в зависимости от специфики создания ИТ‑продукта, включает не только выявленные, оформленные и согласованные требования, но и перечень проектных решений, бюджетов и необходимых работ [Шаврина и др., 2019]. Более того, специальный стандарт ГОСТ 34.602 [18] закрепляет обязательные разделы ТЗ. К этим разделам относятся общие сведения, цели и назначение ИТ‑продукта, пользовательские и функциональные требования, состав и содержание работ, порядок создания ИТ‑продукта, приемка и другие требования, которые касаются эксплуатации программного решения.

Требуется отметить, закрепленные в национальных стандартах ГОСТ Р 59 853 и ГОСТ 34.602 рассмотренные выше разделы ТЗ противоречат процессной модели создания ИТ‑продуктов в рамках выполнения ИТ‑проектов, представленной в ГОСТ Р ИСО/МЭК 12 207 [19]. Противоречие заключается в том, что согласно разработанной модели объем работ, их длительность, материальные, трудовые и финансовые ресурсы, а также риски должны фиксироваться в базовом плане проекта, а не в ТЗ. По мнению автора настоящей статьи, ТЗ не должно включать информацию о бюджетах, сроках и объемах работ по следующим причинам:

  • Согласно данным The Standish Group International, доля успешно завершенных краткосрочных ИТ‑проектов составляет 67%, среднесрочных и долгосрочных ИТ‑проектов — 10% [The CHAOS Manifesto]. Следовательно, ТЗ и базовый план проекта, разрабатываемые в рамках отдельных самостоятельных процессов и оформленных в виде дополнительных соглашений к контракту, значительно увеличивают шансы создания желаемых высококачественных ИТ‑продуктов и успешного завершения ИТ‑проектов (спринтов, фаз жизненного цикла, контрактов и др.) [Petroșanu et al., Martínez et al., 2021].

  • Последовательная разработка ТЗ и базового плана проекта повышает точность определения существенных условий (предмет контракта, даты начала и окончания выполнения работ и др.). Повышение точности существенных условий уменьшает вероятность наступления комплаенс‑последствий и локализует негативный сценарий развития событий [Грицаев и др., 2018].

  • Отдельно разработанное ТЗ дает возможность заказчику обратиться к иному ИТ‑субъекту для получения альтернативного мнения в части создания ИТ‑продукта [Mazur et al., 2024, Kiemel et al., 2022; Nikolaenko et al., 2023]. Конкуренция является важным фактором, который обеспечивает баланс между экономией средств и достижением желаемых результатов. В связи с этим возможность разработки базового плана проекта и (или) ИТ‑продукта другими лицами позволяет заказчику выбрать лучшего ИТ‑субъекта, обладающего более высоким уровнем надежности, компетентности и зрелости. Более того, разработка ТЗ, базового плана проекта и ИТ‑продукта в рамках отдельных дополнительных соглашений к контракту делает возможным прекращение гражданско‑правовых отношений между заинтересованными сторонами без наступления тяжких комплаенс‑последствий.

  • Разработка ТЗ и базового плана проекта требует специальных компетенций, поэтому их имплементацией должны заниматься разные работники [Минзов и др., 2018; Николаенко, 2025a]. В частности, необходимыми компетенциями по разработке ТЗ обладают системный аналитик (код 06.022) [20], архитектор программного обеспечения (код 06.003) [21] и специалист по дизайну графических пользовательских интерфейсов (код 06.025) [22]. Компетенциями по определению организационной структуры проекта, оценке необходимых ресурсов, секвестрированию бюджетов, формированию календарного план‑графика проекта и элиминированию возможных рисков обладает только руководитель проекта в области ИТ (код 06.016) [23].

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

  1. иерархическая структура работ (структура декомпозиции работ, ИСР) — это детализированный перечень работ, которые необходимо выполнить для создания высококачественного ИТ‑продукта и достижения целей ИТ‑проекта (содержание, длительность, стоимость, качество) [Wijayanti et al., 2022];

  2. календарный план‑график (расписание проекта, календарный план) — это раздел базового плана, содержащий перечень работ проекта, их логические взаимосвязи и длительность, исполнителей, а также ресурсные, временные и внешние ограничения [24];

  3. диаграмма сети проекта (сетевой график) — это графический или табличный способ представления структуры работ, которые определяют ход реализации проекта, а также временные и логические отношения (взаимосвязи) между ними [25];

  4. бюджет проекта (смета) — это раздел базового плана проекта, содержащий общую сумму финансовых средств, распределенных по статьям и временным периодам (см. ст. 709 ГК РФ);

  5. перечень ресурсов — это раздел базового плана проекта, содержащий информацию о количестве и (или) объеме ресурсов, которые необходимы в определенное время или в течение определенного периода времени [Menezes et al., 2023; Gonzalez‑Granadillo et al., 2021]. К ресурсам проекта относятся квалифицированные работники, оборудование, консалтинговые услуги, расходные материалы, сырье, материальные, денежные средства и др.;

  6. организационная структура проекта — это иерархическая структура, которая структурирует отношения между участниками ИТ‑проекта с учетом их ролей, должностей и подчиненности;

  7. реестр рисков — это раздел базового плана проекта, который содержит информацию о возможных негативных и позитивных событиях, которые могут материализоваться во время выполнения работ проекта [Николаенко, 2018; Николаенко, 2025b];

  8. меры воздействия на риски (меры превентивного воздействия и принятия рисков), которые предусматривают превентивное воздействие на риски и реализацию мероприятий, требующих осуществления определенных функций для локализации наступивших проблем. Необходимо отметить, что после создания первой версии базового плана руководитель проекта в области ИТ обязан проверить его устойчивость. Если цели ИТ‑проекта при проверке перестают быть достижимыми, то базовый план проекта направляется на доработку;

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

Рабочая документация. Согласно ГОСТ Р 59793, ГОСТ 34.201 и ГОСТ 19.101, разработка рабочей документации выделена в отдельную стадию создания ИТ‑продукта, для которой характерна подготовка документов, содержащих сведения, необходимые и достаточные для ввода в эксплуатацию разрабатываемого ИТ‑продукта [Гончарова и др., 2018; Кича и др., 2022]. Кроме того, к рабочей документации, в зависимости от специфики подготовки программного решения, могут относиться документы, которые закрепляют требования к закупаемым техническим, программным, информационным и лингвистическим средствам у субподрядчиков.

Эксплуатационная документация является частью рабочей документации и применяется во время использования ИТ‑продукта пользователями. Отметим, что согласно ст. 726 ГК РФ подрядчик обязан передать заказчику вместе с результатом выполненных работ информацию по его эксплуатации [26]. Причем в силу ГОСТ Р 59 795 перечень эксплуатационной документации должен быть заблаговременно согласован с заказчиком.

Приемочная документация. Под приемочной документацией, как разъяснено в ГОСТ 59853, понимается документация, где фиксируются сведения, подтверждающие готовность ИТ‑продукта к приемке и передаче его в эксплуатацию пользователям [Баулин и др., 2020]. Согласно ГОСТ Р 59 792 приемочная документация подготавливается для того, чтобы проверить соответствие созданного ИТ‑продукта требованиям, зафиксированным в ТЗ. Основным документом, который устанавливает необходимый и достаточный объем испытаний для разработанного ИТ‑продукта, является программа и методика испытаний.

Стоит отметить, что требования ГОСТ Р 59 792 устанавливают три основных вида испытаний для созданного ИТ‑продукта — это предварительные испытания, опытная эксплуатация и приемочные испытания. Рассмотрим эти виды испытаний.

Предварительные испытания наступают после создания ИТ‑продукта, где во время испытаний специалист по тестированию в области ИТ (код 06.004) [27] проводит его отладку. В процессной модели создания ИТ‑продуктов отладка выполняется во время фазы жизненного цикла «тестирование ИТ‑продукта», где по завершении тестирования ИТ‑продукт становится верифицированным, то есть продуктом, который имеет объективные свидетельства того, что все установленные требования, заявленные заинтересованными сторонами, национальными и внутренними стандартами, были успешно выполнены [28].

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

Согласно ст. 720 ГК РФ, приемочные испытания проводятся с участием заказчика и подрядчика, где заказчик определяет степень соответствия созданного ИТ‑продукта заявленным требованиям, оценивает его качество и выявляет недостатки [Кудратова и др., 2019]. В процессной модели создания ИТ‑продуктов эти операции выполняются во время фазы жизненного цикла «окончание ИТ‑проекта», где по завершении приемки ИТ‑продукт становится валидированным, то есть высококачественным программным решением, которое имеет объективные свидетельства, что все испытания прошли успешно. Как правило, по итогам валидации ИТ‑продукта стороны контракта оформляют протокол испытаний, который легализует подписание соответствующего акта выполненных работ.

Важно отметить, что создание ИТ‑продуктов в рамках реализации ИТ‑проектов согласно концепции Agile не противоречит нормам действующего законодательства. В частности, в силу ст. 709 ГК РФ цена договора подряда не является существенным условием, благодаря чему стоимость работ может быть приблизительной либо рассчитываться на основании фактически затраченных трудовых и материальных ресурсов ИТ‑субъекта (time & materials). Подобное нивелирование рамок и ограничений дает возможность снизить вероятность наступления проектных рисков, связанных со стоимостью ИТ‑продукта. Кроме того, получение ИТ‑результатов в рамках коротких спринтов позволяет сократить объем подготовительных работ на стороне ИТ‑субъекта, что увеличивает темп подготовки программного кода.

Однако «поверхностная» проектная документация и отсутствие четких границ создания ИТ‑продукта в некоторых случаях могут стать серьезным недостатком Agile. В частности, недостаточная проработанность ТЗ делает ход выполнения ИТ‑проекта менее предсказуемым, так как участники команды ИТ‑проекта не могут оценить объем усилий, который им потребуется для создания той или иной пользовательской истории (user stories). Другим примером проявления «поверхностной» проектной документации являются трудности присоединения к ИТ‑проекту новых участников. Отсутствие ясных целей «картины ожиданий» достаточно легко может увести новых программистов в сторону от магистральной линии разработки.

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

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

  • Юридическая и проектная документация должны рассматриваться как единый набор документов, так как трудоустройство работников, создание ТЗ, базового плана проекта и ИТ‑продукта не представляется возможным без заключения трудовых договоров, контрактов и дополнительных соглашений к ним. Кроме того, совершенно очевидно, что определение точных характеристик существенных условий (предмета контракта, дат начала и окончания выполнения работ и др.) без наличия ТЗ и базового плана проекта трудноосуществимо.

Таким образом, на основании проведенного анализа национальных стандартов, декларирующих документальное сопровождение создания ИТ‑продуктов в рамках выполнения ИТ‑продуктов, предлагается усовершенствовать структуру проектной документации, закрепленной в ГОСТ Р 59853. В частности, предлагается объединить юридическую и проектную документацию с включением документов, которые обеспечивают накопление опыта, внедрение и распространение средств количественного контроля, выявление, формализацию и стандартизацию лучших практик (рис. 2).

Рис. 2. Структура документального сопровождения создания ИТ-продуктов в рамках выполнения ИТ-проектов
Рис. 2. Структура документального сопровождения создания ИТ-продуктов в рамках выполнения ИТ-проектов

Заключение

В 2024 г. группа компаний, действующая под брендом «ДРТ» (далее — Группа ДРТ) [29] представила результаты оценки зрелости систем управления рисками (далее — СУР). В число респондентов вошли 97 российских организаций нефинансового сектора (промышленность, транспорт и инфраструктура, потребительский сектор и др.). Уровень зрелости СУР измеряется в диапазоне от 0 до 1.

Результаты исследований показали, что наиболее высокий уровень зрелости СУР достигли организации нефтегазового сектора (0,73), наименьший — организации, занятые строительством и операциями с недвижимостью (0,25). Общий уровень зрелости управления рисками в 2024 г. составил 0,35, что незначительно выше по сравнению с прошлым периодом (в 2022 г. — 0,34). Необходимо отметить, что Группа ДРТ не проводила отдельно оценку уровня зрелости СУР для субъектов, занятых разработкой компьютерного программного обеспечения и оказанием консультационных услуг в данной области (ОКВЭД класс 62), относя область ИТ к смешанной группе «Высокие технологии, телекоммуникации, развлечения и СМИ». Зрелость управления рисками данной группы в 2024 г. составила 0,44.

В целом полученные результаты Группой ДРТ свидетельствуют о достаточно низком уровне зрелости СУР в отечественных ИТ‑организациях. Подобные обстоятельства ставят субъекты предпринимательской деятельности в очень уязвимое положение, так как с высокой степенью вероятности они будут заключать сделки с ненадежными контрагентами, которые не смогут гарантировать успешное создание безопасных ИТ‑продуктов.

На основании вышесказанного логично заключить, что создание высококачественных ИТ‑продуктов, митигация специальных и универсальных рисков, минимизация величины материального ущерба, получаемого от их наступления, возможно только при полном соответствии нормам действующего законодательства и требованиям национальных стандартов, строгом соблюдении последовательности выполнения процессов создания ИТ‑продуктов и выверенного документального сопровождения [Николаенко, 2026]. Важно подчеркнуть, что несоблюдение данных требований свидетельствует о ненадежности ИТ‑субъектов, а значит, их неспособности гарантировать успешное создание ИТ‑продуктов в рамках выполнения ИТ‑проектов (спринтов, фаз жизненных циклов, договоров и др.).

Список литературы

  1. Болтанова Е.С., Романова О.А., Бандорин Л.Е. Градостроительное право. М.: Проспект, 2022. 312 с. EDN: RWUAJS.

  2. Миронов В. Профессия «бизнес‑аналитик». М.: Олимп‑Бизнес, 2022. 238 с.

  3. Approach to formalizing software projects for solving design automation and project management tasks. A. Filippov, A. Romanov, A. Skalkin, J. Stroeva, N. Yarushkina. Software, 2023, vol. 2, Iss. 1, pp. 133–162. DOI: https://doi.org/10.3390/software2010006. EDN: OJYZLM.

  4. Шаврина К.В., Чекалкина Н.Д., Максимов К.В. Согласование проектно‑сметной документации в электронном виде. Молодой ученый, 2019, № 22 (260), с. 201–206. EDN: FRBLUH.

  5. The CHAOS Manifesto. URL: https://larlet.fr/static/david/stream/ChaosManifesto2013.pdf (дата обращения 10.06.2025).

  6. E‑commerce sales revenues forecasting by means of dynamically designing, developing and validating a directed acyclic graph (DAG) network for deep learning. D. Petroșanu, A. Pirjan, G. Căruţaşu, A. Tăbușcă, D. Zirra, A. Perju‑Mitran. Electronics, 2022, vol. 11, Iss. 18, 2940. DOI: https://doi.org/10.3390/electronics11182940.

  7. Wind speed analysis of hurricane sandy. P. Martínez, I. Pérez, M. Sánchez, M. García, N. Pardo. Atmosphere, 2021, vol. 12, Iss. 11, 1480. DOI: https://doi.org/10.3390/atmos12111480.

  8. Грицаев Р.Т., Николаенко В.С., Пузанов А.Л. Основная, вспомогательная и необязательная документация в ИТ‑проектах. Управление знаниями в цифровой экономике: сборник научных статей Международной молодежной конференции по управлению знаниями. М.: ВШЭ, 2018. С. 36–41. EDN: YUSPJB.

  9. Mazur K., Saleh M., Hornung M. Integrating life cycle assessment in conceptual aircraft design: a comparative tool analysis. Aerospace, 2024, vol. 11, Iss. 1, 101. DOI: https://doi.org/10.3390/aerospace11010101. EDN: VYECKF.

  10. How to simplify life cycle assessment for industrial applications — a comprehensive review. S. Kiemel, C. Rietdorf, M. Schutzbach, R. Miehe. Sustainability, 2022, vol. 14, Iss. 23, 15704. DOI: https://doi.org/10.3390/su142315704. EDN: BLJPPL.

  11. Минзов А.С., Мельникова О.И. Применение профессиональных стандартов при обучении методам и технологиям программной инженерии в высшей школе. Открытое образование, 2018, т. 22, № 2, с. 27–36. DOI: https://doi.org/10.21686/1818-4243-2018-2-27-36. EDN: YXOPLK.

  12. Wijayanti D., Sukwika T., Ramli S. Analisis Insiden Fatality Akibat Covid-19 Menggunakan Metode 5 Why, SCAT, BowTie, dan Interpretive Structural Model (ISM). Jurnal Migasian, 2022, vol. 6, № 1, pp. 84–92. DOI: 10.36601/jurnal‑migasian.v6i1.186.

  13. Menezes T. A review to find elicitation methods for business process automation software. Software, 2023, vol. 2, Iss. 2, pp. 177–196. DOI: https://doi.org/10.3390/software2020008.

  14. Automated cyber and privacy risk management toolkit. G. Gonzalez‑Granadillo, S.A. Menesidou, D. Papamartzivanos, R. Romeu, D. Navarro‑Llobet, C. Okoh, S. Nifakos, C. Xenakis, E. Panaousis. Sensors, 2021, vol. 21, № 16, 5493. DOI: https://doi.org/10.3390/s21165493. EDN: JXOORY.

  15. Nikolaenko V., Sidorov A. Assessment of project management maturity models strengths and weaknesses. Journal of Risk and Financial Management, 2023, vol. 16, Iss. 2, 121. DOI: https://doi.org/10.3390/jrfm16020121. EDN: UOEIOH.

  16. Гончарова Т.В., Литвина Д.Б. Правила создания комплекта рабочей документации. Экономические науки. Современное состояние и перспективы развития: материалы ХI международной студенческой научно‑практической конференции. Екатеринбург: ИМПРУВ, 2018. С. 27–30. EDN: YSYELS.

  17. Вариант оформления документа «перечень (комплектность) рабочей конструкторской документации». Е.И. Кича, М.А. Кича, Д.С. Маловик, В.С. Михайленко, В.В. Зайцева Вестник МАНЭБ, 2022, т. 27, № 2, с. 49–58. EDN: GZINJV.

  18. Баулин А.В., Перунов А.С., Ермаков В.А. Строительный контроль в процессе сдачи объекта в эксплуатацию. Промышленное и гражданское строительство, 2020, № 1, с. 53–59. DOI: 10.33622/0869-7019.2020.01.53–59. EDN: WRNLAC.

  19. Кудратова Г.М., Тарасов Р.В., Макарова Л.В. Разработка мероприятий по совершенствованию приемочного контроля продукции строительного назначения. Дневник науки, 2019, № 1 (25), с. 1−8. EDN: YWAJSX.

  20. Николаенко В.С. Анализ требований к квалификации специалистов, занятых созданием ИТ‑продуктов в рамках выполнения ИТ‑проектов // Векторы благополучия: экономика и социум. — 2025а. — Т. 53. — № 3. — С. 97–109. DOI: https://doi.org/10.18799/26584956/2025/3/1992

  21. Николаенко В.С. Негативные и позитивные риски в ИТ‑проектах // Вестник московского университета. Серия 21: Управление (государство и общество), 2018 — № 3. — С. 91–124. — URL: https://clck.ru/3SuMtU

  22. Николаенко В.С. Анализ универсальных рисков в ИТ‑проектах // Векторы благополучия: экономика и социум. — 2025b. — Т. 53. — № 4. — С. 1–19. DOI: https://doi.org/10.18799/26584956/2025/4/2022

  23. Николаенко В.С. Документальное сопровождение создания ИТ‑продуктов в рамках выполнения ИТ‑проектов // Векторы благополучия: экономика и социум. — 2026. — Т. 54. — № 1. — С. 37–48. DOI: https://doi.org/10.18799/26584956/2026/1/2023

[1] ГОСТ 21.101–2020. Система проектной документации для строительства. Основные требования к проектной и рабочей документации. — М.: Стандартинформ, 2020. — 70 с.

[2] Градостроительный кодекс Российской Федерации (ГрК РФ). — М.: Эксмо, 2023. — 463 с.

[3] О составе разделов проектной документации и требованиях к их содержанию: постановление Правительства РФ от 16.02.2008 г. № 87. URL: https://clck.ru/34AAKp (дата обращения 10.06.2025).

[4] ГОСТ Р 59793–2021. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. — М.: Стандартинформ, 2020. — 8 с.

[5] ГОСТ 34.201–89. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем. — М.: ИПК Издательство стандартов, 2002. — 11 с.

[6] ГОСТ Р 59795–2021. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов. — М.: Российский институт стандартизации, 2021. — 32 с.

[7] ГОСТ 19.604–78. Единая система программной документации. Правила внесения изменений в программные документы, выполненные печатным способом. — М.: Стандартинформ, 2010. — 6 с.

[8] ГОСТ 19.602–78. Единая система программной документации. Правила дублирования, учета и хранения программных документов, выполненных печатным способом. — М.: Стандартинформ, 2010. — 4 с.

[9] ГОСТ 19.601–78. Единая система программной документации. Общие правила дублирования, учета и хранения. — М.: Стандартинформ, 2010. — 6 с.

[10] ГОСТ 19.507–79. Единая система программной документации. Ведомость эксплуатационных документов. — М.: Стандартинформ, 2010. — 6 с.

[11] ГОСТ 19.506–79 Единая система программной документации. Описание языка. Требования к содержанию и оформлению. — М.: Стандартинформ, 2010. — 3 с.

[12] ГОСТ 19.505–79. Единая система программной документации. Руководство оператора. Требования к содержанию и оформлению. — М.: Стандартинформ, 2010. — 3 с.

[13] ГОСТ 19.503–79. Единая система программной документации. Руководство системного программиста. Требования к содержанию и оформлению. — М.: Стандартинформ, 2010. — 4 с.

[14] ГОСТ 19.502–78. Единая система программной документации. Описание применения. Требования к содержанию и оформлению. — М.: Стандартинформ, 2010. — 2 с.

[15] ГОСТ Р 59792–2021. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем. — М.: Российский институт стандартизации, 2021. — 8 с.

[16] О стандартизации в Российской Федерации: федер. закон от 29.06.2015 г. № 162-ФЗ. URL: https://clck.ru/34Bwjs (дата обращения 10.06.2025).

[17] ГОСТ Р 59853–2021. Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения. — М.: Российский институт стандартизации, 2021. — 16 с.

[18] ГОСТ 34.602–2020. Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. — М.: Стандартинформ, 2009. — 13 с.

[19] ГОСТ Р ИСО/МЭК 12207–2010. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. — М.: Стандратинформ, 2010. — 105 с.

[20] Профессиональный стандарт 06.022 «Системный аналитик». URL: https://clck.ru/PaFVa (дата обращения 10.06.2025).

[21] Профессиональный стандарт 06.003 «Архитектор программного обеспечения». URL: https://clck.ru/37inb7 (дата обращения 10.06.2025).

[22] Профессиональный стандарт 06.025 «Специалист по дизайну графических пользовательских интерфейсов». URL: https://clck.ru/PaFGs (дата обращения 10.06.2025).

[23] Профессиональный стандарт 06.016 «Руководитель проектов в области информационных технологий». URL: https://clck.ru/PaFDk (дата обращения 10.06.2025).

[24] ГОСТ Р 54869–2011. Проектный менеджмент. Требования к управлению проектом. — М.: Стандартинформ, 2019. — 8 с.

[25] ГОСТ Р 56715.5–2015. Проектный менеджмент. Системы проектного менеджмента. Часть 5. Термины и определения. — М.: Стандартинформ, 2020. — 12 с.

[26] Гражданский кодекс Российской Федерации (ГК РФ). Комментарий к последним изменениям. — М.: АБАК, 2019. — 752 с.

[27] Профессиональный стандарт 06.004 «Специалист по тестированию в области информационных технологий». URL: https://clck.ru/PaFa5 (дата обращения 10.06.2025).

[28] ГОСТ ISO 9000–2011. Системы менеджмента качества. Основные положения и словарь. — М.: Стандартинформ, 2020. — 28 с.

[29] Официальный сайт «Группа ДРТ». URL: https://delret.ru/about (дата обращения 10.06.2025).