Инжиниринг требований к информационно-технологической поддержке управления предприятием на основе моделирования бизнес-архитектуры тема диссертации и автореферата по ВАК РФ 08.00.13, кандидат наук Лепехин Александр Андреевич

• Лепехин Александр Андреевич
• кандидат наук
• 2022

Оглавление диссертации кандидат наук Лепехин Александр Андреевич

ВВЕДЕНИЕ

ГЛАВА 1. ИНЖИНИРИНГ ТРЕБОВАНИЙ ИНФОРМАЦИОННО-ТЕХНОЛОГИЧЕСКОЙ ПОДДЕРЖКИ

1.1. Исследования в области инжиниринга требований

1.2 Источники требований

1.3 Подходы и методы инжиниринга требований

1.4 Проблемы в области инжиниринга требований

ГЛАВА 2. РАЗРАБОТКА МЕТОДА ИНЖИНИРИНГА ТРЕБОВАНИЙ НА ОСНОВЕ АРХИТЕКТУРНОГО ПОДХОДА

2.1 Обзор существующих концепций и стандартов Архитектуры предприятия

2.2 Архитектурный стандарт TOGAF и Метод Развития Архитектуры предприятия (Architecture Development Method)

2.3 Сопоставление элементов инжиниринга требований с элементами стандарта TOGAF

2.4 Метод инжиниринга требований на основе стандарта TOGAF

2.5 Методика оценки стоимости работ по разработке и внедрению информационно-технологических сервисов

ГЛАВА 3. ПРИМЕНЕНИЕ МЕТОДА ИНЖИНИРИНГА ТРЕБОВАНИЙ В ПРОЕКТЕ ВНЕДРЕНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ

3.1 Характеристика проекта

3.2 Инжиниринг требований к информационной системе

3.3 Оценка стоимости разработки и внедрения ИТ-сервисов корпоративного портала

3.4. Полезность метода инжиниринга требований к информационно -технологической поддержке управления предприятием

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

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

ВВЕДЕНИЕ

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

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

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

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

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

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

Степень разработанности проблемы. В диссертации рассмотрено становление дисциплины инжиниринга требований, существующие подходы и методы инжиниринга требований, а также имеющиеся в данной области проблемы и открытые исследовательские вопросы. Данным вопросам посвящены труды Р. Харвелла, Д. Росса, К. Шомана, П. Зейв, Э. Габба, Л. Маколей, С. и Дж. Робертсонов, С. Люсьена, Д. Леффингвелла, Х. Краснера, С. Поттса, Б.А. Позина и др.

Вопросы развития концепции «архитектуры предприятия» и архитектурного подхода к управлению освещались в трудах Дж. Захмана, М. Ланкхорста, С. Спивака, С. Хилла, Д. Гринфоста, Г. Ричардсона, И.В. Ильина, В.К. Батоврина и др.

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

консорциумы и институциональные объединения, такие как The Open Group, Gartner Group, IEEE.

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

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

1. Исследовать сущность и специфику инжиниринга требований к информационно-технологической поддержке управления предприятием;

2. Проанализировать существующие методы инжиниринга требований и описать взаимосвязь этапов инжиниринга требований с архитектурным подходом;

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

4. Разработать метод инжиниринга требований к информационно-технологической поддержке управления предприятием на основе архитектурного подхода;

5. Разработать методику оценки стоимости работ по разработке и внедрению информационно-технологических сервисов;

6. На основе разработанной методики оценки стоимости предложить развитие модели совокупной стоимости владения информационной системой;

7. Разработать рекомендации по апробации метода инжиниринга требований, основанного на архитектурном подходе;

8. Провести апробацию методики оценки стоимости разработки и внедрения информационно-технологических сервисов для внедрения корпоративного портала в консалтинговой ИТ-компании

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

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

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

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

Информационную базу исследования составляют научные труды зарубежных и отечественных ученых, а также практикующих специалистов, опубликованные в изданиях, индексируемых в наукометрических базах Scopus, Web of Science, РИНЦ.

Научная новизна состоит в разработке метода инжиниринга требований на основе моделирования архитектуры предприятия, который

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

1. Обоснована необходимость формирования комплексного подхода к инжинирингу требований на базе концепции архитектуры предприятия.

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

3. Предложен подход к моделированию предметной области инжиниринга требований средствами языка моделирования архитектуры предприятия ArchiMate.

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

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

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

дополняющая существующие методы расчета затрат на внедрение и эксплуатацию информационных систем.

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

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

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

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

