Введение

Исследование бизнес-деятельности 495 ИТ-субъектов Томской области (ОКВЭД код 62), проведенное в рамках научно-исследовательского гранта РФФИ №16-36-00031 «мол_а», позволило установить, что во время создания ИТ-продуктов в рамках выполнения ИТ-проектов могут материализоваться порядка 105 универсальных рисков^[29]. Под универсальными рисками понимаются вероятные события, актуальные для ИТ-проектов (спринты, фазы жизненного цикла, контракты и др.), независимо от их масштабов, сложности, длительностей (краткосрочные, среднесрочные, долгосрочные), типов (ПО, мобильное приложение, ИС и др.), концепций создания ИТ-продуктов (Waterfall, Agile) и численности участников. Анализ идентифицированных универсальных рисков показал, что одним из механизмов их элиминирования является высокая степень освоения ИТ-субъектами положений о процессах создания ИТ-продуктов и управления ИТ-проектами, которые закреплены в основополагающих национальных стандартах. К данным стандартам относятся ГОСТ Р ИСО/МЭК 12207^[1], серия стандартов ИСО/МЭК 15504^[2][3], ГОСТ Р ИСО 21500^[4] и семейство стандартов «Проектный менеджмент»^{[5],[6],[7],[8],[9],[10]}.

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

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

Национальный стандарт ГОСТ Р ИСО/МЭК 12207 описывает специальные процессы, которые должны быть реализованы на стороне ИТ-субъекта, если он намерен создавать, поставлять и успешно эксплуатировать ИТ-продукты. Для раскрытия особенностей применения данного стандарта раскроем суть и содержание понятия «процесс» подробнее.

Согласно ГОСТ ISO 9000^[11], ГОСТ Р ИСО/МЭК 21827^[12], ГОСТ Р ИСО/МЭК 33001^[13], ГОСТ Р 54869^[14] и ГОСТ Р ИСО/МЭК 15504-1 под процессом необходимо понимать совокупность действий, которые направлены на достижение определенной цели, где вход процесса – это объекты, необходимые для нормальной работы процесса (информация, ресурсы, регламенты и др.), а выход процесса – это результаты достижения цели процесса.

В научной литературе также можно встретить и другие толкования понятия «процесс». Например, О. Вишняков^[28] в своих трудах определяет процесс как повторяющуюся упорядоченную цепочку действий, которая создает значимый результат для заказчика, пользователя, клиента, потребителя и др. Более развернутое определение можно встретить в работах Ю. Т. Шестопал, Н. Ю. Дорофеева, Н. Ю. Шестопал и Э. А. Андреевой. Под процессом ученые понимают устойчивую, целенаправленную совокупность взаимосвязанных видов деятельности, которая по определенной технологии преобразует входы и выходы, где вход – это ресурс, который необходим процессу, а выход – это результат (продукт) выполнения процесса^[30].

Рассмотренные выше определения и требования по документированию процессов, закрепленные в стандарте ГОСТ Р 57098^[15], позволяют заключить, что процесс включает в себя такие элементы, как цель, реализуемые действия, функции и их последовательность, потребляемые ресурсы (вход процесса), результат (выход процесса), риски и др. Пример графического изображения процесса согласно ГОСТ Р 57098 представлен на рис. 1.

Анализ положений, закрепленных в ГОСТ Р ИСО/МЭК 12207, показал, что стандарт описывает цели, желаемые результаты, входы и выходы 43 процессов жизненного цикла ИТ-продукта, которые объединены в 7 групп.

Несмотря на исчерпывающую совокупность процессов, необходимых для создания ИТ-продуктов, применение ГОСТ Р ИСО/МЭК 12207 имеет ряд ограничений, о которых необходимо упомянуть.

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

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

• В-третьих, стандарт не устанавливает применение конкретной модели жизненного цикла (далее – ЖЦ) ИТ-продукта. Ответственность за возможные последствия, связанные с выбором той либо иной модели ЖЦ, согласно положениям стандарта, возлагаются на заинтересованные стороны. Данное обстоятельство также является существенным недостатком, т. к. проведенное исследование показало, что для создания ИТ-продуктов необходимо применять модель ЖЦ ИТ-проекта, включающую в себя квантификацию ЖЦ на 6 фаз: начало ИТ-проекта, определение требований к ИТ-продукту, планирование ИТ-проекта, создание ИТ-продукта, тестирование ИТ-продукта и окончание ИТ-проекта.

Серия стандартов ИСО/МЭК 15504 предлагает использовать процессную модель, состоящую из 60 процессов – 10 процессов соглашения, 13 процессов организационного обеспечения, 7 процессов проекта, 13 технических процессов, 6 процессов реализации ПС, 8 процессов поддержки ПС и 3 процессов повторного применения ПС. Согласно ГОСТ Р ИСО/МЭК 15504-5^[16] под процессной моделью понимается модель, состоящая из логической последовательности процессов, выполнение которых гарантирует получение желаемого результата. Несмотря на исчерпывающее описание процессов, описанных в серии стандартов ИСО/МЭК 15504, проведенный анализ показал, что предлагаемая процессная модель не описывает последовательность выполнения действий, оставляя решение о выборе процессов и определение их последовательности выполнения за пользователями. Стандарты не содержат информации о возможных проблемах, которые могут материализоваться в ходе выполнения процессов, о мерах, элиминирующих эти проблемы, а также о метриках, которые бы показывали результативность и эффективность выполнения процессов. Кроме того, предлагаемая модель не содержит процессов анализа проблем, выявления лучших практик, стандартизации и распространения полученного опыта среди заинтересованных сторон и работников ИТ-субъекта. Отсутствие подобных процессов на стороне ИТ-субъекта создает угрозу утраты выученных уроков, что в будущих проектах может привести к повторному появлению ранее решенных проблем.

ГОСТ Р ИСО 21500 распределяет 39 процессов проектного менеджмента на управленческие (инициация, планирование, исполнение, контроль и завершение) и предметные группы (интеграция, заинтересованные стороны, содержание, ресурсы, сроки, стоимость, риски, качество, закупки и коммуникации). Согласно условиям, закрепленным в разделе 4, требования ГОСТ Р ИСО 21500 носят рекомендательный характер, т. к. количество процессов и их последовательность зависит от области, в которой выполняются проектные работы. Например, если используются заемные средства (кредиты), то в проект должны быть добавлены процессы, связанные с финансами. Если проектные работы могут оказать негативное влияние на жизнь и здоровье человека, то в проект необходимо включить процессы по технике безопасности и охране здоровья. Если оказывается негативное влияние на окружающую среду, то процессы, связанные с экологической безопасностью и др.

Кроме того, в ГОСТ Р ИСО 21500 отмечается, что количество процессов и их последовательность также зависит от зрелости субъекта и его накопленного опыта. В качестве примера следует привести PMBOK® Guide, где:

• в первом издании (1996 г.) было зафиксировано 9 предметных групп и 37 процессов;

• во втором (2000 г.) – 9 предметных групп и 39 процессов;

• в третьем (2004 г.) – 9 предметных групп и 44 процесса;

• в четвертом (2008 г.)^[17] – 9 предметных групп и 47 процессов;

• в пятом (2013 г.)^[18] – 10 предметных групп и 47 процессов;

• в шестом (2017 г.)^[19] – 10 предметных групп и 49 процессов.

Среди ключевых недостатков ГОСТ Р ИСО 21500 необходимо отметить, что представленные процессы дают только общее представление о возможном количестве и последовательности выполнения работ.

Несмотря на расширенный перечень процессов проектного менеджмента (61 наименование) аналогичные недостатки были также выявлены при анализе семейства стандартов «Проектный менеджмент». Однако данное семейство стандартов закрепляет важное положение, которое заключается в декомпозиции процесса выполнения проекта на совокупность подпроцессов с последующим объединением их в самостоятельные группы. Например, согласно требованиям ГОСТ Р 54869 и Р 50.1.028^[20], процесс выполнения проекта включает в себя 5 процессов более низкого уровня – процесс инициации проекта, процесс планирования проекта, процесс организации и исполнения проекта, процесс контроллинга проекта и процесс завершения проекта. Говоря же о наличии подпроцессов следует обратиться к разделу 5 ГОСТ Р 54869, где отмечается, что наличие, количество, повторяемость и последовательность процессов, подпроцессов и функций в первую очередь зависит от масштаба, сложности и длительности работ проекта. Например, если ИТ-продукт создается согласно концепции Agile, то процесс организации и исполнения проекта в части формирования бюджета может выполняться частично либо вовсе отсутствовать.

