Разработка мобильного приложения детская развивающая игра. Теоретические основы разработки мобильных приложений

• Название: Теоретические основы разработки мобильных приложений
• Дата: 23.02.2023
• Размер: 2.75 Mb.
• Имя файла: Разработка мобильного приложения детская развивающая игра.doc
• Тип: Анализ; #951337
• страница: 2 из 7

1.2 Определение требований к мобильным приложениям
Разрабатывая новое мобильное приложение или внедряя уже существующее, каждый неизбежно сталкивается с необходимостью определить требования качества к будущему мобильному приложению.

Требование качества бывают как общие, так и частные, направленные на отдельные категории мобильных приложений. Сначала предоставлен список общих требований, но не весь их список, а имеющие отношения к разрабатываемому в данной дипломной работе мобильному приложению, которые укреплены законодательно в конституции РК. В списке пункты не по порядку, так как номера пунктов соответствуют номерам пунктов в конституции РК.

1 Общие требования к Мобильным Приложениям (далее в тексте МП) 1.1 МП должно соблюдать законы Республики Казахстан.

1.2 МП не должно вводить пользователя в заблуждение относительно своей функциональности.

1.3 МП, значительно изменяющие первоначальную функциональность, одобренную модераторами, или заменяющие одно приложение другим, будут отключены.

1.4 МП без службы поддержки пользователей и/или модерируемой группы не принимаются.

2 Требования к содержанию

2.1 МП, загружающие какие–либо сторонние программы, помимо самой игры или приложения, на мобильное устройство пользователя, не принимаются.

2.3 МП, копирующие дизайн, графику, звук других приложений и не обладающие авторскими правами на данный материал, не принимаются.

2.6 МП, в которых упоминается / демонстрируется алкоголь, табак и табачные изделия, а также сам процесс курения, лекарственные препараты, наркотики и любые другие запрещённые вещества, не принимаются.

2.7 МП с порнографическим или эротическим содержанием не принимаются.

2.8 МП, содержащие реалистичные сцены насилия или в любом виде пропагандирующие насилие, не принимаются.

2.9 МП, использующие в текстах нецензурную лексику, не принимаются и будут исключены.

2.10 МП, содержащие любые сцены насилия над детьми, не принимаются.

2.11 МП, пропагандирующие любые религиозные или политические взгляды, не принимаются.

2.16 МП, работающие как интернет–радио, не принимаются.

2.17 МП, работающие как видео чаты или мессенджеры, не принимаются.

2.19 МП, содержащие ссылки на внешние ресурсы (в том числе и различные счётчики) не принимаются и будут исключены. Исключение составляют ссылки на службу поддержки и документацию юридического характера

3. Функциональные требования

3.1 МП, работающие некорректно и содержащие ошибки, не принимаются.

3.2 МП, находящиеся в режиме тестирования, не принимаются.

3.3 МП имеющие серверный backend без достаточных серверных ресурсов (минимально 200 пользователей одновременно, 1 500 установок в час) не принимаются и будут исключены.

3.4 МП, в любой форме просящие указать логин, пароль от любых сайтов или телефон пользователя, не принимаются и будут исключены.

3.5 Любой подъём МП диалогов API должен происходить после активного действия пользователя.

3.7 МП запрещается использовать информацию, полученную с помощью вызовов API, где бы то ни было, кроме самого приложения, из которого данные вызовы были осуществлены.

3.8 МП запрещается отправлять SMS–сообщения.

3.9 МП, имеющие функциональность сервиса знакомств, являющиеся по факту азартными играми и/или имеющие блатную тематику, будут сопровождаться следующими ограничениями:

3.9.1 ограничения по возрасту;

3.9.2 недоступность быстрых платежей;

3.9.3 невозможность получения информации о балансе пользователя;

3.9.4 Обязательным предварительным информированием пользователей о содержимом приложения.

4 Требования к текстовым и графическим материалам

4.1 Описание приложения должно соответствовать функциональности приложения и не вводить пользователя в заблуждение.

4.2 МП, использующие анимированные иконки, не принимаются и будут исключены.

4.3 Иконка приложения должна быть уникальной и не повторять иконки других приложений

4.4 На логотипе приложения должно быть размещено название приложения или его основная часть. МП без названия в логотипе не принимаются и исключаются.

4.5 МП с логотипом, имеющим белый или прозрачный фон, не принимаются.

4.6 МП, имеющие некорректную категорию или жанр, не принимаются.

5 Внешние ссылки и реклама

5.2 Приложения, размещающие рекламу на другие приложения (в том числе принадлежащие одному и тому же разработчику или издателю) будут удалены.

5.3 Приложения, ограничивающие собственную функциональность рекламой других игр при старте, не принимаются и будут исключены.

5.4 Приложения, в любом виде использующие или упоминающие оферные программы, не принимаются и будут исключены.

5.5 МП, распространяющие назойливые рекламные сообщения (также известные как спам) через любые каналы, не принимаются и будут исключены [5].

 Помимо выше перечисленных общих требований к мобильному приложению или информационной системе. Имеется так же ряд требований, которые предъявляется для отдельной категории, к которому относится будущее мобильное приложение. Далее будут рассмотрены требования, которые относятся к приложениям, относящимся к категории «детская развивающая игра». Требования к ПО состоят из трех уровней — бизнес–требования, требования пользователей и функциональные требования. Вдобавок каждая система имеет свои нефункциональные требования.

Бизнес–требования содержат высокоуровневые цели организации или заказчиков системы. Как правило, они высказываются теми, кто финансирует проект, покупателями системы, менеджерами реальных пользователей, отделом маркетинга или «ясновидцем» (специалистом по системам машинного зрения). В этом пунтке требований объясняется, почему организации или физическому лицу нужна такая система, приложение, то есть описаны цели, которые заказчик намерен достичь посредством ее помощи.

В дополнение к функциональным требованиям спецификация содержит нефункциональные, где описаны цели и атрибуты качества. Атрибуты качества представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям. Другие нефункциональные требования описывают внешние взаимодействия между системой и внешним миром, а также ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта, Люди часто рассуждают о характеристиках продукта.

Характеристика (feature) - это набор логически связанных функциональных требований, которые обеспечивают возможности пользователя и удовлетворяют бизнес цели. В области коммерческого ПО характеристика представляет собой узнаваемую всеми заинтересованными лицами группу требований, которые важны при принятии решения о покупке элемент маркированного списка в описании продукта. Характеристики продукта, которые перечисляет клиент, не эквивалентны тем, что входят в список необходимых для решения задач пользователей. В качестве примеров характеристик продуктов можно привести избранные страницы или закладки веб-браузера, контроль за орфографией, запись макрокоманды, сервопривод стекла в автомобиле, онлайновое обновление или изменение налогового кодекса, ускоренный набор телефонного номера или автоматическое определение вируса. Характеристики могут охватывать множество вариантов использования, и для каждого варианта необходимо, чтобы множество функциональных требований было реализовано для выполнения пользователем его задач [6].

Теперь будут выдвинуты требования к разрабатываемому мобильному приложению на основе вышеизложенных показателей качества и стандартов. Можно было описать ещё пару гостов и стандартов качества мобильного приложения или информационной системы. Но было решено взять лишь эти два стандтарта,которые являются глыбами среди остальных себе подобных. Потому что в первом требовании качества, описанного в пунтках 1–5.6, описываются те законы, которые мобильное приложение должно собладать, разрабатываясь на територии РК.

