Мобильное приложение
Коммуникатор «Energyphone»
Действует с 14.04.2014
СОГЛАСОВАНО
|
Согласовано
|
|
|
_________________ А.В. Школьников ООО «ЭНЕРДЖИ ЭНЕРДЖИ ФОН»
«___» __________________ г.
|
__________________ А.С.Васильев
ООО «Эвотек»
«___» __________________ г.
|
1)Введение
1.1Полное наименование системы и ее условное обозначение
Полное наименование системы: Мобильное приложение «Коммуникатор ЖКХ»/« Energyphone»
Краткое наименование системы: Мобильное приложение.
1.2Наименование предприятий разработчика и заказчика системы и их реквизиты
Заказчик работ — ООО «ЭНЕРДЖИ ЭНЕРДЖИ ФОН» (далее — Заказчик).
Разработчик — ООО «Эвотек» (далее — Исполнитель).
2)Назначение и задачи мобильного приложения
2.1Назначение мобильного приложения
Основное назначение приложения «Коммуникатор ЖКХ / Energyphone» — упростить и автоматизировать максимальное количество действий, расчетов, обменов информацией, способов платежа, связанных с повседневными действиями потребителей услуг в коммунальной сфере, при взаимодействии с поставщиками ресурсов (электроэнергии, тепла, воды, газа) и услуг (управляющих компаний и иных специализированных организаций).
2.2Задачи мобильного приложения
Задачи мобильного приложения:
1. Предоставление потребителю возможности снятия, анализа, хранения и передачи показаний приборов учета поставщику;
2. Предоставление потребителю возможности получения, хранения, анализа и оплаты электронных счетов за коммунальные услуги и ресурсы, а также хранения сканов (фотографий) и оплаты в случае получения бумажных счетов;
3. Предоставление потребителю возможности анализа динамики потребления, начисления и оплаты, хранения информации о тарифах, величинах социальных норм и нормативов, иной информации, используемой при расчетах за коммунальные услуги и энергоресурсы;
4. Предоставление потребителю возможности получения справочной информации посредством многоуровневой справки, в том числе с разделами, индивидуально заполняемыми поставщиками;
5. Предоставление потребителю возможности подготовки и отправки писем (обращений) поставщикам в определенном формате;
6. Предоставление потребителю возможности просмотра уведомлений (объявлений) поставщиков, а также ленты выполненных действий; 7. Предоставление потребителю возможности поиска на карте ближайших точек оплаты, офисов поставщиков с просмотром сопутствующей информации, а также возможности оставления отзыва (оценки) каждой точки.
3)Требования к системе
3.1Требования к системе в целом
3.1.1.Требования к структуре и функционированию системы
3.1.1.1Требования к характеристикам взаимосвязей со смежными системами
В Мобильном приложении должно быть предусмотрено взаимодействие со следующими системами:
сеть Интернет (взаимодействие с API сервера)
социальные сети:
Facebook;
Twitter;
ВКонтакте
3.1.1.2Требования к режимам функционирования системы
Штатная работа Мобильного приложения должна быть гарантирована в режиме, когда мобильный аппарат, на котором запущено приложение, подключен к сети Интернет.
В начале работы Мобильного приложения осуществляется запрос к API для получение информации о наличии изменений в данных. Если такая информация получена, выполняется загрузка и сохранение данных.
3.1.1.3Требования по диагностированию системы
Диагностирование Мобильного приложения осуществляется на основе отчетов об ошибках системными средствами, которые предоставляются платформой, а также встроенным функционалам, предоставляемым компонентами Flurry.
При возникновении исключительных ситуаций в ходе работы приложения они должны быть обработаны таким образом, чтобы приложение продолжало свою работу. Сообщение пользователю о внутренних ошибках в работе приложения недопустимо. Также недопустимо аварийное завершение приложения. Исключением являются ситуации порожденные средой исполнения приложения и независящие от действий, выполняемых самим приложением.
Исключительные ситуации, возникшие у конечных пользователей и препятствующие продолжению нормальной работе приложения, должны фиксироваться внутренними механизмами Мобильного приложения и автоматически отправляться на почту службы технической поддержки в виде отчета о неполадках. Данная функция должна быть реализована посредством компонентов Flurry.
3.1.1.4Перспективы развития, модернизации системы
Периоды развития Мобильного приложения приведены в таблице .
Таблица — Этапы развития Мобильного приложения
Наименование этапа
|
Временной период
|
Содержание этапа
|
1. Создание приложения в платной и бесплатной версии для iOS
|
Апрель-июнь 2014
|
Создание и размещение в Apple Store приложения согласно настоящему ТЗ
|
2. Доработка приложения iOS в соответствии с замечаниями и предложениями пользователей
|
Июль-август 2014
|
Доработка и размещение в Apple Store новой версии приложения
|
3. Разработка приложения в платной и бесплатной версии для Android
|
Май –август 2014
|
Создание и размещение в Google Play приложения в т.ч. с учетом замечаний и предложений пользователей
|
4. Встраивание в приложение платежной системы (систем)
|
Сентябрь – октябрь 2014
|
Доработка и размещение в Apple Store и Google Play новой версии приложения со встроенным платежным функционалом
|
5. Доработка версии приложения для планшетов
|
Сентябрь – октябрь 2014
|
Доработка и размещение в Apple Store и Google Play версии приложения для планшетов со встроенным платежным функционалом
|
6. Создание версий приложения для стран СНГ (бывш. СССР)
|
Октябрь –ноябрь 2014
|
Доработка с учетом специфики данных стран и размещение в Apple Store и Google Play версии приложения с возможностью выбора одного из языков (русский, белорусский, украинский, казахский)
|
7. Создание версий приложения для иных зарубежных стран
|
Ноябрь-декабрь 2014
|
Доработка с учетом специфики данных стран и размещение в Apple Store и Google Play версии приложения на языках: английский, немецкий, испанский
|
3.1.2Требования к надежности
3.1.2.1Требования к нагрузкам
Максимальная нагрузка на сервер не превышает 200 запросов HTTP/HTTPS в секунду, длительность сессии до 10 минут для пользователей, 10 запросов в секунду для поставщиков при длительность сессии до 8 часов.
При достижении критических значений по производительности Мобильное приложение должно продолжать текущее функционирование, а в случае невозможности — сообщить пользователю об ограничениях в работе Мобильного приложения.
3.1.2.2Требования к обеспечению функционирования
Для обеспечения бесперебойного функционирования Мобильного приложения должны быть соблюдены следующие требования:
4)кеширование необходимых для Мобильного приложения данных для доступа к ним в моменты недоступности сети Интернет;
5)включение в состав Мобильного приложения средств валидации полученного контента, а также введенных пользователем данных;
6)обеспечение работоспособности Мобильного приложения при обрывах соединений и возможности догрузить необходимые данные;
7)возможность своевременного информирования пользователя о проблемах с Мобильным приложением, требующих его внимания;
8)максимально полное покрытие тестами различных сочетаний операционных систем и устройств всех необходимых платформ;
9)участие в комплексных тестовых мероприятиях, организуемых Заказчиком или третьими сторонами по поручению Заказчика, обеспечение возможности проведения таких мероприятий, путем взаимодействия с Заказчиком и третьими сторонам в ходе тестовых мероприятий;
10)учет и реализация всех рекомендаций, предоставленных Заказчиком по результатам проведения комплексных тестовых мероприятий. По факту реализации рекомендаций или устранения выявленных недоработок Исполнителем должен быть подготовлен и предоставлен соответствующий отчет в рамках функционала, описанного в настоящем документе;
11)следование утвержденному Заказчиком регламенту взаимодействия со сторонними поставщиками.
В зоне ответственности Исполнителя находится работоспособность Мобильного приложения.
В случае нарушения работоспособности Приложения должен быть оформлен инцидент на исправление. При поступлении заявки на разрешение инцидента данной заявке присваивается приоритет в зависимости от степени влияния. Уровни приоритетов заявок представлены в таблице .
Таблица — Уровни приоритетов заявок
Критичность
|
Описание
|
Уровень 1
|
Критичная. Система не работает, затронуто значительное количество пользователей, жизненно важное приложение неработоспособно, возникла угроза безопасности или жизни
|
Уровень 2
|
Работа системы под угрозой, но работоспособность не нарушена или существует неисправность, которая некритична или для которой существуют обходные пути решения
|
Уровень 3
|
Компонент системы неработоспособен или имеется неисправность, влияющая на группу пользователей
|
Уровень 4
|
Один пользователь не получает ИТ-сервисы, но известны обходные пути их восстановления
|
11.1.1.1Требования к технической поддержке
Исполнитель обеспечивает бесперебойное функционирование Приложения, что включает в себя обеспечение следующих услуг:
обеспечение работоспособности;
оказание консультаций представителям заказчика по телефону, электронной почте и лично;
взаимодействие с производителем программного обеспечения по вопросам исправления ошибок программного обеспечения;
подготовку и предоставление регулярных отчётов о функционировании.
11.1.1.2Требования к реагированию на ошибки
Сообщения об ошибках Мобильного приложения или ошибочных действиях пользователя должны сопровождаться информацией о причинах ошибки и подсказкой о дальнейших действиях, необходимых для устранения проблемы.
Выполнение задачи, инициированной пользователем, в случае отсутствия очевидного результата должно сопровождаться соответствующей обратной реакцией со стороны системы, сигнализирующей о результате выполнения.
Настройки должны быть установлены таким образом, чтобы возможные ошибочные действия пользователей были сведены к минимуму.
Формат демонстрации сообщения об ошибке должен соответствовать гайдлайнам мобильных операционных систем.
11.1.2Требования к доступности
Мобильное приложение на платформе iOS должно поддерживать версии 5.17.x.
Для работы Мобильного приложения под операционной системой Android необходима минимальная версия ОС 2.3 и экраны устройств с разрешением не менее 320x480 пикселей .
Для устройств, не подходящих под вышеуказанные требования должна быть либо закрыта возможность загрузки Мобильного приложения, либо обеспечена версия Мобильного приложения с уведомлением, что Мобильное приложение может работать нестабильно на данном устройстве.
Мобильное приложение должно обеспечивать возможное функционирование в условиях отсутствия связи с сетью Интернет (за исключением первоначальной загрузки данных), а также при любом типе подключения к сети.
Мобильное приложение должно обеспечивать нормальное функционирование в условиях нестабильного и\или низкоскоростного подключения. Мобильное приложение должно уведомить пользователя о сложностях с работой в сети Интернет, если данный факт вызывает серьезные трудности при работе Мобильного приложения.
При наличии технической возможности и соответствующей поддержке со стороны Комплекса при передаче информации в сеть Интернет должны быть использованы алгоритмы сжатия информации.
3.1.4.Требования к эргономике и технической эстетике
11.1.2.1Общие требования к эргономике и технической эстетике
Взаимодействие пользователей с Мобильным приложением должно осуществляться посредством визуального графического интерфейса (далее — интерфейс).
Дизайн страниц Мобильного приложения (включая шрифты и цвета составляющих элементов) должен соответствовать представленным Заказчиком материалам по дизайну.
Управление Мобильным приложением должно осуществляется с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен использоваться при заполнении и (или) редактировании текстовых и числовых полей экранных форм.
Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений) должны быть реализованы на том языке, который указан в настройках ОС
Экранные формы интерфейса должны проектироваться с учетом требований унификации:
все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации;
для обозначения сходных операций должны использоваться сходные графические значки, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций (добавление информационной сущности, редактирование поля данных), а также последовательности действий пользователя при их выполнении, должны быть унифицированы.
Интерфейсы должны обеспечивать использование Мобильного приложения без навыков программирования или каких-либо специализированных, по отношению к обычному использованию интерфейсов мобильной операционной системы, знаний, умений и навыков.
Мобильное приложение должно учитывать различный пользовательский опыт работы с приложениями на планшетах и смартфонах и адаптировать содержимое для наилучшего соответствия этому опыту.
От окна к окну Мобильного приложения должно прослеживаться единство дизайна, а используемые примитивы графического интерфейса (кнопки, меню, элементы интерфейса) должны вести себя предсказуемо.
Там, где это возможно, Мобильное приложение должно сохранять введённые пользователем данные, чтобы избегать повторного их ввода.
Для каждого экрана приложения должен быть доступен соответствующий подраздел справки.
3.1.4.Требования к транспортабельности для подвижных АС
Требования к транспортабельности не предъявляются.
3.1.5.Требования к защите информации от несанкционированного доступа
Исполнитель должен предоставлять по запросу Заказчика все необходимые исходные коды, документы, права доступа и структуру базы данных. Исполнитель не должен препятствовать проведению аудита информационной безопасности.
Исполнителем должны быть устранены все выявленные уязвимости, подготовлен и предоставлен Заказчику отчет об устранении уязвимостей (с комментариями по каждому пункту списка выявленных уязвимостей в рамках функционала, описанного в настоящем документе.
Реализуемые в рамках Мобильного приложения механизмы обработки конфиденциальной информации должны соответствовать требованиям Законодательства РФ.
Должна быть обеспечена защита Мобильного приложения от угроз нарушения конфиденциальности данных и программных средств, а также нарушения целостности данных.
В рамках работ по разработке Политики информационной безопасности должна быть сформирована система оценки возможного ущерба от различных видов атак и проведена оценка соответствующих рисков информационной безопасности. Кроме того, политика информационной безопасности должна определять сферу ответственности Исполнителя.
3.1.5.Требования к защите от влияния внешних воздействий
Требования к защите от влияния внешних воздействий не предъявляются.
3.1.6.Требования к патентной чистоте
По всем техническим и программным средствам, применяемым в Мобильном приложении, должны соблюдаться условия лицензионных соглашений и обеспечиваться патентная чистота.
Реализация технических, программных, организационных и иных решений, предусмотренных проектом, не должна приводить к нарушению авторских и смежных прав третьих лиц.
При использовании программного обеспечения (или компонентов программного обеспечения), разработанного третьими лицами, для обеспечения работы Мобильного приложения условия, на которых передается право на использование (исполнение) этого программного обеспечения, не должны накладывать ограничений, препятствующих эксплуатации Мобильного приложения.
3.1.7.Требования по стандартизации и унификации
Разработка прикладного программного обеспечения Мобильного приложения должна быть основана на применении принципов объектно-ориентированного программирования и модульной архитектуры с использованием типовых программных компонент, реализующих одни и те же функции (фрагменты функций). Должны применяться тиражные инструментальные средства разработки программного обеспечения, общепринятые (стандарты де-факто) языки программирования, стандартные технические и программные средства общего назначения и процедуры информационного взаимообмена.
При создании Мобильного приложения должно использоваться тиражное стандартное общесистемное программное обеспечение, лицензированное установленным порядком.
Должно применяться серийно выпускаемое оборудование и аппаратные средства ведущих мировых производителей, сертифицированное для применения в Российской Федерации.
3.1.8.Дополнительные требования
Дополнительные требования не предъявляются
|