Таким образом, на основании проведенного анализа основополагающих национальных стандартов автором настоящей статьи предлагается распределить процессы создания ИТ-продуктов в рамках выполнения ИТ-проектов на 3 группы: процессы, реализуемые во время фаз жизненного цикла ИТ-проекта, процессы, распределенные по предметным группам, и процессы контроллинга ИТ-проекта. Рассмотрим данные группы процессов подробнее.

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

В качестве примера наступления нежелательного исхода для заинтересованных сторон, которые спонтанно инициировали запуск ИТ-проекта, можно привести дело № А67-4580/2016^[21], в котором между сторонами отсутствовали документальные соглашения, подтверждающие заключение контракта. Однако в ходе разбирательства было установлено, что требующие исполнения гражданско-правовые обязательства все же возникли.

Похожая ситуация произошла в деле № А67-3471/2010^[22], где подписание актов сдачи-приемки оказанных услуг по техническому обслуживанию и обновлению баз данных ИСС «Кодекс» послужило доказательством того, что между сторонами возникли определенные обязательства.

Другим примером тяжких комплаенс-последствий для заинтересованных сторон является дело № А45-15497/2020^[23]. Согласно материалам, при эксплуатации мобильного приложения «Boom Boom» заказчик выявил большое количество программных недостатков и потребовал от ИТ-субъекта переделать работу. ИТ-субъект не согласился с предъявленной претензией и отказал в удовлетворении данного требования. Для определения характера недостатков суд был вынужден провести экспертизу, которая установила, что результат выполненных работ частично соответствует условиям контракта, является некачественным и требует устранения выявленных дефектов. Размер причиненного ущерба составил 340,8 тыс. руб.

Нередки случаи, когда заинтересованные стороны после завершения ИТ-проектов запрещают своим бывшим контрагентам и работникам использовать ИТ-продукты. В качестве примера следует привести дело № А53-23110/22^[24], где истец попросил суд запретить ответчику использовать ИТ-продукт «LabWagon». Другим примером является дело № А40-90889/21-134-529^[25], где истец требовал запретить использование его ИТ-продукта, изъять все материальные носители с копиями ИТ-продукта и взыскать компенсацию за нарушение исключительных прав в размере 5 млн. руб.

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

Цели, действия и результаты процессов процессной модели создания ИТ-продуктов в рамках выполнения ИТ-проектов представлены в табл. 1.

Табл. 1. Цели, действия и результаты процессов процессной модели создания ИТ-продуктов в рамках выполнения ИТ-проектов

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

Процессы ИТ-проекта, распределенные по предметным группам. Процессы, относящиеся к функциональным областям управления проектами согласно ГОСТ Р ИСО 21500 должны быть дифференцированы на предметные группы. Предметная группа – это выделенная область проекта, определяемая ее требованиями к знаниям^[31]. В частности, управление рисками в проекте является отдельным знаниевым доменом, который регулируется собственным семейством стандартов ГОСТ Р ИСО 31000^[26], управление качеством – ГОСТ ISO 9000, управление закупками и интеграцией – нормами действующего гражданского законодательства^[27] и др. В литературе также можно встретить синонимы понятия «предметная группа». Например, А. А. Дульзон в своих трудах предметные группы управления проектами называет функциями управления^[32]. В своде лучших практик управления проектами PMBOK® Guide используется понятие области знаний, которыми руководитель проекта должен обладать для успешного завершения проекта. В ряде национальных стандартов, например, ГОСТ Р 54869, предметные группы управления проектами именуют как области управления.

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

 Табл. 2. Процессы ИТ-проекта, распределенные по предметным группам

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

Цели контроллинга совпадают с целями ИТ-проекта – создать ИТ-продукт в назначенный срок и в границах утвержденного бюджета^[33]. Для достижения запланированных целей ИТ-проекта во время контроллинга осуществляется взаимодействие с заинтересованными сторонами, управление их ожиданиями, сбор и протоколирование запросов на изменения, а также внесение изменений в контракты, дополнительные соглашения к ним, технические задания, базовые планы проектов либо ИТ-продуктов. Внесение изменений является ключевым процессом контроллинга, который приводит к изменению существенных условий, в связи с чем рекомендуется в тексте контракта заблаговременно описывать механизм внесения изменений. В табл. 3.5 дается подробное описание процессов контроллинга.

 Табл. 3. Процессы контроллинга ИТ-проекта

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

