Модели и алгоритмы управления процессом разработки программного обеспечения информационных систем тема диссертации и автореферата по ВАК РФ 05.13.11, кандидат наук Голосовский Михаил Сергеевич

• Голосовский Михаил Сергеевич
• кандидат наук
• 2019

Оглавление диссертации кандидат наук Голосовский Михаил Сергеевич

ВВЕДЕНИЕ

ГЛАВА 1. АНАЛИЗ СОСТОЯНИЯ ТЕОРИИ И ПРАКТИКИ УПРАВЛЕНИЯ ПРОЦЕССОМ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

1.1 Определение процесса разработки ПО информационных систем назначения

1.2 Современное состояние отрасли по разработке ПО

1.3 Ретроспективный анализ моделей процесса разработки программного обеспечения

1.4 Обоснование облика технологической проблемы

1.4.1 Обзор моделей и алгоритмов оценивания трудоёмкости и сроков разработки ПО на начальных этапах жизненного цикла проекта

1.4.2 Обзор моделей поддержки принятия решения при оценивании сроков разработки ПО в процессе разработки ПО

1.4.3 Обзор алгоритмов автоматизированного выявления связей между элементами проекта разработки ПО

1.4.4 Обобщённый алгоритм управления процессом разработки ПО

1.5 Выводы по главе 1 и постановка задачи исследования

ГЛАВА 2. МОДЕЛИ И АЛГОРИТМЫ УПРАВЛЕНИЯ ПРОЦЕССОМ

РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

2.1 Функциональная модель обобщённого жизненного цикла ПО

2.2 Имитационная модель обобщённого жизненного цикла ПО

2.3 Модель расчета предварительной оценки трудоёмкости и срока разработки ПО на начальных этапах жизненного цикла проекта

2.4 Алгоритм калибровки модели предварительной оценки трудоёмкости и сроков разработки информационных систем на начальных этапах жизненного цикла проекта

2.5 Комплекс алгоритмов автоматизированного расчёта потребного объема повторного тестирования ПО после внесенных изменений на основе автоматизировано выявленных связей между элементами проекта разработки ПО

2.4.1 Исходные данные для выполнения трассировки

2.4.2 Алгоритм приведения графа связности артефактов ПО к виду леса деревьев

2.4.3 Алгоритм приведения деревьев к максимальной высоте

2.4.4 Алгоритм вычисления связей между требованиями для текущей ревизии (версии) ПО и ветки репозитория системы контроля его версий

2.4.5 Алгоритм отбора требований для повторного тестирования ПО

2.4.6 Пример применения алгоритма определения силы связей между артефактами системы

2.6 Модель поддержки принятия решений при оценивании сроков разработки ПО с адаптивной подстройкой на основе статистической и экспертной информации

2.7 Выводы по главе

ГЛАВА 3. АЛГОРИТМ ЛОКАЛЬНОЙ НАСТРОЙКИ СИСТЕМ

НЕЧЁТКОГО ЛОГИЧЕСКОГО ВЫВОДА ТИПА МАМДАНИ С СОХРАНЕНИЕМ ИНТЕРПРЕТАБЕЛЬНОСТИ ПРОДУКЦИОННЫХ ПРАВИЛ

3.1 Исходные данные для построения алгоритма локальной настройки систем нечёткого логического вывода типа Мамдани

3.2 Прямое и обратное приведение систем типа Мамдани к системам типа Сугено

3.3 Точная локальная подстройка системы нечёткого логического вывода типа Сугено

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

3.5 Выводы по главе

ГЛАВА 4. ФОРМИРОВАНИЕ СТРУКТУРЫ СИСТЕМЫ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЯ В ПРОЦЕССАХ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ И ОЦЕНКА ЭФФЕКТИВНОСТИ ПРЕДЛОЖЕННЫХ РЕШЕНИЙ

4.2 Структура системы поддержки принятия решения

4.1 Сравнение результатов применения модели оценки трудоёмкости и

сроков разработки информационных систем на начальных этапах жизненного цикла проекта с моделью COCOCMO II

4.3 Проверка эффективности предложенных решений в реальных проектах

ЗАКЛЮЧЕНИЕ

СПИСОК ЛИТЕРАТУРЫ

ВВЕДЕНИЕ

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

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

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

- структура данных претерпевает изменения в процессе развития системы и изменения предметной области в целях сохранения новых объемов данных без искажения данных, уже хранящиеся в системе;

- большие объёмы хранимых и обрабатываемых данных;

- десятки и сотни пользователей, одновременно модифицирующих данные в информационной системе;

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

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

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

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

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

- ошибки выбора модели процесса разработки ПО;

- ошибки оценивания сроков и трудоёмкостей проекта на начальных стадиях проекта (формирование недостижимых целей);

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

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

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

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

В настоящее время методы и технологии поддержки принятия управленческих решений при разработке ПО получили новый импульс развития, обусловленный появлением гибких методологий разработки ПО (Т.Демарко [15, 72], Т.Листер [15, 72], К.Вигерс [56], А.Кокберн [10, 11], С.Макконел [95], Г.Н.Калянов [79], В.В.Липаев [89, 90, 91, 92, 93], А.М.Вендров [51, 52], А.А.Демирский [73], Ю.М.Мадорская [94] и др.).

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

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

Для достижения цели потребовалось решить задачи исследования:

1) разработать функциональную модель обобщённого жизненного цикла ПО;

2) разработать имитационную модель обобщённого жизненного цикла ПО;

3) разработать модель расчета предварительной оценки трудоёмкости и срока разработки ПО на начальных этапах жизненного цикла проекта;

4) разработать комплекс алгоритмов автоматизированного расчёта потребного объема повторного тестирования ПО после внесенных изменений на основе автоматизировано выявленных связей между элементами проекта разработки ПО;

5) разработать алгоритм поддержки принятия решений при оценивании сроков разработки ПО с адаптивной подстройкой на основе статистической и экспертной информации.

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

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

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

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

На защиту выносятся:

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

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

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

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

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

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

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

Результаты исследований реализованы в ГВМУ Минобороны России, ГосНИИИ военной медицины Минобороны России, ПАО «ММТР-технологии» и при выполнении исследований по гранту РФФИ № 16-06-00486 «Исследование методологических проблем инновационного развития информационных технологий организации».

Апробация работы. Основные положения диссертационной работы докладывались и обсуждались на: VI Международной научно-практической конференции «Интеллектуальные технологии в образовании, экономике и управлении» (Воронеж 2009), XV научно-технической конференции ВКА им. А.Ф.Можайского (Москва, 2010), Х международной научной конференции «Инновационное развитие общества: условия, противоречия, приоритеты» (Москва, 2014), VШ-Х международных научной конференции «Системный анализ в медицине» (Благовещенск, 2014-2016), II Всероссийской научно-практической конференции «Южно-Уральская молодежная школа по математическому моделированию» (Челябинск, 2015).

Публикации. По теме диссертации опубликовано 20 научных работ (8 из которых опубликованы без соавторов), в том числе: 8 - статьи в рецензируемых научных изданиях, рекомендованных ВАК при Минобрнауки России, 2 - статьи в других изданиях, 4 - отчеты о НИР, 2 - сборники трудов конференций, 3 -свидетельства о государственной регистрации программы для ЭВМ.

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

ГЛАВА 1. АНАЛИЗ СОСТОЯНИЯ ТЕОРИИ И ПРАКТИКИ УПРАВЛЕНИЯ ПРОЦЕССОМ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

1.1 Определение процесса разработки ПО информационных систем назначения