И так бизнес - требования, выдвигаемые для разрабатываемого мобильного приложения. Целью данного мобильного приложения является: развитие ребёнка. И к тому же помощь в формировании у него конкретных психических процессов и способностей. А именно развитие логического мышления, арифметических знаний, способности запоминать. Как все знают, игровая деятельность занимает отдельное место в жизнедеятельности любого ребёнка. Доказано, что успешное освоение новых знаний, и также адаптация детей в окружающем мире происходят намного быстрее и лучше в игровом процессе, нежели посреди обычных занятий. Поэтому неслучайно годами в педагогике используются игры для всестороннего развития детей дошкольного возраста. И разрабатываемое приложение так же будет ориентировано на детей школьного возраста. То есть, для детей в возрасте от 4 до 7 лет.

Теперь будут рассмотрены следующие немаловажные атрибуты качества: легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям. Особенное внимание нужно уделить простоте использования и легкости применения. Ведь приложения для детей от 4 до 7 лет.

Интерфейс и внешний вид приложения должен быть окрашен в яркие цвета, или сделан в стиле, который способен заинтересовать детей. Ориентировочно интерфейс должен напоминать сказку или окружающие его предметы. Чтобы ребёнок сразу мог ориентироваться в знакомом пространстве. Чтобы сэкономить время для адаптации и навигации в приложении.

Ограничения по поводу цензуры очень строги. Так как это совсем малыши, и наша цель именно в их развитии, а не в разрушении. То есть мы должны чётко подобрать интерфейс с детской тематикой. Избегая всевозможной, умышленной или нет пропаганды всего нетрадиционного и традиционного, пошлостей, извращений, нецензурных выражений, или двусмысленных выражений, намекающих на неприличности.

Ещё одно требование, которое будет описано в последнюю очередь, но является далеко не последним это требования к логике игры. Так как игра обучающая. Она должна действительно обучать. Обучать посредством игры, не перегружая ребёнка теорией и прочей скучной для непоседы ерундой. Игра должна следовать строгой логике. Игра должна быть помощником в развитии ребёнка. И должна помочь без проблем обучить начальным азам, чтобы ребёнок без проблем поступил в первый класс. Среди требований для малышей, поступающих в первый класс общеобразовательной школы присутствует список областей, в которых он должен обладать начальными знаниями. Основными из них являются: Счет (знание цифр, умение составлять числа, базовые знания арифметики – умение сравнивать, складывать и вычитать в уме числа в пределах десяти).

1. 
   ) Чтение (знание алфавита, умение чтения слогов и слов, умение различать звук, слово, слог, предложение, гласные и согласные буквы).
   
2. 
   ) Цвета (умение называть и различать основные цвета радуги).
   
3. 
   ) Геометрические фигуры (двумерные и трехмерные).
   
4. 
   ) Общие знания окружающего мира (животные, растения, предметы, явления).
   

Из всего этого списка планируется особое внимание уделить для обучения счету, и развитию аналитического мышления у детей.

Основными требованиями, предъявляемыми для мобильных приложений, относящихся к категории «Детская развивающая игра» являются: приложение должно не нарушать ни одну из статей конституции РК, контент приложения должен соответствовать заявленному возрасту, приложение должно быстро откликаться на запросы, интерфейс приложения должен быть дружелюбным. Задания должны быть продуманными и соответствовать тематике приложения.
1.3 Анализ сред разработки
В этой главе дипломной работы будут описаны среды разработки или фреймворки, которые могут дать возможность для написания мобильное приложение. В этой же главе будет проведён сравнительный анализ этих сред разработки и фреймворков, и здесь же будет выбрана платформа, на которую будет ориентироваться при написании кода. А это значит, что с выбором платформы, будет выбран и язык программирования на котором будет писаться мобильное приложение.

Список будет начат с самых популярных фреймворков. И первый в этом списке анализа это: Appcelereator Titanium.

1. 
   ) Приложения, сделанные в нём, внешне выглядят и ведут себя подобно нативным, но полностью написаны на JavaScript (js код при запуске транслируется в нативные виды).
   
