Примерная тематика ВКР при выполнении работы на базе университета

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

2. Автоматизация бизнес-процесса анализа загруженности аудиторного фонда на платформе 1С: Предприятие

3. Автоматизация деятельности специалиста по работе со студентами

4. Автоматизация подбора списка литературы для учебно-методических материалов

5. Автоматизация процесса записи на приём к руководству образовательной организации

6. Автоматизация процесса контроля знаний обучающихся

7. Автоматизация процесса направления студентов на практику

8. Автоматизация процесса разработки диагностических материалов на основе компетентностного подхода

9. Автоматизация процесса создания контент-плана для социальных сетей образовательной организации

10. Автоматизация процесса создания учебных планов

11. Автоматизация процесса учёта посещаемости студентов

12. Автоматизация процесса формирования расписания

13. Автоматизация процессов учета работы филиалов образовательной организации

14. Автоматизация работы научно-исследовательского отдела и аспирантуры

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

16. Автоматизация работы Управления по организации приема

17. Автоматизация работы факультета довузовской подготовки

18. Автоматизация рабочего места психолога колледжа

19. Автоматизация сбора информации о публикационной активности преподавателей

20. Автоматизация управления студенческими проектами

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

22. Автоматизация учета посещаемости обучающихся

23. Автоматизация учета публикационной активности аспирантов университета

24. Автоматизация формирования документации приёмной комиссии

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

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

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

28. Автоматизированная система учета работы студентов в Электронном университете

29. Автоматизированная система юридической службы организации

30. Автоматизированное рабочее место библиотекаря

31. Автоматизированное рабочее место сотрудника группы планирования учебного процесса

32. Автоматизированное формирование вариантов тестовых заданий для проведения диагностики сформированности компетенций

33. Адаптация корпоративного электронного университета для лиц с ограниченными возможностями зрения

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

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

36. Внедрение системы электронного документооборота в юридической клинике

37. Доработка модуля контроля текущей успеваемости студентов

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

39. Информационная система учета спортивных достижений студентов

40. Корпоративная информационная система Цифрового издательства

41. Модернизация информационной системы Центра обслуживания звонков

42. Модификация личного кабинета студента в дистанционной образовательной среде

43. Модификация чата Электронного университета

44. Проектирование портала для создания и хранения портфолио обучающихся

45. Разработка web-сайта для просмотра видео-курсов

46. Разработка автоматизированного рабочего места медсестры учебного заведения

47. Разработка автоматизированного рабочего места омбудсмена

48. Разработка автоматизированного рабочего места педагога-психолога

49. Разработка автоматизированного сервиса подбора сотрудников на основе информации из резюме

50. Разработка автоматизированной информационной системы для библиотекаря

51. Разработка автоматизированной системы "Учебный график студента"

52. Разработка автоматизированной системы для проведения тестирования остаточных знаний обучающихся

53. Разработка автоматизированной системы для службы безопасности и внутреннего контроля

54. Разработка автоматизированной системы мониторинга здоровья обучающихся

55. Разработка автоматизированной системы планирования и учета воспитательной работы факультета

56. Разработка автоматизированной системы планирования расписания учебных занятий

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

58. Разработка автоматизированной системы поддержки и организации конференций

59. Разработка автоматизированной системы поддержки проекта "ВКР как стартап"

60. Разработка автоматизированной системы сопровождения проектной деятельности студентов

61. Разработка автоматизированной системы учета выполнения преподавателями норм времени по научной и учебно-методической работе

62. Разработка автоматизированной системы учета текущего контроля знаний студентов колледжа

63. Разработка автоматизированной системы учёта академических задолженностей студентов на платформе 1С: Предприятие

64. Разработка агрегатора библиотечных ресурсов с использованием web-интерфейсов

65. Разработка бота-автоответчика для Центра поддержки

66. Разработка геоинформационной модели для обучения студентов направления подготовки 41.03.02 "Регионоведение России"

67. Разработка и адаптация плагинов moodle для электронной образовательной среды университета

68. Разработка интерактивного образовательного приложения по изучению языка запросов SQL

69. Разработка интерактивного образовательного приложения по программированию на языке Python

70. Разработка интерактивного приложения для изучения английского языка на учебных занятиях

71. Разработка интерактивного приложения для обучения русскому языку

72. Разработка интерактивной модели и алгоритма навигации в здании университета

73. Разработка информационной системы для организации и проведения спортивных соревнований

74. Разработка информационной системы для учета успеваемости студентов

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

76. Разработка информационной системы мониторинга образовательного процесса

77. Разработка информационной системы подготовки документации для проверки аккредитационными органами

78. Разработка информационной системы промежуточного контроля знаний учащихся

79. Разработка информационной системы учета динамики изменения показателей здоровья спортсменов

80. Разработка информационной системы учета медицинских изделий и препаратов в медицинском пункте

81. Разработка информационной системы учета оборудования лаборатории комплексных исследований водных ресурсов

82. Разработка информационной системы учета публикационной активности сотрудников организации

83. Разработка информационный системы для организации взаимодействия между организаторами и участниками научной конференции

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

85. Разработка конструктора электронных учебных курсов

86. Разработка корпоративной информационной системы для Цифрового издательства

87. Разработка личного кабинета сотрудника учебно-методического департамента в электронной образовательной среде университета

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

89. Разработка мобильного приложения для закрепления результатов изучения языков программирования на платформе Android

90. Разработка мобильного приложения для изучения иностранного языка

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

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

93. Разработка мобильного приложения учета посещаемости и активности студентов на учебных занятиях

94. Разработка модуля автоматического формирования методических рекомендаций к рейтинговым работам

95. Разработка модуля визуализации данных для Единого центра статистических данных

96. Разработка модуля для организации дистанционного консультирования студентов тьюторами

97. Разработка модуля для оценки качества письменных работ студентов в Электронном университете

98. Разработка модуля для формирования индивидуального образовательного трека обучающегося

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

100. Разработка модуля контроля сеанса тестирования обучающихся со стороны преподавателя

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

102. Разработка модуля корпоративной системы для формирования студенческих портфолио

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

104. Разработка модуля создания и учета учебно-методических материалов

105. Разработка модуля учета достижений обучающихся

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

107. Разработка модуля формирования резюме на основе данных Электронного портфолио

108. Разработка планировщика задач на языке программирования Python и создание Telegram-бота

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

110. Разработка платформы для взаимодействия проектных групп

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

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

113. Разработка платформы для сопровождения образовательного процесса инвалидов и лиц с ограниченными возможностями здоровья

114. Разработка платформы для сопровождения процессов разработки авторского контента

115. Разработка платформы для технологических стартапов

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

117. Разработка приложения для проведения внутренней оценки качества образования

118. Разработка приложения для проведения онлайн-консультаций специалистами Юридической клиники

119. Разработка приложения для проверки корректности выходных данных научной литературы в студенческих работах

120. Разработка приложения для решения комбинаторных задач

121. Разработка приложения для управления индивидуальными студенческими заданиями по курсу "Дискретная математика"

122. Разработка программного модуля учета проведения вебинаров в высшем учебном заведении

123. Разработка программного модуля учета рейтинговых работ студентов

124. Разработка сайта приемной комиссии университета

125. Разработка сервиса для проведения онлайн контестов

126. Разработка системы автоматизированного подбора списка литературы для рабочих программ учебных дисциплин

127. Разработка системы автоматизированного формирования рабочих программ учебных дисциплин

128. Разработка системы автоматического формирования сертификатов участников научной конференции

129. Разработка системы автоматической генерации информационных рассылок студентам

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

131. Разработка системы для автоматизированного формирования сборника конференции из файлов научных статей