паспорта специальности 08.00.13 - Математические и инструментальные методы экономики.

Апробация и реализация результатов исследования. Результаты работы обсуждались и изложены в материалах:

- научной конференции с международным участием «Неделя Науки СПбПУ» (Санкт-Петербург, 2016 г.);

- научной конференции с международным участием «Неделя Науки СПбПУ» (Санкт-Петербург, 2017 г.);

- международной научной конференции "Business Technologies for Sustainable Urban Development", SPBWOSCE 2017 (Санкт-Петербург, 2017 г.);

- 30-й международной конференции IBIMA 2017 - Vision 2020: Sustainable Economic development, Innovation Management, and Global Growth (Мадрид, 2017 г.);

- научной конференции с международным участием «Неделя Науки СПбПУ» (Санкт-Петербург, 2018 г.);

- международной научной конференции "Business Technologies for Sustainable Urban Development", SPBWOSCE 2017 (Санкт-Петербург, 2018 г.);

- международной научной конференции "Energy Management of Municipal Facilities and Sustainable Energy Technologies EMMFT 2018" (Воронеж, Самара, 2018 г.);

- международной научной конференции "Digital Transformation on Manufacturing, Infrastructure and Service" (Санкт-Петербург, 2019 г.);

- 1-м международном воркшопе "Software Engineering Research & Practices for the Internet of Things (SERP4IoT) (Монреаль, 2019);

- 33-й международной конференции IBIMA Education Excellence and Innovation Management through Vision 2020 (Гранада, 2019 г.);

- всероссийской научной и учебно-практической онлайн конференция «Фундаментальные и прикладные исследования в области управления, экономики и торговли» (Санкт-Петербург, 2020 г.).

Практическая апробация работы реализована в консалтинговой ИТ-компании Санкт-Петербурга.

Публикации. Основные результаты диссертационного исследования изложены в 19 научных публикациях общим объемом 15,36 п.л., в том числе 8 работ объемом 5,2 п.л. опубликованы в журналах, входящих в перечень ВАК при Минобрнауки РФ.

ГЛАВА 1. ИНЖИНИРИНГ ТРЕБОВАНИЙ ИНФОРМАЦИОННО-ТЕХНОЛОГИЧЕСКОЙ ПОДДЕРЖКИ 1.1. Исследования в области инжиниринга требований

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

Существуют различные определения термина «требование», подчеркивающие его различные аспекты.

Харвелл определил требование как утверждение, которое предписывает, чтобы что-то было выполнено, преобразовано, произведено или предоставлено [1]. В статье Габба под требованием понимается выражение предполагаемой потребности в том, чтобы что-то было достигнуто или реализовано [2]. В стандарте IEEE 1220-1998 дано следующее определение термина «требование»: требование - это утверждение, которое идентифицирует эксплуатационные, функциональные параметры, характеристики или ограничения проектирования продукта или процесса, являющееся недвусмысленным, проверяемым и измеримым; оно необходимо для приемки продукта или процесса (потребителем или внутренним руководящим принципом обеспечения качества) [3].

Стандарт IEEE 610.12-1990 [4] определяет термин «требование» следующим образом:

(1) Условие или возможности, необходимые пользователю для решения проблемы или достижения цели,

(2) Условие или возможности, которые должны выполняться или которыми должна обладать система или системные компоненты для удовлетворения контракта, стандарта, спецификации или других формально наложенных документов.

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

Вопросы требований к программному обеспечению являются исследовательским направлением на протяжении более чем 25 лет. На ранних этапах становления данного исследовательского направления пришло понимание, что в реальных проектах довольно часто возникает неполное, непоследовательное или двусмысленное определение требований, что в конечном счете критическим образом сказывается на качестве итогового программного продукта. Данный феномен был замечен в отношении различных типов проектов. В связи с этим, в одном из ранних исследований было сформулировано основополагающее утверждение: «Требования не должны возникать сами по себе; вместо этого их следует создавать с помощью инженерного подхода» [2]. Отсюда и возник термин «инжиниринг требований».

Этот термин достаточно быстро стал использоваться в различных исследованиях. Боэм оценил, что поздняя корректировка ошибок в требованиях может стоить в 200 раз больше, чем корректировка в процессе непосредственно инжиниринга требований [5]. В другом классическом исследовании о сущности и проблемах программной инженерии, Брукс утверждал, что «самая сложная часть в создании программного обеспечения -это процесс принятия решения о том, что нужно создать. Поэтому самая важная функция, которую разработчик программного обеспечения выполняет для клиента, - это итерационное формирование и уточнение требований к продукту» [6].

Более поздние исследования подтвердили, что в области инжиниринга требований существуют серьезные проблемы и задачи, которые требуют решения. Например, изучение более чем 8000 проектов среди 350 компаний

показало, что треть проектов не была завершена вовсе, а половина оставшихся могли считаться успешно завершенными только частично (частично реализованная функциональность, превышение запланированных затрат и срывы сроков) [7]. Анализ показал, что большая часть факторов, повлиявших на такую статистику, связана именно с требованиями. К таким факторам относятся: недостаточность вовлеченности пользователей (13%), незавершенность требований (12%), изменения требований (11%), не реалистичность ожиданий (6%), неоднозначность целей (5%) [8]. В другом аналогичном исследовании, в котором приняло участие более 3800 организаций, результат был похожим - большая часть проблем в проектах связана именно со спецификацией требований и с управлением требованиями.

В 1990-х годах Standish Group проводила серию обзоров проектов разработки программного обеспечения в США, анализируя показатели отказов от проектов до их завершения и определяя критические факторы успеха. Первое исследование, проведенное в 1994 году, показало, что только 16% проектов были успешными [9]. При этом успешным проектом считался тот, который был завершен вовремя и в рамках бюджета, и в котором были учтены и реализованы все изначально указанные требования и функции. Следует отметить, что подобное определение успеха проекта является довольно строгим, поскольку многие проекты могут реализовать полезный продукт, даже если при этом не были соблюдены установленные сроки и рамки бюджета, а некоторые требования разрабатывались непосредственно в процессе создания программного обеспечения. Такие проекты были отнесены в так называемую «проблемную» категорию, и их доля составила 53%. Однако анализ показал, что перерасход финансовых и временных затрат был невелик - среди «проблемных» проектов произошло превышение расходов на 189% и перерасход времени на 222% [10]. Наконец, 31% пришелся на проекты, которые были полностью отменены до завершения. С учетом этих данных Standish Group спрогнозировала, что затраты американских компаний и правительственных агентств на отмененные проекты в 1995 году составят

около 81 млрд долларов. В следующем исследовании, проведенном в 1998 году, было зафиксировано небольшое улучшение: доля успешных проектов выросла с 16% до 26%, хотя доля отмененных проектов почти не изменилась и составила 28%. Вместе с тем произошло резкое сокращение среднего размера перерасхода финансовых и временных затрат для проектов в «проблемной» категории.

Одной из ключевых составляющих этого исследования были предложенные перечни факторов успеха и неудачи проектов.

Согласно оценкам респондентов, полученным при анализе причин успешных или неудачных исходов проектов, были определены три главных фактора успеха:

• активное участие пользователей;

• поддержка исполнительного руководства;

• четкое изложение требований [8].

В свою очередь тремя главными факторами, приводящими к провалу, были названы:

• недостаточная вовлеченность пользователей;

• неполные требования и спецификации;

• изменение требований и спецификаций.

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

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

Таблица 1.1.1 - Связь между требованиями и успехом проекта

№ п/п Утверждение Ссылка

1. «Проект соответствует всем требованиям к спецификации» в качестве внутренних критериев измерения успеха [11]

2. 12 основ инжиниринга требований для успешной реализации проекта [9]

3. «Функциональные требования, требования к производительности и надежности не документируются» как фактор провала проекта [12]

4. «Соответствие всем требования» как мера успеха проекта [13]

5. Требования как «Успех продукта» [14]

6. «Соответствовать требованиям пользователей» как критерий успеха проекта [15]

7. Соответствие требований как ключевой аспект качества, которое является составляющей успеха проекта [10]

Интерес к области разработки требований начал постепенно появляться вместе с развитием сферы разработки программного обеспечения. Дело в том,

что на заре развития области разработки программного обеспечения, примерно с 1960-х до 1980-х годов, многие программные продукты, используемые организациями, практически целиком создавались самими организациями [16]. В таких проектах зачастую возникали серьезные проблемы: программные продукты часто поставлялись не вовремя, а проекты выходили за рамки установленного бюджета. Кроме того, пользователи таких систем зачастую не хотели их использовать, так как они не отвечали их потребностям и ожиданиям [17]. Рост числа подобных проблем стимулировал развитие интереса к роли требований в процессе разработки программных продуктов, поскольку начало формироваться осознание того, что ошибки на этапе определения требований приводят росту затрат на обслуживание программных продуктов или даже к полному отказу от их использования.

Исторически термин «программная инженерия» появился, когда стало очевидно, что инженерный подход к созданию программного обеспечения необходим [4]. Впоследствии сложилось понимание, что, если к разработке программного обеспечения нужно подходить с инженерной точки зрения, то и к отдельным этапам внутри него также следует применять данный подход [18]. В результате появился термин «инжиниринг требований», который был принят для описания инженерного подхода к ранним стадиям создания программного обеспечения. Термин вошел в широкое употребление в конце 1990-х годов, когда было опубликовано учебное пособие IEEE Computer Society, а также была проведена серия конференций, посвященных инжинирингу требований, которая дала начало ежегодной Международной конференции по инжинирингу требований (International Requirements Engineering Conference) [17].

При этом считается, что началом инжиниринга требований как отдельной дисциплины стала работа Росса и Шомана [19]. В их исследовании была не только всесторонне описана сама дисциплина и ее фокус, но также были предложены цели, точки зрения и другие элементы для инжиниринга требований [20].

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

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

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

• проблемы, которые должны быть решены: барьеры при коммуникации, незавершенность требований, несогласованность требований;

• способы решения проблем: формальный язык и алгоритмы анализа, прототипирование, метрики, прослеживаемость требований;

• методы накопления знаний: описание текущих практик, учебные кейсы, контролируемые эксперименты;

• типы систем: встроенные системы, критически важные системы безопасности, распределенные системы [21].

Ченг и Атли предположили, что успешный инжиниринг требований включает следующие аспекты:

• понимание потребностей пользователей, клиентов и других заинтересованных сторон;

• понимание контекста, в котором разрабатывается программный продукт;

• моделирование, анализ, согласование и документирование требований;

• валидацию того, что задокументированные требования соответствуют требованиям, сформулированным в устном виде;

• управление развитием и эволюцией требований [18].

Недостаточное количество информации об имеющихся потребностях

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

Список литературы диссертационного исследования кандидат наук Лепехин Александр Андреевич, 2022 год

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Harwell R. et al. What Is A Requirement? // INCOSE Int. Symp. 1993. Vol. 3, № 1. P. 17-24.

2. Gabb A. et al. Requirements Categorization // INCOSE Int. Symp. 2001. Vol. 11, № 1. P. 1075-1082.

3. IEEE Standard for Application and Management of the Systems Engineering Process // IEEE Std 1220-1998. 1999. P. 1-84.

4. IEEE Standard Glossary of Software Engineering Terminology // IEEE Std 61012-1990. 1990. P. 1-84.

5. Boehm B. Requirements that handle IKIWISI, COTS, and rapid change // Computer. 2000. Vol. 33, № 7. P. 99-102.

6. Brooks F.P. The mythical man-month. Addison-Wesley Reading, MA, 1975.

7. Hastie S., Wojewoda S. Standish Group 2015 Chaos Report-Q&A with Jennifer Lynch // Retrieved. 2015. Vol. 1, № 15. P. 2016.

8. Johnson J., others. The chaos report // Standishgroup Com. 1994.

9. Young R.R. Twelve requirements basics for project success // CrossTalk J. Def. Softw. Eng. 2006. Vol. 19, № 12. P. 4-8.

10. Dalcher D. Software project success: moving beyond failure // Eur. J. Inform. Prof. 2009. Vol. 10, № 1. P. 42-50.

11. Patanakul P., Iewwongcharoen B., Milosevic D. An empirical study on the use of project management tools and techniques across project life-cycle and their impact on project success // J. Gen. Manag. 2010. Vol. 35, № 3. P. 41-65.

12. Kappelman L.A., McKeeman R., Zhang L. Early warning signs of IT project failure: The dominant dozen // Inf. Syst. Manag. 2006. Vol. 23, № 4. P. 31-36.

13. DeLone W. et al. Bridging global boundaries for IS project success // System Sciences, 2005. HICSS'05. Proceedings of the 38th Annual Hawaii International Conference on. IEEE, 2005. P. 48b-48b.

14. Bannerman P.L. Defining project success: a multilevel framework // Proceedings of the Project Management Institute Research Conference. Citeseer, 2008. P. 1-14.

15. Müller R., Turner R. The influence of project managers on project success criteria and project success by type of project // Eur. Manag. J. 2007. Vol. 25, № 4. P. 298-309.