2. 
   ) UI можно сделать отдельно для всех платформ при использовании фреймворка Alloy (интегрированный фреймворк, который использует XML и CSS–подобным синтаксисом). Притом, что создание отдельного UI для каждой операционной системы усложняет разработку и очень снижает объем заново используемого кода, вся логика, модель и ядро приложения все же не нарушаются, и остаются одинаковыми для любой платформы.
   
3. 
   ) Магазин плагинов и визуальных компонентов (520 компонентов и 204 из них бесплатные) – все, что только будет пригодно для приложений: аналитика, реклама, облачное хранилище, социальные сети, компоненты для работы с графикой и т.д.
   
4. 
   ) Аналитическая платформа, тестовая платформа (мониторинг данных о приложении в режиме реального времени, мониторинг производительности, крэшей, логов и даже самого процесса создания приложения)
   
5. 
   ) Полностью автоматизированная система тестов.
   
6. 
   ) Встроенные соединители к самым известным enterprise–платформам (Salesforce, SAP, Oracle, Microsoft Dynamics и Share Point), соединители к популярным приложениям (LinkedIn, PayPal, DropBox, Facebook, Twitter и др.). Возможность создавать свои собственные соединители к любым сервисам [8].
   

Kony Platform.

1. 
   ) Веб, гибридные и нативные приложения для телефонов, планшетов и десктопных приспособлений, написанные единым кодом.
   
2. 
   ) Поддержка полного процесса создания приложения от начала до конца (дизайн, разработка, тестирование, развертывание и управление кроссплатформенным приложением).
   
3. 
   ) Возможность показывать и делиться прототипами и приложениями между дизайнерами и разработчиками (можно даже комментировать и обсуждать какие–то проблемные места на макетах).
   
4. 
   ) Гибкая возможность выбирать фреймворки для разработки (включая JavaScript и PhoneGap) и нативные средства (iOS, Android).
   
5. 
   ) Превью приложений в режиме настоящего времени.
   
6. 
   ) Возможность отсылать сообщения и уведомления пользователям (push services).
   
7. 
   ) Синхронизация сервесов (sync services) позволяет подключаться к любым сторонним энтерпрайз сервисам.
   
8. 
   ) Система отчетов, аналитики и тестов. Определение устройств, крэш–логи.
   
9. 
   ) Контроль безопасности данных посредством авторизации.
   

10) Обновление приложения, оперирование настройками и версиями [9].

Adobe Phone Gap

1. 
   ) Приложение работает в режимей совершенно обыденной веб–страницы внутри Web View, исходя из этого все строится на основе знакомых для всех HTML, CSS и JS. Но при этом Phone Gap API дает нам возможность использовать все возможности устройства в приложении: микрофон, камера, файловая система, GPS, уведомления, контакты и т.д.
   
2. 
   ) В основу построения AdopePhoneGap приожения заложенWebView, поэтому его можно внедрить как нативное приложение (получим гибридное).
   
3. 
   ) Можно компилировать под каждую существующую на сегодняшний день мобильную платформу, включая Firefox, Bada, TizenOS. Причем, используя облачный сервис PhoneGapBuild, сделать это можно буквально в пару кликов. Порог вхождения в разработку на PhoneGap довольно низок. Фреймворк сам по себе не очень большой и простой в использовании. И достаточно знать лишь базовые веб–технологии.
   
4. 
   ) Это бесплатный и открытый продукт [10].
   

IBM Worklight

1. 
   ) При создании в основу были взяты Apache Cordova (так же как и вышеописанный Phone Gap), поэтому как и в Phone Gap можно создавать веб-приложения, так же как и нативные (с учётом того что они будут гибридными, при этом имея возможностью пересылать сообщения и данные между нативными и веб модулями).
   
2. 
   ) Поддерживает интернационализацию.
   
3. 
   ) Поддерживает USSD–сервисов.
   
4. 
   ) Имеется сервис для тестировки приложения.
   
5. 
   ) Прослеживается много уровней безопасности на каждом уровне – приложение, данные, устройство, пользователь.
   

TelerikPlatform