Процесс разработки программного обеспечения (ПО) представляет собой комплекс мероприятий по сбору и разработке требований и преобразованию их в программное обеспечение. В работе под понятием требование будет использоваться общее определение требования, данное в своде знаний по программной инженерии третьей версии [19] как свойство, представленное чем-либо, для решения некоторой проблемы реального мира. Более детально, в зависимости от методологии проектирования и обработки требований в организации, возможно деление требований на различные типы (как пример [14, 19, 56, 68]: функциональные требования, не функциональные требования, атрибуты качества, ограничения, бизнес требования и бизнес правила). Процесс разработки ПО, как правило, протекает в условиях трёх основных видов ограничений: ограничения по срокам, ограничения по составу работ, ограничения по имеющимся ресурсам и бюджету. В этом случае, понятие процесса разработки ПО можно считать синонимом термина проект разработки ПО, так как в соответствии с ГОСТ Р 54869—2011 [69] проект - это комплекс взаимосвязанных мероприятий, направленный на создание уникального продукта или услуги в условиях временных и ресурсных ограничений. Некоторые модели разработки ПО допускают возможность разработки ПО без ограничения по времени, так называемые гибкие методологии, но в этом случае временные ограничения накладываются на этапы выполнения работ, в то время как самих этапов может быть большое число. В связи с этим, понятие процесса будем считать более общим, но на практике, в большинстве случаев, требуется получение работающего ПО в заданный промежуток времени, поэтому в дальнейшем будем использовать оба термина как синонимы. Более подробно обзор моделей разработки программного обеспечения приведён в главе

Согласно ГОСТ РВ 51987 информационная система - это

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

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

- структура данных претерпевает изменения в процессе развития системы и изменения предметной области в целях сохранения новых объемов данных без воздействия на старые, уже хранящиеся в системе;

- большие объёмы данных;

- десятки и сотни пользователей, одновременно модифицирующих данные в информационной системе;

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

Определение управления проектом дано в ГОСТ Р 54869-2011 как планирование, организация и контроль трудовых, финансовых и материально-технических ресурсов проекта, направленные на эффективное достижение целей проекта. Где под эффективностью понимается соблюдение проектных ограничений, заданных на этапе планирования проекта [82, 83, 123]. На основании этого определения, управленческое решение лица принимающего решение будет считаться качественным, если оно способствует достижению целей проекта, в области разработки ПО - выпустить работоспособное программное обеспечение (ПО), без нарушения заданных на этапе планирования ограничений.

1.2 Современное состояние отрасли по разработке ПО

В Российской Федерации только в рамках федеральной целевой программы «Информационное общество (2011 - 2020 годы)» запланированный бюджет 88 миллиардов рублей [109]. На основе ежегодного аналитического отчёта Российского не коммерческого партнёрства РУССОФТ [74], объединяющего в себе

разработчиков программного обеспечения, в Росси по состоянию на 2013 год зарегистрировано более 1400 компаний, занимающихся разработкой программного обеспечения и общий объём экспорта программной продукции, составил 4,6 миллиарда долларов. При этом, далеко не все проекты завершаются успешно. Согласно исследованию Standish Group [5, 39] в период с 2003 по 2015 год, успешно завершилось только 6% проектов по разработке программного обеспечения, 42% были завершены неудачно и 52% предоставили недостаточно данных, или имеют выход за рамки бюджета расписания или разработанный продукт не соответствовал требованиям заказчика. Согласно совместному исследованию специалистов консалтингового агентства McKinsey & Company и Оксфордского университета [25], после обследования 5,400 проектов по разработке программного обеспечения, начальный бюджет которых более 15 миллионов долларов установлено, что 17% проектов были на грани срыва, в 45% проектов был превышен запланированный бюджет, 7% проектов завершились позже запланированного, и в 56% проектах содержание проекта не соответствовало запланированному. По статистике за 2000 по 2017 годы собранной на основе анализа различных источников [25, 38, 39, 40, 41, 74, 78], согласно диаграммы, представленной на рисунке 1, уровень успешности завершения программных проектов остаётся примерно постоянным и составляет порядка 30%. Стратегия развития информационного общества в РФ на 2017-2030 годы акцентируется на вопросах развития информационного общества, формирования национальной цифровой экономики, обеспечения национальных интересов и реализации стратегических национальных приоритетов и в частности на развитие критической информационной инфраструктуры в сфере обороны Российской Федерации. Что обусловливает высокую потребность в разработке информационных систем военного назначения. На основании опроса экспертов в области разработки программного обеспечения [6, 25, 78], выделены основные группы факторов, влияющих на процесс разработки ПО, по результатам опроса установлено следующее распределение ответов экспертов: проекты срываются только по техническим причинам - 1%, по причине только организационных

19%, в равной степени и организационных и технических -степени организационные, чем технические - 59%.

21% и в большей

=я Неуспешные

\ Выход за рамки бюджета, сроков, содержания

■ Успешные

2000

Рисунок 1 - Распределение процента успешных и не успешных проектов по разработке программного обеспечения за 2000 - 2015 гг. При этом в части организационных проблем в качестве основных выделены:

- Ошибки выбора соответствующей модели процесса разработки программного обеспечения;

- Ошибки оценки сроков и трудоёмкостей проекта на начальных стадиях проекта (формирование не достижимых целей);

- Ошибки оценки сроков и трудоёмкости работ в ходе выполнения проекта, что приводит к невозможности корректировки плана проекта и нарушению проектных ограничений;

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

1.3 Ретроспективный анализ моделей процесса разработки программного обеспечения

Основные процессы разработки ПО схожи с процессами разработки в других

инженерных областях и состоят из следующих стадий: проектирование, разработка (создание образца изделия), испытания (тестирование), серийное производство, сопровождение. Процесс, начинающийся с момента принятия решения о разработке программного обеспечения, и завершающийся его изъятием из эксплуатации носит название жизненного цикла программного обеспечения [124]. За время развития индустрии разработки программного обучения модели жизненного цикла так же претерпели значительные изменения, в частности появилось большое количество «Легковесных» или Agile методологий, с возможностью «легкого» внесения изменений в структуру разрабатываемых программ [45, 96]. Несмотря на различия, все модели содержат в себе следующие общие стадии:

- Анализ требований;

- Подготовка спецификаций;

- Проектирование;

- Реализация;

- Интеграция;

- Сопровождение;

- Вывод из эксплуатации.

Хронология развития моделей жизненного цикла приведена на рисунке 2. Одной из первых моделей разработки программного обеспечения является водопадная (waterfall) или каскадная модель жизненного цикла. Он так же носит название классического жизненного цикла разработки ПО, отчасти в связи с тем, что эта модель повторяет последовательность действий при разработке инженерных решений в других областях науки и техники. Впервые данный подход как адаптированный для разработки ИТ-продуктов упомянул Герберт Бенингтон (Herbert D. Benington) в своей презентации 29 июня 1956 года на Симпозиуме по передовым методикам для цифровых компьютеров (Symposium on advanced

programming methods for digital computers). Но более формально этот жизненный цикл был описан Уинстоном Ройсом в своей статье в 1970 году [37]. В связи с этим, он считается классическим, и используется в качестве основы для сравнения с другими моделями жизненного цикла ПО.

Рисунок 2 - История развития моделей жизненного цикла ПО.

По классификации, представленной в своде знаний по программной инженерии SWEBOK [19], третья версия которого вышла в 2013 году, модели жизненного цикла разделяются на две категории, линейные и итерационные модели. Исторически, первой в системе разработки была водопадная модель, но, в связи с тем, что в отсутствие полноты требований возникала необходимость в уточнении требований, и внесении дополнительных изменений в проект на стадии реализации или тестирования, были предложены различные итеративные модели, которые по сути, отличаются только количеством итераций, их размером, и действиями выполняемыми при подготовке и завершении каждой итерации [55]. В связи с этим, был выделен класс гибких методологий разработки, в которых размер итераций был сравнительно маленьким (занимал порядка недели, а в некоторых до одного дня). Подобные подходы применяются в основном при разработке программного обеспечения в условиях изменяющихся требований и высокой неопределённости предметной области применяются итеративные и относятся к семейству Agile [1, 3, 10, 24, 81, 108], наиболее известные: экстремальное программирование (XP), Scrum, Kanban, OpenUP, FDD. Основной идеей, лежащей в основе этих процессов, является частая смена итераций с получением на каждой итерации работающего программного образца, пусть и реализующего не весь

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

- В промышленной разработке требуется полный комплект документации на разработанное программное обеспечение, что является противоречием основному принципу гибких процессов разработки: «Работающий программный продукт важнее полной документации» [1];

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

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