132. Разработка системы для автоматизированного формирования списка литературы в соответствии с ГОСТ

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

134. Разработка системы информирования студентов на базе телеграмм-бота

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

136. Разработка системы прокторинга для образовательного процесса

137. Разработка телеграм-бота помощника для улучшения взаимодействий со студентами и абитуриентами

138. Разработка чата для общения обучающихся-инвалидов и сотрудников университета с использованием шрифта Брайля

139. Разработка чат-бота для ответов на заявки студентов

140. Разработка чат-бота для поддержки проведения межвузовского турнира "CodeIT"

141. Разработка чат-бота для формирования документов участников ;научных конференций

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

143. Разработка электронного конструктора для формирования методических указаний к рейтинговым работам

Примерная тематика ВКР, при выполнении работы на базе предприятия

1. Автоматизация логистических процессов организации

2. Автоматизация планирования работы сотрудников

3. Автоматизация процесса складского учета

4. Автоматизация процесса составления юридических документов

5. Автоматизация процессов документооборота лабораторий специальных исследований

6. Автоматизация работы военного комиссариата

7. Автоматизация работы научно-исследовательского центра

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

9. Автоматизированная система выдачи пропусков

10. Автоматизированное рабочее место диспетчера транспортного предприятия

11. Автоматизированное рабочее место инженера автобусного парка

12. Автоматизированное рабочее место инженера по эксплуатации многофункционального делового центра

13. Автоматизированное рабочее место инженера производственного отдела

14. Автоматизированное рабочее место юриста предприятия по делам административных правонарушений

15. Адаптация корпоративной информационной системы для слабовидящих сотрудников

16. Доработка конфигурации Бит.Строительство

17. Информационная система обслуживания заявок

18. Информационная система управления грузами складского помещения на основе корпоративной системы 1С: Предприятие

19. Информационно-аналитическая система персонализированной выдачи информации на платформы социальных сетей

20. Модернизация ИТ инфраструктуры организации

21. Модификация модуля кадрового учета геодезического предприятия на платформе 1С: Предприятие

22. Модификация типовой конфигурации 1С: Предприятие для учета туристических туров

23. Программа-переводчик с русского жестового языка на русский язык

24. Проектирование и разработка корпоративной электронной библиотеки

25. Проектирование информационной системы «Автоматизация проверки доступности сайта»

26. Разработка desktop-приложения для сбора и хранения научных данных по учёту и регистрации животных

27. Разработка web-приложения для регистрации заявок на приобретение систем хранения данных

28. Разработка автоматизированного рабочего места сотрудника охранного предприятия

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

30. Разработка автоматизированной системы для отдела охраны труда и техники безопасности

31. Разработка автоматизированной системы персонального спортивного тренера

32. Разработка агрегатора новостей с элементами персонифицированной выдачи информации

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

34. Разработка аналитического модуля для автоматизированного рабочего места маркетолога

35. Разработка виртуальной модели умного здания

36. Разработка генератора картографических альбомов

37. Разработка и внедрение корпоративного хранилища данных

38. Разработка и внедрение корпоративной телефонной сети VoIP на основе программного обеспечения Asterisk

39. Разработка инструмента для автоматической рассылки по электронной почте оповещений о кадровых изменениях с использованием 1С: Зарплата и управление персоналом

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

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

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

43. Разработка информационной системы планирования спортивных мероприятий

44. Разработка информационной системы по оркестрации статических анализаторов

45. Разработка конфигурации для контроля качества пищевой продукции с использованием платформы 1С: Предприятие

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

47. Разработка мобильного приложения электронной библиотеки

48. Разработка модуля автоматизированного складского учета в информационной системе мебельного магазина

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

50. Разработка модуля для проведения геодезических работ

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

52. Разработка модуля отчетности геодезического предприятия на платформе 1С

53. Разработка модуля фотографирования

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

55. Разработка портала для организации виртуальных выставок