1. 
   ) Возможность создавать нативные и гибридные приложения.
   
2. 
   ) Функция удаленного доступа к управлению своими приложениями.
   
3. 
   ) Интеграция с энтерпрайз–сервисами.
   
4. 
   ) Push уведомления.
   
5. 
   ) Синхронизация с сервером изменений, сделанных пока приложение было в режиме оффлайн.
   
6. 
   ) Возможность использовать для разработки любую привычную и любимую интегрированную среду разработки (IDEA,Eclipse,NetBeans и др.), а также есть собственная среда разработки :Verivo App Studio [11].
   

Xamarin

1. 
   ) Разработка нативных iOS, Android, Mac и Windows приложений с помощью объектно-ориентированного языка C#. Поведение, вид и производительность такая же, как и у родных приложений. Потому что, в отличие от Appcelerator, код не интерпретируется на стадии выполнения, а компилируется сразу в нативный код.
   
2. 
   ) UI создается для каждой платформы с помощью стандартных для этих платформ view.
   
3. 
   ) Xamarin Test Cloud – сервис для проведения автоматизированного тестирования приложения для сотен виртуальных мобильных устройств.
   
4. 
   ) Огромное число плагинов (компонентов) для увеличения возможностей Xamarin.
   
5. 
   ) Ориентирован на покупки внутри приложений (in-apppurchases).
   

Теперь переидем к самим средам разработки.


Рисунок 4 – Android Studio
Android Studio – среда разработки для устройств на платформе Android, взявшая в основу IntelliJ IDEA. Она предоставляет интегрированные компоненты для сборки, разработки и отладки, интерфейс представлен на рисунке 4. В добавок ко всем возможностям, ожидаемым от IntelliJ, в Android Studio реализованы:

1. 
   ) поддержка сборки приложения, взязвшей за основуGradle;
   
2. 
   ) быстрое исправление дефектов ирефакторинг, специфичный для Android;
   
3. 
   ) lint инструменты, предназначенные для поиска проблем с использованием, с производительностью;
   
4. 
   ) возможности ProGuard (утилита для обфускации, сокращения и оптимизации кода) и подписи приложений;
   
5. 
   ) основанные на шаблонах мастера для создания общих компонентов и конструкций для Android;
   
6. 
   ) WYSIWYG редактор, работающий почти на всех размерах экранов и разрешений, дающий, окно предварительного просмотра, показывающее запущенное приложение сразу на нескольких устройствах и в реальном времени;
   
7. 
   ) встроенная поддержка облачной платформы Google [12].
   

Следующая среда разработки из списка: Microsoft Visual Studio 2015 Ultimate.

В ней может выполняться сборка приложений на основе таких алгоритмических языков как: С/C++, C# компилируя его, для устройств на платформахIOS (некоторых ранних версиях) и Windows, а также предоставлять общий доступ к коду в библиотеках, собранных для IOS, Android и Windows, с помощью Visual C++ для разработки кроссплатформенных мобильных приложений. Эта возможность доступна в среде Visual Studio 2015 (рисунок 5), вместе с которой устанавливаются пакеты SDK и все компоненты, необходимые для кроссплатформенного создания общих библиотек и собственных приложений. После ее установки можно использовать Visual C++ для создания кода, выполняющегося не только в Windows, WindowsPhone и Xbox, но и на устройствах и платформах iOS и Android [13].

Написание кода для различных платформ может быть очень утомительным занятием. Основные языки и средства разработки под iOS, Android и Windows под каждую платформу различны между собой. Однако каждая из платформ поддерживает код написанный на языке C++. Это общий знаменатель, который обеспечивает возможность использования основной части кода на различных платформах. Машинный код, который был написан на языке C++, может быть более производительным и устойчивым к изменениям и реконструкциям. Использование кода повторно позволяет сэкономить силы и время при создании приложений под различные платформы.

Использование Microsoft Visual Studio для разработки кроссплатформенных мобильных приложений имеет несколько преимуществ.