В соответствии со стандартами по управлению проектами ISO 21500:2012 и PMBOK v6 оценку сроков выполнения проектов можно представить в виде следующих процессов: планирование содержания проекта и на основе полученного содержания планирование сроков выполнения проекта [115, 124]. Модель взаимодействия этих процессов в нотации IDEF0 представлена на рисунке 3. Декомпозиция процесса планирования содержания выделяет следующие под процессы:

- Сбор требований;

- Определение содержания;

- Формирование иерархической структуры работ.

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

Рисунок 3 - Диаграмма верхнего уровня планирования сроков и содержания

проекта.

Как было описано ранее, возможно как полное выделение сразу всех работ, так и итеративное, в при котором планирование происходит поэтапно [86]. В литературе используется терминология как планирование методом набегающей волны. Диаграмма декомпозиции процесса планирования сроков проекта, приведена на рисунке 4, выделяет следующие под процессы:

- Определение операций;

- Определение последовательности операций;

- Оценка ресурсов операций;

- Оценка длительности операций;

- Разработка расписания.

Рисунок 4- Декомпозиция процесса планирования сроков проекта Диаграмма декомпозиции процесса планирования содержания проекта представлена на рисунке 5. При этом, оценка ресурсов операций и длительности операций в сфере разработки ПО осуществляется на основе экспертной оценки [32, 95].

Рисунок 5- Декомпозиция процесса планирования содержания проекта

В Российской Федерации управление проектами регламентируется стандартом ГОСТ Р 54869—2011 «Проектный менеджмент Требования к управлению проектом». Стандарт устанавливает требования к управлению проектом, и перечисляет список основных процессов, которые должны выполняться в процессе управления проектами и выделены следующие группы процессов: инициации, планирования, организации исполнения, контроля и завершения проекта. Стандарт является общим, и не ориентирован на конкретную область промышленности, в связи с чем, в стандарте делается оговорка, о необходимости адаптации процессов под каждый конкретный проект. Более детально список процессов жизненного цикла ПО и управления проектом по разработке ПО приведен в стандартах: ISO/IEC 15288:2007 Процессы жизненного цикла систем и ГОСТ Р 12207-2010 «Процессы жизненного цикла программных средств» [70], при этом, в указанных стандартах не требуются использования какой-либо конкретной модели жизненного цикла и закладываются общие процессы и стадии характерные для любых типов проектов. Это обуславливает актуальность разработки функциональной и имитационной моделей обобщённого жизненного цикла ПО, позволяющей моделировать различные виды моделей жизненного цикла для их сравнения и обоснования возможностей применения.

1.4 Обоснование облика технологической проблемы

1.4.1 Обзор моделей и алгоритмов оценивания трудоёмкости и сроков разработки ПО на начальных этапах жизненного цикла проекта

Вопросу оценивания трудоёмкости и сроков разработки ПО на начальных

этапах жизненного цикла ПО посвящено большое количество публикаций [50, 89, 100, 8]. Среди наиболее известных алгоритмических методов оценивания выделяют модель COCOMO II (Constructive Cost Model) [7, 30, 121], SLIM - модель (модель Путнэма, Putnam model) [36, 126], COSYMO (Constructive Systems Engineering Cost Model) [42]. Основой для расчета в этих моделях служит экспертная оценка о будущем размере информационной системы, выраженная в числе строк кода или функциональных точек (которые в итоге тоже приводятся к числу строк кода). При этом основная идея, на которой базируются эти модели,

заключается в нелинейности возрастания трудоёмкости разработки системы от её размера.

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

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

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

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

Гибкие процессы разработки информационных систем призваны разрешить неопределённость в оценке сроков и трудоёмкости разработки информационных систем посредством разбиения проекта на мелкие этапы (инкременты/итерации), при этом оценка сроков и трудоёмкости разработки информационных систем производится командой проекта только для отдельно взятого этапа перед его выполнением. В работе [9] показано, что проекты, использующие agile методологии также подвержены недооценке трудоёмкости и сроков. Ещё одним недостатком agile проектов является отсутствие оценки числа итераций, необходимых для завершения проекта, так как согласно agile методологий в конце каждой итерации получается продукт, готовый к использованию. Однако время реализаций проекта теоретически может быть бесконечным.

В работе С. Макконела [95] выделены следующие далее три критерия качественной оценки.

1. Использование расчётных данных в приоритете перед экспертными.

2. Ретроспективные данные конкретной компании приоритетнее отраслевых данных.

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

Одним из фундаментальных алгоритмических методов оценивания, наиболее часто цитируемым в литературе является метод СОСОМО/СОСОМО II, предложенный Барри Боэмом [7] ориентированный на разработку программного обеспечения, и основан на трёх уровнях оценки, уточняющихся по ходу выполнения проекта, при этом основным недостатком его является ориентация на число строк кода разрабатываемого программного обеспечения, что является не состоятельным в условиях развития объектно-ориентированного программирования и развития компонентно-ориентированного подхода в разработке программного обеспечения. В качестве одного из достоинств модели, выделяют наиболее проработанное дерево из 22 факторов, влияющих на проект по разработке программного обеспечения, построенное на основе статистических данных анализа более 160 программных проектов. Дерево факторов согласно модели СОСМО II приведено на рисунке 6. В модели СОСМО II выделены две основные группы факторов: масштабные и влияющие на затраты производства Масштабные факторы дают общую оценку сложности будущей разработки проекта за счет выделения таких факторов как новизна проекта, общие показатели зрелости команды и процессов в компании. Вторая группа факторов объединяет четыре более детальные группы факторов, дающих описание характеристик объекта производства, характеристик коллектива специалистов, описание технической и аппаратно-вычислительных сред производства. В различной литературе [2, 53, 54, 68, 75, 126] технические факторы разбивают на отдельные, более детальные группы. Пример причинно-следственного анализа технических факторов в виде диаграммы Ишикавы представлен на рисунке 7. На диаграмме выделяется набор факторов в виде программных сред и оболочек, применяющихся в разработке. Эта

группа факторов определяется на начальном этапе сбора требований и проектирования ПО.

Новизна проекта

Факторы, влияющие на разработку ПО

Согласованность с

требова ниями и

интерфейсами

Масштабные факторы Управление рисками и архитектурой проекта

Слаженность работы

коллектива

Технологическая

зрелость обеспечения

разрабтки Надежность функционирования

Требования и Размер базы данных

характеристики объекта Сложность функций и

производства структуры

Требования повторного

испол ьзования

компонентов

Пол нота и соответстви е

документации проекта

Квал ифи каци я

аналитиков

Квал ифи каци я

программистов

Характеристики коллектива Стабильность коллектива

специ алистов Опыт работы по тематике

проекта

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

Опыт работы в

инструментальной среде

Факторы, влияющие на Опыт работы с языками

затраты производства программирования

Уровень инструментальной поддержки проекта

Необходи мость

Технологическая среда распределённой

производства поддержки проекта

Ограничения

длительности

производства продукта

Ограничения времени исполнения программ

Аппаратно-вычислительная среда производства Ограничения доступной оперативной памяти

Изменчивость виртуальной среды разраб отки проекта

Рисунок 6 - Дерево факторов, влияющих на процесс разработки ПО согласно

модели СОСМО II

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

Рисунок 7 - Диаграмма Ишикавы технических и организационных факторов, влияющих на разработку программного обеспечения Использование вариации метода COCOMO/COCOMO II в процессе планирования и получения адекватной оценки сроков и трудоёмкости ПО рассмотрено в работе Полицина [107]. В работе рассмотрены методы вероятностного сетевого планирования PERT, метод Монте-Карло, COCOMO/COCOMO II. Метод PERT является наиболее простым и популярным методом при планировании сроков проекта. При этом, его основными недостатками являются зависимость от корректности сетевого графика проекта, низкое качество вероятностных оценок и слабые возможности оперативного реагирования на изменения, возникающие в ходе выполнения проекта. Метод Монте-Карло позволяет смоделировать различные варианты хода выполнения проекта, с учетом заданных распределений вероятностей сроков выполнения каждой отдельно взятой работы. Метод является более точным, чем метод PERT, но требует большой трудоёмкости задания исходных данных для выполнения моделирования. Для разрешения описанных выше недостатков существующих методов в работе предложен метод построения графа задач с согласованными

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