16. Agüero U., Sasgupta S. A plausibility-driven approach to computer architecture design // Commun. ACM. 1987. Vol. 30, № 11. P. 922-932.

17. Bell T.E., Thayer T.A. Software requirements: Are they really a problem? // Proceedings of the 2nd international conference on Software engineering. Washington, DC, USA: IEEE Computer Society Press, 1976. P. 61-68.

18. Cheng B.H.C., Atlee J.M. Research Directions in Requirements Engineering // Future of Software Engineering (FOSE '07). IEEE, 2007. P. 285-303.

19. Ross D.T., Schoman K.E. Structured Analysis for Requirements Definition // IEEE Trans. Softw. Eng. 1977. Vol. SE-3, № 1. P. 6-15.

20. van Lamsweerde A., Axel. Requirements engineering in the year 00 // Proceedings of the 22nd international conference on Software engineering -ICSE '00. New York, New York, USA: ACM Press, 2000. P. 5-19.

21. Zave P., Pamela. Classification of research efforts in requirements engineering // ACM Comput. Surv. ACM, 1997. Vol. 29, № 4. P. 315-321.

22. Ilin I.V., Frolov K.V., Lepekhin A.A. From Business processes model of the company to software development: MDA business extension // Proceedings Of The 29th International Business Information Management Association Conference - Education Excellence And Innovation Management Through Vision 2020: From Regional Development Sustainability To Global Economic Growth. 2017. P. 1157-1164.

23. Ryan K. The role of natural language in requirements engineering // [1993] Proceedings of the IEEE International Symposium on Requirements Engineering. 1993. P. 240-242.

24. Juan Li et al. Preliminary results of a systematic review on requirements evolution // 16th International Conference on Evaluation Assessment in Software Engineering (EASE 2012). 2012. P. 12-21.

25. Борреманс А.Д. et al. Разработка требований к системе управления медицинской организации в условиях цифровой трансформации // Наука И Бизнес Пути Развития. 2019. № 8 (98). P. 92-96.

26. Лепехин А.А., Борреманс А.Д. Анализ инжиниринга требований к информационно-технологической поддержке с точки зрения теории сложности // Наука И Бизнес Пути Развития. 2018. № 11 (89). P. 66-69.

27. Robinson W.N., Vlas R.E. Requirements Evolution and Project Success: An Analysis of SourceForge Projects. // AMCIS. Association for Information Systems, 2015.

28. Zowghi D., Coulin C. Requirements Elicitation: A Survey of Techniques, Approaches, and Tools // Engineering and Managing Software Requirements / ed. Aurum A., Wohlin C. Berlin, Heidelberg: Springer, 2005. P. 19-46.

29. Robertson S., Robertson J. Mastering the Requirements Process: Getting Requirements Right. Addison-Wesley, 2012. 579 p.

30. Ильин И.В., Левина А.И., Лепехин А.А. Подход к управлению проектом внедрения ERP-системы, основанный на концепции сквозных бизнес-процессов // Перспективы Науки. 2017. № 2 (89). P. 26-31.

31. Katina P.F., Keating C.B., Jaradat R.M. System requirements engineering in complex situations // Requir. Eng. 2014. Vol. 19, № 1. P. 45-62.

32. Snowden D.J., Boone M.E. A leader's framework for decision making // Harv. Bus. Rev. 2007. Vol. 85, № 11. P. 68.

33. Holland J. Complexity: the emerging science at the edge of order and chaos. Harmondsworth, England: Penguin, 1994.

34. Ilin I.V., Levina A.I., Lepekhin A.A. The complexity of requirements engineering approach as a potential critical-success factor of software project // Proceedings Of The 30th International Business Information Management Association Conference, Ibima 2017 - Vision 2020: Sustainable Economic

Development, Innovation Management, And Global Growth. 2017. P. 25782590.

35. Christoph A.J., Konrad S. Project complexity as an influence factor on the balance of costs and benefits in project management maturity modeling // Procedia-Soc. Behav. Sci. 2014. Vol. 119. P. 162-171.

36. Kutz M. What Is Contextual Intelligence? // Contextual Intelligence. Springer, 2017. P. 9-20.

37. Fitsilis P. Measuring the Complexity of Software Projects. IEEE, 2009. P. 644648.

38. Williams T. Assessing and Moving on From the Dominant Project Management Discourse in the Light of Project Overruns // IEEE Trans. Eng. Manag. 2005. Vol. 52, № 4. P. 497-508.

39. Krasner H. Requirements Dynamics in Large Software Projects: A Perspective on New Directions in Software Engineering Process. 1989. P. 211-216.

40. Araujo A.R., França C., de Moura H.P. Complexity Within Software Development Projects: an Exploratory Overview. // Gest. Org Rev. Eletrônica Gest. Organ. 2015. Vol. 13.

41. Turner J.R., Cochrane R.A. Goals-and-methods matrix: coping with projects with ill defined goals and/or methods of achieving them // Int. J. Proj. Manag. 1993. Vol. 11, № 2. P. 93-102.

42. Hasan H., Kazlauskas A. Making sense of IS with the Cynefin framework // PACIS 2009 Proc. 2009. P. 47.

43. Jarke M., Lyytinen K. Editorial: "Complexity of Systems Evolution: Requirements Engineering Perspective" // ACM Trans. Manag. Inf. Syst. 2015. Vol. 5, № 3. P. 1-7.

44. Fernandez D.J., Fernandez J.D. Agile Project Management —Agilism versus Traditional Approaches // J. Comput. Inf. Syst. 2008. Vol. 49, № 2. P. 10-17.

45. Ilin I. et al. Analysis of Factors, Defining Software Development Approach // International Scientific Conference Energy Management of Municipal Transportation Facilities and Transport EMMFT 2017 / ed. Murgul V., Popovic Z. Cham: Springer International Publishing, 2018. P. 1306-1314.

46. Wysocki R. Effective Software Project Management . Hoboken. Wiley Publishing, Inc, 2006.

47. Paetsch F., Eberlein A., Maurer F. Requirements engineering and agile software development // WET ICE 2003. Proceedings. Twelfth IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, 2003. 2003. P. 308-313.

48. Cao L., Ramesh B. Agile Requirements Engineering Practices: An Empirical Study // IEEE Softw. 2008. Vol. 25, № 1. P. 60-67.

49. Pandey D., Suman U., Ramani A.K. An Effective Requirement Engineering Process Model for Software Development and Requirements Management // 2010 International Conference on Advances in Recent Technologies in Communication and Computing. 2010. P. 287-291.

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

Shahin A. et al. Typology of Kano models: a critical review of literature and proposition of a revised model // Int. J. Qual. Reliab. Manag. Emerald Group Publishing Limited, 2013. Vol. 30, № 3. P. 341-358. Leffingwell D., Widrig D. Managing Software Requirements: A Unified Approach. Addison-Wesley Professional, 2000. 532 p.

Lauesen S. Software Requirements: Styles and Techniques. Pearson Education, 2002.618 p.

Gilb T. Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. Elsevier, 2005. 497 p.

Blanchard B.S. System Engineering Management. John Wiley & Sons, 2004. 514 p.

Jarke M., Pohl K. Requirements engineering in 2001: (virtually) managing a changing reality // Softw. Eng. J. IET Digital Library, 1994. Vol. 9, № 6. P. 257-266.

Potts C., Takahashi K., Anton A.I. Inquiry-based requirements analysis // IEEE Softw. 1994. Vol. 11, № 2. P. 21-32.

Damian D.E.H. Challenges in Requirements Engineering. University of Calgary, 2000.

IEEE Guide for Software Requirements Specifications // IEEE Std 830-1984. 1984. P. 1-26.

Macaulay L.A. Requirements Engineering. London: Springer-Verlag, 1996. Chatzoglou P.D., Macaulay L.A. Requirements capture and analysis: the project manager's dilemma // Int. J. Comput. Appl. Technol. Inderscience Publishers, 1995. Vol. 8, № 3-4. P. 190-202.

IEEE Recommended Practice for Architectural Description for SoftwareIntensive Systems // IEEE Std 1471-2000. 2000. P. 1-30. Lankhorst M.M. Introduction to Enterprise Architecture // Enterprise Architecture at Work: Modelling, Communication and Analysis / ed. Lankhorst M. Berlin, Heidelberg: Springer, 2017. P. 1-10.

Definition of Enterprise Architecture (EA) - Gartner Information Technology Glossary [Electronic resource] // Gartner. URL:

https://www.gartner.com/en/information-technology/glossary/enterprise-architecture-ea (accessed: 26.01.2021).

Classic Topics - Enterprise Architecture | MIT CISR [Electronic resource]. URL: https://cisr.mit.edu/content/classic-topics-enterprise-architecture (accessed: 26.01.2021).

Дубгорн А.С., Левина А.И., Лепехин А.А. Референтная модель функциональной структуры медицинской организации // Журнал Исследований По Управлению. 2019. Vol. 5, № 1. P. 29-36. Lepekhin A.A. et al. Digitalization of Seaports based on Enterprise Architecture approach // IOP Conf. Ser. Mater. Sci. Eng. IOP Publishing, 2020. Vol. 940. P. 012023.

67

68

69

70

71

72

73

74

75

76

77

78

79

80

Levina A.I. et al. The evolution of Enterprise Architecture in scopes of digital transformation // IOP Conf. Ser. Mater. Sci. Eng. IOP Publishing, 2020. Vol. 940. P. 012019.

Maydanova S., Ilin I., Lepekhin A. Capabilities evaluation in an enterprise architecture context for digital transformation of seaports network // Proceedings of the 33rd International Business Information Management Association Conference, IBIMA 2019: Education Excellence and Innovation Management through Vision 2020. 2019. P. 5103-5111. Лепехин А.А., Ильин И.В., Дубгорн А.С. Применение архитектурного подхода в проектах внедрения информационных систем // НЕДЕЛЯ НАУКИ СПБПУ. Материалы научной конференции с международным участием. Санкт-Петербург: Федеральное государственное автономное образовательное учреждение высшего образования "Санкт-Петербургский политехнический университет Петра Великого," 2015. P. 193-195. Kotusev S. The History of Enterprise Architecture: An Evidence-Based Review // J. Enterp. Archit. 2016. Vol. 12. P. 29-37.

Greefhorst D., Proper E. Architecture Principles: The Cornerstones of Enterprise Architecture. Springer Science & Business Media, 2011. 204 p. Zachman J.A. A framework for information systems architecture // IBM Syst. J. 1987. Vol. 26, № 3. P. 276-292.

Sowa J.F., Zachman J.A. Extending and formalizing the framework for information systems architecture // IBM Syst. J. 1992. Vol. 31, № 3. P. 590616.

Richardson G.L., Jackson B.M., Dickson G.W. A Principles-Based Enterprise Architecture: Lessons from Texaco and Star Enterprise // MIS Q. Management Information Systems Research Center, University of Minnesota, 1990. Vol. 14, № 4. P. 385-403.

Spewak S.H., Hill S.C. Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology. QED Publishing Group, 1993.386 p.

Perks C., Beveridge T. Guide to Enterprise IT Architecture. Springer Science & Business Media, 2007. 472 p.

Lankhorst M.M., Quartel D.A.C., Steen M.W.A. Architecture-Based IT Portfolio Valuation // Practice-Driven Research on Enterprise Transformation / ed. Harmsen F. et al. Berlin, Heidelberg: Springer, 2010. P. 78-106. Anisiforov A., Dubgorn A., Lepekhin A. Organizational and economic changes in the development of enterprise architecture // E3S Web Conf. EDP Sciences, 2019. Vol. 110. P. 02051.

Shah H., Kourdi M.E. Frameworks for Enterprise Architecture // IT Prof. 2007. Vol. 9, № 5. P. 36-41.

Jonkers H. et al. Towards a language for coherent enterprise architecture descriptions // Seventh IEEE International Enterprise Distributed Object Computing Conference, 2003. Proceedings. 2003. P. 28-37.

81. Синельников М.А., Лепехин А.А. Проектирование ИТ-инфраструктуры производственного предприятия и разработка плана реализации задач диджитализации // ФУНДАМЕНТАЛЬНЫЕ И ПРИКЛАДНЫЕ ИССЛЕДОВАНИЯ В ОБЛАСТИ УПРАВЛЕНИЯ, ЭКОНОМИКИ И ТОРГОВЛИ. Сборник трудов научно-практической и учебной конференции. Санкт-Петербург: Федеральное государственное автономное образовательное учреждение высшего образования "Санкт-Петербургский политехнический университет Петра Великого," 2018. P. 81-88.

82. Ilin I. et al. Business Requirements to the IT Architecture: A Case of a Healthcare Organization // International Scientific Conference Energy Management of Municipal Facilities and Sustainable Energy Technologies EMMFT 2018 / ed. Murgul V., Pasetti M. Cham: Springer International Publishing, 2019. P. 287-294.

83. Ильяшенко О.Ю., Ильин И.В., Лепехин А.А. Инновационное развитие ИТ-архитектуры предприятия посредством внедрения системы бизнес-аналитики // Наука И Бизнес Пути Развития. 2017. № 8 (74). P. 59-66.

84. Kaplan R., Norton D. The Balanced Scorecard: measures that drive performance // Harv. Bus. Rev. 2005. Vol. 83. P. 172.

85. Paredes-Gualtor J., Moscoso-Zea O., Lujan-Mora S. The Role of Enterprise Architecture as a Management Tool // 2018 International Conference on Information Systems and Computer Science (INCISCOS). 2018. P. 306-311.

86. Haes S.D. et al. Enterprise Governance of Information Technology: Achieving Alignment and Value in Digital Organizations. Springer Nature, 2019. 217 p.

87. What is ITIL | IT service management [Electronic resource] // AXELOS. URL: https://www.axelos.com/best-practice-solutions/itil/what-is-itil (accessed: 23.01.2021).

88. Shang S.S.C., Lin S.-F. Understanding the effectiveness of Capability Maturity Model Integration by examining the knowledge management of software development processes // Total Qual. Manag. Bus. Excell. Routledge, 2009. Vol. 20, № 5. P. 509-521.

89. Kalyazina S. et al. Application of prototyping for the development of a recommendation system for analysis and replenishment of inventory balances // Proceedings of the 33rd International Business Information Management Association Conference, IBIMA 2019: Education Excellence and Innovation Management through Vision 2020. 2019. P. 9706-9711.

90. Левина А.И., Борреманс А.Д., Лепехин А.А. Функционально-ориентированное проектирование информационных систем инфраструктурно-емких предприятий // Перспективы Науки. 2018. № 11 (110). P. 35-39.

91. Власов М.П., Лепехин А.А., Дубгорн А.С. Разработка функциональной модели системы управления цепочками поставок на производственном предприятии // Наука И Бизнес Пути Развития. 2018. № 12 (90). P. 41-44.

92. Ильин И.В. et al. Формирование проекта по интеграции технологий обработки больших данных в архитектуру предприятия // НЕДЕЛЯ НАУКИ СПБПУ Материалы научного форума с международным участием. Междисциплинарные секции и пленарные заседания институтов. Санкт-Петербург: Федеральное государственное автономное образовательное учреждение высшего образования "Санкт-Петербургский политехнический университет Петра Великого," 2015. P. 92-102.

93. Josey A. TOGAF® Version 9.1 - A Pocket Guide. Van Haren, 2016. 161 p.

94. Kotusev S. TOGAF-based Enterprise Architecture Practice: An Exploratory Case Study // Commun. Assoc. Inf. Syst. 2018. Vol. 43. P. 321-359.

95. ISO/IEC/IEEE 42010:2011 [Electronic resource] // ISO. URL: https://www.iso.org/cms/render/live/en/sites/isoorg/contents/data/standard/05/0 5/50508.html (accessed: 24.01.2021).

96. Нефедова Л.А. et al. Разработка моделей бизнес-процессов систем НИОКР для применения аддитивных технологий // Наука И Бизнес Пути Развития. 2019. № 6 (96). P. 72-76.

97. ArchiMate® Specification | The Open Group Website [Electronic resource]. URL: https://www.opengroup.org/archimate-home (accessed: 08.02.2021).

98. Josey A. ArchiMate® 3.0.1 - A Pocket Guide. Van Haren, 2017. 127 p.

99. ArchiMate® 3.1 Specification [Electronic resource]. URL: https://pubs.opengroup.org/architecture/archimate3-doc/chap03.html (accessed: 08.02.2021).

100. Josey A. et al. An Introduction to the ArchiMate® 3.0 Specification. P. 20.

101. Работа в Санкт-Петербурге, поиск персонала и публикация вакансий -spb.hh.ru [Electronic resource]. URL: https://spb.hh.ru/search/vacancy (accessed: 07.02.2021).

102. Кочерышкина Э.Г., Гарифуллин Р.Ф. Основной функционал корпоративного портала. 2017. P. 246-249.

103. EIP: Выбор и внедрение [Electronic resource] // TAdviser.ru. URL: /index.php/Статья:EIP:_Выбор_и_внедрение (accessed: 12.02.2021).

104. Дорожная карта внедрения корпоративного портала Битрикс24 в крупной компании. Цели, стадии, место в инфраструктуре [Electronic resource]. URL: https://habr.com/ru/post/518688/ (accessed: 12.02.2021).