56. Разработка приложения для контроля этапов приготовления блюд в соответствии с рецептурами

57. Разработка программного модуля по десериализации базы данных в рамках разработки автоматизированной системы

58. Разработка прототипа корпоративной системы управления рисками

59. Разработка сервиса технической поддержки и сопровождения программного обеспечения

60. Разработка системы автоматизации бизнес-процессов сбора и обработки телеметрической информации

61. Разработка системы автоматизированного формирования рассылок участникам научных конференций

62. Разработка системы информирования слабослышащих пользователей о чрезвычайных ситуациях

63. Разработка системы организованного электронного документооборота ремонтно- механического завода

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

65. Разработка системы прогнозирования водопотребления для полива сельскохозяйственных культур

66. Разработка системы регистрации заявок на сопровождение лиц с ограниченными возможностями здоровья при посещении организации

67. Разработка системы экстренного оповещения

68. Разработка стратегии тестирования информационной системы

69. Разработка универсального фреймворка для автоматизации создания ботов на платформе eXpress

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

71. Система управления задачами разработки программного обеспечения

ВКР содержит титульный лист, содержание (оглавление), введение, основную часть, заключение, список литературы и приложения (при необходимости).

Введение (1-2 страницы). Во введении обосновывается актуальность выбранной темы, определяется степень её разработанности, формулируются цель и задачи ВКР.

Ключевые элементы введения:

- обоснование актуальности выбранной темы;

- определение цели и постановка задач исследования;

- выделение и определение объекта и предмета исследования;

- выбор программной платформ;

- ссылка на репозиторий Gitflic или Github;

- ссылка на разработанный веб-ресурс, размещенный на бесплатном хостинге (для ВКР по разработке веб-ресурса).

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

В аналитической части необходимо провести:

- провести анализ нормативно-правовой базы выбранной предметной области;

- оценку уровня разработанности выбранной темы;

- выявить ключевые проблемные зоны в предметной области;

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

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

- определить требования пользователей к системе;

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

Аналитическую документацию составляет формальное описание предметной области, бизнес-процессов, автоматизацию которых призвана обеспечить система (программа), функциональных и нефункциональных требований к ней. В зависимости от решаемых задач возможно использование различных методов и моделей построения таких описаний. К ним относятся SADT, BPMN, ERM, UML.

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

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

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

В проектной части необходимо:

- определить границы разрабатываемого программного обеспечения;

- определить контексты работы программного обеспечения;

- построить соответствующие диаграммы, иллюстрирующие результат работы (минимальный набор – диаграммы «как есть» и «как будет» в нотации IDEF0 не ниже 1-го уровня, диаграмма в нотации DFD, диаграмма вариантов использования и диаграмма деятельности на языке UML; в работе должны быть диаграммы, отражающие структуру используемых данных, например, диаграммы в нотациях ER, IDEF1X);

- разработать техническое задание в соответствии с ГОСТ 34.602-2020;

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

- провести разработку программного обеспечения / модуля;

- выбрать методику тестирования разработанного ПО;

- провести отладку и тестирование ПО в соответствии с выбранной методикой;

- разработать руководство администратора ПО;

- разработать руководство пользователя.

Экономическая часть

В экономической части рассматриваются вопросы эффективности предлагаемых решений, излагается методика определения показателей эффективности, приводятся расчетные данные на конкретном примере.

Заключение

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

Список литературы включает перечень источников, которые были использованы при подготовке бакалаврской работы и на которые есть ссылки в основном тексте. Список должен быть оформлен по ГОСТ Р 7.0.100-2018.

Список литературы бакалаврской работы должен включать не менее 10 источников.

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

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

1. Требования к разрабатываемому программному обеспечению на базе платформы 1С: Предприятие

1. Обязательна загрузка в ЭУ вместе с ВКР / выгрузка в репозиторий Gitflic или Github файла с выгрузкой конфигурации 1С *.dt (возможно приложить архив всей папки с конфигурацией, с комментариями о версии платформы 1С, для которой выполнялся проект).