В работе [120] дан обзор различных методологий и методов оценки трудоёмкости новых проектов по разработке ПО. Выделены две основные группы методов: алгоритмические и не алгоритмические. Согласно его исследования, наиболее популярными алгоритмическими методами являются методы COCOMO / COCOMO II (рассмотрена ранее) и SLIM (модель Путнэма), не алгоритмическими экспертные оценки, оценки по аналогии и Oracle AIM (Application Implementation Methodology). Метод, предложенный в работе, является расширением метода оценки по аналогии, основными шагами которого включают: формирование базы выполненных проектов, включающее формирование множеств характеристик для сравнения проектов, и разбиение полученной базы проектов на множества похожих проектов. Мера сходства определяется на основе расстояния между

характеристиками проекта а в, где ai и в - значения i-й характеристики проекта. Проекты считаются похожими, если для заданного экспертами количества

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

недостаткам можно отнести отсутствие инструмента оценки трудоёмкости нового проекта при отсутствии аналогов.

Демирский в своей работе [73] предложил алгоритм построения модели оценки структурной сложности объектов программной системы на основе базы знаний с использованием нечёткой нейронной сети Такаги-Сугенто-Канга, в которой результаты (заключения) правил представляются в виде функциональных зависимостей, а не в форме принадлежности выходной переменной к нечётким множествам. В качестве основы для обучающей выборки предлагается использовать исторические данные, накопленные по предыдущим проектам, а в качестве метрики использовать LOC (Line of Code) оценки (метрика основанная на числе строк кода). Но, основным недостатком работы, является сложность применения метрик основанных на числе строк кода в объектно-ориентированных языках программирования, с возможностью использования специализированных технологий и паттернов проектирования - в значительной мере в таких системах большое число строк кода при сравнительно малой функциональности может являться признаком низкого уровня разработчиков. Так же нейронные сети дают достаточно большую ошибку на небольших обучающих выборках, что ограничивает их использование в задачах прогнозирования сроков разработки программного обеспечения.

Несмотря на то, что моделей и алгоритмов оценивания трудоёмкости и сроков разработки информационных систем на начальных этапах жизненного цикла ПО разработано много, ни одна из них не соответствует одновременно всем перечисленным ниже критериям:

- Оценка даётся в виде интервала - значения верхней и нижней границы;

- Оценка базируется на известных на начальном этапе высокоуровневых требованиях к разрабатываемому ПО и рисках способных повлиять на ход выполнения проекта, а не на предполагаемом размере проекта в виде числа строк кода;

- Модель должна учитывать лингвистическую неопределённость оценок экспертов;

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

1.4.2 Обзор моделей поддержки принятия решения при оценивании сроков разработки ПО в процессе разработки ПО

В проектах, использующих в качестве основы каскадную модель жизненного цикла, лежащую в основе методологий управления проектами, таких как PMBOK [111], ISO 21500:2012, ГОСТ Р 54869—2011, выполнение оценки работ в ходе выполнения проекта не подразумевается - после завершения стадии планирования, пересмотр оценок сроков уже не производится, фактическая трудоёмкость или длительность работы или укладывается в первоначальную оценку или нет. Для проектов с высокой степенью неопределённости в этих стандартных предлагается всю работу разбивать на этапы и проводить планирование методом «набегающей волны», который подразумевает проведение детального планирования непосредственно перед началом выполнения нового этапа. Но при этом в качестве инструментов планирования рекомендуются стандартные инструменты, такие как декомпозиция, экспертная оценка, оценка по аналогии, метод Делфи и др.

В гибких методологиях разработки, основанных на итеративных моделях разработки ПО детальное планирование производится перед каждой итерацией, при этом в качестве основного метода планирования наибольшую популярность получил метод «Покер планирования» (Planning poker) [34]. Этот метод относится групповым методам экспертной оценки. Суть метода заключается в следующем: Каждому эксперту выдаётся набор карт, содержащих оценки задач в виде последовательности чисел Фибоначи (0, 1/2, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89). При этом оценка даётся не в часах, а в условных единицах: юнитах (Story Points). При оценке каждый из экспертов выкладывает перед собой карту и кладёт её перед собой не значащей стороной вверх (оценка скрыта от других экспертов). После того, как все эксперты сделали оценку, карты переворачиваются, и все видят оценочные

значения. В случае, если есть оценки, значительно отличающиеся от среднего значения, эксперт, давший эту оценку должен дать обоснование, почему указана именно эта оценка. В качестве итоговой может быть принята средняя оценка, а может быть проведено повторение оценки до тех пор, пока оценки экспертов не совпадут, и не будет достигнут консенсус. В ходе выполнения работ, для каждого исполнителя рассчитывается величина производительности (velocity), отражающую количество юнитов (Story Points) реализованных за единицу времени. На основании оценки в Story Points и величины производительности, которая уточняется каждую итерацию производится отбор оцененных задач на итерацию. Недостатком метода является необходимость проведения нескольких итераций (порядка 2-3) для расчёта значения величины производительности (velocity).

В работе Бахиркина [43], так же проведён обзор основных алгоритмических методов оценки трудоёмкости проектов по разработке ПО. В его работе на основании 6 проектов была проведена проверка гипотезы, что распределение ошибки экспертов ближе к логнормальному распределению, чем к бета распределению, используемому при выводе формулы оценки по методу PERT. В связи с чем, в работе продолжена модифицированная формула оценки метода PERT, с использованием которой реализован алгоритм динамической оценки программных систем (ДОПС). В основе которого лежит динамическое вычисление срока выполнения фазы проекта на основе корректировки полученной экспертной оценки с использованием фактора оценки качества первоначального прогноза (Estimating Quality Factor - EQF), предложенного Т. Демарко, как меры отклонения прогнозируемого значения оценки от фактического. При этом, корректировка оценки производится без учёта факторов, влияющих на процесс оценки. Примером фактора может служить размер оцениваемой задачи: большие и трудоёмкие задачи сложнее точно оценить, чем маленькие и простые. В связи с чем, величина ошибки одних и тех же экспертов при различных значениях факторов может значительно отличаться, но в алгоритме ДОПС берётся усреднённое значение, в результате чего, точность алгоритма снижается.

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

1.4.3 Обзор алгоритмов автоматизированного выявления связей между элементами проекта разработки ПО

В качестве основы для оценки сложности изменений ПО в литературе и на практике часто используют оценку величины изменений на основе трассировки требований [27, 56, 80]. В работе К. Вигерса [56] дано определение трассируемости требований как документирование зависимостей и логических связей отдельных требований и других элементов системы. Наиболее востребованными задачами, решаемыми применением трассировки, являются:

1. Получение актуального статуса системы по требованиям;

2. Анализ влияния изменения.

Вигерс рассматривал полную трассировку от требования до исходного кода (функции) программы, но большинство систем управления требованиями поддерживает трассировку до уровня тест кейса или до уровня задачи разработчику на реализацию соответствующего требования. Подобная трассировка позволяет достаточно эффективно решать задачу 1, посредством связей отвечая на вопросы какие требования реализованы и какие требования протестированы, но не всегда эффективно позволяет решать задачу 2, в связи с тем, что между двумя требованиями может существовать связь на уровне программного кода, которая не проставлена на уровне требований, задач или тестовых сценариев. Подробный обзор работ, затрагивающих тему измерения силы влияния изменения проведён в работе [27], на основании которого выделены четыре класса анализа влияния изменений:

1. Использование статического анализа программ основанного на структуре программы и отношении между элементами программы;

2. Использование динамического анализа программ основанного на сборе данных во время выполнения программы;

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

4. Анализ моделей разрабатываемых программ.

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

В работе [94] автором рассмотрены основные инструменты и методы формирования оценки изменений (ФОИ) в ПО основанные на анализе моделей разрабатываемой системы. В качестве основных компонентов, включаемых в современные методы ФОИ выделены:

- Методы описания требований к системе. Основу которых могут составлять различные архитектурные каркасы, методологии разработки ПО, парадигмы проектирования, онтологии, методы анализа и проектирования ПО, парадигмы проектирования;

- Модели трассировки;

- Методы трассировки.

Для возможности использования произвольных методов описания требований в работе предложен метод интеграции описания требований, основанный на предметно-независимой трассировке. Реализация метода использует формализацию описания требования как высказывание о свойствах системы, а правила контроля ошибок представляются в виде высказываний, и их структура задаётся в виде предикатов. В этом случае, возможно использовать методы математической логики для формирования основных понятий, классификации и выявления ошибок. Но использование формального описания требования ограничивает его использование для представления различных уровней и вариантов требований, рассмотренных в работе [56], что ограничивает область

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

Проведённый анализ подтверждает актуальность разработки алгоритма автоматизированного выявления связей между элементами проекта разработки ПО на основе данных из систем контроля версий, но не зависимого от языка программирования.

1.4.4 Обобщённый алгоритм управления процессом разработки ПО

В соответствии с законом необходимого разнообразия У.Р. Эшби

разнообразие системы управления (знание методов решения проблемы) должно быть больше или по крайней мере равно разнообразию (сложности) управляемого объекта. В случае возрастания сложности процесса разработки ПО, в частности за счет появления новых технологий, методов организации процесса разработки ПО (появления гибких методологий разработки ПО), и отсутствия достаточной квалификации у лиц принимающих решения, повышение качества управленческих решений возможно за счёт использования систем и алгоритмов поддержки принятия решений [97, 103, 105, 106].

Выполним постановку задачи управления процессом разработки программного обеспечения информационных систем. Зададим объект Q (Т, S, P, ц), где Q - процесс разработки ПО, Т - время разработки ПО, S - количество требований к ПО (функциональных и не функциональных), Р - ресурсы, затрачиваемые на разработку ПО, ц - управляющие воздействия:

где V - применяемые модели жизненного цикла ПО, г - сложность/удобство среды разработки и выбранного языка программирования и применяемые готовые шаблоны и библиотеки, w - алгоритмы определения надёжности оценки сроков/трудоёмкости выполнения задач по разработке ПО, у - алгоритмы учёта влияния изменений отдельных требований на уже разработанное ПО. Для объекта Q требуется определить управляющее воздействие и чтобы выполнялось условие:

х1 - характеристики процесса разработки ПО ИС в заданный момент времени t:

На рисунке 8 приведен обобщённый алгоритм управления процессом разработки ПО со вспомогательными подпроцессами поддержки принятия решений. На которой выделены основные подпроцессы:

- Подпроцесс 1: Планирование и постановка целей;

- Подпроцесс 2: Реализация ПО;

- Подпроцесс 3: Тестирование и контроль качества;

- Подпроцесс 4: Формирование управляющего воздействия.

В соответствии с проведённым выше анализом, требуется обеспечение поддержки принятия решения в подпроцессах 1, 3, 4, для чего формируются следующие подпроцессы поддержки принятия решений:

- Подпроцесс 5: Выбор модели жизненного цикла разработки ПО;

- Подпроцесс 6: Предварительный расчёт сроков разработки ПО;

где: х0 - целевые характеристики процесса разработки ПО ИС:

- Подпроцесс 7: Оценка величины изменений и отбор тестовых сценариев для выполнения тестирования;

- Подпроцесс 8: Оценка сроков в ходе выполнения процесса разработки ПО.

Рисунок 8 - Общая модель процесса разработки ПО со вспомогательными процессами поддержки принятия решений

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

Для обеспечения функционирования подпроцесса предварительного расчёта сроков разработки ПО требуется разработать модель предварительной оценки срока разработки ПО, обеспечивающей учёт неопределённости в оценках экспертов на начальном этапе проекта. Разрабатываемая модель должна в отличии от известных моделей COCOMO II, SLIM, Монте-Карло, а также предложенных в

работах [107, 120], использовать в качестве входных данных описания высокоуровневых требований проекта, и учитывать неопределённость в мнении экспертов.

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

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

1.5 Выводы по главе 1 и постановка задачи исследования

Современные тенденции в развитии сферы разработки программного

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

1) разработать функциональную модель обобщённого жизненного цикла ПО;

2) разработать имитационную модель обобщённого жизненного цикла ПО;

3) разработать модель расчета предварительной оценки трудоёмкости и срока разработки ПО на начальных этапах жизненного цикла проекта;

4) разработать комплекс алгоритмов автоматизированного расчёта потребного объема повторного тестирования ПО после внесенных изменений на основе автоматизировано выявленных связей между элементами проекта разработки ПО;

5) разработать модель поддержки принятия решений при оценивании сроков разработки ПО с адаптивной подстройкой на основе статистической и экспертной информации.

ГЛАВА 2. МОДЕЛИ И АЛГОРИТМЫ УПРАВЛЕНИЯ ПРОЦЕССОМ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

2.1 Функциональная модель обобщённого жизненного цикла ПО

Перечисленные главе 1.3 модели жизненного цикла по последовательности выполнения процессов ЖЦ и передачи задач от одного процесса другому можно разделить на следующие три основные категории [101, 115]:

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

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

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

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

документации, при этом позволяющую осуществить переключение между моделями ЖЦ ПО в ходе выполнения проекта.

Таблица 1- Сравнение категорий моделей жизненного цикла ПО

Категория Завершение Политика Наличие Соответствующие

ЖЦ всех задач передачи производствен- методологии/

проекта на изменении на ных циклов Модели

одном этапе исполнение разработки ПО.

перед

началом

следующего

Последова- Требуется После завершения Могут Водопадная модель

тельная основной части проекта выделяться крупные этапы

Циклическая Не требуется После завершения Вся разработка Scrum, OpenUP,

текущего ведётся RUP, RAD,

производственного производствен- итеративная модель,

цикла ными циклами спиральная модель.

Конвейерная Не требуется В любое время Производствен- XP, Kanban, Lean,

выполнения ные циклы FDD

проекта отсуствуют

За основу для формирования модели возьмём итеративно-инкрементную модель разработки ПО. Существуют различия между итеративной и инкрементной разработками программного обеспечения [11, 61, 87]. Итеративная разработка подразумевает создание системы (пусть с ограниченным набором функций) и её последующее улучшение в течении нескольких итераций. Достоинством итеративной разработки является получение работающей версии ПО на каждой итерации с возможностью проверки его соответствия требованиям и получения оценки необходимости продолжения дальнейшей работы над программным продуктом. В случае, если необходимо продолжение разработки, то всегда можно выбрать: продолжать работу в текущей итерации или развивать альтернативное направление, в одной из более ранних итераций. В этом кроется один из недостатков итеративного подхода - сложность управления итеративными проектами высока в связи с тем, что не всегда можно предсказать количество итераций, которое может потребоваться для передачи всех заданных на начальном этапе функций ПО в промышленную эксплуатацию.

При инкрементной разработке программный продукт разбивается на несколько законченных функциональных частей, и в рамках каждого инкремента производятся разработка одной функциональной части и её тестирование. Финальным инкрементом является интеграция всех модулей и тестирование всего программного продукта. Достоинством инкрементной стратегии разработки является легкое управление сроками и расписанием процесса разработки за счет разбиения системы на части (количество частей определить проще чем число итераций, и можно отслеживать разработку каждой части системы), а так же возможности применения методики сжатия расписания Fast Tracking (Быстрый проход) [44], заключающейся в параллельном выполнении нескольких инкрементов, за счет привлечения большего количества ресурсов. После инициации разработки ПО разбивается на несколько модулей, которые разрабатываются параллельно, после чего интегрируются в единое целое. Недостатками инкрементной разработки являются [116]:

Список литературы диссертационного исследования кандидат наук Голосовский Михаил Сергеевич, 2019 год

СПИСОК ЛИТЕРАТУРЫ

1. Agile-манифест разработки программного обеспечения [Электронный ресурс] URL: http://agilemanifesto.org/iso/ru/ (дата обращения: 24.08.2018).

2. Basha S., Dhavachelvan P. Analysis of Empirical Software Effort Estimation Models // International Journal of Computer Science and Information Security. -2010. - Vol. 7, - No. 3, - P. 68-77.

3. Beck K. Embracing Change with Extreme Programming // Los Alamitos, CA, USA: Computer 32. - 1999. - №10. - P. 70-77.

4. Beck K. Test Driven Development by Example. ). - Reading: Addison-Wesley Professional, 2002. - 252 p

5. Big Bang Boom. The Standish Group International research CHAOS Tuesday [Электронный ресурс] URL: http://blog.standishgroup.com/BigBangBoom.pdf, (дата обращения: 12.04.2018).

6. Bloch M., Blumberg В., Laartz J. Delivering large-scale IT projects on time, on budget, and on value. [Электронный ресурс] URL: http://www.mckinsey.com/insights/business_technology/delivering_large-scale_it_proj ects_on_time_on_budget_and_on_value, (дата обращения : 12.04.2018).

7. Boehm B. W., Abts C., Brown A. W., Chulani S., Clark B. K., Horowitz E., Madachy R., Reifer D. J., Steece B. Software Cost Estimation with COCOMO II 1st Edition. - New Jersey: Prentice Hall, 2000. - 368 p.

8. Brooks F. No Silver Bullet — Essence and Accidents of Software Engineering // IEEE Computer. - №20. - 1987. - P. 10-19.

9. Cao L, Estimating Agile Software Project Effort: An Empirical Study //The Fourteenth Americas Conference on Information Systems. - 2008. - P. 401-410.

10. Cockburn A. Agile Software Development: The Cooperative Game (Edition 2). -Reading: Addison-Wesley Professional, 2006. - 120 p.

11. Cockburn L. Using Both Incremental and Iterative Development // Cross Talk. -2008. - P. 27-30.

12. Cohn M. Agile Estimating and Planning. - Upper Saddle River: Prentice Hall, 2005. - 368 p.

13. Cohn M. User Stories Applied. For Agile Software Development. - Reading: Addison-Wesley Professional, 2004. - 304 p.

14. Davis A. Just Enough Requirements Management: Where Software Development Meets Marketing. - New York: Dorset House, 2005. - 240 p.

15. DeMarco T. Lister T. Waltzing With Bears: Managing Risk on Software Projects. - New York: Dorset House, 2003. - 207 p.

16. Driankov О., Hellendoorn Н.,. Reinfrank М. An introduction to fuzzy control. -Cham: Springer, 1993. - 326 p.

17

18

19

20

21

22

23

24

25

26

27

28

29

30

Gacto M., Alcala R., Herrera F. Interpretability of linguistic fuzzy rule - based systems: An overview of interpretability measures // Information Sciences. - 2011.

- № 20. - Vol. 181, - P. 4340-4360.

Gang F. Analysis and synthesis of fuzzy control systems: a model-based approach (automation and control engineering). - Boca Raton: CRC Press, 2017. - 299 p. Guide to the Software Engineering Body of Knowledge Version 3.0. - Washington D.C.: IEEE Computer Society, 2013. - 355 p.

Hood С., Wiedemann S., Fichtinger S., Pautz U. Requirements Management: Interface Between Requirements Development and All Other Engineering Processes. - Berlin: Springer, 2007. - 275 p.

Khoroshilov A., Kuliamin V., Petrenko A. Verification of operating system components // Системная информатика. - 2017. - № 10. - С. 11-22. Kosko B. Fuzzy systems as universal aproximators // IEEE Transactions on computers. - 1994. - №11 - vol. 43 - P. 1329 - 1333.

Kosko B. Global stability of generalized additive fuzzy systems // IEEE transactions on systems, man, and cybernetics - part c: applications and reviews. -1998. - №3. - vol. 28 - P. 441 - 452.

Larman С. Agile and Iterative Development: a Manager's Guide. - Reading: Addison-Wesley Professional, 2004. - 342 p.

Lars Mieritz Gartner Survey Shows Why Projects Fail, 2012 [Электронный ресурс] URL: http://thisiswhatgoodlookslike.com/2012/06/10/gartner-survey-shows-why-projects-fail/ (дата обращения: 12.04.2018). Lederer A. Prasad J. Nine management guidelines for better cost estimating // Communications of the ACM. - Vol. 35, - Issue 2, - P. 51-59 Li B., Sun X., Leung H., Zhang S. A survey of code-based change impact analysis techniques // Software Testing, Verification and Reliability. - 2012. - P. 613-646 M. J0rgensen Unit effects in software project effort estimation: Work-hours gives lower effort estimates than workdays // Journal of Systems and Software. - 2016.

- Vol. 117. - P. 274-281.

Maistrou A.I., Bogomolov A.V. Technology of automated medical diagnostics using fuzzy linguistic variables and consensus ranking methods // IFMBE Proceedings World Congress on Medical Physics and Biomedical Engineering: Diagnostic and Therapeutic Instrumentation, Clinical Engineering. Cycle: "World Congress on Medical Physics and Biomedical Engineering: Diagnostic and Therapeutic Instrumentation, Clinical Engineering" Munich. - 2009. - Р. 38-41. Manalif E. Fuzzy Expert-COCOMO Risk Assessment and Effort Contingency Model in Software Project Management: Ph.D. dissertation \ Ekananta Manalif. -Canada, 2013. - 401 p.

31

32

33

34

35

36

37

38

39

40

41

42

43

44

Manentia F., Rossia F., Goryunov A., Dyadik A, Kozin K., Nadezhdin I. Mikhalevich S. Fuzzy adaptive control system of a non-stationary plant with closed-loop passive identifier // Resource-Efficient Technologies. - 2015. - № 1.

- Vol. 1. - P. 10-18.

McConnell S. Software Estimation: Demystifying the Black Art (Developer Best Practices). - Redmond: Microsoft Press, 2006. - 319 p.

Miller G.A., The magical number seven plus or minus two: some limits on our capacity for processing information // The Psychological Review. - 1956. - №63.

- P. 81-97.

Molokken-Ostvold K., Haugen N., Combining Estimates with Planning Poker -An Empirical Study // Software Engineering Conference ASWEC. - 2007. - P. 349-358.

Poppendieck M., Cusumano M., Lean Software Development: A Tutorial. // IEEE Software. - 2012. - vol. 29. - №5 - P. 26-32.

Putnam L., Putnam D., Beckert D. A Method for Improving Developers Software Size Estimates // Crosstalk. - 2005. - Vol. 18. - № 4. P. - 16-19.

Royce W. Managing the Development of Large Software Systems // TRW. - 1970.

- August. - P. 328-338.

Rupinder K., Sengupta J. Software Process Models and Analysis on Failure of Software Development Projects // International Journal of Scientific & Engineering Research. - 2011. - issue 2. - vol. 2. - P. 1-4.

Stanish Group Chaos report 2014. [Электронный ресурс] URL: http://www.projectsmart.co.uk/docs/chaos-report.pdf (дата обращения: 12.04.2014).

Stanish Group Chaos report 2015. [Электронный ресурс] URL: https ://www. infoq. com/articles/standish-chaos-2015, (дата обращения: 12.04.2018).

The Standish GroupReport CHAOS 2006. [Электронный ресурс] URL: http://www.projectsmart.co.uk/docs/chaos-report.pdf (дата обращения: 12.04.2018)

Valerdi R. The constructive systems engineering cost model (COSYSMO): Ph.D. dissertation / Valerdi Ricardo. - USA, 2005. - 152 p.

Бахиркин М.В. Система поддержки принятия решений для прогнозирования времени цикла разработки программных систем: дис. канд. тех. наук.: 05.13.01 / Бахиркин Михаил Васильевич. - М., 2016. - 114 с. Бахтизин В.В, Глухова Л.А. Выбор модели жизненного цикла разработки программных средств и систем на основе сводной таблицы критериев классификации проекта. // Доклады Белорусского государственного университета информатики и радиоэлектроники. 2005. № 1 C. 110-113.

