В настоящее время на российских предприятиях наблюдается глобальная тенденция к цифровизации, которая включает в себя автоматизацию документооборота [1], а также внедрение информационных технологий на всех этапах конструкторской и производственной деятельности [2, 3]. Дополнительное повышение спроса на продукцию отечественных разработчиков корпоративных информационных систем обусловлено продолжающейся волной импортозамещения зарубежного программного обеспечения. Совокупность этих факторов требует от разработчиков качественно и в сжатые сроки выполнять поставленные задачи, чтобы удовлетворить потребности заказчика программного продукта, гарантировать получение своих экономических выгод, а также противостоять конкурентам. Ведение такой деятельности является сложным процессом, который требует от руководителей проектов учитывать большое количество внутренних и внешних факторов, а целью исследования, описание которого приводится в данной статье, является разработка программного средства для поддержки и оптимизации управленческих решений в рамках проектной деятельности по разработке и внедрению корпоративных информационных систем.
Методы организации проектной деятельности формировались десятилетиями и непрерывно меняются под требования современного рынка [4, 5]. Инструментальные средства для поддержки проектной деятельности также демонстрируют непрерывное развитие, в частности широкое распространение получили трекеры задач, такие как Jira, RedMine, которые поддерживают гибкие методологии разработки программного обеспечения [6], а также на рынке представлены инструменты для управления рисками [7]. Для проведения исследования процесса разработки информационных систем исследователями представлены варианты реализации мультиагентных моделей деятельности коллектива разработчиков [8]. Однако, несмотря на многообразие методологических и программных средств для управления проектами, многие задачи остаются нерешенными.
Целью проводимого авторами исследования является разработка алгоритмического и программного обеспечения для поддержки и оптимизации управленческих решений в части:
- мониторинга общего хода выполнения задач, отклонений от поставленных сроков, а также общее количество свободных и занятых исполнителей;
- назначения исполнителей на выполнение задач;
- обеспечения развития исполнителей в профессиональном плане.
Обеспечение трех вышеперечисленных условий гарантирует руководителю проекта получение актуальной информации о вовлеченности сотрудников в реальном времени, а также их профессиональных компетенциях. Входные данные для мониторинга и поддержки принятия решений берутся из трекера задач, где имеется вся необходимая информация о решенных и открытых задачах, а также имеются данные для сбора статистики по разработчикам. Обработка входных данных должна осуществляться в программном комплексе, использующем методы теории принятия решений, исследования операций. Главное требование к разрабатываемому программному комплексу – инвариантность по отношению к предметной области и отсутствие жесткой привязки к конкретному источнику входных данных, что позволит его использование в процессе разработки и внедрения информационных систем любого класса. В результате анализа и обработки информации должны формироваться рекомендации о назначениях, формы статистической и интерактивной отчетности.
Материалы и методы исследования
При разработке описанного комплекса в первую очередь необходимо обеспечить информационную интеграцию с трекером задач, общая схема которой представлена на рис. 1.
Рис. 1. Схема информационного обмена между системами
На данной схеме показано, что акторы «Аналитик» и «Разработчик» могут вносить задачи, редактировать, а также закрывать их в трекере задач, получать уведомления от него посредством электронной почты. Трекер задач взаимодействует со своей базой данных (БД), а также реализовано двухстороннее взаимодействие посредством протокола https между ним и информационной системой (ИС) для поддержки решений. ИС для поддержки решений взаимодействует со своей БД, что обеспечивает независимость от трекера, а также позволяет хранить историю и проводить простую миграцию данных для новых сотрудников. Для реализации инвариантных методов поддержки принятия решений ИС также посредством https взаимодействует с web-сервисами для поддержки решений. Результаты расчетов по запросу передаются менеджеру проекта (МП).
После реализации такой интеграции решение первой из поставленных в цели исследования задач может быть достигнуто следующим образом: если существует хотя бы одна задача, которую решает данный разработчик, то он считается занятым в текущий момент. Если не существует ни одной задачи, которую бы решал данный разработчик в текущий момент, то он считается свободным. Эту информацию можно выводить в форме любой отчетности, показывая итоги по занятым и не занятым в текущий момент исполнителям. Также полезной отчетной формой является перечень задач, для которых указывается отклонение от плановых сроков.
Вторая задача – задача о назначениях исполнителей на задачи – является более сложной в решении и требует применения математических подходов для нахождения оптимального или рационального решения. Классическая задача о назначениях предлагает использование матрицы потерь, на основании которой определяется назначение исполнителей по задачам, при котором выгода руководителя проекта будет максимальной. Однако априорной информации о разработчиках и задачах зачастую недостаточно для составления такой матрицы, поэтому авторы предлагают отказаться от ее использования в пользу регрессионной модели, которая позволила бы подобрать наилучшего исполнителя для решения очередной задачи из числа доступных в данный момент. В качестве зависимой величины Y в регрессионной модели предлагается использовать выгоду от решения данным исполнителем данной задачи. Под выгодой будем подразумевать качество решения задачи в установленный срок. Для оценки выгоды можно использовать следующее априорное соотношение, которое в достаточной степени характеризует качество выполнения разработки:
где используются следующие обозначения: Yapr – априорная величина выгоды от выполнения задачи, вычисление которой необходимо для подбора коэффициентов уравнения регрессии; R – количество возвратов разработки после тестирования; Tf и Tp – фактическое и плановое время на выполнение разработки соответственно. В качестве вектора независимых величин X можно использовать следующий набор количественных характеристик:
- общее количество решенных задач х1 в данный момент;
- количество задач, решенных в данной предметной области х2 в данный момент;
- плановое время на решение задачи х3;
- сложность задачи х4;
- приоритет задачи х5;
- количество параллельно решаемых задач х6 в данный момент.
Далее авторы предлагают составить линейное уравнение регрессии на исторически имеющейся из трекера задач информации о зависимой и независимых величинах:
где α0 – свободный член уравнения регрессии, αi – значимые коэффициенты при значимых факторах, xi – значения независимых переменных, n – количество независимых переменных. Подбор коэффициентов уравнения регрессии осуществляется путем решения оптимизационной задачи:
где m – количество исторических наблюдений за задачами и разработчиками из трекера задач. После подбора оптимальных коэффициентов уравнения регрессии в распоряжении менеджера появляется инструмент, с помощью которого можно прогнозировать выгоду от решения очередной задачи конкретным программистом.
Следующая задача, которая должна решаться в разрабатываемом программном комплексе – обеспечение профессионального развития исполнителей в различных предметных областях, которые охватываются разрабатываемой или внедряемой информационной системой. Для этого рассмотрим полигон частот F решения задач из каждой предметной области, представленный на рис 2. Для большей конкретики рассмотрим предметные области, охватываемые ERP-системой.
Рис. 2. Полигон частот решения задач из разных предметных областей
На данном рисунке горизонтальная линия показывает оценку математического ожидания частоты решения задач в различных предметных областях. С точки зрения менеджера идеальный разработчик – тот, у которого отклонения как в большую, так и в меньшую сторону от этой линии равны нулю, – такой разработчик может решить любую задачу, возникающую на проекте. Однако авторы не предлагают выравнивать полигон частот до среднего значения, так как здесь имеют место быть различные качественные факторы, например такие как личный интерес исполнителя к определенной предметной области, но для обеспечения широкого круга компетенций полезно минимизировать отклонения между средним значением и частотами меньше него:
где l – количество предметных областей, ? – разность между средним значением и частотой.
Заключительный критерий, который является важным для выбора исполнителя для решения очередной задачи – профессионализм в конкретной области, для каждого разработчика это будет высота столбца на полигоне частот для конкретной предметной области. Таким образом, мы имеем три критерия, которые подходят для рационального выбора исполнителя. Для последующего ранжирования разработчиков данные критерии необходимо скаляризовать. Для использования методов свертки авторы используют распределенные web-сервисы для поддержки принятия решений ws-dss.com, где представлена открытая реализация методов теории принятия решений. Самый простой метод свертки представленных критериев реализуется применением метода взвешенной суммы:
Здесь Rk(Di, T) показывает ранг разработчика с номером i для решения задачи T, w – весовые коэффициенты, Yi(T) – прогнозная выгода от решения задачи T разработчиком с номером i, F(T)i – частота решения разработчиком с номером i задач из предметной области, к которой относится задача T. Чем больше значение взвешенной суммы – тем лучше подходит разработчик.
Главное преимущество применения метода взвешенной суммы – возможность управлять процессом ранжирования за счет варьирования весовых коэффициентов в зависимости от ситуации на проекте. Если ситуация благоприятная и все задачи решаются в срок, большее внимание можно уделять развитию сотрудников за счет повышения w2, если же имеет место срыв сроков, то большую значимость приобретает w3, что обеспечивает применение самого опытного и надежного разработчика для данной задачи.
Результаты исследования и их обсуждение
В данном исследовании рассмотрена актуальная задача управления проектами по разработке и внедрению информационных систем – задача о ранжировании исполнителей. Представленные алгоритмы реализованы на языке C# с применением .Net Core, для обмена данными со сторонними информационными системами используется технология REST, а сами данные передаются в формате json, что обеспечивает кросс-платформенное решение. Информация о весах критериев и самих критериях передается в ws-dss (рис. 3) для дальнейшей обработки, откуда итоговые ранги разработчиков попадают в интерфейс программы для поддержки решений.
Рис. 3. Распределенные web-сервисы для поддержки принятия решений
Ws-dss реализована с применением языков Ruby и Python, а в распоряжении разработчиков есть такие методы свертки как взвешенная сумма, свертка Гермейера и т.д. Применение облачных и параллельных вычислений гарантирует быстрое получение результатов при большом объеме данных.
Заключение
Разработанные методы показали достаточную эффективность и быстродействие на тестовой выборке данных, что позволяет сделать вывод об их пригодности к решению реальных практических задач. Дальнейшие направления развития проекта предполагают доработку пользовательского интерфейса, преобразуя его в так называемое рабочее место руководителя проекта по разработке и внедрению информационных систем. Также приоритетным направлением является апробация предложенных методов в рамках реального проекта с возможностью получения полезных предложений и замечаний, которые позволили бы, при необходимости, улучшить функциональные качества предложенного программного продукта.
Данная работа выполнена при финансовой поддержке РФФИ, проект № 18-00-00012 (18-00-00011) КОМФИ.
Библиографическая ссылка
Алексеева М.С., Куренных А.Е., Судаков В.А. ПОДДЕРЖКА УПРАВЛЕНЧЕСКИХ РЕШЕНИЙ НА IT-ПРОЕКТАХ // Современные наукоемкие технологии. – 2020. – № 3. – С. 14-18;URL: https://top-technologies.ru/ru/article/view?id=37932 (дата обращения: 20.04.2024).