V Международная студенческая научная конференция Студенческий научный форум - 2013

ведение

На сегодняшний день рынок мобильных приложений является быстро развивающейся сферой для вклада интеллектуальных, физических и финансовых ресурсов. Однако не все приложения, доступные в официальных интернет-магазинах, таких как Google Play, AppStore, Marketplace, удобны для пользования и соответствуют требованиям, которые будут описаны дальше. Именно по этой причине целью данной статьи – определить какие же требования должны предъявляться к приложению как с точки зрения дизайна, так и с точки зрения работы приложения в целом.

Для выбора приложения, к которому и будут предъявлены требования не нужно "далеко уходить" от реальности. Достаточно посмотреть на современный мир. У каждого человека огромное количество дел, как на работе, так и в семейном кругу. Однако к этим делам прибавляется один из главных аспектов современности - финансовый аспект. Зачастую тратится огромное количество сил и времени на планирование и надлежащий контроль личных или семейных финансов. Возникает логический вопросом, "Что будет, если отдать часть обязанностей по контролю финансов некому "роботу", мобильному приложению?"

И, несмотря на то, что подобных приложений на рынке достаточно, именно мобильных приложений по контролю и отслеживанию финансовых потоков индивида, как оказалось, не так много(удалось найти Home Budget, Checkbox – Personal manager, Bills и т.д.). Именно поэтому разработка приложений для данной сферы достаточна перспективна и само приложение будет довольно востребовано.

В первую очередь необходимо определить целевую аудиторию приложения. Так как прежде всего приложение будет удовлетворять нужды "загруженных" людей, основным контингентом пользователей будут молодые люди 20-35 лет, которые уже не могут представить жизнь без мобильных технологий. Однако не стоит забывать и о людях старше 35. Сегодняшние тенденции показывают, что 80% населения активно используют мобильные устройства (смартфоны, планшетные ПК) и 5/6 из этого количества – люди 20-35 лет, однако 1/6 людей старше, следовательно, они тоже являются потенциальными пользователями приложения.

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

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

Жизненный цикл приложения

Каждая программа проходит несколько стадий до начала своего полноценного существования и выхода на рынок.

Первая стадия – разработка идеи, определение того, что приложение будет делать и для кого.

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

Таким образом, согласно пункту 2.5 ГОСТ 34.602-89 «Характеристики объекта автоматизации», мы установили объект автоматизации нашим приложением – управление личными финансами.

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

Выработанные требования должны быть оформлены в техническом задании. Оно должно быть написано с учетом всех пунктов ГОСТ 34.602-89 , ГОСТ 24.601, и так же на понятном языке для заказчика с целью того, чтобы расставить все детали будущего приложения "по полочкам", так как после проделанной работы может оказаться, что приложением попросту невозможно пользоваться и оно не соответствует требованиям заказчика; и, пожалуй, главным аспектов для понятного усваивания информации в ТЗ является то, что оно должно быть оформлено в соответствии с ГОСТ 2.301.Также некорректно определенные требования к разработке приложения могут стать огромной проблемой и уничтожить весь текущий прогресс, тем самым заставив вернуться на начальную стадию, что отсрочит готовность приложения на неопределенный срок. На данной стадии необходимо понять следующее: как снизить объем потребляемых системных ресурсов, как уменьшить риск непредвиденных аварийных ситуаций и как нормализировать работу приложения.

И финальной стадией разработки приложения являются приемо-сдаточные испытания, предполагающие тестирование. Разработка мобильных приложений требует многогранного тестирования, чтобы в будущем обезопасить себя и будущего пользователя от неожиданных сбоев в системе. Не для всех приложений нужна такая разносторонняя проверка, например, для приложений социальных «Вконтакте» и одноклассники нужна оперативность тестирования.

Назначение приложения

Рассмотрим идею и возможности применения приложения.

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

Рассмотрим процесс распоряжения и регулирования денежных средств рядового человека(рис 1).

Каждый месяц человек получает деньги(зарплата/выручка и тп). Для регулирования потока денег, человек должен запоминать, подсчитать их количество. На протяжении месяца человек совершает покупки и оплату за услуги. После их совершения человек записывает сколько денег он потратил на это в, назовем это так, "тетрадь затрат". Далее это повторяется до тех пор, пока либо деньги не кончатся, либо не удовлетворятся потребности человека. Далее необходимо прочитать из "тетради" сколько, на что и когда была потрачена определенная сумма денег, затем высчитать итоговую сумму затрать, вспомнить начально полученную сумму денег и вывести свой бюджет.

Однако благодаря мобильному приложению по управлению личными финансами ранее описанный процесс будет выглядеть иначе(рис 2).

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

Из этого следует вывод, что используя приложение человек:

1. избавляет себя от необходимости запоминать и подсчитывать количество своих денег

2. избавляет себя от необходимости высчитывать текущее состояние своего бюджета

3. избавляет себя от необходимости излишнего занесения информации в "тетрадь затрат"

Требования к приложению

Следующий пункт, который необходимо рассмотреть – требования к приложению. Небезызвестный факт, что следует ставить перед собой «высокие цели», почти недостижимо-высокие, а после пытаться дотянуться до них. Так и в разработке приложения и требований к нему нужно подходить со стороны оптимизма, ставить задачи куда более высокие, чем можно себе позволить и бросать все силы на их исполнение.

По этой причине в данной статье требования будут выдвигаться со стороны «оптимизма», то есть будут предъявлены наиболее сложные требования к разрабатываемому приложению.

Так как идея уже определена(создать механизм учета расходуемых и потребляемых благ), можно перейти к более конкретным параметрам.

Согласно ГОСТ 34.602-89 в требованиях к приложению (АС) должны быть предъявлены требования к входным данным приложения, требования к системе, запрашиваемой приложением.

Рис. Контролирование финансов	Рис. Контролирование финансов с приложением

Данное приложение будет разрабатываться в соответствие со следующими требованиями:

1.  
   1.  
      1. Требования к входные данные.

Что будет использоваться в качестве входных данных – это то, что необходимо ввести, чтобы приложение работало:

1. потребуется ввод бюджета, которым располагает пользователь;

2. краткое описание потребляемых товаров с указанием их стоимости. Следует отметить, что пользователь должен иметь возможность единожды записав свои регулярные расходы, выбирать их из предлагаемого списка. Рис. 3

Рис. Контролирование финансов

Предположим, пользователь приложения ежедневно выполняет три процедуры: заправляет автомобиль, покупает продукты в магазине и паркует автомобиль около места работы. Таким образом, чтобы не тратить время на ввод наименование статьи расхода, человек может заранее записать его в базу данных, а впоследствии выбирать нужное из списка, дополнительно указав стоимость.

1. Пользователь должен иметь возможность корректировать бюджет, как в положительную ,так и в отрицательную сторону. Рис. 4

Рис. корректировка бюджета

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

1. Временные данные буду заполняться автоматически в историю трат(согласно текущей дате и времени на устройстве). Рис. 5

Рис. История трат

Пользователь должен иметь возможность просматривать историю покупок со всей необходимой информацией.

1.  
   1.  
      1. Требуемые ресурсы ПО аппаратного устройства.

Согласно пункту 2.6.1 ГОСТ 34.602-89 «Требования к системе в целом» , 2.6.2 «Требования к функциям(задачам)», 2.6.3 «Требования к видам обеспечения» к разрабатываемому приложению должны предъявляться следующие требования:

1. Требования к системе в целом:

• Приложение должно занимать не более 1 мб оперативной памяти устройства;

• Приложено должно свободно функционировать на устройствах с минимальной мощностью в 400 МГЦ.

1. Требования к функциям(задачам):

• Приложение не должно завершаться аварийно.

• Приложение должно продолжать свое функционирование после сворачивания с целью осуществления другой функции устройства.

• Полное и безошибочное осуществление заявленных функций.

• Корректный перенос бюджета с одного месяца на другой.

• При удалении информации пользователем осуществляется очистка данных из БД.

• Низкий уровень энергозатратности.

1. Требования к видам обеспечения:

• Минимальная версия фреймворк, на которой приложение должно свободно функционировать – API 2.2, однако и на API 4.0 приложение должно работать корректно.

Заключение

На данном этапе разработки приложения (разработка требований к приложению) достигнуто ясное и явное понимания того, что предстоит сделать при проектировании самого приложения. Это является главной целью в разработке требований.

С учетом этих требований предполагается реализовать приложение с использованием Eclipse SDK Android, так как данный инструментарий обеспечивает возможность кроссплатформенной разработки.

Код для цитирования: Скопировать