45. Белоусов В.В. Состояние исследований в области разработки методического и программного обеспечения для систем управления и обработки информации // Системы высокой доступности. - 2010. - Т. 6. - № 4. - С. 4862.

46. Богомолов А.В. Использование лингвистических переменных и методов обработки экспертной информации для автоматизированного распознавания ранних стадий нарушения функционального состояния человека // Информационные технологии. - 2000. - № 8. - С. 12-18.

47. Богомолов А.В., Зуева Т.В., Чикова С.С., Голосовский М.С. Экспертно-аналитическое обоснование приоритетных направлений совершенствования системы предупреждения биологических террористических актов // Информатика и системы управления. - 2009. - № 4 (22). - С. 134-136.

48. Борисов В.В., Круглов В.В., Федулов А.С. Нечёткие модели и сети. - М.: Горячая линия - Телеком, 2007. - 284 с.

49. Брукс Ф. Мифический человеко-месяц, или как создаются программные системы. - СПб.: Символ-Плюс, 2010. - 304 с.

50. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений. - М.: Вильямс, 2008. - 720 с.

51. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. - М.: Финансы и статистика, 1998. - 98 с.

52. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. -М.: Финансы и статистика, 2006. - 544 с.

53. Ветошкин В.М., Саяпин О.В. Методика построения концептуальной информационной модели организационной системы // Известия ЮФУ. Технические науки. - 2013. - № 3 (140). - С. 250-255.

54. Ветошкин В.М., Саяпин О.В. Формулировка проблемы проектирования концептуальной информационной модели организационной системы // Технические науки - от теории к практике. - 2013. - № 17-1. - С. 29-34.

55. Ветошкин В.М., Саяпин О.В., Сергеев С.А. Взаимосвязь этапов фазы системного анализа и проектирования информационной базы // Труды ГосНИИАС. Серия: Вопросы авионики. - 2016. - № 2 (26). - С. 25-30.

56. Вигерс К., Битти Д. Разработка требований к программному обеспечению. -М.: Русская редакция, 2014. - 736 с.

57. Володин А.С., Столяр В.П., Голосовский М.С., Чикова С.С. и др. Обоснование системотехнических решений по созданию экспертной системы верификации биотерактов и разработка ее информационного обеспечения // Отчет о НИР шифр «Антибак». М.: ГосНИИИ военной медицины Минобороны России, 2006. 125 с.

58. Голосовский М.С. Модель расчета оценок трудоемкости и срока разработки информационных систем на начальном этапе жизненного цикла проекта // Программная инженерия. - 2016. - Т. 7. - № 10. - С. 446-455.

59. Голосовский М.С. Алгоритм локальной настройки систем нечёткого логического вывода типа Мамдани с сохранением интерпретабельности продукционных правил // Управление большими системами. - 2018. -Выпуск 74. - С. 6-22.

60. Голосовский М.С. Алгоритмы автоматизированного выявления связей между элементами проекта разработки программного обеспечения // Кибернетика и программирование. - 2017. - № 6. - С. 38-49.

61. Голосовский М.С. Информационно-логическая модель процесса разработки программного обеспечения // Программные системы и вычислительные методы. - 2015. - № 1. - С. 59-68.

62. Голосовский М.С. Моделирование жизненного цикла специального программного обеспечения // В сборнике: Южно-Уральская молодежная школа по математическому моделированию Сборник трудов II всероссийской научно-практической конференции. Под редакцией Ю.М. Ковалева. - 2015. - С. 55-62.

63. Голосовский М.С. Модель жизненного цикла разработки программного обеспечения в рамках научно-исследовательских работ // Автоматизация. Современные технологии. - 2014. - № 1. - С. 43-46.

64. Голосовский М.С. Модель оценивания погрешностей прогнозирования сроков разработки программного обеспечения // Программные системы и вычислительные методы. - 2015. - № 3, - С. 311-322.

65. Голосовский М.С. Сравнительный анализ моделей жизненного цикла программного обеспечения с различными способами организации потоков работ на основе результатов имитационного моделирования // Cloud of Science. - 2017. - Т. 4. - № 4. - С. 676-690.

66. Голосовский М.С., Постников А.В., Бодалова М.Ю. Совместная работа над документами в распределенных редакционных системах // Перспективы науки. - 2013. - № 4 (43). - С. 67-70.

67. Голосовский М.С., Постников А.В., Холкин С.И. Определение объема внесенных в текст изменений в редакционно-издательском процессе // Инновации и инвестиции. - 2013. - № 3. - С. 173-175.

68. Гольфанд И.Я., Хлебутин П.С. Оценка трудозатрат разработки программной компоненты//Труды ИСА РАН. - 2005. - Т.15. - С. 125-135.

69. ГОСТ Р 54869—2011 Проектный менеджмент. Требования к управлению проектом. - M. Стандартинформ, 2012. - 11 с.

70

71

72

73

74

75

76

77

78

79

80

81

82

83

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

- M. Стандартинформ, 2011. - 105 с.

Гуськов Г.Ю., Наместников А.М., Тимина И.А., Ярушкина Н.Г. Интеллектуальная система управления проектами разработки программного обеспечения // Вестник Ростовского государственного университета путей сообщения. - 2016. - № 3. - С. 31-36.

Демарко Т. Листер Т. Человеческий фактор. Успешные проекты и команды. M: Символ-Плюс, 2014. - 288 с.

Демирский А. А. Оценка структурной сложности программных средств в промышленности на ранних стадиях жизненного цикла: дис. канд. тех. наук. : 05.13.01 / Демирский Александр Анатольевич - Тверь, 2009. - 161 с. Десятое ежегодное исследование Российской индустрии экспортной разработки программного обеспечения. - M. Руссофт, - 2013, - 183c. Есев А.А., Солдатов А.С., Пушкарский Е.Ю. Метод квалиметрии сложных технических систем при проведении их испытаний // Научно-методический электронный журнал Концепт. - 2013. - Т. 3. - С. 1191-1195. Жбанова Н.Ю. Структурная и параметрическая идентификация разностных нейронечётких переключаемых моделей и нечётких многоэтапных входных процессов: дис. канд. тех. наук.: 05.13.18 / Жбанова Наталья Юрьевна. -Липецк, 2015. - 145 с.

Заде Л. Понятие лингвистической переменной и его применение к принятию приближенных решений. - М.: Мир, 1976. - 167 с.

Зимин К., Аншина М. Разработка ПО в российских компаниях. Результаты исследования // Information Management - 2014. - №1. - C. 69-79. Калянов Г. Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов. - М.: Финансы и статистика, 2006. - 240 с. Князев Е.Г., Шопырин Д.Г. Использование автоматизированной классификации изменений программного кода в управлении процессом разработки программного обеспечения // Информационно-управляющие системы. - 2008. - № 2. - С. 15-21.

Кон М. Scrum. гибкая разработка ПО. - М.: Вильямс, 2011. - 576 с. Копычев В.А. Управление качеством процесса разработки программного обеспечения на основе оценки профилей возможностей процессов // Инновационные технологии: теория, инструменты, практика. - 2014. - № 1.

- С. 234-239.

Кочеткова Л.И., Сенкевич Л.Б. Структура плана управления проектом в области разработки программного обеспечения // Современные наукоемкие технологии. - 2017. - № 6. - С. 62-66.

84. Круглов В.В. Сравнение алгоритмов Мамдани и Сугено в задаче аппроксимации функции // Математическая морфология: электронный математический и медико-биологический журнал. - 2001. - № 4. - С. 69-76.

85. Кудинов Ю.И., Келина А.Ю. Методы синтеза и настройки нечетких ПИД регуляторов Мамдани // Информационные технологии. - 2012. - № 6 (приложение). - 32 с.

86. Лаврищева Е.М., Петренко А.К. Моделирование семейств программных систем // Труды Института системного программирования РАН. - 2016. - Т. 28. - № 6. - С. 49-64.

87. Ларман К., Базили В. Итеративная и инкрементальная разработка: краткая история // Открытые системы. - 2003. - № 9. - С. 43-53.

88. Лезин А.Л., Медведев В.Р., Голосовский М.С. Разработка и апробация математических методов и компьютерных моделей обоснования выбора образцов технических средств медицинской службы // Материалы 3-го Азиатско-Тихоокеанского конгресса по военной медицине конгресса. - 2016.

- С. 31-32.

89. Липаев В. В. Прогнозирование экономических характеристик производства заказных программных продуктов // Программная инженерия. - 2012. - №3.

- С. 2-12.

90. Липаев В.В. Программная инженерия. Методологические основы. - М.: ТЕИС, 2006. - 608 с.

91. Липаев, В.В. Системное проектирование сложных программных средств для информационных систем. - М.: Синтег, 2002. - 268 с.

92. Липаев, В.В. Отечественная программная инженерия. Фрагменты истории и проблемы. - М.: Синтег, 2007. - 312 с.

93. Липаев, В.В. Процессы и стандарты жизненного цикла сложных программных средств. Справочник. - М.: Синтег, 2006. - 276 с.

94. Мадорская Ю.М. Метод обеспечения оценки сложности модификации программного обеспечения АСУПП: дис. канд. тех. наук.: 05.13.01 / Мадорская Юлия Михайловна. - СПб., 2011. - 170 с.

95. Макконел С. Сколько стоит программный проект. - СПб.: Питер, 2007. - 297 с.

96. Мельченко А.А. Гибкие методологии разработки программного обеспечения: экстремальное программирование управления проектами // Известия Гомельского государственного университета им. Ф. Скорины. - 2015. - № 2 (89). - С. 146-150.

97. Мещеряков Р.В. Критерий структурной сложности информационных систем // Труды СПИИРАН. - 2010. - № 3 (14). - С. 76-90.

98. Митрофанов Е.П. Формирование системы управления инвестиционными проектами по разработке программного обеспечения // Вестник Чувашского университета. - 2010. - № 2. - С. 397-401.

99. Муравьев Е.В., Барановская Е.В. Особенности управления рисками распределенной разработки программного обеспечения // Nauka-Rastudent.ru. - 2016. - № 12. - С. 30.

100. Нагин Д. А. Методы и модели для автоматизированного управления программными проектами: дис. канд. тех. наук.: 05.13.01 / Нагин Дмитрий Александрович. - М., 2006. - 148 с.

101. Орлик С. В. Модели жизненного цикла программного обеспечения // Ученые записки российского государственного социального университета. - 2011г. -№9. - С. 234-239.

102. Паклин Н.Б Адаптивные модели нечеткого вывода для идентификации нелинейных зависимостей в сложных системах: автореф. дис. канд. техн. Наук: 05.13.18 / Паклин Николай Борисович. - Ижевск, 2004. - 20 с.

103. Пащенко Д.С. Основные ошибки в управлении проектами заказной разработки программного обеспечения // Программная инженерия. - 2018. -Т. 9. - № 5. - С. 228-234.

104. Пегат А. Нечёткое моделирование и управление. 2-е издание. - М.: БИНОМ. Лаборатория знаний, 2013. - 798 с.

105. Песелис А. Управление рисками на предприятии в проектах разработки программного обеспечения // Предпринимательство. - 2012. - № 6. - С. 144152.

106. Петунин С.В., Юрьев А.М. Управление и автоматизация разработки программного обеспечения для систем MES-уровня // Автоматизация, телемеханизация и связь в нефтяной промышленности. - 2012. - № 4. - С. 2123.

107. Полицын С.А. Разработка специального математического и алгоритмического обеспечения системы анализа и принятия решений при управлении проектами создания программного обеспечения: дис. канд. тех. наук.: 05.13.01 / Полицын Сергей Александрович. - Москва, 2017. - 121 с.

108. Поппендик М, Поппендик Т. Бережливое производство программного обеспечения: от идеи до прибыли, Вильямс, 2009 г.

109. Проект ФЦП «Информационное общество (2011 - 2020 годы)» [Электронный ресурс] URL: http://минобрнауки.рф/%D0%B4%D0%BE%D0%BA%D1%83%D0%BC%D0 %B5%D0%BD%D 1 %82%D 1 %8B/2968/%D 1 %84%D0%B0%D0%B9%D0%B B/1675/13.02.07-

%D0%9F%D 1 %80%D0%BE%D0%B5%D0%BA%D 1 %82_%D0%A4%D0%A 6%D0%9F_%D0%98%D0%B8%D0%A0.pdf (дата обращения: 12.08.2018).

110. Ронжин А.Л., Басов О.О., Соколов Б.В., Юсупов Р.М. Концептуальная и формальная модели синтеза киберфизических систем и интеллектуальных пространств // Известия высших учебных заведений. Приборостроение. -2016. - Т. 59. - № 11. - С. 897-905.

111. Руководство к своду знаний по управлению проектами (Руководство PMBOK®) — Пятое издание // Project Management Institute, 2013, 614 c.

112. Сафронов В.В, Федорец О.Н. Метод построения эффективных моделей разработки программного обеспечения// Информационные технологии. -2010. - №1. - С. 34-40

113. Сачек Е.А. Применение имитационного моделирования в управлении проектами по разработке программного обеспечения с гибкими методологиями // Научные труды Северо-Западного института управления. -2015. - Т. 6. - № 4 (21). - С. 251-257.

114. Силич В.А., Силич М.П., Аксёнов С.В. Алгоритм построения системы нечёткого вывода Мамдани, основанный на анализе плотности обучающих примеров // Управление, вычислительная техника и информатика. - 2013. -№3. - С. 76-82

115. Скопин И.Н. Модели жизненного цикла программного обеспечения // Сб. Новосибирская школа программирования. Перекличка времен. Новосибирск: Изд. Института систем информатики им. А.П. Ершова СО РАН. - 2004. - С. 120-173.

116. Скрябин А.М. Кардаш Д.И. Жизненный цикл композиционно-адаптируемого программного обеспечения // Аспирант и соискатель. - 2008. - № 2. - С. 171174.

117. Стасенко А. Тестирование изменений в программной системе на основе покрытия исходного кода // Сборник научных трудов. Новосибирск: Ин-т систем информатики им. А.П. Ершова СО РАН. - 2012, - С. 106-115.

118. Сумароков С.В., Солдатов А.С., Кечков А.А., Гавров К.Е. Формирование информационной модели сложного научно-технического проекта // Информационные технологии в проектировании и производстве. - 2016. - № 1 (161). - С. 30-37.

119. Суслова С. А. Идентификация динамики технологических процессов на основе моделей нечеткой логики: дис. канд. тех. наук.: 05.13.18 / Суслова Светлана Александровна. - Воронеж, 2006. - 138 с.

120. Тележкин А.М. Применение алгоритмических сетей для оценки ресурсов в программных проектах: дис. канд. тех. наук.: 05.13.11 / Тележкин Александр Михайлович. - Санкт-Петербург, 2015. - 129 с.

121. Ткачук Н.В., Земляной А.А., Чугай В.А. Применение модели COCOMO II в задачах управления системными требованиями при разработке программного обеспечения // Вестник Национального технического университета Харьковский политехнический институт. Серия: Информатика и моделирование. - 2006. - № 40. - С. 178-185.

122. Фаулер М. Архитектура корпоративных программных приложений. 2-е издание. - М.: Издательский дом «Вильямс», 2006. - 544 c.

123. Чугунов А.В. Особенности управления проектами разработки и внедрения программного обеспечения // Вестник Международного института менеджмента ЛИНК. - 2016. - № 11 (40). - С. 171-176.

124. Чумакова Т.Я., Цыганенко С.М. Международные стандарты и жизненные циклы программного обеспечения // Математические машины и системы. -2009. - Т. 1. - № 3. - С. 144-150.

125. Штовба С.Д., Мазуренко В.В., Тылец Р.О. Информационная технология нечеткой идентификации для синтеза точных, компактных и интерпретабельных баз знаний // Computer Sciences and Telecommunications. - 2016. - № 1 (47). - С. 8-22.

126. Этингоф Е.В. Оценка затрат на информационные системы // Управление экономическими системами: электронный научный журнал. - 2013. - № 12 (60). - С. 33-45.