Содержание
Формирование оценки
Этапы выполнения курсовой контроля
Идея
В курсе балльно-рейтинговая система оценивания. Баллы (0-100) складываются из:
- (индивидуально) Полное прохождение онлайн-курса (0-40 баллов пропорционально степени прохождения, нужный балл в курсе указан в Таблице успехов) - Нужно пройти все модули https://developer.android.com/courses/android-basics-compose/course
- (группа) Выполнение курсовой (0-60 баллов)
О курсовой:
- Подготовка курсовой работы разбита на отдельные блоки (этапы).
- Работа ведется в github репозитории проекта, доступ в который вам дает преподаватель.
- Вы работаете в репоизтории полностью самостоятельно.
- Результаты этапов сдаются в ветке main, сдавать их в виде Pull Request не нужно.
- Этап считается сданным, когда в таблице с текущим контролем он получает соответствующую отметку. Внимательно следите, чтобы эти отметки появлялись - от этого зависит объем вашей работы.
- За каждый сданный этап команда получает баллы. Баллы указаны в Таблице успехов.
- У каждого этапа есть срок, когда его необходимо сдать. Этот срок указан в заголовке в Таблице успехов.
- Если этап сдан без опоздания, то команда получает все баллы за этап.
- Если этап сдан с опозданием от необходимого срока, то команда получает половину (50%) от баллов за этап.
- Фраза в виде вики-страницы, означает, что задание сдается в виде вики-страницы в репозитории проекта. Иные варианты сдачи (аттач в письме, файл в репо, устно, в виде песни или танца ….) - не принимаются.
!! Внизу указано больше этапов, чем вам нужно выполнить. Не делайте лишней работы. !!
Общие советы по курсовой работе
Смысл данного курса - разработать приложение с перспективы потенциального пользователя. Это означает, что первичны вопросы (и оцениваются именно они):
- Удобства и понятности пользовательского интерфейса / сценария,
- Универсальности и стабильности работы приложения.
Следующие вопросы вторичны:
- Бакенды
- Модели машинного обучения,
- Базы данных.
Про юмор в курсовой
Увы, наш предмет посвящен не развитию КВН, а более приземленным вопросам. Поэтому, требования из "Введения в нереляционные СУБД" актуальны и для курсовой по «Разработке приложений для мобильных платформ».
Проверка стабильности работы приложений
Проверка приложений на стабильность работы будет выполнятся вручную и автоматизировано.
Вручную приложение будет собираться стандартным способом (Import project / Run) через
Android Studio Ladybug Feature Drop | 2024.2.2
и эмулятор, указанный ниже.
Если вы используете какие-либо нестандартные подходы к разработке / фреймворки / языки и тд (отличные от штатных технологий, которые может без доп. настроек переварить среда разработки выше), то ваша обязанность предоставить dockerfile, в котором будут настроены все зависимости и можно будет штатно (см. выше) собрать и запустить проект.
Для автоматизированной проверки будет использован скрипт https://bitbucket.org/mark_zaslavskiy/adfmp/src/master/monkey.sh
Эмулятор, на котором будут проверятся работы
Версия API 35
Экран
- hw.lcd.density 480
- hw.lcd.height 2856
- hw.lcd.width 1280
Остальное
- avd.ini.displayname Pixel 9 Pro API 35
- avd.ini.encoding UTF-8
- AvdId Pixel_9_Pro_API_35
- disk.dataPartition.size 2G
- fastboot.chosenSnapshotFile
- fastboot.forceChosenSnapshotBoot no
- fastboot.forceColdBoot no
- fastboot.forceFastBoot yes
- hw.accelerometer yes
- hw.arc false
- hw.audioInput yes
- hw.battery yes
- hw.camera.back virtualscene
- hw.camera.front emulated
- hw.cpu.ncore 2
- hw.device.hash2 MD5:73e7b35d09e3a8055043aca4688e0dad
- hw.device.manufacturer Google
- hw.device.name pixel_9_pro
- hw.dPad no
- hw.gps yes
- hw.gpu.enabled yes
- hw.gpu.mode auto
- hw.initialOrientation portrait
- hw.keyboard yes
- hw.mainKeys no
- hw.ramSize 11548
- hw.sdCard yes
- hw.sensors.orientation yes
- hw.sensors.proximity yes
- hw.trackBall no
- image.androidVersion.api 35
- image.sysdir.1 system-images/android-35/google_apis_playstore/x86_64/
- PlayStore.enabled true
- runtime.network.latency none
- runtime.network.speed full
- showDeviceFrame yes
- skin.dynamic yes
- tag.display Google Play
- tag.displaynames Google Play
- tag.id google_apis_playstore
- tag.ids google_apis_playstore
- vm.heapSize 256
Список этапов
Макет и сценарий использования
- Продемонстрирована работа 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
Результат: вики-страница
- с таблицой подсчета количества действий (суммарным),
- количеством действий по каждому виду взаимодействия (кликов/вводов текста/ нажатий на апп.кнопки и пр.), иллюстрирующие подсчет скриншоты.
- выводом о том, как можно упростить последовательность.
- макетом интерфейса, реализующим предыдущий пункт.
- краткое описание приложения - ближайшего аналога (ссылка на страницу приложения, название, пару предложений с описанием)
- аналогичным подсчетом количества действий для ближайшего аналога
- вывод по итогам сравнения с аналогом (Кто удобнее)
Примечание: вывод о том, что интерфейс упрощать не надо (так как он лучше аналога / по другим причинам) использовать нельзя :) Проявите фантазию (от вас не требуется эти фиксы реализовывать, достаточно только изобразить и кратко описать)
Создание юнит-тестов для приложения
Результат:
- тег unit
- в репозитории выложены файлы юнит-тестов (не менее 3х TestCase ) для основных классов, которые можно запустить стандартным способом через Android studio,
- в репозитории настроен автоматический запуск юнит-тестов по коммитам через Github actions.
Если вам кажется, что для вашего приложения юнит-тесты не сделать - это означает, что либо оно еще слишком сырое (в нем только заглушки), либо что вы не отделили бизнес-логику от интерфейсов.
Пояснительная записка
- Пояснительная записка в электронном виде (
- Требования http://se.moevm.info/doku.php/staff:courses:application_development_for_mobile_platforms:course_work . Если вы какие-то задания не сделали и вас устраивает текущая оценка, то вы можете пропустить соответствующие разделы (задания для которых вы не сделали) в записке.
- Выложена в репозиторий в doc(x)/odt + pdf (в каталог docs, формат названия report_ФАМИЛИИ. )
- Соответствует требованиям оформления ВУЗа.
- Есть непустой список литературы.
- Нет разделов без текста.
- Все таблицы, рисунки и схемы имеют подпись.
- В списке литературы указана ссылка на ваш открытый репозиторий .
Создание интеграционных тестов для приложения
Интеграционные тесты == espresso-тесты (каюсь, термин не совсем удачный)
Результат:
- тег integrationtests
- в репозитории выложены файлы интеграционных тестов для основных сценариев использования, которые можно запустить стандартным образом (как Android InstrumentedTest), либо скрипт для запуска (например, если это тесты для игры);
- тесты стабильно выполняются при нескольких запусках подряд на эмуляторе, обозначенном выше;
- тесты проверяют работу приложения преимущественно через его UI;
Если в вашем приложении сложно писать интеграционные тесты, возможно, у вас есть проблемы с UI (он плохо показывает состояния приложения) и/или с архитектурой.
Материалы для публикации
Подготовьте материалы, необходимые для публикации приложения в Play Market.
- краткое описание, 80 символов;
- полное описание, не более 4000 символов;
- иконка( 512 x 512 32-bit PNG (with alpha));
- Feature Graphic 1024 w x 500 h, JPG or 24-bit PNG (no alpha);
- три скриншота.
Материалы необходимо выложить в репозитории в каталог play_market_publication/
Формирование оценки
Допуск (зачет)
Необходимые условия (ЛЭТИ): Чтобы претендовать на оценку выше «Не аттестован»,
- в репозитории проекта должно быть не менее (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
- Срок окончательной проверки 02.04.2026 14:00
Как работают дедлайны:
- Все присланное до мягкого дедлайна будет проверено до наступления жесткого дедлайна
- Все присланное до жесткого дедлайна будет проверено до срока окончательной проверки
- Все присланное (Как и решения онлайн-курса) после жесткого дедлайна будет проигнонировано.
Оценка
Оценка выставляется только при получении зачета (см. выше).
Как баллы трансформируются в оценки (5-балльная система):
- <70 — Неудовлетворительно
- >=70 && <80 — Удовлетворительно
- >=80 && <90 — Хорошо
- >=90 — Отлично
Бонусы за олимпиаду
Бонусы за олимпиаду начисляются по аналогии с ВвНСУБД, но сроки более сжатые - информация принимается до 15 апреля, после этого срока бонус получить нельзя.