Введение, где мы определим цели и актуальность нашего проекта
В современном мире мобильные технологии стали неотъемлемой частью повседневной жизни, а сектор финансовых приложений демонстрирует экспоненциальный рост. Пользователи все чаще доверяют смартфонам управление своими личными финансами, отслеживание расходов и планирование бюджета. Однако, несмотря на обилие решений на рынке, сохраняется проблема отсутствия универсальных, но при этом простых в использовании инструментов для комплексного финансового планирования, которые бы сочетали в себе как функции ежедневного учета, так и возможности для более сложных математических расчетов.
Актуальность данной курсовой работы обусловлена именно этим разрывом. Существующие приложения либо слишком упрощены и не удовлетворяют потребности продвинутых пользователей, либо, наоборот, перегружены профессиональными инструментами, что отталкивает широкую аудиторию. Настоящий проект нацелен на решение этой проблемы.
Цель работы: разработка мобильного приложения для Android, предоставляющего пользователям удобный и функциональный инструмент для ведения личного бюджета и проведения ключевых финансовых вычислений.
Для достижения поставленной цели необходимо решить следующие ключевые задачи:
- Проанализировать предметную область и существующие на рынке аналоги.
- Сформулировать детальные функциональные и нефункциональные требования к приложению.
- Обосновать выбор технологического стека для реализации проекта.
- Спроектировать архитектуру программного обеспечения, структуру базы данных и пользовательский интерфейс.
- Реализовать основные программные модули приложения.
- Провести комплексное тестирование для обеспечения качества и надежности продукта.
- Оценить экономическую эффективность разработанного решения.
Структура данной работы полностью соответствует поставленным задачам. Мы последовательно пройдем путь от анализа рынка и формулирования требований до практической реализации, тестирования и оценки жизнеспособности проекта, создав таким образом полный и исчерпывающий пример выполнения академической работы в области мобильной разработки.
Глава 1. Как глубокий анализ предметной области определяет успех проекта
Любой успешный продукт начинается не с кода, а с глубокого понимания контекста: рынка, конкурентов и, самое главное, потребностей будущего пользователя. Прежде чем приступить к проектированию, необходимо провести тщательный анализ предметной области, чтобы убедиться, что создаваемое приложение будет востребованным и конкурентоспособным.
Рынок мобильных финансовых приложений насыщен, однако его можно условно разделить на несколько категорий. Проанализировав 2-3 популярных приложения, мы можем выявить их сильные и слабые стороны. Например, Приложение А может предлагать превосходные инструменты для совместного ведения семейного бюджета, но не иметь функций для учета инвестиций. Приложение Б, напротив, может быть ориентировано на инвесторов, но его интерфейс для ежедневного отслеживания трат оказывается слишком сложным. Эта поверхностная оценка уже выявляет потенциальную нишу.
Портрет нашей целевой аудитории достаточно широк и включает в себя несколько сегментов:
- Студенты и молодые специалисты: нуждаются в простом инструменте для контроля первых заработков, формирования привычки к сбережениям и планирования крупных покупок.
- Семьи: ищут решение для ведения общего бюджета, отслеживания расходов по категориям (продукты, дети, коммунальные платежи) и планирования семейного отдыха.
— Начинающие инвесторы: требуют функциональности для расчета доходности, учета операций в разных валютах и базового финансового моделирования.
Анализ рынка и потребностей аудитории позволяет сформировать список ключевых функций, которые должны стать ядром нашего приложения. К ним относятся:
- Отслеживание доходов и расходов: базовый функционал, реализованный с максимальным удобством.
- Бюджетирование: возможность устанавливать лимиты расходов по различным категориям.
- Управление несколькими счетами: поддержка дебетовых карт, кредитных карт, электронных кошельков и наличных.
- Поддержка нескольких валют: автоматическая конвертация и отслеживание курсов для путешественников и фрилансеров.
- Генерация отчетов: наглядные графики и диаграммы для визуального анализа финансового положения.
- Сканирование чеков: функция для быстрого добавления транзакций без ручного ввода.
Пробел, который мы стремимся заполнить, — это отсутствие единого приложения, которое бы эффективно совмещало все эти функции с модулем для более сложных финансовых расчетов (например, сложных процентов или ROI), оставаясь при этом интуитивно понятным. Именно эта комбинация и станет нашим главным конкурентным преимуществом.
Глава 2. Формализация требований как фундамент для разработки
Проведенный в предыдущей главе анализ позволяет перейти от общих идей к созданию конкретного технического задания. Формализация требований — это критически важный этап, который служит фундаментом для всей последующей работы архитекторов, разработчиков и тестировщиков. Требования принято разделять на две основные группы: функциональные и нефункциональные.
Функциональные требования
Эта группа описывает, что система должна делать с точки зрения пользователя. Для нашего финансового приложения они включают:
- Управление транзакциями: Система должна позволять пользователю создавать, редактировать и удалять записи о доходах и расходах.
- Управление счетами: Пользователь должен иметь возможность добавлять и настраивать несколько счетов (например, «Банковская карта», «Наличные», «Сберегательный счет») с указанием начального баланса и валюты.
- Категоризация: Система должна предоставлять возможность присваивать каждой транзакции категорию (например, «Продукты», «Транспорт», «Развлечения») для последующего анализа.
- Валютные операции: Приложение должно поддерживать транзакции в нескольких валютах с отслеживанием актуальных курсов.
- Финансовые расчеты: Система должна включать калькулятор для расчета сложных процентов и рентабельности инвестиций (ROI).
- Отчетность: Система должна генерировать наглядные отчеты в виде круговых диаграмм (по структуре расходов) и гистограмм (динамика доходов/расходов по времени).
- Синхронизация данных: Данные пользователя должны безопасно синхронизироваться между его устройствами (при наличии аккаунта).
Нефункциональные требования
Эта группа определяет, как система должна выполнять свои функции, и описывает ее качественные атрибуты.
- Производительность: Время отклика на основные пользовательские действия (добавление транзакции, открытие отчета) не должно превышать 1.5 секунды на целевых устройствах.
- Безопасность: Все пользовательские данные, хранящиеся локально на устройстве, должны быть зашифрованы. Для доступа в приложение должна быть предусмотрена возможность установки PIN-кода или биометрической аутентификации.
- Удобство использования (Usability): Интерфейс приложения должен быть интуитивно понятным для целевой аудитории. Процесс добавления транзакции должен занимать не более трех кликов с главного экрана.
- Совместимость: Приложение должно корректно функционировать на устройствах под управлением ОС Android, начиная с версии 9.0 (Pie) и выше.
Глава 3. Обоснованный выбор технологического стека для решения задачи
После формализации требований следующим логическим шагом является выбор инструментов — технологического стека, который позволит наиболее эффективно и качественно реализовать задуманный проект. Выбор каждого компонента должен быть аргументирован.
Мобильная платформа: Android. Для курсового проекта была выбрана операционная система Android. Этот выбор обусловлен несколькими факторами: во-первых, Android занимает доминирующую долю на мировом рынке мобильных ОС, что обеспечивает максимальный охват потенциальной аудитории. Во-вторых, среда разработки для Android является полностью бесплатной и кроссплатформенной, что снижает порог входа для разработки.
Среда разработки (IDE): Android Studio. Android Studio является официальной и наиболее мощной средой разработки для платформы Android. Она предоставляет интегрированные инструменты для дизайна интерфейсов, отладки, профилирования производительности и управления зависимостями, что делает ее безальтернативным выбором для создания качественного продукта.
Язык программирования: Kotlin. В качестве основного языка программирования выбран Kotlin. Несмотря на то что Java остается поддерживаемым языком, Kotlin, официально рекомендованный Google, предлагает более лаконичный и безопасный синтаксис. Его встроенная защита от NullPointerException (NPE) и поддержка современных программных парадигм позволяют писать более надежный и поддерживаемый код, сокращая время разработки.
Архитектура и СУБД. Для приложения выбрана клиент-серверная архитектура, хотя на первом этапе серверная часть может быть опциональной. Локально на устройстве данные будут храниться в легковесной реляционной базе данных SQLite, которая встроена в Android SDK и идеально подходит для структурированных данных (счета, транзакции, категории). Использование клиент-серверной архитектуры в перспективе позволит реализовать синхронизацию данных между устройствами через собственный API. В качестве академического примера стоит отметить, что для корпоративного сегмента подобная архитектура могла бы предусматривать интеграцию с такими системами, как «1С: Предприятие 8.3», для обмена финансовыми данными.
Глава 4. Проектирование архитектуры и пользовательского интерфейса
Определив инструментарий, мы переходим к созданию «чертежа» нашего приложения. На этом этапе детально прорабатывается как его внутренняя структура (архитектура), так и внешний вид (UI/UX), что позволяет минимизировать ошибки и неопределенность на этапе программирования.
Архитектура программного обеспечения
Для обеспечения гибкости, масштабируемости и тестируемости приложения был выбран архитектурный паттерн MVVM (Model-View-ViewModel). Этот паттерн разделяет код на три логических слоя:
- Model (Модель): Ответственна за бизнес-логику и данные. В нашем случае это слой, который работает напрямую с базой данных SQLite, выполняет финансовые расчеты (сложные проценты, ROI) и предоставляет данные остальным частям приложения.
- View (Представление): Это UI-слой (экраны, кнопки, графики), который отвечает исключительно за отображение данных и передачу действий пользователя в ViewModel. В Android это реализуется с помощью Activity и Fragment.
- ViewModel (Модель Представления): Служит посредником между Model и View. Она запрашивает данные из модели, подготавливает их для отображения и предоставляет представлению. ViewModel ничего не знает о конкретных элементах UI, что позволяет легко тестировать логику отображения.
Проектирование структуры базы данных
Для локального хранения данных с помощью SQLite была спроектирована следующая структура основных таблиц:
Таблица `accounts`: (id_account, name, balance, currency_code)
Таблица `transactions`: (id_transaction, amount, type, date, description, account_id, category_id)
Таблица `categories`: (id_category, name, type)
Такая реляционная модель обеспечивает целостность данных и позволяет эффективно выполнять запросы, например, для генерации отчетов по расходам в разрезе категорий за определенный период.
Проектирование пользовательского интерфейса (UI) и взаимодействия (UX)
Внешний вид и логика взаимодействия являются ключевыми для удержания пользователя. Были спроектированы макеты ключевых экранов:
- Главный экран: Отображает сводную информацию — общий баланс, диаграмму структуры расходов за текущий месяц и ленту последних операций. Ключевой элемент — большая кнопка «+» для быстрого добавления транзакции.
- Экран добавления транзакции: Содержит поля для ввода суммы, выбора счета списания/зачисления, выбора категории, даты и добавления короткого описания.
- Экран отчетов: Предоставляет пользователю возможность выбрать период и тип отчета (например, «Расходы по категориям»), который визуализируется в виде интерактивного графика.
Сценарий взаимодействия (UX) для добавления новой транзакции выглядит следующим образом:
- Пользователь нажимает кнопку «+» на главном экране.
- Открывается модальное окно или новый экран «Новая транзакция».
- Пользователь вводит сумму с помощью цифровой клавиатуры.
- Выбирает счет списания из выпадающего списка (по умолчанию — основной).
- Выбирает категорию (система может предлагать наиболее частые).
- Нажимает «Сохранить». Система возвращает пользователя на главный экран, где баланс и диаграмма расходов мгновенно обновляются.
Такой детальный проект позволяет команде разработки иметь четкое представление о конечном продукте еще до написания первой строки кода.
Глава 5. Воплощение проекта в жизнь через реализацию программных модулей
На этапе реализации теоретические модели, архитектурные решения и дизайн-макеты превращаются в работающий программный продукт. Процесс разработки велся модульно, что позволило концентрироваться на отдельных функциональных блоках, обеспечивая их качество и независимость.
Модуль управления транзакциями
Это ядро приложения, отвечающее за базовые CRUD-операции (Create, Read, Update, Delete) с транзакциями. Его реализация тесно связана со всеми слоями архитектуры MVVM. Когда пользователь заполняет форму на экране (View) и нажимает «Сохранить», ViewModel получает объект с данными о транзакции и передает его в репозиторий слоя Model. Модель, в свою очередь, сохраняет эти данные в локальную базу данных SQLite. Для отображения списка операций используется компонент `RecyclerView`, который эффективно обрабатывает даже большие объемы данных, обеспечивая плавную прокрутку.
Модуль финансовых вычислений
Один из самых сложных и ответственных модулей, демонстрирующий математическую состоятельность приложения. Здесь были реализованы функции для ключевых финансовых расчетов. Важно было не просто написать формулы, но и обеспечить их точность и производительность. Ниже приведен упрощенный пример реализации функции расчета сложных процентов на языке Kotlin:
fun calculateCompoundInterest( principal: Double, // Начальная сумма rate: Double, // Годовая ставка (в долях, например, 0.08 для 8%) periods: Int, // Количество периодов начисления в год years: Int // Срок в годах ): Double { val amount = principal * Math.pow(1 + rate / periods, (periods * years).toDouble()) return Math.round(amount * 100) / 100.0 // Округляем до 2 знаков после запятой }
Аналогичным образом в этом модуле были реализованы и другие модели, такие как расчет рентабельности инвестиций (ROI) и вычисление параметров для простых аннуитетов. Этот функционал вынесен в отдельный класс-утилиту, что позволяет легко тестировать его независимо от остального приложения.
Модуль отчетов
Для визуализации данных и превращения сухих цифр в понятную инфографику был реализован модуль генерации отчетов. Для построения графиков и диаграмм использовалась популярная библиотека MPAndroidChart. Процесс генерации отчета выглядит следующим образом:
- ViewModel запрашивает у слоя Model агрегированные данные из БД (например, сумму транзакций, сгруппированную по категориям за последний месяц).
- Model выполняет соответствующий SQL-запрос и возвращает данные.
- ViewModel преобразует полученный набор данных в формат, понятный для библиотеки MPAndroidChart.
- Подготовленные данные передаются во View (Fragment), где компонент `PieChart` или `BarChart` отрисовывает их, создавая наглядный визуальный отчет для пользователя.
Такой подход к реализации, основанный на четком разделении ответственности между модулями и слоями архитектуры, позволил создать надежную и масштабируемую основу для дальнейшего развития приложения.
Глава 6. Комплексное тестирование как гарантия качества и надежности
После завершения этапа разработки необходимо провести всестороннюю проверку приложения, чтобы убедиться в его качестве, стабильности и соответствии требованиям, сформулированным в Главе 2. Тестирование — это не просто поиск ошибок, а процесс подтверждения того, что продукт готов к использованию.
Методология тестирования включала несколько уровней:
- Модульное тестирование (Unit Testing): Проводилась проверка отдельных, изолированных компонентов системы. Особое внимание уделялось модулю финансовых вычислений. Например, функция `calculateCompoundInterest` проверялась с десятками различных входных данных (целые и дробные числа, нулевые значения, большие числа) для сверки результатов с эталонными расчетами.
- Интеграционное тестирование: На этом этапе проверялось корректное взаимодействие между разными модулями. Например, тестировался сценарий «добавление транзакции -> сохранение в БД -> обновление баланса счета -> отображение в отчете». Цель — убедиться, что модули правильно обмениваются данными.
- Тестирование пользовательского интерфейса (UI Testing): Проверялась корректность верстки на экранах с разным разрешением и соотношением сторон, а также отклик интерфейса на действия пользователя (нажатия кнопок, свайпы).
Результаты ключевых тест-кейсов были занесены в таблицу для наглядности.
Тест-кейс | Ожидаемый результат | Фактический результат |
---|---|---|
Добавление транзакции расхода | Транзакция появляется в списке. Баланс соответствующего счета уменьшается на сумму транзакции. | Совпадает |
Расчет сложного процента | Результат расчета в приложении совпадает с эталонным значением, рассчитанным вручную. | Совпадает |
Генерация отчета по категориям | Диаграмма корректно отображает доли расходов по всем категориям за выбранный период. | Совпадает |
Смена ориентации экрана | Приложение не «падает», все введенные данные на экране сохраняются. | Совпадает |
По результатам комплексного тестирования можно сделать вывод, что разработанное приложение работает стабильно, выполняет свои функции в соответствии с требованиями и готово к следующему этапу оценки.
Глава 7. Расчет экономической эффективности и жизнеспособности проекта
Технически успешный проект — это лишь половина дела. Для оценки его полного потенциала необходимо проанализировать экономическую составляющую: затраты на создание и возможные пути монетизации. Этот раздел демонстрирует понимание бизнес-аспектов разработки.
Расчет затрат на разработку
Для курсовой работы затраты можно рассчитать условно, исходя из трудозатрат. Предположим, что над проектом работал один разработчик.
- Анализ и проектирование: 40 часов
- Разработка (кодирование): 200 часов
- Тестирование и отладка: 60 часов
Итого трудозатрат: 300 человеко-часов. При условной ставке специалиста в 1000 рублей/час, общие затраты на разработку составляют 300 000 рублей. Этот расчет не включает затраты на маркетинг и поддержку, но служит хорошей отправной точкой.
Прогноз доходов и модель монетизации
Для приложения выбрана модель Freemium. Основной функционал (учет транзакций, отчеты) предоставляется бесплатно для привлечения широкой аудитории. Продвинутые функции монетизируются:
- PRO-подписка (199 руб/год): Включает синхронизацию между устройствами, расширенные отчеты, совместное ведение бюджетов и сканирование чеков.
Прогноз выручки строится на основе воронки:
Привлечение 15 000 бесплатных пользователей в первый год.
Конверсия в платную подписку: 2%.
Прогнозируемая выручка за первый год: 15 000 * 0.02 * 199 = 59 700 рублей.
Расчет ключевых показателей эффективности
На основе данных о затратах и доходах можно рассчитать основные финансовые метрики.
Рентабельность инвестиций (ROI) за первый год:
ROI = (Доход — Затраты) / Затраты = (59 700 — 300 000) / 300 000 = -80.1%.
Отрицательный ROI в первый год является нормой для большинства стартапов.
Срок окупаемости инвестиций (Payback Period):
PP = Сумма инвестиций / Среднегодовой доход = 300 000 / 59 700 ≈ 5 лет.
Этот показатель говорит о том, что при текущих прогнозах проект окупит начальные вложения через 5 лет, что является приемлемым сроком для венчурного проекта.
Таким образом, несмотря на начальные убытки, проект имеет коммерческий потенциал при условии успешного маркетинга и постепенного увеличения пользовательской базы и конверсии.
Заключение, где мы подводим итоги и намечаем пути для развития
В начале данной курсовой работы была поставлена цель — разработать мобильное приложение для Android, предоставляющее пользователям удобный инструмент для ведения личного бюджета и проведения финансовых вычислений. Пройдя все этапы от анализа до тестирования и экономического обоснования, можно с уверенностью утверждать, что поставленная цель полностью достигнута.
В ходе работы были получены следующие ключевые результаты:
- Проведен детальный анализ рынка финансовых приложений, выявлены потребности целевой аудитории и определена конкурентная ниша.
- Сформулированы исчерпывающие функциональные и нефункциональные требования, послужившие техническим заданием для проекта.
- Обоснован выбор современного технологического стека (Kotlin, MVVM, SQLite), оптимального для решения поставленных задач.
- Спроектирована и реализована надежная архитектура приложения, включая структуру базы данных, ключевые программные модули (управление транзакциями, финансовые расчеты, отчетность).
- Комплексное тестирование подтвердило стабильность, корректность работы и соответствие приложения заявленным требованиям.
- Расчет экономической эффективности показал коммерческую жизнеспособность проекта в долгосрочной перспективе.
Проект успешно доказал свою состоятельность как с технической, так и с академической точки зрения. Однако любой IT-продукт требует постоянного развития.
Возможные направления для дальнейшего развития приложения:
- Интеграция с банковскими API: Добавление функции автоматической загрузки транзакций из банковских приложений (с разрешения пользователя) кардинально повысит удобство использования.
- Развитие инвестиционного модуля: Создание полноценного инструмента для ведения инвестиционного портфеля с учетом дивидендов, комиссий и налогов.
- Внедрение элементов машинного обучения: Автоматическая категоризация расходов и предоставление персональных советов по оптимизации бюджета на основе анализа данных пользователя.
- Создание версии для iOS: Расширение аудитории за счет выхода на вторую по популярности мобильную платформу.
Таким образом, представленная курсовая работа является не только законченным исследованием, но и прочным фундаментом для создания реального, конкурентоспособного продукта на рынке мобильных приложений.
СПИСОК ИСТОЧНИКОВ.
- Амелин К.С., Граничин О.Н. и др. Введение в разработку приложений для мобильных платформ — СПб.: Изд-во ВВМ, 2011. — 518 с.
- Блау, С.Л. Финансовая математика: Учеб. для студ. учреждений сред. проф. образования / С.Л. Блау, С.Г. Григорьев. – М.: ИЦ Академия, 2013. – 192 c.
- Борисов В.В. iPhone для пользователя СПб.: БХВ-Петербург, 2014. — 176 с.
- Брусов, П.Н. Финансовая математика: Учебное пособие / П.Н. Брусов, П.П. Брусов, Н.П. Орехова. – М.: КноРус, 2013. – 224 c.
- Дейтел П., Дейтел Х., Дейтел Э., Моргано М. Android для разработчиков СПб.: Питер, 2015. — 384 с.
- Дремова Марина. 100 секретов работы на планшетах с Android, о которых должен знать каждый М.: Эксмо, 2016. — 224 с.
- Касимов, Ю.Ф. Финансовая математика: Учебник для бакалавров / Ю.Ф. Касимов. – М.: Юрайт, 2012. – 335 c.
- Кристиан Нейгел и др. C# 5.0 и платформа .NET 4.5 для профессионалов = Professional C# 5.0 and .NET 4.5. – М.: «Диалектика», 2013. – 1440 с.
- Леонтьев В.П. Новейший самоучитель Андроид для планшетов и смартфонов Москва: Эксмо, 2015. — 288 с.
- Машнин Т.С. Eclipse разработка RCP-, Web-, Ajax — и Android-приложений на Java СПб.: БХВ-Петербург, 2013. — 384 с.
- Нахавандипур В. iOS. Приемы программирования СПб.: Питер, 2014. — 832 c.
- Пайлон Д., Пайлон Т. Программируем для iPhone и iPad (+ исходники программ) 3-е издание. — СПб.: Питер, 2014. — 336 с.
- Самаров, К.Л. Финансовая математика: сборник задач с решениями: Учебное пособие / К.Л. Самаров. – М.: Альфа-М, ИНФРА-М, 2011. – 80 c.
- Семакова А. Введение в разработку приложений для смартфонов на ОС Android М.: НОИ Интуит, 2016. — 102 с.
- Уорнер Тимоти Л. Неофициальное руководство по ремонту iPhone, iPad и iPod М.: ДМК Пресс, 2014. — 256 с.
- Фиртман Максимилиано. Веб-программирование для мобильных устройств М.: ООО Рид Групп, 2012. –576 с.
- Четыркин, Е.М. Финансовая математика: Учебник / Е.М. Четыркин. – М.: ИД Дело РАНХиГС, 2011. – 392 c.
- Чуйко, А.С. Финансовая математика: Учебное пособие / А.С. Чуйко, В.Г. Шершнев. – М.: НИЦ ИНФРА-М, 2013. – 160 c.
- Интерфейсы мобильных приложений: дизайн и эргономика [Электронный ресурс]. URL: https://habrahabr.ru/company/alee/blog/117950/
- Статистика мобильных операционных систем за 2-й квартал 2015 [Электронный ресурс]. URL: http://www.oszone.net/27945/The_state_of_the_smartphone_market_Q2_2015_Gartner#prettyPhoto