2. Конфигурация должна содержать следующий минимальный набор объектов:

- Справочники – не менее 15, из них не менее 3 иерархических.

- Документы – не менее 10.

- Константы – не менее 2.

- Перечисления – не менее 3.

- Общие модули – не менее 1.

- Обработки – не менее 1.

- Отчеты – не менее  5, в том числе сложные – не менее 3. Сложным отчетом считается отчет, для построения которого следует обратиться к данным не менее 3-х объектов конфигурации. Для решения задач учета следует использовать специализированные объекты (планы и регистры).

- Подсистемы - не менее 4.

- Регистры накопления – не менее 3.

3. Отчеты, представленные в конфигурации должны иметь печатные формы.

4. Проанализировать необходимость использования регистров сведений и регистров расчета. Разработать необходимые регистры сведений и регистры накопления. Анализ отразить в ВКР.

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

6. Создать не менее 3-х ролей пользователей конфигурации.

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

8. Для основных сценариев использования конфигурации должны быть созданы бизнес-процессы.

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

2. Требования к разрабатываемому ПО на языке высокого уровня

1. Программное обеспечение разрабатывается на языке Python c использованием сред разработки PyCharm / VS Code / Google Colab / Yandex DataSphere.

2. Обязательна загрузка в ЭУ вместе с ВКР / выгрузка в репозиторий Gitflic или Github исполняемого *.exe файла и файлов программного кода *.py (при необходимости архивируется вся папка проекта, с комментариями об используемых дополнительных библиотеках и версиях), либо файла программного кода *.ipynb, если работа выполнялась с использованием языка программирования Python и сервисов Google Colab и Yandex DataSphere.

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

4. Обязательно должен быть сформирован исполняемый *.exe файл

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

6. Обеспечить хранение данных приложения в СУБД, поддерживающей SQL- запросы. Рекомендуется PostgreSQL.

7. В приложении должно быть не менее 10 оконных форм.

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

9. Реализовать функционал доступа к файловой системе.

10. Реализовать панель управления / настройки в приложении, где добавить не менее 5 пунктов меню.

11. Реализовать возможность формирования документов в форматах .docx, .xlsx и т.п. из разрабатываемого приложения.

12. Предусмотреть не менее 3-х ролей пользователей. Предоставить учетные данных всех созданных пользователей.

13. Разработать панель администратора.

14. Разработать личный кабинет пользователя.

15. Предусмотреть функционал «Справка по системе».

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

16. Разработка кода должна выполняться с использованием аппаратного обеспечения.

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

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

1. Приложение должно быть разработано под операционную систему Android. Язык написания приложения Java или Kotlin.

2. Обязательна загрузка в ЭУ вместе с ВКР / выгрузка в репозиторий Gitflic или Github исполняемого *.apk файла-приложения для Android и исходных файлов с программным кодом.

3. Работа над проектом должна вести в git-репозитории в системе Gitflic или Github. Работа над ВКР должна представлять собой не менее 50 коммитов от имени студента, происходящих в течение периодов прохождения преддипломной практики и подготовки ВКР. Коммиты должны отражать итеративное развитие проекта, то есть не просто создание целиком готовых файлов, а их изменение по мере развития функционала проекта.

4. Использование готовых универсальных кроссплатформенных фреймворков запрещается. Используемые средства разработки не регламентируются, однако рекомендуется использовать Android Studio для уменьшения проблем со сборкой приложения в аудитории.

5. Определить не менее 5 взаимосвязанных сущностей в рамках предметной области.

6. Для организации сущностей использовать модель MVC или MVVM.

7. Для организации интерфейса в файлах представлений использовать не менее одного макета ConstraintLayout.

8. Не менее одного макета представления сформировать как для портретного, так и для альбомного режима.

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