На основании проведенного анализа основополагающих национальных стандартов, разработанной процессной модели, а также предложенного распределения процессов автор настоящей статьи разработал модель, состоящую из 62 подпроцессов создания ИТ-продуктов в рамках выполнения ИТ-проектов (рис. 3).

Разработанная модель представляет собой замкнутую последовательность подпроцессов, распределенных по фазам жизненного цикла и предметным группам, где каждый подпроцесс направлен на получение конкретного измеримого результата(-ов). Замкнутость последовательности подпроцессов указывает на их непрерывность, взаимосвязь и взаимозависимость. Данное обстоятельство подчеркивает важность и значимость каждого подпроцесса. Например, если будут отсутствовать такие процессы, как «B.5 Валидирование ТЗ», «С.13 Валидирование базового плана проекта» и (или) «F.1 Валидирование ИТ-продукта», то может возникнуть проблема, связанная с тем, что заказчик выявит недостатки ИТ-продукта во время его эксплуатации. Кроме того, анализ разработанной модели показал, что самым трудоемким является процесс планирования ИТ-проекта, где нарушение последовательности выполнения подпроцессов создает угрозу получения недостоверных значений в базовом плане проекта и искажение существенных условий контракта.

Заключение

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

Процессная модель универсальна, поэтому подходит для Waterfall и Agile. Универсальность возможна за счет выделения процесса создания ИТ-продукта в отдельную фазу жизненного цикла ИТ-проекта «Создание ИТ-продукта», где решение о способе создания ИТ-продукта ИТ-субъект определяет самостоятельно.

Модель соответствует требованиям, закрепленным в основополагающих национальных стандартах (ГОСТ Р ИСО/МЭК 12207, серия стандартов ИСО/МЭК 15504, ГОСТ Р ИСО 21500 и семейство стандартов «Проектный менеджмент»), дополняя их в части распределения процессов создания ИТ-продуктов в рамках выполнения ИТ-проектов на следующие группы: процессы, реализуемые во время фаз жизненного цикла ИТ-проекта; процессы, распределенные по предметным группам и процессы контроллинга ИТ-проекта.

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

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

Благодаря выявлению 62 подпроцессов удалось не только идентифицировать их результаты, потребляемые трудовые, материальные и финансовые ресурсы, метрики, риски, превентивные меры воздействия, но и определить обязательные разделы для ключевых проектных документов. Например, было установлено, что базовый план проекта должен включать в себя следующие разделы: иерархическая структура работ (ИСР), календарный план-график, диаграмма сети проекта, бюджет проекта, перечень ресурсов, организационная структура проекта, реестр рисков, меры воздействия на риски и реестр заинтересованных сторон. Некачественное, частичное выполнение либо невыполнение данного условия создаст угрозу получения недостоверных значений в базовом плане проекта и искажает существенные условия контракта.

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

^[2] ГОСТ Р ИСО/МЭК 15504-1-2009. Информационные технологии. Оценка процессов. Часть 1. Концепция и словарь. – М.: Стандартинформ, 2017. – 20 с.

^[3] ГОСТ Р ИСОМЭК 15504-2-2009. Информационные технологии. Оценка процессов. Часть 2. Проведение оценки. – М.: Стандартинформ, 2017. – 16 с.

^[4] ГОСТ Р ИСО 21500-2014. Руководство по проектному менеджменту. – М.: Стандартинформ, 2015. – 46 с.

^[5] ГОСТ Р 56716-2015. Проектный менеджмент. Техника сетевого планирования. Общие положения и терминология. – М. : Стандартинформ, 2020. – 20 с.

^[6] ГОСТ Р 56715.1-2015. Проектный менеджмент. Системы проектного менеджмента. Часть 1. Основные положения. – М.: Стандратинформ, 2017. – 11 с.

^[7] ГОСТ Р 56715.2-2015. Проектный менеджмент. Системы проектного менеджмента. Часть 2. Процессы и процессная модель. – М.: Стандратинформ, 2016. – 42 с.

^[8] ГОСТ Р 56715.3-2015. Проектный менеджмент. Системы проектного менеджмента. Часть 3. Методы. – М.: Стандратинформ, 2016. – 11 с.

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

^[10] ГОСТ Р МЭК 61160-2015. Проектный менеджмент. Документальный анализ проекта. – М. : Стандартинформ, 2016. – 28 с.

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

^[12] ГОСТ Р ИСО/МЭК 21827-2010. Информационная технология. Методы и средства обеспечения безопасности. Проектирование систем безопасности. Модель зрелости процесса. – М.: Стандартинформ, 2015. – 188 с.

^[13] ГОСТ Р ИСО/МЭК 33001-2017. Информационные технологии. Оценка процесса. Понятия и терминология. – М.: Стандартинформ, 2017. – 16 с.

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

^[15] ГОСТ Р 57098-2016/ISO/IEC TR 24774: 2010. Системная и программная инженерия. Управление жизненным циклом. Руководство для описания процесса. – М.: Стандартинформ, 2018. – 14 с.

^[16] ГОСТ Р ИСОМЭК 15504-5-2009. Информационные технологии. Оценка процессов. Часть 5. Образец модели оценки процессов жизненного цикла программного обеспечения. – М.: Стандартинформ, 2016. – 158 с.

^[17] Project management body of knowledge. Guide 4th edition (PMBOK-4). – Project Management Institute (PMI), 2008. – 506 p.

^[18] Project management body of knowledge. Guide 5th edition (PMBOK-5). – Project Management Institute (PMI), 2013. – 616 p.

^[19] Project management body of knowledge. Guide 6th edition (PMBOK-6). – Project Management Institute (PMI), 2017. – 756 p.

^[20] Р 50.1.028-2001. Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования. – М.: ГОССТАНДАРТ РОССИИ, 2003. – 50 с.

^[21] Решение Арбитражного суда Томской области по делу № А67-4580/2016 от 10.10.2016 г. [Электронный ресурс]. – URL: https://clck.ru/m5nMz (Дата обращения: 31.01.2024 г.).

^[22] Решение Арбитражного суда Томской области по делу № А67-3471/2010 от 28.06.2010 г. [Электронный ресурс]. – URL: https://clck.ru/m4kbL (Дата обращения: 31.01.2024 г.).

^[23] Решение Арбитражного суда Новосибирской области по делу № А45-15497/2020 от 24.03.2022 г. [Электронный ресурс]. – URL: https://clck.ru/36d7VV (Дата обращения: 31.01.2024 г.).

^[24] Решение Арбитражного суда Ростовской области по делу № А53-23110/22 от 07.06.2023 г. [Электронный ресурс]. – URL: https://clck.ru/36cr8y (Дата обращения: 31.01.2024 г.).

^[25] Решение Арбитражного суда города Москвы по делу № А40-90889/21-134-529 от 05.10.2023 г. [Электронный ресурс]. – URL: https://clck.ru/36cmjw (Дата обращения: 31.01.2024 г.).

^[26] ISO 31000:2009. «Risk Management – Principles and Guidelines». – 2013. – 34 p.

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

^[28] Вишняков О. Преимущество повторяемости. Практическое руководство по бизнес-процессам. Процессы и их описание. СПб.: Питер. 2022. 304 с.

^[29] Nikolaenko V., Sidorov A.. Analysis of 105 IT Project Risks. Journal of Risk and Financial Management. 2023. vol. 16(1). no. 33. pp. 1-20. DOI: https://doi.org/10.3390/jrfm16010033

^[30] Шестопал Ю. Т., Дорофеев Н. Ю., Шестопал Н. Ю., Андреева Э. А. Управление качеством. М.: ИНФРА-М. 2019. 331 с.

^[31] Alasmari E., Martinez-Vazquez P., Baniotopoulos C. A Systematic Literature Review of the Adoption of Building Information Modelling (BIM) on Life Cycle Cost (LCC). Buildings. 2022. vol. 12(11). no. 1829. pp. 1-25. DOI: https://doi.org/10.3390/buildings12111829

^[32] Дульзон А. А. Управление проектами. Томск: Изд-во Томского политехнического университета. 2013. 335 с.

^[33] Barahmand Z., Eikeland M. S. Life Cycle Assessment under Uncertainty: A Scoping Review. World. 2022. vol. 3(3). pp. 692-717. DOI: https://doi.org/10.3390/world3030039

^[34] Николаенко В.С. Анализ процессов создания ИТ-продуктов в рамках выполнения ИТ-проектов // Проблемы анализа риска, 2025. – Т. 22. – № 1. – С. 68-87.