Деревенец, Дудкин. Испокон веков человек испытывал много трудностей, связанных с жизнедеятельностью, но основной проблемой всегда была добыча пропитания. Люди тратили большое количество времени на приготовление пищи
Скачать 2.95 Mb.
|
3.5 Реализация программных модулей мобильного приложения для сотрудников3.5.1 Модуль “входа” На экране входа сотруднику лишь необходимо указать свой ID и пароль (Рис. 3.11). Рисунок 3.11 окно входа для сотрудника 3.5.2 модуль “главная” страница для сотрудниковГлавная страница для сотрудников содержит панель с самым продаваемым товаром за месяц, а также статистику по полученным заказам в определенный промежуток времени (Рис. 3.12). Рисунок 3.12 главная страница для сотрудников 3.5.3 модуль “отзывы”Модуль “отзывы” содержит рейтинг определенных позиций, среднюю оценку и качественное описание оценок в виде “в основном отрицательные” или “в основном положительные” (рис.3.13). Рисунок 3.13 отзывы 3.5.4 модуль “история заказов”Содержит историю заказов, оборудован фильтрацией по дням, неделям и месяцам (рис. 3.14). Рисунок 3.14 история заказов 3.5.5 модуль “статистика”Данный экран показывает количество заказанных позиций за определенный промежуток времени, и рассчитывает их популярность (рис 3.15). Рисунок 3.15 окно статистики Вывод к 3 главеВ результате выполнения третьей главы были реализованы компоненты необходимые для работы приложения. А именно: Была выбрана система для разработки; Был выбран язык программирования; Была реализована база данных приложения; Был реализован интерфейс приложения; Были разработаны все модули приложения. Рассмотрена результативность мобильного приложения. В заключение возможно сделать вывод, на основании рассмотренных объектов и описания функциональных возможностей, что мобильное приложение работает исправно и удовлетворяет установленной задаче. 4 ОБОСНОВАНИЕ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ4.1 Расчет трудозатрат на разработку мобильного приложенияВ среднем проектирование мобильного приложения занимает от одного до трёх месяцев. Сроки и смета проекта рассчитываются на основании количества нормо-часов на каждый аспект приложения. Рассмотрим расходы на проект по этапам разработки мобильного приложения. Сначала определяем социально-демографический срез аудитории и маркетинговые задачи. На этом этапе заказчику стоит определиться, как он намеревается пользоваться приложением, какая окончательная цель разработки мобильного приложения. Вот перечень приблизительных вопросов, на которые стоит найти ответы, прежде чем формулировать ТЗ и заказывать разработку приложения: каких целей вы намереваетесь достичь путем создания и релиза собственного мобильного приложения? каков бюджет на разработку и продвижение полученного приложения? планируются ли продажи / конверсия переходов в продажу товаров и услуг в рамках приложения? кто ваша целевая аудитория и за счет кого она может пополниться? какими приложениями пользуется ваша аудитория и аудитория ваших конкурентов, пересекаются ли они между собой? Готовы ли они пользоваться вашим приложением вместо приложений-аналогов? насколько высока конкуренция в сфере, в которой вы планируете работать (в том числе – с приложением)? Затем определяется наиболее уместная платформа, для которой необходимо мобильное приложение и разрабатывается концепция мобильного приложения и механизм вовлечения аудитории. Необходимо сформировать Техническое Задание с учетом пожеланий клиента, сформировать сценарии применения приложения. В первую очередь нужно определить, какие потребности пользователей и клиента обязано решать приложение, а также сформулировать его основные задачи. Этому этапу уделяется особое внимание: от задания зависят технические особенности будущего продукта. Упустив даже незначительную на первый взгляд деталь и не заложив ее в архитектуру приложения, можно встретиться с необходимостью переделывать его практически с нуля. На этом этапе создатель мобильного приложения: составляет подробное описание функционала приложения; определяет временные рамки и финансовые затраты на работу; оформляет договор. На следующем этапе происходит конструирование эффективного интерфейса. Теперь создаётся основа графического интерфейса, карта экранов, макет низкой детализации, а также пользовательские сценарии и дизайн кода приложения. Поскольку приложения, как правило, работают с сервером, итогом этапа проектирования также являются требования к серверной стороне по части взаимодействия с мобильным приложением (спецификация API). Чтобы понять, как покупатель будет пользоваться приложением, создают графическую карту взаимодействия между экранами, также на данном этапе прорабатывается практически весь функционал продукта. конструирование UI/UX является разработкой прототипа приложения: мы реализуем все описанные в техническом задании функции, определяем, как будет работать приложение и как будет работать с ним пользователь, продумываем, какие кнопки и какой функционал будет размещен на каждом экране. На этом этапе разработчик: оттачивает функционал приложения и окончательно продумывает сценарий поведения пользователя; разрабатывает схемы всех экранов с указанием функционала на каждом из них; на схеме показывает связь всех экранов, то есть продумываем, как пользователь будет переходить на них. Далее нужно скорректировать интерфейс, сформировать окончательный дизайн, создает концепцию дизайна для мобильных приложений. На основных экранах приложения находится его будущий дизайн, отталкиваясь в первую очередь от целей, аудитории и функционала. На этом этапе: детально прорабатываются от 1 до 3 экранов будущего приложения; при необходимости создается дизайн в нескольких разных стилях, чтобы выбрать наиболее подходящий. На следующем этапе верстают все элементы приложения, т. из статичной картинки осуществляем интерактивную рабочую модель. Также мы объединяем серверную и клиентскую части приложения, дабы оно взаимодействовало с пользователем и полноценно работало. В результате получают первую версию функционирующего приложения; отсылают заказчику тестовое приложение, который он может установить на свои мобильные устройства под управлением операционной системы Android. Впоследствии происходит тестирование на предмет возможных ошибок. Приложение тестируется на соблюдение всех требований, указанных в ТЗ. Если приложение каким-либо образом не соответствует одному из пунктов ТЗ – оно в кратчайшие сроки доводится за наш счет до полного соответствия. Если какой-либо функционал не описан в ТЗ (но подразумевается заказчиком) – он реализуется после приемки и оплаты основных работ за отдельную стоимость. Происходит полная отладка приложения. Проектируя приложение на экране монитора, невозможно предусмотреть все особенности его живого использования. Все приложения уникальны, и возникновение ошибок на первом этапе работы неизбежно. В большинстве случаев отладка занимает примерно четверть времени от первоначальной разработки. Далее необходимо совершить регистрацию в необходимых магазинах мобильных приложений, выход мобильного приложения, размещение приложения в магазине. Политика проверки приложений Android достаточно либеральная, приложения проходят лишь поверхностную проверку. Если приложение не содержит вредоносного ПО или материалов, оскорбляющих социальную нравственность – с большой долей вероятности оно будет принято в Google. После публикации мобильного приложения работу продолжает вести служба техподдержки, которая как помогает пользователям решить их проблемы, так и определяет наличие конкретных дефектов (багов) приложения, которые подлежат исправлению. Важно понимать, что хорошие приложения появляются не в один момент, а в результате длительной работы по анализу пользовательского поведения с комплексным совершенствованием свойств и метрик. Приложения нуждаются в сопровождении на протяжении всего их жизненного цикла. Трудозатраты измеряются в чел*час. Расчет производится по формуле: T = tи + tа + 𝑡п + tотл + tд где tи – затраты труда на изучение задачи; tа – затраты на разработку модели системы; tп – затраты на программирование; tотл – затраты на отладку программы; tд – затраты на подготовку документации. Затраты труда на изучение задачи с учетом уточнения описания и квалификации программиста вычисляются по формуле: 𝑡и = Q ∙ B / (75 … 85) ∙ 𝑘, где Q– условное число операторов в программе; В – коэффициент увеличения затрат в зависимости от сложности программы (1,2...5); K–коэффициент квалификации разработчика. Составляющие затраты труда можно определить через условное число операторов в программном продукте. В их число входят те операторы, которые нужно учесть программисту в процессе работы над задачей с учетом возможных уточнений постановки задачи и совершенствования алгоритма. Q = q ∙ c ∙ (1 + 𝑝), где q – предполагаемое число операторов; с – коэффициент сложности программы (от 1 до 2); р – коэффициент коррекции программы в ходе ее разработки (от 0,5до 1). Для расчета затрат следует применить следующие значения: q = 150; c = 1,8; p = 0,7; Условное число операторов составляет: Q = 150 ∙ 1,8 ∙ 1 + 0,7 = 459 операторов. Коэффициент увеличения затрат характеризует увеличение затрат труда вследствие недостаточно полного описания задачи, уточнений и некоторой доработки. Этот коэффициент может принимать значения от 1,2 до 5. Необходимо взять среднее для наиболее точных расчетов: В = 3 Коэффициент квалификации разработчика зависит от стажа работы программиста следующим образом: стаж до 2 лет – к = 0,8; от 2 до 3 лет – к = 1; от 3 до 7 лет – к = 1,3...1,4; от 7 лет – к = 1,5...1,6. Так как предусмотрен небольшой набор операторов, можно будет нанимать разработчика с малым опытом работы: к = 0,8 (стаж работы до 2 лет) Затраты труда на изучение задачи составят: 𝑡и = 459 ∙ 3/ 75 ∙ 0,8 = 22,95 чел ∗ час. Расчет затрат на разработку модели системы производится по формуле: 𝑡а = Q / (60 … 75) ∙ 𝑘, (3.4) где Q– условное число операторов; k – коэффициент квалификации разработчика. Затраты на разработку модели системы составят: 𝑡а = 459 / (70 ∙ 0,8) = 8,2 чел ∗ час. Далее необходимо рассчитать трудозатраты на отладку программы программистом. Расчет трудозатрат на отладку производится по формуле: 𝑡отл = Q / (40 … 50) ∙ 𝑘 (3.5) Затраты на отладку программы на компьютере составят: 𝑡отл = 459 / (45 ∙ 0,8) = 12,75 чел ∗ час. При комплексной отладке программы следует предусмотреть возрастающие в 1,5 раза затраты, поэтому окончательные трудовые затраты на отладку программы будут равны: 𝑡отл.ок = 𝑡отл ∙ 1,5 Затраты на окончательную отладку программы на ПК составят: 𝑡отл.ок = 12,75 ∙ 1,5 = 19,125 чел ∗ час. Трудовые затраты на подготовку документации включают в себя затраты труда на подготовку рукописного текста и затраты труда на редактирование, печать и оформление документации. 𝑡д = 𝑡дп ∙ 𝑡др, где tдп– затраты труда на подготовку материалов в рукописи; tдр– затраты труда на редактирование, печать и оформление различной документации. Трудозатраты на подготовку материалов в рукописи рассчитываются по формуле: 𝑡дп = Q / (150 … 200) ∙ k, где Q– условное число операторов; k–коэффициент квалификации разработчика. Исходя из имеющихся данных, трудозатраты на подготовку материалов в рукописи составят: 𝑡дп = 459/ (175 ∙ 0,8) = 3,28 чел ∗ час. Затраты на редактирование, печать и оформление tтр прямо пропорционально зависит от затрат на подготовку материалов в рукописи: 𝑡др = 0,75 ∙ 𝑡дп Результаты расчетов: 𝑡др = 0,75 ∙ 3,28 = 2,46 чел ∗ час. Таким образом, общие трудовые затраты на подготовку документации составят: 𝑡д = 3,28 + 2,46 = 5,74 чел ∗ час. Теперь необходимо провести расчет трудозатрат на программирование, то есть на написание исходного кода программы. Затраты на программирование составляет примерно 20 – 30 % от общих трудозатрат на остальные этапы разработки программы. Расчет затрат на программирование, как 25% от общих трудозатрат, посредством выражения из формулы (1) и подстановки известных значений: 𝑡др = 22,95 + 8,2 + 19,125 + 5,74 ∙ 0,25 = 14 чел ∗ час. Общие трудозатраты составят: 𝑡др = 22,95 + 8,2 + 19,125 + 5,74 + 14 = 70 чел ∗ час. Полученные трудозатраты на разработку приложения представлены в таблице 4.1. Таблица4.1–Трудозатратынаразработкуприложения
В результате составленной таблицы наибольшее количество трудозатрат при разработке программного продукта приходится на отладку программы и изучение задачи. |