Какого требования к функционалу нет в задании на мобильное приложение 2 абитуриенты
Области, расположенные в верхнем и нижнем поле каждой страницы документа, которые обычно содержат повторяющуюся информацию:
Вопрос 5
b. совокупность методов, производственных процессов и программно-технических средств для обработки данных
Вопрос 6
Двоичный код каждого символа при кодировании текстовой информации (в кодах ASCII) занимает в памяти персонального компьютера:
Вопрос 7
Какое максимальное количество рабочих листов Excel может содержать рабочая книга?
Вопрос 8
a. рабочее место консультанта по предметным приложениям и автоматизации предприятия
c. компьютер, оснащенный предметными приложениями и установленный на рабочем месте
Вопрос 9
Какой принцип является основополагающим при создании и развитии автоматизированной информационной системы?
Вопрос 10
Команды меню Формат в текстовом процессоре MS Word позволяют осуществить действия:
Вопрос 11
Вопрос 12
a. система упРавления базами данных, экспертные системы, системы автоматизации проектирования
b. операционные системы, системы программирования, программы технического обслуживания
c. совокупность универсальных пакетов прикладных программ
Вопрос 13
Какая единица измерения обычно связана с разрешением графики?
Вопрос 14
В развитии информационных технологий произошло следующее число революций:
Вопрос 15
Текстовый процессор – это программа, предназначенная для:
a. ввода, редактирования и форматирования текстовых данных
c. автоматического перевода с символических языков в машинные коды
Вопрос 16
c. выполнение программы без вмешательства пользователя
Вопрос 17
Вопрос 18
a. описание объекта с помощью математической модели
b. описание объекта с помощью информационной модели
c. рассмотрение объекта как целого, состоящего из частей и выделенного из окружающей среды
Вопрос 19
b. предварительно обработанные данные, годные для принятия управленческих решений
Вопрос 20
Вопрос 21
Какая часть шифра ОС напрямую взаимодействует с оборудованием компьютера?
Вопрос 22
Какую программу можно использовать для проведения мультимедийной презентации?
Вопрос 23
Какое периферийное устройство является запоминающим устройством, соединенным с интерфейсом USB, и позволяющим сохранять и перемещать файлы между компьютерами?
Вопрос 24
Объект, позволяющий создавать формулы в документе MS Word, называется:
Вопрос 25
Вопрос 26
Вопрос 27
Вопрос 28
a. система, предназначенная для выдачи аналитических отчетов
b. система, включающая в себя различные информационные сети
c. система, созданная на основе международных стандартов
Вопрос 29
В каких случаях, и с какой целью создаются базы данных?
a. когда необходимо отследить, проанализировать и хранить информацию за определенный период времени
b. когда необходимо быстро найти какой-либо файл на компьютере
c. когда винчестер компьютера имеет небольшой размер свободной памяти
Вопрос 30
Сетевой техник должен установить на компьютер новую ОС. Какой метод установки следует использовать, чтобы сохранить данные, настройки приложений и параметры конфигурации, а также уже существующее разбиение?
Никто не любит наступать на одни и те же грабли. Чтобы избегать их на этапе анализа и тестирования требований, мы завели общую шпаргалку. Она включает в себя те вопросы, которые в идеале должны быть выявлены и зафиксированы до разработки. Мы используем её как чек-лист, с помощью которого стараемся глубже вникнуть в логику мобильного приложения и разобраться, какие потенциальные проблемы могут возникнуть у пользователя.
Статья ориентирована на тестировщиков, которых просят провести ревью ТЗ и найти в нём несоответствия, и на аналитиков, которым разработчики после прочтения ТЗ часто задают вопросы формата: «А что должно быть, если …?».
Итак, с чего начать?
Общие вопросы по приложению
Тут все просто, но лучше никогда не забывать уточнять эти вопросы у менеджеров проектов и аналитиков.
- Для каких платформ будет разрабатываться приложение и какие версии ОС будут поддерживаться? Необходимо всегда помнить о минимальной поддерживаемой версии ОС. Иначе можно обнаружить, что функциональность не работает у пользователей, когда задача уже закрыта.
- На каких устройствах необходимо проверить приложение? Например, приложение должно работать как на смартфонах, так и на планшетах. Или должна быть поддержка Apple Watch.
- Какую ориентацию экранов поддерживает приложение? Портретная и/или ландскейп? Неприятный момент: если смена ориентации экрана хорошо работает на смартфонах, это не значит, что всё будет так же на планшетах.
- На каких девайсах приоритетнее всего смотреть? На ваших девайсах приложение может идеально работать, а вот у заказчика на любимом (вставьте китайский android-смартфон) все разъехалось.
- Должен быть идеальный пиксель-перфект или допускаются некоторые погрешности? Привет, тестирование на соответствие макетам! Ещё неплохо уточнить, должна ли растягиваться вёрстка или под каждый размер экрана должны быть свои макеты?
- Существуют ли другие клиентские приложения? Например, есть админка, которая внезапно начнет удалять или добавлять элементы. Или веб-версия, которая существует уже в продакшене. Главное – узнать об этом как можно раньше.
- Есть ли какие-то внешние устройства, которые могут повлиять на логику мобильного приложения? Например, beacon'ы, отправляющие сигналы приложению, или принтеры, печатающие информацию из приложения.
- Какая целевая аудитория у приложения? Все пользователи в Play Market/AppStore или 50 человек в компании заказчика?
Разбор приложения по экранам
- Состав экрана и возможные действия на нем. Из каких элементов состоит экран? Какие действия можно совершить? Какие состояния экрана возможны? Какие есть переходы и на какие экраны они ведут? Что должно отображаться при возврате на этот экран? Ответы на эти вопросы необходимо найти, а лучше зафиксировать в документации.
- Взаимодействие с сервером на экране. Какие запросы идут на экране? Понимание того, какие запросы на сервер отправляются на экране, поможет выявить такие требования, которые не сможет реализовать сервер по тем или иным причинам.
- Активность по таймеру. Например, отправляется важная аналитика раз в две минуты или идет обновление данных.
- Кэширование данных. Загрузка одних и тех же данных при каждом входе на экран может раздражать пользователей. При кэшировании необходимо продумать, когда должна обновляться информация на экране? Когда должен очищаться кэш?
- Заглушки. Что отображается, если данных нет? Пустой экран – неинформативный для пользователя. А съехавшая заглушка может быть поводом для недовольства заказчика.
- Поведение в случаях ошибки. Что должно отображаться, если произошла ошибка? Например, отсутствие интернета, серверная или незадокументированная ошибка.
- Медленная загрузка данных. Что должно происходить при медленной загрузке данных? Лоадеры, блокировка действий, кастомные анимации – всё должно быть продумано.
- Действия, которые влияют на поведение других экранов. Как действие на одном экране повлияет на поведение на других? Сквозные действия – опасная штука. Особенно, если разработка и тестирование идет по экранам или по отдельным фичам. Тут без регрессии обойтись сложно. Поэтому на некоторых проектах, прежде чем писать тест-кейсы, мы строим матрицу влияния для новых фич.
- Обновление данных на экране. Когда происходит обновление? Есть следующие варианты и они могут сочетаться:
- Каждый раз при открытии экрана (данные живут только пока у пользователя открыт экран).
- Каждый раз при запуске приложения (данные живут только пока у пользователя запущено приложение).
- По pull-to-refresh'у/по специальной кнопке обновления/по таймеру (данные хранятся в локальном хранилище устройства и при перезапуске приложения восстанавливаются).
Далее рассмотрим функциональность, которая часто используется в приложениях.
Навигация в приложении
- С помощью бокового меню. Какие разделы являются корневыми? Какие разделы открываются поверх корневых? Сбрасывается ли история переходов между корневыми разделами?
- С помощью таббара. Остаётся ли таббар на экране при углублении по навигации внутри раздела? Возвращает ли на корневой экран при повторном тапе на разделе?
- Различие в переходах между аппаратной и программной кнопкой «Back» в Android.
Локализация
Виды поддерживаемой локализации:
- Тексты зашиты внутри приложения. Пользователь в настройках приложения может выставить необходимый язык.
- Тексты зависят от языка в системных настройках. Язык определяется в зависимости от установленного языка в системных настройках.
- Тексты приходят с сервера. Тексты приходят с сервера, и язык зависит либо от настроек устройства, либо от настроек приложения.
Разрешения
- Запрос на доступ к нотификациям, геолокации, галерее, камере, смс… Кастомный экран или просто системный алерт?
- Пользователь отказался предоставить доступ. Как приложение поведет себя в этом случае? Предусмотрена ли логика перезапроса на доступ?
- Пользователь отключил в системных настройках доступ (см. пункт выше).
Списки
Часто мобильные приложения включают в себя списки. Для них стоит обратить внимание на следующие моменты:
- Первая загрузка списка. Сколько элементов загружаются за один раз? Что происходит при загрузке? Какое максимальное время может загружаться список?
- Наличие пэйджинга. Есть ли подгрузка элементов при скролле или весь список загружается за раз? Если есть подгрузка, то обязательно надо проверить, что элементы на границах не пропадают и не дублируются.
- Обновление списка (см. варианты выше).
- Наличие разделов.
- Наличие фильтров/сортировок. Фильтр может быть локальным или серверным. Для списков, которые загружаются целиком или зашиты внутри приложения, фильтры чаще всего локальные, и тестирование их не вызывает особых трудностей. Для списков с подгрузкой фильтры могут повлечь большое количество проверок. Аналогично для сортировок.
- Состав каждого элемента в списке. Тут может быть как элементарный текст, так и целые экраны со своей внутренней логикой.
- Взаимодействие с элементами. Добавление нового элемента, удаление, скрытие, перетаскивание.
- Синхронизация списка между всеми устройствами. В качестве примера можно привести синхронизацию файлов после его изменения на всех устройствах.
- Сохранение позиции скролла. При переходах между разделами или при возвращении на экран со списком может быть очень важной фичей. Например, если это лента постов.
Поиск по списку
- Онлайн/оффлайн поиск. С оффлайновым поиском всё просто. По сути, это локальный фильтр. Для онлайнового поиска, так же как и для онлайновых фильтров, кейсов будет гораздо больше.
- Посимвольный поиск или поиск по нажатию на кнопку поиска. Обратите внимание, для посимвольного поиска должно быть ограничение на количество запросов, иначе сервер может начать игнорировать спам от приложения.
- Очистка поисковой строки.
- Наличие подсказок.
- Наличие истории запросов.
Форма ввода
- Перечень полей с их описанием и особенностями.
- Условия сохранения и сброса данных в полях. Когда и какие поля должны сохранять свои значения? Когда очищаться?
- Ограничения на количество и вид символов.
- Клавиатура для ввода данных по выбранному полю. Вид клавиатуры: цифровая или символьная. Должна ли клавиатура сдвигать контент при открытии? При каких условиях она должна закрываться?
- Логика переходов между полями. По кнопке «Далее», по «Next» на клавиатуре.
- Валидация некорректно введенных данных. Проверки на сервере или на клиенте.
- Автозапросы на сервер при определенных условиях. Например, если пользователь ввел 6-значный код подтверждения.
Учетные записи
- Создание учетной записи при первой авторизации через соцсеть.
- Подгрузка данных из соцсети. Синхронизация при их изменении в соцсети. Например, имя-фамилия пользователя и аватарка.
- Авторизация через мобильное приложение, соцсети или браузер/вебвью.
- Запрет доступа приложению к данным из соцсети.
Ролевая модель
- Описание ролевой модели. Какие действия доступны для каждой роли?
- Взаимодействие между представителями разных ролей. Взаимодействие между представителями одной роли.
- Переход пользователей от одной роли к другой. Какие действия для этого должны выполниться?
- Предполагаемое процентное соотношение представителей разных ролей. На какую роль обратить внимание в первую очередь?
Карта
- Первая загрузка карты. Какая область должна загрузиться? Где и в каком масштабе должна быть отцентрирована карта?
- Загрузка и отрисовка элементов. Должны ли загруженные элементы кэшироваться? Когда элементы должны обновляться? Этот момент очень важно продумать, чтобы обеспечить быструю загрузку данных и плавные перемещения по карте.
- Логика работы элементов на карте. Пины, попапы над пинами, карточки для пинов, построение маршрута.
- Поддержка масштабирования, вращения, наклона карты.
- Обновление геопозиции и отправка координат текущего местоположения при свернутом приложении.
Отправка файлов на сервер и скачивание на устройство
- Формат файлов. Какие форматы файлов система должна обрабатывать и на какие выдавать ошибку?
- Возобновление прерванной отправки/скачивания. Автоматическое или после подтверждения пользователя?
- Максимальное количество отправляемых/закачиваемых файлов.
- Нехватка памяти на устройстве для скачивания файла. На практике были случаи, когда памяти не хватает, чтобы не просто скачать файл, а даже сделать запись в базу данных. Такие проблемы приходилось обрабатывать.
- Отмена отправки/скачивания файла.
- Замена файла один на другой.
- Скачивание на внешнюю память SD Card.
- Скачивание в фоне при свернутом приложении.
Внешние устройства
- Подключение/отключение устройства. Канал связи, по которому оно взаимодействует с приложением (Wi-Fi/Bluetooth).
- Влияние внешнего устройства на логику приложения.
- Конфигурация внешнего устройства. Есть ли какие-то системы, которые администрируют внешнее устройство?
- Максимальное расстояние, на котором происходит взаимодействие.
- Сила/мощность сигнала. Выясните, от чего могут зависеть эти параметры? Например, если beacon спрятать в металлическую банку, то шансы на потерю его сигнала резко возрастает.
- Подключение нескольких внешних устройств одновременно. Например, переключение с одного устройства на другое может привести к любопытным кейсам.
- Подключение к внешнему устройству при свёрнутом приложении/при заблокированном экране.
Аудиоплеер/видеоплеер
- Поддерживаемые форматы файлов.
- Кэширование проигрываемого контента. Обязательно нужно понять, какой объем данных необходимо кэшировать для удобства пользователя.
- Проигрывание в фоне. Нужна ли подгрузка данных при свернутом приложении?
- Нотификация плеера в системной шторке.
- Интеграция с Bluetooth-гарнитурой, CarPlay и с другими внешними системами.
Оплата банковской картой
- Привязка к профилю и удаление банковской карты. Есть ли тестовое снятие минимальной суммы? Например, 1 рубль, который потом вернется на счет.
- Оплата привязанной картой. Например, будет ли повторный запрос на смс-подтверждение при последующих оплатах?
- Обработка ошибок при попытке привязать/оплатить по карте.
- Синхронизация списка карт при наличии нескольких клиентов в системе. Например, есть веб-версия и есть iOS-версия.
- Сканирование через камеру и распознавание номера карты.
Время, календарь, таймер
- Календарь/время. Влияет ли на логику приложения некорректно выставленная дата и время? Можно ли выбрать период? Какая область допустимых значений?
- Таймер. Локальный/серверный? Как происходит синхронизация серверного таймера? Например, в Android приложение может ориентироваться не на время, установленное на устройстве, а на время запуска устройства. Как бы пользователь не переводил часы в системных настройках, таймер не собьется.
Нотификации
- Вид нотификаций. Есть ли нотификации на определенные события, которые зашиты в приложение? Или push-нотификации, которые присылает сервер?
- Действия, которые доступны при нотификации. Что будет, если перейти по нотификации? Закрыть её? Что если нотификация устарела и она недоступна?
- Привязка нотификаций к определенной учетке. Какие действия указывают серверу, что один пользователь вышел и зашел другой?
Безусловно, в этой шпаргалке покрыта далеко не вся возможная функциональность мобильных приложений. У нас она служит отправной точкой для начала тест-анализа. Делитесь в комментариях своими кейсами или шпаргалками, которые вам помогают в тестировании требований.
В настоящем документе приводится полный набор требований к реализации мобильного приложения и сайта.
Подпись Заказчика и Исполнителя на настоящем документе подтверждает их согласие с нижеследующими фактами и условиями:
- Исполнитель подготовил и разработал настоящий документ, именуемый Техническое Задание, который содержит перечень требований к выполняемым работам.
- Заказчик согласен со всеми положениями настоящего Технического Задания.
- Заказчик не вправе требовать от Исполнителя в рамках текущего Договора выполнения работ либо оказания услуг, прямо не описанных в настоящем Техническом Задании.
- Исполнитель обязуется выполнить работы в объёме, указанном в настоящем Техническом Задании.
- Заказчик не вправе требовать от Исполнителя соблюдения каких-либо форматов и стандартов, если это не указано в настоящем Техническом Задании.
- Все неоднозначности, выявленные в настоящем Техническом задании после его подписания, подлежат двухстороннему согласованию между Сторонами.
- В процессе согласования могут быть разработаны дополнительные требования, которые оформляются дополнительным соглашением к Договору и соответствующим образом оцениваются.
- Требования к графическому дизайну сайта
3.1 Требования к дизайну сайта
Оформление должно быть разработано в достаточно консервативном ключе.
На страницах недолжно быть большого объема текста.
В дизайне сайта не должны присутствовать:
Рис. Пример формы авторизации
3.2 Порядок утверждения дизайн-концепции
Под дизайн-концепцией понимается вариант оформления главной страницы и графическая оболочка внутренних страниц, демонстрирующие общее визуальное (композиционное, цветовое, шрифтовое, навигационное) решение основных страниц сайта. Дизайн-концепция представляется в виде файла (нескольких файлов) в растровом формате или в распечатке по согласованию сторон.
В этом случае Исполнитель разрабатывает второй вариант дизайн-концепции (дорабатывает, вносит изменения). Обязательства по разработке второго варианта дизайн-концепции Исполнитель принимает только после согласования и подписания дополнительного соглашения о продлении этапа разработки дизайн-концепции на срок не менее пяти рабочих дней. Дополнительные (третий и последующие) варианты разрабатываются Исполнителем за отдельную плату на основании дополнительных соглашений.
4.1 Классы пользователей
3) Администратор – пользователь, авторизованный в интерфейсе сайта
4.2 Требования к представлению мобильного приложения
Требования к представлению главной страницы мобильного приложения.
Главная страница мобильного приложения должна содержать графическую часть, навигационное меню сайта (у пользователя появляются списки меню в нижней части приложения и в боковой части, который открывается с помощью слайдера пальцем.), а также контентную область для того, чтобы посетитель мобильного приложения с первой страницы мог получить вводную информацию об актуальных развлечениях, транспорте, питании и путевки, а также ознакомиться с последними новостями.
В нижней части экрана должно располагаться горизонтальное меню и включать разделы: Транспорт, Питание, Развлечение, Проживание.
Контентная часть главной странице мобильного приложения должна включать:
Требования к отображению раздела «проживание».
При переходе пользователя на раздел «проживание» пользователю в верхней части экрана
- должен присутствовать поиск (в котором пользователь может задать город, в который он хочет поехать);
- ниже должна быть возможность выбрать дата заезда и дату отъезда;
- рядом должна быть опция выбора количества взрослых, количества номеров и количества детей;
- Разделы с отелями, хостелами, домами, гостиницами;
- Во всей остальной части экрана слева должна отображаться фотография места, рядом с правой стороны должны быть написано название места, количество звездочек, отзывы, соотношение цены и качества, спецпредложение;
- С правой стороны должна отображаться цена, агент (который предоставил информацию, и кнопка посмотреть).
Требования к внутренним страницам раздела проживание.
- стрелка, чтобы вернуться на страницу разделов. Должна присутствовать опция поделиться с друзьями и добавить в избранное.
- во всю ширину должен располагаться слайдер с фотографиями данного места, справой стороны должна располагаться кнопка поделиться и сохранить в закладки.
- название места, количество звездочек, количество отзывов, выбор дата заезда и отъезда (с выбором дат на карте)
- Ниже должна быть написана цена и спецпредложение. Чуть ниже должна присутствовать информация о отеле (хостеле, дома отдыхе и тд).
Требования к отображению раздела «развлечения».
При переходе пользователя на раздел «развлечения» пользователю
- в верхней части экрана должен отображаться поиск (в котором пользователь может задать развлечение, которое он хочет выбрать)
- Должны присутствовать разделы с самыми лучшими развлечениями, раздел с индивидуальными экскурсиями, раздел с общими экскурсиями, раздел с пешими экскурсиями, раздел с экстремальными экскурсиями.
- Во всей остальной части экрана слева должна отображаться фотография места, рядом с правой стороны должны быть написано название места, количество звезд, отзывы, соотношение цены и качества, спецпредложение;
Требования к внутренним страницам раздела «развлечения».
- стрелка, чтобы вернуться на страницу разделов. Должна присутствовать опция поделиться с друзьями и добавить в избранное.
- во всю ширину должен располагаться слайдер с фотографиями данной экскурсии;
- название места, количество звездочек, количество отзывов, выбор дата заезда и отъезда (с выбором дат на карте);
- Ниже должна быть написана цена и спецпредложение. Чуть ниже должна присутствовать информация о отеле (хостеле, дома отдыхе и тд).
Требования к разрабатываемому разделу «транспорт»
- Должны присутствовать разделы-выборы авиа-билеты, жд билеты, вызов такси, аренда автобуса;
- В разделе авиабилеты должен быть календарь с выбором дата отчета и прилета, пунктом отправления и пунктом назначения, класс
- В разделе авто должны присутствовать выбор тип авто: эконом, «люкс», «комфорт»
Требования к разрабатываемому разделу «питание»
- Вызов питания на дом
- Заказ столика в ресторане
Требования к внутренним страницам раздела «питание».
- стрелка, чтобы вернуться на страницу разделов. Должна присутствовать опция поделиться с друзьями и добавить в избранное.
- во всю ширину должен располагаться слайдер с фотографиями данной экскурсии;
- название места, количество звездочек, количество отзывов,
- ниже должна быть написана цена.
Требования к внутренним страницам раздела «личный кабинет».
- После регистрации пользователя у него создается личный кабинет.
- У пользователя появляются списки меню в нижней части приложения и в боковой части, который открывается с помощью слайдера пальцем.
- Личный кабинет пользователя находится в боковой части экрана. Там должна быть возможность выбрать фотографию пользователю, выбрать перейти в раздел редактирования личного кабинете. Добавления данных кредитной карты, добавления информации, включения галочки пуш уведовлений.
- К личному кабинету прикрепляется мониторинг действий (возможно гугл метрика).
- На основании активности пользователя формируется релевантные предложения
Требования к странице «оплата».
Оплата путевки, тура, экскурсии, снаряжения и тд.
Оплата авиа, жд билетов.
- Оплата билетов происходит с помощью iframe, который выводится после нажатия на кнопку оплатить.
- В iframe передаются параметры: фамилия, имя, отчество, данные кредитной карты.
- После оплаты возвращается callback в мобильное приложение.
Требования к структуре сайта
- Сайт создается с целью внесения в ручном режиме информации на сайт.
- Для выгрузки отчетности
Пользователи группы «Администратор-владелец» могут редактировать все поля. Пользователи группы «Администратор-аналитик» могут выгружать информацию, но не могут редактировать и просматривать информацию о клиентах.
Пользователи могут авторизоваться в мобильном приложении, в форме авторизации должны присутствовать:
- Текстовое поле для ввода логина пользователя
- Кнопка отправки формы.
Данные для доступа (авторизации):
- Логин – адрес электронной почты пользователя
- Пароль – строка содержащая от 8 символов, состоящая из A-z, 0-9.
Ниже формы располагаются ссылка:
Форма «Забыли пароль» содержит поля:
- Email адрес пользователя, указанный при регистрации
При неудачной попытке авторизации – появляется приглашение для повторной попытки
авторизоваться с формой авторизации.
Списки рассылок и уведомления
Авторизованные пользователи могут управлять своими списками рассылок, а также
просматривать полученные уведомления.
- Добавить рассылку
- Удаление рассылку
- Редактирование рассылку
- Просмотреть список рассылок
- Подписаться на список рассылок
- Отписать от списка рассылок
- Просмотреть уведомления
4.4 Требования к разделению доступа
5.1 Требования к информационному обеспечению
Требования к хранению данных
Все данные сайта должны храниться в структурированном виде под управлением реляционной
СУБД. Исключения составляют файлы данных, предназначенные для просмотра и скачивания
(изображения, видео, документы и т.п.). Такие файлы сохраняются в файловой системе, а в БД
размещаются ссылки на них.
Наполнение различных сайтов, функционирование которых поддерживается одной и той же
инсталляцией системы, должно храниться под управлением единой СУБД.
Требования к языкам программирования
Для реализации статических страниц и шаблонов должны использоваться языки HTML 4.0 и CSS.
Исходный код должен разрабатываться в соответствии со стандартами W3C (HTML 4.0).
Для реализации интерактивных элементов клиентской части должны использоваться языки
JavaScript и DHTML.
Для реализации динамических страниц должен использоваться язык PHP.
Для разработки мобильного приложения должен быть использован ReactJS
Требования к организации гиперссылок
Все ссылки в мобильном приложении должны быть относительными (за исключением внешних).
Требования к иллюстрациям
Все рисунки и фото объемом более 1 kb (кроме элементов дизайна страницы) должны быть
выполнены с замещающим текстом. Все рисунки должны быть в формате gif или jpg.
Требования к объему одной страницы
Объем одной стандартной загружаемой страницы сайта в среднем не должен превышать 170 kb.
5.2 Требования к программному обеспечению
- Операционная система семейства Unix (Linux, FreeBSD и пр.)
- Веб-сервер Apache 1.3.18 и выше
- Nginx, модуль mod_accel для Apache
- Набор библиотек и утилит ffmpeg
- PHP 4.2.0 и выше (должен быть собран как модуль Apache)
- СУБД MySQL 4.1.14 и выше (предпочтительно: поддержка формата InnoDB).
- Модули PHP: Mcrypt, FTP, ffmpeg-php
- Библиотеки PHP: Smarty, GeoIP
- Возможность доступа к localhost по FTP протоколу
- 2 пользователя БД
Желательно, чтобы PHP не был запущен в SafeMode.
- Любой из перечисленный ниже браузеров (указана минимальная версия) с включенным
- Internet Explorer 6
- Mozilla 1.6 (Firefox 1.0)
- Opera 9
- Adobe Flash Player версии 9 и выше. Сайт должен быть работоспособен (информация,
- расположенная на нем, должна быть доступна) при отключении в браузере поддержки flash и
5.3 Требования к техническому обеспечению
- Компьютер с процессором Xeon 4 ядерный
- 2 ГГц (рекомендуется от 3 ГГц)
- Оперативная память 4 Гб
- Место на жестком диске от 1 Гб
Точные технически характеристики сервера будут уточнены после завершения системы и
обширного тестирования всех модулей
- Компьютер с процессором i3 ГГц (рекомендуется от 1.5ГГц)
- Оперативная память 256 Мб (рекомендуется от 512 Мб)
5.4 Требования к лингвистическому обеспечению
Сайт должен выполняться на русском языке.
5.5 Требования к эргономике и технической эстетике
Дизайн приложения должен быть адаптивный и работать корректно во всех устройствах (Android и IOS) с разрешением экрана 720х1280 пикселей, 1080х1920, 2560×1440, 640х1136 и 750х1334 пикселей соответственно. Интерфейс подключаемых модулей должен быть выполнен в едином стиле с интерфейсом ядра системы и должен обеспечивать возможность прозрачного перемещения администратора между модулями системы и использование одинаковых процедур управления и навигационных элементов для выполнения однотипных операций.
- Требования к приемке-сдаче проекта
6.1 Требования к наполнению информацией
Общие требования к информационному наполнению
Наполнение страниц мобильного приложения должно происходить в автоматическом режиме.
6.3 Требования к персоналу
Для эксплуатации веб-интерфейса сайта от администратора не должно требоваться специальных технических навыков, знания технологий или программных продуктов, за исключением общих навыков работы с персональным компьютером и стандартным веб-браузером (например, MS IE 6.0 или выше).
Администратор, оператор: уверенный пользователь сети Интернет, знание Microsoft Word.
Прочие пользователи: уверенный пользователь сети Интернет.
6.4 Порядок предоставления дистрибутива
По окончании разработки Исполнитель должен предоставить Заказчику дистрибутив системы в
Дистрибутив предоставляется на CD-диске в виде файлового архива.
6.5 Порядок переноса сайта на технические средства заказчика
После завершения сдачи-приемки сайта, в рамках гарантийной поддержки Исполнителем
производится однократный перенос разработанного программного обеспечения в apple store, google market .
Перед осуществлением переноса Заказчик обеспечивает удаленный shell-доступ к веб-серверу и
доступ к базе данных сайта.
6.6 Дополнительные требования
Требования к производительности
Работа любого скрипта не должна превышать 60 секунд.
При условии нагрузки на сервер не более
500.000 обращений к страницам портала в сутки.
Требования к безопасности
Требуется защитить исходный код общей части сайта. Не должно быть возможности считать php-
код скриптов. Требуется разграничение доступа.
Пароли пользователей хранятся в зашифрованном виде. Перехват данных на уровне протокола tcp возможен.
На уровне СУБД должно быть реализовано разграничение доступа к данным в БД.
Требования к надежности
Система может быть недоступна не более чем 24 часа в год. Резервирование данных осуществляет
хостинг-провайдер. У администратора сайта должна быть возможность выгрузить и загрузить
Рассмотрим основные моменты на наш взгляд по реализации мобильного приложения на платформе 1С. В качестве примера будем использовать приложение для просмотра данных по результатам тестирования для конфигурации «Тестирование 3.0».
Приложение доступно в Google Play (поиск выполняйте по словосочетанию «Тестирование 3.0: Отчеты» или по ссылке в конце статьи). Оно предназначено для отображения результатов тестирования на мобильном устройстве совместно с конфигурацией "Тестирование 3.0".
1. Демонстрационный режим
Для демонстрации работы и возможностей приложения мы добавили режим - «демо». В этом случае приложение для построения отчетов и графиков использует сохраненные заранее в макете данные и не требует соединения с сервером.
Технически данные для демонстрации хранятся в плоской таблице с двумя колонками «url» и «текстовые данные». Пример таблицы можно увидеть на рисунке ниже.
В функции выполнения запроса вставили проверку на наличие режима и при положительном условии сразу возвращаем данные из макета по соответствию url запроса. В случае отсутствия соответствия возвращается пустая строка, что может соответствовать ошибке.
Данный функционал удобно использовать при прототипировании интерфейса приложения, выполнения отладки, тестирования.
2. Авторизация
1С пока не поддерживает windows авторизацию в мобильном приложении, поэтому для обеспечения безопасности и подключения к серверу внутри сети предприятия мы используем VPN-канал (any-connect или другое приложение). Если без VPN, то рекомендуем обязательно использовать SSL.
На форме «Авторизация» мы реализовали сохранение настроек входа в приложение, что позволило упростить процедуру ввода необходимых данных. Доступны следующие комбинации:
а) сохраняются автоматически последние введенные данные после успешного входа и всегда отображаются при запуске (сервер, имя базы, логин, ssl);
б) при включении настройки «сохранять пароль» будет сохраняется пароль пользователя.
3. Дизайн форм приложения
Мобильное приложение должно иметь дизайн, позволяющий комфортно обрабатывать информацию.
Шрифт не должен быть мелким, в таблицах не должно быть излишнее число колонок, число элементов управления должно быть минимальным (два блока оптимально). Глубина операции не должна быть излишней (кликабельность) - оптимально не более 3х.
Отображение форм должно быть простым, а не перегруженным и излишне сложным. Ниже на картинке приведен пример в сравнении «сложной» формы с «легкой».
Раскройте все опции сразу
Адаптируйте приложение к изменению положения экрана (вертикально или горизонтально).
4. Получение данных
Мы используем для обмена информацией SOAP, REST сервисы. При разработке удобно использовать технологию REST (нет жесткого описания формата данных).
Был выбран «JSON» формат для передачи данных. С ним довольно легко работать. Тип передаваемых данных всегда структура. У структуры обязательно определено несколько основных полей – «ТипОбъекта», «Проверка», «Дата». Свойство «ТипОбъекта» используется для идентификации режима отображения и может содержать следующие значение: График, Таблица, HTML.
Приведем пример кода для преобразования ответа сервера из формата «JSON» в стандартный тип данных 1С (см. справку для более подробной информации):
5. Фоновое получение и обновление данных
Если предполагается получение большого объема данных, то чтобы не было зависаний в приложении используем фоновые задания для получения или обработки данных, т.е. асинхронно.
Реализовать это удалось, связав механизм фоновых заданий, хранилище настроек и обработчик ожидания. Логически процесс работы с фоновыми заданиями выглядит стандартно:
а) при открытии формы мы проверяем режим получения данных. Если асинхронно, то запускаем фоновое задание, в качестве ключа передаем имя формы.
б) запускаем фоновое задание и в хранилище настроек пишем признак того что задание запущено и не выполнено. Функция в фоновом задании по завершению в хранилище настроек записывает результат по переданному ранее ключу.
в) далее подключаем обработчик ожидания с минимальной длительностью в «0.1 с». (если канал хороший и данных не очень много, то синхронный режим справляется замечательно и быстрее чем с фоновым)
в) в функции при выполнении обработчика ожидания проверяем наличие в хранилище настроек признака выполнения по ключу.
Интерфейсно мы сначала активируем вкладку «знак загрузки» и показываем знак длительной операции, а потом по готовности данных переключаемся на вкладку с данными. Картинка ниже демонстрирует описанную схему.
6. Получение информации по изменению ориентации экрана
Для определения события изменения ориентации необходимо использовать функцию формы «ПриИзмененииПараметровЭкрана».
Для получения информации о текущем состоянии окна – вертикально или горизонтально используем функцию «ПолучитьИнформациюЭкрановКлиента». Приведем немного кода в качестве примера:
7. Использование таблиц и большого количества отображения данных
Фильтруйте данные, отображайте постраничный вывод – это позволит повысить отзывчивость приложения и упростит визуальную обработку информации пользователем.
На формах с таблицами используем фильтр с опциями: «все», «только ошибки», «только падения», «только пропуски».
Мы используем ограниченное количество колонок, все служебные поля обязательно скрываем. Подробную информацию выводим только в детализации.
8. Глобальные параметры, настройки
Практически всегда требуется использовать по отдельности или все вместе: какие-либо глобальные опции, настройки, сохранение значений реквизитов на управляемых формах (в мобильном приложении пока нет автосохранения реквизитов). Для решения всех этих задач совместно реализован механизм описанный в п.12.
В нашем приложении мы используем глобальный параметр «Тестируемый клиент». В десктопном приложении, мы выводили его в верху формы, и пользователь мог спокойно выбрать его или изменить, но в мобильно приложении существует проблема размещения. Поэтому мы вынесли эту настройку, а изменение значения реализовали в отдельной форме. Перейти к нему возможно из пункта меню.
Дополнительно, если пользователь не будет заходить при первом запуске системы в настройки приложения, то мы реализовали при открытии формы переадресацию на форму выбора текущего тестируемого клиента.
9. Используем иконки вместо текста
При отображении информации, особенно в табличном представлении мы сталкиваемся с ограничением в количестве колонок, особенно в вертикальном положении экрана. Поэтому удобно использовать картинки вместо слов – это выгодно экономит пространство и более наглядно.
В нашем приложении для информирования:
- о результатах последнего теста используем следующую картинку: (пропуск, успешно, в работе, ошибка, провал)
- о результатах сводке за последние 5 заданий - картинки в форме перехода от солнышка к тучкам
10. Использование цветов на диаграммах и графиках
Необходимо использовать устоявшиеся цвета и обозначения. В нашем приложении на диаграммах используется следующая цветовая маркировка (см. рис. ниже): успешно – зеленый, провал – красный, ошибка – желто-оранжевый, пропуск – серый.
Не стоит использовать произвольные цвета или обратные. К примеру, для понятия «да» использовать красный цвет или иной не подходящий, а для «нет» использовать зеленый.
11. Используем АБ-тестирование
Используйте АБ-тестирование для определения выбора варианта дизайна форм
12. Используем поле HTML
Иногда удобно использовать поле html для отображения информации. Мы в нашем приложении используем данный вариант в сводке по дефектам - для вывода общей информации по тестам с ошибками.
13. Сохранение настроек и параметров
Пока в мобильных приложениях нет функционала сохранения настроек на формах, реквизитов в формах и хранилища общих настроек. Поэтому для решения этого вопроса мы создали свое решение:
а) создали регистр сведений «ОбщееХранениеНастроек» (измерения: КлючОбъекта, КлючНастроек,Пользователь и ресурсы: Настройки (хранилище значения));
б) написали три функции в общем модуле «УправлениеОбщимХранилищемНастроек» – СохранитьНастройкиПользователя, ЗагрузитьНастройкиПользователя, УдалитьНастройкиПользователя (код функций тривиальный – запись значения в регистр сведений, чтение и удаление по параметрам);
Используем этот функционал практически везде: для сохранения настроек авторизации, передачи параметром от фонового задания инициатору и сохранению реквизитов, сохранения настроек отображения форм и др.
14. Демонстрация бета версии и сбор замечаний от первых пользователей
Оформляем приложение и запускаем его использование в ограниченном кругу лиц. В результате получаем первые отзывы по юзабилити, недостатках и другие советы, и замечания. В этот круг могут входить коллеги (заинтересованные лица), можно дать жене, детям, тете или дяде (не заинтересованным лицам).
По результатам обратной связи мы уже изменили некоторый функционал и внесли доработки в интерфейс. Также будем ждать отзывов и советов сообщества.
Читайте также: