Инструменты пользователя

Инструменты сайта


staff:courses:application_development_for_mobile_platforms:mark

Формирование оценки

Этапы выполнения курсовой контроля

Идея

В курсе балльно-рейтинговая система оценивания. Баллы (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

Эмулятор, на котором будут проверятся работы

Нажмите, чтобы отобразить

Нажмите, чтобы скрыть

  • Properties
  • avd.ini.displayname Medium Phone API 36.1
  • avd.ini.encoding UTF-8
  • AvdId Medium_Phone_API_36.1
  • disk.dataPartition.size 6G
  • 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 7
  • hw.device.hash2 MD5:2016577e1656e8e7c2adb0fac972beea
  • hw.device.manufacturer Generic
  • hw.device.name medium_phone
  • hw.dPad no
  • hw.gps yes
  • hw.gpu.enabled yes
  • hw.gpu.mode auto
  • hw.gyroscope yes
  • hw.initialOrientation portrait
  • hw.keyboard yes
  • hw.lcd.density 420
  • hw.lcd.height 2400
  • hw.lcd.width 1080
  • hw.mainKeys no
  • hw.ramSize 2048
  • hw.sdCard yes
  • hw.sensors.light yes
  • hw.sensors.magnetic_field yes
  • hw.sensors.orientation yes
  • hw.sensors.pressure yes
  • hw.sensors.proximity yes
  • hw.trackBall no
  • image.sysdir.1 system-images/android-36.1/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
  • target android-36.1
  • vm.heapSize 336

Список этапов

Макет и сценарий использования

Руководство

  • Продемонстрирована работа 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

Результат: вики-страница

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

Примечание: вывод о том, что интерфейс упрощать не надо (так как он лучше аналога / по другим причинам) использовать нельзя :) Проявите фантазию (от вас не требуется эти фиксы реализовывать, достаточно только изобразить и кратко описать)

Пояснительная записка

  1. Пояснительная записка в электронном виде (
    1. Требования http://se.moevm.info/doku.php/staff:courses:application_development_for_mobile_platforms:course_work . Если вы какие-то задания не сделали и вас устраивает текущая оценка, то вы можете пропустить соответствующие разделы (задания для которых вы не сделали) в записке.
    2. Выложена в репозиторий в doc(x)/odt + pdf (в каталог docs, формат названия report_ФАМИЛИИ. )
    3. Соответствует требованиям оформления ВУЗа.
    4. Есть непустой список литературы.
    5. Нет разделов без текста.
    6. Все таблицы, рисунки и схемы имеют подпись.
    7. В списке литературы указана ссылка на ваш открытый репозиторий .

Формирование оценки

Допуск (зачет)

Необходимые условия (ЛЭТИ): Чтобы претендовать на оценку выше «Не аттестован»,

Дедлайны проверок

Все время - Московское.

  • Мягкий дедлайн - 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 баллов.

Бонусы за олимпиаду

staff/courses/application_development_for_mobile_platforms/mark.txt · Последнее изменение: mark