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

 

Объект исследования: системная модель «Пирамида программного проекта».

Результаты, полученные лично автором: разработана уточненная нечеткая когнитивная модель «Пирамида программного проекта» для руководителя программного проекта с использованием нечетких когнитивных карт В.Б. Силова. Проведен статический анализ модели и динамическое моделирование в системе поддержки принятия решений «ИГЛА».

 

Целью работы является создание уточненной нечеткой когнитивной модели формирования стратегий управления предприятий, занимающихся разработкой программных проектов на основе системной модели «Пирамида программного проекта» В.Е. Гвоздева и Б.Г. Ильясова.

Для построения когнитивной карты требуется выполнить когнитивный анализ сложной ситуации:

· формулировка задачи и цели исследования;

· изучение процесса с позиций поставленной цели;

· сбор, систематизация, анализ существующей статистической и качественной информации по решаемой проблеме;

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

· определение присущих исследуемой ситуации требований, условий и ограничений;

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

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

В основе семантической сети программного проекта выделены следующие концепты:

· Объем требований заказчика;

· Сложность Технического задания;

· Ожидаемый объем работ;

· Объем привлекаемых ресурсов;

· Уровень используемых технологий;

· Качество программного продукта;

· Количество доработок на стадии внедрения;

· Ценность программного продукта с точки зрения пользователя.

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

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

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

Графическое представление нечеткой когнитивной модели на основании сформированной матрицы в системе поддержки принятия решений«ИГЛА» представлено на рис. 1, где красным цветом выделены положительные связи, а синим цветом отрицательные.

Рис.1. Графическое представление нечеткой когнитивной модели

 

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

Материал поступил в редколлегию 20.04.2017

УДК 004.42

И.С. Исаев

Научный руководитель: доцент кафедры «Информатика и программное обеспечение», к.т.н., Д.И. Булатицкий

Разработка программного интерфейса (API) для манипулирования данными в системе мониторинга успеваемости студентов и посещаемости занятий "СУП"

Объект исследования: процесс взаимодействия приложений посредством программных интерфейсов (API).

Результаты, полученные лично автором: разработан программный интерфейс (API) для манипулирования данными в системе мониторинга успеваемости студентов и посещаемости занятий "СУП" (программная реализация).

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

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

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

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

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

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

Все данные в теле запроса к системе и ответа от нее будут представлены в формате JSON.

Далее представлен список некоторых методов разрабатываемого API c кратким описанием входных параметров и ответов.

Методы работы с группами:

1. /groups – GET метод. Возвращает список всех групп в системе. Входные параметры отсутствуют. Ответ содержит словарь ключ-значение, где в качестве ключа выступает id группы, а в качестве значения – название группы.

2. /groups – POST метод. Предназначен для создания групп. Обязательными входными параметрами являются название группы, id учебного плана, назначенного данной группе, смена, год поступления. В ответе содержатся id созданных групп в случае успеха.

3. /groups/{groupId} – GET метод. Предоставляет общие данные по группе. Входным параметром является id группы. На выход система предоставляет id учебного плана, назначенного данной группе, смену, год поступления, статус активности группы.

4. /groups/{groupId}/students – GET метод. Возвращает список студентов в группе. В качестве входного параметра выступает id группы. Ответ содержит словарь ключ-значение, где в качестве ключа выступает id студента, а в качестве значения – ФИО студента.

5. /groups/{groupId}/students – POST метод. Предназначен для добавления новых студентов в группу. Обязательными параметрами являются фамилия, имя студента, id группы. В ответе содержатся id созданных студентов в случае успеха.

6. /attendance/{groupId} – GET метод. Позволяет получить данные о посещаемости. Входными параметрами являются id группы, номер месяца и id семестра. Ответ содержит данные о посещаемости каждого студента в группе в каждый день месяца.

7. /academicPlans – GET метод. Возвращает список учебных планов (УП) в системе. Входных параметров нет. Ответ содержит словарь ключ-значение, где в качестве ключа выступает id УП, а в качестве значения – название УП.

В случае возникновения ошибки для всех методов помимо стандартного кода ошибки, также возвращается описание ошибки в теле запроса.

Для разработки подсистемы была использована среда разработки MS Visual Studio Community 2015 и язык С#. Также для разработки была использована СУБД Microsoft SQL Server 2016 Express. Для документирования методов API был использован сервис SwaggerHub.

Материал поступил в редколлегию 12.04.2017

УДК 519.81

Д.А. Касницкий

Научные руководители: заведующий кафедрой «Информатика и программное обеспечение», к.т.н., доцент А.Г. Подвесовский; доцент кафедры «Информатика и программное обеспечение», к.т.н., Д.В. Титарев

[email protected]

СОВЕРШЕНСТВОВАНИЕ МОДЕЛИ ПРЕДПОЧТЕНИЙ ЛИЦА, ПРИНИМАЮЩЕГО РЕШЕНИЕ, В МНОГОКРИТЕРИАЛЬНОЙ
ЗАДАЧЕ О НАЗНАЧЕНИЯХ

Объект исследования: многокритериальная задача о назначениях.

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

 

Целью работы является совершенствование модели предпочтений лица, принимающего решение (ЛПР), в многокритериальной задаче о назначениях (МЗН) за счет учета и формализации дополнительной информации о предпочтениях ЛПР. В общем виде постановка МЗН заключается в следующем. Имеется n субъектов (например, работ) и n объектов (например, исполнителей). Каждый субъект и каждый объект характеризуются вектором оценок по совокупности критериев. Критерии оценки субъектов и объектов носят «зеркальный» характер – например, каждому критерию, характеризующему требования, предъявляемые работой, соответствует некоторый критерий, характеризующий возможности исполнителя. Необходимо определить n наиболее близких по своим характеристикам пар «субъект – объект», где под близостью понимается соответствие между характеристиками объекта и требованиями субъекта.

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

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

Рис. 1. Классический алгоритм решения МЗН

1. Информация для формирования векторов соответствия. Включает в себя сообщения следующих видов:

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

– оценка исполнителя по критерию должна в точности равняться целевой;

– оценка исполнителя по критерию должна быть не выше целевой.

2. Дополнительная информация о важности критериев:

– критерий K_i важнее критерия K_j;

– критерии K_i и K_j имеют одинаковую важность.

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

Материал поступил в редколлегию 20.04.2017

УДК 004.422.63

Р.А. Крылов

Научный руководитель: профессор кафедры «Информатика и программное обеспечение», к.т.н., В.К. Гулаков

[email protected]