отчет. Магистерской диссертации
 Скачать 1.86 Mb.
|
|
Раздел Процент 1. / 34,90 % 2. /portfolio.php 18,68 % 3. /about.php 11,05 % 4. /courses.php 9,52 % 5. /other Исходя из данных таблицы видно, что пользователи большую часть времени проводят в разделе портфолио. Что может являться показателем того, что такой инструмент, как аккумулирование и ведение портфолио на сайте работает. Это есть хорошая альтернатива скролингу социальных сетей в поисках хэштегов с именами мастеров. Сеансы; 25- 34; 146; 37% Сеансы; 35- 44; 69; 18% Сеансы; 45- 54; 41; 10% Сеансы; 18- 24; 135; 35% Сеансы 25-34 35-44 45-54 18-24 54 2.4 Анализ лояльности текущей клиентской базы Мы определяем лояльность покупателей – как основу целей организации. Исследование лояльности – это составная часть оценки качества услуг, предоставляемых компанией (рисунок 6). Рисунок 6 – Процесс исследования удовлетворенности и лояльности клиентов Процесс оценки лояльности – это стратегический инструмент, который позволяет определить уровень и качество взаимоотношений компании с клиентами и позволяет разработать план действий по удержанию и наращиванию позиций на рынке. Основные принципы процесса оценки лояльности заключаются в следующем: - возможность анализа результатов исследования; - стратегический фактор-удовлетворенность клиента; Мотивация сотрудников Удовлетворенность покупателей Качество обслуживания Удовлетворенность покупателей Показатели Лояльность покупателей Качество Процесс оценки Качество обслуживания Вымышленный покупатель Удовлетворенность персонала 55 - определение места организации в конкурентной среде; - стремление определить все факторы, влияющие на лояльность (психологические, экономические и т.д.); Исследования проводились на основе методики, представленной, на рисунке 7. Рисунок 7 – Процесс исследования удовлетворенности и лояльности клиентов Изучение лояльности является детальным анализом: - предпочтений времени записи; - факторов выбора мастера; - удобства записи; - оценки качества работы мастера. Методология данного исследования основана на: - репрезентативном очном опросе клиентов, т.е. опросе, проводимом на основе выборочной совокупности, позволяющий экстраполировать выводы на всю генеральную совокупность. На рисунке 8 представлены данных опроса по выявлению лояльности текущих клиентов и сопоставления фактического участия в жизни студии в период с 01.03.17 по 22.04.17. 56 Рисунок 8 – Процесс исследования удовлетворенности и лояльности клиентов Рисунок 9 содержит сведенную статистику по уровню удовлетворенности клиентов бизнес-процессами студии. Стоит отметить, что данные показатели также свидетельствуют о высоком уровне лояльности текущей клиентской базы. Рисунок 9 – Процесс исследования удовлетворенности и лояльности клиентов Анализируя данные представленные выше и данные анализа трафика сайта можно сказать, что студия не испытывает проблем с бизнес-процессом удержанием лояльности текущих клиентов, что, безусловно, наталкивает на мысль разобрать бизнес-процесс привлечения новых клиентов. Порекоменд овали репостом; Буду рекомендова ть(98 чел.); … Порекоменд овали репостом; Скорее всего (43 чел.); 23 Порекоменд овали репостом; Не интересно (6 чел.); 0 Привели друга; Буду рекомендова ть(98 чел.); 29 Привели друга; Скорее всего (43 чел.); 7 Привели друга; Не интересно (6 чел.); 0 Оба способа; Буду рекомендова ть(98 чел.); 29 Оба способа; Скорее всего (43 чел.); 7 Оба способа; Не интересно (6 чел.); 0 Оба способа Привели друга Порекомендовали репостом Отлично; Работа мастеров; 138 Отлично; Цена- качество; 112 Отлично; Работа админитсрато ра; 145 Отлично; Ассортимент услуг; 129 Отлично; Частота акций; 98 Требует внимания; Работа мастеров; 9 Требует внимания; Цена- качество; 35 Требует внимания; Работа админитсрато ра; 2 Требует внимания; Ассортимент услуг; 18 Требует внимания; Частота акций; 49 Отлично Требует внимания 57 2.5 Оптимизация бизнес-процессов предприятия Большая часть клиентов готовы рекомендовать услуги и действительно это делают. Основной трафик сайта генерируют уникальные посетители, а это значит, что мы не удерживаем аудиторию на сайте, а также не имеем механизма побуждения к действию. Таким механизмом может быть модуль «Онлайн-записи». Это своего рода рупор: «Мы вас ждем, вот наши мастера, вот их работы, выбирай и вперед на мэйк!». Таким образом, сформулированы основные положения по оптимизации двух бизнес-процессов привлечения клиентов представлены в таблице 7. Таблица 7 – Бизнес-процессы, подлежащие изменениям поведения пользователей на сайте Наименования БП Подлежит оптимизации Подлежит полной реорганизации Оформление записи на процедуру - + Привлекательная модель лояльности + - В процессе построения AS-IS модели бизнес-процесса «Оформление записи на процедуру» была выявлена необходимость оптимизации, которая может решить две проблемы: сокращение времени на запись и побудить пользователя к действию на этапе посещения сайта. Модель AS-IS представлена на рисунке 10. 58 Рисунок 10 – « Процедура записи». Модель «AS-IS» Ниже, на рисунке 11, представлена декомпозиция процесса записи. Рисунок 11 –Декомпозиция процесса «Запись» Согласно текущему регламенту, клиент оставляет заявку в любой социальной сети, где представлена студия, что требует от администратора постоянного мониторинга заявок, далее в MS Excel администратор выявляет 59 возможность записи на определенное время и возвращает время на согласование клиенту. Запись считается завершенной после акцептования времени клиентом и осуществления процедуры, а также внесения соответствующей записи в MS Excel. Зачастую оперативность записи влияет на лояльность клиента, а в некоторых случаях приводит к его потере. В результате анализа общих временных затрат, была выдвинута идея разработки модуля онлайн записи. Это позволит сократить количество процессов предшествующих обработке заявки, а также вести запись клиентов централизованно посредством программного решения. 2.6 Разработка модели лояльности. Исследования, проведенные во второй главе, показывают, что рынок являет собой интенсивную конкурентную среду. Основная проблема заключается в замедлении роста объема продаж. В подобной ситуации рекомендуется ориентация на повышение прибыльности бизнеса, поиск путей диверсификации бизнеса, наиболее оптимальной является стратегия дифференциации. Пути развития бизнеса указаны в таблице 8. Таблица 8 – Поиск путей развития бизнеса РЫНОК существующий новый П Р О Д У К Т существующий 1. Повышение лояльности существующих клиентов 2. Охват большей аудитории новый 3. Создание бизнес-процесса онлайн запись 4. Увеличение количества услуг Критерии отбора: - достижение стратегической цели – повышению объема прибыли на 20%; 60 - временные границы – 6 мес; - затраты на реализацию не должны превысить 20% от оборота. Потребительская лояльность: - удовлетворенность; - регулярность и постоянство суммы закупок услуг; - доля студии в закупках услуг клиента; - готовность рекомендовать; - имидж лучшей студии по соотношению: цена-качество. Анализ существующей системы работы с клиентами проводится следующим образом: - анализируется структура клиентского портфеля услуг; - определяется потенциал продаж услуг; - производится классификация и отбор клиентов с целью определения наиболее прибыльных и отсеивания неприбыльных; - анализируется детерминант лояльности и удовлетворенности клиентов, производится оценка их существующего уровня. На рисунке 12 показаны этапы определения потенциала продаж. Рисунок 12 – Определение потенциала продаж Определяем потенциал продаж, таблица 11. Это можно сделать по следующим критериям: - Норма продаж в неделю; - Доля клиентов в общем количестве; - Доля группы в общем объеме клиентов. Таблица 11 – Потенциал продаж Группировка по качественным признакам Определение лучших представителей в группе Определение потенциала продаж 61 Xарактеристика Потенциал продаж низкий средний высокий VIP 3 4 5 6 7 8 9 Норма продаж в неделю, руб. 12000 14000 17000 20000 25000 30000 35000 Доля клиентов в общем количестве, % 55 14 6 11 9 5 Доля группы в общем объеме клиентов, % 55 20 20 5 На основе данных таблицы 11, проанализировав потенциал продаж, мы можем выявить структуру клиентов студии AlisaMakeUp, таблица 12: Таблица 12 – Структура клиентов студии «AlisaMakeUp» Низкий потенциал Средний потенциал Высокий потенциал VIP 3-4 5-6 7-8 9 Доля клиентов в общем колличестве,% 55% 20% 20% 5% Окончание таблицы 12 Низкий потенциал Средний потенциал Высокий потенциал VIP 3-4 5-6 7-8 9 Доля клиентов в общем объеме продаж, % 25% 15% 25% 35% Программа лояльности будет проводиться следующим образом, таблица 13. Таблица 13 – Программа лояльности студии «AlisaMakeUp» От 2 услуг От 3 услуг От 4 услуг Фотопроект Скидка на сумму 200 руб. Скидка на сумму 300 руб. Скидка на сумму 500 руб. Скидка на сумму 600 руб. Мониторинг лояльности отражен в таблице 14. 62 Таблица 14 – Мониторинг лояльности студии «AlisaMakeUp» Характеристик и Атрибуты Периодичность контроля показателей ежедневно, очный опрос, соц.сети В начале каждой недели Привлекающие Качество работы мастеров Желаемые оперативность в решении возникающих проблем рекламная поддержка компетентность и качество работы адинистратора Ожидаемые Вариативность услуг уровень цен наличие скидок Разработанная модель лояльности будет являться инструментом удержания клиентской базы студии. Внедрение данных рекомендаций запланировано после тестирования MVC модуля «Онлайн-запись» т.к. это может повлиять на результаты тестирования гипотезы о привлечении новых клиентов программным продуктом. 63 3. РАЗРАБОТКА ИНФОРМАЦИОННОГО МОДУЛЯ 3.1 Формирование требования к ИС Студия AlisaMakeUp на сегодняшний день активно исследует методы увеличения прибыли без существенных оперативных издержек. Проведя анализ факторов увеличения конверсии, мы построили гипотезу о влиянии функциональной возможности «Онлайн запись» на конверсию продаж услуг. Для запуска данной возможности необходимо разработать программный модуль и интегрировать его в текущую инфраструктуру. Разработка и внедрение модуля «Онлайн-запись»» необходима для выполнения следующих задач: - ведение расписания работы мастеров; - ведение заявок на оказание услуг клиентам; - ведение портфолио мастеров; - получение обратной связи от клиента; - формирование необходимой отчетности в формате xml. 3.2 Разработка технического задания В соответствии с ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» было разработано техническое задание на разработку программного модуля «Онлайн-записи» для студии AlisaMakeUp. 3.2.1 Общие сведения Полное наименование системы: Программный модуль «Онлайн- запись». Краткое наименование системы: модуль «Онлайн-запись». Основанием для проведения работ разработке модуля служит согласованное с администрацией студии задание на разработку/внедрение. 64 3.2.2 Назначение и цели создания системы Программный модуль предназначен для автоматизированного ведения заявок пользователей на оказание услуг. Цели создания: - ведение графика работы мастеров; - ведение портфолио; - автоматическа подгрузка данных портфолио и графика; - возможность брони/подтверждения времени; - формирование необходимой отчетности в формате xml. В результате разработки и внедрения Модуля «Онлайн-запись» должны быть улучшены значения следующих показателей: - оформление записи на процедуру; - время составления отчетности; - время выбора мастера; - время, затрачиваемое на информационно-аналитическую деятельность. 3.2.3 Характеристика объектов автоматизации Характеристика объектов автоматизации приведена в таблице 15. Таблица 15 – Характеристика объектов автоматизации Структурное подразделение Наименование процесса Возможность автоматизации Решение об автоматизации в ходе проекта Администрация Формирование отчетности Возможна Будет автоматизирован Управление персоналом Ведение портфолио и графика Возможна Будет автоматизирован Управление персоналом Организация контроля качества Возможна Будет автоматизирован Управление персоналом Анализ и выявление инцидентов Возможна Будет автоматизирован 65 3.2.4 Требования к системе 3.2.4.1 Требования к системе в целом 3.2.4.1.1 Требования к структуре и функционированию системы Модуль должен иметь сущность в БД и подсистемы ввода–вывода данных, предусматривающих графический интерфейс работы пользователя с ними. Модуль должен поддерживать разграничение прав доступа и иметь следующие подсистемы: - система администрирования доступа; - система обработки и выполнения команд; - система чтения и обработки данных; - система размещения данных в БД; - система формирования и визуализации отчетности. Для организации информационного обмена между компонентами Системы должен использоваться MVC паттерн на базе PHP. 3.2.4.1.2 Требования к способам и средствам связи для информационного обмена между компонентами системы Программно-технические средства компонент модуля должны соответствовать стандартам обмена с использованием протокола TCP/IP. 3.2.4.1.3 Требования по диагностированию системы Модуль должен иметь встроенные системы диагностирования. Проводимая диагностика должная обеспечивать возможность определения 66 корректности функционирования системы и определения возможных сбоев в системы. 3.2.4.1.4 Требования к режимам функционирования Разрабатываемый программный модуль предназначен для работы в непрерывном (круглосуточном) режиме. Технологические перерывы не предусмотрены. 3.2.4.1.5 Перспективы развития, модернизации системы Программный модуль должен разрабатываться с учетом обеспечения его дальнейшего развития и наращивания функциональности. При этом в него уже должны быть заложены основные архитектурные принципы MVC. 3.2.4.1.6 Требования к численности и квалификации персонала системы и режиму его работы 3.2.4.1.6.1 Требования к численности персонала Численность пользователей системы и необходимого обслуживающего персонала уточняется на этапе назначения Agile-команды. 3.2.4.1.6.2 Требования к квалификации персонала В таблице 16 Представлены предусмотренные роли для обслуживания и разработки программного модуля. Таблица 16 – Роли для обслуживания и разработки программного модуля Роль Кол-во Квалификация 1 Веб-разработчик 2 Знание php, html5, Знание методологии проектирования БД, MVC паттерна. 67 Окончание таблицы 16 Роль Кол-во Квалификация 2 SMM-специалист 1 Понимание паттернов индустрии, управления брендом в сети 3 Веб-дизайнер 1 Дизайн макета 3.2.4.1.7 Показатели назначения 3.2.4.1.7.1 Требования к приспособляемости системы к изменениям Обеспечение приспособляемости должно выполняться за счет: - своевременности администрирования; - модернизации процессов сбора, обработки и загрузки данных в соответствии с новыми требованиями; - модификации процедур доступа и представления данных конечным пользователям. 3.2.4.1.7.2 Требования сохранению работоспособности системы в различных вероятных условиях В зависимости от различных вероятных условий система должна выполнять различные требования, приведенные в таблице 17 Таблица 17 – Требования к работоспособности системы в различных вероятных условиях Вероятное условие Требование Ошибки функционирования модуля Уведомление администратора 3.2.4.1.8 Требования к надежности 3.2.4.1.8.1 Состав показателей надежности для системы в целом 68 Модуль должен обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях пользователю должны выдаваться соответствующие аварийные сообщения, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде, группы команд или некорректному вводу данных. 3.2.4.1.8.2 Требования к надежности технических средств и программного обеспечения К надежности электроснабжения предъявляются следующие требования: - модуль должны быть укомплектован подсистемой оповещения администраторов о переходе на автономный режим работы. Надежность аппаратных и программных средств должна обеспечиваться за счет следующих организационных мероприятий: - предварительного обучения пользователей и обслуживающего персонала; - своевременного выполнения процессов администрирования; - соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств; - своевременное выполнение процедур резервного копирования данных. Надежность программного обеспечения систем модуля должна обеспечиваться за счет: - надежности общесистемного ПО; - проведением комплекса мероприятий отладки, поиска и исключения ошибок; 69 - ведением журналов системных сообщений и ошибок по подсистемам для последующего анализа и изменения конфигурации. 3.2.4.1.9 Требования к эргономике и технической эстетике Взаимодействие пользователей с модулем должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме, в реальном времени. Интерфейс должен соответствовать современным эргономическим требованиям и обеспечивать удобный доступ к основным функциям и операциям, выполняемым подсистемами. Система чтения, обработки данных должна обеспечивать удобный для конечного пользователя интерфейс, отвечающий следующим требованиям. В части внешнего оформления: - интерфейсы подсистем должен быть типизированы; - должно быть обеспечено наличие русскоязычного и английского интерфейса пользователя; - должен использоваться шрифт: Roboto. В части диалога с пользователем: - при возникновении ошибок в работе подсистемы на экран монитора должно выводиться сообщение с наименованием ошибки и с рекомендациями по её устранению на русском языке. В части процедур ввода-вывода данных: - должна быть возможность многомерного анализа данных в табличном и графическом видах. 70 3.2.4.1.10 Требования к защите информации от несанкционированного доступа Обеспечение информационной безопасности программного модуля «Онлайн-запись» должно осуществляться за счет встроенной системы администрирования доступа. 3.2.4.1.11 Требования по сохранности информации при авариях Должна быть предусмотрена возможность организации автоматического или ручного резервного копирования данных. Порядок проведения мер по организации автоматического или ручного резервного копирования данных должен быть приведен в эксплуатационной документации. Резервное копирование данных осуществляется посредством Системы Размещения данных в БД. 3.2.4.1.12 Требования по стандартизации и унификации Разработка должна осуществляться с использованием стандартных методологий функционального моделирования: IDEF0, DFD в рамках рекомендаций по стандартизации Р50.1.028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования». Моделирование должно выполняться в рамках стандартов, поддерживаемых программными средствами моделирования BPWin 4.х. Для разработки пользовательских интерфейсов и средств генерации отчетов должны использоваться встроенные возможности АБС. 71 Должны использоваться (при необходимости) общероссийские классификаторы и единые классификаторы и словари для различных видов алфавитно-цифровой и текстовой информации. 3.2.4.1.13 Требования безопасности Все технические решения, использованные при разработке модуля, а также при определении требований к аппаратному обеспечению, должны соответствовать действующим нормам и правилам техники безопасности, пожарной безопасности и взрывобезопасности, а также охраны окружающей среды при эксплуатации. 3.2.4.2 Требования к функциям, выполняемым системой 3.2.4.2.1 Система администрирования доступа Система администрирования доступа обеспечивает защиту от несанкционированного доступа к элементам модуля. 3.2.4.2.2 Система обработки и выполнения команд Система обеспечивает корректную интерпретацию и выполнение команд. 3.2.4.2.3 Система чтения и обработки данных 3.2.4.2.3.1 Перечень функций и задач подлежащих автоматизации В таблице 18 приведен перечень функций и задач, подлежащих автоматизации. 72 Таблица 18 – Перечень функций и задач, подлежащих автоматизации Функция Задача Управляет процессами сбора, обработки и загрузки данных по процедуре онлайн-записи. Создание, редактирование и удаление данных по осуществлению онлайн-записи Формирование последовательности выполнения процессов сбора, обработки и загрузки данных по осуществлению онлайн-записи Осуществление процессов сбора, обработки данных Определение и изменение расписания процессов сбора, обработки и загрузки данных Запуск процедур сбора данных из систем источников, загрузка данных в область временного, постоянного хранения Обработка и преобразование извлечённых данных Ведение протокола результатов Ведение журналов результатов сбора, обработки и загрузки данных Оперативное извещение пользователей о всех нештатных ситуациях в процессе работы подсистемы 3.2.4.2.3.2 Временной регламент реализации каждой функции, задачи В таблице 19 приведен временной регламент реализации каждой функции и задачи. Таблица 19 – Временной регламент реализации функций и задач Задача Требования к временному регламенту Создание, редактирование и удаление данных по осуществлению онлайн-записи Весь период функционирования, при возникновении необходимости изменения процессов сбора, обработки и загрузки Формирование последовательности выполнения процессов сбора, обработки и загрузки данных по осуществлению онлайн- записи Весь период функционирования системы, при возникновении необходимости модификации регламента загрузки данных Запуск процедур сбора данных из систем источников, загрузка данных в область временного, постоянного хранения Весь период функционирования системы. В режиме реального времени Обработка и преобразование извлечённых данных Весь период функционирования системы. В режиме реального времени Ведение журналов результатов сбора, обработки и загрузки данных Регулярно, при работе подсистемы Оперативное извещение пользователей о всех нештатных ситуациях в процессе Регулярно, при возникновении нештатной ситуации в процессе работы подсистемы 73 работы подсистемы 3.2.4.2.4 Система размещения данных в БД 3.2.4.2.4.1 Перечень функций и задач подлежащих автоматизации В таблице 20 приведен перечень функций и задач, подлежащих автоматизации. Таблица 20 – Перечень функций и задач, подлежащих автоматизации Функция Задача Управление сущностью модуля в БД Создание и сопровождение сущности модуля «онлайн-запись» в БД Формирование последовательности выполнения процессов создания и управления сущности «онлайн- запись» в БД Размещение, хранение и преобразование данных Запуск процедур размещения, хранения и преобразования данных в соответствии с настройками бизнес-объекта модуля Обработка и преобразование извлечённых данных Протоколирование результатов сбора, обработки и загрузки данных Ведение журналов результатов сбора, обработки и загрузки данных Оперативное извещение пользователей о всех нештатных ситуациях в процессе работы подсистемы Предоставление данных Предоставление данных необходимых для дальнейшего преобразования Резервное копирование данных Осуществление резервного копирования данных. Информирование о результатах архивирования 3.2.4.2.5 Система формирования и визуализации отчетности 3.2.4.2.5.1 Перечень функций и задач подлежащих автоматизации В таблице 21 приведен перечень функций и задач, подлежащих автоматизации. Таблица 21 – Перечень функций и задач, подлежащих автоматизации Функция Задача Логическое представление данных Создание логической модели данных Создание и сопровождение запросов и отчетности Обработка логической модели данных 74 Выполнение запросов Окончание таблицы 21 Функция Задача Предоставление отчетности Обработка запросов Преобразование полученных данных в табличную, графическую форму отчетности Предоставление отчетности пользователю 3.2.4.3 Требования к видам обеспечения 3.2.4.3.1 Требования к математическому обеспечению Не предъявляются. 3.2.4.3.2 Требования к информационному обеспечению 3.2.4.3.2.1 Требования к информационному обмену между компонентами системы Информационный обмен между компонентами онлайн модуля должен быть реализован, согласно таблице 22. Информационный обмен между компонентами системы, условные обозначения: - «Х» - обмен осуществляется; - «–» - обмен не осуществляется. Таблица 22 – Перечень функций и задач, подлежащих автоматизации Система администри- рования доступа Система обработки и чтения команд Система чтения, обработки данных Система размещения данных в БД Система формирования и визуализации отчетности Система администри- рования доступа – X – – – 75 Окончание таблицы 22 Система администри- рования доступа Система обработки и чтения команд Система чтения, обработки данных Система размещения данных в БД Система формирования и визуализации отчетности Система обработки и чтения команд X – X – – Система чтения, обработки данных – X – X – Система размещения данных в БД – – X – X Система формирова- ния и визуализации отчетности – – – X – 3.2.4.3.2.2 Требования по использованию классификаторов, унифицированных документов и классификаторов На усмотрение разработчика. 3.2.4.3.2.3 Требования к контролю, хранению, обновлению и восстановлению данных Стандартные требования, предъявляемые при разработке, доработки программных модулей, работающих с пользовательскими данными. 3.2.4.3.2.4 Требования к процедуре придания юридической силы документам, продуцируемым техническими средствами системы Требования не предъявляются. 76 3.2.4.3.3 Требования к лингвистическому обеспечению Стандартные требования, предъявляемые при разработке, доработки программных модулей, работающих с пользовательскими данными. 3.2.4.3.4 Требования к техническому обеспечению Стандартные требования, предъявляемые при разработке, доработки программных модулей, работающих с пользовательскими данными. 3.2.4.3.5 Требования к метрологическому обеспечению Не предъявляются. 3.2.4.3.6 Требования к организационному обеспечению Основными пользователями модуля «Онлайн-запись» являются клиенты студии AlisaMakeUp. Функциональным подразделением является персонал студии AlisaMakeUp. Состав и расписание обслуживающего персонала определяется штатным расписанием студии AlisaMakeUp, которое, в случае необходимости, может изменяться. К организации функционирования Системы и порядку взаимодействия персонала, обеспечивающего эксплуатацию, и пользователей предъявляются следующие требования: - в случае возникновения со стороны функционального подразделения необходимости изменения функциональности модуля, персонал должен действовать следующим образом: 77 оформить заявку в системе управления задачами на разработчика информационной системы. К защите от ошибочных действий персонала предъявляются следующие требования: - для всех пользователей должна быть запрещена возможность удаления преднастроенных объектов и отчетности; - для снижения ошибочных действий пользователей должно быть разработано полное и доступное руководство пользователя. 3.2.4.3.7 Требования к патентной чистоте По всем техническим и программным средствам, применяемым в системе, должны соблюдаться условия лицензионных соглашений и обеспечиваться патентная чистота. 3.2.5 Состав и содержание работ по созданию системы Состав и содержание работ определяются по итогам планирования Спринта. 3.3 Архитектура приложения System has been developed on the basis of the following secure techniques: PHP, JavaScript, Ajax, HTML5, CSS3, RBAC Yii, jQuery. Database: MySQL. В основе архитектуры информационной системы является MVC шаблон. Это позволило отделить бизнес-логику приложения от пользовательского интерфейса. В результате, мы упростили процесс масштабирования, тестирования, обслуживания и внедрения. Информационная система состоит из четырех модулей, которые интегрированы в эту модель: profile, admin, schedule, onlineApply. Порядок 78 работы может быть описан как последовательное взаимодействие этих компонентов архитектуры: - когда пользователь проходит авторизацию в учебной платежной системе сценарий инициализации создает экземпляр приложения и запускает его. Значение по умолчанию отражает экземпляр аккаунт-модуля; - затем приложение получает запрос пользователя и определяет запрошенный контроллер и действие. Что касается домашней страницы, действие по умолчанию (index); - приложение создает экземпляр контроллера и запускает метод действия, в котором, например, содержаться вызову модели внесения информации по новому товару в базу данных: - после этого, действие порождает представление данных, полученных от модели и выводит результат пользователю. Рассмотрим блок-схему архитектуры приложения, с последующим описанием ее составных частей, на рисунке 13. Рисунок 13 –Архитектура локально платежной системы Модель (Model). Модель локальной платежной системы содержит бизнес-логику приложения, включая методы сбора, обработки, правила проверки и процессов представления конкретных данных. Логика бизнес- приложения, распределяется между четырьмя основными модулями: 79 - schedule module содержит логику: ведения графика работы мастеров, оформления процедуры онлайн-записи; - onlineApply module содержит логику оформления процедуры онлайн-записи (подсчет стоимости, акцептование и т.д.); - profile Module отвечает за управление портфолио мастеров и обратной связью от клиентов; - admin Module обеспечивает аутентификацию и администрирование, а так же методы контроля. Модель непосредственно не взаимодействует с пользователем. Все переменные, связанные с запросом пользователя сначала должны быть обработаны контроллером. Модель не генерирует код отображения HTML или другие коды отображения, которые могут быть изменены в соответствии с потребностями пользователя, за это отвечает view. Вид (View). Вид используется для внешнего отображения данных, полученных от контроллера и модели. Вид содержит HTML-форматирование и другие PHP вставки кода для обработки отображения данных. Вид не относится напрямую к базе данных и не работает с данными, полученными из запроса пользователя. Эта задача должна выполняться контроллером. Он может напрямую обращаться к свойствам и методам контроллера или моделей для получения готовых к выходу данных. Виды информационной системы загружаются под управлением контекстного меню. Контроллер (Controller). Контроллер является связующим звеном, которое соединяет модель, вид и другие компоненты в функционирующее приложение. Контроллер отвечает за обработку запросов пользователей. Контроллер не включает в себя SQL-запросы (они содержатся в модели), HTML и другие представления (они содержатся в View). Его основная функция - вызов и координация ресурсов и объектов, необходимых для выполнения действий, заданных пользователем. Контроллер определяет подходящую модель для задачи и выбирает соответствующий вид. 80 Модуль доступа (Access module). Модуль доступа предназначен для взаимодействия модели и основных функциональных. В нашей ИС существует понятие элемента авторизации – это фактически разрешение на выполнения определенного действия. На рисунке 14 показана структура элемента авторизации локальной платежной системы. Рисунок 14 – Структура элемента авторизации Элемент авторизации однозначно идентифицируется своим первоначальным названием. Элемент авторизации и связанный с ним бизнес- правила - это PHP-коды будут использоваться для проверки доступа. Пользователи будут иметь доступ к элементу только после того, как код возвращает результат true. Это ограничение позволило создать гибкую систему распределения полномочий. Элемент А является родительским элементом B. Согласно иерархии, если А состоит из B (или наследуется права, представленные в B). Элемент может иметь несколько потомков и несколько предков. Таким образом, разработанная система обладает высокой производительностью за счет оптимизации модели. Система может быть легко масштабируется путем добавления бизнес-логики в модель. 3.4 Эскизный проект На рисунке 15, размещен эскизный проект модуля «Онлайн-запись» в нотации IDEF0. Эскизный проект будет служить для нас моделью «TO-BE» Authorization element Role (Admin) Task (Delete goods) Task (Give access) Task (Drop user) Action Action Action Action Action 81 Рисунок 15 – Эскизный проект модуля. Уровень A0 Далее, на рисунке 16, представлена декомпозиция БП «Ведение онлайн записи». Рисунок 16 – Декомпозиция БП «Ведение онлайн записи» Бизнес процесс внесения и обработки данных заявок на запись в модели «TO-BE» представлен на рисунке 17. 82 Рисунок 17 – Декомпозиция БП «внесения и обработки данных» Далее, на рисунке 18 размещен процесс управления состояниями заявки. Рисунок 18 – Декомпозиция БП «Управление состояниями заявки» Размещение и получение данных БД представлены на рисунке 19. 83 Рисунок 19 – Декомпозиция БП «Размещение и получение данных БД» Бизнес процесс формирования визуальной отчетности в модели «TO- BE» представлен на рисунке 20. Рисунок 20 – Декомпозиция БП «Формирования визуальной отчетности» Назначением использования диаграммы IDEF0 служит визуальное отображение потоков данных между подсистемами и поток взаимодействия с внешними, относительно Системы, элементами. 84 В границы охвата модели входят все подсистемы информационной системы, представленные функциональными блоками. Основными объектами модели являются: - функциональные блоки. Отражают название функциональных подсистем; - стрелки управления (сверху функционального блока). Отражают команды (запросы от пользователей или других подсистем) и инструкции, влияющие на работу подсистемы; - стрелки входа (слева от функционального блока). Отражают входящие потоки данных из внешней среды или другой подсистемы; - стрелки выхода (справа от функционального блока). Отражают исходящие потоки (результаты работы подсистемы) данных во внешнюю среду (пользователям и администраторам) или в другую подсистему; - стрелки исполняющего механизма (снизу функционального блока). Отражают средства (программное обеспечение, людские ресурсы), которые используются при работе подсистемы. 3.5 Разработка программного модуля 3.5.1 План общего спринта В студии AlisaMakeUp Спринт назначается в начале месяца, его длительность составляет один месяц. Помимо этого, команда имеет право разделить работы по проекту на два Микроспринта. Эта практика применяется в небольших по времени проектах, в связи с необходимостью получить быстрый и четкий feedback от Владельца продукта. Как правило, большинство задач связано с бизнес-процессами обслуживания клиентов и тестированием гипотез. Мы используем Agile потому что большинство задач 85 из категории: разработка курсов и проведение акций, вполне можно считать конечным продуктом, над которым работают несколько членов команды в несколько итераций. На момент составление спринта перед командой стоял ряд задач, которые нужно было выполнить в течение месяца. Задачи представлены в таблице 23. Таблица 23 –Задачи спринта Тип запроса Дата создания Статус |