10. Контроллеры представлений выполнять с помощью класса Fragment и библиотеки поддержки androidx. Разработать взаимодействие фрагментов на разных этапах жизненного цикла.

11. У каждой сущности должна быть форма редактирования объекта, а также форма списка объектов, построенная на базе класса RecyclerView.

12. Обеспечить хранение данных приложения в СУБД, поддерживающей SQL- запросы. Допустимо использование библиотек ORM для упрощения доступа к данным. Рекомендуется использование SQLite.

13. Реализовать панель управления в приложении, где добавить не менее 5 пунктов меню.

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

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

16. В основной сущности должен быть реализован функционал доступа к файловой системе и получение изображений с камеры.

17. Реализовать взаимодействие основной сущности с внешним веб-сервисом.

4. Требования к разрабатываемому сетевому ресурсу (веб-сайта, порталу и т.п.)

1. Сетевой ресурс должен быть разработан с применением языков программирования – PHP, JavaScript или Python c использованием фреймворков Django / Flask.

2. Обязательна загрузка в ЭУ вместе с ВКР / выгрузка в репозиторий Gitflic или Github файлов веб-страниц в формате *.html, *.css, *.php, *.js (при необходимости архивируется вся папка проекта, с комментариями об используемых версиях) или файлами программного кода *.py (при необходимости архивируется вся папка проекта, с комментариями об используемых дополнительных библиотеках и версиях), если работа выполнялась с использованием языка программирования Python.

3. Работа над проектом должна вести в git-репозитории в системе Gitflic или Github. Работа над ВКР должна представлять собой не менее 50 коммитов от имени студента, происходящих в течение периодов прохождения преддипломной практики и подготовки ВКР. Коммиты должны отражать итеративное развитие проекта, то есть не просто создание целиком готовых файлов, а их изменение по мере развития функционала проекта.

4. Дополнительно сетевой ресурс должен быть размещен на бесплатном хостинге.

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

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

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

8. Разработать структуру Web-страниц. Сетевой ресурс должен содержать не менее 10 страниц.

9. Разработать макет каждой страницы сетевого ресурса.

10. Предусмотреть форму обратной связи.

11. Разработать не менее 10 пунктов бокового и/или верхнего меню, «хлебные крошки».

12. Обеспечить хранение данных приложения в СУБД, поддерживающей SQL- запросы.

13. Предусмотреть не менее 3-х ролей пользователей, например, администратор, менеджер, клиент. Предоставить учетные данных всех созданных пользователей.

14. Разработать панель администратора сетевого ресурса.

15. Разработать личный кабинет пользователя сетевого ресурса.

16. Обеспечить корректное отображение сетевого ресурса в основных браузерах (Mozilla Firefox, Chrome, Яндекс.Браузер, Microsoft Edge)

17. Обеспечить корректное отображение сетевого ресурса на разных устройствах (ПК, ноутбук, смартфон)

18. Текст статей в сетевом ресурсе должен быть читабельным, грамотно сформулированным, корректным и соответствовать предметной области ВКР. Не должно быть пустых страниц в сетевом ресурсе.

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

1. Интеллектуальный сервис разрабатывается на языке Python с использованием сервисов Google Colab или Yandex DataSphere.

2. Обязательна загрузка в ЭУ вместе с ВКР файла/ов программного кода *.ipynb (при необходимости архивируется вся папка проекта, с комментариями об используемых дополнительных библиотеках и версиях, а также с используемыми датасетами). Обязательна выгрузка в репозиторий Gitflic или Github файла/ов программного кода *.ipynb (при необходимости архивируется вся папка проекта, с комментариями об используемых дополнительных библиотеках и версиях, а также с используемыми датасетами)

3. Работа над проектом должна вести в git-репозитории в системе Gitflic или Github. Работа над ВКР должна представлять собой не менее 50 коммитов от имени студента, происходящих в течение периодов прохождения преддипломной практики и подготовки ВКР. Коммиты должны отражать итеративное развитие проекта, то есть не просто создание целиком готовых файлов, а их изменение по мере развития функционала проекта.

