Как сделать тз для мобильного приложения
Обновлено: 01.07.2024
Пример технического задания на разработку Андроид-приложения
Создать подобное ТЗ можно с помощью приложения.
1. Общее описание примера-приложения:
Лаунчер ( launcher ) – оболочка операционной системы Android , запускающийся кнопкой ДОМОЙ ( Home ) . Кнопка НАЗАД – игнорируется . Выхода из приложения (остановки, выгрузки) внутри кода – не предусмотрено, возможно только сторонними средствами
1.1. Только горизонтальная ориентация экрана
1.2. Работа на Android v.2.3+
1.3. Графика будет разработана дизайнером заказчика. Нужна будет тщательная отладка внешнего вида приложения.
2. Настройки:
2.1. При первом старте – диалог настроек
2.1.1. Каталоги на FTP сервере :
2.1.1.1. Пакеты – скачивание .ZIP файлов или файла update.apk (например, rootfolder/routes )
2.1.1.2. Статистика использования устройства: загрузка в каталог .TXT файлов c информацией (например, rootfolder/stat )
2.1.2. Имя этого устройства (планшета), принадлежность клиенту, имя пользователя и т.п.
2.1.4. Изменить настройки:
2.1.4.1. Удалить лаунчер и поставить снова
2.1.4.2. Или УДАЛИТЬ ВСЕ ДАННЫЕ в системном диалоге свойств приложения
3. Внешний вид и реакция на нажатия экрана:
3.1. Фоновая картинка
3.1.1. Короткий тап:
3.1.1.1. Скрытие лога
3.1.1.2. Запуск синхронизации с FTP -сервером
3.2. Зеленая кнопка слева-внизу
3.2.1. Короткий тап:
3.2.1.1. Запуск навигационной программы YYYY , если система в легальном статусе
3.3. Правый верхний угол экрана (невидимая кнопка)
3.3.1. Длинный тап: открытие лога обмена с FTP сервером
4. Синхронизация с FTP -сервером:
4.1. Логин и чтение листинга каталога с файлами пакетов (routes)
4.1.1. Пароль FTP- каунта хранится зашифрованным
4.1.2.1. Пароль SMTP- экаунта хранится зашифрованным
4.2. Загрузка файлов .ZIP пакетов (и обновления update.apk ) из каталога, если присутствуют и если момент времени их записи на сервер – больше времени, сохраненного в предыдущий сеанс связи с сервером
4.2.1. Если обнаружено обновление приложения update.apk c бОльшим номером версии:
4.2.1.2. Запуск обновления его на установку
4.3. Чтение листинга каталога security
4.3.1. Загрузка файла security /registered.txt , в котором находится список легальных ID устройств
4.3.2. Проверка присутствия ID устройства в списке, при отсутствии – блокировка системы
4.4. По окончании синхронизации файлов пакетов – вывод на весь экран диалог ввода номера пакета, с подсказкой в виде списка скачанных пакетов:
4.4.1. Отказаться от ввода – нельзя, при ошибочном вводе – перезапрос номера
4.4.2. После ввода номера пользователем:
4.4.2.1. Распаковка пакета в каталог маршрутов YYYY ( с удалением всего прочего в этом каталоге )
4.4.2.2. Показ фона и кнопки запуска YYYY вручную пользователем
5. Работа с навигатором YYYY
5.1. Запуск зеленой кнопкой слева-внизу
5.2. Фиксация времени начала работы
5.3. Фиксация номера пакета, скопированного для работы
5.4. При завершении YYYY и возврате в лаунчер – фиксация времени окончания работы с YYYY
5.5. Сохранение этой статистики в памяти и в файл
5.6. При наличии Интернет-соединения – отправка этих данных в файле на FTP в каталог stat
5.7. Новый запрос номера пакета и ожидание ввода
6. Фоновая работа:
6.2. При появлении Интернет-соединения:
6.2.1. Отправка сохраненной статистики использования пакетов в общем файле с суффиксом saved.txt в каталог stat
6.2.2. Запуск нового цикла синхронизации c FTP -сервером
6.3. Каждые 24 часа – принудительная попытка синхронизации c FTP -сервером:
6.3.1. При неудаче – увеличение счетчика неудач
6.3.2. Если синхронизация прошла – счетчик сбрасывается
6.3.3. При достижении 10 неудач (суток) – предупреждение пользователя, что нужна синхронизация
6.3.4. При достижении 60 суток без синхронизации – блокировка системы
6.3.5. Каждые 10 секунд после старта – проверка наличия отладки по USB ( через которое может быть нелегальный доступ к файлам устройства )
6.3.5.1. При наличии включенной отладки – блокировка системы
6.3.5.2. Если отладка отключена – то после касания фона, т.е. ручной синхронизации с FTP – блокировка снимается.
7. Блокировка системы:
7.1. Удаление файлов:
7.1.1. Пакетов скачанных с FTP
7.1.2. Распакованных маршрутов пакета в каталоге маршрутов YYYY
7.1.3. Блокировка запуска YYYY зеленой кнопкой
7.1.5. Принудительная синхронизация с FTP -сервером (для повторной проверки легальности, сброса счетчика неудач) – доступна при тапе экрана.
8. Общая защита системы производится с помощью приложения-киоска SureLock, запрещающего доступ к другим частям устройства, включая USB -интерфейс.
В этой статье хочу поговорить о разработке мобильного приложения на базе 1С.
Моя статья для Вас, если:
- Вы пишете на 1С, и в основном вся работа выполняется на типовых конфигурациях
- Вы хорошо знаете процесс создания конфигурации для ПК и стоит задача написать мобильное приложение (далее МП) или возможно внести исправления/доработки в существующее приложение.
Я подразумеваю, что читатель хорошо знаком с программированием на 1С, часто используемыми объектами конфигурации и умеет пользоваться гулгом (чтобы мочь самостоятельно погрузиться в тонкости, а не читать огромную статью с кучей лишнего материала).
Мы коротко рассмотрим весь процесс создания МП от составления технического задания (ТЗ) до компиляции готового к установке Android файла apk.
Еще уточню, мы не будем очень сильно углубляться в детали, иначе бы статья превратилась в полное пошаговое руководство по созданию МП или даже в небольшой роман))) Также не будет рассматриваться компиляция под iOS и публикация в AppStore или PlayMarket.
Здесь речь пойдет только о разработке мобильных приложений под одну платформу, что подразумевает непосредственную работу в собственной базе данных (БД) на МП и обмен данными с центральной базой (ЦБ). О мобильном клиенте 1С (не путать с мобильным приложением) стоит поговорить отдельно, но не сегодня.
1. ТЗ проекта мобильного приложения
Здесь, кажется, не о чем говорить. Общаемся с заказчиком, пишем все за ним. Обсуждаем хотелки, критерии интерфейса, в общем все, как и в версии для ПК. Но! Хочу выделить различия составления ТЗ для МП и для ПК.
Обычно заказчик хочет видеть на экране мобильного устройства те же объекты, что и в ПК версии. Поясню, бывают случаи, когда разрабатывается, например, МП для сбора каких-либо данных, и в ЦБ эти данные обрабатываются просто как коллекция. Но когда мы говорим об отображении объектов из ЦБ на МП, нужно понимать, что перетащив/скопировав объект один в один, как есть, мы совершаем акт насилия над МП))) Все дело в том, что, во-первых, не стоит перегружать базу данных МП лишними реквизитами, так как это может привести к увеличению размера базы на устройстве и к существенному увеличению времени получения и обработки данных при обмене с ЦБ. Но и это еще не все причины! Экран МП может вместить в себе намного меньше элементов, нежели экран ПК. Поэтому, если мы перенесем даже простой справочник с десятком реквизитов, он уже будет смотреться на МП очень загроможденным. И еще, стоит учитывать, что даже если объект достаточно прост, то на его оформление нужно будет потратить минимум вдвое больше времени нежели при создании аналогичного объекта на ПК.
Также при составлении ТЗ стоит уточнить у заказчика, на каких устройствах планируется использовать мобильное приложение. И если мы говорим о качественной разработке, нужно будет провести тестирование на таком же устройстве или, как минимум, в эмуляторе этой модели. Если же в планах заказчика нет конкретного оборудования и даже нет примерного понимания размера экрана, обязательно оговариваем диапазон тестируемых экранов, например, от 5 до 10 дюймов. И, конечно же, не забываем заложить в ТЗ часы на такое тестирование.
Подчеркну, самым важным, по моему мнению, в МП это его простота и минимализм. Интерфейс должен нести минимально необходимый объем информации, даже подписи к реквизитам могут иметь очень большое значение в визуальном восприятии приложения.
И, конечно же, приложение должно быть максимально удобным. Расположение кнопки справа или слева может сыграть ключевую роль: так как в некоторые места экрана очень неудобно нажимать, управляя устройством одной рукой.
Итак, подводим итог по ТЗ:
- уточняем размер устройств;
- заставляем заказчика назвать минимум реквизитов для переноса объектов из ПК на МП;
- при тестировании учитываем ориентацию и размер экрана. Проверяем удобство расположения элементов на форме.
2. XDTO-пакеты и объекты XDTO в разработке мобильного приложения
Перед тем как создавать объекты в конфигурации МП, нужно определиться с набором объектов и реквизитов, которые идентичны с ЦБ. Например, справочник контрагенты, мы решаем, что будем переносить только наименование и адрес.
Далее я вижу такие варианты развития событий:
1. Использовать XDTO-пакеты.
Этот способ несколько более сложен, чем другие, потому как нужно вникнуть в такой объект метаданных. Хотя это очень даже удобный инструмент, когда, например, есть разработанный сторонний продукт и ему нужно обмениваться данными с 1С. Разработчик этого ПО создает xsd-схему, Вы импортируете ее в свою конфигурацию и легко получаете из xml файлов обмена данными объектов xdto. С ними намного удобней работать, чем, например, парсить, иногда огромных размеров xml.
Итак, что же нам делать с этими объектами?! xdto-пакет должен быть создан в конфигурации ЦБ и описывать структуру объекта мобильного приложения. И когда мы получим объект из МП, при чтении xdto, ЦБ будет точно знать, что у нас за объект. Важно! Порядок реквизитов в xdto и МП должен совпадать. Точно так же, если структура метаданных объектов совпадает (имя и названия реквизитов) и Вы передаете сериализованные объекты без какой-либо обработки из Цб в МП, в любом случае порядок реквизитов должен быть идентичным, иначе получите неинформативную ошибку на МП при десериализации.
2. Передавать структуру или таблицу значений вместо объектов XDTO.
Тут все просто: берем названные выше коллекции и наполняем их необходимыми нам данными. Сериализуем, получая таким образом строку, передаем на сервер, десериализуем и вновь получаем нашу коллекцию.
Также сериализация подходит, если мы решаем, что объект МП будет иметь весь набор реквизитов ЦБ, то есть они будут идентичны.
Вот такие есть варианты обмена информацией между МП и ЦБ. Хотя, как мне кажется, можно придумать и другие, но эти наиболее часто используются.
Почему столько заморочек при обмене?
В ином случае мы сможем передавать из МП только примитивные типы данных (Число, Булево, Строка). А вышеописанные методы позволяют преобразовать объекты в строку и после передачи получить из нее обратно свои объекты в том же виде.
После того, как выбран метод обмена, можно приступать к созданию объектов метаданных конфигурации МП. При этом важно не забывать просматривать доступность используемых Вами объектов на мобильном приложении. Пока мобильное приложение в разработке, никто не запрещает тестить в тонком клиенте, запуская отладку и пользоваться всеми прелестями десктопного приложения. Но! Не все таким образом можно отладить и протестировать. Если используется функционал только МП, как, например, работа с геоданными, телефонией, камерой устройства, с нативным или сторонним ПО Android, - то тут удастся протестить только на реальном устройстве или на эмуляторе (например, Genymotion).
Итак, конфигурация МП написана, все что можно потестили на ПК, что дальше?
3. Настройка обмена данными
Как определить объем передаваемых данных?
Я вижу такие варианты:
1) Использовать план обмена. Конечно же, его придется создать. Тогда можно будет использовать свои правила регистрации, скажем, в подписке на события. Таким образом сможем учитывать любые задуманные отборы, чтоб на МП попало минимальное количество объектов;
2) Постоянно передавать все данные. В основном так можно делать, когда объем передаваемых данных минимален.
Вот, например: на МП передаются данные для отчетов, которые не нужно фильтровать (ДДС для руководителей) или прочая отчетность, которая нуждается только в отборе по периоду.
Данные мы отобрали, как же их передавать с ЦБ на МП и обратно?
4. Передача приложения с помощью Android файла apk
Компиляция
Передать клиенту готовый результат для 1С-ника, обычно означает передать конфигурацию (cf-ник). Но это не так в случае с МП.
Что же мы должны передать клиенту?
Ииии))), конечно же, готовое к установке мобильное приложение! Для Android устройств это файл с расширением .apk
Как же его получить?
Это прям-таки отдельная история)))
Если Вы хоть немного ориентируетесь в разработке мобильного приложения под android на java, то это существенно облегчит понимание происходящего далее.
Приведу несколько примеров ошибок и их решения:
1) Youhavenotacceptedthelicenseagreementsofthefollowing SDK components:
[Android SDK Platform 27, Android SDK Build-Tools 27.0.3].
- в таком случае, скорее всего, не установлено нужное апи версии 27 (устанавливается в Androidstudio), потому как лицензия принимается именно при его установке;
2) Couldnotfindplay-services-basement.aar (com.google.android.gms:play-services-basement:15.0.1).
- эта ошибка уже поглубже будет. Она хорошо гуглится, но!
Куда вносить правки?
В данном случае мы правим файл build.gradle
Как я узнал, вы спросите?
Тут, наверно, проще ориентироваться по содержимому. На форумах часто выкладывают полные скрины с кодом. Вот по нему можно и поискать. Либо четко указывают названия файлов.
Бывают и другие ошибки, но способ их решения всегда сводится к гуглу и нахождению аналогичных ошибок у ява-разработчиков.
И последний важный момент про компиляцию. Если вы однажды собрали apk и отдали клиенту, он неделю его проверял и просит внести правку в виде запятой в названии формы; Вам все равно придется компилировать apk заново!
Использование платформы в поставке
Как же избежать мучений с компиляцией?
5. Тестирование мобильных приложений
Описанным выше вариантом (использование платформы в поставке) очень удобно тестировать приложение. Ставим себе платформу и обновляемся без повторных компиляций и установок apk.
Но как сработают точки останова?
Отмечу также, что если ранее Вы не разрабатывали под мобильную платформу, Вам придется установить немного стороннего софта. Естественно компоненты java для компиляции и, например, web-сервер (рекомендую apache версии 2.2), который будет полезен для отладки на Вашем устройстве.
Также важный момент: лучше брать версии софта выпущенные теми датами, когда и был выпуск вашей версии мобильной платформы. Иначе могут быть ошибки, связанные с несоответствием версий (например sdk и gradle). Так что рекомендую сразу копаться в архивах)))
В завершение скажу, что если уж этот нелегкий путь однажды был пройден Вами, то последующие достижения в области мобильной разработки пройдут гораздо проще, чего Вам и желаю! Удачи!
Вас могут заинтересовать следующие статьи:
94 [PROP_CODE] => TAGS2 [TITLE] => Вас могут заинтересовать следующие семинары: ) --> 95 [PROP_CODE] => TAGS [TITLE] => Вас могут заинтересовать следующие вебинары: ) -->
Вас могут заинтересовать следующие вебинары:
24.12.2014
Большинству из нас хоть раз приходилось или ещё придётся писать техническое задание – на разработку софта, на создание сайта или на оформление банкетного зала. Называть этот документ (а это именно документ) можно по-разному – техническое задание, спецификация, требования к качеству или протокол требуемых изменений, но суть этой бумаги во всех случаях остаётся одной. Сегодня мы покажем вам пример требований к техническому заданию.
Техническое задание на разработку мобильного приложения
Так, давайте подробнее остановимся на том, как написать хорошее ТЗ на разработку мобильных приложений.
1.1 Идея проекта – Дайте поставщику услуг максимально много деталей о вашем проекте разработки мобильных приложений.
1.2 Определите основную цель своего мобильного приложения – краткое, но точное объяснение того, чего вы хотели бы достичь.
1.3 Укажите, на каких платформах должно работать ваше мобильное приложение: Android, iPhone, BlackBerry или любой другой, должно ли оно быть кросс-платформенным или нет.
1.4 Графический дизайн – Уточните, будет ли разработка дизайна передана на аутсорсинг (если да, укажите, кто будет работать над проектной задачей: подрядчик или фрилансер…), или всё будет выполнено в рамках компании.
1.5 Бюджет проекта – Расскажите о рамках бюджета.
1.6 Желаемые сроки поставки продукции – Укажите дату поставки и этапы развития проекта мобильного приложения.
2. Детали проекта
2.1 Экраны – экраны (вкладки) должны быть представлены отдельно, с имеющимися изображениями, презентациями и всеми другими визуальными материалами.
2.2 Интеграция с социальными медиа – Уточните, должно ли мобильное приложение быть интегрировано с социальными медиа (Facebook, Twitter….).
2.3 Ландшафтный режим – Уточните, хотите ли вы реализовать в вашем мобильном приложении ландшафтный режим.
2.4 Автономная работа – Упомяните, должно ли мобильное приложение сохранять любые данные на устройстве.
2.5 Взаимодействие с сервером – Уточните, будет ли ваше мобильное приложение отправлять данные с/на внешний сервер. Дайте некоторую общую характеристику серверной части.
2.6 Функции печати – Укажите, должно ли ваше мобильное приложение иметь возможность распечатать информацию, и если да, то какие типы данных будут доступны для печати.
2.7 Встроенные покупки – Упомяните, должны ли пользователи мобильного приложения иметь возможность покупать контент внутри приложения, и если да, то какой тип контента будет продаваться.
2.8 Услуги геолокации – Укажите, будет ли у вашего мобильного приложения функциональность гео-данных.
2.9 Всплывающие уведомления – Уточните, будет ли ваше приложение отсылать всплывающие уведомления для более широкого взаимодействия с пользователем, и если да, то укажите типы уведомлений.
3. Рыночная информация
3.1 Целевая группа – Представьте свои идеи о потенциальных пользователях вашего мобильного приложения.
3.2 Конкуренты – Упомяните, на какую продукцию конкурентов вы хотите, чтобы взглянул ваш потенциальный поставщик услуг, прежде чем давать вам какие-либо оценки проекта.
4. Разные вопросы
4.1 Ответственные люди с вашей стороны – Выясните, кто и сколько человек будут задействованы управлении проектом разработки мобильного приложения с вашей стороны.
4.2 Связь – Опишите желаемый метод(ы) общения с вашим поставщиком услуг.
4.3 Дополнительные сведения – Любые другие подробности проекта, вопросы и т.д.
Каким должно быть техзадание на разработку мобильного приложения? Какова его стоимость? Мы подскажем, что делать и с чего начать, если вы не знаете, как составить ТЗ на разработку мобильного приложения.
Без подробного технического задания разработка мобильных приложений невозможна так же, как пошив костюма без снятия мерок. Практика показывает, что владельцы бизнесов часто не знают, с какой стороны подойти к техзаданию, поэтому медлят с заказом, теряя время и деньги. На какие вопросы нужно дать точные ответы разработчикам?
Что такое ТЗ на разработку мобильного приложения
Это подробное задание программистам и другим членам команды, по которому на заданной платформе создают конкретный продукт или совокупность программных продуктов. Заказчик делает наглядное описание со снимками, логическими схемами, расчетами и другими пояснениями. На этапе проектирования создают концепцию и прописывают технические подробности:
Делают дополнительное описание требований к нагрузке сервера. Если техническое задание на разработку мобильного приложения включает параметры безопасности, секретности и так далее, то их указывают.
Как написать ТЗ самостоятельно?
Самостоятельно создать техническое задание — задача сложная и требующая компетенций в различных областях знания (IT, дизайне и т.п.). Как правило, заказчики приходят с идеей, или с описанием требуемого функционала и общих представлений о том, как это должно выглядеть и работать. Некоторые компании собирают собственную команду для создания технического задания или нанимают внешнего подрядчика для выполнения этой работы.
Мы выделяем следующие стадии готовности ТЗ:
2. Описание функционала
3. Референсы (приложения, аналог которого Вы хотите получить)
На любой стадии прежде чем обратиться за расчетом стоимости, мы рекомендуем найти время и письменно ответить на следующие вопросы (хотя бы для себя):
1) Цели создания приложения
— для кого вы хотите создать приложение
— какие реальные задачи пользователей будет решать приложение
— зачем пользователи будут скачивать приложение и занимать память своего телефона
— какую цель преследуете Вы сами (ваш бизнес), создавая это приложение
— какие функции должны быть в первой версии приложения обязательно
— какие функции могут появиться во вторую/третью/… очередь
3) Как организован бизнес-процесс сейчас
Как правило, приложения — это внешняя часть некоторого бизнес-процесса, данные о котором уже содержатся в некой системе. Это может быть CRM, 1С, IIKO, R-Keeper и другие. В каждой отрасли своя специфика, но в каждой отрасли есть решения, позволяющие хранить и обрабатывать данные о клиентах/заказах/продукции и т.п. Приложение не работает на пустом месте — это лишь оболочка, которая транслирует пользователю информацию с сервера и загружает ее обратно. При отсутствии такой системы — необходимо либо ее внедрение либо проектирование и создание (а это уже совсем другой процесс). Нужно быть к этому готовым.
Можно заказать приложение и без ТЗ
Порой ответы на эти вопросы приводят к пониманию того, что приложение вашему бизнесу не нужно. Если Вы убеждены в необходимости создания приложения, то ответы на эти вопросы помогут нам быстро и правильно понять Вашу задачу. А техническое задание составим вместе.
В компания Wellsoft разработкой мобильных приложений на заказ занимается высокопрофессиональная команда программистов, дизайнеров, верстальщиков и тестировщиков, мы интегрируем приложения с любыми сайтами, платежными системами. Интегрируем с любой базой данных по API.
Читайте также: