CC BY
21
УДК 004.3 DOI: 10.18287/2223-9537-2021-11-3-382-392
Оценка бюджета проекта по критериям удовлетворённости акторов
В.Е. Гвоздев, О.Я Бежаева, Д.Р. Ахметова, Г.Р. Сафина
Уфимский государственный авиационный технический университет, Уфа, Россия Аннотация
В руководствах по управлению проектами создания программных компонентов вычислительно-коммуникационных систем отмечается, что качество результатов определяется обоснованностью организационных решений, связанных с управлением проектом. Подчёркивается, что организационные ошибки, допускаемые на начальных стадиях проекта, включая недостаточную обоснованность бюджета проекта, имеют тяжелые последствия. Новизна настоящей работы заключается в утверждении о том, что качество результатов проекта в равной степени определяется не только удовлетворённостью потребителей/заказчиков, но и удовлетворённостью разработчиков ходом выполнения проекта. Предложена схема оценивания возможных границ бюджета проекта, в которых возможно получение решения, приемлемого как для потребителей/заказчиков, так и для исполнителей проекта. Основу схемы составляет использование опыта потребителей и разработчиков в реализации схожих по содержанию проектов. Модельную основу схемы составляют нелинейные эмпирические функциональные зависимости между показателями удовлетворённости акторов, бюджетом проекта и длительностью его реализации. Повышение обоснованности оценки бюджета с учётом опыта акторов является предпосылкой сокращения организационных дефектов проекта, что делает возможным достижение требуемого качества инфраструктурных компонентов вычислительно-коммуникационных систем.
Ключевые слова: треугольник проекта, удовлетворённость акторов, характеристика проекта, управление проектом, бюджет проекта.
Цитирование: Гвоздев, В.Е. Оценка бюджета проекта по критериям удовлетворённости акторов / В.Е. Гвоздев, О.Я. Бежаева, Д.Р. Ахметова, Г.Р. Сафина // Онтология проектирования. - 2021. -Т. 11, №3(41). - С. 382-392. - DOI: 10.18287/2223-9537-2021-11-3-382-392.
Введение
Переход от парадигмы «объект управления - субъект управления» к парадигме, основанной на сетецентрическом управлении [1, 2], от локальных информационных систем (ИС) к цифровой экосреде умных предприятий [3] обусловил необходимость внесения принципиальных изменений в методическое, модельное и инструментальное обеспечение реализации инфраструктурных компонентов вычислительно-коммуникационных систем (ВКС). В условиях четвёртой промышленной революции ВКС являются системообразующим инфраструктурным компонентом системы обеспечения жизнедеятельность распределённых динамических гетерогенных многоуровневых человеко-машинных систем [4].
К параметрам, характеризующим качество ВКС, относится, в том числе, удовлетворённость субъектов1 (акторов) как потребительскими свойствами объектов, так и ходом выпол-
1 Критерий удовлетворенности рассматривается как чувство, испытываемое человеком (актором), пожелания и требования которого удовлетворены в определённой степени, причём не обязательно в полном объёме. Степень удовлетворённости предполагаемым исходом проекта служит для актора основанием при принятии им решения о целесообразности его участия в проекте. Согласно (ISO/IEC 26514 Systems and software engineering — Requirements for designers and developers of user documentation) под проектом понимается совокупность мероприятий для разработки нового продукта или улучшения существующего продукта. См. также ГОСТ Р ИСО 10004-2020. Менеджмент качества. Удовлетворённость потребителей. Руководящие указания по мониторингу и измерению. Дата введения 2021-04-01.
2
нения проекта создания ВКС. В силу этого организационные ошибки, к числу которых относятся необоснованное назначение на начальной стадии проекта длительности реализации и бюджета3 проекта4, являются фактором снижения качества ВКС.
Переход от локальных ИС к цифровой экосреде при анализе результатов проекта требует смещения акцентов от оценки соответствия свойств результатов проекта требованиям технического задания к оценке удовлетворённости пользователей [1, 2, 5, 6]. Отмеченное обстоятельство служит основанием для совершенствования подходов к оцениванию основных характеристик проектов на их начальных стадиях.
Концептуальной основой настоящей статьи является утверждение, что удовлетворённость потребителя5 результатами проекта, а исполнителя - организацией и ходом выполнения проекта являются важными факторами, определяющими успех проекта. Удовлетворённость заказчика6 является интегральной характеристикой соответствия потребительских свойств ИС представлениям о ценностях потребителей. Удовлетворённость исполнителя является интегральной характеристикой соответствия внутреннего устройства проекта (организационного, финансового, технологического) на всех стадиях его жизненного цикла (ЖЦ) такому устройству, которое ожидалось на ранней стадии проекта.
1 Факторы, влияющие на определение основных характеристик проекта
Для формирования консолидированного мнения неоднородных акторов в условиях всё возрастающей сложности, неопределённости, скорости изменения состояния окружающей среды и их различного влияния на представление акторов о ценностях и удовлетворённость своим состоянием необходимо наличие инструментов, позволяющих:
■ быстро получать хорошо интерпретируемые и одинаково понимаемые акторами оценки основных характеристик проекта;
■ учитывать опыт реализации аналогичных проектов;
■ использовать как фактические (исторические) данные, связанные с реализованными подобными проектами, так и нематериальные активы акторов (аксиологические знания). Одной из наиболее известных концептуальных моделей проекта, соответствующих
начальной фазе ЖЦ, является «треугольник проекта». Эта модель определяет факторы, составляющие основу построения систем управления проектами. Известные вариации этой модели можно условно разделить на два класса по признаку важности субъективной составляющей в успехе/провале проектов.
В моделях, относящиеся к 90-м годам, в качестве критических факторов проекта приняты: бюджет, сроки, качество (иногда - расписание, бюджет, технические спецификации). Отмечалась необходимость учёта субъективного восприятия критических факторов и пред-
Ход выполнения проекта - это состояние работ по проекту на текущую дату. Отслеживание хода выполнения проекта позволяет сопоставлять плановые фактические сроки выполнения работ, расход, бюджет и качество получаемых
3 Бюджет проекта представляет собой план затрат, необходимых для выполнения проекта в стоимостном выражении. Бюджет проекта включает затраты на закупку аппаратных компонентов, информационных ресурсов, инструментальных средств, выплату заработной платы (включая отчисления в социальные фонды), услуги сторонних организаций, амортизацию зданий, техники, оборудования и нематериальных активов. Бюджет проекта служит основанием для определения стоимости проекта.
4 Под реализацией проекта понимается выполнение операций, обозначенных в плане проекта и направленных на достижение целей проекта.
5 Потребители результатов проекта (в случае информационной системы - пользователи информационной системы) -лицо, группа лиц или организация, пользующееся услугами информационной системы для получения информации или решения других задач. Потребитель получает и внедряет результаты проекта в свою деятельность, согласует промежуточные и окончательные результаты проекта.
6 Заказчик - сторона, заинтересованная в осуществлении проекта и достижении его целей. Будущий владелец результатов проекта.
полагалось ввести в модель четвёртую составляющую - «люди» [7]. Анализ перечня критических факторов успеха проекта позволил заключить, что успех более чем на 75% определяется субъективной составляющей [8]. Анализ критических факторов провала указывает на то, что субъективная составляющая влияет не менее чем на 60%.
В отчёте Standish Group 2015 года вместо фактора качества (Quality) использована следующая совокупность характеристик: цели проекта (Target); локальные цели, соответствующие дорожной карте проекта (Goal); ценности, получаемые заказчиком (Value); удовлетворённость организацией и ходом выполнения проекта исполнителем (Satisfaction) [8, 9]. Внесённые изменения также являются свидетельством важности влияния субъективной составляющей на успех проекта.
Время реализации проекта ИС является приоритетным критическим фактором, определяющим ценность предоставленных информационных продуктов и услуг [10]. Время жизни информационных продуктов и услуг зависит от скорости изменения состояния внешней среды и внутреннего состояния объекта управления [5, 11, 12].
В бюджете проекта наибольшую неопределённость представляет оценка стоимости программного компонента ВКС, т.к. реализация программных проектов основана на использовании нематериальных активов - интеллектуальных ресурсов акторов [8, 9].
К числу факторов, определяющих стоимость продукта, относятся: предполагаемая трудоёмкость создания продукта (основанием для её оценки служат требования пользователей к свойствам конечного продукта); предложения по готовым решениям на рынке программных продуктов; ограничения на длительность реализации проекта; опыт, полученный субъектами, участвующими в определении бюджета проекта, при реализации предшествующих проектов; состояние рынка труда и другие факторы, среди которых существенное место занимают факторы субъективной природы.
На начальной стадии ЖЦ возможность влияния на длительность реализации проекта является ограниченной. В большей степени акторы могут влиять на бюджет проекта.
2 Анализ подходов к оцениванию бюджета проекта
Бюджет проекта в основном определяется путём переговоров между заказчиком и исполнителем. Задача разработки формализованных методик для информационной поддержки поиска заинтересованными сторонами консолидированного решения относительно оценки стоимости результатов проекта давно находятся в поле зрения специалистов, связанных с реализацией ИС.
Анализу моделей, методов и инструментов оценки стоимости программных продуктов посвящены работы [13-15]. Подходы к оценке стоимости, изложенные в этих работах, могут быть классифицированны следующим образом:
Слабоформализованные методы. Их областью применимости является начальная стадия проекта. Определение стоимости предполагаемого продукта основано на эмпирических данных, относящихся к ранее реализованным проектам. Примерами методов, относящихся к этому классу, являются Price-to-win («цена победы»); оценка по Паркинсону; экспертные оценки; оценки по аналогии и др. [16].
Методы, основанные на анализе архитектуры программных продуктов. Наиболее известным представителем методов, относящихся к этому классу, является метод функциональных точек (Function Points - FP). Метод инвариантен к языку программирования и среде разработки. Ограничением базового FP является то, что он не ориентирован на исследование программных систем с высокой интенсивностью вычислений. Модифицированный метод FP ориентирован на исследование программных систем, реализующих высокую интенсивность
вычислений [17]. Существенным ограничением методов этого класса является предположение о высоком качестве функциональных требований [15].
Методы, основанные на подсчёте числа строк кода (Source Lines of Code — SLOC). Основу этих методов составляют эмпирические модели, устанавливающие размер затрат в зависимости от числа строк кода и характеристик среды реализации проекта. Примером метода оценивания, основанного на SLOC, может служить модель Post Architecture Model (PAM), являющаяся частью COCOMO [18]. Ограничениями этого подхода являются низкая достоверность оценивания числа SLOC на начальной стадии проекта и неопределённость понятия «строка кода».
Методы, основанные на совместном использовании измерительных данных и экспертных оценок. Примером такого метода является CoBRA [19]. Основу метода составляет оценивание номинальной трудоёмкости и накладных расходов. Под «номинальной трудоёмкостью» понимаются инженерные и управленческие усилия на разработку программного проекта в среде организации.
В работе [20] рассматривается подход к оцениванию бюджета проекта на начальной стадии на основе исторических данных о бюджетах и длительности реализации ранее выполненных проектов, а также оценках уровня удовлетворённости различных целевых групп пользователей и исполнителей проекта в виде параметров лингвистической шкалы. Модельную основу подхода составляло построение эмпирических (регрессионных) моделей в условиях различных объёмов независимых и зависимых случайных величин [21]. Основными допущениями подхода являются следующие:
■ Удовлетворённость потребителей свойствами конечного продукта определяется организацией и ходом реализации проекта. Поведение системы определяется её устройством [22], поэтому причинами нежелательных событий, возникающих при управлении сложными субъектоцентрическими системами, являются в первую очередь ошибки в организации управления системой, и лишь во-вторую очередь ошибки операторов [23].
■ На предпроектной стадии ВКС в силу высокой неопределённости состояния внешней среды проекта (модель «конус неопределённости» [24]) целесообразно проект создания ИС рассматривать как многосвязный объект управления. Это даёт основание рассматривать прямые и перекрёстные связи между входными и выходными параметрами проекта как строгие функциональные зависимости с неизменными структурой и параметрами.
■ Программные системы относятся к классу субъектоцентрических систем. В силу этого при оценивании характеристик проектов следует одновременно использовать как метрические исторические данные о ранее реализованных проектах, так и субъективные оценки акторов, причастных к реализации проектов.
■ Исход проекта в равной мере определяется как ограничениями на бюджет и длительность реализации проекта, так и опытом исполнителя в выполнении проектов аналогичного содержания. Это допущение основано на «принципе ресурсов» [22] и субъектоцен-тричности проекта ИС [25].
■ Сопоставимость и однородность исторических данных об основных параметрах проектов и полученных в ходе их реализации продуктов. Основанием является то, что организации-разработчики специализируются на реализации проектов в определённой предметной области и внутри организации накапливается опыт решения задач определённой тематической направленности [26], а ключевые моменты деятельности сотрудников регламентируется стандартами и официально утверждёнными руководствами.
Исход проекта - это логически завершенный конечный результат проекта в виде продукта (например, ВКС), обладающего свойствами, соответствующими в приемлемой для потребителя степени его потребностям и ожиданиям.
3 Модель проекта как многосвязного объекта
Основу построения модели проекта составляет рассмотрение его как многосвязного объекта управления [20]. Входами объекта являются параметры х1 - бюджет проекта и х2 - длительность реализации проекта. Выходами являются - характеристика удовлетворённости пользователей/заказчиков и г2 - характеристика удовлетворённости разработчиков. Характеристики г/ (у = 1,2 ) и параметры х1(/ = 1, 2 ) связаны функциональными зависимостями 2/ = Фу (х1,х2 ). В работе [20] Фу (х1,х2 ) представлена в виде:
Ф1(Х1, Х2 ) = 71^11 (Х1) + 72^21 (Х2), (1)
Ф2(Х1, Х2 ) = ^12 (Х1) * ^22 (Х2), (2)
где (х^), (/,_/' = 1, 2 ) - строгие функциональные зависимости. При 1=] они характеризуют прямые связи между входами и выходами объекта; при iфj - перекрестные.
7ь 72 - коэффициенты, характеризующие значимость параметров х1 и х2. Если исходить из равного влияния на успех проекта его длительности и бюджета [24], то коэффициентам следует присвоить значение 71= 72=0,5.
При этом
ф12 (х1) = 0 при х1 = 0 и ф12 (х1) ^ 1 при х1 ^ от, (3)
^22 (Х2) = 0 при Х2 = 0 и ^22 (Х2) ^ при Х2 ^ ОТ. (4)
4 Оценивание возможности реализации проекта
Основу оценивания возможности реализации проекта составляет нахождение значений х1, х2, при которых уровень удовлетворённости заказчика и исполнителя не ниже некоторых заданных значений, т.е.
а<Ф1(х1,Х2 ) <1 ; (5)
^<Ф2(Х1,Х2 ) <1 ■ (6)
Качественные графические модели для условий (5) и (6) представлены на рисунке 1, где пунктирными линиями выделены области допустимых решений.
а) Графическая модель Фх (х1( х2 )
б) Графическая модель Ф2(х 1,х2 )
х* - граничные значения параметров бюджета и длительности реализации, при повышении которых реализация проекта теряет смысл; х1" - предельные (верхние) значения параметров проекта, при повышении которых удовлетворённость
заказчика уменьшается ниже желаемого для него значения а; х^ - предельные (нижние) значения параметров проекта, при уменьшении которых удовлетворённость исполнителя оказывается ниже желаемого для него значения
Рисунок 1 - Графические модели Ф1(х1,х2 ) и Ф2(х 1,х2 )
Графическое представление нахождения сбалансированного решения между потребителем/заказчиком и исполнителями представлены на рисунке 2. Реализация проекта возможна лишь в условиях сбалансированности запросов к параметрам проекта заказчика и исполнителя (значения а и Р) и сопоставимости их персонального опыта, накопленного при реализации прежних проектов (зависимости (р¿у (х^), /,_/' = 1, 2).
(а) - возможность нахождения сбалансированного решения с учётом особенностей ф;у (х;),
а также значений а и Р; (б) - невозможность нахождения сбалансированного решения с учётом особенностей ф;у (х;),
а также значений а и Р;
Рисунок 2 - Графическое представление нахождения сбалансированного решения между потребителем/заказчиком и исполнителями
5 Оценивание эмпирических функциональных зависимостей
5.1 Формирование структуры функциональных зависимостей
В качестве структур эмпирических зависимостей могут быть выбраны следующие:
фп (х;) = е"1^ (7)
фи (х;) = ( 1 - ), / = 1, 2 . (8)
Эти зависимости удовлетворяют всем ограничениям, накладываемым на Фу (х1,х2 ) и формируемым посредством (3) и (4).
5.2 Оценивание параметров функциональных зависимостей
К особенностям оценивания эмпирических функциональных зависимостей относятся то, что: параметры х1 и х2 являются метрическими характеристиками, а степень удовлетворённости субъектов выражается вербальными оценками; целевые группы пользователей/ заказчика могут выражать разные уровни удовлетворённости потребительскими свойствами продукта. Группы исполнителей, участвующие в решении задач, могут выражать разные уровни удовлетворённости ходом выполнения проекта. Иными словами, отдельному проекту изначально ставятся в соответствие две метрические характеристики х^ х2 и множество вербальных оценок различных групп потребителей и исполнителей.
Первым этапом определения параметров эмпирических зависимостей является обеспечение равенства объёмов параметров {х;}", (/ = 1 , 2 ); {гу}", (у = 1 , 2 ). В [21] описана процедура квантификации экспертных оценок, даваемых субъектами, принадлежащими к различным подгруппам групп пользователей и исполнителей.
В результате применения процедуры каждому /-му проекту ставятся в соответствие интегральные оценки удовлетворённости пользователей/заказчика z( l) и исполнителей z( 1 \
Расчёт эмпирических моделей (7) и (8) сводится к решению задач оптимизации без ограничений.
Для модели (7): £f= ¿z[l) - !?=i е "1у'х('°) г? min. (9)
ГЛ ( i)
Для модели (8): £f= Az) l) - П 2=i ( 1 - е qjXJ ) —> m in. (10)
J <?1,<?2
Здесь N - число однотипных проектов, схожих с тем, параметры которого оцениваются.
Выбор квадратичной целевой функции обусловлен высокой устойчивостью полученных оценок. Особенности решения задач, подобных (9) и (10) обсуждается в [27].
Параметры моделей 1уДу (j = 1 , 2 ) содержательно характеризуют опыт пользователей/заказчика и исполнителей, полученный при реализации предыдущих проектов. Полученные значения ( ) позволяют оценить возможность нахождения приемлемых решений с учётом ограничений вида ( ) а также желаемых значений .
Пример. Пусть имеются исторические сведения о десяти проектах, схожих с тем, параметры которого оцениваются (см. таблицу 1).
Таблица 1 - Исторические сведения о проектах
Проекты Xi x? Z i (x i , X 2 ) Z 2 (x i ,x 2 )
1 2,5 1,5 0,9 0,95
2 1 3 0,9 0,9
3 2 1 1 0,8
4 3,5 2 0,7 1
5 2 5 0,6 1
6 3 5 0,4 1
7 2,5 2,5 0,7 1
8 2 3 0,75 1
9 0,5 0,5 1 0,3
10 5 5 0,3 1
Граничные значения параметров для предполагаемого проекта составляют: x¡ =
5, ( / = 1,2 ).
Значения коэффициентов, полученных в результате решения задач (9) и (10) методом деформируемого многогранника [28] и характеризующих опыт пользователей/заказчика и исполнителей, составляют 1 ! = 1 2= 0,4; ц ! = ц2 = 2. Графические модели, характеризующие возможность нахождения приемлемых решений при различных требованиях к уровням удовлетворённости, представлены на рисунке 3.
ч
(а) (б)
а) Возможно нахождение решений при а > 0 , 8 ; / > 0, 9 5 (область с двойной штриховкой) б) Невозможно нахождение решений при а > 0, 9 5 ; // > 0, 9 5 (нет области с двойной штриховкой)
Рисунок 3 - Возможность нахождения приемлемых решений при разных значениях уровней удовлетворенности
Рисунок 3 носит иллюстративный характер и предназначен для демонстрации ситуаций, когда нахождение приемлемого для заказчика и исполнителя решения о характеристиках проекта, исходя из ограничений на уровень их удовлетворённости исходом проекта, возможно или невозможно.
Заключение
Предлагаемый подход к оцениванию одной из основных характеристик проекта (бюджета) основан на эмпирических моделях, построенных на опыте реализации предыдущих проектов. Такой подход отражает субъектоцентрическую природу проектов, субъективизм в оценивании приемлемых стартовых условий проекта.
Благодарности
Исследования выполнены при поддержке гранта РФФИ №19-08-00937 А «Методы и модели интеллектуальной поддержки принятия решений при управлении программными проектами, реализуемыми в среде производственных предприятий».
Список источников
[1] Козлов, С.В. Проблема интероперабельности в сетецентрических системах управления / С.В. Козлов, С.И. Макаренко, А.Я Олейников., Д.В. Растягаев, Т.Е Черницкая. // Журнал радиоэлектроники. 2019. № 12. С.34. DOI: 10.30898/1684-1719-2019.12.4.
[2] Макаренко, С.И. Модели интероперабельности информационных систем / С.И. Макаренко, А.Я Олейников, Т.Е. Черницкая // Системы управления, связи и безопасности. 2019. № 4. С.215-245. - DOI: 10.24411/2410-9916-2019-10408.
[3] Geisberger, E. Living in a networked world. Integrated research agenda Cyber-Physical Systems / E. Geisberger, M. Broy // Acatech STUDY. March 2015. - 291 p.
[4] Тимофеев, А.Н. Почему падают IT-проекты? / А.Н. Тимофеев // Практика проектирования систем, 2017. С.2-12.
[5] Systems Engineering Guide for Systems of Systems. DoD, version 1.0, August 2008. - 135 p.
[6] Kazman, R. Understanding Patterns for system-of-system integration / R. Kazman, C. Nielsen, K. Schmid // Software Engineering Institute and Acquisition Practices, Technical Node. CMU/SET-2013-TR-017, December 2013. - 25 p.
[7] Gray, R. Projects and Projects Management / Gray R. // A review of literature. 1998. - 27 p.
[8] CHAOS Report. The Standish Group International, Inc., 2015. -https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf.
[9] CHAOS MANIFESTO. The Standish Group International, Inc., 2013. -https://www.standishgroup.com/sample_research_files/CM2013-8+9.pdf.
[10] Беркун, С. Искусство управления IT-проектами / С. Беркун. - СПб: Питер, 2010. - 432 с.
[11] Трутнев, Д.Р. Архитектуры информационных систем. Основы проектирования. / Д.Р. Трутнев. - СПб: НИУ ИТМО, 2012. - 125 с.
[12] Noureen, A. Model Driven Architecture - Issues, Challenges and Future Directions / A. Noureen, A. Amjad, F. Azam // Journal of Software, 2016. 11(9), P. 924-933. DOI: 10.17706/jsw.11.9.924-933.
[13] Сидоров, Н.А. Модели, методы и средства оценки стоимости программного обеспечения / Н.А. Сидоров, Д.В. Баценко, Ю.Н. Василенко, Ю.В. Щебетин // Методи та засоби програмно! iнженерii, 2006. С.290-298.
[14] Медведкова, И.В. Сравнительный анализ методов оценки стоимости проектов по разработке программного обеспечения / И.В. Медведкова, А.А. Иванов // International Journal of Humanities and Natural Sciences, 2009, Vol. 6-1, P.138-141.
[15] Котов, С.Л. Информационно-аналитическая система оценивания трудозатрат и стоимости создания программных средств / С.Л. Котов, А.А. Демирский // Программные продукты и системы, 2017, Т. 3(30). С.469-473. DOI: 10.15827/0236-235 x.119.469-473.
[16] Boeham, B. W. Software Engineering Economics / B. W. Boeham - Prentice-Hall, 1981. - 320 p.
[17] Albrecht, A.J Software function, source lines of code, and development effort prediction: a software science validation / A.J. Albrecht, J.E. Gaffney Jr. // IEEE Transactions on Software Engineering, Vol. 9, 1983. P.639-648.
[18] Липаев, В.В. Технико-экономическое обоснование проектов сложных программных средств / В.В. Липаев. - М.: СИНТЕГ, 2004. - 284 с.
[19] Briand, L. COBRA: a hybrid method for software cost estimation, benchmarking, and risk assessment / L. Briand, K. Emam, F. Bomarius // International Software Engineering Reseavel Network Technical Report ISERN - 97 -24 (version 2), 1997. - 24 p.
[20] Гвоздев, В.Е. Формирование параметров модели управления проектом на основе линеаризации функциональных зависимостей / В.Е. Гвоздев, О.Я. Бежаева, Д.Р. Ахметова, Г.Р. Сафина // Онтология проектирования. - 2020. - Т.10, №4 (38). С.527-539. DOI: 10.18287/2223-9537-2020-10-4-527-539.
[21] Гвоздев, В.Е. Оценивание линейных взаимосвязей параметров технических объектов при отсутствии корреляционной таблицы эмпирических данных / В.Е. Гвоздев, О.Я. Бежаева, А.С. Субхангулова // Вестник Уфимского государственного авиационного технического университета, 2005. - Т.19, №4(70). С. 106-117.
[22] Meadows, D.H. Thinking in Systems / D.H. Meadows. - Chelsea Green Publishing. 2008, - 240 p.
[23] Shappell, S. The Human Factors Analysis and Classification System-HFACS / Scott Shappell, Douglas A Wiegmann // U.S. Department of Transportation Federal Aviation Administration, 2000. - 15 p.
[24] Макконнелл, С. Сколько стоит программный проект / С. Макконнелл. - Санкт-Петербург, 2007. - 297с.
[25] Huang. F. Software defect prevention based on human error theories / F. Huang, B. Liu // Chinese Journal of Aeronautics, Vol. 30(3). 2017. P.1054-1070.
[26] Шведин, Б.Я. Онтология предприятия: экспириентологический подход. Технология построения онтологической модели предприятия на основе анализа и структурирования живого опыта / Б.Я. Шведин. - М.: ЛЕНАНД, 2010. - 240 с.
[27] Демиденко, Е.З. Линейная и нелинейная регрессии / Е.З. Демиденко. - М.: Финансы и статистика, 1981. - 304 с.
[28] Дамбраускас, А.П. Симплексный поиск / А.П. Дамбраускас. - М.: Энергия, 1979. - 176 с.
Сведения об авторах
Гвоздев Владимир Ефимович, 1956 г. рождения. Окончил Уфимский авиационный институтам. Орджоникидзе в 1978 г., д.т.н. (2000). Профессор кафедры технической кибернетики Уфимского государственного авиационного технического университета (УГАТУ). В списке научных трудов более 370 работ в области прикладного статистического анализа, информационной поддержки управления программными системами, информационной поддержки управления состоянием территориальных систем. AuthorID (РИНЦ): 174520. Author ID (Scopus): 7101700484. wega55@mail.ru. Бежаева Оксана Яковлевна, 1977 г. рождения. Окончила УГАТУ в 2000 г., к.т.н. (2004). Заведующий кафедрой технической кибернетики Уфимского государственного авиационного технического университета. В списке научных трудов более 100 работ в области разработки моделей и программного обеспечения сложных производственных и социально-экономических систем. AuthorID (РИНЦ): 271220. Author ID (Scopus): 57216845244. obezhaeva@gmail.com.
Ахметова Динара Раилевна, 1992 г. рождения. Окончила УГАТУ в 2014 г. Аспирант кафедры технической кибернетики УГАТУ. В списке научных трудов 30 работ в области программно-аппаратных комплексов технических систем. AuthorID (РИНЦ): 943467. Author ID (Scopus): 57204756902. dinara. akhmetova. 92@gmail.com.
Сафина Гульнур Радиковна, 1997 г. рождения. Магистрант УГАТУ по направлению «Информатика и вычислительная техника». В списке научных трудов 10 работ в области программно-аппаратных комплексов технических систем. lafleur300997@gmail.com.
Поступила в редакцию 14.07.2021, после рецензирования 21.09.2021. Принята к публикации 27.09.2021.
Assessment of the project budget according to the criteria of the actors' satisfaction
V.E. Gvozdev, O.Ya. Bezhaeva, D.R. Akhmetova, G.R. Safina
Ufa State Aviation Technical University, Ufa, Russia
Abstract
In the project management manuals for the creation of software components of computing and communication systems, it is noted that the quality of the results is determined by the validity of organizational decisions related to project management. It is emphasized that organizational mistakes made at the initial stages of the project, including insufficient justification of the project budget, have serious consequences. The novelty of this work lies in the assertion that the quality of the project results is equally determined not only by the satisfaction of consumers / customers, but also by the satisfaction of the developers with the progress of the project. A scheme for assessing the possible boundaries of the project budget, in which it is possible to obtain a solution acceptable both for consumers / customers and for the executors of the project, is proposed. The basis of the scheme is the use of the experience of consumers and developers in the implementation of projects with similar content. The model basis of the scheme is formed by non-linear empirical functional dependencies between the indicators of actor satisfaction, the project budget and the duration of its implementation. Improving the validity of the budget assessment, taking into account the experience of the actors, is a prerequisite for reducing the organizational defects of the project, which makes it possible to achieve the required quality of the infrastructure components of computing and communication systems.
Key words: project triangle, actor satisfaction, project description, project management, project budget.
Citation: Gvozdev VE, Bezhaeva OYa, Akhmetova DR, Safina GR. Assessment of the project budget according to the criterion of the actors' satisfaction [In Russian]. Ontology of designing. 2021; 11(3): 382-392. DOI: 10.18287/22239537-2021-11-3-382-392.
Acknowledgment: The research was carried out with the support of the RFBR grant No. 19-08-00937 A "Methods and models of intelligent support for decision-making in the management of software projects implemented in the environment of industrial enterprises."
List of figures and tables
Figure 1 - Graphic models 0>1(x1,x2
Figure 2 - Graphical representation of finding a balanced solution between the consumer / customer and contractors Figure 3 - The ability to find acceptable solutions for different values of the levels of satisfaction Table 1 - Historical information about projects
References
[1] Kozlov SV, Makarenko SI, Oleinikov AYa, Rastyagaev DV, Chernitskaya TE. The problem of interoperability in network-centric control systems [In Russian]. Journal of Radioelectronics, 2019; 12: 34 p.
[2] Makarenko SI, Oleinikov AYa, Chernitskaya TE. Models of interoperability of information systems [In Russian]. Control systems, communications and security, 2019; 4: 215-245. DOI: 10.24411/2410-9916-2019-10408.
[3] Geisberger E, Broy M. Living in a networked world. Integrated research agenda Cyber-Physical Systems. Acatech STUDYMarch, 2015; 291 p.
[4] Timofeev AN. Why are IT projects falling? [In Russian]. Practice of systems design. 2017; 2-12. http://reqcenter.pro/why-it-fails/.
[5] Systems Engineering Guide for Systems of Systems. DoD, version 1.0, August 2008, 135 p.
[6] Kazman R, Nielsen C, Schmid K. Understanding Patterns for system-of-system integration. Software Engineering Institute and Acquisition Practices, Technical Node. CMU/SET-2013-TR-017, December 2013; 25 p.
[7] Gray R. Projects and Projects Management. A review of literature, 1998; 27 p.
[8] CHAOS Report. The Standish Group International, Inc., 2015. -https://www.standishgroup.com/sample_research_files/CHA0SReport2015-Final.pdf
[9] CHAOS MANIFESTO. The Standish Group International, Inc., 2013. -https://www.standishgroup.com/sample_research_files/CM2013-8+9.pdf
[10] Berkun S. The art of IT project management [In Russian]. Peter Publisher. 2010; 432 p.
[11] Trutnev DR. Information systems architecture. Basics of design. [In Russian] St. Petersburg, NRU ITMO. 2012; 255 p.
[12] Noureen A, Amjad A, Azam F. (2016). Model Driven Architecture - Issues, Challenges and Future Directions. Journal of Software.2016; 11(9): 924-933. DOI: 10.17706/jsw.11.9.924-933.
[13] Sidorov NA, Batsenko DV, Vasilenko YuN, Schebetin YuV. Models, methods and means of software evaluation [In Russian]. Methods for software engineering. 2006; 290-298.
[14] Medvedkova IV, Ivanov AA. Comparative analysis of methods for assessing the cost of software development projects [In Russian]. International Journal of Humanities and Natural Sciences, 2009; 6-1:138-141.
[15] Kotov SL, Demirsky AA. Information-analytical system for assessing labor costs and the cost of creating software [In Russian]. Software products and systems, 2017; 3 (30): 469-473. DOI: 10.15827 / 0236-235 x.119, pp 469-473.
[16] Boeham BW. Software Engineering Economics. Prentice-Hall, 19814; 320p.
[17] Albrecht AJ, Gaffney JE. Software function, source lines of code, and development effort prediction: a software science validation. - IEEE Transactions on Software Engineering. 1983; 9: 639-648.
[18] Lipaev VV. A feasibility study of complex software projects. [In Russian]. Moscow: SINTEG, 2004; 284 p.
[19] Briand L, Emam K, Bomarius F. COBRA: a hybrid method for software cost estimation, benchmarking, and risk assessment. International Software Engineering Reseavel Network Technical Report ISERN - 97 - 24 (version 2). 1997; 24 p.
[20] Gvozdev VE, Bezhaeva OYa, Akhmetova DR, Safina GR. Formation of project management model parameters based on linearization of functional dependencies [In Russian]. Ontology of designing. 2020; 10(4): 527-539. DOI: 10.18287/2223-9537-2020-10-4-527-539.
[21] Gvozdev VE, Bezhaeva OYa, Subkhangulova AS. Estimation of linear relationships of parameters of technical objects in the absence of a correlation table of empirical data [In Russian]. Bulletin of the Ufa State Aviation Technical University. 2005; 19(4): 106-117.
[22] Meadows DH. Thinking in Systems. Chelsea Green Publishing. 2008; 240 p.
[23] Shappell S, Wiegmann D. The Human Factors Analysis and Classification System-HFACS.U.S. Department of Transportation Federal Aviation Administration. 2000; 15 p.
[24] McConnellS. How much does a software project cost? [In Russian]. Peter Publisher; 2007. 296 p.
[25] Huang F, Liu B. Software defect prevention based on human error theories. Chinese Journal of Aeronautics. 2017; 30(3): 1054-1070.
[26] Shvedin BYa. Enterprise ontology. Experimental approach. Technology for constructing an enterprise ontological model [In Russian]. Moscow: Lenand. 2010; 240 p.
[27] DemidenkoEZ. Linear and non-linear regression. [In Russian]. Moscow: Finance and Statistics. 1981; 304 p.
[28] DambrauskasAP. Simplex search. [In Russian]. Moscow: Energiya. 1979; 176 p.
About the authors
Vladimir Efimovich Gvozdev (b. 1956) graduated from the Ufa Aviation Institute in 1978, D. Sc. Eng. (2000). Professor of the Department of Technical Cybernetics, Ufa State Aviation Technical University (USATU). He is a coauthor of about 370 scientific articles and abstracts in the field of applied statistical analysis, information support for managing software systems, information support for managing the state of territorial systems. AuthorlD (RSCI): 174520. Author ID (Scopus): 7101700484. wega55@mail.ru.
Oksana Yakovlevna Bezhaeva (b. 1977) graduated from the USATU in 2000, PhD. (2004). Head of the Department of Technical Cybernetics, Ufa State Aviation Technical University (USATU). She is a co-author of about 100 scientific articles and abstracts in the field of development of models and software for complex production and socioeconomic systems. AuthorlD (RSCI): 271220. Author ID (Scopus): 57216845244. obezhaeva@gmail.com.
Dinara Railevna Akhmetova (b. 1992) graduated from the USATU in 2014. She is a graduate student at USATU (Department of Technical Cybernetics). She is a co-author of 30 scientific articles and abstracts in the field of software and hardware systems of technical systems. AuthorID (RSCI): 943467. Author ID (Scopus): 57204756902.
dinara. akhmetova. 92@gmail.com.
Gulnur Radikovna Safina (b. 1997) is a magister of the USATU in the direction of Informatics and Computer Engineering. She is a co-author of 10 scientific articles and abstracts in the field of software and hardware systems of technical systems. lafleur300997@gmail.com.
Received July 14, 2021. Revised September 21, 2021. Accepted September 27, 2021.
