Содержание
Формирование оценки
Этапы выполнения курсовой контроля
Идея
В курсе балльно-рейтинговая система оценивания. Баллы (0-100) складываются из:
- (индивидуально) Полное прохождение онлайн-курса (0-40 баллов пропорционально степени прохождения, нужный балл в курсе указан в Таблице успехов) - Нужно пройти все модули https://developer.android.com/courses/android-basics-compose/course
- (группа) Выполнение курсовой (0-60 баллов)
О курсовой:
- Подготовка курсовой работы разбита на отдельные блоки (этапы).
- Работа ведется в FORGEJO репозитории проекта, доступ в который вам дает преподаватель.
- Вы работаете в репоизтории полностью самостоятельно.
- Результаты этапов сдаются в ветке main, сдавать их в виде Pull Request не нужно.
- Этап считается сданным, когда в таблице с текущим контролем он получает соответствующую отметку. Внимательно следите, чтобы эти отметки появлялись - от этого зависит объем вашей работы.
- За каждый сданный этап команда получает баллы. Баллы указаны в Таблице успехов.
- У каждого этапа есть срок, когда его необходимо сдать. Этот срок указан в заголовке в Таблице успехов.
- Если этап сдан без опоздания, то команда получает все баллы за этап.
- Если этап сдан с опозданием от необходимого срока, то команда получает половину (50%) от баллов за этап.
- Фраза в виде вики-страницы, означает, что задание сдается в виде вики-страницы в репозитории проекта. Иные варианты сдачи (аттач в письме, файл в репо, устно, в виде песни или танца ….) - не принимаются.
Общие советы по курсовой работе
Смысл данного курса - разработать приложение с перспективы потенциального пользователя. Это означает, что первичны вопросы (и оцениваются именно они):
- Удобства и понятности пользовательского интерфейса / сценария,
- Универсальности и стабильности работы приложения.
Следующие вопросы вторичны:
- Бакенды
- Модели машинного обучения,
- Базы данных.
Про юмор в курсовой - увы, наш предмет посвящен не развитию КВН, а более приземленным вопросам. Поэтому, требования из "Введения в нереляционные СУБД" актуальны и для этой курсовой .
Проверка стабильности работы приложений
Проверка приложений на стабильность работы будет выполнятся вручную и автоматизировано.
Вручную приложение будет собираться стандартным способом (Import project / Run) через
Android Studio Otter 3 Feature Drop | 2025.2.3
и эмулятор, указанный ниже.
Проверка будет происходить на ОС (X)Ubuntu 24.04
Если вы используете какие-либо нестандартные подходы к разработке / фреймворки / языки и тд (отличные от штатных технологий, которые может без доп. настроек переварить среда разработки выше), то ваша обязанность предоставить dockerfile, в котором будут настроены все зависимости и можно будет штатно (см. выше) собрать и запустить проект.
Для автоматизированной проверки будет использован скрипт https://bitbucket.org/mark_zaslavskiy/adfmp/src/master/monkey.sh
Эмулятор, на котором будут проверятся работы
Список этапов
Макет и сценарий использования
- Продемонстрирована работа Android Studio на вашем компьютере (в формате микроскринкаста работы helloworld).
- Скринкаст выложен в репо и / или на него дана ссылка
- Код приложения helloworld выложен в репозиторий (просто для проверки что есть доступ)
- Сформулированы реализуемые сценарии использования в виде вики-страницы.
- Нарисован макет пользовательского интерфейса в виде графа (по аналогии с прошлым семестром) и выложенн в репозиторий, макет показан на вики-странице, где также размещены сценарии использования приложения.
UI на заглушках
Результат:
- в репозитории установлен тег 0.5
- код приложения выложен в репозитории,
- есть .gitignore для Android Studio, в котором в числе прочего полностью добавлен каталог .idea (каталога .idea не должно быть в репо также как и промежуточных артефактов сборки),
- приложение собирается и запускается на эмуляторе и AS, обозначенных выше
- переходы работают, но данные отображаются только те, что захардкожены в элементах UI, приложение не падает с exception в ответ на любые действия пользователя.
- пакет приложения называется согласно теме курсов ( использование названия по умолчанию или не информативного названия будет ошибкой).
- в приложении есть экран About, где указаны авторы.
Окончательная версия приложения (она же App is ready)
Результат:
- в репозитории установлен тег 1.0
- выполнены требования «Ui на заглушках»
- код приложения выложен в репозитории, его можно скачать, собрать и запустить. При этом выполняются все сценарии использования, приложение работает стабильно.
- приложение собирается и запускается на эмуляторе, обозначенном выше,
- если для работы приложения нужны secrets, ключи или иные чувствительные данные, то авторы должны их предоставить в письме
- если в приложении есть механизм регистрации, то авторы должны добавить в приложение тестовый аккаунт и указать его данные в README.md
- У приложения есть иконка, корректное название в манифесте(согласно теме)
- В приложении есть или реальные, или демо данные. В последнем случае, данных должно быть достаточно для демонстрации всех сценариев использования.
Оценка сложности пользовательского интерфейса вашего приложения
Данное задание сдается ТОЛЬКО после принятого app is ready. Если у вас и так хватает баллов на нужную вам оценку, то делать это задание не нужно.
Руководство по измерению последовательности действий и оценки сложности UI
Результат: вики-страница
- с таблицой подсчета количества действий (суммарным),
- количеством действий по каждому виду взаимодействия (кликов/вводов текста/ нажатий на апп.кнопки и пр.), иллюстрирующие подсчет скриншоты.
- выводом о том, как можно упростить последовательность.
- макетом интерфейса, реализующим предыдущий пункт.
- краткое описание приложения - ближайшего аналога (ссылка на страницу приложения, название, пару предложений с описанием)
- аналогичным подсчетом количества действий для ближайшего аналога (включая скриншоты, иллюстрирующие подсчет)
- вывод по итогам сравнения с аналогом (Кто удобнее)
Примечание: вывод о том, что интерфейс упрощать не надо (так как он лучше аналога / по другим причинам) использовать нельзя :) Проявите фантазию (от вас не требуется эти фиксы реализовывать, достаточно только изобразить и кратко описать)
Пояснительная записка
- Пояснительная записка в электронном виде (
- Требования http://se.moevm.info/doku.php/staff:courses:application_development_for_mobile_platforms:course_work . Если вы какие-то задания не сделали и вас устраивает текущая оценка, то вы можете пропустить соответствующие разделы (задания для которых вы не сделали) в записке.
- Выложена в репозиторий в doc(x)/odt + pdf (в каталог docs, формат названия report_ФАМИЛИИ. )
- Соответствует требованиям оформления ВУЗа.
- Есть непустой список литературы.
- Нет разделов без текста.
- Все таблицы, рисунки и схемы имеют подпись.
- В списке литературы указана ссылка на ваш открытый репозиторий .
Формирование оценки
Допуск (зачет)
Необходимые условия (ЛЭТИ): Чтобы претендовать на оценку выше «Не аттестован»,
- в репозитории проекта должно быть не менее (10 / 15 / 20 - Удовл. / Хор / Отл) коммитов в абсолютном выражении в КОД ПРОЕКТА, созданных участником. (как считаются коммиты: https://se.moevm.info/doku.php/staff:courses:no_sql_introduction:mark#%D0%BC%D0%B8%D0%BD%D0%B8%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B5_%D1%83%D1%81%D0%BB%D0%BE%D0%B2%D0%B8%D1%8F_%D0%BF%D0%BE%D0%BB%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D1%8F_%D0%BB%D1%8E%D0%B1%D0%BE%D0%B9_%D0%BE%D1%86%D0%B5%D0%BD%D0%BA%D0%B8)
- у группы должно быть сдано задание «Пояснительная записка».
Дедлайны проверок
Все время - Московское.
- Мягкий дедлайн - 30.03.2026 10:00
- Жесткий дедлайн - 01.04.2026 10:00
- Срок окончательной проверки 01.04.2026 12:30
Как работают дедлайны:
- Все присланное до мягкого дедлайна будет проверено до наступления жесткого дедлайна
- Все присланное до жесткого дедлайна будет проверено до срока окончательной проверки
- Все присланное (Как и решения онлайн-курса) после жесткого дедлайна будет проигнонировано.
Оценка
Оценка выставляется только при получении зачета (см. выше).
Как баллы трансформируются в оценки (5-балльная система):
- <70 — Неудовлетворительно
- >=70 && <80 — Удовлетворительно
- >=80 && <90 — Хорошо
- >=90 — Отлично
Бонусы за публикацию в Rustore
Если команда успешно опубликовала (== оно прошло модерацию, его можно найти и скачать в магазине) свое приложение в Rustore, а также подготовило небольшую заметку с описанием приложения (для канала кафедры), то все участники получают +5/100 баллов.
Бонусы за олимпиаду
Бонусы за олимпиаду начисляются по аналогии с ВвНСУБД, но сроки более сжатые - информация принимается до 15 апреля, после этого срока бонус получить нельзя.