4. Объем собственноручно разработанного программного кода должен быть не менее 2 000 логических строк кода. Считаются только строчки алгоритмического кода, строки кода разметки типа HTML или JSON, пустые строки, строки комментариев, строки только с управляющими символами подсчету не подлежат.

5. Создаваемое приложение для демонстрации работы приложения обязательно должно позволять:

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

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

- загружать обученную модель из файла.

- применять обученную или загруженную модель по назначению

- оценивать и сохранять результаты работы модели для обучения новых версий модели

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

7. В git-репозитории должен присутствовать файл requirements.txt, описывающий список необходимых для работы приложения и модели библиотек, которые надо будет установить проверяющему в пустое виртуальное окружение. Файл необходимо положить в корневой каталог репозитория.

8. В git-репозитории должен присутствовать в корневом каталоге файл main.py, который запускает приложение для работы с моделью.

9. Все демонстрируемые в отчёте модели должны быть сохранены в сдаваемом git- репозитории в файле с названием model и расширением, которое удобно для конкретной выбранной архитектуры (например, модели на PyTorch сохраняются с расширением .pt, то есть будет model.pt). Если в отчёте демонстрируется больше 1 модели, то к названию файла добавляется порядковый номер (напр., model1, model2 и т.д.). При проверке будет ожидаться, что работать эти модели будут так же, как описано в отчёте.

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

11. При работе моделей, ожидается достижений уровня эффективности, сопоставимого с уровнем Accuracy >= 70. Если к конкретной модели в конкретной предметной области этот уровень не применим, то можно согласовать с руководителем работы другую метрику эффективности, отразив её в отчёте.

12. Реализация GUI интеллектуального сервиса может быть в виде «оконных» или web форм, а также с использованием возможностей чат-ботов по отрисовке интерфейсных компонентов. Конкретный формат GUI согласовывается с руководителем ВКР.

13. В ВКР обязательно должно быть математическое описание выбранной модели.

Методологические требования к разработке интеллектуального сервиса

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

2. Создание модели предполагает, что студент умеет применять основные способы создания моделей в программном коде, как в плане написания алгоритмов «с нуля», так и в плане использование стандартных готовых библиотек – от базовых библиотек типа NumPy и Pandas, до библиотек глубокого обучения типа PyTorch и Tensorflow.

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

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

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

6. Получение данных предполагает, что студент знает откуда вообще можно брать данные для обучения моделей. Знаком как с публичными ресурсами типа kaggle, так и с подходами к самостоятельной добыче данных через web-скрейпинг, публичные API или через коннекторы для подключения хранилищ на облачных сервисах.

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

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

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

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

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

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

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

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

15. Улучшение модели машинного обучение предполагает внесение изменений в модель с целью получить улучшенные результаты. От студента ожидается способность сформулировать предложение об улучшении модели по результатам первичного тестирования, обосновать его с помощью математического и визуального анализа, выполнить это улучшение (изменив параметры модели или пересоздав модель заново с новой топологией) и заново провести обучение и тестирование, оценив результаты улучшения (то есть фактически повторить весь путь с улучшенной моделью). Это должно быть отражено в ВКР.

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

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

6. Требования к разрабатываемому интерактивному графическому приложению (компьютерной игре)

1. Интерактивное графическое приложение разрабатывается на языке Python c использованием интерпретатора PyCharm или Google Colab.

2. Обязательна загрузка в ЭУ вместе с ВКР исполняемого *.exe файла и выгрузка в репозиторий Gitflic или Github файлов программного кода *.py (при необходимости  архивируется  вся  папка  проекта,  с  комментариями  об используемых дополнительных библиотеках и версиях) если работа выполнялась с использованием языка программирования Python, либо файла программного кода *.ipynb, если работа выполнялась с использованием языка программирования Python и сервисов Google Colab и Yandex DataSphere.

3. Работа над проектом должна вести в git-репозитории в системе Gitflic или Github. Работа над ВКР должна представлять собой не менее 50 коммитов от имени студента, происходящих в течение периодов прохождения преддипломной практики и подготовки ВКР. Коммиты должны отражать итеративное развитие проекта, то есть не просто создание целиком готовых файлов, а их изменение по мере развития функционала проекта.

4. Объем собственноручно разработанного программного кода должен быть не менее 2 000 логических строк кода. Считаются только строчки алгоритмического кода, строки кода разметки типа HTML или JSON, пустые строки, строки комментариев, строки только с управляющими символами подсчету не подлежат.

5. При описании внутренней архитектуры приложения, студент должен описать не менее 10 сущностей игровой системы (из которых минимум 5 должны быть реализованы самостоятельно) и не менее 5 игровых систем (из которых минимум 3 должны быть реализованы самостоятельно).

6. При описании интерфейса приложения, студент должен описать не менее 4 игровых экранов и не менее 15 элементов интерфейса на этих экранах (из которых не менее 8 взяты не в готовым виде, а реализованы самостоятельно). Элементом интерфейса считается любой интерфейсный объект, реагирующий на события в игровой системе (например, шкала здоровья или индикатор возможности действия) или сам инициирующий событийную цепочку по факту ввода от игрока (например, кнопка).

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

8. Для реализации приложения можно использовать любые игровые движки и middleware, при этом имея ввиду требование о реализации достаточного объёма собственного функционала поверх заимствованного.

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

10. Хранение сборок в самом git-репозитории не разрешается. Можно выгрузить сборки на любой внешний ресурс для скачивания или, что предпочтительнее, осуществить релиз своего приложения на специализированной площадке типа itch.io.

11. Необходимым условием является наличие сборки, которую можно запустить под Linux, для запуска на компьютерах Университета для проверки. Сборки только под Windows недостаточно. Если проект нельзя собрать для Linux или хотя бы для Web-запуска из браузера под Linux, то запускаемую сборку необходимо установить в соответствующий докер-контейнер.

Методологические требования к разработке интерактивного графического приложения

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

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

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

15. Определение требований к игровому приложению через требования научной модели используется когда целью работы ставится создание игровой модели какого-то сложного процесса. Примерами приложений, моделирующих подобные сложные процессы являются игровые приложения в стиле Microsoft Flight Simulator, Kerbal Space Program, Civilisation. Требования к игровому приложению в этом случае проистекают из требований к точности реализации и визуализации работы научной модели и описанных в этой модели процессов.

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

17. Если студент решает в своей работе определять требования к своему игровому приложению через призму требований научной модели, то от него будут ожидаться

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

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

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

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

Студент может использовать в своей работе бизнес-процессы Университета (и тогда специалистом может выступать руководитель работы) или внешней организации (и тогда специалист должен быть из внешней организации). Отсутствие доступа к специалисту делает невозможным определение требований к игровому приложению через дизайн-фокус.

20. Если студент решает в своей работе определять требования к своему игровому приложению через дизайн-фокус, то от него будут ожидаться:

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

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

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

22. Если студент решает в своей работе определять требования к своему игровому приложению как к коммерческому продукту, то от него будут ожидаться:

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

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

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

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

24. На этапе планирования от студента ожидаются:

a. Знания о типовых способах составления проектной документации для игрового приложения (далее «дизайн-документа»).

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

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

25. Спланировав первую версию приложения, студент переходит к его реализации. На этом этапе, от студента ожидаются:

a. Знания общих архитектурных схем, стандартных алгоритмов и типовых структур данных, позволяющих реализовать запланированное в дизайн- документе.

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

c. Владение инструментарием создания игровых приложений, будь то промежуточные библиотеки типа pygame или Ren’Py, или интегрированные решения типа Unity.

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

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

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

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

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